Lebenszyklus und Entwicklung von Softwaresystemen

Klassische Lebenszyklus-Systeme

Entwicklung

Das Lebenszyklusmodell für die Systementwicklung umfasst eine Reihe von Aktivitäten, die Analysten, Designer und Systembenutzer durchführen, um ein Informationssystem zu entwickeln und zu implementieren. Der Lebenszyklusansatz für die Systementwicklung besteht aus 6 Phasen:

1. Vorstudie

Die Anforderung der Unterstützung durch ein Informationssystem kann mehrere Gründe haben. Unabhängig davon beginnt der Prozess immer mit der Anfrage einer Person.

2. Bestimmung der Systemanforderungen

Der zentrale Aspekt der Systemanalyse ist das Verständnis aller wichtigen Facetten des zu untersuchenden Unternehmens.

3. Systementwurf

Der Entwurf eines Informationssystems erzeugt Details, die festlegen, wie das System die in der Analysephase identifizierten Anforderungen erfüllt. Systemspezialisten bezeichnen den logischen Entwurf oft im Gegensatz zur Softwareentwicklung, die den Entwurf als physisch bezeichnet.

4. Softwareentwicklung

Die Softwareentwicklung kann durch Schreiben von Software oder durch Installation von Programmen von Drittanbietern erfolgen, die auf den Antragsteller zugeschnitten sind. Die Wahl hängt von den Kosten der einzelnen Alternativen, der verfügbaren Zeit und der Verfügbarkeit von Programmierern ab, die die Software schreiben.

In der Regel arbeiten Entwickler in großen Organisationen, die zu einer Gruppe von Fachleuten gehören.

5. Systemtests

Bei Systemtests wird das System experimentell verwendet, um sicherzustellen, dass die Software keine Fehler enthält, d. h., dass sie gemäß den Spezifikationen und in der vom Benutzer erwarteten Weise funktioniert.

Die Eingaben werden als Testdaten für die Verarbeitung eingegeben und anschließend die Ergebnisse überprüft.

6. Implementierung und Evaluierung

Die Implementierung ist der Prozess der Prüfung und Installation neuer Geräte, der Schulung von Benutzern, der Installation der Anwendung und der Erstellung aller Dateien, die zur Verwendung der Daten erforderlich sind. Einmal installiert, werden Anwendungen viele Jahre lang verwendet. Im Laufe der Zeit ändern sich jedoch Benutzer und Organisationen, und auch die Umgebung ändert sich im Laufe der Wochen und Monate.

Daher ist klar, dass Anwendungen gewartet werden müssen. Die Evaluierung eines Systems wird durchgeführt, um Stärken und Schwächen zu identifizieren. Die Evaluierung erfolgt anhand einer der folgenden Eigenschaften:

Betriebliche Evaluierung

Bewertung des Systembetriebs, einschließlich Benutzerfreundlichkeit, Reaktionszeit, Angemessenheit des Informationsformats, Zuverlässigkeit und Nutzungsintensität.

Organisatorische Auswirkungen

Identifizierung und Messung der Auswirkungen auf die Leistung der Organisation in Bereichen wie Finanzen, Wirtschaftlichkeit und Wettbewerbsfähigkeit. Ebenfalls enthalten sind die Auswirkungen auf den externen und internen Informationsfluss.

Bewertung durch Administratoren

Bewertung der Aktivitäten von Managern und Administratoren in der Organisation und der Endbenutzer.

Leistungsentwicklung

Bewertung des Entwicklungsprozesses anhand von Kriterien wie Zeit- und Entwicklungsaufwand im Einklang mit Budgets und Standards sowie anderen Kriterien für das Projektmanagement. Ebenfalls enthalten ist die Bewertung der in der Entwicklung verwendeten Methoden und Werkzeuge.

Prototyping-Modell

Prototypen sind eine vorläufige Ansicht des zu implementierenden zukünftigen Systems.

Das Prototyping eines Informationssystems ist eine wertvolle Technik zur schnellen Erfassung spezifischer Informationen über die Informationsbedürfnisse der Benutzer.

Prototypen sollten früh im Lebenszyklus der Systementwicklung eingesetzt werden, während die Anforderungen ermittelt werden.

Auf diese Weise sucht der Analyst nach den ersten Reaktionen der Benutzer auf den Prototyp und nach Vorschlägen der Benutzer für Änderungen und Verfeinerungen des Systems. Für den Aufbau eines Prototyps müssen potenzielle Innovationen und Details des Systemdesigns überprüft werden, die Teil des ersten Prototyps sein müssen.

Arten von Prototypen

• Patching-Prototyp

  Ein System, das alle vorgeschlagenen Funktionen hat, aber eigentlich ein Basismodell ist, das irgendwann verbessert wird. Diese Art von Prototyp funktioniert, ist aber weder effizient noch elegant.

• Nicht funktionsfähiger Prototyp

  Der zweite Entwurf eines Prototyps besteht aus einem nicht funktionsfähigen Modell zum Zwecke der Prüfung bestimmter Aspekte des Entwurfs. Dies kann der Fall sein, wenn Anwendungen durch die erforderliche Codierung ziemlich umfangreich sind, um den Prototyp zu erstellen, und dennoch kann man nur dann eine nützliche Vorstellung vom System erhalten, wenn man Prototypen der Ein- und Ausgabe entwickelt.

  Sie können nach Benutzerfeedback zu den Schnittstellen (Eingabe und Ausgabe) suchen. Aufgrund der zu hohen Kosten und des Zeitaufwands konnte dies nicht durchgeführt werden. Sie können jedoch einige der Dienstprogramme prototypisieren, auf denen das System basiert, indem Sie Ein- und Ausgabe verwenden.

• Erster Prototyp einer Serie

  Ein drittes Prototyping-Konzept beinhaltet die Erstellung eines ersten vollständigen Modells eines Systems, auch Pilot genannt.

  Diese Art von Prototyp ist nützlich, wenn viele Installationen desselben Systems geplant sind. Das funktionale oder vollständige Modell ermöglicht eine realistische Interaktion mit dem neuen System, minimiert aber die Kosten für die Behebung aller vorhandenen Probleme.

• Prototyp mit ausgewählten Funktionen

  Ein Prototyp mit ausgewählten Funktionen ermöglicht die Einführung des Systems, während andere Funktionen zu einem späteren Zeitpunkt hinzugefügt werden können.

  Dies bezieht sich auf den Aufbau eines Betriebsmodells, das nicht alle, sondern einige der Funktionen enthält, die das endgültige System haben wird.

  Beim Aufbau dieser Art von Prototyp ist das System modular aufgebaut, so dass, wenn die Bewertung der Funktionen zufriedenstellend ist, die Schnittstellen ohne großen Aufwand in das viel größere endgültige System integriert werden können. Die in diesem Teil des aktuellen Systems erstellten Prototypen sind nicht nur ein Modell.

Entwicklung eines Prototyps

Bei der Entscheidung, ob die Systementwicklung Prototyping als Teil des Entwicklungslebenszyklus umfassen soll, muss der Analyst die Bedürfnisse ermitteln, welche Art von Problem vorliegt und wie das System die Lösung bieten soll.

Richtlinien für die Entwicklung eines Prototyps

1. Arbeiten mit überschaubaren Modulen

Es ist gut, dass der Analyst es als nützlich erachtet, beim Aufbau des Prototyps des Modells einige der Merkmale eines Systems zu modellieren, um ein funktionales zu erhalten. Ein für praktische Zwecke geeignetes Modell ist eines, das die Interaktion mit seinen wichtigsten Funktionen ermöglicht, aber dennoch können die Systemmodule getrennt von anderen aufgebaut werden. Die Module, die als weniger wichtig erachtet werden, werden absichtlich aus dem ersten Prototyp weggelassen.

2. Schnelle Prototypenerstellung

Geschwindigkeit ist entscheidend für die erfolgreiche Entwicklung eines Prototyps. Der Prototyp trägt dazu bei, die Zeit für die Interaktion zwischen Benutzer und System zu verkürzen, so dass mit dem Experimentieren begonnen werden kann.

Traditionelle Datenerfassungstechniken wie Interviews, Beobachtungen und wissenschaftliche Daten werden verwendet.

Die Entwicklung eines Prototyps sollte innerhalb einer Woche erfolgen. Für die schnelle Erstellung eines Prototyps müssen spezielle Tools wie Systemverwaltungs- und Datenbanksoftware verwendet werden, die die Verwendung vorhandener Ein- und Ausgaben ermöglichen.

In dieser Phase des Lebenszyklus sammeln Systemanalysten weiterhin Informationen darüber, was die Benutzer brauchen und wollen.

Die schnelle Erstellung eines funktionsfähigen Prototyps in den frühen Phasen des Lebenszyklus der Systementwicklung ermöglicht hilfreiche Anmerkungen dazu, wie der Rest des Projekts durchgeführt werden sollte. So sehen die Benutzer, wie die Teile des Systems funktionieren.

3. Prototypänderungen

Eine dritte Richtlinie für die Prototypenentwicklung ist die flexible Gestaltung von Änderungen für die Zukunft. Dies bedeutet, dass Module erstellt werden, die nicht sehr voneinander abhängig sind.

Im Allgemeinen wird der Prototyp durch mehrere Iterationen modifiziert. Die Änderungen am Prototyp sollten ein wichtiger Schritt sein, um das System dem anzunähern, was die Kunden sagen. Jede Änderung erfordert eine weitere Bewertung durch die Benutzer. Diese Änderungen sollten schnell innerhalb von zwei oder einem Tag erfolgen, abhängig davon, wie schnell die Benutzer die Bewertung vornehmen.

4. Betonung der Benutzeroberfläche

Die Benutzeroberfläche des Prototyps (und schließlich des Systems) ist sehr wichtig, da das Prototyping wirklich versucht, den Benutzern zu ermöglichen, ihre wachsenden Anforderungen anzuzeigen. Die Informationen sollten leicht geschichtet sein, um mit dem Prototyp des Systems zu interagieren.

Der Analyst hat das Ziel, eine Schnittstelle zu entwerfen, die Funktionen darstellt, die es dem Benutzer ermöglichen, mit minimalem Schulungsaufwand mit dem System zu interagieren und maximale Kontrolle über das System zu haben.

Nachteile des Prototypings

Es ist schwierig, die Systementwicklung mit Prototypen als Projekt im Rahmen einer größeren Initiative zu verwalten. Benutzer und Analysten können einen Prototyp mit einem fertigen System verwechseln, wenn dies unangemessen ist.

Vorteile des Prototypings

Es besteht die Möglichkeit, Änderungen am System in den frühen Phasen der Entwicklung vorzunehmen. Es besteht die Möglichkeit, die Entwicklung eines Systems zu stoppen, das nicht funktionsfähig ist. Es kann Bedürfnisse und Erwartungen genauer erfassen.

Das RAD-Modell

• Rapid Application Development (RAD) ist ein lineares sequentielles Softwareentwicklungsprozessmodell, das eine sehr kurze Entwicklungszeit betont.
• Dies ist ein komponentenbasierter Entwicklungsansatz.
• RAD umfasst die folgenden Schritte:

Managementmodell

Der Informationsfluss zwischen den Geschäftsfunktionen wird so modelliert, dass die folgenden Fragen beantwortet werden:

• Welche Informationen steuern die Geschäftsprozesse?
• Welche Informationen werden erzeugt?
• Wer erzeugt sie?
• Wo befinden sich die Informationen?
• Wer verarbeitet sie?

Datenmodellierung

Der in der Phase des Informationsflusses definierte Informationsfluss wird verfeinert, um die Datenobjekte zu identifizieren, die zur Unterstützung des Geschäfts erforderlich sind. Die Eigenschaften (Attribute genannt) jedes Objekts und die Beziehungen zwischen diesen Objekten werden definiert.

Prozessmodellierung

Die in der Datenmodellierungsphase definierten Datenobjekte werden transformiert, um den Informationsfluss zu erzeugen, der für die Implementierung einer Geschäftsfunktion erforderlich ist. Prozessbeschreibungen für das Hinzufügen, Bearbeiten, Löschen oder Abrufen eines Datenobjekts werden erstellt.

Anwendungsgenerierung

RAD setzt den Einsatz von Techniken der vierten Generation voraus. Anstatt Software mit Programmiersprachen der dritten Generation zu programmieren, verwendet der RAD-Prozess bestehende Programmierkomponenten wieder (wenn möglich) oder erstellt wiederverwendbare Komponenten (wenn nötig). In allen Fällen werden automatisierte Tools verwendet, um die Softwareerstellung zu erleichtern.

Test und Auslieferung

Da der RAD-Prozess die Wiederverwendung betont, wurden viele der Programmkomponenten bereits getestet. Dies reduziert die Testzeit. Alle neuen Komponenten müssen jedoch getestet werden, und alle Schnittstellen müssen gründlich getestet werden.

• RAD zerlegt das System in Komponenten. Jede von ihnen kann von einem anderen Team entwickelt werden. Für eine spätere Anwendung endgültig integriert.

Evolutionäre Softwareentwicklungsmodelle

• Software entwickelt sich wie alle komplexen Systeme im Laufe der Zeit.
• Evolutionäre Modelle sind iterativ.
• Sie zeichnen sich dadurch aus, dass Softwareentwickler zunehmend vollständige Versionen der Software erstellen.

Inkrementelles Modell

• Das inkrementelle Modell kombiniert Elemente des linearen sequenziellen Modells (wiederholt angewendet) mit der iterativen Philosophie des Prototypings.
• Jede lineare Sequenz erzeugt ein "Inkrement" der Software.
• Bei der Verwendung eines inkrementellen Modells ist das erste Inkrement oft ein Kernprodukt. Das heißt, es werden grundlegende Anforderungen erfüllt, aber viele zusätzliche Funktionen (von denen einige bekannt sind, andere nicht) bleiben weg.
• Dieser Prozess wird nach der Auslieferung jedes Inkrements wiederholt, bis das komplette Produkt entwickelt ist.
• Im Gegensatz zum Prototyping konzentriert sich das inkrementelle Modell auf die Bereitstellung eines funktionsfähigen Produkts mit jedem Inkrement.
• Frühe Inkremente sind "eingeschränkte" Versionen des Endprodukts, bieten aber den Benutzern eine Funktionalität und dienen auch als Plattform für die Benutzerbewertung.

Assembly-Modell

• Das Assembly-Modell vereint viele der Merkmale des Spiralmodells.
• Es ist evolutionär und erfordert einen iterativen Ansatz für die Softwareerstellung.
• Das Komponentenmodell basiert jedoch auf der Zusammensetzung vorgefertigter Softwarekomponenten (manchmal auch Klassen genannt).
• Beginnt mit der Identifizierung von Klassenkandidaten.
• Die zu verarbeitenden Daten und der für die Verarbeitung verwendete Algorithmus werden untersucht.
• Nachdem die Daten in einer Klasse gekapselt wurden.
• Klassen (Komponenten) werden erstellt und in der Klassenbibliothek gespeichert.
• Identifizierte Klassenkandidaten prüfen die Klassenbibliothek, um festzustellen, ob diese Klassen bereits existieren.
• Studie zur Wiederverwendung:
• Es wird berichtet, dass die Komponentenmontage zu einer Reduzierung der Entwicklungszeit um 70 % führt.
• 84 % der Projektkosten.
• Ein Produktivitätsindex von 26,2 %.
• Im Vergleich zum Industriestandard von 16,9 %.
• Es besteht kein Zweifel, dass die Komponentenmontage Softwareentwicklern erhebliche Vorteile bietet.
• Gleichzeitiges Entwicklungsmodell
• Das gleichzeitige Entwicklungsmodell, manchmal auch Concurrent Engineering genannt.
• Es basiert auf dem Prinzip, dass viele der Softwareentwicklungsphasen gleichzeitig durchgeführt werden können.
• Die Idee des Concurrent Modells ist es, diesen Prozess zu modellieren.
• Versuchen Sie, diesen Prozess grob als eine Reihe von Hauptaktivitäten, Aufgaben und damit verbundenen Zuständen zu modellieren.

INKREMENTELLES MODELL

Es ist in 4 Teile unterteilt: Analyse, Design, Code und Test. Es ist ein generischer Ansatz für den Prozess. Bei der Softwareerstellung wird jedoch das Prinzip der Linienarbeit und -programmierung in vielen anderen Formen verwendet. Dieser Kunde wird in ständigem Kontakt mit den Ergebnissen jedes Inkrements gehalten. Es ist derselbe Kunde, der auch die Bedürfnisse oder verworfenen Konzepte am Ende jedes Inkrements beibehält, so dass die Software tatsächlich besser für seine Bedürfnisse geeignet ist. Der Prozess wird wiederholt, bis das komplette Produkt entwickelt ist.

Dadurch wird die Entwicklungszeit erheblich verkürzt.

Wie bei anderen iterativen Modellierungsmethoden unterscheidet sich das inkrementelle Modell dadurch, dass jedes Inkrement ein voll funktionsfähiges Produkt liefert.

Das inkrementelle Modell ist besonders nützlich, wenn nicht genügend Personal zur Verfügung steht. Die ersten Inkremente können von einem kleinen Team durchgeführt werden, und jedes Inkrement kann bei Bedarf Personal hinzufügen. Auf der anderen Seite können die technischen Risiken der geplanten Inkremente kontrolliert werden.

Merkmale

• Vermeidet große Projekte und liefert den Benutzern "etwas Wertvolles" mit einer gewissen Häufigkeit.
• Der Benutzer ist stärker involviert.
• Schwierige Bewertung der Gesamtkosten.
• Schwierig auf Transaktionssysteme im Allgemeinen anzuwenden, die tendenziell integriert sind und als Einheit funktionieren.
• Erfordert erfahrene Manager.
• Fehler in den Anforderungen werden zu spät erkannt.
• Das Ergebnis kann sehr positiv sein.

Vorteile

• Mit einem inkrementellen Paradigma wird die anfängliche Entwicklungszeit reduziert, da die Funktionalität schrittweise implementiert wird.
• Es wirkt sich auch positiv auf den Kunden aus, da die Software durch die frühzeitige Bereitstellung von funktionsfähigen Teilen bereitgestellt wird.
• Das Modell bietet alle Vorteile des Wasserfallmodells, indem es dessen Nachteile nur in jedem Abschnitt reduziert.
• Ermöglicht es dem Kunden, im Vergleich zum Wasserfallmodell schneller ein Produkt zu liefern.
• Änderungen sind einfacher zu berücksichtigen, da der Umfang der Inkremente begrenzt ist.
• Die Vielseitigkeit erfordert eine sorgfältige Planung sowohl auf administrativer als auch auf technischer Ebene.

Nachteile

• Das inkrementelle Modell wird nicht für Echtzeitsysteme empfohlen, die ein hohes Maß an Sicherheit, verteilte Verarbeitung und/oder einen hohen Risikoindex aufweisen.
• Erfordert viel Planung, sowohl administrativ als auch technisch.
• Benötigt klare Ziele für den Projektstatus.

Spiralmodell

Das Spiralmodell für Softwareentwicklung wurde entwickelt, um die besten Eigenschaften des klassischen Lebenszyklus und des Prototypings zu kombinieren und gleichzeitig ein neues Element der Risikoanalyse hinzuzufügen.

Die Prozesse innerhalb eines Spiralmodells sind:

Kundenkommunikation: Arbeiten zur Straffung der Interaktion zwischen Entwickler und Kunde.

Planung: Definition von Ressourcen, Zeit und anderen projektrelevanten Informationen.

Risikoanalyse: Bewertung technischer und Managementrisiken.

Engineering: Erstellung einer oder mehrerer Darstellungen der Anwendung.

Erstellung und Anpassung: Aufgaben zum Erstellen, Testen und Installieren der Anwendung.

Kundenbewertung: Kundenreaktion auf die aus der Engineering-Phase resultierende Anwendungskonstruktion.

Zyklen

• Entwicklung von Konzepten
• Entwicklung neuer Produkte
• Verbesserung neuer Produkte
• Produktwartung

In der ersten Runde werden Ziele, Alternativen und Einschränkungen analysiert und Risiken bewertet.

Der Kunde bewertet die technischen Arbeiten (Kundenbewertungsquadrant) und schlägt Änderungen vor. Basierend auf dem Kundenfeedback erfolgt die nächste Phase der Planung und Risikoanalyse. Bei jeder Schleife um die Spirale führt der Abschluss der Risikoanalyse zu einer "Go/No-Go"-Entscheidung.

Mit jeder Iteration um die Spirale (beginnend in der Mitte und nach außen wandernd) werden aufeinanderfolgende Versionen der Software erstellt, die immer umfassender werden und schließlich das Betriebssystem selbst bilden.

Merkmale

• Es ist ein evolutionäres Modell, das das klassische Modell mit dem Prototyping kombiniert.
• Beinhaltet eine Risikoanalysephase.
• Es ist ideal für die Erstellung verbesserter Produkte mit verschiedenen Versionen, wie es bei modernen Mikrocomputern der Fall ist.
• Das Engineering kann durch Prototyping oder den klassischen Lebenszyklus weiterentwickelt werden.
• Dies ist der realistischste Ansatz, der heute verfügbar ist.

Vorteile

• Reduziert das Projektrisiko
• Fördert Qualitätsziele
• Integriert Entwicklung, Wartung usw.

Nachteile

• Erzeugt eine lange Entwicklungszeit
• Teures Modell
• Erfordert Erfahrung in der Risikoidentifizierung

Gleichzeitiges Entwicklungsmodell

Das Concurrent Development Model, auch bekannt als Concurrent Engineering, kann grob als eine Reihe von Hauptaktivitäten, Aufgaben und damit verbundenen Zuständen dargestellt werden.

Dieses Modell wird häufig als Paradigma für die Client/Server-Entwicklung verwendet. Es bietet eine Meta-Beschreibung des Softwareprozesses. Das Concurrent Model ist in der Lage, die verschiedenen Aktivitäten zu beschreiben, die gleichzeitig bei der Softwareentwicklung stattfinden.

Die meisten Softwareentwicklungsprozessmodelle werden von der Zeit gesteuert, d. h. spätere Entwicklungen im Prozess basieren auf früheren. Ein Concurrent Process Model wird durch Benutzerbedürfnisse, Managemententscheidungen und Designergebnisse gesteuert. Das Concurrent Process Model definiert eine Reihe von Ereignissen, die Übergänge von Zustand zu Zustand für jede der Softwareentwicklungsaktivitäten auslösen. In den frühen Phasen des Entwurfs wird eine Inkonsistenz der Analyse nicht als Modell betrachtet. Dieses Modell erzeugt das richtige Analyseereignis, das den Zustand der Analyseaktivität von "Änderungen ausstehend" in "Bereit" auslöst.

Dieses Modell erzeugt das richtige Analyseereignis, das den Zustand der Analyseaktivität von "Änderungen ausstehend" in "Bereit" auslöst. Es ist eine Art Netzwerkmodell, bei dem alle Personen gleichzeitig oder gleichzeitig arbeiten.

Ein Client/Server-System besteht aus einer Reihe von Funktionskomponenten. Bei Anwendung auf Client/Server definiert das Concurrent Process Model die Aktivitäten in zwei Dimensionen:

• Systemgröße
• Komponentenabmessung

Es gibt drei Phasen: Entwurf, Montage und Verwendung, die Aspekte auf Systemebene sind. Tatsächlich ist das Concurrent Process Model für alle Arten der Softwareentwicklung geeignet und bietet einen genauen Überblick über den Projektstatus.

Parallelität wird auf zwei Arten erreicht:

1. Systemaktivitäten und Komponentenaktivitäten können gleichzeitig stattfinden und mit einem objektorientierten Ansatz modelliert werden.
2. Eine Client/Server-Anwendung wird typischerweise gleichzeitig mit vielen Komponenten implementiert, die jeweils entworfen und realisiert werden können.

Vorteile

• Hervorragend geeignet für Projekte mit separaten Arbeitsgruppen.
• Bietet ein genaues Bild vom Projektstatus.

Nachteile

• Wenn die oben genannten Bedingungen nicht zutreffen.
• Wenn es keine Arbeitsgruppen gibt, kann diese Methode nicht funktionieren.

Einheitliches Modell

Einführung

UML entstand in den 1990er Jahren aus dem Wunsch heraus, die Modellierungssprachen der 1980er Jahre zu vereinheitlichen, einer Zeit des Wachstums und des "Methodenkriegs" der 1970er Jahre. Obwohl UML hauptsächlich von mehreren objektorientierten Methoden der zweiten Generation (Notationsebene) beeinflusst wurde, ist UML mehr als nur eine objektorientierte Modellierungssprache der dritten Generation. Ihr Anwendungsbereich geht über den ihrer Vorgänger hinaus. Und es ist die Erfahrung, das Experimentieren und die schrittweise Einführung des Standards, die das wahre Potenzial offenbaren, Organisationen in die Lage zu versetzen, ihre Gewinne zu realisieren.

UML

Es ist eine Modellierungssprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation der Artefakte eines systemintensiven Prozesses.

Unter systemintensivem Prozess versteht man die Entwicklung einer Anwendung oder eines Systems.

Als Sprache wird sie zur Kommunikation verwendet. Das heißt, es ist eine Möglichkeit, Wissen über ein Thema zu erfassen, dieses Wissen auszudrücken (Semantik) und das Wissen zu bewahren (Syntax), wobei der Zweck der Kommunikation im Vordergrund steht. Das Thema ist das zu untersuchende System.

Als Modellierungssprache konzentriert sie sich auf das Verständnis eines Themas durch die Formulierung eines Modells des Themas (und seines jeweiligen Kontexts). Das Modell umfasst das Wissen über das Thema, und die angemessene Anwendung dieses Wissens ist Intelligenz.

Als vereinheitlichende Sprache integriert sie die besten Praktiken der Branchen für Engineering-Technologie und Informationssysteme in allen Arten von Systemen (Software und Nicht-Software), Domänen (Geschäft im Vergleich zu Software) und Lebenszyklusprozessen.

Als Sprache zur Spezifikation kann sie verwendet werden, um zu kommunizieren, "was" von einem System benötigt wird und "wie" ein System sein kann.

Als Sprache zur Visualisierung kann sie verwendet werden, um ein System visuell zu beschreiben, bevor es erstellt wird.

Als Sprache zur Konstruktion kann sie verwendet werden, um die Implementierung eines Systems ähnlich einer "Blaupause" zu steuern.

Als Sprache zur Dokumentation kann sie verwendet werden, um das Wissen über ein System während seines gesamten Lebenszyklus zu erfassen.

UML ist nicht:

• Eine visuelle Programmiersprache, sondern eine visuelle Modellierungssprache
• Ein Werkzeug oder eine Speicherungsspezifikation, sondern eine Modellierungsspezifikationssprache
• Ein Prozess, sondern prozessfähig

Im Wesentlichen befasst sich UML mit der Erfassung, Kommunikation und dem Niveau (Zerlegung in Ebenen) von Wissen.

UML-Dienstprogramm

UML ist eine universelle, weit verbreitete, werkzeuggestützte und industriell standardisierte Modellierungssprache. Sie ist auf eine Vielzahl von Systemtypen, Domänen und Methoden oder Verfahren anwendbar.

Als universelle Sprache konzentriert sie sich auf den Kern von Konzepten zur Erfassung, Weitergabe und Anwendung von Wissen, gekoppelt mit Mechanismen zur Erweiterung.

Als Modellierungssprache für breite Anwendbarkeit kann sie auf verschiedene Systemtypen (Software und Nicht-Software), Domänen (Geschäft im Vergleich zu Software) und Methoden oder Verfahren angewendet werden.

Als werkzeuggestützte Modellierungssprache gibt es Werkzeuge für Systeme zur Unterstützung der Implementierung der Sprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation.

Als industriell standardisierte Modellierungssprache ist die Sprache kein geschlossenes Eigentum von jemandem, sondern eine offene und erweiterbare Sprache, die von der gesamten Branche vollständig anerkannt wird.

UML ermöglicht die Erfassung, Kommunikation und das Niveau von Wissen auf strategischer, taktischer und operativer Ebene, um die Wertsteigerung, die Qualitätsverbesserung, die Kostenreduzierung und die Verkürzung der Markteinführungszeit zu erleichtern, das Risikomanagement zu verbessern und die potenzielle Zunahme von Komplexität und Wandel proaktiv zu bewältigen.

Assembly-Modell und formale Methoden

Das komponentenbasierte Entwicklungsmodell enthält viele der Merkmale des Spiralmodells. Es ist evolutionär und erfordert einen iterativen Ansatz für die Softwareerstellung. Das komponentenbasierte Entwicklungsmodell basiert jedoch auf der Zusammensetzung von Anwendungen aus vorgefertigten Softwarekomponenten (Klassen).

Dies liegt daran, dass objektorientierte Klassen, wenn sie richtig entworfen und implementiert werden, in verschiedenen Anwendungen und Architekturen computerbasierter Systeme wiederverwendbar sind.

Zunächst werden die Klassenkandidaten identifiziert, indem die zu verarbeitenden Daten, der von der Anwendung verwendete Algorithmus und die zu erstellende Behandlung untersucht werden. Wenn diese Klassen in früheren Programmen erstellt wurden, werden sie in einem Repository oder einer Klassenbibliothek gespeichert. Als Nächstes wird ermittelt, welche von ihnen bereits vorhanden sind, um sie wiederzuverwenden.

Das komponentenbasierte Entwicklungsmodell fördert die Wiederverwendung und Wiederverwertung von Software und bietet Softwareentwicklern Vorteile. In einer Studie zur Wiederverwendung berichtet QSM Associates, Inc., dass die Komponentenmontage zu einer Reduzierung der Entwicklungszeit um 70 %, der Projektkosten um 84 % und einem Produktivitätsindex von 26,2 führt. Es besteht kein Zweifel, dass die Komponentenmontage Softwareentwicklern erhebliche Vorteile bietet.

Vorteile

Dieses Paradigma hat einige Vorteile:

1. Software-Wiederverwendung
2. Vereinfachung von Tests
3. Vereinfachte Systemwartung
4. Höhere Qualität

• Komponentennotation
• Komponentendiagramm
• Schnittstellen
• Komponenten und Knoten (Deployment-Diagramm)
• Einschränkungen
• Risikoanalyse
  • Vorteile und Nachteile

Fazit

Dieses neue Systemmodell basiert auf der Erstellung eines Systems nach dem anderen, wobei jedes System eine Bibliothek von Komponenten (Klassen/Objekte) enthält. Wenn ein System erstellt werden soll, besteht der Prozess darin, die Objekte im System zu definieren, die Objekte in der Bibliothek zu suchen, die nicht vorhandenen Objekte zu erstellen, sie in die Bibliothek aufzunehmen, die Objekte zusammenzusetzen und die Methoden zu testen. Auf der Grundlage der Kundenbewertung wird das System iterativ durch eine Planungs-, Risikoanalyse-, Engineering-, Erstellungs- und Anpassungsphase weiterentwickelt, wobei diese Schritte so oft wiederholt werden, dass die ersten Iterationen Konzepte entwickeln, die nächsten neue Komponenten entwickeln, die nächsten versuchen, sie zu verbessern, und die letzten schließlich die Wartung durchführen.