...
- Место концепции в ТЗ
- Место описания бизнес-процессов в ТЗ
- Место вариантов использования и других требований в ТЗ
...
Ой ли?
Ой.
Если в проекте нужно работать по ГОСТам, то по
ГОСТ 34.601-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ" первыми 3-мя стадиями идут:
1. Формирование требований к АС
2. Разработка концепции АС.
3. Техническое задание.
Далее, если посмотрим по содержанию
РД 50-34.698-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ" (Приложение 1), то увидим, что на 1-м этапе пишется отчет по ГОСТ 7.32, основное содержание которого:
1) характеристика объекта и результатов его функционирования;
2) описание существующей информационной системы;
3) описание недостатков существующей информационной системы;
4) обоснование необходимости совершенствования информационной системы объекта;
5) цели, критерии и ограничения создания АС;
6) функции и задачи создаваемой АС;
7) выводы и предложения.
А более детально раздел 2 "
Описание существующей информационной системы" содержит:
описание функциональной и информационной структуры системы, качественных и количественных характеристик, раскрывающих взаимодействие ее компонентов в процессе функционирования
, а это собственно и есть модели бизнес-процессов и прочее, одним понятием - модель деятельности объекта автоматизации.
Далее, то что на стадии "
Разработка концепции АС" разрабатывается концепция АС думаю, и так понятно (оформляется отчётом по ГОСТ 7.32).
Теперь посмотрим на группы обобщённых сценариев взаимодействия (aka варианты использования) - что они содержат? Описание взаимодействия пользователей и системы. Откуда эти сценарии берутся, от заказчика? Нет, они являются результатом ПРОЕКТИРОВАНИЯ ВЗАИМОДЕЙСТВИЯ, как работы по определению хода развёртывания взаимодействия реактивной функции (в отличие от трансформационной), затребованной от системы на этапе ТЗ. Т.е. это материал для стадий 4/5 по ГОСТ 34.601 - "
Эскизный проект", "Т
ехнический проект".
Смотрим содержание документа "
Описание функциональной структуры" из ЭП/ТП:
1) элементы функциональной структуры АС (подсистемы АС); автоматизированные функции и (или) задачи (комплексы задач); совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком;
2) информационные связи между элементами и с внешней средой с кратким указанием содержания сообщений и (или) сигналов, передаваемых по связям, и при необходимости, связи других типов (входимости, подчинения и т. д.);
3) детализированные схемы частей функциональной структуры (при необходимости).
А также документ "
Описание автоматизируемых функций":
1) исходные данные;
2) цели АС и автоматизированные функции;
3) характеристика функциональной структуры;
4) типовые решения (при наличии).
Раскроем отсюда пункт 3:
1) перечень подсистем АС с указанием функций и (или) задач, реализуемых в каждой подсистеме;
2) описание процесса выполнения функций (при необходимости);
3) необходимые пояснения к разделению автоматизированных функций на действия (операции), выполняемые техническими средствами и человеком;
4) требования к временному регламенту и характеристикам процесса реализации автоматизированных функций (точности, надежности и т.п.) и решения задач.
Ба, да 2-3 это собственно и есть алгоритмы для трансформационных функций и сценарии взаимодействия для реактивных (use case'ы)!
Ещё простой пример логики - что такого технического в модели бизнес-процессов и концепции, чтобы засовывать их в документ под названием ТЕХНИЧЕСКОЕ задание? Да ничего.
Просмотр сообщений
. Видно, что львиная доля бизнес-моделирования приходится на стадию Развития.