В разработке программного обеспечения оценка усилий — это процесс прогнозирования наиболее реалистичного количества усилий (выраженного в человеко-часах или деньгах), необходимых для разработки или поддержки программного обеспечения на основе неполных, неопределенных и шумных входных данных. Оценки усилий могут использоваться в качестве входных данных для планов проекта, планов итераций, бюджетов, инвестиционных анализов, процессов ценообразования и раундов торгов. [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]. Категории верхнего уровня следующие:
- Экспертная оценка: этап количественной оценки, т. е. этап, на котором оценка производится на основе оценочных процессов. [14]
- Формальная модель оценки: этап количественной оценки основан на механических процессах, например, использовании формулы, полученной из исторических данных.
- Оценка на основе комбинирования: этап количественной оценки основан на субъективном и механическом сочетании оценок из разных источников.
Ниже приведены примеры подходов к оценке в каждой категории.
Выбор подходов к оценке
Данные о различиях в точности оценки различных подходов и моделей оценки свидетельствуют о том, что не существует «лучшего подхода» и что относительная точность одного подхода или модели по сравнению с другим сильно зависит от контекста. [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]
Закон Хофштадтера: Всегда требуется больше времени, чем вы ожидаете, даже если принять во внимание закон Хофштадтера.
То, что один программист может сделать за один месяц, два программиста могут сделать за два месяца.
Сравнение программного обеспечения для оценки развития
Смотрите также
Ссылки
- ^ «Что мы знаем и чего не знаем об оценке усилий по разработке программного обеспечения».
- ^ "Руководство по оценке и расчету затрат GAO-09-3SP. Передовой опыт разработки и управления затратами на капитальные программы" (PDF) . Счетная палата США. 2009.
- ^ Йоргенсен, М. (2004). «Обзор исследований по экспертной оценке усилий по разработке программного обеспечения». Журнал систем и программного обеспечения . 70 (1–2): 37–60. doi :10.1016/S0164-1212(02)00156-5.
- ^ Molokken, K. Jorgensen, M. (2003). "Обзор обзоров программного обеспечения по оценке усилий по разработке программного обеспечения". 2003 Международный симпозиум по эмпирической разработке программного обеспечения, 2003. ISESE 2003. Труды . С. 223–230. doi :10.1109/ISESE.2003.1237981. ISBN 978-0-7695-2002-5. S2CID 15471986.
{{cite book}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Йоргенсен, М. Тейген, К. Х. Рибу, К. (2004). «Лучше быть уверенным, чем безопасным? Излишняя уверенность в интервалах прогнозирования усилий по разработке программного обеспечения на основе суждений». Журнал систем и программного обеспечения . 70 (1–2): 79–93. doi :10.1016/S0164-1212(02)00160-7.
{{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Эдвардс, Дж. С. Мурс (1994). «Конфликт между использованием инструментов оценки и планирования в управлении информационными системами». Европейский журнал информационных систем . 3 (2): 139–147. doi :10.1057/ejis.1994.14. S2CID 62582672.
- ^ Гудвин, П. (1998). Улучшение прогнозирования продаж на основе суждений: роль лабораторных исследований. Прогнозирование с суждением. Г. Райт и П. Гудвин. Нью-Йорк, John Wiley & Sons: 91-112. Привет
- ^ Фарр, Л. Нанус, Б. "Факторы, влияющие на стоимость компьютерного программирования, том I" (PDF) . Архивировано из оригинала (PDF) 21 февраля 2017 г.
{{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Фарр, Л. Нанус, Б. "Факторы, влияющие на стоимость компьютерного программирования, том II" (PDF) . Архивировано из оригинала (PDF) 28 июля 2018 г.
{{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Нельсон, Э. А. (1966). Справочник по управлению оценкой затрат на компьютерное программирование. AD-A648750, Systems Development Corp.
- ^ Анда, Б. Ангелвик, Э. Рибу, К. (2002). «Улучшение методов оценки путем применения моделей вариантов использования». Улучшение процесса разработки программного обеспечения, ориентированного на продукт . Конспект лекций по информатике. Том 2559. С. 383–397. CiteSeerX 10.1.1.546.112 . doi :10.1007/3-540-36209-6_32. ISBN 978-3-540-00234-5.
{{cite book}}
: CS1 maint: несколько имен: список авторов ( ссылка ) ISBN 9783540002345 , 9783540362098 . - ^ Briand, LC и Wieczorek, I. (2002). «Оценка ресурсов в программной инженерии». Энциклопедия программной инженерии . JJ Marcinak. Нью-Йорк, John Wiley & Sons: 1160–1196.
- ^ Йоргенсен, М. Шепперд, М. «Систематический обзор исследований по оценке стоимости разработки программного обеспечения».
{{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ «Услуги по разработке программного обеспечения на заказ – Разработка приложений на заказ – Oxagile».
- ^ Хилл Питер (ISBSG) – Estimation Workbook 2 – опубликовано Международной группой стандартов бенчмаркинга программного обеспечения ISBSG - Центр ресурсов по бенчмаркингу и оценке. Архивировано 29 августа 2008 г. на Wayback Machine.
- ^ Моррис Пэм — Обзор общих показателей анализа функциональных точек — Центр ресурсов функциональных точек
- ^ Шриниваса Гопал и Минакши Д'Соуза. 2012. Повышение точности оценки с помощью рассуждений на основе прецедентов и комбинированного подхода к оценке. В трудах 5-й конференции по программной инженерии в Индии (ISEC '12). ACM, Нью-Йорк, США, 75-78. doi :10.1145/2134254.2134267
- ^ Шепперд, М. Кадода, Г. (2001). «Сравнение методов прогнозирования программного обеспечения с использованием моделирования». Труды IEEE по программной инженерии . 27 (11): 1014–1022. doi :10.1109/32.965341.
{{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ ab Йоргенсен, М. «Оценка трудозатрат на разработку программного обеспечения: данные экспертных оценок и формальных моделей».
- ^ Винклер, Р. Л. (1989). «Объединение прогнозов: философская основа и некоторые текущие вопросы менеджера». Международный журнал прогнозирования . 5 (4): 605–609. doi :10.1016/0169-2070(89)90018-6.
- ^ Blattberg, RC Hoch, SJ (1990). «Модели баз данных и управленческая интуиция: 50% модель + 50% менеджер». Management Science . 36 (8): 887–899. doi :10.1287/mnsc.36.8.887. JSTOR 2632364.
{{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ BlueOptima (29.10.2019). «Определение надежных, объективных метрик разработки программного обеспечения».
- ^ Шепперд, М. Картрайт, М. Кадода, Г. (2000). «О построении систем прогнозирования для инженеров-программистов». Эмпирическая программная инженерия . 5 (3): 175–182. doi :10.1023/A:1026582314146. S2CID 1293988.
{{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Китченхэм, Б. , Пикард, Л. М., Макдонелл, С. Г. Шепперд. «Какую точность на самом деле измеряет статистика».
{{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Фосс Т., Стенсруд Э., Китченхем Б. , Миртвейт И. (2003). «Имитационное исследование критерия оценки модели MMRE». Транзакции IEEE по разработке программного обеспечения . 29 (11): 985–995. CiteSeerX 10.1.1.101.5792 . дои :10.1109/TSE.2003.1245300.
{{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Миядзаки, Y. Terakado, M. Ozaki, K. Nozaki, H. (1994). «Надежная регрессия для разработки моделей оценки программного обеспечения». Журнал систем и программного обеспечения . 27 : 3–16. doi :10.1016/0164-1212(94)90110-4.
{{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Ло, Б. Гао, С. «Оценка моделей оценки стоимости программного обеспечения: критерии точности, согласованности и регрессии».
{{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Хьюз, Р. Т. Канлифф, А. Янг-Мартос, Ф. (1998). «Оценка методов построения моделей усилий по разработке программного обеспечения для применения в телекоммуникационной среде реального времени». Труды IEE — Программное обеспечение . 145 : 29. doi :10.1049/ip-sen:19983370. Архивировано из оригинала 20 сентября 2017 г.
{{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Гримстад, С. Йоргенсен, М. (2006). «Структура для анализа точности оценки стоимости программного обеспечения».
{{cite web}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Йоргенсен, М. Гримстад, С. (2008). «Как избежать влияния нерелевантной и вводящей в заблуждение информации при оценке усилий по разработке программного обеспечения». IEEE Software : 78–83.
{{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Бентли, Джон (1985). «Жемчужины программирования» (требуется плата) . Сообщения ACM . 28 (9): 896–901. doi : 10.1145/4284.315122 . ISSN 0001-0782. S2CID 5832776.
- ^ Гёдель, Эшер, Бах: Вечная золотая коса . 20-летие издания, 1999, стр. 152. ISBN 0-465-02656-7 .
- ^ Руководство AFCAA Revic 9.2 Мемориальный сайт Revic
- ^ "Обзор SLIM Suite". Qsm.com . Получено 2019-08-27 .
- ^ "SLIM-WebServices". Qsm.com . Получено 2019-08-27 .
- ^ TruePlanning Integrated Cost Models PRICE Systems сайт Архивировано 2015-11-05 на Wayback Machine