ソフトウェア開発の品質管理

ソフトウェア開発の品質管理についての記事です。
読み手は若手のソフトウェアエンジニアを想定しています。
2023/5/20に本記事を改定しました。

対象となるソフトウェアの品質基準を策定し、品質基準を満たすように開発プロセス内でソフトウェアの品質をコントロールすることです。

ソフトウェアの品質基準は各組織が独自で定めている値であり、組織内に品質基準がない場合は算出する必要があります。

組織内で定めておくべき、ソフトウェア開発における主な品質基準は以下の3つです。

これらの品質基準を定めておき、新規開発するソフトウェアに対して品質を計測後、基準と照らし合わせて品質の妥当性を評価します。

組織内でこれまでの開発実績からテスト密度とバグ密度を算出しておき、それを組織内の品質基準に設定します。

新たにソフトウェア開発する時、計測対象のソフトウェアに対してテスト密度とバグ密度をそれぞれ求め、組織内の品質基準と照らし合わせ、品質の妥当性を評価します。

評価にはゾーン分析と呼ばれる手法を用いることが一般的です。

テスト密度とバグ密度による品質評価と合わせて、残存バグ予測による品質評価も行います。
テスト実施完了時、残存バグ予測数と比較して、検出したバグ件数の妥当性を評価します。

残存バグ予測よりもバグ検出数が少ない場合は効果的なテストが実施されていない可能性があるため、テストの質を見直す必要があります。

テスト密度とバグ密度を算出するためにはソフトウェアの規模を見積もる必要があります。

見積もり手法にはいくつか手段があります。

ソフトウェアの規模を見積もる手法として最も適切な手法はFP法によるものです。
組織でFP法による見積もりルールを定めておけば、開発担当者のスキルによるばらつきを抑えることもでき、外部設計時点で実施可能なため、使用言語によるばらつきお抑えることができます。

最後に本記事の内容を全て否定して終わりにします。

品質基準とは幻であり、自分をあるいは他人を納得させるためのツールに過ぎません。
品質基準に合格している＝市場不具合が起きないわけではないのです。

いくら実績ベースに基準を作成しても、開発はまだ世の中に存在しない新しい商品を開発します。"品質基準そのもの" の基準を作ることはできないのです。

品質基準を作成する時間があるならば、1件でも多くテストを実施した方が品質は上がります。品質基準に合格することを目指すよりも、バグが潜んでいないか？徹底的に設計とテストを実施した方が遥かに高品質の商品ができあがるのは事実です。

泥臭い作業こそ品質の裏付けになるのです。

結果が全てであるならば品質基準は幻でしかありません。

本質とはかけ離れた幻の基準にすがるしかないのは辛いですね。