Д. А. Градусов а. В. Шутов теоретические вопросы разработки программного обеспечения учебное пособие
Таблица 5.1 - Ошибка оценки в ключевых точках работы
жүктеу/скачать 2,75 Mb. Pdf көрінісі
|
- Бұл бет үшін навигация:
- Конус неопределенности для итеративного проекта
| Таблица 5.1 - Ошибка оценки в ключевых точках работы
над проектом Фаза Ошибка Возможная ошибка в меньшую сторону Возможная ошибка в большую сторону Диапазон Исходная концепция 0,25х (-75%) 4,0х (+300%) 16х Согласованное определение продукта 0,50х (-50%) 2,0х (+100%) 4х Завершение проектирования пользовательского интерфейса 0,67х (-33%) 1,5х (+50%) 2,25х Завершение детального проектирования 0,90х (-10%) 1,10х (+10%) 1,2х При использовании оценок из этой таблицы необходимо понимать, что в момент создания оценки мы еще не знаем, в какую сторону окажется смещенным фактический результат проекта – к началу или к концу диапазона. Второй способ основан на отделении «оценки того, что мы знаем» от «оценки неопределенности». Один специалист дает оценки наилучшего и наихудшего случая – то есть концов диапазона, а другой оценивает вероятность того, что фактический результат войдет в этот диапазон. 107 Конус неопределенности для итеративного проекта Учесть воздействие конуса неопределенности в итеративных проектах несколько сложнее, чем при традиционном последовательном подходе: если проект на каждой итерации проходит полный цикл разработки (от постановки требований до выхода готовой версии), то на каждой итерации возникает свой миниатюрный конус неопределенности. Перед постановкой требований для текущей итерации проект находится в точке согласованного определения продукта и подвержен 4-кратной амплитуде неопределенности в оценках. При коротких итерациях (меньше месяца) переход от согласованного определения проекта к фазам определения требований и завершения проектирования пользовательского интерфейса происходит за несколько дней, а неопределенность снижается с 4х до 1,6х. При фиксированном графике неопределенность 1,6х будет относиться к функциональности, готовой в отведенное время, а не к объему работ или срокам. С другой стороны, при выборе подходов, при которых требования остаются неопределенными до начала каждой итерации, утрачивается возможность долгосрочного прогнозирования комбинаций затрат, сроков и функциональности, то есть их прогнозирование на несколько итераций спустя. Многие группы разработчиков выбирают промежуточные методики, когда большинство требований определяется в начальной стадии работы над проектом, а проектирование, конструирование, тестирование и выпуск производятся короткими итерациями. Другими словами, проект движется последовательно до точки завершения проектирования пользовательского интерфейса (около 30% календарного времени), а затем переходит на более итеративный путь. Неопределенность, обусловленная воздействием конуса, снижается до 25%; это позволяет добиться поставленных целей при 108 качественном управлении проектом, не утрачивая основных преимуществ итеративной разработки. Промежуточный подход обеспечивает долгосрочную прогнозируемость затрат и сроков в сочетании с умеренной гибкостью в требованиях. 5.3 Факторы, влияющие на оценку Факторы, оказывающие влияние на программный продукт, следует тщательно проанализировать, поскольку хорошее их знание повышает точность оценки и улучшает понимание общей динамики программного проекта. жүктеу/скачать 2,75 Mb. Достарыңызбен бөлісу:
|