Содержание к диссертации
Введение
Глава 1. Анализ процесса планирования проектов разработки программного обеспечения 11
1.1 Определение понятия проекта 11
1.2 Анализ процесса планирования проектов 12
1.2.1 Определение цели проекта 12
1.2.2 Анализ проблемы планирования ресурсов проекта 12
1.3 Анализ основных методик ведения проектов 14
1.3.1 Треугольник взаимозависимостей частей проекта 14
1.3.2 Обзор методик ведения проектов на основе ограничений 15
1.4 Анализ основных методов прогнозирования сроков проекта 19
1.4.1 Сетевое планирование 20
1.4.2 Метод PERT 21
1.4.3 Метод Монте–Карло 23
1.4.4 Модель планирования проектов COCOMO/COCOMO II 24
1.4.5 Необходимость создания нового метода планирования 25
1.5 Обзор и анализ систем ведения проекта 26
1.6 Выводы 32
Глава 2. Анализ информационной структуры процесса выполнения проекта разработки программного обеспечения 34
2.1 Общая схема и этапы выполнения проекта 34
2.2 Функционально-информационная модель процесса выполнения проекта разработки ПО 36
2.2.1 Инициация проекта и составление списка задач. 36
2.2.2 Построение плана итераций проекта 39
2.2.3 Процесс выполнения задач 40
2.3 Преобразование данных в процессе выполнения проекта разработки программного обеспечения 41
2.3.1 Преобразование данных о требованиях к спискам задач от источников 41
2.3.2 Объединение списков задач 42
2.3.3 Построение графа задач 43
2.3.4 Переопределение приоритетов задач 45
2.3.5 Построение общего списка задач 47
2.3.6 Построение плана проекта 47
2.4 Автоматизация процесса разработки программного обеспечения 48
2.5 Требования к инструментам поддержки принятия решения при планировании и выполнении проекта 53
2.6 Выводы 56
Глава 3. Разработка модели процесса выполнения задач при разработке программного обеспечения 58
3.1 Команда разработки как система массового обслуживания 58
3.2 Основные элементы и характеристики системы 59
3.3 Расчет вероятностей выполнения задач 62
3.3.1 Состояния системы 62
3.3.2 Уравнения состояний системы 64
3.3.3 Функции вероятностей состояний системы 69
3.4 Расчет вероятностей выполнения плана задач на итерацию 72
3.5 Выводы 74
Глава 4. Прогнозирование процесса выполнения проекта разработки программного обеспечения 76
4.1 Архитектура инструмента поддержки принятия решения при планировании проекта 76
4.1.1 Основные модули 76
4.1.2 Модуль постановки задач 78
4.1.3 Модуль анализа задач 79
4.1.4 Модуль прогнозирования итераций проекта 81
4.2 Интерфейс разработанного инструмента 88
4.3 Прогнозирование процесса выполнения задач в проекте разработки системы автоматизированного анализа текстов 90
4.1.3 Описание проекта 90
4.1.3 Формирование общего списка задач по проекту 92
4.3.3 Формирование плана проекта 95
4.3.4 Контроль хода выполнения проекта 96
4.3.5 Анализ результатов прогноза и выбор параметров проекта 98
4.4 Сравнение предлагаемой методики с методами PERT и Монте-Карло 101
4.5 Перспективы использования предложенных алгоритмов и инструментальных средств прогнозирования 106
4.6 Выводы 107
Заключение 109
Список литературы 111
Приложение 1 IDEF0 модель ведения проекта с применением предварительного расчета параметров проекта на предлагаемой модели 118
Приложение 2 IDEF0 и IDEF3 диаграммы первой и второй фазы выполнения проекта 120
Приложение 3 Акты о внедрении результатов диссертационного исследования 122
- Обзор методик ведения проектов на основе ограничений
- Автоматизация процесса разработки программного обеспечения
- Модуль прогнозирования итераций проекта
- Сравнение предлагаемой методики с методами PERT и Монте-Карло
Введение к работе
Актуальность темы диссертации. При разработке программного обеспечения (ПО) большое значение имеет планирование проекта. Часто именно по причине ошибок в планировании программный продукт не выпускается в срок или не укладывается в выделенный бюджет. С одной стороны, это связано со сложностью задачи планирования и учета особенностей продукта, заказчика, команды разработки, финансовых средств и т.д., с другой - с большой ролью человеческого фактора в вопросах планирования.
Интенсивное развитие информационных и коммуникационных
технологий привело к формированию новых требований к планированию и управлению проектами в различных областях. Процесс выполнения проекта разработки ПО динамичен, требования и набор задач могут часто меняться, ошибка в планировании может привести к значительной задержке времени окончания проекта и/или существенному перерасходу ресурсов. Одним из обязательных условий эффективной реализации проектов становится применение современных средств и инструментов управления проектами, основанных на использовании новых информационных технологий. Развитие специального ПО для планирования и управления проектами обусловлено, в первую очередь, необходимостью максимальной интеграции наиболее эффективных методов, средств и инструментов теории управления проектами для оперативного доступа к аналитическим данным по состоянию проекта.
Отечественными учеными (Бурков В.Н., Разу М.Л., Нижегородцев Р.М., Антонов А.В. и др.) достаточно хорошо проработан вопрос управления различными проектами, однако в области разработки ПО, как показывает практика и исследования Липаева В.В., Брукса Ф., Бема Б., Мадачи Р. и др., вопросы планирования требуют дальнейшего изучения.
Существующие методики планирования проекта предлагают различные подходы к построению процесса разработки ПО («каскадный», итерационный, гибкий), разработаны программные средства для ведения проектов в рамках той или иной методики (MS Project, Primavera Project Planner, Spider Project и т.д.). Их главным недостатком является то, что ошибки в планировании могут быть учтены уже только после завершения проекта. Существующие методы предварительной оценки составленного плана проекта (PERT, COCOMO) требуют задания для еще несформированного проекта большого количества характеристик и чаще всего дают недостаточно точные результаты.
С учетом этого актуальной является задача анализа информационной структуры и создания специального математического и алгоритмического обеспечения системы анализа и принятия решений при планировании процесса разработки, позволяющей до начала реализации проекта и в процессе его выполнения получать оценку вероятности успешного выполнения проекта за определенный срок.
Цель диссертационной работы. Целью диссертационной работы является повышение точности оценки необходимого для выполнения проектов разработки ПО времени путем анализа информационной структуры и разработки
специального математического и алгоритмического обеспечения системы анализа и поддержки принятия решений при управлении проектами разработки ПО.
Для достижения цели в работе решены следующие задачи:
анализ известных моделей процесса разработки ПО, подходов к планированию и существующих программных продуктов для проектов разработки ПО;
исследование информационных процессов при выполнении проекта разработки ПО с целью проведения моделирования и их автоматизации;
разработка функционально-информационной модели процесса выполнения проекта разработки ПО с использованием вероятностной модели планирования;
создание математической модели процесса выполнения задач при разработке ПО;
синтез структуры и разработка системы поддержки принятия решения при планировании на основе математической модели;
экспериментальная проверка созданных моделей и системы поддержки принятия решения при планировании проекта разработки ПО.
Объект исследования. Объектом исследования в диссертационной работе являются процесс разработки ПО.
Предмет исследования. Предметом исследования являются модели, средства и методы планирования проектов разработки ПО и методики принятия решений при управлении проектами разработки ПО.
Методы исследования: методы математического анализа, математического моделирования, численные методы; методы теории вероятностей и математической статистики, массового обслуживания.
Научная новизна. Научную новизна диссертационной работы составляют результаты, полученные в ходе решения поставленных задач:
функционально-информационная модель процесса выполнения проекта разработки ПО с использованием вероятностной модели планирования, отличающаяся возможностью перестройки плана проекта в зависимости от его текущего состояния или изменения набора задач и ресурсов;
алгоритмическое обеспечение системы поддержки принятия решения при планировании проектов разработки ПО, позволяющей получить необходимую информацию о состоянии проекта на каждом из этапов разработки;
математическая модель процесса выполнения задач при разработке ПО, в основе которой лежит рассмотрение команды разработки как системы массового обслуживания;
принципы прогнозирования хода выполнения проекта и определения требуемых параметров проекта разработки ПО, заключающиеся в использовании математической модели для предварительного расчета характеристик проекта и их пересчета в реальном времени с помощью созданного программного обеспечения.
Практическая ценность работы. Практическую ценность работы составляют следующие результаты:
система поддержки принятия решения при планировании проекта разработки ПО с возможностью прогнозирования процесса его выполнения;
подход к планированию проекта с предварительной проверкой возможности его успешного выполнения с помощью математической модели.
Положения, выносимые на защиту. На защиту выносятся следующие положения:
алгоритмическое обеспечение системы анализа и принятия решения при планировании проектов разработки программного обеспечения;
математическая модель процесса выполнения задач при разработке программного обеспечения;
принципы прогнозирования хода выполнения проекта и определения требуемых параметров: сроков, ресурсов и объема работ.
Апробация результатов работы. Основные результаты, полученные в ходе выполнения диссертационной работы, докладывались на международных молодёжных научных конференциях ХХХV-ХХХIХ Гагаринские чтения (Москва, 2009-2013гг.), XLI Гагаринские чтения (Москва, 2015 г.), CEE-SECR (Москва, 2009 г.), XII Международной конференции «Региональная информатика - 2010» (Санкт-Петербург, 2010 г.), X-XVI Международной научно-методической конференции «Информатика: проблемы, методология, технологии» (Воронеж, 2010-2016 гг.), «Современный менеджмент: проблемы, гипотезы, исследования» (Москва, 2016 г.), а также докладывались и обсуждались на научных семинарах кафедры 319 МАИ (Национальный исследовательский университет), научных семинарах НИУ ВШЭ, «Экспертные оценки и анализ данных» ИПУ РАН.
Публикации. Основное содержание диссертации изложено в 17 печатных работах, из них 4 статьи в журналах, рекомендованных ВАК.
Исследование соответствует паспорту специальности 05.13.01 по областям: п.5 «Разработка специального математического и алгоритмического обеспечения систем анализа, оптимизации, управления, принятия решений и обработки информации»; п. 10 «Методы и алгоритмы интеллектуальной поддержки при принятии управленческих решений в технических системах»; п. 11. «Методы и алгоритмы прогнозирования и оценки эффективности, качества и надежности сложных систем»; п.13 «Методы получения, анализа и обработки экспертной информации».
Структура и объем работы. Работа состоит из введения, четырёх глав, заключения, списка литературы и трех приложений. Работа изложена на 117 страницах и включает 31 рисунков, 6 таблиц, список литературы из 91 наименования, а также 3 приложения на 7 страницах. Общий объём работы - 124 страницы.
Обзор методик ведения проектов на основе ограничений
Большинство проектов имеют определенные дату окончания, бюджет и объем работ. Время, ресурсы и объем работ в литературе [8, 41-42, 56-57] обычно называют проектным треугольником (рисунок 1.1), т.к. изменения в одном из этих элементов вызывают изменения других. В общем случае, для проекта важны все три составные части, но, как правило, только один из них в зависимости от приоритетов имеет наибольшее влияние на другие. В этом случае говорят о проектах с фиксированным временем выполнения (time–driven, самым существенным параметром является время), с фиксированным объемом работ (feature driven, для реализации основных функций системы могут быть увеличены ресурсы или сроки) и с фиксированной стоимостью (resource driven, приоритетным является ограничение одного из ресурсов) [60, 64].
Увеличить объем работ, то проект будет длиться дольше и стоить дороже. То, как изменения в плане влияют на другие стороны треугольника, зависит от обстоятельств и специфики проекта [75].
Качество, четвертый элемент проектного треугольника, находится в его центре, и изменения, вносимые в любую из сторон треугольника, практически всегда влияют на качество (рисунок 1.2). Качество не является стороной треугольника – это результат действий со временем, стоимостью и объемом работ [43]. В работах некоторых авторов треугольник за счет добавления качества превращается в пирамиду [68, 76].
В стандарте ГОСТ ИСО/МЭК 12207–1999 [17] упоминается каскадная, спиральная и эволюционная модели. В новой версии стандарта количество моделей возрастает до четырех (добавляется итерационная модель). В последующих же версиях декларируется множество вариантов организации процесса разработки ПО [18], но основными являются: каскадная, инкрементная и эволюционная.
В работах [3, 5, 9-10, 54, 58–59, 89] рассматривается множество современных вариантов организации разработки программного обеспечения, вырабатываются критерии оценки и выбора альтернатив, а также и их различные классификации. Однако для большинства современных вариантов построения процесса разработки программного обеспечения точная классификация затруднительна. Практически каждый проект, часто стараясь следовать тем или иным принципам, адаптирует их к своим реалиям, тем самым создавая новый подход. При этом практически всегда команда разработки в чем–либо ограничена. Поэтому в работе эти подходы классифицируются по способу построения процесса разработки программного обеспечения на основе приоритетного типа ограничений.
Выбор среди вариантов построения процесса разработки ПО представляет собой достаточно сложную задачу. Зачастую такой выбор происходит без учета всех возможных альтернатив, рассматривая только ограниченный набор методик, при этом не учитывается специфика проекта.
Подходы к разработке ПО, основанные на ограничениях размеров проекта, исторически возникли первыми. Это объясняется в первую очередь тем, что ограничения размеров проекта (как, впрочем, и ресурсов) логически вытекают из самой сути проекта. Как только удается определить и декомпозировать цель проекта сразу возникают рамки проекта (scope), в которых определен проект и ограничения. Проект, не имеющий границ, заранее неуспешен. Все подходы данной группы основаны на четком разделении проекта на фазы, отличаясь только длительностью и степенью проработки фаз.
Существует набор стандартов, определяющих различные элементы в структуре жизненных циклов программного обеспечения и программно– аппаратных систем. В качестве основных таких элементов выделяют технологические процессы – структурированные наборы деятельностей, решающих некоторую общую задачу или связанную совокупность задач, такие как процесс сопровождения ПО, процесс обеспечения качества, процесс разработки документации и пр. Процессы могут определять разные этапы жизненного цикла проекта и увязывать их с различными видами деятельностей, артефактами и ролями заинтересованных лиц [14]. Самыми распространенными вариантами построения процесса разработки ПО являются: каскадный (водопадный) подход, V–образный, спиральный и итерационный подходы.
Детальное рассмотрение этих подходов выходит за рамки данной работы. Стоит отметить, что, не смотря на многочисленную критику и большой возраст каскадного подхода, зачастую, на практике, даже если заявлен другой подход, применяется именно каскадный, по всей видимости, ввиду простоты его применения.
Нахождение верного баланса между ресурсами, временем разработки и возможностями - самый важный момент в построении решения, отвечающего потребностям заказчика [8].
Например, сравнение важности ограничений каждого типа для подходов к разработке, дает диаграмму, представленную на рисунке 1.3.
В чистом виде данных методик разработки в ходе исследования выявлено не было. Однако ограничения различного вида ресурсов, безусловно, присутствуют в каждом проекте. Обычно они следуют из ограничений остального типа, когда на стадии планирования выясняется, какая из составляющих будет играть наибольше значение для проекта в целом. Обычно, ограничения ресурсов дополняют ограничения рамок проекта.
Автоматизация процесса разработки программного обеспечения
Проведенный анализ показал, что процесс разработки ПО длительный, трудоемкий, характеризующийся большим числом преобразований данных на разных этапах проекта, особенно в вопросах, связанных с работой со списками задач по проекту в целом или по итерациям, т.к. именно эти данные отражают все вносимые в план проекта изменения, как со стороны заинтересованных лиц, так и стороны команды разработки. Для его упрощения применяется ряд программных средств автоматизации на различных фазах создания проекта.
На начальных этапах первой фазы, когда формируются требования и еще нет формализованного списка задач, автоматизацию процесса разработки составляют системы ведения проекта и системы хранения требований [91], позволяющие вносить, хранить, модифицировать, структурировать информацию о требованиях, часть из них поддерживает работу с формализованным представлением требований в форме UML-диаграмм прецедентов. Часто к этому добавляется возможность хранения многосвязных списков требований и задач. Полная автоматизация процесса формирования и формализации требований и создания задач на их основе сильно затруднена слишком большим влиянием всех участников проекта и прочих заинтересованных лиц, от которых поступают требования или ограничения, поэтому для процессов первой фазы используются только инструменты, упрощающие рутинную работу с данными по проекту.
С повышением уровня формализации передаваемой информации с одного этапа на другой во второй и третьей фазах с одной стороны появляется больше повторяющейся рутинной деятельности, которая может и должна быть автоматизирована, с другой стороны еще больше, чем в первой фазе, проявляется динамичность процесса разработки ПО и изменчивость требований. Поэтому повышается потребность в использовании средств автоматизации и создании новых средств поддержки принятия решений [90] для оперативного контроля за ходом выполнения проекта.
В результате проведенного анализа информационной структуры процесса разработки ПО были выявлены части процесса, которые нуждаются в автоматизации:
переопределение приоритетов задач и построение общего списка задач
Составление общего списка задач на основе предварительного графа происходит в два этапа: переопределение приоритетов задач и непосредственно обход графа для составления списка. Для решения обоих задач необходимо провести рекурсивный обход графа, при количестве вершин превышающем десятки вручную эта процедура достаточно трудоемка, к тому же алгоритмы рекурсивного обхода достаточно хорошо изучены, поэтому автоматизация этого процесса должна проводится в первую очередь.
автоматизация построения плана итераций и его проверки с помощью одной или нескольких моделей оценки
Как до начала выполнения задач, так и во время, план итераций может претерпевать множество изменений, это связано с изменчивостью требований к ПО и вероятностным характером процесса их выполнения в последствии, поэтому необходимо использовать существующие средства моделирования для проверки построенного плана проекта с точки зрения оценки успешности выполнения проекта и создавать новые для увеличения точности и упрощения получения оценок, что может достигаться путем автоматизации построения и использования этих моделей.
автоматизированный контроль хода выполнения задач и внесения корректировок в план проекта
В ходе выполнения задач большое значения имеет своевременность реагирования на изменения, для чего необходимо быстро получать актуальные данные по текущему состоянию задач, анализировать их с целью определения последствий и вносить корректировки в план проекта. Для решения этой проблемы необходимо создания новых средств контроля хода выполнения проекта и систем поддержки принятия решений по внесению изменений в план проекта.
Исходя из этого, в диссертационной работе предлагается методика ведения проекта (рисунок 2.8):
1. Проверка плана проекта и его возможная корректировка перед переходом к выполнению задач и после очередной итерации.
2. Максимальный учет результатов предыдущих проектов и завершенных итераций при текущем планировании.
3. Возможность простого внесения изменений в план проекта в процессе выполнения задач после очередной итерации без изменения всего плана проекта целиком.
Проведенный анализ информационной структуры процесса разработки ПО показал, что в нем задействовано большое количество участников проекта и заинтересованных лиц, влияющих на ход его выполнения на всех этапах, при этом кроме непосредственно выполнения задач по реализации функционала ПО существует потребность в преобразовании большого количества данных, которые отражают динамичность процесса. Поэтому для применения предложенной методики необходимо создание инструментальных средств поддержки принятия решений при планировании проекта, которые позволят автоматизировать работу с данными о задачах проекта на этапах планирования и выполнения задач в дополнение к существующим средствам автоматизации управления требованиями и задачами и на основе математической модели процесса разработки просчитать основные характеристики будущего проекта, найти их приемлемое сочетание на основе имеющихся входных данных и только после этого переходить к непосредственно разработке.
Модуль прогнозирования итераций проекта
Модуль составления плана итераций В результате на вход модуля прогнозирования результатов выполнения задач поступает большая, в сравнении с размером одного этапа выполнения проекта, очередь единичных задач. Далее в зависимости от типа проекта может быть определено:
примерное количество итераций, необходимых для выполнения N задач, при фиксированных рамках проекта. Это количество оценивается как отношение N задач к среднему количеству, которое коллектив может выполнить за одну итерацию.
примерное количество задач, которое необходимо выполнить за одну итерацию при фиксированном времени. Количество задач можно оценить как отношение количества задач к количеству допустимых итераций проекта.
При этом размер итерации в соответствии с выбранной идеологией ведения проекта обычно фиксируется для стандартизации процессов внутри итерации. Однако в общем случае встречаются итерации переменной длины, поэтому система позволяет учитывать и их, поскольку за основу взята задача единичного объема.
Модуль прогнозирования хода выполнения проекта В основу работы модуля прогнозирования хода выполнения проекта положена модель процесса выполнения задач по разработке ПО, в которой команда разработки рассматривается как система массового обслуживания.
Исходными данными для составления прогноза является очередь единичных задач, план итераций для единичных задач и характеристики команды разработки: интенсивность выполнения задач и количество специалистов. План итераций включает в себя время и размер каждой из итераций для поддержки работы с неравными итерациями.
В модуле прогнозирования результатов выполнения задач, составляющих проект, описанная динамическая модель СМО используется для получения вероятностей выполнения списка запланированных на итерацию задач, отображения прогноза хода проекта, а также определения требуемых для итерации проекта ресурсов.
На вход модуля прогнозирования результатов выполнения задач подаются следующие параметры:
N - количество специалистов в команде;
к- количество задач на итерацию;
d - количество дней в итерации;
X - средняя производительность команды разработки, задач в день. Система может использовать для прогнозирования параметры N, к, d по умолчанию, исходные значения которых: 7V=5, &=20, d=10. Пользователь может установить свои значения параметров, как для конкретного прогноза, так и в качестве значений по умолчанию.
Блок-схема работы модуля представлена на рисунке 4.4. В начале работы модуля проверяются входные параметры. Если N не имеет значения по умолчанию и не совпадает с характеристиками последней моделируемой системы, то в зависимости от входных параметров определяются состояния системы и формируется система соответствующих дифференциальных уравнений. После решения системы уравнений определяются функции зависимости вероятности нахождения системы в z–ом состоянии от времени t. Если N имеет значение по умолчанию, то граф и уравнения состояний и функции вероятностей были ранее определены и хранятся в памяти системы.
С помощью полученных зависимостей определяется вероятность выполнения всех запланированных задач за итерацию и вероятности выполнения каждой задачи по всем дням в итерации. Если вероятность меньше заданного в системе порогового значения, то определяется оптимальное количество задач для заданных входных параметров и время окончания проекта.
На основе этих данных формируется общий прогноз на итерацию, общий вид которого представлен в табл. 4.1.
После этого сохраняется модель системы для текущих параметров и выводятся результаты прогноза. Используя построенную модель, составляется прогноз хода выполнения проекта в течение времени итерации и определяется вероятность успешного выполнения всех поставленных задач за этот срок.
Удовлетворительность прогноза определяется сравнением с пороговым значением вероятности успешного выполнения проекта, которое в системе задано по умолчанию и равно 0.9 (90%).
Модуль прогнозирования хода выполнения проекта может работать в двух режимах: прогнозирования и анализа. В случае работы в режиме прогнозирования система строит прогноз (рисунок 4.5), который включает в себя набор единичных задач на итерацию и количество дней в соответствии с планом итераций, для решения каждого количества задач в каждый день итерации рассчитывается вероятность их выполнения, определяется вероятность выполнения всех поставленных задач за срок итерации и оценивается приемлемый ли результат прогноза с учетом порогового значения.
В случае работы в режиме анализа помимо составления прогноза после оценки удовлетворительности результата прогноза система предлагает пользователю решения по оптимизации плана итераций.
Если вероятность успешного выполнения задач больше порогового значения, то система составляет расширенный прогноз для положительного случая (рисунок 4.6) и определяет количество дополнительных единичных задач, которое можно добавить в анализируемую итерацию, при условии, что вероятность их успешного выполнения останется в допуске.
Если вероятность успешного выполнения задач меньше порогового значения, то система строит расширенный прогноз для отрицательного случая (рисунок 4.7) и предлагает изменить возможные параметры:
увеличить размер итерации (количество дней, необходимых на выполнение определенного числа задач);
уменьшить количество выполняемых задач, оставив размер итерации неизменным. Такая методика предписывается большинством методологий, относящихся к семейству «гибких»;
изменить состав команды разработки, добавляя в нее новых специалистов. При этом в системе будет произведет новый расчет средней производительности команды и на ее основе перестроится модель процесса выполнения задач и будет рассчитана скорректированная вероятность выполнения N отобранных задач за время d
Сравнение предлагаемой методики с методами PERT и Монте-Карло
Исторически первым подходом к планированию проектов являлось использование метода PERT, который, даже несмотря на свои недостатки, благодаря относительной простоте первичных вычислений и по сегодняшний день используется для выполнения предварительных оценок. При моделировании по методу PERT реального проекта разработки ПО помимо составления графа задач проекта для корректности выполнения расчетов требуется искусственно ввести дополнительные зависимости между задачами, чтобы максимальное число одновременно выполняемых задач не превышало количество разработчиков на проекте, а при изменении этого количества граф задач потребуется перестроить полностью. В общем случае строится большое число независимых ветвей графа, а затем определяются потребности в тех или иных ресурсах.
Метод PERT основывается на предположении о бета-распределении случайной величины – времени выполнения отдельной задачи. Для реализации метода Монте-Карло необходимо сгенерировать случайным образом числа, подчиняющиеся такому распределению, в промежутке от tmin до tmax для каждой задачи, затем после 1000 или более таких «опытов», было подсчитана вероятность выполнения проекта за определенный срок.
Было проведено сравнение оценок реализации предложенной методики с использованием методов PERT и Монте-Карло для итераций нескольких проектов, оценена трудоемкость получения таких оценок и их порядок. Поскольку оценки являются приближенными, представляя собой вероятность успешности выполнения задач, то возможно только их сравнение с реальными данными, полученными по завершении данных проектов.
Сравнение методов проведено на примере планирования и реализации задач итераций разработки в проекте создания системы автоматизированного анализа текста. Из всего списка задач проекта (около 250) для составления прогноза были выбраны задачи для выполнения в ходе одной итерации. В случае разработанной методики дополнительная гибкость проявляется в том, что количество задач итерации предварительно задавать не требуется, поскольку оно определяется заданной вероятностью выполнения итерации в срок. Для метода PERT был дополнительно определен критический путь (таблица 4.2), а для метода Монте-Карло подготовлено приложение для генерации бета-распределения.
Затем в соответствии с методом PERT было получено время TE -выполнения задач критического пути, и стандартное отклонение для задач проекта. Продолжительность задач критического пути: 12,5 дней. Стандартное отклонение для итерации проекта: 2,17 дней.
Для 1-3 итераций количество задач было задано вручную, для 4 и далее количество задач итерации было определено автоматически, исходя из условия 90% вероятности успеха, что соответствует двум режимам работы системы планирования. Для 1–3 итерации количество задач было задано вручную, для 4 и далее количество задач итерации было определено автоматически, исходя из условия 90% вероятности успеха, что соответствует двум режимам работы системы планирования.
Сравнения относительной ошибки каждого метода было проведено, исходя из предположения, что по плану вероятность успеха итерации должна быть более 90%. С помощью каждого из методов был получен прогноз количества дней, необходимых для выполнения итерации, при условии заданной вероятности успеха и фиксированном количестве задач, поскольку методы PERT и Монте-Карло не позволяют менять количество задач без перестройки модели целиком. Затем средняя относительная ошибка прогноза вычисляется по следующей формуле [15]
Сравнение полученной относительной ошибки дает следующие значения для перечисленных методов (PERT, Монте-Карло, Предложенный метод): относительная ошибка для предложенного метода(0,0683) меньше на 17%, чем относительная ошибка метода PERT(0,0825) и на 14% меньше, чем относительная ошибка метода Монте-Карло(0,0794).
Разработанная система поддержки принятия решений была применена для прогнозирования сроков выполнения задач при планировании ряда проектов разработки прикладного ПО для массового использования.
Предлагаемый метод всём на множестве проанализированных проектов дает в среднем на 7% меньшее отклонение от фактического времени по сравнению с PERT и на 5% меньшее - относительно метода Монте-Карло. Кроме того, предложенный метод позволяет произвести расчеты быстрее, без серьезной зависимости от вида критического пути и количества разработчиков проекта.