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

Такая постановка вопроса вполне логична и обоснована, это подтвердит любой Разработчик. Однако, она вызывает много вопросов, например:

• Где найти Заказчика, который согласится ждать 2-3 месяца, пока Разработчик составит для него коммерческое предложение?
• Кто оплатит работы по анализу требований? (очевидно, Заказчик)
• Как быть, если цена вопроса окажется непомерной и от проекта придется отказаться - кто возместит Заказчику убытки на проведение исследований?

Разумный Заказчик сможет найти выход из этого непростого положения, например:

• подыскав Разработчика, обладающего богатым опытом выполнения подобных проектов, который сможет дать требуемую оценку значительно быстрее (но риск ошибки при этом остается);
• взяв на себя риски возможного прекращения проекта на ранних стадиях, в случае, если выявится его несоответствие бюджетным ограничениям (в сложных рискованных проектах лучше потерять 5% или 10% от закладываемого бюджета, чем все 100%, как это было в "каскадных" схемах разработки) - путь прогнозирующих методологий
• разделив с Разработчиком ответственность за конечный продукт, приготовившись день за днем работать с ним рука об руку вплоть до появления результата - путь гибких (Agile) методологий.

От рамок проекта к экспресс-планированию

Начальную, самую грубую оценку проекта можно сделать на основании документа "Видение". Так, шаблон Vision/Scope MSF содержит список ключевых характеристик/функций, критерии приемлемости и (что очень важно) перечень характеристик/функций, которые лежат "вне рамок" проекта. Параллельно с проработкой концепции, первая фаза MSF содержит работы по анализу рисков: выявляются и оцениваются главные риски проекта.

Чтобы сделать первое приближение плана и сметы проекта на ранних этапах анализа, в [15.1] предлагается следующий подход:

• Выделить 25 - 99 функций, характеризующих систему (совместно, Заказчик и Разработчик);
• Установить приоритеты для каждой из функций (Заказчик);
• Оценить трудозатраты (Разработчик);
• Оценить риски (Разработчик, возможно привлечение Заказчика);

Все оценки делаются по 3-балльной шкале (высокий, низкий, средний; критический, важный, полезный и т.п.) и сводятся в таблицу:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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