Лекция 16. Документирование в процессах жизненного цикла ПО. Стандарты управления жизненным циклом автоматизированной системы

1.1        Документация и ее роль в обеспечении качества

Документирование ПО определяется стандартами ГОСТ серии 19, 34, ГОСТ Р ИСО/МЭК 8631, ГОСТ Р ИСО 9127, ГОСТ Р ИСО/МЭК ТО 9294. Полный перечень нормативных документов на программную документацию приведен в документе Методика экспертизы программной документации, находящегося на стадии утверждения.

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

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

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

Эффективность выполнения руководящей роли можно рассматривать как основанную на следующих трех элементах.

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

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

3. Признаки руководящих обязанностей и поддержки - требует обеспечить:

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

В ГОСТ Р ИСО/МЭК ТО 9294-93 программная документация рассматривается как имеющая следующие шесть основных функций.

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

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

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

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

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

6. Исторические справки. Документация, требуемая в качестве исторической справки по проекту. Данная документация может помочь в переносе и переводе ПО в новое окружение.

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

Стратегия должна поддерживать основные элементы эффективного документирования:

1.      требования документации охватывают весь жизненный цикл ПО;

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

3.      документация должна соответствовать ее читательской аудитории;

4.      работы по документированию должны быть объединены в общий процесс разработки ПО;

5.      должны быть определены и использованы стандарты по документированию;

6.      должны быть определены средства поддержки.

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

1.     модели жизненного цикла ПО;

2.     типов и взаимосвязей документов;

3.     содержания документа;

4.    качества документа; 

5.     форматов документа; 

6.     обозначение документа.

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

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

- какие типы документов требуются? 

- каков объем представляемой документации?

- что документы содержат?

-какой уровень качества будет достигнут?

- где документы будут созданы?

- как документы будут хранить, сопровождать и обращать?

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

Основными ресурсами, требуемыми для документирования, являются следующие: персонал, средства, финансирование.

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

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

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

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

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

График документирования должен распределять время для:

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

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

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

редактирование при внесение комментариев, появившихся при проверке;

проведения согласования;

перевода;
распространения.

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

Более подробно рассмотрим стандарты и руководства, принимаемые в организации.

1. Выбор модели жизненного цикла ПО.

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

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

В рамках ИСО/МЭК 12207 документирования решаются при вызове каким-либо процессом ЖЦ процесса документирования.

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

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

Реализация. Это действие состоит из следующих задач.

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

а) название или имя;

б) цель;

в) назначение;

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

д) расписание промежуточной и конечной версий.

Проектирование и разработка. Это действие состоит из следующих задач.

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

2. Источник и соответствие входных данных для документов должны быть гарантированы. Должны быть использованы автоматические средства документирования.

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

Производство. Это действие состоит из следующих задач.

1. Документы должны быть произведены и упакованы. В соответствии с планом, ими должны быть обеспечены все заинтересованные стороны. Производство и распространение документов может быть выполнено в бумажном, электронном виде. Исходные материалы должны храниться в соответствии с условиями записи, секретности, сопровождения и резервных копий проекта.

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

Сопровождение. Это действие состоит из следующих задач.

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

Стадия Рабочая документация ГОСТ 34.601 частично соответствует привлечению процесса документирования процессов разработки по ИСО/МЭК 12207. Название данной стадии не точно отражает ее содержание, так как она содержит этап 6.2 - Разработка или адаптация программ. Кроме того, процесс документирования выполняется на стадиях эскизного и технического проекта. По ГОСТ 19.102 этап разработки программной документации появляется только на стадии Рабочий проект. Такое позднее начало документирования процессов ЖЦ не в состоянии обеспечить ни требуемого качества документации, ни требуемого качества ПО.

Таким образом, терминология и концепция в области документирования ИСО/МЭК 12207 представляются более удачными. Можно рекомендовать при использование ГОСТ 34.601 для этапов 4.2, 5.2, 5.3, 6.1 учитывать в содержании работ задачи, определенные в ИСО/МЭК 12207 для процесса документирования

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

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

документация разработки;

документация продукции;

документация управления проектом.

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

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

Разработка документов преследует пять целей:

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

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

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

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

д) они описывают историю разработки ПО.

Типовыми документами разработки являются:

анализы осуществимости и исходные заявки;

спецификации требований и функций;

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

планы разработки, сборки и тестирования ПО;

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

защитная и текстовая информация.

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

Документация продукции преследует три цели:

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

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

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

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

учебные руководства;

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

руководства по сопровождению ПО;

брошюры и информационные листки, посвященные продукции.

ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских пакетов вводит определение документации пользователя, как документации, которая обеспечивает пользователей информацией, необходимой для установки и прогона ПО и является обязательной в поставке (документация пользователя выполняется в виде одного или нескольких руководств и вкладывается вместе с программным продуктом внутрь упаковки).

Данный стандарт определяет три категории информации:

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

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

Назначением документации пользователя является обеспечение конечного пользователя достаточной информацией для ясного понимания:

цели, функций и характеристик ПО;

того, как ввести в действие и использовать ПО;

договорных прав и обязанностей.

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

Таким образом, ГОСТ Р ИСО 9127, не имея формальных ссылок на ГОСТ Р ИСО/МЭК ТО 9294, фактически дополняет введенное в нем понятие документации продукции.

3. Документация управления проектом. Документы создаются на основе информации управления проектом, такой как:

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

отчеты о решениях, связанных с разработкой;

распределение обязанностей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.1.1      Стандарты управления жизненным циклом автоматизированной системы

Ø ГОСТ 19.102-77 Единая система программной документации. Стадии разработки

Ø ГОСТ 19.201-78* Единая система программной документации. Техническое задание. Требования к содержанию и оформлению

Ø ГОСТ 2.503-90 ЕСКД. Правила внесения изменений

Ø ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания

Ø ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

Ø ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств

Ø РД 50-34.698-90 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов

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

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

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

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

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

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

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

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

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

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

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

Таблица 3.1

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

ГОСТ 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

корректны;

Таблица 3.3

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

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

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

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

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

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. Ограничения на совместимость. Необходимо рассматривать несколько аспектов совместимости:

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

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

изделиями-компаньонами (т.е. относящимися к той же группе средств и являющимися альтернативой);

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

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

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

3.3.n.2. Внешние характеристики.

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

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

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

3.3.n.2.3. Входы. Описание подобно п. 3.3.2.1

3.3.n.3. Эргономические характеристики.

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

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

защита данных пользователя;

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

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

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

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

4. ИСПОЛЬЗУЕМЫЕ МАТЕРИАЛЫ (в т.ч. справочные)

5. ПЕРЕДАЧА ЗАКАЗЧИКУ И ВВОД В ДЕЙСТВИЕ.

Скачано с www.znanio.ru