Общая характеристика состояния

Подготовка документации на программные средства (ПС) в соответствии с имеющимися ГОСТами (документация)

1. Основные вопросы при разработке программных средств

Перед программистом-разработчиком встают вопросы:

· что должно быть сделано, кроме собственно программы?

· что и как должно быть оформлено в виде документации?

· что передавать пользователям?

· что должно входить в само задание на программирование?

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

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

Общая характеристика состояния

Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД), разработанный в 70-80-е годы. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории РФ на основе межгосударственного соглашения по стандартизации.

Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны с документированием функциональных характеристик ПС. Стандарты ЕСПД (ГОСТ 19) носят рекомендательный характер. Это относится и ко всем другим стандартам в области ПС (ГОСТ 34, Международному стандарту ISO/IEC, и др.). В соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе - то есть при ссылке на них в договоре на разработку (поставку) ПС.

Большая часть стандартов ЕСПД морально устарела.

Основные недостатки ЕСПД:

· ориентация на единственную, "каскадную" модель жизненного цикла (ЖЦ) ПС;

· отсутствие четких рекомендаций по документированию характеристик качества ПС;

· отсутствие системной увязки с другими действующими отечественными системами стандартов по ЖЦ и документированию продукции в целом, например, ЕСКД;

· нечетко выраженный подход к документированию ПС как товарной продукции;

· отсутствие рекомендаций по самодокументированию ПС, например, в виде экранных меню и средств оперативной помощи пользователю ("хелпов");

· отсутствие рекомендаций по составу, содержанию и оформлению перспективных документов на ПС, согласованных с рекомендациями международных и региональных стандартов.

ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы жизненного цикла.

Наряду с комплексом ЕСПД официальная нормативная база РФ в области документирования ПС и в смежных областях включает ряд перспективных стандартов (отечественного, межгосударственного и международного уровней).

Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию ЖЦ продуктов программного обеспечения (ПО).

Стандарты комплекса ГОСТ 34 на создание и развитие автоматизированных систем (АС) - обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации (эти стандарты многие считают бюрократическими до вредности и консервативными до устарелости).

Перечень документов ЕСПД

1. ГОСТ 19.001-77 ЕСПД. Общие положения.

2. ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов.

3. ГОСТ 19.102-77 ЕСПД. Стадии разработки.

4. ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.

5. ГОСТ 19.104-78 ЕСПД. Основные надписи.

6. ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.

7. ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.

8. ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.

9. ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний.

10. ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.

11. ГОСТ 19.402-78 ЕСПД. Описание программы.

12. ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.

13. ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.

14. ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.

15. ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.

16. ГОСТ 19.504-79 ЕСПД. Руководство программиста.

17. ГОСТ 19.505-79 ЕСПД. Руководство оператора.

18. ГОСТ 19.506-79 ЕСПД. Описание языка.

19. ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.

20. ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.

21. ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.

22. ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

Термины и определения

Стандарты ЕСПД, которые чаще используются на практике.

Стандарт ГОСТ (СТ СЭВ) 19.201-78 (1626-79). ЕСПД. Техническое задание. Требование к содержанию и оформлению. (Переиздан в ноябре 1987г с изм.1).

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

Техническое задание должно содержать следующие разделы:

· введение;

· основания для разработки;

· назначение разработки;

· требования к программе или программному изделию;

· требования к программной документации;

· технико-экономические показатели;

· стадии и этапы разработки;

· порядок контроля и приемки;

· в техническое задание допускается включать приложения.

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

Стандарт ГОСТ (СТ СЭВ) 19.101-77 (1626-79). ЕСПД. Виды программ и программных документов (Переиздан в ноябре 1987г с изм.1).

Устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

Виды программ

Вид программы	Определение
Компонент	Программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса
Комплекс	Программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса

Виды программных документов

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

Стандарты комплекса ГОСТ 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).

Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД, но и не использовать

Подготовка документации на программные средства (ПС) в соответствии с имеющимися ГОСТами (документация)

1. Основные вопросы при разработке программных средств

Перед программистом-разработчиком встают вопросы:

· что должно быть сделано, кроме собственно программы?

· что и как должно быть оформлено в виде документации?

· что передавать пользователям?

· что должно входить в само задание на программирование?

Общая характеристика состояния

Большая часть стандартов ЕСПД морально устарела.

Основные недостатки ЕСПД:

· ориентация на единственную, "каскадную" модель жизненного цикла (ЖЦ) ПС;

· отсутствие четких рекомендаций по документированию характеристик качества ПС;