Роль государственных стандартов на документацию

- общий  бланк;

- бланк  письма;

- бланк  конкретного вида документа.

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

Общий бланк в зависимости от учредительных  документов организации включает в  себя реквизиты 01 (02 или 03), 08, 11, 14.

Бланк письма в зависимости от учредительных  документов организации включает в  себя реквизиты 01 (02 или 03), 04, 05, 06, 08, 09 и, при необходимости, ограничительные  отметки для верхних границ зон  расположения реквизитов 11, 12, 13, 14, 15, 17, 18, 19, 20.

Бланк конкретного вида документа, кроме  письма, в зависимости от учредительных  документов организации включает в  себя реквизиты 01 (02 или 03), 08, 10, 14 и, при  необходимости, ограничительные отметки  для границ зон расположения реквизитов 11, 12, 13, 18, 19.

Для организаций  субъектов Российской Федерации, имеющих  наряду с государственным языком Российской Федерации государственный  язык субъекта Российской Федерации, целесообразно  использование продольного бланка; при этом реквизиты 08, 09, 14 печатают на двух языках: русском (слева) и национальном (справа) на одном уровне.

При изготовлении документов на двух и более страницах  вторую и последующие страницы нумеруют.

Номера  страниц проставляют посередине верхнего поля листа. 

 

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

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

• приложения  двухуровневые, состоящие из клиентской программы и сервера СУБД (никаких  трех- и более «уровневых» приложений, никаких 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 на стадии ТП. 

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

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

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