Добрый день.

У меня возник вопрос, связанный с ГОСТ 34.601 и его представлении в виде деятельностей. На лабе по моделированию последним заданием в качестве повторения/забивания в голову стадий и этапов разработки АС было предложено замоделировать этот самый гост

1-й уровень - стадии, 2-ой - этапы, 3-й (swimlanes) - содержание работ.

Вопрос как раз-таки по swimlane'ам. Там мне нужно отобразить на 3-х колоннах (вх/вых эл, деят, роли) каждый этап по содержанию. Как быть с документами (вх/вых элементы)? Смотрел РД-50, там в приложении есть по предпроектным стадиям куски, но они результирующие всю стадию. Т.е., например, непонятно что должно входить в деятельность Сбор данных об объекте автоматизации и что должно выходить

Как быть и что можете посоветовать? Заранее спасибо.

Вход - в общем понимании регулирующая среда.
В частности устав, например.

Выход: назовите, например, отчет об обследовании.

По "Формирование требований пользователя к АС"  -  думаю вход это анкеты, выход - описание требований

А в целом -  раз это "лаба" , то думаю подробностей не надо.

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

Во вложении пример (больше по выходным документам). Но выход на предыдущем  - это вход на следующем.

Это-то понятно. Другое дело, что желательно бы детально порасписывать

Эскизно содержание этапа 1 (Обследование объекта и обоснование необходимости создания АС) по ГОСТу (3-й уровень) представлено на скрине в приложении. Прошу сильно не бить, если чего там не туда

Я так понимаю, что в реальной жизни происходит так: проходит процесс анкетирования/интервьюирования и т.д. посредством соответсвенно анкет и т.п. А может и не так. И вот не понятно, когда же в отчёт всё пакуют, т.е. после каждого действия я вставляю на диаграмму отчёт (см. рисунок), но уже с другим статусом или нет?

Или же просто формально обзывать объекты каким-нибудь, например, набором данных об объекте автоматизации да и всё???

Золотухина рулит (

И вот не понятно, когда же в отчёт всё пакуют

Когда удобно тогда и пакуют.

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

И еще - Вы же это (диаграммы) не ко всем проектам хотите применять, как универсальное средство?
В реальности все равно будет для каждого свое.

Для целей закрепления можно писать формально -

набором данных об объекте автоматизации

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

Золотухина рулит (

Е.Б. Золотухину узнают по Интерпрайзу?

И еще вопрос - А почему роль - это ответственный за формирование требований а АС?

Нет, роли чуть позже.

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

pha,

Золотухину узнают по кривой форме описания Д Действий ....
А почему нормально нельзя описать в нотации UML или BPMN? Дорожки - это роли, а объекты (документы) стоят на переходе от действия к действию, как здесь в последнем абзаце:
http://www.sparxsystems.com.au/resources/uml2_tutorial/uml2_activitydiagram.html

Никто не запрещает пользоваться и старым ГОСТ 24.602-86
Надо только содержание работ переделать на документы.
Например "Сбор и анализ данных об организационной и производственной структуре объекта управления" - документ "Организационная структура".

Но в целом это достаточно сложный и спорный  вопрос - привязать ко всем пунктам ГОСТа 34.601-90 - документы.

Есть ряд статей , но это уже вглубь. Да и на сайте были обсуждения данной тематики.
Методические подходы в обследовании объектов автоматизации

План внедрения: новое и забытое старое
Выводы из статьи (план внедрения...):
Недостатки стандарта:

    * ГОСТ ТЗ 34.601-90 не ориентирован на конкретный вид программного продукта. В нем не учтены особенности внедрения комплексных систем автоматизации предприятия (особенно – в области обучения персонала и управления данными). Многие понятия определяются слишком широко.
    * ГОСТ содержит рудименты “планово-социалистического” подхода к управлению предприятием. Нулевой этап внедрения плохо проработан. Отсутствует этап предварительной переподготовки. Неубедительно и непоследовательно сформулированы процессы Выработка целей и ТЭО.

Стандарт имеет и ряд достоинств. В частности, хорошо проработана технологическая цепочка: Обследование – Техническое задание – Технический проект и Опытный Пример – Получение результата – Анализ текущего состояния. Это универсальные элементы внедрения, необходимые для автоматизации во всех областях деятельности.

ГОСТ – открытый, публично доступный стандарт внедрения. Несмотря на все недостатки, он превосходит по качеству многие “уникальные” и “эксклюзивные” методики.
 

bas,
а что будет, если роль одна? На пересечение чего с чем будем ставить документ?

bas,
а что будет, если роль одна? На пересечение чего с чем будем ставить документ?

На пересечении действий: из одного действия выходит стрелка идет в объект (документ), из объекта выходит и идет в другое действие.

Ясно. Правда разницы я особо не вижу с тем, как сделано выше Ибо если я делаю диаграмму для более чем 1-го актёра, то тогда тяну объекты на пересечение колонок (и это понятно, потому что колонки соответствуют ролям). А так (если один актёр в рамках содержания работы по этапу ГОСТа) - это просто гигантский, выпадающий вниз набор действий и объектов вперемешку. Может быть я чего-то не понимаю  . Тем не менее это пока не самый принципиальный вопрос для меня.

Я бы вообще смоделировал поток работ с помощью IDEF0 - строго всё и формально: вход, выход, управление, механизм. Нечто подобное я делал в дипломном проекте.

Я бы вообще смоделировал поток работ с помощью IDEF0 - строго всё и формально: вход, выход, управление, механизм. Нечто подобное я делал в дипломном проекте.

Для потока работ имеется другая нотация IDEF3. IDEF0 все-таки показывает иерархию функций (активностей) + горизонтальные связи на каждом иерархическом уровне

Правда разницы я особо не вижу с тем, как сделано выше

А если нет разницы, то тем более нужно делать по ГОСТу в соответствии с нотацией.

А так (если один актёр в рамках содержания работы по этапу ГОСТа) - это просто гигантский, выпадающий вниз набор действий и объектов вперемешку. Может быть я чего-то не понимаю  .

Видимо да ) Объекты можно располагать чуть левее/правее от действий и разницы вообще нет, зато действий с Д нужно делать меньше и она сразу понятна.