CMC
Software development with IBM Rational
IBM
 
 
 
 

Print

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

Александр Новичков, Дмитрий Лапыгин

Опубликовано в жунале КомпьютерПресс, Ноябрь 2005

Введение

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

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

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

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

Подробное описание УК и УИ представлено в документах, описывающих методологию IBM Rational Unified Process (RUP), которая в настоящий момент является наиболее известной методологией коллективной разработки, имеющей полноценную инструментальную поддержку. Ниже кратко изложены основные характеристики этих процессов.

Цели:

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

Важные составляющие процессов:

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

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

Рассмотрим основные преимущества внедрения этих дисциплин с точки зрения руководства:

  1. Прозрачное управление проектом (за счет строгой формализации процессов). Процесс выстраивается таким образом, что все случаи, требующие принятия решений, контролируются на должном уровне.
  2. Четкое представление о том, кто и чем занимается в проекте, сколько ошибок исправлено, сколько ошибок найдено и т.д.
  3. Полное документирование всех ключевых изменений.
  4. Планирование деятельности каждого разработчика, который точно знает, что ему нужно сделать сегодня, завтра и послезавтра.
  5. Графическое представление метрик проекта, формируемых при определении процесса (типы, количество и т.д.).
  6. Формирование статистических отчетов по проекту (часто называемых срезами). Сформированные метрики проекта ранжируются в зависимости от уровня руководства: руководитель департамента, начальник отдела, менеджер проекта и т.д.

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

Примеры срезов

Примеры срезов

Рис. Примеры срезов

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

Экономический эффект от внедрения

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

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

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

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

Давайте посчитаем

Рассмотрим типовой сценарий оценки сроков возврата инвестиций для проекта разработки ПО. Для реализации этого сценария не обходимы следующие данные:

  • Количественное распределение участников проекта разработки ПО по их функциям. Например, разработчиков новой версии — 50, сопровожденцев — 50, технических писателей — 10, тестировщиков — 20, менеджеров — 12, системных администраторов — 2, инженеров технической поддержки — 10.
  • Перечень операций для каждого специалиста, время выполнения которых может быть сокращено с помощью управления конфигурацией.
  • Количественное распределение специалистов, участвующих во внедрении процесса управления конфигурацией. Напри мер, разработчиков — 5, технических писателей — 2, тестировщиков — 2, менеджеров — 1, системных администраторов — 1, инженеров технической поддержки — 1.
  • Стоимость часа рабочего времени каждого специалиста.
  • Рабочее время каждого специалиста, занятого в проекте внедрения (на основе плана проекта).
  • Оценка сэкономленного времени для каждой операции из п. 2 за неделю. Такие данные могут быть определены во время пилотного проекта или взяты из других аналогичных проектов.
  • Стоимость обучения специалистов, участвующих в проекте разработки ПО.
  • Стоимость внешних консультантов, участвующих в проекте внедрения процесса УК.
  • Стоимость лицензий средств автоматизации процесса УК.
  • Стоимость годовой технической поддержки средств автоматизации процесса УК.

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

За первый год подсчитываются:

  1. Доходы — стоимость сэкономленного в неделю на каждой операции времени, умноженная на стоимость рабочего времени специалиста, выполняющего эту операцию.
  2. Издержки:
    • стоимость рабочего времени специалистов, участвующих в проекте внедрения. Здесь также можно учесть упущенную выгоду от их использования в других проектах;
    • стоимость обучения специалистов;
    • стоимость внешних консультантов;
    • стоимость лицензий;
    • стоимость годовой технической поддержки.

За второй и последующие годы подсчитываются:

  1. Доходы — стоимость сэкономленного в неделю на каждой операции времени, умноженная на стоимость рабочего времени специалиста, выполняющего эту операцию.
  2. Издержки:
    • стоимость обучения новых специалистов проекта разработки ПО (обычно не более 10% от общего числа специалистов);
    • стоимость лицензий (при расширении числа участников проекта, обычно до 10% от первоначального количества лицензий);
    • стоимость годовой технической поддержки.

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

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

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

Как видно из представленной схемы расчета окупаемости, внедрение процесса УК в от дельно взятом краткосрочном проекте, срок реализации которого не превышает года, обычно нерентабельно. Но стоит ли отказываться от использования управления конфигурацией в краткосрочных проектах? Не обязательно. Есть два пути исправления этой ситуации. Первый, по которому идут сейчас многие отечественные компании-разработчики, — как можно больше сократить издержки первого года. При этом обычно:

  • полностью прекращаются расходы на внешних консультантов;
  • количество обучаемых специалистов урезается до 12 человек, которые затем в роли «гуру» должны будут распространять приобретенные знания среди других участников проекта;
  • используются наиболее дешевые средства автоматизации процесса УК, или, мягко говоря, «условно-бесплатные» версии;
  • услуги, связанные с технической поддержкой, не приобретаются. Такой вариант решения проблемы может

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

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

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

Долгосрочность означает, что оптимизацию инвестиций следует осуществлять в первую очередь на основе постоянно действующих факторов. К ним относятся:

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

Наличие большого числа участников оказывает влияние в основном на следующие вели чины:

  • сокращение затрат на типовые операции, постоянно выполняемые участниками проекта;
  • расходы на обучение;
  • расходы на лицензии.

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

  • расходы на обучение — наличие постоянно действующей группы совершенствования процесса (ГСП) позволит использовать ее специалистов в качестве тренеров для обучения новых участников проекта, что позволит снизить затраты на обучение начиная со второго года. Первоначальное обучение все же следует проводить силами внешних специалистов;
  • расходы на лицензии — одной из задач совершенствования процесса УК является оптимизация использования лицензий, которая может осуществляться ГСП на основе постоянного мониторинга применения лицензий в проекте. Обычно первоначальное количество закупаемых лицензий приблизительно рассчитывается исходя из общих данных. Реальная потребность в лицензиях может отличаться от первоначальной оценки на 15-20% в ту или иную сторону;
  • расходы на техническую поддержку — обычно производители программного обеспечения применяют политику обеспечения не скольких уровней технической поддержки разной стоимости, зависящей от набора ус луг. Наличие ГСП в организации позволит снизить уровень технической поддержки за счет использования опыта специалистов ГСП для решения части технических проблем.

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

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

  1. Сокращаем стоимость обучения специалистов проекта разработки ПС, обучив не всех, а лишь одного-двух сотрудников. Затем используем их для обучения других специалистов. С одной стороны — снижение расходов в несколько раз, хотя и не очень значительное по абсолютной величине, поскольку в малых проектах число участников не велико. С другой стороны — опасность того, что обученные специалисты уйдут, окажутся неспособными (или не желающими — для сохранения своей уникальности) передать полученные знания другим. Это может при вести к тому, что такому специалисту придется повысить зарплату, чтобы он не ушел, а это, в свою очередь, снизит эффект от сокращения затрат.
  2. Стоимость внешних консультантов — то, на чем экономят практически во всех малых проектах, да и во многих средних. Вместо них используют собственных «гуру». Это приводит к тем же рискам, что и в случае экономии на обучении. К тому же, отвлекаясь на консультации, «гуру» снижают производительность своей основной работы.
  3. Стоимость лицензий — на этом тоже экономят во всех малых проектах. Результат — доступен только базовый набор функций управления конфигурацией (в случае с простыми и дешевыми продуктами типа CVS и Microsoft SourceSafe). Или же (при использовании нелицензионного продукта более высокого класса) увеличивается стоимость администрирования, но в основном опять же применяются базовые функции — на самостоятельное освоение других нет времени (ведь надо и основной работой заниматься). В такой ситуации лучше использовать более простой легальный продукт.
  4. Стоимость годовой технической поддержки — о ней можно говорить только для легальных продуктов. На этом экономят почти всегда, хотя большой выгоды не получается, так как стоимость технической поддержки зависит от количества используемых лицензий, а в малых проектах оно невелико.

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

Строго говоря, внедрение дисциплины управления конфигурацией на уровне одного проекта — неоправданно дорогое удовольствие. Разумный подход состоит в поэтапном внедрении УК в организации.

Общие выгоды от внедрения УК

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

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

Заключение

Достижение всех вышеуказанных целей воз можно с использованием любой современной методологии, основанной на международных стандартах. Это же касается и инструментов: IBM Rational является лидером в этой дисциплине, но существуют похожие инструментальные сред ства других компаний: Telelogic Synergy, Borland StarTeam, PVCS, CVS, MS Source Safe.

Если распределить по важности элементы внедрения, то на первом месте должен быть процесс, а на втором — выбор инструментального средства, так как даже очень хороший инструмент не сможет работать в плохом процессе.