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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェア開発ライフサイクルのモデル、メンテナンスフェーズを強調

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

概要

システム開発ライフサイクルは、システムエンジニアとシステム開発者が情報システムの計画、設計、構築、テスト、および提供を行うために使用する、明確に定義された明確な作業フェーズの数で構成されています。 SDLCは、組立ラインで製造されるものと同様に、スケジュールされた時間枠とコスト見積もりの​​範囲内で、明確に定義された各フェーズを通過するシステムを提供することにより、顧客の要件に基づいて、顧客の期待に応える、またはそれを超える高品質のシステムを作成することを目指しています。[3] コンピュータシステムは複雑で、多くの場合(特に、サービス指向アーキテクチャの最近の台頭により))異なるソフトウェアベンダーによって提供される可能性のある複数の従来のシステムをリンクします。このレベルの複雑さを管理するために、ウォーターフォールスパイラルアジャイルソフトウェア開発ラピッドプロトタイピングインクリメンタル、同期および安定化など、多数のSDLCモデルまたは方法論が作成されています[4]

SDLCは、アジャイルから反復、シーケンシャルの方法論のスペクトルに沿って説明できます。XPスクラムなどのアジャイル手法は、開発サイクルに沿って(必ずしもSDLCアプローチのパターンに従わなくても)迅速な変更を可能にする軽量プロセスに焦点を合わせています。Rational Unified Process動的システム開発方法などの反復方法論は、限られたプロジェクト範囲と、複数の反復による製品の拡張または改善に焦点を合わせています。ウォーターフォールなどのシーケンシャルまたはビッグデザインアップフロント(BDUF)モデルは、大規模なプロジェクトとリスクを成功した予測可能な結果に導くための完全で正しい計画に焦点を当てています。[要出典]アナモルフィック開発などの他のモデルは、プロジェクトの範囲と機能開発の適応反復によって導かれる開発の形式に焦点を当てる傾向があります。

プロジェクト管理プロジェクトは、との両方を定義することができ、プロジェクトのライフサイクルわずかに異なる活動が起こる時、(PLC)とSDLC。テイラー(2004)によると、「プロジェクトのライフサイクルは、すべての活動を包含するプロジェクトをシステム開発ライフサイクルは、製品の実現に焦点を当てながら、要件を」。[5]

SDLCは、それ自体が方法論ではなく、ソフトウェアアプリケーションのライフサイクルのフェーズの説明です。広い意味では、これらのフェーズは、調査、分析、設計、構築、テスト、実装、および保守とサポートです。すべてのソフトウェア開発方法論はSDLCフェーズに従いますが、それを行う方法は方法論によって大きく異なります。たとえば、スクラムフレームワーク[6]では、1人のユーザーストーリーが1回の2週間のスプリント内でSDLCのすべてのフェーズを通過すると言うことができます。これをウォーターフォール手法と比較してください。別の例として、すべてのビジネス要件(SDLCの分析フェーズでビジネス要件仕様と呼ばれるドキュメントに記録されています)[要出典]機能/機能の説明(機能仕様と呼ばれるドキュメントの設計段階で記録されます)に変換され、通常3〜9か月以上の期間にわたって、ソリューション機能のコレクションとしてすべて一度に構築されます。[要出典]これらの方法論は異なるアプローチですが、どちらも要件が発生するSDLCフェーズを含み、ライフサイクルフェーズを経て、メンテナンスとサポートの最終フェーズで終了します。その後、ライフサイクル全体が通常開始されます。ソフトウェアアプリケーションの後続バージョンについても同様です。[要出典]

歴史と詳細

製品のライフサイクルは、製品の人生の各段階を反復する、非常に、意図的な構造および方法論のように情報システムを構築するためのプロセスについて説明します。 Elliott&Strachan&Radford(2004)によると、システム開発ライフサイクルは、「1960年代に始まり、大規模なビジネスコングロマリットの時代に大規模な機能的なビジネスシステムを開発しました。情報システムの活動は、大量のデータ処理数の処理中心に展開されました。ルーチン」。[7]

1980年代に英国政府商務省向けに作成された構造化システム分析および設計手法(SSADM)など、いくつかのシステム開発フレームワークは部分的にSDLCに基づいています。それ以来、Elliott(2004)によると、「システム開発に対する従来のライフサイクルアプローチは、従来のSDLCに固有の欠陥のいくつかを克服しようとする代替アプローチおよびフレームワークにますます置き換えられてきました」。[7]

フェーズ

システム開発ライフサイクルフレームワークは、システム設計者と開発者が従うべき一連のアクティビティを提供します。これは、SDLCの各フェーズが前のフェーズの結果を使用する一連のステップまたはフェーズで構成されます。[8] [9]

SDLCは、開発者にとって不可欠な重要なフェーズ(計画分析設計実装など)に準拠しており、以下のセクションで説明します。これには、現在使用されているシステムの評価、情報収集、実現可能性調査、および承認の要求が含まれます。ウォーターフォール、ファウンテン、スパイラル、ビルドと修正、ラピッドプロトタイピング、インクリメンタル、同期、安定化など、多数のSDLCモデルが作成されています。[10] [11]これらの中で最も古く、最もよく知られているのはウォーターフォールモデルです。これは、各ステージの出力が次のステージの入力になる一連のステージです。[9]これらの段階は、次のようなさまざまな方法で特徴づけられ、分割することができます。[8] [9] [12] [13]

システム開発ライフサイクルの10フェーズバージョン[8]
  • 予備分析予備分析から始めて、代替ソリューションを提案し、コストとメリットを説明し、推奨事項を含む予備計画を提出します。
  1. 予備分析を実施します。組織の目的と、調査中の問題の性質と範囲を発見します。問題が組織自体のごく一部にのみ関係している場合でも、組織自体の目的が何であるかを調べてください。次に、調査中の問題がどのようにそれらに適合するかを確認します。
  2. 代替ソリューションの提案:組織の目的と特定の問題を掘り下げた後、いくつかのソリューションが発見された可能性があります。ただし、代替案は、従業員、クライアント、サプライヤー、および/またはコンサルタントへのインタビューから得られる場合があります。競合他社が何をしているのかを調査することによっても洞察を得ることができます。
  3. 費用便益分析:提案された変更を実装することの費用と便益を分析して説明します。最終的に、システムをそのままにするか、システムを改善するか、新しいシステムを開発するかについての最終的な決定は、これと残りの予備分析データによって導かれます。
  • システム分析、要件定義:プロジェクトの目標を、目的のアプリケーションの定義された機能と操作に定義します。これには、事実の収集と解釈、問題の診断、およびシステムの改善の推奨のプロセスが含まれます。プロジェクトの目標は、エンドユーザー情報のニーズを分析し、これらの要件の不整合や不完全さを取り除くことでさらに支援されます。
開発者が従う一連のステップは次のとおりです。[14]
  1. 事実の収集:ドキュメント、クライアントインタビュー、観察、およびアンケートを通じてエンドユーザーの要件を取得します。
  2. 既存のシステムの精査:現在のシステムの長所と短所を特定して、長所を引き継ぎ、新しいシステムの短所を回避します。
  3. 提案されたシステムの分析:ステップ2で説明した欠点の解決策を見つけ、特定のユーザー提案を使用して仕様を準備します。
  • システム設計:このステップでは、画面レイアウト、ビジネスルールプロセスダイアグラム擬似コード、その他のドキュメントなど、必要な機能と操作について詳しく説明します。
  • 開発:実際のコードはここに書かれています。
  • 統合とテスト:すべてのモジュールが特別なテスト環境にまとめられ、エラー、バグ、相互運用性がチェックされます。
  • 受け入れ、インストール、展開:これは初期開発の最終段階であり、ソフトウェアが本番環境に移行して実際のビジネスを実行します。
  • メンテナンス:SDLCのメンテナンス段階では、システムが陳腐化しないように評価/評価されます。これは、初期ソフトウェアに変更が加えられる場所でもあります。
  • 評価:一部の企業はこれをSDLCの公式段階とは見なしていませんが、他の企業はこれを保守段階の延長と見なしており、一部のサークルでは実装後のレビューと呼ばれる場合があります。ここで、開発されたシステムとプロセス全体が評価されます。回答が必要な質問には、新しく実装されたシステムが初期のビジネス要件と目的を満たしているかどうか、システムが信頼性が高くフォールトトレラントであるかどうか、承認された機能要件に従って機能するかどうかなどがあります。リリースされたソフトウェアを評価することに加えて、開発プロセスの有効性を評価することも重要です。経営陣が満足していないプロセス全体(または特定の段階)の側面がある場合、これは改善する時期です。
  • 廃棄:このフェーズでは、システム情報、ハードウェア、およびソフトウェアの使用を中止し、新しいシステムに移行するための計画が作成されます。ここでの目的は、機密データの不正開示の可能性を防ぐ方法で、置き換えられる情報、ハードウェア、およびソフトウェアを適切に移動、アーカイブ、破棄、または破棄することです。廃棄活動により、新しいシステムへの適切な移行が保証されます。以前のシステムで処理されたデータの適切な保存とアーカイブに特に重点が置かれています。これはすべて、組織のセキュリティ要件に従って実行する必要があります。[15]

次の図では、システム開発ライフサイクルのこれらの段階が、IT作業成果物の定義から作成および変更までの10のステップに分割されています。

すべてのプロジェクトでフェーズを順番に実行する必要があるわけではありません。ただし、フェーズは相互に依存しています。プロジェクトのサイズと複雑さに応じて、フェーズが組み合わされたり、重複したりする場合があります。[8]

システム調査

まず、ITシステムの提案を検討します。このステップでは、影響を受ける可能性のある現在のすべての優先順位と、それらの処理方法を検討します。システム計画を行う前に、実現可能性調査を実施して、新しいシステムまたは改善されたシステムを作成することが実行可能なソリューションであるかどうかを判断する必要があります。これは、完了に必要なコスト、メリット、リソース要件、および特定のユーザーニーズを判断するのに役立ちます。開発プロセスは、経営陣が実現可能性調査からの推奨事項を承認した場合にのみ続行できます。[16]

以下は、実現可能性調査のさまざまな要素を表しています。

分析

分析の目的は、システムを修正するために、問題がどこにあるかを判別することです。このステップでは、システムをさまざまな部分に分解して状況を分析し、プロジェクトの目標を分析し、作成する必要があるものを分解し、明確な要件を定義できるようにユーザーを関与させようとします。

デザイン

システムの設計、設計機能および動作は、画面レイアウト、ビジネスルール、プロセス図、および他の文書を含め、詳細に記載されています。このステージの出力は、新しいシステムをモジュールまたはサブシステムのコレクションとして記述します。

設計段階では、承認された要件ドキュメントで特定された要件を最初の入力として使用します。要件ごとに、インタビュー、ワークショップ、および/またはプロトタイプの取り組みの結果として、1つまたは複数の設計要素のセットが作成されます。

設計要素は、必要なシステム機能を詳細に記述し、通常、機能階層図、画面レイアウト図、ビジネスルールの表、ビジネスプロセス図、疑似コード、および完全なデータディクショナリを備えた完全なエンティティ関係図を含みます。これらの設計要素は、熟練した開発者やエンジニアが最小限の追加入力設計でシステムを開発および提供できるように、システムを十分に詳細に説明することを目的としています。

環境

環境は、システム開発者がSDLCを移動するシステムを構築、配布、インストール、構成、テスト、および実行できる制御された領域です。各環境はSDLCのさまざまな領域に合わせて調整されており、特定の目的を持つことを目的としています。このような環境の例には、次のものがあります。

  • 開発環境。開発者は、自分の作業を他の作業とマージしようとする前に、互いに独立して作業できます。
  • 統合された作業を結合されたシステムとして一緒に構築できる共通の構築環境
  • システム統合テスト環境。システムの統合が他のアップストリームまたはダウンストリームシステムを指す基本的なテストをテストできます。
  • ビジネスの利害関係者が元のビジネス要件に対してテストできるユーザー受け入れテスト環境
  • 実稼働環境。システムは、意図したエンドユーザーによる最終的な使用のために最終的に展開されます。

テスト

コードは、ソフトウェアテストのさまざまなレベルでテストされますユニット、システム、およびユーザーの受け入れテストが頻繁に実行されます。これは灰色の領域です。テストの段階と、反復が発生した場合の量について、さまざまな意見があります。反復は通常、ウォーターフォールモデルの一部ではありませんが、展開前に欠陥を修正し、修正を検証する手段がこのフェーズに組み込まれています。

以下は、開発中のシステムのタイプに応じて、関連する可能性のあるテストのタイプです。

トレーニングと移行

適切なテストによってシステムが安定すると、SDLCは、システムをサポートスタッフとエンドユーザーに移行する前に、システムの適切なトレーニングが実行または文書化されていることを確認します。トレーニングには通常、システムのサポートを担当する人向けの運用トレーニングと、実稼働環境に導入した後にシステムを使用するエンドユーザー向けのトレーニングが含まれます。

トレーニングが正常に完了すると、システムエンジニアと開発者は、システムを最終的な実稼働環境に移行します。この環境では、エンドユーザーが使用し、サポートおよび運用スタッフがサポートすることを目的としています。

運用・保守

システム展開には、システムの廃止または廃止前のさまざまな変更と機能強化が含まれます。システムの保守は、SDLCの非常に重要な側面です。主要な担当者が組織内のポジションを変更すると、新しい変更が実装されます。システム開発には、従来のアプローチ(構造化)とオブジェクト指向の2つのアプローチがあります情報工学には、構造化分析および設計手法とも呼ばれる従来のシステムアプローチが含まれます。オブジェクト指向のアプローチでは、情報システムを、完全で完全な情報システムを作成するために相互に統合されたオブジェクトのコレクションと見なします。


評価

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

システム分析と設計

システム分析と設計(SAD)は、ハードウェア、ソフトウェア、データ、プロセス、および人員を効果的に使用して会社のビジネス目標をサポートする情報技術システム(ITS)を開発するプロセスです。これは、特定の要件を満たすようにコンポーネントまたはモジュールを定義することにより、新しいビジネスシステムを計画するか、既存のシステムを置き換えるプロセスです。システムの分析と設計は、メタ開発活動と見なすことができます。これは、ステージを設定し、問題を解決するのに役立ちます。 SADを活用して、機能分析ドメインと非機能分析ドメインの競合する高レベル要件間の正しいバランスを設定できます。システム分析と設計は、分散型エンタープライズアーキテクチャ、エンタープライズITアーキテクチャ、およびビジネスアーキテクチャと強力に相互作用し、パーティショニング、インターフェイス、ペルソナ、役割などの概念に大きく依存しています。高レベルのシステム記述に到達するための展開/運用モデリング。次に、この高レベルの説明は、ビジネス目標を達成するために個別に分析、設計、構築し、統合できるコンポーネントとモジュールにさらに分解されます。 SDLCとSADは、完全なライフサイクル製品およびシステム計画の基礎です。

オブジェクト指向分析

オブジェクト指向分析(OOA)は、タスク(問題領域とも呼ばれますを分析して、タスクを完了するために使用できる概念モデルを開発するプロセスです。典型的なOOAモデルは、顧客定義の一連の要件を満たすために使用できるコンピューターソフトウェアを記述します。問題解決の分析段階で、プログラマーは、書面による要件ステートメント、正式なビジョンドキュメント、または利害関係者やその他の利害関係者へのインタビューを検討する場合があります。対処するタスクは、いくつかのサブタスク(またはドメイン)に分割される場合があり、それぞれが異なるビジネス、技術、またはその他の関心領域を表します。各サブタスクは個別に分析されます。実装の制約(例:並行性分散永続性、またはシステムの構築方法)は、分析フェーズでは考慮されません。むしろ、それらはオブジェクト指向設計(OOD)中に対処されます。

OOAから得られる概念モデルは、通常、一連のユースケース、1つ以上のUML クラス図、およびいくつかの相互作用図で構成されます。また、ある種のユーザーインターフェイスのモックアップが含まれる場合もあります

オブジェクト指向設計の入力は、オブジェクト指向分析の出力によって提供されますオブジェクト指向設計の入力として機能するために、出力アーティファクトを完全に開発する必要はないことを認識してください。分析と設計は並行して行われる可能性があり、実際には、1つのアクティビティの結果が、反復プロセスを通じて短いフィードバックサイクルで他のアクティビティにフィードされる可能性があります。分析と設計の両方を段階的に実行でき、アーティファクトを1回のショットで完全に開発するのではなく、継続的に成長させることができます。

オブジェクト指向のいくつかの典型的な(しかしすべてのタイプの設計分析に共通の)入力アーティファクト:

  • 概念モデル:概念モデルはオブジェクト指向分析の結果であり、問​​題領域の概念をキャプチャします。概念モデルは、並行性やデータストレージなどの実装の詳細から独立するように明示的に選択されます。
  • ユースケース:ユースケースは、システムが何か有用なことを実行することにつながる一連のイベントの説明です。各ユースケースは、特定のビジネス目標または機能を達成するために、システムがアクターと呼ばれるユーザーとどのように対話するかを伝える1つ以上のシナリオ提供します。ユースケースアクターは、エンドユーザーまたは他のシステムである可能性があります。多くの場合、ユースケースはユースケース図にさらに詳しく説明されています。ユースケース図は、アクター(ユーザーまたは他のシステム)とそれらが実行するプロセスを識別するために使用されます。
  • システムシーケンス図:システムシーケンス図(SSD)は、ユースケースの特定のシナリオについて、外部アクターが生成するイベント、それらの順序、および考えられるシステム間イベントを示す図です。
  • ユーザーインターフェイスのドキュメント(該当する場合):最終製品のユーザーインターフェイスのルックアンドフィールを示し、説明するドキュメントこれは必須ではありませんが、最終製品を視覚化するのに役立ち、したがって設計者に役立ちます。
  • リレーショナルデータモデル(該当する場合):データモデルは、データの表現方法と使用方法を説明する抽象的なモデルです。オブジェクトデータベースを使用しない場合、オブジェクトリレーショナルマッピング用に選択された戦略はOO設計プロセスの出力であるため、通常、リレーショナルデータモデルは設計の前に作成する必要があります。ただし、リレーショナルデータモデルとオブジェクト指向の設計アーティファクトを並行して開発することは可能であり、アーティファクトの成長は他のアーティファクトの改良を刺激する可能性があります。

ライフサイクル

管理と制御

管理制御に関連するSPIUフェーズ[17]

SDLCフェーズは、プロジェクトアクティビティのプログラムガイドとして機能し、プロジェクトの範囲に一致する深さまでプロジェクトを実施するための柔軟で一貫した方法を提供します。このセクションでは、SDLCフェーズの各目標について、主要な成果物、推奨されるタスクの説明、および効果的な管理のための関連する制御目標の概要とともに説明します。プロジェクトマネージャーは、プロジェクトの実行中にSDLCの各フェーズで管理目標を設定および監視することが重要です。制御目標は、望ましい結果または目的の明確なステートメントを提供するのに役立ち、SDLCプロセス全体で使用する必要があります。制御目標は、主要なカテゴリ(ドメイン)にグループ化でき、図に示すようにSDLCフェーズに関連します。[17]

SDLCイニシアチブを管理および制御するには、各プロジェクトで、プロジェクトを完了するために必要な作業をキャプチャしてスケジュールするためのある程度の作業分解図(WBS)を確立する必要があります。 WBSとすべてのプログラム資料は、プロジェクトノートブックの「プロジェクトの説明」セクションに保管する必要があります。 WBS形式は、ほとんどの場合、プロジェクト作業を最もよく表す方法で確立するためにプロジェクトマネージャーに任されています。

SDLCポリシーの一部としてWBSで定義する必要のある重要な領域がいくつかあります。次の図は、プロジェクトマネージャーによって確立された方法でWBSで対処される3つの主要な領域を示しています。[17]この図は、カバレッジがSDLCの多数のフェーズにまたがっていることを示していますが、関連するMCDにはSDLCフェーズへのプライマリマッピングのサブセットがあります。たとえば、分析と設計は主に取得と実装のドメインの一部として実行され、システムの構築とプロトタイプは主に配信とサポートの一部として実行されます。

作業分解図の構造化された組織

作業分解図[17]

作業分解図(WBS)の上部セクションでは、プロジェクトの主要なフェーズとマイルストーンを要約して特定する必要があります。さらに、上部のセクションでは、プロジェクトの全範囲とタイムラインの概要を説明する必要があり、プロジェクトの承認につながる最初のプロジェクトの説明作業の一部になります。 WBSの中央のセクションは、WBSタスク開発のガイドとしての7つのシステム開発ライフサイクルフェーズに基づいています。 WBS要素は、「アクティビティ」ではなくマイルストーンと「タスク」で構成され、明確な期間(通常は2週間以上)を持つ必要があります。各タスクには、測定可能な出力(ドキュメント、決定、分析など)が必要です。 WBSタスクは、1つ以上のアクティビティ(ソフトウェアエンジニアリング、システムエンジニアリングなど)に依存する場合があり、他のタスクとの緊密な調整が必要になる場合があります。プロジェクトの内部または外部のいずれか。請負業者からのサポートが必要なプロジェクトのどの部分にも、SDLCフェーズからの適切なタスクを含めるために作成された作業範囲記述書(SOW)。SOWの開発は、SDLCの特定のフェーズでは発生しませんが、請負業者などの外部リソースによって実行される可能性のあるSDLCプロセスからの作業を含むように開発されます。[17]

ベースライン

ベースラインは、システム開発ライフサイクルの重要な部分です。これらのベースラインは、SDLCの5つのフェーズのうち4つ後に確立され、モデルの反復性にとって重要です。[18]各ベースラインは、SDLCのマイルストーンと見なされます。

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

補完的な方法論

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

方法論アプローチの比較(Post、&Anderson 2006)[19]
SDLC RAD オープンソース オブジェクト JAD プロトタイピング エンドユーザー
コントロール 丁寧 MIS 弱い 基準 ジョイント ユーザー ユーザー
時間枠 長さ 短い 中くらい どれでも 中くらい 短い 短い

ユーザー 多くの 少し 少し 不定 少し 一つか二つ 一つ
MISスタッフ 多くの 少し 数百 スプリット 少し 一つか二つ なし
トランザクション/ DSS 取引 両方 両方 両方 DSS DSS DSS
インターフェース 最小限 最小限 弱い ウィンドウズ 重要 重要 重要
ドキュメントとトレーニング 重要 限定 内部 オブジェクト内 限定 弱い なし
整合性とセキュリティ 重要 重要 わからない オブジェクト内 限定 弱い 弱い
再利用性 限定 いくつか 多分 重要 限定 弱い なし

長所と短所

多くの最新の方法論がこの考え方に取って代わったため、現代のコンピューティングの世界では、SDLCに厳密なウォーターフォールモデルを使用する人はほとんどいません。SDLCはアジャイルコンピューティングのようなモデルには適用されなくなったと主張する人もいますが、それでもテクノロジー界で広く使用されている用語です。SDLCの実践には、構造化環境により適したシステム開発の従来のモデルに利点があります。SDLC方法論を使用することの不利な点は、反復型開発が必要な場合、または利害関係者が設計中のソフトウェアを定期的にレビューする必要がある場合(つまり、Web開発またはeコマース)です。

SDLCの長所と短所の比較:

SDLCの長所と短所 [19]
強み 弱点
コントロール 開発時間の増加
大規模なプロジェクトを監視する 開発コストの増加
詳細な手順 システムは事前に定義する必要があります
コストと完了目標を評価する 剛性
ドキュメンテーション コストを見積もるのが難しい、プロジェクトの超過
明確に定義されたユーザー入力 ユーザー入力が制限される場合があります
メンテナンスのしやすさ 少し並列性
開発および設計基準 ドキュメントと標準の自動化は制限されています
人員配置のMISの変更を許容します 要件の変更を許容しません
結果の早い段階で缶詰にされたプロジェクトは、ほとんどまたはまったく価値がありません

SDLCの代替手段は、プロトタイピング、共同アプリケーション開発、およびCASEツールの実装を組み合わせた迅速なアプリケーション開発です。RADの利点は、速度、開発コストの削減、および開発プロセスへの積極的なユーザーの関与です。

システムライフサイクル

システムエンジニアリングにおけるシステムライフサイクルは、システムの構想、設計と開発、生産および/または建設、流通、運用、保守とサポート、廃止、段階的廃止を含む、その存在のすべての段階に対処するシステムまたは提案されたシステムのビューです。と廃棄。[20]

コンセプトデザイン

概念設計段階が同定必要性が検討されている段階であり、潜在的な解決策のための要件が定義され、潜在的な解決策が評価され、システム仕様が開発されています。システム仕様は、システム設計の全体的なガイダンスを提供する技術要件を表しています。このドキュメントは将来のすべての開発を決定するため、システム仕様が動機付けのニーズに適切に対応していると概念設計レビューが決定するまで、この段階を完了することはできません

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

  • 身分証明書が必要
  • 実行可能性分析
  • システム要件分析
  • システム仕様
  • コンセプトデザインレビュー

予備的なシステム設計

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

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

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

たとえば、Viti Bankのシステムアナリストとして、あなたは現在の情報システムを調査する任務を負っています。Viti Bankは、フィジーで急成長している銀行です。遠隔地の農村地域の顧客は、銀行サービスにアクセスするのが難しいと感じています。銀行のサービスにアクセスする場所に移動するには、数日から数週間かかります。銀行は、顧客のニーズを満たすというビジョンを持って、現在のシステムを調査し、ニーズを満たすために現在のシステムを提供する方法のソリューションまたは推奨事項を考え出すようにサービスに要求しました。

詳細設計と開発

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

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

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

生産と建設

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

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

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

利用とサポート

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

使用率とサポートの段階での主な手順は次のとおりです。

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

段階的廃止と廃棄

システムの有効性と効率を継続的に評価して、製品が最大有効ライフサイクルに達した時期を判断する必要があります。[22]考慮事項には、運用上のニーズの継続的な存在、運用要件とシステムパフォーマンスの一致、システムの段階的廃止と保守の実現可能性、および代替システムの可用性が含まれます。

も参照してください

参考文献

  1. ^ 開発アプローチの選択2014年7月17日取得。
  2. ^ Parag C. Pendharkara; ジェームズA.ロジャーブ; Girish H. Subramanian(2008年11月)。「ソフトウェア開発努力のコッブ・ダグラス生産関数特性の実証的研究」。情報およびソフトウェア技術50(12):1181–1188。土井10.1016 /j.infsof.2007.10.019
  3. ^ 「システム開発ライフサイクルから」FOLDOC 取得した2013年6月14日を
  4. ^ 「ソフトウェア開発ライフサイクル(SDLC)」
  5. ^ テイラー、ジェームス(2004)。情報技術プロジェクトの管理NS。39。
  6. ^ 「スクラムとは何ですか?」2019年12月24日。
  7. ^ a b Geoffrey Elliott&Josh Strachan(2004)グローバルビジネス情報テクノロジーp.87。
  8. ^ a b c d 米国司法省(2003)。情報資源管理第1章はじめに。
  9. ^ a b c Everatt、GD; McLeod Jr.、R。(2007)「第2章:ソフトウェア開発ライフサイクル」ソフトウェアテスト:ソフトウェア開発ライフサイクル全体にわたるテストジョン・ワイリー&サンズ。pp。29–58。ISBN 9780470146347CS1 maint: multiple names: authors list (link)
  10. ^ Unhelkar、B。(2016)。アジャイル実践の芸術:プロジェクトと組織のための複合アプローチCRCプレス。pp。56–59。ISBN 9781439851197
  11. ^ 土地、SK; スミス、DB; Walz、JW(2012)。リーンシックスシグマソフトウェアプロセス定義の実用的なサポート:IEEEソフトウェアエンジニアリング標準の使用ジョン・ワイリー&サンズ。pp。341–3。ISBN 9780470289952CS1 maint: multiple names: authors list (link)
  12. ^ ケイ、ラッセル(2002年5月14日)。「QuickStudy:システム開発ライフサイクル」ComputerWorld
  13. ^ テイラー、GD(2008)。ロジスティクス工学入門CRCプレス。pp。12.6–12.18。ISBN 9781420088571
  14. ^ 制御と監査、情報システム。SDLC(2013年8月版)。第5章:インド勅許会計士協会。NS。5.28。CS1 maint: location (link)
  15. ^ Radack、S。(nd)。「システム開発ライフサイクル(SDLC)」(PDF)米国国立標準技術研究所。
  16. ^ マラカス、ジェームズA.オブライエン、ジョージM.(2010)。経営情報システム(第10版)。ニューヨーク:McGraw-Hill / Irwin。pp。485–489。ISBN 978-0073376813
  17. ^ a b c d e 米国下院(1999)。システム開発ライフサイクルポリシーp.13。
  18. ^ Blanchard、BS、& Fabrycky、WJ(2006)システムエンジニアリングと分析(第4版)ニュージャージー:プレンティスホール。p.31
  19. ^ a b Post、G。、&Anderson、D。、(2006)。経営情報システム:情報技術によるビジネス上の問題の解決(第4版)。ニューヨーク:マグロウヒルアーウィン。
  20. ^ Blanchard and Fabrycky(2006)。システム工学と分析、第4版プレンティスホール。NS。19。
  21. ^ Joahn Gouws博士(2007)。工学入門、システム工学Melikon Pty Ltd.
  22. ^ カニンガム、ジェームズ。「HERCメンテナンス」ファーゴXXI(ノースアベニュー):49 検索された5月13 2009

さらに読む

  • カミングス、ハーグ(2006)。情報時代の経営情報システムトロント、マグロウヒル・ライアーソン
  • Beynon-Davies P.(2009)ビジネス情報システムパルグレイブ、ベイジングストーク。ISBN 978-0-230-20368-6 
  • Computer World、2002年、2006年6月22日にワールドワイドウェブから取得:
  • 経営情報システム、2005年、2006年6月22日にワールドワイドウェブから取得:

外部リンク