ソフトウェア開発プロセスにおける要件の役割に関する記事を執筆中に 、Rational Software要件スペシャリストJim Heumannの 1人によって2003年に提案された要件管理の成熟度の成熟度スケールを発見しました。
この分類をhabrahabr読者と共有したいと思います。
はじめに
「 成熟度 」という用語は、システムの完全で完成した開発として定義されます。 開発にはコストが必要なため、ビジネスのコンテキストでは、組織が自身の開発への投資額を決定し、そのメリットを明確に理解することを意味します。
以下は、CMMIモデルと同様に構築された要件管理プロセスの成熟度のスケールです。 これらのモデルは相互接続されていませんが、いくつかの交差点があります。 したがって、要件管理プロセスの成熟度のレベル5（要件の統合）を達成すると、CMMIモデルに従って少なくともレベル3（組織全体のレベルでプロセスが定義されます）を取得できます。 ただし、これは直接的な結果ではありません。1つのプロセスで高いレベルの成熟度を達成しても、組織全体の成熟度の全般的な向上が保証されるわけではないためです。
成熟度スケール
レベル0。要件の欠如
このレベルは、ソフトウェア開発プロセスの主なものがプログラミング（コーディング）であり、要件がないことはまったく許容できると考えるチームにとって典型的です。
この場合、プロジェクトチームは、ソフトウェア製品の開発をすぐに開始するためにすべてを知っていること、および要件を収集、分析、文書化する段階で節約された時間のおかげで、将来、プログラミングにもっと注意を払うことができると信じています機能が多すぎます。
結果は次のような製品です：
- 必要な機能がありません。
- 機能が過剰です。
- 低品質です。
多くの場合、要件が不足しているため、プロジェクトチームのメンバー間で紛争や誤解が生じ、スタッフが変更されると、要件の一部が失われる可能性があります。
レベル1.文書化要件
要件の完全な欠如からその外観に移行するための最初のステップは、要件の識別と文書化です。 この段階では、要件の説明フォームは特に重要ではありませんが、要件の存在という事実がさらなる作業の基礎となります。
要件の記録と保存を開始すると、プロジェクトチームには次の利点があります。
- 一連のドキュメントが表示され、そこからプロジェクトチームが顧客のニーズをどのように理解したかが明確にわかります。 顧客と要件のリストに同意すると、プロジェクトチームはプロジェクトの境界を明確に確立し、予算と決定のタイミングを決定できます。
- 開発チームのすべてのメンバーの作業の基礎となるドキュメントが表示されます。 たとえば、設計者と設計者はインターフェイスとアーキテクチャの作業を開始でき、テストの専門家は将来の機能のためにテストスクリプトを準備できます。
- 新しいプロジェクト参加者向けに作成されたアプリケーションの機能に関する知識のソースが表示されます。
- 要件を記録して保存することで、いつでも要件を復元できるため、人員の変更や要件の喪失に関連するリスクが軽減されます。
多くの場合、この段階では、要件（要件の仕様）を説明するドキュメントの品質が低いため、プロジェクトチームは主題の専門家または顧客による要件のチェックに頼ります。
レベル2.組織の要件
プロジェクトチームは、要件を説明するドキュメントを持って、開発された製品の望ましい動作を明確に、一貫して、明確に説明する要件のセットを取得するタスクに直面しています。 指定された品質基準で要件を取得するには、仕様を作成するために受け入れられているルールを遵守し、すべてのプロジェクト参加者がアクセスできる場所にそれらを保存し、要件へのアクセス権を区別し、変更の履歴を保持する必要があります。
時間の節約のために仕様の設計に十分な注意が払われていない場合、不十分に設計されたテキストは詳細な要件さえも不要にする可能性があります。 見出しの使用、図の番号付け、目次の存在など、文書の書式設定に関する基本的な規則を遵守することで、文書を読みやすく、理解しやすく、使いやすくすることができます。 開発会社のレベルで採用されたテンプレートまたは顧客によって提供されたテンプレートを使用すると、要件の説明を準備するタスクを大幅に簡素化できます。
識別子要件の課題は要件をユニークにします。 単一のリポジトリに仕様を配置すると、要件にアクセスできるようになり、ドキュメントへのアクセスを制限することで、権限のある人にのみ変更を加えることができ、 整合性が確保されます 。 バージョン管理を使用すると、プロジェクトチームに仕様の現在のバージョンで作業し、要件の変更履歴を表示し、要件の変更の人と理由を記録する機会を提供できます。
この段階での主な焦点は、プロジェクトチームに新しい作業方法のトレーニングと、 完全 性と検証可能性をテストするスペシャリストによる仕様の追加検証にあります。 その結果、要件が改善され、コストと開発時間が短縮されます。
レベル3.構造化要件
ソフトウェア製品の要件の性質は異なるため、それらをタイプ別に分類するのが慣例です。 同様に、各タイプは特定の属性セットによって特徴付けられます。 属性は、要件のテキスト記述の拡張として追加され、その構造化と管理性の向上に貢献します。 属性を使用すると、要件のステータスを追跡し、繰り返しと矛盾を特定できます。
要件のタイプと属性はプロジェクトのタイプに大きく依存するため、プロジェクトの開始前に、要件のタイプ、その属性、要件管理に関連する必要なドキュメントとタスクのセットに関する合意が、要件管理計画と呼ばれるドキュメントに作成されます。
したがって、3番目の成熟レベルでは、要件管理プロセスを計画し、統一された機能に従って識別された要件をタイプ別にグループ化するアクティビティが実行されます。これにより、管理が容易になり、すべてのプロジェクト参加者の要件をよりよく理解できます。
このレベルの成熟度では、要件に対応するように設計された専用ツールを使用する必要がある場合があります。
レベル4.トレース要件
前の3つのレベルの成熟度が達成されると、プロジェクトチームは要件間の関係を判断できるという事実につながります。 関係の設定（ トレース ）を使用すると、要件が相互に及ぼす影響を追跡し（ 影響分析 ）、冗長で会計上の要件を特定できます（ カバレッジ分析 ）。
影響分析は、ある要件の変更が他の要件の変更に及ぼす影響を追跡することです。
カバレッジ分析では、一連の要件を準備した後、上位レベル（機能）の要件が下位レベルの要件（ソフトウェア要件）で完全に詳細に記述されていることを明確に判断できます。
関係決定ルールとカバレッジ分析も、要件管理計画で定義されています。
レベル5.要件の統合
多くの場合、要件は、開発中のソフトウェア製品の望ましい動作について顧客との合意のみを目的とするものですが、開発プロセスには関与していません。 これは、プロジェクトの終わりまでに要件が時代遅れになり、実装されたソフトウェアがユーザーの期待に応えないという事実につながります。 したがって、顧客の要件を満たすソフトウェアを作成するには、プロジェクトチームが要件を開発プロセスの主な入力として使用する必要があります。
5番目の成熟度レベルの目標は、要件管理プロセスを変更管理、設計、開発、テスト、およびプロジェクト管理全般のプロセスに正確に統合することです。
もちろん、このような緊密な統合は大規模なプロジェクトで必要であり、ソフトウェア開発で使用される特殊なツールの購入には多大な費用が必要です。
繰り返しになりますが、前述のように、要件管理プロセスの一定レベルの成熟度を達成するという決定は、プロジェクトチームまたは企業が直面する目標と目的の明確な理解に基づいてバランスを取る必要があります。 明らかに、3〜5人で構成されるスタートアップチームの要件を追跡する必要はありません。 しかし、ロシアの現実には、文書化することさえせずに長い間ソフトウェアを開発している企業がまだあります。 もちろん、そのような企業では、関連する開発プロセスの成熟度は非常に低く、ソフトウェア製品の品質に確かに影響します。