Pittsburgh, PA 15213-3890 適用於發展的能力成熟度整合模式(CMMI-DEV) 版 CMU/SEI-2006-TR-008 ESC-TR-2006-008 為了更佳產品的流程改善 CMMI 產品團隊 August 2006 在著作權下可無條件流通.
This work is sponsored by the . Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the . Department of Defense. Copyright 2006 by Carnegie Mellon University. NO WARRANTY ®THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works. External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent. This work was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at -7013. For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site ( The following service marks and registered marks are used in this document: ≤Capability Maturity Model ≤CMM SM CMM Integration ≤CMMI SM IDEALSM SCAMPI CMMI, CMM, and Capability Maturity Model are registered in the . Patent and Trademark Office. CMM Integration, SCAMPI, and IDEAL are service marks of Carnegie Mellon University.
此文件由美國國防部贊助。軟體工程學院是由美國國防部提供官方基金所成立的研究發展中心。 卡內基美隆大學版權所有2006。 無擔保 卡內基美隆大學軟體工程學院係以文件交付時的狀況提供文件。卡內基美隆大學對任何明示、默示的事情不做任何擔保，其中包括但不限於符合特定用途的擔保和適售性，尤其是使用此文件所產生的結果。卡內基美隆大學對於任何關於免除專利，商標或著作權侵害不做任何擔保。 使用此報告內的任何商標不能以任何方式侵害商標所有人的權利。 內部使用。複製此文件或利用此文件衍生的文件，只要版權及無擔保的聲明包含於所有的複製文件及衍生文件內，可允許於內部使用。 外部使用。複製此文件或利用此文件衍生的文件於外部或商業用途，應向軟體工程學院授權中心提出申請。 此文件是卡內基美隆大學軟體工程學院，官方提供資金成立的研究發展中心，執行聯邦政府合約號碼FA8721-05-C-0003所產生。美國政府擁有免技術權利金政府使用許可，以全部或部分或任何方式使用，複製或公布此文件。或根據版權許可條款-7013允許他人做相同的事。 有關於購買SEI報告複本的資訊，請拜訪我們網站的出版品部分( 此文件使用下列服務標章及註冊商標： ≤Capability Maturity Model ≤CMM SM CMM Integration ≤CMMI SM IDEALSM SCAMPI CMMI、CMM及Capability Maturity Model註冊於美國專利商標局。 CMM Integration、SCAMPI及IDEAL是卡內基美隆大學的服務標章。
CMMI中文版發刊詞 面對產業與市場全球化的變革，產業快速回應市場變化的不二法便是回歸檢視核心的獲利關鍵能力—流程。穩定的流程，忠實反應出企業的品質改善脈絡、成本降低策略與縮短上市速度的能力，因此，掌握並改善流程即為企業創造獲利空間的利器。 CMMI嚴謹規範不僅符合持續改善的精神，著重流程、講究細節更是大型系統工程架構發展的基礎。卡內基美隆大學軟體工程學院，協同政府機構、產業界共同研究發展CMMI模式，於二十多年前首次將品質管理的概念帶入軟體發展流程管理，迄今仍秉持遲續改善精神不斷發展演進，將全球一流頂尖企業之最佳執行方法加入模式中，其卓越之貢獻可由逐年遞增的引用組織數及回饋改善成果報告中窺見。財團法人資訊工業策進會長期投入軟體工程的研究與推展工作，於2005年獲得SEI支持出版CMMI v 中文版，對華文社會在導入、應用CMMI提供極大的便利，並促進品質與生產力的提昇。 CMMI v 版以中文版為基礎，歷時14個月，並經內外部及獨立審查，終於完成；特別要對本書的外部審查委員、獨立審查人員及翻譯小組致意，感謝他們對本書出版的投入，期各界對軟體產業有識之士共同關注並持續協助推動軟體品質提昇。 財團法人資訊工業策進會 執行長 陳銘憲 2007年11月
CMMI-DEV中文版序 產業關鍵之鑰-軟體 資訊科技發展以實現人類之夢想而不斷創新精進。伴隨著高度資訊化的生活及多樣化的科技產品，從瞬息萬變的市場處處可見軟體的影響力，其可謂為滿足功能需求的關鍵之鑰。軟體生命週期隨著市場快速變化而趨短，企業面臨著需要品質優良、快速上市、成本精準掌控的考驗，因此企業參與全球化競爭，其軟體工程的精進修練已成必要。 CMMI是美國國防部委託卡內基美隆大學軟體工程學院(SEI)發展出來的，作為採購者評估供應者(發展者)的流程能力度與組織成熟度的標準，也可做為廠商提升產品(系統、軟體、硬體)發展流程管理水準的參考。自1991年起CMMs陸續發展應用於許多專業領域，較著名的包含了系統工程、軟體工程、軟體採購、及整合的產品與流程發展(Integrated Process & Product Development)等模式。由於使用單位快速增加及實務應用需要而於2000年整合軟體工程、系統工程、整合式產品開發等專業領域而發表了整合式模式CMMI 版，於2002年加入委外作業管理後而為版。 CMMI持續其不斷改進的精神，在2006年8月發表CMMI 版，這個版本應用「群集」(constellations)概念，以一組核心組件的集合，提供高度共通內容給特定應用模式，將最佳執行方法擴展至新領域，包含2006年公佈的CMMI-DEV發展模式(CMMI-Development)、2007年11月發表的CMMI-ACQ採購模式(CMMI-Acquisition)，以及正在規劃發展中的服務模式(CMMI-Service)。此重要改變的意義在於同步提昇供需雙方在發展、採購及服務等各面向的流程管理能力，以達到雙贏的效果。 CMMI-DEV發展模式，係以發展者角度規範思考流程模式，目的是為了協助組織改善其產品與服務之發展及維護流程。與前版相較其內容的差異部份主要如下：1.將階段式與連續式兩種表述合併以一體呈現；2.新增並強化硬體發展相關範例；3. 簡化整合的產品與流程發展資料；4. 納入委外作業管理延伸在基礎模型中；其他如限定評鑑結果的最長效期為三年。中文版的製作除隨英文版做上述內容變更外，也就版之勘誤更正並增強譯文之閱讀性。
CMMI-DEV 中文版的製作過程依循嚴謹的程序。在SEI的授權下，我們依據翻譯成員之擅長領域分為專案管理、流程管理、工程以及支援等四個翻譯小組，期間以同儕審查、查核會議及討論的方式完成初稿，然後邀請外部專家審查。外部專家意見涵括文意、表達、詞性、用字甚至標點符點等282則。之後再經獨立審查小組之審查。翻譯小組對各方意見均逐一處理，往返推敲再修正定稿。 CMMI –DEV 中文版已製作完成，預期可對全球軟體產業發展多有助益。在此，謹向所有參與人員致敬，謝謝他們的貢獻。 財團法人資訊工業策進會 資訊工程研究所 所長 范長康 2007年11月
中文版參與人員 指導人員 吳明機 經濟部工業局 羅達生 經濟部工業局 廖振資 經濟部工業局 綦淑媛 經濟部工業局 外部審查 范長康 財團法人資訊工業策進會 張子龍 財團法人資訊工業策進會 張文貴 私立東海大學 陳振楠 關貿網路(股)有限公司 莊順吉 昇峰資訊(股)有限公司 彭永興 工業技術研究院 鼎升數位科技(股)有限公司 中冠資訊(股)有限公司 獨立審查 洪肇奎 國立成功大學 刑承中MITRE Cooperation 陳杏村 芝加哥大學 翻譯團隊 李治平 財團法人資訊工業策進會 林文質 財團法人資訊工業策進會 陳莉莉 財團法人資訊工業策進會 黃永祥 財團法人資訊工業策進會 黎兆濱 財團法人資訊工業策進會 劉景華 財團法人資訊工業策進會 歐世文 財團法人資訊工業策進會
CMMI for Development Version 前言 ®能力成熟度整合模式 (Capability Maturity Model ®Integration,CMMI)是一個針對產品與服務發展的流程改善成熟度模式。它包含發展與維護活動的最佳執行方法，涵蓋產品從起始到交付與維護的生命週期。 最新版本的CMMI模式整合了發展與維護所必需的知識體系，例如軟體工程、系統工程、硬體與設計工程、工程服務與採購等，這些在過去都是各別闡述。適用於發展的CMMI (Capability Maturity ®Model Integration for Development, CMMI-DEV )取代之前適用於軟體工程及系統工程的CMMI (CMMI-SE/SW)，以真實地反映這些知識體系的廣泛整合，以及組織的模式應用。CMMI-DEV對於產品與服務的發展與維護活動，提供廣泛整合的解決方案。 CMMI-DEV 版是利用CMMI的「群集」概念，持續更新CMMI 版。「群集」提供一組核心流程組件，能夠以附加流程的方式，來擴充成為具備高共通內容的特定應用模式(如CMMI-DEV, CMMI-ACQ等)。其中CMMI-DEV是針對發展領域，最早公佈的特定應用模式。 目的 CMMI-DEV的目的是為了協助組織改善其產品與服務之發展與維護流程，它源自於CMMI架構的最佳1執行方法集合。針對特定領域，CMMI架構容許產生多個模式、訓練課程與評鑑方法，以支援CMMI產品系列的發展。 1 CMMI架構是基本結構，用來組織CMMI組件，並且將其整合成為CMMI群集與模式。 前言 i
CMMI for Development Version 群集是針對某個領域的CMMI組件集合，其中包含模式、訓練教材，以及評鑑相關文件。目前版本的模式架構支援三個已規劃的群集：發展、服務與採購。 本份文件包含CMMI-DEV群集，並且包含基本的CMMI-DEV與附加IPPD的CMMI-DEV(CMMI-DEV+IPPD)。「附加」是將特定額外內容擴充到群集的機制。 假如你目前沒有使用IPPD，就忽略被標記為「IPPD 附加」的資訊，你使用到的模式即為CMMI for Development模式。 與CMMI 版不同之處，是用單一模式文件描述流程改善的階段式與連續式表述，而不是用個別文件描述階段式與連續式表述。將這兩種表述的模式內容統一描述的做法，最早開始於CMMI: Guidelines for Process Integration and Product Improvement這本書中。感謝Peter Gordon、出版商Addison-Wesley與本書作者Mary Beth Chrissis、Mike Konrad與Sandy Shrum，使我們能夠使用這本書的手稿，當做發展CMMI 版本的基礎 [Chrissis 2003]。 致謝 許多菁英參與CMMI 產品系列的產品團隊，三個主要參與這個發展的群組是推動組、產品團隊、建構管制委員會。 推動組指引及核准產品團隊的計畫，提供CMMI專案重要議題的諮詢，確認包含各種不同有興趣的社群。 產品團隊撰寫、審查、修訂、討論及認可CMMI產品系列的架構及技術內容，包括架構、模式、訓練及評鑑教材。發展活動是根據各種不同的來源。這些來源包含推動組所提供的一份A-規格與每一次釋 前言 ii
CMMI for Development Version 出之指引詳述、來自於使用者社群的變更請求、來源模式以及來自於其它關鍵人員的草案 [SEI 2004]。 建構管制委員會是一個控制CMMI模式與Introduction to CMMI訓練課程變更的正式機制。因此，此群組經由審查所有被提議的基準變更，以及只核准滿足已界定議題及符合下一個版本準則的變更，來確保產品系列生命週期的完整性。 附錄C列出參與發展CMMI 版本之群組成員。 讀者群 本模式的讀者群包括任何對發展與維護環境之流程改善有興趣的人。無論你是否熟悉能力成熟度整合模式的內容或是你正在尋求資訊以開始進行你的改善工作，這份文件都將有助於你。 2本模式的預期讀者包含想要使用評鑑.來檢視它們目前所處情況的人、已經知道該從哪裡進行改善的人、剛剛開始進行的人以及想要對CMMI for Development群集有一般性瞭解的人。 本文件的組織 3本文件可以由SEI網站取得以提供組織流程改善指引。它主要被組織為三個主要部份： • 第一單元—關於CMMI for Development • 第二單元—一般目標、一般執行方法以及流程領域 • 第三單元—附錄與詞彙 2評鑑是經由受過專業訓練之團隊針對一到多個流程進行審視，並使用一個參考模式(例如：CMMI)來當做決定優勢與劣勢的基準。 3SEI的網站位於。 前言 iii
CMMI for Development Version 第一單元「關於CMMI for Development」包含以下五章： • 第一章，「簡介」，提供一個CMMI與CMMI for Development群集的廣泛概觀。本章以流程改善的概念來引導你，並且描述用於流程改善的模式歷史以及不同的流程改善方法。 • 第二章，「流程領域組件」，描述CMMI for Development流程領域下的所有組件。 • 第三章，「試著合而為一」，組合模式組件與解釋成熟度等級及能力度等級的概念。 • 第四章，「流程領域間的關係」，針對CMMI for Development下所有流程領域的互動關係做更深的剖析。 • 第五章，「使用CMMI模式」，描述CMMI在流程改善與標竿學習上的採用與使用路徑。 第二單元，「一般目標、一般執行方法以及流程領域」，包含所有CMMI for Development群集必要的及期望的組件。它也包含相關助益的組件，包括組件名稱、細部執行方法、註釋與典型的工作產品。 第二單元包含23節。第一節包含一般目標與一般執行方法，說明它們如何被使用以及描述它們與流程領域的關係。其餘的22節，每一節都描述一個4CMMI for Development的流程領域 。為了使這些流程領域容易被找到，它們是以首字母的縮寫字來排序。每一節均包含目標描述、最佳執行方法與範例。 第三單元「附錄與詞彙」包含4個資訊資源： • 附錄A，「參考資料」，提供參考資訊以便你可以找到有關CMMI for Development的原始紀 4「流程領域」是在一個區域中相關連的最佳執行方法群集，當被共同實行時，會滿足一組被認為重要且具有顯著改善該區域的目標。我們將會在第2章詳述這個概念。 前言 iv
CMMI for Development Version 錄，例如報告、流程改善模式、產業標準及書籍等。 • 附錄B，「縮寫字」，定義本文件所使用的縮寫字。 • 附錄C，「CMMI for Development專案的參與者」，包含參與CMMI for Development 版本發展的人員及組織名單清單。 • 附錄D，「詞彙」，定義CMMI所使用的許多術語。 如何使用本文件 無論你是剛接觸流程改善與CMMI或是已經熟悉CMMI，第一單元都可以幫助你瞭解為什麼CMMI for Development是用來改善發展與維護流程的最佳模式。 剛接觸流程改善的讀者 ®假如你不熟悉流程改善或是CMM的內容，我們建議你先開始閱讀第一章，「簡介」。第一章將會給你一個流程改善的整體概念，並且解釋CMMI是什麼。 接下來，瀏覽第二單元，包含一般目標、一般執行方法和特定目標及特定執行方法，以察覺包含在此模式下的最佳執行方法之範圍。將注意力放在每一節要開始前的目的與前言說明。 在第三單元，在開始使用CMMI for Development前，仔細察看附錄A的參考文獻以及挑選部份你認為有助於你閱讀的額外原始資料。徹底閱讀縮寫字與詞彙以熟悉CMMI的用語，然後，回到第二單元做更細部的閱讀。 前言 v
CMMI for Development Version 有流程改善經驗的讀者 假如你剛接觸CMMI，但是有其它流程改善模式的經驗，例如軟體能力成熟度模式版本、系統工程能力成熟度(例如EIA 731)，你可以立即認知到有許多相似之處 [EIA 1998]。 我們建議你閱讀第一單元來瞭解CMMI與其它流程改善模式的差異，但是你可能想要更快速的閱讀部份章節。簡略的閱讀第二單元時，從模式中找出你會試行的最佳執行方法。識別熟悉的內容，可以讓你感覺什麼是新的，以及哪些模式中的內容是你已經知道的。 接著下來，審視詞彙以瞭解相同名稱術語在本文件與你所知道的流程改善模式中的定義差異。許多內容將有可能重複，但是他們可能有部份差異。 熟悉能力成熟度整合模式的讀者 假如你在之前已經審視或是使用過CMMI模式，你可以很快的認識CMMI所討論的內容以及所呈現的最佳執行方法。版本與版本的差異被更細微的解釋在SEI網站上的release notes。這些差異反映版本使用者所提出的改善建議。 以下是版本所做的改善： • 兩種表述一體呈現。 • 移除進階執行方法與一般共同特徵的內容。 • 一般目標與一般執行方法的描述移到第二單元。 • 新增硬體強化。 • 統一所有的詞彙定義。 • IPPD執行方法的合併與簡化。不再有任何單獨處理IPPD的流程領域。 前言 vi
CMMI for Development Version • 供應商協議管理(SAM)與整合的供應商管理(ISM)被合併，並移除供應商來源。 • 一般執行方法詳細說明新增第三級的一般執行方法。 • 新增流程領域如何支援一般執行方法實行的解釋。 • 新增內容以確保專案開始時可以佈署標準流程。 回饋資訊 你可以經由各種不同的管道來找到有關於CMMI的額外資訊，例如：CMMI模式的背景與歷史及使用CMMI 模式的效益。這些管道被列在附錄A以及被發表在CMMI網站— [SEI 2]。 歡迎任何有關改善CMMI產品系列的建議，有關如何提供回饋的資訊，請參閱CMMI網站： 。如果有任何問題，請送電子郵件到 cmmi-comments@。前言 vii
CMMI for Development Version 目次 前言 i 目的 致謝ii 讀者群iii 本文件的組織iii 如何使用本文件v 剛接觸流程改善的讀者 有流程改善經驗的讀者vi 熟悉能力成熟度整合模式的讀者vi 回饋資訊vii 關於CMMI for Development 1 關於能力成熟度模式3 能力成熟度整合模式的演進5 適用於發展的CMMI7 CMMI for Development的範圍8 IPPD附加的群組 解決CMM家族的差異看法 選擇表述9 連續式表述 階段式表述10 連續式與階段式表述的比較10 你的決策因素11 為什麼不是兩種表述? 12 你的流程改善方法13 情節113 情節214 必要的、期望的及助益的組件16 必要的組件16 期望的組件16 助益的組件 17 第二單元相關的組件17 流程領域17 目的18 前言19 相關流程領域19 特定目標19 一般目標19 特定目標與執行方法摘要 20 viii 目次
CMMI for Development Version 特定執行方法 20 典型的工作產品20 細部執行方法21 一般執行方法21 一般執行方法的詳細說明21 支援助益的組件22 註釋22 範例22 強化 23 參考資料23 編碼系統24 印刷慣例24 表述的特定內容27 附加28 瞭解等級29 連續式與階段式表述的結構 30 瞭解能力度等級33 能力度第0 級：不完整級33 能力度第1級：執行級34 能力度第2級：管理級34 能力度第3級：調適級34 能力度第4級：量化管理級 35 能力度第5級：最佳化級35 能力度等級的進展35 瞭解成熟度等級36 成熟度第1級：初始級37 成熟度第2級：管理級37 成熟度第3級：已定義級 38 成熟度第4級：量化管理級38 成熟度第5級：最佳化級39 成熟度等級的進展39 流程領域42 一般目標與執行方法45 表述比較47 對等的階段式 47 CMMI流程領域的四種類別52 流程管理53 基本流程管理類流程領域53 進階流程管理類流程領域55 專案管理56 基本專案管理流程領域 56 進階專案管理類流程領域58 工程59 工程類流程領域的遞迴與反覆63 目次 ix
CMMI for Development Version 支援64 基本支援類流程領域 64 進階支援類流程領域66 採用能力成熟度整合模式67 你的流程改善計畫68 影響你計畫的選擇68 能力成熟度整合模式69 使用能力成熟度整合模式的評鑑 70 能力成熟度整合模式的評鑑需求70 SCAMPI評鑑方法71 評鑑考量 71 能力成熟度整合模式的相關訓練73 一般目標與一般執行方法及流程領域 74 一般目標及一般執行方法76 概述76 流程制度化76 已執行流程77 已管理流程77 已調適流程78 已量化管理流程 79 最佳化流程80 流程間的關係81 一般目標及一般執行方法82 應用一般執行方法95 支援特定執行方法的流程領域 96 原因分析與解決方案105 建構管理122 決策分析與解決方案142 整合的專案管理 + IPPD 158 度量與分析195 組織創新與推展218 組織流程定義+ IPPD 242 組織流程專注268 組織流程績效291 組織訓練307 產品整合326 專案監控348 專案規劃364 流程與產品品質保證 395 量化專案管理408 需求發展437 需求管理460 風險管理473 x 目次
CMMI for Development Version 供應商協議管理 496 技術解決方案518 確認549 驗證564 附錄與詞彙584 附錄A. 參考資料586 公開的資料586 定期更新的資料590 附錄B. 縮寫字591 附錄C. CMMI-DEV專案參與人員 594 產品團隊594 模式團隊成員594 SCAMPI 更新團隊成員595 訓練團隊成員595 架構團隊成員595 硬體團隊成員596 試行團隊成員596 品質團隊成員597 贊助者597 推動組597 推動組成員 597 官方推動組成員598 推動組支援：採購598 推動組支援：變更管制委員會 598 變更管制委員會598 變更管制委員會成員598 無投票權變更管制委員會成員599 D.詞彙600 目次 xi
CMMI for Development Version 第一單元 關於CMMI for Development 關於 CMMI for Development 1
CMMI for Development Version 1 簡介 現在，愈來愈多企業想要使產品和服務的交付做得更好、更迅速與更便宜。同時，在二十一世紀的高科技環境裡，幾乎所有的組織都發現到所發展的產品和服務越來越複雜。現今，一家企業通常不會發展產品與服務的所有組件。比較常見的是，一部份組件自行發展而另一部份組件採購，然後將所有的組件整合成最終產品或服務。組織必須能夠管理與控制這樣複雜的發展與維護流程。 現今，這些組織需要一個整合方法，解決牽涉到企業整體環境的問題。組織資產的有效管理是經營成功的關鍵。本質上，這些組織是產品及服務的發展者，需要一個管理發展活動的整合方法，作為達成經營目標的部分方法。 在目前的市場上，有成熟度模式、標準、方法論與指引，可以協助組織改善經營方式。但是，大多數可利用的改善方法專注於經營的特定部分，並沒有針對許多組織現今所面對的問題採取系統的方法。由於專注於改善經營上的一個領域，這些模式不幸地使組織永遠存在高煙囪(難以溝通)和障礙。 ®能力成熟度整合模式(Capability Maturity Model ®Integration, CMMI)憑藉優越專業領域的整合模式，提供一個機會來避免或排除這些高煙囪(難以溝通)和障礙。CMMI for Development包含處理應用於產品及服務的發展與維護活動之最佳執行方法。它處理涵蓋產品生命週期從構思到交付與維護的執行方法。強調建立與維護整體產品所必需的工作。 簡介 2
CMMI for Development Version 關於能力成熟度模式 在協助組織發展與維護品質產品及服務的研究中，SEI發現，組織可以專注數個改善經營的維度。圖說明組織一般會專注的3個重要維度：人員、程序與方法，以及工具與設備。 定義工作關係的定義工作關係的程序和方法 程序與方法 有技能、訓練和積極的人員 圖 三個重要的維度 但是什麼將一切都結合在一起呢？答案是你組織中所使用的流程。流程允許你調校你執行的經營方式，允許你處理擴大規模，並提供一個方式，整合如何讓事情做得更好的知識。流程允許你善用你的資源與檢視經營趨勢。 這不是說人員與技術不重要。我們現今生活的世界，技術有秩序的每十年改變一次。同樣，人員在事業生涯中一般會在多家企業工作。我們生活在一個動態的世界。專注於流程，提供處理世界每次變動所需要的基礎建設，以及極大化人員的生產力，並且讓技術的使用更具有競爭力。 製造業早就認知到流程的效果與效率之重要性。今日，許多製造業與服務業的組織認知到品質流程的重要性。流程透過協助人員更敏捷的工作而非費力簡介 3
CMMI for Development Version 工作及一致性改善，來幫助組織人員符合經營目標。有效的流程也提供導入與使用新技術的工具，以符合組織的經營目標。 在1930年代，瓦特．蕭華德開始利用統計品質管制原理，致力於流程改善 [Shewhart 1931]。這些原理被威廉．愛德華．戴明[Deming 1986]、菲力普．克勞斯比[Crosby 1979]、約瑟夫．朱蘭[Juran 1988]重新定義。瓦玆．韓福瑞、羅恩．雷迪斯及其它人開始在IBM與SEI [Humphrey 1989]內延伸這些原理至軟體。韓福瑞的書「管理軟體流程，Managing the Software Process」提出基本原理與觀念的描述，有許多成為能力成熟度模式的基礎。 SEI認定流程管理的前提是「一個系統或產品的品質會高度受到發展與維護它的流程品質影響」，並且定義CMMs來具體化這個前提。這個前提裡的信念在全世界的品質活動中都可以得見，國際標準組織/國際電子技術委員會(ISO/IEC)標準的內容就是一個證據。 CMMs專注於改善組織的流程。它們包含一到多個專業領域之有效流程的必要元素，並且描述由混亂且不成熟的流程到專業且可提昇品質與效果之成熟流程的演進改善途徑。 SEI首先針對軟體組織設計能力成熟度模式，並出版一本書「The Capability Maturity Model: Guidelines for Improving the Software Process」 [SEI 1995]。 SEI的書將幾乎是一個世紀以前的原理應用在持續流程改善。這個流程改善方法的價值已經通過時間考驗。組織已有提升生產力與品質及更精確與可預測時程與預算的經驗[Gibson 2006] 。 簡介 4
CMMI for Development Version 能力成熟度整合模式的演進 自1991年後，CMMs開始在各種專業領域上發展。一些比較著名的模式包含系統工程、軟體工程、軟體採購、人力管理及發展，以及整合產品與流程發展(IPPD)。 雖然這些模式已經被證實對不同產業的許多組織有益，然而使用多個模式是有問題的。許多組織想要將它們的改善成果擴展到組織中的其它群組，然而每個群組使用的特定專業領域模式的差異，包含架構、內容與方法，卻限制這些組織改善成功的能力。再者，使用未經組織內及跨組織整合的模式，就訓練、評鑑和改善活動而言，是昂貴的。 SMCMMI專案的成立旨在釐清使用多種能力成熟度模式的問題。CMMI產品團隊初始的任務是整合三個來源模式： 1. 軟體能力成熟度模式(SW-CMM) 版草案C [SEI 1997b] 52. 系統工程能力模式(SECM) [EIA 1998]. 3. 整合產品發展能力成熟度模式(IPD-CMM) 版 [SEI 1997a] 將這些模式整合成單一的改善架構，以供尋求企業全面流程改善的組織使用。 選擇這三個來源模式，是因為它們被廣泛的採用於軟體及系統工程社群，以及它們對組織流程改善的不同方式。 採用具普遍性且被重視的模式作為來源資料，CMMI產品團隊創造一組緊密結合的整合模式，此模式既能被目前使用來源模式者採用，又能被那些對能力成熟度模式概念尚生疏者所採用。 因此，CMMI是SW-CMM、SECM與IPD-CMM的演進結果。 5電子工業聯盟731(EIA 731)也肯定CMMI。 簡介 5
CMMI for Development Version 發展一組整合模式，不僅是單純地將現有的模式組合起來。藉由使用提升共識的流程，CMMI 產品團隊建立可容納多種專業領域，並有足夠彈性以支援不同來源模式方法的架構 [Ahern 2003]。 圖 : 能力成熟度模式家族的歷史 自CMMI 版本正式發表後，我們已經看到這個改善架構可以被應用於其它有興趣的領域 [SEI 2002a, SEI 2002b]。為了應用到多個有興趣的領域，這個架構將最佳執行方法分群到我們所謂的「群集」。群集是建立模式、訓練教材與評鑑文件之CMMI組件的集合。 最近，CMMI模式架構已經改良，以支援多個群集，以及群集與其成員模式間分享最佳執行方法。從兩個新群集開始工作：一個是針對服務（CMMI for Services），另一個是針對採購（CMMI for Acquisition）。雖然CMMI for Development加入了服務發展，包含組件、消耗品與人員的組合，以滿足服務需求，它仍不同於規劃中專注於服務交付的CMMI for Services。在2006年以前，於社群中所使用的CMMI模式，現在可視為CMMI for Development群集的一部份。 簡介 6
CMMI for Development Version 適用於發展的CMMI CMMI for Development群集包含2個模式：CMMI for Development + IPPD與CMMI for Development（不包含IPPD）。這兩個模式共享許多內容，這些共享的領域是完全相同的。然而，CMMI for Development + IPPD包含IPPD附加的目標與執行方法。 目前，只有一個模式已經被發表。在CMMI for Development +IPPD模式中包含群集內全部完整且可以利用之執行方法，你可以從這個內容取得其它模式。假如你現在沒有使用IPPD，請忽略標示為「IPPD附加」的資訊，即你使用的是CMMI for Development模式。假如出現需求或是擴展發展群集，這個架構允許產生與發表其它模式。 CMMI for Development是這三個來源模式的指定繼承模式。SEI已經淘汰軟體能力成熟度模式與IPD-CMM。EIA已經淘汰SECM。這三個模式由CMMI for Development接替。 CMMI模式的最佳執行方法已經過了廣泛的審查流程。CMMI 版本經過公開審查並在試行活動中使用。 CMMI產品團隊評估超過3000個變更請求，以建立CMMI 版本。不久之後，發表細微修正的CMMI 版本。 版本包含來自於初期使用回饋的改善指引，公開審查所提交超過1500個變更請求，以及來自於變更控制流程的數百個意見。 CMMI 版本是經由CMMI使用者所提交將近2000個變更請求，當做來源所發展出來的。這些變更請求中，有超過750個是與CMMI的內容直接相關。如同你所見到的，不只是CMMI被廣泛的採用，CMMI也從所收到的社群回饋進行改善。 簡介 7
CMMI for Development Version CMMI for Development的範圍 CMMI for Development是一個涵蓋應用於產品與服務之發展與維護活動的參考模式。許多產業的組織，包含航太產業、銀行產業、電腦硬體產業、軟體產業、國防產業、汽車製造產業與電信產業，使用CMMI for Development。 CMMI for Development群集中的模式包含使用在發展與維護的執行方法，涵蓋專案管理、流程管理、系統工程、硬體工程、軟體工程與其它支援流程。CMMI for Development + IPPD模式也涵蓋整合團隊使用於發展與維護活動。 IPPD附加的群組 在CMMI中，「附加」使用於包含特定使用者有興趣的內容，在CMMI for Development群集中，包含處理IPPD的附加內容。 附加IPPD群組涵蓋IPPD方法，包含幫助組織在產品生命週期中，達到相關關鍵人員即時合作的執行方法，以滿足客戶需要、期望與需求 [DoD 1996 ] 。當使用支援IPPD方法的流程時，你應該將這些流程與組織的其它流程整合。為了支援那些使用與IPPD相關的流程，CMMI for Development群集允許組織隨意地選擇附加IPPD群組。 當你選擇CMMI for Development + IPPD，你選擇的是CMMI for Development模式，並額外加上所有的IPPD附加。當你選擇CMMI for Development，你選擇的模式不包含IPPD附加。為了簡潔文件，本文件第一單元中，我們使用「CMMI for Development」可能是這些模型中的任何一個。 解決CMM家族的差異看法 能力成熟度模式的定義允許社群發展模式，以支援不同的流程改善方法。只要一個模式對一或多個的 簡介 8
CMMI for Development Version 專業領域包含有效流程的必要元素，並且描述由混亂之不成熟流程到有紀律且可改善品質與效果之成熟流程的演進改善途徑，它就可視為是能力成熟度模式。CMMI使用兩種不同的表述：連續式與階段式，協助你進行流程改善與評鑑。 連續式表述協助組織選擇一個流程領域（或一組流程領域）和改善與其相關的流程。這個表述使用能力度等級，描述與個別流程領域有關的改善。 階段式表述使用預先定義的幾組流程領域，以定義組織流程改善的途徑，這個改善途徑使用成熟度等級描述。每一個成熟度等級提供一組流程領域，描述不同的組織行為。 選擇表述 假如你對流程改善沒有經驗，並且不熟悉階段式或連續式表述，無論你選擇哪一個表述，你都不會出錯，因為有許多有根據的理由指出，可以選擇兩者中的任何一個表述。 假如你已經使用能力成熟度模式，並且熟練一個特定的表述，我們建議你繼續使用這個表述，因為它將使得轉換到能力成熟度整合模式的過程更容易。當你完全對能力成熟度整合模式滿意，你才能決定使用其它的表述。 因為每一個表述都有其優越之處，有些組織會在其改善專案的不同時間點上，使用兩種表述解決特定的需求。在接下來的章節中，我們提供每一個表述的優點與缺點，幫助你決定哪一個表述對你的組織是最好的。 連續式表述 當使用CMMI模式進行流程改善時，連續式表述可提供最大的彈性。一個組織可以選擇改善單一流程相關之問題點的績效，或是可以使用多個領域以密簡介 9
CMMI for Development Version 切配合組織的經營目標。連續式表述也允許一個組織將不同的流程改善至不同的等級。但組織在選擇上仍有一些限制，因為有一些流程領域是彼此相依的。 假如你知道在你的組織中需要改善的流程，以及瞭解CMMI中流程領域間的相依性。對你的組織而言，連續式表述是一個好的選擇。 階段式表述 階段式表述提供系統化與結構化的方式，一次一個階段達到以模式為基礎的流程改善。達成每一個階段可確保有足夠的流程基礎建設，可做為下一個階段流程改善的基礎。 流程領域是以成熟度等級組織，並且對流程改善做一些推測工作。階段式表述根據成熟度等級規定執行流程改善的順序，它定義一個組織由初始級到最佳化級的改善路徑。達到每一個成熟度等級可確保有足夠的流程基礎建設，可做為下一個成熟度等級的基礎，並且允許持續與漸進的改善。 假如你不知道要選擇哪一個流程開始進行改善，階段式表述對你而言是一個好的選擇。它給你一組特定的流程，針對每一個階段進行改善。這組流程的決定，是來自於十多年流程改善的研究和經驗。 連續式與階段式表述的比較 表比較每一個表述的優勢，能夠協助你決定哪一種表述適合你的組織。 簡介 10
CMMI for Development Version 表連續式與階段式表述的優勢比較 連續式表述 階段式表述 授予明確的自由度來選擇使組織有一個已定義且被最符合組織經營目標與減證實的改善路徑 少組織風險範圍的改善順序 增加每一個流程領域能力專注在一組流程領域，此度透視度 組流程領域為每一成熟度等級的特徵，提供組織特定的能力 允許對不同流程執行不同以簡單的型式彙總流程改等級的改善 善結果—單一成熟度等級數目 一種新方法仍未有數據證建立在一個相對長期的使明其與投資報酬率有關連 用歷史，包含個案研究與數據以證明投資報酬率 你的決策因素 當選擇表述時，有三種類型的因素可能影響你的決定：經營、文化與現況。 經營因素 當組織在經營目標上有成熟知識，很可能有一個強大的流程對映到其經營目標。這樣的組織可能發現連續式表述有利於評鑑其流程，以及決定組織流程支援及符合經營目標的程度。 如果組織產品線專注於決定要改善跨組織的流程，它最好使用階段式表述。階段式表述將幫助組織在改善上選擇要專注改善的重要流程。 同一個組織也可能利用產品線來改善流程。那樣的話，它可能選擇連續式表述—每一個產品線有不同的能力度評鑑等級。這兩種表述都是有效的。最重簡介 11
CMMI for Development Version 要的考量是哪些經營目標是你希望你的流程改善專案要支援的與這些經營目標如何用兩種表述調校。 文化因素 當選擇表述與組織推展流程改善計畫的能力有關時，要考慮文化因素。例如，如果企業文化是以流程為基礎且對流程改善有經驗，或是有特定流程需要快速地改善，組織就可能選擇連續式表述。若組織缺乏流程改善經驗，可能選擇階段式表述，階段式表述提供要發生的變更及順序的額外指引。 現況 假如一個組織對其它模式有階段式表述的經驗，當使用CMMI時，它可能希望繼續使用階段式表述，尤其是組織已經跨組織投入資源及推展流程，這與階段式表述相關。會繼續使用連續性表述亦是如此。 為什麼不是兩種表述? 不管是使用於流程改善或評鑑，這兩個表述是設計來提供相同的結果。這兩種表述的CMMI模式內容幾乎相同。因此，組織只要選擇一個表述即可。 事實上，組織可能發現此二種表述是通用的。組織很少完全地實行前述的某一種表述。在流程改善上成功的組織經常定義一個改善計畫，此改善計畫專注在組織的唯一需要，然後使用階段式與連續式表述的原則。 例如，選擇階段式表述並位於成熟度第1級的組織，常常會在實行成熟度第2級的流程領域時，執行位於組織成熟度第3級下的組織流程專注流程領域。另一個例子，組織選擇連續式表述，指引其內部流程改善工作，然後選擇階段式表述進行評鑑。 簡介 12
CMMI for Development Version 你的流程改善方法 為了要展示如何使用這個模式，讓我們看兩個不同的情節。情節1是一個電子系統開發者想要使用連續式表述來改善它的產品發展流程。情節2是一個已經使用IPPD與軟體能力成熟度模式的軟體開發公司，現在想要使用能力成熟度整合模式，這個公司目前達到軟體能力成熟度的第3級。 情節1 在情節1中，你使用連續式表述，並選擇對你的經營目標是重要的流程。由於有22個流程領域可以選擇，當在開始時，過多的流程領域通常使我們會不知如何著手。你需要縮小你的焦點。舉例來說，你也許發現到競爭對手的產品總是比你的產品還要早發行，因此你可能選擇專注於改善你的工程與專案管理流程。 建立在這個決定上，選擇所有的工程流程領域當成一個開始點：產品整合、需求發展、需求管理、技術解決方案、確認與驗證。你也選擇專案規劃與專案監控。 你在此點上決定一開始要專注八個流程領域仍然是過多的，然後你決定需求流程是問題的真實所在。所以你選擇需求發展與需求管理流程領域，開始你的改善工作。 接著下來你要決定需求領域需要改善到多好。你有任何的流程已經在需求領域上嗎？如果你並沒有，你的流程改善目標可能要從能力度第1級開始。 您的每一個專案都有需求發展及管理流程，但是它們卻不是已管理的流程？舉例來說，政策、訓練和工具無法執行以支援流程。假如您有需求流程，但是它們並沒有支援的基礎建設，您的流程改善目標也許是在能力度等級第2級。 簡介 13
CMMI for Development Version 你有所有的需求發展與管理流程，並且它們已被管理，但是每一個專案執行的流程卻是有差異的？例如，您的需求誘導流程無法在跨組織中被一致地執行。假如以這個個案來看，您的流程改善目標也許是在能力度等級第3級。 你有一致性地管理與執行你的需求發展及管理流程，但是沒有用客觀方式去控制和改善這些流程嗎？假如以這個個案來看，你的流程改善目標也許是在能力等級第4級。 你想要確保您根據量化目標所選擇的適當子流程可以最大化你的經營？假設是如此，你的流程改善目標也許是針對所選擇的流程到能力度等級第5級。在每個流程領域的描述下，記得要去看「適用於硬體工程」、「適用於系統工程」與「適用於軟體工程」的強化。使用沒有特定標記與被框線標記為「僅適用於連續式表述」的所有資訊。 如你在這個情節所見到的，你需要瞭解哪些流程需要改善以及每一個流程要達到的成熟度。這個進行方式反映了連續式表述的根本準則。 情節2 在第二個情節中，你是一間使用IPPD與軟體能力成熟度模式的軟體開發公司，你想要使用能力成熟度整合模式。你選擇成熟度第2級與第3級的流程領域，以及選擇CMMI for Development + IPPD模式。 這個選擇包含成熟度等級第2級下的七個流程領域：需求管理、專案規劃、專案監控、供應商協議管理、度量與分析、流程與產品品質保證與建構管理。它也包含成熟度等級第3級下的11個流程領域：需求發展、技術解決方案、產品整合、驗證、確認、組織流程專注、組織流程定義、組織訓練、整合的專案管理、風險管理及決策分析與解決方案。你也會包含IPPD附加在內。 簡介 14
CMMI for Development Version 因為你在軟體能力成熟度模式中，已經被評等為成熟度第3級，所以只要看那些包含在CMMI內，但卻未包含在軟體能力成熟度模式內之流程領域。這些流程領域包含度量與分析、需求發展、技術解決方案、產品整合、驗證、確認、風險管理及決策分析與解決方案。確認你的組織是否存在這些流程，即使它們沒有被軟體能力成熟度模式描述。假如有任何合適的流程可以與這些流程領域對映，或是與軟體能力成熟度模式之其它流程領域對映，執行差異分析去對照這些目標及執行方法，以確保你解決每一個CMMI流程領域的意圖。 記住，每一個你所選擇的流程領域，察看標記為「適用於軟體工程」與「IPPD附加」的資訊。使用沒有特定標記與被框線標記為「僅適用於階段式表述」的所有資訊。 如你所見，這份文件所提供的資訊可以有各種使用方式，端視你的改善需要。能力成熟度整合模式的整體目標是提供一個可以一致地分享流程改善最佳執行方法的架構與表述，但是仍有足夠的彈性解決社群變更的需要。 簡介 15
CMMI for Development Version 2 流程領域組件 這一章說明每一個流程領域、一般目標與一般執行方法的組件。瞭解這些組件的意義，對於有效使用第二單元的資訊是重要的。假如你不熟悉第二單元，在閱讀本章之前，你可能要快速瀏覽一般目標與一般執行方法的章節以及相關流程領域的章節，以針對內容與版面編排取得一般性的理解。 必要的、期望的及助益的組件 CMMI模式組件被群組成三個類型—必要的、期望的與助益的—反映如何解釋它們。 必要的組件 必要的組件是說明一個組織要滿足某一個流程領域所需要達成的成果。這個成果必須很明顯地被一個組織的流程所執行。在CMMI中的特定目標及一般目標是必要的模式組件。目標滿足是在評鑑中決定某流程領域是否有達成或滿足的基礎。 期望的組件 期望的組件說明一個組織要達成某一個必要的組件所需要執行的作法。期望的組件用來指引要執行改善或評鑑的個人與團體。期望的組件包含特定執行方法和一般執行方法。 在目標被認定已滿足之前，執行方法或其可行的替代方案，都必須表現於組織已規劃和已實行的流程之內。 領程領域組件 16
CMMI for Development Version 助益的組件 助益的組件提供細部描述以協助組織開始著手思考，如何達成必要的組件與期望的組件。細部執行方法、典型的工作產品、強化、一般執行方法詳細說明、目標和執行方法的標題、目標和執行方法的註解及參考資料都是助益的模式組件的例子。 CMMI的詞彙並不是CMMI模式之必要的、期望的及助益的組件。你必須以詞彙中之術語在模式組件出現時的上下文來詮釋它的意義。 第二單元相關的組件 彙總與第二單元有關的模式組件，並說明它們的關係，如圖所示。 目的簡介 圖 能力成熟度整合模式的組件 下面章節提供模式組件的詳細說明。 流程領域 流程領域是一個領域下相關執行方法的集合，當它們共同執行時，滿足一系列被視為對改善該領域是重要的目標。 流程領域組件 17
CMMI for Development Version 這裡有22個流程領域以首字母縮寫方式依序排列： • 原因分析及解決方案(CAR) • 建構管理(CM) • 決策分析與解決方案(DAR) 6• 整合專案管理+IPPD(IPM+IPPD) • 度量與分析(MA) • 組織創新與發展(OID) 6• 組織流程定義+IPPD（OPD+IPPD） • 組織流程專注(OPF) • 組織流程績效(OPP) • 組織訓練(OT) • 產品整合(PI) • 專案監控(PMC) • 專案規劃(PP) • 流程與產品品質保證(PPQA) • 量化專案管理(QPM) • 需求發展(RD) • 需求管理(REQM) • 風險管理(RSKM) • 供應商協議管理(SAM) • 技術解決方案(TS) • 確認(VAL) • 驗證(VER) 目的 目的說明流程領域的目的，目的是助益的組件。 6.流程領域的名稱有包含「+IPPD」是因為其包含IPPD的目標與執行方法。IPPD的特定內容稱之為IPPD附加。所有包含「IPPD附加」的流程領域其名稱後面都有「+IPPD」 領程領域組件 18
CMMI for Development Version 例如，組織流程定義流程領域的目的是「組織流程定義(OPD)的目的是建立與維護一套可以使用的組織流程資產與工作環境標準」。 前言 流程領域的前言是說明流程領域所涵蓋的主要觀念，是助益的組件。 例如，在專案規劃流程領域的前言例子是「規劃始於定義產品及專案的需求」。 相關流程領域 相關流程領域列出與流程領域有關的流程領域參考資料，並反映流程領域間高層級的關係。相關流程領域是助益的組件。 專案規劃流程領域之相關流程領域章節的參考資料，例如「請參考風險管理流程領域，有關界定與管理風險的部份，以獲得更多資訊」。 特定目標 特定目標描述必須用來滿足該流程領域唯一的特徵。特定目標是必要的模式組件以及被使用在評鑑中判斷某個流程領域是否滿足。 例如，建構管理流程領域的其中一個特定目標是「建立與維護基準的完整性」。 只有特定目標下的說明是必要的模式組件。特定目標的標題（前有目標編碼）與該目標有關的任何註釋視為助益的模式組件。 一般目標 一般目標之所以稱為「一般」是因為相同的目標說明可適用於多個流程領域。一般目標描述必須能夠呈現執行流程領域流程制度化的特徵。一般目標是必要的模式組件，被使用在評鑑中判斷一個流程領流程領域組件 19
CMMI for Development Version 域是否滿足。（一般目標的詳細描述，請參看一般目標與一般執行方法章節）。 一般目標的例子是「流程制度化為已定義流程」。 只有一般目標下的說明是必要的模式組件。一般目標的標題（前有目標編碼）及任何與目標有關的註釋被視為助益的模式組件。 特定目標與執行方法摘要 特定目標與執行方法摘要提供特定目標高層的摘要。特定目標是必要的組件，特定執行方法是期望的組件，特定目標與執行方法摘要是助益的組件。 特定執行方法 特定執行方法是一種活動的說明，它對達成相關的特定目標是重要的。特定執行方法說明能夠達成流程領域特定目標期望結果的活動。特定執行方法是期望的模式組件。 例如，專案監控流程領域的一個特定執行方法是「依專案計畫所界定的承諾，監督承諾」。 只有特定執行方法下的說明是期望的模式組件。特定執行方法的標題（前有執行方法編碼）及任何與該特定執行方法有關的註釋，被視為助益的模式組件。 典型的工作產品 典型的工作產品章節列出特定執行方法所產出的範例。這些範例稱之為典型的工作產品，是因為除了這些具代表性的範例之外，還有其他的工作產品也是有效的，但未被列出。典型的工作產品是助益的模式組件。 例如，專案監控流程領域中特定執行方法「依照專案，監督專案規劃參數的實際值」的一個典型的工作產品是「重大偏差的記錄」。 領程領域組件 20
CMMI for Development Version 細部執行方法 細部執行方法是一個詳細說明，提供解釋與執行特定或一般執行方法的指引。細部執行方法可能以規範的文字描述，但是實際上是一個助益的模式組件，只提供可用於流程改善的想法。 例如，專案監控流程領域中特定執行方法「對議題採取矯正行動」的一個細部執行方法是「決定與文件化所需解決已界定議題的適當活動」。 一般執行方法 一般執行方法之所以稱為「一般」是因為相同的執行方法可適用於多個流程領域。一般執行方法被視為達成相關的一般目標之重要活動。一般執行方法是期望的模式組件。 例如，一般目標「流程制度化為已管理的流程」下之一般執行方法「提供足夠的資源執行流程、發展工作產品與提供流程服務」。 只有一般執行方法的說明是期望的模式組件。一般執行方法的標題（前有執行方法編碼）與該執行方法有關的任何註釋，被視為助益的模式組件。 為了降低此資訊的重覆性以及節省用來呈現此資訊的頁數，只有一般執行方法的標題、敘述與詳細說明會顯示在流程領域。（一般執行方法的完整描述請參看一般目標與一般執行方法章節）。 一般執行方法的詳細說明 一般執行方法詳細說明是助益的模式組件，它出現在各流程領域，並提供指引以說明一般執行方法要如何應用於流程領域。 例如，專案規劃流程領域的一般執行方法「建立與維護規劃與執行專案規劃流程的組織政策」的詳細說明是「這個政策建立估計規劃參數，決定內部與外部承諾，與發展管理專案計畫的組織期望」。 流程領域組件 21
CMMI for Development Version 支援助益的組件 在很多地方，需要進一步的資料來描述一個概念。這種助益的資料是以下列組件方式提供： • 註釋 • 範例 • 強化 • 參考資料 註釋 註釋是緊密附帶在任何其它模式組件的文字。它可能提供細節、背景或原由。註釋是助益的組件。 例如，在原因分析與解決方案流程領域中，伴隨特定執行方法「執行在原因分析中發展且被選擇的活動建議」的註釋是「只有證明為有價值的變更才應該被考慮廣泛實行」。 範例 範例包含文字與項目清單的組件，通常用框線加以區隔。範例會緊密附帶在任何其它組件中，並提供更多的例子，以釐清觀念或說明活動。範例是助益的組件。 下面在流程與產品品質保證流程領域中，伴隨在細部執行方法「當它們在專案中無法解決時，文件化無法遵循的爭議」下之特定執行方法「與員工及管理者溝通品質爭論，並確保無法遵循的爭論已解決」的範例。 領程領域組件 22
CMMI for Development Version 解決專案中無法遵循爭論之方法的範例： • 修正不符合。 • 變更所違反的流程描述、標準或程序。 • 取得無法遵循的豁免書。 強化 強化是一個與特定專業領域有關的註釋或範例。本模式中的專業領域為硬體工程、系統工程與軟體工程。 每一個強化使用其專業領域的名稱加以標記。例如，軟體工程的強化標記為「適用於軟體工程」。強化是助益的模式組件。 強化的例子，在專案規劃流程領域中的特定執行方法「建立與維護整體專案計畫內容」下，這個強化說明「適用於硬體工程：對於硬體，規劃文件常常參考到硬體發展計畫。準備生產的發展活動可能包含在硬體發展計畫或是定義在個別的生產計畫內」。 參考資料 參考資料是指相關流程中附加或是更詳細的資訊。參考資料會緊密伴隨在任何其它模式組件。參考資料是助益的模式組件。 例如，在量化專案管理流程領域的特定執行方法「根據歷史穩定與能力數據，選擇包含專案定義流程的子流程」下，所伴隨的參考資料「有關組織流程資產館，應該包含已知與所需能力的流程元件，請參考組織流程定義流程領域」。 流程領域組件 23
CMMI for Development Version 編碼系統 特定及一般目標以流水號的方式編碼。每一個特定目標的編碼以SG開頭(例如：SG1)。每一個一般目標的編碼以GG 開頭(例如：GG2)。 每個特定執行方法的編碼以SP 開頭，其後有數字 (例如：SP )。x 對應特定目標的編號，而y 是特定目標之下特定執行方法的序號。 以專案規劃流程領域的特定執行方法編碼為例，第一個執行方法的編碼是SP ，第二個是SP 。 每個一般執行方法的編碼以GP 開頭，其後有 (例如：GP )。 x是對應一般目標的編號，y則是一般目標之下一般執行方法的序號。例如，GG2下的第一個一般執行方法的序號是，第二個是。 印刷慣例 本模式的印刷慣例是設計來協助你有效地選擇與使用你所需要的部份。我們描述的模式組件格式允許你在頁面中快速地找到它們。 圖到是第二單元中流程領域的範例頁面。它們顯示不同的流程領域組件，並以標記讓你可以識別它們。注意組件在印刷上的差異，你就可以容易地識別出每一個。 領程領域組件 24
CMMI for Development Version 特定目標與 執行方法摘要特定目標與執行方法摘要 圖 原因分析與解決方案的範例頁面 流程領域組件 25
CMMI for Development Version 圖 驗證的範例頁面 領程領域組件 26
CMMI for Development Version 僅適用於連續式區塊 僅適用於連續式僅適用於階段式區塊 圖 整合的專案管理+IPPD的範例頁面 表述的特定內容 在第二單元中，每一個流程領域的目標章節下，你會注意到一些一般執行方法的組件被框起來並命名為「僅適用於階段式」、「僅適用於連續式」或「連續式/成熟度3-5級」。 沒有標記的元件可應用於兩種表述。標記為「僅適用於階段式」的元件只在你使用階段式表述中才使流程領域組件 27
CMMI for Development Version 用。標記為「僅適用於連續式」的元件只在你使用連續式表述中才使用。（看圖的例子） 標記為「連續式/成熟度3-5級」的元件只在你使用連續式表述或是要進行成熟度第3級、第4級與第5級時才可以使用。所以如果你進行階段式表述成熟度第2級的評等時，並不應用這些組件 附加 附加可以是助益的內容、特定執行方法、特定目標或流程領域，以延伸模式範圍或強調使用上的特定觀點。在本文件中，所有的附加都應用於IPPD。 組織訓練流程領域中附加的範例，出現在特定目標1「建立組織訓練的能力」之後。附加描述「整合的團隊成員需要跨職能的訓練、領導才能訓練、人際關係技能訓練，以及整合適當經營與技術功能所需技能的訓練。針對潛在的廣泛需求及需求提供者背景，可要求未參與需求發展的相關關鍵人員參加產品設計專業領域之訓練，以取得對於需求範圍有全面性了解及需求間互動關係的承諾」。 領程領域組件 28
CMMI for Development Version 3 試著合而為一 既然已經向您介紹CMMI模式的組件，你需要瞭解它們如何合而為一，以符合你的流程改善需要 [Dymond 2004]。在本章中，我們介紹等級的概念與顯示流程領域如何被組織與使用。為了完成此目的，我們需要再回顧第一章一開始的討論。 瞭解等級 CMMI使用等級，說明組織建議的演進途徑，組織想要改善發展與維護產品與服務的流程。等級也是7評鑑中評等活動的產出。評鑑可以在全公司（通常是小型）或是小群組中執行，小群組就像是專案群組或是公司內的一個部門。 CMMI支援兩種改善途徑。一個途徑是針對組織所選擇的一個流程領域（或多個流程領域），使組織能夠漸進地改善流程。另一個途徑是組織漸進地解決連續的一組流程領域，使組織改善一組相關的流程。 這兩種改善途徑與第1章所探討的兩種表述使用的兩種等級類型有關連。對於連續式表述，我們使用術語「能力度等級」。對於階段式表述，我們使用術語「成熟度等級」。 無論你選擇哪一種表述，等級的概念都是相同的。等級描述改善從一個不清楚定義的狀態到使用量化資訊，決定與管理改善的狀態，這個改善必須符合組織經營目標。 7更多有關於評鑑的資訊，請參考Appraisal Requirements for CMM與Standard CMMI Appraisal Method for Process Improvement Method Definition Document [SEI 2006a, SEI 2006b] 試著合而為一 29
CMMI for Development Version 為達到一個特定等級，組織必須滿足流程領域或一組流程領域中所有適當的目標。無論是能力度等級或是成熟度等級，它們被當做改善的目標。 這兩種表述也提供執行流程改善的方法，以達到經營目標。這兩種表述提出相同的必要內容與使用相同的模式組件。 連續式與階段式表述的結構 圖說明連續式與階段式表述的結構。當你看到這兩種表述的架構，對您而言立刻注意到其差異。階段式表述使用成熟度等級，然而連續式表述使用能力度等級。 試著合而為一 30
CMMI for Development Version 圖 連續式與階段式表述的結構 在你比較這兩種表述的相似性後，有什麼是讓你有印象的？這兩種表述有許多相似的元件（例如：流程領域、特定目標與特定執行方法），並且這些元件有相同的層級與結構。 圖從高層觀點中有什麼不容易立即看出的。是連續式表述專注在以能力度等級度量的流程領域能力。而階段式表述專注在以成熟度等級度量的組織成熟度。這些CMMI維度（能力度/成熟度）使用在標竿學習與評鑑活動，並且指引組織的改善工作。 試著合而為一 31
CMMI for Development Version • 能力度等級，屬於連續式表述，應用於個別流程領域的組織流程改善的達成。這些等級對一個流程領域有遞增地改善流程的方式。有六個能力度等級，編號為0到5。 • 成熟度等級，屬於階段式表述，應用於跨流程領域的組織流程改善的達成。這些等級有預測下一個從事的專案之一般產出的方式。有五個成熟度等級，編號為1到5。 表為六個能力度等級與五個成熟度等級的比較。你可以察覺到這兩種表述中，有4個等級的名稱是相同的。差異之處在於階段式表述並沒有成熟度第0級，而是以成熟度第1級的名稱為起始級。所以，這兩種表述的開始點是不同的。 表 能力度與成熟度等級的比較 連續式表述的能力階段式表述的成熟等級 度等級 度等級 等級 0 不完整級 無 等級 1 執行級 初始級 等級 2 管理級 管理級 等級 3 調適級 調適級 等級 4 量化管理級 量化管理級 等級 5 最佳化級 最佳化級 連續式表述關心選擇特定的流程領域進行改善，以及該流程領域期望的能力度等級。在這個背景下，一個流程是否已執行或不完整是重要的。所以，名稱「不完整」做為連續式表述的開始點。 由於階段式表述關心組織的整體成熟度，無論個別流程是已執行或不完整都不是主要焦點。所以，名稱「初始」做為階段式表述的開始點。 試著合而為一 32
CMMI for Development Version 能力度等級與成熟度等級兩者均提供一個度量方式，以度量組織能夠並實行改善他們的流程到多好。然而，流程改善的相關方法是不同的。 瞭解能力度等級 為支援使用連續式表述，所有的CMMI模式在它們的設計與內容中反映能力度等級。能力度等級包含與流程領域有關的一般目標及相關的一般執行方法，可以改善該流程領域有關的組織流程。當您滿足每一個能力度等級下的一般目標與其一般執行方法，您就能獲得在那個流程領域的流程改善效益。 有六個能力度等級，標示由編號0 到編號5如下： 0. 不完整級 1. 執行級 2. 管理級 3. 調適級 4. 量化管理級 5. 最佳化級 事實上，能力度等級第2級到第5級有意的使用與一般目標2到5相同的術語，因為每一個一般目標與執行方法反映你會實行的目標與執行方法之能力度等級的意義（一般目標與執行方法的更多資訊，請參看一般目標與一般執行方法段落）。每一個能力度等級簡短說明如下： 能力度第0 級：不完整級 「不完整流程」是一個沒有執行或部分執行的流程。無法滿足流程領域的一個或多個特定目標，以及因為沒有制度化部分執行流程的理由，這個等級沒有一般目標。 試著合而為一 33
CMMI for Development Version 能力度第1級：執行級 能力度第1級流程特徵為「已執行流程」。已執行流程是滿足流程領域特定目標的流程，它支援並使所需工作能夠產出工作產品。 由能力度第1級所導致的重大改善可能會隨著時間而失去，因為它們沒有被制度化。應用制度化（CMMI能力度第2級到第5級的一般執行方法）可以確保維護改善。 能力度第2級：管理級 能力度第2級流程特徵為「已管理流程」。已管理流程是一個已執行的流程(能力度第1級)，具有基本的基礎建設支援流程。它會根據政策規劃與執行流程；任用具備技能的人員，並給予足夠的資源以產出可控制的產品；納入相關的關鍵人員；監督、控制及審查；並評估遵循流程說明的程度。能力度第2級所反映的流程規範，確保現有的執行方法能在有壓力的情況下，仍維持運作。 能力度第3級：調適級 能力度第3級流程特徵為「已調適流程」。已調適流程是一個已管理流程（能力度第2級）。流程根據組織的調適指引調適組織標準流程，並納入工作產品、度量與其他流程改善資訊至組織流程資產。 能力度第2級與第3級間的重要差異在標準、流程說明與程序的範圍。在能力度第2級中，每一個流程特定案例(例如，特定專案)中標準、流程說明與程序可能頗有差異。能力度第3級，專案的標準、流程說明與程序由組織標準流程調適而得，以符合特定專案或組織單位。所以，除了調適指引允許的差異外，因而更具一致性。 其它能力度第3級的重要差異是，流程通常說明的比能力度第2級還要嚴謹。一個已調適流程清楚地說明目的、輸入、允入準則、活動、角色、度量、 試著合而為一 34
CMMI for Development Version 驗證步驟、輸出，允出準則。在能力度第3級中，透過瞭解流程活動之互動關係及流程、工作產品與服務的詳細度量，能夠更主動的管理流程。 能力度第4級：量化管理級 能力度第4級流程特徵為「已量化管理流程」。已量化管理流程是一個已調適流程(能力度第3級)，使用適當的統計和其它量化的技術進行控制。建立品質和流程績效的量化目標，並以該目標為管理流程的準則。以統計的術語瞭解品質和流程績效，並在流程生命週期受到管理。 能力度第5級：最佳化級 能力度第5級流程特徵為「最佳化流程」。最佳化流程是一個已量化管理流程(能力度第4級)，利用瞭解流程中的共同變異原因，改善流程。最佳化流程以漸進與創新的改善，專注於持續改善流程績效。 記住，能力度第2級到第5級使用相同的一般目標2到5的術語，這些術語的詳細說明，顯示在一般目標與一般執行方法段落。 能力度等級的進展 流程領域能力度等級的達成，是憑藉一般執行方法或在流程領域中相關流程之適當替代方案的應用。 達到一個流程領域之能力度第1級，等同於說該流程領域相關的流程是「已執行流程」。 達到一個流程領域之能力度第2級，等同於說有政策可以指出你會執行這個流程。有執行計畫、提供資源、指派責任、執行訓練、控制執行流程相關之所選擇的工作產品等等。換句話說，一個能力度第2級的流程是有規劃與監督的，就像任何專案或支援活動一樣。 試著合而為一 35
CMMI for Development Version 達到一個流程領域的能力度第3級，即認為有一個組織標準流程存在於流程領域中，並且可以根據專案需要調適。因為它們根據組織標準流程調適，所以組織流程更具一致性的定義與應用。 達到一個流程領域的能力度第4級，即認為這個流程領域是一個關鍵的經營驅力，此驅力是組織想要使用量化與統計技術執行管理。這個分析使組織對所選擇之子流程的績效更加透明，使組織在市場上更有競爭力。 達到一個流程領域的能力度第5級，即認為你所選擇的子流程穩定，並且你想要降低流程的共同變異原因。記住，變異在任何流程中是自然發生的，因此雖然改善所有流程在概念上是可行的，但是將所有流程都改善至第5級是不經濟的。再說一次，你將專注於那些會幫助你，符合你經營目標的流程。 瞭解成熟度等級 為支援使用階段表述，所有的CMMI模式在其設計與內容中反映成熟度等級。成熟度等級包含預先定義的一組流程領域與相關的特定與一般執行方法，以改善組織整體績效。組織的成熟度等級提供一個方式，在一個專案領域或是一組專案領域下，預測組織績效。當組織流程改善工作專注於可管理數目的流程領域，而且組織改善逐漸增加那些領域的熟練度，經驗顯示組織會做到最好。 成熟度等級在組織流程改善中是一個已定義的演進水準。每一個成熟度等級會使一個重要的組織流程子集合變得成熟，為提升到下一個成熟度做準備。憑藉達成度量成熟度等級預先定義的一組流程領域中特定與一般目標。 有五個成熟度等級，每一個等級都是進行下一個等級的基礎，標示由編號1到5： 1. 初始級 試著合而為一 36
CMMI for Development Version 2. 管理級 3. 調適級 4. 量化管理級 5. 最佳化級 記住，成熟度第2級到第5級使用相同術語，如同能力度第2到第5級。這是有其目的的，因為成熟度等級與能力度等級的概念是互補的。成熟度等級的使用特徵為一組相關流程領域的組織改善，而能力度等級特徵為個別流程領域的組織改善。 成熟度第1級：初始級 在成熟度第1級中，流程通常是混亂的。組織通常沒有提供穩定的環境維持流程。這些組織的成功，往往依賴組織成員的能力與英雄主義，而不是使用一套經過證實的流程。除了混亂的環境之外，成熟度第1級的組織也經常可產生會運作的產品和服務；不過它們經常會超過專案的預算且不符合時程。 成熟度第1級組織的特徵為過度承諾的傾向、在緊急關頭放棄流程，以及沒有能力複製成功經驗。 成熟度第2級：管理級 成熟度第2級中，可確保組織的專案是按照政策規劃與執行流程；專案雇用具備技能的人員，並給予足夠的資源，產出可控制的產品；納入相關的關鍵人員；監督、控制與審查；以及評估遵循流程說明的程度。成熟度第2級所反映的流程規範，可提供協助以確保現有的執行方法在有壓力的情況下，仍維持運作。在這些執行方法實行時，專案依計畫執行和管理。 成熟度第2級，工作產品的狀況及服務的交付情形，在已定義的時間點（例如：重要里程碑及重要任務完成）是可以透明管理的。承諾是由相關的關鍵人員所建立，並視需求修訂。適當的管控工作產試著合而為一 37
CMMI for Development Version 品。工作產品和服務滿足其特定的流程說明、標準及程序。 成熟度第3級：已定義級 成熟度第3級，流程被適當地描述特徵與瞭解，並以標準、程序、工具與方法說明。建立與改善組織標準流程，是成熟度第3級的基礎。標準流程被使用來確保跨組織的一致性。專案根據調適指引，調適組織標準流程，以建立它們的調適流程。（參考組織標準流程的詞彙定義）。 成熟度第2級與第3級間的重要差異在標準、流程說明與程序的範圍。在成熟度第2級中，每一個流程案例（例如；特定專案）中標準、流程說明與程序可能有很大的差異。成熟度第3級中除了調適指引允許的差異外，專案的標準、流程說明與程序由組織標準流程調適而得，以符合特定專案或組織單位，因而流程更具一致性。 其它成熟度第3級的重要差異是，流程通常說明得比成熟度第2級還要嚴謹。一個已調適流程清楚地說明目的、輸入、允入準則、活動、角色、度量、驗證步驟、輸出，允出準則。在成熟度第3級中，流程透過瞭解流程活動之互動關係及工作產品與服務的流程詳細度量，以更主動的管理流程。 成熟度第3級中，組織必須使成熟度第2級的流程領域變得更成熟。成熟度第2級未處理的屬於一般目標3的一般執行方法，可應用於達成成熟度第3級。 成熟度第4級：量化管理級 成熟度第4級，組織與專案針對品質與流程績效建立量化目標，並使用它們當做管理流程的準則。量化目標是基於客戶、最終使用者、組織與流程執行者的需要。以統計的術語瞭解品質與流程績效，並在流程生命週期受到管理[SEI 2001]。 試著合而為一 38
CMMI for Development Version 對所選擇的子流程，搜集與統計分析流程績效的詳細度量。品質與流程績效度量值被合併到組織度量儲藏庫，以支援以事實為基礎的決策 [McGarry 2000]。適當地定義流程變異的特殊原因，修正特殊原因的源頭，以預防下次發生。（請參考流程變異的特殊原因的詞彙定義）。 成熟度第3級與第4級的重要差異在流程績效的可預測性。在成熟度第4級中，流程績效使用統計與其它量化技術控制及量化預測。成熟度第3級中，流程通常僅量化預測。 成熟度第5級：最佳化級 成熟度第5級，組織根據流程變異共同原因的量化瞭解，持續改善它的流程。（參考流程變異的共同原因的詞彙定義）。 成熟度第5級透過漸增與創新流程及技術改進，專注於持續改善流程績效。建立組織量化流程改善目標，且持續修改以反映經營目標的變動，以及用作管理流程改善的準則。依量化流程改善目標，度量與評估推展流程改善的影響。已定義流程與組織標準流程是可度量的改善活動目標。 成熟度第4級與第5級的重要差異在所解決的流程變異類型。在成熟度第4級中，組織關心解決流程變異的特殊原因，以及提供結果的統計預測。雖然流程可能產出可預測的結果，然而這個結果可能不足以達成所建立的目標。在成熟度第5級中，組織關心流程變異的共同原因，以及變更流程（轉移流程績效的平均值或降低內在有經驗的流程變異），以改善流程績效，並且達成已建立的量化流程改善目標。 成熟度等級的進展 組織可以逐漸達成組織成熟度的改善。先由專案層級達成，持續到較高層級(整個組織層級的持續性流程改善)，使用定量和定性資料做決策。 試著合而為一 39
CMMI for Development Version 既然已改善的組織成熟度與一個組織可以達到的預期結果之改善範圍有關，它也是預測組織下一個專案一般結果的一個方法。例如：在成熟度第2級，組織經由建立良好的專案管理流程，已由無特定章法提升到有制度可循。當組織達成所設定之成熟度等級中所有流程領域的一般及特定執行方法時，就提升了組織成熟度，並獲得流程改善的好處。因為每一成熟度等級都是下一個等級的基礎，嘗試略過某一個成熟度，通常會有反效果。 同時，你必須瞭解流程改善的工作應該專注於組織經營環境的需要，在較高成熟度等級的流程領域可能解決組織或專案的目前需要。例如：尋求自成熟度第1級升級到成熟度第2級的組織，通常被建議成立一個流程組，但是此流程組卻是屬於成熟度第3級的「組織流程專注流程領域」才會說明的內容。雖然流程組並不是組織成熟度第2級組織之必要特徵，但是流程組可以是一個有效方法，以協助組織達到成熟度第二級。 這種情況有時候稱為「建立成熟度第1級的工程流程組，以帶動組織到成熟度第2級」。成熟度第1級的流程改善活動可能主要依賴流程團隊成員的洞察力和能力，一直到擁有支援較專業及廣泛改善的基礎建設。 組織可以在任何時間著手於特定的流程改善，甚至在準備進入成熟度等級所建議的特定執行方法之前即可著手。然而在這些情況下，組織應該瞭解到這些改善的成功是有風險的，因為能讓這些改善成功的基礎並未建置完成。面對壓力時，缺乏適當基礎的流程可能會在最需要它的時候失敗。 倘若缺乏成熟度第2級管理階層的執行方法，即已調適流程，這是成熟度第3級組織的特徵，就可能會發生問題。例如：管理階層可能會承諾一個未經妥善規劃的時程，或是無法控制基準需求的變更。同樣地，許多組織蒐集了成熟度第4級所需詳細的 試著合而為一 40
CMMI for Development Version 資料，但卻因為流程與度量定義的不一致，而無法詮釋這些資料。 另一使用較高成熟度等級流程領域所屬流程的例子為建造產品的流程。當然，我們期望成熟度第1級的組織，會執行需求分析、設計、整合及驗證等活動。不過這些活動到成熟度第3級時才會描述。在成熟度第3級，會以連貫且整合良好的工程流程來描述這些活動。工程流程補足專案管理能力，可將相關活動就定位，使工程改善不致於因混亂的管理流程而迷失。 試著合而為一 41
CMMI for Development Version 流程領域 兩種表述針對流程領域的觀點是不同的。圖比較流程領域如何使用在連續式與階段式表述中之觀點。 達成成熟度第3級流程改善所選擇的一組流程領域 圖 連續式與階段式表述的流程領域 試著合而為一 42
CMMI for Development Version 連續式表述使組織能夠選擇那些流程領域或是一組有互相關連的流程領域，選擇流程改善努力的專注以為組織及其經營目標帶來最大利益。雖然因為流程領域間的相依性，使得組織在選擇上有一些限制，但是組織仍然有相當多的自由選擇。 為支援使用連續式表述，流程領域組織成4種類型：流程管理、專案管理、工程與支援。這些類型強調流程領域間存在的關係，並且討論於第四章。 當你選擇流程領域時，你也必須選擇在這些流程領域中流程需要成為多少成熟度（例如：選擇適當的能力度等級）。能力度等級與一般目標及執行方法支援個別流程領域相關的流程改善。舉例來說，一個組織可能希望努力於某個流程領域達到能力度第2級，以及在另一個流程領域達到能力度第4級。當一個組織達到一個能力度等級時，它將這些相同流程領域中的一個設為下一個能力度等級的目標，或是決定擴大視野及解決更大數量的流程領域。 這個選擇一般以目標摘要來說明。目標摘要是用來定義所有必須要解決的流程領域及其每一個目標能力度等級，然後這個摘要會影響有哪一些目標與執行方法，組織將在流程改善工作中解決。 大多數組織在最低情況下會將能力度第一級當做目標，它要求流程領域的所有特定目標均需達成。所以，將高於能力度第一級當做目標之組織，會專注於組織內所選擇流程的制度化，實行相關的一般目標與執行方法。 相反地，你將會看到階段式表述鼓勵你，注意成熟度等級所屬的流程領域。流程領域被成熟度等級所組織，以強化這個概念。 階段式表述提供由成熟度第1級到第5級之預先定義的改善路徑，包含達成每一個成熟度等級流程領域之目標。為了支援階段式表述，流程領域群組成成熟度等級，指出實行哪些流程領域以達成每一個成熟度等級。例如，成熟度第2級中，有一組流程試著合而為一 43
CMMI for Development Version 領域是組織要用來指引它們流程改善的，直到達成所有流程領域的目標。一旦達成成熟度第2級，組織會專注於成熟度第3級的流程領域等等。每一個流程領域的一般目標也是預先定義的。一般目標2應用在成熟度第2級，而一般目標3應用於成熟度3-5級。 表 提供所有流程領域的清單與其相關的類別及成熟度等級。為了解釋流程領域組件如何被呈現在每一個表述下，我們必須討論表述如何解決特定執行方法。 表 流程領域與其相關的類別及成熟度等級 流程領域 類別 成熟度等級 原因分析與解決方案 支援 5 建構管理 支援 2 決策分析與解決方案 支援 3 整合專案管理+IPPD 專案管理 3 度量與分析 支援 2 組織創新與推展 流程管理 5 組織流程定義+IPPD 流程管理 3 組織流程專注 流程管理 3 組織流程績效 流程管理 4 組織訓練 流程管理 3 產品整合 工程 3 專案監控 專案管理 2 專案規劃 專案管理 2 流程與產品品質保證 支援 2 試著合而為一 44
CMMI for Development Version 量化專案管理 專案管理 4 需求發展 工程 3 需求管理 工程 2 風險管理 專案管理 3 供應商協議管理 專案管理 2 技術解決方案 工程 3 確認 工程 3 驗證 工程 3 一般目標與執行方法 一般目標是必要的組件，應用於所有流程領域。圖說明一般目標與一般執行方法。所有的一般目標與執行方法都會在連續式表述中使用。（一般目標與執行方法的更詳細說明，請參考一般目標與一般執行方法章節）。在你改善的工作中，你設定為目標的能力度等級，將決定哪些一般目標與執行方法，將應用到你所選擇的流程領域。 試著合而為一 45
CMMI for Development Version 圖 : 一般目標與一般執行方法 在階段式表述中，只使用一般目標2與3，說明在圖中灰色部分所強調的一般執行方法。當你試著達到成熟度第2級，你使用成熟度第2級的流程領域，以及使用一般目標2與其一般執行方法。 注意，不使用一般目標4與5以及它們相關的執行方法，是因為並不是所有流程都要被「提升」到已定義流程之上。只有選擇的流程與子流程將會量化管理與最佳化，哪些選擇的流程與子流程解決成熟度第4與第5級的流程領域。 當你達到成熟度第3級、第4級與第5級，你適當的使用成熟度等級的流程領域，以及使用較低成熟度等級的流程領域。此外，一般目標3與其相關的一般執行方法（包含一般目標2與其相關的一般執行方法），應用到這些所有流程領域。這個意思是即使你已經達到成熟度第2級評等，為了達到成熟度第3級評等，你必須回到成熟度第2級的流程領 試著合而為一 46
CMMI for Development Version 域，並且同樣地應用一般目標3與其相關的一般執行方法。 表述比較 表彙總兩種表述的差異。 表比較連續式與階段式表述 連續式表述 階段式表述 組織依據其流程改善目組織依據成熟度等級，標，選擇流程領域與能選擇流程領域。 力度等級。 使用能力度等級度量改使用成熟度等級度量改善。能力度等級： 善。成熟度等級： • 度量跨組織的特定• 度量跨組織的一組流程領域的能力流程領域成熟度。 度。 • 等級從1到5。 • 等級從0到5。 能力度等級摘要當做目成熟度等級當做目標與標與追蹤流程改善績追蹤流程改善績效。 效。 對等的階段式允許一個並不需要一個對等的機組織使用連續式表述進制來反推連續式表述。 行流程改善並引申成熟度等級以當做評鑑的一部分。 對等的階段式 對等的階段式是一個比較使用連續式表述與階段式表述之結果的方式。在本質上，假如你在連續式表述中使用能力度等級度量所選擇流程領域相關的改試著合而為一 47
CMMI for Development Version 善，你如何將它與成熟度等級做比較呢？這有可能嗎？ 到目前為止，我們沒有討論詳細的流程評鑑。SM8SCAMPI方法. 用來評鑑使用CMMI的組織，其中一項評鑑結果是評等 [Ahern 2005]。假如評鑑使用連續式表述，評等就是能力度等級摘要。假如評鑑使用階段式表述，評等就是成熟度等級（例如：成熟度等級3）。 能力度等級摘要是流程領域清單，以反映每一個流程領域達成的能力度等級。這個摘要使組織能夠追蹤其流程領域的能力度等級。當它呈現組織每一個流程領域的實際進展時，這個摘要是一個達成摘要。或者，當它呈現組織的已規劃流程改善目標，這個摘要是一個目標摘要。圖說明目標摘要與達成摘要。每一個長方條灰色的地帶呈現已經達成的。未遮蔽的部份呈現有待完成的，以符合目標摘要。 圖 達成摘要與目標摘要的例子 8SCAMPI方法被描述在第五章。 試著合而為一 48
CMMI for Development Version 達成摘要與目標摘要的比較，使組織能夠規劃與追蹤每一個所選擇的流程領域的進展。當使用連續式表述時，維護能力度等級摘要是明智的。 目標階段是一個循序的目標摘要，以說明組織要遵循的流程改善路徑。當建立目標摘要時，組織應該專注一般執行方法與流程領域的從屬關係。假如有一般執行方法依賴某個流程領域，當該流程領域未9實行時，無論執行一般執行方法或是提供必要產9品，一般執行方法可能會比較沒有效果。 .雖然有許多理由使用連續式表述，但是能力度等級摘要所提供的評等能力，對於提供組織一個一般性的方式與其它組織進行比較是有限的。如果每一個組織選擇相同流程領域，能力度等級摘要可能會有用。然而，成熟度等級可以用於每一年組織比較，而且已經提供一組預先定義的流程領域。 因應這個情況，建立對等的階段式。對等的階段式組織能夠使用連續式表述的評鑑，以轉換能力度等級摘要到相關的成熟度等級的評等。 更有效用來描述對等的階段式的方式，是提供一個連續的目標摘要，每一個都是對等於階段式表述中的成熟度等級評等。這個結果是目標階段，它對等於階段式表述的成熟度等級。 圖顯示當使用連續式表述來對等於成熟度等級的第2級到第5級之必須達成的目標摘要一覽。每一個能力度等級欄位遮蔽的區域呈現對等於成熟度等級的目標摘要 ML CL1 CL2 CL3 CL4 CL5 名稱 縮寫 需求管理 REQM 2 專案規劃 PP 2 9請參考表一般目標與一般執行方法章節，已獲得更多資訊有關一般執行方法與流程領域的相依性 試著合而為一 49
CMMI for Development Version ML CL1 CL2 CL3 CL4 CL5 名稱 縮寫 專案監控 PMC 2 目標 供應商協議管理 SAM 2 摘要 2 度量與分析 MA 2 流程與產品品質PPQA 2 保證 建構管理 CM 2 需求發展 RD 3 技術解決方案 TS 3 產品整合 PI 3 確認 VER 3 驗證 VAL 3 組織流程專注 OPF 3 組織流程定義 OPD 3 目標 +IPPD +IPPD 摘要 3 組織訓練 OT 3 整合的專案管理 IPM 3 +IPPD +IPPD 風險管理 RSKM 3 決策分析與解決DAR 3 方案 組織流程績效 OPP 4 目標 摘要 4 量化專案管理 QPM 4 組織創新與推展 OID 5 目標 摘要 5 原因分析與解決CAR 5 方案 圖 目標摘要與對等的階段式 以下概述對等的階段式規則： 試著合而為一 50
CMMI for Development Version • 達成成熟度第2級，所有成熟度第2級指定的流程領域，必須達到或高於能力度第2級。 • 達成成熟度第3級，所有成熟度第2與第3級指定的流程領域，必須達到或高於能力度第3級。 • 達成成熟度第4級，所有成熟度第2、第3與第4級指定的流程領域，必須達到或高於能力度第3級。 • 達成成熟度第5級，所有流程領域，必須達到或高於能力度第3級。 這些對等的階段式的規則與表格是完整的。但是你可能會問為什麼目標摘要4 及5沒有擴展至CL4 與CL5。這個理由是成熟度第4級的流程領域，說明選擇的子流程已穩定為基礎，組織與專案的品質和流程績效目標在某種程度上。不是每一個流程領域，都會被選擇進行處理，以及CMMI並沒有預先假設哪一些流程領域，會被選擇進行處理。 所以，一個流程領域之能力度第4級的達到無法預先決定，因為這個選擇依賴組織中成熟度第4級之流程領域的實行。所以，圖並沒有顯示目標摘要4擴展至CL4，即使有些流程領域會達到能力度第4級。成熟度第5級的情況與目標摘要5是相似的。 對等的階段式之存在，不應該阻止連續式表述的使用者，建立擴展至能力度第3級以上的目標摘要。該目標摘要在某種程度上，由組織的選擇所決定，以符合組織經營目標。 試著合而為一 51
CMMI for Development Version 4 流程領域間的關係 在這一章節中，我們說明流程領域間的互動關係，以幫助你理解流程改善的組織觀點，以及哪些流程領域建立在其它流程領域的實行。用兩個維度來呈現流程領域間的關係。 第一個維度包含個別流程領域的互動關係，顯示資訊與成果如何由一個流程領域流到另一個流程領域，這一章節使用多個圖形與說明，這些互動關係幫助你理解流程領域改善的廣泛觀點。 第二個維度包含流程領域類的互動關係。有一些流程領域被分類為基本，而其它分類為進階。這些分類說明基本流程領域的實行應該早於進階流程領域，以確保符合成功實行進階流程領域的必要條件。 流程改善成功的起始必須由組織經營目標所驅動，舉例而言，一個典型的經營目標是降低產品推出市場所需要的時間。這個經營目標驅動流程改善目標可能是改善專案管理流程以確保如期交付，這些改善依賴專案規劃與專案監控流程領域中的最佳執行方法。 CMMI流程領域的四種類別 流程領域可分成下列四類： • 流程管理 • 專案管理 • 工程 • 支援 流程領域間的關係 52
CMMI for Development Version 雖然我們將流程領域分成上述四類，以討論其間的互動。然而不論它們如何歸類，流程領域間常有互動，且彼此相互影響。例如：決策分析與解決方案流程領域中提供解決正式評估的特定執行方法，該評估會使用於技術解決方案流程領域，以便從備選方案中選定技術解決方案。技術解決方案流程領域歸類在工程類流程領域，而決策分析與解決方案流程領域歸類在支援類流程領域。 瞭解CMMI模式流程領域間的互動，以及哪些是屬於基本或是進階的流程領域，將會幫助你用有益與有生產力的方式應用CMMI。以下各節說明各類別內流程領域間的互動關係，以及簡略的說明流程領域與其它類別流程領域的互動關係。不同類別的流程領域間的互動關係，說明在第二單元各流程領域的相關流程領域的參考資料，參見第二章可以得到更多關於參考資料的資訊。 流程管理 流程管理類流程領域涵蓋有關定義、規劃、推展、實行、監督、控制、評鑑、度量及流程改善之跨專案的各種活動。 CMMI的流程管理類流程領域，包括下列內容： • 組織流程專注 10• 組織流程定義+IPPD • 組織訓練 • 組織流程績效 • 組織創新與推展 基本流程管理類流程領域 基本流程管理類流程領域提供組織能力，以記錄與分享最佳執行方法、組織流程資產，以及跨組織的學習。 10當使用CMMI具有附加IPPD組時，組織流程定義(OPD)僅有一個目標(Goal)應用。 流程領域間的關係 53
CMMI for Development Version 圖提供基本流程管理類流程領域之間，以及與其他流程領域類間互動關係的鳥瞰圖。如圖所示，基於對組織流程和流程資產的現況優點和缺點之瞭解，組織流程專注流程領域協助組織規劃、實行及推展組織流程改善。 組織流程需要高階管理與目標專案與支援組在標準流程與資產的訓練OT組織經營目標訓練需要標準流程與其他資產專案管理 、支援與工程標準流程 、工作環境標準類流程領域OPF與其他資產OPD+IPPD資源與協調改善資訊(例如： 學習心得 、資料’及成果)流程改善建議 ；參OPF = 組織流程專注與定義 、評鑑與推OT = 組織訓練展流程OPD + IPPD = 組織流程定義(包含IPPD附加)圖 基本流程管理類流程領域 可由多種方法得到備選的組織流程改善方案。這些方法包括流程改善建議書、流程的度量、實行流程時的學習心得，以及流程評鑑和產品評估活動的結果。 基於組織流程需要與組織目標，組織流程定義流程領域建立與維護組織標準流程、工作環境標準及其他資產。其他資產包括生命週期模式的說明、流程調適指引及與流程相關的文件及資料。專案調適組織標準流程以產生已調適流程，而其他資產則用以支援該已調適流程的調適和實行。執行該已調適流程的經驗與工作產品，包括度量資料、流程說明、流程成果及學習心得，將適當的整合至組織標準流程和其他資產中。在附加IPPD的部份，組織流程定義+IPPD提供針對專案的IPPD規則與指引。 組織訓練流程領域界定組織的策略訓練需要和實務訓練需要，這些訓練通常是整個專案和支援團隊的共通需要。尤其是發展執行組織標準流程所需技能 流程領域間的關係 54
CMMI for Development Version 之發展和取得訓練。訓練的主要項目包括：有管理的訓練發展計畫、文件化的計畫、具有適當知識的人員，以及度量訓練計畫成效的機制。 進階流程管理類流程領域 進階流程管理類流程領域使組織具備進階的能力，以達成其品質與流程績效的量化目標。 圖是進階流程管理類流程領域之間及與其他流程領域類間互動關係的鳥瞰圖。每一進階流程管理類流程領域取決於發展與推展流程及支援資產的能力，而基本流程管理類流程領域提供這能力。 改善組織OID試行改善的成本與效益資料品質與流程績效目標 、度量、 基準與模式品質與流程績效目標 、度量 、基準與模式高階管理OPP專案管理 、支援與工程類流程領域達成經營目標的進度共同度量流程績效與能力資料發展與推展標準流程與其他資產的能力基本流程管理類流程領域OID = 組織創新與推展OPP = 組織流程績效圖 進階流程管理類流程領域 如圖所示，組織流程績效流程領域，由組織經營目標導引出品質與流程績效的量化目標。組織提供專案和支援團隊共同的度量、流程績效基準及流程績效模式。這些額外的組織資產對專案和支援團隊支援關鍵子流程的量化專案管理和統計管理。組織分析其已調適流程所蒐集的流程績效資料，以發展對產品品質、服務品質及組織標準流程之流程績效的量化瞭解。 組織創新與推展流程領域，選擇與推展所建議的漸進和創新改善方案，改善組織能力，以符合其品質流程領域間的關係 55
CMMI for Development Version 和流程績效目標。配合組織經營價值與目標，經授權之團隊參與有希望的漸進和創新改善方案的界定。必須以推展該備選改善方案的可能效益與可預見成本，以及可用於推展的資金等量化的理解為基礎，選擇推展改善方案。 專案管理 專案管理類流程領域，包含與專案的規劃、監督及控制有關的專案管理活動。 CMMI的專案管理類流程領域，包括下列內容： • 專案規劃 • 專案監控 • 供應商協議管理 11• 整合的專案管理+IPPD • 風險管理 • 量化專案管理 基本專案管理流程領域 基本專案管理流程領域解決有關建立與維護專案計畫、建立與維護承諾、依計畫監督進展、採取改善活動與管理供應商協議。 圖提供基本專案管理類流程領域之間，以及與其他流程領域類間互動關係的鳥瞰圖。如圖所示，專案規劃流程領域包括發展專案計畫、適當地納入關鍵人員的參與、取得對計畫的承諾，以及維護計畫。當使用IPPD時，關鍵人員代表的意義不只是產品與流程發展的技術專家，同時也是產品與流程發展的經營密切關係人。 11當使用CMMI具有附加IPPD組時，整合的專案管理(IPM)僅有一個目標(Goal)應用。 流程領域間的關係 56
CMMI for Development Version 狀況、 議題 、流程與產品矯正行動評估結果 ：度量與分析PMC矯正行動監督什麼重新規劃建造什麼做什麼工程與支援類流程領域PP承諾狀況、 議題與審查及監督結果計畫度量需要SAM產品組件需求技術議題完成的產品組件供應商協議驗收審查與測試供應商PMC = 專案監控PP = 專案規劃SAM = 供應商協議管理 圖 基本專案管理類流程領域 規劃由需求開始，定義產品與專案的需求(即圖中的「建造什麼」)。專案計畫包含專案所執行的各種專案管理和發展活動。專案審查對專案造成影響的其他計畫，這些計畫來自許多相關的關鍵人員，並建立這些相關的關鍵人員對專案貢獻的承諾。舉例而言，這些計畫包含建構管理、驗證及度量與分析。 專案監控流程領域，包括監督活動和採取矯正行動。專案計畫指明專案監督的適當層級、進度審查頻率及用以監督進度的度量。進度主要由實際進度和計畫進度的比較來決定。當實際的狀況和期望的數值有明顯差異時，應採取適當的矯正行動。這些行動可能包括重新進行規劃。 供應商協議管理流程領域，解決取得由供應商執行工作部分的專案需要。積極界定滿足專案需求的產品來源。選擇供應商與建立供應商協議，以管理供應商。藉由監督所選擇的工作產品與流程，追蹤供應商的進展與績效，適當地修訂供應商協議。執行驗收審查與測試供應商所生產的產品組件。 流程領域間的關係 57
CMMI for Development Version 進階專案管理類流程領域 進階專案管理類流程領域，解決包括：調適組織標準流程以建立專案的已調適流程的活動、從組織的工作環境標準制定專案工作環境、與相關關鍵人員(包括供應商)協調與合作、管理風險、組成與維持執行專案的整合團隊，以及量化管理專案的已調適流程。 圖提供進階專案管理類流程領域之間，以及與其他流程領域類間互動關係的鳥瞰圖。每一進階專案管理類流程領域，決定於專案規劃、監督及控制的能力，而基本專案管理類流程領域提供這能力。 QPM統計管理資料源於不穩定流程的流程績效目標 、量化目標 、統計管風險項目基準與模式理子流程 、專案原件與已定義流程組織標準流程界定風險工作環境標準RSKM支援資產IPM+IPPD指引則與D規PPI流程管理類流程領域學習心得規劃專風險分類與參專案與績效資料專案已定義流案願數、 風險狀況 、績景程與工作環境效分風險降低計畫及資享料矯正行動協調 、承諾與解決議題結構化團隊的產整合執行工程與支援品架構流程的團隊基本專案管理類流程領域工程及支援類流程領域IPM + IPPD = 整合的專案管理(包含IPPD附加)QPM = 量化專案管理RSKM = 風險管理 圖 進階專案管理類流程管理 整合的專案管理流程領域建立與維護由組織標準流程所調適的專案已調適流程，專案使用該流程以管理專案。專案使用組織流程資產，並貢獻結果到組織流程資產中。專案工作環境由組織工作環境標準所建立與維護。 流程領域間的關係 58 程流義定已與成組的案專
CMMI for Development Version 專案的管理確保與專案有關的關鍵人員可適時的協調合作。為達此目的必須進行：提供關鍵人員參與的管理；重要相依項目的識別、協商及追蹤；以及與有關的關鍵人員協商專案議題的解決方案。 在附加IPPD的部份，整合的專案管理+IPPD建立與維護專案的共同願景與專案的整合團隊結構。然後建立整合團隊來執行專案工作，確保適當的跨團隊合作。 雖然在專案規劃和專案監控流程領域已包含風險的界定與監督，但風險管理流程領域採取持續性和前瞻性的管理風險方法，這些活動包括風險參數的界定、風險評量及風險降低。 量化專案管理流程領域，應用量化和統計的技術，以管理流程績效和產品品質。專案的品質和流程績效的目標是建立在組織的目標上。專案的已調適流程包含流程元件和子流程，其流程績效是可以預測的。至少達成專案品質和流程績效目標的重要子流程所經驗的流程變異是可以理解的。當界定出流程變異的特殊原因時，應採取矯正行動（參見詞彙表中流程變異的特殊原因之定義）。 工程 工程類流程領域，包含所有工程專業領域皆可共用的發展活動和維護活動。工程類流程領域使用一般工程術語所撰寫，所以任何技術專業領域有關的產品發展流程（例如：軟體工程或機械工程），都可以使用它們進行流程改善。 工程類流程領域也將不同工程專業領域的流程，整合成單一的產品發展流程，以支援產品導向流程改善策略。這種策略是以基本的經營目標為對象而非特定的技術專業領域。這個作法可使流程有效的避免趨向組織的「高煙囪(難以溝通)」心態。 流程領域間的關係 59
CMMI for Development Version 工程類流程領域應用於發展領域(例如：軟體產品、硬體產品、服務或流程)中，任何產品或服務的發展。 IPPD的技術基礎，建立於健全的系統工程方法上，此方法包含產品生命週期階段的發展。工程類流程領域提供這個技術基礎。因而IPPD的實行，對工程類流程領域的特定執行方法有強化作用，特別強調同步發展和專注於產品生命週期的所有階段。 CMMI的工程類流程領域，包括下列內容： • 需求發展 • 需求管理 • 技術解決方案 • 產品整合 • 驗證 • 確認 圖提供六個工程流程領域之間互動關係的鳥瞰圖 流程領域間的關係 60
CMMI for Development Version REQM 需求產品與產品組件需求備選解決方案產品組件客戶RDTSPI產品 需求產品組件、工作產品與驗證及確認報告PI = 產品整合RD = 需求發展REQM = 需求管理VERVALTS = 技術解決方案VAL = 確認VER = 驗證客戶需要 圖 工程類流程領域 需求發展流程領域界定客戶需要，並將其轉換為產品需求。分析產品需求，以產生高層的、概念性的解決方案。然後將產品需求加以配置，以建立初使的產品組件需求。同時衍生其他有助於定義產品的需求(即衍生需求)，並將其配置到產品組件中。產品和產品組件需求，應以發展者所瞭解和使用的用語，清楚的說明產品績效、設計特色、驗證需求等。 需求發展流程領域提出對技術解決方案流程領域的需求，而在技術解決方案流程領域將需求轉換為產品架構、產品組件設計及產品組件本身(例如：程式製作及製造)。需求發展流程領域也提出對產品整合流程領域的需求，而在產品整合流程領域會將產品組件加以組合，並驗證其介面確保介面符合需求發展所提的介面需求。 需求管理流程領域的重點在於維護需求，此流程領域說明取得需求和管制需求變更的活動，確保其他的相關計畫和資料保持在最新狀況，並提供由客戶到產品，以及到產品組件的需求追溯性。 流程領域間的關係 61
CMMI for Development Version 需求管理確保需求變更已反映於專案計畫、活動及工作產品中。變更的週期可能衝擊到其他的工程類流程領域，所以需求管理是動態的，並常常遞迴於事件發生的順序。需求管理流程領域是有管制和有紀律之工程設計流程的基礎。 技術解決方案流程領域，發展產品組件的技術相關資料，以供產品整合流程領域或供應商協議管理流程領域使用。使用想要選擇出最佳化設計所建立的準則，檢查備選方案。這些準則因產品而有明顯的差異，取決於產品的類別、操作環境、績效需求、支援需求，以及成本或交付時程。選擇最終解決方案的任務，會利用決策分析與解決方案流程領域的特定執行方法。 技術解決方案流程領域引用驗證流程領域的特定執行方法，在設計期間和最終產品建造之前，執行設計驗證和同仁審查。 驗證流程領域確保所選定的工作產品，符合其特定的需求。驗證流程領域選擇工作產品和驗證方法，以驗證工作產品是否符合其特定的需求。驗證通常是漸進式的流程，由產品組件開始驗證，最後是完全組合之產品的驗證。 驗證也強調同仁審查。同仁審查是經證實的方法，可在產品發展與維護時及早移除缺失，並對發展與維護中的工作產品和產品組件，提供有用和深入的瞭解。 確認流程領域逐步地確認產品是否符合客戶需要。確認可以在操作環境或模擬的操作環境執行，與客戶協調「確認的需求」是這個流程領域的重要元件。 確認流程領域的範圍，包括產品、產品組件、經選定的中間工作產品及流程的確認。這些需要確認的元素可能時常需要再次驗證和再次確認。在確認時所發現的問題，通常在需求發展或技術解決方案流程領域中解決。 流程領域間的關係 62
CMMI for Development Version 產品整合流程領域包含產生可能的最佳整合順序、整合產品組件，以及交付產品給客戶有關之特定執行方法。 在實行產品整合流程時，產品整合流程領域使用驗證和確認的特定執行方法。在產品整合前，驗證流程驗證介面及產品組件間的介面需求是否相符，是整合流程的必要項目。在操作環境進行產品整合時，使用確認流程領域的特定執行方法。 工程類流程領域的遞迴與反覆 許多流程標準都同意，有兩種可以應用流程的方式。這兩種方式稱為遞迴與反覆。 遞迴發生在系統結構中，一個流程應用於系統元素的連續層次。一個應用的產出，被使用來作為在系統結構中另一個層級的輸入。例如：確認流程設計應用於整體組合產品、主要產品組件，以及組件之組件。你應用確認流程於產品多久，完全取決於產品的規模與複雜度而定。 反覆發生在同一個系統層次的流程重做。一個流程的實行產生新的資訊並回饋到其它相關流程。這個新的資訊一般會升高一些問題，而這些問題必須在結束流程前解決。舉例而言，大多數的反覆可能發生在需求發展與技術解決方案間。流程的重覆應用可以解決升高的問題，反覆可以確保在應用下一個流程前的品質。 工程類流程領域（例如需求發展或是驗證）會針對一個產品反覆實行，以確保在交付產品到客戶前，這些工程類流程領域已充分地滿足。而且，工程類流程領域可以應用於產品組件，舉例而言，有一些在驗證與確認流程領域中的流程所引起的問題，可以在需求發展或產品整合流程領域中的流程解決。這些流程領域的遞迴與反覆，使專案在交付產品到客戶前，可以確保所有產品組件的品質 流程領域間的關係 63
CMMI for Development Version 支援 支援類流程領域包含支援產品發展與維護的活動。支援類流程領域所解決的流程，在執行其他流程時會使用。一般而言，支援類流程領域解決的流程以專案為對象，而針對組織時，會以比較通用的方式解決流程。例如：所有的流程領域都會使用「流程與產品品質保證」，以提供所有流程領域的流程和工作產品的客觀評估。 CMMI的支援類流程領域，包括下列內容： • 建構管理 • 流程與產品品質保證 • 度量與分析 • 決策分析與解決方案 • 原因分析與解決方案 基本支援類流程領域 基本支援類流程領域，解決所有的流程領域都會使用的基本支援功能。雖然所有支援類流程領域依賴其他流程領域的輸入，基本支援類流程領域提供幫助實行幾個一般執行方法的支援功能。 圖提供基本支援類流程領域之間，以及與其他類流程領域間互動關係的鳥瞰圖 流程領域間的關係 64
CMMI for Development Version 度量分析品質與未符合議題所有流程領域MAPPQA流程與工作產資訊需要品、 標準與程序建構管理項基準、 稽核目變更要求報告CM圖 基本支援類流程領域 度量與分析流程領域提供特定執行方法，以支援所有的流程領域。該特定執行方法以度量方法，引導專案與組織調整度量需要與目標。該度量方法提供客觀的結果，可使用於作有根據的決策，並採取適當的矯正行動。 流程與產品品質保證流程領域提供特定執行方法，以支援所有的流程領域。該特定執行方法，依據流程說明、標準及程序，客觀地評估所執行的流程、工作產品及服務，並確保解決審查所發現的任何議題。藉由提供專案人員和各層級管理者，對專案生命週期中的流程與相關工作產品之適當的可見度及回饋，流程與產品品質保證流程領域可支援高品質產品與服務的交付。 建構管理流程領域使用建構識別、建構控制、建構狀態紀錄及建構稽核，建立與維護工作產品的完整性，支援所有的流程領域。納入建構管理的工作產品，包括交付客戶的產品、指定的內部工作產品、採購的產品、工具，以及用來產生與說明這些工作產品的其他項目。工作產品可能納入建構管理的例子包括：計畫、流程說明、需求、設計資料、圖表、產品規格、程式碼、編譯碼、產品資料檔，以及產品技術的出版品。 流程領域間的關係 65
CMMI for Development Version 進階支援類流程領域 進階支援類流程領域提供專案與組織改善過的支援能力。每一個進階支援類流程領域依賴其他流程領域的特定輸入或執行方法。 圖提供進階支援類流程領域間，以及與其他流程領域間互動關係的鳥瞰圖 CAR流程改善建議缺失與其他問題全部流程領域選定的議題正式評估DARCAR = 決策分析解決方案DAR = 原因分析解決方案 圖 進階支援類流程領域 利用原因分析與解決方案流程領域，專案成員辨識被挑選出來的缺失之原因及其它問題，並且採取行動以預防它們在未來發生。當專案已調適流程是界定缺失原因的主要目標時，他們針對組織標準流程，提出流程改善提案，全組織將防止缺失再發生。 決策分析與解決方案流程領域支援所有流程領域，決定哪一個議題應該要進行正式評估流程，並針對它們實行一個正式評估流程。 流程領域間的關係 66
CMMI for Development Version 5 使用CMMI模式 現今產品的複雜度要求組織如何用一個整合觀點從事經營。企業利用多個部門或群組產出產品與服務，CMMI可以降低跨企業的流程改善成本。 為了達到整合的觀點，CMMI架構包含一般術語、一般模式組件、一般評估方法與一般訓練工具。這個章節說明組織如何使用CMMI產品系列，改善它們的品質、降低它們的成本及最佳化它們的排程，除此之外判斷它們的流程改善計畫的工作滿意程度。 採用能力成熟度整合模式 研究顯示對於流程改善起步最有影響的，是透過有力高階管理者的贊助，建立強大的組織支援。為了得到有力高階管理者的贊助，讓高階管理者發覺別人使用CMMI進行流程改善的績效結果是很有助益的。 有關於CMMI績效結果的進一步資訊，請參考SEI 網站： [SEI 3]。 高階管理者一旦承諾成為流程改善贊助者，就必須主動參與以能力成熟度整合模式為基礎的流程改善工作。高階管理贊助者的執行活動包含（但是沒有限制）以下： • 影響組織採用CMMI。 • 選擇最佳的人員來管理流程改善工作。 • 親自監控流程改善工作。 • 成為流程改善工作顯而易見的提倡者與發言人。 使用CMMI模式 67
CMMI for Development Version • 確保提供足夠的資源使得流程改善的努力能夠成功 在充份的高階主管者贊助後，下一步驟為建立一個強大、技術上能勝任的流程組，此流程組代表相關的關鍵人員，以指引流程改善工作。 對於發展軟體密集系統為任務的組織，流程組可能包含代表跨組織之不同專業領域的工程師，以及其它根據經營需求被選擇來促進改善的成員。舉例來說，系統管理者可能會專注於資訊科技的支援，然而銷售代表可能專注於整合客戶的需要。這兩種成員可能會對流程組有很大的貢獻。 一旦你的組織決定採用CMMI，規劃可以由一個改SM善方法開始，例如IDEAL(初始、診斷、建立、行動與學習)模式。有關於IDEAL模式的進一步資訊，請參考SEI 網站： ideal/ [SEI 1] 你的流程改善計畫 使用CMMI產品系列，協助建立你的組織流程改善計畫。針對這個目的使用CMMI產品系列可以是相當非正式流程，涉及瞭解與應用CMMI最佳實務於組織中，或者，它可以是一個需要廣泛訓練、建立流程改善基礎建設、評鑑等的正式流程。 影響你計畫的選擇 應用CMMI到你組織的流程改善，你必須做出三個選擇： 1. 選擇組織的單位 2. 選擇模式 3. 選擇表述 選擇要納入你的流程改善計畫中的專案是重要的。如果你選擇的群組過大，可能會使初始改善時所需 使用CMMI模式 68
CMMI for Development Version 的工作量太多。選擇也應該要考慮到群組的同質性。(例如：儘管他們都是軟體工程師，但是他們是否都是工作在相同產品或是經營線等等)。 選擇要使用的模式是依據你的組織有興趣要進行改善的領域。你不僅必須選擇一個群集(例如：發展、採購或服務)，而且你也要決定是否要包含任何附加(例如：IPPD)。 因為CMMI模式的建立方式，選擇要使用哪種表述的流程有一些指引。如果你的組織喜歡成熟度等級與階段式表述，你的改善途徑已經定義好了。若你的組織喜歡連續式表述，你幾乎可以選擇任何流程領域或是一組流程領域來指引改善，雖然在做這些選擇時，應該考慮流程領域之間的相依性。 在流程改善計劃與活動進展時，其它重要的選擇也必須決定，包含該使用哪個評鑑方法、應該評鑑哪個專案、如何確保員工訓練和應該訓練哪些員工。 能力成熟度整合模式 CMMI模式說明已決定的最佳執行方法，組織發現這些執行方法有助於生產力並有用於達到它們的經營目標。 無論你的組織是哪種類型，應用CMMI最佳執行方法時，你必須使用專業判斷，針對你的現況、需求和經營目標來解釋它們。雖然流程領域描述一個組織承諾流程改善的特徵，你必須使用CMMI、你的組織、經營環境與特定情況的深入的知識，解釋流程領域。 當你開始使用CMMI，改善你的組織流程時，將你真實世界的流程與CMMI流程領域對應。這個對應幫助你做初始判斷，以及之後追蹤你的組織符合你所使用CMMI模式的等級，並界定改善的機會。 解釋執行方法時，考慮使用哪些執行方法，以及決定這些執行方法如何滿足流程領域目標的程度是重使用CMMI模式 69
CMMI for Development Version 要的。CMMI模式並沒有明確規定或暗指某些特定流程適合任何組織或專案。相反地，CMMI對於規劃與執行組織經營目標所選擇要改善的流程，說明最基本的必要準則。 CMMI執行方法有目的地使用非特定的片語，如同「相關的關鍵人員」、「適當的」、「如有需要」來相容於不同組織和專案的需要。專案的特定需要也可能會在生命週期中的不同時間點上有所差異。 使用能力成熟度整合模式的評鑑 很多組織發現度量它們進展的價值，藉由執行評鑑，然後獲得成熟度等級評等或是能力度等級達成摘要。這些評鑑通常為下列一到多個理由而執行： • 要決定組織流程對應到CMMI最佳執行方法到怎樣程度，以及界定要進行改善的領域。 • 為了向外部客戶與供應商報告組織流程對應到CMMI最佳執行方法的程度。 • 為了符合一個或多個客戶在合約上的需求。 組織使用CMMI模式評鑑，必須遵循Appraisal Requirements for CMMI(ARC)文件上的需求定義。這些評鑑方式專注在界定改善機會與比對CMMI最佳執行方法及組織內部流程。評鑑團隊使用CMMI模式與符合ARC之評鑑方法來指引它們的組織評估，並且報告他們的結論。然後這些評鑑結果被(例如：流程組)用來規劃組織的改善。 能力成熟度整合模式的評鑑需求 ARC文件說明數個評鑑類型的需求。一個完整可標竿學習的評鑑類型被定義成評鑑類型A，較不正規的方法被定義成評鑑類型B或C。ARC文件是設計用以協助跨評鑑方法的一致性，以及幫助評鑑方法之發展者、贊助者及使用者瞭解其他相關方法的權衡選擇 [SEI 2006a]。 使用CMMI模式 70
CMMI for Development Version 取決於評鑑目的與環境性質，一個類型可能會優先於其它類型。有些時候，自我評量、初始評鑑、快速察看、小型評鑑、漸增評鑑或是外部評鑑是適當的，然而其它時候一個正式基準比較評鑑是適當的。 以ARC的需求為基礎，一個特定的評鑑方法宣告為ARC Class A、ARC Class B或ARC Class C評鑑方法。這個ARC的需求是在設計這個方法時，由方法發展者所處理。 更多有關於ARC的資訊可以利用SEI網站 SCAMPI評鑑方法 一般已接受用來執行CMMI模式評鑑的方法為SCAMPI評鑑方法，SCAMPI方法定義文件(MDD)定義確保評鑑等級一致性的規則，對於跨組織的基準比較，評鑑必須確保一致性的等級，特定成熟度等級的達到或是一個流程領域的滿足對於不同被評鑑組織而言都必須代表相同的情況。 SCAMPI評鑑家族包含Class A、Class B與Class C評鑑方法。SCAMPI A是最嚴謹以及唯一會產出評鑑等級的方法。SCAMPI B針對模式範圍提供另一種選擇，但是執行方法的特性描述是固定於一個尺度上以及針對已被執行的一般方法上實行。SCAMPI C根據使用者定義的尺度提供廣大的選擇，包含針對流程執行規劃方法特徵。 更多有關於SCAMPI方法的資訊可以利用SEI網站 [SEI 2006b]。 評鑑考量 選擇會影響以CMMI為基礎的評鑑包含以下所述： 使用CMMI模式 71
CMMI for Development Version • 哪一個CMMI模式用來評鑑（對於群集而言，這個選擇可能是CMMI for Development模式與CMMI for Development +IPPD模式兩者之一）。 • 制定評鑑範圍，包含要評鑑的組織單位、要調查的CMMI流程領域以及要評鑑的成熟度等級與能力等級。 • 選擇評鑑方法。 • 選擇評鑑團隊成員。 • 由要評鑑的個體選擇要進行訪談的評鑑參與者。 • 建立評鑑產出（例如：評比或是特定案例發現）。 • 建立評鑑限制條件（例如：現場審查時間）。 SCAMPI MDD容許在評鑑中使用預定選項選擇。這些評鑑選項是設計用來幫助組織調準CMMI以符合其經營需求與目標。 SCAMPI評鑑計劃與結果的文件化必須包含評鑑選擇的說明、模式範圍與選擇的組織範圍。這份文件會確認評鑑是否有符合基準比較的需求。 當組織想要針對多個部門或群組進行評鑑時，CMMI整合方法使得模式的規模經濟與評鑑訓練成為可能。評鑑方法可以針對多個部門提供個別或是整合的結果。 12針對CMMI產品組的評鑑準則和用於評鑑其它流程改善模式的準則相同，這些準則包含以下： 13• 高階管理支持 • 專注在組織經營目標 • 訪談的機密 • 已文件化評鑑方法的使用 12看能力成熟度整合模式產品系列的詞彙定義 13經驗顯示最重要會影響流程改善與評鑑之成功的因素是高階管理者的支持 使用CMMI模式 72
CMMI for Development Version • 使用流程參考模式（例如：CMMI模式）作為基礎 • 團隊合作方法 • 專注於流程改善的活動 能力成熟度整合模式的相關訓練 無論你的組織現在是流程改善的新手或是已經熟悉流程改善模式，訓練是組織能力中採用CMMI的關鍵元素，SEI及其夥伴提供一系列基本課程，但是你的組織可能想要利用內部教育來補充這些課程，這個方法允許你的組織專注於提供更大的經營價值的區域。 SEI及其夥伴提供Introduction to CMMI課程，這個課程提供一個CMMI模式的基本簡介。SEI也提供Intermediate Concepts of CMMI課程給那些規劃要成為熟悉CMMI之採用與評鑑的人。舉例而言，在流程組中將要指引改善的人、想要教授Introduction to CMMI課程的人。目前有關於CMMI的訓練資訊可以利用SEI網站 使用CMMI模式 73
CMMI for Development Version 第二部份 一般目標與一般執行方法及流程領域 74
CMMI for Development Version 一般目標與一般執行方法及流程領域 75
CMMI for Development Version 一般目標及一般執行方法 概述 本節詳細的描述所有一般目標及一般執行方法－直接說明流程制度化的模式原件。 流程領域中，一般目標及一般執行方法出現在流程領域的最後。一般執行方法的詳細說明出現在一般執行方法之後，以表達這些執行方法如何獨特的應用於流程領域中。 一般目標及一般執行方法的全部內文在流程領域中不會重複（例如：省略了細部執行方法、筆記、範例，及參照）。取而代之的只有一般目標及一般執行方法的標題及敘述。當說明流程領域時，一般執行方法的詳細內容可參照本節。 流程制度化 制度化在流程改善中是很重要的觀念。在一般目標及一般執行方法敘述中，制度化意指流程已根深蒂固在工作的執行，以及執行流程的承諾與一致性。 當壓力來時，制度化流程仍被維持。然而，當需求及目標因流程而改變，流程的執行也需要改變以確保仍然有效。一般執行方法描述這些制度化觀念的活動。 制度化的等級包含於一般目標中，並以個別目標相關的流程名稱來表達，如表所示。 一般目標與一般執行方法及流程領域 76
CMMI for Development Version 表一般目標及流程名稱 一般目標 流程的發展 GG 1 已執行流程 GG 2 已管理流程 GG 3 已調適流程 GG 4 量化管理流程 GG 5 最佳化流程 在接下來的流程敘述中，將描述流程制度化的發展。 已執行流程 已執行流程是一種流程，為必要完成的工作以產生工作產品，並滿足流程領域的特定目標。 已管理流程 已管理流程是已執行流程，依據政策被規劃及執行；任用擁有充足資源的技術人員生產已控制的產出；涉及相關關鍵人員；被監督、控制及審查；以及遵循流程敘述來評估。 建立流程的需求及目標。工作產品的狀態及服務交付在已定義時間點（例如：在主要的里程碑及主要工作的完成）中的管理是顯而易見的。在工作執行中及相關關鍵人員間建立承諾，必要時進行修訂。由相關關鍵人員審查及控制工作產品，其工作產品及服務滿足特定的需求。 已執行流程及已管理流程間的主要區別在於被管理的程度。已管理流程是有規劃的（計畫可能是整合性計畫的一部分），並依照計畫來管理流程的執行。當正確的結果及績效很明顯與計畫脫軌時，應一般目標與一般執行方法及流程領域 77
CMMI for Development Version 採取矯正行動。已管理流程達到計畫的目標，且以制度化達成績效的一致性。 已調適流程 已調適流程是一個已管理流程，根據組織的調適指引調適組織標準流程，擁有已維護的流程敘述，並納入工作產品、度量與其他流程改善資訊至組織流程資產。 組織流程資產是與描述、執行及改善流程相關的人為產物，之所以被稱為資產，是因為透過發展或迎合組織經營目標而取得，且對於期望能提供現在及未來經營價值的組織來說，也算是投資。 建立並持續改善已調適流程的基礎－組織標準流程。標準流程描述已調適流程期望的基本流程元件。標準流程同時描述這些流程元件間的關係(例如：順序與介面)。組織層面的基礎架構，支援現在與未來使用已建立並持續改善的組織標準流程。有關「標準流程」的定義，請參見詞彙。 專案的已調適流程提供規劃、執行及改善專案工作和活動的基礎。專案不只有一個已調適流程（例如：一個用於發展產品，另一個用於測試產品）。 已調適流程的清楚陳述如下： • 目的 • 輸入 • 允入準則 • 活動 • 角色 • 度量 • 驗證步驟 • 輸出 • 允出準則 一般目標與一般執行方法及流程領域 78
CMMI for Development Version 已管理流程與已調適流程的主要區別，在於流程說明、標準及程序的應用範圍。在已管理流程中，流程說明、標準及程序應用於特定專案、團隊或組織功能群。同一組織內，兩個專案的已管理流程可能非常不同。 另一個主要的區別，在於已調適流程比已管理流程描述更詳細，執行更嚴謹，這意味著改善資訊更容易瞭解、分析與使用。最後，經由瞭解流程活動的相互關係，以及流程、工作產品和服務的細部度量，來管理已調適流程，並提供更多的洞察力。 已量化管理流程 已量化管理流程是一個已調適流程，使用統計和其它量化的技術進行控制。產品品質、服務品質及流程績效屬性，在整個專案中是可量測及控制的。 量化目標是根據組織標準流程的能力、組織企業的目標，與客戶、最終使用者、組織及流程執行者的需要，以及提供的可用資源而設定。執行流程的人直接從事量化的流程管理。 對生產產品的整體流程執行量化管理，並對整體流程績效有重要貢獻的子流程進行統計管理。針對這些已選定的子流程，蒐集流程績效的詳細度量資料，並進行統計分析。界定流程變異的特殊原因，並適當蒐集特殊原因的來源，以避免未來再度發生。 將品質和流程績效的度量結果，納入組織度量儲存庫，以支援未來以事實為基礎的決策。 流程績效的量化管理活動包含如下： • 界定置於統計管理的子流程 • 界定並度量產品與流程屬性，該屬性對品質與流程績效有重要貢獻 一般目標與一般執行方法及流程領域 79
CMMI for Development Version • 界定並處理子流程變異的特殊原因(以已選定的產品與流程屬性，及已選定進行統計管理的子流程為基礎) • 以界定績效在常態範圍為目標，管理每一已選定的子流程(例如：以已選定的產品與流程屬性為基礎，使子流程績效具統計穩定性與可預測性) • 預測流程能力，以符合已建立的量化品質與流程績效目標 • 當決定已建立的量化品質與流程績效目標無法符合時，採取適當的矯正措施 以上描述的矯正措施包括：改變目標，或確保相關關鍵人員對績效差距具量化的瞭解，並同意此績效差距。 已調適流程與已量化管理流程的主要區別，在於流程績效的可預測能力。已量化管理流程意指使用適當的統計和其它量化的技術，管理一個流程的一至多個子流程，因此可預測未來的流程績效。已調適流程僅提供量化的可預測性。 最佳化流程 最佳化流程是一個已量化管理流程，改變與適應已量化管理流程，以符合重要的趨勢與專案的經營目標。最佳化流程透過漸進與創新的技術改善，致力於持續的流程績效改善。界定、評估及推展那些處理流程變異的共同原因，缺失與其他問題根本原因的流程改善，和可度量的組織流程改善。以下列二者的量化瞭解為基礎選擇改善方案：流程改善方案對達成組織流程改善目標的預期貢獻，以及執行時的成本和對組織的衝擊。組織流程的績效是持續改善的。 系統化管理與推展已選定之漸進與創新的技術改善至組織。根據量化流程改善的目標來度量與評估推展流程改善的效果。 一般目標與一般執行方法及流程領域 80
CMMI for Development Version 最佳化流程，藉由改變平均值或減少變異的方式改變流程，以回歸穩定的狀態。這些改變意圖改善流程績效，以便達成組織已建立的流程績效目標。 已量化管理流程與最佳化流程的主要區別，在於最佳化流程藉由處理流程變異的共同原因而持續改善。已量化管理流程專注於克服流程變異的特殊原因，並提出統計上可預測的結果。雖然流程或許可以產生可預期的結果，但結果本身卻未必足以達成預期的目標。 流程間的關係 一般目標逐步發展，所以每個目標為下一個的基礎。結論如下： • 已管理流程是已執行流程 • 已調適流程是已管理流程 • 已量化管理流程是已調適流程 • 最佳化流程是已量化流程 如此，按照順序應用，一般目標描述漸進式制度化的流程，從已執行流程到最佳化流程。 達到流程領域的GG1，就等於達到該流程領域的一般目標。 達到流程領域的GG2，就等於可管理該流程領域的流程績效。有政策及有計畫執行流程，並提供資源，指派責任如何執行訓練流程，控制執行流程所選定的工作產品，等等。換句話說，規劃及監督該流程就像任何專案或支援活動一樣。 達到流程領域的GG3，假設存在組織標準流程，可調適為所使用的流程。調適可能對標準流程沒有任何改變，換句話說，所使用的流程與標準流程可能是完全一樣的。使用眾所皆知的標準流程也是調適，因為已決定不需更進一步修改。 一般目標與一般執行方法及流程領域 81
CMMI for Development Version 每個流程領域描述多樣活動，有些是重複執行的。你可能需要調適其中一個已執行的活動，來導出新功能或環境。舉例來說，你有一個發展或獲得組織訓練的標準，但沒有包含網路線上訓練。當準備發展或獲得網路線上課程時，你可能需要調適標準流程，來導出特定的挑戰及網路線上訓練的利益。 達到流程領域的GG4或GG5概念上是可實行的,但除不經濟外，也許在延長階段中，產品領域會趨於穩定，或者流程領域或專業領域是關鍵經營的驅動者。 一般目標及一般執行方法 本節描述所有一般目標及一般執行方法，相關的細部執行方法、筆記、案例，以及參照。以數列順序來排列一般目標，從GG1到GG5，一般執行方法也以數列順序及其所支援的一般目標來排列。 如同前面所述，細部執行方法、筆記、案例，以及參照不會在流程領域中重複出現；一般目標及一般執行方法的細節只在此出現。 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 此特定執行方法的目的在於產出工作產品與履行服務，該工作產品與服務是執行本流程所預期的結果。這些執行方法可能以非正式且未遵循書面的流程說明或計畫的方式來執行。這些執行方法執行的精確度端視管理或執行該項工作的人員而定，不同的人執行，其差異可能相當大。 一般目標與一般執行方法及流程領域 82
CMMI for Development Version GG 2 制度化已管理流程 將流程制度化為已管理流程。 GP 建立組織政策 建立並維護組織的政策，以規劃和執行流程。 此一般執行方法的目的，在於定義組織對流程的期望，並使組織中的關鍵人員都能瞭解這些期望。一般而言，資深管理人員擔負著建立與溝通組織之指導原則、方向及期望的責任。 來自高階管理階層的指示，不一定都稱為「政策」。不論如何稱呼或如何告知，存在於組織中的指示，都是對一般執行方法的期望。 GP 規劃流程 建立並維護用來執行流程的計畫。 此一般執行方法的目的，在於決定執行流程和達成已設定目標時所需的資源、準備執行流程所需的計畫、準備流程說明，以及取得相關關鍵人員對該計畫的同意。 實際上，每一流程領域對一般執行方法的應用不盡相同。當應用於專案監控流程領域時，本一般執行方法所說的規劃，可能經由專案規劃流程領域相關的流程來實現。當應用於專案規劃流程領域時，專案規劃流程領域的一般執行方法就會設定專案規劃流程的期望。必須瞭解本一般執行方法會強調在模式的其他地方已設定的期望，或設定新的期望。 有關建立及維護專案計畫，請參考專案規劃流程領域，以獲得更多資訊。 計畫的建立包含將計畫文件化及提供流程說明。計畫的維護包括進行更新以反應矯正措施，需求或目標的改變。 執行流程的計畫，包括下列基本項目： • 流程說明 一般目標與一般執行方法及流程領域 83
CMMI for Development Version • 流程之工作產品和服務的標準及需求 • 流程績效的特定目標(例如：品質、時程、循環時間，以及資源的使用) • 流程的活動、工作產品及服務間的相依性 • 執行流程所需的資源，包含資金、人力及工具 • 責任與授權的指派 • 執行與支援流程所需的訓練 • 控制的工作產品及其納管的層級 • 度量需求以深入瞭解流程、工作產品，以及服務的績效 • 納入已界定的關鍵人員 • 流程的監控活動 • 流程的客觀評估活動 • 流程和工作產品的管理審查活動 細部執行方法 1. 定義並記錄執行流程的計畫。 此計畫可能是一份獨立的文件，可能包含在另一範圍更廣的文件中，也可能散佈在不同的文件裡。若散佈在不同的文件裡，就必須確保任務分工的一致性。文件可用儲存媒體或紙本方式保存。 2. 定義並記錄流程說明。 流程說明包含相關的標準和程序，可視為流程規劃的一部分，或者當做規劃的參考。 3. 與相關的關鍵人員審查此計畫，並取得他們的同意。 此動作在於審查已規劃的流程是否符合現行的政策、計畫、需求及標準，以便向相關的關鍵人員提出保證。 一般目標與一般執行方法及流程領域 84
CMMI for Development Version 4. 視需要修訂計畫。 GP 提供資源 提供充分的資源，以執行流程、發展工作產品及提供流程服務。 此一般執行方法的目的，在於確保需要時能獲得執行流程所需的資源。資源包含充分的資金、合適的硬體設施、有技能的人力及適當的工具。 「充分」一詞的詮釋則視許多因素而定，而且隨時可能改變。不充分的資源可以靠增加資源，或減少需求、限制及承諾來解決。 GP 指派責任 指派流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 此一般執行方法的目的，在於整個執行流程和達成指定結果的過程中，都有人能負責任。被指派責任的人一定要取得適當的授權，以執行該責任。 可以用詳細的工作說明或文件(如執行流程的計畫)來指派責任。在流程的生命週期內，只要責任的指派和接受都能獲得保證，動態的責任指派也是執行本一般執行方法的一種合理方法。 細部執行方法 1. 指派整體性的責任與授權，以執行流程。 2. 指派責任及授權以執行流程的特定工作。 3. 確定被指派責任與授權的人，都能瞭解和接受。 GP 訓練人員 依需要訓練人員，以執行或支援流程。 此一般執行方法的目的，在於確保人員具有必要的技巧和專業知識，以執行或支援流程的執行。 提供執行工作的人員適當的訓練，並針對與執行工作人員互動的人員，實施概要訓練以提供指導。 一般目標與一般執行方法及流程領域 85
CMMI for Development Version 訓練的進行方式，包括自修、自我引導的訓練、線上學習、在職訓練、同仁指導及正式的課堂訓練等。 訓練可建立對流程的共識，以及傳授執行流程時所需的技巧和專業知識，所以訓練可提供協助以成功地執行流程。 有關訓練人員來執行或支援流程，請參考組織訓練流程領域，以獲得更多資訊。 GP 管理建構 將指定的流程工作產品，納入適當層級的控制。 此一般執行方法的目的，在於建立並維護流程的指定工作產品(或其說明)在它整個生命週期的完整性。 在執行流程的計畫中須特別界定什麼是指定的工作產品，以及該工作產品被納入適當控制的層級。 不同的工作產品，以及在不同的時間點，所適用的控制層級可能不同。對某些工作產品而言，進行版本管制可能就足夠。也就是不論過去或者現在，工作產品在某段時間所用的版本都很清楚，而且改變都在控制下進行。版本管制通常都由工作產品的擁有者(可能是個人、小組或團隊)單獨控制。 有時將工作產品置於正式或「基準(baseline)」的建構管理是非常重要的。這種類型的控制會在事先設定的時間點，定義和建立基準。這些基準會被正式審查及同意，並當做工作產品進一步發展的基礎。 有關將工作產品納入建構管理，請參考建構管理流程領域，以獲得更多資訊。 在版本控制與正式的控制之間，可能有其他層級的建構管理。在不同的時間點，經界定的工作產品可能納入不同層級的控制之下。 GP 界定並納入相關關鍵人員 依計畫界定並納入流程相關關鍵人員。 一般目標與一般執行方法及流程領域 86
CMMI for Development Version 此一般執行方法的目的，在於建立並維護關鍵人員在流程執行期間預期的參與程度。 依描述關鍵人員參與之適當計畫所述，將相關的關鍵人員納入。將關鍵人員適當地納入，以參與下列活動： • 規劃 • 決策 • 承諾 • 溝通 • 協調 • 審查 • 評鑑 • 需求定義 • 問題或議題的解決方案 有關納入關鍵人員的專案規劃，請參考專案規劃流程領域，以獲得更多資訊。 規劃關鍵人員參與的目的，在於確保關鍵人員與流程間必要的互動，但又不致於使太多相關的小組或個人阻礙流程的執行。 細部執行方法 1. 界定與流程有關的關鍵人員，並決定其參與的方式。 由輸入的供應者、輸出的使用者，以及流程活動的執行者之中，界定出相關的關鍵人員。一旦界定相關的關鍵人員，也會規劃相關的關鍵人員在流程活動的參與程度。 2. 將這些身分界定的方式，與專案規劃人員或其他適當的規劃人員一起分享。 3. 依規劃的方式，納入相關的關鍵人員。 一般目標與一般執行方法及流程領域 87
CMMI for Development Version GP 監控流程 依流程的執行計畫，監控流程，並採取適當的矯正措施。 此一般執行方法的目的，在於執行直接的日常流程監控。維護流程適當的能見度，以便於必要時，採取適當的矯正措施。流程監控包括流程或流程所產生之工作產品參數的度量工作。 有關監控專案與採行矯正措施，請參考專案監控流程領域，以獲得更多資訊。 有關度量，請參考度量與分析流程領域，以獲得更多資訊。 細部執行方法 1. 度量實際的績效，並與流程的執行計畫進行比較。 度量的對象為流程、工作產品及服務。 2. 審查流程的實際執行結果，是否與流程的執行計畫相符。 3. 與第一線負責流程的管理者審查流程的活動、進度及結果，並界定可能的問題。此審查的目的，在於提供第一線管理者對流程適當的瞭解。這類審查的進行時機可以是定期的，也可以在事件發生時才進行。 4. 界定並評估與流程的執行計畫有顯著差異的影響。 5. 界定發生在執行流程時和流程執行計畫的問題。 6. 當需求與目標不符合、議題被界定，或進度嚴重落後於流程執行計畫的要求時，採取矯正措施。 採取矯正措施之前，應先考慮其潛在風險。 矯正措施可涵蓋下列內容： • 採取補救措施，以修補有缺失的工作產品或服務 一般目標與一般執行方法及流程領域 88
CMMI for Development Version • 變更流程的執行計畫 • 調整資源包含人員、工具及其他資源 • 對已承諾事項的變更進行溝通 • 確保需求和目標的改變能符合要求 • 終止工作 7. 追蹤矯正措施直到結案。 GP 客觀評估遵循程度 依流程之說明、目標、標準及程序，客觀評估流程的遵循程度，並解決不符合的情況。 此一般執行方法的目的，在於提供可信的保證，確保流程依計畫執行，並遵循該流程的說明、標準及程序。某種程度來說，是藉由評估流程的已選定工作產品，來執行一般執行方法（有關「客觀評估」的定義，請參見詞彙。 有關遵循程度的客觀評估，請參考流程與產品品質保證流程領域，以獲得更多資訊。 基本上，非直接負責管理或執行流程活動的人員，可進行遵循程度的評估。大部分的情況下，由下列人員執行遵循度的評估：組織中非本流程或專案的人員或非本組織的人員。因此即使在流程面對壓力(如進度落後或預算超過)的情況下，亦可提供遵循程度的可信賴保證。 GP 與上層管理人員審查各狀況 與上層管理人員審查流程的活動、狀況及結果，並解決問題。 此一般執行方法的目的，在於使上層管理人員對流程的執行有適當的瞭解。 「上層管理人員(higher-level management)」包括高於直接負責流程管理階層之所有階層的管理人員。特別注意的是，上層管理者包含資深管理階層。本一般執行方法所指之審查的管理人員，是指提供負一般目標與一般執行方法及流程領域 89
CMMI for Development Version 責整體流程指導的管理人員，而不是執行日常流程監控的管理人員。 不同的管理人員對流程的資訊需要會有所不同。上述的審查能確保在流程規劃與執行時，有充分的資訊以進行決策。因此這類審查的進行時機，可以是定期的，也可以在事件發生時才進行。 GG 3 制度化已調適流程 將流程制度化為已調適流程。 GP 建立已調適流程 建立並維護已調適流程的說明。 此一般執行方法的目的，在於建立並維護流程的說明。流程的說明，為滿足某種特定狀況的需要，自組織標準流程調適而來。組織應有一套涵蓋流程領域的標準流程與調適指引，依據某專案或組織單位的需要調適該標準流程。有了已調適流程，會減少組織執行流程的差異，而且更能有效率地分享流程資產、資料及學習心得。 有關組織標準流程和調適指引，請參考組織流程定義流程領域，以獲得更多資訊。 有關建立及維護專案的已調適流程，請參考整合專案管理流程領域，以獲得更多資訊。 已調適流程的描述，提供流程規劃及流程執行的基礎，也提供流程相關活動、工作產品及服務的管理基礎。 細部執行方法 1. 自組織標準流程中，選擇已包含流程領域且最適合某專案或組織功能需要的流程組。 2. 根據組織的調適指引，調適已選定的流程，以建立已調適流程。 3. 確保已調適流程，已適當的說明組織的流程目標。 一般目標與一般執行方法及流程領域 90
CMMI for Development Version 4. 記錄已調適流程和調適的紀錄。 5. 視需要修訂已調適流程的說明。 GP 蒐集改善資訊 蒐集由規劃和執行流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 此一般執行方法的目的，在於蒐集進行規劃和執行流程時的資訊和產品。經由執行本一般執行方法，相關資訊和產品可存放於組織流程資產中，並可供正在(或將要)規劃和執行相同或相似流程的人員使用。相關資訊和產品存放於組織度量儲存庫和組織流程資產館中。 相關資訊，包括各種活動所投入的工作量、某特殊活動所注入或移除的缺失數，以及學習心得等。 有關組織度量儲存庫、組織流程資產館，以及納入資產館的工作產品、度量及改善資訊，請參考組織流程定義流程領域，以獲得更多資訊。 有關貢獻工作產品、度量及文件化的經驗，給組織流程資產，請參考整合專案管理流程領域，以獲得更多資訊。 細部執行方法 1. 將流程和產品的度量資料存放到組織度量儲存庫中。 流程和產品的度量資料，主要是組織標準流程所定義的共用度量。 2. 提交相關文件，以納入組織流程資產館。 3. 記錄流程的學習心得，以納入組織流程資產館。 4. 提出組織流程資產的改善建議。 一般目標與一般執行方法及流程領域 91
CMMI for Development Version GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 本執行方法的目的，在決定並自相關關鍵人員取得關於流程特定量化目標的協議，這些量化目標能表達產品品質、服務品質及流程績效。 有關如何設定專案已調適流程的子流程之量化目標，請參考量化專案管理流程領域，以獲得更多資訊。 量化目標可能為特定流程而定，或者它們可能為較廣的範圍而定義(例如：為一組流程)，在往後的案例，這些量化目標可能分配至某些被涵蓋的流程。 這些量化目標是用來判斷產品、服務與流程績效是否滿足客戶、最終使用者、組織管理及流程執行者的準則。這些量化目標超越傳統最終產品的目標，它們同時包括用來管理持續達成目標的中間目標。它們部分地反映組織標準流程的展示績效。當參與的流程是穩定的，並落入常態範圍的目標範圍內，這些量化目標應設定可能達成的數值。 細部執行方法 1. 建立流程有關的量化目標。 2. 分配量化目標至流程或其子流程。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定流程的能力，是否達成已建立之量化品質與流程績效目標。 本一般執行方法的目的是穩定一個或多個已調適(能力度第三級)流程的子流程之績效，該流程使用適當的統計和其它量化的技術，並對整體績效有重要貢獻。穩定已選定子流程來支援流程的預測能力，以達成已建立的量化品質與流程改善目標。 一般目標與一般執行方法及流程領域 92
CMMI for Development Version 有關為統計管理、監督子流程績效及其他穩定子流程績效方面，選擇子流程，請參考量化專案管理流程領域以獲得資訊。 一個穩定的流程展現沒有流程變異特殊原因的重要指標，在子流程的常態範圍所建立的限制下，穩定的子流程是可預測的。穩定子流程的變異，是由於一個穩定系統的偶然原因，而且變異的強度可小可大。 預測流程的能力以達成已建立的量化目標，需要量化瞭解子流程的貢獻，這對達成這些目標，以及持續建立和管理過渡的量化目標是重要的。 已選定的流程與產品度量納入組織度量儲存庫，以支援流程績效分析與未來以事實為基礎的決策。 細部執行方法 1. 統計管理一個或多個子流程績效，對整體流程績效有重要貢獻。 2. 預測流程的能力以達成已建立的量化目標，考慮統計管理子流程績效。 3. 將已選定的流程績效度量，納入組織流程績效基準。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保流程的持續改善，以實現相關的組織經營目標。 此一般執行方法的目的，在於選擇系統化推展流程與技術改善項目，以促成符合所建立的品質和流程改善目標。 一般目標與一般執行方法及流程領域 93
CMMI for Development Version 有關選定及佈置漸進及創新的改善方法，以可度量式地改善組織流程及科技，請參考組織創新及佈置流程領域，以獲得更多資訊。 靈活和創新的最佳化流程，有賴於被充分授權之工作團隊的參與，並且配合組織的經營價值與目標。可藉由加速學習和分享學習的方法，加強組織對改變和機會的快速反應能力。流程改善是每個人的責任，它也會導致持續改善的循環。 細部執行方法 1. 建立與維護量化流程改善目標，以支援組織的經營目標。 量化流程改善目標可能是個別流程的特定目標，或為較廣的範圍而定義(例如：一組流程)，而個別流程對達成這些目標做出貢獻。個別流程的特定目標通常由為較廣範圍所建立的量化目標配置而來。 這些流程改善目標，主要由組織的經營目標和流程能力的詳細瞭解衍生而來，這些目標是用來判斷流程績效是否量化改善組織能力，以滿足經營目標的準則。這些流程改善目標時常設定高於目前流程績效的數值，並且可能需要漸進與創新的技術改善，以達成這些目標。這些目標也可能經常修訂，以持續驅動流程改善(例如：當達成目標，可能設定再高於新流程績效的新數值)。 這些流程改善目標，可能與「建立流程的量化目標」一般執行方法的目標相同或更精確。只要它們可以作為成功流程改善的驅動與準則。 2. 界定流程改善項目，這些改善項目對流程績效會產生可度量的改善。 流程改善包括漸進的改變與創新的技術改善，通常個別規劃、執行與管理追求創新技術改善的工作量。時常執行試行。藉由分析流程績效與界定 一般目標與一般執行方法及流程領域 94
CMMI for Development Version 重要度量改善的特定機會，決定處理流程特定領域的工作量。 3. 以量化的預期效益、估計成本與影響，以及流程績效度量的改變為基礎，定義策略並管理已選定流程改善項目的推展。 量化估計這些改善項目的成本與效益，並度量實際的成本與效益。相對於組織量化的流程改善目標，效益是主要的考量。同時對組織標準流程與已調適流程進行改善。 管理流程改善的推展，包括變更的試行與適當的進行實施的調整、處理潛在與實際的推展障礙、減低對不斷努力的瓦解，以及管理風險。 GP 矯正問題的根本原因 界定並矯正流程之缺失與其他問題的根本原因。 此一般執行方法的目的，在於分析在量化管理流程中，所造成缺失和其它問題的原因，矯正此類缺失與問題的根本原因，並避免缺失及問題未來再度發生。 有關界定並矯正所選缺失的根本原因，請參考原因分析與解決方案流程領域，以獲得更多資訊。雖然原因分析與解決方案流程領域有專案背景，其亦可應用於其他背景的流程。 根本原因分析可有效益地應用在非量化管理的流程。但是本一般執行方法仍著重在量化管理流程，雖然在流程外可能發現最終根本原因。 應用一般執行方法 本節幫助你更了解一般執行方法，並提供資訊，以詮釋及應用一般執行方法到你的組織。 一般目標與一般執行方法及流程領域 95
CMMI for Development Version 一般執行方法對所有流程領域來說，是共通的元件，目的在於提醒你把事情做對，並期望成為模型元件。 舉例來說，當達成專案規劃流程領域的一般執行方法時，同時你也在建立及維護定義專案活動的計畫。應用一般執行方法到專案規劃流程領域，是在建立及維護計畫，以執行專案規劃流程()。當應用一般執行方法到本流程領域，是在提醒你去規劃與建立與專案計畫相關的活動。 當你滿足組織訓練流程領域的特定目標時，也就是在發展專案及組織人員的技巧及知識，以致於能更有效果及有效率地執行他們的角色。當應用同樣的一般執行方法()到組織訓練流程領域，特定執行方法能提醒你去規劃，與發展組織人員技巧及知識相關的活動。 支援特定執行方法的流程領域 一般目標及一般執行方法是模型元件，用以直接陳述跨組織的流程制度化，很多流程領域同樣地陳述支援一般執行方法實施的制度化過程。了解這些關係，將有助於有效率地執行一般執行方法。 這些流程領域包含一個或多個特定執行方法，實施時，可能完全執行一個特定執行方法，或者是產生用於執行特定執行方法的工作產品。 舉建構管理流程領域及”在適當控制層級中，選定流程的指定工作產品”的例子來說。為執行一個或多個流程領域的一般執行方法，你可能選擇執行建構管理流程領域，全部或部分地執行特定執行方法。 另一個是組織流程定義流程領域及”建立及維護已調適流程敘述”的例子。為執行一個或多個流程領域的一般執行方法，應該先執行組織流程定義流 一般目標與一般執行方法及流程領域 96
CMMI for Development Version 程領域，全部或部分地建立組織流程資產，用以執行特定執行方法。 表描述(1)支援執行特定執行方法的流程領域，及(2)特定執行方法及其緊密相關流程領域間的遞迴關係。流程改善利用存在於特定執行方法及其相關的流程領域間自然的合作方式，這兩種關係的種類要牢記。 表特定執行方法及流程領域關係 特定執行方法 在特定執行方法的實施上，執行方法如何遞迴地應用於14流程領域的角色 其相關的流程領域 GP 專案規劃：對所有與專案相應用於專案規劃流程規劃流程 關的流程領域（除專案規劃是”規劃計畫”的特點，並包含本身外），專案規劃流程可規劃專案的規劃活動 以完全實行。 GP 專案規劃：部分的專案規劃 提供資源 流程，實行了”專案規劃執行專案所需資源的GP 計畫”，對所有與專案相關指派責任 的流程領域(也許除最初的 專案規劃本身外) ，支援及的實行，並藉由界定所需流程、角色，及責任，以確保專案所需的適當任職、機構、設備，以及其他資產，是安全的。 14 當一般執行方法與流程領域無直接關係，混淆的風險就會降低，所以在表中並不描述所有遞迴的關係（例如：一般執行方法、及） 一般目標與一般執行方法及流程領域 97
CMMI for Development Version 特定執行方法 在特定執行方法的實施上，執行方法如何遞迴地應用於14流程領域的角色 其相關的流程領域 GP 組織訓練：組織訓練流程支應用於組織訓練流程，訓練人員 援的實行，可藉由訓包含執行組織訓練活動的訓練策略或組織全面的訓練需練，其陳述了管理、創造及求，給將執行或支援流程的完成訓練所需要的技巧。 人員，以應用到所有流程領域。 專案規劃：專案規劃流程實行專案規劃”執行專案所需的知識及技巧計畫”，以及組織訓練流程，對於所有專案相關的流程領域，支援的完整實行。 GP 建構管理：對於所有專案相應用於建構管理流程，建構管理 關的流程領域，以及部分組包含了建構管理產生之工作織流程領域，建構管理流程產品的變更及版本控制。 可完整實行。 一般目標與一般執行方法及流程領域 98
CMMI for Development Version 特定執行方法 在特定執行方法的實施上，執行方法如何遞迴地應用於14流程領域的角色 其相關的流程領域 GP 專案規劃：專案規劃流程應用於專案規劃流程，界定及涉及相中，有關實行專案規劃包含了專案規劃活動中，相關關鍵人員 ” 關鍵人員參與計關關鍵人員的參與。 畫”，對於所有專案相關的應用於專案監控流程，流程領域，同樣可完整實行包含相關關鍵人員在專案監的關鍵人員部分（前控活動的參與。 二個細部執行方法）。 GP 應用於整合專案管理專案監控：專案監控流程流程，包含了相關關鍵中，有關實行專案專案監控人員在整合專案管理活動的”監督關鍵人員參參與。 與”， 對於所有專案相關的流程領域，有助於實行第三個細部執行方法。 整合專案管理：整合專案管理流程中，有關實行整合專案管理”管理關鍵人員參與”，對於所有專案相關的流程領域，有助於實行第三個細部執行方法。 GP 專案監控管理：對於所有專應用於專案監控流程，監控流程 案相關的流程領域，專案監包含監控專案的監控活動。 控管理流程可完整實行。 度量與分析：對所有流程，而不只是專案相關流程來說，度量與分析流程領域提供有關度量、分析與記錄資訊的一般指引，可用於建立度量，來監督流程的實際績效。 一般目標與一般執行方法及流程領域 99
CMMI for Development Version 特定執行方法 在特定執行方法的實施上，執行方法如何遞迴地應用於14流程領域的角色 其相關的流程領域 GP 流程與產品品質保證：對於應用於流程與產品品質目標評估遵循 所有流程領域（也許除了流保證流程，包含品質保證活程與產品品質保證本身），動的目標評估。 流程與產品品質保證流程可完整實行。 GP 專案監控管理：在專案監控 與更高管理階流程中，有關實行專案監控級審查狀態 ”進行進度審查”及”進行里程碑審查”，對於所有專案相關流程領域，支援的實行，其完整度端視這些審查的較高管理階級而定。 GP 整合專案管理：在整合專案應用於整合專案管理流建立已調適流管理流程中，有關實行整合程，包含為了整合專案管理程 專案管理”從專案成立活動，而建立已調適流程。 到整個專案週期，建立及維護專案已調適流程”，對於所有專案相關的流程領域，可完整實行。 組織流程定義：對所有流程，而不只是專案相關流程來說，組織流程定義流程建立實行所需的組織流程資產。 一般目標與一般執行方法及流程領域 100
CMMI for Development Version 特定執行方法 在特定執行方法的實施上，執行方法如何遞迴地應用於14流程領域的角色 其相關的流程領域 GP 整合專案管理：在整合專案應用於整合專案管理流收集改善資訊 管理流程中，有關實行專案程，包含收集從規劃及執行管理”提供工作產品、整合專案管理活動中，所取度量及文件化的經驗給組織得的改善資訊。 流程資產”，對於所有專案相關的流程領域，可完整實行。 組織流程專注：在組織流程專注流程中，有關實行組織流程專注”從規劃及執行流程中，取得流程相關工作產品、度量及改善資訊，並合併到組織流程資產中”， 對於所有流程領域，可部分或完整實行。 組織流程定義：對所有流程，組織流程已調適流程建立實行所需的組織流程資產。 一般目標與一般執行方法及流程領域 101
CMMI for Development Version 特定執行方法 在特定執行方法的實施上，執行方法如何遞迴地應用於14流程領域的角色 其相關的流程領域 GP 量化專案管理：量化專案管應用於量化專案管理流建立流程的量理流程中，有關實行量化專程，包含建立量化專案管理化目標 案管理”建立及維護專活動的量化目標。 案的品質及流程績效目應用於組織流程績效，標”，對於所有專案相關流包含建立組織流程績效活動程領域，從各特定流程取得的量化目標。 的目標，可支援的實行。如果這些目標為量化專案管理細部執行方法5及8的一部分，則量化專案管理流程完整地實行。 組織流程績效：在組織流程績效流程中，有關組織流程績效”建立及維護組織品質及流程績效的量化目標”，對於所有流程領域，支援的實行。 GP 量化專案管理：量化專案管應用於量化專案管理流穩定細部流程理流程中，有關實行量化專程，包含在量化專案管理活績效 案管理GP2”統計管理細部動中，已選定細部流程的穩流程績效”，對於所有專案定性。 相關流程領域，以及相對應的統計管理細部流程，可支援的完整實行。 組織流程績效：對所有流程，而不只是專案相關流程來說，組織流程績效流程建立實行所需的組織流程資產。 一般目標與一般執行方法及流程領域 102
CMMI for Development Version 特定執行方法 在特定執行方法的實施上，執行方法如何遞迴地應用於14流程領域的角色 其相關的流程領域 GP 組織創新推展：組織創新推應用於組織創新推展流確保持續流程展流程，對於所有流程領程，包含在組織創新及推展改善 域，可完整實行，提活動中，確保持續流程改供品質及流程績效目標給已善。 調適的組織。（如果已實行組織流程績效流程領域，就如同是後者）。 GP 原因分析及解決方案：對於應用於原因分析及解決矯正問題的根所有專案相關的流程領域，方案流程，包含在原因分析本原因 原因分析及解決方案流程可及解決方案活動中，界定缺完整實行。 失的根本原因及其他問題。 這些流程領域通常較早以完整或部分來實行，提早或同時與相關的一般執行方法共同執行，以提供一般執行方法在這些流程領域的相依性，以及很多流程領域所呈現更多完整的觀點。 應用一般執行方法到特定的流程領域，似乎是多餘的，但事實上，並非如此。這樣來想也許是正常的，應用”建立已調適流程”，到專案規劃及專案監控流程領域，效果如同整合專案管理的第一個特定執行方法。“使用從組織標準流程調適的已調適流程，來執行專案”。 雖然有些部分是重疊，一般執行方法應用於這兩個流程領域中，提供已定義流程涵蓋了專案規劃及專案監控活動。已調適流程無需涵蓋支援活動（如建構管理）、其他專案管理流程（如供應商協議管理），或工程流程。相反地，整合專案管理流程領域的專案已調適流程，涵蓋了所有適當的專案管理、工程，和支援流程。 一般目標與一般執行方法及流程領域 103
CMMI for Development Version 一般目標與一般執行方法及流程領域 104
CMMI for Development Version 原因分析與解決方案 成熟度第五級的支援類流程領域 目的 原因分析與解決方案(Causal Analysis and Resolution, CAR)的目的，在於界定造成缺失和其他問題的原因，並採取行動以避免未來再度發生。 簡介 原因分析與解決方案，包括下列活動： • 界定並分析造成缺失和其他問題的原因 • 採取特定行動，以移除造成缺失及問題的原因，並避免此類缺失及問題未來再度發生 藉由原因分析與解決方案以改善品質和生產力避免將缺失導入產品。在缺失發生後再進行偵測是不符合成本效益的。更有效的方式是，將原因分析與解決方案的活動整合到專案的每個階段，以避免缺失的發生。 既然缺失和問題可能發生於先前的其他專案或現有專案的稍早階段，原因分析與解決方案的活動可以做為各專案間溝通學習的機制。 分析所發生的缺失和其他問題的種類，以界定其趨勢。依對已調適流程及其如何實施的瞭解為基礎，判定缺失的根本原因及未來可能發生的地方。 原因分析也可以運用於與缺失無關的問題上，例如：原因分析可用來改善品質屬性，如週期時間等。這種分析可由改善建議、模擬、動態系統模型、工程分析、新的經營指示或其他項目所啟動。 原因分析與解決方案(CAR) 105
CMMI for Development Version 當對所有的缺失進行原因分析並不實際時，必須在預估的投資與預估的品質、生產力、週期時間的報酬之間做取捨，選擇缺失目標。 在某些情況下，也許需要新的度量來分析流程變更的影響，但度量流程應準備妥當，並使用已定義的度量。 有關建立度量與分析的目標、界定待執行的度量與分析、取得和分析度量資料，以及報告結果等，請參考度量與分析流程領域，以獲得更多資訊。 原因分析與解決方案活動提供專案一個機制，以便在專案層級評估其流程，並找尋可實施的改善措拖。 當改善措施在專案層級的實施被認定為有效時，這些資訊可擴展至組織層級。 有關經由所建議的改善措施和行動建議，以改善組織層級的流程，請參考組織創新與推展流程領域，以獲得更多資訊。 本流程領域的助益性資料的前提為特定執行方法適用量化管理流程。在不考慮此前提的情況下，本流程領域的特定執行方法也可適用，不過會降低所產生的價值。 有關「穩定流程」和「流程變異的共同原因」的定義，請參見詞彙。 相關流程領域 有關流程績效的分析與已選定之專案流程的能力度之度量的產生，請參考量化專案管理流程領域，以獲得更多資訊。 有關針對組織流程和技術改善的選擇與推展，請參考組織創新與推展流程領域，以獲得更多資訊。 原因分析與解決方案(CAR) 106
CMMI for Development Version 有關建立度量與分析的目標、界定待執行的度量與分析、取得和分析度量資料，以及報告結果等，請參考度量與分析流程領域，以獲得更多資訊。 原因分析與解決方案(CAR) 107
CMMI for Development Version 特定目標及執行方法摘要 SG 1決定造成缺失的原因 SP 選擇待分析的缺失資料 SP 分析原因 SG 2處理造成缺失的原因 SP 實施行動建議方案 SP 評估變更的效果 SP 記錄相關資料 各目標的特定執行方法 SG 1 決定造成缺失的原因 有系統地決定造成缺失和其他問題的根本原因。 根本原因是缺失的源頭，若移除根本原因，那麼就移除或減少缺失。 SP 選擇待分析的缺失資料 選擇缺失和其他問題資料，以進行分析。 典型的工作產品 1. 選定待進一步分析的缺失和問題資料 細部執行方法 1. 蒐集相關的缺失或問題資料。 相關缺失資料，舉例如下： • 客戶反應的缺失 • 終端使用者反映的缺失 • 同仁審查時發現的缺失 • 測試時發現的缺失 原因分析與解決方案(CAR) 108
CMMI for Development Version 有關問題資料，舉例如下： • 需要矯正措施的專案管理問題 • 流程能力的問題 • 流程期間的度量 • 各流程的實獲值度量(例如成本績效指標) • 資源流量、適用率、或反應時間度量 有關工作產品的驗證，請參考驗證流程領域，以獲得更多資訊。 有關統計化管理，請參考量化專案管理流程領域，以獲得更多資訊。 2. 決定需進一步分析的缺失和其他問題。 在決定哪些缺失需進一步分析時，應考慮缺失的影響、發生頻率、缺失間的相似性、分析成本、所需的時間和資源、安全性考量等等。 選擇缺失和其他問題的方法，舉例如下 • 柏拉圖分析 • 直方圖 • 流程能力分析 SP 分析原因 針對所選的缺失和其他問題，進行原因分析，並提出處理的行動方案。 原因分析的目的，在於藉由分析相關資料和產生實施的行動建議，以發展所界定問題的解決方案。 典型的工作產品 1. 行動建議方案 細部執行方法 1. 與負責執行該項工作的人共同分析原因。 原因分析與解決方案(CAR) 109
CMMI for Development Version 通常以會議的方式，與瞭解缺失和其他問題的人，針對所選的缺失和其他問題，共同進行原因分析的研究，而最瞭解缺失的人通常也是負責執行該項工作的人。 執行原因分析的時機，舉例如下： • 當穩定流程無法滿足它的品質和流程績效目標時 • 在工作執行期間，當缺失數目或已界定問題數量多到需要召開額外會議時 • 當工作產品與其需求之間存在非預期的差異時 有關達成專案品質和流程績效目標，請參考量化專案管理流程領域，以獲得更多資訊。 2. 分析所選的缺失和其他問題，以決定它們的根本原因。 在界定根本原因之前，可依缺失的類型和數量先將它們分類。 決定根本原因的方法，舉例如下： • 因果圖，即魚骨圖 • 查核表 3. 依據根本原因，將所選的缺失和其他問題分類進行。 原因的類別，舉例如下： • 訓練不足 • 溝通中斷 • 沒有說明工作的所有細節 • 人為操作錯誤(例如：打錯字) • 流程缺失 原因分析與解決方案(CAR) 110
CMMI for Development Version 4. 建議並記錄需要採行的行動方案，以避免未來發生類似的缺失或其他問題。 建議的行動方案可能包括對下列的變更： • 有問題的流程 • 訓練 • 工具 • 方法 • 溝通 • 工作產品 特定的行動方案，舉例如下： • 針對共通性的問題和技術，提供訓練以避免再度發生 • 變更流程，使易犯錯的步驟不再發生 • 流程的局部或全部自動化 • 將流程活動重新排序 • 增加避免缺失的流程步驟，例如：增加工作啟動會議，以審查共同的缺失和行動方案，並避免再度發生 行動建議方案，通常記錄下列各項： • 行動建議的發起人 • 問題說明 • 缺失原因說明 • 缺失原因類別 • 提出問題的階段 • 界定出缺失的階段 • 行動建議的說明 • 行動建議的類別 原因分析與解決方案(CAR) 111
CMMI for Development Version SG 2 處理造成缺失的原因 有系統地處理造成缺失和其他問題的根本原因，以避免未來再度發生。 專案依已妥善調適的流程運作，若專案仍然發生問題，專案會系統化的分析其運作方式，並實施流程變更，以消除所選問題的根本原因。 SP 實施行動建議方案 實施原因分析所發展的行動建議方案。 行動建議方案描述必要工作，用以移除經過分析之缺失和問題的根本原因，並避免它們再度發生。 只有證明此變更有價值，才可考慮將其廣泛實施。 典型的工作產品 1. 已選定要實施的行動建議 2. 改善建議 細部執行方法 1. 分析各種行動建議，並決定優先順序。 排定行動建議優先順序的準則，包括： • 未處理缺失的意涵 • 實施流程改善措施以避免缺失的成本 • 對品質的預期影響 2. 選擇將實施的行動建議。 3. 產生實施行動建議的行動項目。 原因分析與解決方案(CAR) 112
CMMI for Development Version 行動項目所提供的資訊，舉例如下： • 負責實施的人 • 受影響領域的描述 • 必須被告知行動狀況的人 • 下一次進行狀況審查的日期 • 關鍵決策的理由 • 實施行動的描述 • 界定和矯正缺失所需時間和成本 • 不解決問題的預估成本 實施行動建議必須執行下列各項工作： • 指派工作 • 協調執行工作的相關人員 • 審查各項結果 • 追蹤各行動項目至結案為止 針對特殊複雜的變更，可先進行實驗。 實驗的舉例如下： • 使用暫時性已修訂的流程 • 使用新工具 行動項目可指派給原因分析團隊、專案團隊，或組織內其他的成員。 4. 界定並移除可能存在於其他流程和工作產品的類似缺失。 5. 界定並記錄組織標準流程的改善建議。 有關組織標準流程之改善建議的選擇與推展，請參考組織創新與推展流程領域，以獲得更多資訊。 原因分析與解決方案(CAR) 113
CMMI for Development Version SP 評估變更的效果 評估變更在流程績效上所產生的效果。 有關流程績效的分析與已選定流程的能力度之度量的產生，請參考量化專案管理流程領域，以獲得更多資訊。 一旦在專案內推展已變更的流程，應檢查變更所產生的效果，以便蒐集相關證據來證明該流程變更確已矯正問題和改善績效。 典型的工作產品 1. 績效和績效變更的度量 細部執行方法 1. 適當的度量專案已調適流程的績效變更。 本細部執行方法決定所選的變更對流程績效是否有正面影響及其影響程度。 對專案已調適設計流程的績效變更，以設計文件在缺失密度的變更為例：經由同仁審查，比較實施改善措施前後所統計的缺失數變化。在統計流程控制圖表上，這些變更可由其平均值的變化看出。 2. 適當的度量專案已調適流程的能力。 本細部執行方法決定已挑選的變更對滿足其品質與流程績效目標的能力是否有正面影響，該品質目標係由相關的關鍵人員決定。 對專案已調適設計流程的能力變更，以將該流程停留在流程規格內之能力的變更為例：經由同仁審查，比較實施改善措施前後所統計的缺失幅度變化。在統計流程管制圖上，這些變更可由其已降低的管制區間看出。 原因分析與解決方案(CAR) 114
CMMI for Development Version SP 記錄相關資料 記錄原因分析和解決方案相關資料，以供專案和組織使用。 記錄資料，使其他專案和組織可做適當的流程變更並達成相似結果。 記錄下列資料： • 分析之缺失和其他問題的資料 • 決策的理由 • 原因分析會議的行動建議方案 • 行動建議方案所導出的行動項目 • 原因分析與解決方案活動的成本 • 解決方案之已調適流程績效變更的度量 典型的工作產品 1. 原因分析與解決方案的紀錄 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施原因分析與解決方案流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 原因分析與解決方案(CAR) 115
CMMI for Development Version 僅適用於階段式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行原因分析與解決方案流程。 詳細說明： 本政策建立組織期望，以界定及有系統的處理造成缺失及其他問題的根本原因。 GP 規劃流程 建立並維護執行原因分析與解決方案流程的計畫。 詳細說明： 本計畫用於執行原因分析與解決方案可包括(或參照)專案規劃流程領域的描述專案計畫。不同於本流程領域的特定執行方法所描述的行動建議和相關的行動項目。本一般執行方法所謂的計畫，乃在說明專案整體的原因分析與解決方案流程(可能由組織所維護的標準流程調適而成)。而流程的行動建議和相關的行動項目則強調移除特定根本原因所需的活動。 GP 提供資源 提供充足的資源，以執行原因分析與解決方案流程、發展工作產品及提供流程服務。. 原因分析與解決方案(CAR) 116
CMMI for Development Version 詳細說明： 提供的資源，舉例如下： • 資料庫系統 • 流程模型工具 • 統計分析套裝軟體 • 工具、方法及分析技術，如：石川圖(Ishikawa)或魚骨圖、柏拉圖分析、直方圖、流程能力研究、控制圖等 GP 指派責任 指派原因分析與解決方案流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援原因分析與解決方案流程。 詳細說明： 訓練主題，舉例如下： • 品質管理方法(例如：根本原因分析) GP 管理建構 將指定的原因分析與解決方案流程工作產品，納入適當層級的控制。 原因分析與解決方案(CAR) 117
CMMI for Development Version 詳細說明： 納入控制的工作產品，舉例如下： • 行動建議方案 • 已選定要實施之改善建議的行動建議 • 原因分析與解決方案的紀錄 GP 界定並納入相關的關鍵人員 依計畫界定並納入原因分析與解決方案流程相關的關鍵人員。 詳細說明： 關鍵人員參與的活動，舉例如下： • 進行原因分析 • 評量行動建議 GP 監控流程 依本流程的執行計畫，監控原因分析與解決方案流程，並採取適當的矯正措施。 原因分析與解決方案(CAR) 118
CMMI for Development Version 詳細說明： 用於監控的度量及工作產品，舉例如下： • 已移除之根本原因的數目 • 原因分析與解決方案流程中每個案例在品質或流程績效的改變 • 執行已選定行動建議活動的時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估原因分析與解決方案流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 決定缺失的原因 • 處理造成缺失的原因 審查的工作產品，舉例如下： • 已選定要實施的行動建議方案 • 原因分析和解決方案的紀錄 GP 與上層管理人員審查各狀況 與上層管理人員審查原因分析與解決方案流程的活動、狀況及結果，並解決問題。 原因分析與解決方案(CAR) 119
CMMI for Development Version 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義原因分析與解決方案流程的說明。 GP 蒐集改善資訊 蒐集由規劃並執行原因分析與解決方案流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 詳細說明： 工作產品、度量、度量結果及改善資訊的例子，包括如下： • 行動建議方案 • 尚未結案之行動建議數，以及其帳齡 • 行動建議狀態報告 原因分析與解決方案(CAR) 120
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護原因分析與解決方案流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定原因分析與解決方案流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保原因分析與解決方案流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正原因分析與解決方案流程之缺失與其他問題的根本原因。 原因分析與解決方案(CAR) 121
CMMI for Development Version 建構管理 成熟度第二級的支援流程 目的 建構管理(Configuration Management, CM)的目的，在使用建構識別、建構控制、建構狀態紀錄及建構稽核，來達到建立與維護工作產品之完整性。 簡介 建構管理流程領域，包含下列活動： • 界定所選定之工作產品的建構，這些工作產品在特定的時間點會組成基準 • 管制建構項目的變更 • 建立或提供規格，以便從建構管理系統建造工作產品 • 維護基準的完整性 • 提供正確的狀態和目前的建構資料給發展人員、最終使用者及客戶 納入建構管理的工作產品，包含交付客戶的產品、指定的內部工作產品、取得的產品、工具，以及其他用以產生或描述這些工作產品的項目。(有關「建構管理」的定義，請參見詞彙。) 供應商和專案可能都需要將取得的產品納入建構管理。供應商協議中應建立執行建構管理的規定。應建立並維護用以確保資料之完整性和一致性的方法。 請參考「供應商協議管理」流程領域，以獲取更多有關建立及維護供應商的協議資訊。 建構管理(CM) 122
CMMI for Development Version 可能納入建構管理的工作產品，舉例如下： • 計畫 • 流程說明 • 需求 • 設計資料 • 圖表 • 產品規格 • 程式碼 • 編譯器 • 產品資料檔 • 產品技術文件 工作產品的建構管理可以在許多不同層次的精細度上執行。建構項目可分解為建構組件和建構單元。本流程領域只使用「建構項目」這個術語。因此，在這些執行方法中，在適當的時候，建構項目可詮釋為「建構組件」或「建構單元」。(有關「建構項目」的定義，請參見詞彙) 基準是建構項目持續演進的穩定基礎。 舉例來說，已核可的產品說明是一個基準，它包含需求、需求追溯表、設計、特定專業項目及使用者文件，成為內部一致的版本。 當基準發展完成，就會納入建構管理系統。基準的變更與自建構管理系統所建造之工作產品的發行，經由建構管理的建構管制、變更管理及建構稽核等功能，進行有系統的管制與監督。 本流程領域不只適用於專案的建構管理，也適用於組織工作產品(如標準、程序及再用程式庫)的建構管理。 建構管理著重於工作產品(包含已交付的系統)在管理面和技術面的嚴格管制。 建構管理(CM) 123
CMMI for Development Version 建構管理流程領域涵蓋執行建構管理功能的執行方法，也適用於已納入建構管理的所有工作產品。 相關流程領域 有關發展計畫和分工結構圖，請參考專案規劃流程領域，以獲得更多資訊。分工結構圖可用於決 有關績效分析和矯正措施，請參考專案監控流程領域，以獲得更多資訊。 建構管理(CM) 124
CMMI for Development Version 特定目標及執行方法摘要 SG 1建立基準 SP 界定建構項目 SP 建立建構管理系統 SP 建立或發行基準 SG 2追蹤並管制變更 SP 追蹤變更申請 SP 管制建構項目 SG 3建立完整性 SP 建立建構管理紀錄 SP 實施建構稽核 各目標的特定執行方法 SG 1 建立基準 建立由已界定的工作產品所組成的基準。 本特定目標涵蓋用以建立基準的特定執行方法。「追蹤並管制變更」特定目標所涵蓋的特定執行方法用以維護基準，而「建立完整性」特定目標的特定執行方法則用以記錄和稽核基準的完整性。 SP 界定建構項目 界定將納入建構管理的建構項目、組件及相關的工作產品。 建構識別為下列項目的選擇、建立及說明： • 交付客戶的產品 • 指定的內部工作產品 • 取得的產品 • 工具及其他專案工作環境的資本資產 • 其它用以產生或說明這些工作產品的項目 建構管理(CM) 125
CMMI for Development Version 納入建構管理的項目，包含用於說明工作產品需求的規格和介面文件；也包含其他的文件，例如：測試結果。可依據它對於定義產品的重要性，來決定是否納入建構管理。 「建構項目」是被指定要納入建構管理的實體，它可能包含組成某基準的數個相關工作產品。這種邏輯上的編組，提供較容易的識別和存取控制。應根據規劃時所定的準則，選取需納入建構管理的工作產品。 典型的工作產品 1. 已界定的建構項目 細部執行方法 1. 根據文件化的準則，選擇建構項目和組成這些項目的工作產品。 在適當的工作產品層次中，選擇建構項目的準則，舉例如下： • 可能被兩個(含)以上小組共用的工作產品 • 會隨著時間而變更的工作產品，其變更原因可能是發生錯誤或變更需求 • 數個相互依存的工作產品，當其中一個改變時，將會影響到其他的工作產品 • 對專案具有極高重要性的工作產品 建構管理(CM) 126
CMMI for Development Version 可組成建構項目的工作產品，舉例如下： • 流程說明 • 需求 • 設計 • 測試計畫和程序 • 測試結果 • 介面說明 • 圖表 • 原始碼 • 工具(如編譯器) 2. 指定每個建構項目唯一的識別碼。 3. 界定每個建構項目的重要特性。 建構項目的特性，包含作者、文件格式或檔案格式，以及程式碼所使用的語言。 4. 界定每個建構項目納入建構管理的時間點。 何時將工作產品納入建構管理的準則，舉例如下： • 在專案生命週期的各階段 • 當工作產品準備好可進行測試的時候 • 工作產品需要某種程度控制的時候 • 成本和時程的界限 • 客戶需求 5. 界定每個建構項目的負責人。 SP 建立建構管理系統 建立並維護一個建構管理與變更管理的系統，以便管制工作產品。 建構管理系統包含：儲存媒體、運作程序，以及存取建構系統的工具。 建構管理(CM) 127
CMMI for Development Version 變更管理系統包含：儲存媒體、運作程序，以及記錄和存取變更申請的工具。 典型的工作產品 1. 建構管理系統，內含被管制的工作產品 2. 建構管理系統的存取控制程序 3. 變更申請資料庫 細部執行方法 1. 在建構管理中，建立多重管制層級的機制。 通常會根據專案目標，風險及/或資源來選擇管制層級。管制層級可能因專案生命週期、發展時的系統種類及特定專案需求而異。 管制層級，舉例如下： • 建立-由作者管制 • 工程-當變更發生時，通知相關的關鍵人員 • 發展-由低階建構管制委員會管制 • 正式-由與客戶參與的高階建構管制委員會管制 管制層級可從簡易追蹤發展中建構項目變更的非正式管制到正式建構管理流程變更基準的正式建構管制。 2. 在建構管理系統中，存取建構項目。 建構管理(CM) 128
CMMI for Development Version 建構管理系統的舉例如下： • 動態(或作者)的系統，包含目前正在產生或修訂的組件。它們在發展者的工作場所，而且由作者所管制。屬於動態系統的建構項目，由版本管制來控制。 • 主要(或受管制)的系統，包含目前的基準和基準的變更。屬於主要系統的建構項目，完全由本流程領域的建構管理來控制。 • 穩定的系統，包含已發行使用之各種基準的保存檔。穩定的系統完全由本流程領域的建構管理來控制。 3. 在建構管理系統的不同程度管制機制下，分享和移轉建構項目。 4. 儲存和復原已歸檔保存的建構項目版本。 5. 儲存、更新及取出建構管理紀錄。 6. 從建構管理系統中，產生建構管理報告。 7. 保存建構管理系統的內容。 建構管理系統的保存功能，舉例如下： • 建構管理檔案的備份和復原 • 建構管理檔案的歸檔保存 • 建構管理錯誤的復原 8. 必要時，修訂建構管理結構。 SP 建立或發行基準 建立或發行供內部使用和交付給客戶的基準。 基準是一組經正式審查和同意的規格或工作產品，也是未來發展或交付的基礎，而且只能經由變更控制程序才能改變此基準。基準表示對一個或多個建構項目及相關項目之識別的指定。當產品演進中，有幾個基準可用來控制產品的發展與測試。 建構管理(CM) 129
CMMI for Development Version 系統工程適用 基準共通的地方包含系統層次的需求、系統元件層次的設計需求，以及發展結束/製造前的產品定義。這些被稱為「功能基準(functional baseline)」、「配置基準(allocated baseline)」及「產品基準(product baseline)」。 軟體工程適用 軟體基準可以是已指定唯一識別碼的一組需求、設計、程式碼檔案以及相關的可執行碼、版次檔和使用者文件(相關的項目)。 典型的工作產品 1. 基準 2. 基準說明 細部執行方法 1. 在建立或發行建構項目的基準之前，取得建構管制委員會的授權。 2. 只有來自建構管理系統的建構項目，才能建立基準或發行基準。 3. 記錄基準所含的建構項目。 4. 使目前最新的基準，隨時可供使用。 SG 2 追蹤並管制變更 追蹤並管制已納入建構管理工作產品的變更。 本特定目標所涵蓋的特定執行方法用來維護基準，這些基準是由「建立基準」特定目標所涵蓋的特定執行方法所建立。 SP 追蹤變更申請 追蹤建構項目的變更申請。 建構管理(CM) 130
CMMI for Development Version 變更申請不只用於新的需求或需求的變更，也可用於工作產品的故障或缺失。 分析變更申請，以決定此變更對工作產品、相關工作產品、時程及成本的影響。 典型的工作產品 1. 變更申請 細部執行方法 1. 啟動變更申請，並記錄於變更申請資料庫。 2. 分析變更建議和所需的修改所造成的影響。 藉由活動來評估變更，以便確保此變更與所有的技術需求和專案需求的一致性。 評估變更所造成的影響，也應考慮目前專案或合約之外的需求。如建構項目被數個產品所使用，則該建構項目的改變或許可以解決目前的問題，但也可能造成其他應用上的新問題。 3. 如果變更申請會影響其他基準，應與相關的關鍵人員一起審查這些變更申請，並取得他們的同意。 執行變更申請審查時，讓合適的人參與決定，並記錄每一變更申請的處理方法和決策理由，包含成功的準則、簡單的行動計畫及變更是否符合需要等。執行處理方法所提的行動，並將結果告知相關的關鍵人員。 4. 追蹤變更申請的狀態直到結案。 系統的變更申請，須用有效和即時的方式處理。一旦開始處理變更申請，重要的是，當已核准的行動已產生作用，應儘速將之結案。若行動一直不結案，結果將不只是更長的待處理狀態清單，它可能導致成本和困擾的增加。 建構管理(CM) 131
CMMI for Development Version SP 管制建構項目 管制建構項目的變更。 需要管制工作產品基準的建構，管制包含追蹤每一建構項目的建構、必要時核准新的建構，並更新基準。 典型的工作產品 1. 建構項目的修訂歷史紀錄 2. 基準的保存檔(archives) 細部執行方法 1. .在整個產品生命週期，管制建構項目的變更。 2. 變更後的建構項目，在納入建構管理系統之前，必須獲得適當的授權。 舉例來說，授權可來自建構管制委員會、專案經理或客戶。 3. 針對同時受某些變更影響的建構項目，在簽入或簽出建構管理系統時，必須設法維護這些建構項目的正確性和完整性。 簽入和簽出的步驟，舉例如下： • 確認這些修訂已取得授權 • 更新建構項目 • 將舊基準歸檔保存，並取出新基準 4. 執行審查，以確保該變更沒有對基準造成意料外的影響。例如：確保變更沒有影響系統的安全及(或)機密。 5. 適當記錄建構項目的變更和變更的理由。 如果接受對工作產品的變更建議，則須界定完成修改工作產品及其他受影響部分的時程表。 建構管理(CM) 132
CMMI for Development Version 建構管制機制可以調適成多種變更類別。例如：有些不影響其他組件的組件變更，其核准流程可以較簡化。 已變更的建構項目，須經審查和核准後才能發行。若未經發行，變更並不算正式生效。 SG 3 建立完整性 建立並維護基準的完整性。 「建立基準」特定目標的流程用於建立基準，「追蹤並管制變更」特定目標的流程用於維護基準，而本特定目標所涵蓋的特定執行方法則用以記錄和稽核基準的完整性。 SP 建立建構管理紀錄 建立並維護描述建構項目的紀錄。 典型的工作產品 1. 建構項目的修訂歷史紀錄 2. 變更過程的紀錄 3. 變更申請的備份 4. 建構項目的狀態 5. 不同基準間的差異 細部執行方法 1. 詳細記錄建構管理活動，使他人知道每個建構項目的內容和狀態，並能復原建構項目的先前版本。 2. 確保相關的關鍵人員，能存取和瞭解建構項目的建構狀態。 建構管理(CM) 133
CMMI for Development Version 溝通建構狀態資訊的活動，舉例如下： • 提供存取權限給經授權的最終使用者 • 備妥基準的備份，以供經授權的最終使用者使用 3. 標示基準的最新版本。 4. 界定組成某基準之建構項目的版本。 5. 描述前後版本基準間的差異。 6. 必要時修訂建構項目的狀態和歷史紀錄(指變更及其他行動)。 SP 實施建構稽核 實施建構稽核以維護建構基準的完整性。 建構稽核確認最終的基準和文件有遵照特定標準或需求，並適當記錄稽核結果。(有關「建構稽核」的定義，請參照詞彙。) 稽核種類舉例如下： • 功能建構稽核(FCA)-稽核的執行是在驗證建構項目的測試功能特徵，達到功能基準文件所指定的需求，而且操作及支援文件已完整及滿足。 • 實體建構稽核(PCA)-稽核的執行是在驗證建置的建構項目遵照技術文件的定義。 • 建構管理稽核-稽核的執行是在確認建構管理紀錄及建構項目的完整性、一致性及正確性。 典型的工作產品 1. 建構稽核結果 2. 行動項目 細部執行方法 1. 評量基準的完整性。 2. 確認建構管理紀錄已正確界定建構項目。 建構管理(CM) 134
CMMI for Development Version 3. 審查建構管理系統中，建構項目的結構和一致性。 4. 確定建構管理系統中，建構項目的完整性和正確性。 依據計畫中所述的需求和已核准之變更申請的處理為基礎，來判斷內容的完整性和正確性。 5. 確定符合適用的建構管理標準和程序。 6. 追蹤稽核的行動項目直到結案。 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為職別輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施建構管理流程的特定執行方法，以發展工作產品並提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 GP 建立組織政策 建立並維護組織政策，以規劃和執行建構管理流程。 詳細說明： 本政策建立組織對下列活動的期望：建立和維護基準；追溯和管制工作產品的變更(在建構管理下)；以及建立和維護基準的完整性。 建構管理(CM) 135
CMMI for Development Version GP 規劃流程 建立並維護執行建構管理流程的計畫。 詳細說明： 執行建構管理流程的計畫可包含於專案計畫或被專案計畫所參考，專案計畫在專案規劃流程領域中描述。 GP 提供資源 提供充足的資源，執行建構管理流程、發展工作產品及提供流程服務。 詳細說明： 可用於本流程領域的資源(工具)，舉例如下： • 建構管理工具 • 資料管理工具 • 歸檔及複製工具 • 資料庫程式 GP 指派責任 指派建構管理流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援建構管理流程。 建構管理(CM) 136
CMMI for Development Version 詳細說明： 訓練的主題，舉例如下： • 建構管理人員的角色、責任及權力 • 建構管理標準、程序及方法 • 建構資料庫系統 GP 管理建構 將指定的建構管理流程工作產品，納入適當層級的管制。 詳細說明： 請參照表的一般目標和一般執行方法，以獲得更多關於GP 的資訊及建構管理流程領域的關聯性。 納入管制的工作產品，舉例如下： • 存取清單 • 變更狀態報告 • 變更申請資料庫 • 建構管制委員會會議紀錄 • 已歸檔保存的基準 GP 界定並納入相關的關鍵人員 依計畫界定並納入建構管理流程相關的關鍵人員。 建構管理(CM) 137
CMMI for Development Version 詳細說明： 關鍵人員參與的活動，舉例如下： • 建立基準 • 審查建構管理系統報告，並解決議題 • 評量變更建構項目的影響 • 執行建構稽核 • 審查建構管理稽核的結果 GP 監控流程 依本流程的執行計畫，監控建構管理流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量和工作產品，舉例如下： • 建構項目變更的數量 • 建構稽核的執行數量 • 建構管制委員會或稽核活動時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估建構管理流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 建立基準 • 追蹤並管制變更 • 建立並維護基準的完整性 建構管理(CM) 138
CMMI for Development Version 審查的工作產品，舉例如下： • 基準的保存檔 • 變更申請資料庫 GP 與上層管理人員審查各狀況 與上層管理人員審查建構管理流程的活動、狀況及結果，並解決問題。 僅適用於階段式表述 GG 3 及其執行方法不應用於成熟度第二級評等，但應用於成熟度第三級和更高級評等。 建構管理(CM) 139
CMMI for Development Version 僅適用於連續式/階段式表述第3-5級 GG 3 制度化已定義流程 將流程制度化為已定義流程。 GP 建立已定義流程 建立並維護已定義建構管理流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行建構管理流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產未來的使用與改善。 詳細說明： 工作產品、度量、度量結果及改善資訊，舉例如下： • 建構項目的狀態趨勢 • 建構稽核結果 • 變更申請時序報告 建構管理(CM) 140
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理的流程。 GP 建立流程的量化目標 建立並維護建構管理流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定建構管理流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化的流程。 GP 確保持續的流程改善 確保供建構管理流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正建構管理流程之缺失與其他問題的根本原因。 建構管理(CM) 141
CMMI for Development Version 決策分析與解決方案 成熟度第三級的支援類流程領域 目的 決策分析與解決方案(Decision Analysis and Resolution, DAR)的目的，在於利用正式的評估流程，依據已建立的準則評估各種已界定的備選方案，以分析可能的決策。 簡介 決策分析與解決方案流程領域包含建立指引，以決定什麼議題需要正式評估流程，然後引用正式評估流程解決議題。 正式評估流程為一結構化的方法，依據已建立的準則評估備選解決方案，並決定推薦的方案來解決議題。正式評估流程包含下列的活動： • 建立評估備選方案的準則 • 界定備選解決方案 • 選擇評估備選方案的方法 • 使用已建立的準則與方法，評估備選解決方案 • 依據評估準則，從備選方案中選擇建議方案 本文中要表達「解決議題的備選解決方案」時，將使用「備選解決方案(alternative solutions)」或「備選方案(alternatives)」。 正式評估流程是減少決策的主觀性，並有較高的可能性選擇一符合相關關鍵人員多樣需求的解決方案。 本流程領域主要應用於選定技術的重要事項，正式評估流程也可應用於許多非技術的議題，特別當專案開始規劃，議題有多種備選解決方案與評估準則時，適合使用正式評估流程。 決策分析與解決方案(DAR) 142
CMMI for Development Version 設備或軟體的替代方案研究是正式評估流程的典型範例。 在專案規劃期間，界定哪些特定議題需要正式評估流程。典型的議題包括：選擇架構或設計的備選方案、使用再用或現成品組件、選擇供應商、工程支援環境或相關工具、測試環境、交付的備選方案以及後勤和生產。正式評估流程也可用於解決自行發展或採購的決策、製造流程的發展、配銷位置的選擇及其他決策。 建立指引，以決定何時使用正式評估流程來解決非規劃的議題。當議題涉及中高風險或議題會影響達成專案目標的能力時，指引通常建議使用正式評估流程。 正式評估流程有不同的形式、準則類型及使用的方法，例如：較不正式的決策，其分析可能花費幾小時、只使用幾條準則(如有效性和建置的成本)，以及產生一兩頁報告；但是較正式的決策可能需要個別計畫、幾個月的工作量、研訂與核准準則的會議、模擬、雛型、試用及大量的文件。 正式評估流程可使用量化或非量化的準則。量化準則使用權重以反映準則的相對重要性；非量化準則使用較主觀的等級劃分(如：高、中、低)。較正式的決策可能要求完整的替代方案研究。 正式評估流程界定與評估各種備選解決方案。選定最後方案的過程，可能包括反覆的界定與評估活動。在評估期間，已界定的備選方案，可能部分的被組合、新出現的技術也可能改變備選方案，而供應商的經營情況在評估期間也可能改變。 所建議的備選方案伴隨選定之方法、準則、備選方案及建議理由的文件，此文件將分送給相關關鍵人員，並提供正式評估流程的紀錄及理由，它對其他未來遇到相似議題的專案是有幫助的。 決策分析與解決方案(DAR) 143
CMMI for Development Version 整個專案中，部分決策涉及正式評估流程，其他決策則否，就像之前所述，建立指引以決定哪些議題是屬於正式評估流程。 相關流程領域 有關一般的專案規劃，請參考專案規劃流程領域，以獲得更多資訊。 有關建立專案已調適流程，請參考整合的專案管理流程領域，以獲得更多資訊。專案已調適流程包含每一選定議題的正式評估流程，並納入對無法預知的議題，引用正式評估流程的使用指引。 有關界定風險及降低風險，請參考風險管理流程領域，以獲得更多資訊。正式評估流程經常用以解決已界定的中、高風險議題。選定的解決方案通常會衝擊風險降低計畫。 決策分析與解決方案(DAR) 144
CMMI for Development Version 特定目標及執行方法摘要 SG 1評估備選方案 SP 建立決策分析指引 SP 建立評估準則 SP 界定備選解決方案 SP 選擇評估方法 SP 評估備選方案 SP 選擇解決方案 各目標的特定執行方法 SG 1 評估備選方案 使用已建立的準則，根據評估的備選方案作決策。 在產品或專案的任何時間點都可能界定出需正式評估流程的議題。目標為儘早界定議題，使得有較充裕時間解決該議題。 SP 建立決策分析指引 建立並維護指引，以決定哪些議題須經正式評估流程。 不是每個決策都足夠重要到需要正式評估流程。若沒有明確的指引，在重要與不重要之間的選擇會不清楚。一個決策重要與否，與專案及環境相關，並由已建立的指引加以決定。 用來決定何時需要正式評估流程的典型指引，包含如下： • 當某決策與經評量之中高度風險主題有直接關係時 • 當某決策與在建構管理下之工作產品的變更有關時 • 當某決策會導致時程延誤超過某一比例或特定的時間時 決策分析與解決方案(DAR) 145
CMMI for Development Version • 當某決策影響達成專案目標的能力時 • 當正式評估流程的成本與決策衝擊相比較是合理時 • 當招標中有合法契約時 有關決定哪些議題屬於中高風險，請參考風險管理流程領域，以獲得更多資訊。 使用正式評估流程的時機，舉例如下： • 在材料採購上，當20%材料零件耗用80%材料成本時 • 在設計實作決策上，當技術設計失誤可能釀成巨災時(例如：飛行項目的安全) • 各種可能重大降低設計風險、工程變動、週期時程、反應時間及生產成本的決策(例如：在公佈工程繪圖與生產建造前，使用印刷方法評量外型與符合的能力。) 典型的工作產品 1. 何時引用正式評估流程的指引 細部執行方法 1. 建立指引。 2. 適當時，將指引的使用併入已調適流程中。 有關建立專案已調適流程，請參考整合的專案管理流程領域，以獲得更多資訊。 SP 建立評估準則 建立並維護用來評估備選方案的評估準則及其相對排序。 評估準則提供評估備選解決方案的基礎。將準則排序，以使得排序最高的準則代表對評估有最大的影響。 決策分析與解決方案(DAR) 146
CMMI for Development Version CMMI模式的許多其他流程領域參考本流程領域，正式評估流程也在許多地方使用。因此，在某些情況下你會發現準則已經定義於其他的流程中。本特定執行方法不建議再次發展相同的準則。 記錄評估準則，以避免後續決策猜疑的可能性或忘掉作成該決策的原因，依據已明確定義及建立的準則所作的決策，可排除關鍵人員的認同障礙。 典型的工作產品 1. 評估準則的紀錄 2. 準則重要性排序 細部執行方法 1. 定義評估備選解決方案的準則。 準則應可追溯到需求、劇本、經營個案假設、經營目標或其他已記錄的來源。考量的準則類型包括如下： • 技術限制 • 環境衝擊 • 風險 • 所有權及生命週期成本 2. 定義評估準則分級的範圍與等級。 可運用非數字的值或將評估參數和權重數值結合的公式，建立評估準則之相對重要性的等級。 3. 將準則排序。 依據定義的範圍與等級將準則排序，以反映需求、目標及相關關鍵人員的優先順序。 4. 評估準則及其相對的重要性。 5. 漸進發展評估準則以改善其有效性。 6. 記錄選用及捨棄評估準則的理由。 決策分析與解決方案(DAR) 147
CMMI for Development Version 記錄選用的準則及理由，以證明解決方案的正當性，或作為未來參考與使用。 SP 界定備選解決方案 界定解決議題的備選解決方案。 儘可能請關鍵人員提出廣泛的備選方案，關鍵人員的技能和背景皆不相同，其建議有助於界定和解決各種假設、限制及偏見。腦力激盪會議經由快速互動與回饋可刺激有創意的備選方案。充分的備選方案可能也不足提供分析，當分析進行時，其它方案應加到可能的候選解決方案清單內，在決策分析與解決方案流程初期，考量與產生多樣的備選方案，可增加做成可接受之決策的可能性，且該決策的結果較易理解。 典型的工作產品 1. 已界定的備選方案 細部執行方法 1. 執行文獻搜尋。 文獻查詢可發覺組織內外曾做過的事情，可提供對下列有更深的瞭解：問題、考慮的備選方案、執行障礙、既有的替代方案研究及類似決策的學習心得。 2. 除了議題的解決方案之外，界定納入考量的備選解決方案。 評估準則是界定備選方案的有效起點。評估準則界定相關關鍵人員的優先順序及技術、後勤或其他挑戰的重要性。 組合既有方案的關鍵屬性可能產生額外的方案，且有時侯是更具說服力的方案。 誘導相關關鍵人員提出備選方案。可有效地使用腦力激盪、訪談及工作小組等方式以發現備選方案。 決策分析與解決方案(DAR) 148
CMMI for Development Version 3. 記錄提議的方案。 SP 選擇評估方法 選擇評估方法。 依據已建立的準則，用以評估備選方案的方法，其範圍從模擬到使用機率和決策理論，這些方法必須小心選擇。方法的詳細程度應與成本、時程、績效及風險的衝擊相稱。 雖然許多問題只需一種評估方法，但有些問題可能需要多種方法。舉例來說，模擬可加強替代方案研究，以決定那個設計備選方案最符合特定的準則。 典型的工作產品 1. 已選擇的評估方法 細部執行方法 1. 以分析決策的目的與可用以支援該方法之資訊的可用性為基礎，來選擇方法。 例如：在需求定義不明確的情況下，用來評估技術解決方案的方法，可能會與在需求定義明確的情況有所不同。 典型的評估方法包含下列： • 模式與模擬 • 工程研究 • 製程研究 • 成本研究 • 經營機會研究 • 調查 • 依據經驗與雛型加以推斷 • 使用者審查與評論 • 測試 • 一個或一組專家的判斷(例：Delphi方法) 決策分析與解決方案(DAR) 149
CMMI for Development Version 2. 依據專注於手邊的議題，而不受無關議題過度影響的能力，選擇評估方法。 模擬的結果，會被解決方案中沒有直接相關議題的隨意活動所曲解。 3. 決定支援評估方法所需的度量。 考量對成本、時程、績效及風險的衝擊。 SP 評估備選方案 使用已建立的準則與方法，評估備選方案。 評估備選方案包括：分析、討論及審查。反覆的分析有時是必要的。可能需要支援分析、實驗、雛型、演練或模擬，以支持評分及結論。 準則的相對重要性經常是不精確的，且解決方案的整體效果往往在執行相關分析工作之後才會明顯。若各備選方案的評分結果差距不大，則可能無法從備選解決方案中明確選出最佳者。應鼓勵對準則及假設條件的挑戰。 典型的工作產品 1. 評估結果 細部執行方法 1. 使用已建立的評估準則與選定的方法，評估提議的備選解決方案。 2. 評估各種評估準則的假設條件，以及支持該假設條件的各種證據。 3. 評估是否有價值觀念的不確定性影響備選解決方案的評估，並給予適當的解決。 例如：假若分數可在兩數值中改變，該差異是否足以區分最後方案？分數的差異是否代表高風險？為克服這些疑慮，可進行一些模擬、執行進一步的研究或修改評估準則。 決策分析與解決方案(DAR) 150
CMMI for Development Version 4. 必要時，執行模擬、塑模、雛型及試行，以測試評估準則、方法及備選解決方案。 未經試驗的準則，其相對的重要性以及支援資料或功能，可能造成對解決方案實用性的質疑。準則及其相對的優先順序與規模大小，可試用於一些備選方案以進行測試。試用這些評估準則，使準則得以在解決方案中進行漸進的影響性評估。若試用顯現問題，則應考慮不同的準則或備選方案，以避免偏差。 5. 若建議的備選解決方案無法通過測試時，考量新的備選解決方案、準則及方法。並重複評估活動，直到備選方案能通過測試。 6. 記錄評估結果。 記錄增加新備選方案或方法、準則變動的理由，以及中間評估的結果。 SP 選擇解決方案 依據評估準則，從備選方案中選擇解決方案。 選擇解決方案包含對於備選方案評估結果，賦予權重。必須評量執行解決方案有關的風險。 典型的工作產品 1. 解決重大議題的建議解決方案 細部執行方法 1. 評量執行建議解決方案相關的風險。 有關如何界定與管理風險，請參考風險管理流程領域，以獲得更多資訊。 決策經常在資訊不完備的情況下進行，因資訊不完備而制定的決策可能有實質的風險。 當決策必須依照特定的時程、時間及資源進行時，可能無法搜集完備的資訊。因此，日後可能決策分析與解決方案(DAR) 151
CMMI for Development Version 需要重新分析在資訊不完備時所制定的危險決策。應監督已界定的風險。 2. 記錄建議解決方案的結果及理由。 記錄選擇某解決方案與拒絕另一解決方案的理由是很重要的。 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施決策分析與解決方案流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 僅適用於階段式表述 GG 3 制度化已定義的流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行決策分析與解決方案流程。 決策分析與解決方案(DAR) 152
CMMI for Development Version 詳細說明： 本政策建立組織的期望，使用正式評估流程，分析可能的決策以進行決策。正式評估流程係依已建立的準則評估已界定的備選方案。本政策也應提供哪些決策需要正式評估流程的指引。 GP 規劃流程 建立並維護執行決策分析與解決方案流程的計畫。 詳細說明： 專案計畫通常包含(或參考)執行決策分析與解決方案流程的計畫，專案計畫在專案規劃流程領域中說明。 GP 提供資源 提供充足的資源，以執行決策分析與解決方案流程、發展工作產品及提供流程服務。 詳細說明： 提供的資源包含下列工具： • 模擬及塑模工具 • 雛型工具 • 執行調查的工具 GP 指派責任 指派決策分析與解決方案的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援決策分析與解決方案流程。 決策分析與解決方案(DAR) 153
CMMI for Development Version 詳細說明： 訓練的主題，舉例如下： • 正式決策分析 • 依準則評估備選解決方案的方法 GP 管理建構 將指定的決策分析與解決方案流程工作產品，納入適當層級的管制。 詳細說明： 納入管制的工作產品，舉例如下： • 何時引用正式評估流程的指引 • 包含建議解決方案的評估報告 GP 界定並納入相關的關鍵人員 依計畫界定並納入決策分析與解決方案流程相關的關鍵人員。 詳細說明： 關鍵人員參與的活動，舉例如下： • 建立哪些議題須經正式評估流程的指引 • 建立評估準則 • 界定並評估備選方案 • 選擇評估方法 • 選擇解決方案 GP 監控流程 依本流程的執行計畫，監控決策分析與解決方案流程，並採取適當的矯正措施。 決策分析與解決方案(DAR) 154
CMMI for Development Version 詳細說明： 用於監控的度量與工作產品，舉例如下： • 使用正式評估流程的本益比 • 交易研究的執行排程 GP 客觀評估遵循程度 依據流程說明、標準及程序，客觀地評估決策分析與解決方案流程、工作產品及流程服務，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 使用已建立的準則與方法，評估備選方案 審查的工作產品，舉例如下： • 何時引用正式評估流程的指引 • 包含建議解決方案的評估報告 GP 與上層管理人員審查各狀況 與上層管理人員審查決策分析與解決方案流程的活動、狀況及結果，並解決議題。 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 決策分析與解決方案(DAR) 155
CMMI for Development Version GP 建立已定義流程 建立並維護已定義決策分析與解決方案流程的說明。 GP 蒐集改善資訊 蒐集由規劃並執行決策分析與解決方案流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 詳細說明： 工作產品、度量、度量結果及改善資訊，舉例如下： • 考慮備選方案的數目 • 評估結果 • 重要議題的建議解決方案 決策分析與解決方案(DAR) 156
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護決策分析與解決方案流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定決策分析與解決方案流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保決策分析與解決方案流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正決策分析與解決方案流程之缺失與其他問題的根本原因。 決策分析與解決方案(DAR) 157
CMMI for Development Version 整合的專案管理 + IPPD 成熟度第三級的專案管理類流程領域 目的 整合的專案管理(Integrated Project Management, IPM)之目的，是依據組織標準流程所調適而成之整合的已調適流程，來建立和管理專案，以及相關的關鍵人員的參與。 IPPD補充 對於整合的產品與流程發展(IPPD)，整合的專案管理(IPPD)也涵蓋建立專案共同願景，以及建立整合團隊來實現專案的目標。 簡介 整合的專案管理包含下列事項： • 調適組織標準流程，以建立專案已調適流程。 • 使用專案已調適流程管理專案。 • 根據組織工作環境標準，建立專案的工作環境。 • 使用組織流程資產，並對其產生貢獻。 • 在產品的發展過程中，使相關關鍵人員所關心的事均被界定、考慮及適當的處理。 • 確保相關關鍵人員以協調及即時的態度執行工作：(1)處理產品與產品組件需求、計畫、目標、議題及風險；(2)實現他們的承諾；以及(3)界定、追蹤及解決議題。 IPPD 補充 整合的專案管理(IPPD)包含下列事項： • 由專案建立及為專案建立的共同願景。 • 建立負有達成專案目標任務的整合團隊。 整合的專案管理(IPM+IPPD) 158
CMMI for Development Version 由組織標準流程調整而來之整合及調適的流程稱為專案已調適流程。 專案工作量、成本、時程、人員、風險及其他因素的管理，與專案已調適流程的工作項目息息相關。專案已調適流程的實施與管理，通常描述於專案計畫中，而某些活動可能包含於影響專案的其他子計畫，諸如品質保證計畫、風險管理策略及建構管理計畫。 因為每個專案的已調適流程均從組織標準流程調適而來，專案間的相異性通常會減少，且專案可以更容易分享流程資產、資料及學習心得。 此流程領域同時也規範所有與專案相關活動的協調，舉例如下： • 發展活動，例如：需求發展、設計及驗證 • 服務活動(例如，交付、服務台、營運及客戶聯絡) • 採購活動(例如，招標、合約監控及移轉至營運) • 支援活動(例如：建構管理、文件、行銷及訓練) 規劃與管理專案內部或外部相關關鍵人員間的工作介面與互動，以確保整體專案的品質與產品的完整性。定義專案已調適流程與專案計畫時，相關的關鍵人員可適當參與。與這些相關關鍵人員定期的進行審查與交流，並適當的注意協調的問題，以確保參與專案的每個人，適當的瞭解專案的狀態、計畫及活動。(相關關鍵人員的定義，請參考詞彙)定義專案已調適流程時，依需要建立正式的介面，以確保適當的協調與合作。 本流程領域適用於任何組織架構，包括如線性組織、矩陣組織或整合團隊。此術語應該在合適的組織架構中，適當地加以解釋。 整合的專案管理(IPM+IPPD) 159
CMMI for Development Version 相關流程領域 有關規劃專案，請參考專案規劃流程領域，以獲得更多資訊。 有關監控專案，請參考專案監控流程領域，以獲得更多資訊。 有關界定關鍵人員及其適當的參與專案，請參考專案規畫流程領域，以獲得更多資訊。 有關同仁審查，請參考驗證流程領域，以獲得更多資訊。 有關組織流程資產及工作環境標準，請參考組織流程定義流程領域，以獲得更多資訊。 有關定義一個度量與分析的流程，請參考度量與分析流程領域，以獲得更多資訊。 IPPD補充 有關創立組織規則及指引，請參考組織流程定義+IPPD流程領域，以獲得更多資訊。 整合的專案管理(IPM+IPPD) 160
CMMI for Development Version 特定目標及執行方法摘要 SG 1 使用專案的已調適流程 SP 建立專案的已調適流程 SP 使用組織流程資產規劃專案活動 SP 建立專案工作環境 SP 整合計畫 SP 使用整合計畫管理專案 SP 貢獻組織流程資產 SG 2 與關鍵人員協調與合作 SP 管理關鍵人員參與 SP 管理相互依存關係 SP 解決協調議題 IPPD補充 SG 3 採行IPPD原則 SP 建立專案共同願景 SP 建立整合團隊架構 SP 配置需求給整合團隊 SP 建立整合團隊 SP 確保介面團隊間的合作各目標的特定執行方法 SG 1 使用專案的已調適流程 專案執行須使用依組織標準流程所調適的流程。 專案已調適流程必須包含組織標準流程，該標準流程說明採購或發展與維護產品所需的所有流程。產品相關的生命週期流程，如製造與支援流程，與產品同步開發。 整合的專案管理(IPM+IPPD) 161
CMMI for Development Version SP 建立專案的已調適流程 從專案啟動到專案全程，建立並維護專案的已調適流程。 有關組織流程資產館，請參考組織流程定義流程領域，以獲得更多資訊。 有關組織流程需求與目標，以及推展組織的標準流程至專案，請參考組織流程專注流程領域，以獲得更多資訊。 專案已調適流程由經過調適的流程所組成，提供專案形成一個整合的、連貫的生命週期。 IPPD補充 專案的已調適流程以下列流程支援IPPD • 使整合的專案管理環境在組合或分散式團隊時，更禁得起考驗。 • 選擇專案的整合團隊架構 • 分配有限的人力資源 • 建立跨整合團隊之間的溝通 專案已調適流程應該滿足專案合約與經營上的需求、機會及限制，其設計是要提供最適合專案的需求。專案已調適流程以下列要素為基礎： • 客戶需求 • 產品與產品組件需求 • 承諾 • 組織流程需求與目標 • 組織標準流程及調適指引 • 運作環境 • 經營環境 在專案一開始時，建立專案的已調適流程，有助於確保專案人員及關鍵人員執行一套有效建立專案初步需求和計畫所需的活動。當專案進行時，專案已調適流程會更詳細說明並修訂，更能符合專案需求 整合的專案管理(IPM+IPPD) 162
CMMI for Development Version 及組織流程需要及目標。且當組織標準流程改變時，專案已調適流程可能需要隨著修訂。 典型的工作產品 1. 專案已調適流程 細部執行方法 1. 從組織流程資產，挑選一個生命週期模式。 會影響生命週期模式選擇的專案特性，舉例如下： • 專案大小 • 人員執行流程的經驗及熟悉程度 • 週期時間及可接受的缺失等級等限制 2. 從組織標準流程，挑選最適合專案需要的標準流程。 3. 依據調適指引，調適組織標準流程及其他的組織流程資產，產生專案的已調適流程。 有時候，可用的生命週期模式與標準流程不足以符合特定專案的需求，或專案不能產出需要的工作產品或度量。在此情況下，專案須徵求偏離組織需求的核准。豁免權是為了這樣的目的而提供。 4. 適當的使用組織流程資產館的其他成果。 其他成果可能包括如下事項： • 學習心得文件 • 樣板 • 範例文件 • 估計模式 5. 記錄專案的已調適流程。 整合的專案管理(IPM+IPPD) 163
CMMI for Development Version 專案已調適流程，涵蓋專案所有的工程、管理及支援活動，以及與關鍵人員間的介面。 專案活動，舉例如下： • 專案規劃 • 專案監控 • 需求發展 • 需求管理 • 供應商管理 • 建構管理 • 品質保證 • 風險管理 • 決策分析與解決方案 • 產品發展與支援 • 招標 6. 對專案已調適流程，進行同仁審查。 有關進行同仁審查，請參考驗證流程領域，以獲得更多資訊。 7. 必要時，修訂專案的已調適流程。 SP 使用組織流程資產規劃專案活動 使用組織流程資產與度量儲存庫來估計及規劃專案活動。 有關組織流程資產與組織度量儲存庫，請參考組織流程定義流程領域，以獲得更多資訊。 典型的工作產品 1. 專案的估計值 2. 專案計畫 整合的專案管理(IPM+IPPD) 164
CMMI for Development Version 細部執行方法 1. 以專案已調適流程的工作項目與工作產品為基礎，進行估計及規劃活動。 瞭解專案已調適流程不同工作項目與工作產品之間的關係，以及瞭解關鍵人員所扮演的角色，是發展實際計畫的基礎。 2. 使用組織度量儲存庫來估計專案的規劃參數。 估計通常包含下列事項： • 使用來自本專案或類似專案之適當的歷史資料 • 說明並記錄現行專案與引用歷史資料之專案間的相似與不同處 • 獨立驗證歷史資料 • 記錄用以選擇歷史資料的原因、假設及理由 考量相似與不同處的參數，舉例如下： • 工作產品與工作項目屬性 • 應用領域 • 設計方法 • 運作環境 • 人員經驗 整合的專案管理(IPM+IPPD) 165
CMMI for Development Version 組織度量儲存庫所包括的資料，舉例如下： • 工作產品的規模大小或其他工作產品的屬性值 • 工作量 • 成本 • 時程 • 人員配置 • 缺失 • 回應時間 • 服務能量 • 供應商績效 SP 建立專案工作環境 根據組織工作環境標準，建立與維護專案的工作環境。 一個專案的適當工作環境包括設施、工具與設備的基礎建設，人員用以有效執行工作，以支援企業與專案目標。工作環境及其組件維持在組織工作環境標準中所指定之績效與可靠度水準。當需要時，專案的工作環境或部分組件可以內部自行發展或購自外部的供應商。 IPPD補充 有效的工作環境幫助專案利用IPPD，使用組合或分散式整合團隊去執行工作。雙向溝通媒體應該讓專案所有相關關鍵人員易於使用。 專案工作環境可能包含產品整合、驗證與確認的環境，或其可能為分立環境。 有關組織流程資產，尤其是組織度量儲存庫，請參考組織流程定義流程領域，以獲得更多資訊。 整合的專案管理(IPM+IPPD) 166
CMMI for Development Version 有關建立及維護專案產品整合環境，請參考產品整合流程領域的建立產品整合環境特定執行方法，以獲得更多資訊。 有關建立及維護專案驗證環境，請參考驗證流程領域的建立驗證環境特定執行方法，以獲得更多資訊。 有關建立及維護專案的確認環境，請參考確認流程領域的建立確認環境執行方法，以獲得更多資訊。 典型的工作產品 1. 專案的設備及工具 2. 專案工作環境的安裝、營運及維護手冊 3. 使用者調查與結果 4. 使用、績效及維護紀錄 5. 專案工作環境的支援服務 細部執行方法 1. 規劃、設計及安裝專案的工作環境。 如同其他產品一樣，專案工作環境的關鍵點是需求導向。以任何其他產品發展相同的嚴格度探索工作環境的功能性及操作性。 績效改善、成本及風險間可能須取捨，各別舉例如下： • 績效改善可能包括及時溝通、安全、保密及可維護性。 • 成本可能包括資本費用、教育訓練及支援架構、現有環境的拆卸及處置，以及環境的營運及維護。 • 風險可能包括工作流程及專案瓦解。 整合的專案管理(IPM+IPPD) 167
CMMI for Development Version 設備及工具，舉例如下： • 辦公軟體 • 決策支援軟體 • 專案管理工具 • 需求管理工具，設計工具 • 建構管理工具 • 評估工具 • 測試及（或）評估設備 2. 對專案工作環境提供持續的維護及營運支援。 工作環境的維護與支援可以用組織內部能力或外聘來達成。 維護及支援方法舉例如下： • 聘用人員來執行維護及支援 • 訓練人員來執行維護及支援 • 維護及支援外包 • 發展所選用工具的專家使用者 3. 維護專案工作環境構成組件的資格。 組件包括軟體、資料庫、硬體、工具、測試設備，以及適當的文件。軟體資格包括適當的檢定，硬體及測試工具資格則包括分類與調校紀錄以及分類標準的可追溯性。 4. 定期的審查工作環境符合專案需求及支援合作的程度，並適時採取行動。 可能採取的行動舉例如下： • 增加新的工具 • 採購額外的網路、設備、教育訓練及支援 整合的專案管理(IPM+IPPD) 168
CMMI for Development Version SP 整合計畫 整合專案計畫，以及其他影響描述專案已調適流程的計畫。 有關建立及維護專案計畫，請參考專案規劃流程領域，以獲得更多資訊。 有關組織流程資產，特別是組織度量庫，請參考組織流程定義流程領域，以獲得更多資訊。 有關界定度量及度量活動並使用分析技術，請參考度量與分析流程領域，以獲得更多資訊。 有關定義及分析風險，請參考風險管理流程領域，以獲得更多資訊。 有關組織流程需要與目標，請參考組織流程專注流程領域，以獲得更多資訊。 本特定執行方法延伸為建立及維護專案計畫的特定執行方法，以陳述額外的規劃活動，例如納入專案已調適流程、與相關關鍵人員協調、使用專案流程資產、納入同仁審查計畫，以及建立工作目標性的允入及允出準則。 專案計畫的發展應適當說明組織、客戶、供應商及最終使用者之當前和期望的需要、目標與需求。 IPPD補充 整合團隊的計畫包括在本整合計畫中。如果要推展一個複雜、多層次的整合團隊架構，發展完整的專案計畫與及專案已調適流程可能需要反覆多次的努力。 典型工作產品 1. 整合計畫 細部執行方法 1. 整合其他影響專案的計畫。 整合的專案管理(IPM+IPPD) 169
CMMI for Development Version 影響專案的其他計畫可能包括： • 品質保證計畫 • 建構管理計畫 • 風險管理策略 • 文件管理計畫 2. 將用來管理專案的度量定義與度量活動，納入專案計畫。 被納入的度量，舉例如下： • 組織的共通性度量 • 附加的專案特定度量 3. 界定並分析產品與專案介面的風險。 產品與專案介面的風險，舉例如下： • 不完整的介面描述 • 無法取得工具或測試設備 • 無法取得的現成品組件 • 不適當或無效的團隊介面 4. 安排工作順序時，考慮關鍵性發展因素與專案風險。 時程安排時的考量因素，舉例如下： • 工作項目的規模大小與複雜度 • 整合與測試議題 • 客戶與最終使用者的需求 • 關鍵資源的可用性 • 關鍵人物的可用性 5. 將對工作產品執行同仁審查的已調適流程，納入計畫。 整合的專案管理(IPM+IPPD) 170
CMMI for Development Version 有關同仁審查，請參考驗證流程領域，以獲得更多資訊。 6. 在專案的訓練計畫中，納入執行專案已調適流程所需的訓練。 這項工作通常包含與提供支援的組織訓練團隊協商。 7. 建立客觀的允入與允出準則，以授權分工結構圖(WBS)所描述之工作的啟動與完成。 有關分工結構圖，請參考專案規劃流程領域，以獲得更多資訊。 8. 確保專案計畫與相關關鍵人員的計畫相容。 通常會審查計畫與計畫變動的相容性。 9. 界定如何解決相關關鍵人員之間的衝突。 SP 使用整合計畫管理專案 使用專案計畫、影響專案的其他計畫及專案已調適流程來管理專案。. 有關組織流程資產，請參考組織流程定義流程領域，以獲得更多資訊。 有關組織流程需求及目標，以及與組織的其他單位協調流程改善活動，請參考組織流程專注流程領域，以獲得更多資訊。 有關管理風險，請參考風險管理流程領域，以獲得更多資訊。 有關專案監控，請參考專案監控流程領域，以獲得更多資訊。 典型的工作產品 1. 執行專案已調適流程所產生的工作產品 2. 已蒐集的度量(實際的)與進度紀錄或報告 整合的專案管理(IPM+IPPD) 171
CMMI for Development Version 3. 已修訂的需求、計畫及承諾 4. 整合計畫 細部執行方法 1. 使用組織流程資產館，實施專案已調適流程。 這項工作通常包括下列事項： • 從組織流程資產館，將合適的成果納入專案 • 使用自組織流程資產館中的學習心得來管理專案 2. 使用專案已調適流程、專案計畫及影響專案的其他計畫來監控專案的活動和工作產品。 這項工作通常包括下列事項： • 利用已定義的允入與允出準則，授權工作的啟動，並決定工作的完成 • 監控對專案的規劃參數有重大影響的活動 • 使用將引發調查和適當行動的度量門檻，來追蹤專案的規劃參數 • 監控產品與專案介面的風險 • 以執行專案已調適流程的工作項目與工作產品的計畫為基礎，管理外部與內部承諾 瞭解專案已調適流程中不同工作項目與工作產品間的關係、關鍵人員所扮演的角色，以及完整定義的控制機制(例如：同仁審查)，可達成較好且明顯的專案績效及較佳的專案控管。 3. 取得並分析所選擇的度量資料，以管理專案與支援組織的需求。 有關定義取得與分析度量的流程，請參考度量與分析流程領域，以獲得更多資訊。 4. 定期審查，並將專案績效與組織、客戶及最終使用者之當前和期望的需要、目標及需求，作適當的調整。 整合的專案管理(IPM+IPPD) 172
CMMI for Development Version 這項審查包括組織流程需要與目標的調整。 達成調整的措施，舉例如下： • 加速時程，並對其他的規劃參數與專案風險，作適當的調整 • 改變需求，以反應市場機會或客戶與最終使用者需求的變更 • 終止專案 SP 貢獻組織流程資產 貢獻工作產品、度量及經驗紀錄予組織流程資產。 有關流程改善建議，請參考組織流程專注流程領域，以獲得更多資訊。 有關組織流程資產、組織度量儲存庫及組織流程資產館，請參考組織流程定義流程領域，以獲得更多資訊。 本特定執行方法說明從專案已調適流程的流程蒐集資訊。 典型的工作產品 1. 針對組織流程資產所提出的改善措施 2. 從專案所蒐集之實際的流程與產品度量 3. 文件(如示範的流程描述、計畫、訓練模組、檢查表及學習心得) 4. 專案調適及執行組織標準流程的相關流程成果。 細部執行方法 1. 針對組織流程資產，提出改善方案。 2. 保存流程與產品度量資料於組織度量儲存庫中。 有關記錄規劃與重新規劃的資料，請參考專案規劃流程領域，以獲得更多資訊。 整合的專案管理(IPM+IPPD) 173
CMMI for Development Version 有關記錄度量資料，請參考專案監控流程領域，以獲得更多資訊。 通常包括下列事項： • 規劃資料 • 重新規劃資料 • 度量 專案紀錄的資料，舉例如下： • 工作項目描述 • 假設 • 估計值 • 修訂的估計值 • 記錄的資料與度量的定義 • 度量 • 使度量與執行活動及產出工作產品產生關聯的相關資訊 • 重新估計、評量其合理性及新工作之衍生估計值所需的相關資訊 3. 提交可能會納入組織流程資產館的文件。 文件，舉例如下： • 流程描述範例 • 訓練模組 • 計畫範例 • 檢查表 4. 記錄專案的學習心得，以納入組織流程資產館。 5. 為支援組織流程監控活動，提供與調適及執行組織標準流程相關的流程成果。 整合的專案管理(IPM+IPPD) 174
CMMI for Development Version 有關在新的及現有專案中，由組織活動來了解標準流程的推展程度，請參考組織流程專注流程領域的監控實施特定執行方法，以獲得更多資訊。 SG 2 與相關關鍵人員協調與合作 與相關的關鍵人員，進行專案的協調與合作。 SP 管理關鍵人員參與 管理相關的關鍵人員在專案的參與程度。 根據專案整合及已調適流程，管理相關關鍵人員的參與。 有關界定關鍵人員、關鍵人員的適當參與，以及建立並維護承諾，請參考專案規畫流程領域，以獲得更多資訊。 典型的工作產品 1. 協調活動的議程與時程 2. 議題紀錄(如客戶需求、產品及產品組件需求、產品架構與產品設計等議題) 3. 解決相關關鍵人員議題的建議 細部執行方法 1. 與應參與專案活動的相關關鍵人員協調。 相關的關鍵人員應已定義在專案計畫中。 2. 確保產出的工作產品滿足承諾，並符合承接專案的需求。 有關工作產品可接受度的決定，請參考驗證流程領域，以獲得更多資訊。 這項工作通常包括下列事項： • 由相關的關鍵人員適當的審查、展示或測試每項工作產品 整合的專案管理(IPM+IPPD) 175
CMMI for Development Version • 專案產出的每項工作產品，由接收工作產品的其他專案代表，作適當的審查、展示或測試 • 解決驗收工作產品的相關議題 3. 提出建議與協調的措施，以解決產品與產品組件間之需求、架構及設計的誤解與問題。 SP 管理相互依存關係 與相關的關鍵人員共同界定、協商與追蹤重要的依存關係。 有關界定關鍵人員、適當參與及建立並維護承諾，請參考專案規畫流程領域，以獲得更多資訊。 典型的工作產品 1. 與相關的關鍵人員審查所產生的缺失、議題及行動項目 2. 重要依存關係 3. 滿足重要依存關係的承諾 4. 重要依存關係的狀態 細部執行方法 1. 與相關的關鍵人員進行審查。 2. 界定每一重要依存關係。 3. 以專案的時程為基礎，建立每一重要依存關係的必要天數與計畫天數。 4. 對每個重要依存關係中，負責提交工作產品和承接工作產品之人員，審查承諾的履行並取得協議。 5. 記錄重要依存關係與承諾。 承諾文件通常包括下列事項： • 承諾的描述 • 界定承諾人員 整合的專案管理(IPM+IPPD) 176
CMMI for Development Version • 界定負責滿足承諾的人員 • 明確說明滿足承諾的時機 • 明確說明用來判定承諾是否滿足的準則 6. 追蹤重要的依存關係與承諾，並採取適當的矯正措施。 有關追蹤承諾，請參考專案監控流程領域，以獲得更多資訊。 追蹤重要的依存關係通常包括下列事項： • 評估延遲與提早完成的影響，以及它對未來活動及里程碑的衝擊 • 盡可能與負責人員解決實際與潛在的問題 • 將負責人員未解決之實際與潛在的問題，提昇至適當的管理階級 SP 解決協調議題 與相關的關鍵人員解決議題。 協調議題，舉例如下： • 遲來的重要依存關係與承諾 • 產品及產品組件需求與設計缺失 • 產品層級的問題 • 無法取得關鍵的資源或人員 典型的工作產品 1. 相關的關鍵人員協調議題 2. 相關的關鍵人員協調議題的狀況 細部執行方法 1. 界定與記錄議題。 2. 與相關關鍵人員溝通議題。 3. 與相關關鍵人員解決議題。 整合的專案管理(IPM+IPPD) 177
CMMI for Development Version 4. 將相關關鍵人員無法解決的議題，提報至適當的管理者。 5. 追蹤議題到結案。 6. 與相關關鍵人員溝通議題的狀態及解決。 整合的專案管理(IPM+IPPD) 178
CMMI for Development Version IPPD補充 SG 3 應用IPPD原則 使用IPPD原則管理專案。 本特定目標及執行方法的目的，在於建立IPPD環境，使整合團隊有效達成專案需求並產出優良產品。 SP 建立專案的共同願景 建立及維護專案的共同願景。 專案並非單獨運作，了解組織任務、目標、期望及限制，能使專案與組織方向、活動及共同願景密切結合，並有助於建立協調專案活動的共同目的。為達此，了解專案與外部關鍵人員之間的介面，以及所有內外部相關關鍵人員的目標與期望，是重要的。 建立共同願景時須考慮： • 外部關鍵人員的期望與需求 • 專案領導者、團隊領導者與團隊成員的期待與期望 • 專案的目標 • 專案將建立的條件與結果 • 專案須維護的介面 • 由介面團隊所建立的願景 • 由外在權威人士所加的限制(例如：環境規則) • 當致力於達成目標時的專案運作(含原則與行為兩者) 當建立共同願景時，專案的所有人員應受邀參加。雖然可能有一份建議草稿，但應讓更多人有機會表達與被傾聽他們真正關心的事務。共同願景要能清楚表達中心思想體系(價值、原則及行為)，以及對專案每個成員渴望的未來能作出保證。 有效的溝通策略是整個專案執行共同願景並使之清晰的關鍵。公佈共同願景是專案承諾共同願景的公開宣告，並提供機會給其他人員以檢定、瞭解及調整他們的活動往共同方向。溝通與協議共同願景，並且取得整合的專案管理(IPM+IPPD) 179
CMMI for Development Version IPPD補充 關鍵人員的承諾。 當有新的專案成員加入時，有效率的溝通也顯得特別重要。專案的新進人員常常需要更多或特別的注意，以確保其瞭解願景，願意支持並準備遵循願景來執行工作。 典型的工作產品 1. 共同願景文件 2. 溝通策略 3. 頒佈的原則、共同願景說明、任務說明及目標(例如：海報、隨身卡及簡報) 細部執行方法 1. 在目的或任務、願景、價值與目標上，清楚表達專案的共同願景。 2. 達成對專案共同願景的共識。 3. 建立對內與對外溝通專案共同願景的策略。 4. 為需要被告知專案共同願景的不同聽眾，製作合適的簡報。 5. 檢視專案及個別的活動與工作，是否符合專案共同願景。 SP 建立整合團隊架構 建立並維護專案的整合團隊架構 產品需求、成本、時程、風險、資源規劃、經營流程、專案的已調適流程以及組織指引，皆屬用以評估建立定義整合團隊及其責任、授權與相互關係的基礎。 典型的整合團隊架構，是以分工結構圖的產品導向層級為基礎。若分工結構圖不是產品導向、產品風險不一致及資源受限，會發生更複雜的結構。 整合的專案管理(IPM+IPPD) 180
CMMI for Development Version IPPD補充 整合團隊架構是動態的實體，隨著人員、需求及工作性質的異動而調整，並能處理許多困難。對小專案而言，整合團隊架構可視整個專案為整合團隊。應持續不斷地監控整合團隊架構，以發現機能不全、管理不善的介面，以及人員與工作的不協調。當績效無法符期望時，應採取矯正措施。 有關構成及組成整合團隊的建立組織規則與指引，請參考組織流程定義+IPPD流程領域中，整合團隊特定執行方法之建立原則與指引，以獲得更多資訊。 典型的工作產品 1. 產品與產品架構的評量，包含風險與複雜度。 2. 整合團隊架構 細部執行方法 1. 建立整合團隊架構。 整合團隊架構有賴於： • 產品風險及複雜度 • 風險的地點及型態 • 整合風險，包括產品組件的介面與團隊內部的溝通 • 資源，包括擁有適當技能的人員 • 有效率的合作受限於團隊大小 • 專案外部關鍵人員的團隊關係需求 • 經營流程 • 組織結構 整合團隊架構應基於，專案已調適流程和共同願景、組織標準流程，以及組織流程資產可應用於團隊與團隊間架構的瞭解。 2. 定期評估與修訂整合團隊架構，使最符合專案需要。 整合的專案管理(IPM+IPPD) 181
CMMI for Development Version IPPD補充 產品需求或架構的變動會影響團隊結構。 持續不斷地監督整合團隊架構，以偵測問題，例如：管理不善的介面，以及工作指派與人員執行工作的不協調。當績效無法符預期時，應採取包括評量推展團隊與架構的矯正措施。 團隊架構的變更包括如下： • 團隊除役一段時間（例如：當已完成長期的製造或驗證時） • 當團隊在服務專案上不再具成本效益時，解散該團隊 • 合併團隊以達成運作的效率 • 當界定須發展的新產品組件時，增加團隊 SP 分配需求至整合團隊 分配需求、責任、工作，以及介面至整合團隊架構的各團隊。 在任何團隊形成之前，先完成整合團隊需求的分配，以驗證整合團隊架構是可行的，且涵蓋所有必要需求、責任、職權、工作項目及介面。一旦確認架構，選定整合團隊負責人來建立該架構中的各別團隊。 典型的工作產品 1. 每一整合團隊的責任分配 2. 各整合團隊有責任滿足之工作產品需求、技術介面及經營介面(如成本會計及專案管理) 3. 整合團隊負責人清單 細部執行方法 1. 分配工作項目、責任、交付的工作產品，以及相關需求及介面至適當的整合團隊。 整合團隊的經營、管理及其他非技術性的權責，是 整合的專案管理(IPM+IPPD) 182
CMMI for Development Version IPPD補充 適當團隊功能的必須元素。整合團隊的責任及權限通常由專案發展出來，並與已建立的組織執行方法一致。 責任及權限，舉例如下： • 團隊挑選其負責人的權力 • 團隊建立子團隊的權力（例如：產品團隊組成整合子團隊） • 報告體系 • 報告需求（成本、時程及績效狀況） • 進度報告的度量與方法 2. 檢查需求與介面的分配是否涵蓋所有指定的產品需求與其他需求。 如果未達到需求的完全涵蓋，應採取矯正措施，以重新分配需求或改變整合團隊架構。 3. 指定各整合團隊的負責人。 整合團隊負責人是（個別或團隊）管理者，負責建立及提供資源給整合團隊，監控團隊的活動與進度，以及需要時採取矯正措施。團隊負責人可能同時管理一或多個團隊，也可以是專案經理。 SP 建立整合團隊 建立並維護架構中的整合團隊。 由團隊負責人建立整合團隊架構中的整合團隊。本該流程包含選擇團隊領導者及團隊成員，以及根據需求分配建立各整合團隊團隊規章。同時也包含提供必要資源，以完成指派給團隊的工作。 有關建構成及組成整合團隊的建立組織規則與指引，請參考組織流程定義+IPPD流程領域，整合團隊特定執行方法之建立規則與指引，以獲得更多資訊。 整合的專案管理(IPM+IPPD) 183
CMMI for Development Version IPPD補充 典型的工作產品 1. 團隊領導人清單 2. 團隊成員指派到各整合團隊的清單 3. 整合團隊規章 4. 用來評估整合團隊績效的度量 5. 定期的整合團隊狀況報告 細部執行方法 1. 選擇各整合團隊的領導者。 在選擇領導者的組織及專案方向範圍上，通常視產品風險及複雜度，或具有組織需要培養新領導者的功能。依照組織政策，團隊負責人可選擇團隊領導者，或由團隊成員間投票選出。 2. 分配資源給各整合團隊[s1]。 分配人員與其他資源給各整合團隊。與團隊討論這些項目，以確保資源及人員足以完成工作，並能與其他團隊成員共處。 3. 規範各整合團隊。 團隊規章是團隊成員間，以及團隊與其負責人間對工作預期及績效等級的契約。規章建立了權利、保證、特權，以及授與同意權來組織及執行團隊所分派的需求及介面、責任與工作項目。整合團隊及其負責人發展團隊規章，視為談判活動。當雙方都核准時，團隊規章制定了被認可的管理權力協議。 規章包括下列幾方面： • 如何接受指派 • 如何評估資源及投入 • 如何完成工作 • 誰來檢討及審查工作 整合的專案管理(IPM+IPPD) 184
CMMI for Development Version IPPD補充 • 如何核准工作 • 如何交付及溝通工作 4. 當團隊領導人或其他成員發生重大變更時，審查整合團隊架構中的整合團隊組合及配置。 這種變更可能嚴重影響團隊完成目標的能力。需要審查新組合與新責任間的契合度，若新組合無法滿足，需要改變團隊組合或調整團隊責任。 5. 當團隊責任變更時，審查團隊組合及任務分派。 責任變更通常發生在專案從一階段進行至下一階段時。舉例來說，當細部設計完成，以及建構和整合產品組件開始時，愈不需要團隊設計技術。 6. 管理團隊整體績效。 規章應指定如何度量團隊及個別績效，也應包括在專案中團隊的關鍵成功因素。 SP 確保跨團隊間的合作 確保跨團隊間的合作。 以團隊組成的專案，其成功的作用在於整合團隊如何有效率及成功地與其他團隊合作，以達成專案目標。團隊合作可藉由控制工作團隊介面而達成。 有關管理關鍵人員參與、重要相互依存關係及解決合作議題，請參考本流程領域之相關關鍵人員的協調與合作特定目標，以獲得更多資訊。 有關建立組織期望及規則，引導整合團隊如何共同工作，請參考組織流程定義(IPPD)流程領域中，整合團隊建立原則與指引之指定執行方法，以獲得更多資訊。 典型工作產品 1. 工作產品所有權協議 整合的專案管理(IPM+IPPD) 185
CMMI for Development Version IPPD補充 2. 團隊工作計畫 3. 承諾清單 細部執行方法 1. 建立與維護在專案或跨團隊間，工作產品所有權的界限。 2. 建立與維護在跨團隊間，投入、產出與工作產品的介面與流程。 3. 發展、溝通與分配在跨團隊間，與工作產品或團隊介面相關的承諾清單與工作計畫。 整合的專案管理(IPM+IPPD) 186
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施整合的專案管理流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 僅適用於階段式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃並執行整合的專案管理流程。 詳細說明： 本政策建立組織期望：從專案開始到專案全期，建立及維護專案已調適流程，並使用專案已調適流程來管理專案，以及與相關的關鍵人員協調合作。 IPPD補充 本政策應用IPPD原則，建立組織期望。 整合的專案管理(IPM+IPPD) 187
CMMI for Development Version GP 規劃流程 建立並維護執行整合的專案管理流程的計畫。 詳細說明： 整合專案管理流程計畫，結合專案規劃及監控流程計畫。在整合專案管理中，描述實施規劃相關執行方法計畫，是規劃專案規劃流程的一部分。專案規劃流程領域提及，在整合專案管理中，實施監控相關執行方法計畫，可包含（或參考）專案計畫。 有關一般執行方法與專案規劃流程間的關係，請參考一般目標與一般執行方法表，以獲得更多資訊。 GP 提供資源 提供充足的資源，以執行整合的專案管理流程、發展工作產品及提供流程服務。 詳細說明： 提供的資源，舉例如下： • 問題追蹤與困境報告的相關資料 • 群組軟體 • 視訊會議 • 整合的決策資料庫 • 整合的產品支援環境 GP 指派責任 指派整合的專案管理流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援整合的專案管理流程。 整合的專案管理(IPM+IPPD) 188
CMMI for Development Version 詳細說明： 訓練的主題，舉例如下： • 調適組織標準流程，以符合專案的需求 • 以專案已調適流程為基礎，管理專案的程序 • 使用組織度量儲存庫 • 使用組織流程資產 • 整合的管理 • 群組之間的協調 • 群組問題的解決 IPPD 補充 訓練的主題，舉例如下： • 建立專案的共同願景 • 團隊建立 GP 管理建構 將指定的整合的專案管理流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 專案已調適流程 • 專案計畫 • 影響專案的其他計畫 • 整合計畫 • 自專案中蒐集到的實際流程與產品度量 IPPD補充 納入控制的工作產品，舉例如下： • 專案共用願景 整合的專案管理(IPM+IPPD) 189
CMMI for Development Version • 整合團隊架構 • 整合團隊規章 GP 界定並納入相關的關鍵人員 依計畫界定並納入整合的專案管理流程相關的關鍵人員。 詳細說明： 有關一般執行方法GP 與本流程領域之管理關鍵人員參與執行方法間的關係，請參考一般目標與一般執行方法表，以獲得更多資訊。 關鍵人員參與的活動，舉例如下： • 解決調適組織流程資產的議題 • 解決專案計畫與影響專案的其他計畫之間的議題 • 審查專案的績效，以調整現行的與期望的需要、目標及需求 IPPD補充 關鍵人員參與的活動，舉例如下： • 建立專案的共同願景 • 定義專案的整合團隊架構 • 產生整合團隊 GP 監控流程 依本流程的執行計畫，監控整合的專案管理流程，以執行流程，並採取適當的矯正措施。 整合的專案管理(IPM+IPPD) 190
CMMI for Development Version 詳細說明： 用於監控的度量及工作產品，舉例如下： • 專案已調適流程變動的次數 • 調適組織標準流程的時程與工作量 • 介面協調議題趨勢(例如：已界定與已結案的數量) • 專案調適活動的時程 IPPD補充 用於監控的工作產品，舉例如下： • 專案共同願景的使用性與有效性 • 整合團隊架構的使用性與有效性 • 整合團隊規章的使用性及有效性 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估整合的專案管理流程的遵循程度，並解決不符合的情況。. 詳細說明： 審查的活動，舉例如下： • 建立、維護及使用專案已調適流程 • 與相關關鍵人員的協調與合作 IPPD補充 審查的活動，舉例如下： • 使用專案的共同願景 • 組織整合團隊 整合的專案管理(IPM+IPPD) 191
CMMI for Development Version 審查的工作產品，舉例如下： • 專案已調適流程 • 專案計畫 • 影響專案的其他計畫 IPPD補充 審查的工作產品，舉例如下： • 整合團隊架構 • 整合團隊規章 • 共同願景敘述 GP 與上層管理人員審查各狀況 與上層管理人員審查整合的專案管理流程的活動、狀況及結果，並解決問題。 僅適用於流程式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義整合的專案管理流程的說明。 詳細說明： 有關一般執行方法與整合專案管理流程領域間的關係，請參考一般目標與一般執行方法表，以獲得更多資訊。 整合的專案管理(IPM+IPPD) 192
CMMI for Development Version GP 蒐集改善資訊 蒐集由規劃及執行整合的專案管理流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 詳細說明： 有關一般執行方法與整合專案管理流程領域間的關係，請參考一般目標與一般執行方法表，以獲得更多資訊。 工作產品、度量、度量結果與改善資訊，舉例如下： • 專案已調適流程 • 專案使用數個調適選項，來創造已調適流程 • 介面協調議題趨勢（例，已界定與已結案數量） • 為取得規劃專案相關的資產，專案個人讀取PAL的次數。 • 召開面對面會議的費用紀錄，相對於使用協調設備的會議，如視訊及音訊設備。 IPPD補充 工作產品、度量、度量結果與改善資訊，舉例如下： • 整合團隊規章 • 專案共同願景 整合的專案管理(IPM+IPPD) 193
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護整合的專案管理流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定整合的專案管理流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保整合的專案管理流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正整合的專案管理流程之缺失與其他問題的根本原因。 整合的專案管理(IPM+IPPD) 194
CMMI for Development Version 度量與分析 成熟度第二級的支援類流程領域 目的 度量與分析(Measurement and Analysis, MA)的目的在發展與維持度量能力，以支援管理之資訊需求。 簡介 度量與分析流程領域包括： • 指定度量與分析的目標，並使其配合已界定的資訊需求與目標 • 指定度量、分析技術、資料蒐集、資料儲存以及報告與回饋機制 • 執行資料的蒐集、儲存、分析及報告 • 提供客觀的結果以做出有根據的決策，並採取適當的矯正措施 將度量與分析活動整合到專案流程中，可支援下列活動： • 客觀的規劃與估計 • 根據建立的計畫和目標，追蹤實際績效 • 界定與解決流程相關議題 • 提供將度量納入未來增訂流程的基礎 執行度量功能的同仁，不一定需參與組織層面的計畫。度量功能可以整合至個別專案，或其他的組織功能(例如：品質保證)。 度量活動最初的重點是在專案，而度量功能在處理組織面與(或)企業面的資訊需求上，亦經證明確實有用。為支援度量功能，度量活動應支援多層次的資訊需求，包括業務、組織單位及專案及當組織成熟時，支援減低重工。 度量分析(MA) 195
CMMI for Development Version 專案可選擇在專案特定儲存庫中儲存專案的資料與結果。當資料更廣為各專案分享時，可存放於組織度量儲存庫。 針對供應商提供的產品組件進行度量與分析，對有效管理專案的品質與成本是必要的。經由謹慎的管理供應商協議，可深入瞭解支援供應商績效分析的資料。 相關流程領域 有關估計專案屬性和其他規劃資訊需求，請參考專案規劃流程領域，以獲得更多資訊。 有關監控專案績效資訊需求，請參考專案監控流程領域，以獲得更多資訊。 有關管理度量工作產品，請參考建構管理流程領域，以獲得更多資訊。 有關滿足客戶需求和相關資訊需求，請參考需求發展流程領域，以獲得更多資訊。 有關維持需求的可溯性和相關資訊需求，請參考需求管理流程領域，以獲得更多資訊。 有關建立組織度量儲存庫，請參考組織流程定義流程領域，以獲得更多資訊。 有關瞭解變異和適當使用統計分析技術，請參考量化專案管理流程領域，以獲得更多資訊。 度量分析(MA) 196
CMMI for Development Version 特定目標及執行方法摘要 SG 1安排度量與分析的活動 SP 建立度量目標 SP 指定度量 SP 指定資料蒐集與儲存程序 SP 指定分析程序 SG 2 提供度量結果 SP 蒐集度量資料 SP 分析度量資料 SP 儲存資料與結果 SP 溝通結果 各目標的特定執行方法 SG 1 安排度量與分析的活動 度量目標與活動要配合已界定的資訊需求與目標。 本目標涵蓋的特定執行方法，可同時處理或依任意順序處理： • 建立度量目標時，專家經常先考量界定度量和分析程序的必要準則，同時也會考量資料蒐集與儲存程序的限制。 • 在處理度量規格、資料蒐集或儲存等細節之前，先界定需進行的必要分析，通常是重要的。 SP 建立度量目標 建立並維護度量目標，此度量目標衍生自已界定的資訊需求與目標。 度量目標記錄完成度量與分析活動的目的，並界定基於資料分析的結果，需要採取何種行動。 度量目標的來源可能是管理、技術、專案、產品或流程實施的需要。 度量分析(MA) 197
CMMI for Development Version 度量目標可能受限於現行的流程、可用的資源或其他的度量考量。需要判斷投入度量工作的資源與度量結果的價值是否相當。 度量與分析的過程及結果，將影響已界定的資訊需求與目標的修改。 資訊需求與目標的來源，舉例如下： • 專案計畫 • 專案績效的監控 • 與管理人員和其他具有資訊需求的人員進行訪談 • 已建立的管理目標 • 策略計畫 • 經營計畫 • 正式需求或合約義務 • 再發的或其他棘手的管理或技術問題 • 其他專案或組織的經驗 • 外部的產業標竿 • 流程改善計畫 度量目標舉例如下： • 減少交付時間 • 減少生命週期總成本 • 完整交付指定功能 • 改善優先層級的品質 • 改善優先客戶滿意度評等 • 維護與改善採購/供應商的關係 有關估計專案屬性和其他規劃資訊需求，請參考專案規劃流程領域，以獲得更多資訊。 有關專案績效資訊需求，請參考專案監控流程領域，以獲得更多資訊。 有關滿足客戶需求和相關資訊需求，請參考需求發展流程領域，以獲得更多資訊。 度量分析(MA) 198
CMMI for Development Version 有關維持需求的可追溯性和相關資訊需求，請參考需求管理流程領域，以獲得更多資訊。 典型的工作產品 1. 度量目標 細部執行方法 1. 記錄資訊需求與目標。 記錄資訊需求與目標，以維持後續度量與分析活動的可追溯性。 2. 排定資訊需求與目標的優先順序。 並非所有最初界定的資訊需求都需要度量與分析，在可用資源的限制下，必須排定優先順序。 3. 記錄、審查及更新度量目標。 仔細考量度量與分析的目的與預期的用途是重要的。 記錄度量目標，並交由管理人員和其他相關的關鍵人員審查，必要時並予更新，使得接續的度量與分析活動可以追溯，並幫助確保分析活動可適當的說明資訊需求與目標。 讓度量與分析結果的使用者參與設定度量目標與決定行動計畫是重要的。讓提供度量資料的人員參與也是適當的。 4. 必要時提供回饋，以調修和釐清資訊需求與目標。 設定度量目標後可能需修訂和釐清界定的資訊需求與目標。資訊需求的初始描述可能不清楚或模糊。現存的需求和目標之間可能產生抵觸。對一個已經存在的度量，要求精確的目標可能是不切實際的。 5. 維持度量目標和指定的資訊需求與目標之間的可溯性。 度量分析(MA) 199
CMMI for Development Version 對於「為何要作這項度量？」這樣的問題，必須要有好的答案。 當然，也可以改變度量目標，以反映不斷發展的資訊需求與目標。 SP 指定度量 指定度量以說明度量的目標。 將度量目標調修為精確的、可量化的度量。 度量包括「基礎」度量與「衍生」度量，基礎度量資料得自於直接度量，衍生度量資料來自其他資料，通常結合多個基礎度量而得。 一般使用的基礎度量，舉例如下： • 工作產品規模大小的估計及實際度量(例如：頁數) • 人力與成本的估計及實際度量(例如：人時) • 品質度量(例如：缺失數、依嚴重程度區分的缺失數) 一般使用的衍生度量，舉例如下： • 所得價值(Earned Value) • 時程績效指標(SPI) • 缺失密度 • 同仁審查涵蓋度 • 測試或驗證涵蓋度 • 可靠度度量(例如:平均失敗時間) • 品質度量(例如：依嚴重程度區分的缺失數/總缺失數) 度量分析(MA) 200
CMMI for Development Version 衍生度量通常以比例、混合指標或其他合計度量來表示。衍生度量由基礎度量產生，通常比基礎度量更具數量可信度和說明意義。 典型的工作產品 1. 基礎與衍生度量規格 細部執行方法 1. 依據文件化的度量目標，界定可能的度量。 度量目標被調修為特定的度量，根據度量的名稱和單位，將這些可能的度量予以分類。 2. 界定已經存在且可以說明度量目標的度量。 度量規格可能已經存在，或許早期為其他目的而建立，或存在於組織的某處。 3. 指定度量的操作定義。 以精確和明白的方式陳述操作定義，有下列兩個重要準則： • 可溝通：度量什麼？如何度量？度量的單位是什麼？包括或排除什麼？ • 可重複：在相同的定義下，度量是否可以重複執行，且獲得相同的結果？ 4. 將度量排序，並予以審查及更新。 請可能的最終使用者和其他相關的關鍵人員，對所建議之度量規格的適當性進行審查。可設定或改變排序，必要時可更新度量規格。 SP 指定資料蒐集與儲存程序 指定度量資料如何獲得與儲存。 明確規範蒐集方法可確保適當的蒐集正確的資料，也幫助更進一步釐清資訊需求和度量目標。 注意儲存和取用程序，可協助確保資料將來的可用性及可存取性。 度量分析(MA) 201
CMMI for Development Version 典型的工作產品 1. 資料蒐集與儲存程序 2. 資料蒐集工具 細部執行方法 1. 界定由目前工作成果、流程或交易產生的資料來源。 在指定度量時，可能已有現行的資料來源。不論相關的資料是否已蒐集，適當的資料蒐集機制可能已存在。 2. 界定目前沒有資料，但需要的度量。 3. 為每一項需要的度量，指定資料蒐集與儲存的方法。 明確的描述資料如何蒐集、從何處蒐集及何時蒐集，並描述蒐集有效資料的程序。資料以容易取得的方式儲存以便於分析，並決定資料是否需儲存，以作為再分析或撰寫文件之用。 通常考量的問題包括如下： • 是否已經決定資料蒐集的頻率，以及在流程中執行度量的時點? • 是否已經建立將度量結果自資料蒐集處轉移到資料儲存庫、其他資料庫或最終使用者處所的時序? • 誰負責取得資料? • 誰負責資料儲存、取得及安全維護? • 是否已發展或取得必要之支援工具? 4. 建立資料蒐集的機制與流程指引。 資料蒐集與儲存的機制需與其他一般工作流程整合。資料蒐集的機制可以包括人工/自動的表格與樣板。負責這項工作的人員，提供清楚簡明的指引以正確執行工作。視需要提供訓練，說明蒐 度量分析(MA) 202
CMMI for Development Version 集資料的流程，以便蒐集完整與正確的資料，並減輕負責提供和記錄資料人員的負擔。 5. 適當且可行時，支援資料蒐集自動化。 自動化的支援可以幫助蒐集更完整與正確的資料。 自動化的支援，舉例如下： • 時間戳記的活動日誌 • 成果的靜態或動態分析 然而，有些資料沒有人工介入無法蒐集(例如：客戶滿意度或其他人為判斷)，且為了自動化建立所需的基礎建設可能相當昂貴。 6. 對資料蒐集與儲存程序加以排序，並進行審查及更新。 資料蒐集與儲存程序的適當性與可行性，必須經過負責提供、蒐集及儲存資料人員的審查，他們對於如何改進現行的流程或建議其他有用的度量和分析，具備洞察力。 7. 必要時更新度量與度量目標。 基於以下的條件，度量與度量目標需要重新排定優先順序： • 度量的重要性 • 取得資料所需的代價 考量因素包括取得這個資料是否需要新的表格、工具或訓練。 SP 指定分析程序 指定度量資料如何分析與報告。 事先指定度量的分析程序，可確保執行適當的分析與報告，以說明已記錄的度量目標(亦說明了資訊需度量分析(MA) 203
CMMI for Development Version 求和目標，因其為度量目標的基礎)。此方法也是必要資料蒐集的一種查核。 典型的工作產品 1. 分析規格與程序 2. 資料分析工具 細部執行方法 1. 指定將要執行的分析與將準備的報告，並排定優先順序。 及早注意所執行的分析，以及分析報告呈現的方式。應符合下列準則： • 分析可以清楚的說明度量目標。 • 表達結果的方式，能讓需處理此結果的人員清楚瞭解。 在可取得的資源內排定優先順序。 2. 選擇適當的資料分析方法與工具。 有關瞭解變異和適當使用統計分析技術，請分別參考量化專案管理流程領域之「應用統計方法瞭解變異」和「選擇度量與分析技術」特定執行方法，以獲得更多資訊。 考量點通常包括如下： • 選擇視覺顯示方法和其他呈現技術(例如：圓形圖、長條圖、柱狀圖、雷達圖、線條圖、分佈圖或表格) • 選擇適合的敘述統計方法(例如：算數平均數、中數或眾數) • 當無法或無必要檢驗每一資料元素時，決定統計取樣的準則 • 當出現缺少資料元素時，決定如何處理分析 • 選擇適當的分析工具 敘述統計通常用於資料分析，以執行下列事項： 度量分析(MA) 204
CMMI for Development Version • 審查指定度量的分佈(例如：集中趨勢、變化程度、資料點呈現異常變異) • 審查指定度量之間的相互關係(例如：以產品生命週期的不同階段或產品組件來比較缺失) • 顯示隨著時間的變化 3. 指定分析資料和溝通結果的管理程序。 考量點通常包括如下： • 指定適合的人員和團體負責分析資料和簡報結果 • 決定分析資料和簡報結果的時間 • 決定溝通結果的方式(例如：進度報告、傳送備忘錄、書面報告或工作人員會議) 4. 審查並更新分析與報告的內容和形式。 所有提出的分析與報告的內容和形式應予審查和修正，包括分析方法和工具、管理程序及優先順序。相關關鍵人員的諮詢應該包括預期的最終使用者、贊助者、資料分析人員及資料提供人員。 5. 必要時，更新度量與度量目標。 正如同度量需求會導引資料分析，清楚的分析準則會影響度量。以資料分析程序為基礎，某些度量規格可能會進一步調修，其他度量可能並不需要，或發現需要其他的度量。 當描述度量如何分析和報告時，可能同時會建議調修度量目標。 6. 指定評估分析結果有用性及評估度量與分析活動的準則。 評估分析結果有用性的準則，可以考慮下列項目的應用程度： • 分析結果是否(1)適時提供、(2)容易瞭解，以及(3)可用來制定決策。 • 分析工作的執行成本不應比它提供的效益高。 度量分析(MA) 205
CMMI for Development Version 度量與分析活動的評估準則可考慮下列項目的應用程度： • 資料缺少與不一致的數量是否超出門檻。 • 資料取樣是否有偏差(例如：僅調查滿意的使用者以評估最終使用者滿意度，或只評估不成功的專案以決定整體生產力)。 • 度量資料是否可重複(例如：統計上的可靠性)。 • 統計的假設是否滿足(例如：關於資料的分佈或關於度量單位的合適性) SG 2 提供度量結果 提供度量結果，此度量結果說明已界定的資訊需求與目標。 進行度量和分析的主要理由，是要處理已界定的資訊需求與目標。以客觀證據為基礎的度量結果，能夠幫助監測績效、履行契約義務、制定有根據的管理與技術決策，以及採取矯正措施。 SP 蒐集度量資料 獲得指定的度量資料。 取得需分析的資料，並檢查其完整性和整合性。 典型的工作產品 1. 基礎度量資料集與衍生度量資料集 2. 資料完整性測試的結果 細部執行方法 1. 獲得基礎度量資料。 視需要蒐集資料，包括已使用的與新指定的基礎度量。現存資料可從專案紀錄或在組織其他地方蒐集。 需注意，以前已蒐集並放置於現行的資料庫、文件紀錄或正式儲存庫中的資料，可能無法再使用。 度量分析(MA) 206
CMMI for Development Version 2. 產生衍生度量資料。 重新計算所有衍生度量的值。 3. 檢查資料一致性，使其儘可能接近原始資料。 所有度量在說明或記錄資料的過程中可能發生錯誤，最好能在度量與分析週期的初期界定這些錯誤，並能指出所缺資料的來源。 檢查應包括詳查缺少的資料、超出所訂範圍的資料值，以及不尋常的型態和度量間的相關性。下列工作特別重要： • 測試和修正人為判斷分類的不一致(亦即決定工作人員根據相同資訊而做出不同分類決策的頻率，否則稱作「互相轉譯的可靠度」)。 • 以經驗審查用來計算衍生度量之度量間的關係，如此可確保未忽視重要差異，以及傳達衍生度量的預期的意義(否則稱作「準則有效性(criterion validity)」)。 SP 分析度量資料 分析與解釋度量資料。 依照計畫分析度量資料，並視需要執行額外的分析。分析結果需由相關的關鍵人員審查，並記錄將來分析所需做的修正。 典型的工作產品 1. 分析結果與報告草案 細部執行方法 1. 進行初步分析並解釋結果，並導出初步結論。 資料分析的結果很少可以顯而易見。解釋結果與產生結論的準則應予明確的陳述。 2. 必要時，執行額外的度量與分析，並準備進行簡報。 度量分析(MA) 207
CMMI for Development Version 規劃的分析結果可能提出進行額外、非預期分析的建議。此外，為適當完成計畫內的分析工作可能界定下列需求，例如：調修現行度量、計算額外的基礎度量，或為額外的原始度量蒐集資料。相同地，為了準備初步分析結果的簡報，可能界定出額外、未預期的分析需要。 3. 與相關的關鍵人員審查初步分析結果。 在分析結果廣泛傳佈之前，對結果的初步解釋及其表達的方式加以審查是否適當。 在初步結果發表之前予以審查，可以避免不必要的誤解，並改善資料分析與呈現方式。 進行審查的相關關鍵人員包括預期的最終使用者、贊助者、資料分析人員及提供人員。 4. 為未來的分析調修準則。 可改善未來工作之學習心得，經常來自於執行資料分析和準備結果時。類似狀況，當有調修指定的資訊需求與目標的構想時，改善度量規格及資料蒐集程序的方式可能會變得明顯。 SP 儲存資料與結果 管理和儲存度量資料、度量規格和分析結果。 儲存度量相關資訊，使未來能更及時和經濟的使用歷史資料與結果。此資訊也對資料詮釋、度量準則及分析結果，提供充分的說明內容。 儲存的資訊通常包括如下： • 度量計畫 • 度量規格 • 已蒐集的資料 • 分析報告和簡報資料 儲存的資訊包含或參考下列資訊：瞭解和解釋度量的資訊，以及評量其合理性及適用性之資訊(例如： 度量分析(MA) 208
CMMI for Development Version 進行專案之間的比較時，不同的專案可能使用不同的度量規格)。 衍生度量的資料集通常可以重新計算，所以不需要儲存，可能較適合儲存衍生度量的摘要(例如：圖表、結果表格或報告)。 如果可以有效重建中間分析的結果，這中間分析結果不需要個別儲存。 專案可在專案特定儲存庫中儲存專案特定的資料與結果。當資料於專案間廣泛的共享時，可以存放在組織度量儲存庫。 有關建立組織度量儲存庫，請參考組織流程定義流程領域的「建立組織度量儲存庫」特定執行方法，以獲得更多資訊。 有關管理度量工作產品，請參考建構管理流程領域，以獲得更多資訊。 典型的工作產品 1. 儲存資料清單 細部執行方法 1. 審查資料以確保完整性、一致性、正確性與及時性。 2. 根據資料儲存程序來儲存資料 3. 確定儲存的內容僅提供適當的團體與人員使用。 4. 防止資料不當使用。 防止資料及相關資訊不當使用的例子包括：控制資料的存取權限及教育同仁適當使用資料。 度量分析(MA) 209
CMMI for Development Version 不當使用資料之情形，舉例如下： • 揭露秘密資訊 • 由於不完全、不相關或其他誤導的資訊，而造成錯誤的解釋 • 不當的評估同仁的績效或進行專案評比 • 責難特定人員的正直與誠實。 SP 溝通結果 向所有相關的關鍵人員報告度量與分析活動的結果。 用即時、有用的方式，向所有相關的關鍵人員報告度量與分析的結果，以支援制訂決策與協助採取矯正措施。 相關的關鍵人員包括預定的使用者、贊助者、資料分析人員及資料提供人員。 典型的工作產品 1. 交付的報告和相關的分析結果 2. 能幫助詮釋分析結果的相關資訊或指引 細部執行方法 1. 及時告知相關的關鍵人員度量結果。 度量結果因為有預期目的，因此需及時傳達。報告如果未能分送給所有需要知道結果的人，則報告不太可能會被使用。 在可能的範圍內，度量結果的使用者應親自參與設定目標與決定度量與分析行動的計畫，就如同他們執行企業的部分任務一般。進度和中間結果定期持續告知使用者。 有關度量結果的使用，請參考專案監控流程領域，以獲得更多資訊。 度量分析(MA) 210
CMMI for Development Version 2. 協助相關的關鍵人員瞭解結果。 以清楚簡明的方式，對相關的關鍵人員報告結果，。報告必須易於瞭解、詮釋，並且與指定的資訊需求及目標清楚連結。 對不是度量專家的從業者而言，很難從資料中自行詮釋其涵義，選擇度量方式應瞭解下列原因： • 如何與為何指定基礎度量和衍生度量 • 如何取得資料 • 如何使用資料分析方法解釋結果 • 結果如何說明資訊需求 協助瞭解結果的活動，舉例如下： • 與相關的關鍵人員討論結果 • 提供內含背景與解說的備忘錄 • 對使用者進行度量結果的簡報 • 提供關於適當使用和瞭解度量結果的教育訓練。 度量分析(MA) 211
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施度量與分析流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 GP 建立組織政策 建立並維護組織政策，以規劃和執行度量與分析流程。 詳細說明： 本政策建立組織的期望，使度量目標與活動和已界定的資訊需求與目標相一致，並提供度量結果。 GP 規劃流程 建立並維護執行度量與分析流程的計畫。 詳細說明： 專案計畫可以包含(或參考)執行度量與分析流程的計畫。專案計畫在專案規劃流程領域中說明。 GP 提供資源 提供充足的資源，以執行度量與分析流程、發展工作產品及提供流程服務。 度量分析(MA) 212
CMMI for Development Version 詳細說明： 度量人員可以是專職或兼職，亦可組成一個小組，同時支援多個專案度量活動。 其他提供的資源，舉例如下： • 統計套裝軟體 • 支援透過網路蒐集資料的套裝軟體 GP 指派責任 指派度量與分析流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援度量與分析流程。 詳細說明： 訓練的主題，舉例如下： • 統計技術 • 資料蒐集、分析及報告流程 • 與目標相關度量的發展(例如：目標問題矩陣) GP 管理建構 將指定的度量與分析流程工作產品，納入適當層級的管制。 度量分析(MA) 213
CMMI for Development Version 詳細說明： 納入管制的工作產品，舉例如下： • 基礎度量和衍生度量規格 • 資料蒐集和儲存的程序 • 基礎度量資料集和衍生度量資料集 • 分析結果和報告草案 • 資料分析工具 GP 界定並納入相關的關鍵人員 依計畫界定並納入度量與分析流程相關的關鍵人員。 詳細說明： 關鍵人員參與的活動，舉例如下： • 建立度量目標與程序 • 評量度量資料 • 給負責對原始資料提供分析和結果的人，提供有意義的回饋 GP 監控流程 依本流程的執行計畫，監控度量與分析流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量與工作產品，舉例如下： • 使用進度及績效度量的專案，佔整個組織專案的百分比 • 度量目標達成的百分比 • 收集與審查度量資料的時程 度量分析(MA) 214
CMMI for Development Version GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估度量與分析流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 安排度量與分析活動 • 提供度量結果 審查的工作產品，舉例如下： • 基礎度量和衍生度量規格 • 資料蒐集和儲存的程序 • 分析結果和報告草案 GP 與上層管理人員審查各狀況 與上層管理人員審查度量與分析流程的活動、狀況及結果，並解決問題。 僅適用於階段式表述 GG 3 和其執行方法不適用於成熟度第二級評等，但對於成熟度第三級和更高等級評等而言，是適用的。 度量分析(MA) 215
CMMI for Development Version 僅適用於連續式/成熟度第3-5級 GG 3 制度化已定義流程 將流程制度化為已調適流程。 GP 建立已定義流程 建立並維護已定義度量與分析流程的說明。 GP 蒐集改善資訊 蒐集由規劃並執行度量與分析流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 詳細說明： 工作產品、度量、度量資料及改善資訊，舉例如下： • 資料即時狀態 • 資料整合性測試結果 • 資料分析報告 度量分析(MA) 216
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護度量與分析流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定度量與分析流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保度量與分析流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正度量與分析流程之缺失與其他問題的根本原因。 度量分析(MA) 217
CMMI for Development Version 組織創新與推展 成熟度第五級的流程管理類流程領域 目的 組織創新與推展(Organizational Innovation and Deployment, OID)的目的，在於選擇與推展具漸進和創新效果的各種改善措施。這些改善措施以可度量的方式，改善組織流程和技術，也支持由組織經營目標導出的品質和流程績效目標。 簡介 組織創新與推展流程領域藉由改善措施的選擇與推展，加強組織能力，以滿足其品質和流程績效目標(有關「品質和流程績效目標」的定義，請參見詞彙)。本流程領域所用的術語「改善」係指可變更組織流程和技術的所有構想(含已證明及未證明的)，以更符合組織的品質和流程績效目標。 本流程領域所說明的品質和流程績效目標，可包括： • 改善的產品品質(例如：功能、績效) • 提升的生產力 • 減低的週期時間 • 更高的客戶和最終使用者滿意度 • 因應變更功能、增加新特性或採用新技術，較短的發展和生產時間 • 減少交付時間 • 減少適應新技術及經營需要的時間 這些目標的達成有賴於成功的建立一個基礎架構，以促成並鼓勵所有同仁，提出組織流程和技術的可能改善措施。這些目標的達成也有賴於有效地評估與推展所建議的改善措施。所有同仁都能參與流程 組織創新與推展(OID) 218
CMMI for Development Version 和技術的改善活動，而且有系統的蒐集和處理同仁的建議。 在廣泛推展之前，具重大變革之未經實驗、高風險或創新的改善建議，應進行試行以評估其影響。 自流程和技術的改善建議中挑選改善措施，以推展至整個組織的準則如下所列： • 對組織現行品質和流程績效的量化瞭解 • 組織的品質和流程績效目標 • 推展流程和技術改善後，品質和流程績效改善的預估值 • 推展流程和技術改善的預估成本，以及可用於該推展的資源和資金 必須衡量流程和技術改善帶來的預期效益與其成本和對組織的衝擊，並在變更與穩定之間小心取得平衡。變更太大或太快，組織將無法承受，而且會毀壞組織的學習投資，亦即破壞組織的流程資產。而一成不變的穩定也會導致停滯不前，使不斷變動的經營環境腐蝕組織的經營地位。 對新的與進行中的專案，適當地推展改善措施。 本流程領域的「流程和技術改善」係指對流程本身，以及對流程或產品技術(包括專案工作環境)之漸進和創新的改善。 本流程領域的助益性資料的撰寫前提為特定執行方法適用量化管理流程。在不考慮此前提的情況下，本流程領域的特定執行方法也可適用，不過會降低所產生的價值。 本流程領域的特定執行方法補充並擴大組織流程專注流程領域的特定執行方法。本流程領域專注於流程改善，乃以下列兩項量化的知識為基礎進行流程改善：組織標準流程和技術，以及其在可預知情境下所期望的品質和績效。在組織流程專注流程領域中，並沒有關於改善之量化基礎的假設。 組織創新與推展(OID) 219
CMMI for Development Version 相關流程領域 有關將已推展的流程改善措施納入組織流程資產，請參考組織流程定義流程領域，以獲得更多資訊。 有關流程改善建議的徵求、蒐集及處理，以及協調將流程改善的推展納入專案已調適流程，請參考組織流程專注流程領域，以獲得更多資訊。 有關提供最新訓練以支援流程和技術改善的推展，請參考組織訓練流程領域，以獲得更多資訊。 有關品質和流程績效目標，以及流程績效模式，請參考組織流程績效流程領域，以獲得更多資訊。品質和流程績效目標用以分析和選擇所要推展的流程和技術改善建議。流程績效模式則用以量化創新所帶來的衝擊和效益。 有關建立度量與分析的目標、界定待執行的度量與分析、取得和分析度量資料，以及報告結果等，請參考度量與分析流程領域，以獲得更多資訊。 有關協調將流程和技術改善之推展納入專案已調適流程和專案工作環境，請參考整合的專案管理流程領域，以獲得更多資訊。 有關改善建議和創新的正式評估，請參考決策分析與解決方案流程領域，以獲得更多資訊。 組織創新與推展(OID) 220
CMMI for Development Version 特定目標及執行方法摘要 SG 1選擇改善措施 SP 蒐集並分析改善建議 SP 界定並分析創新 SP 試行改善措施 SP 選擇改善措施以便推展 SG 2推展改善措施 SP 規劃推展計畫 SP 管理推展工作 SP 度量改善效果 各目標的特定執行方法 SG 1 選擇改善措施 選擇有助於符合品質與流程績效目標的各種流程與技術改善措施。 SP 蒐集並分析改善建議 蒐集並分析流程與技術的改善建議。 必須分析每個流程和技術的改善建議。 通常不需要詳細評估容易瞭解其效益及影響的簡單流程和技術改善措施。 簡單的流程和技術改善措施，舉例如下： • 增加一個項目至同仁審查檢查表。 • 將對供應商所進行的技術和管理兩項審查，合併為單一的技術／管理審查。 典型的工作產品 1. 已分析的流程和技術改善建議 組織創新與推展(OID) 221
CMMI for Development Version 細部執行方法 1. 蒐集流程和技術的改善建議。 流程和技術改善建議記錄對特定流程和技術之漸進和創新的改善建議。組織中的管理者和成員，以及客戶、最終使用者及供應商，都能提出流程和技術改善建議。在提議到整個組織實施之前，流程和技術改善措施應先局部實施。 流程和技術改善建議的來源，舉例如下： • 流程評鑑的調查結果和建議 • 組織品質和流程績效的目標 • 客戶和最終使用者的問題，以及客戶及最終使用者滿意度的資料分析 • 專案績效與品質和生產力目標比較的資料分析 • 技術績效度量的分析 • 流程和產品標竿學習工作的結果 • 缺失原因的資料分析 • 流程活動的度量成效 • 專案工作環境的度量成效 • 流程和技術改善建議於其他地方成功採用的範例 • 先前提出之流程和技術改善建議的回饋 • 專案經理和成員自發的構想 有關流程和技術改善，請參考組織流程專注流程領域，以獲得更多資訊。 2. 適當地分析流程和技術改善建議的成本和效益。 如果流程和技術改善建議的本益比太高，應予排除。 評估成本和效益的準則如下： 組織創新與推展(OID) 222
CMMI for Development Version • 滿足組織品質和流程績效目標的貢獻程度 • 對減輕已界定之專案和組織風險的影響 • 對專案需求、市場狀況及經營環境等變更的快速反應能力 • 對相關流程和資產的影響 • 蒐集和定義資料的成本，該資料用以支援流程和技術改善建議之度量與分析 • 改善建議的預期期限 不能改善組織流程的流程和技術改善建議，應予排除。 流程績效模式可以洞察流程變更在流程能力和績效上的影響。 有關流程績效模式，請參考組織流程績效流程領域，以獲得更多資訊。 3. 界定具創新的流程和技術改善建議。 「界定並分析創新」特定執行方法也界定並分析創新的改善。 「界定並分析創新」特定執行方法用以主動尋求和找出創新改善，而本特定執行方法用於分析被動蒐集的建議。「界定及分析創新」特定執行方法的「尋求」主要是從組織外找尋。 創新改善的界定通常藉由審查流程和技術改善建議，或積極調查和追蹤其他機構所使用或研究文獻所記載的創新著手。創新可能由內部的改善目標或外在經營環境所激發。 創新的改善通常是流程的重要變更，它代表自舊有做事方法的一種脫離，例如生命週期方法論的變更。創新的改善也可能包括支援流程、加強流程，或使流程自動化之產品的變更。例如：使用現成品以支援流程。 組織創新與推展(OID) 223
CMMI for Development Version 創新改善，舉例如下： • 先進的電腦和相關硬體產品 • 新的支援工具 • 新的技術、方法、流程或生命週期模式 • 新的介面標準 • 新的再用元件 • 新的管理技術 • 新的品質改善技術 • 新的流程發展和推展支援工具 4. 界定推展流程和技術改善建議的潛在障礙和風險。 推展流程和技術改善的障礙，舉例如下： • 本位主義和狹窄的眼光 • 不清楚或不堅定的經營理念 • 缺少短期效益和可見的成功 • 對每個人的期望不清楚 • 同一時間有太多的變更 • 缺少相關的關鍵人員的參與和支援 組織創新與推展(OID) 224
CMMI for Development Version 影響流程和技術改善推展的風險因素，舉例如下： • 改善措施與現有流程、價值觀及潛在最終使用者技能的相容程度 • 改善的複雜度 • 實施改善的困難度 • 在全面推展前，展示改善價值的能力 • 在某些方面(如工具和訓練)進行大額、前期投資的正當理由 • 因現有技術已成功地被大量成熟的最終使用者所採用，故無法克服的「技術障礙」 5. 估計推展每個備選流程和技術改善建議所需的成本、工作量及時程。 6. 在大規模推展前，先選擇一些流程和技術改善建議進行試行。 依據定義，創新通常代表重大變更，所以大部分的創新改善應先試行。 7. 記錄每個流程和技術改善建議的評估結果。 8. 監督每個流程和技術改善建議的狀況。 SP 界定並分析創新 界定並分析能增加組織之品質與流程績效的創新改善措施。 「蒐集並分析改善建議」特定執行方法係分析被動蒐集的建議，而本特定執行方法係主動尋求和找出創新改善措施，而且主要是從組織外找尋。 典型的工作產品 1. 備選的創新改善措施 2. 所建議之創新改善措施的分析 組織創新與推展(OID) 225
CMMI for Development Version 細部執行方法 1. 分析組織標準流程，以決定這些創新改善措施對哪些領域最有幫助。 執行這些分析，以決定達到組織品質和流程績效目標具關鍵性的子流程，以及可加以改善的備選子流程。 2. 調查研究可改善組織標準流程的創新改善措施。 創新改善的調查，可包括： • 有系統地留意領先的工作相關技術和技術趨勢 • 定期尋求市面上可用的創新改善措施 • 蒐集來自專案和組織的創新改善建議 • 有系統地審查外界使用的流程和技術，並與組織內部所使用的相互比較 • 界定已成功使用創新改善的領域，並審查這些改善措施的資料和經驗文件 • 界定整合新技術到產品及專案工作環境的改善措施 3. 分析具潛力的創新改善措施，以瞭解它們對流程元件的效果，並預測它們對流程的影響。 流程績效模式提供基礎，以分析流程元件變更的可能影響。 有關流程績效模式，請參考組織流程績效流程領域，以獲得更多資訊。 4. 分析具潛力之創新改善措施的成本和效益。 如果創新改善的本益比太高，應予排除。 5. 針對可導致改善組織流程或技術的創新改善措施，製作流程和技術改善建議。 6. 在大規模推展之前，應選擇創新改善措施進行試行。 組織創新與推展(OID) 226
CMMI for Development Version 依據定義，創新通常代表重大變更，所以大部分的創新改善應先試行。 7. 記錄創新改善措施的評估結果。 SP 試行改善措施 試行流程與技術改善措施，以選擇適合推展的措施。 在大規模推展之前，適當地試行創新改善，以評量新的和未經證明的重大變更。 本特定執行方法可與原因分析與解決方案流程領域的「實施行動建議書」特定執行方法重疊實施，例如：當整個組織或跨多個專案實施原因分析與解決方案的時候。 典型的工作產品 1. 試行的評估報告 2. 試行的學習心得 細部執行方法 1. 規劃試行計畫。 在規劃試行計畫時，定義用以評估試行結果的量化準則是重要的。 2. 審查試行計畫，並取得相關關鍵人員的同意。 3. 提供諮詢和協助予執行試行計畫的人員。 4. 在具有大規模推展性的環境下，執行每個試行計畫。 5. 按照計畫，追蹤試行的情況。 6. 審查並記錄試行的結果。 試行結果是使用在進行試行規劃時，所定義的量化準則加以評估。審查並記錄試行的結果，通常包括： 組織創新與推展(OID) 227
CMMI for Development Version • 決定是否結束試行、重新規劃並繼續試行，或進行流程和技術改善的推展 • 更新配合試行之流程和技術改善建議的安排 • 適當的界定並記錄新的流程和技術改善建議 • 界定並記錄在試行時所遇到的問題和學習心得 SP 選擇改善措施以便推展 選擇流程與技術的改善措施，以便在組織內推展。 推動整個組織的流程和技術改善措施，其選擇方式是以可量化的準則為基礎，而該準則是由組織的品質和流程績效目標衍生而來。 典型的工作產品 1. 已選定用以推展之流程和技術的改善措施 細部執行方法 1. 排定流程和技術改善措施的推展優先順序。 優先順序是以預估本益比的評估為基礎，該本益比與品質和流程績效目標有關。 有關品質和流程績效目標，請參考組織流程績效流程領域，以獲得更多資訊。 2. 選擇要在組織內推展的流程和技術改善措施。 流程改善措施的評選係以其優先順序和可用資源為基礎。 3. 決定如何推展每個流程和技術改善措施。 組織創新與推展(OID) 228
CMMI for Development Version 何處可以推展流程和技術改善措施，舉例如下： • 組織流程資產 • 組織的產品系列 • 組織的能力 • 組織的專案 • 組織的團隊 4. 記錄評選過程的結果。 評選過程的結果，通常包括： • 評選候選改善措施的準則 • 每個改善建議的處理方式 • 每個改善建議之處理方式的理由 • 每個選定的改善措施將變更的資產 SG 2 推展改善措施 針對組織的流程與技術，持續及有系統地推展各種可度量的改善措施。 SP 規劃推展計畫 針對已選定的流程與技術改善措施，建立並維護推展計畫。 每個流程和技術改善的推展計畫，可包含在組織創新和推展計畫中，也可以個別文件記載。 本特定執行方法的實施，補足了組織流程專注流程領域中，推展組織流程資產的特定執行方法，並加入量化資料的使用，來指導推展，與決定有關品質及流程績效目標的改善價值。 有關推展組織流程資產，請參考組織流程專注流程領域，以獲得更多資訊。 組織創新與推展(OID) 229
CMMI for Development Version 本特定執行方法規劃個別流程和技術改善的推展。而「規劃流程」一般執行方法則注重廣泛的規劃活動，它涵蓋本流程領域的特定執行方法。 典型的工作產品 1. 已選定之流程和技術改善措施的推展計畫 細部執行方法 1. 決定如何調整每個流程和技術改善措施，以便在整個組織內推展。 在有限範圍(如單一專案)內的流程和技術改善，如果要適用於全組織，或許須進行一些修正。 2. 決定必要的變更，以便推展每個流程和技術改善措施。 推展流程和技術改善措施，須進行的變更，舉例如下： • 流程說明、標準及程序 • 工作環境 • 教育訓練 • 技能 • 現有承諾 • 現有活動 • 對最終使用者的持續支援 • 組織文化和特色 3. 界定各種策略，以便克服每個流程和技術改善措施推展時的潛在障礙。 4. 建立度量和目標，以決定每個流程和技術改善措施相對於組織經營目標的價值。 組織創新與推展(OID) 230
CMMI for Development Version 決定流程和技術改善價值的度量，舉例如下： • 投資報酬 • 流程或技術改善的成本回收所需時間 • 專案或組織流程績效的已度量改善 • 藉由流程和技術改善，減輕之專案和組織風險的數目和類型 • 對專案需求、市場狀況及經營環境的變更快速反應的能力 有關建立度量與分析的目標、界定待執行的度量與分析、取得和分析度量資料，以及報告結果等，請參考度量與分析流程領域，以獲得更多資訊。 5. 記錄每個流程和技術改善措施的推展計畫。 6. 審查每個流程和技術改善措施的推展計畫，並取得關鍵人員的同意。 7. 必要時，修訂每個流程和技術改善措施的推展計畫。 SP 管理推展工作 針對已選定的流程與技術改善措施，管理其推展情況。 本特定執行方法可與原因分析與解決方案流程領域的「實施行動建議書」特定執行方法重疊實施，例如：當整個組織或跨多個專案實施原因分析與解決方案的時候。主要差異在於原因分析與解決方案流程領域的規劃，是用於管理如何移除專案已調適流程之缺失或問題的根本原因，而組織創新與推展流程領域的規劃，是用於管理如何推展符合組織經營目標之組織流程和技術的改善措施。 組織創新與推展(OID) 231
CMMI for Development Version 典型的工作產品 1. 最新的訓練教材(以反映已推展的流程和技術改善措施) 2. 流程和技術改善措施推展活動的紀錄 3. 已修訂的流程和技術改善措施之度量、目標、優先順序及推展計畫 細部執行方法 1. 使用推展計畫，監督流程和技術改善措施的推展情形。 2. 協調組織內流程和技術改善措施的推展活動。 推展的協調活動，包括： • 協調每個流程和技術改善之專案、支援小組及組織中各小組的活動。 • 協調相關之流程和技術改善的各項推展活動。 3. 以受管制、有紀律的適當方式，快速推展流程和技術改善措施。 快速推展流程和技術改善措施的方法，舉例如下： • 使用劃紅線、流程變更通告，或其他納管流程的文件，作為暫時的流程說明 • 漸進地推展流程和技術改善措施，而非一步完成 • 對流程和技術改善措施的早期採用者，提供廣泛的顧問諮詢，以代替已修訂的正式訓練 4. 適當地把流程和技術改善措施整合至組織流程資產。 有關組織流程資產，請參考組織流程定義流程領域，以獲得更多資訊。 組織創新與推展(OID) 232
CMMI for Development Version 5. 將流程和技術改善措施的推展，適當地融入專案已調適流程。 有關推展組織流程資產，請參考組織流程專注流程領域，以獲得更多資訊。 6. 提供適當的諮詢服務，以支援流程和技術改善措施的推展。 7. 提供最新的訓練教材，以反映組織流程資產的改善。 有關訓練教材，請參考組織訓練流程領域，以獲得更多資訊。 8. 確認所有流程和技術改善措施的推展皆已完成。 9. 決定已調適流程滿足品質和流程績效目標的能力，是否受到流程和技術改善措施的負面影響。必要時，採取矯正措施。 有關量化管理專案已調適流程以達成專案所設定的品質和流程績效目標，請參考量化專案管理流程領域，以獲得更多資訊。 10. 記錄並審查流程和技術改善措施推展的結果。 記錄並審查結果，包括： • 界定並記錄學習心得 • 界定並記錄新流程和技術的改善建議 • 修訂流程和技術改善的度量、目標、優先順序及推展計畫 SP 度量改善效果 針對已推展的流程與技術改善措施，度量其效果。 有關建立度量與分析的目標、界定待執行的度量與分析、取得和分析度量資料，以及報告結果等，請參考度量與分析流程領域，以獲得更多資訊。 本特定執行方法可與原因分析與解決方案流程領域的「評估變更的效果」特定執行方法重疊實施，例組織創新與推展(OID) 233
CMMI for Development Version 如：當整個組織或跨多個專案實施原因分析與解決方案的時候。 典型的工作產品 1. 推展流程和技術改善效果度量的紀錄 細部執行方法 1. 度量推展每個流程和技術改善措施所需的成本、工作量及時程。 2. 度量每個流程和技術改善措施的價值。 3. 度量改善措施在達成組織品質和流程績效目標的進度。 4. 分析改善措施在達成組織品質和流程績效目標的進度。必要時，採行矯正措施。 有關流程績效分析，請參考組織流程績效流程領域，以獲得更多資訊。 5. 儲存度量結果於組織度量儲存庫中。 組織創新與推展(OID) 234
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施組織創新與推展流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 僅適用於階段式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維謢組織政策，以規劃和執行組織創新與推展流程。 詳細說明： 本政策建立組織對下列活動的期望：界定及推展流程和技術改善措施，以有助於滿足品質和流程績效目標。 組織創新與推展(OID) 235
CMMI for Development Version GP 規劃流程 建立並維謢執行組織創新與推展流程的計畫。 詳細說明： 本計畫用於執行組織創新與推展，不同於本流程領域的特定執行方法所描述的推展計畫。一般執行方法所謂的計畫，乃在說明本流程領域特定執行方法的廣泛規劃，從蒐集和分析改善建議，一直到改善影響的度量。而特定執行方法的推展計畫則強調推展個別流程和技術改善建議時所需的規劃。 GP 提供資源 提供充足的資源，以執行組織創新與推展流程、發展工作產品及提供流程服務。 詳細說明： 提供的資源，舉例如下： • 模擬套裝軟體 • 雛型工具 • 統計套裝軟體 • 動態系統模型 • 訂閱線上技術資料庫及發行刊物 • 流程模型工具 GP 指派責任 指派組織創新與推展流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援組織創新與推展流程。 組織創新與推展(OID) 236
CMMI for Development Version 詳細說明： 訓練主題，舉例如下: • 規劃、設計及進行試行 • 成本/效益分析 • 技術移轉 • 變更管理 GP 管理建構 將指定的組織創新與推展流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 試行的學習心得紀錄 • 已修訂之流程和技術改善的度量、目標、優先順序及推展計畫 • 最新的訓練教材 GP 界定並納入相關的關鍵人員 依計畫界定並納入組織創新與推展流程相關的關鍵人員。 詳細說明： 關鍵人員參與的活動，舉例如下： • 審查流程和技術的改善建議，該建議對流程績效或客戶和最終使用者滿意度可能有重大影響。 • 提供組織有關流程和技術改善推展活動的結果和狀態的回饋。 回饋通常包括： 組織創新與推展(OID) 237
CMMI for Development Version • 通知提出流程和技術改善建議的人，有關對其建議的處理方式。 • 定時通知關鍵人員有關選擇與推展流程和技術改善的計畫和狀態。 • 準備並分發流程和技術改善之選擇與推展活動的摘要。 GP 監控流程 依本流程的執行計畫，監控組織創新與推展流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量，舉例如下: • 品質的變更 • 流程績效的變更 • 推展已選定改善措施活動的時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估組織創新與推展流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 選擇改善措施 • 推展改善措施 組織創新與推展(OID) 238
CMMI for Development Version 審查的工作產品，舉例如下： • 推展計畫 • 已修訂之流程和技術改善的度量、目標、優先順序及推展計畫 • 最新的訓練教材 GP 與上層管理人員審查各狀況 與上層管理人員審查組織創新與推展流程的活動、狀況及結果，並解決問題。 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義組織創新與推展流程的說明。 GP 蒐集改善資訊 蒐集由規劃並執行組織創新與推展流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 組織創新與推展(OID) 239
CMMI for Development Version 詳細說明： 工作產品、度量、度量結果及改善資訊，舉例如下： • 從相關關鍵人員的經驗分享，界定來自於先前技術植入推行時的阻礙 • 因推展創新所記錄的成本與效益度量 • 相似發展流程的比較報告，用以界定改善效率的可能性。 組織創新與推展(OID) 240
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護組織創新與推展流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定組織創新與推展流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保組織創新與推展流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正組織創新與推展流程之缺失與其他問題的根本原因。 組織創新與推展(OID) 241
CMMI for Development Version 組織流程定義+ IPPD 成熟度第三級的流程管理類流程領域 目的 組織流程定義的目的是建立並維護可用的組織流程資產與工作環境標準。 IPPD補充 適用於IPPD，組織流程定義+IPPD也包含組織規則與指引的建立，以能使用整合團隊執行工作。 簡介 組織流程資產使整個組織有一致的流程績效，並且提供組織一累積性、長期性效益的基礎。(「組織流程資產」的定義在詞彙中) 組織流程資產館是蒐集資料項目的地方，並由組織維護，以提供組織人員及專案使用。組織流程資產館蒐集的資料項目包括：流程與流程元件的說明、生命週期模式的說明、流程調適指引、流程相關的文件及資料。組織流程資產館允許全組織共享最佳執行方法與學習心得，以支援組織學習與流程改善。 專案引用組織標準流程，將其調適成專案定義的流程。而其他組織流程資產可用來支援調適或建置已定義流程。工作環境的標準是用來建立專案工作環境。 標準流程由其他流程或流程元件所組成。流程元件是流程定義的基本單位(例如：原子)，它說明一致性執行工作的活動與工作項目。流程架構提供在標準流程中連接流程元件的規則。組織標準流程可包含多個流程架構。 組織流程定義(OPD)+IPPD 242
CMMI for Development Version 「標準流程」、「流程架構」與「流程元件」的定義，請參見詞彙。 依組織流程定義流程領域的建置，組織流程資產可以多種方式組織起來。舉例如下： • 生命週期模式的說明，可以成為組織標準流程的一部分文件，或是獨立成另一文件。 • 組織標準流程可以儲存在組織流程資產館，或是單獨儲存。 • 可用單一儲存庫儲存度量及流程相關文件，或是二者分開儲存。 相關流程領域 有關組織流程相關的事項，請參考組織流程專注流程領域，以獲得更多的資訊。 組織流程定義(OPD)+IPPD 243
CMMI for Development Version 特定目標及執行方法摘要 SG 1建立組織流程資產 SP 建立標準流程 SP 建立生命週期模式說明 SP 建立調適準則及指引 SP 建立組織度量儲存庫 SP 建立組織流程資產館 SP 建立工作環境標準 IPPD補充 SG 2促成IPPD管理 SP 建立授權機制 SP 建立整合團隊規則與指引 SP 平衡團隊與原隸屬組織的責任各目標的特定執行方法 SG 1 建立組織流程資產 建立並維護組織流程資產。 IPPD 補充 整合的流程強調同步而不是循序列的發展，它是執行IPPD的基石。產品發展流程及產品相關的生命週期流程(如製造流程發展與支援流程發展的流程)同步執行。整合的流程應該包含代表產品生命週期各階段經營與技術功能的關鍵人員所提供的資訊，也需要有效的團隊工作流程。 SP 建立標準流程 建立並維護組織標準流程。 組織流程定義(OPD)+IPPD 244
CMMI for Development Version 在企業中，標準流程可定義成多個層次，並且能以架構性層次互相關聯。例如：一個企業的標準流程，可由個別組織(例如：部門或地點)進行調適，以建立自己的標準流程。標準流程可按各個組織經營領域或產品線調適而得。因此組織標準流程可以參照在組織層次所建立的標準流程，以及在組織較低層次所建立的標準流程。某些組織可能只有單一層次的標準流程。(「標準流程」與「組織的一組標準流程」的定義，請參見詞彙。) 多個標準流程可能同時存在，以滿足不同的應用領域、生命週期模式、方法及工具的需要。流程架構描述流程元件之間的關聯，組織標準流程包含流程元件(例如：估算工作產品規模大小的元件)，而這些元件在一個或多個流程架構中互相關聯。流程可能由一些流程或流程元件組成。 組織標準流程通常包括技術、管理、行政、支援及組織的流程。 IPPD補充 在IPPD環境，組織的一組標準流程包括專案用來建立共同願景的流程。 組織標準流程應涵蓋組織與專案所需的全部流程，包括成熟度第2級的流程領域。 典型的工作產品 1. 組織標準流程 細部執行方法 1. 分解個別的標準流程為構成的流程元件，使詳細到足以瞭解並說明流程。 每個流程元件包含一組緊密相關的活動。流程元件的說明可能是供填寫的樣板、供完整組合的組件、供進一步細緻化的抽象概念，或供調適或不經修改即可採用的完整說明。這些元件以充分詳組織流程定義(OPD)+IPPD 245
CMMI for Development Version 盡的方式說明，以致於流程經完整地定義後，經過適當訓練與具備技能的人員能夠一致地執行。 流程元件，舉例如下： • 產生工作產品規模大小估計的樣板 • 工作產品設計方法的說明 • 可調適的同仁審查方法 • 執行管理審查的樣板 2. 界定每一流程元件的重要屬性。 重要屬性，舉例如下： • 流程的角色 • 適用的標準 • 適用的程序、方法、工具及資源 • 流程績效目標 • 允入準則 • 輸入 • 需蒐集與使用的產品與流程度量 • 驗證點(例如：同仁審查) • 輸出 • 介面 • 允出準則 3. 界定各流程元件的關聯。 組織流程定義(OPD)+IPPD 246
CMMI for Development Version 關聯，舉例如下： • 流程元件的次序 • 流程元件之間的介面 • 與外部流程的介面 • 流程元件之間的相依性 說明流程元件之間關聯的規則叫做「流程架構」，流程架構涵蓋重要的需求與指引。這些關聯的詳細規格包含於已調適流程中，而已調適流程是由組織標準流程調適而得。 4. 確保組織標準流程是遵循適用的政策、流程標準與模式，以及產品標準。 遵循適用的流程標準與模式，通常以製作組織標準流程與相關流程標準及模式的對照表來證明，而且這個對照表可作為未來評鑑時有用的輸入資料。 5. 確保組織標準流程能滿足流程需要與組織目標。 有關建立並維護組織流程的需要與目標，請參考組織流程專注流程領域，以獲得更多的資訊。 6. 確保組織標準流程中的各個流程，都能恰當地整合。 7. 記錄組織標準流程。 8. 對組織標準流程執行同仁審查。 有關同仁審查，請參考驗證流程領域，以獲得更多的資訊。 9. 必要時，修訂組織標準流程。 SP 建立生命週期模式說明 建立並維護生命週期流程模式的說明，經核准後在組織中使用。 組織流程定義(OPD)+IPPD 247
CMMI for Development Version 對於不同的客戶與不同的情況，可能發展多個生命週期模式，因為只有一個生命週期模式可能不適用於所有情況。生命週期模式常用來定義專案的階段，同時組織對每一產品與服務種類，可能定義不同的生命週期模式。 典型的工作產品 1. 生命週期模式的說明 細部執行方法 1. 根據專案與組織的需要，選擇生命週期模式。 專案的生命週期模式，舉例如下： • 瀑布式 • 螺旋式 • 演進式 • 漸進式 • 反覆式 2. 文件化生命週期模式的說明。 生命週期模式可以成為組織標準流程說明的一部分文件，或獨立成另一文件。 3. 對生命週期模式執行同仁審查。 有關執行同仁審查，請參考驗證流程領域，以獲得更多的資訊。 4. 必要時，修訂生命週期模式的說明。 SP 建立調適準則及指引 建立並維護組織標準流程的調適準則及指引。 IPPD 補充 組織流程定義(OPD)+IPPD 248
CMMI for Development Version 製作調適準則與指引時，須包含同步發展以及與整合小組運作的考量。例如：如何調適製造流程，其結果將有賴於在產品發展後再依序進行，或像在IPPD環境中，產品發展時同步進行而有所不同。以資源分配流程為例，如果專案是與整合小組運作，也會作不同的調適。 調適準則及指引說明下列事項： • 如何引用組織標準流程及組織流程資產，以產生已調適流程 • 已調適流程必須滿足必要的需求(例如：對於已調適流程非常重要的組織流程資產的子集合) • 列出可選擇的項目及選擇的準則 • 執行與記錄流程調適時必須遵循的程序 調適的原因，舉例如下： • 為新的產品線或主機環境而調適流程 • 為特定的應用或應用類別(例如：啟動發展、維護或製作雛型)而將流程客製化 • 更詳盡的流程說明，以使已調適流程能夠執行 在調適與定義流程的彈性以及確保全組織流程的適當一致性之間，須作平衡。彈性是需要的，以滿足範圍的變數，例如：專業領域，客戶特性，成本、時程及品質取捨分析，工作的技術難度，以及執行流程的人員經驗。在組織中須有一致性，以能夠適當滿足組織標準、目標及策略，並且能夠分享流程資料與學習心得。 調適準則與指引允許標準流程就是已調適流程，不需要調適。 典型的工作產品 1. 組織標準流程的調適指引 組織流程定義(OPD)+IPPD 249
CMMI for Development Version 細部執行方法 1. 界定用以調適組織標準流程的選擇準則及程序。 準則與程序，舉例如下： • 由組織核准的生命週期模式中進行選擇的準則 • 由組織標準流程中選擇流程元件的準則 • 為了適合特定流程的特性與需求，調適選定的生命週期模式與流程元件的程序 調適行動，舉例如下： • 修改生命週期模式 • 組合不同生命週期模式的元件 • 修改流程元件 • 替換流程元件 • 重新排列流程元件的順序 2. 界定文件化已調適流程的標準。 3. 針對組織標準流程的需求，界定用以提出及取得豁免權核准的程序。 4. 文件化組織標準流程的調適指引。 5. 對調適指引執行同仁審查。 有關執行同仁審查，請參考驗證流程領域，以獲得更多的資訊。 6. 必要時，修訂調適指引。 SP 建立組織度量儲存庫 建立並維護組織度量儲存庫。 有關使用組織度量儲存庫於規劃專案活動，請參考整合的專案管理流程領域的「使用組織流程資產規劃專案活動」特定執行方法，以獲得更多資訊。 組織流程定義(OPD)+IPPD 250
CMMI for Development Version 儲存庫包含與組織標準流程相關的產品度量與流程度量。儲存庫也包含或引用瞭解與解釋度量，並評量其合理性與適用性所需的資訊。例如：引用度量的定義以比較不同流程的相同度量。 典型的工作產品 1. 組織標準流程的共通產品與流程度量的定義 2. 組織度量儲存庫的設計 3. 組織度量儲存庫(即儲存庫結構及支援環境) 4. 組織度量資料 細部執行方法 1. 決定組織儲存、取用及分析度量的需要。 2. 定義組織標準流程中產品及流程的共通度量。 共通度量是根據組織標準流程而選出。所選定的度量是有能力提供流程績效之可視性，以支援預期的商業目標。共同共通度量可能會因不同的標準流程而不同。 度量的操作定義說明蒐集正確資料的程序及在流程中的資料蒐集點。 一般共通使用的度量類型，舉例如下： • 工作產品規模大小(例如：頁數)的估計值 • 工作量及成本(例如：人時)的估計值 • 規模大小、工作量及成本的實際度量 • 品質度量(例如：發現的錯誤數量、錯誤的嚴重程度) • 同仁審查的涵蓋度 • 測試涵蓋範圍 • 可靠性度量(例如：平均故障次數) 組織流程定義(OPD)+IPPD 251
CMMI for Development Version 有關定義度量，請參考度量與分析流程領域，以獲得更多的資訊。 3. 設計及建置度量儲存庫。 4. 界定儲存、更新及取用度量的程序。 5. 對於共通度量的定義，以及儲存與取用度量的程序，執行同仁審查。 有關執行同仁審查，請參考驗證流程領域，以獲得更多的資訊。 6. 將指定的度量放入儲存庫。 有關蒐集與分析資料，請參考度量與分析流程領域，以獲得更多的資訊。 7. 使流程度量儲存庫的內容，能夠讓組織及專案恰當地使用。 8. 當組織需求變更時，修訂度量儲存庫、共通度量及程序。 共通度量需要修訂的時機，舉列如下： • 新增流程 • 修訂流程及需要新流程度量 • 需要更細節的資料 • 需要更具清晰度的流程 • 需要淘汰的度量 SP 建立組織流程資產館 建立並維護組織流程資產館。 組織流程定義(OPD)+IPPD 252
CMMI for Development Version 儲存在組織流程資產館的資料項目，舉例如下： • 組織政策 • 已調適流程的說明 • 程序(例如：估計程序) • 發展計畫 • 採購計畫 • 品質保證計畫 • 訓練教材 • 流程的輔助工具(例如：檢查清單) • 學習心得報告 典型的工作產品 1. 組織流程資產館的設計 2. 組織流程資產館 3. 已選定將要放入組織流程資產館的資料項目 4. 組織流程資產館資料項目的目錄 細部執行方法 1. 設計並建置組織流程資產館，包括組織流程資產館的結構及支援環境。 2. 界定資料項目納入組織流程資產館的準則。 納入的資料項目主要依據它們與組織標準流程的關聯性。 3. 界定儲存與取用資料項目的程序。 4. 將已選擇的資料項目納入組織流程資產館中，並編入目錄，使之容易參考及取用。 5. 使資料項目可供各專案使用。 組織流程定義(OPD)+IPPD 253
CMMI for Development Version 6. 定期審查個別資料項目的使用情況，並引用其結果以維護資產館的內容。 7. 必要時，修訂組織流程資產館。 需要修訂組織流程資產館的時機，舉列如下： • 新增資料項目 • 淘汰資料項目 • 變更現有資料項目版本 SP 建立工作環境標準 建立及維護工作環境標準。 工作環境標準容許組織及專案，從共用的工具、訓練及維護中獲益，同時從大量採購中節省成本。工作環境標準描述所有相關關鍵人員的需要，並考量生產力、成本、可用性、保全性及工作地點健全、安全性，以及人因工程因素。工作環境標準包括調適與/或使用豁免的指引，能讓工作環境標準適應並符合特定需要。 工作環境標準，舉例包括： • 工作環境操作、安全及保全性的程序 • 標準工作站的硬體及軟體 • 標準應用軟體及其調適指引 • 標準生產及機器等級 • 請求及核准調適或豁免的流程 典型工作產品 1. 工作環境標準 細部執行方法 1. 評估適合組織之市售可用的工作環境標準。 2. 採行現存工作環境標準，並以組織流程需要及目標為基礎，發展新的工作環境標準來彌補差距。 組織流程定義(OPD)+IPPD 254
CMMI for Development Version 組織流程定義(OPD)+IPPD 255
CMMI for Development Version IPPD補充 SG 2 促成IPPD管理 提供組織規則及指引，來管理整合團隊的營運。 如果能成功的長期維持組織基礎建設，來支援及提倡IPPD的觀念，是具關鍵性的。這些規則及指引所提倡的觀念，例如：整合團隊，以及容許在不同的層級做授權的決策。透過其規則及指引，組織顯示對於IPPD及整合團隊成功的承諾。 IPPD規則及指引成為組織標準流程及專案已調適流程的一部分。組織標準流程有能力提倡及加強來自於專案、整合團隊及人員所期望的行為。這些期望行為以政策、操作程序、指引，和其他組織流程資產做為典型的溝通形式。 SP 建立授權機制 建立及維護授權機制，能夠及時做決策 在成功的IPPD環境，必須建立責任及授權的透明管道。當整合團隊承擔授權太多或太少，與決策者不明確時，組織任何層級都可以提出議題。文件化與推展清楚定義整合團隊的授權的組織指引，都可避免這些議題。 當授權給人員或整合團隊，且決策降至較低的適當層級，IPPD的實施引發領導階層的挑戰，因為需要文化改變。 有效果及有效率的溝通機制，在整合工作環境中，對於及時和明智的決策是關鍵的。一旦建立了整合團隊專案架構及提供訓練，也必須提供處理授權、進行決策，和議題解決的機制。 有關進行決策，請參照決策分析及解決方案流程領域，以獲得更多資訊。 典型工作產品 1. 針對人員及整合團隊的授權規則及指引 組織流程定義(OPD)+IPPD 256
CMMI for Development Version IPPD補充 2. 決策制定的規則及指引 3. 議題解決的文件 細部執行方法 1. 決定授權給人員或整合團隊不同等級的規則及指引。 整合團隊授權應考慮的因素，包括下列： • 授權團隊選擇自己的領導者 • 授權團隊建置子團隊（例如：產品團隊組成整合子團隊） • 集合做決策的等級 • 整合團隊決策所需的共識等級 • 整合團隊內，不同衝突及意見如何陳述及解決 2. 決定不同決策型態所使用的規則及指引，以做出不同種類的團隊決策。 3. 定義使用決策制定規則及指引的流程。 4. 定義當議題發生時無法在該等級做決定的議題解決方案流程。 有關與相關關鍵人員解決議題，請參照整合專案管理流程領域中，解決協調議題特定執行方法，以獲得更多資訊。 5. 維護授權機制及決策的規則及指引。 SP 建立整合團隊的規則及指引 建立及維護組織規則及指引，以架構及組成整合團隊。 整合團隊的運作規則及指引可用以定義及控制團隊如何相互影響以完成目標。這些規則及指引也提倡有效整合團隊的工作量、高績效，及生產力。整合團隊成組織流程定義(OPD)+IPPD 257
CMMI for Development Version IPPD補充 員必須了解工作的標準，並根據這些標準來參與。 典型工作產品 1. 架構及組成整合團隊的規則及指引 細部執行方法 1. 建立架構及組成整合團隊的規則及指引。 組織流程資產能幫助專案來架構及執行整合團隊。這樣的資產包括如下： • 團隊架構指引 • 團隊組成指引 • 團隊授權及責任指引 • IPPD執行技術 • IPPD管理風險指引 • 建立溝通及授權的指引 • 團隊領導者選擇情境 • 團隊責任指引 2. 定義期望、規則及指引，引導整合團隊如何共同的工作。 這些規則及指引，建立了跨整合團隊的組織執行方法之一致性。 • 整合團隊間的介面，如何建立與維護 • 如何接受指派 • 如何使用資源及輸入 • 如何完成工作 • 誰來檢查、審查及核准工作 • 如何核准工作 • 如何交付及溝通工作 組織流程定義(OPD)+IPPD 258
CMMI for Development Version IPPD補充 • 報告鏈 • 報告需求（成本、時程及績效狀態）、度量及方法 • 進度報告的度量及方法 3. 維護架構及組成整合團隊的規則及指引。 SP 平衡團隊及原隸屬組織的責任 建立及維護組織指引，以幫助團隊成員平衡團隊及隸屬組織責任。 隸屬組織是組織的一部分，當團隊成員不屬於整合團隊，就可被指派。隸屬組織也可稱為功能組織、隸屬基礎、隸屬辦公室，或直接組織。隸屬組織通常負責其成員的職涯成長（例如：績效評估，及訓練以維護功能性與領域的專門知識）。 在IPPD環境中，報告程序及職等系統都認為成員的責任應專注於整合團隊，而非隸屬組織。然而，整合團隊成員的責任對於隸屬組織也是重要的，特別對於流程的執行與改善。應平衡專案、功能，和職涯成長及進階間的工作量與責任。協調工作量以符合在團隊環境的經營目標的同時，組織機制應支援隸屬組織。 有時團隊堅持跳脫在組織的生產生活，在整合團隊解散後，並無隸屬組織，讓團隊成員回去。因此，必須有解散整合團隊的指引，並維持隸屬組織。 典型工作產品 1. 平衡團隊及隸屬組織責任的組織指引 2. 績效審查流程，同樣考慮到功能監督人員及團隊領導者的輸入 細部執行方法 1. 建立隸屬組織責任的指引，以提倡整合團隊行為。 2. 建立團隊管理責任，以確保整合團隊成員可適當地組織流程定義(OPD)+IPPD 259
CMMI for Development Version IPPD補充 報告給其隸屬組織。 3. 建立績效審查流程，以考慮從隸屬組織及整合團隊領導者的輸入。 4. 維護平衡團隊及隸屬組織責任的指引。 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施組織流程定義流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 僅適用於階段式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置 GP 建立組織政策 建立並維護組織政策，以規劃和執行組織流程定義流程。 組織流程定義(OPD)+IPPD 260
CMMI for Development Version 詳細說明： 政策為建立組織的期望，以建立並維護標準流程可供組織使用，並且使組織流程資產能夠在全組織中使用。 GP 規劃流程 建立並維護執行組織流程定義流程的計畫。 詳細說明： 本執行組織流程定義流程計畫是組織流程改善計畫的一部分(或參照)。 GP 提供資源 提供充足的資源，以執行組織流程定義流程、發展工作產品及提供流程服務。 詳細說明： 流程組通常管理組織流程定義活動，且通常由專業人員所組成，主要責任是聯繫組織流程改善。流程組是由流程的負責人，以及在各種專業領域上有經驗的人員作支援，舉例如下： • 專案管理 • 適當的工程專業領域 • 建構管理 • 品質保證 其他提供的資源，舉例如下： • 資料庫管理系統 • 流程模式工具 • 網頁的製作及瀏覽器 組織流程定義(OPD)+IPPD 261
CMMI for Development Version GP 指派責任 指派組織流程定義流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援組織流程定義流程。 詳細說明： 訓練的主題，舉列如下： • CMMI與其他流程及流程改善參考模式 • 流程的規劃、管理及監督 • 流程模式與定義 • 發展可調適的標準流程 • 發展工作環境標準 • 人因工程學 GP 管理建構 將指定的組織流程定義流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 組織標準流程 • 生命週期模式的說明 • 組織標準流程的調適指引 • 共通性產品與流程度量的定義 • 組織度量資料 IPPD 補充 納入控制的工作產品，舉例如下： 組織流程定義(OPD)+IPPD 262
CMMI for Development Version • 人員與整合團隊的激勵規則與指引 • 議題解決的組織流程文件 GP 界定並納入相關的關鍵人員 依計畫界定並納入組織流程定義流程相關的關鍵人員。 詳細說明： 關鍵人員參與活動，舉例如下： • 審查組織標準流程 • 審查組織的生命週期模式 • 解決調適指引相關的議題 • 評量共通性流程與產品度量的定義 • 審查工作環境標準 IPPD 補充 關鍵人員參與的活動，舉例如下： • 建立與維護IPPD授權機制 • 建立與維護組織規則與整合團隊的結構與組成的指引 GP 監控流程 依本流程的執行計畫，監控組織流程定義流程，並採取適當的矯正措施。 組織流程定義(OPD)+IPPD 263
CMMI for Development Version 詳細說明： 用於監控的度量及工作產品，舉例如下： • 專案使用組織標準流程的流程架構與流程元件的百分比 • 組織標準流程的每一流程元件之缺失密度 • 由於人因問題的工作補償請求的數目 • 流程或流程變更發展的時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估組織流程定義流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 建立組織流程資產 IPPD 補充 審查的活動，舉例如下： • 決定提供給人員及整合團隊的授權等級的規則與指引 • 建立與維護議題解決流程 審查的工作產品，舉例如下： • 組織標準流程 • 生命週期模式的說明 • 組織標準流程的調適指引 • 組織度量資料 組織流程定義(OPD)+IPPD 264
CMMI for Development Version IPPD 補充 審查工作產品，舉例如下： • 人員與整合團隊的授權規則與指引 • 組織流程文件 GP 與上層管理人員審查各狀況 與上層管理人員審查組織流程定義流程的活動、狀況及結果，並解決問題。 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反應連續式表述的位置 GP 建立已定義流程 建立並維護已定義組織流程定義流程的說明。 GP 蒐集改善資訊 蒐集由規劃並執行組織流程定義流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 組織流程定義(OPD)+IPPD 265
CMMI for Development Version 詳細說明： 工作產品、度量、度量結果及改善資訊，舉例如下： • 納入組織流程資產館的學習心得 • 納入組織度量儲存庫的度量資料 • 修改組織標準流程變更改善建議單的狀況 • 無標準調適需求的紀錄 IPPD補充 工作產品、度量、度量結果及改善資訊，舉例如下： • 整合團隊輸入的績效審查狀況 組織流程定義(OPD)+IPPD 266
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護組織流程定義流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定組織流程定義流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保組織流程定義流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正組織流程定義流程之缺失與其他問題的根本原因。 組織流程定義(OPD)+IPPD 267
CMMI for Development Version 組織流程專注 成熟度第三級的流程管理類流程領域 目的 組織流程專注(Organizational Process Focus, OPF)的目的在於以充份瞭解現行組織流程及流程資產之優點與缺點為基礎，規劃、執行與推展組織流程改善。 簡介 組織流程包括組織與專案所使用的所有流程。組織流程與流程資產的可能改善由不同的來源取得，包括流程的度量、執行流程的學習心得、流程評鑑的結果、產品評估活動的結果、以其他組織流程標竿比較的結果，以及組織中其他改善構想的建議。 流程改善源於組織需要的範圍，以實現組織的目標。組織鼓勵將要執行流程的人，參與流程改善活動。協助與管理組織流程改善活動的責任(包括協調其他的參與)，通常指派給流程組。組織應提供長期的承諾及所需的資源，以支持流程組，以及確保有效與適時的推展改善。 為了保證整個組織流程改善的投入人力，有充分的管理與實行，必須要有詳細的規劃。組織流程改善規劃的成果為流程改善計畫。組織流程改善計畫說明評鑑規劃、流程行動規劃、試用規劃及推展規劃。評鑑計畫說明評鑑的時間與時程、評鑑的範圍、執行評鑑所需的資源、執行評鑑所採用的參考模式及評鑑的後勤支援等。流程行動計畫通常由評鑑的結果導出，並且以評鑑時所發現的缺點為目標，製作如何執行改善的文件。如果描述於流程行動計畫中的改善，在整個組織中推展前，決定先在小團體作測試，則會製作試用計畫。最後，推展改 組織流程專注(OPF) 268
CMMI for Development Version 善時，採用推展計畫，該計畫說明整個組織何時及如何推展改善。 組織流程資產說明、執行及改善組織流程(「組織流程資產」的定義，請參考詞彙)。 相關流程領域 有關組織流程資產，請參考組織流程定義流程領域，以獲得更多的資訊。 組織流程專注(OPF) 269
CMMI for Development Version 特定目標及執行方法摘要 SG 1決定流程改善機會 SP 建立組織流程需要 SP 評鑑組織流程 SP 界定組織流程改善 SG 2規劃與執行流程改善 SP 建立流程行動計畫 SP 執行流程行動計畫 SG 3推展組織流程資產及彙整學習心得 SP 推展組織流程資產 SP 推展標準流程 SP 監督執行 SP 彙整流程相關經驗納入組織流程資產 各目標的特定執行方法 SG 1 決定流程改善機會 定期與在需要的時候，界定組織流程的優點、缺點與改善機會。 可經由與流程標準或模式的比較，決定組織流程的優點、缺點及改善機會。流程標準或模式例如：CMMI模式或國際標準組織(ISO)的標準。流程改善應該特別選擇，以實現組織的需要。 SP 建立組織流程需要 建立並維護組織流程需要及目標的說明。 組織流程專注(OPF) 270
CMMI for Development Version IPPD補充 整合的流程強調同步而不是循序發展，它是執行 IPPD的基石。產品發展流程與產品相關的生命週期流程(如製造流程發展與支援流程發展的流程)同步執行。整合的流程需要包容代表產品生命週期各階段經營與技術功能的關鍵人員所提供的資訊，也需要有效的團隊工作流程。 IPPD 補充 有效的團隊工作流程，舉例如下： • 溝通 • 合作決策 • 議題解決 • 團隊建立 必須瞭解組織流程運作的經營範圍。組織經營的目標、需要及限制決定組織流程的需要與目標。重要的流程考慮項目通常包括：財務、技術、品質、人力資源及市場等議題。 組織流程的需要與目標，涵蓋下列各方面： • 流程特性 • 流程績效目標，例如：產品上市時間與交付項目品質 • 流程有效性 典型的工作產品 1. 組織的流程需要及目標 細部執行方法 1. 界定適用於組織流程的政策、標準及經營目標。 2. 檢查相關的流程標準及模式，以建立最佳執行方法。 組織流程專注(OPF) 271
CMMI for Development Version 3. 決定組織流程績效目標。 流程績效目標可以用定量或定性的術語表達。 有關建立度量目標，請參考度量分析流程領域，以獲得更多資訊。 流程績效目標，舉例如下： • 週期 • 缺失除去率 • 生產力 4. 定義組織流程的重要特性。 組織流程的重要特性，根據下列項目來決定： • 組織中正在使用的流程 • 組織所利用的標準 • 組織客戶通常強加的標準 流程特性，舉例如下： • 用來說明流程的詳細程度 • 使用的流程符號 • 流程的細部組成 5. 記錄組織流程的需要與目標。 6. 需要時，修訂組織流程的需要與目標。 SP 評鑑組織流程 定期與在需要的時候，評鑑組織流程，以維護對於流程優點與缺點的瞭解。 執行流程評鑑的理由，舉例如下： • 界定出應改善的流程 • 確定進度並且使流程改善的效益顯而易見 • 滿足客戶與供應商關係的需要 組織流程專注(OPF) 272
CMMI for Development Version • 鼓舞與支援 如果流程評鑑後，沒有接著執行以評鑑為基礎的行動計畫，則在流程評鑑中所獲得的同意會被嚴重的忽略。 典型的工作產品 1. 組織流程評鑑的各種計畫 2. 說明組織流程優缺點的評鑑調查報告 3. 組織流程的改善建議 細部執行方法 1. 取得高階管理人員對流程評鑑的贊助。 高階管理人員的贊助包括承諾讓組織的管理人員及職員參與流程評鑑，並且提供資源及經費以進行評鑑調查報告的分析與溝通。 2. 定義流程評鑑的範圍。 流程評鑑可在整個組織執行或在組織的一小部分執行，例如：一個專案或經營領域。 流程評鑑的範圍說明下列各項： • 評鑑所涵蓋的組織定義(例如：地點或經營領域) • 在評鑑中能代表組織的專案與支援功能的界定 • 將接受評鑑的流程 3. 決定流程評鑑的方法與準則。 流程評鑑可能以許多形式進行。組織的需要與目標會隨時間而變更，流程評鑑應滿足組織的需要及目標。例如：評鑑可依據流程模式，如CMMI模式或依據國家或國際標準，如ISO9001 [ISO 2000]。評鑑也可以用標竿比較的方式與其他組織作比較。評鑑方法可假設下列各種特性：耗費的時間及工作量、評鑑組的組成，以及調查的方法與深度。 組織流程專注(OPF) 273
CMMI for Development Version 4. 流程評鑑的規劃、時程安排及準備。 5. 執行流程評鑑。 6. 記錄與交付評鑑活動與調查報告。 SP 界定組織流程改善 界定組織流程及流程資產的改善。 典型的工作產品 1. 可能的流程改善的分析 2. 組織流程改善的界定 細部執行方法 1. 決定可能的流程改善。 可能的流程改善，可經由執行下列工作而決定： • 度量流程並分析度量結果 • 審查流程的有效性與合適性 • 檢閱調適組織標準流程所得到的學習心得 • 檢閱執行流程所得到的學習心得 • 審查組織管理者、職員及其他相關的關鍵人員提出的流程改善建議 • 向組織高層管理者及領導者請求提供對於流程改善的意見 • 檢查流程評鑑及其他流程相關審查的結果 • 檢閱其他組織改善構想的結果 2. 決定可能之流程改善的優先順序。 決定優先順序的準則如下： • 考慮執行流程改善所需的預估成本及工作量 • 針對組織改善的目標及優先順序，評鑑預期的改善 • 決定流程改善可能遭遇的障礙，並提出克服這些障礙的策略 組織流程專注(OPF) 274
CMMI for Development Version 幫助決定可能的改善，並定出執行的優先順序的技術，舉例如下： • 比較組織目前情況與最佳情況的落差分析 • 可能改善的著力點分析，用以界定流程改善可能遭遇的障礙及克服這些障礙的策略 • 因果分析，用以提供可比較之不同改善之可能效果的資訊 3. 界定並記錄將要執行的流程改善。 4. 修訂計畫中的流程改善清單，以維持其最新狀況。 SG 2 規劃與執行流程改善 規劃與執行組織流程與流程資產改善的流程活動 成功的執行改善，需要流程負責人(也就是執行流程及支援組織的人)參與流程行動規劃與執行。 SP 建立流程行動計畫 建立並維護流程行動計畫，以實行組織流程與流程資產的改善。 建立並維護流程行動計畫，通常包括下列各種角色的參與： • 管理委員會建立策略，並督導流程改善活動 • 流程組人員協助與管理流程改善活動 • 流程行動組定義並執行改善 • 流程負責人管理推展 • 流程參與人員執行流程 參與有助於在流程改善中獲得效益，並且能增進有效推展的可能性。 流程行動計畫是詳細的執行計畫。這些計畫與組織流程改善計畫不同的地方，在於它們規劃特定的改善，以處理通常於評鑑時發現的缺點。 組織流程專注(OPF) 275
CMMI for Development Version 典型的工作產品 1. 組織核准通過的流程行動計畫 細部執行方法 1. 界定策略、方法及行動，以實行已界定的流程改善。 在彙整成正規使用以前，新的、未經證明的及重大的變更需先經過試用。 2. 建立流程行動組，負責執行行動。 執行流程改善行動的團隊及人員叫做「流程行動組」，流程行動組通常包括流程的負責人及執行流程的人員。 3. 製作流程行動計畫。 流程行動計畫通常涵蓋下列項目： • 流程改善基礎架構 • 流程改善目標 • 將進行的流程改善 • 規劃及追蹤流程行動的程序 • 試用與執行流程行動的策略 • 執行流程行動的責任及授權 • 執行流程行動的資源、時程及工作指派 • 決定流程行動有效性的方法 • 流程行動計畫的風險 4. 與相關的關鍵人員審查並討論流程行動計畫。 5. 必要時，審查流程行動計畫。 SP 執行流程行動計畫 執行流程行動計畫。 典型的工作產品 1. 各個流程行動組的承諾 組織流程專注(OPF) 276
CMMI for Development Version 2. 執行流程行動計畫的狀況與結果 3. 試用計畫 細部執行方法 1. 使相關的關鍵人員可容易取得流程行動計畫。 2. 各流程行動組討論和記錄其承諾，如需要並修訂其行動計畫。 3. 依流程行動計畫追蹤進度及承諾。 4. 與流程行動組及相關的關鍵人員聯合審查流程行動的進度及結果。 5. 規劃需要的試用，以測試所選擇的流程改善。 6. 審查流程行動組的活動及工作產品。 7. 對執行流程行動計畫的議題加以界定、記錄及追蹤至結案。 8. 確保執行流程行動計畫的結果能符合組織流程改善的目標。 SG 3 推展組織流程資產及彙整學習心得 在組織中推展組織流程資產，並將流程相關經驗彙整至組織流程資產中。 此特定目標中的特定執行方法描述持續進行的活動。每一專案的生命期間，可能出現專案可從組織標準流程及其變更中獲益的新機會。標準流程及其他組織流程資產的推展，必須在組織中持續予以支援，特別對於新專案剛啟動時。 SP 推展流程資產 在組織中推展流程資產。 組織流程資產的推展，或是組織流程資產變更的推展，必須用有次序的方式執行。某些組織流程資產或流程資產的變更，對組織的某些部門可能不適用(例如：由於客戶的需求或目前執行的生命週期階組織流程專注(OPF) 277
CMMI for Development Version 段)。因此，必要時，正在執行流程或即將執行流程的人員，以及其他組織功能(例如：訓練及品質保證) 的人員參與推展，是很重要的。 有關如何組織流程資產館來支援並啟動組織流程資產的推展，請參考組織流程定義流程領域，以獲得更多的資訊。 典型的工作產品 1. 在組織中推展組織流程資產及其變更的計畫 2. 推展組織流程資產及其變更的訓練教材 3. 組織流程資產的變更記錄文件 4. 推展組織流程資產及其變更的支援材料 細部執行方法 1. 在組織中推展組織流程資產。 推展時，執行的活動通常包括下列項目： • 界定執行流程人員應採用的組織流程資產。 • 決定如何讓組織流程資產可供使用(例如：藉由網站) • 界定如何傳達組織流程資產的變更 • 界定支援組織流程資產的使用所需的資源(例如：方法與工具) • 規劃推展 • 協助使用組織流程資產的人員 • 確定能提供使用組織流程資產人員所需的訓練 有關訓練的協調，請參考組織訓練流程領域，以獲得更多的資訊。 2. 記錄組織流程資產的變更。 記錄組織流程資產變更有兩個主要目的： • 使變更能夠傳達 組織流程專注(OPF) 278
CMMI for Development Version • 瞭解組織流程資產變更與流程績效及結果的關係 3. 在組織中推展組織流程資產的變更。 推展變更時，通常包括下列各項活動： • 決定哪些變更適合執行流程的人員 • 規劃推展活動 • 安排成功轉換流程變更所需的支援 4. 提供組織流程資產使用的指引與諮詢。 SP 推展標準流程 在專案啟動時，推展組織標準流程至專案，並在每一專案生命全程中，適當的推展變更至專案。 新專案使用已證明且有效的流程，以執行關鍵的早期活動是重要的(例如：專案規劃、接受需求及取得資源)。 當對組織標準流程的變更對專案有益時，專案也應該定期更新已調適流程，以彙整最新的組織標準流程變更至專案中。定期更新幫助確保所有專案的活動，獲得其他專案學習心得的全部效益。 有關組織標準流程與調適指引，請參考組織流程定義流程領域，以獲得更多資訊。 典型的工作產品 1. 組織的專案清單及每一專案流程推展狀況(例如：現有與規劃的專案) 2. 新專案推展組織標準流程的指引 3. 已界定的專案，調適組織標準流程及執行流程的紀錄 細部執行方法 1. 界定組織內已啟動的專案。 組織流程專注(OPF) 279
CMMI for Development Version 2. 界定將從執行組織現有標準流程獲益的進行中專案。 3. 對已界定的專案，建立執行組織現有標準流程的計畫。 4. 協助專案調適組織標準流程，以符合專案需要。 有關調適組織標流程，以符合專案獨特的需要與目標，請參考整合的專案管理流程領域，以獲得更多資訊。 5. 維護已界定專案調適與執行流程的紀錄。 6. 確保流程調適產生的已調適流程，已納入流程符合度稽核計畫中。 流程符合度稽核是專案活動依據專案已調適流程的客觀評估。 7. .當組織標準流程更新時，界定哪些專案應執行變更。 前述細部執行方法說明如何推展至組織標準流程變更至已界定的專案。 SP 監督執行 對所有專案，監督組織標準流程的執行及流程資產的使用。 藉由監督執行，組織確保組織標準流程與其他流程資產，適當地推展至所有專案。監督執行也幫助組織瞭解組織流程資產的使用及在組織中何處使用。監督執行也幫助建立廣泛的內涵，以解釋與使用流程及產品度量、學習心得、以及由專案取得的改善資訊。 典型的工作產品 1. 監督專案流程的執行結果 2. 流程符合評估的狀況與結果 組織流程專注(OPF) 280
CMMI for Development Version 3. 審查選定的流程成果(流程調適與執行的部份產出)的結果 細部執行方法 1. 監督專案使用組織流程資產及其變更。 2. 審查選定的流程結果(每一專案生命期間的產出)。 審查選定的流程結果(每一專案生命期間的產出)，確保所有專案適當的使用組織標準流程。 3. .審查流程符合評估的結果，以決定組織標準流程推展的良窳。 有關依據適用的流程說明、標準及程序以客觀的評估流程，請參考流程與產品品質保證流程領域以獲得更多資訊。 4. 界定、記錄與追蹤有關執行組織標準流程的議題至結案。 SP 彙整流程相關經驗至組織流程資產 納入流程相關的工作產品、度量及導自規劃與執行流程的改善資訊，至組織流程資產。 典型的工作產品 1. 流程改善建議 2. 流程學習心得 3. 組織流程資產的度量值 4. 組織流程資產的改善建議 5. 組織流程改善活動的紀錄 6. 組織流程資產及其改善的資訊 細部執行方法 1. 定期審查組織標準流程及相關的組織流程資產相對於組織經營目標的有效性及適用性。 組織流程專注(OPF) 281
CMMI for Development Version 2. 取得使用組織流程資產的回饋意見。 3. 導出來自於定義、試用、執行及推展組織流程資產的學習心得。 4. 使組織中的人員能夠適當地取得有用的學習心得。 為了保證能適當地使用學習心得，可能必須採取一些行動。 不適當的使用學習心得，舉例如下： • 評估人員績效 • 判斷流程績效或結果 避免不適當的使用學習心得的方法，舉例如下： • 控制學習心得的取得 • 教育人員如何適當地使用學習心得 5. 分析組織的共通度量。 有關分析度量，請參考度量與分析流程領域，以獲得更多的資訊。 有關建立組織度量儲存庫，包括共通度量，請參考組織流程定義流程領域，以獲得更多的資訊。 6. 評鑑在組織中使用的流程、方法及工具，並發展用來改善組織流程資產的建議。 評鑑通常包括下列各項： • 決定哪些流程、方法及工具，可能用在組織的其他的部門 • 評鑑組織流程資產的品質與有效性 • 界定組織流程資產的可能改善 • 決定組織標準流程及調適指引的符合程度 組織流程專注(OPF) 282
CMMI for Development Version 7. 使組織中的人員適當地充分運用組織的流程、方法及工具。 8. 管理流程改善建議。 流程改善建議能夠說明流程與技術改善兩者。 管理流程改善建議的活動，通常包括下列各項： • 徵求流程改善建議 • 收集流程改善建議 • 審查流程改善建議 • 選擇要執行的流程改善建議 • 追蹤流程改善建議的執行 流程改善建議，應適當地以流程變更要求或問題報告方式做成文件。 有些流程改善建議可彙整納入組織流程行動計畫。 9. 建立並維護組織流程改善活動的紀錄。 組織流程專注(OPF) 283
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施組織流程專注流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 僅適用於階段式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標在此出現反映其在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行組織流程專注流程。 詳細說明： 本政策建立組織的期望，以決定流程使用的流程改善機會，並在組織中規劃與執行流程改善的活動。 GP 規劃流程 建立並維護執行組織流程專注流程的計畫。 組織流程專注(OPF) 284
CMMI for Development Version 詳細說明： 執行組織流程專注的計畫通常叫做「流程改善計畫」。這個流程改善計畫與本流程領域中特定執行方法說明的流程行動計畫不相同。在此一般執行方法的計畫為此流程領域中所有執行方法的廣泛規劃，從組織流程需要的建立到彙整流程相關經驗納入組織流程資產。 GP 提供資源 提供充足的資源，以執行組織流程專注流程、發展工作產品及提供流程的服務。 詳細說明： 提供的資源，舉例如下： • 資料庫管理系統 • 流程改善工具 • 網頁的製作工具與瀏覽器 • 群組軟體 • 品質改善工具(例如：因果圖、相關圖、柏拉圖) GP 指派責任 指派組織流程專注流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 詳細說明： 為了流程改善，通常會建立二個團隊並指派責任：(1) 流程改善的管理指導委員會，以提供資深管理人員的贊助；(2) 流程組，以協助並管理流程改善活動。 組織流程專注(OPF) 285
CMMI for Development Version GP 訓練人員 依需要訓練人員，以執行或支援組織流程專注流程。 詳細說明： 訓練主題，舉例如下： • CMMI與其他流程及流程改善的參考模式 • 規劃並管理流程改善 • 工具、方法及分析技術 • 流程模式 • 推展技術 • 變更管理 GP 管理建構 將指定的組織流程專注流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 流程改善建議 • 組織已核准的流程行動計畫 • 推展組織流程資產的訓練教材 • 新專案推展組織標準流程的指引 • 組織流程評鑑計畫 GP 界定並納入相關的關鍵人員 依計畫界定並納入組織流程專注流程相關的關鍵人員。 組織流程專注(OPF) 286
CMMI for Development Version 詳細說明： 關鍵人員參與活動，舉例如下： • 在流程改善活動中，與流程負責人協調合作，流程負責人即目前或未來執行流程與支援組織的人(例如：訓練的工作人員與品質保證代表) • 建立組織流程的需要與目標 • 評鑑組織流程 • 執行流程行動計畫 • 在執行試用以測試所選擇的改善建議時，相互協調與合作 • 推展組織流程資產及組織流程資產的變更 • 溝通規劃、執行與推展流程改善活動相關的計畫、狀況、活動及結果 GP 監控流程 依本流程的執行計畫，監控組織流程專注流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量，舉例如下： • 提出、接受或執行之流程改善建議的數量 • CMMI成熟度等級或能力度等級 • 專案使用現有組織標準流程(或調適同一版本)的百分比 • 有關執行組織標準流程的議題趨勢(例如：界定議題的數量及結案議題的數量) GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估組織流程專注流程的遵循程度，並解決不符合的情況。 組織流程專注(OPF) 287
CMMI for Development Version 詳細說明： 審查的活動，舉例如下： • 決定流程改善機會 • 規劃並協調流程改善活動 • 在專案啟動時，推展組織標準流程 審查的工作產品，舉例如下： • 流程改善計畫 • 流程行動計畫 • 流程推展計畫 • 組織流程評鑑計畫 GP 與上層管理人員審查各狀況 與上層管理人員審查組織流程專注流程的活動、狀況及結果，並解決問題。 詳細說明： 這些審查通常是由流程組及流程行動組以簡報的型式，向管理委員會報告。 簡報的主題，舉例如下： • 流程行動組所發展的改善狀況 • 試用的結果 • 推展的結果 • 達到重要里程碑的時程狀況(即評鑑的準備度或達到組織選定的目標成熟度等級或能力度等級摘要的進度) 組織流程專注(OPF) 288
CMMI for Development Version 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標在此出現反映其在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義組織流程專注流程的說明。 GP 蒐集改善資訊 蒐集由規劃並執行組織流程專注流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 詳細說明： 工作產品、度量、度量結果及改善資訊，舉例如下： • 排定候選流程改善的優先順序的準則 • 說明組織流程優缺點的評鑑調查報告 • 依據時程說明改善活動的狀況 • 已界定的專案，調適組織標準流程及其執行的紀錄 組織流程專注(OPF) 289
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護組織流程專注流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定組織流程專注流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保組織流程專注流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正組織流程專注流程之缺失與其他問題的根本原因。 組織流程專注(OPF) 290
CMMI for Development Version 組織流程績效 成熟度第四級的流程管理類流程領域 目的 組織流程績效(Organizational Process Performance, OPP)的目的在於建立並維護量化模式，以藉此瞭解組織用於支援品質與流程績效目標之標準流程的績效，並提供流程績效資料、基準及模式，以便以量化方式管理組織的專案。 簡介 流程績效是遵循流程而達成之實際結果的度量，流程績效以流程度量(例如：工作量、週期時間及缺失移除的有效性)，以及產品度量(例如：可靠度、缺失密度、能力、反應時間及成本)來描述其特性。 組織的共通度量由流程及產品度量所構成，可用以彙整組織內個別專案之流程的實際績效。這些度量的組織資料被分析以建立度量結果的分佈及範圍，並藉以描述組織內個別專案執行此流程的預期績效。 在本流程領域，「品質及流程績效目標」這個名詞涵括產品品質、服務品質及流程績效的目標及需求。如同上述的概念，「流程績效」一詞包含品質，然而，為強調品質的重要性，因此使用「品質及流程績效目標」而不是只使用「流程績效目標」。 預期流程績效可用來設定專案的品質及流程績效目標，亦可作為與實際專案績效比較的基準。本資訊用於以量化方式管理專案。每個已量化管理的專案依序地提供實際的績效結果，以成為組織流程資產之基準資料的一部分。 相關的流程績效模式用於展現過去及目前的流程績效，並預測流程的未來結果。例如：在產品驗證活組織流程績效(OPP) 291
CMMI for Development Version 動中所界定的缺失度量，可用來預測交付產品的潛在缺失。 當組織對各項關鍵流程產品及服務特性具有度量、資料及分析技術時，就可以進行下列事項： • 決定流程的表現是否具備一致性或有穩定的趨勢(亦即，具可預測性)。 • 界定績效在常態範圍的流程，此常態範圍在不同的流程執行團隊是一致的。 • 建立相關的準則，以界定流程或子流程是否應採統計管理，並決定用於此管理程序的相關度量及分析技術。 • 界定顯示不正常(例如：偶發或不可預測的)行為的流程。 • 界定組織標準流程中可改善的任何一面。 • 界定實行最佳之流程。 相關流程領域 有關流程績效基準及模式的使用，請參考量化專案管理流程領域，以獲得更多資訊 有關如何指定度量，以及蒐集及分析資料，請參考度量與分析流程領域，以獲得更多資訊。 組織流程績效(OPP) 292
CMMI for Development Version 特定及執行方法摘要 SG 1 建立績效基準及模式 SP 選定流程 SP 建立流程績效度量 SP 設定品質及流程績效目標 SP 建立流程績效基準 SP 建立流程績效模式 各目標的特定執行方法 SG 1 建立績效基準及模式 建立並維護基準及模式，用以描述組織標準流程預期流程績效的特性。 建立流程績效的基準與模式之前，應先決定哪些流程適合度量(「選定流程」特定執行方法)、哪些度量對決定流程績效是有用的(「建立流程績效度量」特定執行方法)，以及這些流程的品質與績效目標(「設定品質及流程績效目標」特定執行方法)。這些特定執行方法彼此相互關聯，而且可能需同時執行以選定合適的流程、度量，以及品質與績效目標。通常流程、度量或品質與績效目標的選擇都會限定其他兩者的選擇，例如：選定特定的流程之後，度量及品質與績效目標的選擇就可能受限於流程本身。 SP 選定流程 於組織標準流程中，選定將納入組織流程績效分析的流程或子流程。 有關組織流程資產結構，請參考組織流程定義流程領域，以獲得更多資訊。 組織標準流程包含一組標準流程，而標準流程又由眾多的子流程所組成。 將統計的管理技術應用到組織標準流程的所有流程或子流程，通常是不可能、沒有效果且不符合經濟組織流程績效(OPP) 293
CMMI for Development Version 效益的。以組織及專案的需要及目標為基礎，選擇納入量化流程績效分析的流程及(或)子流程。 選擇流程或子流程作為組織分析的準則，舉例如下： • 子流程對主要經營目標的關係 • 目前與子流程相關之有效歷史資料的可利用性 • 目前這些資料的變動程度 • 子流程穩定性(例如，可比較案例的穩定績效) • 可用以建立預測模型之公司或商業資訊的可用性 在選擇流程或子流程時，可指出流程或子流程是穩定之專案資料的存在是個有用的準則。 典型的工作產品 1. 納入流程績效分析的流程或子流程清單 SP 建立流程績效度量 建立並維護納入組織流程績效分析之度量的定義。 有關如何選定度量，請參考度量與分析流程領域，以獲得更多資訊。 典型的工作產品 1. 所選定流程績效度量的定義 細部執行方法 1. 決定哪些組織品質與流程績效的經營目標必須由哪些度量來說明。 2. 選定能適當洞察組織品質與流程績效的度量。 如何選擇能適當洞察組織經營目標的度量，可使用「目標問題度量(Goal Question Metric )」的相關作法。 組織流程績效(OPP) 294
CMMI for Development Version 選擇度量的準則，舉例如下： • 度量與組織經營目標的關聯性 • 度量對整個產品或服務生命期的涵蓋度 • 度量是否能確實表現流程績效 • 度量的可用性 • 度量的客觀程度 • 度量資料的蒐集頻率 • 度量受流程或子流程改變的控制程度 • 度量可用以代表使用者對於有效流程績效觀點的程度 3. 將所選定的度量納入組織的共通度量。 有關如何建立組織流程資產，請參考組織流程定義流程領域，以獲得更多資訊。 4. 必要時修訂度量。 SP 設定品質及流程績效目標 設定並維護組織品質及流程績效的量化目標。 組織的品質與流程績效目標，應具有下列屬性: • 以組織的經營目標為基礎 • 以專案過去的績效為基礎 • 用以度量流程績效，例如：產品品質、生產力週期時間或反應時間 • 受限於原有的變異或選定之流程或子流程的常態範圍 典型的工作產品 1. 組織品質與流程績效目標 細部執行方法 1. 檢視品質與流程績效相關的組織經營目標。 組織流程績效(OPP) 295
CMMI for Development Version 經營目標，舉例如下： • 在特定期間內完成某一特定版本產品的發展工作。 • 對特定服務形式，達到平均反應時間小於指定時間 • 在預估成本的目標百分比內，交付產品的功能 • 減少指定百分比的產品維護成本。 2. 定義組織品質與流程績效的量化目標 設定流程或子流程度量(例如：工作量、週期時間及缺失移除的有效性)、產品度量(例如：可靠度及缺失密度)，以及適當服務度量(例如：容量及反應時間)的目標。 品質與流程績效目標，舉例如下： • 達成指定的生產力。 • 交付少於指定之潛在缺失數的工作產品。 • 在流程績效基準的指定百分比內，縮短交付時間。 • 以某百分比，減少現有及新產品的整個生命週期成本。 • 指定產品功能的交付百分比。 3. 定義組織品質與流程績效目標的優先順序。 4. 與相關的關鍵人員審查和協商組織品質與流程績效目標及其優先順序，並取得其承諾。 5. 必要時修訂組織品質與流程績效的量化目標。 組織流程績效(OPP) 296
CMMI for Development Version 組織品質與流程績效量化目標的修訂時機，舉例如下： • 當組織經營目標改變時 • 當組織流程改變時 • 當實際的品質與流程績效與目標有極大差異時 SP 建立流程績效基準 建立並維護組織流程績效基準。 組織流程績效基準是組織標準流程之不同詳細程度的績效度量，這些流程包括： • 相聯流程的次序 • 涵蓋整個專案的流程 • 發展個別工作產品的流程 組織可能需要多套的流程績效基準，以描述組織次團體績效的特性。 用以分類組織次團體的準則，舉例如下： • 產品線 • 經營種類 • 應用領域 • 複雜度 • 團隊規模大小 • 工作產品規模大小 • 從組織標準流程選出的流程元件 組織標準流程所容許的調適動作，可能會顯著影響納入流程績效基準資料的相容性，調適的結果應列入建立基準的考量。根據容許的調適，績效基準可能分別針對每一種調適種類。 有關流程績效基準的運用，請參考量化專案管理流程領域，以獲得更多資訊。 組織流程績效(OPP) 297
CMMI for Development Version 典型的工作產品 1. 組織流程績效的基準資料 細部執行方法 1. 從組織各專案蒐集度量結果。 度量時正在使用的流程或子流程應加以記錄，以便日後可適當的使用此紀錄。 有關資料的蒐集及分析，請參考度量與分析流程領域，以獲得更多資訊。 2. 從蒐集的度量資料及分析結果，建立並維護組織的流程績效基準。 有關設定度量與分析的目標、設定欲執行的度量與分析、蒐集與分析度量結果及報告結果，請參考度量與分析流程領域，以獲得更多資訊。 流程績效基準係由分析蒐集的度量資料，以建立結果的分佈與範圍所衍生而來，其描述組織的個別專案，在使用選定流程或子流程的預期績效。 應使用來自專案之穩定子流程所取得的度量結果，其他資料可能不可靠。 3. 與相關關鍵人員審查組織流程績效基準，並達成協議。 4. 將組織流程績效資訊納入組織度量儲存庫，以供整個組織使用。 專案可使用組織流程度量基準，以估計流程績效的常態範圍。 有關如何建立組織度量儲存庫，請參考組織流程定義流程領域，以獲得更多資訊。 5. 比較組織流程績效基準與相關的目標。 6. 必要時修訂組織流程績效基準。 組織流程績效(OPP) 298
CMMI for Development Version 組織流程績效基準的修訂時機，舉例如下： • 當流程改變時 • 當組織的結果改變時 • 當組織的需要改變時 SP 建立流程績效模式 建立並維護組織標準流程的流程績效模式。 配合其他流程、產品及服務度量獲得的數值，流程績效模式可用來估計或預測一個流程績效度量的數值。這些流程績效模式，通常使用由整個專案執行過程所蒐集的流程及產品度量數值，來推估非到專案執行過程後段才能度量的目標達成進度。 流程績效模式運用範圍如下: • 組織運用它們以估計、分析及預測與組織標準流程相關的流程績效。 • 組織運用它們以評量組織改善活動的(潛在)投資報酬。 • 專案運用它們以估計、分析及預測其已調適流程的流程績效。 • 專案運用它們以選擇使用的流程或子流程。 這些度量及模式用來提供必要的洞察力及能力，以預測對經營有價值的關鍵流程及產品特性。 組織流程績效(OPP) 299
CMMI for Development Version 模式可能有用的專案相關領域，舉例如下： • 時程及成本 • 可靠度 • 缺失界定及移除比率 • 缺失移除有效性 • 潛在的缺失估計 • 反應時間 • 專案進度 • 上述領域的組合 流程績效模式，舉例如下： • 系統動態模式 • 可靠度成長模式 • 複雜度模式 有關流程績效模式的使用，請參考量化專案管理流程領域，以獲得更多資訊。 典型的工作產品 1. 流程績效模式 細部執行方法 1. 以組織標準流程及組織流程績效基準為基礎，建立流程績效模式。 2. 以組織過去的結果及目前的需要為基礎，調整流程績效模式。 3. 與相關關鍵人員審查流程績效模式，並達成協議。 4. 支持流程績效模式在專案的運用。 5. 必要時修訂流程績效模式。 組織流程績效(OPP) 300
CMMI for Development Version 流程績效模式的修訂時機，舉例如下： • 當流程改變時 • 當組織的結果改變時 • 當組織的需要改變時 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施組織流程績效流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 僅適用於階段式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行組織流程績效流程。 詳細說明： 本政策建立組織的期望，以建立並維護組織標準流程的流程績效基準。 組織流程績效(OPP) 301
CMMI for Development Version GP 規劃流程 建立並維護執行組織流程績效流程的計畫。 詳細說明： 執行組織流程績效流程的計畫可包含於組織改善計畫或由其引用參考(組織改善計畫在組織流程專注流程領域中描述)，或是記錄於另一個的計畫，僅描述執行組織流程績效的流程。 GP 提供資源 提供充足的資源，以執行組織流程績效流程、發展工作產品及提供流程服務。 詳細說明： 可能需要統計及統計流程控制(SPC)等特殊的專業知識，以建立組織標準流程的流程績效基準。 其他可用的資源工具，舉例如下： • 資料庫管理系統 • 系統動態模式 • 流程模式化工具 • 統計分析套裝軟體 • 問題追蹤套裝軟體 GP 指派責任 指派組織流程績效流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援組織流程績效流程。 組織流程績效(OPP) 302
CMMI for Development Version 詳細說明： 訓練的主題，舉例如下： • 流程及流程改善模式化 • 計量及統計方法(例如：估計模式、柏拉圖分析及控制圖) GP 管理建構 將指定的組織流程績效流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 組織的品質與流程績效目標 • 所選定流程績效度量的定義 • 組織流程績效的基準資料 GP 界定並納入相關的關鍵人員 依計畫界定並納入組織流程績效流程相關關鍵人員。 詳細說明： 關鍵人員參與的活動，舉例如下： • 建立組織品質與流程績效目標及其優先順序 • 審查並解決有關組織流程績效基準的議題 • 審查並解決有關組織流程績效模式的議題 GP 監控流程 依本流程的執行計畫，監控組織流程績效流程，並採取適當的矯正措施。 組織流程績效(OPP) 303
CMMI for Development Version 詳細說明： 用於監控的度量及作產品，舉例如下： • 工作產品及工作項目屬性變化對組織流程績效影響的趨勢(例如：規模大小成長、工作量、時程及品質) • 用於建立流程績效基準之度量的蒐集與審查時程。 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估組織流程績效流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 建立流程績效基準及模式 審查的工作產品，舉例如下： • 流程績效計畫 • 組織品質與流程績效目標 • 所選定之流程績效度量的定義 GP 與上層管理人員審查各狀況 與上層管理人員審查組織流程績效流程的活動、狀況及結果，並解決議題。 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 組織流程績效(OPP) 304
CMMI for Development Version GP 建立已定義流程 建立並維護已定義組織流程績效流程的說明。 GP 蒐集改善資訊 蒐集由規劃並執行組織流程績效流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 詳細說明： 工作產品、度量、度量結果及改善資訊，舉例如下： • 流程績效基準 • 由於與流程績效度量定義不一致，所剔除度量資料的百分比 組織流程績效(OPP) 305
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護組織流程績效流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定組織流程績效流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保組織流程績效流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正組織流程績效流程之缺失與其他問題的根本原因。 組織流程績效(OPP) 306
CMMI for Development Version 組織訓練 成熟度第三級的流程管理類流程領域 目的 組織訓練(Organizational Training, OT)的目的在於發展人員的技能與知識，使其有效執行他們的任務。 簡介 組織訓練包括兩方面的訓練：一是配合組織策略性經營目標的訓練，一是滿足專案與支援團隊共同需要的實務訓練。個別專案與支援團隊階層負責處理其界定的特定訓練需要，而且不包含在組織訓練範圍之內。專案與支援團隊負責界定及提出他們的特定訓練需要。 有關專案所界定的特定訓練需要，請參考專案規劃流程領域，以獲得更多的資訊。 組織訓練計畫包括下列各項： • 界定組織所需要的訓練 • 取得並提供訓練以滿足需要 • 建立並維護訓練能力 • 建立並維護訓練紀錄 • 評量訓練成效 有效的訓練需要對需求、規劃、教學設計及適當訓練媒體 (例如：規範手冊、電腦軟體) 進行評量，並需要一訓練流程資料的儲存庫。如同組織流程一樣，訓練的主要元件包括一套被管理的訓練發展計畫、計畫書、具特定專業與其他知識領域的專精人員，以及用以度量訓練計畫成效的機制。 主要根據執行組織標準流程所需的技能來界定流程訓練需求。 組織訓練(OT) 307
CMMI for Development Version 有關組織標準流程，請參考組織流程定義流程領域，以獲得更多的資訊。 某些技能可有效的透過課堂以外的方式傳授(例如：非正式的顧問指導)，其他技能則需要較正規的訓練方式(例如：課堂教學、網路教學、自修或正式的在職訓練計畫等)。以訓練需求與需解決之績效落差的評量為基礎，採用正規或非正規的訓練方式。本流程領域所使用的「訓練」字眼，泛指正規或非正規訓練方式的學習活動。 依據企業執行新的或正在進行的活動中，應用訓練所獲取的技能與知識的有用性來度量訓練成功與否。 技能與知識可以是技術的、組織的或人際關係的。技術性技能是指專案或流程所需之設備、工具、材料、資料及流程的使用能力。組織技能是指依據員工的組織結構、角色與責任，以及一般性運作原則與方法有關的行為。人際關係技能是指專案及支援團隊在組織及社會關係中，成功執行所需的自我管理、溝通及人際關係的能力。 「專案及支援團隊」一詞，經常使用於流程領域本文的敘述，用來指明組織階層的觀點。 相關流程領域 有關組織流程資產，請參考組織流程定義流程領域，以獲得更多資訊。 有關專案所界定的特定訓練需求，請參考專案規畫流程領域，以獲得更多資訊。 有關如何應用決策準則，以決定訓練方法，請參考決策分析與解決方案流程領域。 組織訓練(OT) 308
CMMI for Development Version 特定目標及執行方法摘要 SG 1 建立組織訓練能力 SP 建立策略性訓練需求 SP 決定哪些訓練需求是組織的責任 SP 建立組織訓練的實施計畫 SP 建立訓練能力 SG 2 提供必要的訓練 SP 實施訓練 SP 建立訓練紀錄 SP 評量訓練成效 各目標的特定執行方法 SG 1 建立組織訓練能力 建立與維護用以支援組織之管理與技術任務的訓練能力。 組織應界定訓練需求，以增進執行企業活動必要的技能與知識。一旦需求被界定，即可提出滿足這些需求的訓練計畫。 IPPD補充 整合團隊成員必須接受跨職務訓練、領導能力訓練、人際關係技能訓練，以及整合適當的經營與技術功能所需的訓練。在產品與流程發展時，必須有各種不同工作背景的人員參與作業，並將各種可能的需求納入發展過程。在此種發展方式下，非需求發展團隊的相關關鍵人員必須接受產品設計相關的跨職務訓練，以承諾需求，並完整掌握各類需求的內容與需求間的關係。 SP 建立策略性訓練需求 建立並維護組織的策略性訓練需求。 組織訓練(OT) 309
CMMI for Development Version 藉由彌補重大知識的落差、引用新技術或實施重大行為變更，策略性訓練需要說明長期的目標，以建立能力。策略性規畫通常往後看二至五年。 策略性訓練需求的來源，舉例如下： • 組織的標準流程 • 組織的策略性經營計畫 • 組織的流程改善計畫 • 企業層級的想法 • 技術評量 • 風險分析 IPPD需要領導與人際關係的技能，超過傳統得發展環境。在IPPD環境，強調的特定技能包括： • 整合所有適當的經營與技術功能及其流程的能力 • 與他人溝通與協調的能力 典型的工作產品 1. 訓練需求 2. 評量分析 細部執行方法 1. 分析組織的策略性經營目標與流程改善方案，以界定未來潛在的訓練需求。 2. 記錄組織的策略性訓練需求。 組織訓練(OT) 310
CMMI for Development Version 訓練需求的種類，舉例如下(但不限於所舉範例)： • 流程分析與文件製作 • 工程(例如：需求分析、設計、測試、建構管理及品質保證) • 服務交付項目 • 供應商的選擇與管理 • 管理(例如：估計、追蹤及風險管理) • 災難復原與運作的持續性 3. 決定實施組織標準流程所需的角色與技能。 4. 記錄組織標準流程中各角色所需的訓練。 5. 記錄維護安全、保全及持續經營運作所需的訓練。 6. 必要時，修訂組織的策略性需求及所需的訓練。 SP 決定哪些訓練需求是組織的責任 決定哪些訓練需求是組織的責任，以及哪些是個別專案或支援團隊的責任。 有關專案及支援團隊特定的訓練計畫，請參考專案規劃流程領域，以獲得更多資訊。 組織訓練除了滿足策略性訓練需求外，同時也要滿足跨專案與支援團隊的共同訓練需求。專案及支援團隊的主要責任，是界定與提出他們的特定訓練需求。組織訓練的工作人員，僅須負責提出跨專案及支援團隊的共同訓練需求，例如：多專案共同的工作環境訓練。然而，有些情況是在訓練資源允許及組織訓練優先的前提下，在組織訓練的工作人員與專案及支援團隊協商後，可能會提出額外的訓練需求。 組織訓練(OT) 311
CMMI for Development Version 典型的工作產品 1. 專案與支援團隊的共同訓練需求 2. 訓練承諾 細部執行方法 1. 分析由不同專案與支援團隊所界定的訓練需求。 專案與支援團隊需求的分析意指界定能夠最有效滿足整個組織的共同訓練需求，這些需求分析的活動，通常是先從專案與支援團隊階層中，察覺到未來的訓練需求。 2. 與不同專案和支援團隊協調如何滿足他們的特定訓練需求。 在訓練資源允許及組織訓練優先的前提下，由組織訓練的工作人員提供支援。 適合由專案或支援團隊執行的訓練，舉例如下： • 專案應用或服務領域的訓練 • 專案或支援團隊所使用之特殊工具與方法的訓練 • 安全、保全與人際關係的訓練 3. 記錄將提供予專案與支援團隊的訓練承諾。 SP 建立組織訓練的實施計畫 建立並維護組織訓練的實施計畫。 組織訓練的實施計畫是與訓練內容和組織責任相關的計畫，對個人有效的執行其角色是必要的。此一計畫解決短期訓練的執行，會因應相關因素的變化(如需求或資源)與訓練成效的評估而進行週期性的修訂。 典型的工作產品 1. 組織訓練實施計畫。 組織訓練(OT) 312
CMMI for Development Version 細部執行方法 1. 建立計畫內容。 組織訓練實施計畫，通常包含下列內容： • 訓練需求 • 訓練主題 • 以訓練活動及其相依性為基礎的時程表 • 訓練所使用的方法 • 訓練教材的需求與品質標準 • 訓練工作項目、角色及責任 • 所需的資源，包括：工具、設備、環境、人員、技能與知識。 2. 建立對計畫的承諾。 為使計畫有成效，有必要記錄負責執行與支援計畫人員的承諾。 3. 必要時，修訂計畫與承諾。 SP 建立訓練能力 建立並維護訓練能力，以滿足組織的訓練需求。 有關如何應用決策準則，以選擇訓練方法與發展訓練教材，請參考決策分析與解決方案流程領域。 典型的工作產品 1. 訓練教材與支援物品 細部執行方法 1. 選擇適當的方法，以滿足特定的組織訓練需求。 許多因素可能會影響訓練方法的選擇，包括聽眾特定的知識、成本與時程、工作環境等。選擇方法時，必須考量在既定的限制下，提供最有效的技能與知識的方法。 組織訓練(OT) 313
CMMI for Development Version 訓練方法，舉例如下： • 教室訓練 • 電腦輔助教學 • 自修 • 正式的師徒傳授課程 • 視訊教學 • 用圖解說明的演講 • 午餐討論會 • 有系統的在職訓練 2. 決定內部自行發展或自外部取得教材。 決定內部發展訓練或自外部取得訓練的成本與效益。 可用以決定獲取知識、技能最有效率方式的準則，舉例如下： • 績效目標 • 準備專案執行的可利用時間 • 經營目標 • 內部專業人才的可用性 • 外部訓練來源的可用性 外部訓練來源，舉例如下： • 客戶提供的訓練 • 可取得的商業化訓練課程 • 學術課程 • 專業研討會 • 專題討論會 組織訓練(OT) 314
CMMI for Development Version 3. 發展或取得訓練教材。 訓練可由專案、支援團隊、組織或外部組織來提供。無論提供來源為何，組織訓練的工作人員，應協調訓練的取得與實施。 訓練教材，舉例如下： • 課程內容 • 電腦輔助教學 • 教學錄影帶 4. 培訓或尋求合格講師。 為確保由組織內部提供的講師具備必需的知識與教學技能，可訂定發掘、培訓、評定內部講師的準則。若是由外部機構提供訓練，組織訓練的工作人員可以檢視該外部機構如何選定講師人選。選定講師的方式也可做為選取或持續引用外部訓練機構的因素之一。 5. 於組織訓練課程中，說明訓練內容。 每個課程在訓練說明中所提供的資訊，舉例如下： • 訓練涵蓋的主題 • 預期的訓練對象 • 參加訓練的必備條件與準備事項 • 訓練目標 • 訓練期間 • 課程計畫 • 課程的完成準則 • 允許訓練豁免的準則 6. 必要時，修訂訓練教材與支援物品。 組織訓練(OT) 315
CMMI for Development Version 訓練教材與支援物品可能需修訂的時機，舉例如下： • 訓練需求改變(例如：與訓練主題相關的新技術可取得時) • 訓練的評估結果界定出變更需求(例如：訓練成效調查、訓練計畫績效評量或教學評量表的評估) SG 2 提供必要的訓練 提供個人必要的訓練，使其能有效地執行任務。 選擇受訓人員時，應考量下列事項： • 參與受訓目標人選的背景 • 受訓的必備資格 • 人員執行任務所需的技能與能力 • 針對跨專業的技術管理訓練需求，包括專案管理 • 管理人員接受適當組織流程訓練的需求 • 對安排特定工程領域基本工作方式，以支援人員的品質管理、建構管理及其他相關支援功能的訓練需求 • 提供關鍵功能領域之發展能力的需求 • 維護個人能力與資格，以運作與維護對眾多專案共同的工作環境。 SP 實施訓練 依據組織的訓練實施計畫提供訓練。 典型的工作產品 1. 實施的訓練課程 細部執行方法 1. 選擇需接受訓練以有效執行其角色的受訓人員。 訓練的目的是要傳授知識與技能予組織內執行各種任務的人員。某些人已擁有必須圓滿執行指定任務所必要的知識與技能。對於這些人而言，可 組織訓練(OT) 316
CMMI for Development Version 以免除訓練，但應小心謹慎，避免訓練豁免權被濫用。 2. 排定訓練時程，包括任何必要的資源(如設備及講師)。 訓練應規劃和排定時程。訓練的提供，對預期的工作績效有直接影響。因此，最佳的訓練對於預期的工作績效有立竿見影的效果。這些期望常包含下列： • 使用特定工具的訓練 • 個人如何執行新程序的訓練 3. 進行訓練。 訓練應由有經驗的講師執行。如果可以的話，訓練應在非常類似實際的執行情況下實施，並包括活動以模擬實際的工作情況。此方法包括用以發展能力之工具、方法及程序的整合。訓練應與工作責任結合，如此一來，在職的活動或其他外來的經驗，在訓練後合理的時間內，將可強化其訓練。 4. 追蹤訓練是否依計畫進行。 SP 建立訓練紀錄 建立並維護組織訓練的紀錄。 有關專案或支援團隊如何維護訓練紀錄，請參考專案監控流程領域，以獲得資訊。 本執行方法的範圍，是在組織層級所執行的訓練。對於專案或支援贊助之訓練紀錄的建立及維護，由個別專案或支援團隊負責。 典型的工作產品 1. 訓練紀錄 2. 更新於組織儲存庫的訓練 組織訓練(OT) 317
CMMI for Development Version 細部執行方法 1. 對於每項訓練課程或其他核准的訓練活動，保存所有完成與未完成訓練的學員紀錄。 2. 保存所有豁免特定訓練之人員的紀錄。 允許豁免訓練的理由必須加以記錄；學員必須取得負責經理及其直屬經理的核准才可豁免特定訓練。 3. 保存所有成功完成指定之必要訓練的學員紀錄。 4. 讓適當人員可取得訓練紀錄，作為指派工作的考量。 訓練紀錄可以做為訓練組織所發展之技能資料表的一部分，以提供人員經驗及教育的彙整，以及組織所負責的訓練。 SP 評量訓練成效 評量組織訓練計畫的成效。 應存在決定訓練成效的流程(即：訓練是如何符合組織的需求)。 評量訓練成效的方法，舉例如下： • 受訓內容的測驗 • 受訓後對受訓人員的調查 • 經理對受訓後效果的滿意度調查 • 教育軟體內建的評量機制 針對專案與組織目標，訓練所產生的附加價值可用度量來評量，不同訓練方法的需求也必須加以注意，例如：將訓練團隊視為一個整體的工作單位。當實行度量時，績效目標應與課程參與者分享，且績效目標應是清楚、顯著及可驗證的。訓練成效評量的結果應用以修訂上述「建立訓練能力」特定執行方法所述的訓練教材。 組織訓練(OT) 318
CMMI for Development Version 典型的工作產品 1. 訓練成效調查 2. 訓練計畫績效評量 3. 教學評估表 4. 訓練測驗 細部執行方法 1. 評量進行中或已完成專案，以決定人員知識是否足以完成專案工作。 2. 針對已建立的組織、專案或個人學習(或績效)目標，提供評量每一訓練課程成效的機制。 3. 取得學員有關訓練活動是否符合其需求的評估。 組織訓練(OT) 319
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施組織訓練流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 僅適用於階段式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行組織訓練流程。 詳細說明： 本政策建立組織的期望，以界定組織策略性訓練需求，並提供該項訓練。 GP 規劃流程 建立並維護用以執行組織訓練流程的計畫。 組織訓練(OT) 320
CMMI for Development Version 詳細說明： 用以執行組織訓練流程的計畫與本流程領域中特定執行方法所述的組織訓練實施計畫是不同的，在本一般執行方法所說的計畫應說明本流程領域所有特定執行方法的廣泛規劃，由建立策略性訓練需求，一直到組織訓練績效評量；相對的，本特定執行方法所謂的組織訓練實施計畫則應敘述個別訓練實施的定期性規劃。 GP 提供資源 提供充足的資源，以執行組織訓練流程、發展工作產品及提供流程服務。 詳細說明： 人員(全職或兼職、內部或外部)及技能需求，舉例如下： • 主題專家 • 課程設計人員 • 教學設計人員 • 講師 • 訓練管理人員 訓練可能需要特殊設備，當需要時，應發展或購買組織訓練流程領域活動所需的設備。 用於執行組織流程領域活動的工具，舉例如下： • 用於分析訓練需求的工具 • 用於訓練的工作站 • 教學設計工具 • 發展簡報教材的相關資料的套裝軟體 組織訓練(OT) 321
CMMI for Development Version GP 指派責任 指派組織訓練流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援組織訓練流程。 詳細說明： 有關一般執行方法GP 與組織訓練流程領域關係，請參考表一般目標與一般執行方法，以獲得更多資訊。 訓練的主題，舉例如下： • 知識與技能需求分析 • 教學設計 • 教學技巧(例如：訓練人員的訓練) • 主題的更新訓練 GP 管理建構 將指定的組織訓練流程工作產品，納入適當層級的控制。 詳細說明： 納入建構管理的工作產品，舉例如下： • 組織訓練實施計畫 • 訓練紀錄 • 訓練教材及支援物品 • 教學評估表 GP 界定並納入相關的關鍵人員 依計畫界定並納入組織訓練流程相關的關鍵人員。 組織訓練(OT) 322
CMMI for Development Version 詳細說明： 相關關鍵人員參與的活動，舉例如下： • 建立訓練需求與訓練成效溝通協調的環境，以確保符合組織訓練的需求 • 界定訓練需求 • 審查組織訓練的實施計畫 • 評量訓練成效 GP 監控流程 依本流程的執行計畫，監控組織訓練流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量，舉例如下： • 已實施的訓練課程數(例如：規劃的相較於實際的) • 受訓後的評價 • 訓練計畫品質調查評價 • 交付訓練的時程 • 課程發展的時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估組織訓練流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 界定訓練需求並取得訓練 • 提供必要的訓練 組織訓練(OT) 323
CMMI for Development Version 審查的工作產品，舉例如下： • 組織訓練實施計畫 • 訓練教材與支援物品 • 教學評量表 GP 與上層管理人員審查各狀況 與上層管理人員審查組織訓練流程的活動、狀況及結果，並解決問題。 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義組織訓練流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行組織訓練流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 詳細說明： 工作產品、度量、度量結果及改善資訊，舉例如下： • 訓練成效調查結果 • 訓練計畫績效評量結果 • 課程評估 • 顧問群的訓練需求 組織訓練(OT) 324
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護組織訓練流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定組織訓練流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保組織訓練流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正組織訓練流程之缺失與其他問題的根本原因。 組織訓練(OT) 325
CMMI for Development Version 產品整合 成熟度第三級的工程類流程領域 目的 產品整合(Product Integration, PI)的目的，在於將產品組件組合為產品、確保已整合的產品適當地運作及交付產品。 簡介 產品整合流程領域說明，將產品組件整合成更複雜的產品組件或完整的產品。 此領域的範圍，是依據已定義的整合順序與程序，在一個階段或漸進的階段，逐漸地組合產品組件，以達成完整的產品整合。整個流程領域中，產品及產品組件的意涵也包括服務及其組件。 產品整合的關鍵點，為產品與產品組件的內部與外部介面的管理，以確保介面間的相容性。在整個專案進行中，應注意介面管理。 產品整合不只是在完成設計與製造時，進行一次產品組件的組合而已。產品整合可使用下列重複過程漸進執行，包括：組合產品組件、評估已組合的產品組件，再組合更多的產品組件。這整合過程，首先分析與模擬(例如：相關串聯、快速雛型、虛擬雛型及實體雛型)，並穩定的進展，逐漸增加更多實際的功能，直到達成最終產品。在每一次連續的「建造」時，雛型(虛擬、快速或實體)被建造、評估、改進，並基於評估過程所得到知識再建造。虛擬對實體雛型的要求程度，決定於設計工具的功能、產品的複雜度與有關的風險。以此方式整合產品，有很高的可能性會通過產品驗證與確認。就一些產品及服務而言，最後的整合階段，會在產品部署於預期的運作場所時進行。 產品整合(PI) 326
CMMI for Development Version 相關流程領域 有關界定介面需求，請參考需求發展流程領域，以獲得更多資訊。 有關定義介面與整合環境(當需要發展整合環境時)，請參考技術解決方案流程領域，以獲得更多資訊。 有關驗證介面、整合環境及漸進組合的產品組件，請參考驗證流程領域，以獲得更多資訊。 有關執行產品組件與已整合產品的確認，請參考確認流程領域，以獲得更多資訊。 有關界定風險與使用雛型於降低介面相容性及產品組件整合之風險，請參考風險管理流程領域，以獲得更多資訊。 有關使用正式評估流程，以選擇適當的整合順序與程序及決定整合環境之採購或發展，請參考決策分析與解決方案流程領域，以獲得更多資訊。 有關管理介面定義之變更與資訊發佈，請參考建構管理流程領域，以獲得更多資訊。 有關獲得產品組件或部分的整合環境，請參考供應商協議管理流程領域，以獲得更多資訊。 產品整合(PI) 327
CMMI for Development Version 特定目標及執行方法摘要 SG 1準備產品整合 SP 決定整合順序 SP 建立產品整合環境 SP 建立產品整合程序與準則 SG 2確保介面相容性 SP 審查介面說明的完整性 SP 管理介面 SG 3組合產品組件並交付產品 SP 確定欲整合的產品組件已準備就緒 SP 組合產品組件 SP 評估已組合的產品組件 SP 包裝並交付產品或產品組件 各目標的特定執行方法 SG 1 準備產品整合 完成產品整合的準備。 準備產品組件的整合，包含建立並維護整合順序、執行整合的環境及整合程序。「準備產品整合」特定目標的特定執行方法的關係，如下述：第一個特定執行方法決定產品與產品組件整合的順序。第二個特定執行方法決定用來完成產品，或整合產品組件的環境。第三個特定執行方法發展產品與產品組件整合的程序與準則。在專案初期便開始整合的準備動作，且與技術解決方案流程領域的執行方法同步發展整合順序。 SP 決定整合順序 決定產品組件的整合順序。 整合的產品組件可能包含交付產品的一部分與測試設備、測試軟體或其他像是配件的整合項目。一旦已分析替代的測試與組合的整合順序，就選擇最佳的整合順序。 產品整合(PI) 328
CMMI for Development Version 產品整合順序提供產品組件的漸進的組合及評估，並為納入其他可取得之產品組件或高風險產品組件的雛型，提供一個沒有問題的基礎。 整合順序應與技術解決方案流程領域中解決方案的選擇及產品與產品組件的設計和諧一致。 有關使用正式評估流程，以選擇適當的產品整合順序，請參考決策分析與解決方案流程領域，以獲得更多資訊。 有關界定與處理整合順序相關的風險，請參考風險管理流程領域，以獲得更多資訊。 有關移交取得的產品組件，與產品整合順序需處理的產品組件需求，請參考供應商協議管理流程領域，以獲得更多資訊。 典型的工作產品 1. 產品整合順序 2. 選擇或拒絕整合順序的理由 細部執行方法 1. 界定待整合的產品組件。 2. 界定產品組件整合時，將執行的驗證[s2]。 3. 界定備選的產品組件整合順序。 可包含定義特定工具與測試設備，以支援產品整合。 4. 選擇最佳整合順序。 5. 定期審查產品整合順序，必要時予以修訂。 評量整合順序，以確保生產與交付時程之差異，不會對整合順序有不利的影響，或不會危及早期所做的決定。 6. 記錄制定與擱置決策的理由。 SP 建立產品整合環境 建立並維護支援產品組件整合所需的環境。 產品整合(PI) 329
CMMI for Development Version 有關自製或採購的決策，請參考技術解決方案流程領域，以獲得更多資訊。 產品整合環境可自外部取得或自行發展。為了建立環境，必須發展設備、軟體，以及其他資源採購或自製的需求。這些需求在實作與需求發展流程領域相關的流程時產生。產品整合環境可能包含現有組織資源的再用。採購或自行發展產品整合環境的決策，在技術解決方案流程領域相關的流程中說明。 產品整合流程之每一步驟所需的環境，可包括測試設備、模擬器(代替無法取得的產品組件)、實際設備的部分及記錄裝置。 典型的工作產品 1. 已驗證的產品整合環境 2. 產品整合環境的支援文件 細部執行方法 1. 界定產品整合環境的需求。 2. 界定產品整合環境的驗證準則與程序。 3. 決定自製或採購所需的產品整合環境。 有關整合環境的採購，請參考供應商協議管理流程領域，以獲得更多資訊。 4. 若無法採購合適的環境，則自行發展整合環境。 對無前例、複雜的專案而言，產品整合環境是一項重大的發展工作。因此它會包括專案規劃、需求發展、技術解決方案、驗證、確認及風險管理。 5. 整個專案進行時，維護產品整合環境。 6. 產品整合環境的某些部分不再使用時，進行處置。 SP 建立產品整合程序與準則 建立並維護產品組件整合的程序與準則。 產品整合(PI) 330
CMMI for Development Version 產品組件的整合程序所包含事項，如：執行漸進整合的次數，以及在每一階段需執行之預期測試與其他評估的細節。 準則可指出產品組件可進行整合或其可接受性的準備度。 產品整合的程序與準則，說明如下： • 建立組件的測試階層 • 介面的驗證 • 效能偏差的門檻 • 產品組合與其外部介面的衍生需求 • 允許的替代組件 • 測試環境參數 • 測試成本的限度 • 執行整合時，品質與成本的取捨 • 正確運作的機率 • 交付率及其差異 • 訂貨到交貨所需的時間 • 人員可用性 • 整合設備/生產線/環境的可用性。 準則可定義如何驗證產品組件及期望的功能，並定義如何確認與交付組合的產品組件與最終已整合的產品。 準則可限制允許產品組件通過測試模擬的程度，或限制用來作為整合測試的環境。 適當地將部分的組合時程及準則與工作產品的供應商分享，以減少延期或組件錯誤的發生。 有關與供應商的溝通，請參考供應商協議管理流程領域，以獲得更多的資訊。 典型的工作產品 1. 產品整合程序 2. 產品整合準則 產品整合(PI) 331
CMMI for Development Version 細部執行方法 1. 建立並維護產品組件的產品整合程序。 2. 建立並維護產品組件整合與評估的準則。 3. 建立並維護已整合產品的確認與交付準則。 SG 2 確保介面相容性 產品組件的內部與外部介面是相容的。 許多產品整合問題，起源於未知或無法控制的內部及外部介面。有效的管理產品組件介面的需求、規格及設計，可確保已實作之介面的完整與相容。 SP 審查介面說明的完整性 審查介面說明的範圍與完整性。 除產品組件介面外，介面應包括產品整合環境中的所有介面。 典型的工作產品 1. 介面類別 2. 每個類別的介面清單 3. 介面與產品組件及產品整合環境的對照表 細部執行方法 1. 審查介面資料的完整性，並確保已涵蓋所有介面。 考慮所有的產品組件，並準備一張關係表。介面通常分成三種主要類型：環境、實體及功能。這些類別的典型介面類型包括：機械、流體、聲音、電子、氣候、電磁、熱、訊息，以及人機或人因介面。 產品整合(PI) 332
CMMI for Development Version 可分類於此三種類型的介面(如，機械或電子組件)，舉例如下： • 機械介面(例如：重量及規模大小、重力中心、操作零件間隙、維護所需空間、固定連接、移動連接、由軸承結構所接收的震動與振動) • 噪音介面(例如：結構所傳動的噪音、空氣中傳動的噪音、聽音) • 氣候介面(例如：溫度、濕度、壓力、鹽度) • 熱介面(例如；熱散、軸承結構的熱傳導、空調特性) • 流體介面(例如：淡水入口/出口、船運/海岸產品的海水入口/出口、空調、壓縮空氣、氮、燃料、潤滑油、排出氣體出口) • 電氣介面(例如：網路電力供應消耗量的電流變換量與尖峰量、電力供應與通訊無敏感控制信號；敏感信號[如，類比連接]；分配信號[微波等]；符合TEMPEST標準地面信號) • 電磁介面(例如：磁場、無線電與雷達連接、光頻連接波、同軸電纜與光纖電纜) • 人機介面(例如：聲音合成、聲音識別、顯示器[類比顯示盤、電視螢幕、或液晶顯示器、指示器的光發射電子組件]、人工操控裝置[踏板、操縱桿、操作球、操作鍵、按鈕、觸控螢幕] ) • 訊息介面(例如：來源、終點、刺激、協定及資料特徵) 2. 確保產品組件與介面已標註記號，以確保容易與正確的連接產品組件。 3. 定期審查介面說明的充份性。 產品整合(PI) 333
CMMI for Development Version 建立介面後，必須定期審查介面說明，以確保現有介面說明與正在發展、處理、生產或購買中的產品並無偏差。 產品組件介面說明應與相關關鍵人員共同審查，以避免誤解、減少延期，並避免發展無法正常運作的介面。 SP 管理介面 管理產品與產品組件的內部與外部介面之定義、設計與變更。 介面需求驅動整合產品組件所需介面的發展。在產品發展初期便開始管理產品與產品組件介面。介面的定義與設計不只影響產品組件與外部系統，也影響驗證與確認的環境。 有關介面需求，請參考需求發展流程領域，以獲得更多資訊。 有關產品組件間的介面設計，請參考技術解決流程領域，以獲得更多資訊。 有關介面需求變更的管理，請參考需求管理流程領域，以獲得更多資訊。 有關發佈介面說明(規格)的變更，以使每個人知道介面的最新狀態，請參考建構管理流程領域，以獲得更多資訊。 介面管理包括維護介面在整個產品週期的一致性，以及解決衝突、不符合及變更議題。供應商取得的產品、與其他產品或產品組件間的介面管理，對專案的成功有關鍵性影響。 有關管理供應商，請參考供應商協議管理流程領域，以獲得更多資訊。 除產品組件的介面外，介面應包括整合環境中的所有介面，以及用於驗證、確認、操作及支援之其他環境的所有介面。 需記錄、維護介面的變更，並使其容易取用。 產品整合(PI) 334
CMMI for Development Version 典型的工作產品 1. 產品組件與外部環境的關係表(例如：主電源、用來固定的產品、電腦匯流系統等) 2. 不同產品組件間的關係表 3. 適用時，已同意之每對產品組件間的介面清單 4. 介面管制工作組會議報告 5. 更新介面的行動方案 6. 應用程式介面(API) 7. 已更新的介面說明或協議 細部執行方法 1. 確保介面在整個產品生命週期的相容性。 2. 解決衝突、不符合及變更議題。 3. 維護專案參與人員可取得的介面資料儲存庫。 一個共用、可存取的介面資料儲存庫，提供一機制，以確保每人都知道最新介面資料存放處，及其取得和使用。 SG 3 組合產品組件並交付產品 組合已驗證的產品組件，並交付已整合、已驗證及已確認的產品。 依據產品整合順序與可用的程序，進行產品組件整合。整合前，每一產品組件應確定與其介面需求相符合。產品組件被組合成更大、更複雜的產品組件，並檢查已組合的產品組件能正確的相互操作。持續此流程，直到完成產品整合。在整合過程中，如界定出問題，應記錄問題，並啟動矯正措施流程。 確保依據產品整合順序與可用的程序，組合產品組件成更大、更複雜的產品組件。及時接收所需的產品組件與適合人員的參與，將促成產品組件成功地整合成產品。 產品整合(PI) 335
CMMI for Development Version SP 確定欲整合的產品組件已準備就緒 在產品組合前，確定欲組合成產品的產品組件已被適當的界定、並依據其說明運作，以及確定產品組合介面符合介面說明。 有關確認產品組件，請參考確認流程領域，以獲得更多資訊。 有關產品組件的單元測試，請參考技術解決流程領域，以獲得更多資訊。 本特定執行方法的目的，在確保已適當界定的產品組件符合其說明文件，並能依產品整合順序與可用程序實際組合。檢查產品組件的數量、明顯的損害及產品組件與介面說明間的一致性。 執行產品整合，最終要負責檢查，以確定所有事情在產品組件組合前皆已就緒。 典型的工作產品 1. 已接收產品組件的驗收文件 2. 交付的收據 3. 已檢查的包裝清單 4. 異常報告 5. 豁免權 細部執行方法 1. 當產品組件變成可用於整合時，儘快追蹤所有產品組件的狀態。 2. 依據產品整合順序與可用程序，確保產品組件已交付至產品整合環境中。 3. 確定收到每個正確界定的產品組件。 4. 確保每一接收的產品組件符合其說明。 5. 依期望的建構，檢查其建構狀態。 6. 在連接產品組件前，執行所有實體介面的預先檢查(例如：目視檢查與使用基本度量)。 產品整合(PI) 336
CMMI for Development Version SP 組合產品組件 依據產品整合順序與可行程序，組合產品組件。 本特定執行方法的組合活動與下一個特定執行方法的評估活動交互執行，由最初產品組件組合成中間產品組件，再組合成完整的產品。 典型的工作產品 1. 已組合的產品或產品組件。 細部執行方法 1. 確保產品整合環境已準備就緒。 2. 確保正確地執行組合順序。 記錄所有適當的資訊(例如：建構狀態、產品組件的序號、型式及儀器校正日期)。 3. 適當地修訂產品整合順序與可用程序。 SP 評估已組合的產品組件 評估已組合之產品組件的介面相容性。 有關驗證已組合的產品組件，請參考驗證流程領域，以獲得更多資訊。 有關確認已組合的產品組件，請參考確認流程領域，以獲得更多資訊。 本評估包含使用可用的程序與環境，檢查及測試已組合的產品組件之績效、適用性或完成度。評估的執行如同已界定的產品整合順序與可用程序，評估可適當地分階段進行。產品整合順序與可用程序可定義較精煉的整合和評估順序，而非僅為產品架構的檢查。例如：如果某產品組件的組合是由四個較不複雜的產品組件組成，則整合順序未必需要四個組件同時整合及檢查。而是這四個組件可能逐步整合，一次一個，並在每次組合後執行檢查，以確保組合的產品組件符合產品架構中的規格。另一方面，產品整合順序與可用程序被認定為只有最終評估才是最佳的實施方式。 產品整合(PI) 337
CMMI for Development Version 典型的工作產品 1. 異常報告 2. 介面評估報告 3. 產品整合摘要報告 細部執行方法 1. 依據產品整合順序與可用程序，評估已組合的產品組件。 2. 記錄評估結果。 評估結果包含如下： • 整合程序的任何調適要求 • 產品建構的任何變更(備用零件、新品) • 評估程序的偏差 SP 包裝並交付產品或產品組件 包裝已組合的產品或產品組件，並交付給適當的客戶。 有關包裝前驗證產品或產品組件組合，請參考驗證流程領域，以獲得更多資訊。 有關包裝前確認產品或產品組件組合，請參考確認流程領域，以獲得更多資訊。 某些產品的包裝需求，可能說明於規格與驗證準則中，當客戶自行存放及運送產品時，此項尤其重要。在此狀況下，包裝說明可能有環境的範圍及壓力條件的註解。在其他狀況下，下列因素可能較為重要： • 經濟且易於運輸(例如：貨櫃裝貨) • 可說明性(例如：收縮性包裝薄膜) • 拆封的容易與安全性(例如：銳利邊緣、裝訂方式的強度、兒童保護、包裝材質環保、重量) 產品整合(PI) 338
CMMI for Development Version 整合組件所做的調整在工廠中整合產品組件所做的調整，可能與安裝於作業現場時組件調整有所不同。在此狀況下，為客戶而做的產品紀錄簿應予使用，以記載此特定的參數。 典型的工作產品 1. 已包裝的產品或產品組件 2. 交付的文件 細部執行方法 1. 審查需求、設計、產品、驗證結果及文件，以確保影響產品包裝與交付的議題，已被界定與解決。 2. 利用有效的方法，包裝與交付已組合的產品。 軟體工程適用 軟體包裝及交付方法，舉例如下： • 磁帶 • 磁片 • 影印文件 • 光碟 • 其他電子發佈，例如：網際網路 3. 滿足包裝與交付產品的適用需求與標準 需求及標準的例子，包括安全、環境、保全、運輸，以及銷毀。 產品整合(PI) 339
CMMI for Development Version 軟體工程適用 軟體包裝與交付的需求及標準，舉例如下： • 儲存及交付媒體的類型 • 軟體原始及備份版本的保管人 • 必要的文件 • 版權 • 提供的授權 • 軟體安全性 4. 準備產品安裝的運作場所。 準備運作場所，可能是客戶或最終使用者的責任。 5. 交付產品與其相關文件，並確定收到收據。 6. 在運作場所安裝產品，並確定可正確操作。 安裝產品可能是客戶或最終使用者的責任。某些情況下，需要確認可正確操作是極少的(例如：檢查程序)。另有些狀況，已整合產品最後的驗證，是在操作現場執行。 產品整合(PI) 340
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施產品整合流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 僅適用於階段式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行產品整合流程。 詳細說明： 本政策建立組織的期望，以發展產品整合順序、程序與環境、確保產品組件間的介面相容、組合產品組件，以及交付產品與產品組件。 GP 規劃流程 建立並維護執行產品整合流程的計畫。 產品整合(PI) 341
CMMI for Development Version 詳細說明： 執行產品整合流程的計畫，說明在本流程領域中所有特定執行方法，從產品整合的準備一直到最終產品的交付的完整規劃。 GP 提供資源 提供充足的資源，以執行產品整合流程、發展工作產品及提供流程服務。 詳細說明： 產品組件介面的協調，可由外部與內部介面的代表人員所組成的介面管制工作組達成，該工作組可誘導介面需求發展的需要。 組合與交付產品可能需要特殊設備。必要時，將採購或發展產品整合流程領域中活動所需的設備。 其他提供的資源，如下列工具： • 雛型工具 • 分析工具 • 模擬工具 • 介面管理工具 • 組合工具(例如：編譯器、執行檔製作檔、接合工具、釣鉤及固定設備) GP 指派責任 指派產品整合流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援產品整合流程。 產品整合(PI) 342
CMMI for Development Version 詳細說明： • 訓練主題，舉例如下： • 應用領域 • 產品整合程序與準則 • 組織的整合與組合設備 • 組合方法 • 包裝標準 GP 管理建構 將指定的產品整合流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 接收產品組件的驗收文件 • 已檢查組合過的產品與產品組件 • 產品整合順序 • 產品整合程序與準則 • 已更新的介面說明或協議 GP 界定並納入相關的關鍵人員 依計畫界定並納入與產品整合流程相關的關鍵人員。 詳細說明： 從下列人員中選擇相關的關鍵人員：客戶、最終使用者、發展者、生產者、測試人員、供應者、行銷人員、維護人員、銷毀人員，以及其他可能被產品及流程影響或可能影響產品及流程的人。 產品整合(PI) 343
CMMI for Development Version 關鍵人員參與的活動，舉例如下： • 審查介面說明的完整性 • 建立產品整合順序 • 建立產品整合程序與準則 • 組合與交付產品與產品組件 • 評估後，溝通檢查結果 • 溝通新的、有效的產品整合執行方法，讓受影響的人員有機會改善績效。 GP 監控流程 依本流程的執行計畫，監控產品整合流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量及工作產品，舉例如下： • 產品組件整合摘要(例如：產品組件組合規劃與執行，以及發現的例外數目) • 整合評估問題報告的趨勢(例如：問題數量與結案數量) • 整合評估問題報告處理時間(例如：每一問題報告懸而未解決的時間) • 執行特定整合活動的時程 GP 客觀評估遵循程度 依據流程說明、標準及程序，客觀評估產品整合流程的遵循程度，並解決不符合的情況。 產品整合(PI) 344
CMMI for Development Version 詳細說明： 審查的活動，舉例如下： • 建立並維護產品整合順序 • 確保介面相容性 • 組合產品組件與交付產品 審查的工作產品，舉例如下： • 產品整合順序 • 產品整合程序與準則 • 已接收產品組件的驗收文件 • 已組合的產品與產品組件 GP 與上層管理人員審查各狀況 與上層管理人員審查產品整合流程的活動、狀況及結果，並解決問題。 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義產品整合流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行產品整合流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產未來的使用與改善。 產品整合(PI) 345
CMMI for Development Version 詳細說明： 工作產品、度量、度量結果和改善資訊，舉例如下： • 產品組件、例外報告、建構狀態的確認、以及準備程度檢查結果的取得紀錄。 • 產品整合全部發展工作量(實際完成加上預估完成)佔的百分比 • 產品整合過程中，在產品及測試環境所發現的缺失 • 產品整合所產生的問題報告 產品整合(PI) 346
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護產品整合流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定產品整合流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化的流程。 GP 確保持續的流程改善 確保產品整合流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正產品整合流程之缺失與其他問題的根本原因。 產品整合(PI) 347
CMMI for Development Version 專案監控 成熟度第二級的專案管理類流程領域 目的 專案監控(Project Monitoring and Control, PMC)的目的在瞭解專案進度，以便在專案執行績效嚴重偏離專案計畫時，可採取適當的矯正措施。 簡介 文件化的專案計畫是監控各項活動、溝通狀態及採取矯正措施的基礎。專案進度主要決定於工作產品、工作屬性、工作量，以及成本的實際值與規定於里程碑或專案時程之控制階層或分工結構圖(WBS)之規劃值的比較結果。當執行績效重大偏離原訂計畫時，適當的能見度可促使採取及時的矯正措施。如果重大偏離未解決，則會阻礙專案達成目標。 這些執行方法使用「專案計畫」一詞，以代表管制專案的全盤計畫。 當專案實際狀況重大偏離預期值時，適當地採取矯正措施。所採取的矯正措施可能需要重新進行專案規劃，而重新規劃可能包括修訂原計畫、訂定新的協議，或在現行計畫中增加額外的降低活動。 相關流程領域 有關專案計畫，其內容包含如何指定適當的專案監控層級、用於監控專案進度的度量及已知風險，請參考專案規劃流程領域，以獲得更多資訊。 有關度量、分析及記錄資訊的流程，請參考度量與分析流程領域，以獲得更多資訊。 專案監控(PMC) 348
CMMI for Development Version 特定目標及執行方法摘要 SG 1依計畫監控專案 SP 監控專案規劃之各項參數 SP 監控承諾事項 SP 監控專案風險 SP 監控資料管理 SP 監控關鍵人員的參與 SP 進行進度審查 SP 進行里程碑審查 SG 2管理矯正措施直到結案 SP 分析議題 SP 採取矯正措施 SP 管理矯正措施 各目標的特定執行方法 SG 1 依計畫監控專案 依專案計畫監控專案實際執行績效與進度。 SP 監控專案規劃之各項參數 依專案計畫監控專案規劃參數之實際值。 專案規劃參數構成專案進度與執行績效的代表性指標，它包含工作產品與工作項目、成本、工作量、時程等屬性。工作產品與工作項目的屬性包含如規模大小、複雜度、重量、形狀、安裝或功能等。 監控通常包含度量專案規劃參數的實際值、比較實際值與計畫的估計值，以及界定其重大偏離。記錄專案規劃參數的實際值，包含記錄前後相關的資訊，以協助對度量的瞭解。分析重大偏離的影響，以決定須採取之矯正措施是屬於本流程領域的第二個特定目標及其特定執行方法。 專案監控(PMC) 349
CMMI for Development Version 典型的工作產品 1. 專案執行績效的紀錄 2. 重大偏離的紀錄 細部執行方法 1. 依時程表監控專案進度。 進度監控通常包含： • 定期度量活動與里程碑的實際完成度 • 將活動與里程碑的實際完成度，與專案計畫所記載的時程表互相比較 • 界定與專案計畫預估時程表的重大偏差。 2. 監控專案的成本與耗用人力。 耗用人力與成本的監控，通常包括： • 定期度量實際耗用的人力與成本，以及成員指派 • 將實際的投入人力、成本、人員配置與訓練，與專案計畫所記載的估計值與預算互相比較 • 界定與專案計畫之預算的重大偏差 3. 監控工作產品與工作項目的屬性。 有關工作產品與工作項目的屬性，請參考專案規劃流程領域，以獲得更多資訊。 監控工作產品及工作項目之屬性，通常包括： • 定期度量工作產品與工作項目的實際屬性，例如：規模大小或複雜度(及屬性的變更) • 將實際工作產品與工作項目的屬性(含屬性的變更)，與專案計畫所記載的估計值互相比較 • 界定與專案計畫之估計值的重大偏差 4. 監控所提供與使用的資源。 有關規劃的資源，請參考專案規劃流程領域，以獲得更多資訊。 專案監控(PMC) 350
CMMI for Development Version 資源舉例如下： • 實體設施 • 用於設計、製造、測試及操作的電腦、週邊裝置及軟體 • 網路 • 安全環境 • 專案成員 • 流程 5. 監控專案人員的知識與技能。 有關規劃執行專案所需的知識與技能，請參考專案規劃流程領域，以獲得更多資訊。 監控專案人員的知識與技能，通常包括： • 定期度量專案人員知識與技能的獲得狀況 • 將實際獲得的訓練，與專案計畫所記載的互相比較 • 界定與專案計畫之估計值的重大偏差 6. 記錄專案規劃參數的重大偏差。 SP 監控承諾事項 依專案計畫監控所界定的承諾。 典型的工作產品 1. 承諾審查紀錄 細部執行方法 1. 定期審查承諾(包含外部及內部的)。 2. 界定尚未滿足或有重大風險無法滿足的承諾。 3. 記錄承諾審查的結果。 專案監控(PMC) 351
CMMI for Development Version SP 監控專案風險 依專案計畫監控所界定的風險。 有關界定專案風險，請參考專案規劃流程領域，以獲得更多資訊。 有關風險管理活動，請參考風險管理流程領域，以獲得更多資訊。 典型的工作產品 1. 專案風險監控紀錄 細部執行方法 1. 在專案目前情況及環境下，定期審查記載風險的文件。 2. 一旦有新增資訊，修訂風險文件以反應改變。 3. 與相關關鍵人員溝通風險狀態。 風險狀態，舉例如下： • 風險發生機率的改變 • 風險優先順序的改變 SP 監控資料管理 依專案計畫監控專案資料的管理。 有關界定哪些類型的資料應該列管及如何規劃其管理，請參考專案規劃流程領域的「規劃資料管理」特定執行方法，以獲得更多資訊。 專案資料管理計畫一旦訂定，就必須監控資料的管理，以確保管理計畫的完成。 典型的工作產品 1. 資料管理紀錄 專案監控(PMC) 352
CMMI for Development Version 細部執行方法 1. 定期審查資料管理活動，是否依專案計畫所述。 2. 界定與記錄重大議題及其影響。 3. 記錄資料管理活動審查的結果。 SP 監控關鍵人員的參與 依專案計畫監控關鍵人員的參與。 有關界定相關的關鍵人員及規劃他們適當的參與，請參考專案規劃流程領域的「規劃關鍵人員之參與」特定執行方法，以獲得更多資訊。 在專案規劃時，一旦界定關鍵人員，且已指定他們在專案內的參與程度，就必須監控其參與，以確保有適當的互動。 典型的工作產品 1. 關鍵人員參與的紀錄 細部執行方法 1. 定期審查關鍵人員參與的情形。 2. 界定與記錄重大議題及其影響。 3. 記錄關鍵人員參與情形的審查結果。 SP 進行進度審查 定期審查專案的進度、執行績效及議題。 進度審查是對專案的審查，以使關鍵人員瞭解狀況。這些專案審查可能是非正式的審查，且可能未在專案計畫中明確說明。 典型的工作產品 1. 專案審查結果紀錄 專案監控(PMC) 353
CMMI for Development Version 細部執行方法 1. 定期與相關關鍵人員，溝通所指派之活動與工作產品的狀態。 審查人員可適當地包含：管理者、專案成員、客戶、最終使用者、供應商及組織內其他相關關鍵人員。 2. 審查蒐集與分析度量的結果，以控制專案。 有關度量與分析專案績效資料的流程，請參考度量與分析流程領域，以獲得更多資訊。 3. 界定與記錄重大議題以及與專案計畫的偏差。 4. 記錄任何工作產品與流程所界定的變更要求與問題。 有關如何管理變更，請參考建構管理流程領域，以獲得更多資訊。 5. 記錄審查的結果。 6. 追蹤變更要求和問題報告直到結案。 SP 進行里程碑審查 於專案里程碑，審查專案的完成情形及執行結果。 有關里程碑規劃，請參考專案規劃流程領域，以獲得更多資訊。 里程碑審查應在專案規劃時予以規劃，里程碑審查通常是正式的審查。 典型的工作產品 1. 里程碑審查結果紀錄 細部執行方法 1. 在專案時程的重要時間點(如階段的完成)，與相關的關鍵人員進行審查。 專案監控(PMC) 354
CMMI for Development Version 審查人員可適當地包含：管理者、專案成員、客戶、最終使用者、供應商及組織內其他相關關鍵人員。 2. 審查專案的承諾、計畫、狀態及風險。 3. 界定並記錄重大議題及其影響。 4. 記錄審查、行動項目及決策的結果。 5. 追蹤行動項目直到結案。 SG 2 管理矯正措施直到結案 當專案的執行績效或結果重大偏離計畫時，管理矯正措施直到結案。 SP 分析議題 蒐集與分析議題，並決定採取必要的矯正措施以解決議題。 典型的工作產品 1. 需要採取矯正措施的議題清單 細部執行方法 1. 蒐集議題，以備分析之用。 從審查及其他流程的執行，蒐集議題。 蒐集的議題，舉例如下： • 經由執行驗證與確認活動所發現的議題 • 專案計畫估計值中，專案規劃參數的重大偏離 • 尚未滿足的承諾(內部或外部的) • 風險狀態的重大改變 • 資料存取、蒐集、隱私或安全的議題 • 關鍵人員的代表性或參與的議題 2. 分析議題，以決定採取矯正措施的必要性。 專案監控(PMC) 355
CMMI for Development Version 有關矯正措施準則，請參考專案規劃流程領域，以獲得更多資訊。 如果未解決需採取矯正措施的議題，可能妨礙專案達成其目標。 SP 採取矯正措施 對界定的議題，採取矯正措施。 典型的工作產品 1. 矯正措施計畫 細部執行方法 1. 決定並記錄須採取的適當行動，來解決已界定的議題。 當專案計畫需重新規劃時，請參考專案規劃流程領域，以獲得更多資訊。 可能的行動，舉例如下： • 修改工作說明書 • 修改需求 • 修訂估計值與計畫 • 再協商承諾事項 • 增加資源 • 變更流程 • 修訂專案風險 2. 與相關關鍵人員，審查將採取的矯正措施，並取得協議。 3. 協商內部與外部承諾的改變。 SP 管理矯正措施 管理矯正措施直到結案。 專案監控(PMC) 356
CMMI for Development Version 典型的工作產品 1. 矯正措施結果 細部執行方法 1. 監控矯正措施直到完成。 2. 分析矯正措施的結果，以決定矯正措施的有效性。 3. 決定並記錄適當行動，以修正矯正措施與規劃結果的偏離。 採取矯正措施的學習心得，可以作為規劃與風險管理流程的輸入。 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施專案監控流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 GP 建立組織政策 建立並維謢組織政策，以規劃並執行專案監控流程。 專案監控(PMC) 357
CMMI for Development Version 詳細說明： 本政策建立組織的期望，以依專案計畫監控執行績效，當實際執行績效或結果重大偏離原計畫時，管理矯正措施直到結案。 GP 規劃流程 建立並維謢執行專案監控流程的計畫。 詳細說明： 執行專案監控流程的計畫可以是描述於專案規劃流程領域之專案計畫的一部分(或由其引用參考)。 GP 提供資源 提供充足的資源，以執行專案監控流程、發展工作產品及提供流程服務。 詳細說明： 所提供的資源，舉例如下列工具： • 成本追蹤系統 • 工作量報告系統 • 行動項目追蹤系統 • 專案管理與時程管制計畫 GP 指派責任 指派專案監控流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援專案監控流程。 專案監控(PMC) 358
CMMI for Development Version 詳細說明： 訓練主題，舉例如下： • 專案監控 • 風險管理 • 資料管理 GP 管理建構 將指定的專案監控流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 專案時程與其狀態 • 專案度量資料與分析 • 實獲值報告 GP 界定並納入相關的關鍵人員 依計畫界定並納入相關關鍵人員。 詳細說明： 參考表有關一般目標與一般執行方法，以取得更多關於一般執行方法與專案監控流程領域中之監控關鍵人員參與執行方法關係的資訊。 專案監控(PMC) 359
CMMI for Development Version 專案關鍵人員參與的活動，舉例如下： • 依計畫評量專案 • 審查承諾事項及解決議題 • 審查專案風險 • 審查資料管理活動 • 審查專案進度 • 管理矯正措施直到結案 GP 監控流程 依本流程的執行計畫，監控專案監控流程，並採取適當的矯正措施。 詳細說明： 參考表有關一般目標與一般執行方法，以取得更多一般執行方法GP 與專案監控流程領域關係的資訊。 用於監控的度量及工作產品，舉例如下： • 未結案與結案的矯正措施數目 • 每月財務資料蒐集、分析及報告之時程與狀態 • 執行審查的次數及類型 • 審查時程(規劃的與實際的及落後目標日期的對照) • 蒐集分析監控資料的時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估專案監控流程的遵循程度，並解決不符合的情況。 專案監控(PMC) 360
CMMI for Development Version 詳細說明： 審查的活動，舉例如下： • 依專案計畫監控專案績效 • 管理矯正措施直到結案 審查的工作產品，舉例如下： • 專案績效的紀錄 • 專案審查結果 GP 與上層管理人員審查各狀況 與上層管理人員審查專案監控流程的活動、狀況及結果，並解決問題。 僅適用於階段式表述 GG 3 及其執行方法不應用於成熟度第二級評等，但可應用於成熟度第三級和更高級評等。 專案監控(PMC) 361
CMMI for Development Version 僅適用於連續式/階段式表述第3-5級 GG 3 制度化已定義流程 將流程制度化為已定義流程。 GP 建立已定義流程 建立並維護已定義專案監控流程的說明。 GP 蒐集改善資訊 蒐集由規劃並執行專案監控流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 詳細說明： 工作產品、度量、度量結果與改善資訊，舉例如下： • 重大偏差的紀錄 • 構成偏差的準則 • 矯正措施的結果 專案監控(PMC) 362
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護專案監控流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定專案監控流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保專案監控流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正專案監控流程之缺失與其他問題的根本原因。 專案監控(PMC) 363
CMMI for Development Version 專案規劃 成熟度第二級的專案管理類流程領域 目的 專案規劃(Project Planning, PP)的目的，在建立並維護用以定義專案活動的計畫。 簡介 專案規劃流程領域包括： • 發展專案計畫 • 與關鍵人員適當的互動 • 取得對計畫的承諾 • 維護專案計畫 規劃開始於用以定義產品與專案的需求。 規劃包括：估計工作產品及工作項目之屬性、決定資源需求、協商承諾、產生時程，以及界定和分析專案風險。訂定專案計畫可能需要反覆上述活動。專案計畫提供執行及控制專案活動的基礎，以完成對專案客戶的承諾。 專案進行時，專案計畫常因下列情況而須修訂：需求及承諾變更、不準確的估計、矯正措施及流程變更。說明規劃及重新規劃的特定執行方法，包含在本流程領域之內。 在本流程領域的一般與特定執行方法中，全部使用「專案計畫」這個術語，來描述控制專案的全盤計畫。 專案規劃(PP) 364
CMMI for Development Version 相關流程領域 有關產品及其組件之需求發展，請參考需求發展流程領域，以獲得更多資訊。產品及產品組件之需求與需求變更，是規劃及重新規劃之基礎。 有關規劃及重新規劃所需的管理需求，請參考需求管理流程領域，以獲得更多資訊。 有關風險界定與管理，請參考風險管理流程領域，以獲得更多資訊。 有關把需求轉成產品及其組件解決方案，請參考技術解決方案流程領域，以獲得更多資訊。 專案規劃(PP) 365
CMMI for Development Version 特定目標及執行方法摘要 SG 1建立估計值 SP 估計專案範圍 SP 建立工作產品與工作項目屬性的估計值 SP 定義專案生命週期 SP 決定工作量與成本的估計值 SG 2發展專案計畫 SP 建立預算和時程 SP 界定專案風險 SP 規劃資料管理 SP 規劃專案資源 SP 規劃所需知識和技能 SP 規劃關鍵人員之參與 SP 建立專案計畫 SG 3取得對計畫的承諾 SP 審查影響專案的各種計畫 SP 調整工作和資源水準 SP 取得計畫承諾 各目標的特定執行方法 SG 1 建立估計值 建立並維護專案規劃參數的估計值。 專案規劃參數包括專案從事下列活動所需之所有資訊：規劃、組織、用人、督導、協調、報告及預算。 規劃參數之估計值應有可信賴的基礎，以逐漸建立信心，使得任何以此估計值為基礎所做的計畫，都有能力支援專案目標。 估計這些參數值時，通常考慮的因素舉例如下： 專案規劃(PP) 366
CMMI for Development Version • 專案需求，包括產品需求、組織需求、客戶需求及可影響專案的其他需求 • 專案範圍 • 已界定之工作項目及工作產品 • 技術方法 • 已選定的專案生命週期模式(例如：瀑布式、漸進式、螺旋式等) • 工作產品與工作項目的屬性(例如：規模大小或複雜度) • 時程 • 把工作產品與工作項目屬性轉換成投入工時與成本的模式或歷史性資料 • 決定所需材料、技能、工時及成本的方法(模式、資料、演算法) 為了關鍵人員對專案計畫的審查與承諾，以及在專案執行過程中維護專案計畫，記錄估計理由與支援性的資料是必要的。 SP 估計專案範圍 建立高階的分工結構圖(WBS)，以估計專案的範圍。 分工結構圖隨專案進行而漸進發展。初始期的最高階WBS用於初期估計。發展WBS時，把整個專案分成一組可管理之相互連結的組件。WBS通常是產品導向的結構，提供一種綱要結構，以識別與安排工作管理的邏輯單元，該邏輯單元稱之為「工作包(work packages)」。通常，WBS提供工作指派、時程安排及權責的參考與組織的機制，並做為規劃、安排及管制專案工作的基本架構。 有些專案會使用「合約WBS」一詞，以代表合約中的WBS(可能是整個的WBS)。並非所有的專案都會有「合約WBS」(例如公司內部資助的發展案)。 專案規劃(PP) 367
CMMI for Development Version 典型的工作產品 1. 工作項目描述 2. 工作包描述 3. 分工結構圖 細部執行方法 1. 以產品架構為基礎，發展分工結構圖。 分工結構圖提供綱要結構以安排專案工作，該工作環繞所支援的產品。分工結構圖應確認下列事項： • 界定風險與風險降低工作 • 專案交付項目，及支援活動所需的工作 • 為了獲得技能與知識的工作項目 • 發展工作所必須的支援計畫，如：建構管理、品質保證及驗證等計畫 • 非發展類項目的整合與管理工作 2. 界定工作包，須詳細到足以估計專案工作項目、責任及時程。 在工作項目及組織角色與責任方面，最高階的WBS用來協助度量專案工作量。至於細節則描述於更低階的WBS，有助於發展實際可行的時程計畫，從而減少預留管理空間之需要。 3. 界定會從外部取得的工作產品(或者是工作產品的組件)。 有關從專案外部來源獲得工作產品，請參考供應商協議管理流程領域，以獲得更多資訊。 4. 界定將再使用的工作產品。 SP 建立工作產品與工作項目屬性的估計值 建立並維護工作產品與工作項目屬性的估計值。 專案規劃(PP) 368
CMMI for Development Version 規模大小是許多模式用來估計工作量、成本及時程的主要輸入。這些模式也可根據連結、複雜度及結構做為輸入的基礎。 規模大小估計的工作產品種類，舉例如下： • 交付類及非交付類工作產品 • 文件與檔案 • 可運作及支援的硬體、刃體和軟體 規模大小之度量方式，舉例如下： • 功能數 • 功能點 • 原始碼行數(SLOC) • 類別(Class)與物件(Object)數量 • 需求數 • 介面的數目與複雜度 • 文件頁數 • 輸出及輸入數 • 技術風險項目數量 • 資料數量 • 積體電路邏輯閘的數目 • 零件的數目(例如以洗好的電路板、組件與機械零件) • 物理限制(例如重量與容量) 這些估計值應與專案需求一致，俾決定專案之工作量、成本及時程。每個規模大小屬性，均應指定一個相對困難度與複雜度的等級。 典型的工作產品 1. 技術方法 專案規劃(PP) 369
CMMI for Development Version 2. 工作項目及工作產品的規模大小及複雜度 3. 估計模型 4. 屬性估計值 細部執行方法 1. 決定專案的技術方法。 技術方法決定產品發展的高階策略。它包括架構特性的決策，例如採用分散式或主從式架構；應用最先進的技術或較成熟的技術，例如機器人、複合材料、或人工智慧；以及對產品更廣泛的功能期望，例如安全性、機密性及人體工學等方面的需要。 2. 使用適當方法決定工作產品及工作項目之屬性，以估計資源需求。 決定規模大小及複雜度的方式，應以經過確認之模式或歷史資料為基礎。 我們對產品特性與屬性的關係瞭解越多，決定屬性的方法也將隨之漸進發展。 現行方法，舉例如下： • 用於IC設計的邏輯閘數目 • 用於軟體的LOC或功能點數 • 用於系統工程的需求數量/複雜度 • 用於標準住宅的平方呎數 3. 估計工作產品及工作項目之屬性。 SP 定義專案生命週期 定義專案生命週期階段，並據此建立規劃工作的範圍。 決定專案生命週期的階段，為評估與決策之規劃階段作準備。這通常與資源及技術方法重大承諾的合 專案規劃(PP) 370
CMMI for Development Version 理決策點有關。這樣的決策點在修訂專案方向與決定未來工作範圍與成本上，提供可達成的計畫結果。 專案生命週期各階段的定義，有賴於需求的範圍，專案資源的估計，以及專案的本質。較大型的專案可能包含多個階段，例如觀念探索、發展、製造、操作與配置。在這些階段中，可能會需要子階段。發展階段可能包含的子階段有需求分析、設計、製造整合與驗證。軟體專案階段之決定，通常包含軟體發展模式的選擇與改進，以說明專案活動間的相互關係與適當次序。 根據發展策略，也可能還需要有下列中間階段：雛型製作、功能漸進或螺旋模式週期。 瞭解專案生命週期對下列工作是必要的：決定規劃工作的範圍、決定開始規劃的時機及決定計畫修訂之時機與準則(關鍵里程碑)。 典型的工作產品 1. 專案生命週期階段 SP 決定工作量與成本的估計值 依據估計理由，估計工作產品和工作項目所需之專案工作量和成本。 工作量及成本的估計值，通常根據模式分析的結果，或應用於規模大小、活動及其他規劃參數的歷史資料而來。對這些估計值之信心，是來自估計模式的邏輯原理及歷史資料的本質。有時候歷史資料不適用，例如工作欠缺前例或工作項目類型與模式不合。所謂工作欠缺前例(在某種程度)，是指以前從未有人做過相似的產品或組件，或是發展小組以前從未做過。 欠缺前例的工作風險通常較大，必須多做一些研究以便建立合理的估計基準，通常在管理上也須多預留一些空間。當使用這些模式時，必須記錄專案的專案規劃(PP) 371
CMMI for Development Version 獨特性，以確保在初始規劃階段所做的假設均達成共識。 典型的工作產品 1. 估計理由 2. 專案工作量估計值 3. 專案成本估計值 細部執行方法 1. 蒐集估計模式或歷史資料，俾用於將工作產品及工作項目的屬性，轉換成工時及成本的估計值。 在軟體工程領域，已發展出許多參數化模式，以協助估計成本及時程。並不建議只使用這些模式作為估計的單一來源，因為它們所依據的歷史專案資料，可能並不適合你的專案。使用多種估計模式及(或)多種估計方法可以確保估計上的高度信心。 來自於先前執行專案的歷史資料，包括成本、工作量及時程，以及考慮不同專案規模及複雜度的調整因素。 2. 估計工作量及成本時，應納入支援基礎環境所需的項目。 支援的基礎環境包含從產品發展及維護的觀點所反映的資源需求。 在評估人力與成本時，應考慮在開發環境、測試環境、製造環境、用戶終端環境，以及上述任何組合所需的內在基礎資源。 專案規劃(PP) 372
CMMI for Development Version 內在基礎資源包含如下： • 重要的電腦資源(例如：硬碟及網路容量) • 開發環境與工具(如雛型工具、裝配、電腦輔助設計與模擬) • 設施、機械與設備(如測試平台與記錄的儀器) 3. 用估計模式及(或)歷史資料，估計所需工作量及成本。 用來估計工作量及成本的輸入，通常包括： • 專家(群)所提供的判斷估計(例如：Delphi預估法) • 風險因素，包括工作欠缺前例的影響程度 • 執行工作所需之核心能力與關鍵角色 • 產品與產品組件需求 • 技術方法 • 分工結構圖 • 工作產品與預期變更之規模大小估計 • 對外採購工作產品之成本 • 已選定之專案生命週期模式與流程 • 生命週期成本估計 • 在工程環境下的工具提供能力 • 執行工作的管理人員與幕僚人員之技能水準 • 所需知識、技能和訓練 • 所需設施(例如：辦公室、會議室及工作站) • 所需工程設施 • 製程能力 • 差旅 • 工作項目、工作產品、硬體、軟體、人員及工作環境之安全程度 • 客服中心及產品保證之服務等級協議 • 直接人工與間接費用 專案規劃(PP) 373
CMMI for Development Version SG 2 發展專案計畫 建立並維護專案計畫，以做為管理專案的基準。 專案計畫以專案需求及已建立的估計值為基礎，是用來管控專案執行的正式核定文件。 專案計畫應考慮所有專案生命週期的各階段。專案規劃時應確保所有影響專案的計畫與主計畫之間的一致性。 SP 建立預算與時程 建立並維護專案預算與時程。 專案預算及時程，要依據已發展的估計值來安排，並確保預算分配、工作複雜度、工作項目的依存關係均已適當考量。 事件驅動且有資源限制的時程安排，已被證明能有效處理專案風險。若工作開始之前，就清楚界定完成時將要展示的成果，則有下述好處：提供事件處理的時間彈性、對預期成果的共識、較佳的專案狀態願景，以及較精確的專案工作項目狀況掌握。 典型的工作產品 1. 專案時程表 2. 時程相依關係 3. 專案預算 細部執行方法 1. 界定重要的里程碑。 里程碑用來協助確定交付項目能如期完成。里程碑可以事件或日期為基準。若以日期為基準，一旦決定日期就很難更改。 2. 界定時程安排的假設前題。 當開始發展時程時，通常需要假設某些活動的期程。這些假設通常涉及一些缺少估計資料的工作 專案規劃(PP) 374
CMMI for Development Version 項目。界定這些假設前題，可提供對全程之信心程度(不確定性)的洞察力。 3. 界定限制條件。 應儘早界定影響管理方案彈性的限制因素。檢驗工作產品與工作項目的屬性，常會促使這些因素浮現。這些屬性可包括：工作項目之工期、資源需求、輸入及輸出。 4. 界定工作項目的相依關係。 專案工作項目若依某一次序進行，通常可縮短完工時間。這需要先界定工作項目的先後順序，以決定最佳的次序。 可用於決定工作項目最佳次序的工具，舉例如下： • 關鍵路徑法(CPM) • 計畫評核術(PERT) • 資源限制排程法 5. 定義預算與時程。 建立並維護專案預算及時程通常包括下列事項： • 定義資源與設施已承諾或已預期的可用時段 • 決定專案活動的時間階段 • 決定附屬時程的分類 • 定義專案活動間的相依關係(先後順序關係) • 定義支援精確進度度量所需的排程活動及里程碑 • 界定交付客戶產品的里程碑 • 定義適當工期的專案活動 • 定義適當時間間隔的里程碑 • 根據滿足時程與預算要求之信心度，定義管理上需預留的空間 專案規劃(PP) 375
CMMI for Development Version • 用適當的歷史資料來驗證時程 • 定義漸增的經費需求 • 記錄專案的假設與理由 6. 建立矯正措施準則。 建立構成嚴重偏離專案計畫的判斷準則。度量的議題與問題對決定何時採取矯正措施十分重要。矯正措施可能需要重新規畫，重新規畫包括修訂原計畫、建立新協議，或減少目前計畫內的活動。 SP 界定專案風險 界定並分析專案風險。 有關風險管理活動，請參考風險管理流程領域，以獲得更多資訊。 有關風險監測活動，請參考專案監控流程領域的特定執行方法，以獲得更多資訊。 須界定或發現風險，並進行分析以支援專案規劃。本特定執行方法必須延伸到影響專案的所有計畫，以確保與所界定之風險相關的相關關鍵人員之間的介面，已有適當的安排。專案規劃風險的界定與分析，通常包括下列各項： • 界定風險 • 分析風險以決定其影響程度、發生機率及可能發生問題的時間點 • 排列風險的優先順序 典型的工作產品 1. 已界定的風險項目 2. 風險的影響程度及發生機率 3. 風險的優先順序 細部執行方法 1. 界定風險。 專案規劃(PP) 376
CMMI for Development Version 風險界定包括界定會負面影響工作成果與計畫的各種潛在問題、危險、威脅及弱點。在分析風險之前，必須先以容易瞭解的方式，界定及描述風險。界定風險時，最好能採用定義風險的標準方法。可使用風險界定及分析工具，以協助界定可能的問題。 風險界定及分析工具，舉例如下： • 風險分類 • 風險評量 • 查核表 • 結構化訪談 • 腦力激盪 • 績效模式 • 成本模式 • 網路分析 • 品質因素分析 2. 記錄風險。 3. 與相關的關鍵人員審查已記錄風險之完整性與正確性，並取得其同意。 4. 適當地修訂風險。 已界定的風險須要修訂的情況，舉例如下： • 新風險已被界定 • 當風險變成問題 • 風險已消失 • 專案環境有大幅變動 SP 規劃資料管理 規劃專案資料的管理。 專案規劃(PP) 377
CMMI for Development Version IPPD補充 當整合團隊由多個小組所組成時，專案資料包括單一小組或跨小組所使用或發展的資料。 資料是多種型式的文件，用以支援計畫的全部領域(例如：行政管理、工程、建構管理、財務、後勤、品質、安全、製造及採購)。資料可能有多種型式(例如：報告、手冊、筆記、圖表、規格書、檔案或往來書函)。資料可存放於各種媒體(例如：不同材質的印刷本或繪圖本、照片、電子媒體或多媒體)。資料可能是交付項目(例如列於合約中的項目)，或是非交付項目(例如：非正式資料、市場研究及分析資料、內部會議紀錄、內部設計審查文件、學習心得及行動資料)。資料分送方式也有多種方式，包括可用電子方式傳送。 專案資料需求，應就資料項目的格式與內容，按共通或標準的資料需求來建立。統一的資料項目內容及格式，使資料內容更容易瞭解，亦有助於資料資源的一致性管理。 蒐集每份文件的理由必須要很清楚。這工作包括分析和驗證專案交付及非交付項目、合約及非合約資料需求，以及客戶提供的資料。資料蒐集時，經常沒有清楚的瞭解將如何使用該資料，蒐集資料的成本很高，應該只在需要時才蒐集。 典型的工作產品 1. 資料管理計畫 2. 列管資料總表 3. 資料內容及格式描述 4. 對使用者與供應者的資料需求清單 5. 隱私需求 6. 安全需求 專案規劃(PP) 378
CMMI for Development Version 7. 安全程序 8. 資料檢索、複製及分發機制 9. 專案資料的蒐集時程 10. 待蒐集的專案資料清單 細部執行方法 1. 建立確保資料的隱私與安全的需求及程序。 並非每個人都有取用專案資料的需要或權限。必須建立程序，以界定什麼人可在什麼時候取用什麼資料。 2. 建立將資料存檔及取用已存檔資料的機制。 取用的資訊應該以容易瞭解的型式(例如：電子型式或從資料庫的電腦輸出)表達，或以其原始建立的型式表達。 3. 決定待界定、蒐集及分發的專案資料。 SP 規劃專案資源 規劃執行專案所需之必要資源。 IPPD補充 組成整合團隊時，專案資源規劃應考慮整合團隊的用人需求。 按照估計初始值，定義專案資源(人工、機器/設備、材料及方法)及執行專案活動的資源需求數量。同時也提供更多的資訊，以展開用來管理專案的分工結構圖。 先前發展的高階WBS (當作估計機制)，通常藉由將高階WBS分解為代表單一工作單元的工作包而展開，工作包可分別指派、執行及追蹤。如此細分能分配管理責任，並提供較好的管理控制。分工結構圖的每一工作包或工作產品，應指定唯一的識別符專案規劃(PP) 379
CMMI for Development Version 號(例如：數字)以便追蹤。WBS可按需求、專案活動、工作產品或上述的任意組合而建立。配合WBS，建立每一工作包工作描述的說明書。 典型的工作產品 1. WBS工作包 2. WBS工作說明書 3. 依專案規模大小及範圍的用人需求 4. 關鍵設施/設備表 5. 流程/工作流程的定義及圖表 6. 計畫行政管理需求表 細部執行方法 1. 決定流程需求。 必須界定、定義用以管理專案的流程，並與所有關鍵人員協調，以確保專案執行期間能有效率的操作。 2. 決定用人需求。 專案的用人應依WBS的工作包來安排。工作包的分割是從達成專案需求著眼，將需求分做工作項目、執行角色及責任做考量。 用人需求必須考慮每個職位所需的知識與技能，如「規劃所需知識和技能」特定執行方法所述。 3. 決定設施、設備及組件需求。 就某些意義來說，多數專案都是獨一無二的，因此需要某些獨特的資產，以完成專案目標。及時決定並取得這些資產，對專案成功極為重要。 需及早界定有生產前置時間的項目，以決定如何處理。即使所需資產不是獨特的，蒐集一份包括全部設施、設備及零件(例如：專案成員工作所 專案規劃(PP) 380
CMMI for Development Version 需的電腦數目、應用軟體、辦公空間等等)的清單，可提供常被忽視的工作範圍方面的洞察力。 SP 規劃所需知識和技能 規劃執行專案所需之知識與技能。 有關將知識與技能的資訊併入專案計畫，請參考組織訓練流程領域，以獲得更多資訊。 將知識導入專案，包含專案成員的訓練以及從外界獲取知識。 用人需求必須根據執行專案所需之知識與技能而定。 典型的工作產品 1. 技能需求的詳細記載 2. 用人及聘僱新人計畫 3. 資料庫(例如：技能及訓練) 細部執行方法 1. 界定執行專案所需的知識與技能。 2. 評量可用的知識與技能。 3. 選擇提供所需知識與技能的機制。 機制舉例如下： • 內部訓練(公司與專案) • 外部訓練 • 用人及聘僱新人 • 向外採購所需技能 要選擇以內部訓練或外部採購來取得所需知識與技能，應依公司內的訓練能力、專案時程及經營目標來決定。 專案規劃(PP) 381
CMMI for Development Version 4. 將選定的機制併入專案計畫。 SP 規劃關鍵人員之參與 規劃已界定的關鍵人員之參與。 IPPD補充 組成整合團隊時，對關鍵人員參與的規劃應深入到整合團隊層級。 藉由界定專案代表的人員類型與功能需要，以及描述他們在特定專案活動的關聯和互動程度，來界定專案生命週期各階段的關鍵人員。製作關鍵人員和專案活動的二維矩陣對照表以實現關聯是很方便的形式。矩陣的每一格(即每一縱橫座標交叉點)，即可用來描述某一關鍵人員，在某特定活動中的關係和被期望參與該活動的角色與份量。 要讓關鍵人員的參與發揮效用，必須慎選相關的關鍵人員。專案每個主要活動，都應界定出會受該活動影響的關鍵人員，以及有專案技術來引導該活動的關鍵人員。相關關鍵人員的名單應隨專案生命週期階段而調整。先期的專案工作(如需求和設計決策)會影響到後期工作，故應確保列名於專案後期生命週期階段的相關關鍵人員，能及早表達對影響他們的需求與設計決策的意見。 專案規劃(PP) 382
CMMI for Development Version 關鍵人員互動計畫應包括的內容，舉例如下： • 相關關鍵人員名單 • 關鍵人員參與的理由 • 專案生命週期各階段中相關關鍵人員的角色與責任 • 關鍵人員間的關係 • 專案生命週期各階段中關鍵人員對專案成功的重要性 • 所需的資源(例如：訓練、材料、時間、經費)，以確保關鍵人員的互動 • 關鍵人員分階段互動的時程 本特定執行方法之實施與前述「規劃所需知識與技能」執行方法應相互分享或交換相關資訊。 典型的工作產品 1. 關鍵人員參與計畫 SP 建立專案計畫 建立並維護全盤的專案計畫內容。 在說明所有相關規劃項目，以取得所有要執行該計畫的個人、團體、組織的相互了解、承諾、及執行時，一份書面計畫是必要的。專案的計畫，以邏輯的方式定義了所有層面的人力；專案生命週期的考量；技術及管理工作；預算與時程；里程碑；資料管理、風險界定、資源與技術的需求；以及關鍵人員的界定和互動。基礎架構的描述包含有專案成員間責任與授權的關係、管理階層以及組織的支援。 軟體工程適用 軟體的規劃文件通常為下列之一： • 軟體發展計畫 專案規劃(PP) 383
CMMI for Development Version • 軟體專案計畫 • 軟體計畫 硬體工程適用 對於硬體，規劃文件通常是只硬體發展計畫。製造準備時的發展活動，可能包含在發展計畫或定義在不同的製造計畫。 用於美國國防部的計劃範例包含如下： • 整合主計畫-一份事件驅動式的計畫，記錄重要的產出，以及該產出在專案的營運及技術方面上的成功/失敗準則，並將各產出與關鍵事件相結合。 • 整合主時程-整合網路是多層次的計畫工作時程，用以完成記錄檔整合主計畫的工作人力。 • 系統工程管理計畫-詳細說明專案中整合技術人力的計畫。 • 系統工程主時程-事件導向的時程，包含了所有有技術上的關鍵產出，每個產出都要有可度量的準則，要能成功的實現，以通過所界定的事件。 • 系統工程詳細時程-詳細的與時間相關工作項目導向的時程，用以說明系統工程主時程中的特定日期與里程碑。 滿足相關規劃事項的計畫文件，對執行及支援該計畫之個人、團隊及組織，必須達成共同的瞭解、承諾及執行。專案計畫須以邏輯的方式定義所有的工作面向：專案生命週期考量、技術及管理工作項目、預算及時程、里程碑、資料管理、風險界定、資源及技能需求，以及關鍵人員的界定與互動。基本環境的描述應包括專案成員、管理人員及支援單位間的權責關係。 專案規劃(PP) 384
CMMI for Development Version 典型的工作產品 1. 全盤專案計畫 SG 3 取得對計畫的承諾 建立並維護對專案計畫的承諾。 計畫必須獲得負責執行及支援人員的承諾才生效。 SP 審查影響專案的各種計畫 審查影響專案的所有計畫，以瞭解專案承諾。 IPPD補充 當整合團隊組成時，其整合工作計畫均屬須審查的計畫。 其他流程領域所發展的計畫，通常包括與全盤專案計畫同類的資訊。這些計畫可能提供額外且詳細的指引，應配合與支持全盤專案計畫，以指出權責與管制的人。影響專案的所有計畫應予審查，以確保達成使專案成功所需的範圍、目標、角色及關係的共識。很多影響專案的計畫描述於每個流程領域之規劃流程的一般執行方法中。 典型的工作產品 1. 影響專案計畫的審查紀錄 SP 調整工作和資源水準 調整專案計畫，以反映可用的資源與預估的資源。 IPPD補充 當整合團隊組成時，若各整合小組分散於多處，或有人同時參與一個或多個專案的多個整合團隊，要特別注意資源承諾問題。 專案規劃(PP) 385
CMMI for Development Version 為使所建立的專案是可行的，獲取相關的關鍵人員的承諾，以及調整預估與實際可用資源之間的差距是重要的。調整的方式通常包括：降低或延後技術效能的需求、爭取更多資源、找尋增進生產力的方法、委外、調整專案人員的技能組合、修訂影響專案的所有計畫或時程表。 典型的工作產品 1. 已修訂的方法與對應的預估參數 (例如：較好的工具、使用現成品組件) 2. 重新協商的預算 3. 已修訂的時程 4. 已修訂的需求表 5. 重新協商的關鍵人員協議 SP 取得計畫承諾 從負責執行與支援計畫之相關關鍵人員取得承諾。 IPPD 補充 整合團隊組成時，整合團隊計畫必須被團隊成員、其他介面團隊、全專案及團隊所選以調適應用標準流程的負責人所接受。 取得承諾涉及所有專案內外部相關關鍵人員之間的互動。做了承諾的個人及小組應有信心在預定之成本、時程及執行的限制條件下完成工作。通常先做一個暫時性的承諾較為適當，以容許工作啟動，並進行相關研究，當增加信心至適當程度，需要得到充分的承諾。 典型的工作產品 1. 承諾要求紀錄 2. 承諾紀錄 專案規劃(PP) 386
CMMI for Development Version 細部執行方法 1. 界定所需支援，並與相關關鍵人員協商承諾。 可用WBS為檢查表，以確保所有工作項目都獲得承諾。 關鍵人員互動計畫應界定所有取得承諾之對象。 2. 記錄所有組織的承諾，包括完整的及臨時的，並確保由適當層級的人員簽署。 承諾須文件化，以確保一致的相互瞭解，並可追蹤及維護。臨時性的承諾應附有相互關係的風險描述。 3. 適時與資深管理人員一起審查內部承諾。 4. 適時與資深管理人員一起審查外部承諾。 管理者可能具有必要的洞察力及權威，以降低與外部承諾相關聯的風險。 5. 界定專案內、專案間及組織單位間各元件的介面承諾，以利監督。 定義良好的介面規格是承諾的基礎。 專案規劃(PP) 387
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施專案規劃流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 GP 建立組織政策 建立並維護組織政策，以規劃和執行專案規劃流程。 詳細說明： 本政策建立組織的期望，以規劃參數估算、安排內外部承諾、發展管理專案的計畫。 GP 規劃流程 建立並維護執行專案規劃流程的計畫。 詳細說明： 參考表一般執行方法與流程領域關係已取得更多關於一般執行方法和專案規畫流程領域的資訊。 專案規劃(PP) 388
CMMI for Development Version GP 提供資源 提供充足的資源，以執行專案規劃流程、發展工作產品及提供流程服務。 詳細說明： 專案規劃時，可能需要特殊專業能力、設備及設施。在專案規劃時所需的特殊專業能力，舉例如下: • 有經驗的估計人員 • 排程人員 • 特定領域專家(例如: 產品專業及技術) 其他資源提供的工具，舉例如下： • 試算表程式 • 估計模式 • 專案規劃及排程軟體 GP 指派責任 指派專案規劃流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援專案規劃流程。 專案規劃(PP) 389
CMMI for Development Version 詳細說明： 訓練主題，舉例如下： • 估計 • 預算 • 談判 • 風險界定及分析 • 資料管理 • 規劃 • 排程 GP 管理建構 將指定的專案規劃流程工作產品，納入適當層級的控制。 詳細說明： 應置於控制的工作產品，舉例如下： • 分工結構圖(WBS) • 專案計畫 • 資料管理計畫 • 關鍵人員參與計畫 GP 界定並納入相關的關鍵人員 依計畫界定並納入專案規劃流程相關的關鍵人員。 詳細說明： 參考表一般執行方法與流程領域關係，以取得更多關於一般執行方法以及在專案規畫流程領域中規劃關鍵人員參與此一執行方向間的資訊。 專案規劃(PP) 390
CMMI for Development Version 關鍵人員參與的活動，舉例如下： • 建立估計值 • 審查並處理專案風險有關之完整性與正確性 • 審查資料管理計畫 • 制定專案計畫 • 審查專案計畫並處理工作及資源議題 GP 監控流程 依本流程的執行計畫，監控專案規劃流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量，舉例如下： • 計畫修訂次數 • 各次計畫修訂之成本、時程及工作量之差異 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估專案規劃流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 建立估計值 • 發展專案計畫 • 取得對專案計畫的承諾 專案規劃(PP) 391
CMMI for Development Version 審查的工作產品，舉例如下: • 分工結構圖 • 專案計畫 • 資料管理計畫 • 關鍵人員參與計畫 GP 與上層管理人員審查各狀況 與上層管理人員審查專案規劃流程的活動、狀況及結果，並解決問題。 僅適用於階段式表述 GG 3 和其他執行方法不採行於成熟度第二級評等，但對於成熟度第三級和更高及評等而言，是採行的。 專案規劃(PP) 392
CMMI for Development Version 僅適用於連續式/成熟度第3-5級 GG 3 制度化已定義流程 將流程制度化為已定義流程。 GP 建立已定義流程 建立並維護已定義專案規劃流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行專案規劃流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 詳細說明： 工作產品、度量、度量結果與改善資訊的範例包括下列： • 專案資料館結構 • 專案屬性估計 • 風險發生的影響與機率 專案規劃(PP) 393
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護專案規劃流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定專案規劃流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保專案規劃流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正專案規劃流程之缺失與其他問題的根本原因。 專案規劃(PP) 394
CMMI for Development Version 流程與產品品質保證 成熟度第二級的支援類流程領域 目的 流程與產品品質保證的目的，在提供成員與管理階層客觀洞察流程與相關工作產品。 簡介 流程與產品品質保證流程領域包括： • 依據適用的流程說明、標準及程序，客觀評估所執行的流程、工作產品及服務 • 界定並記錄不符合的議題 • 對專案成員與管理人員，提供品質保證活動結果的回饋 • 確保不符合議題已經處理 流程與產品品質保證流程領域藉由提供專案成員和各階層的管理人員，對於專案生命週期中的流程和工作產品提供適當的能見度和回饋，以支援交付高品質的產品和服務。 流程與產品品質保證流程領域的執行方法可確保實行所規劃的流程，而驗證流程領域的執行方法則確保滿足特定的需求。這兩個流程領域可從不同的觀點檢視同樣的工作產品，專案應注意將投入的重複性降到最低。 流程與產品品質保證評估的客觀性，是專案成功的關鍵(「客觀評估」的定義，詳見詞彙)。客觀性可藉由獨立與使用準則來達成。由未參與生產工作產品的人，依據準則進行評估，經常混合使用不同的方法、較不正式的方法，可用於涵蓋日常的活動，較正式的方法，則週期性的使用以確保客觀性。 流程與產品品質保證(PPQA) 395
CMMI for Development Version 執行客觀評估的方法包含如下： • 由獨立的品質保證組執行的正式稽核 • 執行不同形式的同仁審查 • 深入的實地審查(辦公桌稽核) • 工作產品分散式的審查和評論 傳統上，為了提供客觀性，品質保證組常獨立於專案之外。但對於某些組織而言，在並非獨立的狀況下實施流程與產品品質保證，可能也很適合。例如：在一個具有開放、品質導向文化的組織，流程與產品品質保證的角色由同仁部分或全部擔任，且品質保證功能可能植入於流程之中。對小型組織而言，這可能是最可行的方法。 如果品質保證功能植入於流程中，必須處理下列幾個議題以確保客觀性。執行品質保證活動的每個人必須接受品質保證訓練。執行工作產品品質保證活動的人員，應該與直接參與發展與維護工作產品的人員有所區隔。品質保證人員必須有獨立的報告管道，以對組織適當管理層級報告，必要時讓不符合的議題向上反應。 例如：以同仁審查做為執行客觀評估的方法： • 參加同仁審查的人要接受訓練並被指派角色。 • 指派未參與生產工作產品的同仁審查成員，擔任QA的角色。 • 已具有支援品保活動的檢核表。 • 缺失會成為同仁審查報告的一部份，且加以追蹤，並於必要時提升到專案之上的層次。 品質保證工作應開始於專案建立的初期，參與建立專案的計畫、流程、標準及程序，為專案增加價值，並滿足專案和組織政策的需求。執行品質保證的人員參與建立計畫、流程、標準及程序，可確保 流程與產品品質保證(PPQA) 396
CMMI for Development Version 符合專案的需要，在執行品質保證評估時，也相當有用。此外，需指定專案將進行評估的特定流程及相關工作產品。此項指定以抽樣或客觀準則為基礎，而且與組織政策、專案需求及需要相符合。 當界定不符合議題時，盡可能先在專案內處理與解決，無法在專案內解決的不符合議題，需提升到適當的管理階層解決。 本流程領域主要用於評估專案的活動和工作產品，但它也用於評估非專案活動和工作產品，例如：訓練活動。對於這些活動和工作產品，「專案」這個術語，應予適當的解釋。 相關流程領域 有關界定需要客觀評估的流程和相關工作產品，請參考專案規劃流程領域，以獲得更多資訊。 有關滿足特定需求，請參考驗證流程領域，以獲得更多資訊。 流程與產品品質保證(PPQA) 397
CMMI for Development Version 特定目標及執行方法摘要 SG 1客觀評估流程與工作產品 SP 客觀評估流程 SP 客觀評估工作產品及服務 SG 2提供客觀的洞察力 SP 溝通並確保解決不符合的議題 SP 建立紀錄 各目標的特定執行方法 SG 1 客觀評估流程與工作產品 客觀評估執行的流程、相關的工作產品及服務，對適用的流程說明、標準及程序的遵循程度。 SP 客觀評估流程 根據適用的流程說明、標準及程序，客觀評估所指定的執行流程。 品質保證評估的客觀性是專案成功的關鍵。須定義品質保證報告的管道及如何確保客觀性。 典型的工作產品 1. 評估報告 2. 不符合的報告 3. 矯正措施 細部執行方法 1. 提倡鼓勵員工參與界定並報告品質議題的環境(建立該環境成為專案管理的一部分)。 2. 建立並維護明確陳述的評估準則。 本細部執行方法的目的，是以經營需要為基礎提供準則，例如： • 評估的標的是什麼 流程與產品品質保證(PPQA) 398
CMMI for Development Version • 流程評估的時程或頻率 • 如何進行評估 • 必須參與評估的人員 3. 使用上述準則評估所執行之流程，對流程說明、標準及程序的遵循程度。 4. 界定評估時發現的每一個不符合事項。 5. 界定能改善未來產品及服務流程的學習心得。 SP 客觀評估工作產品及服務 根據適用流程說明、標準和程序，客觀評估指定的工作產品及服務。 典型的工作產品 1. 評估報告 2. 不符合的報告 3. 矯正措施 細部執行方法 1. 取樣時，根據文件化的取樣準則，選擇需評估的工作產品。 2. 建立並維護明確陳述的準則，以供評估工作產品。 本細部執行方法的目的，是以經營需要為基礎提供準則，例如： • 評估的標的 • 評估工作產品的時程或頻率 • 如何進行評估 • 必須參與評估的人員 3. 使用上述準則評估工作產品。 4. 在工作產品交給客戶前，評估工作產品。 5. 在發展過程的已選定里程碑中，評估工作產品。 流程與產品品質保證(PPQA) 399
CMMI for Development Version 6. 根據流程說明、標準及程序，對工作產品及服務進行漸進式或漸增式的評估。 7. 界定評估時發現的每一個不符合事項。 8. 界定能改善未來產品及服務流程的學習心得。 SG 2 提供客觀的洞察力 客觀追蹤與溝通不符合的議題，並確保解決議題。 SP 溝通並確保解決不符合的議題 溝通品質議題，並和成員與管理者確保解決不符合的議題。 評估時發現的不符合議題，反映出對適用標準、流程說明或程序缺乏遵循。不符合議題的狀況可提供品質趨勢的指標。品質議題包括不符合議題和趨勢分析的結果。 當不符合議題不能在專案內解決時，使用已建立的向上反應機制，確保適當的管理階層可以解決議題。追蹤不符合議題直到解決為止。 典型的工作產品 1. 矯正措施報告 2. 評估報告 3. 品質趨勢 細部執行方法 1. 盡可能與適當的成員解決每一個不符合的議題。 2. 當不符合議題在專案內無法解決時，需予以記錄。 流程與產品品質保證(PPQA) 400
CMMI for Development Version 專案內解決不符合事項的方法，舉例如下： • 修改不符合處 • 修改違反的流程說明、標準或程序 • 取得不符合議題的豁免 3. 不符合議題在專案內無法解決時，提升到適當的管理階層，以瞭解議題並採取行動。 4. 分析不符合議題，以瞭解是否有品質趨勢需要界定和處理。 5. 確定相關關鍵人員及時知道評估的結果和品質趨勢。 6. 定期與指派的管理者審查未結案的不符合議題和趨勢，以瞭解議題並採取行動。 7. 追蹤不符合議題直到解決為止。 SP 建立紀錄 建立並維護品質保證活動的紀錄。 典型的工作產品 1. 評估紀錄 2. 品質保證報告 3. 矯正措施的狀況報告 4. 品質趨勢報告 細部執行方法 1. 詳細記錄流程與產品品質保證活動，以瞭解狀況和結果。 2. 視需要修正品質保證活動的狀況與歷史。 流程與產品品質保證(PPQA) 401
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施流程與產品品質保證流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 GP 建立組織政策 建立並維護組織政策，以規劃和執行流程與產品品質保證流程。 詳細說明： 本政策建立組織的期望，以客觀評估流程與相關工作產品，遵循適用的流程說明、標準及程序的程度，並確保解決不符合議題。 本政策建立將流程與產品品質保證功能放置於所有專案的組織期望。流程與產品品質保證必須充分的從專案管理獨立出來，以便能客觀指出並報告不符合議題。 GP 規劃流程 建立並維護執行流程與產品品質保證流程的計畫。 流程與產品品質保證(PPQA) 402
CMMI for Development Version 詳細說明： 專案計畫通常包含(或參考)執行流程與產品品質保證流程的計畫。專案計畫在專案規劃流程領域中說明。 GP 提供資源 提供充足的資源，以執行流程與產品品質保證流程、發展工作產品及提供流程服務。 詳細說明： 提供的資源，舉例如下： • 評估工具 • 追蹤不符合事項的工具 GP 指派責任 指派流程與產品品質保證流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 詳細說明： 為預防主觀或偏見，須確保已指派流程與產品品質保證之責任與授權的人員，能充分獨立且客觀的執行評估。 GP 訓練人員 依需要訓練人員，以執行或支援流程與產品品質保證流程。 流程與產品品質保證(PPQA) 403
CMMI for Development Version 詳細說明： 訓練的主題，舉例如下： • 應用領域 • 客戶關係 • 專案的流程說明、標準、程序及方法 • 品質保證目標、流程說明、標準、程序、方法及工具 GP 管理建構 將指定的流程與產品品質保證流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 不符合的報告 • 評估紀錄與報告 GP 界定並納入相關的關鍵人員 依計畫界定並納入流程與產品品質保證流程相關的關鍵人員。 詳細說明： 相關的關鍵人員參與的活動，舉例如下： • 建立流程與工作產品客觀評估的準則 • 評估流程與工作產品 • 解決不符合的議題 • 追蹤不符合議題直到解決 流程與產品品質保證(PPQA) 404
CMMI for Development Version GP 監控流程 依本流程的執行計畫，監控流程與產品品質保證流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量及工作產品，舉例如下： • 規劃與執行客觀流程評估的差異 • 規劃與執行客觀工作產品評估的差異 • 客觀評估的時程 • 特定的客觀評估時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估流程與產品品質保證流程的遵循程度，並解決不符合的情況。 詳細說明： 參考表格一般目標和一般執行方法去獲得更多關於在一般執行方法和流程與產品品質保證流程領域。 審查的活動，舉例如下： • 客觀評估流程與工作產品 • 追蹤與溝通不符合的議題 審查的工作產品，舉例如下： • 不符合的報告 • 評估紀錄與報告 GP 與上層管理人員審查各狀況 與上層管理人員檢討流程與產品品質保證流程的活動、狀況及結果，並解決議題。 流程與產品品質保證(PPQA) 405
CMMI for Development Version 僅適用於階段式表述 GG 3的目標及其執行方法，不是成熟度第二級評等的必要項目，但它們是成熟度第三級和更高等級評等的必要組件。 僅適用於連續式/成熟度第3-5級 GG 3 制度化已定義流程 將流程制度化為已定義流程 GP 建立已定義流程 建立並維護已定義流程與產品品質保證流程的說明。 GP 蒐集改善資訊 蒐集由規劃並執行流程與產品品質保證流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 詳細說明： 工作產品、度量、度量結果及改善資訊，舉例如下： • 評估記錄 • 品質趨勢 • 不符合的報告 • 改正措施的狀況報告 • 專案品質報告的成本 流程與產品品質保證(PPQA) 406
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護流程與產品品質保證流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定流程與產品品質保證流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保流程與產品品質保證流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正流程與產品品質保證流程之缺失與其他問題的根本原因。 流程與產品品質保證(PPQA) 407
CMMI for Development Version 量化專案管理 成熟度第四級的專案管理類流程領域 目的 量化專案管理(Quantitative Project Management, QPM)流程領域的目的，在於以量化的方式管理專案已調適流程，以達成專案既定的品質及流程績效目標。 簡介 量化專案管理流程領域包括以下事項： • 設定並維護專案品質及流程績效目標 • 以流程績效基準或模式的穩定性及能力的歷史資料為基礎，界定組成專案已調適流程的適當子流程 • 從專案已調適流程中，選定採統計化管理的子流程 • 監控專案，以決定是否符合專案的品質及流程績效目標，並界定適當的矯正措施 • 選定用於統計化管理所選定子流程的度量及分析技術 • 運用選定的度量及分析技術來建立並維護對所選定子流程變異的理解 • 監控所選定子流程的績效，以決定子流程是否符合其品質及流程績效目標，並界定矯正措施 • 將統計及品質管理資料記錄於組織度量儲存庫 此處所界定的品質與流程績效目標、度量及基準，是由組織流程績效流程領域的內容發展而來。因此，實施量化專案管理流程領域相關的流程(例如：度量定義與度量資料等)，將成為組織流程績效流程領域所指組織流程資產的一部分。 量化專案管理(QPM) 408
CMMI for Development Version 為有效說明本流程領域的特定執行方法，組織應已建立一組標準流程及相關的組織流程資產，例如：每一專案用來建立其已調適流程的組織度量儲存庫及組織流程資產館。專案已調適流程是為專案而構成的整合且藕合之生命週期的一組子流程，其一部分是由組織標準流程挑選及調適而來。有關「已調適流程」在CMMI產品系列中如何使用的說明(參考詞彙的定義)。 專案也應該以確保能取得供應商工作的度量與進度資料。要成功的完成本流程領域的特定執行方法必須與供應商建立有效的關係。 流程績效是實際流程績效結果的一個度量，流程績效以流程度量(例如：工作量、週期時間及缺失移除的有效程度)及產品度量(例如：可靠度、缺失密度及反應時間)來表示。 子流程是一個更大已調適流程的定義組件，例如：一個典型的組織發展流程，可由需求發展、設計、產品製作、測試及同仁查核等子流程所構成。必要時，這些子流程又可再進一步分解為其他子流程或流程元件。 量化管理的一個基本要素是要對估計值要有信心(也就是說，要能夠預測專案品質及流程績效目標的達成度)。需要統計化管理的子流程是基於可預測的績效需要來選定。(有關「統計化管理流程」「品質與流程績效目標」與「量化管理流程」的定義，請參見詞彙) 量化管理的另一個基本要素是要瞭解實際流程績效差異的本質及差異程度，並認知在什麼時候，專案實際績效並無法協助達成專案品質及流程績效目標。 統計化管理涉及統計化的思維及各種統計技術的正確運用，如執行圖(run charts)、控制圖、信賴區間、預測區間及假設驗證等統計技術。量化管理是運用由統計化管理所得到的資料，來協助專案預計量化專案管理(QPM) 409
CMMI for Development Version 是否能達成其品質及流程績效目標，並界定必須採取的矯正措施。 本流程領域應用於管理一個專案，但其相關的概念可運用於管理其他小組與功能群。將這些相關概念應用於其他小組與功能群，並不必然對達成組織經營目標有所幫助，但可能可以協助這些小組與功能群控制其流程。 其他小組與功能群，舉例如下: • 品質保證 • 流程定義及改善 • 工作量報告 • 客戶抱怨處理 • 問題追蹤及報告 相關流程領域 有關如何監控專案與採取矯正措施，請參考專案監控流程領域，以獲得更多資訊。 有關設定度量目標、指定度量及分析項目，取得及分析度量，以及提供度量結果，請參考度量與分析流程領域，以獲得更多資訊。 有關組織品質及流程績效目標、流程績效分析、流程績效基準及流程績效模式，請參考組織流程績效流程領域，以獲得更多資訊。 有關包含組織度量儲存庫的組織流程資產，請參考組織流程定義流程領域，以獲得更多資訊。 有關建立並維護專案已調適流程，請參考整合的專案管理流程領域，以獲得更多資訊。 量化專案管理(QPM) 410
CMMI for Development Version 有關如何界定缺失及問題原因，並採取行動以預防未來再度發生，請參考原因分析與解決方案流程領域，以獲得更多資訊。 有關選定及推展改善措施，以支援組織品質及流程績效目標，請參考組織創新與推展流程領域，以獲得更多資訊。 量化專案管理(QPM) 411
CMMI for Development Version 特定目標及執行方法摘要 SG 1量化管理專案 SP 設定專案目標 SP 組合已調適流程 SP 選定納入統計化管理的子流程 SP 管理專案績效 SG 2 統計化管理子流程的績效 SP 選定度量及分析技術 SP 應用統計方法瞭解變異 SP 監控子流程的績效 SP 記錄統計管理資料 特定目標的特定執行方法 SG 1 量化管理專案 依品質及流程績效目標，以量化的方式管理專案。 SP 設定專案目標 設定並維護專案品質及流程績效目標。 事先思考要將哪些組織標準流程納入專案的已調適流程並參考相關流程績效的歷史資料，經常能對設定專案品質及流程績效目標的工作有所幫助，藉由這些事前的思考將有助於設定實際可行的專案目標。日後當知道專案實際的績效並且更容易預測時，也許需要修訂專案的目標。 典型的工作產品 1. 專案品質及流程績效目標。 細部執行方法 1. 審查組織的品質及流程績效目標。 審查的目的是要確保專案瞭解專案運作的整體經營背景。專案的品質及流程績效目標是依據整個組織的目標發展而來。 量化專案管理(QPM) 412
CMMI for Development Version 有關組織品質及流程績效目標，請參考組織流程績效流程領域，以獲得更多資訊。 2. 界定客戶、最終使用者及其他相關關鍵人員，對品質及流程績效的需求及優先順序。 應界定需要與優先順序的品質及流程績效屬性，舉例如下： • 功能性 • 可靠度 • 可維護性 • 可用性 • 期間 • 可預測性 • 適時性 • 準確性 3. 界定如何度量流程績效。 考量組織所建立的度量是否適用於評量進度，以履行客戶、使用者及其他關鍵人員的需要及優先順序。必要時，需補充其他額外的度量。 有關度量的定義，請參考度量與分析流程領域，以獲得更多資訊。 4. 定義並記錄專案可度量的品質及流程績效目標。 定義並記錄專案的目標包括以下事項： • 納入組織的品質及流程績效目標 • 記錄目標及目標的度量方法，這些目標須能反映品質與流程績效需要，以及客戶、最終使用者和其他關鍵人員的優先順序 量化專案管理(QPM) 413
CMMI for Development Version 可能採用的專案目標品質屬性，舉例如下： • 失敗的平均間隔時間 • 關鍵性資源的使用狀況 • 交付產品的缺失數量及其嚴重性 • 客戶對所提供服務的抱怨數量與嚴重性 可能採用的專案目標流程績效屬性，舉例如下： • 在產品驗證活動中，缺失移除的百分比(可依驗證活動類型分類，例如：同仁查核及測試) • 未發現的缺失比率 • 產品交付(或服務開始)第一年內，所發現的缺失數量及缺失密度(依嚴重性) • 週期時間 • 重做時間的百分比 5. 於適當時機，針對生命週期每一階段，推衍出過渡性目標，以監控達成專案目標的進度。 預測流程未來結果的一個方法是：運用流程績效模式，並使用在產品驗證活動(例如：同仁查核及測試)所界定的過渡性缺失度量，來預測未來交付產品的潛在缺失。 6. 解決專案品質及流程績效目標間的衝突(例如：如果一個目標沒有妥協，另一個目標將無法達成)。 解決衝突相關的活動包括： • 設定各項目標的相對優先順序 • 依長期經營策略及短期需要，衡量各項備選目標 量化專案管理(QPM) 414
CMMI for Development Version • 邀集客戶、最終使用者、高階管理人員、專案管理人員及其他有關的關鍵人員參與取捨的決定 • 必要時修訂目標以反映衝突解決的結果 7. 從來源建立專案品質及流程績效目標的可追溯性。 目標的來源，舉例如下： • 需求 • 組織的品質及流程績效目標 • 客戶的品質及流程績效目標 • 經營目標 • 與客戶及潛在客戶討論 • 市場調查 「品質機能展開(QFD)」是界定及追蹤這些需求及優先順序的一個方法。 8. 定義並協商供應商的品質及流程績效目標。 有關建立並維護供應商協議，請參考供應商協議管理流程領域，以獲得更多資訊。 9. 必要時修訂專案品質及流程績效目標。 SP 組合已調適流程 以過去的穩定性及能力資料為基礎，選定組成專案之已調適流程的子流程。 有關建立並維護專案已調適流程，請參考整合的專案管理流程領域，以獲得更多資訊。 有關包含已知及必需能力之流程元件的組織流程資產館，請參考組織流程定義流程領域，以獲得更多資訊。 量化專案管理(QPM) 415
CMMI for Development Version 有關組織流程績效基準及流程績效模式，請參考組織流程績效流程領域，以獲得更多資訊。 從組織標準流程的流程元件及組織流程資產館的流程產品，界定子流程。 典型的工作產品 1. 用以界定納入專案已調適流程備選子流程的準則 2. 納入專案已調適流程的備選子流程 3. 確定納入專案已調適流程的子流程 4. 所選定的子流程缺乏流程歷史績效資料時，所界定的風險 細部執行方法 1. 建立用以界定有效備選子流程的評估準則。 界定的基礎包括： • 品質及流程績效目標 • 具體的流程績效資料 • 產品線標準 • 專案生命週期模式 • 客戶需求 • 法規 2. 決定欲納入統計化管理及從組織流程資產所取得的子流程，是否適合採行統計化管理。 某子流程如果有以下的歷史紀錄，可能將更適合採行統計化管理： • 過去類似的案例具穩定的績效 • 流程績效資料滿足專案品質及流程績效目標 歷史資料主要是由組織流程績效基準取得，不過，並不是所有子流程都有這些資料。 3. 分析子流程的相互關係，以瞭解子流程間的關連性以及各子流程的度量屬性。 量化專案管理(QPM) 416
CMMI for Development Version 可採用的分析技術，如系統動態模式及模擬方法。 4. 界定無任何子流程滿足品質及流程績效目標時的風險(也就是說，沒有具能力的子流程或不瞭解子流程的能力)。 即使某子流程並未被選為採用統計化管理，其歷史資料及流程績效模式，亦可能可以指出該子流程未能滿足品質及流程績效目標。 有關風險的界定及分析，請參考風險管理流程領域，以獲得更多資訊。 SP 選定欲納入統計化管理的子流程 從專案已調適流程中，選定欲納入統計化管理的子流程。 選定納入統計化管理的子流程通常是同步及重複進行的流程，以界定可用的專案與組織的品質及流程績效目標、選定子流程，以及界定用以度量與控制的流程及產品屬性。通常在選擇流程、品質與流程績效目標或度量的屬性時，選擇其中一者會限制其他二者，例如：選定一個特別的流程之後，相關的度量屬性與流程績效目標都會因選定的流程而受限制。 典型的工作產品 1. 統計化管理所要追求的品質及流程績效目標 2. 用於選定納入統計化管理子流程的準則 3. 納入統計化管理的子流程 4. 應度量及控制之子流程的已界定流程及產品屬性 細部執行方法 1. 界定專案有哪些品質及流程績效目標將納入統計化管理。 量化專案管理(QPM) 417
CMMI for Development Version 2. 界定用以選擇對達成既定品質及流程績效目標最有影響且極具績效可預測性之子流程的準則。 用於選定子流程的準則來源，舉例如下： • 與品質及流程績效相關的客戶需求 • 客戶所設定的品質及流程績效目標 • 組織所設定的品質及流程績效目標 • 組織的績效基準與模式 • 其他專案子流程穩定的績效 • 法規 3. 利用選取準則選定將被統計化管理的子流程。 可能無法對某些子流程進行統計化管理(例如：新的子流程及正在試行的技術。) 在某些情形，應用統計技術於某些的子流程可能不符經濟效益。 4. 界定用以度量與控制子流程的產品及流程屬性。 產品及流程屬性，舉例如下： • 缺失密度 • 週期時間 • 測試涵蓋度 SP 管理專案績效 監控專案，以決定是否符合其品質及流程績效目標，並於適當時機界定矯正措施。 有關分析及使用度量，請參考度量與分析流程領域，以獲得更多資訊。 進行本項比較的前提之一是：專案已調適流程所選定的子流程已採統計化管理，並充分瞭解其流程能 量化專案管理(QPM) 418
CMMI for Development Version 力。特定目標2對於統計畫管理所選定的子流程，提供詳細的說明。 典型的工作產品 1. 專案品質及流程績效目標達成度的估計值(預測值) 2. 達成專案品質及流程績效目標的風險文件 3. 達成專案目標過程中，用以解決缺失的行動措施文件 細部執行方法 1. 定期審查每個子流程的績效及每個選定納入統計化管理之子流程的能力，以評估達成專案品質及流程績效目標的進度。 參考該子流程既定的品質及流程績效目標，來決定每個所選定子流程的流程能力，這些目標是從專案品質及流程績效目標中，以專案整體的觀點推衍而來。 2. 定期審查生命週期中每個階段性目標的實際達成狀況，以評估達成專案品質及流程績效目標的進度。 3. 追蹤供應商品質及流程績效目標的達成狀況。 4. 運用關鍵屬性度量所調整的流程績效模式，以估計達成專案品質及流程績效目標的進度。一些到專案生命週期後期才能度量的進度，可運用流程績效模式加以估計，例如：可運用流程績效模式，並使用同仁查核時的過渡度量，預測交付產品時的潛在缺失。 流程績效模式用於估計進度目標該目標一定要在專案生命週期的未來階段，才能度量。例如運用流程績效模式，並使用同仁查核時的過渡度量，預測交付產品時的潛在缺失。 量化專案管理(QPM) 419
CMMI for Development Version 有關流程績效模式，請參考組織流程績效流程領域，以獲得更多資訊。 此處的調整是以執行先前細部執行方法所得的結果為基礎。 5. 界定並管理達成專案品質及流程績效目標的相關風險。 有關界定及管理風險，請參考風險管理流程領域，以獲得更多資訊。 風險的來源，舉例如下： • 組織度量儲存庫內缺乏穩定性及能力資料 • 子流程缺乏績效或能力 • 供應商未能達成其品質及流程績效目標 • 對供應商的能力缺乏深入瞭解 • 用於預測未來績效的組織流程績效模式內不正確 • 預測流程績效(估計進度)時的缺失 • 其他與所界定缺失相關的風險 6. 決定並記錄在達成專案品質和流程績效目標的過程中，用以解決缺失的行動措施。 這些行動措施的目的，是要規劃及推展正確的活動、資源及時程，以儘可能將專案帶回正軌，以達成專案目標。 量化專案管理(QPM) 420
CMMI for Development Version 在達成專案目標過程中，用以解決缺失的行動措施，舉例如下： • 改變品質或流程績效目標，使得這些目標在專案已調適流程的預期範圍內。 • 改善專案已調適流程的實行過程，以減小其常態的變異性(在不必移動平均值的情形下，藉由減小變異，將專案績效帶回專案目標之內) • 採行可能滿足目標及管理相關風險的新子流程及技術。 • 界定這些缺失的風險及降低風險的策略 • 終止專案 有關採取矯正措施，請參考專案監控流程流程領域，以獲得更多資訊。 SG 2 統計化管理子流程績效 以統計化方式管理專案的已調適流程之子流程績效。 此特定目標描述在本流程領域中用以達成「量化管理專案」特定目標的重要活動，此特定目標的特定執行方法描述如何統計化管理依第一個特定目標下的特定執行方法所選取的子流程，當這些選定的子流程被統計化管理時，便可確定各子流程達成目標的能力，藉此，就可能預測專案是否可以達成其目標，此即為量化專案管理的關鍵。 SP 選定度量及分析技術 選定將用於統計化管理所選定子流程的度量及分析技術。 有關設定度量目標，定義、蒐集及分析度量，以及修訂度量及統計分析技術，請參考度量與分析流程領域，以獲得更多資訊。 量化專案管理(QPM) 421
CMMI for Development Version 典型的工作產品 1. 用於(或建議採用)統計化管理所選定子流程之度量及分析技術的定義 2. 度量的操作定義，它們在子流程的蒐集點，以及如何確定度量的完整性。 3. 度量的可追溯性，可回溯至專案品質及流程績效目標 4. 支援自動化資料蒐集的工具化組織支援環境 細部執行方法 1. 從支援統計化管理的組織流程資產中，界定共通性度量。 有關共通性度量，請參考組織流程定義流程領域，以獲得更多資訊。 可運用產品線或其他分層準則將共通性度量分類。 2. 界定此實體所需的額外度量，以涵蓋所選定子流程的關鍵產品及流程屬性。 在某些情形，度量可能是研究導向的，應特別標示這些度量。 3. 界定適用於統計化管理的度量。 選擇統計化管理度量的關鍵性準則如下： • 可受控制(例如：改變子流程的執行方法，是否能改變度量值？) • 適當的績效指標(例如：以子流程達成重要目標的程度來看，其度量是否是個好的指標？) 量化專案管理(QPM) 422
CMMI for Development Version 子流程度量，舉例如下： • 需求變動性 • 規劃參數估計值相對於度量值的比例(例如：規模大小、成本及時程) • 同仁審查的涵蓋度及效率 • 測試涵蓋度及效率 • 訓練的成效(例如：訓練計畫的完成比例及測驗分數） • 可靠度 • 專案生命週期各階段新增或發現缺失佔總缺失的百分比 • 專案生命週期各階段所工作量佔總工作量的百分比 4. 制定度量的操作定義，它們在子流程的蒐集點，以及如何確定度量的完整性。 說明操作定義時，必須明確而不含糊，以下是兩個重要的說明準則： • 明確傳達：說明度量的內容、如何進行度量、度量的單位，以及納入或排除的度量項目。 • 可重複性：度量是否可以重複，在於是否給予相同的定義以獲取相同的結果。 5. 分析指定度量與組織及專案目標之間的關聯性，並推衍出目標，說明每個選定子流程的度量屬性，必須符合的特定目的之度量或範圍。 6. 建構支援統計化度量資料蒐集、推導及分析的工具化組織支援環境。 工具化的基礎包括： • 組織標準流程的描述 • 專案已調適流程的描述 • 組織支援環境的能力 量化專案管理(QPM) 423
CMMI for Development Version 7. 界定適用於子流程統計化管理的適當統計分析技術。 「一雙鞋子無法適合所有人」的觀念可應用到統計分析技術。決定某一特定的統計技術是否適用的因素，不僅是度量的類型，更重要的是：度量如何使用、實際情況是否確保可應用該技術等。選擇的適當性須隨時加以瞭解探究。 統計分析技術的範例將在下個特定執行方法中說明。 8. 必要時修訂度量及統計分析技術。 SP 應用統計方法瞭解變異 運用選定的度量及分析技術，以建立並維護對所選定子流程之變異的瞭解。 有關蒐集、分析及運用度量結果，請參考度量與分析流程領域，以獲得更多資訊。 蒐集並分析流程及產品度量資料，可以瞭解部分的流程變異性，藉此可以進一步界定及說明造成變異的特殊原因，以達成預期的績效。 流程變異的特殊原因是流程執行時產生非預期性的改變，特殊的原因也稱為「可指定的原因」，因為這些原因可以界定、分析及說明，以預防變異重複發生。 界定變異的特殊原因應先區隔系統變異的共同原因，區隔的方式包括使用極端的數值或其他由子流程或相關工作產品蒐集而來可辨別的資料形式，有關流程變異的知識、判斷異常型態來源的洞察力是發掘特殊原因時應具備的能力。 量化專案管理(QPM) 424
CMMI for Development Version 流程變異異常型態的來源，包括： • 與流程不符 • 數個子流程對資料產生的不明影響 • 子流程內部活動的順序與時機 • 子流程的未控管輸入 • 子流程執行時環境的改變 • 時程壓力 • 不恰當的資料取樣或組合 典型的工作產品 1. 蒐集的度量 2. 每個選定子流程之度量屬性的流程績效常態範圍 3. 與每個選定子流程之度量屬性的流程績效常態範圍相比較的流程績效 細部執行方法 1. 針對具適當歷史績效資料的子流程，設定試驗性質的常態範圍。 有關組織流程績效基準，請參考組織流程績效流程領域，以獲得更多資訊。 屬性的常態範圍是變異發生的正常範圍，所有流程在執行過程中，均會出現流程及產品度量數值上的一些變異。但存在的議題是：這些變異是起因於流程正常執行的共同變異原因，或是起因於某些應加以界定並解決的特殊原因。 當一子流程開始執行時，設定試驗性的常態範圍，有時可從該子流程或相類似流程的先前實例、流程績效基準或流程績效模式取得合適資料，這些資料通常包含於組織度量儲存庫。執行子流程時，可蒐集特定案例的資料，以更新及取代試驗性的常態範圍值。不過，如果有疑慮的流量化專案管理(QPM) 425
CMMI for Development Version 程已經過大幅的調適，或情況已和過去的執行狀況有很大的差異，度量儲存庫的資料可能就不適當，且不應該使用。 在某些情形，可能沒有類似的歷史資料(例如：當引進一項新的流程、進入一個新的應用領域或子流程已有顯著改變時)。針對這些情形，應使用子流程的初期流程資料，建立試驗性的常態範圍，這些試驗性的常態範圍應隨著流程的進行，適時地調修及更新。 決定資料是否可進行比較的準則，舉例如下： • 產品線 • 應用領域 • 工作產品及任務屬性(例如：產品規模大小) • 專案規模大小 2. 依選定的度量，蒐集執行子流程時的度量資料。 3. 針對每一度量屬性，計算流程績效的常態範圍。 計算常態範圍之處，舉例如下： • 控制圖 • 信賴區間(針對分配參數) • 預測區間(針對將來的結果) 4. 界定變異的特殊原因。 在控制圖中，偵測流程變異特殊原因的一個準則範例是：一個落在3個標準差控制界限外的資料點。 偵測發生變異特殊原因的準則，是以統計理論及經驗為基礎，並考量經濟上的可行性。當增列準則時，雖可以更容易界定特殊原因，但出現假警報的機會將增加。 量化專案管理(QPM) 426
CMMI for Development Version 5. 分析流程變異的特殊原因，以確認異常發生的原因。 分析變異特殊原因之理由的技術，舉例如下： • 因果關係圖(魚骨圖) • 實驗設計 • 控制圖(應用於子流程輸入或較低層次的子流程) • 分群法(依對子流程實行的瞭解，將資料分割至較小的群組，幫助區隔特殊原因) 一些異常可能僅是統計分配的極端值而不是問題，實行流程的人通常是最具分析並瞭解變異特殊原因能力的人。 6. 當界定變異的特殊原因之後，決定應採取什麼矯正措施。 移除變異的流程特殊原因並不是要改變子流程，而是說明子流程在某種程度上執行的錯誤。 有關採取矯正措施，請參考專案監控流程領域，以獲得更多資訊。 7. 必要時針對所選定子流程的每一度量屬性，重新計算其常態範圍。 以預示子流程已經改變的度量值為基礎(而不是以預期或隨意的決策為基礎)，重新計算(統計方法估算)常態範圍。 量化專案管理(QPM) 427
CMMI for Development Version 常態範圍需要重新計算的時機，舉例如下： • 對子流程有累進的改善 • 子流程推展新的工具 • 推展新的子流程 • 所蒐集的度量資料指出，子流程的平均值已經永久性改變，或子流程的變異已經永久性改變 SP 監控子流程的績效 監控所選定子流程的績效，以確認這些子流程滿足其品質及流程績效目標的能力，並於適當時機界定矯正措施。 本特定執行方法的目的是要： • 以統計的方式從子流程的預期，決定流程的行為 • 評量流程達成其品質及流程績效目標的機率 • 以流程績效資料統計分析為基礎，界定要採取的矯正措施。 矯正措施可包含：重新協商受影響的專案目標、界定及實施替代的子流程，或界定並度量更低層級的子流程，以瞭解績效資料更多的細節。這些行動是要協助專案運用合格流程。有關「合格流程」的定義，請參見附錄C詞彙。 所選定子流程的能力與其品質及流程績效目標相比較的先決條件之一是：對其度量屬性而言，子流程的績效要具穩定性及可預測性。 應針對已設定(衍生)目標的子流程及度量屬性，分析其流程能力，並不是所有納入統計化管理的子流程或度量屬性，都要分析其流程能力。 歷史資料可能不足以初步決定一流程是否合格，也有可能子流程績效的常態範圍估計值，與品質及流程績效目標逐漸產生差距。無論是上述何種情形，統計控制隱含著監控其能力及穩定性。 量化專案管理(QPM) 428
CMMI for Development Version 典型的工作產品 1. 每一所選定子流程流程績效的常態範圍與其(衍生)目標的比較 2. 每一子流程的流程能力 3. 每一子流程解決流程能力缺失的行動 細部執行方法 1. 比較品質及流程績效目標與度量屬性常態範圍的差異。 本比較對子流程的每一度量屬性，評估其流程能力。這些比較可以圖形的方式表示，藉由圖形可顯示出常態範圍估計值與目標間的相對關係，或作為流程能力指標，用來摘要目標與常態範圍間的相對關係。 2. 監控品質及流程績效目標，以及選定之子流程流程能力的變化。 3. 界定並記錄子流程的能力缺失。 4. 決定並記錄解決子流程能力缺失所必要的行動。 當所選定子流程的績效未能達成其目標時，可採取的行動，舉例如下： • 改變品質及流程績效目標，使其落入子流程的流程能力範圍內 • 改善現行子流程的實施過程，以減小其常態的變異性(在不必移動平均值的情形下，藉由減小變異性，將常態範圍落入目標範圍內) • 採行有可能滿足目標及管理相關風險的新流程元件、子流程及技術 • 針對每一子流程的流程能力缺失，界定這些缺失的風險及風險降低策略 量化專案管理(QPM) 429
CMMI for Development Version 有關採取矯正措施，請參考專案監控流程領域，以獲得更多資訊。 SP 記錄統計管理資料 將統計的及品質管理資料記錄於組織度量儲存庫。 有關管理及儲存資料、度量定義及度量結果，請參考度量與分析流程領域，以獲得更多資訊。 有關組織度量儲存庫，請參考組織流程定義流程領域，以獲得更多資訊。 典型的工作產品 1. 記錄於組織度量儲存庫的統計及品質管理資料 量化專案管理(QPM) 430
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施量化專案管理流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理的流程。 僅適用於階段式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行量化專案管理流程。 詳細說明： 本政策建立組織的期望，依品質及流程績效目標，進行量化專案管理，並對專案已調適流程中所選定的子流程，進行統計化管理。 GP 規劃流程 建立並維護執行量化專案管理流程的計畫。 量化專案管理(QPM) 431
CMMI for Development Version 詳細說明： 執行量化專案管理流程的計畫可包含在專案計畫(或者被參考)。專案計畫在專案規劃流程領域中說明。 GP 提供資源 提供充足的資源，以執行量化專案管理流程、發展工作產品及提供流程服務。 詳細說明： 可能需要統計及統計流程控制等特殊的專業知識，以界定所選定子流程統計化管理所需的技術，專案成員需運用統計工具及技術，以執行統計化管理工作。可能也需要統計學的特殊專業知識，以便分析及解讀統計化管理所取得的度量資料。 提供的其他資源/工具，舉例如下： • 系統動態模式 • 測試涵蓋度自動化分析工具 • 統計流程及品質控制套裝軟體 • 統計分析套裝軟體 GP 指派責任 指派量化管理流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援量化專案管理流程。 量化專案管理(QPM) 432
CMMI for Development Version 詳細說明： 訓練的主題，舉例如下： • 流程模式化及分析 • 流程度量資料選擇、定義及蒐集 GP 管理建構 將指定的量化專案管理流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 納入專案已調適流程的子流程 • 度量的操作定義、度量資料在子流程的蒐集點，以及如何判定度量的完整性 • 蒐集的度量 GP 界定並納入相關的關鍵人員 依計畫界定並納入量化專案管理流程相關的關鍵人員。 詳細說明： 關鍵人員參與的活動，舉例如下： • 設定專案目標 • 解決專案品質及流程績效目標的議題 • 評鑑所選定子流程的績效 • 界定並管理在達成專案品質及流程績效目標過程中的風險 • 界定必須採取的矯正措施 量化專案管理(QPM) 433
CMMI for Development Version GP 監控流程 依本流程的執行計畫，監控量化專案管理流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量，舉例如下： • 納入統計化管理的子流程摘要(例如：計畫納入統計化管理的子流程數量、目前正以統計化管理的子流程數量及具統計穩定性的子流程數量) • 已界定之變異特殊原因的數量 • 當度量與分析的活動週期與量化管理活動相關時，它資料蒐集、分析與報告的時程。 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估量化專案管理流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 依品質及流程績效目標進行量化專案管理 • 對專案已調適流程的子流程進行統計化管理 審查的工作產品，舉例如下： • 包含於專案已調適流程的子流程 • 度量的操作定義 • 蒐集的度量 GP 與上層管理人員審查各狀況 與上層管理人員審查量化專案管理流程的活動、狀況及結果，並解決問題。 量化專案管理(QPM) 434
CMMI for Development Version 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義的流程。 本一般目標反映在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義量化專案管理流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行量化專案管理流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產未來的使用與改善。 詳細說明： 工作產品、度量、度量結果與改善資訊，舉例如下： • 專案的統計畫與品質管理資料的紀錄，包含如依已建立專案過渡性目標，定期審查統計化管理子流程的實際執行績效，所得到的審查結果。 • 流程與產品品質保證報告，用以界定在執行上雖不一致但符合的統計化子流程。 量化專案管理(QPM) 435
CMMI for Development Version 僅適用於連續式表示 GG 4 制度化已量化管理流程 將流程制度化為已量化管理的流程。 GP 建立流程的量化目標 建立並維護量化專案管理流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定量化專案管理流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化的流程。 GP 確保持續的流程改善 確保量化專案管理流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正量化專案管理流程之缺失與其他問題的根本原因。 量化專案管理(QPM) 436
CMMI for Development Version 需求發展 成熟度第三級的工程類流程領域 目的 需求發展(Requirements Development, RD)的目的，在於產出並分析客戶、產品及產品組件的需求。 簡介 本流程領域描述客戶、產品及產品組件等三種需求，這些需求說明相關關鍵人員的需要，包括與產品生命週期各階段 (如，驗收測試準則)及產品屬性(如，安全性、可靠性、與維護能力等) 有關的需要。需求也包括選擇某設計解決方案而產生的限制條件。例如：與現成品整合的需求。 所有發展專案都有需求，從專案於維護活動的專案案例來看，產品或產品組件的變更，是基於現有需求、設計、或實作的變更。需求變更可能來自顧客或使用者所記載的變更請求單，或來自於需求發展流程的新需求形式。不論需求來源或型式，變更所驅動的維護活動也要加以管理。 需求是設計的基礎，需求的發展包括下列活動： • 誘導、分析、驗證，以及溝通客戶的需要、期望及限制，以獲得客戶需求，並達成關鍵人員的共識 • 蒐集和協調關鍵人員的需要 • 發展產品的生命週期需求 • 建立客戶需求 • 建立與客戶需求一致的原始產品及產品組件需求 需求發展(RD) 437
CMMI for Development Version 因為客戶也可能提出特定的設計需求，本流程領域討論所有客戶的需求，而非侷限於產品層次的需求。 客戶需求可進一步調修為產品及產品組件需求。除客戶需求外，選定的解決方案也可能衍生產品及產品組件需求。整個流程領域中，產品及產品組件的意涵也包括服務及其組件。 在整個產品生命週期中界定並修訂需求。對設計決策、後續的矯正措施，以及產品生命週期各階段所產生的回饋進行分析，以瞭解它們對衍生及已配置需求的影響。 需求發展流程領域包括三項特定目標。「發展客戶需求」特定目標說明如何定義完整的客戶需求，以使用於產品需求發展。「發展產品需求」特定目標說明如何定義完整的產品和產品組件需求，以使用於產品和產品組件設計。「分析並確認需求」特定目標說明客戶、產品及產品組件需求須執行的必要分析，以定義、衍生及瞭解需求。第三項特定目標的特定執行方法，用以輔助前兩項特定目標的特定執行方法。需求發展流程領域的流程和技術解決方案流程領域的流程，可彼此相互循環互動。 對競爭的備選方案進行分析，以瞭解、定義及選用各層次的需求。這些分析活動包括： • 分析產品生命週期每階段的需要和需求，包括：相關關鍵人員的需要、操作環境，以及反映所有客戶及使用者之期望和滿意的因素(如安全性、保密性及負擔能力) • 發展操作觀念 • 定義必要的功能 功能的定義，也稱為「功能分析」，與軟體發展的結構化分析不同，也不能假定為功能導向的軟體設計。在物件導向的軟體設計裡，它相當於定義所謂的「服務」或「方法」。功能、功能的邏輯群組， 需求發展(RD) 438
CMMI for Development Version 以及它們和需求之間關連的定義，就是所謂的「功能架構」。 對產品架構更細層次不斷地分析，直到獲得足夠的細節以進行產品的細部設計、採購及測試。經由分析需求的結果及操作概念(包括功能性、支援、維護及銷毀)，製造或生產的概念會產生出更多的衍生需求，包括下列考量： • 不同類型的限制 • 技術的界限 • 成本和成本因素 • 時間限制和時程因素 • 風險 • 客戶或使用者所暗示但未明確陳述之議題的考量 • 發展者獨特的經營考量、規定及法律等所產生的因素 邏輯實體的層次架構(功能及子功能，物件類別及子類別)，建立在反覆發展的操作觀念裡。需求經過調修、衍生，才能配置到該邏輯實體。需求和邏輯實體再被配置於產品、產品組件、人員、或相關流程。 在需求發展和分析時，納入相關關鍵人員的參與，藉此使他們瞭解需求的演進過程。本活動持續向相關關鍵人員提供保證：需求已適切定義。 相關流程領域 有關管理客戶及產品需求、取得需求提供者同意、取得需求執行者承諾及維護追溯性，請參考需求管理流程領域，以獲得更多資訊。 有關如何使用需求發展流程領域的輸出，以及發展替代方案和設計，以用於調修和衍生需求，請參考技術解決方案流程領域，以獲得更多資訊。 需求發展(RD) 439
CMMI for Development Version 有關介面需求和介面管理，請參考產品整合流程領域，以獲得更多資訊。 有關驗證最終產品是否符合需求，請參考驗證流程領域，以獲得更多資訊。 有關確認如何依照客戶需要建置產品，請參考確認流程領域，以獲得更多資訊。 有關需求相關風險的界定和管理，請參考風險管理流程領域，以獲得更多資訊。 有關確保重要工作產品的控管，請參考建構管理流程領域，以獲得更多資訊。 需求發展(RD) 440
CMMI for Development Version 特定目標及執行方法摘要 SG 1發展客戶需求 SP 誘導需要 SP 發展客戶需求 SG 2發展產品需求 SP 建立產品與產品組件需求 SP 配置產品組件需求 SP 界定介面需求 SG 3分析並確認需求 SP 建立操作概念及劇本 SP 建立必要功能的定義 SP 分析需求 SP 分析需求以取得平衡 SP 確認需求 各目標的特定執行方法 SG 1 發展客戶需求 蒐集關鍵人員需要、期望、限制及介面，並轉換成客戶需求。 關鍵人員(例如：客戶、最終使用者、供應商、建置人員、測試人員、製造人員，與後勤支援人員)的需要，是決定客戶需求的基礎。進行關鍵人員之需要、期望、限制、介面、操作概念，以及產品觀念的分析、協調、調修及詳細說明，以轉換成客戶需求。 關鍵人員的需要、期望、限制及介面，經常被粗略的界定或相互矛盾。因為必須清楚界定和瞭解關鍵人員的需要、期望、限制及界限，在整個專案的生命週期裡可使用反覆的流程，以達到這目標。為協助此必要的循環流程，最終使用者或客戶的代表，通常會加入此過程，以說明其需要並協助解決矛盾。組織的客戶關係或行銷部門，以及來自人際工需求發展(RD) 441
CMMI for Development Version 程或支援部門的發展團隊成員，可視為此類的代表。在研擬和解決客戶需求時，也應考量客戶的外在環境、法規及其他限制。 SP 誘導需要 誘導關鍵人員提出有關產品生命週期各階段的需要、期望、限制及介面。 誘導不只是積極界定尚未經客戶明確提出的新增需求。新增的需求應描述各種生命週期的活動，以及它們對產品的影響。 誘導需要的技術，舉例如下： • 技術展示 • 介面管制工作組 • 技術管制工作組 • 中間時期的專案審查 • 由最終使用者取得的問卷、訪談及操作劇本等資料 • 操作的審查和最終使用者的工作分析 • 雛型和模型 • 腦力激盪 • 品質機能展開 • 市場調查 • 試用版本的試用 • 由文件、標準或規格等來源中抽取 • 觀察現行產品、環境及工作流程的樣式(patterns) • 使用案例(use cases) • 經營案例分析 • 採取反向工程(針對現有產品) • 客戶滿意度調查 需求發展(RD) 442
CMMI for Development Version 可能未被客戶界定的需求來源，舉例如下： • 經營策略 • 標準 • 經營環境要求(例：研究室、測試其他設施、資訊科技基礎建設等) • 技術 • 現有產品或產品組件(可再用產品組件) 細部執行方法 1. 與相關的關鍵人員一起參與，並使用方法，以誘導出需求、期望、限制及外部介面。 SP 發展客戶需求 轉換關鍵人員的需要、期望、限制及介面為客戶需求。 來自相關關鍵人員的各種輸入，須經合併、取得遺漏的資訊，以及解決衝突等過程，並記錄為客戶需求。客戶需求可包括與驗證和確認有關的需要、期望及限制。 某些情況來說，客戶提供專案的一套需求，或者之前專案活動的需求產出。以這些情況來說，客戶需求與相關關鍵人員的需要、期望、限制及介面可能有所衝突，所以在衝突適當解決之後，需要轉換成被認可的客戶需求。 代表產品生命週期的所有階段的相關關鍵人員，應包括經營及技術功能。因此，所有與產品生命週期相關的流程概念，都應與產品的概念同步考量。客戶需求來自資訊充分的決策，同時考量需求在經營面與技術面的影響。 典型的工作產品 1. 客戶需求 需求發展(RD) 443
CMMI for Development Version 2. 執行驗證時的客戶限制 3. 執行確認時的客戶限制 細部執行方法 1. 轉換關鍵人員的需要、預期、限制及介面，成為客戶需求。 2. 定義驗證及確認時的限制。 SG 2 發展產品需求 調修並詳細說明客戶需求，以發展產品及產品組件需求。 分析客戶需求並發展操作概念，以衍生更詳細和精準的需求，此需求稱為「產品與產品組件需求」。「產品與產品組件需求」說明產品生命週期每一階段的相關需要。衍生需求是由限制、對某些隱含議題的考量及某些因素而間接產生，這些議題在客戶需求基準中並未明確說明；而這些因素是基於所選用的架構、設計，以及發展者獨特的經營考量等而產生。需求須以後續的、較低階的需求及功能架構再檢查，並調修優先的產品概念。 配置需求於產品功能及產品組件，包括物件、人員及流程，並記錄需求到功能、物件、測試、議題，或其他實體的追溯性。已配置的需求及功能是組成技術解決方案的基礎。當發展內部組件時，須定義新增的介面，並建立介面需求。 有關維護雙向追溯性，請參考需求管理流程領域的「維護需求的雙向追溯性」特定執行方法，以獲得更多資訊。 SP 建立產品與產品組件需求 以客戶需求為基礎，建立並維護產品與產品組件的需求。 客戶需求可能以客戶術語表示，且以較不具技術的方式描述。產品需求則是以專業術語表示這些客戶需求，以用來進行設計的決策。「品質機能展開」 需求發展(RD) 444
CMMI for Development Version 是此轉換的範例，它描述客戶期望與技術參數的對應關係。例如：「結實的門」可能對應到尺寸規模大小、重量、適合、濕度及共振頻率。 「產品與產品組件需求」強調客戶、經營，以及專案目標和相關屬性(如有效性和負擔能力)的滿足。 衍生需求也包括其他生命週期階段的成本和績效(如，生產、操作及銷毀)，以與經營目標相容。 需求管理流程領域涵蓋需求變更的管理，而本特定執行方法的「維護」部分，涵蓋因已核准的需求變更而引起的需求修改活動。 有關管理需求變更，請參考需求管理流程領域，以獲得更多資訊。 典型的工作產品 1. 衍生需求 2. 產品需求 3. 產品組件需求 細部執行方法 1. 以專業術語發展產品與產品組件設計的需求。 針對產品架構設計所需之重要的產品品質和績效，發展架構需求。 2. 由設計決策衍生需求。 有關發展解決方案以產生其他衍生需求，請參考技術解決方案流程領域，以獲得更多資訊。 技術的選用會引進其他的需求。例如：運用電子學將增加特定技術的需求，如電磁干擾的界限。 3. 建立並維護需求間的關連性，並考量在變更管理和需求配置時的影響。 需求發展(RD) 445
CMMI for Development Version 有關維護需求追溯，請參考需求管理流程領域，以獲得更多資訊。 需求間的關連有助於評估變更的影響。 SP 配置產品組件需求 配置產品組件需求。 有關配置需求到產品和產品組件，請參考技術解決方案流程領域，以獲得更多資訊。本執行方法提供資訊以定義需求配置，但必須和技術解決方案流程領域的執行方法互動，以建立配置需求的解決方案。 上述中所定義的解決方案，其產品組件的需求，包括所配置的產品績效、設計限制，以及符合需求和有助於生產的合適、形式及功能。假使較高階需求的指定績效歸屬於兩組或以上的產品組件時，該績效必須進行切割，並單獨配置到各個產品組件，就像是衍生需求一樣。 典型的工作產品 1. 需求配置表 2. 暫時性的需求配置 3. 設計限制 4. 衍生需求 5. 衍生需求間的關係 細部執行方法 1. 配置需求於功能。 2. 配置需求於產品組件。 3. 配置設計限制於產品組件。 4. 記錄已配置需求間的關係。 關係包括依賴性，在這情境下，某需求的改變可能會影響其他的需求。 需求發展(RD) 446
CMMI for Development Version SP 界定介面需求 界定介面需求。 定義功能之間(或物件之間)的介面。功能介面可能衍生出替代方案的發展，替代方案在技術解決方案流程領域中描述。 有關介面管理以及產品和產品組件的整合，請參考產品整合流程領域，以獲得更多資訊。 定義產品架構中所界定之產品與產品組件間的介面需求，並將它們當做產品與產品組件整合的一部分來管制，它們也是架構定義中不可缺少的部分。 典型的工作產品 1. 介面需求 細部執行方法 1. 界定產品內部及外部的介面(例如：功能分割或物件之間的介面)。 在設計工作進行的過程中，產品架構可能受技術解決方案流程的影響，而產生產品組件和專案外部組件間的新介面。 必須界定產品有關之生命週期流程的介面。 與測試設備、傳輸系統、支援系統及製造設施之間的介面，都屬於這類介面。 2. 發展已界定介面的需求。 有關在設計過程中，如何產生介面需求，請參考技術解決方案流程領域，以獲得更多資訊。 例如以軟體的來源、目的地、刺激及資料特徵，和硬體的電子及機械的特徵，來定義介面需求。 需求發展(RD) 447
CMMI for Development Version SG 3 分析並確認需求 分析並確認需求，並發展所要功能的定義。 「分析並確認需求」特定目標的特定執行方法，支援「發展客戶需求」和「發展產品需求」兩個特定目標的需求發展過程。本特定目標的特定執行方法涵蓋需求的分析，以及確認需求是否符合使用者預期。 執行分析，以決定為求滿足關鍵人員的需要、期望、限制及介面，對原計畫的操作環境會產生哪些影響。視產品的範圍而定，可行性、任務需要、經費限制、市場潛力及採購策略等都必須納入考量，並建立必要功能的定義。所有產品的特定使用形式均應考量，並產生對時間敏感之功能順序的時間點分析。 分析的目的，在於決定可滿足關鍵人員需要、期望及限制之產品概念的可能需求，再將這些概念轉換為需求。與此活動同時進行的是，依據客戶的輸入和初步的產品概念，決定用以評估產品有效性的參數。 確認需求，以增加最終產品在使用環境中，可按照期望運作的可能性。 SP 建立操作概念及劇本 建立並維護操作概念及其相關的劇本。 劇本一般而言是指使用產品時可能發生的事件順序，以明確說明關鍵人員的某些需要。相對的，產品的操作概念通常是依據設計方案和劇本而來。例如：衛星的通訊產品與地面的通訊產品，它們的操作概念是不同的。在研擬原始操作概念時，其替代方案通常尚未定義。所以，在需求分析時，發展概念性的解決方案。在進行解決方案的決策時，調修操作概念，進而發展出細部的需求。 正如某產品的設計決策可能變成產品組件需求，操作概念也可能變成產品組件的劇本(需求)。發展操作 需求發展(RD) 448
CMMI for Development Version 概念及劇本逐步發展，以利產品組件解決方法的選擇，使得在實作後將滿足產品的預期使用。不管哪一種工程，操作概念及劇本描述了產品組件與環境、使用者，及其他產品組件的互動關係。包括營運、產品推展、交付、支援（含維護及營運）、訓練、處置，以及所有的模式和狀態等相關的操作概念與劇本，都應予以描述。 如果操作順序用以表達客戶需求而非操作概念，則劇本可能包含了操作順序。 典型的工作產品 1. 操作概念 2. 產品或產品組件安裝、操作、維護及支援概念 3. 銷毀概念 4. 使用案例 5. 依時間演化的劇本 6. 新需求 細部執行方法 1. 發展操作概念和劇本，包括適當的功能、績效、維護、支援及銷毀。 界定並發展劇本，此劇本須與關鍵人員各細部層級的需要、預期及限制一致。經此建議的產品或產品組件應可如預期運作。 2. 定義產品或產品組件的操作環境，包括界限和限制。 3. 審查操作概念和劇本，以調修需求並發現新需求。 操作概念和劇本的發展是個反覆的過程。應定期舉行審查，以確保其結果與需求一致。審查可採用逐步審查的形式。 需求發展(RD) 449
CMMI for Development Version 4. 產品與產品組件一經選定，就發展詳細的操作概念，以定義產品、最終使用者及環境之互動，並滿足操作、維護、支援及銷毀的需要。 SP 建立必要的功能定義 建立並維護必要的功能定義。 功能的定義，也就是所謂的「功能分析」，描述哪些是產品預期該做的，包括，行動、順序、輸入、輸出，或其他說明如何使用產品的資訊。 功能分析與軟體發展的結構化分析不同，也不能假定為功能導向的軟體設計。在物件導向的軟體設計裡，它相當於定義所謂的服務或方法。功能、功能的邏輯群組，以及它們和需求之關連的定義，就是所謂的「功能架構」。有關「功能架構」的定義，請參見詞彙。 典型的工作產品 1. 功能架構 2. 活動圖和使用案例 3. 物件導向分析和已界定的服務或方法 細部執行方法 1. 分析和量化最終使用者需要的功能。 2. 分析需求，以界定邏輯或功能分割(如子功能)。 3. 依已建立的準則(如類似的功能、績效或耦合)，將需求分割成群組，以促進和專注於需求分析。 4. 在產品發展的整個過程，考量具有時效性之功能的順序。 5. 配置客戶需求於功能分割、物件、人員或支援元件，以支援解決方案的綜合。 6. 配置功能及績效需求於功能及子功能。 需求發展(RD) 450
CMMI for Development Version SP 分析需求 分析需求，以確保其必要性和充分性。 在操作概念和劇本的說明下，分析在產品架構某一階的需求，以決定其是否必要且可滿足較高階的目標。經過分析的需求就變成產品架構中較低階需求的基礎，而較低階的需求通常是更詳細且精準的。 定義需求時，必須能瞭解它與更高階需求和已定義功能的關係。決定應界定哪些需求，以追蹤技術的進展，也是重要的行動之一。例如：在整個發展過程，產品的重要性或軟體產品的規模大小，可依其風險程度加以監控。 有關用於支援此分析的驗證方法，請參考驗證流程領域，以獲得更多資訊。 典型的工作產品 1. 需求缺失報告 2. 用來解決缺失的需求變更建議 3. 關鍵需求 4. 技術績效度量 細部執行方法 1. 分析關鍵人員的需要、期望、限制及外部介面，以移除矛盾，並彙整成相關主題。 2. 分析衍生需求，以決定是否滿足更高階需求的目標。 3. 分析需求，以確保是完整、可行、可實現及可驗證的。 雖然「設計」決定某特殊解決方案的可行性，本細部執行方法可以了解哪些需求會影響可行性。 4. 界定對成本、時程、功能、風險或績效有重大影響的關鍵需求。 需求發展(RD) 451
CMMI for Development Version 5. 界定技術績效度量，以便於發展階段時進行追蹤。 有關度量的用途，請參考度量與分析流程領域，以獲得更多資訊。 6. 分析操作觀念及劇本，以調修客戶需要、限制及介面，並發現新需求。 此分析可能產生更詳細的操作觀念及劇本，同時也衍生新需求。 SP 分析需求以取得平衡 分析需求，並在關鍵人員的需要和限制間取得平衡。 關鍵人員的需要和限制，可說明成本、時程、績效、功能、再使用的組件、維護能力，或風險。 典型的工作產品 1. 需求相關風險的評量 細部執行方法 1. 使用經驗證的模型、模擬及雛型等，以分析關鍵人員之需要和限制間的平衡。 分析的結果，可用以降低產品的成本與發展產品時的風險。 2. 執行需求及功能架構的風險評量。 有關執行客戶及產品需求和功能架構的風險評量，請參考風險管理流程領域，以獲得更多資訊。 3. 檢查產品生命週期概念，以分析它對需求風險的影響或衝擊。 SP 確認需求 確認需求以確保最終產品在使用者環境下如預期的運作。 需求發展(RD) 452
CMMI for Development Version 在發展工作的初期，與最終使用者執行需求確認，俾使需求能夠引導發展工作，並導致成功之最終確認的信心。此活動應與風險管理活動整合。成熟的組織，通常會以更複雜的方式使用多種技術來執行需求確認，擴大確認的基礎，以包括其他的關鍵人員需要和期望。這些組織通常會使用分析、模擬或雛型等方法，以確保需求滿足關鍵人員的需要和期望。 需求確認的技術，舉例如下： • 分析 • 模擬 • 雛型 • 示範 典型的工作產品 1. 分析方法和結果的紀錄 細部執行方法 1. 分析需求以界定最終產品不能於使用者環境下適當運作的風險。 2. 以產品展示(如，雛型、模擬、模型、情境及場景)，以及取得相關關鍵人員的回饋，尋求需求的足夠性和完整性。 有關產品及產品組件的確認及確認執行，請參考確認流程領域，以獲得更多資訊。 3. 於設計成熟時，在需求確認環境下進行設計的評量，以界定確認議題，並揭露未敘明的需要和客戶需求。 需求發展(RD) 453
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將可界定之輸入的工作產品轉換為可界定之輸出的工作產品，以支援與促成該流程領域之特定目標的達成。 GP 實施特定執行方法 實施需求發展流程的特定執行方法來發展工作產品與提供服務，以達成該流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 僅適用於階段式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行需求發展流程。 詳細說明： 本政策建立組織對下列活動的期望：蒐集關鍵人員需要、明確地陳述產品及產品組件需求，以及分析和確認需求。 GP 規劃流程 建立並維護執行需求發展流程的計畫。 需求發展(RD) 454
CMMI for Development Version 詳細說明： 執行需求發展的計畫可以是專案計畫的一部分，專案計畫在專案規劃流程領域中說明。 GP 提供資源 提供充足的資源，以執行需求發展流程、發展工作產品及提供流程服務。 詳細說明： 應用領域的特殊專業知識、誘導關鍵人員需要的方法，用於指定及分析客戶、產品，以及產品組件需求的方法及工具等可能是必要的。 可用於本流程領域的資源(工具)，舉例如下： • 需求規格工具 • 模擬及模型工具 • 雛型工具 • 劇本定義及管理工具 • 需求追蹤工具 GP 指派責任 指派需求發展流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援需求發展流程。 需求發展(RD) 455
CMMI for Development Version 詳細說明： 訓練主題，舉例如下： • 應用領域的專業知識 • 需求定義及分析 • 需求誘導 • 需求規格及模型 • 需求追蹤 GP 管理建構 將指定的需求發展流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 客戶需求 • 功能架構 • 產品及產品組件需求 • 介面需求 GP 界定並納入相關的關鍵人員 依計畫界定並納入需求發展流程相關的關鍵人員。 詳細說明： 從下列人員中選擇相關的關鍵人員：客戶、最終使用者、發展人員、製作人員、測試人員、供應商、市場行銷人員、維護人員、報廢處理人員，以及其他會影響產品及流程或受產品及流程所影響的人。 需求發展(RD) 456
CMMI for Development Version 關鍵人員參與的活動，舉例如下： • 審查需求的足夠性，以滿足需要、預期、限制及介面的要求。 • 建立操作觀念和劇本 • 評量需求的足夠性 • 建立產品與產品組件需求 • 評量產品成本、時程及風險 GP 監控流程 依本流程的執行計畫，監控需求發展流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量及工作產品，舉例如下： • 成本、時程及重做所需的工作量 • 需求規格的缺失密度 • 發展一組需求的活動時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估需求發展流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 蒐集關鍵人員需要 • 明確地陳述產品與產品組件需求 • 分析並確認產品與產品組件需求 需求發展(RD) 457
CMMI for Development Version 審查的工作產品，舉例如下： • 產品需求 • 產品組件需求 • 介面需求 • 功能架構 GP 與上層管理人員審查各狀況 與上層管理人員審查需求發展流程的活動、狀況及結果，並解決問題。 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義需求發展流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行需求發展流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產未來的使用與改善。 詳細說明： 工作產品、度量、度量結果及改善資訊，舉例如下： • 含糊不清的產品需求清單 • 產品生命週期各階段的需求數量 • 需求配置流程的經驗分享 需求發展(RD) 458
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護需求發展流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定需求發展流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保需求發展流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正需求發展流程之缺失與其他問題的根本原因。 需求發展(RD) 459
CMMI for Development Version 需求管理 成熟度第二級的工程類流程領域 目的 需求管理(Requirements Management, REQM)的目的，在於管理專案產品及產品組件的需求，並界定這些需求與專案計畫及工作產品間的差異。 簡介 「需求管理流程」管理專案所發展或收受的技術性、非技術性需求，以及組織加在專案的需求。尤其是如果組織實施「需求發展」流程領域，它的流程所產生的產品及產品組件需求，也要納入需求管理流程的管理。在所有的流程領域中，當使用產品及產品組件這個專門名詞時，也意指包含服務及其組件的意思。當組織實施需求發展、需求管理及技術解決方案等流程領域，它們相關的流程將會緊密聯繫並同步執行。 專案採行適當的步驟，確保議定的需求是受管理的，以支援專案規劃和執行的需要。當專案從已核定的需求提供者收受需求時，應與其一起審查，以便在需求納入專案計畫前，先行解決有關議題並避免誤解。一旦需求提供與接受的雙方達成協議，須再取得專案成員對需求的承諾。當需求漸進發展時，專案須管理需求的變更，並界定計畫、工作產品，以及需求間可能產生的差異。 需求管理也須記錄需求變更及其理由，並維護原始需求與所有產品和產品組件需求之間的雙向追溯性。(「雙向追溯性」的定義，請參考詞彙。) 所有發展專案都有需求。以專注於維護活動的專案來看，產品或產品組件的變更是基於現有需求、設計及開發的變更。如有需求變更，可能是記錄在客 需求管理(REQM) 460
CMMI for Development Version 戶或使用者的變更請求上，也可能是從需求發展流程中所產生的新需求。不論來源或形式，因需求變更所引起的維護活動，應依此原則管理。 相關流程領域 有關將關鍵人員之需要轉成產品需求，以及決定如何將需求配置於產品組件，請參考需求發展流程領域，以獲得更多資訊。 有關將需求轉為技術解決方案，請參考技術解決方案流程領域，以獲得更多資訊。 有關專案計畫如何反映需求，以及專案計畫如何因需求變更而修訂，請參考專案規劃流程領域，以獲得更多資訊。 有關基準和如何管制需求的建構文件的變更，請參考建構管理流程領域，以獲得更多資訊。 有關以需求為基礎的專案活動和工作產品之追蹤與控制，以及採取適當的矯正措施，請參考專案監控流程領域，以獲得更多資訊。 有關與需求有關的風險界定與處理，請參考風險管理流程領域，以獲得更多的資訊。 需求管理(REQM) 461
CMMI for Development Version 特定目標及執行方法摘要 SG 1管理需求 SP 瞭解需求 SP 取得需求承諾 SP 管理需求變更 SP 維護需求的雙向追溯性 SP 界定專案工作與需求間的差異 各目標的特定執行方法 SG 1 管理需求 管理需求，並界定需求與專案計畫及工作產品間之差異。 本執行方法藉由進行下列活動，使專案能全程維護一組最新及已核定的需求： • 管理所有的需求變更 • 維護需求、專案計畫及工作產品間的關係 • 界定需求、專案計畫及工作產品間的差異 • 採取矯正措施 有關決定需求的可行性，請參考技術解決方案流程領域，以獲得更多資訊。 有關確保需求能反映客戶的需要和期望，請參考需求發展流程領域，以獲得更多資訊。 有關採取矯正措施，請參考專案監控流程領域，以獲得更多資訊。 SP 瞭解需求 與需求提供者一起瞭解需求之意義。 當專案成熟且需求已衍生後，全部的專案活動或專業領域將收受需求。要避免需求不知不覺的到來，須建立準則，以指定需求收受的適當管道和正式的來源。執行需求收受活動時，須與需求提供者一起 需求管理(REQM) 462
CMMI for Development Version 分析需求，以確保對需求的意義能達成共識。此分析和對話的結果，才是被議定的需求。 典型的工作產品 1. 區別適當需求提供者的準則清單 2. 需求評估和接受準則 3. 依準則進行分析的結果 4. 經議定的需求 細部執行方法 1. 建立區別適當需求提供者的準則清單。 2. 建立客觀的需求評估及接受準則。 缺乏評估及接受準則常常導致需求確認不夠充分、昂貴的重做成本，或客戶退件。 需求評估及接受準則，舉例如下： • 清晰而適當地表達 • 完整 • 相互的一致性 • 可個別界定 • 可適當地實作 • 可驗證(可測試) • 可追溯 3. 分析需求，以確保其符合已建立之準則的要求。 4. 與需求提供者達成需求共識，使專案成員可對需求承諾。 SP 取得對需求的承諾 取得專案成員對需求的承諾。 需求管理(REQM) 463
CMMI for Development Version 有關承諾的監督，請參考專案監控流程領域，以獲得更多資訊。 IPPD補充 組成整合團隊(integrated teams)時，專案成員就是整合團隊和其成員。對其他整合團隊的互動也是一項需求，對此需求的承諾，其重要性一如對產品及其他專案需求的承諾一般。 上一個特定執行方法用於處理如何與需求提供者達成需求的瞭解，本特定執行方法則處理如何取得專案成員的承諾和同意，這些專案成員是負責執行需求之必要活動的人員。在專案進行期間，需求將漸進發展，尤其是在需求發展流程領域和技術解決方案流程領域之特定執行方法的說明中。在需求逐漸發展的情況下，本特定執行方法確保專案成員對當時已核可需求的承諾，以及對專案計畫、活動及工作產品所造成之變更的承諾。 典型的工作產品 1. 需求影響評量(Requirements impact assessments) 2. 需求和需求變更承諾的紀錄 細部執行方法 1. 評量需求對現有承諾的影響。 需求變更或新需求發生時，評估其對專案成員的影響。 2. 協商並記錄承諾。 在專案成員對需求或需求改變承諾之前，對現有承諾的改變，應先協商。 SP 管理需求變更 當需求於專案執行期間漸進發展時，管理需求的變更。 需求管理(REQM) 464
CMMI for Development Version 有關維護和控制需求基準，並使需求及其變更資料能為專案運用，請參考建構管理流程領域，以獲得更多資訊。 在專案執行期間，造成需求變更的原因甚多。當需要改變或工作進行中衍生新需求時，就可能需要變更現有的需求。如何有效率和有效果地管理這些新增需求或變更需求是很重要的。要有效分析變更所造成的影響，必須知道每一需求項目的來源，並記錄變更的原因。然而，專案經理或許要追蹤需求變更程度的適當度量，以決定是否要實施新的或修訂現有的控制方式。 典型的工作產品 1. 需求狀況表 2. 需求資料庫 3. 需求決策資料庫 細部執行方法 1. 記錄所有的需求和需求變更，不論是專案本身產生的或外界的要求。 2. 維護需求變更紀錄，以及每次變更的理由。 維護變更的歷史紀錄，有助於追蹤需求變更的狀況。 3. 從相關關鍵人員的觀點，評估需求變更的影響。 4. 確保專案人員能取得需求和變更的資料。 SP 維護需求的雙向追溯性 維護需求與工作產品間的雙向追溯性。 本特定執行方法的目的，在於維護每一階產品組件需求的雙向追溯性。(「雙向追溯性」的定義，請參考詞彙。)當有效地管理需求，就可建立從原始需求至低階需求的追溯性，亦可建立由低階需求至原始需求的追溯性。如此一來，雙向追溯性可協助確定需求管理(REQM) 465
CMMI for Development Version 已處理所有原始需求，以及所有低階需求皆可追溯至有效的來源。 需求追溯性也可以涵蓋與其他實體的關係，例如：中間和最終產品、設計文件的變更、測試計畫及工作項目。追溯性應包括水平及垂直關係，例如：跨介面。在進行需求變更對專案計畫、活動及工作產品的影響評量時，特別需要追溯性。 典型的工作產品 1. 需求追溯表 2. 需求追蹤系統 細部執行方法 1. 維護需求追溯性，確保已記錄低階(或衍生)需求的來源。 2. 維護需求追溯性，從需求到衍生需求，以及需求配置到功能、介面、物件、人員、流程及工作產品。 3. 製作需求追溯表。 SP 界定專案工作與需求間的差異 界定需求與專案計畫及工作產品間的差異。 有關監控專案計畫及工作產品與需求是否一致，以及視需要採取矯正措施，請參考專案監控流程領域，以獲得更多資訊。 本特定執行方法用以找出需求與專案計畫及工作產品間的差異，並啟動修正的矯正措施。 典型的工作產品 1. 差異紀錄，包括差異來源、條件及理由 2. 矯正措施(corrective actions) 需求管理(REQM) 466
CMMI for Development Version 細部執行方法 1. 審查專案計畫、活動及工作產品，是否與需求及需求變更相符。 2. 界定差異來源及其理由。 3. 當需求基準有變動時，界定有關計畫及工作產品所需的變更。 4. 啟動矯正措施。 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程藉由將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施需求管理管理流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 GP 建立組織政策 建立並維護組織政策，以規劃和執行需求管理流程。 詳細說明： 本政策建立組織對下列活動的期望：管理需求，以及界定需求與專案計畫及工作產品間的差異。 GP 規劃流程 建立並維護執行需求管理流程的計畫。 需求管理(REQM) 467
CMMI for Development Version 詳細說明： 執行需求管理的計畫通常是專案計畫的一部分(或可參照)，專案計畫在專案規劃流程領域中說明。 GP 提供資源 提供充足的資源，以執行需求管理流程、發展工作產品及提供流程服務。 詳細說明： 可用於本流程領域的資源(工具)，舉例如下： • 需求追蹤工具 • 追溯工具 GP 指派責任 指派需求管理流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援需求管理流程。 詳細說明: 訓練的主題，舉例如下： • 應用領域的專業知識 • 需求定義、分析、審查及管理 • 需求管理工具 • 建構管理 • 談判及衝突解決 GP 管理建構 將指定的需求管理流程工作產品，納入適當層級的控制。 需求管理(REQM) 468
CMMI for Development Version 詳細說明： 納入控制的工作產品，舉例如下： • 需求 • 需求追溯表 GP 界定並納入相關的關鍵人員 依計畫界定並納入需求管理流程相關的關鍵人員。 詳細說明： 從下列人員中選擇相關的關鍵人員：客戶、最終使用者、發展人員、製作人員、測試人員、供應商、市場行銷人員、維護人員、報廢處理人員，以及其他會影響產品及流程或受產品及流程所影響的人。 關鍵人員參與的活動，舉例如下： • 解決需求瞭解的議題 • 評量需求變更的影響 • 溝通雙向追溯性 • 界定專案計畫、工作產品及需求間的差異 GP 監控流程 依本流程的執行計畫，監控需求管理流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量及工作產品，舉例如下： • 需求變動率(即需求變更的百分比) • 需求協調的時程 • 所建議的需求變更的分析時程 需求管理(REQM) 469
CMMI for Development Version GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估需求管理流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 管理需求 • 界定專案計畫、工作產品及需求間的差異 審查的工作產品，舉例如下： • 需求 • 需求追溯表 GP 與上層管理人員審查各狀況 與上層管理人員審查需求管理流程的活動、狀況及結果，並解決問題。 詳細說明： 針對組織外部承諾的變更建議，必須與上層管理人員審查，以確保所有的承諾可以完成。 僅適用於階段式表述 GG3及其執行方法，不是成熟度第二級評等的必要項目，但它們是成熟度第三級和更高等級評等的必要組件。 需求管理(REQM) 470
CMMI for Development Version 僅適用於連續式/成熟度第3-5級 GG 3 制度化已定義流程 將流程制度化為已定義流程。 GP 建立已定義流程 建立並維護已定義需求管理流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行需求管理流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產未來的使用與改善。 詳細說明： 工作產品、度量、度量結果及改善資訊，舉例如下： • 需求追溯表 • 基準設定後，無費用的需求變更數量 • 解決含糊不清需求的經驗分享 需求管理(REQM) 471
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護需求管理流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定需求管理流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保需求管理流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正需求管理流程之缺失與其他問題的根本原因。 需求管理(REQM) 472
CMMI for Development Version 風險管理 成熟度第三級的專案管理累流程領域 目的 風險管理(Risk Management, RSKM)的目的是在風險發生前，界定出潛在的問題，以便在產品或專案的生命週期中規劃風險處理活動，並於必要時啟動之，如此可將不利於完成目標的影響降低。 簡介 風險管理是一個持續的、前瞻的流程，此流程是管理的重要部分。風險管理應該強調可能會危害到重要目標的議題。持續的風險管理方法可以有效預測並降低對專案有重大影響的風險。 有效的風險管理是透過相關的關鍵人員的合作與參與，及早且積極的界定風險，如同專案規劃流程領域所述的「關鍵人員參與計畫」一樣。需要具備領導相關關鍵人員的優越領導能力，以建立自由、公開及討論風險的環境。 風險管理須同時考慮有關成本、時程、績效及其他風險的內部及外部來源。因為在專案初期進行變更或修正的工作負荷，通常比在專案後期來得容易、花費較低及較不具破壞性，所以，早期及積極的風險偵測是重要的。 風險管理可以區分成三部分：定義風險管理策略、界定及分析風險，以及處理已界定的風險，包括必要時，執行風險降低計畫。 如同專案規劃流程領域和專案監控流程領域所示，組織初期可能只專注於界定風險，以及當這些風險發生時採取行動。風險管理流程領域描述這些特定執行方法之演進，以有系統的規劃、預測及降低風險，使對專案的衝擊降至最低。 風險管理(RSKM) 473
CMMI for Development Version 雖然風險管理流程領域主要強調的是專案，但觀念亦可應用在管理組織的風險。 相關流程領域 有關專案風險界定及關鍵人員參與的規劃，請參考專案規劃流程領域，以獲得更多資訊。 有關監控專案風險，請參考專案監控流程領域，以獲得更多資訊。 有關使用正式評估流程以評估選擇及降低已界定風險的備選方案，請參考決策分析和解決方案流程領域，以獲得更多資訊。 風險管理(RSKM) 474
CMMI for Development Version 特定目標和執行方法摘要 SG 1風險管理準備 SP 決定風險來源和類別 SP 定義風險參數 SP 建立風險管理策略 SG 2界定並分析風險 SP 界定風險 SP 評估、分類及排序風險 SG 3降低風險 SP 發展風險降低計畫 SP 執行風險降低計畫 各目標的特定執行方法 SG 1 風險管理準備 準備執行風險管理。 建立並維護用來界定、分析及降低風險的策略，以執行風險管理的準備工作。風險管理策略通常記錄於風險管理計畫中。風險管理策略說明用來控制風險管理計畫的特定活動和管理方法。這包括界定風險來源、風險分類的計畫，以及用來有效處理評估、限定和控制風險的參數。 SP 決定風險來源和類別 決定風險來源和類別。 界定風險來源提供一種基礎，以系統化檢視隨時間而改變的狀況，發覺影響專案達成目標的情況。風險來源來自專案的內部及外部。在專案進行過程中，可能界定其他的風險來源。建立風險類別提供一種機制以蒐集和組織風險，並對比較嚴重影響專案目標的風險，保持適當的警覺和注意。 典型的工作產品 1. 風險來源清單(內部及外部) 風險管理(RSKM) 475
CMMI for Development Version 2. 風險類別清單 細部執行方法 1. 決定風險來源。 風險來源是專案或組織內造成風險的基本因素，專案有許多內部及外部的風險來源。風險來源是界定風險發生的共同來源，典型的內部及外部風險來源包括下列各項： • 不確定的需求 • 無前例的工作量─無法取得預估值 • 不可行的設計 • 不存在的技術 • 不實際的時程估計值或配置 • 不充分的人員配置和技能 • 成本或資金議題 • 不確定或不充分的分包商能力 • 不確定或不充分的供應商能力 • 與實際或潛在客戶，或與業務代表的不充分溝通 • 營運連續性的中斷 很多風險來源經常未做充分規劃就已被接受。越早界定內部和外部的風險來源，即可儘早界定風險，並在專案初期執行風險降低計畫，以排除風險的發生，或降低發生時的嚴重性。 2. 決定風險類別。 風險類別表達「貯存倉」的概念，用來蒐集和組織風險。界定風險類別的原因之一是它可協助未來整合風險降低計畫的各項活動。 風險管理(RSKM) 476
CMMI for Development Version 決定風險類別時，可考慮下列因素： • 專案生命週期模式的各階段(如：需求、設計、製造、測試與評估、交付、汰除) • 使用的流程類型 • 使用的產品類型 • 計畫管理的風險(如：合約風險、預算/成本風險、時程風險、資源風險、績效風險、支援能力的風險) 風險分類表可作為風險來源和類別的架構。 SP 定義風險參數 定義用來分析及分類風險的參數，以及用以管制風險管理投入的參數。 用來評估、分類和排序風險的參數，包括下列各項： • 風險可能性(即風險發生的機率) • 風險結果(即風險發生的影響和嚴重性) • 驅動管理活動的門檻 風險參數提供共通且一致的準則，用以比較需要管理的各種風險。沒有這些參數，則由風險導致的非預期變更，將很難估計其嚴重程度；在風險降低計畫中，也很難排定必要行動的優先順序。 典型的工作產品 1. 風險評估、分類及排定優先順序的準則 2. 風險管理需求(例：控制與核准層級、再評量的時間間隔等) 細部執行方法 1. 定義一致性的準則，以評估及量化風險的可能性及嚴重程度。 風險管理(RSKM) 477
CMMI for Development Version 透過使用一致性的準則(例如：可能性和嚴重程度的範圍)，可共同瞭解不同風險之衝擊，使能適度的檢查，並保證獲得管理者注意。在管理不同的風險方面(例如：人員安全相對於環境污染)，保證最終結果的一致性是重要的(例如：環境污染的高風險和人員安全的高風險一樣重要)。 2. 定義每個風險類別的門檻。 對每一風險類別，可建立門檻以決定風險的可接受性或不可接受性、風險的優先順序，或管理行動啟動裝置。 門檻的範例，舉例如下： • 專案門檻值可建立為：當產品成本超過目標成本百分之10，或當成本績效指標(CPI)降到以下時，可與資深管理階層共同研商。 • 時程門檻值可建立為：當時程績效指標(SPI)降到以下時，可與資深管理階層共同研商。 • 績效門檻值可建立為：當關鍵項目(如處理器使用率或平均反應時間)超過預期設計的百分之125以上，可與資深管理階層共同研商。 對每個已界定的風險，建立若干個監控點，以更積極的監控風險，或通知執行降低風險計畫。這些數值日後可再調修。 3. 定義某風險類別門檻的範圍。 並未限制風險以量或質的方式評量。範圍的定義(或範圍的條件)，可用來限定風險管理投入程度，以避免資源過度消耗。範圍的訂定，可排除某個類別的風險來源，亦可排除任何發生小於某個頻率的情況。 風險管理(RSKM) 478
CMMI for Development Version SP 建立風險管理的策略 建立並維護風險管理的策略。 周詳風險管理策略說明的事項如下： • 風險管理投入的範圍 • 使用於風險界定、風險分析、風險降低、風險監控及溝通的方法及工具 • 專案特定的風險來源 • 如何組織、分類、比較及整合風險 • 對已界定風險採取行動的參數，包括可能性、結果及門檻 • 風險降低所使用的技術，例如：雛型製作、試行、模擬、備選方案設計或漸進式發展 • 定義風險度量，以監控風險狀況 • 風險監控或再評量的時間間隔 風險管理策略應由共同的成功願景所導引，這願景從交付產品、成本及對任務之適用性的觀點，來描述對未來專案結果的期望。風險管理策略通常記錄於組織或專案的風險管理計畫。風險管理策略由相關的關鍵人員審查，以增進承諾和瞭解。 典型的工作產品 1. 專案風險管理策略 SG 2 界定並分析風險 界定並分析風險，以決定其相對的重要性。 風險的嚴重程度會影響用於處理已界定風險的資源，以及何時需要適當之管理階層關切的決定。 分析風險需要自已經界定的內外部來源界定風險，而後評估每一風險，以決定可能性和發生結果。風險分類提供處理風險所需的資訊，它是依據已建立的風險類別，以及風險管理策略所發展的準則來進行評估。為了有效率的處理和有效的應用風險管理資源，可把相關風險組成不同的群組。 風險管理(RSKM) 479
CMMI for Development Version SP 界定風險 界定並記錄風險。 IPPD 補充 需考慮整合團隊執行專案時的特殊風險，例如：團隊外部或團隊內部間失去協調所導致的風險。 界定可能會負面影響工作投入或計畫的潛在問題、危險、威脅及弱點等，是完整及成功的風險管理的基礎。必須先用容易明瞭的方式，界定與描述風險，才可以適當的分析與處理風險。用簡潔的敘述記錄風險，包括風險發生的內容、條件及結果。 風險界定應是有組織及透徹的方法，以找出在達成目標的過程中可能發生或實際的風險。為了有效起見，風險界定不應試圖說明每一可能事件，而無論其是否極不可能發生。使用由風險管理策略發展出來的類別與參數，以及已界定的風險來源，可提供適用於風險界定的規範及效率。已界定的風險是啟動風險管理活動的基準。風險清單應定期審查，以重新檢查可能的風險來源和狀況變更，以揭露自風險管理策略前次更新以來，忽略或不存在的風險與來源。 風險界定活動著重於風險的界定，而非給予責難，管理者不應使用風險界定活動的結果來評估個人的績效。 界定風險的方法有很多，典型的界定方法如下： • 檢查專案分工結構圖的每個元件以找出風險。 • 使用風險分類表來評量風險。 • 訪談主題事務專家。 • 由類似產品的比較來審查風險管理投入。 • 檢查學習心得文件或資料庫。 • 檢查設計規格和協議書需求。 風險管理(RSKM) 480
CMMI for Development Version 典型的工作產品 1. 已界定的風險清單，包括風險發生的內容、條件及結果。 細部執行方法 1. 界定與成本、時程及績效相關的風險。 檢查成本、時程及績效風險對專案目標的衝擊程度。可能有潛在風險不在專案目標的範圍內，卻對客戶的利益非常重要。例如：發展成本、產品取得成本、備品(或替代品)成本及產品處理(汰除)成本等風險隱含在設計中。客戶可能並未考慮到支援現場產品或交付服務的所有成本。客戶雖然未必需要主動管理那些風險，但應被告知風險。適當時，應該在專案和組織層級，檢查並實施此種決策的機制，尤其是對於影響驗證與確認產品能力的風險。 除了以上所界定的成本風險外，其它的成本風險包含與贊助資金額、資金估計及預算分配有關的議題。 時程風險包括與規劃的活動、主要事件及里程碑相關的風險。 績效風險包含與下列相關的風險： • 需求 • 分析與設計 • 新技術應用 • 實體規模大小 • 形狀 • 重量 • 生產與製造 • 功能績效及操作 • 驗證 • 確認 風險管理(RSKM) 481
CMMI for Development Version • 績效維護屬性 績效維護屬性是指某些特徵，這些特徵會讓使用中的產品或服務保有原先所要求的績效，例如：維持安全和保密績效。 還有其他非屬成本、時程或績效上的風險類別。 以下是其他風險的範例： • 與罷工相關的風險 • 供應來源縮減 • 科技循環時間 • 競爭 2. 審查可能影響專案的環境因素。 專案經常疏忽的風險，包含那些被認為在專案範圍外的風險(即專案無法控制他們是否發生，但可降低其衝擊)，例如：天氣，影響營運持續性的自然或人為災害，政治變化及電信故障。 3. 審查分工結構圖所有元件，作為風險界定的一部分，以協助確保所有的工作投入均已考慮。 4. 審查專案計畫的所有元件，做為風險界定的一部分，以確保專案在各方面均已考慮。 有關界定專案風險，請參考專案規劃流程領域，以獲得更多資訊。 5. 記錄風險之內容、條件及可能的結果。 風險說明通常以標準的格式記錄，包含風險內容、條件及發生的結果。風險內容提供額外的資訊，可容易瞭解風險的意義。在記錄風險內容時，要考慮風險出現的相對時間順序，以及風險週遭的環境或條件，因風險會帶來關切、疑慮或不確定性。 6. 界定每一風險相關的關鍵人員。 風險管理(RSKM) 482
CMMI for Development Version SP 評估、分類及排序風險 利用定義的風險種類及參數，評估及分類每個已界定的風險，並決定其相對的優先處理順序。 在指定每個已界定的風險相對的重要性時需要風險評估，以決定在何時需給予適當的管理階層注意。依據風險間相互關係將風險匯集起來，並於某匯集層級上發展方案，通常是有用的。當一個風險由較低層級風險向上彙集而形成時，必須小心謹慎，以確保未忽略重要之較低層級的風險。 總體來說，風險評估、分類及排序的活動，有時被稱為「風險評量」或「風險分析」。 典型的工作產品 1. 風險清單，包含各風險的優先順序 細部執行方法 1. 利用已定義的風險參數，評估已界定的風險。 根據定義的風險參數，評估每個風險並指定數值，數值可包括可能性、結果(嚴重性或衝擊度)及門檻。可整合這些指定的風險參數值以產生額外的度量，例如：風險曝光程度可用來排列風險的優先順序，以便處理。 通常具有3到5個數值的量尺，可用來評估可能性和結果。例如：可能性可分類為微乎其微、不太可能、可能、非常可能，或近乎確定。 風險管理(RSKM) 483
CMMI for Development Version 結果(嚴重性或衝擊度)的範例，舉例如下： • 低 • 中 • 高 • 可忽略 • 微小 • 重要 • 嚴重 • 災難 機率值經常用來量化可能性。結果通常和成本、時程、環境衝擊或人員度量值相關(例：人力時間損失和傷害的嚴重程度)。 此評估經常是困難且費時的工作，可能需要特定的專門知識或群組技術，以評量風險和獲得對排定優先順序的信心。此外，優先順序隨著時間進展可能需要重新評估。 2. 依照定義的風險類別，將風險分類並分組。 將風險歸類到已定義的風險類別，可提供一個根據風險的來源、分類表或專案組件，檢查風險的方法。相關或相同的風險可歸成一類，以便有效處理，並記錄相關風險之間的因果關係。 3. 排列降低風險的優先順序。 依據指定的風險參數，決定每個風險相對的優先順序，應使用清楚的準則來決定風險的優先順序。排定優先順序的目的是為了確定降低風險的資源能用在最有效的範圍，使其對專案有最大的正面影響。 風險管理(RSKM) 484
CMMI for Development Version SG 3 降低風險 適當地處理及降低風險，以減少對目標達成的不利衝擊。 處理風險的步驟，包括研訂風險處理方案、監控風險，以及超過所定義的門檻時，執行風險處理活動。對於選定的風險，應研訂和執行風險降低計畫，以主動減少風險發生的潛在衝擊。除試圖降低風險，亦應包括緊急應變計畫(contingency plan)，以處理可能發生的風險衝擊。在風險管理策略中，定義啟動風險處理活動的風險參數。 SP 研訂風險降低計畫 依風險管理策略所定義之對專案影響最大的風險，研訂風險降低計畫。 針對每個關鍵性的風險，研訂可選擇的活動、替代方案、返回點，並對每個風險皆有建議的行動過程，是風險降低計畫的關鍵組件。特定風險的風險降低計畫包括規避、降低及控制風險發生可能性的技術和方法，或風險發生時遭受的損失程度(有時稱作「緊急應變計畫」)，或上述兩者。監控風險，當風險超過設定的門檻時，展開風險降低計畫，以使受衝擊的部分回歸到可接受的風險等級。只有風險結果評定為高或無法接受時，才對該風險研訂風險降低計畫和緊急應變計畫，其它的風險可能僅是接受，並簡單地監控。 風險處理方案，通常包括下列各種備選方案： • 風險規避：改變或降低需求，但仍符合使用者需要 • 風險控制：採取主動的步驟，以降低風險 • 風險移轉：重新配置設計需求，以降低風險 • 風險監控：就指定之風險參數的變化，觀察並定期重新評估風險 • 風險接受：對風險有認知，但不採取任何動作 通常，特別針對「高」風險，應產生一種以上的風險處理方法。 風險管理(RSKM) 485
CMMI for Development Version 在中斷營運持續力的案例中，風險管理的處理方法舉例如下： • 保留資源以因應中斷事件 • 適當可使用的支援設備清單 • 主要的備援人員 • 緊急應變系統的測試計畫及結果 • 緊急事件的後續程序 • 緊急事件中，主要聯絡人及資訊資源的散播清單 在很多情況中，風險會被接受或被觀察。若風險被判定太低而不需正式的風險降低計畫，或當似乎沒有降低風險的可行方法，則通常接受該風險。假如接受一個風險，就必須記錄決定的理由。在績效、時間或風險曝光程度(可能性和結果的組合)的門檻能客觀定義、驗證及記錄之後，風險才可觀察。必要時才能啟動風險降低計畫，或緊急應變計畫。 應儘早且充分地考慮技術的展示、模型、模擬及雛型，做為風險降低計畫的一部分。 典型的工作產品 1. 每個已界定風險之處理方案的紀錄 2. 風險降低計畫 3. 緊急應變計畫 4. 負責追蹤及解決每個風險的人員清單 細部執行方法 1. 決定風險的等級及門檻，以定義風險在什麼情況下是變成無法接受，並啟動風險降低計畫或緊急應變計畫。 風險等級(利用風險模式導出)是一種度量，由達成目標的不確定性和無法達成目標的結果所組成。 風險管理(RSKM) 486
CMMI for Development Version 必須清楚瞭解並定義風險程度和門檻，因風險程度和門檻會限定規劃的或可接受的績效範圍，以提供方法來瞭解風險。為了確保適當的排序(根據嚴重性)和相關管理回應，正確的風險分類是必要的。可設定多重門檻，以啟動不同等級的管理回應。通常在設定執行緊急應變計畫門檻之前，會先設定好執行風險降低計畫的門檻。 2. 界定負責處理每個風險的個人或團隊。 3. 決定實施每個風險之風險降低計畫的成本效益比。 應檢驗風險降低活動產生的效益相對於將耗用的資源。就如同其他的設計活動，需要發展替代計畫，並評量每個替代計畫的成本與效益，而後選擇最佳的計畫來實行。有時，風險可能很重大且效益很小，但仍需降低風險，以減少無法接受之結果的發生機率。 4. 發展專案整體的風險降低計畫，以協調個別的風險降低計畫和緊急應變計畫。 完整的風險降低計畫可能無法負擔。所以，應作取捨分析，以對風險降低計畫排定優先順序。 5. 針對選取的關鍵風險，研訂當其發生時的緊急應變計畫。 需要時，在風險變成問題前，研訂和實施風險降低計畫，以主動降低風險。儘管有最佳的努力，有些風險可能無法避免且成為衝擊專案的問題。對關鍵的風險研訂緊急應變計畫，描述專案在衝擊發生時，可能採取的行動。定義處理風險的預先動作計畫的意圖，不是降低風險(風險降低計畫)，就是回應風險(緊急應變計畫)，但無論那一種，都是管理風險。 有些風險管理文獻可能把緊急應變計畫當作風險降低計畫的同義詞或一部分，這些計畫也可能與風險處理計畫或風險行動計畫一起說明。 風險管理(RSKM) 487
CMMI for Development Version SP 執行風險降低計畫 定期監控每一風險的狀況，並適當地執行風險降低計畫。 為了在工作期間有效控制和管理風險，需遵守事先安排的計畫，定期監控風險及其狀況，以及風險處理活動的結果。風險管理策略定義風險狀況應再評量的間隔。這個活動可能導致發現新風險，或可能需要重新規劃或重新評量新風險的處理方案。在任一情況，風險可接受的門檻應與風險狀況比較，以決定是否需要執行風險降低計畫。 典型的工作產品 1. 更新後的風險狀況清單 2. 更新後的風險可能性、結果及門檻的評量 3. 更新後的風險處理方案清單 4. 更新後的風險處理行動清單 5. 風險降低計畫 細部執行方法 1. 監控風險狀況。 風險降低計畫啟動後，仍然要監控風險。評量門檻以檢查是否要執行緊急應變計畫。 應使用定期監控的機制。 2. 提供方法，以追蹤未完成的風險處理行動項目，一直到結案。 有關追蹤行動項目，請參考專案監控流程領域，以獲得更多資訊。 3. 當監控的風險超過定義的門檻時，引用選定的風險處理方案。 風險處理經常只對判斷為「高等」或「中等」的風險。對於已知風險，風險處理策略可能包括避免、降低及控制風險可能性的技術和方法，或控 風險管理(RSKM) 488
CMMI for Development Version 制風險(預期的事件或情況)發生時，遭受損失程度的技術和方法，或上述兩者。因此，風險處理包括風險降低計畫和緊急應變計畫。 發展風險處理的技術，以避免、降低及控制不利專案目標的衝擊，並根據可能的衝擊，提出可接受的結果。處理風險的活動，需要適當的資源並安排於計畫與基準時程表之中。重新規劃的工作需要密切考慮前後相接的或有相依性之工作啟動或活動的影響。 有關修訂專案計畫，請參考專案監控流程領域，以獲得更多資訊。 4. 針對每個風險處理活動，建立時程或某段期間的績效，包括起始日期和預計的完成日期。 5. 對每個計畫提供持續性的資源承諾，以使風險處理活動成功的執行。 6. 蒐集風險處理活動的績效度量。 風險管理(RSKM) 489
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程藉由將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施風險管理流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 僅適用於階段式表述 GG 3 制度化已定義流程 制度化已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行風險管理流程。 詳細說明： 本政策建立組織對風險管理策略的期望，並界定、分析及降低風險。 GP 規劃流程 建立並維護執行風險管理流程的計畫。 風險管理(RSKM) 490
CMMI for Development Version 詳細說明： 專案計畫通常包含(或參考)執行風險管理流程的計畫。專案計畫在專案規劃流程領域中說明。本一般執行方法所需要的計畫，涵蓋此流程領域所有特定執行方法完整的規劃，特別地，提供降低風險的整體處理方法，但對特定工作項目，是與降低風險計畫(包括緊急應變計畫)有所區分的。相反的，執行方法所需要的風險降低計畫，描述更確定的項目，例如：驅動風險處理活動的風險程度。 GP 提供資源 提供充足的資源，以執行風險管理流程、發展工作產品，以及提供流程服務。 詳細說明： 提供的資源，包括下列工具： • 風險管理資料庫 • 風險降低工具 • 雛型製作工具 • 模組化和模擬 GP 指定責任 指派風險管理流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援風險管理流程。 風險管理(RSKM) 491
CMMI for Development Version 詳細說明： 訓練主題，舉例如下： • 風險管理觀念和活動(例如：風險界定、評估、監控、降低) • 風險降低的度量選擇 GP 管理建構 將指定的風險管理流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 風險管理策略 • 已界定的風險項目 • 風險降低計畫 GP 界定並納入相關的關鍵人員 依計畫界定並納入相關風險管理流程相關的關鍵人員。 詳細說明： 關鍵人員參與的活動，舉例如下： • 建立可自由及開放討論風險的合作環境 • 審查風險管理策略和風險降低計畫 • 參與風險界定、分析及降低風險活動 • 溝通及報告風險管理狀況 GP 監控流程 依本流程的執行計畫，監控風險管理流程，並採取適當的矯正措施。 風險管理(RSKM) 492
CMMI for Development Version 詳細說明： 用於監控的度量及工作產品，舉例如下： • 已界定、管理、追蹤及控制的風險數目 • 對每個評量的風險，其風險曝光程度和風險曝光程度的改變，且當作一個管理保留的摘要百分比 • 為風險降低計畫的變更活動(例如：流程、時程、資金) • 非預期風險的發生 • 風險分類的變動性 • 比較降低風險之預估和實際的投入和衝擊 • 風險分析活動的時程 • 特定降低行動的時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估風險管理流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 建立並維護風險管理策略 • 界定並分析風險 • 降低風險 審查的工作產品，舉例如下： • 風險管理策略 • 風險降低計畫 GP 與上層管理人員審查各狀況 與上層管理人員審查風險管理流程的活動、狀況及結果，並解決問題。 風險管理(RSKM) 493
CMMI for Development Version 詳細說明： 以定期和事件導向為基礎，與適當的管理階層審查專案狀況，以便發現潛在的專案風險，並提供適當的矯正措施。 基本上，這些審查包括最嚴重風險和主要風險的參數摘要(例如：風險的可能性和結果)，以及降低風險的投入狀況。 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義風險管理流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行風險管理流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產的未來使用與改善。 詳細說明： 工作產品、度量、度量結果及改善資訊，舉例如下： • 風險參數 • 風險類別 • 風險狀態報告 風險管理(RSKM) 494
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護風險管理流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定風險管理流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保風險管理流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正風險管理流程之缺失與其他問題的根本原因。 風險管理(RSKM) 495
CMMI for Development Version 供應商協議管理 成熟度第二級的專案管理流程領域 目的 供應商協議管理(Supplier Agreement Management, SAM)的目的，在管理供應商產品的取得。 簡介 供應商協議管理流程領域，包含下列各項活動： • 決定待取得產品的取得方式 • 選擇供應商 • 建立並維護供應商協議 • 執行供應商協議 • 監督選商流程 • 評估選商工作產品 • 接受交付的取得產品 • 移交已取得產品給專案 本流程領域主要說明取得將交付給專案客戶的產品和產品組件。在所有流程領域中，當使用產品及產品組件這樣的專有名詞時，也意指包含服務及其組件的意思。 可能由專案取得的產品及產品組件，舉例如下： • 子系統(例：飛機的導航系統) • 軟體 • 硬體 • 文件(例：安裝、操作者與使用者手冊) • 零件及材料(例：儀表、開關、輪子、鋼鐵及原料) 供應商協議管理(SAM) 496
CMMI for Development Version 為減低專案風險，本流程領域也可適用於取得不交付給客戶的產品及產品組件，而是用來發展及維護產品或服務（舉例：發展工具及測試環境）。 典型地，專案取得的產品，決定於產品規劃及發展的早期階段。技術解決流程領域提供執行方法，以決定可從供應商取得的產品及產品組件。 本流程領域不直接適用於供應商整合到專案團隊的約定，以及使用者與產品發展者（例：整合團隊）相同的管理流程和報告。這些情形通常是由其他流程或功能(可能是專案的外部功能)來處理。不過，本流程領域的一些特定執行方法可用於管理這類供應商的正式協議。 依經營的需要，供應商可能有多種型態，包括內部的供應商(亦即是組織內部，專案之外的供應商)、製造與研發的供應商，以及商業化的供應商等。有關「供應商」的定義，請參見詞彙。 建立正式協議以管理組織與供應商的關係。正式協議是指一個組織（代表專案）與供應商間的任何法律協議，它可能是一份合約書、授權／許可、服務水準協議，或者是協議備忘錄。根據本正式協議（意即是供應商協議），供應商交付產品給專案。 相關流程領域 有關監控專案及採取矯正措施，請參考專案監控流程領域，以獲得更多資訊。 有關如何定義需求，請參考需求發展流程領域，以獲得更多資訊。 有關管理需求，包括從供應商取得之產品的需求追溯，請參考需求管理流程領域，以獲得更多資訊。 有關如何決定哪些產品與產品組件可由供應商處取得，請參考技術解決方案流程領域，以獲得更多資訊。 供應商協議管理(SAM) 497
CMMI for Development Version 供應商協議管理(SAM) 498
CMMI for Development Version 特定目標及執行方法摘要 SG 1 建立供應商協議 SP 決定取得方式 SP 選擇供應商 SP 建立供應商協議 SG 2 滿足供應商協議 SP 執行供應商協議 SP 監督選定之供應商流程 SP 評估選定之供應商工作產品 SP 接受取得的產品 SP 移交產品 各目標的特定執行方法 SG 1 建立供應商協議 建立並維護與供應商的協議。 SP 決定取得方式 決定欲取得之每一產品或產品組件的取得方式。 有關如何界定須取得哪些產品和產品組件，請參考技術解決方案流程領域，以獲得更多資訊。 有許多取得方式可供專案使用，以取得產品和產品組件。 供應商協議管理(SAM) 499
CMMI for Development Version 取得方式，舉例如下： • 採購現成品 • 經由合約的協議得到產品 • 由內部供應商處得到產品 • 由客戶處得到產品 • 上述各種方式的組合，例如：經由合約修改現成品或經由外部供應商與企業內其他部門共同發展產品 需要現成品時，須關切產品的評估及選擇，對專案來說，供應商可能也是關鍵。選擇決策的思考要件，包含專利權議題及產品的可供應性。 典型的工作產品 1. 產品和產品組件的取得方式清單 SP 選擇供應商 評估供應商滿足專案指定需求與已建立準則之能力，選擇供應商。 有關選擇供應商的正式評估方法，請參考決策分析與解決方案流程領域，以獲得更多資訊。 有關指定的需求，請參考需求管理流程領域，以獲得更多資訊。 應建立準則，以反映專案成敗的重要因素。 供應商協議管理(SAM) 500
CMMI for Development Version 重要因素，舉例如下： • 供應商的所在地 • 供應商類似工作經驗及執行紀錄 • 工程能力 • 可執行工作的成員和設施 • 相似應用的先前經驗 典型的工作產品 1. 市場研究 2. 備選的供應商名冊 3. 優先選擇的供應商名冊 4. 趨勢研究或評估準則的其他紀錄、備選供應商的優缺點分析，以及選商的理由 5. 邀商文件和需求 細部執行方法 1. 建立並記錄評估潛在供應商的評估準則。 2. 界定潛在的供應商，並分發邀商文件和需求。 執行本活動的事前進行的方法是，做市場研究來界定取得備選產品的潛在來源，備選產品包括供應商的客製化產品及現成品。 有關流程及技術改善的來源，以及如何試行及評估此改善的案例，請參考組織創新及推展流程領域，以獲得更多資訊。 3. 依據評估準則，評估廠商建議書。 4. 評估各備選供應商的相關風險。 有關評估專案風險，請參考風險管理流程領域，以獲得更多資訊。 5. 評估備選供應商執行工作的能力。 供應商協議管理(SAM) 501
CMMI for Development Version 評估備選供應商執行工作之能力的方法，舉例如下： • 評估類似應用的經驗 • 評估類似工作的執行狀況 • 評估供應商的管理能力 • 評估供應商的能力 • 評估可執行工作的成員 • 評估可用設施和資源 • 評估專案與備選供應商共同工作的能力 • 評估在專案計畫及承諾中，備選現成品的衝擊 當評估現成品時，應考慮下列事項： • 現成品的成本 • 將現成品併入專案的成本及工作量 • 安全性需求 • 未來產品發行的利益及衝突 未來現成產品的發行可能提供附加功能，以支援專案已規劃或已期望的加強功能，但也有可能的結果是供應商無法持續支援目前版本。 6. 選擇供應商。 SP 建立供應商協議 建立並維護與供應商間的正式協議。 供應商協議管理(SAM) 502
CMMI for Development Version IPPD補充 當組成整合團隊時，須與供應商協調團隊成員資格，並納入協議內容。協議須界定任何整合性的決策制定、報告的需求(經營面及技術面)，以及需要供應商參與的替代方案研究。採購者必須妥善安排供應商的工作量，以支援IPPD的工作。 正式協議是指一個組織(代表專案)與其供應商間的任何法律協議，因此，它可能是一份合約書、授權/許可、服務水準協議或協議備忘錄。 如果審查、監督、評估、驗收測試活動的執行，對於取得或已取得的產品來說是適當的話，協議內容就應該指定。 典型的工作產品 1. 工作說明書 2. 合約 3. 協議備忘錄 4. 許可協議書 細部執行方法 1. 必要時，修訂供應商須履行的需求(例：產品需求、服務水平需求)，以反映供應商與專案的協商結果。 有關修訂需求，請參考需求發展流程領域，以獲得更多資訊。 有關需求變更的管理，請參考需求管理流程領域，以獲得更多的資訊。 2. 記錄專案將提供給供應商的內容。 包含： • 專案供給的設施 供應商協議管理(SAM) 503
CMMI for Development Version • 文件 • 服務 3. 記錄供應商協議。 供應商協議應包含：工作說明書、規格、協議條款及條件、交付清單、時程表、預算及已定義的驗收流程。 細部執行方法通常包含： • 建立工作說明書、規格、協議條款及條件、交付清單、時程表、預算及驗收流程 • 界定專案與供應商中，被授權負責變更供應商協議的人員 • 界定需求如何變更，與如何決定、溝通及描述供應商協議的變更 • 界定須遵循的標準和程序 • 界定專案和供應商間的關鍵依存關係 • 界定專案監督供應商的形式及深度、程序，以及用以監督供應商績效的評估準則，包括監督流程的選擇及評估工作產品 • 界定供應商審查的方式 • 界定供應商對取得產品之持續維護與支援的責任 • 界定取得產品的保證、所有權及使用權 • 界定驗收準則 在某些選擇現成品的案例中，除了產品授權，還可要求供應商協議。 供應商協議管理(SAM) 504
CMMI for Development Version 與現成品供應商的協議，包含的範圍舉例如下： • 大量採購的折扣 • 在許可協議下，相關關鍵人員的範圍，包括專案供應商、團隊成員，以及專案客戶 • 未來的加強計畫 • 現場支援，例如詢問及問題報告的回應 • 目前不在產品上的附加功能 • 維護支援，包括產品喪失一般可用性的支援 4. 週期性審查供應商協議，以確保正確反映與供應商及目前風險的專案關係，以及市場條件。 5. 在履行協議或任何變更前，確保與協議有關的各方人士都已瞭解並同意所有需求。 6. 必要時，修訂供應商協議，以反映供應商流程或工作產品的變更。 7. 必要時，修訂專案計畫和承諾事項，包括專案流程或工作產品的變更，以反映供應商協議內容。 有關修訂專案計畫，請參考專案監控流程領域，以獲得更多資訊。 SG 2 滿足供應商協議 專案與供應商的協議必須滿足雙方。 SP 執行供應商協議 與供應商共同執行供應商協議所指定的各項活動。 有關監控專案及採取矯正措施，請參考專案監控流程領域，以獲得更多資訊。 典型的工作產品 1. 供應商進度報告和績效度量資料 2. 供應商審查文件和報告 供應商協議管理(SAM) 505
CMMI for Development Version 3. 追蹤行動項目直到結案 4. 產品文件和文件交付的佐證文件 細部執行方法 1. 據供應商協議所定義的事項，監督其進度和工作情況，包括時程、工作量、成本及技術的績效。 2. 供應商協議所指定的事項，進行供應商審查。 有關執行審查，請參考專案監控流程領域，以獲得更多資訊。 審查有正式與非正式審查兩種，包含下列步驟： • 審查準備 • 確保相關的關鍵人員參加 • 執行審查 • 界定、記錄及追蹤所有行動項目直到結案 • 準備審查摘要報告，並分發給相關的關鍵人員 3. 供應商協議所指定的事項，進行供應商技術審查。 技術審查通常包含： • 適當提供清楚的專案客戶和最終使用者之期望和需要給供應商 • 審查供應商的技術活動，並驗證供應商對需求的詮釋和實作是否符合專案的詮釋 • 確保已滿足技術的承諾，且技術的問題均及時溝通和解決 • 取得供應商產品的技術資訊 • 提供適當技術資訊和支援給供應商 4. 供應商協議所指定的事項，與供應商進行管理審查。 管理審查通常包含： • 審查關鍵性的依存關係 供應商協議管理(SAM) 506
CMMI for Development Version • 審查與供應商有關的專案風險 • 審查時程表及預算 技術及管理審查可以一起進行。 5. 由審查結果，改進供應商的績效，以建立和培養可長期合作的優良供應商。 6. 監督與供應商有關的風險，必要時採取矯正措施。 有關監控專案風險，請參考專案監控流程領域，以獲得更多資訊。 SP 監督選定之供應商流程 選擇、監督及分析供應商所使用的流程。 在專案和供應商各自負責一些必須緊密合作之流程情況下，監督這些流程將有助於避免介面的問題。 所選來進行監督的流程必須考慮供應商流程對專案的衝擊。大型專案中，若有發展關鍵組件的重要子合約，監督主要流程是一定要做的。大多數的供應商協議針對尚未發展的產品、或者對較小及不關鍵組件的產品時，可能決定不選擇監督流程。這兩個極端中，應考慮到選擇被監督的流程之整體風險。 如未謹慎的執行監督，可能會出現二種極端狀況，一種是具侵略性且繁重，另一種是沒有助益且無效。所以，應有充分的監督，以儘早發現可能會影響供應商履約能力的議題。 監督執行時若沒有足夠的關心，極端表現是侵略性及煩人的，另一種極端表現是無法獲得資訊及無效率的。盡可能早一點有足夠監督能力，來發覺議題，這會影響供應商的能力，是否滿足供應商協議的需求。 對所選擇流程之分析活動，包括取得所監督之供應商流程的資料，並進行分析，以決定是否存在嚴重的議題。 供應商協議管理(SAM) 507
CMMI for Development Version 典型的工作產品 1. 已選定要被監督的流程或不選擇的理由清單 2. 活動報告 3. 績效報告 4. 績效曲線 5. 差異報告 細部執行方法 1. 界定對專案的成功具關鍵性的供應商流程 2. 監督已選擇的供應商流程，以符合協議的需求 3. 分析已選定之供應商流程的監督結果，以儘早發現可能會影響供應商履約能力的議題。 趨勢分析可使用內部和外部資料。 有關記錄驗證與分析的結果，請參考驗證流程領域，以獲得更多資訊。 有關採取矯正措施，請參考專案監控流程領域，以獲得更多資訊。 SP 評估所選定之供應商工作產品 針對客製化產品的供應商，選擇及評估工作產品。 本執行方法的使用範圍，限定於提供客製化產品專案的供應商，特別是因其複雜度或關鍵性，導致程式上的風險。本特定執行方法的目的，在於評估供應商所生產的工作產品，以儘早發現會影響供應商履約能力的議題。經選定用以進行評估的工作產品，應包括可儘早洞察品質議題的關鍵性產品、產品組件及工作產品。 典型的工作產品 1. 選定用以監督的工作產品清單或不選定理由清單 2. 活動報告 供應商協議管理(SAM) 508
CMMI for Development Version 3. 差異報告 細部執行方法 1. 界定對專案的成功具關鍵性的工作產品，以儘早發現議題。 對專案成功具關鍵性的工作產品，舉例如下： • 需求 • 分析 • 架構 • 文件 2. 評估已選擇工作產品 評估工作產品，確保以下事項： • 衍生需求是可追溯至較更高階的需求 • 架構是可行性的，並滿足產品未來的成長及再使用的需要 • 產品的操作和支援文件是足夠的 • 工作產品之間是一致的 • 產品及產品組件（例，客製的、現成的及客戶提供的產品）可以被整合 3. 針對評估所界定的缺點，決定行動方案，並記錄之。 有關採取矯正措施，請參考專案監控流程領域，以獲得更多資訊。 SP 接受取得的產品 在接受取得的產品前，確保其已滿足供應商協議。 依供應商協議所指定的事項，在接受產品之前，須完成驗收審查和測試，以及完成建構稽核。 供應商協議管理(SAM) 509
CMMI for Development Version 典型的工作產品 1. 驗收測試程序 2. 驗收測試報告 3. 差異報告或矯正計畫 細部執行方法 1. 定義驗收程序。 2. 驗收審查或測試前，先與相關的關鍵人員審查驗收程序，並取得他們的同意。 3. 驗證所取得的產品，滿足其需求。 有關驗證產品，請參考驗證流程領域，以獲得更多資訊。 4. 確認所取得的產品，滿足其非技術性的承諾。 可能包含確認適當的授權/許可、保證書、所有權、使用權，以及支援或維護協議，均已妥當安排，且所有支援物資均已收到。 5. 記錄驗收審查或測試的結果。 6. 未通過驗收審查或測試的工作產品，建立行動方案，並取得供應商的同意。 7. 界定、記錄及追蹤所有行動項目直到結案。 有關追蹤行動項目，請參考專案監控流程領域，以獲得更多資訊。 SP 移交產品 移交從供應商取得的產品予專案。 在取得的產品移交到專案以供整合之前，須執行適當的規劃和評估，以確保能順利移交。 有關整合取得的產品，請參考產品整合流程領域，以獲得更多資訊。 供應商協議管理(SAM) 510
CMMI for Development Version 典型的工作產品 1. 移交計畫 2. 訓練報告 3. 支援和維護計畫 細部執行方法 1. 保有適當設施以接收、儲存、使用及維護所取得的產品。 2. 確保與接收、儲存、使用及維護所取得產品有關的人員皆獲得適當訓練。 3. 確保在執行所取得產品的儲存、配送及使用時，皆依據供應商協議或授權/許可所指定之條款及限制的規定。 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將藉由界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施供應商協議管理流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 GP 建立組織政策 建立並維謢組織政策，以規劃和執行供應商協議管理流程。 供應商協議管理(SAM) 511
CMMI for Development Version 詳細說明： 本政策建立組織對下列活動的期望：建立、維護及滿足供應商協議。 GP 規劃流程 建立並維謢執行供應商協議管理流程的計畫。 詳細說明： 本計畫有關執行供應商協議管理流程，可以是一部分(或參照)專案計畫，而專案計畫在專案規劃流程領域中說明。本計畫的某些部分是由專案以外的獨立團隊執行，如合約管理。 GP 提供資源 提供充足的資源，以執行供應商協議管理流程、發展工作產品及提供流程服務。 詳細說明： 可用於本流程領域的資源(工具)，舉例如下： • 優先的供應商清單 • 需求追蹤工具 • 專案管理及時程工具指派責任 GP 指派責任 指派供應商協議管理流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援供應商協議管理流程。 供應商協議管理(SAM) 512
CMMI for Development Version 詳細說明： 訓練主題，舉例如下： • 與供應商協商及共同工作有關的規定及經營實務 • 取得的規劃及準備 • 現成品的取得 • 供應商的評選 • 協調及衝突解決 • 供應商管理 • 取得產品的測試及移交 • 取得產品的接收、儲存、使用及維護 GP 管理建構 將指定的供應商協議管理流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 工作說明書 • 供應商協議 • 協議備忘錄 • 子合約 • 優先選擇的供應商名冊 GP 界定並納入相關的關鍵人員 依計畫界定並納入供應商協議管理流程相關的關鍵人員。 供應商協議管理(SAM) 513
CMMI for Development Version 詳細說明： 關鍵人員參與的活動，舉例如下： • 建立評估潛在供應商的評估準則 • 審查潛在的供應商 • 建立供應商協議 • 與供應商解決爭論的議題 • 審查供應商的工作績效 GP 監控流程 依本流程的執行計畫，監控供應商協議管理流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量，舉例如下： • 供應商需求的變更次數 • 供應商協議在成本和時程的差異 • 供應商工作產品評估已完成（規劃的相對於實際完成的）數量 • 供應商流程評估已完成（規劃的相對於實際完成的）數量 • 選擇供應商及建立協議的時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估供應商協議管理流程的遵循程度，並解決不符合的情況。 供應商協議管理(SAM) 514
CMMI for Development Version 詳細說明： 審查的活動，舉例如下： • 建立並維護供應商協議 • 滿足供應商協議 審查的工作產品，舉例如下： • 供應商協議管理計畫 • 供應商協議 GP 與上層管理人員審查各狀況 與上層管理人員審查供應商協議管理流程的活動、狀況及結果，並解決問題。 僅適用於階段式表述 GG 3的目標及其執行方法，不是成熟度第二級評等的必要項目，但它們是成熟度第三級和更高等級評等的必要組件。 供應商協議管理(SAM) 515
CMMI for Development Version 僅適用於連續式表述式之成熟度第3-5級 GG 3 制度化已定義流程 將流程制度化為已定義流程。 GP 建立已定義流程 建立並維護已定義供應商協議管理流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行供應商協議管理流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產未來的使用與改善。 詳細說明： 工作產品、度量、度量結果與改善資訊，舉例如下： • 供應商審查的結果 • 用於選商的交易研究 • 供應商協議的改版歷史紀錄 • 供應商績效報告 • 供應商工作產品及流程評估的結果 供應商協議管理(SAM) 516
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護供應商協議管理流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定供應商協議管理流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保供應商協議管理流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正供應商協議管理流程之缺失與其他問題的根本原因。 供應商協議管理(SAM) 517
CMMI for Development Version 技術解決方案 成熟度第三級的工程類流程領域 目的 技術解決方案(Technical Solution, TS)的目的，為設計、發展及實作需求的解決方案。解決方案、設計結果及實作成品包括產品、產品組件，以及與產品相關生命週期的單一流程或適當組合的流程。 簡介 技術解決方案流程領域適用於產品架構的任何層級，且適用於所有產品、產品組件、產品相關生命週期流程。整個流程領域中，產品及產品組件的意涵也包括服務及其組件。 本流程領域專注於下列事項： • 評估與選擇解決方案(有時稱為「設計方案)、「設計概念」或「初步設計」」，滿足適當的配置需求。 • 對選定的解決方案發展細部設計(詳細到包括製造、程式製作，或實作設計為產品或產品組件所需的資訊)。 • 實作設計成產品或產品組件。 基本上，這些活動相互支援。某種程度的設計，有時相當詳細，可能需要選擇解決方案。雛型或試行可用來作為取得足夠知識，以發展技術相關資料或一組完整需求的方法。 技術解決方案的特定執行方法，不僅適用於產品及產品組件，也適用於產品相關生命週期的流程。產品相關生命週期流程的發展，與產品或產品組件的發展有關。這種發展包括選擇與調適現有流程(包含標準流程)以供使用與發展新流程。 技術解決方案(TS) 518
CMMI for Development Version 技術解決方案流程領域相關的流程，接受來自需求管理流程的產品與產品組件需求。需求管理源自於需求發展流程的需求，將需求納入適當的建構管理，並維護他們對先前需求的追溯性。 就維護或維運的專案而言，需要維護活動或重新設計的需求可能由使用者的需要或產品組件潛伏的瑕疵所驅動。新需求可能來自於操作環境的變更，這些需求在產品驗證的時候，透過比較實際績效與指定績效而界定出不被接受的績效落差，可以被發掘出來。技術解決方案流程領域相關的流程應用以執行維護或維運的設計工作。 相關流程領域 有關需求配置、操作觀念的建立及介面需求定義，請參考需求發展流程領域，以獲得更多資訊。 有關同仁審查及對產品和產品組件是否滿足需求之驗證，請參考驗證流程領域，以獲得更多資訊。 有關正式評估，請參考決策分析與解決方案流程領域，以獲得更多資訊。 有關管理需求，請參考需求管理流程領域，以獲得更多資訊。需求管理流程領域之特定執行方法執行時，與技術解決方案流程領域的特定執行方法交互作用。 有關改善組織的技術，請參考組織創新與推展流程領域，以獲得更多資訊。 技術解決方案(TS) 519
CMMI for Development Version 特定目標及執行方法摘要 SG 1選擇產品組件解決方案 SP 發展備選解決方案及評選準則 SP 選擇產品組件解決方案 SG 2發展設計 SP 設計產品或產品組件 SP 建立技術相關資料 SP 使用準則設計介面 SP 執行自製、購買或再用之分析 SG 3實作產品設計 SP 實作設計 SP 建立產品支援文件 各目標的特定執行方法 SG 1 選擇產品組件解決方案 從備選方案中，選擇產品或產品組件解決方案。 選擇解決方案之前，應考量備選解決方案及其相關優點。建立在分析備選解決方案時所使用的關鍵需求、設計問題及限制條件。架構特性提供產品改善與演進的考量基礎，並按相對成本、時程、績效及風險，考慮是否採用現成品做為產品組件。現成品(COTS)可直接或修改後使用，有時候這種現成品須進行介面修改或對部分特性進行客製化，以符合產品需求。 良好設計流程的指標之一，是在比較與評估各種備選解決方案後，才進行設計方案的選擇。通常在設計選擇時要處理架構、客製或採用現成品及產品組件模組化的決定。有些決策需要使用正式的評估流程。 有關正式評估流程的使用，請參考決策分析與解決方案流程領域，以獲得更多資訊。 技術解決方案(TS) 520
CMMI for Development Version 有時尋找解決方案，只需檢查相同需求的備選實例，而不必涉及其下層產品組件的需求配置。在產品架構的底層(組件)即為一例。有些情況，有些方案已預先決定(例如：某特定方案已被直接指定，或是調查可供使用的產品組件，如現成品)。 一般而言，解決方案是整套的。亦即，在定義產品組件的下一層時，一起建立每個組件的解決方案。備選方案不單是對同一需求的不同處理方式，也反映需求配置於組件，構成解決方案的不同思考。此處的目標是將整體的解決方案最佳化，而非個別設計的優劣。因此，與需求發展流程領域有密切互動，以支援產品需求暫時性的配置到各產品組件，直至選定解決方案並建立「最終」配置。 產品組件解決方案是由備選解決方案所選出，而產品相關的生命週期流程就在這些產品組件解決方案之中。例如：製造、交付與支援流程就是產品相關的生命週期流程。 SP 發展備選解決方案及評選準則 發展備選解決方案及評選準則。 有關取得將需求配置到產品組件的備選解決方案，請參考需求發展流程領域中，配置產品組件需求指定執行方法，以獲得更多資訊。 有關建立用於決策的準則，請參考決策分析與解決方案流程領域，以獲得更多資訊。 IPPD補充 選擇備選解決方案的活動以及決策分析與替代方案研究的議題，都需要相關關鍵人員的參與。這些關鍵人員代表經營與技術功能，以及同步發展的產品與產品相關的生命週期流程 (例如：製造、支援、訓練、驗證及銷毀)。以此方式，重要的議題在產品發展的早期就會浮現出來，並在這些議題變成高成本的錯誤之前就予以處理。 技術解決方案(TS) 521
CMMI for Development Version 需要界定及分析備選解決方案，以便就成本、時程及績效，選擇最均衡的解決方案。這些解決方案，是以已建議的產品架構為基礎，來說明關鍵產品品質，以及擴展可行解決方案的設計空間。「發展與設計」特定目標的特定執行方法，提供更多關於發展可能的產品架構，使其能結合產品備選解決方案的資訊。 備選解決方案通常包含將備選需求配置到不同的產品組件。這些備選解決方案在產品架構中，也包括現成品解決方案的使用。與需求發展流程領域相關的流程，也可用於提供更完整及健全的臨時性需求配置到備選解決方案。 備選解決方案涵蓋可接受的成本、時程及績效的範圍。產品組件需求與設計問題、限制及準則一起用於發展備選解決方案。評選準則通常必須強調成本(例如：時間、人員、費用)、效益(例如：績效、性能、有效性)及風險 (例如：技術、成本及時程)。詳細的備選解決方案及評選準則的考量因素可包括下列： • 成本(發展、製造、購買、維護及支援) • 績效 • 產品組件及產品相關生命週期流程的複雜度 • 對產品操作與使用條件、操作模式、環境及產品相關生命週期流程變異的堅固程度 • 產品擴充性與成長性 • 技術界限 • 建造方法及材料的敏感度 • 風險 • 需求與技術的演進 • 廢棄 • 最終使用者與操作者的能力與界限 • 現成品的特性 技術解決方案(TS) 522
CMMI for Development Version 這裡所列為最基本的考量因素。組織應發展與經營目標一致的備選方案篩選準則，以縮小備選清單。產品生命週期的成本期望能越小越好，但常非發展組織所能控制。客戶可能不願支付短期內較高成本，來換取最終會隨著產品生命週期而降低成本的功能。在此情況下，至少應提醒客戶，任何會降低生命週期成本的潛在機會。用來選擇最終解決方案的準則須提供成本、效益及風險之間的平衡方法。 典型的工作產品 1. 備選解決方案篩選準則 2. 新技術的評估報告 3. 備選解決方案 4. 最終選擇的評選準則 5. 現成品的評估報告 細部執行方法 1. 界定篩選準則，以作為選擇備選解決方案的考量因素 2. 界定現有技術與具競爭優勢的新產品技術 有關改善組織技術，請參考組織創新與推展流程領域，以獲得更多資訊。 專案應界定應用於現有產品及流程的技術，並在整個專案生命週期，監督目前使用技術的進展。專案應界定、選擇、評估及投資新技術，以獲得競爭優勢。備選解決方案可包括新發展的技術，但亦可包括不同應用的成熟技術或維持現有方法。 3. 界定能滿足需求的備選現成品 有關評估供應商，請參考供應商管理流程領域，以獲得更多資訊。 這些需求包括下列： 技術解決方案(TS) 523
CMMI for Development Version • 功能性、績效、品質及可靠性 • 產品保證書的條款 • 風險 • 供應商對後續的產品維護及支援的責任 4. 產生備選方案 5. 取得每一備選解決方案的完整需求配置。 6. 發展選擇最佳備選解決方案的準則。 準則應包括產品生命週期設計問題的處理，例如：易於加入新技術或利用商用產品的能力等。例如：與開放式設計或開放架構概念有關的準則，都應列入評估。 SP 選擇產品組件解決方案 選擇最能滿足所建立準則之產品組件解決方案。 有關建立產品組件的配置需求及產品組件間之介面需求，請參考需求發展流程領域之「配置產品組件需求」及「界定介面需求」等特定執行方法，以獲得更多資訊。 選擇最能滿足準則的產品組件，即建立需求配置給產品組件。低階需求的產生來自於備選方案的選擇，並用來發展產品組件的設計。主要以功能性的觀點描述產品組件間的介面需求。文件中也包含產品對外活動及項目的實體介面描述。 記錄方案的描述及選擇理由。在發展過程中，漸進發展技術相關資料為技術解決方案及發展詳細設計，並實作設計。維護選擇理由的紀錄對後續的決策十分重要。這種紀錄可使後續的關鍵人員免於重做，也可在某些適用的應用環境下，提供對技術應用的深入見解。 典型的工作產品 1. 產品組件選擇決策及理由 2. 需求及產品組件間相關性的紀錄 技術解決方案(TS) 524
CMMI for Development Version 3. 解決方案、評估及理由的紀錄 細部執行方法 1. 依據操作概念、操作方式及操作狀態所建立的評選準則，評估各備選解決方案/解決方案組。 針對每一個備選解決方案，發展產品操作及使用者互動的時序劇本。 2. 依據備選解決方案的評估，評量評選準則之適用性，必要時，更新準則。 3. 界定並解決與備選技術方案及需求有關的議題。 4. 選擇能滿足已建立之評選準則的最佳解決方案。 5. 建立與所選擇之備選方案關聯的需求，此即為該產品組件的配置需求。 6. 界定將再用或取得的產品組件解決方案。 有關取得產品及產品組件，請參考供應商協議管理流程領域，以獲得更多資訊。 7. 建立並維護解決方案、評估及理由的文件。 SG 2 發展設計 發展產品或產品組件的設計。 產品或產品組件的設計，必須提出適當的內容，這不僅是為了實作，也是為了產品生命週期階段，如修正、重新採購、維護、維持及安裝。設計文件提供相關的關鍵人員，對於設計的相互瞭解之參考，並在產品的發展與後續的生命週期階段，支持未來設計上的改變。完整的設計描述，記錄於技術相關資料中，該相關資料含有格式、安裝、功能、介面、製造流程特性及其他參數等完整的特徵與參數。已建立的組織或專案的設計標準(例如：檢查清單、樣板、物件架構)，形成達成高度定義與完整性之設計文件的基礎。 技術解決方案(TS) 525
CMMI for Development Version IPPD 補充 整合團隊在設計產品的同時，也設計適當的產品相關的生命週期流程。適當時，這些流程可挑選自組織標準流程且不經修改。 SP 設計產品或產品組件 發展產品或產品組件的設計。 產品設計包含兩階段，在執行上可能相互重疊：初步設計與細部設計。初步設計建立產品功能與架構，包含產品組成區塊、產品組件界定、系統狀態與模式、主要的內部介面，以及外部產品介面。細部設計完整的定義產品組件的結構與功能。 有關發展架構需求，請參考需求發展流程領域，以獲得更多資訊。 架構定義由需求發展流程的發展架構需求而來。這些需求代表產品成功的關鍵品質與效能。當建立細部產品設計時，架構定義結構化元素與協調的機制，使其直接滿足需求或支援需求的達成。架構包含標準與設計規則，用來管理產品組件的發展與介面，就像能幫助產品發展者的指引一樣。「選擇產品組件解決方案」特定目標的特定執行方法中，包含更多關於使用產品架構作為備選解決方案基礎的資訊。 架構師設定並發展產品的模式，對產品組件所包含的軟硬體做需求配置的判斷。多個支援備選解決方案的架構，經發展與分析以找出針對架構需求的優缺點。 操作概念與劇本用來產生作為調修架構的使用案例與品質劇本。它們也用來評估架構的合適性，以滿足架構評估期間的期望目標，並在產品設計過程中定期地執行。 技術解決方案(TS) 526
CMMI for Development Version 有關發展用來作為架構評估的操作概念與劇本，請參考需求發展流程領域之「建立操作概念及劇本」特定執行方法，以獲得更多資訊。 定義架構的工作項目，舉例如下： • 建立功能區塊的結構化關聯，與功能區塊內的元件以及功能區塊間的介面規則 • 建立軟體主要的內部介面與外部介面 • 界定產品組件及其之間的介面 • 定義協調機制(例：針對軟體及硬體) • 建立基礎建設的能力與服務 • 發展產品組件樣板或類別與框架 • 建立設計規則與授權，以制定決策 • 定義流程/執行緒的模式 • 定義軟體到硬體的實際部署 • 界定主要再用的方法與資源 在細部設計期間，完成產品架構的細節、完整定義產品組件，以及完整描述介面。產品組件的設計可能針對某些品質或效能特性而進行最佳化。設計者可評估既有產品或現成品，以作為產品組件。當設計成熟時，追蹤需求(該需求已指定給較低階的產品組件)，以確保這些需求已滿足。 有關追蹤產品組件需求，請參考需求管理流程領域，以獲得更多資訊。 軟體工程適用 細部設計專注於軟體產品組件的發展。定義產品組件的內部結構、產生資料綱要、發展演算法及建立啟發法，使得產品組件功能滿足所配置的需求。 技術解決方案(TS) 527
CMMI for Development Version 硬體工程適用 細部設計專注於電子、機械、光電，及其他硬體產品及其組件的產品發展。發展電子概圖及電路圖、產生機械及光學封裝模式，並發展製造及封裝流程。 典型的工作產品 1. 產品架構 2. 產品組件設計 細部執行方法 1. 建立並維護準則，以評估設計。 除預期的效能外，用以建立設計準則的屬性，舉例如下： • 模組化 • 清晰 • 簡單 • 可維護 • 可驗證 • 可攜性 • 可靠性 • 準確性 • 安全 • 可擴充 • 可使用 2. 界定、發展或取得適合於產品的設計方法。 有效的設計方法能具體表現大範圍的活動、工具及描述的技術。方法是否有效，視情況而定。兩家公司在他們所專長的產品上，或許都有非常有 技術解決方案(TS) 528
CMMI for Development Version 效的設計方法，但是這些方法在合作上也許就不那麼有效。複雜度高的方法，對未經訓練的設計者而言，就未必是有效的方法。 方法是否有效，也要看它能提供設計者多少的協助，以及其成本效益。例如：一個需要多年時間的雛型設計，可能不適用於簡單的產品組件，但在發展無前例可循、昂貴及複雜的產品時，卻可能會是最佳選擇。使用工具的方法是非常有效的，因工具可確保設計將包括所有必要實作產品組件設計的屬性。例如：設計工具「知道」製造流程的能力，在設計的容忍誤差中說明製造流程的差異。 增進有效設計的技術與方法，舉例如下： • 雛型法 • 結構化模式 • 物件導向設計 • 精實系統分析 • 實體關聯模式(E-R models) • 設計再用 • 設計樣式 3. 確保設計遵循所應用的設計標準與準則。 技術解決方案(TS) 529
CMMI for Development Version 設計標準的範例，舉例如下(部分或全部的「標準」可能是設計準則，特別是標準尚未建立時)： • 操作人員介面標準 • 測試腳本 • 安全標準 • 設計限制(例：電磁相容性、訊號完整性及環境面) • 生產限制 • 設計的容忍範圍 • 零件標準(如生產的廢棄物與廢品) 4. 確保設計遵循已配置的需求。 必須考慮已界定的現成品組件。例如：將現有產品組件放入產品架構可能會修改需求與需求的配置。 5. 記錄設計。 SP 建立技術相關資料 建立並維護技術相關資料。 技術相關資料提供發展者在發展產品或產品組件時，周詳的描述。該資料在各種情況下，也提供採購的彈性。例如以績效為主的合約或依設計圖建造。 設計結果記錄於技術相關資料中。在初步設計期間產生技術相關資料，以記錄架構定義。在整個產品生命週期中必須維護技術相關資料，以記錄必要的產品設計細節。技術相關資料提供產品或產品組件的說明(包含未視為個別產品組件之產品相關生命週期流程)，以支援產品取得策略，或產品生命週期的實作、生產、工程及後勤支援階段。這些說明包含必要的設計建構定義與程序，以確保產品或產品組件應有的效能。它包含所有可用的技術資料，例 技術解決方案(TS) 530
CMMI for Development Version 如：繪圖、相關清單、規格、設計描述、設計資料庫、標準、效能需求、提供的品質保證及組裝細節。技術相關資料包含用來實作之已選定的備選解決方案。 若該資訊適合產品或產品組件的型態(例如：原料與製造需求，對軟體服務或流程相關的產品組件可能沒有幫助)，技術相關資料應包含下列資訊： • 產品架構描述 • 已配置的需求 • 產品組件描述 • 產品相關生命週期流程描述，如未描述於個別產品組件 • 關鍵產品特性 • 必要的實體特性與限制 • 介面需求 • 原料需求(原料清單與原料特性) • 建造及製造需求(針對原先的設備製造商與現場支援) • 用來確保達成需求的驗證準則 • 整個產品生命週期中的使用條件(環境)和操作/使用劇本、操作的方式與狀態、支援、訓練、製造、廢棄及驗證 • 決定的理由與特性(需求、需求配置及設計選擇) 由於設計說明包含大量資料，且這些資料對產品組件成功的發展可能是關鍵，因此建議要建立組織資料與選擇資料內容的準則。使用產品架構來組織資料與抽象化觀點，使得感興趣的議題或特性能以清晰與切題的方式呈現，是一個特別有用的方法。這些觀點包含： • 客戶 • 需求 • 環境 • 功能 技術解決方案(TS) 531
CMMI for Development Version • 邏輯 • 安全性 • 資料 • 狀態/模式 • 結構 • 管理 這些觀點都記錄在技術相關資料中。 典型的工作產品 1. 技術相關資料 細部執行方法 1. 決定設計階層數目及每一設計階層文件的適當階層。 決定需要以文件記錄與執行需求追溯之產品組件階層的數目(例如：子系統、硬體建構項目、電路板、電腦軟體建構項目、電腦軟體產品組件、電腦軟體單元)，對管理文件成本與支援整合及驗證計畫都非常重要。 2. 已配置的產品組件需求、架構及較高階的設計為基礎，執行細部設計。 3. 記錄設計資料於技術相關資料中。 4. 記錄關鍵 (例如：對成本、時程或技術績效有重要影響)決策或定義的理由。 5. 必要時修改技術相關資料。 SP 使用準則設計介面 使用已建立的準則來設計產品組件介面。 介面設計包含下列： • 起源 • 終點 • 軟體的影響事件與資料特性 • 硬體的電子、機械與功能特性 技術解決方案(TS) 532
CMMI for Development Version • 溝通的服務管道 介面準則經常反映出周詳的重要參數清單。必須定義這些參數，或最起碼要進行調查，以確保其適用性。這些參數通常是某特定產品的特性(如軟體、機械的、電子的、服務)，並常與安全、保密、耐久性及任務的關鍵特性有關。 有關界定產品及產品組件介面需求，請參考需求發展流程領域中，界定介面需求的特定執行方法，以獲得更多資訊。 典型的工作產品 1. 介面設計規格 2. 介面控制文件 3. 介面規格準則 4. 所選之介面設計的理由 細部執行方法 1. 定義介面準則。 這些準則可以是組織流程資產的一部分。 有關建立並維護組織流程資產，請參考組織流程定義流程領域，以獲得更多資訊。 2. 界定與其他產品組件相關的介面。 3. 界定與外部項目相關的介面。 4. 界定介於產品組件與產品相關生命週期流程的介面。 舉例來說，這介面可包括所製造的產品組件與製造流程中用於組裝的配件間的介面。 5. 應用準則於介面設計的備選方案。 有關界定準則與依據準則來選擇備選方案，請參考決策分析與解決方案流程領域，以獲得更多資訊。 技術解決方案(TS) 533
CMMI for Development Version 6. 記錄已選取的介面設計與理由。 SP 執行自製、購買或再用之分析 根據已建立的準則，評估產品組件是要發展、購買或再用。 決定要取得哪些產品或產品組件，通常稱為「自製或採購分析」，通常是以專案需求的分析為基礎。自製或採購分析從專案早期的設計開始，在設計流程階段持續進行，完成時，決定產品要自行發展、由外部取得或再用。 有關決定產品或產品組件的需求，請參考需求發展流程領域，以獲得更多資訊。 有關管理需求，請參考需求管理流程領域，以獲得更多資訊。 影響自製或購買決策的因素包含如下： • 產品所提供的功能以及這些功能如何符合專案的需要 • 可用的專案資源與技術 • 內部自行發展與外購的成本比較 • 關鍵的交付日期與整合日期 • 策略聯盟，包含高階的經營需求 • 可用產品的市場分析，包含現成品 • 可用產品的功能與品質 • 潛在供應商的技能與能力 • 對核心競爭力的影響 • 有關外購產品的授權、保證書、權責及界限 • 產品可用性 • 所有權議題 • 風險降低 可使用正式評估方法以進行自製或購買的決策。 技術解決方案(TS) 534
CMMI for Development Version 有關定義準則及備選方案，以及執行正式評估，請參考決策分析與解決方案流程領域，以獲得更多資訊。 一如技術的漸進發展，選擇發展或採購產品組件的理由也是一樣。雖然複雜的發展工作量會使大家傾向於購買現成品，但生產力與工具的進步，卻又會使大家抱持相反的看法。現成品的文件可能不夠完整或正確，而且在將來未必會提供支援。 一旦決定購買現成的產品組件，其需求就用以建立供應商協議。有時，所謂「現成品」在目前的市場也可能缺貨。例如：某種型號的飛機或引擎等，它們並非真正的現成品，但隨時可以製造。在某些情況，這類非發展項目的使用，是因為績效上的特殊理由，還有其他產品特性上的限制。在這種情況下，需求與驗收準則就必須包含在供應商協議中，並加以管理。在其它的狀況下，現成品就如它們字面上的意思一樣(如文字處理軟體)，供應商並沒有需要被管理的協議。 有關如何說明產品組件的取得，以便執行採購，請參考供應商協議管理流程領域，以獲得更多資訊。 典型的工作產品 1. 設計與產品組件再用的準則 2. 自製或採購分析 3. 選擇現成品組件的指引 細部執行方法 1. 發展產品組件設計再用的準則。 2. 分析設計以決定產品組件要自行發展、再用或採購。 3. 當採購或選擇非發展的項目(現成品、政府的成品及再用)時，分析維護所隱藏的代價。 技術解決方案(TS) 535
CMMI for Development Version 維護的涵意，舉例如下： • 與未來現成品的發行有相容性 • 供應商變更的建構管理 • 非發展性項目的缺失與其解決方案 • 非計畫性的廢置 SG 3 實作產品設計 依照設計，實作產品組件及相關的支援文件。 從「發展設計」特定目標的特定執行方法所建立的設計，實作產品組件。實作工作通常包括產品整合及终端使用者文件製作前，所需的產品組件單元測試。 SP 實作設計 實作產品組件設計。 一旦完成產品設計，接著就是將之實作為產品組件。實作的特性與產品組件的種類有關。 產品階層最高階設計的實作，包含下一階每個產品組件的規格。此活動包含配置、調修及驗證每一產品組件。同時也涉及多樣的產品組件發展工作間的協調。 有關需求的配置與調修，請參考需求管理流程領域，以獲得更多資訊。 有關介面管理與產品及產品組件的整合，請參考產品整合流程領域，以獲得更多資訊。 技術解決方案(TS) 536
CMMI for Development Version 實作的特性，舉例如下： • 已撰寫程式碼。 • 資料已文件化。 • 服務已文件化。 • 電子及機械零件已製造。 • 產品獨特的製造流程已放入實際作業中。 • 流程已文件化。 • 設施已建造。 • 原料已生產(例如：一項產品特有的原料可能是一種石油、燃料油、潤滑油，或是一種新的合金)。 典型的工作產品 1. 已實作的設計 細部執行方法 1. 使用有效的方法實作產品組件。 軟體工程適用 軟體程式製作的方法，舉例如下： • 結構化程式設計 • 物件導向程式設計 • 自動化產生程式碼 • 軟體程式碼再用 • 使用合適的設計模式 技術解決方案(TS) 537
CMMI for Development Version 硬體工程適用 硬體製造方法，舉例如下： • 閘門層級組合 • 電路版設計（位置及路線） • 電腦輔助設計圖 • 事後設計模擬 • 製造方法 2. 遵循適當的標準與準則。 實作製作的標準，舉例如下： • 程式語言標準(例：軟體程式語言標準及硬體描述語言) • 繪圖需求 • 標準零件清單 • 製造零件 • 軟體組件的結構及階層 • 流程及品質標準 製作的準則，舉例如下： • 模組化 • 明確 • 簡單 • 可靠性 • 安全性 • 可維護性 3. 對選定的產品組件，執行同仁審查。 技術解決方案(TS) 538
CMMI for Development Version 有關執行同仁審查，請參考驗證流程領域，以獲得更多資訊。 4. 適當時對產品組件執行單元測試。 請注意，單元測試不限於軟體。單元測試涵蓋個別硬體或軟體單元或先前已整合的相關項目群組。 有關驗證方法與程序，以及關於驗證工作產品是否依據所指定的要求，請參考驗證流程領域，以獲得更多資訊。 軟體工程適用 單元測試的方法，舉例如下： • 敘述涵蓋度測試 • 分支涵蓋度測試 • 述詞涵蓋度測試 • 路徑涵蓋度測試 • 邊界值測試 • 特殊值測試 硬體工程適用 單元測試的方法，舉例如下： • 功能性測試 • 輻射檢查測試 • 環境測試 5. 必要時修訂產品組件。 在實作階段發生了未能於設計階段預見的問題時，就是修訂產品組件時機的範例之一。 技術解決方案(TS) 539
CMMI for Development Version SP 建立產品支援文件 建立並維護產品使用文件。 本特定執行方法發展並維護用於產品安裝、操作及維護的相關文件。 典型的工作產品 1. 终端使用者訓練教材 2. 使用者手冊 3. 操作手冊 4. 維護手冊 5. 線上求助 細部執行方法 1. 審查需求、設計、產品及測試結果，以確保影響安裝、操作及維護等項文件的相關議題已被界定並解決。 2. 運用有效的方法，製作安裝、操作及維護的文件。 3. 遵循適當的文件製作標準。 文件製作的標準，舉例如下： • 與指定的文書處理軟體相容 • 可接受的字型 • 章節及分頁的編碼 • 與指定的文體手冊一致 • 縮寫的使用 • 安全分級的標示 • 國際化的需求 4. 在生命週期的初期階段就製作安裝、操作及維護等文件的初始版本，以供相關的關鍵人員審查。 技術解決方案(TS) 540
CMMI for Development Version 5. 執行安裝、操作及維護等文件的同仁審查。 有關執行同仁審查，請參考驗證流程領域，以取得更多資訊。 6. 必要時修訂安裝、操作及維護文件。 需要修訂文件的時機，舉例如下： • 需求變更 • 設計變更 • 產品變更 • 已界定的文件錯誤 • 界定出來預見的修改 技術解決方案(TS) 541
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程將界定之輸入的工作產品轉換為輸出的工作產品，並支援與促成流程領域特定目標的達成。 GP 實施基礎執行方法 實施技術解決方案流程的基礎執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理流程。 僅適用於階段式表述 GG 3 制度化已調適流程 將流程制度化為已調適流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行技術解決方案流程。 詳細說明： 本政策建立組織的期望，以反覆處理下列工作：選擇產品組件解決方案、發展產品及產品組件之設計與實作產品組件設計。 GP 規劃流程 建立並維護執行技術解決方案流程的計畫。 技術解決方案(TS) 542
CMMI for Development Version 詳細說明： 執行技術解決方案流程的計畫可以是專案計畫的一部分(或參考)，專案計畫在專案規劃流程領域中說明。 GP 提供資源 提供充足的資源，以執行技術解決方案流程、發展工作產品及提供流程服務。 詳細說明： 需求的發展、設計及實作，可能要使用特殊設施。如有必要，應發展或購買在技術解決方案流程領域各活動所需設施。 提供的資源，舉例如下： • 設計規格工具 • 模擬器及模型工具 • 雛型工具 • 劇本定義及管理工具 • 需求追蹤工具 • 互動式文件製作工具 GP 指派責任 指派技術解決方案流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援技術解決方案流程。 技術解決方案(TS) 543
CMMI for Development Version 詳細說明： 訓練主題，舉例如下： • 產品及產品組件應用領域 • 設計方法 • 介面設計 • 單元測試技術 • 標準(例如：產品、安全、人為因素、環境) GP 管理建構 將指定的技術解決方案流程工作產品，納入適當層級的控制。 詳細說明： 納入控制的工作產品，舉例如下： • 產品、產品組件、流程、服務及介面設計 • 技術相關資料 • 介面設計文件 • 設計與產品組件再用的準則 • 已實作的設計(例如：軟體程式碼、已裝配的產品組件) • 使用者、安裝、操作及維護文件 GP 界定並納入相關的關鍵人員 依計畫界定並納入與技術解決方案流程相關的關鍵人員。 詳細說明： 在下列人員中考量相關的關鍵人員：客戶、最終使用者、發展者、製造者、測試人員、供應商、市場行銷人員、維護人員、報廢處理人員及其他可能影響或被產品及流程所影響的人。 技術解決方案(TS) 544
CMMI for Development Version 關鍵人員參與的活動，舉例如下： • 發展備選方案及評選準則 • 取得外部介面規格及設計說明之核可 • 發展技術相關資料 • 評量產品組件自製、採購、再用的備選方案 • 實作設計 GP 監控流程 依本流程的執行計畫，監控技術解決方案流程，並採取適當的矯正措施。 詳細說明： 用於監控的度量及工作產品，舉例如下： • 重做所花費的成本、時程及工作量 • 在產品及產品組件設計所涉及的需求比率 • 產品、產品組件、介面及文件的規模大小與複雜度 • 技術解決方案之工作產品的缺失密度 • 設計活動的時程 GP 客觀評估遵循程度 客觀評估技術解決方案流程、工作產品及流程服務，對適用的流程說明、標準及程序的遵循程度，並解決不符合的情況。 技術解決方案(TS) 545
CMMI for Development Version 詳細說明： 審查的活動，舉例如下： • 選擇產品組件解決方案 • 發展產品及產品組件設計 • 實作產品組件設計 審查的工作產品，舉例如下： • 技術相關資料 • 產品、產品組件及介面設計 • 已實作的設計(如：軟體程式碼、裝配好的產品組件) • 使用者、安裝、操作及維護文件 GP 與上層管理人員審查各狀況 與上層管理人員審查技術解決方案流程的活動、狀況及結果，並解決問題。 僅適用連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義技術解決方案流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行技術解決方案流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產未來的使用與改善。 技術解決方案(TS) 546
CMMI for Development Version 詳細說明： 工作產品、度量、度量結果與改善資訊，舉例如下： • 製造、購買或再用的分析結果 • 設計缺失密度 • 應用新方法及工具的結果 技術解決方案(TS) 547
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護技術解決方案流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定技術解決方案流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保技術解決方案流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正技術解決方案流程之缺失與其他問題的根本原因。 技術解決方案(TS) 548
CMMI for Development Version 確認 成熟度第三級的工程類流程領域 目的 確認(Validation, VAL)的目的，在於展示置於預期環境中的產品或產品組件，可滿足其預期的使用需求。 簡介 所有的產品均可於其任何的預期環境中(例如：操作、訓練、製造、維護及支援服務)執行確認活動。可用於工作產品的確認方法，亦能使用於產品及產品組件上。(整個流程領域中，產品及產品組件的意涵也包括服務及其組件) 選擇工作產品（例如：需求、設計、雛型）的基礎在於，何種最佳指標能衡量產品及產品組件可滿足使用者需要的程度，因此在整個產品生命週期，可早點並逐步執行確認。 確認環境應能表達產品及產品組件的預期環境，同時亦能表達適用於工作產品確認活動的預期環境。 確認證明所提供的產品符合預期的使用需求，而驗證說明工作產品是否適當的反映了特定需求。換言之，驗證確保「你把事做對了」，而確認確保「你做了對的事」。確認活動使用與驗證類似的方法，例如：測試、分析、檢查、展示或模擬。通常，確認活動包含了最終使用者及其他相關關鍵人員。確認與驗證活動經常同時執行，且可能使用部分相同的環境。 有關驗證活動，請參考驗證流程領域，以獲得更多資訊。 若有可能，執行確認應將產品或產品組件置於其預期環境中運作。確認可能使用全部或部分的預期環境，使用工作產品執行確認，可讓議題在專案生命確認(VAL) 549
CMMI for Development Version 週期中，透過相關鍵人員的參與來及早發現。服務的確認活動可應用於工作產品，例如建議書、服務目錄、工作說明書，以及服務紀錄。 當確認議題界定後，還需參考需求發展、技術解決方案或專案監控流程領域的執行方法，並予解決。 本流程領域互為基礎的特定執行方法說明如下： • 「選擇需確認之產品」特定執行方法界定需確認的產品或產品組件，與用來執行確認的方法。 • 「建立確認環境」特定執行方法決定用來執行確認的環境。 • 「建立確認程序與準則」特定執行方法依照選定的產品特性、使用者限制、確認方法與確認環境來發展確認程序與準則。 • 「執行確認」特定執行方法依照方法、程序及準則來執行確認。 相關流程領域 有關需求確認，請參考需求發展流程領域，以獲得更多資訊。 有關將需求轉成產品規格，以及界定影響產品或產品組件設計的確認議題界定後，採行矯正措施，請參考技術解決方案流程領域，以獲得更多資訊。 有關驗證產品及產品組件合於需求，請參考驗證流程領域，以獲得更多資訊。 確認(VAL) 550
CMMI for Development Version 特定目標及執行方法摘要 SG 1 確認準備 SP 選擇需確認之產品 SP 建立確認環境 SP 建立確認程序與準則 SG 2 確認產品或產品組件 SP 執行確認 SP 分析確認結果 各目標的特定執行方法 SG 1 確認準備 執行確認準備。 準備活動包含選擇需確認的產品與產品組件，建立並維護確認環境、程序及準則。所選定的確認項目可能僅包含產品， 也可能包含適當層級的產品組件，該產品組件可用以建立產品。任何產品或產品組件均可確認，包括替換、維護及訓練產品等。 準備執行產品或產品組件確認所需環境。環境可以購置或制訂規格、設計及建造。確認環境可考慮產品整合及驗證所使用的環境，以減低成本並提高效率或生產力。 SP 選擇須確認之產品 選擇須確認之產品及產品組件，及每一產品及產品組件使用之確認方法。 根據產品及產品組件與使用者需要的關係，來選擇需確認之產品與產品組件。必須決定每個產品組件確認的範圍(例如：操作行為、維護、訓練及使用者介面)。 確認(VAL) 551
CMMI for Development Version 可被確認的產品及產品組作，舉例如下： • 產品及產品組件的需求與設計 • 產品及產品組件（例如：系統、硬體單元、軟體、服務文件） • 使用者介面 • 使用者手冊 • 訓練教材 • 流程文件 蒐集執行確認的需求與限制，然後依據確認方法展示出滿足使用者需求的能力，來選擇確認方法。確認方法不只定義產品確認的技術，也會主導設施、設備及環境的需求。這會導出由需求發展流程所處理的低階產品組件需求，也可能產生衍生需求，例如測試集與測試設備的介面需求。這些需求均傳送到需求發展流程，以確保產品或產品組件能於可支援確認方法的環境中執行確認。 確認方法應於專案生命週期初期即做選擇，才能讓相關的關鍵人員清楚的瞭解與同意。 適當時，確認方法說明產品與產品組件的發展、維護、支援及訓練。 確認(VAL) 552
CMMI for Development Version 確認的方法，舉例如下： • 與使用者討論，可能在正式審查的場合 • 雛型展示 • 功能性展示（例如：系統、硬體單元、軟體、服務文件、使用者介面） • 訓練教材的試行 • 由最終使用者及其他相關關鍵人員執行產品及產品組件的測試 • 分析產品及產品組件（例如：模擬、塑模、使用者分析） 硬體工程適用 硬體確認活動包括，以塑模執行形式、調適及機械設計的功能的確認；熱模；維護性及可靠性分析；時序展示；以及電子或機械產品組件的電子化設計模擬。 典型的工作產品 1. 需確認的產品或產品組件清單 2. 每一產品或產品組件的確認方法 3. 每一產品或產品組件執行確認的需求 4. 每一產品或產品組件的確認限制 細部執行方法 1. 界定專案生命週期中，產品或產品組件確認的主要原則、特性及階段。 2. 決定需確認何種類型的使用者需要(操作、維護、訓練或支援)。 產品或產品組件於其預期作業環境中，必須是可維護及可支援的。本特定執行方法說明可能伴隨產品一起交付的維護、訓練及支援服務。 確認(VAL) 553
CMMI for Development Version 展示維護工具在實際產品上運作，是於作業環境中評估維護概念的範例之一。 3. 選擇需確認的產品與產品組件。 4. 選擇用以確認產品或產品組件的評估方法。 5. 與相關的關鍵人員共同審查產品或產品組件的確認選擇、限制及方法。 SP 建立確認環境 建立並維護支援確認工作所需的環境。 確認環境的需求可由下列產生：所選擇的產品或產品組件、工作產品的類型(例如：設計、雛型、最終版本)及確認的方法。這會產生採購或自行發展設備、軟體或其他資源的需求。這些需求會提供給需求發展流程進行發展。確認環境可能包含現有資源的再利用，在此狀況下，必須安排這些資源的運用。確認環境包含的要素類型舉例如下： • 測試工具與需確認產品的介面(例如：範圍、電子設備、探針) • 暫時嵌入的測試軟體 • 可將電腦內部資料移轉出來，進一步分析或重新執行的記錄工具 • 以軟體、電子設備或機械設備模擬過的子系統或組件 • 模擬的介面系統(例如：為測試海軍雷達的虛擬戰艦) • 實際介面系統(例如：為測試雷達與彈道追蹤設施的飛行器) • 設施及客戶供應的產品 • 操作及使用前述各要素的熟練人員 • 專用於計算或網路測試的環境(例如：模擬作業的電訊網路測試環境，或由通訊主幹、交換機以及為實際整合與確認所建立的系統，上述三者組成的設施) 確認(VAL) 554
CMMI for Development Version 及早選擇需確認的產品或產品組件、確認需使用的工作產品及確認方法，可確保確認環境於需要時已經備妥。 執行確認所需環境必須謹慎控制，以便複製、分析結果及再次確認有問題部分。 典型的工作產品 1. 執行確認的環境 細部執行方法 1. 界定確認環境需求。 2. 界定客戶供應品。 3. 界定可再用的項目。 4. 界定測試設備及工具。 5. 界定可再用及修改的確認資源。 6. 詳細規劃資源的可用性。 SP 建立確認程序與準則 建立並維護確認程序與準則。 定義確認程序與準則，以確保產品或產品組件置於其預期使用環境中，會符合預期使用需要。驗收測試個案及程序可能合於確認程序的需要。 確認程序與準則包含維護、訓練及支援服務的測試及評估。 確認準則的來源，舉例如下： • 產品與產品組件需求 • 標準 • 顧客驗收準則 • 環境績效 • 績效偏差的門檻 確認(VAL) 555
CMMI for Development Version 典型的工作產品 1. 確認程序 2. 確認準則 3. 維護、訓練及支援服務的測試及評估程序 細部執行方法 1. 審查產品需求，以確保影響產品或產品組件確認的議題已經界定並解決。 2. 記錄用來確認選定的產品或產品組件的環境、操作劇本、程序、輸入、輸出及準則。 3. 當確認環境設計漸趨成熟時，評量設計以界定確認議題。 SG 2 確認產品或產品組件 確認產品或產品組件，以確保在預期作業環境中可適用。 確認方法、程序及準則是用來確認所選擇的產品與產品組件，以及相關的維護、訓練及支援服務。此項確認是在適當的確認環境中進行。整個產品生命週期中，都要執行確認活動。 SP 執行確認 對選定的產品及產品組件執行確認。 為讓使用者接受，產品或產品組件置於預期作業環境中，其工作表現必須完全符合預期要求。 執行確認活動，並依據已建立的方法、程序及準則，蒐集結果資料。 適當時，記錄已執行的確認程序及執行時所發生的偏差。 典型的工作產品 1. 確認報告 2. 確認結果 3. 確認對照表 確認(VAL) 556
CMMI for Development Version 4. 執行程序的紀錄 5. 操作展示 SP 分析確認結果 分析確認活動的結果。 由確認測試、檢查、展示或評估產生的資料，應予分析並與所定義的準則比對。分析報告應指出需求是否符合，如有偏差，報告需記載成功或失敗的程度，並將可能失敗的原因分類。所蒐集的測試、檢查或審查結果，需和已建立的評估準測比較，以決定是否繼續進行，或處理屬於需求發展或技術解決方案流程領域的需求或設計議題。 分析報告或確認文件可能指出，測試結果不佳乃是確認程序或執行環境的問題。 典型的工作產品 1. 確認缺失報告 2. 確認議題 3. 程序變更請求 細部執行方法 1. 比較實際及預期結果。 2. 按已建立的確認準則界定問題。包括界定於預期作業環境下執行不佳的產品或產品組件，或界定確認方法、準則及(或)環境問題。 3. 分析確認缺失資料。 4. 記錄分析結果並界定議題。 5. 利用確認結果，將實際度量及績效，與預期使用或操作需要進行比較。 確認(VAL) 557
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程藉由將可界定之輸入的工作產品轉換為可界定之輸出的工作產品，以支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施確認流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理的流程。 僅適用於階段式流程領域 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行確認流程。 詳細說明： 本政策建立組織的期望，以選擇需確認的產品及產品組件、選擇確認方法、建立並維護確認程序、準則與環境，確保產品及產品組件於其預期操作環境下，能符合使用者的需要。 GP 規劃流程 建立並維護執行確認流程的計畫。 確認(VAL) 558
CMMI for Development Version 詳細說明： 執行確認流程的計畫包含(或參考)在專案計畫。專案計畫在專案規劃流程領域中說明。 GP 提供資源 提供充足的資源，以執行確認流程、發展工作產品及提供流程服務。 詳細說明： 產品及產品組件的確認可能需要特殊設施。必要時，這些確認所需的設施可以自行發展或採購。 其他提供的資源，舉例如下： • 測試管理工具 • 測試個案產生器 • 測試涵蓋分析器 • 模擬器 • 負載、壓力及績效工具 GP 指派責任 指派確認流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援確認流程。 詳細說明： 訓練主題，舉例如下： • 應用領域 • 確認原則、標準及方法 • 預期使用環境 確認(VAL) 559
CMMI for Development Version GP 管理建構 將指定的確認流程工作產品，納入適當層級的管制。 詳細說明： 納入管制的工作產品，舉例如下： • 需確認的產品或產品組件清單 • 確認方法、程序及準則 • 確認報告 GP 界定並納入相關的關鍵人員 依計畫界定並納入確認流程相關的關鍵人員。 詳細說明： 從下列人員中選擇相關的關鍵人員：客戶、使用者、發展者、生產者、測試人員、供應者、行銷人員、維護人員、銷毀人員，以及其他可能被產品及流程影響或可能影響產品及流程的人。 關鍵人員參與的活動，舉例如下： • 選擇要確認的產品與產品組件 • 建立確認方法、程序及準則 • 審查產品及產品組件確認結果，並解決議題 • 與顧客或使用者解決議題 客戶或使用者的議題，當與下述基準需要項目有重大差異時，需予特別解決： • 合約或協議書的豁免權(什麼、何時，以及哪些產品、服務或製造的產品) • 額外的深入研究、試驗、測試或評估 • 合約或協議書可能的變更 確認(VAL) 560
CMMI for Development Version GP 監控流程 依本流程的執行計畫，監控確認流程，並採取適當的矯正措施。 詳細說明： 用以監控的度量及工作產品，舉例如下： • 確認活動完成次數(計畫及實際) • 確認問題報告趨勢(例如：問題數及結案數) • 確認問題報告處理時間(即每一問題報告懸而未決的時間) • 特定確認活動的時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估確認流程的遵循程度，並解決不符合的情況。 詳細說明： 審查的活動，舉例如下： • 選擇須確認的產品及產品組件 • 建立並維護確認方法、程序及準則 • 確認產品或產品組件 審查的工作產品，舉例如下： • 確認方法、程序及準則 GP 與上層管理人員審查各狀況 與上層管理人員審查確認流程的活動、狀況及結果，並解決議題。 確認(VAL) 561
CMMI for Development Version 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義確認流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行確認流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產未來的使用與改善。 詳細說明： 工作產品、度量、度量結果與改善資訊，舉例如下： • 產品組件雛型 • 確認環境之可用時間的百分比 • 每個發展階段中，透過確認所發現的產品缺失數量 • 確認分析報告 確認(VAL) 562
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護確認流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定確認流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保確認流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正確認流程之缺失與其他問題的根本原因。 確認(VAL) 563
CMMI for Development Version 驗證 成熟度第三級的工程類流程領域 目的 驗證(Verification, VER)的目的，在於確保選定的工作產品符合其指定的需求。 簡介 驗證流程領域包括：驗證準備、驗證執行及矯正措施界定。 驗證包括產品及中間工作產品的驗證，將其與選定的客戶需求、產品需求及產品組件需求加以比較。整個流程領域中，產品及產品組件的意涵也包括服務及其組件。 驗證是一種漸進式過程因為它發生於產品及工作產品的發展過程中，從需求驗證開始，經工作產品到最終完成產品的驗證。 互為基礎的本流程領域特定執行方法說明如下： • 「選擇需驗證之工作產品」特定執行方法界定需驗證的工作產品、執行驗證的方法及每一工作產品需滿足的需求。 • 「建立驗證環境」特定執行方法能決定執行驗證所需使用的環境。 • 「建立驗證程序及準則」特定執行方法發展與需驗證的工作產品、需求、方法及驗證環境特性配合的驗證程序與準則。 • 「執行驗證」特定執行方法依據可行的方法、程序及準則執行驗證。 驗證工作產品可實質增加產品符合客戶需求、產品需求及產品組件需求的可能性。 驗證(VER) 564
CMMI for Development Version 驗證及確認流程領域相似，但強調不同重點。「確認」展現所提供的產品(或即將提供的產品)符合其預期使用需求，而「驗證」強調工作產品是否適當反映其指定的需求。換句話說，驗證確保 「你把事做對了(you built it right)」，確認確保「你做了對的事(you built the right thing)」。 同仁審查是驗證的重要部分，也是經證實可以有效去除缺失的機制。發展一套瞭解工作產品及產出流程的方法，以利防制缺失並界定流程改善的有利機會。 同仁審查為有系統的檢查工作產品，以界定缺失及其他變更需求。此項工作是由產品製作人員的同仁來執行。 同仁審查的方法，舉例如下： • 檢查 • 結構化逐步審查 相關流程領域 有關產品或產品組件置於預期環境中，可符合其預期使用需求，請參考確認流程領域，以獲得更多資訊。 有關產生與發展客戶、產品及產品組件需求，請參考需求發展流程領域，以獲得更多資訊。 有關需求管理，請參考需求管理流程領域，以獲得更多資訊。 驗證(VER) 565
CMMI for Development Version 特定目標及執行方法摘要 SG 1 驗證準備 SP 選擇需驗證之工作產品 SP 建立驗證環境 SP 建立驗證程序及準則 SG 2 執行同仁審查 SP 準備同仁審查 SP 進行同仁審查 SP 分析同仁審查資料 SG 3 驗證工作產品 SP 執行驗證 SP 分析驗證結果 各目標的特定執行方法 SG 1 驗證準備 執行驗證準備。 事前準備可確保驗證措施已植入於產品及產品組件需求、設計、發展計畫及時程中。驗證包含工作產品的選擇、檢查、測試、分析及展示。 驗證方法包括(但不限於)檢查、同仁審查、稽核、逐步審查、分析、模擬、測試及展示。與同仁審查有關的執行方法，如特定驗證方法，都包含在特定目標2中。 驗證準備亦需對支援工具、測試設備及軟體、模擬、雛型系統及設施加以定義。 SP 選擇需驗證之工作產品 選擇需驗證之工作產品及每一工作產品使用之驗證方法。 工作產品選擇的基準在於其對符合專案目標及需求，以及可說明專案風險的貢獻程度。 驗證(VER) 566
CMMI for Development Version 需驗證之工作產品包含與維護、訓練及支援相關的服務。工作產品的驗證需求包含驗證方法。驗證方法說明驗證工作產品的方法，以及驗證特定的工作產品符合其需求的特定方法。 軟體工程適用 驗證方法，舉例如下： • 路徑涵蓋度測試 • 負載、壓力及績效測試 • 以決策表為基礎的測試 • 以功能分解為基礎的測試 • 測試個案再用 • 驗收測試 系統工程適用 系統工程的驗證通常包括，雛型製作、塑模，與模擬以驗證系統設計（及配置）的足夠性。 硬體工程適用 硬體工程的驗證通常需要參數化的方法，用來考量不同環境情況（例如：壓力、溫度、震動、濕度）、不同輸入範圍（例如：輸入電力可能介於20至32伏特，當規劃的正常值為28伏特）、零件與零件的容忍議題所引起的變異數，以及其他變數。硬體驗證除了對不確定的互相影響存疑外，通常大多數的變數會分開測試。 選擇驗證方法通常始於參與定義產品及產品組件需求，以確保需求可以驗證。驗證方法必須說明再次驗證如何執行，以確保工作產品經過重新製作後不會引發不可預期的缺失。供應商應參與選擇的過程，以確保專案所採行的方法對於供應商環境是適當的。 驗證(VER) 567
CMMI for Development Version IPPD補充 驗證方法應與產品及產品組件設計同時發展，並不斷反覆檢討修訂。 典型的工作產品 1. 需接受驗證的工作產品清單 2. 每個工作產品的驗證方法 細部執行方法 1. 界定需驗證的工作產品。 2. 界定每個工作產品須符合的需求。 參考需求管理流程領域的「維護需求的雙向追溯性」特定執行方法，以協助界定每一工作產品的需求。 3. 界定可用的驗證方法。 4. 定義每個工作產品的驗證方法。 5. 提出需驗證的工作產品、需滿足的需求及使用的驗證方法，以與專案計畫整合。 有關協調專案規劃的資訊，請參考專案規劃流程領域。 SP 建立驗證環境 建立並維護支援驗證工作的環境。 須建立環境以便執行驗證。執行驗證所需的環境可以購買、自行發展、再利用、修改已存在的環境，或以上所列的組合，端視專案的需求而定。 驗證所需的環境取決於需驗證的工作產品及所使用的方法。同仁審查僅需文件、資料、審查人員及會議室。產品測試可能需要模擬器、劇本產生器、資料量降低工具、環境控制及與其他系統的介面。 驗證(VER) 568
CMMI for Development Version 典型的工作產品 1. 驗證環境 細部執行方法 1. 界定驗證環境需求。 2. 界定可再用及修改的驗證資源。 3. 界定驗證設備及工具。 4. 取得支援驗證的設備及環境，例如：測試設備及軟體。 SP 建立驗證程序與準則 建立並維護所選定的工作產品的驗證程序與準則。 IPPD補充 驗證程序與準則應與產品及產品組件的設計同時且反覆發展。 定義驗證準則，以確保工作產品符合需求。 驗證準則的來源包括： • 產品與產品組件的需求 • 標準 • 組織政策 • 測試類型 • 測試參數 • 測試品質與測試成本間取捨的因素 • 工作產品類型 • 供應商 • 建議書與協議 驗證(VER) 569
CMMI for Development Version 典型的工作產品 1. 驗證程序 2. 驗證準則 細部執行方法 1. 必要時，為工作產品與現成品，製作廣泛且整合的驗證程序。 2. 必要時，發展與調修驗證準則。 3. 界定預期結果、觀察中允許的誤差及其他符合需求的準則。 4. 界定支援驗證所需的設備及與環境有關的組件。 SG 2 執行同仁審查 對選定的工作產品執行同仁審查。 同仁審查為有條理的檢查工作產品，界定需移除之缺失並建議其他需變更事項。此項工作乃由產品製作人員的同仁執行。 同仁審查是重要而且有效的驗證方法，經由檢查、結構化逐步審查或其他經證實的審查方式來執行。 同仁審查主要應用於專案工作產品上，亦可應用在其他工作產品，例如：由支援團隊發展的文件及訓練教材。 SP 準備同仁審查 準備對選定的工作產品進行同仁審查。 同仁審查的準備工作，通常包括：界定受邀參與每一工作產品審查的人員、界定必要參與的主要審查人員、準備及更新同仁審查需使用的資料，例如：檢查表、審查準則及同仁審查時程等。 典型的工作產品 1. 同仁審查時程 驗證(VER) 570
CMMI for Development Version 2. 同仁審查檢查表 3. 工作產品的允入及允出準則 4. 需再次舉行同仁審查的準則 5. 同仁審查訓練教材 6. 已選定待審查的工作產品 細部執行方法 1. 決定採用哪一種同仁審查類型。 同仁審查的類型，舉例如下： • 檢查 • 結構化逐步審查 • 主動審查 2. 針對同仁審查時所應蒐集的資料，定義其需求。 有關界定及蒐集資料的資訊，請參考度量與分析流程領域。 3. 建立並維護同仁審查的允入及允出準則。 4. 建立並維護再次審查工作產品的準則。 5. 建立並維護檢查表，以確保工作產品審查的一致性。 檢查表包括的項目，舉例如下： • 架構原則 • 設計指引 • 完整性 • 正確性 • 維護性 • 共通缺失的類型 驗證(VER) 571
CMMI for Development Version 視工作產品及同仁審查的特性修改檢查表，並由發展檢查表的同仁及可能的使用者審查檢查表。 6. 發展詳細的同仁審查時程，包括同仁審查的訓練日期及審查所需資料的完成時程。 7. 工作產品分發前，需先確保其符合同仁審查允入準則。 8. 提早分發工作產品及其相關資訊給審查人員，使審查人員有足夠的準備時間。 9. 適當地指派人員所擔任的角色。 審查人員的角色，舉例如下： • 負責人 • 讀者 • 記錄者 • 作者 10. 先行審查工作產品，以準備進行同仁審查。 SP 進行同仁審查 針對所選定的工作產品進行同仁審查，並由同仁審查的結果界定議題。 執行同仁審查目的之一，即是能及早發現並去除缺失。同仁審查是隨著工作產品的發展逐步進行。此種審查為結構化的，但並非管理審查。 可以針對規格、設計、測試及實作活動的關鍵工作產品，以及特定的規劃性質工作產品執行同仁審查。 同仁審查重點應為被審查的工作產品，而非工作產品的製作人員。 同仁審查發現的議題，應與工作產品的主要製作人員溝通，以便修正。 驗證(VER) 572
CMMI for Development Version 有關追蹤同仁審查發現的議題，請參考專案監控流程領域。 同仁審查須強調下列指引：必須充分準備、須於管控下執行、須記錄一致且充分的資料 (例如：執行正式審查) 及須記錄行動方案。 典型的工作產品 1. 同仁審查結果 2. 同仁審查議題 3. 同仁審查資料 細部執行方法 1. 依指派的角色進行審查。 2. 界定並記錄工作產品的缺失及其他議題。 3. 記錄審查結果，包括行動方案。 4. 蒐集同仁審查資料。 有關資料蒐集，請參考度量與分析流程領域，以獲得更多資訊。 5. 界定行動方案並與相關的關鍵人員溝通議題。 6. 若已定義的準則指出需要性，則需再次執行審查。 7. 確保符合審查的允出準則。 SP 分析同仁審查資料 分析同仁審查的準備、執行及結果資料。 有關獲得與分析同仁審查資料，請參考度量與分析流程領域，以獲得更多資訊。 典型的工作產品 1. 同仁審查資料 2. 同仁審查行動方案 驗證(VER) 573
CMMI for Development Version 細部執行方法 1. 記錄同仁審查準備、執行及結果的資料。 典型的資料通常包括產品名稱、產品規模大小、審查成員、審查類型、每一審查人員的準備時間、審查會議時間、缺失數、缺失類型及發生處等。其他可能蒐集的工作產品資訊，例如：規模大小、發展階段、所檢查的操作模式及被評估的需求。 2. 保存資料，以便日後參考及分析。 3. 保護資料，以確保同仁審查資料無不當使用。 使用資料評估人員績效、將審查結果歸屬到個人的績效上是不當使用同仁審查資料的範例。 4. 分析同仁審查資料。 可用來分析的同仁審查資料，舉例如下： • 被植入的階段缺失 • 相對於期望時間或速率的準備時間或速率 • 相對於期望數量的缺失數量 • 已發現的缺失種類 • 缺失的原因 • 缺失解決方案的衝擊 SG 3 驗證工作產品 依照其指定的需求,驗證所選定的工作產品。 使用驗證的方法、程序及準則，並在適當的驗證環境中，來驗證已選擇的工作產品及其他相關的維護、訓練，及支援服務。整個產品生命週期都應該執行驗證活動。與同仁審查有關的執行方法，定位為或如同特定驗證方法，包含在特定目標2中。 驗證(VER) 574
CMMI for Development Version SP 執行驗證 對選定的工作產品執行驗證。 於產品及工作產品發展過程中，逐步執行驗證，促使及早發現問題，並能及早移除缺失。驗證結果節省了耗用在尋找問題過程中，將問題獨立出來及重做的可觀成本。 典型的工作產品 1. 驗證結果 2. 驗證報告 3. 展示 4. 執行程序紀錄 細部執行方法 1. 依據需求，針對選定的工作產品執行驗證。 2. 記錄驗證活動的結果。 3. 由工作產品的驗證結果，界定行動方案。 4. 記錄所執行的驗證方法，以及在執行中發現與可行方法及程序的偏差。 SP 分析驗證結果 分析所有驗證活動的結果。 真實的結果必須與驗證準則比較，以決定可接受性。 記錄分析結果，作為驗證執行的證據。 對於每一工作產品，所有可用的驗證結果需逐項分析，以確保工作產品符合需求。因為同仁審查為驗證方法之一，同仁審查資料必須包括在分析活動中，以確保驗證結果已經充分分析。分析報告或執行方法的紀錄，可能指出不良的驗證結果肇因於驗證方法、準則或基礎環境架構的問題。 驗證(VER) 575
CMMI for Development Version 典型的工作產品 1. 分析報告(例如：績效統計值、不符合事項的原因分析、實際產品與模式的比較、趨勢等) 2. 問題報告 3. 驗證方法、準則及環境的變更需求 細部執行方法 1. 比較實際與預期結果。 2. 以驗證準則為基準，界定未符合需求的產品，或界定方法、程序、準則及驗證環境的問題。 3. 分析與缺失有關的驗證資料。 4. 記錄所有分析結果並製成報告。 5. 運用驗證結果，比較實際度量及績效與技術性績效參數間的差異。 6. 提供缺失如何解決的資訊(包含驗證方法、準則及驗證環境)，並開始實施矯正措施。 有關矯正措施的實施，請參考專案監控流程領域之矯正措施執行方法，以獲得更多資訊。 驗證(VER) 576
CMMI for Development Version 各目標的一般執行方法 僅適用於連續式表述 GG 1 達成特定目標 本流程藉由將可界定之輸入的工作產品轉換為可界定之輸出的工作產品，以支援與促成流程領域特定目標的達成。 GP 實施特定執行方法 實施驗證流程的特定執行方法，以發展工作產品與提供服務，達成流程領域的特定目標。 GG 2 制度化已管理流程 將流程制度化為已管理的流程。 僅適用於階段式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在階段式表述的位置。 GP 建立組織政策 建立並維護組織政策，以規劃和執行驗證流程。 詳細說明： 本政策建立組織對建立並維護驗證方法、程序、準則與驗證環境、以及對執行同仁審查及驗證選定的工作產品的期望。 GP 規劃流程 建立並維護執行驗證流程的計畫。 驗證(VER) 577
CMMI for Development Version 詳細說明： 執行驗證流程的計畫可包含在(或參考)專案計畫。專案計畫在專案規劃流程領域中說明。 GP 提供資源 提供充足的資源，以執行驗證流程、發展工作產品及提供流程服務。 詳細說明： 驗證選定的工作產品可能需要特殊設施，這些驗證流程領域活動所需要的設施可以自行發展或採購。 某些驗證方法可能需要特別的工具、設備、設施及訓練(例如：同仁審查可能需要會議室及受過訓練的會議主席，有些驗證測試可能需要特殊測試設備以及熟悉設備使用的人員)。 其他提供的資源，舉例如下： • 測試管理工具 • 測試個案產生器 • 測試涵蓋分析器 • 模擬器 GP 指派責任 指派驗證流程的責任與授權，以執行流程、發展工作產品及提供流程服務。 GP 訓練人員 依需要訓練人員，以執行或支援驗證流程。 驗證(VER) 578
CMMI for Development Version 詳細說明： 訓練主題，舉例如下： • 應用或服務領域 • 驗證原則、標準及方法(例如：分析、展示、檢查、測試) • 驗證工具及設施 • 同仁審查準備及作業程序 • 會議協調技巧 GP 管理建構 將指定的驗證流程工作產品，納入適當層級的管制。 詳細說明： 納入管制的工作產品，舉例如下： • 驗證程序與準則 • 同仁審查訓練教材 • 同仁審查資料 • 驗證報告 GP 界定並納入相關的關鍵人員 依計畫界定並納入驗證流程相關的關鍵人員。 詳細說明： 從下列人員中選擇相關的關鍵人員：客戶、使用者、發展者、生產者、測試人員、供應者、行銷人員、維護人員、銷毀人員，以及其他可能被產品及流程影響或可能影響產品及流程的人。 驗證(VER) 579
CMMI for Development Version 關鍵人員參與的活動，舉例如下： • 選擇需驗證之工作產品與驗證方法 • 建立驗證程序及準則 • 執行同仁審查 • 評量驗證結果並界定矯正措施 GP 監控流程 依本流程的執行計畫，監控驗證流程，並採取適當的矯正措施。 詳細說明： 用以監控的度量及工作產品，舉例如下： • 驗證摘要(例如：計畫與執行驗證的次數、發現的缺失數，並將缺失依驗證方法或類型分類) • 每一缺失類型發現的缺失數 • 驗證問題報告趨勢(例如：問題數量及結案數量) • 驗證問題報告狀況(例如：每一問題報告懸而未解的時間) • 特定驗證活動的時程 GP 客觀評估遵循程度 依本流程的說明、標準及程序，客觀評估驗證流程的遵循程度，並解決不符合的情況。 驗證(VER) 580
CMMI for Development Version 詳細說明： 審查的活動，舉例如下： • 選擇需驗證的工作產品 • 建立並維護驗證程序與準則 • 執行同仁審查 • 驗證所選定的工作產品 審查的工作產品，舉例如下： • 驗證程序與準則 • 同仁審查檢查表 • 驗證報告 GP 與上層管理人員審查各狀況 與上層管理人員審查驗證流程的活動、狀況及結果，並解決議題。 僅適用於連續式表述 GG 3 制度化已定義流程 將流程制度化為已定義流程。 本一般目標反映在連續式表述的位置。 GP 建立已定義流程 建立並維護已定義驗證流程的說明。 GP 蒐集改善資訊 蒐集由規劃及執行驗證流程所衍生的工作產品、度量、度量結果及改善資訊，以支援組織流程與流程資產未來的使用與改善。 驗證(VER) 581
CMMI for Development Version 詳細說明： 工作產品、度量、度量結果與改善資訊，舉例如下： • 同仁審查紀錄包括，執行時間及平均準備時間 • 每個發展階段中，透過驗證所發現的產品缺失數量 • 驗證及分析報告 驗證(VER) 582
CMMI for Development Version 僅適用於連續式表述 GG 4 制度化已量化管理流程 將流程制度化為已量化管理流程。 GP 建立流程的量化目標 建立並維護驗證流程的量化目標，該目標用來處理以客戶需要與經營目標為基礎的品質與流程績效。 GP 穩定子流程績效 穩定一個或多個子流程的績效，以決定驗證流程的能力，是否達成已建立之量化品質與流程績效目標。 GG 5 制度化最佳化流程 將流程制度化為最佳化流程。 GP 確保持續的流程改善 確保驗證流程的持續改善，以實現相關的組織經營目標。 GP 矯正問題的根本原因 界定並矯正驗證流程之缺失與其他問題的根本原因。 驗證(VER) 583
CMMI for Development Version 第三部份 附錄與詞彙 附錄與詞彙 584
CMMI for Development Version 附錄與詞彙 585
CMMI for Development Version 附錄A. 參考資料 公開的資料 Ahern 2003 Ahern, Dennis M.; Clouse, Aaron; and Turner, Richard. CMMI Distilled: A Practical Introduction to Integrated Process Improvement, Second Edition. Boston: Addison-Wesley, 2003. Ahern 2005 Ahern, Dennis M.; Armstrong, Jim; Clouse, Aaron; Ferguson, Jack R.; Hayes, Will; and Nidiffer, Kenneth E. CMMI SCAMPI Distilled: Appraisals for Process Improvement. Boston: Addison-Wesley, 2005. Chrissis 2003 Chrissis, Mary Beth; Konrad, Mike; and Shrum, Sandy. CMMI: Guidelines for Process Integration and Product Improvement. Boston: Addison-Wesley, 2003. Crosby 1979 Crosby, Philip B. Quality Is Free The Art of Making Quality Certain. New York: McGraw-Hill, 1979. Curtis 2002 Curtis, Bill; Hefley, William E.; and Miller, Sally A. The People Capability Maturity Model Guidelines for Improving the Workforce. Boston: Addison-Wesley, 2002. Deming 1986 Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Center for Advanced Engineering, 1986. DoD 1996 Department of Defense. DoD Guide to Integrated Product and Process Development (Version ). Washington, DC: Office of the Under Secretary of Defense (Acquisition and Technology), February 5, 1996; Dymond 2004 Dymond, Kenneth M. A Guide to the CMMI: Interpreting the Capability Maturity Model Integration. Annapolis, MD: Process Transition International Inc., 2004. 參考資料 586
CMMI for Development Version EIA 1994 Electronic Industries Alliance. EIA Interim Standard: Systems Engineering (EIA/IS-632). Washington, DC, 1994. EIA 1998 Electronic Industries Alliance. Systems Engineering Capability Model (EIA/IS-731). Washington, DC, 1998; (Note: This model has been retired by EIA.) GEIA 2004 Government Electronic Industries Alliance. Data Management (GEIA-859). Washington, DC, 2004; Gibson 2006 Gibson, Diane L.; Goldenson, Dennis R. and Kost, Keith. Performance Results of CMMI-Based Process Improvement. (CMU/SEI-2006-TR-004). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, July 2006. Humphrey 1989 Humphrey, Watts S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989. IEEE 1990 Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York: IEEE, 1990. ISO 1987 International Organization for Standardization. ISO 9000: International Standard. New York, 1987; ISO 1995 International Organization for Standardization and International Electrotechnical Commission. ISO/IEC TR 12207 Information Technology—Software Life Cycle Processes, 1995; ISO 1998 International Organization for Standardization and International Electrotechnical Commission. ISO/IEC TR 15504 Information Technology—Software Process Assessment, 1998; ISO 2000 International Organization for Standardization. ISO 9001, Quality Management Systems—Requirements, 2000; 參考資料 587
CMMI for Development Version ISO 2002a International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15939 Software Engineering—Software Measurement Process, 2002; ISO 2002b International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15288 Systems Engineering—System Life Cycle Processes, 2002; ISO 2006 International Organization for Standardization and International Electrotechnical Commission. ISO/IEC TR 15504 Information Technology—Software Process Assessment Part 1: Concepts and Vocabulary, Part 2: Performing an Assessment, Part 3: Guidance on Performing an Assessment, Part 4: Guidance on Use for Process Improvement and Process Capability Determination, Part 5: An Exemplar Process Assessment Model, 2003-2006; Juran 1988 Juran, Joseph M. Juran on Planning for Quality. New York: Macmillan, 1988. McGarry 2000 McGarry, John; Card, David; Jones, Cheryl; Layman, Beth; Clark, Elizabeth; Dean, Joseph; and Hall, Fred. Practical Software Measurement: Objective Information for Decision Makers. Boston: Addison-Wesley, 2002. SEI 1995 Software Engineering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995. SEI 1997a Integrated Product Development Capability Maturity Model, Draft Version . Pittsburgh, PA: Enterprise Process Improvement Collaboration and Software Engineering Institute, Carnegie Mellon University, July 1997; (Note: This model was never officially released and is no longer publicly available.) SEI 1997b Software Engineering Institute. Software CMM, Version (Draft C), October 22, 1997; (Note: This model was never officially released and is no longer publicly available.) 參考資料 588
CMMI for Development Version SEI 2001 Paulk, Mark C.; and Chrissis, Mary Beth. The 2001 High Maturity Workshop (CMU/SEI-2001-SR-014). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, January 2002; SEI 2002a CMMI Product Development Team. CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Version Staged Representation (CMU/SEI-2002-TR-012, ESC-TR-2002-012). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, March 2002; SEI 2002b CMMI Product Development Team. CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Version Continuous Representation (CMU/SEI-2002-TR-011, ESC-TR-2002-011). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, March 2002; SEI 2002c Software Engineering Institute. Software Acquisition Capability Maturity Model (SA-CMM) Version (CMU/SEI-2002-TR-010, ESC-TR-2002-010). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, March 2002; SEI 2004 Software Engineering Institute. CMMI A-Specification, Version 1. 6, February 2004; SEI 2005 Software Engineering Institute. CMMI Acquisition Module (CMMI-AM) Version (CMU/SEI-2005-TR-011). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, May 2005; 參考資料 589
CMMI for Development Version SEI 2006a CMMI Product Development Team. ARC , Appraisal Requirements for CMMI, Version (CMU/SEI-2006-TR-011). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, July 2006; SEI 2006b CMMI Product Development Team. SCAMPI , Standard CMMI Appraisal Method for Process Improvement, Version : Method Definition Document (CMU/SEI-2006-HB-002). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, July 2006; Shewhart 1931 Shewhart, Walter A. Economic Control of Quality of Manufactured Product. New York: Van Nostrand, 1931. 定期更新的資料 SEI 1 Software Engineering Institute. The IDEAL Model; SEI 2 Software Engineering Institute. CMMI Frequently Asked Questions (FAQs); SEI 3 Software Engineering Institute. CMMI Performance Results; 參考資料 590
CMMI for Development Version 附錄B. 縮寫字 API 應用程式介面 ARC CMMI評鑑需求 CAD 電腦輔助設計 CAR 原因分析與解決方案(流程領域) CCB 建構管制委員會 CL 能力度層級 CM 建構管理(流程領域) CMM 能力成熟度模式 CMMI 能力成熟度整合模式 CMMI-DEV CMMI適用於發展 CMMI-DEV+IPPD CMMI適用於含整合的產品與流程發展 COTS 現成品 CPI 成本績效指標 CPM 關鍵路徑方法 CSCI 電腦軟體建構項目 DAR 決策分析與解決方案(流程領域) DoD 國防部 EIA 電子工業協會 EIA/IS 電子工業協會過渡期標準 EPG 工程流程組 FCA 功能建構稽核 GG 一般目標 GP 一般執行方法 IBM 國際商業機器公司 縮寫字 591
CMMI for Development Version IDEAL 啟始、診斷、建立、行動、學習 IEEE 電子電機工程學會 INCOSE 國際系統工程協會 IPD-CMM 整合的產品發展能力成熟度模式 IPM 整合的專案管理(流程領域) IPM+IPPD 整合的專案管理含IPPD(流程領域) IPPD 整合的產品與流程發展 ISO 國際標準組織 ISO/IEC 國際標準組織與國際電機協會 MA 度量與分析(流程領域) MDD 方法定義文件 ML 成熟度層級 NDI 非發展項目 NDIA 國家國防工業協會 OID 組織創新與推展(流程領域) OPD 組織流程定義(流程領域) OPD+IPPD 組織流程定義含IPPD(流程領域) OPF 組織流程專注(流程領域) OPP 組織流程績效(流程領域) OT 組織訓練(流程領域) OUSD (AT&L) 國防部助理部長辦公室(採購、技術及後勤) P-CMM 人員能力成熟度模式 PA 流程領域 PCA 實體建構稽核 PERT 計畫評核與審查技術 PI 產品整合(流程領域) PMC 專案監控(流程領域) PP 專案規劃(流程領域) 縮寫字 592
CMMI for Development Version PPQA 流程與產品品質保證(流程領域) QA 品質保證 QFD 品質功能展開 QPM 量化專案管理(流程領域) RD 需求發展(流程領域) REQM 需求管理(流程領域) ROI 投資報酬率 RSKM 風險管理(流程領域) SA-CMM 軟體採購能力成熟度模式 SAM 供應商協議管理(流程領域) SCAMPI CMMI流程改善標準評鑑方法 SECM 系統工程能力模式 SEI 軟體工程學院 SG 特定目標 SP 特定執行方法 SPI 時程績效指標 SW-CMM 軟體能力成熟度模式 TS 技術解決方案(流程領域) URL 統一資源定址器 VAL 確認(流程領域) VER 驗證(流程領域) WBS 分工結構圖 縮寫字 593
CMMI for Development Version 附錄C. CMMI-DEV專案參與人員 許多菁英從一開始就是產品組的成員，一直從事建立與維護CMMI產品系列。本附錄列出參與CMMI 版的人員。本發展團隊有四個主要小組：產品團隊、贊助組、推動組及建構管制委員會。這些小組的現有成員如下所列，如要知道前幾年更完整的參與人員清單，參考模式 版之附錄C。 產品團隊 產品團隊審查由CMMI使用者提出變更CMMI產品系列的變更要求，包括架構、模式、訓練及評鑑材料。發展活動依據變更要求、推動組提供的V 版指引及建構管制委會成員的輸入資料。 V 版發行的計畫經理為Mike Phillips，他協調下列團隊的努力成果。 模式團隊成員 • Armstrong, Jim (Systems and Software Consortium) • Bate, Roger (Software Engineering Institute) • Cepeda, Sandra (RD&E Command, Software Engineering Directorate) • Chrissis, Mary Beth (Software Engineering Institute) • Clouse, Aaron (Raytheon) • D'Ambrosa, Mike (BAE Systems) • Hollenbach, Craig (Northrop Grumman) 15• Konrad, Mike (Software Engineering Institute) • Norimatsu, So (Norimatsu Process Engineering Laboratory, Inc.) • Richter, Karen (Institute for Defense Analyses) • Shrum, Sandy (Software Engineering Institute) 15 團隊負責人 CMMI-DEV專案參與人員 594
CMMI for Development Version SCAMPI 更新團隊成員 16• Busby, Mary (Lockheed Martin) • Cepeda, Sandra (RD&E Command, Software Engineering Directorate) 16• Ferguson, Jack (Software Engineering Institute) • Hayes, Will (Software Engineering Institute) • Heil, James (. Army) in memoriam • Kirkham, Denise (Boeing) • Masters, Steve (Software Engineering Institute) • Ming, Lisa (BAE Systems) • Ryan, Charlie (Software Engineering Institute) • Sumpter, Beth (National Security Agency) • Ulrich, Ron (Northrop Grumman) • Wickless, Joe (Software Engineering Institute) 訓練團隊成員 • Chrissis, Mary Beth (Software Engineering Institute) • Gibson, Diane (Software Engineering Institute) • Knorr, Georgeann (Software Engineering Institute) • Kost, Keith (Software Engineering Institute) • Matthews, Jeanne (Software Engineering Institute) • Shrum, Sandy (Software Engineering Institute) • Svolou, Agapi (Software Engineering Institute) 17• Tyson, Barbara (Software Engineering Institute) • Wickless, Joe (Software Engineering Institute) • Wolf, Gary (Raytheon) 架構團隊成員 • Bate, Roger (Software Engineering Institute) • Chrissis, Mary Beth (Software Engineering Institute) 16 團隊負責人 17 團隊負責人 CMMI-DEV專案參與人員 595
CMMI for Development Version • Hoffman, Hubert (General Motors) • Hollenbach, Craig (Northrop Grumman) • Ming, Lisa (BAE Systems) 18• Phillips, Mike (Software Engineering Institute) • Scibilia, John (. Army) • Wilson, Hal (Northrop Grumman) • Wolf, Gary (Raytheon) 硬體團隊成員 • Armstrong, Jim (Systems and Software Consortium) • Bishop, Jamie (Lockheed Martin) • Cattan, Denise (Spirula) • Clouse, Aaron (Raytheon) • Connell, Clifford (Raytheon) • Fisher, Jerry (Aerospace Corporation) • Hertneck, Christian (Siemens) • Nussbaum, Winfried (Siemens) 19• Phillips, Mike (Software Engineering Institute) • Zion, Christian (THALES) 試行團隊成員 20• Brown, Rhonda (Software Engineering Institute) • Chrissis, Mary Beth (Software Engineering Institute) • Ferguson, Jack (Software Engineering Institute) • Konrad, Mike (Software Engineering Institute) • Phillips, Marilyn (Q-Labs, Inc.) 20• Phillips, Mike (Software Engineering Institute) • Tyson, Barbara (Software Engineering Institute) 18 團隊負責人 19 團隊負責人 20 團隊負責人 CMMI-DEV專案參與人員 596
CMMI for Development Version 品質團隊成員 21• Brown, Rhonda (Software Engineering Institute) • Kost, Keith (Software Engineering Institute) • McSteen, Bill (Software Engineering Institute) • Shrum, Sandy (Software Engineering Institute) 贊助者 CMMI 版由政府及工業界贊助，政府贊助由美國國防部提供，特別是國防部助理部長辦公室(採購、技術及後勤)( OUSD [AT&L])，工業界贊助由國家國防工業協會(NDIA)的系統工程委員會提供。 • Rassa, Bob (NDIA Systems Engineering Division) • Schaeffer, Mark (OUSD [AT&L]) 推動組 推動組指導與核准V 版產品團隊的計畫，提供重大CMMI專案議題的諮詢，與確保來自眾多有興趣團體的參與。 推動組成員 • Baldwin, Kristen (OUSD [AT&L] DS/SE) • Chittister, Clyde (Software Engineering Institute) • D'Agosto, Tony (. Army RDECOM-ARDEC) • Gill, Jim (Boeing Integrated Defense Systems) • Kelly, John (NASA HQ) • Lundeen, Kathy (Defense Contract Management Agency) • McCarthy, Larry (Motorola, Inc.) 22• Nicol, Mike (. Air Force ASC/EN) • Peterson, Bill (Software Engineering Institute) 23• Rassa, Bob (Raytheon Space & Airborne Systems) • Weszka, Joan (Lockheed Martin) 21 團隊負責人 22 政府協同主席 23 產業協同主席 CMMI-DEV專案參與人員 597
CMMI for Development Version • Wilson, Hal (Northrop Grumman Mission Systems) • Zettervall, Brenda (. Navy, ASN/RDA CHENG) 官方推動組成員 • Anderson, Lloyd (Department of Homeland Security) • Bate, Roger; chief architect (Software Engineering Institute) • Drake, Thomas (National Security Agency) • Phillips, Mike; CMMI program manager (Software Engineering Institute) • Sumpter, Beth (National Security Agency) • Yedlin, Debbie (General Motors) 推動組支援：採購 • Gallagher, Brian (Software Engineering Institute) 推動組支援：變更管制委員會 • Konrad, Mike (Software Engineering Institute) 變更管制委員會 變更管制委員會為管制CMMI-DEV模式V 版變更的正式機制。這個組負責審查針對基準的變更並且只核准符合版相關準則的變更，以執行產品整合。 變更管制委員會成員 • Atkinson, Shane (Borland/TeraQuest) • Bate, Roger (Software Engineering Institute) • Bernard, Tom (. Air Force) • Chrissis, Mary Beth (Software Engineering Institute) • Croll, Paul (Computer Sciences Corporation) • Gristock, Stephen (JPMorganChase) CMMI-DEV專案參與人員 598
CMMI for Development Version • Hefner, Rick (Northrop Grumman Corporation) • Jacobsen, Nils (Motorola) 24• Konrad, Mike (Software Engineering Institute) • Osiecki, Lawrence (. Army) • Peterson, Bill (Software Engineering Institute) • Phillips, Mike (Software Engineering Institute) • Rassa, Bob (Raytheon) • Richter, Karen (Institute for Defense Analyses) • Sapp, Millee (. Air Force) • Schoening, Bill (Boeing and INCOSE) • Schwomeyer, Warren (Lockheed Martin) • Smith, Katie (. Navy) • Wolf, Gary (Raytheon) 無投票權變更管制委員會成員 • Brown, Rhonda (Software Engineering Institute) • Shrum, Sandy (Software Engineering Institute) 24 變更管制委員會主席 CMMI-DEV專案參與人員 599
CMMI for Development Version D.詞彙 CMMI詞彙定義用於CMMI模式的基本術語。詞彙通常是數個字的術語，包含一個名詞與一個或一個以上的限制修飾詞。(此規則有部分例外，詞彙中也有一個字的術語說明)。 為有系統的說明適合CMMI的定義，我們諮詢許多的來源出處。首先我們參考韋氏線上字典()及來源模式(如EIA 731,SW-CMM V2. draft C 及IPD-CMM )。如有需要我們也參考其它標準，包括下列： • ISO 9000 [ISO 1987] • ISO/IEC 12207 [ISO 1995] • ISO/IEC 15504 [ISO 2006] • ISO/IEC 15288 [ISO 2002b] • IEEE [IEEE 1990] • SW-CMM • EIA 632 [EIA 1994] • SA-CMM [SEI 2002c] • P-CMM [Curtis 2002] 我們發展詞彙乃是基於「使所有模式的使用者都瞭解專門術語」之重要性的認知。同時文字與術語在不同的內文與環境，有不同的意義。CMMI模式的詞彙用來記載文字與術語的意義，應是使用最廣泛且應為CMMI產品使用者所瞭解的。 驗收準則 產品或產品組件必須符合的準則，以讓使用者、客戶或其他經授權的實體能接受該產品或產品組件。 詞彙 600
CMMI for Development Version 驗收測試 讓使用者、客戶或其他經授權的實體決定是否對接受產品或產品組件，所執行的正式測試。(請參見「元件測試」。) 達成摘要 連續式表述中，在提升能力程度時，一組流程領域與其相關的能力度，表示組織於每個流程領域的進度。(請參見「能力度摘要」、「目標摘要」及「目標階段式」。) 採購 經由合約取得產品(物品及服務)的流程。 採購策略 根據供應的來源、採購的方法、需求規格的類型、合約或協議的類型及相關的採購風險以決定產品與服務之採購的特定方法。 補充 在CMMI產品系列中，清楚註記的模式元件含有特定的使用者有興趣的資訊。CMMI模式中，所有的補充說明帶有相同的名稱(如IPPD補充說明) 可當作一組來選用。 足夠的 經由這些字詞的使用，你可以依組織的經營目標來詮釋模式的目標及執行方法。當使用任何CMMI 模式的時候，你必須詮釋執行方法使其適用於貴組織。而在模式的目標及執行方法中使用這些字詞，可以用來說明其中的某些活動並不是一直都要進行。(請參見「適當的」及「視需要的」) 配置的需求 將較高階需求的所有或部分績效及功能，賦予較低階架構元件或設計組件的需求。 替代的執行方法 可用以替代CMMI模式中，一個或多個一般或特定執行方法的執行方法，該執行方法在達成CMMI的一般或者特定目標時，具有相同的效果。替代的執行方法未必與一般或特定的執行方法是一對一的替代關係。 強化 強化(amplifications)是助益的模式組件，包含特定專業領域的相關資訊。例如：想找軟體工程的專業領域強化，可以在模式中尋找標示為「軟體工程適用(For Software Engineering)」的標籤。此方式也適用於找其他專業領域強化的資訊。 詞彙 601
CMMI for Development Version 評鑑 在CMMI產品系列中，「評鑑(appraisal)」是指一群訓練有素的專家，以評鑑的參考模式(reference model)為基礎，對一個或多個流程進行檢驗，至少做到決定其優點及缺點。(請參見「評量」及「能力評估」) 評鑑調查結果 評鑑調查結果界定出評鑑範圍內流程改善最重要的議題、問題或機會。評鑑調查結果是根據證實的客觀證據推論得到。 評鑑參與者 在評鑑時，提供資料的組織單位成員。 評鑑評等 如同CMMI評鑑資料所定義的，由評鑑組對於(a)CMMI的目標或流程領域、(b)流程領域的能力度，或(c)組織單位的成熟度，指定評分。經由執行評鑑方法定義的評等流程來決定評等。 評鑑參考模式 如同CMMI評鑑資料所定義的，評鑑組將已實施的流程活動與此CMMI模式相互關連。 評鑑範圍 定義評鑑的界限，包含將被調查運作流程的組織界限與CMMI模式界限。 適當的 經由這個字詞的使用，你可以依組織的經營目標來詮釋模式的目標及執行方法。當使用任何CMMI 模式的時候，你必須詮釋執行方法使其適用於貴組織。而在模式的目標及執行方法中使用這些字詞，可以用來說明其中的某些活動並不是一直都要進行。(請參見「足夠的」及「視需要的」) 視需要的 經由這個字詞的使用，你可以依組織的經營目標來詮釋模式的目標及執行方法。當使用任何CMMI 模式的時候，你必須詮釋執行方法使其適用於貴組織。而在模式的目標及執行方法中使用這些字詞，可以用來說明其中的某些活動並不是一直都要進行。(請參見「足夠的」及「適當的」) 詞彙 602
CMMI for Development Version 評量 在CMMI產品系列中，組織為了本身流程改善的目的所進行的一種評鑑。「評量」在CMMI產品系列中使用的意義與日常使用的意義相同(例如:風險評量)。(請見「評鑑」及「能力評估」) 流程變異的可指在CMMI中，以「流程變異的特殊原因」來定原因 替代「流程變異的可指定原因」以確保一致性，兩者皆有相同的定義。(請參見「流程變異的特殊原因」。) 稽核 在CMMI流程改善的工作中，依據特定的準則(例如:需求)，客觀的檢驗一項工作產品或一組工作產品。 基礎度量 一個實體的明確特性或特徵，以及將其量化的方法。(請參見「衍生度量」。) 基準 經正式審查及同意的一組規格或工作產品，據以用作未來發展的基礎，而且僅能由變更管制程序變更。(請參見「建構基準」及「產品基準」) 雙向追溯性 兩個或更多個邏輯實體間可辨識的雙向關聯(如指向與來自某個實體)。(請參見「需求追溯性」及「追溯性」) 經營目標 (請參見「組織經營目標」。) 能力評估 由一組受過訓練的專業人員所作的評鑑，以作為選擇供應商、依合約監督供應商、或決定與強制實施誘因之辨識工具。評估用來洞察供應商組織的流程能力，幫助決策者做更好的採購決定、改善分包商的績效及提供採購組織的洞察力。(請參見「評鑑」及「評量」。) 能力程度 個別流程領域內流程改善達到的程度，能力度由流程領域內適當的特定及一般執行方法所定義。(請參見「一般目標」、「一般執行方法」、「成熟度等級」及「流程領域」。) 詞彙 603
CMMI for Development Version 能力度摘要 在連續式表述中，一組流程領域與其對應的能力度。(請參見「達成摘要」、「目標摘要」及「目標階段式」。) 當摘要用來表示在提升能力度過程中，組織於每個流程領域的進度，這個摘要可能是達成摘要。或者當它用來表示流程改善的目標時，可能是目標摘要。 能力成熟度模式 模式包含一個或多個專業領域的有效流程之基本元件。它也描述漸進的改善途徑，從隨興的不成熟的流程到具有改善品質及有效性的有紀律的成熟流程。 有能力的流程 能滿足其特定的產品品質、服務品質及流程績效目標的流程。(請參見「穩定流程」、「標準流程」及「統計化管理流程」。) 原因分析 分析缺失以找出其原因。 變更管理 審慎使用各種方法，以達成產品或服務的變更或建議的變更。(請參見「建構管理」。) CMMI架構 組織CMMI組件的基本結構，包括目前CMMI 模式中的共同元件、模式產出的規則及方法、評鑑方法(包括相關的產出)及其訓練教材。這個架構可讓新的專業領域加到CMMI 中，並使它可與現有專業領域整合。(請參見「CMMI模式」及「CMMI產品系列」) CMMI模式 CMMI架構可產生可能模式的整個集合，CMMI模式為其中一個模式。因此依照各組織的需要，可由CMMI架構產生不同的模式，目前有許多CMMI模式。(請參見「CMMI架構」及「CMMI產品系列」) CMMI模式組件 任何組成CMMI模式的主要結構元件，一些CMMI模式的主要元件包括特定執行方法、一般執行方法、特定目標、一般目標、流程領域、能力度及成熟度。 詞彙 604
CMMI for Development Version CMMI產品系列 以CMMI觀念所發展的整套產品，這些產品包括架構本身、模式、評鑑方法、評鑑資料及各種訓練。(請參見「CMMI架構」及「CMMI模式」。) 流程變異的共同因流程各組件間彼此正常與預期的交互作用，原因 而存在的流程變異。(請參見「流程變異的特殊原因」。) 操作概念 (請參見「操作概念(operational concept)。」 建構稽核 執行稽核以驗證建構項目或一組建構項目建構基準符合特定的標準或需求。(請參見「稽核」、「建構項目」、「功能性建構稽核」及「實體性建構稽核」。) 建構基準 建構資訊是指產品或產品組件生命中某一特定時間的資訊，建構基準加上以這些基準為主所核可的變更，構成目前的建構基準。(請參見「產品生命週期」。) 建構管制 建構管理的元件包含評估、協調、核可或不核可，以及正式建立建構識別後對建構項目所做的變更。(請參見「建構識別」、「建構項目」及「建構管理」。) 建構管制委員會 負責評估及對建構項目提出之變更的核可或不核可，而且確保核可的變更均已執行的一組人。(請參見「建構項目」。)建構管制委員會又稱為「變更管制委員會」。 建構識別 建構管理的元件包含選擇產品的建構項目、指定唯一的識別，以及記錄其功能與實體的特性於技術文件。(請參見「建構項目」、「建構管理」及「產品」。) 建構項目 為了建構管理所指定的一組工作產品，在建構管理流程中視為單一實體。(請參見「建構管理」。) 詞彙 605
CMMI for Development Version 建構管理 應用技術與管理的引導與監督之專業訓練，來(1)界定與記錄建構項目功能與實體的特性、(2)控制這些特性的變更、(3)記錄與報告變更的處理與執行的狀態，以及(4)驗證符合特定的需求。(請參見「建構稽核」、「建構管制」、「建構識別」及「建構狀態紀錄」。) 建構狀態紀錄 建構管理的元件包含記錄與報告有效管理一個建構所需的資訊。這個資訊包括核可的建構識別清單、建構預期變更的狀態，以及核可變更的執行狀態。(請參見「建構識別」及「建構管理」。) 連續式表述 一種能力成熟模式架構，在每一特定的流程領域中，能力度提供處理流程改善的建議順序。(請參見「能力度」、「流程領域」及「階段式表述」。) 承包商 （請參見「供應商」。） 矯正措施 修復某種狀況、除去錯誤或調整狀態的行動或行為。 現成品 可向商業供應商購買的項目。(COTS 代表「commercial off the shelf」。) 客戶 負責驗收產品或授權付款的團體(可能是個人、專案或組織)。客戶是專案的外部單位(當IPPD使用整合團隊時，可能除外)，但未必是組織的外部單位。客戶可能是較高層的專案。客戶是關鍵人員的一部分。(請參見「關鍵人員」。) 大部分使用這個名詞時，意指上述定義。然而，有些情況“客戶”意含其他相關的關鍵人員。(請參見「客戶需求」。) 客戶需求 以客戶可接受的方式，誘導、整合及解決產品相關關鍵人員對需要、期望、限制及介面衝突。(請參見「客戶」。) 詞彙 606
CMMI for Development Version 資料 無論紀錄的形式與方法的紀錄資訊，包括技術資料、電腦軟體文件、財務資訊、管理資訊、事實、任何能夠溝通、儲存與處理的數量或數據 資料管理 在資料生命週期，對經營與技術資料規劃、獲取及提供管理之有規律的流程與系統，能與資料需求有一致性。 缺失密度 每單位產品的缺失數(如每千行程式碼的問題報告單數)。 已調適流程 一個已管理流程，此流程是根據組織的調適指引，從組織標準流程所調適而來；包含維護流程說明及對組織流程資產貢獻工作產品、度量與其他的流程改善資訊。(請參見「已管理流程」。) 衍生度量 兩個或多個基礎度量的數學函數所導出的資料。(請參見「基礎度量」。) 衍生需求 在客戶需求中並未明顯陳述的需求，但可(1)自上下文的需求推論（如應用的標準、法律、政策、一般執行方法及管理決策），或(2)自指定產品組件所需的需求推論。衍生需求亦可在分析與設計產品或系統的組件時產生。(請參見「產品需求」。) 設計審查 對設計之正式的、文件化的、完整的及有系統的檢驗，以評估設計需求與符合這些需求的設計能力，界定問題並提出解決方案。 發展 在CMMI產品系列中，不僅是發展的活動，還包括維護活動。受益於CMMI最佳執行方法的專案，可以專注於發展或維護，或者兩者並行。 發展計畫 用以指引、執行及控制一個或多個產品之設計與發展的計畫。(請參見「產品生命週期」及「專案計畫」。) 詞彙 607
CMMI for Development Version 專業領域 在CMMI 產品系列中，當選擇CMMI模式(如系統工程)時，可使用的知識體系(bodies of knowledge)。CMMI產品團隊未來也計劃將其他的知識體系整合到CMMI架構中。 文件 文件是資料的集合，不論其記錄媒體。文件通常具有永久性，而且可由人或機器來閱讀。所以，文件包括書面文件與電子文件。 企業集團 企業集團由多個公司所組成。公司可能由位於不同地點及擁有不同客戶的多個組織所組成。(請參見「組織」。) 允入準則 在可成功開始工作投入之前，必須出現的狀態。 對等的階段式 目標階段式由連續式表述所產生。使用目標階段式的結果可與階段式表述的成熟度比較。(請參見「能力度摘要」、「成熟度」、「目標摘要」及「目標階段式」。) 不論使用何種CMMI表述，此階段式允許於組織、企業及專案之間進行進度的標竿學習。組織可能執行某些CMMI模式的組件超越其對等的階段式部分組件。對等的階段式只是一個度量，以成熟度的立場說明一個組織相對於其他組織的成熟度。 建立並維護 在CMMI產品系列中，你將遇到目標與執行方法中常含有「建立並維護(establish and maintain)」字詞。這個字詞所包含的意義，不僅是建立並維護，它還有書面化與使用的涵義。舉例而言，「建立並維護組織政策，以規劃與執行組織的流程專注流程」的意思，不僅是整理過的政策，還必須有書面記載，並於整個組織中執行。 證據 (請參見「客觀證據」。) 高階主管人員 (請參見「資深管理人員」。) 允出準則 在可成功結束工作投入之前，必須出現的狀態。 詞彙 608
CMMI for Development Version 期望的CMMI組能解釋執行什麼可滿足一個必要之CMMI組件 件的CMMI組件。模式的使用者可明確的執行期望的組件，或執行與這些組件相同意義的替代執行方法。特定與一般執行方法皆是期望的CMMI組件。 調查結果 (請參見「評鑑調查結果」。) 正式評估流程 一種結構化的方法，依據已建立的準則評估備選解決方案，並決定推薦的方案，以解決議題。 架構 (請參見「CMMI架構」。) 功能分析 檢驗已定義的功能來界定完成該功能所需的所有子功能；界定功能的關係與介面(內部及外部)，並在功能架構中呈現；可自上層績效需求引導，並將這些需求指定給下層的子功能。(請參見「功能架構」。) 功能架構 功能的階層式安排，其內部及外部(聚集本身的外部)的功能介面、外部的實體介面、相關功能，以及績效需求及設計限制。 功能建構稽核 執行稽核以驗證建構項目的發展已滿足的完成，建構項目在功能或配置建構識別的績效與功能特性已達成，以及操作與支援文件已完成與滿意。(請參見「建構稽核」、「建構管理」及「實體建構稽核」。) 一般目標 必要的模式組件，說明制度化流程實施流程領域必須呈現的特性。(請參見「制度化」。) 一般執行方法 期望的模式組件，對達成相關的一般目標相當重要。與其一般目標相關連的一般執行方法，說明為達成一般目標結果的期望活動及貢獻流程領域相關流程的制度化。 一般執行方法的有助益的流程組件，出現在一般執行方法之詳細說明 後，提供一般執行方法如何應用到流程領域的指引。 詞彙 609
CMMI for Development Version 目標 必要的CMMI組件，可能是一般目標或特定目標。當在CMMI模式看到目標字詞時時常參考到模式組件(例如一般目標與特定目標)。(請參見「一般目標(goal)」、「目的(objective)」及「特定目標」。) 硬體工程 應用有系統化、有紀律的及數量化方法，將一組使用文件化的技術表示關鍵人員需要、期望與限制之需求，轉換為設計、實施及維護有形的產品。(請參見「軟體工程」及「系統工程」。) 在CMMI中，硬體工程代表所有的技術領域(例如：電子、機械)，轉換需求與構想為有形及可生產的產品。 高層管理 提供流程政策與整體性指導，並非提供日常流程監督與控制的人員。此種人員在組織中高於負責流程的中層管理人員。可能是(但不一定是) 資深管理人員。(請參見「資深管理人員」。) 不完整的流程 未執行或只執行部分的流程(又稱為能力度第0級)。該流程領域的一項或多項特定目標未達成。 助益的CMMI組可幫助模式使用者瞭解模式必要與期望組件的件 CMMI組件。這些組件包括範例、詳細解釋或其他有助益的資訊。細部執行方法、註解、參考資料、目標標題、執行方法標題、來源、典型的工作產品、強化及一般執行方法詳細說明等，都是助益的模式組件。 制度化 經營企業根深蒂固的方法，組織經常性的遵守，就像公司文化的一部分。 整合的產品與流產品發展的系統化方法，使相關的關鍵人員在程發展 產品生命週期中做到適時的合作，以更能符合客戶的需要。 詞彙 610
CMMI for Development Version 整合團隊 一組具備完整技能與專業知識的人員，能適時合作並承諾交付特定的工作產品。整合團隊成員對工作產品生命期各階段提供適當的技能與支持，並能共同負責交付指定的工作產品。整合團隊應包括來自組織、專業領域及功能的授權代表，他們對於工作產品的成功都有利害關係。 介面控制 建構管理中的流程，包括：(1)由一個或一個以上的組織所提的二個或多個建構項目，界定與其介面相關的所有功能與實體特性的流程，以及(2)在執行之前，確保對這些特性提出的變更，是經過評估與核可的流程。(請參見「建構項目」及「建構管理」。) 生命週期模式 將一個產品或專案的生命週期分成數個階段。已管理流程 已執行的流程依照政策規劃與執行；雇用有技能的人有足夠資源生產受管理的產出；納入相關的關鍵人員；有監督、控制與審查；以及評估遵循流程說明程度。(請參見「已執行的流程」)。 管理人員 在CMMI產品系列中，管理人員提供技術與管理的方向與控制給其責任區域內執行工作與活動的人員。管理人員傳統的功能包括：責任區域內規劃、組織、領導及管制工作。 成熟度等級 流程改善的程度，在一組事先定義的流程領域中，其所有的目標皆達成。(請參見「能力度」及「流程領域」。) 協議備忘錄 二個或多個團體之間瞭解或協議必須遵守的文件。(又稱為「備忘錄」。) 自然界限 流程的本質以流程績效的度量來表示，有時稱為「流程的聲音」。使用如管制圖、信賴區間與預測區間的技術，來決定變異是來自於共同原因(即流程是可預測的或「穩定的」)，或來自於某些可以且應找出並移除的特殊原因。 詞彙 611
CMMI for Development Version 非發展項目(NDI)採購或發展流程中，於使用之前即已發展完成的供應項目，該項目可能只需要較小的修改，以符合其目前期望的使用需求。 非技術需求 合約規定、承諾、條件及條文，將影響產品或服務如何獲得。例如：交付的產品、交付現成品(COTS)與非發展項目(NDIs)的資料權、交付日期及有允出準則的里程碑。其他的非技術需求包括訓練需求、場地需求及部署時程等。 目標 在 CMMI 產品系列中，「目標(goal)」一詞已有特定的用途，即使用於「一般目標」與「特定目標」中。所以，當模式中需要表達日常使用之「目標(goal)」的意義時，會以「目標(objective)」來表示。(請參見「目標(goal)」。) 客觀證據 如CMMI評鑑資料、文件或面談結果，用來當做模式執行方法的實施與制度化的指標。客觀證據的來源能包括工具、簡報文件及訪查。 客觀評估 依據準則審查活動與工作產品，將審查人員的主觀與偏見減至最小。由獨立的品質保證功能人員，針對需求、標準或程序所執行的稽核是客觀評估的範例。(請參見「稽核」。) 觀察 如同CMMI評鑑資料，「觀察」是一份書面的紀錄，用以表示評鑑組成員在評鑑資料蒐集活動中，對於所見所聞的瞭解。該書面紀錄可以用報告表的格式，也可以用其他的表格來記錄，只要可以保存資訊的內容即可。 操作概念 一個實體使用或操作方法的一般描述。(又可稱為「操作概念(concept of operations)」。) 操作劇本 想像之事件順序的描述，包括產品與其環境與使用者的相互作用，以及產品組件之間的相互作用。操作劇本用來評估系統的需求與設計，並驗證與確認系統。 詞彙 612
CMMI for Development Version 最佳化流程 根據瞭解流程變異的共同原因，而改善的量化管理流程。以漸進與創新的改善，最佳化流程專注於流程績效範圍的持續改善。(請參見「流程變異的共同原因」、「已調適流程」及「量化管理流程」。) 組織 一個行政管理結構由成員共同管理一個或多個專案。這些專案有共同的資深管理人員，並在相同的政策下運作。不過在CMMI模式中，「組織」也可以是只有一個人以執行某功能的小組織；如果在大組織中，這些功能可能由一組人執行。(請參見「企業集團」及「組織單位」。) 組織成熟度 組織明顯且一致地推展流程的程度，這些流程已文件化、已管理、已度量、已控制及持續改善。組織成熟度可由評鑑來度量。 組織政策 通常由資深管理人員所建立的指引原則，組織採納後將會影響並決定決策。 組織流程資產 流程的說明、實施及改善有關的成果(artifacts) (如政策、度量、流程說明及流程實行支援工具等。)，「流程資產」指出發展或取得這些成果的目的，在於滿足組織的經營目標。流程資產也代表組織的投資，並預期這些投資會提供目前及未來的經營價值。(請參見「流程資產館」。) 組織單位 組織中接受評鑑的部分。組織單位推展一個或多個流程，這些流程具有一致性的流程範圍，並在一致性的經營目標下執行。組織單位通常是較大組織的一部分，然而在小組織中，組織單位可能就是整個組織。 詞彙 613
CMMI for Development Version 組織經營目標 資深管理人員所發展的策略，用來確保組織永續存在及增強其獲利率、市場佔有率，以及其他影響組織成功的因素。(請參見「品質與流程績效的目標」及「量化目標」。) 當應用至系統工程的活動時，這樣的目標包括降低系統整合階段需求變更的次數、減少發展週期時間、增加發展的第一或第二階段錯誤發現的數目、減少客戶所報告的缺失數等等。 組織度量儲存庫 蒐集與提供流程與工作產品之度量資料的儲存庫，尤其是與組織標準流程相關的資料。儲存庫包含或參考實際的度量資料或其參照的資料，以及瞭解與估計度量資料所需的相關資訊。 組織流程資產館 用來儲存與使有用流程資產館。它使組織中定義、實施及管理流程的人員，可以取得這些有用的流程資產。這資訊庫包含流程相關文件，如政策、已調適流程、檢查表、學習心得的文件、樣板、標準、程序、計畫、及訓練教材等。 組織標準流程 組織中引導所有活動之流程的定義。這些流程說明涵蓋基本的流程元件(process elements)(及其相互的關係，如次序與介面)。而且這些基本的流程元件必須合併到整個組織的專案所執行的已調適流程中。標準流程使整個組織具有一致的發展活動與維護活動，也是長期之穩定性及改善的重要條件。(請參見「已調適流程」及「流程元件」。) 委外 (請參見「採購」。) 同仁審查 在工作產品發展期間，由工作同仁對工作產品所執行的審查，以界定須移除的缺失。在 CMMI 產品系列中，使用「同仁審查(peer review)」，而不使用「工作產品檢查(work product review)」。(請參見「工作產品」。) 績效參數 有效性的度量與其他的主要度量，用來指引與控制發展的進行。 詞彙 614
CMMI for Development Version 已執行的流程 完成整個必要工作以產生工作產品的流程。該流程領域的特定目標皆須符合要求。 實體建構稽核 執行稽核以驗證所建立的建構項目，符合技術文件的定義與說明。 (請參見「建構稽核」、「建構管理」及「功能建構稽核」。) 已規劃的流程 指包含說明與計畫之文件化的流程，說明與計畫應彼此協調，而且計畫應包括標準、需求、目標、資源及工作指派等。 政策 (請參見「組織政策」。) 流程 在CMMI產品系列中，活動可視作CMMI模式中執行方法的實施。這些活動可以對照到CMMI流程領域的一個或多個執行方法，以允許模式有用於流程改善及流程評鑑。(請參見「流程領域」，「子流程」及「流程元件」。) 在一般目標與一般執行方法的敘述與說明，「流程」字詞有特別的用法。「流程」如同使用再第二部份時，是指實施該流程領域的一個流程與許多流程。 流程行動計畫 通常是評鑑結果後的計畫，針對評鑑時發現的缺失，記錄如何實施改善。 流程執行團隊 記錄於流程行動計畫中，負責發展及執行組織流程改善活動的團隊。 流程與技術改善 對流程或產品技術漸進與創新的改善。 流程架構 標準流程中，流程元件間的次序、介面、相互依賴，以及流程元件間的其他關係。流程架構也說明流程元件與外部流程(例如：合約管理)間的介面、相互依賴及其他關係。 流程領域 一組同屬某領域及相關的執行方法，當共同執行時，可以達成一組目標，而這些目標對該領域的重大改善是重要的。對連續式表述與階段式表述所有的CMMI流程領域而言，都是共通的。 詞彙 615
CMMI for Development Version 流程資產 組織認為達到某流程領域目標有用的任何事物。(請參見「組織流程資產」。) 流程資產館 流程資產的蒐集，可用於組織或專案。(請參見「組織流程資產館」。) 流程屬性 流程能力的可度量特性，可適應用於任何流程。 流程能力 遵循一個流程可達到之預期結果的範圍。 流程定義 定義與描述流程的行動。流程定義的結果為流程說明。(請參見「流程說明」。) 流程說明 以文件化的表達方式，表示執行一組活動以完成某特定的目的，該文件提供流程主要組件的操作定義。這文件以完整、明確及可驗證的方式，指定流程的需求、設計、行為或其他的特性。它可能也包括決定這些規定是否符合的程序。流程說明可見於活動、專案或組織層級。 流程元件 流程的基本單位。以子流程或流程元件的方式定義流程，子流程可以繼續分解成其他的子流程與/或流程元件，但流程元件則不能繼續分解。 每一個流程元件包含一組關係密切的活動(例如：估計元件、同仁審查元件)。可使用待完成的樣版、待調修的摘要，或待修正或使用的說明，來描述流程元件。流程元件可以是一項活動或工作。 流程組 協助定義、維護及改善組織所使用之流程的專家群。 流程改善 用來改善組織流程績效與成熟度的行動計畫，以及該計畫的成果。 詞彙 616
CMMI for Development Version 流程改善目標 採用可度量方式所建立一組目標特性，用以改善現有流程的指引。度量方式可以是產品結果的特性(例如：品質、績效、標準的符合程度等)，或是流程執行的方式(例如：除去多餘的流程步驟、合併流程步驟、改善週期時間等)。(請參見「組織經營目標」及「量化目標」。) 流程改善計畫 基於充分瞭解現在組織流程與資產的優點與缺點，為達成組織流程改善的目標的計畫。 流程度量 用來度量流程及其產品的定義、方法與活動，其目的是瞭解該流程及記述其特徵。 流程負責人 負責定義與維護流程的個人(或團隊)。在組織層級，流程負責人是負責描述標準流程的個人(或團隊)。在專案層級，流程負責人是負責描述已調適流程的個人(或團隊)。因此在不同層級責任中，一個流程可能有多個流程負責人。(請參見「已調適流程」及「標準流程」。) 流程績效 遵循一個流程所達成實際結果的度量。是由流程度量(如工作量、週期時間及缺失移除的效率)與產品度量(如可靠度、缺失密度及反應時間)所描述。 流程績效基準 遵循一個流程所達成實際結果的特性紀錄，用來作為比較實際流程績效與預期流程績效的標竿。(請參見「流程績效」。) 流程績效模式 描述流程與其工作產品的屬性間的關係，它們自歷史的流程績效資料發展而來，並使用專案所蒐集的流程與產品度量加以調校，以及來預測後續流程達成的結果。 流程調適 為了某特定目的而製作、修改或改編流程說明。例如：專案自組織標準流程調適其已調適流程，以符合專案的目標、限制及環境。(請參見「已調適流程」、「組織標準流程」及「流程說明」。) 詞彙 617
CMMI for Development Version 產品 在CMMI產品系列中，產品是指預定交付給客戶或最終使用者的工作產品。產品的形式依不同的情況而異。(請參見「客戶」、「產品組件」、「服務」及「工作產品」。) 產品基準 建構管理中已核可的初始技術資料包(包括軟體、原始碼清單)，在其生命週期的生產、操作、維護及後勤支援中定義建構項目。(請參見「建構項目」及「建構管理」。) 產品組件 在CMMI 模式中，產品組件通常指產品中較低階的工作產品，產品組件經由整合以組合成產品，產品組件可以有許多層次。(請參見「產品」及「工作產品」)。 產品組件需求 產品組件的完整規格，包含適合、表格、功能、績效及其他需求。 產品生命週期 從產品的構想開始，到產品不再使用的期間，通常分幾個階段。組織可能同時為多個客戶生產多個產品，單一產品生命週期的描述可能不足。所以組織可以定義一組經驗證的產品生命週期模式。這些模式通常可以從公開的刊物上尋得，但多半須調適才能適用於組織。 產品生命週期可包含下列的階段：(1)概念/願景；(2)可行性研究；(3)設計/發展；(4)生產；(5)廢除。 產品線 擁有共同的及已管理特性的一系列產品，可滿足某一部分市場或任務的特定需要。 產品相關的生命與產品生命週期一個或多個階段相關的流程週期流程 (例如：從概念設計到產品汰除)，例如：製造與支援流程。 產品需求 將客戶的需求調修成發展者的語言，將隱含的需求變成明確的衍生需求。(請參見「衍生需求」及「產品組件需求」。) 發展者使用產品需求來指引設計與產品的製作。 產品系列 (請參見「CMMI產品系列」。) 詞彙 618
CMMI for Development Version 摘要 (請參見「達成摘要」與「目標摘要」。) 計畫 (1)一個專案。(2)一組相關的專案及支援它們的基礎架構，包括目標、方法、活動、計畫及成功的度量。(請參見「專案」。) 專案 在CMMI 模式中，一組受管理的相關資源，以便交付一項或多項產品給客戶或最終使用者。專案有明確的開始點(例如專案啟動)及依據計畫執行。這個計畫大多以文件記載，並說明將交付與實作的產品、所使用的資源與經費、工作項目及工作時程表。一個專案也可以由多個專案組成。(請參見「專案啟動」。) 專案管理人員 在CMMI產品系列中，負責規畫、督導、控制、組織及推動專案的人。專案管理人員負責滿足客戶的需求。 專案計畫 計畫提供執行與控制專案活動的基礎，以處理對專案客戶的承諾。 專案規劃包括估計工作產品與工作項目的屬性、決定所需的資源、協商、承諾、產生時程，以及界定與分析專案風險，有時需要重覆些活動足以建立專案計畫。 專案進度與績效 專案根據執行專案計畫所達成者，包括工作量、成本、時程及技術績效。 專案啟動 當一組相關的資源被指示去發展或交付一個或多個產品給客戶或最終使用者。(請參見「專案」。) 專案已調適流程 由組織標準流程調適而得的已整合與定義的流程。(請參見「已調適流程」。) 詞彙 619
CMMI for Development Version 雛型 產品或產品組件的初步類型、形式或實例，可作為後續階段或最終完成產品的模型。這個模型(實體的、電子的、數位的、分析的等)可用於下列(及其他)目的： • 評量新的或不熟悉技術的可行性。 • 評量或降低技術風險。 • 確認需求。 • 展示重要的特性。 • 證明產品合格。 • 證明流程合格。 • 描述績效或產品的特性。 • 說明物理的原理 品質 產品、產品組件或流程本身特性的能力，以滿足客戶需求。 品質與流程績效產品品質、服務品質、與流程績效的目標與需的目標 求。流程績效目標包括品質；然而，在CMMI產品系列中為了強調品質的重要性，所以使用品質與績效目標字詞而不是流程績效目標。 品質保證 保證管理以有計劃的與系統化的方法，引用已定義的流程標準、執行方法、程序及方法。 品質管制 用於滿足品質需求的操作技術與活動。(請參見「品質保證」。) 量化目標 以量化的度量表示期望的目標值。(請參見「流程改善目標」及「品質與流程績效的目標」。) 量化管理流程 已經以統計及其他量化技術來控制的已調適流程，在整個專案過程中，產品品質、服務品質及流程績效的屬性是可度量與控制的。(請參見「已調適流程」、「最佳化流程」及「統計化管理的流程」。) 評等 (請參見「評鑑評等」。) 詞彙 620
CMMI for Development Version 參考資料 助益的模式組件，它指引在相關的流程領域中更多詳細的資訊。 參考模式 當作度量某些屬性之標竿的模型。 相關的關鍵人員 界定參與某特定活動與納入計畫的關鍵人員。 (請參見「關鍵人員」) 表述 CMM組件的組織、使用及展示。總體而言，顯然有兩種方法表示最佳執行方法：階段式表述與連續式表述。 必要的CMMI組在流程領域中，要達成流程改善的必要CMMI件 組件，這些組件在評鑑中用以決定流程的能力。特定目標與一般目標是必要的模式組件。需求 (1)使用者解決問題或達成目標所需的條件或能力。(2)產品或產品組件必須符合或擁有的條件或能力，以滿足合約、標準、規格或其他正式提出的文件。(3)記錄(1)或(2)所述之條件或能力的文件。 需求分析 以客戶需要、期望及限制的分析；操作觀念；人員、產品及流程的預期使用環境；以及度量的有效性為基礎，來決定產品特定的績效與功能的特徵。 需求誘導 使用有系統的技術，例如雛型與結構化調查，以主動界定與記錄客戶與使用者的需要。 需求管理 管理專案收到或產生的所有需求，包括技術與非技術的需求，以及組織對專案的需求。 需求追溯 需求與相關需求、實施及驗證間可識別的關連。(請參見「雙向追溯性」及「追溯性」。) 投資報酬率 輸出(產品)相對於生產成本的收益比，用以決定組織是否由產生產品的執行行動中獲得利益。 風險分析 風險的評估、分類及設定優先順序 風險界定 有組織且完整的方法，以尋找達成目標時可能的或實際的風險。 詞彙 621
CMMI for Development Version 風險管理 一個有組織、分析式的流程，用以界定可能造成傷害或損失的來源(界定風險)；評量及量化已界定的風險；以及發展並於必要時執行適當的方法，來避免或處理可能造成巨大傷害或損失的風險原因。 風險管理策略 一個有組織、技術的方法，用以界定可能造成傷害或損失的原因(界定風險)；評量及量化已界定的風險；以及發展與並於必要時執行適當的方法，來避免或處理可能造成巨大傷害或損失的風險原因。通常風險管理是為專案、組織或發展產品的組織單位而實行。 根本的原因 缺失的源頭，一旦去除，缺失會減少或清除。 資深管理人員 在CMMI 模式中，一個組織中，層次夠高的管理角色。資深管理人員主要專注於組織永續的經營，而不是短期的專案及合約的顧慮與壓力。資深管理人員有權分配或重分配資源，以支持組織流程改善的有效性。(請參見「高層管理」。) 符合以上條件的管理人員都可以是資深管理人員，包括組織負責人。資深管理人員的同義詞有「執行長(executive)」與「高層主管(top-level manager)」，但為了確保模式的一致性及實用性，CMMI模式裡並不使用這兩個同義詞。 服務 在CMMI產品系列中、服務是無形與不可儲存的產品。(請參見「產品」、「客戶」、「工作產品」及「服務」。) 共同願景 一種指導原則的共識，包括任務、目標、期望的行為、價值及最終結果。共同願景由專案所發展與使用。 軟體工程 (1)應用系統化、有紀律的及量化的方法，來發展、操作及維護軟體。(2)關於第(1)項方法的研究。(請參見「硬體工程」及「系統工程」。) 招標 準備招標文件及選擇供應商(承包商)的流程。 詞彙 622
CMMI for Development Version 流程變異的特殊缺失的原因是特有的某些瞬間情況，而不是流原因 程本身所造成。(請參見「流程變異的共同原因」。) 特定目標 必要的模式組件說明必須要呈現以滿足該流程領域的獨特屬性。(請參考「能力度」、「一般目標」、「組織經營目標」及「流程領域」。) 特定執行方法 對達成相關的特定目標是重要的期望類模式組件。特定執行方法說明一組活動，這組活動被期望可達成某流程領域的特定目標。 (請參見「流程領域」及「特定目標」。) 穩定流程 當所有流程變異的特殊原因皆已移除，且避免再發生，以致只留下流程變異的共同原因。(請參見「有能力的流程」、「流程變異的共同原因」、「標準流程」、「流程變異的特殊原因」及「統計化管理的流程」。) 階段式表述 一種模式架構，當達到一組流程領域的所有目標，則建立了一成熟度等級；每一等級是後續等級的基礎。(請參見「成熟度」及「流程領域」。) 關鍵人員 在CMMI產品系列中，承擔計畫執行結果或受計畫影響的個人或團體，關鍵人員可能包括專案成員、供應商、客戶、最終使用者及其他。(請參見「客戶」及「相關的關鍵人員」。) 標準 在CMMI 模式中，當名詞使用的「標準(standard)」是指一個正式且具強制性的需求，這些需求被發展及用來規定具有一致性的發展方法 (例如：ISO/IEC標準、IEEE標準、組織的標準)。我們使用與「標準」有相同意義的其他術語來代表一般日常意義的「標準」(例如：典型的、傳統的、通常的或慣例)。 詞彙 623
CMMI for Development Version 標準流程 基本流程的操作定義，用來指導組織共用流程的建立。 標準流程描述基本的流程元件，期望這些流程元件可包含在任何已調適流程中，它也描述這些流程元件之間的關係(如順序與介面)。(請參見「已調適流程」。) 工作說明書 完成專案所需之協議工作的說明。 統計的可預期度 量化流程的績效，可由統計及其他量化的技術所控制。 統計流程管制 以統計的方法分析流程與度量流程的績效，可界定流程績效，變異的共同與特殊原因，並將流程績效維持在某一範圍內。(請參見「流程變異的共同原因」、「流程變異的特殊原因」及「統計化管理的流程」。) 統計技術 應用統計方法的分析技術(例如：統計流程管制、信賴區間及預測區間)。 統計化管理的流已以統計技術管理的流程，此流程已被分析、程 界定流程變異的特殊原因，且績效維持在明確界定的範圍內。(請參見「有能力的流程」、「流程變異的特殊原因」、「穩定流程」、「標準流程」及「統計流程管制」。) 細部執行方法 提供指引詮釋與執行特定或一般執行方法，為助益的模式組件。細部執行方法以規範式的文字描述，僅提供可用於流程改善的意見而不具強制性。 子流程 較大流程的部分流程。子流程能再細分為子流程及/或流程元件。(請參見「流程」、「流程說明」及「流程元件」。) 供應商 (1)一個可交付購買產品或提供服務的實體。(2)個人、合夥、公司、法人、協會或其他的服務機構，與採購者有協議(合約)，在協議(合約)的條款下進行設計、發展、製造、維護、修訂或供應商品。 詞彙 624
CMMI for Development Version 維持 確保產品可供最終使用者與客戶操作的流程。「維持」確保已完成維護，不論客戶或最終使用者是否正使用該產品，產品皆在可操作的狀況下。 系統工程 橫跨不同專業領域，管控整個技術與管理投入之方法，用來將客戶的需要、期望及限制，轉換成為產品的解決方案，並在產品生命週期內支援該解決方案。(請參見「硬體工程」及「軟體工程」) 包括技術的績效度量定義，整合工程的特性來建立產品的架構，以及支援生命週期流程的定義，用來平衡成本、績效及時程的目標。 調適 調適流程為了特定目的，製作、改變或調整流程說明。舉例而言，某專案經由調適組織標準流程，來建立一套已調適流程，以符合專案的目標、限制及環境。 調適指引 組織指引，能讓專案、團隊及組織功能經由適當的調適標準流程，以符合他們的使用。在CMMI模式中，組織標準流程只是一般性的說明，不見得可直接用來執行流程。 調適指引可輔助為專案建立已調適流程的人。調適指引的內容涵蓋：(1)選擇一標準流程，(2)選擇一經驗證的生命週期模式，以及(3) 調適所選擇的標準流程及生命週期模式，以符合專案的需要。調適指引說明調適時哪些內容是否可修改，並界定哪些流程組件是可修改的對象。 目標摘要 在連續式表述中，一組流程領域與其相關的能力度，可表示流程改善的目標。(請參見「達成摘要」及「能力度摘要」。) 目標階段式 在連續式表述中，用來描述流程改善途徑，以供組織遵循的一系列目標摘要。(請參見「達成摘要」、「能力度摘要」及「目標摘要」。) 詞彙 625
CMMI for Development Version 技術相關資料 如果下列資訊適合產品與產品組件的類型(例如：原料與製造需求可能不適用於軟體服務與流程的產品組件)，技術資料包可包括下列各項： • 產品架構說明 • 配置的需求 • 產品組件說明 • 產品相關的生命週期流程說明，如果不是以個別產品組件來說明時 • 主要的產品特性 • 必要的實體特性與限制 • 介面需求 • 原料需求(原料需求表及原料特性) • 生產與製造需求(對原始設備製造商與現場支援)） • 確保需求已達成的驗證準則。 • 整個產品生命週期中，操作、支援、訓練、製造、汰除與驗證的使用(環境)條件與操作/使用劇本、模式與狀態。 • 決策與特性的理由說明(需求、需求配置、設計選擇) 詞彙 626
CMMI for Development Version 技術需求 欲採購或發展的產品或服務的內容(屬性)。 測試程序 為某特定測試的準備、執行及結果評估的詳細說明。 追溯性 兩個或更多個邏輯實體(如需求、系統元件、驗證或工作項目)間可辨識的關聯。 (請參見「雙向追溯性」及「需求追溯性」。) 替代方案研究 根據準則與系統化分析，評估各個方案，以選擇能達成目標的最佳方案。 訓練 正式與非正式學習選項，可包括課堂訓練、非正式指導：上網訓練、自我引導學習及正式工作中訓練計畫。對每一情況的學習是基於選擇訓練需要的評量及欲解決的績效落差。 典型的工作產品 提供某特定執行方法的產出範例之助益的模式組件。這些範例之所以稱為典型的工作產品，是因為除了這些具代表性的範例之外，還有其他的工作產品也是有助益的，但未被列出。 元件測試 個別的硬體或軟體單元或一組相關單元的測試。(請參見「驗收測試」。) 確認 證實所提供的產品(或即將提供的產品)，符合其預期的使用需求。換句話說，「確認」確保「你做了正確的事」(請參見「驗證」。) 驗證 證實工作產品是否適當的反映其指定的需求。換句話說，驗證確保「你做對了」。(請參見「確認」。) 版本管制 建立與維護基準及界定基準的變異，使還原至前一個基準成為可能。 分工結構圖 工作項目的安排、其彼此之間的關係，以及與最終產品之間的關係。 詞彙 627
CMMI for Development Version 工作產品 在CMMI產品系列中，一個流程所產出的有用結果。工作產品包括檔案、文件、產品、產品組件、服務、流程說明、規格及出貨單。工作產品與產品組件的主要差異，在於工作產品不必要是產品的一部分。(請參見「產品」及「產品組件」。) 在CMMI 模式中，許多地方使用了工作產品及服務字詞。雖然工作產品的定義已包含服務，但在討論中，使用這個字詞強調工作產品包括了服務。 工作產品與工作產品、服務及專案工作的特性，可協助估計專項目屬性 案的工作量。這些特性的項目包括如：規模大小、複雜度、權重、表格、安裝與功能。它們通常作為輸入以推得其他的專案及資源的估計值(如工作量、成本、時程)。 詞彙 628
