ПО_УП / Практические занятия / Составление расписания Л3

Техника составления расписания Часть 3

Разработка компьютерной модели проекта - дополнительные возможности

Введение

• Некоторые возможности из описанных далее - это последующие шаги разработки компьютерной модели, другие - возвращение к тем шагам, которые были рассмотрены, но уже на другом уровне.

Множественные ИСР

•Мы уже упоминали, что ИСР проекта не определяется однозначно - можно исходить из объектов проекта, из процессов, из ответственности, из географии и т.д.

•Крайне полезно иметь возможность взглянуть на проект с различных точек зрения и использовать для этого дополнительные Иерархические Структуры Работ.

•В Spider Project достаточно просто выбрать отображение новой структуры и задать ее графически.

•Использование дополнительных структур позволяет – проверить полноту описания проекта в компьютерной модели, – получить возможность получать отчетность в разных разрезах с разными «итого» и соответственно анализировать как план, так и ход реализации проекта.

Иерархические структуры ресурсов

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

•В таких структурах подводятся всевозможные «итого» по ресурсным подразделениям, что позволяет планировать, анализировать и контролировать деятельность организации.

•Принципиальное отличие иерархической структуры ресурсов от иерархической структуры работ - то, что в структуре ресурсов каждый ресурс имеет одного «родителя», в то время как в структуре работ у операции - один «родитель».

Иерархические структуры контрактов

• В такой структуре фазы - это контракты и работа относится к той или иной фазе, если исполняется по соответствующему контракту. Структура определяется отношениями Генподрядчик, субподрядчик и т.д.

Иерархические структуры затрат

• В пакете Spider Project можно завести неограниченное количество составляющих и центров затрат, что может позволить проводить наиболее гибкий стоимостной анализ проекта.

Мультиресурсы

•Мультиресурсы. Использование мультиресурсов - особенность пакета Spider Project. Мультиресурс – это устойчивая группа ресурсов, выполняющая работы вместе (например, бригада, автомобиль с шофером и т.п.).

•Задав мультиресурсы, вы впоследствии можете назначать их на исполнение операций.

•При этом убиваются два зайца:

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

–при необходимости можно изменить состав исполнителей во всем проекте, изменив только состав мультиресурса. Это неоценимо при анализе «что если».

Пулы ресурсов

•Пул ресурсов - это группа взаимозаменяемых ресурсов. У этих ресурсов могут быть разные производительности, но все они способны исполнять некоторые операции.

•Назначая на исполнение операции пул, пользователь указывает либо общее количество, либо общую производительность назначенных ресурсов.

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

•Таким образом, пользователю достаточно задать, какие ресурсы способны исполнять операции, а программа сама составит план.

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

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

Команды ресурсов

•Еще одна особенность пакета Spider Project.

•Команда - это группа ресурсов, работающая вместе на данной операции, но независимо от других команд.

•Если те назначения, которые мы рассматривали до сих пор, подразумевали только совместную работу ресурсов, то команды работают независимо друг от друга.

•Если раньше отсутствие какого-либо ресурса из назначенных тормозило исполнение операции, то в случае назначения независимых команд операция начнет исполняться, если хотя бы одна из назначенных команд способна приступить к работе.

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

•При этом могут задаваться объемы работ и длительности для каждой из команд, либо такой режим работы, что команда не прекратит исполнение, пока операция не будет завершена.

•При этом часть назначенных команд может просто не успеть приступить к работе.

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

Прерываемые операции

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

•Но не все операции допускают прерывание, поэтому в Spider Project задается, допускает ли конкретная операция прерывание своего исполнения или нет.

Другие методы управления расписанием

•Можно ввести пользовательские приоритеты операций, что позволяет откорректировать составленные расписания.

•Пользоваться этой возможностью следует осторожно, потому что такое вмешательство может существенно ухудшить полученные результаты.

•Еще одна возможность, обычно предоставляемая пользователям – ввод директивных дат - ограничений на начало или завершение операций.

•Функция та же, что у приоритетов, но это ограничение более жесткое и вероятность его соблюдения выше.

Оптимизация расписания

•В отличие от составления расписания без учета ограниченности ресурсов проекта, задача составления расписания с учетом ограничений на ресурсы, очень сложна и не имеет точного математического решения. Для одного и того же проекта разные пакеты рассчитают разные расписания, потому что используют разные эвристические алгоритмы.

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

•Однако западные пакеты не утруждают себя поиском оптимума.

•Spider Project остается единственным пакетом, в котором уделяется серьезное внимание оптимизации расписания исполнения проекта.

•Во всяком случае, расписания, составляемые им, как правило короче расписаний, составляемых для тех же проектов западными пакетами при наличии ограниченных ресурсов.

•Можно привести множество примеров не оптимальности расписаний, составляемых западными пакетами.

•На следующем слайде - один такой пример, который для нас будет интересен не только этим.

Устойчивость расписания

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

•Такое изменение чревато катастрофическими последствиями, если проект утвержден и заключены контракты.

•К тому же такие изменения происходят непрерывно в процессе исполнения проекта - что-то исполняется, меняется оставшаяся длительность и т.д.

•Если в процессе исполнения «прыгает» план, это ни к чему хорошему не приводит - летят контракты, не понятно относительно чего измерять исполнение и т.д.

•На следующем слайде вы увидите последствия изменения на один день длительно

сти одной из операций предыдущего примера.

• Расписание стало другим, срок завершения проекта изменился на 16 дней и неважно в какую сторону - начиная с какого-то момента все подобные изменения одинаково плохи.

•Поэтому в Spider Project введена опция - поддержка предыдущего расписания, когда пользователь задает версию проекта с принятым расписанием, а текущее сохраняет порядок исполнения работ, принятый в заданной версии.

•Мы считаем эту функцию очень важной для управления проектами.