Управление программными проектами. Учебник

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

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

конкретность — четкость и однозначность понимания результатов;

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

реальность — соизмерение возможностей команды проекта с факторами влияния внешней среды;

согласованность — единство мнений всех участников проекта в понимании конечного результата и координация действий по его достижению;

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

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

При описании желаемого результата программного проекта необходимо определять:

конкретные бизнес-выгоды, которые получит заказчик по завершении проекта;

функционал продукта (услуги), получаемый по окончании проекта;

краткое описание и при необходимости ключевые свойства и/или характеристики функционала.

12 Особенности процесса управления программным проектом

Формулирование желаемого результата программного проекта должно отражать конкретные бизнес-цели с учетом прави-

ла «железного треугольника» (рис. 1.1) [1, 5]. Ни один из углов треугольника не может быть изменен без изменения других: например, чтобы уменьшить время, потребуется увеличить бюджет и/или сократить содержание.

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

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

Содержание

Время Бюджет

Рис. 1.1. Характеристики желаемого результата программного проекта по правилу «железного треугольника»

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

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

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

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

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

1)заказчиков, которым нужна определенная функциональность в конкретные сроки при имеющемся бюджете;

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

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

1.2.Этапы жизненного цикла программного проекта

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

1) Руководство к своду знаний по управлению проектами

(Project Management Body of Knowledge — PMBOK) [2];

5)управление качеством проекта (Project Quality Management);

6)управление человеческими ресурсами проекта (Project Human Resource Management);

7)управление коммуникациями проекта (Project Communications Management);

8)управление рисками проекта (Project Risk Management);

9)управление закупками проекта (Project Procurement Management);

10)управление заинтересованными сторонами проекта (Project Stakeholder Management).

Содержание видов деятельности, необходимых для управления проектом, изложено в Руководстве в описании 47 процессов. Формальная структура описания каждого из процессов представлена в следующих терминах:

вход процесса — информация, данные, документы, технологии, необходимые для эффективного выполнения процесса;

инструменты и методы процесса — способы и техноло-

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

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

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

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

тельности независимо от области приложения или специфики жизненного цикла проекта.

Врамках процессов инициации определяются:

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

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

внутренние и внешние заинтересованные в результатах проекта стороны;

пользования результатов проекта; проведение анализа эффективности внедрения; внесение необходимых изменений в историю успеха компании-разработчика.

Каждая из десяти областей знаний включает соответствующие подразделы:

1)управление интеграцией проекта — разработка плана проекта, организация исполнение плана проекта, контроль изменений в проекте;

2)управление содержанием проекта — формальное при-

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

3)управление сроками проекта — определение состава работ и их взаимосвязей, оценка длительностей работ, составление расписания проекта;

4)управление стоимостью проекта — планирование и оценка стоимости ресурсов, необходимых для работ; разработка бюджета, распределение затрат по работам проекта; контроль стоимости и управление изменениями бюджета;

5)управление качеством проекта — определение стандар-

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

6)управление человеческими ресурсами — идентифика-

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

7)управление коммуникациями — определение потребно-

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

18 Особенности процесса управления программным проектом

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

8)управление рисками проекта — разработку плана уп-

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

9)управление закупками проекта — определение продук-

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

10)управление заинтересованными сторонами проекта —

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

Вариант распределения работ по этапам жизненного цикла, рекомендованных стандартом [2], приведен в табл. 1.1.

ВГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств» приведены семь процессов по управлению программными проектами [6]. Каждый процесс представлен в стандарте в виде совокупности действий и задач, предназначенных для достижения одного или более результатов.

Встандарте описываются следующие процессы управления программным проектом:

1)планирование проекта;

2)оценка проекта и процесс управления;

3)менеджмент решений;

4)менеджмент рисков;

5)менеджмент конфигурации;

6)менеджмент информации;

7)процесс измерений.