パターン21:グループによる妥当性確認

   

 

問題:

製品品質を保証する

コンテキスト:

分析、設計あるいは実装の品質が評価されようとしている。

影響する事柄:

品質を評価する仕事はQAの仕事である。

QAは、通常、ブラックボックステストによる妥当性確認と検証を行い、最終製品の品質を評価する。

グループの集まりは、製品の問題点や好機についての多くの洞察をもたらす。

個人では、システムを悩ませるようなバグを発見できるような洞察力を持つていないかもしれない(これは客観性の問題かもしれない)。

解決策:

QAが参加する前であっても、開発チーム(顧客を含む)は設計の妥当性を確認することができる。CRC設計技法のような技法やグループによるデバッグは、問題を顕在化し解決するのに役に立つ。

妥当性確認チームのメンバーは、共通なソフトウエア欠陥の分類に帰因するような根本原因を解決するためにQAと協力することもできる。

結果として生じるコンテキスト:

システムの品質が、チーム全員の前でいつも焦点が当てられるようなプロセスになる。結果として、問題は早く解決されるようになる。このパターンにともなうコストは、グループによる設計/コーディング/デバッグの工程において費やされる時間である。

論理的根拠:

CRC設計技法は、チーム構築のためのすばらしいものであるということが認められており、設計を社交的にする理想的な方法である。GBCSプロジェクトでの研究では、グループでのデバッグはいちじるしく生産性が高いということが確認されている。

顧客をこのような過程に参加させることは特に役に立つ。プロジェクト遂行に当たっては、結果として生じるコンテキストで述べられているようなパターンを用いることにより、顧客と開発者の間での相互干渉を調整するように注意しなければならない。

このパターンについては、経験的な研究結果がある。「An implementation of structured walk-throughs in teaching COBOL programming,」(CACM, Vol. 22, No. 6, June, 1979)を参照してください。この論文では、チームによるデバッグがチームの学習と効率に寄与することが確認されている。G. J. Meyersによる「A controlled experiment in program testing and code walk-throughs/inspections,」(CACM, Vol. 21, No. 9, September, 1978)では、反対の意見が述べられている。しかしながら、この研究は欠陥発見に限定しており、チームの学習の利点を評価していない。

ペアで開発のパターンと比較しなさい。