CC BY
28
Уточнено визначення поняття «методо-логiя управлтня проектом». Запропоновано метод i математичну модель синтезу методологи управлтня для умов конкретного проекту. Математична модель вра-ховуе нечттсть вихидних даних, що вид-носяться до проекту та його оточення. Прошюстровано роботу наведеного методу на nрикладi проекту, присвяченого створен-ню програмного забезпечення
Ключовi слова: управлтня проектом, методологiя, визначення, метод синтезу,
математична модель, нечтк дат
□-□
Уточнено определение понятия «методология управления проектом». Предложены метод и математическая модель синтеза методологии управления для условий конкретного проекта. Математическая модель учитывает нечеткость исходных данных, относящихся к проекту и его окружению. Проиллюстрирована работа приведенного метода на примере проекта, посвященного созданию программного обеспечения
Ключевые слова: управление проектом, методология, определение, метод синтеза, математическая модель, нечеткие данные
УДК 519.857.6
|DOI: 10.15587/1729-4061.2016.656711
ПРИМЕНЕНИЕ МЕТОДА СИНТЕЗА МЕТОДОЛОГИИ
УПРАВЛЕНИЯ ПРОЕКТОМ ПРИ НЕЧЕТКИХ ИСХОДНЫХ
ДАННЫХ
И. В. Кононенко
Доктор технических наук, профессор, заведующий кафедры* E-mail: igorvkononenko@gmail.com А. А га и Аспирант*
E-mail: ahmadaghaee@yahoo.com С. Ю. Луцен ко*
E-mail: lutsenkosyu@gmail.com *Кафедра стратегического управления Национальный технический университет «Харьковский политехнический институт» ул. Багалия, 21, г. Харьков, Украина, 61002
1. Введение
В настоящее время в мире существует ряд стандартов и руководств, а также многие десятки методологий управления проектами. Они предлагают широкий ассортимент процессов для управления проектами различной сложности и при различной степени ответственности за результат.
Находят применение как тяжелые plan-driven, так и гибкие Agile методологии, которые отличаются количеством и детализацией процессов управления, универсальностью применения.
Многообразие существующих подходов значительно усложняет задачу выбора адекватной методологии для управления конкретным проектом или всеми проектами компании. Для того чтобы оценить пригодность методологии для управления проектом, необходимо вначале ее детально изучить, а для этого необходимы и время и средства. Многие известные методологии отличаются своей неполнотой или незавершенностью.
Выбор методологии для управления конкретным проектом оказывает существенное влияние на содержание проекта, на его параметры, а также на параметры продукта. Такой выбор является достаточно ответственной задачей, которую приходится решать руководству организаций и командам управления проектами.
В свете изложенного актуальной является разработка методов выбора существующей или создания
специальной методологии для управления отдельным проектом либо всеми проектами компании.
2. Анализ литературных данных и постановка проблемы
В исследовании [1] подчеркнуто, что выбор методологии для конкретного проекта важен, так как он может определить успех с точки зрения эффективности, качества или вообще возможности завершения проекта.
Многие авторы акцентируют внимание на незавершенности существующих методологий и стандартов управления проектами и, как следствие, на необходимости их дополнения рядом процессов или областей знаний. Так в работах [2, 3] путем сравнения процессов управления проектами, представленных в стандарте PMBoK [4], с компонентами гибких методологий управления проектами показано, что гибкие методологии управления проектами нельзя считать совершенными. Ряд процессов в них либо отсутствует (процессы управления стоимостью и закупками) или не описаны явно (процессы управления рисками). Авторы считают, что сочетание гибких методологий с PMBoK будет полезно для управления проектами в области IX
В работе [5] предлагается дополнять общие методологии процессом управления выгодами, приводится структура данного процесса и иллюстрируется его сочетание с общими методологиями на примере
©
методологии PRINCE2. Авторы статьи [6] в качестве дополнительного процесса предлагают процесс «оптимизация содержания проекта» и приводят входы, выходы, взаимодействие данного процесса с другими процессами стандарта PMBoK, а также инструменты и методы. Автор работы [7] акцентирует внимание на необходимости расширить PMBoK, ISO 21500 и другие стандарты управления проектами, путем добавления трех новых областей знаний: управление организацией проекта, управление устойчивостью проекта и создание концепции проекта.
Ряд работ посвящен вопросам, связанным со способом выбора методологий или их компонентов для применения в условиях отдельных проектов.
В работе [8] предлагается осуществлять выбор определенного набора процессов управления проектом, который лучше всего удовлетворит его потребности. При этом набор процессов определяется исходя из значений следующих параметров проекта: характер проекта (его критичность и сложность), размер проекта, размер команды, количество заинтересованных сторон и их местоположение, опыт менеджера проекта, требования гибкости, понимание клиента, его доступность, бюджет, время, риски, итеративность процесса разработки, уровень навыков команды и тип команды. Авторами предложена комплексная методология, которая включает выбранные из PMBOK, PRINCE2, Tenstep и SCRUM процессы, то есть процессы, взятые как из традиционных, так и из гибких методологий, с целью получения преимуществ каждого из подходов. Приведены рекомендации по выбору процессов с учетом перечисленных параметров [8].
Работа [9] сосредоточена на идее создания специальной методологии для проекта на основе различных подходов. При этом выбор элементов, которые будут составлять такую методологию, должен базироваться на характеристиках конкретного проекта и организации, опыте менеджера проекта и знаниях эксперта. В работе произведено сравнение гибких и тяжелых методологии по ряду показателей (четкость требований к проекту и продукта, участие пользователей в проекте и др.). На основе данного сравнения, автор приходит к выводу, что, возможно, лучшей методологией могла бы быть комбинация элементов, основанных на традиционном и гибком подходах, так как ни полностью гибкая, ни полностью традиционная методология управления не подходят в полной мере [9].
В работе [10] предложен метод синтеза методологии управления проектом, основанный на оптимизации содержания проекта по таким критериям как стоимость управления проектом, трудоемкость управления проектом и риски, связанные с применением синтезируемых методологий. В качестве основы для синтеза предлагается использовать «полную» методологию, которая содержит в себе процессы из самых востребованных известных традиционных и гибких методологий. Авторами приведены модель и метод синтеза методологии управления проектом для ситуации, когда информация о проекте и его окружении является нечеткой [10]. Актуальным является уточнение понятия «методология управления проектом», дальнейшее развитие метода, предложенного в работе [10], а также применение его для решения конкретной задачи синтеза методологии.
3. Цель и задачи исследования
Целью статьи является разработка и применение метода синтеза методологии управления проектом, работоспособного при нечетких исходных данных.
Для достижения поставленной цели необходимо решить ряд задач:
- уточнить понятие «методология управления проектом»;
- предложить метод синтеза методологии управления проектом при нечетких исходных данных;
- применить метод синтеза методологии управления для проекта по созданию программного обеспечения оптимизации содержания проекта «PTCQR Project Scope Optimization» [6] и проанализировать результаты.
4. Метод и нечеткая математическая модель синтеза методологии управления проектом
Применение метода синтеза методологии управления проектом [10] возможно, если итоговый результат, получаемый при его использовании, отвечает определению «методологии». Рассмотрим, что же конкретно подразумевается под понятием «методология».
По мнению автора работы [11] методология управления проектом представляет собой набор руководящих указаний или принципов, которые могут быть адаптированы и применены к конкретной ситуации. В проектной среде эти принципы могут представляться как перечень работ, которые должны быть выполнены в ходе проекта [11].
В соответствии с глоссарием, приведенным в [4], методология - это система практик, методов, процедур и правил, используемых в определенной сфере деятельности. Позднее в издании PMI [12] указывалось, что более конкретно, методология управления проектами представляет собой определенный, задокументированный и обнаруживаемый набор политик, практик, процессов, инструментов, методов и шаблонов, которые обеспечивают руководство тем, как проекты выполняются в рамках организации.
В свою очередь, политика в данном контексте - это структурированная модель действий, принятая организацией. Политику организации можно определить как набор основных принципов, регламентирующих деятельность организации [4].
Практика - это особый тип профессиональной или управленческой деятельности, которая вносит свой вклад в выполнение процесса и может использовать один или несколько методов и инструментов [4].
Процесс - систематическая последовательность действий, направленная на достижение конечного результата, при этом один или несколько входов преобразуются в один или несколько выходов [4].
Процедуру PMBoK определяет, как установленный метод достижения последовательного исполнения или результата. Процедуру, как правило, можно описать как последовательность шагов, которые будут использоваться для выполнения процесса [4].
Не следует из определения понятия методология управления проектом исключать правила. Правило (rule, англ.) - это предписанное руководство для по-
уз
ведения или действия [13]. Именно правила должны объединять составляющие в одно целое, создавать определенный порядок, систему.
Более того, методология управления проектом должна содержать организационную структуру, прописанные роли участников, жизненный цикл проекта. С другой стороны, инструменты, методы и шаблоны для осуществления конкретной методологии могут быть представлены многими вариантами. Включать их в понятие методологии нецелесообразно, поскольку они могут меняться.
В результате приходим к следующему определению. Методология управления проектами представляет собой определенный и задокументированный набор политик, правил, процессов, практик, жизненного цикла, организационной структуры, прописанных ролей, которые обеспечивают руководство выполнением проекта в рамках организации.
В работе [10] предлагалось создать «полную» методологию на основе процессов из многих известных методологий. Поскольку, с одной стороны, методологий очень много и трудно все охватить, а с другой - постоянно появляются все новые и новые, более целесообразно ее назвать «обобщенной» методологией, которая вберет в себя процессы ряда существующих методологий, однако, не будет претендовать на полноту.
Так как методология - это не только процессы, для создания обобщенной методологии наряду с множеством процессов необходимо собрать информацию о политиках, правилах, практиках, организационных структурах, прописанных ролях, жизненных циклах проекта всех рассматриваемых методологий.
Исходя из вышесказанного, предложенный в работе [10] метод представляет собой метод выбора процессов управления проектом, которые еще не являются в полном смысле методологией. Для достижения соответствия результата применения данного метода определению понятия «методология», необходимо привнести в него ряд дополнений. При этом предлагается следующий метод синтеза методологии управления проектом.
Осуществляется анализ стандартов, сводов знаний по управлению проектами, наиболее востребованных и перспективных методологий управления проектами. На основании этого анализа формируется собрание политик, правил, процессов, практик, жизненных циклов и организационных структур проекта, возможных ролей участников, распределений их ответственности в проекте. Отобранные процессы распределяют по областям знаний и группам процессов. В итоге получают «обобщенную» методологию управления проектами, которая может использоваться при синтезе методологии для условий конкретного проекта.
Применительно к каждому конкретному проекту выполняют следующие действия:
1. Эксперт или группа экспертов на основании информации, представленной в обобщенной методологии, выбирают для конкретного проекта политики, правила, процессы, практики, жизненный цикл и организационную структуру проекта, производят распределение ролей, ответственности в проекте. При этом процессы выбирают в областях знаний «обобщенной» методологии и определяют связи между ними, а так-
же связи с процессами жизненного цикла продукта. Как правило, эксперты имеют возможность задать несколько комбинаций компонентов обобщенной методологии, по их мнению, наиболее соответствующих проекту. В результате получают несколько методологий, из которых предстоит сделать выбор.
2. Для выбранных процессов назначают инструменты и методы их выполнения, а также подходящие шаблоны.
3. Решается задача выбора лучшей методологии для конкретного проекта. В качестве критериев для оптимизации применяются: трудоемкость выполнения операций управления, стоимость выполнения операций управления и риски, им сопутствующие.
4. Выбранную методологию применяют для управления проектом.
5. При осуществлении проекта проводится периодическая подстройка процессов, связей между ними, других компонентов методологии, инструментов, методов, шаблонов. В качестве критериев для подстройки применяются: трудоемкость выполнения операций управления, стоимость выполнения операций управления и риски, им сопутствующие.
В математической модели задачи синтеза методологии управления проектом, предложенной в работе [10], треугольные нечеткие числа (ТНЧ) приводились как нечеткие числа ^ - Я) -типа. На практике целесообразно использовать следующее определение ТНЧ: треугольным нечетким числом А называется тройка (а,Ь,с^, (а < Ь < с) действительных чисел, через которые его функция принадлежности цА (х) определяется как [14]:
^а (х ) =
1 - ^—Х, если х е[а;Ь];
1-
Ь - а х - Ь
, если х е[Ь;с];
с - Ь
0, в противном случае.
(1)
Второе число Ь тройки ^а,Ь,с^, как правило, называют модой или четким значением ТНЧ. Числа а и с характеризуют степень размытия четкого числа (а -начало интервала, с - конец интервала) [14].
Если А = ^аА,ЬА,сА^ и В = (аВ,ЬВ,сВ^ треугольные нечеткие числа, а у - скаляр, то основные арифметические операции над этими числами осуществляются по следующим законам [15]:
А + В = (аА + ав,ЬА + Ьв,СА + сД (2)
А Х В = {аАаВ, ЬАЬВ, сАсВ },
ух А = ^А, Ч^, У=А).
Произведем соответствующие преобразования в представлении параметров задачи синтеза методологии управления проектом [10].
Стоимость выполнения j -го процесса, относящегося к одной из рассматриваемых методологий в Ь-й комбинации процессов, обозначим
где j = 1,.]Ь,Ь = 1,Н. Н - количество комбинаций процессов, ^ - количество возможных процессов в Ь-й комбинаций процессов.
Тогда целевая функция задачи - стоимость управления проектом будет равна
Н / ,
С(Х):= ЕЕ (% ,Ьс)Ь,% )хЬ ^ пш,
Ь=1 4 ' 1 '
(4)
Т1Ь = <аТ)Ь,ЬХь,Сть ),1 = 1,]ЬЬ =1,Н.
Целевая функция, которая определяет трудоемкость управления проектом, примет вид
Т(Х) = ЕЕ(ат)Ь,Ьт)Ь,ст^}хь ^™п,
Ь=1 1=1
Vlh =а^Чл).
Р1Ь = (^ЛлУ
Н ^
с(Х) = ЕЕ(ас,ь,Ьс,ь,Сс,)хк <^
Ь=1 1=1
Хор' = а^пиппах {Спогт (Х),Тпогт (Х),Япогт (X)}, (11)
Н
С(Х) = ЕЕас,ь,Ьс,ь,Сс,)хь <^ (12) Ь=1 1=1
ЕЕхь=1, (13)
хЬ е{0,1},хЬ = 1, если Ь-я комбинация процессов используется для управления проектом, хЬ = 0 в противном случае.
Трудоемкость выполнения 1-го процесса, относящегося к одной из рассматриваемых методологий в Ь-й комбинации процессов, обозначим
хЬ е{0,1},Ь = 1,Н,
(14)
где Х = (х1,х2,...,хН),хЬ = 1, если Ь- я комбинация процессов используется для управления проектом, хЬ = 0 в противном случае.
(5)
(6)
Хор' = (х°р',х2Р',...,хН"),
попп с (Х)- сор' V / сор1 '
погп ( и Т(Х)- Тор'
\ / Тор1 '
Я- (Х)=
(15)
(16)
(17)
(18)
Негативные последствия 1-го рискового события, связанного с применением Ь-й комбинации процессов, обозначим
(7)
Полагаем, что негативные последствия 1-го рискового события оцениваются в баллах по десятибалльной системе. При этом предлагается воспользоваться шкалой оценок, представленной в [10].
Вероятность наступления 1-го рискового события, связанного с применением Ь-й комбинации процессов, обозначим
(8)
Целевая функция, которая отражает системные риски при применении выбранного сочетания процессов управления проектом, имеет вид
к (х)=Е Е^лх,, =
Ь=1 1=1
Н ь
=ЕЕ( ^чААлч.К ^ пХп. (9)
Ограничение на стоимость выполнения операций по управлению проектом будет следующим
где сор', Тор', Яор' - минимальные значения стоимости, трудоемкости управления проектом и рисков, связанных с применением синтезируемой методологии, соответственно.
Минимальные значения сор', Тор', Яор' будем находить в результате однокритериальной комбинаторной оптимизации, для осуществления которой необходимо решать задачу сравнения нечетких чисел.
Нечеткое число А больше нечеткого числа В , если любое значение носителя нечеткого числа А больше любого значения носителя нечеткого числа В [16], то есть
А > В ^{х1 > х2|Ух1 еА5,Ух2 еВ5}, (19)
А ={х1 е X | ц а (х1 )> 0^ еХ,
В5 = {х2 еХ|цв(х2)>0}Ух2 еХ.
Для сравнения нечетких чисел будем использовать процедуру дефаззификации методом центра масс или центроида площади [17], предполагающую определение некоторого четкого значения нечеткого числа.
Для ТНЧ А, имеющего функцию принадлежности fk (х, а, Ь, с), координата центра масс составляет
d = -
(10)
где Срег - максимально допустимая величина стоимости всех операций по управлению проектом.
Решение задачи (4), (6), (9), (10) будем находить в виде
(20)
то есть дефаззифицированное значение А равно d.
В приведенном выше виде, нечеткую математическую модель выбора процессов управления рекомендуется применять на практике. Данное ее представление позволяет упростить расчеты и повысить наглядность результатов использования представленного метода.
5. Применение метода синтеза методологии управления трудоемкости и стоимости выполнения процессов для для проекта по созданию программного обеспечения рассматриваемой методологии.
Предложенный метод применен для синтеза методологии управления проектом в области IT. Основные сведения о проекте.
1. Проект посвящен разработке программного обеспечения для оптимизации содержания проекта «PTCQR Project Scope Optimization».
2. Ограничение на стоимость управления проектом - 40000 грн.
3. Длительность проекта - 2,5 мес.
4. Жизненный цикл программного продукта составляют процессы, соответствующие международному стандарту [18].
Для выполнения данного проекта экспертом было выбрано два разных жизненных цикла: предиктивный и адаптивный [4].
В случае применения предиктивного жизненного цикла предложено использовать организационную структуру проекта, в которую входят менеджер проекта (ставка 180 грн./час), два программиста (ставка 120 грн./час) и один тестировщик (ставка 70 грн./час). Предиктивный жизненный цикл предложено осуществлять с помощью комбинации процессов управления, показанной в табл. 1. Данная комбинация была отобрана экспертом из «обобщенной» методологии. Выбранные процессы должны выполняться в соответствии со схемой, показанной на рис. 1, совместно с процессами создания программного продукта. В основном процессы управления выполняются менеджером проекта, однако и члены команды также привлекаются для выбора проектного подхода, сборки проектного брифа, разработки устава проекта, интеграции планов проекта, анализа выполнения всей совокупности планов, принятия решений о выполнении всей совокупности планов. После каждой фазы проекта и по его окончанию также задействована вся команда проекта. В табл. 1 представлены оценки трудоемкости и стоимости выполнения процессов управления проектом с учетом применения конкретных методов, инструментов и шаблонов.
Адаптивный жизненный цикл проекта предложено осуществлять на основе правил, организационной структуры, ролей, событий, артефактов методологии Scrum [19]. Предполагается применение комбинации процессов управления проектом, показанных в табл. 2. В дополнение к традиционным процессам Scrum-а предложено использовать учет выполнения задач на карточках из методологии Канбан [20]. Scrum команда привлекается для выполнения всех указанных процессов. В нее входят владелец продукта (представитель заказчика), Scrum мастер, команда разработки. Функции Scrum мастера выполняет один из программистов (ставка 180 грн./час), кроме того, в команду разработки входят еще один программист (ставка 120 грн./час) и тестировщик (ставка 70 грн./час). В табл. 2 приведены оценки
Рис. 1. Схема выполнения процессов проекта при использовании первой комбинации процессов управления
Таблица 1
Оценки стоимости и трудоемкости процессов для первой методологии
управления
Название процесса Трудоемкость tj, человеко-часы Стоимость, c0, грн./час Общая стоимость по процессу, c = tjO0 , грн.
1. Выбор проектного подхода и сборка проектного брифа (Prince 2) (4,5,5) (450,490,520) (1800,2450,2600)
2. Разработка устава проекта (ISO 21500) (8,11,12) (450,490,520) (3600,5390,6240)
3. Интеграция планов проекта (5,6,8) (450,490,520) (2250,2940,4160)
4. Руководство работы по проекту (ISO 21500) (20,25,30) (180,180,180) (3600,4500,5400)
5. Учет выполнения всей совокупности планов (10,12,14) (180,180,180) (1800,2160,2520)
6. Контроль выполнения всей совокупности планов (10,12,14) (180,180,180) (1800,2160,2520)
7. Анализ выполнения всей совокупности планов (10,12,14) (450,490,520) (4500,5880,7280)
8. Принятие решений о выполнении всей совокупности планов (5,6,8) (450,490,520) (2250,2940,4160)
9. Завершение фазы проекта или проекта (ISO 21500) (5,7,8> (450,490,520) (2250,3430,4160)
Всего по комбинации (77,96,113) - (23850,31850,39040)
Данные о рисках проекта, связанных с применением отобранных методологий, приведены в табл. 3.
Диаграммы результирующих значений стоимости, трудоемкости управления проектом и рисков, связанных с применением методологий, представлены на рис. 2-4.
Таблица 2
Оценки стоимости и трудоемкости процессов для второй методологии управления
Первая комбинация Вторая комбинация
Рис. 2. Диаграмма стоимости управления проектом (грн.)
Название процесса Трудоемкость ti, человеко-часы Стоимость, С , грн./час Общая стоимость по процессу, С = tjC0 , грн.
1. Создание product backlog (Scrum) (6,7,8) (350,370,400) (2100,2590,3200)
2. Планирование Sprint-a (Scrum) (9,10,11) (350,370,400) (3150,3700,4400)
3. Ежедневный Scrum (Scrum) (10,11,12) (350,370,400) (3500,4070,4800)
4. Учет выполнения задач на карточках (Канбан) (5,6,8) (350,370,400) (1750,2220,3200)
5. Обзор Sprint-a (Scrum) (8,9,10) (350,370,400) (2800,3330,4000)
6. Ретроспектива Sprint-a (Scrum) (3,5,6) (350,370,400) (1050,1850,2400)
Всего по комбинации (41,48,55) - (14350,17760,22000)
Первая комбинация Вторая комбинация
Рис. 3. Диаграмма трудоемкости управления проектом (человеко-часы)
Таблица 3
Риски, связанные с применением первой и второй методологий
Рис. 4. Диаграмма рисков, связанных с применением комбинаций
Рисковое событие Вероятность, pj Последствия, vj РисК rpPjVj
№ методологии № методологии
1 2 1 2
Не все требования учтены (0.3,0.3,0.4) (0.5,0.6,0.6) (5,5,6) (1.5,1.5,2.4) (2.5,3,3.6)
Риск ошибки алгоритма (0.2,0.2,0.3) (0.4,0.5,0.6) (3,3,4> (0.6,0.6,1.2) (1.2,1.5,2.4)
Риск ошибок программирования (0.3,0.35,0.4) (0.3,0.4,0.5) (3,3,4> (0.9,1.05,1.6) (0.9,1.2,2)
Риск несовместимости программных блоков (0.28,0.4,0.45) (0.3,0.4,0.5) (5,5,6) (1.4,2.0,2.7) (1.5,2,3)
Риск неглубокого тестирования (0.2,0.35,0.5) (0.2,0.4,0.5) (0.6,1.05,2.0) (0.6,1.2,2)
Риск несовместимости ПО с операционной системой пользователей (0.1,0.25,0.25) (0.2,0.3,0.5) (2,2,2) (0.2,0.5,0.5) (0.4,0.6,1)
Всего по комбинации (5.2,6.7,10.4) (7.1,9.5,14)
Определим, какую из комбинаций наиболее целесообразно применять для рассматриваемого проекта.
Целевые функции (4), (6), (9) примут вид
C(X) = (23850,31850,39040) x1 + +(14350,17760,22000)x2 ^min,
T(X) = (77,96,113)^ + (41,48,55)x2 ^nun, R(X) = (5.2,6.7,10.4)^ + (7.1,9.5,14)x2 ^nun,
где
X = (x1,x2), xh ={0,1},h = 1,2, ¿xh = 1, xh = 1,
h=1
если h-я комбинация процессов используется для управления проектом, xh=0 в противном случае.
Условие (13) выполняется только для комбинаций X = (1,0) и X = (0,1).
Для данных комбинаций, исходя из выражения (19), осуществим проверку ограничения (12) при Cper = 40000 (грн.).
C(1,0) = (23850,31850,39040) < 40000,
C(0,1) = (14350,17760,22000) < 40000.
Все возможные комбинации компонентов удовлетворяют ограничению (12).
Для осуществления процедуры нормирования решим задачу однокритериальной оптимизации целевых функций (4), (6), (9).
При этом сравнивать полученные нечеткие значения будем при помощи процедуры дефаззифика-ции (20)
С (1,0)= 23850 + 31850 + 39040 = 31580,
С^ (0,1)= 14350 +17760 + 22000 = 18036.67,
Td (1,0) = 77 + 96 +113 = 95.333,
Td (0,1)= 41+48 + 55 = 48,
Rd (1,0) = = 7.43,
Rd (0,1)=LiiM+ii=10.2.
Cd (X),Td (X),Rd (X) представляют собой дефаз-зифицированные значения стоимости, трудоемкости управления проектом с помощью рассматриваемых методологий и рисков, связанных с их применением, соответственно.
Определим минимальные значения целевых функций.
Copt = min {31580,18036.67} = 18036.67,
Topt = min {95.333,48} = 48,
Ropt = min {7.43,10.2} = 7.43.
На основе полученных результатов, имеем возможность вычислить нормированные значения (16)-(18)
Cnorm (10)= Cd (1°)- Copt = 31580 -18036.67 = 0751 1 ' ' Copt 18036.67 ' '
Cd (0,1)-Copt 18036.67 -18036.67 „
Cnorm (0,1) = —-—'—-=-= 0,
Copt
18036.67
T"» (1,0)= Td (1,°jp;T°Pt = 95.333 - 48 = 0.986,
T°pt
48
, . Td (0,1)- Topt 48 - 48
Tnorm (0,1) = —-= = 0,
Topt 48
Rnorm (10 )= Rd (l0)- Ropt = 7.43 - 7.43 = 0
l ' / DoPt 7 /.o
Rnorm (0,1)= Rd (0,1)^RoPt = 10.2 - 7.43 = 0.373.
Ropt 7.43
Минимаксный критерий при этом имеет вид
opt . fmax{Cnorm(1,0),Tnorm(1,0),Rnorm(1,0)},{
Xopt = argmin < }• =
I max {Cnorm (0,1), Tnorm (0,1), Rnorm (0,1)} I
[max {0.751,0.986,0},{
= argmin •! !• =
[max{°,°,°.373} J
= argmin {0.986,0.373} = (0,1).
Таким образом, для управления данным проектом наиболее целесообразной является вторая методология. В случае ее применения, стоимость управления проектом составляет (1435°,1776°,22°°°) (грн.), трудоемкость - (41,48,55) (человеко-часов), риски, связанные с применением второй методологии - (7.1,9.5,14).
6. Анализ результатов применения метода синтеза методологии управления проектом
Предложенный метод синтеза методологии управления проектом в условиях нечеткой информации о проекте и его окружении, позволяет выбрать лучшую комбинацию компонентов методологии с максимальной осторожностью (как результат использования минимаксного метода для решения задачи многокритериальной оптимизации). Кроме того, данный метод дает возможность оценить пределы стоимости управления проектом в случае использования данной комбинации, трудоемкости управления проектом и рисков, связанных с ее применением.
Из практических расчетов видно, что конечный результат предложенного метода синтеза методологии управления проектом в значительной степени зависит от компетенции экспертов, которые выбирают альтернативные варианты комбинаций компонентов и оценивают значения трудоемкости, стоимости и риски проекта для каждой из заданных альтернатив. Решение приведенной задачи синтеза методологии для управления проектом предполагает использование метода минимакса в сочетании с полным перебором решений. При полном переборе общее количество комбинаций составляет H = 2n, где n - это количество рассматриваемых компонентов из «обобщенной» методологии. Так как в реальных задачах n измеряется в сотнях, применение полного перебора невозможно. Для сокращения объема перебора, исходя из своих знаний и интуиции, а также рекомендаций по применению процессов из существующих plan-driven и Agile методологий, экспертам необходимо выбрать сравнительно небольшое количество лучших, по их мнению, комбинаций компонентов, которые требуют более глубокого исследования. Привлечение для отбора компонентов более квалифицированных экспертов позволит сократить перебор вариантов и уменьшить трудоемкость подготовки данных.
Метод позволяет учесть степень ответственности команды за результат проекта, срочность его выполнения и многие другие факторы путем оценивания и учета рисков, сопутствующих применению синтезируемой методологии управления в конкретных условиях. Предложенный метод может быть использован для синтеза методологии управления проектом любой сложности в любой отрасли экономики.
7. Выводы
В результате проведенных исследований:
- дано определение понятию «методология управления проектом», которое уточняет ранее существовавшие определения с точки зрения состава компонентов такой методологии;
- предложен метод синтеза методологии для управления конкретным проектом при нечетких исходных данных относительно проекта и его окружения. Его суть заключается в использовании «обобщенной» методологии. Такая методология должна содержать политики, правила, процессы, практики, жизненные циклы, организационные структуры, возможные роли участников, ответственности в проекте из наиболее известных стандартов и методологий. Решается задача
выбора лучшей комбинации таких компонентов по критериям: трудоемкость, стоимость выполнения операций управления и риски, им сопутствующие;
- при помощи предложенного метода определена наилучшая из рассматриваемых в минимаксном смысле методология по критериям трудоемкость, стоимость управления, а также сопутствующие риски для управления проектом по созданию программного обеспечения «PTCQR Project Scope Optimization»;
- на основе анализа проведенных практических расчетов приводятся рекомендации по наиболее эффективному использованию изложенного метода. Утверждается, что привлечение для отбора компонентов методологии более квалифицированных экспертов позволит сократить перебор вариантов и уменьшить трудоемкость подготовки данных.
Литература
1. Ilas, M. E. Selecting the appropriate project management process for R&D projects in microelectronics [Text] / M. E. Ilas, S. Ionescu, C. Ilas // U.P.B. Sci. Bull - Series C. - 2011. - Vol. 73, Issue 1. - P. 105-116.
2. Fitsilis, P. Comparing PMBOK and Agile Project Management software development processes [Text] / P. Fitsilis // Advances in Computer and Information Sciences and Engineering. - 2008. - P. 378-383. doi: 10.1007/978-1-4020-8741-7_68
3. Usman, M. Embedding project management into XP, SCRUM and RUP [Text] / M. Usman, T. R. Soomro, M. N. Brohi // European Scientific Journal. - 2014. - Vol. 10, Issue 15. - P. 293-307.
4. Руководство к своду знаний по управлению проектами (Руководство PMBoK). Пятое издание [Текст]. - USA: PMI,
2013. - 586 с.
5. Karamitsos, I. Benefits Management Process Complements Other Project Management Methodologies [Text] / I. Karamitsos,
C. Apostolopoulos, M. Al Bugami // Journal of Software Engineering and Applications. - 2010. - Vol. 3, Issue 9. - P. 839-844. doi: 10.4236/jsea.2010.39097
6. Кононенко, И. В. Процесс многокритериальной оптимизации содержания проекта при использовании методологии PMBoK [Текст] / И. В. Кононенко, М. Э. Колесник, Е. В. Лобач // Вюник Нацюнального техшчного ушверситету «ХП1». Серiя: Стратепчне управлшня, управлшня портфелями, програмами та проектами. - 2014. - № 2 (1045). - С. 11-17.
7. Reusch, P. J. A. On the role of project organization in project management standards and new approaches for project organization [Text] / P. J. A. Reusch // 12th International Scientific-Practical Conference «Project Management in the development of society», 2015.
8. Cheema, A. Customizing project management methodology [Text] / A. Cheema, A. A. Arshad // 9th International Multitopic Conference, IEEE INMIC, 2005.
9. Spundak, M. Mixed agile/traditional project management methodology - reality or illusion? [Text] / M. Spundak // Procedia -Social and Behavioral Sciences. - 2014ю - Vol. 119. - P. 939-948. doi: 10.1016/j.sbspro.2014.03.105
10. Kononenko, I. V. Model and method for synthesis of project management methodology with fuzzy input data [Text] /
I. V. Kononenko, A. Aghaee // Вюник НТУ «ХП1». Серiя: Стратепчне управлшня, управлшня портфелями, програмами та проектами. - 2016. - № 1 (1173). - С. 9-13.
11. Charvat, J. Project Management Methodologies: Selecting, Implementing, and Supporting Methodologies and Processes for Projects [Text] / J. Charvat. - USA: John Wiley & Sons, INC, 2003. - 264 p.
12. Whitaker, S. The benefits of tailoring: Making a project management methodology fit [Text] / S. Whitaker. - PMI White Paper,
2014. - 23 p.
13. Merriam-webster [Electronic resource]. - Available at: http://www.merriam-webster.com/dictionary/rule
14. Гусева, А.И. Дискретная математика для информатиков и экономистов [Текст]: учеб. пос. / А. И. Гусева, А. Н. Тихомирова. - М: НИЯУ МИФИ, 2010. - 280 с.
15. Zhang, L. Some Similarity Measures for Triangular Fuzzy Number and Their Applications in Multiple Criteria Group Decision-Making [Text] / L. Zhang, X. Xu, L. Tao //Journal of Applied Mathematics. - 2013. - Vol. 2013. - P. 1-7. doi: 10.1155/2013/538261
16. Ибрагимов, В. А. Элементы нечеткой математики [Текст] / В. А. Ибрагимов. - Баку: Азербайджанская госуд. нефтяная академия Баку, 2009. - 391 с.
17. Леоненков, А. Нечеткое моделирование в среде Matlab и fuzzyTECH [Текст] / А. Леоненков. - СПб.: БХВ-Петербург, 2005. - 736 с.
18. ISO/IEC 12207:2008 Systems and software engineering - Software life cycle processes. 2nd edition [Text]. - ISO/IEC, 2008. - 122 p.
19. The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game [Electronic resource]. - Available at: http:// www.scrumguides.org/
20. Anderson, D. J. Kanban: Succesful Evolutionary Change for Your Technology Business [Text] / D. J. Anderson. - Washington: Blue Hole Press, 2010. - 278 p.
