Артефакт является одним из многих видов материальных побочных продуктов , полученных в процессе разработки программного обеспечения. Некоторые артефакты (например, варианты использования , диаграммы классов и другие модели Unified Modeling Language (UML), требования и проектные документы) помогают описать функции, архитектуру и дизайн программного обеспечения. Другие артефакты связаны с самим процессом разработки - например, планы проектов, бизнес-модели и оценки рисков.
Термин « артефакт» в связи с разработкой программного обеспечения в значительной степени связан с конкретными методами или процессами разработки, например, унифицированный процесс . Такое использование термина могло появиться из этих методов [ необходима цитата ] .
Инструменты сборки часто называют исходный код, скомпилированный для тестирования, артефактом, поскольку исполняемый файл необходим для выполнения плана тестирования. Без исполняемого файла для тестирования артефакт плана тестирования ограничивается тестированием, не связанным с выполнением . При тестировании, не основанном на выполнении, артефактами являются пошаговые инструкции , проверки и доказательства правильности . С другой стороны, тестирование на основе выполнения требует как минимум двух артефактов: набора тестов и исполняемого файла. Иногда артефакт может относиться к выпущенному коду (в случае библиотеки кода ) или выпущенному исполняемому файлу (в случае программы), но чаще артефакт является побочным продуктом разработки программного обеспечения, а не самим продуктом. Библиотеки с открытым исходным кодом часто содержат средства тестирования, позволяющие участникам убедиться, что их изменения не вызывают ошибок регрессии в библиотеке кода.
Многое из того, что считается артефактом, - это документация по программному обеспечению .
При разработке для конечного пользователя артефакт - это либо приложение, либо сложный объект данных, который создается конечным пользователем без необходимости знать общий язык программирования. Артефакты описывают автоматизированное поведение или управляющие последовательности, такие как запросы к базе данных или правила грамматики [1], или контент, созданный пользователем.
Артефакты различаются по ремонтопригодности. На ремонтопригодность в первую очередь влияет роль, которую выполняет артефакт. Роль может быть как практической, так и символической. На самых ранних стадиях разработки программного обеспечения группа разработчиков может создавать артефакты, которые выполняют символическую роль, чтобы показать спонсору проекта, насколько серьезно подрядчик относится к удовлетворению потребностей проекта. Символические артефакты часто плохо передают информацию, но выглядят впечатляюще. Символические улучшают понимание. Вообще говоря, свитки с подсветкой также считаются недостижимыми из-за того, что для сохранения их символического качества требуется старание. По этой причине, как только свитки с подсветкой показаны спонсору проекта и одобрены, они заменяются артефактами, которые играют практическую роль. Практические артефакты обычно необходимо поддерживать на протяжении всего жизненного цикла проекта, и поэтому они, как правило, легко обслуживаются.
Артефакты важны с точки зрения управления проектом как результаты . Результаты программного проекта, вероятно, будут такими же, как и его артефакты, с добавлением самого программного обеспечения.
Смысл артефактов как побочных продуктов аналогичен использованию термина « артефакт» в науке для обозначения чего-то, что является результатом текущего процесса, а не самой проблемы, т. Е. Результат интереса, проистекающего из средств, а не из цели.
Для сбора, организации и управления артефактами может использоваться папка разработки программного обеспечения .
// POST: api / Todo[HttpPost]общедоступная асинхронная задача> PostTodoItem (элемент TodoItem) { _context.TodoItems.Add (элемент); ждать _context.SaveChangesAsync (); return CreatedAtAction (nameof (GetTodoItem), новый {id = item.Id}, item);}
Смотрите также
Рекомендации
- ^ Х. Либерман, Б.А. Нарди и Д. Райт. Grammex: определение грамматик на примере. На конференции ACM по человеческому фактору в вычислительных системах (резюме, демонстрации; CHI 1998), Лос-Анджелес, Калифорния, США, стр. 11–12. ACM Press, апрель 1998 г.
дальнейшее чтение
- Пер Кролл и Филипп Крюхтен (2003). Rational Unified Process Made Easy: Практическое руководство по RUP . .