ウォーターフォール開発の課題

ウォーターフォール開発の課題

　ウォーターフォール型の開発では、この仕様のとおり作ればうまくいくことを示す直接的な方法がないことが最大の弱点なのではないかと思いはじめている。
　

「ウォーターフォールモデルは間違いだ！」 pdfファイルの11枚目
とする資料もある。

• 仕様を書いている人が、まだその段階では作るべきシステムを理解していない。

  • 実現したいこと
  • 実現可能な方式はどれだけあるか
  • その中から実現するのによい方式は何か
  • どうやってテストするか
  • どうやってシステムをメンテナンスするか 　　こういった項目を考えないままに書かれた仕様書は役に立つことなく、開発者にあだをなすことになる。
    

• 一方、bottom-upで開発をする側は、アジャイルな開発をする。

  • できないことをやれと言われても困るから、できるものをbottom-upでプロトタイピングして実装する。プロトタイピングでその方式が結果を出せることを確かめつつ進めている。

• その結果、現場を顧みずに作りっぱなしの仕様書は、役に立たず放置されている。

• ウォーターフォール型では、「開発はやらせるもの。そのとおりできない側が悪い。」というニュアンスがどこかに隠れているような気がする。

  • 発注側と受託側という力関係や、上司と部下という値から関係の中で、その仕様の妥当性を検討しないままに、ごりおししがちです。
  • 仕様を作成する側が、それが実現可能かどうか、作りやすいかどうか、その仕様にしたがって作れば絶対うまくいくことを担保するための努力を怠っている場合がある。
  • ネットのニュースに聞く某システムの場合の場合、ただでさえ複雑になりそうなシステムを、しがらみのために、複数の会社に分担させてしまっている。そのことで、複雑なシステムを少しでも単純化しやすくするための調整作業を困難にしているのではないかと推測される。
  • 該当技術の担当者が、それは無理だと明言しているのにも関わらず、それをできることを前提として開発を継続しようとする。 　

• 仕様を作成して外部に委託すれば問題が解決したかのように扱われて、納期になって解決していないことに気づく。

  • 例：納品されたのが使いものにならない実装だった。
  • 実現にはある難しさがあるからこそ、開発を委託したものが、その難しさをまったく解決していなかった。そのため実用にはならず放置された。その問題を解決して納品されてくると信じているから、その問題は結果的に放置されていたことになる。

• 例：納品されたソースコードは、仕様書に書いたAPIをことごとく無視したものだった。
  MS-Wordで書いた仕様書で、開発を委託したのにもかかわらず、それとは違ったAPIになっていた。
  　

付記
仕様を作成する上で必要なこと

• 適度な抽象化
  　実装の詳細は変化するものだから、適度なレベルで外部仕様を抽象化するのがよさそうだ。
  　適度なレベルがどのあたりなのかは、どのようなデータ構造までは見えて、どのようなデータ構造を見えなくするのか。
  　私自身が試行錯誤中です。

• 依存性を切り離す。
  　ライブラリはなるべく依存性が少なくなるようにする。

• ロジックを単純化する。
  　まとめて扱うべき変数に対して、メソッド名を見れば何をするものなのか分かることを目指して単純なロジックにする。
  　単純なロジックはテストも考えやすくなる。

• 対応するテスト項目が思い描くことができないならば、仕様の明確化ができていない可能性が高い。

  • run time errorを生じる可能性があるならば、そのときの動作はどうなるのか？　例外の発生か？戻り値のチェックか？

ウォーターフォール開発でときとして欠け落ちていること

• 要求仕様の明確化
  • 要求仕様があいまいなまま、いつまでたって仕様がfixしない。そのソフトウェアに何を実現させたいのか不明確なまま。そのため、どんなに有能なソフトウェア技術者を投入したところで、解決できない。
• 実現可能性
  • その仕様がどうやって実現できるのかへの検討作業がないまま、仕様を確定してしまう。そのため、願望としての仕様にすぎず、だれも実現できなくなってしまう。

この２つの特徴は、開発に失敗した大規模ソフトウェア開発事例によく見られる。

ウォーターフォール開発で時として生じていること
- 適切な要件定義、適切な上位設計をできるようになるには、コーディング・リファクタリングなどの経験を積んで適切な設計のしかたを習得しなければならないのに、「コーディングは下請にやらせるものだ」という考え方を生じている組織があったりする。