Содержание к диссертации
Введение
ГЛАВА 1. Обзор литературных источников 10
1.1. Описание IT-проекта 10
1.2. Управление рисками 13
1.3. Распределение ресурсов между задачами проекта 17
1.4. Управление коммуникациями 19
1.5. Методологии управления проектами 20
1.6. Методика критической цепи 23
1.7. Информационные системы по управлению проектами 26
1.8. Агентные технологии 28
1.9. Выводы по первой главе 34
ГЛАВА 2. Методика управления проектами 36
2.1. Этап1. Назначение ресурсов проекта 37
2.2. Этап 2. Учет рисков. 42
2.3. Этап 3 Формирование системы уведомлений . 47
2.4. Этап 4. Мониторинг состояния проекта 51
2.5. Этап 5. Формирование управленческого решения. 54
2.6. Этап 6. Принятие решений о замене ресурса. 57
2.7. Ранжирование альтернатив 59
2.8. Выводы по второй главе 63
ГЛАВА 3. Разработка алгоритмов для решения задач многокритериальной оптимизации распределения ресурсов 64
3.1. Конкурентный коэволюционный генетический алгоритм 68
3.2. Кооперационный коэволюционный генетический алгоритм 77
3.3. Сравнение алгоритмов 82
3.4. Выводы по третьей главе 93
ГЛАВА 4. Структурно-функциональная модель разработанной системы 94
4.1. Функциональная модель системы 94
4.2. Входные и выходные данные 96
4.3. Общая архитектура системы 101
4.4. Взаимодействие агентов 109
4.5. Реализация агентов 112
4.6. Апробация работы 115
4.7. Выводы 124
Заключение 125
Список литературы 127
- Распределение ресурсов между задачами проекта
- Информационные системы по управлению проектами
- Этап 3 Формирование системы уведомлений
- Кооперационный коэволюционный генетический алгоритм
Распределение ресурсов между задачами проекта
А поскольку кривая распределения имеет длинный «хвост» справа, то можно заключить, что за оценку задачи принимают оценку, большую, чем наиболее вероятностная оценка, т.е. закладывают в саму задачу еще больше «подстраховки». Кроме того, риски срабатывают не всегда и тем самым происходит существенная переоценка длительности проекта.
Данный подход к закладыванию рисков при помощи метода PERT относится к вероятностному подходу. Для использования данного подхода к оценке необходимо иметь статистику выполнения схожих задач, что в условиях постоянно растущей сложности информационных систем не всегда представляется возможным в виду отсутствия истории выполнения похожих задач. Существует еще один подход - использование аппарата нечетких множеств [82, 84]. В работе [83] показано, что в ситуациях, когда у менеджера нет статистики выполнения задач, удобно представлять длительность в виде нечеткого числа (трапециевидного или треугольного). При помощи нечетких чисел удобно представлять такие оценки как: «не более 5 дней», «не менее 4 дней», «от 2 до 7 дней». Кроме того при использовании нечеткого подхода снижаются затраты на вычисление длительности задачи. В случае использования нечетких множеств необходимо выбрать механизм дефуззификации, например индекс соответствия [77] или таких механизмов как нахождение центра тяжести или максимума функций [49].
С целью устранения риска «Некачественное календарное планирование» или его ослабления использовать механизм оценки длительности задач-проекта, который позволял бы учитывать риски и исключал бы переоценку проекта.
Срабатывание риска «Низкая производительность» относится к процессу выполнения задач разработчиком. В настоящее время не только сильно различается производительность отдельных разработчиков [81], но производительность отдельного разработчика при выполнении задач.
Данный риск покрывается временным запасом, закладываемым в проект. В случае срабатывания данного риска единственным возможным решением, чтобы не ставить под удар весь проект, является замена ресурса. Распределение ресурсов между задачами проекта
Одной из задач управления IT-проектами является задача выполнения распределения ресурсов задачам проекта [5, 56, 57], выполняемая на этапе планирования проекта. Решения, принимаемые на данной стадии, могут оказать существенное влияние на весь проект в целом. Так принятие некорректных решений при назначении ресурсам задач может привести к нарушению сроков проекта и/или превышению бюджета. В общем случае такую задачу относят к NP-трудным задачам, не имеющим эффективных точных методов решения. Для решения подобных задач в случае однокритериальной оптимизации (минимизации времени проекта) используют линейное программирование [30, 5], а также теорию графов [58] с элементами эвристики [2, 3, 6], метод ветвей и границ [24].
Сокращение себестоимости [16] и длительности проекта является критическим для большинства компаний. Нередко компании нанимают команду разработчиков только на время разработки проекта. Каждый разработчик требует определённую заработанную плату и, как правило, чем лучше разработчик, тем дороже он будет стоить. Задачи данного типа являются примером задач многокритериальной оптимизации [70]. Задачу многокритериальной оптимизации представляют в виде тройки х, z, g следующим образом: где х - вектор оптимизируемых переменных, Х– пространство поиска, z - множество целевых функций (критериев оптимальности), g- множество ограничений переменных.
Как правило, в многокритериальных задачах целевые функции конфликтуют между собой, т.е. улучшение одного из показателей возможно лишь при ухудшении другого.
Наибольшей популярностью пользуются алгоритмы, использующие принципы Парето-доминирования: решение х доминирует над решением у ( ХУ у), если выполняется условие: \/i,Zi(x) zt(y)л3i,zt(x) Zj(x). (1.5) Данное условие справедливо в случае минимизации целевых функций. Решение х называется Парето-оптимальным, если не существует ни одного решения, которое доминирует х. Наборы решений образуют фронт Парето.
Целью многокритериальной оптимизации является нахождения множества Парето-оптимальных решений. Тем не менее, нахождения всех решений, как правило, невозможно из-за большого размера множества. Кроме того, нахождение всех решений требует значительных вычислительных ресурсов. Поэтому на практике находят приближенное множество Парето-оптимальных решений.
Наиболее популярным алгоритмом решения многокритериальной оптимизации является модифицированный генетический алгоритм, предложенный Голдбергом [82]. Данный алгоритм и его различные модификации использовались для решения задач календарного планирования [76, 87].
Информационные системы по управлению проектами
Если датчики способны предоставлять агенту всю необходимую информацию о состоянии среды в любой момент времени, то такая среда называется полностью наблюдаемая, в противном случае - частичной. В случае частичной среды агенту приходится поддерживать некоторое состояние или же запрашивать информацию от других агентов. Если состояние среды, в которой действует агент, полностью определяется текущим состоянием и действием, то такая среда называется детерминированной, в противном случае стохастической. Если опыт агента рассматривается в среде как набор неразрывных эпизодических элементов, где действия агента не зависят от действий, выполненных в предыдущих эпизодах. Среда называется статической, если во время принятия решения агентом, она не изменяется, в противном случае - динамической. В зависимости от количества агентов среды принято делить на одноагентные и многоагентные. Среда считается дискретной, если ее можно представить в виде конечного числа состояний, иначе - непрерывной. Также агентов можно представлять в виде множества рецепторов, процессоров и эффекторов [21].
Агенты получили широкое применение во многих областях [80]. Имеются многочисленные работы, в которых рассматривается применение агентных технологий [4, 43, 23, 47, 27] в том числе и в управлении проектами [91, 88, 53]. 1.9. Постановка задачи
В настоящее время существуют два противоречащих друг другу фактора: с одной стороны – рост потребностей в разработке ИС, а также высокие требования к их качеству и срокам разработки, с другой – различные проблемы и изъяны в управлении IT-проектами: выполнение и поддержка принятия решений по управлению ресурсами и календарным планированием с учетом рисков в условиях ограниченных бюджета проекта и его длительности. Таким образом, актуальной является задача разработки методики управления ресурсами IT-проекта, учитывающей риски некачественного календарного планирования и низкой производительности, а также технической реализации методики – системы по управлению IT-проектом, обеспечивающую поддержку принятия решений (СППР) для менеджера проекта на этапе инициации проекта (составление оптимального распределения между ресурсами и задачами проекта) и его исполнения (проведение замен ресурсов на задачах) (рис. 1.4).
State – состояние проекта (выполняется ли проект с опережением графика или сроки нарушаются), включающее в себя состояния задач (выполнены, не начаты, в процессе и пр.).
Методика включает в себя набор методов по выполнению распределению ресурсов между задачами проекта, составлению расписания с учетом рисков, мониторингу состояния проекта, распространению информации по проекту между его участниками, обнаружению срабатывания рисков и осуществлению реагировании на риски путем выполнения замен ресурсов на задачах.
Управляющее воздействие оказывается на расписание проекта (происходит корректировка расписания), путем выполнения замен ресурсов R на назначенных задачах.
Для построения СППР необходимо выполнить комплекс задач, заключающихся в следующем: 1. Решить задачу оптимизации составления распределения ресурсов между задачами проекта при минимальных длительности и себестоимости проекта, а также при ограниченных времени и бюджета проекта.
Составить расписание проекта, ослабевающего воздействия рисков «Некачественное календарное планирование» и «Низкая производительность» с учетом неопределенности исполнителей в оценках времени исполнения работ.
Разработать механизм распространения информации между исполнителями и менеджером проекта с учетом неопределенности в оценках объема оставшихся работ исполнителями, а также состояния проекта.
Разработать механизм обнаружения риска «Низкая производительность», а также определения действий, направленных на его устранение.
Выполнение приведенных пунктов диссертационного исследования позволит сформировать своевременные управленческие решения, с одной стороны – повышающие оперативность принятия решений, с другой – существенно снижающие субъективизм человеческого фактора, выраженного при назначении ресурсов на задачи проекта, принятии решений о корректировке расписания проекта, выполнения замен ресурсов менеджером проекта, что является отличительной чертой специальности 05.13.10 – Управление в социальных и экономических системах.
Этап 3 Формирование системы уведомлений
В кооперационном коэволюционном алгоритме случае происходит разбиение общей задачи оптимизации на несколько составляющих, тем самым происходит сокращение пространства поиска. Каждая из составляющих отвечает за оптимизацию отдельного критерия, и таким образом, вычисление можно выполнять в параллельных потоках, лучше используя вычислительные возможности машины.
После создания популяций особей для отдельных задач оптимизации и оценки их внутренней приспособленности происходит процесс кооперации различных популяций. На основании этого происходит оценка общей приспособленности особи и дальнейшая селекция.
Как правило, кооперационный коэволюционный алгоритм использует разбиение задачи на подзадачи таким образом, что каждая из подзадач содержит лишь часть решения и при сочетании найденных решений подзадач, получается все решение [65]. Однако, для задачи многокритериальной оптимизации, такой как составление расписания, используется подход, когда каждая из подзадач уже содержит все решение. А разбиение задачи на подзадачи имеет своей целью более быструю сходимость.
Каждая из подзадач использует генетический алгоритм поиска оптимального решения. Операции кроссовера и мутации ничем не отличаются от соответствующих операторов в других алгоритмах. В качестве условия останова алгоритма выступает количество итераций. Отличительными операторами являются селекция и эллитизм.
Для селекции необходимо выполнить ранжирование особей и, следовательно, рассчитать функцию приспособленности. В кооперационных алгоритмах для расчета функции приспособленности (общей) используется понятие внутренней и внешней функции приспособленностей. Значение внутренней функции приспособленности определяется значением оптимизируемого критерия. Внешняя функция показывает как «хорошо» кооперируется текущая особь с особями других популяций. Для определения внешней приспособленности используются три параметра: объем выборки (sample size); плотность выборки (selective pressure); присваивание коэффициентов доверия (credit assignment). Объем выборки определяет количество популяций, участвующих в сравнении. В качестве объема выборки предлагается использовать текущую популяцию из другого субалгоритма. Плотность выборки определяет: каким образом будут выбираться особи. Здесь возможны несколько вариантов:
Выбрать всех особей из популяции. Выбрать и особей с наилучшим значением функции внутренней приспособленности или выбрать и случайным образом. Присваивание коэффициентов доверия определяет то, каким образом будет рассчитываться внешняя приспособленность. В случае минимизации целевых критериев значение внешней функции приспособленности для особи р по отношению к внешней популяции Pj с выборкой элементов SPj = {pi} предлагается рассчитывать по формуле: \SP\-cooperate(p,SP) f (р) = \ + К J J\ (3.11) extV У I SPJ где К - коэффициент кооперации (чем больше значение имеет К, тем большее влияние оказывает значение внешней приспособленности на общую приспособленность особи),
В случае же решения многокритериальной оптимизации с целевыми функциями (2.3) и заданными ограничениями (2.6), (2.10), (2.11), (2.15) и с целевыми функциями (2.38) и заданными ограничениями (2.6), (2.10), (2.11), (2.37) алгоритм упрощается. Вся задача разбивается на две подзадачи: первая минимизирует время проекта, вторая - себестоимость. Внутренняя приспособленность определяется значением оптимизируемого критерия. Для первой подзадачи внутренняя приспособленность определяется полученным временем расписания, второй - стоимости. Коэффициент кооперации предлагается принять за 1. В качестве плотности выборки использовать всех особей другой популяции. Элитизм в этой задаче не используется.
Кооперационный коэволюционный генетический алгоритм
Результаты работы были апробированы в ООО «Агент Плюс». «Агент Плюс» - российская IT-компания, являющаяся резидентом фонда развития центра разработки и коммерциализации новых технологий «Сколково». Данная компания ориентирована на разработку ПО, решающего задачи автоматизации бизнес-процессов в компаниях разных сфер деятельности, в штате которых работают мобильные сотрудники: торговые представители, супервайзеры, мерчендайзеры, и другие. «Агент Плюс» разрабатывает и внедряет мобильные приложения и офисные программные продукты. Разработанная система использовалась в компании для решения отдельных задач управления проектами:
1. Подбор исполнителей под внешний проект с целью минимизации длительности проекта и минимизации теряемой «ценности» для компании в связи с участием исполнителей, а также выполнение замен.
2. Составление расписания проекта с учетом рисков. Также методика и разработанная ИС использовалась для управления внутренними проектами.
В результате внедрения созданной методики и системы поддержки принятия решений по управлению проектом для различных задач управления были получены результаты.
Для решения первой задачи в проекте «Фрост Микс» (автоматизация задач мерчендайзинга) использовался модуль выполнения распределения ресурсов между задачами проекта. В данном случае роль зарплаты ресурса играла ценность сотрудника для компании. В результате использования данного модуля были отмечено сокращение времени подбора исполнителей на 75%. При этом качество полученного решения было лучше (длительность проекта была сокращена на 8%, а ценность на 10%), чем, если бы подбор осуществлялся вручную.
Для решения второй задачи был использован модуль составления расписания. Раньше в компании каждую задачу проекта оценивали с закладыванием подстраховки в саму задачу. В результате использовании механизма буферов при составлении расписания проекта его общая длительность была сокращена на 15%, а время составления расписания сократилось на 80%, при этом проект «Мобильные сервисные службы» уложился в заявленные сроки.
Поскольку дорого и почти невозможно обеспечить сравнение результатов исполнения проекта до и после внедрения методики, то для этих целей была разработана имитационная модель.
Управление проектами в компании «Агент Плюс» происходит при помощи методики Scrum. Команды проекта (до 6 человек в одной команде) работают итерациями. Итерация составляет, как правило, 2 недели. На каждой итерации решаются задачи анализа требований, разработки и тестирования. При составлении модели рассматривались лишь задачи разработки, поскольку именно выполнение данных задач определяет итоговый успех итерации.
Каждый исполнитель характеризуется фокус-фактором, который представляет собой дробное число от 0 до 1. Фокус-фактор показывает отношение количества выполняемых часов задачи к общему времени работы, так, если за один рабочий день (8 часов) была выполнена задача, оценённая в 4 часа, то фокус фактор составляет 0,5. Чем выше фокус-фактор, тем лучше исполнитель (больше задач выполняет за день), и кроме того его мнение является более авторитетным в команде в спорных ситуациях.
На каждой итерации (рис. 4.13) на вход команде поступает список задач, согласно производительности команды (среднему фокус фактору). Для задач большинства проектов компании характерно небольшое количество связей (ОН), остальные связи отсутствуют. Каждый исполнитель (ресурс) дает свою оценку по времени исполнения каждой задаче (ожидаемое время выполнения), как правило, с использованием метода PERT. Далее происходит покер-планирование – все ресурсы приходят к единой оценке по каждой задаче, достигая консенсуса. Мнения исполнителей с большим
На следующем этапе происходит назначение ресурсов. Исполнители по своему желанию (случайно) выбирают каждый для себя задачи. При этом соблюдается равномерная, согласно фокус-фактору загруженность команды, а также занятость каждого ресурса на протяжении всей итерации. В составленном расписании отсутствуют жесткие даты исполнения задач. Если исполнитель завершил свои задачи, то он берет задачи другого исполнителя, к которым тот еще не приступил.
Мониторинг состояния проекта происходит при помощи диаграммы сгорания спринта, где учитываются общие трудозатраты работ, без учета связей между ними. В случае нарушения сроков, принимаются решения либо о выполнении сверхурочных работ, либо об отказе от выполнения данного функционала.
Входами имитационной модели процесса управления проектом на каждой итерации являются: Список задач со связями Список ресурсов с заданными фокус-факторами Оценки времени исполнения задач каждым ресурсом Выходом является общее время выполнения всех задач на итерации. Блок «Выравнивание оценок» для каждой задачи описывается в математической функции, представляющей собой нормальное распределение со средним квадратичным отклонением т = 0,5 . Математическое ожидание основывается на оценках ресурсов и их фокус-факторов: 4. Инициализировать для каждого ресурса г, реальную загруженность ресурса rCapacity = 0. 5. Сгруппировать задачи по времени начала выполнения Begin(wi) по возрастанию. Для каждой из групп выполнить шаги 6- 7 6. Сортировать все задачи wt группы по убыванию длительности dt 7. Для каждых гМ задач выполнить случайное назначение каждого ресурса rj задачи wt, xtj = 1 и rCapacity . = rCapacity . + dt где rM = \{r },rCapacity . capacity . - количество ресурсов, которые еще недостаточно загружены. 8. Завершить алгоритм. Блок «Исполнение» представляет собой сетевую диаграмму, время исполнения каждой задачи описывается при помощи бета-распределения с параметрами а = 1 и /3 = 2. В случае, если все задачи ресурса были завершены, то он берет на себя самую раннюю из возможных задач (см. этап 118 «Назначение задач»). Таким образом, замены ресурсов выполняются лишь после завершения задач
Таким образом, время выполнения всех задач итерации определяется следующим Тестирование имитационной модели происходило по итерациям следующих проектов: СКУЛ (сервис контроля и учета лицензий). Программный продукт, обеспечивающий контроль использования лицензий мобильных приложений Агент Плюс, а также обеспечивающий возможность управления лицензиями (прикрепить лицензию к устройству и открепить) клиентом. Веб-решение реализовано при помощи набора технологий от Microsoft. УДС (управление дистрибьюторской сетью). Программные продукт, ориентированный на управление торговой сетью крупных держателей бренда, обеспечивает сбор данных (консолидация) с мобильных устройств торговых представителей и ИС региональных оптовых компаний сети и подготовку аналитической информации. Комплекс решения состоит из набора веб-сервисов, веб-приложения, хранилищ данных, OLAP - кубов. Мобильная торговля 1С. Мобильное приложение, разработанное на мобильной платформе 1С, направленное на автоматизацию мобильных сотрудников в торговле (торговый представитель, мерчендайзер). Агент Плюс Мобильная платформа - платформа, на основе которой возможна разработка мобильных приложений, например Агент Плюс Мобильная торговля Проф. и Агент Плюс Мерчендайзинг. Разработана с использованием языков С++ и Java.
