シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います
今回は「２．３ プロトタイプ（RAD)」です。
■２．３ プロトタイプ（RAD)
前章（２．２）で見た、V字型、フィードバックV字、W字型開発も結局、ウォーターフォールを踏襲しているものでした。
これらの方法に共通している問題として、開発リスクが先送りされてしまうという欠点があります。
たとえば、
「携帯の画面から受注データを送信する」
「その際、商品名は、選択できるように」
という仕様があったとします。
現実的には、商品が１００００点もあったら、商品名を選択するのが大変です。
だから、画面入力を考えれば、この仕様は、単純にはできない（何か工夫しないとできない）ということになります。
ウォーターフォールで開発する場合、この仕様の問題が露呈するのは、画面設計段階です。
しかし、そのとき、画面設計の人が、この問題を見落とし、１００００点もあるものをドロップダウンリストで設計してしまったら、どうなるでしょう。
プログラムが作成され、単体、結合テストまで行ってしまいます。
結合テストのとき、１００００件もドロップダウンできない！と気づき、修正がかかります。 このときは、画面設計まで戻って修正しないといけません。
一般に、外部設計や旧来言っていた基本設計でのミスは、その設計をテストする結合テストまで、露呈しない危険性があります。よく、結合テストで問題が連続的に発覚、デスマーチになるのは、要するに、設計ミスです。
では仮に、画面設計のとき、それに気づいて、画面を、「大分類」「中分類」「小分類」と３つのドロップダウンリストにしたらどうでしょう。なんかよさそうです。でも、ユーザーから見たら、大分類、中分類、小分類がどうなっているかわかってなかったとしたら、これは不便そうです。この不便さは、ユーザーの受け入れテストまで、発覚しないかもしれません。
受け入れテストで発覚したら大変です。大きな作り直しになります。
そこで、プロトタイプを開発することになります。
画面だけを表示するとか、さらにちょっとしたデータを入出力するだけなら、ツールを使って簡単に作れる場合があります（というか、画面だけなら、たいてい簡単に作れます）
ですので、設計段階で画面を作ってしまい（これがプロトタイプ）それをお客さんに見せて、OKを取っておけば、上記のような問題は起こらないはずです。このように、要求分析、設計段階で、画面などを部分的に作って(プロトタイプ）、お客さんや関係者などと確認を取りながら開発する方法が、プロトタイプ開発です。
プロトタイプ開発の場合、作った画面等を、後工程で使うかどうかという話があります。
このとき、後工程で使わない場合は、作ったプロトタイプを「モックアップ」ということがあります。また、プロトタイプは必ずしも「コンピューターで動くものでなくてはならない！」と定義されたものではないようです。紙レベルの紙芝居風のものも、プロトタイプということがあります。
なお、上記の例の場合、画面は、この方法で問題を早期発見できますが、そもそも、１００００件の商品データを携帯側にどう持つのか、通信で送れるのか？といった、性能面はプロトタイプを作るだけでは、発見することが難しいです。
つまり、プロトタイプを作れば完璧というわけではなくて、作っても検討しなければいけない問題が、まだ残っているわけです。
今回は「２．３ プロトタイプ（RAD)」です。
■２．３ プロトタイプ（RAD)
前章（２．２）で見た、V字型、フィードバックV字、W字型開発も結局、ウォーターフォールを踏襲しているものでした。
これらの方法に共通している問題として、開発リスクが先送りされてしまうという欠点があります。
たとえば、
「携帯の画面から受注データを送信する」
「その際、商品名は、選択できるように」
という仕様があったとします。
現実的には、商品が１００００点もあったら、商品名を選択するのが大変です。
だから、画面入力を考えれば、この仕様は、単純にはできない（何か工夫しないとできない）ということになります。
ウォーターフォールで開発する場合、この仕様の問題が露呈するのは、画面設計段階です。
しかし、そのとき、画面設計の人が、この問題を見落とし、１００００点もあるものをドロップダウンリストで設計してしまったら、どうなるでしょう。
プログラムが作成され、単体、結合テストまで行ってしまいます。
結合テストのとき、１００００件もドロップダウンできない！と気づき、修正がかかります。 このときは、画面設計まで戻って修正しないといけません。
一般に、外部設計や旧来言っていた基本設計でのミスは、その設計をテストする結合テストまで、露呈しない危険性があります。よく、結合テストで問題が連続的に発覚、デスマーチになるのは、要するに、設計ミスです。
では仮に、画面設計のとき、それに気づいて、画面を、「大分類」「中分類」「小分類」と３つのドロップダウンリストにしたらどうでしょう。なんかよさそうです。でも、ユーザーから見たら、大分類、中分類、小分類がどうなっているかわかってなかったとしたら、これは不便そうです。この不便さは、ユーザーの受け入れテストまで、発覚しないかもしれません。
受け入れテストで発覚したら大変です。大きな作り直しになります。
そこで、プロトタイプを開発することになります。
画面だけを表示するとか、さらにちょっとしたデータを入出力するだけなら、ツールを使って簡単に作れる場合があります（というか、画面だけなら、たいてい簡単に作れます）
ですので、設計段階で画面を作ってしまい（これがプロトタイプ）それをお客さんに見せて、OKを取っておけば、上記のような問題は起こらないはずです。このように、要求分析、設計段階で、画面などを部分的に作って(プロトタイプ）、お客さんや関係者などと確認を取りながら開発する方法が、プロトタイプ開発です。
プロトタイプ開発の場合、作った画面等を、後工程で使うかどうかという話があります。
このとき、後工程で使わない場合は、作ったプロトタイプを「モックアップ」ということがあります。また、プロトタイプは必ずしも「コンピューターで動くものでなくてはならない！」と定義されたものではないようです。紙レベルの紙芝居風のものも、プロトタイプということがあります。
なお、上記の例の場合、画面は、この方法で問題を早期発見できますが、そもそも、１００００件の商品データを携帯側にどう持つのか、通信で送れるのか？といった、性能面はプロトタイプを作るだけでは、発見することが難しいです。
つまり、プロトタイプを作れば完璧というわけではなくて、作っても検討しなければいけない問題が、まだ残っているわけです。
アクセス
トータル
ランキング
