Структура графика работ программного проекта

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

Планирующие утилиты позволяют:

· определить критический путь (цепочку задач, задающих длительность всего проекта);

· определить длительность критического пути;

· установить для каждой задачи наиболее вероятную временную оценку (по прикладной статистической модели);

· вычислить границы, определяющие временное окно для отдельной задачи.

Результат работы такой утилиты представляется в виде сетевой диаграммы. Типовая сетевая диаграмма приведена на рис. 2.3. Она создается на основе иерар хической структуры распределения работ, называемой WBS — Work Breakdown Structure.

Первыми выполняемыми задачами являются сбор требований и анализ требований. Они закладывают фундамент для последующих параллельных задач.

Сбор требований проводится с целью:

1) выяснения потребностей заказчика;

2) оценки выполнимости программной системы;

3) выполнения экономического и технического анализа;

4) определения стоимости и ограничений планирования;

5) создания системной спецификации.

В системной спецификации описываются функции, характеристики программной системы, ограничения разработки, входная и выходная информация.

Рис. 2.3. Типовая сетевая диаграмма работ проекта

Анализ требований дает возможность:

1) уточнить функции и характеристики программного продукта;

2) обозначить интерфейс продукта с другими системными элементами;

3) определить проектные ограничения программного продукта;

4) построить модели: процесса, данных, режимов функционирования продукта;

5) создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.

Результаты анализа сводятся в спецификацию анализа, содержащую конкретизированные требования к программному продукту.

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

Далее проводится тестирование правильности, которое обеспечивает проверку соответствия ПО требованиям заказчика.

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

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

Основной рычаг в планирующих методах — вычисление границ времени выполнения задачи.

Обычно используют следующие оценки:

1. Раннее время начала решения задачи (при условии, что все предыдущие задачи решены в кратчайшее время).

2. Позднее время начала решения задачи (еще не вызывает общую задержку проекта).

3. Раннее время конца решения задачи

.

4. Позднее время конца решения задачи m

.

5. Общий резерв — количество избытков и потерь планирования задач во времени, не приводящих к увеличению длительности критического пути T_кп.

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

Рекомендуемое правило распределения затрат проекта — 40–20–40:

· на анализ и проектирование приходится 40% затрат (из них на планирование и сбор требований — 5%);

· на кодирование — 20%;

· на тестирование и отладку — 40%.

Данное правило отражает накопленный мировой опыт индустрии программной инженерии и базируется на следующих фактах:

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

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

· Трудоемкость третьего сегмента — тестирования и отладки — тоже очень велика. Это обусловлено доминирующим стилем человеческой деятельности: «методом проб и ошибок». Никого не удивляет, что человек, выполняя работу, часто ошибается. На поиск и устранение ошибок (а это цель данных действий) тратится много усилий.

Дата добавления: 2015-07-07