摘要
- 文章編號:20050706
- 投稿日期:2005/06/25
- 作者:陳建憲
- 備註:
淺談專案管理…
什麼是專案管理呢?專案管理是為了完成一個「預定的目標」,而對「任務」和「資源」進行規劃、組織和管理的程序;
通常需要配合時間、資源或成本方面的限制來進行。
大部分的專案管理工作都涉及一些相同的活動,例如將專案分割成便於管理的多個任務、排程任務、在小組中交流資訊以
及追蹤任務的工作進度,都是專案管理中基本常見的需求。
除了這些,還有哪些是我們專案管理系統的需求呢?
上週提到資訊服務委外時需要有一個輔助的專案管理系統,來協助專案經理及專案團隊順利的對「任務」和「資源」進行規劃、組織和管理,當然這個系統我
們要求採用ASP.NET軟體來開發,以節省開發成本及縮短開發時程;以Web介面的專案管理方式,讓專案經理及團隊能更快速、有效率的掌控專案任務的工
作進度、並利用簡便的Web介面完成任務的指派與回報;在配合線上審核的機制,替專案開發的品質把關。
除了Web的介面外,我們還想利用Microsoft
Project2003強大的任務規畫及時程管理的強大功能,來協助我們能以更方便、更輕鬆的方式,達成專案管理的目標。在此;因為Microsoft
Project2003與我們的X系統是不一樣的的環境,因此在這我們利用DSA
WebService作為兩系統間溝通的橋樑,來解決不同系統間的整合需求。
規劃中的X系統架構…
現在我們專案管理系統的需求已經清楚了,接下來我們該如何實作呢?在此;我們針對X系統的需求及Microsoft
Project2003的屬性,設計了完整的架構。首先,我們將X系統拆解成三個子系統來實現,分別是「任務時程子系統」、「成本管理子系統」、「品質管
理子系統」,各個子系統的目標如下:
1.「任務時程子系統」: 依據專案需求規劃任務與時程。
評估任務的合理性,是否能充份支援專案目標。
將實際任務項目及時程、參與者紀錄下來。
評估專案實際時程是否與計劃一致。
2.「成本管理子系統」: 依據專案需求編列預算項目。
評估支出項目的合理性,是否能充份支援專案目標。
將實際支出項目及請購人紀錄下來。
評估專案預算與成本的使用率是否與計劃一致。
3.「品質管理子系統」: 審查系統可行性研究文件。
審查系統需求分析文件。
審查系統設計文件。
審查程式文件。
測試使用者介面、作業流程、程式邏輯。
審查系統使用手冊。
規劃中的X系統ERD...
接著重頭戲登場了,一個系統中最重要的就是資料之間的關係能否定義好。於是我們便針對專案管理的需求及Microsoft Project2003的屬性,規劃了完整的ERD,如圖一所示。
從圖一的ERD中不難發現「任務」這個Entity有著舉足輕重的地位,接下來我們對「任務」這個Entity與週遭的Entity發生的關係做個簡單的說明。
從圖一的ERD中我們可以看到「任務」這個Entity總共跟3個Entity還有一個Relation發生關係,分別是「專案」、「任務回報紀錄」、「任務」本身、及專案團隊與實務社群成員之間的Relation。
1.「專案」vs「任務」:專案管理的概念裡,一個專案是由多個任務所組成的,而團隊則由完成一個個任務的方式,來達成專案的目標,所以這2個Entity之間的關係是「包含」。
2.「任務」vs「任務」:在圖一的ERD中,我們可以發現「任務」這個Entity會與自身發生2種不同的關係。
第一種情況是:在專案管理中,有一種概念,稱為「摘要任務」;而「摘要任務」的完成,則必須靠它底下每個子任務的達成才能做到,所以在這種情況下,這個自身的關係是「擁有」。
第二種情況是:在專案管理中,還有另一種概念,稱為「前置任務」,舉例來說,現在有A、B兩個任務,但是它們之前有著順序關係,必須先完成
A後才能進行B的工作,所以A就是B的前置任務。一個任務可能不只有一個前置任務,而這個任務本身也可能是其他任務的前置任務,所以在這種情況下,這個自
身的關係是「前置」。
3.「任務」vs「任務回報紀錄」:這2個Entity間的關係是很單純的,當專案經理指派任務後,任務執行人就必須在協定好的一段時間內回報任務進度,而「任務回報紀錄」是依附在「任務」底下的WeakEntity,所以它們之間的關係是「屬於」。