4、召開架構設計評審會議進行同行評審。
架構設計評審是極其重要的一環，我曾將其形容為“七種武器”中的離別鉤，就是因為在會議上，同行們可能會提很多問題或意見，而且很多意見很尖銳，所以一定要虛心接受，并做好記錄，正所謂“良藥苦口利于病，忠言逆耳利于行”。
在評審會議之前，我們要完成很多準備工作，最好是能準備一份簡明扼要的電子簡報，把最重要的問題列出來，這樣在進行評審會議時，就不會漫無目的，在會議前就將這些資料發給與會人員，請他們抽空先了解一下，在會議進行時，要學會控制會議的進度，提高會議的效率。
5、針對關鍵Use case在設計的架構上實現功能來驗證架構。
對于架構設計的驗證也是一項十分重要的工作，其驗證技術有很多種，在我們公司通常會采用Sample的形式，即XP中所說的迭代0，RUP中所說的切片。這樣做的好處是既可以從實際的產品角度出發來有效的驗證架構是否滿足要求，又可以比拋棄型原型驗證技術節省成本。
這個Sample絕不是我們在解決架構設計中的問題時拿來做實驗的一些代碼的拼湊，而是完整的實現某一關鍵Use case的符合架構設計和一系列規范的可交付的代碼及相關文檔。同時，這個Sample可以作為你在給大家講解或培訓架構時的教材，也可以作為開發人員使用此架構進行開發的藍本，甚至是只需要復制粘貼，加上簡單的修改即可。
6、 交付給客戶Review。
這一環節，在很多公司可能并不存在，因為他們的軟件架構并不一定需要客戶Review，但像我們這種做服務的公司，最重要的就是客尊，落實到軟件架構設計這一活動，就是讓客戶理解并接受你的架構設計方案，同時，客戶也會起到幫你驗證架構的作用。通常，我們的架構得到客戶的認可后，便可進入大規模的開發。
在交付給客戶Review時，通�？赡軙詴h的形式進行Review，所以我們可以參照評審會議時好的做法來召開會議，在這里就不再冗述。
軟件架構設計的常見誤區及解決辦法
文章來源于領測軟件測試網 http://www.kjueaiud.com/
