「軟體專案開發程序」(SPDP)之設計
98
0
0
全文
(2) 「軟體專案開發程序」(SPDP)之設計 The Design of Software Project Development Process(SPDP). 研 究 生：李志宏. Student：Chih-Hung Li. 指導教授：鍾乾癸. Advisor：Chyan-Goei Chung. 國 立 交 通 大 學. 電機學院與資訊學院專班 資訊學程 碩 士 論 文. A Thesis Submitted to Degree Program of Electrical Engineering and Computer Science College of Computer Science National Chiao Tung University in Partial Fulfillment of the Requirements for the Degree of Master of Science in Computer Science June 2006 Hsinchu, Taiwan, Republic of China. 中華民國九十五年六月.
(3) 國. 立. 交. 通. 大. 學. 博碩士論文全文電子檔著作權授權書 (提供授權人裝訂於紙本論文書名頁之次頁用). 本授權書所授權之學位論文，為本人於國立交通大學電機資訊學院資 訊學程碩士班 資訊組， 九十四學年度第二學期取得碩士學位之論文。 論文題目： 「軟體專案開發程序」(SPDP)之設計 指導教授：鍾乾癸 教授 ■ 同意 □不同意 本人茲將本著作，以非專屬、無償授權國立交通大學與台灣聯合大學 系統圖書館：基於推動讀者間「資源共享、互惠合作」之理念，與回 饋社會與學術研究之目的，國立交通大學及台灣聯合大學系統圖書館 得不限地域、時間與次數，以紙本、光碟或數位化等各種方法收錄、 重製與利用；於著作權法合理使用範圍內，讀者得進行線上檢索、閱 覽、下載或列印。 論文全文上載網路公開之範圍及時間： 本校及台灣聯合大學系統區域網路. ■ 中華民國 年 月 日公開. 校外網際網路. ■ 中華民國 年 月 日公開. 授 權 人：李志宏 親筆簽名：______________________ 中華民國九十五年六月二十二日.
(4) 國. 立. 交. 通. 大. 學. 博碩士紙本論文著作權授權書 (提供授權人裝訂於全文電子檔授權書之次頁用). 本授權書所授權之學位論文，為本人於國立交通大學電機資訊學院資 訊學程碩士班 資訊組， 九十四學年度第二學期取得碩士學位之論文。 論文題目： 「軟體專案開發程序」(SPDP)之設計 指導教授：鍾乾癸 教授 ■ 同意 本人茲將本著作，以非專屬、無償授權國立交通大學，基於推動讀者 間「資源共享、互惠合作」之理念，與回饋社會與學術研究之目的， 國立交通大學圖書館得以紙本收錄、重製與利用；於著作權法合理使 用範圍內，讀者得進行閱覽或列印。 本論文為本人向經濟部智慧局申請專利(未申請者本條款請不予理 會)的附件之一，申請文號為：____________________，請將論文延 至____年____月____日再公開。. 授 權 人：李志宏 親筆簽名：______________________ 中華民國. 年. 月. 日.
(5) 國立交通大學 論文口試委員會審定書. 本校. 電機學院與資訊學院 碩士在職專班. 資訊. 組. 李志宏. 君. 所提論文:(中文)「軟體專案開發程序」(SPDP)之設計 (英文)The Design of Software Project Development Process (SPDP) 合於碩士資格水準、業經本委員會評審認可。. 口試委員：. 指導教授：. 班主任： 中 華 民 國. 年. 月. 日.
(6) 「. 軟. 體. 專. 案. 開. 發. 程. 序. 」. (. S. P. D. P. ). 之. 設. 計. 指導教授：鍾乾癸. 學生：李志宏. 國立交通大學 電機學院與資訊學院 資訊學程(研究所)碩士班. 摘. 要. 軟體開發專案管理不善常造成專案延誤、預算超支，及推出功能不完整、品 質不佳的系統，加班趕程式進度更是軟體工程師常有的夢魘，此種現象在國內軟 體業界更為常見。 近年來資訊業界試圖在軟體開發專案導入先進的「統一軟體開發流程」 (USDP)」[1]或專案管理方法- 「專案管理知識體系」(PMBOK)」[2]，但許多單 位常因準備不周而告失敗，甚至未謀其利、先受其害。 本論文提出的「軟體專案開發程序」是融合了「統一軟體開發流程」及「專 案管理知識體系」的優點，依實務需求將「統一軟體開發流程」之步驟更為細緻 化，並制定相關管理表單以管制各階段工作之確實完成，經實際應用於政府機構 軟體開發專案，已確認其實用性，且本文所提出「軟體專案開發程序」具有學習 時間短，方法簡單，進度及風險易於掌握等優點，進而提昇專案的成功率。. i.
(7) The Design of Software Project Development Process(SPDP). student：Chih-Hung Li. Advisors：Dr. Chyan-Goei Chung. Degree Program of Electrical Engineering and Computer Science National Chiao Tung University. ABSTRACT. Worse Project Management usually together with delay schedule, over budget, releasing broken and poor quality systems, that is nightmarish for the IT industry, especially in our country. In recently years, many local enterprises were tried to apply Unified Software Development Process (USDP) or Project Management Body of Knowledge (PMBOK) in software development project, however, most of them failed due to insufficient preparation. This research proposed a Software Project Development Process (SPDP), which combines the advantage of USDP and PMBOK. The proposed process is based on the procedures of the Unified Software Development Process; however some project management related procedures and artifacts are added. This process was used by a local software company in executing a government-sponsored software project in 2005. From the result of pilot run, we found the proposed process has the advantages of ease to learning, ease of use, and ease of progress and risk control.. ii.
(8) 誌. 謝. 在交大修業期間的上百個不覺天已大白的日子，或讀書，或寫作 業，或作研究，或寫論文，或趕著完成明天要交付的工作進度，每每 心有戚戚，總想著在畢業論文的誌謝要寫些什麼來紀念這一段不會忘 記的日子。在終將得償所願時，卻充滿著近鄉情怯而無處下筆… 得之於人者太多，感謝各位體恤我一邊工作一邊讀書的各位長官 與同事，尤其是我的指導教授- 鍾乾癸 老師，如果沒有您的耐心、 體諒與撥冗於百忙公務之中的悉心指導，這篇誌謝終將永遠沒有撰寫 的可能性… 最後感謝我的親人，尤其是我的媽媽，從小撫養不太聽話的我長 大，並且在我工作及課業繁忙的三年間幫忙照顧小女，很慚愧在小女 出生後的日子，我才能體察為人父母的用心良苦，還有一直扮演我的 好榜樣的哥哥跟姊姊，另外感謝內子體諒我無數不歸的日子，因為有 你們的成全，我才能沒有後顧之憂地完成學業，最後對不起的是小 女，常常在妳要騎牛牛時老爸已經累垮了，相信以後能有多一點時間 陪伴妳的成長….. iii.
(9) 目. 錄. 中文提要………………………………………………………………………………i 英文提要………………………………………………………………………………ii 誌謝………………………………………………………………………...…………iii 目錄………………………………………………………………………...…………iv 表目錄……………………………………………………………………....…………v 圖目錄……………………………………………………………………....………...vi 一、 緒論................................................................................................................1 1.1 研究背景與動機........................................................................................1 1.2 章節介紹....................................................................................................4 二、 軟體專案開發與管理相關技術探討............................................................5 2.1 開發技術「統一軟體開發流程」簡介....................................................5 2.1.1 「統一軟體開發流程」歷史沿革與特性簡介............................5 2.2. 三、 3.1 3.2. 四、 4.1. 4.2. 五、. 2.1.2 導入「統一軟體開發流程」的優點及桃戰..............................11 管理技術「專案管理知識體系」簡介..................................................14 2.2.1 「專案管理知識體系」歷史沿革..............................................14 2.2.2 「專案管理知識體系」簡介......................................................14 2.2.3 導入「專案管理知識體系」於軟體開發專案的優點..............19 2.2.4 直接運用「專案管理知識體系」於軟體開發專案的挑戰......21 「軟體專案開發程序」之制定..................................................................22 「統一軟體開發流程」及「專案管理知識體系」的整合..................22 「軟體專案開發程序」之各階段程序工作..........................................25 3.2.1. 起動階段(Inception Phase)之程序工作 .....................................25 3.2.2. 詳述階段(Elaboration Phase)之程序工作..................................43 3.2.3. 建構階段(Construction Phase)之程序工作................................57 3.2.4. 移交階段(Transition Phase)之程序工作 ....................................69 「軟體專案開發程序」之成效評估及優缺點..........................................79 「軟體專案開發程序」之成效評估......................................................79 4.1.1 「軟體專案開發程序」之成效評估目的..................................79 4.1.2 「軟體專案開發程序」之成效評估作法..................................79 「軟體專案開發程序」之優缺點檢討..................................................83 4.2.1 「軟體專案開發程序」的優點..................................................83 4.2.2 「軟體專案開發程序」的缺陷..................................................83 結論..............................................................................................................84. iv.
(10) 表 目 錄 表 表 表 表 表 表 表 表 表 表 表 表. 1 軟體專案管理經歷的三個主要階段..................................................................2 2 SPDP起動階段計劃檢核表 ...............................................................................34 3 SPDP起動階段-範疇評估管理表單..................................................................35 4 SPDP起動階段-成本分析表..............................................................................36 5 SPDP起動階段-第一階段可行性評估報告表..................................................37 6 SPDP起動階段-第二階段可行性評估報告表..................................................37 7 SPDP起動階段-第三階段可行性評估報告表..................................................38 8 SPDP起動階段-風險管理表..............................................................................40 9 SPDP起動階段-採購項目確認表......................................................................41 10 SPDP詳述階段-風險管理表............................................................................51 11 SPDP詳述階段-採購進度管制表....................................................................51 12 SPDP詳述階段-專案成員技能評估表............................................................52. 表 表 表 表 表 表 表 表 表 表 表 表 表 表. 13 SPDP詳述階段-專案成員技能訓練管制表....................................................53 14 SPDP詳述階段-客戶配合工作管制表............................................................53 15 SPDP詳述階段-成本預估基準表....................................................................54 16 SPDP建構階段-反覆管制表............................................................................64 17 SPDP建構階段-建構管理稽核表....................................................................65 18 SPDP建構階段-需求變更管制表....................................................................65 19 SPDP建構階段-開發環境稽核表....................................................................66 20 SPDP建構階段-工作改進管制表....................................................................66 21 SPDP建構階段-溝通矩陣表............................................................................67 22 SPDP建構階段-專案預備人員表....................................................................68 23 SPDP移交階段-使用者提出問題管理表........................................................75 24 SPDP移交階段-交付項目管制表....................................................................76 25 SPDP移交階段-常見問題與建議解決方式表................................................76 26 SPDP移交階段-專案獲得經驗記錄表............................................................77. v.
(11) 圖 目 錄 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖. 1 USDP五大工作流程在起動階段的資源分佈比重 ............................................8 2 USDP五大工作流程在詳述階段的資源分佈比重 ............................................8 3 USDP五大工作流程在建構階段的資源分佈比重 ............................................9 4 USDP五大工作流程在移交階段的資源分佈比重 ..........................................10 5 USDP四大階段及五大工作流程的關係圖 ......................................................10 6 PMBOK五大程序群組間關係 .........................................................................17 7 PMBOK不同階段間五大程序群組的關係 ......................................................18 8 PMBOK九大領域與五大程序群組之間的關係 ..............................................18 9 SPDP起動階段之工作流程 ...............................................................................30 10 SPDP詳述階段之工作流程 .............................................................................47 11 SPDP建構階段-甘特圖(工作分解結構) .........................................................55. 圖 12 SPDP建構階段-要徑圖....................................................................................56 圖 13 SPDP建構階段之工作流程 .............................................................................61 圖 14 SPDP移交階段之工作流程 .............................................................................72. vi.
(12) 一、 1.1. 緒論. 研究背景與動機 資訊/軟體產業的發展至今已數十年，與其它產業動輒數百年(如：建 築、機械…等)而至上千年的發展史相比(如：農業、造紙…等)，實屬 於新興產業，然而其迅速發展帶動了各種不同領域之應用，對此，進 步之影響與其它俱有悠久歷史的產業不惶多讓。過去其數十年，軟體 專案開發與管理歷經了如下三個主要階段： 1. 1950 至 1960 年代中期：軟體開發僅屬少數專家的特定領域，一般 而言，軟體開發者也擔任維護者的角色，品質保證的觀念維繫在專 業的信任、良好的顧客關系及服務上，沒有品質確保與品質設計的 觀念。 2. 1960 年代晚期至 1970 年代：由於企業管理資訊系統與資料庫應用 的興起，軟體由藝術創作逐漸普及為企業應用的工具，促成專業軟 體公司及套裝軟體的興起，並引進其它工業產品設計與生產經驗， 包含開發方法、標準、審查制度、檢驗制度、開發工具等等，以加 速軟體發展速度及提升軟體品質。 3. 1980 至 2000 年代初期：由於個人電腦與網際網路的普及，各種應 用軟體需求殷切，縮短軟體開發的生命週期，軟體開發的競爭愈見 激烈，開發成本及時程需有良好控制，以免失去市場競爭力，軟體 工程的方法與工具已不足以應付如此複雜的問題，開始導入管理的 方法。 此三個階段的特性可歸納如下表：. 1.
(13) 表 1 軟體專案管理經歷的三個主要階段. 第一階段. 第二階段. 第三階段. 軟體類別. 訂製型軟體 套裝軟體 特殊功能軟體 應用軟體. 消費性軟體 大型整合性軟體 網路應用軟體. 時間. 1950 至 1960 年 1960 年代晚期至 1970 1980 至 2000 年代初期 代中期 年代. 應用領域. 科學 國防. 企業管理 工程應用. 硬體. 處理能力小 價格昂貴. 迷你電腦與大型電腦 個人電腦與工作店 集中處理為主 網路連接 分散式系統. 軟體開發的重點. 效率 產品功能 程式撰寫技巧 降低錯誤. 品質 生產力 競爭力 創新. 支援工具. 非常少. 逐漸增加. 普遍受重視. 軟體開發的原則. 藝術與技藝. 工程原則. 市場導向 管理與技術並重. 挑戰. 程式撰寫技巧 結構化方法 程序改進 支援工具的開發. 個人工作 網路應用 整合性系統. 縮短開發時程 確保品質 知識的累積 創新. 軟體專案管理雖已受重視，但仍未趨理想，由以下事實可了解其現況： z. Standish Group 研究：52.7%資訊系統專案會透支預算或無法如期 完成(On-time Deliver)，31.1%會中斷進行，只有 16.2%在原訂的預 算下如期完成(Hayes，1997)[12]。. z. 美國政府機關的所有的資訊專案中，只有 18%在原訂的預算下如 期完成(Davis & Wilder，1998)[13]。. z. 1999 年 Information Week 的一篇論文研究了 100 家公司，發現只 有 37%以軟體為主的專案如期完成；42%在原訂的預算下完成 (Gordon，1999)[14]。. 2.
(14) z. 尤其以大型的軟體開發專案，失敗的機率更高達 85%(Ambler， 1999)[15]。. 作者在國內半導體產業的資訊部門擔任軟體開發工作及在軟體公司從 事政府軟體專案開發近九年，深深感受軟體開發專案無法如期完成之 苦，尤其是執行政府部門的軟體開發專案因行政流程導致開發時間較 為短暫、專案需求明確程度較低，民間業者深受煎熬。然作者擔任資 訊部門主管，不得不主動解決此問題，實有必要探討更適當的軟體專 案開發程序以降低公司的風險。 作者學習「統一軟體開發流程」技術，並在公司推廣，部門同仁均利 用此方法來開發軟體，但此方式在軟體專案管理方面的準則卻較少敘 述，因此作者研讀「專案管理知識體系」一書後，深深感受實有必要 結合二者，使公司同仁能更精確地在預定時間內完成專案。本研究即 依此目的而設計，並在作者服務的公司試用。. 3.
(15) 1.2. 章節介紹 本論文之章節安排如下： 第二章 對軟體開發技術之「統一軟體開發流程」及管理技術- 「專案 管理知識體系」進行探討，並分析以上關鍵技術直接運用於軟體開發專 案之實務困難。 第三章 提出「統一軟體開發流程」及「專案管理知識體系」整合為「軟 體專案開發程序」之可行性、方向、作法步驟及範疇，並訂定「軟體專 案開發程序」之各階段工作，包含：目標、主要工作、主要產出、及工 作表單與管理表單樣本。 第四章 為確保「軟體專案開發程序」之實用性，將「軟體專案開發程 序」運用於實務專案，分析「軟體專案開發程序」所帶來之成效，並檢 討應用「軟體專案開發程序」之優缺點。 第五章 為本論文之結論。. 4.
(16) 二、 2.1. 軟體專案開發與管理相關技術探討. 開發技術「統一軟體開發流程」簡介 2.1.1 「統一軟體開發流程」歷史沿革與特性簡介 1987 年，歸納易利信(Ericssion)開發軟體系統的方式(Approach)， 提出「Objectory Process 1.0」。 1996-1997 年間，Ration 整合 1995 年提出的「Objectory Process 3.8」 ，並結合「Rational Approach」及「UML」[3]，提出「Rational Objectory Process 4.1」 。 後來由逐步整合各項新技術，如：資料工程、使用者介面設計、企 業工程…等，提出「統一軟體開發流程」。 「統一軟體開發流程」有別於簡略的軟體生命週期(Software Lifecycle)，務實的將達成使用者需求轉換為軟體系統的過程所需要 的工作項目予以有系統的整理歸納為一組流程及框架 (Framework)，並得以應用於不同領域的軟體系統開發。 「統一軟體開發流程」歸納軟體的開發流程為五大工作流程及四大 階段，其設計具有以下三大特性： 1. 以使用案例驅動(Use-Case Driven)： 傳統的需求搜集多以訪談、觀察資訊化前的作業方式及閱讀標準作 業程序(SOP)等文件方式進行，在系統分析師歸納、吸收後以條列 方式以系統功能為導向記錄以文字記錄需求成為需求規格書，然而 此一方式先天存在許多重大的缺點，舉例如下： 需求規格書是以系統分析師的認知所列出的功能，因此系統分 析師想像的系統常跟使用者預期的系統有重大的差異。 使用者對以系統功能為導向的需求規格書吸收、了解程度不 佳，因此往往匆匆瀏覽過了事，等實際看到、操作到系統時才 發覺不符需求。 有鑑於以上問題，「統一軟體開發流程」納入了使用案例 (Use-Case)、參與者(Actor，Worker)、情節(Scenario)等概念，引導 使用者在需求搜集時能很容易想像、領會未來系統之性質，並藉由 使用者參與程度的提昇，在需求搜集階段即大幅減少使用者與系統 開發者對系統需求的差異，有系統歸納「使用案例」作為系統規格， 並提供後續設計、實作與測試等工作「需求追溯」，並以「使用案 例」作為軟體開發過程之量化管理，並確保使用者提出需求已確實. 5.
(17) 解決。 2. 以架構為中心(Architecture Centric)： 在「統一軟體開發流程」推出前，開發系統之架構文件由於沒有一 定的表達方式，往往僅以一張架構圖及數張簡單的流程圖代表，且 在系統上線後即不再被維護，以致於未來進行系統規模擴增時，往 往遭遇無從下手的困境，「統一軟體開發流程」配合「統一塑模語 言」(Unified Modeling Language，UML)對系統架構進行完整的描 述，以架構為中心實務上將帶來以下重要的好處： 系統架構及早確定，有助於確定系統之技術可行性及計畫 時程之掌握，對於專案風險也較能掌握。 在系統規模擴增或需求變更時，可以藉由這些圖形快速的 找到切入點，並找出變更的方式。 3. 採反覆及增添方式進行(Iterative and Incremental)： 由於使用者及系統開發者對需求的認知確實存在相當的差異，且此 差異會隨開發時間長度而增大，如以瀑布法(Waterfall Approach)方 式進行系統開發，需經過長期開發過程後才發現需求的差異，必須 付出重大的代價進行更改，或使用者被迫妥協使用一個不太符合需 求的系統，此外，由於資訊技術的進展迅速，系統開發者隨之必須 採取不甚熟悉的新技術進行系統開發，很多技術問題往往在程式撰 寫(Implementation/Coding)或測試(Test)階段才發現，此時已沒有充 足的應變時間，於是造成了時程的延宕。 有鑑於以上問題，「統一軟體開發流程」將整個系統切割成一個個 小小的反覆，每次反覆產生一個可以執行的小版本，並透過每次的 反覆增加系統的功能，此一作法讓使用者能在初期完成的小版本中 及時發現與真實需求的差異，於是可以最快的速度進行修正，並預 防尚未開發的部份產生相同的問題，此外，由於在初期的反覆 (Iteration)即經歷整個系統的開發過程(需求搜求，分析，設計，程 式撰寫，測試)，故能及早發現技術問題並從容進行排除。 z 「統一軟體開發流程」的五大工作流程(Workflow) 1. 需求搜集(Requirements)工作流程 需求搜集工作流程的目的為尋求使用者與開發者對系統的共識、精 確捕捉使用者的實際需求、界定系統的範圍，作為評估開發成本與 時間的基礎，其工作包含定義系統願景(Vision)-包含以雛型 (Prototyping)方式設計使用者介面(User Interface)，將願景轉換為使 6.
(18) 用案例模型(Use-case Model)，並制定輔助規格(Supplementary Specification)，以確定系統之非功能性需求。 2. 分析(Analysis)工作流程 分析工作流程目的是把需求搜集工作流程的使用案例轉成軟體設 計師(Software Designer)所關心的應用子系統與類別，藉以確定應 用系統所必需包含之資料模型(Data Model)及執行流程。 3. 設計(Design)工作流程 配合系統佈署之硬體架構，制定軟體系統架構，進而設計各子系統 之詳細邏輯。 4. 實作(Implementation)工作流程 為將設計工作流程的產出進行程式撰寫、單元測試(Unit Test)。 5. 測試(Test)工作流程 將單元測試完成的類別進行整合，將整合完成的軟體進行指標測試 (Benchmark Test)、組態測試(Configuration Test)、功能測試(Function Test)、安裝測試(Installation Test)、整體性測試(Integrity Test)、負載 測試(Load Test)、效能測試(Performance Test)、壓力測試(Stress Test) 等以確保產品品質。 z 「統一軟體開發流程」的四大階段(Phase)： 1. 起動階段(Inception Phase) 此階段的重點在了解專案背景及範疇，決定系統初步架構，進行少 部份之設計實作以評估專案之可行性，並進行專案建議書撰寫，上 述五大工作流程在本階段之資源分佈比重如下：. 7.
(19) 圖 1 USDP 五大工作流程在起動階段的資源分佈比重. 資料來源：The Unified Software Development Process: Figure 13.1 2. 詳述階段(Elaboration Phase) 此階段的重點在制定系統之指標性架構，包含分析、設計及實作出 架構的基準線，並嚐試對風險高的部份進行開發，以降低開發的風 險，並學習使用特定工具與技術、據以安排後續工作時程，上述五 大工作流程在本階段之資源分佈比重如下：. 圖 2 USDP 五大工作流程在詳述階段的資源分佈比重. 資料來源：The Unified Software Development Process: Figure 14.1 3. 建構階段(Construction Phase) 8.
(20) 此階段的重點為實作出完整系統，包含所以系統功能之分析、設計 及程式開發工作，延續上一階段的架構雛型(Prototype)，不斷附加、 更新系統內容，使系統達成可以上線運作的目標，上述五大工作流 程在本階段之資源分佈比重如下：. 圖 3 USDP 五大工作流程在建構階段的資源分佈比重. 資料來源：The Unified Software Development Process: Figure 15.1 4. 移交階段(Transition Phase) 此階段的重點在確保系統用戶可完全熟悉此系統之使用且軟體已 達到足夠的品質水準，並符合軟體需求，工作內容包含修正錯誤、 訓練終端使用者、調整系統加入缺少的必要功能以造出最終的軟體 產品，及建立系統維運之機制以確保未來系統正常運作無虞。上述 五大工作流程在本階段之資源分佈比重如下：. 9.
(21) 圖 4 USDP 五大工作流程在移交階段的資源分佈比重. 資料來源：The Unified Software Development Process: Figure 16.1 z. 上述四大階段及五大工作流程的關係可表示如下：. 圖 5 USDP 四大階段及五大工作流程的關係圖. 資料來源：The Unified Software Development Process: Figure 5.6. 10.
(22) 2.1.2 導入「統一軟體開發流程」的優點及桃戰 運用「統一軟體開發流程」於專案開發具有以下優點： 1. 「統一軟體開發流程」是結合理論與實務經驗的成果，且是在業界 已被廣泛驗證的開發方式，可用以輔助軟體開發，快速增進軟體開 發的品質。 2. 「統一軟體開發流程」以有組織、系統化的方式規劃軟體開發的製 程，提高不同開發者進行軟體開發的品質一致性。 3. 「統一軟體開發流程」以使用者案驅動，有效建立使用者與開發者 間的橋樑，並以視覺化的方式與使用者溝通需求。 4. 「統一軟體開發流程」以架構為中心，並搭配統一描述語言(UML) 作為軟體開發過程的表達方式，與開發者間資訊交流的有效工具， 並達成重要資訊保留的方式。 5. 「統一軟體開發流程」以反覆及增添方式進行軟體開發，改善傳統 軟體開發生命週期(Life-cycle)的重大缺點。 「統一軟體開發流程」解決了許多重要的軟體專案問題，但是直接 應用「統一軟體開發流程」於軟體開發專案仍存在許多挑戰如下： 1. 「統一軟體開發流程」著重於軟體開發問題的解決方案，然而許多 軟體開發專案的問題存在於專案管理上，「統一軟體開發流程」對 此部份問題相關著墨有限。 2. 「統一軟體開發流程」中提出許多先進行的觀念與作法，改善軟體 開發的品質(如：以反覆與增添方式進行開發)，然而，此一作法有 別與傳統里程碑(Milestone)檢驗專案進度的方式，無疑增加了進行 開發工作的負擔。 3. 「統一軟體開發流程」完整規範了軟體開發的過程，可有效增強專 案的透明度，然而也需更巨細靡遺地進行專案規劃及控管，此舉對 傳統的專案經理(Project Manager)產生了重大的挑戰，如果沒有更 良好的管理技能訓練，在落實層面將遭遇困難。. 11.
(23) 4. 專案進度的透明度不佳：軟體開發專案不若其它產業的專案，如建 築業的專案，可以用一眼看出挖地基、搭建模板、堆砌磚塊數量… 等進度，軟體等進度，軟體開發專案常常必須等需求分析、系統設 計、程式撰寫階段完成後，才能明確知道專案進度，且對於其階段 品質，階段的過程中，對軟體開發專案進度往往只能用估計的方法 自由心證。 5. 專案成員異動：成員異動，補充不易，且補充的人對專案開發流程 及專案內容不熟悉，產生更多溝通問題。 6. 專案成員對專案成功要素(Critical Success Factor)的認知不一致：專 案成員對專案成功要素往往存在相當大的認知差異，有的認為如期 完成是最重要的，可能認為在預估成本內完成是最重要的，有的認 為符合使用者需求及沒有軟體缺陷(Bug)是最重要的，共識不足， 工作安排及執行均會產生溝通困難。 7. 脆弱的專案組織：專案成員(包含開發單位及需求單位)往往不是全 職參與專案，有其平時必須進行的既定任務或同時參加多個專案， 當多項工作同時進行時，常依個人或長官認知的優先度來安排工 作，造成專案工作進度掌握不易，因而牽一髮而動全身，造成相關 工作延遲。 8. 管理階層對專案要求不一致：由於缺乏一致的專案管理及文件標 準，造成管理階層對專案的要求不一致，造成專案經理人或專案參 與者的力量不能集中於專案的重要工作，必須花費很多力量作不同 型式的報表或紙上作業(Paper Work)，因而分身乏術，這種情況尤 其出現在規模較大的軟體開發專案或已經發生時程延遲的專案上。 9. 軟體開發專案時程估計過於樂觀：軟體開發專案往往依專案經理的 經驗進行概念性估計，然而由於經驗所限或專案複雜度未被周詳考 量，導致軟體開發專案時程延誤履見不鮮。 10. 使用者對軟體成本觀念認知不佳：使用者對修改軟體的觀念往 往停留在＂花一點時間改一下就好了＂，加上軟體開發專案的透明 程度不佳，頻頻提出修改需求，然而軟體的修改常牽涉到既定之後 續工作及資源規劃、設計的概念及標準、規劃好的軟體架構…等， 加上系統硬體的限制、要小心避免修改後衍生新問題、對其它功能 產生影響…等，因而造成軟體開發專案預算頻頻超支及時程的延. 12.
(24) 誤。 上述問題經分析為專案管理的管理性問題，針對以上問題於以下管理技 術「專案管理知識體系」進行探討，並提出解決方案。. 13.
(25) 2.2. 管理技術「專案管理知識體系」簡介 2.2.1 「專案管理知識體系」歷史沿革 專案管理專家在 80 年代將專案管理技術區分為傳統專案管理與現代專 案管理兩個不同階段，其最重要的里程碑是 1987 年由專案管理協會 (Project Management Institute，縮寫為 PMI)集合眾多各領域專家窮十年 之功制定的「專案管理知識體系」(Project Management Body of Knowledge，縮寫為 PMBOK)」 ， 「專案管理知識體系」經歷幾次大幅的 修正，並於 2000 年的版本趨於完整。 2.2.2 「專案管理知識體系」簡介 「專案管理知識體系」將專案管理所需涵蓋的知識領域區分為九大 知識領域，將專案進行過程為五大程序群組，茲將九大知識領域與 五大知識群組介紹如下： z 九大知識領域(Nine Knowledge Area)： 1. 專案整合管理 (Project Integration Management)： 目的在確保專案需執行的各項活動均能相互協調及有效整合的一 系列程序與方法，其涉及在相互競爭的目標和備選方案間作一取 捨，專案整合管理包含下列子程序： 專案計劃制定(Project Plan Development)。 專案計劃執行(Project Plan Execution)。 整合變更控制(Integration Change Control)。 2. 專案範疇管理(Project Scope Management) 目的在確保所有必要執行的工作事項均已被列入專案中，俾使專案 能成功完成的一系列過程，其主要工作重點是定義及控制那些工作 項目應該或不應該包含在專案之中，專案範疇管理包含下列子程 序： 專案起始(Initiation)。 範疇計劃(Scope Planning)。 範疇定義(Scope Definition)。 範疇確認(Scope Verification)。 範疇變更控制(Scope Change Control)。 3. 專案時間管理(Project Time Management)： 14.
(26) 目的在確保專案能如期完成的一系列過程，其包含將專案產出分解 成一個個完成專案所必須包含的明確工作項目(活動)，安排它們間 的相關工作順序，並對時間進行妥善估計，並在專案執行過程中進 行管控，包含下列子程序： 活動定義(Activity Definition)。 活動排序(Activity Sequencing)。 活動時程估算(Activity Duration Estimation)。 時程制定(Schedule Development)。 時程控制(Schedule Control)。 4. 專案成本管理(Project Cost Management)： 目的在確保專案能夠在核定預算範圍內完成的一系列過程，包含規 劃所需資源，進行成本預估，完成專案預算編列，並在專案過程中 對成本進行控制，專案成本管理包含下列子程序： . 資源規劃(Resource Planning)。 成本預估(Cost Estimating)。 預算編列(Cost Budgeting)。 成本控制(Cost Control)。. 5. 專案品質管理(Project Quality Management)： 目的在確保專案能夠以規劃的品質滿足所有需求的一系列過程，其 包括決定品質政策、目標和責任的所有活動項目，專案品質管理包 含下列子程序： 品質規劃(Quality Planning)。 品質保證(Quality Assurance)。 品質管制(Quality Control)。 6. 專案人力資源管理(Project Human Resource Management)： 目的在確保以最有效的方式運用人員以完成專案工作與活動的一 系列過程，其管理的對象為所有的專案利害關係人(Stakeholders)， 包含出資人、顧客、合作夥伴及個別貢獻者，專案人力資源管理包 含下列子程序： 組織規劃(Organizational Planning)。 人員獲得(Staff Acquisition)。 團隊制定(Team Development)。 7. 專案溝通管理(Project Communication Management)： 目的在確保能適時且妥當地將專案相關的資訊予以產生、蒐集、傳. 15.
(27) 送、儲存、彙整給所有專案關係人的一系列管理過程與方法，其目 的在提供促使專案有關人員的知識及資訊可有效的連結，專案溝通 管理包含下列子程序： 溝通規劃(Communication Planning)。 資訊散佈(Information Distribution)。 績效報告(Performance Reporting)。 結案管理(Administrative Closure)。 8. 專案風險管理(Project Risk Management)： 目的在以系統化方法辨識、分析、和解決專案各種風險問題的過 程，包括將各種對專案目標達成有正面影響之所有事件的發生機率 與其結果極大化，並使有負面影響之事件的發生機率與衝擊降低到 最小，專案風險管理包含下列子程序： 風險管理規劃(Risk Management Planning)。 . 風險辨識(Risk Identification)。 風險定性分析(Qualitative Risk Analysis)。 風險定量分析(Quantitative Risk Analysis)。 風險回應規劃(Risk Response Planning)。 風險監控(Risk Management and Control)。. 9. 專案採購管理(Project Procurement Management)： 目的在確保專案向外採購的物品或委外的服務能順利獲得，以「買」 方的角度去制定必要的程序，包含下列子程序： 採購規劃(Procurement Planning)。 邀商規劃(Solicitation Planning)。 邀商作業(Solicitation)。 商源評選(Source Selection)。 履約管理(Contract Administration)。 合約終結(Contract Closeout)。 z. 五大程序群組(Five Process Groups)： 所有的專案管理過程可被區分為五個程序群組，而每個程序群組都 包含有一個以上的過程，五大程序群組為： 1. 起始程序(Initiating Processes)： 確認一專案或階段應開始進行並獲得執行之許可。 2. 計劃程序(Planning Processes)： 設計及維持一可實踐計劃以利具體執行足以滿足客戶需求的專案。. 16.
(28) 3. 執行程序(Executing Processes)： 運用及協調人及其資源以實現此專案目之所有活動。 4. 管制程序(Controlling Processes)： 藉品質監控及進度衡量以確保專案目標之有效達成，並視情況採必 要的改善措施。 5. 結尾程序(Closing Processes)： 正式驗收專案的結果，並按計劃終結所有作業。 z. 五大程序群組間關係可表示如下：. 圖 6 PMBOK 五大程序群組間關係. 資料來源：A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 2000 Edition: Figure 3-1 z. 一個專案間可能存在不同階段(Phase)，在不同階段間五大程序群 組的關係可表示如下：. 17.
(29) 圖 7 PMBOK 不同階段間五大程序群組的關係. 資料來源：A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 2000 Edition: Figure 3-3 z. 上述九大領域與五大程序群組之間的關係可以表示如下表：. 圖 8 PMBOK 九大領域與五大程序群組之間的關係. 資料來源：A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 2000 Edition: Figure 3-9. 18.
(30) 2.2.3 導入「專案管理知識體系」於軟體開發專案的優點 「專案管理知識體系」所揭櫫的重點為：明確設定專案目標、完善 規劃完成專案所需的各項計劃、落實專案計劃中各項工作、以制度 化的方式管控專案的變異及工作品質，並配合系統化方法累積專案 經驗，以提高每一個專案的成功機率，其優點可歸納如下： 1. 增進專案任務的明確性： 藉由在專案計劃中制定明確的專案目標、範疇、時程、所需資源、 各項專案管理計劃，使專案成員明確了解專案任務。 2. 增進專案進度的透明度： 透過客觀標準的專案評價手法(如：Earned Value Management)，定期 檢視專案最重要的時程及成本。 3. 增進專案過程的秩序性： 經由排定的工作順序，避免因多項工作同時進行或多項工作需要相 同資源所造成衝突。 4. 增進專案工作的完整性： 透過工作分解結構(Work Breakdown Structure)的手法分解專案的工 作，並於各項工作訂定明確時程與可檢視的工作成果，避免因考慮 不周詳而遺漏重要工作。 5. 突顯專案的重點工作： 藉由網路圖(Network Diagram)的手法找出專案要徑(Critical Path)上 的工作，並投注心力於這些少數的重要工作，可以最小的成本大幅 降低專案延遲的可能性。 6. 提高專案的品質： 藉由明確定義工作計劃及預期產生工作成果(Deliverable)、檢視 (Review)專案中每一個里程碑(Milestone)的各項工作成果，確實因應 專案的問題及風險，確保專案中各項工作均被確實執行。 7. 降低專案的風險： 主動發掘、量化、制定風險的回應計劃、採用解決、規避、移轉或 接受等方式因應風險、並定期監控風險的狀態，以減少專案的非預. 19.
(31) 期因素，減少專案失敗的機率，進而提高專案成功率。 8. 促進專案經驗的累積： 以有系統的方式累積專案經驗，並經由回饋機制提昇專案管理的能 力，藉由已累積專案經驗，避免因參與人員經驗不足而影響專案品 質，及降低專案失敗的風險。. 20.
(32) 2.2.4 直接運用「專案管理知識體系」於軟體開發專案的挑戰 導入適當的管理方法確可降低軟體開發專案的風險問題，有效提昇 專案的成功率，但在導入管理方法時，將面臨下列的挑戰： 1. 學習成本： 專案管理是一門相當專門的學問，國外有專門的碩士學程，要在組 織內廣泛提昇專案管理的專業知識，必須耗費大量的人力及物力， 業界希望避開艱深的理論研究、縮短或免除摸索或嚐試錯誤的時 間，可以快速學習、馬上應用，加上導入初期，因技能不熟悉可能 影響正在進行專案的品質，此為導入管理方法必須面對的實質挑 戰。 2. 建立及推行組織軟體開發專案管理標準 由於「專案管理知識體系」係針對各行各業的專案廣泛適用的方向 進行，並非針對軟體開發專案制定，導入此管理方法，於軟體開發 專案管理必須投入大量資源以建立專案管理標準及程序，此牽涉高 度的溝通、爭論及妥協，因此在建立及推行組織專案管理標準及程 序的過程中，專案戰力的折損將是難以避免。 3. 增加額外的專案管理工作： 軟體專案管理的目的是透過有系統的方法妥善安排專案計劃，嚴密 監控、追蹤專案工作進度，防範並提早排除可能導致專案失敗的因 子，並累積專案管理的經驗，雖然這些方法雖然有效增進了專案成 功的可能性，但無可避免的增加了專案管理工作的負擔及複雜性， 如何適切引用管理法，盡可能降低額外負擔的情形，獲得專案最大 的效益，亦為必須因應的重要挑戰。. 21.
(33) 三、 3.1. 「軟體專案開發程序」之制定. 「統一軟體開發流程」及「專案管理知識體系」的整合 軟體開發專案中如果只擁有軟體開發技術，在進行小型軟體開發專案 時還勉能負荷，隨著在進行的軟體開發專案規模漸漸增大、參與的人 員與所需的資源增加時就會顯得力不從心或分身乏術，這樣的專案往 往無法有通盤可行的計劃，只能見招拆招，專案落入就會必須草草收 場或沒有結案日的牢籠；相反的，如果只擁有專案管理技術，往往因 為紮實地以滿足使用者的方式完成軟體開發的各個工作流程：需求搜 集- 分析- 設計- 實作- 測試，軟體開發的技術問題總是這類型專案延 遲與超支的關鍵因素。 「統一軟體開發流程」聚焦於「軟體開發技術」 ，提出許多前瞻的務實 作法， 「專案管理知識體系」則以有系統的方式組織專案的流程、必須 俱備的知識，這些技術在進行軟體開發專案時確可有互補的效果。 分析「統一軟體開發流程」及「專案管理知識體系」兩大技術後，訂 定出整合方向如下： 1. 由於軟體開發專案在實務上通常具有分階段交付及付款之特性，整 合後之「軟體專案開發程序」階段以「統一軟體開發流程」定義之 「四大階段」為主。 2. 因「專案管理知識體系」之定義流程對象為任意行業之專案，「統 一軟體開發流程」之定義流程對象為軟體開發，故整合後之程序以 「統一軟體開發流程」規範之工作為主體，增加軟體公司承接業主 之軟體標案進行系統開發所需額外具備工作，本整合需對上述工作 進行整理、串連為可行之工作流程。 3. 因「專案管理知識體系」將任意行業專案之各項工作特性歸類為「五 大程序」，以利使用分類之工作特性進行分別管理，本整合需將上 述工作進行「五大程序」歸納，以利管理工作之進行。 4. 使用「專案管理知識體系」之「九大知識領域」進行本階段主要問 題檢視，並分析提出解決方案。 5. 因應工作流程中以「專案管理知識體系」精神制定各階段之重要工 22.
(34) 作表單與管理表單樣本，以符合業界對軟體開發專案的快速應用需 求。 6. 充份考量軟體開發專案之「軟體開發技術」- 「統一軟體開發流程」 及「專案管理技術」- 「專案管理知識體系」，制定「軟體專案開 發程序」(Software Development Project Process)，簡寫為「SPDP」， 以符合整合目的。 依上整合方向，本程序之各階段採以下六大作法步驟，進行程序制訂， 茲分述如下： 1. 制訂階段之目標 為確保階段目標得以如質完成，本作法步驟之主要目標為明確定義 各階段之目標。 2. 制訂階段之主要工作 為使專案對各階段之工作內容有所依循，本作法步驟之主要目標為 以「統一軟體開發流程」之工作為主軸，增加軟體公司承接業主之 軟體標案進行系統開發所需額外具備工作，進行明確定義各階段之 各項主要工作。 3. 制訂階段之工作流程 為使業界能按部就班使用本程序進行專案，本作法步驟之主要目標 為將上述之各項工作之優先順序確認後，以「專案管理知識體系」 之「五大程序」之工作類型進行歸納、排列為本「軟體專案開發程 序」之工作流程。 4. 制訂階段之主要工作產出 為確保各階段之主要工作得以如質完成，本作法步驟之主要目標為 明確定義各階段工作之主要產出。 5. 制訂階段之管理問題分析 為避免專案執行過程因管理性問題而造成執行困難之可能性，本作 法步驟之主要目標為利用「專案管理知識體系」之「九大知識領域」 進行本階段主要問題檢視，並分析提出解決方案。 6. 制訂階段管理問題之解決方案及管理表單樣本 為符合業界對軟體開發專案的快速應用需求，本作法步驟之主要目. 23.
(35) 標為因應工作流程中以「專案管理知識體系」之精神制定各階段之 重要管理表單樣本，包含常用之管理表單樣本、使用方法及使用時 機說明。 「軟體專案開發程序」包含以下兩大部份： z. z. 流程： 以「統一軟體開發流程」之各項工作流程為主軸，增加軟體公司承 接業主之軟體標案進行系統開發所需額外具備工作，將上述之各項 工作之優先順序確認後， 「專案管理知識體系」之五大程序之工作類 型進行歸納、排列為本「軟體專案開發程序」之工作流程，本文第 四章，我們將逐一介紹程序中四大階段之的各項工作。 工作與管理表單： 除了在「軟體專案開發程序」中制定各項工作，為了使業界得以快 速運用本程序，本程序亦包含常用的樣版，包含常用之管理表單樣 本、使用方法及使用時機說明。. 24.
(36) 3.2. 「軟體專案開發程序」之各階段程序工作 「軟體專案開發程序」之各階段皆包含四大階段，其目標、主要工作、 工作流程、主要工作產出、可能問題及因應對策及管理表單如下： 3.2.1. 起動階段(Inception Phase)之程序工作 1. 起動階段之目標： 在招標性軟體開發專案的起動階段，由業主進行招標公告開始，至 專案進行開標，確認是否得標為止，軟體公司在本階段必須完成以 下重要工作項目： z 確認專案的可行性。 z 提出專案架構的適用性。 z 辨識專案的風險。 z 預估專案之工作時程。 z 評估專案之工作成本。 z 提出專案建議書。 最後開標時若雀屏中選，則贏得軟體開發專案之合約。 2. 起動階段之主要工作： 依「統一軟體開發流程」(USDP)所述之主要工作，配合專案管理知 識體系的精神，定義本階段工作如下： z USDP-起動階段早期工作 (1)起動階段前置工作(Before the Inception Phase Begins; USDP13.2.1)：在業主公告招標後，專案業務人員於獲得招標資訊後進 行領標工作，以取得各項招標文件，如：「招標須知」、「徵求需 求說明書」 、 「招標投標及契約文件」…等，經業務及工程評估負 責人詳閱後粗略評估公司參與該標案之可行性後，並考量公司策 略，完成「第一階段可行性評估報告表」，以決定是否放棄投標 或繼續進行後續工作，考量本程序定位，本工作名稱應調整為「 招標文件取得與評估」。 (2)規劃起動階段(Planning the Inception Phase; USDP- 13.2.2)：若決 定進行投標，則進行專案工作團隊成員工作分派及時程安排，通 常由業務及研發主管共同協商，而後以開會方式向團隊成員說. 25.
(37) 明，並分發相關資料，即刻進行相關工作。 (3)延伸系統願景(Expanding the System Vision; USDP- 13.2.3)：本工 作之主要作法通常包含以下步驟： 詳閱招標文件中「徵求需求說明書」(RFP)之「專案概述」 、 「交 付產品項目」 、 「階段與時程」 、 「功能性需求」 、 「非功能性需求」 、 「公告預算金額」…等。在詳閱招標文件過程中，除對專案之 概略性了解，另須彙整對本專案之相關疑問，並將疑問為兩大 類- 「不需訪談業主或專案相關人員疑問」及「需訪談業主或 專案相關人員疑問」，並分別用以下兩種方式進行處理： A.「不需訪談業主或專案相關人員疑問」：此類問題之處理方式為 搜集領域知識進行自修，請教領域專家…等。 B.「需訪談業主或專案相關人員疑問」：此類問題之處理方式邀約 並訪談業主或專案相關人員，進行此類疑問之釋疑，並進行專案 背景與預期效益之了解，包含相關人員對專案之期望、範疇、需 求重點及可能競爭者等資訊，與此專案有關之現有系統使用情況 及問題搜集。 (4)可行性評估(Setting the Evaluation Criteria; USDP- 13.2.4)：當專 案經理取得足夠之專案資訊後，會設定階段評估條件來進行可行 性評估，一般常見之評估條件如下： A.確認系統範疇之了解程度(Resolve System Scope)。 B.階段中模糊的需求之澄清程度(Resolve Ambiguities in the Requirements Needed in this Phase)。 C.候選架構資訊是否明確(Establish a Candidate Architecture)。 D.關鍵風險是否有明確的因應方案(Mitigate the Critical Risks)。 E.初期的商業效益判斷是否已經完成(Judge the Worth of the Initial Business Case)。 在對上述條件進行初步評估後，進行「第二階段可行性評估報 告表」撰寫，決定是否放棄投標或繼續進行後續工作。 z USDP-執行需求訪談至設計之核心工作 (5)獲得大部份系統需求(Capture the Requirements; USDP- 13.4.1)： 本工作為本階段之重點項目，主要目的為獲知系統需求，其工作 主要包含四項行動(Activities)如下： A.表列候選需求(List Candidate Requirements)。 B.了解系統內涵(Understanding the System Context)。 C.獲得功能性需求(Capture Functional Requirements)。 26.
(38) D.獲得非功能性需求(Capture Nonfunctional Requirements)。 (6)候選架構分析(Analysis; USDP- 13.4.2)：本工作為將需求用物件 模型(Object Model)作精確表達，產出粗略的分析模型(Analysis 作為規範候選架構之用，在業主未規範需進行雛型展示的案子 中，只有少數把握度低及風險性高(約 10%)的需求將在本階段優 先進行分析、精煉詳述完成，其它把握度高之需求則可跳過「分 析」、「設計」、「實作」與「測試工作」，直接進行成本分析，本 工作主要包含三項行動： A.架構分析 (Architectural Analysis)。 B.分析使用個案(Analyze a Use Case)。 C.類別與包裝設計(Analyze a Class and Analyze a Package)。 (7)候選架構設計(Design; USDP- 13.4.3)：本工作為將分析工作產出 轉換為設計模型(Design Model)的候選架構(Candidate Architecture)， 在業主未規範需進行雛型展示的案子中，只對極 少數把握度不足的使用者介面或演算法(約 5%)可使用快速開發 技術來進行雛型設計，利用雛型展示使專案關係人(Stakeholders) 相信專案團隊可達成專案的需求，並證實專案過程中不致因極少 數把握度不足的使用者介面或演算法而失敗，本工作主要包含三 項行動： A.架構設計 (Architectural Design)，包括硬體架構及軟體架構之初 步設計。 B.設計使用個案(Design a Use Case)。 C.設計類別與子系統(Design a Class and Design a Subsystem)。 (8)概念驗證實作(Implementation; USDP- 13.4.4)：專案經理可決對 是否對以上極少數把握度不足的使用者介面或演算法進行雛型 實作，以證實候選架構的可行性，如果考量資源有限性及把握度 夠高，也可只產出候選架構描述即結束本階段，不需進行實作。 (9)概念驗證測試(Test; USDP- 13.4.5)：由於雛型展示之雛型有別於 正在運作之系統，故有請測試工程師對實作之雛型進行測試之需 求，並嚐試撰寫部份探索性之測試計劃。 z USDP-樹立初期的商業效益 (10) 描述評估成本(Outline Business Bid; USDP- 13.5.1)：對本專案 進行成本估價，包含硬體、套裝軟體授權費用…等等外購項目之. 27.
(39) 詢價，人力成本則依軟體候選架構進行每一個子系統之人力預估 後，加總各子系統之需求人日作為開發此系統所需人力，再乘以 每人日之成本作為開發該子系統所需成本，此外也可利用本專案 與過往之基準專案進行比較來決定商業價格，考量本程序定位， 本工作名稱應調整為「進行成本分析」。 (11) 預估投資報酬率(Estimate Return on Investment; USDP13.5.2)：預估本專案開發軟體完成後，業主可從導入本專案開發 軟體獲得之效益，促進業主委託本團隊進行軟體開發之意願，並 就供、需因素決定投標價格，並完成「第三階段可行性評估報告 表」，並考量專案投資報酬率，以決定是否放棄投標或繼續進行 後續工作，考量本程序定位，本工作名稱應調整為「分析專案預 期效益」。 z USDP-評價起始階段工作 (12) 評價起始階段(Assess the Iterations in the Inception Phase; USDP- 13.6)：利用評估條件，對起始階段之成果進行評價，以 確保階段目標已經完成，常見之評價條件如下： A.確認系統範疇之了解程度。 B.階段中模糊的需求之澄清程度。 C.候選架構資訊是否明確。 D.關鍵風險是否有明確的因應方案。 E.初期的商業效益判斷是否已經完成。 z. SPDP-因應本程序為軟體公司承接業主之軟體標案進行系統開 發而須完成之工作 (13) 撰寫投標建議書：投標建議書一般由候選之專案經理進行撰 寫，並由以下兩個階段完成： A.於業務人員取得業主提供之徵求建議書後，依專案團隊之現有專 案執行方式進行專案共通性章節之撰寫，如：「公司簡介」、「專 案管理方法」、「建構管理方法」…等。 B.歸納上述各項技術評估工作後，依各項工作之產出進行專案特定 性章節之撰寫，如： 「解決方案建議」 、 「專案組織」 、 「成本分析」… 等。 本工作除產出「投標建議書」外，另外會將「投標建議書」之重 點製作為「建議書簡報」。 (14) 進行投標：在撰寫建議書後，於截標日前完成投標動作，並依 28.
(40) 業主規定完成投標建議書介紹，以進行投標建議書評審、議價等 動作。 (15) 建議書簡報：在完成投標及通過資格審查後，則會由業主召開 建議書簡報會議，專案團隊將對評審進行建議書內容之簡報說明 及必要之雛型展示。 (16) 接獲開標結果：由業主正式公佈評審結果及得標廠商，如果結 果為得標，則進行議價、簽約，否則本專案即召開投標檢討會， 檢討本次開標結果失敗原因供後續投標參考，並宣佈專案團隊本 專案宣告終止。 (17) 議價及議約：在接獲開標結果後即展開議價之價格策略制定及 專案合約審訂，並於議價及議約後進入後續詳述階段(Elaboration Phase)。 3. 起動階段之工作流程： 將上述之各項工作之優先順序確認後，「專案管理知識體系」之五 大程序之工作類型進行歸納、排列為本起動階段之工作流程如下：. 29.
(41) 圖 9 SPDP 起動階段之工作流程. 4. 起動階段之主要工作產出： 起動階段之主要交付項目(Artifact)為「投標建議書」及「建議書簡 報」，除專案共通性章節，如：「公司簡介」、「專案管理方法」、「建 構管理方法」…等可依專案團隊之現有專案執行方式進行撰寫，其 它專案特定性章節將於前述起動階段之各項工作中陸續產出，起動 階段各項工作之產出如下： (1)招標文件取得與評估：業主提供之各項招標文件，如：「招標須 知」 、 「徵求需求說明書」 、 「招標投標及契約文件」…等，團隊內 部產出則為「第一階段可行性評估報告表」。 (2)規劃起動階段：起動階段之工作計劃。 30.
(42) (3)延伸系統願景：專案之「願景」 、 「範疇」 、 「需求重點」及「可能 競爭者」…等資訊及「業務模型」，後續據以分析提出「投標建 議書」中之「解決方案建議」。 (4)可行性評估： 「階段評估條件列表」 ，用以確保達成階段之主要目 標，團隊內部產出則為「第二階段可行性評估報告表」。 (5)獲得大部份系統需求：使用案例排序後之列表，此產出為「投標 建議書」中「候選需求列表」 、 「系統內涵描述」 、 「功能性需求描 述」、「非功能性需求描述」之主要內容。 (6)候選架構分析：定義之「子系統」及「分析模型」，後續據以分 析提出「投標建議書」中之「解決方案建議」。 (7)候選架構設計(架構設計)：候選架構之「架構圖」 ，此產出為「投 標建議書」中「系統架構建議」之重要項目。 (8)概念驗證實作： 「使用者介面雛型」及「演算法雛型」 ，此產出為 「建議書簡報」中「雛型展示」之主要內容。 (9)概念驗證測試：「雛型測試結果」與「測試計劃之樣本」，「測試 計劃之樣本」為「投標建議書」中「測試方法說明」之主要內容。 (10) 進行成本分析： 「專案成本分析表」及「專案成本分析圖」 ，此 產出為「投標建議書」中「專案成本分析」之內容。 (11) 分析專案預期效益： 「專案預期效益說明」 ，此產出為「投標建 議書」中「投標價格」及「專案預期效益」之內容，團隊內部產 出則為「第三階段可行性評估報告表」。 (12) 評價起始階段：起始階段之工作內容及成果是否完成，且符合 專案目標。 (13) 撰寫投標建議書： 「投標建議書」及「建議書簡報檔」 ，供「進 行投標」及「建議書簡報」之用。 (14) 進行投標：收文憑據/押標金收據。 31.
(43) (15) 建議書簡報：進行建議書簡報及回答評審詢問之問題。 (16) 接獲開標結果：是否得標之正式結果通知，如為得標，則通知 議價及簽約時間。 (17) 議價及議約：專案之正式合約內容。 5. 起動階段之管理問題分析： 考量本階段限制及特性，彙整實務常見之管理問題如下： (1)階段參與人員整合問題：各項工作此階段之時程緊迫，不確定因 素多，且經由不同人負責，工作順序及成果又必須緊密整合，如 無有效管理方式，可能因牽一髮而動全身，影響整體階段成果。 (2)階段範疇認知不當問題：階段評估之專案範疇廣泛且時間有限， 如無有效管理方法，可能無法依範疇之掌握度而進行適切之深度 評估，而導致部份重要專案範疇認知不當，小則影響開標結果， 大則得標後因範疇認不當，而造成無法結案。 (3)階段時間短暫問題：本階段時程相當短暫，各項工作如無有效工 作時間分配安排及管理方法，可能到本階段末期，才發現仍有許 多工作尚未完成。 (4)階段評估專案成本客觀性問題：因成本評估人員之經驗或疏失而 造成專案成本低估或部份成本項目漏估，導致實際專案執行成本 大幅超出預期，甚至不符成本。 (5)對把握度不足專案投入之階段費用損耗問題：每個專案的投標成 本相當高(投入各項工作之人力、建議書與簡報檔大量印製… 等)，如果無論是否把握度如何皆進行投標將產生大量成本耗費。 (6)建議書提出架構無法滿足專案效能需求問題：由於本階段時間短 暫，無論就時間或以成本考量都難以對建議書提出架構進行完整 建置及效能驗證，因此可能提出之架構將無法滿足專案效能需 求，造成專案驗收之困難。. 32.
(44) (7)階段參與人員之工作調配問題：因本階段部份參與之技術人員可 能非專職進行本階段，因此可能因投入程度不足而無法產出完整 且周全的建議書。 (8)階段參與人員之間相互溝通問題：階段參與成員可能因工作默契 不足，又因本階段時間相當有限，無法妥善進行相互溝通之磨 合，導致因參與成員間之溝通方式不同，而造成資訊傳遞不良。 (9)專案風險無法有效掌握及回應問題：本階段對專案存在之重大風 險尚未完全搜集、辦識及客觀評價、尚未提出適當之因應計劃並 有效管理，導致無法得標或得標後難以結案。 (10) 建議提出之採購項目無法如期完成問題：建議提出之採購項 目，包含：套裝軟體版權及硬體…等，因上游廠商之庫存或交期 等因素無法如期完成採購，造成專案無法如期順利結案。 6. 起動階段管理問題之解決方案及管理表單樣本： 上述問題可以「專案管理知識體系」之「九大知識領域」進行歸納 如下： (1)階段參與人員整合問題：整合管理(Integration Management)問 題。 (2)階段範疇認知不當問題：範疇管理(Scope Management)問題。 (3)階段時間短暫問題：時間管理(Time Management)問題。 (4)階段評估專案成本客觀性問題：成本管理(Cost Management)問 題。 (5)對把握度不足專案投入之階段費用損耗問題：成本管理(Cost Management)問題。 (6)建議書提出架構無法滿足專案效能需求問題：品質管理(Quality Management)問題。 (7)階段參與人員之工作調配問題：人力資源管理(Human Resource 33.
(45) Management)問題。 (8)階段參與人員之間相互溝通問題：溝通管理(Communication Management)問題。 (9)專案風險無法有效掌握及回應問題：風險管理(Risk Management) 問題。 (10) 建議提出之採購項目無法如期完成問題：採購管理 (Procurement Management)問題。 上述各項問題可以參考「專案管理知識體系」之「九大知識領域」， 在階段各項工作提出解決方案及管理表單如下： (1)階段參與人員整合問題：藉由制定「規劃起動階段」工作運用之 「起動階段計劃檢核表」(請參閱表 2)，輔助階段中各項工作安 排，並進行各項工作進度情況管理，其應用方法、時機及表單樣 本如下： A.應用方法：於「規劃起動階段」工作輔助階段中各項工作安排， 並進行各項工作進度及情況管理。 B.應用時機： a. 填表：於「規劃起動階段」工作開始時進行填寫。 b. 檢視及修改：每天定時進行實際工作情況檢討，並依實際 工作情況進行內容調整。 C.表單樣本： 表 2 SPDP 起動階段計劃檢核表 專案名稱：. 階段工作負責人：. 項次. 工作項目. 1. 招標文件取得與評估 規劃起動階段 延伸系統願景 可行性評估 獲得大部份系統需求 候選架構分析 候選架構設計 概念驗證實作 概念驗證測試 進行成本分析 分析專案預期效益 撰寫投標建議書 進行投標 建議書簡報. 2 3 4 5 6 7 8 9 10 11 12 13 14. 工作負責人 其它參與人員. 34. 工作時程. 交付成果項目. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. /. /. ~. /. /. 確認者.
(46) (2)階段範疇認知不當問題：藉由制定「獲得系統需求」工作運用之 「範疇評估管理表單」(請參閱表 3)，管理各範疇之掌握度，以 利決定適切之評估深度，其應用方法、時機及表單樣本如下： A.應用方法：於「獲得系統需求」工作管理各範疇之掌握度，以利 決定適切之評估深度。 B.應用時機： a. 填表：於「獲得系統需求」工作開始時進行填寫。 b. 檢視及修改：每天定時進行檢討，新增剛獲得之系統範疇 評估項目。 C.表單樣本： 表 3 SPDP 起動階段-範疇評估管理表單. 專案名稱： 項次. 階段工作負責人：. 候選需求名稱 評估者. 相關經驗評估 相關程度 相關經驗專案名稱 確認者 □>80% □>60% □>40% □>20% □<20% □>80% □>60% □>40% □>20% □<20% □>80% □>60% □>40% □>20% □<20% □>80% □>60% □>40% □>20% □<20% □>80% □>60% □>40% □>20% □<20% □>80% □>60% □>40% □>20% □<20% □>80% □>60% □>40% □>20% □<20% □>80% □>60% □>40% □>20% □<20% □>80% □>60% □>40% □>20% □<20% □>80% □>60% □>40% □>20% □<20%. (3)階段時間短暫問題：藉由制定「規劃起動階段」工作運用之「起 動階段計劃檢核表」(請參閱表 2)，輔助階段中各項工作安排， 並進行各項工作進度情況管理，其應用方法、時機及表單樣本如 下： A.應用方法：於「規劃起動階段」工作輔助階段中各項工作安排， 並進行各項工作進度情況管理。 B.應用時機： a. 填表：於「規劃起動階段」工作開始時進行填寫。 b. 檢視及修改：每天定時進行實際工作情況檢討，並依實際 工作情況進行內容調整。 C.表單樣本：(請參閱表 2) (4)階段評估專案成本客觀性問題：藉由制定「進行成本分析」工作 運用之「成本分析表」(請參閱表 4)，包含軟體開發專案之常見 成本項目，以避免因成本評估人員之經驗或疏失而造成專案成本 低估或部份成本項目漏估，導致實際專案執行成本大幅超出預. 35.
(47) 期，甚至不符成本，其應用方法、時機及表單樣本如下： A.應用方法：於「進行成本分析」，以進行客觀分析及掌握之專案 成本。 B.應用時機： a. 填表：於「進行成本分析」工作開始時進行填寫。 b. 檢視及修改：每天定時進行檢討，進行修正調整。 C.表單樣本： 表 4 SPDP 起動階段-成本分析表. 專案名稱：. 階段工作負責人：. 項目 成本類型. 1. 管理行政. 說明. 數量. 計畫主持人. 人月. 專案經理. 人月. 計畫助理. 人月. 行政雜支-印刷、交通. 2. 3. 系統開發. 單位. 單價. 小計. 月. 子系統1:. 人月. 子系統2:. 人月. 子系統3:. 人月. 子系統4:. 人月. 保固維護 提供7×24保固維護. 月. 教材撰寫 教材印刷 4. 教育訓練 教室租借. 場. 師資人力 交通差勤 5 6 7. 採購. 硬體採購項目及規格. 套. 軟體採購項目及規格. 套. 技術顧問. 式 新台幣. 總計. 元整(含稅). (5)對把握度不足專案投入之階段費用損耗問題：藉由制定「招標文 件取得與評估」、「可行性評估」及「分析專案預期效益」工作 運用之「第一階段可行性評估報告表」(請參閱表 5)、「第二階 段可行性評估報告表」(請參閱表 6)及「第三階段可行性評估報 告表」(請參閱表 7)，在工作完成後即客觀進行評估並決定是否 要繼續進行後續工作，以避免無謂的成本損失，其應用方法、時 機及表單樣本如下： A.應用方法：於「招標文件取得與評估」、「可行性評估」及「分 析專案預期效益」，在工作完成後即分別填寫「第一階段可行性 評估報告表」、「第二階段可行性評估報告表」及「第三階段可 行性評估報告表」並決定是否要繼續進行後續工作，以避免無謂. 36.
(48) 的成本損失。 B.應用時機： a. 填表：於「招標文件取得與評估」、「可行性評估」及「分 析專案預期效益」工作中進行填寫「第一階段可行性評估報 告表」、「第二階段可行性評估報告表」及「第三階段可行 性評估報告表」。 C.表單樣本： 表 5 SPDP 起動階段-第一階段可行性評估報告表. 專案名稱：. 階段工作負責人：. 業務部門評估-評估者簽名：_________ 項次 評估項目 評估結果 對客戶熟悉程度 □>80%, □>60%, □>40%, □>20%, □<20%, 1 說明： 對公司策略相關性 □>80%, □>60%, □>40%, □>20%, □<20%, 2 說明： 後續商機 預估未來____年，共__________萬元 3 說明： 其它_________________________ 4 說明： 是否建議繼續進行後續工作：□強烈建議 □建議 □普通 □不建議 □強烈不建議 其它說明： 工程部門評估-評估者簽名：_________ 項次 評估項目 評估結果 對專案技術把握度 □>80%, □>60%, □>40%, □>20%, □<20%, 1 說明： 對專案人力「量」的充沛程度 □>80%, □>60%, □>40%, □>20%, □<20%, 2 說明： 其它_________________________ 3 說明： 是否建議繼續進行後續工作：□強烈建議 □建議 □普通 □不建議 □強烈不建議 其它說明： 會議結論：決議：□繼續進行, □放棄 參與人員：業務部____________________ 原因說明：. 主席簽名__________ 工程部____________________. 表 6 SPDP 起動階段-第二階段可行性評估報告表. 37. 備註. 備註.
(49) 專案名稱： 項次 1. 2. 3. 4. 階段工作負責人：. 評估項目 評估者簽名__________ 確認系統範疇之了解程度 需求1： 了解程度：□非常了解, □很了解, □普通, □很模糊, □非常模糊 需求2： 了解程度：□非常了解, □很了解, □普通, □很模糊, □非常模糊 需求3： 了解程度：□非常了解, □很了解, □普通, □很模糊, □非常模糊 階段中模糊的需求之澄清程度 (至少列出「招標文件取得」工作之模糊需求) 模糊需求1： 模糊需求2： 模糊需求3： 關鍵風險是否有明確的因應方案 關鍵風險1說明： 可能影響說明： 因應方案說明： 關鍵風險2說明： 可能影響說明： 因應方案說明： 關鍵風險3說明： 可能影響說明： 因應方案說明： 初期的商業效益判斷是否已經完成 預期商業效益說明：. 其它補充： 5 會議結論：決議：□繼續進行, □放棄 參與人員：業務部____________________ 原因說明：. 主席簽名__________ 工程部____________________. 表 7 SPDP 起動階段-第三階段可行性評估報告表. 38.
(50) 專案名稱：. 階段工作負責人：. 業務部門預估-預估者簽名：___________ 項次 預估分類 預估項目 預估值 單位 備註 1 採購硬體成本 元 非系統開 2 採購軟體成本 元 發成本 3 其它非軟體開發成本 元 是否建議繼續進行後續工作：□強烈建議 □建議 □普通 □不建議 □強烈不建議 其它說明： 工程部門預估-預估者簽名：___________ 項次 預估分類 預估項目 預估值 單位 備註 1 合計系統開發成本 人日 1.1 子系統1： 人日 系統開發 1.2 子系統2： 人日 1.3 子系統3： 人日 2 合計系統差旅成本 元 2.1 需求搜集 元 2.2 差旅成本 系統分析 元 2.3 系統設計 元 2.4 其它差旅 元 是否建議繼續進行後續工作：□強烈建議 □建議 □普通 □不建議 □強烈不建議 其它說明： 會議結論：決議：□繼續進行, □放棄 參與人員：業務部____________________ 原因說明：. 主席簽名__________ 預估利潤___________元 工程部____________________. (6)建議書提出架構無法滿足專案效能需求問題：藉由規範於「評價 起始階段」工作撰寫「效能分析報告書」，並提出相關佐證，對 建議書提出架構之效能提出預估，： A.應用方法：於「評價起始階段」中撰寫，以確保建議書提出之架 構滿足專案之效能需求。 B.應用時機： a. 撰寫：於「評價起始階段」工作開始中進行填寫「效能分 析報告書」。 b. 審查：於「效能分析報告書」完成後，由工程部主管進行 審查確認。 C.表單樣本：無 (7)階段參與人員之工作調配問題：藉由制定「規劃起動階段」工作 運用之「起動階段計劃檢核表」(請參閱表 2)，明定參與人員負 責之工作及工作區間，以確保該人員於工作進行期間之責任歸 屬，其應用方法、時機及表單樣本如下： A.應用方法：於「規劃起動階段」工作輔助階段中各項工作安排， 39.
數據
+5
相關文件
McCreedy , “The Process of Knowledge Management Within organization ：a Critical Assessment of both Theory and Practice”, Knowledge and Process Management， Vol.6,
This study aimed to explore the effectiveness of the classroom management of the homeroom teacher by analyzing the process of the formation of the classroom management and
Keywords: Professional construction management, international project management, case study, ethnographic survey.. Due to the increasing scale and complexity of public
Although various schedule delay analysis methodologies, professional project management software and commercial delay analysis software are available, delay analysts still
The objective is to evaluate the impact of personalities balance in a project management team on the team’s performance.. To verify the effectiveness of this model, two
在專案規劃階段，專案團隊就必須做出決定，同 時紀錄於專案成本管理計畫書 (project cost manage ment plan) 與專案時程管理計畫書 (project schedul e management
The Earned Value Management (EVM) is an international standard for project cost control, which provides a promising tool for project cost control practice of the middle
The aspects that influences the process are :(1)Institutional framework, (2)The project budget (3)The project construct managements (4)Project quality control (5)Pricing,
