2.3. Применяемые политики, директивы и процедуры

1. Управление конфигурациями для данного проекта должно осуществлять­ся в соответствии с указаниями по управлению конфигурациями, изложен­ными в корпоративном документе 7890 версии 6 от 15.08.98.

2. В соответствии с политикой улучшения процесса разработки требуется проводить обзорные совещания по ходу и в конце проекта, и все предло­жения по улучшению должны фиксироваться с целью использования их в организации. Данные совещания требуются для подготовки подразделения разработки к сертификации по СММ уровня 5. Результаты самооценки должны быть отправлены управляющему, ответственному за улучшение процесса, не позднее трех недель после того, как состоялось совещание. Все разделы, в которых указаны возможные улучшения, должны содержать соответствующий материал и конкретные примеры.

3. Все текущие и предшествующие версии CI должны сохраняться.

4. К главному файлу (определен в разделе 3.1.2) имеет доступ только веду­щий конфигурацию, а в его отсутствие — начальник отдела.

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

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

3. Виды деятельности

3.1. Определение конфигурации

3.1.1. Определение элементов конфигурации

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

3.1.2. Именование элементов конфигурации

Ведущий конфигурацию несет ответственность за маркировку всех CI. Соглаше­ние об именах следующее.

Корневой каталог: TestSystemProject.

Вложенные каталоги: SRS или SDD

Файл с именем N_N_N.xxx соответствует версии N.N.N документа.

Например, версия SRS 2.4.8 имеет имя TestSystemProject /SRS/2_4_8.txt.

Главный файл с именем TestSystemProject _Main находится в корневом каталоге и содержит ин­формацию о текущем состоянии и предыдущих состояниях проекта.

3.1 Получение элементов конфигурации

Для модификации CI разработчик должен взять CI с помощью процедуры checkout инструмента SuperCMTool. Отметим, что SuperCMTool предлагает поль­зователю заполнить специальную форму и указать, на какой срок берется CI. Эта информация запоминается и предоставляется другим пользователям, желаю­щим взять данный CI на модификацию. Любой желающий взять данный CI дол­жен договориться с текущим владельцем CI о передаче средствами SuperCMTool. Ни при каких обстоятельствах разработчики не должны передавать друг другу CI прямо, в обход SuperCMTool. Для любого разработчика любой CI должен быть доступен на чтение в любое время.

3.2. Контроль конфигурации

3.2.1. Запрос на изменения

Как определено в SPMP (глава 2), команда назначает инспектора для каждого участника команды. Прежде чем сделать запрос на изменение, разработчик обязан получить одобрение данного предложения по изменению от инспектирующей команды или, если последнее невозможно, от своего инспектора.

3.2.2. Оценка изменений

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

3.2.3 Одобрение или неодобрение изменений

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

3.2.4. Реализация изменений

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

Выпуск версий должен утверждаться лидером проекта или руководителем проекта, если лидер отсутствует.