Оценка трудозатрат

редактировать

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

Содержание

  • 1 Практическое положение
  • 2 История
  • 3 Подходы к оценке
  • 4 Выбор подходов к оценке
  • 5 Оценка точности оценок
  • 6 Психологические проблемы
  • 7 Юмор
  • 8 Сравнение программ оценки развития
  • 9 См. Также
  • 10 Источники

Практическое положение

Опубликованные обзоры практики оценки показывают, что экспертная оценка является доминирующей стратегией при оценке усилий при разработке программного обеспечения.

Как правило, оценки усилий чрезмерно оптимистичны и есть сильная чрезмерная уверенность в их точности. Средний перерасход усилий составляет около 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 = | фактическое усилие - расчетное усилие | фактическое усилие {\ displaystyle {\ frac {| {\ text {фактическое усилие}} - {\ text {оценочное усилие}} |} {\ text {фактическое усилие}}}}{\ frac {| { \ text {фактическое усилие}} - {\ text {приблизительное усилие}} |} {\ text {фактическое усилие}}}

Эта мера подверглась критике, и есть несколько альтернативных показателей, таких как более симметричные показатели, взвешенное среднее квартилей относительных ошибок (WMQ) и среднее отклонение от оценки (MVFE).

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

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

Психологические проблемы

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

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

Юмор

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

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

— Том Каргилл, Bell Labs

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

Дуглас Хофштадтер, Гедель, Эшер, Бах: вечная золотая коса

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

Фред Брукс

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

Сравнение программного обеспечения для оценки разработки

Программное обеспечениеОценка графикаОценка затратМодели затратИсходные данныеОтчет Формат выводаПоддерживаемые языки программирования Платформы СтоимостьЛицензия
AFCAA REVIC ДаДаREVICKLOC, Коэффициенты масштабирования, драйверы затратпроприетарный, текстлюбой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КоммерческийСобственный

См. Также

Ссылки

Последняя правка сделана 2021-06-08 08:27:06
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте