CC BY
118
УДК 681.3
ОПТИМИЗАЦИЯ УПРАВЛЕНИЯ ПРОЕКТОМ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ НА ОСНОВЕ МУЛЬТИАГЕНТНОЙ СИСТЕМЫ Е.В. Хрыкин, В.Н. Кострова
В работе рассматривается жизненный цикл проекта разработки программного обеспечения, приводится обзор методологий управления проектом и планирование на основе методологии РМІ. Обосновывается принципиальная возможность и преимущества оптимизации управления проектом на основе мультиагентной системы
Ключевые слова: управление проектом, РМІ, агенты
Проект - это процесс создания продукта, описанного в контракте с заказчиком. При этом под управлением проектом в общем смысле подразумевают набор действий, направленных на обеспечение создания продукта, при котором проект не выйдет за грани тройственного ограничения, то есть стоимости, срока и содержания предусмотренных работ. Кроме того, правильным подходом является включение в этот набор ограничений обеспечение удовлетворенности заказчика. Соответственно задача управления разбивается на следующие части: управление временем, стоимостью и содержанием. Помимо этого необходимо уделить внимание управлению качеством, рисками, закупками, персоналом, коммуникациями и интеграцией.1
Для управления проектом существует следующие наиболее распространенные методологии:
1 PMI - не привязана к предметной области и разрабатывается Международным Некоммерческим Институтом Управления Проектами.
2 IPMA - не привязана к предметной области и разрабатывается Международной Ассоциацией Управления Проектами.
3 PRINCE2 - не привязана к предметной области и разрабатывается Центральным Компьютерным и Телекоммуникационным агентством Великобритании.
4 MSF - ориентирована на разработку ПО, автором является корпорация Microsoft.
5 RUP - ориентирована на разработку ПО, автором является корпорация Rational Software.
6 Методологии Agile- ориентирована на разработку программного обеспечения (ПО), автором является альянс Аgile (глобальная некоммерческая организация).
7 Набор моделей CMMI - ориентирован на разработку ПО, автором является Университет Карнеги-Мелона.
Многие из этих методологий схожи между собой. Далее рассматривается управление с использованием методологии PMI, основные
Хрыкин Евгений Валерьевич - ВГТУ, аспирант, e-mail: [email protected] Кострова Вера Николаевна - ВГТУ, д-р техн. наук, профессор, тел. (473) 220-56-16
положения которой изложены в своде знаний РМВоК.
Жизненный цикл проекта разработки программного обеспечения состоит из следующих этапов: инициация, планирование, мониторинг, выполнение, закрытие. Причем все этапы, кроме инициации и закрытия, выполняются циклично.
На этапе инициации происходит выбор руководителя проекта и разработка и утверждение устава проекта. В устав должны в обязательном порядке входить пункты с описанием менеджера проекта, сроков, бюджета, содержания работ и заинтересованных лиц.
На этапе планирования составляется и постоянно корректируется пакет планов разработки продукта. Наиболее важным среди планов является план управления содержанием, который служит документом, содержащим сведения о работах, которые необходимо выполнить, соответствующих им срокам и требуемых ресурсах. В дальнейшем планы используются в первую очередь, как средство коммуникации между участниками проекта.
Возможный алгоритм планирования состоит из следующих этапов:
1 Определение необходимых этапов планирования.
2 Сбор и финализация требований. Используемый шаблон: реестр заинтересованных лиц и матрица требований. Планирование осуществляется командой.
3 Формирование концепции. Используемый
шаблон: концепция проекта. Планирование
осуществляется командой.
4 Принятие решения о закупках.
5 Определение набора команды.
Используемый шаблон: перечень ресурсов.
6 Создание иерархической структуры работ (ИСР). Используемый шаблон: документ с ИСР и словарь ИСР. В настоящее время поддерживается соответствующим программным обеспечением. Планирование осуществляется командой.
7 Создание перечня действий. Используемый шаблон: перечень действий. В настоящее время поддерживается соответствующим программным обеспечением. Планирование осуществляется командой.
8 Создание сетевой диаграммы. Используемый шаблон: сетевая диаграмма. В настоящее время
поддерживается соответствующим программным обеспечением. Планирование осуществляется командой.
9 Оценка требуемых ресурсов. Используемый шаблон: ресурсы, распределенные по работам. В настоящее время поддерживается соответствующим программным обеспечением. Планирование осуществляется командой.
10 Оценка продолжительности действий и стоимости. Используемый шаблон: оценки сроков и стоимости. В настоящее время поддерживается соответствующим программным обеспечением. Планирование осуществляется командой.
11 Формирование расписания. Используемый
шаблон: расписание. В настоящее время
поддерживается соответствующим программным обеспечением.
12 Создание бюджета. Используемый шаблон: предельная цена проекта. В настоящее время поддерживается соответствующим программным обеспечением.
13 Планирование качества. Планирование осуществляется командой.
14 Создание плана улучшения процессов.
15 Распределение ролей и ответственностей. Планирование осуществляется командой.
16 Создание плана коммуникаций. Планирование осуществляется командой.
17 Управление рисками: идентификация
рисков, их качественный и количественный анализ, планирование реагирования на риски.
Используемый шаблон: реестр рисков.
Планирование осуществляется командой.
Данные шаги повторяются циклично до получения конечного продукта.
На первом этапе выполняется определение необходимых этапов планирования. Этот выбор зависит от размера проекта, личных предпочтений и опыта менеджера проекта.
Для управления ожиданиями заказчика
необходим этап сбора требований. На данном шаге происходит сбор информации от всех заинтересованных лиц. Это может быть реализовано в виде интервью, анкетирования, мозговых штурмов и прототипирования. При сборе требований необходимо в обязательном порядке опрашивать конечных пользователей, а не только представителей заказчика. После получения всех данных, необходимо провести балансировку
требований - отбор требований, реализация
которых предполагается в рамках проекта.
Полученные на предыдущих этапах планирования документы необходимо собрать в единый реестр, доступный для ознакомления всем участникам проекта. Это достигается благодаря формированию концепции проекта - документа, содержащего краткое описание и ссылки на ранее созданные документы.
На следующем этапе планирования происходит определение и захват требуемых для проектов ресурсов - набор команды и необходимые закупки. Перечень необходимых закупок
формируется и подается спонсору проекта. При наборе команды существует возможность набирать людей не только своей компании, но и подрядчиков, что позволит перенести часть задач на сторонних исполнителей.
По завершении предыдущих этапов необходимо создать иерархическую структуру работ. ИСР создается до разумной глубины при совместном обсуждении с командой. После определения всех необходимых работ происходит задание последовательности этих работ, необходимых для каждой из них ресурсов и продолжительности. В результате задания даты старта проекта получается расписание. На основе введенных данных рассчитывается стоимость работ, строится диаграмма Ганта и сетевая диаграмма. Затем проводится сетевой анализ расписания. Он включает в себя анализ и выравнивание ресурсов, анализ критического пути, сжатие расписания и анализ Монте-Карло. Сжатие расписание может проводиться за счет добавления ресурсов и распараллеливания работ.
Затем определяется предельная цена проекта. Она включает не только стоимости работ, но также стоимости всех резервов на непредвиденные случаи и управленческих резервов. В случае если рассчитанная предельная цена проекта превышает заявленную в уставе цену, то происходит перепланирование.
В результате проделывания описанных выше шагов получаются следующие данные,
соответствующие граням треугольника
ограничений:
1 Грань “содержание”: концепция + ИСР + словарь ИСР.
2 Грань “время”: расписание.
3 Грань “стоимость”: предельная цена проекта.
На следующем шаге необходимо провести
планирование ответственности, коммуникации и качества. Изначально вся ответственность лежит на менеджере проекта, но его цель заключается в том, чтобы переложить низкоуровневые задачи на плечи сотрудников команды. Данные о распределении ответственности могут быть описаны в виде матрицы ответственности, строкам которой соответствуют члены команды, столбцам - работы.
Коммуникации между членами команды могут быть реализованы в виде устного общения или документооборота. Часто они реализуются при поддержке соответствующего программного обеспечения. В этом случае коммуникации между членами команды организуются в виде создания задач, для которых указывается исполнитель, создатель задачи, срочность выполнения, информационная составляющая (например, “ошибка”, “к тестированию”, “требуется
информация”), дата создания и описание. После выполнения задача закрывается; при невозможности выполнения задачи она меняет статус и адресуется другому члену команды. Правила коммуникации с внешними по отношению
к команде субъектами регламентируется соответствующими документами.
Управление качеством должно выполняться на этапе всего жизненного цикла проекта, а не только перед сдачей продукта. При этом под качеством должен подразумеваться уровень и состав работ, описанный в уставе. Для того, чтобы не выйти за грани треугольника ограничений, нельзя стремиться к качеству выше заданного в уставе, кроме того, нельзя наделять продукт непредусмотренными характеристиками.
Для планирования рисков необходимо в первую очередь идентифицировать и составить перечень всех возможных рисков проекта. Для каждого риска задается хозяин - лицо, которому поручено обрабатывать риск (контролировать, что превентивные меры предприняты, а в случае наступления риска - реагировать на него).
Качественный анализ рисков заключается в том, что экспертами осуществляется оценка рисков, путем задания для каждого из них вероятности появления и тяжести из множества значений “высокое”, “среднее”, “низкое”. Затем на основе этих данных происходит ранжирование рисков. Самые значимые риски могут быть подвергнуты количественному анализу. Для этого может применяться сбор экспертных мнений, анализ Монте-Карло и оценка стоимости риска.
Затем следует планирование реагирования на риск. При этом для каждого из выбранных рисков составляется два вида планов. “План А” - это стратегия реагирования на риск. Реагирование на отрицательные риски может заключаться в нивелировании (устранении корневой причины риска), ослаблении, переносе (например, на подрядчика) или принятии. Реагирование на положительные риски может заключаться в использовании (задание условий, гарантирующих корневую причину риска), усилении, разделении (например, с дружественными компаниями) или принятии. “План Б” будет использоваться
«хозяевами рисков», если “План А” окажется недостаточно эффективен. Обычно он включает действия на случай, когда событие, описываемое в риске, уже произошло. После описанных действий для управления рисками необходимо изменение планов и определение резервов.
Кроме выше описанных шагов планирования возможно также использование подходов к управлению изменениями и конфигурациями.
После разработки начального плана происходит запуск работ проекта. В это время на менеджера проекта накладывается обязанность выполнять следующие виды работ:
1 Отслеживание выполнения работ. В том числе сбор показателей прогресса, анализ показателей и внесение корректив в расписание и предельную стоимость проекта.
2 Управление рисками.
3 Управление изменениями.
4 Управление ожиданиями заказчика.
5 Мотивация и развитие проектной команды.
6 Предоставление выше стоящим должностям отчетности о выполнении проекта.
События в этих работах могут приводить к изменению начального плана, что является нормальным рабочим процессом.
На этапе закрытия проекта происходит сдача-приемка продукта, высвобождение ресурсов и документирование всей важной информации по проекту.[1]
Как видно из алгоритма планирования, почти все его этапы базируются на документах и правилах методологии. Это позволяет автоматизировать данные шаги на основе специального программного обеспечения. Существующие программные продукты не позволяют в полной мере автоматизировать этот процесс. Кроме того, они сложны в использовании, тяжеловесны и дорогостоящи как для использования, так и для развертывания на предприятии.
Тот факт, что большинство этапов планирования разрабатываются в результате обсуждения проблем командой, а не единолично, позволяет воспользоваться преимуществами мультиагентной системы (МАС).
Преимущества оптимизации управления проектами на основе МАС были доказаны в ходе исследований сетей потребностей и возможностей (ПВ-сетей). При этом мультиагентный подход к управлению производством заключается в том, что всем ресурсам и этапам (заказам на работы) ставятся в соответствие программные агенты (небольшие интеллектуальные программы), действующие от лица и в интересах этих заказов и ресурсов. Таким образом, реализуется взаимодействие агентов потребностей и возможностей. В ходе переговоров агентов строится квазиоптимальный, сбалансированный по многим критериям план производства с учетом индивидуальных ограничений и предпочтений.
В качестве критериев обычно выступают требование максимальной загруженности ресурсов и минимизация сроков выполнения заказов. Агенты заказов и ресурсов могут вступать в непосредственные связи между собой и инициировать процесс взаимного пересмотра и согласования планов по мере возникновения ожидаемых или непредвиденных событий (например, недоступности ресурса). Подобный подход является незаменимым на практике для управления производством сложных продуктов в режиме реального времени, требующего учета множества индивидуальных особенностей производства каждого элемента в условиях непредвиденных изменений [2].
При этом вне зависимости от того, является ли система «коммерческой» или нет по своему прямому назначению, каждый агент или их некоторое сообщество могут получить в системе свой «интерес» и взаимодействовать на экономической основе равноправного партнерства с другими агентами в рамках внутреннего рынка системы. В этом случае агенты могут не только
интеллектуально (с учетом финансовых ограничений) осуществлять постоянный
«матчинг» своих потребностей и возможностей, конкурировать между собой и кооперироваться для достижения поставленных целей, реализуя идеи самоорганизации, но и заботиться о собственной прибыли, сокращать затраты и увеличивать доходы - и в результате использовать полученные средства для своего развития, что обычно и происходит на свободном рынке в ходе естественной эволюции предприятий.
Однако главная особенность предлагаемого подхода состоит в развитии имеющихся механизмов самоорганизации агентов специальным «методом компенсаций», а также в разработке нового механизма для реализации эволюции в рассматриваемых системах. При этом предлагается использовать такую микроэкономику агентов, в которой каждая из сущностей напрямую связана с конечными результатами деятельности всей организации и, соответственно, участвует в распределении прибыли всей системы
(предприятия) или вместе с ней терпит убытки. В результате деньги агентов (сущностей), с одной стороны расширяют возможности агентов и, с другой - выступают в качестве критерия
эффективности деятельности агента в ходе эволюционного «естественного отбора» агентов. Кроме того, впервые областью применения МАС становится «мир абстракций», где главными действующими лицами становятся агенты
концептуальных (абстрактных) сущностей, таких, как понятия, символы, слова или кластеры, которые также получают возможность вступать в переговоры, торговаться заключать сделки,
инвестировать друг друга, богатеть, платить неустойки или штрафы и иногда разоряться. Такая архитектура МАС называется “холистической”. [3]
Для решения задачи управления на основе ПВ-сети могут использоваться следующие модели взаимодействия агентов:
1 Расширенная аукционная модель. Она заключается в том, что агенты потребностей и возможностей, инициируемые событиями на рынке, связанным с приходом нового заказа или отзывом существующего, появлением нового ресурса или его исчезновением, а также любым другим изменением хотя бы у одного из участников взаимодействия, собирают новый аукцион агентов в ПВ-сети и получают новые предложения. Если аукцион инициирован новым агентом возможности, то для установления связи выбирается тот агент потребности, который предложил наилучшие условия. И наоборот, если аукцион инициирован агентом потребности, ищется агент возможности, предлагающий наилучшие условия.
2 Метод компенсаций. Он позволяет более согласованно принимать решения о разрыве связей между агентами. В этом методе структура взаимодействия агентов в ПВ-сети не только выстраивается специально под каждый новый заказ, но и потом пересматривается и реконструируется
под другие заказы. Этот способ базируется на сквозном динамическом распределении прибыли между взаимодействующими агентами. Суть метода, первоначально применявшегося для решения задач автомобильной логистики, состоит в том, что приходящий новый заказ не может “перебить” существующие заказы и напрямую использовать уже забронированные другими заказами ресурсы или изделия (даже менее выгодными для предприятия), но может “договориться с ними”, предлагая компенсацию из собственной прибыли. В результате прибыль заказов постоянно перераспределяется с учетом меняющейся ситуации, достигается более глубокая кооперация, более эффективное и гибкое использование всех ресурсов предприятия. Кроме того, если система не может разрешить ситуацию, допускается выход на клиентов со “встречным предложением” пересмотреть условия заказа и, например, разрешить отложить срок поставки в обмен на дополнительную скидку по цене товара.
3 Виртуальный “круглый стол”. Более сложная мультиагентная модель взаимодействия, предназначенная для согласованного коллективного принятия решений, призвана моделировать процесс достижения договоренностей людей за “круглым столом”. При этом каждый из участников, обладающий своей точкой зрения на предмет, “по кругу” делает свое предложение по заданному предмету, исходя из своих критериев и ограничений, но способен изменять и пересматривать это решение, возвращаться на несколько шагов назад в случае, если он выходит за рамки общих ограничений. Такая модель виртуального круглого стола позволяет решать задачи согласованного удовлетворения нескольких потребностей на основе многих возможностей, что может быть использовано, в частности, для поддержки процессов принятия решений при взаимодействии нескольких департаментов предприятия в решении сложных общих задач, например, конструкторов, технологов, дизайнеров и экономистов при проектировании новых автомобилей.
4 Модель со связанным обучением агентов. Наиболее сложной среди используемых является модель взаимного обучения агентов, превращающая самих агентов в открытые системы. В этой модели в мультиагентом сообществе могут динамически появляться агенты, которые заранее не были известны другим агентам. Для того, чтобы начать взаимодействовать между собой, эти агенты должны “представиться” другим агентам и объяснить им, какие действия и при каких условиях могут выполнять, что требует передачи фрагмента знаний от одного агента к другому и его распространения в ПВ-сети. Такое взаимодействие позволит строить системы эволюционным путем, автономно определяя новые компоненты и заставляя их самостоятельно договариваться с существующими компонентами “на ходу”, без какого-либо останова и перезапуска системы. Это
открывает путь к внедрению механизмов эволюции в рассматриваемые системы, что обеспечивает согласованное развитие системы вместе с развитием самого предприятия.
Рассматриваемые модели позволяют создавать живучие и надежные системы, поскольку потеря любой части открытой системы тут же активизирует внутренние процессы взаимодействия агентов потребностей и возможностей,
направленные на замещение утраченной возможности (и точно так же система ведет себя при появлении новых возможностей, стремясь к замещению своих компонент более эффективными)
[4].
Проблема применения мультагентных систем управления распределением производственных ресурсов заключается в том, что в результате переговоров происходит построение квазиопти-мального плана, то есть, полностью перебрав все варианты, в большинстве случаев можно найти решение лучше (в смысле оптимизации выбранных показателей эффективности) того, которое было получено в ходе мультиагентных переговоров.
Однако на практике в случае высокой интенсивности потока поступающих событий данная проблема не является критической, так как каждое новое событие приводит к частичному пересмотру плана, а, следовательно, к изменению ключевых показателей эффективности. При этом важнее локализовать изменения в расписании и не производить полное перепланирование в ответ на каждое поступающее событие. Таким образом, критерием достаточности решения, полученного мультиагентной системой, является его близость к глобальному оптимуму.
Для исследования данного свойства был проведен эксперимент по планированию расписания двумя способами: полным перебором возможных вариантов результирующего расписания и построением варианта с помощью мультиагентной системы планирования. В качестве критерия оптимальности расписания был задан минимум времени выполнения (интервал между началом самого первого этапа и окончанием самого последнего).
Для каждого расписания, полученного в процессе перебора, осуществлялась оценка времени выполнения производства. В результате сравнения
решения, полученного с помощью мультиагентной системы (без специальной оптимизации) и путем полного перебора возможных вариантов было обнаружено, что для установленных условий задачи среди решений, найденных в результате полного перебора, лишь 4 % лучше (по выбранному критерию эффективности), чем решение, предложенное мультиагентной системой.
Методология на основе ПВ-сетей поддержана развитыми инструментальными средствами и обеспечивает эффективную реализацию прикладных МАС в рамках заявленной концепции. Однако она ориентирована на сравнительно узкий класс систем промышленной логистики и агентную модель, описывающую конкуренцию за ресурсы [5].
Все это свидетельствует о том, что оптимизация управления производством на основе МАС имеет большой потенциал и, несмотря на некоторый объем проведенных исследований, эта задача нуждается в дальнейшем глубоком изучении. Это может выражаться в исследованиях архитектур агентов и мультиагентных систем, способов коммуникаций агентов и разработке на их основе алгоритмов принятия оптимальных решений.
Литература
1. Селиховкин И.А. Управление ИТ-проектом.
Эффективная система «с нуля» в любой организации // Санкт-Петербург, 2010, 90 стр. ШТ:
http://www.selikhovkin.ru/ITPMSelikhovkin.pdf
2. Мультиагентная система распределения производственных ресурсов в тяжелом машиностроении / А.В. Иващенко, М.В. Андреев, П.О. Скобелев, С.А. Кривенок // Программные продукты и системы, № 3, 2010. иКЬ: http://swsvs.ru/index.php?page=article&id=2571
3. Открытые мультиагентные системы для холонических предприятий / Скобелев П.О. // Научнотеоретический журнал "Искусственный интеллект", №3, 2001 - С. 98 - 119.
4. Открытые мультиагентные системы для оперативной обработки информации в процессах принятия решений / Скобелев П.О. // Автометрия, №6, 2002. - С. 45 -61.
5.Швецов А.Н. Агентно-ориентированные системы: от формальных моделей к промышленным приложениям / Всероссийский конкурсный отбор обзорно-аналитических статей по приоритетному направлению "Информационнотелекоммуникационные системы", 2008. - 101 с.
Воронежский государственный технический университет
OPTIMIZATION OF SOFTWARE DEVELOPMENT PROJECT MANAGEMENT BASED ON MULTIAGENT SYSTEMS E.V. Hrykin, V.N. Kostrova
The paper deals with the life cycle of software development project, provides an overview of methodologies for project management and planning based on the methodology of PMI. Substantiates the theoretical possibility and advantages of optimizing the management of the project based on multi-agent system
Key words: project management, PMI, agents
