從開發角色看「兩地分工」開發流程
（縮略圖，點擊圖片鏈接看原圖）圖、從開發角色看「兩地分工」開發流程

關於專案經理與架構師

專案經理(Projct Manager)負責整個專案的資源統籌、時程控管、專案 Review 會議、開發各角色人員的協調等。關於專案經理，視專案的規模與性質等，可由 IT 部門的開發主管擔任，或亦可委外給專業的專案控管中心(Project Center)來負責。

而架構師(Architect)，要能具規劃整體架構(architecture)的能力，包括建立架構觀點的模型(請參考 “最佳實務—以架構為中心” 內容)，將架構的概念得以具體化呈現，也就是用大家都能同意的方式來呈現架構，讓架構變成具體的東西，可以系統化傳達、審查、加註和改善(一般而言，在系統規劃初期，架構師為了讓大家對未來開發的模式與技術等有概念，會以原型(prototype)的實作來作為架構的解釋與驗證(POC, proof of concepts))。同時，架構師也能懂得如何將抽象設計的那一面，與現實在專案上要使用的平台技術能相結合，所以架構師也需要瞭解高階設計、平台設計與程式實作等知識、技能與技術(只是，架構師一般以 “Mentor” 的角色來輔導，而不作量化重覆性的工作)。因為架構師需要瞭解 “純” 軟體相關太多的議題，包括抽象與實作，一般而言，會委外交給專職的軟體顧問公司來負責，例如，在國外，軟體界的大師 “Martin Fowler”，即創立這一類型的專業顧問公司(名為 ThoughtWorks)。尤其隨著專案的複雜度與系統整合的整體架構規劃考量等，專職的架構規劃與顧問公司，更形有其必要性。

「兩地分工」的開發者角色

上圖係以主要開發的角色，來看「兩地分工」的開發流程，與角色之間所需傳遞的主要設計產出。當 ISV(Independent Software Vendor) 在未來以 "軟體設計中心(Design Center)" 為事業開發的核心時，兩個最主要的角色：需求分析師(RA, Requirement analyst)、結構分析/設計師 (SA/SD, Structure Analyst/Designer)。

RA 負責蒐集與紀錄源自於客戶單位的需求，包括與領域專家(Doamin Expert)溝通後，所得出的整體性、精要性的企業流程(Business Process)與企業規則、邏輯等；而與未來資訊系統的操作使用者(Operator)，所訪談的需求記錄，會比較是偏於局部性的表單流程與功能。

RA 負責整理並過濾有效的需求，據此而建構出能有效表達資訊系統功能觀點的使用案例模型(Use Case Model)，包括使用案例圖與使用案例敘述 ＊註＊。第二步則是 SA/SD 需要 “實現(Realize)” 使用案例圖中的每一個使用案例，即代表著可以被計量的系統功能單位(Functional point)，SA/SD 主要的工作即在於，需要分析出系統的內部，在動態執行期間，會由那些物件的參與，來完成一個個使用案例的任務(實現系統功能)。找出物件、據個別物件的特性來作分類，然後賦予物件的責任，設計出實現使用案例的物件合作圖。這些工作由於已牽涉到系統的內部，一般稱之為 “系統的結構分析與設計”。SA/SD 的主要設計產出有：靜態結構的類別圖(Class Diagram)，同時連帶產出表達資料庫的 “E-R 圖(Entity-Relationship)”、動態物件合作的循序圖(Sequence Diagram)。因為這些設計圖是偏向表達高階、較抽象的軟體設計觀點，而與實體平台的技術沒有絕對關連，一般稱之該階段的設計產出為 “PIM(Platform Independent Model)”。

＊註＊
由於使用案例圖會需要界定系統範圍(System Boundary)，以及找出誰會來使用該系統的主要參與者(Primary Actor)，與該系統是否需要其它系統的服務(Supporting Actor)。一般而言，這已屬於架構設計的範疇，所以最好由架構師與 RA 共同參與規劃與需求分析，比較能得到表達使用案例圖的架構全貌(由 Architect 負責)，以及個別使用案例的需求記錄(由 RA 負責)。

依「兩地分工」的開發模式，下一步驟即是將 SA/SD 的PIM 設計產出，交付給 “Coding Center” 的 “Technical Designer”，依其設計圖的規範，然後將系統面的考量加入到設計之中，並且擔任Programmer的監工。因此，“Technical Designer” 的工作並非屬於整體系統架構面的工作，相反地，“Technical Designer” 的工作主要是針對某一個特定的功能(也就是單一使用案例)進行細部的設計。加入跟平台面相關的元件資訊，讓 SA/SD 的設計可以實際交付給Programmer照圖施工，因此，“Technical Designer” 的設計和平台面的知識有絕對的關係。例如，若實作的系統平台為 Java/Spring 的平台，那麼，“Technical Designer” 在進行設計之前，就必須要先瞭解有關 J2EE 平台的相關技術。“Technical Designer” 的主要產出仍是有類別圖、循序圖與資料庫的 “Table Schema”，與 SA/SD 設計產出較不一樣的是，本階段的設計產出，已與平台的技術有直接關連，所以一般稱之為 “PSM(Platform Specific Model)”。

「兩地分工」成敗最主要的關鍵即在於 SA/SD 與 Technical Designer 之間，是否能達成有效順暢的溝通。一般而言，在專案開發啟始(Initial)階段，架構師會 “調和” 兩者之間的設計產出與其規範，使之不會違背整體架構設計，同時會確認 SA/SD 在實現使用案例的設計框架，未來得以順暢地移轉給 “Technical Designer (以下簡稱 TD)” 作平台的細部設計，並且會協助檢視 “TD” 的設計回饋，是否有違背 SA/SD 的結構設計。通常，Architect 會引導示範幾個兩者之間設計產出的案例，藉由早期謀和的過程中，把其中的風險因子降到最低，且能建立起兩者之間溝通的橋樑。

當 TD 的設計經驗證許可後，就準備移轉至實做階段開始程式設計。TD 除了將其產出交付給 Programmer，若 Programmer 尚未與 TD 取得足夠的溝通默契，TD 尚須考量實做面的諸多問題，例如 “Coding Style”，提供程式碼的範例及規範；”Code Generation”，如何使用 Modeling 的工具(如 RSA)來產生程式碼框架。若 Programmer 是比較資淺的，可能對 3-tier 平台之間物件的呼叫並不熟悉，TD 甚至必須親自撰寫原型程式(Prototype)並說明其程式的架構是如何表達的。

TD 的角色，可能比較接近傳統所謂的 CTO(Chief Technology Officer)角色。在單一的系統之內，系統內部的細節性的技術問題，TD 均必須有一定程度的素養。