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

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

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

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

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

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

製品品質メトリクス
インプロセス品質メトリクス
メンテナンス品質メトリクス

製品品質メトリクス

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

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

平均故障間隔

それは失敗の間の時間です。このメトリックは主に、航空会社の交通管制システム、航空電子工学、武器などのセーフティクリティカルシステムで使用されます。

欠陥密度

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

顧客の問題

これは、顧客が製品を使用するときに遭遇する問題を測定します。これには、ソフトウェアの問題領域に対する顧客の視点が含まれています。これには、欠陥に関連しない問題と欠陥の問題が含まれます。

問題のメトリックは通常、次のように表されます。 Problems per User-Month (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段階評価による顧客調査データによって測定されます。

非常に満足
Satisfied
Neutral
Dissatisfied
非常に不満

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

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

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

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

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

機械試験中の欠陥密度
機械試験中の欠陥到着パターン
フェーズベースの欠陥除去パターン
欠陥除去効果

機械試験中の欠陥密度

正式なマシンテスト（コードがシステムライブラリに統合された後のテスト）中の欠陥率は、現場での欠陥率と相関しています。テスト中に検出されたより高い欠陥率は、ソフトウェアが開発プロセス中により高いエラー注入を経験したことを示します。ただし、テストの欠陥率がより高いのは、特別なテスト作業によるものではありません。

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

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

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

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

フェーズベースの欠陥除去パターン

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

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

設計段階とコーディング段階の測定基準に関しては、欠陥率に加えて、多くの開発組織が検査範囲や検査作業などの測定基準を使用して、工程内の品質管理を行っています。

欠陥除去効果

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

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

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

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

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

バックログとバックログ管理インデックスを修正する
応答時間の修正と応答性の修正
延滞率の修正
品質を修正する

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

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

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

$$ BMI = \ frac {Number \：of \：problems \：closed \：during \：the \：month} {Number \：of \：problems \：arrived \：during \：the \：month} \ times 100 \％$$

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

応答時間の修正と応答性の修正

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

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

延滞率の修正

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

$パーセント\：滞納\：修正= $

$ \ frac {Number \：of \：fixes \：that \：exceeded \：\：response \：time \：criteria \：by \：ceverity \：level} {Number \：of \：fixes \：delivered \：in \：a \：specified \：time} \ times 100 \％$

品質を修正する

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

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

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