2.3 Жизненный цикл разработки ПО с повышенными требованиями к безопасности системы

Жизненный цикл разработки ПО, регламентированный документом DO - 178 [5], заслуживает внимания из следующих соображений. Программное обеспечение, используемое в бортовых системах и оборудование летательных аппаратах, исполняет свою функцию с уровнем доверия к безопасности, которая соответствует требованиям авиационного приложения. Данные требования авиационного приложения отличаются от аналогичных в других сферах более жесткими требованиями по качеству, надежности, так как влияют на безопасность пассажиров и характеристики самого летательного аппарата. Необходимо заметить, что описанные ниже руководящие принципы относительно жизненного цикла, не возведены в ранг закона, но представляют из себя согласие авиационного сообщества.
На рис. 2.2. показан краткий обзор аспектов безопасности информационного потока между этапами жизненного цикла системы и этапами жизненного цикла ПО.
Этап оценки безопасности системы определяет категорию отказа системы. В рамках данного этапа, анализ проекта системы определяет требования, связанные с безопасностью, для аппаратных средств ЭВМ и ПО, для устранения и ограничения влияния ошибок, с ними связанных. Требования, связанные с безопасностью - часть требований к системе, которые вводятся в этапы жизненного цикла ПО. В целях гарантии того, что требования связанные с безопасностью, учитываются на всех этапах жизненного цикла ПО, требования к системе включают:
описание системы и аппаратных средств ЭВМ;
требования сертификации;
требования системы, относящиеся к ПО, включая функциональные и эксплуатационные требования, а также требования, связанные с безопасностью;
уровни ПО, состояния отказа, их категории и связанные с этим функции, относящиеся к ПО;
стратегии безопасности и проект разработки;

Рис.2.2 Информационные потоки между системой и этапами жизненного цикла ПО.

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

Рис. 2.3 Этапы жизненного цикла ПО.

На рис.2.4 показана последовательность этапов жизненного цикла для компонентов еденичного программного продукта с различными жизненными циклами.

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

Компонент W выполняет множество системных требований для разработки программных требований (R), использует эти требования для проектирования ПО (D), исполняет этот проект в исходном коде (C) и тогда интегрирует компонент с аппаратурой (I).
Компонент X показывает использование ранее разработанного ПО, которое уже было сертифицировано.
Компонент Y показывает использование простой отдельной функции, которая может быть закодирована прямо на основе требований к ПО.Компонент Z показывает использование прототипной стратегии. Обычно, целями прототипирования является лучшее понимание требований к ПО и уменьшение технических рисков и рисков разработки. Исходные требования используются как базис для получения прототипа. Этот прототип преобразуется в среду, типичную для конкретного использования системы при разработке. Результатом преобразования является использование уточненных данных.
Этапы жизненного цикла могут носить итерационный характер, т.е. повторяться несколько раз. Количество этапов и итераций варьируется из-за доработок функций ПО, сложности, появления новых требований или нового аппаратного обеспечения, результатов выполнения предыдущих этапов, которые претерпели изменения, а также других особенностей.Практически все этапы жизненного цикла ПО объединяются с интегрированным этапом и действиями по верификации.
Для перехода с одного этапа на другой необходимо предусмотреть критерии перехода. Критерии перехода будут зависеть от запланированной последовательности шагов разработки и шагов интегрированного этапа, а также от уровня ПО (уровень ПО определяется на основе анализа вклада, которое оно вносит в набор потенциальных состояний отказа системы). Например, в качестве критерия перехода можно назвать:
что было выполнено при рецензирование на этапе верификации;
вход определенного элемента конфигурации;
трассировка, проведенная для входа.
Если удовлетворен критерий перехода к последующему этапу, то нет необходимости в том, чтобы каждый вход этого этапа был сформирован до начала его выполнения. Руководящий принцип следующий: если этап производит действия над отдельными входами, последовательность входов должна быть проверена с целью определения того, что выходы предшествующих шагов этапа разработки и интегрированного этапа еще имеют силу.
Рассмотрим подробно цели и действия каждого этапа ЖЦ.
На этапе планирования разработки ПО создаются планы и выбираются стандарты, которые направляют этап разработки и интегрированный этап. Его целью является определение средств для создания ПО, которое будет удовлетворять требования, предъявляемые к нему и обеспечивать достаточный уровень надежности. На этом этапе производиться:
определение действий на этапах разработки и интегрированном этапе, которые будут посвящены определению системных требований и уровня ПО;
определение ЖЦ ПО, включая взаимодействие между этапами, механизм взаимного влияния этапов, критерии оценки ПО при переходе от одного этапа к другому;
определение среды ЖЦ, т.е. методы и инструментальные средства, используемые на каждом этапе;
формирование дополнительных замечаний к ПО;
рассмотрение стандартов разработки ПО, соотношение их с системными целями безопасности, относящиеся к разрабатываемому ПО;
разработка плана создания ПО;
доработка и проверка плана создания ПО.
Эффективность планирования - определяющий фактор при разработке ПО. Основные руководящие принципы этого этапа следующие.
1. План разработки ПО должен быть разработан в такой момент ЖЦ, чтобы обеспечить своевременное управление конкретными действиями на этапе разработки и интегрированном этапе.
2. Стандарты разработки ПО, используемые в проекте, должны быть строго определенными и четкими.
3. Выбранные методы и инструментальные средства должны быть такие, чтобы обеспечили предотвращение ошибок на этапе разработки или свели их к минимуму.
4. Этап планирования разработки ПО должен обеспечить координацию между остальными этапами с целью согласования их стратегий в плане разработки ПО.
5. Этап планирования разработки ПО должен включать в себя средства проверки плана на этапе реализации проекта.
6. На завершающей стадии этапа планирования, план и стандарты разработки ПО должны быть проанализированы на предмет полноты и непротиворечивости.
Другие этапы ЖЦ могут быть начаты до окончания этапа планирования при условии, что имеются планы и процедуры для действий на этих этапах.
План разработки включает в себя следующие компоненты:
Задачей определения среды план программных аспектов сертификации, служащий основным средством объединения предлагаемых методов разработки со службами сертификации;
собственно план разработки, определяющий жизненные циклы и среду разработки;
план верификации ПО, определяющий средства, с помощью которых удовлетворяются цели этапа верификации;
план управления конфигурацией ПО, определяющий средства, с помощью которых удовлетворяются цели этапа оценки качества.
ЖЦ является обоснование методов, инструментальных средств, процедур, языков программирования и аппаратного обеспечения, которые будут использоваться при разработке, верификации, контроле и выпуске данных этапов жизненного цикла и ПО в целом. Примером того, как выбор среды оказывает полезное влияние на ПО, может служить строгое соблюдение стандартов, определение ошибок, предотвращение ошибок исполнения, методов смягчения последствий сбоев в ПО. Среда ЖЦ является потенциальным источником ошибок, которые способствуют возникновению сбоев ПО. На состав среды влияют требования по безопасности, определяемые этапом оценки безопасности системы.
Цель методов предотвращения ошибок - недопущение ошибок в ходе этапа разработки. Основной принцип при выборе требований к разработке ПО, методам его проектирования и программирования заключается в ограничении числа случаев внедрения ошибок и применение таких методов верификации, которые гарантируют установление факта внедрения ошибки.
Целью методов смягчения последствий сбоев является включение характеристик безопасности в проект ПО для гарантии того, что ПО будет корректно реагировать на ошибки входных данных и предотвращать ошибки выходных данных и ошибки управления. Необходимость в методах предотвращения ошибок и смягчения последствий сбоев определяется системными требованиями и этапом оценки безопасности системы.
Среда разработки ПО - определяющий фактор при разработке высококачественного и надежного ПО. Среда может оказывать также и неблагоприятное влияние на процесс разработки ПО. Например, компилятор может вносить ошибки в процессе компиляции, загрузчик может давать сбои при обнаружении ошибок распределения памяти. Руководящие принципы для выбора методов и инструментальных средств среды разработки ПО следующие.
1. В ходе этапа планирования среда разработки должна быть выбрана исходя из минимума потенциального риска для конечного ПО.
2. Использование специализированных инструментальных средств или инструментов и компонентов среды должно производиться путем достижения необходимого уровня гарантии того, что ошибки, вносимые одним компонентом, обнаружились бы другим. В этом случае среда является приемлемой.
3. Действия на этапе верификации и стандарты разработки должны быть определены так, чтобы свести к минимуму потенциальные ошибки, относящиеся к среде разработки ПО.
4. При поиске определенного уровня доверия к сертификации при использовании комбинации инструментов, последовательность действий, производимых этими инструментами, должна быть определена в соответствующем плане.
5. Если определены необязательные характеристики инструментальных средств среды для использования в проекте, то влияние этих характеристик должно быть проверено и специфицировано в соответствующем плане. Это особенно важно там, где инструмент непосредственно создает часть ПО (в этом смысле компиляторы, вероятно, наиболее важный инструмент).
Назначение стандартов разработки ПО является определение правил и ограничений для этапа разработки. Эти стандарты включают в себя:
стандарт требований к ПО, который предназначен для определения методики, правил и средств, используемых при разработке требований высокого уровня, и включает:
а) методы, используемые при разработке требований к ПО (структурные, объектно-ориентированные и др.);
б) нотации, используемые для выражения этих требований (диаграммы потоков данных, спецификации формальных языков и др.);
в) ограничения на использование средств разработки требований;
стандарты проектирования ПО, которые позволяет определить методики, правила и средства, используемые для создания архитектуры ПО и требований низкого уровня и включающие:
а) используемые методы описания процесса проектирования;
б) используемые соглашения по именам;
в) условия, налагаемые на разрешенные методы проектирования (например, использование прерываний и архитектур, управляемых событиями, динамическое управление задачами и т.д.);
г) ограничения на использование средств проектирования;
д) ограничения на конструкцию (например, исключение, рекурсия, динамические объекты, ссылки на данные под разными именами и т.д.);
е) ограничения по сложности (например, максимальное число вложенных вызовов процедур или условных структур, использование безусловных ветвлений и т.д.);
стандарты кодирования ПО, которые позволяют определить языки программирования, методы, правила и средства, используемые для кодирования ПО и включающие:
а) используемые языки программирования и/или их подмножества (для языка необходимо указать данные, которые непротиворечиво определяют синтаксис, поведение управления, поведение данных и сторонние эффекты языка);
б) стандарты на представление исходного кода (например, ограничения на длину строки, отступы, использование пустых строк), стандарты на документирование исходного кода (например, имя автора, дата написания, входные и выходные данные, используемые глобальные переменные);
в) соглашения по именам для компонентов, подпрограмм, переменных, констант;
г) условия и ограничения, налагаемые на разрешенные соглашения по коду (например, степень связей между компонентами ПО и сложность логических и числовых выражений);
д) ограничения на использование средств кодирования.
Этап верификации использует эти стандарты как основу для сравнения выходов этапов с требуемыми результатами. Руководящие принципы для определения стандартов включают в себя следующие.
1. Стандарты должны давать возможность компонентам ПО или взаимосвязанному множеству продуктов разрабатываться единообразно.
2. Стандарты должны обеспечить невозможность использования таких конструкций или методов, в результате выполнения которых получаются выходы, не соответствующие требования безопасности.
Как отмечалось выше, составляющими этапа разработки ПО являются:
подэтап разработки требований к ПО;
подэтап проектирования ПО;
подэтап кодирования ПО;
подэтап интеграции ПО.
При разработке ПО вырабатывается один и более уровней требований к ПО. Требования высокого уровня вытекают непосредственно из анализа требований к системе и ее архитектуры. Далее они развиваются на подэтапе проектирования ПО, формируя один и более последующих уровней требований, более низких. Однако если исходный код генерируется непосредственно из требований высокого уровня (например, компонент Y на рис. 2.4), то они могут рассматриваться одновременно и как требования низкого уровня. В этом случае к ним применяются соответствующие основополагающие принципы формирования.
Разработка архитектуры ПО предполагает принятие решения о структуре ПО. На подэтапе проектирования ПО определяется как архитектура ПО, так и требования низкого уровня - такие требования к ПО, исходя из которых, без какой либо дополнительной информации, может быть непосредственно реализован исходный код.
Каждая из составляющих этапа разработки ПО может порождать производные требования - требования, которые прямо не сводятся к требования высокого уровня. Например, необходимость разработки ПО поддержки прерываний для выбранного целевого компьютера. Требования как высокого (ВУ), так и низкого уровня (НУ) могут включать в себя производные требования. Влияние последних на требования безопасности определяется на этапе оценки безопасности системы.
В таблице 2.6 показаны цели каждого подэтапа, составляющих этап разработки, их входные данные, результаты, основные принципы, применяемые на каждом из них.
Подэтап разработки требований к ПО использует выходные данные жизненного цикла системы для выработки таких требований высокого уровня, как функциональные требования, требования производительности, интерфейсные требования и требования безопасности.
Требования высокого уровня к ПО на подэтапе проектирования перерабатываются в ходе одной или более итераций в архитектуру ПО и требования низкого уровня, которые в свою очередь используются для реализации исходного кода.
На подэтапе кодирования, исходя из архитектуры ПО и требований низкого уровня, вырабатывается исходный код ПО.Целевой компьютер, а также исходный и объектный код, получаемые из подэтапа кодирования, используются совместно с компоновкой и загрузкой данных на подэтапе интеграции для создания интегрированной системы. Подэтап интеграции включает программную и программно-аппаратную интеграцию.
Все подэтапы этапа разработки могут начинаться при удовлетворении планируемого промежуточного критерия перехода. Подэтапы считаются завершенными, когда их цели и цели всех связанных с ними подэтапов достигнуты.
Верификация, входящая в состав интегрированного этапа - это техническая оценка результатов как этапа разработки ПО, так и этапа верификации ПО (последний применяется согласно этапу планирования разработки ПО и плана верификации ПО). Верификация не сводиться только к тестированию ПО. Тестирование, в общем случае, не в состоянии показать отсутствие ошибок, поэтому употребляется термин верификация, а не тестирование.

Таблица 2.6

Наименование подэтапа	Цель подэтапа и входные данные	Результат и основные принципы
Разработка требований к ПО	Цель: - получение требований ВУ; - выработка производных от них требований для этапа оценки безопасности. Входные данные: - требования к системе, аппаратный интерфейс, архитектура системы; - план разработки ПО; - стандарты на требования к ПО.	Первичный результат - данные о требованиях. Основные принципы: - интерфейсные и функциональные требования к системе, реализуемые на базе ПО, должны быть проанализированы на предмет противоречий, несоответствия и неопределенности; - неадекватные и некорректные входные данные должны быть направлены на выработавшие их подэтапы для разъяснения или исправления; - каждое требование к системе, реализуемое на базе ПО, должно быть включено в требования ВУ; - должны быть особо отмечены требования ВУ, соответствующие системным требованиям по предотвращению выхода системы из строя; - требования ВУ должны соответствовать стандартам на требования к ПО; - требования ВУ должны формулироваться в количественных терминах; - требования ВУ не должны описывать детали разработки или тестирования, за исключением указанных и проверенных ограничений конструкции; - каждое системное требование, реализуемое на базе ПО, должно быть сводимо к одному или более требованию ВУ к ПО; - каждое требование ВУ, за исключением производных требований, должно быть сводимо к одному или нескольким системным требованиям; - производные требования ВУ должны быть направлены этапу оценки безопасности системы.
Проектирование ПО	Цель: - создание архитектуры ПО и требований НУ; - выработка производных от них требований для этапа оценки безопасности. Входные данные: - данные о требованиях к ПО; - план разработки ПО; - стандарты проектирования ПО.	Первичный результат - описание разработки, включающее архитектуру ПО и требования НУ. Основные принципы: - создаваемые требования НУ и архитектура ПО должны соответствовать стандартам разработки ПО, быть непротиворечивыми и допускать трассировку и проверку;- определяемые производные требования должны быть проанализированы на предмет соответствия требованиям ВУ; - на подэтапе проектирования ПО следует ввести возможные типы сбоев ПО и наоборот предотвратить остальные, что может изменить ранее назначенный программный уровень и определить дополнительные данные в качестве производных требований, передаваемых этапу оценки безопасности системы; - потоки данных и управления должны быть наблюдаемы согласно требованиям безопасности; - реакции на условия сбоев должны соответствовать требованиям безопасности; - неадекватные или некорректные входные данные должны быть переданы либо этапу оценки жизненного цикла системы, либо подэтапу разработки требований, либо этапу планирования разработки ПО по принципу обратной связи для разъяснения или исправления.
Кодирование ПО	Целью является получение исходного кода, который должен допускать трассировку, проверку, быть непротиворечивым и корректно реализовывать требования НУ. Входные данные: - требования НУ; - архитектура ПО; - план разработки ПО; - стандарты кодирования ПО.	Первичный результат - исходный код и объектный код. Основные принципы: - исходный код должен реализовывать требования НУ и соответствовать архитектуре ПО; - исходный код должен соответствовать стандартам кодирования ПО; - исходный код должен сводиться к описанию проекта; - неадекватные или некорректные входные данные должны быть переданы либо подэтапу разработки требований к ПО, либо подэтапу проектирования ПО, либо этапу планирования разработки ПО по принципу обратной связи для разъяснения или исправления.
Интеграция ПО	Целью является загрузка исполняемого объектного кода в аппаратное или программно-аппаратное обеспечение. Входные данные: - архитектура ПО; - исходный код; - объектный код.	Результат - исполняемый объектный код, а также компонуемые и загружаемые данные. Основные принципы: - исполняемый объектный код должен быть сгенерирован из исходного кода и компонуемых и загружаемых данных; - ПО должно быть загружено в целевой компьютер для программно-аппаратной интеграции; - неадекватные или некорректные входные данные должны быть переданы либо подэтапу разработки требований к ПО, либо подэтапу проектирования ПО, либо подэтапу кодирования ПО, либо этапу планирования разработки ПО по принципу обратной связи для разъяснения или исправления.

Целью этапа верификации является обнаружение ошибок, которые могли быть внесены в ПО на этапе его разработки и корректировка таких ошибок должна производиться на этом же этапе. Основной целью этапа верификации является проверка следующего.
1. Системные требования, реализуемые на базе ПО, были соответствующим образом воплощены в требования высокого уровня.
2. Требования высокого уровня были соответствующим образом воплощены в архитектуре ПО и требованиях низкого уровня.
3. Архитектура и требования низкого уровня были соответствующим образом воплощены в исходном коде.
4. Исполняемый объектный код соответствует требованиям к ПО.
5. Средства, используемые для достижения выше перечисленных целей, являются технически корректными и функционально законченными для программного уровня.
Методы этапа верификации базируются на комбинации обзоров, анализе, разработке тестовых событий и процедур и последующего их исполнения. Обзоры и анализ обеспечивают оценку точности, полноты и проверяемости требований к ПО, архитектуре ПО и исходного кода Разработка тестовых событий обеспечивает более полную оценку внутренней состоятельности ПО и полноту требований к нему. Выполнение тестовых процедур обеспечивает демонстрацию соответствия ПО назначенным требованиям.
Входные данные этапа верификации: требования к системе, требования к ПО и архитектуре ПО, данные о трассируемости, исходный код, исполняемый объектный код, план верификации ПО.
Выходные данные этапа верификации ПО фиксируются в Сводке ситуаций и процедур верификации ПО, а также в Сводке результатов верификации ПО.
Этап верификации обеспечивает проверку соответствия реализации требованиям к ПО и верификацию этих требований следующими методами.
1. Соответствие между требованиями к ПО и тестовыми ситуациями выполняется путем анализа области покрытия требований.
2. Соответствие между структурой кода и тестовыми ситуациями выполняется путем анализа области покрытия структуры.
Основные методы этапа верификации ПО:
необходимо верифицировать требования высокого уровня и сводимость реализации к этим требованиям;
результаты анализа соответствия реализации, анализа области покрытия требований и анализа области покрытия структуры должны показывать, что каждое требование к ПО сводимо к области кода, реализующего это требование, а также к обзорам, анализам и тестовым ситуациям, проверяющим его;
если нет возможности верифицировать специфические требования к ПО путем эксплуатации ПО в реальных условиях, должны быть обеспечены иные средства, а в плане Верификации ПО или сводке результатов верификации ПО должно быть отмечено их использование в этапе верификации ПО.
К результатам этапов разработки и верификации ПО могут быть применены различные виды анализа и обзоров. Различия между обзором и анализом заключается в том, что анализ дает повторяемые доказательства корректности, а обзор обеспечивает количественную оценку корректности. Обзор может состоять из исследования выходных данных этапа, выполненного в виде диаграммы. Анализ может исследовать в деталях функционирование, производительность, трассируемость и вопросы безопасности компонента ПО.
Обзоры и анализ требований высокого (ВУ), низкого уровней (НУ), архитектуры, исходного кода показаны в таблице 2.7. Цель таких обзоров и анализов заключается в обнаружении ошибок в требованиях, которые могли быть внесены в ходе выполнения подэтапа разработки требований к ПО (подэтапов проектирования, разработки архитектуры, кодирования).
Цель обзоров и анализа результатов подэтапа интеграции - убедиться в том, что результаты данного этапа полны и корректны. Это может быть выполнено путем детального исследования компонуемых и загружаемых данных и карты памяти и рассмотрения следующих вопросов: некорректность аппаратных адресов, перекрытия областей памяти, отсутствия отдельных компонентов ПО.

Таблица 2.7.

	Требования ВУ	Требования НУ	Архитектура ПО	Исходный код
Подчинение системным требованиям /требованиям ВУ/ требованиям НУ/	Функции системы, выполняемые на базе ПО, определены; функциональные требования, требования к производительности и безопасности отражены в требованиях ВУ; производные требования корректны и необходимы.	Требования ВУ отражены в требованиях НУ; производные требования корректны и действительно необходимы.	Архитектура ПО не конфликтует с требованиями ВУ, особенно в функциях обеспечения целостности системы.	Исходный код корректен и полноценен по отношению к требованиям НУ; не реализуются недокументированные функции.
Точность и состоятельность	Каждое требование ВУ точно, корректно, непротиворечиво и не конфликтует с другими требованиями.	Каждое требование НУ точно, корректно, непротиворечиво и не конфликтует с другими требованиями.	Между компонентами архитектуры ПО существует корректные отношения. Отношения выражаются через потоки данных и управления.	Определить корректность и состоятельность исходного кода.
Совместимость с целевым компьютером (ЦК)	Нет конфликтов между требованиями ВУ и возможностями ЦК.	Нет конфликтов между требованиями к ПО и возможностями ЦК.	Нет конфликтов между архитектурой ПО и возможностями ЦК.
Проверяемость	Каждое требование ВУ может быть проверено.	каждое требование НУ может быть проверено.	Архитектура ПО может быть проверена.	Исходный код не содержит операторов и структур, которые не могут быть проверены.
Соответствие стандартам	На подэтапе разработки требований к ПО соблюдались стандарты на требования, а все отклонения от них исправлены.	На подэтапе проектирования соблюдались стандарты на разработку ПО, а все отклонения от них исправлены.	На подэтапе проектирования соблюдались стандарты на разработку ПО, а все отклонения от них исправлены.	На подэтапе кодирования соблюдались стандарты на кодирования ПО, а все отклонения от них исправлены.
Трассируемость	Системные функциональные требования, требования производительности и безопасности, реализуемые на базе ПО, были отражены в требованиях ВУ.	Требования ВУ и производные от них были отражены в требованиях НУ.		низкоуровневые требования были отражены в исходном коде.
Аспекты алгоритмов	Убедиться в точности и корректности поведения используемых алгоритмов, особенно в областях перехода от одного алгоритма к другому.	Убедиться в точности и корректности поведения используемых алгоритмов, особенно в областях перехода от одного алгоритма к другому.

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

Рис. 2.5 Диаграмма тестирования ПО.

анализ покрытия структуры должен определить, какие программные структуры не исследовались
Этап контроля конфигурацией, работает совместно с другими этапами жизненного цикла ПО и позволяет достичь следующих целей.
1. Обеспечение определенной управляемой конфигурации ПО в течение жизненного цикла ПО.
2. Обеспечение возможности размножить полноценный исполняемый объектный код для выпуска ПО или воспроизвести его в случае необходимости.
3. Обеспечение управления входными и выходными данными этапа в течении ЖЦ ПО, которое обеспечит состоятельность и воспроизводимость деятельности этапа.
4. Выработка исходных данных для обзоров и оценки статуса: изменение раз за разом параметров конфигурации до установления базового режима.
5. Обеспечение управления, которое даст возможность уделять внимание проблемам и записывать, оценивать и реализовывать изменения.
6. Обеспечение открытости информации о ПО путем управления выходными данными этапов ЖЦ ПО.
7. Помощь в оценке соответствия ПО требованиям на него.
8. Обязательное включение в параметры конфигурации поддержки безопасного физического архивирования, восстановления и управления.
Этап управления и контроля конфигурации включает в себя идентификацию конфигурации, управление изменениями, установление базовой конфигурации и архивацию ПО и данных ЖЦ ПО. Данный этап не останавливается после сертификации ПО, а продолжает функционировать в течение всего срока службы системы.
На этапе оценки качества ПО оцениваются выходные данные подэтапов жизненного цикла ПО для принятия решения об удовлетворении поставленных целей, обнаружении, оценке и устранении ошибок и согласования ПО и данных ЖЦ с требованиями сертификации. Этот этап применяется согласно этапу планирования разработки ПО и плана оценки качества ПО. Выходными данными этапа оценки качества формируются в Реестре оценки качества ПО или других данных жизненного цикла ПО.
Этап оценки качества должен определить, произошла ли в результате выполнения подэтапов ЖЦ ПО выработка такого ПО, который удовлетворял бы поставленным требованиям, допуская, что эти подэтапы выполнялись в соответствии с принятыми планами и стандартами разработки ПО.
Цель этапа оценки качества - убедиться в том, что:
этап разработки ПО удовлетворяет принятым планам и стандартам разработки ПО;
удовлетворен промежуточный критерий для подэтапов ЖЦ ПО;
проведена ревизия программного продукта.
Для достижения целей этапа оценки качества необходимо чтобы этап:
1. Играл активную роль в жизненном цикле ПО.
2. Обеспечивал создание и оценку корректности планов и стандартов разработки ПО.
3. Обеспечивал протекание этапов жизненного цикла ПО согласно указанным планам и стандартам.
4. Фиксировал события этапов разработки и интеграции в течение жизненного цикла ПО с целью определения того, что:
отклонения от планов и стандартов разработки обнаружены, записаны, оценены, проверены и исправлены (общепринято мнение о том, что, чем раньше обнаружены такие отклонения, тем более эффективно достигаются цели этапов ЖЦ ПО);
санкционированные отклонения зафиксированы особо;
среда разработки ПО используется согласно планам разработки ПО;
процесс оповещения о проблемах, их исправления и проверки проводиться согласно плану управления конфигурации ПО;
успешно получены результаты этапа оценки безопасности системы и внесены в жизненный цикл системы.
5. Этап управления и контроля конфигурации ПО должен контролировать удовлетворение промежуточных критериев ЖЦ ПО согласно принятого плану разработки ПО.
6. Этап управления и контроля конфигурации ПО должен проверить контролируемость данных ЖЦ ПО.
7. Прежде чем рассылать копии ПО для проведения его сертификации, необходимо выполнить его ревизию.
8. Этап управления и контроля конфигурации ПО должен фиксировать развитие событий и результаты ревизии ПО для каждого сертифицируемого программного продукта.
Основная цель ревизии заключается в том, чтобы убедиться, что для сертифицированного программного продукта этапы ЖЦ ПО завершены, их выходные данные сформированы, исполняемый объектный код контролируется и может быть воспроизведен.
Целью обеспечения сертификации является установление взаимопонимания между производителем ПО и службами, осуществляющими сертификацию, в течение всего ЖЦ ПО, что облегчит этап сертификации. Данный этап применяется согласно этапу планирования разработки ПО и плана программных аспектов сертификации.
Производитель ПО должен предоставить доказательства того, что жизненный цикл ПО протекает согласно плану разработки ПО. Служба сертификации может выдавать свои обзоры для производителя ПО или его поставщика с обсуждением тех или иных аспектов ЖЦ ПО. Производитель коррелирует замечания с методиками ЖЦ ПО и предоставляет требуемые данные. Производитель ПО обязан:
рассматривать обзоры служб сертификации;
передавать сводку работ, выполненных над ПО и реестр конфигурации ПО службам сертификации;
передавать или делать доступными другие данные о соответствии, требующие службам сертификации.
Кроме того, службам сертификации может быть передан план программных аспектов сертификации.
Обычно, если не возражают службы сертификации, меры по регулированию данных ЖЦ ПО, относящиеся к разработке типичного образца, применяются к данным о требованиях к ПО, описанию проектирования, исходному коду, исполняемому объектному коду, реестру конфигурации ПО, сводке работ, выполненных над ПО.
Необходимо заметить, что руководящие принципы документа DO - 178 В, в целом, удовлетворяют целям следующих международных стандартов: ИСО 9000-3-91 Стандарты в области административного управления качеством и обеспечения качества. Часть 3. Руководящие положения по применению ИСО 9001 при разработке, поставке и техническом обслуживании ПО, IEC 65A (Secretariat) 122 (ноябрь 1991) ПО для компьютеров, используемых в промышленных системах безопасности.