摘要

• 文章編號：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，所以它們之間的關係是「屬於」。