[Из песочницы] Интеллектуальное управление проектами и имитационное моделирование03.08.2015 22:52

Введение

Данная статья планируется как первая публикация из серии статей, посвященных интеллектуальному управлению проектами.
В публикации будут кратко рассмотрены вопросы имитационного моделирования управления проектами (УП) и интеллектуализации УП.

Предполагается, что читатель поверхностно знаком с теорией управления проектами и системным анализом, а так же возможно с проектированием информационных систем. Углубленные знания по всем или одному из направлений могут вызвать непреодолимое желание написать комментарий, что приветствуется! … или запустить в автора чем-нибудь тяжелым…
Итак, приступим.

1. Модель проекта

В соответствии с PMBoK 5 (1) выделяют несколько областей знаний управления проектами (все их мы затрагивать не будем). В каждой из областей проект рассматривается с разных сторон, выделяются всевозможные сущности/объекты, методы управления и их влияние на проект, как на способ организации работы для достижения конкретной цели или решения задачи. Здесь мы лишь кратко опишем типичные объекты, которые можно выделить при управлении проектами, их характеристики, взаимосвязи, а так же общую механику имитационного моделирования и соответствие её жизненному циклу проекта.

Типичные объекты и их характеристики
Проект обладает следующими характеристиками: руководитель, наименование, тип, планируемая дата начала, фактическая дата начала, планируемая дата окончания, фактическая дата окончания, текущее состояние жизненного цикла, начальный баланс проекта, текущий баланс проекта.
Расчетные или определяемые на основании других объектов характеристики: команда проекта, процент выполненного объема работ, отставание или опережение по объему выполненных работ, отставание или опережение по срокам, планируемая стоимость.
Задача/Работа — здесь указываются схожие характеристики с проектом, к которым добавляются следующие: приемщик, ответственный исполнитель, тип выполняемой работы, проект, место, процент готовности.
Расчетные или определяемые на основании других объектов характеристики: последовательность выполнения внутри проекта, состав исполнителей, история изменения состояния, стоимость выполнения задачи/работы.
Материальный ресурс (основные средства): тип объекта, дата постановки на учет, дата ввода в эксплуатацию, название, балансовая стоимость.
Расчетные или определяемые: амортизация, текущее состояние, где задействован сейчас, расписание использования.
Расходуемый ресурс (сырье, запасные части): тип ресурса, начальные запасы, место расположения, дата поставки, срок годности.
Расчетные или определяемые: текущие запасы, интенсивность расходования
Персонал: ФИО, постоянное размещение.
Расчетные или определяемые: доступность для работы, совместимость с другими сотрудниками, текущее размещение на время выполнения работы, где задействован, расписание работы.
Риск: вероятность возникновения, цена ущерба, описание, продолжительность влияния, индикатор срабатывания риска.
Расчетные или определяемые: мероприятия по устранению последствий, мероприятия по недопущению возникновения или уклонению, стоимость, сроки реализации.

Взаимосвязи и зависимости
Проект-[1: M]-задача — выполняются в ограничениях сроков проекта.
Задача-[1: M]-задача — могут иметь иерархическую связь (вертикальную), могут иметь связь в виде указания последовательности выполнения (горизонтальную).
Материальный ресурс-[M: M]-задача — привязывается через отношение расписания к задаче с указанием расписания использования.
Расходуемый ресурс-[M: M]-задача — привязывается через отношение расписания к задаче с указанием необходимого запаса для ее выполнения.
Персонал-[M: M]-задача — могут быть задействованы в рамках нескольких задач, для чего указывается расписание работ и процент использования в задаче.
Риск-[M: M]-[Объект] — при указании взаимосвязи с [Объектом] указывается вероятность возникновения.
Разумеется это не полный перечень объектов.

Механика
Каждый такт моделирования соответствует фиксированному времени — 1 день/час выполняемого проекта. Для этого примем все сроки, и интервалы в проекте — кратными величине 1 день/час. Схема цикла моделирования изображена далее:

Цикл моделирования заключается в следующем:

1. Устанавливаются начальные значения для проекта для симуляции. Создается проект, подготавливается расписание проекта, дерево рисков. На этом этапе так же доступны функции интеллектуальной поддержки управления проектами, но этот шаг не может быть выполнен без ЛПР.
2. Итерация начинается с определения действующих значений.
3. Выполнение такта. Каждый такт моделирования выполняются следующие операции:
   
   • расходуются ресурсы по задачам,
   • проверяется вероятность отказов (рисков),
   • выполняется определенный объем работ из перечня работ по проекту,
   • выполняются финансовые операции по проекту.
   
   
4. Сохраняются рассчитанные значения для определенного такта
5. Проверка условий завершения моделирования.
6. Завершение моделирования и вывод результатов (аналитических, агрегированных и подробных значений по шагам моделирования). При окончании моделирования сохраняются последние (итоговые) значения и причины прекращения моделирования.
7. Выдача пользователю (или лицу, принимающему решения — ЛПР) информации о состоянии проекта без использования оптимизаций, модулей аналитики и поддержки принятия решений. От пользователя необходима реакция на текущее состояние (при необходимости) или продолжение моделирования.
8. Оценка управленческих решений пользователя на основе текущих значений, а так же ретроспективы их изменения и принятых пользователем управленческих решений с применением алгоритмов оптимизаций, модулей аналитики и поддержки принятия решений.

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

• инициализация и планирование проекта — 1 шаг
• реализация проекта — 2–5, 7 и 8 шаг цикла
• завершение проекта — 6 шаг

Общие замечания
Все данные промежуточных шагов симуляции сохраняются и накапливаются в пределах текущей симуляции. При дальнейшей работе оптимизационных алгоритмов (на 8 шаге цикла симуляции) могут использоваться данные как текущей, так и предыдущих завершенных симуляций (с поправкой на результат завершения симуляции).
При нескольких одновременно выполняемых работах проекта симуляция для них выполняется как бы параллельно (т.е. симулируется одновременное выполнение), в случае отсутствия разногласий по используемым ресурсам.
При нескольких сотрудниках/типах ресурсов моделирование выполняется для каждого из них параллельно (т.е. расходуются одновременно), в случае отсутствия разногласий по используемым ресурсам.

2. Технологии реализации

Основные рассматриваемые вопросы:

• хранение структуры данных проекта в БД
• интерфейс для взаимодействия пользователя со структурой БД
• средства реализация сервера симулятора
• интерфейс для взаимодействия между БД и сервером симулятора
• хранение нейронной сети и промежуточных шагов итерации симулятора
• взаимодействие между интерфейсом приложения и нейронной сетью

Как несложно заметить объекты проекта и связи между ними легко представить в виде отношений реляционной БД и хранить в таком виде тоже не сложно, т.е. будет достаточно реляционной БД — MySQL, например.
Для разработки интерфейса выберем фреймворк Yii 2 (и соответствующий стек технологий — PHP, HTML и т.д.).
Реализация сервера симуляции — Node.js
Реализация нейронной сети для Node.js, например — habrahabr.ru/post/193738
Взаимодействие с frontend (Yii2) и Node.js — github.com/oncesk/yii-node-socket
Остается открытым вопрос о формате хранения самой нейронной сети, на которую накладываются следующие требования:

1. Отражение свойств нейронной сети (взаимосвязи, веса связей и т.д.)
2. Безопасный доступ (исключить непосредственное влияние пользователя на сеть)
3. Быстрая загрузка нейронной сети в память.
4. Возможность обучения сети.

3. Логика управления

Для каждой из областей знаний управления проектами существуют постановки задач и описанные математические способы их решения, с которыми автор поверхностно знаком. В зависимости от модели управления знание этих правил и способов решения задач должны перераспределяться между системой и пользователем. Модели управления выделены следующие: (1)

1. управление с уведомлениями — система не воздействует на объект (проект), но отображает уведомления об изменениях показателей и возможности выполнения действий (принятие решений и максимум знаний требуется от ЛПР).
2. интерактивное управление — система предлагает управляющие воздействия, но решение остается за ЛПР (принятие решений остается за ЛПР).
3. эвристическое управление — система принимает решения и выполняет некоторые воздействия самостоятельно (ЛПР исключается из процесса управления).

Реализация самого управления заключается в мониторинге и анализе совокупности характеристик проекта и оценке их отклонения от «нормальных» для данного времени, с учетом динамики их изменения. Управляющие воздействия подбираются на основе полученных данных (т.е. при наличии соответствия такой комбинации характеристик какого-либо воздействия), а так же анализируются схожие проекты со схожими ситуациями и принятые в них решения. В соответствии со степенью или уровнем отклонения могут применяться те или иные способы воздействия:

1. Перераспределение ресурсов между задачами;
2. Перераспределение трудовых ресурсов между задачами;
3. Изменение расписания выполнения задач;
4. Планирование закупок;
5. Уклонение или принятие мер по ликвидации последствий рисков.

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

1. Указанные экспертами характеристики.
2. Наличие информации в накопленной базе выполненных проектов.

Данные механизмы логично строить с применением нейронных сетей и нечеткой логики. Использовать эти алгоритмы можно как на этапе инициализация и планирование проекта, так и на этапе его реализации. Возможно выполнение анализа — как изменяться характеристики после применения управляющего воздействия.

4. Интеллектуализация имитации

Т.о. на этапе выполнения такта возможно полное исключение ЛПР из процесса управления. Что же для этого необходимо? Для моделирования событий нужны уточнения некоторых характеристик (приближенные). Для выполнения управляющих воздействий система должна «знать» некоторую дополнительную информацию относительно предметной области, например:
1. Перераспределение ресурсов между задачами.

• взаимозаменяемость ресурсов — можно задать таблицами-матрицами соответствия;
• вероятность выхода из строя ресурсов — указывается вероятность в диапазоне от Xmin до Xmax;
• возможность параллельного использования несколькими исполнителями — как логическое свойство задачи.

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

• взаимозаменяемость и несовместимость персонала — можно задать таблицами-матрицами соответствия;
• производительность трудовых ресурсов — как расчетное значение на основе данных о: опыте работы, возрасте, повышении квалификации и т.п.
• соотношение типов выполняемой работы и требуемых для ее выполнения навыков — аналогично решается матрицами;
• вероятность невыхода трудовых ресурсов (вероятность болезни) — указывается вероятность в диапазоне от Xmin до Xmax;
• возможность параллельного выполнения одной работы несколькими исполнителями — как логическое свойство задачи.

3. Изменение расписания выполнения задач.

• возможна ли приостановка задачи, или выполнение должно быть непрерывным — как логическое свойство задачи;
• входит ли задача в «критический путь» (т.е. сроки ее выполнения непосредственно влияют на сроки завершения проекта) — определяется системой «налету».

4. Планирование закупок.

• интенсивность расходования ресурса — определяется системой «налету».
• возможность закупки необходимого оборудования — как логическое свойство задачи.

5. Уклонение или принятие мер по ликвидации последствий рисков.

• вероятность отказов оборудования — указывается вероятность в диапазоне от Xmin до Xmax;
• возможные варианты уклонения и ликвидации последствий — решается матрицами или списками соответствия (с указанием степени соответствия).

Это не исчерпывающий список задач. Здесь так же необходимо отметить тот факт, что универсального решения для любого проекта быть не может и, что хорошо для одного проекта — для другого смерть. Т.о. необходимы определенные ключевые характеристики, их совокупности, и их значения, которые позволяли бы типизировать и классифицировать, подбирая схожие проекты для обучения системы, например:

• типы задействованных ресурсов;
• типы поставленных задач;
• квалификация и умения задействованного персонала;
• размер бюджета;
• продолжительность проекта;
• успешность проекта;
• количество участников и т.д.

Далеко не последнюю роль будет играть фактор неопределенности как характеристик описанных выше, так и характеристик самого проекта.

5. Многоагентность

Как было отмечено выше, разногласия по использованию ресурсов могут быть как внутри проекта между задачами, так и между разными проектами, использующими одни и те же ресурсы. Для упрощения работы с ресурсами мы выделим агента, которого назовем «Арбитр ресурсов». Именно к нему будут обращаться агенты «Проекты» за необходимыми ресурсами, что даст возможность перераспределять даже зарезервированные ресурсы в зависимости от важности (критичности) выполняемых задач или проектов.

Заключение

Что даст такое имитационное моделирование или симуляция управления проектом? Ответ прост:

1. управление с уведомлениями — можно использовать как тренировку или тестирование ЛПР на знание определенных принципов или умение решать задачи связанные с управлением проектами.
2. интерактивное управление — отработка некоторых практик и проверка их на модели. Что даст возможность изменить модель для соответствия ситуации или наоборот оценить владение методами решения задач УП самому ЛПР (самопроверка).
3. эвристическое управление — возможность большого количества запусков симуляции и накопление определенного опыта (данных) об этих симуляциях для их дальнейшего анализа.

Однако сама имитация и симуляция — не конечная цель. В результате накопления достаточно точных простых и сложных моделей в базе симуляции, разработки и отладке поведения имитационной модели и модулей, осуществляющих интерактивное взаимодействие и эвристическое управление (без ЛПР), возможно использование накопленных правил и алгоритмов для управления (или интеллектуальной поддержки управления) реальными проектами (3).
Реализация такой системы в виде SaaS решения, с привлечением некоторого количества участников, позволит получить доступ к опыту работы (обезличенному) других участников (с возможностью обучения системы).

Список используемых источников

1. pmlead.ru/? p=1521. [В Интернете]
2. www.aaai.org/ojs/index.php/aimagazine/article/view/564. [В Интернете]
3. us.analytics8.com/images/uploads/general/US_2010–10_Whitepaper_BI_Project_Management_101.pdf. [В Интернете]

© Megamozg