Der Prozess der Erstellung komplexer Softwareanwendungen ist heute ohne die Unterteilung in Lebenszyklusphasen nicht mehr vorstellbar. Unter dem Lebenszyklus eines Programms verstehen wir eine Reihe von Phasen:

• Analyse des Themengebiets und Erstellung technischer Spezifikationen (Interaktion mit dem Kunden)
• Gestaltung der Programmstruktur
• Codierung (Satz von Programmcode gemäß Projektdokumentation)
• Testen und Debuggen
• Umsetzung des Programms
• Programmunterstützung
• Entsorgung

Schauen wir uns den Designprozess genauer an. Während des Designprozesses erstellt ein Architekt oder ein erfahrener Programmierer eine Designdokumentation, einschließlich Textbeschreibungen, Diagrammen und Modellen des zukünftigen Programms. Die UML-Sprache wird uns bei dieser schwierigen Aufgabe helfen.

UML ist eine grafische Sprache zur Visualisierung, Beschreibung von Parametern, Design und Dokumentation verschiedener Systeme (insbesondere Programme). Diagramme werden mit speziellen CASE-Tools wie Rational Rose (http://www-01.ibm.com/software/rational/) und Enterprise Architect (http://www.sparxsystems.com.au/) erstellt. Basierend auf UML-Technologie, einem einheitlichen Informationsmodell. Die oben genannten CASE-Tools sind in der Lage, Code in verschiedenen objektorientierten Sprachen zu generieren und verfügen außerdem über sehr viele nützliche Funktion Reverse Engineering. (Reverse Engineering ermöglicht es Ihnen, ein grafisches Modell aus vorhandenem Programmcode und Kommentaren dazu zu erstellen.)

Schauen wir uns die Arten von Diagrammen zur Visualisierung des Modells an (dies ist ein Muss, obwohl es noch viel mehr Arten gibt):

Anwendungsfalldiagramm

Das entworfene System wird als eine Reihe von Entitäten oder Akteuren dargestellt, die mithilfe sogenannter Präzedenzfälle mit dem System interagieren. In diesem Fall ist ein Akteur oder Akteur jede Entität, die von außen mit dem System interagiert. Mit anderen Worten: Jeder Anwendungsfall definiert eine bestimmte Reihe von Aktionen, die das System während eines Dialogs mit dem Akteur ausführt. Allerdings wird nichts darüber gesagt, wie die Interaktion der Akteure mit dem System umgesetzt wird.

Klassen Diagramm

Ein Klassendiagramm dient der Darstellung der statischen Struktur eines Systemmodells in der Terminologie objektorientierter Programmierklassen. Ein Klassendiagramm kann insbesondere die verschiedenen Beziehungen zwischen einzelnen Domänenentitäten wie Objekten und Subsystemen widerspiegeln und auch deren interne Struktur (Felder, Methoden...) und Beziehungsarten (Vererbung, Implementierung von Schnittstellen...) beschreiben. ). Dieses Diagramm liefert keine Informationen über die zeitlichen Aspekte des Systembetriebs. Unter diesem Gesichtspunkt ist das Klassendiagramm eine Weiterentwicklung des konzeptionellen Modells des entworfenen Systems. In dieser Phase sind Kenntnisse des OOP-Ansatzes und der Entwurfsmuster unerlässlich.

Zustandsdiagramm

Der Hauptzweck dieses Diagramms besteht darin, mögliche Abfolgen von Zuständen und Übergängen zu beschreiben, die zusammen das Verhalten eines Modellelements während seines Lebenszyklus charakterisieren. Ein Zustandsdiagramm stellt das dynamische Verhalten von Entitäten dar, basierend auf der Spezifikation ihrer Reaktion auf die Wahrnehmung bestimmter Ereignisse.

Sequenzdiagramm

Um die Interaktion von Objekten in der UML-Sprache zu modellieren, werden entsprechende Interaktionsdiagramme verwendet. Die Interaktionen von Objekten können zeitlich betrachtet werden, und dann wird ein Sequenzdiagramm verwendet, um den Zeitpunkt der Übertragung und des Empfangs von Nachrichten zwischen Objekten darzustellen. Interagierende Objekte tauschen einige Informationen miteinander aus. In diesem Fall handelt es sich bei den Informationen um abgeschlossene Nachrichten. Mit anderen Worten: Obwohl die Nachricht einen Informationsgehalt hat, erhält sie zusätzlich die Eigenschaft, eine gezielte Wirkung auf den Empfänger auszuüben.

Kollaborationsdiagramm

Im Kooperationsdiagramm werden die an der Interaktion beteiligten Objekte in Form von Rechtecken dargestellt, die den Namen des Objekts, seine Klasse und ggf. Attributwerte enthalten. Wie bei einem Klassendiagramm werden Assoziationen zwischen Objekten in Form verschiedener Verbindungslinien angezeigt. In diesem Fall können Sie die Namen der Assoziation und die Rollen, die Objekte in dieser Assoziation spielen, explizit angeben.
Im Gegensatz zu einem Sequenzdiagramm stellt ein Kooperationsdiagramm nur die Beziehungen zwischen Objekten dar, die bestimmte Rollen in der Interaktion spielen.

Komponentendiagramm

Ein Komponentendiagramm beschreibt im Gegensatz zu den zuvor besprochenen Diagrammen die Merkmale der physischen Darstellung des Systems. Mit einem Komponentendiagramm können Sie die Architektur des zu entwickelnden Systems definieren, indem Sie Abhängigkeiten zwischen Softwarekomponenten festlegen, bei denen es sich um Quell-, Binär- und ausführbaren Code handeln kann. In vielen Entwicklungsumgebungen entspricht ein Modul oder eine Komponente einer Datei. Die gepunkteten Pfeile, die Module verbinden, zeigen gegenseitige Abhängigkeitsbeziehungen an, die denen ähneln, die beim Kompilieren von Programmquellcode auftreten. Die wichtigsten grafischen Elemente eines Komponentendiagramms sind Komponenten, Schnittstellen und Abhängigkeiten zwischen ihnen.

Bereitstellungsdiagramm

Das Bereitstellungsdiagramm soll die Elemente und Komponenten eines Programms visualisieren, die nur zur Laufzeit vorhanden sind. In diesem Fall werden nur Programminstanzkomponenten dargestellt, bei denen es sich um ausführbare Dateien oder dynamische Bibliotheken handelt. Die Komponenten, die zur Laufzeit nicht verwendet werden, werden im Bereitstellungsdiagramm nicht angezeigt.
Das Bereitstellungsdiagramm enthält grafische Bilder Prozessoren, Geräte, Prozesse und Verbindungen zwischen ihnen. Im Gegensatz zu logischen Darstellungsdiagrammen ist ein Bereitstellungsdiagramm für das gesamte System einheitlich, da es die Merkmale seiner Implementierung vollständig widerspiegeln muss. Dieses Diagramm vervollständigt im Wesentlichen den OOAP-Prozess für eine bestimmte Person Software System und seine Entwicklung ist normalerweise die letzte Stufe der Modellspezifikation.

Damit ist unser Überblick über Diagramme im Besonderen und Design im Allgemeinen abgeschlossen. Es ist erwähnenswert, dass der Designprozess längst zum Standard für die Softwareentwicklung geworden ist, aber oft muss man es mit einem hervorragend geschriebenen Programm zu tun haben, das aufgrund des Fehlens einer normalen Dokumentation mit unnötigen Nebenfunktionen überwuchert wird, Krücken macht und umständlich wird und verliert seine frühere Qualität. =(

Ich bin davon überzeugt, dass ein Programmierer in erster Linie ein Programmierer ist – er sollte NICHT mit dem Kunden kommunizieren, NICHT über die Architektur des Systems nachdenken, keine Schnittstelle zum Programm erfinden, er sollte nur programmieren – Algorithmen, Funktionalität implementieren, Aussehen, Benutzerfreundlichkeit, mehr aber auch nicht... Der Designer muss, angefangen bei abstrakten Diagrammen (die den Themenbereich beschreiben) bis hin zu Diagrammen, die die Struktur von Daten, Klassen und Prozessen ihrer Interaktion darstellen, Schritt für Schritt alles im Detail beschreiben. Das heißt, die Komplexität der Arbeit und das Gehalt eines Designers sollten um eine Größenordnung höher sein als die eines Programmierers == Coders. Entschuldigung für die Aufruhr....

Die Entwicklung von Softwareprodukten kennt viele wertvolle Methoden – mit anderen Worten: etablierte Best Practices. Die Wahl hängt von den Besonderheiten des Projekts, dem Budgetierungssystem, subjektiven Vorlieben und sogar dem Temperament des Managers ab. Der Artikel beschreibt Methoden, die uns bei Edison regelmäßig begegnen.

1. „Wasserfallmodell“ (Kaskadenmodell oder „Wasserfall“)

Eine der ältesten umfasst das aufeinanderfolgende Durchlaufen von Phasen, von denen jede vollständig abgeschlossen sein muss, bevor die nächste beginnt. Das Wasserfallmodell erleichtert die Verwaltung eines Projekts. Dank seiner Starrheit schreitet die Entwicklung schnell voran, Kosten und Termin sind vorgegeben. Aber das ist ein zweischneidiges Schwert. Das Wasserfallmodell liefert nur bei Projekten mit klaren und vordefinierten Anforderungen und Möglichkeiten zu deren Umsetzung hervorragende Ergebnisse. Es gibt keine Möglichkeit, einen Schritt zurückzutreten; das Testen beginnt erst, wenn die Entwicklung abgeschlossen oder fast abgeschlossen ist. Produkte, die nach diesem Modell ohne begründete Wahl entwickelt wurden, können Mängel aufweisen (der Anforderungskatalog kann zu keinem Zeitpunkt angepasst werden), die aufgrund der strengen Abfolge der Maßnahmen erst am Ende bekannt werden. Die Kosten für die Durchführung von Änderungen sind hoch, da mit der Initiierung gewartet werden muss, bis das gesamte Projekt abgeschlossen ist. Allerdings überwiegen die Fixkosten oft die Nachteile des Ansatzes. Die Behebung von während des Erstellungsprozesses festgestellten Mängeln ist möglich und erfordert unserer Erfahrung nach ein bis drei zusätzliche Vereinbarungen zum Vertrag mit einer kleinen technischen Spezifikation.

Mithilfe des Wasserfallmodells haben wir viele Projekte von Grund auf erstellt und dabei lediglich technische Spezifikationen entwickelt. Projekte, über die auf Habré geschrieben wurde: mittel - , klein - .

Wann sollte die Wasserfallmethode angewendet werden?

• Erst wenn die Anforderungen bekannt, verstanden und erfasst sind. Es bestehen keine widersprüchlichen Anforderungen.
• Es gibt keine Probleme mit der Verfügbarkeit von Programmierern mit den erforderlichen Qualifikationen.
• In relativ kleinen Projekten.

2. „V-Modell“

Die „Schritt-für-Schritt“-Struktur wurde vom Kaskadenmodell übernommen. Das V-förmige Modell ist auf Systeme anwendbar, bei denen ein unterbrechungsfreier Betrieb besonders wichtig ist. Zum Beispiel, Anwendungsprogramme in Kliniken zur Überwachung von Patienten, integrierte Software für Steuermechanismen für Notfall-Airbags in Fahrzeugen usw. Eine Besonderheit des Modells besteht darin, dass es darauf abzielt, ein Produkt, das sich bereits in der Anfangsphase der Konstruktion befindet, gründlich zu prüfen und zu testen. Die Testphase wird gleichzeitig mit der entsprechenden Entwicklungsphase durchgeführt, beispielsweise werden Unit-Tests während der Codierung geschrieben.

Ein Beispiel unserer Arbeit basierend auf der V-Methodik - App für Europäer Mobilfunkanbieter, was auf Reisen Roaming-Kosten spart. Das Projekt wird nach einer klaren Spezifikation durchgeführt, umfasst jedoch eine umfangreiche Testphase: Benutzerfreundlichkeit, Funktionalität, Auslastung und einschließlich Integration, die bestätigen soll, dass mehrere Komponenten verschiedener Hersteller stabil zusammenarbeiten, Geld- und Kreditdiebstahl ist ausgeschlossen unmöglich.

Wann sollte das V-Modell verwendet werden?

• Wenn ein gründliches Testen eines Produkts erforderlich ist, rechtfertigt das V-Modell seine inhärente Idee: Validierung und Verifizierung.
• Für kleine und mittlere Projekte, bei denen die Anforderungen klar definiert und festgelegt sind.
• Sofern Ingenieure mit den erforderlichen Qualifikationen, insbesondere Tester, verfügbar sind.

3. „Inkrementelles Modell“ (inkrementelles Modell)

Im inkrementellen Modell werden die kompletten Systemanforderungen in verschiedene Baugruppen aufgeteilt. Die Terminologie wird häufig verwendet, um den schrittweisen Aufbau von Software zu beschreiben. Es finden mehrere Entwicklungszyklen statt, die zusammen den Multi-Wasserfall-Lebenszyklus bilden. Der Zyklus ist in kleinere, einfach zu erstellende Module unterteilt. Jedes Modul durchläuft die Phasen Anforderungsdefinition, Design, Codierung, Implementierung und Test. Beim Entwicklungsverfahren nach dem inkrementellen Modell wird in der ersten großen Phase ein Produkt mit Grundfunktionalität freigegeben und anschließend sukzessive um neue Funktionen, sogenannte „Inkremente“, erweitert. Der Prozess wird fortgesetzt, bis das vollständige System erstellt ist.

Inkrementelle Modelle werden dort eingesetzt, wo individuelle Änderungswünsche klar sind und einfach formalisiert und umgesetzt werden können. In unseren Projekten haben wir damit den DefView-Reader und dann das Vivaldi-Netzwerk elektronischer Bibliotheken erstellt.

Als Beispiel beschreiben wir die Essenz eines Inkrements. ersetzt DefView. DefView hat eine Verbindung zu einem Dokumentenserver hergestellt und kann nun eine Verbindung zu mehreren herstellen. Am Standort einer Institution, die ihre Inhalte an ein bestimmtes Publikum senden möchte, wird ein Speicherserver installiert, der direkt auf die Dokumente zugreift und sie in das erforderliche Format konvertiert. Das Wurzelelement der Architektur ist aufgetaucht – der zentrale Vivaldi-Server, der als einziger fungiert Suchmaschineüber alle in verschiedenen Institutionen installierten Speicherserver.

Wann sollte das inkrementelle Modell verwendet werden?

• Wenn die grundlegenden Anforderungen an das System klar definiert und verstanden sind. Gleichzeitig können einige Details im Laufe der Zeit verfeinert werden.
• Eine frühzeitige Markteinführung des Produkts ist erforderlich.
• Es gibt mehrere riskante Funktionen oder Ziele.

4. „RAD-Modell“ (Rapid Application Development Model oder Rapid Application Development)

Das RAD-Modell ist eine Art inkrementelles Modell. Im RAD-Modell werden Komponenten oder Funktionen von mehreren hochqualifizierten Teams parallel entwickelt, ähnlich wie bei mehreren Miniprojekten. Der Zeitrahmen eines Zyklus ist streng begrenzt. Die erstellten Module werden dann in einen funktionierenden Prototyp integriert. Synergy ermöglicht es Ihnen, dem Kunden sehr schnell etwas Arbeitiges zur Überprüfung zur Verfügung zu stellen, damit er es erhält Rückmeldung und Änderungen vornehmen.

Das Rapid Application Development-Modell umfasst die folgenden Phasen:

• Geschäftsmodellierung: Definition einer Liste von Informationsflüssen zwischen verschiedenen Abteilungen.
• Datenmodellierung: Die in der vorherigen Phase gesammelten Informationen werden verwendet, um die Objekte und anderen Einheiten zu bestimmen, die für die Informationszirkulation erforderlich sind.
• Prozessmodellierung: Informationsflüsse verknüpfen Objekte, um Entwicklungsziele zu erreichen.
• Erstellen Sie die Anwendung: Verwendet automatisierte Montagetools, um CAD-Modelle in Code umzuwandeln.
• Testen: Neue Komponenten und Schnittstellen werden getestet.

Wann wird das RAD-Modell verwendet?

Nur bei hochqualifizierten und hochspezialisierten Architekten einsetzbar. Das Projektbudget ist hoch, um diese Spezialisten zu finanzieren, ebenso wie die Kosten für vorgefertigte automatisierte Montagewerkzeuge. Das RAD-Modell kann mit sicherer Kenntnis des Zielgeschäfts und der Notwendigkeit einer dringenden Produktion des Systems innerhalb von 2-3 Monaten ausgewählt werden.

5. „Agiles Modell“ (flexible Entwicklungsmethodik)

Bei der „agilen“ Entwicklungsmethodik kann der Kunde nach jeder Iteration das Ergebnis beobachten und erkennen, ob es ihn zufriedenstellt oder nicht. Dies ist einer der Vorteile des flexiblen Modells. Zu den Nachteilen gehört, dass aufgrund fehlender konkreter Formulierungen der Ergebnisse die Arbeits- und Entwicklungskosten nur schwer abzuschätzen sind. Extreme Programming (XP) ist eine der bekanntesten Anwendungen des agilen Modells in der Praxis.

Dieser Typ basiert auf kurzen täglichen Meetings – „Scrum“ und regelmäßig wiederkehrenden Meetings (einmal pro Woche, einmal alle zwei Wochen oder einmal im Monat), genannt „Sprint“. In täglichen Besprechungen besprechen die Teammitglieder Folgendes:

• Bericht über die seit dem letzten Scrum geleistete Arbeit;
• eine Liste der Aufgaben, die der Mitarbeiter vor der nächsten Besprechung erledigen muss;
• Schwierigkeiten während der Arbeit.

Die Methodik eignet sich für große Projekte oder solche mit einem langen Lebenszyklus und passt sich ständig den Marktbedingungen an. Dementsprechend ändern sich die Anforderungen im Laufe des Implementierungsprozesses. Es lohnt sich, sich an die Klasse der kreativen Menschen zu erinnern, die dazu neigen, wöchentlich oder sogar täglich neue Ideen zu generieren, zu entwickeln und auszuprobieren. Agile Entwicklung eignet sich am besten für diese Art von Manager. Wir entwickeln die unternehmensinternen Startups mit Agile. Ein Beispiel für Kundenprojekte ist das elektronische medizinische Untersuchungssystem, mit dem medizinische Massenuntersuchungen in wenigen Minuten durchgeführt werden können. Im zweiten Absatz dieser Rezension haben unsere amerikanischen Partner eine sehr wichtige Sache beschrieben, die für den Erfolg im Agile-Bereich von grundlegender Bedeutung ist.

Wann sollte man Agile verwenden?

• Wenn sich die Benutzerbedürfnisse in einem dynamischen Unternehmen ständig ändern.
• Agile Änderungen werden aufgrund häufiger Inkremente zu geringeren Kosten umgesetzt.
• Im Gegensatz zum Wasserfallmodell erfordert das agile Modell nur ein wenig Planung, um ein Projekt auf den Weg zu bringen.

6. „Iteratives Modell“ (iteratives oder iteratives Modell)

Ein iteratives Lebenszyklusmodell erfordert zunächst keine vollständige Anforderungsspezifikation. Stattdessen beginnt die Erstellung mit der Implementierung einer Funktionalität, die als Grundlage für die Definition weiterer Anforderungen dient. Dieser Vorgang wird wiederholt. Die Version ist vielleicht nicht perfekt, Hauptsache sie funktioniert. Wir verstehen das Endziel und streben danach, dass jeder Schritt effektiv und jede Version durchführbar ist.

Das Diagramm zeigt die iterative „Entwicklung“ der Mona Lisa. Wie Sie sehen können, gibt es in der ersten Iteration nur eine Skizze von Mona Lisa, in der zweiten erscheinen die Farben und in der dritten Iteration werden Details und Sättigung hinzugefügt und der Prozess abgeschlossen. Im inkrementellen Modell wird die Funktionalität des Produkts Stück für Stück aufgebaut, das Produkt setzt sich aus Teilen zusammen. Im Gegensatz zum iterativen Modell stellt jedes Stück ein vollständiges Element dar.

Ein Beispiel für iterative Entwicklung ist die Spracherkennung. Die erste Erforschung und Aufbereitung des wissenschaftlichen Apparates begann schon vor langer Zeit, zunächst in Gedanken, dann auf dem Papier. Mit jeder neuen Iteration verbesserte sich die Qualität der Erkennung. Eine perfekte Erkennung ist jedoch noch nicht erreicht, sodass das Problem noch nicht vollständig gelöst ist.

Wann ist es optimal, ein iteratives Modell zu verwenden?

• Die Anforderungen an das endgültige System werden im Vorfeld klar definiert und verstanden.
• Das Projekt ist groß oder sehr groß.
• Das Hauptziel muss definiert werden, die Einzelheiten der Umsetzung können sich jedoch im Laufe der Zeit ändern.

7. „Spiralmodell“ (Spiralmodell)

Das „Spiralmodell“ ähnelt dem inkrementellen Modell, legt jedoch den Schwerpunkt auf die Risikoanalyse. Es eignet sich gut zur Lösung kritischer Geschäftsprobleme, wenn Misserfolge nicht mit den Aktivitäten des Unternehmens vereinbar sind, im Zusammenhang mit der Veröffentlichung neuer Produktlinien, wenn wissenschaftliche Forschung und praktische Tests erforderlich sind.

Das Spiralmodell umfasst 4 Stufen für jede Drehung:

1. Planung;
2. Risikoanalyse;
3. Design;
4. Bewertung des Ergebnisses und bei zufriedenstellender Qualität Übergang in eine neue Stufe.

Dieses Modell eignet sich nicht für kleine Projekte; es ist sinnvoll für komplexe und teure Projekte, beispielsweise die Entwicklung eines Dokumentenflusssystems für eine Bank, bei der jeder nächste Schritt mehr Analyse zur Abschätzung der Konsequenzen als Programmierung erfordert. Bei einem Projekt zur Entwicklung eines EDMS für die ODU Sibiriens SO UES nehmen zwei Sitzungen zur Änderung der Kodifizierung von Abschnitten des elektronischen Archivs zehnmal mehr Zeit in Anspruch als die Kombination zweier Ordner durch einen Programmierer. Die Regierungsprojekte, an denen wir beteiligt waren, begannen mit der Ausarbeitung eines teuren Konzepts durch die Expertengemeinschaft, das keineswegs immer nutzlos ist, da es sich auf nationaler Ebene auszahlt.

Fassen wir zusammen

Die Folie zeigt die Unterschiede zwischen den beiden gängigsten Methoden.

In der modernen Praxis sind Softwareentwicklungsmodelle multivariat. Es gibt kein passendes Modell für alle Projekte, Startbedingungen und Zahlungsmodelle. Selbst Agile, das von uns allen so geliebt wird, kann aufgrund der Unvorbereitetheit einiger Kunden oder der Unmöglichkeit einer flexiblen Finanzierung nicht überall eingesetzt werden. Die Methoden überschneiden sich teilweise hinsichtlich der Mittel und sind teilweise einander ähnlich. Einige andere Konzepte dienten lediglich der Förderung der eigenen Compiler und brachten nichts Neues in die Praxis.

Über Entwicklungstechnologien:
.
.
.
.

Welche Methoden verwenden Sie?