Начиная разговор об артефактах, важно сказать несколько слов о стадиях создания информационной системы. Выделяют 8 основных стадий:

1. Формирование требований к АС
2. Разработка концепции АС
3. Техническое задание
4. Эскизный проект
5. Технический проект
6. Рабочая документация
7. Ввод в действие
8. Сопровождение АС

Каждая стадия может содержать целый комплекс мероприятий. Они в свою очередь в зависимости от методологии разработки на проекте могут выполняться либо строго одно за другим, либо параллельно, весь объем работ (функций системы) реализуется сразу или итерациями, обеспечивая плавный прирост возможностей системы и высокую степень адаптивности к условиям динамичного мира. Неизменным остается факт наличия на каждой стадии своих артефактов и конкретных видов требований в них. Исходя из определения термина "Артефакт", к ним можно отнести электронные письма, код разработчика, даже сообщения в чате. Но в пределах данного материала я буду более подробно останавливаться на тех артефактах (или документах), которые прямо влияют на продукт или процесс и используются многими участниками процесса.

ГОСТ 34.201-89 приводит довольно большой список документов, для автоматизированных систем (более 50 наименований). Из этого списка, помимо десятка ведомостей, описаний, схем и перечней стоит выделить отдельно те, которые являются, можно сказать основой для традиционных методологий разработки:

• Отчет о результатах обследования объекта автоматизации
• Концепция автоматизированной системы
• Техническое задание на разработку АС
• Общее описание системы
• Пояснительная записка к техническому проекту
• Схема функциональной структуры
• Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистемы, систем)
• Руководство пользователя

Для гибких методологий обобщенный перечень артефактов выглядит следующим образом:

• Vision. Может включать примерный перечень User story). Подробнее:  Статья 1  Статья 2
• Preliminary Plan (Дорожная карта). Подробнее:  Статья 1  Статья 2
• Архитектура (Черновик). Подробнее:  Статья 1
• План итераций. Подробнее:  Статья 1
• Product Backlog. Подробнее:  Статья 1
• Sprint Backlog + Sprint Goal. Подробнее:  Статья 1
• Test Cases. Подробнее:  Статья 1

Структура и содержание документов может отличаться в зависимости от шаблонов, используемых разработчиками или по требованию заказчика, однако вот эти свойства, на мой взгляд, справедливы для каждого артефакта:

• Версия. На всех этапах жизни документа важно контролировать его актуальность. Для артефактов большого объема, в которых изменения сложно найти в теле документа, история изменений в купе с номером версии помогут всем участникам процесса легко отличить устаревший экземпляр от актуального.
• Владелец / автор. Для каждого документа должен быть однозначно определен список лиц, отвечающих за создание и актуализацию документа. Автор должен обладать максимумом информации для создания своего артефакта. Это гарантирует своевременный и качественный результат.
• Проверяющий / эксперт. В каждой предметной области есть свои эксперты. Это могут быть представили заказчика, сотрудники смежных подразделений компании разработчика или сам автор документа. Однозначно, проверку отраженной в артефакте информации необходимо проводить.
• Утверждающий. Лицо, принимающее решение об использовании документа в работе, а точнее конкретной версии документа.
• Пользователи / целевая аудитория документа. Перечень лиц, кому содержание документа важно и необходимо в работе.

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

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

Иерархия артефактов разработки.

Двигаясь по линии времени в обратном направлении, я попытаюсь описать необходимые и достаточные условия, которые предшествуют основным событиям запуска разработки.

1. Что требуется для старта разработки?

Для того, чтобы разработчики и инженеры начали что-то делать, необходимы, исключая формальные артефакты и управленческие решения, четко сформулированные и описанные задачи для каждой группы специалистов: верстальщикам - описание интерфейса, разработчикам - логика работы, типы данных и ограничения, базистам - описание объектов системы и так далее. Такую декомпозицию обычно проводят опытные разработчики (лиды), архитекторы, аналитики. Особенно актуальна декомпозиция в средних и больших командах (более 5 человек), распределенных командах или случаях, когда объем документации очень большой. Точечное описание требуемых от разработчика действий легко контролировать, оно не требует официального делового языка и не транслируется, как правило, заказчику. Постановки могут оформляться в виде карточек в системах управления проектами (task или bug tracker), или хорошо структурированными техническими заданиями в wiki системах или в форме документов.

2. Что требуется для декомпозиции и постановки задач?

Качественную декомпозицию можно выполнить при условии, что сформирован и утвержден список функций ПО на ближайшую итерацию разработки (спринт, месяц, этап работ). При этом, важно помнить, что этот список команда сможет / гарантирует выполнить в отведенный срок. Такой список может состоять из функциональных требований, user story (бэклог), фичей, технических задач - любой оцениваемой единице всего объема работ. Несмотря на отсутствие технических подробностей, утвержденный список работ - важный элемент коммуникации между заказчиком и командой. Он фиксирует взаимные договоренности, когда команда берет на себя ответственность выполнить, а заказчик - не менять объем и понимание конечной реализации до конца периода. 

3. Что требуется для оценки объема работ?

Не сложно догадаться, что наиболее качественная оценка будет дана при наличии подробного описания того, что нужно сделать. В этой связи, к моменту планирования нужно подходить с готовой спецификацией требований (ТЗ, пояснительная записка, описание технического проекта). Вариантов такой спецификации может быть масса: частное ТЗ на отдельную функцию, общее верхнеуровневое ТЗ с ограничениями и критериями приемки, сценарное описание взаимодействия элементов системы друг с другом и так далее.

4. Что требуется для подготовки спецификации требований?

Подготовка спецификации требований процесс трудоемкий и, отчасти, затрагивает проектирование системы целой командой специалистов. Приступать к нему следует осознанно. Чтобы минимизировать возможные риски и лишние затраты предварительно могут проводиться архитектурные советы, утверждающие в конечном итоге общую техническую концепцию или архитектуру ПО. Как правило, концепция и архитектура, содержат в себе если не полное перечисление, то общее понимание основного объема возможностей системы, атрибутов ее качества и характеристик надежности. Это ни что иное, как функциоанльные требования, системные требования и ограничения. В гибких методологиях применяется понятие бэклог продукта, который по мере развития системы постоянно расширяется.

5. На основе чего формируются требования?

Требования к системе обусловлены процессами, в которых она будет эксплуатироваться. В явном виде требования могут поступать от заказчика, однако лично в моей практике, чаще встречаются случаи, когда команда, а в частности аналитик, дизайнер, UX специалист, прорабатывают структуру требований, основываясь на знаниях предметной области и обозначенной решаемой проблеме. Основными источниками информации будут пользователи, нормативные и регламентирующие документы (бизнес-правила) и каким-либо образом зафиксированные процессы (утвержденные заказчиком схемы, модели или описания).

6. Что ограничивает область анализа?

Любое программное обеспечение создается с определенной целью. Эти цели всегда нужно держать в уме и заказчику, и команде разработки. В противном случае, есть риск создать продукт ради продукта, оторванный от реальности, не приносящий никакой пользы. Зафиксированные в явном виде верхнеуровневые цели (бизнес-требования) и целевые показатели системы определяют границы будущего проекта.

7. От чего исходят и что фиксируют?

Отправной точкой является проблема, идея или потребность заказчика.

Выводы

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

1Объемные артефакты дольше разрабатывать и сложнее читать, следовательно - дольше валидировать.

2Требования, распределенные по большому количеству артефактов сложнее поддерживать в актуальном состоянии. Требуется отлаженный механизм трассировки.

3Максимальная детализация требований будет в более поздних артефактах, следовательно на ранних стадиях высок риск некорректной оценки трудоемкости со стороны команды.