ソフトウェア開発ライフサイクル（SDLC）の概要

Table of Contents hide

ソフトウェア開発ライフサイクルは、新製品の初期要件を収集することにより、成功するソフトウェアを開発するための体系的で段階的なアプローチを組織に提供します。これは、構築されたソフトウェアの品質と正確性を確保し、顧客の期待に応えるためのソフトウェア構築の体系的なプロセスです。

主な開発モデルには、ウォーターフォールモデル、インクリメンタルモデル、スパイラルモデル、ファウンテンモデル、スマートモデル、Vモデル、RADモデル、CBSDモデル、プロトタイプ方式、XP方式、RUP方式などがあります。

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

ライフサイクル法としても知られるウォーターフォールモデルは、ライフサイクル法で最も一般的に使用される開発モデルです。これは、ソフトウェア開発プロセスを、ソフトウェア計画、要件分析、ソフトウェア設計、プログラムコーディング、ソフトウェアテスト、および運用と保守の6つの段階に分割します。滝のように上から下へと一定の順序を達成するために、それらは段階的に落下します。

ソフトウェア計画：主にソフトウェアの開発目標と実現可能性を決定します。
要件分析：ソフトウェア開発が実行可能であることを確認した後、ソフトウェアが実行する必要のあるさまざまな機能の詳細な分析を実行します。要件分析の段階は非常に重要な段階です。この段階での良い仕事は、ソフトウェア開発プロジェクト全体の成功のための良い基盤を築くでしょう。
ソフトウェア設計：需要分析の結果に基づいて、システムフレームワーク設計、データベース設計などのソフトウェアシステム全体を設計します。ソフトウェア設計は、一般的に全体設計（アウトライン設計）と詳細設計に分けられます。
プログラムコード：ソフトウェア設計の結果を、コンピューターで実行できるプログラムコードに変換します。プログラミングの過程で、プログラムの可読性、容易な保守、およびプログラムの運用効率を向上させるために、統一された標準準拠のプログラミング仕様を策定する必要があります。
ソフトウェアテスト：ソフトウェア設計が完了した後、設計プロセス全体を通じてソフトウェアの問題を見つけて修正するために、厳密なテストを受ける必要があります。試験の過程では、詳細な試験計画を立て、試験の恣意性を減らすために、試験計画に厳密に従って試験を実施する必要があります。ソフトウェアメンテナンス：
ソフトウェアのメンテナンス は、ソフトウェアのライフサイクルの中で最も長い期間です。ソフトウェアが開発されて使用された後、さまざまな理由により、ソフトウェアはユーザーの要件を満たし続けることができません。ソフトウェアの耐用年数を延ばすには、ソフトウェアを保守する必要があります。

変換モデル

変換モデル（進化モデル）は、プロトタイプの迅速な開発に基づいています。試作品を呼び出す過程でユーザーから寄せられたフィードバックや提案によると、試作品は改良されて新しいバージョンの試作品が入手され、最終的なソフトウェア製品に発展するまでこの過程が繰り返されます。

スパイラルモデル

スパイラルモデルは、ウォーターフォールモデルと変換モデルを組み合わせたものです。これは、2つの利点を組み合わせ、リスク分析を追加します。プロトタイプに基づいており、スパイラルに沿って内側から外側に回転します。各ローテーションには、計画、リスク分析、実装エンジニアリング、顧客評価、およびその他のアクティビティが必要であり、プロトタイプの新しいバージョンが開発されます。いくつかのスパイラルの後、最終的なシステムが得られます。

噴水モデル

ファウンテンモデルは、ソフトウェアの再利用とライフサイクルにおける複数の開発アクティビティの統合をサポートし、主にオブジェクト指向の開発方法をサポートします。「噴水」という用語自体は、反復とギャップのない特性を体現しています。システムの特定の部分は、多くの場合、作業を何度も繰り返し、関連する機能は、各反復で進化したシステムに追加されます。いわゆるギャップレスとは、開発活動における分析、設計、コーディングの間に明確な境界がないことを意味します。

Vモデル

開発モデルでは、状況を改善するための後付けとしてテストがよく使用されますが、テスト中心の開発モデル、つまりVモデルもあります。Vモデルは、ソフトウェア業界では漠然としか認識されていません。Vモデルは、テストは後付けではなく、開発プロセスと同じくらい重要なプロセスであると主張しています。

Vモデルは、いくつかの異なるテストレベルを記述し、これらのレベルに対応するライフサイクルのさまざまな段階を記述します。この図では、左側の下降は開発プロセスのさまざまな段階であり、対応するものは右側の上昇部分、つまりテストプロセスのさまざまな段階です。

テストフェーズの名前は、組織によって異なる場合があることに注意してください。Vモデルの価値は、テストプロセスに存在するさまざまなレベルを明確に示し、これらのテストフェーズと開発プロセス中のさまざまなフェーズとの対応を明確に説明していることです。

単体テストの主な目的は、コーディングプロセスに存在する可能性のあるさまざまなエラーに対処することです。例：ユーザーが検証プロセス中に境界値にエラーを入力しました。
統合テストの主な目的は、詳細設計で発生する可能性のある問題に対処することです。特に、各ユニットと他のプログラム部分との間のインターフェイスで発生する可能性のあるエラーを確認することです。
システムテストは、主にアウトライン設計を目的としており、システム全体が効果的に動作しているかどうかを確認します。例：製品設定で期待される高性能が達成されているかどうか。
受け入れテストは通常、製品がユーザーのビジネスニーズを本当に満たすことができることを確認するために、ビジネスの専門家またはユーザーによって実行されます。

インクリメンタルモデル

プロトタイプ実装モデルやその他の進化的手法のようなインクリメンタルモデルは、本質的に反復的です。ただし、プロトタイプの実装とは異なり、インクリメンタルモデルでは、インクリメンタルごとに操作可能な製品がリリースされることが強調されています。初期の増分は最終製品の「取り外し可能な」バージョンですが、ユーザーサービス機能を提供し、ユーザーが評価するためのプラットフォームを提供します。

インクリメンタルモデルの特徴は、インクリメンタルパッケージの概念の導入です。すべての要件が出てくるまで待つ必要はありません。特定の要件のインクリメンタルパッケージが出てくる限り、開発を開始できます。特定のインクリメンタルパッケージは、顧客のニーズにさらに適合させる必要があり、変更する必要がある場合がありますが、インクリメンタルパッケージが十分に小さい限り、その影響はプロジェクト全体に耐えることができます。

RADモデルRapidApplication Development（RAD）モデルは、非常に短い開発サイクルを強調するインクリメンタルなソフトウェア開発プロセスモデルです。

RADモデルは、ウォーターフォールモデルの「高速」バリアントであり、再利用可能なコンポーネントとコンポーネントベースの構築方法を幅広く使用することで急速な発展を遂げています。要件が十分に理解されており、プロジェクトの範囲が制限されている場合は、このモデルを使用して、完全に機能する「情報システム」をすばやく作成できます。

このプロセスは、ビジネスモデリングから始まり、データモデリング、プロセスモデリング、アプリケーションの生成、テスト、および反復が続きます。RADモデルを使用したソフトウェアプロセスを次の図に示します。

RADモデルの各活動期間に完了するタスクは次のとおりです。

ビジネスモデリング：どのような情報がビジネスプロセスの運用を推進しますか？どのような情報が生成されますか？誰がそれを生成しましたか？情報の流れはどこに行きますか？誰がそれを処理しますか？データフロー図で補足できます。

データモデリング：ビジネスプロセスのデータフローをサポートするために、データオブジェクトのコレクションを見つけ、データオブジェクトの属性を定義し、他のデータオブジェクトとの関係でデータモデルを形成します。これはER図で補足できます。。

プロセスモデリング：データオブジェクトが情報フローのさまざまなビジネス機能を完了できるようにします。作成プロセスでは、データオブジェクトの追加、変更、削除、および検索、つまり、データフロー図の処理ボックスの改良について説明します。

アプリケーションプログラムの生成：第4世代言語（4GL）を使用して、処理プログラムを記述し、既存のコンポーネントを再利用するか、新しい再利用可能なコンポーネントを作成し、環境が提供するツールを使用して、アプリケーションシステム全体を自動的に生成および構築します。

大量の再利用のため、テストと配信は通常、全体的なテストのみを行いますが、新しく作成されたコンポーネントもテストする必要があります。

コンポーネントベースのモデル

コンポーネント（コンポーネント）は、再利用可能な価値と比較的独立した機能を備えたソフトウェアユニットです。コンポーネントベースのソフトウェア開発（CBSD）モデルは、モジュラーアプローチを使用してシステム全体をモジュール化し、特定のコンポーネントモデルのサポートにより、コンポーネントライブラリ内の1つ以上のソフトウェアコンポーネントを組み合わせて再利用します。アプリケーションソフトウェアを構築するプロセス高効率で高品質のシステム。

コンポーネントベースの開発モデルは、スパイラルモデルの多くの特性を組み込んでおり、本質的に進化的であり、開発プロセスは反復的です。コンポーネントベースの開発モデルは、ソフトウェア要件の分析と定義、アーキテクチャの設計、コンポーネントライブラリの確立、アプリケーションソフトウェアの構築、テスト、およびリリースの5つの段階で構成されています。

プロトタイプ方式

ソフトウェアプロトタイプは、提案された新製品の部分的な実現です。試作品を作る主な目的は、製品開発の初期段階で需要が不確実であるという問題を解決することです。その目的は、要件を明確にして改善し、設計オプションを検討し、最終製品に発展させることです。

プロトタイプを分類する方法はたくさんあります。プロトタイプがその機能を実現するかどうかという観点から、ソフトウェアプロトタイプは、水平プロトタイプと垂直プロトタイプの2つのタイプに分けることができます。

水平プロトタイプは動作プロトタイプとも呼ばれ、予想されるシステムの特定の動作を調査し、要件を改善する目的を達成するために使用されます。水平プロトタイプは通常、関数の単なるナビゲーションですが、実際には関数を実装していません。水平プロトタイプは主にインターフェースで使用されます。

垂直プロトタイプは構造化プロトタイプとも呼ばれ、その機能の一部を実装します。垂直プロトタイプは、主に複雑なアルゴリズムの実現に使用されます。

XP方式

XPは、軽量（アジャイル）、効率的、低リスク、柔軟性、予測可能、科学的で楽しいソフトウェア開発手法です。他の方法論と比較して、最大の違いは次のとおりです。

短期間に具体的かつ継続的なフィードバックを提供します。
反復計画。最初にマスタープランを最初に迅速に生成し、次にプロジェクト開発プロセス全体で継続的に開発します。
自動化されたテスト手順を利用して、開発の進捗状況を監視し、欠陥を早期に発見します。
口頭でのコミュニケーション、テスト、ソースプログラムのコミュニケーションに依存します。
継続的進化的設計を提唱します。
開発チーム内の緊密なコラボレーションに依存します。
プログラマーの短期的な利益とプロジェクトの長期的な利益のバランスをできるだけとるようにしてください。

統合プロセス（UP）方式

Unified Processは、さまざまなソフトウェアシステム、さまざまなアプリケーションフィールド、さまざまな組織タイプ、さまざまなパフォーマンスレベル、さまざまなプロジェクト規模に対応できる一般的なプロセスフレームワークです。UPはコンポーネントベースです。つまり、UPによって開発されたソフトウェアシステムはコンポーネントで構成されており、コンポーネントは明確に定義されたインターフェイスを介して相互に接続されています。ソフトウェアシステムのすべての青写真を準備するとき、UPは統一モデリング言語UMLを使用します。

他のソフトウェアプロセスと比較すると、UPには3つの注目すべき特徴があります。それは、基本的なアーキテクチャを中心としたユースケース主導、反復、および増分です。Rational Unified Processのソフトウェアプロセスは、時間の4つの連続したフェーズ、つまり、初期フェーズ、改良フェーズ、構築フェーズ、および配信フェーズに分けられます。各段階の終わりに、この段階の目標が達成されたかどうかを判断するための技術レビューを手配する必要があります。レビューの結果が満足のいくものであれば、プロジェクトは次の段階に進むことができます。