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