ソフトウェアプロトタイピング（英: Software Prototyping）とは、将来完成する予定のソフトウェアの不完全なモデル（プロトタイプ）を作成することおよびその過程を意味する。プロトタイプは完成品についてのイメージをユーザーに抱かせ、顧客がそのプログラムを評価することができる。これにはいくつかの利点がある。設計者や実装者はプロジェクトの初期段階でユーザーからフィードバックを得ることができる。顧客や契約者はそのソフトウェアがソフトウェア仕様に適合しているかどうかを比較検討できる。また、ソフトウェア開発者はプロジェクトの工数を正確に見積もることが可能となり、要求されている期限などが（人員や開発設備などに照らして）妥当かどうかを検討できる。プロトタイピングをどの程度完璧にすべきかやその製作技法に関しては、1970年代初期から議論を呼んでいる。1960年代や1970年代の固定的な開発サイクルでは、完全なプログラムをまず製作し、それから設計と実装の不整合に対処したりしていた。この方式は開発費用の増大を招き、費用や期間の予測も難しかった。プロトタイピングは多大な出費を防ぎ、完成したプログラム修正という困難な作業を低減する。プロトタイピングはフレデリック・ブルックスの1975年の著書『人月の神話』の主要テーマの1つでもあった。プロトタイピングは以下のようなステップで行われる:ソフトウェアプロトタイピングにはさまざまな手法があるが、それらの手法は以下の2種類に大別される。使い捨て型/ラピッド（高速）プロトタイピングでは、作成したモデルは、最終的なソフトウェアの一部となるよりも、捨てられる可能性が高い。初期の要求仕様分析が完了すると、システムの単純な動作モデルが作られ、要求仕様を可視化してみせ、最終的にシステムがどのように見えるかをユーザーに見せる。使い捨て型プロトタイピングを行う最も明白な理由は、その素早さにある。ユーザーが要求仕様について即座にフィードバックできるなら、ソフトウェア開発の早い段階で改善できる。このような早期の改善はソフトウェア開発においては費用を抑える有力な手法である（早期であれば、何かを再度行うにしても費用がかからないため）。プロジェクトがかなり進行してから変更が発生すると、ソフトウェアの各コンポーネント間の依存関係などによって、小さな変更でも大きな作業を生む。従って使い捨て型プロトタイプの実装は素早さが重要であり、捨てられる運命であるため、時間と費用も最小に抑えなければならない。使い捨て型プロトタイピングの別の利点として、ユーザーがテストできるインタフェースを提供できるという点が挙げられる。ユーザインタフェースはシステムの中でもユーザーの目に触れる部分であり、それを目にすることでそのシステムがどういうものかを把握しやすくなる。プロトタイプは、その実際の製品の見た目/動作/タイミングをどの程度忠実に再現しているかで分類できる。最も再現性が低い使い捨て型プロトタイピングとして、紙と鉛筆を使ったプロトタイピングがある。いわゆるポンチ絵である。再現性の高い使い捨て型プロトタイプとしては、GUIビルダーを使ってクリック可能なダミー画面を作るという方法がある。こちらは製品と変わらない見た目だが、見た目だけで機能は提供されない。使い捨て型プロトタイピングとは言えないかもしれないが、絵コンテを使った手法もある。機能する実装ではないが、システムの見た目を示すことができる（ユーザーエクスペリエンス設計）。また、調査用のプロトタイピングの事を、エクストリーム・プログラミングでは、特に「スパイク」と呼んでいる。進化的プロトタイピング（ブレッドボード・プロトタイピングとも呼ぶ）は、使い捨て型プロトタイピングとは全く異なる。進化的プロトタイピングの主要目標は正式な方法で非常に堅牢なプロトタイプを作り、それを継続的に改良していくことである。「その理由は、進化的プロトタイプが作られると、それが新たなシステムの心臓部となり、その上に新たな要求を作りこんだり改善したりする」進化的プロトタイピングを使った開発では、システムは継続的に改良され再構築される。「…進化的プロトタイピングでは、要求仕様を完全に把握する必要はなく、よくわかっている部分だけについて開発を行う」 この手法では開発チームは機能を追加したり要求分析時点では想定されていなかった変更を加えたりできる。進化的プロトタイピングは、それが実際に機能するシステムであるという点で使い捨て型プロトタイピングよりも優れている。しかし、それにはユーザーが計画した機能が全て実装されているわけではなく、最終的なシステムが提供されるまでの暫定システムとなるだろう。進化的プロトタイピングでは、開発者はシステム全体を一気に開発するのではなく、理解している部分から先に開発することに注力できる。ソフトウェア開発にプロトタイピングを使う利点は多々あり、一部は実利的な利点で一部は抽象的である。プロトタイピングの（間違った使い方を含めた）問題点もある。プロトタイピングは何らかの形であらゆる場合に利用可能であると主張する人もいる。しかし、プロトタイピングはユーザーとのやりとりが多いシステムで特に有効であると言える。バッチ処理のような計算が主体のシステムではユーザーとのやり取りが少なく、プロトタイピングの効果は小さい。システム機能を実現するためのコードが重要であり、プロトタイプで提供できることが非常に少ないのである。プロトタイピングは特にユーザインタフェースの設計で威力を発揮する。「ラピッドプロトタイピングの最も生産的な利用法は段階的なユーザー要求定義とユーザインタフェース設計のツールとしての利用である」。プロトタイピングの手法がいくつか存在する。多くのアジャイル的手法もプロトタイピング技法に基づいている。Dynamic Systems Development Method (DSDM) は主要な技法としてプロトタイピングを使用するビジネスソリューションのためのフレームワークであり、ISO 9001 の認証を受けている。DSDMはプロトタイプの一般的認識をさらに拡張している。DSDMによれば、プロトタイプは、図だったり、ビジネスプロセスだったり、製造中のシステムだったりする。DSDMのプロトタイプは段階的であり、単純な形態から複雑なものへと拡張されていく。DSDM のプロトタイプは「使い捨て型」も「進化的」なものもある。進化的プロトタイプは水平的に拡張されたり（機能追加）、垂直的に拡張されたりする（詳細化）。最終的に進化的プロトタイプが最終システムになっていく。DSDMで推奨するプロトタイプは以下の4つに分類される:DSDMでのプロトタイピングの流れは次のようになる:Alan Davis が提唱した Operational Prototyping は、従来型のシステム開発に使い捨て型プロトタイピングと進化的プロトタイピングを統合する方法である。「プロトタイピングの利点と従来型開発の利点を利用する方法である。設計者はよく理解している機能だけを段階的に開発していき、機能を正しく理解しているかどうかを実験するために使い捨て型プロトタイピングを用いる」 Davis の考え方は、従来型開発にプロトタイプを持ち込む場合、「ラピッドプロトタイプを使って品質を高める」のは正しくないということである。彼はシステムの発展の際にその機能を進化的プロトタイピングとラピッドプロトタイピングで実現するというものである。実際の方法は以下のステップで行われる:これを見て明らかなように、この手法の鍵となるのはよく訓練されたプロトタイプの専門家である。Operational Prototyping はユーザーからの要求が少ない複雑なシステムで有効である。進化的システム開発（Evolutionary Systems Development）は進化的プロトタイピングの形式的実装を試みる方法論である。例えば John Crinnion が著書 "Evolutionary Systems Development" で描いた Systemscraft などがある。Systemscraft はプロトタイプの方法論であり、実際の開発環境などに合わせて変更すべきものとされている。Systemscraftの基本は、初期の要求仕様に基づいて実働するシステムを作成し、それをベースとして一連の改版を行っていくものである。Systemscraft は従来型の分析手法を重視して、開発工程全体でそれを活用する。進化的ラピッド開発（Evolutionary Rapid Development、ERD） はDARPAの情報技術部門配下にある Software Productivity Consortium が開発した。顧客やユーザーの入力を引き出すため、関係者と頻繁に会議を重ねる。設計・実装に関する決定をする前にフィードバックを得るためにシステム機能の実演を行う。頻繁にリリースを行うことで（ベータ版）、ユーザーや顧客のニーズをサポートするためのよりよい手法に関する洞察が得られる。これによりシステムはユーザーのニーズに合わせて進化する。システムの設計フレームワークは既存の一般的な標準に基づく。システムは性能・容量・機能などの発展の可能性を考慮して構成される。アーキテクチャは、サービスとその実装をカプセル化する抽象インタフェースとして定義される。アーキテクチャは複数の実際のシステム開発をガイドするテンプレートとして働く。複数のアプリケーション・コンポーネントを使ってサービスを実装するためにもアーキテクチャが重要である。変更されにくい中核的機能群も特定され確立される。ERDプロセスでは、機能の実演を行うことで関係者との対話を図りニーズや期待を引き出す。このための迅速な提供を可能にするためにタイムボックス管理が行われる。タイムボックスとは固定の期間を意味し、ある作業（例えば、ある機能群の開発）をその期間内に必ず完了させなければならない。漠然とした目標群を達成するために期間を必要に応じて延長可能にするのではなく、期間を固定し（週数だったり、人Hのような工数）、その期間内で完了することが現実的と思われる作業を割り当てる。運に任せるような開発状況に陥らないように、長期の計画はタイムボックス単位の反復をガイドするよう定義される。このような計画によってシステム全体の見通しが立ち、プロジェクトの条件が明確化する。アーキテクチャが確立すると、ソフトウェアの組み立てとテストが毎日行われる。これによりチームは客観的に進捗を評価でき、潜在する問題を迅速に発見することが可能となる。一度に新たに統合される部分はごく小さいので、問題を発見して対処することは迅速に行われる。システムは基本的に常に動作可能であるため、ユーザーへの実演は必要に応じて即座に実施可能である。プロトタイピングを効果的に行うには、適切なツールとそれに熟達した人員が必要である。プロトタイピング用ツールとしては、第4世代言語を使ったツールやより複雑な統合型CASEツールなどがある。Visual Basicなどの第4世代言語は、その手軽さからよく使われる。CASEツールは軍や大企業などで使われることが多い。オブジェクト指向ツールも開発されている。よく使われるものとして画面生成プログラムがある。これは機能は組み込まれていないが画面の見た目をユーザーに示すプロトタイプの作成に使われる。インタフェースはユーザーにとってシステムそのものであるため、ユーザインタフェースの開発は重要な部分を占めることがある。ラピッドプロトタイピングのツールとして Visual Basic も使われる。Visual Basic はプログラミング言語だが、次のような機能があるためプロトタイプ作成に適している:欠点は以下の通り:要求工学環境（Requirements Engineering Environment、REE）は、1985年からローム研究所が開発しており、複雑なシステムの重要な部分のモデルを迅速に実装し動作させるためのツール群を提供する要求工学環境は、アメリカ空軍がシステム開発に使用している。要求工学環境は3つの部分からなる。第1は Proto と呼ばれるラピッドプロトタイピングのためのCASEツールである。第2は Rapid Interface Prototyping System（RIP）と呼ばれ、ユーザインタフェース構築のためのツール群である。3番目は Proto と RIP にアクセスするためのグラフィカルなユーザインタフェースである。ローム研究所は、内部の要求分析手法のために要求工学環境を開発した。手法は3つの部分からなる:1996年、ローム研究所は REE の商用化を目指して Software Productivity Solutions (SPS) と契約した。この商用版REEを Advanced Requirements Engineering Workstation（AREW）と名づけている。LYMB はオブジェクト指向開発環境であり、GUI、可視化、ラピッドプロトタイピングなどを必要とするアプリケーション開発に適している。

出典:wikipedia