第183号：CMMI V2.0とSEハンドブックのマッピング

SEのみなさま、システムズエンジニアリングハンドブック第４版(以下、SEハンドブック)はもう読まれましたか？
https://tinyurl.com/y3adv259

先日開催されたCapability Counts 2019で「Mapping CMMI V2.0 Development View to INCOSE Systems Engineering Handbook V4」という発表がありましたので、簡単に紹介します。

この発表では、CMMI V2.0とSEハンドブック第４版のハイレベルのマッピングと詳細なマッピングを説明されていました。

ハイレベルのマッピングは、CMMI-DEVのカテゴリ(CMMI V2.0には、Doing、Managing、Enabling、Improvingという４つのカテゴリがあります)をSEハンドブックのプロセスにマッピングしています。

詳細なマッピングは、CMMI-DEVのプラクティスをSEハンドブックのアクティビティにマッピングしています。

ハイレベルのマッピングは次のとおりです。

CMMI-DEV Doing(含まれるプラクティス領域:RDM, PQA, VV, PR, TS, PI, SAM)
SEハンドブックのプロセス
4.2 利害関係者ニーズおよび要求定義プロセス
4.3 システム要求定義プロセス
4.4 アーキテクチャ定義プロセス
4.5 設計定義プロセス
4.7 実装プロセス
4.8 統合プロセス
4.9 検証プロセス
4.10 移行プロセス(関連性低い)
4.11 妥当性確認プロセス
4.12 運用プロセス(関連性低い)
6.1 取得プロセス

CMMI-DEV Managing(含まれるプラクティス領域:EST, PLAN, MC, RSK, OT)
SEハンドブックのプロセス
5.1 プロジェクト計画プロセス
5.2 プロジェクトアセスメントおよび統制プロセス
5.4 リスクマネジメントプロセス
7.4 人的資源マネジメントプロセス

CMMI-DEV Enabling(含まれるプラクティス領域:CAR, DAR, CM)
SEハンドブックのプロセス
5.3 意思決定マネジメントプロセス
5.5 構成管理プロセス

CMMI-DEV Improving(含まれるプラクティス領域:GOV, II, PCM, PAD, MPM)
SEハンドブックのプロセス
7.1 ライフサイクルモデルマネジメントプロセス
7.2 インフラストラクチャマネジメントプロセス(関連性低い)
7.4 人的資源マネジメントプロセス(関連性低い)
7.5 品質管理プロセス(関連性低い)
7.6 知識マネジメントプロセス

ハイレベルのマッピングは以上です。
次は、詳細なマッピングです。ここでは例として要件の開発と管理(RDM)を取り上げます。SEハンドブックのプロセスの後にある数字は何個目のアクティビティかを示しています。

レベル1
RDM 1.1 要件を記録する。
4.2 利害関係者ニーズおよび要求定義プロセス　2
4.3 システム要求定義プロセス　2

レベル2
RDM 2.1 利害関係者のニーズ、期待、制約、ならびにインタフェースまたは接続を引き出す。
4.2 利害関係者ニーズおよび要求定義プロセス　2
4.3 システム要求定義プロセス　1
4.12 運用プロセス　1
4.13 保守プロセス　1

RDM 2.2 利害関係者のニーズ、期待、制約、ならびにインタフェースまたは接続を優先付けされた顧客要件へ変換する。
4.2 利害関係者ニーズおよび要求定義プロセス　4

RDM 2.3 要件の提供者と共に、要件の意味について理解を深める。
4.2 利害関係者ニーズおよび要求定義プロセス　5、6
4.3 システム要求定義プロセス　4
7.5 品質管理プロセス　2

RDM 2.4 要件を実装できると、プロジェクトの参加者からコミットメントを獲得する。
該当事項なし

RDM 2.5 要件、ならびに活動、または作業成果物について双方向の追跡可能性を作成、記録、維持する。
4.1 ビジネスまたはミッション分析プロセス　5
4.2 利害関係者ニーズおよび要求定義プロセス　6
4.3 システム要求定義プロセス　4
4.4 アーキテクチャ定義プロセス　4、6
4.5 設計定義プロセス　2、4
4.7 実装プロセス　3
7.5 品質管理プロセス　2
4.10 移行プロセス　3
4.9 検証プロセス　3
4.11 妥当性確認プロセス　3

RDM 2.6 計画や活動または作業成果物が要件に合致し続けるようにする。
4.1 ビジネスまたはミッション分析プロセス　5
4.2 利害関係者ニーズおよび要求定義プロセス　6
4.3 システム要求定義プロセス　4

レベル3
RDM 3.1 ソリューションとその構成要素の要件を作成して更新し続ける。
4.3 システム要求定義プロセス　2、4
4.4 アーキテクチャ定義プロセス　6
4.5 設計定義プロセス　4
4.6 システム分析プロセス　3
4.7 実装プロセス　3
4.8 統合プロセス　3
4.12 運用プロセス　3
4.13 保守プロセス　4

RDM 3.2 運用コンセプトとシナリオを作成する。
4.2 利害関係者ニーズおよび要求定義プロセス　3
4.12 運用プロセス　1
4.13 保守プロセス　1

RDM 3.3 実装される要件を割り当てる。
4.3 システム要求定義プロセス　2
4.4 アーキテクチャ定義プロセス　3、4
4.5 設計定義プロセス　2

RDM 3.4 インタフェースまたは接続要件を特定して作成し、更新し続ける。
4.3 システム要求定義プロセス　1

RDM 3.5 要件が必要かつ十分であるようにする。
4.3 システム要求定義プロセス　3
4.13 保守プロセス　1
4.12 運用プロセス　1

RDM 3.6 利害関係者のニーズと制約の兼ね合いを取る。
4.2 利害関係者ニーズおよび要求定義プロセス　5
4.3 システム要求定義プロセス　3
4.6 システム分析プロセス　2

RDM 3.7 結果としてのソリューションが対象環境にて意図した成果を挙げるように、要件の妥当性を確認する。
4.2 利害関係者ニーズおよび要求定義プロセス　5
4.3 システム要求定義プロセス　3、4
4.6 システム分析プロセス　2
7.5 品質管理プロセス　2
4.11 妥当性確認プロセス　2

RDMと強い関連性があるのは、利害関係者ニーズおよび要求定義プロセスとシステム要求定義プロセスでした。また、要件実装についてプロジェクトの参加者からコミットメントを獲得することについて対応がありませんでした。

他のプラクティス領域も知りたい、CMMI V2.0のことをもっと知りたい場合は、弊社でCMMI導入コンサルティングを行っておりますので、こちらからお問い合わせください。
https://www.daiwa-computer.co.jp/jp/consulting/inquiries

ちなみに、各プラクティス領域のカバー率は下記のとおりでした。
原因分析と解決 (CAR)　15%
構成管理 (CM)　86%
決定分析と解決 (DAR)　80%
見積もり (EST)　50%
統治 (GOV)　30%
実装のインフラ (II)　88%
実績と測定の管理 (MPM)　64%
監視と制御 (MC)　92%
組織トレーニング (OT)　64%
ピアレビュー (PR)　75%
計画 (PLAN)　63%
プロセス資産開発 (PAD)　76%
プロセス管理 (PCM)　50%
プロセス品質保証 (PQA)　100%
成果物統合 (PI)　93%
要件の開発と管理 (RDM)　93%
リスクと機会の管理 (RSK)　61%
供給者合意管理 (SAM)　82%
技術解 (TS)　89%
検証と妥当性確認 (VV)　100%