ソフトウェアのプロトタイピング

ソフトウェアプロトタイピングは、ソフトウェアアプリケーションのプロトタイプ、つまり開発中のソフトウェアプログラムの不完全なバージョンを作成する活動です。これはソフトウェア開発で発生する可能性のある活動であり、機械工学や製造などの他の分野で知られているプロトタイピングに匹敵します。^[1]

プロトタイプは通常、最終製品のいくつかの側面のみをシミュレートするもので、最終製品とはまったく異なる場合があります。

プロトタイピングにはいくつかの利点があります。ソフトウェア設計者と実装者は、プロジェクトの早い段階でユーザーから貴重なフィードバックを得ることができます。クライアントと請負業者は、ソフトウェアがソフトウェア プログラムの構築に使用されたソフトウェア仕様と一致しているかどうかを比較できます。また、ソフトウェア エンジニアは、プロジェクトの初期見積もりの​​精度や、提案された期限とマイルストーンをうまく達成できるかどうかについて、ある程度の洞察を得ることができます。プロトタイピングの完全性の程度と使用される手法は、1970 年代初頭に提案されて以来、開発と議論が続いています。^[2]

プロトタイプの目的は、ソフトウェアのユーザーが、説明に基づいて設計を解釈および評価するのではなく、実際に試すことによって、最終的な製品の設計に関する開発者の提案を評価できるようにすることです。ソフトウェアのプロトタイピングにより、ソフトウェアの機能と潜在的な脅威や問題を理解することができます。^[3]プロトタイピングは、エンドユーザーが考慮されていなかった要件を説明および証明するためにも使用できます。これは、開発者とクライアント間の商業関係の重要な要素となる可能性があります。^[4]特に インタラクションデザインでは、その目的でプロトタイピングを多用します。

このプロセスは、最初にプログラム全体を構築し、次に設計と実装の間の矛盾を解決するという 1960 年代と 1970 年代のモノリシック開発サイクルとは対照的です。モノリシック開発サイクルは、ソフトウェア コストの上昇と時間とコストの見積もりの​​不正確さにつながりました。^[要出典]モノリシック アプローチは、ソフトウェア デザイナーと開発者が 1 人のヒーローであり、ドラゴン全体を 1 人で倒す必要があると想定しているため、「(ソフトウェア) ドラゴンを倒す」手法と呼ばれています。プロトタイピングにより、完成したソフトウェア製品を変更しなければならないという多大な費用と困難も回避できます。

プロトタイピングの実践は、フレデリック・P・ブルックスが1975 年の著書『人月の神話』と 10 周年記念記事「銀の弾丸はない」で指摘している点の 1 つです。

大規模ソフトウェアプロトタイピングの初期の例としては、Adaプログラミング言語用のNYUのAda/EDトランスレータの実装が挙げられます。^{[5]これは、Ada言語の実行可能なセマンティックモデルを作成する目的で}SETLで実装され、速度と効率よりも設計とユーザーインターフェイスの明瞭性を重視しました。NYU Ada/EDシステムは、1983年4月11日に認定された最初の検証済みAda実装でした。^[6]

プロトタイピングのプロセスには次の手順が含まれます。^{[引用が必要]}

1. 基本的な要件を特定する

   必要な入力情報と出力情報を含む基本要件を決定します。セキュリティなどの詳細は、通常無視できます。

2. 初期プロトタイプの開発

   ユーザー インターフェイスのみを含む初期プロトタイプが開発されました。(下記の水平プロトタイプを参照)

3. レビュー

   エンドユーザーを含む顧客はプロトタイプを検査し、潜在的な追加や変更に関するフィードバックを提供します。

4. プロトタイプを修正し強化する

   フィードバックを使用して、仕様とプロトタイプの両方を改善できます。契約/製品の範囲内にあるものについての交渉が必要になる場合があります。変更が導入された場合は、手順 3 と 4 を繰り返す必要がある場合があります。

ニールセンは著書『ユーザビリティエンジニアリング』の中で、プロトタイプのさまざまな側面を次のようにまとめています。

ユーザー インターフェイス プロトタイプの一般的な用語は、水平プロトタイプです。これは、データベース アクセスなどの低レベルのシステム機能よりもユーザー インタラクションに重点を置き、システムまたはサブシステム全体の広い視野を提供します。水平プロトタイプは、次の場合に役立ちます。

• ユーザーインターフェース要件とシステム範囲の確認、
• 企業からの賛同を得るためのシステムのデモ版
• 開発時間、コスト、労力の予備見積りを作成します。

垂直プロトタイプは、単一のサブシステムまたは機能の強化された完全な詳細化です。特定の機能の詳細な要件を取得するのに役立ち、次のような利点があります。

• 改良データベース設計、
• ネットワークのサイズ設定やパフォーマンスエンジニアリングのために、データ量やシステムインターフェースのニーズに関する情報を取得します。
• 実際のシステム機能にドリルダウンして複雑な要件を明確にします。

ソフトウェアのプロトタイピングにはさまざまなバリエーションがあります。ただし、すべての方法は、使い捨てプロトタイピングと進化型プロトタイピングという 2 つの主要なプロトタイピング形式に何らかの形で基づいています。

クローズドエンド プロトタイピングとも呼ばれます。使い捨てまたはラピッド プロトタイピングとは、最終的に提供されるソフトウェアの一部になるのではなく、最終的に破棄されるモデルの作成を指します。予備的な要件収集が完了したら、システムのシンプルな動作モデルを構築して、完成したシステムに実装されたときに要件がどのようになるかをユーザーに視覚的に示します。これもラピッド プロトタイピングの一形態です。

ラピッドプロトタイピングでは、比較的短い調査の後、非常に早い段階でシステムのさまざまな部分の実用的なモデルを作成します。これを構築するために使用される方法は通常非常に非公式であり、最も重要な要素はモデルが提供される速度です。その後、モデルは、ユーザーが期待を再検討し、要件を明確にするための出発点になります。この目標が達成されると、プロトタイプモデルは「破棄」され、特定された要件に基づいてシステムが正式に開発されます。^[7]

使い捨てプロトタイプを使用する最も明白な理由は、それが迅速に実行できることです。ユーザーが要件に関するフィードバックを迅速に得ることができれば、ソフトウェア開発の早い段階で要件を改良できる可能性があります。開発ライフサイクルの早い段階で変更を加えると、やり直す必要がないため、コスト効率が非常に高くなります。かなりの作業を行った後にプロジェクトが変更された場合、ソフトウェア システムには多くの依存関係があるため、小さな変更でも実装に多大な労力が必要になる可能性があります。使い捨てプロトタイプの実装では、時間と予算が限られているため、破棄されるプロトタイプに費やすことができる費用はわずかであるため、スピードが重要です。

使い捨てプロトタイピングのもう 1 つの強みは、ユーザーがテストできるインターフェースを構築できることです。ユーザー インターフェースは、ユーザーがシステムとして見るものであり、目の前で見ることで、システムがどのように機能するかを把握することがはるかに簡単になります。

…革命的なラピッドプロトタイピングは、ユーザー要件関連の問題に対処するためのより効果的な方法であり、したがってソフトウェアの生産性全体をより向上させると主張されています。進化性、保守性、ソフトウェア構造の問題を無視すると、要件の特定、シミュレーション、テストがはるかに迅速かつ安価に行えます。これにより、要件の正確な仕様が実現し、従来のソフトウェア開発モデルを介して、ユーザーの観点から有効で使いやすいシステムを構築できます。^[8]

プロトタイプは、外観、インタラクション、タイミングの点で実際の製品に似ている度合いに応じて分類できます。低忠実度の使い捨てプロトタイプを作成する方法の 1 つは、ペーパー プロトタイピングです。プロトタイプは紙と鉛筆を使用して実装されるため、実際の製品の機能を模倣しますが、見た目はまったく異なります。高忠実度の使い捨てプロトタイプを簡単に作成する別の方法は、GUI ビルダーを使用してクリック ダミーを作成することです。クリック ダミーは、目標システムに似ているが、機能を提供しないプロトタイプです。

ストーリーボード、アニマティック、または図面の使用は、使い捨てのプロトタイピングとまったく同じではありませんが、確かに同じファミリー内にあります。これらは非機能的な実装ですが、システムがどのように見えるかを示します。

概要: このアプローチでは、プロトタイプは破棄され、最終的なシステムはゼロから構築されるという考えのもとに構築されます。このアプローチの手順は次のとおりです。

1. 予備要件を記述する
2. プロトタイプを設計する
3. ユーザーがプロトタイプを体験/使用し、新しい要件を指定する
4. 必要に応じて繰り返します
5. 最終的な要件を記述する

進化型プロトタイピング (ブレッドボードプロトタイピングとも呼ばれます) は、使い捨てプロトタイピングとはまったく異なります。進化型プロトタイピングを使用する際の主な目標は、構造化された方法で非常に堅牢なプロトタイプを構築し、それを継続的に改良することです。このアプローチの理由は、構築された進化型プロトタイプが新しいシステムの中核を形成し、その後、改善とさらなる要件が構築されるためです。

進化的プロトタイピングを使用してシステムを開発する場合、システムは継続的に改良され、再構築されます。

「…進化的プロトタイピングは、すべての要件を理解しているわけではないことを認め、十分に理解されている要件のみを構築します。」^[9]

この手法により、開発チームは要件および設計フェーズでは考えられなかった機能を追加したり、変更を加えたりできるようになります。

システムが有用であるためには、意図された運用環境での使用を通じて進化する必要があります。製品は決して「完成」することはありません。使用環境が変化するにつれて、常に成熟していきます。私たちはしばしば、最も馴染みのある基準枠、つまり現在の状況を使用してシステムを定義しようとします。私たちは、ビジネスがどのように行われるか、ビジネスが実装される技術基盤について仮定を立てます。機能を開発するための計画が実行され、遅かれ早かれ、想定されたシステムに似たものが提供されます。^[10]

進化型プロトタイプは、使い捨てプロトタイプに比べて、機能的なシステムであるという利点があります。ユーザーが計画したすべての機能を備えているわけではありませんが、最終的なシステムが提供されるまで暫定的に使用できます。

「プロトタイピング環境において、ユーザーがより開発されたバージョンを待つ間に最初のプロトタイプを実際に使用することは珍しいことではありません…ユーザーは、「欠陥のある」システムでも、システムがまったくないよりはましだと判断するかもしれません。」^[7]

進化型プロトタイピングでは、開発者はシステム全体の開発に取り組むのではなく、自分が理解しているシステムの部分の開発に集中できます。

リスクを最小限に抑えるため、開発者は十分に理解されていない機能を実装しません。部分的なシステムは顧客のサイトに送られます。ユーザーがシステムを操作すると、新機能の機会が見つかり、開発者にこれらの機能の要求が伝えられます。開発者は、これらの機能強化要求を自分の要求と合わせて、適切な構成管理手法を使用してソフトウェア要件仕様を変更し、設計を更新し、再コーディングして再テストします。^[11]

最終製品は個別のプロトタイプとして構築されます。最後に、個別のプロトタイプが全体のデザインに統合されます。増分プロトタイピングの助けにより、ユーザーとソフトウェア開発者の間の時間差が短縮されます。

開発プロセスとしてのエクストリーム プロトタイピングは、特に Web アプリケーションの開発に使用されます。基本的に、Web 開発を 3 つのフェーズに分割し、各フェーズは前のフェーズに基づいています。最初のフェーズは、主に HTML ページで構成される静的プロトタイプです。2 番目のフェーズでは、シミュレートされたサービス レイヤーを使用して画面がプログラムされ、完全に機能します。3 番目のフェーズでは、サービスが実装されます。

「このプロセスは、契約以外のサービスにほとんど配慮せずに完全に機能するUIが開発されるプロセスの第2段階に注目を集めるためにエクストリームプロトタイピングと呼ばれています。」^[12]

ソフトウェア開発においてプロトタイピングを使用することには多くの利点があり、その中には具体的なものもあれば抽象的なものもあります。^[13]

時間とコストの削減：プロトタイピングは、開発者に提供される要件と仕様の品質を向上させることができます。変更は開発の後半で検出されるため、実装コストが指数関数的に増加するため、ユーザーが本当に望んでいるものを早期に判断することで、ソフトウェアの開発速度が速くなり、コストも削減されます。^[8]

ユーザーの関与の向上と増加: プロトタイピングにはユーザーの関与が必要であり、ユーザーはプロトタイプを見て操作できるため、より適切で完全なフィードバックと仕様を提供できます。^[7]ユーザーがプロトタイプを検査することで、お互いが自分の言ったことを理解していると信じている場合に発生する多くの誤解や誤ったコミュニケーションを防ぐことができます。ユーザーは開発チームの誰よりも問題領域をよく知っているため、相互作用が増加すると、有形および無形の質が向上した最終製品が生まれます。最終製品は、ユーザーの外観、感触、パフォーマンスに対する要望を満たす可能性が高くなります。

成功率の向上: ソフトウェアのプロトタイピングは、製品リリースの成功率を大幅に向上させます。すでに述べたように、プロトタイピング プロセスにより、実際のユーザー フィードバックを早期かつ頻繁に収集できます。この初期段階で継続的にフィードバックを受け取ることで、ソフトウェア開発者は最も重要な要素を優先し、必要な変更を実装し、使いやすさ、パフォーマンス、UX の問題などに対処できます。

プロトタイピングを使用すると、あるいは誤用すると、欠点が生じることもあります。

不十分な分析: 限定されたプロトタイプに焦点を合わせると、開発者がプロ​​ジェクト全体を適切に分析できなくなる可能性があります。これにより、より優れたソリューションを見落としたり、不完全な仕様を準備したり、限定されたプロトタイプを保守が困難なエンジニアリングの不十分な最終プロジェクトに変換したりする可能性があります。さらに、プロトタイプは機能が制限されているため、プロトタイプを最終成果物のベースとして使用すると、うまく拡張できない可能性があります。開発者がモデルとしてのプロトタイプの構築に集中しすぎると、これに気付かない可能性があります。

プロトタイプと完成したシステムに関するユーザーの混乱: ユーザーは、廃棄される予定のプロトタイプを、実際には仕上げや磨きをかけるだけでよい最終システムだと考え始めることがあります。(たとえば、プロトタイプにはないエラー チェック機能やセキュリティ機能を追加するために必要な作業に気付いていないことがよくあります。) これにより、開発者の意図に反して、プロトタイプが最終システムのパフォーマンスを正確にモデル化することを期待するようになります。また、検討のためにプロトタイプに含まれていたが、最終システムの仕様から削除された機能にユーザーが執着することもあります。ユーザーが、提案されたすべての機能を最終システムに含めることを要求できる場合、これは衝突につながる可能性があります。

開発者によるユーザー目標の誤解: 開発者は、より広範な商業的問題を理解しないまま、ユーザーも目標 (コア機能を時間どおりに予算内で提供するなど) を共有していると想定する場合があります。たとえば、エンタープライズ ソフトウェア( PeopleSoftなど) のイベントに参加したユーザー代表は、「トランザクション監査」(変更がログに記録され、差分グリッド ビューに表示される) のデモを見たことがありますが、この機能には追加のコーディングが必要であり、多くの場合、追加のデータベース アクセスを処理するためにより多くのハードウェアが必要になることは知らされていませんでした。ユーザーはすべてのフィールドで監査を要求できると信じているかもしれませんが、開発者はユーザー要件の範囲について想定しているため、これは機能の過剰であると考える可能性があります。開発者がユーザー要件のレビュー前に配信をコミットした場合、特にユーザー管理が要件の実装の失敗から何らかの利益を得ている場合は、開発者は困難な状況に陥ります。

開発者のプロトタイプへの執着:開発者は、作成に多大な労力を費やしたプロトタイプに執着することもあります。これにより、適切な基盤アーキテクチャがないのに、限定的なプロトタイプを最終システムに変換しようとするなど、問題が発生する可能性があります。(これは、進化的プロトタイピングではなく、使い捨てプロトタイピングを使用する必要があることを示唆している可能性があります。)

プロトタイプの開発時間が長すぎる: プロトタイプ作成の重要な特性は、迅速に行う必要があることです。開発者がこの事実を忘れると、複雑すぎるプロトタイプを開発しようとする可能性が高くなります。プロトタイプが破棄されると、プロトタイプが提供する正確に開発された要件では、プロトタイプの開発に費やした時間を補うほどの生産性の向上が得られない可能性があります。ユーザーはプロトタイプの詳細に関する議論で行き詰まり、開発チームの足止めとなり、最終製品の遅れにつながる可能性があります。

プロトタイピングの実装にかかる費用: プロトタイピングに重点を置いた開発チームを構築するための初期費用は高額になる可能性があります。多くの企業では開発方法論が確立されており、それを変更するには再トレーニング、再ツール化、またはその両方が必要になります。多くの企業は、従業員の再トレーニングを十分に行わずに、プロトタイピングを開始する傾向があります。

プロトタイピング技術を採用する際によくある問題は、生産性に対する期待が高すぎる一方で、学習曲線の背後にある努力が不十分であることです。プロトタイピング技術の使用に関するトレーニングに加えて、技術をサポートする企業やプロジェクト固有の基盤構造を開発する必要性は見落とされがちです。この基盤構造が省略されると、生産性が低下することがよくあります。^[14]

何らかの形でプロトタイピングを常に使用すべきだと主張されてきました。しかし、プロトタイピングは、ユーザーと多くのやり取りを行うシステムで最も効果的です。

プロトタイピングはオンラインシステムの分析と設計に非常に効果的であることがわかっています。特に、画面ダイアログの使用がより顕著なトランザクション処理では効果的です。コンピュータとユーザー間のインタラクションが多ければ多いほど、迅速なシステムを構築してユーザーに操作させることで得られるメリットは大きくなります。^[7]

バッチ処理や主に計算を行うシステムなど、ユーザーとのやり取りがほとんどないシステムでは、プロトタイピングによるメリットはほとんどありません。システム機能を実行するために必要なコーディングが集中的すぎる場合があり、プロトタイピングによって得られる潜在的なメリットが小さすぎることがあります。^[7]

プロトタイピングは、優れた人間とコンピュータのインターフェースを設計するのに特に適しています。「これまでのラピッドプロトタイピングの最も生産的な使用法の1つは、反復的なユーザー要件エンジニアリングと人間とコンピュータのインターフェース設計のツールとして使用されたことです。」^[8]

動的システム開発手法（DSDM）^[15]は、プロトタイピングを中核技術として大きく活用したビジネスソリューションを提供するためのフレームワークであり、それ自体がISO 9001の承認を受けています。これは、プロトタイプの最も一般的な定義を拡張したものです。DSDMによれば、プロトタイプは図、ビジネスプロセス、または生産に投入されたシステムである場合もあります。DSDMプロトタイプは、単純な形式からより包括的な形式へと進化する増分型となるように設計されています。

DSDM プロトタイプは、使い捨ての場合もあれば、進化型の場合もあります。進化型プロトタイプは、水平方向 (幅、深さの順) または垂直方向 (各セクションを詳細に構築し、その後のセクションを詳細化する追加の反復) に進化させることができます。進化型プロトタイプは、最終的に最終システムに進化させることができます。

DSDM が推奨するプロトタイプの 4 つのカテゴリは次のとおりです。

• ビジネス プロトタイプ- 自動化されるビジネス プロセスを設計および実証するために使用されます。
• ユーザビリティ プロトタイプ- ユーザー インターフェイス デザインのユーザビリティ、アクセシビリティ、外観と操作性を定義、改良、実証するために使用されます。
• パフォーマンスと容量のプロトタイプ- システムがピーク負荷時にどのように動作するかを定義、実証、予測するとともに、システムのその他の非機能的側面 (トランザクション レート、データ ストレージ量、応答時間など) を実証および評価するために使用されます。
• 機能/技術プロトタイプ- 設計アプローチまたはコンセプトの開発、実証、評価に使用されます。

プロトタイプの DSDM ライフサイクルは次のとおり です。

1. プロトタイプを特定する
2. 計画に同意する
3. プロトタイプを作成する
4. プロトタイプを確認する

運用プロトタイピングは、使い捨てプロトタイピングと進化的プロトタイピングを従来のシステム開発に統合する方法として、アラン・デイビスによって提案されました。「これは、手っ取り早い開発と従来の開発の両方の長所を賢明な方法で提供します。設計者は、進化的ベースラインを構築する際にはよく理解されている機能のみを開発し、よく理解されていない機能については使い捨てプロトタイピングを使用して実験します。」^[9]

デイビス氏は、2 つのアプローチを組み合わせる際に「ラピッド プロトタイプに品質を後付けする」ことは正しい方法ではないと考えています。同氏のアイデアは、進化型プロトタイピング手法を採用し、進化のたびにシステムの機能をラピッド プロトタイプ化するというものです。

具体的な方法論は以下の手順に従う：^[9]

• 進化型プロトタイプは、従来の開発戦略を使用して構築され、ベースラインとなり、十分に理解されている要件のみを指定して実装されます。
• ベースラインのコピーは、訓練を受けたプロトタイパーとともに複数の顧客サイトに送信されます。
• 各サイトで、プロトタイパーはシステムのユーザーを監視します。
• ユーザーが問題に遭遇したり、新しい機能や要件を思いついたりしたときは、プロトタイパーがそれをログに記録します。これにより、ユーザーは問題を記録する必要がなくなり、作業を続行できます。
• ユーザー セッションが終了した後、プロトタイパーはベースライン システムの上に使い捨てのプロトタイプを構築します。
• ユーザーは新しいシステムを使用して評価します。新しい変更が効果的でない場合は、プロトタイパーがそれを削除します。
• ユーザーが変更を気に入った場合、プロトタイパーは機能拡張リクエストを作成し、開発チームに転送します。
• 開発チームは、すべてのサイトからの変更要求を把握し、従来の方法を使用して新しい進化型プロトタイプを作成します。

言うまでもなく、この方法の鍵となるのは、十分に訓練されたプロトタイパーをユーザー サイトに出向かせることです。運用プロトタイピング手法は、複雑で事前に要件がほとんどわかっていないシステムでは多くの利点があります。

進化的システム開発は、進化的プロトタイピングを正式に実装しようとする方法論のクラスです。Systemscraft と呼ばれる特定のタイプは、John Crinnion の著書「進化的システム開発」で説明されています。

Systemscraft は、実装された特定の環境に合わせて変更および適応する必要がある「プロトタイプ」方法論として設計されました。

Systemscraft は、開発プロセスに対する厳格な「クックブック」アプローチとして設計されたわけではありません。現在では、優れた方法論は、あらゆる環境や状況に合わせて調整できるほど柔軟であるべきであることが一般的に認識されています... ^[7]

Systemscraft の基本は、進化的プロトタイピングと似ており、初期要件から実用的なシステムを作成し、一連の修正でそれを基に構築することです。Systemscraft では、システムの開発全体を通じて従来の分析が重視されます。

進化的迅速開発（ERD）^[16]は、国防高等研究計画局（DARPA）の情報技術局の技術開発および統合エージェントであるソフトウェア生産性コンソーシアムによって開発されました。

ERD の基本となるのは、コンポーネントの再利用、ソフトウェア テンプレートの使用、およびアーキテクチャ テンプレートに基づいてソフトウェア システムを構成するという概念です。ユーザーのニーズとテクノロジーの変化に迅速に対応してシステム機能を継続的に進化させることは、ソリューションのクラスを表す進化型アーキテクチャによって強調されます。このプロセスでは、ソフトウェアとシステム エンジニアリングの分野を統合した小規模な職人ベースのチームの使用に重点が置かれ、複数の、多くの場合は並行した短期間のタイムボックスで顧客と頻繁にやり取りします。

ERDベースのプロジェクトを成功させる鍵は、機能、インフラストラクチャ、コンポーネントの並行した探索的分析と開発、そして最先端技術の採用であり、技術、市場、顧客の要件の変化に迅速に対応できるようにすることです。^[10]

顧客/ユーザーの意見を引き出すために、関係者との定期的な会議や臨時/即席の会議が頻繁に開催されます。設計/実装の決定が固まる前に、フィードバックを求めるためにシステム機能のデモンストレーションが行われます。システムがユーザーと顧客のニーズをより良くサポートする方法についての洞察を提供するために、頻繁にリリース (ベータ版など) が提供されます。これにより、システムが既存のユーザーのニーズを満たすように進化することが保証されます。

システムの設計フレームワークは、既存の公開済み標準または事実上の標準の使用に基づいています。システムは、パフォーマンス、容量、および機能性を考慮した一連の機能を進化させることができるように構成されています。アーキテクチャは、サービスとその実装 (COTS アプリケーションなど) をカプセル化する抽象インターフェイスの観点から定義されます。アーキテクチャは、システムの複数のインスタンスの開発をガイドするために使用されるテンプレートとして機能します。これにより、複数のアプリケーション コンポーネントを使用してサービスを実装できます。変更される可能性が低いコア機能セットも特定され、確立されます。

ERD プロセスは、ステークホルダーがニーズや期待を伝える手段として、紙の成果物ではなく実証された機能を使用するように構成されています。この迅速な提供という目標の中心にあるのは、「タイムボックス」方式の使用です。タイムボックスとは、特定のタスク (機能セットの開発など) を実行する必要がある固定期間です。漠然とした目標セットを満たすために時間を拡大するのではなく、時間を固定し (暦週と人時の両方で)、これらの制約内で現実的に達成できる目標セットを定義します。開発が「ランダム ウォーク」に陥らないように、反復をガイドする長期計画を定義します。これらの計画は、システム全体のビジョンを提供し、プロジェクトの境界 (制約など) を設定します。プロセス内の各反復は、これらの長期計画のコンテキストで実行されます。

アーキテクチャが確立されると、ソフトウェアは毎日統合され、テストされます。これにより、チームは進捗状況を客観的に評価し、潜在的な問題を迅速に特定できます。一度に統合されるシステムの量は少ないため、欠陥の診断と除去は迅速です。システムは通常、いつでも実行できる状態にあるため、ユーザー デモンストレーションをすぐに開催できます。

プロトタイピングを効率的に使用するには、組織が適切なツールと、それらのツールを使用するためのトレーニングを受けたスタッフを備えている必要があります。プロトタイピングで使用されるツールは、ラピッドプロトタイピングに使用される第 4 世代プログラミング言語などの個別のツールから、複雑な統合CASEツールまで多岐にわたります。Visual BasicやColdFusionなどの第 4 世代ビジュアルプログラミング言語は、安価でよく知られており、比較的簡単で高速に使用できるため、頻繁に使用されます。要件分析をサポートする CASE ツール (要件エンジニアリング環境 (下記参照) など) は、軍隊や大規模な組織によって開発または選択されることがよくあります。GE 研究開発センターの LYMB などのオブジェクト指向ツールも開発されています。ユーザーは、スプレッドシートでアプリケーションの要素を自分でプロトタイプ化できます。

Web ベースのアプリケーションの人気が高まるにつれて、そのようなアプリケーションのプロトタイプを作成するためのツールも増えています。Bootstrap、Foundation、AngularJS などのフレームワークは、概念実証を迅速に構築するために必要なツールを提供します。これらのフレームワークは通常、開発者が Web アプリケーションのプロトタイプを迅速に作成できるようにする一連のコントロール、インタラクション、および設計ガイドラインで構成されています。

画面生成プログラムもよく使用され、プロトタイプ作成者は、機能しないユーザーのシステムを表示しながら、画面がどのように見えるかを示すことができます。ユーザーにとってインターフェースは本質的にシステムであるため、ヒューマン コンピューター インターフェースの開発は、開発作業の重要な部分になる場合があります。

ソフトウェア ファクトリーは、すぐに使用できるモジュール コンポーネントを組み合わせてコードを生成できます。このアプローチでは、最小限の手動コーディングで、目的の動作を備えたプログラムを迅速に提供できるため、アプリケーションのプロトタイプ作成に最適です。

アプリケーション定義またはシミュレーション ソフトウェアと呼ばれる新しいクラスのソフトウェアを使用 すると、コードを記述せずに、別のコンピュータ プログラムの軽量でアニメーション化されたシミュレーションを迅速に構築 できます。アプリケーション シミュレーション ソフトウェアを使用すると、技術者と非技術者の両方がシミュレートされたプログラムを体験、テスト、共同作業、検証でき、注釈、スクリーンショット、回路図などのレポートが提供されます。ソリューション仕様作成手法として、アプリケーション シミュレーションは、リスクは低いが制限のある、紙ベースのプロトタイピングと呼ばれることもあるテキストまたは図面ベースのモックアップ(またはワイヤーフレーム) と、時間がかかりリスクの高いコードベースのプロトタイプの中間に位置し、ソフトウェアの専門家が開発が始まる前に早い段階で要件と設計の選択を検証できるようにします。そうすることで、ソフトウェア実装に関連するリスクとコストを大幅に削減できます。^[17]

アプリケーションをシミュレートするには、スクリーンキャスト ソフトウェアなど、コンピューター ベースのトレーニング、デモンストレーション、顧客サポート用の実際のソフトウェア プログラムをシミュレートするソフトウェアを使用することもできます。これらの領域は密接に関連しています。

「1985年からローマ研究所で開発が進められている要件エンジニアリング環境（REE）は、複雑なシステムの重要な側面のモデルを迅速に表現、構築、実行するための統合ツールセットを提供します。」^[18]

要件エンジニアリング環境は現在、米国空軍によってシステム開発に使用されています。

システムアナリストがシステムコンポーネントの機能、ユーザーインターフェイス、パフォーマンスのプロトタイプモデルを迅速に構築できるようにする統合ツールセット。これらのモデリング活動は、複雑なシステムをより深く理解し、システム開発プロセス中に不正確な要件仕様がコストとスケジュールに与える影響を軽減するために実行されます。モデルは簡単に構築でき、実行されるモデルの特定の動作の側面に応じて、さまざまなレベルの抽象化または粒度で構築できます。^[18]

REE は 3 つの部分から構成されています。最初の部分は proto と呼ばれ、ラピッド プロトタイピングをサポートするために特別に設計された CASE ツールです。2 番目の部分は Rapid Interface Prototyping System (RIP) と呼ばれ、ユーザー インターフェイスの作成を容易にするツールのコレクションです。REE の 3 番目の部分は、RIP と proto へのユーザー インターフェイスで、グラフィカルで使いやすいように設計されています。

REE の開発元である Rome Laboratory は、社内の要件収集方法をサポートすることを意図していました。この方法には、主に 3 つの部分があります。

• さまざまなソース（ユーザー、他のシステムとのインターフェース）からの抽出、仕様、一貫性のチェック
• 多様なユーザーのニーズを総合すると、矛盾がなく、技術的にも経済的にも実現可能であるという分析
• 導き出された要件がユーザーのニーズを正確に反映したものであるかどうかの検証。^[18]

1996年、Rome LabsはSoftware Productivity Solutions (SPS)と契約し、REEをさらに強化して「要件仕様、シミュレーション、ユーザーインターフェイスのプロトタイピング、要件のハードウェアアーキテクチャへのマッピング、コード生成をサポートする商用品質のREE」を作成しました。^[19]このシステムは、Advanced Requirements Engineering WorkstationまたはAREWと名付けられています。

データの非リレーショナル定義 ( Cachéまたは連想モデルの使用など) は、シミュレーションの反復ごとにデータを正規化する必要性を遅らせたり回避したりすることで、エンドユーザーのプロトタイピングの生産性を高めるのに役立ちます。これにより、ビジネス要件がより早く、より明確になる可能性がありますが、要件がターゲットの生産システムで技術的および経済的に実現可能であることが具体的に確認されるわけではありません。

PSDL は、リアルタイム ソフトウェアを記述するためのプロトタイプ記述言語です。^[20] 関連するツール セットは CAPS (Computer Aided Prototyping System) です。^[21] ハード リアルタイム要件を持つソフトウェア システムのプロトタイピングは、タイミング制約によって実装とハードウェアの依存関係が導入されるため困難です。PSDL は、宣言的なタイミング制約を含む制御抽象化を導入することでこれらの問題に対処します。CAPS はこの情報を使用して、コードと関連するリアルタイム スケジュールを自動的に生成し、プロトタイプ実行中にタイミング制約を監視し、一連のパラメーター化されたハードウェア モデルに比例したリアルタイムで実行をシミュレートします。また、不完全なプロトタイプ記述の実行を可能にする既定の仮定を提供し、プロトタイプ構築をソフトウェア再利用リポジトリと統合して効率的な実装を迅速に実現し、要件と設計の迅速な進化をサポートします。^[22]