Затраты на разработку программного обеспечения пирамида [закрыто

Question

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

Он имел в виду стоимость решения проблемы.

Например,

Чтобы решить проблему на стадии требований 1.

Чтобы решить проблему на этапе разработки, стоит 10.

Чтобы решить проблему на стадии тестирования, стоит 100

Чтобы решить проблему на стадии производства, стоит 1000.

(Эти цифры просто примеры)

Мне было бы интересно узнать больше об этом, если у кого -то есть ссылки.

Answer 1

Невероятная скорость уменьшения доходности исправлений программных ошибок

(Stefan Priebsh: ООП и дизайнерские шаблоны: Codeworks DC в сентябре 2009 года)

Answer 2

Это хорошо известный результат в эмпирической разработке программного обеспечения, которая была воспроизведена и проверена снова и снова в бесчисленных исследованиях. К сожалению, это очень редко в разработке программного обеспечения: большинство «результатов разработки программного обеспечения» - это в основном слухи, анекдоты, догадки, мнения, желаемое мышление или просто ложь. На самом деле, большинство разработчиков программного обеспечения, вероятно, не заслуживает «инженерного» бренда.

К сожалению, несмотря на то, что он является одним из самых прочных, наиболее научных и статистически обоснованных, наиболее исследованных, наиболее широко проверенных, чаще всего воспроизводимых результатов разработки программного обеспечения, это также неправильно.

Проблема в том, что все эти исследования не контролируют свои переменные должным образом. Если вы хотите измерить эффект переменной, вы должны быть очень Осторожно измениться Только тот один переменная и что другие переменные не изменяются вообще. Анкет Не «изменять несколько переменных», а не «минимизировать изменения в других переменных». «Только один» и другие "совсем не".

Или, в блестящих словах Зеда Шоу: если вы хотите измерить дерьмо, не измеряйте другое дерьмо.

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

Это имеет некоторые интересные последствия: если важно найти ошибки быстро, Тогда зачем так долго ждать с фазой, которая, скорее всего, найдет ошибки: тестирование? Почему бы не поставить тестирование в начало?

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

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

---

Примечание: я хорошо знаю о иронии прекращения разглагольствования о том, что он не применяет статистику с совершенно необоснованным требованием. К сожалению, я потерял ссылку, где прочитал это. Гленн Вандербург также упомянул об этом в своем "Реальная разработка программного обеспечения«Поговорите на конференции Lone Star Ruby 2010, но Afaicr, он также не ссылался на никаких источников.

Если кто -то знает какие -либо источники, пожалуйста Дайте мне знать или отредактировать мой ответ, или даже просто воровать мой ответ. (Если вы можете найти источник, вы заслуживаете всего представителя!)

Answer 3

Смотрите страницы 42 и 43 это презентация (PDF).

К сожалению, ситуация происходит, как изображает Джёрг, на самом деле несколько хуже: большинство ссылок, упомянутых в этом документе, считают меня фиктивным, в том смысле, что цитируемая статья либо не является первоначальным исследованием, или не содержит слов, подтверждающих предъявленное требование, или - в случае 1998 год о Хьюзе (p54) - содержит измерения, которые по факту противоречить тому, что подразумевается кривой в P42 презентации: различная форма кривой и скромный фактор затрат на фиксирование от X5 до x10 между фазой требований и фазой функционального испытания (и фактически уменьшение тестирования и обслуживания системы и обслуживания )

Answer 4

Никогда не слышал о том, что его называли пирамидой раньше, и это кажется мне немного перевернутым! Тем не менее, центральный тезис широко считается правильным. Просто густо, затраты на исправление ошибки на стадии Альфа часто тривиальны. На бета -стадии это может потребоваться немного больше отладки и отчетов пользователей. После доставки это может быть очень дорого. Необходимо создать целую новую версию, вы должны беспокоиться о нарушении кода и данных в производстве, также могут быть потеряны продажи из-за ошибки?

Answer 5

Попробуй это статья. Анкет Он использует аргумент «Пирамида затрат» (без именования), среди прочего.