ソフトウェアの品質（その３：バグについて）

バグ（ソフトウェアエラー）は、
開発ステップ数の２乗に比例すると言われ規模が大きくなるにつれ予測が難しくなる。

「バグは付き物」で、摘出し修正するのに大変な工数を費やす。

エラーの作り込みを防ぐことができトラブルを減らすことが出来ればより効果的である。

これを行う一つの方法は、エラーが摘出されたときに、

・その原因を分析すること、
・それを正しく修正することである。

次に、エラーの原因となったと思われることをできるだけ詳細に記録し、

徹底的に分析し、そして、

・それから学んだ同種のエラーを減らすアイデアと共に、
・何が原因でエラーが起きたかを開発者全員に知らせることで再発を予防する。

そうすれば、こうした知識が広範囲に徹底され、エラーを減らすことができる。

しかし、一般的には、発見されたバグに対して、その「原因＝発生の仕組み」を解明し、それが発生しないように修正することでバグ対策は終わってしまうが、これでは本当に解決したことにはならない。

“作り込んだ真の原因”を追求し抜本的な再発防止対策を行わねばならない。

バグを除去しても品質は上がらない

ソースになった後で「信頼性」を取って付けるようなことは出来ない。
ソースになった時点でできることは、精々バグを取り除くことだけで、品質を高めることではない。

品質は、
最初からそれを意図して作り込まれなければ実現しないし、必死の思いでバグを取り除いたとしても、それは単に「欠陥」を直しただけである。

たとえば、要求されている「保守性」を満たすために、

・全体的にプログラムを見やすくし、
・ドキュメントとソースプログラムとの相互参照をし易くし、
・変更が生じやすいモジュールは、入れ替えし易い構造にし、
・保守の「シナリオ」を用意したとしても、

やっと「保守性」という一つの品質特性の要求をある程度満たしたと言えるだけである。
それでも、本当に満たしたかどうかの判断は難しい。

「信頼性」や「移植性」なども、その品質特性を満たすために、色々な手だてを講じなければならない。

その何れもが設計という行為において盛り込まれなければならないし、そのためには、きちんとした分析をする必要がある。
このようなことがなされないで、バグを除去しても品質は上がらない。