Поддержка процесса тестирования при промышленной разработке программного обеспечения

26.2.2.2. Базовые конфигурации и прослеживаемость

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

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

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

26.2.2.3. Управление изменениями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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