ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов
Код страны-разработчика и код организации-разработчика присваивают в установленном порядке.
· Регистрационный номер присваивается в порядке возрастания, начиная с 00001 до 99999, для каждой организации-разработчика.
· Номер издания программы или номер редакции, номер документа данного вида, номер части документа присваиваются в порядке возрастания с 01 до 99. (Если документ состоит из одной части, то дефис и порядковый номер части не указывают).
· Номер редакции спецификации и ведомости эксплуатационных документов на программу должны совпадать с номером издания этой же программы.
ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам
Настоящий стандарт устанавливает общие требования к оформлению программных документов для вычислительных машин, комплексов и систем, независимо от их назначения и области применения и предусмотренных стандартами Единой системы программной документации (ЕСПД) для любого способа выполнения документов на различных носителях данных.
Программный документ может быть представлен на различных типах носителей данных и состоит из следующих условных частей: титульной;
информационной; основной.
Правила оформления документа и его частей на каждом носителе данных устанавливаются стандартами ЕСПД на правила оформления документов на соответствующих носителях данных.
Стандарт ГОСТ 19.402-78 ЕСПД. Описание программы ориентирован на документирование результирующего продукта разработки.
Состав документа "Описание программы" в своей содержательной части может дополняться разделами и пунктами, почерпнутыми из стандартов для других описательных документов и руководств: ГОСТ 19.404-79 ЕСПД. Пояснительная записка, ГОСТ 19.502-78 ЕСПД. Описание применения, ГОСТ 19.503-79 ЕСПД. Руководство системного программиста, ГОСТ 19.504-79 ЕСПД. Руководство программиста, ГОСТ 19.505-79 ЕСПД. Руководство оператора.
Есть также группа стандартов, определяющая требования к фиксации всего набора программ и ПД, которые оформляются для передачи ПС. Они порождают лаконичные документы учетного характера и могут быть полезны для упорядочения всего хозяйства программ и ПД. Есть стандарты, определяющие правила ведения документов в "хозяйстве" ПС.
ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний, который может использоваться для разработки документов планирования и проведения испытательных работ по оценке готовности и качества ПС.
ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Обозначения условные графические и правила выполнения.
Он устанавливает правила выполнения схем, используемых для отображения различных видов задач обработки данных и средств их решения и полностью соответствует стандарту ИСО 5807:1985.
Наряду с ЕСПД на межгосударственном уровне действуют еще два стандарта, относящихся к документированию ПС:
ГОСТ 19781-90 Обеспечение систем обработки информации программное. Термины и определения. Разработан взамен ГОСТ 19.781-83 и ГОСТ 19.004-80 и устанавливает термины и определения понятий в области программного обеспечения (ПО) систем обработки данных (СОД), применяемые во всех видах документации и литературы, входящих в сферу работ по стандартизации или использующих результаты этих работ.
ГОСТ 28388-89 Системы обработки информации. Документы на магнитных носителях данных. Порядок выполнения и обращения. Распространяется не только на программные, но и на конструкторские, технологические и другие проектные документы, выполняемые на магнитных носителях.
Стандарты комплекса ГОСТ 34
ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Объектами стандартизации являются АС различных видов и все виды их компонентов, а не только ПО и БД.
Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO12207 предусмотрено, что заказчик может разрабатывать АС для себя сам (если создаст для этого специализированное подразделение). Однако формулировки ГОСТ 34 не ориентированы на столь явное и, в известном смысле, симметричное отражение действий обеих сторон, как ISO12207. Поскольку ГОСТ 34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно делается отталкиваясь от этого содержания.
Из всех существующих и не реализованных групп документов будем основываться только на Группе 0 "Общие положения" и Группе 6 "Создание, функционирование и развитие АС". Наиболее популярными являются стандарты ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС) и методические указания РД 50-34.698-90 (Требования к содержанию документов). Стандарты предусматривают стадии и этапы выполнения работ по созданию АС, но не предусматривают сквозных процессов в явном виде.
Для общего случая разработки АС стадии и этапы ГОСТ 34 приведены в таблице:
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. Послегарантийное обслуживание. |
Описано содержание документов, разрабатываемых на каждом этапе. Это определяет потенциальные возможности выделения на содержательном уровне сквозных работ, выполняемых параллельно или последовательно, и составляющих их задач. Такой прием может использоваться при построении профиля стандартов ЖЦ проекта, включающего согласованные подмножества стандартов ГОСТ 34 и ISO12207.
Главный мотив: разрешить проблему "вавилонской башни".
В 80-х годах сложилось положение, при котором в различных отраслях и областях деятельности использовалась плохо согласованная или несогласованная НТД - "нормативно-техническая документация". Это затрудняло интеграцию систем, обеспечение их эффективного совместного функционирования. Действовали различные комплексы и системы стандартов, устанавливающие требования к различным видам АС.
Практика применения стандартов показала, что в них применяется по существу (но не по строгим определениям) единая система понятий, есть много общих объектов стандартизации, однако требования стандартов не согласованы между собой, имеются различия по составу и содержанию работ, различия по обозначению, составу, содержанию и оформлению документов и пр.
Эта ситуация отчасти отражала и естественное многообразие условий разработки АС, целей разработчиков, применяемых подходов и методик.
В этих условиях можно было провести анализ такого многообразия и далее поступить, например, одним из двух во многом противоположных способов:
1. Выработать одну обобщенную понятийную и терминологическую систему, общую схему разработки, общий набор документов с их содержанием и определить их как обязательные для всех АС;
2. Определить одну общую понятийную и терминологическую систему, обобщенный комплекс системных требований, набор критериев качества, но предоставить максимальную свободу в выборе схемы разработки, состава документов и других аспектов, наложив минимум обязательных требований, которые позволяли бы:
· определять уровень качества результата;
· выбирать те конкретные методики (с их моделями ЖЦ, набором документов и др.), которые наиболее подходят к условиям разработки и соответствуют используемым Информационным Технологиям;
· работать, таким образом, с минимальными ограничениями эффективных действий проектировщика АС.
Разработчики комплекса стандартов 34 выбрали способ, близкий к первому и пошли по пути, более близкому к схемам конкретных методик, чем к стандартам типа ISO12207. Тем не менее, благодаря общности понятийной базы стандарты остаются применимыми в весьма широком диапазоне случаев.
Степень адаптивности формально определяется возможностями:
· опускать стадию эскизного проектирования и объединять стадии "Технический проект" и "Рабочая документация";
· опускать этапы, объединять и опускать большинство документов и их разделов;
· вводить дополнительные документы, разделы документов и работы;
· динамически создавая ЧТЗ - частные технические задания - достаточно гибко формировать ЖЦ АС; этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.
Стадии и этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании, что близко к подходу ISO.
Введение единой, достаточно качественно определенной терминологии, наличие достаточно разумной классификации работ, документов, видов обеспечения и др. безусловно, полезно. ГОСТ 34 способствует более полной и качественной стыковке разных систем, что особенно важно в условиях, когда разрабатывается все больше сложных комплексных АС, например, типа CAD-CAM, которые включают в свой состав АСУТП, АСУП, САПР-конструктора, САПР-технолога, АСНИ и др. системы.
Определено несколько важных положений, отражающих особенности АС как объекта стандартизации, например: "в общем случае АС состоит из программно-технических (ПТК), программно-методических (ПМК) комплексов и отдельных компонентов организационного, технического, программного и информационного обеспечения".
Разделение понятий ПТК и АС закрепляло принцип, по которому АС есть не "ИС с БД", но:
· "организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях" (по РД 50-680-88), что особенно актуально в аспектах бизнес-реинжиниринга;
· "система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций" (по ГОСТ 34.003-90).
Эти определения указывают на то, что АС - это, в первую очередь, персонал, принимающий решения и выполняющий другие управляющие действия, поддержанный организационно-техническими средствами.
Степень обязательности: прежняя полная обязательность отсутствует, материалы ГОСТ34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС. При этом польза ГОСТ34 может многократно возрасти в случае их более гибкого использования при формировании профиля ЖЦ АС.
Ключевым документом взаимодействия сторон является ТЗ - техническое задание на создание АС. ТЗ является основным исходным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88).