Методология проектирования критического ПО

· В контексте настоящего «Методического руководства…» методология проектирования критического ПО представляется согласованным набором соответствующих моделей, методов, методик и метрик, общего руководства (концепции) по их совместному использованию на различных этапах ЖЦ ПО для достижения демонстрируемого требуемого уровня качества проекта критического ПО.

· Методология в общем случае определяется выбором иерархии абстракций и используемыми методами декомпозиции ПО как объекта разработки при реализации принципа «разделяй и властвуй». К числу широко используемых относятся объектно-ориентированный, компонентно-ориентированный, функционально-ориентированный и др. подходы и их разновидности [1, 24-29].

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

· Методы программной реализации функциональности ИУС критического использования должны учитывать следующие специфические факторы:

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

б) реальное время – глобальный параметр критического ПО (явно или по умолчанию),

в) взаимодействие ПО с физическим оборудованием,

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

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

ПО как продукт программной инженерии является результатом реализации сети производственных процессов. Международным стандартом ISO/IEC/IEEE 12207:2008 «Системная и программная инженерия – Процессы жизненного цикла ПО» определена Опорная (ссылочная) модель процессов ЖЦ ПО (Process Reference Model) [1] (рис.1). Модель включает семь категорий процессов системной и программной инженерии, обеспечивающих исчерпывающее стандартное (унифицированное) представление всех типов процессов, выполняемых при использовании различных моделей ЖЦ программных продуктов (приложений).

Рис.1. Опорная модель процессов ЖЦ ПО системной и программной инженери

Согласование системного и программного контекстов процессов ЖЦ ПО («наблюдение» за состоянием реализации специальных процессов ПО в общем контексте системной инженерии) осуществляется с использованием модели переходов состояний проекта в соответствии со стандартом ECSS-ST-E-40 «Программное обеспечение», представленной на рис.2 [6.13]. Механизм переходов реализуется с использованием стандартных процессов Review и Audit опорной модели ISO/IEC/IEEE 12207:2008 «Системная и программная инженерия – Процессы жизненного цикла ПО».

· Выбор абстракций. Декомпозиция (реализация принципа «разделяй и властвуй» - “divide et impera”). Нотации (графические языки, проектные зарисовки – adornment, аксиоматика, синтаксис) [6.14].

· Реализация «4+1» парадигмы представления архитектуры критического ПО (рис. 3), определяющей сбалансированную совокупность форм представления проектных решений архитектурного проекта: «1» - функции, «2» - компоненты, «3» - динамические спецификации, «4» - размещение на платформе, «4+1» - множество вариантов использования.

· Языки описания архитектуры (Architecture framework and architecture description languages – ADL) на основе стандарта ISO/IEC/IEEE 42010:2011 «Системная и программная инженерия – описание архитектуры» [3].

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

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

b) Объективно действует тенденция “creep requirement” (ползучесть, изменчивость требований) при создании сложных систем (а тем более систем беспрецедентной сложности) и необходимость, как следствие, реализация технологии создания ряда функциональных прототипов разрабатываемого критического ПО.

Такие технологии позволяют управлять полнотой и достоверностью исходных данных и требований к разработке критического ПО при использовании спиральной модели ЖЦ ПО в рамках как классических, так и agile-технологий.

· Анализ, метрики и оценка композиционной, многокомпонентной характеристики качества критического ПО «Гарантоспособность» (Dependability), включающей субхарактеристики Надежность, Готовность, Обслуживаемость, Безопасность (в ряде случаев).

Рис.2 Модель переходов состояний в ЖЦ проекта критического ПО

Рисунок 3 «4+1» парадигма архитектуры ПО.

2.2.2 Квалификационные испытания критического ПО [1, 2, 3, 6, 3, 15]:

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

SFMECA - Анализ видов, последствий и критичности отказов ПО (Software failure mode, effects and criticality analysis);

SFTA - Анализ дерева дефектов (Software Fault Tree Analysis);

HSIA - Анализ аппаратно-программных взаимодействий (Hardware-software interaction analysis);

HA, HAZOP - Анализ безопасности (Hazard analysis) и анализ эксплуатационной безопасности (hazard and operability analysis);

SCCFA - Анализ отказа по общей причине (Software common cause failure analysis)

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

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

· Классификация, анализ ограничений и обоснование выбора методов (тестирование, имитационное моделирование, формальный анализ, статический анализ, model-checking верификация) для верификации, валидации, сертификации, аттестации критического ПО.

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

· Ограничения и предельные возможности верификации в условиях «комбинаторного взрыва» в пространстве «состояния-переходы» критического ПО, диверсифицированная (полимодельная) model-checking верификация с использованием темпоральной логики и инварианто-ориентированных моделей критического ПО.

· Квалификационные испытания критического ПО в «расцепленной V-модели» ЖЦ при модернизациях ИУС в течении длительной эксплуатации на объектах заказчика. Верификация ПО на объектах Заказчика. Цели. Задачи. Методология. Независимая верификация. Роль мобильных инструментальных комплексов (МИК).