定量的品質評価とは？　代表的な評価方法を３つ挙げながら説明！

はじめに

「定量的品質評価」とは、その名の通り、プログラムの品質を数値で評価することを指します。
そのことにより、品質の良し悪しを客観的に把握することが可能になり、有効な対策を打てるようになります。

実態として、定量的品質評価は開発者からの評判が良くないこともあります。
しかし、私の経験上は、管理者やリーダーが品質管理のために自発的に取り入れるのであれば、効果を発揮します。
実際に、他のプログラムに対してテストで見つかるバグが多すぎたり少なすぎたりするプログラムは、「複雑性が高く、バグが大量に出る」「ある担当者のテストが甘く、発見されるバグが少ない」といった原因が隠れています。
原因さえわかれば、重点的にテストやレビューを行うべき箇所も自ずと明らかになり、効率的に品質を強化することができるようになります。

今回の記事では、情報処理技術者試験に良く出てくる２つのモデル（信頼度成長モデル、エラー植付けモデル）と、実務で良く使う管理図について説明します。

信頼度成長モデル

テスト工程の序盤はテスト手順確立のため発見されるバグが少なく、中盤になりテストが進むようになるとバグが順調に見つかるようになり、テスト終盤はテストの残項目が少なくなるため発見されるバグが少なくなる、というものです。
グラフにすると以下の通りです。

標準（類似プロジェクト）よりもテスト序盤でバグが多く出る場合は、テスト工程開始時点での品質が悪いことが予想されますので、その場合は前工程に戻っての品質強化が有効になります。
（そのまま進めても、バグでテストが順調に進捗しなくなることが予想されます）
また、その逆にテスト序盤で標準よりもバグが出ない場合は、テスト方法に問題がありバグが有効に見つけられないことが予想されますので、その場合はテスト方法の見直しが有効になります。
（そのまま進めても、次工程やリリース後にバグが残存することが予想されます）

エラー植付けモデル

意図的にバグを埋め込み、「システム全体のバグ数と埋め込んだバグ数の比率」と「検出したバグ数とそのうちの埋め込んだバグ数の比率」は等しいという前提の元、システム全体のバグ数を予想するものです。
例えば、以下の例だと、システム全体のバグ数は36と予想されます。

管理図

管理図とはQC7つ道具の一つで、品質のばらつきの上限と下限を定め、上限と下限の範囲に品質が収まっているかどうかをもって品質の良しあしを測るというものです。
イメージとしては、品質を折れ線グラフで取ることで以下のような図を作成し、そのばらつきが上限と下限の間に収まっているかどうかを測る、というものです。

ソフトウェアの品質を測る際にもこの考え方を適用することができ、「1000ステップ(1Kステップ)あたりバグがいくつあるか」という観点で品質を測ります。
例えば、1000ステップあたりバグが3～5個あるはず、この範囲で収まっていなければテストやソフトウェアの品質が悪い、と判断することができます。
基準の数字は言語やシステム特性によっても違うので、システム毎に品質測定して基準の数字決めたりします。言語毎に基準の数値を公表している機関もあります。

後書き

良いシステムを作るためには、今回の記事で述べたように、単にプログラムを作成したりテストしたりするだけではなく、本当に高い品質の成果物が出来上がっているかどうかを確認する必要があります。
そして、品質評価を行う上では、前提として、サイゼントの書籍やスクールで取り扱っているような、プログラミングやテストに関する基礎的な知識が必要になります。

株式会社サイゼントでは、即戦力のJavaプログラマーを育てるための書籍「絶対にJavaプログラマーになりたい人へ」をKindleで販売しています。

同じく、Spring Frameworkについてきめ細かく解説した別冊も販売中です。


また、上記の書籍をテキストとして用いたプログラミングスクール「サイゼントアカデミー」も開校しています。
このスクールは、受託開発事業・SES事業である弊社が、新入社員向けの研修で培ったノウハウを詰め込んだものです。


ご興味がある方は、上記画像から個別ページにアクセスしてみてください！