SDLC-反復モデル
反復モデルでは、反復プロセスは、ソフトウェア要件の小さなセットの単純な実装から始まり、完全なシステムが実装されて展開の準備ができるまで、進化するバージョンを繰り返し拡張します。
反復ライフサイクルモデルは、要件の完全な仕様から始めようとはしません。代わりに、開発はソフトウェアの一部のみを指定して実装することから始まり、その後、さらなる要件を特定するためにレビューされます。次に、このプロセスが繰り返され、モデルの各反復の最後にソフトウェアの新しいバージョンが生成されます。
反復モデル-設計
反復プロセスは、ソフトウェア要件のサブセットの単純な実装から始まり、完全なシステムが実装されるまで、進化するバージョンを繰り返し拡張します。各反復で、設計変更が行われ、新しい機能機能が追加されます。この方法の背後にある基本的な考え方は、繰り返しのサイクル(反復)と一度に小さな部分(増分)でシステムを開発することです。
次の図は、反復型および増分型モデルを表したものです。
反復型およびインクリメンタル開発は、反復型設計または反復法と開発用のインクリメンタルビルドモデルの両方を組み合わせたものです。「ソフトウェア開発中に、ソフトウェア開発サイクルの複数の反復が同時に進行している可能性があります。」このプロセスは、「進化的買収」または「インクリメンタルビルド」アプローチとして説明できます。
このインクリメンタルモデルでは、要件全体がさまざまなビルドに分割されます。各反復中に、開発モジュールは要件、設計、実装、およびテストの各フェーズを通過します。モジュールの後続の各リリースは、前のリリースに機能を追加します。このプロセスは、要件に従ってシステム全体の準備が整うまで続きます。
反復的なソフトウェア開発ライフサイクルをうまく使用するための鍵は、要件の厳密な検証と、モデルの各サイクル内のそれらの要件に対するソフトウェアの各バージョンの検証とテストです。ソフトウェアが連続するサイクルを通じて進化するにつれて、ソフトウェアの各バージョンを検証するために、テストを繰り返して拡張する必要があります。
反復モデル-アプリケーション
他のSDLCモデルと同様に、反復型および増分型開発には、ソフトウェア業界でいくつかの特定のアプリケーションがあります。このモデルは、次のシナリオで最も頻繁に使用されます-
システム全体の要件が明確に定義され、理解されています。
主要な要件を定義する必要があります。ただし、一部の機能または要求された拡張機能は、時間の経過とともに進化する可能性があります。
市場の制約には時間があります。
新しいテクノロジーが使用されており、プロジェクトに取り組んでいる間、開発チームによって学習されています。
必要なスキルセットを備えたリソースは利用できず、特定の反復で契約ベースで使用される予定です。
将来変更される可能性のあるリスクの高い機能と目標がいくつかあります。
反復モデル-長所と短所
このモデルの利点は、開発の非常に早い段階でシステムの動作モデルが存在することです。これにより、機能上の欠陥や設計上の欠陥を簡単に見つけることができます。開発の早い段階で問題を見つけることで、限られた予算で是正措置を講じることができます。
このSDLCモデルの欠点は、大規模でかさばるソフトウェア開発プロジェクトにのみ適用できることです。これは、小さなソフトウェアシステムをさらに小さなサービス可能な増分/モジュールに分割することが難しいためです。
反復型および増分型SDLCモデルの利点は次のとおりです。
一部の機能は、ライフサイクルの早い段階で迅速に開発できます。
結果は早期かつ定期的に取得されます。
並行開発を計画することができます。
進捗状況を測定できます。
スコープ/要件を変更するためのコストが低くなります。
小さな反復でのテストとデバッグは簡単です。
反復中にリスクが特定され、解決されます。そして、各反復は簡単に管理できるマイルストーンです。
リスク管理が容易-リスクの高い部分が最初に実行されます。
増分ごとに、運用可能な製品が提供されます。
各増分から特定された問題、課題、およびリスクは、次の増分に利用/適用できます。
リスク分析が優れています。
要件の変化をサポートします。
初期動作時間は短くなります。
大規模でミッションクリティカルなプロジェクトに適しています。
ライフサイクル中、ソフトウェアは早期に作成され、顧客の評価とフィードバックを容易にします。
反復型および増分型SDLCモデルの欠点は次のとおりです。
より多くのリソースが必要になる場合があります。
変更のコストは低くなりますが、要件の変更にはあまり適していません。
より多くの管理上の注意が必要です。
ライフサイクル全体の最初にすべての要件が収集されるわけではないため、システムアーキテクチャまたは設計の問題が発生する可能性があります。
増分を定義するには、システム全体の定義が必要になる場合があります。
小規模なプロジェクトには適していません。
管理の複雑さはさらに大きくなります。
プロジェクトの終了がわからない場合がありますが、これはリスクです。
リスク分析には高度なスキルを持つリソースが必要です。
プロジェクトの進捗状況は、リスク分析フェーズに大きく依存します。