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

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

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

1 概要

2 プロトタイピングの分類

2.1 使い捨て型プロトタイピング

2.2 進化的プロトタイピング


3 プロトタイピングの利点

4 プロトタイピングの問題点

5 プロトタイピングに適したプロジェクト

6 手法

6.1 Dynamic Systems Development Method（DSDM）

6.2 Operational Prototyping

6.3 進化的システム開発

6.4 進化的ラピッド開発


7 ツール

7.1 画面生成/設計ツール

7.2 Visual Basic

7.3 要求工学環境

7.4 LYMB


8 脚注

9 参考文献

10 外部リンク

概要

プロトタイピングは以下のようなステップで行われる:
要求分析を行う基本要求を見定め、必要とされる情報の入出力を確定する。なお、セキュリティなどの詳細はここでは無視する。

最初のプロトタイプを開発するユーザインタフェースだけで構成されるプロトタイプを開発する。

レビューエンドユーザーを含む顧客にプロトタイプを実際に使ってもらい、追加点や修正点などのフィードバックをもらう。

プロトタイプの改良フィードバックを反映して、要求仕様とプロトタイプの両方を改良する。ここでは、契約範囲/製品内容に関する調整が必須となる。変更が加えられたら、3番と4番を繰り返す。

プロトタイピングの分類

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

使い捨て型/ラピッド（高速）プロトタイピングでは、作成したモデルは、最終的なソフトウェアの一部となるよりも、捨てられる可能性が高い。初期の要求仕様分析が完了すると、システムの単純な動作モデルが作られ、要求仕様を可視化してみせ、最終的にシステムがどのように見えるかをユーザーに見せる。ラピッドプロトタイピングでは、比較的短期間の調査期間の後、かなり早い段階でシステムの様々な部分の動作モデルを製作する。その製作手法はあまり形式に拘らず、なによりも製作期間が短いことが重要である。そのモデルをユーザーが評価し、要求をさらに明確化させる。これが出来たらプロトタイプは捨てられ、要求仕様に従って正式な開発が開始される[2]。

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

使い捨て型プロトタイピングの別の利点として、ユーザーがテストできるインタフェースを提供できるという点が挙げられる。ユーザインタフェースはシステムの中でもユーザーの目に触れる部分であり、それを目にすることでそのシステムがどういうものかを把握しやすくなる。…進化的ラピッドプロトタイピングがユーザーの要求に関連する問題のより効果的な解決策になるとされており、ソフトウェア開発の全体の効率も劇的に改善する。発展性/保守性/ソフトウェア構造などを度外視すれば、要求を見定め、シミュレートし、テストすることはたやすい。これにより要求が明確化され、ユーザー視点のシステムの構築のモデルとなる[3]。

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

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

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

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

進化的プロトタイピングを使った開発では、システムは継続的に改良され再構築される。「…進化的プロトタイピングでは、要求仕様を完全に把握する必要はなく、よくわかっている部分だけについて開発を行う」[4] この手法では開発チームは機能を追加したり要求分析時点では想定されていなかった変更を加えたりできる。システムを有効なものにするには、それを実環境で使ってみる必要がある。製品は決して完成することはなく、実環境の変化に伴って常に調整される…システムは現在の環境に従って定義される。その時どきのビジネス手法や技術が前提となる。何らかの機能を開発する計画が立てられ、想定していたものと似たものが提供される。[5]

進化的プロトタイピングは、それが実際に機能するシステムであるという点で使い捨て型プロトタイピングよりも優れている。しかし、それにはユーザーが計画した機能が全て実装されているわけではなく、最終的なシステムが提供されるまでの暫定システムとなるだろう。「プロトタイピング環境では、最初のプロトタイプをユーザーが実業務に使うことは珍しくない…ユーザーは欠陥のあるシステムでも何もないよりましと判断するのだろう」[2]

進化的プロトタイピングでは、開発者はシステム全体を一気に開発するのではなく、理解している部分から先に開発することに注力できる。リスクを最小にするため、開発者は理解が不足している機能は実装しない。部分的に実装されたシステムが顧客側に渡される。ユーザーはそのシステムをしばらく使い、その間に新たな要求が見つかり、それが開発者に伝えられる。開発者はその改善点を要求仕様に加え、設計を更新し、再コーディングと再テストを行う。