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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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