- 21-03-2008
Субъективно о CMMI (часть 10)
Для начала давайте определимся с некоторыми понятиями. Что подразумевается под «конфигурацией» проекта? Это набор документов, исходных кодов, продуктов и подсистем получаемых на различных этапах разработки проекта. Все эти конфигурационные элементы в различные моменты времени находятся в различной степени готовности: одни завершены полностью и согласованы с заказчиком, другие готовы частично, третьи – еще даже не созданы. Конфигурационным срезом мы будем называть набор состояний всех конфигурационных элементов в определенный момент времени на проекте. Как правило, это какие-то значимые для проекта этапы: сдача очередной версии проекта (альфа, бета, релиз); демонстрационный показ заказчику; доставка и т.д. Целостностью конфигурационного среза мы будем называть выполнение набора требований к составу и содержанию конфигурационных элементов на определенном этапе проекта. Ну вот теперь кажется с ключевыми определениями покончено и мы можем поговорить более предметно. J
Давайте рассмотрим такой этап проекта, как «Согласование требований системы с заказчиком». Из каких элементов будет в этом случае состоять наша конфигурация? Например, это могут быть следующие конфигурационные элементы: план управления проектом, диаграмма Гантта с перчнем задач, документ требований, инспекции документа требований, прототип системы. В рамках конфигурационнного среза на данном этапе план управления проектом и диаграмма Гантта будут закончены ровно на столько, на сколько это нужно. Т.е. они не будут содержать информацию по дальнейшим этапам проекта. Что же касается документов требований и его инстпекций и прототипа, то это будут фактически завершенные артефакты, поскольку именно они будут составлять значимую часть доставки заказчику. А такие документы как архитектурный или функциональный дизайн системы вообще могут не существовать. Вот и получается, что целостность этого конфигурационного среза не будет нарушена, если на данном этапе будет окончательная версия прототипа, документа с требованиями, инспекции к нему и промежуточная версия плана управления проектом и диаграмм Гантта.
Назначение процессной области
Назначение данной процессной области состоит в том, чтобы определить и поддерживать в рабочем состоянии систему управления конфигурацией проекта (т.е. все необходимые конфигурационные элементы, такие как документы, код проекта, прочие результаты работ).
Перечень специальных целей
В рамках данной процессной области выделены три специальные цели:
SG 1: Определить конфигурационные срезы: Конфигурационные срезы по необходимым результатам работы на необходимых этапах проекта определены.
SG 2: Отслеживать и контролировать изменения: Изменения результатов работы,в рамках процесса управления конфигурацией, отслеживаются и контролируются .
SG3: Определить целостность: Целостность конфигурационных срезов определена и поддерживается.
Диаграмма выглядит следующим образом:
Идентификатор спец. практики | Пример реализации практик | Примеры прямых артефактов | Примеры косвенных артефактов |
SG 1: Определить конфигурационные срезы | |||
SP 1.1. Определить конфигурационные элементы | 1. Выбрать конфигурационные элементы; 2. Назначить уникальные идентификаторы для конфигурационных элементов; 3. Определить ключевые характеристики конфигурационных элементов; 4. Определить когда каждый из конфигурационных элементов попадет процесс управления конфигурацией; 5. Назначить ответственных за каждый конфигурационный элемент; | · Список конфигурационных элементов; | · План управления конфигурацией (как отдельный документ или как часть плана управления проектом); · Протоколы с обсуждением состава конфигурации на проекте; · Начальная версия конфигурационного среза (как специального документа); |
SP 1.2. Определить систему управления конфигурацией | 1. Обеспечить механизм для управления различными уровнями конфигурации; 2. Обеспечить механизм для сохранения и извлечения конфигурационных элементов из системы управления конфигурацией; 3. Совместно использовать и перемещать конфигурационные элементы на различных уровнях в рамках системы управления конфигурацией; 4. Хранить и восстанавливать архивные версии конфигурационных элементов; 5. Сохранять, изменять и извлекать конфигурационные записи; 6. Создавать отчеты, используя систему управления конфигурацией; 7. Обеспечивать сохранность содержимого системы управления конфигурацией; 8. Видоизменять структуру конфигурации при необходимости; | · Система контроля версий; · Хранилище документов; · Система отслеживания дефектов; | · План управления конфигурацией (как отдельный документ или как часть плана управления проектом); · Список конфигурационных элементов; · Инструкции по использованию корпоративных систем управления конфигурацией систем; · Тренинги для участников проекта по корпоративным системам управления конфигурацией; |
SP 1.3. Создать конфигурационные срезы | 1. Получить необходимые права перед созданием или доставкой среза конфигурационных элементов; 2. Создать или доставить конфигурационный срез только с использованием конфигурационных элементов из системы управления конфигурацией; 3. Задокументировать набор конфигурационных элементов, которые вошли в определенный конфигурационный срез; 4. Сделать существующий набор конфигурационных срезов легко доступным; | · Проектный документ «Конфигурационные срезы»; | · План управления конфигурацией (как отдельный документ или как часть плана управления проектом); · Список конфигурационных элементов; · Протоколы с обсуждением состава конфигурационных срезов на проекте; |
SG 2: Отслеживать и контролировать изменения | |||
SP 2.1. Отслеживать запросы на изменение | 1. Инициировать и записовать запросы на изменение в базе запросов на изменение; 2. Анализировать влияние запрашиваемых изменений; 3. Просмотреть те запросы на изменение, которые затрагивают ближайший конфигурационный срез с человеков, которого затронут эти изменения и заручиться его согласием; 4. Отслеживать статус запроса на изменение до закрытия; | · Запросы на изменение сохраненные в системе управления конфигурацией; | · Перечень задач по изменению существующих конфигурационных элементов, которые появляются по результатам запросов на изменение; · Обновленные версии конфигурационных элементов; |
SP 2.2. Контролировать конфигурационные элементы | 1. Контролировать изменения в конфигурационных элементах на всем протяжении проекта; 2. Получить соответствующее разрешение на добавление измененного конфигурационного элемента в систему управления конфигурацией; 3. Добавлять измененные конфигурационные элементы таким образом, чтобы это не повлияло на их целостность; 4. Проводить обзоры, чтобы убедиться, что изменения не оказывают непредусмотренный эффект на конфигурационный срез; 5. Записывать внесенные изменения и причину их добавления; | · Обновленные версии конфигурационных элементов (с историей обновлений); | · Запросы на изменение; · Конфигурационные срезы; · Обсуждение необходимых изменений с заинтересованными участниками проекта; |
SG 3: Определить целостность | |||
SP 3.1 Вести записи управления конфигурацией | 1. Описывать активности в рамках управления конфигурацией на таком уровне детализации, что содержимое и статус каждого конфигурационного элемента может быть восстановлено; 2. Убедиться, что необходимые участники имеют доступ и понимание того в каком статусе находится тот или иной конфигурационный элемент; 3. Точно определить финальную версию конфигурационного среза; 4. Определить версии конфигурационных элементов из которых состоит конфигурационный срез; 5. Описать различия между успешными конфигурационными срезами; 6. Проверять статус и историю изменений каждого конфигурационного элемента по необходимости; | · Проектный документ с набором конфигурационных срезов; | · Результаты аудитов конфигурации; · Протоколы обсуждений результатов аудитов; · Документ с описанием доставок заказчику, который содержит перечень необходимых конфигурационных элементов; |
SP 3.2 Осуществлять аудиты конфигурации | 1. Оценивать целостность конфигурационных срезов; 2. Подтвердить, что конфигурационные записи корректно описывают конфигурацию; 3. Пересмотреть структуру и целостность элементов, содержащихся в системе управления конфигурацией; 4. Подтвердить полноту и целостность элементов в системе управления конфигурацией; 5. Подтвердить соответствие необходимым процедурам и стандартам; 6. Отслеживать активности аудита до их завершения; | · Результаты аудитов конфигурации; | · Перечень обнаруженных замечаний; · Запланированные работы по устранению замечаний; |
Все в этом процессе, разумеется, построено вокруг системы управления конфигурацией. За таким громким и несколько непонятным названием стоит в первую очередь система контроля версий, система хранения документов или система, которая объединяет обе функции. Систему для хранения запросов на изменение можно и не выделять отдельно, поскольку чаще всего запросы на изменение являются обычными документами, написанными по определенному шаблону.
Появляется дополнительная проектная роль – конфигурационный менеджер. Опять же, роль по совместительству, как в случае с менеджером измерений. Чаще всего роль конфигурационного менеджера совмещает либо руководитель проекта, либо аналитик. Реже – ведущий тестировщик. Если всмотреться в обязанности этой роли пристальнее, то ничего нового мы не увидим: следить за актуальным состоянием всех проектных артефактов и обеспечивать готовность нужных артефактов в определенные моменты проекта. Все то же самое, что и без CMMI делалось на проектах. А с использованием CMMI все более формализованно, и тем самым помогает не успустить ничего важного.
By AAM
| Комментарии к статье "Субъективно о CMMI (часть 10)" (0) |