ソフトウェア品質メトリック

ソフトウェアメトリックスは、3つのカテゴリに分類することができます-

製品メトリック-サイズ、複雑さ、設計機能、パフォーマンス、品質レベルなどの製品の特性を説明します。
プロセスメトリック-これらの特性を使用して、ソフトウェアの開発およびメンテナンスアクティビティを改善できます。
プロジェクトメトリック-このメトリックは、プロジェクトの特性と実行について説明します。例には、ソフトウェア開発者の数、ソフトウェアのライフサイクル全体の人員配置パターン、コスト、スケジュール、および生産性が含まれます。

一部のメトリックは複数のカテゴリに属します。たとえば、プロジェクトのインプロセス品質メトリックは、プロセスメトリックとプロジェクトメトリックの両方です。

ソフトウェア品質指標*は、製品、プロセス、およびプロジェクトの品質面に焦点を当てたソフトウェア指標のサブセットです。これらは、プロジェクトメトリックよりもプロセスおよび製品のメトリックに密接に関連しています。

ソフトウェア品質メトリックは、さらに3つのカテゴリに分類できます-

製品品質指標
工程内品質指標
メンテナンス品質指標

製品品質指標

このメトリックには、次のものが含まれます-

故障までの平均時間
欠陥密度
顧客の問題
顧客満足

故障までの平均時間

失敗の間隔です。このメトリックは、主に航空会社の交通管制システム、航空電子工学、兵器などの安全性が重要なシステムで使用されます。

欠陥密度

コードの行や機能ポイントなどとして表されるソフトウェアのサイズに関連する欠陥を測定します。つまり、ユニットごとのコード品質を測定します。このメトリックは、多くの商用ソフトウェアシステムで使用されています。

顧客の問題

製品の使用時に顧客が遭遇する問題を測定します。これには、ソフトウェアの問題空間に対する顧客の視点が含まれています。これには、欠陥の問題とともに非欠陥指向の問題も含まれます。

問題の測定基準は、通常*ユーザー月ごとの問題（PUM）*で表されます。

PUM = Total Problems that customers reported (true defect and non-defect oriented
problems) for a time period + Total number of license months of the software during
the period

どこで、

Number of license-month of the software = Number of install license of the software ×
Number of months in the calculation period

PUMは通常、ソフトウェアが市場にリリースされた後の各月、および年ごとの月間平均に対して計算されます。

顧客満足

顧客満足度は、多くの場合、5ポイントスケールの顧客調査データによって測定されます-

非常に満足
満足
中性
不満
とても不満

製品の全体的な品質とその特定の寸法に対する満足度は、通常、顧客調査のさまざまな方法を通じて得られます。 5ポイントスケールのデータに基づいて、分析の目的に応じて、わずかに変動するいくつかのメトリックを構築して使用できます。たとえば-

完全に満足している顧客の割合
満足している顧客の割合
不満のある顧客の割合
不満足な顧客の割合

通常、このパーセント満足度が使用されます。

インプロセス品質メトリック

インプロセス品質メトリックは、一部の組織の正式なマシンテスト中に欠陥の到着を追跡します。このメトリックには以下が含まれます-

機械試験中の欠陥密度
機械試験中の欠陥到着パターン
位相ベースの欠陥除去パターン
欠陥除去の有効性

機械試験中の欠陥密度

フォーマルマシンテスト（コードがシステムライブラリに統合された後のテスト）中の欠陥率は、現場の欠陥率と相関しています。テスト中に発見されたより高い欠陥率は、ソフトウェアが開発プロセス中に高いエラー挿入を経験したことを示す指標です。ただし、テストの欠陥率が異常に高い場合は例外です。

ソフトウェアがまだテストされている間、KLOCまたは機能点ごとの欠陥のこの単純なメトリックは品質の良い指標です。同じ開発組織内の製品の後続リリースを監視することは特に役立ちます。

機械試験中の欠陥到着パターン

テスト中の全体的な欠陥密度は、欠陥の概要のみを提供します。欠陥到着のパターンは、フィールドのさまざまな品質レベルに関する詳細情報を提供します。以下が含まれます-

テストフェーズ中に時間間隔（週など）で報告された欠陥の到着または欠陥。ここではすべてが有効な欠陥ではありません。
報告された問題に対して問題判別が行われた場合の有効な欠陥到着のパターン。これが真の欠陥パターンです。
欠陥バックログ残業のパターン。開発組織は、報告されたすべての問題をすぐに調査および修正できないため、このメトリックが必要です。これは、ワークロードステートメントと品質ステートメントです。開発サイクルの終わりに欠陥のバックログが大きく、多くの修正がまだシステムに統合されていない場合、システムの安定性（その品質）が影響を受けます。目標とする製品品質レベルに確実に到達するには、再テスト（回帰テスト）が必要です。

位相ベースの欠陥除去パターン

これは、テスト中の欠陥密度メトリックの拡張です。テストに加えて、テスト前の設計レビュー、コード検査、正式な検証など、開発サイクルのすべての段階で欠陥を追跡します。

プログラミングの欠陥の大部分は設計の問題に関連しているため、フロントエンドでのプロセスの欠陥除去機能を強化するための正式なレビューまたは機能検証の実施により、ソフトウェアのエラーが減少します。フェーズベースの欠陥除去のパターンは、開発プロセスの全体的な欠陥除去能力を反映しています。

設計およびコーディング段階のメトリックに関して、多くの開発組織は、欠陥率に加えて、インプロセス品質管理のために検査カバレッジや検査労力などのメトリックを使用します。

欠陥除去の有効性

次のように定義できます-

DRE = \ frac \ {欠陥\：削除\：\：a \：開発\：フェーズ} \ {欠陥\：潜在\：in \：the \：product} \ times 100 \％

このメトリックは、開発プロセス全体、コード統合前のフロントエンド、および各フェーズについて計算できます。これは、特定のフェーズのフロントエンドおよび*フェーズの有効性*に使用される場合、*早期欠陥除去*と呼ばれます。メトリックの値が高いほど、開発プロセスの効率が上がり、次のフェーズまたはフィールドに渡される欠陥が少なくなります。このメトリックは、ソフトウェア開発の欠陥除去モデルの重要な概念です。

メンテナンス品質メトリック

この段階で製品の品質を変更することはほとんどできませんが、優れた修正品質でできるだけ早く欠陥を排除するために実行できる修正を次に示します。

バックログとバックログ管理インデックスを修正
応答時間を修正し、応答性を修正します
不良債権の割合
品質を修正

バックログとバックログ管理インデックスを修正

修正のバックログは、欠陥の到着率と、報告された問題の修正が利用可能になる率に関連しています。毎月または毎週の終わりに残る報告された問題の単純な数です。このメトリックは、トレンドチャートの形式で使用すると、メンテナンスプロセスを管理するための意味のある情報を提供できます。

バックログ管理インデックス（BMI）は、未解決および未解決の問題のバックログを管理するために使用されます。

BMI = \ frac \ {数\：of \：問題\：クローズ\：\：the \：monthの間に} \ {Number \：of \：問題\：到着\：\：the \：monthの間に} \ times 100 \％

BMIが100より大きい場合、バックログが削減されていることを意味します。 BMIが100未満の場合、バックログが増加しました。

応答時間を修正し、応答性を修正します

通常、修正応答時間メトリックは、オープンからクローズまでのすべての問題の平均時間として計算されます。修正応答時間が短いと、顧客満足度につながります。

修正対応の重要な要素は、顧客の期待、合意された修正時間、および顧客へのコミットメントを満たす能力です。

不良債権の割合

次のように計算されます-

$ Percent \：Delinquent \：Fixes = $

$ \ frac \ {数\：of \：修正\：that \：超過\：\：response \：time \：criteria \：by \：ceverity \：level} \ {Number \：of \：修正\ ：配信された\：\：a \：specified \：time} \ times 100 \％$

修正品質

修正フェーズまたは欠陥修正の数は、メンテナンスフェーズのもう1つの重要な品質指標です。報告された問題を修正しなかった場合、または元の問題を修正したが新しい欠陥を挿入した場合、修正は欠陥です。ミッションクリティカルなソフトウェアの場合、欠陥のある修正は顧客満足度に悪影響を及ぼします。不具合修正の割合のメトリックは、不具合のある時間間隔内のすべての修正の割合です。

欠陥のある修正は、2つの方法で記録できます。発見された月に記録するか、修正が配信された月に記録します。 1つ目は顧客測定です。 2番目はプロセス測定です。 2つの日付の違いは、欠陥修正の潜在期間です。

通常、遅延が長いほど、影響を受ける顧客は多くなります。欠陥の数が多い場合、パーセンテージメトリックの小さい値は楽観的な図を示します。もちろん、メンテナンスプロセスの品質目標は、延滞のない欠陥のない修正です。

Software-quality-management-metrics

目次