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

рамках выполнения некоторых заданий, характеризующихся определенными датами начала и окончания, пределами финансирования и ресурсами [4]. Джеймс Льюис

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

как правило, бюджет [5].

Менеджмент – это практика выполнения и управления проектом. Понятие

менеджмент (управление) программным проектом предполагает наличие необходимых навыков.

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

график) и ресурсы (затраты).

Рисунок 1.2 – Треугольник менеджмента проектов

11

Проект имеет несколько характеристик:

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

момент завершения и начала действия (проект должен иметь четко определенное начало и конец действия, выражаемое в виде дат);

уникальность (проект – одноразовая сущность, не повторяющая какую-

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

ограничения (проект имеет ограничения по стоимости, графику и качеству выполнения).

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

1.2 Определение программы и управления проектами

Существует ряд определений понятия «программа».

Керцнер (Kerzner)описал программу как распределенную по времени систему,

которая реализуется в течение определенного периода времени, предназначенная для достижения определенной цели [6]. Дон Шафер (DonShafer) определяет программу как действие, направленное на достижение комплексной цели. PMI

приводит следующее краткое определение: программа – это группа взаимосвязанных проектов, управляемых централизованным способом[7].

Эти определения схожи в том, что программа является:

большой (программы включают в себя несколько проектов);

12

длинной (программы реализуются на протяжение длительного периода времени);

общей (программы имеют определенные для них общую область действия,

конечные даты и цели).

Таким образом, программа – это мероприятие масштабное и продолжительное по времени с предварительно определенными датами и окончания и целями,

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

PMI определяет управление проектами как набор методов, необходимых для:

эффективного управления проектом;

планирования и составления графика работ;

мониторинг результатов;

успешной реализации проекта.

Керцнер (Kerzner) описывает менеджмент проектами как управление ресурсами компании на основе планирования, организации и контроля, с целью достижения установленной цели [8].

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

Наряду с терминами ПО, проект, программа, управление проектами,

менеджмент, программный инжиниринг применяются другие понятия процесс,

задача, действие, фаза и система.

1.3 Определение процесса, задачи, действия, фазы и системы

Управление проектами включает рабочие процессы, поддерживаемые инструментами разработки. Согласно Мерриам-Вебстер (MerriamWebster) процесс

– это ряд действий или операций, которые приводят к определенному результату [9].

13

Наиболее часто используется следующее определение: процесс – это ряд действий, которые преобразуют набор входных данных в какой-либо результат.

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

процессы продукта и процессы проекта, представленные в таблице 1.1.

Таблица 1.1 – Процессы проекта и продукта

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

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

задача – это самый низкий уровень работ в рамках проекта;

действие – элемент работы, выполненной в течение определенного периода времени.

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

Керцнер (Kerzner) описывает систему как единую организованную и распределенную группу элементов, ориентированных на достижение общей цели

[8].

14

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

состоящие из аппаратных средств, ПО и процессов.

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

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

1.4 Компетенции продукта (ПО)

Методы разработки ПО и компетенции представлены в таблице 1.2.

Таблица 1.2 – Компетенции продукта

Продолжение таблицы 1.2

Компетенция продукта 1: в определение критериев для выполнения экспертных оценок описывается и проводится оценка конечных продуктов работы.

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

Компетенция продукта 2: понимание стандартов процесса влияет на успешную деятельность менеджера проекта. Менеджеры проектов используют специальные промышленные стандарты (IEEE, ISO, ANSI, NIST и т.д.) по реализации проектов, анализу, разработке, кодированию, тестированию и т.д.

Компетенция продукта 3: идентификация клиентской среды и требований,

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

Компоненты стандартного проекта связывают отношения и планы: менеджмента

16

программных проектов (softwareprojectmanagementplan, SPMP), управления рисками, коммуникации, менеджмента конфигурации ПО

(softwareconfigurationmanagementplan, SCM), план обеспечения качества ПО

(softwarequalityassuranceplan, SQA)и план тестирования. Менеджер продукта,

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

Компетенция продукта 4: оценивание различных применяемых подходов.

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

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

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

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

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

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

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

17

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

(патенты, торговые марки, авторские права и подготовка торговли).

Компетенция продукта 7: оценивание трудностей, рисков, затрат и графика.

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

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

Продолжительность разработки и понесенные при этом затраты можно оценить,

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

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

Компетенция продукта 8: определение процессов отбора. Применение менеджерами проектов методов разработки ПО а также методик и инструментов совместно с методами менеджмента проектов определяет успех выполнения проекта. На всех этапах разработки проекта необходимо предусмотреть систему менеджмента конфигурации (Configurationmanagement, CM). Каждый отдельный поставляемый продукт проекта, начиная с исследования концепции и документирования устанавливаемых требований, должен сохраняться при контроле конфигурации.

Компетенция продукта 9: изменение стандартных процессов в целях удовлетворения требований проекта. Менеджеру проекта необходимо определение

18

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

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

Компетенция продукта 10: отслеживание качества разрабатываемого ПО. В

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

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

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

19

1.5 Навыки менеджмента проектов

Кроме навыков работы с продуктом, имеются навыки проектного менеджмента, входящие в состав 34 компетенций. Эти навыки представлены в таблице 1.3.

Таблица 1.3 – Компетенции проекта