作業: 審查架構
這項作業定義何時及如何處理架構審查,以及如何處理審查發現項目。
目的
  • 發現排程或預算中任何不明或已知的風險。
  • 偵測出任何架構上的設計缺失。我們已知架構缺失最難以修正,它終究最容易帶來損害。
  • 偵測需求和架構之間潛在的不符:設計過當、需求不切實際,或遺漏需求。尤其是,評量可能會檢查作業、管理和維護等區域可能會忽略的面向。系統如何安裝? 如何更新? 我們如何轉換目前的資料庫?
  • 預估一或多項特定架構品質:效能、可靠性、可修正性、安全等。
  • 識別重複使用的機會。
關係
角色主要: 其他的: 協助:
輸入強制: 選用: 外部:
輸出
步驟
一般建議
目的 各次審查的一般建議。

從 20,000 英尺高空往下看,軟體架構評量與任何其他評量或審查並沒有太大不同。

不過,軟體架構的一個重要特性是沒有許多架構品質屬性方面的特定測量,只有少數架構品質會有客觀的測量。效能便是一個可測量的範例。其他品質則比較是在特性方面,或比較主觀:例如概念的完整性。另外,當缺少可供比較的資料或參照時,通常很難決定測量值代表什麼。如果有可用的參考系統,且目標聽眾瞭解它,相對於這個參考系統來表示某些審查結果,通常會很方便。當正在設計的系統可以對照較早的設計時,就可能出現這個情況。

當在進行這項評量的生命週期中,它的用途或效益也會受到影響。

專案生命週期反覆圖

  1. 在起始開發週期初始階段結束時,通常會有些現成的具體架構。但審查可能會發現某些目標不現實、遺漏某些片段、遺漏重複使用現有產品的機會等。
  2. 軟體架構評量最自然的位置是在詳述階段結束之時。這個階段的焦點主要在詳細探索需求,以及設定架構的基準線。RUP 是在這個里程碑上委託進行架構審查。這便是會檢查大範圍架構品質的情況。
  3. 焦點更加集中的評量可能在建構期間進行,以便檢查特定的品質屬性,例如效能或安全,也可能在建構階段結束之時,針對任何可能使產品不適合交到使用者手上的殘留問題,進行這些評量。
  4. 當事物真正出錯時,可以在建構階段的後期,甚至在轉換階段,進行損壞控制評量:例如建構未完成,或轉換期間在安裝基礎上出現無法接受的問題層次。
  5. 最後,還可以在轉換階段結束時進行評量,特別是用來庫存最後的新產品或演化週期的可重複使用資產。

「同層級」的審查人員會有與軟體架構師角色相同的人員配置設定檔,不過,焦點更加集中在技術問題上。領導能力、成熟度、實用主義以及結果導向的重要性程度較低,但也仍然重要:如果架構問題威脅到專案的排程,審查人員可彰顯這些可能令人討厭的架構問題。重要問題仍然最好在能夠解決之時及早提出,而不要盲目遵循排程,使專案小組最後走上錯誤的道路。架構審查人員必須在風險和成本之間取得平衡,且必須維持關於順利完成專案之廣泛問題的敏感性。另外,架構審查人員也必須是能夠提出和討論敏感問題的有說服力的傳播者。

建議的審查會議
目的 定義審查的範圍和目標。
定義每項特定的範圍/目標組合所用的方法。 

您可以利用各種不同的方法來進行審查:

  • 表示法驅動
  • 資訊驅動
  • 情境驅動
表示法驅動審查

請取得(或建置)架構的表示法,再根據這個表示法來提出問題和原因。

您可能面對各種不同的狀況,從架構程度很高、能夠提供非常清晰的說明來作為起點的組織,到您必須識別誰是軟體架構師(甚至是隱藏在其他名稱之下),且必須從他取得資訊的組織,以至於完全沒有軟體架構概念的情況,都可能存在。因此,這個流程稱為「架構採礦」,而且現實看起來就如同字面的意思:利用尖鋤從軟體或文件中挖掘它、查看程式碼、介面、配置資料等。

軟體架構文件中所呈現的架構視圖格式,便是一種可用來組織表示法的模型:邏輯視圖用來組織主要類別(物件模型)、流程視圖用來說明主要控制緒及其通訊方式、開發視圖用來顯示各個子系統及其相依性、實體視圖用來說明其他視圖的元素到一或多個實體配置的對映。請沿著各種視圖來組織問題。

資訊驅動審查

請建立推理所需要的資訊(資料、測量)清單,取得資訊,再比較這項資訊和需求或某些已接受的參照標準。這也適合用來探索特定品質屬性,例如屬性或健全程度。

情境驅動審查

這是系統性的「假設」方法。請將所提出的一般問題轉換成系統應該經歷的情境,再根據這些情境來提出問題。這些情境的範例如下:

  • 系統在 X 和 Y 平台上執行。(所探測的真正品質屬性是可攜性。)
  • 系統執行這個(附加的)F 函數。(真正的品質屬性是可延伸性。)
  • 系統每小時處理 200 個要求。(真實的品質屬性是延展性。)
  • 使用者正在將系統安裝在這類網站中。(真實的品質屬性是完成度或可用性。)

這類方法的好處是它會將作業放在非常具體的視景中,讓各方都能夠理解。另外,它也容許探測需求的遺漏或缺失,當需求不正式、未寫下或非常籠統而精簡時,尤其如此。缺點是它不會將架構本身視為審查的對象,它只將系統看成一個黑盒,我們只是將一些探測器傳送進去。

實際上,事物並無法如此清晰地分開,我們最後三個方法都會用到一些。

識別問題

發現潛在問題多半是依賴知識和經驗,靠人工來進行判斷。某些失敗型樣會在專案之間重複,以及在組織之間重複。特定的啟發方式可用來彰顯問題區域。核對清單可能很有幫助(稍後提出非常通用的部分),如果有先前的審查結果,也可能很有幫助。

潛在問題出現時,請擷取它們,用自然的口氣描述它們,不需要指東指西,也沒什麼「在劫難逃」。您可以利用小卡片來協助您設定優先順序、組織、刪除,如同 AT&T 審查人員一樣,也如同我們在用 CRC 卡。

稍後,請依照遞減的範圍或影響來排序候選問題,如果數量很多,請先處理與手邊問題直接相關的部分,如果時間允許,稍後再處理「其他建議」。之後,再確認問題的真實性:我們有時會感覺到一個問題,但它可能不是問題。我們只是沒找對人說話,沒看到正確的資訊。重新整理一下。請確定多個資料點來驗證問題的真正性。(經驗不足的評量者可能會過於單線思考。)

確認問題之後,請儘快檢查消除問題的方式,不一定要試著即時重新設計系統。請寫下可能的簡化、重複使用和選擇方案(如購買和建置)。

配置問題解決責任
目的 採取行動來處理所識別的問題。 

在審查之後,請配置所識別的各項問題的責任。這裡的「責任」可能不是修正問題,而是指協調探索其他選擇方案,如果範圍非常廣泛,則是指協調解決問題。



內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊