Модуль для разработки расписания проекта
Введение
Как работают современные автоматизированные информационные системы управления проектами? Какую выгоду получают организации от их внедрения? Сопоставима ли полученная выгода с затратами, понесенными в процессе разработки и внедрения таких систем? Подобные вопросы часто рождаются в головах руководителей, стремящихся перевести свои компании на рельсы проектного управления.
Основная выгода от использования автоматизированных информационных систем состоит в сокращении временных и финансовых затрат на выполнение формализованных алгоритмических операций, которые не требуют интеллектуального труда. Наиболее распространенными примерами таких операций в проектном управлении очевидно являются пересчет расписания, бюджета и ресурсного плана проекта, построение отчетов. Пользователю достаточно изменить всего один параметр, например, дату начала проекта, и система выполнит все требуемые вычисления за время меньшее, чем потратил бы пользователь, выполняя их вручную. Чем больше операций реализует автоматизированная информационная система (далее - АИС), тем меньше операционные затраты организации.
Сокращение затрат является один из важных факторов при принятии руководством решения о внедрении АИС. Однако часто внедрение не приносит ожидаемых выгод. Причиной такой ситуации является нежелание сотрудников организации использовать систему из-за ее сложности или неприменимости к выполняемым ими операциям. Поэтому важным фактором успеха внедрения АИС является ее адекватность и простота использования.
По данным исследования Young Crew SOVNET почти четверть российских компаний используют автоматизированные системы управления проектами (далее - ИСУП) на базе решений Microsoft PPM. Эти решения автоматически выполняют основные рутинные операции, связанные с пересчетом расписания, бюджета и ресурсного плана проекта. Также они предоставляют широкие возможности по настройке ИСУП под нужды организации. Однако решения на базе Microsoft PPM считаются сложными в использовании и требуют от пользователей серьезной предварительной подготовки. Как следствие, риск неполучения выгод от использования системы достаточно велик.
В 2016 году был запущен исследовательский проект, состоящий в разработке модулей с открытым исходным кодом для последующего их использования при создании адекватных задачам пользователей и простых в использовании ИСУП. Одним из них является модуль predict, позволяющий разрабатывать расписание проекта. Модуль разработан на интерпретируемом языке программирования Python, широко используемом в академической среде для быстрой проверки гипотез и создания прототипов АИС. Описание возможностей модуля predict
в части разработки расписания проекта приведено в разделах ниже.
Класс Activity
Базовым классом для работы с расписанием проекта модуля predict
является класс Activity
. Класс является логическим представлением работы, характеризующейся рядом атрибутов:
Табл. 1. Атрибуты класса Activity
№ | Атрибут | Код | Описание |
---|---|---|---|
1. | Идентификатор | id |
Идентификатор работы, представленный в виде числа |
2. | Дата начала | start_date |
Дата начала работы, представленная в виде числа |
3. | Дата окончания | finish_date |
Дата окончания работы, представленная в виде числа |
4. | Длительность | duration |
Длительность работы, представленная в виде числа |
5. | Начало не раньше | not_early_date |
Дата, раньше которой не может стартовать работа. Дата представлена в виде числа |
6. | Последователи | next_activity |
Массив работ, которые могут стартовать только при условии выполнения текущей работы |
7. | Предшественники | prior_activity |
Массив работ, выполнение которых является обязательным условие старта текущей работы |
Атрибуты start_date
, finish_date
, duration
и not_early_date
представлены в виде чисел по двум причинам:
-
чтобы избежать использование сторонних модулей для работы с датами, тем самым сократив количество зависимостей;
-
чтобы избежать необходимости работы с разными форматами дат (например, даты могут быть представлены в формате “Дата”, а могут быть представлены в формате “Дата и время”).
Атрибут not_early_date
представляет единственное ограничение на сроки выполнения работы. Для сравнения в решениях Microsoft PPM реализовано шесть таких ограничений – “Начало не ранее”, “Окончание не ранее”, “Начало не позднее”, “Окончание не позднее”, “Фиксированное начало”, “Фиксированное окончание”. Четыре последних мешают перестроению сетевой модели и получению прогнозной даты окончания проекта, поэтому было принято решение не реализовывать их в классе Activity
. Ограничение “Окончание не ранее” на практике используется реже, чем ограничение “Начало не ранее”, поэтому для упрощения модели оно осталось за рамками функционала модуля.
Атрибуты next_activity
и prior_activity
предназначены для хранения связей между работами. Они играют главную роль при пересчете расписания проекта.
Атрибуты класса Activity
характеризуют состояние работ расписания проекта. Операции, которые могут быть выполнены над работами, представлены методами класса:
Табл. 2. Методы класса Activity
№ | Метод | Параметр | Описание |
---|---|---|---|
1. | __init__ |
id – идентификатор работы; start_date – дата начала работы; finish_date – дата окончания работы; duration – длительность работы; not_early_date – дата, раньше которой не может стартовать работа |
Создает работу |
2. | get_id |
Возвращает идентификатор работы | |
3. | get_start_date |
Возвращает дату начала работы | |
4. | set_start_date |
start_date – новая дата начала работы |
Задает новую дату начала работы, выполняет пересчет даты окончания работы и значений атрибутов работ-последователей |
5. | get_finish_date |
Возвращает дату окончания работы | |
6. | set_finish_date |
finish_date – новая дата окончания работы |
Задает новую дату окончания работы, выполняет пересчет длительности работы и значений атрибутов работ-последователей |
7. | get_duration |
Возвращает длительность работы | |
8. | set_duration |
duration – новая длительность работы |
Задает новую длительность работы, выполняет пересчет даты окончания работы и значений атрибутов работ-последователей |
9. | recalculate_next |
Выполняет пересчет значений атрибутов работ-последователей | |
10. | get_not_early_date |
Возвращает дату, раньше которой не может стартовать работа | |
11. | set_not_early_date |
not_early_date – новая дата, раньше которой не может стартовать работа |
Задает новую дату, раньше которой не может стартовать работа, и выполняет пересчет даты начала работы |
12. | get_next |
Возвращает идентификаторы работ-последователей | |
13. | is_valid_next_activity |
next_activity – проверяемая работа |
Выполняет проверку, может ли проверяемая работа стать последователем для текущей работы |
14. | append_next |
next_activity – добавляемая работа |
Выполняет включение добавляемой работы в массив работ-последователей текущей работы и пересчет значений атрибутов работ-последователей. При этом текущая работа включается в массив работ-предшественников добавляемой работы |
15. | remove_next |
next_activity – удаляемая работа |
Выполняет исключение удаляемой работы из массива работ-последователей текущей работы и пересчет значений атрибутов работ-последователей. При этом текущая работа исключается из массива работ-предшественников удаляемой работы |
16. | __str__ |
Представляет работу в виде ее идентификатора |
Метод __init__
, являющийся конструктором объекта класса Activity
, не принимает на вход массивы работ-предшественников и последователей в связи с тем, что соответствующие работы могут быть не определены к моменту создания текущей. Поэтому построение расписания должно происходить в два этапа:
-
создание работ, входящих в расписание;
-
установка связей типа “Предшественник-последователь” между работами.
Связь “Предшественник-последователь” сопоставима со связью типа “Окончание-начало” в решениях Microsoft PPM. Этот тип связи на практике используется чаще, чем три остальных – “Начало-начало”, “Начало-окончание”, “Окончание-окончание”, - и его вполне достаточно для построения любого расписания.
Работа со значениями атрибутов объектов класса Activity
осуществляется с использованием методов, помеченных префиксами “get_” и “set_”. Эти методы предназначены для получения и установки значений атрибутов соответственно. Для класса Activity
не определен метод set_id
для задания идентификатора работы. Предполагается, что идентификация работ будет реализована на уровне хранилища данных ИСУП, построенной на базе модуля predict
. Изменение временных параметров работы, осуществляемое с помощью методов set_start_date
, set_finish_date
и set_duration
, подчинено следующим правилам:
-
изменение даты начала работы приводит к изменению даты ее окончания, длительность работы остается неизменной;
-
изменение даты окончания работы приводит к изменению ее длительности, дата начала остается неизменной;
-
изменение длительности работы приводит к изменению даты ее окончания, дата начала остается неизменной;
-
в случае успешного изменения временного параметра выполняется пересчет значений атрибутов работ-последователей с использованием метода
recalculate_next
.
В классе Activity
отсутствует понятие лага между работами. Для фиксации того, что работа-последователь начиналась спустя некоторое время после завершения самой поздней работы-предшественника, используется атрибут not_early_date
. Значение атрибута может быть выставлено автоматически с помощью метода set_not_early_date
при установке новой даты начала работы методом set_start_date
. Также оно может быть задано пользователем методом set_not_early_date
.
Назначение метода is_valid_next_activity
– предотвратить появление циклов в расписании проекта. Метод применяется в связке с append_next
. Также он может быть использован самостоятельно для решения частных задач, возникающих в процессе разработки ИСУП на базе модуля predict
.
Метод remove_next
предназначен для разрыва связи между работой-предшественником и работой-последователем. Важно отметить, что после разрыва связи работа-последователь остается в расписании и может быть использована для дальнейшего планирования проекта.
Моделирование расписания при помощи модуля predict
Для тестирование модуля predict
было разработано веб-приложение, загружающее данные по работам из файла формата XML и выполняющее пересчет расписания в ответ на изменение значений атрибутов работ (за исключением атрибутов “Идентификатор” и “Предшественники”).
На Рис. 1 приведен интерфейс веб-приложения, в котором отображаются значения атрибутов работ расписания до внесения изменений.
Изменение значения атрибута любой из отображаемых работ приводит к формированию POST-запроса к серверу-приложений, в котором передаются три параметра:
-
идентификатор работы;
-
название атрибута;
-
новое значение атрибута.
На сервере-приложений с использованием класса Activity
формируется расписание. Затем по идентификатору, переданному в POST-запросе, выбирается работа и задается новое значение ее атрибута. После пересчета обновленные значения атрибутов работ расписания возвращаются на клиент и отображаются в интерфейсе пользователя.
На Рис. 2 приведен интерфейс веб-приложения, в котором отображается результат пересчета значений атрибутов работ расписания после изменения даты начала работы с идентификатором “4” (дата начала работы перенесена на “7” единиц в будущее – с “5” на “12”):
-
дата окончания работы перенесена на “7” единиц в будущее (было “7”, стало “14”);
-
установлено ограничение на дату начала работы – начало не ранее “12”, - так как окончание самой поздней работы-предшественника (работы с идентификатором “1”) имеет значение “5”, что меньше нового начала работы с идентификатором “4”;
-
пересчитаны значения атрибутов работ-последователей, в частности, дата начала работы с идентификатором “3” перенесена на “4” единицы в будущее из-за того, что дата окончания самой поздней работы предшественника (с идентификатором “4”) после пересчета приняла значение “14”.
На Рис. 3 приведен интерфейс веб-приложения, в котором отображается результат пересчета значений атрибутов работ расписания после изменения даты окончания работы с идентификатором “4” (дата окончания работы перенесена на “3” единицы в будущее – с “14” на “17”):
-
длительность работы увеличена на “3” единицы - с “2” до “5”;
-
пересчитаны значения атрибутов работ-последователей, в частности, дата начала работы с идентификатором “3” перенесена на “3” единицы в будущее из-за того, что дата окончания самой поздней работы предшественника (с идентификатором “4”) приняла значение “17”.
На Рис. 4 приведен интерфейс веб-приложения, в котором отображается результат пересчета значений атрибутов работ расписания после изменения длительности работы с идентификатором “4” (длительность уменьшена на “4” единицы – с “5” до “1”):
-
дата окончания работы перенесена на “4” единицы в прошлое (было “17”, стало “13”);
-
пересчитаны значения атрибутов работ-последователей, в частности, дата начала работы с идентификатором “3” перенесена на “4” единицы в прошлое из-за того, что дата окончания самой поздней работы предшественника (с идентификатором “4”) приняла значение “13”.
На Рис. 5 приведен интерфейс веб-приложения, в котором отображается результат пересчета значений атрибутов работ расписания после изменения значения атрибута “Начало не ранее” работы с идентификатором “4” (ограничение на дату начала работы устранено):
-
дата начала работы перенесена на “7” единицы в прошлое из-за того, что дата самой поздней работы-предшественника (с идентификатором “1”) равна “5”;
-
дата окончания работы перенесена на “7” единиц в прошлое (было “13”, стало “6”);
-
пересчитаны значения атрибутов работ-последователей, в частности, дата начала работы с идентификатором “3” перенесена на “3” единицы в прошлое из-за того, что дата окончания самой поздней работы предшественника (с идентификатором “2”) равна “10”.
На Рис. 6 приведен интерфейс веб-приложения, в котором отображается результат пересчета значений атрибутов работ расписания после изменения последователей работы с идентификатором “7” (добавлен новый последователь – работа с идентификатором 9):
- пересчитаны значения атрибутов работ-последователей, в частности, дата начала работы с идентификатором “9” перенесена на “10” единицы в будущее из-за того, что дата окончания самой поздней работы предшественника (с идентификатором “7”) равна “27”.
На основе данных модели строятся отчеты, отражающие качество планирования работ по проекту в течение года:
-
Длительность задач по проекту в течение года;
-
Длительность задач по проекту в течение года в разрезе кварталов.
Заключение
Модуль predict
, разработанный в рамках проекта с открытым исходным кодом, обладает рядом достоинств. Во-первых, он является свободно распространяемым. Во-вторых, функционал модуля максимально упрощен, в нем реализованы наиболее востребованные при управлении проектами функции ИСУП. Во-третьих, исходный код модуля модифицируем, что позволяет разработчикам ИСУП изменять логику расчета расписания проекта под нужды компании. Приглашаю всех желающих ознакомиться с модулем predict
. Надеюсь, он будет полезным при построении автоматизированной информационной системы управления проектами.