описание систем классификации и кодирования гост 34 пример
Документ «Описание систем классификации и кодирования»
УКАЗАНИЯ ГОСТ:
Настоящие методические указания распространяются на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т. п.), включая их сочетание, и устанавливают требования к содержанию документов, разрабатываемых при создании АС.
Описание систем классификации и кодирования
1 ПЕРЕЧЕНЬ ЗАРЕГИСТРИРОВАННЫХ КЛАССИФИКАТОРОВ, ПРИМЕНЯЕМЫХ В АС
ПРИМЕР СОДЕРЖАНИЯ:
1.1 Общероссийские классификаторы
1.2 Международные классификаторы
Зарегистрированные международные классификаторы в системе не используются.
Либо:
В АС Кадры используются следующие зарегистрированные международные классификаторы:
— ИСО 3166-93 «Коды для представления названий стран» (справочник «Страны»):
Объектами классификации являются суверенные государства или любые другие территории, имеющие политические, экономические, географические или исторические особенности и представляющие интерес с точки зрения внешнеторговых операций, и транспортных перевозок.
Объекты справочника используются при оформлении заявлений.
— т.д.
— пр.
1.3 Системные классификаторы
В АС Кадры используются следующие системные классификаторы:
— Справочник сотрудников;
— Справочник типов документов;
— т.д.;
— пр.
Справочник сотрудников содержит:
— Перечень подразделений организации;
— Перечень должностей;
— Перечень сотрудников и информацию о занимаемых должностях;
— Перечень ролей сотрудников.
Справочник типов документов содержит:
.
.
2 ОПИСАНИЕ МЕТОДА КОДИРОВАНИЯ
2.1 Классификатор стран мира
Классификатор состоит из следующих блоков:
— цифровой идентификации;
— наименования стран;
— буквенной идентификации.
Блок цифровой идентификации построен с использованием порядкового метода кодирования с применением трех цифровых десятичных знаков.
Блок наименования состоит из краткого и полного официального наименования страны (территории). Отсутствие в позиции классификатора полного наименования страны означает его совпадение с кратким наименованием.
Блок буквенной идентификации стран представляет собой трехзначный код, знаками которых являются буквы латинского алфавита.
Основным принципом, который использовался при создании буквенных кодов, является принцип визуальной ассоциации кодов с названиями стран на английском, французском или других языках.
Шаблон описания систем классификации и кодирования по ГОСТ 34
Структура и содержание документа
Требования к структуре описания систем классификации и кодирования по ГОСТ 34 устанавливаются РД 50-34.698-90. В общем случае документ должен состоять из следующих разделов:
1 Перечень зарегистрированных классификаторов, применяемых в АС
2 Описание метода кодирования
3 Структура и длина кода
4 Указания о системе классификации
5 Другие сведения
Содержание документов является общим для всех видов АС и, при необходимости, может дополняться разработчиком документов в зависимости от особенностей создаваемой АС. Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы.
Содержание документов, разрабатываемых на предпроектных стадиях по ГОСТ 34.601, и организационно-распорядительных определяют разработчики в зависимости от объема информации, необходимой и достаточной для дальнейшего использования документов.
Примечание
Оформление документа
Документ выполняют на формах, установленных соответствующими стандартами Единой системы конструкторской документации (ЕСКД).
Для размещения утверждающих и согласующих подписей к документу рекомендуется составлять титульный лист и (или) лист утверждения.
Текст документа при необходимости разделяют на разделы и подразделы. Разделы, подразделы должны иметь заголовки. Пункты, как правило, заголовков не имеют. Заголовки должны четко и кратко отражать содержание разделов, подразделов.
Текст документа должен быть кратким, четким и не допускать различных толкований.
Межгосударственный стандарт ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» (утв. постановлением Госстандарта СССР от 24 марта 1989 г. N 664)
1.2. На стадии «Техническое задание» разрабатывают Техническое задание (ТЗ) на создание автоматизированной системы в соответствии с требованиями ГОСТ 34.602.
Допускается разрабатывать частные ТЗ на отдельные системы (подсистемы, комплексы задач, программно-технические комплексы, компоненты технического и программного обеспечений и т. п.).
1.3. Виды документов, разрабатываемых на стадиях «Эскизный проект», «Технический проект», «Рабочая документация», приведены в табл. 1.
Перечисление в систематизированном виде объектов, предметов и т. д.
Графическое изображение форм документов, частей, элементов системы и связей между ними в виде условных обозначений
Изложение состава действий и правил их выполнения персоналом
Изложение сведений, подтверждающих целесообразность принимаемых решений
Пояснение назначения системы, ее частей, принципов их действия и условий применения
1.3.1. Наименования конкретных документов, разрабатываемых при проектировании системы в целом или ее части, приведены в табл. 2.
1.3.4. В зависимости от применяемых методов проектирования и специфики создаваемых АС допускается:
1) разрабатывать групповые и базовые документы в соответствии с разд. 1, 3, 4, 6 ГОСТ 2.113:
2) выпускать документы отдельными самостоятельными частями, соответствующими разделам основного документа;
3) расширять номенклатуру документов, установленную настоящим стандартом.
1.4. На стадии «Ввод в действие» разрабатывают следующие организационно-распорядительные документы:
1) акт завершения работ;
2) акт приемки в опытную эксплуатацию;
3) акт приемки в промышленную эксплуатацию;
4) план-график работ;
5) приказ о составе приемочной комиссии;
6) приказ о проведении работ;
8) протокол испытаний;
9) протокол согласования.
Ведомость эскизного проекта
Пояснительная записка к эскизному проекту
Схема организационной структуры
Допускается включать в документ ПЗ или ПВ
Схема структурная комплекса технических средств
Допускается включать в документ П9
Схема функциональной структуры
При разработке документов С0, C1, C2, С3 на стадии ЭП допускается их включение в документ П1
Перечень заданий на разработку специализированных (новых) технических средств
При разработке на стадии ТП допускается включать в документ П2
Технические задания на разработку специализированных (новых) технических средств
В состав проекта не входят
Задания на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы
В состав проекта не входят
Ведомость технического проекта
Ведомость покупных изделий
Перечень входных сигналов и данных
Перечень выходных сигналов (документов)
Перечень заданий на разработку строительных, электротехнических, сани- тарно-технических и других разделов проекта, связанных с созданием системы
Допускается включать в документ П2
Пояснительная записка к техническому проекту
Включает план мероприятий по подготовке объекта к вводу системы в эксплуатацию
Описание автоматизируемых функций
Описание постановки задач (комплекса задач)
Допускается включать в документы П2 или П3
Описание информационного обеспечения системы
Описание организации информационной базы
Описание систем классификации и кодирования
Описание массива информации
Описание комплекса технических средств
Для задачи допускается включать в документ 46 по ГОСТ 19.101
Описание программного обеспечения
Описание алгоритма (проектной процедуры)
Допускается включать в документы П2. ПЗ или П4
Описание организационной структуры
Допускается включать в документ П9
Ведомость оборудования и материалов
Локальный сметный расчет
Проектная оценка надежности системы
Чертеж формы документа (видеокадра)
На стадии ТП допускается включать в документы П4 или П5
Ведомость держателей подлинников
Ведомость эксплуатационных документов
Ведомость потребности в материалах
Ведомость машинных носителей информации
Массив входных данных
Каталог базы данных
Состав выходных данных (сообщений)
Методика (технология) автоматизированного проектирования
Инструкция по формированию и ведению базы данных (набора данных)
Инструкция по эксплуатации КТС
Схема соединения внешних проводок
Допускается выполнять в виде таблиц
Схема подключения внешних проводок
Таблица соединений и подключений
Схема деления системы (структурная)
Чертеж общего вида
Чертеж установки технических средств
Схема структурная комплекса технических средств
План расположения оборудования и проводок
Описание технологического процесса обработки данных (включая телеобработку)
Общее описание системы
Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем)
* Документы, код которых установлен в соответствии с требованиями стандартов ЕСКД.
3. Номенклатуру документов одного наименования устанавливают в зависимости от принятых при создании системы проектных решений.
4. Код (обозначение) документов, отмеченных в графе «Принадлежность к проектно-сметной документации» знаком X, может быть установлен по требованиям стандартов СПДС.
(Измененная редакция, Изм. N 1).
2. Комплектность документации
2.1. Перечень наименований разрабатываемых документов и их комплектность на систему и ее части должен быть определен в техническом задании на создание автоматизированной системы (подсистемы).
Примечание. Комплектность проектно-сметных документов определяют в соответствии с правилами, установленными системой проектной документации для строительства (СПДС).
2.2. На каждый комплект должна быть составлена ведомость документов.
2.5. При самостоятельной разработке части системы документы на нее комплектуют в соответствии с требованиями настоящего стандарта.
3. Обозначения документов
3.1. Каждому разработанному документу должно быть присвоено самостоятельное обозначение. Документ, выполненный на разных носителях данных, должен иметь одно обозначение. К обозначению документов, выполненных на машинных носителях, добавляют букву «М».
Заимствованным документам сохраняют ранее присвоенные обозначения.
3.2 Настоящие правила не распространяются на документы, правила обозначения которых регламентированы государственными стандартами других систем документации.
3.3. Обозначение документа имеет следующую структуру:
3.3.1. Правила обозначения системы (части системы) приведены в приложении 2.
Код документа отделяют от предыдущего обозначения точкой.
3.3.3. Порядковые номера документов одного наименования (2 знака) присваивают, начиная со второго, и отделяют от предыдущего обозначения точкой.
3.3.4. Номер редакции документа присваивают, начиная со второй в порядке возрастания от 2 до 9, и отделяют от предыдущего значения точкой. Очередной номер редакции присваивают в случаях сохранения (не аннулирования) предыдущей редакции.
3.3.5. Номер части документа отделяют от предыдущего обозначения дефисом. Если документ состоит из одной части, то дефис не проставляют и номер части документа не присваивают.
3.3.6. Признак документа, выполненного на машинных носителях, вводят при необходимости. Букву «М» отделяют от предыдущего обозначения точкой.
Откройте актуальную версию документа прямо сейчас или получите полный доступ к системе ГАРАНТ на 3 дня бесплатно!
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.
Межгосударственный стандарт ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» (утв. постановлением Госстандарта СССР от 24 марта 1989 г. N 664)
Дата введения 1 января 1990 г.
Текст стандарта приводится по официальному изданию Госстандарта России, ИПК Издательство стандартов
1. Разработан и внесен Государственным комитетом СССР по стандартам Министерством приборостроения, средств автоматизации и систем управления СССР
2. Утвержден и введен в действие Постановлением Государственного комитета СССР по стандартам от 24.03.89 N 664
4. Взамен ГОСТ 24.101-80, ГОСТ 24.102-80, РД 50-617-86
5. Ссылочные нормативно-технические документы
6. Издание с Изменением N 1, утвержденным в декабре 1990 г. (ИУС 4-91)
Документирование по ГОСТ 34* — это просто
Что такое стандарты на документацию?
В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:
Самый любимый и популярный стандарт по разработке ТЗ. Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований. Хотя бы в плане общей идеологии (о которой ниже)
Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.
Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.
Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.
К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.
Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.
Минусы стандартов
Основной минус всем очевиден — стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:
5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.
Смысл документа в том, что на советских предприятиях использовались так называемые «Участки печати», где стояли матричные скоростные принтеры, драйверы к которым часто писали сами инженеры. Поэтому они должны были поддерживать реестр всех документов, которые требовалось печатать для гарантии того, что в напечатанном виде документы будут выглядеть так, как положено.
«Видеокадр» — это тоже документ, который выводился на текстовый дисплей. Дисплеи не всегда поддерживали нужные символы и нужное количество символов по горизонтали и строк по вертикали (а графику вообще не поддерживали). Поэтому тут тоже надо было дополнительно согласовывать формы всех экранных документов.
Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.
Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.
Что в стандарте хорошо
Любой стандарт хорош уже тем, что он позволяет заказчику и исполнителю говорить на одном языке и дает гарантию, что, по крайней мере, претензий «по форме» к передаваемым результатам у заказчика не будет.
А стандарты ГОСТ 34 хороши еще и тем, что они составлялись умными людьми, обкатывались годами и у них есть четкая цель — максимально полно описать на бумаге сложную абстрактную сущность, которую представляет собой любая АСУ.
Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.
Как читать и понимать стандарты документации по ГОСТ серии 34
Стандарт делит все документы по двум осям — время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»
Стадии создания АСУ
Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:
Технический проект описывает будущую систему со всех ракурсов. Документы стадии ТП должны после прочтения оставлять после себя полную ясность в предлагаемых подходах, методах, архитектурных и технических решениях. На следующей фазе уже поздно будет описывать подходы и обосновывать технические решения, так что фаза П является ключом к успешной сдаче работ, так как все многообразие требований ТЗ должно находить отражение в документах фазы П. На этапе П система может вообще не существовать.
Рабочая документация предназначена для успешного развертывания, ввода в действие и дальнейшей эксплуатации новой системы. Это документы, содержащие совершенно конкретные сведения, описывающие физически существующие сущности, в отличие от фазы П, где описывается будущее великолепие.
Части (разделы) проектной документации по созданию АСУ
Предметная область разделена на «Обеспечения». Поначалу кажется, что такое деление избыточно и ненужно. Но когда начинаешь на практике работать этим инструментарием, постепенно доходит вложенная в него идеология.
Автоматизированная система в представлении составителей ГОСТ представляет собой совокупность железа, софта и каналов связи, которая обрабатывает приходящую из разных источников информацию в соответствии с некими алгоритмами и выдает результаты обработки в виде документов, структур данных или управляющих воздействий. Примитивная модель простейшего автомата.
Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):
Математическое обеспечение (МО), отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?
Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса — почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.
Информационное обеспечение (ИО). Еще один срез системы. На этот раз делается прозрачным черный ящик нашей системы и мы смотрим на циркулирующую в нем информацию. Представьте себе модель кровеносной системы человека, когда все остальные органы невидимы. Вот что-то подобное и есть Информационное обеспечение. В нем описываются состав и маршруты прохождения информации внутри и снаружи, логическая организация информации в системе, описание справочников и систем кодирования (кто делал программы для производства, тот знает, как они важны). Основная описательная часть приходится на этап ТП, но в этап РД перетекают некоторые «рудименты», наподобие документа «Каталог баз данных». Понятно, что раньше он содержал именно то, что написано в названии. Но сегодня попробуйте для сложной комплексной системы сформировать такой документ, когда очень часто в составе системы используются покупные подсистемы со своими загадочными информационными хранилищами. Я уж не говорю о том, что этот документ не особенно сейчас и нужен.
Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?
Короче, на фазе РД документы Информационного обеспечения представляют собой довольно зловредный рудимент, так как формально они быть должны, но наполнять их особенно нечем.
Программное обеспечение (ПО). Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.
В этом документе мы должны рассказать, при помощи каких программных средств выполняются алгоритмы, описанные в МО, обрабатывающие информацию, описанная в ИО. То есть, не нужно дублировать тут информацию из других разделов. Тут дается архитектура системы, обоснование выбранных программных технологий, их описание (всякие системные вещи: языки программирования, фреймворки, операционки и т.п.). Также в этом документе мы описываем как организованы средства обработки информации (очереди сообщений, хранилища, средства резервного копирования, решения по доступности, всякие пулы приложений и т.п.). В стандарте есть подробнейшее описание содержания этого документа, которое поймет любой специалист.
Техническое обеспечение (ТО). Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП.
Дело в том, что стандарт предусматривает описание всего технического обеспечения, включая компьютерное «железо» и сети, инженерные системы и даже строительную часть (если потребуется). А это хозяйство регламентируется громадным количеством стандартов и нормативных актов, согласуется в разных организациях и поэтому удобнее все дробить на части и согласовывать (править) по частям. В то же время стандарт позволяет объединять некоторые документы друг с другом, что имеет смысл делать, если всю кучу согласует один человек.
Не забывайте также, что комплекс стандартов качества подразумевает учет и хранение технических документов, и наши «книжицы» у заказчика могут разойтись по разным архивам, в зависимости от предмета описания. Это еще один аргумент в пользу дробления документации.
Организационное обеспечение (ОО). Подавив в себе нормальное для технаря желание проскочить этот раздел поскорее, наоборот, рассмотрю его более подробно. Так как, коллеги, в последнее время на проектах наметились нехорошие тенденции, которые требуют внесения ясности именно в этот раздел.
На стадии ТП раздел содержит всего один документ «Описание организационной структуры», в котором мы должны рассказать заказчику, к чему он должен готовиться в плане изменения оргштатной структуры. Вдруг требуется организовать новый отдел для эксплуатации вашей системы, ввести новые должности и т.п.
На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.
Руководство пользователя. Комментарии излишни, я думаю.
Методика (технология) автоматизированного проектирования. В этот документ при необходимости можно поместить описание процесса сборки ПО, управления версиями, тестирования и т.п. Но это если в ТЗ заказчик желает самолично осуществлять сборку ПО. Если он этого не требует (и не платит за это), то вся ваша внутренняя кухня не его ума дело, и этот документ делать не нужно.
Технологическая инструкция. В связи с модой на формализацию бизнес процессов, в этот документ ушлый заказчик иногда стремится запихнуть регламенты работы службы эксплуатации. Так вот, делать этого ни в коем случае не нужно.
Описание бизнес-процессов, ролевые и должностные инструкции, регламенты работы — все это ОРД, то есть организационно-распорядительная документация. Которая является продуктом консалтингового проекта, который у вас, насколько я понимаю, не покупали. А покупали у вас проект технический и документацию к нему тоже техническую.
Технологическая инструкция является прослойкой между ОРД и руководством пользователя. РП подробно описывает как нужно делать те или иные действия в системе. Технологическая инструкция говорит о том, какие действия необходимо выполнять в тех или иных случаях, связанных с эксплуатацией системы. Грубо говоря, технологическая инструкция это краткий дайджест по РП для конкретной должности или роли. Если у заказчика роли не сформированы или он хочет, чтобы вы сами сформировали роли и требования к должностям, включите в документ самые базовые роли, например: оператор, старший оператор, администратор. Замечания заказчика на тему, «а у нас не так» или «а нам не нравится» должны сопровождаться перечнем ролей и описанием должностных обязанностей. Потому что бизнес-процессы мы не ставим. Мы эти бизнес-процессы автоматизируем.
Об описанных граблях я еще напишу отдельно, с красочными примерами, так как это повторяется уже не первый раз и в разных отраслях «народного хозяйства».
Описание технологического процесса обработки данных (включая телеобработку). Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция — для них. Что в нее писать в XXI веке — я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.
Общесистемные решения (ОР). Стандартом предусмотрено 17 документов раздела ОР. Во-первых, это почти все документы предварительной фазы Эскизного проектирования. Во-вторых, это всевозможные сметы, расчеты и краткие описание автоматизируемых функций. То есть, информация для людей не с основного ИТ-производства, а для вспомогательного персонала — менеджеров, сметчиков, специалистов по закупкам, экономистов и т.п.
А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.
Варианты использования ГОСТ 34
Заключение
Эта статья была о наших ГОСТах на документирование АСУ. ГОСТы старые, но, как оказалось, до сих пор очень даже полезные в хозяйстве. Не считая некоторые явные рудименты, структура документации обладает свойствами полноты и непротиворечивости, а следование стандарту снимает многие проектные риски, о существовании которых мы можем по началу не догадываться.
Надеюсь, изложенный материал был вам полезен, или, как минимум, интересен. Несмотря на внешнюю скуку, документирование является важной и ответственной работой, аккуратность в которой так же важна, как и при написании хорошего кода. Пишите хорошие документы, коллеги! А я на следующей неделе отправляюсь в две подряд командировки, так что публикацию новых материалов не гарантирую (загашника у меня нет, пишу из головы).