プロトタイピング

• プロトタイプは容易に変更可能
• 資金を集めるために必要な概念実証（Proof of Concept）を提供可能
• プロトタイプを早期に目に見える形で実現することで最終的にどういうシステムになるのかユーザーが予想できる
• ユーザーと製作者の間で活発な意見交換が行われる可能性がある
• ユーザーに対してより高度な製品を提供する
• 費用対効果が高い（開発費用が抑えられる）
• システム開発が加速される
• アイデアやコンセプトを形にすることで、共通の言語が形成され、それぞれの認知的負担を軽減し、コミュニケーションの円滑化に繋がる

• 製作者は組織全体の必要性に適合しないシステムを作る可能性がある
• 製作者がプロトタイプに固執する可能性
• 柔軟性の欠如
• 大規模アプリケーションには不向き
• プロジェクトマネジメントが困難

ソフトウェア開発工程のモデルの1つとしてプロトタイピング・モデルがある。要求を集め、プロトタイピングを行い、ユーザーがそれを検証する。エンドユーザーは何が必要か明確に意識していないことが多く、要求分析フェーズで明確な要求や目的を開発者に伝えられないことがある。このためにプロトタイプが使われる。ユーザーがプロトタイプを検証した後、そのフィードバックに基づいて新たなプロトタイプが作られ、再度ユーザーがその検証を行う。各サイクルはユーザーから聞き出すところから始まり、それに基づいてプロトタイプが作られ、それをユーザーがテストし、最初に戻る。

1980年代中ごろ、プロトタイピングはソフトウェア工学における要求分析問題の解決策として導入された。この場合のプロトタイプはアプリケーションの画面のモックアップ（原寸模型）であり、ユーザーはそれによって未だ開発されていないアプリケーションを頭に描くことができる。これによって開発されるシステムに何が必要かという設計上の決定をユーザーが行うことが容易になる。プロトタイプが導入された当初、その結果は驚異的だった。プロトタイプの導入によってユーザーと開発者のコミュニケーションは劇的に改善された。最初に画面を提示することで後からの変更が少なくなり、全体としての費用もかなり低減される。

しかし、その後の10年でプロトタイピングによっても解決できない次のような要求分析問題があることが明らかとなった:

• 管理者クラスがプロトタイプを見たとき、製品がすぐにできないことを理解するのが難しいことがある。
• 設計者は時間を浪費しないことを心がけているため、プロトタイプのコードを製品に使わざるをえないと感じ、（実装の選択肢を）強制されていると感じることがある。
• プロトタイプは設計上の決定やユーザインタフェース設計に有効であるが、本来の要求が何であったかはプロトタイプからはわからない。
• 設計者やエンドユーザーがユーザインタフェースにかかりきりになり、システムの本体であるはずのビジネスプロセスが放って置かれる傾向がある。