Стоимость разработки программного обеспечения Pyramid

Ответ 1

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

Ответ 3

См. стр. 42 и 43 эту презентацию (pdf).

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

Ответ 4

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

Ответ 5

Попробуйте статью. Он использует аргумент "стоимостной пирамиды" (не называя его), среди прочих.