CMMI-用語集
| A | B | C | D | E | F | G | H | 私 | J | K |
| L | M | N | O | P | Q | R | S | T | U | V |
| W | バツ | Y | Z |
Ability to perform −プロジェクトや組織が必要なリソースを確実に持つことに関連する一般的な慣行をグループ化する段階的な表現を備えたCMMIモデルプロセス領域の共通機能。
Acceptance criteria −ユーザー、顧客、またはその他の承認されたエンティティによって受け入れられるために、製品または製品コンポーネントが満たさなければならない基準。
Acceptance testing −ユーザー、顧客、またはその他の許可されたエンティティが製品または製品コンポーネントを受け入れるかどうかを決定できるようにするために実施される正式なテスト。
Achievement profile −継続的な表現において、プロセス領域とそれに対応する機能レベルのリスト。機能レベルを進めながら、各プロセス領域の組織の進捗状況を表します。
Acquisition −製品およびサービスの取得に投資することを確約する、取得エンティティによる個別のアクションまたは提案されたアクションを契約を通じて取得するプロセス。
Acquisition strategy −供給元、取得方法、要件仕様タイプ、契約または契約タイプ、および関連する取得リスクの考慮に基づく、製品およびサービスを取得するための特定のアプローチ。
Adequate−組織のビジネス目標に照らして、すべてのレベルのマネージャーと実務家が特定の一般的な目標と実践を解釈できるように、適切、適切、および必要に応じてCMMIに表示されます。たとえば、リスク管理のプロセス領域の一般的な慣行には、「リスク管理プロセスの実行、作業成果物の開発、およびプロセスのサービスの提供に十分なリソースを提供する」と記載されています。人数、リスクを監視しなければならない人などで十分満足できます。
Advanced practices −連続表現では、能力レベルが2以上のすべての特定のプラクティス。
Agreement/contract requirements −買収に関連するすべての技術的および非技術的要件。
Allocated requirement −低レベルの建築要素または設計コンポーネントに高レベルの要件のパフォーマンスと機能の全部または一部を課す要件。
Alternative practice−モデルプラクティスに関連する一般的または特定の目標を達成するために同等の効果を達成する、CMMIモデルに含まれる1つ以上の一般的または特定のプラクティスの代替となるプラクティス。代替プラクティスは、必ずしも一般的または特定のプラクティスを1対1で置き換えるものではありません。
Appraisal −評価とは、訓練を受けた専門家チームが、長所と短所を判断するための基礎として評価参照モデルを使用して、1つ以上のプロセスを調査することです。
Appraisal findings−評価範囲内で最も重要な問題、問題、または機会を特定する評価の結論。これには、少なくとも、有効な観察に基づく長所と短所が含まれます。
Appraisal participants −評価中に情報を提供することに参加する組織単位のメンバー。
Appraisal rating− CMMI評価資料で使用されているように、評価チームによって（1）CMMIの目標またはプロセス領域、（2）プロセス領域の能力レベル、または（3）組織単位の成熟度レベルのいずれかに割り当てられる値。格付けは、採用されている評価方法について定義された格付けプロセスを制定することによって決定されます。
Appraisal reference model − CMMI評価資料で使用されているように、評価チームが実装されたプロセス活動を関連付けるCMMIモデル。
Appraisal scope −組織の制限とCMMIモデルの制限を含む評価の境界の定義。
Appraisal team leader −鑑定の活動を主導し、鑑定方法で定められた経験、知識、技能の資格基準を満たしている者。
Appropriate −適切の定義を参照してください。
As needed −適切の定義を参照してください。
Assessment −評価とは、プロセス改善の目的で組織が自ら実施する評価です。
Assignable cause of process variation− CMMIでは、一貫性を確保するために、「プロセス変動の割り当て可能な原因」の代わりに「プロセス変動の特別な原因」という用語が使用されています。両方の用語は同じように定義されています。
Audit −要件が満たされているかどうかを判断するための、作業成果物または一連の作業成果物の独立した検査。
Base measure −エンティティの明確な特性または特性とそれを定量化する方法。
Base practices −連続表現では、能力レベルが1のすべての特定のプラクティス。
Baseline−ベースラインという用語は通常、そのような基準点を示すために使用されます。ベースラインは、開発ライフサイクルの適切な時点で承認されたシステムのスナップショットです。ベースラインは、その後の変更を定義するための正式なベースを確立します。この線または参照点がなければ、変化の概念は無意味です。
Business objectives −組織の存続を確保し、その収益性、市場シェア、および組織の成功に影響を与えるその他の要因を強化するために設計された上級管理職が開発した戦略。
Capability evaluation−サプライヤーを選択するため、契約の監視のため、またはインセンティブのための識別器として使用される、訓練を受けた専門家チームによる評価。評価は、意思決定者がより良い買収決定を下し、下請け業者のパフォーマンスを改善し、購買組織に洞察を提供するのに役立ちます。
Capability level−個々のプロセス領域内でのプロセス改善の達成。機能レベルは、プロセス領域の適切な特定の一般的なプラクティスによって定義されます。
Capability level profile−連続表現では、プロセス領域とそれに対応する機能レベルのリスト。プロファイルは、機能レベルを進めながら、各プロセス領域の組織の進捗状況を表す場合、達成プロファイルである可能性があります。または、プロファイルがプロセス改善の目的を表す場合、プロファイルはターゲットプロファイルである可能性があります。
Capability maturity model−能力成熟度モデル（CMM）には、1つ以上の分野の効果的なプロセスの重要な要素が含まれています。また、アドホックで未成熟なプロセスから、品質と有効性が向上した統制のとれた成熟したプロセスへの進化的な改善パスについても説明します。
Capable process −指定された製品品質、サービス品質、およびプロセスパフォーマンスの目標を満たすことができるプロセス。
Causal analysis −原因を特定するための欠陥の分析。
Change management −製品またはサービスに変更または提案された変更をもたらすための手段の賢明な使用。
CMMI appraisal tailoring−特定のインスタンスで使用するための評価方法内のオプションの選択。評価調整の目的は、組織がメソッドの適用をビジネス目標に合わせるのを支援することです。
CMMI model component−CMMIモデルを構成する主要なアーキテクチャ要素のいずれか。CMMIモデルの主な要素には、特定のプラクティス、一般的なプラクティス、特定の目標、一般的な目標、プロセス領域、能力レベル、および成熟度レベルが含まれます。
CMMI model tailoring−特定のアプリケーションに適したものにする目的でのCMMIモデルのサブセットの使用。モデル調整の目的は、組織がモデルの適用をビジネス目標に合わせるのを支援することです。
CMMI Product Suite −この用語は、完全なCMMIフレームワークに使用されています。
Commitment to perform −ポリシーの作成とスポンサーシップの確保に関連する一般的な慣行をグループ化する段階的な表現を備えたCMMIモデルプロセス領域の共通機能。
Common cause of process variation −プロセスのコンポーネント間の通常の相互作用と予想される相互作用のために存在するプロセスのバリエーション。
Concept of operations −エンティティが使用または操作される方法の一般的な説明。
Configuration audit −構成アイテムが指定された標準または要件に準拠していることを確認するために実施される監査。
Configuration baseline−製品または製品コンポーネントの寿命中の特定の時間に正式に指定された構成情報。構成ベースライン、およびそれらのベースラインからの承認された変更は、現在の構成情報を構成します。
Configuration control −構成IDの正式な確立後の構成アイテムの評価、調整、承認または不承認、および変更の実装で構成される構成管理の要素。
Configuration control board −構成アイテムに対して提案された変更を評価および承認または不承認し、承認された変更の実装を確実にする責任がある人々のグループ。
Configuration identification −製品の構成アイテムを選択し、それらに一意の識別子を割り当て、それらの機能的および物理的特性を技術文書に記録することで構成される構成管理の要素。
Configuration item −構成管理用に指定され、構成管理プロセスで単一のエンティティとして扱われる作業成果物の集合体。
Configuration management−技術的および管理上の指示と監視を適用して、（1）構成アイテムの機能的および物理的特性を識別および文書化し、（2）それらの特性に対する変更を制御し、（3）変更の処理と実装のステータスを記録および報告し、（ 4）指定された要件への準拠を確認します。[IEEE Std 610.1990]
CMMI Model− CMMIフレームワークは、それを使用する組織のニーズに基づいてさまざまなモデルを生成できるため、複数のCMMIモデルがあります。したがって、「CMMIモデル」というフレーズは、多くの情報コレクションのいずれかである可能性があります。「CMMIモデル」という句は、CMMIフレームワークから生成できる可能性のあるモデルの1つ、一部、または全体のコレクションを指します。
Configuration status accounting−構成を効果的に管理するために必要な情報の記録とレポートで構成される構成管理の要素。この情報には、承認された構成IDのリスト、構成に対する提案された変更のステータス、および承認された変更の実装ステータスが含まれます。
Continuous representation −能力レベルが、指定された各プロセス領域内でプロセス改善に取り組むための推奨順序を提供する能力成熟度モデル構造。
Corrective action −状況の改善、エラーの削除、または状態の調整に使用される行為または行為。
COTS −商用ベンダーから購入できるアイテム。
Customer−顧客とは、製品の受け入れまたは支払いの承認を担当する個人、プロジェクト、組織、グループなどです。顧客はプロジェクトの外部にいますが、必ずしも組織の外部にいる必要はありません。顧客という用語は、要件の収集または引き出しについて説明するときの変数としても機能します。
Data management −データの共有と管理のための原則、プロセス、およびシステム。
Defect density −製品サイズの単位あたりの欠陥の数（たとえば、1000行のコードあたりの問題レポート）。
Defined process −改善の一環として従うべき一連の定義済みの手順。
Derived measures −2つ以上の基本メジャーの数学関数から得られたデータ。
Derived requirements−顧客の要件に明示的に記載されていないが、（1）コンテキスト要件（適用される標準、法律、ポリシー、一般的な慣行、および管理上の決定など）から、または（2）製品を指定するために必要な要件から推測される要件成分。派生要件は、製品またはシステムのコンポーネントの分析および設計中にも発生する可能性があります。
Design review −設計要件とこれらの要件を満たす設計の能力を評価し、問題を特定して解決策を提案するための、設計の正式で文書化された包括的かつ体系的な調査。
Development−開発は、CMMI全体で使用されるため、開発活動だけでなく保守活動も意味します。経験によれば、組織が優れたエンジニアリングを追求している場合は、開発プロジェクトと保守プロジェクトの両方にベストプラクティスを適用する必要があります。
Developmental plan − 1つ以上の製品の設計と開発を指導、実装、および制御するための計画。
Directing implementation −プロセスのパフォーマンスの管理、作業成果物の整合性の管理、および関連する利害関係者の関与に関連する一般的な慣行をグループ化する段階的な表現を備えたCMMIモデルプロセス領域の共通機能。
Discipline amplification−特定の分野（システムエンジニアリングやソフトウェアエンジニアリングなど）のモデル情報を解釈するためのガイダンスを提供するモデルコンポーネントは、「DISCIPLINEAMPLIFICATIONS」と呼ばれます。規律の増幅は、必要に応じて他のモデルコンポーネントに追加されます。これらはページの右側に表示され、対象となる分野を示すタイトルが付いているため、簡単に見つけることができます（たとえば、「ソフトウェアエンジニアリングの場合」）。
Document−ドキュメントは、記録されているメディアに関係なく、データのコレクションです。それは一般的に永続性があり、人間または機械によって読み取ることができます。文書には、紙と電子文書の両方が含まれます。
Enterprise −エンタープライズは、さまざまな場所にあり、さまざまな顧客を持つ多くの組織で構成される非常に大規模な企業を指すために使用されます。
Entry criteria −努力を成功させる前に存在しなければならない存在の状態。
Equivalent staging −同等のステージングは、ターゲットステージングを使用した結果をステージングされた表現の成熟度レベルと比較できるように、定義された連続表現を使用して作成されたターゲットステージングです。
Exit criteria −努力が成功裏に終了する前に存在しなければならない存在の状態。
Expected CMMI components−必要なCMMIコンポーネントを満たすために何ができるかを説明するCMMIコンポーネント。モデルユーザーは、期待されるコンポーネントを明示的に実装することも、これらのコンポーネントと同等の代替プラクティスを実装することもできます。特定の一般的な慣行は、期待されるモデルコンポーネントです
Finding −評価結果を参照してください。
Formal evaluation process −意思決定分析と解決のプロセス領域で、導入ノートの「正式な評価プロセス」の定義を参照してください。
Functional analysis−定義された機能を調べて、その機能の達成に必要なすべてのサブ機能を特定します。機能的関係とインターフェース（内部および外部）を識別し、これらを機能的アーキテクチャーに取り込む。上位レベルのパフォーマンス要件のフローダウンと、これらの要件の下位レベルのサブ機能への割り当て。
Functional architecture −機能の階層配置、それらの内部および外部（アグリゲーション自体の外部）機能インターフェイスと外部物理インターフェイス、それぞれの機能要件とパフォーマンス要件、およびそれらの設計上の制約。
Generic goal− GENERIC GOALSは、同じ目標ステートメントが複数のプロセス領域に表示されるため、「汎用」と呼ばれます。段階的表現では、各プロセス領域には1つの一般的な目標しかありません。プロセス領域での一般的な目標の達成は、そのプロセス領域に関連付けられたプロセスの計画と実装における制御の向上を意味し、したがって、これらのプロセスが効果的で、再現性があり、持続する可能性が高いかどうかを示します。一般的な目標は必須のモデルコンポーネントであり、プロセス領域が満たされているかどうかを判断するための評価で使用されます。
Generic practice− GENERIC PRACTICESは、プロセス領域に関連するプロセスが効果的で、再現性があり、持続することを保証するための制度化を提供します。一般的な慣行は、一般的な目標と共通の機能によって分類され、CMMIモデルで期待されるコンポーネントです。（一般的なプラクティスのタイトル、ステートメント、および詳細のみがプロセス領域に表示されます。）
Generic practice elaboration−特定のプラクティスの後に、プロセス領域に適用される一般的なプラクティスのタイトルとステートメントが表示されます。各一般的な実践ステートメントの後に、「詳細」という見出しの付いたプレーンテキストで詳細が表示される場合があります。GENERIC PRACTICE ELABORATIONは、プロセス領域で一般的なプラクティスをどのように解釈すべきかについての情報を提供します。詳細が存在しない場合、一般的なプラクティスの適用は詳細がなくても明らかです。
Goal−「目標」は必須のCMMIコンポーネントであり、一般的な目標または特定の目標のいずれかになります。CMMIモデルで「目標」という言葉を目にするとき、それは常にモデルの構成要素（たとえば、一般的な目標、特定の目標）を指します。
Incomplete process−実行されていない、または部分的にしか実行されていないプロセス（機能レベル0とも呼ばれます）。プロセス領域の特定の目標の1つ以上が満たされていません。
Independent group −プロセスおよび製品品質保証プロセス領域で、導入ノートの「独立したグループ」の説明を参照してください。
Informative CMMI components−モデルユーザーがモデルの必要なコンポーネントと期待されるコンポーネントを理解するのに役立つCMMIコンポーネント。これらのコンポーネントには、例、詳細な説明、またはその他の役立つ情報が含まれている場合があります。サブプラクティス、メモ、リファレンス、ゴールタイトル、プラクティスタイトル、ソース、典型的な作業成果物、規律の増幅、および一般的なプラクティスの詳細は、有益なモデルコンポーネントです。
Institutionalization −組織が企業文化の一部として日常的に従うビジネスの根深い方法。
Integrated Product and Process Development −製品ライフサイクル全体を通じて関連する利害関係者のタイムリーなコラボレーションを実現し、顧客のニーズをより適切に満たす、製品開発への体系的なアプローチ。
Integrated team−タイムリーなコラボレーションで特定の作業成果物を提供することに取り組んでいる補完的なスキルと専門知識を持つ人々のグループ。統合されたチームメンバーは、作業成果物のすべてのフェーズに適したスキルとアドボカシーを提供し、指定されたとおりに作業成果物を提供する責任を共同で負います。統合されたチームには、作業成果物の成功に関与する組織、分野、および機能からの権限を与えられた代表者を含める必要があります。
Interface control−構成管理において、（1）1つ以上の組織によって提供される2つ以上の構成アイテムのインターフェースに関連するすべての機能的および物理的特性を識別し、（2）これらの特性に対する提案された変更が評価および承認されることを保証するプロセス実装前。[IEEE828-1983]。
Lead appraiser − CMMI製品スイートで使用されているように、特定の評価方法の評価チームリーダーとして実行することを承認機関から承認された人。
Life-cycle model −製品の寿命をフェーズに分割し、プロジェクトが顧客のニーズの特定から製品の廃棄までをガイドします。
Manager−プロジェクトマネージャーは、プロジェクトの計画、指揮、管理、構造化、および動機付けの責任者です。彼または彼女は、彼または彼女の責任範囲内でプロジェクトのタスクまたは活動を実行する人々に、技術的および管理的な指示と制御の両方を提供することができます。プロジェクトマネージャーは、最終的に顧客に対して責任を負います。
Maturity level −セット内のすべての目標が達成される、事前定義されたプロセス領域のセット全体にわたるプロセス改善の程度。
Memorandum of agreement −2つ以上の当事者間の理解または合意に関する拘束力のある文書。
Natural bounds−「プロセスの声」と呼ばれることもある、プロセスパフォーマンスの測定値に反映される固有のプロセス。管理図、信頼区間、予測区間などの手法を使用して、変動が一般的な原因によるものか（つまり、プロセスが予測可能または「安定」）、特定できる、または特定する必要がある特別な原因によるものかどうかを判断します。削除されました。
Non-developmental item−取得または開発プロセスで現在使用される前に開発された供給品目。このようなアイテムは、現在の使用目的の要件を満たすために、小さな変更が必要になる場合があります。
Nontechnical requirements−製品またはサービスの取得方法に影響を与える契約条項、コミットメント、条件、および条件。例としては、納品される製品、納品された市販（COTS）の非開発品目（NDI）のデータ権利、納期、終了基準のあるマイルストーンなどがあります。その他の非技術的な要件には、トレーニング要件、サイト要件、および展開スケジュールが含まれます。
Objective−目標という用語は、CMMIでは日常的な一般的な意味で使用されます。これが私たちの目標または達成すべき目標です。
Objective evidence − CMMI評価資料、定性的または定量的情報、記録、またはアイテムまたはサービスの特性、またはプロセス要素の存在と実装に関連する事実のステートメントで使用されるもの。これらは、観察、測定、またはテストに基づいており、検証可能です。
Objectively evaluate−レビュー担当者による主観性とバイアスを最小限に抑える基準に照らして活動と作業成果物をレビューする。客観的評価の例は、独立した品質保証機能による要件、基準、または手順に対する監査です。
Observation− CMMI評価資料で使用されているように、評価データ収集活動中に見られた、または聞いた情報についての評価チームメンバーの理解を表す書面による記録。書面による記録は、情報の内容が保存されている限り、声明の形式をとるか、別の形式をとることができます。
Operational concept −エンティティが使用または操作される方法の一般的な説明。
Operational scenario−製品とその環境およびユーザーとの相互作用、および製品コンポーネント間の相互作用を含む、想像される一連のイベントの説明。運用シナリオは、システムの要件と設計を評価し、システムを検証および検証するために使用されます。
Optimizing process−プロセスに固有の変動の一般的な原因の理解に基づいて改善された、定量的に管理されたプロセス。漸進的および革新的な改善の両方を通じて、プロセスパフォーマンスの範囲を継続的に改善することに焦点を当てたプロセス。
Organization −組織とは、1つ以上のプロジェクト全体をまとめて管理し、プロジェクトが上級管理職を共有し、同じポリシーの下で運営される構造です。
Organization's business objectives −組織の存続を確保し、組織の収益性、市場シェア、および組織の成功に影響を与えるその他の要因を強化するために上級管理職によって開発された戦略。
Organizational maturity−組織が、文書化、管理、測定、制御され、継続的に改善されるプロセスを明示的かつ一貫して展開している程度。組織の成熟度は、評価によって測定できます。
Organizational policy −意思決定に影響を与え、決定するために組織によって採用される、通常は上級管理職によって確立される指針となる原則。
Organizational unit−評価の対象となる組織の部分（評価の組織範囲とも呼ばれます）。組織単位は、一貫性のあるプロセスコンテキストを持ち、一貫性のある一連のビジネス目標内で動作する1つ以上のプロセスを展開します。組織単位は通常、大規模な組織の一部ですが、小規模な組織では、組織単位が組織全体である場合があります。
Outsourcing −製品およびサービスの取得に投資することを確約する、取得エンティティによる個別のアクションまたは提案されたアクションを契約を通じて取得するプロセス。
Peer review −成果物の欠陥を見つけるためにピアによって行われたレビュー。
Performance parameters −進歩的な開発を導き、制御するために使用される有効性の測定およびその他の重要な測定。
Performed process−識別された入力作業成果物（機能レベル1とも呼ばれます）を使用して、識別された出力作業成果物を生成するために必要な作業を実行するプロセス。プロセス領域の特定の目標は満たされています。
Planned process−説明と計画の両方によって文書化されたプロセス。説明と計画は調整する必要があり、計画には標準、要件、目的、リソース、割り当てなどを含める必要があります。
Process −システムおよび関連製品を開発および保守するために人々が使用する一連の活動、方法、実践、および変革。
Process action plan −組織プロセスフォーカスプロセス領域で、導入ノートの「プロセスアクションプラン」の定義を参照してください。
Process action team −プロセス改善行動計画に文書化されているように、組織のプロセス改善活動を開発および実装する責任があるチーム。
Process and technology improvements −組織の革新と展開のプロセス領域で、導入ノートの「プロセスとテクノロジーの改善」の説明を参照してください。
Process area−プロセス領域は、その領域で関連するプラクティスのクラスターであり、まとめて実行すると、その領域を大幅に改善するために重要と見なされる一連の目標を満たします。すべてのCMMIプロセス領域は、連続表現と段階的表現の両方に共通です。段階的な表現では、プロセス領域は成熟度レベルごとに編成されています。
Process asset −プロセス領域の目標を達成するのに組織が役立つと考えるもの。
Process asset library −組織またはプロジェクトで使用できるプロセス資産保有のコレクション。
Process attribute −任意のプロセスに適用可能なプロセス能力の測定可能な特性。
Process capability −プロセスに従うことによって達成できる期待される結果の範囲。
Process context−鑑定評価の判断と比較可能性に影響を与える、鑑定入力に文書化された一連の要因。これらには、評価される組織単位のサイズが含まれますが、これに限定されません。組織単位の人口統計。製品またはサービスのアプリケーション分野。製品またはサービスのサイズ、重要度、および複雑さ。および製品またはサービスの品質特性。
Process definition−プロセスを定義および説明する行為。プロセス定義の結果は、プロセスの説明です。
Process description−プロセスの主要コンポーネントの運用上の定義を提供する、特定の目的を達成するために実行される一連のアクティビティの文書化された表現。ドキュメントには、プロセスの要件、設計、動作、またはその他の特性が、完全で正確かつ検証可能な方法で指定されています。また、これらの規定が満たされているかどうかを判断するための手順が含まれる場合もあります。プロセスの説明は、アクティビティ、プロジェクト、または組織レベルで見つけることができます。
Process element−プロセスの基本単位。プロセスは、サブプロセスまたはプロセス要素の観点から定義できます。サブプロセスはさらに分解できます。プロセス要素はできません。各プロセス要素は、密接に関連する一連のアクティビティ（たとえば、見積もり要素、ピアレビュー要素）をカバーします。プロセス要素は、完成させるテンプレート、洗練する抽象化、または変更または使用する説明を使用して表現できます。プロセス要素は、アクティビティまたはタスクにすることができます。
Process group −組織が使用するプロセスの定義、保守、および改善を促進するスペシャリストの集まり。
Process improvement −組織のプロセスのパフォーマンスと成熟度を改善するために設計された活動のプログラム、およびそのようなプログラムの結果。
Process-improvement objectives −結果として得られる製品特性（品質、性能、規格への適合など）の観点から、またはプロセスの方法のいずれかに関して、特定の測定可能な方法で既存のプロセスを改善する取り組みを導くために確立された一連の目標特性実行される（例えば、冗長なプロセスステップの排除、プロセスステップの組み合わせ、サイクルタイムの改善など）
Process-improvement plan −組織プロセスフォーカスプロセス領域で、導入ノートの「プロセス改善計画」の定義を参照してください。
Process measurement −プロセスの特性評価と理解を目的として、プロセスとその結果の製品を測定するために使用される一連の定義、方法、およびアクティビティ。
Process owner−プロセスの定義と維持に責任を持つ人（またはチーム）。組織レベルでは、プロセスの所有者は、標準プロセスの説明を担当する人（またはチーム）です。プロジェクトレベルでは、プロセス所有者は、定義されたプロセスの説明に責任を持つ人（またはチーム）です。したがって、プロセスには、さまざまなレベルの責任を持つ複数の所有者がいる場合があります。
Process performance−プロセスに従うことによって達成された実際の結果の尺度。これは、プロセス測定値（たとえば、労力、サイクル時間、および欠陥除去効率）と製品測定値（たとえば、信頼性、欠陥密度、および応答時間）の両方によって特徴付けられます。
Process performance baseline −実際のプロセスパフォーマンスを期待されるプロセスパフォーマンスと比較するためのベンチマークとして使用される、プロセスに従うことによって達成された実際の結果の文書化された特性。
Process performance model −過去のプロセスパフォーマンスデータから開発され、プロジェクトから収集されたプロセスと製品の測定値を使用して調整され、プロセスに従うことによって達成される結果を予測するために使用される、プロセスとその作業成果物の属性間の関係の説明。
Process tailoring−特定の目的のためにプロセス記述を作成、変更、または適合させること。たとえば、プロジェクトは、プロジェクトの目的、制約、および環境を満たすために、組織の一連の標準プロセスから定義されたプロセスを調整します。
Product−製品は、プロセスに従った結果であり、顧客またはエンドユーザーへの配信を目的とした具体的な出力またはサービスと考えることができます。製品は、契約に従って顧客に提供される任意の作業成果物にすることもできます。
Product component−製品コンポーネントは通常、製品の下位レベルのコンポーネントであり、製品を「構築」するために統合されます。製品コンポーネントは、顧客に提供される製品の一部である場合もあれば、製品の製造または使用に役立つ場合もあります。たとえば、携帯電話のバッテリーを製造している企業にとって、携帯電話のバッテリーは製品です。携帯電話を製造および納入する企業にとって、バッテリーは製品コンポーネントです。
Product baseline −構成管理において、ライフサイクルの生産、運用、保守、および後方支援中に構成アイテムを定義する、最初に承認された技術データパッケージ（ソフトウェアの場合はソースコードリストを含む）。
Product-component requirements −製品コンポーネントの要件は、適合性、形状、機能、パフォーマンス、およびその他の要件を含む、製品コンポーネントの完全な仕様を提供します。
Product life cycle−作業成果物は、ライフサイクルプロセスによって生成されたアーティファクトであり、ライフサイクル作業成果物と呼ばれることもあります。ライフサイクル作業成果物には、要件仕様、インターフェース仕様、アーキテクチャ仕様、プロジェクト計画、設計文書、単体テスト計画、統合およびシステムテスト計画、製造製品の組み立てプロセスなどのプロセスが含まれます。
Project−プロジェクトは、1つ以上の製品を顧客またはエンドユーザーに提供する、相互に関連するリソースの管理されたセットです。リソースのセットには明確な開始と終了があり、計画に従って動作します。
Product line −選択した市場または使命の特定のニーズを満たす、共通の管理された機能セットを共有する製品のグループ。
Product-related life-cycle processes −製造およびサポートプロセスなど、製品のライフサイクルの1つ以上のフェーズ（つまり、構想から廃棄まで）を通じて製品に関連するプロセス。
Product requirements −顧客の要件を開発者の言語に改良し、暗黙の要件を明示的な派生要件にします。
Program−（1）プロジェクト。（2）目的、方法、活動、計画、および成功基準を含む、関連プロジェクトとそれらをサポートするインフラストラクチャのコレクション。
Project manager−プロジェクトマネージャーは、プロジェクトの計画、指揮、管理、構造化、および動機付けの責任者です。彼または彼女は、彼または彼女の責任範囲内でプロジェクトのタスクまたは活動を実行する人々に、技術的および管理的な指示と制御の両方を提供することができます。プロジェクトマネージャーは、最終的に顧客に対して責任を負います。プロジェクトマネージャーは、プロジェクトの規模、多様性、複雑さが変化するにつれて、さまざまな役割と責任を負います。
Project progress and performance −労力、コスト、スケジュール、技術的パフォーマンスなど、プロジェクト計画の実施に関してプロジェクトが達成すること。
Project's defined process −統合プロジェクト管理プロセス領域で、導入ノートおよび「プロジェクト定義プロセスの確立」固有のプラクティスの「プロジェクトの定義済みプロセス」の定義を参照してください。
Prototype −後の段階または製品の最終的な完全バージョンのモデルとして機能する、製品または製品コンポーネントの予備的なタイプ、フォーム、またはインスタンス。
Quality −顧客の要件を満たすための、製品、製品コンポーネント、またはプロセスの一連の固有の特性の能力。
Quality assurance −定義された基準、慣行、手順、およびプロセスの方法が適用されることを管理者に保証するための計画的かつ体系的な手段。
Quality control −品質の要件を満たすために使用される運用技術と活動。
Quantitative objective −定量的尺度として表される望ましい目標値。
Quantitatively managed process−統計的およびその他の定量的手法を使用して制御される定義済みのプロセス。製品品質、サービス品質、およびプロセスパフォーマンスの属性は、プロジェクト全体で測定および制御されます。
Reference mode −いくつかの属性を測定するためのベンチマークとして使用されるモデル。
Relevant stakeholder −関連する利害関係者は、特定の活動への関与が特定され、プロジェクト計画などの適切な計画に含まれる利害関係者を指定するために使用されます。
Required CMMI components−特定のプロセス領域でプロセス改善を達成するために不可欠なCMMIコンポーネント。これらのコンポーネントは、プロセス能力を決定するための評価で使用されます。特定の目標と一般的な目標は、必須のモデルコンポーネントです。
Requirement−（1）問題を解決したり、目的を達成したりするためにユーザーが必要とする条件または機能。（2）契約、標準、仕様、またはその他の正式に課された文書を満たすために、製品または製品コンポーネントが満たす必要がある、または所有する必要がある条件または機能。（3）（1）または（2）のような条件または機能の文書化された表現。
Requirements analysis−顧客のニーズ、期待、および制約の分析に基づく製品固有のパフォーマンスおよび機能特性の決定。運用コンセプト; 人、製品、およびプロセスの予測される使用環境。および有効性の測定。
Requirements elicitation −プロトタイプや構造化調査などの体系的な手法を使用して、顧客とエンドユーザーのニーズを積極的に特定して文書化します。
Requirements management −技術的要件と非技術的要件の両方、および組織がプロジェクトに課す要件を含む、プロジェクトによって受信または生成されたすべての要件の管理。
Requirements traceability −要件とそのソース要件、その実装、およびその検証の間の関連の証拠。
Return on investment −生産コストに対する出力（製品）からの収益の比率。これは、組織が何かを生産するためのアクションを実行することから利益を得るかどうかを決定します。
Risk analysis −リスクの評価、分類、および優先順位付け。
Risk identification −目標を達成する上での可能性のある、または現実的なリスクを探すための組織化された徹底的なアプローチ。
Risk management −危害または損失を引き起こす可能性のあるものを特定し（リスクを特定し）、特定されたリスクを評価および定量化し、重大な危害をもたらす可能性のあるリスク原因を防止または処理するための適切なアプローチを開発および実装するための組織化された分析プロセスまたは損失。
Risk management strategy−危害または損失を引き起こす可能性のあるものを特定し（リスクを特定し）、特定されたリスクを評価および定量化し、重大な危害または損失をもたらす可能性のあるリスク原因を防止または処理するための適切なアプローチを開発および実装するための組織化された技術的アプローチ。通常、リスク管理は、プロジェクト、組織、または製品開発組織単位に対して実行されます。
Root cause −根本原因は欠陥の原因であり、それが除去されると、欠陥が減少または除去されます。
Senior manager− CMMIで使用される上級管理職という用語は、組織内で十分に高いレベルの管理職を指し、その人の主な焦点は、短期的なプロジェクトではなく、組織の長期的な健康と成功です。契約上の懸念と圧力。上級管理者は、プロジェクト管理者によって管理される多くのプロジェクトを含む可能性のあるプログラムの監視を担当する場合があります。
Software engineering−（1）ソフトウェアの開発、運用、および保守に対する体系的で統制のとれた定量化可能なアプローチの適用。（2）（1）と同様のアプローチの研究。
Solicitation −勧誘パッケージを準備し、サプライヤー（請負業者）を選択するプロセス。
Solicitation package−入札の招待（入札）および提案依頼書（提案）のオファーを要求するため、または機能のステートメントと価格見積もり（見積もり）を要求するために使用される、技術的および非技術的要件を説明する正式な文書。それ以外の場合は、製品またはサービスを提供するための1つまたは複数の供給元を選択するための基礎として使用されます。
Special cause of process variation −プロセスの固有の部分ではなく、一時的な状況に固有の欠陥の原因。
Specific goal−特定の目標はプロセス領域に適用され、プロセス領域を満たすために何を実装する必要があるかを説明する固有の特性に対処します。特定の目標は必須のモデルコンポーネントであり、プロセス領域が満たされているかどうかを判断するために評価で使用されます。
Specific practice− SPECIFIC PRACTICEは、関連する特定の目標を達成する上で重要と見なされる活動です。特定のプラクティスは、プロセス領域の特定の目標の達成につながると予想されるアクティビティを説明します。特定のプラクティスは、予想されるモデルコンポーネントです。
Stable process −プロセス変動の一般的な原因のみが残るように、プロセス変動のすべての特別な原因が取り除かれ、再発が防止された状態。
Staged representation−一連のプロセス領域の目標を達成することで成熟度レベルが確立されるモデル構造。各レベルは、後続のレベルの基盤を構築します。
Stakeholder −利害関係者とは、プロジェクトの結果によって影響を受ける、またはプロジェクトの活動や成果に影響を与える可能性のあるグループまたは個人です。
Standard process−組織内の共通プロセスの確立をガイドする基本プロセスの運用上の定義。標準プロセスは、定義されたプロセスに組み込まれることが期待される基本的なプロセス要素を記述します。また、これらのプロセス要素間の関係（順序やインターフェイスなど）についても説明します。
Statement of work −プロジェクトを完了するために必要な契約作業の説明。
Statistical predictability −統計的およびその他の定量的手法を使用して制御される定量的プロセスのパフォーマンス。
Statistical process control −プロセスの統計に基づく分析とプロセスパフォーマンスの測定。これにより、プロセスパフォーマンスの変動の一般的および特殊な原因が特定され、プロセスパフォーマンスが制限内に維持されます。
Statistical techniques −統計的手法（統計的プロセス制御、信頼区間、予測区間など）を使用する分析手法。
Statistically managed process −プロセスが分析され、プロセス変動の特別な原因が特定され、パフォーマンスが明確に定義された制限内に含まれる、統計ベースの手法によって管理されるプロセス。
Strength − CMMI評価資料で使用されているように、CMMIモデルの実践の模範的または注目に値する実装。
Sub-process −より大きなプロセスの一部であるプロセス。
Supplier−（1）取得中の製品を提供する、またはサービスを実行するエンティティ。（2）契約（契約）の条件に基づく品目の設計、開発、製造、保守、変更、または供給の取得と契約（契約）を結んでいる個人、パートナーシップ、会社、企業、協会、またはその他のサービス）。
Sustainment−製品をエンドユーザーまたは顧客が運用上利用できるようにするために使用されるプロセス。維持は、製品が顧客またはエンドユーザーによって使用されているかどうかに関係なく、製品が操作可能な状態になるように保守が行われることを保証します。
Systems engineering−一連の顧客のニーズ、期待、および制約を製品ソリューションに変換し、製品の寿命全体にわたってそのソリューションをサポートするために必要な、技術的および管理上の総努力を管理する学際的なアプローチ。これには、技術的なパフォーマンス指標の定義、製品アーキテクチャの確立に向けたエンジニアリングの専門分野の統合、およびコスト、パフォーマンス、スケジュールの目標のバランスをとるサポートライフサイクルプロセスの定義が含まれます。
Tailoring guidelines−プロセスを調整すると、特定のプロジェクトで使用するために、通常は組織レベルで記述されるプロセス記述が作成、変更、または適合されます。ほとんどの組織では、1つの組織プロセス定義がすべてのプロジェクトで100％従うことはできないか、従わないでしょう。通常、ある程度の適応が必要です。次に、調整ガイドラインは、変更できるものとできないものを説明し、変更の許容可能な候補であるプロセスコンポーネントを特定します。
Target profile −継続的表現において、プロセス改善の目的を表すプロセス領域とそれに対応する能力レベルのリスト。
Target staging −継続的表現において、組織がたどるプロセス改善のパスを説明する一連のターゲットプロファイル。
Technical data package −そのような情報が製品のタイプおよび製品コンポーネントに適切である場合、以下を含む可能性のあるアイテムのコレクション。
Technical requirements −取得または開発する製品またはサービスのプロパティ（属性）。
Test procedure −特定のテストの結果のセットアップ、実行、および評価に関する詳細な手順。
Trade study −決定された目的を達成するための最良の代替案を選択するための、基準と体系的な分析に基づく代替案の評価。
Training−組織トレーニングプロセス領域で、.trainingの定義を参照してください。イントロダクションノートで。
Unit testing −個々のハードウェアまたはソフトウェアユニットまたは関連ユニットのグループのテスト。
Validation−検証は、提供された（または提供される予定の）製品が運用環境での使用目的を満たしていることを示します。検証により、「あなたは正しいものを構築した」ことが保証されます。
Verification−検証には、顧客、製品、および製品コンポーネントの要件を含む、選択されたすべての要件に対する製品および中間作業成果物の検証が含まれます。検証は本質的に段階的なプロセスです。それは、要件の検証から始まり、進化する作業成果物の検証を経て、完成した製品の検証に至ります。検証では、作業成果物が指定された要件を適切に反映しているかどうかを確認します。検証により、「正しく構築された」ことが保証されます。
Verifying implementation − CMMIモデルのプロセス領域の共通の特徴であり、より高いレベルの管理によるレビューに関連する一般的な慣行をグループ化する段階的な表現、およびプロセスの説明、手順、および標準への適合性の客観的な評価。
Version control −ベースラインの確立と維持、および前のベースラインに戻ることを可能にするベースラインへの変更の識別。
Weakness − CMMI評価資料で使用されているように、1つ以上のCMMIモデルプラクティスの実装が効果的でない、または欠如している。
Work breakdown structure −作業要素の配置とそれらの相互および最終製品との関係。
Work product− WORK PRODUCTという用語は、CMMI Product Suite全体で使用され、プロセスによって生成されたアーティファクトを意味します。これらの成果物には、ファイル、ドキュメント、製品の一部、サービス、プロセス、仕様、および請求書が含まれる場合があります。作業成果物と見なされるプロセスの例には、製品の製造プロセス、トレーニングプロセス、および廃棄プロセスが含まれます。WORK PRODUCTと製品コンポーネントの主な違いは、WorkProductを設計したり最終製品の一部にしたりする必要がないことです。
Work product and task attributes−プロジェクト作業の見積もりに役立つ製品、サービス、およびプロジェクトタスクの特性。これらの特性には、サイズ、複雑さ、重量、形状、フィット感、機能などの項目が含まれます。これらは通常、他のプロジェクトやリソースの見積もり（たとえば、労力、コスト、スケジュール）を導き出すための1つの入力として使用されます。