На начальном этапе подготавливаются оценки работы, предлагаемой в проекте (общее описание процедуры оценки проекта программного обеспечения можно найти в разделах [BOE81], [PUT92] и [MCO96]). Поскольку оценка проекта программного обеспечения основывается на сложных математических вычислениях, мы не приводим здесь подробное техническое описание. Процесс оценки состоит из следующих этапов:

1. Оценка размера продукта.
2. Оценка общих трудозатрат и стоимости проекта.
3. Применение ограничений и расстановка приоритетов (например, число сотрудников, дата завершения, бюджет).
4. Выбор оптимального расписания, объема трудозатрат и стоимости.

Оценка размера продукта

Это один из основных показателей, учитываемых в ходе оценки. Без оценки объема предстоящей работы нельзя составить достоверное расписание проекта. На начальном этапе проекта размер программного продукта можно оценить двумя способами: путем аналогии или с помощью анализа. Впоследствии (на этапе уточнения) можно подготовить более точную оценку на основе подробной структуры работы.

Оценка размера путем аналогии

Оценка рамок проекта путем аналогии предусматривает сравнение нового проекта с уже разработанными продуктами (размер которых известен) из предыдущих проектов. Сравнению подлежат различные характеристики продуктов, такие как число вариантов использования бизнес-процесса, число субъектов, размер/сложность базы данных, а также предварительное число интерактивных и пакетных программ.

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

Оценка размера с помощью анализа

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

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

Оценка общих трудозатрат и стоимости

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

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

Применение ограничений и расстановка приоритетов

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

Выбор оптимального расписания, оценка трудозатрат и стоимости

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

В первую очередь в плане разработки программного обеспечения указываются даты и типы основных вех проекта (см. раздел Этапы). Эта часть плана разработки программного обеспечения представляет собой схему основных вех и создается на начальном этапе проекта.

Для планирования этапов проекта в начальном цикле разработки может потребоваться сделать обоснованные предположения относительно вех, принимая во внимание следующие данные:

• Опыт работы с аналогичными проектами.
• Степень новизны.
• Конкретные ограничения среды, такие как время ответа, распределение и безопасность.
• Зрелость организации.

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

Дополнительная информация о выборе продолжительности и числа итераций приведена в разделе Рекомендации: План разработки программного обеспечения.

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

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

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

В результате каждой итерации выпускается исполняемый конечный продукт, применяемый для оценки состояния выполнения и уровня качества. Поскольку, перед итерациями ставятся разные задачи, функциональность и завершенность конечных продуктов может меняться. Цели итераций должны быть сформулированы достаточно точно, чтобы в конце итерации можно быть проверить их выполнение. На более ранних итерациях цели, как правило, выражаются с точки зрения уменьшения рисков; на более поздних - с учетом функциональной завершенности и уровня качества.

По завершении начального этапа вы сможете уточнить план остальных этапов, принимая во внимание следующую информацию:

• Число вариантов использования.
• Сложность изученных вариантов использования.
• Технические и бизнес-риски.
• Функциональные точки или показатели вариантов использования.
• Результаты определения прототипов.

Полученный предварительный план будет обновлен в ходе этапа уточнения. На его основе создается подробный план проекта.

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

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

Процесс закрытия проекта начинается в случае выполнения следующих условий:

• Все конечные продукты завершены и сохранены в системе управления конфигурацией
• Тестирование приемлемости успешно выполнено и продукт официально принят заказчиком
• Продукт официально передан заказчику

Определение задач закрытия

В первую очередь в плане следует указать задачи, подлежащие выполнению в ходе закрытия проекта. Как правило, в число таких задач входят следующие:

• Заключительное обсуждение проекта.
• Разработка окончательного отчета о выполнении проекта.
• Завершение внутренних проверок проекта.
• Архивирование рабочих продуктов проекта.
• Перераспределение сотрудников проекта.
• Добавление показателей проекта в базу данных показателей организации для оценки новых проектов.

Определение участников задач закрытия.

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

Определение расписания задач закрытия

Составьте расписание выполнения задач закрытия. Как правило, эта информация добавляется в план разработки программного обеспечения в конце проекта.