軟件變更控制—控制成本溢出
阿新 • • 發佈：2018-02-23
.net 理論 xxx http sel blog img 控制 必須
軟件生命周期中，軟件修復成本金字塔，越往下修改成本越大。
需求階段發現需求變更代價最小，其他由小到大依次是設計階段 ，編碼階段，測試階段，當到達用戶測試階段和維護階段時，此時修改代碼的代價是原來的5-20倍以上，所以這就是需求階段就與用戶溝通，給他們看原型評審，進行需求確認的意義，減少風險，節約成本。
10月份XXX系統進行需求變更，增加了香港的需求後，新功能做完了，改出來上百個bug，按照經驗個人認為是由於在系統測試階段才進行修改代碼的代價。建議以後的項目，必須增加需求確認環節，需求肯定會變，但我們要管理和控制它，讓它在一個可控範圍內。比如黑龍江就應該在作出原型，畫完流程圖後與用戶確認，這樣才能減少我們的成本超標風險。
<b "="">舉例：
比如需求1和需求2在一開始就開發，它們各自的成本是5人/天，一次性開發是10人/天。
由於需求2一開始並未提出，項目組只開發了需求1，進入測試階段後，發現需求2也要開發，此時需求2的成本按照軟件工程理論翻倍5-20倍，假設為5*5=25，那麽總成本可能為30人/天。
軟件生命周期中，軟件修復成本金字塔，越往下修改成本越大。
需求階段發現需求變更代價最小，其他由小到大依次是設計階段 ，編碼階段，測試階段，當到達用戶測試階段和維護階段時，此時修改代碼的代價是原來的5-20倍以上，所以這就是需求階段就與用戶溝通，給他們看原型評審，進行需求確認的意義，減少風險，節約成本。
10月份XXX系統進行需求變更，增加了香港的需求後，新功能做完了，改出來上百個bug，按照經驗個人認為是由於在系統測試階段才進行修改代碼的代價。建議以後的項目，必須增加需求確認環節，需求肯定會變，但我們要管理和控制它，讓它在一個可控範圍內。比如黑龍江就應該在作出原型，畫完流程圖後與用戶確認，這樣才能減少我們的成本超標風險。
<b "="">舉例：
比如需求1和需求2在一開始就開發，它們各自的成本是5人/天，一次性開發是10人/天。
由於需求2一開始並未提出，項目組只開發了需求1，進入測試階段後，發現需求2也要開發，此時需求2的成本按照軟件工程理論翻倍5-20倍，假設為5*5=25，那麽總成本可能為30人/天。軟件變更控制—控制成本溢出