Метод анализа и оценки PERT

Параллельно с разработкой CPM, в военно-морских силах США был создан (фирма "Буз, Аллен & Гамильтон") метод анализа и оценки программ PERT (Program Evaluation and Review Technique) для реализации проекта разработки ракетной системы "Polaris", объединяющей около 3800 подрядчиков с числом операций более 60 тыс. [6].

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

Метод PERT представляется сетевыми диаграммами с вершинами-событиями, а работа – в виде линии между двумя событиями, отображающими начало и конец данной работы. В целом расхождения между этими двумя методами сетевого представления графа работ являются незначительными. Однако этот метод, в отличие от CMP, учитывает возникающие неопределенности во времени выполнения каждой операции.

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

В этом методе возможное время выполнения операций оценивается с помощью трех оценок:

– оптимистичной (О),

– пессимистической (P),

– вероятностной (B).

А далее вычисляется по формуле: (О+4В+П)/6, c указанием его на сетевом графике.

Для уменьшения провалов проектов используются и другие аналитические методы и усовершенствованные языки разработки систем. Как показывает опыт, "продвинутые" технологии решают вопросы успешного создания проекта с учетом факторов, которые уменьшают его провал [3]:

1. Проект начинать с правильного шага.

2. Поддержка темпа работы.

3. Обеспечение прогресса и правильных решений.

4. Посмертный анализ завершенного проекта.

1). Проект начинать с правильного шага. К правильному шагу относится формирование команды разработчиков из хороших специалистов, в том числе не более 20% звезд, наиболее приспособленных для хорошей работы над проектом (много звезд - создание конфликтов). В команду входят надежные разработчики с совместимыми характерами и рабочими привычками. Звезды решают сложные вопросы, разрабатывают более ответственные алгоритмы и проводят техническое обучение остальных членов команды. Для уточнения всех особенностей проекта разработчики садятся за стол переговоров с заказчиком и составляют взаимно приемлемый документ.

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

2). Поддержка темпа работысостоит в:

– уменьшении текучести кадров;

– контроле качества выполняемых работ;

– управлении процессом разработки, а не людьми.

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

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

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

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

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

Планирование проекта

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

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

Планирование в том или ином виде выполняется в течение всего срока реализации проекта. В начале ЖЦ проекта обычно разрабатывается неофициальный первоначальный план - грубое представление о том, что потребуется выполнить в случае реализации проекта. Решение о выборе проекта в значительной мере базируется на оценках этого первоначального плана. Формальное и детальное планирование проекта начинается после принятия решения о его реализации.

Планирование заключается в составлении следующих планов:

– работ со сроками их выполнения по методу критического пути СРМ или PERT;

– достижения требуемого качества методами проверки промежуточных результатов процессов ЖЦ;

– управление рисками,

– аттестации результатов проектирования и деятельности исполнителей проекта,

– управление конфигурацией и др.

Составляется график работ по следующей схеме (рис.10.2):

Определение Связь Оценка Распределение Определение

этапов между ресурсов персонала графика

этапами для этапа по этапам

Требования График

к проекту

Рис.10.2. Шаги составления графика работ на проекте

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

На этапе планирования могут использоваться также сетевая разбивка работ (СРР) и диаграммы Ганта [7].

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

– структуризацию работ на основные компоненты и подкомпоненты,

– определить направления деятельности для достижения комплекса целей,

– распределить ответственных за выполнение отдельных работ на проектеа,

– получить отчетность и обобщение информации по проекту.

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

Диаграмма Ганта - горизонтальная линейная диаграмма, на которой задачи проекта представляются сроками в виде отрезков времени и имеют даты начала и окончания, возможно с задержками и другими временными параметрами.

План в виде графа СРР имеет фазы, шаги и деятельности, а также начало и конечную деятельность на процессе (рис.10.3).

Фаза 1 Шаг 1 Деятельность 1.1