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

Посмотреть архив целиком

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

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

Введение

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

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

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

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

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

Цели:

контроль вносимых изменений;

улучшение качества продукта или услуги;

повышение степени удовлетворенности пользователей и/или заказчиков;

организация взаимодействия различных рабочих групп. Действия:

создание или обновление рабочего пространства по заданному профилю;

внесение изменений в файлы проекта;

интеграция изменений с изменениями, внесенными другими участниками;

фиксирование базовой линии текущих версий файлов проекта;

регистрация запросов;

назначение исполнителей и сроков;

контроль исполнения (периодический контроль).

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

автоматизированная процедура сборки версии программного средства;

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

возможность количественной и качествен ной оценки проделанной разработчиками работы;

совместный доступ к информации о запросах на изменения.

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

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

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

Четкое представление о том, кто и чем занимается в проекте, сколько ошибок исправлено, сколько ошибок найдено и т.д.

Полное документирование всех ключевых изменений.

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

Графическое представление метрик проекта, формируемых при определении процесса (типы, количество и т.д.).

Формирование статистических отчетов по проекту (часто называемых срезами). Сформированные метрики проекта ранжируются в зависимости от уровня руководства: руководитель департамента, начальник отдела, менеджер проекта и т.д.

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

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



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

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

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

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

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

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

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

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

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

Количественное распределение участников проекта разработки ПО по их функциям. Например, разработчиков новой версии — 50, сопровожденцев — 50, технических писателей — 10, тестировщиков — 20, менеджеров — 12, системных администраторов — 2, инженеров технической поддержки — 10.

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

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

Стоимость часа рабочего времени каждого специалиста.

Рабочее время каждого специалиста, занятого в проекте внедрения (на основе плана проекта).

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

Стоимость обучения специалистов, участвующих в проекте разработки ПО.

Стоимость внешних консультантов, участвующих в проекте внедрения процесса УК.

Стоимость лицензий средств автоматизации процесса УК.

Стоимость годовой технической поддержки средств автоматизации процесса УК.

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

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

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

Издержки:

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

стоимость обучения специалистов;

стоимость внешних консультантов;

стоимость лицензий;

стоимость годовой технической поддержки.

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

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

Издержки:

стоимость обучения новых специалистов проекта разработки ПО (обычно не более 10% от общего числа специалистов);

стоимость лицензий (при расширении числа участников проекта, обычно до 10% от первоначального количества лицензий);

стоимость годовой технической поддержки.

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

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

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

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

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


Случайные файлы

Файл
13452.rtf
50806.doc
27597-1.rtf
18183.rtf
32966.rtf




Чтобы не видеть здесь видео-рекламу достаточно стать зарегистрированным пользователем.
Чтобы не видеть никакую рекламу на сайте, нужно стать VIP-пользователем.
Это можно сделать совершенно бесплатно. Читайте подробности тут.