開発サイクル編 -
第１２章 プロトタイプ開発の利用
１２．１ プロトタイプ開発の使い方
プロトタイプ開発は、システムの全体または一部を対象として、早期に開発し評価する方法である。たとえば、分析や設計フェーズにおいては、すべての問題を初めから理解し、最善の策を得られるわけではない。プロトタイプ開発をうまく利用することで、分析・設計フェーズの質を高め、作業速度を早くすることができる。このように、プロトタイプ開発の利用は非常に有効な手段である。しかしながら、プロトタイピングの使い方を誤ってしまうと、以下のような問題が生ずることになる。
- プロトタイプで作成したつもりのソースが、そのまま開発に使われた結果、製品の品質を低下させることとなった。
- 段階的な開発を行ったが、プロトタイプで作成したソースの再利用がほとんどできなかった。
- 検証目的が不明確だったために、プロトタイプは完成したが、結果として得るものがなかった。
これらの問題を防ぎ、プロトタイプ開発を成功させるためには、
- 効果と目的
- 検証/評価方法
- 再利用範囲
を明確に定め、プロジエクトの中で承認を得るという体系的アプローチが必要とされる 。上記は、プロトタイプ開発基本計画書により記述されなければならない。
| 項目 | 記述内容 |
|---|---|
| 名称 | プロトタイプの種類 |
| 目的 | 何を検証するのか、どの部分を作るのか |
| 期待効果 | 期待する効果は何か |
| 要求仕様 | 目的に応じて何（機能）が必要とされるのか |
| 開発工程 | プロトタイプ開発において、どのような工程を取るのか |
| 開発期間 | いつまでに作るのか |
| 開発担当者 | 誰（チーム）が開発するのか |
| 開発言語 | 言語は何か |
| 再利用範囲 | どの部分を本体（システム）に再利用するのか |
| 品質保証範囲 | 再利用する部分の品質をどの程度保つのか |
| 検証／評価方法 | その検証結果や評価を得る方法は何か |
| 必要ドキュメント | 必要とされるドキュメントは何か |
| 検証／評価の結果 | プロトタイプ開発完了後に最終的な検証／評価の結果を記述する |
１２．２ Drop開発フェーズでプロトタイプを利用する。
Drop開発サイクルにおけるプロトタイプ開発の利用を目的別に分けて解説する。これらは、開発フェーズの中に組み込まれた形で行われるものである。実際のシステム開発では、ここに解説されるものを参考として、そのシステム開発に必要なものだけが採用されることになる。
コンポーネント構造評価プロトタイプ
目的
コンポーネントの関連構造や継承構造について、いくつかの選択肢を実装し、その後に評価検証する。これによって、誤りがなくバランスの取れたクラス構造を実現することを目的とする。このプロトタイプは、不慣れな問題領域や初めて採用するクラス構造設計に遭遇した時に、どうしても机上の理論だけでは評価しづらい場合や、重要なソフトウェア・アーキテクチャを決定する際に、構造的にもパフォーマンス的にも優位性のあるデザインを決める場合に有用である。
利用するフェーズ
ODGのコンポーネント分析フェーズで使用された検証結果は、コンポーネント分析フェーズにフイードバックされ、最終的なクラス階層と関連構造が決定される。
図12-1 コンポーネント構造評価プロトタイプ
注意事項
このプロトタイプは、コンポーネントアーキテクチャの構造面のみを実装することとなり、プロトタイプ評価としては、問題に対してコンポーネントデザインが最適であるかという判断材料に役立つものでなければならない。
コンポーネントインタフェースプロトタイプ
目的
コンポーネントユーザから新規に要求されたコンポーネント開発が、ADGのコンポーネント利用フェーズに間に合わない場合に使用される。すなわち、実現のための検証が目的ではなく、すでに検証されたコンポーネントのインタフェース部分を早期に提供することが目的となる。このような時に、コンポーネントとしてサポートすべき基本インタフェース部分のみ先行して開発し提供する。この場合、インタフェースの実装を模擬するためのスタブを提供しなければならないケースもある。
利用するフェーズ
ODGのコンポーネント設計フェーズの初期段階で使用され、インタフェースを決定してプロトタイプ開発に着手する。プロトタイプ開発が終了するとコンポーネント設計に戻り、残りの設計を継続する。
図12-2コンポーネントインタフェースプロトタイプ
注意事項
提供する個々のクラスのインタフェースの仕様を明確にして、そのインタフェースは最終的なリリース時も保証するよう心がける必要がある。また、インタフェースに変更が発生しそうなケースはコンポーネントユーザに早急に伝えなければならない。
プロトタイプ基本計画書の再利用範囲は、クラスインタフェース部分のソースコード、品質保証範囲は、クラスのインタフェースのコード部分となる。もし、インタフェースだけではなく、実装を模擬するスタブをを作るならば、クラスインタフェース部からその部分を独立させておくべきである。そうでない場合、クラスインタフェースのコードを再利用するのは危険である。うつかり正式リリース時にそのようなコードが忍び込んでしまうという最悪の事態も考えられるからである。
システム構造評価プロトタイプ
目的
システムの全体的な基盤構造の決定は、その後のシステム開発に大きな影響を与える。できるだけ早い時期に短期間で正しい選択を促さなければならない。システム構造評価プロトタイプとは、システムの基盤構造を決定するために以下のような目的を持って行うプロトタイプである。
- 利用する市販ソフトウェア製品の性能比較評価
- システム基盤構造の実現可能性に対する評価
- システムの性能が要求を満たすレベルであるかの評価
利用するフェーズ
システム共通設計において、システム構造をプロトタイプ開発により検証した結果、その問題点や改善点を洗い出す。そしてそれらをコンポーネント開発フェーズへ流すことでコンポーネント開発の基本指針を決定する。
図12-3 システム構造評価プロトタイプ
注意事項
性能評価、方式評価が目的となるため、必要部分だけに焦点を絞り開発される。従ってよりよいクラス設計ということについては後回しされることが多いだろう。よって最終的なシステムにコードをまるごと再利用するということはなく、コンポーネント構造評価プロトタイプと同様にコンセプトのみの再利用ということになる。
ただし、性能評価については、クラス構造の優劣も性能に影響するパターンもありうる。このような場合は、コンポーネント構造評価プロトタイプを同時に行う必要がある。
ユーザインタフェース評価プロトタイプ
目的
ユーザインタフェースを決定するために画面の詳細や画面遷移などを実装し、エンドユーザに実際に使わせることで、画面操作性の確認や、エンドユーザの漠然とした要求を早期に具体化することが目標となる。
利用するフェーズ
システム共通設計フェーズの初期段階で共通的なユーザインタフェースを決定し、システム共通コンポーネントの開発として、コンポーネント分析フェーズへ流す。また、ADGのアプリケーション設計・実装フェーズでは、個々のアプリケーションのユーザインタフェースを決定するために使用され、問題点や改善点をアプリケーション設計・実装フェーズへフィードバックする。
図12-4 ユーザインタフェース評価プロトタイプ
注意事項
できるだけ時間をかけず簡単にプロトタイプを開発することに心がけなければならない。そのためには、ビジュアル設計ツールや、簡易言語などを使うとよい。注意すべきことは、あまりにも簡単に画面を作れることでエンドユーザが、画面はいつでも変更ができるといった誤解を招くことがないようにしなければならない。そのためには、エンドユーザのプロトタイプに対する理解を深めてもらうようシステム管理者の努力が必要となるだろう。
プレゼンテーション支援プロトタイプ
目的
エンドユーザにシステムの効果や特徴をプレゼンテーションするために作成される。これは、大規模システムの計画・調査段階で使用されることとなり、予算獲得という目的の他に、エンドユーザと開発者の間でシステムのオーバービューを確認できるといった効果がある。これによってエンドユーザは、システムの大まかなビューと機能を直接目で確認することができるようになり、結果的に要求定義を支援することにつながるだろう。つまり、このプロトタイプは、システム開発計画のためのナビゲーション(道案内)的役割を果たしたり、早期に要求をコミットできるようにエンドユーザのシステムに対する理解を即したりする非常に有効な手段である。
利用するフェーズ
今までのプロトタイプとは異なり、開発サイクルの外側、計画・調査段階で使用される。
図12-5 プレゼンテーション支援プロトタイプ
注意事項
できるだけ早くしかも本番システムと同じインタフェースや機能をシミュレートしなければならない。そのために、プロトタイピングツールを酷使することとなる。しかし、このプロトタイプは、本番システムの予告であることを忘れてはならない、本番の開発環境では実現不可能なユーザインタフェースや機能を取り込まないよう十分に注意をはらう必要があるだろう。
