帶你讀《SAS資料分析開發之道 軟體品質的次元》第二章品質2.2軟體産品品質模型（四）

品質成本

在軟體或其他産品的開發過程中，确實會存在内部的權衡取舍，我們稱之為限制條件。PMBOK指南将品質和其他5 個架構作為項目的主要限制條件，但同時也指出，這些限制條件不應該看作是完全詳盡的。作為一個限制條件，在軟體    項目的規劃和設計過程中，品質與其他架構之間存在價值和優先次序的競争。實際上，開發人員從軟體中删除性能時，關注的是他們可以得到所有奇妙的東西！

增加範圍     開發人員無須将性能需求編碼到軟體中，他們關注的是附加的功能性。例如，相比提升 SAS軟體的穩健性以避免故障，開發人員可能會選擇建立附加分析報告。

安排      性能需求的添加通常會使代碼更冗長、更複雜，是以相應的，設計、開發和測試階段也會延長。若不優先考慮性能，客戶和其他利益相關者就能夠更快地收到軟體。

預算      由于性能需求的執行需要耗費一定的時間，但時間就是金錢，項目預算通常會随着性能需求的增加而增加。通過删除軟體中的性能，開發團隊能節省一部分預算，或者将節省下來的資金用到其他方面，何其快哉？

資源      項目資源不僅包括人力資源，還包括水電資源。随着性能需求的犧牲，項目所需的開發人員相應也會減少，同時消耗的資源也會減少。

風險      風險不是益處，而是未優先考慮性能時所遇到的意想不到的結果。由于許多性能需求被設計用來減少或消除軟體中的漏洞，是以，當忽略性能需求時，風險通常也會随之增加。

盡管限制條件意味着限制性，但我們也可以從機會成本的角度來看待限制條件。例如，開發人員可以在軟體中添加性能要求，或者他們可以選擇不添加，以生産出速度更快、價格更低廉或功能更強的軟體。但若要評估某個機會，我們就需要知道機會的價值所在。是以，本書的一個目标是讓開發人員熟悉在軟體中插入性能需求的好處，進而幫助他們判定出品質的機會成本。例如，如果利益相關者已經決定執行附加的功能性（是以排除附加的性能），那麼利益相關者至少已經弄清楚了所要添加的性能的價值，而且已經根據該性能的機會成本做出了明智的決定。隻有當利益相關者了解了品質的價值及品質缺少的風險時，才能對照其他項目限制條件評估品質，如進度、範圍和預算。

确定品質的價值是比較困難的，尤其是當軟體開發項目中的各個利益相關者對架構的優先順序存在争議時，品質價值的确定就是一件很棘手的事。投資軟體開發的投資者希望用較少的資金建立軟體，而等着使用軟體的使用者則希望軟體能迅速地建立完成。一些開發人員比較關注軟體的功能，而不是特别在乎性能屬性，但其他的   SAS從業人員可能希望軟體具有可靠性、穩健性、可維護性及子產品化。是以，在軟體品質包含哪些特征及如何評估品質（對照其他項目架構）等問題上，達成共識是比較困難的。然而，利益相關者——包括開發人員和非開發人員，如果能使用軟體産品品質模型中規定的統一的術語，他們便能更好地讨論品質特征的添加問題。