Артефакт (разработка программного обеспечения)

редактировать

артефакт - это один из многих видов материальных побочных продуктов, возникающих в процессе разработки программного обеспечения. Некоторые артефакты (например, варианты использования, диаграммы классов и другие модели, требования и проектные документы Unified Modeling Language (UML)) помогают описать функцию, архитектуру, и дизайн программного обеспечения. Другие артефакты связаны с самим процессом разработки, например планы проектов, бизнес-модели и оценки рисков.

Термин «артефакт» в связи с разработкой программного обеспечения в значительной степени связан с конкретными методами или процессами разработки, например, Unified Process. Такое использование термина могло появиться благодаря этим методам.

Инструменты сборки часто называют исходный код, скомпилированный для тестирования, артефактом, потому что исполняемый файл необходим для выполнения плана тестирования. Без исполняемого файла для тестирования артефакт плана тестирования ограничен тестированием без выполнения. При тестировании, не основанном на выполнении, артефактами являются пошаговые руководства, проверки и доказательства правильности. С другой стороны, тестирование на основе выполнения требует как минимум двух артефактов: набора тестов и исполняемого файла. Иногда артефакт может относиться к выпущенному коду (в случае библиотеки кода ) или выпущенному исполняемому файлу (в случае программы), но чаще артефакт является побочным продуктом разработки программного обеспечения, а не сам продукт. Библиотеки с открытым исходным кодом часто содержат средства тестирования, чтобы участники могли убедиться, что их изменения не вызывают регрессии ошибок в библиотеке кода.

Большая часть того, что считается артефактами, - это документация по программному обеспечению.

В разработке для конечного пользователя артефакт - это либо приложение, либо сложный объект данных, созданный конечным пользователем. пользователю без необходимости знать общий язык программирования. Артефакты описывают автоматизированное поведение или управляющие последовательности, такие как запросы к базе данных, правила грамматики или контент, создаваемый пользователями.

Артефакты различаются по ремонтопригодности. На ремонтопригодность в первую очередь влияет роль, которую выполняет артефакт. Роль может быть как практической, так и символической. На самых ранних стадиях разработки программного обеспечения группа разработчиков может создавать артефакты, которые выполняют символическую роль, чтобы показать спонсору проекта, насколько серьезно подрядчик относится к удовлетворению потребностей проекта. Символические артефакты часто плохо передают информацию, но выглядят впечатляюще. Символические улучшают понимание. Вообще говоря, свитки с подсветкой также считаются недостижимыми из-за того, что для сохранения их символического качества требуется старание. По этой причине после того, как иллюминированные свитки показаны спонсору проекта и одобрены, они заменяются артефактами, которые играют практическую роль. Практические артефакты обычно необходимо поддерживать на протяжении всего жизненного цикла проекта, и, как таковые, их обычно легко поддерживать.

Артефакты важны с точки зрения управления проектами как результаты. Результаты программного проекта, вероятно, будут такими же, как и его артефакты с добавлением самого программного обеспечения.

Понимание артефактов как побочных продуктов аналогично использованию термина артефакт в науке для обозначения чего-то, что является результатом текущего процесса, а не самой проблемы, т. Е. Результата интереса, который проистекает из средств, а не из цели.

Для сбора, организации и управления артефактами может использоваться папка разработки программного обеспечения.

// POST: api / Todo [HttpPost] общедоступная асинхронная задача >PostTodoItem (элемент TodoItem) {_context.TodoItems.Add (item); ждать _context.SaveChangesAsync (); return CreatedAtAction (nameof (GetTodoItem), новый {id = item.Id}, item); }
См. Также
Ссылки
  1. ^H. Либерман, Б. А. Нарди и Д. Райт. Grammex: определение грамматик на примере. На конференции ACM по человеческому фактору в вычислительных системах (резюме, демонстрации; CHI 1998), Лос-Анджелес, Калифорния, США, стр. 11–12. ACM Press, апрель 1998 г.
Дополнительная литература
  • Per Kroll Philippe Kruchten (2003). Rational Unified Process Made Easy: Практическое руководство по RUP..
Последняя правка сделана 2021-06-11 21:51:40
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте