WikiDer > Analyse und Entwurfsmethode für strukturierte Systeme

Structured Systems Analysis and Design Method

SSADM ist englisch für "Structured Systems Analysis and Design Method" und bedeutet auf Niederländisch "Gestructured Method for Analysis and Design of Systems". Es ist eine Sammlung Methoden und Techniken, das während der Analyse- und Entwurfsphase von . verwendet wird Systementwicklung.

Die SSADM-Methode ist a Wasserfallmethode, erfolgt der Entwurf einer Softwareanwendung nach dieser Methode in klar getrennten Phasen. SSADM verwendet eine Kombination aus Text und Diagrammen während des gesamten Lebenszyklus eines Systemdesigns, von der ersten Designidee bis zum endgültigen physischen Design der Anwendung.

Vorwort

SSADM wurde in 1980 entwickelt von LBMS (Learmonth & Burchett Management Systems) für den IT-Dienst der britischen Regierung, die CCTA (Central Computing and Telecommunications Agency).

John Hall war der ursprüngliche Designer von SSADM, er ist mit Keith Robinson der Entwickler von Version 1. Sie verließen LBMS 1983, um Modellsysteme zu etablieren.

Die britische Regierung hatte die Entwicklung einer Standardmethode für die Gestaltung von Regierungssoftware in Auftrag gegeben. Bevor dieser Standard verwendet wurde, gab es keine klaren Regeln, wie IT-Projekte entwickelt werden sollten. Infolgedessen oft Unternehmen Anforderungen wurden nicht vollständig erreicht, die Analysen waren nicht gut und die Projekte waren schlecht vergleichbar.

In den nächsten 15 Jahren wurde die Methodik erweitert, um interaktive Benutzerschnittstellen, Sprachen der vierten Generation, Client-Server-Technologie, neue Anwendungen und objektorientiertes Design zu unterstützen. CCTA machte die Technik allgemein verfügbar (behielt die Marke "SSADM" und das Copyright für die Referenzhandbücher bei) und führte eine formale Qualifikation für diese Technik ein; eine Ausbildungsakkreditierung oder ein Akkreditierungs- und Compliance-Schema für Programme und Techniken, die SSADM unterstützten.

SSADM wird vom DAB (Design Authority Board) verwaltet. Das NNC (National Computing Centre) entwickelt und verwaltet die endgültige SSADM-Dokumentation. Es ist ein offener Standard und daher für jedermann frei nutzbar.

Geschichte

  • 1980 ordnete die Central Computer and Telecommunications Agency (CCTA) die Schaffung eines Standards an.
  • 1981 Die von LBMS entwickelte Methode wurde aus 5 anderen möglichen Methoden ausgewählt.
  • 1983 Die britische Regierung machte die SSADM-Methode für alle neuen Regierungs-IT-Projekte obligatorisch.
  • 1984 Version 2 von SSADM veröffentlicht
  • 1986 Version 3 von SSADM veröffentlicht, Default wird nun auch vom UK NCC verwendet (Nationales Rechenzentrum)
  • 1988 Einführung des SSADM-Befähigungsnachweises
  • 1989 SSADM entspricht mehr den EUROMETHOD-Richtlinien, CASE-Produktzertifizierungsschema im SSADM-Standard enthalten
  • 1990 Version 4 veröffentlicht
  • 1993 SSADM V4 Standards und Tools Schema an SSADM Standard angehängt
  • 1995 SSADM V4 angekündigt, endlich V4.2 veröffentlicht
  • 1996 SSADM V4.3 veröffentlicht, diese Version zielt hauptsächlich auf die Entwicklung von Anwendungen mit einer grafischen Benutzeroberfläche ab.

Methode

SSDM verwendet a Wasserfallmethode für die Gestaltung eines Informationssystem.Die SSADM-Methode wird in der Machbarkeitsstudienphase, Analysephase und der Designphase in einem IT-Projekt verwendet. Die anderen Phasen fallen außerhalb der in SSADM beschriebenen Methoden.

Jede Phase innerhalb von SSADM ist in Phasen unterteilt, jede Phase ist weiter in Schritte unterteilt und jeder Schritt enthält wiederum eine Reihe von Aufgaben. Diese Unterteilung unterteilt ein Problem in kleine überschaubare Teilprobleme. Dies reduziert die Komplexität erheblich und verringert die Fehlerwahrscheinlichkeit.Ein weiterer Vorteil dieser Aufteilung besteht darin, dass die entstandenen Teile aufgeteilt werden können. Dadurch kann der Arbeitsaufwand reduziert und der Fortschritt leicht nachverfolgt werden.

Die SSADM-Methode verwendet einen strengen dokumentenorientierten Ansatz. Dies im Gegensatz zu den moderneren Schnelle Anwendungsentwicklung- (RAD) Methoden wie Dynamische Systementwicklungsmethode (DSDM).

Die SSADM-Methode geht davon aus, dass die 'Anforderungen“ (Wünsche) haben sich während der Entwicklungsphase eines Projekts nicht geändert.

Das Befolgen jedes Schrittes der SSADM-Methode kann zeitaufwändig sein und eine erhebliche Verzögerung zwischen Beginn und Lieferung verursachen. Der Vorteil: Je länger die Entwicklungszeit, desto größer ist die Chance, dass das System die geforderten Spezifikationen erfüllt. Aber es wird nicht den geschäftlichen Anforderungen zugute kommen.

Das Design von SSADM hat sich seit seiner ersten Veröffentlichung aufgrund von Benutzererfahrungen und neueren Methoden mehrmals geändert. SSADM wurde hauptsächlich aufgrund der Notwendigkeit wiederholter Schritte im Prozess weiterentwickelt. Dadurch grenzt oder überschneidet sich die Methode zunehmend an die RAD-Methoden. Trotz der Änderungen wurde SSADM, insbesondere die Wasserfallmethode, dafür kritisiert, dass die Erstellung eines Softwareprojekts viel mehr Zeit in Anspruch nimmt, ohne das Ergebnis der Projekte zu verbessern.

Phasenverschiebung

Die SSADM-Methode befasst sich mit einer Reihe von sequentiellen Analyse-, Dokumentations- und Designaufgaben zur Entwicklung einer Anwendung.

Phase 0: Machbarkeit (Machbarkeitsstudie)

In dieser Phase wird kurz geprüft, ob das vorgeschlagene Informationssystem innerhalb der gestellten Geschäftsanforderungen umsetzbar ist und ob nicht bereits ein ähnliches System entwickelt wurde.

Diese Phase umfasst die folgenden Schritte:

  1. Problem Definition
    In diesem Schritt schauen wir uns das Unternehmen an und welche Informationen benötigt werden. Dieser Schritt zeigt hauptsächlich, welche aktuellen Engpässe innerhalb der Organisation liegen.
  2. Machbarkeitsoptionen
    In diesem Schritt werden eine Reihe von Lösungsmöglichkeiten für das zu entwickelnde Informationssystem mit den dazugehörigen Geschäftsanforderungen vorgeschlagen.

Am Ende dieser Phase wird ein Machbarkeitsbericht erstellt. Diese Phase kann möglicherweise mit der nächsten Phase in einem kleinen Projekt kombiniert werden.

Phase 1: Analyse des aktuellen Systems (Anforderungsanalyse)

Diese Phase besteht in der Analyse der Ist-Situation auf hohem Niveau, in der mittels a DFD Es wird deutlich gemacht, wie das aktuelle System funktioniert und wo die Probleme liegen.

Diese Phase umfasst die folgenden Schritte:

  1. Geschäftsaktivitätsdiagramm
    Dadurch wird ein Diagramm der aktuellen Geschäftsaktivitäten erstellt, die möglicherweise berücksichtigt werden müssen. Werden im Unternehmen geltende Regeln oder sonstige Sachverhalte festgestellt, die Einfluss auf das zu entwickelnde Informationssystem haben, sind diese ebenfalls in die Spezifikation aufzunehmen.
  2. Bedarfsrecherche
    Die Anforderungen an das zu entwickelnde Informationssystem werden auf Vollständigkeit geprüft und bei Bedarf ergänzt. In diesem Schritt werden auch die Nutzer des neuen Informationssystems nach ihrer Meinung, Anforderungen und Wünschen zum neuen System gefragt.
  3. Ist-Situationsanalyse
    In diesem Schritt a DFD erstellt, in dem sich die aktuelle Situation befindet, für die später das Informationssystem gemacht wird. Dieser Schritt befasst sich speziell mit der Verarbeitung.
  4. Aktuelle Datenanalyse
    In diesem Schritt a DFD erstellt, in dem sich die aktuelle Situation befindet, für die später das Informationssystem erstellt wird. Dieser Schritt konzentriert sich speziell auf die Daten.
  5. Ein logisches Modell erstellen
    Dieser Schritt zielt darauf ab, ein schematisches Modell des aktuellen Systems zu erstellen. Dieser Schritt zielt darauf ab, die Probleme im aktuellen System zu identifizieren.

Phase 2: Skizzieren Sie die Geschäftsspezifikationen

Am Ende dieser Phase wurde entschieden, für welche Option der möglichen Business-System-Optionen (BSO) ausgewählt ist. Die Geschäftsleitung trifft diese Wahl auf der Grundlage des in dieser Phase gefundenen BSO. Die Optionen können durch eine technische Dokumentation bestehend aus Arbeitspraxismodelle, Logische Datenmodelle (LDM) und DFDs.

Diese Phase umfasst die folgenden Schritte:

  1. Identifizieren von Geschäftssystemoptionen Business
    In diesem Schritt wird untersucht, welche Optionen für das zu entwickelnde Informationssystem zur Verfügung stehen.
    Diese Optionen entsprechen (weitgehend) den Anforderungen der Benutzer.
  2. Wählen Sie Business-System-Optionen
    Für diesen Schritt werden Benutzer und Management nach ihrer Meinung zu den vorgestellten Optionen gefragt.

Stufe 3: Anforderungsdefinitionen (Anforderungsspezifikation)

In dieser Phase werden die Anforderungen weiter ausgearbeitet, sowohl funktionale Anforderungen als auch nicht-funktionale Anforderungen. Durch Techniken werden die Prozesse und Datenstrukturen noch gezielter ausgearbeitet. Das DFDs und LDMs weiter ausgearbeitet und mit den in der vorherigen Phase ausgewählten Geschäftssystemoptionen getestet.

Diese Phase umfasst die folgenden Schritte:

  1. Systemverarbeitung angeforderte Definition
    Der aktuelle Schritt besteht darin, die Benutzerrollen im neuen System im Hinblick auf Systemdatenflüsse zu definieren.
  2. Angeforderte Datenmodelldefinition
    Das logische Datenmodell der Phase 2 wird in diesem Schritt um alle Verarbeitungen des gewählten BSO erweitert. Dieser Schritt kann gleichzeitig mit dem obigen Schritt durchgeführt werden.
  3. Abgeleitete Systemfunktionen
    In diesem Schritt werden die Service-Level-Anforderungen für jede Funktion bestimmt und die zusätzlichen Funktionen, die in den vorherigen 2 Schritten gefunden wurden, werden hinzugefügt.
  4. Stellenbeschreibung des Mitarbeiters
    In diesem Schritt wird ein Arbeitspraxismodell entwickelt, um mehr Klarheit über die zu leistende Arbeit der Mitarbeiter zu gewinnen.
  5. Datenmodell verbessern
    Normalisieren Sie das logische Datenmodell, um die Qualität zu erhöhen.
  6. Prototypen
    Um den Nutzer wieder in den Prozess einzubeziehen, wird in diesem Schritt ein Prototyp erstellt. Anhand des erstellten Prototyps wird vor allem überprüft, ob die Anforderungen gut verstanden sind und noch der richtige Weg eingeschlagen wird.
  7. Verarbeitung angeben
    In diesem Schritt muss das Abrufen und Auffrischen der für das Informationssystem benötigten Daten beschrieben werden.
  8. Systemziele prüfen
    In dieser Phase ist es diesen möglich, die Erkenntnisse der Anforderungen zu ändern. Dies ist ein direktes Ergebnis der Wasserfallmethode.

Phase 4: Technische Systemoptionen

In dieser Phase werden mehrere technische Systemoptionen (ÜNB) hergestellt. Es ist wichtig zu bestimmen, wie viele ÜNB hergestellt werden. Unter Berücksichtigung der Kosten für die Entwicklung jedes ÜNB bis zu einem bestimmten Niveau muss die Notwendigkeit und der Grad der Erforschung alternativer Lösungen nachgewiesen werden.

Diese Phase umfasst die folgenden Schritte:

  1. ÜNB definieren
    Dabei werden die möglichen Ansätze und die funktionalen Anforderungen betrachtet, aus denen eine Reihe von Optionen extrahiert werden.
  2. ÜNB auswählen
    Präsentieren Sie die ÜNB den Nutzern

Phase 5: Logisches Design (Spezifikation des logischen Systems)

In dieser Phase werden die logischen Designs verwendet, um ein physisches Datenbankdesign zu erstellen und eine Reihe von Programmspezifikationen zu erstellen.

Diese Phase umfasst die folgenden Schritte:

  1. Benutzerdialoge definieren
    Dies bestimmt die Navigation und die Strukturen der Dialoge.
  2. Aktualisierungsprozesse definieren
    Hier werden die Fehler- und Aktualisierungsereignisse ausgearbeitet.
  3. Abfrageprozesse definieren
    Hier werden die Fehler- und Abfrageereignisse ausgearbeitet.

Phase 6: Physisches Design (Physikalisches Design)

Die letzte Stufe der SSADM-Methode; es definiert die physischen Daten und Prozesse unter Verwendung der Sprache und Optionen der ausgewählten physischen Umgebung, in der das System ausgeführt wird.

Dies beinhaltet die folgenden Schritte:

  1. Bereiten Sie sich auf das physische Design vor.
    Dieser Schritt besteht aus folgenden Punkten:
    • Lernen Sie die Regeln des Bereitstellungssystems kennen.
    • Zeigen Sie die Anforderungen für die logische und physische Zuordnung an.
    • Planen Sie die Anfahrt
  2. Vervollständigen Sie die Spezifikation der Funktionen.
  3. Erstellen Sie nachfolgende Daten- und Prozessdesigns.

Techniken

SSADM dreht sich um die Verwendung von drei grundlegenden Techniken, nämlich der logischen Datenmodellierung, der Datenflussmodellierung und der Entitäts-/Ereignismodellierung.

  • Logikdatenmodellierung (Logische Datenmodellierung): Dies ist der Prozess zur Identifizierung, Modellierung und Dokumentation des Datenbedarfs eines Unternehmensinformationssystems. Diese Modellierung enthält die logische Datenstruktur (LDS: die Terminologie für ein Entity-Relation-Modell) und ihre Dokumentation.
  • Datenflussmodellierung (Datenflussmodellierung): Dies ist der Prozess zur Identifizierung, Modellierung und Dokumentation des Datenflusses in einem Unternehmensinformationssystem. Ein Datenflussmodell besteht aus einer Reihe von Datenflussdiagrammen (DFDs) mit der begleitenden Dokumentation. Diese DFDs zeigen die Prozesse, die Datenspeicherung, externe Entitäten (Dinge, die Daten in ein System eingeben oder übertragen) und schließlich die Datenflüsse (die Routen, denen Daten folgen).
  • Entitäts-/Ereignismodellierung (Modellierung des Entitätsverhaltens): Dies ist der Prozess zum Identifizieren, Modellieren und Dokumentieren der Geschäftsereignisse, die sich auf jede Entität und Sequenz auswirken, in der diese Ereignisse auftreten. Dieses Modell besteht aus einer Reihe von Entitäten (Aufzeichnungen) mit Begründung und Dokumentation (eine für jede Entität).

DFDs in SSADM

Ein DFD (Datenflussdiagramm) stellt anschaulich dar, wie ein Geschäftsprozess funktioniert.Das Diagramm beginnt mit einer sehr globalen Sicht auf das untersuchte Unternehmen und analysiert weiterhin die entsprechenden Umgebungen und Interessen. Diese Technik verwendet eine Methode, die Top-Down-Methode wird genannt.

Das Produkt ist am Ende der Analysen eine Gruppe von Diagrammen, die detailliert und übersichtlich alle Geschäftsprozesse innerhalb eines Unternehmens abbilden. Das Diagramm erfasst die Definitionen eines Prozesses und erleichtert die Kommunikation darüber.

Der Beginn eines DFD beginnt auf der Einstiegsebene. Auf dieser Ebene, a Kontextdiagramm gezeichnet, ist dies eine sehr einfache Darstellung des untersuchten Prozesses.

Darauf folgt Ebene 1. Auf dieser Ebene identifiziert das Diagramm die wichtigsten Geschäftsprozesse, die später weiter analysiert werden können. Wenn ein Geschäftsprozess auf Stufe 1 noch zu komplex ist, können Sie ihn auf Stufe 2 noch genauer beschreiben sehr ungewöhnlich fortzufahren, über Level 3 hinauszugehen.

Kritikpunkte

SSADM trägt der Bedeutung des kollektiven Informations- und Datenmanagements wenig Rechnung. SSADM verfolgt einen strukturierten, rigorosen und projektgesteuerten Ansatz zur Entwicklung von Datenstrukturen und Prozessen. SSADM kann die Wahrscheinlichkeit verringern, dass anfängliche Anforderungen missverstanden werden. SSADM geht jedoch davon aus, dass sich die Anforderungen (in Form einer genehmigten Anforderungsspezifikation) während der Entwicklung eines Projekts nicht ändern.

Jedem Schritt von SSADM zu folgen ist sehr zeitaufwendig und kann einen großen Zeitunterschied zwischen dem Start und der Auslieferung verursachen (was tatsächlich das erste Mal ist, dass Benutzer ein funktionierendes System sehen). Je länger die Entwicklungszeit, desto wahrscheinlicher erfüllt das System die erforderlichen Spezifikationen, aber nicht die Geschäftsanforderungen zum Zeitpunkt der Auslieferung. Diese ändern sich und können nicht lange unverändert bleiben.

Das Design von SSADM hat sich seit der ersten Version aufgrund von Benutzererfahrungen und anderen Methoden mehrmals geändert. Trotz der Änderungen gibt es bei SSADM im Besonderen und beim Wasserfall-Ansatz im Allgemeinen viel Kritik. Dies liegt daran, dass Zeit und Geld in das Softwareprojekt gesteckt werden, ohne das Ergebnis/die Ausgabe des Projekts zu verbessern.

Siehe auch