Читать «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию» онлайн - страница 14

5.4 Проектирование системы

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

5.4.1 Проектные решения системного уровня

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

Результаты должны быть включены в раздел проектных решений системного уровня документа «Описание проекта системы/подсистемы» (12.15). В зависимости от условий контракта часть проекта, имеющая отношение к интерфейсам, может быть включена в Описание проекта системы/подсистемы или в Описание проекта интерфейса (12.17), а часть проекта, имеющая отношение к базам данных, — в Описание проекта системы/подсистемы или в Описание проекта базы данных (12.18).

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

5.4.2 Проектирование архитектуры системы

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

5.5 Стратегии архитектурного проектирования системы

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