【外包開發與管理】從開發者角色看「兩地分工」開發流程

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

關於專案經理與架構師

專案經理(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 均必須有一定程度的素養。

文章導覽

   

共有 7 則迴響

  1. Hi Patrick:
    看來您其實比較偏向是與 Banking 相關的專業領域(Domain)。 🙂
    其實說真的,UML 比較仍偏向是軟體這邊所專用的模式語言,用來與客戶端這邊溝通,其實不太恰當。

    也謝謝您介紹的書,我會記下來的,若是真的不錯,我會考慮買原版的來看。 ^^

  2. Hi Kenming,

    Thanks for the comment. However UML is not widely used in the bank I work for even thought it is a good tool. I’ve bought the book of your review: Exploring Requirements, Quality before design at beginning of this year. It provides some good hints to my work. The bank I work for doesn’t like much that BA to explore technical Spec. I’ve always been told to focus on business side instead of thinking on Non-functional technical spec from PM. Well, there is still a bit of politics needs to deal with at work place…..

    For BA role, I have a A Guide to the BABOK (Business Analysis Body of Knowledge) book, so feel free to let me know if you are interest to have a copy, I can email it to you. It is free to distribute for helping people who is working in BA role.

  3. Hi Patrick:
    1. 聽您的敘述,與我們現在正在顧問的某家保險業公司的角色規劃還挺類似的。 🙂 另您所提的 BA, 已比較接近是 “domain expert” 的角色了。
    2. “Business Modeling with UML” ,在我的 書評裡有介紹喔。
    3. 您提的見解甚有道理! 再補充一下,太多人把所謂的 “角色(Role)” 與 實際的 “人” 給一對一關連起來了。 其實並非如此,一個人可以擔任多種角色,而明確的角色,是可以清楚在這個角色之內所作的事情職掌是什麼。 ; 另,PM 的角色,其實在我個人諸多的文章內有闡述過,他是比較偏向 “人” 與 “資源” 的調和,這最重要。 要命的是,幾乎我碰過的絕大多數 PM,似乎不是往這個方向,而一味地往所謂的製程與管理來走,這… 我是覺得這絕不會是 “Smart” 的作法。

  4. sorry, just to add comments for Mrmaid:
    Quote:
    就現實環境而言,我想很難作到如此完備的角色分配及流程實踐;
    不知大大在現實生活中經歷過多少案子是這樣完美?
    人力的吃緊,時程的壓迫,客戶的需索無度,不該來的總會來…
    雖然總試著不要一再落入這種惡性循環,可現實總不盡如人意…

    I think it is PM’s responsibility to push back on what is considered out of scope items. Normally, if requirements have been approved and signed off, it serve as a foundation for design phrase. Any change request (CR) will cost your sponsor big time. BA will ensure that requirements have been prioritised (ie. Mandatory, Highly desirable, desirable, noice to have) so when time or funding goes insufficient, PM can negotiate with sponsor to drop some requirements.

  5. I agree. I am currently working on a new credit card product development. Besides PM, we have a system architect to assist us to review the business requirements. As you mention the title “Requirement Analyst”, we normally call it Business Analyst (BA). BA is not just gathering requirements, also assess business impacts and assist in SDLC, govern SIT & UAT and implementation assessment. Your discussion is in the view of high level in role stracture which I’ve found is quite similar to the bank I am working for.

    Do you have any book to recommend for Use Case at business analyst level? Thanks

  6. Hello Mermaid:
    由於我們比較面對的是大型組織的 IT 單位,一般而言,其 IT 人員均有上百位以上之多,所以,所謂的角色擔任,所以細部的角色分配是有的,但,這與角色分配與流程實踐,也實在沒有什麼關係。

    一個所謂「完美」的案子,可不是在完備的角色分配與高度儀式的流程實踐上,有一些更「根本」的地方,那個「根本」,我並不容易在此解釋。

    您後述的問題,那是常態,我們也是在協助這些大型 IT 單位擺脫掉所謂的這種「惡性循環」,如何不要擺脫,如同前述,當通曉了所謂的「根本道理」與現實的假設環境後,大概就知道如何找出應對的方法的。能否一次擺脫這種宿命? 我們是認為,不容易,最好的方式,還是採取漸進、逐步推進的策略與方法,當然,最重要的是,有沒有這種意志力與毅力來克服這種環境的。

    另,回歸主題,這張圖並非是談單一組織的開發團隊,主要的議題在於「外包分工」的角色與其職掌及技能。有興趣,歡迎來我們研討會或者透過公司找我們過去說明,我們很樂意!

  7. 就現實環境而言,我想很難作到如此完備的角色分配及流程實踐;
    不知大大在現實生活中經歷過多少案子是這樣完美?
    人力的吃緊,時程的壓迫,客戶的需索無度,不該來的總會來…
    雖然總試著不要一再落入這種惡性循環,可現實總不盡如人意…

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *