Определение качества документов.

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

Понятия качества, применимые к содержанию, структуре и представлению документации:

1. качество содержания можно измерять в элементах точности, полноты и ясности;

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

3. качество представления должно соответствовать типу проекта.

4. Определение форматов документов.

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

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

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

5. Определение системы обозначения документов.

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

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

В части требований 2 - 5 отечественные стандарты 19-ой, 34-ой серии, ГОСТ 28195-89 обеспечивают решение задачи формирования комплекта документации, что будет нами рассмотрено ниже.

3.2. Требования стандартов к программной документации

 

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

19-я система стандартов (Единая система программной документации - ЕСПД) устанавливает следующие виды программной документации.

1. Спецификация. Состав программы и документация на нее.

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

3. Текст программы. Запись программы с необходимыми комментариями.

4. Описание программы. Сведения о логической структуре и функционировании программ.

5. Программа и методика испытаний. Требования, подлежащие проверке при испытании программы, а также порядок и методы контроля.

6. Техническое задание. Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний.

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

8. Эксплуатационные документы. Сведения для обеспечения функционирования и эксплуатации программы. Перечень эксплуатационных документов представлен в таблице 3.1.

Таблица 3.1

Вид эксплуатационного документа	Содержание эксплуатационного документа	Регламентирующие стандарты
Ведомость эксплуатационных документов	Перечень эксплуатационных документов на программу.	ГОСТ 19.507-79.
Формуляр	Основные характеристики программы, комплектность и сведения об эксплуатации программы.	ГОСТ 19.501-78.
Описание применения	Сведения о назначении программы, области применения, классе решаемых задач, применяемых методах, ограничениях для применения, минимальной конфигурации технических средств.	ГОСТ 19.502-78.
Руководство системного программиста	Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения.	ГОСТ 19.503-79.
Руководство программиста	Сведения для эксплуатации программы.	ГОСТ 19.504-79.
Руководство оператора	Сведения, необходимые для осуществления действий, связанных с выполнением программы вычислительной системой.	ГОСТ 19.505-79.
Описание языка	Описание синтаксиса и семантики языка.	ГОСТ 19.506-79.
Руководство по техническому обслуживанию	Сведения для применения текстовых и диагностических программ при обслуживание технических средств.	ГОСТ 19.508-79.

 

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

ГОСТ 34.602-89 - техническое задание на создание АС;

ГОСТ 34.201-90 – виды и комплектность документов;

РД 50-34.698-90 - пояснительная записка, схема функциональной структуры, общее описание системы, описание постановки задачи, описание информационного обеспечения системы, описание организации информационной базы, перечень входных сигналов и данных, перечень выходных сигналов/документов, описание программного обеспечения;

ГОСТ 19.201-78 – техническое задание;

ГОСТ 19.402-78 – описание программы;

ГОСТ 19.404-79 – пояснительная записка;

ГОСТ 19.301-79 – программа и методика испытаний.

Техническое задание. Содержание технического задания на разработку программных продуктов должно соответствовать ГОСТ 19.201-78 “Техническое задание. Требования к содержанию и оформлению”. Помимо разработки технического задания на все ПО могут разрабатываться технические задания на этапы, например, техническое задание на выполнение НИР.

Согласно ГОСТ 19.201-78 техническое задание на разработку ПО должно включать следующие разделы:

введение;

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

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

требования к программе;

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

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

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

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

приложения.

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

В разделе “Введение” указывается наименование, краткая характеристика области применения ПО.

В разделе “Основания для разработки” указывается:

документ (документы), на основание которых ведется разработка;

организация, утвердившая документ, и дата утверждения;

наименование (условное обозначение) темы разработки.

В разделе “Назначение разработки” должно быть указано функциональное и эксплуатационное назначение ПО.

В раздел “Требования к программе” включаются следующие подразделы.

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

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

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

4. Требования к составу и параметрам технических средств – необходимый состав технических средств (конфигурация) с указанием их основных технических характеристик.

5. Требования к информационной и программной совместимости, в котором указываются требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым ПО. Кроме того, могут указываться протоколы межмашинного сетевого обмена данными, стандарты протоколов формализации данных и управления терминалами, стандарты и форматы сообщений, протоколы транзакций, протоколы запросов данных, стандарты представления данных, требования к СУБД и операционным системам.

6. Требования к маркировке и упаковке.

7. Требования к транспортированию и хранению.

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

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

В разделе “Стадии и этапы разработки” устанавливают необходимые стадии разработки, этапы и содержание работ (перечень документов, которые должны быть разработаны, согласованы и утверждены), а также сроки разработки и исполнителей.

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

В приложениях к техническому заданию при необходимости приводят:

перечень научно-исследовательских и других работ, обосновывающих разработку;

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

другие источники разработки.

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

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

2. Назначение и цели создания АС, в котором указывают назначение системы и цели ее создания..

3. Характеристика объекта автоматизации.

4. Требования к системе. Данный раздел состоит из следующих подразделов.

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

б) Требования к функциям.

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

5. Состав и содержание работ по созданию (развитию) АС.

6. Порядок контроля и приемки системы.

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в действие.

8. Требования к документированию.

9. Источники разработки.

Основное внимание уделим руководящему документу РД 50-34.698-90, устанавливающий требования к содержанию документов на автоматизированные системы. Структура РД 50-34.698-90 приведена в таблице 3.2.

Содержание документов, разрабатываемых на предпроектных стадиях (“Формирование требований к АС” и “Разработка концепции АС”), приведено в рекомендуемом приложении к РД 50-34.698-90. На первой стадии разрабатывается отчет (согласно ГОСТ 7.32) и заявка на разработку АС. На второй – отчет согласно ГОСТ 7.32.

Содержание организационно-распорядительных документов установлено также в рекомендуемом приложении. К организационно-распорядительным документам относятся:

акт завершения работы;

акты приемки в опытную и промышленную эксплуатацию;

план-график работ;

приказы о проведении работ и составе приемочной комиссии;

протоколы испытаний и согласования.

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

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

В разделе “Структура ПО” приводят перечень частей ПО с указанием их взаимосвязей и обоснованием выделения каждой из них. В разделе “Функции частей ПО” приводят назначение и описание основных функций для каждой части ПО.

В разделе “Методы и средства разработки ПО” приводят перечень методов программирования и средства разработки ПО АС с указанием частей ПО, при разработке которых следует использовать соответствующие средства и методы.

В разделе “Операционная система” указывают следующее.

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

2. Наименование руководства, в соответствие с которым должна осуществляться генерация выбранного варианта операционной системы.

3. Требования к варианту генерации выбранной версии операционной системы.

Раздел “Средства, расширяющие возможности операционной системы” содержит подразделы, в которых для каждого используемого средства, расширяющего возможности операционной системы, указывают:

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

наименование руководства, в соответствие с которым следует настраивать используемое средство на конкретное применение;

требования к настройке используемого средства.

Таблица 3.2.

Область	Документы	Содержание
Документы по общесистемные решения	1. Ведомость эскизного (технического) проекта 2. Пояснительные записки к эскизному, техническому проектам	Выполняется по ГОСТ 2.106   Согласно РД 50-34.698-90
3. Схема функциональной структуры 4. Ведомость покупных изделий	Согласно РД 50-34.698-90   Выполняется по ГОСТ 2.106
5. Описание автоматизируемых функций 6. Описание постановки задачи	Согласно РД 50-34.698-90   Согласно РД 50-34.698-90
7. Паспорт	Согласно РД 50-34.698-90
8. Проектная оценка надежности системы 9. Общее описание системы	Согласно РД 50-34.698-90 Согласно РД 50-34.698-90
10. Программа и методика испытаний 11. Схема орг. структуры	Согласно РД 50-34.698-90 Согласно РД 50-34.698-90
Документы с решениями по организационному обеспечению	1. Описание организационной структуры 2. Методика автоматизированного проектирования	Согласно РД 50-34.698-90   Согласно РД 50-34.698-90
3. Технологическая инструкция 4. Руководство пользователя	Согласно РД 50-34.698-90 Согласно РД 50-34.698-90
5. Описание технологического процесса обработки данных	Согласно РД 50-34.698-90
Документы с решениями по техническому обеспечению (основные)	1. Схема автоматизации 2. Описание комплекса технических средств	Согласно РД 50-34.698-90 Согласно РД 50-34.698-90
3. ТЗ на разработку специализированных технических средств 4. Схема структурная комплекса технических средств (КТС)	Согласно ГОСТ 15.001   Согласно РД 50-34.698-90
Документы с решениями по информационному обеспечению (основные)	1. Перечень входных сигналов и данных 2. Перечень выходных сигналов	Согласно РД 50-34.698-90   Согласно РД 50-34.698-90
3. Описание ИО системы	Согласно РД 50-34.698-90
5. Описание организации информационной базы	Согласно РД 50-34.698-90
6. Описание системы классификации и кодирования 7. Описание массива информации	Согласно РД 50-34.698-90   Согласно РД 50-34.698-90
	8. Массив входных данных 9. Каталог БД	Согласно РД 50-34.698-90 Согласно РД 50-34.698-90
10. Состав выходных данных 11. Инструкция по формированию и ведению БД	Согласно РД 50-34.698-90 Согласно РД 50-34.698-90
Документы с решениями по техническому обеспечению	1. Описание программного обеспечения	Согласно РД 50-34.698-90
Документы с решениями по математическому обеспечению	1. Описание алгоритма (проектной процедуры)	Согласно РД 50-34.698-90

“ Пояснительная записка к эскизному (техническому) проекту ” содержит следующие разделы (согласно РД 50-34.698-90): общие положения; описание процесса деятельности; основные технические решения; мероприятия по подготовке объекта автоматизации к вводу системы в действие.

В разделе “Общие положения” приводят:

наименование проектируемой АС и наименование документов, их номера и дату утверждения, на основании которых ведут проектирование АС;

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

цели, назначение и область использования АС;

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

сведения об использованных при проектирование нормативно-технических документах;

сведения о НИР, передовом опыте, изобретениях, использованных при разработке проекта.

В разделе “Описание процесса деятельности” отражают состав процедур (операций) с учетом обеспечения взаимосвязи и совместимости процессов автоматизированной и неавтоматизированной деятельности, формируют требования к организации работ в условиях функционирования АС.

В разделе “Основные технические решения” приводят:

решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы, подсистем;

решения по взаимосвязям АС со смежными системами, обеспечению их совместимости;

решения по режимам функционирования, диагностированию работы АС;

решения по численности, квалификации и функциям персонала АС, режимам его работы, порядку взаимодействия;

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

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

решения по комплексу технических средств, его размещению на объекте;

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

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

В разделе приводят в виде иллюстраций другие документы, которые допускается включать по ГОСТ 34.201.

В разделе “Мероприятия по подготовке объекта автоматизации к вводу системы в действие” приводят:

мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ;

мероприятия по обучению и проверке квалификации персонала;

мероприятия по созданию необходимых подразделений и рабочих мест;

мероприятия по изменению объекта автоматизации;

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

Рассмотрим содержание ряда документов, определенных в стандарте DO–178B. Некоторые документы, именуемые в данном стандарте как “данные жизненного цикла ПО”, уже рассматривались нами в разделе 2.

В DO–178B определено, что данные жизненного цикла могут принадлежать к одной из двух категорий: Категории Управления 1 и Категории Управления 2. Эти категории связаны с элементами управления конфигурацией. Данное разделение позволяет иметь средства управления затратами на разработку там, где может применяться менее строгий контроль без снижения степени защищенности данных. В приложении А к документу DO–178B приведены минимальные категории управления, назначенному каждому виду данных и их вариации в зависимости от уровня ПО (А, В, С, D, Е). Ниже, в таблице 3.3, представлены некоторые фрагменты целей этапов жизненного цикла и их выходы – данные жизненного цикла.

Документ DO–178B устанавливает, что приложение А не предназначено для представления всех данных, необходимых для создания ПО, и не предусматривает какого-либо определенного способа хранения этих данных или их организации внутри структур хранения. В дополнении к указанным документам могут вырабатываться другие, необходимые для сертификации ПО.

Характеристики данных жизненного цикла ПО следующие:

непротиворечивость: информация непротиворечива, если она записана в терминах, допускающих единственное толкование и дополненная, по необходимости, определениями;

полнота: информация полна, если она включает все необходимые требования и/или описательные материалы; все используемые диаграммы имеют комментарии, единицы измерения и термины полностью определены;

проверяемость: информация проверяема, если она может быть проконтролирована на предмет корректности;

состоятельность; информация состоятельна, если внутри нее нет конфликтов;

модифицируемость: информация модифицируема, если она структурирована и стилизована таким образом, что вносимые изменения полноценны, непротиворечивы и корректны;

 

 

Таблица 3.3

№ п/п	Цели	Применяемость, в зависимости от уровня ПО	Выходы	Категория управления, обуславливаемая уровнем ПО
	Описание	А	В	С	D		А	В	С	D
Этап планирования ПО
1.	Определение действий на этапе разработки и интегрированном этапе	*	*	*	*	План программных аспектов сертификации
2.	Определение критериев перехода, взаимосвязей и согласованности между этапами	*	*	*		План разработки ПО План верификации ПО План управления конфигурацией ПО
3.	Определение среды ЖЦ ПО	*	*	*	*	План определения качества ПО
5.	Определение стандартов разработки ПО	*	*	*		Стандарты требований к ПО Стандарты проектирования ПО Стандарты кодирования ПО
Этап разработки ПО
1.	Разработка ВУ требований	*	*	*	*	Данные требований к ПО
2.	Определение установленных ВУ требований	*	*	*	*	Данные требований к ПО
3.	Разработка архитектуры ПО	*	*	*	*	Описание проектирования
6.	Разработка исходного кода	*	*	*	*	Исходный код
Верификация выходов подэтапа определения требований к ПО
1.	ВУ требований к ПО подчиняются требованиям к системе	-	-	*	*	Результаты верификации ПО
2.	ВУ требований точны и согласованы	-	-	*	*	Результаты верификации ПО
7.	Алгоритмы точны	-	-	*		Результаты верификации ПО
Тестирование выходов подэтапа интеграции
1.	Исполняемый объектный код подчиняются ВУ требованиям	*	*	*	*	Варианты и процедуры верификации ПО Результаты верификации ПО
4.	Исполняемый объектный код точно соответствует НУ требованиям	-	*	*		Варианты и процедуры верификации ПО Результаты верификации ПО
“-” - цели должны быть удовлетворены независимо; “*” – цели должны быть удовлетворены; 1 – данные удовлетворяют Категории Управления 1; 2 – данные удовлетворяют Категории Управления 2.

 

трассируемость: информация трассируема, если могут быть определены источники ее компонентов;

форма; форма должна обеспечить возможность эффективно получать доступ к данным жизненного цикла По в течение всего срока службы системы;

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

Дадим краткую характеристику основных данных жизненного цикла ПО.

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

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

2. Обзор ПО. Здесь коротко описывают функции ПО с акцентом на предлагаемый уровень концепции безопасности.

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

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

5. Данные жизненного цикла ПО. Этот раздел определяет данные, которые будут выработаны и управляемы подэтапами ЖЦ ПО. Здесь также описывается отношение данных друг к другу и другим данным, определяющим систему, данные, требуемые для сертификации, форма данных и т.д.

6. Планировка. Этот раздел описывает средства, которые будут использованы разработчиком для предоставления отчетности по деятельности в течение жизненного цикла ПО при сертификации.

7. Дополнительные аспекты. Здесь приводятся специфические возможности, которые могут повлиять на этап сертификации: например, альтернативные методы обеспечения соответствия, оценка качества инструментальных средств, ранее разработанное ПО и т.д.

 

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

1. Среда. Описание среды оценки качества ПО, включая структуру, организационные ответственности и интерфейсы, стандарты, процедуры, средства, методы и метрики.

2. Полномочия. Характеристика полномочий, ответственности и независимости оценки качества ПО.

3. Методы. Методы оценки качества ПО, которые должны использоваться для каждого подэтапа жизненного цикла ПО на всем его протяжении, включая:

методы ОКПО, такие, как обзоры, ведение протоколов, отчеты, проверки и наблюдение за этапами ЖЦ ПО;

методы, относящиеся к оповещению о проблемах и их исправлению;

методы описания проверки ПО.

4. Промежуточный критерий. Устанавливает промежуточный критерий для перехода к этапу оценки качества ПО.

5. Временные требования. Временные требования методик этапа ОКПО по отношению к методикам подэтапов ЖЦ ПО.

6. Результаты оценки качества ПО. Описание результатов, выработанных этапом оценки качества ПО.

7. Управление поставщиками. Описание средств оценки соответствия действий поставщиков нижнего уровня плану оценки качества ПО.

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

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

2. Функциональные и операционные требования для каждого режима работы.

3. Критерии функционирования, например, точность.

4. Временные требования и ограничения.

5. Ограничения по размеру памяти.

6. Программные и аппаратные интерфейсы, например, протоколы обмена, форматы данных, частота входных и выходных сигналов.

7. Требования на обнаружение сбоев и мониторинг за безопасностью функционирования.

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

Таким образом, хотя стандарт DO – 178B и не устанавливает явно процессы документирования в своем жизненном цикле, ясно видно, что документации в нем уделено большое внимание.

В заключение данного раздела кратко остановимся на документах, разрабатываемых в ходе процесса создания ПО согласно [2]. В процессе разработки ПО появляются следующие документы, перечисленные ниже в хронологическом порядке:

“Соглашение о требованиях”;

“Внешняя спецификация”;

“Внутренняя спецификация”.

Документ “Соглашение о требованиях” должен содержать первое письменное соглашение между заказчиком и разработчиком о том, что будет сделано, и что не будет делаться при разработке и выпуске программного обеспечения. В отличие от него спецификация предполагает наличие более точных и исчерпывающих формулировок и определений. При этом, первые два документа содержат информацию о том, что представляет собой ПО; а третий должен объяснять, как ПО устроено и как достигаются установленные для него цели и требования. Все документы имеют схожую структуру для облегчения контроля над проектом, а также для обеспечения прослеживаемости всех технических решений от требований до их реализации. По мере продвижения проекта разделы документа либо просто копируются в соответствующие разделы следующего создаваемого документа, либо расширяются описаниями технических решений текущего этапа.

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

1. ОПИСАНИЕ ПРОГРАММНОГО ИЗДЕЛИЯ

1.1. Наименование и шифры ПО (полное наименование, сокращенные наименования, шифры ПО и проекта).

1.2. Краткое описание ПО (включая сведения об авторском праве, иерархию документов, с указанием документов вышестоящих уровней).

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

2. ЦЕЛИ

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

3. СТРАТЕГИЯ

3.1. Соглашения относительно представления материала.

3.1.1. Обозначения (определяются все обозначения, используемые в требованиях: например, если применяются индексы, то дается пример их использования и определяется принцип индексации).

3.1.2. Терминология (особенно специфическая для данного изделия).

3.1.3. Синтаксис (приводятся, если необходимо, синтаксические правила для дальнейшего описания требований).

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

3.3. Системное программное обеспечение (все остальное ПО, включая ОС, утилиты, пакеты прикладных программ, которое классифицируется как основное, поскольку оно “генерирует” ПО предыдущего пункта).

Примечание. Причина такой расстановки пунктов состоит в том, что при правильном проектировании сверху вниз генерируемое программное обеспечение является основной целью проектирования и должно быть описано раньше, чем его генератор. Другими словами, структура генерируемых программ должна определять структуру генератора, а не наоборот. Если все ПО является основным, то в п.3.2. делается пометка “не используется” и опускаются все его подпункты. Структура подпунктов п.п. 3.2 и 3.3 полностью дублируется и далее для простоты используется нумерация только п.п. 3.3.

3.3.n. Общие характеристики функции “n”. Если технически затруднительно и неестественно рассматривать ПО как один большой функциональный модуль, то следует привести его функциональную декомпозицию, показав связи между функциями (функциональными модулями) и присвоив каждой функции некоторое уникальное имя “n”. Затем для каждой функции отводится подраздел раздела 3.3 (т.е. 3.3.1, 3.3.2 и т.д.), в заглавии которого используется слово “функция” с последующим именем функционального модуля. Отметим, что такая функциональная декомпозиция не указывает, как именно ПО будет фактически разбито на программные модули (это составляет содержание документа “Внутренняя спецификация”). Для удобства работы, конечно, полезно иметь некоторое соответствие функционального и фактического разбиения, но это не является требованием и не должно уводить с правильного пути проектирования изделия.

3.3.n.1. Внешние ограничения.

3.3.n.1.1. Стандарты (список используемых промышленных стандартов и собственных стандартов предприятия).

3.3.n.1.2. Ограничения на совместимость. Необходимо рассматривать несколько аспектов совместимости: исходный язык, машинный язык, форматы данных и сообщений, форматы отчетов, форматы листингов и т.п. Специально должна оговариваться совместимость со следующими программными изделиями:

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