Основные элементы программной документации

2.4. ГОСТ Р 51904-2002

Созданный специально для встроенных систем, ГОСТ Р 51904-2002 "Программное обеспечение встроенных систем. Общие требования к разработке и документированию" регламентирует общие требования к разработке и документированию программного обеспечения. Во многом этот ГОСТ повторяет общеизвестные международные стандарты типа DO-178B, принятые при сертификации авиационного встроенного программного обеспечения.

Одним из принципиальных моментов является использование не водопадной модели жизненного цикла проекта, выделяющей его отдельные стадии (этапы), а процессной модели. Таким образом, в рамках ГОСТ Р 51904-2002 и DO-178B программный проект и производство программного продукта рассматриваются как совокупность параллельно текущих и взаимодействующих процессов.

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

Рис. 2.5. Основные и поддерживающие процессы разработки

Трассируемость должна обеспечивать прослеживаемость того:

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

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

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

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

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

Категория A - катастрофическая: отказная ситуация, препятствующая безопасному функционированию объекта управления.

Категория B - опасная/критическая: отказная ситуация, приводящая к уменьшению возможностей объекта управления или способности персонала справиться с неблагоприятными эксплуатационными режимами, при которых возникают:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• разработку требований;
• проектирование программного обеспечения;
• кодирование;
• интеграцию программного кода.

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

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

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

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

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

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

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

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