WikiDer > Systementwicklungsmethodik

Systementwicklungsmethodik (SDM), oder Systementwicklungsmethodik (Methodik) ist ein Phasenmethode. Es wird hauptsächlich in Projekten zur Entwicklung von (automatisierten) Informationssysteme. Diese Methode hat sich in den letzten Jahren durch die Entwicklung der Automatisierung steht nicht still.

Geschichte

1970 gründete ein Unternehmen mit dem Namen PANDATE im Auftrag von drei großen niederländischen Unternehmen (AKZO, Nationale Niederlande und das dann PTT) SDM entwickelt. 1987 wurde SDM verbessert und ist jetzt bekannt als SDM2. SDM2 wurde gegenüber früheren Versionen geändert, unter anderem wegen "der zunehmenden Bedeutung der Informationssystementwicklung für die gesamte Unternehmensplanung, (...), dem gestiegenen Bewusstsein für den Einfluss von Informationssystemen auf die Organisation".¹

SDM ist eine Methodik zum Planen, Entwerfen, Bauen, Implementieren und Verwalten von Informationssystemen. Diese Einteilung erfolgt „von oben nach unten“, aus einem größeren Ganzen wird das zu gestaltende Informationssystem immer detaillierter beschrieben. Durch Hinzufügen von Systementwicklungstechniken kann das Design in Modellen beschrieben werden, die dann zur Realisierung des Designs verwendet werden. SDM ist auch ein Wasserfallmethode. Eine neue Phase beginnt erst, wenn die alte abgeschlossen ist.

Einrichtungsmethode

SDM ist ein Methodik basierend auf der Phasenlage. Für jede Phase wird genau festgehalten, was mit den Beteiligten vereinbart wurde und was in der jeweiligen Phase zu tun ist. SDM verwendet einen prozessorientierten Ansatz, das heißt, diese Methode befasst sich hauptsächlich mit der Planung und Organisation des zu erstellenden Systems. Die Steuerung von Systementwicklungsprojekten ist die Hauptaufgabe der SDM-Entwicklungsmethode. Die Dokumente, in denen diese Sachverhalte festgehalten werden, werden Meilensteinprodukte genannt.

Der Einsatz von Meilensteinprodukten ist aus folgenden Gründen wichtig:

• Der Fortschritt kann genau überwacht werden. Durch die Verknüpfung von Terminen mit den Meilensteinprodukten kann überprüft werden, ob die Ausführung des Projekts im Zeitplan liegt.
• Wenn ein Meilensteinprodukt vom Kunden freigegeben wird, erhält es einen bestimmten Status. Der Status kann nicht einfach umgekehrt werden. Dadurch wird verhindert, dass der Client beispielsweise die Systemvoraussetzungen nachträglich erweitern kann.
• Ein Meilensteinprodukt kann dazu führen, dass der Kunde das Projekt abbricht. Dies geschieht in der Regel zu Beginn des Projekts.

Das Verfahren verwendet sieben verschiedene Phasen, die nacheinander ausgeführt werden. Am Ende jeder Phase wird ein Abschlussbericht erstellt. Alle Schlussfolgerungen und Begründungen zu dieser Phase werden darin festgehalten.

Anhand dieses Abschlussberichts kann entschieden werden, ob das Projekt weitergeführt oder abgebrochen wird. Dies wird durch die Schlagworte „Go“ und „NO-GO“ angezeigt. Tritt ein „NO-GO“ auf, kann dies auch bedeuten, dass in der Phase nachgebessert werden muss. Die nächste Phase darf erst gestartet werden, wenn ein "Go" auftritt (Wasserfallmethode).

Phasenverschiebung

Die sieben nacheinander behandelten Phasen sind:

Informationsplanung

In dieser Phase wird der Informationsplan geschrieben, in dem unter anderem das Gesamtsystem beschrieben wird. Dies bedeutet, dass der automatisierte Teil und der manuelle Teil enthalten sind. Dieser Plan schafft Klarheit darüber, welcher Informationsbedarf vorhanden ist und wie dieser Bedarf durch das Informationssystem befriedigt wird.

Die Meilensteinprodukte für diese Phase sind:

• Der Lageanalysebericht

Eine Analyse des aktuellen Informationssystems und/oder der aktuellen Situation.

• Der Informationsplanungsbericht

Planen Sie mit Vereinbarungen über den zukünftigen Informationsbedarf, die verschiedenen Möglichkeiten der Automatisierung und deren Folgen.

Definitionsstudie

Während der Durchführung dieser Phase wird untersucht, ob die Realisierung des Projekts machbar ist. Um die Machbarkeit eines Projekts zu messen, können folgende Fragen als Richtlinie dienen:

• Ist Entwicklung möglich und sinnvoll?

Das Wissen und die Arbeitsstunden müssen ausreichend vorhanden sein und muss das bestehende System ersetzt werden?

• Ist die Entwicklung technisch machbar?

Die Ausrüstung muss für das System verfügbar sein. Wenn Anforderungen gestellt werden, die der Prozessor nicht erfüllen kann, kann die Anforderung nicht mit Hilfe des Systems erfüllt werden.

• Ist Entwicklung wirtschaftlich gerechtfertigt?

Wenn die Kosten für die Entwicklung und Verwaltung des Systems höher sind als die damit erzielten Gewinne, ist eine Entwicklung finanziell nicht sinnvoll.

• Ist das neue System organisatorisch kompatibel?

Die Menschen, die innerhalb der Organisation arbeiten, müssen in der Lage sein, mit dem zukünftigen System zu arbeiten.

• Ist die Entwicklung des neuen Systems politisch machbar?

Das neue System darf nicht im Widerspruch zum Gesetz stehen.

Die Meilensteinprodukte für diese Phase sind:

• Beschreibung der Systemvoraussetzungen

Die Anforderungen, die das neue System erfüllen muss. Dieser legt fest, was das neue System können muss, was zu einem späteren Zeitpunkt (während / nach der Implementierung) noch einmal überprüft werden kann.

• Das Systemkonzept

Eine Beschreibung der Hauptfunktionen des Systems. Hier wird angegeben, welche Teile automatisiert und welche manuell ausgeführt werden.

• Der Gesamtplan mit Kosten-Nutzen-Analyse

Dieser beschreibt, wie das System gebaut wird, unter welchen Bedingungen und welche Kosten damit verbunden sind. Dies ist ein sehr wichtiges Dokument, anhand dessen entschieden werden kann, ob der Bau des neuen Systems sinnvoll ist.

Grundlegende Gestaltung

In dieser Phase erfolgt die Auslegung des Systems. Dies beschreibt, was das System tun wird. Es zeigt auch genau an, aus welchen Subsystemen das zukünftige System bestehen wird. Dadurch können die Subsysteme separat entwickelt und gebaut werden. Dadurch wird die Durchlaufzeit des Projekts deutlich verkürzt Alle Ein- und Ausgaben werden ebenso erfasst wie die zu speichernden Datensätze. Alle Funktionen werden bestimmt, zu welchem ​​Subsystem sie gehören. Auch die Anbindung und Schnittstellen zu anderen Systemen werden beschrieben. Dazu wird untersucht, wie die Beziehung zu anderen Systemen ist, welche Funktionen die anderen Systeme haben und welcher Datenaustausch besteht.Nach Festlegung der Subsysteme werden die Systemanforderungen für jede Komponente notiert. Auch in dieser Phase werden bereits die Testkriterien und Testdaten erhoben sowie eventuelle organisatorische Veränderungen.

Die Meilensteinprodukte für diese Phase sind:

• Grundlegende Datenstrukturermittlung

Welche Daten werden im neuen System verwendet, wie werden die Daten vom alten in das neue System konvertiert.

• Bestimmung der grundlegenden Jobstruktur

Was werden die neuen Funktionen des Systems sein.

• Ermittlung der technischen Systemstruktur

Wie wird das System technisch aussehen? Welche Ausstattung, Software, Dateistruktur und welche Art? DBMS wird eingesetzt.

Detailliertes Design

Diese Phase baut auf der vorherigen Phase auf. Der Entwurf, der in der vorherigen Phase erstellt wurde, wird im Detail weiter ausgearbeitet. Dies geschieht, indem genauer beschrieben wird, was jeder Teil des Systems tut. Das Ergebnis ist das funktionale Design. In dieser Phase wird auch festgelegt, wie die beschriebenen Komponenten realisiert werden sollen. Daraus ergibt sich das technische Design.

Die Meilensteinprodukte für diese Phase sind:

• Funktionales Design melden

Dieser Bericht besteht aus einer vollständigen Beschreibung der Funktionen, der Datenstruktur und der Mensch-Maschine-Schnittstelle (welche Eingaben sollen vom neuen System verarbeitet werden und welche Ausgaben erzeugt werden).

• Technischer Entwurfsbericht

Dies beinhaltet unter anderem eine Beschreibung der Formulare und Abläufe (Welche Dokumente werden verwendet, wie sieht die Peripherie aus), Bildschirmbeschreibungen (Schnittstellen), Speicherstruktur und welche Hardwarekomponenten im neuen System verwendet werden (Komponentenspezifikation) .

• Systemtestplan

Dies ist ein detaillierter Testplan, der beinhaltet, wie der Test durchgeführt wird, wie der Test aussehen wird, wer den Test durchführt, wer entscheidet, ob der Test erfolgreich abgeschlossen wurde, welche Daten verwendet werden (Testkriterien und Test Fälle) usw. .

• Abnahmetestplan

Dieser Test ähnelt dem Systemtest, nur ist dieser Test für den Benutzer oder Client bestimmt. Der Kunde kann das System basierend auf diesem Test akzeptieren oder nicht.

• Realisierungs- und Umsetzungsplan

Dieser zeigt auf, welche Personen und Ressourcen für die Realisierung und Umsetzung benötigt werden und welche Aktivitäten dafür durchgeführt werden müssen.

Realisierung

In dieser Phase wird das System tatsächlich gebaut (realisiert). Wichtig hierfür sind der Functional Design Report und der Technical Design Report. Dies sind die Prinzipien, auf denen das System basiert. In dieser Phase wird auch die notwendige Hardware angeschafft, also die Programme geschrieben, Kurse gemacht, das System getestet, die Ordnungsmäßigkeit der Dokumentation sichergestellt und der Kunde gibt durch den Abnahmetest seine abschließende Bewertung ab die Anforderungen und wird letztendlich vom Kunden genehmigt; mit anderen Worten: wenn beide Tests erfolgreich waren. Danach wird das neue System im Unternehmen eingeführt.

Die Meilensteinprodukte für diese Phase sind:

• Systemtestbericht

Diese enthält die Ergebnisse des Systemtests. Es wurde getestet, ob die Software ordnungsgemäß funktioniert und ob das System die Systemvoraussetzungen erfüllt.

• Abnahmeprüfbericht

Dies ist das Ergebnis des Abnahmetests. Bei diesem Test wird festgestellt, ob das Informationssystem die Anforderungen des Nutzers erfüllt. Wird das System vom Kunden akzeptiert, zahlt er auch.

Einführung

In dieser Phase wird das ausgelieferte System beim Kunden installiert. Die Kurse (aus der vorherigen Phase) werden gegeben und die Mitarbeiter werden mit dem neuen System vertraut gemacht. Die Daten werden mit einer möglichen Konvertierung in das neue System eingegeben. Die Dokumentation wird der Person übergeben, die das neue System verwaltet (Systemadministrator). Auch die Umgebung, in der das neue System laufen soll, wird angepasst.

Die Meilensteinprodukte für diese Phase sind:

• Umbau- und Umsetzungsplan

Dieser gibt an, wie die mögliche Umsetzung erfolgt und wie die Gesamtumsetzung erfolgen soll

• Die fertige Projektdokumentation

Die gesamte Dokumentation, die während der Entwicklung aufgebaut wurde, ist geschlossen. Diese Dokumentation wird dem Systemadministrator übergeben.

• Der Transferbericht

Dies ist der Abschlussbericht, mit dem das System an die Organisation übergeben wird.

Nutzung und Verwaltung

Obwohl die Organisation das System vollständig übernehmen wird, gibt es noch einige Richtlinien zur Nutzung und Verwaltung. Diese Regeln müssen sicherstellen, dass das System weiterhin die Anforderungen erfüllt. Es zeigt auch, wie Mängel und Störungen behoben werden sollten. Darüber hinaus können diese Regeln für Verbesserungen wichtig sein.All diese Aktivitäten sind fortlaufend; sie existieren, solange das System existiert. Damit ist diese Phase nicht abgeschlossen.

Die Meilensteinprodukte für diese Phase sind:

• Organisation der Nutzung und Wartung

Hier wird beschrieben, wie Nutzung und Wartung angeordnet sind. Darin steht, wer wofür verantwortlich ist und wer welche Aufgaben übernommen hat.

• Verschiedene Nutzungs- und Managementpläne

Dies ist ein Überblick über die verschiedenen Nutzungs- und Wartungsformen wie Sicherheitsplan, Notfallplan, Personalschulungsplan, Wartungsplan, Störungsbeseitigungsplan und Datenmanagementplan.

• Vollständige Systembeschreibung

Eine vollständige und ständig aktualisierte Beschreibung des Gesamtsystems ist unabdingbar. Anpassungen sind mit dieser Beschreibung möglich.

• Periodischer Bewertungsbericht

Mindestens einmal jährlich ist ein Bericht über die Funktionsfähigkeit des Systems zu diesem Zeitpunkt erforderlich. Dieser Bericht enthält Empfehlungen für zukünftige Aktivitäten (Änderung, Ersatz usw.).

Verwendete Techniken

Die SDM-Methode verwendet die folgenden Modellierungstechniken:

• Datenflussdiagramm (DFD)

Diese Modellierungstechnik modelliert eine begrenzte Darstellung eines Systems. Aus diesen Modellen lässt sich ablesen, welche Aktionen innerhalb eines Systems ausgeführt werden und mit welchen Daten dies geschieht. Daraus ist nicht zu lesen, wer etwas tut und mit welchem ​​Gerät die Aktion ausgeführt wird.

• Kontextdiagramm

Wenn Sie mit der Erstellung von DFDs beginnen, erstellen Sie als erstes ein globales Bild. Das heißt, Sie sehen nicht, was im System passiert. Dies ist das Kontextdiagramm. Einen guten Ausgangspunkt für dieses Diagramm stellen die Systemanforderungen dar. In diesem Diagramm erfassen Sie die Beziehungen zur Außenwelt und was zu Ihrem System gehört (und was nicht). Dies ist die Systemgrenze.

• Aktivitätsplan

Für jede der sieben Phasen wird ein Aktivitätsplan erstellt. Alle Aktivitäten werden hier nummeriert und angezeigt. Pfeile zeigen den Fortschritt der Aktivitäten an. Wenn beispielsweise ein Pfeil von Aktivität 1 zu Aktivität 2 verläuft, wird Aktivität 2 gestartet, wenn Aktivität 1 abgeschlossen ist.

Leistungen

• Übersichtliche Anordnung der verschiedenen Phasen;
• Verhindert das Überspringen wichtiger Phasen.

Nachteile

• Die Wahrscheinlichkeit des Scheiterns ist hoch;
• Kostet viel Zeit und damit Geld;
• Das System sollte bereits in der Definitionsstudie vollständig beschrieben sein;
• Geringe Benutzerbeteiligung.
• Ineffizient arbeiten

Quelle: Systementwicklung Teil 1: Statische Informationssysteme von: D.T.G.P. Vogelaars und J.J. Marke.

Fußnote

¹: Quelle: Turner, W.S., R.P. Langerhorst, G.F. Hice, H. B. Eilers, E.Remmerde, A.A. Uijttenbroek, SDM - Systementwicklungsmethodik, Rijswijk, 1990