Making Software ―エビデンスが変えるソフトウェア開発

142

9

章 欠陥数予測の自動化

物によって、数時間ないし数日後に行われることもあるでしょう。テスターが

MR

を開始する場合には、

後者の方が典型的なシナリオです。

MR

は、どの開発フェーズで、いつ提出や実装がなされ（日付）、提

出者や実装者が誰で、その

MR

を特性づける属性タグが何かということ、提出者や実装者が書いた変更

内容の記述などを含め、変更のすべての側面をドキュメント化しています。

変更自体も

MR

の一部として記録され、ツールの中のバージョン制御コンポーネントが、システムの

存続中のどの時点のビルドでも作り出せるようにするために、この情報が使われます。

MR

の情報はデー

タベースに保管されていて、私たちはこのデータベースから、過去のリリースを分析したり将来の結果

を予測するのに必要なすべての情報を取り出しました。

私たちが調査対象にしたシステムはすべて、

MR

を記録するのに同一のツールを使っていましたが、

その使い方には違いがあるところもあり

ました。最も大きな違いは、プロジェクトが開発プロセスのど

の段階で、変更を公式の

MR

に基づくように要求し始めるかという点でした。

1

つのよくあるやり方は、

システムがシステムテストの段階になった時点ではじめて、

MR

を要求するようにする、というもので、

その場合、

MR

データベースにはシステムテストの段階よりも前に行われた変更や見つかった欠陥に関

する情報は含まれていません。このやり方は、私たちが調査対象とした

6

件のシステムのうち

4

件で採

用されていました。これらのシステムについては、私たちの作成したモデルはシステムテストおよび現 ...