Software-quality-management-measurement
ソフトウェア測定
ソフトウェア測定のフレームワークは、3つの原則に基づいています-
- 調査するエンティティの分類
- 関連する測定目標の決定
- 組織が到達した成熟度のレベルを特定する
検査するエンティティの分類
ソフトウェアエンジニアリングでは、主に3つのクラスのエンティティが存在します。 彼らは-
- プロセス
- 製品情報
- リソース
これらのエンティティにはすべて、内部エンティティと外部エンティティがあります。
- *内部属性*は、プロセス、製品、またはリソース自体に関して純粋に測定できる属性です。 例：サイズ、複雑さ、モジュール間の依存関係。
- *外部属性*は、環境との関係に関してのみ測定できる属性です。 例：ユーザーが経験した障害の総数、データベースの検索と情報の取得にかかる時間。
各エンティティについて測定できるさまざまな属性は次のとおりです-
プロセス
プロセスは、ソフトウェア関連のアクティビティの集まりです。 以下は、プロセスのために直接測定できる内部属性の一部です-
- プロセスの期間またはそのアクティビティの1つ
- プロセスまたはそのアクティビティの1つに関連する努力
- プロセスまたはそのアクティビティのいずれかで発生した特定の種類のインシデントの数
プロセスのさまざまな外部属性は、コスト、制御性、有効性、品質、および安定性です。
製品情報
製品は、経営陣が提供することを約束しているアイテムであるだけでなく、ソフトウェアライフサイクル中に作成されたアーティファクトまたはドキュメントでもあります。
さまざまな内部製品属性は、サイズ、労力、コスト、仕様、長さ、機能性、モジュール性、再利用、冗長性、および構文の正確さです。 これらのサイズの中でも、努力とコストは他のものよりも比較的簡単に測定できます。
さまざまな外部製品の属性は、使いやすさ、整合性、効率性、テスト容易性、再利用性、移植性、相互運用性です。 これらの属性は、コードだけでなく、開発作業をサポートする他のドキュメントも記述します。
リソース
これらは、プロセスアクティビティに必要なエンティティです。 ソフトウェア生産のための任意の入力にすることができます。 これには、人員、材料、ツール、および方法が含まれます。
リソースのさまざまな内部属性は、年齢、価格、サイズ、速度、メモリサイズ、温度などです。 さまざまな外部属性は、生産性、経験、品質、使いやすさ、信頼性、快適性などです。
関連する測定目標の決定
特定の測定値は、プロセスまたはその結果の製品の1つを理解するのに役立つ場合にのみ役立ちます。 プロセスまたは製品の改善は、プロジェクトでプロセスと製品の目標が明確に定義されている場合にのみ実行できます。 目標の明確な理解を使用して、プロセス成熟度フレームワークのコンテキストで特定のプロジェクトの推奨メトリックを生成できます。
目標-質問-メトリック（GQM）パラダイム
GQMアプローチは、次の3つのステップを含むフレームワークを提供します-
- 開発または保守プロジェクトの主要な目標のリスト
- 目標が達成されているかどうかを判断するために回答する必要がある各目標から質問を導き出す
- 質問に適切に回答できるようにするために何を測定する必要があるかを決定する
GQMパラダイムを使用するには、まず組織の全体的な目標を表現します。 次に、目標が達成されているかどうかを判断できるように、答えがわかるように質問を生成します。 後で、各質問に答えるために必要な測定の観点から各質問を分析します。
典型的な目標は、生産性、品質、リスク、顧客満足度などの観点から表されます。 目標と質問は、視聴者の観点から作成されます。
目標、質問、指標の生成を支援するために、Basili＆Rombachは一連のテンプレートを提供しました。
- 目的-理解、評価、管理、エンジニアリング、学習、改善などのために、（プロセス、製品、モデル、メトリックなど）を（特性化、評価、予測、動機付けなど）すること 例：学習するために製品を特徴付けるため。
- 視点-開発者、管理者、顧客などの観点から（コスト、有効性、正確性、欠陥、変更、製品対策など）を調べます。 例：顧客の視点から欠陥を調べます。
- 環境-環境は、プロセス要素、人的要素、問題要素、方法、ツール、制約などで構成されます。 例：このソフトウェアの顧客は、ツールに関する知識がない人です。
測定とプロセスの改善
通常、測定は次の場合に役立ちます-
- プロセスと製品を理解する
- ベースラインの確立
- 結果へのアクセスと予測
SEIが提供するプロセスの成熟度に応じて、測定の種類と測定プログラムは異なります。 以下は、各成熟度レベルに適用できるさまざまな測定プログラムです。
レベル1：アドホック
このレベルでは、入力は不明確ですが、出力は予想されます。 入力から出力への遷移は定義されておらず、制御されていません。 このレベルのプロセス成熟度では、測定の開始点を提供するためにベースライン測定が必要です。
レベル2：反復可能
このレベルでは、プロセス、制約、およびリソースの入力と出力が識別可能です。 繰り返し可能なプロセスは、次の図で説明できます。
入力尺度は、要件のサイズとボラティリティにすることができます。 出力は、システムサイズ、スタッフの労力、およびコストとスケジュールに関する制約の観点から測定できます。
レベル3：定義済み
このレベルでは、中間アクティビティが定義され、その入力と出力が認識され、理解されます。 定義済みプロセスの簡単な例を次の図に示します。
中間アクティビティへの入力と中間アクティビティからの出力は、調査、測定、評価できます。
レベル4：管理
このレベルでは、初期のプロジェクトアクティビティからのフィードバックを使用して、現在のアクティビティの優先順位を設定し、後でプロジェクトアクティビティの優先順位を設定できます。 プロセス活動の有効性を測定できます。 この測定は、全体的なプロセスの特性、および主要なアクティビティ間の相互作用の特性を反映しています。
レベル5：最適化
このレベルでは、アクティビティからの測定値を使用して、プロセスアクティビティを削除および追加し、測定フィードバックに応じてプロセス構造を動的に変更することにより、プロセスを改善します。 したがって、プロセスの変更は、プロセスだけでなく組織とプロジェクトにも影響を与える可能性があります。 プロセスはセンサーおよびモニターとして機能し、警告サインに応じてプロセスを大幅に変更できます。
特定の成熟度レベルで、そのレベルとそれ以下のすべてのレベルの測定値を収集できます。
成熟度の特定
プロセスの成熟度は、目に見えるもののみを測定することを示唆しています。 したがって、プロセスの成熟度とGQMの組み合わせは、最も有用な手段を提供します。
- *レベル1 *では、プロジェクトの要件が不明確になる可能性があります。 このレベルでは、要求特性の測定は困難です。
- *レベル2 *では、要件は明確に定義されており、各要件のタイプや各タイプへの変更数などの追加情報を収集できます。
- *レベル3 *では、各アクティビティの開始基準と終了基準で中間アクティビティが定義されます
目標と質問の分析は同じですが、メトリックは成熟度によって異なります。 プロセスが成熟すればするほど、測定値は豊かになります。 GQMパラダイムは、プロセスの成熟に合わせて、管理者が測定プログラムを設計するのを支援するいくつかのツールの基盤として使用されています。
GQMは、属性を測定する必要性を理解するのに役立ち、プロセスの成熟度は、意味のある方法で測定できるかどうかを示唆します。 一緒になって、測定のコンテキストを提供します。
