SDLC-クイックガイド

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

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

SDLCとは何ですか？

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

次の図は、一般的なSDLCのさまざまな段階をグラフで表したものです。

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

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

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

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

ステージ2：要件の定義

要件分析が完了したら、次のステップは、製品要件を明確に定義して文書化し、顧客または市場アナリストから承認を得ることです。これは、SRS (Software Requirement Specification) プロジェクトのライフサイクル中に設計および開発されるすべての製品要件で構成されるドキュメント。

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

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

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

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

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

SDLCのこの段階で、実際の開発が始まり、製品が構築されます。プログラミングコードは、この段階でDDSに従って生成されます。設計が詳細かつ組織化された方法で実行される場合、コード生成はそれほど面倒なことなく達成できます。

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

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

この段階は通常、最新のSDLCモデルと同様にすべての段階のサブセットであり、テスト活動は主にSDLCのすべての段階に関係しています。ただし、この段階とは、製品がSRSで定義された品質基準に達するまで、製品の欠陥が報告、追跡、修正、および再テストされる製品のテストのみの段階を指します。

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

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

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

SDLCモデル

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

以下は、業界で採用されている最も重要で人気のあるSDLCモデルです。

ウォーターフォールモデル
反復モデル
スパイラルモデル
V-Model
ビッグバンモデル

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

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

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

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

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

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

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

ウォーターフォールモデルの連続フェーズは次のとおりです。

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

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

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

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

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

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

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

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

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

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

ウォーターフォールモデル-デメリット

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

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

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

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

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

反復モデル-設計

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

次の図は、反復型および増分型モデルを表したものです。

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

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

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

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

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

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

反復モデル-長所と短所

このモデルの利点は、開発の非常に早い段階でシステムの動作モデルが存在することです。これにより、機能上の欠陥や設計上の欠陥を簡単に見つけることができます。開発の早い段階で問題を見つけることで、限られた予算で是正措置を講じることができます。

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

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

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

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

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

スパイラルモデルは、反復型開発のアイデアと、ウォーターフォールモデルの体系的で制御された側面を組み合わせたものです。このスパイラルモデルは、反復型開発プロセスモデルと順次線形開発モデル、つまりリスク分析に非常に重点を置いたウォーターフォールモデルを組み合わせたものです。これにより、製品の段階的なリリース、またはスパイラルの周りの各反復による段階的な改良が可能になります。

スパイラルモデル-設計

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

識別

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

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

設計

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

構築または構築

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

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

評価とリスク分析

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

次の図は、スパイラルモデルを表したもので、各フェーズのアクティビティを示しています。

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

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

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

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

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

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

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

この方法は、複数のソフトウェアビルドとリリースがあり、メンテナンスアクティビティに整然と移行できるアプローチと一致しています。この方法のもう1つの肯定的な側面は、スパイラルモデルがシステム開発作業への早期のユーザーの関与を強制することです。

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

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

変化する要件に対応できます。
プロトタイプの広範な使用を可能にします。
要件をより正確に把握できます。
ユーザーはシステムを早期に確認できます。
開発はより小さな部分に分割することができ、リスクのある部分はより早く開発することができ、より良いリスク管理に役立ちます。

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

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

VモデルはSDLCモデルであり、プロセスの実行はV字型で順次行われます。としても知られていますVerification and Validation model。

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

Vモデル-デザイン

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

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

Vモデル-検証フェーズ

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

ビジネス要件分析

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

システムデザイン

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

建築デザイン

このフェーズでは、アーキテクチャの仕様を理解して設計します。通常、複数の技術的アプローチが提案され、技術的および財政的実現可能性に基づいて最終決定が下されます。システム設計は、さまざまな機能を担うモジュールにさらに分割されます。これは、High Level Design (HLD)。

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

モジュール設計

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

コーディングフェーズ

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

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

検証フェーズ

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

ユニットテスト

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

統合テスト

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

システムテスト

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

受け入れ試験

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

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

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

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

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

Vモデル-長所と短所

V-Model方式の利点は、理解と適用が非常に簡単なことです。このモデルは単純なので、管理も簡単です。欠点は、モデルが変更に柔軟に対応できないことと、今日の動的な世界で非常に一般的な要件の変更があった場合に備えて、変更を行うのに非常に費用がかかることです。

Vモデル法の利点は次のとおりです。

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

Vモデル法のデメリットは次のとおりです。

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

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

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

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

ビッグバンモデルは、ソフトウェア開発とコーディングに可能なすべてのリソースを集中させることで構成されており、計画はほとんどまたはまったくありません。要件は理解され、必要に応じて実装されます。必要な変更は、ソフトウェア全体を刷新する必要がある場合とない場合があります。

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

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

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

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

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

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

ビッグバンモデルのデメリットは次のとおりです。

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

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

Planning
要件分析
Design
Coding
ユニットテストと
受け入れ試験。

イテレーションの最後に、機能する製品が顧客と重要な利害関係者に表示されます。

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

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

反復アプローチが採用され、各反復後に動作するソフトウェアビルドが提供されます。各ビルドは、機能に関して段階的です。最終ビルドには、お客様が必要とするすべての機能が含まれています。

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

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

最も人気のあるアジャイル手法には、Rational Unified Process（1994）、Scrum（1995）、Crystal Clear、Extreme Programming（1996）、Adaptive Software Development、Feature Driven Development、Dynamic Systems Development Method（DSDM）（1995）などがあります。これらは現在、まとめてAgile Methodologies、2001年にアジャイルマニフェストが公開された後。

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

Individuals and interactions −アジャイル開発では、コロケーションやペアプログラミングなどの相互作用と同様に、自己組織化とモチベーションが重要です。
Working software −デモ作業ソフトウェアは、単にドキュメントに依存するのではなく、顧客とのコミュニケーションの最良の手段と見なされ、顧客の要件を理解します。
Customer collaboration −さまざまな要因により、プロジェクトの開始時に要件を完全に収集することはできないため、適切な製品要件を取得するには、継続的な顧客とのやり取りが非常に重要です。
Responding to change −アジャイル開発は、変化への迅速な対応と継続的な開発に重点を置いています。

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

アジャイルはに基づいています adaptive software development methods一方、ウォーターフォールモデルのような従来のSDLCモデルは、予測アプローチに基づいています。従来のSDLCモデルの予測チームは通常、詳細な計画を立てて作業し、今後数か月または製品ライフサイクル中に提供される正確なタスクと機能を完全に予測します。

予測方法は完全に requirement analysis and planningサイクルの初めに行われます。組み込まれる変更はすべて、厳密な変更管理管理と優先順位付けを通過します。

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

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

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

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

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

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

アジャイルモデルのデメリットは次のとおりです。

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

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

Rapid Application Developmentは、ワークショップまたはフォーカスグループによる顧客の要件の収集、反復的な概念を使用した顧客によるプロトタイプの早期テスト、既存のプロトタイプ（コンポーネント）の再利用、継続的インテグレーション、および迅速な配信に重点を置いています。

RADとは何ですか？

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

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

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

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

RADモデルの設計

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

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

ビジネスモデリング

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

データモデリング

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

プロセスモデリング

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

アプリケーションの生成

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

テストと売上高

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

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

RADモデルと従来のSDLC

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

お客様は、ソフトウェアを確認した後、変更が必要になる場合があります。ただし、変更プロセスは非常に厳格であり、製品の大きな変更を従来のSDLCに組み込むことは不可能な場合があります。

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

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

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

次のポインタは、RADを使用できる一般的なシナリオを示しています。

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

RADモデル-長所と短所

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

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

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

RADモデルのデメリットは次のとおりです。

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

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

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

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

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

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

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

基本的な要件の特定

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

初期プロトタイプの開発

最初のプロトタイプはこの段階で開発され、非常に基本的な要件が示され、ユーザーインターフェイスが提供されます。これらの機能は、開発された実際のソフトウェアの内部ではまったく同じように機能しない場合があります。一方、回避策は、開発されたプロトタイプで顧客に同じルックアンドフィールを与えるために使用されます。

プロトタイプのレビュー

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

プロトタイプの改訂と強化

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

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

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

ソフトウェアプロトタイピング-タイプ

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

使い捨て/ラピッドプロトタイピング

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

進化的プロトタイピング。

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

インクリメンタルプロトタイピング

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

エクストリームプロトタイピング

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

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

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

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