July 1999, 中華管理評論
Vol.2, No.5, pp.143~156

以UML改良整合專案管理程序之研究

王志傑
Chih-Chieh Wang
國防管理學院國防資訊研究所研究生

tier@ms1.hinet.net

張克章
Ker-Chang Chang
國防管理學院國防資訊研究所教授

changher@ms19.hinet.net


  網際網路結合個人電腦之應用,拓廣了資訊應用之門, 21世紀裡沒有結合資訊運用之行業都將面臨失敗,運用資訊愈廣之企業將愈加成長茁壯,專案管理技術也不例外,勢必往資訊整合管理發展。然而資訊整合所涉及之技術層面相當廣泛且複雜,致使國人至此仍多不瞭解其內涵。本研究運用物件導向第三代整合模式語言(UML),釐清專案需求,改良整合專案管理程序,並發展出資訊管理模式,結合MS project98軟體,整合管理各式資訊,跟上資訊拓廣之快速腳步,將專案管理導入高品質之境界。

關鍵字:網際網路,資訊運用,整合模式語言,整合專案管理。

ABSTRACT

  The application of Internet linking with personal computers extends the gateway of information flow. In 21st century, the industries that don’t connect with information flow should be failed; On the other hand, the industries that tightly combine with information flow must be strong. On the same situation, project management is also without exception. The development of project management must go through this tide to derive the integrated information management. The integration of information management is so complex and complicated, users will not familiar with this usage of technique. In order to clearly describe the analysis of project management requirement, we use an Unified Modeling Language (UML) technique to enhance the applications of project management (PM). First, the related technologies are analyzed. A new modified process combining with information management model is then developed to manage PM. Finally, a new model working by MS project98 to manage the information of PM is proposed. Model verification and capability analysis is also provided. The proposed method is expected to offer a new concept to meet the information trend and to lead PM toward high-quality control.

KeyWord:Internet, information application, Unified Modeling Language (UML), Integrated project management (IPM).


緒論

  二十一世紀資訊科技進步快速,各企業都面臨如何提昇競爭力等問題,因此資訊整合運用等需求增加,如何運用專案管理降低成本、提昇品質,解決裝備生命週期短暫及運用資源減少等問題,已為各企業所追求之目標。然而,專案管理之技術,以時程管理、成本管理及需求管理為最主要成功因素,目前此類因素中,唯獨需求管理尚未有較佳解決方法。由於近年來物件導向(Object-Oriented, OO)隨著資訊技術演進,發展出第三代整合模式語言(Unified Modeling Language, UML),具有再利用、封藏(Encapsulation)、繼承(Inheritance)等優點,特別適用於需求分析。本文運用UML之技術,發展資訊管理模式,並結合MS Project98軟體,改良整合專案管理程序,有效解決專案需求分析及資訊整合管理等問題,將專案管理導入高品質之境界。目前專案管理技術大部分已相當成熟,其中以美國專案管理學會(Project Management Institute, PMI)1997年所發表的"A Guide to the Project Management Body of Knowledge"提出專案程序標準規範為主流。專案管理乃是指一組完整而有特定目標的活動,其具有明確的時間及成本限制,有多種資源,且內容涉及各項技術,具有相當的複雜性,及不重複性。所以專案管理是保持範圍、時程和資源平衡的一門學問,能夠有效管理目標任務、資源和成本的系統,基本上專案目標不限大小,可以產生有形的結果,或是無形的勞務,但必須具體而明確。因為近年來隨著科技進步,專案管理也必須引進新技術,才能符合未來企業整合運用資訊之需求。

  主要研究目的是將資訊管理模式,運用於MS project98軟體中,整合管理各式資訊;以UML技術釐清專案需求,改良整合專案管理程序,提昇專案管理技術,使專案管理跟上資訊進步之潮流。運用文獻研究專案整合管理及UML方法,分析比較此類技術,作為改良整合專案管理模式之參考依據;運用ROSE (Rational Object-Oriented Software Engineering)軟體設計資訊管理模式;結合UML需求分析方法及資訊管理模式,改良整合專案管理程序;運用MS Project98軟體及物件連結內嵌(Object Linking and Embedding, OLE)技術,整合各式相關軟體,發展出全數位化「整合專案管理模式」。研究成果是以目標任務為核心,設計出資訊管理模式,結合MS Project98軟體整合管理各式專案資訊,達到資訊整合運用目標;充分運用UML技術及ROSE軟體釐清專案需求分析,達到降低成本與風險之目標,解決需求分析數位化等問題,建立個人電腦結合網際網路之資訊管理環境,滿足各企業之需求。研究範圍僅探討專案管理之整合程序及定義資訊標準等問題,並假定專案管理其他各項領域均發展成熟,未作深入探討。


文獻探討

  整合專案管理及UML應用技術是本研究探討重點,其內容包含有專案管理手冊、成本分配方法、動態專案管理系統、程序規劃系統、程序理論、多重整合模式、整體改變控制模式、UML歷史介紹、物件導向應用、UML即時系統及組件基底軟體發展模式等探討。

2.1 專案管理

  Duncan[3]於1996年,發表專案管理指引手冊,定義專案是由程序所組成,所謂程序就是指一系列產生成果之行為,也就是人員以漸進方式投入工作,經過執行後所產生之過程,用來描述與組織專案工作。專案管理程序區分五個部份,各部份又細分為一個或數個程序,分別為1.原始程序(Initiating Processes):確認一個專案或是專案流程之起始點,並決定何時召集研討;2.規劃程序(Planning Processes):設計與維護專案,以達到預定需求,使專案發展依照既定規劃推展;3.執行程序(Executing Processes):指工作人員之間協調合作與調節運用其他資源計畫;4.控制程序(Controlling Processes):藉由監督、程序檢測、修正事項等控制方法,確保達成預定目標;5.結束程序(Closing Processes):指井然有序正式驗收專案成果之步驟。這些程序之間經由輸出及輸入之關係,彼此之間相互關聯共同存在,也就是某個程序之運作結果,將是另一個程序之輸入事項,各程序之間以反覆方式連結,例如初步專案計畫經過執行後,會反覆修正初步設計文件,圖一顯示其連結方式。另外要強調這些程序不是個別獨立存在,而是在同一時間運作且相互重疊實施,每一個程序彼此間都會產生不同強度之相互影響,圖二描繪出各個群組程序重疊情形,以及各程序在專案中運作流程。群組程序之整合運用也跨越時序,也就是當一個時序結束時,就會將成果提供給另一個即將開始程序運用,達到跨越時序。圖三顯示各群組相互影響之關係,將每一個部份起始點,反覆加入程序內,以確保按照步驟運作時,可以不時回顧客戶需求,當顧客需求偏離或是專案執行不能滿足需求時,此種方式也可以使專案暫停,以便於修正及檢討,雖然專案是以階段程序運作,但是專案真正運作時,有許多地方卻是以重疊方式呈現。以規劃階段為例,不但要提供有利於達成現階段工作之細部分配事項,也必須提供有利於後續階段發展之預判事項,此種漸進式專案細部規劃,常稱之為螺旋式規劃。

  wpe76.jpg (9179 bytes)

圖一Duncan專案管理程序關聯圖[3]

wpe75.jpg (11942 bytes)

圖二Duncan各個程序之重疊情形[3]

 

  綜合文獻[3]之整合管理(Integrated Management),共包含範圍、成本、時間、人力、品質、危機、採購及通訊等八大類管理之輸出項目如圖四,然後發展專案計畫、執行專案管理及整體改變控制如圖五。計畫發展是運用八大類管理之輸出結果加以整合而成,運用聯貫式文件指導專案執行與管制,整個過程運用螺旋法一直反覆執行數次,直到完全整合為止;執行程序是實踐專案最主要部份,許多專案預算都要依靠推動執行程序來擴大運作,在整個過程中專案經理及小組成員必須協調合作,直接指導各種技術及組織之運作,達成各項專案目標;整體改變控制之核心工作,在於保持測量基準線完整,方能預判及度量其他改變對專案之影響,唯一要注意的是只有範圍之改變會影響到測量基準,藉由增加改變因素之預判等方式,實施整體改變控制,以誘導所有改變朝向正面影響,並控制各種必然會發生之變化及管理常態性變化等。

 

wpe74.jpg (14958 bytes)

圖三Duncan各個階段之相互影響關係[3]

wpe73.jpg (14136 bytes)

圖四Duncan專案整合管理範圍[3]

  Shoval [4] 於1996年利用成本效益圖形 (Cost-Benefit Graph),考量預期成本和每一組專案之利益,提供成本權值和利益因子,使決策者據以分析規劃專案,有效解決專案設計時程和預算分配等問題,Shoval方法已經發展成熟,可以直接應用於整合管理模式,解決時間計算及成本分析等問題。

  謝遠敦等人[1]於1997年,探討Design Net Model專案管理之方法,認為其無法實施專案任務之分割、重疊、延長、暫停及執行管制等缺點,經由改良後發展出動態專案管理系統(PM-Net),解決了專案需求動態改變控制等問題,提供PC環境之專案管理工具,以視窗方式呈現即時資訊,便利於專案經理管制各項任務。

  微軟公司於1998年推出Project98專案管理軟體,已具備成本計算、人事分派、專案樣式及網路運作等功能,這些功能就是文獻[1]當時所希望再研改項目。然而面對未來資訊之二十一世紀,目前仍然存在以下問題需解決:

  1. 資訊時代要求即時、快速及多重之資訊,因此任務之複雜度提昇,完成任務不再是運用單一軟體,而是要靠好幾種軟體運用各專長項目,共同完成任務,軟體之整合運用成為重要之問題。
  2. 附屬於任務之資訊因此變為複雜,未來將需要新方法加以管理、規範這些多重領域之資訊。
  3. 專案之整合程序也因為上述因素,需要更好之方法解決。

wpe72.jpg (29488 bytes)

圖五Duncan專案整合管理步驟[3]

  由研究文獻[1]之探討,瞭解到如何解決動態專案管理之方法及理論,也釐清目前專案管理之缺點所在,將有利於資訊整合模式改進之依據。

  Zhao[5]於1997年依據方法管理學技術,研發出程序規劃系統,包括有工具定義、要求、資料處理、任務定義、流程定義及流程註解等功能,解決不同系統之間的問題,然而該系統僅解決規劃之前事項,尚缺乏整合管理資訊之模式,目前PC之視窗環境提供Access物件導向資料庫,定義上述項目僅是工具中之基本項目,尚有擴充、統計、計算及分析等功能。一套完整之整合管理模式,必須建立在開放環境,允許即插即用Plug-and-Play環境,使資訊無限擴充使用,在以有限條件加以管制,就可以達到整合管理。

  Pressman [6]於1997年,發表物件導向管理方式必須要有程序支持之理論,強調物件導向管理方式缺少程序時,就像系統中缺少時間表、引擎中缺少機油一樣,即使能夠勉強運作,其效能一定大幅降低。所以程序對整合管理模式是相當重要之一環,程序界定清楚就會按部就班逐一完成,缺少程序就會亂無章法。整合模式中運用雛形法結合螺旋模式,先以繪圖方式畫出雛形,經過反覆研討及修正,直到實際需求目標達成,此種結合方式將可以省時又可以符合需求。

  Song [7]於1997年運用Booch及OMT方法,發表多重複雜方法之整合模式,將多種方法結合設計出整合架構,使需求分析更加明確,此方法乃是初步架構,難以表達全部要敘述之事項,將會隨著Booch及OMT之技術而更加強,由此看出OO技術目前演進至UML,隨著這個理論看出運用UML改良專案管理之整合技術將是趨勢。

  Voropajev[8] 於1998年因為開發中國家經濟呈現不穩定之現象,急需新方法管制各種改變控制,於1998年提出專案管理整合功能之改變管理模式,解決專案執行時各種變相問題,包含有改變預測、專案計畫防護、計畫執行、改變控制及成效評估。專案管理協會已將該方法,正式合併於專案管理之方法論內。資訊作戰環境與開發中國家經濟不穩定現象正好相符,所以運用Voropajev方法,解決整合式專案管理之需求變化等問題是非常合適。

  綜合文獻[1,3-8]之研究,發現專案規劃主要工作有三大類,分別為:1.將規劃結果組合成聯貫式文件。2.執行各項專案任務完成計畫撰擬。3.控制整個計畫變異因素。三者彼此之間相互關聯、重疊運用。

  未來資訊作戰環境所要管制之任務,必定是複雜、多樣及即時性高,我們所面對規劃或決策等問題,其複雜狀況經常涵蓋不同層次之知識領域,因此在思考與規劃過程中,就要有系統瞭解不同領域之問題,才能做出正確的規劃與決策。目前之專案管理方法,未能夠有效解決資訊作戰之資料整合管理,達到資訊優勢主宰戰場。孫子兵法始計篇開宗明義就強調:「多算勝,少算不勝」,同樣的在規劃階段就要全面思考自己所要做的事,以及瞭解目前所擁有之資源,然後有步驟的實施整體規劃,按步驟逐一執行,當遇到一些改變因素時有效運用方法達到整體改變控制,這種方式才適用於善變之大環境。

2.2 整合模式語言

  物件導向(Object-Oriented,OO)軟體技術已經發展到第三代整合模組語言,主要採用Booch等人之研究成果[9],加上其他人建議而產生。於1997年11月經由物件管理協會(Object Management Group, OMG)驗證合格。UML是物件導向之標準模式語言,提供豐富標示法,適合各種系統模式之分析應用,包含各種即時系統、主從系統及其他具有標準規格之軟體裝備,並且支援CASE主要應用工具,UML是未來軟體工程技術發展趨勢,亦即各領域之模式共同語言,各領域設計師以UML為基礎,而發展出該領域的特殊模式語言,進而發展出特殊的發展程序(Process),構成該領域OO整體開發環境之理想。

  Kara [10]於1996年認為傳統軟體開發方法和目前OO方法,皆只偏向一般設計原則(General Rule),指導我們在那個階段思考些什麼。例如找出重要關鍵類別之後,應再考量各類別間之繼承關係,而如何去思考出理想之繼承關係,以建造出美好的類別結構時,頂多提示繼承關係是必須支持之介面,而不能將程式碼再利用。這些一般原則就像開車時應遵守之交通規則,是剛學開車的新手要好好學習法規。但是當開車開久經驗增加以後,除了對這些規則運用純熟之外,還會體會出更多心得和經驗,當處理各種狀況時會變得更乾淨俐落,於是就由菜鳥變為開車老手。軟體開發過程和開車道理相同,若能夠進一步捕捉與表達識途老馬內心深處所蘊藏之經驗法則(Rule of Thumb),就能讓新手再利用高手的各種絕招,同時高手也可從以其它高手中汲取經驗,而更上層樓,發揮人類智慧和創造力極限。更重要的是,在同領域(Domain)的高手心中,常會面對類似狀況,而產生有許多共同經驗法則。但和其他領域高手之共同經驗法則相比,就可能有許多差別了。例如計程車司機與大型貨櫃車司機的經驗法則,就會有某些相同、某些不同之區別。

  Douglas[11]於1998年以UML設計即時系統時,將軟體模式(Software Model)元素,看成像自然語言之「字彙」一樣,並將設計原則與經驗法則視為語言之「文法規則」,嵌含在字彙涵意之中。強調UML像自然語言一樣,由許多小字彙和簡單規則所組成,然後逐漸吸收人們經驗後,擴充其字彙與規則。同時字彙與規則也會汰舊換新呈現出新面貌,表達人們新的思想和文化,於是UML成為放諸四海共同的活語言,各領域人們可彈性地增加其領域專有字彙、涵意和規則,而成為領域中特殊文化下的特殊語言。因此軟體設計師運用這種模式語言來構思及創造軟體,就如同我們利用中文來構思、說話或寫文章一樣,充分地再利用別人的創意、智慧,還可以表達自己的見解,這正合乎OO發展潮流。文獻[2]定義出新一代軟體發展程序,主要用到之工具分為分析設計、程式撰寫與裝配三大類,共整合UML、VB、Deliphi、COM(Component Object Model)和CORBA等技術,發展成組件基底(Component-Based)研發環境如圖六,軟體分析師運用UML各種圖形及符號表達使用者需求,分析設計各個組件,並自動將圖示轉換成文件,程式設計師運用這些UML需求文件,運用VB或Deliphi軟體設計出各個組件之程式,然後再運用COM或CORBA,將各個組件程式裝配成各式各樣應用程式。換句話說就是大幅提高自動化產生軟體的方式,並清楚記錄下所有運作過程。在這種環境中不但能夠充分結合需求、大幅縮減研發時程、增加模組再利用,並且方便於需求之新增與修改,所以UML對國軍未來軟體研發之影響很大。

  由文獻[9,10]中發現,UML之封藏性敘述物件資料部分,只能連接到所定義的功能部分,使物件更安全、可信賴,物件使用者不能夠直接影響物件敘述,必須要透過其他控制介面才可以影響物件敘述。開發者(Developers)所使用之物件類別,在不影響其他使用者前提下,可以改變部分資料。由結構化方法演進到物件導向方法,其最難的部分就是思維模式之轉換,也就是指如何有效運用物件之封藏性,簡而言之就是一個物件它代表著無限多個複雜結構,依據需求一層一層定義清楚,將很複雜的架構簡單化之後封藏起來,平時只看得見主物件,其他次要特性或是細部架構,在用不到的時候放在下幾層封藏起來。將資料種類轉變為模組化的方法中,最簡單的方式就是運用標示法,繪製各種形式圖形,來表達不同的模組觀念。UML以很清楚方式,區別標示法中模組與圖形之間關係,一個模組裡包含了一個系統,能夠獨立表達所有內容,包括所有基本資訊的記錄等。在一張圖裡就可以包含模組中所有基本單位,也可以顯示出附屬於基本單位之詳細資料,而這些基本單位也可以依存在多重圖示裡。共區分為使用案例圖(Use-Case Diagram)、類別圖(Class Diagram)、互動圖示(Interaction Diagram)、狀態圖(State Diagram)、組件圖(Component Diagram)、佈署圖(Deployment Diagram)等六類。每一種圖都描述出系統模式的不同部分,而這些圖有可能是以多樣形式存在,也有可能只運用其中某一種圖來表達,完全依照使用者需求而決定如何運用,例如設計即時系統時只會用到互動、狀態、佈署圖。

  Douglas[11]於1998年以UML設計即時系統時,將軟體模式(Software Model)元素,看成像自然語言之「字彙」一樣,並將設計原則與經驗法則視為語言之「文法規則」,嵌含在字彙涵意之中。強調UML像自然語言一樣,由許多小字彙和簡單規則所組成,然後逐漸吸收人們經驗後,擴充其字彙與規則。同時字彙與規則也會汰舊換新呈現出新面貌,表達人們新的思想和文化,於是UML成為放諸四海共同的活語言,各領域人們可彈性地增加其領域專有字彙、涵意和規則,而成為領域中特殊文化下的特殊語言。因此軟體設計師運用這種模式語言來構思及創造軟體,就如同我們利用中文來構思、說話或寫文章一樣,充分地再利用別人的創意、智慧,還可以表達自己的見解,這正合乎OO發展潮流。文獻[2]定義出新一代軟體發展程序,主要用到之工具分為分析設計、程式撰寫與裝配三大類,共整合UML、VB、Deliphi、COM(Component Object Model)和CORBA等技術,發展成組件基底(Component-Based)研發環境如圖六,軟體分析師運用UML各種圖形及符號表達使用者需求,分析設計各個組件,並自動將圖示轉換成文件,程式設計師運用這些UML需求文件,運用VB或Deliphi軟體設計出各個組件之程式,然後再運用COM或CORBA,將各個組件程式裝配成各式各樣應用程式。換句話說就是大幅提高自動化產生軟體的方式,並清楚記錄下所有運作過程。在這種環境中不但能夠充分結合需求、大幅縮減研發時程、增加模組再利用,並且方便於需求之新增與修改,所以UML對國軍未來軟體研發之影響很大。

  由文獻[9,10]中發現,UML之封藏性敘述物件資料部分,只能連接到所定義的功能部分,使物件更安全、可信賴,物件使用者不能夠直接影響物件敘述,必須要透過其他控制介面才可以影響物件敘述。開發者(Developers)所使用之物件類別,在不影響其他使用者前提下,可以改變部分資料。由結構化方法演進到物件導向方法,其最難的部分就是思維模式之轉換,也就是指如何有效運用物件之封藏性,簡而言之就是一個物件它代表著無限多個複雜結構,依據需求一層一層定義清楚,將很複雜的架構簡單化之後封藏起來,平時只看得見主物件,其他次要特性或是細部架構,在用不到的時候放在下幾層封藏起來。將資料種類轉變為模組化的方法中,最簡單的方式就是運用標示法,繪製各種形式圖形,來表達不同的模組觀念。UML以很清楚方式,區別標示法中模組與圖形之間關係,一個模組裡包含了一個系統,能夠獨立表達所有內容,包括所有基本資訊的記錄等。在一張圖裡就可以包含模組中所有基本單位,也可以顯示出附屬於基本單位之詳細資料,而這些基本單位也可以依存在多重圖示裡。共區分為使用案例圖(Use-Case Diagram)、類別圖(Class Diagram)、互動圖示(Interaction Diagram)、狀態圖(State Diagram)、組件圖(Component Diagram)、佈署圖(Deployment Diagram)等六類。每一種圖都描述出系統模式的不同部分,而這些圖有可能是以多樣形式存在,也有可能只運用其中某一種圖來表達,完全依照使用者需求而決定如何運用,例如設計即時系統時只會用到互動、狀態、佈署圖。

  Douglas在文獻[11]中強調,UML特別適用於即時複雜之系統,提供模組類別、物件和其他不同關係之工具,包含有結合、聚合、繼承、獨立和產生物件,使用案例直接支援劇本的編寫,以詳細描述系統所需要的行為,互動圖是圖解劇本,可以包含時間和同步訊息,加強限定狀態模式支援一些即時特性,包含了同時發生、事件傳播、建立狀態等,透過本身附加飾別(Stereotype)定義來達到擴充,系統之設計師可以在很清楚狀況下,運用UML技術開發複雜系統。

wpe6A.jpg (10343 bytes)

圖六 高換堂組件基底軟體發展流程圖[3]


三、改良式整合專案管理模式

  以往專案管理觀念上雖已有具體的成果,但隨著資訊科技及物件導向技術的蓬勃發展,如何將整合專安管理與UML結合,以改良整合式專案管理程序,為本文研究之目標。

  基於文獻[3-8]研究,結合UML技術,改良整合式專案管理模式為原始程序、需求分析、規劃程序、執行程序、控制程序及結束程序等六大步驟如圖七,並利用資訊管理模式,明確定義出各個程序之標準資料格式,以利資訊整合管理。

六大步驟之細部說明如下:

  1. 原始程序:建立Project 98專案任務檔案,定義專案之初步任務、範圍、起始時間、完成時間、預定資源、預定專案經理、研討方式。直到第一次會議完成前之工作,都是屬於初始規劃,並將原始規劃之各項資訊記錄成文件。

  2. 需求分析(Requirement Analysis):依據原始規劃結果定義專案資訊格式,然後隨即開始執行各項資訊記錄工作,輸入初始規劃輸出事項,繪製四維模式之聯合景象雛形,經由委製者與分析師反覆溝通後,在ROSE軟體內以UML圖示實施需求分析,經由反覆模式運作直到實際需求確定,輸出專案任務實際需求。

  3. 規劃程序:輸入UML需求分析之輸出結果,瞭解專案各項任務之需求、時程及資源等資訊,細部規劃各項子計畫之任務,並分配各細部任務之時程及資源,細部計畫依據實際需求可以分為專案範圍計畫、時間計畫、危機計畫、品質測試計畫、執行計畫、管制計畫、人事運用計畫、採購計畫、資源分配計畫等,規劃完成後輸出各個細部計畫。

  4. 執行程序:執行工作依據各細部計畫之任務,逐步或同步執行各項工作,於執行專案時專案經理需依計畫管制各個細部任務,定期檢討各細部任務執行狀況,並記錄各執行過程與結果。

  5. 控制程序:依據計畫基準資訊、執行記錄及執行成果,檢測各項任務之執行品質,確定各子計畫步驟是否依計畫達成,並預判分析各種可變因素,降低各種改變對任務執行之影響。整體改變控制之基本原則:當改變因素不足以影響任務達成時,直接於執行程序中小幅修正,繼續原計畫之執行程序;當發現改變因素足以影響原計畫執行事項時,立即停止執行程序,回到原規劃程序修正,補強原專案之計畫後再實施執行程序;當發現改變因素大於影響主任務之達成時,將訊息回饋到需求分析階段,重新檢討新增之需求,並以新增獨立專案方式將新增需求附掛加入原計畫之下,運用新增專案目標任務方式,既不影響原專案推動又可達到同步實施爭取時間之功效。控制程序與其他三類程序間之回饋方式,具有執行程序>規劃程序>需求分析優先順序之關係。

  6. 結束程序:委製者依計畫驗收控制程序之各項輸出成果,比對員計畫檢查是否滿足原需求,並檢查各項過程,是否依據資訊管理模式所定義之方式記錄完整,以利於爾後追蹤檢查。

  資訊管理模式如圖八,改良式整合管理除了新增需求分析程序之外,還要求於需求分析程序中,定義資訊管理模式之資訊屬性。依據大物件包含一到多個子物件原理,將專案之各項目標任務視為物件予以管理,大專案裡包含不同小專案,於MS Project98軟體中建立樹狀專案任務架構,任務名稱內包含有時程、成本、人力等資訊,並依需求於附註欄中加入需求、品質、危機、採購及通訊範圍等資訊,各式資訊均依附於專案任務內,並可以依實際需求增減項目,專案經理透過MS Project98軟體管理各項任務資訊,以視窗界面掌握所有相關資訊,達到方便使用與管理之要求。而各項專案任務之基本記錄不得缺少任務名稱、時程、成本及需求,以利爾後專案任務之執行與管制。

wpe71.jpg (9278 bytes)

圖七 改良式整合專案管理模式(整體設計流程圖.mdl)

 

wpe70.jpg (8865 bytes)

圖八 資訊管理模式(資料定義.jpg)


四、改良式整合專案管理應用

  將改良整合專案管理視為一個專案,應用所創新之方法實際執行,以驗證新程序及資料管理模式之可行性,在MS Project98環境中執行情形如圖九。

wpe6F.jpg (29507 bytes)

圖九 改良整合專案管理之發展程序

  改良整合專案管理之專案期程,由88年1月8日起至88年4月21日完成,共計48工作天,將專案任務視為物件管理,六大程序中又細分為33個子任務,每個子任務又附帶著其他資訊,程序之第二項需求分析,內容包括改良整合專案管理整體設計流程如圖十。於MS Project98中,成本、時程及資源等資訊,已有固定儲存格式,而其他未規劃之資訊,均以附掛方式儲存於附註欄之內,以簡圖方式封裝顯示,要查詢附帶之資訊時,以左鍵點兩下開啟,修正之後再次儲存,此種封藏方式不會影響主要任務之執行,例如將改良整合專案管理需求分析所得到之成果(改良式整合專案管理模式如圖七),以流程圖.mdl (壓縮圖片之副檔名)縮圖顯示,並於註記欄中說明所需注意之細部事項,而改良整合專案管理之成果(資料需求定義如圖八),則以資料定義.jpg (ROSE之副檔名)縮圖顯示如圖十一。

wpe6E.jpg (8162 bytes)

圖十改良整合專案管理專案之流程圖

  以上說明及範例證實,運用MS Project98結合改良式整合專案管理模式,可以按照資訊管理模式需求,實施資訊管理,在結合PC及網際網路運作環境,使資訊管理模式不但能夠妥善管理各式資訊,還能運用這些環境分配任務及獲得廣泛資源。依據這些實做驗證改良式整合專案管理模式及資訊管理模式之管理環境,完全符合未來資訊發展要求。

wpe6D.jpg (39802 bytes)

圖十一改良整合專案管理專案之任務程序


五、效益評估

  改良式整合專案管理是經由需求分析程序,確保專案內各個不同基本單位,能夠協調合作推動專案,並確保目標與計畫程序相吻合,以達到委製經理所預期成效,並運用軟體工具達到資訊整合管理之目的,平時善用各種不同佐證資料,整合評估即時性資訊,當需要運用時才能夠立即提供各種整合資訊。將改良式整合專案管理模式與文獻[3-8]專案管理之方法相比較,發現其優點及特徵如下:

  1. 結合UML需求分析方法,釐清需求,使任務有效結合專案目標。

  2. 運用資訊管理模式,整合資訊架構。

  3. 結合ROSE及 MS Project98等各式工具,發展全數位式管理環境。

  4. 提供動態需求分析及整體改變控制環境。

  5. 藉由正確資訊提昇專案品質、降低成本及風險。

表一 改良式整合專案管理比較

wpe6B.jpg (26858 bytes)


六、結論與未來努力方向

  第三代整合模式語言,具有再利用、封藏(Encapsulation)、繼承(Inheritance)等優點,特別適用於需求分析。本文運用UML之技術及ROSE軟體,改良整合專案管理程序,能夠有效掌握所有資訊,將資訊管理透明化,不但提昇專案管理效能,又能實施整體改控制,符合未來資訊需求。而資訊管理模式結合MS Porject98整合各式軟體,有效解決專案需求分析數位化及資訊整合管理等問題,確實發揮整合功能,增加資源共享及達到整體應用之功能,建立了個人電腦結合網際網路之資訊管理環境,將專案管理導入高品質之境界,以符合未來企業整合運用資訊之需求。

  把專案管理比擬成交響樂團,將有助於理解整合運用方式,指揮家管制各項樂器,於適當時間奏出所要之音樂,構成和諧之樂曲,其成效絕非單一樂器所及,這就是整合功效。每當要練習新曲子之前,先組成小樂團試奏一下,瞭解到何時用何種樂器,才可以滿足好聽之需求,然後再召集全體樂團練習,這種先經過小實驗證實無誤之後,才進入大計畫之做法,就是一種需求分析,這種做法可以節約專案管理時程、效果,進而節省訓練成本並且提昇品質。基於上述理論,引進需求分析改良專案管理,具有二個主要優點如圖十二:

  1. 儘早釐清需求,確定專案目標,降低風險,節約成本、時程及人力,並提昇品質,確保專案之達成。

  2. UML之專案需求可以結合軟體工程,直接運用進入程式撰寫步驟,達到降低成本,節省時程之功效。

wpe6C.jpg (7436 bytes)

圖十二 需求分析結合軟體工程圖

  爾後研究方向可將樣式(Pattern)觀念,結合改良整合式專案管理建立成專案資料庫,可以有系統建立專案需求分析能量,使資訊充分再利用,使新專案設計再也不是重頭開始,對於爾後各專業領域之研發會有很大助益。資料管理模式可以結合試算表、資料庫及網路格式等相關軟體,構建相容性更高之整合環境,進而建立專案標準模式,規範出專案發展方式,達到專案管理標準化之境地。


參考文獻

  1. 謝遠敦、黃明祥、林信惠,「動態軟體專案管理資訊系統的設計與應用」,八五年國科會論文專輯,國科會,1996.
  2. 高煥堂,「Visual Basic 與Delphi之間抉擇」,物件導向雜誌,第八期,1997,頁15。
  3. Duncan, W. R., A Guide to the Project Management Body of Knowledge, Project Management Institute, Pennsylvania, 1996.
  4. Shoval, P. and Giladi, R., Determination of an Implementation Order for IS Project, Information & Management, Vol.31, No.2, 1996, pp. 67-74.
  5. Zhao, Z., A Methodology Management Approach to Computerized Process Planning, International Journal of Computer Integrated Manufacturing, Vol.10, No. 2, 1997, pp. 83-91.
  6. Pressman, R., OO Project Management:The Need for Process, IEEE Software, Vol.14, No.4, 1997, pp. 96-97.
  7. Song, X., Systematic Integration of Design Methods, IEEE Software, Vol.14, No.2, 1997, pp. 107-117.
  8. Voropajev, V. I., Change Management-A Key Integrative Function of PM in Transition Economies, International Journal of Project Management, Vol.16, No.1, 1998, pp. 15-19.
  9. Booch, G., Rumbaugh, J. and Jacobson, I., The Unified Modeling Language for Object-Oriented Development: Documentation Set Version 0.9 Addendum Rational Software Corp., 1996.
  10. Kara, D., Components Defined, Application Development Trends, June, 1996, pp. 69-76.
  11. Douglas, B. P., Real-time UML:Developing Efficient Objects for Embedded Systems, Addison-Wesley, Reading, Massachusetts, 1998.

[ 回目錄 | Top ]