開発サイクル編

第１２章　プロトタイプ開発の利用

１２．１　プロトタイプ開発の使い方

• プロトタイプで作成したつもりのソースが、そのまま開発に使われた結果、製品の品質を低下させることとなった。
• 段階的な開発を行ったが、プロトタイプで作成したソースの再利用がほとんどできなかった。
• 検証目的が不明確だったために、プロトタイプは完成したが、結果として得るものがなかった。

効果と目的
検証/評価方法
再利用範囲

１２．２　Drop開発フェーズでプロトタイプを利用する。

コンポーネント構造評価プロトタイプ

• 目的
  　コンポーネントの関連構造や継承構造について、いくつかの選択肢を実装し、その後に評価検証する。これによって、誤りがなくバランスの取れたクラス構造を実現することを目的とする。このプロトタイプは、不慣れな問題領域や初めて採用するクラス構造設計に遭遇した時に、どうしても机上の理論だけでは評価しづらい場合や、重要なソフトウェア・アーキテクチャを決定する際に、構造的にもパフォーマンス的にも優位性のあるデザインを決める場合に有用である。
  
  
• 利用するフェーズ
  　ODGのコンポーネント分析フェーズで使用された検証結果は、コンポーネント分析フェーズにフイードバックされ、最終的なクラス階層と関連構造が決定される。
  
  
  
  

  図12-1 コンポーネント構造評価プロトタイプ

  
  
  
  
• 注意事項
  　このプロトタイプは、コンポーネントアーキテクチャの構造面のみを実装することとなり、プロトタイプ評価としては、問題に対してコンポーネントデザインが最適であるかという判断材料に役立つものでなければならない。
  
  

コンポーネントインタフェースプロトタイプ

• 目的
  　コンポーネントユーザから新規に要求されたコンポーネント開発が、ADGのコンポーネント利用フェーズに間に合わない場合に使用される。すなわち、実現のための検証が目的ではなく、すでに検証されたコンポーネントのインタフェース部分を早期に提供することが目的となる。このような時に、コンポーネントとしてサポートすべき基本インタフェース部分のみ先行して開発し提供する。この場合、インタフェースの実装を模擬するためのスタブを提供しなければならないケースもある。
  
  
• 利用するフェーズ
  ODGのコンポーネント設計フェーズの初期段階で使用され、インタフェースを決定してプロトタイプ開発に着手する。プロトタイプ開発が終了するとコンポーネント設計に戻り、残りの設計を継続する。
  
  
  
  

  図12-2コンポーネントインタフェースプロトタイプ

  
  
  
• 注意事項
  　提供する個々のクラスのインタフェースの仕様を明確にして、そのインタフェースは最終的なリリース時も保証するよう心がける必要がある。また、インタフェースに変更が発生しそうなケースはコンポーネントユーザに早急に伝えなければならない。
  　プロトタイプ基本計画書の再利用範囲は、クラスインタフェース部分のソースコード、品質保証範囲は、クラスのインタフェースのコード部分となる。もし、インタフェースだけではなく、実装を模擬するスタブをを作るならば、クラスインタフェース部からその部分を独立させておくべきである。そうでない場合、クラスインタフェースのコードを再利用するのは危険である。うつかり正式リリース時にそのようなコードが忍び込んでしまうという最悪の事態も考えられるからである。
  
  

システム構造評価プロトタイプ

• 目的
  　システムの全体的な基盤構造の決定は、その後のシステム開発に大きな影響を与える。できるだけ早い時期に短期間で正しい選択を促さなければならない。システム構造評価プロトタイプとは、システムの基盤構造を決定するために以下のような目的を持って行うプロトタイプである。
  
  
  • 利用する市販ソフトウェア製品の性能比較評価
  • システム基盤構造の実現可能性に対する評価
  • システムの性能が要求を満たすレベルであるかの評価
  
  
  
• 利用するフェーズ
  　システム共通設計において、システム構造をプロトタイプ開発により検証した結果、その問題点や改善点を洗い出す。そしてそれらをコンポーネント開発フェーズへ流すことでコンポーネント開発の基本指針を決定する。
  
  
  
  

  図12-3 システム構造評価プロトタイプ

  
  
  
• 注意事項
  　性能評価、方式評価が目的となるため、必要部分だけに焦点を絞り開発される。従ってよりよいクラス設計ということについては後回しされることが多いだろう。よって最終的なシステムにコードをまるごと再利用するということはなく、コンポーネント構造評価プロトタイプと同様にコンセプトのみの再利用ということになる。
  　ただし、性能評価については、クラス構造の優劣も性能に影響するパターンもありうる。このような場合は、コンポーネント構造評価プロトタイプを同時に行う必要がある。
  
  

ユーザインタフェース評価プロトタイプ

利用するフェーズ
システム共通設計フェーズの初期段階で共通的なユーザインタフェースを決定し、システム共通コンポーネントの開発として、コンポーネント分析フェーズへ流す。また、ADGのアプリケーション設計・実装フェーズでは、個々のアプリケーションのユーザインタフェースを決定するために使用され、問題点や改善点をアプリケーション設計・実装フェーズへフィードバックする。

図12-4 ユーザインタフェース評価プロトタイプ

注意事項
　できるだけ時間をかけず簡単にプロトタイプを開発することに心がけなければならない。そのためには、ビジュアル設計ツールや、簡易言語などを使うとよい。注意すべきことは、あまりにも簡単に画面を作れることでエンドユーザが、画面はいつでも変更ができるといった誤解を招くことがないようにしなければならない。そのためには、エンドユーザのプロトタイプに対する理解を深めてもらうようシステム管理者の努力が必要となるだろう。

---

プレゼンテーション支援プロトタイプ

• 目的
  　エンドユーザにシステムの効果や特徴をプレゼンテーションするために作成される。これは、大規模システムの計画・調査段階で使用されることとなり、予算獲得という目的の他に、エンドユーザと開発者の間でシステムのオーバービューを確認できるといった効果がある。これによってエンドユーザは、システムの大まかなビューと機能を直接目で確認することができるようになり、結果的に要求定義を支援することにつながるだろう。つまり、このプロトタイプは、システム開発計画のためのナビゲーション(道案内)的役割を果たしたり、早期に要求をコミットできるようにエンドユーザのシステムに対する理解を即したりする非常に有効な手段である。
  
  
• 利用するフェーズ
  
  　今までのプロトタイプとは異なり、開発サイクルの外側、計画・調査段階で使用される。
  
  
  
  

  図12-5 プレゼンテーション支援プロトタイプ

  
  
  
• 注意事項
  　できるだけ早くしかも本番システムと同じインタフェースや機能をシミュレートしなければならない。そのために、プロトタイピングツールを酷使することとなる。しかし、このプロトタイプは、本番システムの予告であることを忘れてはならない、本番の開発環境では実現不可能なユーザインタフェースや機能を取り込まないよう十分に注意をはらう必要があるだろう。

---