Разработка документации по гост 34. Какие бывают госты? Гост - государственный стандарт

Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора - в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

Что такое стандарты на документацию?

В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:

Самый любимый и популярный стандарт по разработке ТЗ. Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований. Хотя бы в плане общей идеологии (о которой ниже)

Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.

Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.

Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.

К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.

Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.

Минусы стандартов

Основной минус всем очевиден - стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:

• приложения двухуровневые, состоящие из клиентской программы и сервера СУБД (никаких трех- и более «уровневых» приложений, никаких Weblogic или JBoss)
• структура таблиц базы данных, будучи описана, даст представление о логической модели данных (то, что между приложением и базой может находиться какой-нибудь Hibernate, тогда казалось нехорошим излишеством)
• пользовательский интерфейс однооконный (а разве бывает другой? А что такое «браузер»?)
• Отчетов в системе немного, все они бумажные и печатаются на матричном принтере
• Разрабатываемая программа ориентирована на решение «задачи обработки информации», которая имеет четкий вход и выход и узко специализирована. В основе обработки информации лежит «алгоритм». Иногда «алгоритмов» бывает несколько. (Объектно-ориентированное программирование тогда делало лишь свои первые шаги и серьезно не рассматривалось).
• администратор базы данных понимает, какая информация лежит в таблицах и активно участвует в редактировании системных справочников (а разве бывает один сервер СУБД для 50 разных приложений?)

Соответственно, в стандарте есть артефакты, наподобие следующего:

5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.

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

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

Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.

Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.

Что в стандарте хорошо

Любой стандарт хорош уже тем, что он позволяет заказчику и исполнителю говорить на одном языке и дает гарантию, что, по крайней мере, претензий «по форме» к передаваемым результатам у заказчика не будет.

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

Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.

Можно смеяться над тем, что создатели стандартов ничего не знали о java или.NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества.

Как читать и понимать стандарты документации по ГОСТ серии 34

Стандарт делит все документы по двум осям - время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»

Стадии создания АСУ

Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:

• Эскизный проект (ЭП)
• Технический проект (ТП)
• Разработка рабочей документации (РД)

Эскизный проект следует после стадии Техническое задание и служит для разработки предварительных проектных решений.

Технический проект описывает будущую систему со всех ракурсов. Документы стадии ТП должны после прочтения оставлять после себя полную ясность в предлагаемых подходах, методах, архитектурных и технических решениях. На следующей фазе уже поздно будет описывать подходы и обосновывать технические решения, так что фаза П является ключом к успешной сдаче работ, так как все многообразие требований ТЗ должно находить отражение в документах фазы П. На этапе П система может вообще не существовать.

Рабочая документация предназначена для успешного развертывания, ввода в действие и дальнейшей эксплуатации новой системы. Это документы, содержащие совершенно конкретные сведения, описывающие физически существующие сущности, в отличие от фазы П, где описывается будущее великолепие.

Части (разделы) проектной документации по созданию АСУ

Предметная область разделена на «Обеспечения». Поначалу кажется, что такое деление избыточно и ненужно. Но когда начинаешь на практике работать этим инструментарием, постепенно доходит вложенная в него идеология.

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

Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):

Математическое обеспечение (МО) , отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?

Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса - почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.

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

Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?

Короче, на фазе РД документы Информационного обеспечения представляют собой довольно зловредный рудимент, так как формально они быть должны, но наполнять их особенно нечем.

Программное обеспечение (ПО) . Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.

В этом документе мы должны рассказать, при помощи каких программных средств выполняются алгоритмы, описанные в МО, обрабатывающие информацию, описанная в ИО. То есть, не нужно дублировать тут информацию из других разделов. Тут дается архитектура системы, обоснование выбранных программных технологий, их описание (всякие системные вещи: языки программирования, фреймворки, операционки и т.п.). Также в этом документе мы описываем как организованы средства обработки информации (очереди сообщений, хранилища, средства резервного копирования, решения по доступности, всякие пулы приложений и т.п.). В стандарте есть подробнейшее описание содержания этого документа, которое поймет любой специалист.

Техническое обеспечение (ТО) . Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП.

Дело в том, что стандарт предусматривает описание всего технического обеспечения, включая компьютерное «железо» и сети, инженерные системы и даже строительную часть (если потребуется). А это хозяйство регламентируется громадным количеством стандартов и нормативных актов, согласуется в разных организациях и поэтому удобнее все дробить на части и согласовывать (править) по частям. В то же время стандарт позволяет объединять некоторые документы друг с другом, что имеет смысл делать, если всю кучу согласует один человек.

Не забывайте также, что комплекс стандартов качества подразумевает учет и хранение технических документов, и наши «книжицы» у заказчика могут разойтись по разным архивам, в зависимости от предмета описания. Это еще один аргумент в пользу дробления документации.

Организационное обеспечение (ОО) . Подавив в себе нормальное для технаря желание проскочить этот раздел поскорее, наоборот, рассмотрю его более подробно. Так как, коллеги, в последнее время на проектах наметились нехорошие тенденции, которые требуют внесения ясности именно в этот раздел.

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

На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.

Руководство пользователя . Комментарии излишни, я думаю.

Методика (технология) автоматизированного проектирования . В этот документ при необходимости можно поместить описание процесса сборки ПО, управления версиями, тестирования и т.п. Но это если в ТЗ заказчик желает самолично осуществлять сборку ПО. Если он этого не требует (и не платит за это), то вся ваша внутренняя кухня не его ума дело, и этот документ делать не нужно.

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

Описание бизнес-процессов, ролевые и должностные инструкции, регламенты работы - все это ОРД, то есть организационно-распорядительная документация. Которая является продуктом консалтингового проекта, который у вас, насколько я понимаю, не покупали. А покупали у вас проект технический и документацию к нему тоже техническую.

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

Об описанных граблях я еще напишу отдельно, с красочными примерами, так как это повторяется уже не первый раз и в разных отраслях «народного хозяйства».

Описание технологического процесса обработки данных (включая телеобработку) . Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция - для них. Что в нее писать в XXI веке - я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.

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

А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.

Варианты использования ГОСТ 34

1. Полное и точное следование стандарту . Добровольно никто, естественно, такую тучу документов писать не будет. Поэтому полный комплект документов готовится только по настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще договором сверху придавил. В таком случае требуется понимать все буквально и отдать заказчику физические «книжки», на которых будут стоять названия документов из таблицы 2 ГОСТ 34.201-89 за исключением совсем уж ненужных, перечень которых вы обязательно должны обговорить и закрепить письменно. Содержание документов также должно без всякой фантазии соответствовать РД 50-34.698-90, вплоть до названия разделов. Для того, чтобы у заказчика взорвался мозг, иногда большую систему делят на подсистемы, и для каждой подсистемы выпускают отдельную проектную документацию. Выглядит это устрашающе и нормальному контролю при помощи земного разума не подлежит. Особенно в части интеграции подсистем. Что значительно упрощает приемку. Главное, чтобы вы сами при этом не запутались и чтобы ваша система все-таки заработала как надо.
2. Мы просто любим ГОСТы . В серьезных больших компаниях любят стандарты. Потому, что они помогают людям лучше понимать друг друга. Если ваш заказчик замечен в любви к порядку и стандартизации, постарайтесь придерживаться стандартной идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ. Вас лучше поймут и одобрят согласующие специалисты, а вы сами не забудете включить в документацию важную информацию, лучше будете видеть целевую структуру документов, точнее планировать работы по их написанию и сэкономите себе и коллегам массу нервов и денег.
3. Нам плевать на документацию, лишь бы все работало . Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями - директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).

Заключение

Эта статья была о наших ГОСТах на документирование АСУ. ГОСТы старые, но, как оказалось, до сих пор очень даже полезные в хозяйстве. Не считая некоторые явные рудименты, структура документации обладает свойствами полноты и непротиворечивости, а следование стандарту снимает многие проектные риски, о существовании которых мы можем по началу не догадываться.

Надеюсь, изложенный материал был вам полезен, или, как минимум, интересен. Несмотря на внешнюю скуку, документирование является важной и ответственной работой, аккуратность в которой так же важна, как и при написании хорошего кода. Пишите хорошие документы, коллеги! А я на следующей неделе отправляюсь в две подряд командировки, так что публикацию новых материалов не гарантирую (загашника у меня нет, пишу из головы).

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

Таблица 2.1. Стадии и этапы создания автоматизированной системы по ГОСТ 34.601-90

Стадии	Этапы
1. Формирование требований к АС	1.1. Обследование объекта и обоснование необходимости создания АС
	1.2. Формирование требований пользователя к АС
	1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС	2.1. Изучение объекта
	2.2. Проведение необходимых научно-исследовательских работ
	2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя
	2.4. Оформление отчета о выполненной работе
3. Техническое задание	3.1 Разработка и утверждение технического задания на создание АС
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. Послегарантийное обслуживание

Практически все перечисленные стадии и этапы до сих пор встречаются в практике создания информационных систем предприятий и организаций. Конечно, можно критиковать стандарт за негибкость в части последовательности и названий стадий и этапов, но факт остается фактом - он продемонстрировал исключительную живучесть, и понять, в чем причина этого, гораздо важнее, чем заниматься критикой разработки почти 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 стимулировало возникновение новых специалистов - бизнес-аналитиков и консультантов в сфере информационных технологий, основной работой которых стали разработка и согласование Технических заданий с заказчиками автоматизированных систем.

ИСПОЛЬЗОВАНИЕ ТРЕБОВАНИЙ ГОСТ 19 и 34 СЕРИИ ПРИ ОФОРМЛЕНИИ ДОКУМЕНТАЦИИ В IT-ПРОЕКТАХ ДЛЯ ГОСУДАРСТВЕННЫХ СТРУКТУР

Введение

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

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

При разработке автоматизированных систем (АС) по ГОСТ 34 в IT-проектах для госструктур зачастую возникает вопрос: по каким ГОСТам оформлять документацию? В ГОСТ 34 нет явных указаний на то, по каким стандартам оформлять конкретные документы, разрабатываемые в рамках создания АС, кроме требований к оформлению ТЗ. Попробуем выяснить, какие ГОСТы используются при оформлении документов в случае отсутствия точных указаний в государственном контракте или конкурсном техническом задании (ТЗ). Данный материал в первую очередь, предназначен для IT-специалистов, желающих разобраться, как оформляются документы в IT-проектах по требованиям ГОСТ.

Определение стандартов оформления документации

Оформление документов в ГОСТ 34 зависит от вида документа (конструкторский или программный), и стадии создания АС, на которой готовится документ.

Перечень документов, разрабатываемых на различных стадиях создания АС приведен в ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем». В нем приведены следующие требования:

• На стадии «Техническое задание» разрабатывают ТЗ на создание АС по ГОСТ 34.602 -89 «Техническое задание на создание автоматизированной системы»;
• Виды программных документов ГОСТ 19.101-77 «Единая система программной документации. Виды программ и программных документов». К ним относятся различные руководства, например, руководство пользователя.
• Виды конструкторских документов , разрабатываемых на различных стадиях создания АС определяются по ГОСТ 2.102-2013 «Единая система конструкторской документации. Виды и комплектность конструкторских документов». Например, к ним относятся ведомости эскизного и технического проекта, ведомость покупных изделий, пояснительные записки к эскизному, техническому проектам.

Теперь разберем подробнее, как определить стандарты оформления в различных проектах.

Оформление ТЗ

С ТЗ всё достаточно ясно: в ГОСТ 34.602-89 приведен стандарт его оформления: п.3.2. гласит, что «ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней».

Оформление программной документации

С программными документами, разрабатываемыми в рамках ИТ-проекта, также есть чёткое указание использовать ГОСТ 19 серии в части оформления: вышеприведённый ГОСТ 19.101-77 входит в серию ГОСТов 19-й серии «Единая система программной документации» (ЕСПД). ЕСПД - комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации.

Документация в ЕСПД оформляется по ГОСТ 19.104-78 «Единая система программной документации. Основные надписи», ГОСТ 19.105-78 «Единая система программной документации. Общие требования к программным документам», ГОСТ 19.106-78 «Единая система программной документации. Требования к программным документам, выполненным печатным способом».

Оформление конструкторской документации

Теперь рассмотрим ГОСТ 2.102-2013. Этот стандарт входит в серию ГОСТов 2-й серии «Единая система конструкторской документации» (ЕСКД). ЕСКД - межгосударственный комплекс стандартов, устанавливающих взаимосвязанные нормы и правила по разработке, оформлению и обращению конструкторской документации, разрабатываемой и применяемой на всех стадиях жизненного цикла изделия (при проектировании, изготовлении, эксплуатации, ремонте и др.)

Документация в ЕСКД оформляется по нескольким стандартам. Наиболее часто используемыми из них (применительно к ИТ-сфере) являются ГОСТ 2.105-95 «Единая система конструкторской документации. Общие требования к текстовым документам» и ГОСТ 2.106-96 «Единая система конструкторской документации. Текстовые документы».

На первый взгляд из ГОСТ 34 серии непонятно, как оформлять документацию на АС. Нередко в рамках ИТ-проекта, особенно для государственных заказчиков, в ТЗ бывают требования по оформлению документации согласно ГОСТ 2.105-95 и ГОСТ 2.106-96. Но следует ли оформлять документы по этим ГОСТам в случае, если в явном виде требования к оформлению отсутствуют?

Как правильно оформить?

В ГОСТ 2-й серии приведены требования к назначению каждого стандарта и обозначена отрасль его применения: ГОСТ 2.102-2013 – стандарт устанавливает виды и комплектность конструкторских документов на изделия всех отраслей промышленности.

Если ГОСТ 2.102-2013 распространяется на изделия всех отраслей, в том числе и ИТ-сферу, давайте разберёмся, а что является конструкторским документом?

Согласно ГОСТ 2.001-2013 «Единая система конструкторской документации (ЕСКД). Общие положения»:

А) «3.1.2 конструкторский документ: Документ, который в отдельности или в совокупности с другими документами определяет конструкцию изделия и имеет содержательную и реквизитную части, в том числе установленные подписи»

Б) «3.1.5 конструкторская документация: Совокупность конструкторских документов, содержащих данные, необходимые для проектирования (разработки), изготовления, контроля, приемки, поставки, эксплуатации, ремонта, модернизации, утилизации изделия»

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

Основные ГОСТы 2-й серии для ИТ-проекта в части оформления

Теперь посмотрим на основные ГОСТы 2-й серии, наиболее часто применяемые для оформления документов в ИТ-проекте. Как правило, в части оформления используют:

ГОСТ 2.105-95 – стандарт устанавливает общие требования к выполнению текстовых документов на изделия машиностроения, приборостроения и строительства;

ГОСТ 2.106-96 – стандарт устанавливает формы и правила выполнения конструкторских документов изделий машиностроения и приборостроения.

У читателя может возникнуть вопрос, можем ли мы применять эти ГОСТы для АС, если они предназначены для изделий машиностроения и приборостроения?

Согласно определению «Большой Советской энциклопедии», «Приборостроение -отрасль машиностроения, выпускающая средства измерения, анализа, обработки и представления информации, устройства регулирования, автоматические и автоматизированные системы управления; область науки и техники, разрабатывающая средства автоматизации и системы управления», то есть всё, что нужно по нашей теме современных информационных технологий.

Кроме этого, если заглянуть в ГОСТ 34.003-90 «Автоматизированные системы. Термины и определения», этот стандарт определяет АС как «систему, состоящую из персонала и комплекса средств автоматизации его деятельности, реализующую информационную технологию выполнения установленных функций».

Таким образом, АС относится к отрасли приборостроения и, следовательно, конструкторские документы АС оформляются по ГОСТ 2.105-95 и ГОСТ 2.106-96.

Теперь давайте рассмотрим основные моменты оформления проектной документации по ГОСТ 2.105-95 и ГОСТ 2.106-96.

Основные моменты при оформлении по ГОСТ 2. 105

Рассмотрим основные параметры оформления по ГОСТ 2-й серии.

Согласно ГОСТ 2.105-95 расстояние от рамки формы до границ текста в начале и в конце строк должно быть не менее 3 мм. Расстояние от верхней или нижней строки текста до верхней или нижней рамки должно быть не менее 10 мм. Абзацы в тексте начинают отступом, равным пяти ударам пишущей машинки (15 - 17 мм).

В ГОСТ 2.105-95 не определены параметры для оформления текста в электронном виде: название шрифта, высота шрифта, межстрочный интервал. Поэтому параметры оформления документов в электронном виде это, как правило, предмет договоренности с заказчиком.

В начале работы по оформлению в электронном виде определяются параметры для форматирования:

• Формат абзацев текста – используемый шрифт, высота шрифта, размер межстрочного интервала;
• Формат для каждого заголовка по уровням (1, 2, 3) – используемый шрифт, высота шрифта, отступ в см, размер межстрочного интервала;

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

Иллюстрации в документе следует располагать по центру. Название размещается непосредственно под иллюстрацией. Форматирование названия – как у текста документа.

Правила оформления таблиц

Таблицу, в зависимости от ее размера, помещают под текстом, в котором впервые дана ссылка на нее, или на следующей странице, а при необходимости, в приложении к документу.

Таблицы, за исключением таблиц приложений, нумеруют арабскими цифрами сквозной нумерацией. Например: «Таблица 1».

Таблицы каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения. Например: «Таблица В.1».

Допускается нумеровать таблицы в пределах раздела. В этом случае номер таблицы состоит из номера раздела и порядкового номера таблицы, разделенных точкой. Например, в разделе 4 номер будет «Таблица 4.3».

Название таблицы должно отражать ее содержание, быть точным, кратким. Название состоит из слова «Таблица», номера таблицы и текста. В ГОСТ 2.105-95 не определено использование в названии таблицы дефиса или тире. На практике может использоваться тире, по аналогии использования в названии рисунка тире. Например, «Таблица 5 – Выполняемые работы, содержание и сроки». Точка в конце названия не ставится. Название размещают над таблицей слева.

В ГОСТ 2.105-95 в п.п 4.4.3 приведено следущее требование: «На все таблицы документа должны быть приведены ссылки в тексте документа, при ссылке следует писать слово «таблица» с указанием ее номера». На практике слово «таблица» склоняется в тексте по правилам русского языка. Например: «Краткое описание назначения и основных характеристик подсистем ИС МП второй очереди представлено в таблице 1».

Если таблица размещается на нескольких страницах, следует отобразить ее заголовок в начале каждой страницы.

В ГОСТ 2.105-95 есть необязательное требование в п.4.4.7: «если в конце страницы таблица прерывается и ее продолжение будет на следующей странице, в первой части таблицы нижнюю горизонтальную линию, ограничивающую таблицу, допускается не проводить.». На практике нижнюю горизонтальную линию, проводят, так ее отсутствие ухудшает восприятие таблицы пользователем.

Правила оформления иллюстраций

К иллюстрациям относятся графические изображения (схемы, графики, фотографии, рисунки).

Иллюстрации, за исключением иллюстраций приложений, нумеруются арабскими цифрами, при этом нумерация сквозная. Например: «Рисунок 3».

Иллюстрации каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения. Например: «Рисунок В.6».

Допускается нумеровать иллюстрации в пределах раздела. В этом случае номер иллюстрации состоит из номера раздела и порядкового номера иллюстрации, разделенных точкой. Например, в разделе 5 номер будет «Рисунок 5.2».

Допускается не нумеровать мелкие иллюстрации (мелкие рисунки), размещенные непосредственно в тексте и на которые в дальнейшем по тексту нет ссылок.

Требования ГОСТ 2.105-95 к расположению: «иллюстрации могут быть расположены как по тексту документа (возможно ближе к соответствующим частям текста), так и в конце его».

В ГОСТ 2.105-95 в п. 4.3.1 указано следующее: «при ссылках на иллюстрации следует писать "... в соответствии с рисунком 2" при сквозной нумерации и "... в соответствии с рисунком 1.2" при нумерации в пределах раздела».

Название пишется под иллюстрацией в формате «Рисунок 1 – Детали прибора».

Интересный факт: если ошибку в бумажном документе замазать и поверх написать исправление черными чернилами, это будет по ГОСТу. ГОСТ 2.105-95 допускает исправления документов в бумажном виде. Об этом гласит п.3.7: «Опечатки, описки и графические неточности, обнаруженные в процессе выполнения документа, допускается исправлять подчисткой или закрашиванием белой краской и нанесением на том же месте исправленного текста (графика) машинописным способом или черными чернилами, пастой или тушью рукописным способом. Повреждения листов текстовых документов, помарки и следы не полностью удаленного прежнего текста (графика) не допускаются».

То есть, если вы что-то распечатали и нашли ошибку, то её можно исправить вручную приведенным выше способом.

Оформление по ГОСТ 2. 106-96

ГОСТ 2.106-96 устанавливает формы и правила выполнения конструкторских документов. Для каждого типа документа в ГОСТ 2.106-96 приведен шаблон оформления рамок документа.

ГОСТ 2.106-96 определяет не только форму рамок, но и основную надпись в рамке. Пример из ГОСТ 2.106-96: «ПЗ составляют на формах 9 и 9а приложения А, а необходимые схемы, таблицы и чертежи в бумажной форме допускается выполнять на листах любых форматов, установленных ГОСТ 2.301, при этом основную надпись и дополнительные графы к ней выполняют в соответствии с требованиями ГОСТ 2.104 (форма 2а)».

Резюме

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

• Программные документы, разрабатываемые на различных стадиях создания АС оформляются по ГОСТ 19.104-78, ГОСТ 19.105-78, ГОСТ 19.106-78;
• Конструкторские документы, разрабатываемые на различных стадиях создания АС оформляются по ГОСТ 2.105-95 и ГОСТ 2.106-96. При этом требования к содержанию регламентируются РД 50.34-698-90.

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

@ Журавлев Денис

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

Как правило, необходимость в наличии документации по ГОСТ возникает при сотрудничестве с государственными организациями, крупными производствами и компаниями, при заказной разработке программного обеспечения по тендерам и госзаказам или при необходимости добавить программный продукт в "Единый реестр российских программ для электронных вычислительных машин и баз данных (реестр отечественного ПО)".

Существует две серии (набора) стандартов, которые регламентируют набор создаваемых документов и правила их оформления при разработке автоматизированных систем, комплексов и программного обеспечения:

• ГОСТ 34 - Автоматизированные системы
• ГОСТ 19 - Единая система программной документации (ЕСПД)

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

Если говорить именно о документации для конечного пользователя системы, то из перечня описываемых в ГОСТ 34 документов нас интересует "Руководство пользователя". В ГОСТ 19 аналогичный по смыслу документ называется "Руководство оператора", но для программного обеспечения чаще используется именно первый вариант.

Руководство пользователя поставляется с любым изделием, программой, системой. Он должен предоставлять пользователю информацию о свойствах продукта, его функциональности, способах использования и работе с ним.

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

Мало того, что необходимо изучить большое число нормативных документов, изобилующих перекрестными ссылками и написанных сложным, излишне канцелярским, почти юридическим языком, так еще необходимо выбрать оттуда требования, относящиеся именно к создаваемому виду документа. Затем, на протяжении всей работы, нужно постоянно контролировать соблюдение этих требований в рабочем документе, постоянно сверяясь со стандартами.

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

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

Dr.Explain упрощает создание руководства пользователя по ГОСТ

Начиная с версии 5.5.1100 программа для создания пользовательской документации Dr.Explain предлагает функцию автоматизированной поддержки ГОСТ в проектах. Эта функция призвана значительно облегчить жизнь пользователям, перед которыми стоит задача создания руководства пользователя в соответствии с требованиями государственных стандартов.

В частности программа Dr.Explain контролирует и автоматизирует поддержку следующих требований стандартов:

• Наличие обязательных разделов документа “Руководство пользователя” [ГОСТ 34 РД 50-34.698-90]. Все разделы снабжаются пояснениями по их содержанию.
• Оформление титульных листов, аннотации и содержания [ГОСТ 19.105-78, 19.104-78].
• Параметры печатных страниц документа и расположение основных элементов на них [ГОСТ 19.106-78].
• Структуру и оформление колонтитулов [ГОСТ 19.106-78].
• Оформление текстовой части документа: стили шрифтов, абзацные отступы, межстрочные интервалы [ГОСТ 19.106-78].
• Формирование и оформление заголовков, разделов, перечислений (списков) [ГОСТ 19.106-78].

Управление функцией поддержки ГОСТ для проекта доступно в Настройках проекта в разделе Общие .

При включенном режиме поддержки ГОСТ для проекта соответствующие пользовательские настройки для печатаемых форматов RTF\DOC и PDF автоматически перекрываются программой, что гарантирует полное соответствие параметров выходных документов требованиям стандартов.

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

Важно:

Важно: Функция поддержки ГОСТ доступна в Dr.Explain только в русскоязычной версии интерфейса. Язык интерфейса программы выбирается в меню Настройки\Выбор языка программы (Options\Application language ).

Создание нового руководства пользователя по ГОСТ

Для создания нового руководства пользователя по требованиям ГОСТ 34 в программе Dr.Explain можно использовать команды меню Файл \ Создать локальный проект - Руководство пользователя по ГОСТ 34 или Файл \ Создать общий проект на tiwri.com - Руководство пользователя по ГОСТ 34

или аналогичные кнопки на стартовом экране приложения.

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

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

Настройки оформления для печатных форматов RTF/DOC и PDF будут выставлены в соответствии с требованиям ГОСТ 19.

Приведение существующей пользовательской документации в соответствие с требованиями ГОСТ

Также программа Dr.Explain позволяет привести существующую пользовательскую документацию в соответствии с требованиями ГОСТ.

Важно: Перед включением режима поддержки ГОСТ для уже существующих в формате Dr.Explain проектов необходимо сделать резервную копию gui-файла проекта.

Если исходная документация еще не ведется в Dr.Explain, а хранится в других форматах, первым шагом необходимо выполнить импорт существующих документов в программу. Dr.Explain поддерживает импорт документов из ряда популярных форматов. Команды импорта доступны как на стартовом окне программы, так и в меню Файл .

Затем необходимо включить режим поддержки ГОСТ в свойствах проекта описанным ранее способом. Программа проверит структуру документа на наличие обязательных разделов и, если они отсутствуют, создаст их. Остальные существующие разделы, наличие которых не регламентировано ГОСТами, будут перенесены в скрытый от экспорта раздел “Старое дерево разделов ”.

Пользователь должен будет перенести содержимое этих разделов или разделы целиком методом drag-n-drop в основное дерево проекта и отредактировать их по необходимости.

Как и в первом случае настройки оформления для печатных форматов RTF/DOC и PDF будут выставлены в соответствии с требованиям ГОСТ 19.

ГОСТ - государственный стандарт

Государственные стандарты (ГОСТ) впервые были разработаны Комитетом по стандартизации при Совете труда и обороны, созданном в 1925 году. Тогда 80 лет назад были разработаны и утверждены стандарты, регламентирующие производство практически всего - начиная от продуктов питания и заканчивая автомобилями. Данные стандарты носили обязательный характер и действовали на всей территории СССР.

На сегодняшний день насчитывается порядка 25 тысяч ГОСТов, которые распространены не только на территории Российской Федерации, но и некоторых стран СНГ, таких как Азербайджан, Армения, Белоруссия, Грузия, Казахстан, Киргизия, Молдова, Таджикистан, Узбекистан, Украина. С 27 декабря 2002 года, согласно Федеральному закону о техническом регулировании (№184-ФЗ) ГОСТ перестал носить обязательный характер и может применяться добровольно (за исключением случаев, касающихся обеспечения безопасности здоровья граждан или окружающей среды). В этом же году было введено понятие технического регламента, который в будущем должен заменить государственные стандарты.

Публикация текстов ГОСТов на территории Российской Федерации должна вестись на бесплатной основе. На официальном сайте Ростехрегулирования можно найти в открытом доступе большинство государственных стандартов.

Классификация ГОСТов

В советское время классификация ГОСТов была представлена в «Классификаторе Государственных стандартов СССР». Классификация ГОСТов в классификаторе стандартов СССР являлась строго иерархической. Система классификации ГОСТов включала несколько уровней, при этом каждому стандарту присваивался отдельный буквенно-цифровой код.

На сегодняшний день классификация ГОСТов ведется по Общероссийскому классификатору, разработанному в ВНИИ классификации, терминологии и информации по стандартизации и качеству и введенному в действие в 2000 году. Общероссийский классификатор согласуется с Международным классификатором стандартов ISO.

В данном классификаторе каждому стандарту присваивается соответствующий цифровой код, который состоит из номера и года утверждения ГОСТа. Номер стандарта имеет префикс, указывающий его на принадлежность к определенной серии документации, и порядковый номер, который определяется последовательностью принятия. Например:

• ГОСТ 2 .ххх - Единая Система конструкторской документации (ЕСКД)
• ГОСТ 19 .ххх - Единая Система программной документации (ЕСПД)
• ГОСТ 24 ххх. - Единая система стандартов автоматизированных систем управления (позднее ГОСТ 34 - Комплекс стандартов на автоматизированные системы)

Так как ГОСТ носит частично международный характер для стандартов, действующих только на территории России, принято наименование ГОСТ Р.

На нашем сайте вы можете найти основные стандарты, регулирующие производственные процессы в сфере информационных технологий.

ГОСТ 34 и ГОСТ 19

Наиболее частой проблемой при разработке технической документации является вопрос выбора правильного стандарта (ГОСТ 19 или ГОСТ 34 ). Ключ к пониманию разницы между данными стандартами заложен в наименовании их комплекса - Единая система программной документации (ГОСТ 19 ) и Комплекс стандартов на автоматизированные системы (ГОСТ 34 ).

Автоматизированная система является результатом целенаправленной деятельности ведущей к автоматизации одного или нескольких производственных процессов на предприятии. Таким образом, автоматизированная система (АС) должна иметь:

• цель (например: оптимизация процесса документооборота на предприятии);
• обслуживающий и эксплуатационный персонал (например: системный администратор, администратор баз данных и т.п.);
• программные средства, обеспечивающие корректную работу АС (например: операционная система);
• комплекс технических средств, на котором развернута АС (например: сервер, рабочее место пользователя).

В то время как АС является комплексной системой, программа представляет собой код, исполняемый машиной (компьютером). Программа может существовать как часть автоматизированной системы, так отдельно.

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