オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

業務に特化した観点でのレビューの事例

»

ソフトウェアレビューでは検出すべき欠陥をイメージしてから進めたほうが効率的で欠陥の検出もやりやすいと感じています。検出すべき欠陥は「性能(の欠陥・問題)」「セキュリティ」といった多くのソフトウェアにあてはまる汎用的なものが多いと思います。チェックリストは検出すべき欠陥をリスト化していると考えることもできると思います(欲張りすぎて形骸化していることもあると思いますがチェックリストの本来の意図は検出したい欠陥のリスト化にあると思います)。

一方で検出すべき欠陥が汎用的ではないけれども、特定業務において特に検出したい典型的な欠陥、特定業務においてレビューで見逃すとリスクや手戻りが大きくなる欠陥もあります。過去のバージョンの開発時に収集されたバグ票を見渡すとそのような欠陥種別に出会うことがあると思います。業務系であれば月締めの処理での典型的な欠陥がそれにあてはまったり、高いリアルタイム性が求められるソフトウェアの場合には実行命令の分岐数や最長パスに絡む欠陥がそれにあてはまったりすると思います。ドメインのノウハウと呼ぶことができるのかもしれません。

ユーザ系企業のシステム部門とご一緒して、そのような特定業務の観点でのレビューが可能かどうかを過去に収集された不具合管理表の情報を使って検討しました。検討では日付に関する欠陥(期間の定義や日次処理のチェック)を早期検出できるかどうかを調査、検討しています。秋葉原UDXで2012年3/5(月)のエンピリカルソフトウェア工学研究会で検討結果を紹介します。当日お越しいただいた方には、より具体的な情報を提供できるのでお時間があればお越しください。研究会の詳細はこちら

Comment(0)