О чем гласит документ do 178B

1. Введение

Документ DO-178B (Software Considerations in Airborne Systems and Equipment Certification) был разработан рабочей группой и утвержден RTCA 1 декабря 1992 года с целью определения требований (рекомендаций) к процессу разработки бортового программного обеспечения для воздушных судов гражданской авиации. Практически это продукт совместного производства американской команды RTCA, представляющей интересы правительственного органа FAA (Federal Aviation Administration) и фирм-производителей, и европейской группы EUROCADE (European Organisation for Civil Aviation Equipment). В России аналогичный документ носит название КТ-178В.

По сравнению со своим предшественником – DO-178A, в DO-178B несколько смягчены требования по представлению документации программного проекта в сертифицирующий орган. Одним из принципиальных различий, является переход от «водопадной» модели жизненного цикла проекта, выделяющей его отдельные стадии (этапы), к процессной модели. Таким образом, в рамках DO-178B программный проект и производство программного продукта рассматриваются как совокупность параллельно текущих и взаимодействующих процессов.

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

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

Производственным процессам посвящены соответственно главы 4, 5 и 6. Процесс конфигурационного управления рассматривается в седьмой главе документа. При этом некоторые его аспекты затрагиваются в четвертой главе, посвященной планированию, а некоторые в главе 11, посвященной данным процесса разработки, а требования к процессам Обеспечения Качества и Взаимодействия с Сертифицирующим Органом определены соответственно в 8 и 9 главах.

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

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

Документ DO-178B сопровождают два приложения А и В. В приложении А приведены таблицы (10 штук) определяющие состав и правила ведения документации проекта (зависимость от категории критичности). Приложение В содержит глоссарий.

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

Рисунок 1. Процессы разработки программного обеспечения

На Рис.2 приведена структурная схема, иллюстрирующая назначение и область распространения требований секций (глав) документа DO-178B. Следует отметить, что его структура дает несколько иной взгляд на роль процессов, чем тот, который был упомянут выше. В его рамках процессы верификации, конфигурационного управления, обеспечения качества и сертификации отнесены к интеграционным процессам разработки программного обеспечения.

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

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

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

Рисунок 2. Структура документа DO-178B

Знание документа DO-178B, его назначения и структуры является обязательным, но не достаточным для квалифицированного выполнения работ на предприятии «БАРС». Дополнительным материалом, необходимым для качественного выполнения работ, являются требования ISO 9001-2000, AS 9100, стандарты предприятия и стандарты проектов предприятия. Однако многие конкретные процедуры стандартов прямо следуют из требований DO-178B или являются конкретизацией этих требований, учитывающей специфику принятых на предприятии «БАРС» решений по организации производственных процессов.

2. Общесистемные аспекты разработки программного обеспечения

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

Ключевым для решения этого вопроса является понятие категории критичности системы в целом.

Опираясь на классификации FAA, DO-178B перечисляет следующие категории критичности отказов систем:

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

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

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

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

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

Перечисленным выше категориям присвоены соответственно индексы a, b, c, d, e. Наиболее критичными, а соответственно и требующими большего внимания в период разработки, являются системы, отказы которых имеют категории a и b.

На основании категорий критичности системных отказов вводится классификация уровней критичности отказов программного обеспечения. Они так же индексируются буквами латинского алфавита от Level A до Level E.

Level A: ненормальное поведение программного обеспечения может привести к катастрофическому отказу.

Level B: ненормальное поведение программного обеспечения может привести к опасному/чрезвычайно важному отказу.

Level C: ненормальное поведение программного обеспечения может привести к важному отказу.

Level D: ненормальное поведение программного обеспечения может привести к маловажному отказу.

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

По причине несущественности отказов программного обеспечения, относящихся к уровню E, его дальнейшее рассмотрение в рамках документа DO-178B не производится. Фактически далее рассматриваются только вопросы разработки программных средств уровней A, B, C и D.

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

Дополнительно DO-178B указывает на возможные пути повышения безопасности системных решений в области программного обеспечения. К ним относятся, в частности, разделение программных функций на независимые процессы, параллельная разработка нескольких вариантов реализации одной и той же функциональности. Более подробно аспекты применения подобных приемов разработки рассматриваются в главе 12.

3. Жизненный цикл программного обеспечения

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

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

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

Рисунок 3. Варианты жизненных циклов программных компонент

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

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

4. Процесс планирования программного обеспечения

Задачи процесса планирования включают в себя:

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

• Определение жизненного цикла программного обеспечения;

• Определение инструментария программного проекта;

• Определение необходимых стандартов программного проекта;

• Определение состава документации в соответствии с требованиями и уровнем критичности программного обеспечения.

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

Не вдаваясь в детали требований приложения А-1 можно сказать, что для уровней критичности A, B и C, требования по составу документов идентичны. А для разработки программного обеспечения, относящегося к уровню D, они значительно ослаблены. Так для уровня D не является обязательным определение критериев перехода от одной процедуры жизненного цикла к другой, фиксация инструментальных средств, разработка стандартов. Принципиально необходимым считается только определение процедур интеграционных процессов и процессов разработки программного обеспечения.

В свою очередь требования к конфигурационному управлению документами процесса планирования идентичны для уровней A и B, но упрощены для программных проектов уровня C и D.

5. Процесс разработки программного обеспечения

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

• Процесс разработки требований;

• Процесс проектирования;

• Процесс кодирования;

• Процесс интеграции.

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

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

При этом можно упрощенно рассматривать процесс разработки как процесс последовательной трансляции

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

• требований высокого уровня в требования низкого уровня;

• требований высокого и низкого уровней в проект (архитектуру) программного обеспечения;

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

• требований и кода в верификационные (тестовые) планы и т.д.

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

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

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

6. Процесс верификации программного обеспечения

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

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

2. Проверку соответствия разработанных требований низкого уровня требованиям высокого уровня и требованиям к системе в целом;

3. Проверку реализации требований высокого и низкого уровней в архитектуре программного обеспечения;

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

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

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

В зависимости от уровня критичности программного обеспечения в документе DO-178B устанавливаются различные уровни детальности проверки программного кода в процессе верификации.

1. Проверка того, что все требования к программному обеспечению реализованы (100% покрытие требований в процессе тестирования);

2. Проверка того, что выполнено требование (a) и при этом все команды программного кода были выполнены в процессе тестирования (100% покрытие кода в процессе тестирования);

3. Проверка того, что выполнено требование (b) и при этом все ветви программного кода были выполнены в процессе тестирования (100% покрытие ветвей программного кода в процессе тестирования);

4. Проверка того, что выполнено требование (c) и при этом все условия разветвления программного кода были независимо проверены в процессе тестирования.

Очевидно, что требования (a) полностью ориентировано на тестирование программного обеспечения, как «черного ящика». Другими словами, исследователь программного кода при этом рассматривает объект исследования только снаружи. Он оказывает входные воздействия, определяемые требованиями, и наблюдает значения на выходе, сравнивая их с ожидаемыми (вытекающими из требований). Ни каких сведений о внутреннем устройстве (структуре и особенностях реализации) программного кода при таком подходе не должно использоваться.

При выполнении тестирования, соответствующего уровням требований (b) и (c) в ряде случаев удается оставаться в рамках концепции «черного ящика», по крайней мере, на этапе проверки требований. Большинство сред поддержки тестирования (эмуляторов, отладчиков) позволяют произвести сбор покрытий программного кода. Но выявление причин недостаточного уровня покрытия, требует сопоставления функциональных требований и способа их реализации в программном коде.

Поэтому выполнение тестирования по уровням требований (b) и (c), как правило, можно рассматривать в рамках концепции «серого ящика». Такой подход предполагает использование при исследовании объекта некоторых свойств его структуры. Но надо заметить, что эти сведения должны привлекаться только для анализа причин непокрытия кода.

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

Таблицы с А-3 по А-7 приложения к документу DO-178B дают представление о составе документов, которые должны быть разработаны и находится под управлением процесса верификации. Там же определяется уровень (категория) конфигурационного управления соответствующей документацией.

7. Процесс конфигурационного управления

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

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

Еще один термин, используемый в процессе конфигурационного управления – Базовая Конфигурация (Baseline). Под базовой конфигурацией (БК) понимается объект конфигурационного управления (отдельный элемент или совокупность элементов), который прошел процедуру утверждения и может быть изменен только в рамках процедуры Управления Изменениями.

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

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

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

• Объективность и контролируемость данных проекта;

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

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

• Точки контроля, возможность вычисления статуса конфигурации и управления изменениями через управление ОКУ и создание БК;

• Фиксацию проблем и отслеживание принятых по ним решений;

• Возможность прослеживания состояния проекта путем контроля выходных данных его жизненного цикла;

• Гарантии соответствия производимой продукции предъявляемым к ней требованиям;

• Ограничения доступа и сохранность ОКУ.

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

8. Процесс обеспечения качества программного обеспечения

• Обеспечение (гарантия) качества это не просто тестирование.

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