Понравилась презентация – покажи это...
Слайд 0
Software Estimation
Слайд 1
О себе
Слайд 2
КО
Слайд 3
Зачем?
Слайд 4
Давайте на чистоту
Слайд 5
Слайд 6
Слайд 7
Слайд 8
Слайд 9
“Estimation is not Exactimation!” S. McConnell
Слайд 10
Слайд 11
Проблемы оценок:
Погрешность
Разные люди
Предубеждение
Вариация производительности
Риски
Очень мало времени на оценку
Слайд 12
А есть ли выход?
Слайд 13
Оцениваем непрерывно Ретроспектива
Слайд 14
Как оценивать?
Слайд 15
Уменьшаем неопределённость
Слайд 16
Слайд 17
Ищем, что посчитать
Количество бизнес-процессов
Количество строк кода
Количество входов-выходов
Количество ХП
Количество подсистем
Количество модулей
Слайд 18
Если считать нечего, то см. методы «Локтём по карте» и «Вилами по воде»
Слайд 19
Этапы оценки
Слайд 20
1 этап
Знаем «о чём»
Слайд 21
Методы на 1-ом этапе
«Локтём по карте»
Метод аналогий
Слайд 22
2 этап
Знаем, «что»
Слайд 23
Методы на 2-ом этапе
Экспертные оценки
WBS
Use Case Points
Формула Боэма
Классификация
Story Points
Planning Poker
Wideband Delphi
Слайд 24
3 этап
Знаем, «как»
Слайд 25
Методы на 3-ем этапе
WBS
PERT
CLOC
Functional Points
Слайд 26
4 этап
Знаем, «что получилось»
Слайд 27
Методы на 4-ом этапе
Ретроспектива
Слайд 28
Примеры
Слайд 29
Слайд 30
Исходные данные
Чужой незнакомый код на Power Builder
Ограниченная экспертиза в Power Builder
Слайд 31
Требуется
Оценить миграцию кода на Java
Минимизировать затраты на оценку
Слайд 32
Что можем посчитать
Количество файлов
Объём кода в Мб
Количество ХП
Количество пунктов меню (вариантов использования)
Количество экранных форм
Количество печатных форм
Слайд 33
Что можем вычислить
Оценить среднее соотношение строк кода и объёма файлов (файлы содержат ещё и ресурсы)
Слайд 34
Что можем позаимствовать
Статистику перевода строк кода Power Builder в Java
Слайд 35
Как можем уточнить
Анализ наиболее рискованных вариантов использования (экспертный анализ)
Слайд 36
Что оцениваем
Аналитика
Разработка
Тестирование
Управление
Слайд 37
Вводим поправки
Ищем повторяющиеся действия – сокращаем оценки
Не забываем про фреймворк – базовая архитектура
Слайд 38
Слайд 39
Исходные данные
Длительность предыдущей фазы: 15 мес.
Количество старых требований: 502
Команда уменьшилась в 2 раза
Количество новых требований: 250
Время на оценку – 2 дня
Задача – определить стоимость всех работ
Слайд 40
Грубая интегральная оценка
1 требование разрабатывалось: 15 мес. / 502 треб. = 0,62 дня
1 требование новой командой:
0,62 дня * 2 = 1,24 дня
Новый scope:
1,24 дня * 250 = 308 дней ~ 15 мес.
Слайд 41
Грубая интегральная оценка
Корректировка на проблемы внедрения (эмпирически)
308 дней * 1,2 = 370 дней ~ 17,5 мес.
Общая трудоёмкость:
17,5 мес * 54 чел = 945 чел*мес
Слайд 42
Уточнение оценки
На самом деле детализация требований изменилась
На сколько?
Слайд 43
Ранжирование требований
Слайд 44
Уточнённая оценка
250 новых требования соответствуют 74-ём старым требованиям
945 чел*мес * (74 / 250) = 280 чел*мес
Слайд 45
Описание результата
Без технического и функционального анализа задач
Без учёта проектных факторов (команда, баги, регрессии)
Без учёта внепроектных факторов (болезни, отпуска и пр.)
Только на основе предыдущего опыта!
Но закон больших чисел на нашей стороне. ?
Слайд 46
Повышение атомарности задач
Предыдущий этап:
Не позволял манипулировать задачами
Не учитывал специфику «несредних задач»
Был слишком непрозрачен для Заказчика
Слайд 47
Оценка индивидуальных задач
Разбиваем на аналитику, разработку, тестирование
Ранжируем на уровни сложности:
элементарный
лёгкий
средний
тяжёлый
очень тяжёлый
Слайд 48
Оценка индивидуальных задач
* То же для аналитики и тестирования
Слайд 49
Оценка задач
Слайд 50
Индивидуальный анализ
Индивидуальное ревью оценок на предмет явно завышенных или заниженных оценок
Слайд 51
Результаты
Проведена обоснованная оценка
Применена комбинация методов
Точность попадания по ряду задач 10-20 %
Слайд 52
Вопросы
Какие методы были применены в примере?
Какие недостатки у методов?
Какие преимущества у методов?
Слайд 53
Заключение
