sdlc phases
ソフトウェア開発ライフサイクル（SDLC）とは何ですか？ SDLCのフェーズ、方法論、プロセス、およびモデルを学ぶ
ソフトウェア開発ライフサイクル（SDLC）は、各フェーズでソフトウェアの開発に関連するステップを定義するフレームワークです。ソフトウェアの構築、展開、および保守に関する詳細な計画について説明します。
SDLCは、開発の完全なサイクル、つまりソフトウェア製品の計画、作成、テスト、および展開に関連するすべてのタスクを定義します。
学習内容：
ソフトウェア開発ライフサイクルプロセス
SDLCは、高品質の製品を提供するためのソフトウェアの開発に関連するさまざまな段階を定義するプロセスです。 SDLCステージは、ソフトウェアのライフサイクル全体、つまり製品の開始から廃棄までをカバーします。
SDLCプロセスを順守することで、体系的かつ統制のとれた方法でソフトウェアを開発できます。
目的：
SDLCの目的は、お客様の要求に応じた高品質の製品を提供することです。
SDLCは、そのフェーズを、要件の収集、設計、コーディング、テスト、および保守として定義しています。体系的な方法で製品を提供するために、フェーズを順守することが重要です。
例えば、 ソフトウェアを開発する必要があり、チームは製品の機能に取り組むために分割され、彼らが望むように働くことができます。開発者の1人は最初に設計することを決定し、もう1人は最初にコーディングすることを決定し、もう1人はドキュメント部分でコーディングします。
これはプロジェクトの失敗につながります。そのため、期待される製品を提供するには、チームメンバー間で十分な知識と理解を持っている必要があります。
SDLCサイクル
SDLCサイクルは、ソフトウェアを開発するプロセスを表しています。
以下は、SDLCサイクルの図式表現です。
SDLCフェーズ
以下に、さまざまなフェーズを示します。
- 要件の収集と分析
- 設計
- 実装またはコーディング
- テスト
- 展開
- メンテナンス
＃1）要件の収集と分析
このフェーズでは、すべての関連情報が顧客から収集され、顧客の期待どおりに製品が開発されます。あいまいさは、このフェーズでのみ解決する必要があります。
ビジネスアナリストとプロジェクトマネージャーは、顧客とのミーティングを設定して、顧客が構築したいもの、エンドユーザーになる人、製品の目的などのすべての情報を収集します。製品を構築する前に、製品のコア理解または知識が非常に重要です。
例えば、 顧客は、金銭取引を伴うアプリケーションを望んでいます。この場合、どのような種類の取引が行われるか、どのように行われるか、どの通貨で行われるかなど、要件を明確にする必要があります。
要件の収集が完了すると、製品の開発の実現可能性を確認するための分析が行われます。あいまいな場合は、さらに話し合うための電話が設定されます。
要件が明確に理解されると、SRS（ソフトウェア要件仕様）ドキュメントが作成されます。このドキュメントは、開発者が完全に理解し、将来の参照のために顧客が確認する必要があります。
＃2）デザイン
このフェーズでは、SRSドキュメントで収集された要件が入力として使用され、システム開発の実装に使用されるソフトウェアアーキテクチャが導出されます。
＃3）実装またはコーディング
開発者が設計ドキュメントを入手すると、実装/コーディングが開始されます。ソフトウェアの設計はソースコードに翻訳されています。ソフトウェアのすべてのコンポーネントは、このフェーズで実装されます。
経験豊富なモバイルテスト面接の質問と回答
＃4）テスト
コーディングが完了し、モジュールがテスト用にリリースされると、テストが開始されます。このフェーズでは、開発されたソフトウェアが徹底的にテストされ、見つかった欠陥があれば開発者に割り当てられて修正されます。
再テスト、回帰テストは、ソフトウェアがお客様の期待どおりになるまで行われます。テスターはSRSドキュメントを参照して、ソフトウェアがお客様の標準に準拠していることを確認します。
＃5）展開
製品がテストされると、本番環境または最初に展開されます UAT（ユーザー受け入れテスト） 顧客の期待に応じて行われます。
UATの場合、本番環境のレプリカが作成され、開発者とともに顧客がテストを行います。顧客が期待どおりにアプリケーションを見つけた場合、顧客はサインオフを提供して公開します。
＃6）メンテナンス
製品を本番環境にデプロイした後、製品のメンテナンス、つまり問題が発生して修正が必要になった場合、または拡張を行う必要がある場合は、開発者が対応します。
ソフトウェア開発ライフサイクルモデル
ソフトウェアライフサイクルモデルは、ソフトウェア開発サイクルを説明するものです。 SDLCモデルのアプローチは異なる場合がありますが、基本的なフェーズとアクティビティはすべてのモデルで同じです。
＃1）ウォーターフォールモデル
ウォーターフォールモデル SDLCで使用される最初のモデルです。線形シーケンシャルモデルとも呼ばれます。
このモデルでは、あるフェーズの結果が次のフェーズの入力になります。次のフェーズの開発は、前のフェーズが完了したときにのみ開始されます。
- まず、要件の収集と分析が行われます。要件が凍結されると、システム設計のみを開始できます。ここで、作成されたSRSドキュメントは、要件フェーズの出力であり、システム設計の入力として機能します。
- システム設計ソフトウェアアーキテクチャと設計では、次のフェーズ、つまり実装とコーディングの入力として機能するドキュメントが作成されます。
- 実装フェーズでは、コーディングが行われ、開発されたソフトウェアが次のフェーズ、つまりテストの入力になります。
- テストフェーズでは、開発されたコードを徹底的にテストして、ソフトウェアの欠陥を検出します。欠陥は欠陥追跡ツールに記録され、修正されると再テストされます。バグログ、再テスト、回帰テストは、ソフトウェアが稼働状態になるまで続きます。
- 展開フェーズでは、顧客がサインオフした後、開発されたコードが本番環境に移行されます。
- 実稼働環境の問題は、メンテナンス中の開発者によって解決されます。
ウォーターフォールモデルの利点：
- ウォーターフォールモデルは、簡単に理解できる単純なモデルであり、すべてのフェーズが段階的に実行されるモデルです。
- 各フェーズの成果物は明確に定義されており、これにより複雑さがなくなり、プロジェクトを簡単に管理できるようになります。
ウォーターフォールモデルのデメリット：
- ウォーターフォールモデルは時間がかかり、短期間のプロジェクトでは使用できません。このモデルでは、進行中のフェーズが完了するまで新しいフェーズを開始できません。
- ウォーターフォールモデルは、要件が不確実なプロジェクトや、要件が変化し続けるプロジェクトには使用できません。このモデルでは、要件の収集と分析のフェーズ自体で要件が明確であることが期待され、後の段階で変更を加えると、コストが高くなるためです。すべてのフェーズで変更が必要になります。
＃2）V字型モデル
Vモデル 検証および妥当性確認モデルとも呼ばれます。このモデルでは、検証と妥当性確認は密接に関連しています。つまり、開発とテストは並行して行われます。 Vモデルとウォーターフォールモデルは、テスト計画とテストがVモデルの初期段階で開始されることを除いて同じです。
a）検証フェーズ：
（i）要件分析：
このフェーズでは、必要なすべての情報が収集および分析されます。検証アクティビティには、要件のレビューが含まれます。
（ii）システム設計：
要件が明確になると、システムが設計されます。つまり、アーキテクチャ、製品のコンポーネントが作成され、設計ドキュメントに文書化されます。
（iii）高レベルの設計：
高レベルの設計は、モジュールのアーキテクチャ/設計を定義します。 2つのモジュール間の機能を定義します。
（iv）低レベルの設計：
低レベル設計は、個々のコンポーネントのアーキテクチャ/設計を定義します。
（v）コーディング：
コード開発はこのフェーズで行われます。
b）検証フェーズ：
（i）ユニットテスト：
ユニットテスト 設計され、低レベルの設計フェーズで実行される単体テストケースを使用して実行されます。ユニットテストは開発者自身が実行します。これは、早期の欠陥検出につながる個々のコンポーネントに対して実行されます。
（ii）統合テスト：
統合テスト 高レベルの設計フェーズで統合テストケースを使用して実行されます。統合テストは、統合モジュールで実行されるテストです。テスターによって実行されます。
（iii）システムテスト：
システムテスト システム設計フェーズで実行されます。このフェーズでは、システム全体がテストされます。つまり、システム全体の機能がテストされます。
（iv）検収試験：
受け入れテストは、要件分析フェーズに関連付けられており、お客様の環境で実行されます。
Vの利点–モデル：
- シンプルでわかりやすいモデルです。
- Vモデルのアプローチは、要件が定義され、初期段階でフリーズする小規模なプロジェクトに適しています。
- それは、高品質の製品をもたらす体系的で統制のとれたモデルです。
Vモデルのデメリット：
- V字型モデルは進行中のプロジェクトには適していません。
- 後の段階での要件の変更は、コストが高すぎます。
＃3）プロトタイプモデル
プロトタイプモデルは、実際のソフトウェアの前にプロトタイプが開発されたモデルです。
プロトタイプモデルは、実際のソフトウェアと比較した場合、機能機能が制限され、パフォーマンスが非効率的です。ダミー関数は、プロトタイプを作成するために使用されます。これは、お客様のニーズを理解するための貴重なメカニズムです。
ソフトウェアのプロトタイプは、実際のソフトウェアの前に作成され、顧客から貴重なフィードバックを得ます。フィードバックが実装され、プロトタイプは変更がないかお客様によって再度確認されます。このプロセスは、モデルが顧客に受け入れられるまで続きます。
要件の収集が完了すると、クイックデザインが作成され、評価のために顧客に提示されるプロトタイプが作成されます。
顧客のフィードバックと洗練された要件は、プロトタイプを変更するために使用され、評価のために再び顧客に提示されます。お客様がプロトタイプを承認すると、実際のソフトウェアを構築するための要件として使用されます。実際のソフトウェアは、ウォーターフォールモデルアプローチを使用して構築されています。
プロトタイプモデルの利点：
- プロトタイプモデルは、欠陥がはるかに早く発見されるため、開発のコストと時間を削減します。
- 不足している機能や機能、または要件の変更は、評価フェーズで特定でき、洗練されたプロトタイプに実装できます。
- 初期段階から顧客を関与させることで、機能の要件や理解における混乱を減らすことができます。
プロトタイプモデルのデメリット：
- 顧客はすべてのフェーズに関与しているため、顧客は最終製品の要件を変更できます。これにより、スコープが複雑になり、製品の納期が長くなる可能性があります。
＃4）スパイラルモデル
スパイラルモデル 反復およびプロトタイプアプローチが含まれます。
反復では、スパイラルモデルのフェーズが続きます。モデルのループは、SDLCプロセスのフェーズを表します。つまり、最も内側のループは、計画、リスク分析、開発、および評価に続く要件の収集と分析です。次のループは、設計、実装、テストです。
スパイラルモデルには4つのフェーズがあります。
- 計画
- リスク分析
- エンジニアリング
- 評価
（i）計画：
計画段階には、必要なすべての情報が顧客から収集され、文書化される要件収集が含まれます。ソフトウェア要件仕様書は、次のフェーズのために作成されます。
（ii）リスク分析：
このフェーズでは、関連するリスクに対して最適なソリューションが選択され、プロトタイプを作成して分析が行われます。
例えば 、リモートデータベースからのデータへのアクセスに伴うリスクは、データアクセス速度が遅すぎる可能性があることです。リスクは、データアクセスサブシステムのプロトタイプを作成することで解決できます。
（iii）エンジニアリング：
リスク分析が完了すると、コーディングとテストが行われます。
（iv）評価：
お客様は、開発されたシステムを評価し、次の反復を計画します。
スパイラルモデルの利点：
- リスク分析は、プロトタイプモデルを使用して広範囲にわたって行われます。
- 機能の拡張または変更は、次の反復で行うことができます。
スパイラルモデルのデメリット：
- スパイラルモデルは、大規模なプロジェクトにのみ最適です。
- 反復回数が多く、最終製品に到達するまでに長い時間がかかる可能性があるため、コストが高くなる可能性があります。
＃5）反復型インクリメンタルモデル
反復型インクリメンタルモデルは、製品を小さなチャンクに分割します。
例えば 、反復で開発される機能が決定され、実装されます。各反復は、要件分析、設計、コーディング、およびテストというフェーズを通過します。反復では詳細な計画は必要ありません。
イテレーションが完了すると、製品が検証され、評価とフィードバックのために顧客に提供されます。お客様のフィードバックは、新しく追加された機能とともに次のイテレーションで実装されます。
したがって、製品は機能の観点から増加し、反復が完了すると、最終ビルドは製品のすべての機能を保持します。
反復型およびインクリメンタル開発モデルのフェーズ：
- 開始フェーズ
- 精緻化フェーズ
- 建設段階
- 移行フェーズ
（i）開始フェーズ：
開始フェーズには、プロジェクトの要件と範囲が含まれます。
（ii）精緻化フェーズ：
精緻化フェーズでは、開始フェーズで特定されたリスクをカバーし、非機能要件も満たす製品の作業アーキテクチャが提供されます。
（iii）建設段階：
構築フェーズでは、アーキテクチャに、展開の準備ができており、機能要件の分析、設計、実装、およびテストを通じて作成されたコードが入力されます。
（iv）移行フェーズ：
移行フェーズでは、製品は本番環境にデプロイされます。
反復型および増分モデルの利点：
- 要件の変更は簡単に行うことができ、次の反復で新しい要件を組み込む余地があるため、コストはかかりません。
- リスクは反復で分析および識別されます。
- 欠陥は早い段階で検出されます。
- 製品は小さなチャンクに分割されているため、製品の管理が簡単です。
短所 反復型およびインクリメンタルモデルの概要：
- 分解して段階的に構築するには、製品の完全な要件と理解が必要です。
＃6）ビッグバンモデル
ビッグバンモデルには、定義されたプロセスはありません。入力と出力が開発された製品として提供されるため、お金と労力がまとめられます。これは、顧客が必要とするものと同じである場合とそうでない場合があります。
ビッグバンモデルは、多くの計画とスケジューリングを必要としません。開発者は、要件分析とコーディングを行い、彼の理解に従って製品を開発します。このモデルは、小規模なプロジェクトにのみ使用されます。テストチームは存在せず、正式なテストも行われていません。これがプロジェクトの失敗の原因となる可能性があります。
利点 ビッグバンモデルの：
- とてもシンプルなモデルです。
- 必要な計画とスケジューリングが少なくて済みます。
- 開発者は、独自のソフトウェアを構築する柔軟性を持っています。
ビッグバンモデルのデメリット：
- ビッグバンモデルは、大規模で進行中の複雑なプロジェクトには使用できません。
- 高いリスクと不確実性。
＃7）アジャイルモデル
アジャイルモデルは、反復モデルとインクリメンタルモデルを組み合わせたものです。このモデルは、要件よりも製品開発中の柔軟性に重点を置いています。
アジャイルでは、製品は小さな増分ビルドに分割されます。一度に完全な製品として開発されるわけではありません。各ビルドは、機能の観点から増加します。次のビルドは、以前の機能に基づいて構築されています。
アジャイルイテレーションでは、スプリントと呼ばれます。各スプリントは2〜4週間続きます。各スプリントの最後に、製品の所有者は製品を検証し、承認後、顧客に納品します。
顧客のフィードバックは改善のために取られ、彼の提案と強化は次のスプリントで取り組まれます。障害のリスクを最小限に抑えるために、各スプリントでテストが行われます。
アジャイルモデルの利点：
- これにより、変更に柔軟に適応できます。
- 新機能は簡単に追加できます。
- フィードバックや提案としての顧客満足度は、あらゆる段階で取られます。
短所：
- ドキュメントの欠如。
- アジャイルには、経験豊富で高度なスキルを持つリソースが必要です。
- 顧客が製品をどの程度正確に望んでいるかについて明確でない場合、プロジェクトは失敗します。
結論
プロジェクトを成功させるためには、適切なライフサイクルを順守することが非常に重要です。これにより、管理が容易になります。
さまざまなソフトウェア開発ライフサイクルモデルには、独自の長所と短所があります。プロジェクトに最適なモデルは、要件（明確か不明確か）、システムの複雑さ、プロジェクトのサイズ、コスト、スキルの制限などの要因によって決定できます。
例、 要件が不明確な場合は、スパイラルモデルとアジャイルモデルを使用するのが最適です。必要な変更はどの段階でも簡単に対応できるためです。
ウォーターフォールモデルは基本モデルであり、他のすべてのSDLCモデルはそれのみに基づいています。
SDLCに関する膨大な知識が得られたと思います。