Требования к процессу ук в смм

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

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

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

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

Ниже приведены требования CMM к процессу конфигурационного управления с вольными авторскими комментариями. Это требования 2 и 3 уровней. Хочется отметить, что внедрение УК в соответствии с RUP автоматически дает уровень 3 CMM

Цели процесса УК:

1. Управление конфигурацией происходит на плановой основе

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

2. Все изменения происходят управляемо

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

Обязательства по выполнению

1. Проект следует документированной организационной политике

1.1. Есть ответственные за выполнение проекта

Мало иметь ответственных. Они должны быть формально утверждены. Должен быть документ (например, приказ) в котором назначаются ответственные за реализацию.

1.2. УК реализуется на протяжении всего жизненного цикла разработки

Недостаточно использовать УК только на этапе разработки. УК реализуется на протяжении всего жизненного цикла: от бизнес-моделирования и постановки требований до ввода в эксплуатацию и сопровождения (если ведется поддержка разработанного программного обеспечения, то УК заканчивается только с окончанием поддержки).

1.3. УК реализуется для конечных продуктов, промежуточных, экспериментальных и перспективных

Очень часто бывает, что разработчикам разрешают промежуточные версии, перспективные макеты и т.д. разрабатывать локально. Логика руководства понятна – пусть он работает – придет время, все, что сделал, впишет в проект. Это неправильно. Нормально поставленный процесс подразумевает, что все изменения делаются в средстве автоматизации процесса УК, так как здесь хранится история изменений и комментарии к ним. Ведь если разработчик уйдет, то в случае такой организации проект пойдет дальше. А если разработка велась локально, то можно и потерять сегменты кода, а значит потерять массу времени на восстановление.

1.4. Все проекты имеют собственный репозиторий

*

(Примечание: здесь приводятся только основные требования к процессу. В стандарте СММ их существенно больше. Пропуски отмечены символами "*". Более подробную информацию о стандарте можно получить на сайте SEI-CMM)

4. Работы по УК должны быть обеспечены ресурсами

Очень часто внедрение процессов происходит по сценарию: «Витек или Васек все сделают». В итоге ничего не сделано. Процесс должен быть обеспечен ресурсами. Должны быть назначены ответственные, им должны быть вменены дополнительные обязанности. Если это не сделано, то проект рассыплется очень скоро.

4.1. Назначение менеджера УК

Ключевая роль. Этот человек знает процесс разработки. Понимает цели и задачи УК. Все свои знания он излагает в плане УК. Сам управляет процессом УК. Очень часто пытаются либо вообще обойтись без такой роли, либо «спихивают» ее на разработчиков. Естественно, это неправильно, так как разработчик не видит всей картины процесса разработки, может не понимать структурных взаимодействий между отделами… и т.д. Перечень непониманий можно продолжать далее. На первых порах, на порах становления роль менеджера берет на себя человек, который имеет представление о процессе разработки. Такой человек всегда есть в коллективе.

4.2. Назначение администратора УК

Для того, чтобы все работало и проверялось, необходим человек, занимающийся поддержкой процесса. Если менеджер процесса отвечает за его логическую стройность, непротиворечивость и необходимую детальность (все это отражено в плане), то администратор должен имплементировать эту концепцию в дело (превратить в скрипты, настройки). Ведь план – это верхний уровень, а его реализация – нижний. Так вот, администратор и отвечает за реализацию и поддержание процесса. Без него также не обойтись.

4.3. Работы обеспечены инструментальными средствами и оборудованием

5. Участники УК должны пройти обучение целям, процедурам и методам выполнения работ по УК

6. Члены группы разработки ПО должны пройти обучение по своим задачам

Проблема проблем – инструмент поставили, а что делать не сказали. Все участники должны пройти обучение, для понимания того, чего же от них требуется в плане знания инструмента и что же им нужно делать в проекте. Конечно, можно обойтись и без обучения, только риски запороть дело очень высоки, ведь никому в голову не придет сажать за руль автомобиля человека, который не умеет водить, а лишь слышал, как это делается. Кажется, что в деле разработки ПО все не так. Но законы природы одинаковы везде – сначала обучение – потом практика (это общий комментарий к пунктам 5 и 6).

Операции

1. Для каждого проекта готовится план УК

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

1.1. План разрабатывается на ранних стадиях общего планирования проекта

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

1.2. План рассматривается всеми участниками процесса и рецензируется ими

План – живой документ. План пишут живые люди, которые могут ошибиться. План – не секретный документ – он должен храниться на видном месте, его должны все читать, так как план описывает процесс разработки, то его ОСОБЕННО должны читать вновь пришедшие разработчики, тестировщики, менеджеры. Чтобы план был живым плодом любви, а не засохшим листком в гербарии – его необходимо читать и корректировать - избавлять от косноязычия и от неправильных формулировок. Такая ошибка, как неправильное понимание процесса, ведет к простоям и частым доработкам продукта.

1.3. План должен быть доступен и управляем в части его изменений

*

3. Устанавливается библиотечная система УК, служащая репозиторием проекта

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

3.1. Многоуровневая поддержка контроля УК

3.2. Хранение и извлечение элементов конфигурации

3.3. Совместное использование элементов группами разработчиков

3.4. Помощь в применении производственных стандартов УК

3.5. Хранение и извлечение архивных версий

3.6. Обеспечение корректного создания продуктов

3.7. Хранение и обновление записей по УК

3.8. Поддержка создания отчетов

3.9. Поддержка структуры и содержимого библиотеки

4. Идентификация промежуточных программных продуктов, находящихся в системе УК

4.1. Выбор элементов на основании документированных критериев

4.2. Элементам репозитория назначаются уникальные идентификаторы

4.3. Определяются характеристики каждого блока конфигурации

4.4. Определяются базовые линии

4.5. Для каждого блока определена стадия разработки, на которой он помещается в систему УК

4.6. Определен ответственный за каждый элемент

5. Запросы обслуживаются. Отчеты составляются

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

6. Изменение базовых версий ( baseline ) происходит подконтрольно, в соответствии с документированной процедурой

6.1. Выполнение проверок и регрессионных тестов

6.2. Внесение в библиотеку базовых версий лишь утвержденных блоков конфигурации

6.3. Внесение и извлечение блоков конфигурации не нарушает целостность проекта

7. Создание продуктов на основе библиотек базовых версий и контролирование их выпуска в соответствии с документированной процедурой

7.1. Комиссия контролирует создание продуктов на основе библиотеки базовых версий

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

8. Запись статуса элементов конфигурации в соответствии с документированной процедурой

8.1. Запись действий по УК производится с детальностью, достаточной для того, чтобы иметь в наличии статус всех элементов

8.2. Иметь возможность восстановить прежние версии файлов

8.3. Ведение истории изменений

Измерения и анализ

1. Выполнение измерений и использование их результатов для определения состояния работ по УК

Все, с чем мы сталкиваемся в жизни, можно измерить. Процесс УК не исключение – его тоже можно измерить. Мало того, ЕГО НУЖНО измерять. Ведь при активной работе в репозитории (хранилище) скапливается огромное число статистических сведений. Формирование отчетов и аналитических срезов – есть неотъемлемая часть как процесса разработки вообще, так и УК в частности. Ведь только на основе анализа собранной статистики можно принимать решения о дальнейших действиях. СММ оговаривает только самые важные срезы и отчеты.

1.1. Отчеты по количеству запросов за единицу времени

1.2.Отчеты по выполнению этапов работ по УК в сравнении с планом

1.3. Отчеты по объему выполненных работ по УК

1.4. Отчеты по ресурсам

18