システム開発技術の基本☆ソフトウェアの開発からシステムテストを経て、実際に引用されるまでの流れ

システムを構築する際の設計に関して、要件定義から具体的なシステム開発までの流れをまとめて解説しましょう。

システム開発技術

システム開発では、システム利用者の様々なニーズを的確に聞き取り、その内容を正しくシステムに反映させる必要があります。

大規模になればなるほど、多くの人が関わることになります。

システム開発の担当者相互間、システム開発者とその利用者等他の利害関係者との間に認識のズレがあると、システム開発に大きな影響をおよぼす可能性があるのです。

そのようなことにならないように、システムを開発するためには、作業内容や評価などを標準化し、その手順を適切に実施することが重要でしょう。

システム開発の標準的な手順は、既に実施してきた「要件定義」に基づき、「設計」→「開発・テスト」→「受入」→「移行」と実施し、システムが稼働すると「運用・保守」へと進んでいきます。

コンテンツ

システムの設計

要件定義書が確定したら、それに基づいて、次はシステムの設計を行います。設計は、「システム方式設計」「ソフトウェア要件定義」「ソフトウェア方式設計」「ソフトウェア詳細設計」の手順で行うのです。

システム方式設計

「システム方式設計」では、要件定義において定められたすべての項目を、ハードウェアで実現する内容、ソフトウェアで実現する内容、手作業で実現する内容に分類します。

それらを実現するために必要な構成品目を決定し、それらに合せたネットワークの構成等を整理するのです。

システム方式設計を行う際には、要求されているシステム仕様が確実に、安定的に実現可能か、リスク等を考慮した選択肢の中から検討されているか、効率的な運用や保守が可能か等を考慮しなくてはなりません。

システム方式設計を行うことで、利用者目線での機能の概要と利用者自身の作業範囲が明確となり、運用や保守までを考慮した設計が可能となります。

設計した内容は、「システム方式設計」の内容を示す設計文書として整理しておきます。

この「システム方式設計」と、次で説明する「ソフトウェア要件定義」は、いわゆる「外部設計」に対応すると考えることもできるのです。共同レビュー

「システム方式設計」においてハードウェアの構成を考える場合には、システムの信頼性や性能要件に基づいて検討しなくてはなりません。

金融システムなど、システムが停止した場合に社会的な影響が大きいものに関しては、ハードウェア構成やネットワーク構成の二重化などを検討し、システム全体が停止することがないような設計を考慮することも重要です。

このようなシステム全体の停止を防止する多重の設計を「フォールトトレラント設計」といいます。

その他にもサーバの機能配分や負荷分散などを検討し、費用対効果の面からも、コストの配分に関しても同時に考慮しなくてはなりません。

ソフトウェアの構成に関しては、全てを自社開発するか、ソフトウェアパッケージを活用するかなどの検討が必要です。

このシステム方式設計の工程を終了できる品質が確保できているかどうかを判断するために、決定したシステム方式が要件定義に合致しているかどうか、共同レビューで確認します。

ソフトウェア要件定義

「ソフトウェア要件定義」とは、システム方式設計で定義された内容をもとに構成するソフトウェアに求められる要件を定義したものです。

ソフトウェアの要件を定義するために必要となる要素には、画面のインタフェース、操作性、帳票設計、ファイル・データ定義、他システムとのインタフェース、運用・保守の方法、動作する環境条件・機能・能力、情報セキュリティ等があります。

システム開発者は、利用者が求めていることとソフトウェアで実現する具体的な内容を確認して、ソフトウェア要件の内容を決定します。

定義した内容は「ソフトウェア要件定義」の内容を示す設計文書として整理するのです。

本工程が終了する時点でも、次の開発工程がスムーズに行えるように、決定したソフトウェア要件が要件定義、システム方式設計に合致しているかどうか、レビューで確認します。

「ソフトウェア方式設計」では、ソフトウェア要件定義をもとに、システムの要件を実現するために必要なソフトウェアの構成とソフトウェアコンポーネントの分析・検討を行い、設計します。

ソフトウェア方式設計は、システムを開発する視点からみた機能等の設計となるため、プログラミングも意識した内容です。

ソフトウェアコンポーネント

「ソフトウェアコンポーネント」とは、他のソフトウェアコンポーネントと組み合わせることで、特定の機能を実践するプログラム部品のことです。

ソフトウェア方式設計では、ソフトウェア要件定義をもとに、各機能を分割してソフトウェアコンポーネントによる構造化の設計を行います。

これらのソフトウェアコンポーネントは組み合わせて利用するため、それぞれのデータの受け渡しのための入出力インタフェースや、ソフトウェアコンポーネントの機能などを明確にした、ソフトウェアコンポーネント間インタフェース設計が必要です。

ここで設計した内容は、「ソフトウェア方式設計」の内容を示す設計文書として整理します。

ソフトウェア方式設計は、システムの内部機能の設計であるため、システムの利用者は関与しません。

ソフトウェアユニット

「ソフトウェア詳細設計」では、ソフトウェア要件及びソフトウェア方式設計に対して、実装し、検証し、コーディング及びテストの実施を可能とするために十分に詳細である設計を行います。

詳細設計では、一連の動作の流れ、データベースへのアクセス方法の取り決めや、各機能の詳細な設計を行います。

ソフトウェア方式設計で分割されたソフトウェアコンポーネントはさらに細分化されて、「ソフトウェアユニット」になります。

ソフトウェアユニットはソフトウェアを構成する最小単位で、この単位でコーディングや単体テストなどが行われます。

一般にソフトウェアユニットに分割することを、「ユニット分割」又は「モジュール分割」といいます。

モジュールに分割をして、各モジュールの設計をすることを「プログラム設計」といいます。

ここで設計した内容は、「ソフトウェア詳細設計」の内容を示す設計文書として整理するのです。

ソフトウェア詳細設計はシステムの内部機能の設計（「内部設計」）であるため、システムの利用者は関与しません。

開発・テスト

設計フェーズが終了したら、次は「開発・テスト」です。

「プログラム開発」⇒「単体テスト」⇒「結合テスト」⇒「総合テスト」と進みます。

「プログラム開発」とは、「ソフトウェア詳細設計」に基づいて、プログラム言語の文法に従って、処理手順を記述し、個々の動作検証（単体テスト）まで行います。

このシステム要件定義で定められた機能や能力がすべて備わっているかを確認する工程が「システムテスト」です。

プログラムレビュー（ソースコードレビュー）

プログラム言語で記述されたプログラムを、「ソースプログラム」と言います。「ソースコード」と呼ばれるもあります。

アルゴリズムやデータ処理をソースコードで記述することを、「コーディング」と言います。

コーディングが終了したソースプログラムに対して、「プログラムレビュー（ソースコードレビュー）」を行うのです。

プログラムレビューとは、記述されたプログラムがソフトウェア詳細設計に従って正しく記述されているかどうか、また可読性や保守性が高いかどうかという視点で確認することです。

この際に、記述されたソースプログラムがシステム詳細設計書に従って正しく記述されているか検証することを、「プログラムインスペクション」ということもあります。

プログラムレビューが終了しても、コンピュータはソースプログラムを理解することができません。

ソースプログラムを、コンピュータが理解できるオブジェクトプログラムに変換します。この変換することを「コンパイル」と言います。また、変換するソフトウェアを「コンパイラ」と言います。

この時、ソースプログラムに文法的に誤った記述があるものは、コンパイルができませんので、ソースプログラムの記述を見直す必要が生じます。

単体テスト

プログラムを作成したら、ソフトウェア詳細設計書通りに動作するかどうかをテストします。

このことを「単体テスト」と言います。

単体テストでは、個々のモジュールに論理的なエラーが無いか、ソフトウェア詳細設計書通りに動作するかを確認します。

このフェーズでは一般的に、ソフトウェア詳細設計の制作者、及びプログラム開発者が中心となってテストを実行。

単体テストの手法には、内部構造に着目して実施する「ホワイトボックステスト」を用います。

ホワイトボックステスト

「ホワイトボックステスト」とは、システム開発者側の視点から行われるもので、プログラムの制御や処理の流れなどの内部構造に着目したテストです。

単体テストにおいて使われる技法で、各々のモジュール内の誤り（バグ）を発見することを目的としています。

ホワイトボックステストのテストケースを作成する方法として、「命令網羅」と「条件網羅」があります。

命令網羅とは、プログラムで実行されるすべての命令をカバーするように、テストケースを作成する方法です。

条件網羅とは、すべての条件分岐を通過し、その条件式が真になる場合と偽になる場合との両方をカバーしたテストケースを作成する方法です。

「結合テスト」と「総合テスト」

単体テストによる個々のモジュールの動作確認が終了したら、順次モジュールを結合した状態でのテストを実施します。

ここでは、要件定義書や設計書で指示した内容通りにシステムが正常に動作するか、またそのシステムが運用に耐えられるかなどをテストするのです。

テスト工程は、「結合テスト」、「総合テスト」に分かれています。

単体テストでエラーが検出されない場合でも、順次モジュールを結合することによって新たにエラーが検出される場合があります。

そのようなエラーを発見するために、テスト計画をしっかり立て、テスト実績を評価しながらテストを実施していく必要があるのです。

テスト実施手順

テスト実施手順は図のとおりです。

「テスト計画の作成」では、テストの目的、主要な確認事項、テストのスケジュール、テスト実施者の体制、使用するテストツール、テストの方法、評価基準などを決めます。

「テスト仕様の設計」では、要件定義書や設計書などで記述されている仕様に基づき、テストデータと、正しく処理した場合の処理結果の対応などを設計します。

「テスト環境の設定」では、テスト仕様に基づいて、テストデータの作成や、テストで使用する機器の設置、ソフトウェアの準備・設定などを行い、テストが実施できる環境を構築。

「テストの実施」では、テストデータを作成する際に、条件に合った大量のデータを作成するテストジェネレータ等のツールを使用するなど、効率的なテストの実施を目指すのです。

テスト実施をした後は、結果の記録や分析、エラーに対するプログラムの修正などの作業が発生します。

「テスト結果の評価」では、テスト結果のデータを分析することで、システムに問題点が無いかどうかを評価します。

結合テスト

個々のテストで実施される中で、「結合テスト」は、モジュールやプログラムを順次結合して行うテストです。

単体テストで発見された全てのバグが修正されたモジュールやプログラムが対象となります。

結合した各モジュール間のデータの受け渡しや画面の遷移が正しく行われるかどうかは、単体テストでは検証できていないケースなので、重視する必要があります。

テストのやり方としては「トップダウンテスト」と「ボトムアップテスト」があるのです。

テストの範囲としては、「ソフトウェア方式設計」で記述されている処理が正しく実行されるかどうかを確認します。

一般的には「ソフトウェア方式設計」の担当者がテストケースを作成し、システム開発担当者がテストを実施。

結合テストの手法には、「ブラックボックステスト」があります。

ブラックボックステスト

「ブラックボックステスト」とは、利用者側の視点から行われるもので、プログラムの入出力に着目したテストです。

結合テスト以降で使われる技法で、機能が仕様書通りに動作するかどうかをチェックすることを目的としています。

業務で実際に使われるデータに近いデータ、またケースによっては非現実的なデータを入力して、出力結果が仕様書通りであることを検証するのです。

あくまでも、プログラム部分はブラックボックスであるため、入力データと出力結果に注目します。

テストケースを作成する具体的な方法としては、「同値分割」や「限界値分析」などがあります。

同値分割

「同値分割」とは、入力するデータを、正常に処理する値（有効同値クラス）と、処理が行われなかったりエラーとなる値（無効同値クラス）に分け、それぞれを代表する値を用いてテストを行います。

少ない項目数でより広い範囲をカバーできるテスト手法です。

図の例では、18℃～27℃の間で処理が行われるため、有効同値クラスから「23」、無効同値クラスから「15」「31」というデータを用いてテストを実施します。

限界値分析

「限界値分析」とは、同値分割の境界となる前後の値を用いてテストデータを作成する方法です。

少ない項目数でより広い範囲をカバーできるテスト手法で、出力結果が変化する境界付近の条件文の記述ミス等を重点的に調べることができます。

上記の例では、18℃～27℃の間で処理が行われるため、下限の境界値（限界値）は“17”と“18”、上限の境界値（限界値）は“27”と“28”となります。

本ケースは1℃ごとの計測を想定していますが、「17.5℃」などという小数点を設けた計測等を行う場合は、境界値が異なります。

また、「以上」「以下」「未満」などにおける数値の取り扱いなども確認する必要があるので、境界値では、テストケースの漏れがないように設定する必要があるのです。

トップダウンテスト

結合テストの手法の1つである、「トップダウンテスト」とは、上位のモジュールまたはプログラムから順番にテストを行う方法のことです。

全てのモジュールが完成していない場合や、モジュールを段階的にテストしていく場合に、上位モジュールから呼び出すだけのために作成された仮の下位モジュール「スタブ」を用いて行います。

上位モジュールの機能が確認できたら、「スタブ」をモジュールに置き換え、さらに下位に「スタブ」を設けて徐々にテストを実施。

最上位のモジュールからテストを行うため、プログラムの機能の抜け漏れが発見しやすいこと、使用頻度が高い上位モジュールの信頼性が高くなるなどの特徴があります。

ボトムアップテスト

「ボトムアップテスト」とは、下位のモジュールまたはプログラムから順番にテストを行う方法のことです。

トップダウンテストと同様に、上位モジュールが完成していない場合、または各モジュールを段階的にテストするために、上位モジュールに仮のモジュール「ドライバ」を準備します。

大規模なシステムの場合は、ツリー構造の下位から、同時並行で効率的にテストを行える利点があるのです。

その一方で、メインとなる上位の問題の発見が遅くなるという欠点もあります。

総合テスト

「総合テスト」とは、「システム方式設計」にて定められている仕様通りに、正しく動作しているかどうか確認するテストです。

ハードウェア構成品目、ソフトウェア構成品目、ネットワーク等を全て結合した後に行うテストです。

システムの全てを検証するフェーズなので、手作業の部分の検証も含まれます。

一般的には、システム方式設計の担当者がテストケースを作成し、テストを実施します。機能テスト分類

総合テストでは、目的に応じて「機能テスト」「非機能テスト」を実施します。

非機能テストには、「性能テスト」「例外処理テスト」「負荷テスト」「操作性テスト」「回帰テスト」などがあります。

信頼度曲線（ゴンペルツ曲線）

テスト実施の段階において、テスト結果の記録や分析を行い、最終的な品質の判定をする必要があります。

その際に、バグの収束状況がわかるように、図のように、横軸にテスト開始からの期間を、縦軸にエラー発生の累積件数を示して、グラフで表示します。このグラフは信頼度曲線（ゴンペルツ曲線）とも呼ばれます。

図のような推移でバグの累積曲線がＳ字カーブを描けば、経験的に適切なテストが実施され、品質としても信頼がおけるシステムであるといえます。

受入テスト

システム開発の発注者は、システムの納品時に、受入テストや検収を行います。

受入テストでは、要件定義書に記載した要件が満たされているか、システムが正常に稼働するか、契約内容通りにシステムが稼働するか等、システム開発の発注者が確認します。

このとき、関連部門の協力を得ることも大切です。

受入テストに問題がない場合は、システム開発者はシステム開発の発注者にシステムを納品し、発注者は検収を行います。

「受入テスト」の一側面として実施する「運用テスト」では、操作マニュアルや運用マニュアルが正しく作成されており、それらに基づき稼働できるかどうかを確認します。

テストデータには、業務的な実務上の確認も必要なため、業務で使用している実データを用いることも多いです。

システムの移行

完成したシステムの移行にあたって、システムをスムーズに移行させるための計画を作成します。

具体的には実環境にシステムを移行させる移行要件や、既存のシステムの扱いを取り決める移行要件の作成などがあります。

これらの移行の準備作業は、要件定義、設計等の早い段階で着手し、必要に応じて情報システム本体の開発・テスト等に先立ち、移行のためのツール等の開発・テストを実施しておくことが大切です。

情報システムが完成し「受入」できることを確認し、「移行」を実施しても良いと判断されたら、移行作業を行います。

移行の際には、利用部門やシステム運用部門とで連携を図り、スケジュール通りに実施できるよう進めていきます。

移行に先立ち、システムを利用し、運用するための教育訓練を行うことも必要です。

その際には、講習会の実施や利用者マニュアルの作成などを行い、運用段階に入っても継続的に支援をしていきます。

システムの運用

情報システムが完成したら、その情報システムを業務に活用して、業務の円滑な運営を図ることになります。

情報システムを安定的かつ効率的に運用を行うことが大切です。

情報システムの起動、計画されたJOBの実行・管理、情報システムの監視、資源の管理などについて、専門的に対応する必要があります。

最近では、これらの統合的な実施を目指して、「ITサービスマネジメント」として体系的に取り組むことが多くなっています。

システムの保守

システムやソフトウェアを導入して受入が完了した後も、運用中に発見された不具合や新たに発生した修正事項に関しては、取り決められた契約に基づいて、対応しなくてはなりません。

大きなトラブルが生じないように、日常的な運用においても、点検作業を実施する必要があります。

このような作業を「保守」と言います。

ここで注意しておくことに、「保守」と「改修」の違いがあることです。制度や要求が変わり、システムの機能を加除改訂することは、「保守」とはいいません。「改修」等として「保守」とは切り分けて考えます。

保守の内容には様々な項目が含まれます。保守の実施内容や条件を明確にして、保守を提供する側と受ける側とで、しっかりと合意するとともに、SLA（Service Level Agreement：サービスレベル合意書）により、提供されるサービスレベルについて合意しておくことが大切です。

決定した保守要件に従い、必要に応じた保守契約を結ばなくてはなりません。

また、問題の発生や改善への対応としてシステムの修正などを行う際には、既存のシステムやソフトウェアへの影響を確認するため、「回帰テスト（リグレッションテスト）」を実施します。

保守の形態には様々なものがありますが、主な保守作業としては以下の表のようなものがあります。

システム保守の種類

ソフトウェアの規模の見積り

システム開発は、業務の効率化を生む一方で、開発コストが生じます。

業務システムを導入する場合には、コストを意識した検討が必要となります。

そのためには、開発するソフトウェアの規模をより正確に見積ることが大切です。

代表的なソフトウェアの規模の見積方法は上記表のとおりです。

ソフトウェア開発管理技術

ソフトウェア開発手法

「ソフトウェア開発手法」とは、ソフトウェアの開発工程の進め方のことです。

ソフトウェアの品質向上を目指して、様々な開発手法が提案されています。

表にあげた手法の他に関連用語を解説します。

◎DevOps： “Development”（開発）と“Operations”（運用）の略語を組み合わせた造語。開発担当と運用担当が密接に協力する体制をつくって、ソフトウェア導入や更新を迅速に進めること。

ソフトウェア開発モデル

「ソフトウェア開発モデル」とは、高品質のソフトウェアを効率的に開発するために用いられる開発モデルです。

代表的な開発モデルには、「ウォータフォールモデル」「スパイラルモデル」「プロトタイピングモデル」「RAD（Rapid Application Development）」「アジャイル」「リバースエンジニアリング」等があります。

ウォータフォールモデル

「ウォータフォールモデル」とは、滝が落ちるという名前の通り、プロジェクト全体をいくつかの工程に分解し、上流工程から下流工程に向かって各工程を順番に実施するモデルです。

前の工程で作成された成果物を引き継ぐ形で、次の工程に進みます。

大規模開発で多く用いられ、基本的には前工程への後戻りはしません。大規模開発で開発期間が長期になる場合などは、当初の要件の変化に柔軟に対応できないというデメリットがあります。

スパイラルモデル

「スパイラルモデル」とは、「要件定義」「設計」「開発」「テスト」のサイクルを繰り返しながら、システムの精度を上げていくモデルです。

サイクルごとにユーザのフィードバックによって改善されていくので、要件定義とのずれが少ない開発をすすめることができます。

その一方で、ウォータフォールモデル等と比較して、開発期間が長くなるという欠点もあります。

プロトタイピングモデル

「プロトタイピングモデル」とは、システム開発の早い段階から、「プロトタイプ（試作品）」を作成し、利用者に対してレビューを行ない、そのレビューの内容を開発に取り込んでいく開発モデルです。

プロトタイプを用いることで、要件定義ではあいまいだった事項が明確になり、利用者と開発者の間での認識の違いや誤解を早期に解消することができます。

しかしこのソフトウェア開発モデルも、スパイラルモデルと同様に、試作品の繰り返しの作成により、開発期間が長くなるという欠点があります。

RAD(Rapid Application Development)

「RAD」とは、Rapid Application Developmentの略で、「高速アプリケーション開発」と訳されます。

開発に携わる人員を限定し、プロトタイプを作成して、設計、開発、テストを繰り返し行う開発モデルです。

「タイムボックス」という一定の開発期間を設定し、その期間が経過したら、その時点で強制的に次の工程に移っていくことで、高速で開発を進めるように工夫しています。

このモデルは、プロトタイピングモデルの欠点である開発期間の延伸を防ぐことができます。しかし、品質ではなく時間で区切って作業を次フェーズへ展開していくため、プロトタイピングモデルに比べて、品質に配慮しながら検討を進めることが大切です。

アジャイル

「アジャイル」とは「俊敏な」という意味で、数週間という短い期間で、繰り返し開発を行うモデルです。

その場で出される要求仕様に柔軟に対応できるというメリットがあります。

代表的な手法にXP（extreme programming ：エクストリームプログラミング）があります。XPでは、利用者の要望を聞き取り、そこから出てくる内容を要求仕様として開発していきます。

設計書の作成よりも、実際に動くソースコードの作成を重視します。再設計を何度も行うことで、柔軟なシステム開発が行えるのです。

プログラミング開発は、2人1組で行う「ペアプログラミング」での開発が基本となります。

そのうち1人が「ドライバ」としてキーボードを操作してコード記述を担当し、もう一人が「パートナ（ナビゲータ）」としてコード記述の指示・提案・誤りの指摘・助言などを行います。

ソフトウェアの動作を変えずに、プログラムの内部構造を変更する「リファクタリング」や、テスト対象のコードを単体テストケースを作成してから実装する「テスト駆動開発」などで開発を行う手法があります。

その他「スクラム」という手法もあります。

スプリントと呼ばれる反復期間を繰り返すことで、機能開発を増加的に行います。

プロジェクトの状況や進捗の確認を毎日行ったり、定期的に機能の確認を行うなど、開発チームが一丸となってラグビーのスクラムのようにゴール到達をめざす開発手法です。

リバースエンジニアリング

既存のプログラムを機械語等から解析したり、ソフトウェアの動作を解析したりして、ソフトウェアやシステムの構造を分析して、ソフトウェアの動作原理、設計図、ソースコードなどを調査することを「リバースエンジニアリング」といいます。

自ら開発したソフトウェアであっても、開発から時間が経って設計図や仕様書の所在が不明になったり、作成されていなかったり、種々の場合に必要になることもあります。

共通フレーム2013（SLCP-JCF2013)

ソフトウェア取引にかかる「共通フレーム」とは、情報処理推進機構（IPA)が策定した、システム及びソフトウェア開発とその取引に関する標準的なガイドラインのことです。

利用者と開発者が共通で理解できるように、ソフトウェアの構想・設計から、開発、導入、運用、保守、破棄に到るまでの各工程について、個々の作業内容、用語の意味などを統一し、共通の枠組みを持つための標準的なモデルを示したものです。

システム開発に必要な「作業」について、役割の観点でまとめたもので、工程や成果物を規定しているものではありません。

「SLCP（ソフトウェアライフサイクルプロセス）」に沿って整理されています。

共通フレームは、ソフトウェアや情報処理システムの開発者（受注者）、それらを利用したサービス事業者（発注者）が、言葉の意味（範囲）の解釈の違いによるトラブルを予防する（誤解を招かぬようにする）ためのものです。

“同じ言葉を話す” ことができるよう共通の枠組みを提供し、ソフトウェアの構想から開発、運用、保守、廃棄にいたるまでのライフサイクルを通して必要な作業内容を包括的に定めたものです。

2013年に情報処理推進機構（IPA)が「共通フレーム2013（SLCP-JCF2013)」を定め、国際標準である「ISO/IEC 12207」及び対応する我が国の標準である「JIS X0016」を日本の商習慣に合わせて拡張しています。

能力成熟度モデル（CMMI：Capability Maturity Model Integration）

組織としての開発プロセスの成熟度を表す指標として「能力成熟度モデル（CMMI：Capability Maturity Model Integration）」があります。

「能力成熟度モデル」とは、システム開発や保守を行うためのプロセスを評価したり、改善したりするための指標のことです。

個人としての能力に依存しない、組織としての開発能力を客観的に評価できる指標で、アメリカのカーネギーメロン大学ソフトウェア工学研究所（SEI)で考案された「CMMI」により、その成熟度が5段階レベルで定義されています。

「成熟度レベル1」とは初期段階のことで、プロセスは場当たり的なもので、開発標準等の秩序が無く、担当する人員の力量に依存するレベルです。

「成熟度レベル2」とは管理段階のことで、要件の管理、プロジェクトの基本的な管理が行われているレベルです。

「成熟度レベル3」とは定義段階のことで、組織全体でプロセスが標準化されており、さらに継続的に改善がされているレベルです。

「成熟度レベル4」とは定量的な管理段階のことで、プロセスを定量的に把握して、プロセスの実施結果予測の手法を持っていたり、定量的な目標が設定できたりするレベルです。

「成熟度レベル5」とは、レベル4の定量的な管理のもと、さらに自発的に新しい取り組みや、改善のための調査、問題の未然の防止や継続的な改善に取り組めるレベルです。