Software Estimation

О себе

КО

Зачем?

Давайте на чистоту

“Estimation is not Exactimation!”
S. McConnell

Проблемы оценок:
Погрешность
Разные люди
Предубеждение
Вариация
производительности
Риски
Очень мало времени на оценку

А есть ли выход?

Оцениваем непрерывно Ретроспектива

Как оценивать?

Уменьшаем неопределённость

Ищем, что посчитать
Количество бизнес-процессов
Количество строк кода
Количество входов-выходов
Количество ХП
Количество подсистем
Количество модулей

Если считать нечего, то см. методы
«Локтём по карте»
и
«Вилами по воде»

Этапы оценки

1 этап
Знаем «о чём»

Методы на 1-ом этапе
«Локтём по карте»
Метод аналогий

2 этап
Знаем, «что»

Методы на 2-ом этапе
Экспертные оценки
WBS
Use Case Points
Формула Боэма
Классификация
Story Points
Planning Poker
Wideband Delphi

3 этап
Знаем, «как»

Методы на 3-ем этапе
WBS
PERT
CLOC
Functional Points

4 этап
Знаем, «что получилось»

Методы на 4-ом этапе
Ретроспектива

Примеры

Исходные данные
Чужой незнакомый код на Power Builder
Ограниченная экспертиза в Power Builder

Требуется
Оценить миграцию кода на Java
Минимизировать затраты на оценку

Что можем посчитать
Количество файлов
Объём кода в Мб
Количество ХП
Количество пунктов меню (вариантов использования)
Количество экранных форм
Количество печатных форм

Что можем вычислить
Оценить среднее соотношение строк кода и объёма файлов (файлы содержат ещё и ресурсы)

Что можем позаимствовать
Статистику перевода строк кода Power Builder в Java

Как можем уточнить
Анализ наиболее рискованных вариантов использования (экспертный анализ)

Что оцениваем
Аналитика
Разработка
Тестирование
Управление

Вводим поправки
Ищем повторяющиеся действия – сокращаем оценки
Не забываем про фреймворк – базовая архитектура

Исходные данные
Длительность предыдущей фазы: 15 мес.
Количество старых требований: 502
Команда уменьшилась в 2 раза
Количество новых требований: 250
Время на оценку – 2 дня
Задача – определить стоимость всех работ

Грубая интегральная оценка
1 требование разрабатывалось:
15 мес. / 502 треб. = 0,62 дня
1 требование новой командой:
0,62 дня * 2 = 1,24 дня
Новый scope:
1,24 дня * 250 = 308 дней ~ 15 мес.

Грубая интегральная оценка
Корректировка на проблемы внедрения (эмпирически)
308 дней * 1,2 = 370 дней ~ 17,5 мес.
Общая трудоёмкость:
17,5 мес * 54 чел = 945 чел*мес

Уточнение оценки
На самом деле детализация требований изменилась
На сколько?

Ранжирование требований

Уточнённая оценка
250 новых требования соответствуют 74-ём старым требованиям
945 чел*мес * (74 / 250) = 280 чел*мес

Описание результата
Без технического и функционального анализа задач
Без учёта проектных факторов (команда, баги, регрессии)
Без учёта внепроектных факторов (болезни, отпуска и пр.)
Только на основе предыдущего опыта!
Но закон больших чисел на нашей стороне. ☺

Повышение атомарности задач
Предыдущий этап:
Не позволял манипулировать задачами
Не учитывал специфику «несредних задач»
Был слишком непрозрачен для Заказчика

Оценка индивидуальных задач
Разбиваем на аналитику, разработку, тестирование
Ранжируем на уровни сложности:
элементарный
лёгкий
средний
тяжёлый
очень тяжёлый

Оценка индивидуальных задач
* То же для аналитики и тестирования

Оценка задач

Индивидуальный анализ
Индивидуальное ревью оценок на предмет явно завышенных или заниженных оценок

Результаты
Проведена обоснованная оценка
Применена комбинация методов
Точность попадания по ряду задач 10-20 %

Вопросы
Какие методы были применены в примере?
Какие недостатки у методов?
Какие преимущества у методов?