Введение Известно, что большинство проектов по разработке информационных систем в настоящее время не завершаются в срок, превышают бюджет или сдаются с недостаточной функциональностью для того, чтобы системой можно было пользоваться. Согласно отчету Chaos Report о положении дел в разработке IT-проектов, выполненному компанией Standish Group [1], каждый пятый проект заканчивается неудачно, каждый второй не укладывается в срок либо выполняется с худшим качеством или неполным функционалом (рис. 1). Рис. 1. Характеристика успешности выполнения IT-проектов Одной из причин сложившейся ситуации являются неправильные решения, принимаемые менеджерами проекта, в частности неправильные решения, принимаемые на этапе исполнения проекта. Так, менеджеры проектов могут затянуть с моментом замены менее эффективного разработчика на более эффективного. Одной из задач по управлению IT-проектами является задача управления исполнением проекта [2]. Сложность данной задачи обусловлена тем, что, как правило, что-то идет не по плану, например нарушаются сроки и бюджет, причинами могут являться и такие факторы, как недооценка сложности задач, низкая производительность разработчиков и т. д. [3]. Для решений, принимаемых на данной стадии, характерен повышенный субъективизм. Принятие некорректных решений может привести к нарушению сроков проекта и (или) превышению бюджета. Одним из механизмов управления проектом на этапе исполнения является метод критической цепи [4]. Метод критической цепи Настоящим прорывом в области по управлению неопределенностью и рисками в управлении проектами явился метод критической цепи, предложенный Э. М. Голдраттом. Критическая цепь - самая длинная последовательность зависимых задач, у которых устранен конфликт ресурсов. Отсутствие конфликта ресурсов является главным отличием метода критической цепи от метода критического пути. Метод основан на теории ограничений [5], а также законах статистики [6]. Голдратт показал, что для борьбы с рисками в проекте необязательно закладывать подстраховку в каждую задачу, ее необходимо закладывать в сам проект. Для этих целей Голдратт предложил использовать буферы времени - буфер проекта и буфер слияния путей. Для всего проекта запас времени называется буфером проекта (помещается в конец проекта), для слияния некритических цепей с критической - буфером слияния путей. Для расчета размеров буферов необходимо иметь статистические данные распределения длительности каждой задачи. Выделяют следующие виды оценок: - EO - минимально возможное время исполнения задачи (оптимистическая оценка); - EM - наиболее вероятная оценка; - EP - пессимистическая оценка вероятности (все риски реализовались); - EA - оценка с вероятностью исполнения задачи 50 %. Размер буфера цепочки задач определяется на основании правила суммирования отклонений: , где , i - номер задачи. В плане буфер указывается как очередная операция, но операция, не имеющая содержания. Для каждого из буферов времени (проекта и слияния путей) по результатам мониторинга строится диаграмма (рис. 2). Рис. 2. Мониторинг состояния буферов Диаграмма состояния буферов используется для индикации состояния проекта. При мониторинге буфера условно выделяют три зоны: белую - все нормально (правая нижняя область), никаких действий предпринимать не нужно; серую - необходимо подготовить план действий (центральная область); черную - необходимо предпринимать действия (левая верхняя область). Примером действия может являться привлечение нового ресурса, переназначение задач ресурсам. Цели и задачи исследования Метод критической цепи предлагает простейший механизм управления состоянием проекта при помощи мониторинга состояния буферов. Метод не включает в себя описания действий, необходимых для корректировки проекта. К таким действиям может быть отнесена замена ресурса - частичная и полная. Для принятия решения о замене ресурса необходимо иметь информацию об истории выполнения задач проекта данным ресурсом, которая поможет принять правильное и своевременное решение. Таким образом, цель наших исследований - описание модели управления проектом на этапе исполнения для поддержки принятия решений менеджером проекта. Поскольку большая часть информации по управлению проектами, в связи с высокой вероятностью рисков, носит неопределенный или неточный характер (в частности, сроки завершения задачи и, как результат, - потребление буфера), то для данной системы необходимо применение нечетких множеств [7-9]. Предлагаемое решение Поскольку при выполнении заданий неизбежны отклонения, любой четко заданный график будет на деле приблизительной прикидкой. Вследствие этого необходимо, чтобы ресурсы периодически уведомляли об объемах оставшейся работы. Данный объем представляется в виде нечеткого трапециевидного числа, т. е оценки представляются в виде «не меньше», «не больше», «примерно» n часов. Дефаззификацию нечеткого числа можно выполнить при помощи индекса соответствия (agreement index) [10]. В результате получаем оставшуюся длительность выполнения задачи di. Количество выполненной работы рассчитывается по формуле , где Duration(wi, rj) - функция, возвращающая плановую длительность выполнения ресурсом rj задачи wi; k - номер цепи. Количество плановой работы в некоторый момент времени t рассчитывается по формуле , где - функция, возвращающая дату и время начала выполнения задачи. Разница в количестве плановой и выполненной работы, т. е потребление буфера, определяется по формуле . Степень потребления буфера определяется по формуле где Sk - размер буфера для цепи k. Степень завершения работ для цепи k рассчитывается по формуле , где - функция, возвращающая задачу, которая выполняется в текущий момент времени t для цепи k; - функция, возвращающая дату начала выполнения задач цепи; - функция, возвращающая плановую длительность выполнения задач цепи. Схематически данные характеристики приведены на рис. 3. Рис. 3. Расчет выполнения плана и потребления буферов На основании данных об уровне буферов (% потребления) и степени завершения задач получаем состояние цепи. В качестве сигнала выступает значение лингвистической переменной «Состояние цепи». Терм-множеством данной переменной являются следующие значения: - «С опережением графика» (Ahead); - «В соответствии с оптимистической оценкой» (Optimistic); - «Все хорошо» (Normal); - «В соответствии с пессимистической оценкой» (Pessimistic); - «Небольшой сбой» (Fault); - «Отставание» (Lag); - «Серьезное отставание» (Huge Lag). Функция принадлежности значения «С опережением графика» является функцией принадлежности класса L, «Серьезное отставание» - , остальных - t (рис. 4). Рис. 4. Функции принадлежности лингвистической переменной «Состояние цепи» Аргументом функции принадлежности является В качестве информации о ресурсе выступает значение лингвистической переменной «Производительность ресурса». Терм-множеством данной переменной являются следующие значения: - «Высокая производительность» (High); - «Средняя производительность» (Medium); - «Производительность ниже средней» (Bellow); - «Низкая производительность» (Low). Функция принадлежности значения «Высокая производительность» является функцией принадлежности класса L, «Низкая производительность» - , остальных - t (рис. 5). Рис. 5. Функции принадлежности лингвистической переменной «Производительность ресурса» Аргумент функции принадлежности , где History (rj) - функция, возвращающая историю выполнения задач ресурсом rj. Данная функция возвращает множество пар вида (tr, tp), где tr - фактическое время исполнения задачи; tp - плановое время исполнения задачи. Выходным сигналом является лингвистическая переменная «Заменяемость ресурса». Терм-множеством данной переменной являются следующие значения: - «Замена не требуется» (None); - «Единичная замена» (Single); - «Частичная замена» (Partial); - «Полная замена» (Full). Функция принадлежности значения «Замена не требуется» является функцией принадлежности класса L, «Полная замена» - , остальных - t (рис. 6). Рис. 6. Функции принадлежности лингвистической переменной «Заменяемость ресурса» Аргументом функции принадлежности является относительный объем работ ресурса, требующий замены. Общая модель нечеткого управления [11] представлена на рис. 7. Рис. 7. Модель нечеткого управления База правил - лингвистическая модель - представляет собой множество нечетких правил R(m) вида R(m): если(Состояние цепи = значение1 И Производительность ресурса = значение2 ТО Заменяемость ресурса = значение 3) Примеры правил приведены в таблице. Список правил Номер правила Посылка Следствие Состояние цепи Производительность ресурса Заменяемость ресурса 1 Ahead Medium None 2 Ahead Low None 3 Pessimistic Medium Single 4 Fault Medium Partial 5 Fault Low Full Отметим, что предложенная нами база правил представляет собой жесткий набор правил, самообучаемость системы нами не рассматривалась. Заключение Таким образом, нами предложено расширение метода критической цепи, представляющее собой модель нечеткого управления, которая позволяет оперативно определять ресурсы, требующие замены, а также степень их замены. С целью упростить управление учитываются лишь два фактора: потребление буфера и производительность ресурса. Для развития данной системы можно добавить также прогноз проекта, который будет указывать предполагаемую дату завершения проекта. Из рисков, со «срабатыванием» которых борется система, учитывается лишь риск «Низкая производительность». В случае дальнейшего развития системы можно добавить риск «Неправильная оценка». Предложенная нами база правил представляет собой жесткий набор правил, самообучаемость системы нами не рассматривалась. Для дальнейшего развития модели предполагается включение информационной поддержки принятия решений при управлении [12, 13], а именно генерация и ранжирование альтернатив. Альтернативами будут являться заменяемые ресурсы.