Cmmi-quick-guide
SEI CMMI-概要
プロセス改善は継続的な改善です。 完璧に達することはできません。 このチュートリアルでは、常により良い成果を上げることに焦点を当てた、絶えず進化し改善するモデルであるCMMを学びます。 私たちの到達範囲は常に私たちの把握を超えているべきです。
CMMとは何ですか？
- CMMは[。underline] #C＃* apability * [。underline] #M＃* aturity * [。underline] #M＃ odelを表します。
- さまざまな知識体系の不可欠な実践およびプロセスの要素に焦点を当てています。
- 常識的で効率的で実績のあるビジネスのやり方を説明します（すでに行っているはずです）-根本的な新しいアプローチではありません。
- CMMは、組織のソフトウェア開発プロセスの成熟度を評価および測定する方法です。
- CMMは、ソフトウェア開発プロセスの成熟度を1〜5のスケールで測定します。
- CMM v1.0は、米国ピッツバーグにあるカーネギーメロン大学のSoftware Engineering Institute（SEI）によって開発されました。
- CMMはもともとソフトウェア開発および保守用に開発されましたが、後に開発されました-
- システムエンジニアリング
- サプライヤー調達
- 統合された製品およびプロセス開発
- ピープルCMM
- ソフトウェア取得
CMMの例
- People CMM-プロジェクトの才能を開発、動機付け、維持します。
- ソフトウェアCMM-ソフトウェア中心の開発および保守機能を強化します。
成熟度とは何ですか？
定義はさまざまですが、成熟したプロセスは一般的に考えられています-
- 明確に定義された、
- 繰り返し可能、
- 測定された、
- 分析済み、
- 改善され、
- 効果的。
不十分だが成熟したプロセスは、まったく成熟していないのと同じくらい悪いです！
CMMは、一連のプラクティスを定義し、それらを改善するための一般的なフレームワークを提供することで、成熟度の問題を解決するのに役立ちます。 CMMの焦点は、重要なプロセス領域と、統制されたソフトウェアプロセスを含む例示的なプラクティスを識別することにあります。
未熟な組織と成熟した組織
未熟な組織には、次の特性があります-
- プロジェクト中に即興で行われるプロセス
- 承認されたプロセスは無視されます
- 積極的ではなく反応的
- 非現実的な予算とスケジュール
- スケジュールのために品質を犠牲にする
- 客観的な品質の尺度がない
対照的に、成熟した組織の特徴は次のとおりです-
- グループ間のコミュニケーションと調整
- 計画通りに成し遂げられた仕事
- プロセスと一貫した実践
- 必要に応じて更新されるプロセス
- 明確に定義された役割/責任
- 経営陣による正式なコミット
CMMIとは何ですか？
CMM統合プロジェクトは、複数のCMMを使用する問題を整理するために形成されました。 CMMI製品チームの使命は、3つの*ソースモデル*を、企業全体のプロセス改善を追求する組織のための単一の改善フレームワークに結合することでした。 これらの3つのソースモデルは-
- ソフトウェアの機能成熟度モデル（SW-CMM）-v2.0ドラフトC
- Electronic Industries Alliance Interim Standard（EIA/IS）-731システムエンジニアリング。
- 統合製品開発能力成熟度モデル（IPD-CMM）v0.98。
- CMM統合*
- 統合モデルの初期セットを構築します。
- 学んだ教訓に基づいて、ソースモデルのベストプラクティスを改善します。
- 将来のモデルの統合を可能にするフレームワークを確立します。
CMMとCMMIの違い
CMMは、Systems Engineering CMM、Software CMM、People CMM、Software Acquisition CMMなどの特定の分野における成熟したプラクティスの参照モデルですが、必要に応じて統合することは困難でした。
CMMIはCMMの後継であり、より成熟したガイドラインとして進化し、CMMの個々の分野の最高のコンポーネント（ソフトウェアCMM、People CMMなど）を組み合わせて構築されました。 製品の製造、人材管理、ソフトウェア開発などに適用できます。
CMM Integratedはソフトウェアエンジニアリングとシステムエンジニアリングの両方を説明していますが、CMMはソフトウェアエンジニアリングのみを説明しています。 CMMIは、統合プロセスおよび製品開発とサプライヤソーシングも取り入れています。
CMMIとビジネス目標
CMMIの目的は非常に明白です。 彼らは次のとおりです-
- 高品質の製品またはサービスの生産-CMMIモデルのプロセス改善コンセプトは、デミング、ジュラン、およびクロスビーの品質パラダイムから進化しました。高品質の製品は品質プロセスの結果です。 CMMIは、要件管理、品質保証、検証、検証などの品質関連の活動に重点を置いています。
- 株主のための価値の創造-成熟した組織は、成熟度の低い組織よりもコストと収益の見積もりを改善し、それらの見積もりに沿って実行する傾向があります。 CMMIは、高品質の製品、予測可能なスケジュール、効果的な測定をサポートし、正確で防御可能な予測を行う際の管理をサポートします。 このプロセスの成熟度は、投資家の目には組織の価値を弱める可能性のあるプロジェクトのパフォーマンスの問題を防ぐことができます。
- 顧客満足度の向上-顧客のニーズに照らして検証された高品質の製品でコストとスケジュールの目標を達成することは、顧客満足のための良い公式です。 CMMIは、計画、監視、および測定に重点を置いてこれらのすべての要素に対処し、より有能なプロセスに伴う予測可能性の向上を実現します。
- 市場シェアの増加-市場シェアは、高品質の製品とサービス、名前の識別、価格設定、画像など、多くの要因の結果です。 顧客は、コミットメントを達成したことで定評のあるサプライヤーと取引することを好みます。
- 卓越性に対する業界全体の評価を獲得-卓越性の評判を高める最良の方法は、プロジェクトで一貫して良好なパフォーマンスを発揮し、コストとスケジュールのパラメーター内で高品質の製品とサービスを提供することです。 CMMI要件に準拠したプロセスを持つことで、その評判を高めることができます。
SEI CMMIモデル-専門分野
CMM統合は、複数の専門分野/知識体系を統合したモデルです。 現在、CMMIモデルを選択する際に利用できる知識は4つあります。
システムエンジニアリング
システムエンジニアリングは、ソフトウェアを含む場合と含まない場合がある完全なシステムの開発を対象としています。 システムエンジニアは、顧客のニーズ、期待、制約を製品ソリューションに変換し、製品のライフサイクル全体を通じてこれらの製品ソリューションをサポートすることに焦点を当てています。
ソフトウェア工学
ソフトウェアエンジニアリングは、ソフトウェアシステムの開発を対象としています。 ソフトウェアエンジニアは、ソフトウェアの開発、運用、および保守に対する体系的で統制された定量化可能なアプローチの適用に焦点を当てています。
統合された製品およびプロセス開発
統合された製品およびプロセス開発（IPPD）は、顧客のニーズ、期待、および要件をよりよく満たすために、製品のライフサイクルを通じて関連する利害関係者のタイムリーなコラボレーションを実現する体系的なアプローチです。 IPPDアプローチをサポートするプロセスは、組織内の他のプロセスと統合されています。
プロジェクトまたは組織がIPPDを選択した場合、IPPDのベストプラクティスは、製品の生産に使用される他のベストプラクティス（システムエンジニアリングに関連するものなど）と同時に実行されます。 つまり、組織またはプロジェクトがIPPDを使用する場合、IPPDに加えて1つ以上の分野を選択する必要があります。
サプライヤー調達
作業がより複雑になると、プロジェクトマネージャーはサプライヤを使用して、プロジェクトで特に必要な機能を実行したり、製品に変更を加えたりします。 これらの活動が重要な場合、プロジェクトは、ソース分析の強化と製品納入前のサプライヤ活動の監視の恩恵を受けます。 このような状況では、サプライヤーの調達規律はサプライヤーからの製品の取得をカバーします。
IPPDのベストプラクティスと同様に、サプライヤーの調達のベストプラクティスは、製品の生産に使用されるベストプラクティスと併せて選択する必要があります。
CMMI規律の選択
規律を選択することは難しいステップであり、組織が改善したいものに依存します。
- 構成管理、測定と分析、組織プロセスのフォーカス、プロジェクトの監視と制御、プロセスと製品の品質保証、リスク管理、サプライヤー契約管理などのシステムエンジニアリングプロセスを改善する場合は、システムエンジニアリング（SE）を選択する必要があります。規律。 システムエンジニアリングの分野の増幅は特に強調されています。
- 統合チーム、統合のための組織環境などの統合製品およびプロセス開発プロセスを改善する場合は、IPPDを選択する必要があります。 IPPDの専門分野の拡大は特に強調されています。
- 統合サプライヤ管理などのソース選択プロセスを改善する場合は、サプライヤソーシング（SS）を選択する必要があります。 サプライヤーの調達に対する規律の拡大は、特に強調されています。
- 複数の分野を改善する場合、それらの分野に関連するすべての分野で作業し、それらの分野のすべての分野増幅に注意を払う必要があります。
以降の章では、CMMIの実装に関連するさまざまな領域について説明します。
SEI CMMI-表象
CMMIは次のように構成されています-
- 成熟度レベル（段階的な表現）または能力レベル（連続的な表現）
- プロセスエリア
- 目標：一般的および具体的
- 共通の機能
- プラクティス：汎用および特定
この章では、2つのCMMI表現について説明し、残りの主題については後続の章で説明します。
表明により、組織はさまざまな改善目標を追求できます。 組織は、次の2つの改善パスのいずれかに進むことができます。
段階的な表現
段階的表現は、ソフトウェアCMMで使用されるアプローチです。 定義済みのプロセス領域のセットを使用して、組織の改善パスを定義するアプローチです。 この改善パスは、成熟度レベルと呼ばれるモデルコンポーネントによって記述されます。 成熟度レベルは、組織プロセスの改善に向けて明確に定義された進化的プラトーです。
CMMI段階的表現
- 実績のある一連の改善を提供し、それぞれが次の基盤として機能します。
- 成熟度レベルを使用して、組織間および組織間の比較を許可します。
- SW-CMMからCMMIへの簡単な移行を提供します。
- 評価結果を要約し、組織間の比較を可能にする単一の評価を提供します。
したがって、段階的表現は、プロセスおよび関連する組織関係の実証済みのグループ化と順序付けに基づいて、組織改善のための事前定義されたロードマップを提供します。 手順のシーケンスから迂回することはできません。
CMMIの段階的な構造
次の図は、CMMI段階モデル構造を示しています。
連続表現
連続表現は、SECMおよびIPD-CMMで使用されるアプローチです。 このアプローチにより、組織は特定のプロセス領域を選択し、それに基づいて改善を行うことができます。 連続表現では、機能レベルを使用して、個々のプロセス領域に関連する改善を特徴付けます。
CMMI連続表現
- 組織のビジネス目標に最適な改善の順序を選択し、組織のリスク領域を軽減できます。
- プロセス領域ごとに、組織全体および組織間の比較を可能にします。
- EIA 731（および他の連続表現モデル）からCMMIへの簡単な移行を提供します。
したがって、継続的表現は、改善のプロセスと必要な改善の量を選択するための柔軟性を組織に提供します。
CMMI連続構造
次の図は、CMMI連続モデル構造を示しています。
連続表現と段階的表現
| Continuous Representation | Staged Representation |
|---|---|
| Process areas are organized by process area categories. | Process areas are organized by maturity levels. |
| Improvement is measured using capability levels. Capability levels measure the maturity of a particular process across an organization; it ranges from 0 through 5. | Improvement is measured using maturity levels. Maturity levels measure the maturity of a set of processes across an organization: it ranges from 1 through 5. |
| There are two types of specific practices: base and advanced. All specific practices appear in the continuous representation. | There is only one type of specific practice. The concepts of base and advanced practices are not used. All specific practices appear in the staged representation except when a related base-advanced pair of practices appears in the continuous representation, in which case only the advanced practice appears in the staged representation. |
| Capability levels are used to organize the generic practices. | Common features are used to organize generic practices. |
| All generic practices are included in each process area. | Only the level 2 and level 3 generic practices are included. |
| Equivalent staging allows determination of a maturity level from an organization’s achievement profile. | There is no need for an equivalence mechanism to back the continuous representation because each organization can choose what to improve and how much to improve using the staged representation. |
どの表現が優れていますか？
各表現には他の表現に比べて利点があり、組織によっては両方の表現を使用して、改善プログラムのさまざまな時点で特定の要件に対処します。
組織の成熟度は段階的な表現の焦点であり、プロセス領域の能力は連続的な表現の焦点です。
組織の成熟度とプロセス領域の機能は同様の概念です。 それらの違いは、組織の成熟度が組織全体の一連のプロセス領域に関係するのに対し、プロセス領域機能は単一のプロセス領域または特定のプラクティスに関連する一連のプロセスを処理することです。
次の図は、両方のプレゼンテーションを示しています。 この図では、 ML は成熟度レベルを示し、 PA はプロセス領域を示します。
CMMI-成熟度レベル
成熟度レベルは、成熟したソフトウェアプロセスの達成に向けて明確に定義された進化的プラトーです。 各成熟度レベルは、継続的なプロセス改善のための基盤となるレイヤーを提供します。
段階表示のCMMIモデルには、1〜5の数字で指定された5つの成熟度レベルがあります。 彼らは-
- 初期
- マネージド
- 定義済み
- 定量的に管理
- 最適化
CMMI段階的表現成熟度レベル
次の図は、CMMIの段階的表現の成熟度レベルを示しています。
次に、各成熟度レベルの詳細を学習します。 次のセクションでは、これらの成熟度レベルに関連するすべてのプロセス領域をリストします。
成熟度レベルの詳細
成熟度レベルは、事前定義された一連のプロセス領域で構成されています。 成熟度レベルは、プロセス領域の定義済みの各セットに適用される*特定*および*汎用目標*の達成度によって測定されます。 次のセクションでは、各成熟度レベルの特性について詳しく説明します。
成熟度レベル1初期
成熟度レベル1では、プロセスは通常アドホックで無秩序です。 通常、組織は安定した環境を提供しません。 これらの組織での成功は、実績のあるプロセスの使用ではなく、組織内の人々の能力と英雄に依存しています。
成熟度レベル1の組織は、機能する製品とサービスを頻繁に作成します。ただし、プロジェクトの予算とスケジュールを頻繁に超過します。
成熟度レベル1の組織の特徴は、過剰なコミットメントを起こし、危機時にプロセスを放棄し、過去の成功を繰り返すことができないことです。
成熟度レベル2管理
成熟度レベル2では、組織は成熟度レベル2のプロセス領域のすべての*特定*および*一般的な目標*を達成しています。 言い換えれば、組織のプロジェクトは、要件が管理され、プロセスが計画、実行、測定、および制御されていることを保証しています。
成熟度レベル2に反映されたプロセスの規律は、ストレス時に既存のプラクティスが保持されることを保証するのに役立ちます。 これらのプラクティスが実施されると、プロジェクトは文書化された計画に従って実行および管理されます。
成熟度レベル2では、要件、プロセス、作業成果物、およびサービスが管理されます。 成果物のステータスとサービスの提供は、定義された時点で管理者に表示されます。
関連する利害関係者の間でコミットメントが確立され、必要に応じて改訂されます。 作業成果物は利害関係者とともにレビューされ、管理されます。
作業成果物とサービスは、指定された要件、標準、および目的を満たします。
成熟度レベル3の定義
成熟度レベル3では、組織は、成熟度レベル2および3に割り当てられたプロセス領域のすべての*特定*および*汎用目標*を達成しています。
成熟度レベル3では、プロセスは十分に特徴付けられ理解されており、標準、手順、ツール、および方法で説明されています。
成熟度レベル2と成熟度レベル3の重要な違いは、標準、プロセスの説明、および手順の範囲です。 成熟度レベル2では、標準、プロセスの説明、および手順は、プロセスの特定のインスタンス（たとえば、特定のプロジェクト）ごとにまったく異なる場合があります。
成熟度レベル3では、プロジェクトの標準、プロセスの説明、および手順は、特定のプロジェクトまたは組織単位に合うように、組織の一連の標準プロセスから調整されます。 組織の一連の標準プロセスには、成熟度レベル2および成熟度レベル3で対処されたプロセスが含まれます。 その結果、組織全体で実行されるプロセスは、調整ガイドラインで許可されている違いを除いて一貫しています。
もう1つの重要な違いは、成熟度レベル3では、プロセスは通常、成熟度レベル2よりも詳細かつ厳密に記述されることです。 成熟度レベル3では、プロセスの相互関係とプロセス、作業成果物、およびサービスの詳細な測定値の相互関係を理解して、プロセスをより積極的に管理します。
定量的に管理された成熟度レベル4
成熟度レベル4では、組織は、成熟度レベル2、3、および4に割り当てられたプロセス領域のすべての*特定の目標*と、成熟度レベル2および3に割り当てられた*一般的な目標*を達成しています。
成熟度レベル4では、プロセス全体のパフォーマンスに大きく貢献するサブプロセスが選択されます。 これらの選択されたサブプロセスは、統計的手法およびその他の定量的手法を使用して制御されます。
品質とプロセスパフォーマンスの定量的目標が確立され、プロセス管理の基準として使用されます。 定量的な目標は、顧客、エンドユーザー、組織、およびプロセスの実装者のニーズに基づいています。 品質とプロセスのパフォーマンスは統計的に理解され、プロセスの全期間を通じて管理されます。
これらのプロセスでは、プロセスパフォーマンスの詳細な測定値が収集され、統計的に分析されます。 プロセス変動の特別な原因が特定され、必要に応じて、特別な原因の原因が修正され、将来の発生を防ぎます。
品質とプロセスのパフォーマンス測定値は、組織の測定リポジトリに組み込まれ、将来の事実に基づいた意思決定をサポートします。
成熟度レベル3と成熟度レベル4の重要な違いは、プロセスパフォーマンスの予測可能性です。 成熟度レベル4では、プロセスのパフォーマンスは統計的手法やその他の定量的手法を使用して制御され、定量的に予測可能です。 成熟度レベル3では、プロセスは定性的にのみ予測可能です。
成熟度レベル5の最適化
成熟度レベル5では、組織は、成熟度レベル2、3、4、および5に割り当てられたプロセス領域の特定の目標、および成熟度レベル2および3に割り当てられた*一般的な目標*をすべて達成しています。
プロセスに固有の変動の一般的な原因の定量的理解に基づいて、プロセスは継続的に改善されます。
このレベルは、漸進的かつ革新的な技術の改善を通じて、プロセスのパフォーマンスを継続的に改善することに焦点を当てています。
組織の定量的プロセス改善目標が確立され、変化するビジネス目標を反映するために継続的に改訂され、プロセス改善の管理の基準として使用されます。
展開されたプロセス改善の効果は、定量的なプロセス改善目標に対して測定および評価されます。 定義されたプロセスと組織の一連の標準プロセスの両方が、測定可能な改善活動のターゲットです。
機敏で革新的なプロセスの最適化は、組織のビジネス価値と目標に沿った力を与えられた従業員の参加に依存します。 学習を加速し共有する方法を見つけることにより、変化と機会に迅速に対応する組織の能力が強化されます。 プロセスの改善は本質的に誰もが果たすべき役割であり、継続的な改善のサイクルをもたらします。
成熟度レベル4と成熟度レベル5の重要な違いは、対処するプロセスの種類です。 成熟度レベル4では、プロセスはプロセス変動の特別な原因に対処し、結果の統計的な予測可能性を提供することに関係しています。 プロセスは予測可能な結果を生成する場合がありますが、確立された目標を達成するには結果が不十分な場合があります。 成熟度レベル5では、プロセスはプロセス変動の一般的な原因への対処とプロセスの変更（つまり、プロセスパフォーマンスの手段のシフト）に関係し、確立された定量的プロセス改善目標を達成するためにプロセスパフォーマンスを改善します（統計的な予測可能性を維持します） 。
成熟度レベルをスキップしないでください
各成熟度レベルは、次のレベルでのプロセスの効果的な実装に必要な基盤を提供します。
- 高レベルのプロセスは、低レベルの規律がなければ成功の可能性が低くなります。
- イノベーションの効果は、ノイズの多いプロセスではあいまいになります。
より高い成熟度レベルのプロセスは、より低い成熟度レベルの組織によって実行される可能性があり、危機において一貫して適用されないリスクがあります。
成熟度レベルとプロセス領域
これは、ソフトウェア組織に定義されているすべての対応するプロセス領域のリストです。 これらのプロセス領域は、組織によって異なる場合があります。
このセクションでは、関連するプロセス領域の名前を提供します。 これらのプロセス領域の詳細については、CMMIプロセス領域の章をご覧ください。
| Level | Focus | Key Process Area | Result |
|---|---|---|---|
|
5 最適化 |
Continuous Process Improvement |
Organizational Innovation and Deployment 原因分析と解決 |
Highest Quality/Lowest Risk |
|
4 定量的に管理 |
Quantitatively Managed |
Organizational Process Performance 定量的プロジェクト管理 |
Higher Quality/Lower Risk |
|
3 定義済み |
Process Standardization |
Requirements Development テクニカルソリューション 製品統合 検証 検証 組織プロセスの焦点 組織プロセス定義 組織トレーニング 統合プロジェクト管理（IPPDエキストラ付き） 危機管理 意思決定の分析と解決 統合チーミング（IPPDのみ） Org. 統合環境（IPPDのみ） 統合サプライヤー管理（SSのみ） |
Medium Quality/Medium Risk |
|
2 マネージド |
Basic Project Management |
Requirements Management プロジェクト計画 プロジェクトの監視と制御 サプライヤー契約管理 測定と分析 プロセスおよび製品品質保証 構成管理 |
Low Quality/High Risk |
|
1 初期 |
Process is informal and Adhoc | Lowest Quality/Highest Risk |
CMMI-機能レベル
能力レベルは、プロセス領域に関連する組織の能力を表す、明確に定義された進化的プラトーです。 機能レベルは、プロセスエリアに関連する特定の一般的なプラクティスで構成され、そのプロセスエリアに関連付けられた組織のプロセスを改善できます。 各レベルは、継続的なプロセス改善の基盤となる層です。
したがって、能力レベルは累積的です。つまり、より高い能力レベルには、より低いレベルの属性が含まれます。
連続表現のCMMIモデルには、0〜5の数字で指定された6つの機能レベルがあります。
- 0-不完全
- 1-実施済み
- 2-管理
- 3-定義済み
- 4-定量的に管理
- 5-最適化
各機能レベルの簡単な説明は次のとおりです-
機能レベル0：不完全
「不完全なプロセス」とは、実行されていないか部分的に実行されているプロセスです。 部分的に実行されたプロセスを制度化する理由がないため、プロセス領域の特定の目標の1つ以上が満たされておらず、このレベルの一般的な目標は存在しません。
これは、段階的表現の成熟度レベル1に相当します。
機能レベル1：実施済み
機能レベル1プロセスは、機能レベル1固有の一般的なプラクティスをすべて実行することが期待されるプロセスです。 パフォーマンスは安定していない場合があり、品質、コスト、スケジュールなどの特定の目標を満たしていない場合がありますが、有用な作業は実行できます。 これは、プロセス改善のほんの始まり、または小さな一歩にすぎません。 それはあなたが何かをしていることを意味しますが、それが本当にあなたのために働いていることを証明することはできません。
機能レベル2：管理
管理プロセスは、特定の目的を達成するために、個々のプロジェクト、グループ、またはスタンドアロンプロセスに対して計画、実行、監視、および制御されます。 プロセスを管理すると、プロセスのモデル目標と、コスト、スケジュール、品質などの他の目標の両方が達成されます。 このレベルのタイトルが示すように、組織で物事が行われる方法を積極的に管理しています。 一貫して収集され、管理アプローチに適用されるいくつかのメトリックがあります。
注意-メトリックは、段階的表現と連続表現の両方で、CMMIのすべてのレベルで収集され、使用されます。 組織が能力レベル4までメトリックを使用するのを待つことができると考えるのはひどい誤りです。
機能レベル3：定義済み
機能レベル3プロセスは、「定義済みプロセス」として特徴付けられます。定義済みプロセスは、組織の調整ガイドラインに従って組織の一連の標準プロセスから調整された管理（機能レベル2）プロセスであり、作業成果物、測定、およびその他のプロセス改善情報を組織プロセス資産に提供します。
機能レベル4：定量的に管理
機能レベル4プロセスは、「定量的に管理されるプロセス」として特徴付けられます。定量的に管理されるプロセスは、統計的およびその他の定量的手法を使用して制御される定義済み（機能レベル3）のプロセスです。 品質とプロセスパフォーマンスの定量的目標が確立され、プロセス管理の基準として使用されます。 品質とプロセスのパフォーマンスは統計的に理解され、プロセスの全期間を通じて管理されます。
機能レベル5：最適化
最適化プロセスは、プロセスに固有のプロセス変動の一般的な原因の理解に基づいて改善された、定量的に管理されるプロセスです。 漸進的および革新的な改善を通じて、プロセスのパフォーマンスを継続的に改善することに焦点を当てています。 定義されたプロセスと組織の一連の標準プロセスの両方が改善活動の対象です。
機能レベル4は、プロセスパフォーマンスのベースライン、モデル、および測定値の確立に重点を置いています。 機能レベル5は、組織または企業全体のパフォーマンス結果の調査、作業の実行方法（使用されるプロセス）の問題の一般的な原因の発見、およびプロセスの問題の修正に焦点を当てています。 修正には、プロセス文書の更新と、エラーが挿入された場所に関連するトレーニングが含まれます。
継続的な表現におけるプロセス領域の編成
| Category | Process Area |
|---|---|
| Project Management |
|
| Support |
|
| Engineering |
|
| Process Management |
|
CMMI-主要なプロセス領域
プロセスエリアは、エリア内の関連するプラクティスのクラスタであり、集合的に実装された場合、そのエリアを大幅に改善するために重要と考えられる一連の目標を満たします。 すべてのCMMIプロセス領域は、連続表現と段階的表現の両方に共通です。
継続的な表現により、組織は、組織とそのビジネス目標に最も利益をもたらすプロセス領域または相互に関連するプロセス領域のセットを選択することにより、プロセス改善努力の焦点を選択できます。 プロセス領域間の依存関係のため、組織が選択できるものにはいくつかの制限がありますが、組織はその選択にかなりの自由があります。
プロセス領域を選択したら、それらのプロセス領域に関連付けられたプロセスをどの程度改善したいのかも選択する必要があります（つまり、適切な機能レベルを選択します）。 能力レベル、および一般的な目標と実践は、個々のプロセス領域のプロセスの改善をサポートします。
逆に、段階的な表現は、プロセス領域が属する成熟度レベルのコンテキストで常にプロセス領域を見ることを奨励していることがわかります。 プロセス領域は、この概念を強化するために、成熟度レベル別に編成されています。 プロセス領域を使用する場合、プロセス領域全体、つまりすべての目標とすべてのプラクティスを使用します。
CMMIプロセスエリア（PA）は、定義されたレベルに関係なく、相互作用および相互リンクを理解するために、次の4つのカテゴリにグループ化できます。
- プロセス管理
- プロジェクト管理
- エンジニアリング
- サポート
各プロセス領域は、一連の目標と実践によって定義されます。 目標と実践には2つのカテゴリがあります-
- 一般的な目標と実践-それらはすべてのプロセス領域の一部です。
- 特定の目標と実践-特定のプロセス領域に固有です。
会社のプロセスがそのプロセス領域の一般的および特定の目標と実践のすべてをカバーしている場合、プロセス領域は満たされます。
一般的な目標と実践
一般的な目標と実践は、すべてのプロセス領域の一部です。
注記-GG→一般的な目標とGP→一般的な練習
- 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改善情報の収集
- GG 4定量的に管理されたプロセスの制度化
- GP 4.1プロセスの定量的目標を確立する
- GP 4.2サブプロセスのパフォーマンスの安定化
- GG 5最適化プロセスの制度化
- GP 5.1は継続的なプロセス改善を保証します
- GP 5.2問題の根本原因を修正する
共通の機能
共通の機能は、重要なプロセス領域の実装と制度化が効果的で、反復可能で、永続的であるかどうかを示す属性です。 5つの一般的な機能は以下のとおりです-
- 実行するコミットメント-実行するコミットメントはアクションを説明します。組織はプロセスが確立され、持続することを保証するために取らなければなりません。 通常、実行のコミットメントには、組織のポリシーと上級管理職のスポンサーシップの確立が含まれます。
- 実行する能力-実行する能力は、ソフトウェアプロセスを適切に実装するためにプロジェクトまたは組織に存在しなければならない前提条件について説明します。 実行能力には通常、リソース、組織構造、およびトレーニングが含まれます。
- 実行されたアクティビティ-実行されたアクティビティは、主要なプロセス領域を実装するために必要な役割と手順を説明しています。 通常、実行されるアクティビティには、計画と手順の確立、作業の実行、追跡、および必要に応じた修正アクションの実行が含まれます。
- 測定と分析-測定と分析では、プロセスを測定して測定値を分析する必要性について説明します。 通常、測定と分析には、実行されたアクティビティのステータスと有効性を判断するために実行できる測定の例が含まれています。
- 実装の検証-実装の検証では、確立されたプロセスに従ってアクティビティが実行されることを確認する手順について説明します。 検証には通常、管理者によるレビューと監査とソフトウェア品質保証が含まれます。
共通機能「実行されるアクティビティ」のプラクティスは、プロセス機能を確立するために何を実装する必要があるかを説明しています。 全体としてとられた他のプラクティスは、組織が「実行されたアクティビティ」の共通機能で説明されているプラクティスを制度化できる基盤を形成します。
プロセス領域の詳細
CMMIには、企業プロセスでカバーされる製品開発の側面を示す22のプロセス領域が含まれています。
原因分析と解決
- 成熟度レベル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セレクトソリューション
統合プロジェクト管理+ IPPD
- これは、成熟度レベル3のプロジェクト管理プロセスエリアです。
目的
*Integrated Project Management + IPPD* （IPM）の目的は、組織の一連の標準プロセスから調整された統合され定義されたプロセスに従って、プロジェクトと関連する利害関係者の関与を確立および管理することです。目標別の実践
- SG 1プロジェクトの定義済みプロセスを使用する
- SP 1.1プロジェクトの定義済みプロセスを確立する
- SP 1.2プロジェクト活動の計画に組織プロセス資産を使用する
- SP 1.3プロジェクトの作業環境を確立する
- SP 1.4計画の統合
- SP 1.5統合プランを使用したプロジェクトの管理
- SP 1.6組織プロセス資産への貢献
- SG 2関連する利害関係者との調整と協力
- SP 2.1利害関係者の関与の管理
- SP 2.2依存関係の管理
- SP 2.3調整の問題を解決する
IPPD追加-
- SG 3 IPPD原則の適用
- SP 3.1プロジェクトの共有ビジョンを確立する
- SP 3.2統合チーム構造の確立
- SP 3.3統合チームへの要件の割り当て
- SP 3.4統合チームを確立する
- SP 3.5インターフェースチーム間のコラボレーションを確保する
測定と分析
成熟度レベル2のサポートプロセスエリアです。
目的
測定と分析（MA）の目的は、管理情報のニーズをサポートするために使用される測定機能を開発および維持することです。
目標別の実践
- 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結果の伝達
組織の革新と展開
これは、成熟度レベル5のプロセス管理プロセスエリアです。
目的
組織の革新と展開（OID）の目的は、組織のプロセスと技術を測定可能な程度に改善する漸進的で革新的な改善を選択して展開することです。 この改善は、組織のビジネス目標から導き出された組織の品質およびプロセスパフォーマンスの目標をサポートします。
目標別の実践
- SG 1セレクトの改善
- SP 1.1改善提案の収集と分析
- SP 1.2イノベーションの特定と分析
- SP 1.3パイロットの改善
- SP 1.4 Selectの展開の改善点
- SG 2展開の改善
- SP 2.1展開領域を計画する
- SP 2.2展開の管理
- SP 2.3改善効果の測定
組織プロセス定義+ IPPD（OPD）
これは、成熟度レベル3のプロセス管理プロセスエリアです。
目的
- 組織プロセス定義+ IPPD *（OPD）の目的は、組織プロセス資産の使用可能なセットを確立および維持することです。
目標別の実践
- SG 1組織プロセス資産の確立
- SP 1.1標準プロセスの確立
- SP 1.2ライフサイクルモデルの説明の確立
- SP 1.3調整基準とガイドラインの確立
- SP 1.4組織の測定リポジトリを確立する
- SP 1.5組織のプロセス資産ライブラリを確立する
IPPD追加-
- SG 2 IPPD管理を有効にする
- SP 2.1エンパワーメントメカニズムの確立
- SP 2.2統合チームのルールとガイドラインを確立する
- SP 2.3バランスチームとホーム組織の責任
組織プロセスの焦点
これは、成熟度レベル3のプロセス管理プロセスエリアです。
目的
*Organizational Process Focus* （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プロセス関連の経験を組織プロセス資産に組み込む
組織プロセスのパフォーマンス
これは、成熟度レベル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 Provide Objective Insight
- 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選択したサブプロセスのパフォーマンスの監視
- SP 2.4統計管理データの記録
要件開発
これは、成熟度レベル3のエンジニアリングプロセスエリアです。
目的
要件開発（RD）の目的は、顧客、製品、および製品コンポーネントの要件を作成および分析することです。
目標別の実践
- SG 1開発顧客要件
- SP 1.1 Elicit Needs
- 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のプロジェクト管理プロセスエリアです。
目的
*Risk Management* （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サプライヤー契約の確立M
- SP 1.1集録タイプの決定
- SP 1.2サプライヤの選択
- SP 1.3サプライヤー契約の確立
- SG 2サプライヤ契約を満たす
- SP 2.1サプライヤ契約の実行
- SP 2.2選択したサプライヤプロセスの監視
- SP 2.3選択したサプライヤ作業成果物の評価
- SP 2.4取得した製品を受け入れる
- SP 2.5移行製品
テクニカルソリューション
これは、成熟度レベル3のエンジニアリングプロセスエリアです。
目的
テクニカルソリューション（TS）の目的は、要件に対するソリューションを設計、開発、および実装することです。 ソリューション、設計、および実装には、製品、製品コンポーネント、および製品関連のライフサイクルプロセスが単一または適切に組み合わせて含まれます。
目標別の実践
- SG 1 Select製品コンポーネントソリューション
- SP 1.1代替ソリューションと選択基準の開発
- SP 1.2 Select製品コンポーネントソリューション
- 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 Perform Peerレビュー
- SP 2.1ピアレビューの準備
- SP 2.2ピアレビューの実施
- SP 2.3ピアレビューデータの分析
- SG 3選択した作業成果物の検証
- SP 3.1検証の実行
- SP 3.2検証結果の分析
バージョン1.2に加えられた変更
ここでは、一連のプロセス領域に加えられた変更のみが考慮されます。 包括的な詳細については、https://www.sei.cmu.edu/[SEIホームページ]をご覧ください。
- 次のプロセス領域が削除されました（すべて成熟度レベル3）-
- 統合のための組織環境（OEI）
- 統合チーミング（IT）
- 統合サプライヤー管理（ISM）
- 次の追加が既存のプロセスエリア内で行われました-
- IPM SG3とSG4は廃止され、新しいSG3が追加されました（すべてのIPPD PA）
- OPD SGが追加され、IPPD PAになりました
- OPF 2つのSPがSGから抽出され、2つの新しいSPと一緒にSG3を作成しました
- REQD SP3.5はValidate Requirementsという名前に変更されました
- SAM SP2.1は廃止され、2つの新しいSPがSG2に追加されました
- TS . SP1.2は廃止されました
- VER。 SP3.2は、検証結果の分析に名前が変更されました。
CMMI-評価
CMMI評価は、組織の長所と短所を判断するための基準として評価基準モデルを使用して、訓練された専門家チームによる1つ以上のプロセスの検査です。
評価には計画が必要です。 組織の評価を計画するときは、組織部門の範囲を決定します。これには、評価するチームが組織の内部または外部のメンバーで構成されるかどうか、含めるプロジェクト、インタビューする個人、およびタイプまたは評価のクラスが必要です。
評価では、CMMIで定義されているモデルコンポーネントの3つのカテゴリを検討します-
- 必須-特定および汎用の目標のみ。
- 期待-特定および一般的なプラクティスのみ。
- 参考-サブプラクティスと典型的な作業成果物が含まれています。
SEIはCMMI評価のための2つのガイド文書をリリースしました-
- * CMMI（ARC）の評価要件*-評価方法のクラスA、クラスB、およびクラスCの3つのクラスの要件が含まれています。 これらの要件は、評価方法の各クラスを定義するためのルールです。
- プロセス改善のための標準的なCMMI評価方法（SCAMPI）-メソッド記述文書（MDD）は現在、唯一の承認されたクラスA評価方法です。
SCAMPIは現在、唯一の承認済みCMMIクラスA評価方法です。 つまり、SCAMPIはARCクラスA評価方法のすべての要件を満たし、SEIによって承認されています。
CMMI評価方法には、クラスA、クラスB、およびクラスCの3つのクラスがあります。
SCAMPIクラスA評価
SCAMPIクラスAの評価は、通常、組織が多数の重要なプロセスの改善を実施し、CMMIに関連してそのプロセスを正式にベンチマークする必要があるときに行われます。 SCAMPI Aは、CMMI成熟度レベルまたは能力レベルの評価を提供する唯一の評価方法です。
あなたはSCAMPI Aから次の結果を期待することができます-
- 成熟度評価または能力レベル評価。
- CMMIに対する組織のプロセスの長所と短所を説明する調査結果。
- 組織の主要なプロセスの問題に関するコンセンサス。
- 組織がプロセス改善の進捗状況を監視し、将来の評価をサポートするために引き続き使用できる評価データベース。
SCAMPIクラスB評価
SCAMPI Bは、組織がターゲットCMMI成熟度レベルへの進捗を評価する必要があるが、SCAMPI Aよりも低コストで必要な場合に必要です。 SCAMPI B評価は詳細な調査結果を提供し、評価されたプラクティスがSCAMPI A評価で十分に実装されていると評価される可能性を示します。
3つのSEI評価方法の1つであるSCAMPIクラスB評価は、組織がCMMIに関連するソフトウェアおよびシステムエンジニアリングプロセスの状態を比較的高い信頼度で理解するのに役立ちます。 SCAMPI Bは、組織がターゲットCMMI成熟度レベルに向けた進捗を正確に評価する必要がある場合に実行されることがよくあります。
あなたはSCAMPI Bから次の結果を期待することができます-
- CMMIに対する組織のプロセスの長所と短所を説明する詳細な調査結果。
- 検討された実践が目標を満たし、CMMIの意図を満たす可能性を示す実践特性。
- 組織の主要なプロセスの問題に関するコンセンサス。
- 組織がプロセス改善の進捗状況を監視し、将来の評価をサポートするために引き続き使用できるFIDOデータベース。
SCAMPIクラスC評価
SCAMPI Cの評価は、SCAMPI AおよびBの評価よりも短くて柔軟性があり、クイックギャップ分析からSCAMPI Aに対する組織の準備状況の決定まで、さまざまな特別なニーズに対応するために実施されます。
SEIの一連の評価方法の中で最も形式的でないSCAMPIクラスC評価は、柔軟性が高く、さまざまなニーズに対応するために実施できます。 通常、クラスAおよびBの評価よりも期間がはるかに短く、SCAMPI Cの評価は次のような理由で実行されることがよくあります-
- CMMIに関連する組織のプロセスの迅速なギャップ分析を提供します。
- 実装する前に、新しいプロセスの妥当性を評価します。
- プロセスの実装を監視します。
- SCAMPI Aに対する組織の準備を決定します。
- サプライヤーの選択をサポートします。
あなたはSCAMPI Cから次の結果を期待することができます-
- 評価されたプロセスの長所と短所を説明する調査結果。 評価の範囲と戦略に応じて、調査結果は関連するCMMIコンポーネントにマッピングされる場合があります。
- CMMIに対する評価されたプロセスの妥当性を要約する特性評価。
- 推奨されるプロセス改善アクション。
- 組織がプロセス改善の進捗状況を監視し、将来の評価をサポートするために引き続き使用できるFIDOデータベース。
評価クラスの特徴
各クラスは、メソッドのアプリケーションに関連する厳密さの程度によって区別されます。 クラスAは最も厳格で、クラスBはやや厳しくなく、クラスCは最も厳格ではありません。 次の表に、各クラスのメソッド間の予想される違いについての考えを示します。
| Characteristics | Class A | Class B | Class C |
|---|---|---|---|
| Amount of objective evidence gathered | High | Medium | Low |
| Rating generated | Yes | No | No |
| Resource needs | High | Medium | Low |
| Team size | Large | Medium | Small |
| Data sources (instruments, interviews, and documents) | Requires all three data sources | Requires only two data sources (one must be interviews) | Requires only one data source |
| Appraisal team leader requirement | Authorized Lead Appraiser | Authorized Lead Appraiser or person trained and experienced | Person trained and experienced |
SCAMPIの基礎
SCAMPIは、プロセス改善のための標準CMMI評価方法の略語です。 SCAMPI評価は、SEI認定のSCAMPIリード評価者が主導する必要があります。 SCAMPIは、SCAMPIメソッド記述、成熟度アンケート、作業支援、テンプレートを含むSCAMPI製品スイートでサポートされています。
現在、SCAMPIは評価を提供できる唯一の方法であり、SEIが認めている唯一の方法であり、組織にとって最も関心の高い方法です。
SCAMPIは、次のような以前の方法の経験に基づいています-
- CBA IPI -内部プロセス改善のためのCMMベースの評価。
- SCE -ソフトウェア機能評価。
- EIA/IS 732.2 -Systems Engineering Assessment Methodと題された暫定的な国際標準。
- SDCE -ソフトウェア開発能力評価。
- FAA評価法。
CMMIプレーヤー-役割の責任
この章では、プロセス改善の取り組みに関与する主要なプレーヤーについて説明します。 ただし、組織で必要なグループの数は増減する場合があります。
組織の規模とプロセス改善（PI）の努力の複雑さに応じて、1人でこれらの役割の多くを同時にまたは連続して果たすことができることに注意してください。
プロセス改善
プロセス改善の取り組みには、一般的に次の個人とグループが必要です-
- * PIスポンサー*-PIの取り組み全体を監督する責任を負う組織の人。 この人は一般に、資金と人員を割り当てる権限を持っています。 この人は通常、役員レベル以上です。
- * PIチャンピオン*-これは、PI活動の広報担当者であり、EPGリードとして働くこともあれば、そうでないこともあります。 この人物は、PIのアイデア、アプローチ、および結果をマーケティングします。
- エンジニアリングプロセスグループ（EPG）リード-この人はプロセスをレビューするグループをリードします。 この担当者は、EPGメンバーにタスクを割り当て、その努力を監視し、EPGの毎日の任務を計画します。
- * EPGメンバー*-これらの個人は、委員会メンバーとしてEPGに参加しています。 彼らは、プロセス改善の文書が作成され、遵守されることを保証する責任があります。 また、プロセス改善プロセスを追跡するためのメトリックを生成する責任もあります。 彼らはPATをリードしています。
- プロセスアクションチーム（PAT）-これらのチームは、プロセス改善のドキュメント、ポリシー、プロセス、手順、チャーター、およびアクションプランを生成します。
- 移行パートナー-通常、組織プロセス改善の進捗を設定、計画、リード、および監視するために外部のコンサルタントである1人または2人の個人が参加します。 これらの個人は、他のいくつかの組織や業界からプロセス改善を行った経験をもたらします。
CMMI-まとめ
このチュートリアルでは、次のコンポーネントで構成されるCMMIの構造をカバーしました-
- 成熟度レベル（段階的な表現）または能力レベル（連続的な表現）
- プロセスエリア
- 目標：一般的および具体的
- 共通の機能
- プラクティス：汎用および特定
すべての成熟度レベルと能力レベルをカバーしました。 さらに、すべての主要なプロセス領域と関連する一般的な目標、特定の目標、共通の機能および実践について説明しました。
後で、CMMI評価について簡単に紹介し、さまざまな評価クラスを紹介しました。
次は何ですか？
SEI CMMIは、小さなチュートリアルでは説明できない大きなテーマです。 したがって、他のCMMIリソースを調べて、このテーマに関する詳細情報を収集することを強くお勧めします。 これらのリソースは、CMMIリソースの章にリストされています。
フィードバックを[email protected]_に送信してください
CMMI-用語集
| A | B | C | D | E | F | G | H | I | J | K |
| L | M | N | O | P | Q | R | S | T | U | V |
| W | X | Y | Z |
[A]#
実行する能力-プロジェクトおよび/または組織に必要なリソースを確保することに関連する一般的な慣行をグループ化した段階的表現を持つCMMIモデルプロセス領域の共通機能。
受入基準-製品または製品コンポーネントがユーザー、顧客、またはその他の認可されたエンティティに受け入れられるために満たさなければならない基準。
受け入れテスト-ユーザー、顧客、またはその他の承認されたエンティティが製品または製品コンポーネントを受け入れるかどうかを決定できるようにするために実施された正式なテスト。
達成プロファイル-継続的な表現で、プロセス領域のリストと、対応する能力レベルは、能力レベルを進めながら各プロセス領域の組織の進捗状況を表します。
取得-契約を通じて、製品およびサービスの取得のために投資することを約束する取得エンティティによる個別のアクションまたはアクションの提案を取得するプロセス。
取得戦略-供給元、取得方法、要件仕様タイプ、契約または契約タイプ、および関連する取得リスクの考慮に基づいた製品およびサービスの取得に対する特定のアプローチ。
適切-すべてのレベルの管理者および実務家が組織のビジネス目標に照らして特定の一般的な目標と実践を解釈できるように、CMMIに適切で適切な必要に応じて表示されます。 たとえば、リスク管理のプロセス領域の一般的なプラクティスでは、「リスク管理プロセスを実行し、作業成果物を開発し、プロセスのサービスを提供するための適切なリソースを提供します」と述べています。多くの人々、リスクを監視しなければならない人々などによって十分に満足できるでしょう。
高度なプラクティス-継続的な表現では、能力レベルが2以上のすべての特定のプラクティス。
契約/契約要件-買収に関連するすべての技術的および非技術的要件。
割り当てられた要件-下位レベルのアーキテクチャ要素または設計コンポーネントに、上位レベルの要件のパフォーマンスと機能のすべてまたは一部を課す要件。
代替プラクティス-CMMIモデルに含まれる1つまたは複数の一般的または特定のプラクティスの代替であり、モデルプラクティスに関連する一般的または特定の目標を満たすために同等の効果を達成するプラクティス。 代替プラクティスは、必ずしも一般的または特定のプラクティスを1対1で置き換えるものではありません。
評価-評価は、長所と短所を決定するための基礎として評価基準モデルを使用して、訓練された専門家チームによる1つ以上のプロセスの検査です。
評価結果-評価範囲内の最も重要な問題、問題、または機会を特定する評価の結論。 少なくとも、有効な観測に基づく長所と短所が含まれます。
評価参加者-評価中に情報の提供に参加する組織単位のメンバー。
評価の評価-CMMI評価資料で使用される、（1）CMMIの目標またはプロセスエリア、（2）プロセスエリアの能力レベル、または（3）の成熟レベルのいずれかに評価チームによって割り当てられる値組織単位。 評価は、採用されている評価方法に対して定義された評価プロセスを実施することにより決定されます。
評価基準モデル-CMMI評価資料で使用されているように、評価チームが実装されたプロセス活動と相関させるCMMIモデル。
評価範囲-組織の制限とCMMIモデルの制限を含む評価の境界の定義。
評価チームのリーダー-評価の活動を主導し、評価方法で定義された経験、知識、スキルの資格基準を満たしている人。
適切-適切な定義を参照してください。
必要に応じて-適切な定義を参照してください。
評価-評価とは、プロセス改善の目的で組織が自ら実施する評価です。
プロセスの変動の原因-CMMIでは、一貫性を確保するために、「プロセスの変動の特定の原因」という用語が「プロセスの変動の原因」の代わりに使用されます。 両方の用語は同じように定義されます。
監査-要件が満たされているかどうかを判断するための作業成果物または作業成果物のセットの独立した検査。
[B]#
ベースメジャー-エンティティの明確なプロパティまたは特性、およびそれを定量化する方法。
基本プラクティス-継続的な表現では、能力レベル1のすべての特定のプラクティス。
ベースライン-ベースラインという用語は、通常、そのような基準点を示すために使用されます。 ベースラインは、開発ライフサイクルの適切な時点でのシステムの承認されたスナップショットです。 ベースラインは、後続の変更を定義するための正式なベースを確立します。 この線または基準点がなければ、変化の概念は無意味です。
ビジネス目標-組織の存続を確保し、収益性、市場シェア、および組織の成功に影響を与えるその他の要因を強化するために設計された上級管理者が開発した戦略。
[C]#
能力評価-サプライヤーの選択、契約の監視、またはインセンティブのための差別者として使用される専門家の訓練されたチームによる評価。 評価は、意思決定者がより良い買収決定を下し、下請業者のパフォーマンスを向上させ、購買組織に洞察を提供するために使用されます。
能力レベル-個々のプロセス領域内のプロセス改善の達成。 能力レベルは、プロセス領域の適切な特定の一般的な慣行によって定義されます。
能力レベルのプロファイル-連続表現では、プロセス領域とそれに対応する能力レベルのリスト。 プロファイルは、能力レベルを進めながら各プロセス領域の組織の進捗を表す場合、達成プロファイルである場合があります。 または、プロセス改善の目的を表す場合、プロファイルはターゲットプロファイルである場合があります。
能力成熟度モデル-能力成熟度モデル（CMM）には、1つ以上の分野の効果的なプロセスの重要な要素が含まれています。 また、アドホックで未熟なプロセスから、改善された品質と有効性を備えた統制された成熟したプロセスへの進化的改善パスについても説明しています。
対応プロセス-指定された製品品質、サービス品質、およびプロセスパフォーマンスの目標を満たすことができるプロセス。
原因分析-欠陥の原因を特定するための欠陥の分析。
変更管理-製品またはサービスに変更または提案された変更をもたらす手段の賢明な使用。
- CMMI評価調整*-特定のインスタンスで使用する評価方法内のオプションの選択。 評価調整の目的は、組織がメソッドの適用をビジネス目標に合わせるのを支援することです。
- CMMIモデルコンポーネント*-CMMIモデルを構成する主要なアーキテクチャ要素のいずれか。 CMMIモデルの主な要素には、特定のプラクティス、一般的なプラクティス、特定の目標、一般的な目標、プロセス領域、機能レベル、成熟度レベルが含まれます。
- CMMIモデルの調整*-特定のアプリケーションに適合させるためにCMMIモデルのサブセットを使用すること。 モデル調整の目的は、組織がモデルの適用をビジネス目標に合わせるのを支援することです。
- CMMI製品スイート*-この用語は、完全なCMMIフレームワークに使用されています。
実行へのコミットメント-ポリシーの作成とスポンサーシップの保護に関連する一般的なプラクティスをグループ化した段階的表現を持つCMMIモデルプロセス領域の共通機能。
プロセス変動の一般的な原因-プロセスのコンポーネント間の通常および予想される相互作用のために存在するプロセスの変動。
操作の概念-エンティティが使用または操作される方法の一般的な説明。
構成監査-構成アイテムが指定された標準または要件に準拠していることを確認するために実施される監査。
構成ベースライン-製品または製品コンポーネントの寿命中の特定の時間に正式に指定された構成情報。 構成ベースラインと、それらのベースラインから承認された変更は、現在の構成情報を構成します。
構成制御-構成識別の正式な確立後の構成アイテムへの変更の評価、調整、承認または不承認、および実装で構成される構成管理の要素。
構成管理ボード-構成アイテムへの提案された変更を評価、承認、または不承認にし、承認された変更を確実に実装する担当者のグループ。
構成の識別-製品の構成アイテムを選択し、それらに一意の識別子を割り当て、それらの機能的および物理的特性を技術文書に記録することで構成される構成管理の要素。
構成アイテム-構成管理用に指定され、構成管理プロセスで単一のエンティティとして扱われる作業成果物の集合。
構成管理-（1）構成アイテムの機能的および物理的特性の識別と文書化、（2）それらの特性への変更の制御、（3）変更の処理と実装の記録と報告（4）指定された要件への準拠を確認します。 [IEEE Std 610.1990]
- CMMIモデル*-CMMIフレームワークは、それを使用する組織のニーズに基づいて異なるモデルを生成できるため、複数のCMMIモデルがあります。 その結果、「CMMI MODEL」というフレーズは、多くの情報のコレクションのいずれかになります。 「CMMIモデル」という語句は、CMMIフレームワークから生成可能なモデルの1つ、一部、または全体のコレクションを指します。
構成ステータスのアカウンティング-構成を効果的に管理するために必要な情報の記録と報告で構成される構成管理の要素。 この情報には、承認された構成識別のリスト、構成に対する提案された変更のステータス、および承認された変更の実装ステータスが含まれます。
連続表現-能力成熟度モデル構造。能力レベルは、指定された各プロセス領域内のプロセス改善に近づくための推奨順序を提供します。
是正措置-状況の改善、エラーの除去、または状態の調整に使用される行為または行為。
*COTS* -商用ベンダーから購入できるアイテム。顧客-顧客は、製品の受け入れまたは支払いの承認を担当する個人、プロジェクト、組織、グループなどです。 顧客はプロジェクトの外部にいますが、必ずしも組織の外部にいるわけではありません。 顧客という用語は、要件の収集や抽出について議論するときに変数としても機能します。
[D]#
データ管理-データの共有と管理のための原則、プロセス、およびシステム。
欠陥密度-製品サイズの単位あたりの欠陥数（例：コード1000行ごとの問題報告）。
定義されたプロセス-改善の一部として従うべき定義された一連のステップ。
派生メジャー-2つ以上のベースメジャーの数学関数から得られたデータ。
派生要件-顧客の要件に明示的に記載されていないが、（1）コンテキスト要件（例：適用可能な標準、法律、ポリシー、一般的な慣行、管理決定）から、または（2）必要な要件から推測される要件製品コンポーネントを指定します。 派生要件は、製品またはシステムのコンポーネントの分析および設計中にも発生する可能性があります。
設計レビュー-設計要件およびこれらの要件を満たす設計の能力を評価し、問題を特定して解決策を提案するための設計の正式な文書化された包括的かつ体系的な検査。
開発-開発はCMMI全体で使用されるため、メンテナンスアクティビティと開発アクティビティを意味します。 組織がエンジニアリングの卓越性を追求している場合、開発プロジェクトと保守プロジェクトの両方にベストプラクティスを適用する必要があることが経験からわかっています。
開発計画-1つまたは複数の製品の設計と開発をガイド、実装、および制御するための計画。
実装の指示-プロセスのパフォーマンスの管理、作業成果物の整合性の管理、および関連する利害関係者の関与に関連する一般的なプラクティスをグループ化した段階的表現を備えたCMMIモデルプロセス領域の共通機能。
規律増幅-特定の分野（システムエンジニアリング、ソフトウェアエンジニアリングなど）のモデル情報を解釈するためのガイダンスを提供するモデルコンポーネントは、「DISCIPLINE AMPLIFICATIONS」と呼ばれます。必要に応じて、他のモデルコンポーネントに規律増幅が追加されます。 これらは、ページの右側に表示され、対処する分野を示すタイトル（「ソフトウェアエンジニアリング」など）があるため、簡単に見つけることができます。
ドキュメント-ドキュメントは、記録されるメディアに関係なく、データのコレクションです。 通常、永続性があり、人間または機械で読み取ることができます。 文書には、紙の文書と電子文書の両方が含まれます。
[E]#
エンタープライズ-エンタープライズは、さまざまな顧客のさまざまな場所にある多くの組織で構成される非常に大きな企業を指すために使用されます。
エントリー基準-努力が成功する前に存在しなければならない状態。
同等のステージング-同等のステージングは、ターゲットステージングを使用した結果をステージングされた表現の成熟度レベルと比較できるように定義された連続表現を使用して作成されたターゲットステージングです。
終了基準-努力が正常に終了する前に存在しなければならない状態。
期待されるCMMIコンポーネント-必要なCMMIコンポーネントを満たすために何ができるかを説明するCMMIコンポーネント。 モデルユーザーは、予想されるコンポーネントを明示的に実装するか、これらのコンポーネントと同等の代替プラクティスを実装できます。 特定の一般的なプラクティスは、予想されるモデルコンポーネントです
[F]#
検索-評価結果を参照してください。
正式な評価プロセス-意思決定分析および解決プロセスの領域では、導入ノートの「正式な評価プロセス」の定義を参照してください。
機能分析-定義された機能を検査して、その機能の達成に必要なすべてのサブ機能を特定します。機能的関係とインターフェース（内部および外部）の識別と、機能的アーキテクチャーにおけるこれらのキャプチャー。上位レベルのパフォーマンス要件のフローダウン、およびこれらの要件の下位レベルのサブ機能への割り当て。
機能アーキテクチャ-機能の階層的配置、それらの内部および外部（集約自体の外部）機能インターフェイスおよび外部物理インターフェイス、それぞれの機能要件およびパフォーマンス要件、および設計制約。
[G]#
ジェネリックゴール-ジェネリックゴールは、複数のプロセスエリアに同じゴールステートメントが表示されるため、「ジェネリック」と呼ばれます。 段階的な表現では、各プロセス領域には1つの一般的な目標のみがあります。 プロセス領域での一般的な目標の達成は、そのプロセス領域に関連付けられたプロセスの計画と実装における制御の改善を意味し、これらのプロセスが効果的で、繰り返し可能で、持続する可能性が高いかどうかを示します。 一般的な目標は必須のモデルコンポーネントであり、評価でプロセス領域が満たされているかどうかを判断するために使用されます。
一般的なプラクティス-一般的なプラクティスは、プロセス領域に関連するプロセスが効果的で、繰り返し可能で、持続することを保証する制度化を提供します。 ジェネリックプラクティスは、ジェネリックゴールと共通の機能によって分類され、CMMIモデルで期待されるコンポーネントです。 （一般的な練習タイトル、ステートメント、および詳細のみがプロセス領域に表示されます。）
一般的な練習の詳細-特定の練習の後、プロセス領域に適用される一般的な練習のタイトルと説明が表示されます。 各一般的な実践の説明の後に、詳細が「詳細」という見出しのプレーンテキストで表示される場合があります。 GENERIC PRACTICE ELABORATIONは、プロセス領域に対する一般的な慣行の解釈方法に関する情報を提供します。 精緻化が存在しない場合、一般的な慣行の適用は精緻化なしで明らかです。
目標-「目標」は、一般的な目標または特定の目標のいずれかになり得る必須のCMMIコンポーネントです。 CMMIモデルで「目標」という単語が表示されている場合、それは常にモデルコンポーネント（一般的な目標、特定の目標など）を指します。
[H]#
不完全なプロセス-実行されない、または部分的にのみ実行されるプロセス（機能レベル0とも呼ばれます）。 プロセス領域の特定の目標の1つ以上が満たされていません。
独立グループ-プロセスおよび製品品質保証プロセス領域では、導入ノートの「独立グループ」の説明を参照してください。
有益なCMMIコンポーネント-モデルのユーザーがモデルの必須および予想されるコンポーネントを理解するのに役立つCMMIコンポーネント。 これらのコンポーネントには、例、詳細な説明、またはその他の役立つ情報が含まれている場合があります。 サブプラクティス、メモ、リファレンス、目標タイトル、プラクティスタイトル、ソース、典型的な作業成果物、規律の拡大、および一般的な練習の詳細化は、有益なモデルコンポーネントです。
*Institutionalization* -組織が企業文化の一部として定期的に従うビジネスを行う染み込んだ方法。統合された製品およびプロセス開発-製品開発への体系的なアプローチにより、製品のライフサイクル全体で関連する利害関係者とのタイムリーなコラボレーションを実現し、顧客のニーズによりよく応えます。
統合チーム-タイムリーなコラボレーションで特定の作業成果物を提供することにコミットしている補完的なスキルと専門知識を持つ人々のグループ。 統合されたチームメンバーは、作業成果物のすべての段階に適切なスキルとアドボカシーを提供し、指定されたとおりに作業成果物を提供する責任を共同で負います。 統合チームには、成果物の成功に関係する組織、専門分野、および機能の権限を与えられた代表者を含める必要があります。
インターフェース制御-構成管理において、（1）1つ以上の組織によって提供される2つ以上の構成アイテムのインターフェースに関連するすべての機能的および物理的特性を特定し、（2）これらの特性に対して提案された変更を確実にするプロセス実装前に評価および承認されます。 [IEEE 828-1983]。
- [#J]"/></emphasis>#[J][#K][#L]'#
リード評価者-CMMI製品スイートで使用されるように、特定の評価方法の評価チームリーダーとして実行するために、認可機関からの認識を達成した人。
ライフサイクルモデル-製品のライフをフェーズに分割し、プロジェクトが顧客のニーズの特定から製品の廃止までを導く。
[M]#
マネージャー-プロジェクトマネージャーは、プロジェクトの計画、指揮、管理、構築、および動機付けを担当します。 彼または彼女は、彼または彼女の責任範囲内でプロジェクトのタスクまたはアクティビティを実行する人に技術的および管理的な指示と制御の両方を提供できます。 プロジェクトマネージャーは最終的に顧客に責任を負います。
成熟度-セット内のすべての目標が達成される、事前に定義された一連のプロセス領域全体のプロセス改善の程度。
同意書-拘束力のある文書または2つ以上の当事者間の合意。
[N]#
自然境界-プロセスパフォーマンスの測定値に反映される固有のプロセス。「プロセスの声」とも呼ばれます。管理図、信頼区間、予測区間などの手法を使用して、変動が一般的な原因によるものなのか（つまり、プロセスが予測可能または「安定」なのか）、特定できる特定の原因によるのかを特定し、削除されました。
非開発アイテム-買収または開発プロセスで現在使用する前に開発された供給アイテム。 このようなアイテムは、現在の使用目的の要件を満たすために、わずかな修正が必要になる場合があります。
非技術的要件-製品またはサービスの取得方法に影響する契約条項、コミットメント、条件、および条件。 例には、配達される製品、配達された市販の（COTS）非開発品目（NDI）のデータ権、配達日、終了基準を伴うマイルストーンが含まれます。 その他の非技術的な要件には、トレーニング要件、サイト要件、および展開スケジュールが含まれます。
[O]#
目的-目的という用語は、日常の一般的な意味でCMMIで使用されます。これが私たちの達成すべき目標です。
客観的証拠-CMMI評価資料、定性的または定量的情報、記録、または項目またはサービスの特性に関する、または観察、測定に基づくプロセス要素の存在と実装に関する事実の記述で使用される、またはテストで検証可能です。
客観的に評価-レビューアによる主観性と偏見を最小限に抑える基準に照らして、アクティビティと作業成果物をレビューします。 客観的評価の例は、独立した品質保証機能による要件、標準、または手順に対する監査です。
観察-CMMIの評価資料で使用されるように、評価チームのメンバーが評価データ収集活動中に見たり聞いたりした情報を理解していることを表す書面による記録。 書面による記録は、声明の形をとることも、情報内容が保存されている限り別の形をとることもあります。
操作上の概念-エンティティが使用または操作される方法の一般的な説明。
運用シナリオ-製品の環境およびユーザーとの相互作用、および製品コンポーネント間の相互作用を含む、想定される一連のイベントの説明。 運用シナリオは、システムの要件と設計を評価し、システムを検証および検証するために使用されます。
プロセスの最適化-プロセスに固有の変動の一般的な原因の理解に基づいて改善された定量的に管理されたプロセス。 段階的な改善と革新的な改善の両方を通じて、プロセスパフォーマンスの範囲を継続的に改善することに焦点を当てたプロセス。
組織-組織は、人々が1つ以上のプロジェクトを全体としてまとめて管理し、そのプロジェクトが上級管理者を共有し、同じポリシーの下で運営される構造です。
組織の事業目標-組織の存続を確保し、その収益性、市場シェア、および組織の成功に影響を与えるその他の要因を強化するために上級管理職によって開発された戦略。
- 組織の成熟度-組織が文書化、管理、測定、制御、および継続的に改善されるプロセスを明示的かつ一貫して展開した程度。 組織の成熟度は、評価によって測定できます。
組織ポリシー-意思決定に影響を与え、決定するために組織が採用する、一般的に上級管理職によって確立された指針。
組織単位-評価の対象となる組織の部分（評価の組織範囲とも呼ばれます）。組織単位は、一貫したプロセスコンテキストを持ち、一貫したセット内で動作する1つ以上のプロセスを展開します。ビジネス目標。 通常、組織単位は大規模な組織の一部ですが、小規模な組織では組織単位が組織全体になる場合があります。
アウトソーシング-契約を通じて、製品およびサービスの取得のために投資することを約束する個別のアクションまたは取得エンティティによるアクションの提案を取得するプロセス。
[P]#
ピアレビュー-成果物の欠陥を見つけるためにピアによって行われたレビュー。
パフォーマンスパラメータ-進行性の開発をガイドおよび制御するために使用される有効性の尺度およびその他の主要な尺度。
実行済みプロセス-特定された入力作業成果物（機能レベル1とも呼ばれる）を使用して、特定された出力成果物を生成するために必要な作業を達成するプロセス。 プロセス領域の特定の目標は満たされています。
計画されたプロセス-説明と計画の両方によって文書化されたプロセス。 説明と計画を調整する必要があり、計画には標準、要件、目的、リソース、割り当てなどを含める必要があります。
プロセス-人々がシステムおよび関連製品の開発と保守に使用する一連のアクティビティ、方法、実践、および変換。
プロセスアクションプラン-組織プロセスフォーカスプロセス領域では、導入ノートの「プロセスアクションプラン」の定義を参照してください。
プロセスアクションチーム-プロセス改善アクションプランに記載されているように、組織のプロセス改善活動を開発および実装する責任を持つチーム。
プロセスと技術の改善-組織の革新と展開プロセスの領域で、導入ノートの「プロセスと技術の改善」の説明を参照してください。
プロセス領域-プロセス領域は、領域内の関連するプラクティスのクラスターであり、集合的に実行された場合、その領域を大幅に改善するために重要と考えられる一連の目標を満たします。 すべてのCMMIプロセス領域は、連続表現と段階的表現の両方に共通です。 段階的表現では、プロセス領域は成熟度レベル別に整理されます。
プロセス資産-プロセス領域の目標を達成する上で組織が有用と考えるすべてのもの。
プロセス資産ライブラリ-組織またはプロジェクトで使用できるプロセス資産保有のコレクション。
プロセス属性-プロセスに適用可能なプロセス能力の測定可能な特性。
プロセス能力-プロセスに従うことで達成できる期待される結果の範囲。
プロセスコンテキスト-評価の評価の判断と比較可能性に影響を与える、評価の入力で文書化された一連の要因。 これらには、評価される組織単位のサイズが含まれますが、これに限定されません。組織単位の人口統計。製品またはサービスの申請規律。製品またはサービスのサイズ、重要度、および複雑さ。製品またはサービスの品質特性。
プロセス定義-プロセスを定義および説明する行為。 プロセス定義の結果は、プロセスの説明です。
プロセスの説明-特定の目的を達成するために実行される一連のアクティビティの文書化された表現であり、プロセスの主要コンポーネントの運用上の定義を提供します。 ドキュメントは、プロセスの要件、設計、動作、またはその他の特性を、完全かつ正確で検証可能な方法で指定します。 また、これらの規定が満たされているかどうかを判断するための手順を含めることもできます。 プロセスの説明は、アクティビティ、プロジェクト、または組織レベルで見つけることができます。
プロセス要素-プロセスの基本単位。 プロセスは、サブプロセスまたはプロセス要素の観点から定義できます。 サブプロセスはさらに分解できます。プロセス要素はできません。 各プロセス要素は、密接に関連する一連のアクティビティ（たとえば、推定要素、ピアレビュー要素）を対象としています。 プロセス要素は、完成するテンプレート、洗練される抽象化、または修正または使用される説明を使用して描写できます。 プロセス要素は、アクティビティまたはタスクです。
プロセスグループ-組織が使用するプロセスの定義、保守、改善を促進する専門家の集まり。
プロセス改善-組織のプロセスのパフォーマンスと成熟度、およびそのようなプログラムの結果を改善するために設計された活動のプログラム。
プロセス改善目標-結果の製品特性（品質、性能、標準への適合など）の観点から、または特定の測定可能な方法で既存のプロセスを改善する努力を導くために確立されたターゲット特性のセットプロセスの実行方法（たとえば、冗長なプロセスステップの削除、プロセスステップの結合、サイクルタイムの改善など）
プロセス改善計画-組織プロセス中心のプロセス領域では、導入ノートの「プロセス改善計画」の定義を参照してください。
プロセス測定-プロセスの特性評価と理解を目的として、プロセスとその結果の製品の測定に使用される定義、方法、およびアクティビティのセット。
プロセス所有者-プロセスの定義と維持を担当する人（またはチーム）。 組織レベルでは、プロセス所有者は標準プロセスの説明を担当する人（またはチーム）です。プロジェクトレベルでは、プロセスの所有者は、定義されたプロセスの説明を担当する人（またはチーム）です。 したがって、プロセスには、さまざまな責任レベルで複数の所有者がいる場合があります。
プロセスのパフォーマンス-プロセスに従うことによって達成された実際の結果の尺度。 それは、プロセス測定（例、労力、サイクル時間、欠陥除去効率）と製品測定（例、信頼性、欠陥密度、応答時間）の両方によって特徴付けられます。
プロセスパフォーマンスベースライン-プロセスを追跡することによって達成される実際の結果の文書化された特性評価。これは、実際のプロセスパフォーマンスと予想されるプロセスパフォーマンスを比較するためのベンチマークとして使用されます。
プロセスパフォーマンスモデル-プロセスおよびその成果物の属性間の関係の説明。これは、過去のプロセスパフォーマンスデータから開発され、プロジェクトから収集されたプロセスおよび製品指標を使用して調整され、達成される結果を予測するために使用されますプロセスに従う。
プロセス調整-特定の目的のためにプロセス記述を作成、変更、または適応させること。 たとえば、プロジェクトは、組織の一連の標準プロセスから定義済みプロセスを調整して、プロジェクトの目的、制約、および環境を満たします。
製品-製品は、プロセスに従うことの結果であり、顧客またはエンドユーザーへの配信を目的とした具体的な出力またはサービスと考えることができます。 製品は、契約に従って顧客に提供される作業製品でもあります。
製品コンポーネント-製品コンポーネントは通常、製品の下位レベルのコンポーネントであり、製品を「ビルド」するために統合されています。 製品コンポーネントは、顧客に納入される製品の一部であるか、製品の製造または使用に役立つ場合があります。 たとえば、携帯電話のバッテリーを製造する会社の場合、携帯電話のバッテリーは製品です。 携帯電話を製造および提供する企業にとって、バッテリーは製品コンポーネントです。
製品ベースライン-構成管理において、そのライフサイクルの生産、運用、保守、およびロジスティックサポート中に構成アイテムを定義する、最初に承認された技術データパッケージ（ソフトウェアの場合はソースコードリストを含む）。
製品コンポーネントの要件-製品コンポーネントの要件は、適合、形状、機能、性能、およびその他の要件を含む製品コンポーネントの完全な仕様を提供します。
製品ライフサイクル-作業製品は、ライフサイクルプロセスによって生成される任意のアーティファクトであり、ライフサイクル作業製品とも呼ばれます。 ライフサイクル作業製品には、要件仕様、インターフェース仕様、アーキテクチャ仕様、プロジェクト計画、設計ドキュメント、単体テスト計画、統合およびシステムテスト計画、製造製品の組み立てプロセスなどのプロセスを含めることができます。
プロジェクト-プロジェクトは、1つ以上の製品を顧客またはエンドユーザーに提供する相互に関連するリソースの管理セットです。 リソースのセットには明確な始まりと終わりがあり、計画に従って動作します。
製品ライン-選択した市場またはミッションの特定のニーズを満たす機能の共通の管理されたセットを共有する製品のグループ。
製品関連のライフサイクルプロセス-製造およびサポートプロセスなど、製品のライフフェーズの1つまたは複数のフェーズ全体（つまり、構想から廃棄まで）に関連付けられたプロセス。
製品要件-暗黙の要件を明示的な派生要件に変更する、開発者の言語への顧客要件の改良。
プログラム-（1）プロジェクト。 （2）目的、方法、活動、計画、成功基準など、関連プロジェクトとそれらをサポートするインフラストラクチャのコレクション。
プロジェクトマネージャー-プロジェクトマネージャーは、プロジェクトの計画、指示、管理、構築、および動機付けを担当します。 彼または彼女は、彼または彼女の責任範囲内でプロジェクトのタスクまたはアクティビティを実行する人に技術的および管理的な指示と制御の両方を提供できます。 プロジェクトマネージャーは最終的に顧客に責任を負います。 プロジェクトマネージャーは、プロジェクトの規模、多様性、複雑性が変化するにつれて、さまざまな役割と責任を負います。
プロジェクトの進捗状況とパフォーマンス-努力、コスト、スケジュール、技術的パフォーマンスなど、プロジェクト計画の実施に関してプロジェクトが達成するもの。
プロジェクトの定義済みプロセス-統合プロジェクト管理プロセス領域で、導入ノートおよび「プロジェクトの定義済みプロセスの確立」固有のプラクティスで「プロジェクトの定義済みプロセス」の定義を参照してください。
プロトタイプ-製品または製品コンポーネントの予備的なタイプ、フォーム、またはインスタンスで、後の段階または製品の最終的な完全バージョンのモデルとして機能します。
[Q]#
品質-製品、製品コンポーネント、またはプロセスの固有の特性のセットが顧客の要件を満たす能力。
品質保証-プロセスの標準、プラクティス、手順、および方法を定義した管理を保証するための計画的かつ体系的な手段が適用されます。
品質管理-品質の要件を満たすために使用される運用技術と活動。
定量的目標-定量的尺度として表される望ましい目標値。
定量的管理プロセス-統計的およびその他の定量的手法を使用して制御される定義済みプロセス。 製品の品質、サービスの品質、およびプロセスパフォーマンスの属性は、プロジェクト全体で測定および制御できます。
[R]#
参照モード-何らかの属性を測定するためのベンチマークとして使用されるモデル。
関連する利害関係者-関連する利害関係者は、特定の活動への関与が確認され、プロジェクト計画などの適切な計画に含まれる利害関係者を指定するために使用されます。
必須のCMMIコンポーネント-特定のプロセス領域でプロセス改善を達成するために不可欠なCMMIコンポーネント。 これらのコンポーネントは、評価でプロセス能力を決定するために使用されます。 特定の目標と一般的な目標は、必須のモデルコンポーネントです。
要件-（1）ユーザーが問題を解決したり目的を達成するために必要な条件または機能。 （2）契約、標準、仕様、またはその他の正式に課された文書を満たすために、製品または製品コンポーネントが満たすか所有しなければならない条件または機能。 （3）（1）または（2）のような条件または機能の文書化された表現。
要件分析-顧客のニーズ、期待、および制約の分析に基づいた製品固有のパフォーマンスと機能特性の決定。運用コンセプト;人、製品、およびプロセスの使用環境の予測。および有効性の尺度。
要件の引き出し-プロトタイプや構造化調査などの体系的な手法を使用して、顧客とエンドユーザーのニーズを積極的に特定し、文書化します。
要件管理-プロジェクトによって受信または生成されたすべての要件の管理。技術要件と非技術要件、および組織がプロジェクトに課した要件の両方を含みます。
要件のトレーサビリティ-要件とそのソース要件、その実装、および検証との間の関連付けの証拠。
投資収益率-生産コストに対する生産（製品）からの収益の比率。何かを生産するアクションを実行することで組織が利益を得るかどうかを決定します。
リスク分析-リスクの評価、分類、および優先順位付け。
リスクの識別-目標を達成する際に、起こりうるまたは現実的なリスクを見つけるための組織化された徹底的なアプローチ。
リスク管理-危害や損失を引き起こす可能性のあるものを特定し（リスクを特定）、特定したリスクを評価および定量化し、必要に応じてリスクの原因を予防または処理する適切なアプローチを開発および実装するための組織化された分析プロセス重大な損害または損失をもたらします。
リスク管理戦略-危害や損失を引き起こす可能性のあるものを特定し（リスクを特定）、特定したリスクを評価および定量化し、発生する可能性のあるリスクの原因を防止または処理する適切なアプローチを開発し、必要に応じて組織化した技術的アプローチ重大な損害または損失。 通常、リスク管理は、プロジェクト、組織、または製品開発組織単位に対して実行されます。
根本原因-根本原因は、除去された場合に欠陥が減少または除去されるような欠陥の原因です。
[S]#
上級管理職-CMMIで使用されている上級管理職という用語は、組織の十分に高いレベルでの管理役割を指し、人の主な焦点は短期ではなく組織の長期的な健康と成功です長期プロジェクトおよび契約上の懸念と圧力。 シニアマネージャーは、プロジェクトマネージャーが管理する多くのプロジェクトを含むプログラムの監視を担当する場合があります。
ソフトウェアエンジニアリング-（1）ソフトウェアの開発、運用、および保守に対する体系的で統制された、定量化可能なアプローチの適用。 （2）（1）のようなアプローチの研究。
勧誘-勧誘パッケージを準備し、サプライヤー（請負業者）を選択するプロセス。
勧誘パッケージ-入札（入札）および提案の要求（提案）の招待の申し出を要求するため、または能力と価格の見積り（引用）を要求するために使用される技術的および非技術的要件を描写する正式な文書。 それ以外の場合は、製品またはサービスを提供する供給元を選択するための基礎として使用されます。
プロセス変動の特別な原因-プロセスの固有の部分ではなく、一時的な状況に固有の欠陥の原因。
特定の目標-特定の目標はプロセス領域に適用され、プロセス領域を満たすために何を実装する必要があるかを記述する固有の特性に対処します。 特定の目標は必須のモデルコンポーネントであり、評価でプロセス領域が満たされているかどうかを判断するのに役立ちます。
特定のプラクティス-特定のプラクティスは、関連する特定の目標を達成する上で重要と考えられるアクティビティです。 特定のプラクティスは、プロセス領域の特定の目標の達成をもたらすと予想されるアクティビティを記述しています。 特定のプラクティスは、予想されるモデルコンポーネントです。
安定したプロセス-プロセスのプロセス変動の一般的な原因のみが残るように、プロセス変動のすべての特別な原因が除去され、再発が防止されている状態。
段階的表現-一連のプロセス領域の目標を達成することで成熟レベルを確立するモデル構造。各レベルは、後続のレベルの基盤を構築します。
利害関係者-利害関係者は、プロジェクトの結果によって影響を受ける、またはプロジェクトの活動や成果に影響を与える可能性のあるグループまたは個人です。
標準プロセス-組織内の共通プロセスの確立を導く基本プロセスの運用上の定義。 標準プロセスは、定義されたプロセスに組み込まれることが期待される基本的なプロセス要素を記述します。 また、これらのプロセス要素間の関係（順序やインターフェイスなど）についても説明します。
作業内容-プロジェクトを完了するために必要な契約作業の説明。
統計的予測可能性-統計的およびその他の定量的手法を使用して制御される定量的プロセスのパフォーマンス。
統計的プロセス制御-プロセスの変動の一般的および特殊な原因を特定し、プロセスパフォーマンスを制限内に維持する、プロセスの統計ベースの分析とプロセスパフォーマンスの測定。
統計手法-統計的手法（統計的プロセス制御、信頼区間、予測区間など）を使用する分析手法。
統計的に管理されたプロセス-プロセスが分析され、プロセス変動の特別な原因が特定され、パフォーマンスが明確に定義された制限内に含まれる統計ベースの手法によって管理されるプロセス。
強度-CMMI評価資料で使用される、CMMIモデルの実践の模範的または注目に値する実装。
サブプロセス-より大きなプロセスの一部であるプロセス。
サプライヤー-（1）取得する製品またはサービスを提供するエンティティ。 （2）契約（契約）の条件に基づいて、アイテムの設計、開発、製造、保守、修正、または供給の取得と契約（契約）を結んでいる個人、パートナーシップ、会社、企業、団体、またはその他のサービス）。
サステイン-エンドユーザーまたは顧客が製品を運用上利用できるようにするために使用されるプロセス。 維持により、製品が顧客またはエンドユーザーによって使用されているかどうかに関係なく、製品が動作可能な状態になるように保守が行われます。
システムエンジニアリング-顧客のニーズ、期待、制約のセットを製品ソリューションに変換し、製品ライフ全体を通じてそのソリューションをサポートするために必要な技術的および管理上の総努力を管理する学際的なアプローチ。 これには、技術的なパフォーマンス測定の定義、製品アーキテクチャの確立に向けたエンジニアリング専門分野の統合、およびコスト、パフォーマンス、およびスケジュールの目標のバランスをとるライフサイクルプロセスのサポートの定義が含まれます。
[T]#
調整ガイドライン-プロセスの調整は、特定のプロジェクトで使用するために、通常は組織レベルで記述されるプロセスの説明を作成、変更、または適合させます。 ほとんどの組織では、すべてのプロジェクトで1つの組織プロセス定義を100％遵守することはできません。 通常、ある程度の適応が必要です。 調整ガイドラインでは、変更できるものとできないものを説明し、変更の候補として許容されるプロセスコンポーネントを特定します。
ターゲットプロファイル-継続的な表現では、プロセス改善の目的を表すプロセス領域とそれに対応する能力レベルのリスト。
ターゲットステージング-継続的な表現で、組織が従うべきプロセス改善のパスを記述するターゲットプロファイルのシーケンス。
技術データパッケージ-製品および製品コンポーネントのタイプに適切な情報である場合、以下を含むアイテムのコレクション。
技術要件-取得または開発される製品またはサービスのプロパティ（属性）。
テスト手順-特定のテストの結果のセットアップ、実行、評価の詳細な手順。
貿易研究-決定された目標を達成するための最良の代替案を選択するための、基準と体系的分析に基づく代替案の評価
トレーニング-組織トレーニングプロセス領域で、.trainingの定義を参照してください。 導入ノートで。
[U]#
ユニットテスト-個々のハードウェアまたはソフトウェアユニットまたは関連ユニットのグループのテスト。
[V]#
検証-検証は、提供された製品（または提供される製品）が運用環境での意図された使用を満たすことを実証します。 検証により、「正しいものを構築した」ことが保証されます。
検証-検証には、顧客、製品、および製品コンポーネントの要件を含む、選択されたすべての要件に対する製品および中間作業製品の検証が含まれます。 検証は本質的に増分プロセスです。 要件の検証から始まり、進化する作業成果物の検証を経て、完成した製品の検証に至ります。 検証は、作業成果物が指定された要件を適切に反映しているかどうかに対処します。 検証により、「正しく構築された」ことが保証されます。
実装の検証-CMMIモデルプロセス領域の共通機能。段階的な表現で、上位レベルの管理によるレビューに関連する一般的なプラクティスと、プロセスの説明、手順、および標準への準拠の客観的評価をグループ化します。
バージョン管理-ベースラインの確立と維持、および以前のベースラインに戻ることを可能にするベースラインへの変更の識別。
[W]#
弱点-CMMI評価資料で使用されているように、1つまたは複数のCMMIモデルプラクティスの実装が無効である、または実装されていない
作業分解構造-作業要素の配置と、相互および最終製品との関係。
作業製品-作業製品という用語は、CMMI製品スイート全体で使用され、プロセスによって生成されるアーティファクトを意味します。 これらのアーティファクトには、ファイル、ドキュメント、製品の一部、サービス、プロセス、仕様、および請求書を含めることができます。 作業成果物と見なされるプロセスの例には、製品の製造プロセス、トレーニングプロセス、廃棄プロセスが含まれます。 WORK PRODUCTと製品コンポーネントの主な違いは、WORK PRODUCTを設計したり、最終製品の一部にする必要がないことです。
作業製品とタスクの属性-プロジェクト作業の見積もりに役立つ製品、サービス、プロジェクトタスクの特性。 これらの特性には、サイズ、複雑さ、重量、形、フィット、機能などの項目が含まれます。 これらは通常、他のプロジェクトおよびリソースの見積もり（労力、コスト、スケジュールなど）を導出するための1つの入力として使用されます
CMMI-頭字語
以下は、アルファベット順に並べられたすべてのCMMI頭字語のリストです。
| Acronym | Expanded Form |
|---|---|
| ARC | Appraisal Requirements for CMMI |
| CAF | CMM Appraisal Framework |
| CAR | Causal Analysis and Resolution (process area) |
| CAU | Cockpit Avionics Upgrade |
| CBA IPI | CMM-Based Appraisal for Internal Process Improvement |
| CBT | Computer-Based training |
| CCB | Configuration Control Board |
| CM | Configuration Management (process area) |
| CMM | Capability Maturity Model |
| CMMI | Capability Maturity Model Integration |
| CMMI-SE/SW | Capability Maturity Model Integration for Systems Engineering and Software Engineering |
| CMMI-SE/SW/IPPD | Capability Maturity Model Integration for Systems Engineering, Software Engineering, and Integrated Product and Process Development |
| CMMI-SE/SW/IPPD/SS | Capability Maturity Model Integration for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing |
| COTS | Commercial Off The Shelf |
| CPM | Critical Path Method |
| DAR | Decision Analysis and Resolution (process area) |
| EIA | Electronic Industries Alliance |
| EIA/IS | Electronic Industries Alliance Interim Standard |
| FAA | Federal Aviation Administration |
| FAA-iCMM | Federal Aviation Administration Integrated Capability Maturity Model |
| GG | Generic Goal |
| GP | Generic Practice |
| IDEAL | Initiating, Diagnosing, Establishing, Acting, Learning |
| IEEE | Institute of Electrical and Electronics Engineers |
| INCOSE | International Council on Systems Engineering |
| IPD-CMM | Integrated Product Development Capability Maturity Model |
| IPM | Integrated Project Management (process area) |
| IPPD | Integrated Product and Process Development |
| IPT | Integrated Product Team |
| ISM | Integrated Supplier Management (process area) |
| ISO | International Organization for Standardization |
| ISO/IEC | International Organization for Standardization and International Electro technical Commission |
| IT | Integrated Teaming (process area) |
| KSLOC | Thousand Source Lines of Code |
| MA | Measurement and Analysis (process area) |
| MOA | Memorandum of Agreement |
| NDI | Non Developmental Item |
| NDIA | National Defense Industrial Association |
| OEI | Organizational Environment for Integration (process area) |
| OID | Organizational Innovation and Deployment (process area) |
| OPD | Organizational Process Definition (process area) |
| OPF | Organizational Process Focus (process area) |
| OPP | Organizational Process Performance (process area) |
| OT | Organizational Training (process area) |
| OUSD/AT&L | Office of the Under Secretary of Defense, Acquisition, Technology, and Logistics |
| P-CMM | People Capability Maturity Model |
| PA | Process Area |
| PAIS | Process Appraisal Information System |
| PASS | Primary Avionics Software System |
| PERT | Program Evaluation and Review Technique |
| PI | Product Integration (process area) |
| PMC | Project Monitoring and Control (process area) |
| PP | Project Planning (process area) |
| PPQA | Process and Product Quality Assurance (process area) |
| QFD | Quality Function Deployment |
| QPM | Quantitative Project Management (process area) |
| RD | Requirements Development (process area) |
| REQM | Requirements Management (process area) |
| RSKM | Risk Management (process area) |
| SA-CMM | Software Acquisition Capability Maturity Model |
| SAM | Supplier Agreement Management (process area) |
| SCAMPI | Standard CMMI Appraisal Method for Process Improvement |
| SDMP | Software development management plan |
| SE | Systems Engineering |
| SE-CMM | Systems Engineering Capability Maturity Model |
| SEC | Software Executive Council |
| SECAM | Systems Engineering Capability Assessment Model |
| SECM | Systems Engineering Capability Model |
| SEI | Software Engineering Institute |
| SE/SW | Systems Engineering and Software Engineering |
| SEPG | Software Engineering Process Group |
| SG | Specific Goal |
| SP | Specific Practice |
| SPMN | Software Program Managers Network |
| SS | Supplier Sourcing |
| STSC | Software Technology Support Center |
| SW | Software Engineering |
| SW-CMM | Capability Maturity Model for Software |
| TS | Technical Solution (process area) |
| VAL | Validation (process area) |
| VER | Verification (process area) |
| WBS | Work Breakdown Structure |
SEI CMMI-有用なリソース
次のリソースには、CMMIに関する追加情報が含まれています。 このトピックに関する詳細な知識を得るためにそれらを使用してください。
CMMIの便利なリンク
- SEI CMMI-Software Engineering Instituteの公式ウェブサイト。
- https://www.iso.org [ISO.org]-国際標準化機構の公式ウェブサイト。
- Wikipedia-CMMIに関するWiki記事
- CMMI（ARC）の評価要件-カーネギーメロン大学ソフトウェア工学研究所（2001）。 2006年3月5日に取得。
- CMMI記事-CMMIおよびプロセス改善の記事。
CMMIに関する便利な本
このページにサイトを登録するには、 contact @ finddevguides.com にメールを送信してください。
