4.1. Требования к системе в целом.

4.1.1. Требования к структуре и функционированию системы.
4.1.2. Требования к численности и квалификации персонала системы и режиму его работы.
4.1.3. Требования к надежности.
4.1.4. Требования безопасности.
4.1.5. Требования к эргономике и технической эстетике.
4.1.6. Требования к эксплуатации и техническому обслуживанию.
4.1.7. Требования к защите информации от несанкционированного доступа;
4.1.8. Требования к сохранности информации при авариях.
4.1.9. Требования к защите от влияния внешних воздействий.
4.1.10. Требования к патентной чистоте.
4.1.11. Любые дополнительные требования.

4.2. Требования к функциям (задачам), выполняемым системой.

(перечень функций (задач), подлежащих автоматизации; временной регламент реализации каждой функции (задачи); требования к качеству реализации каждой функции (задачи), к форме представления выходной информации, к точности и времени выполнения, к достоверности выдачи результатов; перечень и критерии отказов для каждой функции (задачи), для которых определены требования к надежности)

4.3. Требования к видам обеспечения.

4.3.1. Требования к математическому обеспечению системы.

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

4.3.2. Требования информационному обеспечению системы.

(требования к составу, структуре и способам организации данных в системе; к информационному обмену между компонентами системы; к информационной совместимости со смежными системами; к применению систем управления базами данных; к структуре процесса сбора, обработки, передачи данных в системе и представлению данных; к защите данных от разрушений при авариях и сбоях в электропитании системы; к контролю, хранению, обновлению и восстановлению данных)

4.3.3. Требования к лингвистическому обеспечению системы.

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

4.3.4. Требования к программному обеспечению системы.

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

4.3.5. Требования к техническому обеспечению.

(требования к видам технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе; к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы)

4.3.6. Требования к организационному обеспечению.

(требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию; к организации функционирования системы и порядку взаимодействия персонала объекта автоматизации; к защите от ошибочных действий персонала системы)

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ Комплекс стандартов на автоматизированные системы	ГОСТ 34.201-89
ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ
Information technology. Set of standards for automated systems. Types, sets and indication of documents for automated systems design

Дата введения 01.01.90

Настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т. п.), включая их сочетание, и устанавливает виды, наименование, комплектность и обозначение документов, разрабатываемых на стадиях создания АС, установленных ГОСТ 24.601.

Пояснение терминов, применяемых в настоящем стандарте, приведены в приложении 1.

1. ВИДЫ И НАИМЕНОВАНИЕ ДОКУМЕНТОВ

1.1. Состав видов документов, разрабатываемых на стадии «Исследование и обоснование создания АС» определяют в соответствии с разд. 3 ГОСТ 24.601, исходя из требуемых результатов выполнения данной стадии.

1.2. На стадии «Техническое задание» разрабатывают Техническое задание (ТЗ) на создание автоматизированной системы в соответствии с требованиями ГОСТ 34.602 .

Допускается разрабатывать частные ТЗ на отдельные системы (подсистемы, комплексы задач, программно-технические комплексы, компоненты технического и программного обеспечений и т. п.)

1.3. Виды документов, разрабатываемых на стадиях «Эскизный проект», «Технический проект», «Рабочая документация» приведены в табл. 1.

Таблица 1

Вид документа	Код документа	Назначение документа
Ведомость		Перечисление в систематизированном виде объектов, предметов и т. д.
		Графическое изображение форм документов, частей, элементов системы и связей между ними в виде условных обозначений
Инструкция		Изложение состава действий и правил их выполнения персоналом
Обоснование		Изложение сведений, подтверждающих целесообразность принимаемых решений
Описание		Пояснение назначения системы, ее частей, принципов их действия и условий применения
Конструкторский документ		По ГОСТ 2.102
Программный документ

1.3.1. Наименование конкретных документов, разрабатываемых при проектировании системы в целом или ее части, приведены в табл. 2.

Таблица 2

Стадия создания	Наименование документа	Код документа	Часть проекта	Принадлежность к		Дополнительные указания
				проектно- сметной докумен- тации	эксплуа- тационной докумен- тации
	Ведомость эскизного проекта
	Пояснительная записка к эскизному проекту
	Схема организационной структуры					Допускается включать в документ П3 или ПВ
		С1 *	ТО	Х	-
	Схема функциональной структуры					При разработке документов СО, С1, С2, С3 на стадии ЭП допускается их включать в документ П1
	Перечень заданий на разработку специализированных (новых) технических средств	В9	ТО	Х	-	При разработке на стадии ТП допускается включать в документ П2
	Схема автоматизации	С3 *	ТО	Х	-	-
	Технические задания на разработку специализированных (новых) технических средств	-	ТО	-	-	В состав проекта на входят
ТП	Задания на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы	-	ТО	Х	-	В состав проекта на входят
	Ведомость технического проекта	ТП *	ОР	-	-	-
	Ведомость покупных изделий	ВП *	ОР	-	-	-
	Перечень входных сигналов и данных	В1	ИО	-	-	-
	Перечень выходных сигналов (документов)	В2	ИО	-	-	-
	Перечень заданий на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы	В3	ТО	Х	-	Допускается включать в документ П2
	Пояснительная записка к техническому проекту	П2	ОР	-	-	Включает план мероприятий по подготовке объекта к вводу системы в эксплуатацию
	Описание автоматизируемых функций	П3	ОР	-	-	-
	Описание постановки задач (комплекса задач)	П4	ОР	-	-	Допускается включать в документы П2 или П3
	Описание информационного обеспечения системы	П5	ИО	-	-	-
	Описание организации информационной базы	П6	ИО	-	-	-
	Описание систем классификации и кодирования	П7	ИО	-	-	-
	Описание массива информации	П8	ИО	-	-	-
	Описание комплекса технических средств	П9	ТО	-	-	Для задачи допускается включать в документ 46 по ГОСТ 19.101
	Описание программного обеспечения	ПА	ПО	-	-	-
	Описание алгоритма (проектной процедуры)	ПБ	МО	-	-	Допускается включать в документы П2, П3 или П4
	Описание организационной структуры	ПВ	ОО	-	-	-
	План расположения	С8	ТО	Х	-	Допускается включать в документ П9
	Ведомость оборудования и материалов	-	ТО	Х	-	-
	Локальный сметный расчет	Б2	ОР	Х	-	-
	Проектная оценка надежности системы	Б1	ОР	-	-	-
	Чертеж формы документа (видеокадра)	С9	ИО	-	Х	На стадии ТП допускается включать в документы П4 или П5
	Ведомость держателей подлинников	ДП *	ОР	-	-	-
	Ведомость эксплуатационных документов	ЭД *	ОР	-	Х	-
	Спецификация оборудования	В4	ТО	Х	-	-
	Ведомость потребности в материалах	В5	ТО	Х	-	-
	Ведомость машинных носителей информации	ВМ *	ИО	-	Х	-
	Массив входных данных	В6	ИО	-	Х	-
	Каталог базы данных	В7	ИО	-	Х	-
	Состав выходных данных (сообщений)	В8	ИО	-	Х	-
	Локальная смета	Б3	ОР	Х	-	-
	Методика (технология) автоматизированного проектирования	И1	ОО	-	Х	-
	Технологическая инструкция	И2	ОО	-	Х	-
	Руководство пользователя	И3	ОО	-	Х	-
	Инструкция по формированию и ведению базы данных (набора данных)	И4	ИО	-	Х	-
	Инструкция по эксплуатации КТС	ИЭ	ТО	-	Х	-
	Схема соединений внешних проводок	С4 *	ТО	Х	-	Допускается выполнять в виде таблиц
	Схема подключения внешних проводок	С5 *	ТО	Х	-	То же
	Таблица соединений и подключений	С6	ТО	Х	-	-
	Схема деления системы (структурная)	Е1 *	ТО	-	-	-
	Чертеж общего вида	ВО *	ТО	Х	-	-
	Чертеж установки технических средств	СА	ТО	Х	-	-
	Схема принципиальная	СБ	ТО	Х	-	-
	Схема структурная комплекса технических средств	С1 *	ТО	Х	-	-
	План расположения оборудования и проводок	С7	ТО	Х	-	-
	Описание технологического процесса обработки данных (включая телеобработку)	ПГ	ОО	-	Х	-
	Общее описание системы	ПД	ОР	-	Х	-
	Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистемы, систем)
	Формуляр	ФО *	ОР	-	Х	-
	Паспорт	ПС *	ОР	-	Х	-
* Документы, код которых установлен в соответствии с требованиями стандартов ЕСКД

(Измененная редакция, Изм. № 1)

Примечания:

• 1. В таблице приняты следующие обозначения:
  • ЭП - эскизный проект;
  • ТП - технический проект;
  • РД - рабочая документация;
  • ОР - общесистемные решения;
  • ОО - решения по организационному обеспечению;
  • ТО - решения по техническому обеспечению;
  • ИО - решения по информационному обеспечению;
  • ПО - решения по программному обеспечению;
  • МО - решения по математическому обеспечению.
• 2. Знак Х - обозначает принадлежность к проектно-сметной или эксплуатационной документации.
• 3. Номенклатуру документов одного наименования устанавливают в зависимости от принятых при создании системы проектных решений

1.3.2. Виды документов на программные средства, используемые при создании АС (ее частей), - по ГОСТ 19.101.77 .

1.3.3. Виды документов на технические средства, используемые при создании АС (ее частей), - по ГОСТ 2.102 и по ГОСТ 2.601 в части эксплуатационных документов.

1.3.4. В зависимости от применяемых методов проектирования и специфики создаваемых АС допускается:

• 1) разрабатывать групповые и базовые документы в соответствии с разд. 1, 3, 4, 6 ГОСТ 2.113;
• 2) выпускать документы отдельными самостоятельными частями, соответствующими разделам основного документа;
• 3) расширять номенклатуру документов, установленную настоящим стандартом.

1.4. На стадиях «Изготовление несерийных компонентов КСА» и «Ввод в действие» разрабатывают следующие организационно-распорядительные документы:

• 1) акт завершения работ;
• 2) акт приемки в опытную эксплуатацию;
• 3) акт приемки в промышленную эксплуатацию;
• 4) план-график работ;
• 5) приказ о составе приемочной комиссии;
• 6) приказ о проведении работ;
• 7) программа работ;
• 8) протокол испытаний;
• 9) протокол согласования.

2. КОМПЛЕКТНОСТЬ ДОКУМЕНТАЦИИ

2.1. Перечень наименований разрабатываемых документов и их комплектность на систему и ее части должен быть определен в техническом задании на создание автоматизированной системы (подсистемы).

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

2.2. На каждый комплект должна быть составлена ведомость документов.

2.3. Комплектность документации, обеспечивающей разработку, изготовление, приемку и монтаж технических средств, - по ГОСТ 2.102. Комплектность эксплуатационной документации на эти средства - по ГОСТ 2.601.

2.4. Комплектность документации на программные средства вычислительной техники - по ГОСТ 19.101.77 .

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

3. ОБОЗНАЧЕНИЯ ДОКУМЕНТОВ

3.1. Каждому разработанному документу должно быть присвоено самостоятельное обозначение. Документ, выполненный на разных носителях данных, должен иметь одно обозначение. К обозначению документов, выполненных на машинных носителях, добавляют букву «М».

Заимствованным документам сохраняют ранее присвоенные обозначения.

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

3.3. Обозначение документа имеет следующую структуру:

Pre> ___________
|___________|. XX . XX . X - X . M
Обозначение системы | | | | | |
(части системы) | | | | | |
Код документа | | | | |
Порядковый номер документа одного | | | |
наименования | | | |
Номер редакции документа | | |
Номер части документа | |
Признак документа, выполненного на машинных |
носителях |

3.3.1. Правила обозначения системы (части системы) приведены в приложении 2.

3.3.2. Код документа состоит из двух буквенно-цифровых знаков. Код для документов, определенных настоящим стандартом, проставляют в соответствии с графой 3 табл. 2. Код дополнительных документов формируют следующим образом: первый знак - буква, означающая вид документа согласно табл. 1, второй знак - цифра или буква, указывающая порядковый номер документа данного вида.

Код документа отделяют от предыдущего обозначения точкой.

3.3.3. Порядковые номера документов одного наименования (2 знака) присваивают, начиная со второго, и отделяют от предыдущего обозначения точкой.

3.3.4. Номер редакции документа присваивают, начиная со второй в порядке возрастания от 2 до 9, и отделяют от предыдущего значения точкой. Очередной номер редакции присваивают в случаях сохранения (не аннулирования) предыдущей редакции.

3.3.5. Номер части документа отделяют от предыдущего обозначения дефисом. Если документ состоит из одной части, то дефис не проставляют и номер части документа не присваивают.

3.3.6. Признак документа, выполненного на машинных носителях, вводят при необходимости. Букву «М» отделяют от предыдущего обозначения точкой.

ПРИЛОЖЕНИЕ 1
Справочное

ПОЯСНЕНИЕ ТЕРМИНОВ, ПРИМЕНЯЕМЫХ В НАСТОЯЩЕМ СТАНДАРТЕ

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

Проектно-сметная документация на АС - часть документации на АС, разрабатываемая для выполнения строительных и монтажных работ, связанных с созданием АС.

Рабочая документация на АС - часть документации на АС, необходимой для изготовления, строительства, монтажа и наладки автоматизированной системы в целом, а также входящих в систему программно-технических, программно-методических комплексов и компонентов технического, программного и информационного обеспечения.

ПРАВИЛА ОБОЗНАЧЕНИЯ СИСТЕМ И ИХ ЧАСТЕЙ

1. Структура обозначения автоматизированной системы или ее части имеет вид:

А . Б . ХХХ
Код организации-разработчика | | |
Код классификационной характеристики | |
системы (ее части) | |
Регистрационный номер |

2. Код организации-разработчика присваивают в соответствии с общесоюзным классификатором предприятий, учреждений и организаций (ОКПО) или по правилам, установленным отраслевыми НТД.

3. Код классификационной характеристики системы или ее части (подсистемы, комплекса, компонента) присваивают в соответствии с правилами, установленными в отрасли на основе 425 подкласса общесоюзного классификатора продукции и/или общесоюзного классификатора подсистем и комплексов задач АСУ - 1 84 154.

4. Порядковый регистрационный номер системы (части системы) присваивает служба организации разработчика, ответственная за ведения картотеки и учет обозначений. Регистрационные номера присваивают с 001 до 999 по каждому коду регистрационной характеристики.

ИНФОРМАЦИОННЫЕ ДАННЫЕ

1. РАЗРАБОТАН И ВНЕСЕН
Государственным комитетом СССР по стандартам
Министерством приборостроения, средств автоматизации и систем управления СССР

ИСПОЛНИТЕЛИ
И.П. Вахлаков; Я.Г. Виленчик; Н.М. Вицын, канд. техн. наук; Ф.Р. Выдра, канд. техн. наук; С.В. Гаршина; Б.А. Дюков; Л.М. Зайденберг, канд. техн. наук; А.П. Игошин, канд. техн. наук; Ю.Б. Ирз, канд. техн. наук (руководитель темы); В.Ю. Королев; И.А. Коротеева; Е.С. Кранков, канд. техн. наук; В.И. Махнач, д-р техн. наук; И.С. Митяев; А.М. Мустафина; Е.И. Некрылов, канд. техн. наук; В.Ф. Попов; Е.Г. Савина; Н.В. Степанчикова; В.К. Чистов, канд. техн. наук; П.А. Шалаев, канд. техн. наук

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитата СССР по стандартам от 24.03.89 № 664

3. Срок проверки - 1999 г.; периодичность проверки - 10 лет

4. ВЗАМЕН ГОСТ 24.101-80, ГОСТ 24.102-80, РД 50-617-86

5. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

Внесены изменения ¹ 1, (Утверждены и введены в действие Постановлением Государственного комитета СССР по управлению качеством продукции и стандартам от 29.12.90 № 3468, дата введения 01.07.91).

Введение

В современном мире каждый день появляется десятки и сотни различных программ, приложений, информационных систем. Они могут быть разработаны как для государственного или коммерческого сектора, так и для обычных пользователей. 90% всех пользователей не читает документацию, считает её скучной, занудной и неинтересной, а открывает руководство пользователя только тогда, когда что-то не получается или разобраться без инструкции уж совсем невозможно. Общепринято теперь строить пользовательский интерфейс таким образом, чтобы он был интуитивно понятен, и пользователь мог разобраться с системой, не прибегая к чтению длиннейших мануалов. Однако, при работе с крупными заказчиками практически всегда необходимо сдать определённый пакет документов – руководств, инструкций, проектных решений, оформленных по ГОСТу.
Когда впервые сталкиваешься с написанием документации по ГОСТу, то приходишь в ступор и полный шок, так как этих ГОСТов «море» и, как и чего по ним писать становится неясно.
В этой статье рассмотрены ГОСТы для написания документации и их основные моменты.

Какие бывают ГОСТы?

Для начала надо разобраться какие бывают ГОСТы. Все лишь знают, что ГОСТ — это нечто, что разрабатывалось при Союзе и их просто бесконечное количество. Спешу вас успокоить для сферы IT ГОСТов не так много, и они все, несмотря на свой срок создания, не потеряли своей актуальности.
В первую очередь стандарты для написания документации делятся на два типа:

1. Международные стандарты (ISO, IEEE Std);
2. Российские или Советские ГОСТы.

Международные стандарты
Международные стандарты применяются для разработки документации международного уровня. Как правило, они не бесплатные, так как разрабатываются не государственными организациями, но, в отличие от наших, разработаны совсем недавно. Тема международных стандартов очень широкая, поэтому она будет рассмотрена в другой статье. Тут же затронуто несколько стандартов, которые тесно связаны с написанием документации.
Список основных международных стандартов для написания документации:

1. IEEE Std 1063-2001 «IEEE Standard for Software User Documentation» - стандарт для написания руководства пользователя;
2. IEEE Std 1016-1998 «IEEE Recommended Practice for Software Design Descriptions» - стандарт для написания технического описания программы;
3. ISO/IEC FDIS 18019:2004 «Guidelines for the design and preparation of user documentation for application software» - ещё один стандарт для написания руководства пользователя. В данном документе есть большое количество примеров. Так сказать, это больше похоже на руководство по написанию руководства пользователя. Начинающим специалистам будет особенно полезен;
4. ISO/IEC 26514:2008 «Requirements for designers and developers of user documentation» - ещё один стандарт для дизайнеров и разработчиков пользователей документации.

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

Российские стандарты
Российские стандарты разрабатываются на государственном уровне. Они все абсолютно бесплатны и каждый из них легко найти в интернете. Для написания документации на программу используются две серии ГОСТов 19 и 34. Именно о них и будет идти речь дальше.

Чем отличаются ГОСТы серий 19 и 34?

Первый вопрос, который возникает, а чем, вообще, эти ГОСТы 19 и 34 отличаются друг от друга.
В ГОСТе 19.781-90 «Единая система программной документации. Программное обеспечение систем обраб0отки информации. Термины и определения» указаны определения:

1. Программа - данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определённого алгоритма.
2. Программное обеспечение - совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ.

В ГОСТе 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения» указано определение:

1. Автоматизированная система (АС) - система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.
   В зависимости от вида деятельности выделяют, например, следующие виды АС: автоматизированные системы управления (АСУ), системы автоматизированного проектирования (САПР), автоматизированные системы научных исследований (АСНИ) и другие.

В зависимости от вида управляемого объекта (процесса) АСУ делят, например, на: АСУ технологическими процессами (АСУТП), АСУ предприятиями (АСУП) и т.д.
Также ГОСТ 34 делает разделение на виды обеспечения АС:

1. Организационное;
2. Методическое;
3. Техническое;
4. Математическое;
5. Программное обеспечение;
6. Информационное;
7. Лингвистическое;
8. Правовое;
9. Эргономическое.

В итоге Автоматизированная система - это не программа, а комплекс видов обеспечения, среди которых есть и программное обеспечение. АС, как правило, несёт в себе организационное решение под конкретного пользователя и заказчика, а Программа может быть создана и растиражирована под большое количество пользователей без привязки к какому-либо предприятию.
Поэтому если вы разрабатываете документацию на программу, которую создали под конкретное предприятие, то ваш ГОСТ 34. Если же пишете документы на массовую программу, то ваш ГОСТ 19.

ГОСТ 34

Серия ГОСТов 34 (ГОСТ 34.ххх Стандарты информационной технологии) состоит:

1. ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем - данный стандарт устанавливает виды, наименование, комплектность и номера документов. Является одним из основных документов серии ГОСТов 34. По сути, это базовый документ, так что новичкам необходимо ознакомиться с ним в первую очередь.
2. ГОСТ 34.320-96 Концепции и терминология для концептуальной схемы и информационной базы - настоящий стандарт устанавливает основные понятия и термины концептуальных схем и информационных баз, охватывающие разработку, описание и применение концептуальных схем и информационных баз, манипулирования информацией, а также описание и реализацию информационного процесса. Стандарт определяет роль концептуальной схемы. Положения, изложенные в нём, носят рекомендательный характер и могут использоваться для оценки систем управления базами данных (СУБД). Этот документ не описывает конкретные методы применения средств поддержки концептуальных схем. Описанные в стандарте языки концептуальных схем не следует рассматривать как стандартные.
3. ГОСТ 34.321-96 Информационные технологии. Система стандартов по базам данных. Эталонная модель управления - данный документ устанавливает эталонную модель управления данными.
   Эталонная модель определяет общую терминологию и понятия, относящиеся к данным информационных систем. Такие понятия используются для определения услуг, предоставляемых системами управления базами данных или системами словарей данных.
   Эталонная модель не рассматривает протоколы для управления данными.
   Область применения эталонной модели включает процессы, которые касаются управления постоянными данными и их взаимодействия с процессами, отличающимися от требований конкретной информационной системы, а также общие услуги управления данными, для определения, хранения, поиска, обновления, ввода, копирования, восстановления и передачи данных.
4. ГОСТ 34.601-90 Автоматизированные системы. Стадии создания - стандарт устанавливает стадии и этапы создания АС.
5. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы (Взамен ГОСТ 24.201-85) - устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы».
   Данный документ является одним из часто используемых документов серии ГОСТ 34. При разработке ТЗ по этому ГОСТу следует помнить и о других стандартах, даже если в этом документе нет ссылок на эти стандарты.
6. ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем - стандарт устанавливает виды испытаний АС автономные, комплексные, приёмочные испытаний и опытная эксплуатация) и общие требования к их проведению.
7. РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов - один из важнейших документов 34 ГОСТа, так как именно в нём описано содержание практически всех документов, а также описание каждого пункта документа.
8. ГОСТ Р ИСО/МЭК 8824-3-2002 Информационная технология. Абстрактная синтаксическая нотация версии один - настоящий стандарт является частью абстрактной синтаксической нотации версии 1 (АСН.1) и устанавливает нотацию для спецификации ограничений, определённых пользователем, и табличных ограничений.
9. ГОСТ Р ИСО/МЭК 10746-3-2001 Управление данными и открытая распределённая обработка.
   В настоящем стандарте:
   • определено, как специфицируются системы открытой распределённой обработки (ОРО) с использованием понятий, введённых в ГОСТ Р ИСО/МЭК 10746-2;
   • идентифицированы характеристики, по которым системы относятся к системам ОРО.

   В стандарте установлен каркас для координации разработки стандартов по системам ОРО.

10. ГОСТ Р ИСО/МЭК 15271-02 Процессы жизненного цикла программных средств - данный ГОСТ необходимо больше, на мой взгляд, для аналитиков при проектировании и моделировании АС.
    Этот документ полезен, с моей точки зрения, в чисто образовательных целях.
11. ГОСТ Р ИСО/МЭК 15910-2002 Процесс создания документации пользователя программного средства - определяет минимально необходимый процесс создания документации пользователя всех видов для программного средства, имеющего интерфейс пользователя. Данные виды охватывают печатную документацию (например, руководства пользователя и краткие справочные карты), диалоговую (оперативную) документацию, справочный текст («хелпы») и системы диалоговой документации.

Итак, исходя из всего выше написанного, видно, что основных документов в 34 ГОСТе 3: ГОСТ 34.201-89, РД 50-34.698-90 и ГОСТ 34.602-89.
При разработке пакета документации, для начала, необходимо открыть ГОСТ 34.201-89 и выбрать стадию создания Эскизный проект, Технический проект и Рабочая документация. Далее, следует выбрать документы для разработки, которые соответствуют стадии создания.

Перечень документов 34 ГОСТа

Стадия создания	Наименование документа	Код	Часть проекта	Принад лежнос ть к проект но-смет ной доку мента ции	Принад лежнос ть к эксплуа тацион ной до кумен тации	Дополнительные указания
ЭП	Ведомость эскизного проекта	ЭП*	ОР	—	—	—
	Пояснительная записка К эскизному проекту	П1	ОР	—	—	—
ЭП, ТП	Схема организационной структуры	СО	ОР	—	—	Допускается включать в документ П3 или ПВ
	Схема структурная комплекса технических средств	С1*	ТО	Х	—
	Схема функциональной структуры	С2*	ОР	—	—	При разработке документов СО, С1, С2, С3 на стадии ЭП допускается их включать в документ П1
	специализированных (новых) технических средств	В9	ТО	Х	—	При разработке на стадии ТП допускается включать в документ П2
	Схема автоматизации	С3*	ТО	Х	—	—
	Технические задания на разработку специализированных (новых) технических средств	—	ТО	—	—	В состав проекта не входят
ТП	Задания на разработку санитарно-технических и других разделов проекта, связанных с созданием системы	—	ТО	Х	—	В состав проекта не входят
	Ведомость технического проекта	ТП*	ОР	—	—	—
	Ведомость покупных изделий	ВП*	ОР	—	—	—
	Перечень входных сигналов и данных	В1	ИО	—	—	—
	Перечень выходных сигналов (документов)	В2	ИО	—	—	—
	Перечень заданий на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы	В3	ТО	Х	—	Допускается включать в документ П2
	Пояснительная записка к техническому проекту	П2	ОР	—	—	Включает план мероприятий по подготовке объекта к вводу системы в эксплуатацию
	Описание автоматизируемых функций	П3	ОР	—	—	—
	Описание постановки задач (комплекса задач)	П4	ОР	—	—	Допускается включать в документы П2 или П3
	Описание информационного обеспечения системы	П5	ИО	—	—	—
	Описание организации информационной базы	П6	ИО	—	—	—
ТП	Описание систем классификации и кодирования	П7	ИО	—	—	—
	Описание массива информации	П8	ИО	—	—	—
	Описание комплекса технических средств	П9	ТО	—	—	Для задачи допускается включать в документ 46 по ГОСТ 19.101
	Описание программного обеспечения	ПА	ПО	—	—	—
	Описание алгоритма (проектной процедуры)	ПБ	МО	—	—	Допускается включать в документы П2, П3 или П4
	Описание организационной структуры	ПВ	ОО	—	—	—
	План расположения	С8	ТО	Х	—	Допускается включать в документ П9
	Ведомость оборудования и материалов	—	ТО	Х	—	—
	Локальный сметный расчёт	Б2	ОР	Х	—	—
ТП, РД	Проектная оценка надёжности системы	Б1	ОР	—	—	—
	Чертёж формы документа (видеокадра)	С9	ИО	—	Х	На стадии ТП допускается включать в документы П4 или П5
РД	Ведомость держателей подлинников	ДП*	ОР	—	—	—
	Ведомость эксплуатационных документов	ЭД*	ОР	—	Х	—
	Спецификация оборудования	В4	ТО	Х	—	—
	Ведомость потребности в материалах	В5	ТО	Х	—	—
	Ведомость машинных носителей информации	ВМ*	ИО	—	Х	—
	Массив входных данных	В6	ИО	—	Х	—
РД	Каталог базы данных	В7	ИО	—	Х	—
	Состав выходных данных (сообщений)	В8	ИО	—	Х	—
	Локальная смета	Б3	ОР	Х	—	—
	Методика (технология) автоматизированного проектирования	И1	ОО	—	Х	—
	Технологическая инструкция	И2	ОО	—	Х	—
	Руководство пользователя	И3	ОО	—	Х	—
	Инструкция по формированию и ведению базы данных (набора данных)	И4	ИО	—	Х	—
	Инструкция по эксплуатации КТС	ИЭ	ТО	—	Х	—
	Схема соединений внешних проводок	С4*	ТО	Х	—	Допускается выполнять в виде таблиц
	Схема подключения внешних проводок	С5*	ТО	Х	—	То же
	Таблица соединений и подключений	С6	ТО	Х	—	—
	Схема деления системы (структурная)	Е1*	ТО	—	—	—
	Чертёж общего вида	ВО*	ТО	Х	—	—
	Чертёж установки технических средств	СА	ТО	Х	—	—
	Схема принципиальная	СБ	ТО	Х	—	—
	Схема структурная комплекса технических средств	С1*	ТО	Х	—	—
	План расположения оборудования и проводок	С7	ТО	Х	—	—
	Описание технологического процесса обработки данных (включая телеобработку)	ПГ	ОО	—	Х	—
	Общее описание системы	ПД	ОР	—	Х	—
	Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистемы, систем)	ПМ*	ОР	—	—	—
	Формуляр	ФО*	ОР	—	Х	—
	Паспорт	ПС*	ОР	—	Х	—
*Документы, код которых установлен в соответствии с требованиями стандартов ЕСКД

Примечание к таблице:

1. В таблице приняты следующие обозначения:
   • ЭП — эскизный проект;
   • ТП — технический проект;
   • РД — рабочая документация;
   • ОР — общесистемные решения;
   • ОО — решения по организационному обеспечению;
   • ТО — решения по техническому обеспечению;
   • ИО — решения по информационному обеспечению;
   • ПО — решения по программному обеспечению;
   • МО — решения по математическому обеспечению.
2. Знак Х — обозначает принадлежность к проектно-сметной или эксплуатационной документации.
3. Номенклатуру документов одного наименования устанавливают в зависимости от принятых при создании системы проектных решений.

Когда перечень документов определён, то в РД 50-34.698-90 следует найти выбранные документы и разработать их строго по указанным пунктам. Все пункты содержания, которые указаны, обязательно должны быть в документе.
Если разрабатывается Техническое задание, то сразу нужно открыть ГОСТ 34.602-89 и разработать ТЗ строго согласно пунктам.

ГОСТ 19

Серия ГОСТов 19 (ГОСТ 19.ххх Единая система программной документации (ЕСПД)) состоит:

1. 1. ГОСТ 19.001-77 Общие положения - слишком общий документ, практической пользы он не несёт. Поэтому его можно пропустить.
   2. ГОСТ 19781-90 Термины и определения - хороший список определений в области программного обеспечения систем обработки информации. Кроме как определений больше не содержит ничего.
   3. ГОСТ 19.101-77 Виды программ и программных документов - один из главных документов 19 ГОСТа. Именно с него следует начинать работу с 19 ГОСТом, так как в нём содержится полный перечень и обозначения документов ГОСТа.

Перечень документов 19 ГОСТа

Код	Вид документа	Стадии разработки
		Эскизный проект	Технический проект	Рабочий проект
				компонент	комплекс
—	Спецификация	—	—
05	Ведомость держателей подлинников	—	—	—
12	Текст программы	—	—
13	Описание программы	—	—
20	Ведомость эксплуатационных документов	—	—
30	Формуляр	—	—
31	Описание применения	—	—
32	Руководство системного программиста	—	—
33	Руководство программиста	—	—
34	Руководство оператора	—	—
35	Описание языка	—	—
46	Руководство по техническому обслуживанию	—	—
51	Программа и методика испытаний	—	—
81	Пояснительная записка			—	—
90-99	Прочие документы

Условные обозначения:
— документ обязательный;
— документ обязательный для компонентов, имеющих самостоятельное применение;
— необходимость составления документа определяется на этапе разработки и утверждения технического задания;
- — документ не составляют.

1. ГОСТ 19.102-77 Стадии разработки - содержит описание стадий разработки. Полезен в образовательных целях. На мой взгляд, особой практической пользы не несёт.
2. ГОСТ 19.103-77 Обозначения программ и программных документов - содержит описание присвоения номера (кода) документу. Даже после прочтения этого ГОСТа остаётся куча вопросов о том, как же присвоить этот самый номер документу.
3. ГОСТ 19.104-78 Основные надписи - устанавливает формы, размеры, расположение и порядок заполнения основных надписей листа утверждения и титульного листа в программных документах, предусмотренных стандартами ЕСПД, независимо от способов их выполнения. Так как документы 19 ГОСТа оформляются в рамочках, то данный документ очень важен.
4. ГОСТ 19.105-78 Общие требования к программным документам - устанавливает общие требования к оформлению программных документов. Требования слишком общие. Как правило для разработки документа этот ГОСТ почти не применяется, так как хватает специального ГОСТа на документ, но для общих знаний в данный ГОСТ все же лучше заглянуть разок.
5. ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом - содержит требования к оформлению всех документов 19 ГОСТа.
6. ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению - устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия.

   Пункты ТЗ 34 ГОСТа и 19 ГОСТа отличаются.

7. ГОСТ 19.601-78 Общие правила дублирования, учёта и хранения - общие правила дублирования, обращения, учёта и хранения программных документов. В ГОСТе в нескольких пунктах описано как сделать так, чтобы документы не потерялись.
8. ГОСТ 19.602-78 Правила дублирования, учёта и хранения программных документов, выполн-х печ. Способом - дополнение к ГОСТу 19.601-78.
9. ГОСТ 19.603-78 Общие правила внесения изменений - устанавливает общие правила внесения изменений в программные документы. По сути, описывает длинный бюрократический алгоритм внесения изменений в документы.
10. ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненных печатным способом - описывает порядок работы и заполнения с Листа регистрации изменений.

Список специализированных ГОСТов, то есть в каждом из них описано содержание и требования к определённому документу:

1. ГОСТ 19.202-78 Спецификация. Требования к содержанию и оформлению;
2. ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению;
3. ГОСТ 19.401-78 Текст программы. Требования к содержанию и оформлению;
4. ГОСТ 19.402-78 Описание программы;
5. ГОСТ 19.403-79 Ведомость держателей подлинников;
6. ГОСТ 19.404-79 Пояснительная записка. Требования к содержанию и оформлению;
7. ГОСТ 19.501-78 Формуляр. Требования к содержанию и оформлению;
8. ГОСТ 19.502-78 Описание применения. Требования к содержанию и оформлению;
9. ГОСТ 19.503-79 Руководство системного программиста. Требования к содержанию и оформлению;
10. ГОСТ 19.504-79 Руководство программиста. Требования к содержанию и оформлению;
11. ГОСТ 19.505-79 Руководство оператора. Требования к содержанию и оформлению;
12. ГОСТ 19.506-79 Описание языка. Требования к содержанию и оформлению;
13. ГОСТ 19.507-79 Ведомость эксплуатационных документов;
14. ГОСТ 19.508-79 Руководство по техническому обслуживанию. Требования к содержанию и оформлению.

Порядок работы с 19 ГОСТом:

1. В ГОСТе 19.101-77 выбрать документ и его код согласно стадии разработки.
2. Согласно ГОСТу 19.103-77 присвоить номер документу.
3. Затем по ГОСТам 19.104-78 и 19.106-78 оформить документ.
4. Из специализированного списка ГОСТов следует выбрать тот, который соответствует разрабатываемому документу.

Заключение

ГОСТ - это не страшно и несложно! Главное понять, что нужно написать и какой для этого ГОСТ используется. Наши основные ГОСТы 19 и 34 для написания документации очень старые, но и по сей день актуальны. Написание документации по стандарту снимает множество вопросов между исполнителем и заказчиком. Следовательно, несёт в себе экономию времени и денег.

Зачем, в принципе, нужны при проектировании?

Получается так, что ГОСТы помогают самому проектировщику.

Основная проблема при проектировании – это отсутствие самого проектирования. Есть некие обрывки мыслей, желаний, но без формирования их в некую целостную картину. Это свойственно и начинающим и системным администраторам и начинающим системным инженерам. Присутствуют некая спонтанность мышления. Кстати, она же свойственна и многим заказчикам. Но они находятся в несколько более выгодном положении, чем исполнители.

Возникает интересный вопрос: а кому нужно и все эти пояснительные записки, ТЗ и т.п.? И вот какой интересный ответ у нас получится: на 85% документирование необходимо исполнителю. Оставшиеся 15% нужны заказчику для некоего общего понимания происходящего. Но исполнителю надо четко обозначить как границы проекта, так и признаки его выполнения. Исполнитель должен уметь защищать себя от хаотичности мышления заказчика.

Итак, обратимся к ГОСТам разработчика. Основных у нас их два: ГОСТ 34й серии и ГОСТ 19й серии. 34я серия относится к разработке автоматизированных систем, а 19й – к разработке программного обеспечения.
Мы будем говорить о ГОСТе 34й серии.

В 34й серии много различных ГОСТов. Нас будут интересовать лишь некоторые из них. А именно:

1. ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Термины и определения
2. ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания
3. ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
4. ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем
5. ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем
6. РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.

ГОСТы чем-то похожи по своей иерархической структуре на каталог. На такой, например, как Active Directory. Вероятно, что если писать документацию четко следуя ГОСТам, то перекрестные ссылки позволят вам ознакомиться с огромным количеством документов. Но что самое главное в ГОСТах, это четкая модель «от общего к частному». Начиная с общих фраз мы дойдем до самого последнего RJ45 в системе.

А теперь более подробно. Основным ГОСТом, вокруг которого идет т.н. пляска является ГОСТ 34.601-90 (Стадии создания). Давайте более подробно посмотрим на этот документ.

Вот такая вот структура встречает нас в данном документе. Что же в этом замечательного? Замечательного в этом то, что мы видим практически полный цикл жизни автоматизированной системы. Почему почти? Потому что тут отсутствует такая стадия как вывод из эксплуатации и утилизация. Но нам это не особо и надо. Пока с лихвой хватит и существующих стадий. Тем более, что стадия утилизации рассмотрена в одном из других ГОСТов, но это выходит за рамки этой статьи.

Как я говорил выше, ГОСТы содержат в себе перекрестные ссылки. И чтобы пойти дальше в наших рассуждениях, мы чуть-чуть заглянем в ГОСТ 34.003-90 (Термины и определения). В нем интересует определение автоматизированной системы. Это важно, т.к. нам все же надо иметь представление, что же мы собираемся создавать.

ГОСТ 34.003-90 в определении автоматизированной системы говорит нам следующее: автоматизированная система; АС: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. Т.е. другими словами, АС состоит из

1. Персонала
2. комплекса средств
3. некой деятельности, подлежащей автоматизации.

Так же уточним у ГОСТа 34.003-90

1. комплекс средств автоматизации автоматизированной системы; КСА АС: Совокупность всех компонентов АС, за исключением людей
2. пользователь автоматизированной системы; пользователь AC: Лицо, участвующее в функционировании АС или использующее результаты ее функционирования
3. эксплуатационный персонал автоматизированной системы; эксплуатационный персонал АС
4. компонент автоматизированной системы; компонент AC: Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое

Итак, что же у нас получается? А получается, что мы почувствовали под ногами некоторый фундамент, на который будем опираться. Нам известно, из чего состоит автоматизированная система и уточнили, что персонал бывает двух видов: пользовательский и эксплуатационный. И логически выведем, что компонент АС, выделенный по определенному признаку будет т.с. «hardware» и «software», если совсем просто. И совокупность программы+железо будет комплекс средств автоматизации АС.

Значит, если заказчик, например, скажет «А установите мне Exchange», то это не будет АС по одной простой причине: как минимум в таком задании отсутствует вид автоматизируемой деятельности. А может быть заказчику вообще нужен не Exchange. А может ему совсем нужен не Exchange. А это значит, что требуется обследование объекта автоматизации. А значит начинается стадия первая ГОСТ 34.601-90 (Стадии создания). «Формирование требований к АС»

На этой стадии ГОСТ требует от нас сделать несколько этапов. Если перевести это на человеческий язык, то тут мы должны определить надо ли вообще что-либо разрабатывать. Целесообразно ли это различных точек зрения. В общем, провести оценку необходимости начала работ. Итогом работы по этой стадии становится отчет, который фиксирует результат.

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

В концепции нам необходимо изучить объект, где требуется произвести внедрение. Если в первой стадии мы искали причину создания АС вообще(исходя лишь из бизнес-целей, просто ГОСТ писался тогда, когда таких слов не употребляли), то на второй стадии нам необходимо найти возможные варианты, которые удовлетворяют требованиям заказчика. Например, если заказчик хочет почтовую систему, то это можно реализовать как на Exchange, так и на Postfix или на чем ни будь еще. Со своими плюсами, минусами и вариантами развития. Проводится общая экспертиза объекта и предварительно оцениваются трудозатраты. Мы, как исполнители, тоже ищем для себя наиболее оптимальный вариант.
После того, как мы придем с заказчиком к определенному единому мнению о том, какой именно вариант решения ему подходит в общих чертах больше всего, мы переходим к, не побоюсь этого слова, самому важному пункту проекта «Техническое задание»

Техническое задание, если посмотреть определение ГОСТ 34.602-89, является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

ТЗ настолько важный документ, что ему посвящен персональный ГОСТ. Сейчас мы на этом подробно останавливаться не будем. Замечу лишь, что для правильного формирования ТЗ необходимо, чтобы стадии ГОСТа 34.601-90 «Формирование требований к АС» и «Разработка концепции АС» были выполнены. От качества выполнения этих стадий зависит правильность и корректность создания ТЗ.

Оставьте свой комментарий!

В своем докладе я опираюсь на:

• статью "Стандартизация в области программных средств" В.В.Васютковича - начальника отделения и С.С.Самотохина v ст.н.с. ВНИИ стандарта ГОССТАНДАРТА РФ;
• статью "Соотносение и использование стандартов организации жизненных циклов систем" Е.З.Зиндера;
• тексты ГОСТов и других стандартов.

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

Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы:

• что должно быть сделано, кроме собственно программы?
• что и как должно быть оформлено в виде документации?
• что передавать пользователям, а что? службе сопровождения?
• как управлять всем этим процессом?
• что должно входить в само задание на программирование?

Кроме упомянутых вопросов есть и другие.

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

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

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

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

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

Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела.

К числу основных недостатков ЕСПД можно отнести:

• ориентацию на единственную, "каскадную" модель жизненного цикла (ЖЦ) ПС;
• отсутствие четких рекомендаций по документированию характеристик качества ПС;
• отсутствие системной увязки с другими действующими отечественными системами стандартов по ЖЦ и документированию продукции в целом, например, ЕСКД;
• нечетко выраженный подход к документированию ПС как товарной продукции;
• отсутствие рекомендаций по самодокументированию ПС, например, в виде экранных меню и средств оперативной помощи пользователю ("хелпов");
• отсутствие рекомендаций по составу, содержанию и оформлению перспективных документов на ПС, согласованных с рекомендациями международных и региональных стандартов.

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

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

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

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

В своей статье Е.З.Зиндер подробно останавливается на методике Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle.

2.1. Краткое представление стандартов ЕСПД

Тем не менее, до пересмотра всего комплекса, многие стандарты ЕСПД могут с пользой применяться в практике документирования ПС. Эта позиция основана на следующем:

• стандарты ЕСПД вносят элемент упорядочения в процесс документирования ПС;
• предусмотренный стандартами ЕСПД состав программных документов вовсе не такой "жесткий", как некоторым кажется: стандарты позволяют вносить в комплект документации на ПС дополнительные виды
• стандарты ЕСПД позволяют вдобавок мобильно изменять структуры и содержание установленных видов ПД исходя из требований заказчика и пользователя.

При этом стиль применения стандартов может соответствовать современному общему стилю адаптации стандартов к специфике проекта: заказчик и руководитель проекта выбирают уместное в проекте подмножество стандартов и ПД, дополняют выбранные ПД нужными разделами и исключают ненужные, привязывают создание этих документов к той схеме ЖЦ, которая используется в проекте.

Стандарты ЕСПД (как и другие ГОСТы) подразделяют на группы, приведTнные в таблице:

Обозначение стандарта ЕСПД строят по классификационному признаку:

Обозначение стандарта ЕСПД должно состоять из:

• числа 19 (присвоенных классу стандартов ЕСПД);
• одной цифры (после точки), обозначающей код классификационной группы стандартов, указанной таблице;
• двузначного числа (после тире), указывающего год регистрации стандарта.

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

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.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом.
8. ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.
9. ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.
10. ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний.
11. ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.
12. ГОСТ 19.402-78 ЕСПД. Описание программы.
13. ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.
14. ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.
15. ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.
16. ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.
17. ГОСТ 19.504-79 ЕСПД. Руководство программиста.
18. ГОСТ 19.505-79 ЕСПД. Руководство оператора.
19. ГОСТ 19.506-79 ЕСПД. Описание языка.
20. ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.
21. ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.
22. ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
23. ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

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

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

Первым укажем стандарт, который можно использовать при формировании заданий на программирование.

ГОСТ (СТ СЭВ) 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.102-77. ЕСПД. Стадии разработки.

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

Стадии разработки, этапы и содержание работ

Стадии разработки	Этапы работ
Техническое задание	Обоснование необходимости разработки программы	Постановка задачи. Сбор исходных материалов. Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ.
	Научно-исследовательские работы	Определение структуры входных и выходных данных. Предварительный выбор методов решения задач. Обоснование целесообразности применения ранее разработанных программ. Определение требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи.
	Разработка и утверждение технического задания	Определение требований к программе. Разработка технико-экономического обоснования разработки программы. Определение стадий, этапов и сроков разработки программы и документации на нее. Выбор языков программирования. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания.
Эскизный проект	Разработка эскизного проекта	Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи. Разработка технико-экономического обоснования.
	Утверждение эскизного проекта	Согласование и утверждение эскизного проекта
Технический проект	Разработка технического проекта	Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств.
	Утверждение технического проекта	Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта.
Рабочий проект	Разработка программы	Программирование и отладка программы
	Разработка программной документации	Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.
	Испытания программы	Разработка, согласование и утверждение программы и методики испытаний. Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний.
Внедрение	Подготовка и передача программы	Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ.

Примечания:

1. Допускается исключать вторую стадию разработки, а в технически обоснованных случаях - вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.
2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком.

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

Код страны-разработчика и код организации-разработчика присваивают в установленном порядке.

• Регистрационный номер присваивается в порядке возрастания, начиная с 00001 до 99999, для каждой организации-разработчика.
• Номер издания программы или номер редакции. номер документа данного вида, номер части документа присваиваются в порядке возрастания с 01 до 99. (Если документ состоит из одной части, то дефис и порядковый номер части не указывают).
• Номер редакции спецификации и ведомости эксплуатационных документов на программу должны совпадать с номером издания этой же программы.

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

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

Программный документ может быть представлен на различных типах носителей данных и состоит из следующих условных частей:
титульной;
информационной;
основной.

Правила оформления документа и его частей на каждом носителе данных устанавливаются стандартами ЕСПД на правила оформления документов на соответствующих носителях данных.

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

Программные документы оформляют:

• на листах формата А4 (ГОСТ 2.301-68) при изготовлении документа машинописным или рукописным способом;
• допускается оформление на листах формата А3;
• при машинном способе выполнения документа допускаются отклонения размеров листов, соответствующих форматам А4 и А3, определяемые возможностями применяемых технических средств; на листах форматов А4 и А3, предусматриваемых выходными характеристиками устройств вывода данных, при изготовлении документа машинным способом;
• на листах типографических форматов при изготовлении документа типографским способом.

Расположение материалов программного документа осуществляется в следующей последовательности:

Титульная часть:

• лист утверждения (не входит в общее количество листов документа);
• титульный лист (первый лист документа);

информационная часть:

• аннотация;
• лист содержания;

основная часть:

• текст документа (с рисунками, таблицами и т.п.)
• перечень терминов и их определений;
• перечень сокращений;
• приложения;
• предметный указатель;
• перечень ссылочных документов;

часть регистрации изменений:

• лист регистрации изменений.

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

Следующий стандарт ориентирован на документирование результирующего продукта разработки:

ГОСТ 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 Системы обработки информации. Документы на магнитных носителях данных. Порядок выполнения и обращения. Распространяется не только на программные, но и на конструкторские, технологические и другие проектные документы, выполняемые на магнитных носителях.

2.2. Стандарты комплекса ГОСТ 34

ГОСТ 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-х годах сложилось положение, при котором в различных отраслях и областях деятельности использовалась плохо согласованная или несогласованная НТД - "нормативно-техническая документация". Это затрудняло интеграцию систем, обеспечение их эффективного совместного функционирования. Действовали различные комплексы и системы стандартов, устанавливающие требования к различным видам АС.

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

Конечно, эта ситуация отчасти отражала и естественное многообразие условий разработки АС, целей разработчиков, применяемых подходов и методик.

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

1. Выработать одну обобщенную понятийную и терминологическую систему, общую схему разработки, общий набор документов с их содержанием и определить их как обязательные для всех АС;
2. Определить также одну общую понятийную и терминологическую систему, обобщенный комплекс системных требований, набор критериев качества, но предоставить максимальную свободу в выборе схемы разработки, состава документов и других аспектов, наложив только минимум обязательных требований, которые позволяли бы:
   • определять уровень качества результата;
   • выбирать те конкретные методики (с их моделями ЖЦ, набором документов и др.), которые наиболее подходят к условиям разработки и соответствуют используемым Информационным Технологиям;
   • работать, таким образом, с минимальными ограничениями эффективных действий проектировщика АС.

Разработчики комплекса стандартов 34 выбрали способ, близкий к первому из указанных выше, то есть пошли по пути, более близкому к схемам конкретных методик, чем к стандартам типа ISO12207. Тем не менее, благодаря общности понятийной базы стандарты остаются применимыми в весьма широком диапазоне случаев.

Степень адаптивности формально определяется возможностями:

• опускать стадию эскизного проектирования и объединять стадии "Технический проект" и "Рабочая документация";
• опускать этапы, объединять и опускать большинство документов и их разделов;
• вводить дополнительные документы, разделы документов и работы;
• динамически создавая т. н. ЧТЗ - частные технические задания - достаточно гибко формировать ЖЦ АС; как правило, этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.

Стадии и этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании, что близко к подходу ISO.

Введение единой, достаточно качественно определенной терминологии, наличие достаточно разумной классификации работ, документов, видов обеспечения и др. безусловно полезно. ГОСТ 34 способствует более полной и качественной стыковке действительно разных систем, что особенно важно в условиях, когда разрабатывается все больше сложных комплексных АС, например, типа CAD-CAM, которые включают в свой состав АСУТП, АСУП, САПР-конструктора, САПР-технолога, АСНИ и др. системы.

Определено несколько важных положений, отражающих особенности АС как объекта стандартизации, например: "в общем случае АС состоит из программно-технических (ПТК), программно-методических (ПМК) комплексов и отдельных компонентов организационного, технического, программного и информационного обеспечения".

Разделение понятий ПТК и АС закрепляло принцип, по которому АС есть не "ИС с БД", но:

• "организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях" (по РД 50-680-88), что особенно актуально в аспектах бизнес-реинжиниринга;
• "система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций" (по ГОСТ 34.003-90).

Эти определения указывают на то, что АС - это, в первую очередь, персонал, принимающий решения и выполняющий другие управляющие действия, поддержанный организационно-техническими средствами.

Степень обязательности:

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

Ключевым документом взаимодействия сторон является ТЗ - техническое задание на создание АС. ТЗ является основным исходным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88).

2.3. Государственные стандарты РФ (ГОСТ Р)

В РФ действует ряд стандартов в части документирования ПС, разработанных на основе прямого применения международных стандартов ИСО. Это? самые "свежие" по времени принятия стандарты. Некоторые из них впрямую адресованы руководителям проекта или директорам информационных служб. Вместе с тем они неоправданно мало известны в среде профессионалов. Вот их представление.

ГОСТ Р ИСО/МЭК 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения. Стандарт полностью соответствует международному стандарту ИСО/МЭК ТО 9294:1990 и устанавливает рекомендации по эффективному управлению документированием ПС для руководителей, отвечающих за их создание. Целью стандарта является оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования.

ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. Стандарт полностью соответствует международному стандарту ИСО/МЭК 9126:1991. В его контексте под характеристикой качества понимается "набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается". Стандарт определяет шесть комплексных характеристик, которые с минимальным дублированием описывают качество ПС (ПО, программной продукции): функциональные возможности; надежность; практичность; эффективность; сопровождаемость; мобильность. Эти характеристики образуют основу для дальнейшего уточнения и описания качества ПС.

ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов. Стандарт полностью соответствует международному стандарту ИСО 9127:1989. В контексте настоящего стандарта под потребительским программным пакетом (ПП) понимается "программная продукция, спроектированная и продаваемая для выполнения определенных функций; программа и соответствующая ей документация, упакованные для продажи как единое целое". Под документацией пользователя понимается документация, которая обеспечивает конечного пользователя информацией по установке и эксплуатации ПП. Под информацией на упаковке понимают информацию, воспроизводимую на внешней упаковке ПП. Ее целью является предоставление потенциальным покупателям первичных сведений о ПП.

ГОСТ Р ИСО/МЭК 8631-94 Информационная технология. Программные конструктивы и условные обозначения для их представления. Описывает представление процедурных алгоритмов.

2.4. Международный стандарт ISO/IEC 12207: 1995-08-01

Первая редакция ISO12207 подготовлена в 1995 году объединенным техническим комитетом ISO/IEC JTC1 "Информационные технологии, подкомитет SC7, проектирование программного обеспечения".

По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые!) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

Очень важные ЗАМЕЧАНИЯ СТАНДАРТА:

1. Процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.)
2. Добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Контракт понимается в широком смысле: от юридически оформленного контракта до неформального соглашения, соглашение может быть определено и единственной стороной как задача, поставленная самому себе.
3. Стандарт принципиально не содержит конкретные методы действий, тем более - заготовки решений или документации. Он описывает архитектуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить услуги и задачи, включенные в процессы, не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа принимаются использующим стандарт.

ОПРЕДЕЛЕНИЯ СТАНДАРТА:

1. Система - это объединение одного или более процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей.
2. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
   Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте. Степень адаптивности: максимальная
3. Требование квалификации - набор критериев или условий (квалификационные требования), которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как подчиняющийся (удовлетворяющий условиям) его спецификациям и готовый для использования в целевой окружающей среде.

Стандарт не предписывает конкретную модель ЖЦ или метод разработки ПО, но определяет, что стороны-участники использования стандарта ответственны за выбор модели ЖЦ для проекта ПО, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение методов разработки ПО, за выполнение действий и задач, подходящих для проекта ПО.

Стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.

Каждый процесс ЖЦ разделен на набор действий, каждое действие - на набор задач. Очень важное отличие ISO: каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).

В стандарте ISO12207 описаны:

1. 5 основных процессов ЖЦ ПО:
   • Процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПО.
   • Процесс поставки. Определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПО.
   • Процесс разработки. Определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт.
   • Процесс функционирования. Определяет действия предприятия-оператора, которое обеспечивает обслуживание системы (а не только ПО) в процессе ее функционирования в интересах пользователей. В отличие от действий, которые определяются разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рассматриваемых стандартах), определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующе обязанности.
   • Процесс сопровождения. Определяет действия персонала сопровождения, который обеспечивает сопровождение программного продукта, что представляет собой управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности, включает в себя инсталляцию и удаление программного изделия на вычислительной системе.
2. 8 вспомогательных процессов, которые поддерживают реализацию другого процесса, будучи неотъемлемой частью всего ЖЦ программного изделия, и обеспечивают должное качество проекта ПО:
   • решения проблем;
   • документирования;
   • управления конфигурацией;
   • гарантирования качества, который использует результаты остальных процессов группы обеспечения качества, в которую входят:
     • Процесс верификации;
     • Процесс аттестации;
     • Процесс совместной оценки;
     • Процесс аудита.
3. 4 организационных процесса:
   • Процесс управления;
   • Процесс создания инфраструктуры;
   • Процесс усовершенствования;
   • Процесс обучения.

К ним примыкает особый Процесс адаптации, который определяет основные действия, необходимые для адаптации стандарта к условиям конкретного проекта.

Под процессом усовершенствования здесь понимается не усовершенствование АС или ПО, а улучшение самих процессов приобретения, разработки, гарантирования качества и т. п., реально осуществляемых в организации.

Каких-либо этапов, фаз, стадий не предусмотрено, что дает описываемую ниже степень адаптивности.

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

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

Такой характер позволяет реализовывать любую модель ЖЦ.

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

При этом разработчик должен установить и документировать как требования к программному обеспечению:

1. Функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица программного обеспечения должна быть выполнена;
2. Внешние связи (интерфейсы) с единицей программного обеспечения;
3. Требования квалификации;
4. Спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;
5. Спецификации защищенности,
6. Человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучению;
7. Определение данных и требований базы данных;
8. Установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);
9. Документация пользователя;
10. Работа пользователя и требования выполнения;
11. Требования сервиса пользователя.

(Интересно и важно, что эти и аналогичные характеристики хорошо корреспондируются с характеристиками АС, предусматриваемыми в ГОСТ 34 по видам обеспечения системы.)

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

Итак, ISO12207 имеет набор процессов, действий и задач, охватывающий наиболее широкий спектр возможных ситуаций при максимальной адаптируемости.

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

По этой причине центральным стандартом, положения которого берутся за начальный "стержневой" набор положений в процессе построения профиля стандартов ЖЦ для конкретного проекта, полезно рассматривать именно ISO12207. Этот "стержень" может задавать модель ЖЦ ПО и АС, принципиальную схему гарантирования качества, модель управления проектом

Практики используют еще один путь: сами переводят и используют в своих проектах современные стандарты на организацию ЖЦ ПС и их документирование. Но этот путь страдает как минимум тем недостатком, что разные переводы и адаптации стандартов, сделанные разными разработчиками и заказчиками, будут отличаться массой деталей. Эти отличия неизбежно касаются не только наименований, но и их содержательных определений, вводимых и используемых в стандартах. Таким образом, на этом пути неизбежно постоянное возникновение путаницы, а это прямо противоположно целям не только стандартов, но и любых грамотных методических документов.

В настоящее время во ВНИИ стандартов подготовлены предложения по совершенствованию и развитию комплекса стандартов по документированию ПС.

Справочная информация

Для приобретения стандартов в области документирования рекомендуем обращаться в следующие организации:

ИПК "Издательство стандартов" , Территориальный отдел распространения НТД (магазин "Стандарты"), 17961, Москва, ул. Донская, д. 8, тел. 236-50-34, 237-00-02, факс/тел. 236-34-48 (в части ГОСТ и ГОСТ Р).