SDLC-概要

ソフトウェア開発ライフサイクル（SDLC）は、ソフトウェア業界が高品質のソフトウェアを設計、開発、およびテストするために使用するプロセスです。 SDLCは、顧客の期待に応える、またはそれを超える高品質のソフトウェアを作成し、時間とコストの見積もりで完了することを目指しています。

SDLCは、ソフトウェア開発ライフサイクルの頭字語です。
ソフトウェア開発プロセスとも呼ばれます。
SDLCは、ソフトウェア開発プロセスの各ステップで実行されるタスクを定義するフレームワークです。
ISO/IEC 12207は、ソフトウェアライフサイクルプロセスの国際標準です。ソフトウェアの開発と保守に必要なすべてのタスクを定義する標準を目指しています。

SDLCとは何ですか？

SDLCは、ソフトウェア組織内のソフトウェアプロジェクトが従うプロセスです。これは、特定のソフトウェアを開発、保守、交換、および変更する方法を説明する詳細な計画で構成されています。ライフサイクルは、ソフトウェアの品質と開発プロセス全体を改善するための方法論を定義します。

次の図は、一般的なSDLCのさまざまな段階のグラフィカルな表現です。

SDLCのステージ

典型的なソフトウェア開発ライフサイクルは、次の段階で構成されています-

ステージ1：計画と要件の分析

要件分析は、SDLCで最も重要かつ基本的な段階です。これは、顧客、販売部門、市場調査、業界の専門家からの情報をもとに、チームの上級メンバーによって実行されます。次に、この情報を使用して、基本的なプロジェクトアプローチを計画し、経済的、運用的、および技術的な分野で製品の実現可能性を調査します。

品質保証要件の計画とプロジェクトに関連するリスクの特定も、計画段階で行われます。技術的実現可能性調査の結果は、最小限のリスクでプロジェクトを成功裏に実施するために従うことができるさまざまな技術的アプローチを定義することです。

ステージ2：要件の定義

要件分析が完了したら、次のステップは製品要件を明確に定義して文書化し、顧客または市場アナリストから承認を得ることです。これは、プロジェクトライフサイクル中に設計および開発されるすべての製品要件で構成される* SRS（ソフトウェア要件仕様）*文書を通じて行われます。

ステージ3：製品アーキテクチャの設計

SRSは、製品設計者が開発する製品に最適なアーキテクチャを提供するためのリファレンスです。 SRSで指定された要件に基づいて、通常、製品アーキテクチャの複数の設計アプローチが提案され、DDS-Design Document Specificationに文書化されます。

このDDSはすべての重要な利害関係者によってレビューされ、リスク評価、製品の堅牢性、設計のモジュール性、予算、時間の制約などのさまざまなパラメーターに基づいて、製品に最適な設計アプローチが選択されます。

設計アプローチでは、製品のすべてのアーキテクチャモジュールと、外部およびサードパーティモジュール（存在する場合）との通信およびデータフロー表現を明確に定義します。提案されたアーキテクチャのすべてのモジュールの内部設計は、DDSの詳細の中で最も明確に定義する必要があります。

ステージ4：製品の構築または開発

SDLCのこの段階で、実際の開発が開始され、製品が構築されます。プログラミングコードは、この段階でDDSに従って生成されます。設計が詳細かつ体系化された方法で実行される場合、コード生成はそれほど手間をかけずに達成できます。

開発者は、組織およびコンパイラ、インタープリター、デバッガーなどのプログラミングツールで定義されたコーディングガイドラインに従う必要があります。コードの生成に使用されます。 C、C ++、Pascal、Java、PHPなどのさまざまな高レベルプログラミング言語がコーディングに使用されます。プログラミング言語は、開発中のソフトウェアの種類に応じて選択されます。

ステージ5：製品のテスト

このステージは通常、現代のSDLCモデルのようにすべてのステージのサブセットであり、テスト活動はSDLCのすべてのステージにほとんど関与しています。ただし、この段階は、製品がSRSで定義された品質基準に達するまで、製品の欠陥が報告、追跡、修正、再テストされる製品のテストのみの段階を指します。

ステージ6：市場への展開とメンテナンス

製品がテストされ、展開の準備ができたら、適切な市場で正式にリリースされます。製品の展開は、その組織のビジネス戦略に従って段階的に行われる場合があります。製品は最初に限定されたセグメントでリリースされ、実際のビジネス環境でテストされます（UAT-ユーザー受け入れテスト）。

その後、フィードバックに基づいて、製品をそのままリリースするか、ターゲット市場セグメントで提案された拡張機能を使用してリリースできます。製品が市場にリリースされた後、その保守は既存の顧客ベースに対して行われます。

SDLCモデル

ソフトウェア開発プロセス中に従うさまざまなソフトウェア開発ライフサイクルモデルが定義および設計されています。これらのモデルは、ソフトウェア開発プロセスモデルとも呼ばれます。各プロセスモデルは、そのタイプに固有の一連のステップに従って、ソフトウェア開発プロセスの成功を保証します。

以下は、業界で最も重要で人気のあるSDLCモデルです-

滝モデル
反復モデル
スパイラルモデル
Vモデル
ビッグバンモデル

他の関連する方法論は、アジャイルモデル、RADモデル、ラピッドアプリケーション開発、およびプロトタイプモデルです。

SDLC-ウォーターフォールモデル

ウォーターフォールモデルは、導入された最初のプロセスモデルでした。また、*線形順次ライフサイクルモデル*とも呼ばれます。理解して使用するのは非常に簡単です。ウォーターフォールモデルでは、次のフェーズを開始する前に各フェーズを完了する必要があり、フェーズに重複はありません。

ウォーターフォールモデルは、ソフトウェア開発に使用された最も初期のSDLCアプローチです。

ウォーターフォールモデルは、線形の順次フローでソフトウェア開発プロセスを示しています。つまり、開発プロセスのすべてのフェーズは、前のフェーズが完了した場合にのみ開始されます。このウォーターフォールモデルでは、フェーズは重複しません。

ウォーターフォールモデル-デザイン

ウォーターフォールアプローチは、プロジェクトの成功を確実にするためにソフトウェアエンジニアリングで広く使用される最初のSDLCモデルでした。「ウォーターフォール」アプローチでは、ソフトウェア開発のプロセス全体が別々のフェーズに分割されます。このウォーターフォールモデルでは、通常、1つのフェーズの結果が次のフェーズの入力として順次機能します。

次の図は、ウォーターフォールモデルのさまざまなフェーズを表しています。

SDLCウォーターフォールモデル

ウォーターフォールモデルのシーケンシャルフェーズは次のとおりです-

要件の収集と分析-開発されるシステムのすべての可能な要件は、このフェーズでキャプチャされ、要件仕様書に文書化されます。
システム設計-第1フェーズの要件仕様がこのフェーズで研究され、システム設計が準備されます。このシステム設計は、ハードウェアとシステムの要件を指定し、システム全体のアーキテクチャを定義するのに役立ちます。
実装-システム設計からの入力により、システムはまずユニットと呼ばれる小さなプログラムで開発され、次のフェーズで統合されます。各ユニットは、その機能のために開発およびテストされます。これは、ユニットテストと呼ばれます。
統合とテスト-実装フェーズで開発されたすべてのユニットは、各ユニットのテスト後にシステムに統合されます。統合後、システム全体の障害と障害がテストされます。
システムの展開-機能テストと非機能テストが完了すると、製品は顧客環境に展開されるか、市場にリリースされます。
メンテナンス-クライアント環境で発生するいくつかの問題があります。これらの問題を修正するために、パッチがリリースされています。また、製品を強化するために、いくつかのより良いバージョンがリリースされています。顧客環境でこれらの変更を提供するためにメンテナンスが行われます。

これらのすべてのフェーズは相互にカスケード接続されており、進捗状況はフェーズを通じて着実に下に向かって流れるように見えます（滝のように）。次のフェーズは、定義済みの目標セットが前のフェーズで達成され、サインオフされた後にのみ開始されるため、「ウォーターフォールモデル」という名前になります。このモデルでは、フェーズは重複しません。

ウォーターフォールモデル-アプリケーション

開発されるソフトウェアはすべて異なり、内部および外部の要因に基づいて適切なSDLCアプローチに従う必要があります。ウォーターフォールモデルの使用が最も適切な状況は次のとおりです-

要件は非常によく文書化され、明確で修正されています。
製品の定義は安定しています。
技術は理解されており、動的ではありません。
あいまいな要件はありません。
製品をサポートするために必要な専門知識を備えた豊富なリソースを利用できます。
プロジェクトは短いです。

ウォーターフォールモデル-利点

ウォーターフォール開発の利点は、部門化と管理が可能なことです。開発の各段階の期限を設定してスケジュールを設定し、製品を1つずつ開発プロセスモデルフェーズに進めることができます。

開発は、概念から設計、実装、テスト、インストール、トラブルシューティングを経て、運用と保守に至ります。開発の各フェーズは厳密な順序で進行します。

ウォーターフォールモデルの主な利点のいくつかは次のとおりです-

シンプルで理解しやすく使いやすい
モデルの剛性により管理が簡単です。各フェーズには、特定の成果物とレビュープロセスがあります。
フェーズは1つずつ処理されて完了します。
要件が十分に理解されている小規模プロジェクトに適しています。
明確に定義されたステージ。
よく理解されたマイルストーン。
タスクの整理が簡単。
プロセスと結果は十分に文書化されています。

ウォーターフォールモデル-欠点

ウォーターフォール開発の欠点は、多くの反映または修正ができないことです。アプリケーションがテスト段階に入ると、概念段階で十分に文書化されていない、または考えられていないものに戻って変更することは非常に困難です。

ウォーターフォールモデルの主な欠点は次のとおりです-

ライフサイクルの後半まで動作するソフトウェアは作成されません。
大量のリスクと不確実性。
複雑でオブジェクト指向のプロジェクトには適したモデルではありません。
長く進行中のプロジェクトの貧弱なモデル。
要件が変更されるリスクが中程度から高いプロジェクトには適していません。そのため、このプロセスモデルではリスクと不確実性が高くなります。
段階内で進捗を測定することは困難です。
変化する要件に対応できません。
ライフサイクル中にスコープを調整すると、プロジェクトが終了する可能性があります。
統合は「ビッグバン」として行われます。最後に、技術的またはビジネス上のボトルネックや課題を早期に特定することはできません。

SDLC-反復モデル

反復モデルでは、反復プロセスは、ソフトウェア要件の小さなセットの単純な実装から始まり、完全なシステムが実装されてデプロイの準備ができるまで、進化するバージョンを繰り返し強化します。

反復的なライフサイクルモデルは、要件の完全な仕様から開始しようとしません。代わりに、ソフトウェアの一部のみを指定して実装することから開発を開始し、さらに要件を特定するためにレビューします。その後、このプロセスが繰り返され、モデルの各反復の最後にソフトウェアの新しいバージョンが生成されます。

反復モデル-設計

反復プロセスは、ソフトウェア要件のサブセットの単純な実装から始まり、完全なシステムが実装されるまで、進化するバージョンを繰り返し強化します。反復ごとに、設計の変更が行われ、新しい機能が追加されます。この方法の背後にある基本的な考え方は、繰り返されるサイクル（反復）と一度に小さな部分（増分）でシステムを開発することです。

次の図は、反復および増分モデルの表現です-

SDLC反復モデル

反復およびインクリメンタル開発は、反復設計または反復方法と開発用のインクリメンタルビルドモデルの両方の組み合わせです。「ソフトウェア開発中に、ソフトウェア開発サイクルの複数の反復が同時に進行している場合があります。」このプロセスは、「進化的獲得」または「インクリメンタルビルド」アプローチとして説明できます。

このインクリメンタルモデルでは、要件全体がさまざまなビルドに分割されます。各反復中に、開発モジュールは要件、設計、実装、およびテストのフェーズを通過します。モジュールの後続のリリースごとに、以前のリリースに機能が追加されます。このプロセスは、要件に従ってシステム全体の準備が整うまで続きます。

反復的なソフトウェア開発ライフサイクルを成功させるための鍵は、要件の厳密な検証と、モデルの各サイクル内の要件に対するソフトウェアの各バージョンの検証とテストです。ソフトウェアが連続したサイクルを経て進化するにつれて、テストを繰り返して拡張し、ソフトウェアの各バージョンを検証する必要があります。

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

他のSDLCモデルと同様に、反復的でインクリメンタルな開発には、ソフトウェア業界でいくつかの特定のアプリケーションがあります。このモデルは、次のシナリオで最も頻繁に使用されます-

完全なシステムの要件は明確に定義され、理解されています。
主要な要件を定義する必要があります。ただし、一部の機能または要求された拡張機能は時間とともに進化する場合があります。
市場の制約には時間があります。
新しい技術が使用されており、プロジェクトでの作業中に開発チームによって学習されています。
必要なスキルセットを持つリソースは利用できず、特定の反復に対して契約ベースで使用する予定です。
将来変更される可能性のあるいくつかの高リスク機能と目標があります。

反復モデル-長所と短所

このモデルの利点は、開発の非常に初期の段階でシステムの作業モデルがあることです。これにより、機能または設計上の欠陥を見つけやすくなります。開発の初期段階で問題を見つけることにより、限られた予算で修正措置を講じることができます。

このSDLCモデルの欠点は、大規模でかさばるソフトウェア開発プロジェクトにのみ適用できることです。これは、小さなソフトウェアシステムをさらに小さなサービス可能な増分/モジュールに分割することが難しいためです。

反復および増分SDLCモデルの利点は次のとおりです-

一部の作業機能は、ライフサイクルの早い段階で迅速に開発できます。
結果は早期に定期的に取得されます。
並行開発を計画できます。
進行状況を測定できます。
スコープ/要件を変更するための費用がかかりません。
小規模な反復中のテストとデバッグは簡単です。
リスクは反復中に特定され解決されます。そして、各反復は簡単に管理できるマイルストーンです。
リスクの管理が容易-最初にリスクの高い部分が実行されます。
すべての増分で、運用可能な製品が提供されます。
各増分から特定された問題、課題、およびリスクは、次の増分に利用/適用できます。
リスク分析が優れています。
要件の変更をサポートします。
初期稼働時間が短縮されます。
大規模でミッションクリティカルなプロジェクトに適しています。
ライフサイクル中、ソフトウェアは早期に作成され、顧客の評価とフィードバックを促進します。

反復および増分SDLCモデルの欠点は次のとおりです-

さらにリソースが必要になる場合があります。
変更のコストは低くなりますが、要件の変更にはあまり適していません。
より多くの管理上の注意が必要です。
ライフサイクル全体の最初にすべての要件が収集されるわけではないため、システムアーキテクチャまたは設計の問題が発生する可能性があります。
増分を定義するには、システム全体の定義が必要になる場合があります。
小規模なプロジェクトには適していません。
管理の複雑さはさらに大きくなります。
プロジェクトの終わりがわからない可能性があり、これはリスクです。
リスク分析には高度なスキルを持つリソースが必要です。
プロジェクトの進行は、リスク分析フェーズに大きく依存しています。

SDLC-スパイラルモデル

スパイラルモデルは、反復開発のアイデアと、ウォーターフォールモデルの体系的で制御された側面を組み合わせたものです。このスパイラルモデルは、反復開発プロセスモデルとシーケンシャルリニア開発モデルの組み合わせです。リスク分析を非常に重視したウォーターフォールモデル。これにより、製品の段階的なリリースまたはスパイラルの各反復を通じて段階的な改良が可能になります。

スパイラルモデル-設計

スパイラルモデルには4つのフェーズがあります。ソフトウェアプロジェクトは、スパイラルと呼ばれる反復でこれらのフェーズを繰り返し通過します。

識別

このフェーズは、ベースラインスパイラルでビジネス要件を収集することから始まります。製品の成熟に伴うその後のスパイラルでは、システム要件、サブシステム要件、およびユニット要件の特定はすべてこのフェーズで行われます。

このフェーズには、顧客とシステムアナリスト間の継続的なコミュニケーションによるシステム要件の理解も含まれます。スパイラルの終わりに、製品は特定された市場に展開されます。

設計

設計段階は、ベースラインスパイラルの概念設計から始まり、アーキテクチャ設計、モジュールの論理設計、物理的な製品設計、および後続のスパイラルの最終設計が含まれます。

構築または構築

構築フェーズは、スパイラルごとの実際のソフトウェア製品の生産を指します。ベースラインスパイラルでは、製品が考えられ、デザインが開発されているとき、顧客からのフィードバックを得るために、このフェーズでPOC（概念実証）が開発されます。

次に、要件と設計の詳細をより明確にした後続のスパイラルで、ビルドと呼ばれるソフトウェアの作業モデルがバージョン番号とともに生成されます。これらのビルドは、フィードバックのためにお客様に送信されます。

評価とリスク分析

リスク分析には、スケジュールのずれやコスト超過などの技術的実現可能性と管理リスクの特定、推定、監視が含まれます。ビルドをテストした後、最初の反復の最後に、顧客はソフトウェアを評価し、フィードバックを提供します。

次の図は、スパイラルモデルを表しており、各フェーズのアクティビティをリストしています。

SDLCスパイラルモデル

顧客の評価に基づいて、ソフトウェア開発プロセスは次の反復に入り、その後線形アプローチに従って顧客から提案されたフィードバックを実装します。スパイラルに沿った反復のプロセスは、ソフトウェアの寿命を通して続きます。

スパイラルモデルアプリケーション

スパイラルモデルは、あらゆる製品の自然な開発プロセスと同期しているため、ソフトウェア業界で広く使用されています。顧客と開発会社のリスクを最小限に抑える成熟度の学習。

次のポインタは、スパイラルモデルの一般的な使用法を説明します-

予算の制約があり、リスク評価が重要な場合。
中リスクから高リスクのプロジェクト向け。
要件が時間とともに変化するため、経済的優先順位が変更される可能性があるため、長期的なプロジェクトのコミットメント
顧客は通常そうである彼らの要件を確信していません。
要件は複雑で、明確にするために評価が必要です。
十分な顧客フィードバックを得るために段階的にリリースされるべき新しい製品ライン。
開発サイクル中に製品に大幅な変更が予想されます。

スパイラルモデル-長所と短所

スパイラルライフサイクルモデルの利点は、製品の要素が利用可能または既知になったときに追加できることです。これにより、以前の要件および設計との競合がないことが保証されます。

この方法は、複数のソフトウェアビルドとリリースを使用するアプローチと一貫性があり、メンテナンスアクティビティへの規則的な移行を可能にします。この方法のもう1つの利点は、スパイラルモデルがシステム開発の取り組みにユーザーの早期関与を強いることです。

一方、そのような製品を完成させるには非常に厳密な管理が必要であり、無限ループでスパイラルを実行するリスクがあります。そのため、製品の開発と展開を成功させるには、変更の規律と変更要求の範囲が非常に重要です。

スパイラルSDLCモデルの利点は次のとおりです-

変化する要件に対応できます。
プロトタイプを広範囲に使用できます。
要件をより正確にキャプチャできます。
ユーザーはシステムを早く見ます。
開発はより小さな部分に分割でき、リスクの高い部分はより早く開発できるため、リスク管理の改善に役立ちます。

スパイラルSDLCモデルの欠点は次のとおりです-

管理はより複雑です。
プロジェクトの終わりは、早期に知られていない可能性があります。
小規模または低リスクのプロジェクトには適さず、小規模プロジェクトには費用がかかる可能性があります。
プロセスは複雑です
スパイラルは無期限に続く可能性があります。
多数の中間段階では、過度のドキュメントが必要です。

SDLC-Vモデル

Vモデルは、プロセスの実行がVシェイプで連続的に発生するSDLCモデルです。 *検証と検証モデル*とも呼ばれます。

Vモデルはウォーターフォールモデルの拡張であり、対応する各開発段階のテストフェーズの関連付けに基づいています。これは、開発サイクルの各フェーズごとに、直接関連付けられたテストフェーズがあることを意味します。これは高度に規律化されたモデルであり、次のフェーズは前のフェーズの完了後にのみ開始されます。

Vモデル-デザイン

Vモデルの下では、開発フェーズの対応するテストフェーズが並行して計画されます。そのため、「V」の一方には検証フェーズがあり、もう一方には検証フェーズがあります。コーディングフェーズは、Vモデルの2つの側面を結合します。

次の図は、SDLCのVモデルのさまざまなフェーズを示しています。

SDLC V-Model

Vモデル-検証フェーズ

Vモデルにはいくつかの検証フェーズがあり、それぞれについて以下で詳しく説明します。

ビジネス要件分析

これは開発サイクルの最初のフェーズであり、製品の要件が顧客の観点から理解されます。このフェーズでは、顧客との詳細なコミュニケーションを行い、顧客の期待と正確な要件を理解します。これは非常に重要なアクティビティであり、ほとんどの顧客は正確に何が必要かわからないため、適切に管理する必要があります。ビジネス要件を受け入れテストの入力として使用できるため、*受け入れテスト設計計画*はこの段階で行われます。

システム設計

明確で詳細な製品要件を取得したら、完全なシステムを設計します。システム設計には、開発中の製品の完全なハードウェアおよび通信セットアップの理解と詳細が含まれます。システムテスト計画は、システム設計に基づいて作成されます。より早い段階でこれを行うと、後で実際のテストを実行する時間が長くなります。

建築デザイン

アーキテクチャ仕様は、このフェーズで理解および設計されます。通常、複数の技術的アプローチが提案され、技術的および財務的な実現可能性に基づいて最終決定が行われます。システム設計は、さまざまな機能を使用するモジュールにさらに分割されます。これは、* High Level Design（HLD）*とも呼ばれます。

内部モジュール間および外部世界（他のシステム）とのデータ転送および通信は、この段階で明確に理解および定義されています。この情報を使用して、この段階で統合テストを設計および文書化できます。

モジュール設計

この段階では、すべてのシステムモジュールの詳細な内部設計が指定され、*低レベル設計（LLD）*と呼ばれます。設計がシステムアーキテクチャの他のモジュールおよび他の外部システムと互換性があることが重要です。単体テストは開発プロセスの重要な部分であり、非常に早い段階で最大の障害とエラーを排除するのに役立ちます。これらの単体テストは、内部モジュールの設計に基づいて、この段階で設計できます。

コーディング段階

設計段階で設計されたシステムモジュールの実際のコーディングは、コーディング段階で行われます。システムとアーキテクチャの要件に基づいて、最適なプログラミング言語が決定されます。

コーディングは、コーディングのガイドラインと標準に基づいて実行されます。コードは多数のコードレビューを経て、最終ビルドがリポジトリにチェックインされる前に最高のパフォーマンスが得られるように最適化されます。

検証フェーズ

Vモデルのさまざまな検証フェーズについて、以下で詳しく説明します。

単体テスト

モジュール検証段階で設計された単体テストは、この検証段階でコードに対して実行されます。ユニットテストはコードレベルでのテストであり、バグを早期に排除するのに役立ちますが、ユニットテストではすべての欠陥を発見することはできません。

統合テスト

統合テストは、アーキテクチャ設計段階に関連付けられています。統合テストは、システム内の内部モジュールの共存と通信をテストするために実行されます。

システムテスト

システムのテストは、システムの設計段階に直接関連付けられています。システムテストは、システム全体の機能と、開発中のシステムと外部システムとの通信をチェックします。このシステムテストの実行中に、ソフトウェアとハードウェアの互換性の問題のほとんどが明らかになります。

受け入れ試験

受け入れテストはビジネス要件分析フェーズに関連付けられており、ユーザー環境での製品のテストが含まれます。受け入れテストは、ユーザー環境で利用可能な他のシステムとの互換性の問題を明らかにします。また、実際のユーザー環境での負荷やパフォーマンスの欠陥など、機能しない問題も検出します。

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

V-Modelアプリケーションは、両方のモデルがシーケンシャルタイプであるため、ウォーターフォールモデルとほぼ同じです。プロジェクトを開始する前に、要件を明確にする必要があります。通常、戻って変更を加えるのは費用がかかるためです。このモデルは、厳密に統制されたドメインであるため、医療開発分野で使用されます。

以下のポインターは、V-Modelアプリケーションを使用するのに最も適したシナリオの一部です。

要件は明確に定義され、明確に文書化され、修正されています。
製品の定義は安定しています。
技術は動的ではなく、プロジェクトチームがよく理解しています。
あいまいな要件や未定義の要件はありません。
プロジェクトは短いです。

Vモデル-長所と短所

V-Modelメソッドの利点は、理解と適用が非常に簡単なことです。このモデルのシンプルさにより、管理も容易になります。欠点は、モデルが変更に対して柔軟ではないことと、今日のダイナミックな世界で非常に一般的な要件の変更がある場合に、変更を行うのに非常に費用がかかることです。

V-Modelメソッドの利点は次のとおりです-

これは高度に規律化されたモデルであり、フェーズは1つずつ完了します。
要件が十分に理解されている小規模プロジェクトに適しています。
シンプルで理解しやすく使いやすい。
モデルの剛性により管理が簡単です。各フェーズには、特定の成果物とレビュープロセスがあります。

V-Modelメソッドの欠点は次のとおりです-

高いリスクと不確実性。
複雑でオブジェクト指向のプロジェクトには適したモデルではありません。
長く進行中のプロジェクトの貧弱なモデル。
要件が変更されるリスクが中程度から高いプロジェクトには適していません。
アプリケーションがテスト段階に入ると、戻って機能を変更することは困難です。
ライフサイクルの後半まで動作するソフトウェアは作成されません。

SDLC-ビッグバンモデル

Big Bangモデルは、特定のプロセスに従わないSDLCモデルです。開発は、必要な資金と労力を入力として開始するだけで、出力は開発されたソフトウェアであり、顧客の要件に応じて、またはそうでない場合があります。このビッグバンモデルはプロセス/手順に従っていないため、計画はほとんど必要ありません。顧客でさえ、自分が何を望んでいるのか正確にはわからず、要件は多くの分析なしにその場で実装されます。

通常、このモデルは、開発チームが非常に小さい小規模プロジェクトで使用されます。

ビッグバンモデル─設計と応用

ビッグバンモデルは、ソフトウェア開発とコーディングで考えられるすべてのリソースに焦点を当てることで構成され、計画はほとんど、またはまったくありません。要件は理解されて、実装されます。必要な変更は、完全なソフトウェアを修正する必要がある場合とない場合があります。

このモデルは、1人または2人の開発者が一緒に作業する小規模なプロジェクトに最適であり、学術プロジェクトや実践プロジェクトにも役立ちます。要件が十分に理解されておらず、最終リリース日が示されていない製品にとって理想的なモデルです。

ビッグバンモデル-長所と短所

このビッグバンモデルの利点は、非常に単純であり、計画をほとんどまたはまったく必要としないことです。管理が簡単で、正式な手順は不要です。

ただし、ビッグバンモデルは非常にリスクの高いモデルであり、要件の変更や要件の誤解により、プロジェクトが完全に取り消されたり、スクレイピングされたりする可能性さえあります。リスクが最小の反復プロジェクトまたは小規模プロジェクトに最適です。

ビッグバンモデルの利点は次のとおりです-

これは非常に単純なモデルです
計画はほとんどまたはまったく必要ありません
管理が簡単
必要なリソースは非常に少ない
開発者に柔軟性を与えます
それは、新参者や学生にとって良い学習補助です。

ビッグバンモデルの欠点は次のとおりです-

非常に高いリスクと不確実性。
複雑でオブジェクト指向のプロジェクトには適したモデルではありません。
長く進行中のプロジェクトの貧弱なモデル。
要件が誤解されている場合、非常に高価になることがあります。

SDLC-アジャイルモデル

アジャイルSDLCモデルは、反復および増分プロセスモデルの組み合わせであり、動作中のソフトウェア製品を迅速に提供することにより、プロセスの適応性と顧客満足に焦点を当てています。アジャイルメソッドは、製品を小さなインクリメンタルビルドに分割します。これらのビルドは反復で提供されます。通常、各反復は約1〜3週間続きます。すべての反復には、次のようなさまざまな分野で同時に機能するクロスファンクショナルチームが含まれます-

計画中
要件分析
設計
コーディング
ユニットテストと
受け入れ試験。

反復の最後に、動作中の製品が顧客と重要な利害関係者に表示されます。

アジャイルとは何ですか？

アジャイルモデルは、すべてのプロジェクトを異なる方法で処理する必要があり、既存の方法をプロジェクト要件に最適に調整する必要があると考えています。アジャイルでは、リリースに特定の機能を提供するために、タスクがタイムボックス（小さなタイムフレーム）に分割されます。

反復的なアプローチが取られ、各反復後に機能するソフトウェアビルドが提供されます。各ビルドは、機能の面でインクリメンタルです。最終ビルドには、顧客が必要とするすべての機能が含まれています。

これはアジャイルモデルの図解です-

SDLCアジャイルモデル

アジャイル思考プロセスは、ソフトウェア開発の初期段階で開始され、その柔軟性と適応性により、時間とともに普及し始めました。

最も一般的なアジャイル手法には、Rational Unified Process（1994）、Scrum（1995）、Crystal Clear、Extreme Programming（1996）、Adaptive Software Development、Feature Driven Development、Dynamic Systems Development Method（DSDM）（1995）などがあります。 2001年にアジャイルマニフェストが公開された後、これらは*アジャイル方法論*と総称されるようになりました。

以下はアジャイルマニフェストの原則です-

個人と相互作用-アジャイル開発では、自己組織化と動機付けが重要であり、コロケーションやペアプログラミングなどの相互作用も重要です。
ワーキングソフトウェア-デモワーキングソフトウェアは、単にドキュメントに依存するのではなく、要件を理解するための顧客とのコミュニケーションの最良の手段と見なされます。
顧客コラボレーション-さまざまな要因によりプロジェクトの最初に要件を完全に収集できないため、適切な製品要件を取得するには、継続的な顧客との対話が非常に重要です。
変化への対応-アジャイル開発は、変化への迅速な対応と継続的な開発に焦点を当てています。

アジャイルと従来のSDLCモデル

アジャイルは*適応型ソフトウェア開発手法*に基づいていますが、ウォーターフォールモデルのような従来のSDLCモデルは予測的アプローチに基づいています。従来のSDLCモデルの予測チームは通常、詳細な計画を立てて作業し、今後数か月または製品ライフサイクル中に提供される正確なタスクと機能の完全な予測を行います。

予測方法は、サイクルの最初に行われる*要件分析と計画*に完全に依存します。組み込まれるすべての変更は、厳密な変更管理と優先順位付けを通過します。

アジャイルは、*詳細な計画がなく、どの機能を開発する必要があるかに関してのみ将来のタスクを明確にする*適応アプローチ*を使用します。機能駆動型の開発があり、チームは変化する製品要件に動的に適応します。製品は、リリースの繰り返しを通じて非常に頻繁にテストされ、将来の重大な障害のリスクを最小限に抑えます。

カスタマーインタラクション*はこのアジャイル手法のバックボーンであり、最小限のドキュメントでのオープンなコミュニケーションがアジャイル開発環境の典型的な機能です。アジャイルチームは互いに緊密に連携して作業し、ほとんどの場合、同じ地理的場所に配置されます。

アジャイルモデル-長所と短所

アジャイル手法は、最近ソフトウェアの世界で広く受け入れられています。ただし、この方法は必ずしもすべての製品に適しているとは限りません。アジャイルモデルの長所と短所を次に示します。

アジャイルモデルの利点は次のとおりです-

ソフトウェア開発への非常に現実的なアプローチです。
チームワークとクロストレーニングを促進します。
機能を迅速に開発して実証することができます。
リソース要件は最小限です。
固定要件または変化する要件に適しています
初期の部分作業ソリューションを提供します。
着実に変化する環境に適したモデル。
最小限のルール、簡単に使用できるドキュメント。
計画された全体的なコンテキスト内で同時開発と配信を可能にします。
計画はほとんど、またはまったく必要ありません。
管理が簡単。
開発者に柔軟性を与えます。

アジャイルモデルの欠点は次のとおりです-

複雑な依存関係の処理には適していません。
持続可能性、保守性、および拡張性のリスクが増加します。
全体的な計画、アジャイルリーダー、アジャイルPMプラクティスは必須であり、それなしでは機能しません。
厳密な配信管理により、配信範囲、配信される機能、および期限に合わせた調整が決まります。
顧客とのやり取りに大きく依存しているため、顧客が明確でない場合、チームは間違った方向に進む可能性があります。
最小限のドキュメントが生成されるため、非常に高い個人依存性があります。
ドキュメントの不足により、新しいチームメンバーへの技術の移転は非常に困難な場合があります。

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-ソフトウェアプロトタイプモデル

ソフトウェアプロトタイプとは、開発中の製品の機能を表示するソフトウェアアプリケーションプロトタイプを構築することを指しますが、実際には元のソフトウェアの正確なロジックを保持していない場合があります。

ソフトウェアプロトタイピングは、開発の初期段階で顧客の要件を理解できるため、ソフトウェア開発モデルとして非常に人気が高まっています。これは、顧客から貴重なフィードバックを得るのに役立ち、ソフトウェア設計者と開発者が開発中の製品に正確に期待されることについて理解するのに役立ちます。

ソフトウェアプロトタイプとは何ですか？

プロトタイプは、機能が制限されたソフトウェアの実用モデルです。プロトタイプは、実際のソフトウェアアプリケーションで使用される正確なロジックを常に保持しているわけではなく、労力の見積もりの下で検討するための余分な労力です。

プロトタイプを使用して、ユーザーが開発者の提案を評価し、実装前に試してみることができます。また、ユーザー固有の要件であり、製品設計時に開発者が考慮していない可能性がある要件を理解するのにも役立ちます。

以下は、ソフトウェアのプロトタイプを設計するために説明される段階的なアプローチです。

基本的な要件の特定

この手順では、特にユーザーインターフェイスの観点から、非常に基本的な製品要件を理解する必要があります。この段階では、内部設計とパフォーマンスやセキュリティなどの外部の側面のより複雑な詳細は無視できます。

初期プロトタイプの開発

初期のプロトタイプはこの段階で開発され、非常に基本的な要件が示され、ユーザーインターフェイスが提供されます。これらの機能は、開発された実際のソフトウェアで内部的に同じ方法で正確に機能しない場合があります。一方、回避策は、開発したプロトタイプで同じ外観を顧客に提供するために使用されます。

プロトタイプのレビュー

開発されたプロトタイプは、顧客およびプロジェクトの他の重要な利害関係者に提示されます。フィードバックは体系的に収集され、開発中の製品のさらなる機能強化に使用されます。

プロトタイプの修正と強化

フィードバックとレビューコメントはこの段階で議論され、時間と予算の制約、実際の実装の技術的実現可能性などの要因に基づいて、顧客といくつかの交渉が行われます。受け入れられた変更は、開発された新しいプロトタイプに再び組み込まれ、顧客の期待に応えるまでサイクルが繰り返されます。

プロトタイプは、水平または垂直の寸法を持つことができます。水平プロトタイプは、製品のユーザーインターフェイスを表示し、内部機能に集中することなく、システム全体をより広く表示します。反対側の垂直プロトタイプは、製品の特定の機能またはサブシステムの詳細な精緻化です。

水平プロトタイプと垂直プロトタイプの両方の目的は異なります。水平プロトタイプは、ユーザーインターフェイスレベルとビジネス要件に関する詳細情報を取得するために使用されます。市場でビジネスを獲得するために、販売デモで提示することもできます。垂直プロトタイプは本質的に技術的であり、サブシステムの正確な機能の詳細を取得するために使用されます。たとえば、特定のサブシステムでのデータベース要件、相互作用、データ処理の負荷。

ソフトウェアプロトタイプ-タイプ

業界ではさまざまな種類のソフトウェアプロトタイプが使用されています。以下は、広く使用されている主要なソフトウェアプロトタイプタイプです。

スローアウェイ/ラピッドプロトタイピング

使い捨てのプロトタイピングは、ラピッドまたはクローズエンドのプロトタイピングとも呼ばれます。このタイプのプロトタイピングでは、最小限の要件分析でほとんど労力をかけずにプロトタイプを作成します。実際の要件が理解されると、プロトタイプは破棄され、ユーザーの要件を明確に理解して実際のシステムが開発されます。

進化的プロトタイピング

ブレッドボードプロトタイプとも呼ばれる進化的プロトタイプは、最初は最小限の機能で実際の機能プロトタイプを構築することに基づいています。開発されたプロトタイプは、システム全体が構築される将来のプロトタイプの中心となります。進化的プロトタイピングを使用することにより、十分に理解されている要件がプロトタイプに含まれ、要件が理解されたときに追加されます。

増分プロトタイピング

インクリメンタルプロトタイプとは、さまざまなサブシステムの複数の機能プロトタイプを構築し、利用可能なすべてのプロトタイプを統合して完全なシステムを形成することです。

極端なプロトタイピング

極端なプロトタイピングは、Web開発ドメインで使用されます。 3つの連続したフェーズで構成されます。最初に、既存のすべてのページを含む基本的なプロトタイプがHTML形式で表示されます。次に、プロトタイプサービスレイヤーを使用してデータ処理をシミュレートします。最後に、サービスが実装され、最終プロトタイプに統合されます。このプロセスはエクストリームプロトタイピングと呼ばれ、プロセスの第2段階に注意を引くために使用されます。この段階では、実際のサービスをほとんど考慮せずに完全に機能するUIが開発されます。

ソフトウェアプロトタイプ-アプリケーション

ソフトウェアプロトタイプは、オンラインシステムなど、ユーザーとのやり取りが多いシステムの開発に最も役立ちます。データを処理する前にユーザーがフォームに記入するか、さまざまな画面を表示する必要があるシステムは、実際のソフトウェアが開発される前でも、プロトタイプを非常に効果的に使用して正確なルックアンドフィールを提供できます。

データ処理が多すぎ、ほとんどの機能が内部にあり、ユーザーインターフェイスがほとんどないソフトウェアは、通常、プロトタイピングの恩恵を受けません。プロトタイプ開発は、そのようなプロジェクトでは余分なオーバーヘッドになる可能性があり、多くの追加の努力が必要になる場合があります。

ソフトウェアのプロトタイピング-長所と短所

ソフトウェアプロトタイプは典型的な場合に使用され、プロトタイプの構築に費やされた努力が開発された最終ソフトウェアにかなりの価値を追加するように、決定は非常に慎重に行われるべきです。このモデルには、次のような長所と短所があります。

プロトタイプモデルの利点は次のとおりです-

製品の実装前であっても、製品へのユーザーの関与が増加しました。
システムの作業モデルが表示されるため、ユーザーは開発中のシステムをよりよく理解できます。
欠陥をより早く検出できるため、時間とコストが削減されます。
より迅速なユーザーフィードバックが利用可能であり、より良いソリューションにつながります。
欠落している機能は簡単に特定できます。
混乱した機能や困難な機能を特定できます。

プロトタイプモデルの欠点は次のとおりです-

プロトタイプへの依存が多すぎるため、要件分析が不十分になるリスク。
ユーザーは、プロトタイプと実際のシステムで混乱する可能性があります。
実際には、システムの範囲が元の計画を超えて拡大する可能性があるため、この方法論によりシステムの複雑さが増す可能性があります。
開発者は、技術的に実行可能でない場合でも、既存のプロトタイプを再利用して実際のシステムを構築しようとする場合があります。
プロトタイプを適切に監視しないと、プロトタイプの構築に費やした労力が多すぎます。

Sdlc-quick-guide