У меня подходит к концу проект, в котором целый этап был посвящен написанию ТЗ ровно по ГОСТ 34.602. Не то, чтобы это первое ТЗ по ГОСТ у меня, но такого трепетного отношения мы к нему еще не проявляли, к тому же со временем приходит все новое понимание старых вещей. Хорошо или плохо, но мы, естественно написали этот документ.
Из вопросов которые я мог бы осветить в потенциальной статье мне наиболее интересны следующие:
- Место концепции в ТЗ
- Место описания бизнес-процессов в ТЗ
- Место вариантов использования и других требований в ТЗ

Чуть менее интересно, по причине того, что это может быть очень по разному у всех
- Что мы писали в определеннных разделах (наше толкование ГОСТ)
- Последовательность разработки

Учитывая, что этим 3-м перечисленным пунктам в ТЗ не место - интересно )

...
- Место концепции в ТЗ
- Место описания бизнес-процессов в ТЗ
- Место вариантов использования и других требований в ТЗ
...
Ой ли?

Ой.
Если в проекте нужно работать по ГОСТам, то по ГОСТ 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'ы)!


Ещё простой пример логики - что такого технического в модели бизнес-процессов и концепции, чтобы засовывать их в документ под названием ТЕХНИЧЕСКОЕ задание? Да ничего.

На мой взгляд из западных стандартов и шаблонов ГОСТ 34.602 в наибольшей мере соответствует документу System Requirements Document/System Requirements Specification (SRD/SRS), описанному в IEEE Std 1233-1998 - Guide for Developing System Requirements Specifications, с некоторыми элементами System Architecture Document (SAD, разбиение на подсистемы).

В любом случае интересно почитать, что получилось. Заодно и покритиковать, если надо, а так же прийти к правильным выводам

Просто, к сожалению, ГОСТ уже слишком далеко от тех стандартов по которым де-факто принято описывать требования. Вот каждый и изголяется.

М.б. действительно сначала обсудим что где должно быть. А потом уж писать?

Насчет твоего утверждения есть возражения http://authorit.ru/?c=2, сам я, конечно, не фанат ГОСТ. НО может не так все печально как кажется, может мы не верно трактуем возможности ГОСТ?

Теперь посмотрим на группы обобщённых сценариев взаимодействия (aka варианты использования) - что они содержат? Описание взаимодействия пользователей и системы. Откуда эти сценарии берутся, от заказчика? Нет, они являются результатом ПРОЕКТИРОВАНИЯ ВЗАИМОДЕЙСТВИЯ, как работы по определению хода развёртывания взаимодействия реактивной функции (в отличие от трансформационной), затребованной от системы на этапе ТЗ. Т.е. это материал для стадий 4/5 по ГОСТ 34.601 - "Эскизный проект", "Технический проект".
Ещё простой пример логики - что такого технического в модели бизнес-процессов и концепции, чтобы засовывать их в документ под названием ТЕХНИЧЕСКОЕ задание? Да ничего.

То, что варианты использования являются исключительно продуктом проектной деятельности - сильное утверждение.
1. Если есть уже старая система, на смену которой создается новая, то часть сценариев взаимодействия неизбежно будет унаследована новой системой.
2. Системы и даже понятие системы возникли раньше, чем для управления этими системами стали применять программы. Поэтому когда все автоматизированные ныне виды деятельности автоматизировались впервые, то содержание автоматизированной деятельности (взаимодействие человека с "неавтоматизированной системой") получалась именно "от заказчика". И никак иначе. Проектировщик новой системы вносит в неё своё технологическое содержание, но обязательно на фундаменте содержания, полученного от заказчика системы.
3. То что в нашей стране многие представления о том как именно нужно "делать дело"  появляются вместе с программными продуктами никак не умаляет значимости тех системных решений, которые принимались при проектировании "неавтоматизированных" систем (например, автомобилей, самолетов, электростанций, городов). Многие такие ныне работающие системы унаследовали принципы их создания и функционирования, которые возникли до появления компьютера и пока еще не пересмотрены. История таких системных решений для автоматизируемой деятельности может быть очень полезна для понимания текущих проблем деятельности Заказчика, из-за чего он и затеял новый проект по автоматизации. Поэтому в разделе "Характеристика объекта автоматизации" ТЗ представляется вполне уместным описание деятельности заказчика как системы, рассматривая понятие "система" в данном случае существенно шире чем "компьютерная система".

Конечно, было бы интересно прочитать и услышать ваши комментарии по проекту.
Ждем-с...

skip...

Ой, Shur, как сказал. Прямо песня ....

Насчет ТЗ и use case есть забавный пример:
ТЗ на ИАС по социально-экономическому положению региона

ТЗ на ИАС юридических лиц региона

ну и там пошукайте. для ТЗ типа использовался шаблон МЭРТ

Ой, Shur, как сказал. Прямо песня ....

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

То, что варианты использования являются исключительно продуктом проектной деятельности - сильное утверждение.
1. Если есть уже старая система, на смену которой создается новая, то часть сценариев взаимодействия неизбежно будет унаследована новой системой.

Ну это какие-то частности, мы пока вроде о более фудаментальных вещах не договорились.

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

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

3. То что в нашей стране многие представления о том как именно нужно "делать дело"  появляются вместе с программными продуктами никак не умаляет значимости тех системных решений, которые принимались при проектировании "неавтоматизированных" систем (например, автомобилей, самолетов, электростанций, городов). Многие такие ныне работающие системы унаследовали принципы их создания и функционирования, которые возникли до появления компьютера и пока еще не пересмотрены. История таких системных решений для автоматизируемой деятельности может быть очень полезна для понимания текущих проблем деятельности Заказчика, из-за чего он и затеял новый проект по автоматизации. Поэтому в разделе "Характеристика объекта автоматизации" ТЗ представляется вполне уместным описание деятельности заказчика как системы, рассматривая понятие "система" в данном случае существенно шире чем "компьютерная система".

Если вы смотрели требования к содержанию раздела "Характеристика объекта автоматизации", то там достаточно поверхностные вещи отражаются. Я не понимаю, зачем в ТЗ тащить то, для чего есть отдельный документ и этап. Есть раздел "Описание существующей информационной системы", который я упоминал выше. Информационная система - естественно шире, чем компьютерная система.

Ведь ТЗ пишется на основе концепции, концепция пишется на основе результатов обследования и описания объекта автоматизации.

О БП и их размещении в техзадании.
Я часто наблюдаю картину, когда ошибочно ставят знак равенства м/у бизнес-процессами и их моделями и ТЗ. Мне кажется тут не обошлось без "этих мерзких ERP-ников" (прим. это шутливое высказывание). В SAP нет например понятия требований как таковых -- есть БП и техническая имплементация. Вобщем, в голове рядового разработчика софта в интересах крупных полугосударственных структур есть жуткая каша и непонимание места моделей бизнес-процессов и требований к системам. Да, я понимаю, что есть т.н. "функциональная архитектура" по AIM (тоже заметим, те же ERP-шники), более того даже в IEEE этот термин используется. Но тут нужно очень четко представлять ДЛЯ чего мы делаем модели бизнес-процессов. Если для оптимизации бизнеса, внедрения KPI -- это одно,  а если для ПОНИМАНИЯ как устроен бизнес, чтобы его автоматизировать - это другое. Хуже, когда стоит задача "оптимизации бизнеса через автоматизацию", или как нынче модно говорить, через информатизацию :-). Ибо при этом с одной стороны -- что может быть очевиднее -- преимущества автоматизации явные (ускорение, удешевление и т.п.). Но тут начинает возникать вопрос -- "автоматизация изменяет бизнес-процессы или нет???". На него можно ответить по-разному. Например, мы копали яму лопатой, приделали к ней мотор -- она стала копать сама и гораздо быстрее. Бизнес-процесс изменился? Ответ -- НЕТ, т.к. изменился только механизм (вспомним IDEF0), но не процесс. Да, он стал производительнее. Аналог, автоматизация документооборота ... раньше бегали ногами носили бумаги, регистрировали в журнале ... а теперь то же самое, только в компьютерах. Вопрос -- изменился бизнес-процесс???

В любом случае я согласен с Денисом, что в чистом виде описание БП не должно быть в ТЗ, тем более по ГОСТ 34. Т.к. эту работу нужно было делать еще на этапе формирования требований к АС, проводя соответствующий НИР по изучению процессов организации и выпуская отчет по НИР.

В любом случае я согласен с Денисом, что в чистом виде описание БП не должно быть в ТЗ, тем более по ГОСТ 34. Т.к. эту работу нужно было делать еще на этапе формирования требований к АС, проводя соответствующий НИР по изучению процессов организации и выпуская отчет по НИР.

Я тоже согласен, что моделирование БП не должно отражаться в ТЗ. Если посмотреть множество примеров вот здесь:http://projects.economy.gov.ru/pms/public/, то можно обнаружить, что бизнес-моделирование есть часть технического проекта.
Если обратится к RUP, то бизнес-моделирование происходит на стадии Развития, после формирования первой версии Концепции, важных прецедентов и спецификации дополнительных требований.

Ясно и то, что процесс в общем случае цикличен.

Так все-таки когда и кто делает бизнес-моделирование. Где место моделям бизнес-процессов?

Если посмотреть множество примеров вот здесь:http://projects.economy.gov.ru/pms/public/, то можно обнаружить, что бизнес-моделирование есть часть технического проекта.

Кроме того, если посмотреть множество примеров там, то можно увидеть много всякой чуши. А именно происходит путаница ГОСТовского технического проекта и консалтерского системного.

Если обратится к RUP, то бизнес-моделирование происходит на стадии Развития, после формирования первой версии Концепции, важных прецедентов и спецификации дополнительных требований.

Эд, с точностью до наоборот.

Так все-таки когда и кто делает бизнес-моделирование. Где место моделям бизнес-процессов?

В рамках ГОСТов - я уже сказал, в других методологиях надо обсуждать отдельно, хотя с RUP'ом всё понятно.