中 華 大 學

中 華 大 學 碩 士 論 文

題目 題目

題目 題目： ： ：系統動態觀點下軟體開發 ： 系統動態觀點下軟體開發 系統動態觀點下軟體開發專案 系統動態觀點下軟體開發 專案 專案 專案之 之 之 之 探討

探討 探討

探討─以某資訊軟體 以某資訊軟體 以某資訊軟體 以某資訊軟體開發公司 開發公司 開發公司為例 開發公司 為例 為例 為例

系 所 別：科 技 管 理 研 究 所 學號姓名：E09603007 吳 秀 茹 指導教授：林 錦 煌 博 士

中華民國九十八年八月

謝 謝

謝 謝 辭 辭 辭 辭

衷心感謝指導教授林錦煌博士的悉心教誨，並提供自行蒐集整理之國內外 文獻，讓我粗略的概念能理出頭緒，進而完成本論文。

衷心感謝兩位口試委員：楊和利博士與劉典嚴博士，仔細審查並指正疏漏，

使其更加完善。

論文靈感來自我之前公司導入能力成熟度評鑑機制，個人擔任流程改善小 組主要成員之一，藉此感謝核心研發處同仁在推廣時積極配合並對論文方向給 予看法與建議，加強理論與實務的結合。

衷心感謝科技管理所各位師長、學長姐與 96 級同學：明樟、政全、國強、

琬淇、碧貞、文祥、廷福，大方分享課業知識、論文寫作等等，也充實這 2 年 求學生活。

吳秀茹 謹誌 于中華科管所 中華民國九十八年八月

摘 摘

摘 摘 要 要 要 要

國內資訊軟體廠商多半由中小企業所組成，即使政府積極輔導廠商導入能 力成熟度整合模式(CMMI)，但在人力與成本的考量下未能使用，使軟體專案管 理能力與軟體開發流程制度仍不完善，導致軟體專案品質與結案率無法與國外 大廠制衡。雖然已有許多探討這類問題的研究，但都偏重單方面討論管理層面 或成功因素，缺乏全面性整合概念。

本研究藉由軟體專案管理的文獻探討輔以 CMMI 流程規範，歸納出軟體開 發專案各階段的主要影響因素。且因軟體專案具有時間滯延、動態性複雜等特 性，可使用系統動態學建構出軟體開發專案流程模式。

此模式可以提供專案管理者總觀整個流程概念，釐清各項因素相互間的因 果關係，以追根溯源發現問題癥結所在，並給予適時的妥善及平衡處理；也可 以讓專案開發團隊人員加深整體開發流程架構觀念，並即時回饋給專案管理 者，最終得以提高專案品質與結案率。

關鍵關鍵

關鍵關鍵字字字字：：：：系統動態學、軟體專案管理、軟體開發流程、能力成熟度整合模式

ABSTRACT

Most firms of the information software industry are small and medium enterprises (SMEs), even if the government has been actively counseling they into the Capability Maturity Model Integration (CMMI), but they don’t implement the CMMI after considered with the human resource and cost, so that the capability of the software project management and software development process are not perfect, resulting in software quality and project closing rate unable to compete with foreign firms. Although there have been many studies to explore such issues, but emphasis on unilateral management or success factors, lack of a comprehensive concept of integration.

This study used the literature review in software project management and the CMMI process into the software development process at various stages of the main factors. And as a result of software project time-delay, dynamic and complex characteristics can be used to verify the System Dynamics (SD) methodology of building software development process model.

This model can provide project manager overview of the whole concept of process, to clarify the causal-loop relationship between the various factors to early detection of the crux of the problem and make proper solution. It also allows the team members to enhance the overall development of the concept of process architecture and feedback to the project manager in time, which will eventually be improved the software project quality and enhanced the closing rate.

Keywords: System Dynamics, software project management, software development process, Capability Maturity Model Integration

目 目

目 目 次 次 次 次

摘 要... i

目 次...iii

表 次... v

圖 次... vi

第一章 緒論... 1

第一節 研究背景與動機... 1

第二節 研究目的... 3

第三節 研究流程與章節安排... 4

第二章 文獻探討... 7

第一節 軟體專案管理... 7

第二節 能力成熟度整合模式... 16

第三節 小結... 31

第三章 研究方法... 32

第一節 個案研究... 32

第二節 系統動態學... 33

第三節 模型主要元件... 37

第四章 系統建模... 39

第一節 研究對象... 39

第二節 軟體開發專案系統動態模型... 47

第三節 小結... 63

第五章 結論與建議... 64

第一節 結論... 64

第二節 管理上的意涵... 65

第三節 後續研究建議與研究限制... 66

參考文獻... 67

表 表

表 表 次 次 次 次

表 1 軟體專案成功的影響因素彙整表... 15

表 2 連續式與階層式表述比較表... 21

表 3 一般目標與一般執行方法表... 30

表 4 專案管理生命週期與 CMMI 流程領域對應表... 31

表 5 應用系統動態學之比較表... 34

表 6 應用系統動態學在軟體專案管理之文獻彙整表... 36

表 7 系統動態流圖符號表... 38

表 8 V 公司軟體專案流程工作表... 41

表 9 V 公司之 CMMI 工作項目表... 44

表 10 V 公司對應 CMMI 文件表... 45

表 11 專案初始階段因果關聯表... 48

表 12 專案規劃階段因果關聯表... 52

表 13 軟體工程與專案監控階段因果關聯表... 56

表 14 專案結束階段因果關聯表... 59

表 15 V 公司軟體專案開發流程之積量率量表 ... 61

圖 圖

圖 圖 次 次 次 次

圖 1 研究架構圖... 4

圖 2 研究流程圖... 5

圖 3 典型專案管理生命週期模式... 9

圖 4 Lewis 專案管理生命週期模式 ... 10

圖 5 Adams and Brandt 專案管理生命週期模式... 11

圖 6 瀑布式軟體開發生命週期模式... 13

圖 7 CMMI 發展歷程圖... 17

圖 8 階層式表述... 18

圖 9 成熟度等級... 19

圖 10 連續式表述... 20

圖 11 能力等級... 20

圖 12 CMMI 流程領域... 23

圖 13 工程類流程領域圖... 27

圖 14 瀑布式軟體開發生命週期與工程類流程領域關聯圖... 28

圖 15 存量與流量示意圖... 37

圖 16 V 公司軟體開發生命週期與專案管理生命週期模式 ... 40

圖 17 專案初始子系統... 50

圖 18 專案規劃子系統... 54

圖 19 軟體工程與專案監控子系統... 58

圖 20 專案結束子系統... 60

圖 21 V 公司軟體開發專案系統動態流圖... 62

第一章 第一章

第一章 第一章 緒論 緒論 緒論 緒論

本章節闡述目前軟體市場環境與未來發展性，並探討在現今政府所提出的 政策下，對資訊軟體服業的提升與轉型、廠商的動態與未來發展性的影響。發 現國內資訊軟體廠商在軟體專案品質與產品成熟度不足的成因，進一步構成本 研究動機與目的。

第一節 第一節 第一節

第一節 研究背景與動機 研究背景與動機 研究背景與動機 研究背景與動機

根據財團法人資訊工業策進會資訊市場情報中心網站(mic.iii.org.tw)針對 企業資訊軟體調查結果顯示，2008 年台灣資訊軟體市場為 292 億台幣，相較於 2007 年成長了 10.4%，預估 2010 年台灣資訊軟體市場將達到 350 億台幣規模。

而且資訊市場情報中心也引用 INPUT 機構調查結果，預估到 2010 年，軟體與 資訊服務將占 65%，硬體只占 35%。軟體與資訊服務在全球資訊市場的比重逐 年上升，加上資訊軟體服務業具有無污染的特性，符合綠色環保的趨勢，未來 軟體市場發展的前景會比硬體好。

能力成熟度整合模式(Capability Maturity Model Integration, CMMI)，是美國 卡內基美隆大學軟體工程學院(SEI)結合過去軟體工程與專案管理的理論，輔以 持續改善觀念，所建立一套軟體流程改善模式，如今被視為軟體品質保證與國 際合作的基本要求。政府為提升國家資訊軟體產業的競爭力，將資訊服務業轉 型為外銷導向之知識產業，在 2005 年由經濟部工業局委託中華民國資訊軟體協 會執行「提升資訊軟體品質(CMMI)計畫」，期許導入 CMMI 廠商能提升專案管 理能力、掌握專案時程、成本與品質，藉由不斷的流程改善促進生產力與降低 營運成本。經濟部工業局提升資訊軟體品質計畫網站(www.cmmi-taiwan.org.tw) 說明該計畫願景為「推動資訊服務業“大型化”與“國際化”之基礎工程」。從協助 資訊服務業者提升生產力、增強承接大型與複雜專案能力與建立資訊服務業協 作平台，進而醞釀資訊服務業者外銷潛力，最終以轉型成外銷導向之知識產業 為目標。經過 4 年計畫執行時間，已成功輔導 3 家達到成熟度第五級、38 家成

熟度第三級及 76 家成熟度第二級的廠商。

國內資訊軟體服務業有高達 95.8%由中小企業所組成(經濟部中小企業 處，2008)，在研發經費、人力與內部管理方面均無法與國際規模大廠相比，尤 其是軟體專案主要由人所組成，要讓專案管理者與開發人員能相互溝通並達成 共識，其軟體專案管理能力與軟體開發流程制度就受到業界的重視，而這又需 要大量人力、時間與費用的投入，才能建構一套可確保軟體品質穩定的軟體專 案管理流程系統。特別是當軟體開發進度落後時，專案管理者總是直覺地增加 人力，卻造成更嚴重的時程延誤，正如 Brooks(1995)在「The mythical Man-Month」

一書中指出，專案管理者的預估技術常誤把工作量和專案進度混為一談，以為 人力和工時可以互換，增加人力就可以帶來工時的減少，但是在時程已經落後 的專案中加派人手，只會讓軟體專案更加落後，結果是帶來大災難。

加上國內廠商通常基於成本或其他因素考量下，無法導入或建置完善的管 理流程與專案知識庫，試著解決預估技術薄弱的問題，讓軟體開發的專案規劃 停留在專案管理者個人臆測、客戶需求無法透過專案管理者傳達給開發人員，

使開發人員的系統需求規格總是存在落差，導致時常發生預算超出與時程延 誤。還有專案範圍模糊不清，使得要開發的功能不斷增加或陷入重工重工重工重工(rework) 迴圈中，特別是大型系統的軟體開發工作，當各種問題同時發生又互相糾葛，

使專案越來越停滯不前，就像掉入焦油坑(Brooks, 1995)。最後就算系統可以運 作，品質卻無法維持穩定，導致結案率偏低。

Phan、Vogel and Nunamaker(1995)的研究發現軟體專案開發的問題大多是 管理問題，技術問題所占的比例反而較低。Standish Group(2006)在CHAOS報告 指出，有46%的軟體專案會超出成本與時程或沒有完全符合客戶需要，甚至有 19%的軟體專案是完全失敗，只有35%的軟體專案可以在受控制的成本、時程與 品質下完成。而林信惠、黃明祥與王文良(2005)將軟體專案管理的範疇分為管理 主題、作業流程與開發程序三個構面，其中管理主題的主要議題為時程、成本

與品質，所以軟體專案開發遭遇到的困難與軟體專案管理有密切相關。特別是 專案進行到中後期時，還會專注在團隊內部網路的結合與爭取跨團隊網路的支 援，以完成專案任務(陳明惠、陳相甫，2008)。

由於軟體開發專案的特性具有時間滯延、資訊回饋、動態性複雜與非線性 (Coyle, 1996)，且企業面對複雜性動態環境，選擇系統動態學來做動態系統模擬 預測，是有利於決策過程的結構化與決策結果的預估(許玉芬，2005)。王錦泰與 管孟忠(2007)也利用系統動態學的因果關聯分析，來總觀整個專案系統中各因子 關係，認為有助了解專案中不易察覺的關鍵因素。

總結以上觀點，台灣資訊軟體市場仍有其成長空間與力道，為了開拓國際 市場，導入一套符合國際規範的制度與認證已勢在必行，但國內廠商衡量成本 時，往往會犧牲眼前暫時性的大筆支出，因此本研究欲以通過 CMMI 評鑑的廠 商為研究對象，建立軟體開發專案之系統動態模型，同時也能符合 CMMI 規範，

預計讓未導入 CMMI 廠商利用此模型進行開發，除了能快速釐清影響軟體專案 成敗因素，也能完成符合 CMMI 流程，將能降低未來實際導入時的差距。

第二節 第二節 第二節

第二節 研究目的 研究目的 研究目的 研究目的

本研究希望能藉由軟體專案管理的文獻探討輔以 CMMI 流程指導規範，歸 納出軟體開發專案流程階段與影響各階段的因果關聯因素，並應用已被驗證的 系統動態學方法論建構出一個動態模型，讓資訊軟體服務業內絕大多數之中小 型廠商，可以釐清軟體開發專案中各項因素之間因果關係，利用最少資源控制 每階段主要影響因素，也能讓專案進行符合 CMMI 規範，故本研究目的如下：

1.以某家資訊軟體開發公司通過 CMMI 成熟度第二級之軟體專案流程，建構一 個軟體開發專案的系統動態模型。

2.提供專案管理者快速總觀整個流程概念，釐清各項因素相互間的因果關係，以 追根溯源發現問題癥結所在，並給予適時的妥善及平衡處理。

3.提供專案開發團隊人員加深整體開發流程架構觀念，並即時回饋資訊給專案管

理者。

4.透過此模型讓專案管理者與專案開發團隊人員，對於軟體開發每一個階段的影 響因素容易達成共識，進而將有限資源專注投入影響深遠的因素中，以提高風 險防制的效率。

5.透過此模型建立符合 CMMI 開發流程，期以能降低導入 CMMI 的落差與抗拒。

第三節 第三節 第三節

第三節 研究 研究 研究 研究流程 流程 流程 流程與章節 與章節 與章節 與章節安排 安排 安排 安排

為達成本研究目的，將分為文獻探討、研究方法、研究對象等方面進行研 究，故本研究架構如圖 1 所示。

圖1 研究架構圖

首先以文獻探討方式整理出軟體開發專案之流程階段、軟體專案管理之影 響因素。而研究對象係分析某家資訊軟體開發公司的軟體開發作業程序，並以 能力成熟度整合模式加強其所採用軟體開發專案流程模式，然後採用系統動態 學之研究方法，建構出一套軟體開發專案系統動態模型。

規劃出本研究架構後，據此發展本研究流程，依序為說明研究動機與目的，

接著蒐集與探討相關文獻、選擇適合之研究方法、分析研究對象如何進行軟體 專案，再依此定義出軟體開發專案之流程階段與影響因素，用以建構軟體開發 專案系統動態模型，最後提出結論與後續研究建議，如圖 2 所示。

圖2 研究流程圖

故根據該研究流程圖，其章節安排說明如下：

第一章為緒論，說明目前國內資訊軟體服務業的環境，並探討在現今政府 所提出的政策下，對資訊軟體服務業的提升與轉型、廠商的動態與未來發展性

研究動機與目的

文獻探討

軟體開發專案 系統動態模型建構

結論與建議 軟體開發專案各階段

與影響因素定義 研究對象探討

第一章 緒論

第二章 文獻探討

研究方法選擇 第三章

研究方法

第四章 系統建模

第五章 結論與建議

的影響。發現國內資訊軟體廠商在軟體專案品質與產品成熟度不足的環境因 素，衍生出本研究動機與目的並建立其研究流程。

第二章為文獻探討，探討與本研究相關之文獻，包括軟體專案管理、能力 成熟度整合模式等。在軟體專案管理文獻中，主要是整理分析出影響專案成敗 的重大因素，以釐清模型中的因果關聯。而能力成熟度整合模式部分，則是找 出整個流程規範中，應達成的活動及文件，以建立能夠符合 CMMI 流程的模型，

最後再歸納出本研究對於文獻的看法與應用。

第三章為研究方法，闡述本研究所採用個案研究與系統動態學之理論與方 法。個案研究是一種實證研究方法，系統動態學是一套嚴謹地建立系統模型之 方法。首先是定義問題概念，分析研究對象實際執行之軟體專案，以界定問題 範圍並找出因素之間的兩兩關聯，然後利用真實案例的流程建構出系統動態模 型，並以個案研究法推論至該個案公司所屬產業。

第四章為系統建模，說明本研究之研究對象如何進行符合 CMMI 規範的軟 體開發專案，以及每個階段的核心活動與產出文件。利用第二章文獻探討所歸 納之影響因素，建立因果關聯循環並建構系統動態模型。本章節即是本研究的 主要研究成果說明。

第五章為結論與建議，將本研究結果做出總結並呼應第一章之研究目的。

另外針對本研究不足與研究受限的部分，提出未來研究方向並給予後續研究者 建議。

第二章 第二章

第二章 第二章 文獻探討 文獻探討 文獻探討 文獻探討

本章節探討與本研究相關之文獻，包括軟體專案管理、能力成熟度整合模 式等。在軟體專案管理文獻中，主要是整理分析出影響專案成敗的重大因素，

以釐清模型中的因果關聯。而能力成熟度整合模式部分，則是找出整個流程規 範中，應達成的活動及文件，以建立能夠符合 CMMI 流程的模型，最後再歸納 出本研究對於文獻的看法與應用。

第一節 第一節

第一節 第一節 軟體專案管理 軟體專案管理 軟體專案管理 軟體專案管理

軟體的本質在於為使用者解決問題的一種工具(鄧志成，2007)，但是研發 人員與使用者之間卻總存在著認知的落差，導致以下狀況時常發生：

1.使用者不確定自己到底需要什麼。

2.研發人員老是誤解使用者需求。

3.軟體開發的完成時間總是遙遙無期。

4.實際交付的產品毫無品質可言。

5.系統開發沒有撰寫文件。

對於軟體專案的管理，DeMarco(1997)曾經舉例「管理者的一天」的故事來 說明優質管理四大要素有：選擇對的人，然後替他們分配到對的工作並讓他們 對工作保持積極，最終幫忙團隊結合起來凝聚共識，維持團隊向心力，還指出 剩下的全都只是“文案”。

正因為軟體是無形的，通常會組成一個專案小組來共同開發軟體，故小組 成員之間的關 係與工 作環境在在影 響了軟 體的品質(Yabuuchi, Kocaoglu &

Watada, 2006)。如此看來，軟體開發存在太多不確定性，卻又簡單到把人管理 好，其他僅在製作文件而已。因此許多學者嘗試解決這些問題，分別對軟體開 發提出一些看法，並認為軟體專案也該有一套管理的方式。

一 一 一

一、 、 、 軟體專案管理 、 軟體專案管理 軟體專案管理 軟體專案管理定義 定義 定義 定義

Gido and Clements(2008)認為專案管理包括建立計畫、執行計畫與達成專案 目標，把握時間、考慮周詳並審慎評估以成功地完成各種專案。美國專案管理 協會(Project Management Institute, PMI)是國際上頗具權威的專案管理機構，定 義專案管理是將管理的知識、技術、工具與方法綜合運用到專案活動的行為(PMI, 2004)，因此專案管理包括確認與定義需求、建立清楚可達成的目標，且對於需 求是在相互競爭的範圍、時間、成本與品質之間取得平衡，輔以規格、計劃和 方法的修改調整，以符合甚至超越專案相關人員(stakeholder)之間不同的利益和 期望。

軟體專案管理(Software Project Management, SPM)是透過管理的方法，以降 低不確定性與風險(鄧志成，2007)，這可以是專案管理其中一環，因為林信惠、

黃明祥與王文良(2002)認為軟體專案管理是運用管理的原則與方法，使軟體開發 專案能達到預期的目標。而軟體專案廠商常面臨了軟體危機(Software Crisis)的 問題，也就是在軟體開發上要面對預算超出、時程延誤、可信度與客戶滿意度 低 ， 所 以 各 種 軟 體 工 程 的 方 法 與 推 陳 出 新 的 技 術 被 提 出 以 解 決 此 類 問 題 (Pressman, 2005)。

陳建蒝(2001)也認為軟體專案管理主要目的在軟體發展過程中，將可能會 影響專案時程或品質等因素，可以進行事前預防與調整，以避免軟體專案的問 題發生。當軟體專案需求規格不明確、開發人員流動頻繁使軟體專案管理更加 困難(林信惠等，2005)，這也表示妥適的專案規劃與監控必定伴隨著健全與可靠 的 管 理 ， 因 此 軟 體 專 案 管 理 是 一 項 最 具 挑 戰 性 的 軟 體 開 發 (Tarawneh, Al-Tarawneh & Elsheikh, 2008)。

進行軟體專案管理時，從時間序列的概念分段進行是比較容易可行的，生 命週期模式(Life-Cycle Model)正是以時間始末為基礎所建立的模式，以下將探 討專案管理生命週期模式及軟體開發生命週期模式。

二 二 二

二、 、 、 專案管理生命週期模式 、 專案管理生命週期模式 專案管理生命週期模式 專案管理生命週期模式

專案管理生命週期模式有各種不同觀點來看待，PMI(2004)認為專案管理生 命週期可以是概略的，也可以是非常詳細地定義，端看專案的類型，典型的專 案管理生命週期包括以下幾點：

1.各階段的技術性工作為何？

2.各階段的產出應如何被審查、確認與驗證？

3.各階段專案相關人員有哪些人？

4.各階段如何控制與核可？

典型專案管理生命週期模式分為初始、中期及結束等 3 大階段，每一個階 段有其輸入及產出的工作項目，如圖 3。

圖3 典型專案管理生命週期模式

Note. From ”A guide to the project management body of knowledge,” by PMI, 2004, p.23.

典型專案管理生命週期模式，一開始專案初始階段的輸入為概念，在專案

成形後則產出授權，表示專案正式啟動，接著專案管理小組加入並陳述專案範 圍，然後進入專案中期階段，此時可謂專案管理的重頭戲，因為專案管理主要 產出都發生在此階段，包括規劃、基準、發展。最後接受所開發出來的產品。

專案結束階段則批准完成的產品可以進行移交，再將產品交付給客戶。另一方 面，此專案的所有資源則進行交接，以利下次專案的進行。

Lewis(2005)自己也建立一套專案管理法，則是將專案管理生命週期模式分 為 5 個階段：概念、定義、計畫、執行、結案，且專案的特性會隨生命週期各 階段而改變，故專案規劃所投入的程度從概念、定義階段大量投入後再逐漸減 少，如圖 4。

圖4 Lewis 專案管理生命週期模式

Note. From “Project planning, scheduling, and control: A hands-on guide to bringing projects in on time and on budget,” by J. P. Lewis, 2005, p.36.

Lewis 專案管理生命週期模式，是從概念階段開始，在此投入行銷理論與 手法，也就是評估未來市場可行性，並調查競爭者狀態。接著定義問題、發展 願景並制定此專案任務的聲明，此為定義階段。由此可知，這兩階段都在規劃，

以做為未來專案執行的準備，故在專案規劃部分所投入的程度最高。

然後是計畫階段，針對前期的專案規劃進行專案發展策略、執行計畫並進

行風險管理。再來則進入執行階段，也就是開始做所有開發工作、進行監控，

若有缺失則有矯正行動。最後結案階段，則提出結案報告，此階段重要課題是 學習此專案的優缺點，並進行審查，以利後續專案執行。

Adams and Brandt(1983)則是以專案階段所需完成任務，來建立專案管理生 命週期模式，分為概念、規劃、執行與結束等 4 個階段。而投入程度在規劃、

執行階段達到高峰，如圖 5。

圖5 Adams and Brandt 專案管理生命週期模式

Note. From ”Behavioral implications of the project life cycle,” by J. R. Adams & S.

E. Brandt, 1983, p.227.

Adams and Brandt 專案管理生命週期模式是從概念階段開始，將需要(Need) 定義清楚並建立其可行性與備選方案，再依其準備專案建議書，以發展出基本 的預算與時程，然後定義適合專案團隊。規劃階段則依時程執行專案並實施研 究與分析專案內容是否可行，然後設計系統以建置、測試產品的雛型，並分析

結果以期獲得產品化的同意。

執行階段則為實際進行專案開發，開始採購原物料、建置及測試的工具，

發展專案以支援需求(Requirement)，在正式完成系統後進行驗證，確保效能有 達成需求，或是依照需求再修改。結束階段則建立功能與人員的訓練方針，以 提供下次專案參考。另外，將專案剩餘的原物料、專案原本所承擔的責任移交 至相關單位或人員，以進行追蹤或再利用，且由於專案結束，原本佔用的人力、

設備等資源亦隨之釋出。專案結束後如需後續服務與追蹤，再重新指派專案團 隊成員負責。

從以上 3 種專案管理生命週期模式可知，專案通常被分成概念成形、進行 規劃、正式執行並監控進度，最後是結案。本研究欲探討軟體開發專案，在執 行部分通常是指程式碼開發測試，即進行軟體工程的工作，故本研究結合以上 理論，擬將專案管理生命週期模式分為 4 大階段：專案初始、專案規劃、軟體 工程與專案監控、專案結束。

三 三 三

三、 、 、 軟體 、 軟體 軟體 軟體開發 開發 開發生命週期模式 開發 生命週期模式 生命週期模式 生命週期模式

軟體開發者需要一個系統性的流程以開發軟體，且隨著開發環境、專案目 標與類型的不同，各種不同的軟體開發模式也被提出。通常被區分為軟體開發 生命週期模式與軟體開發程序模式。不過這些模式其實都隱含從開始到結束的 時間序列，Madhavji(1991)便統稱為生命週期模式(Life-Cycle Model)。

軟體開發生命週期模式包括瀑布模式、雛型模式、漸進模式、螺旋模式、

演化雛型模式、同步模式等。其中瀑布模式(Waterfall Model)由 Royce 在 1970 年提出，是一個發展最成熟且仍被廣泛使用的模式，使軟體的開發能有一定程 序可依循，其開發階段正可配合文件產出與品質檢驗。瀑布模式可視為軟體開 發的基本模式，因為其他更複雜模式也包含瀑布模式中各階段內容與作法(林信 惠等，2005)。軟體開發從考量系統需求開始，然後是軟體需求的評估，接著規 劃執行方案且分析其可行性後才開始程式設計、編碼、測試活動，最後移交產

品給客戶，如圖 6。

圖6 瀑布式軟體開發生命週期模式

Note. From ”Managing the development of large software systems: Concepts and techniques,” by W. W. Royce, 1970 WESCON Technical Papers, 14, p.3.

這是一個在受限制的各個階段與連續步驟之間的反覆互動。因此在使用瀑 布模式進行軟體開發時，需完成一個階段後才能到下一個階段，若發現問題則 重回上一層依序執行。當一個階段結束時，同時也是下一個階段的開始，而且 每一個階段開始，都必須有審查(Review)流程，以確認前一階段已結束，下一階 段可開始(鄧志成，2007)。每一個階段都有其應進行的事項與文件產出，讓專案 相關人員對整個專案發展有共識，並了解專案執行的步驟及重要的里程碑。

由於瀑布模式強調軟體開發過程需包含規劃、分析、設計、測試、審查、

文件之管理，能有效確保產品品質。但缺點是該模式僅適用需求明確的專案，

也無法處理需求改變造成程序上變動(鄧志成，2007)，因此本研究將再結合能力 成熟度整合模式中的需求管理概念，彌補瀑布模式之不足。

其他的軟體開發生命週期模式，如雛型模式、漸進模式、螺旋模式、演化 雛型模式、同步模式等，因本研究對象之軟體開發專案沒有應用這些模式，在 此予以忽略。

四 四 四

四、 、 、 影響 、 影響 影響 影響軟體專案成功 軟體專案成功 軟體專案成功因素 軟體專案成功 因素 因素 因素

探討專案管理生命週期模式及軟體開發生命週期模式時，可發現各階段均 有應執行的工作與需達成的任務，這也表示執行並完成一件軟體專案，將受到 諸多預期的與預期之外的影響因素，而導致軟體專案的成功與否。在此探討有 哪些是影響軟體專案的成功因素。

隨著軟體開發環境日趨複雜，進行軟體專案管理所涉及的範圍也更加廣 泛，影響軟體專案成功的因素，除了傳統的鐵三角：成本、時間與品質(Atkinson, 1999)，還包括人員、更改與風險等(林信惠等，2002)。Boehm(1991)與 Phan, et al.(1995)則認為軟體專案失敗原因多數是在於管理問題而非技術問題，是屬於專 案本身的管理技巧，例如變動管理、人力管理與風險管理等。近幾年管理問題 又提升到組織層面，高階主管的支持與否將會影響整個專案的存續問題(李慧 菁，2005；Addison & Vallabh, 2002)。SEI 網站(www.sei.cmu.edu)也曾提出研究 報告顯示，軟體專案及流程改善的推動是否順利，高層支持度有極大影響力，

且軟體專案成敗也受到成本、時間與品質所影響。

軟體開發專案中，隨時會面臨“變動”的不穩定狀態，包括環境、技術與客 戶需求，鄧志成(2007)認為這導因於兩個不清楚：客戶要什麼不清楚、會做出什 麼不清楚。因此為應付客戶多變的需求，除了仰賴有經驗與能力的專案管理者 穩定客戶要求與規格(Addison & Vallabh, 2002)，研發能力也受到關注，建立一

個充足可再用的模組(Jones, 1996)或是提供可擴充的組件，增加軟體功能的變動 彈性，需要研發人員卓越的開發與整合的技術能力。

DeMarco and Lister(2003)提出軟體專案在開發期間普遍會出現時程預估錯 誤、需求無限膨漲、規格崩潰、人力流失與生產力低。所以專案管理者能力又 再度受到重視，Tarawneh, et al.(2008)整合過去幾篇文獻建立了一個成功軟體專 案研究模式，他們驗證出幾項重要影響因素：專案管理者能力、確認客戶需求 與高層的支持與否等等。

因此本研究彙整以上探討影響軟體專案成功因素相關文獻，分析出重要影 響因素包括成本、時間、品質、確認客戶需求、專案管理者能力、研發能力與 高層支持度共 7 項因素，如表 1。

表 1 軟體專案成功的影響因素彙整表 軟體專案成功的影響因素彙整表

影響因素

學者 年份

成 本

時 間

品 質

確 認 客 戶 需 求

專 案 管 理 者 能 力

研 發 能 力

高 層 支 持 度

Boehm 1991 V V V V

Phan, et al. 1995 V V V

Jones 1996 V V V V

Atkinson 1999 V V V

林信惠等 2002 V V V V

Addison and Vallabh 2002 V V V V V V

DeMarco and Lister 2004 V V V

李慧菁 2005 V V V V V

SEI 2006 V V V V

Tarawneh, et al. 2008 V V V

第二節 第二節 第二節

第二節 能力成熟度整合模式 能力成熟度整合模式 能力成熟度整合模式 能力成熟度整合模式

Ellmer and Merkl(1996)研究發現，軟體產品的品質需仰賴高品質的軟體過 程，所以在軟體工程領域的研究多著重在軟體過程評估與改善，其中以能力成 熟度整合模式(Capability Maturity Model^® Integration, CMMI^®)是近幾年備受重 視的軟體流程改善方法。

SEI(2006)認為流程管理是一個產品或系統的品質，會強烈受到發展與維護 其流程品質影響，據以此定義出能力成熟度模式(Capability Maturity Model, CMM)的流程規範，這套流程改善方法並非憑空創造，而是應用了之前軟體專 案管理相關原理，再結合持續流程改善的精神。

SEI 自 2000 年整合原先 CMM 的軟體工程(Software Engineering, SW)、系 統工程(System Engineering, SE)、整合式產品與流程發展(Integrated Product and Process Development, IPPD)等領域，發表了 CMMI 1.0 版，2002 年又加入委外作 業管理(Outsourcing)成為 1.1 版，自此全球導入 CMMI 的家數呈倍數成長，且根 據 SEI 網站(www.sei.cmu.edu)在 2007 年公佈 35 家實施 CMMI 後，在成本、時 程、品質、生產力、客戶滿意度與投資報酬率平均都能提升 50%左右，證實此 模式的確有助於流程改善。

對組織而言，能擁有提升生產力、品質與更精確地預估時程與預算的經驗 (Gibson, Goldenson & Kost, 2006)，因而被視為軟體品質保證與國際合作的基本 要求。故 CMMI 發展歷程可用圖 7 表示：

圖7 CMMI 發展歷程圖

自從 SEI 在 2000 年發表 CMMI 1.0 版以來，此流程規範仍不斷地整合與改 進中，目前推廣的 1.2 版為 2006 年 8 月所發表，利用群集(constellations)的概念，

以一組核心組件的集合建立共通的模型、訓練教材與相關評鑑文件，不僅能應 用在特定模式，將來還可延展到新領域。這裡所提到的特定模式包括 2006 年發 佈的 CMMI-DEV 發展模式(CMMI-Development)、2007 年發佈的 CMMI-ACQ 採 購 模 式 (CMMI-Acquisition) 、 2009 年 發 佈 的 CMMI-SEV 服 務 模 式 (CMMI-Service)。此版本意在同步提升供需雙方的發展、採購與服務流程領域 的管理能力，達到雙贏成效。

當然 CMMI 制度本身也秉持流程改善的目標而持續改善中，2009 年已在 規劃 1.3 版本，預計 2010 年推出。

CMMI 模式規範流程改善中應被包含的流程領域(Process Area)，與每一項 流程領域應達成的一般目標(Goal)、一般執行方法(Practice)與特定目標、特定執 行方法，但是 CMMI 模式卻沒有限制組織為了要導入 CMMI 時，應該建立及實 施什麼樣的制度，也就是說組織可以自行採用適合的方法、文件與制度，以達 到 CMMI 所制定的目標(SEI, 2006)。

2000年 CMMI 1.0版

系統

2002年 CMMI 1.1版

委外 作業

2006年 CMMI 1.2版

發展 模式

CMM

2007年 CMMI 1.2版

服務 模式

採購 模式

2009年 CMMI 1.2版

軟體 流程

持續 改善

整合式 產品

一 一 一

一、 、 、 模式 、 模式 模式 模式表述 表述 表述種類 表述 種類 種類 種類

為達成能力成熟度等級，在導入 CMMI 時，組織應視其經營型態與目的，

選 擇 適 合 CMMI 模 式 表 述 。 表 述 方 式 分 為 兩 種 ： 階 層 式 表 述 (Staged Representation)與連續式表述(Continuous Representation)。

(一 一 一 一) 階 階 階 階層 層 層式表述 層 式表述 式表述 式表述

提供系統化與結構化的方式，一次達成一個階段的流程改善(Chrissis, Konrad & Shrum, 2006)，如圖 8。

圖8 階層式表述

Note. From ”CMMI^®: Guidelines for process integration and product improvement,”

by M. B. Chrissis, M. Konrad & S. Shrum, 2006, p.45.

每一個流程領域都會有一組一般目標與特定目標，且各自又有相對應的一 般執行方法與特定執行方法。而階層式表述在於它一個階段就使用多組流程領 域，以定義組織流程改善的途徑。因此階層式表述是根據成熟度等級(Maturity

特定 執行方法

一般 執行方法

成熟度等級 特定

目標

一般

目標

流程領域

Levels)來執行流程改善順序。

成熟度等級在組織的流程改善，是一個已定義的演進標準，有五個成熟度 等級，如圖 9。

圖9 成熟度等級

Note. From ”Introduction to CMMI^® Version 1.2,” by SEI, 2006, p.7.

成熟度等級分別為等級 1：初始級、等級 2：管理級、等級 3：調適級、等 級 4：量化管理級與等級 5：最佳化級，每一個等級都有應該執行的流程領域，

而且達成一個成熟度等級時，將可確保有足夠的流程基礎建設，以做為下一個 等級之流程改善的基礎。

(二 二 二 二) 連續式表述 連續式表述 連續式表述 連續式表述

提供最大彈性來進行流程改善，完成每一個流程領域中的一般目標與一般 執行方法，以達成能力等級(Chrissis et al., 2006)，如圖 10。

初始級初始級初始級

ML1

管理級管理級 管理級管理級

ML2

調適 調適 調適 調適級級級級

ML3 ML4

ML5 O

量化管理 量化管理量化管理 量化管理級級級級

最佳化最佳化 最佳化最佳化級級級級

圖10 連續式表述

Note. From ”CMMI^®: Guidelines for process integration and product improvement,”

by M. B. Chrissis, M. Konrad & S. Shrum, 2006, p.45.

連續式表述所應用之流程領域與階層式表述相同，都有一般及特定目標，

與相對應執行方法。唯連續式表述對於流程改善達成方式，是在個別流程領域。

能力等級(Capability Levels)對流程領域屬遞增性改善方式，分為 6 個等級，

如圖 11。

5 最佳化級 4 量化管理級 3 調適級 2 管理級 1 執行級 0 不完整級 圖11 能力等級

Note. From ”Introduction to CMMI^® Version 1.2,” by SEI, 2006, p.8.

流程領域

特定 執行方法

一般 執行方法 特定

目標

一般 目標

能力等級

能力等級分別為等級 0：不完整級、等級 1：執行級、等級 2：管理級、等 級 3：調適級、等級 4：量化管理級與等級 5：最佳化級，因此組織可以選擇單 一流程領域針對問題點做績效改善，或利用多項流程領域並配合組織目標進 行。雖然組織可自行選擇將不同的流程領域改善至不同的能力等級，但是在流 程領域的選擇上仍會受到部分流程領域是彼此相依所限制，故通常分為工程、

專案管理、支援、流程管理等四大構面實施。

(三 三 三 三) 連續式 連續式 連續式 連續式表述 表述 表述與 表述 與 與階層式表述 與 階層式表述 階層式表述 階層式表述

2006 年發佈的 CMMI-DEV 發展模式，是以發展者的角度、思考方向所規 範的流程模式，旨在協助組織改善產品與服務之發展與維護流程。與前版最大 差異在於此版本將階段式與連續式表述合而為一，可以一體呈現，使組織不需 在導入初期得先評選該使用何種表述式，但兩種表述式之特色、運用方式仍舊 存在。以下將連續式與階層式表述的特色與優勢做一比較，組織可依需求選擇 合適的表述式，如表 2。

表 2 連續式與階層式表述比較表 連續式與階層式表述比較表

連續式表述 連續式表述 連續式表述

連續式表述 階層式表述階層式表述 階層式表述階層式表述 組織依據其流程改善目標，選擇流

程領域與能力等級

組織依據其成熟度等級，選擇流程 領域

使用能力等級度量：

度量跨組織的特定流程領域 能力度

等級從 0 至 5

使用成熟度等級度量：

度量跨組織的一組流程領域 成熟度

等級從 1 至 5 以能力等級的摘要當作目標與追

蹤流程改善績效

以成熟度等級當作目標與追蹤流 程改善績效

特色

以對等的階段式允許組織使用連 續式表述進行流程改善及引用成 熟度等級來做為評鑑的一部分

不需要一個對等的機制來推衍至 連續式表述

表 2(續)

連續式表述 連續式表述 連續式表述

連續式表述 階層式表述階層式表述 階層式表述階層式表述 授予明確的自由度來選擇最符合

組織經營目標與減少組織風險範 圍的改善順序

使組織有一個已定義且被證實的 改善路徑

增加每一個流程領域能力度與透 視度

專注在一組流程領域，此組流程領 域為每一成熟度等級的特徵，提供 組織特定的能力

允許對不同流程執行不同等級的 改善

以 簡 單 的 型 式 彙 總 流 程 改 善 結 果：單一成熟度等級數目

優勢

一種新方法仍未有數據證明其與 投資報酬率有關連

建 立 在 一 個 相 對 長 期 的 使 用 歷 史，包含個案研究與數據以證明投 資報酬率

資料來源：「CMMI-DEV v1.2 正式中文版」，財團法人資訊工業策進會資訊系統 實驗室，2007，頁 11、頁 47。

二 二 二

二、 、 、 流程領域 、 流程領域 流程領域 流程領域

流程領域係每一個領域中相關目標與執行方法的集合，當這些方法被共同 執行且滿足其目標時，則視為該領域有被改善。故各個流程領域之間常有互動，

且彼此互相影響(Chrissis et al., 2006)。

CMMI 共有 22 個流程領域，分別為：原因分析及解決方案、建構管理、

決策分析與解決方案、整合專案管理+IPPD、度量與分析、組織創新與發展、組 織流程定義+IPPD、組織流程專注、組織流程績效、組織訓練、產品整合、專案 監控、專案規劃、流程與產品品質保證、量化專案管理、需求發展、需求管理、

風險管理、供應商協議管理、技術解決方案、確認與驗證。此 22 個流程領域亦 可分為四大類：專案管理類、流程管理類、支援類與工程類，而圖 12 將流程領 域依四大類別與成熟度等級分別顯示之。

成熟度等級 成熟度等級 成熟度等級 成熟度等級

工程類 工程類 工程類

工程類 支援類支援類支援類支援類

專案管理類 專案管理類 專案管理類

專案管理類 流程管理類流程管理類流程管理類流程管理類

圖12 CMMI 流程領域

Note. From ”Introduction to CMMI^® Version 1.2,” by SEI, 2006, p.9-11.

以下依據 CMMI 流程領域的四大類別，分別說明 SEI(2006)所定義之每一 個流程領域的目的：

組織流 程專注

組織流 程績效

組織創新 與發展

組織 訓練

組織流 程定義 專案

規劃

專案 監控

供應商協 議管理

整合專 案管理

風險 管理

量化專 案管理

建構 管理

流程與產品 品質保證

度量與 分析

原因分析 與 解決方案

決策分析 與 解決方案

第二級 第二級 第二級

第二級 第三級第三級第三級第三級 第四級第四級第四級第四級 第五級第五級第五級第五級

需求 管理

需求 發展

技術解 決方案

產品 整合

驗證 確認

(一 一 一 一) 專案管理類 專案管理類 專案管理類 專案管理類

專案管理類流程領域在解決有關建立及維護專案計畫、建立及維護承諾、

依計畫監督進展、採取改善活動與管理供應商協議，包括專案規劃、監督與控 制有關的專案管理活動。也就是說基本專案管理類流程領域提供專案規劃、監 督與控制的能力，而進階專案管理類流程領域則決定這些能力。專案管理類流 程領域涵蓋專案規劃、專案監控、供應商協議管理、整合專案管理+IPPD、風險 管理與量化專案管理，目的如下：

5.專案規劃(Project Plan, PP)：發展專案計畫、適時納入關鍵人員參與，以及取 得對計畫的承諾並維護計畫。

6.專案監控(Project Monitoring and Control, PMC)：監督和採取矯正行動。

7.供應商協議管理(Supplier Agreement Management, SAM)：監督、審查與管理供 應商所提供的產品或組件。

8.整合專案管理+IPPD(Integrated Project Management +IPPD, IPM+IPPD)：建立及 維護由組織標準流程所調適的專案執行流程。所附加的 IPPD 部分則是建立及 維護專案共同願景與整合專案團隊結構。

9.風險管理(Risk Management, RSKM)：採取持續性與前瞻性的管理風險方法，

包括界定風險參數、評量與降低風險。

10. 量化專案管理(Quantitative Project Management, QPM)：使用量化及統計方 法，以管理流程績效與產品品質。

(二 二 二 二) 流程管理類 流程管理類 流程管理類 流程管理類

流程管理類提供組織能力，以記錄分享最佳執行方法、組織流程資產與跨 組織的學習，進而達成品質與流程績效的量化目標。流程管理類流程領域包括 組織流程專注、組織流程定義+IPPD、組織訓練、組織流程績效以及組織創新與 發展，目的如下：

1.組織流程專注(Organizational Process Focus, OPF)：協助組織規劃、實行及推展

組織流程改善。

2.組織流程定義+IPPD(Organizational Process Definition +IPPD, OPD+IPPD)：建 立與維護一套可以使用的組織流程資產與工作環境標準。所附加的 IPPD 部分 則針對專案的 IPPD 規則與指引。

3.組織訓練(Organizational Training, OT)：發展人員的技能與知識，使其有效執 行他們的任務。

4.組織流程績效(Organizational Process Performance, OPP)：建立並維護量化模 式，以藉此瞭解組織用於支援品質與流程績效目標之標準流程的績效，也提供 流程績效資料、基準及模式，以利使用量化方式管理組織專案。

5.組織創新與發展(Organization Innovation and Deployment, OID)：選擇並發展具 漸進與創新效果的各種改善措施。

(三 三 三 三) 支援類 支援類 支援類 支援類

支援類流程領域包括支援產品發展與維護的活動，所解決的對象通常以專 案為主，對於組織層面則以一般通用方式解決。支援類流程領域包含了建構管 理、流程與產品品質保證、度量與分析、決策分析與解決方案、原因分析與解 決方案，目的如下：

1.建構管理(Configuration Management, CM)：建立與維護工作產品的完整性，並 支援全部的流程領域。

2.流程與產品品質保證(Process and Product Quality Assurance, PPQA)：給予專案 成員與管理階層能客觀審查流程及工作產品。提供特定執行方法，如流程說 明、標準與程序，客觀評估所執行流程、服務與工作產品，確保審查時所發現 之問題缺失都有被解決。此支援全部的流程領域，以提供所有流程領域的作業 流程與工作產品客觀評估，故此流程領域可支援高品質產品與服務的交付。

3.度量與分析(Measurement and Analysis, MA)：發展與維持度量之能力，以支援 管理資訊需求。提供特定執行方法，如指定度量與分析目標、使用技術、資料

蒐集儲存，以及報告與回饋機制，並採取妥適的矯正措施，亦用於支援全部的 流程領域。

4.決策分析與解決方案(Decision Analysis and Resolution, DAR)：利用正式的評估 流程，依照已建立的準則評估各種經界定後的備選方案，以分析可行決策。

5.原因分析與解決方案(Causal Analysis and Resolution, CAR)：界定造成缺失和其 他問題的原因並採取行動，以避免未來再度發生。

(四 四 四 四) 工程類 工程類 工程類 工程類

工程類流程領域描述軟體開發與客戶需求之間的互動，因此在探討軟體開 發專案之流程時，先從工程類流程領域分析較容易入手。

此流程領域涵蓋了需求管理、需求發展、技術解決方案、產品整合、驗證 與確認，目的如下：

1.需求管理(Requirements Management, REQM)：管理專案產品與產品組件的需 求，並界定此需求與專案計畫、工作產品之間的差異。

2.需求發展(Requirements Development, RD)：產出並分析客戶、產品與產品組件 的需求。

3.技術解決方案(Technical Solution, TS)：設計、發展與實作需求的解決方案。

4.產品整合(Product Integration, PI)：將產品組件組合成產品，並確保已經整合的 產品能適當地運作及交付產品。

5.驗證(Verification, VER)：確保選定之工作產品能符合其指定的需求。

6.確認(Validation, VAL)：展示裝置於預期環境中的產品或產品組件，並可滿足 其預期的使用需求。

工程類流程領域圖顯示了從開發到交付產品給客戶的流程，並指出其流程 領域之間的時間先後關聯，如圖 13。

圖13 工程類流程領域圖

Note. From ”CMMI^®: Guidelines for process integration and product improvement,”

by M. B. Chrissis, M. Konrad & S. Shrum, 2006, p.82.

由此可知，一開始客戶提出需求即進行需求發展，分析並提出對產品與產 品組件的需求規格文件，再尋求可行的技術解決方案且驗證能符合需求，進而 將產品整合與確認是否滿足需求，然後將產品組件、工作產品、驗證和確認的 報告與需求發展所提出的規格文件進行比對，之後交付產品給客戶，而整個流 程中的客戶需求則藉由需求管理來控管。

財團法人資訊工業策進會(2002)在 CMMI 導入指引中，引用 Sverdrup Advanced System Group 公司的整合性工程生命週期，其劃分為專案規劃、需求 分析、設計、元件製作與測試、整合與測試、建置與驗收測試、運作與維護階 段，並以此說明了整合性工程生命週期與工程類流程領域關係如下：

1.需求管理涵蓋生命週期所有階段。

2.需求發展涵蓋需求分析階段。

3.技術解決方案涵蓋設計、元件製作與測試的兩個階段。

4.產品整合涵蓋整合與測試、建置與驗收測試兩個階段。

5.驗證涵蓋生命週期所有階段，但採用的方法不盡相同。

6.確認涵蓋生命週期所有階段，但採用的方法不盡相同。

7.驗證與確認很相似，驗證展示產品與需求相符，而確認展示產品在預期操作環 境中能符合使用需求。

因此從專案一開始就進行的需求發展時期，可界定為專案初始階段；專案 規劃階段則是在尋求可行的技術解決方案與驗證時期；產品整合並置於預期環 境下的確認，可界定為軟體工程與專案監控階段；專案結束階段即為交付產品 給客戶時期。

故本研究結合專案管理、瀑布式軟體開發生命週期模式與 CMMI 工程類流 程領域，認為軟體開發專案之流程架構如圖 14 所示。

圖14 瀑布式軟體開發生命週期與工程類流程領域關聯圖

也就是說，專案初始階段包括瀑布式軟體開發生命週期中的系統需求與軟 體需求，而 CMMI 流程領域則涵蓋需求發展與需求管理；專案規劃階段包括分 析，即技術解決方案與驗證之流程領域；軟體工程與專案監控階段包括程式設 計、編碼與測試，亦囊括產品整合與確認之流程領域；專案結束階段則為移交，

將產品交付客戶。比較特別的是需求管理、驗證與確認之流程領域，雖然整個 生命週期都與其相關，但從工程類流程領域圖(圖 13)來看，仍有其主要活動的 先後順序差異。

最後再將 CMMI 其餘的流程領域依其相關性，分別納入軟體開發專案的四 大階段中，其中涵蓋整個生命週期階段的流程領域，則以其主要或最初活動階 段為區隔，所以軟體生命週期中各階段所涵蓋的 CMMI 流程領域如下：

1.專案初始階段包括需求管理、需求發展與建構管理。

2.專案規劃階段包括專案規劃、技術解決方案、驗證、供應商管理與整合專案管 理。

3.軟體工程與專案監控階段包括專案監控、產品整合、確認、流程與產品品質保 證、風險管理、決策分析與解決方案以及原因分析與解決方案。

4.專案結束階段包括量化專案管理、度量與分析。

5.另外，從組織層面來看軟體生命週期，則為組織流程專注、組織流程定義、組 織訓練、組織流程績效以及組織創新與推展。

三 三 三

三、 、 、 一般目標 、 一般目標 一般目標 一般目標與執行方法 與執行方法 與執行方法 與執行方法

一般目標(Generic Goals, GG)是執行 CMMI 流程之必要組件，用於評鑑時 決定某流程領域是否達成或滿足的憑據。CMMI 也定義了達成一般目標的方 法，稱做一般執行方法(Generic Practices, GP)。

之所以被稱為“一般”，泛指這些目標可以被應用至全部的流程領域中，每 一組一般目標會有一般執行方法以達成目標，所以另外還有特定目標與特定執 行方法。由於“特定”係指應用至某一特定的流程領域，不同的流程領域，其特

定目標與對應之特定執行方法均不同，但最後也仍需符合一般目標與一般執行 方法，故在此忽略不提特定目標與特定執行方法。

一般目標也有類似成熟度等級的分級，可分為 1 至 5 等級，每個等級均有 不同的一般目標，但在階層式表述下，只需使用一般目標 2 跟 3 等級，這並不 表示等級 4 至 5 的一般目標即不被採用，而是因為不需要將所有流程領域都要 提升其目標等級，且等級 2 跟等級 3 的一般目標是評鑑時必要達成的基礎，即 使進行成熟度等級第三級之評鑑，仍需達成等級 2 與等級 3 的目標等級。各個 等級之一般目標與一般執行方法，如表 3 所示。

表 3 一般目標與一般執行方法表 一般目標與一般執行方法表

目標等級目標等級

目標等級目標等級 一般目標一般目標一般目標一般目標 一般執行方法一般執行方法一般執行方法一般執行方法 等級 1 GG1 達成特定目標 GP1.1 實施特定執行方法

GP2.1 建立組織政策 GP2.2 規劃流程 GP2.3 提供資源 GP2.4 指派責任 GP2.5 訓練人員 GP2.6 管理建構

GP2.7 界定並納入相關關鍵人員 GP2.8 監控流程

GP2.9 客觀評估遵循程度 等級 2 GG2 制度化已管理流程

GP2.10 與高層管理人員審查各狀況 GP3.1 建立已調適流程

等級 3 GG3 制度化已調適流程

GP3.2 蒐集改善資訊

GP4.1 建立流程的量化目標 等級 4 GG4 制度化已量化管理流程

GP4.2 穩定子流程績效 GP5.1 確保持續的流程改善 等級 5 GG5 制度化最佳化流程

GP5.2 矯正問題的根本原因 Note. From ”Introduction to CMMI^® Version 1.2,” by SEI, 2006, p.76.

第三節 第三節 第三節

第三節 小結 小結 小結 小結

綜合上述文獻之觀點，本研究歸納出以下幾點看法：

1.軟體專案管理影響層面很廣泛，影響其成功的因素很多，但經過彙總比較之 下，影響軟體專案成功因素不失為成本、時間、品質、確認客戶需求、專案管 理者能力、研發能力與高層支持度等等。

2.瀑布式軟體開發生命週期模式強調各個階段都有其應進行的事項與文件產 出，且需經過審查後才能進入下一個階段，容易建立與執行專案步驟及監控里 程碑，是常被使用的軟體開發模式。但缺點是該模式僅適用需求明確的專案，

也無法處理需求改變造成程序上變動，因此本研究將再結合能力成熟度整合模 式中的需求管理概念，彌補瀑布模式之不足。

3.同時也利用能力成熟度整合模式，釐清軟體開發生命週期模式中各流程領域與 角色後，再結合專案管理生命週期模式，可將軟體專案的進行再整併為專案初 始階段、專案規劃階段、軟體工程與專案監控階段、專案結束階段，藉以簡化 模型建構的複雜度。

4.最後依每一階段核心活動再區分出相對應的 CMMI 流程領域，如表 4。

表 4 專案管理生命週期與 CMMI 流程領域對應表 專案管理生命週期與CMMI流程領域對應表

層面層面

層面層面 專案管理專案管理專案管理專案管理生命週期階段生命週期階段生命週期階段生命週期階段 主要對應主要對應 CMMI 流程領域主要對應主要對應 流程領域流程領域 流程領域 專案初始階段 REQM、RD

專案規劃階段 PP、TS、VER、SAM、IPM 軟體工程與專案監控階段 PMC、PI、VAL、PPQA、RSKM、

DAR、CAR 專案層面

專案結束階段 QPM、MA、CM

組織層面 涵蓋各階段 OPF、OPD、OT、OPP、OID

第三章 第三章

第三章 第三章 研究方法 研究方法 研究方法 研究方法

本章節闡述本研究所採用個案研究與系統動態學之理論與方法。個案研究 是一種實證研究方法，系統動態學是一套嚴謹地建立系統模型之方法。首先是 定義問題概念，分析研究對象實際執行之軟體專案，以界定問題範圍並找出因 素之間的兩兩關聯，然後利用真實案例的流程建構出系統動態模型，並以個案 研究法推論至該個案公司所屬產業。

第一節 第一節

第一節 第一節 個案研究 個案研究 個案研究 個案研究

本研究以系統動態觀點，探討某家資訊軟體開發公司是如何進行軟體開發 專案，並分析其因果關聯。為探究該個案公司研究結果是否能推論至所屬產業，

需先窺探個案研究法之理論。

Yin(2008)將個案研究定位成一種研究策略，其主要目的在於檢測、推展與 修正現有理論，係追求理論效度(analytical validity)，而非統計意義上的外部效 度(statistical validity)。故個案研究法是一種實證研究，專注於真實背景下當時現 象的探討，進行分析式概化(analytic generalization)，將結果擴展並推論到理論的 命題，不似統計式概化(statistical generalization)是算出其頻率並推論到母體(Yin, 2008)，Lipset, Trow and Coleman(1956)也表明單一個案研究的目的是要做概括性 (generalizing)，而非特殊性(particularizing)的分析。因此本研究結果不單單屬於 該個案公司，還是能應用於資訊軟體產業的概括性分析。

本研究探討以「人」為組成要素的軟體開發專案，為了找出執行軟體開發 專案時，無法用科學觀察探究的因果關聯性，以敘述方式說明個案公司執行軟 體專案的流程。由於這已經具有揭露性，值得進行單一個案研究(Yin, 2008)。

總之，個案研究是案例導向的過程，對個案進行分析與邏輯的複製屬於獨 一無二的歸納，由此產生的理論往往是新穎、可被檢驗並實證有效的(Eisenhardt, 1989)。

第二節 第二節 第二節

第二節 系統動態學 系統動態學 系統動態學 系統動態學

許多企業管理的理論是根據過去所發生的問題，找出最適解決方案，不過 隨著時間流逝，同樣運作方式不見得能讓企業經營有所突破，因為這只能處理 細節性複雜，無法處理動態性複雜(Senge, 1990)。

由於企業系統的結構具有高度複雜性、動態性與回饋性(謝長宏，1987)，

在 1956 年，美國麻省理工史隆管理學院(MIT Sloan School of Management)的 Jay W. Forrester 教授結合決策理論、系統理論、控制論、伺服機械學、資訊理論與 電腦模擬，發展出系統動態學(System Dynamics, SD)，用於解決企業經營管理的 問題，Sterman(2000)則用來分析美國國家與城市的社經問題。

系統動態學在協助人們以宏觀角度俯瞰系統全貌，釐清各因素間的動態相 互關係，以找出問題關鍵所在(韓釗，2002)。它包含時間滯延(time delay)的過程，

是一種過程導向的研究方法，也是一種全面性研究人類動態複雜系統的方法 (Senge, 1990)。這種以研究系統中的因果回饋關係，觀察組織運作所產生的問 題，可以幫助組織學習與思考動態性複雜問題的工具，其所建立的系統動態模 型讓管理者能了解問題背後的動態系統運作情形，藉此找出問題解決之道。因 此建構一個系統動態模型，其涵蓋範圍的大小需視系統分析時所關注的問題及 目的而定(韓釗，2002)，它是描述和分析複雜系統的組織與範圍、系統內流程和 訊息關係與策略對系統的影響的一種嚴謹研究方法(楊朝仲、張良正、葉欣誠、

陳昶憲與葉昭憲，2007)。

時至今日，系統動態學應用在各種領域，如研發、專案、健康照護與交付 的動態模型等(Roberts, 2007)，專案管理則是應用最成功的領域之一(Lyneis &

Ford, 2007)，這是因為系統動態學可以提供寶貴的策略課題給專案管理，亦能補 充傳統技術提供營運支援的細節(Rodrigues & Bowers, 1996)。

此外，系統思考中最重要考量因素是因果之間的時空關聯，加上立竿見影 的因果效應在動態性複雜系統中並不多見，反倒是因果之間的時間滯延常會迷

惑決策者的方向(韓釗，2002)。楊仁壽(2000)就提到動態性複雜系統中的回饋資 訊，不見得能即時顯現系統的真實狀態，將使專案管理者解讀錯誤，進而產生 錯誤決策。這就是杜強國(2004)所定義的動態性陷阱(dynamic pitfalls)，雖然一 開始可以啟動企業的成功，但隨著目標衝突的形成並加重產生負面影響，進而 負面影響組織整體績效。

因此決策者不能一昧依賴過去有效的經驗法則，當原因與影響結果的關聯 性不明確時，若無法及時察覺並加以解決，可能導致陷入動態性問題的困境中。

但藉由 Lyneis and Ford(2007)所提出四種模擬專案動態的架構，其中專案特徵 (project features)模型，利用系統動態學專注於從真實系統塑造模型的特徵，用 真實專案的主要構成要素來建模，以加強模擬真實專案動態的能力，並可與專 案管理者的經驗做連結，增加其決策的準確度。

故本研究方法應用系統動態學，來探討軟體專案管理中的開發流程，其特 色依研究者發表年份排序，整理如表 5。

表 5 應用系統動態學之比較表 應用系統動態學之比較表

研究者 研究者 研究者

研究者 年份年份年份年份 特色特色特色特色 未解決環節未解決環節 未解決環節未解決環節 Forrester 1956 用於解決企業經營管理的

問題

--

謝長宏 1987 企業系統的結構具高度複

雜性、動態性與回饋性，同 系統動態學特性

--

Senge 1990 含時間滯延過程，一種過程 導向、全面性研究人類動態 複雜系統方法

--

Rodrigues and Bowers

1996 提供寶貴的策略課題給專 案管理，亦能補充傳統技術 提供營運支援的細節

--

Sterman 2000 用來分析美國國家與城市 的社經問題

--

表 5(續) 研究者研究者

研究者研究者 年份年份年份年份 特色特色特色特色 未解決環節未解決環節 未解決環節未解決環節

楊仁壽 2000 -- 動態性複雜系統中的回饋

資訊，不見得能即時顯現系 統的真實狀態，將使專案管 理者解讀錯誤，進而產生錯 誤決策

韓釗 2002 協 助 人們 以宏 觀角 度俯瞰 系統全貌，釐清各因素間的 動態相互關係，以找出問題 關鍵所在。且建構模型時，

其涵蓋範圍的大小需視所 關注的問題及目的而定

因果之間的時間滯延常會 迷惑決策者的方向

杜強國 2004 -- 一開始啟動企業的成功，但

隨著目標衝突加重產生負 面影響，進而負面影響組織 整體績效

楊朝仲等 2007 描 述 和分 析複 雜系 統的組 織與範圍、系統內流程和訊 息關係與策略對系統的影 響的一種嚴謹研究方法

--

Roberts 2007 系 統 動態 學應 用在 各種領 域，如研發、專案、健康照 護與交付的動態模型等

--

Lyneis and Ford

2007 專 案 管理 是應 用最 成功的 領域之一，利用真實專案來 建模，可與專案管理者經驗 做連結，增加決策準確度

--

總結以上系統動態學之優劣勢觀點，本研究方法採用系統動態學是可行 的，唯需利用真實專案的構成要素來建模，才能避免陷入動態性陷阱中。除此 之外，本研究也依研究者發表年份排序，整理出系統動態學在軟體專案管理相 關議題之文獻，如表 6。

表 6 應用系統動態學在軟體專案管理之文獻彙整表 應用系統動態學在軟體專案管理之文獻彙整表

研究 研究 研究

研究者者者者 年份年份年份年份 研究題目研究題目研究題目研究題目 研究研究成果研究研究成果成果 成果 Abdel-Hamid 1989 動 態 的 軟 體 專 案 人 員 配

置：一個基於系統動態學模 擬方法

利用單一軟體專案的系統 動態模式以協助克服軟體 危機

Rodrigues and Williams

1997 系 統 動 態 學 下 軟 體 專 案 理：關於正式整合框架的發 展

將系統動態學應用在軟體 管理，提出一個 PMIM 概念 模型的綜合管理框架，並討 論其基本原則

Ford and Sterman

1998 產品開發流程之動態模型 探討多階段專案動態模型

中，程序、資源、範圍與目 標之發展活動

鄧翠玲 2004 以 系 統動 力學 探討 軟體開 發專案之動態規劃特性

以 Brooks’定律系統動態模 式為核心模式，依據軟體專 案管理建立變數因果關係 環路圖，使用情境引導方式 觀察設定情境下的系統動 態行為變化

許玉芬 2005 整 合 式動 態決 策方 法論之 建立－以 R&D 專案管理為 例

藉由 QFD、AHP、平衡計分 卡及系統動態學，建構一套 整合式動態決策方法論，以 預測企業策略規劃設計及 策略專案實施結果的績效 王志欽 2006 以 系 統動 態觀 點探 討應用

資訊系統開發專案績效之 因果關係

結合文獻研究與專家訪談 輔以系統動態學，針對台灣 地區企業應用資訊系統開 發專案績效之因果關係進 行探討

王錦泰 與 管孟忠

2007 以 系 統動 態學 模式 建置專 案管理決策支援系統之分 析

以平衡計分卡、系統動態學 和ARIS流程管理方法，建構 專案管理決策支援系統

由此可知，各學者在探討軟體專案管理，雖結合系統動態學與其他研究方 法或理論，來建構模型並以模擬方式導出結論，但缺乏真實案例的應用，因此