設計複審

(1)設計複審應該把重點放在系統的總體結構、模塊劃分、內外接口等方面。例如軟件的結構能否滿足需求；結構的形態是否合理；層次是否清晰；模塊的劃分是不是符合優化的原則；系統的人機界面、內外部接口，以及出錯處理是否合理等。

(2)過程設計複審的重點應該放在各個模塊的具體設計上。例如模塊的設計能否滿足其功能與性能要求；選擇的算法與數據結構是否合理，符不符合編碼語言的特點；設計描述是否簡單、清晰等。 ^[1] 

存在着兩種不同的設計複審方法。

(1)正規復審

製作好幻燈片、邀請聽眾按計劃好的議事日程進行正式複審。這種方法是概要設計複審常用的方式。由於參加人員包括各方面的代表，正式複審通常採取正式會議的方式。評審材料一般要提前兩週散發給與會人員，並要求他們在會前送回書面的評審意見。開會時，設計人員會對設計方案的進行詳細説明，答覆與會者的問題，並記下各種重要的評審意見。最後，會議應就會後應採取的糾正與彌補措施，以及要不要重新提交複審等作出決定。

(2)非正規復審

只召集少數設計人員和有關用户參加討論設計問題。這類複審的特點是參加人數少，且均為軟件人員，帶有同行討論的性質，因而方便靈活，十分適合於詳細複審。 ^[1] 

(1)在傳統軟件設計中，概要設計複審和過程設計複審應該分開進行，不允許合併為一次複審。

(2)除軟件開發人員外，概要設計複審必須有用户代表參加，必要時還可邀請有關領域的專家到會。過程設計複審一般不邀請用户和其他領域的代表。

(3)既然複審是為了及早揭露錯誤，參加複審的設計人員應歡迎別人提出批評和建議，不要為設計的缺陷“護短”。但複審的對象是設計文檔，不是設計者本身，其他參加者也應為複審創造和諧的氣氛，防止把複審變成質訊或辯論。

(4)複審中提出的問題應詳細記錄，但不要謀求當場解決。

(5)複審結束前，應做出本次複審能否通過的結論。 ^[1] 

設計複審沒有統一的規範，通常公司或研發團隊根據目標產品的特點自行建立設計複審的形式，審視系統裏特定的組件，清楚表達設計複審的重點。一個設計複審團隊通常包含以下成員：

①複審小組組長：統籌負責協調複審會議之前的準備工作、會議進行以及會後的追蹤工作。

②設計者：他們本身應該最清楚自己所設計的組件。在複審的過程中，他們是被審查的對象，需要報告與解釋為什麼要這樣設計，讓所有參與複審的成員瞭解他們的設計思路。

③複審員：負責研讀系統的需求以及各個組件，審查設計者提供的各種報告。複審員可以來自參與這個產品研發的成員(他們最瞭解產品設計)，同時也必須包括別的研發小組成員，這樣可以從其他角度來審視這個產品設計，找出可能的問題。 ^[2] 

設計複審的標準包括：

(1)易追溯性：該軟件設計包括了軟件需求規格説明的所有要求了嗎?該軟件的每個部件與某個具體的軟件要求有關嗎?

(2)風險：實現該設計會有很大風險嗎?也就是説，沒有技術性的突破該設計也能完成嗎?

(3)實用性：該軟件對軟件要求所確定的問題是一種實用的解決辦法嗎?

(4)易維護性：該設計是否將帶來一個便於維護的系統?

(5)質量：該設計具備一個“好”的軟件應有的質量特徵嗎?

(6)接口：外部和內部的接口已經規定得足夠明確了嗎?

(7)技術清晰度：該設計的表達方式是否使它便於轉化成程序?

(8)選擇方案：考慮了其他設計方案了嗎?採用什麼標準來選擇最後方案呢?

(9)限制：軟件限制是否現實?與要求相符合嗎?

(10)某些具體的問題：該軟件便於人控制機器嗎?便於測試嗎?與其他系統部分相適應嗎?有足夠的文檔嗎? ^[3]