Организация качественного управления конфигурацией с использованием CMM и Rational ClearCase

Источник: КомпьютерПресс, №3/2002

А. Новичков, Interface Ltd.

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

Вполне вероятно, что даже в таком случае определенный контроль над проектом, с той или иной долей успеха, возможен. Правда, трудно определить качественный уровень выходного изделия, как это принятo в промышленном производстве.

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

На данный момент существуют два способа подтверждения качественности процессов сертификации: ISO и CMM. ISO - это стандарт качества любых процессов, будь то выпуск мороженого или разработка программного обеспечения, а CMM - модель качества, специально соотнесенная с процессом разработки ПО. В настоящей статье мы не будем рассматривать достоинства и недостатки каждого из стандартов, а также их соотношение друг с другом. Это тема отдельного подробнейшего разговора (подробности о стандартах качества ISO и CMM можно посмотреть на сайте Interface Ltd.)

CMM - большой, многоступенчатый стандарт качества, охватывающий весь цикл разработки программного обеспечения: от проектирования и до внедрения. Он годится для оптимизации и улучшения качества выпускаемого ПО. Но пути достижения качества могут быть различными, ведь в этом стандарте не сказано, КАК осуществить ту или иную процедуру, он описывает лишь, ЧТО должно получиться в результате.

Понятие "внедрить СММ" заключается не во внедрении стандарта как такового. Стандарту можно удовлетворять, а чтобы внедрить его, требуется некая технология, способная упорядочить процесс создания ПО в соответствии с требованиями СММ. Такой технологией может служить продукт фирмы Rational, носящий имя Rational Unified Process, где четко расписаны все этапы разработки, даны четкие инструкции, описаны все документы, все роли участников и все их действия. А в дополнение к подобной инструкции поставляется специальное программное обеспечение, с помощью которого эти процедуры можно осуществить. Дело остается только за внедрением RUP.

Естественно, хорошо было бы взять отдельную компанию, отдельный стандарт и внедрить все означенное в этом стандарте (будь то СММ или ISO - не важно). Но так не бывает! Как показывает практика, редкая компания внедряет ту или иную технологию полностью, сверху донизу. Чаше бывает наоборот - компания пытается внедрить ту часть технологии, которая наиболее насущна в данный момент. Внедрением всего и сразу занимаются обычно те, кто начинает новый проект. Для работающих фирм данный способ малопригоден.

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

Вполне очевиден выбор пути внедрения именно той части RUP и CMM, которая относится именно к конфигурационному и версионному управлению. И уже затем, подобно нанизыванию бусин на нить, можно по мере необходимости добавлять к проекту новые технологии. Тем самым можно со временем относительно безболезненно полностью внедрить RUP и далее получить определенный уровень качества по CMM (Rational гарантирует получение 2-го и 3-го уровня).

Статья, которую вы читаете, не претендует на полное описание продукта конфигурационного управления ClearCase, поскольку данный продукт уже не раз рассматривался в прессе (см. КомпьютерПресс № 5, 8'2001).

Настоящая статья посвящена описанию принципа приведения конфигурационного управления к качеству CMM, при этом основное внимание уделяется ролям участников проекта и действиям, которые необходимы для достижения качественного уровня управления. Логически статья поделена на несколько частей. Первая часть содержит общее введение в СММ. Вторая - оговаривает особенности конфигурационного управления согласно Rational Unified Process. И, наконец, третья часть содержит в табличном виде информацию о соответствии ключей-требований СММ технологии RUP.

Если статья вызовет у читателей интерес, мы планируем опубликовать ее продолжение, в котором будут даны практические примеры реализации ключей из таблицы с помощью Rational ClearCase. Автор ждет любые отзывы о данной статье, а также предложения по тематике следующей публикации по адресу http://www.interface.ru/iservices/mailfrompage.asp.

Что такое СММ

CMM (Capability Maturity Model) - модель зрелости процессов создания ПО, или эволюционная модель развития способности компании разрабатывать качественное программное обеспечение.

Изначально CMM разрабатывалась и развивалась как методика, позволяющая крупным правительственным организациям США выбирать наилучших поставщиков ПО. Для этого предполагалось создать исчерпывающее описание способов оценки процессов разработки ПО и методики их дальнейшего усовершенствования. В итоге авторам удалось достичь такой степени подробности и детализации, что стандарт оказался пригодным и для обычных компаний-разработчиков, стремящихся качественно улучшить существующие процессы разработки, привести их к определенным стандартам.

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

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

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

Начальный уровень (initial level) - это основной стандарт. К данному уровню, как правило, относится любая компания, которой удалось получить заказ, разработать и передать заказчику программный продукт. Предприятия первого уровня не отличаются стабильностью разработок. Как правило, успех одного проекта не гарантирует успешность следующего. Для компаний данного уровня свойственны неравномерность процесса разработки - наличие авралов в работе. К этой категории можно отнести любую компанию, которая хоть как-то исполняет взятые на себя обязательства.
Повторяемый уровень (repeatable level). Данному уровню соответствуют предприятия, обладающие определенными технологиями управления проектами. Планирование и управление в большинстве случаев основывается на имеющемся опыте. Как правило, в компании данного уровня уже выработаны внутренние стандарты и организованы специальные группы проверки качества.
Определенный уровень (defined level). Уровень характеризуется наличием формального подхода к управлению (то есть описаны все типичные действия, необходимые для многократного повторения: роли участников, форматы документов, производимые действия и пр.). Для создания и поддержания подобного стандарта в актуальном состоянии в организации уже подготовлена специальная группа. Компания постоянно проводит специальные тренинги для повышения профессионального уровня своих сотрудников. Начиная с этого уровня организация перестает зависеть от личностных качеств конкретных разработчиков и не имеет тенденции скатываться на нижестоящие уровни. Абстрагирование от разработчиков обусловлено продуманным механизмом постановки задач и контроля исполнения.
Управляемый уровень (managed level). Уровень, при котором устанавливаются количественные показатели качества.
Оптимизирующий уровень (optimizing level) характеризуется тем, что мероприятия по совершенствованию рассчитаны не только на существующие процессы, но и на оценку эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное совершенствование существующих процессов, которое в идеале призвано способствовать предупреждению возможных ошибок или дефектов. Применяется механизм повторного использования компонентов от проекта к проекту, например шаблоны отчетов, форматы требований.

Из градации уровней видно, что технологические требования сохраняются только до 3-го уровня, далее же в основном следуют требования к административному управлению. То есть уровни 4 и 5 по большей части управленческие и для их достижения важно не только выпустить программный продукт, но и проанализировать ход проекта, а также построить планы на будущий проект, основываясь на текущих шаблонах. Применение данных подходов должно обеспечить планомерно-плавное улучшение используемых процессов.

Пока в России знают только аббревиатуру СММ, но не представляют себе, каким образом можно добиться качественного скачка. И дело не только в том, что неизвестно направление этого скачка, а в том, что каждой отдельно взятой компании довольно трудно выстроить свои процессы под требования CMM самостоятельно, без внешнего вмешательства. А зачем изобретать велосипед? Не проще ли взять готовый набор решений оптимизации (например, Rational Unified Process), внедрить его (здесь уже можно и своими силами обойтись), получив готовый набор решений для качественного построения ПО, а уж затем приглашать специалистов и аттестоваться на определенный уровень? Как мы уже не раз упоминали в данной статье, Rational гарантирует получение 3-го уровня СММ.

На Западе сегодня уже широко используют для оптимизации процесса выпуска ПО технологии компании Rational Software. Причин тому несколько: во-первых, Rational Software - практически единственная компания, которая четко описала весь производственный цикл по выпуску программного обеспечения (Rational Unified Process), определила все возможные виды документов, сопровождающие проект, строго расписала роли (входные/выходные документы, шаблоны документов и пр.) каждого участника проекта. Во-вторых, компания создала специальное программное обеспечение для качественного исполнения как каждого этапа в отдельности, так и всего проекта в целом. Важно и то, что Rational посредством RUP предлагает перейти от программирования как искусства к программированию как к науке, где все понятно и прозрачно благодаря научному подходу к разработке. По некоторым оценкам западных аналитиков, соотношение возврата капитала до и после внедрения качественных процессов варьируется от 5:1 до 8:1.

Configuration and Change Management с точки зрения CMM и RUP

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

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

Конфигурационное управление участвует в идентификации конфигурации выпускаемого ПО (то есть в выборе программного продукта и в его описании) в срок. SCM (Source Configuration Management) обеспечивает систематизированное управление изменениями конфигурации, поддержание их целостности и актуальности на протяжении всего жизненного цикла проекта. Результаты разработки, которые поставляются клиенту, находятся под управлением конфигурационной системы. Также под ее управлением находятся все документы и результаты компиляции (документы требований, отчеты, исходные данные на любом языке программирования).

Библиотеки базовых линий должны быть установлены и содержать работающие версии релизов. Под базовыми линиями здесь и далее понимается набор версий исходных файлов, составляющих конкретную версию откомпилированного релиза. Изменения базовых линий программного продукта, построенных на основе библиотеки базовых линий, должны быть управляемыми посредством контроля изменений и конфигурационного аудита функций в SCM, что полностью обеспечивается продуктом Rational ClearCase (версионное управление).

Все данные из ключевых областей процесса (Key Process Area) охватывают возможные методы исполнения функции конфигурационного управления. В СММ все качественные требования представляются именно как KPA. Каждый из этих методов четко описывает определенный участок с формализованными требованиями, а RUP способен привести этот участок в соответствие означенному требованию.

Механизмы, идентифицирующие определенные единицы конфигурации, содержатся в KPA и описывают развитие и сопровождение каждой единицы конфигурации (исходные тексты, картинки, документация и пр.).

Ниже приведены основные постулаты конфигурационного управления по CMM (дословный перевод требований):

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

Для реализации тех или иных действий, связанных с конфигурационным управлением, в RUP имеются несколько взаимосвязанных программных продуктов: Rational ClearCase (средство версионного управления), Rational ClearQuest (средство организации конфигурационного управления и управления изменениями). Также на некоторых этапах удобно использовать систему генерации проектной документации Rational SoDA для получения отчетов установленного образца. Для объединения регионально удаленных команд применяется приложение Rational ClearCase MultiSite.

Rational Unified Process описывает все этапы разработки программного обеспечения, включая конфигурационое управление. Содержит описание ролей участников проекта, шаблоны входных/выходных документов, набор рекомендаций для каждой проектной стадии. На рис. 1 изображены потоки работ и фазы по RUP. Обратите внимание на конфигурационное управление. Из диаграммы видно, что конфигурационное управление сопровождает все этапы и фазы проекта и вступает в действие с момента создания аналитиком бизнес-модели и до передачи готового программного продукта заказчику.

Рис. 1

Как говорилось выше, RUP описывает, каким образом следует построить конфигурационное управление. Если посмотреть на топик конфигурационного управления из RUP, то нашему взору предстанет диаграмма разработки проекта с точки зрения RUP (рис. 2).

Рис. 2

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

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

Рис. 3

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

Установка плана управления конфигурацией

Участники и роли:

Менеджер конфигурации
- установление конфигурационной политики
- создание конфигурационного плана
Менеджер контроля изменений
- установление процесса контроля над версиями

Артефакты: конфигурационный план

Создание проекта и среды

Участники и роли:

Менеджер конфигурации
- установление среды конфигурации
Интегратор
- создание интегрирующего пространства

Артефакты: конфигурационный план (дополнения), модель внедрения, настройка проектного репозитария, разработка рабочего пространства

Изменение и представления конфигурационных элементов

Участники и роли:

Интегратор
- создание базовых линий
Остальные
- создание рабочего пространства
- создание изменений

Обновление рабочего пространства

Артефакты: наряд на работу, модификация пространства

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

Участники и роли:

Интегратор
- Создание базовых линий
- Выделение базовых линий
Менеджер конфигурации
- Создание единицы развертывания

Артефакты: спецификации материалов, репозитарий, единицы развертывания

Составление отчетов по конфигурационному пространству

Участники и роли:

Менеджер конфигурации
- генерирование отчета по состоянию
- подготовка конфигурационного аудита

Артефакты: проектные единицы измерения, аудит репозитария (отчет)

Управление запросами на изменение

Участники и роли:

Менеджер контроля изменений
- просмотр запросов на изменение
- поиск дублей в запросах
Интегратор
- проверка изменения в билде
Остальные
- представление запросов на изменение
- обновление запросов на изменение

Артефакты: запросы на изменения

Под термином "артефакт" здесь подразумевается получение выходного документа.

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

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

Конфигурационный план:

Введение
Цели
Область охвата
Определения и сокращения
Ссылки
Краткий обзор

SCM (Software Configuration Management)

Организация, ответственность и интерфейс
Инструментальные средства, среда и инфраструктура

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

Идентификация методов
Проектные базовые линии
Контроль изменений и конфигураций
- Процесс запроса изменений
- Группа управления изменениями
Учет конфигурационного состояния
- Способы проектного хранения и процесс выпуска релизов
- Отчеты и аудит

Oсновные производственные задания

Oбучение и ресурсы

Подрядчик и услуги продавца

Естественно, это шаблон, который предстоит заполнять данными в соответствии с рекомендациями RUP (каждый пункт шаблона в RUP можно посмотреть в развернутом виде).

В заключение следует обратить внимание на соответствие ключей CMM их привязке к Rational Unified Process:

Ключи CMM и их реализация в RUP

Наименование ключа СММ	Описание ключа	Роль в RUP	Процессы в RUP	Процедуры в RUP	Примечания
Сo1	Проект выполняется в соответствии с установленной организационной политикой (Software Configuration Management)	Инициативная группа			Под политикой можно определять ключевые роли и должностные обязанности сотрудников, вовлеченных в КУ.
Ab1	Руководство обладает полномочиями для управления существующими или устанавливаемыми проектными базовыми линиями	Менеджер проекта, руководитель	Конфигурационное управление и управление версиями, план проекта конфигурационного и версионного контроля	Действия: установление процесса контроля изменений	Данный шаг подразумевает определение конкретной политики версионного управления.
Ab2	Организуется работа группы, ответственной за внедрение SCM для существующего проекта	Любой работник	Управление проектами. Разработка SDP (Software Development Plan)	Действия: определение проектной организации	Данный шаг подразумевает определение проектной организации. Входящими данными для этого ключа могут служить: модель системы в Rational Rose, и сгенерированный на ее основе отчет в SoDA, по SDP.
Ab3	Выделяются ресурсы и финансирование для выполнения SCM-действий	Менеджер проекта	Управление проектами. Разработка SDP	Действия: определение проектной организации	Частичное повторение предыдущего этапа. В силу особой важности правильного выбора проектной организации полагается уделить большое количество времени на ее правильную организацию.
Ab4	Все члены SCM-групп обучены процедурам и методам для исполнения SCM-действий	Менеджер проекта	Управление проектами. Управление итерациями	Действия: изучение/обучение	Данный шаг подразумевает обучение сотрудников заказчика либо собственными силами (если есть соответствующие специалисты, проводившие пилотный проект), либо с привлечением сторонних консультантов.
Ab5	Члены группы разработки программного обеспечения связываются с обученными группами, чтобы дополнять их SCM-действия	Менеджер проекта	Управление проектами. Управление итерациями	Действия: изучение/обучение	То же, что и предыдущий шаг.
Ac1	План SCM готовится к каждому проекту согласно установленной процедуре	Менеджер конфигураций	Конфигурационное управление и управление версиями. План проекта конфигурационного и версионного контроля	Действие: создание CM-плана. Шаблон: SCMP
Ac2	Зарегистрированный и утвержденный SCM-план используется в качестве основы для выполнения дальнейших SCM-действий	Менеджер конфигураций	Конфигурационное управление и управление версиями. План проекта конфигурационного и версионного контроля	Действия: создание CM-плана. Шаблон: SCMP	Подразумевается написание конфигурационного плана - политики изменений версий файлов в составе проекта. План является обязательным для всех участников проекта.
Ac3	Система библиотек управления конфигурациями установлена как основа (репозитарий) для программных базовых линий	Менеджер конфигураций	Конфигурационное управление и управление версиями. Создается конфигурационная среда	Действия: настройка среды CM. Инструмент: ClearCase ClearQuest	Практический шаг. Администратор ClearCase и ClearQuest реализует физическое воплощение запланированной конфигурационной политики. Создается репозитарий, который насыщается начальными правами.
Ac4	Разрабатываемые данные кладутся под управление и идентифицируются	Менеджер конфигураций	Конфигурационное управление и управление версиями. План проекта конфигурационного и версионного контроля	Действия: Создание CM-плана. Шаблон: SCMP	Физическая постановка проектных данных под управление ClearCase.
Ac5	Запросы на изменение и отчеты по всем элементам конфигурации должны быть введены, зарегистрированы, рассмотрены и одобрены согласно установленной процедуре	Менеджер проекта, руководитель	Конфигурационное управление и управление версиями. План проекта конфигурационного и версионного контроля	Действия: установление процесса контроля изменений. Шаблон: SCMP	Данная функциональность может быть обеспечена при совместном использовании ClearCase и ClearQuest. При настройке выбирается тип возможной совместной работы продуктов: UCM или BASE. От выбранного типа существенно зависит политика дальнейшей работы.
Ac6	Изменения базовых линий управляются согласно установленной процедуре	Интегратор	Конфигурационное управление и управление версиями. Управление релизами и базовыми версиями	Действия: создание базовых линий. Шаблон: SCMP	В зависимости от выбранной политики использования ClearCase (UCM или BASE) выбирается политика нумерации релизов (базовых, отладочных).
Ac7	Базовые линии компилируются и управляются согласно установленной процедуре	Интегратор	Конфигурационное управление и управление версиями. Управление релизами и базовыми версиями.	Действия: продвижение базовых линий. Шаблон: SCMP	Данная процедура должна быть зарегистрирована в SCMP и иметь соответственное сопровождение. В отличие от предыдущего данный этап подразумевает практическое использование уже установленной политики.
Ac8	Состояния элементов конфигурации и модулей зарегистрированы согласно установленной процедуре	Любой работник	Конфигурационное управление и управление изменениями. Изменение и производство базовых линий	Действия: создание изменений. Шаблон: SCMP	Собственно процесс обеспечения доступа к подконтрольным данным любого участника.
Ac9	Стандартные отчеты, документирующие SCM-действия и содержания базовых линий, разработаны и сделаны доступными как заинтересованным группам, так и отдельным участникам	Менеджер конфигураций	Конфигурационное управление и управление изменениями. Мониторинг состояния и создания отчетов статуса конфигурации	Действия: создание отчетов по конфигурационным статусам. Шаблон: SCMP	Генерация отчетов возможна как через сам ClearCase, так и через специальные средства отчетности, такие как Rational SoDA. Если используются возможности ClearCase, то допускается автоматизированная генерация произвольных отчетов по заранее установленному расписанию.
Ac10	Аудит базовых линий проводится согласно установленной процедуре	Менеджер конфигураций	Конфигурационное управление и управление изменениями. Мониторинг состояния и создания отчетов статуса конфигурации	Действия: исполнение конфигурационного аудита. Шаблон: SCMP	ClearCase имеет встроенные средства по аудиту, а также позволяет при помощи набора мастеров устанавливать способы, отличающиеся от стандартных.
Me1	Единицы измерения созданы и используются для определения состояний SCM-действий	Менеджер проектов	Управление проектом. Отслеживание и контроль проекта	Действия: отслеживание проектного статуса. Шаблон: план единиц измерений.	Заканчивая план измерений, проект определит, что измерения будут приняты. В этом случае они должны быть проанализированы и использованы для улучшения процессов.
Ve1	SCM-действия периодически просматриваются старшими менеджерами или руководителями	Рецензент проекта	Управление проектом. Отслеживание и контроль проекта	Действия: рецензирование проекта	Все отчеты читаются и рецензируются.
Ve2	SCM-действия просматриваются в двух случаях: периодически и по событиям (действий)	Менеджер проектов	Управление проектом. Отслеживание и контроль проекта	Действия: отслеживание проектного статуса	Руководство должно иметь представление о состоянии проекта. Соответственно отчетные представления позволяют легко это обеспечить. Периодичность и форма проверки определяется на более ранних этапах. Формат просмотра может быть линейным, в соответствии с расписанием, например, еженедельно, а может быть интерактивным, когда вышестоящее руководство немедленно информируется об определенных действиях сотрудников.
Ve3	SCM-группа периодически проводит аудит базовых линий на предмет соответствия начальным установкам	Менеджер конфигураций	Управление конфигурациями и изменениями. Отслеживание состояния и вывод отчетов по конфигурационному статусу	Действие: подготовка конфигурационного аудита. Шаблон: SCMP	Периодически проводится аудит состояние проектных линий. Отчеты по базовым линиям представляются ClearCase. Группа ответственных лиц периодически просматривает, не противоречат ли они установленным ранее политикам.
Ve4	Группа гарантии качества ПО просматривает и/или проводит ревизию действий и генерирует соответствующие отчеты	Рецензент проекта	Управление проектом. Отслеживание и контроль проекта	Действия: отслеживание проектного состояния

Термины, используемые в таблице:

SCM - Software Configuration Management
SDP - Software Development Plan
SCMP - Software Configuration Management Plan
UCM - Unified Change Management
CM - Configuration Management

Заключение

Автор не претендует на полноту изложения материала по проблеме конфигурационного управления. Данная статья - попытка показать, продемонстрировать мощные возможности как CMM, так и Rational Unified Process в их совместном использовании для улучшения качества выпускаемого ПО.

В следующей части статьи будет более подробно рассказано о настройке и конфигурации программных продуктов Rational ClearCase, Rational ClearQuest и SoDA в соответствии с Key Process Area. Также планируется осветить вопросы, присланные автору на http://www.interface.ru/iservices/mailfrompage.asp

Ссылки по теме

Организация качественного управления конфигурацией с использованием CMM и Rational ClearCase

Оглавление