インクリメンタルアプローチは、生成物が終了するまで（たびに加算されるもう少し）モデルは、設計、実装、および漸増試験されたソフトウェア開発方法です。開発と保守の両方が含まれます。製品は、すべての要件を満たしたときに完成品として定義されます
反復設計は、プロトタイプ試験、分析、および製品またはプロセスを精製する循環プロセスに基づく設計手法です。設計の最新の反復をテストした結果に基づいて、変更と改良が行われます。このプロセスは、最終的に設計の品質と機能を改善することを目的としています。反復設計では、設計されたシステムとの相互作用は、連続したバージョンまたは設計の反復が実装されるときに、プロジェクトを通知および進化させるための研究の一形態として使用されます。
両方の方法は、システムの一部を作成し、すべてのテストケースに合格するようにシステムを調整し、システムの別のコンポーネントを追加し、再度調整することに関するものと思われます。
これら2つのソフトウェア設計方法の実際の違いは何ですか
これらの2つの方法を組み合わせて、反復および増分設計アプローチを形成する方法
回答:
インクリメンタルアプローチは、ステップのセット番号を使用し、開発が進行の直線経路に最初から最後まで行きます。
インクリメンタル開発は、設計、実装、テスト/検証、メンテナンスから段階的に行われます。これらはさらにサブステップに分割できますが、ほとんどのインクリメンタルモデルは同じパターンに従います。滝のモデルは、従来の増分開発アプローチです。
反復アプローチは、ステップのないセット数を持っていない、むしろ開発が周期的に行われています。
反復的な開発では、個々の機能の進捗を追跡することにあまり関心がありません。代わりに、作業プロトタイプを最初に作成し、開発サイクルで機能を追加することに重点が置かれます。開発サイクルでは、すべてのサイクルで増分開発ステップが実行されます。アジャイルモデリングは、典型的な反復アプローチです。
増分モデルは元々、工場で使用されている従来の組立ラインモデルに従うために開発されました。残念ながら、ソフトウェアの設計と開発は、物理的な商品の製造とほとんど共通点がありません。コードは開発の完成品ではなく設計図です。多くの場合、開発プロセス中に適切な設計の選択が「発見」されます。適切なコンテキストなしに開発者を一連の仮定に縛り付けると、最良の場合は設計が貧弱になり、最悪の場合は開発が完全に混乱する可能性があります。
反復アプローチは、ソフトウェア開発の進行の自然な経路によりよく適合するため、現在では一般的なプラクティスになりつつあります。仮定に基づいて「完璧な設計」を追いかけるために多くの時間/労力を費やす代わりに、反復アプローチは、ユーザーのニーズに合わせて開始および進化するのに「十分な」何かを作成することです。
tl; dr-インクリメンタルモデルでエッセイを書いている場合、一度に1つの文を最初から最後まで完全に書き込もうとします。反復モデルで作成した場合は、簡単なラフドラフトを作成し、一連の改訂フェーズを通じて改善するように努力します。
更新：
より実用的な例に合わせて、「インクリメンタルアプローチ」の定義を変更しました。
あなたがこれまで契約に対処しなければならなかった場合、増分アプローチは、ほとんどの契約がどのように実行されるかです（特に軍隊の場合）。典型的な「ウォーターフォールモデル」の多くの微妙なバリエーションにもかかわらず、それらのほとんど/すべてが実際に同じ方法で適用されます。
手順は次のとおりです。
PDRとCDRは、仕様が作成および改訂される場所です。仕様が完成したら、スコープのクリープを防ぐために仕様を凍結する必要があります。ソフトウェアが既存のシステムを拡張するために使用される場合、統合が発生します。検証は、アプリケーションが仕様に一致することを確認するためのものです。信頼性は、アプリケーションが長期にわたって信頼できることを証明するテストです。これは、システムが一定の割合の稼働時間（3か月間99％の稼働時間）を維持する必要があるSLA（サービスレベル契約）のように指定できます。 ）。
このモデルは、紙で簡単に指定できるが、作成が難しいシステムに最適です。ソフトウェアは、かなりの詳細度（UMLなど）を紙で指定するのは非常に困難です。管理/契約を担当するほとんどの「ビジネスタイプ」は、ソフトウェア開発に関してはコード自体が仕様であることを認識していません。紙の仕様は、多くの場合、コード自体と同じかそれ以上の時間/労力を費やし、通常、実際には不完全/劣っていることを証明しています。
インクリメンタルアプローチは、コード自体を仕様として扱うことにより、無駄な時間/リソースを試みます。複数の改訂手順を経て紙の仕様を実行する代わりに、コード自体は複数の改訂サイクルを経ます。
あらゆる形容詞、およびソフトウェア開発のほとんどのものと同様に...それは依存します！
それは文脈と用語がどのように使用されているかに依存します。したがって、ソフトウェア開発に対するインクリメンタルアプローチと反復アプローチの違いについて尋ねているのですが、引用は反復設計を見ており、これは異なることです（ただし類似しています）。
ソフトウェア開発へのアプローチとして具体的に答えます。
質問は見当違いです。どちらでもありません。プロセスのさまざまな部分を参照しているため、直接比較することはできません。
反復的なソフトウェア開発は、本質的にインクリメンタルです。増分ソフトウェア開発は反復的である必要はありません。
増分は小さな動きであり、うまくいけば前進します。実行される作業の各ステップを参照する方法です。
反復は作業のサイクルです。
したがって、反復とは、使用される開発サイクル全体を指します。増分は、作業の個々のステップを指します。反復は増分を生成します。増分は、ソフトウェアに対する1つ以上の実際の増分（通常はそれ以上）で構成されます。
結論として...
反復的なソフトウェア開発は、ソフトウェア開発に対する特定のタイプのアプローチであり、従来のウォーターフォールアプローチとは対照的に、反復して動作します。スクラムは良い例です。
増分ソフトウェア開発はより一般的であり、作業を段階的に進めることを指します。これは、ほとんどの（おそらくすべての）アプローチの特徴です。そうは言っても、この用語は現代のアジャイルなアプローチに関連してより頻繁に使用されます。これは、2つの非常に類似した用語の混乱をおそらく説明しています。
そして最後に、もちろん、それが使用されるときの用語の意味に依存します。これはしばしば、話し手、時間帯などによって大きく異なります！
さらに興味深い質問は、ソフトウェア開発への経験的アプローチがどこに当てはまるかです。反復アプローチの利点は、経験主義を可能にすることです。経験主義は魔法の発生場所です。
お役に立てれば。
この記事では、例を挙げて説明します。