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

В стандарте DO-178B определяются шесть основных процессов программного проекта, из которых три можно отнести к производственным: планирование, разработка и верификация, а три к поддерживающим: обеспечение качества, взаимодействие с сертифицирующим органом  и конфигурационное управление. Производственным процессам посвящены соответственно главы 4, 5 и 6.

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

Задачи процесса конфигурационного управления

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

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

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

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

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

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

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

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

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

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

Процедуры процесса конфигурационного управления

Конфигурационное управление построено как композиция нескольких подпроцессов, функционирующих совместно:

Идентификация конфигураций; Управление изменениями; Формирование базовых конфигураций; Вычисление статусов конфигураций; Поддержка ограничений доступа; Архивирование, аудиты/обзоры конфигураций.

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

Идентификация конфигураций

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

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

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

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

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

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

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

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

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

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

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

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

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

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