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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

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

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

概要

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

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

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

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

概要

プロトタイピングのプロセスには、次の手順が含まれます。[要出典]

  1. 基本的な要件を特定する
    必要な入力および出力情報を含む基本的な要件を決定します。セキュリティなどの詳細は、通常は無視できます。
  2. 初期プロトタイプを開発する
    最初のプロトタイプは、ユーザーインターフェイスのみを含むように開発されています。(下記の水平プロトタイプを参照)
  3. レビュー
    エンドユーザーを含む顧客は、プロトタイプを調べて、追加または変更の可能性についてフィードバックを提供します。
  4. プロトタイプを改訂および強化する
    フィードバックを使用すると、仕様とプロトタイプの両方を改善できます。契約/製品の範囲内にあるものについての交渉が必要になる場合があります。変更が導入された場合は、手順3と4の繰り返しが必要になる場合があります。

寸法

Nielsenは、彼の著書UsabilityEngineeringでプロトタイプのさまざまな次元を要約しています。

横型プロトタイプ

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

  • ユーザーインターフェイスの要件とシステムスコープの確認、
  • ビジネスから賛同を得るためのシステムのデモンストレーションバージョン、
  • 開発時間、コスト、および労力の予備的な見積もりを作成します。

垂直プロトタイプ

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

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

タイプ

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

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

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

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

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

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

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

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

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

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

  1. 予備要件を書く
  2. プロトタイプを設計する
  3. ユーザーエクスペリエンス/プロトタイプの使用、新しい要件の指定
  4. 必要に応じて繰り返します
  5. 最終要件を書く

進化的プロトタイピング

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

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

「…進化的プロトタイピングは、私たちがすべての要件を理解しているわけではなく、よく理解されている要件のみを構築することを認めています。」[8]

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

システムが有用であるためには、意図された運用環境での使用を通じて進化する必要があります。製品が「完成」することは決してありません。使用環境が変化するにつれて、それは常に成熟しています…私たちはしばしば、私たちが現在いる最も身近な参照フレームを使用してシステムを定義しようとします。私たちは、ビジネスの実施方法とビジネスを実施するための技術基盤について想定しています。機能を開発するための計画が制定され、遅かれ早かれ、想定されたシステムに似たものが提供されます。[9]

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

「プロトタイピング環境では、ユーザーが最初のプロトタイプを実用化する一方で、より開発されたバージョンを待つことも珍しくありません。ユーザーは、「欠陥のある」システムの方がシステムがまったくないよりも優れていると判断する可能性があります。」[6]

進化的プロトタイピングでは、開発者は、システム全体の開発に取り組む代わりに、理解しているシステムの一部を開発することに集中できます。

リスクを最小限に抑えるために、開発者はよく理解されていない機能を実装しません。部分的なシステムは顧客サイトに送信されます。ユーザーがシステムを操作すると、新しい機能の機会を検出し、開発者にこれらの機能の要求を出します。次に、開発者はこれらの拡張要求を独自のものと一緒に受け取り、適切な構成管理手法を使用して、ソフトウェア要件の仕様を変更し、設計を更新し、再コーディングして再テストします。[10]

インクリメンタルプロトタイピング

最終製品は、個別のプロトタイプとして作成されます。最後に、個別のプロトタイプが全体的な設計に統合されます。インクリメンタルプロトタイピングの助けを借りて、ユーザーとソフトウェア開発者の間の時間のギャップが減少します。

極端なプロトタイピング

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

「このプロセスはエクストリームプロトタイピングと呼ばれ、プロセスの第2フェーズに注目します。このフェーズでは、契約以外のサービスをほとんど考慮せずに、完全に機能するUIが開発されます。」[11]

利点

ソフトウェア開発でプロトタイピングを使用することには多くの利点があります–いくつかは具体的で、いくつかは抽象的です。[12]

時間とコストの削減:プロトタイピングにより、開発者に提供される要件と仕様の品質を向上させることができます。変更は開発の後半で検出されるため、実装にかかるコストが指数関数的に高くなるため、ユーザーが本当に必要としているものを早期に決定することで、ソフトウェアをより高速で安価にすることができます。[7]

ユーザーの関与の改善と増加:プロトタイピングにはユーザーの関与が必要であり、プロトタイプを表示して操作できるため、より優れた、より完全なフィードバックと仕様を提供できます。[6]ユーザーが検討しているプロトタイプの存在は、お互いが自分の言ったことを理解していると双方が信じるときに発生する多くの誤解や誤解を防ぎます。ユーザーは開発チームの誰よりも問題のドメインをよく知っているため、対話が増えると、有形無形の品質が向上した最終製品が得られる可能性があります。最終製品は、外観、感触、パフォーマンスに対するユーザーの要望を満たす可能性が高くなります。

短所

プロトタイピングを使用する、またはおそらく誤用することも、不利になる可能性があります。

不十分な分析:限られたプロトタイプに焦点を合わせると、開発者はプロジェクト全体を適切に分析できなくなる可能性があります。これは、より良い解決策を見落としたり、不完全な仕様を準備したり、限られたプロトタイプを維持するのが難しい不十分に設計された最終プロジェクトに変換したりすることにつながる可能性がありますさらに、プロトタイプは機能が制限されているため、プロトタイプを最終成果物のベースとして使用すると、拡張性が低下する可能性があります。これは、開発者がモデルとしてのプロトタイプの作成に集中しすぎている場合は気付かない可能性があります。

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

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

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

プロトタイプの過度の開発時間:プロトタイピングの重要な特性は、それが迅速に行われることになっているという事実です。開発者がこの事実を見失った場合、彼らは非常に複雑すぎるプロトタイプを開発しようとする可能性があります。プロトタイプが廃棄されると、それが提供する正確に開発された要件は、プロトタイプの開発に費やされた時間を埋め合わせるのに十分な生産性の向上をもたらさない可能性があります。ユーザーは、プロトタイプの詳細についての議論にとらわれ、開発チームを停滞させ、最終製品を遅らせる可能性があります。

プロトタイピングの実装費用:プロトタイピングに焦点を当てた開発チームを構築するための初期費用は高くなる可能性があります。多くの企業は開発方法論を導入しており、それらを変更することは、再トレーニング、ツールの再構築、またはその両方を意味する可能性があります。多くの企業は、必要なだけ労働者を再訓練することを気にせずに、プロトタイプを作成し始める傾向があります。

プロトタイピング技術を採用する際の一般的な問題は、学習曲線の背後にある不十分な努力による生産性への高い期待です。プロトタイピング技術を使用するためのトレーニングに加えて、技術をサポートするための企業およびプロジェクト固有の基礎となる構造を開発する必要性が見過ごされがちです。この基本構造を省略すると、生産性が低下することがよくあります。[13]

適用性

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

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

バッチ処理やほとんど計算を行うシステムなど、ユーザーの操作がほとんどないシステムは、プロトタイピングのメリットをほとんど受けません。場合によっては、システム機能を実行するために必要なコーディングが多すぎて、プロトタイピングが提供できる潜在的な利益が小さすぎることがあります。[6]

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

動的システム開発方法

Dynamic Systems Development Method(DSDM)[14]は、コア技術としてプロトタイピングに大きく依存するビジネスソリューションを提供するためのフレームワークであり、それ自体がISO9001の承認を受けています。これは、プロトタイプの最も理解されている定義を拡張したものです。DSDMによると、プロトタイプは、ダイアグラム、ビジネスプロセス、または実稼働環境に配置されたシステムである可能性があります。DSDMプロトタイプは、単純な形式からより包括的な形式に進化する、段階的なものになることを目的としています。

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

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

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

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

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

運用プロトタイピング

運用プロトタイピングは、使い捨ておよび進化的プロトタイピングを従来のシステム開発と統合する方法として、AlanDavisによって提案されました。「これは、迅速で汚い開発の世界と従来の開発の世界の両方の長所を賢明な方法で提供します。設計者は、進化のベースラインを構築する際によく理解された機能のみを開発し、使い捨てのプロトタイピングを使用して、よく理解されていない機能を実験します。」[8]

デイビスの信念は、2つのアプローチを組み合わせようとする場合、「品質をラピッドプロトタイプに後付けする」ことは正しい方法ではないということです。彼のアイデアは、進化的なプロトタイピング手法に取り組み、進化するたびにシステムの機能を迅速にプロトタイプ化することです。

具体的な方法論は次の手順に従います。[8]

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

明らかに、この方法の鍵は、十分に訓練されたプロトタイプ作成者がユーザーサイトにアクセスできるようにすることです。運用プロトタイピングの方法論は、複雑で事前に既知の要件がほとんどないシステムで多くの利点があります。

進化型システム開発

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

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

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

Systemscraftの基本は、進化的プロトタイピングとは異なり、初期要件から機能するシステムを作成し、それを一連の改訂で構築することです。Systemscraftは、システムの開発全体で使用されている従来の分析に重点を置いています。

進化的急速開発

Evolutionary Rapid Development(ERD)[15]は、国防高等研究計画局(DARPA) の情報技術オフィスの技術開発および統合エージェントであるソフトウェア生産性コンソーシアムによって開発されました。

ERDの基本は、コンポーネントの再利用、ソフトウェアテンプレートの使用、およびアーキテクチャテンプレートに基づいてソフトウェアシステムを構成するという概念です。変化するユーザーのニーズとテクノロジーに迅速に対応するシステム機能の継続的な進化は、ソリューションのクラスを表す進化可能なアーキテクチャによって強調されています。このプロセスは、ソフトウェアとシステムエンジニアリングの分野を統合する、職人ベースの小規模なチームの使用に焦点を当てています。
ERDベースのプロジェクトの成功の鍵は、テクノロジー、市場、または顧客の要件の変化に迅速に対応できる最先端のテクノロジーを使用して、機能、インフラストラクチャ、およびコンポーネントを並行して探索的に分析および開発することです。[9]

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

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

ERDプロセスは、利害関係者がニーズと期待を伝える方法として、紙製品ではなく実証済みの機能を使用するように構成されています。迅速な配信というこの目標の中心は、「タイムボックス」方式の使用です。タイムボックスは、特定のタスク(たとえば、一連の機能の開発)を実行する必要がある固定期間です。漠然とした一連の目標を満たすために時間を拡張するのではなく、時間は固定され(暦週と工数の両方で)、これらの制約内で現実的に達成できる一連の目標が定義されます。開発が「ランダムウォーク」に退化するのを防ぐため、 "長期計画は、反復をガイドするために定義されます。これらの計画は、システム全体のビジョンを提供し、プロジェクトの境界(制約など)を設定します。プロセス内の各反復は、これらの長期計画のコンテキストで実行されます。 。

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

ツール

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

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

スクリーンジェネレーター、デザインツール、ソフトウェアファクトリー

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

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

アプリケーション定義またはシミュレーションソフトウェア

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

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

要件エンジニアリング環境

「1985年以来ローマ研究所で開発中の要件工学環境(REE)は、複雑なシステムの重要な側面のモデルを迅速に表現、構築、実行するための統合ツールセットを提供します。」[17]

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

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

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

REEの開発者であるRomeLaboratoryは、内部要件収集方法をサポートすることを目的としていました。彼らの方法には3つの主要な部分があります。

  • さまざまなソース(ユーザー、他のシステムへのインターフェース)からの引き出し、仕様、および整合性チェック
  • 多様なユーザーのニーズをまとめて競合せず、技術的および経済的に実現可能であるという分析
  • そのように導き出された要件がユーザーのニーズを正確に反映していることの検証。[17]

1996年、Rome Labsはソフトウェア生産性ソリューション(SPS)と契約し、REEをさらに強化して、「要件仕様、シミュレーション、ユーザーインターフェイスのプロトタイピング、要件のハードウェアアーキテクチャへのマッピング、およびコード生成をサポートする商用品質のREE ...」を作成しました[18 ]このシステムは、Advanced Requirements EngineeringWorkstationまたはAREWと呼ばれます。

非リレーショナル環境

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

PSDL

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

参考文献

  1. ^ Todd Grimm:人間の状態:ラピッドプロトタイピングの正当化。時間圧縮技術、vol。3いいえ。3. Accelerated Technologies、Inc. 1998年5月。ページ1。 [1]
  2. ^ 「ソフトウェアプロトタイピング-INGSOFTWARE」ingsoftware.com 2018年6月27日取得
  3. ^ Smith MFソフトウェアプロトタイピング:採用、実践、管理マグロウヒル、ロンドン(1991)。
  4. ^ デュワー、ロバートBK; フィッシャージュニア、ジェラルドA。; Schonberg、エドモンド; Froelich、Robert; ブライアント、スティーブン; ゴス、クリントンF。; バーク、マイケル(1980年11月)。「NYUエイダ翻訳者および通訳者」。ACM SIGPLAN通知–Adaプログラミング言語に関するACM-SIGPLANシンポジウムの議事録15(11):194–201。土井10.1145 /948632.948659ISBN 0-89791-030-3S2CID10586359 _
  5. ^ SofTech Inc.(1983-04-11)。「Adaコンパイラ検証要約レポート:NYU Ada / ED、バージョン19.7V-001」2012年3月12日にオリジナルからアーカイブされました。2010年12月16日取得
  6. ^ a b c d e f John Crinnion:Evolutionary Systems Development、構造化シ​​ステム手法内でのプロトタイピングの使用に関する実用的なガイド。プレナムプレス、ニューヨーク、1991年。18ページ。
  7. ^ a b c S. P. Overmyer:革新的vs.進化的ラピッドプロトタイピング:ソフトウェアの生産性とHCI設計の懸念のバランスをとる。Center of Excellence in Command、Control、Communications and Intelligence(C3I)、George Mason University、4400 University Drive、Fairfax、Virginia。
  8. ^ a b c Alan M. Davis:運用プロトタイピング:新しい開発アプローチ。IEEEソフトウェア、1992年9月。71ページ。
  9. ^ a b ソフトウェア生産性コンソーシアム:進化的急速開発。SPCドキュメントSPC-97057-CMC、バージョン01.00.04、1997年6月。バージニア州ハーンドン6ページ。
  10. ^ デイビス。ページ72-73。引用:E。BersoffおよびA. Davis、ソフトウェア構成管理のライフサイクルモデルの影響。通信。ACM、1991年8月、104〜118ページ
  11. ^ Komatineni、Satya。「極端なプロトタイピングによるITプロジェクトの提供の再構築」2016年12月6日にオリジナルからアーカイブされました。
  12. ^ C. Melissa Mcclendon、Larry Regot、GerriAkersから改作。
  13. ^ ジョセフE.アーバン:ソフトウェアプロトタイピングと要件エンジニアリング。ローマ研究所、ニューヨーク州ローマ。
  14. ^ 動的システム開発方法コンソーシアム。https://web.archive.org/web/20060209072841/http://na.dsdm.org/
  15. ^ ソフトウェア生産性コンソーシアムから採用。PPS 10–13。
  16. ^ シミュレーションソフトウェアがアプリケーション開発を合理化する 方法アーカイブ2012-07-22atarchive.today
  17. ^ a b c Dr. Ramon Acosta、Carla Burns、William Rzepka、およびJamesSidoran。要件エンジニアリング環境でのラピッドプロトタイピング技術の適用。IEEE、1994年。[2]
  18. ^ ソフトウェア生産性ソリューション、組み込まれています。高度な要件エンジニアリングワークステーション(AREW)。1996. [3]
  19. ^ Luqi; Berzins、Yeh(1988年10月)。「リアルタイムソフトウェアのプロトタイピング言語」(PDF)ソフトウェアエンジニアリングに関するIEEEトランザクション14(10):1409–1423。土井10.1109 /32.6186hdl10945/39162
  20. ^ Luqi; ケタブチ(1988年3月)。「コンピュータ支援プロトタイピングシステム」。IEEEソフトウェア5(2):66–72。土井10.1109 /52.2013hdl10945/43616S2CID15541544_ 
  21. ^ Luqi(1989年5月)。「ラピッドプロトタイピングによるソフトウェアの進化」IEEEコンピュータ22(5):13–25。土井10.1109 /2.27953hdl10945/43610S2CID1809234_