SDLC-RADモデル

RAD（Rapid Application Development）*モデルは、プロトタイピングと反復開発に基づいており、特定の計画は含まれていません。ソフトウェア自体を記述するプロセスには、製品の開発に必要な計画が含まれます。

Rapid Application Developmentは、ワークショップまたはフォーカスグループを通じて顧客の要件を収集し、反復コンセプトを使用して顧客がプロトタイプを早期にテストし、既存のプロトタイプ（コンポーネント）を再利用し、継続的な統合と迅速な配信を実現します。

RADとは何ですか？

ラピッドアプリケーション開発は、ラピッドプロトタイピングを優先して最小限の計画を使用するソフトウェア開発方法論です。プロトタイプは、製品のコンポーネントと機能的に同等の作業モデルです。

RADモデルでは、機能モジュールはプロトタイプとして並行して開発され、統合されて、製品を迅速に納品できる完全な製品を作成します。詳細な事前計画が存在しないため、開発プロセスに変更を組み込むことが容易になります。

RADプロジェクトは、反復および増分モデルに従い、開発者、ドメインエキスパート、顧客担当者、およびコンポーネントまたはプロトタイプで漸進的に作業するその他のITリソースで構成される小さなチームを持ちます。

このモデルが成功するための最も重要な側面は、開発されたプロトタイプが再利用可能であることを確認することです。

RADモデルの設計

RADモデルは、分析、設計、構築、テストの各フェーズを一連の短い反復的な開発サイクルに分散します。

以下は、RADモデルのさまざまなフェーズです-

ビジネスモデリング

開発中の製品のビジネスモデルは、情報の流れとさまざまなビジネスチャネル間での情報の配信の観点から設計されています。完全なビジネス分析が実行され、ビジネスに不可欠な情報、その入手方法、情報がいつどのように処理されるか、そして情報の流れを成功させる要因は何かを見つけます。

データモデリング

ビジネスモデリングフェーズで収集された情報は、ビジネスに不可欠なデータオブジェクトのセットを形成するためにレビューおよび分析されます。すべてのデータセットの属性が識別および定義されます。これらのデータオブジェクト間の関係は、ビジネスモデルに関連して詳細に確立および定義されます。

プロセスモデリング

データモデリングフェーズで定義されたデータオブジェクトセットは、ビジネスモデルに従って特定のビジネス目標を達成するために必要なビジネス情報フローを確立するために変換されます。データオブジェクトセットに対する変更または拡張のプロセスモデルは、このフェーズで定義されます。データオブジェクトを追加、削除、取得、または変更するプロセスの説明が記載されています。

アプリケーション生成

実際のシステムが構築され、コーディングが自動化ツールを使用して行われ、プロセスおよびデータモデルが実際のプロトタイプに変換されます。

テストと売上高

プロトタイプはすべての反復中に独立してテストされるため、RADモデルでは全体的なテスト時間が短縮されます。ただし、すべてのコンポーネント間のデータフローとインターフェイスは、完全なテストカバレッジで徹底的にテストする必要があります。ほとんどのプログラミングコンポーネントは既にテストされているため、重大な問題のリスクが軽減されます。

次の図は、RADモデルの詳細を示しています。

SDLC RADモデル

RADモデルと従来のSDLC

従来のSDLCは、要件分析とコーディングの開始前の収集に重点を置いた厳格なプロセスモデルに従います。プロジェクトを開始する前に要件を承認するように顧客に圧力をかけ、長時間使用可能なビルドがないため、顧客は製品の感触を得られません。

顧客は、ソフトウェアを見た後にいくつかの変更が必要になる場合があります。ただし、変更プロセスは非常に厳格であり、従来のSDLCの製品に大きな変更を組み込むことは現実的ではありません。

RADモデルは、顧客への作業モデルの反復的かつ段階的な配信に焦点を当てています。これにより、製品の開発サイクル全体で顧客への迅速な納品と顧客の関与が実現し、実際のユーザー要件に準拠しないリスクが軽減されます。

RADモデル-アプリケーション

RADモデルは、明確なモジュール化が可能なプロジェクトに正常に適用できます。プロジェクトをモジュールに分割できない場合、RADは失敗する可能性があります。

次のポインターは、RADを使用できる典型的なシナリオを説明しています-

RADは、システムをモジュール化して段階的に配信できる場合にのみ使用してください。
モデリングの設計者の可用性が高い場合に使用する必要があります。
予算が自動コード生成ツールの使用を許可している場合にのみ使用してください。
RAD SDLCモデルは、関連するビジネス知識を持つドメインエキスパートが利用可能な場合にのみ選択する必要があります。
プロジェクト中に要件が変更される場合に使用し、2〜3か月の短い反復で作業プロトタイプを顧客に提示する必要があります。

RADモデル-長所と短所

RADモデルは、コンポーネントの再利用性と並行開発により開発時間全体を短縮するため、迅速な配信を可能にします。 RADは、高度なスキルを持つエンジニアが利用可能であり、顧客が特定の時間枠内で目標とするプロトタイプを達成することを約束している場合にのみ機能します。どちらかの側にコミットメントが欠けている場合、モデルは失敗する可能性があります。

RADモデルの利点は次のとおりです-

変化する要件に対応できます。
進行状況を測定できます。
強力なRADツールを使用すると、反復時間を短くすることができます。
短時間でより少ない人数での生産性。
開発時間の短縮。
コンポーネントの再利用性が向上します。
迅速な初期レビューが行われます。
顧客からのフィードバックを促します。
統合は非常に最初から多くの統合の問題を解決します。

RADモデルの欠点は次のとおりです-

ビジネス要件を特定するための技術的に強力なチームメンバーへの依存。
RADを使用して構築できるのは、モジュール化できるシステムのみです。
非常に熟練した開発者/設計者が必要です。
モデリングスキルへの依存度が高い。
モデリングと自動コード生成のコストが非常に高いため、安価なプロジェクトには適用できません。
管理の複雑さはさらに大きくなります。
コンポーネントベースでスケーラブルなシステムに適しています。
ライフサイクル全体を通してユーザーの関与が必要です。
より短い開発時間を必要とするプロジェクトに適しています。

Sdlc-rad-model

目次