В разработке программного обеспечения, оценка трудозатрат - это процесс прогнозирования наиболее реалистичное количество усилий (выраженное в человеко-часах или деньгах), необходимых для разработки или сопровождения программного обеспечения, на основе неполных, неопределенных и зашумленных данных. Усилия оценки могут использоваться в качестве входных данных для планов проекта, планов итераций, бюджетов, инвестиционного анализа, процессов ценообразования и раундов торгов.
Опубликованные обзоры практики оценки показывают, что экспертная оценка является доминирующей стратегией при оценке усилий при разработке программного обеспечения.
Как правило, оценки усилий чрезмерно оптимистичны и есть сильная чрезмерная уверенность в их точности. Средний перерасход усилий составляет около 30% и не уменьшается со временем. Для обзора обзоров ошибок оценки усилий см. Однако измерение ошибки оценки проблематично, см. Оценка точности оценок. Сильная чрезмерная уверенность в точности оценок усилий иллюстрируется выводом о том, что в среднем, если профессионал в области программного обеспечения на 90% уверен или «почти уверен» в том, что он включит фактические усилия в минимально-максимальный интервал, наблюдаемая частота включения фактические усилия составляют всего 60-70%.
В настоящее время термин «оценка усилий» используется для обозначения различных концепций, таких как наиболее вероятное использование усилий (модальное значение), усилия, которые соответствуют вероятности 50% от непревышения (медиана) запланированных усилий, запланированных усилий или усилий, использованных для предложения предложения или цены клиенту. Считается, что это прискорбно, потому что могут возникнуть проблемы с коммуникацией и потому, что концепции служат разным целям.
Исследователи и практики программного обеспечения занимаются проблемами оценки трудозатрат для проектов разработки программного обеспечения с тех пор, как по крайней мере, 1960-е годы; см., например, работу Фарра и Нельсона.
Большинство исследований было сосредоточено на построении формальных моделей оценки усилий по программному обеспечению. Ранние модели обычно основывались на регрессионном анализе или математически выводились из теорий из других областей. С тех пор было оценено большое количество подходов к построению моделей, таких как подходы, основанные на рассуждениях на основе случаев, классификации и деревьях регрессии, моделировании, нейронные сети, байесовская статистика, лексический анализ спецификаций требований, генетическое программирование, линейное программирование, модели экономического производства, нечеткая логика моделирование, статистическая самонастройка и комбинации двух или более из этих моделей. Пожалуй, наиболее распространенными методами оценки сегодня являются модели параметрической оценки COCOMO, SEER-SEM и SLIM. Они основаны на оценочных исследованиях, проведенных в 1970-х и 1980-х годах, и с тех пор обновляются новыми данными калибровки, причем последним крупным выпуском является COCOMO II в 2000 году. Подходы к оценке основаны на измерениях размера на основе функциональности, например, функциональные точки, также основаны на исследованиях, проведенных в 1970-х и 1980-х годах, но они повторно откалиброваны с использованием модифицированных мер размера и различных подходов к подсчету, таких как точки варианта использования или объектные точки в 1990-е гг.
Есть много способов категоризации подходов к оценке, см. Например. Категории верхнего уровня следующие:
Ниже приведены примеры подходов к оценке в каждой категории.
Подход к оценке | Категория | Примеры поддержки реализации подхода к оценке |
---|---|---|
Оценка на основе аналогии | Формальная модель оценки | ANGEL, Взвешенные микрофункции |
Оценка на основе WBS (снизу вверх) | Экспертная оценка | Программное обеспечение для управления проектами, шаблоны деятельности для конкретной компании |
Параметрические модели | Модель формальной оценки | COCOMO, SLIM, SEER-SEM, |
Модели оценки на основе размера | Модель формальной оценки | Анализ функциональных точек, Анализ вариантов использования, Точки вариантов использования, SSU (единица размера программного обеспечения), Оценка на основе точек истории в Гибкая разработка программного обеспечения, Очки объекта |
Групповая оценка | Экспертная оценка | Планирование покера, Wideband delphi |
Механическая комбинация | Оценка на основе комбинации | Среднее значение на основе аналогии и Структурная декомпозиция работ Оценка усилий на основе |
Оценочная комбинация | Оценка на основе комбинации | Экспертное суждение, основанное на оценках параметрической модели и групповой оценке |
Доказательства различий в точности оценки Различные подходы и модели оценки предполагают, что не существует «наилучшего подхода» и что относительная точность одного подхода или модели по сравнению с другим сильно зависит от контекста. Это означает, что разные организации выигрывают от разных подходов к оценке. Выводы, которые могут поддержать выбор метода оценки, основанного на ожидаемой точности подхода, включают:
Наиболее надежный вывод во многих областях прогнозирования заключается в том, что комбинация оценок из независимых источников, предпочтительно с применением различных подходов, в среднем повысит точность оценки.
Важно знать об ограничениях каждого традиционного метода. подход к измерению производительности разработки программного обеспечения.
Кроме того, другие факторы, такие как простота понимания и передачи результатов подхода, простота использования приложения oach, и стоимость внедрения подхода следует учитывать в процессе отбора.
Наиболее распространенной мерой средней точности оценок является MMRE (средняя величина относительной ошибки), где MRE каждой оценки определяется как:
MRE =
Эта мера подверглась критике, и есть несколько альтернативных показателей, таких как более симметричные показатели, взвешенное среднее квартилей относительных ошибок (WMQ) и среднее отклонение от оценки (MVFE).
MRE не является надежным, если отдельные элементы искажены. PRED (25) предпочтительнее в качестве меры точности оценки. PRED (25) измеряет процент предсказанных значений, которые находятся в пределах 25 процентов от фактического значения.
Высокая ошибка оценки не может автоматически интерпретироваться как индикатор низкой способности оценки. Альтернативные, конкурирующие или дополняющие причины включают в себя низкую стоимость контроля над проектом, высокую сложность разработки и большую функциональность, чем первоначально предполагалось. Структура для улучшенного использования и интерпретации измерения ошибки оценки включена.
Существует множество психологических факторов, потенциально объясняющих сильную тенденцию к чрезмерно оптимистичным оценкам усилий, с которыми необходимо иметь дело. с, чтобы повысить точность оценки усилий. Эти факторы важны даже при использовании формальных моделей оценки, поскольку большая часть входных данных для этих моделей основана на суждениях. Доказана важность следующих факторов: принятие желаемого за действительное, привязка, ошибка планирования и когнитивный диссонанс. Обсуждение этих и других факторов можно найти в работе Йоргенсена и Гримстада.
Хроническая недооценка усилий по разработке привела к появлению и популярности множества юмористических пословиц, таких как ироничное обращение к задаче как к "небольшому вопросу программирования "(когда, вероятно, потребуется много усилий), и цитируя законы о недооценке:
Первые 90 процентов кода составляют первые 90 процентов времени разработки. Оставшиеся 10 процентов кода составляют остальные 90 процентов времени разработки.
— Том Каргилл, Bell LabsЗакон Хофштадтера: это всегда занимает больше времени, чем вы ожидаете, даже если вы принимаете во внимание закон Хофштадтера.
— Дуглас Хофштадтер, Гедель, Эшер, Бах: вечная золотая косаЧто один программист может сделать за один месяц, два программиста можно сделать за два месяца.
— Фред БруксДобавив к тому факту, что оценить усилия по разработке сложно, стоит отметить, что выделение дополнительных ресурсов не всегда помогает.
Программное обеспечение | Оценка графика | Оценка затрат | Модели затрат | Исходные данные | Отчет Формат вывода | Поддерживаемые языки программирования | Платформы | Стоимость | Лицензия |
---|---|---|---|---|---|---|---|---|---|
AFCAA REVIC | Да | Да | REVIC | KLOC, Коэффициенты масштабирования, драйверы затрат | проприетарный, текст | любой | DOS | бесплатно | проприетарный бесплатно для общедоступного распространения |
Seer for Software | Да | Да | SEER-SEM | SLOC, Функциональные точки, варианты использования, снизу вверх, объект, функции | проприетарный, Excel, Microsoft Project, IBM Rational, Oracle Crystal Ball | любая | Windows, любая (Интернет-версия ) | Коммерческая | Собственная |
SLIM | Да | Да | SLIM | Размер (SLOC, Функциональные точки, варианты использования и т. Д.), Ограничения (размер, продолжительность, усилия, персонал), масштабные коэффициенты, исторические проекты, исторические тенденции | проприетарный, Excel, Microsoft Project, Microsoft PowerPoint, IBM Rational, текст, HTML | любой | Windows, любой (Веб-интерфейс ) | Коммерческий | Собственный |
TruePlanning | Да | Да | ЦЕНА | Компоненты, структуры, действия, факторы затрат, процессы, размер функционального программного обеспечения (исходные строки кода (SLOC), функциональные точки, точки преобразования вариантов использования (UCCP), точки прогнозирования объектов (POP) и т. Д.) | Excel, CAD | любой | Windows | Коммерческий | Собственный |