ГОСТы на автоматизированные системы
Коротко ГОСТ — государственный стандарт. Многие ГОСТы появились ещё в Советском Союзе и до сих пор действуют в России и ряде других стран СНГ. На ИТ-проектах для государственного сектора и крупных предприятий от вас могут потребовать техническое задание «по ГОСТ 34». На этой странице — три стандарта, которые называют чаще всего, и их связь с документом «Видение» и SRS.
По материалам: Ю. А. Маглинец, «Анализ требований к информационным системам», лекции 4 и 6; ГОСТ 34.601-90; ГОСТ 34.602-89; ГОСТ 19.201-78.
На этой странице
Главные идеи#
Что такое ГОСТ 34 и ГОСТ 19#
Аналитику важны две серии стандартов:
- ГОСТ 34 — «Комплекс стандартов на автоматизированные системы». В этих стандартах автоматизированная система (АС) включает не только технические и программные средства, но и персонал, который с ней работает, поэтому стандарты охватывают людей и организацию, а не только код.
- ГОСТ 19 — более старая серия стандартов на программную документацию, Единая система программной документации (ЕСПД).
Встречаются они на проектах для государственных органов, крупных и государственных предприятий России и других стран СНГ, где на них ссылаются договоры и правила закупок. В курсе Маглинца (2007) ГОСТ 34.602-89 описан как по-прежнему обязательный для государственных контрактов в России. Стандарты время от времени пересматривают, поэтому всегда проверяйте, какой именно стандарт и в какой редакции указан в вашем договоре.
ГОСТ 19.201-78: общий стандарт на техническое задание#
Этот более ранний стандарт устанавливает содержание и оформление технического задания (ТЗ) на разработку программы. Маглинец описывает ГОСТ 34.602-89 как более подробный вариант той же идеи, приспособленный к автоматизированным системам.
ГОСТ 34.601-90: стадии создания и концепция с вариантами#
Этот стандарт определяет стадии создания автоматизированной системы. После стадии «Формирование требований к АС» в нём предусмотрена отдельная стадия «Разработка концепции АС». Её этапы: изучение объекта; проведение необходимых научно-исследовательских работ; разработка вариантов концепции АС; оформление отчёта о выполненной работе.
Отличительная черта — концепция должна предлагать несколько вариантов. Каждый вариант оценивают по нужным ресурсам и обеспечиваемой функциональности, с его преимуществами и недостатками. Концепция также содержит оценки качества, условия приёмки и ожидаемый эффект, а отчёт обосновывает рекомендуемый вариант. Маглинец объясняет логику: заказчику трудно придумать видение системы с нуля, но выбрать из обоснованных вариантов он может хорошо. Большинство западных методологий, например RUP и MSF, вместо этого дают единственный документ о видении системы.
ГОСТ 34.602-89: техническое задание на создание автоматизированной системы#
ТЗ на АС состоит из девяти основных разделов; ниже — их краткое содержание:
- «Общие сведения»: стороны, их реквизиты и финансирование.
- «Назначение и цели создания (развития) системы»: какие показатели объекта автоматизации должна улучшить система и по каким критериям будут оценивать достижение целей. Маглинец отмечает, что к этому разделу часто относятся формально, хотя именно в нём место бизнес-требованиям.
- «Характеристика объектов автоматизации»: организационная структура и структура управления, площадки и филиалы.
- «Требования к системе» (см. ниже).
- «Состав и содержание работ по созданию системы»: методология, стадии и этапы.
- «Порядок контроля и приёмки системы»: роли заказчика и разработчика в испытаниях, сценарии испытаний, критерии приёмки.
- «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»: подбор персонала, обучение и организационные изменения, которые нужны до запуска.
- «Требования к документированию».
- «Источники разработки»: имеющиеся документы, на которые опирается работа.
В приложения можно включить расчёт ожидаемой эффективности системы и оценку научно-технического уровня системы.
Три класса требований#
Раздел 4 делит требования на три класса:
- Требования к системе в целом: к структуре и режимам функционирования, к численности и квалификации персонала, к надёжности, безопасности, эргономике и технической эстетике, к эксплуатации и техническому обслуживанию, к защите информации от несанкционированного доступа, по сохранности информации при авариях, к защите от влияния внешних воздействий, к патентной чистоте, по стандартизации.
- Требования к функциям (задачам), выполняемым системой: перечень функций в привязке к подсистемам и очередям создания системы, временной регламент, требования к качеству реализации каждой функции (форма представления выходной информации, точность, время выполнения, достоверность выдачи результатов), перечень и критерии отказов.
- Требования к видам обеспечения: математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному и методическому.
Соответствие западным документам#
| Раздел ГОСТ 34.602-89 | Ближайший западный аналог |
|---|---|
| 2. Назначение и цели создания (развития) системы | Бизнес-цели и метрики успеха в документе «Видение» или в документе концепции и границ |
| 3. Характеристика объектов автоматизации | Бизнес-контекст, профили заинтересованных сторон, текущее состояние |
| 4. Требования к системе в целом | Атрибуты качества и ограничения в SRS |
| 4. Требования к функциям (задачам) | Функциональные требования или варианты использования |
| 4. Требования к видам обеспечения | Отчасти ограничения на проектные решения; отчасти прямого аналога нет |
| 6. Порядок контроля и приёмки системы | Критерии приёмки и план тестирования, обычно вне SRS |
| 7. Подготовка объекта автоматизации к вводу системы в действие | Переходные требования |
По оценке Маглинца, стандарт остаётся содержательно здравым, потому что не привязан к технологиям, и добавляет то, чего нет в SRS и документе «Видение»: явную приёмку, подготовку организации и виды обеспечения.
Как применять#
- Уточните требование. Проверьте, какие стандарты и в какой редакции названы в договоре и есть ли у заказчика собственный шаблон.
- Отнеситесь к разделу 2 всерьёз. Запишите в нём измеримые бизнес-цели и критерии успеха.
- Используйте результаты своего анализа. Контекст и заинтересованные стороны идут в раздел 3, функциональные требования — в требования к функциям (задачам) раздела 4 (по подсистемам), атрибуты качества — в требования к системе в целом.
- Задайте для каждой функции требования к качеству и критерии отказов, а не только название.
- Договоритесь о приёмке заранее. Подготовьте раздел 6 вместе с заказчиком: от него зависит, когда работа считается выполненной.
- Спланируйте организационные изменения в разделе 7. Обучение и персонал по ГОСТ — часть системы.
- На стадии концепции подготовьте два-три варианта и обоснованно рекомендуйте один. Эта привычка полезна и за пределами проектов по ГОСТ.
Подводные камни#
- Разделы, заполненные общими словами. Каждый раздел должен отвечать на свой вопрос применительно к этому проекту.
- Система — это только ПО. ГОСТ считает частью системы людей, процедуры и виды обеспечения.
Источники и что почитать#
- Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекция 4 (стадия разработки концепции по ГОСТ 34.601-90) и лекция 6 (ГОСТ 34.602-89 и ГОСТ 19.201-78).
- ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания».
- ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».
- ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».