軟體構架評估

Version 1.0

2008-12-1

本文為《軟體構架實踐》一書的讀書筆記。

一、            總述

Why：通過構架能瞭解系統的重要屬性，即使系統還不存在，這是構架評估的理論依據；評估檢驗構架能否滿足要求，帶來諸多收益；

What：

When：可在多個點上進行——構架的早期，評估已經做出的決策與正在考慮的決策；構架完成後開始進入細節前；對已完成的早期系統的評估；採購軟體系統前對其進行評估…

Where：XXX

Who：也許因評估方法而異；

How：定量方法與非定量方法；

How mush：參與人員的時間花費；

Preconditions：清楚的構架目標與需求；可控的明確的構架目標；合適的評估方法以保證收益大於付出；關鍵人員，設計師或至少透徹理解構架的人員的參與；稱職、權威的評估小組，以使評估活動及結果能得到各方的尊重和認同；可管理的期望，理解組織對評估的期望；

Output：報告，描述了所關心的問題及其支援資料，如果存在未解決問題則確定其優先順序；其他，包括對評估活動本身的總結，以提高以後的能力；

二、            ATAM

構架權衡分析方法：一種非定量方法，它可揭示構架滿足特定質量目標的情況，及構架對質量目標的權衡；

1，人員

評估小組：獨立的評估小組，包括小組負責人、評估負責人、書記員、計時員、過程觀察者、提問者等角色；

專案決策者：有權要求專案改變的人，管理人員，客戶代表，設計師；

涉眾：開發、測試、維護、使用者等，他們說明構架應滿足的具體目標；

2，輸出

能在1小時內表述的構架描述

清楚的業務目標

用場景捕獲的質量需求

敏感點、權衡點、有風險決策、無風險決策…

3，過程，4階段法

l         0階段，合作關係與準備，確定細節：人員名單，時間，地點；評估小組獲取資料並進行初步瞭解分析；

l         1階段，評估階段，決策者參與，小組開始資訊收集與分析；耗時約1周

1～2週中斷期，評估小組進一步以非正式方式瞭解構架；

l         2階段，評估階段，涉眾參與，分析繼續；約2天；

l         3階段，後續階段，生成最終報告，進行評估活動總結；1周；

評估階段的細分：

1）  評估負責人向決策者表述ATAM方法，使大家理解其過程，瞭解角色佈局；

2）  決策者介紹系統商業動機、重要功能、各種限制、商業目標、驅動因素等；

3）  設計師介紹構架，技術限制、所用模式等；

4）  評估小組利用所有已知資訊對構架方法進行分類；

5）  生成質量屬性效用樹，捕獲詳細的需求資訊，為每個場景分配一個級別，如（高，中），前者為重要度，後者為實現難易度，重點放在（高，高）的場景；此處場景具備刺激、環境、響應三要素就可以了；

6）  評估小組分析所有重要場景，設計師解釋如何支援該場景，檢查所用構架方法，分析風險點、權衡點、敏感點；

效用樹：效用為根，效能等質量屬性組成二級節點，繼續細分直到場景，場景為葉；

經過一段中斷期，第2階段開始，此時涉眾開始參與；首先仍然需要一個對ATAM方法的介紹，並使涉眾瞭解已有的成果；

7）  集體討論並分析場景的優先順序，以瞭解更廣泛的涉眾的想法；該過程可能產生新的場景；使用“有限票數法”投票確定每個場景的優先順序——此處不考慮實現難度了吧；

8）  分析新的高優先順序的場景，構架師解釋構架是怎麼滿足各場景的；

9）  總結評估結果，評估負責人展示該結果；

注意，看起來第1階段與第2階段活動類似，但它們的關注點與具體操作並不相同。

4，限制

ATAM不是一個準確的方法，且風險不可被量化；

5，小結

看起來ATAM是一個通過捕獲詳細的質量屬性場景，選擇其中最重要的一部分，考慮構架如何滿足這些場景來進行評估的方法；這是一個“過程”方法而非技術方法；

三、            CBAM

成本收益分析方法：對構架設計決策的成本和收益進行建模，一個定量計算的方法；與ATAM的關係是，它可以利用ATAM的輸出。

定量計算存在太多不確定因素——看看老外是怎樣設法解決某些“不可解決”的問題的。

1，原理

CBAM使用“一組”場景進行評估，它們構成“效用—響應曲線”，其x軸為響應的取值，y軸為對應效用值，即y=f(x)；使用該曲線獲得相應變化時所能獲得的效用的變化值。

曲線生成——“4值近似法”（書中提及的第5個值，看起來不是用來生成曲線的，而是使用曲線的），這些值都需要從涉眾處獲得：

l         最好情況的質量屬性級別，最好指繼續提高質量屬性也不能帶來效用的提升，此時效用值取100（如1秒）；

l         最壞情況的質量屬性級別，最壞指如果質量屬性低於該值，系統將毫無價值（如10秒）；

l         本場景（曲線表現的是某個場景）當前的響應與效用級別（當前是5秒，使用者願意付錢50）；

l         期望的效用級別（如果能達到3秒，使用者願意支付80）

確定每個屬性的權重，構架師選擇策略，考慮策略對每個屬性的影響，計算獲得的總收益與成本；

2，過程

1，  整理場景，根據商業目標確定優先順序，選擇1/3的場景；

2，  確定每個場景的最好、最壞、當前、期望情況的質量響應級別——此步僅處理響應級別，期望值有可能等於最好值；

3，  涉眾投票確定場景優先順序——這將同時獲得各場景的權重，去掉一半低優先順序的場景；

4，  涉眾為剩下的場景，根據2中的響應確定效用；

5，  為場景開發構架策略，確定所期望的通過該構架策略所能獲得的質量屬性響應級別；需要分析該策略可能影響的所有場景；

6，  使用內插法確定策略的效用；

7，  計算每個場景的總收益；

8，  確定每個場景的成本/收益ROI，依照值的高低選擇策略，除非其不能滿足預算或進度要求；

9，  通過直覺檢驗結果，如果差別巨大，可能需重新考慮整個過程；

3，問題

1，  為何不把3提前，首先去掉更多的場景以減少工作量？

2，  為何把響應級別與其效用的取值分開成兩步來做？

難道這些僅僅是“最佳實踐”？

4，小結

本方法通過引入“效用—響應曲線”，主要解決了響應的提升所能帶來的效用的計算問題；理論上，如果能獲得準確的“效用—響應曲線”，加上準確的當前響應值（該值應該較易得到），加上策略所能產生影響的準確值，就能計算出策略的準確的ROI。

可見，要想獲得準確的結果，至少下述問題需要解答：

怎樣確保“效用—響應曲線”——哪怕僅僅是那4個點——足夠準確？

怎樣準確確定策略將影響到那些場景？

怎樣確定策略對某個場景能產生多大的響應提升？

沒有好的解決辦法，甚至無所不能的“歷史資料”，看起來都作用有限，於是目前只能完全依賴於檢驗了；這也是步驟9的由來：其實大家對某個策略所能產生的效果都有個“直覺值”，而CBAM的過程使涉眾能夠將那個總的直覺分解到各個步驟中，並且使用不同的、更規範的思維方式表現出來（對最好值的直覺、對策略的效應的直覺…）。這就是CBAM的結果應該與涉眾直覺大體一致的原因。

四、            參考資料

《軟體構架實踐》。