【第161期 January 31, 2011】


CMMI DEV v1.3 的改變




SEI (Software Engineering Institue) 於2010年10月底公告CMMI V1.3,最新公告的CMMI DEV V1.3版本是在原有基礎上增加了許多可以提升組織或企業能力的元素。此次V1.3版本的升級包含了三個模型CMMI-Development (開發模型)、CMMI-Acquisition (採購模型)和CMMI-Services (服務模型)的改進,同時它也包含了對SCAMPI (Standard CMMI Appraisal Method for Process Improvement)評估方式。不過這個改進並不會對CMMI的三個主要模型進行太大的變動,所以企業並不需要重新培訓而造成原有培訓資源的浪費。本文分述於下。

CMMI - DEV的V1.3重大改進

  • 高成熟( High Maturity)流程領域有顯著改善,不再有組織創新與推展(OID), 改為組織績效管理(OPM)。以反映行業最佳做法,包括一個新的具體目標(SG) 和具體做法在一些新領域的過程(SP) 。

  • 改進了該模型的體系結構,簡化了使用多個模型。“Informative”進行了改進,包括修改工程的做法,以反映行業的最佳實踐和指導,為企業增加使用敏捷方法(Agile methods)。

  • 術語的定義(Glossary definitions) and和術語模型(model terminology)進行了改進,以提高清晰度、準確性和可用性模型。

  • ML 4級和ML 5的通用目標( GG)和做法(GP)被取消,集中在高成熟度實現組織目標,這些通用的目標是通過運用能力水平高1-3成熟過程域。

非高成熟度CMMI DEV v1.3 流程領域的改變


一、Supplier Agreement Management SAM (供應商協議管理)

  • 增加:

    SP1.3 Establish and maintain supplier agreement 建立並維護與供應商間的正式協議。

  • 刪除:

    SP2.4 Accept the Acquired Product 接受取得的產品-在接受取得的產品前,確保其已滿足供應商協議。
    SP2.5 Transition Products 移交產品-移交從供應商取得的產品予專案。

二、Organizational Process Definition OPD 組織流程定義

  • 增加:

    SP 1.7 Establish and maintain organizational rules and guidelines for the structure, formation, and operation of teams.建立與維護組織的規範與指引

  • 刪除:

    SG 2 Enable IPPD Management (IPPD Addition)
    SP 2.1 Establish Empowerment Mechanisms建立授權機制
    SP 2.2 Establish Rules and Guidelines for Integrated Teams為整合團隊建立規則及指引
    SP 2.3 Balance Team and Home Organization Responsibilities平衡團隊及原屬組織的權責

三、Integrated Project Management IPM 整合的專案管理

  • 增加:

    SP 1.6 Establish and maintain teams.建立與維護團隊

  • 刪除:

    SG3 Apply IPPD Principles (IPPD Addition) 使用IPPD 原則
    SP3.1 Establish the Project’s Shared Vision建立專案的共同願景-建立並維專案的共同願景。
    SP 3.3 Allocate Requirements to Integrated Teams分配需求給整合團隊
    SP 3.4 Establish Integrated Teams建立整合團隊
    SP 3.5 Ensure Collaboration among Interfacing Teams確保互動團隊間的合作

CMMI DEV v1.3 對敏捷(Agile )的解讀

這次 CMMI v1.3 的重大改變之一是把 敏捷Agile 放進來並加以註解,這些註解均以 “In Agile environments (在Agile環境中)“為開頭,並列於範例框中如”.. “.. that these notes are examples of how to interpret practices and therefore are neither necessary nor sufficient for implementing the process area…,這些註解乃是如何解讀常規的範例,因此,它們對於流程領域既不需要也不充分 “。以下是筆者就CM 及PP 的流程領域註解 Agile 的解讀:


In Agile environments, configuration management (CM) is important because of the need to support frequent change, frequent builds (typically daily), multiple baselines, and multiple CM supported workspaces (e.g., for individuals, teams, and even for pair-programming). Agile teams may get bogged down if the organization doesn’t: 1) automate CM (e.g., build scripts, status accounting, integrity checking) and 2) implement CM as a single set of standard services. At its start, an Agile team should identify the individual who will be responsible to ensure CM is implemented correctly. At the start of each iteration, CM support needs are re-confirmed. CM is carefully integrated into the rhythms of each team with a focus on minimizing team distraction to get the job done. (See ─Interpreting CMMI When Using Agile Approaches∥ in Part I.)

在Agile環境中,由於要支援經常性變更、經常性構築通常是(每日)、多個基準、以及多重CM支援的不同工作區域(例如,對個人、團隊、甚至是成對程式編寫),建構管理(CM)是重要。如果組織做不到下列各項,則Agile團隊可能陷入泥沼:1) 自動化CM (例如,構築腳本(build scripts)、狀態記述、完整性檢查)2)將CM當成組織標準。在啟動的時候,Agile團隊應確認負責CM正確實施。要再次確定。CM以最小化團隊的分心,使工作完成為重點,謹慎地整合到每一個團隊的節奏中。(參閱Part I中“於運用捷式作法時,解讀CMMI。”)


For product lines, there are multiple sets of work activities that would benefit from the practices of this process area. These work activities include the creation and maintenance of the core assets, developing products to be built using the core assets, and orchestrating the overall product line effort to support and coordinate the operations of the inter-related work groups and their activities. In Agile environments, performing incremental development involves planning, monitoring, controlling, and re-planning more frequently than in more traditional development environments. While a high-level plan for the overall project or work effort is typically established, teams will estimate, plan, and carry out the actual work an increment or iteration at a time. Teams typically do not forecast beyond what is known about the project or iteration, except for anticipating risks, major events, and large-scale influences and constraints. Estimates reflect iteration and team specific factors that influence the time, effort, resources, and risks to accomplish the iteration. Teams plan, monitor, and adjust plans during each iteration as often as it takes (e.g., daily). Commitments to plans are demonstrated when tasks are assigned and accepted during iteration planning, user stories are elaborated or estimated, and iterations are populated with tasks from a maintained backlog of work. (See ─Interpreting CMMI When Using Agile Approaches∥ in Part I.)

對於產品線,多種的工作項目活動,能自本流程領域的常規中獲益。這些工作活動包括核心資產的產生與維護、將以該核心資產構築之產品的發展、以及調和整體的產品線努力,以支援與協調交互關聯之工作群組及其活動的運作。在Agile環境中,漸進式發展的履行,較傳統之發展環境中,更為頻繁實施的規劃、監視、控制、與重新規劃。雖然整體專案或工作投入的高階規畫通常都會建立,但是團隊還是要估算、規劃、並以一次一個漸進實行工作。團隊通常不對專案或漸進式未知的部分做預測,除了預判的風險、重大事件、以及大規模的影響與限制條件。估算值反映出影響完成該漸進式之時間、投入、資源、以及風險之漸進式與團隊特定的因素。於每一漸進式期間,經常性地實施(例如,每日)團隊規劃、監視、以及調整計畫。對於計畫的承諾,會在每個漸進式規劃期間,工作指派與接受、使用者故事情節細述或估算、以及工作從受到維護之工作積存中,移至漸進式等時候展現出來。(參閱Part I中“於運用捷式作法時,解讀CMMI。”)

Agile部份除了上述的 CM, PP兩個流程領域, SEI另選定 PMC, REQM, PPQA,RD, TS, PI, VER, VAL 加入了 Agile 註解。 由上述 CM 及PP 對 Agile的解讀在 CMMI 的實作並不夠直覺,因此SEI 應該是順應潮流加入 。因此要從CMMI的角度來看,而不是Agile的角度來看。


CMMI V1.3 高成熟度的證據材料是早期的V1.2a版本的焦點成果,不過它只是高成熟度概念小組為了完成V1.3版本模型開發的改進要求所總結的一小部分。他們也制定了同樣的計劃改進模型中的高成熟度的架構的定義。 但本文只探討CMMI v1.3 DEV在 ML 2及 ML3 的改變,因為依據軟體資訊協會 CISA 2010 的統計,台灣通過CMMI ML2有 81 家,通過ML3 48家及通過ML4有 3家, 希望本文提供給多數正要導入的公司或再評鑑的公司了解 CMMI DEV v1.3 的改變。


CMMIR for Development, Version 1.3