Lebenszyklus von Informationssystemen. IS-Lebenszyklus und seine Struktur

Der Lebenszyklus eines Informationssystems ist ein Zeitraum, der mit der Entscheidung über die Notwendigkeit der Erstellung eines Informationssystems beginnt und mit der vollständigen Außerbetriebnahme endet.

Konzept Lebenszyklus ist eines der Grundkonzepte der Entwurfsmethodik von Informationssystemen.

Die Methodik zur Gestaltung von Informationssystemen beschreibt den Prozess der Erstellung und Wartung von Systemen in Form eines IS-Lebenszyklus (LC) und stellt ihn als eine bestimmte Abfolge von Phasen und darauf durchgeführten Prozessen dar. Für jede Phase werden die Zusammensetzung und Reihenfolge der durchgeführten Arbeiten, die erzielten Ergebnisse, die zur Durchführung der Arbeiten erforderlichen Methoden und Mittel, die Rollen und Verantwortlichkeiten der Teilnehmer usw. festgelegt. Eine solche formale Beschreibung des Lebenszyklus eines Informationssystems ermöglicht es, den Prozess der kollektiven Entwicklung zu planen und zu organisieren und die Steuerung dieses Prozesses sicherzustellen.

Der gesamte Lebenszyklus eines Informationssystems umfasst normalerweise strategische Planung, Analyse, Design, Implementierung, Implementierung und Betrieb. Generell kann der Lebenszyklus wiederum in mehrere Phasen unterteilt werden. Im Prinzip ist diese Einteilung in Etappen recht willkürlich. Wir werden eine der Optionen für eine solche Aufteilung in Betracht ziehen, die von der Rational Software Corporation angeboten wird, einem der führenden Unternehmen auf dem Softwaremarkt für Entwicklungstools für Informationssysteme (unter denen das universelle CASE-Tool Rational Rose zu Recht sehr beliebt ist).

Phasen des IP-Lebenszyklus

Die Phase ist ein Teil des Prozesses der IP-Erstellung, der auf einen bestimmten Zeitraum begrenzt ist und mit der Veröffentlichung eines bestimmten Produkts (Modelle, Softwarekomponenten, Dokumentation) endet, das durch die für diese Phase festgelegten Anforderungen bestimmt wird. Die Beziehung zwischen Prozessen und Phasen wird auch durch das verwendete IS-Lebenszyklusmodell bestimmt.

Gemäß der von Rational Software vorgeschlagenen Methodik ist der Lebenszyklus eines Informationssystems in vier Phasen unterteilt.

Die Grenzen jeder Phase werden durch bestimmte Zeitpunkte definiert, zu denen bestimmte kritische Entscheidungen getroffen und daher bestimmte Schlüsselziele erreicht werden müssen.

1) Anfangsphase

An Erstphase Der Anwendungsbereich des Systems wird festgelegt und die Randbedingungen festgelegt. Dazu ist es notwendig, alle externen Objekte zu identifizieren, mit denen das entwickelte System interagieren muss, und die Art dieser Interaktion auf hoher Ebene zu bestimmen. In der Anfangsphase werden alle Funktionen des Systems identifiziert und die wichtigsten davon beschrieben.

2) Klärungsphase

In der Klärungsphase wird eine Analyse des Anwendungsbereichs durchgeführt und die architektonische Grundlage des Informationssystems entwickelt.

Bei Entscheidungen zur Systemarchitektur ist es notwendig, das zu entwickelnde System als Ganzes zu berücksichtigen. Dies bedeutet, dass es notwendig ist, die meisten zu beschreiben Funktionalität System und berücksichtigen die Beziehungen zwischen seinen einzelnen Komponenten.

Am Ende der Klärungsphase wird eine Analyse durchgeführt architektonische Lösungen und Möglichkeiten zur Beseitigung der Hauptrisikofaktoren im Projekt.

3) Bauphase

In der Designphase wird ein fertiges Produkt entwickelt, das zur Auslieferung an den Benutzer bereit ist.

Am Ende dieser Phase wird die Leistungsfähigkeit der entwickelten Software ermittelt.

4) Inbetriebnahmephase

Im Rahmen der Inbetriebnahme erfolgt die Übergabe der entwickelten Software an die Nutzer. Beim Betrieb eines entwickelten Systems unter realen Bedingungen treten häufig verschiedene Arten von Problemen auf, die zusätzliche Arbeiten zur Anpassung des entwickelten Produkts erfordern. Dies ist in der Regel mit der Feststellung von Fehlern und Mängeln verbunden.

Am Ende der Inbetriebnahmephase muss festgestellt werden, ob die Entwicklungsziele erreicht wurden oder nicht.

IP-Lebenszyklusstandards

Moderne Netzwerke werden auf Basis von Standards entwickelt, wodurch zum einen deren sichergestellt werden kann hohe Effizienz und zweitens die Möglichkeit ihrer Interaktion miteinander.

Zu den bekanntesten Standards zählen die folgenden:

GOST 34.601-90 – gilt für automatisierte Systeme und legt die Phasen und Phasen ihrer Erstellung fest. Darüber hinaus enthält die Norm eine Beschreibung der Arbeitsinhalte in jeder Phase. Die im Standard verankerten Phasen und Arbeitsschritte entsprechen eher dem Kaskadenlebenszyklusmodell.

ISO/IEC 12207 (International Organization of Standardization / International Electrotechnical Commission) 1995 – Standard für Prozesse und Lebenszyklusorganisation. Gilt für alle Arten von kundenspezifischer Software. Die Norm enthält keine Beschreibungen von Phasen, Stufen und Stadien.

Der Rational Unified Process (RUP) bietet ein iteratives Entwicklungsmodell, das vier Phasen umfasst: Starten, Erkunden, Erstellen und Implementieren. Jede Phase kann in Phasen (Iterationen) unterteilt werden, die dazu führen, dass eine Version für den internen oder externen Gebrauch freigegeben wird. Der Fortschritt durch vier Hauptphasen wird als Entwicklungszyklus bezeichnet. Jeder Zyklus endet mit der Generierung einer Version des Systems. Wenn die Arbeit am Projekt danach nicht beendet wird, entwickelt sich das resultierende Produkt weiter und durchläuft erneut dieselben Phasen. Der Kern der Arbeit innerhalb von RUP ist die Erstellung und Pflege von UML-basierten Modellen.

Microsoft Solution Framework (MSF) ähnelt RUP, umfasst außerdem vier Phasen: Analyse, Design, Entwicklung, Stabilisierung, ist iterativ und beinhaltet die Verwendung objektorientierter Modellierung. MSF konzentriert sich im Vergleich zu RUP stärker auf die Entwicklung von Geschäftsanwendungen.

Extreme Programmierung (XP). Extreme Programming (die neueste der betrachteten Methoden) wurde 1996 gegründet. Die Methodik basiert auf Teamarbeit, effektiver Kommunikation zwischen Kunde und Auftragnehmer während des gesamten IP-Entwicklungsprojekts und die Entwicklung erfolgt anhand sukzessive verfeinerter Prototypen.

spiralförmige Lebenszykluskaskade

ZCIS ist der Zeitraum der Erstellung und Nutzung von Informationssystemen, beginnend mit der Entstehung des Bedarfs an Informationssystemen und endend mit dem Zeitpunkt ihrer vollständigen Stilllegung.

Der Lebenszyklus ist ein Modell für die Erstellung und Nutzung von Software, das deren verschiedene Zustände widerspiegelt, beginnend mit dem Moment, in dem ein Bedarf für ein bestimmtes Softwareprodukt entsteht, und endet mit dem Moment, in dem es für alle Benutzer völlig außer Gebrauch ist.

Traditionell werden folgende Hauptphasen des Softwarelebenszyklus unterschieden:

• Anforderungsanalyse;
• Design;
• Codierung (Programmierung);
• Testen und Debuggen;
• Betrieb und Instandhaltung.

Phasen des Lebenszyklus eines Informationssystems

1. Umfrage vor dem Projekt
   • 1.1. Sammlung von Materialien für Design; Gleichzeitig werden die Formulierung von Anforderungen, die Untersuchung des Automatisierungsobjekts beleuchtet und vorläufige Schlussfolgerungen der Vorentwurfsversion des IS gegeben.
   • 1.2. Analyse von Materialien und Entwicklung von Dokumentationen; eine Machbarkeitsstudie mit technischen Spezifikationen für IC-Design.
2. Design
   • 2.1. Vorläufiger Entwurf:
     • Auswahl von Designlösungen zu Aspekten der IS-Entwicklung;
     • Beschreibung realer IS-Komponenten;
     • Registrierung und Genehmigung technisches Projekt(TP).
   • 2.2. Detailliertes Design:
     • Auswahl oder Entwicklung mathematische Methoden oder Programmalgorithmen;
     • Aktualisierung von Datenbankstrukturen;
     • Erstellung der Dokumentation für Lieferung und Installation Softwareprodukte;
     • Auswahl einer Reihe technischer Mittel mit Dokumentation für deren Installation.
   • 2.3. Entwicklung eines technischen und Arbeitsprojekts von IP (TRP).
   • 2.4. Entwicklung einer Methodik zur Umsetzung von Managementfunktionen mittels IS und Beschreibung der Regelungen für das Handeln des Managementapparates.
3. IP-Entwicklung
   • Beschaffung und Installation von Hardware und Software;
   • Testen und Feinabstimmen des Softwarepakets;
   • Entwicklung von Bedienungsanleitungen für Soft- und Hardware.
4. Inbetriebnahme des IS
   • Einführung technischer Mittel;
   • Eingabe von Software;
   • Personalschulung und -zertifizierung;
   • Probebetrieb;
   • Übergabe und Unterzeichnung der Arbeitsabnahmebescheinigungen.
5. IP-Betrieb
   • täglicher Gebrauch;
   • allgemeine Betreuung des gesamten Projektes.

Der Lebenszyklus wird nach dem Prinzip gestaltet Top-Down-Design und ist in der Regel iterativer Natur: Die umgesetzten Stufen, beginnend mit den frühesten, werden zyklisch wiederholt, entsprechend sich ändernden Anforderungen und äußeren Bedingungen, der Einführung von Beschränkungen usw. In jeder Phase des Lebenszyklus wird ein bestimmter Satz an Dokumenten und technischen Lösungen generiert; Darüber hinaus sind für jede Phase die in der vorherigen Phase erhaltenen Dokumente und Entscheidungen der Ausgangspunkt. Jede Phase endet mit der Überprüfung der erstellten Dokumente und Lösungen, um deren Übereinstimmung mit den Originaldokumenten zu überprüfen.

Das wichtigste Regulierungsdokument, das den Lebenszyklus von Software regelt, ist die internationale Norm ISO/IEC 12207 (ISO – International Organization of Standardization, IEC – International Electrotechnical Commission). Es definiert die Lebenszyklusstruktur mit den Prozessen, Aktivitäten und Aufgaben, die während der Softwareerstellung ausgeführt werden müssen.

Die Struktur des Software-Lebenszyklus nach der Norm ISO/IEC 12207 basiert auf drei Gruppen von Prozessen:

• Hauptprozesse des Software-Lebenszyklus (Kauf, Lieferung, Entwicklung, Betrieb, Support);
• Hilfsprozesse, die die Umsetzung der Hauptprozesse sicherstellen (Dokumentation, Konfigurationsmanagement, Qualitätssicherung, Verifizierung, Zertifizierung, Bewertung, Audit, Problemlösung);
• Organisationsprozesse (Projektmanagement, Aufbau der Projektinfrastruktur, Definition, Bewertung und Verbesserung des Lebenszyklus selbst, Schulung).

Unter Entwicklung versteht man alle Arbeiten zur Erstellung von Software und deren Komponenten entsprechend vorgegebener Anforderungen. Dies umfasst die Erstellung der Entwurfs- und Betriebsdokumentation, die Vorbereitung der für die Prüfung der Funktionsfähigkeit erforderlichen Materialien und der entsprechenden Materialien Qualität von Softwareprodukten, Materialien, die für die Organisation der Personalschulung usw. erforderlich sind. Die Softwareentwicklung umfasst typischerweise Analyse, Design und Implementierung (Programmierung).

Der Betrieb umfasst Arbeiten zur Inbetriebnahme von Softwarekomponenten. Dieser Prozess umfasst die Konfiguration der Datenbank und der Benutzerarbeitsplätze, die Bereitstellung von Betriebsdokumentationen, die Durchführung von Personalschulungen usw. sowie den direkten Betrieb, einschließlich der Lokalisierung von Problemen und der Beseitigung der Ursachen ihres Auftretens, der Änderung der Software im Rahmen der festgelegten Vorschriften, der Ausarbeitung von Verbesserungsvorschlägen, der Entwicklung usw Modernisierung des Systems.

Projektmanagement ist mit Fragen der Arbeitsplanung und -organisation, der Bildung von Entwicklungsteams und der Überwachung des Zeitplans und der Qualität der durchgeführten Arbeiten verbunden. Die technische und organisatorische Unterstützung des Projekts umfasst die Auswahl von Methoden und Werkzeugen zur Projektdurchführung, die Festlegung von Methoden zur Beschreibung von Entwicklungszwischenständen, die Entwicklung von Methoden und Werkzeugen für Softwaretests, die Schulung des Personals usw. Die Sicherstellung der Projektqualität ist mit Problemen der Softwareverifizierung, -verifizierung und -prüfung verbunden.

Bei der Verifizierung handelt es sich um den Prozess, bei dem festgestellt wird, ob der aktuelle Entwicklungsstand, der in einer bestimmten Phase erreicht wurde, den Anforderungen dieser Phase entspricht. Durch die Verifizierung können Sie die Übereinstimmung von Entwicklungsparametern mit den ursprünglichen Anforderungen beurteilen. Die Verifizierung überschneidet sich mit dem Testen, bei dem es darum geht, Unterschiede zwischen tatsächlichen und erwarteten Ergebnissen zu identifizieren und zu beurteilen, ob Softwaremerkmale den ursprünglichen Anforderungen entsprechen. Während der Projektumsetzung wichtiger Platz befassen sich mit der Identifizierung, Beschreibung und Steuerung der Konfiguration einzelner Komponenten und des Gesamtsystems.

Das Konfigurationsmanagement ist einer der Hilfsprozesse, die die Hauptprozesse des Software-Lebenszyklus unterstützen, vor allem die Prozesse der Softwareentwicklung und -wartung. Bei der Erstellung komplexer IS-Projekte, die aus vielen Komponenten bestehen, von denen jede Variante oder Version haben kann, stellt sich das Problem, deren Zusammenhänge und Funktionen zu berücksichtigen, eine einheitliche Struktur zu schaffen und die Entwicklung des gesamten Systems sicherzustellen. Mit dem Konfigurationsmanagement können Sie Änderungen an Software in allen Phasen des Lebenszyklus organisieren, systematisch berücksichtigen und steuern. Allgemeine Grundsätze Empfehlungen für Konfigurationsabrechnung, Planung und Softwarekonfigurationsmanagement sind im Normentwurf ISO 12207-2 enthalten.

Jeder Prozess zeichnet sich durch bestimmte Aufgaben und Methoden zu deren Lösung, in der vorherigen Phase gewonnene Ausgangsdaten und Ergebnisse aus. Ergebnisse der Analyse sind insbesondere Funktionsmodelle, Informationsmodelle und die dazugehörigen Diagramme. Der Software-Lebenszyklus ist iterativer Natur: Die Ergebnisse der nächsten Phase führen oft zu Änderungen an Designlösungen, die in früheren Phasen entwickelt wurden.

Der Lebenszyklus ist kein Zeitraum der Existenz, sondern ein Prozess aufeinanderfolgender Zustandsänderungen, die durch die Art der erzeugten Einwirkungen bestimmt werden (R 50-605-80-93).

Der Begriff „Systemlebenszyklus“ bezieht sich normalerweise auf die Entwicklung eines neuen Systems in mehreren Phasen, einschließlich so wichtiger Phasen wie Konzept, Entwicklung, Produktion, Betrieb und endgültige Stilllegung:70.

Geschichte des Lebenszykluskonzepts

Das Konzept des Lebenszyklus entstand Ende des 19. Jahrhunderts. als Komplex von Ideen, einschließlich der Ideen von Vererbung und Entwicklung auf der Ebene von Individuen und Organismen sowie von Anpassung, Überleben und Aussterben auf der Ebene einzelner Arten und ganzer Populationen lebender Organismen.

Typische Systemlebenszyklusmodelle

Es gibt kein einzelnes Lebenszyklusmodell, das die Anforderungen jeder möglichen Aufgabe erfüllt. Verschiedene Normungsorganisationen, Regierungsbehörden und Ingenieurgesellschaften veröffentlichen ihre eigenen Modelle und Technologien, die zur Erstellung des Modells verwendet werden können. Daher ist es unangemessen, die Existenz eines einzigen möglichen Algorithmus zur Erstellung eines Lebenszyklusmodells zu behaupten.

Einige Systemingenieure schlagen vor, ein Systemlebenszyklusmodell in Betracht zu ziehen, das auf drei Quellen basiert: dem Logistikmanagementmodell des Verteidigungsministeriums (DoD) (DoD 5000.2), dem ISO/IEC 15288-Modell und dem Modell der National Society of Professional Engineers (NSPE). :71.

Typisches Lebenszyklusmodell nach ISO/IEC 15288

Gemäß der Norm werden Lebenszyklusprozesse und -aktivitäten definiert, angemessen konfiguriert und während einer Lebenszyklusphase verwendet, um die Ziele und Ergebnisse dieser Phase vollständig zu erfüllen. Verschiedene Organisationen können in unterschiedlichen Phasen des Lebenszyklus beteiligt sein. Es gibt kein einheitliches universelles Modell für Systemlebenszyklen. Je nach Fall der Systementwicklung können bestimmte Phasen des Lebenszyklus fehlen oder vorhanden sein:34.

Als Beispiele nennt die Norm folgende Lebenszyklusphasen:

1. Die Idee.
2. Entwicklung.
3. Produktion.
4. Anwendung.
5. Anwendungsunterstützung.
6. Einstellung und Abschreibung.

In der Version 2008 der Norm (ISO/IEC 15288:2008) gibt es keine Beispiele für Lebenszyklusphasen.

Typisches Lebenszyklusmodell nach Angaben des US-Verteidigungsministeriums

Um die Risiken des Einsatzes fortschrittlicher Technologien zu bewältigen und kostspielige technische oder Managementfehler zu minimieren, hat das US-Verteidigungsministerium Leitlinien entwickelt, die alle notwendigen Grundsätze für die Systementwicklung enthalten. Diese Grundsätze sind in einer speziellen Richtlinienliste enthalten – DoD 5000.

Das Lebenszyklusmodell eines Logistikmanagementsystems besteht nach Angaben des US-Verteidigungsministeriums aus fünf Phasen:71:

1. Analyse.
2. Technische Entwicklung.
3. Engineering und Produktionsentwicklung.
4. Produktion und Bereitstellung.
5. Betrieb und Support.

Generisches Systemlebenszyklusmodell der National Society of Professional Engineers (NSPE).

Dieses Modell ist für die Entwicklung kommerzieller Systeme angepasst. Dieses Modell zielt hauptsächlich auf die Entwicklung neuer Produkte ab, die normalerweise das Ergebnis von sind technischer Fortschritt. Das NSPE-Modell bietet eine alternative Sicht auf das DoD-Versionsmodell. Der Lebenszyklus nach dem NSPE-Modell ist in sechs Phasen unterteilt:72:

1. Konzept.
2. Technische Umsetzung.
3. Entwicklung.
4. Kommerzielle Validierung und Produktionsvorbereitung.
5. Serienproduktion.
6. Endproduktsupport.

Typisches Produktlebenszyklusmodell gemäß R 50-605-80-93

Das Leitliniendokument R 50-605-80-93 untersucht sorgfältig den Lebenszyklus eines Industrieprodukts, einschließlich militärischer Ausrüstung.

Für Industrieprodukte zur zivilen Nutzung werden folgende Stufen vorgeschlagen:

1. Forschung und Design.
2. Herstellung.
3. Berufung und Umsetzung.
4. Betrieb oder Verbrauch.

Im Lebenszyklus von Industrieprodukten für den zivilen Gebrauch wird vorgeschlagen, 73 Arten von Arbeiten und 23 Arten von Beteiligten („Arbeitsteilnehmer“ in der Terminologie des Dokuments) zu berücksichtigen.

Für Industrieprodukte für militärische Zwecke werden folgende Stufen vorgeschlagen:

1. Forschung und Begründung der Entwicklung.
2. Entwicklung.
3. Produktion.
4. Ausbeutung.
5. Große Renovierung.

Im Lebenszyklus militärisch-industrieller Produkte wird vorgeschlagen, 25 Arten von Arbeiten und 7 Arten von Stakeholdern (Arbeitsteilnehmer) zu berücksichtigen.

Typisches Software-Lebenszyklusmodell

Die Systemlebenszyklusphasen und ihre Komponentenphasen, dargestellt in der Abbildung „Systemlebenszyklusmodell“, gelten für die komplexesten Systeme, einschließlich solcher, die Software mit einem erheblichen Funktionsumfang auf Komponentenebene enthalten. In softwareintensiven Systemen, in denen Software nahezu alle Funktionen übernimmt (z. B. in modernen Finanzsystemen, Ticketreservierungssystemen, dem globalen Internet usw.), sind Lebenszyklen in der Regel inhaltlich ähnlich, werden jedoch häufig durch Iteration verkompliziert Prozesse und Prototyping: 72-73.

Hauptphasen des Systemlebenszyklus (Kossiakoff, Sweet, Seymour, Biemer)

Wie in der Abbildung „Systemlebenszyklusmodell“ dargestellt, enthält das Systemlebenszyklusmodell drei Phasen. Die ersten beiden Phasen finden während der Entwicklung statt und die dritte Phase umfasst die Nachentwicklung. Diese Phasen zeigen allgemeinere Übergänge von Zustand zu Zustand im Lebenszyklus eines Systems und zeigen auch Änderungen in der Art und dem Umfang der Aktivitäten im System-Engineering. Die Stufen sind:73:

• Konzeptentwicklungsphase;
• technischer Entwicklungsstand;
• Post-Entwicklungsphase.

Konzeptentwicklungsphase

Der Zweck der Konzeptentwicklungsphase besteht darin, neue Möglichkeiten im Anwendungsbereich des Systems zu bewerten und vorläufig zu entwickeln System Anforderungen und mögliche Designlösungen. Die Phase der konzeptionellen Designentwicklung beginnt mit der Erkenntnis, dass ein neues System erstellt oder ein bestehendes geändert werden muss. Die Phase umfasst den Beginn der Faktenrecherche, eine Planungsphase und die Bewertung der wirtschaftlichen, technischen, strategischen und marktbezogenen Grundlagen zukünftiger Maßnahmen. Es findet ein Dialog zwischen Stakeholdern und Entwicklern statt.

Hauptziele der Konzeptentwicklungsphase:74:

1. Führen Sie Untersuchungen durch, um festzustellen, was für das neue System benötigt wird und ob das System technisch und wirtschaftlich machbar ist.
2. Erkunden Sie mögliche Systemkonzepte und formulieren und validieren Sie eine Reihe von Systemleistungsanforderungen.
3. Wählen Sie das attraktivste Anlagenkonzept aus und definieren Sie es funktionelle Eigenschaften sowie die Entwicklung eines detaillierten Plans für die nachfolgenden Phasen des Entwurfs, der Produktion und des betrieblichen Einsatzes des Systems.
4. Entwickeln Sie irgendwelche neue Technologie Eignung für das gewählte Systemkonzept und Validierung seiner Eignung zur Erfüllung der Anforderungen.

Technische Entwicklungsphase

Die technische Entwicklungsphase umfasst den Prozess des Entwurfs eines Systems, um die im Systemkonzept formulierten Funktionen in eine physische Ausführungsform umzusetzen, die in ihrer Betriebsumgebung unterstützt und erfolgreich betrieben werden kann. Die Systemtechnik befasst sich in erster Linie mit der Richtung von Entwicklung und Design, der Verwaltung von Schnittstellen und der Entwicklung von Testplänen und legt fest, wie Abweichungen in der Leistung eines Systems, die während der Tests und Evaluierung nicht überprüft wurden, ordnungsgemäß korrigiert werden sollten. Der Großteil der Ingenieurtätigkeiten wird in dieser Phase durchgeführt.

Die Hauptziele der technischen Entwicklungsphase sind:74:

1. Führen Sie die technische Entwicklung eines Systemprototyps durch, der die Anforderungen an Leistung, Zuverlässigkeit, Wartbarkeit und Sicherheit erfüllt.
2. Entwerfen Sie ein gebrauchstaugliches System und demonstrieren Sie dessen betriebliche Eignung.

Post-Entwicklungsphase

Die Nachentwicklungsphase besteht aus Aktivitäten außerhalb der Systementwicklungsphase, erfordert aber dennoch erhebliche Unterstützung durch Systemingenieure, insbesondere wenn unerwartete Probleme auftreten, die eine sofortige Lösung erfordern. Darüber hinaus erfordern Fortschritte in der Technologie häufig interne Upgrades von Servicesystemen, die ebenso von der Systemtechnik abhängen können wie die Konzept- und technischen Entwicklungsphasen.

Laborarbeit Nr. 1

Identifizierung der Lebenszyklen des Computersystemdesigns

Ziel der Arbeit: sich mit Lebenszyklusmodellen von Informationssystemen vertraut machen, Vor- und Nachteile von Modellen ermitteln, ein Modell zum Aufbau eines Informationssystems für eine einzelne Projektaufgabe und Software auswählen, einen Plan für die Umsetzung einer einzelnen Projektaufgabe erstellen.

Kurze theoretische Informationen.

Lebenszyklus eines Informationssystems

Die Entwicklung komplexer Informationssysteme (IS) ist ohne einen sorgfältig durchdachten methodischen Ansatz nicht möglich. Das Konzept des Lebenszyklus ist eines der Grundkonzepte der Entwurfsmethodik von Informationssystemen.

IS-Lebenszyklus –Dies ist ein kontinuierlicher Prozess vom Moment der Entscheidung über die Notwendigkeit, eine Lösung zu erstellen, bis zum vollständigen Abschluss des Betriebs.

Der AIS-Entwurfsprozess wird durch die folgende Dokumentation (Standards, Methoden, Modelle) geregelt:

· GOST 34.601-90. In Kraft getreten am 01.01.1992. Legt die Phasen und Phasen der Erstellung automatisierter Systeme fest und gibt den Arbeitsinhalt in jeder Phase an. Die in der Norm verankerten Arbeitsschritte und Arbeitsschritte entsprechen Kaskadenmodell Lebenszyklus.

· ISO/IEC 12207:1995. Ein internationaler Standard, der Software-Lebenszyklusprozesse beschreibt. Enthält eine Beschreibung von mehr als 220 grundlegenden Arbeiten, die bei der Erstellung eines IP erforderlich sein können. Alle Software-Lebenszyklusprozesse sind in drei große Gruppen unterteilt:

o Hauptprozesse (Einkauf, Lieferung, Entwicklung, Betrieb, Support);

Ö Hilfsprozesse(Dokumentation, Konfigurationsmanagement, Qualitätssicherung, Problemlösung, Audit, Zertifizierung, gemeinsame Bewertung, Verifizierung);

o Organisatorische Prozesse (Infrastrukturerstellung, Management, Schulung, Verbesserung).

Zur Umsetzung der Vorgaben des Standards müssen Werkzeuge ausgewählt werden, die zusammen einen zusammenhängenden Komplex aus technologischer Unterstützung und Automatisierung des Software-Lebenszyklus bilden und nicht im Widerspruch zum vorgefertigten Set stehen Regulierungsdokumente. Zu erleichtern praktischer Nutzen Standard wurden die folgenden Dokumente von der internationalen Organisation für Standardisierung entwickelt und genehmigt:

o ISO/IEC TR 15271:1998 – Anleitung zur Anwendung von ISO/IEC 12207;

o ISO/IEC TR 16326:1999 – Anleitung zum Projektmanagement bei Verwendung von ISO/IEC 12207.

· ISO/IEC 15288:2002. Internationaler Standard zur Beschreibung mögliche Prozesse Lebenszyklus von Systemen, die vom Menschen geschaffen wurden. Es wurde unter Berücksichtigung der Erfahrung beim Entwurf automatisierter Informationssysteme sowie unter Einbeziehung von Spezialisten aus verschiedenen Bereichen erstellt: Systemtechnik, Programmierung, Verwaltung, Qualitätsmanagement, Sicherheit usw. Der Standard soll den vollständigen Satz von Prozessen enthalten, die während des Lebenszyklus eines Systems auftreten können. Die Aufgabe des IS-Entwicklers besteht also darin, das von ihm benötigte Set – die Prozessumgebung – zu erstellen. Die Überprüfung des Standards stellt fest, dass er nicht die Methoden und Verfahren beschreibt, die erforderlich sind, um sicherzustellen, dass die Ziele, Vorgaben und Ergebnisse der festgelegten Prozesse erreicht werden. Im Jahr 2003 wurde eine Anleitung zur Anwendung der Norm (ISO/IEC TR 19760:2003) herausgegeben. Derzeit wird an der Vorbereitung einer neuen Ausgabe des Standards der Serie 15288 gearbeitet.

· Rational Unified Process (RUP) ist ein Konzept der iterativen (spiralförmigen) Softwareentwicklung, das von Rational Software (heute eine Abteilung von IBM) vorgeschlagen wird. Der IS-Lebenszyklus besteht aus vier Phasen: Gründung, Forschung, Aufbau und Übergang. Jede Phase kann mehrere Iterationen enthalten. Darüber hinaus bedeutet der Abschluss aller vier Phasen nicht immer den Abschluss der Arbeiten am Projekt – seine Entwicklung kann in einem neuen Zyklus fortgesetzt werden. Im Rahmen der Iterationen entstehen untereinander konsistente Modelle, die in einer eigens entwickelten UML (Unified Modeling Language) beschrieben werden.

· Microsoft Solution Framework (MSF). Iterative Anwendungsentwicklungsmethodik ähnlich wie RUP. Es umfasst außerdem vier Phasen: Analyse, Design, Entwicklung, Stabilisierung und beinhaltet den Einsatz objektorientierter Modellierung. Im Vergleich zu RUP konzentriert es sich stärker auf die Entwicklung von geistigem Eigentum für Unternehmen.

· Extreme Programmierung (XP). Extreme Programming ist die neueste unter den betrachteten Methoden (die ersten Ideen entstanden Mitte der 1990er Jahre). Grundprinzipien: Teamarbeit, effektive Interaktion zwischen Auftraggeber und Auftragnehmer über den gesamten Zeitraum der IP-Entwicklung, Einsatz sukzessive verfeinerter Prototypen, Erzielung maximaler Entwicklungsflexibilität (Anpassung an sich ändernde Kundenanforderungen).

IS-Lebenszyklusmodelle.

Unter dem IS-Lebenszyklusmodell wird eine Struktur verstanden, die die Reihenfolge der Ausführung und die Beziehungen zwischen Handlungs- und Aufgabenprozessen im gesamten Lebenszyklus bestimmt.

IP-Lebenszyklusmodell- Hierbei handelt es sich um eine Struktur, die die Prozesse, Aktionen und Aufgaben beschreibt, die während der Entwicklung, des Betriebs und der Wartung über den gesamten Lebenszyklus des Systems ausgeführt werden.

Die Wahl eines Lebenszyklusmodells hängt von den Besonderheiten, dem Umfang, der Komplexität des Projekts und den Bedingungen ab, unter denen das AIS erstellt und betrieben wird.

Gemäß berühmte Modelle Software-Lebenszyklen werden durch IS-Lebenszyklusmodelle bestimmt - Kaskade, iterativ, Spirale.

I. Kaskadenmodell beschreibt den klassischen Ansatz zur Entwicklung von Systemen in jedem Themenbereich; in den 1970er und 80er Jahren weit verbreitet.

Das Kaskadenmodell sieht eine sequentielle Arbeitsorganisation vor, und das Hauptmerkmal des Modells ist die Aufteilung aller Arbeiten in Phasen. Der Übergang von der vorherigen Stufe zur nächsten erfolgt erst nach vollständigem Abschluss aller Arbeiten der vorherigen Stufe.

Markieren fünf Nachhaltige Entwicklungsstadien, praktisch unabhängig vom Fachgebiet:

Im ersten Schritt wird eine Untersuchung des Problembereichs durchgeführt und die Anforderungen des Kunden formuliert. Das Ergebnis dieser Phase ist eine mit allen Interessenten abgestimmte technische Spezifikation (Entwicklungsaufgabe).

Im zweiten Schritt werden entsprechend den Anforderungen des technischen Lastenhefts bestimmte Designlösungen entwickelt. Das Ergebnis ist eine Menge Projektdokumentation.

Die dritte Stufe ist die Projektumsetzung; Im Wesentlichen Softwareentwicklung (Codierung) gemäß den Designentscheidungen der vorherigen Phase. Implementierungsmethoden sind in diesem Fall nicht von grundlegender Bedeutung. Das Ergebnis dieser Phase ist ein fertiges Softwareprodukt.

Im vierten Schritt wird die resultierende Software auf Übereinstimmung mit den in den technischen Spezifikationen genannten Anforderungen überprüft. Der Probebetrieb ermöglicht es, verschiedene Arten versteckter Mängel zu identifizieren, die unter realen Betriebsbedingungen des IS auftreten.

Die letzte Phase ist die Lieferung des fertigen Projekts.

In jeder Phase wird eine vollständige Entwurfsdokumentation erstellt, die den Kriterien Vollständigkeit und Konsistenz entspricht. In der Endphase wird eine Benutzerdokumentation entwickelt, die alle in den Standards vorgesehenen Arten der AIS-Unterstützung abdeckt (organisatorisch, informativ, softwaretechnisch, technisch usw.). Durch die konsequente Ausführung der Arbeitsschritte können Sie Fertigstellungstermine und damit verbundene Kosten planen.

Gleichzeitig ist für das Kaskadenmodell eine erhebliche Verzögerung bei der Erzielung von Ergebnissen, die Komplexität der parallelen Arbeit am Projekt und die Komplexität des Projektmanagements und infolgedessen ein hohes Maß an Risiko und Unzuverlässigkeit festzustellen Investitionen in geistiges Eigentum. Darüber hinaus treten Fehler und Mängel in jeder Phase in der Regel auch in späteren Arbeitsphasen auf, was zur Notwendigkeit einer Rücksendung führt.

II. Iteratives Modell liegt in der Serie kurze Zyklen(Schritte) zum Planen, Umsetzen, Studieren, Handeln. Die IS-Entwicklung ist im Gange Iterationen mit Rückkopplungsschleifen zwischen den Stufen. Zwischenstufenanpassungen ermöglichen es, die tatsächliche gegenseitige Beeinflussung der Entwicklungsergebnisse in verschiedenen Stufen zu berücksichtigen; Die Lebensdauer jeder Stufe erstreckt sich über den gesamten Entwicklungszeitraum.

Bei der Erstellung komplexer Informationssysteme geht es um die Koordination von Designlösungen, die bei der Umsetzung einzelner Aufgabenstellungen gewonnen werden. Der „Bottom-up“-Designansatz erfordert solche Renditeiterationen, bei denen Designlösungen für einzelne Aufgaben zu allgemeinen Systemlösungen kombiniert werden. Gleichzeitig besteht die Notwendigkeit, bereits formulierte Anforderungen zu überarbeiten.

Im iterativen Modell sorgen stufenübergreifende Anpassungen im Vergleich zum Wasserfallmodell für eine weniger arbeitsintensive Entwicklung.

Gleichzeitig wird die Lebensdauer jeder Stufe über die gesamte Arbeitsdauer verlängert große Zahl Iterationen, Diskrepanzen bei der Umsetzung von Entwurfsentscheidungen und der Dokumentation können in der Implementierungsphase zu einer Neugestaltung des gesamten Systems führen.

III. Spiralmodell Im Gegensatz zur Kaskade, aber ähnlich der vorherigen, geht es von einem iterativen Prozess der IS-Entwicklung aus. Gleichzeitig steigt die Bedeutung der ersten Phasen wie Analyse und Design, in denen die Machbarkeit technischer Lösungen durch die Erstellung von Prototypen überprüft und begründet wird.

Jede Iteration stellt einen vollständigen Entwicklungszyklus dar, der zur Veröffentlichung einer internen oder externen Version eines Produkts (oder einer Teilmenge des Endprodukts) führt, die von Iteration zu Iteration verbessert wird, um ein vollständiges System zu werden:

Somit entspricht jede Windung der Spirale der Erstellung eines Fragments oder einer Version eines Softwareprodukts, die Ziele und Eigenschaften des Projekts werden geklärt, seine Qualität bestimmt und die Arbeit für die nächste Windung der Spirale geplant. Jede Iteration dient dazu, die Details des Projekts zu vertiefen und konsistent zu spezifizieren, wodurch eine sinnvolle Option für die endgültige Umsetzung ausgewählt wird.

Die Verwendung des Spiralmodells ermöglicht den Übergang zu nächste Stufe Abschluss eines Projekts, ohne darauf zu warten, dass das aktuelle Projekt vollständig abgeschlossen ist – unvollendete Arbeiten können bei der nächsten Iteration abgeschlossen werden. Die Hauptaufgabe jeder Iteration besteht darin, ein funktionierendes Produkt zu erstellen, das den Benutzern so schnell wie möglich demonstriert werden kann. Dadurch wird der Prozess der Klärung und Ergänzung des Projekts deutlich vereinfacht.

Der Spiralansatz bei der Softwareentwicklung überwindet die meisten Nachteile des Wasserfallmodells und bietet darüber hinaus eine Reihe zusätzlicher Funktionen, die den Entwicklungsprozess flexibler machen. Durch die Verwendung des Spiralmodells werden Änderungen am Projekt bei sich ändernden Kundenanforderungen erheblich vereinfacht, das Risikoniveau wird reduziert (das Risikoniveau ist zu Beginn der Projektentwicklung maximal, mit fortschreitender Entwicklung nimmt es ab) und die Flexibilität erhöht im Projektmanagement wird aufgrund der Möglichkeit, taktische Änderungen am entwickelten Produkt vorzunehmen, die Fähigkeit zur Verbesserung des Entwicklungsprozesses bereitgestellt – als Ergebnis der Analyse am Ende jeder Iteration wird eine Bewertung der Änderungen in der Entwicklungsorganisation durchgeführt; In der nächsten Iteration wird es besser, die Wiederverwendung von Komponenten wird einfacher, da es viel einfacher ist, gemeinsame Teile des Projekts zu identifizieren, wenn sie bereits teilweise entwickelt sind, als zu versuchen, sie gleich zu Beginn des Projekts zu isolieren. Das Spiralmodell ermöglicht ein zuverlässigeres und stabileres System. Dies liegt daran, dass im Zuge der Weiterentwicklung des Systems bei jeder Iteration Fehler und Schwachstellen entdeckt und korrigiert werden. Gleichzeitig werden sie angepasst kritische Parameter Effizienz, die beim Kaskadenmodell erst vor der Systemimplementierung verfügbar ist. Durch die Einbeziehung der Benutzer in den Prozess des Entwerfens und Kopierens der Anwendung können Sie Kommentare und Ergänzungen zu den Anforderungen direkt während des Anwendungsdesignprozesses erhalten und so die Entwicklungszeit verkürzen. Kundenvertreter haben die Möglichkeit, den Entstehungsprozess des Systems zu steuern und dessen Funktionsinhalt zu beeinflussen. Das Ergebnis ist die Inbetriebnahme eines Systems, das den Großteil der Kundenbedürfnisse berücksichtigt.

Allerdings ist das Spiralmodell des IC-Designs in der Regel mit hohen Kosten verbunden (daher ist es sinnvoll, es für komplexe und teure Systeme zu verwenden). Das Modell hat Komplexe Struktur, was die praktische Anwendung durch ungeschulte Fachkräfte und Kunden erschweren kann. Die Spirale kann unendlich weitergehen, da jede Kundenreaktion auf die erstellte Version einen neuen Arbeitszyklus generieren kann. Eine große Anzahl von Zwischenschritten erschwert die Pflege der Projektdokumentation. Es kann schwierig sein zu bestimmen, wann mit der nächsten Iteration des Zyklus fortgefahren werden soll. Typischerweise unterliegen die Ausführung der Iteration und jede ihrer Phasen zeitlichen Beschränkungen.

In manchen Situationen ist die Verwendung des Spiralmodells unmöglich oder eingeschränkt, da es unmöglich ist, ein Produkt mit unvollständiger Funktionalität zu verwenden/zu testen (z. B. militärische Entwicklungen, Atomkraft usw.). Die schrittweise iterative Implementierung von Unternehmensinformationssystemen ist in der Regel mit organisatorischen Schwierigkeiten verbunden (Datentransfer, Systemintegration, Änderungen in Geschäftsprozessen, Rechnungslegungsrichtlinien, Benutzerschulung). Die Arbeitskosten während der schrittweisen iterativen Umsetzung fallen deutlich höher aus, und ein ungebildetes Management des Umsetzungsprozesses kann alle erzielten Ergebnisse zunichte machen. Aus diesem Grund wird in der Implementierungsphase häufig auf iterative Modelle verzichtet und das System „ein für alle Mal“ eingeführt.

©2015-2019 Website
Alle Rechte liegen bei ihren Autoren. Diese Seite erhebt keinen Anspruch auf Urheberschaft, stellt die Nutzung jedoch kostenfrei zur Verfügung.
Erstellungsdatum der Seite: 27.04.2016

VORTRAG 10

LEBENSZYKLUS DES SYSTEMS

Lebenszyklusmodelle und ihre Hauptphasen

Bei der Beschreibung des Systemlebenszyklus werden folgende Konzepte verwendet:

Prozess – eine Kette nacheinander ausgeführter Arbeiten;

Phasen – aufeinanderfolgende Zeiträume, in denen Arbeit ausgeführt wird . Während der Phase können Arbeiten im Zusammenhang mit verschiedenen Prozessen durchgeführt werden. Die Tätigkeit der Erstellung und Nutzung eines automatisierten Unternehmensmanagementsystems (EMS) basiert auf dem Konzept seines Lebenszyklus (LC). Der Lebenszyklus ist ein Modell für die Erstellung und Nutzung automatisierter Kontrollsysteme, das deren verschiedene Zustände widerspiegelt, beginnend mit der Entstehung des Bedarfs an einem bestimmten Produkt und endend mit dem Moment seiner völligen Obsoleszenz für alle Benutzer ausnahmslos.

Traditionell werden die folgenden Hauptphasen des Lebenszyklus automatisierter Steuerungssysteme unterschieden:

Anforderungsanalyse;

Design;

Programmierung/Implementierung;

Testen und Debuggen;

Betrieb und Instandhaltung.

Der Lebenszyklus wird nach dem Prinzip des Top-Down-Designs gebildet und ist in der Regel iterativer Natur: Die implementierten Phasen, beginnend mit den frühesten, werden entsprechend sich ändernden Anforderungen und äußeren Bedingungen zyklisch wiederholt Einführung von Beschränkungen usw. In jeder Phase des Lebenszyklus wird ein bestimmter Satz von Dokumenten und technischen Lösungen generiert, und für jede Phase werden die in der vorherigen Phase erhaltenen Ausgangsdokumente und Entscheidungen verwendet. Jede Phase endet mit der Überprüfung der erstellten Dokumente und Lösungen, um deren Übereinstimmung mit den Originaldokumenten zu überprüfen.

Bestehende Lebenszyklusmodelle bestimmen die Reihenfolge der Ausführung von Phasen während der Entwicklung sowie die Kriterien für den Übergang von Phase zu Phase. Dementsprechend sind die folgenden drei Lebenszyklusmodelle am weitesten verbreitet:

1. Kaskadenmodell(in den 70-80er Jahren) - beinhaltet einen Übergang zur nächsten Stufe nach vollständigem Abschluss der Arbeiten an der vorherigen Stufe und zeichnet sich durch eine klare Trennung von Daten und deren Verarbeitungsprozessen aus.

2. Stufenmodell mit Zwischensteuerung(in den 80er und 85er Jahren) – ein iteratives Entwicklungsmodell mit Rückkopplungsschleifen zwischen den Phasen. Der Vorteil dieses Modells besteht darin, dass stufenübergreifende Anpassungen im Vergleich zum Kaskadenmodell zu einer geringeren Arbeitsintensität führen. Andererseits erstreckt sich die Lebensdauer jeder Stufe über den gesamten Entwicklungszeitraum.

3. Spiralmodell(in den 86-90er Jahren) – konzentriert sich auf die Anfangsphasen des Lebenszyklus: Anforderungsanalyse, Spezifikationsentwurf, vorläufiger und detaillierter Entwurf. In diesen Phasen wird die Machbarkeit technischer Lösungen überprüft und durch die Erstellung von Prototypen begründet. Jede Windung der Spirale entspricht einem Schritt-für-Schritt-Modell zur Erstellung eines Fragments oder einer Version des Systems. Darauf werden die Ziele und Merkmale des Projekts geklärt, seine Qualität bestimmt und die Arbeit der nächsten Windung festgelegt Spirale ist geplant. Auf diese Weise werden die Details des Projekts vertieft und konsistent spezifiziert und im Ergebnis eine sinnvolle Option ausgewählt, die zur Umsetzung gebracht wird.

Experten weisen auf folgende Vorteile des Spiralmodells hin:

Ansammlung und Wiederverwendung von Software, Modellen und Prototypen;

Orientierung an der Entwicklung und Modifikation des Systems im Prozess seiner Gestaltung;

Risiko- und Kostenanalyse während des Designprozesses

. Beachten Sie, dass das Hauptmerkmal der Branche der automatisierten Steuerungssysteme die Konzentration der Komplexität ist Anfangsstadien Lebenszyklus (Analyse, Design) mit relativ geringer Komplexität und Arbeitsintensität der nachfolgenden Phasen. Darüber hinaus führen ungelöste Probleme und Fehler in der Analyse- und Entwurfsphase zu schwierigen, oft unlösbaren Problemen in späteren Phasen und können letztendlich den Erfolg zunichte machen.

Anforderungsanalyse

Die Anforderungsanalyse ist die erste Phase der Entwicklung automatisierter Steuerungssysteme, in der Kundenanforderungen geklärt, formalisiert und dokumentiert werden. Tatsächlich ist in dieser Phase die Antwort auf die Frage gegeben: „Was soll das zukünftige System tun?“ Hier liegt der Schlüssel zum Erfolg des gesamten Projekts. In der Praxis des Schaffens große Systeme Gerade wegen der Unvollständigkeit und unklaren Definition der Systemanforderungen gibt es viele Beispiele für eine erfolglose Projektumsetzung.

Die Liste der Anforderungen an automatisierte Kontrollsysteme sollte Folgendes umfassen:

Die Reihe von Bedingungen, unter denen das zukünftige System voraussichtlich betrieben wird (dem System bereitgestellte Hardware- und Softwareressourcen; äußere Bedingungen seines Funktionierens; Zusammensetzung der damit verbundenen Personen und Arbeiten);

Beschreibung der vom System ausgeführten Funktionen;

Einschränkungen im Entwicklungsprozess (Richtlinienfristen für den Abschluss einzelner Phasen, verfügbare Ressourcen, organisatorische Abläufe und Maßnahmen zur Gewährleistung des Informationsschutzes).

Ziel der Analyse ist es, allgemeines, unklares Wissen über die Anforderungen an das zukünftige System in möglichst präzise Definitionen zu überführen. Das Ergebnis der Phase sollte ein Modell der Systemanforderungen sein (mit anderen Worten, ein Systemprojekt). , definiert:

Die Architektur des Systems, seine Funktionen, äußere Bedingungen, Funktionsverteilung zwischen den Hardware- und Softwareteilen (FC);

Schnittstellen und Funktionsverteilung zwischen Mensch und System;

Anforderungen an Software- und Informationskomponenten des Frequenzumrichters , notwendige Hardwareressourcen, Datenbankanforderungen, physikalische Eigenschaften der Wechselrichterkomponenten, deren Schnittstellen. Das Anforderungsmodell sollte Folgendes umfassen:

Ein vollständiges Funktionsmodell der Anforderungen an das zukünftige System mit einer detaillierten Ausarbeitung bis hin zur Ebene jeder Tätigkeit jedes Beamten;

Betriebsspezifikationen auf niedrigem Niveau;

Ein Paket von Berichten und Dokumenten zum Funktionsmodell, einschließlich Merkmalen des Modellierungsobjekts, einer Liste von Subsystemen, Anforderungen an Methoden und Kommunikationsmittel für den Informationsaustausch zwischen Komponenten, Anforderungen an die Merkmale der Beziehungen des Systems zu angrenzenden Systemen, Anforderungen an Systemfunktionen;

Konzeptionelles Informationsmodell von Anforderungen;

Paket von Berichten und Dokumenten zum Informationsmodell;

Systemarchitektur unter Bezug auf das konzeptionelle Informationsmodell;

Vorschläge für eine Organisationsstruktur zur Unterstützung des Systems.

Somit enthält das Anforderungsmodell Funktions-, Informations- und ggf. Ereignismodelle (sofern es sich bei dem Zielsystem um ein Echtzeitsystem handelt). Bietet eine Reihe von Vorteilen gegenüber dem herkömmlichen Modell:

1. Die traditionelle Entwicklung zeichnet sich durch die Umsetzung der Anfangsphasen mit handwerklichen, nicht formalisierten Methoden aus. Dadurch können Kunden und Anwender das System erstmals sehen, nachdem es bereits weitgehend implementiert ist. Natürlich wird dieses System anders sein als erwartet. Daher werden mehrere weitere Iterationen seiner Entwicklung oder Modifikation folgen, was zusätzliche (und erhebliche) Kosten an Geld und Zeit erfordert. Der Schlüssel zur Lösung dieses Problems liegt in einem Anforderungsmodell, das Ihnen Folgendes ermöglicht:

Beschreiben, „sehen“ und passen Sie das zukünftige System an, bevor es physisch implementiert wird;

Reduzieren Sie die Kosten für die Systementwicklung und -implementierung;

Bewerten Sie die Entwicklung im Hinblick auf Zeit und Ergebnisse.

Erreichen Sie gegenseitiges Verständnis zwischen allen an der Arbeit Beteiligten (Kunden, Benutzer, Entwickler, Programmierer usw.);

Verbessern Sie die Qualität des entwickelten Systems, indem Sie dessen funktionale Zerlegung durchführen und die optimale Struktur der integrierten Datenbank entwerfen.

2. Das Anforderungsmodell ist völlig unabhängig und von bestimmten Entwicklern trennbar, erfordert keine Wartung durch seine Ersteller und kann problemlos auf andere übertragen werden. Wenn ein Unternehmen aus irgendeinem Grund nicht bereit ist, ein auf einem Anforderungsmodell basierendes System zu implementieren, kann es außerdem „auf Eis gelegt“ werden, bis der Bedarf entsteht.

3. Das Anforderungsmodell kann zur eigenständigen Entwicklung oder Anpassung bereits auf seiner Basis implementierter Software durch Programmierer aus der Untergenutzt werden.

4. Das Anforderungsmodell kann zur automatisierten und schnellen Schulung neuer Mitarbeiter in einem bestimmten Tätigkeitsbereich des Unternehmens verwendet werden, da seine Technologie im Modell enthalten ist.

Die Phase der Anforderungsanalyse ist die wichtigste aller Lebenszyklusphasen. Es hat erhebliche Auswirkungen auf alle nachfolgenden Phasen und ist gleichzeitig der am wenigsten untersuchte und verstandene Prozess. In dieser Phase ist es erstens notwendig zu verstehen, was getan werden soll, und zweitens, es zu dokumentieren, denn wenn die Anforderungen nicht erfasst und den Projektbeteiligten zur Verfügung gestellt werden, dann scheinen sie nicht zu existieren. Gleichzeitig muss die Sprache, in der die Anforderungen formuliert werden, möglichst einfach und für den Kunden verständlich sein.

Andererseits ist die betrachtete Lebenszyklusphase der schwierigste Teil der Entwicklung. Die folgenden Probleme, mit denen ein Systemanalytiker konfrontiert ist, hängen miteinander zusammen (und dies ist einer der Hauptgründe, warum sie schwer zu lösen sind):

Der Analyst verfügt nicht immer über umfassende Informationen, um die Systemanforderungen aus Kundensicht einzuschätzen;

Der Kunde wiederum verfügt nicht über ausreichende Informationen über das Datenverarbeitungsproblem, um beurteilen zu können, was machbar ist und was nicht;

Der Analyst wird mit einer übermäßigen Menge an detaillierten Informationen sowohl zum Themenbereich als auch zum Thema konfrontiert neues System;

Die herkömmliche (Text-)Systembeschreibung ist aufgrund der Fülle an Fachbegriffen für den Kunden oft unverständlich;

Wenn eine solche Spezifikation für den Kunden klar ist, reicht sie für die Designer und Programmierer, die das System erstellen oder anpassen, nicht aus.

Natürlich werden durch den Einsatz bekannter Analysemethoden einzelne Analyseprobleme beseitigt, eine akzeptable Lösung für die Gesamtheit dieser Probleme kann jedoch nur durch den Einsatz moderner Methoden des System- und Software-Engineerings gefunden werden, unter denen eine Schlüsselstellung einnimmt durch die Methoden der strukturellen und objektorientierten Analyse.

Strukturelle Analysemethoden

Strukturanalyse wird üblicherweise als Methode zur Untersuchung eines Systems bezeichnet, die mit einem allgemeinen Überblick über das System beginnt und dann ins Detail geht, um eine hierarchische Struktur mit zunehmender Anzahl von Ebenen zu erhalten. . Diese Methoden zeichnen sich aus durch:

Unterteilung in Abstraktionsebenen mit einer Begrenzung der Anzahl der Elemente auf jeder Ebene (normalerweise zwischen 3 und 7, wobei die Obergrenze der Wahrnehmungsfähigkeit des menschlichen Gehirns entspricht). eine bestimmte Menge von miteinander verbundene Objekte, und das untere wurde aus Gründen ausgewählt gesunder Menschenverstand);

Eingeschränkter Kontext, der nur relevante Details auf jeder Ebene enthält;

Verwendung strenger formeller Aufzeichnungsregeln;

Konsequente Annäherung an das Endergebnis.

Strukturanalysemethoden ermöglichen es, die Komplexität großer Systeme zu überwinden, indem man sie in Teile („Black Boxes“) zerlegt und diese Black Boxes hierarchisch organisiert . Der Vorteil der Verwendung einer Blackbox besteht darin, dass der Benutzer nicht wissen muss, wie sie funktioniert, sondern nur ihre Ein- und Ausgänge und ihren Zweck (d. h. die Funktion, die sie ausführt). In der Welt um uns herum gibt es Black Boxes große Mengen: Tonbandgerät und Fernseher auf Haushaltsebene, ein Unternehmen aus Sicht des Kunden usw. Lassen Sie uns die Vorteile daraus bestehender Systeme am Beispiel eines Musikcenters veranschaulichen.

Der Aufbau eines Black-Box-Systems wird stark vereinfacht. Es ist viel einfacher, ein Tonbandgerät oder einen Plattenspieler zu entwerfen, wenn Sie sich nicht um den Einbau einer Verstärkereinheit kümmern müssen.

Dies erleichtert das Testen solcher Systeme. Wenn der Ton aus einem der Lautsprecher schlecht ist, können Sie die Lautsprecher austauschen. Wenn sich der Fehler mit der Säule verschoben hat, muss die Säule repariert werden; Wenn nicht, liegt das Problem am Verstärker, Tonbandgerät oder deren Anschlusspunkten.

Es ist möglich, das Blackbox-System einfach umzukonfigurieren. Wenn der Lautsprecher defekt ist, können Sie ihn in eine Reparaturwerkstatt bringen und die Aufnahmen im Mono-Modus weiterhören.

Erleichtert das Verstehen und Beherrschen. Es ist möglich, Tonbandgerät-Spezialist zu werden, ohne über fundierte Sprecherkenntnisse zu verfügen.

Verbessert die einfache Änderung. Sie können Lautsprecher für mehr als erwerben Gute Qualität und einen leistungsstärkeren Verstärker, aber das bedeutet nicht, dass ein größerer Player benötigt wird.

Daher besteht der erste Schritt zur Vereinfachung eines komplexen Systems darin, es in Black Boxes zu zerlegen (das „Teile-und-Herrsche“-Prinzip – das Prinzip, schwierige Probleme zu lösen, indem man sie in viele unabhängige Aufgaben aufteilt, die leicht zu verstehen und zu lösen sind) und eine solche Aufteilung muss folgende Kriterien erfüllen:

Jede Blackbox muss eine einzelne Funktion des Systems implementieren;

Die Funktion jeder Black Box sollte leicht verständlich sein, unabhängig von der Komplexität ihrer Implementierung (z. B. kann ein Raketensteuerungssystem über eine Black Box zur Berechnung seines Landeplatzes verfügen: Trotz der Komplexität des Algorithmus ist die Funktion der Black Box nicht erkennbar Es ist offensichtlich - Landepunktberechnung);

Der Zusammenhang zwischen Blackboxen sollte nur dann eingeführt werden, wenn ein Zusammenhang zwischen den entsprechenden Funktionen des Systems besteht (z. B. wird in der Buchhaltung eine Blackbox zur Berechnung der Summe benötigt). Löhne Arbeitnehmer und zum anderen – zur Berechnung der Steuern ist ein Zusammenhang zwischen diesen Black Boxes notwendig: Zur Berechnung der Steuern ist die Höhe des Lohns erforderlich);

Die Verbindungen zwischen Blackboxen sollten so einfach wie möglich sein, um die Unabhängigkeit zwischen ihnen zu gewährleisten.

Die zweite wichtige Idee, die strukturellen Methoden zugrunde liegt, ist die Idee der Hierarchie. Um ein komplexes System zu verstehen, reicht es nicht aus, es in Teile zu zerlegen; es ist notwendig, diese Teile auf eine bestimmte Weise zu organisieren, nämlich in Form hierarchischer Strukturen. Alle komplexen Systeme des Universums sind in Hierarchien organisiert. Und es selbst umfasst Galaxien, Sternensysteme, Planeten, Moleküle, Atome und Elementarteilchen. Bei der Schaffung komplexer Systeme ahmt der Mensch auch die Natur nach. Jede Organisation hat einen Direktor, Stellvertreter in den Bereichen, eine Hierarchie von Abteilungsleitern und normale Mitarbeiter. Das zweite Prinzip der Strukturanalyse (das Prinzip der hierarchischen Ordnung) besagt also, dass neben der Tatsache, dass es einfacher ist, ein Problem zu verstehen, wenn es in Teile zerlegt wird, auch die Anordnung dieser Teile für das Verständnis von wesentlicher Bedeutung ist. Die Verständlichkeit eines Problems erhöht sich dramatisch, wenn seine Teile in baumartigen hierarchischen Strukturen organisiert werden, das heißt, das System kann in Ebenen verstanden und aufgebaut werden, die jeweils neue Details hinzufügen.

Zum Schluss noch das dritte Prinzip: Strukturelle Methoden nutzen in großem Umfang grafische Notationen, dient auch dazu, das Verständnis komplexer Systeme zu erleichtern. Es ist bekannt, dass „ein Bild mehr sagt als tausend Worte“.

Die Einhaltung dieser Grundsätze ist bei der Organisation der Arbeit in den Anfangsphasen des Lebenszyklus erforderlich, unabhängig von der Art des zu entwickelnden Systems und den verwendeten Methoden. Geleitet von allen Prinzipien in einem Komplex ermöglicht es mehr frühe Stufen Entwicklung, um zu verstehen, wie das erstellte System aussehen wird, um Fehler und Mängel zu erkennen, was wiederum die Arbeit in späteren Phasen des Lebenszyklus erleichtert und die Entwicklungskosten senkt.

Für die Zwecke der Strukturanalyse werden traditionell drei Gruppen von Werkzeugen verwendet, die Folgendes veranschaulichen:

Funktionen, die das System ausführen muss,

Beziehungen zwischen Daten,

zeitabhängiges Verhalten des Systems (Echtzeitaspekte).

Unter den verschiedenen grafischen Notationen, die zur Lösung der aufgeführten Probleme verwendet werden, werden die folgenden am häufigsten und effektivsten in Strukturanalysemethoden verwendet:

DFD(Datenflussdiagramme) - Datenflussdiagramme zusammen mit Datenwörterbücher und Prozessspezifikationen (Minispezifikationen);

ERD(Entity-Relationship-Diagramme) - Diagramme"Wesen-Verbindung»;

STD(Zustandsübergangsdiagramme) - Zustandsübergangsdiagramme.

Ein klassisches DFD zeigt Datenquellen und -senken (Ziel) außerhalb des Systems an, identifiziert logische Funktionen (Prozesse) und Gruppen von Datenelementen, die eine Funktion mit einer anderen verknüpfen (Threads), und identifiziert auch Datenspeicher (Laufwerke), auf die zugegriffen wird. Datenflussstrukturen und Definitionen ihrer Komponenten werden in einem Datenwörterbuch gespeichert und analysiert. Jede logische Funktion (Prozess) kann mithilfe eines DFD auf niedrigerer Ebene detailliert beschrieben werden. Wenn weitere Details nicht mehr sinnvoll sind, fahren Sie mit dem Ausdrücken der Logik der Funktion mithilfe einer Prozessspezifikation (Minispezifikation) fort. Der Inhalt jedes Repositorys wird auch in einem Datenwörterbuch gespeichert, das Datenmodell des Repositorys wird mithilfe von ERD verfügbar gemacht. Im Fall von Echtzeit wird DFD durch die Beschreibung des zeitabhängigen Verhaltens des Systems ergänzt, das mithilfe von STD ermittelt wird. Diese Beziehungen sind in Abb. dargestellt. 20.

Es ist zu beachten, dass für die funktionale Modellierung neben DFD häufig eine andere Notation verwendet wird – SADT (genauer gesagt seine standardisierte Teilmenge IDEFO). Vergleichende Analyse Diese beiden Ansätze zur Modellierung von Systemfunktionen werden im Folgenden vorgestellt.

Mit den oben aufgeführten Tools können Sie dies tun Gesamte Beschreibung Systeme, unabhängig davon, ob sie bereits vorhanden sind oder von Grund auf neu entwickelt werden. Diese detaillierte Beschreibung dessen, was das System tun soll, weitestgehend frei von der Betrachtung von Implementierungspfaden, wird als Anforderungsspezifikation bezeichnet und gibt dem Designer, der die nächste Phase des Lebenszyklus implementiert, eine klare Vorstellung davon, welche Endergebnisse erzielt werden müssen erreicht.

Die oben aufgeführten grafischen Notationen werden (in der einen oder anderen Menge) in fast allen verwendet moderne Methoden Strukturelle Systemanalyse. Die Rolle dieser Methoden besteht darin, die Grundlagen der Entwicklung komplexer Systeme zu regeln. Sie beschreiben die Abfolge von Schritten, Modellen und

Reis. 20

Ansätze, die, wenn sie sorgfältig befolgt werden, zu gut funktionierenden Systemen führen. Obwohl Methoden im Allgemeinen keine Garantie für die Qualität gebauter Systeme sind, tragen sie dennoch dazu bei, alle wichtigen Phasen, Schritte und Momente der Entwicklung abzudecken und zu berücksichtigen, helfen bei der Bewältigung von Dimensionsproblemen und letztendlich bei der Bewertung des Fortschritts. Darüber hinaus bieten Methoden organisatorische Unterstützung, die es großen Entwicklungsteams ermöglicht, koordiniert zu arbeiten.

Mit anderen Worten definiert die Strukturanalysemethodik die Richtlinien für die Erstellung und Bewertung des Anforderungsmodells des zu entwickelnden Systems, die durchzuführenden Arbeitsschritte, deren Reihenfolge sowie die Regeln für die Verteilung und Zuordnung der Operationen und Methoden gebraucht.

Derzeit werden fast alle bekannten Strukturanalysemethoden erfolgreich eingesetzt, aber die am weitesten verbreiteten Methoden sind SADT (Structured Analysis and Design Technique), Gane-Sarson-Struktursystemanalyse, Yourdon-DeMarko-Strukturanalyse und -Design), Entwicklung von Jackson-Systemen, Entwicklung von Struktursystemen von Warmer-Orr, Analyse und Design von Echtzeitsystemen von Ward-Mellor und Hatley, Informationsmodellierung von Martin.

Die aufgeführten Strukturmethoden regeln streng die Phasen der Anforderungsanalyse und des Spezifikationsentwurfs und spiegeln einen „Kochbuch“-Ansatz für die Systementwicklung wider. Zu den Anforderungsspezifikationen gehören Merkmale des Zielsystems und seine vorhergesagten Eigenschaften, Benutzeroberflächendesigns (Menüs, Bildschirme und Formulare), Systemleistungskriterien sowie Software- und Hardwareumgebung. Das resultierende Anwird weiter in Designspezifikationen umgewandelt, in denen die beabsichtigte Implementierung des Antriebs detailliert beschrieben wird. Designspezifikationen identifizieren die Hauptmodule, Kommunikations- und Steuerwege zwischen Modulen, Hauptroutinen innerhalb jedes Moduls, Datenstrukturen und Spezifikationen für Eingabe- und Ausgabedateiformate. Für Schlüsselprozesse enthalten Designspezifikationen häufig Algorithmusdetails in einer Minispezifikations-Designsprache. Zukünftig bieten strukturelle Methoden eine Technik zur Übersetzung von Designspezifikationen in Programmcodes. Die Codegenerierung setzt die Existenz von Codestandards voraus, die das Format von Unterprogrammüberschriften, das gestaffelte Erscheinungsbild verschachtelter Blöcke, die Nomenklatur zur Angabe von Variablen und Namen von Unterprogrammen usw. festlegen.

Moderne Strukturmethoden werden nach den folgenden drei Merkmalen klassifiziert:

VonAttitüdeZuSchulen - Software Engineering (SE) undInformationstechnik (IE);

in der Reihenfolge der Konstruktion des Modells – verfahrensorientiert und informationsorientiert;

Typ Zielsysteme - für Echtzeitsysteme (RTS) und Informationssysteme (IS).

SE ist eine universelle Disziplin in der Entwicklung von Softwaresystemen aller Art (IS, SRV). IE ist die Disziplin des Aufbaus von IS im Allgemeinen und nicht nur ihrer Softwarekomponenten, sondern umfasst auch Phasen weiterer Aspekte hohes Level(zum Beispiel strategische Planung), jedoch sind diese Disziplinen in der Phase der Analyse der Anforderungen für den Softwareteil ähnlich.

Der traditionelle verfahrensorientierte Ansatz regelt den Vorrang des Entwurfs funktionaler Komponenten gegenüber dem Entwurf von Datenstrukturen: Datenanforderungen werden durch funktionale Anforderungen offengelegt. Bei einem informationszentrierten Ansatz sind Eingabe und Ausgabe am wichtigsten – zunächst werden Datenstrukturen definiert und aus den Daten werden prozedurale Komponenten abgeleitet.

Das Hauptmerkmal von Echtzeitsystemen besteht darin, dass sie externe Ereignisse überwachen und durch diese gesteuert werden. Die rechtzeitige Reaktion auf diese Ereignisse ist die Hauptfunktion solcher Systeme. Die grundlegenden Unterschiede zwischen Informationssystemen und Echtzeitsystemen sind in der Tabelle aufgeführt. 2;

Tabelle 2

Die Mittel zur Unterstützung dieser Merkmale unterscheiden die entsprechenden Strukturmethoden. Es ist zu beachten, dass zur Analyse der Anforderungen an Echtzeitsysteme spezielle Arten von Strukturdiagrammen verwendet werden: Kontrollflussdiagramme, Zustandsübergangsdiagramme, Zustands-/Ereignismatrizen, Entscheidungstabellen usw. Viele davon sind jedoch Variationen von Strukturdiagrammen zur Analyse von Anforderungen an Informationssysteme. Darüber hinaus basieren bekannte Methoden zur Analyse und zum Entwurf von ICs (insbesondere die Methoden von Hutley und War da Mellor) auf den aufgeführten Methoden zur Analyse und zum Entwurf von ICs und erweitern diese um entsprechende Diagrammtechniken.

In der Tabelle Abbildung 3 zeigt die Klassifizierung der am häufigsten verwendeten Methoden gemäß den oben genannten Kriterien (Daten zur Häufigkeit der Verwendung wurden basierend auf einer Analyse der Informationen zu 127 CASE-Paketen ermittelt).

Wie bereits erwähnt, liegt der bedeutendste Unterschied zwischen den Arten der Strukturanalyse in den Methoden und Werkzeugen der funktionalen Modellierung. Unter diesem Gesichtspunkt lassen sich alle Arten der strukturellen Systemanalyse in zwei Gruppen einteilen: diejenigen, die DFD-Methoden und -Technologie (in verschiedenen Notationen) verwenden, und diejenigen, die die SADT-Methodik verwenden. Nach Angaben des maßgeblichsten Forschungsunternehmens in diesem Bereich, der CASE Consulting Group, beträgt das Verhältnis der Verwendung dieser beiden Arten der Strukturanalyse in der Praxis 90 % für DFD und 10 % für SADT.

Tisch 3

Vorwegnehmen vergleichende Analyse von DFD- und SADT-Ansätzen Betrachten Sie als Beispiel die oberste Ebene des Anforderungsmodells an ein Management-Automatisierungssystem für ein Unternehmen, das an der auftragsgemäßen Warenverteilung beteiligt ist (Abb. 21 bzw. Abb. 22). Bestellungen unterliegen der Eingangskontrolle und -sortierung. Sollte die Bestellung nicht dem Sortiment entsprechen oder fehlerhaft ausgeführt werden, wird sie mit entsprechender Mitteilung an den Kunden storniert. Sofern die Bestellung nicht storniert wird, wird ermittelt, ob das entsprechende Produkt vorrätig ist. Bei positiver Antwort wird eine Rechnung zur Zahlung ausgestellt und dem Kunden nach Zahlungseingang vorgelegt, die Ware wird an den Kunden versandt. Wenn der Bestellung keine Lagerbestände zur Verfügung gestellt werden, wird eine Anfrage für das Produkt an den Hersteller gesendet. Nachdem die benötigte Ware im Lager des Unternehmens eingetroffen ist, wird die Bestellung gesichert und der oben beschriebene Weg wiederholt sich.

Eine vergleichende Analyse dieser beiden Arten von Methoden wird gemäß durchgeführt die folgenden Parameter:

Angemessenheit der Mittel für das betrachtete Problem;

Konsistenz mit anderen Strukturanalysetools;

Integration mit nachfolgenden Entwicklungsphasen (und vor allem mit der Designphase).

1) Angemessenheit. Die Wahl der einen oder anderen Strukturmethodik hängt direkt vom Themenbereich ab, für den das Modell erstellt wird. In unserem Fall werden die Methoden auf automatisierte Unternehmensmanagementsysteme angewendet und nicht auf Systeme im Allgemeinen, wie in SADT angenommen. Für die betrachteten Probleme ist DFD konkurrenzlos.

Erstens sind SADT-Diagramme viel weniger aussagekräftig und für die Modellierung automatisierter Steuerungssysteme geeignet (vergleiche Abb. 21 und Abb. 22). Daher sind Bögen in SADT streng typisiert (Eingabe, Ausgabe, Steuerung, Mechanismus). Gleichzeitig wird in Bezug auf automatisierte Steuerungssysteme die semantische Unterscheidung zwischen Eingaben und Ausgaben einerseits und Kontrollen und Mechanismen andererseits aufgehoben: Eingaben, Ausgaben, Mechanismen und Kontrollen sind Datenflüsse und/oder oder Kontrolle und die Regeln für ihre Transformation. Die Systemanalyse anhand von Datenflüssen und den sie transformierenden Prozessen ist transparenter und eindeutiger.

Bestimmte Systeme (z. B. Data Warehouses sind Prototypen von Dateien oder Datenbanken, externe Entitäten spiegeln die Interaktion des modellierten Systems mit wider Außenwelt).

Zweitens mangelt es SADT im Allgemeinen an ausdrucksstarken Mitteln zur Modellierung der Merkmale automatisierter Steuerungssysteme. DFDs wurden von Anfang an als Mittel zur Gestaltung von Informationssystemen entwickelt, die den Kern automatisierter Steuerungssysteme bilden und über einen umfangreicheren Satz von Elementen verfügen, die die Besonderheiten und drittens das Vorhandensein von Minispezifikationen von DFD auf niedrigerer Ebene angemessen widerspiegeln Prozesse ermöglichen es, die logische Unvollständigkeit von SADT zu überwinden (nämlich den Bruch des Modells auf einer ausreichend niedrigen Ebene, wenn weitere Details bedeutungslos werden) und eine vollständige funktionale Spezifikation des zu entwickelnden Systems zu erstellen.

2) Konsistenz. Der Hauptvorteil jedes Modells ist die Möglichkeit, es in andere Modelltypen zu integrieren. In diesem Fall sprechen wir von der Konsistenz funktionaler Modelle mit Informations- und Ereignismodellierungswerkzeugen (zeitlich). Die Vereinbarkeit des SADT-Modells mit ERD und/oder STD ist nahezu unmöglich oder trivial. DFD, ERD und STD ergänzen sich wiederum und sind im Wesentlichen konsistente Darstellungen verschiedener Aspekte desselben Modells (siehe Abb. 20). In der Tabelle Abbildung 4 zeigt die Möglichkeit einer solchen Integration für DFD- und SADT-Modelle.

Tabelle 4

Beachten Sie, dass die Integration von DFD-STD durch die Erweiterung des klassischen DFD um spezielle Tools zum Entwerfen von Echtzeitsystemen (Steuerungsprozessen, Threads, Datenspeichern) erfolgt und STD eine Detaillierung des Steuerungsprozesses ist, die über alle Steuerungsthreads hinweg konsistent ist Shops. Die Integration von DFD-ERD erfolgt über ein Objekt, das in SADT fehlt – einen Datenspeicher, dessen Struktur mit ERD beschrieben wird und mit den entsprechenden Flüssen und anderen Speichern auf DFD übereinstimmt.

3) Integration mit nachfolgenden Stufen. Wichtiges Merkmal Methodik – ihre Kompatibilität mit den nachfolgenden Phasen der Anwendung der Analyseergebnisse (und vor allem mit der Entwurfsphase, die unmittelbar auf die Analyse folgt und sich auf ihre Ergebnisse verlässt). DFDs lassen sich leicht in Entwurfsmodelle (Strukturkarten) umwandeln – das sind ähnliche Modelle. Darüber hinaus sind eine Reihe von Algorithmen bekannt, die die DFD-Hierarchie automatisch in Strukturkarten unterschiedlicher Art umwandeln, was einen logischen und reibungslosen Übergang von der Anforderungsanalysephase zum Systemdesign gewährleistet. Andererseits sind formale Methoden zur Umwandlung von SADT-Diagrammen in Lösungen für den Entwurf automatisierter Steuerungssysteme unbekannt.

Dennoch ist zu beachten, dass es sich bei den betrachteten Arten der Strukturanalyse im Wesentlichen um zwei Sprachen mit annähernd gleicher Leistungsfähigkeit zur Vermittlung von Verständnis handelt. Und eines der Hauptauswahlkriterien ist Folgendes: Wie gut spricht der Berater oder Analyst jede dieser Sprachen, wie kompetent kann er seine Gedanken in dieser Sprache ausdrücken?