軟件開發成本金字塔

Question

一位朋友前幾天告訴我，在軟件開發生命週期中解決問題的成本有金字塔。我在哪裏可以找到這個？

他指的是解決問題的成本。

例如，

要在需求階段成本1.

解決問題要在開發階段成本10.

解決問題要在測試解決問題階段成本100

要解決生產階段的成本問題1000.

（這些數字僅僅是示例）

我希望看到更多關於此的信息，如果任何人有引用。

Answer 1

The Incredible Rate of Diminishing Returns of Fixing Software Bugs

（斯特凡Priebsh：OOP和設計模式：Codeworks DC在2009年9月）

Answer 2

從來沒有聽說過它被稱爲金字塔之前，這似乎有點顛倒了我！儘管如此，中心論點被廣泛認爲是正確的。在這個問題上，對於在alpha階段修復bug的成本往往是微不足道的。在測試階段，它可能需要更多的調試和用戶報告。運輸後可能會非常昂貴。必須創建一個全新的版本，您不得不擔心打破生產中的代碼和數據，由於該錯誤，銷售也可能會丟失？

Answer 3

這是經驗的軟件工程一個衆所周知的結果是已被複制和驗證無數次的研究一遍又一遍。不幸的是，這在軟件工程中非常罕見：大多數軟件工程「結果」基本上都是傳聞，軼事，猜測，意見，一廂情願的想法或簡單的謊言。實際上，大多數軟件工程可能不配「工程」品牌。

不幸的是，儘管它是最堅實，最科學和最具統計特徵的，研究最深入，得到最廣泛驗證的軟件工程複製結​​果，但這也是錯誤的。

問題是所有這些研究都不能正確控制它們的變量。如果要衡量一個變量的影響，你必須非常小心改變只是一個變量和其他變量完全不改變。不是「改變一些變量」，而不是「最小化對其他變量的改變」。 「只有一個」和其他「完全不」。或者，用傑出的Zed Shaw的話說：如果你想測量狗屎，不要測量其他狗屎。

在這種特殊情況下，他們沒有不只是衡量哪個階段（需求，分析，建築，設計，實施，測試，維護）的bug被發現，他們也衡量它是如何長留在系統中。事實證明，這個階段幾乎不相關，重要的是時間。重要的是發現錯誤快速，而不是在哪個階段。

這有一些有趣的分支：如果發現錯誤很重要快速，那麼爲什麼要等這麼長時間，最可能發現錯誤的階段：測試？爲什麼不把測試放在開始？

「傳統」解釋的問題是，它導致低效的決策。因爲您認爲您需要在需求階段找到所有錯誤，所以您不必要地拖出需求階段：不能運行需求（或體系結構或設計），因此找不到某些您不能即使執行正在發抖硬！基本上，雖然修復錯誤在要求階段很便宜，發現他們是昂貴的。

但是，如果你意識到這不是關於尋找在儘可能早的階段的錯誤，而是要找到的錯誤在最早的時間，那麼你可以調整你的過程中，讓你移動找到錯誤是最便宜的（測試）到修復他們是最便宜（最開始）的時間點的階段。

---

注意：我很清楚終止咆哮關於沒有正確應用統計數據的完全沒有根據的說法的諷刺。不幸的是，我在閱讀本文時丟失了鏈接。 Glenn Vanderburg在他的「Real Software Engineering」在2010年孤星紅寶石會議上的演講中也提到了這一點，但AFAICR，他也沒有引用任何消息來源。

如果有人知道任何來源，請讓我知道或編輯我的回答，甚至只是偷我的答案。 （如果你可以找到一個來源，你應該得到所有的代表！）

Answer 4

請參閱this presentation（pdf）的第42和43頁。

不幸的是，這種情況與Jörg描述的一樣，事實上有些惡化：本文中引用的大多數參考文獻都將我視爲虛假，因爲所引用的論文要麼不是原創性研究，要麼不包含支持或者 - 在1998 paper about Hughes（p54）的情況下 - 包含的測量結果實際上與演示文稿p42中的曲線隱含的內容相反：曲線的不同形狀以及適度的x5至x10因子需求階段和功能測試階段之間的成本 - 修復（實際上系統測試和維護的減少）。

Answer 5

試試這個article。它使用「成本金字塔」參數（不命名它）等等。