「標準ソフトウエア工学教科書」を作ってみたいと思います その８ ２．３

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は「２．３　プロトタイプ（RAD)」です。

---

■２．３　プロトタイプ（RAD)

　前章（２．２）で見た、V字型、フィードバックV字、W字型開発も結局、ウォーターフォールを踏襲しているものでした。

　これらの方法に共通している問題として、開発リスクが先送りされてしまうという欠点があります。

---

　たとえば、
　　「携帯の画面から受注データを送信する」
　　「その際、商品名は、選択できるように」
　という仕様があったとします。

　現実的には、商品が１００００点もあったら、商品名を選択するのが大変です。
　だから、画面入力を考えれば、この仕様は、単純にはできない（何か工夫しないとできない）ということになります。


　ウォーターフォールで開発する場合、この仕様の問題が露呈するのは、画面設計段階です。
　しかし、そのとき、画面設計の人が、この問題を見落とし、１００００点もあるものをドロップダウンリストで設計してしまったら、どうなるでしょう。
　プログラムが作成され、単体、結合テストまで行ってしまいます。
　結合テストのとき、１００００件もドロップダウンできない！と気づき、修正がかかります。　このときは、画面設計まで戻って修正しないといけません。

　一般に、外部設計や旧来言っていた基本設計でのミスは、その設計をテストする結合テストまで、露呈しない危険性があります。よく、結合テストで問題が連続的に発覚、デスマーチになるのは、要するに、設計ミスです。

　では仮に、画面設計のとき、それに気づいて、画面を、「大分類」「中分類」「小分類」と３つのドロップダウンリストにしたらどうでしょう。なんかよさそうです。でも、ユーザーから見たら、大分類、中分類、小分類がどうなっているかわかってなかったとしたら、これは不便そうです。この不便さは、ユーザーの受け入れテストまで、発覚しないかもしれません。
　受け入れテストで発覚したら大変です。大きな作り直しになります。

---

　そこで、プロトタイプを開発することになります。
　画面だけを表示するとか、さらにちょっとしたデータを入出力するだけなら、ツールを使って簡単に作れる場合があります（というか、画面だけなら、たいてい簡単に作れます）

　ですので、設計段階で画面を作ってしまい（これがプロトタイプ）それをお客さんに見せて、OKを取っておけば、上記のような問題は起こらないはずです。このように、要求分析、設計段階で、画面などを部分的に作って(プロトタイプ）、お客さんや関係者などと確認を取りながら開発する方法が、プロトタイプ開発です。

---

　プロトタイプ開発の場合、作った画面等を、後工程で使うかどうかという話があります。
　このとき、後工程で使わない場合は、作ったプロトタイプを「モックアップ」ということがあります。また、プロトタイプは必ずしも「コンピューターで動くものでなくてはならない！」と定義されたものではないようです。紙レベルの紙芝居風のものも、プロトタイプということがあります。

　なお、上記の例の場合、画面は、この方法で問題を早期発見できますが、そもそも、１００００件の商品データを携帯側にどう持つのか、通信で送れるのか？といった、性能面はプロトタイプを作るだけでは、発見することが難しいです。
　つまり、プロトタイプを作れば完璧というわけではなくて、作っても検討しなければいけない問題が、まだ残っているわけです。