МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ

НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

«ХАРЬКОВСКИЙ ПОЛИТЕХНИЧЕСКИЙ ИНСТИТУТ»

На правах рукописи

ХАРАЗИЙ Анна Владимировна

УДК 65.01.005

МОДЕЛИ И МЕТОДЫ ВЫБОРА МЕТОДОЛОГИИ УПРАВЛЕНИЯ

ПРОЕКТОМ ПРИ РАЗНОЙ ИНФОРМИРОВАННОСТИ КОМАНДЫ

05.13.22 – управление проектами и программами

Диссертация на соискание ученой степени

кандидата технических наук

Научный руководитель:

доктор технических наук, профессор

КОНОНЕНКО Игорь Владимирович

Харьков – 2015

2

СОДЕРЖАНИЕ

ВВЕДЕНИЕ .............................................................................................................. 5

РАЗДЕЛ 1 МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИ, ИХ

КЛАССИФИКАЦИЯ И СУЩЕСТВУЮЩИЕ ПОДХОДЫ К ВЫБОРУ

НАИБОЛЕЕ ЭФФЕКТИВНОЙ МЕТОДОЛОГИИ ............................................ 12

1.1 Классификация методологий управления проектами ................................. 12

1.2 Обзор наиболее популярных методологий и стандартов управления

проектами ............................................................................................................... 15

1.2.1 Методология PMBOK ................................................................................... 16

1.2.2 Методология PRINCE2 ................................................................................. 18

1.2.3 Методология SWEBOK ................................................................................ 19

1.2.4 Методология Р2М ......................................................................................... 20

1.2.5 Методология SCRUM ................................................................................... 21

1.2.6 Методология Crystal Clear ............................................................................ 22

1.3 Анализ существующих методов и рекомендаций к выбору

методологий ........................................................................................................... 23

1.4 Анализ моделей и методов многокритериальной оптимизации

содержания проектов ............................................................................................ 28

1.5 Анализ существующих методов проверки устойчивости решений ........ 37

1.6 Цель и задачи исследования........................................................................... 38

Выводы к разделу 1 ............................................................................................... 42

РАЗДЕЛ 2 МЕТОДЫ ВЫБОРА МЕТОДОЛОГИИ ДЛЯ УПРАВЛЕНИЯ

ПРОЕКТОМ В ОБЛАСТИ СОЗДАНИЯ ИНФОРМАЦИОННЫХ

ТЕХНОЛОГИЙ ...................................................................................................... 44

2.1 Главные особенности предложенных методов выбора методологии для

управления проектом ............................................................................................ 44

2.2 Метод выбора методологии управления проектом на основе

существующих рекомендаций экспертов ........................................................... 45

3

2.3 Метод выбора методологии управления проектом с точки зрения

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

2.4 Метод выбора методологии управления проектом на основе оптимизации

содержания проекта .............................................................................................. 62

2.5 Математическая модель многокритериальной задачи оптимизации

содержания проекта .............................................................................................. 64

2.6 Метод последовательных уступок для оптимизации содержания

проекта .................................................................................................................... 74

Выводы к разделу 2 ............................................................................................... 83

РАЗДЕЛ 3 ВЫБОР МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТОМ НА

ОСНОВЕ РЕКОМЕНДАЦИЙ ЭКСПЕРТОВ, А ТАКЖЕ ПО КРИТЕРИЯМ . 86

ТРУДОЗАТРАТЫ, СТОИМОСТЬ, РИСКИ ....................................................... 86

3.1 Описание проекта по созданию программного продукта «ForPlan» ......... 86

3.2 Применение метода выбора методологии управления проектом на основе

существующих рекомендаций ............................................................................. 88

3.3 Применение метода выбора методологии управления проектом с точки

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

3.3.1 Оценка трудозатрат и стоимости управления проектом при

использовании методологии PMBOK ................................................................. 91

3.3.2 Оценка стоимости управления проектом при использовании

методологии PRINCE2 .......................................................................................... 93

3.3.3 Оценка стоимости управления проектом при использовании

методологии P2M .................................................................................................. 95

3.3.4 Оценка стоимости управления проектом при использовании

методологии SWEBOK ......................................................................................... 97

3.3.5 Оценка стоимости управления проектом при использовании

методологии SCRUM ............................................................................................ 99

3.3.6 Оценка стоимости управления проектом при использовании

методологии Crystal Clear ................................................................................... 102

4

3.3.7 Оценка рисков от управления проектом при использовании

методологий PMBOK, PRINCE2, P2M и SWEBOK ........................................ 104

3.3.8 Оценка рисков от управления проектом при использовании

методологии SCRUM .......................................................................................... 107

3.3.9 Оценка рисков от управления проектом при использовании

методологии Crystal Clear ................................................................................... 112

3.4 Анализ результатов, полученных при применении метода выбора

методологии управления проектом с точки зрения трудозатрат, стоимости

управления и сопутствующих рисков ............................................................... 115

Выводы к разделу 3 ............................................................................................. 117

РАЗДЕЛ 4 ВЫБОР МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТОМ НА

ОСНОВЕ ОПТИМИЗАЦИИ СОДЕРЖАНИЯ ПРОЕКТА .............................. 119

4.1 Программное обеспечение для многокритериальной оптимизации

содержания проекта «ScopePro» ........................................................................ 119

4.2 Описание интерфейса программного обеспечения «ScopePro»............ 121

4.3 Подготовка входных данных для решения задачи оптимизации

содержания проекта ............................................................................................ 131

4.4 Результаты решения задачи оптимизации содержания проекта, для

управления которым применяется методология Scrum .................................. 137

4.5 Результаты решения задачи оптимизации содержания проекта, для

управления которым применяется методология Crystal Clear ....................... 141

4.6 Анализ устойчивости решений задачи оптимизации содержания

проекта .................................................................................................................. 143

Выводы по разделу 4 ........................................................................................... 152

ВЫВОДЫ ............................................................................................................. 155

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ......................................... 158

ПРИЛОЖЕНИЯ ................................................................................................... 179

5

ВВЕДЕНИЕ

Актуальность темы. Управление проектами все чаще становится

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

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

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

множество требований к проектам приводят к увеличению числа

методологий, стандартов, руководств и принципов управления проектами. В

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

проектами, получивших широкое распространение. В первую очередь к ним

относятся PMBOK, PRINCE2, P2M. Наряду с ними разработан ряд

специальных методологий для применения в конкретных отраслях. Особенно

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

сфере информационных технологий (ИT), из которых к наиболее известным

и широко используемым относятся гибкие методологии разработки (Agile

software development).

Обилие методологий и их разновидностей, а также неоднозначность

объема, в котором та или иная методология может применяться в проекте,

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

или ее подмножества для применения в конкретном проекте.

На данный момент в литературе подходы к выбору методологий

управления проектом носят рекомендательный характер и сводятся к

сопоставлению двух классов методологий: жестких (plan-driven) и гибких.

Команды проектов могут иметь различную степень осведомленности о

существующих методологиях. Методы выбора методологии должны быть

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

методологии и когда владеет достаточно большим числом методологий, а

также имеет возможность оценивать трудоемкость использования

методологии, затраты на ее применение, связанные с ней риски.

6

Указанные особенности нынешней ситуации свидетельствуют об

актуальности научно-прикладной задачи разработки модели и методов

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

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

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

Диссертационная работа выполнена на кафедре стратегического управления

Национального технического университета «Харьковский политехнический

институт» в рамках госбюджетной научно-исследовательской работы № гос.

регистрации 0115U000543 по теме «Разработка информационной технологии

формирования портфелей проектов национального уровня на основе

имитационной модели научно-технологического развития Украины» по

разделу «Разработка метода выбора методологии управления проектом».

Вклад автора заключается в разработке модели и методов выбора

методологии при различной степени осведомленности лица, принимающего

решения, и команды проекта.

Цель и задачи исследования. Целью диссертационного исследования

является повышение качества управления проектами путем выбора

рациональной методологии управления.

Для достижения поставленной цели необходимо решить следующие

научные и практические задачи:

- разработать метод выбора методологии управления проектом,

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

значимые характеристики проекта и его окружения;

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

критериев трудоемкости, стоимости и рисков применения той или иной

методологии;

- разработать метод выбора методологии, основанный на методе

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

методологий и выборе оптимальной;

7

- создать программное обеспечение для автоматизации расчетов,

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

многокритериальной оптимизации содержания проекта;

- решить задачу выбора методологии управления для проекта в

области ИТ;

- оценить устойчивость полученных результатов к изменению

исходных данных;

- внедрить результаты работы в практику управления реальными

проектами.

Объект исследования – процессы управления проектами.

Предмет исследования – модели и методы выбора методологии

управления проектами.

Методы исследования. При разработке метода выбора методологии на

основе анкетирования использовался системный подход. Кроме того, при

формировании анкеты для метода выбора методологии на основе

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

применения различных методологий управления проектами.

При разработке метода выбора методологии с точки зрения

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

методы эконометрики, а также методы оценивания рисков.

При усовершенствовании модели многокритериальной оптимизации

содержания проектов использовались методы эконометрики,

математического программирования, оптимизационно-имитационный

подход.

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

проектов использовались методы сетевого планирования, метод

последовательных уступок, метод экспертных оценок и системный подход.

Для решения однокритериальных оптимизационных задач применялся метод

неявного перебора. При анализе устойчивости полученных результатов

использовался метод Монте-Карло.

8

Научная новизна полученных результатов. Основной научный

результат диссертации заключается в создании моделей и методов выбора

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

доступных исходных данных и учитывает не только особенности проекта, но

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

Впервые:

− разработан метод выбора методологии управления проектами на

основе решения трехкритериальной задача оптимизации по критериям:

трудозатраты, стоимость управления и сопутствующие риски, что позволяет

оценить количественно преимущества и недостатки выбираемой

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

− разработан метод выбора методологии управления проектом на

основе оптимизации содержания проекта по критериям: экономический

эффект (прибыль), сроки, стоимость, качество, риски, технологический,

экологический и социально-политический эффекты, что позволяет учесть

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

выполнения операций.

Усовершенствованы:

− метод выбора методологии управления проектом на основе

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

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

сделать более обоснованный выбор;

− математическая модель решения задачи многокритериальной

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

функциями технологический, социально-политический и экологический

эффекты, что позволяет более полно характеризовать ценности проекта.

Практическое значение полученных результатов. Предложенные в

работе математические модели и методы позволяют решать задачи выбора

методологии управления проектами в зависимости от наличия и полноты

исходных данных, а также в зависимости от того, насколько менеджер и

9

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

на основе разработанных методов программное обеспечение «ScopePro»

может быть применено для оптимизации содержания проектов и выбора

методологии на предприятиях и в организациях всех отраслей экономики.

Для проекта создания компьютерной программы «ForPlan» в

Национальном техническом университете «Харьковский политехнический

институт» были применены разработанные методы выбора методологии

управления. С помощью метода выбора методологии на основе

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

SCRUM, Crystal Clear и P2M. Аналогичный результат был получен с

помощью метода, основанного на оценивании трудозатрат, стоимости

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

основании пятикритериальной оптимизации содержания проекта и анализа

его устойчивости к изменению исходных данных. В качестве лучшей

предложено примять Crystal Clear.

Полученные результаты исследования внедрены:

в проектную деятельность ООО «Пайп-Икс» (акт внедрения от

31.03.2015 г.);

в проектную деятельность ООО «НВК Автоматизовані системи» (акт

внедрения от 10.04.2015 г.);

в проектную деятельность ООО «АЙН УКРАИНА» (акт внедрения

от 26.05.2015 г.);

в учебный процесс Национального технического университета

«Харьковский политехнический институт» (акт внедрения от 05.06.2015 г.).

Личный вклад соискателя. Все положения, вынесенные на защиту,

получены автором лично. Соискателю лично принадлежат в совместных

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

управления проектом [1], разработка метода выбора методологии на основе

существующих рекомендаций экспертов [2, 3], разработка метода выбора

методологии управления проектом с точки зрения трудозатрат, стоимости

10

управления и сопутствующих рисков [3], применение метода

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

оптимизации содержания проектов [4, 5], разработка метода выбора

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

[6, 7], совершенствование математической модели решения задачи

многокритериальной оптимизации содержания проекта путем дополнения

модели новыми целевыми функциями [8], описание разработанного

программного обеспечения для оптимизации содержания проектов

«ScopePro» [9], изложение результатов, полученных при применении

разработанных методов [7,10 ,11]

Апробация результатов диссертации. Основные результаты

диссертационной работы, выводы и предложения докладывались и

обсуждались на таких научно-практических конференциях:

IX Міжнародна науково-практична конференція «Сучасні інформаційні

технології в економіці та управлінні підприємствами, програмами та

проектами» (м. Алушта, 12-18 вересня 2011р.); III Міжнародна науково-

практична конференція «Інтегроване стратегічне управління, управління

проектами і програмами розвитку підприємств і територій» (смт. Славське

Львівської області 7-10 лютого 2012 р.); Міжнародна науково-практична

конференція «Сучасні інформаційні технології в економіці і управлінні

підприємствами, програмами і проектами» (м. Алушта, 10 – 16 вересня

2012 р.); IV Міжнародна науково-практична конференція «Інтегроване

стратегічне управління, управління проектами і програмами розвитку

підприємств і територій» (м. Яремче Івано-Франківської області, 12-15

лютого 2013 р.); Х Міжнародна конференція «Управління проектами у

розвитку суспільства» (м. Київ, 17 – 18 травня 2013 року); The 7th IEEE

International Conference on Intelligent Data Acquisition and Advanced Computing

Systems: Technology and Applications (IDAACS’2013) (Berlin, Germany,

September 12-14, 2013); Международная научно-практическая конференция

«Математическое моделирование процессов в экономике и управлении

11

инновационными проектами» (ММП-2014), (г. Алушта 15- 21 сентября

2014); VI Міжнародна науково-практична конференція «Інтегроване

стратегічне управління, управління проектами і програмами розвитку

підприємств і територій» (Буковель 10-13лютого 2015р.); XIII

Международная научно-практическая конференция «Современные

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

программами и проектами» (Харьков-Одесса, 2015 г.)

Публикации. Основные результаты диссертационной работы

изложены в 11-ти работах, из них 3 статьи в научных журналах, один из

которых входит в наукометрическую базу Scopus, 3 статьи в сборниках

научных трудов, которые входят в перечень профессиональных, один из

журналов является международным, 5 материалов и тезисов конференций.

12

РАЗДЕЛ 1

МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИ, ИХ

КЛАССИФИКАЦИЯ И СУЩЕСТВУЮЩИЕ ПОДХОДЫ К ВЫБОРУ

НАИБОЛЕЕ ЭФФЕКТИВНОЙ МЕТОДОЛОГИИ

1.1 Классификация методологий управления проектами

Бурное развитие управления проектами, как научного направления,

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

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

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

стандартов и рекомендаций, как в нашей стране, так и за рубежом. Среди

отечественных ученых, внесших большой вклад в развитие методологий

управления проектами, следует отметить С.Д. Бушуева [12-20], Н.С. Бушуеву

[12,14,20], А.А. Белощицкого [21-23], В.Д. Гогунского [24-26],

Е.А. Дружинина [27], В.М. Илюшко [28-30], К.В. Кошкина [31],

О.В. Малееву [32,33], С.И. Неизвестный [34-35], Ю.П. Рака [36,37], В.А. Рача

[38-41], C.К. Чернова [42], И.В. Чумаченко [43,44]. Из зарубежных учёных,

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

необходимо назвать Р.Д. Арчибальда [39], В.Н. Буркова [46-48],

В.И. Воропаева [49-52], Ф.К. Грея [53], А. Коуберна [54-56] Х. Керцнера

[57,58], Д. Локка [59], В.И. Либерзона [60], П. Мартина [61], И.И. Мазура,

В.Д. Шапиро [62], Дж. Родни Тернера [63], П. Ройша [64,65], М.Л. Разу

[52,53], А.С. Товба, Г.Л. Ципеса [68], и многих других.

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

научного направления, перед менеджерами встает непростая задача – выбор

наиболее подходящей методологии для управления новыми или уже

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

Также эта проблема заставляет задуматься, а на самом ли деле уже

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

лучшей, чем остальные существующие. Для лучшего понимания всего

13

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

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

современных ученых и практиков в сфере управления проектами, дающие

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

и областей применения.

В работе [69] автор предлагает классифицировать методологии по ряду

наиболее важных характеристик.

По характеру обоснования рекомендаций автор делит методологии на

концептуальные и эмпирические.

По назначению методологии предлагается делить на модели зрелости,

процессные модели, проектные методологии, индивидуальные и групповые

практики.

По характеру условий реализации проекта методологии делятся на

прогнозируемые (предикативные) и адаптивные. Первые требуют

подробного планирования на начальном этапе разработки проекта, а вторые -

более гибко относятся к изменениям в планах проекта и адаптируются под

текущие условия осуществляемого проекта. Далее данная классификация

уточняется путем деления методологии в зависимости от лежащей в ее

основе модели жизненного цикла: каскадная, V-образная, итеративная и

спиральная.

По характеру знаний и фокусу автор разграничивает методологии на

инженерные, управленческие и интегрированные. В основе инженерных

моделей лежат применяемые технологии создания продукта. Управленческие

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

теоретических основах менеджмента. Интегрированные методологии

обобщают инженерные и управленческие концепции в единую систему

управления.

Также методологии делят по характеру рисков, связанных с поставкой

некачественного продукта проекта. Рассматривают риски потери комфорта,

14

потери денег, потери значительного количества денег и бизнеса, потери

жизни.

Методологии в области информационных технологий (ИТ) разделяют

на методологии управления разработкой программного обеспечения и

методологии внедрения информационных систем.

В статье [54] для классификации методологий Алистэр Коуберн вводит

такие понятия как размер методологии, под которым понимается количество

элементов управления в ней. К элементам управления автор относит виды

деятельности, меры качества, стандарты, и т.д. Также вводится понятие

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

детализации и связности между элементами управления, необходимыми для

ее осуществления, и понятие объема методологии. Объем, в данном случае,

оценивается протяженностью жизненного цикла проекта, множеством ролей

и видов деятельности, которые продиктованы методологией.

В работе Бушуевой Н.С., Ярошенко Ю.Ф. и Ярошенко Р.Ф. [70]

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

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

область использования, размер проекта, риски возникновения проблем,

сложность внедрения, интенсивность использования ресурсов, частые

изменения в проекте, поддержка изменений в содержании проекта,

поддержка отчетности по проекту, система ведения документооборота,

использование информационных технологий, накопленный опыт и

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

подход, проектный подход.

Данный перечень может служить проектному менеджеру инструментом

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

использовать в деятельности организации [70].

В работе [71] проведен сравнительный анализ существующих

стандартов по управлению проектами. Все стандарты были разделены на

четыре категории: стандарты управления монопроектами, к которым

15

относятся PMBOK [72], ISO 10006 [73], PRINCE2 [74], P2M [75]; стандарты

управления программами, к которым отнесен – Standard for Program

Management [76]; стандарты описания компетенций менеджера проекта –

PMCDF [77], ICB Version 3.0 [78], НТК [79], GAPPS [80]; стандарты

организационного управления проектами – ОРМ3 [81]. Автор отмечает, что

PMBOK, ISO 10006 и PRINCE2 относятся к процессным методологиям, а

P2M – к системным. Также в работе выделены предметные области

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

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

рассмотренных методологий, кроме ISO 10006, существуют системы

индивидуальной сертификации. Автор обратил внимание на то, что стандарт

по компетенциям PMCDF включает компетенции знания, компетенции

исполнения и поведенческие компетенции, ICB Version 3.0 включает

контекстные, технологические и поведенческие компетенции, а НТК

опирается на знания и личные качества.

Рассматривая стандарты по управлению программами, автор отмечает,

что Standard for Program Management построен на процессном подходе,

содержит пять групп процессов: инициация, планирование, мониторинг,

контроль и завершение, но, по сравнению с P2M, в нем не определены

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

подходе, и дает определения ценности программы.

Следует отметить, что приведенные в работе [71] сравнения уже

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

1.2 Обзор наиболее популярных методологий и стандартов

управления проектами

К наиболее популярным и широко используемым методологиям и

стандартам управления проектами, можно отнести – A Guide to the Project

Management Body of Knowledge (PMBoK) [72], PRojects IN Controlled

Environments 2 (PRINCE2) [74], Project and Program Management for Enterprise

16

Innovation (Р2М) [75], ISO 21500 [82], ISO 10006 [73], к стандартам по

управлению программами относят The Standard for Program Management

[76], Managing Successful Programmes (MSP) [83], наиболее

распространенным стандартом по управлению портфелями считается The

Standard for Portfolio Management [84], стандарты по управлению проектами,

программами и портфелями России [85]. Популярным стандартом,

описывающим компетенций менеджера проекта является ICB [78]. К широко

известным моделям зрелости управления проектами относятся ОРМ3 [81] и

СММI [86]. Также стоит отметить наиболее применяемые методологии

управления в сфере IТ, к которым можно отнести – Software Engineering

Body of Knowledge (SWEBOK) [87], SCRUM [88], KANBAN [89], Dynamic

System Development Method (DSDM) [90], Microsoft Solutions Framework

(MSF) [91], Rational Unified Process (RUP) [92], XP[94] Crystal Clear [55].

Рассмотрим более подробно некоторые из перечисленных выше

методологий.

1.2.1 Методология PMBOK

Наиболее распространенным стандартом управления проектами

является американский национальный стандарт (A Guide to the Project

Management Body of Knowledge; далее — PMBOK®) [72], который содержит

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

80-х годов его развивает Институт управления проектами (PMI — Project

Management Institute), находящийся в штате Пенсильвания, США. Этот

стандарт представляет собой ясную и достаточно действенную процессную

модель управления проектами, которая, к тому же, расширена на управление

портфелями и программами [94, 95]. PMBOK является универсальным

стандартом и может эффективно использоваться в любых отраслях и сферах

деятельности. В последней, пятой, редакции данной методологии можно

выделить несколько основных моментов [96]:

17

- основным объектом управления и оптимизации является проект и

показана четкая его взаимосвязь с программами, портфелями и

операционной деятельностью;

- четко прописан жизненный цикл проекта: старт проекта,

организация и подготовка, выполнение работ проекта, завершение проекта;

- управление проектом осуществляется через применение 47

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

(инициация (initiation), планирование (planning), исполнения (executing),

мониторинга и контроля (controlling), закрытия (closing)) и десяти областей

знаний (управление интеграцией проекта, управление содержанием проекта,

управление сроками проекта, управление стоимостью проекта, управление

качеством проекта, управление человеческими ресурсами проекта,

управление коммуникациями проекта, управление рисками проекта,

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

проекта).

- раскрыты межличностные качества, которые необходимы менеджеру

проекта для эффективной реализации проекта (лидерство,

командообразование, мотивация, коммуникация, воздействие, принятие

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

построение доверительных отношений, управление конфликтами,

наставничество) [72, 96].

Стандарт PMBOK является одной из наиболее проработанных

методологий, упор в которой сделан, непосредственно, на процесс

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

конкретной предметной области, что делает его удобным инструментом при

управлении любым проектом, программой или портфелем.

К недостаткам PMBOK можно отнести его громоздкость, что является

обратной стороной универсальности, и наличие большого количества

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

сложна в практической реализации.

18

1.2.2 Методология PRINCE2

Методология управления проектами PRINCE 2 (PRojects IN Controlled

Environment) была разработана в 1989 году в Великобритании для

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

технологий. В настоящее время этот стандарт стал всемирно признанным

(используется более чем в 150 странах мира) и представляет собой

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

адаптировать его для управления любыми типами проектов [83, 94]. Одной

из особенностей методологии PRINCE 2 является применение «управления

по отклонениям», что обеспечивает явное распределение ролей и

обязанностей в проекте. PRINCE2 включает в себя набор принципов,

контрольных тем и модель процессов [97].

Каждый процесс проекта характеризуется входными и выходными

данными и специфическими целями. Стандарт PRINCE 2 выделяет 6

основных процессов: старт проекта (Starting up a Project), инициация проекта

(Initiating a Project), контроль стадии (Control of a Stage), управление

поставкой продукта (Managing Product Delivery), управление границами

стадий (Managing Stage Boundaries), завершение проекта (Closing a project).

Кроме того используются и два обеспечивающих процесса - планирование

(Planning) и руководство (Direction of project), которые проходят в течение

всего проекта. Все процессы включают в себя подпроцессы, которых всего

насчитывается 45. Кроме того, следует обратить внимание, что PRINCE 2

описывает три методики — планирование, основанное на продукте, обзоры

качества и управление изменениями [83]. Весь процесс управления состоит

из стадий, подстадий и связей.

Широкое применение методологии PRINCE 2 связано с тем, что

руководство по этому стандарту представляет собою четко прописаный

документ, состоящий из основного текста, понятно структурированных

перечней вопросов и диаграмм процессов. Кроме того, PRINCE 2 дает

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

19

ролей и обязанностей на каждом уровне, сокращения количества совещаний,

разделения менеджерских и технических действий, качественной оценки

рисков проекта.

К недостаткам стандарта PRINCE 2 можно отнести отсутствие

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

1.2.3 Методология SWEBOK

Профессиональное ядро знаний SWEBOK содержит в себе обобщение

знаний и опыта специалистов в области программной инженерии, а также

того, каким образом это согласуется с современным пониманием процессов

создания и существования программного обеспечения [98, 99]. В этом ядре

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

основные, для проектирования программного обеспечения, и

дополнительные, которые включают организационные методы и подходы,

отражающие инженерию управления проектированием программных

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

относятся:

1. Инженерия требований. Отражаются свойства, которыми должно

обладать ПО для адекватного и запланированного выполнения своих

функций c точки зрения людей, которые заинтересованы в его создании.

2. Проектирование ПО. Процесс определения архитектуры,

компонентов, интерфейсов и других характеристик конечного программного

продукта.

3. Конструирование ПО. Процесс создания работающего ПО с

привлечением методов верификации, кодирования и тестирования его

компонентов. Инструментами этой области являются языки

программирования, программные методы и инструментальные системы.

4. Тестирование ПО. Процесс верификации созданного продукта в

статике, т.е. внешний вид, интерфейс, и в динамике, т.е. прогон тестовых

данных и сравнение результатов с заранее запланированными.

5. Сопровождение ПО. Процесс поддержки функциональности

20

созданного ПО, улучшение производительности и внесение изменений в

случае обнаружения ошибок.

К организационным областям относятся:

1. Управление конфигурацией.

2. Управление проектами.

3. Процесс инженерии программных систем.

4. Методы и средства инженерии.

5. Инженерия качества программных систем [87,100].

Таким образом, SWEBOK демонстрирует отличие программной

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

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

конечной цели создания программного продукта. Кроме того, данное

руководство подразумевает, что владеющий им специалист не очень зависит

от перемен, которые происходят в технологиях.

К недостаткам SWEBOK специалисты относят тот факт, что несмотря

на то, что первостепенной целью этого стандарта было представление

программной инженерии, как области профессиональной деятельности, в нем

не решается задача создания теоретической базы для обеспечения качества

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

1.2.4 Методология Р2М

Статус стандарта Японской ассоциации управления проектами имеет с

2005 года стандарт P2M, который был разработан профессором Ш. Охарой

[75]. Он рассчитан на управление инновационными проектами и

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

организации в результате выполнения проектов. Важным аспектом этого

является, так называемое «ментальное пространство», т.е. взаимодействие

между лицами, разделяющими цели, миссию, ценности проекта и

заинтересованы в его успешном завершении [101]. В P2M вводится понятие

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

1) вход, который показывает, как можно стать специалистом в области

21

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

2) управление проектом, который показывает сферу применения знаний

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

3) управление программой отражает основные понятия и специфику

управления программой;

4) элементы управления, отражающие 11 основных процессов

управления проектами и программами в соответствие с методологией P2M.

Основной акцент в методологии P2M делается на создании ценности в

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

коммерческой, так и некоммерческой. Кроме того, данный стандарт

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

проекта.

К недостаткам стандарта можно отнести сложность практической

реализации из-за большого количества «ментальных» понятий.

1.2.5 Методология SCRUM

В настоящий момент одной из самых распространенных методологий,

используемых в IT сфере, является SCRUM, относящаяся к категории гибких

методологий [88, 102]. Ее особенностью является вовлечение в процесс

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

тайм-менеджмента, что подразумевает постоянную вовлеченность всех, кому

важно успешное завершение проекта. Даже Scrum Master, который играет

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

задачи членам команды. Он постоянно отслеживает прогресс команды

(которая в данном случае является самоорганизующейся и самоуправляемой)

при помощи специальных средств и отмечает статус всех задач в спринте и,

при этом, участвует во всех митингах, создает атмосферу доверия и является,

по сути интерфейсом между менеджментом и командой.

Основной временной единицей методологии является Sprint, который,

как правило, составляет один месяц, по завершении которого команда

должна выдать результат заказчику или, как минимум, быть готовым

22

показать его. Жизненный цикл спринта состоит из планирования спринта,

остановка спринта (в исключительных случаях), Daily Scrum Meeting, т.е.

ежедневное 15-минутное совещание, которое проводится ежедневно для

обмена информацией, и Демо и ревью спринта, где команда демонстрирует

инкремент продукта, созданный за последний спринт.

К достоинствам SCRUM можно отнести ориентированность на клиента

и адаптивность. Упор на самоорганизованность и самоуправляемость

команды позволяет широко использовать ее в небольших компаниях и

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

руководителей. Однако, это же несет в себе и определенный недостаток,

связанный со сложностью и дороговизной первоначального набора

персонала, его мотивацию и обучение.

Еще одним минусом методологии SCRUM является отсутствие плана

коммуникаций и реагирования на риски, что затрудняет работу в резко

меняющихся условиях [102].

1.2.6 Методология Crystal Clear

Методология Crystal Clear относится к группе легковесных гибких

методологий [103]. Она ориентирована на использование в небольших

командах, количество членов которых составляет 4-8 человек, и

специализацией которых является создание некритичных бизнес-

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

Crystal Clear основной упор делает на людей, а не на процессы. Данная

методология использует семь методов (или практик):

1) частая поставка продукта;

2) улучшения через рефлексию;

3) личные коммуникации;

4) чувство безопасности;

5) фокусировка;

6) простой доступ к экспертам;

7) качественное техническое окружение.

23

Первые три практики являются обязательными для реализации. Как

видно, все эти методы являются характерными для Agile методологий, в ходе

реализации которых специалисты обмениваются информацией о состоянии и

достижении целей проекта, а не о соблюдении процедур. Crystal Clear

относится к итеративным методологиям. Длительность итерации

(инкремента) может варьироваться от 1 до 4 месяцев. Важной особенностью

данной методологии является постоянное привлечение пользователей к

активному участию в проекте, что обеспечивает получение быстрой

обратной связи и позволяет ликвидировать недостатки на ранних стадиях.

Кроме того, постоянная настройка методологии позволяет адаптировать ее

для любого проекта и команды.

Достоинствами методологии Crystal Clear является максимальная

простота использования с минимальными усилиями и затратами на

внедрение. Кроме того, считается, что она описывает естественный порядок

разработки ПО.

К недостаткам следует отнести отсутствие глубокого управления

содержанием, сроками, стоимостью, качеством, рисками, что скажется на

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

ответственным проектом, сложность в предвидении того, какие

промежуточные продукты необходимы для достижения итоговой цели [104].

1.3 Анализ существующих методов и рекомендаций к выбору

методологий

Существование обширного числа методологий и стандартов,

значительные различия в технологии их применении и в квалификации

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

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

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

а некоторых случаях – даже судьбоносной. Именно поэтому эта проблема

24

волнует многих ученых и подталкивает их к разработке различных подходов

для ее решения.

Алистэр Коуберн в статье [54] предложил подход к группировке

методологий. Он схематично разделил прямоугольник на ячейки по

количеству людей, занятых в проекте (размер проекта), и на зоны

критичности (рис.1.1).

Рисунок 1.1 – Методологии, организованные по принципу люди х

критичность

Каждой ячейке схемы может одновременно соответствовать несколько

различных методологий.

Выбор конкретной методологии зависит от предпочтений спонсоров

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

обозримость, повторяемость и корректность процесса. "Размер" методологии

увеличивается при увеличении количества людей, что связано с увеличением

количества элементов, между которыми осуществляются коммуникации.

"Плотность" методологии растет при приближении к верхней части

25

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

правому верхнему углу увеличивается стоимость проекта. Для уменьшения

стоимости проекта следует стремится к левому нижнему углу

прямоугольника [54].

В работах [105,106] предложен метод балансировки жестких плановых

методологий и Agile методологий при управлении конкретным проектом в

предполагаемой среде. Существо метода аккумулируется в следующих

шагах.

Шаг 1. Оцениваются риски, связанные с осуществлением проекта с

помощью плановой и Agile методологии в конкретных условиях среды.

Шаг 2. Если риски, связанные с применением Agile методологии,

доминируют над рисками, присущими плановой методологии, то

применяется последняя.

Шаг 3. Если риски, связанные с применением плановой методологии,

доминируют над рисками, присущими Agile методологии, то применяется

Agile методология.

Шаг 4. Если одни компоненты проекта удовлетворяют шагу 2, а другие

– шагу 3, для выделенных компонентов применяются наиболее адекватные

методологии.

Шаг 5. Планируется осуществление проекта.

Шаг 6. Проводится мониторинг осуществления проекта, оценивают

риски и возможности, переделывают балансировку, если это необходимо.

В работе [107] на основании анализа литературы выделены факторы,

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

разработке программного обеспечения, ориентированной на жесткий

плановый подход (PRINCE2, PMBOK) или на адаптивный Agile подход. В

работе также был сделан опрос 127 специалистов в области управления

проектами из 22-х стран. Из общего числа опрошенных 26% были

специалистами по применению PRINCE2, 28% - по использованию PMBOK

и 30% - по Agile. Наименьший среди проектов, на который указывали

26

респонденты, имел стоимость 2500 USD и трудоемкость 2 человеко-месяца, а

наибольший проект стоил 840 млн USD и имел трудоемкость 1260 человеко-

лет. Цель опроса специалистов состояла в выявлении факторов в проекте и в

его окружении, которые бы давали основания для применения Agile подхода

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

В результате опроса был сформирован список проранжированных факторов.

Низкие значения этих факторов указывают на плановый подход к

управлению проектом, высокие значения – на Agile подход. Для четырех

групп переменных, которые характеризуют проектную среду, проект, Agility

и успех проекта был проведен факторный анализ. Результатом работы стало

выделение 8 важнейших факторов.

В работе [108] проведен опрос специалистов о выполнении 112

проектов в области создания программных продуктов 63-мя организациями

Греции. Результаты были проанализированы с помощью структурных

уравнений с целью исследования влияния качества персонала и качества

процессов на риски проектов по созданию программных продуктов. В работе

рассматривалось 6 факторов риска в подобных проектах, а именно

пользователь, требования, сложность проекта, планирование и контроль,

команда проекта, окружение организации. Общее качество проекта

измерялось с помощью двух факторов: качество процессов и качество

персонала. Анализ показал, что существует отрицательная статистически

значимая связь между качеством проекта и рисками. Аналогичная по знаку

связь существует между качеством персонала и пятью из шести показателей

риска (кроме сложности проекта). Также значимая отрицательная связь

имеет место между качеством процессов и одним фактором риска – команда

проекта.

В работе [109] изучен вопрос перехода организации, занимающейся

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

управления проектами. На примере пяти организаций из Ирландии

рассмотрены причины перехода от собственных методологий управления

27

проектами к международно признанным, а также причины внедрения таких

методологий в ситуации, когда методологии управления проектами в

организации вообще не применялись. В одной организации (самой малой по

численности) методологию выбирали по рекомендации коллег и остановили

свой выбор на PMBoK. Во втором случае выбор был также сделан по

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

методологии под нужды организации. Предпочтение было отдано PRINCE 2.

В третьей организации методологию выбирали исходя из рекомендаций

CMMI с тем, чтобы в дальнейшем пройти сертификацию по этой системе.

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

структуры из США, которая ценит возможность получения сертификата PMI.

Неудивительно, что в итоге приняли для внедрения методологию PMBOK. В

четвертой организации, которая насчитывает около 2500 сотрудников, выбор

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

такая задача. При принятии решения принималась во внимание возможность

адаптации методологии к требованиям организации. В результате пошли по

пути подстройки PMBoK. Наконец, в пятом случае главным при выборе

методологии рассматривали требование наличия множества структур,

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

предоставляют поддержку при внедрении конкретной методологии. Кроме

того, учитывалось то, какая методология используется в «родительской»

организации и возможность адаптации методологии. В результате выбор был

сделан в пользу PRINCE 2.

В работе [110] автором были разработаны модели и механизмы

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

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

компетентности персонала. Автором была предложена геномная модель

организации знаний о методологии управления проектами, программами и

портфелями проектов.

28

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

работа [111]. В ней даны общие рекомендации по выбору среди водопадных,

спиралеподобных и адаптивных методологий, приведены их характеристики.

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

лучшей методологии. В статье [112] также приведен подход к выбору

методологий, рекомендательного содержания, состоящий из шести этапов. В

основу данного подхода положено экспертное оценивание факторов проекта

и окружения и рекомендации по применению predictive или adaptive

методологий. Работа [112] также не позволяет сделать обоснованный выбор

лучшей методологии с достаточной точностью.

В работе [113] утверждается, что для конкретного проекта необходимо

создавать специальную методологию. Это позволит повысить эффективность

управления. Однако подбор методологии для проекта из числа уже

существующих имеет свои преимущества – такая методология доступна и

хорошо описана, тогда как синтез специальной методологии является

сложным, дорогим и длительным процессом.

В работе [114] описаны этапы работ по внедрению методологии

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

возможных формально не представлен.

1.4 Анализ моделей и методов многокритериальной оптимизации

содержания проектов

Данная работа посвящена применению моделей, методов и средств

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

В этой связи большое значение имеют достижения в области

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

Одной из важнейших задач при разработке содержания любого проекта

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

стоимостью. Взаимосвязь этих характеристик достаточно очевидна и может

29

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

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

Причем каждый конкретный случай характеризуется соответствующими

показателями длительности выполнения работ и затратами финансовых

средств на их выполнение. Обе эти характеристики зависят от количества и

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

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

увеличению стоимости выполнения работ. Это происходит в том случае,

когда такого сокращения добиваются путем привлечения большего

количества трудовых ресурсов, либо повышения их квалификации. Однако

это не однозначно и существуют случаи, когда более длительное выполнение

работ является и более дорогим. Это, как правило, наблюдается в тех

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

организации с почасовой оплатой труда. Кроме того, различные стоимости

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

реализуется проект, страны реализации и т.д. Как показывает практика,

наиболее реальной является дискретная связь между длительностью

выполнения работ и их стоимостью.

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

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

стоимостью. Так например, в работах [115] и [116] рассматривается

непрерывная зависимость между этими показателями и предлагается решать

задачи минимизации стоимости проекта [115] и минимизации сроков

проекта [116] методами линейного программирования. Следует отметить, что

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

делает результаты решения практически не применимыми на практике.

В работах [117] и [118] предлагается использовать для решения задачи

метод ветвей и границ при учете ограничений на ресурсы и на

последовательность выполнения задач.

30

В работе [119] в качестве исходных данных используется уже

дискретное множество вариантов стоимости и времени выполнения работ.

Для нахождения оптимального варианта предлагается использовать

математическую модель целочисленного программирования. Отличительной

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

затрат на выполнение работ.

В статье [120] представлен алгоритм, использующий линейное и

целочисленное программирование для эффективного получения

оптимальной выборки ресурсов с целью оптимизации времени и стоимости

реализации проекта.

В работе [121] рассмотрены задачи минимизации общих затрат на

проект при фиксированном сроке и минимизации сроков проекта при

ограничениях на бюджет. Предложены модели смешанного целочисленного

программирования.

Сложность решения подобных задач связана с тем, что для проектов, в

которых присутствует большое количество работ, задача приобретает

огромную размерность и ее решение методами математического

программирования становится неэффективным с вычислительной точки

зрения [122]. Авторы в работе [123] показывают, что такие задачи относятся

к особо сложным комбинаторным задачам. Ими предложен метод поиска

компромисса между временем и стоимостью, который относится к линейным

целочисленным методам. Он учитывает обобщенные отношения

предшествования работ, штрафы за задержку и бонусы за преждевременное

завершение проекта, а также ограничения по времени. Аналогичная задача

решается приближенным методом [124], что существенно ускоряет процесс

В работе [125] для минимизации сроков реализации проекта

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

особенностью является то, что для получения оптимального решения

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

31

По мнению авторов работ [125, 126] более эффективно для

оптимизации сроков и стоимости проектов использование динамического

программирования, чем линейного или нелинейного. К недостаткам

предложенного подхода следует отнести то, что не всегда удается находить

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

решение.

Одним из направлений решения рассматриваемых задач является

применение генетического алгоритма [127]. По сравнению со строгими

методами этот подход имеет значительно большую вычислительную

эффективность. С помощью генетического алгоритма автору работы [127]

удалось найти оптимальные решения для 90-95% задач.

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

генетического алгоритма с другими методами. Так, в работе [128]

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

строить непрерывные кривые время-стоимость. В работе [129] авторы

объединили генетический алгоритм с моделью, в которой осуществляется

выравнивание ресурсов с учетом ограничений на них. В исследовании [130]

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

случайный характер данных.

Авторы работы [131] реализовали в Microsoft Project

модифицированный подход, в котором применили вместо фиксированных

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

Для решения задачи оптимизации содержания проектов большой

размерности применяют декомпозицию исходной задачи на несколько задач

меньшей размерности. Такой подход предложен в работе [132], где для

каждой частной задачи находят оптимальное расписание и затем формируют

общее расписание. Полученное решение не обязательно является

оптимальным.

Аналогичный подход предложен в работах [133, 134, 87], где также

разбивают исходную сеть на подсети. В работах [134, 135] для каждой из

32

непересекающихся подсетей формируется зависимость между временем и

стоимостью.

Для упрощения решения задачи с помощью алгоритма динамического

программирования в работе [125] применяют декомпозицию на

последовательности одномерных оптимизационных задач.

Особую группу составляют эвристические методы решения задачи

оптимизации времени и сроков проекта [136], к которым относится и

структурный метод [137].

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

требуемого значения при наименьших затратах. В работе [138] предложен

повторяющийся процесс поиска операции, находящейся на критическом

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

других. Алгоритм является приближенным. Точный алгоритм, основанный

на исследовании путей в сети, у которых продолжительность превышает

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

В работе [139] поиск оптимума для рассматриваемых критериев

осуществляется с учетом неопределенностей, которые содержатся в

зависимостях время-стоимость. Вероятностный подход к проблеме

уменьшения времени проекта предложен в работе [140]. В ней с помощью

модели линейного программирования с ограничениями минимизируется

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

Методы нелинейного и в некоторых случаях выпуклого

программирования применены в работе [141] для минимизации

продолжительности работ, представленных в виде сетевой модели.

Особняком в области моделирования и оптимизации сетевых моделей

проектов стоят разработки, проводимые под руководством В.И. Воропаева.

Они развивают идею так называемых циклических альтернативных сетевых

моделей (ЦАСМ) 99. Они объединяют в себе обобщенные сетевые модели

[52, 142] с вероятностными [143] и стохастическими [144]. Такой подход

33

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

управлению проектами.

ЦАСМ позволяют решать задачи минимизации времени выполнения

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

при заданном времени, а также формирования плана минимальной

стоимости.

С.К. Черновым разработан адаптированный подход, предназначенный

для создания математического обеспечения планирования и управления

проектами, и реализованный в системе автоматизированного планирования и

управления мелкосерийным производством [145]. Подход основан на

решении ряда взаимосвязанных оптимизационных задач. Вначале

формируются последовательности выполнения отдельных работ или их

групп в календарном плане. Это осуществляется минимизацией суммарного

взвешенного момента их завершения. Это позволяет повысить качество

сформированных расписаний. Одновременно с этим разрабатываются

системы взаимосвязанных алгоритмов, решение которых позволяет

согласованно планировать и управлять проектом по критериям, которые

обеспечивают достижение целей проекта и учитывают ограничения на

ресурсы, сроки и требуемое качество.

Отдельно задача минимизации времени выполнения проекта решается

в работе [146]. В ней предполагается, что любой проект можно представить в

виде последовательности этапов, каждый из которых представляется сетевой

моделью. Кроме того, каждая совокупность работ может иметь

альтернативные варианты выполнения. В качестве ограничений используется

отсутствие финансовой задолженности после завершения каждого этапа.

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

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

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

[147].

34

Во многих случаях минимизация стоимости реализации проекта

является более приоритетной, чем сроки его выполнения [148, 149]. В этих

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

недопущение финансовой задолженности после окончания каждого этапа.

Как и предыдущая, данная модель относится к динамическим с

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

помимо аналитических, присутствуют и алгоритмические ограничения.

Решение такой задачи основывается, как и в предыдущем случае, на методе

неявного перебора.

Для решения задачи оптимизации выполнения работ проекта по

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

обеспечение. Так, в работе [150] описано программное обеспечение «Project

Optimum», которое позволяет определить оптимальную комбинацию

альтернативных вариантов выполнения работ по критериям времени или

стоимости проекта. Кроме того, это программное обеспечение позволят

построить диаграмму Гантта для более наглядного представления расписания

работ по проекту.

Минимаксный подход к решению задачи оптимизации содержания

проекта в двухкритериальной постановке когда известны альтернативные

варианты выполнения работ сформулирован и предложен в статье [149].

В работе [151] были предложены модель и метод двухкритериальной

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

моделей альтернативные варианты выполнения работ. В качестве критериев

рассматривались время и стоимость. Предложенная модель учитывала

ограничения на качество продуктов отдельных этапов.

В диссертационной работе [152] этот метод получил свое развитие и

была разработана математическая модель оптимизации содержания проекта

по пяти критериям - прибыль, время, стоимость, качество, риски и

содержащая нечеткие параметры как в целевых функциях, так и в

ограничениях. Создан метод оптимизации содержания по этим критериям,

35

позволяющий использовать исходные данные в виде нечетких чисел, что

дает возможность учитывать изменения и неопределенность внешней среды.

Реализован данный алгоритм в разработанной программе «PTCQR Project

Scope Optimization».

Среди работ последних пяти лет следует отметить статью [153], в

которой рассматривается дискретная задача поиска компромисса между

временем, стоимостью проекта и его влиянием на окружающую среду.

Задача решается для крупномасштабных строительных систем с множеством

способов действий и с учетом нечеткости данных. Общая длительность

проекта рассматривается как нечеткая переменная. Целевыми функциями

задачи являются общая стоимость проекта, его продолжительность, crashing

стоимость и влияние на окружающую среду. Для поиска эффективных

решений задачи предложен адаптивный гибридный генетический алгоритм.

Представлены результаты анализа чувствительности полученных решений.

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

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

позволяющих эффективно управлять как небольшими проектами, так и

крупными, длительными проектами, программами и портфелями проектов.

Такие системы позволяют автоматизировать такие процессы, как построение

диаграммы Гантта, расчет критического пути, составление бюджета проекта,

анализ рисков, мониторинг и анализ выполнения работ [154, 155]. Все эти

функции в современных системах реализованы в OnLine режиме, что

позволяет отслеживать ход выполнения проекта постоянно и с любого

мобильного устройства.

Наиболее распространенным приложением является программа

Microsoft Project. Она позволяет достаточно эффективно управлять как мега,

так и небольшими по размерам и срокам реализации проектами. В версии

2013 года реализована очень удобная и функциональная система отчетности,

которая делает ее, несомненно, одной из самых удобных и востребованных

систем.

36

Программное решение Primavera P6 позволяет существенно увеличить

эффективность управления проектом за счет автоматизации планирования и

мониторинга реализации проектов и работ проекта, управления ресурсами и

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

строительстве, промышленности, IT и телекоммуникациях, т.к. позволяет

сократить сроки на планирование и формирование балансов требуемых

ресурсов.

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

крупных проектов Open Plan является наличие мощных средств ресурсного и

стоимостного планирования, эффективная организация

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

решения для всего предприятия, независимо от его размеров.

Пакет Spider Project, в отличие от своих конкурентов, использует

мощные алгоритмы планирования использования ограниченных ресурсов,

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

принимать менеджеру обоснованные и проверенные решения, что, в свою

очередь, ведет к более быстрой и качественной реализации проектов.

Для реализации портфелей проектов одним из наиболее мощных

продуктов является система Time Line. В ней реализована концепция

многопроектного планирования в рамках организации, а также гибкие

средства формирования отчетов. Это позволило реализовать мощные

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

прописывать специфические календарные графики работы. К недостаткам

можно отнести слабое развитие данной системы.

Для управления небольшими и малыми проектами разрабатывается все

больше мобильных и онлайн приложений и сервисов. Они позволяют

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

работу и отслеживать результаты в реальном времени. К таким системам

относятся Basecamp, Trello, Мегаплан, Worksection. Однако к недостаткам

таких систем можно отнести строго ограниченный набор услуг, громоздкость

37

и сложность настройки под требования конкретного клиента. Кроме того, все

эти приложения в большей степени можно назвать органайзерами, нежели

инструментами поддержки принятия решений.

1.5 Анализ существующих методов проверки устойчивости

решений

Решения, получаемые с помощью того или иного метода оптимизации

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

Исходная информация для данной задачи всегда содержит значительную

степень неопределенности, поэтому получаемые решения должны

анализироваться с точки зрения их устойчивости к изменению исходных

данных.

В работах [156–157] предлагается найти количественные оценки,

характеризующие меру устойчивости оптимальных решений. Основой

рассматриваемого подхода является понятие радиуса устойчивости, под

которым авторы понимают предельный уровень возмущений параметров

задачи, сохраняющих некоторые свойства оптимальных решений. Авторы

работ [158-159] фокусируются на поиске и описании области устойчивости

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

работе [160] рассматривается модель функционирования организации и ее

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

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

организации; ко второму – устойчивость относительно цели при изменении

плана развития организации. Далее предлагаются методики вычисления

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

организации, для первого и второго вида устойчивости. В работе [161]

представлен наиболее полный обзор существующих исследований в теории

устойчивости.

38

1.6 Цель и задачи исследования

В рассмотренных работах показано, что в настоящее время существует

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

эффективно управлять как отдельными проектами, так программами и

портфелями. Большинство из них являются универсальными и могут

применяться в различных отраслях экономики.

В настоящее время все больше методологий разрабатывается для

управления проектами в ИT сфере. Такие методологии более мобильные и

позволяют лучше адаптироваться к соответствующим условиям и

конкретным проектам. Это, так называемые, Agile методологии. Однако

использование при управлении проектами по разработке программного

обеспечения жестких, плановых методологий, таких как PMBОK, PRINCE2 и

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

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

применение. К таковым относятся: PMBOK, PRINCE2, SWEBOK, P2M,

SCRUM, Crystal Clear.

В литературе рассматриваются различные подходы для выбора той или

иной методологии для управления конкретным проектом. Для выбора

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

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

равно не дает возможности однозначно выбрать методологию, отвечающую

потребностям конкретного проекта. Выбор происходит на эвристическом

уровне и, в большинстве случаев, зависит от предпочтений менеджера или

спонсора, их опыта работы [2]. Как правило, исследование лежит в плоскости

сравнения эффективности использования жестких плановых методологий с

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

различных стандартов управления в уже существующих организациях и

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

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

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

39

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

методологиями.

Выбор методологии не всегда может быть осуществлен каким либо

одним методом, так как команды проектов могут иметь различную степень

осведомленности о существующих методологиях. Метод выбора должен это

учитывать. Таким образом, необходимо иметь ряд методов выбора

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

команды проекта и знание ею альтернативных методологий.

Необходимо создать метод который был бы основан на опросе

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

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

быть даны рекомендации о применении наиболее целесообразных

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

спонсор и команда проекта недостаточно хорошо знакомы с

альтернативными методологиями.

Многие специалисты отмечают, что наиболее важными критериями,

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

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

выполнения проекта или его фазы, а также риски, которые могут возникнуть

в результате управления проектом при помощи данной методологии. Но в

большинстве работ эти критерии рассматриваются обособленно и не

предложен подход, который сводил бы выбор к решению трехкритериальной

задачи.

Для обоснованного выбора методологии в случае, когда спонсор и

команда проекта знакомы с наиболее эффективными методологиями

управления в рассматриваемой отрасли, следует предложить метод,

основанный на оценивании трудоемкости применения той или иной

методологии, затрат на нее и рисков с ней связанных.

Проведенный анализ показывает, что еще одним фактором, который

существенно влияет на качество процесса управления, является содержание

40

проекта. Под содержанием проекта будем понимать работы, которые

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

заданными свойствами и функциями [72].

Применение различных методологий требует соответствующего

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

свою очередь, влияет на ключевые показатели проекта, оценка которых

может быть использована лицом, принимающим решение, для

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

Все большее распространение получают модели, дающие возможность

находить компромисс между содержанием, временем, стоимостью и другими

ключевыми показателями проекта. Это позволяет решать большое

количество задач, в частности, выбирать оптимальное содержание при

ограничениях на время и стоимость. Для решения таких задач существуют

достаточно эффективные алгоритмы. Они основаны на сочетании минимакса

и неявного перебора.

Сходный подход возможно применить и для выбора методологии, т.е.

сравнить результаты выполнения содержания, соответствующего каждой

методологии, выраженные в прибыли, которую может принести проект, в

стоимости проекта, времени его реализации, обобщенном показателе

качества продукта проекта, рисках.

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

проектом по сравнению с применением альтернативных методологий.

Согласно ДСТУ ISO – 9000:2007 [162] , качество – это степень, в

которой совокупность собственных характеристик удовлетворяет

требованиям.

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

которой совокупность характеристик управления соответствует

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

рассматриваться трудоемкость управления проектом, затраты на управление,

риски, связанные с применением определенной методологии управления.

41

Качество проекта в целом, который содержит процессы создания

продукта и процессы управления, может оцениваться такими критериями:

экономический эффект, время, стоимость, качество продукта проекта, риски,

связанные с его осуществлением, технологический, социально-политический,

экологический эффекты, в некоторых случаях – военный эффект.

Исходя из вышеизложенного, целью диссертационного исследования

является повышение качества управления проектами путем выбора

рациональной методологии управления.

Для достижения поставленной цели необходимо решить следующие

научные и практические задачи:

- разработать метод выбора методологии управления проектом,

основанный на опросе экспертов, менеджеров проектов и спонсоров,

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

окружения;

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

критериев трудоемкости, стоимости и рисков применения той или иной

методологии;

- разработать метод выбора методологии, основанный на методе

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

методологий и выборе оптимальной;

- создать программное обеспечение для автоматизации расчетов,

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

многокритериальной оптимизации содержания проекта;

- решить задачу выбора методологии управления для проекта в

области ИТ;

- оценить устойчивость полученных результатов к изменению

исходных данных;

- внедрить результаты работы в практику управления реальными

проектами.

42

Выводы к разделу 1

Результатом исследования, которое было проведено в первом разделе,

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

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

следующие выводы.

1. В настоящее время существует большое количество методологий

управления проектами, которые классифицируются по различным признакам

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

конкретных условиях.

2. К широко используемым методологиям и стандартам управления

проектами относятся следующие: PMBoK, PRINCE2, SWEBOK, P2M,

SCRUM, Crystal Clear. Все они имеют свои достоинства и недостатки.

3. Выявлено, что в большинстве подходов к подбору методологии для

управления конкретным проектом выбор осуществляется на основе опросов,

которые не носят структурированный характер, или на основе

приверженности или знания менеджером определенной методологии. В

большинстве случаев выбор осуществляется между двумя классами

методологий – плановыми и адаптивными, а не между конкретными

методологиями.

4. Применение расчетных методов для поиска оптимальной

методологии в прямом виде в известной литературе не представлено. Однако

выявлен ряд достаточно эффективных подходов поиска компромисса между

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

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

конкретных условиях.

5. Выявлено, что к показателям, которые характеризуют качество

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

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

также риски.

43

6. Следующим шагом в развитии выбора той или иной методологии

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

поиска рациональной методологии, основанных на применении

оптимизационных задач по показателям, которые наиболее полно

характеризуют качество управления.

7. Основные результаты раздела опубликованы в работах [2,7,10 11].

44

РАЗДЕЛ 2

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

ОБЛАСТИ СОЗДАНИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

2.1 Главные особенности предложенных методов выбора

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

Предложены методы выбора методологии для управления проектом в

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

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

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

управлению проектами. Как правило, менеджер и команда проекта владеют в

достаточной степени одной или двумя методологиями. Знания об остальных

являются поверхностными. Если при управлении конкретным проектом у

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

методологий, то целесообразно воспользоваться имеющимися

рекомендациями экспертов по их применению в конкретных практических

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

ситуации. В дальнейшем в работе под термином «команда проекта» для

сокращения мы будем понимать всех участвующих в инициировании,

планировании и выполнении работ по проекту. В это число будем включать

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

команды.

Второй метод предназначен для использования, когда команда проекта

в достаточной степени владеет альтернативными методологиями и

стандартами по управлению проектами, имеет средства и время для

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

помощью конкретной методологии, а также для оценивания рисков с этим

связанных.

В основе третьего метода выбора методологии лежит задача

оптимизации содержания проекта. При решении задачи выбора содержания

45

проекта важным фактором является то, какая методология будет

применяться для управления этим проектом. Применяемая методология

управления проектом сказывается на времени его осуществления, на

стоимости, на качестве продуктов этапов и всего проекта в целом, на рисках

ему сопутствующих. Использование той или иной методологии управления

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

технологическом, экологическом и даже социально-политическом эффекте

от продукта проекта. Решая задачу оптимизации содержания проекта для

альтернативных методологий, можно сделать более обоснованный ее выбор,

нежели при выборе методологии в отрыве от оптимизации содержании

проекта. В данной работе предлагается делать выбор методологии в

результате решения задачи оптимизации содержания проекта по критериям

экономический эффект (прибыль), сроки, стоимость, качество, риски,

технологический, экологический, социально-политический эффекты.

В случаях, когда это допустимо с точки зрения трудоемкости

исследования, данную оптимизацию можно выполнить для всех

рассматриваемых методологий и обойтись без оптимизации по критериям

трудоемкость, стоимость, риски проекта, описанной выше.

Для сокращения сложности исследования целесообразно сделать

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

помощью предыдущего, второго, метода. Когда список методологий сужен,

можно осуществить оптимизацию содержания проекта при условии

применения каждой из оставленных методологий.

2.2 Метод выбора методологии управления проектом на основе

существующих рекомендаций экспертов

Метод предполагает заполнение разработанной анкеты лицом,

принимающим решение, например менеджером проекта. Анкета состоит из

двух частей. Первая часть позволяет отразить краткое резюме проекта

(табл.2.1.) Вторая содержит вопросы в закрытой форме (табл. 2.2 – табл. 2.6).

46

Существует ряд мнений [54,69,70], высказанных специалистами на

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

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

характеристиках:

- жизненный цикл проекта, который может соответствовать либо

каскадной модели, либо итеративной модели. Уже в пределах жизненного

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

менеджера, команды проекта;

- стоимость проекта;

- количество людей, задействованных в проекте, и виды коммуникаций

между участниками команды проекта;

- критичность разрабатываемого продукта проекта по отношению к

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

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

- критичность проекта к задержкам во времени и превышению

стоимости.

Перечисленные выше характеристики и были приняты за основу при

разработке вопросов анкеты. Однако перечень сфер, в которых

сосредоточены вопросы, и сам перечень вопросов существенно расширены.

Предлагаемые вопросы анкеты охватывают сферу формирования команды

проекта, уровень ее компетентности, выбор средств коммуникации и форм

отчетности, а также уровень ответственности менеджера проекта, перечень

возможных рисков и последствий при неудовлетворительном завершении

проекта. Ответы на вопросы соответствуют баллам по шкале от 1 до 4 в

зависимости от необходимой степени детализации работ при управлении

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

выполнения проекта. Чем ниже конечный балл по анкете или тематическим

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

подходящая методология. Набранному среднему баллу соответствуют

47

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

данного проекта.

Таким образом после того, как анкета заполнена следует определить

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

вопросов, на которые даны ответы. В зависимости от итогового значения

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

соответствующим набором элементов управления.

В настоящее время известны десятки методологий, которые, в

принципе, можно применять для управления проектом в области ИТ. В

данном исследовании мы ограничились четырьмя «тяжелыми» или

«прогнозными» методологиями: PMBoK, PRINCE2, Р2М, SWEBOK и двумя

гибкими – SCRUM, Crystal Clear. Указанные, широко распространенные

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

быть дополнен любой существующей методологией.

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

Вопросы Ответы

Название проекта Приведите название проекта

Суть проекта Основная стратегическая цель проекта.

Краткое описание инновации/проекта

Тип проекта

Выберете из: НИОКР, создание нового продукта

(технологии, услуги), создание нового

производства.

Продукт проекта Краткое описание создаваемого товара, услуги,

технологии, инновации в проекте

Для лучшей наглядности вопросы разбиты на семантически-связанные

блоки. Ответственность за заполнение блоков лежит на заказчике, менеджере

проекта и сторонних экспертах.

В таблицах 2.2 и 2.3, представлен блок вопросов, связанных с опытом

работы заказчика с командой проекта и ее компетентностью в реализации

конкретного проекта.

48

Таблица 2.2 – Опыт работы заказчика с командой проекта

Таблица 2.2 отражает зависимость необходимого уровня детализации

процессов управления проектом от опыта работы заказчика с конкретной

командой. Данная зависимость на качественном уровне показана на рисунке

2.1. Под уровнем детализации процессов управления проектом будем

понимать количество типов процессов, которые применяются для данного

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

Вид данной функции объясняется тем, что при увеличении опыта

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

детализации процессов снижается.

Рисунок 2.1 – Зависимость необходимого уровня детализации процессов

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

Вопросы анкеты Варианты ответов Баллы Рекомендуемая

методология

1 2 3 4

Опыт работы заказчика

с данной командой

проекта

Никогда не работал с командой 1 PMBoK,

PRINCE2,

SWEBOK

Есть опыт работы с некоторыми

участниками команды

2 PMBoK,

PRINCE2,

SWEBOK, Р2М

Сотрудничал с менеджером

команды

3 SCRUM, Р2М

Один или более совместных

проектов со всем составом

команды

4 SCRUM, Crystal

Clear

49

Таблица 2.3 – Оценка компетентности команды проекта менеджером

проекта

Вопросы анкеты Варианты ответов Баллы Рекомендуемая

методология

1 2 3 4

Опыт работы в

данной отрасли

Нет опыта работы в отрасли

1

PMBoK,

PRINCE2,

SWEBOK

Есть опыт работы в отрасли до 2 лет

2

PMBoK,

PRINCE2,

SWEBOK, Р2М,

SCRUM*

Есть опыт работы в отрасли от 2 до

5 лет 3 Р2М, SCRUM

Есть опыт работы в отрасли более 5

лет 4

SCRUM, Crystal

Clear

Понимание

требований, умение

адаптироваться и

проявлять

инициативу

Плохо ориентируются в

требованиях, требуют частых

разъяснений и постоянного

контроля

1

PMBoK,

PRINCE2,

SWEBOK

Понимают выставленные

требования, могут им следовать, но

требуют регулярного контроля

2

PMBoK,

PRINCE2,

SWEBOK

Понимают выставленные

требования, могут им следовать, не

требуя регулярного контроля

3 Р2М, SCRUM

Хорошо ориентируются в

требованиях, могут следовать им,

не требуя регулярного контроля,

могут предложить лучшие

альтернативы

4 SCRUM, Crystal

Clear

Опыт совместной

работы

Никогда не работали вместе

1

PMBoK,

PRINCE2,

SWEBOK

Работали над созданием продукта,

но в другой области 2

PMBoK,

PRINCE2,

SWEBOK, Р2М*

Работали вместе над созданием

одного продукта в интересующей

отрасли

3 Р2М, SCRUM,

Работали вместе над созданием

нескольких продуктов в

интересующей отрасли

4 SCRUM, Crystal

Clear

Знание

используемых

инструментов и

методов

Инструменты и методы,

используемые в проекте, никогда

раньше не применялись и

неизвестны команде

1

PMBoK,

PRINCE2,

SWEBOK,

Инструменты и методы,

используемые в проекте, известны

команде, но никогда раньше не

2

PMBoK,

PRINCE2,

SWEBOK, Р2М*,

50

Окончание таблицы 2.3

1 2 3 4

применялись SCRUM*,

Инструменты и методы, используемые в

проекте, известны команде, но

применяются редко

3 SCRUM, Р2М*

Инструменты и методы известны

команде и широко применялись в

прошлом

4 SCRUM, Crystal

Clear

Обучаемость Тяжело осваивают новые знания и

технологии, плохо адаптируются к

изменениям

1

PMBoK,

PRINCE2,

SWEBOK

Некоторым членам команды сложно

освоить новые знания и технологии, но

команда умеет адаптироваться к

изменениям

2

PMBoK,

PRINCE2,

SWEBOK, Р2М*

Легко обучаемы, умеют адаптироваться к

изменениями 3

Р2М, SCRUM,

Crystal Clear

Легко обучаемы, всегда стремятся узнать

что-то новое, хорошо адаптируются к

изменениям.

4 SCRUM, Crystal

Clear

Четкость и прямота

в высказываниях

Не умеют четко формулировать свои

идеи и редко их высказывают 1

PMBoK,

PRINCE2,

SWEBOK

Умеют четко формулировать идеи, но

редко высказывают свое мнение 2

PMBoK,

PRINCE2,

SWEBOK, Р2М*

Умеют четко формулировать идеи, могут

прямо высказать свое мнение 3 Р2М, SCRUM

Умеют четко формулировать идеи, не

боятся высказывать свое мнение и могут

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

4 SCRUM, Crystal

Clear

Умение признавать

свои ошибки

Не признают открыто свои ошибки и не

умеют извлекать из них опыт 1

PMBoK,

PRINCE2,

SWEBOK

Редко открыто признают свои ошибки, но

стараются их не повторять 2

PMBoK,

PRINCE2,

SWEBOK, Р2М*,

Открыто признают свои ошибки, и

стараются их не повторять 3

Р2М, SCRUM,

Crystal Clear

Всегда признают свои ошибки и умеют

извлекать из них опыт 4 SCRUM

Знаком «*» отмечены случаи, когда методология не полностью

отвечает ситуации, но ее использование возможно.

Таблица 2.3 базируется на качественной зависимости необходимого

уровня детализации процессов управления проектом от опыта команды

проекта, графически представленной на рисунке 2.2. Вид данной

51

зависимости аналогичен зависимости, показанной на рисунке 2.1, поскольку

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

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

Рисунок 2.2 – Зависимость необходимого уровня детализации процессов

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

Графики, показанные на рисунках 2.1 и 2.2 отражают характер

зависимости, но не определяют конкретные значения факторов. Конкретные

значения уровня детализации определяются экспертами.

Следующий блок вопросов, представленный в таблице 2.4, отражает

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

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

Таблица 2.4 – Отчетность по проекту

Вопросы анкеты Варианты ответов Баллы

Рекомендуемая методология

1 2 3 4

Виды средств коммуникаций

Письменные отчеты. Формальное ведение документации

1 PMBoK, PRINCE2, SWEBOK, Р2М,

Он-лайн общение (ICQ, Skype, E-mail)

2 PRINCE2, SCRUM*

Голосовое общение(телефонная связь, интернет-конференция)

3 SCRUM

Непосредственное общение команды проекта (собрания, видеоконференции)

4 Р2М, SCRUM, Crystal Clear

Частота отчетов перед заказчиком в процессе выполнения проекта

Отчет о каждой операции 1 PMBoK, PRINCE2, SWEBOK,

52

Окончание таблицы 2.4

1 2 3 4

Отчет о выполнении пакета работ 2 PMBoK,

PRINCE2,

SWEBOK, Р2М,

SCRUM, Crystal

Clear

Отчет о получении компонента

продукта проекта

3 SCRUM, Crystal

Clear

Отчет о готовности проекта 4 SCRUM

Имеющееся

представление о

работах проекта

Есть полный список работ по

проекту. Дальнейшее внесение

изменений в проект будет

невозможно

1 PMBoK,

PRINCE2,

SWEBOK,

Есть детальный список работ по

проекту с возможным дополнением

и расширением

2 PMBoK,

PRINCE2,

SWEBOK, Р2М,

Есть приблизительный список

работ по проекту

3 SCRUM, Р2М*

Есть представление о конечной

цели проекта и несколько

альтернатив для путей ее

достижения

4 SCRUM, Crystal

Clear

Отдельно стоит остановиться на вопросе о влиянии способа общения

заказчика, проектного менеджера и команды проекта на требуемый уровень

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

уровне показано на рисунке 2.3. Как видим, при большей формализации

общения уровень детализации возрастает. Диаметр окружностей на рисунке

отражает трудоемкость процесса.

Рисунке 2.3 – Влияние уровня формализации общения на уровень

детализации процессов управления проектом

53

Таблица 2.5 содержит вопросы о критичности разрабатываемого проекта,

и соответственно, ответственности менеджера проекта; о требованиях к

стоимости, качеству и срокам проекта.

Таблица 2.5 – Ответственность менеджера и основные требования к

проекту

Вопросы анкеты Варианты ответов Баллы Рекомендуемая методология

1 2 3 4

Последствия в случае неудовлетворительного завершения проекта

Потеря жизни 1 PMBoK, PRINCE2, SWEBOK

Потеря невосполнимой суммы денег

2 PMBoK, PRINCE2, SWEBOK, Р2М*

Потеря несущественной суммы денег

3 Р2М, SCRUM

Потеря комфорта в работе 4 SCRUM, Crystal Clear

Стоимость проекта

Свыше 1 млн. долл. США 1 PMBoK, PRINCE2, SWEBOK, Р2М*

От 300 тысяч – 1 млн. долл. США

2 PMBoK, PRINCE2, SWEBOK, Р2М,

От 100 – 300 тысяч долл. США 3 SCRUM

Менее 100 тысяч долл. США 4 SCRUM, Crystal Clear

Требования к качеству продукта проекта

Высшие международные требования

1 PMBoK, PRINCE2, SWEBOK,

Международные требования 2 PMBoK, PRINCE2, SWEBOK, P2M

Национальные требования 3 Р2М, SCRUM*, Crystal Clear*

Требования локального рынка 4 SCRUM, Crystal Clear

Требования к срокам реализации проекта

Сроки не лимитируют 1 PMBoK, PRINCE2, SWEBOK, Р2М

Не очень срочно 2 Р2М, SCRUM*, PRINCE2*

Срочно 3 SCRUM, Crystal Clear

Очень срочно 4 SCRUM

Требования к точности

соблюдения сроков

Сроки должны быть точно соблюдены

1 PMBoK, PRINCE2, SWEBOK,

54

Окончание таблицы 2.5

1 2 3 4

Допускается некоторое

отклонение от сроков

2 PMBoK,

PRINCE2,

SWEBOK, Р2М

Допускается значительное

отклонение от сроков

3 SCRUM, Crystal

Clear

Соблюдение сроков не является

важным

4 SCRUM, Crystal

Clear

На рисунке 2.4 показано, что при высоком уровне ответственности

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

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

детализации процессов управления проектом. При увеличении срочности

проекта степень детализации необходимо снижать. Оба графика имеют

насыщение, которое объясняется тем, что фиксированному увеличению

ответственности, требований к качеству, стоимости и времени соответствует

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

управления.

Рисунок 2.4 – Зависимость необходимого уровня детализации процессов

управления проектом от уровня ответственности менеджера проекта,

требований к качеству, стоимости, времени проекта

55

Завершающий блок анкеты, представленный в таблице 2.6, содержит

вопросы, описывающие возможные риски проекта и вероятности появления

рисковых событий.

Таблица 2.6 – Вероятность появления рисковых событий

Вопросы анкеты Варианты ответов Баллы

Рекомендуемая

методология

1 2 3 4

Вероятность

проявления риска,

связанного с

архитектурой объекта,

технологиями и

процессами его

создания, показателями

качества

Рисковое событие наверняка

произойдет ( ≥ 95%)

1 PMBoK,

PRINCE2,

SWEBOK

Рисковое событие, скорее всего,

проявится (75%).

2 PMBoK,

PRINCE2,

SWEBOK, Р2М*

Вероятность проявления

рисковых событий равна 50%

3 Р2М, SCRUM*,

Crystal Clear*

Рисковое событие, скорее всего,

не проявится (10%)

4 SCRUM, Crystal

Clear

Вероятность

проявления внешних

рисков (срыв работ

подрядчиками,

неблагоприятная

политическая,

экономическая

обстановка в стране,

изменения рынка и

т.д.)

Рисковое событие наверняка

реализуется ( ≥ 95%)

1 PMBoK,

PRINCE2,

SWEBOK,

Рисковое событие, скорее всего,

проявится (75%)

2 PMBoK,

PRINCE2,

SWEBOK, Р2М*

Вероятность проявления

рисковых событий равна 50%

3 Р2М, SCRUM,

Crystal Clear*

Рисковое событие, скорее всего,

не проявится (10%)

4 SCRUM, Crystal

Clear

Вероятность

наступления

организационных

рисков (срыв

финансирования, срыв

поставки ресурсов,

неправильная

расстановка

приоритетов и т.д.)

Рисковое событие наверняка

реализуется ( ≥ 95%)

1 PMBoK,

PRINCE2,

SWEBOK,

Рисковое событие, скорее всего,

проявится (75%)

2 PMBoK,

PRINCE2,

SWEBOK, Р2М*,

Вероятность проявления

рисковых событий равна 50%

3 Р2М, SCRUM,

Crystal Clear*

Рисковое событие, скорее всего,

не проявится (10%)

4 SCRUM, Crystal

Clear

Вероятность

наступления рисковых

событий, связанных с

управлением проектом

(некачественное

планирование,

Рисковое событие наверняка

реализуется (95%)

1 PMBoK,

PRINCE2,

SWEBOK

56

Окончание таблицы 2.6

1 2 3 4

Рисковое событие, скорее всего,

проявится (75%)

2 PMBoK,

PRINCE2,

SWEBOK, Р2М*,

Вероятность проявления

рисковых событий равна 50%

3 Р2М, SCRUM,

Crystal Clear*

Рисковое событие, скорее всего,

не проявится (10%)

4 SCRUM, Crystal

Clear

В приведенных таблицах рекомендации относительно методологий

даются на основании мнений экспертов, а также руководствуясь данными,

представленными в самих методологиях. Например, такие методологии как

PMBoK, PRINCE2 и SWEBOK соответствуют одному или двум баллам

ответов на вопросы, т.е. их применение целесообразно при требуемой

высокой степени детализации работ по управлению проектом. Это связано с

тем, что данные методологии очень подробно описаны. В них описаны все

процессы, с которыми столкнутся члены команды проекта. Данные

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

незначительном опыте работы в ней. Также данные методологии

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

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

выполнения проекта. Для команды, которая имеет соответствующий опыт и

знания, приведенные методологий избыточны, требуют обширного

документооборота и могут только мешать работе. Эта особенность отражена

в таблице 2.3. Рассматриваемые методологии предполагают формальную,

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

2.4). Они больше подходят для управления крупными проектами с большим

бюджетом, рекомендуются для проектов с жесткими сроками их завершения

и высокими требованиями к качеству продукта проекта.

Методологии PMBOK, PRINCE2 и SWEBOK рекомендованы для

использования в проектах с высокой вероятностью возникновения

57

различного типа рисков (более 50%), что и отражено в рекомендациях выше

(табл 2.6).

Методология Р2М рекомендована для заказчика, у которого уже есть

опыт работ с некоторыми участниками команды и с менеджером проекта,

потому что методология достаточно сложно описана, и, не имея опыта

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

с ее помощью (табл 2.2). В таблице 2.3 методология Р2М почти всегда

рекомендуется для второго и третьего варианта ответов. Это следует из того,

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

ориентируется в требованиях и тяжело усваивает новые знания, то ей будет

очень трудно разобраться в методологии Р2М и реализовать проект с ее

помощью. Поэтому команда должна иметь опыт работы в рассматриваемой

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

Р2М не рекомендуется для четвертого варианта ответа, потому что если

команда имеет опыт работы в области уже более 5 лет и хорошо

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

гибкие методологии без потери качества продукта проекта.

Р2М предполагает написание письменных отчетов в конце каждого

этапа, формальное ведение документации и непосредственное общение

команды проекта (собрания, видеоконференции) (табл. 2.4). Данная

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

лимитируются строго и результаты проекта не очень критичны (табл. 2.5).

Из таблицы 2.6 видно, что Р2М рекомендуется для второго со

знаком «*» и третьего варианта ответов, где вероятность наступления

рисковых событий равна 50%. Это объясняется тем, что при высокой

вероятности рискового события (более 75%) целесообразно применять очень

детально прописанную методологию управления рисками. Если же

вероятность наступления рисковых событий менее 10%, то возможно

использование легкой и гибкой методологии.

58

Представленные адаптивные методологии SCRUM и Crystal Clear в

большинстве своем рекомендованы для ответов, соответствующих 3-м и 4-м

баллам, так как эти методологии считаются рамочными, их положения

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

Решение вопроса о необходимости, а также полноте применения данных

рекомендаций в большей мере лежит на команде управления проектом.

Поэтому предполагается ее компетентность, сознательность, сработанность,

отсутствие необходимости в постоянных письменных отчетах, отчетах на

промежуточных стадиях. Сроки выполнения проектов при применении таких

методологий сравнительно невелики, а их стоимость не очень значительна,

но и последствия от неудовлетворительного завершения проекта не являются

критическими для компании.

Однако есть между этими методологиями и некоторые отличия. В

Crystal Clear, в отличие от SCRUM, участие заказчика в процессе разработки

менее значительно. В Crystal Clear отсутствуют ежедневные stand up meeting,

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

со стороны заказчика к команде, которое может быть достигнуто опытом

совместной работы. Также в данной методологии, в отличии от SCRUM,

заказчик может вносить изменения в инкремент на этапе его выполнения,

разработка ведется через регрессионное тестирование и практически

полностью отсутствует проектная документация. В этом случае особая

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

они должны быть максимально самоорганизованы и дисциплинированы,

владеть инструментами и методами на высшем уровне, моментально

реагировать на любые изменения в требованиях. Crystal Clear предполагает

работу в малых командах по 4-8 человек на openspace пространстве, что

требует постоянного живого общения и, соответственно, умения четко и

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

неконфликтным и открыто признавать свои ошибки. Все перечисленные

качества соответствуют исключительно высоким профессиональным

59

требованиям к команде и позволяют сделать вывод, что методология Crystal

Clear абсолютно не применима для новичков.

После ответа на вопросы анкеты, на основе полученных рекомендаций

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

методологии. Выбор может быть непростым, если отдельным тематическим

блокам анкеты, согласно выставленным баллам, соответствуют различные

методологии. В этом случае менеджер проекта должен осуществить выбор

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

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

компании для ряда перспективных проектов, то среди возможных проектов

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

для всех типовых перспективных проектов и осуществить выбор, исходя из

приведенных рекомендаций.

2.3 Метод выбора методологии управления проектом с точки зрения

трудозатрат, стоимости управления и сопутствующих рисков

Данный метод предполагает решение трехкритериальной задачи

оптимизации выбора методологии с учетом ограничений. Критериями

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

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

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

методологии.

Метод оценивания трудозатрат и стоимости управления проектом, с

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

состоит из следующих этапов.

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

определить, как происходит управление проектом, какие процессы

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

вовлекаются в процессы управления.

60

2. Составить список задач менеджера проекта по данной методологии.

На этом этапе необходимо учесть все процессы, к которым может быть

привлечен менеджер проекта, как на стадии подготовки, так и на стадии

выполнения проекта.

3. Рассчитать трудозатраты менеджера проекта при управлении

проектом.

4. Определить, к каким процессам управления проектом и в какой

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

составление отчетов или меры по развитию команды проектов почти всегда

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

5. Рассчитать трудозатраты каждого из членов команды проекта на

управление проектом.

6. Определить общие трудозатраты на управление проектом:

m

i

n

j

ji KWPT1 1

; (2.1)

где – трудозатраты менеджера проекта;

– трудозатраты i-го ассистента менеджера проекта. В качестве

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

m – количество ассистентов менеджера проекта;

Kj – трудозатраты j-го члена команды. В данном случае имеются ввиду

члены команды проекта, не входящие в команду управления;

n – количество членов команды проекта.

7. Рассчитать стоимость управления проектом по следующей

формуле:

;11

j

n

j

ji

m

i

i KCWHPML

(2.2)

где – почасовая ставка менеджера проекта;

– почасовая ставка i-го ассистента менеджера проекта ;

– почасовая ставка j-го члена команды.

P

iW

M

iH

jC

61

8. Оценить риски, связанные с управлением проектом с помощью

рассматриваемой методологии.

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

конкретной методологии. Для каждого i-го риска оцениваются вероятность

его наступления pi и уровень последствий от него yi , , где r –

количество выявленных рисков.

Для оценивания вероятности наступления риска можно

воспользоваться следующими градациями вероятностей :

чрезвычайно маловероятно: 0 – 0,25;

маловероятно: 0,26 – 0,50;

достоверно: 0,51 – 0,75;

очень вероятно: 0,76 – 1.

Для определения уровней последствий для проекта, требуется

разработать подробную шкалу влияния рисков на проект. В таблице 2.7

приведен пример такой шкалы, составленный для проекта, описанного в

разделе 3. Данная шкала сделана по аналогии с [72].

Таблица 2.7 - Определение шкалы влияния рисков

Цели проекта

Последствия

Незначительные Умеренные Критические Катастрофические

Содержание

изменения содержания проекта почти незаметны

изменения содержания значительные, но не оказывают

влияния на продукт

проект не полностью

соответствует требованиям заказчика

проект совершенно не соответствует требованиям заказчика

Стоимость увеличение

стоимости < 5%

увеличение стоимости на

5-15%

увеличение стоимости на 15-

40%

увеличение стоимости > 40%

Сроки задержка сдачи проекта до 1

недели

задержка сдачи проекта на 1-3

недели

задержка сдачи проекта на 3-6

недель

задержка сдачи проекта на 6-10

недель

Качество снижение

качества едва заметно

снижение качества не влияет на ключевые элементы проекта

снижение качества имеет значительное влияние на весь

проект; дальнейшая работа над

проектом требует согласования с заказчиком

продукт проекта совершенно не соответствует требованиям по

качеству

62

Каждой градации последствий соответствует определенный уровень

последствий:

незначительные ( уровень 1);

умеренные (уровень 2);

критические (уровень 3);

катастрофические (уровень 4).

Определить общий коэффициент риска:

.1

r

i

ii ypR (2.3)

9. Далее следует проранжировать рассматриваемые методологии с

точки зрения трех критериев: Т, L, R и выбрать лучшую.

В процессе оптимизации могут быть учтены ограничения на стоимость

процессов управления и на их трудоемкость.

2.4 Метод выбора методологии управления проектом на основе

оптимизации содержания проекта

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

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

вся команда проекта. Выполняемый перечень работ определяет ценности

проекта. Все ценности можно свести к следующему перечню: экономический

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

осуществлением, технологический, социально-политический, экологический

эффекты, в некоторых случаях – военный эффект. Для того, чтобы наиболее

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

сравнить ценности, которые будут получены от осуществления проекта при

использовании альтернативных методологий. В результате приходим к

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

его содержания по критериям экономический эффект (в качестве него будет

63

рассматриваться прибыль от осуществления проекта), время, стоимость,

качество продукта проекта, риски, технологический, экологический и

социально-политический эффекты. Военный эффект в данной работе

рассматривать не будем.

Оптимизацию содержания проекта с целью выбора методологии

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

как уже отмечалось, для уменьшения трудоемкости исследования

предварительный выбор небольшого числа методологий рационально

осуществить с помощью более простого из предложенных методов. В

качестве более простых могут быть использованы:

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

существующих рекомендаций экспертов;

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

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

После сокращения количества альтернативных методологий

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

Для решения задачи оптимизации содержания проекта по критериям

экономический эффект (прибыль), сроки, стоимость, качество, риски,

технологический эффект, экологический и социально-политический эффекты

можно использовать метод неявного перебора в сочетании с обобщенным

критерием [163,164] или метод последовательных уступок, описанный

ниже.

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

уступок имеет свои преимущества по сравнению с применением

обобщенного критерия [164]. При этом нет необходимости задавать весовые

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

субъективности. Достаточно только проранжировать критерии с точки

зрения решаемой задачи и определить допустимые уступки.

64

2.5 Математическая модель многокритериальной задачи

оптимизации содержания проекта

Рассматриваемые проекты состоят из следующих фаз жизненного

цикла:

прединвестиционная;

инвестиционная;

производства, реализации и поддержки продукции

На прединвестиционной фазе генерируется идея проекта,

разрабатывается его бизнес план, осуществляется поиск инвестиций. На

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

проходит тестирование и апробацию путем решения реальной задачи.

В течение фазы производства, реализации и поддержки продукции

осуществляется поиск заказчиков, подписание контрактов на поставку,

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

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

сопровождение продукта у заказчика.

Предполагается, что содержание проекта задано в виде сетевой модели

, в которой операции представлены в виде вершин, а связи – в

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

каждом этапе возможны альтернативные варианты выполнения отдельных

операций или их комплексов. Количество таких вариантов Mh зависит от

номера этапа, т.е. от h, .

Сетевая модель операций проекта включает принятую

комбинацию альтернативных вариантов выполнения операций на всех этапах

проекта,

где A множество узлов сетевой модели,

, ;

i-я операция, которая выполняется на h-м этапе при применении

j-го альтернативного варианта;

WZAG ,,,

Hh ,1

WZAG ,,,

jhiaA

hj MjHhni ,1,,1,1

jhia

65

nj количество операций в j-м альтернативном варианте;

Z множество направленных дуг в сетевой модели;

, , , , , ,

где направленная дуга, выходящая на этапе h из узла с

номером i альтернативного варианта j и входящая на этапе p в узел с

номером m альтернативного варианта f , при ;

множество времен выполнения операций,

время выполнения на этапе h операции i в соответствии с j-м

альтернативным вариантом;

W множество стоимостей выполнения операций сети G,

,

стоимость выполнения на этапе h операции i в соответствии с j-м

альтернативным вариантом.

Предполагается, что проект посвящен созданию программных

продуктов L видов, l – индекс вида продукции. Продукция l-го вида в t-м

году стоит единиц стоимости, . При этом длительность фазы

производства, реализации и поддержки продукции составляет T лет. Объём

продаж продукции l-го вида в t-м году составляет единиц, .

Объём продаж зависит, с одной стороны, от спроса на продукцию в

году t, с другой стороны - от производственной мощности предприятия в

году t по l-му виду продукции, т.е.

В модели используется булевая переменная хhj,

, равная единице в случае, если на h-м этапе выполняется j-й

альтернативный вариант, и равная нулю в противном случае.

fj pmhizZ

, 1 ji ,n fnm ,1 Hph ,1, hMj ,1 pMf ,1

fj pmhizZ

,

mi hphp j ,

hjhiMjniHhj ,1,,1,,1,

jhi

hjhiMjniHhWW j ,1,,1,,1,

jhiW

)(l

tC Tt ,1

)(l

tD Ll ,1 Tt ,1

)(l

tD )(l

tB

)(l

tA

;,

;,

)()()(

)()()(

)(

lt

lt

lt

lt

lt

ltl

tBAеслиB

BAеслиAD

,1,0hjx

hMjHh ,1,,1

66

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

фонды. Это может быть, например, устаревшее оборудование, или

оборудование, которое уже не будет использоваться. При реконструкции

зданий – это могут быть ранее использовавшиеся стройматериалы и другое.

Выбывающие на h-м этапе основные фонды могут быть проданы по

остаточной стоимости Ehj , зависящей от принятого варианта работ j, .

Для производства продукции, ее наладки и сопровождения

необходимы текущие затраты Ut, которые зависят от года t, . Эти

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

проекте и, таким образом, зависят от всей совокупности выполняемых работ

и принятой комбинации альтернативных вариантов, т.е.

,

Математическая модель задачи включает восемь целевых функций.

Одна из них подлежат максимизации и семь - минимизации. Первая целевая

функция – это прибыль предприятия до налогообложения за все годы

жизненного цикла проекта (максимизируется). Вторая – время выполнения

проекта, которое рассчитывается с помощью метода критического пути или

иного метода на сетевой модели (минимизируется). Третья целевая функция

– затраты на реализацию проекта (минимизируется). Четвертая – значение

обобщенного показателя качества продукта проекта (минимизируется). Пятая

– оценка рисков, связанных с реализацией проекта (минимизируется).

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

экологический и социально-политический эффекты от реализации проекта

(все три – минимизируются).

В модели предполагается, что после завершения отдельных этапов

выполнения проекта не должно быть финансовых задолженностей. Также

ограничением модели является максимальное время выполнения проекта.

Задано ограничение на качество продукта проекта. При этом предполагается,

hMj ,1

Tt ,1

hhjc MjHhTtxGU ,1,,1,,1),,(t

67

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

альтернативных вариантов выполнения работ.

Рассмотрим компоненты математической модели задачи оптимизации

содержания проекта. Первая целевая функция - прибыль предприятия до

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

вид [152]:

; (2.4)

Данная целевая функция является алгоритмической, так как величина

объёма продаж с помощью алгоритма связана с прогнозом спроса и

производственной мощностью.

Вторая целевая функция – это значение времени выполнения

инвестиционной фазы проекта [151]:

; (2.5)

Время Tpr зависит от принятых операций сети и, таким

образом, от хhj. Значение Tpr оценивается с помощью метода критического

пути или другого метода аналогичного назначения. Таким образом целевая

функция (2.3) также является алгоритмической.

Третья целевая функция – единовременные затраты, необходимые для

осуществления проекта на инвестиционной фазе [151]:

; (2.6)

где whj стоимость выполнения всех операций на h-м этапе, вошедших

в j-й альтернативный вариант.

T

t

L

l

H

h

M

j

H

h

T

tx

t

M

j

hjhjhjhj

l

t

l

t

h

hj

h

PUxExwDC1 1 1 1 1 1

'

1

)()( max

hx

hjtpr MjHhxGThj

,1,,1,min),(

WZAG ,,,

H

h

M

jx

hjhj

h

hj

Fxw1 1

min

68

Четвертая целевая функция – это значение обобщенного показателя

качества продукта проекта [152]:

(2.7)

где – весовой коэффициент для r-го показателя качества, 0≤ ≤1,.

Значение определяется путем опроса экспертов и вычисления

медианы для их оценок;

– нормированное значение r-го показателя качества продукта h-го

этапа проекта в результате выполнения j-го альтернативного варианта,

;

, (2.8)

;

– значение r-го показателя качества продукта h-го этапа проекта в

результате выполнения j-го альтернативного варианта. Рассматриваемые

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

величинами, соответствующими природе показателя, или выражены

экспертами в виде баллов по некоторой шкале;

– минимально значение показателя качества r;

– максимально значение показателя качества r;

Rh – количество показателей качества продукта h-го этапа проекта;

– множество индексов показателей качества продукта h-го этапа

проекта для показателей, которые стремятся максимизировать;

– множество индексов показателей качества продукта h-го этапа

проекта для показателей, которые стремятся минимизировать.

;min1 1 1

)(

H

h

M

j

R

rx

hj

norm

hjrr

h h

hj

Qxb

)(rb )(

rb

11

)(

hR

r

rb )(rb

norm

hjr

hRr ,1

)(

min,max,

max,

1

hIr

rr

hjrrnorm

hjr

)(

min,max,

min,

2

hIr

rr

rhjrnorm

hjr

hjr

rmin,

rmax,

)(

1

hI

)(

2

hI

69

В модели принято, что чем меньше значение обобщенного показателя

качества продукта проекта (2.9) тем выше качество продукта.

Пятая целевая функция – обобщённая оценка рисков проекта

; (2.10)

где Phji вероятность появления на h-м этапе проекта при реализации j-

го альтернативного варианта i-го рискового события, ;

Vhji – оценка негативных последствий от наступления на h-м этапе

проекта при реализации j-го альтернативного варианта i-го рискового

события, .

Шестая целевая функция – это технологические эффекты от

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

технологических эффектов: выработка на одного работающего в

натуральном и денежном измерении, энергоемкость производства,

ресурсоемкость производства, применение наиболее эффективных

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

технологических процессов, освоение производства новой продукции, объём

НИОКР, компетенции персонала и др.

; (2.11)

где – весовой коэффициент для r-го технологического эффекта,

, . Значение определяется путем опроса экспертов и

затем вычисления медианы для их оценок;

– нормированная оценка r-го технологического эффекта от

осуществления на h-м этапе j-го варианта выполнения работ, .

H

h

M

j

I

ix

neghjhjihji

h

hj

RxVP1 1 1

min

Ii ,1

Ii ,1

)(

rb

10 )( rb 1

1

)(

hR

r

rb )(

rb

norm

hjr

hRr ,1

H

h

M

j

R

r x hj

norm hjr r

h h

hj TE x b

1 1 1

) ( min

70

Для получения каждый из перечисленных эффектов оценивается в

натуральных показателях или с помощью балльных оценок. В результате

получаем . Затем производится нормирование по формуле (2.12):

, (2.12)

;

где – минимальное значение r-го технологического эффекта,

– максимальное значение r-го технологического эффекта;

– множество индексов технологических эффектов h-го этапа

проекта для показателей, которые стремятся максимизировать;

– множество индексов технологических эффектов h-го этапа

проекта для показателей, которые стремятся минимизировать.

Седьмая целевая функция – экологический эффект от реализации

проекта. Среди экологических эффектов учитываются все виды влияния на

окружающую среду как на инвестиционной, так и на эксплуатационной

фазах проекта

; (2.13)

где – весовой коэффициент для r-го экологического эффекта,

, . Значение определяется путем опроса экспертов и

затем вычисления медианы для их оценок;

– нормированная оценка r-го экологического эффекта от

осуществления на h-м этапе j-го варианта выполнения работ, .

norm

hjr

hjr

rmin,

)(

1

hI

)(

2

hI

)(

rb

10 )( rb 1

1

)(

hR

r

rb )(

rb

norm

hjr

hRr ,1

hj

h h

x hj norm hjr

H

h

M

j

R

r r EE x b min

1 1 1

) (

) (

r min, r max,

r min, hjr hjr 2

h norm I r

) (

r min, r max,

hjr r max, hjr 1

h norm I r

71

Для получения каждый из перечисленных эффектов оценивается в

натуральных показателях или с помощью балльных оценок. В результате

получаем . Затем производится нормирование по формуле (2.14):

, (2.14)

;

где – минимальное значение r-го экологического эффекта,

– максимальное значение r-го экологического эффекта;

– множество индексов экологических эффектов h-го этапа проекта

для показателей, которые стремятся максимизировать;

– множество индексов экологических эффектов h-го этапа проекта

для показателей, которые стремятся минимизировать.

Восьмая целевая функция – социально-политические эффекты,

полученные при реализации проекта. К данным эффектам отнесены:

количество рабочих мест в проекте, количество рабочих мест на стадии

эксплуатации продукта проекта, средняя заработная плата команды проекта,

средняя заработная плата команды, эксплуатирующей продукт проекта,

квалификация персонала после осуществления проекта, социальные

проблемы в команде проекта, которые будут решены в результате

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

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

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

результате осуществления проекта. К политической составляющей

социально-политического эффекта отнесем рейтинг конкретной

политической силы или долю ее сторонников в общем числе избирателей.

norm

hjr

hjr

rmin,

)(

1

hI

)(

2

hI

) (

r min, r max,

r min, hjr 2

h norm hjr I r

) (

r min, r max,

hjr r max, 1

h norm hjr I r

72

; (2.15)

где – весовой коэффициент для r-го социально-политического

эффекта, , . Значение определяется путем опроса

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

– нормированная оценка r-го социально-политического эффекта от

осуществления на h-м этапе j-го варианта выполнения работ, .

Для получения каждый из перечисленных эффектов оценивается в

натуральных показателях или с помощью балльных оценок. В результате

получаем . Затем производится нормирование по формуле (2.16):

, (2.16)

;

где – минимальное значение r-го социально-политического эффекта,

– максимальное значение r-го социально-политического

эффекта эффекта;

– множество индексов социально-политических эффектов h-го этапа

проекта для показателей, которые стремятся максимизировать;

– множество индексов социально-политических эффектов h-го этапа

проекта для показателей, которые стремятся минимизировать.

Первое ограничение модели задает требование не допускать

финансовых задолженностей после завершения любого h-го этапа [166]

)(

rb

10 )( rb 1

1

)(

hR

r

rb )(

rb

norm

hjr

hRr ,1

norm

hjr

hjr

rmin,

)(

1

hI

)(

2

hI

) (

r min, r max,

r min, hjr 2

h norm hjr I r

) (

r min, r max,

hjr r max, 1

h

norm hjr I r

H

h

M

j

R

r x hj

norm hjr r

h h

hj SPE x b

1 1 1

) ( min

73

, (2.17)

Sh финансовые средств, которые остаются после завершения работ на

этапе h;

S0 – финансовые средства, которые имеются перед началом первого

этапа;

Kh финансовые средства, которые выделяются для осуществления

операций на этапе h.

Второе ограничение задает требование, в соответствии с которым

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

превышать значение Tdef [151]

. (2.18)

Данное ограничение является алгоритмическим, так как время

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

аналогичного назначения.

Третье ограничение определяет требования к качеству продукта h-го

этапа проекта. В соответствии с этим ограничением значение r-го показателя

качества продукта после h-го этапа проекта должно быть меньше, равно или

больше (в каждом конкретном случае – по своему) значения [152]

. (2.19)

Четвертое ограничение задает требование, чтобы на каждом h-ом этапе

осуществлялся один из альтернативных вариантов выполнения операций

. (2.20)

HhSxwKSS h

M

j

hjhjhhh ,1,0;1

1

hhjtpr

def

pr MjHhxGTTT ,1,,1),,(,

def

hrQ

hh

def

hrhjhjr RrMjHhQx ,1,,1,,1,

HhxhM

j

hj ,1,11

74

Последнее ограничение определяет независимые переменные задачи,

которые являются булевыми

. (2.21)

Модель задачи (2.4) (2.21) имеет восемь целевых функций, является

динамической, содержит алгоритмические и аналитические целевые функции

и ограничения, булевые переменные. Для решения данной задачи предложен

вариант метода последовательных уступок [167].

В рассмотренной задаче (2.4) (2.21) предполагается, что операции

последующего этапа h+1 могут быть начаты только после завершения всех

операций этапа h, . Данное требование должно быть учтено при

формировании сети G.

2.6 Метод последовательных уступок для оптимизации

содержания проекта

Идею процесса поиска оптимального решения для многокритериальной

задачи с применением метода последовательных уступок представим в виде

ряда шагов [167]. При этом предполагаем, что все целевые функции

подлежат максимизации.

Первый шаг: все критерии располагаются в порядке их относительной

значимости, для лица, принимающего решение.

Второй шаг: осуществляется максимизация первого по значимости

критерия.

Третий шаг: назначается уступка, которая представляет собой

величину, на которую можно допустить уменьшение критерия, полученного

на втором шаге.

Четвертый шаг: осуществляется оптимизация второго по важности

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

максимального значения более, чем на установленную уступку.

hhj MjHhx ,1,,1,1,0

1,1 Hh

75

Пятый шаг: назначается уступка для второго критерия, максимальное

значение которого получено на четвертом шаге.

Шестой шаг: осуществляется максимизация третьего по важности

критерия, при условии, что значения первого и второго критериев не

отличаются от раннее полученных максимальных значений, более чем на

назначенные уступки.

Далее аналогично осуществляется поочередная оптимизация всех

сформированных критериев. Оптимальным считается решение, которое

получено при нахождении условного максимума последнего по важности

критерия.

Рассмотрим применение метода на примере задачи оптимизации

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

риски, технологический, экологический и социально-политический эффекты.

При использовании метода последовательных уступок вначале

осуществляется качественный анализ относительной важности частных

критериев задачи. В результате такого анализа критерии ранжируют от

наиболее до наименее важного. Применительно к нашей задаче критерии в

порядке убывания приоритетов расположим так: прибыль (P), стоимость (F),

качество(Q), риски (R), время(T), технологический эффект (ТЕ),

экологический эффект (ЕЕ) и социально-политический эффект (SPE). Метод

решения задачи рассмотрим по шагам.

1. Оптимизируем значение первого по важности критерия с учетом

ограничений. Для этого решаем следующую задачу:

; (2.22)

; (2.23)

; (2.24)

T

t

L

l

H

h

M

j

H

h

T

tx

t

M

j

hjhjhjhj

l

t

l

t

h

hj

h

PUxExwDC1 1 1 1 1 1

'

1

)()( max

HhSxwKSS h

M

j

hjhjhhh ,1,0;1

1

hhjtpr

def

pr MjHhxGTTT ,1,,1),,(,

76

; (2.25)

; (2.26)

. (2.27)

Если решение данной задачи получено, значение целевой функции для

него назовем Pmax, переходим к шагу 2. Если решения нет, исходная задача

также решения не имеет. Для решения рассмотренной однокритериальной

задачи может быть использован метод, предложенный в работе [168].

2. Назначаем уступку в долях от полученного значения критерия

прибыль. Формируем ограничение следующего вида:

3. Оптимизируем значение второго по важности критерия – стоимость,

учитывая ограничения и уступку по прибыли:

; (2.28)

; (2.29)

; (2.30)

; (2.31)

; (2.32)

; (2.33)

. (2.34)

Если решение получено, значение целевой функции для него

обозначим Fmin. Если решения нет и <1, возвращаемся к шагу 2 и

hh

def

hrhjhjr RrMjHhQx ,1,,1,,1,

HhxhM

j

hj ,1,11

hhj MjHhx ,1,,1,1,0

p

max

1 1 1 1 1 11

)()( )1( PUxExwDC p

T

t

L

l

H

h

M

j

H

h

T

t

t

M

j

hjhjhjhj

l

t

l

t

h h

H

h

M

jx

hjhj

h

hj

Fxw1 1

min

HhSxwKSS h

M

j

hjhjhhh ,1,0;1

1

hhjtpr

def

pr MjHhxGTTT ,1,,1),,(,

hh

def

hrhjhjr RrMjHhQx ,1,,1,,1,

max

1 1 1 1 1 11

)()( )1( PUxExwDC p

T

t

L

l

H

h

M

j

H

h

T

t

t

M

j

hjhjhjhj

l

t

l

t

h h

HhxhM

j

hj ,1,11

hhj MjHhx ,1,,1,1,0

p

77

увеличиваем уступку. Если ≥1, задача решения не имеет. Для решения

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

предложенный в работе [169].

4. Назначаем уступку в долях от полученного значения критерия

стоимость. Формируем ограничение

.

5. Оптимизируем значение критерия качество с учетом ограничений и

уступок по критериям прибыль и стоимость:

(2.35)

; (2.36)

; (2.37)

; (2.38)

; (2.39)

; (2.40)

; (2.41)

. (2.42)

Если решение получено, значение целевой функции для него

обозначим Qmin. Если решения нет и < допF , возвращаемся к шагу 4 и

увеличиваем значение уступки по критерию стоимость. Если ≥ допF ,

задача решения не имеет. Здесь допF – максимально допустимое по условиям

p

F

min

1 1

)1( Fxw F

H

h

M

j

hjhj

h

;min1 1 1

)(

H

h

M

j

R

rx

hj

norm

hjrr

h h

hj

Qxb

HhSxwKSS h

M

j

hjhjhhh ,1,0;1

1

hh

def

hrhjhjr RrMjHhQx ,1,,1,,1,

hhjtpr

def

pr MjHhxGTTT ,1,,1),,(,

max

1 1 1 1 1 11

)()( )1( PUxExwDC p

T

t

L

l

H

h

M

j

H

h

T

t

t

M

j

hjhjhjhj

l

t

l

t

h h

min

1 1

)1( Fxw F

H

h

M

j

hjhj

h

HhxhM

j

hj ,1,11

hhj MjHhx ,1,,1,1,0

F

F

78

задачи значение уступки. Для решения рассмотренной однокритериальной

задачи может быть использован метод, предложенный в работе [152].

6. Назначаем уступку Q для найденного оптимального значения

критерия качество. Формируем ограничение:

.

7. Находим оптимальное значение по критерию риски с учетом

ограничений и ранее сделанных уступок:

; (2.43)

; (2.44)

; (2.45)

; (2.46)

; (2.47)

; (2.48)

; (2.49)

; (2.50)

. (2.51)

Если решение получено, значение целевой функции для него

обозначим Rmin и перейдем к шагу 8. Если решения нет и Q<Q доп,

возвращаемся к шагу 6 и увеличиваем значение уступки по критерию

качество. Если Q ≥ Q доп, задача решения не имеет. Здесь Q доп –

min

1 1 1

)( )1( Qxb Q

H

h

M

j

R

r

hj

norm

hjrr

h h

H

h

M

j

I

ix

neghjhjihji

h

hj

RxVP1 1 1

min

HhSxwKSS h

M

j

hjhjhhh ,1,0;1

1

hh

def

hrhjhjr RrMjHhQx ,1,,1,,1,

hhjtpr

def

pr MjHhxGTTT ,1,,1),,(,

max

1 1 1 1 1 11

)()( )1( PUxExwDC p

T

t

L

l

H

h

M

j

H

h

T

t

t

M

j

hjhjhjhj

l

t

l

t

h h

min

1 1

)1( Fxw F

H

h

M

j

hjhj

h

min

1 1 1

)( )1( Qxb Q

H

h

M

j

R

r

hj

norm

hjrr

h h

HhxhM

j

hj ,1,11

hhj MjHhx ,1,,1,1,0

79

максимально допустимое по условию задачи значение уступки. Для решения

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

предложенный в работе [152].

8. Назначаем значение уступки по критерию риски R и формируем

ограничение:

.

9. Оптимизируем значение критерия – время с учетом ограничений и

уступок по остальным критериям:

; (2.52)

; (2.53)

; (2.54)

; (2.55)

; (2.56)

; (2.57)

; (2.58)

; (2.59)

; (2.60)

. (2.61)

Если решение получено, значение целевой функции для него

обозначим как Тpr min и переходим к шагу 10. Если решения нет, и R < R доп,

min

1 1 1

)1( RxVP R

H

h

M

j

I

i

hjhjihji

h

hx

hjtpr MjHhxGThj

,1,,1,min),(

HhSxwKSS h

M

j

hjhjhhh ,1,0;1

1

hhjtpr

def

pr MjHhxGTTT ,1,,1),,(,

hh

def

hrhjhjr RrMjHhQx ,1,,1,,1,

max

1 1 1 1 1 11

)()( )1( PUxExwDC p

T

t

L

l

H

h

M

j

H

h

T

t

t

M

j

hjhjhjhj

l

t

l

t

h h

min

1 1

)1( Fxw F

H

h

M

j

hjhj

h

min

1 1 1

)( )1( Qxb Q

H

h

M

j

R

r

hj

norm

hjrr

h h

min

1 1 1

)1( RxVP R

H

h

M

j

I

i

hjhjihji

h

HhxhM

j

hj ,1,11

hhj MjHhx ,1,,1,1,0

80

возвращаемся к шагу 8 и увеличиваем значение уступки по критерию риски.

Если R ≥R доп, задача решения не имеет. Здесь R доп – максимально

допустимое по условиям задачи значение уступки. Для решения

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

предложенный в работе [146].

10. Назначаем значение уступки по критерию время T и формируем

ограничение:

min1, prThjt TxG .

11. Оптимизируем значение технологического эффекта от проекта с

учетом ограничений и уступок по остальным критериям:

; (2.62)

; (2.63)

; (2.64)

; (2.65)

; (2.66)

; (2.67)

; (2.68)

; (2.69)

min1, prThjt TxG ;

(2.70)

HhSxwKSS h

M

j

hjhjhhh ,1,0;1

1

hhjtpr

def

pr MjHhxGTTT ,1,,1),,(,

hh

def

hrhjhjr RrMjHhQx ,1,,1,,1,

max

1 1 1 1 1 11

)()( )1( PUxExwDC p

T

t

L

l

H

h

M

j

H

h

T

t

t

M

j

hjhjhjhj

l

t

l

t

h h

min

1 1

)1( Fxw F

H

h

M

j

hjhj

h

min

1 1 1

)( )1( Qxb Q

H

h

M

j

R

r

hj

norm

hjrr

h h

min

1 1 1

)1( RxVP R

H

h

M

j

I

i

hjhjihji

h

H

h

M

j

R

r x hj

norm hjr r

h h

hj TE x b

1 1 1

) ( min

81

; (2.71)

. (2.72)

Если решение получено, значение целевой функции для него

обозначим как ТЕ mах и переходим к шагу 12. Если решения нет и Т < Т доп,

возвращаемся к шагу 10 и увеличиваем значение уступки по критерию время.

Если Т ≥Т доп, задача решения не имеет. Здесь Т доп – максимально

допустимое по условиям задачи значение уступки. Для решения

рассмотренной и последующих задач по критериям экологический и

социально-политические эффекты может быть использован по аналогии

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

[152].

12. Назначаем значение уступки по критерию технологический эффект

ТЕ и формируем ограничение:

min

1 1 1

)( 1 TExb TE

H

h

M

j

R

r

hj

norm

hjrr

h h

.

13. Оптимизируем значение экологического эффекта от проекта с

учетом ограничений и уступок по остальным критериям:

; (2.73)

; (2.74)

; (2.75)

; (2.76)

; (2.77)

HhxhM

j

hj ,1,11

hhj MjHhx ,1,,1,1,0

HhSxwKSS h

M

j

hjhjhhh ,1,0;1

1

hhjtpr

def

pr MjHhxGTTT ,1,,1),,(,

hh

def

hrhjhjr RrMjHhQx ,1,,1,,1,

max

1 1 1 1 1 11

)()( )1( PUxExwDC p

T

t

L

l

H

h

M

j

H

h

T

t

t

M

j

hjhjhjhj

l

t

l

t

h h

hj

h h

x hj norm hjr

H

h

M

j

R

r r EE x b min

1 1 1

) (

82

; (2.78)

; (2.79)

; (2.80)

min1, prThjt TxG ; (2.81)

min

1 1 1

)( 1 TExb TE

H

h

M

j

R

r

hj

norm

hjrr

h h

; (2.82)

; (2.83)

. (2.84)

Если решение получено, значение целевой функции для него

обозначим как ЕЕ mах и переходим к шагу 14. Если решения нет и ТЕ < ТЕ доп,

возвращаемся к шагу 12 и увеличиваем значение уступки по критерию

технологический эффект. Если ТЕ ≥ТЕ доп, задача решения не имеет. Здесь

ТЕ доп – максимально допустимое по условиям задачи значение уступки.

14. Назначаем значение уступки по критерию экологический эффект

ЕЕ и формируем ограничение:

min

1 1 1

)( 1 EExb EE

H

h

M

j

R

r

hj

norm

hjrr

h h

;

15. Оптимизируем значение социально-политического эффекта от

проекта с учетом ограничений и уступок по остальным критериям:

; (2.85)

; (2.86)

min

1 1

)1( Fxw F

H

h

M

j

hjhj

h

min

1 1 1

)( )1( Qxb Q

H

h

M

j

R

r

hj

norm

hjrr

h h

min

1 1 1

)1( RxVP R

H

h

M

j

I

i

hjhjihji

h

HhxhM

j

hj ,1,11

hhj MjHhx ,1,,1,1,0

HhSxwKSS h

M

j

hjhjhhh ,1,0;1

1

H

h

M

j

R

r x hj

norm hjr r

h h

hj SPE x b

1 1 1

) ( min

83

; (2.87)

; (2.88)

; (2.89)

; (2.90)

; (2.91)

; (2.92)

min1, prThjt TxG ; (2.93)

min

1 1 1

)( 1 TExb TE

H

h

M

j

R

r

hj

norm

hirr

h h

; (2.94)

min

1 1 1

)( 1 EExb EE

H

h

M

j

R

r

hj

norm

hjrr

h h

; (2.95)

; (2.96)

. (2.97)

Если данная задача имеет решение, оно может рассматриваться как

решение исходной многокритериальной задачи с учетом уступок по ряду

критериев Если решения нет, и EЕ < EЕ доп, возвращаемся к шагу 14 и

увеличиваем значение уступки по критерию экологический эффект. Если

ЕЕ ≥ЕЕ доп, задача решения не имеет. Здесь ЕЕ доп – максимально допустимое

по условиям задачи значение уступки.

Выводы к разделу 2

1. Разработаны три метода выбора методологии для управления

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

hhjtpr

def

pr MjHhxGTTT ,1,,1),,(,

hh

def

hrhjhjr RrMjHhQx ,1,,1,,1,

max

1 1 1 1 1 11

)()( )1( PUxExwDC p

T

t

L

l

H

h

M

j

H

h

T

t

t

M

j

hjhjhjhj

l

t

l

t

h h

min

1 1

)1( Fxw F

H

h

M

j

hjhj

h

min

1 1 1

)( )1( Qxb Q

H

h

M

j

R

r

hj

norm

hjrr

h h

min

1 1 1

)1( RxVP R

H

h

M

j

I

i

hjhjihji

h

HhxhM

j

hj ,1,11

hhj MjHhx ,1,,1,1,0

84

степенью осведомленности лиц, принимающих решения, о существующих

методологиях.

2. Первый метод представляет собой анкету, вопросы которой

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

влияющие на выбор методологии. Метод предлагается использовать в

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

альтернативные методологии и стандарты по управлению проектами.

3. Второй метод представляет собой трехкритериальную задачу

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

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

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

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

в достаточной степени владеет альтернативными методологиями и

стандартами по управлению проектами, а также имеет средства и время для

оценивания указанных показателей.

4. Третий метод представляет собой задачу оптимизации содержания

проекта по критериям экономический эффект (прибыль), сроки, стоимость,

качество, риски, технологический, экологический, социально-политический

эффекты. Решая задачу оптимизации содержания проекта для

альтернативных методологий, можно сделать более обоснованный ее выбор,

нежели при выборе методологии в отрыве от оптимизации содержании

проекта.

5. Усовершенствована математическая модель задачи

многокритериальной оптимизации содержания проекта. Предложено

рассматривать широкую гамму ценностей проекта, которые характеризуются

не только экономическим эффектом (прибылью), временем, стоимостью,

качеством, рисками, но также технологическим, социально-политическим и

экологическим эффектами. Математическая модель задачи дополнена

целевыми функциями, которые отражают указанные эффекты.

6. Предложен метод решения задачи многокритериальной оптимизации

содержания проекта по критериям экономический эффект (прибыль), сроки,

85

стоимость, качество, риски, технологический, экологический, социально-

политический эффекты, развивающий идею метода последовательных

уступок.

7. Основные результаты раздела опубликованы в работе [1-5].

86

РАЗДЕЛ 3

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

РЕКОМЕНДАЦИЙ ЭКСПЕРТОВ, А ТАКЖЕ ПО КРИТЕРИЯМ

ТРУДОЗАТРАТЫ, СТОИМОСТЬ, РИСКИ

3.1 Описание проекта по созданию программного продукта

«ForPlan»

Рассмотрим применение предлагаемых методов выбора методологии

управления проектом на примере проекта по созданию компьютерной

программы «ForPlan». Данное программное обеспечение предназначено для

решения задач, возникающих в процессе маркетингового анализа и

стратегического управления на уровне отдельного предприятия, корпорации,

отрасли. Программное обеспечение будет включать хорошо

зарекомендовавшие себя на практике методы [170], а именно:

методы прогнозирования нестационарных случайных процессов с

использованием Н-критерия и boot-strap оценивания;

метод оптимизации типажа перспективной продукции;

метод экспресс-анализа уровня конкурентоспособности продукции;

метод оптимизации планов развития предприятия.

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

интерфейс, отраженный на диаграмме вариантов использования (приложение

А рис. А.1)

Предполагается, что данные, необходимые для статистического

анализа будут храниться в базах данных различных форматов. Программа

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

сформированным хранилищам данных. Пользователь сможет определить

фильтр выборки этих данных.

Для проведения анализа статистических данных будет предоставлен

наглядный графический интерфейс конфигурирования такого анализа.

Пользователь сможет задать точность его проведения, выбрать один из

87

предложенных методов или позволить программе самостоятельно

определить оптимальный вариант. Результаты проведения анализа будут

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

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

сопровождаться информационно-справочной системой.

Работу над разработкой данного программного обеспечения можно

разделить на три основных блока:

－ создание графического интерфейса;

－ программная реализация математических методов;

－ разработка модуля взаимодействия с операционной системой и

аппаратным обеспечением.

Полное описание операций по реализации программного обеспечения

представлено в приложении А таблица А.1. Совокупность операций

разделяется на пять этапов. На первом этапе закладывается алгоритмическое

ядро разрабатываемого продукта. На втором – проектируется интерфейс для

редактирования введенных данных и конфигурирования выполнения

методов. На третьем и четвертом этапах проектируется интерфейс для

вывода результатов выполнения программируемых методов. На пятом –

формируется документация по проекту и реализуются средства для работы с

внешними источниками входных данных. Организационная структура

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

плат в таблице А.2, перечень функциональных обязанностей участников

команды – в таблице А.3, а также трудозатраты каждого участника команды

на каждом этапе разработки программного обеспечения в таблица А.4. Здесь

и далее все затраты указаны по состоянию на начало 2014 года.

Трудозатраты участников команды на разработку программного

продукта составили – 1168 рабочих часов. Как известно, длительность

эффективного рабочего дня людей, занятых интенсивным творческим и

интеллектуальным трудом, составляет 6 часов [171-173], поэтому в расчетах

была принята тридцатичасовая рабочая неделя.

88

3.2 Применение метода выбора методологии управления проектом

на основе существующих рекомендаций

Основываясь на информации, изложенной в приложении А, была

заполнена анкета, представленная в таблицах 2.1 – 2.6. Строки анкеты,

соответствующие рассматриваемому проекту, собраны в таблицы 3.1 – 3.2.

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

Вопросы Ответы

1 2

Название проекта Разработка программного обеспечения для прогнозирования и

планирования развития предприятия «ForPlan»

Суть проекта

Создание программного обеспечения для прогнозирования

факторов среды, оптимизации типажа продукции и

планирования развития предприятия

Тип проекта Создание нового продукта

Продукт проекта

Программное обеспечение для решения задач стратегического

планирования путем использования разработанных ранее

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

Предполагается дружественный интерфейс пользователя

Таблица 3.2 – Аспекты управления проектом

Вопросы анкеты Варианты ответов Баллы Рекомендуемая

методология

1 2 3 4

Опыт работы заказчика с

данной командой проекта

Есть опыт работы с

некоторыми участниками

команды

2 PMBoK,

PRINCE2,

SWEBOK, Р2М

Опыт работы в данной

отрасли

Есть опыт работы в отрасли

более 5 лет 4

SCRUM, Crystal

Clear

Понимание требований,

умение адаптироваться и

проявлять инициативу

Хорошо ориентируются в

требованиях, могут

следовать им, не требуя

регулярного контроля, могут

предложить лучшие

альтернативы

4 SCRUM, Crystal

Clear

Опыт совместной работы Работали вместе над

созданием нескольких

продуктов в интересующей

отрасли

4 SCRUM, Crystal

Clear

Знание используемых

инструментов и методов

Инструменты и методы

известны команде и широко

применялись в прошлом

4 SCRUM, Crystal

Clear

89

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

1 2 3 4

Обучаемость Легко обучаемы, умеют

адаптироваться к

изменениями

3 Р2М, SCRUM,

Crystal Clear

Четкость и прямота в

высказываниях

Умеют четко формулировать

идеи, могут прямо высказать

свое мнение

3 Р2М, SCRUM

Умение признавать свои

ошибки

Открыто признают свои

ошибки и стараются их не

повторять

3 Р2М, SCRUM,

Crystal Clear

Виды средств коммуникаций Непосредственное общение

команды проекта (собрания,

видеоконференции)

4 Р2М, SCRUM,

Crystal Clear

Частота отчетов перед

заказчиком в процессе

выполнения проекта

Отчет о получении

компонента продукта

проекта

3 SCRUM, Crystal

Clear

Имеющееся представление о

работах проекта

Есть представление о

конечной цели проекта и

несколько альтернатив для

путей ее достижения

4 SCRUM, Crystal

Clear

Последствия в случае

неудовлетворительного

завершения проекта

Потеря комфорта в работе 4 SCRUM, Crystal Clear

Стоимость проекта Менее 100 тысяч долл. США 4 SCRUM, Crystal

Clear

Требования к качеству

продукта проекта

Международные требования 2 PMBoK,

PRINCE2,

SWEBOK, P2M

Требования к срокам

реализации проекта

Не очень срочно 2 Р2М, SCRUM*,

PRINCE2*

Требования к точности

соблюдения сроков

Допускается некоторое

отклонение от сроков

2 PMBoK,

PRINCE2,

SWEBOK, Р2М,

Вероятность проявления

риска, связанного с

архитектурой объекта,

технологиями и процессами

его создания, показателями

качества

Рисковое событие, скорее

всего, проявится (75%).

2 PMBoK,

PRINCE2,

SWEBOK, Р2М

Вероятность проявления

внешних рисков (срыв работ

подрядчиками,

неблагоприятная

политическая,

экономическая обстановка в

стране, изменения рынка и

т.д.)

Вероятность проявления

рисковых событий равна

50%

3 Р2М, SCRUM,

Crystal Clear*

90

Окончание таблицы 3.2

1 2 3 4

Вероятность наступления

организационных рисков

(срыв финансирования, срыв

поставки ресурсов,

неправильная расстановка

приоритетов и т.д.)

Рисковое событие, скорее

всего, не проявится (10%)

4 SCRUM, Crystal

Clear

Вероятность наступления

рисковых событий,

связанных с управлением

проектом (некачественное

планирование, контроллинг,

проблемы коммуникации и

т.д.)

Вероятность проявления

рисковых событий равна

50%

3 Р2М, SCRUM,

Crystal Clear*

В результате анализа таблицы 3.2 составлена диаграмма (рис.3.1),

которая наглядно отображает количество рекомендаций для конкретных

методологий, встречающихся в ответах анкеты, в сравнении с общим числом

ответов.

Рисунок 3.1 – Количество рекомендаций для методологий

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

разработке программного обеспечения «ForPlan» наилучшим образом

подойдут три методологии SCRUM, Crystal Clear и Р2М.

По результатам ответов на вопросы анкеты определен средний балл.

Его значение составило 3,2. Данное значение соответствует рекомендации к

применять методологии SCRUM, Crystal Clear или Р2М.

3 3 4

10 16

14

0

5

10

15

20 PMBOK

SWEBOK

PRINCE2

P2M

SCRUM

CRYSTAL

CLEAR

Количетсво рекомендаций

Общее число вопросов

91

Для решения задачи выбора оптимальной методологии в условиях

достаточной степени владения лицами, принимающими решения,

альтернативными методологиями применим метод выбора методологии

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

сопутствующих рисков.

Для этого оценим трудоемкость и стоимость управления при

применении методологий PMBOK, PRINCE2, SWEBOK, P2M, SCRUM,

Crystal Clear, а также риски от их применения для проекта по разработке

программного обеспечения «ForPlan».

3.3 Применение метода выбора методологии управления проектом

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

рисков

3.3.1 Оценка трудозатрат и стоимости управления проектом при

использовании методологии PMBOK

Проект разработки программного обеспечения «ForPlan» был

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

методологии PMBOK [72].

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

Microsoft Project 2007. Было определено, что если каждый из 47 процессов,

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

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

долгое время.

С целью разгрузки Project manager’а (в дальнейшем должности

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

тем, как это принято в ИТ отрасли), было решено воспользоваться услугами

Business Consultant’а и перевести на него некоторые задачи Project manager’а.

Его услуги будут оплачиваться почасово, а именно 80 гривен в час.

Распределение операций между Project manager’oм и Business

Consultant’oм, а также трудозатраты на выполнение данных процессов,

представлены в таблице Б.1.

92

В таблице Б.1 и далее, в аналогичных таблицах, трудозатраты на

выполнение перечисленных задач рассчитывались как медиана оценок

длительностей задач, сделанных четырьмя экспертами. Здесь и далее

структурные элементы рассматриваемых методологий, такие как процессы в

PMBOK, PRINCE2 и задачи в SCRUM или Crystal Clear будем называть

«операциями».

Исходя из данных таблицы Б.1, можно определить общие

трудозатраты:

－ Project manager’а – 1037,2 часа;

－ Business Consultan’а – 53 часа;

－ Project Team (Business analyst, Senior programmer, Junior programmer,

Junior programmer, Quality assurance engineer (Non-Functional testing), Quality

assurance engineer (Functional testing) – 194,45 часа.

Расчет общих трудозатрат на управление проектом представлен в

таблице 3.3.

Таблица 3.3 – Общие трудозатраты на управление при использовании

методологии PMBOK В часах

Фазы

Команда проекта

Pro

ject

man

ager

Busi

nes

s C

onsu

ltan

t

Busi

nes

s an

alyst

Sen

ior

pro

gra

mm

er

Junio

r pro

gra

mm

er

Junio

r pro

gra

mm

er

Qual

ity a

ssura

nce

engin

eer

(Non-F

unct

ional

tes

ting)

Qual

ity a

ssura

nce

engin

eer

(Funct

ional

tes

ting)

Подготовитель

-ная фаза 112 53 2,25 2,25 2,25 2,25 2,25 2,25

Фаза

выполнения 925,2 - 192,2 192,2 192,2 192,2 192,2 192,2

Весь проект 1037,2 53 194,45 194,45 194,45 194,45 194,45 194,45

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

рассчитаем стоимость управления проектом (таблица 3.4).

93

Таблица 3.4 – Расходы на управление при использовании методологии

PMBOK

Команда проекта почасовая

ставка, грн

трудозатраты,

часы

затраты на

управление, грн

Project manager 170 1037,2 176324

Business Consultant 80 53 4240

Business analyst 150 194,45 29167,5

Senior programmer 180 194,45 35001

Junior programmer 130 194,45 25278,5

Junior programmer 130 194,45 25278,5

Quality assurance engineer

(Functional testing) 130

194,45 25278,5

Quality assurance engineer (Non-

Functional testing) 100

194,45 19445

Всего 2256,9 340 013

Как видно из таблицы 3.4, общие трудозатраты на управление

проектом составят 2256,9 человеко-часов, а стоимость управления проектом

по разработке программного обеспечения «ForPlan» при использовании

методологии PMBOK составит 340 013 грн.

3.3.2 Оценка стоимости управления проектом при использовании

методологии PRINCE2

Методология PRINCE2 [74] предполагает, что управлять проектом

должен Project manager, за деятельностью которого должен наблюдать Project

Steering Committee (Project Board), во главе которого стоит Executive director.

Услуги Executive director’a будут оплачиваться почасово, а именно 80 гривен

в час.

Как и при управлении проектом с использованием методологии

PMBOK, при применении PRINCE2 Project manager, выполняющий все

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

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

непосредственно команды проекта, контролирует Senior programmer,

выполняющий обязанности Team Lead’a.

Распределение операций между Project manager’ом и командой

проекта, а также трудозатраты на выполнение данных операций

представлены в таблице Б.2.

94

Исходя из данных таблицы Б.2, можно определить общие

трудозатраты:

－ Project Steering Committee – 31 час;

－ Executive director – 140 часов;

－ Project manager – 740 часов;

－ Senior programmer (как Team Lead) – 41 час.

－ Project Team (Business analyst, Senior programmer, Junior programmer,

Junior programmer, Quality assurance engineer (Non-Functional testing), Quality

assurance engineer (Functional testing) – 199 часов.

Существует рекомендация, что для малых проектов роль Project

Support, предусмотренная методологией, может выполнять Project manager

[175]. Так как рассматриваемый проект относится к небольшим –

воспользуемся данной рекомендацией.

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

таблице 3.5.

Таблица 3.5 – Общие трудозатраты на управление при использовании

методологии PRINCE2

В часах

Фазы

Команда проекта

Pro

ject

Ste

erin

g

Com

mit

tee

Exec

uti

ve

dir

ecto

r

Pro

ject

man

ager

Busi

nes

s an

alyst

Sen

ior

pro

gra

mm

er

Junio

r pro

gra

mm

er

Junio

r pro

gra

mm

er

Qual

ity a

ssura

nce

engin

eer

(Non-F

unct

ional

tes

ting)

Qual

ity a

ssura

nce

engin

eer

(Funct

ional

tes

ting)

1 2 3 4 5 6 7 8 9 10

Процесс запуска 31 56 123 0 0 0 0 0

Управление

проектом 0 44 123 16 16 16 16 16 16

Процесс

инициации 0 40 208 20 20 20 20 20 20

Процесс

контроля 0 0 136 52 62 52 52 52 52

95

Окончание таблицы 3.5

1 2 3 4 5 6 7 8 9 10

Поставка

продукта 0 0 11 22 53 22 22 22 22

Управление

границами

проекта

0 0 100 60 60 60 60 60 60

Завершение 39 29 29 29 29 29 29

Весь проект 31 140 740 199 240 199 199 199 199

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

рассчитаем стоимость управления проектом – таблица 3.6.

Таблица 3.6 – Расходы на управление при использовании методологии

PRINCE2

Команда проекта почасовая

ставка, грн

трудозатраты,

часы

затраты на

управление, грн

1 2 3 4

Project Steering Committee 0 31 0

Executive director 80 140 11200

Project manager 170 740 125800

Business analyst 150 199 29850

Senior programmer 180 240 43200

Junior programmer 130 199 25870

Junior programmer 130 199 25870

Quality assurance engineer

(Functional testing) 130 199

25870

Quality assurance engineer (Non-

Functional testing) 100 199

19900

Всего 2146 307 560

Как видно из таблицы 3.6 общие трудозатраты на управление проектом

составят 2146 человеко-часов, а стоимость управления при использовании

методологии PRINCE2 составит 307 560 грн.

3.3.3 Оценка стоимости управления проектом при использовании

методологии P2M

В результате анализа рассматриваемого проекта в разрезе применения

методологии Р2М [75] все операции по управлению проектом были

разделены на 5 фаз. В течение каждой фазы члены команды будут выполнять

ряд обязанностей. В таблице Б.3 представлено распределение рабочего

96

времени между менеджером проекта и членами команды. Методология Р2М

предусматривает создание проектной документации в конце каждого из

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

сторон раз в месяц. Как и в других стандартах управления проектами в Р2М

выделяют роль заказчика или инвестора, который наблюдает за работой

команды и менеджера проекта. Инвестор является внешним лицом для

компании, разрабатывающей рассматриваемый программный продукт,

поэтому оплата его труда не учитывается.

Исходя из данных таблицы Б.3, можно определить общие

трудозатраты:

－ Project manager’а – 598 часов;

－ Project Team (Business analyst, Senior programmer, Junior programmer,

Junior programmer, Quality assurance engineer (Non-Functional testing), Quality

assurance engineer (Functional testing) – 131 час.

Расчет общих трудозатрат на управление проектом представлен в

таблице 3.7.

Таблица 3.7 – Общие трудозатраты на управление при использовании

методологии Р2М В часах

Фази

Команда проекта

Pro

ject

man

ager

Busi

nes

s an

alyst

Sen

ior

pro

gra

mm

er

Junio

r

pro

gra

mm

er

Junio

r

pro

gra

mm

er r

Qual

ity

assu

rance

engin

eer

(Funct

ional

test

ing)

Qual

ity

assu

rance

engin

eer

(Non

-

Funct

ional

test

ing)

1 2 3 4 5 6 7 8

Разработка 43 - - - - - -

Планирование 187 6 6 6 6 6 6

Реализация 196 52 52 52 52 52 52

Координация 96 16 16 16 16 16 16

Завершение 76 57 57 57 57 57 57

Весь проект 598 131 131 131 131 131 131

97

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

рассчитаем стоимость управления проектом (таблица 3.8).

Таблица 3.8 – Расходы на управление при использовании методологии

Р2М

Команда проекта почасовая

ставка, грн

трудозатраты,

часы

затраты на

управление, грн

1 2 3 4

Project manager 170 598 101 660,00

Business analyst 150 131 19 650,00

Senior programmer 180 131 23 580,00

Junior programmer 130 131 17 030,00

Junior programmer 130 131 17 030,00

Quality assurance engineer (Functional

testing)

130 131 17 030,00

Quality assurance engineer (Non-

Functional testing)

100 131 13 100,00

Всего 1384 209 080,00

Как видно из таблицы 3.8, общие трудозатраты на управление

составляют 1384 часов, а стоимость управления проектом по разработке

программного обеспечения при использовании методологии P2M составляет

209 080,00 грн.

3.3.4 Оценка стоимости управления проектом при использовании

методологии SWEBOK

В результате анализа представленного проекта для случая

использования методологии SWEBOK [87] все операции управления

проектом были разделены на 6 фаз. В таблице Б.4 представлено

распределение рабочего времени между Project manager’ом и членами

команды на выполнение задач управления проектом. SWEBOK

предусматривает создание отчетности в конце каждого этапа.

Исходя из данных таблицы Б.4, можно определить, что общие

трудозатраты составят:

－ Project manager’а составят 622 часа;

98

－ Project Team (Business analyst, Senior programmer, Junior programmer,

Junior programmer, Quality assurance engineer (Non-Functional testing), Quality

assurance engineer (Functional testing) – 302,2 часа.

Расчет общих трудозатрат на управление проектом представлен в

таблице 3.9.

Таблица 3.9 – Общие трудозатраты на управление при использовании

методологии SWEBOK

В часах

Фазы

Команда проекта

Pro

ject

man

ager

Busi

nes

s an

alyst

Sen

ior

pro

gra

mm

er

Junio

r pro

gra

mm

er

Junio

r pro

gra

mm

er r

Qual

ity

assu

rance

engin

eer

(Funct

ional

test

ing)

Qual

ity

assu

rance

engin

eer

(Non

-

Funct

ional

tes

ting)

1 2 3 4 5 6 7 8

Инициирование

и определение

содержания

26 - - - - - -

Планирование

программного

проекта

126 33 33 33 33 33 33

Выполнение

программного

проекта

310 219,2 219,2 219,2 219,2 219,2 219,2

Обзор

и оценка 24 8 8 8 8 8 8

Закрытие 60 22 22 22 22 22 22

Измерение 76 20 20 20 20 20 20

Весь проект 622 302,2 302,2 302,2 302,2 302,2 302,2

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

рассчитаем стоимость управления проектом (таблица 3.10).

99

Таблица 3.10 – Затраты на управление проектом по методологии

SWEBOK

Команда проекта почасовая ставка,

грн

трудозатраты,

часы

затраты на

управление,

грн

1 2 3 4

Project manager 170 622 105 740,00

Business analyst 150 302,2 45 330,00

Senior programmer 180 302,2 54 396,00

Junior programmer 130 302,2 39 286,00

Junior programmer 130 302,2 39 286,00

Quality assurance engineer (Functional

testing)

130 302,2 39 286,00

Quality assurance engineer (Non-

Functional testing)

100 302,2 30 220,00

Всего 2435,2 353 544,00

Как видно из таблицы 3.10, общие трудозатраты составят 2435,2 часов,

а расходы на управление при использовании методологии SWEBOK равны

353 544,00 грн.

3.3.5 Оценка стоимости управления проектом при использовании

методологии SCRUM

В результате анализа представленного проекта для случая

использования методологии SCRUM [88] проект был разделен на пять

спринтов продолжительностью по четыре недели каждый. В случае, когда

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

должна начинать работать над задачами следующего спринта. В том случае,

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

переносятся на другой спринт.

Группой экспертов, состоящей из трех человек, сделаны оценки

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

Master’ом. Перечислим операции, возлагаемые на Scrum-Master’а согласно

методологии, и время, предполагаемое для их выполнения.

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

100

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

(Product Backlog) - 4 часа;

2) составление краткого описания проекта – 7 часов.

Спринт:

1) проведение совещаний по планированию спринта – 6 часов;

2) составление документов из перечня функциональности и требований

для текущего Спринта (Sprint Backlog) – 6 часов;

3) формирование доски задач (Taskboard) – 2 часа;

4) формирование графика отслеживания их выполнения (Sprint

Burndown chart) – 2 часа;

5) подготовка и проведение релиза демо-версии ПО – 6 часов;

6) проведение ретроспективного анализа спринта – 3 часа.

Оперативная деятельность:

1) проведение ежедневных совещаний (Stand-up meeting ) 20 мин на 20

дней спринта – 7 часов;

2) обновление документации по спринту 8 раз по 1часу – 8 часов;

3) обновление доски задач и графика выполнения – 4 часа;

Исходя из выше перечисленных операций Scrum-Master тратит 11

часов на подготовительный этап и 25 часов на каждый спринт. Оперативная

деятельность занимает 19 часов на спринт [175].

Таким образом, Scrum-Master тратит 44 часа на управление каждым

спринтом. Управление данным проектом, в целом, потребует 231 час работы

Scrum-Master’а.

Следует отметить, что совещание по планированию спринта

проводится перед началом работы команды разработчиков и, как было

указано выше, длительность такого совещания составляет 6 часов. Это время

также входит в рабочее время всех членов команды разработчиков,

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

частью производственного процесса. Также в рабочее время активной

команды добавляется продолжительность ежедневных совещаний

101

длительностью 20 минут в течение всего спринта, которые в целом занимают

7 часов на спринт. Время, необходимое для управления проектом при

использовании методологии SCRUM, представлено в таблице 3.11.

Таблица 3.11 – Общие трудозатраты на управление при использовании

методологии SCRUM

Команда проекта

Рабочие часы за Спринт

Продолжитель-ность cпринта, раб. ч.

Busi

nes

s an

alyst

Sen

ior

pro

gra

mm

er

Junio

r pro

gra

mm

er

Junio

r pro

gra

mm

er

Qual

ity a

ssura

nce

en

gin

eer

(Non

-Funct

ional

te

stin

g)

Qual

ity a

ssura

nce

en

gin

eer

(Funct

ional

tes

ting)

1 2 3 4 5 6 7 8

Спринт 1 13 13 13 13 0 13 65

Спринт2 13 13 13 13 13 13 78

Спринт 3 13 13 13 13 0 13 65

Спринт 4 13 13 13 13 0 13 65

Спринт 5 13 13 13 13 13 0 65

Весь проект 65 65 65 65 26 52 338

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

рассчитаем стоимость управления проектом (таблица 3.12).

Таблица 3.12 – Расчет затрат на управление проектом по методологии

SCRUM

Команда проекта почасовая

ставка, грн

трудозатраты,

часы

затраты на

управление, грн

1 2 3 4

Scrum-Master 170 231 39270

Business analyst 150 65 9750

Senior programmer 180 65 11700

Junior programmer 130 65 8450

Junior programmer 130 35 4550

Quality assurance engeneer

(Functional testing) 130 52 6760

Quality assurance engeneer

(Non-Functional testing) 100 26 2600

Всего 539 83 080,00

102

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

539 человеко-часов, а стоимость управления проектом при использовании

методологии SCRUM составляет 83 080,00 грн.

3.3.6 Оценка стоимости управления проектом при использовании

методологии Crystal Clear

Методология Crystal Clear [55] не предусматривает четкого перечня

операций управления. Поэтому были специально определены операции,

касающиеся управления проектом, без которых невозможно выполнить

проект (таблица 3.13), а также перечень членов команды проекта,

принимающих участие в их выполнении, продолжительность работ и их

количество в течение цикла.

Таблица 3.13 – Распределение операций между членами команды при

применении методологии Crystal Clear

Операция Исполнитель Продолжитель

ность, часы

Количество

на инкремент

1 2 3 4

Сбор требований заказчика Project manager 5

Обсуждение инструментов, Project manager, 3

технологий и графика проекта The project team 2

Составление устава проекта Project manager

Проведение совещания перед

началом реализации

Project manager,

The project team 2 1

Составление плана работ на цикл Project manager 1 1

Коммуникация с заказчиком Project manager 12 1

Проведение осмотра демо-

версии

Project manager,

The project team 3 3

Проведение ретроспективного

анализа проекта

Project manager,

The project team 1 2

Проведение релиза демо-версии Project manager 4 1

Составление отчета о закрытии

проекта

Project manager 2

103

Установим, что при использовании методологии Crystal Clear

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

продолжительностью в один месяц. Особенностью методологии является то,

что она предполагает использование технологии автоматического

регрессионного тестирования [176]. Это означает, что тестированием кода

занимаются сами программисты путем создания специфического

программного обеспечения, и, следовательно, необходимость иметь в

команде Quality assurance engineer исчезает.

Общие трудозатраты членов команды проекта на управление проектом

представлены в таблице 3.14.

Таблица 3.14 – Трудозатраты на управление проектом по методологии

Crystal Clear

В часах

Команда проекта

Трудозатраты, часы

Pro

ject

man

ager

Busi

nes

s an

alyst

Sen

ior

pro

gra

mm

er

Junio

r pro

gra

mm

er

Junio

r pro

gra

mm

er

1 2 3 4 5 6

Подг. этап 12 3 3 3 3

Инкремент 1 30 13 13 13 13

Инкремент 2 30 13 13 13 13

Инкремент 3 30 13 13 13 13

Инкремент 4 30 13 13 13 13

Инкремент 5 30 13 13 13 13

Весь проект 162 68 68 68 68

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

методологии Crystal Clear (таблица 3.15).

104

Таблица 3.15 – Расчет затрат на управление проектом по методологии

Crystal Clear

Команда проекта почасовая

ставка, грн

трудозатраты,

часы

затраты на

управление,

грн

1 2 3 4

Project manager 170 162 27540

Senior programmer 180 68 12240

Business analyst 150 68 10200

Junior programmer 130 68 8840

Junior programmer 130 68 8840

Всего: 434,00 67 660,00

Как видно из таблицы 3.15, общие трудозатраты на управление

проектом составляют 434 человеко-часа, стоимость управления проектом при

использовании методологии Crystal Clear составляет 67 660,00 грн.

3.3.7 Оценка рисков от управления проектом при использовании

методологий PMBOK, PRINCE2, P2M и SWEBOK

Методологии PMBOK, PRINCE2, P2M и SWEBOK по типу относят к

прогнозным методологиям [106,114]. Их применение имеет много общих

черт, и, соответственно, сопряжено со сходными рисками. Данные риски

являются основополагающими при применении представленных

методологий, а риски связанные с индивидуальными особенностями той или

иной методологии достаточно незначительны в сравнении с общими

рисками. В работе приведен расчет общих рисков для методологий PMBOK,

PRINCE2, P2M и SWEBOK.

Основными особенностями применения прогнозных методологий

является предпосылка к детальному планированию на начальном этапе

реализации проекта, что влечет за собой характерные риски при применении

данных методологий, а именно:

－ риски планирования;

－ риски, связанные с несоответствием требованиям заказчика;

105

－ риски, связанные с проектной документацией.

Особенно вероятны риски, связанные с планированием. Исходя из того,

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

любые ошибки или неточности в нем могут иметь достаточно значимые

негативные последствия, такие как несоответствие качества, отклонения по

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

правильно и охватывал все возможные работы проекта, менеджер проекта

должен иметь навыки и опыт планирования, быть внимательным, выполнять

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

достаточный опыт, то риск неточности планирования является одним из

наиболее опасных.

Группа рисков, связанных с требованиями заказчика, включает в себя

риск несоответствия конечного продукта проекта требованиям, а также риск

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

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

будущему продукту проекта, фиксируются еще до начала реализации самого

проекта. Поэтому если требования были поставлены нечетко, полученный

результат может не соответствовать ожидаемому, особенно в случае

отсутствия промежуточных поставок продукта.

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

в которую входят и требования заказчика, является фундаментом, на котором

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

Исходя из этого, возникают следующие риски, связанные с проектной

документацией:

－ неточность/неполнота проектной документации;

－ необходимость переписывать всю проектную документацию в

случае значительных изменений требований заказчика.

Недостаточная детализация требований может стать причиной

возникновения другого риска – несоответствия продукта требованиям.

Изменение требований к проекту и продукту требует внесения изменений в

106

документацию. В свою очередь, внесение изменений в достаточно развитую

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

времени и ресурсов.

Графически риски управления при использовании прогнозных

методологий представлены на рисунке 3.2.

Рисунок 3.2 – Риски управления проектом при использовании

прогнозных методологий

Для ранжирования рисков проекта согласно матрицы вероятности и

последствий (рис. 2.4) при использовании шкалы последствий табл. 2.7

проанализируем каждый из рисков, представленных на рис. 3.2, и составим

таблицу рисков (табл. 3.16).

Таблица 3.16 – Характеристики рисков при использовании прогнозных

методологий

Риск Вероятность возникновения

Уровень последствий

Коэффициент матрицы

1 2 3 4 Несоответствие конечного продукта проекта требованиям заказчика

Маловероятно Катастрофические

2

Невозможность учесть изменение требований заказчика в процессе реализации проекта

Достоверно Критические 2,25

Риски при использовании прогнозных методологий

Связанные с требованиями заказчика

Несоответствие конечного

продукта проекта требованиям заказчика

Невозможность учесть изменение

требований заказчика в процессе реализации проекта

Связанные с проектной

документацией

Неточность / неполнота проектной

документации

Необходимость существенно переделывать проектную

документацию в случае изменений

требований заказчика

Связанные с планированием

Отклонение от целей проекта из-

за неверно составленного

плана

107

Окончание таблицы 3.16

1 2 3 4

Неточность / неполнота проектной

документации Достоверно Критические 2,25

Необходимость существенно

переделывать проектную

документацию в случае изменения

требований заказчика

Маловероятно Критические 1,5

Отклонение от целей проекта из-за

неверно составленного плана Достоверно Умеренные 1,5

Исходя из таблицы 3. 16 общий (суммарный) коэффициент риска

управления проектом при использовании методологий РМВОК, PRINCE2,

P2M и SWEBOK составляет 9,5 единиц.

3.3.8 Оценка рисков от управления проектом при использовании

методологии SCRUM

Методология SCRUM, наряду с методологией Crystal Clear, риски

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

гибким методологиям разработки программного продукта. Применение

данных методологий, как и применение прогнозных, имеют некоторые

общие свойства, а соответственно сопряжено с подобными рисками. Однако

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

влияют на суммарный коэффициент рисков. Поэтому риски, связанные с

применением методологии SCRUM и Crystal Clear, рассмотрим отдельно.

Все риски, связанные с управлением проектом по разработке

программного обеспечения при использовании методологии SCRUM, можно

разделить на несколько групп, исходя из причин их возникновения:

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

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

команды;

риски, возникающие из-за некомпетентности Scrum master;

риски, связанные с тем, что данная методология не предполагает

выполнения целого ряда процессов управления содержанием, сроками,

стоимостью, качеством, рисками и других.

108

Главным и самым разрушительным риском, вызванным частичным

использованием методологии, является невыполнение проекта. В

методологии SCRUM очень важным является соблюдение ее процедур и

ценностей, а именно - постоянная продолжительность спринта, проведение

ежедневных 15-минутных совещаний, проведения ретроспектив после

каждого спринта, а также участие заказчика или его представителя в этих

встречах.

Постоянные изменения продолжительности спринта не позволяют четко

спланировать объем работ, который может быть выполнен за это время, а

следовательно не гарантирует своевременной сдачи всего проекта.

Отказ от проведения ежедневных 15-минутных совещаний приведет к

тому, что нельзя будет отследить эффективность работы команды – как идет

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

установленные сроки, выполняются ли все требования заказчика, есть ли

проблемы, и т.д.

Вследствие отказа от проведения ретроспектив, исчезает возможность

получить обратную связь от заказчика, оценить эффективность работы

команды, а также адаптировать проект к новым требованиям.

Что касается участия заказчика, то оно необходимо на всех стадиях

выполнения проекта, поскольку именно возможность вносить изменения в

проект в процессе его реализации для наиболее полного соответствия

требованиям заказчика лежит в основе методологии SCRUM.

Под рисками, связанными с уровнем квалификации членов команды

проекта, прежде всего, понимается отсутствие опыта работы (как вообще, так

и в данной команде), неспособность команды самоорганизоваться.

Следствием этих рисков является низкое качество продукта проекта.

Не имея предыдущего опыта работы члены команды не могут адекватно

оценить какие именно задачи необходимо выполнить, сколько на это

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

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

109

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

сроков и несоответствие продукта требованиям заказчика.

Методология SCRUM требует от команды проекта способности

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

скрам-мастера о начале работы над следующей задачей, а самостоятельно

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

команды. Если же команда этого не умеет, то использование SCRUM не

будет эффективным, а возможно и наоборот – помешает успешному

выполнению проекта.

Таким образом, некомпетентность команды является вторым по

важности фактором, который может привести к срыву проекта.

Некомпетентность Scrum master может привести к возникновению

следующих рисков:

1 Неэффективное планирование проекта в силу того, что:

－ совещания перед началом каждого спринта и ежедневные скрам-

встречи сфокусированы не на основных целях, а на второстепенных или

совсем малозначимых;

－ задачи на каждый спринт распределяются Scrum master

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

－ в начале проекта составляется неизменный пошаговый план

действий на весь проект;

－ составлены неверные прогнозы относительно процесса реализации

проекта.

2 Неправильное распределение работ между членами команды. При

использовании методологии SCRUM члены команды сами устанавливают

объем работ для себя на следующий спринт перед его началом. Scrum master

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

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

3 Вмешательство Scrum master или заказчика в непосредственную

работу команды проекта. В течение спринта команда проекта работает над

110

определенным перечнем задач, установленным в начале спринта, и члены

команды самостоятельно отслеживают степень их выполнения, обновляют

статус проекта, решают проблемы и т.д. Указания со стороны Scrum master

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

выполнению проекта. Их роль в течение спринта – обеспечивать команду

проекта всеми необходимыми ресурсами и поддержкой в решении вопросов

с внешними организациями.

Низкий уровень квалификации членов команды проекта может

привести к следующим рискам:

1 Неспособность самоорганизоваться. В методологии SCRUM команда

самоорганизуется для выполнения спринта и является самоорганизующейся

и самоуправляемой. Неспособность самоорганизоваться для выполнения

конкретных задач в проекте приводит к тому, что команда не может гибко

реагировать на возникающие проблемы и эффективно выполнять объем

работ спринта.

2 Отсутствие опыта работы. Команда проекта в соответствие с

методологией SCRUM является кроссфункциональной. В нее входят люди с

различными навыками и нет заранее определенных ролей, которые бы

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

отдельных членов команды приводит к неспособности эффективно

выполнять спринт команде в целом.

Еще одним фактором риска является частичное выполнение

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

The Scrum Guide [88] и обусловлена нетипичной организацией процесса,

отсутствием формального лидера и руководителя. Невыполнение этого

условия приводит к тому, что методология не работает вообще или работает

хуже, чем ожидалось.

111

Графически риски проекта при использовании методологии SCRUM

представлены на рисунке 3.3.

Рисунок 3.3 – Риски управления проектом при использовании методологии

SCRUM

Для ранжирования рисков проекта согласно разработанной матрицы

вероятности и последствий (рис. 2.4) и при использовании шкалы

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

на рисунке 3.3, и составим итоговую таблицу рисков 3.17.

Таблица 3.17 – Анализ рисков при использовании методологии SCRUM

Риск Вероятность

возникновения

Уровень

последствий

Коэффициент

матрицы

Частичное использование

методологии Очень вероятно Катастрофически 4

Отсутствие опыта работы Достоверно Критически 2,25

Неспособность к самоорганизации Маловероятно Критически 1,5

Неэффективное планирование Достоверно Критически 2,25

Неправильное распределение работ Маловероятно Умеренно 1

Вмешательство в работу команды Достоверно Умеренно 1,5

Риски SCRUM

Частичное выполнение методологии

Низкий уровень квалификации членов команды

Неспособность самоорганизоваться

Отсутствие опыта работы

Некомпетентность Scrum master

Неэффективное планирование

проекта

Неверное распределение

работ

Вмешательство в непосредственную работу команды

112

Исходя из таблицы 3.17 видно, что общий коэффициент риска

управления проектом при использовании методологии SCRUM составляет

12,5.

3.3.9 Оценка рисков от управления проектом при использовании

методологии Crystal Clear

Риски управления проектом при использовании методологии Crystal

Clear можно разделить на 3 группы:

－ риски, связанные с качеством проекта;

－ риски, связанные с планированием;

－ риски, связанные с заказчиком.

Главным фактором, который может повлиять на качество выполнения

проекта, является почти полное отсутствие проектной документации. Те

документы, которые предусмотрены данной методологией, описывают

проект достаточно кратко и опираются на устную коммуникацию между

членами команды и заказчиком.

Не менее важным фактором является то, что методология Crystal Clear

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

Низкая квалификация членов команды проекта может привести к

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

Так как методология предполагает использование автоматического

регрессионного тестирования, то вся ответственность за разработку

соответствующего программного продукта ложится на программистов.

Низкая самодисциплина и самоорганизация может привести к появлению

ошибок кода, а значит – к созданию некачественного продукта.

В отличие от методологии SCRUM, Crystal Clear не предусматривает

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

Такие совещания проводятся несколько раз в цикл для осмотра

разработанного кода и созданных фрагментов продукта проекта. Таким

образом, к концу цикла или проекта может проявиться критическая ошибка

кода.

113

Рисками, связанными с планированием, являются:

－ ошибки при составлении проектной документации, а именно

неправильное определение целей проекта, его ограничений и критериев

успеха;

－ отклонения от запланированных сроков реализации из-за отсутствия

четкого понимания продолжительности работ;

－ неправильное распределение работ между членами проектной

команды;

－ неверно выбранная технология реализации проекта перед его

началом, так как методология Crystal Clear не имеет единого подхода к

реализации проекта.

Методология Crystal Clear не предусматривает тесное сотрудничество с

заказчиком проекта в течение всего периода его реализации. Как следствие -

возникает риск плохой или недостаточной коммуникации с заказчиком, а

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

требованиям к нему.

Также достаточно серьезным риском является незафиксированный

перечень работ на инкремент. Это означает, что в течение инкремента

заказчик может изменить некоторые из требований, и команда проекта

должна будет сразу учесть эти изменения в разработке кода. Значит, если

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

привести к созданию низкокачественного продукта, или даже срыва всего

проекта.

Графически риски проекта при использовании методологии Crystal

Clear представлены на рисунке 3.4.

114

Рисунок 3.4 – Риски управления проектом при использовании методологии

Crystal Clear

Для ранжирования рисков проекта в соответствии с разработанной

матрицей вероятности и последствий (рис. 2.4) и при использовании шкалы

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

на рисунке 3.4, и составим итоговую таблицу рисков 3.18.

Таблица 3.18 – Анализ рисков при использовании методологии Crystal

Clear

Риск Вероятность

возникновения

Уровень

последствий

Коэффициент

матрицы

1 2 3 4

Плохая коммуникация с

заказчиком Достоверно Критически 2,25

Слишком частые изменения

требований к проекту Достоверно Катастрофически 3

Низкая самоорганизация к

проведению тестирования Маловероятно Критически 1,5

Отсутствие детальной

проектной документации Очень вероятно Умеренно 2

Риски Crystal Clear

Связанные с требованиями заказчиком

Плохая коммуникация с заказчиком

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

Связанные с качеством

Низкая самоорганизация к

проведению тестирования

Отстутсвие детальной проектной

документации

Отсутствие частых совещаний для

выявления ошибок кода

Низкая квалификация

Связанные с планированием

Неверно составлена проектная

документация

Неверное распределение

работ

Неверно выбранная технология

программирования

115

Окончание таблицы 3.18

1 2 3 4

Отсутствие частых

совещаний для выявления

ошибок кода

Очень вероятно Критически 3

Низкая квалификация Достоверно Критически 2,25

Неверно составлена

проектная документация Маловероятно Критически 1,5

Неверный распределение

работ Маловероятно Критически 1,5

Неверно выбранная

технология

программирования

Маловероятно Критически 1,5

Отсутствие фиксированной

продолжительности проекта Достоверно Умеренно 1,5

Исходя из таблицы 3.18 общий коэффициент риска для управления

проектом при использовании методологии Crystal Clear составляет 20. Пять

рисков из десяти рассмотренных являются серьезными и требуют

немедленного реагирования.

3.4 Анализ результатов, полученных при применении метода

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

стоимости управления и сопутствующих рисков

В результате применения метода, описанного в пункте 2.3, к проекту

по разработке компьютерной программы «ForPlan» были получены оценки

трудозатрат при управлении данным проектом, стоимости управления и

рисков при применении методологий PMBOK, PRINCE2, P2M, SWEBOK,

SCRUM и Crystal Clear. Полученные данные нашли свое отражение в

таблице 3.19. Как видно из таблицы наиболее привлекательной по

трудоемкости и стоимости является методология Crystal Clear, однако и риск

при ее применении самый высокий. С меньшим риском можно применять

методологию SCRUM, при этом трудоемкость и стоимость ее применения

остаются достаточно низкими в сравнении с другими рассматриваемыми

методологиями. Среди методологий с минимальным риском применения

можно отметить методологию Р2М, для которой трудоемкость и стоимость

116

применения меньше, чем для SWEBOK, PMBOK, PRINCE2, но существенно

уступают SCRUM.

Таблица 3.19 – Результаты применения метода выбора методологии

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

рисков

Методология

Характеристики проекта

трудозатраты, человеко-

часы

стоимость, грн риски

SWEBOK 2435,2 353 544,00 9,5

PMBoК 2256,9 340 013 9,5

PRINCE2 2146 307 560 9,5

Р2М 1384 209 080 9,5

SCRUM 539 83 080 12

Crystal Clear 434 67 660 20

Решение трёхкритериальной задачи оптимизации для выбора

методологии управления проектом привело к трем эффективным решениям,

соответствующим применению Р2М, SCRUM и Crystal Clear.

Анализируя применение метода выбора методологии управления

проектом на основе существующих рекомендаций и метода выбора

методологии управления проектом с точки зрения трудозатрат, стоимости

управления, а также сопутствующих рисков можно сделать вывод, что

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

компьютерной программы «ForPlan» являются три методологии – Crystal

Clear, SCRUM и Р2М. Рекомендации обоих методов совпали.

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

должно делать лицо, принимающее решение, исходя из личного понимания

ситуации и имеющихся приоритетов. В нашем случае экспертами было

отдано предпочтение методологиям SCRUM и Crystal Clear. Приведем

сравнение отобранных методологий с методологией SWEBOK, которая

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

международного общества IEEE Computer Society. Применение методологии

SCRUM даст возможность сократить трудозатраты на управление по

117

сравнению с методологией SWEBOK на 77,9%, уменьшить стоимость

управления на 76,5%, но приведет к увеличению рисков на 26,3%.

Применение методологии Crystal Clear позволит уменьшить трудозатраты на

управление по сравнению с методологией SWEBOK на 82,2%, стоимость

управления будет снижена на 80,9%, однако эти достижения будут

сопровождаться увеличением рисков на 110,5%. Методология Р2М была

отвергнута, поскольку существенно превосходила указанные по стоимости и

трудозатратам.

Выводы к разделу 3

1. Рассмотрен проект по созданию компьютерной программы для

планирования и прогнозирования развития предприятия «ForPlan», для

которого предлагается применить методы выбора методологии управления

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

разработки программы, описаны особенности разработки и сфера

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

разработки, описаны должностные инструкции и указан уровень

квалификации сотрудников.

2. Применен метод выбора методологии управления проектом на

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

на вопросы анкеты относительно рассматриваемого проекта. На основе

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

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

3. Применен метод выбора методологии управления проектом с точки

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

4. Рассмотрено применение для управления проектом следующих

методологий и стандартов: PMBOK, PRINCE2, P2M, SWEBOK, SCRUM и

Crystal Clear. Составлены списки операций, регламентируемых данными

методологиями, для управления проектом «ForPlan», экспертным путем

оценены длительности предложенных операций и произведено

распределение операций между командой проекта.

118

5. Рассчитаны трудозатраты и стоимости управления проектом

«ForPlan» с применением методологий PMBOK, PRINCE2, P2M, SWEBOK,

SCRUM и Crystal Clear.

6. Рассчитан коэффициент риска, который возможен при применении

методологий PMBOK, PRINCE2, P2M, SWEBOK, SCRUM и Crystal Clear.

7. Проведен анализ полученных результатов, сопоставлены

результаты применения двух методов выбора методологии для управления

проектом «For Plan», рекомендации которых совпали.

8. Основные результаты раздела опубликованы в работе [6,7,10]

119

РАЗДЕЛ 4

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

ОПТИМИЗАЦИИ СОДЕРЖАНИЯ ПРОЕКТА

4.1 Программное обеспечение для многокритериальной оптимизации

содержания проекта «ScopePro»

В соответствии с методом многокритериальной оптимизации

содержания проекта, изложенным в пункте 2.4, создано программное

обеспеченье «ScopePro».

Приложение представляет собой кроссплатформенное решение с

двухуровневой архитектурой, состоящей из графического клиента и базы

данных. Графический клиент реализован в среде разработки Eclipse на языке

программирования Java и имеет трехслойную архитектуру, где каждый слой

представлен соответствующим модулем: модуль доступа к данным, модуль

расчета математической модели, модуль представления. На рисунке 4.1

представлена UML диаграмма компонентов, которая отражает взаимосвязь

между основными архитектурными элементами приложения.

Рисунок 4.1 – Диаграмма компонентов

Данный продукт представляет собой Desktop приложение,

предоставляющее графический интерфейс для ввода и редактирования

характеристик проекта, его этапов и связанных с ними альтернатив, с

120

дальнейшей возможностью решения поставленной задачи оптимизации. Ход

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

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

данные по проектам с возможностью дальнейшей их обработки.

На рисунке 4.2 представлена UML диаграмма вариантов использования

приложения.

Рисунок 4.2 – Диаграмма вариантов использования

Хранение данных осуществляется с помощью СУБД MySQL.

Логическая схема данных приведена на рисунке 4.3.

121

Рисунок 4.3 – Логическая схема данных

Под каждую бизнес-сущность выделена соответствующая одноименная

таблица, хранящая все необходимые данные: Проект (Project), Этап (Stages),

Альтернативный вариант (StagesVariants), Работа (Work), Результат решения

(OptimalVatiant).

4.2 Описание интерфейса программного обеспечения «ScopePro»

Работа пользователя с приложением возможна при выполнении

следующих минимальных требований к рабочему месту:

－ процессор с тактовой частотой не менее 1.0 ГГц;

－ оперативная память объемом не менее 1024Мб;

－ свободное место на диске не менее 300 МБ;

－ операционная система – Microsoft Windows XP и выше;

－ СУБД MySQL 5.1 и среда выполнения Java JRE 1.6.

После запуска программы на экране появляется главная форма (рис.

4.4.)

122

Рисунок 4.4 – Окно главной формы

Для создания нового проекта необходимо выбрать Project -> New

project. Появится первая форма создания проекта. Данная форма

представлена на рисунке 4.5.

Рисунок 4.5 – Первая форма создания проекта

Название проекта вводится в заголовок – Title. В поле Stage вводятся

номера этапов, определенных в проекте, а в поле Variants – количество

альтернативных вариантов выполнения соответствующего этапа проекта.

Чтобы добавить/удалить строку для ввода этапа нужно нажать знак «+/-».

После того, как все перечисленные данные введены – можно перейти

ко второй форме (рис. 4.6).

123

Рисунок 4.6 – Вторая форма создания проекта

На представленной форме нужно указать количество работ в каждом

альтернативном варианте каждого этапа. Для этого выбираем этап в таблице

Stages, и во второй таблице указываем количество работ в каждом варианте

выбранного этапа.

После того, как все работы указаны, переходим к третьей форме (рис.

4.7).

Рисунок 4.7 – Третья форма создания проекта

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

альтернативному варианту. Значение WorkID генерируется автоматически, в

зависимости от того, сколько работ в каждом варианте. В поле Work

указывается название работы (значение может быть символьное или

числовое). В поле Next workID задается WorkID последующей работы, с

которой связана эта работа.

124

После того, как описаны все связи – можно перейти к четвертой форме

создания проекта (рис. 4.8).

Рисунок 4.8 – Четвертая форма создания проекта

На четвертой форме создания проекта размещено: выпадающий список

«Stage» и четыре таблицы для ввода данных.

В верхней таблице слева задаются значения: объем денежных средств

(Amount of money) и остаточная стоимость выбывающих основных фондов

(Depreciated cost).

В верхней таблице справа задаются значения: спроса на продукт

(Product demand) и стоимости продукта (Product cost). Прогнозные данные

вводятся на три года.

В таблице Current cost должны содержаться данные текущих затрат,

прогнозируемых на три года по каждому альтернативному варианту

выполнения этапа.

В таблице Production capacity содержатся прогнозные значения

производственной мощности по вариантам.

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

создания проекта (рис. 4.9).

125

Рисунок 4.9 – Пятая форма создания проекта

На пятой форме необходимо ввести значения основных характеристик

каждого альтернативного варианта выполнения этапа проекта, таких как:

продолжительность этапа (Stage duration), стоимость этапа (Variant cost),

нормированный показатель качества выполнения (Quality value), вероятность

наступления рискового события (Probability of a risk event) и негативные

последствия наступления рискового события, выраженные в баллах от нуля

до единицы (The negative effects of risk event). Три последние перечисленные

характеристики должны изменяться на интервале от нуля до единицы.

Дробные значения характеристик вводятся через точку.

Если данные были введены некорректно - появится информационное

окно ошибки, которое представлено на рисунке 4.10.

Рисунок 4.10 – Сообщение об ошибке при введении некорректных

данных

126

После создания проекта просмотреть или откорректировать данные по

нему можно на главной форме (рис. 4.4). Детальное описание формы

представлено на рисунках 4.11 – 4.18.

На главной форме приведены четыре вкладки с основными данными по

проекту (рис. 4.11) Main data, Additional data, Work & Relations и Solution.

Рисунок 4.11 – Основные вкладки главной формы

Во вкладке Main data представлены три таблицы с данными. Первая

таблица выводит такие данные, как: этап (Stage), количество вариантов на

каждом этапе (Quantity of variants), количество денег, которые выделяются на

каждый этап (Quantity of money) и остаточная стоимость основных фондов

(Remaining cost). Первая таблица представлена на рисунке 4.12.

Рисунок 4.12 – Данные из первой таблицы вкладки Main data

Вторая таблица выводит данные о спросе (Demand), стоимость

продукта (Cost) и производственную мощность (Capacity), которые

прогнозируются на 3 года (рис. 4.13).

127

Рисунок 4.13 – Данные из второй таблицы вкладки Main data

Последняя таблица Current expenses выводит текущие расходы

(рис.4.14). Здесь хранятся прогнозируемые текущие расходы каждого

варианта на три года.

Рисунок 4.14 – Данные таблицы Current expenses

вкладки Main data

Во второй и третьей таблицах есть возможность редактировать и

сохранять данные, нажав кнопку Save.

Следующая вкладка Additional data представлена на рисунке 4.15.

Рисунок 4.15 – Вкладка Additional data

В данной вкладке находится выпадающий список «Stage» и таблица

Coefficient. В выпадающем списке можно выбрать один из этапов и

128

посмотреть значение всех характеристик каждого варианта альтернативного

выполнения проекта.

Следующая вкладка Work & Relations представлена на рисунке 4.16.

Рисунок 4.16 – Вкладка Work & Relations

На приведенной вкладке есть выпадающий список «Stage» и «Variant».

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

Последняя вкладка - это Solution. В ней представлены данные,

полученные в результате оптимизации проекта. А именно: прибыль (Profit)

от реализации проекта, стоимость (Cost) выполения проекта,

продолжительность (Duration) всех этапов проекта, качество (Quality) и

риски (Risks) по проекту, цепочку вариантов (Chain of variants) и значение

уступок (Concessions). Вкладка Solution представлена на рисунке 4.17.

Рисунок 4.17 – Вкладка Solution

129

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

боковое меню главной формы Choose project (рис 4.18).

Рисунок 4.18 – Боковое меню главной формы

Созданные и сохраненные проекты можно удалить (Delete project) или

провести оптимизацию содержания проекта (Optimize).

После нажатия кнопки «Optimize» на экране появляется окно (рис.

4.19) с полями для введения уступок по критериям стоимость (Cost), прибыль

(Profit), качество (Quality), риски (Risk) и максимально допустимое время

длительности всего проекта (Maximum time that need to fulfill the project)

Рисунок 4.19 – Форма введения уступок

Если какая-то уступка не проходит, появляется окно коррекции этой

уступки, которое представлено на рисунке 4.20

130

Рисунок 4.20 – Окно коррекции уступки

Когда все данные и все уступки введены корректно, оптимизированный

проект выводится во вкладку Solution (рис. 17) Также можно отследить ход

выполнения расчетов в логе программы, который сохраняется в отдельном

файле (рис 4.21).

Рисунок 4.21 – Содержимое лог-файла

Если же проект не имеет решения, то на экране появится

информационное окно ошибки, которое представлено на рисунке 4.10.

131

4.3 Подготовка входных данных для решения задачи

оптимизации содержания проекта

Для выбора методологии управления ИT проектом предлагается

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

управления им конкретной методологии. Как уже отмечалось ранее – для

сокращения трудоемкости исследования целесообразно сделать

предварительный выбор небольшого числа методологий, например, двух-

трех, с помощью методов, описанных в пунктах 2.2 и 2.3. Когда список

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

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

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

были выбраны методологии – Crystal Clear, SCRUM и Р2М. Однако, Р2М

существенно уступает двум остальным методологиям по трудоемкости и

стоимости применения. И поэтому ее не будем рассматривать в дальнейшем.

В результате для решения задачи оптимизации содержания проекта

были выбраны две методологии из указанных – SCRUM и Crystal Clear.

Немаловажно, что эти две методологии предназначены для управления

именно ИT-проектами. Также следует отменить, что для выбора методологии

управления проектом «ForPlan» на основе оптимизации содержания проекта

выбрана математическая модель, включающая пять критериев: прибыль,

сроки, стоимость, качество, риски. В данной задаче такие критерии как:

технологический, экологический, социально-политический эффекты не

учтены, в силу того, что осуществление рассматриваемого проекта мало или

совсем не затрагивает указанные сферы.

На начальном этапе процедура решения задачи заключается в

расположении всех критериев в порядке их относительной важности. Далее

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

На основе данных о проекте (приложение А) были сформированы

исходные данные для решения задачи.

132

Проект имеет 5 этапов, на каждом из которых предложено 3

альтернативных варианта осуществления операций. В таблицах 4.1 и 4.2

представлена информация о финансовых средствах, выделяемых на каждый

этап (Кh), о количестве альтернативных вариантов выполнения работ на

каждом этапе (Мh), о времени (t hj), которое необходимо для реализации

каждого варианта на каждом этапе. Информация представлена для случаев

применения методологий: Scrum – табл. 4.1 и Crystal Clear – табл. 4.2.

Таблица 4.1 – Исходные данные для расчета при использовании

методологии Scrum

Этап 1 Этап 2 Этап 3 Этап 4 Этап 5

h = 1 h = 2 h = 3 h=4 h=5

K1 = 60 тыс. грн K2 = 46 тыс. грн K3=50 тыс. грн К4=50 тыс.грн К5=45 тыс. грн

М1 = 3 М2 = 3 М3 = 3 М4 = 3 М5 = 3

t11 = 35,5 дня t21 = 23,5 дня t31 = 23,3 дня t41 = 23,3 дня t51 = 17 дней

t12 = 41 день t22 = 24 дня t32= 23,1 дня t42 = 23,1 дня t52 = 23,8 дня

t13 = 29,3 дня t23 = 23,5 дня t33= 24,8 дня t43 = 24,8 дня t53 = 13,3 дня

Таблица 4.2 – Исходные данные для расчета при использовании

методологии Crystal Clear

Этап 1 Этап 2 Этап 3 Этап 4 Этап 5

h = 1 h = 2 h = 3 h=4 h=5

K1 = 60 тыс.грн K2 = 46 тыс.грн K3=50 тыс. грн К4=50 тыс. грн К5=45 тыс. грн

М1 = 3 М2 = 3 М3 = 3 М4 = 3 М5 = 3

t11 = 33 дня t21 = 20,5 дня t31 = 21,7 дня t41 = 21,6 дня t51 = 15,5 дня

t12 = 40,5 дня t22 = 20,5 дня t32= 21,2 дня t42 = 21,2 дня t52 = 22,75 дня

t13 = 29,6 дня t23 = 20,8 дня t33= 23,5 дня t43 = 23,5 дня t53 = 11 дней

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

варианта на определенном этапе, использовалась система управления

проектами MSProject 2007, в которую были записаны все операции,

связанные с разработкой компьютерной программы и операции по

управлению, предполагаемые методологиями Scrum и Crystal Clear.

Составлены диаграммы Гантта (рисунок 4.22 )

133

Рисунок 4.22 - Диаграмма Гантта для первого варианта пятого этапа

при применении методологии Scrum

Остаточная стоимость выбывающих основных фондов при

осуществлении на h-м этапе j-го варианта (Е hj) в рассматриваемом проекте

равна нулю, h=1,5, j=1,3.

В табл. 4.3 и 4.4 содержится информация об общей стоимости

выполнения операций j-го варианта на h-м этапе данного проекта. Для

расчета стоимости варианта (w hj) в среде MSProject были введены и

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

определенной работы.

Таблица 4.3 –Исходные данные о стоимости выполнения операций на

h-м этапе для j-го варианта выполнения при использовании методологии

Scrum, тыс. грн

Этап 1 Этап 2 Этап 3 Этап 4 Этап 5

w11 =59,3 w21 =45,3 w31 =49,01 w41 =49,01 w51 = 49,1

w12 =57,1 w22 = 45,7 w32 = 48,9 w42 = 48,9 w52 = 43,3

w13 = 59,4 w23 = 45,3 w33 = 49,1 w 43 = 49,1 w 53 = 40,6

Таблица 4.4 – Исходные данные о стоимости выполнения операций на

h-м этапе для j-го варианта выполнения при использовании методологии

Crystal Clear, тыс. грн

Этап 1 Этап 2 Этап 3 Этап 4 Этап 5

w11 =50,3 w21 =37,1 w31 =42,3 w41 =42,3 w51 = 37,2

w12 =48,1 w22 = 37,1 w32 = 42,2 w42 = 42,2 w52 = 36,05

w13 = 48,7 w23 = 37,1 w33 = 42,2 w 43 = 42,2 w 53 = 37,7

134

Данные о показателях качества продукта представлены в табл. 4.5 и 4.6,

а о показателях рисков – в табл. 4.7 и 4.8 для методологии Scrum и Crystal

Clear, соответственно.

Таблица 4.5 – Значения показателей качества продукта при

использовании методологии Scrum Этап 1 Этап 2 Этап 3 Этап 4 Этап 5

Ψ111 = 0,58 Ψ211 = 0,75 Ψ311 = 0,48 Ψ411 = 0,48 Ψ511 = 0,38

Ψ121 = 0,62 Ψ221 = 0,28 Ψ321 = 0,48 Ψ421 = 0,48 Ψ521 = 0,58

Ψ131 = 0,54 Ψ231 = 0,7 Ψ331 = 0,53 Ψ431 = 0,53 Ψ531 = 0,6

Таблица 4.6 – Значения показателей качества продукта при

использовании методологии Crystal Clear Этап 1 Этап 2 Этап 3 Этап 4 Этап 5

Ψ111 = 0,49 Ψ211 = 0,88 Ψ311 = 0,36 Ψ411 = 0,36 Ψ511 = 0,16

Ψ121 = 0,58 Ψ221 = 0,51 Ψ321 = 0,36 Ψ421 = 0,36 Ψ521 = 0,64

Ψ131 = 0,54 Ψ231 = 0,91 Ψ331 = 0,36 Ψ431 = 0,36 Ψ531 = 0,58

Таблица 4.7 – Значения показателей рисков при использовании

методологии Scrum Этап 1 Этап 2 Этап 3 Этап 4 Этап 5

Θ111= 0,12 Θ211 = 0,25 Θ311 = 0,08 Θ411 = 0,08 Θ511 = 0,04

Θ121 = 0,15 Θ221 = 0,02 Θ321 = 0,08 Θ421 = 0,08 Θ521 = 0,12

Θ131 = 0,11 Θ231 = 0,1 Θ331 = 0,1 Θ431 = 0,1 Θ531 = 0,14

Таблица 4.8 – Значения показателей рисков при использовании

методологии Crystal Clear Этап 1 Этап 2 Этап 3 Этап 4 Этап 5

Θ111= 0,08 Θ211 = 0,42 Θ311= 0,04 Θ411 = 0,04 Θ511 = 0,04

Θ121 = 0,12 Θ221 = 0,09 Θ321 = 0,04 Θ421 = 0,04 Θ521 = 0,16

Θ131 = 0,1 Θ231 = 0,49 Θ331 = 0,04 Θ431= 0,04 Θ531 = 0,12

Показатель рисков Θhji оценивает риск i-го рискового события на h-м

этапе проекта при реализации j-го альтернативного варианта, Ii ,1 . Он равен

произведению вероятности появления этого рискового события Phji на

оценку негативных последствий от его наступления Vhji .

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

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

такой подход достаточно неточный и неудобный. В этом случае нельзя

избежать некоторой субъективности, а при большом количестве этапов и

альтернатив еще и серьезных трудозатрат при анализе каждой альтернативы.

135

Для предложенной задачи критерием качества продукта предлагается

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

альтернативе. Полагаем, что идеальное качество продукта получаем лишь в

том случае, если операции этапа идут последовательно одна за другой. В

этом случае все внимание команды проекта и все ресурсы концентрируются

на одной операции. При этом может быть организовано высокоэффективное

управление качеством, специализированное на конкретной операции.

Предполагается, что задачи только с последовательной связью обеспечат

идеальное качество, равное единице. Полагаем, что любое разветвление в

сетевой модели ведет к потере качества продукта.

Показатель качества будем оценивать следующим образом:

ps

ps

NN

NMN

)( , (4.1)

где – количество последовательных задач в этапе;

M – пенальти по качеству;

pN – количество параллельных задач в этапе.

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

операции этапа, выполняемой параллельно с другой операцией.

Размер пенальти рассчитывается следующим образом:

ps

s

NN

NM

. (4.2)

Рассматривается один тип рисков, а именно, срыв сроков по

выполнению конкретного этапа. В качестве критерия риска, в данном

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

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

задач расположено последовательно, тем выше вероятность того, что

увеличение продолжительности одной задачи приведет к увеличению

s

136

продолжительности всего этапа. Наоборот – при параллельном выполнении

операций такая вероятность снижается.

Формулы для расчета рисков:

ps

spp

NN

NMN

)(1 (4.3)

где pM – пенальти по рискам.

ps

p

PNN

NM

(4.4)

В табл. 4.9 и 4.10 представлена общая исходная информация для

проекта, не зависящая от используемой методологии.

В табл. 4.9 представлены данные о спросе В и о цене на компьютерную

программу С.

Таблица 4.9 – Исходные данные о спросе и цене

Показатели Годы

1 год 2 год 3 год

В, шт. 4 5 6

С, тыс. грн 170 170 170

За первый год фазы производства, реализации и поддержки продукции

планируется продать 4 компьютерных программы. На второй и на третий – 5

и 6, соответственно.

Исходные данные о производственной мощности представлены в табл.

4.10

137

Таблица 4.10 – Исходные данные о производственной мощности, )(l

tA , шт

Варианты Годы

1 год 2 год 3 год

1 4 5 6

2 4 5 6

3 4 5 6

Текущие расходы в течение фазы производства, реализации и

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

проекта и коммунальных платежей. В рассматриваемом проекте текущие

расходы не зависят от варианта выполнения операций на любом из пяти

этапов проекта, от номера этапа и от года. Они составляют 573,3 тысячи

гривен.

Собранная информация была применена для оптимизации содержания

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

Scrum или Crystal Clear.

4.4 Результаты решения задачи оптимизации содержания

проекта, для управления которым применяется методология Scrum

При решении задачи критерии были проранжированы в следующем

порядке: прибыль, стоимость, риски, качество и время. Была проведена серия

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

выполнения проекта 120 дней. Уступки задавались с помощью вектора С*

=

(с1*, с2*, с3*, с4*), где сi* значение уступки, выраженное в процентах, с1* –

уступка по прибыли, с2* – уступка по стоимости, с3* – уступка по рискам, с4*

- уступка по качеству.

Первый набор уступок включает только нули. Это означает, что при

оптимизации содержания проекта по стоимости вводится ограничение,

требующее, чтобы прибыль была не хуже, чем в результате оптимизации по

прибыли. При оптимизации по рискам сохраняется тоже ограничение по

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

не больше, чем при оптимизации по стоимости. При оптимизации по

138

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

ограничение, предполагающее, что риски будут не хуже, чем при

оптимизации по рискам. Наконец, при оптимизации времени аналогично

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

ограничение, требующее, чтобы качество было не хуже, чем при

оптимизации по качеству. Тем самым поиск решения привязывается к

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

На рисунке 4.23 представлена экранная форма результата решения

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

применяется методология Scrum.

Рисунок 4.23 – Решение задачи с вектором уступок С* = (0, 0, 0, 0)

Результирующие значения целевых функций рисков и качества равны

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

по всем этапам. Для качества – это нормированные значения. Значения

показателей качества и рисков, соответствующие выбранной комбинации

альтернатив, представлены в табл. 4.11.

139

Таблица 4.11 – Значения оптимальных показателей качества и рисков

на каждом из этапов при использовании методологии Scrum, С* = (0, 0, 0, 0)

Значения

критериев

оптимиза-

ции

Этап 1,

альтернатива

1

Этап 2,

альтернатива

1

Этап 3,

альтернатива

2

Этап 4,

альтернатива

2

Этап 5,

альтернатив

а 3

Качество 0,58 0,75 0,48 0,48 0,60

Риски 0,12 0,25 0,08 0,08 0,14

Второй расчет сделан для вектора уступок С* = (1, 1, 1, 1) (рис. 4.24).

Последовательность решения задач оптимизации оставлена прежней.

Рисунок 4.24 – Решение задачи с вектором уступок С* = (1, 1, 1, 1)

В табл. 4.12 приведены значения рисков и качества для выбранных

альтернатив.

Таблица 4.12 – Значения оптимальных показателей качества и рисков на

каждом из этапов при использовании методологии Scrum, С* = (1, 1, 1, 1)

Значения

крите-

риев

оптимиза

ции

Этап 1,

альтернатива

3

Этап 2,

альтернатива

1

Этап 3,

альтернатива

3

Этап 4,

альтернатива

3

Этап 5,

альтернатива

3

Качество 0,54 0,75 0,53 0,53 0,60

Риски 0,11 0,25 0,10 0,10 0,14

В сводной таблице (табл. 4.13) приведены результаты двух оптимизаций

с различными векторами уступок. Как видно из таблицы, решение с

140

большими уступками отличается лучшим качеством (меньше значения

показателя) и меньшей длительностью, однако незначительно проигрывает

по остальным показателям.

Таблица 4.13 – Результаты решения при разных векторах уступок при

использовании методологии Scrum

Целевые функции Вектор уступок

С* = (0, 0, 0, 0) С* = (1, 1, 1, 1)

Прибыль, тыс. грн 438.0 437.5

Затраты, тыс. грн 243.0 243.5

Риски, баллы 0.67 0,6800

Качество, баллы 1.83 1.702

Длительность всего

проекта, дни 119 116

Табл. 4.14 отражает соотношение результатов решений. Значения,

полученные для вектора уступок С*

= (1, 1, 1, 1), выражены в процентном

отношении от результатов, полученных для вектора С* = (0, 0, 0, 0). Как

видно из табл. 14, интегральное значение нормированного показателя

качества уменьшилось на 7 % (т.е. улучшилось).

Таблица 4.14 – Таблица соотношения результатов решений при

использовании методологии Scrum

Целевые функции Вектор уступок

С* = (0, 0, 0, 0) С* = (1, 1, 1, 1)

Прибыль, тыс. грн 100 99,8858

Затраты, тыс. грн 100 100,2058

Риски, баллы 100 101,4925

Качество, баллы 100 93,0055

Длительность всего проекта, дни 100 97,4790

Результаты, приведенные в табл. 4.14, можно более наглядно отразить

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

141

Рисунок 4.25 – Соотношение значений критериев оптимизации с

использованием методологии Scrum

Диаграмма (рис.4.25) отражает соотношения результатов решений.

4.5 Результаты решения задачи оптимизации содержания проекта,

для управления которым применяется методология Crystal Clear

Как и для представленной выше методологии Scrum, для методологии

Crystal Clear был проведен ряд аналогичных экспериментов при тех же

исходных данных, с векторами уступок С* = (0, 0, 0, 0) и С

* = (1, 1, 1, 1) при

ограничении по длительности проекта, равном 120 дням. В табл. 4.15-4.17 и

на рис. 4.26 – 4.28 представлены результаты вычислений и их анализа.

Рисунок 4.26 – Решение задачи с вектором уступок С* = (0, 0, 0, 0)

90,0000

92,0000

94,0000

96,0000

98,0000

100,0000

102,0000 Прибыль

Затраты

Качество Риски

Длительность

всего проекта

уступка 0 %

уступка 1,0 %

142

Таблица 4.15 – Значения оптимальных показателей качества и рисков на

каждом из этапов при использовании методологии Crystal Clear, С* =(0,0,0,0)

Значения

критериев

оптимиза-

ции

Этап 1,

альтернатива

3

Этап 2,

альтернатива

3

Этап 3,

альтернатива 2

Этап 4,

альтер

натива

2

Этап 5,

альтернатива 2

Качество 0,54 0,91 0,36 0,36 0,64

Риски 0,10 0,49 0,04 0,04 0,16

Рисунок 4.27 – Решение задачи с вектором уступок С* = (1, 1, 1, 1)

Таблица 4.16 – Значения оптимальных показателей качества и рисков

на каждом из этапов при использовании методологии Crystal Clear,

С* = (1, 1, 1, 1)

Значения

крите-

риев

оптимиза

ции

Этап 1,

альтернатива

3

Этап 2,

альтернатива

3

Этап 3,

альтернатива

2

Этап 4,

альтернатива

2

Этап 5,

альтернати

ва 2

Качество 0,54 0,91 0,36 0,36 0,64

Риски 0,10 0,49 0,04 0,04 0,16

Как следует из рис. 2.25 и 2.26, решения для двух векторов уступок не

отличаются. В таблице 4.17 представлены результаты решения при

использовании методологии Crystal Clear.

143

Таблица 4.17 – Таблица результатов решений при использовании

методологии Crystal Clear

Целевые функции Значения показателей

Прибыль, тыс. грн 474.75

Затраты, тыс. грн 206.25

Риски, баллы 0.83

Качество, баллы 2.32

Длительность всего проекта, дни 116

В результате исследования можно сделать следующие выводы. При

значении ветора уступок С* = (0, 0, 0, 0) применение методологии Crystal

Clear по сравнению c методологии Scrum позволяет увеличить прибыль на

8,39% и сократить затраты на проект на 15,12%, сократить длительность на

2,52%. Однако при этом будет получено худшее качество продукта (на

26,78%) и проект будет сопряжен с большими рисками (на 23,88%). При

значении ветора уступок С* = (1, 1, 1, 1) прибыль увеличится на 8,51%,

затраты уменьшатся на 15,29%, качество ухудшится на 36,31% и риск

увеличится на 22,06%. Время выполнения проекта в данном случае не будет

зависеть от применяемой методологии.

4.6 Анализ устойчивости решений задачи оптимизации

содержания проекта

При анализе устойчивости решения задачи оптимизации необходимо

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

значения целевых функций и на выбранный вектор решений в результате

оптимизации. Для этого проследим, как отклонение значений исходных

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

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

проекта. Решение, полученное для исходных данных, представленных в табл.

4.1-4.10, в дальнейшем будем называть детерминированным.

В результате исследования сможем оценить:

144

1) с какой вероятностью значение каждого из показателей (прибыль,

стоимость, время, риски и качество продукта) может находиться в заданном

диапазоне;

2) какова вероятность того, что тот или иной вектор альтернатив будет

оптимальным при изменении исходных данных.

Ввиду сложности реализации аналитического анализа устойчивости

оптимальных решений для задачи (2.4 – 2.21), было принято решение

провести анализ устойчивости по методу Монте-Карло. Каждый эксперимент

представляет собой решение задачи оптимизации содержания проекта для

случайных входных данных. В качестве случайных переменных будем

рассматривать следующие исходные данные:

Kh финансовые средства, которые выделяются для осуществления

операций на этапе h;

jhi

время выполнения на этапе h операции i в соответствии с j-м

альтернативным вариантом;

hiw стоимость выполнения на этапе h операции i в соответствии с j-м

альтернативным вариантом;

hjr – значение r-го показателя качества продукта h-го этапа проекта в

результате выполнения j-го альтернативного варианта;

Phji вероятность появления на h-м этапе проекта при реализации j-го

альтернативного варианта i-го рискового события, Ii ,1 ;

)(ltB спрос на продукцию в году t;

)(ltC стоимость продукции i-го вида в t-ом году.

Выбранные значения принимаем в качестве математического ожидания

случайного числа, распределенного по нормальному закону.

Среднеквадратическое отклонение σ принимаем равным 0,15 от значения

математического ожидания. Выбор такого значения среднеквадратического

отклонения объясняется представлениями экспертов о возможной

неточности исходных данных в рассматриваемой задаче. Обращаемся к

145

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

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

накапливаем для дальнейшего анализа.

Далее накопление и анализ данных для задачи оптимизации содержания

проекта при применении методологий Scrum и Crystal Clear проводим для

уступки 1 % по всем критериям, с ограничением по времени проекта, равным

120 дням.

Для проведения экспериментов была реализована дополнительная

функциональность в программе «ScopePro», которая автоматически

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

отдельный CSV-файл. Для каждой из двух методологий было проведено 100

экспериментов. Полученные результаты были импортированы в Excel и

дополнительно обработаны для дальнейшего анализа. Из 100 проведенных

экспериментов 63 % имели решение для методологии Scrum и 79 % для

методологии Crystal Clear. Для каждого критерия был определен диапазон

изменения, который в дальнейшем был разбит на 6 поддиапазонов, и для

каждого поддиапазона было подсчитано количество решений, попавших в

него.

Для наглядности полученные результаты показаны в виде гистограмм

для Scrum (рис. 4.28 – 4.32) и Crystal Clear (рис. 4.33 – 4.37), где

горизонтальная ось представляет собой интервалы значений

соответствующего критерия, а вертикальная ось – количество попаданий в

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

позволяет оценить вероятности попадания значения в заданный поддиапазон.

Полагаем, что для экспериментов, которые не имеют решения, значения не

попадают ни в один из представленных интервалов.

146

Рисунок 4.28 – Гистограмма распределения стоимости проекта при

использовании методологии Scrum

Рисунок 4.29 – Гистограмма распределения прибыли проекта при

использовании методологии Scrum

Рисунок 4.30 – Гистограмма распределения качества проекта при

использовании методологии Scrum

4

6

28

20

2 3

0

5

10

15

20

25

30

[185,15-196,02) [196,02-206,89) [206,89-217,76) [217,76-228,63) [228,63-239,5) [239,5-250,37)

Ко

ли

чес

тв

о р

ешен

ий

Стоимость, тыс. грн

9

21

12 13

6

2

0

5

10

15

20

25

[5,95-159,99) [159,99-314,04) [314,04-468,08) [468,08-622,12) [622,17-776,17) [776,17-930,21)

Ко

ли

чес

тв

о р

ешен

ий

Прибыль, тыс. грн

5 6

18 19

10

5

0

2

4

6

8

10

12

14

16

18

20

[0,63-1,17) [1,17-1,71) [1,71-2,24) [2,24-2,78) [2,78-3,32) [3,32-3,85)

Ко

ли

чес

тв

о р

ешен

ий

Качество, баллы

147

Рисунок 4.31 – Гистограмма распределения рисков проекта при

использовании методологии Scrum

Рисунок 4.32 – Гистограмма распределения времени выполнения

проекта при использовании методологии Scrum

Основываясь на информации, представленной на рис. 4.28 – 4.32, можем

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

Для наглядности добавим в таблицу значения детерминированных

решений, полученных для исходных данных, и отклонения

детерминированных решений в процентах. Также представим доверительные

интервалы для средних значений, которые рассчитаны при уровне

значимости 95%.

4

10

19

13

7

10

0

2

4

6

8

10

12

14

16

18

20

[0,31-0,38) [0,38-0,46) [0,46-0,54) [0,54-0,61) [0,61-0,69) [0,69-0,77)

Ко

ли

чес

тв

о р

ешен

ий

Риски, баллы

1 3

5 4

12

38

0

5

10

15

20

25

30

35

40

[105-108) [107,5-110) [110-112,5) [112,5-115) [115-117,5) [117,5-120)

Ко

ли

чес

тв

о р

ешен

ий

Время, дни

148

Таблица 4.18 – Сравнение результатов оптимизации содержания

проекта, полученных для детерминированных и стохастических исходных

данных (Scrum)

Название показателя Критерии оптимизации

прибыль стоимость риски качество время

Средние значения 360,4 215,4 0,55 2,3 116,8

Детерминированное

решение

437,5 243,5 0,7 1,702 116

Отклонение от

среднего значения,%

21 13 28 -26 -1

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

360,4 51,62

215,43,10

0,550,03 2,30,18 116,80,87

Как видно из таблицы 4.18, изменения исходных данных дают решения,

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

рисками, но в то же время приносят меньше прибыли и обеспечивают

худшее качество. Время проекта практически не подвержено изменению.

Доверительный интервал показывает диапазон, в который с вероятностью

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

данных c , равной 0,15 от значения этих данных. Как следует из таблицы

4.18 наиболее изменчива прибыль ( 14,32%). Далее по уровню изменчивости

следует качество (7,8%), риски (5,46%), стоимость (14,4%). Наиболее

устойчивым к изменению исходных данных оказалось время (0,74%).

Рисунок 4.33 – Гистограмма распределения стоимости проекта при

использовании методологии Crystal Clear

4

12 12

28

16

7

0

5

10

15

20

25

30

[155,89-164,43) [164,44-172,97) [172,98-181,51) [181,52-190,06) [190,07-198,6) [198,61-207,14)

Ко

ли

чес

тв

о р

ешен

ий

Стоимость, тыс. грн

149

Рисунок 4.34 – Гистограмма распределения прибыли проекта при

использовании методологии Crystal Clear

Рисунок 4.35 – Гистограмма распределения качества проекта при

использовании методологии Crystal Clear

Рисунок 4.36 – Гистограмма распределения рисков проекта при

использовании методологии Crystal Clear

11

15

24

13

10

6

0

5

10

15

20

25

30

[5,71-149,92) [149,93-294,14) [294,15-438,35) [438,36-582,57) [582,58-726,78) [726,79-871)

Ко

ли

чес

тв

о р

ешен

ий

Прибыль, тыс. грн

1

9

25 25

15

4

0

5

10

15

20

25

30

[1,46-1,86) [1,87-2,26) [2,27-2,65) [2,66-3,05) [3,06-3,45) [3,46-3,85)

Ко

ли

чес

тв

о р

ешен

ий

Качество, баллы

11

4

1

14

31

18

0

5

10

15

20

25

30

35

[0,29-0,39) [0,4-0,5) [0,51-0,6) [0,61-0,7) [0,71-0,8) [0,81-0,9)

Ко

ли

чес

тв

о р

ешен

ий

Риски, баллы

150

Рисунок 4.37 – Гистограмма распределения времени выполнения

проекта при использовании методологии Crystal Clear

Так же как и для случаев использования методологии Scrum, составим

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

методологии Crystal Clear (табл. 4.19).

Таблица 4.19 – Сравнение результатов оптимизации содержания

проекта, полученных для детерминированных и стохастических исходных

данных (Crystal Clear)

Название показателя Критерии оптимизации

Прибыль Стоимость Риски Качество Время

Средние значения 392,2 183,7 0,68 2,75 113,6

Детерминированное

решение

474,75 206,25 0,83 2,32 116

Отклонение от

среднего значения,%

21 12 22 -15 % 2

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

392,2 45,16 183,7 2,51 0,68 0,04 2,75 0,10 113,6 1,24

Как видно из таблицы 4.19, изменения исходных данных дают решения,

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

рисками, требуют меньше времени, но в то же время приносят меньше

прибыли и обеспечивают худшее качество. При изменении исходных данных

наиболее изменчива прибыль (11,52%), далее следуют риски (5,88%),

качество (3,64%), стоимость (1,37%). Наименьшая изменчивость

наблюдается для показателя время (1,09%).

3 5

6

15

21

29

0

5

10

15

20

25

30

35

[98-102) [102,01-105) [105,01-109) [109,01-113) [113,01-116) [116,01-120)

Ко

ли

чес

тв

о р

ешен

ий

Время, дни

151

Результаты численных экспериментов показывают, что решения,

полученные после генерации исходных данных по нормальному закону с

математическим ожиданием, равным соответствующему исходному

параметру при σ, равном 0,15 от значения этого параметра, существенно

отличаются от решения, полученного для детерминированных исходных

данных. Анализ устойчивости решения по методу Монте-Карло позволяет

находить более точные решения исходной задачи.

Проведенные эксперименты свидетельствуют, что при использовании

методологии Scrum решение, соответствующее детерминированному, было

получено один раз, 10 решений были получены по два раза, 43 решения по

одному разу и в 37 случаях решение не было получено. При использовании

методологии Crystal Clear решение, соответствующее детерминированному,

было получено один раз, 2 решения были получены по три раза, 13 решений

были получены по два раза, 47 решений по одному разу и в 21 случае

решение не было получено.

В результате анализа устойчивости решения задачи к изменению

исходных данных при применении методологии Crystal Clear была получена

большая прибыль от реализации проекта, меньшая его стоимость, меньшее

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

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

управления проектом должно делать лицо, принимающее решение.

Применительно к рассматриваемому проекту предпочтение было отдано

методологии Crystal Clear.

Полученные в ходе диссертационного исследования результаты были

внедрены в ряде организаций. На предприятии ООО «АЙН УКРАИНА» был

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

на рекомендациях экспертов. Результатом использования метода стал

перечень адаптивных методологий, рекомендованных для проекта по

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

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

152

была выбрана методология SCRUM (акт о внедрении представлен в

Приложении В).

В компании ООО «Пайп-Икс» был внедрен метод выбора методологии

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

критериям: трудозатраты, стоимость и риски. Рассматривалась возможность

использования трех методологий: KANBAN, SCRUM, MSF. Для проекта по

портированию компьютерной игры «Full Pipe» на мобильные платформы

Аndroid і IOS была выбрана методология SCRUM. Эффектом от

использования данной методологии стало уменьшение расходов на

управление в размере 10% по сравнению с использованием методологии

KANBAN и 30% - по сравнению с MSF (акт о внедрении представлен в

Приложении Г).

В ООО «НПК Автоматизированные системы» внедрен метод выбора

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

проекта. Метод применялся к проекту по обеспечению торгово-

развлекательного комплекса "Sun Mall" системами охранной сигнализации и

видеонаблюдения. Результатом использования стала оптимальная

совокупность работ проекта согласно методологии P2M (акт о внедрении

представлен в Приложении Д).

Кроме того, результаты работы использовались в Национальном

техническом университете "Харьковский Политехнический Институт" в

учебном процессе (акт о внедрении представлен в Приложении Е) и в рамках

госбюджетной научно-исследовательской работы № гос. регистрации

0115U000543 по теме «Разработка информационной технологии

формирования портфелей проектов национального уровня на основе

имитационной модели научно-технологического развития Украины».

Выводы по разделу 4

1. Для решения многокритериальной задачи оптимизации

содержания проекта было разработано программное обеспечение «ScopePro»,

153

которое позволяет применить метод выбора методологии управления

проектом на основе оптимизации содержания проекта.

2. Рассмотрены архитектурные особенности разработанного

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

3. Подготовлены исходные данные для выбора методологии

управления проектом на основе метода оптимизации содержания проекта,

для управления которым используются методологии Scrum и Crystal Clear.

4. Исходными данными для программного обеспечения «ScopePro»

является информация о средствах, выделяемых для осуществления проекта, о

количестве этапов, о цене и спросе на продукцию. Для каждого из

альтернативных вариантов выполнения операций каждого этапа проекта в

качестве исходных данных задаются: необходимое время, стоимость

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

остаточная стоимость выбывающих основных фондов, производственная

мощность. На основе указанных данных решается задача выбора

методологии управления проектом из двух альтернативных методологий –

Scrum и Crystal Clear.

5. На основе использования программного средства «ScopePro» было

оптимизировано содержание рассматриваемого проекта для случаев

управления им с помощью методологий Scrum и Crystal Clear.

6. Были получены решения для детерминированных исходных

данных при двух значениях вектора уступок, которые свидетельствуют, что

применение методологии Crystal Clear по сравнению с применением

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

проект, но уступает по качеству продукта и рискам.

7. Проведен анализ устойчивости полученных результатов к

изменению исходных данных методом Монте-Карло, который показал

преимущество применения методологии Crystal Clear для управления

рассматриваемым проектом по показателям прибыли, стоимости, времени.

Однако показатели качества и рисков при использовании методологии

154

Crystal Clear уступают аналогичным показателям при применении

методологии Scrum.

8. Основные результаты раздела опубликованы в работе [4,5,8,9,11].

155

ВЫВОДЫ

В диссертационной работе решена актуальная научно-прикладная

задача разработки модели и методов выбора методологии управления

проектом при различной степени информированности команды проекта о

существующих методологиях. Результаты работы имеют существенное

значение для организации управления проектами в области ИТ и позволяют

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

методологии управления.

Достоверность результатов исследования подтверждена решением

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

ООО «Научно-производственная компания Автоматизированные системы»,

ООО «Пайп-Икс», ООО «АЙН Украина», а также в учебном процессе в

Национальном техническом университете «Харьковский политехнический

институт». Основные положения и результаты диссертационного

исследования прошли апробацию на 9-ти международных научно-

практических конференциях.

В ходе выполнения работы были получены следующие результаты:

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

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

основываются на анализе статистических данных и неструктурированных

опросах.

2. Известные расчетные модели и методы позволяют достаточно

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

однако их не применяли для выбора определенной методологии управления.

3. Усовершенствован метод выбора методологии управления

проектами на основе рекомендаций экспертов, который основан на

анкетировании заказчика, менеджера и команды проекта и обработке

результатов. Вопросы анкеты касаются основных аспектов управления

проектом независимо от применяемой в организации методологии. Ответы

156

на эти вопросы позволяют получить рекомендации по применению

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

и его окружения.

4. Впервые предложен метод выбора методологии управления

проектом на основе решения задачи оптимизации по критериям

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

стоимость управления и риски, связанные с применением конкретной

методологии. Использование данного метода позволяет оценить

количественно преимущества и недостатки выбираемой методологии и

повысить качество управления проектами.

5. Впервые предложен метод выбора методологии управления проектом

на основе оптимизации содержания проекта по критериям: экономический

эффект (прибыль), сроки, стоимость, качество, риски, технологический,

экологический и социально-политический эффекты, что позволяет учесть

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

выполнения операций.

6. Усовершенствована математическая модель задачи

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

только прибыль, время, стоимость, качество и риски, но и технологический,

социально-политический и экологический эффекты от проекта.

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

отражают эти эффекты, что позволяет более полно характеризовать ценности

проекта.

7. Разработано программное обеспечение «ScopePro», в котором

реализован метод выбора методологии управления на основе оптимизации

содержания проекта. Программа написана в среде Eclipse на языке Java.

8. Решена практическая задача выбора методологии для управления

проектом разработки компьютерной программы «For Plan» с использованием

трех разработанных методов. Проведен анализ устойчивости полученных

результатов к изменению исходных данных методом Монте Карло.

157

9. Результатом применения метода, основанного на анкетировании

команды проекта, стал перечень рекомендаций по использованию

методологий, в который вошли Crystal Clear, Scrum, P2M.

10. В результате применения метода выбора методологии управления

проектом на основе решения задачи оптимизации по критериям

трудоемкость, стоимость управления и риски удалось сократить

трудозатраты на управление с помощью методологии SCRUM по сравнению

с методологией SWEBOK на 77,9%, уменьшить стоимость управления на

76,5%, но при этом увеличить риски на 26,3%. Применение методологии

Crystal Clear позволит уменьшить трудозатраты на управление по сравнению

с методологией SWEBOK на 82,2%, стоимость управления будет снижена на

80,9%, однако эти достижения будут сопровождаться увеличением рисков на

110,5%.

11. Метод выбора методологии управления проектом на основе

оптимизации содержания проекта применен для методологий Crystal Clear и

Scrum. Методология Crystal Clear позволяет при, практически, одинаковой

длительности выполнения проекта, в среднем по двум рассматриваемым

векторам уступок, увеличить прибыль на 8,45% и сократить затраты на

15,21%, Однако применение этой методологии увеличивает риск на 22,97 %

и ухудшает качество продукта проекта на 30,05%.

12. Достигнута цель исследования – повышено качество управления

проектом путем выбора наиболее рациональных методологий.

13. Разработанные в ходе диссертационного исследования модель,

методы и программное обеспечение «ScopePro» нашли практическое

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

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

проектами.

158

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Кононенко, И. В. Метод выбора оптимальной методологии

управления проектами [Текст] / И. В. Кононенко, А. В. Харазий // IX

Международная научно-практическая конференция «Современные

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

программами и проектами». – Алушта, 12–18 сентября 2011 г. Тезисы

докладов – Национальный аэрокосмический университет им.

Н.Е. Жуковского «Харьковский авиационный институт», 2011 г. – С. 182–

183.

2. Кононенко, И. Разработка метода анализа информации для

выбора оптимальной методологии управления проектом [Текст] /

И. Кононенко, А. Харазий // Восточно-Европейский журнал передовых

технологий. – 2012. – T. 1. – № 13 (55). – С. 4–7. doi:10.15587/1729-

4061.2012.3634.

3. Кононенко, И. В. Метод выбора методологии управления

проектом [Текст] / И. Кононенко, А. Харазий // X Международная научно-

практическая конференция «Современные информационные технологии в

экономике и управлении предприятиями, программами и проектами». –

Алушта, 10–16 сентября 2012 г. Тезисы докладов – Национальный

аэрокосмический университет им. Н.Е. Жуковского «Харьковский

авиационный институт», 2012 г. – С. 153–184.

4. Кононенко, И. В. Многокритериальная оптимизация содержания

проекта с применением метода уступок [Текст] / И. В. Кононенко,

Е. В. Лобач, А. В. Харазий // Управління проектами у розвитку суспільства.

Тема «Управління програмами та проектами в умовах глобалізації світової

економіки» : тези доповідей IX міжнародної конференції. – Київ, 17–

18 травня 2013 р. Тези доповідей – К.: КНУБА, 2013р. – С. 121–123.

5. Кононенко, И. В. Многокритериальная оптимизация содержания

проекта при заданных приоритетах для критериев [Текст] / И. В. Кононенко,

159

Е. В. Лобач, А. В. Харазий // Открытые информационные и компьютерные

интегрированные технологии : сб. науч. тр. – Х. : Нац. аэрокосм. ун-т

«ХАИ», 2013. – Вып. 59 – С. 6–13.

6. Кононенко, И. В. Трехэтапный метод выбора оптимальной

методологии управления проектом [Текст] / И. В. Кононенко, А. В. Харазий

// Международная научно-практическая конференция «Математическое

моделирование процессов в экономике и управлении инновационными

проектами (ММП–2014)». – Коблево, 16–21 сентября 2014 г. Труды –

Харьков : ХНУРЭ, 2014. – С. 103–105.

7. Kononenko, I. The methods of selection of the project management

methodology [Text] / I. Kononenko, A. Kharazii // International Journal of

Computing. – 2014. – Vol. 13. – № 4. – P. 240–247.

8. Кононенко, И. В. Оптимизация содержания проекта с учетом

технологических, экологических и социально-политических эффектов

[Текст] / И. В. Кононенко, А. В. Харазий // XIII Международная научно-

практическая конференция «Современные информационные технологии в

экономике и управлении предприятиями, программами и проектами». –

Одесса, 14–18 сентября 2015 г. Тезисы докладов – Национальный

аэрокосмический университет им. Н.Е. Жуковского «Харьковский

авиационный институт», 2015 г. – С. 100–101.

9. Кононенко, И. В. Разработка программного обеспечения для

многокритериальной оптимизации содержания проекта с помощью метода

уступок [Текст] / И. В. Кононенко, А. В. Харазий // Вісник Національно

технічного університету «ХПІ». Серія : Стратегічне управління, управління

портфелями, програмами та проектами : зб. наук. праць. – Х. : НТУ «ХПІ». –

2015. – № 1 (1110). – С. 11–24.

10. Kononenko, I. Selection method of the project management

methodology and its application [Text] / I. Kononenko, A. Kharazii, N. Iranik

//Proceedings of the 2013 IEEE 7 Internationalth Conference on Intelligent Data

160

Acquisition and Advanced Computing Systems (IDAACS). – 12–

14 September 2013, Berlin, Germany. – P. 578–582.

11. Кононенко, И. В. Решение задачи выбора методологии

управления проектом на основе оптимизации содержания проекта [Текст] /

И. В. Кононенко, А. В. Харазий // Восточно-Европейский журнал передовых

технологий. – 2015. – T. 4. – № 3 (76). – С. 43–52. doi:10.15587/1729-

4061.2015.47406

12. Бушуев, С. Д. Управление проектами: Основы профессиональных

знаний и система оценки компетентности проектных менеджеров [Текст] /

С. Д. Бушуев, Н. С. Бушуева ; Украинская ассоциация управления проектами.

− К. : ІРІДІУМ, 2010. – 208 с.

13. Керівництво з питань проектного менеджменту [Текст] : пер. з

англ. / під ред. С. Д. Бушуєва. − К. : Деловая Украина, 2000. – 198 с.

14. Бушуєв, С. Д. Креативные технологии управления проектами и

программами [Текст] : монографія / С. Д. Бушуев, Н. С. Бушуева,

И. А. Бабаев [и др.]. – К. : «Саммит-книга», 2010. – 768 с.

15. Руководство по управлению инновационными проектами и

программами [Текст] : пер. на рус. язык / под ред. С. Д. Бушуева. − К. : Наук.

світ, 2009. − т. 1. – 173 с.

16. Бушуєв, С. Д. Словник-довідник з питань управління проектами

[Текст] / С. Д. Бушуєв ; Українська асоціація управління проектами. − К. :

Деловая Украина, 2001. – 640 с.

17. Бушуев, С. Д. Динамическое лидерство в управлении проектами

[Текст] / С. Д. Бушуев, В. В. Морозов. − К. : ВИПОЛ, 1999. – 310 с.

18. Бушуєв, С. Д. Інвестиційні інструменти проектного менеджменту

[Текст] / С. Д. Бушуєв, Є. А. Гурин; Українська асоціація управління

проектами − К. : Укрінтеі, 1998. – 184 с.

19. Бушуєв, С. Д. Управління проектами та програмами [Текст] :

підручник / С. Д. Бушуєв, Н. С. Бушуєва, А. Я. Казарєзов [та ін.]. –

Миколаїв : видавництво Торубари О. С., 2010. – 352 с.

161

20. Бушуев, С. Д. Механизмы формирования ценности в

деятельности проектно-управляемых организаций [Текст] / С. Д. Бушуев,

Н. С. Бушуева // Восточно-Европейский журнал передовых технологий. −

2010. – № 1/2 (43). – C. 4−9.

21. Белощицкий, А. А. Расширяющаяся вселенная проектов [Текст] /

А. А. Белощицкий, Ю. Н. Тесля // Вісник ЧДТУ. – 2011. – № 3. – С. 67–71.

22. Белощицкий, А. А. Структура методологии проектно-векторного

управления образовательными средами [Текст] / А. А. Белощицкий //

Управління розвитком складних систем : зб. наук. пр. – К. : КНУБА, 2011. –

Вип. 7. – С. 121–125.

23. Белощицкий, А. А. Управление проблемами в методологии

проектно-векторного управления образовательными средами [Текст] /

А. А. Белощицкий, С. В. Белощицкая // Управління розвитком складних

систем : зб. наук. пр. – К. : КНУБА, 2012. – Вип. 9. – С. 104–107.

24. Гогунский, В. Д. Азбучные истины или как формировали базовые

компетенции в далекой древности [Текст] / В. Д. Гогунский, Д. В. Лукьянов //

Наук.-метод. семінар: «Шляхи реалізації кредитно-модульної системи

організації навчального процесу і тестових форм контролю знань студентів».

– Вип. 7. Одеса : Наука і техніка, 2013. – С. 54–57.

25. Оганов, А. В. Использование теории ограничения систем при

внедрении офиса управления проектами предприятия [Текст] / А. В. Оганов,

В. Д. Гогунский // GESJ: Computer Sciences and Telecommunications. – 2013 –

№ 4 (40). – С. 59–65.

26. Гогунский, В. Д. Формирование функции управляющих

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

движения галсами [Текст] / В. Д. Гогунский, П. А. Тесленко // Вост.-

Европейский журнал передовых технологий. – № 1/3 (43). – Харьков :

Технолог. центр, 2010 – С. 22–24.

27. Дружинін, Є. А. Методологічні основи ризик-орієнтованого

підходу до управління ресурсами проектів і програм розвитку техніки

162

[Текст] : автореф. дис. … д-ра техн. наук : 05.13.22 / Є. А. Дружинін. – Нац.

аерокосм. ун-т ім. М. Є. Жуковського «ХАІ». – Харків, 2006. – 34 с.

28. Илюшко, В. М. Методи та моделі інформаційної технології

проектування мета систем [Текст] : автореф. дис. … д-ра техн. наук : 05.13.06

/ Віктор Михайлович Илюшко. – Нац. аерокосм. ун-т ім. М. Є. Жуковського

«ХАІ». – Х., 1998. – 33 с.

29. Дружинін, Є. А. Науково-методологічне забезпечення управління

складними проектами [Текст] / Є. А. Дружинін, В. Я. Жихарев, В. М. Ілюшко

[та ін.] ; за ред. М. М. Митраховича. К. : Техніка, 2002 – 369 с.

30. Илюшко, В. И. Системные средства моделирования в задачах

проектирования [Текст] / В. И. Илюшко, О. Е. Федорович, М. М. Митрахович

// Информационные системы. − Х. : НАНУ, ХВУ, 1998. − С. 73−77.

31. Кошкин, К. В. Управление проектами и организация

виртуальных производств в судостроении [Текст] : автореф. дис. … д-ра

техн. наук : 05.13.22 / К. В. Кошкин. – Укр. гос. морской техн. ун-т. им.

адмирала Макарова. – Николаев, 2001. – 32 с.

32. Малеева, О. В. Методологические основы системного анализа

качества проектов и программ развития производства [Текст] : автореф. дис.

… д-ра техн. наук : 05.13.22 / О. В. Малеева. – Нац. аерокосм. ун-т ім. М. Є.

Жуковського «ХАІ». – Х., 2003. – 33 с.

33. Малеева, О. В. Методология управления качеством научно-

технических программ развития [Текст] / О. В. Малеева // Авіаційно-

космічна техніка та технологія : зб. наук. пр. − Х. : Нац. аерокосм. ун-т ім.

М. Є. Жуковського «ХАІ», 2001. – № 28. – С. 59−64.

34. Неизвестный, С. И. Новая парадигма обучения дисциплинам

управления проектами [Текст] / С. И. Неизвесный // Управление проектами и

программами. – 2013. – № 3. – С. 228–239.

35. Бушуев, С. Д. Геном методологий управления проектами как

универсальная модель знаний [Текст] / С. Д. Бушуев, С. И. Неизвесный //

163

Управління розвитком складних систем. – К. : КНУБА, 2013. – № 14. – С. 15–

18.

36. Рак, Ю. П. Информационные технологии в стратегическом

управлении портфелями проектов безопасности жизнедеятельности

[Электронный ресурс] / Ю. П. Рак, В. В. Ковалишин, О. В. Зачко,

I. Г. Барабаш, А. И. Ивануша // ВЕЖПТ. – 2011. – № 5 (49). – Режим доступа :

http://cyberleninka.ru/article/n/informatsionnye-tehnologii-v-strategicheskom-

upravlenii-portfelyami-proektov-bezopasnosti-zhiznedeyatelnosti.

37. Рак, Ю. П. Ідентифікація проектів в портфелях і програмах

регіонального розвитку з питань надзвичайних ситуацій [Текст] / Ю. П. Рак,

А. О. Саченко, О. Б. Зачко, І. О. Палій // Управління проектами та розвиток

виробництва : зб. наук. пр. – Луганськ : вид-во СНУ ім. В. Даля, 2011. –

№ 4 (40). – С. 64–69.

38. Рач, В. Побудова термінологічної системи організації наукового

знання [Текст] / В. Рач, О. Россошанська, О. Медведєва // Науковий світ. –

2011. – № 4. – С. 13–16.

39. Рач, В. А. Управление рисками проекта: общее и различия

РМВОК4 и РМВОК5 [Текст] / В. А. Рач, Н. О. Борулько // Управління

проектами та розвиток виробництва : зб.наук.пр. – Луганськ : вид-во СНУ

ім. В. Даля. – 2014. – № 1 (49). – С. 5–15.

40. Рач, В. А. Особенности регистрации и финансирования

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

государственной стратегии развития [Текст] / В. А. Рач, О. В. Бирюков //

Управління проектами та розвиток виробництва : зб. наук. праць. –

Луганськ : вид-во СНУ ім. В. Даля. – № 3 (47). – 2014. – С. 56–75.

41. Рач, В. А. Модель підготовки фахівців з управління інноваційною

дільністю [Текст] / В. А. Рач, О. В. Бирюков // Управління проектами та

розвиток виробництва : зб. наук. праць. – Луганськ : вид-во СНУ ім. В. Даля.

– № 4 (48). – 2014. – С. 22–31.

164

42. Чернов, С. К. Психологическая готовность менеджеров для

успешной реализации проекта в условиях научно-производственного

комплекса [Текст] / С. К. Чернов, М. Н. Михайлова // Управління проектами

та розвиток виробництва : зб. наук. праць. – Луганськ : вид-во СНУ

ім. В. Даля. – № 31 (33). – 2010. – С. 35–41.

43. Чумаченко, І. В. Управління проектами: процеси планування

проектних дій [Текст] / І. В. Чумаченко, В. В. Морозов, Н. В. Доценко,

А. М. Чередниченко : підручник з грифом МОН України. – К. : «КРОК»,

2014. – 673 с.

44. Чумаченко, І. В. Система управління ризиками проектів

підприємства [Текст] / І. В. Чумаченко, М. О. Латкін, Т. І. Бондарєва, Н. В.

Доценко : навч. посібник з грифом МОН України. – Харків : Нац.

аерокосмічний ун-т «Харк. авіац. ін-т», 2012. – 232 с.

45. Арчибальд, Р. Д. Управление высокотехнологичными

программами и проектами [Текст] : пер. с англ. / Р. Д. Арчибальд. − М. :

ДМК Пресс : АйТи, 2002. – 463 с.

46. Бурков, В. Н. Как управлять проектами [Текст] / В. Н. Бурков,

Д. А. Новиков. − М. : Синтег, 1997. – 188 с.

47. Бурков, В. Н. Модели и методы управления организационными

системами [Текст] / В. Н. Бурков. В. А. Ириков. − М. : Наука, 1994. – 270 с.

48. Бурков, В. Н. Теория графов в управлении организационными

системами [Текст] / В. Н. Бурков, Д. А. Новиков, А. Ю. Заложнев. – М. :

Синтег, 2001. – 124 с.

49. Воропаев, В. И. Управление проектами в России [Текст] /

В. И. Воропаев. − М. : Аланс, 1995. – 225 с.

50. Разу, М. Л.Управление программами и проектами [Текст] /

М. Л. Разу, В. И. Воропаев, Ю. В. Якутин [и др.] ; под ред. М. Л. Разу − М. :

Инфра-М, 1999. – 364 с.

165

51. Воропаев, В. И. Методические рекомендации по ресурсному

анализу календарных планов на основе обобщенных сетевых моделей [Текст]

/ В. И. Воропаев [и др.]. – М. : ЦНИИЭУС, 1990. – 85 с.

52. Воропаев, В. И. Обобщенные сетевые модели [Текст] /

В. И. Воропаев, М. В. Шейнберг. − М. : ЦНИПИАС, 1974. – 118 с.

53. Грей, Ф. К. Управление проектами: практическое руководство

[Текст] : пер. с англ. / Клиффорд Ф. Грей, Эрик У. Ларсон. − М. :

Издательство «Дело и Сервис», 2003. – 528 с.

54. Коуберн, А. Каждому проекту своя методология [Текст] /

Коуберн Алистер. – Humans and Technology Technical Report, 7691 Dell Rd,

Salt Lake City, UT 84121 USA : TR 99.04, Oct. 1999. – 50 с.

55. Cockburn, A. Crystal Clear A Human-Powered Methodology for

Small Teams [Text] / Alistair Cockburn // Addison-Wesley Professional. – 1-st ed.

– 2004. – P. 336.

56. Коберн, A. Люди как нелинейные и наиболее важные

компоненты в создании программного обеспечения [Текст] / Алистер Коберн

// Humans and Technology. – 1999. – 19 c.

57. Kerzner, H. Project management: a systems approach to planning,

scheduling, and controlling [Text] / Harold Kerzner. − 7-th ed. − Copyright, 2001.

– 1200 p.

58. Керцнер, Г. Стратегическое планирование для управления

проектами с использованием модели зрелости [Текст] : пер. с англ. /

Г. Керцнер. – М. : Компания Ай Ти, ДМК Пресс, 2003. – 320 с.

59. Локк, Д. Основы управления проектами [Текст] : пер. с англ. /

Денис Локк. − М. : НІРР, 2004. − 253 с.

60. Либерзон, В. И. Основы управления проектами [Текст] /

В. И. Либерзон. − М. : Нефтяник, 1997. – 150 с.

61. Мартин, П. Управление проектами [Текст] : пер. с англ. /

П. Мартин, К. Тейт. − СПБ. : Питер, 2006. – 224 с.

166

62. Мазур, И. И. Управление проектами [Текст] : учебное пособие /

И. И. Мазур, В. Д. Шапиро, Н. Г. Ольдерогге ; под общ. ред. И. И. Мазура. −

2-е изд. − М. : Омега-Л, 2004. – 664 с.

63. Тернер, Дж. Родни. Руководство по проектно-ориентированному

управлению [Текст] : пер. с англ. под. общ. ред. Воропаева В. И. /

Дж. Родни Тернер. – М. : Издательский дом Гребенникова, 2007. – 552 с.

64. Reusch, Peter J. A. Flexible classification standards for product data

exchange, in Dorloff, Frank-Dieter [Text] / Peter J. A. Reusch, Wolfgang Wilkes,

Laura Esmeralda Garcia // Handbook of Research on E-Business Standards and

Protocols: Documents, Data and Advanced Web Technologies, IGI Global, 2012 –

P. 448 – 466.

65. Reusch, P. J. A How to develop lean project management? [Text] /

Peter J. A. Reusch, P. Reusch // Intelligent Data Acquisition and Advanced

Computing Systems (IDAACS), 2013 IEEE 7th International Conferenc, 2013. –

Vol. 02. – P. 547 – 550.

66. Управление проектом. Основы проектного управления [Текст]:

учебник / кол. авт. ; под ред. проф. М. Л. Разу. − М. : КНОРУС, 2006. – 768 с.

67. Разу, М. Л. Управление программами и проектами [Текст] /

М. Л. Разу, В. И. Воропаев, Ю. В. Якутин. − М. : Инфра-М, 2000. – 364 с.

68. Товб, А. С. Управление проектами: стандарты, методы, опыт

[Текст] / А. С. Товб, Г. Л. Ципес. − М. : ЗАО «Олимп-Бизнес», 2003. – 240 с.

69. Колтунова, Е. Классификация методологий, моделей и

стандартов управления разработкой ПО [Электронный ресурс] /

Е. Колтунова ; IT@Business, 2007. – Режим доступа :

http://www.koltunova.com/it-project-management-methodology-classification/.

70. Бушуєва, Н. С. Управління проектами та програмами

організаційного розвитку [Текст] / Н. С. Бушуєва, Ю. Ф. Ярошенко,

Р. Ф. Ярошенко. – Київ : «Самміт- Книга», 2010. – 198 с.

71. Ильина, О. Н. Методологическое обеспечение управления

проектами, программами и портфелями проектов в организации

167

[Электронный ресурс] / О. Н. Ильина – «Менеджмент в России и за

рубежом» № 1(2010). Режим доступа :

http://mevriz.ru/articles/2010/1/5915.html.

72. A Guide to the Project Management Body of Knowledge (PMBoK

Guide) [Text] / Project Management Institute. USA, 2012. – 5-th ed. – 589 p.

73. ISO 10006:2003 Системы менеджмента качества. Руководящие

указания по управлению качеством в проектах. – К. : Гос. стандарт Украины,

2003. – 41 с.

74. PRINCE2 – Projects IN Controlled Environments [Электронный

ресурс]. – Режим доступа : http://www.apmgroup.co.uk/

PRINCE2/PRINCE2Home.asp. – 21.03.2011 г.

75. A Guidebook of Project & Program Management for Enterprise

Innovation "P2M". Revision 3 [Text] / by Project Management Professionals of

Japan, 2005. – 95 p.

76. The Standard for Program Management [Text] / by Project

Management Institute. USA, 2006. – 109 р.

77. PMCDF Project Management Competency Development Framework

2nd Edition [Text] / Newton Square, Pennsylvania, USA : Project Management

Institute, 2007. – 90 p.

78. IPMA Competence Baseline, Version 3.0. [Text] / ICB : IPMA,

International Project Management Association. The Netherlands, 2006. – 212 р.

ISBN : 0-9553213-0-1

79. Управление проектами: Основы профессиональных знаний,

Национальные требования к компетентности специалистов [Текст] // NCB –

SOVNET National Competence Baseline Version 3.0 /М.: ЗАО «Проектная

ПРАКТИКА», 2010. – 256 с. ISBN 5-904574-03-1

80. A Framework for Performance Based Competency Standards for

Program Managers Sydney: Global Alliance for Project Performance Standards

GAPPS, 2011. – 58 p.

168

81. Organizational Project Management Maturity Model (OPM3)

Knowledge Foundation. – PMI, 2003. – 179 p.

82. ISO 21500:2012. Cтандарт по управлению проектами на базе

модели PMBoK [Текст]. Zaltbommel. : Van Haren Publishing (VHP), 2012.

36 с.

83. Managing Successful Programmes with PRINCE2 2009 Edition

[Text] / Office of Government Commerce (OGC) London, UK : The Stationery

Office, 2009. – 258 р.

84. The Standard for Portfolio management [Text]. – USA : PMI, 2008. –

203 р.

85. Воропаев, В. И. Управление проектами в России [Текст] /

В. И. Воропаев. − М. : Аланс, 1995. – 225 с.

86. Software Engineering Institute. CMMI for Development, Version 1.3.

[Text] //Carnegie Mellon University. 2010. – 433 p.

87. Software Engineering Body of Knowledge (SWEBOK) [Text] /

Software Engineering Coordinating Committee. USA, 2004. – 202 p.

88. Scrum [Электронный ресурс]. – Режим доступа :

http://www.cmsmagazine.ru /library/ items/ management /scrum/

89. Канбан и «точно вовремя» на Toyota: Менеджмент начинается на

рабочем месте // Just-in-Time at Toyota: Management Begins at the Workplace.

М.: Альпина Паблишер, 2014. 214 с. (Модели менеджмента ведущих

корпораций). ISBN 978-5-9614-4659-3.

90. The DSDM Agile Project Framework Handbook // Published by The

DSDM Consortium 1st edition, 2014. – 176p.

91. Turner, Michael S. V. Microsoft® Solutions Framework Essentials

/Michael S. V. Turner // Published by Microsoft Press, August 30, 2006. – 340p.

ISBN 13: 9780735623538

92. Rational Unified Process Best Practices for Software Development

Teams// Rational Software White PaperTP026B, Rev, 2001. – 18p.

169

93. eXtreme Programming An Overview [Електронний ресурс]. –

Режим доступу : http: //csis.pace.edu/ ~marchese/CS616/

Agile/XP/XP_Overview. pdf.

94. Ильина, О. Н. Методология управления проектами: становление,

современное состояние и развитие [Текст] : вузовский учебник /

О. Н. Ильина. М. : ИНФРА-М:, 2011. – 208 с.

95. Павлов, А. Н. Управление проектами на основе стандарта PMI

PMBOK. Изложение методологии и опыт применения [Текст] / А. Н. Павлов.

М. : Бином. Лаборатория знаний, 2012. – 208 с.

96. Нугайбеков, Р. А. Корпоративная система управления проектами:

От методологии к практике [Текст] / Р. А. Нугайбеков, Д. Г. Максин,

А. В. Ляшук. – М. : Альпина Паблишер, 2015. – 236 с.

97. PRINCE2® in one thousand words [Электронный ресурс] / Andy

Murray and Director of Outperform UK Ltd, 2009 – Режим доступа: www.best-

management-practice.com/gempdf/PRINCE2_in_One_Thousand_Words.pdf.

98. Pfleeger, S. L. Software Engineering. Theory and practice [Text] /

S. L. Pfleeger // Printice Hall: Upper Saddenle River. – New Jersey, 1998. – 576 p.

99. Андон, Ф. И. Основы инженерии качества программных систем

[Текст] / Ф. И. Андон, Г. И. Коваль, Т. М. Коротун, Е. М. Лаврищева,

В. Ю. Суслов. – 2-е изд. – Киев : Академпериодика, 2007. – 680 с.

100. Лавріщева, К. М. Програмна інженерія [Текст] : підручник /

К. М. Лавріщева. – Академперіодика, 2008. – 322 с. – ISBN : 978–966–02–

5052–9.

101. Ярошенко, Ф. А. – Управление инновационными проектами и

программами на основе системы знаний Р2М / Ф. А. Ярошенко,

С. Д. Бушуев, Х. Танака. – К., 2011 – 268 с.

102. Sutherland, J. How a Traditional Project Manager Transforms to

Scrum: PMBOK vs. Scrum. [Электронный ресурс] / Jeff Sutherland, Nafis

Ahmad // 2011 – 7 р. Режим доступа : http: //jeffsutherland.com/ PMBOK vs

ScrumAgile2011.pdf.

170

103. Cockburn, A. Surviving Object-Oriented Projects [Text] /

A. Cockburn. – Addison Wesley, 1997. – 272 p.

104. Брагина, Т. И. Сравнительный анализ итеративных моделей

разработки программного обеспечения [Текст] / Т. И. Брагина,

Г. В. Табунщик // Радиоелектроніка. Інформатика. Управління. – 2010. –

№ 2. – С. 130–139.

105. Boehm, B. Using risk to balance agile and plan-driven methods [Text]

/ B. Boehm, R. Turner // IEEE Computer Society –36 (6). – 2003. – P. 57–66.

106. Boehm, B. Balancing Agility and Discipline: A Guide for the

Perplexed [Text] / B. Boehm, R. Turner // Addison-Wesley, Boston (MA), 2004.

107. Sheffield, J. Factors associated with the software development agility

of successful projects [Text] /J. Sheffield, J. Lemétayer // International Journal of

Project Management – 31. – 2013. – P. 459–472.

108. Lazaros, S. Quality vs risk: An investigation of their relationship in

software development projects [Text] / S. Lazaros, D. C. Prodromos //

International Journal of Project Management – 32. – 2014. – P. 1073–1082.

109. McHugh, O. Investigating the rationale for adopting an

internationally-recognised project management methodology in Ireland: The view

of the project manager [Text] / O. McHugh, H. Mairéad // International Journal of

Project Management. – 31. – 2010. – P. 1–10.

110. Нєізвесний, С. І. Розвиток методологій управління проектами із

застосування механізмів конвергенції [Текст] : автореф. дис. … д-ра техн.

Наук : 05.13.22 / С. І. Нєізвесний. – К., 2013. – 39 с.

111. Okwumabua, G. Selecting the Right Project Management

Methodology [Электронный ресурс] / G. Okwumabua // Mythics Blog. – 2013,

April 17. – Режим доступа : http://www.mythics.com/about/blog/selecting-the-

right-project-management-methodology

112. Hanif, T. Selecting the right project management approach using 6P

[Text] / T. Hanif, M. Limbachiya // 24th World Conference IPMA (International

Project Management Association). – Istanbul, Turkey, 2010. – P. 183–189.

171

113. Whitaker, S. How to Build Your Own Project Management

Methodology [Электронный ресурс] / S. Whitaker // Copyright Sean Whitaker. –

2014, February 27. – Режим доступа : http://seanwhitaker.com/how-to-build-

your-own-project-management-methodolog.

114. PM GUIDE 01 Selecting a project management methodology.

Enterprisesolutions [Электронный ресурс] / VICTORIAN GOVERNMENT CIO

COUNCIL – 07/2014. – Режим доступа : //

http://www.enterprisesolutions.vic.gov.au/wp-content/uploads/2014/07/PM-

GUIDE-01-Project-management-methodology-selection-guideline.pdf

115. Fulkerson, D. R. A network flow computation for project cost curves

[Text] / D. R. Fulkerson // Management Science. – 1961. – № 7. – P. 167–178.

116. Perera, S. Linear programming solution to network compression

[Text] / S. Perera // ASCE Journal of the Construction Division. – 1980. – № 106.

– P. 315–326.

117. Bartusch, M. Scheduling project networks with resource constraints

and time windows [Text] / M. Bartusch, R. H. Mohring, F. J. Radermacher //

Annals of Operations Research. – 1988. – №1 6. – P. 201–240.

118. Patterson, J. H. An algorithm for a general class of precedence and

resource constrained scheduling problems [Text] / J. H. Patterson, R. Slowinski,

F. B. Talbot, J. Weglarz // Advances in project scheduling. Amsterdam. – 1989. –

№ 43. – P. 3–28.

119. Shtub, A. Project management: engineering, technology and

implementations [Text] / A. Shtub, J. Bard, S. Globerson. – Englewood Cliffs,

N.J. : Prentice-Hall, 1994. –392 p.

120. Liu, L. Construction time-cost trade-off analysis using LP/IP hybrid

method [Text] / L. Liu, SA. Burns, CW. Feng // ASCE Journal of Construction

Engineering and Management. – 1995. – № 121 (4). – P. 446–454.

121. Moussourakis, J. Flexible model for time/cost tradeoff problem [Text]

/ J. Moussourakis, C. Haksever // ASCE Journal of Construction Engineering and

Management. – 2004. – № 130 (3). – P. 307–314.

172

122. Латкін, М. О. Методологічні основи створення системи

управління ризиками проектів підприємства [Текст] : автореф. дис. … д-ра

техн. Наук : 05.13.22 / М. О. Латкін. – Нац. аерокосм. ун-т ім. М. Є.

Жуковського «ХАІ». – Харків, 2009. – 35 с.

123. Sakellaropoulos, S. Project time-cost analysis under generalized

precedence relations [Text] / S. Sakellaropoulos, A. P. Chassiakos // Advanced in

Engineering software, Elsevier. – 2004. – № 35. – P. 715–724.

124. Chassiakos, A. P. Time-cost optimization of construction projects

with generalized activity constraints [Text] / A. P. Chassiakos // ASCE Journal of

Construction Engineering and Management. – 2005. – № 131 (10). – P. 1015–

1061.

125. Robinson, D. R. A dynamic programming solution to cost-time

tradeoff for CPM [Text] / D. R. Robinson // Management Science. – 1975. – № 22.

– P. 158–166.

126. Hindelang, T. J. A dynamic programming algorithm for decision CPM

networks [Text] / T. J. Hindelang, J. F. Muth // Operations Research. – 1979. –

№ 27. – P. 225–241.

127. Feng, CW. Using genetic algorithms to solve construction time-cfost

trade-off problems [Text] / CW. Feng, L. Liu, SA. Burns // ASCE Journal of Civil

Engineering. – 1997. – № 11 (3). – P.184–189.

128. Li, H. Using machine learning and GA to solve time-cost trade-off

problems [Text] / H. Li, J. N. Cao, P. E. D. Love // ASCE Journal of Construction

Engineering and Management. – 1999. – № 125 (5). – P. 347–353.

129. Leu, SS. GA-based multicriteria optimal model for construction

scheduling [Text] / SS. Leu, CH. Yang // ASCE Journal of Construction

Engineering and Management. – 1999. – № 125 (6). – P. 420–427.

130. Feng, CW. Stochastic construction time-cost tradeoff analysis [Text] /

CW. Feng, L. Liu, SA. Burns // ASCE Journal of Civil Engineering. – 2000. –

№ 14 (2). – P. 117–126.

173

131. Zheng, D. X. M. Applying a genetic algorithm-based multiobjective

approach for time-cost optimization [Text] / D. X. M. Zheng, S. T. Ng.,

M. M. Kumaraswamy // ASCE Journal of Construction Engineering and

Management. – 2004. – № 130 (2). – P. 168–176.

132. Parikh, SC. Decomposition of project networks [Text] / SC. Parikh,

WS. Jewell // Manage Science. – 1965. – № 11. – P. 444–459.

133. Crowston, W. B. Decision CPM: Network reduction and solution

[Text] / W. B. Crowston // Operational Research Quarterly. – 1970. – № 21. –

P. 435–452.

134. Panagiotakopoulos, D. Cost-time model for large CPM project

networks [Text] / D. Panagiotakopoulos // ASCE Journal of the Construction

Division. – 1977. – № 103. – P. 201–211.

135. De, P. The discrete time-cost tradeoff problem revisited [Text] / P. De,

E. J. Dunne, J. B. Ghosh, C. E. Wells // European Journal of Operational Research.

– 1995. – № 81. – P. 225–238.

136. Fondahl, J. W. A noncomputer approach to the critical path method

for the construction industry [Text] / J. W. Fondahl // ASCE Journal of Civil

Engineering. – 1961. – Tech. Rep No. 9. – P. 138–167.

137. Prager, W. A structural method of computing project cost polygons

[Text] / W. Prager // Management Science. – 1963. – № 9 (3). – P. 394–404.

138. Chassiakos, A. P. An integer programming method for CPM time-cost

analysis [Text] / A. P. Chassiakos, C. I. Samaras, D. D. Theodorakopoulos // Corn-

put. Model. Eng. Set. – 2000. – № 1 (4). – P. 9–18.

139. Charnes, A. Chance-constrained programming [Text] / A. Charnes,

W. Cooper // Management Science. – 1959. – № 6. – P. 73–79.

140. Coskunoglu, O. Optimal probabilistic compression of PERT networks

[Text] / O. Coskunoglu // ASCE Journal of Construction Engineering and

Management. – 1984. – № 110 (4). – P. 437–446.

141. Давыдов, Э. Г. Исследование операций [Текст] / Э. Г. Давыдов. −

М. : Высшая школа, 1990. – 383 с.

174

142. Воропаев, В. И. Задачи и методы временного анализа

календарных планов на обобщенных сетевых моделях [Текст] /

В. И. Воропаев, Б. Я. Лебедь, М. П. Нудельман, Т. Я. Орел // Экономико-

математические методы и АСУ в строительстве. – М. : НИИЭС, 1986. − 95 с.

143. Голенко, Д. И. Статистические методы сетевого планирования и

управления [Текст] / Д. И. Голенко. − М. : Главная редакция физико-

математической литературы изд-ва «Наука», 1968. – 400 с.

144. Филлипс, Д. Методы анализа сетей [Текст] / Д. Филлипс,

А. Гарсиа-Диас. − М. : Мир, 1984. – 496 с.

145. Чернов, С. К. Ефективні організаційні структури в управлінні

програмами розвитку наукомістких підприємств [Текст] : автореф. дис. … д-

ра техн. наук : 05.13.22 / C. К. Чернов. – Нац. ун-т кораблебуд.

ім. адм. Макарова. – Миколаїв, 2007. – 43 с.

146. Кононенко, И. В. Математическая модель и метод минимизации

сроков выполнения работ по проекту [Текст] / И. В. Кононенко,

Е. В. Емельянова, А. И. Грицай // Восточно-Европейский журнал передовых

технологий. − 2007. – № 2/6 (26). – С. 35–40.

147. Рихтер, К. Динамические задачи дискретной оптимизации [Текст]

/ К. Рихтер. – М. : Радио и связь, 1985. – 136 с.

148. Кононенко, И. В. Математическая модель и метод минимизации

затрат по проекту при ограничениях на сроки выполнения работ [Текст] /

И. В. Кононенко, Е. В. Емельянова // Вестн. Нац. техн. ун-та «ХПИ»: сб.

науч. тр. – № 4. – Х., 2009. – С. 46–53.

149. Kononenko, I. V. Mathematical Models and Minimization Methods of

Works Time and Costs on the Project [Text] / I. V. Kononenko,

O. V. Iemelianova, A. V. Mochenkov // Materials of The 22nd International

Project Management Association World Congress. – Rome, Italy, 9–11 November

2008. – 507 p.

150. Кононенко, И. В. Программная реализация методов оптимизации

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

175

альтернативных вариантов выполнения работ [Текст] / И. В. Кононенко,

Е. В. Емельянова // Восточно-Европейский журнал передовых технологий. –

2009. – № 4/8 (40). – С. 57–61.

151. Протасов, И. В. Модели и методы управления содержанием

инвестиционных проектов по производству продукции [Текст] : дис. … канд.

техн. наук : 05.13.22 / И. В. Протасов. – Национальный аэрокосмический

университет им. Н. Е. Жуковского «Харьковский авиационный институт». –

Харьков, 2012. – 175 с.

152. Колесник, М. Э. Модели и методы многокритериальной

оптимизации содержания проекта при четких и нечетких исходных данных

[Текст] : дис. канд. техн. наук : 05.13.22 / М. Э. Колесник. – Национальный

аэрокосмический университет им. Н. Е. Жуковского «Харьковский

авиационный институт». – Харьков, 2013. – 157 с.

153. Xu, J. Discrete time–cost–environment trade-off problem for large-

scale construction systems with multiple modes under fuzzy uncertainty and its

application to Jinping-II Hydroelectric Project [Text] / J. Xu, H. Zheng, Z Zeng,

S. Wu, M. Shen // International Journal of Project Management.– 2012. – 8 (30) –

950–966 p.

154. Magic Quadrant for IT Project and Portfolio Management

[Электронный ресурс]. – Режим доступа :

http://www.projektmagazin.de/marktplatz/

details/msproject/Gartner_RAS_Core%20Research_0607.pdf?pmSession,

http://www.cfin.ru/software/project/pms-review.shtml. – 30.04.2012

155. Богданов, В. В. Управление проектами в Microsoft Project 2007

[Текст] : учебный курс (+CD) / В. В. Богданов. – Питер, 2007. – 592 с.

156. Емеличев, В. А. О радиусе устойчивости эффективного решения

одной векторной задачи булева программирования в метрике l1 [Текст] /

В. А. Емеличев, К. Г. Кузьмин // Доклады РАН. – 2005. – Т. 401. – № 6. –

С. 733–735.

176

157. Sotskov, Yu. N. Some concepts of stability analysis in combinatorial

optimization [Text] / Yu. N. Sotskov, V. K. Leontev, E. N. Gordeev // Discrete

Applied Mathematics. – 1995. – Vol. 58. – № 2. – P. 169–190. doi:10.1016/0166-

218x(93)e0126-j.

158. Бухтояров, С. Е. Параметризация принципа оптимальности («от

Парето до Слейтера») и устойчивость многокритериальных траекторных

задач [Текст] / С. Е. Бухтояров, В. А. Емеличев // Дискретный анализ и

исследований операций. Сер. 2. – 2003. – Т. 10. – № 2. – С. 3–18.

159. Emelichev, V. A. Stability and regularization of vector problems of

integer linear programming [Text] / V. A. Emelichev, E. Girlich, Yu. V. Nikulin,

D. P. Podkopaev // Optimization. – 2002. – Vol. 51. – № 4. – P. 645–676.

doi:10.1080/0233193021000030760.

160. Зубанов, Н. В. Анализ устойчивости относительно поставленной

цели как один из подходов к описанию функционирования организации в

условиях неопределенности [Электронный ресурс] : монография /

Н. В. Зубанов. – Режим доступа : \www/URL: www.aup.ru/books/m66/4.htm.

161. Greenberg, H. J. An Annotated Bibliography for Post-Solution

Analysis in Mixed Integer Programming and Combinatorial Optimization [Text] /

N. J. Greenberg // Advances in Computational and Stochastic Optimization, Logic

Programming, and Heuristic Search Operations Research / Computer Science

Interfaces Series. – Boston, MA : Kluwer Academic Publishers, 1998. – Vol. 9. –

P. 97–147. doi:10.1007/978-1-4757-2807-1_4.

162. ДСТУ ISO 9000:2007 Основні положення та словник термінів

[Текст]. – К. : ДЕРЖСПОЖИВСТАНДАРТ України, 2008. – 29 с.

163. Кононенко, И. В. Разработка модели и метода

многокритериальной оптимизации содержания проекта / И. В. Кононенко,

М. Э. Колесник // Открытые информационные и компьютерные

интегрированные технологии : сб. науч. тр. Нац. аэрокосм. ун-т «ХАИ». –

Вып. 56. – Х., 2012. – С. 132–142.

177

164. Кононенко, И. В. Оптимизация содержания проекта по

критериям прибыль, время, стоимость, качество, риски. [Текст] /

И. В. Кононенко, М. Э. Колесник // Восточно-Европейский журнал

передовых технологий. 2012. 1/10 (55). С. 1315.

165. Ємельянова, О. В. Моделі та методи планування інноваційних

проектів і програм з урахуванням альтернативних варіантів виконання робіт

[Текст] : автореф. дис. … канд. техн. наук : 05.13.22 / О. В. Ємельянова. –

Нац. аерокосм. ун-т ім. М.Є. Жуковського «ХАІ». – Харків, 2009. – 20 с.

166. Соловьев, В. И. Методы оптимальных решений. [Текст] : учеб.

пособие / В. И. Соловьев. М. : Финансовый университет, 2012. 364 с.

167. Подиновский, В. В. Оптимизация по последовательно

применяемым критериям / В. В. Подиновский, В. М. Гаврилов. М. :

Сов.радио, 1975. 192 с.

168. Кононенко, И. В. Модель и метод максимизации прибыли в

процессе оптимизации содержания проекта [Текст] / И. В. Кононенко,

М. Э. Колесник // Високі технології в машинобудуванні = High technologies of

machine-building : зб. наук. пр. – Харків : НТУ «ХПІ», 2012. – Вип. 1 (22). –

С. 139–144.

169. Кононенко, И. В. Математическая модель и метод минимизации

затрат по проекту при ограничениях на сроки выполнения работ [Текст] /

И. В. Кононенко, Е. В. Емельянова // Вестн. Нац. техн. ун-та «ХПИ»: сб.

науч. тр. − № 4. − Х., 2009. – С. 46–53.

170. Kononenko, I. Computerizing of Production and Economic Systems

Development Management [Text]. – Black & White, 2012. – 334 p.

171. Реальная норма часов работы программиста в день

[Электронный ресурс] / Vsevolod Dyomkin // Lisp, the Universe and Everything

– 2011 г. Режим доступа : http://lisp-univ-etc.blogspot.com/2011/12/blog-

post.html.

178

172. Работая на работе [Электронный ресурс] /d.razorionov// Ну как

курятник!..Блог о том, как управлять окружением. – 2011 г. Режим доступа :

URL: https://radimos.wordpress.com/tag/agile/.

173. Золотов, Е. От звонка до звонка, все долгие 6 часов! А если

серьёзно, когда на шестичасовку? [Электронный ресурс] / Евгений Золотов //

ООО «Компьютерра-Онлайн», 1997–2015. – 2013 г. Режим доступа :

http://www.computerra.ru/90154/6-hours/.

174. PRINCE2 [Электронный ресурс] Материал из Википедии —

свободной энциклопедии – 11 октября 2014. Режим доступа :

https://ru.wikipedia.org/wiki/PRINCE2.

175. Scrum — реальный опыт работы по методологии [Электронный

ресурс] Блог компании Unicloud Business 365. – 25 января 2013. Режим

доступа : http://habrahabr.ru/company/unicloud/blog/167059/.

176. Закис, А. Часть 2. Сравнение методологий разработки ПО

[Электронный ресурс] RUP и другие методологии разработки ПО. – ноябрь

2006. Режим доступа : http://compress.ru/article.aspx?id=16880.

179

ПРИЛОЖЕНИЕ А

Информация о проекте «ForPlan»

Рисунок A.1 – Диаграмма вариантов использования компьютерной

программы «ForPlan»

Обновление выборки

Конфигурирование выборки

Конфигурирование анализа

Отображение результатов

Отображение в графическом виде

Отображение в табличном виде

Формирование документации по результатам анализа

<<extend>>

Отображение в виде текстовых рекомендаций

Выбор статистики из источников данных предприятия

<<extend>>

Проведение анализа

<<include>>

<<include>>

Вызов информационной справки

Пользователь

<<include>>

<<include>>

<<include>>

<<include>>

180

Таблица А.1 – Перечень работ по созданию компьютерной программы

Номер

п/п Название задачи

Длительность

в часах

1 2 3

Первый этап – Создание алгоритмического ядра

1

Схематическое представление входных и выходных данных

для метода 1 6

2

Создание программных сущностей для входных и выходных

данных для метода 1 10

3 Изучение метода 1 16

4 Реализация метода 1 20

5 Создание тестов и набора тестовых данных для метода 1 12

6

Схематическое представление входных и выходных данных

для метода 2 6

7

Создание программных сущностей для входных и выходных

данных для метода 2 10

8 Изучение метода 2 16

9 Реализация метода 2 20

10 Создание тестов и набора тестовых данных для метода 2 12

11

Схематическое представление входных и выходных данных

для метода 3 6

12

Создание программных сущностей для входных и выходных

данных для метода 3 10

13 Изучение метода 3 16

14 Реализация метода 3 20

15 Создание тестов и набора тестовых данных для метода 3 12

16

Схематическое представление входных и выходных данных

для метода 4 6

17

Создание программных сущностей для входных и выходных

данных для метода 4 10

18 Изучение метода 4 16

19 Реализация метода 4 20

20 Создание тестов и набора тестовых данных для метода 4 12

21

Создание простейшей системы ввода-выводы входных и

выходных данных(чтение из файла - вывод на консоль) 7

22 Настройка инструментов разработки 12

Второй этап – Проектирование интерфейса для редактирования введенных данных и

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

1

Анализ возможных ситуаций, требующих ручного

редактирования 12

2

Анализ изменяемых параметров методов, выбор наиболее

практичных конфигураций 12

3 Проектирование дизайна для формы редактирования данных 15

181

Продолжение таблицы А.1

4

Проектирование дизайна для формы конфигурирования

вычислений 15

5 Создание формы для редактирования входных данных 32

6 Создание формы конфигурирования вычислений 32

7 Создание автоматических тестов для формы редактирования 12

8 Создание автоматических тестов для формы конфигурированя 14

9 Тестирование на удобство пользования и общую стабильность 40

10 Рефакторинг и исправление ошибок 32

Третий этап – Проектирование интерфейса для вывода результатов методов 1 и 2

1 Описание графических и табличных результатов для метода 1 6

2 Описание графических и табличных результатов для метода 2 6

3

Проектирование дизайна для форм отображения графических

результатов 12

4

Проектирование дизайна для форм отображения табличных

результатов 12

5

Проектирование дизайна для форм с автоматическим

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

6

Разработка алгоритмов для автоматического анализа

результатов метода 1 9

7

Разработка алгоритмов для автоматического анализа

результатов метода 2 9

8

Создание формы вывода графических результатов для метода

1 12

9

Создание формы вывода графических результатов для метода

2 12

10 Создание формы вывода табличных результатов для метода 1 12

11 Создание формы вывода табличных результатов для метода 2 12

12 Реализация автоматического анализа для результатов метода 1 18

13

Реализация автоматического анализа для результатов метода

2 18

14 Тестирование вывода результатов для метода 1 24

15 Тестирование вывода результатов для метода 2 24

16 Рефакторинг и исправление ошибок 32

17

Консультация относительно особенностей реализации

методов 12

Четвертый этап – Проектирование интерфейса для вывода результатов методов 3 и 4

1 Описание графических и табличных результатов для метода 3 6

2 Описание графических и табличных результатов для метода 4 6

3

Проектирование дизайна для форм отображения графических

результатов 12

4

Проектирование дизайна для форм отображения табличных

результатов 12

5

Разработка алгоритмов для автоматического анализа

результатов метода 3 9

6

Разработка алгоритмов для автоматического анализа

результатов метода 4 9

182

Окончание таблицы А.1

7

Создание формы вывода графических результатов для метода

3 12

8

Создание формы вывода графических результатов для метода

4 12

9 Создание формы вывода табличных результатов для метода 3 12

10 Создание формы вывода табличных результатов для метода 4 12

11

Реализация автоматического анализа для результатов метода

3 18

12

Реализация автоматического анализа для результатов метода

4 18

13 Тестирование вывода результатов для метода 3 24

14 Тестирование вывода результатов для метода 4 24

15 Рефакторинг и исправление ошибок 32

16

Консультация относительно особенностей реализации

методов 12

Пятый этап – Формирование документации и создания средств для работы с внешними

источниками входных данных

1 Написание документации к реализованному функционалу 26

2

Консультации касательно практичности справочной

информации 10

3 Написание кода для обработки и накопления внешних данных 32

4

Анализ предоставляемых внешних данных и описание

алгоритмов преобразования 32

5

Написание тестов, покрывающих преобразование и

сохранение внешних данных 17

6 Настройка инструментов разработки 12

7 Наладка работы приложения с внешней системой 32

8

Тестирование стабильности системы при работе с внешними

данными 32

9 Рефакторинг и исправление ошибок 32

183

Рисунок А.2 – Организационная структура команды разработки

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

осуществлением проекта Название должности Количество

единиц

Почасовая ставка,

грн.

Project manager 1 170

Senior programmer 1 180

Junior programmer 2 130

Business analyst 1 150

Quality assurance engineer (Functional testing) 1 130

Quality assurance engineer (Non-Functional testing) 1 100

Таблица А.3 – Перечень функциональных обязанностей участников

команды и опыт работы

Должность Опыт работы Описание деятельности

1 2 3

Project manager 2-2,5 года Осуществляет контроль выполнения объемов работ в

соответствии с установленным графиком работ и

принимает координирующие решения.

Контролирует и направляет работу отделов разработки,

бизнес анализа и тестирования, осуществляет

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

проекта

184

Окончание таблицы А.3 1 2 3

Senior

programmer

5 лет Отвечает за архитектуру проекта, выбор технологий

разработки, реализацию решений низкого уровня,

контроль и координацию деятельности других

программистов

Junior

programmer

1,5 – 2 года Занимается написанием программного кода

Business analyst 4-5 лет Отвечает за разработку математического аппарата

программного продукта и за алгоритмическую

интерпретацию математического аппарата

Quality assurance

engineer

(Functional

testing)

1,5 - 2 года Может быть консультантом по математической части,

проверяет корректность работы алгоритма,

соответствия входных данных выходным,

корректность построения графиков и вывод

результатов.

Quality assurance

engineer (Non-

Functional

testing)

До 1 года Проверяет функциональность графического

интерфейса, его эстетический вид, удобство,

понятность, осуществляет проверку на корректность

выполнения действий

Таблица А.4 - Трудозатраты участников команды на каждом этапе

разработки (без учета управления), часы

Команда

Этапы проекта Трудозатраты

всего

проекта, часы 1 2 3 4 5

Project Manager/Team lead - - - - 26 26

Business analyst 88 24 42 42 42 238

Senior programmer/designer 48 62 68 56 32 266

Junior programmer 53,5 32 42 42 40,5 210

Junior programmer 53,5 32 42 42 40,5 210

Quality assurance engineer

(Functional testing) 12 26 - - 44 82

Quality assurance engineer

(Non-Functional testing) - 40 48 48 - 136

Трудозатраты на каждом этапе 255 216 242 230 225 1168

185

ПРИЛОЖЕНИЕ Б

Операции по управлению проектом «ForPlan» согласно рассматриваемым

методологиям

Таблица Б.1 – Распределение операций между членами команды при

применении методологии PMBOK

Фаза Операции Ответственный Трудозатраты,

часы

1 2 3 4

Подготовительная

Разработка Устава проекта Project manager 16

Определение заинтересованных сторон Project manager 8

Разработка плана управления проектом Project manager 5

Планирование содержания Business

Consultant 5

Определение содержания Project manager 3

Создание иерархичной структуры работ Project manager,

The project team

3

0,75

Определение состава операций Project manager 5

Определение взаимосвязей операций Business

Consultant 3

Оценка ресурсов проекта Business

Consultant 5

Оценка длительности операций Business

Consultant,

The project team

6

1,5

Разработка расписания Business

Consultant 5

Стоимостная оценка Project manager 8

Разработка бюджета расходов Project manager 8

Планирование качества Project manager 8

Разработка плана управления

человеческими ресурсами

Project manager 3

Набор команды проекта Business

Consultant 8

Планирование коммуникаций Business

Consultant 5

Планирование управления рисками Project manager 16

Идентификация рисков Project manager 8

Качественный анализ рисков Project manager 5

Количественный анализ рисков Project manager 8

Планирование реагирования на

известные риски

Business

Consultant 16

Завершение проекта или фазы Project manager 8

186

Окончание таблицы 2.11

Фаза Операции Ответственный Трудозатраты,

часы

1 2 3 4

Фаза выполнения

Руководство и управление исполнением

проекта

Project manager 145,6

Мониторинг и управление работами

проекта

Project manager 72,8

Осуществление общего управления

изменениями

Project manager 72,8

Управление содержанием Project manager 52

Управление расписанием Project manager 31,2

Управление стоимостью Project manager 135,2

Процесс контроля качества Project manager 41,6

Развитие команды проекта Project manager, The project team

31,2

Управление командой проекта Project manager 41,6

Распространение информации Project manager, The project team

52

Подтверждение содержания Project manager 5

Обеспечение качества Project manager, The project team

5

Управление участниками проекта Project manager 62,4

Подготовка отчетов о исполнении Project manager, The project team

104

Мониторинг и управление рисками Project manager 72,8

Проект по созданию программного обеспечения «ForPlan» не

предполагает закупку оборудования, инструментов и средств для разработки

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

по управлению данным проектом согласно методологии PMBOK такие

процессы как – планирование покупок, планирование контрактов, запрос

информации у продавцов, выбор продавцов, администрирование контрактов

и закрытие контрактов не вошли.

Таблица Б.2 – Распределение операций между членами команды при

применении методологии PRINCE2

Процесс

Операции Ответственный Трудозатраты, часы

1 2 3 4

Процесс

запуска

Составить мандат проекта Project Steering Committee

16

Описать обязанности исполнительного директора

Project Steering Committee

3

Выбрать и назначить Executive director

Project Steering Committee

12

187

Продолжение таблицы Б.2

1 2 3 4

Описать обязанности Project

manager’a Executive director 3

Назначить Project manager’a Executive director 16

Разработать журнал ежедневного

отчета Project manager 4

Изучить предыдущий опыт:

- изучить предыдущий опыт Project manager 30

- разработать журнал приобретенных

уроков

Executive director /

Project manager 6

Назначить команду проекта:

- обновить журнал ежедневного

отчета Project manager 2

- описать обязанности команды

проекта Project manager 8

- утвердить команду проекта Executive director 40

- определить структуру команды

проекта Project manager 4

Подготовить бизнес-кейс:

- обновить журнал ежедневного

отчета Project manager 2

- написать план бизнес-кейса Executive director 16

- описать продукт проекта Project manager 12

Выбрать проектный подход и составить краткое описание проекта:

- выбрать проектный подход Project manager 12

- составить краткое описание проекта Executive director 15

- обновить журнал ежедневного

отчета Project manager 2

- задокументировать выполненные

действия и полученные уроки Project manager 36

Спланировать этап инициации:

- обновить журнал ежедневного

отчета Project manager 2

- разработать план этапа Project manager 6

- отчитаться перед Project Steering

Committee и получить разрешение на

реализацию проекта

Project manager

3

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

Разрешить инициацию проекта:

- утвердить описание проекта Project manager 8

- утвердить план этапа инициации Project manager 3

Разрешить реализацию проекта:

- разрешить реализацию проекта: Project manager 10

- утвердить проектную

документацию этапа инициации

Project manager 20

- утвердить план выгод Project manager 8

Утвердить план этапа:

- утвердить продукт проекта Project manager 2

- утвердить отчет об окончании этапа Project manager 2

188

Продолжение таблицы Б.2 1 2 3 4

- распространить отчет о

приобретенных уроках Project manager 4

- распространить журнал

рекомендованных действий Project manager 4

- утвердить план следующего этапа Project manager 4

- утвердить план устранения

отклонений Project manager 6

- обновить документацию этапа

инициации

Project manager / The

project team 4

- обновить план выгод Project manager 6

Обеспечить специализированное управление:

- пересмотреть отчет о состоянии

этапа Project manager 6

- среагировать на отчет об

отклонении

Project manager / The

project team 8

- выявить новые проблемы

Project manager /

Executive director /

The project team

4

Утвердить закрытия проекта:

- утвердить отчет о закрытии проекта Project manager 12

- распространить отчет о

приобретенных уроках

Project manager 4

- распространить журнал

рекомендованных действий

Project manager 6

- обновить бизнес-кейс Project manager 4

- обновить план выгод Project manager 6

Процесс инициации

Разработать стратегии управления рисками:

- разработать реестр рисков

Project manager

(Project Support), The

project team

6

- разработать стратегию по

управлению рисками Project manager 20

Подготовить стратегии управления конфигурациями:

- разработать стратегию управления

конфигурациями Project manager 22

- создать запись о конфигурационной

единице

Project manager

(Project Support) 6

- разработать реестр проблем The project team 6

Подготовить стратегии управления качеством:

- разработать стратегию управления

качеством Project manager 25

- разработать реестр качества The project team 8

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

- разработать стратегию управления

коммуникациями Project manager 7

Установить контроль за реализацией проекта:

- разработать механизм

отслеживания (контроля) проекта

Project manager 16

189

Продолжение таблицы Б.2

1 2 3 4

- обновить структуру команды

проекта

Project manager 2

Разработать план проекта:

- разработать план проекта Project manager 8

- обновить запись о

конфигурационной единице

Project manager

(Project Support) 4

- обновить структуру команды

проекта Project manager 1

Уточнить бизнес-кейс:

- разработать план выгод Project manager 16

- составить подробный бизнес-кейс Project manager 40

- составить документацию по

реализации проекта

Executive director /

Project manager 40

- отчитываться перед Project Steering

Committee и получить разрешение

для перехода на следующий этап

Project manager 3

Процесс контроля

Утвердить комплекс работ:

- составить комплекс работ Project manager 20

- создать запись о конфигурационной

единице

Project manager

(Project Support) 16

- обновить реестр качества Project manager

(Project Support) 2

- обновить реестр рисков Project manager / The

project team 3

- обновить реестр проблем Project manager / The

project team 3

- пересмотреть план работы команды Senior programmer 4

- обновить план этапа Project manager 2

Посмотреть статус комплекса работ:

- пересмотреть контрольно-

пропускной отчет Senior programmer 4

- пересмотреть план работы команды Senior programmer 2

- обновить план этапа Project manager 2

- обновить запись о

конфигурационной единице

Project manager

(Project Support) 2

- обновить реестр проблем Project manager / The

project team 3

Получить завершенный комплекс работ:

- подтвердить запись о

конфигурационной единице

Project manager

(Project Support) 4

- обновить план этапа Project manager 2

Посмотреть статус этапа:

- обновить реестр рисков Project manager/ The

project team 3

- обновить реестр проблем Project manager/ The

project team 3

- обновить план этапа Project manager 2

190

Продолжение таблицы Б.2

1 2 3 4

- обновить журнал о приобретенных

уроках Project manager 6

- обновить отчет о проблемах Project manager/ The

project team 2

- разработать отчет о состоянии этапа Project manager 12

Изучить проблемы и риски:

- обновить журнал ежедневного

отчета Project manager 4

- разработать отчет о проблемах Project manager / The

project team 6

- обновить реестр проблем Project manager/ The

project team 3

- обновить реестр рисков Project manager / The

project team 3

Выявить проблемы и риски:

- разработать отчет об отклонении Project manager 2

- обновить реестр проблем Project manager/ The

project team 3

- обновить реестр рисков Project manager / The

project team 3

- обновить отчет о проблемах Project manager/ The

project team 4

Принять корректирующие действия:

- обновить реестр проблем Project manager / The

project team 3

- обновить реестр рисков Project manager / The

project team 3

- обновить отчет о проблемах Project manager / The

project team 4

- обновить план этапа Project manager 2

- обновить запись о

конфигурационной единице Project manager 2

- обновить журнал ежедневного

отчета Project manager 4

Поставка продукта

Разработать комплекс работ:

- составить план работы команды Project manager 4

- обновить реестр качества Project manager

(Project Support) 2

- утвердить комплекс работ Project manager 3

- выявить новые риски Senior programmer /

The project team 4

Выполнить комплекс работ:

- разработать продукт проекта Senior programmer /

The project team 0

- обновить реестр качества The project team 2

- обновить запись о

конфигурационной единице Project manager 2

191

Продолжение таблицы Б.2

1 2 3 4

Выполнить комплекс работ:

- разработать продукт проекта Senior programmer /

The project team 0

- обновить реестр качества The project team 2

- обновить запись о

конфигурационной единице Project manager 2

- обновить план работы команды Senior programmer 1

- разработать контрольно-

пропускной отчет

Senior programmer /

The project team 10

- выявить новые риски Senior programmer /

The project team 3

- выявить новые проблемы Senior programmer /

The project team 3

Сдать комплекс работ:

- обновить комплекс работ Senior programmer 4

- обновить план работы команды Senior programmer 3

- отчитываться перед Заказчиком и

получить разрешение для перехода

на следующий этап

Senior programmer 3

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

Планирование этапа завершения:

- обновить проектную

документацию плана инициации

Project manager / The

project team 8

- разработать план этапа Project manager 10

- обновить запись о

конфигурационной единице

Project manager 2

- обновить реестр рисков Project manager / The

project team 3

- обновить реестр проблем Project manager / The

project team 3

- обновить реестр качества The project team 2

Обновить план проекта:

- обновить план проекта Project manager 6

- обновить реестр проблем Project manager / The

project team 3

- обновить реестр рисков Project manager / The

project team 3

- обновить бизнес-кейс Project manager 4

- обновить план выгод Project manager 6

- обновить реестр проблем Project manager / The

project team 3

- обновить реестр рисков Project manager / The

project team 3

Отчет об окончании этапа:

- разработать отчет об окончании

этапа Project manager 2

- разработать отчет о

приобретенных уроках Project manager 2

- создать журнал рекомендованных Project manager / The 6

192

Продолжение таблицы Б.2

1 2 3 4

действий project team

Разработка плана устранения отклонений:

- обновить проектную

документацию плана инициации

Project manager / The

project team 16

- разработать план устранения

отклонений Project manager 12

- обновить запись о

конфигурационной единице The project team 2

- обновить реестр проблем Project manager / The

project team 3

- обновить реестр рисков Project manager / The

project team 3

- обновить реестр качества The project team 2

Завершение

Подготовить данные для запланированного закрытия проекта:

- обновить план проекта Project manager 2

- составить отчет о состоянии

продукта The project team 6

Подготовить данные для преждевременного закрытия проекта:

- обновить реестр проблем Project manager / The

project team 3

- обновить план проекта Project manager 4

- составить отчет о состоянии

продукта The project team 6

- составить дополнительную оценку

работы

Project manager / The

project team 12

Передать продукт высшему руководству:

- обновить журнал

рекомендованных действий Project manager 10

- обновить запись о

конфигурационной единице The project team 2

- обновить план выгод Project manager 8

Оценить проект:

- составить окончательный отчет

проекта

Project manager 20

- составить отчет приобретенных

уроков

Project manager 16

- отчитываться перед Заказчиком Project manager 3

- отправить запрос на закрытие

проекта Executive director 8

193

Окончание таблицы Б.2

1 2 3 4

Закрытие проекта:

- заполнить реестр проблем Project manager / The

project team 8

- заполнить реестр рисков Project manager / The

project team 12

- заполнить реестр качества Project manager 6

- заполнить журнал ежедневного

отчета

Project manager 8

- заполнить журнал приобретенных

уроков

Project manager / The

project team 24

- подготовить отчет о закрытии

проекта Project manager 2

Таблица Б.3 – Распределение операций между членами команды при

применении методологии Р2М

Фаза Операции Ответственный

Трудо-

затраты,

часы

1 2 3 4

Разработка Формулирование миссии проекта Investor

Project manager 3

Описание миссии в виде сценариев Project manager 24

Формулирование целей и задач проекта Project manager 8

Технологическая оценка продукта проекта Project manager 8

Планирование

Утверждение миссии Investor

Project manager 4

Утверждение задач и целей Project manager 4

Выбор лучших из вариантов сценариев Project manager 8

Определение графика проекта Project manager 16

Определение этапов сдачи проекта Project manager 4

Определение ограничений, допущений, календарей Project manager 12

Определение содержания проекта Project manager 4

Разработка структуры декомпозиции работ Project manager 16

Создание команды проекта Project manager 8

Разработка организационной структуры Project manager 6

Создание матрицы ответственности по выполнению

работ

Project manager 12

Разработка сетевого графика работ и рабочих процедур Project manager 16

Определение заинтересованных сторон проекта Investor

Project manager 8

Оценка ресурсов проекта Project manager 5

Идентификация рисков Project manager 24

Подготовка отчетов по рискам Project manager

The project team

8

6

Выполнение противорисковых мер Project manager 32

194

Продолжение таблицы Б.3

1 2 3 4 Реализация

Организация взаимодействия между всеми

участниками проекта

Project manager

The project team

12

6

Управление временем:

Анализ изменений и отклонений от календарного

плана

Project manager

The project team

24

12

Оптимизация используемых ресурсов Project manager 16

Улучшение производительности труда Project manager

The project team

20

10

Управление стоимостью:

Оценка стоимости проекта и оптимальное

распределение бюджета

Project manager 24

Прогнозирование доходности проекта Project manager 20

Управление качеством:

Планирование качества Project manager 32

Проверка качества Project manager

The project team

48

24

Осуществление оценки прогресса проекта (метод

управления освоенным объемом)

Project manager 8

Отслеживание фактического выполнения проекта Project manager

The project team

16

8

Определение причин проблемы Project manager 24

Выполнение корректирующих действий Project manager 32

Контроль над факторами окружения проекта

(изменения, конфликты, преграды)

Project manager

The project team

16

8

Завершение процесса создания продукта Project manager

The project team

16

8

Тестовый запуск Project manager

The project team

16

8

Подготовка отчетов о выполнении каждой фазы и

проведение собрания с участием всех

заинтересованных сторон

Investor

Project manager

The project team

44

22

Координация

Осуществление оценки прогресса проекта (метод

управления освоенным объемом) Project manager 8

Отслеживание фактического выполнения проекта Project manager

The project team

16

8

Определение причин проблемы Project manager 24

Выполнение корректирующих действий Project manager 32

Контроль над факторами окружения проекта

(изменения, конфликты, преграды)

Project manager

The project team

16

8

Завершение

Завершение процесса создания продукта

Project manager

The project team

16

12

Тестовый запуск

Project manager

The project team

16

12

Подготовка отчетов о выполнении каждой фазы и

проведения собрания с участием всех

заинтересованных сторон

Investor

Project manager

The project team

44

33

195

Таблица Б.4 – Распределение операций между членами команды при

применении методологии SWEBOK

Фаза Операция Ответственный Трудозатраты,

часы

1 2 3 4

Инициирование

и

определение

содержания

Определение и обсуждение требований Project manager 15

Анализ осуществимости Project manager 3

Процесс оценки и пересмотра требований Project manager 8

Планирование программного

проекта

Планирование процесса реализации проекта Project manager

The project team

16

8

Определение результатов процесса

планирования

Project manager 4

Оценка усилий, расписания и стоимостных

данных

Project manager 20

Распределение ресурсов Project manager 6

Управление рисками:

идентификация и анализ рисков Project manager

The project team

20

10

определение необходимых мер для

смягчения последствий при

возникновении рискового события

Project manager 10

Управление качеством Project manager

The project team

30

15

Управление планом проекта Project manager 20

Выполнение программного

проекта

Реализация планов

план управления проектом Project manager

The project team

20

16

план управления содержанием Project manager

The project team

30

24

план управления качеством Project manager

The project team

30

24

план управления рисками Project manager

The project team

30

24

план управления сроками Project manager

The project team

25

20

план управления стоимостью Project manager

The project team

25

20

Реализация процесса по введению

изменений в проект

Project manager

The project team

64

51,2

Процесс мониторинга выходов и условий

завершенности

Project manager 16

Процесс контроля выходов Project manager 20

196

Окончание таблицы Б.4

1 2 3 4

Ведение отчетности

по общему состоянию проекта (для

заказчика)

Project manager 20

Подробные отчеты отдельных групп в

команде, отдельных работ, групп

требований, функциональных модулей

Project manager

The project team

30

24

Обзор

и оценка

Определение удовлетворения требованиям

заказчика

Project manager 8

Оценка производительности и / или

результативности специалистов

Project manager

The project team

16

Закрытие

Определение критериев закрытия проекта Project manager 16

8

Работы по закрытию проекта: сдача и

закрытие проекта

Investor

Project manager

The project team

44

22

Измерения

Установка и поддержка процесса измерений Project manager 16

Планирование процессов измерений Project manager 20

Выполнение процессов измерений Project manager

The project team

25

20

Оценка измерений Project manager 15

197

ПРИЛОЖЕНИЕ В

198

ПРИЛОЖЕНИЕ Г

199

200

ПРИЛОЖЕНИЕ Д

201

202

ПРИЛОЖЕНИЕ Е

203