Здравствуйте!

В организации внедрена, и успешно используется система электронного документооборота.
Нам нужно добавить в эту систему еще один процесс - маршрут обработки нового вида электронного документа, который будет реализацией существующего в организации "бумажного" процесса.
Для этого нужно в системе ЭД разработать новый программный модуль, добавить новые настройки.

Но, чтобы все это заработало, надо не только разработать новый модуль с системе ЭД.
Нужно еще решить и ряд организационных задач:
- утвердить перечень справочных данных, которые нужны для заполнения нового вида электронного документа,
- создать и заполнить справочник из этих данных в системе ЭД,
- издать приказ по предприятию, в котором будет описана новая реализация бизнес-процесса в системе ЭД, и отменяется "бумажный" бизнес-процесс
- описать новые обязанности сотрудников по работе в системе ЭД в должностных или в отдельных инструкциях,
- обучить сотрудников.

Вот для всего этого мы пишем ТЗ.
Стараемся придерживаться ГОСТ-а.

Что правильно понимать под АС в данном случае?
Правильно ли под АС понимать не только новый программный модуль, но и все перечисленные "части": программный модуль + описание бизнес-процесса в приказе + должностные инструкции + обученные сотрудники?
В каком месте ТЗ, например, надо написать о должностных инструкциях?
В разделе "Компоненты системы"? Или инструкции - это один из видов обеспечения и писать о них надо в разделе "Виды обеспечения"?
Или в разделе "Функциональные подсистемы"?

Помогите, пожалуйста, разобраться.

Под АС понимается всё перечисленное и не перечисленное (например, железо).

Справочные данные - информационное обеспечение.
Обязанности сотрудников - организационное обеспечение.
Методы работы сотрудников - методическое обеспечение.

Вот только зачем вам всё это...

Вот только зачем вам всё это...

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

А почему вы думаете, что это не нужно?

Справочные данные - информационное обеспечение.
Обязанности сотрудников - организационное обеспечение.
Методы работы сотрудников - методическое обеспечение.

А что тогда в нашем случае будет являться "подсистемами" и "компонентами" системы?

"Подсистемы" и "Компоненты" - это синонимы?
Или это разные сущности?

Попробуйте посмотреть ГОСТ 19, если Вам так важно делать по какому-то стандарту. Если нет, почему- бы Вам не разработать собственный шаблон документа и не использовать его. В конце концов, Вам же нужно внедрить и довести до всех это внедрение. Почему бы не организовать такую документацию на wiki?

Можно вообще реализовать в каком-то инструменте типа ЕА модель БП и "навешать" на каждое действие и совокупность действий инструкции по внедрению и использованию.

Попробуйте посмотреть ГОСТ 19...

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

...если Вам так важно делать по какому-то стандарту. Если нет, почему- бы Вам не разработать собственный шаблон документа и не использовать его.

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

В стандарте уже закреплена определенная логика изложения всей информации, связанной с разработкой АС.
Предполагаем, что такая логика была принята не спроста, видимо она действительно удобна и способствует более быстрому понимаю ТЗ.
Кроме того, есть вероятность что с каким-то конкретным стандартом могут быть знакомы большинство участников проекта, что также способствует более лучшему понимаю.
Если мы начнем изобретать свой шаблон, придется придумывать свою логику изложения материала.
Вряд ли наша придуманная логика будет лучше той, что в каком-то конкретном стандарте.

В нашем случае мы взяли за основу ГОСТ 34.
Есть ли другие стандарты более удобные для ТЗ на АС?
Если да, то какие и почему?

В конце концов, Вам же нужно внедрить и довести до всех это внедрение. Почему бы не организовать такую документацию на wiki?

Согласен, документацию можно сделать и в вики.
Но все равно эта документация должна быть как-то структурирована.
То есть на первом месте стоит не вопрос в каком виде и в какой форме делать документацию (в ворде или в вики), а вопрос - как она должна быть структурирована.

Мне кажется, мой вопрос к этому относится: выделенные артефакты (инструкции, справочники) к каким частям системы относятся: к подсистемам, компонентам, обеспечению?
И почему?

Можно вообще реализовать в каком-то инструменте типа ЕА модель БП и "навешать" на каждое действие и совокупность действий инструкции по внедрению и использованию.

Модель БП уже начали делать.

Если система, то лучше ГОСТ 34. ГОСТ не регламентирует состав документа, а рекомендует. Так что пункты там могут быть любые. Правда госзаказчики об этом не знают, так как ГОСТ-ы не читали.
Другие способы и более хорошие есть. Мне нравится модель Щедровицкого, но это мне.

Для описания процесса опишите:
* Продукт (Выход)
* Материал (Вход)
* Средства преобразования
* Порядок преобразования
* Нормы деятельности
* Навыки персонала

PS. Как раз сейчас я тренинг по описанию процессов веду...

Другие способы и более хорошие есть

Скажите, пожалуйста, какие?
Очень интересно.

Мне нравится модель Щедровицкого, но это мне.

Что-то я читал Щедровицкого, кажется по деятельности и логике.
А какую его работу вы рекомендуете почитать для написания ТЗ?

Если система, то лучше ГОСТ 34. ГОСТ не регламентирует состав документа, а рекомендует. Так что пункты там могут быть любые.

Это я понимаю.
Но, все-таки хотелось бы определиться именно с подсистемами, компонентами и обеспечением.
В чем особенности этих понятий по отношению к системе в целом?

Для описания процесса опишите:
* Продукт (Выход)
* Материал (Вход)
* Средства преобразования
* Порядок преобразования
* Нормы деятельности
* Навыки персонала

PS. Как раз сейчас я тренинг по описанию процессов веду...

Спасибо за совет, обязательно добавлю эти пункты в ТЗ.
На тренинг я никак не смогу попасть, я в регионе живу.
Если сложится, возможно с 7 по 20 октября поеду в Москву в командировку.

То есть на первом месте стоит не вопрос в каком виде и в какой форме делать документацию (в ворде или в вики), а вопрос - как она должна быть структурирована.

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

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

В организации внедрена, и успешно используется система электронного документооборота.
Нам нужно добавить в эту систему еще один процесс - маршрут обработки нового вида электронного документа, который будет реализацией существующего в организации "бумажного" процесса.
Для этого нужно в системе ЭД разработать новый программный модуль, добавить новые настройки.

Вы пишите - разработать программный модуль - почему 19 гост не подходит? Насколько я вижу - это расширение существующих возможностей. Другое дело, если под программный модулем Вы тут понимаете разработки различных частей системы: клиентской и серверной как минимум.

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

Структура уже есть, ее не надо изобретать.

Мой вопрос в другом.
Должностные инструкции - это часть создаваемой системы.
Согласно ГОСТ-34 в системе выделяются разные "виды" частей: подсистемы, компоненты. А также обеспечение.
Вопрос в следующем: инструкции - это компонент системы? или обеспечение? или подсистема? и почему?
Просто для себя хочется это понять.

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

Правильно, сначала нужно зафиксировать результат реализации.
Точнее планируемый результат, то есть модель будущей АС.
Правильно я понял?
Конечно дальше для фиксации результата кроме ТЗ нужны будут и другие документы.
Сейчас пока возник вопрос по ТЗ.

Вы пишите - разработать программный модуль - почему 19 гост не подходит?

Сейчас пока мы описываем систему в целом. Для этого выбрали ГОСТ-34.
Потом когда дойдем до более детального ТЗ для программного модуля, тогда мы можем воспользоваться ГОСТ-19.
Но сейчас пока вопрос более узкий: "инструкции - это компонент системы? или обеспечение? или подсистема? и почему?"

Но сейчас пока вопрос более узкий: "инструкции - это компонент системы? или обеспечение? или подсистема? и почему?"

Есть прекрасный справочник по определениям ГОСТ.

http://tdocs.su/8473

Компонент автоматизированной системы (АС) (Automated system component) по ГОСТ 34.003-90
Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое

Прекрасен он, в частности, тем, что эти определения практически бесполезны, так как допускают разнообразные толкования.

Насколько я знаю сложившуюся практику, компонентами АС принято называть составляющие программного и технического обеспечения. Документация - составная часть АС сама по себе. А требования к тому, что должно содержаться в документации, размываются по разным разделам ТЗ, как я тут уже писал - в частности, в требованиях к методическому и организационному обеспечению. А на состав и содержание документации есть отдельные стандарты:

http://www.rugost.com/index.php?option=com_content&view=article&id=91:34201-89&catid=22&Itemid=53
http://www.rugost.com/index.php?option=com_content&view=article&id=98:50-34698-90&catid=22&Itemid=53

ГОСТы - это такое болото: чем дальше лезешь, тем больше вязнешь.

Есть прекрасный справочник по определениям ГОСТ.
...
Прекрасен он, в частности, тем, что эти определения практически бесполезны, так как допускают разнообразные толкования.

Вы очень точно сказали!
Вот именно после прочтения этих определений, я и создал данную тему.
Так как по этим определениям я так и не смог понять: чем же являются упомянутые должностные инструкции - компонентом, подсистемой или обеспечением АС.

1. В вашем случае вы планируете дорабатывать существующую СЭД для обеспечения автоматизации определенной деятельности - бизнес-процесса, реализующего "маршрут" документа. На языке ГОСТа это называется развитие АС . Развитие состоит в расширении функционала АС - т.е. реализации новой функции (см. ГОСТ 34.003).
2. АС в числе прочих компонент включает персонал - как пользователей, так и эксплуатационный (т.е. тех, кто обеспечивает функционирование).
Материал, являющийся контентом пользовательских инструкций (или должностными в вашем конкретном случае) относится к методическому (иногда к организационному) обеспечению АС.

И к термину: Автоматизированная система (АС) - система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций [из п. 1.1 ГОСТ 34.003-90].
Дополнительно: документация также входит в состав АС.

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

Чисто на интуитивном уровне это понятно.

Но вот что значит "обеспечивает функционирование"?
Где граница между самим "функционированием" и "обеспечением функционирования"?
По каким признакам разделить - это подсистема, это компонент системы, а это обеспечение системы?

* пользователи системы - все те, кто ПОЛЬзуются ей (непосредственно взаимодействует с системой через ее интерфейсы , человек (оператор) - чаще всего визуально - через графический интерфейс) или результатами ее работы (разного рода руководители, которые сами могут не сидеть за монитором и которым приносят распечатки или др. материалы из выходных данных)
* обеспечивают функционирование все те, кто ОБЕСПЕЧИВАЮТ ее работоспособность - системный администратор, системный программист, электрик, кто фильтры на блоках питания серверов меняет и т.д.

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

Деление по видам обеспечения, по подсистемам и компонентам не следует смешивать.
Компонент - часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое [из п. 2.13 ГОСТ 34.003-90].
В числе компонентов в указанном ГОСТ перечислены все виды обеспечения (помимо персонала, КСА, инф. баз, изделий,  ПТК).
Будет проще понять виды обеспечения, если не пытаться найти их на функциональной структуре конкретной АС, а рассматривать как аспекты, с точки зрения которых следует описывать АС. То есть дополнительный уровень декомпозиции АС, логический. Они определяют специфическую модель обеспечения АС.
Структурно в составе АС можно выделить подсистемы, каждую из которых, в свою очередь, можно рассматривать с точки зрения все тех же видов обеспечения.
Допускаю, если в составе конкретной системы можно определить некий признак (или несколько), по которому в составе системы можно выделить различные элементы, то таким образом систему можно будет декомпозировать иным способом на соответствующие компоненты, и это не будет противоречить ГОСТу.

P.S.
Кстати, термина "подсистема" в ГОСТ 34.003-90 не определено ))
Зато есть понятие "Функциональная подсистема АСУ "(ФП АСУ) по ГОСТ 24.701-86
Функциональная подсистема АСУ "(ФП АСУ) - Подсистема АСУ, выделенная по функциональному признаку и представляющая собой совокупность элементов АСУ (технических, программных, эргатических), участвующих в выполнении некоторой функции системы [из п. 7 Таблицы Приложения 1 ГОСТ 24.701-86]

При этом АСУ или любую ее функциональную подсистему рассматривают как состоящую из трех основных компонентов (групп однородных элементов) - комплекса технических средств (КТС), программного обеспечения (ПО), персонала [из п. 3 Таблицы Приложения 1 ГОСТ 24.701-86]