「ソフトウェアの品質を上げるにはどうするべき？」記事へのコメント

そもそも

[Anonymous Coward]

そもそも「バグの数＝ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。なぜなら「バグがなければ本当に顧客が使いたい完璧なソフトウェアなのか？」は大抵の場合、ＮＯですから。

上流工程の段階から仕様をきちんと煮詰められる（プログラムで処理できるか、実装にどれくらいコストがかかるか、代替案があるか、を判断できる）人間が携わっていれば、そんなにひどいモノはできない気がするんですけどね。

＃でもスーツ着て客の前に出るのが面倒だから引きこもり気味の巫女なのでＡＣ
＃ＡＣの意味がないのは芸風です（言い切った）

Re:

[ikotom (20155)]

> 「バグの数＝ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。
完全同意の、すごく良いこと言ってると思うんですけど、ここで言う 品質 に２つの意味が混ざっちゃってませんか？

「品質」と聞いて何を思うかは人それぞれですが例えばISO-9000でいう品質とは：

本来備わっている特性の集まりが、要求事項を満たす程度

ということになってます。
つまり「その製品を要求事項にどれだけ近づけるか」が品質だ、とまずは定義しておいて、
じゃあ要求事項って何よ、としたとき、
「仕様書に書いてあるのが、要求されたことだ」と捉えるのが旧来の品質管理とする

Re:そもそも

[ijk (16269)]

「混ざっちゃって」いることをもう一つ。「バグ」にいろいろな意味が混ざっていて、ある種の思考停止ワードにすらなっているように思います。「バグの数＝ソフトウェアの品質」なんていうのはその典型だし、プログラムの振る舞いがおかしいこと(仕様通りでないとか、仕様の問題や仕様以前の問題など)とプログラムの不具合を、区別せずに両方「バグ」と呼ぶこともよくあります。ITProの記事でも、「不具合」「指摘事項」「実際のテスト(結果)における実績値」など異なるものをまとめて「バグ」と呼んで、この「バグ」の検出件数を計画をすると言っています。