Процесс руководства проектом

Принцип руководства иллюстрирует рис. 2.1.

Рис. 2.1. Руководство в процессе конструирования ПО

Начало проекта

Перед планированием проекта следует:

q установить цели и проблемную область проекта;

q обсудить альтернативные решения;

q выявить технические и управленческие ограничения.

Измерения, меры и метрики

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

 

В результате измерения определяется

мера — количественная характеристика какого-либо свойства объекта.

В IEEE Standard Glossary of Software Engineering Terms метрика определена как мера степени обладания свойством, имеющая числовое значение.

В программной инженерии понятия мера и метрика очень часто рассматривают как синонимы.

Процесс оценки

При планировании программного проекта надо оценить

§ людские ресурсы (в человеко-месяцах),

§ продолжительность (в календарных датах),

§ стоимость (в тысячах долларов).

Обычно исходят из прошлого опыта.

Анализ риска

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

В результате принимается решение — выполнять проект или нет.

Планирование

§ Определяется набор проектных задач.

§ Устанавливаются связи между задачами,

§ оценивается сложность каждой задачи.

§ Определяются людские и другие ресурсы.

§ Создается сетевой график задач, проводится его временная разметка.

Трассировка и контроль

Каждая задача, помеченная в плане, отслеживается руководителем проекта.

При отставании в решении задачи применяются утилиты повторного планирования.

В результате повторного планирования:

q М.б. перераспределены ресурсы;

q М.б. реорганизованы задачи;

q М.б. пересмотрены выходные обязательства.

Планирование проектных задач

Основной задачей при планировании является определение WBS — Work Breakdown Structure (структуры распределения работ).

Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рис. 2.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

.

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

.

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

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

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

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

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

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

⇐ Предыдущая123456Следующая ⇒

Поделиться:

Популярное:

1. II. ТЕОРЕТИКО-МЕТОДОЛОГИЧЕСКОЕ ОБОСНОВАНИЕ УЧЕБНО-ВОСПИТАТЕЛЬНОГО ПРОЦЕССА ШКОЛЬНИКОВ.
2. RUP - унифицированный процесс разработки
3. X. Технологические процессы отделочных работ.
4. Автоматизация процесса биологической очистки сточных вод
5. Автоматизация процессов механической очистки сточных вод
6. АВТОМАТИЗАЦИЯ ПРОЦЕССОВ ПОСЛЕУБОРОЧНОЙ ОБРАБОТКИ ЗЕРНА
7. АВТОМАТИЗАЦИЯ ПРОЦЕССОВ ПРОИЗВОДСТВА И ПЕРЕРАБОТКИ КОРМОВ
8. АВТОМАТИЗАЦИЯ ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ
9. Адаптационные процессы, обусловленные тренировкой с отягощениями
10. АЛУ и назначение регистров процессора.
11. Амортизация и ее роль в воспроизводственном процессе
12. Анализ заводского технологического процесса обработки детали