什麼是configuration management光就譯名，Configuration Management這在台灣有人翻譯成建構管理、組態管理、構型管理、或稱之為型態管理；在大陸則稱為配置管理。Configuration Management這個管理作業，因為台灣專案管理環境尚未成熟使然，常常使得光看字意而缺乏實際運作經驗的人很難瞭解其中的要義，或者與version control很難界分清楚。
本周的第十五章型態管理，因為焜安同學有事未能與課故由老師代打，老師在課堂直接就指出現實環境中因為軟體專案的成本與期限壓力，台灣地區甚少有軟體公司會於專案團隊中安排專門的Configuration Management人員與工具，加以Configuration Management也會增加程式開發人員開發作業的複雜度，因此一般有規模的公司也僅僅是作到版本控管(version control)。接續報告的子嵐同學因為並未實際接觸到軟體的開發與維護，因此對於此部分有著些許的陌生。幸而代興同學於銀行的資訊單位工作，無私的與大家分享了銀行在資訊系統的維護或者建構上，對於系統維護與變更的流程規定與實際經驗，其中從需求的提出到確認，以及程式變更的分析、申請、測試與上線都有著一套秩序井然的規定。
說實話，肥蝦也是身處在台灣的軟體產業之中，雖然也”呆”過使用單位，但對於Configuration Management也是僅有初淺的認識，尤其是對應到PMI所出版的”Practice Standard for Project Configuration Management”這一本內文僅有26頁，加上附錄也才共51頁的手冊，更是顯得所知有限，在此就只能以管窺天的向大家報告肥蝦的認知與心得，還請 先進們不吝指正。
(一)型態管理的標準定義
在PMBOK的第三版與第四版中，就Configuration 這個字眼的落點處主要在Enterprise Environment Factors中的PMIS(Project Management Information System)、Organizational Process Assets中Organizational corporate knowledge base、第四章整合管理、第五章範疇管理，以及第八章
肥蝦對於【軟體專案管理】第十五章開頭列示美國國防部對於型態項目(以下為方便暨與書本一致起見，將Configuration統稱為型態)，以及IEEE對於型態管理的說明描述實在是不太認同，不認同的原因是型態項目說：「軟體或硬體的組合元件能夠滿足使用者的需求，而且能夠應用在型態管理上之用途者。」而型態管理定義為：「在整個軟體生命週期中，針對型態項目予以定義與控制各種變更、記錄與報告型態項目的實際狀況，以確保其整體性(Integrity)與可追蹤性(Tractability)的管理過程。」如此把型態項目的說明推到說是要能夠應用在型態管理上之用途；型態管理又說是針對型態項目，那到底什麼是型態？什麼又是型態管理？ 對於僅有接觸過版本管理、變更管理，而沒有實際執行過完整型態管理的肥蝦來說，這些說明實在是更令人感到玄上加玄。
(二)從軟體開發遭遇到的問題看型態管理的定義
因此肥蝦建議，我們從實務現狀中，去瞭解現在一般在開發專案之時容易碰到的問題，也許對於型態管理會有一番不同的體會。肥蝦把我【軟體專案管理】與”軟件項目管理案例教程”中對於軟體開發工作碰到屬於型態管理可協助改善的問題整理如下表：
| 項次 | 問題 | 出處 |
| 1 | 多人同時更新某一個軟體。 | 【軟體專案管理】 |
| 2 | 多人共用一個程式碼，部分程式已被更新，但是仍然有些人不知程式內容已經更新。 | 【軟體專案管理】 |
| 3 | 使用的版本不一致。 | 【軟體專案管理】 |
| 4 | 發現程式的錯誤原因，無法有效通知相關的人員。 | 【軟體專案管理】 |
| 5 | 許多設計人員原本可以共用一支程式，但是設計者卻自行開發相同的程式。 | 【軟體專案管理】 |
| 6 | 找不到某個文件的歷史版本。 | ”軟件項目管理案例教程” |
| 7 | 開發人員使用錯誤的版本修改程式碼或文件。 | ”軟件項目管理案例教程” |
| 8 | 開發人員未經授權修改程式碼或文件，或修改的結果不能及時反應到各個相關部分，導致研發過程不一致。 | ”軟件項目管理案例教程” |
| 9 | 人員流動，交接工作不徹底造成關鍵程式遺失。 | ”軟件項目管理案例教程” |
| 10 | 已修復的錯誤在新版本中出現。 | ”軟件項目管理案例教程” |
| 11 | 沒有保存歷史版本的相關文件，無法重新編譯歷史版本。 | ”軟件項目管理案例教程” |
| 12 | 因協同開發或者異地研發，版本變更混亂。 | ”軟件項目管理案例教程” |
肥蝦綜合以上的問題，自大的定義了一個針對型態項目的定義：「從專案開始到專案結束之間所有專案進行的文件、開發環境、開發流程、開發工具、程式碼、界面、產出，攸關軟體專案完成的一切要項。」在不考慮多人共同開發之下，就比如由您一人獨挑大樑，從老闆或業務簽下合約開始，到交付出產出，這一連串過程中所要的需求訪談、確認、評估，決定平台、架構、模組元件等設計，工作分派與時程基準，開發過程的溝通記錄，會議與追蹤稽核的記錄，程式與變數的命名規則，程式的版本、品質管控，後續的單元、整合、系統、驗收測試案例與結果，這以上的種種一切有關於專案都應該加以控管；但是一個專案經理或管理團隊，應就公司與客戶的環境與文化、專案成本與時程負擔、專案成敗關鍵等內外在因素進行取捨，就是要於型態管理之前要先行確認型態項目。換言之，就是要先確認專案開發中有哪些要項是在攸關專案成功的！我們所必要與利害關係人溝通的！必須保有正確性、完整性、可見性、協調性、可歸責性、可追蹤性、可重複性、可回溯性、與可控制性的重要項目！
【圖一】
參考【軟體專案管理】圖15.1所繪的軟體開發程序，肥蝦把從硬體需求分析到硬體型態項目測試的硬體型態項目發展過程曲線移除，因為硬體型態項目，也應從系統分析需求中的非功能需求開始管控起。因此從系統需求分析到安裝的過程中，都應該有必須被列為型態項目的重要元素。
為了達成專案目標，確保專案努力的成果與方向的正確性，對於認定為型態項目要特別在意變更管理的提出、評估、確認、修改、測試與釋出過程的一致性與充分性，因此對於型態項目現今的狀態，變更的管理，都要能確實的掌控，因此肥蝦以為應該參考”Practice Standard for Project Configuration Management”加上型態管理規劃。何為？因為要確認何種項目為型態要項，型態項目的命名規則，型態變更的流程，型態檢測的頻率與指標，型態項目的存放實體與位置等這一切，應該要有一個先視、全面觀的計畫。因此【軟體專案管理】圖15.1型態項目的管理工作肥蝦修改後繪製如【圖二】。
至於專案管理、專案型態管理與專案變更管理，三者之間的範圍與相關性，可以【圖三】表示：
上圖正說明了PMBOK第三版(2004)把型態管理系統(Configuration Management Sysytem)與變更管理系統(Change Control System)納進於專案管理資訊系統(Project Management Information System)之內的原因。
雖說廣意的專案型態管理工具應該包含型態管理系統，但說實話，也可能肥蝦的經驗有限，目前市場上主流的專案管理資訊系統對這一塊均是非常Weak甚至付之闕如。現行實務上，大多使用CVS作為版本管控與文件的管控，【軟體專案管理】書本上所提到的Rational ClearCase因為要價不菲，除非身為IBM的協力夥伴，不然甚少使用；就像那微軟的協力廠商多用Visual SourceSafe一樣。現在已有把專案管理、軟體開發與版本管理整合的趨勢，就如微軟所提出Visual Studio 2010藍圖一樣，這麼的宏大，但是價格也跟這【圖四】藍圖一樣的偉大。
(三)產品型態管理與專案型態管理
最後，肥蝦要進一步說明產品型態管理與專案型態管理間的互動與關聯。專案的產出可能是產品、服務或結果，假設一個研發新”網路下單”資訊應用系統的專案，專案結束後將交付一套”網路下單”系統，該系統也會對應一個產品的生命週期，在以專案所產生的”網路下單”系統必須以產品的Business Idea為始，引發出資訊開發專案，因應專案的型態項目，產品推廣中也將印製與提供系統的操作手冊予公司的客戶與業務人員；同時也將交付系統維護與管理手冊予資訊部門；也將交付系統網路配置圖與維護手冊予網管部門，這將成為也將對應將該產品型態管控的項目，因此產品與專案的流程整合如【圖五】。
再以Institute of Configuration Management於2003年所提供的BUSINESS PROCESS INFRASTRUCTURE，以及焜安同學預擬報告的期刊” Combined application of Product Lifecycle and Software Configuration Management systems for ITER remote handling”為例，肥蝦把兩個重要圖型整合如下【圖六】。
因此在商業觀點來看型態管理，將呈現出”Practice Standard for Project Configuration Management”第二章所說明的【圖七】架構。
記得肥蝦網站中有一位匿名的先進問了一個問題，肥蝦將其中對於Configuration Management的陳述摘要如下：「其實一直不是很懂Configuration Management，看了一些您的文章後...有點了解 它是屬於PMIS系統中版本或變更相關的部分，是這樣解釋的嗎? 不過..... (1)在第四版P 94中又提到"focus on the spec of both the deliverables and the processes" 覺得 越來越混亂 (2)Product Configuration又是什麼呢? 是指功能性嗎? 可以舉個例子嗎? 謝謝您!! (3)在第四版P 110中又提到configuration management activities such as how changes to the product, service, or result requirements will be initiated, how impacts will be analyzed.....怎麼又跟版本不太像呢??」這位先進已把第四版(2008)中對於描述Configuration Management的頁次都明白標示，可見該位先進對於PMBOK的精研程度。但是肥蝦以為PMBOK在4.5 Perform Integrated Change Control(第94與95頁)中對於Configuration Management的說明僅是以整合變更控制程序(integrated change control process)中所涵蓋的Configuration Management加以說明；在5.1 搜集需求(Collect Requirements)產出中的Requirement Management Plan中(110頁)所說明的Configuration Management actives也僅是就Configuration Management中對於需求處理部分的活動。
因此肥蝦在網站上回答了如下的言語：「…基本上CM包含了所謂的版本控管,更遠大於版本控管,不只是程式碼,文件,開發的SDK....都包含在CM之內!(開發的工具版本當然也要控管,不然團隊中有人用JDK1.1,有JDK1.2,有JDK1.6,那不就亂套了) 在PMI中又把它分為Project Configuration Management跟Product Configuration Management(如產品技術手冊等)! 然後中間又有CM Interface.」意思是，除了專案開發所對應的Project Configuration Management之外，對於Project完成所交付的產品也有著Product Configuration Management並且彼此間有著緊密的關聯。
以上是肥蝦對型態管理的初淺認識，還請 先進們多多指正！
沒有留言:
張貼留言