首頁‎ > ‎電子期刊‎ > ‎2005 年 第 11 期‎ > ‎

校園資訊服務委外專案管理-需求分析(六)


摘要

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

Comments