НАЗАД

ГОСТ 34.601-90. Управление ИТ проектом

ГОСТ 34.601-90 и Управление проектом в ИТ области для разработка программного обеспечения и системной интеграции.

В данной статье будет рассмотрен ГОСТ 34.601-90 «Стадии создания автоматизированных систем» и каким образом данный ГОСТ может быть полезен для управления проектом. Под проектом в нашем случае понимается так называемый «западный» термин, т.е. проект – это временное предприятие (деятельность), предназначенная для создания уникальных продуктов, услуг или результатов.
Сейчас практически любая деятельность в области ИТ (системная интеграция, разработка программного обеспечения, информационная безопасность и т.д.) реализуют проектным методом. Иными словами, каждая деятельность от подготовки контракта, внедрения и разработки автоматизированной системы и вывода автоматизированной системы из эксплуатации – может рассматриваться как часть проектное деятельностью или быть выделенной, в зависимости от ситуации, в отдельный проект.
В СССР, для разработки автоматизированных систем были созданы государственные стандарты, которые определяли стадии и последовательность работ. На данный момент в РФ, в некоторых организациях, особенно с большим участием государства, придерживаются методологий и требований, определенных в ГОСТах.
В частности, в ГОСТ 34.601-90 очень хорошо и подробно описаны стадии и работы по созданию автоматизированной системы. Но возникает вопрос, насколько актуален настоящий стандарт и к каким проектам он подходит.
В процессе разработки автоматизированной системы, документом РД-50.698-90 предусматривается разработка 64 документов!!! Это довольно многовато и трудоемко. Многие из документов на данный момент потеряли актуальность. Например, документ описывающий структуру базы данных. Данный документ не важен конечному потребителю, особенно, если устанавливается готовое программное обеспечение и выполняется его настройка. Потребителю важен функционал программного обеспечения.
Сначала предлагаю рассмотреть стандарт 34.601-90, а именно стадии и работы (см. таблицу ниже).


Стадии и этапы создания АС по ГОСТ 34.601-90 приведены в таблице ниже
Стадии Этапы работ
1. Формирование требований к АС 1.1. Обследование объекта и обоснование необходимости создания АС.
1.2. Формирование требований пользователя к АС.
1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС. 2.1. Изучение объекта.
2.2. Проведение необходимых научно-исследовательских работ.
2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя.
2.4. Оформление отчёта о выполненной работе.
3. Техническое задание. 3. Разработка и утверждение технического задания на создание АС.
4. Эскизный проект. 4.1. Разработка предварительных проектных решений по системе и её частям.
4.2. Разработка документации на АС и её части.
5. Технический проект. 5.1. Разработка проектных решений по системе и её частям.
5.2. Разработка документации на АС и её части.
5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку.
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.
6. Рабочая документация. 6.1. Разработка рабочей документации на систему и её части.
6.2. Разработка или адаптация программ.
7. Ввод в действие. 7.1. Подготовка объекта автоматизации к вводу АС в действие.
7.2. Подготовка персонала.
7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).
7.4. Строительно-монтажные работы.
7.5. Пусконаладочные работы.
7.6. Проведение предварительных испытаний.
7.7. Проведение опытной эксплуатации.
7.8. Проведение приёмочных испытаний.
8. Сопровождение АС 8.1. Выполнение работ в соответствии с гарантийными обязательствами.
8.2. Послегарантийное обслуживание.

Из таблицы видно, что настоящий стандарт был разработан для выполнения работ последовательно, от стадии к стадии – так называемый «водопад». Методика «водопад», на мой взгляд подходит для системной интеграции, для всех, практически, проектов внедрения готовых программных продуктов. Для такого проекта довольно просто построить сетевой график работ и рассчитать сроки и трудозатраты. Это просто, потому что мы можем определить длительности каждой операции (поставка, установка оборудования или настройка программного обеспечения по соответствующим требованиям).
Если говорить о разработке программного обеспечения или заказной разработке программного обеспечения, то там все гораздо сложнее (об этом в следующей статье). Сейчас хотелось бы отметить, что разработка программного обеспечения коренным образом отличается от интеграционных проектов и работ по внедрению системы, состоящей из готовых компонентов. Самое главное отличие – это то, что Заказчик до самого конца не знает, что же он все-таки хочет. В начале, Заказчик имеет некое представление о том, что он хочет, но когда видит готовый продукт, его понимание задачи может очень сильно меняться. Поэтому разработку программного обеспечения невозможно выполнить по методике «Водопад» (В общем случае: ТЗ -> ПЗ -> ПМИ -> Программирование -> Развертывание -> Сопровождение). Здесь возможна работа только итерационным методом, с постепенным эволюционным развитием программного обеспечения. Но это не значит, что в проектах по разработке программного обеспечения не надо разрабатывать техническое задание или другие какие-либо документы. Документы разрабатывать необходимо, только они будут сильно отличаться от документов по ГОСТ. Скорее всего это будет документ состоящий из двух частей. Первая часть описывает общие и базовые требования к программному обеспечению. Вторая часть итерационная, опираясь на общие требования в первой, разрабатывается для каждой итерации.

«Зачем нужен документ, если он не соответствует ГОСТ?» – кто-то может задать такой вопрос и добавить, - «А давайте просто список требований в файле Excel!». Безусловно, такой подход возможен при работе с небольшим и не государственным заказчиком, где тот, кто заказывает программное обеспечение и будет фактически его эксплуатировать.
Если мы говорим о более или менее крупном Заказчике, то создание документа преследует следующие цели:

Так где же полезен ГОСТ 34.601-90?

На мой взгляд, имеет смысл отталкиваться от ГОСТ 34.601-90 для выполнения различных интеграционных проектов, но с некоторыми изменениями.
Поэтому предлагается следующий подход разделения работ на этапы:

После выполнения всех работ по развертыванию, настройке автоматизированной системы и приемки системы в промышленную эксплуатацию, работы по проекту, фактически, завершаются. Сопровождение системы может производиться в рамках работ по технической поддержке или можно инициировать проект по технической поддержке. Хотя термин «Проект» не совсем подходящий термин для этапа 5. Хотя некоторые организации настаивают на использование термина проект, и мотивируют это тем, что это работы, которые ограничены во времени, имеют определенные фиксированные трудозатраты и бюджет и нацелены на уникальные решения (некоторые сбои в работе оборудования и программного обеспечения действительно бывают уникальные :)).
В рамках выполнения работ, этапы с первого по четвертый по сути являются проектом.

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

Этапы интеграционного проекта на основании ГОСТ 34.601-90
Этапы Описание этапа и работ Входные данные Выходные данные
1 этап:
«Подготовка договора».
Подготовка договора должна обязательно в себе содержать стадии по ГОСТ 34.601-90: «Формирование требований к АС», «Разработка концепции АС».
Технические требования к договору должны быть подписан вместе с договором, как приложение к договору и быть неотъемлемой частью договора. Кто-то может спросить,- «А почему не ТЗ к договору?». Дело в том, что ТЗ (Техническое задание) более емкий и глубокий документ, на разработку которого и его согласование может уйти месяц и более. Технические требования определяют внешнее границы проекта, общие требования к структуре и построению системы. Но ТЗ будет содержать конкретные требования, которые могут быть сформированы только при работе проектных команд со стороны Заказчика и Исполнителя.
  • проведение организационной встречи с Заказчиком;
  • протокол оргаизационной встречи;
  • соглашение о конфиденциальности (NDA).
  • «Технические требования» к договору;
  • план-график работ;
  • устав проекта. (при необходимости устав проекта можно заменить организационным протоколом проекта).
2 этап:
«Техническое задание».
Включает в себя стадию «Техническое задание»
Договор подписан, проектные команды со стороны Исполнителя и Заказчика сформированы, устав проекта разработан и подписан, все типы коммуникации и роли определены, иными словами «процесс пошел».
  • подписанный договор с техническими требованиями;
  • план-график;
  • устав проекта.
Документ
«Техническое задание».
3 этап:
«Технический проект».
Включает в себя стадии по ГОСТ 34.601-90:
  • эскизный проект;
  • технический проект;
  • рабочая документации.
На данном этапе выполняется разработка необходимых документов для реализации работ по внедрению оборудования и программного-обеспечения, а также проверка их работоспособности. На данном этапе задаются точные критерии проверки системы или систем.
  • документ
    «Техническое задание».
  • устав проекта;
  • план-график;
  • документ
    "Пояснительная записка к техническому проекту»;
  • документ
    «Программа и методика испытаний».
Но мой взгляд этих документов вполне достаточно для успешной сдачи проекта. В случае, если необходимо разработать дополнительные схемы или набор схем, то такие документы лучше всего разместить как приложения к документу «Пояснительная записка к техническому проекту».
4 этап:
«Ввод в действие».
Включает в себя стадию по ГОСТ 34.601-90: Ввод в действие.
Выполняются работы в соответствии с разработанным и согласованным документом «Пояснительная записка к техническому проекту».
Выполняется проверка работоспособности системы и соответствии функционала системы заявленным требованиям на основании документа «Программа и методика испытаний».
На этом этапе выполняется закупка необходимых компонентов для реализации проекта, если необходимое оборудование не было закуплено сразу после заключения договора. В случае, если спецификация определена, то возможно закупить оборудоваие и программное обеспечение сразу после заключения договора.
  • документ
    "Пояснительная записка к техническому проекту»;
  • документ
    «Программа и методика испытаний».
  • устав проекта;
  • план-график.
Построенная автоматизированная система.
  • протокол проведения предварительных испытаний;
  • протокол проведения испытаний в опытную эксплуатацию;
  • протокол проведения испытаний; в промышленную эксплуатацию;
  • акт приемки системы в промышленную эксплуатацию.

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

Сопровождение автоматизированной системы или техническая поддержка
Этапы Описание этапа и работ Входные данные Выходные данные
5 этап:
«Сопровождение автоматизированной системы».
Включает в себя стадию по ГОСТ 34.601-90 «Сопровождение автоматизированной системы». Построенная автоматизированная система.
  • документ
    «Техническое задание».
  • документ
    "Пояснительная записка к техническому проекту»;
  • документ
    «Программа и методика испытаний».
  • акт приемки системы в промышленную эксплуатацию.
  • поступающие заявки на обслуживание; протоколы выполненных
  • работ по регламентному техническому обслуживанию и аварийным работам.


Николай Ткаченко, 2015 г.