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

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

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

В России разворачиваются крупные проекты разработки программных продуктов. Их успех напрямую зависит от совершенства процесса разработки, который, в свою очередь, напрямую зависит от качества процессов управления конфигурациями и управления изменениями в организации. Рассмотрим два подхода к организации процессов управления конфигурациями и изменениями — основанный на Information Technology Infrastructure Library (ITIL) и предлагаемый IBM Rational Unified Process (RUP).

Проблемы разработки

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

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

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

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

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

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

Рассмотрим оценку производительности проектов разработки программных продуктов для американских компаний за 1995 год, которые приводят аналитики Standish Group (можно считать, что это в достаточной мере соответствует текущему состоянию российских организаций). 53% от общего числа проектов характеризуются перерасходом средств более чем на 50%, а 68% проектов — перерасходом времени более чем на 50%. Свыше 31% проектов были прекращены до их завершения. Лишь 16% проектов были завершены в срок и в пределах запланированного бюджета, причем в крупных организациях доля таких проектов составляет только 9%. Не радует и качество программного обеспечения. Более чем в 54% проектов не были реализованы 25% заявленных требований, в 32% проектов — 50% требований и только в 7,3% проектов реализованы все требования. Суммарно все эти ошибки обошлись организациям в 1995 году примерно в 145 млн долл.

RUP и ITIL

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

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

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

Rational Unified Process — итерационный процесс. Создавать современные сложные программные средства последовательно (сначала определяя все проблемы, затем — проектные решения, потом кодируя и, наконец, тестируя результат) невозможно. Такой подход, называемый «каскадным» или «водопадом», в современной информационной индустрии себя не оправдывает, поскольку не позволяет отслеживать изменения требований к программным продуктам в ходе разработки.

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

Библиотека ITIL представляет собой набор книг по наиболее важным видам деятельности ИТ-подразделений, составленных на основании лучших примеров мирового опыта. Для наших целей важны три книги — «Управление конфигурацией» (Configuration Management), «Управление изменениями» (Change Management) и «Управление релизами» (Release Management). Основными чертами ITIL являются представление об ИТ-деятельности как о бизнесе и процессно-ориентированный подход к управлению ИТ. Все процессы рассматриваются во взаимосвязи, и большое значение придается правильному внедрению процессов. Безусловно, ITIL обеспечивает значительно более широкий «охват», чем RUP, поскольку ориентирована на управление ИТ в целом, тогда как методология RUP изначально ориентировалась на разработку программного обеспечения.

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

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

Динамическая структура RUP (рис. 1) состоит из четырех фаз: Inception, Elaboration, Construction и Transition. Фазы могут подразделяться на итерации. Переход с одной на другую фазу осуществляется только после выполнения задач предыдущей фазы и представляет собой контрольную точку (milestone) процесса. Статическая структура RUP состоит из процессов, в которые группируются работы, задачи, артефакты и роли. Они описывают, кто, что, как и когда выполняет. Интеграцию всех участников обеспечивает один из основных процессов — процесс управления конфигурациями и изменениями (Configuration and Change Management). Предполагается, что постановка лишь этого процесса позволит любой компании-разработчику существенно повысить качество создаваемого программного обеспечения и сделать сам процесс разработки не только творческим, но и технологическим. Становится возможным выполнение любых работ не в авральном, а плановом режиме.

С точки зрения ITIL существуют не два (как в RUP), а три взаимосвязанных процесса: к процессам управления конфигурациями и изменениями добавляется процесс управления релизами. В RUP управление релизами отдельно не выделяется (как и в ISO 12207), а его задачи входят в состав задач управления конфигурациями и изменениями. Управление конфигурациями по ITIL призвано обеспечить предоставление актуальной достоверной информации об ИТ-инфраструктуре — ее элементах и их взаимосвязях. Эта информация используется при анализе проблем и принятии решений по изменениям, а хранится она в конфигурационной базе данных (configuration management data base, CMDB).

Одним из ключевых моментов при внедрении процесса управления конфигурациями является определение состава конфигурационной базы данных — элементов конфигурации, которые будут находиться под контролем. Состав CMDB приходится ограничивать некоторыми пределами. Обычно в нее включаются документация, технические средства и программы, используемые в ИТ-инфраструктуре организации. Также в CMDB могут входить процедуры и ИТ-сервисы. Если еще больше расширить сферу применения процесса управления конфигурациями, в CMDB можно включить информацию о пользователях, персонале организации, ее организационной структуре и бизнес-процессах. При этом следует помнить, что изменение или замена любой конфигурационной единицы, зарегистрированной в CMDB, требует прохождения через процесс управления изменениями. А регистрация в CMDB каждой клавиатуры, мышки или сетевого фильтра (которые являются элементами ИТ-инфраструктуры) может привести к излишнему усложнению процесса и замедлить другие процессы.

С управлением конфигурациями тесно связан процесс управления изменениями, цель которого — контроль за изменениями и уменьшение связанных с этим негативных последствий. Область действия процесса управления изменениями соответствует области действия процесса управления конфигурациями; все изменения фиксируются в CMDB, и анализ предлагаемых изменений проводится на основании данных из CMDB. Два этих процесса тесно связаны с процессом управления релизами, который поддерживает контролируемое распространение версий программного и аппаратного обеспечения. Каждый релиз является следствием запроса на изменение и включает в себя определенный набор взаимосвязанных конфигурационных элементов.

Функциональность всех трех процессов в ITIL соответствует функциональности процессов управления конфигурациями и управления изменениями в RUP. Оба подхода оперируют схожими понятиями при определении процессов: роли, задачи и элементы конфигурации. Процессы также в основном совпадают по задачам. Например, RUP и ITIL указывают такие основные задачи управления конфигурациями, как планирование, учет и контроль над конфигурацией. ITIL содержит рекомендации по внедрению процессов, тогда как RUP вовсе не содержит рекомендаций по своему внедрению. Но этот недостаток компенсируется значительным числом публикаций, посвященных внедрению RUP (скажем, www-128.ibm.com/developerworks/rational/rationaledge).

Внедрение

Рассмотрим значимость каждого требования, необходимого для успешного внедрения процессов управления конфигурациями и изменениями. Лучше всего «вес» каждого из них представить в виде пирамиды (рис. 2).

Рис. 2. Значимость требований, необходимых для успешного внедрения процессов управления конфигурациями и изменениями

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

Фундамент. Требуется понимать основы управления конфигурациями и внедрять их в первую очередь. Частичная реализация процесса управления конфигурациями приведет, скорее всего, к краху системы.

Политика. Нужно определить результаты, ожидаемые от внедрения.

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

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

Средства реализации. Нет смысла использовать инструменты управления конфигурациями, если не завершены все предыдущие ступени пирамиды. Лучший способ загубить любое внедрение — идти от инструмента к процессу, а не наоборот.

Элементы конфигурации. Элементы конфигурации представляют собой внутренние и внешние сборочные узлы проекта. Они являются окончательным результатом всей работы, проделанной при реализации процесса управления конфигурациями в организации. Элементы конфигурации управляются средствами автоматизации управления конфигурациями (например, IBM Rational или CVS).

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

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

Эффект от внедрения

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

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

Прямые расходы включают в себя затраты на закупку средств автоматизации (IBM Rational ClearCase, PVCS VM, Perforce и т.п.), на обучение, техническую поддержку (на чем особенно любят экономить российские компании) и другие поддающиеся подсчету расходы, связанные с перестройкой процесса разработки и сопровождения программных средств. Косвенные расходы обусловлены тем, что реорганизация процесса разработки, отвлекая ресурсы, оказывает негативное воздействие на текущие проекты. Если на предприятии поставлен процесс управления ресурсами, такие расходы можно просчитать.

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

  • прирост производительности;
  • возможность для компании планомерно развивать продукт без авралов и срывов сроков проекта;
  • налаженное взаимодействие между тестировщиками, разработчиками и аналитиками, прозрачное управление проектом;
  • возможность постепенного внедрения остальных процессов (управление требованиями, тестирование) с использованием управления конфигурациями и изменениями как фундамента;
  • снижение рисков, связанных с невыполнением проекта в заданный срок с запланированными ресурсами;
  • возможность мониторинга текущей загрузки разработчиков и снижение зависимости от человеческого фактора;
  • накопление статистической информации по проектам;
  • соответствие стандартам качества процессов разработки и сопровождения.

Что выбрать

Однозначного ответа на этот вопрос нет. Проблему выбора приходится решать в каждом конкретном случае; многое зависит от стратегических планов внедрения.

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

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

Если задачи компании скромнее и его основной целью является не ИТ-инфраструктура в целом, а лишь разработка и сопровождение программных средств, тогда более удобной может оказаться RUP. Эта методология содержит детальные рекомендации по организации управления конфигурациями и изменениями именно в целях разработки, вплоть до пошаговых рекомендаций и шаблонов документов. Здесь преимущества дальнейшего развития за счет интеграции с другими процессами — на стороне RUP: помимо процессов управления конфигурациями и изменениями в ней подробно описывается организация других процессов разработки и сопровождения программных средств (управление требованиями, анализ и дизайн, тестирование и др.).

Что делать, если в организации уже применяются управления конфигурациями и изменениями на основе ITIL, а требуется взять под контроль различные элементы конфигурации в виде файлов, которые используются при разработке и сопровождении? Или, наоборот, после успешной автоматизации процессов управления конфигурациями и изменениями для разработки компания решила выйти на более высокий уровень и контролировать ИТ-инфраструктуру в целом?

Возможный вариант решения — использование имеющегося инструментария с небольшой модификацией процессов. Если идти «сверху вниз», от ИТ-инфраструктуры к задачам разработки, то напрашивается выделение дополнительного сегмента в CMDB для хранения элементов конфигурации процессов разработки и сопровождения. Такое решение может оказаться более успешным при реализации для сопровождения программных средств, являющихся частью инфраструктуры ИТ-сервисов. Если же речь идет о производстве программного обеспечения для внешнего заказчика, то этот подход не всегда оправдан. Данный процесс существенно отличается от процессов ITIL, и его интеграция возможна лишь с процессами управления конфигурацией, изменениями и релизами.

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

Альтернативный вариант — интеграция двух подходов. ITIL работает на уровне инфраструктуры, а RUP — на уровне артефактов разработчиков, которые слишком мелки для инфраструктуры, но необходимы для обеспечения нужного качества таких ее элементов, как программные средства. Интеграция привязана к программным средствам, которые являются элементами конфигурации и для ITIL (входят в состав инфраструктуры), и для RUP (готовый продукт состоит из множества артефактов, собранных в определенную конфигурацию).

Автоматизация

Еще один важный аспект — средства автоматизации процессов, от которых в значительной мере зависит успех внедрения. И для ITIL, и для RUP доступен широкий спектр инструментальных средств, решающих задачи автоматизации этих процессов как по отдельности, так и в интеграции. Известен признанный источник информации, определяющий уровень соответствия инструментов процессам ITIL (www.pinkelephant.com/consulting/PinkVerify); для процессов RUP такого единого источника нет.

Аналитики Ovum, Gartner, IDC и других компаний проводят сравнение средств автоматизации, но результаты таких исследований обычно не совпадают. Для ознакомления с различными инструментальными средствами можно порекомендовать портал сообщества CM Crossroads (www.cmcrossroads.com). Остановимся на основных категориях таких инструментов (детальное сравнение доступных систем можно найти на сайте www.cmcons.com/cc_func.htm). IBM Rational — не единственная компания на рынке средств управления конфигурациями, каждое из которых нацелено на свой сегмент рынка и имеет определенные плюсы и минусы. Все средства управления конфигурациями можно разделить на четыре категории.

Начальный уровень — Merant PVCS VM, Microsoft Visual SourceSafe. Поддерживается базовый версионный контроль: обеспечивается только управление версиями. Такие средства могут использоваться лишь в небольших проектах.

Продвинутый уровень — Merant PVCS Professional, Perforce, IBM Rational ClearCase LT. Интегрированное управление изменениями предусматривает более комплексный подход — не только управление версиями, но и управление изменениями, например документирование ошибок и отслеживание их исполнения.

Экстра 1, параллельные разработка и процесс управления конфигурациями — Borland StarTeam, MKS Source Integrity, IBM Rational ClearCase. Такие средства подходят для средних и крупных компаний, а также для фирм, вынужденных одновременно поддерживать множество релизов для множества заказчиков. Системы данного класса позволяют делать это наиболее эффективно. Средства управления конфигурациями на данном уровне — уже не просто инструменты, а системы формирования жесткого прозрачного процесса разработки и сопровождения.

Экстра 2, географически распределенная разработка — IBM Rational ClearCase MultiSite, Merant PVCS Dimensions, Telelogic Synergy. Средства для всех компаний, чьи центры разработки, тестирования и сопровождения находятся в разных городах или странах. Инструменты данной категории содержат механизмы автоматической синхронизации проектных команд независимо от расстояния и способа передачи данных.

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

Как показано на рис. 3, IBM Rational ClearCase находится на двух старших уровнях — наряду с PVCS и Telelogic Continuus. Довольно быстро прогрессирует Telelogic Synergy, который потеснил PVCS и по многим показателям вплотную приблизился к ClearCase. Но все же последний остается самым продвинутым и универсальным решением как для небольших компаний, так и для транснациональных корпораций.

К сожалению, заказчики редко просят сравнить эти средства. Большинство интересуется тем, что лучше — CVS или ClearCase, SourceSafe или ClearCase? Ответить несложно: CVS и SourceSafe — бесплатные программы, ориентированные на линейные проекты, где не требуется параллельная разработка и не создаются множественные прототипы. Да и попросту некорректно сравнивать бесплатные утилиты и мощные коммерческие системы.

IBM Rational ClearCase — широко известная и давно используемая система контроля над версиями. IBM Rational ClearCase используется известными организациями из разных отраслей, такими как HP, Boeing, Lockheed, Siemens, Ford Motor, ЦБ РФ, Сбербанк РФ, Челябинский тракторный завод.

Дмитрий Лапыгин (ldv_mail@operamail.com) — консультант, Александр Новичков (alex-golder@cmcons.com) — руководитель отдела внедрения компании «СМ-Консалт» (Москва).