Традиционные ИТ-стандарты. ГОСТ 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.003-90, помимо того что содержит многочисленные ошибки, полностью устарел и потерял актуальность, поэтому о нем я говорить не буду. Таким образом, далее рассматривается четыре последних документа.

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

Серьезно устаревший, но отчасти пригодный для использования стандарт (ГОСТ 34, 1989а). Устанавливает соответствие документов стадиям создания АСАС - автоматизированная система, т. е. информационная система, разрабатываемая или внедряемая на конкретном предприятии. , описанным в ГОСТ 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б).

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

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

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

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

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

Стандарт ГОСТ 34.603-92

Компактный и прозрачный стандарт (ГОСТ 34, 1992), устанавливающий последовательность испытаний готовой информационной системы, цели и результаты испытаний. Широко применяется на практике, обладая теми же достоинствами, что и ГОСТ 34.601-90, - лаконичностью, доступностью для неспециалиста в ИТ, самодостаточностью. Понятия и термины стандарта стали общепринятыми в российском ИТ-сообществе.

РД 50-34.698-90

Руководящий документ (РД 34, 1990) определяет состав и структуру документов, введенных в ГОСТ 34.201-89, вплоть до форматов приказов о начале опытной эксплуатации и вводе в промышленную эксплуатацию. Многое заимствовано из практики строительства, особенно в части подготовки сметной документации. Вот типичный пример:

"Локальная смета и локальный сметный расчет содержат сведения о сметной стоимости работ, выполняемых при создании АС, и сметной стоимости объектов, сооружаемых при создании АС, в соответствии с требованиями СНиП 1.02.01 и других документов по определению стоимости АС и ее составных частей".

Конечно, многое в документе устарело и не соответствует современным реалиям, но отдельные части его выглядят по-прежнему актуально. Вот достаточно показательная, хотя и пространная цитата.

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

Сама идея, заложенная в РД 50-34.698-90 (формализовать не процесс, а документы), сейчас представляется, конечно, довольно странной, но в прагматичности ей не откажешь. Соответствие проектных документов требованиям стандарта, по существу, устанавливает необходимый уровень качества в проекте разработки АС (хотя понятия проекта в стандарте, конечно, нет). Как мы увидим дальше, этот подход оказался невостребованным в современных стандартах, где форматы и структуры документов отсутствуют, хотя потребность в готовых шаблонах документов у специалистов-практиков достаточно велика. Немаловажно и то, что язык документов хорошо понятен управленцам, и стандарт делает для них задачу создания АС прозрачной (конечно, настолько, насколько это возможно). Тем самым он выполняет важнейшую управленческую задачу - помогает принимать и контролировать решения, касающиеся ИТ, управленцам, не являющимся специалистами в этой области.

ГОСТ 34. Заключение

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

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

Тем не менее практическая ценность ГОСТ 34 достаточно велика и сегодня. 34-й ГОСТ - удобный и практичный инструмент для:

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

Краткие итоги

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

Вопросы