Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

В разработке программного обеспечения , оценка усилий является процессом прогнозирования наиболее реалистичного количества усилий (выражается через человеко-часов или денег) , необходимое для разработки и поддержания программного обеспечения на основе неполных, неопределенные и шумный входа. Оценки трудозатрат могут использоваться в качестве исходных данных для планов проекта, планов итераций, бюджетов, инвестиционного анализа, процессов ценообразования и раундов торгов. [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] илиобъектные точки в 1990-е гг.

Подходы к оценке [ править ]

Есть много способов категоризации подходов к оценке, см., Например. [12] [13] Категории верхнего уровня:

  • Экспертная оценка: этап количественной оценки, т. Е. Этап, на котором оценка производится на основе оценочных процессов. [14]
  • Формальная модель оценки: этап количественной оценки основан на механических процессах, например, использовании формулы, полученной на основе исторических данных.
  • Комбинированная оценка: этап количественной оценки основан на субъективной и механической комбинации оценок из разных источников.

Ниже приведены примеры подходов к оценке в каждой категории.

Подход к оценкеКатегорияПримеры поддержки реализации оценочного подхода
Аналогия основанная оценкаФормальная модель оценкиАНГЕЛ, Взвешенные микро-функциональные точки
Оценка на основе WBS (снизу вверх)Экспертная оценкаПрограммное обеспечение для управления проектами , шаблоны деятельности для конкретной компании
Параметрические моделиФормальная модель оценкиCOCOMO , SLIM , SEER-SEM , TruePlanning для программного обеспечения
Модели оценки на основе размера [15]Формальная модель оценкиФункция точка анализ , [16] Use Case Analysis, Использование очки , SSU (Software Размер Unit), история указует основанную оценку в разработке программного обеспечения Agile , точки объекта
Оценка группыЭкспертная оценкаПланирование покера , Wideband delphi
Механическая комбинацияОценка на основе комбинацииСреднее значение оценки усилий на основе аналогий и структурной разбивки работ [17]
Осуждающая комбинацияОценка на основе комбинацииЭкспертная оценка на основе оценок параметрической модели и групповой оценки

Выбор подходов к оценке [ править ]

Данные о различиях в точности оценки различных подходов и моделей оценки предполагают, что не существует «наилучшего подхода» и что относительная точность одного подхода или модели по сравнению с другим сильно зависит от контекста. [18] Это означает, что разные организации извлекают выгоду из разных подходов к оценке. Результаты [19], которые могут поддержать выбор метода оценки на основе ожидаемой точности подхода, включают:

  • Экспертная оценка в среднем не менее точна, чем оценка усилий на основе модели. В частности, ситуации с нестабильными отношениями и важной информацией, не включенной в модель, могут предложить использование экспертной оценки. Это, конечно, предполагает наличие экспертов с соответствующим опытом.
  • Формальные модели оценки, не адаптированные к условиям конкретной организации, могут быть очень неточными. Следовательно, использование собственных исторических данных имеет решающее значение, если нельзя быть уверенным, что основные взаимосвязи модели оценки (например, параметры формулы) основаны на аналогичных контекстах проекта.
  • Формальные модели оценки могут быть особенно полезны в ситуациях, когда модель адаптирована к контексту организации (либо за счет использования собственных исторических данных, либо модель получена из аналогичных проектов и контекстов), и вполне вероятно, что оценки экспертов будут при условии сильной степени принятия желаемого за действительное.

Наиболее надежный вывод во многих областях прогнозирования состоит в том, что комбинация оценок из независимых источников, предпочтительно с применением различных подходов, в среднем повысит точность оценки. [19] [20] [21]

Важно знать об ограничениях каждого традиционного подхода к измерению производительности разработки программного обеспечения. [22]

Кроме того, в процессе выбора следует учитывать другие факторы, такие как легкость понимания и передачи результатов подхода, простота использования подхода и стоимость внедрения подхода.

Оценка точности оценок [ править ]

Наиболее распространенной мерой средней точности оценки является MMRE (средняя величина относительной ошибки), где MRE каждой оценки определяется как:

MRE =

Эта мера подвергалась критике [23] [24] [25], и есть несколько альтернативных мер, таких как более симметричные меры, [26] Средневзвешенное значение квартилей относительных ошибок (WMQ) [27] и Среднее отклонение от оценки (MVFE). ). [28]

MRE не является надежным, если отдельные элементы перекошены. PRED (25) предпочтительнее в качестве меры точности оценки. PRED (25) измеряет процент предсказанных значений, которые находятся в пределах 25 процентов от фактического значения.

Высокая ошибка оценки не может автоматически интерпретироваться как индикатор низкой способности оценки. Альтернативные, конкурирующие или дополняющие причины включают в себя низкую стоимость контроля над проектом, высокую сложность разработки и большую функциональность, чем первоначально предполагалось. Структура для улучшенного использования и интерпретации измерения ошибки оценки включена в [29].

Психологические проблемы [ править ]

Существует множество психологических факторов, потенциально объясняющих сильную тенденцию к чрезмерно оптимистичным оценкам усилий, которые необходимо учитывать, чтобы повысить точность оценок усилий. Эти факторы важны даже при использовании формальных моделей оценки, поскольку большая часть входных данных для этих моделей основывается на суждениях. Доказано, что важны следующие факторы: принятие желаемого за действительное , привязка , ошибка планирования и когнитивный диссонанс . Обсуждение этих и других факторов можно найти в работе Йоргенсена и Гримстада. [30]

  • Легко оценить то, что вы знаете.
  • Трудно оценить то, что вы знаете, чего не знаете. (известные неизвестные)
  • Очень сложно оценить то, чего вы не знаете, чего не знаете. (неизвестные неизвестные)

Юмор [ править ]

Хроническая недооценка усилий по разработке привела к появлению и популярности множества юмористических пословиц, таких как ироничное обращение к задаче как к « небольшому вопросу программирования » (когда, вероятно, требуется много усилий) и цитирование законов о недооценке:

  • Правило девяноста девяноста :

Первые 90 процентов кода составляют первые 90 процентов времени разработки. Остальные 10 процентов кода составляют остальные 90 процентов времени разработки. [31]

-  Том Каргилл, Bell Labs
  • Закон Хофштадтера :

Закон Хофштадтера: это всегда занимает больше времени, чем вы ожидаете, даже если принять во внимание закон Хофштадтера.

-  Дуглас Хофштадтер , Гедель, Эшер, Бах: вечная золотая коса [32]
  • Закон Фреда Брукса :

То, что один программист может сделать за один месяц, два программиста могут сделать за два месяца.

-  Фред Брукс

В дополнение к тому факту, что оценить усилия по разработке сложно, стоит отметить, что выделение дополнительных ресурсов не всегда помогает.

Сравнение программ оценки разработки [ править ]

Программного обеспеченияОценка расписанияСмета расходовМодели затратВходФормат вывода отчетаПоддерживаемые языки программированияПлатформыРасходыЛицензия
AFCAA REVIC [33]дадаРЕВИКKLOC , коэффициенты масштабирования, факторы затратпроприетарный, текстлюбойДОССвободныйСобственность Бесплатно для публичного распространения
Провидец программного обеспечениядадаSEER-SEMSLOC , функциональные точки , варианты использования, снизу вверх, объект, функциипроприетарный, Excel, Microsoft Project, IBM Rational, Oracle Crystal BallлюбойWindows, Любая ( Интернет- версия )КоммерческийПроприетарный
SLIM [34]дадаСТРОЙНЫЙРазмер ( SLOC , функциональные точки , варианты использования и т. Д.), Ограничения (размер, продолжительность, усилия, персонал), масштабные коэффициенты, исторические проекты, исторические тенденциипроприетарный, Excel, Microsoft Project, Microsoft PowerPoint, IBM Rational, текст, HTMLлюбойWindows, любая ( Интернет- версия ) [35]КоммерческийПроприетарный
TruePlanning [36]дадаЦЕНАКомпоненты, структуры, действия, драйверы затрат, процессы, размер функционального программного обеспечения (исходные строки кода (SLOC), функциональные точки, точки преобразования вариантов использования (UCCP), точки прогнозируемых объектов (POP) и т. Д.)Excel, САПРлюбойОкнаКоммерческийПроприетарный

См. Также [ править ]

  • Конус неопределенности
  • Оценка затрат в программной инженерии
  • Модели оценки затрат
  • Перерасход
  • Функциональные точки
  • Ошибка планирования
  • Оценка на основе прокси
  • Модель Патнэма
  • Метрика программного обеспечения
  • Программные параметрические модели

Ссылки [ править ]

  1. ^ «Что мы делаем и чего не знаем об оценке усилий при разработке программного обеспечения» .
  2. ^ "Руководство по оценке и оценке затрат GAO-09-3SP Лучшие практики для разработки и управления капитальными затратами программы" (PDF) . Счетная палата правительства США. 2009 г.
  3. Перейти ↑ Jørgensen, M. (2004). «Обзор исследований по экспертной оценке усилий при разработке программного обеспечения» . Журнал систем и программного обеспечения . 70 (1–2): 37–60. DOI : 10.1016 / S0164-1212 (02) 00156-5 .
  4. ^ Molokken, К. Йоргенсен, М. (2003). «Обзор обзоров программного обеспечения по оценке объема программного обеспечения». 2003 Международный симпозиум по эмпирической разработке программного обеспечения, 2003. ISESE 2003. Труды . С. 223–230. DOI : 10.1109 / ISESE.2003.1237981 . ISBN 978-0-7695-2002-5. S2CID  15471986 .CS1 maint: multiple names: authors list (link)
  5. ^ Йоргенсен, М. Тейген, К. Х. Рибу, К. (2004). «Лучше уверенность, чем безопасность? Чрезмерная уверенность в интервалах прогнозирования усилий при разработке программного обеспечения на основе суждений». Журнал систем и программного обеспечения . 70 (1–2): 79–93. DOI : 10.1016 / S0164-1212 (02) 00160-7 .CS1 maint: multiple names: authors list (link)
  6. Перейти ↑ Edwards, JS Moores (1994). «Конфликт между использованием инструментов оценки и планирования в управлении информационными системами». Европейский журнал информационных систем . 3 (2): 139–147. DOI : 10.1057 / ejis.1994.14 . S2CID 62582672 . 
  7. ^ Гудвин, П. (1998). Повышение субъективного прогнозирования продаж: роль лабораторных исследований. Прогнозирование с суждением. Г. Райт и П. Гудвин. Нью-Йорк, John Wiley & Sons: 91-112. Здравствуй
  8. ^ Фарр, Л. Нанус, Б. «Факторы, влияющие на стоимость компьютерного программирования, том I» (PDF) . CS1 maint: multiple names: authors list (link)
  9. ^ Фарр, Л. Нанус, Б. «Факторы, влияющие на стоимость компьютерного программирования, том II» (PDF) . CS1 maint: multiple names: authors list (link)
  10. ^ Нельсон, EA (1966). Справочник по менеджменту для оценки затрат на программирование. AD-A648750, Systems Development Corp.
  11. ^ Анда, Б. Ангелвик, Э. Рибу, К. (2002). «Улучшение практики оценки путем применения моделей вариантов использования». Конспект лекций по информатике . 2559 : 383–397. CiteSeerX 10.1.1.546.112 . DOI : 10.1007 / 3-540-36209-6_32 . ISBN  978-3-540-00234-5.CS1 maint: multiple names: authors list (link) ISBN  9783540002345 , 9783540362098 .
  12. Перейти ↑ Briand, LC, Wieczorek, I. (2002). Оценка ресурсов в программной инженерии. Энциклопедия программной инженерии. JJ Marcinak. Нью-Йорк, John Wiley & Sons: 1160–1196.
  13. ^ Йоргенсен, М. Шепперд, М. «Систематический обзор исследований оценки затрат на разработку программного обеспечения» .CS1 maint: multiple names: authors list (link)
  14. ^ «Услуги по разработке программного обеспечения на заказ - Разработка приложений на заказ - Oxagile» .
  15. ^ Хилл Питер (ISBSG) - Рабочая тетрадь 2 - опубликована Международной группой стандартов сравнительного анализа программного обеспечения ISBSG - Ресурсный центр по оценке и сравнительному анализу. Архивировано 29 августа 2008 г. в Wayback Machine.
  16. ^ Моррис Пэм - Обзор общих показателей анализа функциональных точек - Центр ресурсов функциональных точек
  17. ↑ Шриниваса Гопал и Минакши Д'Соуза. 2012. Повышение точности оценки за счет использования аргументации на основе случая и комбинированного подхода к оценке. В материалах 5-й конференции по разработке программного обеспечения в Индии (ISEC '12). ACM, Нью-Йорк, Нью-Йорк, США, 75-78. DOI = https://dx.doi.org/10.1145/2134254.2134267
  18. ^ Шепперд, М. Kadoda, Г. (2001). «Сравнение программных методов прогнозирования с использованием моделирования» . IEEE Transactions по разработке программного обеспечения . 27 (11): 1014–1022. DOI : 10.1109 / 32.965341 .CS1 maint: multiple names: authors list (link)
  19. ^ a b Йоргенсен, М. «Оценка усилий по разработке программного обеспечения: свидетельства экспертных оценок и формальных моделей» .
  20. Перейти ↑ Winkler, RL (1989). «Комбинирование прогнозов: философская основа и некоторые текущие вопросы менеджера». Международный журнал прогнозирования . 5 (4): 605–609. DOI : 10.1016 / 0169-2070 (89) 90018-6 .
  21. ^ Blattberg, RC Хох, SJ (1990). «Модели баз данных и управленческая интуиция: 50% модель + 50% менеджер». Наука управления . 36 (8): 887–899. DOI : 10.1287 / mnsc.36.8.887 . JSTOR 2632364 . CS1 maint: multiple names: authors list (link)
  22. ^ BlueOptima (2019-10-29). «Определение надежных и объективных показателей разработки программного обеспечения» .
  23. ^ Шепперд, М. Картрайт, М. Kadoda, Г. (2000). «О построении систем прогнозирования для инженеров-программистов». Эмпирическая программная инженерия . 5 (3): 175–182. DOI : 10,1023 / A: 1026582314146 . S2CID 1293988 . CS1 maint: multiple names: authors list (link)
  24. ^ Китченхэм, Б. Пикард, Л. М. Макдонелл, С. Г. Шепперд. «Какую точность на самом деле измеряет статистика» .CS1 maint: multiple names: authors list (link)
  25. ^ Фосс, Т. Stensrud, Е. Kitchenham, Б. Myrtveit, И. (2003). «Имитационное исследование критерия оценки модели MMRE» . IEEE Transactions по разработке программного обеспечения . 29 (11): 985–995. CiteSeerX 10.1.1.101.5792 . DOI : 10.1109 / TSE.2003.1245300 . CS1 maint: multiple names: authors list (link)
  26. ^ Миядзаки, Ю. Terakado, М. Озаки, К. Нозаки, Х. (1994). «Робастная регрессия для разработки моделей оценки программного обеспечения» . Журнал систем и программного обеспечения . 27 : 3–16. DOI : 10.1016 / 0164-1212 (94) 90110-4 .CS1 maint: multiple names: authors list (link)
  27. ^ Ло, Б. Гао, X. «Оценка моделей оценки стоимости программного обеспечения: критерии точности, согласованности и регрессии» .CS1 maint: multiple names: authors list (link)
  28. Перейти ↑ Hughes, RT Cunliffe, A. Young-Martos, F. (1998). «Оценка методов построения моделей усилий при разработке программного обеспечения для применения в телекоммуникационной среде в реальном времени» . IEE Proceedings - Программное обеспечение . 145 : 29. DOI : 10.1049 / ip-sen: 19983370 .CS1 maint: multiple names: authors list (link)
  29. Перейти ↑ Grimstad, S. Jørgensen, M. (2006). «Структура для анализа точности оценки стоимости программного обеспечения» .CS1 maint: multiple names: authors list (link)
  30. ^ Йоргенсен, М. Гримстад, С. «Как избежать воздействия неактуальной и вводящей в заблуждение информации при оценке усилий по разработке программного обеспечения» .CS1 maint: multiple names: authors list (link)
  31. ^ Бентли, Джон (1985). «Жемчужины программирования». Связь ACM (требуется плата) требует ( помощь ) . 28 (9): 896–901. DOI : 10.1145 / 4284.315122 . ISSN 0001-0782 . S2CID 5832776 . |format=|url=  
  32. ↑ Гедель, Эшер, Бах: вечная золотая коса . 20-летие изд., 1999, с. 152. ISBN 0-465-02656-7 . 
  33. ^ Руководство AFCAA Revic 9.2 Мемориальный комплекс Ревича
  34. ^ "Обзор SLIM Suite" . Qsm.com . Проверено 27 августа 2019 .
  35. ^ "SLIM-WebServices" . Qsm.com . Проверено 27 августа 2019 .
  36. ^ TruePlanning Интегрированные модели затрат Сайт PRICE Systems Архивировано 5 ноября 2015 г. на Wayback Machine