В своем докладе я опираюсь на:
Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы:
Кроме упомянутых вопросов есть и другие.
На эти и массу других вопросов когда-то отвечали государственные стандарты на программную документацию? комплекс стандартов 19-й серии ГОСТ ЕСПД. Но уже тогда у программистов была масса претензий к этим стандартам. Что-то требовалось дублировать в документации много раз (как, казалось - неоправданно), а многое не было предусмотрено, как, например, отражение специфики документирования программ, работающих с интегрированной базой данных.
В настоящее время остается актуальным вопрос о наличии системы, регламентирующей документирование программных средств (ПС).
Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации.
Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС. Следует отметить, что стандарты ЕСПД (ГОСТ 19) носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПС (ГОСТ 34, Международному стандарту ISO/IEC, и др.). Дело в том, что в соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе - то есть при ссылке на них в договоре на разработку (поставку) ПС.
Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела.
К числу основных недостатков ЕСПД можно отнести:
Итак, ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы жизненного цикла ПС об этом стандарте далее будет сказано подробнее).
Надо сказать, что наряду с комплексом ЕСПД официальная нормативная база РФ в области документирования ПС и в смежных областях включает ряд перспективных стандартов (отечественного, межгосударственного и международного уровней).
Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию ЖЦ продуктов программного обеспечения (ПО) - казалось бы весьма неконкретный, но вполне новый и отчасти "модный" стандарт.
Стандарты комплекса ГОСТ 34 на создание и развитие автоматизированных систем (АС) - обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации. Но эти стандарты многими считаются бюрократическими до вредности и консервативными до устарелости. Насколько это так, а насколько ГОСТ 34 остается работающим с пользой - полезно разобраться.
В своей статье Е.З.Зиндер подробно останавливается на методике Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle.
Тем не менее, до пересмотра всего комплекса, многие стандарты ЕСПД могут с пользой применяться в практике документирования ПС. Эта позиция основана на следующем:
При этом стиль применения стандартов может соответствовать современному общему стилю адаптации стандартов к специфике проекта: заказчик и руководитель проекта выбирают уместное в проекте подмножество стандартов и ПД, дополняют выбранные ПД нужными разделами и исключают ненужные, привязывают создание этих документов к той схеме ЖЦ, которая используется в проекте.
Стандарты ЕСПД (как и другие ГОСТы) подразделяют на группы, приведTнные в таблице:
Обозначение стандарта ЕСПД строят по классификационному признаку:
Обозначение стандарта ЕСПД должно состоять из:
Перечень документов ЕСПД
Термины и определения
Из всех стандартов ЕСПД остановимся только на тех, которые могут чаще использоваться на практике.
Первым укажем стандарт, который можно использовать при формировании заданий на программирование.
ГОСТ (СТ СЭВ) 19.201-78 (1626-79). ЕСПД. Техническое задание. Требование к содержанию и оформлению. (Переиздан в ноябре 1987г с изм.1).
Техническое задание (ТЗ) содержит совокупность требований к ПС и может использоваться как критерий проверки и приемки разработанной программы. Поэтому достаточно полно составленное (с учетом возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком, ТЗ является одним из основополагающих документов проекта ПС.
Техническое задание должно содержать следующие разделы:
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.
Следующий стандарт
ГОСТ (СТ СЭВ) 19.101-77 (1626-79). ЕСПД. Виды программ и программных документов (Переиздан в ноябре 1987г с изм.1).
Устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Виды программ
Виды программных документов
Вид программного документа |
|
Спецификация | Состав программы и документации на нее |
Перечень предприятий, на которых хранят подлинники программных документов | |
Текст программы | Запись программы с необходимыми комментариями |
Описание программы | Сведения о логической структуре и функционировании программы |
Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля | |
Техническое задание | Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний |
Пояснительная записка | Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений |
Эксплуатационные документы | Сведения для обеспечения функционирования и эксплуатации программы |
Виды эксплуатационных документов
Вид эксплуатационного документа |
|
Перечень эксплуатационных документов на программу | |
Формуляр | Основные характеристики программы, комплектность и сведения об эксплуатации программы |
Описание применения | Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств |
Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения | |
Руководство программиста | Сведения для эксплуатации программы |
Руководство оператора | Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы |
Описание языка | Описание синтаксиса и семантики языка |
Сведения для применения тестовых и диагностических программ при обслуживании технических средств |
В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы.
Виды программных документов, разрабатываемых на разных стадиях, и их коды
Код вида документа | Вид документа | Стадии разработки | |||
Эскизный проект | Технический проект | Рабочий проект | |||
компонент | комплекс | ||||
- | Спецификация | - | - | ! | + |
05 | Ведомость держателей подлинников | - | - | - | ? |
12 | Текст программы | - | - | + | ? |
13 | Описание программы | - | - | ? | ? |
20 | Ведомость эксплуатационных документов | - | - | ? | ? |
30 | Формуляр | - | - | ? | ? |
31 | Описание применения | - | - | ? | ? |
32 | Руководство системного программиста | - | - | ? | ? |
33 | Руководство программиста | - | - | ? | ? |
34 | Руководство оператора | - | - | ? | ? |
35 | Описание языка | - | - | ? | ? |
46 | Руководство по техническому обслуживанию | - | - | ? | ? |
51 | Программа и методика испытаний | - | - | ? | ? |
81 | Пояснительная записка | ? | ? | - | - |
90-99 | Прочие документы | ? | ? | ? | ? |
Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ.
Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения
Стадии разработки, этапы и содержание работ
Стадии разработки |
Этапы работ |
|
Техническое задание | Обоснование необходимости разработки программы | Постановка задачи. Сбор исходных материалов. Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ. |
Научно-исследовательские работы | Определение структуры входных и выходных данных. Предварительный выбор методов решения задач. Обоснование целесообразности применения ранее разработанных программ. Определение требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи. |
|
Разработка и утверждение технического задания | Определение требований к программе. Разработка технико-экономического обоснования разработки программы. Определение стадий, этапов и сроков разработки программы и документации на нее. Выбор языков программирования. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания. |
|
Эскизный проект | Разработка эскизного проекта | Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи. Разработка технико-экономического обоснования. |
Утверждение эскизного проекта | Согласование и утверждение эскизного проекта |
|
Технический проект | Разработка технического проекта | Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств. |
Утверждение технического проекта | Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта. |
|
Рабочий проект | Разработка программы | Программирование и отладка программы |
Разработка программной документации | Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77. | |
Испытания программы | Разработка, согласование и утверждение программы и методики испытаний. Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний. |
|
Внедрение | Подготовка и передача программы | Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ. |
Примечания:
Код страны-разработчика и код организации-разработчика присваивают в установленном порядке.
Настоящий стандарт устанавливает общие требования к оформлению программных документов для вычислительных машин, комплексов и систем, независимо от их назначения и области применения и предусмотренных стандартами Единой системы программной документации (ЕСПД) для любого способа выполнения документов на различных носителях данных.
Программный документ может быть представлен на различных типах носителей данных и состоит из следующих условных частей:
титульной;
информационной;
основной.
Правила оформления документа и его частей на каждом носителе данных устанавливаются стандартами ЕСПД на правила оформления документов на соответствующих носителях данных.
Программные документы оформляют:
Расположение материалов программного документа осуществляется в следующей последовательности:
Титульная часть:
Перечень терминов и их определений, перечень сокращений, приложения, предметных указатель, перечень ссылочных документов выполняются при необходимости.
Следующий стандарт ориентирован на документирование результирующего продукта разработки:
Состав документа "Описание программы" в своей содержательной части может дополняться разделами и пунктами, почерпнутыми из стандартов для других описательных документов и руководств: ГОСТ 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 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Мотивы и получившиеся результаты описаны ниже в "Особенностях" ГОСТ 34. Объектами стандартизации являются АС различных (любых!) видов и все виды их компонентов, а не только ПО и БД.
Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично 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-х годах сложилось положение, при котором в различных отраслях и областях деятельности использовалась плохо согласованная или несогласованная НТД - "нормативно-техническая документация". Это затрудняло интеграцию систем, обеспечение их эффективного совместного функционирования. Действовали различные комплексы и системы стандартов, устанавливающие требования к различным видам АС.
Практика применения стандартов показала, что в них применяется по существу (но не по строгим определениям) единая система понятий, есть много общих объектов стандартизации, однако требования стандартов не согласованы между собой, имеются различия по составу и содержанию работ, различия по обозначению, составу, содержанию и оформлению документов и пр.
Конечно, эта ситуация отчасти отражала и естественное многообразие условий разработки АС, целей разработчиков, применяемых подходов и методик.
В этих условиях можно было провести анализ такого многообразия и далее поступить, например, одним из двух во многом противоположных способов:
Разработчики комплекса стандартов 34 выбрали способ, близкий к первому из указанных выше, то есть пошли по пути, более близкому к схемам конкретных методик, чем к стандартам типа ISO12207. Тем не менее, благодаря общности понятийной базы стандарты остаются применимыми в весьма широком диапазоне случаев.
Степень адаптивности формально определяется возможностями:
Стадии и этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании, что близко к подходу ISO.
Введение единой, достаточно качественно определенной терминологии, наличие достаточно разумной классификации работ, документов, видов обеспечения и др. безусловно полезно. ГОСТ 34 способствует более полной и качественной стыковке действительно разных систем, что особенно важно в условиях, когда разрабатывается все больше сложных комплексных АС, например, типа CAD-CAM, которые включают в свой состав АСУТП, АСУП, САПР-конструктора, САПР-технолога, АСНИ и др. системы.
Определено несколько важных положений, отражающих особенности АС как объекта стандартизации, например: "в общем случае АС состоит из программно-технических (ПТК), программно-методических (ПМК) комплексов и отдельных компонентов организационного, технического, программного и информационного обеспечения".
Разделение понятий ПТК и АС закрепляло принцип, по которому АС есть не "ИС с БД", но:
Эти определения указывают на то, что АС - это, в первую очередь, персонал, принимающий решения и выполняющий другие управляющие действия, поддержанный организационно-техническими средствами.
Степень обязательности:
прежняя полная обязательность отсутствует, материалы ГОСТ34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС. При этом польза ГОСТ34 может многократно возрасти в случае их более гибкого использования при формировании профиля ЖЦ АС.
Ключевым документом взаимодействия сторон является ТЗ - техническое задание на создание АС. ТЗ является основным исходным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88).
В РФ действует ряд стандартов в части документирования ПС, разработанных на основе прямого применения международных стандартов ИСО. Это? самые "свежие" по времени принятия стандарты. Некоторые из них впрямую адресованы руководителям проекта или директорам информационных служб. Вместе с тем они неоправданно мало известны в среде профессионалов. Вот их представление.
ГОСТ Р ИСО/МЭК 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения. Стандарт полностью соответствует международному стандарту ИСО/МЭК ТО 9294:1990 и устанавливает рекомендации по эффективному управлению документированием ПС для руководителей, отвечающих за их создание. Целью стандарта является оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования.
ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. Стандарт полностью соответствует международному стандарту ИСО/МЭК 9126:1991. В его контексте под характеристикой качества понимается "набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается". Стандарт определяет шесть комплексных характеристик, которые с минимальным дублированием описывают качество ПС (ПО, программной продукции): функциональные возможности; надежность; практичность; эффективность; сопровождаемость; мобильность. Эти характеристики образуют основу для дальнейшего уточнения и описания качества ПС.
ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов. Стандарт полностью соответствует международному стандарту ИСО 9127:1989. В контексте настоящего стандарта под потребительским программным пакетом (ПП) понимается "программная продукция, спроектированная и продаваемая для выполнения определенных функций; программа и соответствующая ей документация, упакованные для продажи как единое целое". Под документацией пользователя понимается документация, которая обеспечивает конечного пользователя информацией по установке и эксплуатации ПП. Под информацией на упаковке понимают информацию, воспроизводимую на внешней упаковке ПП. Ее целью является предоставление потенциальным покупателям первичных сведений о ПП.
ГОСТ Р ИСО/МЭК 8631-94 Информационная технология. Программные конструктивы и условные обозначения для их представления. Описывает представление процедурных алгоритмов.
Первая редакция ISO12207 подготовлена в 1995 году объединенным техническим комитетом ISO/IEC JTC1 "Информационные технологии, подкомитет SC7, проектирование программного обеспечения".
По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые!) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.
Очень важные ЗАМЕЧАНИЯ СТАНДАРТА:
ОПРЕДЕЛЕНИЯ СТАНДАРТА:
Стандарт не предписывает конкретную модель ЖЦ или метод разработки ПО, но определяет, что стороны-участники использования стандарта ответственны за выбор модели ЖЦ для проекта ПО, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение методов разработки ПО, за выполнение действий и задач, подходящих для проекта ПО.
Стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.
Каждый процесс ЖЦ разделен на набор действий, каждое действие - на набор задач. Очень важное отличие ISO: каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).
В стандарте ISO12207 описаны:
К ним примыкает особый Процесс адаптации, который определяет основные действия, необходимые для адаптации стандарта к условиям конкретного проекта.
Под процессом усовершенствования здесь понимается не усовершенствование АС или ПО, а улучшение самих процессов приобретения, разработки, гарантирования качества и т. п., реально осуществляемых в организации.
Каких-либо этапов, фаз, стадий не предусмотрено, что дает описываемую ниже степень адаптивности.
"Динамический" характер стандарта определяется способом определения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть.
Такой характер позволяет реализовывать любую модель ЖЦ.
При выполнении анализа требований к ПО предусмотрено 11 классов характеристик качества, которые используются позже при гарантировании качества.
При этом разработчик должен установить и документировать как требования к программному обеспечению:
(Интересно и важно, что эти и аналогичные характеристики хорошо корреспондируются с характеристиками АС, предусматриваемыми в ГОСТ 34 по видам обеспечения системы.)
Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД, но и не использовать
Итак, ISO12207 имеет набор процессов, действий и задач, охватывающий наиболее широкий спектр возможных ситуаций при максимальной адаптируемости.
Он показывает пример того, как должен строиться хорошо организованный стандарт, содержащий минимум ограничений (принцип "нет одинаковых проектов"). При этом детальные определения процессов, форм документов и т. п. целесообразно выносить в различные функциональные стандарты, ведомственные нормативные документы или фирменные методики, которые могут быть использованы или не использованы в конкретном проекте.
По этой причине центральным стандартом, положения которого берутся за начальный "стержневой" набор положений в процессе построения профиля стандартов ЖЦ для конкретного проекта, полезно рассматривать именно ISO12207. Этот "стержень" может задавать модель ЖЦ ПО и АС, принципиальную схему гарантирования качества, модель управления проектом
Практики используют еще один путь: сами переводят и используют в своих проектах современные стандарты на организацию ЖЦ ПС и их документирование. Но этот путь страдает как минимум тем недостатком, что разные переводы и адаптации стандартов, сделанные разными разработчиками и заказчиками, будут отличаться массой деталей. Эти отличия неизбежно касаются не только наименований, но и их содержательных определений, вводимых и используемых в стандартах. Таким образом, на этом пути неизбежно постоянное возникновение путаницы, а это прямо противоположно целям не только стандартов, но и любых грамотных методических документов.
В настоящее время во ВНИИ стандартов подготовлены предложения по совершенствованию и развитию комплекса стандартов по документированию ПС.
Для приобретения стандартов в области документирования рекомендуем обращаться в следующие организации:
ИПК "Издательство стандартов" , Территориальный отдел распространения НТД (магазин "Стандарты"), 17961, Москва, ул. Донская, д. 8, тел. 236-50-34, 237-00-02, факс/тел. 236-34-48 (в части ГОСТ и ГОСТ Р).
Система технической документации на АСУ |
ГОСТ 24.207-80 |
ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ ПО ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ |
|
System of technical documentation for computer control systems. Requirements for contents of documents on software |
Постановлением Государственного комитета СССР по стандартам от 14 мая 1980 г. № 2101 срок введения установлен
с 01.01 1981 г.
Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления (кроме общегосударственного), и устанавливает требования к содержанию документов, входящих в соответствии с ГОСТ 24.101-80 в состав документации программного обеспечения в проектах АСУ.
1.1. Документация программного обеспечения предназначена:
1.2. При разработке документов на части АСУ содержание разделов каждого документа ограничивают рамками соответствующей части.
1.3. В зависимости от назначения и специфических особенностей создаваемых АСУ допускается включать в документы дополнительные разделы, требования к содержанию которых не установлены настоящим стандартом. Отсутствие проектных решений по разделу документа фиксируют в соответствующем разделе с необходимыми пояснениями.
1.4. Требования к содержанию документов «Техническое задание», «Пояснительная записка», «Описание применения», «Спецификация», «Руководство оператора», «Текст программы», «Формуляр», «Порядок и методика испытаний» установлены ГОСТ 19.201-78 , ГОСТ 19.404-79 , ГОСТ 19.502-78 , ГОСТ 19.202-78 , ГОСТ 19.505-79 , ГОСТ 19.401-78 , ГОСТ 19.501-78 и ГОСТ 19.301-79 .
(Измененная редакция, Изм. № 1).
2.1.1. Документ должен содержать вводную часть и разделы:
2.1.2. Вводная часть должна содержать основные сведения о техническом, информационном и других видах обеспечения АСУ, необходимые для разработки программного обеспечения, или ссылку на соответствующие документы проекта АСУ.
2.1.3. Раздел «Структура программного обеспечения» должен содержать перечень частей программного обеспечения с указанием их взаимосвязей и обоснованием выделения каждой из них.
2.1.4. Раздел «Основные функции частей программного обеспечения» должен содержать подразделы, в которых для каждой части программного обеспечения приводят назначение и описание основных функций
(Измененная редакция, Изм. № 1).
2.1.5. Раздел «Методы и средства разработки программного обеспечения» должен содержать перечень методов программирования и средств разработки программного обеспечения АСУ с указанием частей программного обеспечения, при разработке которых следует использовать соответствующие методы и средства.
2.1.6. Раздел «Операционная система» должен содержать:
2.1.7. Раздел «Средства, расширяющие возможности операционной системы» должен содержать подразделы, в которых для каждого используемого средства, расширяющего возможности операционной системы, следует указать:
2.2.2. Для программы (комплекса программ), получаемой за счет использования ранее разработанных программных средств, документ «Описание программы» следует дополнять разделом «Настройка программных средств».
2.2.3. Раздел «Настройка программных средств» должен содержать:
2.3.1. Документ по составу разделов и их содержанию должен соответствовать ГОСТ 19.504-79 и, кроме того, включать раздел «Сведения о форме представления программы (комплекса программ)».
2.3.2. Раздел «Сведения о форме представления программы (комплекса программ)» должен содержать сведения о носителе, на котором записана программа, о содержании и системе кодирования информации, записанной на носителе, а также сведения, необходимые для чтения информации с носителя.
2.3.3. Для программы (комплекса программ), допускающей настройку на условия конкретного применения, в документ «Руководство программиста» включают разделы:
2.3.4. Разрешается для программы (комплекса программ), допускающей настройку на условия конкретного применения, вместо разделов, перечисленных в п. 2.3.3, разрабатывать отдельный документ «Руководство системного программиста», удовлетворяющий требованиям ГОСТ 19.503-79 .
2.4.1. Документ должен содержать разделы:
2.4.2. Раздел «Назначение» должен содержать перечень параметров и краткую характеристику функции, из числа реализуемых программой (комплексом программ), проверяемых контрольным примером.
2.4.3. Раздел «Исходные данные» должен содержать описание исходных данных для проверки программы (комплекса программ) с приведением исходных данных. Допускается исходные данные представлять в виде распечатки с АЦПУ.
2.4.4. Раздел «Результаты расчета» должен содержать результаты обработки исходных данных программой (комплексом программ), позволяющие оценить правильность выполнения проверяемых функции и значение проверяемых параметров. Допускается результаты расчета приводить в виде распечатки с АЦПУ.
2.4.5. Раздел «Проверка программы (комплекса программ)» должен содержать:
Наименование:
Единая система программной документации.
Действует
Дата введения:
Дата отмены:
Заменен на:
ГОСТ 19.101-77
МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ
ЕДИНАЯ СИСТЕМА ПРОГРАММНОЙ ДОКУМЕНТАЦИИ
Издание официальное
Стандартинформ
УДК 002:651.7/.78:006.354
Группа Т55
Unified system for program documentation.
Types of programs and program documents
Постановлением Государственного комитета стандартов Совета Министров СССР от 20 мая 1977 г. № 1268 дата введения установлена
Настоящий стандарт устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Стандарт полностью соответствует СТ СЭВ 1626-79.
(Измененная редакция, Изм. № 1).
1.1. Программу (по ГОСТ 19781-90) допускается идентифицировать и применять самостоятельно и (или) в составе других программ.
1.2. Программы подразделяют на виды, приведенные в табл. 1.
1.3. Документация, разработанная на программу, может использоваться для реализации и передачи программы на носителях данных, а также для изготовления программного изделия.
2.1. К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.
2.2. Виды программных документов и их содержание приведены в табл. 2.
Издание официальное ★
Перепечатка воспрещена
) Издательство стандартов, 1977 © СТАНДАРТИНФОРМ, 2010
Издание (январь 2010 г.) с Изменением № 1, утвержденным в июне 1981 г. (ИУС 9-81).
Таблица 2
Вид программного документа | |
Спецификация |
Состав программы и документации на нее |
Ведомость держателей подлин- |
Перечень предприятий, на которых хранят подлинники программ- |
ных документов |
|
Текст программы |
Запись программы с необходимыми коментариями |
Описание программы |
Сведения о логической структуре и функционировании программы |
Программа и методика испыта- |
Требования, подлежащие проверке при испытании программы, а также |
порядок и методы их контроля |
|
Техническое задание |
Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний |
Пояснительная записка |
Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений |
Эксплуатационные документы |
Сведения для обеспечения функционирования и эксплуатации программы |
2.3. Виды эксплуатационных документов и их содержание приведены в табл. 3.
Таблица 3
эксплуатационного документа
Ведомость эксплуатационных документов Формуляр
Описание применения
Руководство программиста Руководство оператора
Описание языка Руководство по техническому обслуживанию
Перечень эксплуатационных документов на программу
Основные характеристики программы, комплектность и сведения об эксплуатации программы
Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств
Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения
Сведения для эксплуатации программы
Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы
Описание синтаксиса и семантики языка
Сведения для применения тестовых и диагностических программ при обслуживании технических средств
2.4. В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы.
2.5. Виды программных документов, разрабатываемых на разных стадиях, и их коды приведены в табл. 4.
Таблица 4
Код вида документа |
Вид документа |
Стадии разработки |
|||
Эскизный |
Технический |
Рабочий проект |
|||
компонент |
комплекс |
||||
Спецификация | |||||
Ведомость держателей подлин- | |||||
Текст программы | |||||
Описание программы | |||||
Ведомость эксплуатационных | |||||
документов | |||||
Формуляр |
Продолжение таблицы 4
Код вида документа |
Стадии разработки | ||||
Вид документа |
Эскизный |
Технический |
Рабочий проект |
||
компонент |
комплекс |
||||
Описание применения | |||||
Руководство системного программиста | |||||
Руководство программиста | |||||
Руководство оператора | |||||
Описание языка | |||||
Руководство по техническому обслуживанию | |||||
Программа и методика испытаний | |||||
Пояснительная записка | |||||
Прочие документы |
Условные обозначения:
Документ обязательный;
С - документ обязательный для компонентов, имеющих самостоятельное применение;
О - необходимость составления документа определяется на этапе разработки и утверждения технического задания;
Документ не составляют.
2.6. Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов.
В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ.
2.7. На этапе разработки и утверждения технического задания определяют необходимость составления технических условий, содержащих требования к изготовлению, контролю и приемке программы.
Технические условия разрабатывают на стадии «Рабочий проект».
2.8. Необходимость составления технического задания на компоненты, не предназначенные для самостоятельного применения, и комплексы, входящие в другие комплексы, определяется по согласованию с заказчиком.
(Введен дополнительно, Изм. № 1).
КУЛЬТУРА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Любое программное обеспечение , от простого Web-сайта до мощных систем управления базами данных , является высокотехнологичным изделием и должно отвечать следующим критериям:
Программы могут удовлетворять данным требованиям только при тщательном соблюдении всей технологии разработки программного обеспечения
.
Общие этапы разработки программ :
Для определения требований к программе разработчику необходимо получить ответ на вопрос: «Насколько заказчик заинтересован в разработке программы?»
Если заказчик не готов активно участвовать во встречах и совещаниях с разработчиком или говорит, что для выполнения работы есть другие кандидаты, работу над программой следует завершить уже на этой стадии.
Если намерения заказчика серьезны, то определение требований к программе, скорее всего, вопрос не одной встречи (совещания), на которых необходимо выяснить и уточнить вопросы:
Разработка технического задания в идеале должна осуществляться заказчиком. На практике зачастую это делает разработчик по причине отсутствия у заказчика квалифицированных специалистов, сведущих в области разработки программного обеспечения. Техническое задание, как правило, разрабатывается на основе ГОСТа 19.201-78 «ЕСПД. Техническое задание. Требования к содержанию и оформлению». В случаях разработки технического программного обеспечения в составе автоматизированных систем применяется ГОСТ 34.602-89 «Информационная технология. Техническое задание на создание автоматизированной системы».
Техническое задание проходит процедуру согласования между заказчиком и разработчиком после проверки правильности его оформления службой нормоконтроля разработчика.
На основе утвержденного технического задания разрабатывается проектная документация (проект ). Содержание проекта зависит от типа программного обеспечения и традиций предприятия разработчика.
Обязательными составляющими проекта должны быть:
для программ, работающих с базами данных структура их является обязательной составляющей.
Проект является документом, на основе которого разрабатывается программа, и любые изменения в структуре и функциях программы без внесения изменений в проект недопустимы. Именно проект является документом, на основе которого в дальнейшем производится анализ программы и подготовка выпуска последующих версий.
Для осуществления кодирования программы проектировщик выдает задания программисту на кодирование модулей программы. В задании определяются требования к структуре входных и выходных данных модуля, к названиям переменных, используемых в модуле, к алгоритму обработки данных модулем, к приемам программирования (в случае необходимости). Программный код сопровождается подробным комментарием, от качества которого зависит возможность выпуска последующих версий программы.
Тщательно в коде должен быть описан смысл входных и выходных данных каждого модуля, а также смысл и функции самого модуля. Это важно для успеха сборки программы.
За стадию сборки программы отвечает руководитель проекта. На этой стадии программа формируется как единое целое. Поскольку все составляющие программы создавались разными программистами, эта стадия особенно важна для устранения несовпадений и несовместимости всех созданных модулей.
Тестирование программы производится следующим образом:
Заказчику на стадии опытной эксплуатации передается программа и обязательный пакет документации:
В зависимости от вида задачи дополнительно могут передаваться:
На стадии опытной эксплуатации программы фиксируются замечания заказчика и выявленные ошибки.
На основе этого производится доводка программного обеспечения , то есть устранение замечаний и ошибок, и программа передается заказчику в постоянную эксплуатацию .
Поддержка программы в зависимости от ее сложности осуществляется либо заказчиком, либо разработчиком. Поддержка заключается в выполнении следующих видов работ:
Последний пункт и является основой для начала разработки новой версии программы .
Только грамотный процесс разработки программ обеспечивает их высокое качество и долгую жизнь!!!
Единая система программной документации |
ГОСТ 19.101-77 (СТ СЭВ 1626-79) |
ВИДЫ ПРОГРАММ И ПРОГРАММНЫХ ДОКУМЕНТОВ |
|
United system for program documentation. Types of programs and program documents |
Дата введения с 01.01.80
Настоящий стандарт устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Стандарт полностью соответствует СТ СЭВ 1626-79.
1.1. Программу (по ГОСТ 19781-90) допускается идентифицировать и применять самостоятельно и (или) в составе других программ.
1.2. Программы подразделяют на виды, приведенные в табл. 1
Таблица 1
1.3. Документация, разработанная на программу, может использоваться для реализации и передачи программы на носителях данных, а также для изготовления программного изделия.
1.2,1.3.
2.1. К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.
2.2. Виды программных документов и их содержание приведены в табл. 2.
Таблица 2
Вид программного документа | Содержание программного документа |
---|---|
Спецификация | Состав программы и документации на нее |
Перечень предприятий, на которых хранят подлинники программных документов | |
Текст программы | Запись программы с необходимыми комментариями |
Описание программы | Сведения о логической структуре и функционировании программы |
Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля | |
Техническое задание | Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний |
Пояснительная записка | Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений |
Эксплуатационные документы | Сведения для обеспечения функционирования и эксплуатации программы |
(Измененная редакция, Изм. № 1).
2.3. Виды эксплуатационных документов и их содержание приведены табл.3.
Таблица 3
Вид эксплуатационного документа | Содержание эксплуатационного документа |
---|---|
Перечень эксплуатационных документов на программу | |
Формуляр | Основные характеристики программы, комплектность и сведения об эксплуатации программы |
Описание применения | Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств |
Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения | |
Руководство программиста | Сведения для эксплуатации программы |
Руководство оператора | Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы |
Описание языка | Описание синтаксиса и семантики языка |
Сведения для применения тестовых и диагностических программ при обслуживании технических средств |
(Измененная редакция, Изм. № 1).
2.4. В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы.
2.5. Виды программных документов, разрабатываемых на разных стадиях, и их коды приведены в табл click . 4.
Таблица 4
Код вида документа | Вид документа | Стадии разработки | |||
---|---|---|---|---|---|
Эскизный проект | Технический проект | Рабочий проект | |||
компонент | комплекс | ||||
- | Спецификация | - | - | ||
05 | Ведомость держателей подлинников | - | - | - | |
12 | Текст программы | - | - | ||
13 | Описание программы | - | - | ||
20 | Ведомость эксплуатационных документов | - | - | ||
30 | Формуляр | - | - | ||
31 | Описание применения | - | - | ||
32 | Руководство системного программиста | - | - | ||
33 | Руководство программиста | - | - | ||
34 | Руководство оператора | - | - | ||
35 | Описание языка | - | - | ||
46 | Руководство по техническому обслуживанию | - | - | ||
51 | Программа и методика испытаний | - | - | ||
81 | Пояснительная записка | - | - | ||
90-99 | Прочие документы |
Условные обозначения:
- документ обязательный;
- документ обязательный для компонентов, имеющих самостоятельное применение;
- необходимость составления документа определяется на этапе разработки и утверждения технического задания;
- - документ не составляют.
2.2-2.5. (Измененная редакция, Изм. № 1).
2.6. Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов.
В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ.
2.7. На этапе разработки и утверждения технического задания определяют необходимость составления технических условий, содержащих требования к изготовлению, контролю и приемке программы.
Технические условия разрабатывают на стадии «Рабочий проект».
2.8. Необходимость составления технического задания на компоненты, не предназначенные для самостоятельного применения, и комплексы, входящие в другие комплексы, определяется по согласованию с заказчиком.
(Введен дополнительно, Изм. № 1).
Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июне 1981 г (ИУС 9-81)