專案管理

1. 專案管理

2. 內容大綱 • 導論 • 瞭解專案 • 界定範圍 • 工作規劃 • 更改管理 • 品質管理 • 風險管理 • 專案的執行 • 專案的評估與控制 • 結論

3. 導論 • 「專案」（Project）是一項在預定的時間內投入預定的資源，以達到特定目標的工作，專案管理則是應用管理的原則及方法，使專案得以順利進行達成預定目標。 • 引進專案管理的方法可使系統的開發做的更好。

4. 瞭解專案 • 探討下列議題有助於對專案的瞭解： • 專案是如何開始的？ • 主要的使用者是誰？ • 意見的主導者在那裏？ • 那些人或部門是專案的倡導者？反對者？旁觀者？ • 是否有相關的專案？關係如何？ • 高階管理者與顧客對時間、金錢、品質與信譽等因素的優先順序為何？ • 重要的人員及角色為何？

5. 界定範圍 • 主要是定義那些工作該做，那些不必做，交付什麼項目與內容等。 • 範圍失控會引發專案管理的問題，例如： • 成本的超支 • 時效的延誤 • 需求的衝突 • 設計的更改 • 管理的複雜度提高

6. 界定範圍 (c.2) • 界定範圍是一個討論、溝通、與協調的過程，過程中應考量時間的限制，資源的多寡和顧客的優先順序等。 • 界定範圍的方法可透過工作分解圖（Work Breakdown Structure, WBS）將系統的功能加以展開，在決定那些功能要納入專案時，應注意有那些功能無法分割，有那些可分階段來進行，有那些功能可以縮減等。

7. 系統功能的工作分解圖

8. 工作規劃 • 工作規劃包含 • 預算規劃 • 時程規劃 • 人力規劃

9. 工作規劃(c.2) • 預算規劃 • 可以從由上而下(Top-down)和由下而上(Bottom-up)兩種角度來執行。 • 由上而下的方法： • 將專案的總預算依某個百分比分配到各階段，此一百分比是一個過去經驗的平均值，對於特殊的情形再予以調整。 • 由下而上的方法： • 由工作分解圖中所列的功能逐一估計所需之成本，由下而上加總後得到的預算估計。 • 這兩種方法可並行使用，以相互對照比較。

10. 工作規劃 (c.3) • 預算可依下列項目加以細分： 1.技術部門人事費用 包括專案經理的費用、技術人員的費用、及助理人員的費用。 2.資本支出 從事專案所需的軟硬體設備、辦公設備等。 3.費用(Expenses) 各階段發生的旅費、顧問費、訓練費用等。 4.經常費用(Overhead) 包括行政人員的分攤費用、水電費、辦公用品費用、保險費、管理費用等。

11. 工作規劃 (c.4) • 時程規劃 • 目的在於定義： • 專案的活動 • 每個活動所需的時間 • 活動的先後順序及起始／完成日期

12. 工作規劃(c.5) • 時程規劃可依下列步驟進行： 1.將專案的活動依工作分解圖展開。 • 工作分解圖的最底層便是所要執行的工作， • 工作分解圖之詳細程度可以責任劃分清楚，容易管理為原則。

13. 專案活動的工作分解圖

14. 工作規劃(c.7) 2.找出活動的先後順序並劃成PERT（Program Evaluation and Review Technique）圖。 • 每一框框表示一個對應於工作分解圖的活動，箭頭表示活動的先後關係。框框內左邊的數字表示工期，右邊的數字表示寬延時間或浮動時間（Floating Time）。 • 寬延時間是活動可延遲而不致影響整體完成時間的容許範圍。

15. 工作規劃(c.8) 流 程 塑 模 4 w 0 w 89/1/24 89/2/20 環 境 模 式 建 立 模 組 設 計 2 w 0 w 4 w 0 w 89/1/10 89/1/23 資 料 塑 模 89/2/21 89/3/19 需 求 分 析 2 w 2 w 0 w 0 w 89/1/24 89/2/6 程 式 編 碼 89/1/10 89/1/10 0 w 0 w 89/3/19 89/3/19 測 試 計 畫 4 w 6 w 89/1/10 89/2/6 PERT圖（欄位左表工期、欄位右表寬裕時間） 需求分析→環境模式建立→流程塑模→模組設計→程式撰寫為要徑。

16. 工作規劃(c.9) 3.找出要徑（Critical Path）及各活動的寬延時間。 • 要徑是活動的總工期最大的一條路徑。 • 要徑上的寬延時間均為零，表示此路徑上的活動均不得延誤，才不會影響整體專案的完成時間。

17. 工作規劃(c.10) 4.將活動的起迄時間轉為甘特圖。 • 首先，假設所有活動都從「最早開始時間」就開始，並不考慮寬延時間。 • 並開始人力規劃，圖形下半部表示人力資源之需求量。

18. 不考慮任何調整下之人力分配 00年 1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3 任務名稱 工期 寬延時間 需求分析 0 w 0 w 1/10 環境模式建立 2 w 0 w SA[300%] 流琵塑模__ 4 w 0 w SA[400%] 資料塑模 2 w 2 w SA[500%] 模組設計 4 w 0 w SA[400%] 測試計畫 4 w 6 w SA[300%] 00年 琵式編碼__ 0 w 0 w 3/19 1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3 1,200% 1,000% 800% 600% 400% 200% 最大資源量: 600% 600% 1,200% 1,200% 400% 400% 400% 400% 400% 400% SA 過度分派: 分派:

19. 不考慮任何調整下之人力分配 • 上圖中，假設 • 環境模式建立需要3人， • 流程塑模需要4人， • 資料塑模需要5人， • 模組設計需要4人， • 測試計畫需要3人， • 則最高之人力需求為12人，最低為4人，起伏頗大。

20. 工作規劃(c.13) 5.資源過度分配及不平衡的情形可考量人員調配、資源限制等因素，利用寬延時間的彈性，進行資源平滑（Leveling）。

21. 平移活動以達到資源平滑 00年 1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3 任務名稱 工期 寬延時間 需求分析 0 w 0 w 1/10 環境模式建立 2 w 0 w SA[300%] 流琵塑模__ 4 w 0 w SA[400%] 資料塑模 2 w 0 w SA[500%] 模組設計 4 w 0 w SA[400%] 測試計畫 4 w 6 w SA[300%] 00年 琵式編碼__ 0 w 0 w 3/19 1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3 1,000% 800% 600% 400% 200% 最大資源量: 600% 600% 700% 700% 900% 900% 400% 400% 400% 400% SA 過度分派: 分派:

22. 平移活動以達到資源平滑 • 上圖中，利用寬延時間的彈性將「資料塑模」的工作延後兩週所得的人力分配圖。 • 未平滑前的尖峰人力需求為12人，平滑後降為9人。

23. 分割活動以達到資源平滑 00年 1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3 任務名稱 工期 寬延時間 需求分析 0 w 0 w 1/10 環境模式建立 2 w 0 w SA[300%] 流琵塑模_. 4 w 0 w SA[400%] 資料塑模 2 w 2 w SA[500%] 模組設計 4 w 0 w SA[400%] 測試計畫 4 w 4 w SA[300%] 00年 琵式編碼_ 0 w 0 w 3/19 1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3 1,000% 800% 600% 400% 200% 最大資源量: 600% 600% 900% 900% 700% 700% 400% 400% 400% 400% SA 過度分派: 分派:

24. 分割活動以達到資源平滑 • 上圖中，是依分割活動的方法將「測試計畫」活動的工作拆開，結果尖峰人力需求由原來的12人再降為9人，同樣可以達到人力需求的穩定性。

25. 工作規劃(c.18) Try this exercise !

26. 工作規劃(c.19) Critical Path = A-F-G-H

27. 工作規劃(c.20) • 上圖中，假設 • A需要3人， • B需要5人， • C需要2人， • D需要4人， • E需要2人， • F需要6人， • G需要5人， • H需要4人。

28. 工作規劃(c.21) • 經過調整，尖峰人力需求由原來的12人降為11人。

29. 更改管理 • 更改管理(Change Management)是針對文件、程式、工具及開發環境加以控管，所有的更改都在一定的程序下接受管制。

30. 更改管理(c.2) • 更改要求（Change Request）必須經由一定的程序處理。 • 審核小組審核時，要考慮下列議題： • 更改是否必要？有否有替代方案？ • 更改後連帶影響的項目是什麼？是否已一併提出更改？ • 對時程、成本、人員調度的影響有多大？ • 審核小組對提出的更改可以接受、拒絕或做適當的處置，例如：暫時接受但延到下個版本再行更改等。

31. 更改管理(c.3)

32. 更改管理(c.4) • 基線(Baseline)： • 所有列入集中管理的文件、程式、工具、和平台。

33. 品質管理 • 要做好品質必須在開發階段的早期就將 • 品質納入規劃，即所謂的 “Planned In”， • 接著在設計階段把所需要的品質設計進去，稱為 “Designed In”， • 最後才到執行及測試檢驗階段進行稱為 “Test Out”。

34. 品質管理(c.2) • 將品質保證由後階段的測試，移到前階段的分析與設計是一項進步的觀念。 • 因為一個錯誤的發生若未及時去除而延至測試階段，甚至到了顧客手中才發現，則修改之成本將數倍甚至數十倍於一發生便立即去除的成本。

35. 品質管理(c.3) • 兩種常用於軟體開發的品質管理方法為： • 審查(Review) • 檢驗(Inspection)

36. 品質管理(c.4) • 審查(Review) • 是透過會議的方法來找出潛在的錯誤，以確保品質。可在不同的階段進行，要求的正式程度也有不同，正式審查的程序包含下列步驟： 1. 開發者準備審查資料，並事先發給參與審查的人員。 2. 參與審查的人應事先閱讀資料，並依個人專長找出潛在的問題。 3. 選定適當的人當主席。 4. 由開發者向大家提出報告。 5. 審查者依一定的議程及檢核表逐一審查。 6. 審查後應做出審查通過、不通過、或條件通過之決定，若不通過則應修改後擇期再審；條件通過則在滿足附帶條件後便予通過，不必再審。 7. 記錄審查的結果以累積經驗。

37. 品質管理(c.5) • 為使審查能順利進行，並達到儘早發現錯誤的目的，一些重要的會議原則對審查的效果有很大的幫助，茲介紹如下： 1.會議應事先安排議程，並應控制會議時間在2小時內，以提高會議的效率。 2.主席對審查的內容應有充分的瞭解，事先閱讀會議資料才能控制會議的進行，使參與者針對問題及避免發言的內容偏離主題。 3.審查的重點在於指出問題和提供方向，而非提供技術性的解答，以免花太多的時間在細節上。

38. 品質管理(c.6) 4.避免人身攻擊和引起爭辯，主席要適當引導會議的進行，即時進行裁決。 5.審查期間，正式的文件應予凍結，等通過後再解凍以避免不一致。 6.參與審查的人員應包括系統開發者、使用者及品質保證人員，必要時可增加外來的專家或顧問。 7.會議的記錄應有顧客的簽名，表示對系統開發進行到現階段結果之認同。 8.審查之會議記錄應保留，錯誤的發現與解決就是經驗的累積。

39. 品質管理(c.7) • 檢驗(Inspection) • 檢驗和審查有相輔相成的效果，它有別於審查的特點是 1. 由有經驗的專家來檢驗：一般的審查較為浮面，檢驗則可深入技術的問題或專注於較複雜的問題。 2.檢驗設計文件或程式碼，而非只是計畫或構想。 3.檢驗須依特定的步驟進行，其步驟為規劃、對檢驗者的簡報、會前準備、會議進行、重做及跟催。 4.檢驗須有特定的角色扮演，包括主持人、記錄人、閱讀人及原作者等。 5.原作者的參與。原作者在場並參與檢驗可節省檢驗者的時間及快速的進入問題核心。

40. 品質管理(c.8) • 檢驗除了可提早發現錯誤以提高品質外，也可以減低測試的負荷。由於檢驗在錯誤發現上比測試更符合成本效益，因此檢驗也有提高生產力的效果。

41. 風險管理 • 風險可定義為足以危害專案成敗的事件，這些事件未必發生，然一旦發生可能導致嚴重的後果。 • 風險管理也是軟體生命週期(軟體開發過程)的每一階段都該進行，其步驟如下： 風險認定→風險評估→風險排序→風險規劃→風險解決→風險追蹤

42. 風險管理(c.2) 1.風險認定(Risk Identification) • 風險認定在於找出風險的來源，並判定是否屬於風險管理的範圍。 • 專案所涉及的風險，例如： • 人員風險：重要人員的離職或缺乏可勝任的人員。 • 技術風險：使用了錯誤或不成熟的技術、關鍵技術無法突破。 • 顧客風險：顧客需求變動頻繁、使用者配合度不佳、承辦人員變動等。 • 市場風險：同業的競爭導致市場需求變化。 • 政治風險：政策急轉彎，利益衝突等。

43. 風險管理(c.3) 2.風險評估 • 找出風險後必須評估其發生的機率大小，以及一旦發生後可能帶來的損失，兩者的綜合即為風險的大小，總風險的大小可以下表示： Ｒ＝ where Ｒ：總風險大小 Ｐi：第ｉ項風險發生的機率，0 Ｐi  1 Ｃi：第ｉ項風險發生的成本損失 ｎ:　風險項目的總數 • 在實務上，風險機率及風險損失的估計無法非常精確，因此可以不同的等級來代表，例如風險機率分為１至５等，風險損失分為１至１０等，兩者的乘積則視為風險的大小。

44. 風險管理(c.4) 3.風險排序 • 依風險的大小排序，挑出重要的風險項目加以列管。風險的項目很多，風險管理也必須付出成本，因此管理者只能針對重大的風險加以管理。

45. 風險管理(c.5) 4.風險規劃 • 找出重要的風險後，就應該做適當的規劃，並找出最有效的方法來控制風險，以下是一些風險控制的方法： (1) 風險規避： • 使用外包或外購將沒有把握的部分委託外人來做，再依合約要求以達專案的目標。 • 刪除高風險的部分。 (2) 風險分散： • 購買保險。 • 找別人合作。 • 合約中分散責任的歸屬。

46. 風險管理(c.6) (3) 風險降低： • 使用較穩健的設計方法。 • 避免將關鍵性的工作集中在一個人身上。 • 選擇成熟的技術。 • 在合約中明定雙方的權責。

47. 風險管理(c.7) 5.風險解決(Risk Resolution) • 風險解決依據風險規畫的內容去執行。解決的方法可運用模擬法，雛型的建造等。 6.風險追蹤 • 追蹤風險的解決是否有效，若無效應找其他的解決方案。 • 風險也會隨專案的進行而變動，有些消失有些新增，管理者必須定期更新高風險的項目，列入管制並設法解決。

48. 專案的執行 • 在專案的執行過程中，許多專案管理的技巧可以運用，例如 • 人員的組織與領導 • 使用者的參與 • 有效的會議

49. 專案的執行(c.2) • 人員的組織與領導 • 開發人員的組織與領導包括：人員的招募、培訓、團隊建立、激勵、領導等工作。 • 系統分析師能力的優劣對生產力的影響可高達數倍，可知人員挑選及訓練的重要性。系統分析師是資訊系統發展過程中的重要人物。

50. 專案的執行(c.3) • 成功的系統分析師必須俱備四種技巧：分析，技術，管理及人際關係。 • 分析技巧可幫助系統分析師瞭解組織及其功能，找出機會與問題，並分析解決之道。 • 技術技巧幫助分析師瞭解資訊科技的潛能與限制，所以，身為一位分析師必須能設計出一個資訊系統，來幫助使用者解決問題並引導整個系統分析的發展，也要能使用程式語言工具，使用不同的作業系統與電腦硬體平台。