システム開発ライフサイクルにはどのような段階があるのでしょうか？
システム開発ライフサイクル

記事
トーク
読む
編集部
履歴を見る

ツール
フリー百科事典『ウィキペディア（Wikipedia）』より引用
この記事は、システム開発ライフサイクルに関するものなのだ。IBMのコンピュータ通信プロトコルについては、Synchronous Data Link Controlを参照のこと。

ソフトウェア開発ライフサイクルのモデル、メンテナンスフェーズにスポットを当てる
システム工学、情報システム工学、ソフトウェア工学において、システム開発ライフサイクル（SDLC）は、アプリケーション開発ライフサイクルとも呼ばれ、情報システムの計画、作成、テスト、配備のためのプロセスなのだ。システムはハードウェアのみ、ソフトウェアのみ、またはその両方を組み合わせて構成することができるので、SDLCコンセプトはハードウェアとソフトウェアの構成の範囲に当てはまる。このサイクルには通常6段階（要求分析、設計、開発およびテスト、実装、文書、および評価）がある。

概要
システム開発ライフサイクルとは、システムエンジニアやシステム開発者が情報システムを提供するために使用する、明確な作業フェーズで構成されているのだ。SDLCは、組立ラインで製造されるものと同様に、予定された時間枠とコスト見積もり内でシステムを提供することにより、要件に基づいて、期待に応える、または期待を上回る高品質のシステムを製造することを目的としています。コンピュータシステムは複雑で、しばしば起源が異なるコンポーネントを連結するのだ。ウォーターフォール、スパイラル、アジャイル、ラピッドプロトタイピング、インクリメンタル、シンクロナイズアンドスタビライズなど、さまざまなSDLCの方法論が生み出されてきた。

SDLC の方法論は、アジャイルから反復的、逐次的までの柔軟なスペクトルに適合している。XP やスクラムのようなアジャイルな方法論は、迅速な変更を可能にする軽量なプロセスに重点を置いている。ラショナル統一プロセスや動的システム開発法のような反復的方法論は、プロジェクトの範囲を安定させ、製品を反復的に拡大または改善することに重点を置く。ウォーターフォールなどの逐次型またはビッグデザインアップフロント（BDUF）モデルは、大規模なプロジェクトを導くために完全で正しい計画に焦点を当て、リスクを制限して成功し予測可能な結果をもたらするのだ[citation needed] アナモフィック開発は、プロジェクト範囲と適応的反復により導かれます。

プロジェクトマネジメントでは、プロジェクトは、プロジェクトライフサイクル（PLC）と SDLC の両方を含むことができ、その間に多少異なる活動が行われる。Taylor (2004) によると、「プロジェクトライフサイクルはプロジェクトのすべての活動を包含し、システム開発ライフサイクルは製品要求の実現に焦点を当てる」。

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

沿革
Elliott & Strachan & Radford (2004) によると、SDLC は「1960 年代に、大規模なビジネスコングロマリットの時代に大規模な機能的ビジネスシステムを開発するために誕生した。情報システム活動は、重いデータ処理と数値計算のルーチンを中心に展開された」。

構造化システム分析・設計法（SSADM）は、1980年代に英国政府のOffice of Government Commerceのために作られた。それ以来、Elliott (2004) によれば、「システム開発に対する伝統的なライフサイクルアプローチは、伝統的なSDLCの固有の欠陥のいくつかを克服しようとした、代替アプローチやフレームワークとますます置き換えられてきた」。

モデル

システム開発ライフサイクルの10段階バージョン。
SDLC は、システム設計者と開発者が従うべき一連のフェーズ/ステップ/アクティビティを提供する。各フェーズは、前のフェーズの結果を基に構築される すべてのプロジェクトで、フェーズを連続させる必要があるわけではない。小規模でシンプルなプロジェクトでは、フェーズを組み合わせたり、重ねたりすることもある。

ウォーターフォール
最も古く、最もよく知られているのはウォーターフォールモデルであり、直線的な一連のステップを使用する ウォーターフォールには様々な種類がある。その1つが次のようなものなのだ。

予備的分析
予備的な分析で実施し、代替案を検討し、コストと利益を見積もり、推奨事項を記載した予備計画を提出する。

予備的な分析を行う：組織の目的を特定し、プロジェクトの性質と範囲を定義する。プロジェクトが目的に合致していることを確認する。
代替案を検討する：従業員、顧客、サプライヤー、コンサルタントへのインタビューや競合分析から、代替案を検討する。
コスト・ベネフィット分析：プロジェクトのコストとベネフィットを分析する。
システム分析、要件定義
プロジェクト目標[clarification needed]を定義された機能および業務に分解する。これには、事実の収集と解釈、問題の診断、および変更の推奨が含まれます。エンドユーザーの情報ニーズを分析し、矛盾や不完全性を解決する：。

事実を収集する：ドキュメントレビュー、クライアントインタビュー、観察、アンケートなどにより、エンドユーザー要件を取得する。
既存のシステムを精査する：長所と短所を把握する。
提案するシステムを分析する：課題解決策を見つけ、適切なユーザー提案を盛り込んだ仕様書を作成するのだ。
システム設計
このステップでは、画面レイアウト、ビジネスルール、プロセス図、擬似コードなどの成果物を含めて、望ましい機能や操作方法を詳細に説明するのだ。

開発
コードを書きます。

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

受入、設置、展開
システムを本番稼動させる。これには、ユーザーのトレーニング、ハードウェアの配備、先行システムからの情報のロードなどが含まれる。

メンテナンス
システムを監視して、その継続的な適合性を評価する。必要に応じて、適度な変更と修正を行う。

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

ディスポーザブル
耐用年数の終了時には、システムを廃止し、その代替品に移行するための計画が策定される。関連する情報やインフラは、セキュリティを適切に保護しながら、再利用、アーカイブ、廃棄、または破壊されなければならない。

以下の図では、これらの段階を、IT作業成果物の定義から作成・修正まで、10段階に分けています：

システム分析・設計
システム分析・設計（SAD）は、舞台を整え、問題を縛る役割を果たす、メタ開発活動と考えることができるのだ。SADは、競合する高レベルの要求のバランスをとるのに役立ちます。SADは、分散型エンタープライズ・アーキテクチャ、エンタープライズI.T.アーキテクチャ、ビジネス・アーキテクチャと相互作用し、パーティショニング、インターフェース、ペルソナおよび役割、展開/運用モデリングなどの概念に大きく依存して、高レベルのシステム記述に到達する。このハイレベルな記述は、次に、ビジネス目標を達成するために個別に分析、設計、構築し、統合することができるコンポーネントとモジュールに分解されます。SDLCとSADは、フルライフサイクルの製品およびシステム計画の基礎となるものなのだ。

オブジェクト指向の解析と設計
オブジェクト指向分析・設計（OOAD）とは、問題領域を分析し、開発の指針となる概念モデルを開発するプロセスなのだ。分析段階では、プログラマーは利害関係者とのインタビューを通じて、要件定義書と正式なビジョン文書を作成するのだ。

OOADから得られる概念モデルは、通常、ユースケース、クラス図、インタラクション図から構成されます。また、ユーザーインターフェイスのモックアップも含まれることがあるのだ。

オブジェクト指向設計の入力となる出力成果物は、完全に定義されている必要はなく、解析と設計が並行して行われることもあるのだ。実際には、一方の活動の結果が他方の活動に反映され、反復的なプロセスが行われることもあるのだ。

OOADの代表的な入力成果物をいくつか紹介するのだ：

概念的なモデル：概念モデルは、オブジェクト指向の分析結果なのだ。問題領域の概念を捉えたものなのだ。概念モデルは、実装の詳細から明示的に独立している。
ユースケース：ユースケースは、必要なタスクを完了させるための一連のイベントの記述なのだ。各ユースケースは、システムがアクター（ユーザー）とどのように相互作用すべきかを伝えるシナリオを提供する。アクターは、エンドユーザーであったり、他のシステムであったりするのだ。ユースケースは、ダイアグラムを使用してさらに詳しく説明することができるのだ。このようなダイアグラムでは、アクターとそれらが実行するプロセスを特定するのだ。
システムシーケンスダイアグラムシステム・シーケンス図（SSD）は、特定のユースケースについて、アクターが生成するイベントとその順序（システム間のイベントを含む）を示す図なのだ。
ユーザーインターフェイス文書：ユーザーインターフェイスを示し、説明する文書。
データモデル：データモデルとは、データ要素が互いにどのように関連しているかを記述したものなのだ。データモデルは、設計段階の前に作成されます。オブジェクト指向の設計は、データモデルから直接マッピングするのだ。リレーショナル・デザインはより複雑なのだ。
システムライフサイクル
システムライフサイクルとは、システムの構想、設計・開発、生産・建設、流通、運用、保守・サポート、引退、段階的廃止、廃棄など、その存在の全段階に対処するシステムまたはシステム案の見解なのだ。

コンセプチュアルデザイン
概念設計段階は、特定されたニーズを検討し、潜在的な解決策の要件を定義し、潜在的な解決策を評価し、システム仕様書を作成する段階なのだ。システム仕様書は、システム設計の全体的な指針となる技術的な要求事項を表している。この文書によって将来の開発がすべて決定されるため、システム仕様が動機となるニーズに適切に対応していると概念設計レビューで判断されるまでは、この段階を完了することはできない。

コンセプトデザインの段階での主なステップは以下の通りなのだ：

ニーズの把握
フィージビリティ・アナリシス
システム要件分析
システム仕様
コンセプトデザインレビュー
システム予備設計
システムライフサイクルのこの段階では、システム仕様に準拠して、必要なシステム機能を実行するサブシステムが設計・規定される。この段階が終了すると、詳細設計と開発を行うのに十分な開発仕様書が作成される。

予備設計段階での主なステップは以下の通りなのだ：

機能解析
要件配分
詳細なトレードオフの検討
システムオプションの合成
エンジニアリングモデルの予備設計
開発仕様
デザイン予備審査
例えば、Viti Bankのシステムアナリストとして、あなたは現在の情報システムを調査することを命じられたとするのだ。Viti Bankはフィジーで急成長している銀行なのだ。しかし、地方の遠隔地に住む顧客は、銀行のサービスにアクセスすることに困難を感じているのだ。銀行サービスを利用するために、何日も、あるいは何週間もかけて現地に赴く必要があるのなのだ。顧客のニーズを満たすというビジョンのもと、同銀行は、現行システムを調査し、現行システムをどのように提供すればニーズに応えられるか、解決策や推奨事項を提示するよう、貴社に依頼しました。

詳細設計・開発
この段階では、初期設計を仕様書として完成させるための詳細設計を行う。この作業には、システムと想定される環境との間のインターフェースの仕様や、システムの後方支援、メンテナンス、サポート要件の包括的な評価が含まれる。詳細設計と開発は、製品、プロセス、材料の仕様を作成する責任があり、開発仕様に大幅な変更を加える可能性があるのだ。

詳細設計・開発段階での主なステップは以下の通りなのだ：

詳細設計
詳細な合成
エンジニアリングモデル、プロトタイプモデルの開発
開発仕様書の改訂
製品、プロセス、材料の仕様
クリティカルデザインレビュー
製造・施工
生産・建設段階では、製品は製品、プロセス、材料仕様で指定された要件に従って構築または組み立てられ、運用目標環境内で配備されテストされる。システム評価は、欠陥の修正と継続的な改善のためのシステム適合のために行われます。

製品の製造段階における主なステップは以下の通りなのだ：

システムコンポーネントの製造および構築
アクセプタンステスト
システムの流通と運用
運用テスト・評価
システム評価
活用とサポート
完全に配備された後、システムは意図された運用上の役割のために使用され、運用環境内で維持されます。

利用・支援段階での主なステップは以下の通りなのだ：

ユーザー環境でのシステム運用
チェンジマネジメント
改善のためのシステム改修
システム評価
フェーズアウトと廃棄
システムの有効性と効率性は、製品が最大有効ライフサイクルを達成したときを判断するために、継続的に評価されなければならない：運用上の必要性の継続、運用上の要求とシステム性能の一致、システムの段階的廃止と保守の実行可能性、代替システムの利用可能性。

フェーズ

このセクションには、参考文献、関連書籍、外部リンクのリストが含まれていますが、インライン引用がないため、出典が不明なままなのだ。より正確な引用を導入することで、このセクションの改善にご協力をお願いするのだ。(2023年1月） （このテンプレートメッセージを削除する方法とタイミングを学ぶ）
システム調査
このステップでは、影響を受けるであろう現在の優先事項と、それをどのように処理すべきかが検討されます。実現可能性調査では、新しいシステムや改善されたシステムを作ることが適切かどうかを判断する。これは、コスト、利益、リソース要件、特定のユーザーニーズの見積もりに役立ちます。

フィージビリティ・スタディは、運用、財務、技術、人的要因、法的・政治的な懸念に対処する必要がある。

分析
分析の目的は、問題がどこにあるのかを特定することなのだ。このステップでは、システムを断片に分解し、プロジェクトの目標を分析し、作るべきものを分解し、ユーザーを巻き込んで要件を定義する。

デザイン
システム設計では、機能や操作を画面レイアウト、ビジネスルール、プロセス図などの文書で詳細に記述する。モジュール設計では、複雑さを軽減し、出力はサブシステムの集合体としてシステムを記述できるようにするのだ。

設計段階では、すでに定義されている要件を入力とするのだ。各要件に対して、デザイン要素のセットが作成されます。

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

テスト
ソフトウェアテストでは、様々なレベルでコードのテストが行われます。ユニットテスト、システムテスト、ユーザー受け入れテストが一般的に行われます。テストには、多くのアプローチが採用されている。

以下のような種類のテストが関連する可能性があるのだ：

パステスト
データセットテスト
単体テスト
システムテスト
統合テスト
ブラックボックステスト
ホワイトボックステスト
リグレッションテスト
自動化テスト
ユーザー受け入れテスト
ソフトウェア性能試験
訓練と移行
テストによってシステムが安定したら、SDLCは、サポートスタッフやエンドユーザーにシステムを移行する前に、適切なトレーニングが準備され、実行されることを保証するのだ。トレーニングは通常、サポートスタッフ向けの運用トレーニングとエンドユーザー向けのトレーニングが含まれます。

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

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

評価
SDLCの最終段階は、システムの有効性を測定し、潜在的な機能拡張を評価することなのだ。

ライフサイクル
管理・統制

管理統制に関連するSDLCのフェーズ。
SDLC フェーズの目的は、このセクションで主要な成果物、推奨されるタスクの説明、および効果的な管理のための関連する管理目標の概要とともに説明される。プロジェクトマネージャは、プロジェクトの実行中に管理目標を設定し、監視することが重要なのだ。管理目標は、望ましい結果や目的を明確に示すものであり、プロジェクトを通じて定義し、監視する必要があるのだ。管理目標は、図に示すように、主要なカテゴリー（ドメイン）に分類することができ、SDLCのフェーズに関連する。

実質的な SDLC の取り組みを管理・統制するために、作業内訳構造（WBS）は作業を捕捉し、スケジュールするのだ。WBSとすべてのプログラム資料は、プロジェクトノートの「プロジェクト説明」セクションに保管されるべきなのだ。[clarification needed] プロジェクトマネージャは、プロジェクトを最もよく説明するWBS形式を選択する。

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

ワークブレイクダウンが構造化された組織

ワーク・ブレイクダウン・ストラクチャー」。
WBSの上段は、プロジェクトのスコープとタイムラインの概要を説明する。また、主要なフェーズとマイルストーンを要約する必要があるのだ。中段は、SDLCのフェーズをベースにしているのだ。WBSの要素は、実施する活動ではなく、マイルストーンと完了するタスクで構成され、期限がある。各タスクには、測定可能なアウトプット（例えば、分析文書）がある。WBSのタスクは、1つまたは複数のアクティビティに依存する場合がある（例：コーディング）。請負業者のサポートが必要なプロジェクトの一部には、作業明細書（SOW）を作成する必要がある。SOW の開発は、SDLC の特定のフェーズで行われるのではなく、コントラクターが実施する可能性のある SDLC プロセスの作業を含むように開発される。

ベースライン
ベースライン[clarification needed]はSDLCの5つのフェーズのうち4つのフェーズの後に確立され、このモデルの反復的な性質にとって重要なのだ ベースラインはマイルストーンになる。

機能ベースライン：概念設計段階の後に確立される。
アロケーションベースライン：予備設計段階の後に確立される。
製品ベースライン：詳細設計・開発フェーズの後に確立される。
更新された製品ベースライン：生産建設フェーズの後に確立されます。
システム開発ライフサイクルには、7つのフェーズがあるのだ。それは、システム調査、分析、設計、テスト、訓練と移行、運用と保守、評価なのだ。