Основные принципы оценки по аналогиям

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

Несколько сотен разработчиков представили свои оценки для проекта Triad. Их оценки были разбросаны в диапазоне от 30 до 144 человеко-месяцев, а среднее значение составило 53 человеко-месяца. Стандартное отклонение оценок составило 24, или 46 % от среднего ответа. Нехорошо! Некоторое структурирование процесса принесет существенную пользу.

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

СОВЕТ № 53

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

Давайте рассмотрим эту процедуру на примере Triad.

Шаг 1. Получение подробных данных об итоговом размере, объеме работ и затратах для предыдущего аналогичного проекта

После первого собрания Майк попросил участников проекта Triad собрать более конкретную информацию о размере старой системы и относительном объеме функциональности старой и новой систем. Когда сбор данных был завершен, Майк поинтересовался результатами: «Вы собрали те данные, о которых мы говорили на прошлой неделе?»

«Конечно, Майк, — ответила Дженнифер.

У нас также имеется общая информация об общем количестве элементов в ка-

Мы постарались определить аналогичные показатели для новой системы.

«Между большинством подсистем старого и нового проектов существует прямое соответствие, но с бизнес-логикой возникли проблемы, — сказала Дженнифер.

«Отличная работа, — сказал Майк. — Теперь у меня есть все необходимое для вычисления оценки к собранию. Завтра я немного повожусь с цифрами и покажу вам результат перед собранием».

Шаг 2. Сравнение размера нового проекта с аналогичным прошлым проектом

Подробная информация о предыдущем проекте дает нам все необходимое для создания содержательной оценки методом аналогии. Группа Triad уже выполнила шаг 1, «Получение подробных данных об итоговом размере, объеме работ и затратах для предыдущего аналогичного проекта». Далее собранные данные шаг за шагом сравниваются с соответствующими показателями нового проекта. Результаты сравнения показаны в табл. 11.1.

Таблица 11.1. Сравнение размеров подсистем между AccSellerator 1.0 и Triad 1.0

Записать данные в столбцах 2 и 3 несложно — проблема'в том, что делать с множителем в столбце 4. Основной принцип вам уже знаком: сначала подсчет, затем вычисления и в последнюю очередь субъективная оценка.

С множителями 1,4 для базы данных, 1,4 для пользовательского интерфейса и 1,0 для библиотеки классов вроде бы все понятно.

С множителем 1,7 для диаграмм и отчетов дело обстоит сложнее. Должны ли мы присвоить диаграммам тот же весовой коэффициент, что и отчетам? Возможно, диаграммы требуют больше работы, чем отчеты, и наоборот. Если бы кодовая база AccSellerator 1.0 была доступна, мы могли бы свериться с ней и определить, присвоить ли диаграммам и отчетам одинаковые или разные весовые коэффициенты. В данном примере мы будем полагать, что веса одинаковы. Это допущение следует документировать, чтобы позднее при необходимости процедуру оценки можно было бы воссоздать.

Бизнес-логика также порождает проблемы. Группа не нашла никакого показателя, поэтому наша оценка в этой области покоится на более шатком основании, чем в других областях. Для определенности мы согласимся с оценкой, что бизнес-логика Triad будет примерно на 50 % сложнее бизнес-логики AccSellerator.

Шаг 3. Построение оценки размера нового проекта в процентах от размера старого проекта

На шаге 3 метрики размеров из разных областей приводятся к общей единице измерения — в нашем случае это строки программного кода. Преобразование позволит выполнить общесистемное сравнение размеров между AccSellerator и Triad. Таблица 11.2 показывает, как это происходит.

Размеры подсистем AccSellerator в строках кода были получены по данным, собранным на шаге 1. Множители определились в ходе шага 2. Оцениваемый размер подсистемы Triad попросту равен произведению размера подсистемы в AccSellerator и множителя. Общий размер системы в строках кода становится основой для вычисления оценки объема работ, которая, в свою очередь, станет основой для оценок сроков и затрат.

Таблица 11.2. Вычисление предполагаемого размера Triad 1.0 на основании размера AccSellerator

Шаг 4. Создание оценки объема работ на основе размера нового проекта, полученного сравнением с размером предыдущего проекта

Теперь мы располагаем достаточной информацией для вычисления оценки объема работ. Это делается так, как показано в табл. 11.3.

Таблица 11.3. Итоговое вычисление объема работ для Triad 1.0 Показатель              Значение

Размер Triad 1.0              62 ООО строк кода

Размер AccSellerator 1.0              ~43 500 строк кода

Соотношение размеров              = 1,45

Объем работ для AccSellerator 1.0              х 30 человеко-месяцев

Оценка объема работ для Triad 1.0              =44 человеко-месяца

Разделив размер проекта Triad на размер AdccSellerator, мы получаем соотношение размеров двух систем. Умножение его на объем работ AccSellerator дает оценку для Triad — 44 человеко-месяца.

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

Я предложил оценщикам, создавшим исходные оценки для Triad, воспользоваться этой процедурой, и их результаты стали более точными и согласованными. Стандартное отклонение результатов составило всего 7 % вместо 46 %, даже с учетом неопределенности, связанной с диаграммами, отчетами и бизнес-логикой.

Шаг 5. Проверка согласованности предположений между старым и новым проектами

Проверяйте свои предположения на каждом шаге. Впрочем, полноценная проверка некоторых предположений становится возможной только после завершения оценки. Далее перечислены основные источники рассогласования. Существенно различающиеся размеры старого и нового проектов, то есть различия более чем в 3 раза (см. раздел 5.1). В нашем случае размеры отличаются всего в 1,45 раза; этого недостаточно, чтобы беспокоиться об издержках масштаба. Разные технологии (например, один проект написан на С#, а другой на Java). Существенные различия в квалификации отдельных участников (в малых проектах) или целых групп (в больших проектах). Небольшие различия вполне допустимы, а часто неизбежны. Существенные различия в типе программы. Например, если старая система была внутренним интрасетевым проектом, а новая представляет собой критическую встроенную систему, сравнивать их было бы некорректно.