ビジネス要件を、実際に動作するシステムとしてご提供します。これによって、ビジネス・ユーザが考えていたイメージと要件定義でドキュメント化されたもののギャップを明らかにし、それを埋めることができます。
要件定義の後、あるいは、要件定義の一部として、システムのプロトタイピングを行うことは、2つの点で非常に効果的です。
1つ目は、実際に動作する機能を提示することによって、エンドユーザーによるビジネス要件イメージとの乖離を早い段階で埋めることができます。エンドユーザーは、頭の中でイメージしているシステムがあります。あるいは、イメージできていない場合もあります。いずれの場合でも、システムとして実際に機能するものが提示された場合、イメージとのギャップから違和感を感じます。リリース直前になって、要件ギャップを埋めるための変更依頼をされることは、非常に困難です。しかし、プロトタイピングでは早い段階でギャップを埋めることができます。
このような要件イメージの乖離に対しては、ソフトウェアとして機能するものでなくとも、原始的な画面イメージを絵にした「紙芝居」による要件イメージの可視化というアプローチも用いられています。
2つ目の効果は、採用を予定するフレームワークを使用することによって、システム設計上のリスクを予め洗い出すことができます。システム設計者は、経験のあるフレームワークを用いれば、実現可能性や工数見積りがそれほど難しいわけではありません。しかし、様々なフレームワークが登場したり、メジャー・バージョンアップが行われている状況では、あらたなシステム設計をするときには、過去の経験では計り切れない場合もあります。
このような状況で、システム構築の見積をするのに最も適した方法は、ある程度、中核となる機能を採用予定のフレームワークでプロトタイピングしてみることです。これを行っておけば、設計・実装フェーズに入ってから、想定外のリスクでプロジェクトに危機をもたらす可能性を減らすことができます。
また、近年、Railsのようなラピッド・プロトタイピングの技術が急速に進歩しているため、プロトタイプとして品質などを割り切ることによって、短期間で機能要件の多くを実現することができるようになっています。
サービス・メニュー
パートナー様向け