Тематичний архів статей

Оцінка Повернення Інвестицій Від Впровадження Процес управління конфігураціями


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

Введение

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

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

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

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

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

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

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

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

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

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

Оцінка Повернення Інвестицій Від Впровадження Процес управління конфігураціями

Рис. Приклади зрізів

Тут наведено лише типові види зрізів. У реальних проектах типи і число зрізів можуть суттєво відрізнятися в залежності від розмірів компанії, числа розробників, кількості проектів і т.д.

Економічний ефект від впровадження

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

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

Прямі витрати включають витрати на закупівлю засобів автоматизації процесу КК, навчання, технічну підтримку (на чому особливо люблять заощаджувати російські компанії) та інші витрати, пов'язані з передачею будівництвом процесу розробки і супроводу ПС.

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

Давайте порахуємо

Розглянемо типовий сценарій оцінки термінів повернення інвестицій для проекту розробки ПЗ. Для реалізації цього сценарію не обхідних наступні дані:

Кількісний розподіл учасників проекту розробки ПЗ за їх функцій. Наприклад, розробників нової версії - 50, сопровожденцев - 50, технічних письменників - 10, тестувальників - 20, менеджерів - 12, системних адміністраторів - 2, інженерів технічної підтримки - 10. Перелік операцій для кожного фахівця, час виконання яких може бути скорочено за допомогою управління конфігурацією. Кількісний розподіл фахівців, що беруть участь у впровадженні процесу управління конфігурацією. Напри заходів, розробників - 5, технічних письменників - 2, тестувальників - 2, менеджерів - 1, системних адміністраторів - 1, інженерів технічної підтримки - 1. Вартість години робочого часу кожного фахівця. Робочий час кожного фахівця, зайнятого в проекті впровадження (на основі плану проекту). Оцінка зекономленого часу для кожної операції з п. 2 за тиждень. Такі дані можуть бути визначені під час пілотного проекту або взяті з інших аналогічних проектів. Вартість навчання спеціалістів, які беруть участь у проекті розробки ПЗ. Вартість зовнішніх консультантів, що беруть участь у проекті впровадження процесу КК. Вартість ліцензій засобів автоматизації процесу КК. Вартість річної технічної підтримки засобів автоматизації процесу КК.

Тепер можна приступати до підрахунків часу окупності, які зазвичай проводяться з річним інтервалом.

За перший рік підраховуються:

Доходи - вартість зекономленого в тиждень на кожній операції часу, помножена на вартість робочого часу фахівця, що виконує цю операцію. Витрати: вартість робочого часу спеціалістів, які беруть участь у проекті впровадження. Тут також можна врахувати упущену вигоду від їх використання в інших проектах; вартість навчання фахівців; вартість зовнішніх консультантів; вартість ліцензій; вартість річної технічної підтримки.

За другий і наступні роки підраховуються:

Доходи - вартість зекономленого в тиждень на кожній операції часу, помножена на вартість робочого часу фахівця, що виконує цю операцію. Витрати: вартість навчання нових фахівців проекту розробки ПЗ (звичайно не більше 10% від загального числа фахівців); вартість ліцензій (при розширенні числа учасників проекту, зазвичай до 10% від первинної кількості ліцензій); вартість річної технічної підтримки.

З наведеної схеми розрахунків видно, що максимальні витрати припадають на пер ший рік, а доходи мають тенденцію до зростання за рахунок двох факторів:

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

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

Як видно з представленої схеми розрахунку окупності, впровадження процесу КК у від но взятому короткостроковому проекті, термін реалізації якого не перевищує року, зазвичай нерентабельно. Але чи варто відмовлятися від використання управління конфігурацією в короткострокових проектах? Не обов'язково. Є два шляхи виправлення цієї ситуації. Перший, за яким йдуть зараз багато вітчизняних компаній-розробники, - як можна більше скоротити витрати першого року. При цьому зазвичай:

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

виявитися не гірше, ніж повна відмова від управління конфігурацією, оскільки витрачені зусилля замість користі можуть принести тільки шкоду. Але, якщо в організації реалізація короткострокових проектів поставлено на потік, можливий більш продуктивний шлях виходу з подібної ситуації. У наступному розділі будуть проаналізовані особливості кожного зі шляхів вирішення даної проблеми.

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

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

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

скорочення витрат на типові операції, постійно виконуються учасниками проекту; витрати на технічну підтримку.

Наявність великої кількості учасників надає вплив в основному на наступні вели чини:

скорочення витрат на типові операції, постійно виконуються учасниками проекту; витрати на навчання; витрати на ліцензії.

Таким чином, для великих проектів найбільшу віддачу обіцяє збільшення доходів від типових операцій, постійно виконуються учасниками проекту. Це може бути досягнуто тільки за рахунок постійного вдосконалення процесу управління конфігурацією. Тому у великих проектах має сенс виділити додаткові ресурси на постійно діючу групу фахівців, зайнятих удосконаленням процесу КК. Наявність такої групи (назвемо її групою вдосконалення процесу) дозволить також оптимізувати і всі витратні статті, важливі для великого проекту, а саме:

витрати на навчання - наявність постійно діючої групи вдосконалення процесу (ГСП) дозволить використовувати її фахівців в якості тренерів для навчання нових учасників проекту, що дозволить знизити витрати на навчання починаючи з другого року. Початкове навчання все ж таки слід проводити силами зовнішніх фахівців, витрати на ліцензії - одним із завдань вдосконалення процесу КК є оптимізація використання ліцензій, яка може здійснюватися ДСП на основі постійного моніторингу застосування ліцензій у проекті. Зазвичай первинна кількість закуповуваних ліцензій приблизно розраховується виходячи з загальних даних. Реальна потреба в ліцензіях може відрізнятися від первісної оцінки на 15-20% в ту чи іншу сторону, витрати на технічну підтримку - зазвичай виробники програмного забезпечення застосовують політику забезпечення не скількох рівнів технічної підтримки різної вартості, яка залежить від набору вус луг. Наявність ГСП у організації дозволить знизити рівень технічної підтримки за рахунок використання досвіду фахівців ДСП для вирішення частини технічних проблем.

Інші статті витрат не настільки критичні для великого проекту. Можливості їх зниження будуть розглянуті при описі інших типів проектів.

Обговоримо тепер протилежний тип проектів - малі проекти. Головною проблемою малих проектів є їх коротко терміновість, яка не дозволяє говорити про реальне повернення інвестицій для одного малого проекту. Як вже зазначалося, в цьому випадку виникає спокуса максимально зрізати всі витрати, в першу чергу разові. Подивимося, до чого це може привести:

Скорочуємо вартість навчання фахівців проекту розробки ПС, навчивши не всіх, а лише одного-двох працівників. Потім використовуємо їх для навчання інших фахівців. З одного боку - зниження витрат в кілька разів, хоча і не дуже значне за абсолютною величиною, оскільки в малих проектах число учасників не велика. З іншого боку - небезпека того, що навчені фахівці підуть, виявляться нездатними (або не бажають - для збереження своєї унікальності) передати отримані знання іншим. Це може при вести до того, що такому фахівцеві доведеться підвищити зарплату, щоб він не пішов, а це, у свою чергу, знизить ефект від скорочення витрат. Вартість зовнішніх консультантів - те, на чому економлять практично у всіх малих проектах, та й у багатьох середніх. Замість них використовують власних «гуру». Це призводить до тих же ризиків, що і в разі економії на навчанні. До того ж, відволікаючись на консультації, «гуру» знижують продуктивність своєї основної роботи. Вартість ліцензій - на цьому теж економлять у всіх малих проектах. Результат - доступний тільки базовий набір функцій управління конфігурацією (у випадку з простими і дешевими продуктами типу CVS і Microsoft SourceSafe). Або ж (при використанні неліцензійного продукту більш високого класу) збільшується вартість адміністрування, але в основному знову ж застосовуються базові функції - на самостійне освоєння інших немає часу (адже треба і основною роботою займатися). У такій ситуації краще використовувати більш простий легальний продукт. Вартість річної технічної підтримки - про неї можна говорити лише для легальних продуктів. На цьому економлять майже завжди, хоча великої вигоди не виходить, тому що вартість технічної підтримки залежить від кількості використовуваних ліцензій, а в малих проектах воно невелике.

Підводячи підсумок, можна констатувати, що всі розглянуті варіанти здійснюються за рахунок перекладання роботи на своїх фахівців. Це призводить до додаткових витрат при найманні додаткових фахівців або до зниження продуктивності фахівців, зайнятих в основному проекті. Тобто такий варіант економії пов'язаний з додат тільних ризиками при незначному зниженні витрат. Рентабельність при цьому залишається незадовільною.

Строго кажучи, впровадження дисципліни управління конфігурацією на рівні одного проекту - невиправдано дороге задоволення. Розумний підхід полягає в поетапному впровадженні КК в організації.

Загальні вигоди від впровадження КК

До загальних вигод від впровадження процесу управління конфігураціями можна віднести:

приріст продуктивності (відносно вихідного рівня) з другого проекту - 30% (залежно від типів проектів, кількості розробників і числа замовників ефект може бути істотно вище); планомірний розвиток без різких спадів; забезпечення взаємодії між учасниками проекту; прозоре управління проектом; зниження ризиків , пов'язаних з невиконанням проекту в заданий термін з запланованими ресурсами; чітке розуміння поточної завантаження розробників; використання статистичної інформації по раніше виконаних проектів; незалежність компанії від окремих осіб; відповідність процесів розробки і зі проводження стандартам якості (CMM, ISO 12207). Висновок

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

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

Ще статті автора


  Схожі новини: {related-news}