ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию

Цели данного процесса состоят в том, чтобы:

а) разработать архитектуру ПО и требования нижнего уровня на основе требований верхнего уровня;

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

Входными данными процесса проектирования ПО являются требования к ПО, План разработки ПО и стандарты на процесс проектирования ПО. После того как удовлетворены указанные в Плане разработки ПО критерии перехода к данному процессу разработки, эти входные данные используются в процессе проектирования для разработки архитектуры ПО и требований нижнего уровня. Требования нижнего уровня могут включать в себя одно или несколько требований более низких уровней. Основным выходным результатом процесса является документ «Описание проекта ПО» (12.16), который содержит описание архитектуры ПО и требования нижнего уровня. Если это предусмотрено условиями контракта, часть проекта, имеющая отношение к интерфейсам, может быть включена в документ «Описание проекта интерфейса» (12.17), а часть проекта, имеющая отношение к базам данных, может быть включена в документ «Описание проекта базы данных» (12.18). Процесс проектирования ПО считают завершенным, когда удовлетворены его цели и цели связанных с ним интегральных процессов. Процесс проектирования ПО должен обеспечивать следующее:

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

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

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

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

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

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

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

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

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

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

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

Разработчик должен определить и зарегистрировать проектные решения уровня ЭКПО. Результаты должны быть включены в раздел проектных решений уровня ЭКПО документов проектирования ПО (12.16, 12.17, 12.18).

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

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

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

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

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