ソフトウェアプロトタイピング（英: Software Prototyping）とは、将来完成する予定のソフトウェアの不完全なモデル（プロトタイプ）を作成することおよびその過程を意味する。プロトタイプは完成品についてのイメージをユーザーに抱かせ、顧客がそのプログラムを評価することができる。これにはいくつかの利点がある。設計者や実装者はプロジェクトの初期段階でユーザーからフィードバックを得ることができる。顧客や契約者はそのソフトウェアがソフトウェア仕様に適合しているかどうかを比較検討できる。また、ソフトウェア開発者はプロジェクトの工数を正確に見積もることが可能となり、要求されている期限などが（人員や開発設備などに照らして）妥当かどうかを検討できる。プロトタイピングをどの程度完璧にすべきかやその製作技法に関しては、1970年代初期から議論を呼んでいる^[1]。

1960年代や1970年代の固定的な開発サイクルでは、完全なプログラムをまず製作し、それから設計と実装の不整合に対処したりしていた。この方式は開発費用の増大を招き、費用や期間の予測も難しかった。プロトタイピングは多大な出費を防ぎ、完成したプログラム修正という困難な作業を低減する。

プロトタイピングはフレデリック・ブルックスの1975年の著書『人月の神話』の主要テーマの1つでもあった。

プロトタイピングは以下のようなステップで行われる:

1. 要求分析を行う
   • 基本要求を見定め、必要とされる情報の入出力を確定する。なお、セキュリティなどの詳細はここでは無視する。
2. 最初のプロトタイプを開発する
   • ユーザインタフェースだけで構成されるプロトタイプを開発する。
3. レビュー
   • エンドユーザーを含む顧客にプロトタイプを実際に使ってもらい、追加点や修正点などのフィードバックをもらう。
4. プロトタイプの改良
   • フィードバックを反映して、要求仕様とプロトタイプの両方を改良する。ここでは、契約範囲/製品内容に関する調整が必須となる。変更が加えられたら、3番と4番を繰り返す。

ソフトウェアプロトタイピングにはさまざまな手法があるが、それらの手法は以下の2種類に大別される。

使い捨て型/ラピッド（高速）プロトタイピングでは、作成したモデルは、最終的なソフトウェアの一部となるよりも、捨てられる可能性が高い。初期の要求仕様分析が完了すると、システムの単純な動作モデルが作られ、要求仕様を可視化してみせ、最終的にシステムがどのように見えるかをユーザーに見せる。

ラピッドプロトタイピングでは、比較的短期間の調査期間の後、かなり早い段階でシステムの様々な部分の動作モデルを製作する。その製作手法はあまり形式に拘らず、なによりも製作期間が短いことが重要である。そのモデルをユーザーが評価し、要求をさらに明確化させる。これが出来たらプロトタイプは捨てられ、要求仕様に従って正式な開発が開始される^[2]。

使い捨て型プロトタイピングを行う最も明白な理由は、その素早さにある。ユーザーが要求仕様について即座にフィードバックできるなら、ソフトウェア開発の早い段階で改善できる。このような早期の改善はソフトウェア開発においては費用を抑える有力な手法である（早期であれば、何かを再度行うにしても費用がかからないため）。プロジェクトがかなり進行してから変更が発生すると、ソフトウェアの各コンポーネント間の依存関係などによって、小さな変更でも大きな作業を生む。従って使い捨て型プロトタイプの実装は素早さが重要であり、捨てられる運命であるため、時間と費用も最小に抑えなければならない。

使い捨て型プロトタイピングの別の利点として、ユーザーがテストできるインタフェースを提供できるという点が挙げられる。ユーザインタフェースはシステムの中でもユーザーの目に触れる部分であり、それを目にすることでそのシステムがどういうものかを把握しやすくなる。

…進化的ラピッドプロトタイピングがユーザーの要求に関連する問題のより効果的な解決策になるとされており、ソフトウェア開発の全体の効率も劇的に改善する。発展性/保守性/ソフトウェア構造などを度外視すれば、要求を見定め、シミュレートし、テストすることはたやすい。これにより要求が明確化され、ユーザー視点のシステムの構築のモデルとなる^[3]。

プロトタイプは、その実際の製品の見た目/動作/タイミングをどの程度忠実に再現しているかで分類できる。最も再現性が低い使い捨て型プロトタイピングとして、紙と鉛筆を使ったプロトタイピングがある。いわゆるポンチ絵である。再現性の高い使い捨て型プロトタイプとしては、GUIビルダーを使ってクリック可能なダミー画面を作るという方法がある。こちらは製品と変わらない見た目だが、見た目だけで機能は提供されない。

使い捨て型プロトタイピングとは言えないかもしれないが、絵コンテを使った手法もある。機能する実装ではないが、システムの見た目を示すことができる（ユーザーエクスペリエンス設計）。

また、調査用のプロトタイピングの事を、エクストリーム・プログラミングでは、特に「スパイク」と呼んでいる。

進化的プロトタイピング（ブレッドボード・プロトタイピングとも呼ぶ）は、使い捨て型プロトタイピングとは全く異なる。進化的プロトタイピングの主要目標は正式な方法で非常に堅牢なプロトタイプを作り、それを継続的に改良していくことである。「その理由は、進化的プロトタイプが作られると、それが新たなシステムの心臓部となり、その上に新たな要求を作りこんだり改善したりする」^[2]

進化的プロトタイピングを使った開発では、システムは継続的に改良され再構築される。「…進化的プロトタイピングでは、要求仕様を完全に把握する必要はなく、よくわかっている部分だけについて開発を行う」^[4] この手法では開発チームは機能を追加したり要求分析時点では想定されていなかった変更を加えたりできる。

システムを有効なものにするには、それを実環境で使ってみる必要がある。製品は決して完成することはなく、実環境の変化に伴って常に調整される…システムは現在の環境に従って定義される。その時どきのビジネス手法や技術が前提となる。何らかの機能を開発する計画が立てられ、想定していたものと似たものが提供される。^[5]

進化的プロトタイピングは、それが実際に機能するシステムであるという点で使い捨て型プロトタイピングよりも優れている。しかし、それにはユーザーが計画した機能が全て実装されているわけではなく、最終的なシステムが提供されるまでの暫定システムとなるだろう。

「プロトタイピング環境では、最初のプロトタイプをユーザーが実業務に使うことは珍しくない…ユーザーは欠陥のあるシステムでも何もないよりましと判断するのだろう」^[2]

進化的プロトタイピングでは、開発者はシステム全体を一気に開発するのではなく、理解している部分から先に開発することに注力できる。

リスクを最小にするため、開発者は理解が不足している機能は実装しない。部分的に実装されたシステムが顧客側に渡される。ユーザーはそのシステムをしばらく使い、その間に新たな要求が見つかり、それが開発者に伝えられる。開発者はその改善点を要求仕様に加え、設計を更新し、再コーディングと再テストを行う。^[6]

ソフトウェア開発にプロトタイピングを使う利点は多々あり、一部は実利的な利点で一部は抽象的である^[7]。

時間と費用の削減

プロトタイピングによって要求仕様の品質が向上する。開発の後の工程で変更が発生すると、その対処にかかる時間は指数関数的に増大するため、ユーザーの要求を早期に把握することで開発の期間も費用も低減される。^[3]

ユーザー関与の増大と改善

プロトタイピングはユーザーの関与を必要とし、ユーザーの関与によってよりよいフィードバックと要求が得られる^[2]。ユーザーがプロトタイプを評価することにより、誤解と対話不足を解消する。ユーザーはシステムの対象とする分野の専門知識があり、対話が増えることで最終的な製品の使い易さや実用性が向上する。最終製品はユーザーの求めていた見た目や使い勝手や性能をよりよく実現している。

プロトタイピングの（間違った使い方を含めた）問題点もある^[7]。

不十分な分析

限定されたプロトタイプに注目することで、開発者はプロジェクトの完全な要求分析を怠る場合がある。これにより、よりよい解決策を見逃したり、要求仕様が不十分になったり、最終的な製品が保守しにくいものになったりする。また、機能が限定されたプロトタイプは最終製品に流用することを想定していないことが多いが、それをベースとして最終製品を開発しようとすると様々な問題が発生する。

プロトタイプと最終製品の（ユーザー側での）混同

使い捨て型を想定していたプロトタイプをユーザーが最終製品とみなして、それ以上の改良を不要としてしまうことがある。そうすると開発者は想定していなかったプロトタイプへの全機能実装を強いられる。また、プロトタイプに検討のために含められていた（最終的には削除される予定だった）機能をユーザーが気に入ってしまうこともある。ユーザーが提案された全機能を最終システムに入れることを希望した場合、プロジェクトがマネジメント不能に陥る場合もある。開発者もプロトタイプに愛着を覚えることがあり、アーキテクチャ的裏づけなしにプロトタイプを改良して最終製品にしようとする羽目に陥る。

プロトタイプ開発に時間をかけすぎる

プロトタイプの重要な特徴として時間が掛からずに開発されるという点が挙げられる。開発者がこれを失念すると、複雑すぎるプロトタイプを作ってしまうことがある。そのプロトタイプが使い捨て型であった場合、プロジェクト全体としての生産性は向上しないだろう。ユーザーがプロトタイプの詳細について議論を開始し、その対応に忙殺されて開発チームが最終製品の実装を延期せざるを得なくなることもある。

プロトタイプ実装の費用

プロトタイピング開発のための開発チームを立ち上げる費用はそれなりにかかる。多くの企業は開発方法論を持っており、それを変更するには再訓練/ツール群の再構築などが必要となる。多くの企業は、なるべく費用と時間をかけないでプロトタイピング手法を使おうとする傾向がある。

プロトタイピング導入の共通な問題として、手間をかけずに生産性が劇的に上がるのではないかという過度の期待がある。プロトタイピング技法には訓練が必要であり、そのプロジェクトや組織に固有な構造の開発の必要性が見過ごされることが多い。この構造をないがしろにすると生産性は低下することが多い^[8]。

プロトタイピングは何らかの形であらゆる場合に利用可能であると主張する人もいる。しかし、プロトタイピングはユーザーとのやりとりが多いシステムで特に有効であると言える。

オンラインシステムの分析と設計でのプロトタイピング利用が効果的であることがわかってきた。特に画面での入力を伴うトランザクション処理で顕著である。コンピュータとユーザーのやり取りが多くなると、プロトタイピングの効果が大きくなる^[2]。

バッチ処理のような計算が主体のシステムではユーザーとのやり取りが少なく、プロトタイピングの効果は小さい。システム機能を実現するためのコードが重要であり、プロトタイプで提供できることが非常に少ないのである^[2]。

プロトタイピングは特にユーザインタフェースの設計で威力を発揮する。「ラピッドプロトタイピングの最も生産的な利用法は段階的なユーザー要求定義とユーザインタフェース設計のツールとしての利用である」^[3]。

プロトタイピングの手法がいくつか存在する。多くのアジャイル的手法もプロトタイピング技法に基づいている。

Dynamic Systems Development Method (DSDM)^[9] は主要な技法としてプロトタイピングを使用するビジネスソリューションのためのフレームワークであり、ISO 9001 の認証を受けている。DSDMはプロトタイプの一般的認識をさらに拡張している。DSDMによれば、プロトタイプは、図だったり、ビジネスプロセスだったり、製造中のシステムだったりする。DSDMのプロトタイプは段階的であり、単純な形態から複雑なものへと拡張されていく。

DSDM のプロトタイプは「使い捨て型」も「進化的」なものもある。進化的プロトタイプは水平的に拡張されたり（機能追加）、垂直的に拡張されたりする（詳細化）。最終的に進化的プロトタイプが最終システムになっていく。

DSDMで推奨するプロトタイプは以下の4つに分類される:

• ビジネスプロトタイプ - 自動化すべきビジネスプロセスの設計と実演に使われる。
• ユーザビリティプロトタイプ - ユーザインタフェースのユーザビリティ、アクセシビリティ、ルック・アンド・フィールを定義/改良/実演するのに使われる。
• 性能・容量プロトタイプ - 負荷が最高のときのシステムの状況を定義・予測し実演する。加えて、非機能的側面も評価と実演にも使われる（トランザクション性能、ストレージ容量、反応時間など）。
• 機能/技法プロトタイプ - 設計手法やコンセプトを評価・実演するために使われる。

DSDMでのプロトタイピングの流れは次のようになる:

1. プロトタイプの要求仕様を定める
2. 計画について合意する
3. プロトタイプを作成する
4. プロトタイプをレビューする

Alan Davis が提唱した Operational Prototyping は、従来型のシステム開発に使い捨て型プロトタイピングと進化的プロトタイピングを統合する方法である。「プロトタイピングの利点と従来型開発の利点を利用する方法である。設計者はよく理解している機能だけを段階的に開発していき、機能を正しく理解しているかどうかを実験するために使い捨て型プロトタイピングを用いる」^[4]

Davis の考え方は、従来型開発にプロトタイプを持ち込む場合、「ラピッドプロトタイプを使って品質を高める」のは正しくないということである。彼はシステムの発展の際にその機能を進化的プロトタイピングとラピッドプロトタイピングで実現するというものである。

実際の方法は以下のステップで行われる:^[4]

• 進化的プロトタイプを構築し、従来型開発のベースとする。これにはただしく理解されている要求のみを実装する。
• このベースのコピーを（複数の）ユーザーサイトに送る。各サイトには訓練されたプロトタイプの専門家を派遣する。
• 各サイトでプロトタイプの専門家がシステムのユーザーを観察する。
• ユーザーが問題に直面したり、新たな要求や機能を思いついたら、プロトタイプの専門家がそれを記録する。これによりユーザーが問題を記録する必要がなくなり、本来の業務を続けられる。
• ユーザーの利用が終わると、プロトタイプの専門家はベースのコード上で使い捨て型プロトタイプを作成する。
• ユーザーはその新たなシステムを使って評価する。変更が効果的でない場合、プロトタイプの専門家はそれを削除する。
• ユーザーがその変更を気に入った場合、プロトタイプの専門家は機能改善要求を書いて開発チームに送る。
• 開発チームは各サイトから届いた機能改善要求に基づき、新たな進化的プロトタイプを作成し、従来型開発の新たなベースとする。

これを見て明らかなように、この手法の鍵となるのはよく訓練されたプロトタイプの専門家である。Operational Prototyping はユーザーからの要求が少ない複雑なシステムで有効である。

進化的システム開発（Evolutionary Systems Development）は進化的プロトタイピングの形式的実装を試みる方法論である。例えば John Crinnion が著書 "Evolutionary Systems Development" で描いた Systemscraft などがある。

Systemscraft はプロトタイプの方法論であり、実際の開発環境などに合わせて変更すべきものとされている。

Systemscraft は開発工程の厳密な規格ではない。一般によい方法論は様々な環境や状況に適用可能な柔軟性を備えている…^[2]

Systemscraftの基本は、初期の要求仕様に基づいて実働するシステムを作成し、それをベースとして一連の改版を行っていくものである。Systemscraft は従来型の分析手法を重視して、開発工程全体でそれを活用する。

進化的ラピッド開発（Evolutionary Rapid Development、ERD）^[10] はDARPAの情報技術部門配下にある Software Productivity Consortium が開発した。

ERDの基本概念は、既存のコンポーネントを活用したソフトウェアの組み立てであり、ソフトウェアテンプレートやアーキテクチャ的テンプレートを多用する。ユーザーのニーズや技術の進展に伴うシステム機能の継続的かつ高速な改良が進化的アーキテクチャの特徴であり、ソリューションのクラスを表している。このプロセスでは小規模の職人的チームによるソフトウェア統合を行い、頻繁な顧客とのやりとりを伴った並行する複数の短期開発を特徴とする。

技術・市場・顧客の要求の変化への迅速な対応を可能にする先端技術の導入、機能・インフラストラクチャ・コンポーネントの開発と予備分析を並行して行うことがERDに基づいたプロジェクト成功の鍵である。^[5]

顧客やユーザーの入力を引き出すため、関係者と頻繁に会議を重ねる。設計・実装に関する決定をする前にフィードバックを得るためにシステム機能の実演を行う。頻繁にリリースを行うことで（ベータ版）、ユーザーや顧客のニーズをサポートするためのよりよい手法に関する洞察が得られる。これによりシステムはユーザーのニーズに合わせて進化する。

システムの設計フレームワークは既存の一般的な標準に基づく。システムは性能・容量・機能などの発展の可能性を考慮して構成される。アーキテクチャは、サービスとその実装をカプセル化する抽象インタフェースとして定義される。アーキテクチャは複数の実際のシステム開発をガイドするテンプレートとして働く。複数のアプリケーション・コンポーネントを使ってサービスを実装するためにもアーキテクチャが重要である。変更されにくい中核的機能群も特定され確立される。

ERDプロセスでは、機能の実演を行うことで関係者との対話を図りニーズや期待を引き出す。このための迅速な提供を可能にするためにタイムボックス管理が行われる。タイムボックスとは固定の期間を意味し、ある作業（例えば、ある機能群の開発）をその期間内に必ず完了させなければならない。漠然とした目標群を達成するために期間を必要に応じて延長可能にするのではなく、期間を固定し（週数だったり、人Hのような工数）、その期間内で完了することが現実的と思われる作業を割り当てる。運に任せるような開発状況に陥らないように、長期の計画はタイムボックス単位の反復をガイドするよう定義される。このような計画によってシステム全体の見通しが立ち、プロジェクトの条件が明確化する。

アーキテクチャが確立すると、ソフトウェアの組み立てとテストが毎日行われる。これによりチームは客観的に進捗を評価でき、潜在する問題を迅速に発見することが可能となる。一度に新たに統合される部分はごく小さいので、問題を発見して対処することは迅速に行われる。システムは基本的に常に動作可能であるため、ユーザーへの実演は必要に応じて即座に実施可能である。

プロトタイピングを効果的に行うには、適切なツールとそれに熟達した人員が必要である。プロトタイピング用ツールとしては、第四世代言語 (4GL) を使ったツールやより複雑な統合型CASEツールなどがある。Visual Basicなどの第四世代言語は、その手軽さからよく使われる。CASEツールは軍や大企業などで使われることが多い。オブジェクト指向ツールも開発されている。

よく使われるものとして画面生成プログラムがある。これは機能は組み込まれていないが画面の見た目をユーザーに示すプロトタイプの作成に使われる。インタフェースはユーザーにとってシステムそのものであるため、ユーザインタフェースの開発は重要な部分を占めることがある。

ラピッドプロトタイピングのツールとして Visual Basic も使われる。Visual Basic はプログラミング言語だが、次のような機能があるためプロトタイプ作成に適している:

• 対話的かつ視覚的なユーザインタフェース設計ツール
• ユーザインタフェース部品と実行機能を容易に結合可能
• 学習と利用が容易な言語（BASIC）
• 既存ソフトウェアの修正が容易
• インタプリタが基本であるため、コンパイル時間を待つ必要がなく、迅速な開発に向いている。この特徴は性能を求められる最終製品には不向きだが、プロトタイプでは性能は求められない^[11]

欠点は以下の通り:

• Visual Basic はオブジェクト指向ではなく、UMLのような一般的記法と相性がよくない。
• 従って、プロトタイプを使ってUMLモデルを検証することはできず、最近の開発では使われることが減ってきている。
• ユーザインタフェースと実行機能が密に関連しているため、そこからビジネスロジックを抜き出すのが難しい。
• 従って、プロトタイプを使ってビジネスロジックを文書化できない。
• SQLを使っている場合、それが内部に組み込まれているため、モデルの変更に対応して検証することが困難。
• ルック・アンド・フィールはある程度固定的であるため、自由度が低い。

要求工学環境（Requirements Engineering Environment、REE）は、1985年からローム研究所が開発しており、複雑なシステムの重要な部分のモデルを迅速に実装し動作させるためのツール群を提供する^[12]

要求工学環境は、アメリカ空軍がシステム開発に使用している。

ツール群によって迅速にユーザインタフェースやシステムコンポーネントのプロトタイプが構築できる。モデリングによって複雑なシステムへの理解が深まり、不完全な要求仕様がシステム開発工程の期間や費用に与える影響を明らかにする。モデル構築は容易であり、必要に応じて様々な抽象度や粒度で構築できる。^[12]

要求工学環境は3つの部分からなる。第1は Proto と呼ばれるラピッドプロトタイピングのためのCASEツールである。第2は Rapid Interface Prototyping System（RIP）と呼ばれ、ユーザインタフェース構築のためのツール群である。3番目は Proto と RIP にアクセスするためのグラフィカルなユーザインタフェースである。

ローム研究所は、内部の要求分析手法のために要求工学環境を開発した。手法は3つの部分からなる:

（第1に）各種情報源からの情報収集、仕様記述、一貫性のチェック、（第2に）様々なユーザーのニーズを分析し、矛盾せず、技術的にも経済的にも実現可能なものを選別し、（第3に）そのようにして選別された要求仕様がユーザーのニーズを正しく反映しているかを検証する。^[12]

1996年、ローム研究所は REE の商用化を目指して Software Productivity Solutions (SPS) と契約した^[13]。この商用版REEを Advanced Requirements Engineering Workstation（AREW）と名づけている。

LYMB^[14] はオブジェクト指向開発環境であり、GUI、可視化、ラピッドプロトタイピングなどを必要とするアプリケーション開発に適している。

1. ^ Todd Grimm: The Human Condition: A Justification for Rapid Prototyping. Time Compression Technologies, vol. 3 no. 3. Accelerated Technologies, Inc. May 1998 . Page 1. [1]
2. ^ ^{a b c d e f g} John Crinnion: Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. Plenum Press, New York, 1991. Page 17.
3. ^ ^{a b c} S. P. Overmyer: Revolutionary vs. Evolutionary Rapid Prototyping: Balancing Software Productivity and HCI Design Concerns. Center of Excellence in Command, Control, Communications and Intelligence (C3I), George Mason University, 4400 University Drive, Fairfax, Virginia.
4. ^ ^{a b c} Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.
5. ^ ^{a b} Software Productivity Consortium: Evolutionary Rapid Development. SPC document SPC-97057-CMC, version 01.00.04, June 1997. Herndon, Va. Page 6.
6. ^ Davis. Page 72-73. Citing: E. Bersoff and A. Davis, Impacts of Life Cycle Models of Software Configuration Management. Comm. ACM, Aug. 1991, pp. 104-118
7. ^ ^{a b} C. Melissa Mcclendon, Larry Regot, Gerri Akers: The Analysis and Prototyping of Effective Graphical User Interfaces. October 1996. “アーカイブされたコピー”. 2000年5月3日時点のオリジナルよりアーカイブ。2004年10月22日閲覧。
8. ^ Joseph E. Urban: Software Prototyping and Requirements Engineering. Rome Laboratory, Rome, NY.
9. ^ Dynamic Systems Development Method Consortium. http://na.dsdm.org Archived 2006年2月9日, at the Wayback Machine.
10. ^ Software Productivity Consortium: Evolutionary Rapid Development. SPC document SPC-97057-CMC, version 01.00.04, June 1997. Herndon, Va. PPS 10-13.
11. ^ Paul W. Parry. Rapid Software Prototyping. Sheffield Hallam University, Sheffield, UK. [2]
12. ^ ^{a b c} Dr. Ramon Acosta, Carla Burns, William Rzepka, and James Sidoran. Applying Rapid Prototyping Techniques in the Requirements Engineering Environment. IEEE, 1994. “アーカイブされたコピー”. 1999年4月21日時点のオリジナルよりアーカイブ。2004年10月22日閲覧。
13. ^ Software Productivity Solutions, Incorporated. Advanced Requirements Engineering Workstation (AREW). 1996. “アーカイブされたコピー”. 2007年9月27日時点のオリジナルよりアーカイブ。2004年10月22日閲覧。
14. ^ from GE Research and Development. http://www.crd.ge.com/esl/cgsp/fact_sheet/objorien/index.html

• D.A. Stacy, professor, University of Guelph. Guelph, Ontario. Lecture notes on Rapid Prototyping. August, 1997. [3]
• Stephen J. Andriole: Information System Design Principles for the 90s: Getting it Right. AFCEA International Press, Fairfax, Virginia. 1990. Page 13.
• R. Charette, Software Engineering Risk Analysis and Management. McGraw Hill, New York, 1989.

• A good list of commonly used prototyping tools
• A new discussion of the latest in Simulation tools