Для себя делаю несколько выводов об общем процессе создания проектных артефактов ИТ-аналитиком.
Итак, процесс ИТ-аналитика по созданию артефактов (по сути, документации и моделей) можно представить в следующем виде:
- Выявление целей и задач будущей автоматизированной Системы.
- Описание бизнес-процессов объекта автоматизации в состоянии "как есть" (AS IS) - бизнес варианты использования.
- Моделирование и описание концепции будущей Системы.
- Описание системных вариантов использования. По сути, это первоначальные процессы, но в состоянии "как должно быть" (TO BE).
- Формирование спецификации (SRS), или, другими словами, ТЗ, которое подробно описывает все функции будущей системы.
- По результатам разработки - создание справочной системы, руководств и инструкций.
Всё наглядно иллюстрирую с помощью VAD-диаграмм (см. рисунок ниже).
Коллеги, будут какие-либо дополнения/уточнения? Мне важно Ваше мнение.
Приведу очень важный комментарий от коллеги:
ОтветитьУдалитьtalk_of_wind (46.0.188.91) wrote:
22 Апр, 2012 05:16 (UTC)
Сначала нужно узнать п. 0 - бизнес-цель. От нее зависит все. Все цели и задачи самого ПО.
П. 2 может и не быть, если предполагается создание принципиально нового продукта. И тут п. 0 играет самую важную роль.
П. 3 - 6 присутствуют только если бюджет проекта и времени достаточен для выделения средств на их реализацию. Иногда ты можешь оказаться в условиях, когда нет времени и ресурсов на описание и моделирование.
SRS к концу проекта чаще всего неактуально выпускаемому продукту, т.к. в процессе разработки заказчик пробует продукт, осознает свои истинные потребности и меняет требования.
Самым актуальными и подробными документами должны быть руководства пользователей и администратора.
Разработчик может залезть в код и узнать, как работает тот или иной функционал. Но у пользователя гораздо больше времени и сил уйдет на узнавание системы методом тыка, если нет актуальных руководств.