私は今年ソフトウェア工学を勉強していて、タイトルの質問について少し混乱しています。
私の教授と参考文献( "Software Engineering A Practitioner Approach")の両方が、3つのタイトルを異なるモデルとして区別しています。ただし、方法論は同じに見えるが、異なるステートメントを使用してそれらを定義しているため、明らかな違いはわかりません。実際には、それらはすべて同じプロセスモデルを表していると思います。
誰かが異なるモデルをよりよく説明できますか?
クレイグ・ラーマンはこのトピックについて広範囲に書いており、私は彼の有名な論文 反復的および段階的開発:簡単な歴史 (PDF)および彼の本 アジャイルおよび反復的開発:マネージャーのガイド を提案します。
これが私が物事を要約する方法です:
インクリメンタル開発は、システム機能がインクリメント(小さな部分)にスライスされるプラクティスです。各増分で、要件から展開まで、ソフトウェア開発プロセスのすべてのアクティビティを実行することにより、機能の垂直スライスが提供されます。
増分開発(追加)は、ソフトウェア開発で反復開発(redo)と一緒に使用されることがよくあります。これは、反復および増分開発(IID)と呼ばれます。
evolutionおよびevolutionaryという用語は、Tom Gilbの著書Software Metrics1976年に発行され、EVO、IIDの実践(おそらく最も古い)について書いた。進化的開発は、利害関係者への高価値の早期提供と、利害関係者からのフィードバックの取得と活用に重点を置いています。
Software Development:Iterative&Evolutionary では、Craig Larmanは次のように記述しています。
進化的反復開発は、要件、計画、推定値、および解決策evolveまたは反復の過程で改良されることを意味します、開発の反復が始まる前に、主要な事前仕様の取り組みで完全に定義および「凍結」されるのではありません。進化的手法は、新製品開発における予測不可能な発見と変化のパターンと一致しています。
さらに、進化的要件、進化的および適応的計画、進化的配信についてさらに説明します。リンクを確認してください。
スパイラルモデルは、反復開発をより適切にサポートするためのウォーターフォールの拡張として1980年代半ばにバリーベームによって正式化されたもう1つのIIDアプローチであり、(反復リスク分析を通じて)リスク管理に特に重点を置いています。
引用 反復的および段階的開発:簡単な歴史 :
IIDの出版物の1985年のランドマークは、Barry Boehmの「ソフトウェア開発と拡張のスパイラルモデル」でした(より頻繁に引用されるのは1986年です)。スパイラルモデルは、おそらくチームがリスクによって開発サイクルに優先順位を付けた最初のケースではありませんでした。たとえば、GilbとIBM FSDは、以前にこのアイデアのバリエーションを適用または提唱していました。ただし、スパイラルモデルは、リスク主導の反復の概念を明確にし、各反復でリスク評価の個別のステップを使用する必要性を明確にしました。
アジャイルメソッドは、IIDおよび進化的メソッドのサブセットであり、現在では好まれています。
これらの概念は通常不十分に説明されています。
Incrementalは、作業成果物(ドキュメント、モデル、ソースコードなど)のプロパティであり、それらが作成されるのではなく、少しずつ作成されることを意味します一度に。たとえば、要件分析中にクラスモデルの最初のバージョンを作成し、UIモデリング後にそれを拡張して、詳細設計中にさらに拡張します。
Evolutionaryは、成果物、つまりユーザーに提供される作業成果物のプロパティであり、この点で、それは特定の種類の「増分」です。つまり、提供されるものはすべて、完全に機能するわけではなく、できるだけ早く初期形式で提供され、その後、機能が追加されるたびに再配信されます。これはしばしば反復ライフサイクルを意味します。
[iterativeライフサイクル、ただし方法は、製品を指す「増分」ではなく、実行するタスクを指します。これは [〜#〜] semat [〜#〜] )によって採用されるビューであり、同じタイプのタスクを繰り返し実行することを意味します。たとえば、反復的なライフサイクルでは、設計、コーディング、ユニットテスト、リリース、そして同じことを何度も繰り返します。反復と増分は互いに意味し合うわけではないことに注意してください。両方の任意の組み合わせが可能です。]
ライフサイクルのスパイラルモデルは、ウォーターフォールの側面と反復的なアプローチなどの革新的な進歩を組み合わせた、 Barry Boehm によって提案されたモデルです。組み込みの品質管理。
「作業成果物」、「タスク」、「ライフサイクル」などの概念については、 ISO/IEC 24744 を参照してください。
お役に立てれば。
これは、ISO 24748-1:2016(システムおよびソフトウェアエンジニアリングライフサイクル管理)のipsis litteris定義です。
システムおよびソフトウェアプロジェクトに適用できるさまざまな開発戦略があります。これらの戦略のうち3つを以下にまとめます。
a)一度通過。 「ウォータースルー」とも呼ばれる「ワンススルー」戦略は、開発プロセスを1回実行することで構成されます。簡単に言うと、ユーザーのニーズを特定し、要件を定義し、システムを設計し、システムを実装し、テストし、修正して提供します。
b)増分。 「増分」戦略は、ユーザーのニーズを決定し、システム要件を定義してから、残りの開発を一連のビルドで実行します。最初のビルドには計画された機能の一部が組み込まれ、次のビルドにはさらに機能が追加され、システムが完成するまで続きます。
c)進化的。 「進化的」戦略もビルドでシステムを開発しますが、ユーザーのニーズが完全に理解されておらず、すべての要件を事前に定義できないことを認める点で、増分戦略とは異なります。この戦略では、ユーザーのニーズとシステム要件が部分的に事前に定義され、その後の各ビルドで改良されます。
お役に立てれば。タチ