目的
|
定義審查的範圍和目標。
定義每項特定的範圍/目標組合所用的方法。
|
您可以利用各種不同的方法來進行審查:
表示法驅動審查
請取得(或建置)架構的表示法,再根據這個表示法來提出問題和原因。
您可能面對各種不同的狀況,從架構程度很高、能夠提供非常清晰的說明來作為起點的組織,到您必須識別誰是軟體架構師(甚至是隱藏在其他名稱之下),且必須從他取得資訊的組織,以至於完全沒有軟體架構概念的情況,都可能存在。因此,這個流程稱為「架構採礦」,而且現實看起來就如同字面的意思:利用尖鋤從軟體或文件中挖掘它、查看程式碼、介面、配置資料等。
軟體架構文件中所呈現的架構視圖格式,便是一種可用來組織表示法的模型:邏輯視圖用來組織主要類別(物件模型)、流程視圖用來說明主要控制緒及其通訊方式、開發視圖用來顯示各個子系統及其相依性、實體視圖用來說明其他視圖的元素到一或多個實體配置的對映。請沿著各種視圖來組織問題。
資訊驅動審查
請建立推理所需要的資訊(資料、測量)清單,取得資訊,再比較這項資訊和需求或某些已接受的參照標準。這也適合用來探索特定品質屬性,例如屬性或健全程度。
情境驅動審查
這是系統性的「假設」方法。請將所提出的一般問題轉換成系統應該經歷的情境,再根據這些情境來提出問題。這些情境的範例如下:
-
系統在 X 和 Y 平台上執行。(所探測的真正品質屬性是可攜性。)
-
系統執行這個(附加的)F 函數。(真正的品質屬性是可延伸性。)
-
系統每小時處理 200 個要求。(真實的品質屬性是延展性。)
-
使用者正在將系統安裝在這類網站中。(真實的品質屬性是完成度或可用性。)
這類方法的好處是它會將作業放在非常具體的視景中,讓各方都能夠理解。另外,它也容許探測需求的遺漏或缺失,當需求不正式、未寫下或非常籠統而精簡時,尤其如此。缺點是它不會將架構本身視為審查的對象,它只將系統看成一個黑盒,我們只是將一些探測器傳送進去。
實際上,事物並無法如此清晰地分開,我們最後三個方法都會用到一些。
識別問題
發現潛在問題多半是依賴知識和經驗,靠人工來進行判斷。某些失敗型樣會在專案之間重複,以及在組織之間重複。特定的啟發方式可用來彰顯問題區域。核對清單可能很有幫助(稍後提出非常通用的部分),如果有先前的審查結果,也可能很有幫助。
當潛在問題出現時,請擷取它們,用自然的口氣描述它們,不需要指東指西,也沒什麼「在劫難逃」。您可以利用小卡片來協助您設定優先順序、組織、刪除,如同 AT&T 審查人員一樣,也如同我們在用 CRC 卡。
稍後,請依照遞減的範圍或影響來排序候選問題,如果數量很多,請先處理與手邊問題直接相關的部分,如果時間允許,稍後再處理「其他建議」。之後,再確認問題的真實性:我們有時會感覺到一個問題,但它可能不是問題。我們只是沒找對人說話,沒看到正確的資訊。重新整理一下。請確定多個資料點來驗證問題的真正性。(經驗不足的評量者可能會過於單線思考。)
確認問題之後,請儘快檢查消除問題的方式,不一定要試著即時重新設計系統。請寫下可能的簡化、重複使用和選擇方案(如購買和建置)。
|