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

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

• ユーザーインターフェース要件とシステム範囲の確認、
• 事業部門の賛同を得るためのシステムのデモ版、
• 開発期間、費用、労力に関する予備的な見積もりを作成する。

垂直プロトタイプとは、単一のサブシステムまたは機能を詳細に具体化した、より高度なプロトタイプです。特定の機能に関する詳細な要件を取得するのに役立ち、以下のような利点があります。

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

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

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

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

使い捨てプロトタイピングのもう一つの強みは、ユーザーがテストできるインターフェースを構築できることです。ユーザーインターフェースは、ユーザーがシステムとして認識するものであり、それを目の前にすることで、システムがどのように機能するかをはるかに容易に理解できます。

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

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

ストーリーボード、アニメーション、または図面の使用は、使い捨てのプロトタイピングと全く同じではありませんが、確かに同じ範疇に属します。これらは機能的な実装ではありませんが、システムの外観を示すものです。

概要：このアプローチでは、プロトタイプは破棄されることを前提として構築され、最終システムはゼロから構築されます。このアプローチの手順は以下のとおりです。

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

進化型プロトタイピング（ブレッドボードプロトタイピングとも呼ばれる）は、使い捨て型プロトタイピングとは大きく異なります。進化型プロトタイピングを用いる際の主な目的は、構造化された方法で非常に堅牢なプロトタイプを構築し、それを継続的に改良していくことです。このアプローチを採用する理由は、進化型プロトタイプが構築された時点で新しいシステムの核となり、その後、改良点や新たな要件が組み込まれていくからです。

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

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

この手法を用いることで、開発チームは要件定義や設計段階では考えられなかった機能を追加したり、変更を加えたりすることが可能になる。

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

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

「プロトタイプ開発環境において、ユーザーがより改良されたバージョンを待つ間に初期プロトタイプを実用化することは珍しくない…ユーザーは『欠陥のある』システムでも、システムがないよりはましだと判断するかもしれない。」^{[ 6 ]}

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

リスクを最小限に抑えるため、開発者は理解が不十分な機能は実装しません。部分的なシステムが顧客サイトに送られます。ユーザーがシステムを使用するにつれて、新しい機能の機会を発見し、開発者にこれらの機能のリクエストを行います。開発者は、これらの機能強化リクエストと自身のリクエストを受け取り、適切な構成管理手法を使用して、ソフトウェア要件仕様を変更し、設計を更新し、コードを再記述して再テストします。^{[ 10 ]}

最終製品は、個別のプロトタイプとして構築されます。最後に、これらの個別のプロトタイプが統合され、全体的なデザインが完成します。段階的なプロトタイピングを用いることで、ユーザーとソフトウェア開発者の間の時間的なギャップが短縮されます。

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

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

動的システム開発手法（DSDM）^{[ 14 ]}は、プロトタイピングをコア技術として重視するビジネスソリューション提供のためのフレームワークであり、それ自体がISO 9001認証を取得しています。DSDMは、プロトタイプの一般的な定義を拡張したものです。DSDMによれば、プロトタイプは図、ビジネスプロセス、あるいは本番環境に導入されたシステムである場合もあります。DSDMのプロトタイプは段階的に進化し、単純な形態からより包括的な形態へと発展していくことを意図しています。

DSDMプロトタイプは、使い捨てのものもあれば、進化型のものもあります。進化型のプロトタイプは、水平方向（幅を広げてから深さを増す）または垂直方向（各セクションを詳細に構築し、さらに反復を重ねて後続のセクションを詳細化する）に進化させることができます。進化型のプロトタイプは、最終的に最終システムへと発展する可能性があります。

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

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

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

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

運用プロトタイピングは、使い捨てプロトタイピングと進化型プロトタイピングを従来のシステム開発に統合する方法として、アラン・デイビスによって提案されました。「これは、迅速かつ粗雑な開発と従来型の開発の両方の利点を合理的な方法で提供します。設計者は、進化型ベースラインを構築する際に、十分に理解されている機能のみを開発し、使い捨てプロトタイピングを使用して、十分に理解されていない機能を実験します。」^{[ 8 ]}

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

具体的な方法論は以下の手順に従います: ^{[ 8 ]}

• 進化型プロトタイプは、従来型の開発戦略を用いて構築され、ベースラインとなる。この際、十分に理解されている要件のみを規定し、実装する。
• ベースラインのコピーは、訓練を受けたプロトタイプ作成担当者とともに、複数の顧客サイトに送付されます。
• 各設置場所で、プロトタイプ開発者はシステムを利用するユーザーの様子を観察する。
• ユーザーが問題に遭遇したり、新しい機能や要件を思いついたりした場合は、プロトタイプ作成者がそれを記録します。これにより、ユーザーは問題を記録する手間が省け、作業を継続できます。
• ユーザーセッションが終了した後、プロトタイプ開発者はベースラインシステムの上に使い捨てのプロトタイプを構築する。
• ユーザーは新しいシステムを使用し、評価を行う。変更が効果的でない場合は、プロトタイプ作成者はそれらを削除する。
• ユーザーが変更内容を気に入れば、プロトタイプ作成者は機能強化リクエストを作成し、開発チームに転送します。
• 開発チームは、すべての拠点からの変更要求を受け取り、従来の手法を用いて新たな進化型プロトタイプを作成する。

言うまでもなく、この手法の鍵は、ユーザーサイトに赴いて作業できる、十分な訓練を受けたプロトタイピング担当者を確保することである。運用プロトタイピング手法は、複雑で事前に要件がほとんど分かっていないシステムにおいて、多くの利点をもたらす。

進化型システム開発とは、進化型プロトタイピングを正式に実装しようとする手法群である。その中でも特に、システムクラフトと呼ばれる手法は、ジョン・クリニオンが著書『進化型システム開発』の中で解説している。

Systemscraftは、実装される特定の環境に合わせて修正・適応されるべき「プロトタイプ」的な手法として設計された。

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

システムクラフトの基本は、進化型プロトタイピングと同様に、初期要件から動作するシステムを構築し、一連の改訂を重ねてそれを発展させていくことです。システムクラフトでは、システム開発全体を通して従来型の分析手法を非常に重視しています。

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

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

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

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

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

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

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

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

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

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

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

「1985年からローマ研究所で開発されている要求工学環境（REE）は、複雑なシステムの重要な側面を迅速に表現、構築、実行するための統合ツールセットを提供します。」^{[ 17 ]}

要求工学環境は現在、米国空軍がシステム開発に使用している。それは以下の通りである。

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

REEは3つの部分から構成されています。1つ目はprotoと呼ばれる、迅速なプロトタイピングを支援するために特別に設計されたCASEツールです。2つ目はRapid Interface Prototyping System（RIP）と呼ばれる、ユーザーインターフェースの作成を容易にするツール群です。REEの3つ目は、RIPとprotoへのグラフィカルなユーザーインターフェースであり、使いやすさを重視しています。

REEの開発元であるローマ研究所は、REEを自社の要件収集方法論を支援するために開発した。その方法論は主に3つの部分から構成されている。

• さまざまな情報源（ユーザー、他のシステムとのインターフェース）からの情報収集、仕様策定、および整合性チェック
• 多様なユーザーのニーズを総合的に考慮しても、それらが矛盾せず、技術的にも経済的にも実現可能であるという分析結果
• このようにして導き出された要件がユーザーのニーズを正確に反映していることを検証する。^{[ 17 ]}

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

非関係的なデータ定義（例えば、Cachéや連想モデルの使用）は、シミュレーションの各イテレーションでデータを正規化する必要性を遅らせたり回避したりすることで、エンドユーザーによるプロトタイピングの生産性向上に役立ちます。これにより、ビジネス要件の明確化がより早期に、より明確になる可能性がありますが、要件が対象となる本番システムにおいて技術的にも経済的にも実現可能であることを具体的に保証するものではありません。

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