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