Cmmi-glossary
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つの入力として使用されます
