В разработке программного обеспечения оценка усилий — это процесс прогнозирования наиболее реалистичного количества усилий (выраженного в человеко-часах или деньгах), необходимых для разработки или поддержки программного обеспечения на основе неполных, неопределенных и шумных входных данных. Оценки усилий могут использоваться в качестве входных данных для планов проекта, планов итераций, бюджетов, инвестиционных анализов, процессов ценообразования и раундов торгов. [1] [2]
Опубликованные исследования практики оценки показывают, что экспертная оценка является доминирующей стратегией при оценке усилий по разработке программного обеспечения. [3]
Обычно оценки усилий чрезмерно оптимистичны, и существует сильная самоуверенность в их точности. Среднее превышение усилий, по-видимому, составляет около 30% и не уменьшается со временем. Для обзора исследований ошибок оценки усилий см. [4] Однако измерение ошибки оценки проблематично, см. Оценка точности оценок. Сильная самоуверенность в точности оценок усилий иллюстрируется выводом о том, что в среднем, если специалист по программному обеспечению на 90% уверен или «почти уверен» в том, что включит фактические усилия в интервал минимум-максимум, наблюдаемая частота включения фактических усилий составляет всего 60-70%. [5]
В настоящее время термин «оценка усилий» используется для обозначения различных концепций, таких как наиболее вероятное использование усилий (модальное значение), усилие, которое соответствует вероятности 50% не превышения (медиана), запланированное усилие, бюджетное усилие или усилие, используемое для предложения цены или предложения цены клиенту. Это считается неудачным, поскольку могут возникнуть проблемы с коммуникацией, а также потому, что концепции служат разным целям. [6] [7]
Исследователи и практики программного обеспечения занимаются проблемами оценки усилий для проектов по разработке программного обеспечения, по крайней мере, с 1960-х годов; см., например, работы Фарра [8] [9] и Нельсона [10] .
Большая часть исследований была сосредоточена на построении формальных моделей оценки усилий по программному обеспечению. Ранние модели обычно основывались на регрессионном анализе или математически выводились из теорий из других областей. С тех пор было оценено большое количество подходов к построению моделей, таких как подходы, основанные на рассуждениях на основе прецедентов , деревьях классификации и регрессии , моделировании , нейронных сетях , байесовской статистике , лексическом анализе спецификаций требований, генетическом программировании , линейном программировании , моделях экономического производства, мягких вычислениях , моделировании нечеткой логики , статистическом бутстрапинге и комбинациях двух или более из этих моделей. Возможно, наиболее распространенными методами оценки сегодня являются параметрические модели оценки COCOMO , SEER-SEM и SLIM. Они основаны на исследованиях по оценке, проведенных в 1970-х и 1980-х годах, и с тех пор обновляются новыми данными калибровки, а последним крупным релизом стал COCOMO II в 2000 году. Подходы к оценке, основанные на мерах размера на основе функциональности, например, функциональных точках , также основаны на исследованиях, проведенных в 1970-х и 1980-х годах, но перекалиброваны с использованием измененных мер размера и различных подходов к подсчету, таких как точки вариантов использования [11] или точки объектов и функциональные точки COSMIC в 1990-х годах.
Существует множество способов категоризации подходов к оценке, см., например, [12] [13]. Категории верхнего уровня следующие:
Ниже приведены примеры подходов к оценке в каждой категории.
Данные о различиях в точности оценки различных подходов и моделей оценки свидетельствуют о том, что не существует «лучшего подхода» и что относительная точность одного подхода или модели по сравнению с другим сильно зависит от контекста. [18] Это подразумевает, что разные организации получают выгоду от разных подходов оценки. Выводы [19] , которые могут поддержать выбор подхода оценки на основе ожидаемой точности подхода, включают:
Наиболее надежным выводом во многих областях прогнозирования является то, что сочетание оценок из независимых источников, предпочтительно с применением различных подходов, в среднем повышает точность оценки. [19] [20] [21]
Важно осознавать ограничения каждого традиционного подхода к измерению производительности разработки программного обеспечения. [22]
Кроме того, в процессе выбора следует учитывать и другие факторы, такие как простота понимания и распространения результатов подхода, простота использования подхода и стоимость внедрения подхода.
Наиболее распространенной мерой средней точности оценки является MMRE (средняя величина относительной ошибки), где MRE каждой оценки определяется как:
Эта мера была подвергнута критике [23] [24] [25], и существует несколько альтернативных мер, таких как более симметричные меры, [26] средневзвешенное значение квартилей относительных ошибок (WMQ) [27] и среднее отклонение от оценки (MVFE). [28]
MRE ненадежен, если отдельные элементы искажены. PRED(25) предпочтительнее в качестве меры точности оценки. PRED(25) измеряет процент прогнозируемых значений, которые находятся в пределах 25 процентов от фактического значения.
Высокая ошибка оценки не может автоматически интерпретироваться как показатель низкой способности оценки. Альтернативные, конкурирующие или дополняющие причины включают низкий контроль стоимости проекта, высокую сложность разработки и большую поставляемую функциональность, чем изначально предполагалось. Включена структура для улучшенного использования и интерпретации измерения ошибки оценки. [29]
Существует множество психологических факторов, потенциально объясняющих сильную тенденцию к чрезмерно оптимистичным оценкам усилий. Эти факторы необходимо учитывать даже при использовании формальных моделей оценки, поскольку большая часть входных данных для этих моделей основана на суждениях. Факторы, которые, как было продемонстрировано, важны, — это желаемое за действительное , якорение , ошибка планирования и когнитивный диссонанс . [30]
Хроническая недооценка усилий по разработке привела к появлению и популярности многочисленных юмористических поговорок, например, иронично называющих задачу « маленьким вопросом программирования » (когда, скорее всего, потребуются большие усилия), и цитирующих законы о недооценке:
Первые 90 процентов кода составляют первые 90 процентов времени разработки. Оставшиеся 10 процентов кода составляют остальные 90 процентов времени разработки. [31]
— Том Каргилл, Bell Labs
Закон Хофштадтера: Всегда требуется больше времени, чем вы ожидаете, даже если принять во внимание закон Хофштадтера.
То, что один программист может сделать за один месяц, два программиста могут сделать за два месяца.
— Фред Брукс , [ необходима ссылка ]
{{cite book}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite book}}
: CS1 maint: несколько имен: список авторов ( ссылка ) ISBN 9783540002345 , 9783540362098 .{{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка )