Планирование проекта на основе требований, путь RUP

RUP поддерживает двухуровневую схему планирования работ над проектом, разделяя план проекта и план итерации. Исходя из базовой концепции планирования итерационных проектов, план проекта разбивается на фазы:

• Начало,
• Уточнение,
• Конструирование,
• Переход.

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

Назначаются даты главных вех (окончания фаз):

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

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

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

Что это означает на практике:

1. укрупненный план работ составляется "как можно раньше", например - через месяц после начала работ;
2. бюджет появляется лишь к окончанию первой фазы (а она, в зависимости от сложности проекта может длиться месяц, а может и полгода);
3. как план, так и бюджет проекта представляют собой лишь прогноз, который может корректироваться на протяжении работ над проектом;
4. на момент появления плана и бюджета должно появиться подробное описание лишь 20% ключевой функциональности системы и "широкое, но неглубокое" [15.2] описание 80% функциональности.

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

Более конкретная информация представлена в плане итерации. Основные его особенности:

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

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

1. План итерации имеет жесткие сроки. В случае проявления незапланированных рисков удовлетворительным вариантом является достижение договоренности о реализации требований данной итерации не в полном объеме, либо переносе требований в следующую итерацию; переносить сроки текущей итерации не рекомендуется;
2. Точный план составляется на одну, очередную итерацию. К моменту окончания текущей итерации должен быть сверстан план очередной итерации. Такой подход позволяет более гибко работать с рисками.

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

Дата добавления: 2014-11-29