網站建置標準流程之需求管理的研究與探討─以大型研究機構為例

國 立 交 通 大 學

管理學院（資訊管理學程）碩士班

碩 士 論 文

網站建置標準流程之需求管理的研究與探討─

以大型研究機構為例

Exploring the Requirement Management on the Standard

Process of Developing a Website : A Case Study of a

Large-scale Research Institute

研 究 生：李婉真

指導教授：劉敦仁 博士

網站建置標準流程之需求管理的研究與探討─以大型研究

機構為例

Exploring the Requirement Management on the Standard Process

of Developing a Website : A Case Study of a Large-scale Research

Institute

研 究 生：李婉真

Student：Wan-Chen Li

指導教授：劉敦仁博士 Advisor：Dr. Duen-Ren Liu

國 立 交 通 大 學

管理學院（資訊管理學程）碩士班

碩 士 論 文

A Thesis

Submitted to Institute of Information Management College of Management

National Chiao Tung University In Partial Fulfillment of the Requirements

For the Degree of Master of Science

in

Information Management

July 2006

網站建置標準流程之需求管理的研究與探

討─以大型研究機構為例

研究生：李婉真 指導教授：劉敦仁

國立交通大學資訊管理研究所

摘要

隨著網際網路(Internet)應用的蓬勃發展，企業可即時的將分散於世界各地的有用資 源統籌串連起來，而各式各樣的網路活動，在在顯示了網際網路已成功地成為資訊來源 及電子商務的作業平台，因此網際網路已經成為最具影響力的媒體之一了，因此網站也 成為了目前重要的應用技術之一。 和一般人熟悉的軟體一樣，網站也是需要一套標準建置流程來建立的；而網站建置 流程是源自於軟體建置流程，有研究指出，眾多的軟體專案無法完全發揮原先預定功能 的原因中，其中缺乏使用者的參與、需求與規格的不完整及需求與規格的變更就佔了大 多數。而網站專案相對於單純的軟體開發專案而言，網站專案更為複雜與不確定，如果 能夠在網站建置專案的初期就積極的進行需求管理，除了能夠減少規格變更的風險產生 之外，避免造成專案時程的延遲與成本的耗損。 目前在軟體的部分，已有許多評量軟體流程的標準或是工具，例如CMMI 或者 ISO 等等，這些標準或是工具均能協助企業、組織或是軟體建置團隊能夠針對需求管理流程 進行評量或是改善原有的流程；但是在網站建置的部分，除了沒有可以參考的標準流 程，造成企業或是組織在建置網站時沒有一套標準來作為參考與評量，當然就更缺乏對 於需求管理的研究與探討了。因此本論文主要是藉由國內的大型研究機構的大量網站規 劃建置的專案經驗，以及該機構原先依循ISO 標準，所建立了一套網站的建置流程標準 的前提下，探討此套流程標準是否符合專案管理與CMMI 的概念進行需求管理，除此之 外，是否另有改善的空間及方案，以降低建置的成本，可提昇網站建置的後續效益。 關鍵字：網站建置流程、需求管理、專案管理、CMMI

Exploring the Requirement Management on the

Standard Process of Developing a

Website: A Case Study of a Large-scale Research

Institute

Student：Wan-Chen Li Advisors：Dr. Duen-Ren Liu

Institute of Information Management

National Chiao Tung University

Abstract

With the tremendous growth and change in the Internet, enterprise can benefit from the improved use of all information widely spread on the Internet and collect them in a timely fashion. It can be seen from our daily activities that the Internet has

successfully become a new platform for information gathering and e-commerce.

Therefore, it has been one of the largest media that has great influence on our daily life. Among those technologies introduced on the Internet, web has played a very important role.

Just like the approach people use in developing desktop software, web site

construction also need a standard process to carry out. Most of the process of building a web-site originates from software engineering. There are some researches pointing out that the software project which could not meet the goals for functionality results from, for the most part, the lack of user participation, incompletion of requirements and

specifications, and frequent change of specifications. Compared with traditional software project, web site construction is more complex and uncertain. If the requirement

management can be put into practice at early stage during the process of building a web site, we can reduce the risk of specification change as well as the delay of project and cost made for the process.

There are various standards or tools for software process assessment today, such as CMMI and ISO. They help people from enterprise, organization or software

development team to carry out the process of requirement assessment or to improve their original process. However, no standard was made specifically for web site construction to assist enterprise or organization to do assessment when establishing a web site, especially for requirement management. This thesis is based on the process of web site construction defined by a large research institute which builds up many web sites and has derived a standard process from ISO to meet their requirements. We focus on whether this standard process fits in with the concept of CMMI and Project Management to do requirement management and see if there is space left for improvement to reduce the cost during setting up a web site.

Key Word：The Process of Building a Web-site、Requirements Management、Project Management、CMMI

誌謝

很高興終於完成了兩年的研究所學業。 首先得感謝我的指導教授劉敦仁博士，給予我論文上的許多指導與寶貴建議，使我 得以順利完成碩士論文。另外感謝口試委員王朝煌教授、李瑞庭副教授以及楊千教授在 口試期間給予我論文許多的寶貴意見。 感謝我的同事陸銘輝先生給予我論文上的寶貴意見，使我著實獲益良多。同時也感 謝張惠娟小姐、楊秀之小姐、蔡懿琪小姐以及陳建泰先生，沒有你們的專業素養與知識， 我是沒辦法獨立完成我的研究的。當然也要感謝實驗室的同學佳郁、惠琪、宏道、稚農 與育勳在論文以及生活上給予的幫助，另外感謝同學鋸賢大哥、小米、國誠不時地幫助 我、鼓勵我，感謝所有關心我的朋友以及助理欣欣，使我度過很多難關，心中感激之情， 難以言喻。 最後，我得感謝我的家人，在求學的漫長歲月中，你們的支持與鼓勵，是我最溫暖 而厚實的依靠。最重要的，我要感謝我的先生中州，因為有你，我才能如期完成我的研 究，謝謝你。

目 錄

摘要 ... I ABSTRACT...II 誌謝 ... IV 目 錄 ... I 表目錄 ... III 圖目錄 ... IV 第一章 緒論 ...1 1.1 研究動機...1 1.2 研究目的...2 1.3 論文架構...2 第二章 文獻縱覽 ...4 2.1. 網站建置的需求管理...4 2.1.1 網站的定義與特性...4 2.1.2 網站生命週期模式...7 2.1.3 網站專案建置流程...9 2.1.4 網站目標與需求...13 2.1.5 需求管理的重要性...14 2.2 專案管理的需求管理...16 2.2.1 專案的定義與特性...17 2.2.2 專案管理的定義與特性...18 2.2.3 PMI的需求管理─專案範疇管理...20 2.2.3.1 專案起始 ...21 2.2.3.2 範疇計劃 ...23 2.2.3.3 範疇定義 ...25

2.2.3.4 範疇驗證 ...27 2.2.3.5 範疇變更控制 ...28 2.3 軟體能力成熟度整合的需求管理...30 2.3.1 CMMI能力成熟度整合模式...30 2.3.2 CMM-Level 2的需求管理...32 2.3.3 CMM-Level 2需求管理流程簡介...37 2.3.3.1 管理規劃程序 ...37 2.3.3.2 變更追溯管理程序 ...39 第三章 網站需求之研究架構 ...42 3.1 研究方法...42 3.2 研究架構...44 第四章 實例探討與流程改善建議 ...47 4.1 研究個案簡述...47 4.2 數位內容需求洽談與規畫程序以及產出結果...49 4.3 需求變更追溯管理程序以及產出結果...54 第五章 資料分析與研究結果 ...61 5.1 資料評估方法...61 5.2 專家意見彙整...65 5.3 網站建置流程的改善方案...65 第六章 結論與建議 ...69 參考文獻 ...71 附錄 ...75

表目錄

表1. PROJECT CHALLENGED FACTORS...14

表2. 專案的基本特性...18 表3. 專案範疇管理的基本概念...20 表4. 能力成熟度的共同特徵...32 表5. 個案研究四項研究作法...43 表6. 需求管理規劃程序工作表...45 表7. 需求變更追溯管理程序工作表...45 表8. 數位內容製作程序人員角色權責表...48 表9. 需求可行性評估準則範例...52 表10. 需求垂直追溯表範例...53 表11. 需求水平追溯表範例...53 表12.WBS 範例 ...54 表13. 變更申請單範例...57 表14. 變更影響評估表範例...58 表15. 變更申請彙總表範例...59 表16. 差異紀錄與矯正措施表範例...59 表17. 需求管理統計圖表範例...60 表18. 專家專長表...62 表19. 專家意見彙整表...65 表20. 專家意見彙整表...66

圖目錄

圖1. 網站金字塔...5 圖2. 瀑布型模式...8 圖3. 簡易軟體系統開發之品質模式...9 圖4. 數位內容開發作業流程圖...12 圖5. 變更成本曲線圖...16 圖6. 專案起始圖...21 圖7. 範疇計劃圖...23 圖8. 範疇定義圖...25 圖9. 範疇驗證圖...27 圖10. 範疇變更控制圖...28 圖11.CMMI 能力成熟度等級圖...31 圖12.CMMILEVEL 2 流程領域圖...33 圖13. 需求管理流程領域圖...34 圖14. 需求管理流程領域主要程序圖...37 圖15. 需求管理規劃程序流程圖...38 圖16. 需求變更追溯管理程序流程圖...40 圖17. 研究步驟圖...44 圖18. 需求管理流程領域主要程序圖...44 圖19. 數位內容需求洽談與規畫原圖...50 圖20. 數位內容需求洽談與規畫新圖...51 圖21. 數位內容需求變更追溯管理新圖...56 圖22. 專家人數及專家成本比較圖...61 圖23. 德菲法實施步驟流程圖...64 圖24. 需求洽談與規畫程序最終圖...68

第一章 緒論

資訊時代來臨後，網際網路的興起再度掀起了另一波企業革命的狂潮，各式各樣的 訊息無時無刻都在網路上流竄著。「速度化」及「多樣化」是網路訊息傳達的重要特徵， 而這樣的改變卻也對於傳統的訊息傳遞方式產生了相當大的衝擊與影響。 據統計，至 94 年 3 月為止，我國民眾上網人口普及率達 55％，推估我國有 1,237 萬人曾經上網， 而最近一個月仍有上網的民眾有 1,091 萬人，上網比率為 48％，台灣地區家庭上網的方 式以 ADSL 為主，佔 83％；2004 年全球寬頻用戶達 1.5 億，台灣寬頻滲透率排名第七。 這些數據的背後所呈現的現象是─「訊息點選，隨即到家」的情況已經不是遙不可 及的夢想。而網站是各類訊息的總入口，透過網站，來自世界各地，各式各類的訊息及 服務均可以迅速的呈現在 20 吋見方的舞台上，而在這個被稱為網站的空間裡，任何人 都可隨意的選擇他所想要接收的訊息、服務及提出需求。 在分秒必爭的資訊時代中，企業若能妥善利用發揮網際網路的特性，進行資訊交換 的工作，例如企業與客戶間訊息可以透過全球資訊網(Internet)主動傳遞至家庭中，增 加客戶便利性，並可爭取更多的客戶，擴大市場需求。企業與員工訊息可透過內部企業 網(Intranet)，快速取得內部資訊，拉近雇主與員工距離，縮短內部作業流程，強化企 業向心力。企業與企業間訊息透過（Extranet）可及時傳送到指定的目的地，節省傳輸 時間，爭取物流、金流、資訊流遞送時效，掌握先機。企業如果要達到與滿足上列的需 求，建置一個能夠代表企業形象、整合上中下游合作廠商或客戶、達成內外資訊一致的 企業網站就成為了最佳的解決方案。

1.1 研究動機

和一般人熟悉的軟體一樣，網站也是需要一套標準建置流程來建立的；而網站建置 流程是源自於軟體建置流程。但其中和軟體最大的不同是─網站的建置需要結合視覺設 計、資訊架構、網站技術程式等截然不同的專業領域─目前的網站，已經不僅止於傳統 的靜態網頁的呈現，而是包含了多媒體及動態系統內容相互穿插而成，一個網站除了可 以提供內部員工的資訊分享交流之外，更能夠以 24 小時無休的方式，串連上游的廠商 及下游的客戶，形成一個具有廣度及深度的 business model，除此之外，更可以透過網 站的設計，強而有力的傳播企業的形象及理念，而視覺設計將和網站技術程式一樣，成 為影響使用者決定專案是否成功的重要因素。因此網站的建置是需要多種專業能力集合

而成，而且必須於有限的時間、人力、預算的限制下完成，因此可以藉由專案管理的概 念，來進行計畫評估、規劃、執行以及驗收的工作。 有研究指出，眾多的軟體專案無法完全發揮原先預定功能的原因中，其中缺乏使用 者的參與、需求與規格的不完整及需求與規格的變更就佔了大多數。而網站專案相對於 單純的軟體開發專案而言，網站專案更為複雜與不確定，也就更需要釐清使用者對於視 覺以及技術上的需求。如果能夠在網站建置專案的初期就積極的進行需求管理，除了能 夠減少規格變更的風險產生之外，避免造成專案時程的延遲與成本的耗損。

1.2 研究目的

企業如果要建置一個能夠代表企業形象、整合上中下游合作廠商或客戶、達成內外 資訊一致的企業網站就成為了最佳的解決方案。而一個好的建置流程對於企業網站的建 置工作來說就相當重要了，除了能夠提供企業能夠準確的規劃網站的製作步驟之外，更 可以藉由網站建置的專業技術，建立出一個符合使用者所期待的、能快速獲取資料的、 易於維護的且能降低建置成本的網站，因此網站的標準建置流程，已經成為一項值得深 入研究的方向了。 網站的建置與軟體發展息息相關，其中網站建置的流程與生命週期皆來自於軟體的 建置概念，但是對於網站的規劃及建置，一直欠缺著標準建置流程的規劃；而目前針對 軟體專案的評估及改善，又以能力成熟度整合模式(CMMI) 廣為國際間所認可，除了可 以提升專案的整體績效(降低開發成本、提高生產能力)，同時又可以改善任務小組的架 構，因此本次的研究，因此希望能夠透過專案管理與能力成熟度整合模式中對於需求管 理的概念，進行現有大型研究機構的網站建置標準流程中需求管理的研究與探討，藉此 改善專案流程，達到降低成本、縮短時程、提高品質等目標。 本研究提出需求管理的主要目的，是希望網站建置單位在面對網站建置專案時，能 清楚了解網站需求的工作內容，而不再單只是強調系統開發技術，忽略了以客戶為導向 的專案本質。因此在本研究架構中，僅針對「需求管理」部分作為探討的主要項目。

1.3 論文架構

本論文共分為六章與附件參考文獻。 第一章為緒論，說明本論文的研究動機、研究目的與論文架構。 第二章為文獻探討，主要針對本論文中所探討之網站建置流程的簡介，以及其中需

關架構與模式內容作一說明。 第三章為網站需求之研究架構，說明本論文研究的方法與研究的邏輯與架構。 第四章為實例探討與流程改善建議，結合專案管理與CMMI Level 2之需求管理之理 論，對於網站建置流程中的需求階段進行探討，指出其中必須改善的問題點及流程缺 失，同時間針對提出問題點及流程缺失具體的流程改善建議方案。 第五章為資料分析與研究結果，透過德菲法，也就是利用專家問卷的方式，彙整歸 納專家對於網站建置流程中的需求階段的改善意見，對照第四章所指出的流程改善建議 方案，進行異同點的比較，並依據專家所提之意見，再次修改網站建置的部分流程，以 確保研究之完整性與正確性。 第六章為結論與建議，內容重點在整理本論文之研究結果，提出個人心得與建議， 以提供後續研究發展與網站建置團隊於網站建置標準制度之參考。 最後於參考文獻中列出本論文內容之中所引用過去研究與各項參考文獻。

第二章 文獻縱覽

2.1. 網站建置的需求管理

網站技術的日新月異，改變了軟體開發的架構：由原先的Client-Server 架構轉換成 Web-Based 架構，除了解決了跨平台、每次更新即須重新安裝以及系統升級時 Client 與 Server 端軟體相容性等種種問題，此外由於瀏覽軟體(Browser)已經解決了使用者介面的 顯示功能，軟體開發時不需多花時間於瀏覽畫面的設計。而這些改變，也大大的提昇了 軟體對於客戶的可用性，但是同時也讓軟體或是系統網站的建置工作變成不同於以往的 靜態網站的單純及簡易。因此對於網站建置的流程，將需要訂定一項符合原有軟體開發 標準且能夠持續改善的流程；同時由於網站的建置過程中，除了技術程式的撰寫之外， 對於視覺傳遞及行銷部分也多有發展，因此許多潛在的客戶需求需要被及早被開發及管 理，以避免因需求的變更造成的規格變更，使得相關的成本增加或是完工的時程延遲， 因此網站建置的需求管理變成為本論文所要研究重點項目。

2.1.1 網站的定義與特性

網站的定義相關的廣泛，根據維基百科所示，網站(Website)是指在網際網路上，根 據一定的規則，使用HTML 等工具製作的用於展示特定內容的相關網頁的集合。簡單 地說，網站是一種通訊工具，就像佈告欄一樣，人們可以通過網站來發布自己想要公開 的資訊，或者利用網站來提供相關的網路服務。人們可以通過網頁瀏覽器來訪問網站， 獲取自己需要的資訊或者享受網路服務。 而一個網站的組成，包含了四個主要部分：內容、網站技術、視覺外觀以及經濟。 內容指的是對使用者來說是有用的的資料和豐富化的資訊，可以用來說服使用者或是通 知使用者經常使用網站的因素；網站技術則是讓網站規劃階段時所預定的功能能被設計 出來並能實用；至於視覺外觀則是設計出網站的外觀，如此能夠傳達出網站的主要訴求 對象及項目；最後大部分的網站的背後都有原始建置網站的經濟效益的考量，如果沒有 了明確的目標和可被產生的利益，那就不會有網站建置的工作了。 不同的目標及利益的條件下，就會產生不同類型的網站，以企業網站來說，網站的 主要訴求對象是客戶、投資人及員工，因此如何建立企業形象或是推廣產品、技術或是

提供企業獲利的資訊等，因此清楚的視覺效果、及時的訊息發布以及增加公司的收益就 是企業網站的特色；而如果是個人的部落格，可能就不需要明顯的經濟考量，而是著重 於個人化的設計，例如個人日誌式的文章的即時發布與回應與個人相簿、留言板等功能 的集合。但是正也因為每個網站的特性不同，四大主要部分所需要的比重也就需要跟著 調整，而所需的專業領域技術也就跟著不同，所以很難將網站的建置歸成如同軟體建置 一樣的單純個體來討論。 Thomas A.Powell(2001)曾經提出這樣的理論：一個網站可以想像成一做金字塔，其 中內容就像是建造金字塔的的磚塊，金字塔的基礎則是要穩固的建立在視覺設計與網站 技術上面，並且依照著經濟的條件訂定目標加以執行，讓網站整體變得更有價值。 圖 1. 網站金字塔 資料來源：Web Design 設計實務-徹底研究 而在實際建置網站時，卻會發生眾多的問題，例如：網站技術不斷的日新月異，使 得網站建置團隊也必須跟著技術求新求變；網站需要一個兼具美觀和功能的設計，但是 網站製作的委託人卻容易只迷惑於美麗的外觀，而忽略了真正網站使用者的需求，缺乏 任何的技術或是功能，將網站製作的像是一個放置於網路上的線上手冊；或是以技術為 出發點，充滿了最新穎的技術或功能，但是卻缺乏整體的視覺設計，讓網站像是一個炫 燿技術的舞台，但是卻讓人望而卻步，無法真正獲取需要的資料或是資訊。為了避免這 樣的錯誤持續的發生，就需要了解一個好的網站的特性，接下來才能依照其特性來進行

網站的建置工作，讓網站的建置專案不至於事倍功半。 一個好的網站的特性有下列三項： 1. 需要針對使用者建置的： 網站開發者最常犯的的錯誤就是以自己的需求為中心，反而忽略了網站的真正 的使用者是誰，因此貼近使用者的需求與興趣是相當重要的；但是使用者往往 又不如設計者對於網站技術如此熟知，因此要從使用者的口中說出網站的確切 需求又太過困難，因此在設計網站時，必須先設定使用者為一般的使用者，但 是必須再針對主要關鍵的使用者的差異點去深入設計，這樣就能符合使用者的 需求。 2. 需要考慮到可用性與符合軟體原則： 網站內容的呈現方式已經從線上印刷品的方式轉變成線上軟體的模式了，因 此目前網站的功能變得用來越多樣而複雜了。網站除了提供內容之外，也提 供了很多的互動的機制，而這些互動機制，它們要能夠不經很多學習的時間 就可以上手，而且不需要安裝的動作，最重要的是能夠讓內容與行銷結合。 所以與其他傳統的媒體相比，網路上的工具與技術變更的相當快速，加上瀏 覽器廠商不斷的推出各自創新但不互相支援的瀏覽器，因此為了滿足使用者 隨時隨地都可以使用，也就讀取到正確無誤的資訊的要求之下，也讓網站的 建置變得更加的複雜。 而網站上所使用到的互動機制，雖然在及時性的要求與傳統上的軟體有所差 異，但是網站還是保留了很多軟體設計的元件功能，像是視窗、選單或是滑 鼠指標。這些軟體設計的元件功能，已經像是慣例一般的深植於使用者的腦 中，因此依循原有的慣例還不輕易改變，也將有助於網站的可用性的提昇， 也可以減少使用者因為改變而產生混淆所產生的不好的感受。 3. 以內容為中心： 網站與傳統軟體最大的不同是，網站是以內容為中心，因此所有的視覺以及 功能設計，都是以能夠快速的尋找到資訊為最重要的目的，因此一個好的導 覽(Navigation)將能夠幫助一個網站的使用者達成他們所需要的內容，此外還 可以透過利用一些求助系統，例如搜尋引擎、網站地圖等功能來幫助使用者 達成他們的目標。 而一個網站的視覺設計對於使用者的第一印象影響相當大，使用者經常會將

好看的網站認知為好的網站，因此網站的視覺將有助於網站的價值。但是在 使用過一陣子之後，除了視覺設計的因素外，使用者還是會因為網站所提供 的內容、可用性、技術等因素來評斷網站的優劣，因此回歸到網站金字塔的 概念，網站建置的策略以內容為中心，視覺、技術為基礎，朝著預定的經濟 目標發展。

2.1.2 網站生命週期模式

近期的網站製作已經與以往如同放置於網路上的線上手冊一般的做法大為不同，現 在的網站隨著動態網頁與電子商務的興盛，規模、人力需求、時程都變得龐大也變得複 雜，如果還是沒有依循任何的流程開發，將導致網站製作的風險提高及失敗危機，而這 些都將造成建置成本的損失。因此一個良好的網站建置流程是重要的，它除了可以強化 團隊的效率與生產力、控制建置過程的風險、加速建置過程，同時還能提升網站品質， 因為依循了網站建置流程，就能夠控制網站建置過程的品質，並且也就能提供評估品質 的依據。 而流程則是為了達到特定目標，所制訂的一連串可執行的步驟，網站建置流程也跟 軟體流程有相同的用意，一般而言，軟體的製作是藉由一連串的活動以及活動結果而完 成的，而這一連串的活動也可以稱為軟體開發過程。其中軟體生命週期模式(Software Life Cycle Models)就是依據軟體開發過程的活動劃分成問題探討、需求分析、設計、執 行、整合測試、操作及維護等階段，而軟體生命週期模式又依照軟體專案的規模、複雜 度、不確定性、時程限制等因素又發展了多個不同的開發模式，其中最具代表性也是最 早被提出的就是瀑布模式(Waterfall Model)， 於 1970 年由 Royce 提出。網站的基本功能 是參考了軟體元件的概念，因此網站的開發流程也參考了瀑布模式，如圖2 所示。

圖 2. 瀑布型模式 資料來源：軟體專案管理 基本運作的方法如下： 1. 一個網站可以包含內容、視覺、技術及經濟目標等部份。從網站的問題與概念 開始，定義網站的經濟目標以及內容，同時也要定義網站的功能。 2. 經過問題與概念的探索之後，獲得了網站需求的初步內容，接下來就開始進行 需求的分析，當需求分析過後，便可以開始定義網站的功能與規格。 3. 依照前面網站的功能與規格，就可以進行設計網站雛型，這個階段就可以分視 覺設計與技術開發兩大部分，各自產出網站外觀及功能的雛型以供測試。 4. 實作及單元測試(Test)是用來檢驗各階段產出是否正確的方法。實作的目的是 為了確認雛型是否滿足了顧客的需求，同時驗證每一個階段的產出是否在下一 階段正確無誤的被執行。單元測試則是能針對原先設計的功能程式是否撰寫正 確的一種檢驗方法。 5. 整合測試是一種系統層次的測試。在測試之前必須先準備測試計劃，其中要包 含測試個案與相關的內容，而測試計劃本身也要經過審查以免錯誤或遺漏。測 試的結果必須符合設計的標準，否則必須經由除錯的動作去除錯誤。 6. 發行、操作及維護階段，如果在整合測試階段就已經滿足所有的需求時，就可

以進行發行工作，讓建置完成的網站正式的開放給使用者使用。但是如果整合 測試階段時或是發行後發現有錯誤出現，或是新功能的增加需求產生的情形， 其中功能程式的錯誤必須回到編碼及測試階段，新功能的增加則必須從軟體需 求開始，有如一個小型的系統開發進行。 而這個開發模式的特色是，每一個階段的結束都必須產出文件，每一份產出文件都 需經由內部人員及顧客的確認後才可以進入下一個階段。而任何的需求變動都要經過顧 客的確認，再依瀑布模式的階段順序進行修改。

2.1.3 網站專案建置流程

網站建置流程，除了參考依照網站生命週期模式之外，同時也參考了軟體的開發流 程，早期軟體開發時，常依時間劃分成幾個階段，例如：系統分析、系統設計、程式撰 寫、測試、建置與維護等階段（如圖 3）。而流程則是為了達到特定目標，所制訂的一連 串可執行的步驟，網站建置流程也跟軟體流程有相同的用意。因此，一個良好的網站建 置流程，必須要能強化團隊的效率與生產力、控制建置過程的風險、加速建置過程，以 及提升網站品質。依循了網站建置流程，就能夠控制網站建置過程的品質，並且也就能 提供評估品質的依據。

軟體系統開發流程模式

規格分析 設計建置 系統確認 軟體需求規格書 軟體發展計畫 軟體移交計畫 (C) 軟體設計規格書 軟體測試報告 建構管理報告 (B、C) 軟體設計規格書 系統規劃 系統維護 軟體使用手冊 圖 3. 簡易軟體系統開發之品質模式 資料來源：中華民國資訊軟體協會 http://www.cisanet.org.tw/

品質是來自於使用者的認定，如果無法滿足使用者的需求與期望，則不能視為有品 質之網站。整體而言，網站建置專案發展策略應包含強化驗證及確認之品質保證機制 (Verification & Validation, V&V)，其流程強調網站專案導向的品質，即網站品質保證 (Software Quality Assurance)，終極目標是要確保符合使用者的需求。

而在網站方面，對於使用者來說，品質的表現則是能夠在最短的時間裡，獲得所需 資料；所以擁有良好的網站資料分類及資訊架構將是幫助使用者快速獲取所需資料的不 二法門，配合網站視覺最佳化的設計及高使用性的導覽設計，客戶只要具有基本的瀏覽 器使用知識以及直覺的網站使用習慣性，就能輕易的在這類網站中獲取所需要的資訊。 精心設計的內容標籤，漸進式敘述的網頁內文結構，讓讀者能在最短的時間內了解網頁 內容，大量縮短客戶在網站內耗用的閱覽時間。 目前製作的公司與組織相當的多，但是大多都以網站套件的方式，也就是包含制式 的視覺樣板、固定的功能包裝成一個單位來進行販售。這樣的做法，不僅無法顯示出企 業或組織的特色之外，對於內容也無提供一個有系統性的分析，不但會造成資料分類雜 亂無章，使用者無法快速獲取資訊之外，同時也無法同步顧及往後的資料擴充與維護等 工作，最後也就容易造成網站的停止更新或是一旦增加服務內容時，就要重新建站的缺 點。而國內大型研究機構透過許多網站建置的經驗，以及參考國外最新的網站架構學， 配合 ISO 品質保證管理標準而建立出一套網站的建置流程，而其中分為四大部分（如圖 4 所示）： 1. 需求洽談與規畫： 製作人—根據委託人提供的數位內容需求，負責與客戶洽談了解客戶實際需 求，完成「專案執行構想書」並依主客觀環境分析完成「委製可行性評估」， 呈送核決主管裁決是否接案。成案後，負責協助客戶收集、彙整資料，撰寫「原 始資料清單」，規劃時程與資源，填寫「數位內容製作規劃表」，由創意總監及 技術總監協助完成「提案書」。 2. 內容設計： 創意總監、資訊設計師(IA/ID)、藝術設計師、技術總監根據製作人產出的專 案執行規劃書、提案書，將委託人提供之原始素材作以下的設計： ‧ 創意總監：主導本階段的設計工作。 ‧ 資訊設計師(IA/ID)：進行內容分析、分類，設計網站架構與介面、使用 者互動規格規格的規劃。 ‧ 藝術設計師：負責主視覺及版面設計。

‧ 技術總監：負責相關之環境規劃與系統設計(Infrastructure) ，並產出 「技術規格書」。 3. 內容製作： 依據前一階段數位內容設計的結果，如內容架構資料表、技術規格、主視覺等 等，進行數位內容的製作。 4. 系統測試驗收上線： 數位內容測試人員根據「驗收規劃書」、「內容架構資料表」及「使用者互動規 格」與數位內容製作人員於系統測試區內進行系統測試工作（包含：功能測試 與效能測試），同時測試與其他系統介面及現有環境整合性是否正常運轉；待 測試一切正常後，再會同製作人及委託人進行驗收測試。完成後進行系統上線 並由委託人進行驗收工作。 從需求洽談、網站規劃、網站設計、網站製作及測試驗收，每一步驟都需要有工作 指引、明定產出文件並提供文件範本及範例。這樣不僅縮短建置時間、維持網站品質， 更能透過經驗傳承使網站建置專案團隊的能力不斷精進。 企業網站背負著訊息傳遞、員工學習及網路系統服務的重責大任，它必須隨時提供 更快速、更廣泛的服務，也必須要整合舊有系統所提供的訊息，同時也可能必須是全球 化跨時區的機制；最重要的是，它還必須考量後續企業內部引進新系統的相容性。在如 此嚴苛要求的環境下，如何讓一個企業的網站穩定而順暢的運作，著實考驗著企業內部 的IT 人員。除了技術本身外，網站營運的可大可久，更是網站管理者必須時時面對的 重要課題。

相關關鍵人員 流程圖 委託人/SME 製作人 決策小組 創意總監 資訊設計師 技術總監 藝術設計師 決策小組 整合工程師 程式設計師 多媒體工程師 藝術設計師 決策小組 測試人員 製作人 委託人 決策小組 製作人 委託人 圖4. 數位內容開發作業流程圖 資料來源：工研院資訊中心，數位內容製作程序書

2.1.4 網站目標與需求

一個網站專案在開始之際，最重要的就是針對網站的目標作一個完整而明確的定 義。目標的設定，將有助於於增進人類工作表現及提高生產力，而1960 年代洛克(Edwin Locke)所提出目標設定理論(Goal-Setting Theory)中曾經指出挑戰性的目標是激勵的來 源，當設定一明確(specific)且具難度(difficult)的目標時，人們表現會比沒有目標或是盡 力而為的目標來的佳。而設定目標並不困難，但是一個明確的目標會比一個模糊的目標 更能夠有效的激勵生產力並可以協助事後評量的。根據SMART 原則，一個有效的目標 必須有以下的五項要點： ƒ Specific：意指具體的，訂定目標必須明確而不籠統 ƒ Measurable：意指可衡量的 ƒ Attractive：說明目標是否具有吸引力 ƒ Realistic：字面的含意是實際的。這是指目標的可實現性 ƒ Traceable 是指目標的可紀錄、追蹤反省、與檢討 依照上述五項要點所訂定出來的目標，是具體而且可以被測量的，並且是有吸引 力、可以被實行且可以被紀錄追蹤的，這樣的目標，在網站專案執行的過程中，在爭議 出現時，提供一個可以持續遵循的正確方向；而在網站專案結束後，則提供了專案成功 或失敗的測量標準。同時明確的目標訂出之後，對於網站專案的製作時程、預算，以及 人力的配置，也能夠產生初步的構想。 在清楚的訂定出網站的目標之後，接下來必須描述用戶群以及用戶的特色，並且找 出用戶群瀏覽網站的原因。網站的用戶群除了網站的實際使用者之外，應該還需要包含 更多與網站建置工作相關的專案成員，也就是『專案利害關係人』(Project Stakeholders)。 依據美國專案管理學會(Project Management Institute, PMI)所出版的「專案管理知識體系 指南」〈The Project Management Body of Knowledge, PMBOK®〉的定義，所謂『專案利 害關係人』，是指所有積極參與專案的個人及組織、利益會受到專案執行的結果後正面 或負面影響的個人及組織，同時他們也可能對於專案和專案結果產生影響力。而專案中 主要的利害關係人，至少包含： ƒ 專案經理人(Project Manager)─負責管理專案的個人 ƒ 顧客(Customer) 或使用者(User)─使用專案產品的個人或組織。在網站專案裡， 『顧客』指的是採購專案結果的個別實體；而『使用者』指的是直接使用專案 結果的個人或是組織

ƒ 執行專案的組織(Project Organization)─例如一個大多數員工都直接參與專案工 作的企業體

ƒ 專案團隊成員(Project Team Member)─執行專案工作的團體

ƒ 贊助者(Sponser)─在專案執行組織內，提供經費或是相關資源的個人或是組織 專案利害關係人經常站在專案中不同的位置，正因為如此，每個專案利害關係人都 會有不同的需求以及期望，因此將所有專案利害關係人的期望引導到顧客導向是相當重 要的。 在網站專案裡，『使用者』指的是直接使用專案結果的個人或是組織；而『顧客』 指的是採購專案結果的個別實體。在『使用者』的角度而言，來到網站的第一理由是他 們需要資訊，因此提供一個內容豐富且有適當的瀏覽介面設計及好用的功能與資訊搜尋 技術，並且可以吸引他們不斷返回的網站將是使用者瀏覽網站的首要需求；但對『顧客』 而言，一個能夠在合理的成本與時程下，能夠達到想要傳達的訊息或是建立更多的利益 將是顧客採購或建置網站的首要需求。而因為在客戶導向的現今社會，如果能夠整合滿 足了使用者與顧客的需求，將原先可能是相互衝突的情況，轉換成雙方得利的結果，這 樣才能夠達成原先設定的經濟目標，讓網站建置專案的整體變得更有價值。

2.1.5 需求管理的重要性

在眾多網站建置的專案中，由於開發流程的過度簡化以及時間緊迫，因此常常是在 顧客只和專案經理初步談定合作案後，在雙方尚未明確的描述真正的需求時，就開始組 成開發團隊，開始分析、視覺設計、撰寫程式、測試等階段工作，等到顧客看到了初步 的開發成果，才發現和顧客原先預估的成果有了差異。差異小的，可能會因為修改而延 後交期；差異大的，除了交期延後、成本增加之外，嚴重的甚至可能導致專案的失敗。 Emanuel R. Baker (2001)也曾經提到，在很多研究中指出，大約有 30% 到 40%的軟 體專案是失敗的，在這些失敗的專案裡，其中有50%都起因於對於需求定義不夠充分的 緣故；而在電子商務方面，又必須因應網際網路快速的特性去發展應用程式，這樣子的 組織風險將會招致影響深遠的損失傾向。 而在在Standish group 研究機構的研究報告(1994)提出過，眾多的軟體專案無法完 全發揮原先預定功能的原因中，其中缺乏使用者的參與、需求與規格的不完整及需求與 規格的變更就佔了36.9%，而技術的不足則僅佔 7%(如表 1 所示)；

Project Challenged Factors % of Responses 1. Lack of User Input 12.8% 2. Incomplete Requirements & Specifications 12.3% 3. Changing Requirements & Specifications 11.8% 4. Lack of Executive Support 7.5% 5. Technology Incompetence 7.0% 6. Lack of Resources 6.4% 7. Unrealistic Expectations 5.9% 8. Unclear Objectives 5.3% 9. Unrealistic Time Frames 4.3% 10. New Technology 3.7% Other 23.0% 資料來源：http://www.standishgroup.com/sample_research/chaos_1994_2.php 需求管理如果進行得不好，除了讓專案無法完全發揮原先預定功能或是失敗之外， 其中對於成本也有相當大的影響。舉例來說，在需求階段，如果儘早發現需求錯誤時， 需要修正的部分只佔整體專案的一小部分成本(以 1 元來計算)；如果這個錯一直沒發 現，而到了設計階段才被發現，那所需付出的成本就增加了一些，因為還需包括了將原 本有缺陷的設計補強的方案、分析、估價等相關工作的費用，而這樣大概已經變成10 元了；但是如果還是來不及補救，而等到設計階段後為了沒有達成使用者的需求而進行 規格變更的話，要付出的成本就要包含了所有的分析、設計、程式撰寫的工作，這樣大 概需要花費100 元了；等到測試階段才發現錯誤時，由於必須修改眾多的文件和要逐行 的進行修改程式碼等工作，所需成本就已經增加至1000 元；但是如果一直到專案結果 才去修正的化，所需要的成本就將超過10000 元以上，而這樣不僅造成獲利的大幅度減 少，甚至喪失了商譽，失去未來再次接案的機會(如圖 5)。 由此可知，需求管理雖然處在網站建置流程的起始階段，但是卻貫穿了建置專案的 生命週期，而需求管理的成功與否，正是影響了網站專案的關鍵重點，因此明確的需求 釐清與有效率的需求管理，將會是協助網站建置專案順利的進行及成功的結案的不二法 門。

圖5. 變更成本曲線圖 資料來源：http://www.agilemodeling.com/essays/costOfChange.htm

2.2 專案管理的需求管理

目前為一個高度資訊化的社會，每個人的生活中，經常充斥著電腦、軟體等相關的 資訊名詞，而軟體開發對於一般大眾而言，可能只是個經常被提及的名詞，但是在資訊 產業當中，軟體開發不只是代表著技術，更是代表著結合眾人之力量的藝術。而不同的 專案管理風格，將會導致截然不同的結果。如果以大型軟體專案來看，一個成功的專案 管理，可以讓公司賺進大量的金錢與商譽；相反的，一個失敗的專案管理，卻可以導致 專案的失敗，甚至拖延數年無法結案，造成公司及客戶無法預估的損失。由此可見，專 案管理對軟體開發的重要性。不論軟體專案是採取公司內部員工自行開發，或是交由公 司外部廠商委外開發；或是在同樣的區域開發，或是跨國的開發專案，其中所面臨的挑 戰與風險，其實都蘊含著不同的管理技巧。而軟體專案管理 (Software Project Management, SPM) 顧名思義就是運用管理運用管理的原則與方法，使得軟體開發專案 能達到預期的目標。為了達成這些目標，專案管理者必須掌握專案成功的要素，同時也 要洞察足以危害專案順利進行的變動與風險。接下來就要詳細的來研究軟體、專案管理 的定義與特性。

2.2.1 專案的定義與特性

在日常生活中，經常聽到「專案」這個名詞，專案，其實無所不在，不管是企業或 是政府機關，或是學校或是研究機構，只要是為了執行特殊任務或是解決疑難問題等活 動，皆可以運用專案來達成目的。而一般學者專家對於專案的定義也不盡相同； Reeser(1973)指出牽涉各種技術為達成技術任務所必要之努力，需在限定時間內完成 者。Cleland and King(1983)指出匯集人力及非人力的資源於臨時的組織中以達成特定 的目的。而 Meredith and Mantel(1989)則指出為一特殊及限期內完成之任務，具有技 術複雜性，賴不斷協調來控制進度、過程、成本及工作績效。但是「專案」的定義究竟 是什麼呢？廣義而言，所謂「專案」係指一個特殊而有一定限度的 (Finite) 任務，或 由一群聚相互關連性的工作所共同組合起來的任務，需要有明確的起訖時間及成本控 制，而該任務是以獲得特殊結果或圓滿達成某種成就為目標。而專案具備了下列的基本 特性： ƒ 無論執行時間的長短，它都具有一定的時程、明確的開始及終止點。 ƒ 執行專案需使用資源，而通常專案都是在資源有限的環境下運作。 ƒ 專案內部間各任務具有「相互依賴」、「介面」及「互動關係」而亦與外部環境 息息相關、彼此間需密切合作按一定執行程序，並需要有高度的整合性。 ƒ 它是獨一無二且未曾發生過的。 ƒ 執行專案的組織內外經常隱含著「利益性的衝突」

而依照美國專案管理學會(Project Management Institute, PMI)所出版的「專案管理知 識體系指南」〈The Project Management Body of Knowledge, PMBOK®〉的定義，『專案是 一種暫時性的工作活動藉以創造出一項獨特的產品或服務』；「暫時性」指的是每個專案 都有一個明確的開始點和終止點。「獨特性」指的是和其他相似的產品或是服務相比， 專案還是在某些地方有所不同的，而對於許多組織來說，有時專案的產生常是因為產品 或是服務並不能依循組織內原有正常的作業管道而滿足所採取的必要手段。專案可以在 組織內的所有階層中實行，可能由一人或是數千位人員共同參與；專案執行的時間可以 短至數小時，長至超過5 年以上才能完成；專案的運作可能只有組織內的單一個部門， 或是跨組織的合資合夥關係。 專案和例行性的工作的執行可以幫助組織或是企業完成所需的策略或是任務，兩者 之間最大的不同是專案屬於暫時性的，而例行性的工作卻是持續性的，也就是會有相同 的流程一再而再的重複，而相同的流程重複執行的話，將會產生相同的結果，所以需要

一個固定處理這種例行性的工作的職務或是人員產生。在組織或是企業當中，專案和例 行性的工作也經常是交錯的被執行的。 專案的執行的結果常是組織或是企業內策略執行成敗的關鍵因素，專案也擁有相當 獨特的性質，而這些特性也讓專案管理成為一門專業的研究領域，其中一些重要的特性 如下： 表2. 專案的基本特性 專案特質 描述 暫時性 ƒ 每個專案都有一個明確的開始點和終止點。當專案的目標達成， 或是已經明顯確認難以實行時，就是專案的終止點。 ƒ 不一定表示著是短期的，有些專案需要持續執行數年之久，但是 可以確定的是，專案必須要有一定的時程，而不是永無止境的實 行。 ƒ 專案的目的是為了促進專案任務的目標的達成，並且要讓它有一 個圓滿的結束。 獨特的產品、 服務或結果 專案是從事一項前所未有的事物，即使它是一個複雜且龐大的專案屬 性而已，專案的基本獨特性並不會因為重複性的存在而有所更動。 持續的演進 ƒ 由於每一個專案都是具有獨特性的，因此若要區分產品或是服務 的特性就需要持續的演進。 ƒ 「持續的」代表的是依照步驟的進行；「演進」代表的是完全地 小心並仔細的發展，並且產生結果。

2.2.2 專案管理的定義與特性

專案的進行過程中，會有許多的資源、人員參與，同時也會有品質、時程、成本等 等的限制，當然還會有風險的產生，為了讓專案能夠順利的完成以滿足組織或是企業的 期望，因此必須針對專案的多面性進行管理。 專案管理所產生的結果通常會促進流程或是策略的改善，但是專案管理的理論並不 是由某個人或是組織所發明的；專案管理其實並不是於近代才出現的，在古代，例如埃 及金字塔的建造、中國長城的修築、歐洲教堂的興建，乃至每一次的軍事或是探險活動， 每一項都是以專案的方式執行，當中也都包含了詳盡而完整的計畫，這些案例都證明了

專案管理的重要性及必要性。在近代引起專案管理組織注意的綜合性文章之一為西元 1959 年五/六月號的《哈佛商業評論(Harvard Business Review)》內一篇由保羅‧葛第斯 (Paul O. Gaddis)所發表的，描述此個人在先進科技工業的角色、擔任專案管理工作所需 的必要條件、以及建議的訓練類型以使個人準備好來管理專案。

目前國際上發展專案管理的理論團體中，以西元1969 年成立的美國專案管理學會 (Project Management Institute, PMI)組織最為龐大、系統最為成熟； PMI 邀請多位知名 的專案管理專家及學者參與，經歷多年的研究及編撰，於西元1984 年完成「專案管理 知識體系指南」〈The Project Management Body of Knowledge, PMBOK®〉，書中提到專案 管理中分為九大知識領域及五大過程，為原本百家爭鳴的專案管理訂定了一個標準架 構。世界標準組織(ISO)更於西元 1987 年參考 PMBOK® 制定了 ISO10006，使它在國際 上更具有舉足輕重的地位，而成為專案管理領域最重要的知識理論架構。 在PMBOK®中是這樣定義專案管理的：「專案管理」是將管理知識、技術、工具和 方法綜合運用到一個專案活動上，以期能符合專案的需求。專案管理是經由專案起始、 計劃、執行、控制及結案等五大過程的運作，方得以完成。專案團隊負責管理各項專案 工作，而這些工作基本上包含： ƒ 範疇、時間、成本、風險、和品質間之需求競爭 ƒ 利害關係人間彼此不同的需求及期望 ƒ 已辨識的需求 在進行專案管理的過程中，除了需要滿足上述的需求之外，由於每個專案都有其獨 特性，所以每個專案也就擁有某些不確定性，也正因為如此，再執行專案的時候，經常 會將專案切割成不同的專案階段(Project Phase)，這樣比較容易進行管理的工作，同時也 可以利用組織上持續性的作業，將不同的專案階段連結在一起，或是透過專案階段的管 理，針對需要反覆推演的部分，加以控制評量，以確認專案階段工作的推進。 每一個專案階段都需要產出一項以上的「交付標的」(Deliverables)，而交付標的的 目的就是做為專案階段確認完成的標記，而「交付標的」必須是有形的且可以驗證的產 物。一般來說，是用審查主要交付標的和專案績效的方式作為一個專案階段結束的註 記，而這些註記的內容通常包含了專案是否應該可以進行到下一個階段的決定以及在成 本效益上的錯誤的檢定與更正資料。而這些在每個階段之後的審查工作，也可以被稱之 為「階段結束處」(Phase Exits)、「步驟開始處」(Stage Gates)或是「封殺點」(Kill points)， 這些名稱正是能夠突顯出對於專案階段來說，審查的工作是相當重要且不可忽視的重

點，同時也能提供專案管理的機制，以確實執行專案管理及控制的目的。

2.2.3 PMI 的需求管理─專案範疇管理

在PMBOK 書中提到專案管理中分為九大知識領域及五大過程，其中跟需求管理最 有關係的是『專案範疇管理』知識領域，在專案起始階段，有『專案起始』的過程；而 在計劃階段，則有『範疇計劃』、『範疇定義』、『範疇驗證』與『範疇變更控制之投入』 的過程，這些都是可以協助專案在問題定義與需求分析階段時所有必須執行的工作項目 都能被列入在專案工作，促使專案能夠成功的過程；而這些過程的重點是指導人們如何 去定義以及去控制專案中的工作項目。 而專案範疇管理主要是在定義和控制在專案當中，哪些工作項目需不需要被包含在 內，而這些工作項目將會關係到專案的範圍；透過工作項目清單的產生，同時也可以釐 清是否達到客戶的需求，因此專案範疇管理可以喻為是專案成功與否的關鍵流程。而表 3 為專案範疇管理的基本概念。 表3. 專案範疇管理的基本概念 項目名稱 投入 工具及技術 產出 專案起始 1. 產品說明 2. 策略計劃 3. 專案選擇準則 4. 歷史性資料 1. 專案選擇方法 2. 專家判斷 1. 專案核准證明 2. 專案經理人的確 認/指派 3. 限制條件 4. 假設事項 範疇計劃 1. 產品說明 2. 專案核准證明 3. 限制條件 4. 假設事項 1. 產品分析 2. 利潤/成本分析 3. 備選方法的辨識 4. 專家判斷 1. 範疇聲明 2. 支援細節 3. 範疇管理計劃 範疇定義 1. 範疇聲明 2. 限制條件 3. 假設事項 4. 其他規劃之產出 5. 歷史性資料 1. 工作分解結構範 本 2. 分解 1. 工作分解結構 2. 範疇聲明更新

範疇驗證 1. 工作結果 2. 產品文件 3. 工作分解結構 4. 範疇聲明 5. 專案計畫書 1. 計劃 1. 正式接受 範疇變更控制 1. 工作分解結構 2. 績效報告 3. 變更請求 4. 範疇管理計劃 1. 範疇變更控制系 統 2. 績效評量 3. 額外的規劃 1. 範疇變更 2. 更正行動 3. 經驗學習 4. 調整基準 2.2.3.1 專案起始 其中在專案起始階段，是由『專案起始』策略開始的，關於『專案起始』，PMBOK 是這樣描述的： 『專案起始』是正式地宣告一個新專案的存在或是已存在的專案應持續進入下階段的一 系列程序；而這個起始係要將專案和組之內常態性工作連結在一起。某些形式的專案， 特別是內部服務和新產品開發的專案，剛開始時是以非正式的方式進行若干有限的工 作，以獲得正式開始進行專案時所需的認可。而基本上，專案之授權至少受到下列一項 原因之影響所造成：市場需求、商業需求、顧客請求、追求新科技、法律要求、社會需 要。以上這些啟動專案的因素也可能被視為是問題、機會或是商業的需求。 圖6. 專案起始圖 資料來源：PMBOK 專案管理知識體系導讀指南

而『專案起始』其中包含了事前投入的資料、執行的工具或技術及產出資料，說明 如下： 1. 事前投入的資料 (1)產品說明： 是用來描述專案所創造之產品或服務的特性。產品說明在初期階段只對產品 做概略性的說明，經過進一步的發展後，才逐漸會有比較詳細的描述。此外 產品說明應該也需要陳述該項產品或服務對於企業的需要或其他促使這個 專案發展原因的關係。就算是當產品說明的形式或內容有所變更時，也應該 詳細描述，以利支援後續專案的規劃。許多專案是依合約由一個組織(賣方) 為另一個組織(買方)工作，在這種情況下，最初的產品說明經常是由買方提 供。 (2)策略計劃： 所有專案應該支持執行組織的策略目標─策略計劃應該被視為專案選擇的 一項決定因素。 (3)專案選擇準則： 專案選擇準則通常是從專案產品的觀點來定義，所有管理方面的考量都是可 能涵蓋的範圍。 (4)歷史性資料： 當『專案起始』過程牽涉到下一階段的專案進行是否會被許可時，則有關上 個階段執行的結果資料通常是相當關鍵的。 2. 執行的工具或技術 (1)專案選擇方法： 指的是對於專案擁有者(Project Owner)所能產生的價值及吸引力的評量， 也就是運用一些決策模式的技術與特殊的計算方式，在許多不確定的因素下 計算價值的方式。 (2)專家判斷： 『專案起始』過程中經常需要某些專業技術來評估，而這些專業技術，可以 藉由任何具有專業知識或受過特殊訓練的個人或是團體來提供。他們可能 是：組織裡的其他部門、顧問、利害關係人、專業人士、以及產業團體等。 3. 產出資料： (1)專案核准證明：

是用來確認專案存在的一份正式文件。若專案是以合約的方式來執行，對賣 方來說，所簽署的合約就是一份專案核准證明了。 (2)專案經理人的確認/指派： 一般來說，專案經理人應該在專案初期就已經確認或指派。 (3)限制條件： 是專案團隊可以選擇的因素，例如：預算、合約等。 (4)假設事項： 為達成計劃的目的而被視為是真實的、實際的或確定的一些考慮因素，例 如：如果某一個主要的成員的加入專案起始日期不能確定的話，就可能需要 事先預定一個特定的起始日期。而假設事項通常都含有某種程度的風險。 2.2.3.2 範疇計劃 執行完『專案起始』過程後，接下來就是『範疇計劃』了，對於『範疇計劃』，PMBOK 是這樣描述的： 『範疇計劃』是以循序漸進的方式為生產專案產品所需的專案工作所發展出的一份書面 說明。專案範疇的規劃是先從『產品說明』開始，接著是『專案核准證明』以及『限制 條件』與『假設事項』的定義。而『產品說明』需要融入產品需求，而且應該要充分反 映經過認可後的顧客需要；產品的設計則更需要完全符合產品需求的。 圖7. 範疇計劃圖 資料來源：PMBOK 專案管理知識體系導讀指南 而『範疇計劃』其中包含了事前投入的資料、執行的工具或技術及產出資料，說明 如下： 1. 事前投入的資料

(1)產品說明： (2)專案核准證明： (3)限制條件： (4)假設事項： 2. 執行的工具或技術 (1)產品分析： 主要是提供對專案產品有更清楚的了解。可能包含如系統工程、價值工程、 功能分析和品質功能展開等技術。 (2)利潤/成本分析： 去估算多個方案中的有形和無形成本以及利潤，並且使用財務評量方法，藉 由這些方法來評估這些方案的相對優點。 (3)備選方法的辨識： 利用不同的方式，產生專案一個概括性的描述，最常用的是腦力激盪和側面 思考。 (4)專家判斷： 『專案起始』過程中經常需要某些專業技術來評估，而這些專業技術，可以 藉由任何具有專業知識或受過特殊訓練的個人或是團體來提供。他們可能 是：組織裡的其他部門、顧問、利害關係人、專業人士、以及產業團體等。 3. 產出資料： (1)範疇聲明： 是提供未來專案決策與確認或發展利害關係人對於專案範疇共同認知基礎的 一份書面文件。當專案進行時，範疇聲明可能需要修訂或更新，以適時反映 專案範疇的任何改變。它還應該直接或間接地運用下列文件： ƒ 專案理由：說明專案是因應需要而產生的原因 ƒ 專案產品：為產品說明的簡要摘要 ƒ 專案交付標的：專案應該提供次產品的摘要目錄表，此外任何已知卻未 被列入的項目也該被列入。 ƒ 專案目標：是一個可計量的範圍，而且專案必須符合此範圍內的要求才 算成功。而其中至少應該包含成本、時程和品質的評量。 (2)支援細節： 應該包括所有已確認的假設事項和相關限制條件，而且在組合後以書面方式

記載，以利於其他程序的有效運用。 (3)範疇管理計劃： 一份描述了專案範疇將如何管理，以及如何整合範疇變更到專案中的文件。 範疇管理計劃可能是正式或非正式的、詳盡的或是簡略的，是依照專案的需 要來決定的。 2.2.3.3 範疇定義 執行完『範疇計劃』過程後，接下來就是『範疇定義』了，對於『範疇定義』，PMBOK 是這樣描述的： 『範疇計劃』的目的是將主要的專案交付標的細分為較小而且較容易管理的元素，這樣 能夠幫助達到改善成本、時間和資源預估的準確度，也可以藉此定義績效評量和控制的 基準，同時也可以釐清責任的分派問題。 而適當的範疇定義對於專案的成功是非常重要的，因為當範疇定義不佳的話，專案最後 的成本預期可能會增加，因為無可避免的變更更會打斷專案的節奏、造成重做、增加專 案時程，以及降低生產力與影響員工士氣。 圖8. 範疇定義圖 資料來源：PMBOK 專案管理知識體系導讀指南 而『範疇定義』其中包含了事前投入的資料、執行的工具或技術及產出資料，說明 如下： 1. 事前投入的資料： (1)範疇聲明： (2)限制條件：

如果當專案是依據合約來執行時，合約條款定義中的限制條件經常是『範疇 定義』過程中相當重要的考量因素。 (3)假設事項： (4)其他規劃之產出： 在專案的進行當中，通常還會同時進行其他的知識領域過程，而這些已經進 行的知識領域過程的產出資料，也需要一併檢視是否會對範疇定義可能造成 影響。 (5)歷史性的資料： 對於過去如果有類似的專案的歷史性的資料應該納入考量的，尤其是曾經發 生過的錯誤或是疏忽鬥是特別需要注意的及參考的。 2. 執行的工具或技術：

(1)工作分解結構範本(Work Breakdown Structure Templates)：

先前專案中的工作分解結構(WBS)可以作為新專案的範本。因為大多數的專 案都會有相同或是相似的生命週期，所以每一個階段會有相同或是相似的交 付標的。 (2)分解(Decomposition)： 主要是能將專案交付標的細分成更小且較容易管理的元素，直到交付標的的 定義詳盡到可以支援未來的專案活動(例如：計劃、執行、控制跟結案)。它 包含下列步驟： ƒ 辨識出專案的主要元素。一般而言，主要元素就是專案交付標的和專案 管理事項。 ƒ 決定適當的成本和時程預估能否在此詳細的層級下發展。 ƒ 辨識交付標的所構成的元素，它應該以具體可驗證的結果來陳述，以利 績效的評量。 ƒ 確認分解的正確性，如果有缺失則必須加以修正： ƒ 基層的項目是否對於已經分解的項目的完成有其必要和充分性? ƒ 每個項目是否都已經清楚且完整的定義? ƒ 每個項目是否都已經被適當的安排時程、分配預算或被指派到特定的 組織單位?誰將負起達成任務的責任? 3. 產出資料：

工作分解結構是一個以交付標的為導向的專案元素集合體，用來定義全部專 案的範疇。對於範疇聲明來說，WBS 經常被用來發展或確認對專案範疇的 綜合性瞭解。 (2)範疇聲明更新： 包含任何範疇聲明內容的更新需要時，重要相關的專案利害關係人都要給予 通知。 2.2.3.4 範疇驗證 對於『範疇驗證』，PMBOK 是這樣描述的： 『範疇驗證』是指一個專案的範疇被利害關係人正式接受的程序，它需要檢視工作產出 和結果，以確保所有的工作都已正確且令人滿意地完成。若專案被提早中止，『範疇驗 證』過程則應將已完成的工作程度和範圍加以建檔留存。『範疇驗證』與『品質控制』 是不同的，因為『範疇驗證』主要關切的是工作結果的接受度，而『品質控制』則是在 乎工作結果的正確度。 圖9. 範疇驗證圖 資料來源：PMBOK 專案管理知識體系導讀指南 而『範疇驗證』其中包含了事前投入的資料、執行的工具或技術及產出資料，說明 如下： 1. 事前投入的資料： (1)工作結果： 指的是哪些交付標的已經被完全或是部份完成？什麼成本已經發生或已承 偌將會被使用等等？

(2)產品文件： 一份用以描述專案產品必須完備以供審查的文件，此文件的名稱(如計劃、 規格說明書、技術文件等)會隨著應用領域的不同而有所改變。 (3)工作分解結構： WBS 可以用來協助範疇定義，並可用來確認專案的各項工作。 (4)範疇聲明： 範疇聲明是一份可以詳細的定義範疇且需要被確認的文件。 (5)專案計畫書 2. 執行的工具或技術： (1)檢查： 檢查包含評量、檢驗和測試等活動，以決定結果是否與要求的條件相符合。 3. 產出資料： (1)正式接受： 指已被委託人或顧客接受的專案產品或是必須準備進入分派執行階段的憑 證，有些接受可能有條件的，尤其是在專案階段的末期。 2.2.3.5 範疇變更控制 對於『範疇變更控制』，PMBOK 是這樣描述的： 『範疇變更控制』主要關注以下三件事情：(A)影響產生範疇變更的因素，以確保此變 更是有益的；(B)如何決定範疇變更已經發生；(C)當變更實際發生時，則施予必要的管 理。 圖10. 範疇變更控制圖 資料來源：PMBOK 專案管理知識體系導讀指南 而『範疇變更控制』其中包含了事前投入的資料、執行的工具或技術及產出資料，

說明如下： 1. 事前投入的資料： (1)工作分解結構(WBS) (2)績效報告書： 績效報告書會提供範疇績效的資料，如哪些「中間產品」已經完成或是尚 未完成的說明；績效報告也可以作為向專案小組提出未來可能發生的問題 的警訊‧ (3)變更請求： 變更請求有多種不同形式表達，例如：口頭的或是書面的、直接的或是間 接的、由外部發起的或是內部發起的。變更可能引起範疇範圍的擴大或是 縮小。 (4)範疇管理計劃 2. 執行的工具或技術： (1)範疇變更控制系統： 範疇變更控制系統定義了專案範疇中可能改變的程序，它可以包含文書工 作、追蹤系統以及被授權許可變更的層級。 (2)績效評量： 績效評量有助於衡量所發生的任何變異的大小，而它的重要功能為可以決 定什麼因素造成此種變異？以及是否需要採取更正行動？ (3)額外的規劃： 因為專案很少能完全按照計劃來進行，因此可以被預見的範疇變更可能需 要去修改WBS 或是分析備用的方法。 3. 產出資料： (1)範疇變更： 範疇變更是對於已經認可過的WBS 中定義過的專案範疇所做的任何修改， 範疇變更通常要諄對成本、時間、品質或其他的專案目標進行調整。而範疇 變更可以經由計劃過程來獲得回饋，相對應的技術與計劃文件也應該隨著更 新，同時也要知會相關的利害關係人。 (2)更正行動： 更正行動指的是採取任何必要的作為使得專案計畫能符合對未來專案績效 的期許。

(3)經驗學習： 所有執行範疇變更所學到的經驗，都應該列入資料庫裡，使得這些變更資料 成為此次專案及其他專案歷史性資料的一部份。 (4)調整基準： 調整基準是基於變更的本質而定，原先符合基準的文件可能還需要修訂及重 新發佈，來因應已經核准的變更，並且為未來的變更建立一項新的基準。

2.3 軟體能力成熟度整合的需求管理

2.3.1 CMMI 能力成熟度整合模式

CMMI 是美國軟體工程學院所發展的軟體開發能力評鑑，前身是能力成熟度模式 （CMM；Capability Maturity Model）。1986 年，美國卡內基美隆大學的軟體工程學院 (SEI；Software Engineering Institute)接受美國國防部委託，發展一套用來評鑑組織、部 門或團隊軟體專案開發能力水準的評鑑模型，同時對軟體開發的流程提供嚴謹完備的架 構與描述，這套模型就是舉世聞名的CMM。

歷經 20 年沿革，SEI 近年延展 CMM 意涵與適用性，開發可用於系統工程、軟體工 程、軟硬體系統整合、產品與流程整合開發、供應商管理等應用領域之上的新模型— CMMI，而 CMMI 不只涵蓋原 CMM 模型，還將系統工程標準 EIA731、國際品保 ISO 模式的標準定義集於一身。 CMMI 不只要求導入企業依循規範改善系統工程與軟體專案的開發流程，以提高軟 體生產力與品質，同時也提供完整的評鑑架構。現階段，在國際軟體市場上，多數業者 已將有無通過 CMMI 評鑑，視為能否承接軟體代工專案的重要條件。 CMMI 對於系統發展 及管理的流程建立嚴謹的規範，同時將某一團隊的能力成熟度區分成 5 個等級，最高為 第五級（Level 5）。

圖 11. CMMI 能力成熟度等級圖 資料來源：PMBOK 專案管理知識體系導讀指南 1. CMM-Level 1（initial）： 軟體程序漫無章法，程序未被定義。專案計劃的成功仰賴於工作人員個別的努 力。 2. CMM-Level 2（repeatable）： 已建立基本的管理程序，對成本、時程、和職務權責能加以追蹤、查詢。已 有作業程序所須具有的紀律，所以有能力重覆使用相類似的專案成功的案例 與經驗。 3. CMM-Level 3（defined）： 屬於管理和工程的活動都已設計、定義好，並且文件化，完整地整合成組織 內的標準作業程序。各個專案計劃延用標準程序或被認可的標準程序修改程 序。 4. CMM-Level 4（managed）： 組織可收集詳細的軟體程序以及軟體產品的量測資料。軟體作業程序和產品 都有一組量測的數據，可讓工程師和經理們了解程序和產品的狀況。 5. CMM-Level 5（optimized）： 評估革新性的新技術，有規則地依序導入採用，以持續不斷地改進程序。 就模型設計單位SEI 自己的觀點來看，CMMI 設計的目的，是要提供一個衡量組織

軟體過程能力的尺度，這個尺度是以美國資訊軟體業界的最佳常規(state-of-the-practice) 為基準的，讓被衡量的組織了解自己的能力，以及可以改善的方向。 然而， 如果要衡量專案成熟度層級中的關鍵流程領域，在專案的實施與制度化上 是否具有效性、可否重複使用執行、以及是否可持續下去，尚必須參考CMMI 的五個共 同特徵(如表 4)進一步依專案特性及組織文化來發展所需的關鍵樣版，由上而下評估專 案流程，以規範專案的發展及管理架構中作業與能力層面的成熟程度及完整性。 表4. 能力成熟度的共同特徵 共同特徵 描述與關鍵技巧 執行的承諾 組織用來確信程序皆已被建立並可持續做下去所採取的行動。 典型的例子包括建立組織政策及領導。 執行的能力 專案或組織有能力來實施軟體程序所需具備的先前條件。典型 的例子包括資源、組織架構政策及訓練。 執行的活動 實施某一關鍵流程領域所需具備的活動、角色、及過程。典型 的例子包括建立規劃和過程、執行工作、追蹤該工作、及採取 必要的修正行動。 量度與分析 判斷與流程有關的狀況所需的基本度量實務，此量度是用來控 制改進程序之用。例子包括可採用的度量樣本。 實施的驗證 用來確定所有的活動都依照著既定的程序在執行所採行的步 驟。典型的例子包括管理者和軟體品質保證小組所執行的審閱 與稽核。

資料來源：Mark Paulk (2001), Extreme Programming from a CMM Perspective, XP Universe.

2.3.2 CMM-Level 2 的需求管理

在CMMI 成熟度第二級當中，包含了七大流程領域：需求管理、專案規劃、專案 監控、供應商協議管理、度量與分析、流程與產品品質保證與建構管理。而需求管理的 目的，在於管理專案產品級產品組件的需求，並界定這些需求與專案計劃及工作產品間 的差異。

圖12. CMMI Level 2 流程領域圖 資料來源：工研院資通所 其中需求管理流程指的是管理專案所收受或發展的所在需求，包括技術性與非技 術需求，以及組織加在專案的需求。尤其是如果組織實施「需求發展」流程領域，它的 流程所產生的產品及產品組件需求，也要納入需求管理流程的管理。當組織實施需求發 展、需求管理及技術解決方案等流程領域，它們相關的流程將會緊密聯繫並同步執行。 而專案採行適當的步驟，確保議定的需求是受管理的，以支援專案規劃和執行的需 要。當專案從已核定的需求提供者收受需求時，應與其一起審查，以便在需求納入專案 計劃前，先行解決有關議題並避免誤解。一旦需求提供與接受的雙方達成協議時，需再 取得專案成員對需求的承諾。當需求漸進發展時，專案需管理需求的變更，並界定計劃、 工作產品，以及需求間任何的差異。 「需求管理」流程包含了特定及一般目標以及相關目標的執行方法，其中特殊目標 如圖13 所示：