Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Сергей() от 20 Сентября 2017, 23:18:29
-
Здравствуйте!
В организации внедрена, и успешно используется система электронного документооборота.
Нам нужно добавить в эту систему еще один процесс - маршрут обработки нового вида электронного документа, который будет реализацией существующего в организации "бумажного" процесса.
Для этого нужно в системе ЭД разработать новый программный модуль, добавить новые настройки.
Но, чтобы все это заработало, надо не только разработать новый модуль с системе ЭД.
Нужно еще решить и ряд организационных задач:
- утвердить перечень справочных данных, которые нужны для заполнения нового вида электронного документа,
- создать и заполнить справочник из этих данных в системе ЭД,
- издать приказ по предприятию, в котором будет описана новая реализация бизнес-процесса в системе ЭД, и отменяется "бумажный" бизнес-процесс
- описать новые обязанности сотрудников по работе в системе ЭД в должностных или в отдельных инструкциях,
- обучить сотрудников.
Вот для всего этого мы пишем ТЗ.
Стараемся придерживаться ГОСТ-а.
Что правильно понимать под АС в данном случае?
Правильно ли под АС понимать не только новый программный модуль, но и все перечисленные "части": программный модуль + описание бизнес-процесса в приказе + должностные инструкции + обученные сотрудники?
В каком месте ТЗ, например, надо написать о должностных инструкциях?
В разделе "Компоненты системы"? Или инструкции - это один из видов обеспечения и писать о них надо в разделе "Виды обеспечения"?
Или в разделе "Функциональные подсистемы"?
Помогите, пожалуйста, разобраться.
-
Под АС понимается всё перечисленное и не перечисленное (например, железо).
Справочные данные - информационное обеспечение.
Обязанности сотрудников - организационное обеспечение.
Методы работы сотрудников - методическое обеспечение.
Вот только зачем вам всё это...
-
Вот только зачем вам всё это...
Ну как зачем?
Нам нужно все это внедрить.
Значит, в плане работ надо предусмотреть создание инструкций, заполнение справочников.
Это же конкретные работы, хоть и не связанные напрямую с разработкой программной системы.
Часть этих работ будет выполнять Заказчик, другую часть - Исполнитель.
А почему вы думаете, что это не нужно?
Справочные данные - информационное обеспечение.
Обязанности сотрудников - организационное обеспечение.
Методы работы сотрудников - методическое обеспечение.
А что тогда в нашем случае будет являться "подсистемами" и "компонентами" системы?
"Подсистемы" и "Компоненты" - это синонимы?
Или это разные сущности?
-
Попробуйте посмотреть ГОСТ 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]
-
И еще о точных терминах.
Должностные инструкции не являются частью системы и не относятся к системе.
Это документы организации, в которых указываются обязанности СОТРУДНИКА. Не надо пытаться использовать для них 34 серию ГОСТ.
В лучшем случае в них может быть ссылка на инструкции к тому ПО, которым сотрудник должен пользоваться при выполнении своих должностных обязанностей. А можно ограничиться формулировкой, избегая указывать наименования (коды) документов-инструкций, ограничившись наименованием ПО. Под этим ПО может быть как обычное офисное, так и то, что является одной из компонент конкретной АС.
Для системы должны предусматриваться инструкция ПОЛЬЗОВАТЕЛЯ, администратора, системного программиста.
Разницу понимаете? Пользователь - это роль. Разные сотрудники могут авторизоваться в системе с одной и той же ролью пользователя, при этом они могут быть сотрудниками с разными окладами, из разных подразделений и у них, соответственно, будут разные должностные обязанности.
При том подходе, методология которого предлагается 34 ГОСТом, и который Сергей() проявил желание соблюсти, вполне можно подготовить необходимый набор документов/материалов (которые великолепно описывают все необходимые аспекты). Важно их грамотно "вплести" в деятельность предприятия (в составе приказов, пользователских инструкций и др. организационно-распорядительный и методических документов), чтобы обеспечить эффективное использование системы.
-
34.602 Можно писать чтобы тендеры выигрывать, а можно, чтобы работало.
Если, чтоб работало, то в ТЗ я бы записал требование к должностным инструкциям. Что они должны быть созданы в рамках проекта. Перечислить какие инструкции должны быть и т.д. (желательно).
-
Деление по видам обеспечения, по подсистемам и компонентам не следует смешивать.
Да, я это понимаю, что это разные вещи. Поэтому-то и поднял этот вопрос.
Кстати, термина "подсистема" в ГОСТ 34.003-90 не определено ))
Зато есть понятие "Функциональная подсистема АСУ "(ФП АСУ) по ГОСТ 24.701-86
Значит, скорее всего когда упоминается «подсистема», имеется ввиду именно «функциональная подсистема».
То есть получается так.
Обеспечение – это все, из чего состоит система, конкретные элементы системы.
Подсистема (функциональная подсистема) – это совокупность элементов АСУ (конкретных элементов обеспечения), которые выполняют конкретную функцию системы, то есть выделенных по функциональному признаку.
Компонент – это совокупность элементов АСУ (конкретных элементов обеспечения), объединенных по любому другому не-функциональному признаку.
Согласны?
Должностные инструкции не являются частью системы и не относятся к системе. Это документы организации, в которых указываются обязанности СОТРУДНИКА. Не надо пытаться использовать для них 34 серию ГОСТ.
В лучшем случае в них может быть ссылка на инструкции к тому ПО, которым сотрудник должен пользоваться при выполнении своих должностных обязанностей…
Мы в них пропишем ссылку на «Порядок выполнения бизнес-процесса ХХХ».
Вот этот порядок наверно будет частью системы?
Разницу понимаете? Пользователь - это роль. Разные сотрудники могут авторизоваться в системе с одной и той же ролью пользователя, при этом они могут быть сотрудниками с разными…
Да, это понятно.
При том подходе, методология которого предлагается 34 ГОСТом, и который Сергей() проявил желание соблюсти, вполне можно подготовить необходимый набор документов/материалов (которые великолепно описывают все необходимые аспекты).
Вы меня правильно поняли.
Поэтому мы и решили использовать стандарт, потому что вряд ли бы мы сами придумали другой метод описать все важные моменты.
Если, чтоб работало, то в ТЗ я бы записал требование к должностным инструкциям. Что они должны быть созданы в рамках проекта. Перечислить какие инструкции должны быть и т.д. (желательно).
Да, так мы и задумывали.
Чтобы наша АС работала, эти инструкции должны быть.
Вернее, сами инструкции уже есть.
Мы впишем в ТЗ требование, что в них нужно внести изменения, необходимые для работы нашей АС.
Как я писал выше, мы в инструкции вставим ссылку на "Порядок выполнения бизнес-процесса ХХХ".
После изменения должностных инструкций, придется повторно ознакомить с ними сотрудников.
-
Обеспечение – это все, из чего состоит система, конкретные элементы системы.
Не так. АС не состоит из видов обеспечения. Каждый из видов обеспечения отражает, как систему можно описать с перечисленных позиций: какая математика там должна быть реализована вообще, какая информация и в каком виде должна обрабатываться (храниться, передаваться, отображаться), какие правоотношения и как следует отрегулировать в связи с функционированием, и т.д. по всем другим видам обеспечения.
Предложу такую аналогию. Вы строите систему, разрабатываете ТЗ. Вы в общем знаете ее назначение и функционал и приблизительно как она будет работать. У вас в команде есть спец по каждому виду обеспечения - математик, юрист, спец по базам данных, программист, руководитель подразделения, которое будет ее использовать, дизайнер-"эргономист", и т.д. Каждый из них, допустим, сперва для ТЗ разрабатывает требования в своей части. Ну а потом, допустим, формирует соответствующие решения.
Ещё раз: виды обеспечения - это не структура, это точки зрения.
-
Не так. АС не состоит из видов обеспечения.
А я не говорил про "виды обеспечения".
Раз есть виды, значит есть конкретные элементы, которые можно по определенному признаку разделить на эти виды.
Вот про эти конкретные элементы АС я и говорил в определении "обеспечения".
То есть я имел ввиду, что (повторю свое определение):
обеспечение - это конкретные элементы системы, их совокупность.
Каждый из видов обеспечения отражает, как систему можно описать с перечисленных позиций: какая математика ... какая информация ...
Ещё раз: виды обеспечения - это не структура, это точки зрения.
Согласен.
Виды обеспечения - это "группировка" конкретных элементов системы с определенной точки зрения.
Так будет правильно?
-
Не уверен, что следует подходить через "группировку" элементов по видам.
Главное, что следует учитывать (и, надеюсь, удалось довести) - что описание по каждому их видов обеспечения и описание структуры системы (по функциональным подсистемам) - это разные подходы, формирующие вместе несколько моделей системы. Совокупность всех этих моделей наиболее полно описывает необходимую систему.
Как в будущей работе по созданию (развитию) вы сможете использовать эти модели (или создавать дополнительные) - это уже воля автора и самая интересная часть работы.
Практика дальше вам поможет ;)
-
Вот ещё статья Михаила Острогорского, простым языком о компонентах, подсистемах и видах обеспечения.
http://philosoft-services.com/gost34asconcept.zhtml (http://philosoft-services.com/gost34asconcept.zhtml)