Верификация программного обеспечения (стр. 45 )

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

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

Версии (version) и Редакции (release): - эти термины иногда взаимозаменяемы. В данном документе термин "версия" используется прежде всего для ссылок на каждое новое проявление объекта конфигурационного управления, которому присвоен уникальный идентификационный номер, и подразумевает наличие цепочки ОКУ связанных отношением прослеживаемости. Другими словами одна версия ОКУ получается из другой через процедуру управления изменениями.

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

Вычисление статуса конфигурации

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

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

Время возникновения каждой БК и изменения (проблемы); Время определения каждого объекта конфигурации; Описательная информация о каждом объекте конфигурации; Статус запросов на изменения (принят, отклонен, ожидает выполнения, выполнен) Описание статусов Описательная информация о каждом запросе на изменение Статус изменения Описательная информация о каждом изменении

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

Архивирование, аудиты и обзоры конфигураций

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

Сохранность данных подразумевает не только возможность восстановления искомой версии ОКУ во все время действия процесса конфигурационного управления, но и защиту данных проекта от не санкционированного доступа. Иными словами изменения объекта могут производиться только тем лицом, которому это изменение доверено руководством проекта.

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

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

Аудитам конфигураций адресуются следующие вопросы, относящиеся к измененным объектам конфигурации:

Проведены ли изменения так, как они специфицированы и проведены ли соответствующие технические инспекции? Выдержано ли следование соответствующим стандартам? Выдержано ли следование установленным процедурам управления конфигурациями для записи и выдачи отчетов? Модифицированы ли все связанные с изменением объекты конфигурации?

Управление инструментальными средствами

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

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

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

Процедуры проекта должны точно идентифицировать конфигурацию используемых инструментальных средств. Модификация этой конфигурации допускается только через управление изменениями. Настройки СКУ должны предотвращать несанкционированное изменение инструментальных средств.

Уровни управления данными

Документ DO-178B в третьем разделе седьмой главы выделяет две категории управления данными жизненного цикла программного проекта. Они соответственно названы СС1 и СС2 категории управления данными. Выбор следования той или иной категории определяется приложением А. В упрощенном виде различие между категориями можно проследить по следующим соответствиям:

идентификация объектов                                                        (СС1,СС2)

Формирование базовых конфигураций                                         (СС1)

обеспечение трассируемости                                                 (СС1,СС2)

фиксация проблем                                                                (СС1)

управление изменениями (фиксация данных)                                (СС1,СС2)

анализ изменений                                                                (СС1)

вычисление статуса конфигурации                                        (СС1)

изменения                                                                        (СС1,СС2)

обеспечение ограничений доступа                                                (СС1,СС2)

контроль загрузочных модулей                                                (СС1)

хранение данных                                                                (СС1,СС2)

Управление качеством и конфигурационное управление при разработке сертифицируемого программного обеспечения.

Стандарт DO-178B обеспечивает авиационное сообщество руководящими указаниями, предназначенными для установления в конструктивной манере и с приемлемым уровнем достоверности факта того, что программное обеспечение бортовых авиационных систем и оборудование согласуются с требованиями летной годности. [7, раздел 1].

Процесс конфигурационного управления в данном стандарте рассмотрен в разделах 7 (Процесс конфигурационного управления при разработке программного обеспечения), 11.4 (План конфигурационного управления при разработке программного обеспечения) и 12.1.5 (Соображения о конфигурационном управлении при разработке программного обеспечения).

Основные цели процесса конфигурационного управления, согласно требованиям данного стандарта, включают в себя следующие положения [7, раздел 7.1]:

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

В целом процесс конфигурационного управления, охватываемый стандартом DO-178B, направлен на поддержание целостности данных, создаваемых в ходе всех стадий жизненного цикла продукции. Основная специфика процесса КУ, регламентируемого данным стандартом состоит в учете аспектов сертификации на летную годность, которую должно проходить все программное обеспечение, используемое в бортовых авиационных системах. Данные процесса КУ используются в качестве основных данных, предоставляемых сертифицирующему органу.