🗊Презентация Базовое расписание проекта работ

Базовое расписание проекта После определения трудоемкости работ необходимо определить график их выполнения и общие сроки реализации проекта — составить расписание работ по проекту. Базовое расписание — утвержденный план-график с указанными временными фазами проекта, контрольными точками и элементами иерархической структуры работ.

Базовое расписание это, как правило, элемент контракта с заказчиком. Контрольные точки (вехи) должны служить точками анализа состояния проекта и принятия решения «GO/NOT GO», поэтому они должны зримо демонстрировать статус проекта. Контрольная точка «Проектирование завершено» — плохо. Наиболее эффективный подход — метод последовательных поставок: контрольная точка «Завершено тестирование требований 1, 3, 5, 7» Базовое расписание это, как правило, элемент контракта с заказчиком. Контрольные точки (вехи) должны служить точками анализа состояния проекта и принятия решения «GO/NOT GO», поэтому они должны зримо демонстрировать статус проекта. Контрольная точка «Проектирование завершено» — плохо. Наиболее эффективный подход — метод последовательных поставок: контрольная точка «Завершено тестирование требований 1, 3, 5, 7»

Если работы не связаны между собой, то любую из них мы можем начинать и завершать, когда нам удобно. Все работы можно делать параллельно и в этом случае минимальная длительность проекта равна длительности самой долгой работы. Однако, на практике между работами существуют зависимости, которые могут быть «жесткими», например, анализ — проектирование — кодирование — тестирование и документирование конкретной функции; или «нежесткими», которые могут пересматриваться или смягчаться. Например, последовательное выполнение задач конкретным исполнителем (можно перепланировать на другого исполнителя) или разработка базового ПО, которая должна предшествовать разработке прикладного ПО. В этом случае можно создавать «заглушки» эмулирующие работу базового ПО. Если работы не связаны между собой, то любую из них мы можем начинать и завершать, когда нам удобно. Все работы можно делать параллельно и в этом случае минимальная длительность проекта равна длительности самой долгой работы. Однако, на практике между работами существуют зависимости, которые могут быть «жесткими», например, анализ — проектирование — кодирование — тестирование и документирование конкретной функции; или «нежесткими», которые могут пересматриваться или смягчаться. Например, последовательное выполнение задач конкретным исполнителем (можно перепланировать на другого исполнителя) или разработка базового ПО, которая должна предшествовать разработке прикладного ПО. В этом случае можно создавать «заглушки» эмулирующие работу базового ПО.

Критический путь проекта Критический путь проекта (Critical path) — самая длинная цепочка работ в проекте. Увеличение длительности любой работы в этой цепочки приводит к увеличению длительности всего проекта. В проекте всегда существует хотя бы один критический путь, но их может быть несколько. Критический путь может меняться во время исполнения проекта. При исполнении проекта руководитель должен обращать внимание на исполнение задач на критическом пути в первую очередь и следить за появлением других критических путей. Практическая рекомендация: на критическом пути должны стоять работы с нежесткими связями, которые всегда можно перепланировать, если возникает угроза срыва сроков.

Чтобы проиллюстрировать понятие критического пути рассмотрим пример «суперпроекта». Концепция проекта выглядит следующим образом. Чтобы проиллюстрировать понятие критического пути рассмотрим пример «суперпроекта». Концепция проекта выглядит следующим образом. Цель проекта. Сделать завтрак в постель Результаты проекта. Завтрак в постели из вареного яйца, тоста и апельсинового сока. Ресурсы. Имеется один оператор и обычное кухонное оборудование. Сроки. Проект начинается на кухне в 8:00 и завершается в спальне. Критерий приемки. Используются минимальные трудовые ресурсы и срок. Конечный продукт имеет высокое качество: яйцо свежесваренное, тост теплый, сок холодный. Обоснование полезности. Проект служит достижению стратегических целей. Иерархическая структура работ, ориентированная на конечный продукт, с оценкой их длительности представлена на Рисунке

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

В результате мы определили, что минимальный срок реализации нашего проекта составляет 10 минут. Однако мы не можем на этом остановиться, поскольку должны еще учесть ограничение по ресурсам. У нас только один оператор. Если мы посмотрим на диаграмму загруженности ресурсов (Рисунок 20), то увидим, что наш критический ресурс загружен на первой минуте на 400%. что недопустимо. В результате мы определили, что минимальный срок реализации нашего проекта составляет 10 минут. Однако мы не можем на этом остановиться, поскольку должны еще учесть ограничение по ресурсам. У нас только один оператор. Если мы посмотрим на диаграмму загруженности ресурсов (Рисунок 20), то увидим, что наш критический ресурс загружен на первой минуте на 400%. что недопустимо. Следовательно, мы должны выполнить выравнивание ресурсов. Поскольку одним из критериев успеха проекта является его минимальная длительность, то если мы не хотим ее увеличивать, мы должны выявить критический путь в проекте и не сдвигать работы, которые на нем находятся.

Поэтому, после выравнивания ресурсов, расписание нашего проекта будет выглядеть следующим образом

Выводы На верхнем уровне ИСР должны находиться не процессы, а продукты проекта, на следующем уровне — компоненты из которых эти продукты состоят. Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое мы должны выполнить на фазе планирования проекта, не дожидаясь проработки всех функциональных требований к разрабатываемому ПО. В проекте всегда существует хотя бы один критический путь, но их может быть несколько. Критический путь может меняться во время исполнения проекта. При исполнении проекта руководитель должен обращать внимание на исполнение задач на критическом пути в первую очередь и следить за появлением других критических путей.