【書摘】關於專案與專案管理

軟體系統的開發,絕大部分是以專案(Project)的型態來進行的,那麼, “專案” 到底是什麼呢? 個人從 「Fundamentals of Project Management」 一書中,節錄對其專案一詞的定義:
“專案是指在一次性的工作中,必須同時完成成效、時間、成本以及範疇等,多重任務要求的工作。”

然後,著名的品管大師 J. M. Juran 更是精簡扼要地點出專案的定義:
“專案是為了解決問題所排定的進度表」。”

而專案的規範,主要有四項要素的考量: 成本、規模、時程與品質。此四項要素,取其英文的頭字語,稱之為 “PCTS (performance, cost, time, scope)。而在「eXtreme Programming explained」一書,XP 製程的開山祖師 Kent-Beck,更是對其這四個變數,探討在這些變數之間的互動,來找出比較容易控制的因子,進而建立起某種模式的軟體開發心法。嗯,這裡直接先說出結論, Kent-Beck 認為 “控制規模” 可說是最有用的因子。

再回頭來看什麼是 “專案管理 (Project Management)”?
“為了要達到專案目標,將相關的所有計畫、進度以及控管等行動,使之順暢地銜接起來,就是專案管理。”

專案管理的首要原則是: 一定要讓未來會牽涉到專案實際作業的人,一起參與專案的計畫工作。

所以,專案經理(Project Manager, PM)所扮演的角色,會是一個專案的啟動者(enabler)。當成員(member)有人缺少資源時,要幫他們找到;當有外力介入,會阻礙到他們的作業時,專案經理也要能居間緩衝,減少外力衝擊。嘿,個人的想法與其對 PM 角色的定位,完全不謀而合! 個人一直認為,PM 就是屬於 “資源提供者與協調者 (Resource Supporter and Coordinator)”,他不是用 “管” 的方式,或是用 “工具”、”一套標準製程” 、還是僅排進度如此而已的方式來帶領團隊。專案成員,要的是領導者,而不是暴君或是紙上作業的幕僚。而領導者,會使成員「想」去做這些事,而不是只想「做完」事情。

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

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

關於專案經理與架構師

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

利用 UML 類別圖表達 CMMI Content 與範例說明

關於 CMMI

  • 與其說 CMMI 是流程框架(Process Framework),倒不如說 CMMI 是目標框架(Objective Framework)。
  • CMMI 是以 “流程區域(Process Area)” 為主要完成目標。無論是以 “Continuous” 或 “Staged” 的途徑(approach),均以 “Process Area” 為單位,來檢驗 “軟體能力” 的成熟度。
  • Ex. “需求管理(Requirement Management)” 為一個 “Process Area”,是 CMMI level 2 必須完成的主要目標。(level 2 需完成 7 個主要的 “Process Area”;level 3 需完成 14 個”)。
  • 每一個 “流程區域” 會細分為多個子目標。若該子目標只對應單一的流程區域,稱為 “特定目標(Specific goal)”;若子目標會涵跨多個流程區域,則稱為 “一般目標(Generic goal)”。
  • 每一個特定目標/一般目標會列出一到多個 “期望(expected)” 的特定實務(specific-practice, sp)/一般實務(generic-practice, gp)。實務為一段陳述(statement),表達了完成子目標時的作法。
  • 實務並非為絕對、唯一達成子目標的唯一作法,它是 CMMI 建議、期望的作法,但仍可就現實狀況來找出 “自己” 的的實務作法,重點是,能達成(achieve)子目標(GG/SG)的規範與要求。
  • 既然實務僅為敘述性的陳述,可以把它視為是 “抽象(abstract)” 的 “How-to”,要能找出符合實務的作法,可以從主流軟體開發流程,如 RUP/Agile/XP 等,找出實踐的具體手段。

CMMI 的 Model Content 為:Process Area, GG/SG, GP/SP。其中,Process Area 與 GG/SG 為達成軟體能力成熟度的必要元件(required component);GP/SP 則為 "期望(expected)" 的元件,屬建議性,並非絕對需要。若以 UML 類別圖表達 CMMI Content 之間的關連,如下圖1 表示。

利用UML 類別圖表達 CMMI Content 之間的關連

圖1、範例-利用 RUP/XP 方法論實現 Requirement Development -> SG3

CMMI Content 類別圖說明:

  • CMMI Level (2~5) 包含(aggregate) 多個“流程區域(Process Area)”。
  • 每一個流程區域會包含多個子目標(Goal),子目標依性質區分為“一般目標(Generic Goal, GG)”與“特定目標(Specific Goal, SG)”。
  • 將 GG/SG 設計為“Interface”的意涵在於,任一個具體(concrete)的實務(practice)類別,只要符合該子目標的介面規範即可,也就是說,CMMI 不規定“how-to”,只要能確實達成(achieve)子目標的規範即可。
  • GP/SP 可視為是“抽象(abstract)”的“how-to”陳述(statement),因此,具體實務類別也可以依循 GP/SP 內的陳述來具體實現。

閱讀全文 »

論 3P (Project, Package, Product)

國內從事 “企業(Enterprise)” 軟體的獨立開發廠商(ISV),大致可以分為三種營利的模式:

  • Project (專案)。
  • Package (套件)。
  • Product (產品)。

算起來,應該約有 80% 以上的開發廠商是以專案開發為主的(Project-based)。專案,顧名思義,會偏以滿足單一任務的工作性質,服務的對象也偏以單一的客戶為主,目的就在於能達成客戶對資訊系統的期望,而這些期望,也就是系統所提供的服務與功能—軟體開發廠商所負責承諾來實現,並換取實質的回饋報酬。

我們都知道,最為難的就是如何能滿足客戶的期望,因為,客戶的期望一直在變;又,競爭的因素,專案性質的資訊系統開發總是被要求在最短的時間,以最少的成本來完成,自然,種種不合理的要求,品質當然也就不佳。

請記得,開發端與客戶端是要能達成一種實質交易上的平衡,而開發端投入許多的心力與人力,來服務單一的客戶,卻換取開發端認為不合理的報酬,當然這種交易的結果也就無法讓雙方都能協調滿意的了。

只賣給一家客戶,即使開發 ERP 系統拿到 200 萬元,開發端都還認為是慘賠,因為人月的實質負擔實在不敷成本。一般專案性質的軟體開發總是存在一個根本問題:無法達成軟體的大量複製!

專案的規模除非夠 “肥”、專業領域夠 “精”,否則,對開發與客戶端都很難取得實質交易的平衡。我還記得,閱讀 XP (Extreme Programming) 的書籍,Kent beck,軟體業界的大師,所涉及參與的專案,諸如航空班機的控管系統,開發預算都是高達數千萬、數億美金以上,開發的週期要高達好幾年以上 …。我覺得,若要開發專案,作這種才有機會有實質的回饋、人生也會活得比較有成就感吧?

ERP 系統可否大量複製呢? 嗯,我們在世貿軟體展,可以看到國內許多的軟體廠商展出 ERP 系統的產品,可真便宜,數千至數萬就可以買到了。站在該軟體廠商的角度,活用軟體的大量複製,方向是對的,如此才有可能將成本壓低,才能服務眾多需要的客戶,售價自然也就可以大幅降低了。只可惜,這些 ERP 系統實在不能稱為產品(Product),最多最多,只能稱為套件(Package)而已。

套件與產品如何區別? 每一次我到軟體展時,遇到漂亮的展售小姐解說 ERP 功能時,我只會問一個問題:可不可以將 SQL Server 換成 MySQL? 幾乎一致的回答是不行。我還只是問實體平台的變更而已喔,還沒有問到,若我要求某一個 ERP 系統所沒有的功能或需要變更業務流程時,該如何客製化(Customize)呢?這問題我連問根本也不想問,因為可想而知,作不到!

套件的特性是,它提供了預先定義好的功能(pre-defined)給客戶,然後利用 “參數(parameters)”,讓客戶來自行 “微調” 系統功能;若是客戶單位要求的是套件沒有的功能、企業規則或企業流程的話,當然就要找原開發廠商,然後回到 “專案” 的型態來開發新的功能。

專案要作的是滿足客戶的需求,但期望客戶的需求變動不要太頻繁;套件則是提供預先定義好的需求給客戶,但其假設點是客戶的要求不多、規模不大(這也就是國內的 ERP 廠商的客戶鎖定在中小企業的原因)。兩者的根本問題是:彈性度不足,無法提供 Enterprise 層級的資訊系統,有效的客製化與變動性管理!

那麼,該具備什麼樣的特性才 “夠格” 稱之為 “產品(Product)” 呢? 答案就是理出專案與套件的共同問題:讓系統更有彈性!

為什麼客戶端需要更換資料庫系統與應用伺服平台? 因為成本、效能、穩定性等考量。
為什麼客戶端需要客製化? 因為需求就是一直持續性地變動。

即使有領域專家的協助、即使有超炫的使用者介面、即使提供的是更棒更完善的功能,這些仍是沒有用的,因為,客戶永遠都會有第 101 個意想不到的需求!

既然如此,就乾脆讓客戶端可以自行開發他們的需求,未嘗不可! 學學 MS 的 .NET Framework、Java 陣營的 J2EE Framework,以上兩者提供的是作業系統層級的框架(System-level frameworks),而開發如 ERP 產品,就是提供企業層級的框架(Business-level frameworks),讓開發者視需求的變動與要求,而在既有的基礎建設(Infrastructure)上,加工快速建置新的功能。

企業層級的 Framework,除了提供共用的資料庫、共用的企業流程,還要能提供白箱的 Open-APIs 與原始碼,以及黑箱的 “企業元件(Business Components)”,來供其客製化客戶單位的功能。難不難? 非常地困難! Business Framework 的設計與開發,需要能結合領域專家、軟體專家、與平台面的 IT 專家,共同合力協助,才有可能完成的。這也是為什麼國外頂級的 PDM((Product Data Management)產品與國內某些軟體公司所開發號稱的 PDM 產品,價格為何能差到數百萬元之多吧。

對了,Open-source 的許多企業層級的專案,可否稱之為產品? 個人是不以為然,還是無法到這樣的層次。但,Open-source 卻靠兩種方式,來達成如同產品的性質:

  • 頻繁的改版。
  • 提供原始程式碼(Source-codes)。

這是一種非常有意思與另類的作法,此時,軟體廠商反而不是賣產品,而改以提供 “服務(services)” 的方式來計價收費了。

從觀點來解釋架構 — Kenming 看架構 <1>

前言:

架構(Architecture)一詞,非常之難解釋。

若真要一言以蔽之,那麼,可以說,”架構” 是一種整體觀,需要保持從各角度看待架構時,仍有一致性與調和的觀點。

對 ”架構” 要能有充分的理解與認識,至少要能確實瞭解與體會下列幾個與架構至為關鍵的意涵與術語,包括了:整體、觀點(View),包括巨(Macro)觀與微(Micro)觀、焦點(Focus)、層次(Layer)、廣度(Boundary)。

擔任軟體架構師(Software Architect)必備的素養,即在於:觀照整體的能力。

經常我在輔導許多軟體公司的專案開發與教育訓練時,發現到與開發團隊對 “架構” 一詞的認知與定義大不相同。我發現到,大部分的 IT 技術開發人員,所表達出來的架構,是比較偏向於實體層次如 .NET, J2EE 的 IT 技術層次。不是不對,而是 IT 實體層次僅是架構的觀點之一,並不足以代表整體的架構觀。

我想試著利用以上述幾個術語來解釋 “架構”。畢竟,架構的設計,牽涉到相關於設計中系統的議題與範圍太廣了,包括:團隊開發的共識、開發流程(Development Process)的制訂,分工與外包(Outsourcing)控管、系統的彈性、延展(Scalibility)與維護性等。

金剛經有云:「凡所有相,皆屬虛妄,見諸相非相,即見如來」。

“相”,是被具化、可以看得到的形,如同軟體模型,是被具化的產出(Artifact),也就是 “相”。而 “如來”,是不著相的,架構即為如來,所以架構也可以說是一種空、無。

問題來了,既然不著相,你又如何知道何為正道,何為如來?
佛教禪宗有個「以指標月」的譬喻:對於一個從不來不知月亮為何物的人,在蒼茫的星空中,不知那一個叫做月亮,這時候就需要一個認識月亮的人,用手指著月亮說:「那就是月亮」。

同樣的道理,你又能如何瞭解甚至來驗證架構(如來)的正確性呢?
有經驗的架構師(Architect),以各種不同的角度(以上所涵蓋的幾個術語),建構各類型的軟體模型,來看待並解釋「架構」。如同「以指標月」一般,對架構有深一層體會的架構師,會以導師(Mentor)的角色,利用各種工具來具化產出,以引導軟體設計師認識「架構」。

所以,UML, 程式碼等只是個標示工具,真正的「架構」是要靠自己去體會的。

觀點(Viewpoint)

我想首先以 “觀點(Viewpoint)” 一詞來解釋架構。

要能具軟體架構的整體與協調性,最起碼要能有三個觀點:

ˇ 需求面的觀點
ˇ 結構面的觀點
ˇ 實做面的觀點

閱讀全文 »

【企業軟體委外】外包程式碼的結構驗收問題

問題陳述—外包程式碼的結構驗收問題

  • 客戶(發包單位)可以透過自動化的功能測試碼來驗證系統功能的正確性,這是屬於系統外觀的驗收範疇。但是,客戶又如何來檢驗外包廠商(承包單位)有依據承包契約(Contract)內的設計藍圖來施工(Coding),確保系統內部的結構(Structure)設計,而不是以沙拉油桶混充建材,偷工減料?

從客戶端的角度來思考對策與解決方案

  • 系統內部結構設計的檢驗重點是什麼?
  • 能利用利器將程式碼反轉(Reverse)成為視覺化的模型,最好就是標準的 UML 圖,而得以方便與快速來作結構的檢驗。
  • 這個利器若能同步反應設計圖與程式碼的變更,那就更理想不過!
  • 因為設計圖與程式碼能透過該利器保持一致性,兩者成為系統的一體兩面:程式碼反應實做;設計圖反應視覺化的模型設計,更因之而能成為標準、實在、確實、非作假的設計產出(Artifacts)文件(Documents)了。

系統結構設計的檢驗核心—相依性分析

  • 兩個元素之間的關係,稱為相依性(Dependency)。
  • A 元件(Component)呼叫(call) B 元件所提供的服務(service),兩者之間構成了相依的關係 — A 相依於 B。
  • A 元件相依於 B 元件,代表當 B 元件變動時,會造成 A 元件的連帶變動。但反之則否(A 元件變動,不會影響到 B 元件)。

範例-A 元件相依於 B 元件
圖、範例-A 元件相依於 B 元件

相依性分析的目的與元素的單位

  • 讓元素之間相依性降低(低耦合性,Low Coupling),變動的影響不大。
  • 相依性分析的元素(或可稱之為元件,Component)單位
    • 類別(Class)
    • 套件(Package)
    • 模組(Module)
    • 子系統(Sub-System)
    • 單一系統
    • 系統與其它系統(如透過 Web Service 介面連接)

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal