作業: 審查設計
這項作業定義如何審查設計,以及如何處理審查發現項目。
目的
  • 確認設計模型符合系統需求,且能夠作為實作的好基礎。
  • 確定在一般設計準則上,設計模型是一致的。
  • 確定設計準則符合目標。
關係
步驟
一般建議
目的 各次審查的一般建議。

「同層級」的審查人員會有與軟體架構師角色相同的人員配置設定檔,不過,焦點更加集中在技術問題上。領導能力、成熟度、實用主體以及結果導向的重要性程度較低,但也仍然重要:如果設計問題威脅到專案的排程,審查人員可彰顯這些可能令人討厭的設計問題。重要問題仍然最好在能夠解決之時及早提出,而不要盲目遵循排程,使專案小組最後走上錯誤的道路。設計審查人員必須在風險和成本之間取得平衡,且必須維持對於順利完成專案之廣泛問題的敏感性。另外,設計審查人員也必須是能夠提出和討論敏感問題的有說服力的通訊家。從技術知識的觀點來看,設計審查人員必須有如同設計者角色的經驗。
審查整體設計模型
目的  確定設計模型的整體架構形式完整。
偵測查看低階元素時所見不到的大範圍品質問題。 


您必須將設計模型當作一個整體來審查,以偵測顯著的分層和責任分割問題。審查整體模型的目的是偵測出更詳細的審查所將遺漏的大範圍問題。

在初始階段及詳述階段的初期,這項審查的焦點在於模型的整體結構,且特別強調分層和介面。您應該檢查套件和子系統相依性來確定套裝元素之間的耦合性鬆散。您應該檢查套件和子系統的內容來確保套裝元素內的高內聚力。一般而言,您應該檢查所有元素來確保它們有清楚而適當的責任,且它們的名稱反映了這些責任。

在至少已開發了架構原型之後,就應該進行更綜合性的設計審查。您應該先針對整體完整性來審查模型,之後,再更小心探索問題。

審查每項設計使用案例實現化
目的 確定系統的行為(如設計使用案例實現化所表示)符合所需要的系統行為(如使用案例所表示),也就是說,它完整嗎?
確定已在模型元素之間適當配置行為,也就是說,它正確嗎? 


審查設計模型結構之後,必須審查模型的行為。首先,請檢查設計使用案例實現化是否完整涵蓋了現行反覆的所有情境,以確保沒有遺漏的行為。在完成的設計使用案例實現化中,必須有相關使用案例子流程中之所有行為的說明。

如果系統行為是事件驅動的行為,您可能是利用狀態圖來說明使用案例的行為。當存在這種行為時,您必須檢查狀態圖來確定它們說明了正確的行為,請參閱技術:狀態圖,以取得詳細資料。在即時系統中,您利用工作成果:通訊協定來說明互動的工作成果:封裝體,您應該檢查它們來看它們是否提供了正確的行為。

之後,請確定設計使用案例實現化的行為正確分佈在實現化的各個模型元素之間:請確定作業的使用正確,傳遞了所有參數,且回覆值的類型正確。

審查每個設計元素
目的  確定設計元素的內部實作會執行它需要的行為。 

每個配置了行為的設計元素(如設計類別或設計子系統)都必須審查內部設計。對於設計子系統而言,這代表確保顯現的介面所指定的行為已配置給一或多個內含的設計元素。對於設計類別,這代表每項作業的說明都有充分的定義,可以明確實作,不會有任何模糊。

審查設計準則
目的 確保與設計相關的特定專案專用準則仍是最新的,以及更正準則中的問題。 


在設計審查的基礎上,找出設計準則中的問題。

  • 遵循準則嗎?如果沒有,為什麼?
  • 它們正確嗎?是否偵測到錯誤準則所引進的系統問題?
  • 它們完整嗎? 如果提供了指引,系統問題會減少嗎?
準備審查記錄以及產生問題的文件
目的 產生審查結果的文件。
確定已產生所識別之問題的文件。 


在每項審查會議之後,會議結果會記錄在審查記錄中。另外,任何問題的記錄都要符合專案的變更管理流程。



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