使い捨てプロトタイピングが必要な理由

ソフトウェアエンジニアリングにおける使い捨てプロトタイピングモデルとは何ですか？なぜそれが必要なのですか？進化的プロトタイピングとどのように違いますか？

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

使い捨てプロトタイピングとは、将来のアプリケーションの一部を可能な限り迅速に作成して、機能が技術的に実現可能であることを保証するか、関係者や潜在的なユーザーにフィードバックを収集して機能を提示することです。

このプロトタイプのソースコードは、後でアプリケーション自体を開発するときに再利用されないため、使い捨てプロトタイプになります。それが使い捨てのコードであることを知ることは、コード、スタイル、デザインパターン、またはテストの保守性などの側面を残しながら、実際の機能に集中するのに役立ちます。これにより、最終製品の技術的負債に悪影響を与えることなく、非常に速くプロトタイプを完成させることができます。

使い捨てプロトタイプはスケッチとは異なります。スケッチは、よりグラフィカルで、ユーザーインターフェイスとユーザーエクスペリエンスを重視しており、プログラミングコードの記述ではありません。使い捨てプロトタイピングは通常、スケッチでは不十分な場合に使用されます（たとえば、さまざまなスマートフォンで機能がどのように実行されるかを示す必要がある場合や、実際のパフォーマンスと応答性を示す必要がある場合）。

使い捨てのプロトタイピングは、技術的背景がなく、期限が厳しくリソースが非常に限られている状況で関係者を扱う場合にリスクをもたらす可能性があります。関係者は、プロトタイプのソースコードを最終製品で再利用するように説得しようとする場合があります。発売までの時間を短縮できるのは当然のことですが、実際は発送が遅れるだけです。これを防ぐ1つの方法は、プロトタイプに本番環境で使用できない言語を使用することです（たとえば、最終製品がPythonのみがインストールされているLinuxサーバーでホストされることがわかっている場合は、C＃を使用します）。

^{図1：使い捨てのプロトタイピングとスケッチ：プロトタイプは、実際の機能の開発を開始する前に初期のフィードバックを収集するのに役立ちます。}

進化したプロトタイピング

進化的プロトタイピングは、プロトタイプを構築することで構成されます。プロトタイプは、利害関係者または潜在的なユーザーからの定期的なフィードバックに基づいて改良されます。

ここでは、コード、スタイル、デザインパターン、またはテストの保守性が最初から数えられており、プロトタイプをフル機能のエンタープライズグレードの製品に進化させることができます。プロトタイプの初期のステップには、将来の製品のコア部分のみが含まれ、その後、機能が段階的に追加されます。

^{図2：進化的なプロトタイピング：機能はプロトタイプに集約され、最終製品を構築します。}

進化的プロトタイピングは、増分プロトタイピングとは異なります。インクリメンタルプロトタイピングは、それぞれが将来のシステムの一部を表す複数のプロトタイプを構築し、それらを組み合わせることで構成されます。進化的プロトタイピングはアジャイルに近いです。多くの場合、限られた機能を備えた実用的な製品を早期に入手し、利害関係者が資金を手にするまで拡張することができます。一方、インクリメンタルプロトタイピングは、多くの貢献チームがあり、各チームが個別のプロトタイプに取り組んでいる大規模プロジェクトに適しています。

^{図3：インクリメンタルプロトタイピング：複数のプロトタイプを組み合わせて最終製品を形成します。}

進化的プロトタイピングは、アジャイル手法とも異なります。アジャイルは、完全に機能する製品を製造にリリースできる反復と頻繁なマイルストーンについてです。毎週木曜日に機能する製品がある場合、アジャイルを実行しています。進化的プロトタイピングでは、プロトタイプを拡張しますが、完全に機能する製品を定期的に使用する必要はありません。最初のプロトタイプを作成するのに2か月かかりますが、2、3日でいくつかの機能を追加して拡張し、その後、別の機能に3か月を費やすことができます。アジャイルでは、このような不規則なパターンはありません。

特定のアジャイル手法では、追加のルールが適用されます。たとえば、ペアプログラミングを行わない場合、エクストリームプログラミングを行っていると断言することはできません。チームが毎日会議を行っていない場合は、スクラムを行っていません。

プロトタイピングは多くの理由で使用されます。新しいアプリケーションのユーザーエクスペリエンスを測定して、実際に構築するための費用をかけずに、構築する価値があるかどうかを推定したい場合があります。ノード上で実行されている実際のソフトウェアを終了する前に、ネットワーク上で統合または負荷テストを実行するために、ネットワークを介して既存のプログラムと通信するものが必要な場合があります。おそらく、投資家が実際に必要な投資をより積極的に考え出すことができるように、ほぼ完成したプログラムのように見えるものを投資家に示す必要があるかもしれませんプログラムを終了します。（これは欺瞞とは何の関係もありません。ユーザーとマネージャーはソフトウェアをそのインターフェースだけで判断するので、プロジェクトが実際と同じくらい遠くにあると彼らが信じるように彼らに良いインターフェースを提示することが重要です。）

使い捨てのプロトタイプは、単にインクリメンタル実際のソリューションに変換が、新しい-書かれたものに交換されることはありませんものです。明らかに、少なくとも必要な機能の一部をすでに実行しているコードを破棄することには、いくつかの無駄がありますが、適切なコードのアーキテクチャの整合性が高ければ、その欠点を簡単に埋め合わせることができます。