Управление проектами - это философия управления, а не инструмент или техника
Управление проектамиГлоссарийФорум

Применение управления прибавочной стоимостью к интенсивным программам разработки ПО

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

Установление процесса для технического задания и разработка исходного технического плана, плана расходов и графика

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

В книге "Определение размера программного обеспечения, его оценка и управление рисками" (Майкл Эванс, 2007) описан 10-ступенчатый процесс для выработки (о) оценки требований к программе. Эти 10 этапов таковы:

  1. Формирование оценочного масштаба.
  2. Формирование технического базового плана, основных принципов и допущений.
  3. Сбор данных.
  4. Оценка и утверждение размера программного обеспечения.
  5. Подготовка базовых оценок.
  6. Рассмотрение, проверка и утверждение оценки.
  7. Определение количества рисков и их анализ.
  8. Создание плана проекта.
  9. Документирование оценки и полученного опыта.
  10. Отслеживание проекта на всем протяжении его разработки.

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

Выявление важнейших показателей управления разработкой программного обеспечения

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

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

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

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

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

Применение основанной на эффективности прибавочной стоимости (PBEV)

Основанная на эффективности прибавочная стоимость (PBEV) – это расширение стандарта систем управления прибавочной стоимостью (EVMS). PBEV преодолевает недостатки стандарта относительно измерения технических характеристик и качества (несоответствия качества требуемому уровню). PBEV основана на стандартах и моделях для проектирования систем, разработки программного обеспечения и управления проектами, делающих упор на качестве. Отличительный признак PBEV – это сосредоточенность на требованиях заказчиков. PBEV предоставляет принципы и указания по стоимостно-эффективным процессам, определяющим самые эффективные показатели расходов, графика, и показатель качества продукта.

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

  • Указанное качество разрабатываемого продукта измерено.
  • Выбраны правильные базовые показатели технических характеристик.
  • Прогресс оценивается объективно.

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

Из-за несоответствия качества в стандарте EVMS нет гарантии, что сообщаемая прибавочная стоимость (EV) основана на показателях продукта и на качестве разрабатываемого продукта. Во-первых, стандарт EVMS утверждает, что прибавочная стоимость – это показатель количества выполненной работы, и что качество и техническое содержание выполняемой работы контролируются другими процессами. Руководитель проекта должен гарантировать, что прибавочная стоимость – это также показатель качества продукта и технической зрелости разрабатываемых продуктов, а не только количества выполненной работы. Во-вторых, принципы EVMS обращены только на рабочий масштаб проекта. EVMS игнорирует масштаб продукта и требования к продукту. В-третьих, стандарт EVMS не требует точных, измеримых показателей прогресса. Он утверждает, что объективные методы прибавочной стоимости предпочтительны, но также утверждает, что допускается использование оценки руководства (субъективной). В отличие от этого, другие стандарты определяют объективные показатели. В-четвертых, EVM считается инструментом управления рисками. Но EVMS не предназначался для управления рисками и не дает никаких указаний по данной теме.

PBEV – это набор принципов и указаний, определяющих самые эффективные показатели расходов, графика и характеристик качества продукта. Он имеет несколько особенностей, отличающих его от традиционного EVMS, дополняя EVMS 4 дополнительными принципами и 16 дополнительными указаниями.

PBEV дополняет традиционный EVMS передовыми методиками. Его принципы и указания позволяют по-настоящему объединить расходы проекта, график и технические характеристики. Отличительный признак PBEV – это сосредоточенность на требованиях заказчика. Показатели масштаба продукта и качества продукта включены в план проекта. Прогресс измеряется по отношению к плану, чтобы удовлетворить все требования заказчиков. Измерение неверных показателей не ослабляет внимание руководства. Следовательно, руководство способно предпринять немедленные корректировочные действия относительно отклонений, представляющих собой опасность для удовлетворения заказчика и целей предприятия.

Использование аналитического процесса для расходов проекта и графика на основе действительной производительности

Когда завершено определение требований, установлены базовые расходы и график, выбраны надлежащие показатели и внедрена система PBEV, заключительная задача – это внедрение процесса, быстро и точно оценивающего конечную стоимость и график на основе действительной производительности. Этот анализ лучше всего выполнять при помощи аналитического/параметрического процесса. Корпорация Galorath называет этот процесс «контроль SEER». Задача контроля SEER – это обеспечение понимания прогресса проекта, чтобы можно было предпринять соответствующие корректировочные действия, когда производственные показатели проекта существенно отклоняются от плана. Контроль SEER предоставляет панель управления, содержащую индикатор состояния  проекта, относящийся к: отклонению от графика, отклонению по срокам, отклонению от нормативных затрат, росту размера, и выявлению и устранению дефектов.

В основе контроля SEER лежит способность прогнозировать итоговый результат проекта, основываясь на реальной производительности на сегодняшний день. Одна из главных  целей контроля SEER – предоставление надлежащей сопроводительной документации (диаграмм и отчетов), чтобы поддержать процесс управления программным проектом и удовлетворить потребности заинтересованных лиц.

Заключение

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


Newer news items:
Older news items:

 

Предложения

Copyright ©2014, PMToday.ru. При копировании материалов наличие прямой индексируемой ссылки на сайт обязательно.