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

1) что мотивирует приобретение инструмента с точки зрения организации?

2) использовать коммерческие средства или разработать их самостоятельно?

3) каковы ограничения, вводимые организацией, и их технический контекст?

4) как новые средства будут использованы (или не использованы) в проектах?

5) кто будет платить за приобретение инструментов, их настройку, техническое обслуживание и обучение специалистов?

6) как новые инструменты будут развернуты – например, во всей организации или в рамках отдельных проектов?

7) кто отвечает за внедрение новых инструментов?

8) как планируется использовать новые инструменты в будущем?

9) насколько новые инструменты поддаются адаптации?

10) объединять различные инструменты управления конфигурации между собой? С другими инструментами, используемыми в организации?

11) может ли репозиторий, поддерживаемый инструментом контроля версий быть перенесён в другой инструмент контроля версий при сохранении полной истории входящих в нее элементов конфигурации?

SCM как правило требует набора инструментов, организованных как единый инструмент. Такие наборы инструментов иногда называются рабочими местами (workbench). В таком контексте ещё одним важным фактором выбора инструментов является определение, будут ли рабочее место открытым (иными словами, инструменты от разных поставщиков будут использоваться в различных работах SCM-процессf) или интегрированным (где элементы рабочего места созданы для совместной работы).

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

Возможности инструментальных средств развиваются для обеспечения поддержки:

· SCM-библиотек (проектно-ориентированных баз знаний);

· запросов на изменения (software change request - SCR) и процедур утверждения (approval);

· управления кодом (и связанных рабочих продуктов) и изменениями;

· отчетности по статусу конфигураций и сбору соответствующих метрических показателей;

· Аудиту конфигураций;

· управлению и отслеживанию <состояния и полноты> программной документации;

· выполнению задач по сборке программных продуктов и их модулей;

· управлению, контролю и поставке выпусков (релизов) программных продуктов.

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

· работы и прогресс <по их выполнению> (Work and Progress);

· поток изменений (Change Traffic);

· стабильность конфигураций (Stability);

· раздробленность (Breakage);

· модульность (Modularity);

· переработка (Rework);

· адаптируемость (Adaptibility);

· среднее время между сбоями (MTBF – Mean Time Between Failures);

· полнота <информации> (Maturity).

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

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

Вопрос выбора SCM-системы должен решаться исходя из целей, сформулированных в отношении используемых процессов программной инженерии и уровня зрелости этих процессов. Кроме того, необходимо учитывать и вопросы унификации программных средств, используемых для поддержки инфраструктуры разработки и сопровождения всего портфеля программных проектов, выполняемых в организации. В силу фундаментальной значимости SCM-системы для обеспечения базовых процессов программной инженерии и управления всеми проектными активами, принимать решение об использовании той или иной SCM-системы для каждого отдельно взятого проекта выглядит необоснованным. SCM-система, система управления требованиями (более чем желательно, связанная с SCM), средства бизнес-моделирования и проектирования, среды разработки – все это должно быть стандартизировано в рамках организации, за исключением тех случаев, когда требования в отношении тех или иных инструментальных средств сформулированы со стороны заказчика и являются составной частью требований, предъявляемых к проекту. Возвращаясь к вопросу выбора SCM-системы, безусловно, необходимо учитывать мнение инженеров, однако, сложившиеся привычки не должны “перевешивать” функциональность предлагаемых к унификации SCM-средств, обеспечиваемую ими доступность и прозрачность информации о состоянии проекта в любой момент времени и, конечно, возможность эффективного администрирования активов проекта, в том числе, в контексте необходимых для этого трудозатрат (Орлик, 2004).

В процесс планирования (применения SCM-инструментов) рассматриваются аспекты, которые могут “всплыть” в процессе внедрения (и, даже, на этапе эксплуатации) выбираемой системы конфигурационного управления. В частности, обсуждаются и вопросы возможных изменений организационной культуры, если это необходимо (с точки зрения поставленных целей – проекта и/или совершенствования процессов).