プロセス領域 (CMMI)

能力成熟度モデル統合( CMMI )では、プロセス領域を「ある領域における関連するプラクティスの集合体であり、まとめて実装すると、その領域の改善に重要だと考えられる一連の目標を満たすもの」と定義しています。CMMI for Development v1.3 と CMMI for Acquisition v1.3 はどちらも 22 のプロセス領域を特定し、CMMI for Services v1.3 は 24 のプロセス領域を特定しています。これらの 3 つのモデルでは、多くのプロセス領域が同じです。

CMMI モデルでは、プロセス領域は頭字語に従ってアルファベット順に整理されます。ただし、プロセス領域は成熟度レベルまたはプロセス領域のカテゴリに従ってグループ化できます。

成熟度レベルは 5 つあります。ただし、成熟度レベルの評価はレベル 2 から 5 に対して与えられます。以下のプロセス領域とその成熟度レベルは、開発用 CMMI モデルにリストされています。

成熟度レベル 2 - 管理

• CM - 構成管理
• MA - 測定と分析
• PMC - プロジェクトの監視と制御
• PP - プロジェクト計画
• PPQA - プロセスおよび製品品質保証
• REQM - 要件管理
• SAM - サプライヤー契約管理

成熟度レベル 3 - 定義

• DAR - 意思決定分析と解決
• IPM - 統合プロジェクト管理
• OPD - 組織プロセス定義
• OPF - 組織プロセスフォーカス
• OT - 組織研修
• PI - 製品統合
• RD - 要件開発
• RSKM - リスク管理
• TS - テクニカルソリューション
• VAL - 検証
• VER - 検証

成熟度レベル4 - 定量的に管理

• OPP - 組織プロセスパフォーマンス
• QPM - 定量的プロジェクト管理

成熟度レベル5 - 最適化

• CAR - 原因分析と解決
• OPM - 組織パフォーマンス管理

CMMI for Services モデルには、以下のプロセス領域とその成熟度レベルがリストされています。

成熟度レベル 2 - 管理

• CM - 構成管理
• MA - 測定と分析
• PPQA - プロセスおよび製品品質保証
• REQM - 要件管理
• SAM - サプライヤー契約管理
• SD - サービス提供
• WMC - 作業監視と制御
• WP - 作業計画

成熟度レベル 3 - 定義済み(これには、以前のレベルを構成するプロセス領域が含まれます。成熟度レベル 3 は、レベル 2 とレベル 3 のプロセス領域で構成されます)

• CAM - 容量と可用性の管理
• DAR - 意思決定分析と解決
• IRP - インシデントの解決と予防
• IWM - 統合作業管理
• OPD - 組織プロセス定義
• OPF - 組織プロセスフォーカス
• OT - 組織研修
• RSKM - リスク管理
• SCON - サービス継続性
• SSD - サービスシステム開発
• SST - サービスシステムの移行
• STSM - 戦略的サービス管理

成熟度レベル4 - 定量的に管理

• OPP - 組織プロセスパフォーマンス
• QPM - 定量的作業管理

成熟度レベル5 - 最適化

• CAR - 原因分析と解決
• OPM - 組織パフォーマンス管理

CMMI for Acquisition モデルでは、以下のプロセス領域とその成熟度レベルがリストされています。

成熟度レベル 2 - 管理

• AM - 契約管理
• ARD - 調達要件の開発
• CM - 構成管理
• MA - 測定と分析
• PMC - プロジェクトの監視と制御
• PP - プロジェクト計画
• PPQA - プロセスおよび製品品質保証
• REQM - 要件管理
• SSAD - 入札およびサプライヤー契約の開発

成熟度レベル 3 - 定義

• ATM - 買収技術管理
• AVAL - 買収検証
• AVER - 取得検証
• DAR - 意思決定分析と解決
• IPM - 統合プロジェクト管理
• OPD - 組織プロセス定義
• OPF - 組織プロセスフォーカス
• OT - 組織研修
• RSKM - リスク管理。

成熟度レベル4 - 定量的に管理

• OPP - 組織プロセスパフォーマンス
• QPM - 定量的プロジェクト管理

成熟度レベル5 - 最適化

• CAR - カジュアル分析と解決
• OPM - 組織パフォーマンス管理

目標と実践には、一般的な目標と具体的な目標の 2 つのカテゴリがあります。具体的な目標と実践は、プロセス領域に固有のものです。一般的な目標と実践は、すべてのプロセス領域の一部です。プロセス領域は、組織のプロセスがそのプロセス領域の一般的な目標と実践、具体的な目標と実践をすべてカバーしている場合に満たされます。

一般的な目標と実践は、あらゆるプロセス領域の一部です。

• GG 1 具体的な目標を達成する
  • GP 1.1 特定のプラクティスを実行する
• GG 2 管理されたプロセスを制度化する
  • GP 2.1 組織ポリシーを確立する
  • GP 2.2 プロセスを計画する
  • GP 2.3 リソースの提供
  • GP 2.4 責任の割り当て
  • GP 2.5 人材育成
  • GP 2.6 作業成果物の管理
  • GP 2.7 関連する利害関係者を特定し関与させる
  • GP 2.8 プロセスの監視と制御
  • GP 2.9 遵守状況を客観的に評価する
  • GP 2.10 上位レベルの管理者によるステータスの確認
• GG 3 定義されたプロセスを制度化する
  • GP 3.1 定義されたプロセスを確立する
  • GP 3.2 プロセス関連の経験の収集

各プロセス領域は、一連の目標と実践によって定義されます。これらの目標と実践は、そのプロセス領域にのみ表示されます。

CMMI for Development バージョン 1.2 には、組織プロセスでカバーされる製品およびサービス開発の側面を示す 22 のプロセス領域が含まれています。各モデルのプロセス領域の概要については、SEI Web サイトで入手できる次のクイック リファレンス ドキュメントを参照してください。

• 調達のためのCMMI [1]
• 開発のためのCMMI [2]
• サービスのためのCMMI [3]

• 成熟度レベル2のプロジェクト管理プロセス領域

目的

契約管理(AM)の目的は、サプライヤーと買収者がサプライヤー契約の条件に従って業務を遂行することを保証することです。

目標別の具体的な実践

• SG 1 サプライヤー契約の遵守
  • SP 1.1 サプライヤー契約の締結
  • SP 1.2 選択したサプライヤーのプロセスを監視する
  • SP 1.3 取得した製品の受け入れ
  • SP 1.4 仕入先請求書の管理

• 成熟度レベル3のサポートプロセス領域

目的

容量および可用性管理(CAM)の目的は、効果的なサービス システム パフォーマンスを確保し、サービス要件をサポートするためにリソースが効果的に提供され、使用されるようにすることです。

目標別の具体的な実践

• SG 1 容量と可用性の管理の準備
  • SP 1.1 容量と可用性の管理戦略を確立する
  • SP 1.2 測定基準と分析手法の選択
  • SP 1.3 サービスシステム表現を確立する
• SG 2 容量と可用性の監視と分析
  • SP 2.1 容量の監視と分析
  • SP 2.2 可用性の監視と分析
  • SP 2.3 容量と可用性の管理データのレポート

• 成熟度レベル5のサポートプロセス領域

目的

原因分析と解決(CAR)の目的は、選択された結果の原因を特定し、プロセスのパフォーマンスを改善するための措置を講じることです。

目標別の具体的な実践

• SG 1 選択された結果の原因を特定する
  • SP 1.1 分析結果の選択
  • SP 1.2 原因の分析
• SG 2 選択された結果の原因に対処する
  • SP 2.1 アクション提案の実施
  • SP 2.2 実施されたアクションの効果を評価する
  • SP 2.3 因果分析データを記録する

• 成熟度レベル2のサポートプロセス領域

目的

構成管理(CM)の目的は、構成の識別、構成の制御、構成ステータスの記録、および構成の監査を使用して、作業成果物の整合性を確立し、維持することです。

目標別の具体的な実践

• SG 1 ベースラインを確立する
  • SP 1.1 構成項目の特定
  • SP 1.2 構成管理システムの確立
  • SP 1.3 ベースラインの作成またはリリース
• SG 2 トラックとコントロールの変更
  • SP 2.1 変更要求の追跡
  • SP 2.2 制御構成項目
• SG 3 誠実さを確立する
  • SP 3.1 構成管理記録の確立
  • SP 3.2 構成監査を実行する

• 成熟度レベル3のサポートプロセス領域

目的

意思決定分析および解決(DAR)の目的は、確立された基準に照らして特定された選択肢を評価する正式な評価プロセスを使用して、可能な意思決定を分析することです。

目標別の具体的な実践

• SG 1 代替案の評価
  • SP 1.1 意思決定分析のガイドラインを確立する
  • SP 1.2 評価基準を確立する
  • SP 1.3 代替ソリューションの特定
  • SP 1.4 評価方法の選択
  • SP 1.5 代替ソリューションの評価
  • SP 1.6 選択ソリューション

• 成熟度レベル3のプロジェクト管理プロセス領域

目的

統合プロジェクト管理(IPM)の目的は、組織の一連の標準プロセスから調整された統合され定義されたプロセスに従って、プロジェクトと関連する利害関係者の関与を確立および管理することです。

目標別の具体的な実践

• SG 1 プロジェクトで定義されたプロセスを使用する
  • SP 1.1 プロジェクトの定義済みプロセスを確立する
  • SP 1.2 プロジェクト活動の計画に組織プロセス資産を使用する
  • SP 1.3 プロジェクトの作業環境を確立する
  • SP 1.4 計画の統合
  • SP 1.5 統合計画を使用してプロジェクトを管理する
  • SP 1.6 チームの設立
  • SP 1.7 組織プロセス資産への貢献
• SG 2 関係するステークホルダーとの調整と協力
  • SP 2.1 ステークホルダーの関与の管理
  • SP 2.2 依存関係の管理
  • SP 2.3 調整問題の解決

• 成熟度レベル2のサポートプロセス領域

目的

測定と分析(MA)の目的は、管理情報のニーズをサポートするために使用される測定機能を開発し、維持することです。

目標別の具体的な実践

• SG 1 測定と分析の活動を調整する
  • SP 1.1 測定目標の確立
    • リソース、人材、施設、技術。
  • SP 1.2 対策の指定
    • 情報ニーズ文書、ガイダンス、参照、およびレポート。
  • SP 1.3 データ収集および保存手順の指定
    • 情報源、方法、頻度、所有者。
  • SP 1.4 分析手順の指定
    • ルール、アラーム、SPC、差異。
• SG 2 測定結果を提供する
  • SP 2.1 測定データの取得
    • 実際、計画、自動、手動。
  • SP 2.2 測定データの分析
    • 評価、ドリルダウン、RCA。
  • SP 2.3 データと結果を保存する
    • 保存、セキュリティ、アクセス、履歴、証拠。
  • SP 2.4 結果を伝える
    • 情報共有、ダッシュボード、最新、シンプル、解釈。

• 成熟度レベル3のプロセス管理プロセス領域

目的

組織プロセス定義(OPD)の目的は、使用可能な組織プロセス資産、作業環境標準、およびチームのルールとガイドラインのセットを確立し、維持することです。

目標別の具体的な実践

• SG 1 組織プロセス資産の確立
  • SP 1.1 標準プロセスの確立
  • SP 1.2 ライフサイクルモデルの説明を確立する
  • SP 1.3 調整基準とガイドラインを確立する
  • SP 1.4 組織の測定リポジトリを確立する
  • SP 1.5 組織のプロセス資産ライブラリを確立する
  • SP 1.6 作業環境基準の確立
  • SP 1.7 チームのルールとガイドラインを確立する

• 成熟度レベル3のプロセス管理プロセス領域

目的

組織プロセスフォーカス(OPF)の目的は、組織のプロセスとプロセス資産の現在の長所と短所を徹底的に理解した上で、組織プロセスの改善を計画、実装、展開することです。

目標別の具体的な実践

• SG 1 プロセス改善の機会を特定する
  • SP 1.1 組織プロセスのニーズを確立する
  • SP 1.2 組織のプロセスを評価する
  • SP 1.3 組織のプロセス改善を特定する
• SG 2 プロセス改善の計画と実施
  • SP 2.1 プロセスアクションプランの確立
  • SP 2.2 プロセスアクションプランの実装
• SG 3 組織プロセス資産を展開し、経験を組み込む
  • SP 3.1 組織プロセス資産の展開
  • SP 3.2 標準プロセスの導入
  • SP 3.3 実装の監視
  • SP 3.4 経験を組織プロセス資産に組み込む

• 成熟度レベル5のプロセス管理プロセス領域

目的

組織パフォーマンス管理(OPM)の目的は、ビジネス目標を達成するために組織のパフォーマンスを積極的に管理することです。

目標別の具体的な実践

• SG 1 ビジネスパフォーマンスの管理
  • SP 1.1 ビジネス目標の維持
  • SP 1.2 プロセスパフォーマンスデータの分析
  • SP 1.3 改善の余地がある領域を特定する
• SG 2 セレクトの改善
  • SP 2.1 改善提案を引き出す
  • SP 2.2 提案された改善点の分析
  • SP 2.3 検証の改善
  • SP 2.4 展開の改善点の選択と実装
• SG 3 デプロイの改善
  • SP 3.1 展開の計画
  • SP 3.2 展開の管理
  • SP 3.3 改善効果の評価

• 成熟度レベル4のプロセス管理プロセス領域

目的

組織プロセス パフォーマンス(OPP)の目的は、品質とプロセス パフォーマンスの目標達成をサポートするために、組織の一連の標準プロセス内の選択されたプロセスのパフォーマンスに関する定量的な理解を確立して維持し、組織のプロジェクトを定量的に管理するためのプロセス パフォーマンス データ、ベースライン、およびモデルを提供することです。

目標別の具体的な実践

• SG 1 パフォーマンスのベースラインとモデルを確立する
  • SP 1.1 品質とプロセスパフォーマンスの目標を確立する
  • SP 1.2 プロセスの選択
  • SP 1.3 プロセスパフォーマンス測定の確立
  • SP 1.4 プロセスパフォーマンスの分析とプロセスパフォーマンスベースラインの確立
  • SP 1.5 プロセスパフォーマンスモデルの確立

• 成熟度レベル3のプロセス管理プロセス領域

目的

組織研修(OT)の目的は、人々が役割を効果的かつ効率的に遂行できるように、スキルと知識を開発することです。

目標別の具体的な実践

• SG 1 組織的なトレーニング能力を確立する
  • SP 1.1 戦略的なトレーニングニーズを確立する
  • SP 1.2 組織の責任となるトレーニングニーズを決定する
  • SP 1.3 組織トレーニング戦術計画の確立
  • SP 1.4 トレーニング能力を確立する
• SG 2 トレーニングを提供する
  • SP 2.1 トレーニングの提供
  • SP 2.2 トレーニング記録の確立
  • SP 2.3 トレーニングの有効性を評価する

• 成熟度レベル3のエンジニアリングプロセス領域

目的

製品統合(PI)の目的は、製品コンポーネントから製品を組み立て、統合された製品が適切に動作すること (つまり、必要な機能と品質属性を備えていること) を確認し、製品を納品することです。

目標別の具体的な実践

• SG 1 製品統合の準備
  • SP 1.1 統合戦略の確立
  • SP 1.2 製品統合環境の確立
  • SP 1.3 製品統合手順と基準を確立する
• SG 2 インターフェースの互換性の確保
  • SP 2.1 インターフェースの説明の完全性を確認する
  • SP 2.2 インターフェースの管理
• SG 3 製品コンポーネントの組み立てと製品の配送
  • SP 3.1 製品コンポーネントの統合準備状況を確認する
  • SP 3.2 製品コンポーネントの組み立て
  • SP 3.3 組み立てられた製品コンポーネントの評価
  • SP 3.4 製品または製品コンポーネントのパッケージ化と配送

• 成熟度レベル2のプロジェクト管理プロセス領域

目的

プロジェクト監視および制御(PMC)の目的は、プロジェクトの進捗状況を把握し、プロジェクトのパフォーマンスが計画から大幅に逸脱した場合に適切な是正措置を講じることができるようにすることです。

目標別の具体的な実践

• SG 1 計画に対するプロジェクトの監視
  • SP 1.1 プロジェクト計画パラメータの監視
  • SP 1.2 コミットメントの監視
  • SP 1.3 プロジェクトリスクの監視
  • SP 1.4 モニターデータ管理
  • SP 1.5 利害関係者の関与を監視する
  • SP 1.6 進捗レビューを実施する
  • SP 1.7 マイルストーンレビューを実施する
• SG 2 是正措置の管理から終了まで
  • SP 2.1 問題の分析
  • SP 2.2 是正措置を講じる
  • SP 2.3 是正措置の管理

• 成熟度レベル2のプロジェクト管理プロセス領域

目的

プロジェクト計画(PP)の目的は、プロジェクト活動を定義する計画を確立し、維持することです。

目標別の具体的な実践

• SG 1 見積りの作成
  • SP 1.1 プロジェクトの範囲を見積もる
  • SP 1.2 作業成果物とタスク属性の見積りを確立する
  • SP 1.3 プロジェクトライフサイクルフェーズの定義
  • SP 1.4 労力とコストの見積り
• SG 2 プロジェクト計画の作成
  • SP 2.1 予算とスケジュールを確立する
  • SP 2.2 プロジェクトリスクの特定
  • SP 2.3 計画データ管理
  • SP 2.4 プロジェクトのリソースを計画する
  • SP 2.5 計画に必要な知識とスキル
  • SP 2.6 ステークホルダーの関与を計画する
  • SP 2.7 プロジェクト計画の策定
• SG 3 計画へのコミットメントを得る
  • SP 3.1 プロジェクトに影響する計画のレビュー
  • SP 3.2 作業レベルとリソース レベルの調整
  • SP 3.3 計画のコミットメントを得る

• 成熟度レベル2のサポートプロセス領域

目的

プロセスおよび製品品質保証(PPQA)の目的は、スタッフと管理者にプロセスと関連する作業成果物に関する客観的な洞察を提供することです。

目標別の具体的な実践

• SG 1 プロセスと作業成果物を客観的に評価する
  • SP 1.1 プロセスを客観的に評価する
  • SP 1.2 作業成果物を客観的に評価する
• SG 2 客観的な洞察を提供する
  • SP 2.1 非準拠の問題の伝達と解決
  • SP 2.2 レコードを確立します。

• 成熟度レベル4のプロジェクト管理プロセス領域

目的

定量的プロジェクト管理(QPM) プロセス領域の目的は、プロジェクトの確立された品質とプロセス パフォーマンスの目標を達成するためにプロジェクトを定量的に管理することです。

目標別の具体的な実践

• SG 1 定量的管理の準備
  • SP 1.1 プロジェクトの目的を確立する
  • SP 1.2 定義されたプロセスを構成する
  • SP 1.3 サブプロセスと属性の選択
  • SP 1.4 測定基準と分析手法の選択
• SG 2 プロジェクトを定量的に管理する
  • SP 2.1 選択したサブプロセスのパフォーマンスを監視する
  • SP 2.2 プロジェクトパフォーマンスの管理
  • SP 2.3 根本原因分析を実行する

• 成熟度レベル 3 のエンジニアリング プロセス領域。

目的

要件開発(RD)の目的は、顧客、製品、製品コンポーネントの要件を引き出し、分析し、確立することです。

目標別の具体的な実践

• SG 1 顧客要件の開発
  • SP 1.1 ニーズを引き出す
  • SP 1.2 利害関係者のニーズを顧客の要件に変換する
• SG 2 製品要件の開発
  • SP 2.1 製品および製品コンポーネントの要件を確立する
  • SP 2.2 製品コンポーネント要件の割り当て
  • SP 2.3 インターフェース要件の特定
• SG 3 要件の分析と検証
  • SP 3.1 運用コンセプトとシナリオを確立する
  • SP 3.2 必要な機能と品質特性の定義を確立する
  • SP 3.3 要件の分析
  • SP 3.4 バランスを達成するための要件の分析
  • SP 3.5 要件の検証

• 成熟度レベル2のプロジェクト管理プロセス領域

目的

要件管理(REQM)の目的は、プロジェクトの製品と製品コンポーネントの要件を管理し、それらの要件とプロジェクトの計画および作業成果物との間の整合性を確保することです。

目標別の具体的な実践

• SG 1 要件の管理
  • SP 1.1 要件を理解する
  • SP 1.2 要件へのコミットメントの取得
  • SP 1.3 要件変更の管理
  • SP 1.4 要件の双方向トレーサビリティを維持する
  • SP 1.5 プロジェクト作業と要件の整合性を確保する

• 成熟度レベル3のプロジェクト管理プロセス領域

目的

リスク管理(RSKM)の目的は、潜在的な問題を発生前に特定し、製品またはプロジェクトのライフサイクル全体にわたって必要に応じてリスク処理活動を計画および実行し、目標達成への悪影響を軽減することです。

目標別の具体的な実践

• SG 1 リスク管理の準備
  • SP 1.1 リスク源とリスクカテゴリの特定
  • SP 1.2 リスクパラメータの定義
  • SP 1.3 リスク管理戦略の確立
• SG 2 リスクの特定と分析
  • SP 2.1 リスクの特定
  • SP 2.2 リスクの評価、分類、優先順位付け
• SG 3 リスクの軽減
  • SP 3.1 リスク軽減計画の策定
  • SP 3.2 リスク軽減計画の実施

• 成熟度レベル2のプロジェクト管理プロセス領域

目的

サプライヤー契約管理(SAM)の目的は、サプライヤーからの製品の取得を管理することです。

目標別の具体的な実践

• SG 1 サプライヤー契約の確立
  • SP 1.1 取得タイプの決定
  • SP 1.2 サプライヤーの選択
  • SP 1.3 サプライヤー契約の確立
• SG 2 サプライヤー契約の遵守
  • SP 2.1 サプライヤー契約の締結
  • SP 2.2 取得した製品の受け入れ
  • SP 2.3 製品の移行を確実にする

• 成熟度レベル3のエンジニアリングプロセス領域

目的

テクニカル ソリューション(TS)の目的は、要件に対するソリューションを選択し、設計および実装することです。ソリューション、設計、実装には、製品、製品コンポーネント、および製品関連のライフサイクル プロセスが、必要に応じて単独または組み合わせて含まれます。

目標別の具体的な実践

• SG 1 製品コンポーネントソリューションを選択
  • SP 1.1 代替ソリューションと選択基準の開発
  • SP 1.2 製品コンポーネントソリューションの選択
• SG 2 デザインの開発
  • SP 2.1 製品または製品コンポーネントの設計
  • SP 2.2 技術データパッケージの確立
  • SP 2.3 基準を使用してインターフェースを設計する
  • SP 2.4 製造、購入、再利用の分析を実行する
• SG 3 製品設計の実装
  • SP 3.1 設計の実装
  • SP 3.2 製品サポートドキュメントの開発

• 成熟度レベル3のエンジニアリングプロセス領域

目的

検証(VAL)の目的は、製品または製品コンポーネントが意図された環境に配置されたときに、意図された用途を満たすことを実証することです。

目標別の具体的な実践

• SG 1 検証の準備
  • SP 1.1 検証対象製品の選択
  • SP 1.2 検証環境を確立する
  • SP 1.3 検証手順と基準を確立する
• SG 2 製品または製品コンポーネントの検証
  • SP 2.1 検証の実行
  • SP 2.2 検証結果の分析

• 成熟度レベル3のエンジニアリングプロセス領域

目的

検証(VER)の目的は、選択された作業成果物が指定された要件を満たしていることを確認することです。

目標別の具体的な実践

• SG 1 検証の準備
  • SP 1.1 検証のための作業成果物の選択
  • SP 1.2 検証環境の確立
  • SP 1.3 検証手順と基準を確立する
• SG 2 ピアレビューの実施
  • SP 2.1 ピアレビューの準備
  • SP 2.2 ピアレビューの実施
  • SP 2.3 ピアレビューデータの分析
• SG 3 選択された作業成果物の検証
  • SP 3.1 検証を​​実行する
  • SP 3.2 検証結果の分析

ここでは、プロセス領域のセットに加えられた変更のみが考慮されます。バージョン 1.2 に加えられた変更の詳細については、バージョン 1.2 リリース ノートを参照してください。変更の確定リストについては、CMMI バージョン 1.2 アップグレード トレーニングを受講してください。

• 次のプロセス領域は削除されました (すべて成熟度レベル 3):
  • 統合のための組織環境 (OEI)
  • 統合チーム (IT)
  • 統合サプライヤー管理 (ISM)
• 既存のプロセス領域に次の追加が行われました。
  • IPM – SG3 と SG4 は廃止され、新しい SG3 が追加されました (IPPD の追加として)
  • OPD – SG2 が追加されました (IPPD の追加として)
  • OPF – 古いSG3から2つのSPを抽出し、2つの新しいSPと組み合わせて新しいSG3を作成しました。
  • REQD – SP3.5はValidate Requirementsに名前が変更されました
  • SAM – SP2.1 は廃止され、SG2 で 2 つの新しい SP が追加されました。
  • TS – SP1.2はRD SP 3.1に組み込まれました
  • VER – SP3.2は「検証結果の分析」に名前が変更されました

CMMI-DEV V1.3 の重要な改善点は次のとおりです。

• 成熟度の高いプロセス領域は、業界のベストプラクティスを反映するように大幅に改善され、^[1]組織的イノベーションと展開（OID）から組織的パフォーマンス管理（OPM）に名前が変更されたプロセス領域における新しい特定の目標といくつかの新しい特定のプラクティスが含まれています。
• アジャイルプラクティス^[2]は、解釈ガイドラインとともに、プロセス領域の紹介に該当するプロセス領域への注釈とアジャイルプラクティスの解釈方法が追加されました。
• 複数のモデルの使用を簡素化するモデル アーキテクチャが改善されました。
• 業界のベストプラクティスを反映するようにエンジニアリングプラクティスを改訂し、アジャイル手法を使用する組織向けのガイダンスを追加するなど、情報資料が改善されました。
• モデルの明瞭性、正確性、および使いやすさを向上させるために、用語集の定義とモデルの用語が改善されました。
• レベル 4 と 5 の一般的な目標とプラクティス、および能力レベル 4 と 5 は削除され、高い成熟度を適切にビジネス目標の達成に集中させることができました。これは、能力レベル 1 ～ 3 を高い成熟度のプロセス領域 (原因分析と解決、定量的プロジェクト管理、組織パフォーマンス管理、組織プロセス パフォーマンス) に適用することで実現されます。

より完全で詳細な改善点のリストについては、http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/comparison.cfm を参照してください。変更の概要については、http://www.benlinders.com/2011/cmmi-v1-3-summing-up/ で説明されています。CMMI 認定でビジネスを向上させ、世界的な認知度を獲得し、組織のプロセスを最適化しましょう。

表：プロセス領域、カテゴリ、成熟度レベル^[3]

• 能力成熟度モデル
• 能力成熟度モデルの統合

• CMMI 製品チーム (2010 年 11 月)。「開発のための CMMI、バージョン 1.3」( PDF )。技術レポート CMU/SEI-2010-TR-033。ソフトウェア エンジニアリング研究所。2011年2 月 16 日に取得。 {{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です

• Chrissis, Mary Beth、Mike Konrad、Sandy Shrum (2011 年 2 月 16 日)。CMMI :プロセス統合および製品改善のガイドライン(第 3 版)。Addison -Wesley Professional。ISBN 978-0-321-71150-2。