沖縄をＩＴで盛り上げる社長のブログ

システム開発において、品質の良し悪しを調べる方法にはいろいろあるが、
昔ながらの方法を長年使い続けてるところもいる。

テスト時に発生した不具合の件数によって、テストの精度を測るという方法がそれだ。

プログラムを作成して、テスト時に不具合が発生しないことは、まずあり得ない。
プログラムの記述行数（ステップ数などと言う）が大きくなればなるほど不具合の件数は多くなる。

テスト時の不具合発生率が１５％～３０％が品質の合格点だとする。

たとえば、１０００ステップのプログラムを書いたすると、
１５個から３０個の不具合を検出しなければならない。

１０年前ならそれくらいの不具合は出たかもしれない。

しかし、時代は進歩しテスト前の動作確認である程度の不具合は修正できるようになってきた。
不具合もつぶしながらプログラムを作成してるというのが現状だ。

その昔、プログラムを動かすだけでも手間がかかる時代があった。
パソコンではなく、汎用機とかオフコンとか呼ばれてたコンピュータの時代だ。
（今もないわけではないが・・・）

プログラムを書いた後、コンパイルするのにも許可が必要だった。
「コンパイル申請書」みたいなものを上司に提出し、認められて初めてコンパイル可能。

※コンパイル＝人間が書いたプログラムをコンピュータが解析し、動作可能な状態にすること。

なのでコンパイルを行うときには、プログラムを完成させ、紙に出力して目でチェックし、
その時点で発見できた不具合は直しておく。何度もコンパイルできないから必死だ。

やっとコンパイルした後、プログラムを動かしてみると初歩的な不具合も出てきたりする。

今の時代、パソコンで開発していれば、申請なんかせずにプログラムを動かせる。
プログラム全体を記述する前に、一部分ずつ動作確認していれば、最終的には不具合は少ない。

それでも、上記のような不具合発生率を求められるとつらいものがある。

しかしながら、今の時代にも悪いところはある。

あまり考えずにプログラムを書いても、コンピュータがすぐにチェックしてくれるため、
開発者のプログラミング能力が低くなってるかも知れない。

あるロジックを書くときに、じっくり考えず、「まずは動かしてみよう」的な方法に慣れてしまうと、
プログラミング能力は向上しないような気がする。

ちょっとずつ動かしながら作っていると、時間もかかることになる。
生産性についても問題になる。

この時代でも、プログラミングを最後までやってからコンパイルを行い、
「エラー０件」を目指すことに挑戦しても面白いだろう。（０件なんてまずないが・・・）

人気ブログランキング←続きを読む前にクリック！ありがとうございます！