軟件架構師的職責范圍談
上一篇《軟件架構師之基本素質》講述了做為一名合格的架構師應該具備哪些基本條件。當我們具備了這些條件的時候就可以選擇成為架構師了。這時候我們就應該知道軟件架構師應該做些什么，不應該做些什么，也就是軟件架構師的職責范圍。
由于國內外軟件土壤差別巨大，適合國外的一些理論在國內不一定行的通，而國內的一些資料往往都是根據國外的資料直接搬過來用的，這也直接導致國外的軟件架構師在國內變得水土不服。今天本篇隨筆的內容則是在一些培訓資料的基礎上，加上自己的思考，總結出來的適合國情的軟件架構師職責范圍。
1，需求整理分析
有人認為架構師是在需求規格說明書完成后介入的，但我認為架構師要從項目最開始的階段就參與進來。理由有很多：首先，第一手的信息損失最少，架構師能夠更好的把握需求；其次，分析人員在與客戶交流時，往往不會深入挖掘需求，因為有很多隱藏的需求客戶自己都不見得意識的到，而架構師則可以依靠敏感的軟件嗅覺發現這些需求，減少以后的變數；第三，分析人員往往脫離開發團隊，盲目接受客戶需求，而架構師能夠清楚把握現有的研發團隊能做什么，不能做什么，提前預知風險，降低項目失敗的機率。
2，系統分解
在收集完信息后，架構師需要將用戶需求轉化為軟件需求，同時要補充非業務需求，如健壯性，擴展性等等。如何區分和化解用戶需求與軟件需求，如何有效把握用戶需求與軟件需求的區別，是系統分解的核心。這是最考驗架構師的地方，也是只有架構師參與的工作。
3，技術選型
這一步要根據對軟件需求決定項目該使用何種架構，開發模型，及依賴選項。如使用多層架構還是分布式架構，是瀑布模型還是RUP，是使用MySQL還是SQLServer，是否需要使用企業庫，是否需要使用ORM。但是，架構師對項目的技術選型要提供多種不同的方案，并為每種不同方案提供詳細說明文檔，用來闡述每種方案的優勢，劣勢，可行性等內容。這些文檔供項目經理或領導決策最終的技術選型。
4，系統設計
依據軟件需求和技術選型，架構師需要和軟件工程師一起將軟件需求落實到軟件詳細設計說明書中。架構師負責將軟件需求分解，重組織為子項目，子系統，組件和模塊，以及它們之間的邏輯關系，從而形成不同的邏輯組成部分，最后還需要確定各個子系統及組件間的接口。這些都是作為進一步的團隊分工的依據。同系統分解一樣，系統設計是考驗架構師能力的重要職責。
5，培訓與指導
在軟件詳細設計說明書完成后，為保證項目的順利進行，架構師需要對整個團隊進行技術培訓，讓團隊中的每個人明白自己的職責范圍，該做什么，不該做什么。在項目實施過程中，架構師需要參與到具體開發過程中，給與每個開發人員有效指導，以避免團隊成員對系統設計的誤解而造成項目的延誤。在我看來，這點對于新手比較多的團隊尤為重要。因為國內新手的一個通病是眼高手低，剛學會了一點點就認為自己什么都會；當他們拿到真正的設計時又往往不知所措，畏首畏尾。
6，保持溝通
溝通是保證項目順利開展的有效保障。架構師要從多方面跟蹤項目進度，及時與項目經理或直屬領導匯報項目進展，與技術開發人員溝通遇到的問題，如果是迭代開發，還需要與用戶溝通需求變更。
原文標題：軟件架構師之職責范圍
鏈接：http://www.cnblogs.com/niyw/archive/2010/08/04/1792597.html
【編輯推薦】
