Реферат: Руководство программным проектом

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

4. распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.);

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

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

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

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

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

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

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

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

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

Рис. 2.2. Типовая структура распределения проектных работ

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

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

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

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

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

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

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

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

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

T^out _min = Tⁱⁿ _min + T_реш

4. Позднее время конца решения задачи T^out _max

T^out _max = Tⁱⁿ _max + T_реш .

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

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

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

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