今期は、上流工程におけるレビュー強化が重点課題なので、以前読んだ記事を再読。
| ソフトウェア・テスト PRESS Vol.2 | |
 | 技術評論社 技術評論社 2005-12-01 おすすめ平均 |
<p>
この記事は、本当に良いと思うんですよね。
</p>
<p>
欠陥の分類方法として、「IEEE Std. 1044, IEEE Standard <strong>Classification</strong> for <strong>Software</strong> <strong>Anomalies</strong>」というのがあるそうですが、ググってみても本文まではなかなか見つかりませんでした。残念。
</p>
<p>
一番センスを感じたのが、品質を健康に例えたくだり。<br />・どちらも単位がない<br />・どちらも複数の代替特性で表現（例：血糖値の値だけで健康とは言えない）<br />・追求しすぎはない（健康すぎるという完全な状況はない。普遍の完了基準はない）<br />・・・
</p>
<p>
さて、インスペクションとは何か。記事にはわかりやすい図が載っていますが、<a href="http://www.rsch.tuis.ac.jp/~tamaki/software_engineering/Chap_18.pdf">www.rsch.tuis.ac.jp/~tamaki/<strong>software</strong>_engineering/Chap_18.pdf</a><br />にやや近い図があります。<br />ようするに、一番フォーマルで一番コストもかかるが、一番欠陥検出効果が高いレビュー方法ということです。<br />その他の解説としては、<br /><a href="http://homepage3.nifty.com/Proc.Inspec.Guid/Proc.InspIntro.html">ウォークスルーの進め方</a><br />もよいでしょうか。
</p>
<p>
そしてその中でも手法はいろいろあるようで、「パースペクティブ・ベース・インスペクション」（参加者が利害関係者になりきって、それぞれの立場・観点から検証する）、「パスアラウンド法」（招集するのではなく、成果物を複数担当者に送付・回覧して、複数のフィードバックを受ける）が紹介されています。
</p>
<p>
最後にテクニックもいくつか挙げられていますが、これらも納得です。<br />・事実を指摘<br />・まず全体像を把握せよ、微細欠陥にこだわるな<br />・欠陥数を追跡しない、欠陥の種類を追跡する<br />など。
</p>
<p>
なお、別記事「三色ボールペンで読む仕様書」も活用したらよいかもですね。<br />・赤：客観的に見て、最も重要な箇所<br />・青：客観的に見て、まあ重要な箇所<br />・緑：主観的に見て、おかしいと感じた個所
</p>