Традиционные ИТ-стандарты. ГОСТ 34

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

Тридцать четвертым ГОСТом на жаргоне ИТ-специалистов называется совокупность взаимосвязанных стандартов, которые имеют номер, начинающийся на 34: ГОСТ 34.602-89, 34.003-90, 34.603-92, 34.201-89, 34.601-90, 34.698-90, 34.320-96, 34.321-96, а также руководящий документ РД 50-34.698-90 и два стоящих особняком стандарта, относящихся к узкоспециальной теме криптозащиты - ГОСТ 34.10-01 и ГОСТ 34.11-94.

Все эти стандарты появились в конце 80-х - начале 90-х годов (год выпуска обозначен числом после дефиса), заменив или дополнив более ранние стандарты 19-й и 24-й серий.

Чтобы понять и оценить логику, содержащуюся в семействе ГОСТ 34, проанализируем содержание составляющих его стандартов более подробно. Ориентированные на ИТ-специалистов ГОСТ 34.320-96 "Концепции и терминология для концептуальной схемы и информационной базы", ГОСТ 34.321-96. "Эталонная модель управления данными", ГОСТ 34.10-01 "Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи" и ГОСТ 34.11-94 "Криптографическая защита информации. Функция хэширования" я рассматривать не буду, поскольку они рассчитаны не на управленцев, а на технических специалистов. Для нас интерес представляют следующие стандарты:

• ГОСТ 34.201-89. "Виды, комплектность и обозначение документов при создании автоматизированных систем";
• ГОСТ 34.003-90 "Термины и определения";
• ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы";
• ГОСТ 34.603-92 "Виды испытаний автоматизированных систем";
• ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания";
• Руководящий документ РД 50-34.698-90 "Автоматизированные системы. Требования к содержанию документов".

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

Стандарт ГОСТ 34.201-89

Серьезно устаревший, но отчасти пригодный для использования стандарт (ГОСТ 34, 1989а). Устанавливает соответствие документов стадиям создания АС^{1АС - автоматизированная система, т. е. информационная система, разрабатываемая или внедряемая на конкретном предприятии.} , описанным в ГОСТ 24.601 (впоследствии заменен на ГОСТ 34.601). По составу документов и стадиям проекта можно проследить происхождение стандарта из практики строительства. Очевидно, проектная природа строительства и деятельности по созданию информационной системы навела авторов стандарта на мысль распространить основные формы организации строительных проектов на проекты создания информационных систем. Отчасти это оказалось удобно - такие документы, упомянутые в стандарте, как "Техническое задание", "Эскизный проект", "Технический проект", "Инструкция" (пользователя), "Программа и методика испытаний" прочно вошли в практику создания систем. С другой стороны, "Ведомость машинных носителей информации", "Каталог базы данных" или "Ведомость держателей подлинников" вряд ли сейчас имеют смысл. Стандарт включает также элементы практики делопроизводства в виде правил кодирования документов.

Короче говоря, при "творческом" подходе он может еще послужить, особенно в тех организациях, где проектная деятельность регулируется аналогичными проектно-ориентированными стандартами, а состав проектных документов близок к тому, что предлагает ГОСТ 34.201-89.

Стандарт ГОСТ 34.601-90

Один из наиболее применяемых до сих пор стандартов (ГОСТ 34, 1990), определяющий стадии и этапы создания автоматизированной системы. Приведенная ниже таблица является центральной в стандарте.

Практически все перечисленные стадии и этапы до сих пор встречаются в практике создания информационных систем предприятий и организаций. Конечно, можно критиковать стандарт за негибкость в части последовательности и названий стадий и этапов, но факт остается фактом - он продемонстрировал исключительную живучесть, и понять, в чем причина этого, гораздо важнее, чем заниматься критикой разработки почти 20-летней давности. Мне кажется, что стандарт демонстрирует точное соответствие своим целям. Во-первых, он не требует знаний в области ИТ и, следовательно, понятен обычным управленцам. Во-вторых, он компактен и прост по структуре, что позволяет человеку, не знакомому с ним, быстро войти в курс дела. В-третьих, он самодостаточен - практически никаких ссылок на смежные документы в нем нет (за исключением ГОСТ 34.201). И наконец, он практичен - сразу понятно, как его применять и как контролировать его применение.

Помимо вышеприведенной таблицы ГОСТ 34.601-90 содержит справочное Приложение 1 с поэтапной расшифровкой работ, включая указание на документы, возникающие в результате этих работ, а также Приложение 2 - "Перечень организаций, участвующих в работах по созданию АС". Это подсказывает способ адаптации стандарта к конкретным условиям: достаточно переработать Приложения, и получится вполне разумный корпоративный стандарт на создание ИС. Причем опять-таки эта работа под силу обычному управленцу.

Стандарт ГОСТ 34.602-89

Требование "подготовить Техническое задание в соответствии с ГОСТ 34.602-89", знакомо, наверное, каждому, кто хоть однажды участвовал в заказной разработке ИС или ее приемке, да и вообще всем, кто так или иначе связан с информационными системами. Некоторые разработчики до сих пор считают хорошим тоном помнить наизусть состав Технического задания (ТЗ) в соответствии с ГОСТ 34.602-89 (ГОСТ 34, 1989б).

1. Общие сведения.
2. Назначение и цели создания (развития) системы.
3. Характеристика объектов автоматизации.
4. Требования к системе.
5. Состав и содержание работ по созданию системы.
6. Порядок контроля и приемки системы.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
8. Требования к документированию.
9. Источники разработки.

Попробуем разобраться в причинах неизменной популярности этого стандарта, возраст которого перевалил уже за 20 лет. Собственно, весь стандарт представляет собой расшифровку перечисленных девяти пунктов. Размер его - всего 11 страниц, но объем сообщаемой полезной информации на удивление велик. Если выбросить явные архаизмы, вроде существовавших когда-то фондов алгоритмов и программ, окажется, что практически все, о чем идет речь, полностью применимо до сих пор. Вот пример одного из разделов.

"2.6.2. В подразделе "Требования к функциям (задачам)", выполняемым системой, приводят:

1. по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;

   при создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;
2. временной регламент реализации каждой функции, задачи (или комплекса задач);
3. требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов;
4. перечень и критерии отказов для каждой функции, по которой задаются требования по надежности".

Приведенный отрывок демонстрирует иерархичность стандарта: система состоит из подсистем, комплексов задач, отдельных задач, функций. Чем точнее и подробнее сформулированы требования, тем более предсказуемым будет результат. Специально формулируются требования к функциям взаимодействия подсистем (сейчас мы бы сказали "к методам интеграции"), функции привязываются к плану-графику реализации системы (который тем самым также становится иерархическим). Специально упомянуты требования к качеству. Форма представления выходной информации, т.е. совокупность отчетов, также заслужила отдельного упоминания. Одним словом, представленный отрывок показывает, что разработка Технического задания в соответствии с ГОСТ 34.602-89 - непростая и очень трудоемкая работа, накладывающая серьезные обязательства не только на разработчика, но и на заказчика системы. Потенциал стандарта чрезвычайно велик, и неудивительно, что популярность его остается неизменно высокой на протяжении стольких лет.

С течением времени стали видны и оборотные стороны стандарта:

• стандарт ориентирован на полностью заказную разработку системы "с нуля" и не рассчитан на внедрение готового решения с помощью типовой методологии или на комбинацию заказных разработок и внедрений;
• стандарт предлагает одну-единственную модель жизненного цикла системы, называемую каскадной, когда все работы по созданию системы линейно упорядочены и этот порядок заранее определен;
• стандарт имеет слишком формальный характер. На практике это приводит к появлению Технических заданий, по форме удовлетворяющих требованиям ГОСТ 34.602-89, но по сути малосодержательных.

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

Другое интересное явление, которое продемонстрировала практика, состоит в том, что, как оказалось, далеко не каждый ИТ-специалист способен разработать Техническое задание, удовлетворяющее требованиям стандарта. Фактически появление ГОСТ 34.602-89 стимулировало возникновение новых специалистов - бизнес-аналитиков и консультантов в сфере информационных технологий, основной работой которых стали разработка и согласование Технических заданий с заказчиками автоматизированных систем.