Loading article…
構造化システム分析設計手法（SSADM）は、情報システムの分析と設計に対するシステムアプローチである。SSADMは、 1980年以降、英国政府の中央コンピュータ・電気通信庁（政府における技術利用を担当する機関）向けに開発された。
SSADMは、情報システムの分析と設計のためのウォーターフォール型手法です。SSADMは、システム設計における厳密な文書主導型アプローチの頂点を極めたものと考えられ、DSDMやScrumといったより現代的なアジャイル手法とは対照的です。
SSADMは、その具体的な実装の一つであり、ピーター・チェックランドのソフトシステム手法、ラリー・コンスタンティンの構造化設計、エドワード・ヨードンのヨードン構造化手法、マイケル・A・ジャクソンのジャクソン構造化プログラミング、トム・デマルコの構造化分析など、さまざまな構造化分析および開発手法の学派の成果に基づいています。
「Structured Systems Analysis and Design Method」および「SSADM」という名称は、英国財務省傘下の政府商務局（OGC）の登録商標です。 [ 1 ]
構造化システム分析設計手法の開発の主な段階は次のとおりです。[ 2 ]
SSADMで使用される最も重要な3つの手法は以下のとおりです。
SSADMメソッドは、以下の事項に関する一連の分析、文書化、および設計タスクの適用を伴います。
特定のプロジェクトが実現可能かどうかを判断するには、プロジェクトの目標と影響について何らかの調査を行う必要があります。非常に小規模なプロジェクトの場合、プロジェクトの範囲が容易に理解できるため、このような調査は全く必要ないかもしれません。大規模なプロジェクトでは、正式な調査を行う時間がない場合や、プロジェクトが「必須」であり、いずれにせよ実行しなければならない場合など、非公式な形で実現可能性の検討が行われることがあります。データフロー図は、現在のシステムがどのように機能するかを説明し、既知の問題を視覚化するために使用されます。
実現可能性調査を実施する際には、主に以下の4つの点が検討対象となります。
技術面：プロジェクトは技術的に実現可能か？ 財務面：企業はプロジェクトを実行するだけの資金力があるか？ 組織面：新しいシステムは既存の業務慣行と互換性があるか？ 倫理面：新しいシステムの影響は社会的に受け入れられるものか？
これらの疑問に答えるため、実現可能性調査は、包括的なシステム分析と設計を凝縮した実質的なバージョンと言えます。要件と用途が一定程度分析され、いくつかのビジネスオプションが策定され、技術的な実装の詳細もいくつか示されます。この段階の成果物は、正式な実現可能性調査文書です。SSADMでは、構築された予備モデル、却下されたオプションの詳細、および却下理由など、調査に含めるべき項目を規定しています。
SSADMの開発者は、たとえそれが完全に人と紙で構成されているとしても、ほぼすべての場合において何らかの既存のシステムが存在することを理解していました。従業員へのインタビュー、アンケートの配布、観察、既存の文書を組み合わせることで、アナリストはプロジェクト開始時点でのシステムの現状を完全に理解することができます。これは多くの目的に役立ちます（例など）。
アナリストは、既存システムの調査を終えた後、新システムの全体設計を決定する必要があります。そのためには、前の段階で得られた結果を基に、ビジネスシステムの選択肢をいくつか作成します。これらの選択肢は、現状維持から既存システムを完全に廃止して全く新しいシステムを構築するまで、新システムを構築するための様々な方法を示しています。アナリストは、できるだけ多くの多様なアイデアを生み出すために、ブレインストーミングセッションを実施することもあります。
アイデアは集約され、ユーザーに提示される選択肢となります。これらの選択肢は、以下の点を考慮しています。
必要に応じて、そのオプションは論理データ構造とレベル1のデータフロー図を用いて文書化されます。
ユーザーとアナリストは共同で単一のビジネスオプションを選択します。これは既に定義されているオプションのいずれかである場合もあれば、既存のオプションのさまざまな側面を組み合わせたものである場合もあります。この段階の成果物は、選択された単一のビジネスオプションと、実現可能性調査段階のすべての成果物です。
これはおそらくSSADMの中で最も複雑な段階です。第1段階で策定された要件に基づき、選択されたビジネスオプションの枠組みの中で、アナリストは新しいシステムが果たすべき役割を完全に論理的に記述した仕様書を作成する必要があります。この仕様書は、誤り、曖昧さ、矛盾があってはなりません。ここで言う「論理的」とは、仕様書がシステムの実装方法ではなく、システムが果たす役割を記述していることを意味します。
論理仕様を作成するために、アナリストはデータフロー図（DFD）と論理データモデル（LDM）の両方に必要な論理モデルを構築します。論理データモデルは、論理データ構造（他の手法ではエンティティ関係図と呼ばれる）と、データおよびその関係の完全な記述で構成されます。これらは、ユーザーがシステムに要求するすべての機能の機能定義、エンティティのライフサイクル全体を通してのすべてのイベントを記述するエンティティライフサイクル（ELH）、および各イベントが関連するすべてのエンティティとどのように相互作用するかを記述する効果対応図（ECD）を作成するために使用されます。これらは要件と継続的に照合され、必要に応じて要件が追加され、完成されます。
この段階の成果物は、以下の要素で構成される完全な要件仕様書です。
この段階は、新しいシステムアプリケーションの物理的な実装に向けた最初のステップです。ビジネスシステムオプションと同様に、この段階では新しいシステムの実装に関する多数のオプションが生成されます。これらは2つか3つに絞り込まれ、ユーザーに提示されます。ユーザーはその中から最終的なオプションを選択または統合します。
しかし、考慮すべき点は全く異なり、以下の通りである。
これらのすべての側面は、利用可能な資金やハードウェアおよびソフトウェアの標準化など、事業によって課されるあらゆる制約にも適合しなければならない。
この段階の成果物は、選択された技術システムオプションです。
前の段階では実装の詳細が規定されているが、この段階の成果物は実装に依存せず、ヒューマンコンピュータインターフェースの要件に重点を置く。論理設計では、メニュー構造とコマンド構造の観点から、主な対話方法が規定される。
活動領域の一つは、ユーザーダイアログの定義です。これらは、ユーザーがシステムとやり取りする主要なインターフェースとなります。その他の活動は、システム更新におけるイベントの影響と、システム上のデータに関する照会の必要性の両方を分析することに関係しています。これらの活動はいずれも、ステージ3で作成されたイベント、機能記述、および効果対応図を使用して、データを一貫性のある安全な方法で更新および読み取る方法を正確に決定します。
この段階の成果物は、以下の要素から構成される論理設計です。
これは最終段階であり、システムの論理仕様をすべて、実際のハードウェアとソフトウェアの観点からシステムを記述するものです。非常に技術的な段階であるため、ここでは簡単な概要を説明します。
論理データ構造は、データベース構造という観点から物理アーキテクチャに変換されます。関数の正確な構造と実装方法が規定されます。物理データ構造は、サイズとパフォーマンスの要件を満たすために必要に応じて最適化されます。
この製品は、ソフトウェアエンジニアがハードウェアとソフトウェアの具体的な詳細を適切な規格に準拠して構築する方法を示す、完全な物理設計書です。