以CMMI-ACQ規劃資訊科技籌獲管理 - 政大學術集成
69
0
0
全文
(2) 以 CMMI-ACQ 規劃資訊科技籌獲管理 研究生：王培得. 指導教授：曾淑峰 博士. 國立政治大學資訊管理學系. 摘要 「流程改善」是任何組織追求卓越、提升競爭力的根本方法，美國卡內基 美隆大學軟體工程學院(CMU-SEI)集結經實作證明，可有效提升軟體品質的 最佳實作方法成為 CMMI，提供開發型組織流程改善的依循準則。繼開發方. 政 治 大 CMMI-ACQ(CMMI for 立Acquisition)因應而生。. CMMI (CMMI for Development) 的 成 功 推 廣 與 有 效 運 用 ， 籌 獲 方 的. ‧ 國. 學. CMMI-ACQ 乃針對籌獲方採購流程改善之 CMMI 模式。在委外環境下， 籌獲方與開發方應共同築成 CMMI-ACQ 與 CMMI-DEV 互動的協同合作關. ‧. 係，使雙方擁有對等、公平、專業的流程溝通基礎，以更有效的方式完成委. sit. y. Nat. 外專案協同工作。最終目標，就是使整體專案能如期、如質、如預算的完成，. al. er. io. 提升資訊服務品質。. v. n. 本論文以 CMMI-ACQ 的籌獲需求發展、籌獲確認及籌獲驗證流程領域為. Ch. engchi. i n U. 參考，規劃資訊科技籌獲管理，以 UML 活動圖表達其互動關係，並以 Zachman 5W1H 方法研析籌獲管理必要的作業程序，進一步分析、說明其使用案例， 以發掘籌獲管理資訊需求，最後以 CMMI 評鑑檢視表，回顧本論文所提 CMMI-ACQ 資訊需求架構所提供之直接證據。透過本文研究的過程，期盼提 供籌獲組織一個簡單的導入參考。 關鍵詞：流程改善、CMMI、籌獲管理。. -I-.
(3) Planning IT Acquisition Management Based on CMMI-ACQ Student：Pei-De Wang. Advisor：Dr. Shu-Feng Tseng. Department of Management Information Systems National Chengchi University. Abstract. 政 治 大 promote competitive advantages for any organizations. CMU-SEI has gathered the 立 Process improvement is the fundamental way to pursue excellence and. so-called best practices that has been experienced and proven to be effective to. ‧ 國. 學. establish the CMMI to provide reference guidelines for process improvement in. ‧. the software development organizations. Following the pervasive adoption of. sit. y. Nat. CMMI-DEV (CMMI for Development) for the developers, CMMI-ACQ (CMMI. io. er. for Acquisition) was developed for the acquirers. CMMI-ACQ focuses on acquisition processes in order to constitute an equal, fair, and professional. al. n. v i n C hcollaboration in anUoutsourcing environment. The common platform for effective engchi. goal is to achieve the project completion on time with expected quality and budget. This research proposes an information requirement planning approach for IT acquisition management based on CMMI-ACQ, using ARD, AVER and AVAL process areas as examples. Using the UML activity diagram and Zachman 5W1H, this research analyzes the operation procedures and elaborates the information requirements in the use case diagrams and the associated descriptions. Finally, a set of CMMI self appraisal tables are used to review the support evidences provided by the proposed information requirements architecture. This research - II -.
(4) provides a reference for any acquisition organization to elicit the information requirements for CMMI-ACQ adoption and its supporting system construction. Keywords：Process Improvement, CMMI, Acquisition Management. 立. 政 治 大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. - III -. i n U. v.
(5) 致謝辭 本論文的完成，首先要感謝的是指導教授曾淑峰博士，在學生有機會奉派 出國研習 CMMI 課程給予意見，並於學生任職單位導入 CMMI-ACQ 之際提 供前瞻性的見解與指導，在論文寫作時，不遺餘力地提供過去理論研究與實 務者的觀念與經驗。還有財團法人資訊工業策進會網路多媒體研究所何所長 寶中及商學院副院長林教授我聰，特別撥冗擔任學生的口試委員，並對本論 文提供專業與實務的見解。 再者要特別感謝土地銀行蘇總經理樂明，在他時任財政部財稅資料中心主. 政 治 大 Institute ,Carnegie Mellon 立University; CMU-SEI ）研習 CMMI 中階課程，才得. 任時，於 94 年特別派我至美國卡內基美隆大學（Software Engineering. ‧ 國. 學. 以將此模式帶回財稅資料中心並著手實作。另外，也要謝謝財稅資料中心前 第四組劉組長緯華在中心導入 CMMI-ACQ 各個階段的參與、協助與包容，. ‧. 還有前財稅資料中心黃主任定方（現任國庫署署長）的支持、勉勵與推動，. sit. y. Nat. 尤其是「要為成功找方法，勿為失敗找籍口」的鼓舞與啟發，才得以讓我有. al. er. io. 較完整的理論與實際的學習機會，也因此 SEI 執行長 Dr. Paul Nielsen 在. v. n. CMMI-ACQ V1.2 中文版序中，特別為財稅資料中心成為全球第一個通過. Ch. engchi. i n U. CMMI-ACQ 正式評鑑的單位給予高度的肯定與評價。 最後，我要感謝我的妻子敏蘭的支持、關心與體諒，以及三個孩子－咨翔、 淯琳與妤庭的加油與打氣，他們的鼓勵是我最大的心靈支柱與撫慰。. - IV -.
(6) 目次 第一章 緒論..................................................................................................................1 1.1 研究背景....................................................................................................1 1.2 研究動機....................................................................................................3 1.3 研究目的....................................................................................................4 1.4 研究範圍....................................................................................................4 1.5 研究程序....................................................................................................4 1.6 研究方法....................................................................................................5 第二章 文獻探討..........................................................................................................8 2.1 資訊科技的籌獲........................................................................................8 2.2 資訊軟體品質與籌獲需求........................................................................9 2.3 CMMI-AM 與CMMI-ACQ....................................................................10 2.4 需求分析..................................................................................................18 2.5 統一化模型語言......................................................................................20 第三章 籌獲管理資訊需求發展................................................................................22 3.1 研究架構..................................................................................................22 3.2 背景說明..................................................................................................23 3.3 目標階層分析（Why）與概念圖..........................................................24 3.4 流程分析（When, Who, Where, How, What）與活動圖......................27. 立. 政 治 大. ‧. ‧ 國. 學. n. al. er. io. sit. y. Nat. 第四章 籌獲管理使用案例分析................................................................................33 4.1 籌獲需求發展案例分析與說明..............................................................33 4.2 籌獲驗證案例分析與說明......................................................................41 4.3 籌獲確認案例分析與說明......................................................................47 第五章 自評支援........................................................................................................53 5.1 SCAMPI評鑑說明...................................................................................53 5.2 SCAMPI評鑑的支援...............................................................................54 5.3 SCAMPI評鑑支援之確認.......................................................................56 第六章 結論與建議....................................................................................................57 6.1 研究結論..................................................................................................57 6.2 研究限制..................................................................................................57 6.3 研究貢獻..................................................................................................58 6.4 未來研究與發展......................................................................................58. Ch. engchi. -V-. i n U. v.
(7) 表目錄 表 1-1：導入績效 ....................................................2 表 2-1：技術籌獲模式及其面向 ........................................8 表 2-2：籌獲模組的流程領域 .........................................11 表 2-3：籌獲需求發展的特定目標與執行方法 ...........................14 表 2-4：籌獲驗證的特定目標與執行方法 ...............................15 表 2-5：籌獲確認的特定目標與執行方法 ...............................15 表 2-6：一般目標 ...................................................16 表 2-7：CMMI-ACQ模式彙整 ...........................................17 表 2-8：各種需求分析方法 ...........................................18 表 2-9：Zachman Framework ..........................................20 表 2-10：UML 圖示法分類及其說明 ....................................21 表 3-1：織織角色與權責 .............................................23 表 3-2：籌獲管理流程支援籌獲專案生命週期示意圖 .....................29 表 4-1：「建立籌獲需求發展計畫」使用案例說明 ........................34 表 4-2：「審查籌獲需求發展計畫」使用案例說明 ........................35 表 4-3：「上傳客戶/契約需求」使用案例說明 ...........................37 表 4-4：「建立客戶/契約需求分析報告」使用案例說明 ...................39 表 4-5：「確認客戶/契約需求」使用案例說明 ...........................40 表 4-6：「審查驗證計畫」使用案例說明 ................................44 表 4-7：「審查驗證環境」使用案例說明 ................................45 表 4-8：「同仁審查」使用案例說明 ....................................46 表 4-9：「分析整體驗證」使用案例說明 ................................47 表 4-10：「審查確認計畫」使用案例說明 ...............................49 表 4-11：「審查確認環境」使用案例說明 ...............................50 表 4-12：「分析確認報告」使用案例說明 ...............................52 表 5-1：籌獲需求發展的直接證據 .....................................55 表 5-2：籌獲驗證的直接證據 .........................................55 表 5-3：籌獲確認的直接證據 .........................................56. 立. 政 治 大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. - VI -. i n U. v.
(8) 圖目錄 圖 1-1：研究流程 ....................................................7 圖 2-1：籌獲流程模式 ................................................9 圖 2-2：甲/乙雙方的匹配 ............................................10 圖 2-3：CMMI應用範圍之三大類別 .....................................13 圖 2-4：模式表述 ...................................................14 圖 3-1：研究架圖 ...................................................22 圖 3-2：組織架構圖 .................................................23 圖 3-3：籌獲需求發展概念圖 .........................................25 圖 3-4：籌獲驗證概念圖 .............................................26 圖 3-5：籌獲確認概念圖 .............................................27 圖 3-6：籌獲者與開發者的互動關係圖 .................................28 圖 3-7：籌獲需求發展活動圖 .........................................30 圖 3-8：籌獲驗證活動圖 .............................................31 圖 3-9：籌獲確認活動圖 .............................................32 圖 4-1：籌獲需求發展使用案例圖 .....................................34 圖 4-2：籌獲驗證使用案例圖 .........................................42 圖 4-3：籌獲確認使用案例圖 .........................................48 圖 5-1：評鑑的種類 .................................................53 圖 5-2：SCAMPI A 流程 ..............................................54. 立. 政 治 大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. - VII -. i n U. v.
(9) 第一章 緒論 1.1 研究背景 據 2008 年 9 月 14 日自由電子報報導，我國資訊科技發展多獲國際間肯 定，依英國經濟學人信息部（Economist Intelligence Unit；EIU）於 9 月公布 2008 年「全球 IT（資訊科技）產業競爭力指數大調查」，台灣去年表現大放 異彩，從 2007 年全球排名第 6，攀升至第 2 名，僅次於美國，超越日、韓，. 政 治 大 第一。在軟體發展方面，根據 立 SEI 報告顯示與提升資訊軟體品質(CMMI)計畫. 位居亞洲第一。台灣在「研發環境」指標分數更是拔得頭籌，拿下全球排名. ‧ 國. 學. 網站之最新消息表示，台灣通過評鑑家數約為 117 家，占全球排名第 7。可 見我國內資訊科技的相關產業日趨成熟，甚至為國際間的先驅者。. ‧. 目前我國正值發展知識型經濟體系，其中資訊軟體產業是重點中的產業，. sit. y. Nat. 也是各個產業的靈魂！能力成熟度整合模式（Capability Maturity Model. al. er. io. Integrated；CMMI）搭配全球性的軟體品質評鑑模式，更是資訊軟體輸出承. v. n. 接國際委外（Outsourcing）訂單的門票。但為建立完善的優質軟體產業環境，. Ch. engchi. i n U. 籌獲方應以身作則，率先推動並導入，並結合甲、乙雙方（籌獲方與開發方） 的實質能力，一起改善軟體產業環境，提升「軟」實力，才可獲得國際間的 認可，進而獲取國際間更多的大型標案，提升台灣軟體產業在全球的競爭力。 CMMI 的著重點是持續的流程改善。人才、技術及作業流程為完成任務之 金三角，而其中以流程最為重要。CMMI 強調唯有良好的流程結合人才及技 術才可發揮最大效果，因為「流程的品質直接影響著產品的品質」 ，而此一流 程改善必需是持續向前的。自 1984 年起，美國國防部開始贊助卡內基美隆大 學（Carnegie Mellon University, CMU）軟體工程學院（Software Engineering Institute, SEI）結合產、官、學各界，發展出 CMMI 這一套組織品質管理制度，. -1-.
(10) 希望經由嚴謹的流程管控，確保所開發軟體產品的品質，一直以來為乙方（開 發者）開發軟體的遵循模式，於 2006 年 8 月改版為 CMMI-DEV V1.2（CMMI for Development Version 1.2） 。依 SEI 於 2006 年統計 35 個導入 CMMI 模式組 織的績效發現（如表 1-1），CMMI 確實可以作為提升軟體品質、減少開發成 本、甚至提前交付產品的實作準則。 表 1-1：CMMI 導入績效 績效指標. 中位數. 成本. 34%. 時程. 50%. 生產力. 61% 治 品質 政 48% 大 使用者滿意度 14% 立 投資報酬率. ‧ 國. 學. 4.0 : 1 資料來源：Gibson 等, 2006. 為加強推動資訊服務業之發展，經濟部在提升資訊軟體品質(CMMI)計畫. ‧. 網站上表示：自 2005 年起將「提升資訊軟體品質(CMMI)計畫」列為資訊服. Nat. sit. y. 務業主軸措施，以宣示政府全力推動資訊軟體品質制度之決心，期望透過 4. n. al. er. io. 年計畫之執行，協助資訊服務業者提升其生產力，增強其承接大型與複雜專. i n U. v. 案之能力；並藉以建立資訊服務業協作平台，以落實垂直分工水平整合之產. Ch. engchi. 業架構；最終目標在於厚植資訊服務業者外銷潛力，將資訊服務業轉型為外 銷導向之知識產業。從環境建立、技術輔導、人才培訓、推廣宣導等分項計 畫的實施，健全國內環境達到強化業者的體質；同時，透過已達一定數量的 CMMI 認證廠商數目發揮群聚效應，建立品質品牌，將使國際買主對台灣資 訊服務業的技術與服務更具信心，打開產業的國際知名度。 目前國內推行 CMMI-DEV 成效頗佳，共計約有 111 個組織通過評鑑，在 「行政院國家資訊通信發展推動小組」積極推動與「經濟部標準檢驗局」協 助建立下，98 年 5 月 7 日已核定公布 CMMI 評鑑要求（Appraisal Requirements for CMMI; ARC）為國家標準(CNS15190)，期能全面提昇軟體產業競爭力（詳. -2-.
(11) 見國家標準檢索系統）。. 1.2 研究動機 長久以來，國內外資訊委外專案多面臨專案時程延宕、成本錯估與品質難 以信賴，依 Standish Group International CHAOS 於 2006 年的統計，只有百分 之 29 的專案是成功的，而使用者的參與更是專案成功最重要的因素，所以僅 僅提升軟體廠商單一方的水準顯然不足夠，SEI 於 2007 年 11 月正式公告 CMMI-ACQ (CMMI for Acquisition)，即針對甲方採購流程改善之 CMMI 模. 治 政 大 的導入，挑選認真落實 不能只憑藉對最後結果的驗收；透過 CMMI-ACQ 立. 式。因為，專案的成功起源於好的規格與選商，及全程有效的監控與管理，. CMMI-DEV 模式的廠商，以優質的流程管理及能力、有效而低風險的方式開. ‧ 國. 學. 發產品，同時強化自己的採購流程與專案管理能力，知道如何有效地要求供. ‧. 應商，更進一步，與供應商共同築成 CMMI-DEV 與 CMMI-ACQ 共用平台，. y. Nat. 使甲、乙雙方擁有對等的流程基礎，以更有效的方式協同工作。最終目標，. er. io. sit. 就是使整體專案能如期、如質、如預算的完成，提升資訊服務品質。 根據 CMMI-ACQ，籌獲管理著重於甲方的活動，甲方應先確立初步專案. al. n. v i n 需求，再由乙方承接並發展後續細部的開發需求；前者可遵循 Ch engchi U. CMMI-ACQ. 的籌獲需求發展流程領域的指引進行之，後者則可借重 CMMI-DEV 的需求 發展（Requirement Development）流程領域的指引進行之。 甲方的重要工作產出，如需求規格書、工作說明書、整體籌獲專案計畫等 對後續專案標辦、簽約、開發與驗收皆有重大影響，應先建立相關重要產出 的驗證準則與程序並依此進行驗證，以確保甲方的工作產品品質。至於甲方 的確認作業，則是針對乙方交付產品之審查與驗收，以確保甲方接收符合需 求的產品。 因此，本研究嘗試以資訊組織管理觀點研究籌獲管理的資訊需求，期待據 此建立籌獲管理資訊溝通平台，支援高成熟度的籌獲管理能力。 -3-.
(12) 1.3 研究目的 本研究目的以 CMMI-ACQ 模式為基礎，建構軟體開發籌獲管理資訊需求 架構，供籌獲型組織進行作業流程及資訊支援工具使用的規劃，以追求 CMMI 籌獲管理能力成熟度的提升，使籌獲組織建立一個以 CMMI-ACQ 為基礎的 籌獲管理支援系統分析架構，以達成以下目的: （一）探討 CMMI-ACQ 模式， （二）協助誘發組織建立籌獲管理支援系統的需求，. 政 治 大. （三）發展 CMMI-ACQ 與 CMMI-DEV 共用資訊管理平台。. 立. 1.4 研究範圍. ‧ 國. 學. 本論文目的以 CMMI-ACQ 模式為參考模式，並選取 3 個籌獲方特有的流. ‧. 程領域：籌獲需求發展、籌獲確認及籌獲驗證，萃取其資訊需求，以期建立. sit er. io. 1.5 研究程序. y. Nat. 籌獲管理系統以提升組織的籌獲管理能力。. n. al. i 本論文共分為 6 大步驟，茲敘述如下（圖 1-1）：n Ch engchi U. v. 1. 提出研究動機與目的. 說明本研究的動機與目的以及研究方法。 2. 文獻探討 探討籌獲管理的重要性，如何提升籌獲管理能力， CMMI-ACQ 流 程領域相關作業程序，軟體需求發展等。 3. 籌獲管理需求發展 以 CMMI-ACQ 模式中 3 個籌獲方特有的流程領域：籌獲需求發展、 籌獲確認及籌獲驗證，萃取其資訊需求，建構軟體開發籌獲管理資訊需 求架構，供籌獲型組織進行作業流程及資訊支援工具使用的規劃。 -4-.
(13) 4. 使用案例分析與說明 參考第 3 步驟所產生的活動圖以及 5W1H，進行系統的使用案例分 析與說明。 5. 以 SCAMPI 試評 以 SCAMPI 試評整個籌獲管理作業是否符合 CMMI-ACQ 籌獲需求 發展、籌獲驗證及籌獲確認流程領域的特定目標。 6. 結論以及貢獻說明 結論以及未來研究方向說明。. 1.6 研究方法. 政 治 大. 立. ‧ 國. 學. Nunamaker(1992)所提出以系統發展法為主的研究生命週期概念，在此概念 中，資訊系統的研究生命週期大致包括四類方法：. ‧. 1. 理論建立(Theory Building). sit. y. Nat. 2. 實驗(Experimentation). al. n. 4. 系統發展(System Development). Ch. engchi. er. io. 3. 觀察(Observation). i n U. v. 梁定澎（民 86）於「資訊管理研究方法總論」一文中參考美國學者於 1989 年舉行了一系列的研討會，將資管研究方法主要分為六類：(1)個案研究（Case Study）、(2)調查研究（Survey Research Method）、(3)實驗性研究（Experimental research method）、(4)模式推導（Modeling） 、(5)系統展示（System representation）、(6)彙總研究（Meta-research）。 此外，Scott-Morton(1984)對管理支援系統(Management Support Systems)提出 了九種的研究方法，包括了雛型法(Prototyping)、方法論(Methodology)、理論發 展(Theory Development)、概念形成(Concept Formulation)、實驗室實證測試 (Empirical Laboratory Test)、真實世界實證測試(Empirical Real-World Test)、調查. -5-.
(14) (Survey)、個案研究(Case Study)及真理(Truth)。 本研究採概念形成的方式，以 CMMI-ACQ 為基礎規劃資訊科技籌獲管理之 資訊需求，可作為後續研究系統發展及展示相關研究之根據。. 立. 政 治 大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. -6-. i n U. v.
(15) 提出研究動機與目的. 文獻探討. 治 政 籌獲需求發展、籌獲 大. 立 確認及籌獲驗證之概 念發展. y. ‧. ‧ 國. 學. Nat. n. er. io. al. sit. 使用案例分析. Ch. engchi. i n U. SCAMPI試評. 成果與貢獻說明. 圖 1-1：研究流程 資料來源：本研究整理 -7-. v.
(16) 第二章 文獻探討 2.1 資訊科技的籌獲 Duranni 等(1999)建立一個「科技籌獲模式」 （表 2-1） ，考量 3 大面向及 其分類等級，結合市場資訊、客戶需求及相關產品開發流程，建構一個結構 化的框架，用以界定最符合市場需求及企業策略目標的技術解決方案。 表 2-1：技術籌獲模式及其面向. 政 治 大 市場需求 立 必要的、加值的、想要的 面向. 分類/等級. ‧ 國. 學. 技術分類 基本的、核心的、未來的 籌獲來源 內部、聯盟、外部. ‧. 資料來源：Duranni 等,1999. sit. y. Nat. CMMI V1.1（2002）及 CMMI-DEV V1.2（2006）中的技術解決方案. io. er. （Technical Solution; TS）流程領域中揭露在發展產品元件的解決方案並著手 設計時，其實作的方式可採「自製（Make）」 、「採購（Buy）」或「再利用. al. n. v i n Ch （Reuse）」。若為「採購」，有關產品的需求及驗收準則須詳細記載於供應商 engchi U 契約中。後續的籌獲管理，則納入供應商契約管理（Supplier Agreement Management; SAM）流程領域中規範。 周玄明（2004）以能力成熟度整合模式籌獲模組（CMMI AM V1.0）為 基礎，結合我國政府採購法（Government Procurement Law；GPL）與資訊系 統功能發展有關法規，及美國聯邦採購規則（Federal Acquisition Regulation －FAR）等指引，提出政府資訊系統採購規劃階段執行要領與注意事項。 黃政霖（2008）針對國軍於 2001-2006 年間籌獲缺失進行探討，依據 CMMI-ACQ 各個流程領域架構關聯性，架構出我國空軍應有的籌獲作業流. -8-.
(17) 程。. 2.2 資訊軟體品質與籌獲需求 軟體品質的控制，乙方可以透過嚴謹的測試手法確保品質（Saran, 2003） ，品質的提升，對外可提高甲方滿意度，對內可增加軟體再利用性。更 重要的是，甲方必需於系統籌獲前置作業時，依操作需要、技術、風險及成 本的評估結果發展系統概念（圖 2-1），以確立後續系統發展的品質。. 立. 政 治 大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 註：. Ch. engchi. i n U. v. IOC：Initial Operational Capability JROC：Joint Requirements Oversight Council LRIP：Low Rate Initial Production MNS：Mission Need Statement ORD：Operational Requirements Document 圖 2-1：籌獲流程模式 資料來源：Defense Acquisition University, 2001 專案失敗的主因與需求高度相關，在一個委外環境中，明確、清楚的需求 更是專案成功的重要源頭，這也是 SEI 將原本在 CMMI-ACQ 初步報告 （Adapting CMMI for Acquisition Organizations: A Preliminary Report；Dodson -9-.
(18) 等著）中屬成熟度等級 3 的籌獲需求發展流程領域（Acquisition Requirement Development） ，於 CMMI-ACQ V1.2 正式版中納入成熟度等級 2，以便讓籌獲 者可先行導入的原因。. 與 CMMI-ACQ. 2.3 CMMI-AM 2.3.1 CMMI-AM. Acquisition Support Program (2005)指出一個成功的委外專案單靠具有 CMMI-DEV 流程模式能力的開發方是不足的，需要雙方的共同努力（如圖. 政 治 大. 2-2）。最佳的實作準則是一對能力匹配的甲、乙雙方，有效的協同合作，才 可提高專案成功率。. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 2-2：甲/乙雙方的匹配 資料來源：譯自 Acquisition Support Program, 2005 Bernard 等分別於 2004、2005 年公告籌獲模組 (CMMI Acquisition Module ; CMMI-AM) 版本 1.0 與版本 1.1，定義有效的籌獲實作方法並支援. - 10 -.
(19) 監控外部發展者或供應商，目的是影響籌獲流程的產出及如期、如質、如預 算地提供正確的產品與服務。該模組建立籌獲者應有的基礎概念與規範，包 含專案管理類、支援類及工程類共 12 個流程領域（表 2-2）。 表 2-2：籌獲模組的流程領域 專案管理類. 支援類. （Project Management ）. （Support） . 專案管理（Project. 專案監控（Project. 立. Monitoring and Control;. Operations and. n. Support; TOS）. Ch. engchi. . sit. io. al. Management; IPM） . . Management; REQM） 驗證（Verification; VER）. y. Nat. SCM）. 需求管理 （Requirements. 產品移轉與支援 （Transition to. （Integrated Project. . ‧. . Contract Monitoring;. 整合的專案管理. Development; RD）. （Measurement and Analysis）. （Solicitation and. . and Resolution; DAR） 政 治 大 度量與分析. 邀商與契約監控. 需求發展 （Requirements. 學. ‧ 國. PMC） . . 決策分析與解決方案 （Decision Analysis. Planning; PP） . （Engineering ）. 確認（Validation; VAL）. er. . 工程類. i n U. v. 風險管理（Risk Management; RSKM）. 資料來源：整理自 CMMI-AM V1.1, 2005 CMMI-AM 除指出邀商與契約監控及產品移轉與支援為籌獲者額外應 具備的流程能力外，其餘流程領域皆引用 CMMI-DEV 模式的精神，採籌獲 者的角度所建立的籌獲管理流程。雖然籌獲模組提供了基本籌獲管理的概. - 11 -.
(20) 念，但無法提供一個比較的基準或說是評鑑的方法支撐。 一個完整的模式除模式本身外，應再包含評鑑方法(Appraisal Methods)及相關 訓練課程，以 CMMI 為例即包含： . 模式：CMMI-DEV、CMMI-ACQ、CMMI-SVC。. . 評鑑方法(Appraisal Methods): SCAMPI（Standard CMMI Appraisal Method for Process Improvement） 。. . 訓練課程: CMMI 簡介、中階課程、SCAMPI 課程、講師培訓課程及主評 鑑員培訓課程等。. 政 治 大 2006 年 6 月由美國通用汽車（GM）資訊科技委外部門與 SEI 共同發表 立. 2.3.2 CMMI-ACQ. ‧ 國. 學. CMMI-ACQ 初步報告，2007 年 11 月發布 CMMI-ACQ V1.2 正式版本，CMMI-ACQ 宣稱是為籌獲組織所適用的 CMMI，彙集來自於政府與產業界的最佳執行方法。. ‧. CMMI-ACQ 提供籌獲者 CMMI 應用指導，包括供應商選擇、供應商協議起草、簽. sit. y. Nat. 訂的必要活動，以及透過一組標準的量度、驗收準則及供應商交付項目，來管理產. al. er. io. 品與服務的籌獲。CMMI-ACQ 整合了對於籌獲者來說至為重要的知識體系，透過這. v. n. 些知識體系的整合，為籌獲者在與供應商一起發展及維護產品與服務時，提供周延 的解決方案。. 2.3.2.1. Ch. engchi. i n U. CMMI 發展趨勢 CMMI 管理制度已成為國際公認軟體開發與專案管理品質的標竿，目前已高達. 63 個國家依據此模式來進行流程改善與品質提升，為擴大其應用範圍，建立三大類 別（Constellations，圖 2-3） ： 1.開發的 CMMI(CMMI for Development, CMMI-DEV)：為開發者所適用，其前 身為 CMMI，於 2006 年 8 月 25 日正式出版 V1.2。 2.籌獲的 CMMI(CMMI for Acquisition, CMMI-ACQ)：為採購者所適用。於 2007 年 11 月 1 日正式出版 CMMI-ACQ V1.2。 - 12 -.
(21) 3.服務的 CMMI(CMMI for Service, CMMI-SVC)：為提供服務者所適用，於 2006 年 9 月發展出 CMMI-SVC 初稿(CMMI Services: Initial Draft)，2009 年 2 月 25 日正式出版 V1.2。 三大類別皆以 CMMI 的 16 個流程領域(Process Area; PA)為共同發展的基礎， 稱為 CMF(CMMI Model Foundation)，再各自發展其所需的特定流程領域。. CMMI-SVC CMMI-DEV 開發者的指引. CMMI-SVC 服務提供者的指引. 政 治 大. 16 核心/共用 流程領域 CMMI-DEV CMMI-ACQ. 學. CMMI-ACQ 籌獲者的指引. y. er. al. n. 模式表述. io. 2.3.2.2. 資料來源：譯自 SEI, 2007. sit. Nat. 圖 2-3：CMMI 應用範圍之三大類別. ‧. ‧ 國. 立. Ch. i n U. v. CMMI-ACQ 有連續式與階段式兩種表述（圖 2-4），兩種表述方式即為. engchi. 實作 CMMI-ACQ 的方式，分別是針對各別的、單一的流程領域(連續式)，或 一群特定的流程領域(階段式)進行流程改善，雖然表述方式不一，但其內容 及效果是相同的。在連續式中評鑑之基準為能力度（capability） ，而階段式之 基準為成熟度（maturity）。能力度衡量單一流程領域之能力層級（Capability Level） ，成熟度衡量整個組織針對一組既定的流程領域之成熟層級（Maturity Level）。. - 13 -.
(22) 圖 2-4：模式表述 資料來源:整理自 CMMI Product Team, 2007 2.3.2.3. 政 治 大. 流程領域(Process Area; PA). 立. ‧ 國. 學. 將屬性近似的執行方法(Practice)集合成為一個流程領域，以達到該 流程領域的目標(Goal)，進而改善組織對該流程領域的作法，如籌獲需. er. io. sit. 特定目標(Specific Goals; SG). y. Nat. 2.3.2.4. ‧. 求發展、籌獲驗證及籌獲確認流程領域。. 為一流程領域內的各項應實作目標，說明流程領域內必需完成的作. al. n. v i n 業目標。如籌獲需求發展、籌獲驗證及籌獲確認流程領域分別有 3 個、 Ch engchi U 3 個及 2 個特定目標，詳如表 2-3,表 2-4 及表 2-5。 2.3.2.5. 特定執行方法(Specific Practices; SP) 即為一特定執行目標所認定的細部實作指引。例如籌獲需求發展流 程領域的 SG1 發展客戶需求即有 2 個 SP，詳如表 2-3,表 2-4 及表 2-5。 表 2-3：籌獲需求發展的特定目標與執行方法. SG 1 發展客戶需求（Develop Customer Requirements） SP 1.1 誘導關鍵人員需要（Elicit Stakeholder Needs） SP 1.2 發展並排序客戶需求（Develop and Prioritize Customer Requirements） SG 2 發展契約需求（Develop Contractual Requirements） SP 2.1 建立契約需求（Establish Contractual Requirements） - 14 -.
(23) SP 2.2 配置契約需求（Allocate Contractual Requirements） SG 3 分析與確認需求（Analyze and Validate Requirements） SP 3.1 建 立 操 作 性 概 念 與 劇 本 （ Establish Operational Concepts and Scenarios） SP 3.2 分析需求（Analyze Requirements） SP 3.3 平衡需求（Analyze Requirements to Achieve Balance） SP 3.4 確認需求（Validate Requirements） 資料來源：整理自 CMMI Product Team, 2007. 表 2-4：籌獲驗證的特定目標與執行方法 SG 1 準備驗證（Prepare for Verification） SP 1.1 選擇驗證工作產品（Select Work Products for Verification） SP 1.2 建立驗證環境（Establish the Verification Environment） SP 1.3 建立驗證程序與準則（Establish Verification Procedures and Criteria） SG 2 執行同仁審查（Perform Peer Reviews） SP 2.1 準備同仁審查（Prepare for Peer Reviews） SP 2.2 執行同仁審查（Conduct Peer Reviews） SP 2.3 分析同仁審查資料（Analyze Peer Review Data） SG 3 驗證工作產品（Verify Selected Work Products） SP 3.1 執行驗證（Perform Verification） SP 3.2 分析驗證結果（Analyze Verification Results） 資料來源：整理自 CMMI Product Team, 2007. 立. 政 治 大. ‧. ‧ 國. 學. io. sit. y. Nat. n. al. er. 表 2-5：籌獲確認的特定目標與執行方法. i n U. v. SG 1 準備確認（Prepare for Validation） SP 1.1 選擇確認產品（Select Products for Validation） SP 1.2 建立確認環境（Establish the Validation Environment） SP 1.3 建立確認程序與準則（Establish Validation Procedures and Criteria） SG 2 確認產品（Validate Selected Products and Product Components） SP 2.1 執行確認（Perform Validation） SP 2.2 分析確認結果（Analyze Validation Results） 資料來源：譯自 CMMI Product Team,2007 2.3.2.6. Ch. engchi. 一般目標(Generic goals; GG) 為確保流程的執行度，建立所有流程領域內的共通實作目標，說明 每個流程領域皆需完成的目標區分 5 個 GG（表 2-6）。. - 15 -.
(24) 表 2-6：一般目標 Generic Goal. 名稱. 主要特性. GG1. 執行的(Performed). 已執行各 PA 之 SG. GG2. 管理的(Managed). 各 專 案 之 流 程 在 GG2 指引（完成GG2 的GP） 中使得具管理性。. 定義的(Defined). GG3. 以全組織為著眼，所有 專案皆具一致性。. GG4. 量化管理(Quantitatively. GG5. managed) 最佳化(Optimizing). 量化管理所有流程，改 善流程特殊異常。. 政 治 大. 持續改善流程根本異 常。. 資料來源：譯自 CMMI Product Team, 2007. 立. 一般執行方法(Generic practices ;GP). 學. ‧ 國. 2.3.2.7. 為一般執行目標的細部實作指引，必需在所有流程領域內完成。以 GG2 來說,共有 10 個 GP:. ‧. GP 2.1. 建立組織流程策略(ESTABLISH AN ORGANIZATIONAL. sit. n. al. er. io. GP 2.2 GP 2.3 GP 2.4 GP 2.5 GP 2.6 GP 2.7. y. Nat. POLICY) 規劃流程(PLAN THE PROCESS.) 提供資源(PROVIDE RESOURCES.) 指派責任(ASSIGN RESPONSIBILITY.) 訓練人員(TRAIN PEOPLE.) 管理組態 (MANAGE CONFIGURATIONS.) 界 定 參 與 人 員 (IDENTIFY AND INVOLVE RELEVANT. Ch. engchi. i n U. v. GP 2.8. STAKEHLODERS.) 監 控 流 程 執 行 (MONITOR AND CONTROL THE. GP 2.9. PROCESS.) 客 觀 評 估 流 程 之 執 行 (OBJECTIVELY EVALUATE. ADHERENCE.) GP 2.10 陳報流程狀態(REVIEW STATUS WITH HIGHER LEVEL MANAGEMENT.) 2.3.2.8. CMMI-ACQ 的 22 個流程領域 CMMI-ACQ 分 4 大類別含流程管理、籌獲類、專案管理類及支援 類，共有 22 個流程領域。以成熟度及流程領域類別區分，CMMI-ACQ - 16 -.
(25) 模式的 22 個流程領域如表 2-7。 表 2-7：CMMI-ACQ 模式彙整 專案管理 ◥. 支援 ●. Process Acquisition Management OID 組織創新和推 展. Project Management. Support. Level 4 量化管理. OPP 組織流程績效. QPM量化專案管理. Level 3 定義. OPF 組織流程專注 ATM 籌獲技術管理 IPM 整合性專案管 DAR 決策分析 OPD 組織流程定義 AVER 籌獲驗證 理 和解決方案 OT 組織訓練 AVAL 籌獲確認 RSKM 風險管理. 類別 成熟度 等 級 Level 5 最佳化. 流程管理 ★. 立. CAR 原因分析 和解決方案. 政 治 大 ARD 籌獲需求發展 PP 專案管理. AM 協議管理 PMC 專案監控 SSAD 邀商與合約發 REQM 需求管理. 學. ‧ 國. Level 2 管理. 籌獲 ╋. 展. ‧. n. al. Ch. engchi. - 17 -. y. sit er. Acquisition Requirements Development (ARD) Acquisition Technical Management (ATM) Acquisition Validation (AVAL) Acquisition Verification (AVEL) Causal Analysis and Resolution (CAR) Configuration Management(CM) Decision Analysis and Resolution(DAR) Integrated Project Management (IPM) Measurement and Analysis (MA) Organizational Innovation and Deployment (OID) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Process Performance(OPP) Organizational Training(OT) Project Monitoring and Control (PMC) Project Planning(PP) Process and Product Quality Assurance (PPQA). io. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.. Nat. 註：流程領域英文全名如下： 1. Agreement Management（AM）. i n U. v. MA. 度量與分. 析 PPQA 流程和產 品品質保證 CM 型態管理.
(26) 19. Quantitative Project Management(QPM) 20. Requirements Management (REQM) 21. Risk Management (RSKM) 22. Solicitation and Supplier Agreement Development (SSAD) ※. 斜體部分為 ACQ 特有的流程領域，餘為共用流程領域。 資料來源:本研究整理. 2.4 需求分析 需求分析是研究使用者的需要，將之轉為系統、硬體、軟體需求的過程；或是 研究及精製系統、硬體、軟體需求的過程(IEEE, 1993)。需求分析是需求工程系統化. 政 治 大. 找出需求的活動之一，也是需求工程最重要的活動，文獻中的各種需求分析技術如. 立. 表 2-8 所示列。. ‧ 國. 學. 表 2-8：各種需求分析方法. 需求分析技術. sit. y. 資訊不同，因此此法依賴需求分析師的整合資訊的經驗. n. al. er. 於進行系統發展階段之前，即需定義出系統的一般性特. io. 專業領域模型法. 需求分析過程中收集資訊最常使用的方式，由於收集的. Nat. (Berlin, 1989). (Kang et. al., 1990). 性. ‧. 訪談. 特. i n U. v. 性及功能，以確保所收集到的資訊可以涵蓋所有相關知. Ch. engchi. 識領域；可以增進效率以及降低系統開發成本。 ORDIT. 可運用於組織需求的定義，滿足所有使用者的需求；可. (Dobson et. al., 1992). 集中於確保資訊的收集來源涵蓋所有相關範圍。. SDL. 可以圖示法描述需求及設計規格；可與其他需求分析方. (Milson, 1989). 法相互搭配。. 模型法. 利用模型來抓取需求，為需求的替代呈現。例如，資料. (Benyon &. 流程圖(Data Flow Diagram)。但在需求不明確時，較難. Skidmore, 1989). 以模型化。. - 18 -.
(27) Zachman Framework. 從程式設計者觀點、資料庫管理者、分析者、設計者等. (Zachman, 1987). 都可以利用這個 5W1H 架構來瞭解整個企業的資訊系 統架構。此架構針對資訊系統分析。. The Information. 依據 Zachman Framework 發展而來，針對資訊作分析，. Framework. 發展的複雜度較高，主要目標為提供管理資訊的策略。. (Evernden, 1996). 適用於財務金融服務業。 資料來源：宋珍儀，2001. 近年來朱明強(2002)、宋珍儀(2001)、林建妤(2004)及郭浩昇(2004)的論文. 政 治 大. 所提出之需求分析架構，皆源自於 Zachman Framework（表 2-9）觀點結合至. 立. 物件導向和統一流程的概念。. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. - 19 -. i n U. v.
(28) 表 2-9：Zachman Framework. 立. 政 治 大. ‧ 國. 學 資料來源:Zachman, 1987. ‧ sit. y. Nat. 2.5 統一化模型語言. n. al. er. io. UML 是一種模型語言，最早是由 Rational Software Cooperation 和三位. i n U. v. 物件導向方法論大師，Grady Booch、James Rumbaugh 與 Ivar Jacobson 共同. Ch. engchi. 創立的(Alhir, 1999)。UML 融合了三位大師多年來的研究成果及業界的實務 經驗，它的應用廣泛，涵蓋多種工具，已被公認為業界標準的物件導向塑模 語言，適用於各種型態的系統、專業領域、及實務方法。本。本文研究以 UML 作為系統規劃表達語法，取用 UML 所提供的部份圖示（表 2-10）（Booh 等, 1999），以萃取籌獲管理的資訊需求。. - 20 -.
(29) 表 2-10：UML 圖示法分類及其說明 分類. 靜態 模型. 圖示名稱. 說明. 物件圖 (Object). 表達一組實體物件間在某一時點的關係。. 類別圖 (Class ). 描述系統中物件的類型(type)及各類型間的關 係。內容包含類別名稱、屬性及操作方法。. 元件圖 (Component ). 主要表示當系統開發完成後的軟體執行架構， 及元件彼此的相依性(dependency)。. 描述分散式系統所包含的硬體設備種類及當中 部署圖 (Deployment) 各元件的分佈。可配合元件圖表達軟硬體設備 的關係。 目的是表達符合使用者需求的劇本 (Scenarios)。主要功能在於描述系統所提供的功 能及其執行時的事件流。. 使用案例圖 (Use-Case). 立. 活動圖 (Activity). 流和組織等互動。. 狀態圖 (State). 將一個物件可能進入的狀態，及其面對外部事 件衍生的狀態變化表示出來。. 循序圖 (Sequence). 用生命線(Lifeline)表現物件生命週期時間，及控 制焦點(Focus of Control)表示物件處理某項工 作的所耗費的時間；為互動圖的一種。. Nat. y. ‧. ‧ 國. 學. 動態 模型. 治 政用來表達企業流程運作是透過工作人員、工作 大. 表達物件如何參與互動，用順序編號代表訊息 傳遞的時間順序；為互動圖的一種。. sit. 合作圖. n. al. er. io. (Collaboration) 資料來源：整理自 Booch 等, 1999. Ch. i n U. v. 本論文重點在於規劃基本的籌獲管理能力的資訊需求，所以只採用活動 圖與使用案例圖。. engchi. - 21 -.
(30) 第三章 籌獲管理資訊需求發展 本研究以探討籌獲管理資訊需求發展為主，期使支援籌獲組織管理能力 之提升。本章分為四大部份：一、研究架構，二、背景說明，三、目標階層 分析(Why)，四、流程分析(When, Who, How, What, Where)。第一部份先簡介 研究架構之形成，從第二部分至第四部分說明架構的概念，運用 UML 的活 動圖加以展現。進一步的使用分析與系統操作畫面則於第四章說明。. 3.1 研究架構. 立. 政 治 大. 本研究延用 QMAP 方法（Tseng and Lin, 2006） ，利用「背景說明」了解. ‧ 國. 學. 組織特性定位，再利用 5W1H 的提問方式-Why, When, Who, What, Where 以 結合 Zachman Framework 的觀點和統一流程的模型元素進行「目標階層分析」. ‧. 及「流程分析」，最後進行描述自動化需求的「使用分析」，如圖 3-1。. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖 3-1：研究架圖 資料來源：修改自林建妤, 2004. - 22 -. v.
(31) 3.2 背景說明 為建立後續發展籌獲需求之便，本研究假設籌獲需求發展、籌獲驗證及 籌獲確認所在的組織架構如圖 3-2 所示，以此為基礎發展籌獲管理的資訊需 求。. 立. 政 治 大. ‧. ‧ 國. 學 er. io. sit. y. Nat 圖 3-2：籌獲管理組織架構圖. n. a l 資料來源：本研究編纂 i v n Ch U 品保小組為獨立之組織，直接向執行長負責。每個籌獲專案皆有一計畫 engchi 主持人，負責整體專案之管理。專案成員含需求規劃人員、需求承諾人員、 驗證與確認人員、審查同仁。需求提供者可能為組織內部或外部人員。將組 織以「角色」而不以「功能別」來界定，目的是保持流程的彈性，實務上， 一個成員可能同時或不同時兼任多重角色，甲方人員各種角色權責詳列於表 3-1。乙方則為承接籌獲專案的開發廠商或組織內部的開發團隊。。 表 3-1：織織角色與權責 角色. 權責. 計畫主持人. 審查籌獲需求發展計畫、分析整體驗證結果. 需求規劃人員. 規劃籌獲需求發展相關活動 - 23 -.
(32) 需求承諾人員. 與需求提供者面談、誘導、分析需求、實現 需求. 需求提供者. 提供、確認使用者/契約需求. 驗證人員. 擬定專案驗證計畫、審查驗證環境與程序、 執行驗證. 品保小組. 審查專案驗證計畫，建立驗證環境、程序與 準則，紀錄、分析並撰寫驗證報告. 審查同仁. 準備審查、進行審查. 確認人員. 審查籌獲確認計畫、審查環境與程序、分析 確認結果. 乙方. 撰擬確認計畫，建立確認環境、程序與準 則，執行確認，紀錄、分析並撰寫確認報告 資料來源：本研究整理 治 政 大. 立 3.3 目標階層分析（Why）與概念圖. ‧ 國. 學. 3.3.1 籌獲需求發展. ‧. 籌獲需求發展（圖 3-3）的目的是發展與分析客戶（使用者）與契約需. Nat. sit. n. al. er. 誘導、分析與確認關鍵人員的需要、期望、限制與界面，進而獲取. io. . y. 求（Why）。主要活動有：. 客戶的真正需求。. Ch. engchi. . 發展品所有生命週期的需求。. . 依客戶需求建立契約需求。. . 發展操作性概念與劇本。. . 分析需要、需求及操作環境。. - 24 -. i n U. v.
(33) 立. 政 治 大. ‧. ‧ 國. 學 圖 3-3：籌獲需求發展概念圖. sit. y. Nat. 資料來源：譯自 Carnegie Mellon University, 2008. io. al. er. 3.3.2 籌獲驗證. v. n. 籌獲驗證（圖 3-4）的目的是確保所選定的工作產品（甲方）符合既定. Ch. 的需求（Why）。主要活動有： . 準備驗證. . 執行驗證. . 界定改善行動. engchi. - 25 -. i n U.
(34) 立. 政 治 大. ‧ 國. 學 圖 3-4：籌獲驗證概念圖. ‧. 資料來源：譯自 Carnegie Mellon University, 2008. n. al. er. io. sit. y. Nat. 3.3.3 籌獲確認. i n U. v. 籌獲確認（圖 3-5）的目的是實體確認所籌獲的產品或服務在其預設的. Ch. engchi. 環境中可以逹成其應有的使用情形（Why）。主要活動有： . 準備確認. . 執行確認. . 界定改善行動. - 26 -.
(35) 立. 政 治 大. ‧ 國. 學 圖 3-5：籌獲確認概念圖. ‧. 資料來源：譯自 Carnegie Mellon University, 2008. sit. y. Nat. n. al. er. io. 3.4 流程分析（When, Who, Where, How, What）與活動圖. Ch. engchi. i n U. v. CMMI Guidebook for Acquirers Team(2007)界定籌獲者於籌獲過程的 7 大階段及與開發者的基本互動關係（圖 3-6）。其中籌獲管理的生命週期為： 籌獲規劃（Acquisition Planning）、RFP 準備（RFP Preparation）、招商 (Solicitation)、選商（Source Selection） 、管理與監控（Program Leadership Insight/ Oversight）、驗收（Acceptance）及 移轉（Transition），以下簡稱 AP、RP、 SL、SS、PO、AC、TS。. - 27 -.
(36) 籌獲者 籌獲規劃. RFP準備. （AP）. （RP）. 招商. 選商. （SL）. 提供建議 書與簽約. 規劃. （SS）. 設計. 管理與監. 驗收. 控（PO）. （AC）. 開發. 移轉 （TS）. 整合與. 交付. 測試. 產品. 開發者. 政 治 大. 圖 3-6：籌獲者與開發者的互動關係圖 資料來源：譯自 CMMI Guidebook for Acquirers Team,2007. 立. 3.4.1 When 的定義：. ‧ 國. 學. 籌獲過程是從籌獲規劃階段開始，安排一系列的籌獲管理活動。. y. Nat. 動。. ‧. CMMI-ACQ 的 22 個流程領域之啓動時間點源自於整體籌獲過程的進程所啓. er. io. sit. 籌獲需求發展（ARD）主要是為確實發展籌獲者需求，其著重點應在 AP 與 RP 兩階段，籌獲確認（AVER）主要是確保甲方工作產品（如籌獲計. al. n. v i n 畫，含相關計畫，如建構管理計畫、專案品保計畫等，RFP、招標文件、契 Ch engchi U. 約、籌獲需求文件等）符合特定的需求/規格，著重點也在 AP 與 RP 兩階段。 籌獲確認（AVAL）主要是確保籌獲產品（如專案執行計畫書、需求與設計限 制、系統分析文件、系統設計文件、軟體設計規格書、產品與產品組件-軟硬 體系統、測試計畫書、使用者手冊、訓練文件、乙方的驗證/確認報告等）的 品質，其著重點在 PO、AC 及 TS 三階段。 SL 與 SS 多屬邀商與契約發展流程領域活動，不在本論文探討的三個流 程領域範圍內，本研究所涵蓋的 CMMI-ACQ 流程領域與籌獲流程之對映如 表 3-2 所示。. - 28 -.
(37) 表 3-2：籌獲管理流程支援籌獲專案生命週期示意圖 AP. RP. SL. SS. PO. AC. TS. ARD AVER AVAL 資料來源：本研究整理. 3.4.2 Who，Where，How，When 及 What 的定義 本論文針對籌獲需求發展、籌獲驗證及籌獲確認三個流程領域繪製活動 圖，根據每個活動（How），以 UML 活動圖表達 Who/Where 和 How 的作業. 政 治 大 整個籌獲需求發展的活動（圖 3-7） ，由擬定籌獲需求發展計畫開始。在 立. 流程，並加註 When（籌獲專案生命週期）及 what（主要產出）的說明。. ‧ 國. 學. 發展使用者需求與契約需求時，皆須經由操作性概念與劇本、分析需求、平 衡需求及確認需求活動的支援。. ‧. 籌獲驗證的活動（圖 3-8） ，主要有同仁審查與驗證作業。為確保甲方的. sit. y. Nat. 工作產品符合特定需求/規格，可由品保小組負責建立驗證環境及相關程序與. io. er. 準則。若驗證結果不符合，將重新檢討驗證環境或重擬驗證計畫。. al. 籌獲確認的活動（圖 3-9） ，是要確保乙方產品的品質。確認的產品不限. n. v i n Ch 於產品本身，也可以是產品組件或與使用者需要相關的產出。乙方依契約要 engchi U 求訂定確認計畫，由甲方審查後據以執行。若確認結果不符合，將重新檢討 確認環境或重擬確認計畫。確認的計畫雖可由乙方擬定，但甲方需在委外契 約中訂定確認的產品及確認標準、確認程序、確認方法/工具及準則。. - 29 -.
(38) 立. 政 治 大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖 3-7：籌獲需求發展活動圖 資料來源：本研究整理. - 30 -. v.
(39) 立. 政 治 大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖 3-8：籌獲驗證活動圖 資料來源：本研究整理. - 31 -. v.
(40) 立. 政 治 大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖 3-9：籌獲確認活動圖 資料來源：本研究整理. - 32 -. v.
(41) 第四章 籌獲管理使用案例分析 使用案例圖可以用來表示「使用案例(Use Case) 」和「行動者(Actor)」 之間的互動關係。 「使用案例(Use Case) 」呈現系統的功能，也可以說是用戶 觀點下的系統需求， 「行動者(Actor)」則代表提供資訊給系統或從系統接受資 訊的人或是其他的系統。因此，使用案例圖可以呈現出每一個使用案例是由 哪個行動者所引起的，同時也說明了行動者可以從使用案例中獲得資訊的事. 政 治 大. 實，本質上，使用案例圖及使用案例描述即在說明系統的需求(Alhir, 1999)。. 立. 4.1 籌獲需求發展使用案例分析與說明. ‧ 國. 學. 依據籌獲需求發展活動圖（圖 3-7） ，建立籌獲需求發展使用案例圖（圖. ‧. 4-1）。首先在籌獲規劃階段，由需求規劃人員擬定需求發展計畫，此計畫可. sit. y. Nat. 簡單的以人、事、時、地及物的方式，交待需求發展期間需要配合的人、需. al. n. 表)。. er. io. 求主題、時間、地點及相關使用工具並通知需求承諾人員與需求提供者(代. Ch. engchi. i n U. v. 在 RFP 準備階段，需求承諾人員需與需求提供者協同合作，共同發展 需求，含客戶需求與契約需求。為有效取得、發展需求，在 CMMI 模式中列 舉了多種誘發需求的方法：問卷與訪談、雛型和模型、觀察現行產品、環境 及工作流程的樣式、腦力激盪、市場調查、由文件、標準或規格等來源中抽 取、使用案例、業務案例分析等方法。而在需求發展的過程中，須建立操作 性概念與劇本，用以協助誘發、分析及確認需求。. - 33 -.
(42) 1.1 建立籌獲需求發展計畫 ::需求規劃人員 1.2 審查後公告籌獲需求發展計畫. 1.3 上傳客戶需求 ::計畫主持人 1.4 治 政 建立客戶需求分析報告 大 立. ‧ 國. ::需求承諾人員. 學. 1.5 確認客戶需求. Nat. y. ‧. 1.6 上傳契約需求. n. sit er. io. 1.7 建立契約需求分析報告. al. ::需求提供者. Ch. 1.8 確認契約需求. engchi. i n U. v. 圖 4-1：籌獲需求發展使用案例圖 資料來源：本研究整理 依籌獲需求發展使用案例圖（圖 4-1），發展出各個使用案例（表 4-1、 表 4-2、表 4-3、表 4-4 及表 4-5）。 表 4-1：「建立籌獲需求發展計畫」使用案例說明 使用案例名稱(Use Case Name)：建立籌獲需求發展計畫. 編號：1.1. 主流程（Main Flow）： －使用者一進入此畫面，系統將自動帶出規劃人員(同登入人員)。 - 34 -.
(43) 使用案例名稱(Use Case Name)：建立籌獲需求發展計畫. 編號：1.1. －使用者輸入專案代號後，系統自動帶出專案名稱。 －使用者點選或輸入訪談時間、地點、訪談人員、受訪人員、受訪單位及訪談 內容，按「新增」，系統即可此筆資料資新增至畫面的表格中。 －使用者若需「修改」或「刪除」，可直接點選欲修改或刪除的訪談時間，系 統將該筆資料顯示於畫面之欄位內。 －使用者當完成所有需求發展訪談的規劃後，按「規劃完成」，系統將發出電 子郵件信箱，通知計畫主持人進行審查，並直接提供超連結供計畫主持人. 政 治 大 衍生或替代流程（Extensions or Alternatives）：無。 立資料來源：本研究整理 點選。. ‧ 國. 學. 相關畫面展示：. ‧. io. sit. y. Nat. n. al. er. . Ch. engchi. i n U. v. 表 4-2：「審查後公告籌獲需求發展計畫」使用案例說明. - 35 -.
(44) 編號：1.2. 使用案例名稱(Use Case Name)：審查後公告籌獲需求發展計畫. 主流程（Main Flow）： －使用者一進入此畫面，系統將自動帶出審查人員(同登入人員)。 －使用者輸入專案代號後，系統自動帶出專案名稱。 －使用者選擇欲審查的文件，系統自動帶出最新版次。 －使用者點選應公告的對象。 －使用者依系統所提供的審查項目，點選審查結果。 －使用者完成所有審查項目，點選「審查完成」，系統將依彙整審查結果修改. 政 治 大. 文件狀態為審查通過或審查未通過。若為審查通過，系統自動發送計畫予 公告的對象。. 立. 學. 資料來源：本研究整理. 相關畫面展示：. ‧. io. sit. y. Nat. n. al. er. . ‧ 國. 衍生或替代流程（Extensions or Alternatives）：無。. Ch. engchi. - 36 -. i n U. v.
(45) 立. 政 治 大. ‧ 國. 學. 表 4-3：「上傳客戶/契約需求」使用案例說明. 使用案例名稱(Use Case Name)：上傳客戶/契約需求. 編號：1.3/1.6. ‧. 主流程（Main Flow）：. y. Nat. n. al. －使用者點選欲上傳的文件類別。. Ch. engchi. i n U. －使用者將文件狀態由「未完成」修改為「完成」。 －使用者「瀏覽」欲上傳文件的位置。 －使用者「點選」上傳。 衍生或替代流程（Extensions or Alternatives）：無。 資料來源：本研究整理 . 相關畫面展示：. - 37 -. er. io. －使用者輸入專案代號後，系統自動帶出專案名稱。. sit. －使用者一進入此畫面，系統將自動帶出承諾人員(同登入人員)。. v.
(46) . 客戶需求建議大綱 1. 管理資訊的說明：含文件名稱、撰寫人、日期、版別、頁數. 立. 政 治 大. ‧. ‧ 國. 學. 2. 文件修訂紀錄 3. 簡介 4. 需求提供與接受準則 5. 需求誘導方式 6. 需求限制 7. 特定需求 8. 介面需求 9. 驗證與確認條件 10. 需求順序 11. 操作性概念與據本 12. 需求彙整表 契約需求建議大綱 1. 管理資訊的說明：含文件名稱、撰寫人、日期、版別、頁數 2. 文件修訂紀錄 3. 專案整體需求 4. 應用系統需求 5. 軟硬體設備需求 6. 介面管理需求 7. 資訊安全需求 8. 系統發展需求 9. 服務管理需求 10. 專案管理（含專案品質）需求 11. 流程管理需求 12. 交付項目與驗收（含契約需求與交付項目對照表）. n. er. io. sit. y. Nat. al. . Ch. engchi. - 38 -. i n U. v.
(47) 表 4-4：「建立客戶/契約需求分析報告」使用案例說明 使用案例名稱(Use Case Name)：建立客戶/契約需求分析報告. 編號：1.4/1.7. 主流程（Main Flow）： －使用者一進入此畫面，系統將自動帶出分析人員(同登入人員)。 －使用者輸入專案代號後，系統自動帶出專案名稱。 －使用者選擇欲分析的文件，系統自動帶出最新版次。 －使用者依系統所提供的文件項目，點選分析結果。 －使用者完成所有分析項目，點選「分析完成」，系統依各分析項目的結果，. 政 治 大 衍生或替代流程（Extensions or Alternatives）：無。 立資料來源：本研究整理. 將分析結果修改為「待確認」，並將通知需求提供者進行需求確認。. ‧ 國. 學. 相關畫面展示：. ‧. io. sit. y. Nat. n. al. er. . Ch. engchi. - 39 -. i n U. v.
(48) 表 4-5：「確認客戶/契約需求」使用案例說明 使用案例名稱(Use Case Name) 確認客戶/契約需求. 編號：1.5/1.8. 主流程（Main Flow）： －使用者一進入此畫面，系統將自動帶出確認人員(同登入人員)。 －使用者輸入專案代號後，系統自動帶出專案名稱。 －使用者選擇欲確認的文件，系統自動帶出最新版次。 －使用者依系統所提供的確認項目，點選確認結果。 －使用者完成所有確認項目，點選「確認完成」，系統將依彙整確認結果，修. 政 治 大 衍生或替代流程（Extensions or Alternatives）：無。 立資料來源：本研究整理. 改客戶/契約需求文件態為確認通過或確認未通過。. ‧ 國. 學. 相關畫面展示： 確認「客戶需求」畫面：. ‧. n. er. io. sit. y. Nat. al. . Ch. engchi. 確認「契約需求」畫面：. - 40 -. i n U. v.
(49) 立. 政 治 大. ‧ 國. 學 ‧. 4.2 籌獲驗證使用案例分析與說明. sit. y. Nat. 依據籌獲驗證活動圖（圖 3-8），建立籌獲驗證使用案例圖（圖 4-2）。. al. er. io. 首先在籌獲規劃階段，由驗證人員負責撰寫驗證計畫，驗證的項目以甲方重. v. n. 要的工作產品為主，且須經由獨立的品保小組審查，以確立其公正性。. Ch. engchi. i n U. 雖然驗證的活動是貫穿完整籌獲生命週期，但考量「甲方」的重要工作 產品多發生在「RFP 準備」階段，如招標文件、契約書等。所以在該階段以 品保小組獨立、客觀的特性，建立所須的驗證環境、程序與準則後，再經驗 證人員審查無誤後，據以執行。而「同仁審查」是驗證的一種形式，在驗證 計畫中須界定採用同仁審查的工作產品。 至於其他階段，多為乙方的工作產出，不論是乙方的驗證活動或同仁審 查的項目、方法、紀錄等，應在契約內規範，要求乙方提報，再由甲方進行 審查。. - 41 -.
(50) 立. 政 治 大. ‧. ‧ 國. 學 er. io. sit. y. Nat. n. al. i n 圖 4-2：籌獲驗證使用案例圖 Ch engchi U 資料來源：本研究整理. v. 依籌獲驗證使用案例圖（圖 4-2） ，發展出各個使用案例（表 4-6、表 4-7、 表 4-8 及表 4-9） ，另「上傳驗證計畫」 、 「上傳驗證報告」 （使用案例編號：2.1 與 2.4）與「上傳客戶/契約需求」使用案例說明（表 4-3）相似度頗高，故不 再描述。 隨同「上傳驗證計畫」、「上傳驗證報告」使用案例說明，提供驗證/確 認計畫與報告之建議大綱如下：. . 驗證/確認計畫建議大綱 - 42 -.
(51) 立. 政 治 大. 學. ‧. ‧ 國. io. sit. y. Nat. n. al. er. . 1. 管理資訊的說明：含文件名稱、撰寫人、日期、版別、頁數 2. 文件修訂紀錄 3. 驗證/確認的目的 4. 驗證/確認的方法 5. 驗證/確認的環境 6. 驗證/確認的資料準備 7. 驗證/確認的程序與準則 8. 驗證/確認的項目 9. 同仁審查的準備 10. 同仁審查項目 11. 驗證/確認的時程 驗證/確認報告建議大綱 1. 管理資訊的說明：含文件名稱、撰寫人、日期、版別、頁數 2. 文件修訂紀錄 3. 驗證/確認的目的 4. 驗證/確認的方法 5. 驗證/確認的環境 6. 驗證/確認的資料準備 7. 驗證/確認的程序與準則 8. 驗證/確認的結果 9. 同仁審查結果 10. 驗證/確認的時程 11. 驗證/確認的異常清單. Ch. engchi. - 43 -. i n U. v.
(52) 表 4-6：「審查驗證計畫」使用案例說明 使用案例名稱(Use Case Name)：審查驗證計畫. 編號：2.2. 主流程（Main Flow）： －使用者一進入此畫面，系統將自動帶出審查人員(同登入人員)。 －使用者輸入專案代號後，系統自動帶出專案名稱。 －使用者選擇欲確認的文件，系統自動帶出最新版次。 －使用者依系統所提供的審查項目，點選審查結果。 －使用者完成所有審查項目，點選「審查完成」。系統將依彙整審查結果修改. 政 治 大 衍生或替代流程（Extensions or Alternatives）：無。 立資料來源：本研究整理 驗證計畫文件狀態為審查通過或審查未通過。. ‧ 國. 學. 相關畫面展示：. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. - 44 -. i n U. v.
(53) 表 4-7：「審查驗證環境」使用案例說明 使用案例名稱(Use Case Name)：審查驗證環境. 編號：2.3. 主流程（Main Flow）： －使用者一進入此畫面，系統將自動帶出審查人員(同登入人員)。 －使用者輸入專案代號後，系統自動帶出專案名稱。 －使用者選擇審查驗證環境之依據，系統自動帶出最新版次。 －使用者依系統所提供的審查項目，點選審查結果。 －使用者完成所有審查項目，點選「審查完成」。系統將依彙整審查結果修改. 政 治 大 衍生或替代流程（Extensions or Alternatives）：無。 立資料來源：本研究整理 驗證環境之文件狀態為審查通過或審查不通過。. ‧ 國. 學. 相關畫面展示：. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. - 45 -. i n U. v.
(54) 表 4-8：「同仁審查」使用案例說明 使用案例名稱(Use Case Name)：同仁審查. 編號：2.5. 主流程（Main Flow）： －使用者一進入此畫面，系統將自動帶出審查人員(同登入人員)。 －使用者輸入專案代號後，系統自動帶出專案名稱。 －使用者選擇欲進行同仁審查之項目，系統自動帶出最新版次、規模。 －使用者選擇欲進行同仁審查之型態。 －同仁審查項目若有缺失應於缺失處與說明欄位描述。. 政 治 大. －使用者點選「審查完成」時，若無缺失描述，系統將視同審查通過，若有缺. 立. 學. ‧ 國. 失描述則視為審查不通過。 衍生或替代流程（Extensions or Alternatives）：無。 資料來源：本研究整理. ‧. 相關畫面展示：. n. er. io. sit. y. Nat. al. Ch. engchi. - 46 -. i n U. v.
(55) 表 4-9：「分析整體驗證」使用案例說明 使用案例名稱(Use Case Name)：分析整體驗證. 編號：2.6. 主流程（Main Flow）： －使用者一進入此畫面，系統將自動帶出分析人員(同登入人員)。 －使用者輸入專案代號後，系統自動帶出專案名稱。 －使用者依系統所提供的分析項目，進行分析，並點選其分析結果。 －使用者完成分析後，點選「分析完成」。系統將依彙整分析結果修改整體驗 證之狀態為驗證通過或驗證不通過。. 治 政 資料來源：本研究整理大 立. 衍生或替代流程（Extensions or Alternatives）：無。 相關畫面展示：. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 4.3 籌獲確認使用案例分析與說明 依據籌獲確認活動圖（圖 3-9），建立籌獲確認使用案例圖（圖 4-3）。. - 47 -.
(56) 首先在籌獲規劃階段，在籌獲需求發展流程領域之配置契約需求活動中須事 先將乙方需配合的確認活動詳訂於契約內。 在「管理與監控」階段的開始，由乙方的計畫撰寫人撰擬專案確認計畫， 連同其內部的審查紀錄交由甲方審查。審查無誤後，由乙方進行環境的建立 與確認活動。完成的報告再交給甲方，而其後的「驗收」與「移轉」階段則 重覆執行確認活動直到上線與保固完成。 在籌獲的過程中，開發方（乙方）在約定的時間點將會交付相關重要的 產出，為確保其品質，於專案監控流程中，應確實監控廠商工作與產品的進. 治 政 大 勉強接受不良率過高的產品。 立. 度，更進一步實際審查其工作與產品以確保其品質，才不致於在確認活動時. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4-3：籌獲確認使用案例圖 資料來源：本研究整理 依籌獲確認使用案例圖（圖 4-3），發展出各個使用案例（表 4-10、表 4-11 及表 4-12） 。因「上傳確認計畫」 、 「上傳確認報告」 （使用案例編號：3.1 - 48 -.
(57) 與 3.4）與「上傳客戶/契約需求」使用案例說明（表 4-3）相似度頗高，故不 再描述。 隨同「上傳確認計畫」 、 「上傳確認報告」使用案例說明，提供之確認計 畫與報告之建議大綱與驗證計畫與報告雷同，已於 4.2 描述。. 表 4-10：「審查確認計畫」使用案例說明 使用案例名稱(Use Case Name)：審查確認計畫. 編號：3.2. 主流程（Main Flow）：. 政 治 大 －使用者輸入專案代號後，系統自動帶出專案名稱。 立. －使用者一進入此畫面，系統將自動帶出審查人員(同登入人員)。. －使用者選擇欲審查的文件，系統自動帶出最新版次。. ‧ 國. 學. －使用者依系統所提供的審查項目，點選審查結果。. ‧. －使用者完成所有審查項目，點選「審查完成」，系統將依彙整審查結果修改. sit. y. Nat. 確認計畫文件狀態為審查通過或審查不通過。. io. al. n. 相關畫面展示：. 資料來源：本研究整理. Ch. engchi. - 49 -. er. 衍生或替代流程（Extensions or Alternatives）：無。. i n U. v.
(58) 立. 政 治 大. ‧. ‧ 國. 學. 表 4-11：「審查確認環境」使用案例說明. y. Nat. n. al. 編號：3.3. er. io. 主流程（Main Flow）：. sit. 使用案例名稱(Use Case Name)：審查確認環境. i n U. v. －使用者一進入此畫面，系統將自動帶出審查人員(同登入人員)。. Ch. engchi. －使用者輸入專案代號後，系統自動帶出專案名稱。. －使用者選擇審查確認環境之依據，系統自動帶出最新版次。 －使用者依系統所提供的審查項目，點選「審查完成」。系統將依彙整審查結 果修改確認環境之文件狀態為審查通過或審查不通過。 衍生或替代流程（Extensions or Alternatives）：無。 資料來源：本研究整理 相關畫面展示：. - 50 -.
(59) 立. 政 治 大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. - 51 -. i n U. v.
(60) 表 4-12：「分析確認報告」使用案例說明 使用案例名稱(Use Case Name)：分析確認報告. 編號：3.5. 主流程（Main Flow）： －使用者一進入此畫面，系統將自動帶出分析人員(同登入人員)。 －使用者輸入專案代號後，系統自動帶出專案名稱。 －使用者依系統所提供的分析項目，進行分析，並點選其分析結果。 －使用者完成分析後，點選「分析完成」。系統將依彙整分析結果修改確認狀 態為確認通過或確認未通過。. 治 政 資料來源：本研究整理大 立. 衍生或替代流程（Extensions or Alternatives）：無。 相關畫面展示：. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. - 52 -. i n U. v.
(61) 第五章 自評支援 5.1 SCAMPI 評鑑說明 SCAMPI（Standard CMMI Appraisal Method for Process Improvement）是 以 CMMI 為參考模式，所使用的標準評鑑流程，用以衡量組織流程能力的一 把「尺」 ，因為流程改善會牽涉職務作業調整與人事管理，必須要求高階管理 者的加入與嚴守保密與不公開原則，以支持後續流程改善活動。. 政 治 大. SCAMPI Upgrade Team（2006）評鑑的種類分為 A、B 及 C 三類（圖. 立. 學. ‧ 國. 5-1） ，其中只有 A 類才可賦予評鑑的等級，如成熟度等級多少（階段式適用）. B 類別. ‧. 文件與訪談. 文件與訪談. 有. 無. io. 評等. Nat. 證據收集的型態. n. al. 組織涵蓋率. 需要. 最小的 ATM 人數. 4. 評鑑員的要求. 主任評鑑員. Ch. 不需要. e n g2c h i. C 類別 文件或訪談. sit. A 類別. er. 需求. y. 或能力度等級多少（連續式適用）等。. i n U. v. 無 不需要 1. 主任評鑑員或有. 主任評鑑員或有. 經驗的人. 經驗的人. 圖 5-1：CMMI 評鑑的種類 資料來源：翻譯自 SCAMPI V1.2 以 SCAMPI A 來說，完整的評鑑流程（圖 5-2），主要分為三大階：規 劃與準備評鑑、執行評鑑與報告評鑑結果。. - 53 -.
(62) 立. 政 治 大. ‧. ‧ 國. 學 y. sit. Nat. 圖 5-2：SCAMPI A 流程. io. n. al. er. 資料來源：翻譯/彙整自 SCAMPI V1.2：Class A Team Training. Ch 5.2 SCAMPI 評鑑的支援 e. ngchi. i n U. v. 本研究參考 SCAMPI A 的 PIID（ Practices Implementation Index Description；PIID） 範本格式，並參考 Ralf Kneuper(2009)的 PIID 表指引， 檢視本研究的籌獲管理規劃，是否能夠針對籌獲需求發展、籌獲驗證及籌獲 確認流程領域的特定執行方法，由表 5-1、表 5-2 及表 5-3 可以看出，若在籌 獲組織充份執行，應可充份提供三個流程領域特定執行方法的直接證據。. - 54 -.
(63) 表 5-1：籌獲需求發展的直接證據 SG. SP. 可能的直接證據. 可能的資料來源. SG 1 發展客戶需求. SP 1.1 誘導關鍵人員需要. 客戶需求. 客戶需求書. SP 1.2 發展並排序客戶需求. 客戶需求的優先順 序 契約需求. 客戶需求書之「需求順 序」章節 契約需求書 契約需求書之「契約需求 與交付項目對照表」 客戶需求書之「操作性概 念與劇本」章節 使用案例 1.4/1.7 建立客 戶/契約需求分析報告之 畫面 使用案例 1.4/1.7 建立客 戶/契約需求分析報告之 畫面 使用案例 1.5/1.8 確認客 戶/契約需求分析報告使 用案例之畫面. SG 2 發 展 契 約 需 求. SP 2.1 建立契約需求. SG 3 分析與確認需 求. SP 3.1 建立操作性概念與劇本. 契約需求與交付項 目清單 操作性概念與劇本. SP 3.2 分析需求. 需求分析報告. SP 3.3 平衡需求. 需求分析報告. SP 2.2 配置契約需求. SP 3.4 確認需求. 立. n. al. 驗證環境. Ch. SG 3 驗證工作產品. i n U. v. e n g c 驗證程序與準則 hi. SP 1.3 建立驗證程序與準則 SG 2 執 行 同 仁 審 查. sit. io. SP 1.2 建立驗證環境. 驗證工作產品清單. er. SP 1.1 選擇驗證工作產品. y. 可能的直接證據. SP. Nat. SG 1 準備驗證. 表 5-2：籌獲驗證的直接證據. ‧. ‧ 國. 資料來源：本研究整理. 學. SG. 政 治確認紀錄 大. SP 2.1 準備同仁審查. 同仁審查規劃. SP 2.2 執行同仁審查. 同仁審查紀錄. SP 2.3 分析同仁審查資料. 同仁審查紀錄分析. SP 3.1 執行驗證. 驗證結果. SP 3.2 分析驗證結果. 驗證結果分析. 資料來源：資料來源：本研究整理. - 55 -. 可能的資料來源 驗證計畫之「驗證的項 目」章節 驗證計畫之「驗證的 環境」章節 使用案例 2.3 審查驗 證環境之畫面 驗證計畫之「驗證的程序 與準則」章節 驗證計畫之「同仁審查的 準備」章節 使用案例 2.5 進行同仁審 查之畫面 使用案例 2.6 分析整體驗 證報告之畫面 驗證報告 使用案例 2.6 分析整體驗 證報告之畫面.
(64) 表 5-3：籌獲確認的直接證據 SG. SP. 可能的直接證據. 可能的資料來源. SG 1 準備確認. SP 1.1 選擇確認產品. 確認工作產品清單. SP 1.2 建立確認環境. 確認環境. SP 1.3 建立確認程序與 準則 SP 2.1 執行確認. 確認程序與準則. 確認計畫之「確認的項目」 章節 確認計畫之「確認的環境」 章節 使用案例 3.3 審查確認環 境之畫面 確認計畫之「確認的程序與 準則」章節 確認報告. SP 2.2 分析確認結果. 確認結果分析. SG 2 確認產品 或產品組件. 確認結果. 使用案例 3.5 分析確認報告 之畫面. 政 治 大. 資料來源：本研究整理. 5.3 SCAMPI 評鑑支援之確認 立. ‧ 國. 學. 本論文之研究根植於研究生參與國內及世界第一家通過 CMMI-ACQ 模. ‧. 式評鑑之觀察心得，結合指導老師多年來在資訊系統需求規劃之研究心得。 然而因為試行環境之限制，無法在現階段完成支援系流開發並安排第三方確. y. Nat. io. sit. 認本研究概念發展之適用性。同時全世界目前只有二家組織通過 CMMI-ACQ. n. al. er. 評鑑，顯示籌劃管理流程改善之觀念尚未普及，現階段所研究的籌獲管理之. Ch. i n U. v. 觀念，可望降低 CMMI-ACQ 的導入複雜度及 SCAMPI 評鑑支援。. engchi. 這個觀念也可望適用於未來籌獲管理觀念、服務管理及資訊安全等模型 整合之研究，成為規劃資訊組織流程改善資訊需求的工具。因此於後續研究 中再安排評鑑或認證各種模型支援之確認。. - 56 -.
數據
Outline
相關文件
Have shown results in 1 , 2 & 3 D to demonstrate feasibility of method for inviscid compressible flow problems. Department of Applied Mathematics, Ta-Tung University, April 23,
The disadvantage of the inversion methods of that type, the encountered dependence of discretization and truncation error on the free parameters, is removed by
¾真實案例 2：美國政府商業部：透過 知識管理，運用資訊科技來開發專家 知識管理 運用資訊科技來開發專家
朝陽科技大學 資訊與通訊系. 107
Keywords: Mobile ad-hoc network, Cluster manager electing, Fuzzy inference rule, Workload sharing, Backup manager... 致謝 致謝
試驗計劃」 教育局資訊科技教育組 香港大學
本校目前已完工啟用的建築物為行政、理工、教學、宿舍、設
培養具有檔案學基礎知識與文化知識，掌握現代資訊技術的基 本技能，能在檔案館、國家機關和企事業單位的檔案機構、資
