ウォーターフォールモデルで考える事


※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

ウォーターフォールモデルで考える事


ウォータフォールモデルには良いレビュアーで良い開発者が必要。

ウォーターフォールモデルとはレビューだ。

ウォーターフォールモデルで重要なのはレビューを何度も重ね、仕様を精査(せいさ)して行く事。
そして次工程に進む前に不良を摘出すること。

そのためウォーターフォールモデルの人員は人からレビューを頼まれたら喜んで引き受けること。
レビューが通る前には、次工程に進まない事。

レビューを依頼すること。依頼しやすい様にすること。
作業人員は開発作業と同じウエイトで、他人の成果物のレビュー作業を行う義務を持つことを頭に叩き込む。
自分担当の仕様精査だけではなく、自分に関係のある成果物についてレビューを行い、不良を早期に発見すること。

ウォータフォールは基本手戻りを許さない。顧客や管理者が手戻りを前提としないスケを組んでいるから。



レビュー

レビューは有識者・経験者がドキュメントを評価することで、ドキュメントの不良を検出する。
レビューは初めてやることに関しては効果が薄い。

森崎 修司(2014).間違いだらけの設計レビュー P75によれば、
「問題種別によっては、チーム内の誰も十分なスキルや知識を持っていないケースがあります。その場合、レビューで問題を検出することは期待できません。リーダーが中心となって先行テストやプロトタイピングなどのレビュー以外の方法を検討する必要があるでしょう。」と記述があり、そこからも何でもかんでもレビューでプログラムの品質を持ち上げようとするのは間違いであるとわかります。プロジェクトがWFだからサブシステムの進行もWFでレビューを実施して品質を上げようなんて考えるのは、管理者の怠惰でしかない。


優秀な有識者が集まるのであれば話は別だが…。

工程別レビュー



要件定義


レビュア→顧客

*