システム開発ライフサイクル

システムエンジニアリング、情報システム、ソフトウェアエンジニアリングにおいて、システム開発ライフサイクル（SDLC ）は、アプリケーション開発ライフサイクルとも呼ばれ、情報システムの計画、作成、テスト、展開のプロセスです。^[1]システムはハードウェアのみ、ソフトウェアのみ、またはその両方の組み合わせで構成できるため、SDLCの概念はさまざまなハードウェアおよびソフトウェア構成に適用されます。^[2]このサイクルには通常、要件分析、設計、開発とテスト、実装、ドキュメント化、評価の6つの段階があります。

「ソフトウェア開発組織は、成熟した組織でソフトウェア製品を開発する際に、明確に定義され管理されたプロセスに従います。ソフトウェア開発ライフサイクルでは、体系的かつ規律ある方法でソフトウェアを開発します。」

システム開発ライフサイクルは、システムエンジニアとシステム開発者が情報システムを提供するために使用する明確な作業フェーズで構成されています。組立ラインで製造されるものと同様に、SDLCは、スケジュールされた時間枠とコスト見積もり内でシステムを提供することにより、要件に基づいて期待を満たすかそれを超える高品質のシステムを生み出すことを目的としています。^{[3]コンピュータシステムは複雑であり、多くの場合、さまざまな起源を持つコンポーネントをリンクします。ウォーター}フォール、スパイラル、アジャイル、ラピッドプロトタイピング、インクリメンタル、同期と安定化など、さまざまなSDLC方法論が作成されています。 ^[4]

SDLC方法論は、アジャイルから反復的、そしてシーケンシャルに至るまでの柔軟性の範囲に当てはまります。XPやスクラムなどのアジャイル方法論は、迅速な変更を可能にする軽量プロセスに重点を置いています。^[5] Rational Unified Processや動的システム開発方法などの反復的方法論は、プロジェクト範囲の安定化と製品の反復的な拡張または改善に重点を置いています。ウォーターフォールなどのシーケンシャルまたは大規模設計先行（BDUF）モデルは、より大規模なプロジェクトを導き、リスクを制限して成功し予測可能な結果を​​得るための完全で正確な計画に重点を置いています。^[6]アナモルフィック開発は、プロジェクト範囲と適応型反復によって導かれます。

プロジェクト管理では、プロジェクトにはプロジェクトライフサイクル(PLC) と SDLC の両方が含まれることがあり、その間に多少異なるアクティビティが発生します。Taylor (2004) によると、「プロジェクトライフサイクルはプロジェクトのすべてのアクティビティを網羅し、システム開発ライフサイクルは製品要件の実現に重点を置いています。」^[7]

SDLC は方法論そのものではなく、方法論が取り組むべきフェーズの説明です。フェーズのリストは決定的なものではありません。通常、計画、分析、設計、構築、テスト、実装、保守/サポートが含まれます。たとえば、スクラム フレームワーク^[8]では、1 つのユーザー ストーリーが 2 週間のスプリントで SDLC のすべてのフェーズを通過すると言えます。これとは対照的に、ウォーターフォール方法論では、すべてのビジネス要件^[要出典]が機能/機能の説明に変換され、通常は数か月以上かけて実装されます。^[要出典]

エリオット（2004）によると、SDLCは「1960年代に、大規模ビジネスコングロマリットの時代に大規模な機能ビジネスシステムを開発するために始まりました。情報システム活動は、大量のデータ処理と数値計算ルーチンを中心に展開されていました」。^[9]

構造化システム分析設計法(SSADM) は、1980 年代に英国政府商務局向けに開発されました。それ以来、Elliott (2004) によると、「システム開発に対する従来のライフサイクル アプローチは、従来の SDLC の固有の欠陥の一部を克服しようとする代替アプローチやフレームワークにますます置き換えられてきました」。^[9]

SDLCは、システム設計者と開発者が従うべき一連のフェーズ/ステップ/アクティビティを提供します。各フェーズは、前のフェーズの結果に基づいて構築されます。^{[10] [11] [12] [13]}すべてのプロジェクトでフェーズが連続している必要はありません。小規模で単純なプロジェクトでは、フェーズが組み合わされたり重複したりすることがあります。^[10]

最も古く、最もよく知られているのは、直線的な一連のステップを使用するウォーターフォールモデルです。 ^[11]ウォーターフォールにはさまざまな種類があります。1つの種類は次のとおりです。^{[10] [11] [14] [15]}

予備分析を実施し、代替ソリューションを検討し、コストと利点を見積もり、推奨事項を含む予備計画を提出します。

• 予備分析を実施する: 組織の目的を特定し、プロジェクトの性質と範囲を定義します。プロジェクトが目的に適合していることを確認します。
• 代替ソリューションを検討する: 代替案は、従業員、顧客、サプライヤー、コンサルタントへのインタビューや競合分析から得られる場合があります。
• 費用便益分析: プロジェクトの費用と便益を分析します。

プロジェクトの目標を、定義された機能と操作に分解します^。これには、事実の収集と解釈、問題の診断、変更の推奨が含まれます。エンドユーザーの情報ニーズを分析し、矛盾や不完全さを解決します。^[16]

• 事実の収集: ドキュメントのレビュー、クライアントへのインタビュー、観察、アンケートによってエンドユーザーの要件を取得します。
• 既存のシステムを精査し、長所と短所を特定します。
• 提案されたシステムを分析する: 問題の解決策を見つけ、適切なユーザー提案を取り入れて仕様を準備します。

このステップでは、画面レイアウト、ビジネス ルール、プロセス図、疑似コード、その他の成果物 など、必要な機能と操作の詳細が定義されます。

コードを書いてください。

テスト環境でモジュールを組み立てます。エラー、バグ、相互運用性をチェックします。

システムを本番環境に導入します。これには、ユーザーのトレーニング、ハードウェアの導入、以前のシステムからの情報の読み込みなどが含まれる場合があります。

システムを監視して、その継続的な適合性を評価します。必要に応じて適度な変更と修正を行います。システムの品質を維持するため。継続的な監視と更新により、システムの有効性と高品質が維持されます。^[17]

システムとプロセスがレビューされます。関連する質問には、新しく実装されたシステムが要件を満たし、プロジェクトの目標を達成しているかどうか、システムが使用可能かどうか、信頼性/可用性があるかどうか、適切に拡張され、フォールト トレラントであるかどうかなどがあります。プロセス チェックには、タイムラインと費用のレビュー、およびユーザーの受け入れが含まれます。

システムの寿命が尽きると、システムを廃止し、代替システムに移行するための計画が立てられます。関連する情報とインフラストラクチャは、セキュリティを適切に保護しながら、再利用、アーカイブ、廃棄、または破壊する必要があります。^[18]

次の図では、これらの段階は、IT 作業成果物の定義から作成および変更まで、10 のステップに分かれています。

システム分析と設計(SAD) は、ステージを設定し、問題を限定するメタ開発アクティビティと考えることができます。SAD は、競合する高レベルの要件のバランスをとるのに役立ちます。SAD は、分散エンタープライズ アーキテクチャ、エンタープライズ IT アーキテクチャ、ビジネス アーキテクチャと連携し、パーティション分割、インターフェイス、ペルソナとロール、展開/運用モデリングなどの概念に大きく依存して、高レベルのシステム記述に到達します。この高レベルの記述は、コンポーネントとモジュールに分割され、個別に分析、設計、構築して統合することでビジネス目標を達成できます。SDLC と SAD は、製品とシステムのライフサイクル全体にわたる計画の基礎となります。

オブジェクト指向分析および設計(OOAD) は、問題領域を分析して、開発のガイドとして使用できる概念モデルを作成するプロセスです。分析フェーズでは、プログラマーは関係者とのインタビューを通じて、要件を文書化し、正式なビジョン ドキュメントを作成します。

OOAD から得られる概念モデルは、通常、ユースケース、クラス図、相互作用図で構成されます。また、ユーザー インターフェイスのモックアップが含まれる場合もあります。

出力成果物は、オブジェクト指向設計の入力として使用するために完全に定義される必要はありません。分析と設計は並行して行われる場合があります。実際には、1 つのアクティビティの結果が、反復プロセスで他のアクティビティにフィードされます。

OOAD の一般的な入力アーティファクト:

• 概念モデル: 概念モデルは、オブジェクト指向分析の結果です。問題領域の概念を捉えます。概念モデルは、実装の詳細とは明確に独立しています。
• ユースケース: ユースケースとは、一連のイベントをまとめて記述したもので、必要なタスクを完了します。各ユースケースは、システムがアクター (ユーザー) とどのように対話するかを示すシナリオを提供します。アクターは、エンド ユーザーまたは他のシステムです。ユースケースは、図を使用してさらに詳しく説明できます。このような図は、アクターと、アクターが実行するプロセスを特定します。
• システム シーケンス図: システム シーケンス図 (SSD) は、特定のユース ケースについて、アクターが生成するイベントとその順序 (システム間イベントを含む) を示す図です。
• ユーザー インターフェイス ドキュメント: ユーザー インターフェイスを表示および説明するドキュメント。
• データ モデル: データ モデルは、データ要素が互いにどのように関連しているかを説明します。データ モデルは設計フェーズの前に作成されます。オブジェクト指向設計は、データ モデルから直接マップします。リレーショナル設計はより複雑です。

システムライフサイクルとは、システムまたは提案されたシステムの構想、設計と開発、生産と/または建設、配布、運用、保守とサポート、廃止、段階的廃止、廃棄を含む、その存在のすべての段階を扱うシステムまたは提案されたシステムの見方です。^[19]

概念設計段階は、特定されたニーズを調査し、潜在的なソリューションの要件を定義し、潜在的なソリューションを評価し、システム仕様を開発する段階です。システム仕様は、システム設計の全体的なガイドラインとなる技術要件を表します。このドキュメントによって将来の開発がすべて決定されるため、概念設計レビューでシステム仕様が動機となるニーズに適切に対応していることが判断されるまで、この段階は完了できません。

概念設計段階の主なステップは次のとおりです。

• 身分証明が必要
• 実現可能性分析
• システム要件分析
• システム仕様
• 概念設計レビュー

システムライフサイクルのこの段階では、システム仕様に準拠して、必要なシステム機能を実行するサブシステムが設計および指定されます。サブシステム間のインターフェース、および全体的なテストと評価の要件が定義されます。^[20]この段階が完了すると、詳細な設計と開発を実行するのに十分な開発仕様が作成されます。

予備設計段階の主な手順は次のとおりです。

• 機能分析
• 要件の割り当て
• 詳細なトレードオフ研究
• システムオプションの統合
• エンジニアリングモデルの予備設計
• 開発仕様
• 予備設計レビュー

たとえば、Viti Bank のシステム アナリストとして、現在の情報システムを調査する任務を負っているとします。Viti Bank はフィジーで急成長している銀行です。遠隔地の顧客は銀行サービスへのアクセスに苦労しています。銀行サービスを利用するために、特定の場所まで出向くのに数日、場合によっては数週間かかります。顧客のニーズを満たすというビジョンのもと、銀行は現在のシステムを調査し、現在のシステムをどのように提供すればニーズを満たすことができるかについてのソリューションや推奨事項を作成するよう、あなたに依頼しました。

この段階には、初期設計作業を完成した仕様にまとめる詳細設計の開発が含まれます。この作業には、システムと対象環境間のインターフェイスの仕様、およびシステムのロジスティクス、保守、サポート要件の総合的な評価が含まれます。詳細設計と開発は、製品、プロセス、および材料の仕様を作成する責任があり、開発仕様に大幅な変更が生じる可能性があります。

詳細設計および開発段階における主なステップは次のとおりです。

• 詳細設計
• 詳細な合成
• エンジニアリングおよびプロトタイプモデルの開発
• 開発仕様の改訂
• 製品、プロセス、材料の仕様
• 重要な設計レビュー

生産および/または建設段階では、製品は製品、プロセス、および材料の仕様で指定された要件に従って構築または組み立てられ、運用対象環境内で展開およびテストされます。システム評価は、欠陥を修正し、システムを継続的に改善するために実施されます。

製品構築段階における主なステップは次のとおりです。

• システムコンポーネントの製造および/または構築
• 受け入れテスト
• システムの配布と運用
• 運用テストと評価
• システム評価

完全に展開されると、システムは意図された運用上の役割に使用され、運用環境内で維持されます。

利用とサポートの段階における主なステップは次のとおりです。

• ユーザー環境でのシステム操作
• 変更管理
• 改善のためのシステム変更
• システム評価

システムの有効性と効率性は、製品が最大有効ライフサイクルに達した時期を判断するために継続的に評価されなければならない。^[21]考慮事項には、運用上の必要性の継続的な存在、運用要件とシステムパフォーマンスの一致、システムの段階的廃止とメンテナンスの実現可能性、代替システムの可用性などが含まれる。

このステップでは、影響を受ける現在の優先事項とその対処方法を検討します。実現可能性調査により、新しいシステムまたは改善されたシステムの作成が適切かどうかが判断されます。これにより、コスト、利点、リソース要件、および特定のユーザー ニーズを見積もることができます。

実現可能性調査では、運用、財務、技術、人的要因、および法的/政治的な懸念に対処する必要があります。

分析の目的は、問題がどこにあるのかを特定することです。このステップでは、システムを細分化し、プロジェクトの目標を分析し、作成する必要があるものを細分化し、ユーザーを関与させて要件を定義します。

システム設計では、画面レイアウト、ビジネス ルール、プロセス図、その他のドキュメントなど、機能と操作が詳細に記述されます。モジュール設計により複雑さが軽減され、出力によってシステムをサブシステムの集合として記述できるようになります。

設計段階では、すでに定義されている要件を入力として受け取ります。要件ごとに、設計要素のセットが作成されます。

設計ドキュメントには通常、機能階層図、画面レイアウト、ビジネス ルール、プロセス図、疑似コード、データ ディクショナリを含む完全なデータ モデルが含まれます。これらの要素は、開発者やエンジニアが最小限の追加入力でシステムを開発および提供できるように、システムを十分に詳細に記述します。

ソフトウェア テストでは、さまざまなレベルでコードがテストされます。通常、ユニット テスト、システム テスト、およびユーザー受け入れテストが実行されます。テストにはさまざまなアプローチが採用されています。

次の種類のテストが関連する可能性があります。

• パステスト
• データセットのテスト
• ユニットテスト
• システムテスト
• 統合テスト
• ブラックボックステスト
• ホワイトボックステスト
• 回帰テスト
• 自動テスト
• ユーザー受け入れテスト
• ソフトウェアパフォーマンステスト

テストを通じてシステムが安定化したら、SDLC によって、システムをサポート スタッフとエンド ユーザーに移行する前に適切なトレーニングが準備され、実行されることが保証されます。トレーニングには通常、サポート スタッフの運用トレーニングとエンド ユーザー トレーニングが含まれます。

トレーニング後、システム エンジニアと開発者はシステムを本番環境に移行します。

メンテナンスには、変更、修正、機能強化が含まれます。

SDLC の最終フェーズは、システムの有効性を測定し、潜在的な機能強化を評価することです。

このセクションでは、SDLC フェーズの目標について、主要な成果物、推奨タスクの説明、効果的な管理のための関連する制御目標の概要とともに説明します。プロジェクト マネージャーにとって、プロジェクトの実行中に制御目標を確立して監視することは非常に重要です。制御目標は、望ましい結果または目的を明確に述べたものであり、プロジェクト全体を通じて定義および監視する必要があります。制御目標は、主要なカテゴリ (ドメイン) にグループ化でき、図に示すように SDLC フェーズに関連します。^[22]

実質的な SDLC イニシアチブを管理および制御するには、作業の内訳構造(WBS) で作業を把握してスケジュールします。WBS とすべてのプログラム資料は、プロジェクト ノートブックの「プロジェクトの説明」セクションに保存する必要があります。^{[説明が必要]}プロジェクト マネージャーは、プロジェクトを最もよく表す WBS 形式を選択します。

この図は、カバレッジがSDLCの多数のフェーズにまたがっていることを示していますが、関連するMCD（管理制御ドメイン）はSDLCフェーズへのマッピングを示しています。たとえば、分析と設計は主に取得と実装ドメインの一部として実行され、システム構築とプロトタイプは主に配信とサポートの一部として実行されます。^[22]

WBS の上部には、プロジェクトの範囲とタイムラインの概要が記載されています。また、主要なフェーズとマイルストーンもまとめられています。中間のセクションは、SDLC フェーズに基づいています。WBS の要素は、実行して期限が設定されているアクティビティではなく、マイルストーンと完了するタスクで構成されています。各タスクには、測定可能な出力 (分析ドキュメントなど) があります。WBS タスクは、1 つ以上のアクティビティ (コーディングなど) に依存する場合があります。請負業者からのサポートが必要なプロジェクトの部分には、作業明細書(SOW) が必要です。SOW の作成は、SDLC の特定のフェーズでは行われませんが、請負業者が実施する可能性のある SDLC プロセスの作業を含めるように作成されます。^[22]

ベースライン^{[説明が必要]}は、 SDLCの5つのフェーズのうち4つのフェーズの後に確立され、モデルの反復的な性質にとって重要です。 ^[23]ベースラインはマイルストーンになります。

• 機能ベースライン: 概念設計フェーズ後に確立されます。
• 割り当てられたベースライン: 予備設計フェーズ後に確立されます。
• 製品ベースライン: 詳細設計および開発フェーズ後に確立されます。
• 更新された製品ベースライン: 生産構築フェーズ後に確立されます。

システム開発ライフサイクルに 代わるソフトウェア開発方法は次のとおりです。

• ソフトウェアのプロトタイピング
• 共同アプリケーション開発（JAD）
• 迅速なアプリケーション開発(RAD)
• エクストリームプログラミング（XP）
• オープンソース開発
• エンドユーザー開発
• オブジェクト指向プログラミング

基本的に、SDLC は構造を課すことで柔軟性を犠牲にして制御を実現します。多くの開発者がいる大規模プロジェクトでよく使用されます。

• アプリケーションライフサイクル管理
• 意思決定サイクル
• IPOモデル
• ソフトウェア開発方法論

• カミングス、ハーグ（2006年）。情報化時代の経営情報システム。トロント、マグロウヒル・ライアソン
• Beynon-Davies P. (2009).ビジネス情報システム. Palgrave, Basingstoke. ISBN 978-0-230-20368-6 
• Computer World、2002、2006 年 6 月 22 日に World Wide Web から取得:
• Management Information Systems、2005、2006 年 6 月 22 日に World Wide Web から取得:

ウィキメディア・コモンズには、システム開発ライフサイクルに関連するメディアがあります。

• アジャイルシステム開発ライフサイクル
• 年金保証公社 – 情報技術ソリューションライフサイクル方法論
• 国防総省統合フレームワークチャート IFC (表、裏)
• FSA ライフサイクル フレームワーク
• HHS エンタープライズ パフォーマンス ライフサイクル フレームワーク
• オープンシステム開発ライフサイクル
• システム開発ライフサイクル進化モデリング
• ゼロ偏差ライフサイクル
• 統合防衛 AT&L ライフサイクル管理チャート、この概念の米国国防総省形式。