過去にてこずった不具合を将来のレビューで注力して検出する手順を提案した論文
類似のソフトウェアを開発するときに、過去の不具合や過去の失敗がノウハウとして役立つことがあることを感じたことがあると思います。そのことをソフトウェアレビューにおいて活かすためにシステマチックな方法を検討し、構築しています。
具体的には、過去にレビューで見逃してテストで大きな修正の手間がかかった不具合のタイプを抽出し、そのタイプの不具合を次のバージョンのレビューで見逃さないようにすることを目的として手法を考え、試行を実施しました。
以下の論文で詳細を報告しています。
森崎 修司，久保 匡，荻野 利彦，阪本 太志，山田 淳，"過去の不具合の修正工数を考慮したソフトウェアレビュー手法"，電子情報通信学会論文誌 D Vol.J95-D No.8 pp.1623-1632(2012) アブストラクトはこちら（電子情報通信学会のページへ）。
また、電子情報通信学会の利用規程に沿って我々の研究グループでも論文の本文を公開しています。
レビューで検出すべき欠陥タイプは、不具合管理表に記録された修正工数、検出すべきであった工程、重要度、原因、担当者をはじめとした選択肢式の項目から得ます。上述の論文の場合、設計レビューを対象としていますので、まず、設計レビュー以前の工程で検出できた可能性のある不具合を対象として、不具合のタイプを抽出します。
条件にあてはまる不具合管理情報に記録された選択肢式の項目の総当たりの組合せと修正工数から修正工数の大きな不具合に頻出する項目や項目の組合せをツールで抽出します。ツールのアルゴリズムは論文に掲載しています。
開発対象に豊富な知識を持つ人が項目や項目の組合せから、その不具合のタイプを次以降のバージョンの開発のレビューにおいて、どう検出するかを検討し、レビューでの着眼点とします。
実際にこの方法が有効かどうかを確認するために、著者らが携わる商用開発において試行しました。着眼点として、例外処理、パラメータの初期化／クリア等が挙がりました。通常のレビュー、本手法の両方において検出できた全ての欠陥について、もしも見逃していた場合にテストで必要となったであろう修正工数を算出しました。その結果、本手法を使ったほうが大きくなる結果が得られました。修正工数が大きくなりがちな不具合の項目やその組合せからレビューでの着眼点を決定する部分を洗練していくことを今後目指します。
本手法の優れている点は、比較的客観的なデータである過去に検出された不具合をもとに、一定の手順でレビューの着眼点を選択している点にあります。レビューの着眼点を個人がバラバラに想定して、検出するとレビューで期待する効果が出にくくなります。また、一定の手順という点で合意が得やすいところにも特徴があります。
レビューの着眼点を選択する手順は、他にも考えられます。ポイントの1つはレビューアの間で合意できていることです。試されてはいかがでしょうか。
本研究で実施した試行の一部は、日経SYSTEMSに寄稿しています。その記事が日経ITproでも転載され、公開されています。