續(xù)《軟件設計評價》。
    雖然從理論上我們可以知道軟件設計評價具有三類標準，但卻沒有辦法真正按照這些標準去檢驗一個軟件的設計。

    實體空間標準應該是一個軟件設計最終應該附合的標準。但是，這個標準很難直接應用于軟件設計模型上，因為軟件設計是思維的產(chǎn)物，在實體上檢驗這個產(chǎn)物是否 正確，恐怕只能說“實踐是檢驗真理的唯一標準”了。只有在錯誤非常明顯的情況下，這個標準才會起作用。

    過程空間標準相對好一些。通過和軟件生產(chǎn)過程前期階段產(chǎn)物進行對比，可以找到其中不一致的地方，這可能就是設計上的問題了。同時，現(xiàn)代軟件開發(fā)一般采用迭 代的方式進行，設計活動可能分多次進行。這種迭代也要求我們檢查設計對需求的覆蓋情況。

    通過形式空間標準對軟件設計進行檢驗時，往往并不存在一個唯一的檢驗標準。這是因為實際軟件的質(zhì)量要求不是唯一的，不同的軟件有不同的質(zhì)量屬性要求。而特 定軟件的質(zhì)量要求，是在需求分析、設計的過程中逐步形成的。這些質(zhì)量要求，最終成為我們檢驗軟件設計的標準之一。

    根據(jù)這些標準，我們現(xiàn)在設計一個軟件設計評價表模版：

軟件設計評價表
軟件名稱							迭代周期
設計人員
評審人員
設計合理性
需求附合度
功能點覆蓋率（FPC）			?%			重點功能點覆蓋率（IFPC）		?%
優(yōu)先功能覆蓋率（PFPC）			?%			需求一致度(Should be 100%)		?%
質(zhì)量屬性
模塊性	權重	在過程中確定權重			分數(shù)，100分制，下同
可修改性	權重	權重之和應為100%
可擴展性	權重	下同
性能	權重
可靠性	權重
可用性	權重
可移植性	權重
可維護性	權重
靈活性	權重
可重用性	權重
可理解性	權重
彈性	權重
安全性	權重
容錯性	權重
評審結論

    在設計合理性方面，主要考慮以下內(nèi)容：

• 類的職責單一、明確
• 模塊結構清晰、完整
• 活動、行為描述清晰
• 實體關聯(lián)清楚，狀態(tài)合理
  

    對需求附合度的要求要在評價之間確定。

    質(zhì)量屬性的評價權重一般在設計開始之前確定，這個工作多數(shù)在架構設計時刻完成。最后，根據(jù)質(zhì)量屬性的權重，可以計算設計的總體質(zhì)量分數(shù)。這些都是最終評審結論的素材。

    一般來說，對于設計的評價通過建立場景的方法來實現(xiàn)。比如評價可修改性，一般先建立一個修改的場景，對設計進行模擬修改，觀察其是否易于修改。有些質(zhì)量屬性無法通過這種方法檢驗，只能通過對設計模型進行觀察得出結論。