プロセス改善と成熟度

自動車業界のプロセス用のプロセス参照モデルおよび関連するプロセスアセスメントモデル。ISO/IEC 33002：2015の要件に準拠する。

Computer Aided Software Testing（コンピュータ支援ソフトウェアテスト）の頭字語。test automationも参照のこと。

組織の品質マネジメントシステムのための規範に縛られない（non-perspective）フレームワークであり、EFQM(ヨーロッパ品質マネジメント財団: European Foundation for Quality Management)によって定義され、所有している。優れた品質マネジメントシステム実現に向けた、五つ …

開始、計画、および改善のアクションを実装するためのロードマップとして機能する組織的な改善モデル。IDEALモデルは、開始、診断、確立、行動、および学習の五つのフェーズにちなんで名付けられた。JSTQB訳注）IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。

テストプロセスを改善するための、継続するビジネス駆動のフレームワーク。効果的で効率的なテストプロセスの主要な要素を定義する。

要求仕様から保守までのソフトウェア開発ライフサイクル活動を表現したフレームワーク。V字モデルは、ソフトウェア開発ライフサイクルの各フェーズに、各テスト活動がどのように対応しているかどうかを示している。

イテレーティブ-インクリメンタル開発に基づくソフトウェア開発。自己組織化された機能横断的役割を担うチーム間での共同作業によって要件と解決策を発展させていく。

エクストリームプログラミング（XP）のような技法や手法が取り込まれているアジャイルソフトウェア開発方法論を用いたり、開発をテストの一部とみなしたり、テストファースト設計パラダイムを重視するプロジェクトで実施するテスト。

アセスメント結果、たとえば結論、提案、所見などをまとめたドキュメント。

アセスメントを実行する人。アセスメントチームのメンバー。

静的解析を行なうツール。

潜在的なユーザ、顧客または開発者のサイトではなく、開発組織の外部で独立したテストチームが、シミュレーションや実際のオペレーションにより実行するテスト。市販ソフトウェアでは、内部受け入れテストの一つとして実施することが多い。

ピアレビューの一種。ドキュメントの目視検査により、欠陥を検出する方法。これにより、たとえば、開発標準の違反や、上位レベルドキュメントへの準拠違反が見つかる。最も公式なレビュー技術なので、必ず、文書化された実施基準に従って進める。

ドキュメントの著者による段階的なドキュメント内容の説明。情報を集めて、内容の共通理解を確立するために行なう。

アジャイルソフトウェア開発の中で使用されるソフトウェアエンジニアリング方法論。中心となるプラクティスは、ペアプログラミング、徹底したコードレビュー、全てのコードの単体テスト、単純明快なコードなどである。

間違った結果を生み出す人間の行為。

特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。

効果や効率を示す高位レベルのメトリック。開発をコントロールし、方向性を決めるために利用する。たとえば、ソフトウェア開発のためのリードタイムの遅れ。

12の重要なプロセスから構成されるテストプロセス改善のためのコンテンツベースドモデル。企業の利益や評価に影響を与えるようなミッションクリティカルなプロセスやコンピタンスの状況を同僚や経営陣が判断できるよう高度に可視化したプロセスを含む。

優れたエンジニアリングプラクティス(たとえば、テストプラクティス)に関する詳細な説明を提供するプロセスモデル。

テストスイートが、ソフトウェアのどの部分を実行（網羅）し、どの部分が未実行かを判定する分析手法。たとえば、ステートメントカバレッジ、デシジョンカバレッジ、条件カバレッジ。

企業業績の状況に関するダッシュボードスタイルの表現。

三つのレベル、すなわち、概念的なレベル（ゴール）、運用上のレベル（クエスチョン）、定量的なレベル（メトリック）のモデルを用いたソフトウェア測定のアプローチ。

統合されたシステムが、特定の要件を満たすことを実証するためのテスト。

アジャイルソフトウェア開発におけるプロジェクト管理のための反復型でインクリメンタル型のフレームワーク。

プログラミング言語の実体。実行の最小単位。

許可されていない人またはシステムが情報またはデータを読んだり、修正したりすることができないように、および許可された人またはシステムが情報またはデータへのアクセスを拒否されないように、情報またはデータを保護するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用

組織のソフトウェアプロセスとその結果のパフォーマンスおよび成熟度を改善する活動プログラム。

ソフトウェアプロダクトの最初から最後、つまり企画段階から利用終了までの期間。ソフトウェアライフサイクルは通常、コンセプトフェーズ、要件フェーズ、設計フェーズ、実装フェーズ、テストフェーズ、インストールとチェックアウトフェーズ、運用と保守フェーズを含み、ときに廃棄フェーズを含むこともある。注）これらのフェーズは重複するこ …

フォールト（欠陥）の原因分析で使用する方法。特定の顕在化したフォールトと結びつく、故障やヒューマンエラーおよび外部イベントの関係を論理的に視覚化したモデルにする技法。

リスクの識別と分析(故障モードの識別と、発生防止策の試み)を行なう体系的なアプローチ。

アイテムの品質に影響を与えるフィーチャや特性。

テスト目的を明記したもの。テスト実施法のアイデアを含む場合もある。探索的テストにて使用する。

特定のプロジェクトのためのテスト戦略を実現化したもの。この中には、（テスト実施）プロジェクトのゴールと評価済みリスクに基づいて決めた決定事項、テストプロセスの開始ポイント、適用するテスト設計技法、テスト終了基準、実施するテストタイプを含む。

テストプロセスを通じて作成される、テストの計画、設計、実行に不可欠なもの。たとえば、ドキュメント、スクリプト、入力、期待結果、セットアップとクリーンアップの処理手順、ファイル、データベース、環境、その他、テストで使用する付加的なソフトウェアやユーティリティなど。

入力値、実行事前条件、期待結果、そして、実行事後条件のセットで、特定のプログラムパスを用いることや特定の要件が満たされていることを検証することのような、特定の目的またはテスト条件のために開発されたもの。

系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。

テスト実行中の連続した一区切りの時間。探索的テストでは、各テストセッションは一つのチャータに焦点を当ててテストを行なう。しかし、セッション中にテスト担当者は新しい気づきや問題に対してもまた探索することもある。テスト担当者はその場で作成して実行し、進捗を記録する。

一つ以上のテスト活動を支援するソフトウェア製品。たとえば、計画とコントロール、仕様化、初期ファイルやデータの構築、テスト実行とテスト分析を支援する。

テスト実行前に実在する（たとえば、データベースの中にある）データであり、テスト対象のコンポーネントやシステムに影響を与えたり、影響を受けたりするもの。

テスト活動をプロジェクト中で管理（マネジメント）しやすいフェーズにまとめたセット。たとえば、あるテストレベルの実行活動。

（テスト）専門家の集団。組織が使用するテストプロセスの定義、改善や保守を促進する。

アジャイルマニフェストにより表明された声明で、テストプロセスを改善するための価値を定義している。ここでいう価値とは以下のようなものである。・プロセスの詳細化よりも柔軟性、・テンプレート(ひな形)よりもベストプラクティス、・プロセス志向よりも展開志向、・品質保証(部門)よりもピアレビュー、・モデル駆動よりもビジネス駆動。 …

テスト改善計画に基づきテストプロセス改善を実行する人。

組織のテストプロセスとその結果のパフォーマンスおよび成熟度を改善する活動プログラム。

基本的なテストプロセスは、テストの計画とコントロール、テストの分析と設計、テストの実装と実行、終了基準の評価と報告、テスト終了作業によって構成される。

テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。

組織にとってのテストに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。

テストプロセスのマネジメントとコントロールを支援するツール。テストウェアマネジメント、テストスケジューリング、結果の記録、進捗管理、インシデントマネジメント、テスト報告等の能力を持つことが多い。

テスト活動の計画、見積り、監視、コントロール。主としてテストマネージャによって実施される。

テストの活動とリソースのマネジメント、テスト対象の評価に責任を持つ個人。テストプロジェクトを指揮、コントロール、運営し、テスト対象の評価を計画し統制する。

テストプロジェクトの状態の周期的なチェックに関連した活動を扱うテスト管理タスク。実際の活動と計画した活動とを比較した報告が準備される。

テスト活動からデータを収集して分析し、その後、データをレポートにまとめてステークホルダに情報を提供する作業。

テスト設計仕様、テストケース仕様、テスト手順仕様からなるドキュメント。

テストベースとテスト目的の定義を分析するプロセス。

あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。

テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。

テストデータを考え出し、テスト手順の開発および優先度付けを行なうプロセス。テストハーネスの準備や自動テストスクリプト記述を含むこともある。

能力成熟度モデル統合（CMMI）と関連させた５段階からなるテストプロセス改善のためのフレームワークであり、効果的なテストプロセスのための重要要素を記述している。

組織や(一つ若しくは複数プロジェクトの)プログラムで実施するテストレベルと各テストレベルでのテスト内容を高位レベルで説明したもの。

コンポーネントやシステムのテストを実施する熟練した専門家。

組織のテストプロセスとテストプロセスの資産について、長所と短所を徹底的に理解し、組織的にテストプロセス改善を達成することをベースとした計画。

テストを設計、実行する理由や目的。

テストプロセスに含まれるテスト終了作業フェーズの間、経験、テストウェア、事実、数字をまとめるために、データを完了した活動から収集する。テスト終了作業フェーズはテストウェアの仕上げ、保管とテスト評価レポートの準備を含むテストプロセスの評価からなる。

テストのさまざまな局面に紐付けられた概算結果(たとえば、工数, 完了日,コスト, テストケース数, など)。ただし、入力情報が不完全、または不確か、若しくは余計な情報を含んでいても実施できる。

達成すべきテスト目的およびそれらを達成するための手段やスケジュールを示し、調整したテスト活動を体系化したドキュメント。

テスト計画書を策定し、更新すること。

概略的なテスト目的を具体的なテスト条件とテストケースに変換するプロセス。

全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。

1つ以上のテストケースのセット。

反復的な四つのステップからなる問題解決のプロセス（計画-実施-評価-改善）。特にプロセス改善において用いられる。

2つのエンティティ（たとえば、要件とテストケース）を関係付ける2次元の表。この表を使用すると、エンティティ間の関係を前工程および後工程の双方向に追跡できるので、達成したカバレッジを測定でき、変更点の影響を評価できる。

ドキュメントとソフトウェアの関連事項（たとえば、ある要件と、それを検証するテストケース）を識別する能力。

コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。

企業の営業活動がその目的と整合しているかどうかをビジネスの構想や戦略の観点から評価するための戦略的ツール。

品質に対する考え方の一つ。品質は価格で定義することができる。プロダクトやサービスの品質は、許容できるコスト範囲内で望まれるパフォーマンスを提供するものである、というもの。この品質はステークホルダ間で、期間、労力とコストのトレードオフに基づく意思決定プロセスによって決められる。

意思決定における統計的手法の一つで、全体的影響を与える特定の重要な要因を選択するために使用される。品質改善の面では、問題の大半（80％）は少数の主要な原因（20％）によって発生する。

欠陥を識別して修正するため、プロダクト開発を担当している同僚がソフトウェア成果物をレビューすること。たとえばインスペクション、テクニカルレビュー、ウォークスルー。

問題のさまざまな根本的原因の相互関係を整理し示すための図表現。（潜在的な）欠陥あるいは故障をルートノードとする水平的なツリー構造を用いて、その欠陥あるいは故障の原因をカテゴリ、サブカテゴリに整理する。

製品開発環境以外の外部環境で、現在、あるいは、将来のユーザや顧客が実施するテスト。コンポーネントやシステムが、ユーザや顧客のニーズを満たし、ビジネスプロセスに適合するかを判定する。マーケットからのフィードバックを得るため、市販ソフトウェアの外部受け入れテストの一形式として用いることが多い。

コンポーネントまたはシステムの中で識別された欠陥の数をコンポーネントまたはシステムのサイズで割った値（サイズを表す標準的な尺度には、コード行数、クラス数、またはファンクションポイント数がある）。

あるテストレベルで見つけた欠陥の数をそのテストレベル、及び、以降のテストレベルで見つけた欠陥の総数で除算した値。

次のプロジェクトまたは次のプロジェクトフェーズを改善するために、教訓を学び、具体的なアクションプランを作成する構造化された方法。

（テスト）プロジェクトのマネジメントとコントロールに関係するリスク。たとえば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。

プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。

参照モデルを用いた、組織におけるソフトウェアプロセスの統制度合の評価。

共通の性質を持つプロセスによって全体的に統一されたモデルで表したフレームワーク。たとえば、テスト改善モデル。

品質に対する考え方の一つ。品質は明確に定義された品質の属性のセットに基づく、というもの。これらの属性は、客観的かつ定量的な方法で測定する必要がある。同じ種類のプロダクト品質の違いは、特定の品質の属性を実装した方法に由来する。

通常、複数のテストレベルを扱うテスト計画。

品質に対する考え方の一つ。品質はプロダクトまたはサービスが、その意図した設計と要件に準拠する度合によって測定される、というもの。品質は、使用されるプロセス（群）に依存する。

測定尺度、および、測定手法。

リリース後のコンポーネントやシステムを変更するプロセス。欠陥の修正、品質特性の改善、変更した環境への適合を目的とする。

品質に対する考え方の一つ。ユーザの必要性、要望、願望を、どこまで満たすか、というもの。要求を満たしていないプロダクトやサービスは、いかなるユーザの支持も得ることができない。この(ユーザベースド)品質は、背景によって異なる流動的なアプローチである。なぜならば、プロダクトごとに異なる品質の側面によりビジネスに求められる特徴 …

独自の適応性を持つ反復ソフトウェア開発プロセスフレームワーク。方向付け、推敲、作成、および移行の四つのプロジェクトライフサイクルフェーズで構成される。

リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを識別し、その後分析するプロセス。一般的に発生確率と影響度を割り当てることによって行なう。

影響度合と発生頻度からみた特徴で定義したリスクの重要性。リスクのレベルはテストを行なうときの強弱を決定するときに使われる。リスクレベルはまた、定性的（高/中/低など）または定量的に表現できる。

リスクの識別、分析、優先順位付け、コントロールのタスクに手順や実施方法を体系的に適用すること。

将来、否定的な結果を生む要素。

アセスメントを主導する人。CMMiやTMMiなどの公式なアセスメントを行なう場合は、リードアセッサーは、公式な訓練を受けて認定を受ける必要がある。

プロダクトやプロジェクトの状態を評価する手法。計画した結果との違いを分析し、改善を提案する。例として、マネジメントレビュー、非公式レビュー、テクニカルレビュー、インスペクション、ウォークスルーがある。

要求仕様、設計ドキュメント、ユーザドキュメント、標準など、または知見、経験から逸脱するあらゆる状態。レビュー、テスト、分析、コンパイルをする中で検出できるが、それだけにとどまらず、ソフトウェアプロダクトや該当するドキュメントを利用するときに検出できることもある。

人と人の心の内の交流分析。交流は刺激とその反応により定義される。交流は、人と人の間と、人の心の中にある自我の状態（個性の部分）の間に発生する。

指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力。[ISO/IEC 9126] JSTQB 訳注）JIS X 0129-1:2003 より引用

修正のしやすさに関するソフトウェア製品の能力。修正は、是正若しくは向上、または環境の変化、要求仕様の変更および機能仕様の変更にソフトウェアを適応させることを含めてもよい。JSTQB訳注）JIS X 0129-1:2003より引用

指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用

あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。

品質に対する考え方の一つ。品質は正確に定義することはできないが、みれば分かる、あるいは、欠落していることにも気づくものである、というもの。この品質は、個人やグループがプロダクトに対して持つ知見や思い入れに依存する。

コンポーネントが参照する変数。コンポーネント内部または外部に格納されている。

他人に対する過度の感情的および精神的依存。特に、人が望ましくない振る舞いをしている場合にそれを変えさせようとせず、その支援しか行なわないという精神的状態。たとえばソフトウェアテストにおいては、テストへの移行が遅延することについてクレームを付けはするものの、足りないテスト時間を補うために超過勤務する(ある意味)「ヒー …

制御フローとして、二つ以上の選択可能なルートがあるプログラムポイント。分岐を切り分けるため、二つ以上のリンクを持ったノード。

（1）明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力。[ISO/IEC 9126]JSTQB訳注）JIS X 0129-1:2003より引用 （2）使用するリソースの量に対比して、意図した結果を生成するプロセスの能力。

コンポーネントやシステムのソフトウェアを実行させて確認するテスト。

欠陥の根本原因の識別を目的とした分析技法。根本原因に是正を行なうことで、欠陥再発を最小化することが期待できる。

入力、刺激（原因）、関連する出力（結果）を図式表現したもの。テストケースの設計で使用できる。

システムを受け入れる判断に焦点を当てたテストレベル

品質にかかる活動や問題のトータルコスト。予防コストと評価コスト、内部失敗コスト、外部失敗コストというように分ける場合が多い。

品質マネジメントの一環としての運用技法および活動。品質要件を満たすことに重点を置く。

品質に関して組織を指揮し、管理するための調整された活動。注記 品質に関する指揮および管理には、通常、品質方針および品質目標の設定、品質計画、品質コントロール、品質保証および品質改善が含まれる。JSTQB訳注）JIS Q 9000:2006より引用

品質マネジメントの一部。品質要件を満たしていることの確信度合に焦点を当てている。

コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。

欠陥の認識、調査、欠陥に対する行動、処置のプロセス。欠陥の記録、分類、および、影響の識別を含む。

(1)個人やチーム、組織を現在の状態から望ましい状態へと移行させるための構造化されたアプローチ。(2)プロダクトやサービスに対して変更あるいは提案された変更を達成するためのコントロールされた方法。

検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。

IDEALモデルの1フェーズであり、経験から学習し、将来の新しいプロセスと技術を適用するために自らの能力を向上させる。学習フェーズは、分析、妥当性確認、および以降の活動提案によって構成される。JSTQB訳注）IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。

システムが故障から回復するまでに要する平均時間。これには一般的に欠陥が解決されていることを保証するテストが含まれる。

システムにおける故障から次の故障までの平均時間。MTBFは、通常、欠陥修正プロセスの一部として、障害が発生したシステムを直ちに修復することを想定した信頼度成長モデルの一部である。

特定の要件を変更する前に、開発ドキュメント、テストドキュメント、コンポーネントの各階層が、変更によりどのような影響を受けるか評価すること。

コンポーネントやシステムが、定義した機能を達成するために使用する時間、リソース、容量の度合。

自己や他者、グループの感情を理解し、評価し、管理する能力、技能のこと。

組織の成熟度の特定側面を構造的に記述した集合体で、組織のプロセスの定義と理解を助ける。成熟度モデルは、多くの場合、共通言語、ビジョンの共有、および改善活動の優先順位を付けるためのフレームワークを提供する。

定義済みプロセス領域のセット全体において、セット内の全てのゴールが達成されているプロセス改善の度合。

(1)プロセスや作業の有効性と効率に関する組織の能力。(2)ソフトウェアに潜在する障害の結果として生じる故障を回避するソフトウェア製品の能力。

増加する負荷に応じてソフトウェア製品をアップグレードできる能力。

他の測定値の見積りまたは予測に使うことができる測定値。

非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。

コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること。

レビューミーティングで指摘された欠陥や、改善の提案を、所定の書式に記録する人。書記は、記録が読みやすく、理解しやすくなるように留意しなくてはならない。

意図する結果を生成する能力。

欠陥の発生源のことで、根本原因が除去されると、欠陥が削減または除去される。

客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用

技術的かつ管理的な指示と監視を適用する規範。この規範の目的は、・構成アイテムの特性を機能的、物理的に識別・文書化すること、・特性に対する変更をコントロールすること、・処理の変更と実装の状況を記録し、報告すること、・特定の要求への整合を実証すること、である。

規格、規約または法律上および類似の法規上の規則を遵守するソフトウェア製品の能力。

公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)

ソフトウェアが、指定された条件の下で利用されるときに、明示的および暗示的必要性に合致する機能を提供するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用

成熟度レベルとして確立したプロセスエリアのゴールに達したかをみるモデル構造であり、各レベルは次のレベルの土台となるよう組み立てられている。

測定することによって、ある実体の特性に付加した数字や種別。

ある実体の特性を表すため、数字や種別を付加する手順。

標準、ガイドライン、仕様、客観的な基準に基づいた手続きに遵守することを確認し、（1）開発するプロダクトの形式や内容、（2）プロダクトの開発プロセス、（3）標準やガイドライン遵守の測定方法の3つを規定したドキュメント等を含む、ソフトウェアプロダクトや開発プロセスの独立した評価。

一つ以上の指定されたシステムと相互作用するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用

IDEALモデルの1フェーズであり、組織が、計画された目標にどのように到達するかを特定する。確立フェーズは、優先順位の決定、アプローチの開発、行動計画の活動によって構成される。

ある環境から他の環境に移すためのソフトウェア製品の能力。備考：環境には組織、ハードウェアまたはソフトウェアの環境を含めてもよい。

統合したコンポーネントやシステムのインターフェースや相互作用の欠陥を摘出するためのテスト。

全てのメンバーが参加することを基本に、社会の利益と組織のメンバー全員の利益と顧客満足を通じた長期的な成功を目的とした品質中心の組織全体のマネジメントアプローチ。総合的品質管理は、計画、組織化、監督、コントロールと保証からなる。

効率的にプロダクトを開発・保守するためのプロセスの重要要素を記述したフレームワーク。プロダクトの開発・保守における計画、エンジニアリング、マネジメントでのベストプラクティスをカバーする。

IDEALモデルの1フェーズであり、改善を展開し、実践し、組織全体に導入する。行動フェーズでは、解決策の創造、試行/試験的導入、改良、実行の活動によって構成される。JSTQB訳注）IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。

コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。

ユーザが問題解決や目的を達成するために必要な条件や能力。契約、標準、仕様、その他の公式ドキュメントを満足するために、システムやシステムコンポーネントが満たし、保持すべき条件や能力。

IDEALモデルの1フェーズであり、現在の状態と改善後の状態を明らかにする。診断フェーズは、現在の状態と望ましい状態を明らかにしたり、改善すべき点を明らかにする活動で構成される。 JSTQB訳注）IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。

コンポーネント、システム、人が、適格要件に従っていることを確認するプロセス。たとえば、試験に合格するなど。

特定のプロセスエリア群内でのプロセス改善アプローチのための推奨順番として提供された、能力レベルをみる成熟度モデル構造。

コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。

組織やプロジェクトが使命を全うするために必要な要素。成功を確実なものにするために不可欠な要因や活動。

IDEALモデルの1フェーズであり、改善活動が成功するための基盤を具体化する。開始フェーズは、活動背景の確認、支援体制および活動体制の構築によって構成される。JSTQB訳注）IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。

ソフトウェア開発の成果物（要件、設計、または、コードなど）の実行をせずに実施する成果物のテスト。たとえば、レビュー、静的解析など。