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

Министерство образования и науки Российской Федерации

ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ (ТУСУР)

Ю. П. Ехлаков

УПРАВЛЕНИЕ
ПРОГРАММНЫМИ ПРОЕКТАМИ

Учебное пособие

Томск
«Эль Контент»
2014

УДК
004.413(075.8)
ББК
32.973.26-018.2я73
Е 934

Рецензенты:

Силич В. А., докт. техн. наук, профессор кафедры оптимизации
систем управления Национального исследовательского
Томского политехнического университета;

Мещеряков Р. В., докт. техн. наук, профессор кафедры комплексной
информационной безопасности электронно-вычислительных систем ТУСУРа.

Ехлаков Ю. П.
Е 934
Управление программными проектами : учебное пособие / Ю. П. Ехлаков. — Томск : Эль Контент, 2014. — 140 с.

ISBN 978-5-4332-0163-7

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

УДК
004.413(075.8)
ББК
32.973.26-018.2я73

ISBN 978-5-4332-0163-7
Ехлаков Ю. П., 2014

Оформление.
ООО «Эль Контент», 2014

ОГЛАВЛЕНИЕ

Введение
5

1
Основные понятия программного продукта и программного проекта
7

1.1
Основные понятия программного продукта . . . . . . . . . . . . . . . .
7

1.2
Основные понятия программного проекта . . . . . . . . . . . . . . . . .
10

2
Стандартизация основных процессов жизненного цикла создания
программных продуктов
20

2.1
Руководство к Своду знаний по программной инженерии (Guide to
the Software Engineering Body of Knowledge — SWEBOK) . . . . . . .
20

2.1.1
Этап «Определение требований» . . . . . . . . . . . . . . . . . .
20

2.1.2
Этап «Проектирование ПП» . . . . . . . . . . . . . . . . . . . . .
24

2.1.3
Этап «Конструирование ПП» . . . . . . . . . . . . . . . . . . . .
26

2.1.4
Этап «Тестирование ПП»
. . . . . . . . . . . . . . . . . . . . . .
28

2.1.5
Этап «Сопровождение ПП» . . . . . . . . . . . . . . . . . . . . .
32

2.2
Государственные стандарты РФ серии ГОСТ Р . . . . . . . . . . . . . .
36

2.3
Серия стандартов «Единая система программной документации
(ЕСПД): ГОСТ 19.102–77 ЕСПД «Стадии разработки» . . . . . . . . .
41

3
Модели жизненного цикла программного продукта
45

3.1
Каскадная модель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45

3.2
V-образная модель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48

3.3
Модель прототипирования
. . . . . . . . . . . . . . . . . . . . . . . . . .
50

3.4
Модель быстрой разработки приложений — RAD
. . . . . . . . . . . .
52

3.5
Инкрементная модель жизненного цикла разработки . . . . . . . . . .
54

3.6
Спиральная модель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57

3.7
Методика выбора модели жизненного цикла разработки ПП . . . . .
60

4
Командообразование
67

4.1
Организация командной работы над проектом . . . . . . . . . . . . . .
67

4.2
Роль руководителя в команде . . . . . . . . . . . . . . . . . . . . . . . . .
74

4.3
Основные модели управления командой проекта
. . . . . . . . . . . .
76

4.4
Основные положения мотивации программиста как участника
проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78

5
Инициация программного проекта
84

5.1
Подготовительный этап . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85

5.2
Этап генерации идей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85

Оглавление

5.3
Этап обсуждения и оценки привлекательных идей
. . . . . . . . . . .
86

5.4
Разработка концепций программного проекта
. . . . . . . . . . . . . .
87

5.5
Этап выбора перспективной концепции будущего ПП . . . . . . . . .
89

5.5.1
Оценка перспективности концепции на основе мнения
экспертов
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89

5.5.2
Гибридная модель оценки перспективности концепции . . . .
90

6
Планирование и реализация программного проекта
93

6.1
Основное содержание этапов
планирования и реализации программного проекта . . . . . . . . . . .
93

6.2
Содержательные модели структурной декомпозиции проекта . . . . .
95

6.3
Математические модели планирования программных проектов . . . . 101
6.3.1
Содержательная и математическая модели формирования
календарного плана программного проекта
. . . . . . . . . . . 101

6.3.2
Алгоритм формирования календарного плана программного
проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.4
Алгоритм выравнивания ресурсов . . . . . . . . . . . . . . . . . . . . . . 105

6.5
Рекомендации по управлению ЖЦ программных проектов
. . . . . . 107

7
Управление рисками программного проекта
111

7.1
Основные понятия риска и рискообразующих факторов . . . . . . . . 111

7.2
Управления рисками: идентификация . . . . . . . . . . . . . . . . . . . . 116

7.3
Управления рисками: анализ . . . . . . . . . . . . . . . . . . . . . . . . . 118

7.4
Управления рисками:
планирование мероприятий по реагированию на риски . . . . . . . . . 124

7.5
Управления рисками: мониторинг и управление рисками . . . . . . . 125

Заключение
127

Литература
128

Приложение А Параметры и функциональные зависимости
гибридной модели
131

ВВЕДЕНИЕ

В настоящее время доля IT-услуг составляет 20% в общем обороте IT-отрасли
экономики России, а темп ежегодного прироста оценивается экспертами в 19%.
Около 26% в общем объеме IT-услуг составляют услуги компаний малого и среднего бизнеса по разработке прикладных программных продуктов (ПП). В то же время
только 35% проектов завершились в срок, не превысили запланированный бюджет
и реализовали все требуемые функции и возможности; 46% проектов завершились
с опозданием, расходы превысили запланированный бюджет, требуемые функции
не были реализованы в полном объеме; 19% проектов были полностью неуспешны
и не доведены до завершения [1].

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

В пособии приводится понятие программного продукта, как результата деятельности команды разработчиков и программного проекта, как методологии управления процессами создания программного продукта. Отмечается, что регламентация этих видов деятельности описывается в соответствующих международных
и отечественных стандартах на жизненные циклы (ЖЦ) программного продукта и программного проекта. Приводится сжатое описание наиболее актуальных
стандартов: PMBOK (Project Management Body of Knowledge) — Свод знаний по
управлению проектами, Руководство к Своду знаний по программной инженерии (Guide to the Software Engineering Body of Knowledge — SWEBOK), ГОСТ Р
ИСО/МЭК 12207–99 «Информационная технология. Процессы жизненного цикла программных средств», «Единая система программной документации (ЕСПД):
ГОСТ 19.102–77 ЕСПД «Стадии разработки».

Конкретизация базовых стандартов к особенностям программного продукта
проводится при выборе модели ЖЦ ПП. В пособии описываются содержания,
достоинства, недостатки и области применения следующих моделей: каскадной,
V-образной, прототипирования, быстрой разработки приложений, многопроходной, спиральной.

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

Введение

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

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

Особенности программного продукта как результата интеллектуальной деятельности предъявляют определенные требования к фазам планирования программных проектов. В пособии последовательно раскрываются вопросы:

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

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

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

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

Соглашения, принятые в книге

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Эта пиктограмма означает определение или новое понятие.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Эта пиктограмма означает цитату.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Контрольные вопросы по главе
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Глава 1

ОСНОВНЫЕ ПОНЯТИЯ ПРОГРАММНОГО
ПРОДУКТА И ПРОГРАММНОГО ПРОЕКТА

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

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

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

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

Глава 1. Основные понятия
программного продукта и программного проекта

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

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

ПП как рыночный товар имеет ряд специфических особенностей [3]:

ПП не материален, его нельзя увидеть в процессе конструирования и, следовательно, оперативно повлиять на его реализацию;

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

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

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

ПП является предметом интеллектуального труда и представляет собой
публикацию текста программы/программ на языке программирования или
в виде исполняемого кода;

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

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

Таким образом, ПП как товар по своей сути является объектом интеллектуальной собственности, для которого характерна нематериальная природа существования, и обладает следующими свойствами:

он может обмениваться, но не отчуждаться полностью;

1.1 Основные понятия программного продукта
9

он может быть неоднократно продан, являясь при этом одновременно объектом нескольких рыночных сделок;

не исчезает и не изнашивается в процессе использования;

состоит из материального носителя и нематериальной части;

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

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

большую часть стоимости составляют затраты по созданию данного ПП
относительно небольшой группой специалистов;

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

Технология процесса производства любого материального продукта представляется в виде жизненного цикла (ЖЦ) как последовательности этапов (фаз, стадий), состоящих из технологических процессов, действий и операций, которые
надо выполнить на протяжении всей «жизни» продукта. Жизненный цикл ПП как
товара определен в стандарте ГОСТ Р ИСО/МЭК 12207–99 «Информационная технология. Процессы жизненного цикла программных средств». В стандарте ЖЦ
ПП определен в виде структуры, состоящей из процессов, работ, задач и описывающей этапы создания и развития ПП от установления требований, разработки,
эксплуатации, сопровождения программного продукта и до полного прекращения
его использования.

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

Модель является хорошей абстракцией различных методов разработки ПП,
позволяя лаконично, сжато и информативно их представить. В моделях ЖЦ, необходимо различать фазы и виды деятельности [4].

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

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

Глава 1. Основные понятия
программного продукта и программного проекта

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Вид деятельности — это определенный тип работы, выполняемый в процессе ЖЦ разработки ПП.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Наиболее известными формальными моделями ЖЦ ПП являются: каскадная
модель или водопад, V-образная модель, модель прототипирования, модель быстрой разработки приложений или RAD-модель, многопроходная модель, спиральная
модель.

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

Управление процессами разработки ПП с использованием одной из формальных моделей ЖЦ происходит в рамках проектной деятельности IT-компании.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
В литературе [5–7] приводятся следующие определения проекта:

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

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

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

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

1.2 Основные понятия программного проекта
11

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

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
С этой точки зрения, обобщая представленные в литературе понятия, приведем следующие варианты определения программного
проекта:

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

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

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

Глава 1. Основные понятия
программного продукта и программного проекта

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

Конкретные формулировки желаемого результата программного проекта
можно приводить с учетом правила «железного треугольника» (рис. 1.1) [5]. В проекте должен быть реализован заданный функционал, необходимо выполнить его
в нормативный срок и не превышать плановый бюджет.

Рис. 1.1 – «Железный треугольник» ограничений проекта

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

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

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

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