Sind klassische Vorgehensmodelle für die Anwendungsentwicklung mit Visual Composer geeignet?

Klassische Anwendungsentwicklung und neue Konzepte

In meinem letzten Blog habe ich die Paradigmenwechsel von betriebswirtschaftlicher Standardsoftware aufgegriffen um die Frage zu beantworten, ob Visual Composer nur ein weiteres Werkzeug zur Erstellung betriebswirtschaftlicher Applikationen ist. Die Frage konnte ich deutlich verneinen. Ich kam zu dem Ergebnis, dass SOA und Visual Composer den Anwender aus dem Fachbereich, den sogenannten Geschäftsprozessexperten, in die Lage versetzt Anwendungen selbst zu entwickeln. Die Möglichkeit das Anwendungen von den Anwendern selbst innerhalb kürzester Zeit erstellt werden können durch die Anwendungsmodellierung wirft die Frage auf, ob die klassischen Vorgehensweisen in der Anwendungsentwicklung noch Ihre Berechtigung haben. In diesem Blog möchte ich die klassischen Vorgehensweisen in der Anwendungsentwicklung diskutieren und auch neuere Konzepte vorstellen.


Aller Anfang ist schwer: Das Modell „Code and Fix“


Dieses Modell stammt aus den Anfangstagen der Anwendungsentwicklung. Dieses Modell ist gekennzeichnet durch schnelle Codeerstellung ohne Planung, mit direkter Codierung und bedarfsweiser Fehlerkorrektur. Dieses Modell ist insbesondere bei Anfängern und Gelegenheitsprogrammierer aufzufinden. Das Vorgehen kann in zwei Schritte eingeteilt werden:
1. Codierung / Programmerstellung
2. Finde und behebe die Fehler im Programm


Die Nachteile dieser Vorgehensweise sind offensichtlich. Die Fehlerbehebung führt zu Strukturmängeln in den Programmen. Strukturmängel wiederum erschweren die Beseitigung von Folgefehlern. Die Folgerung daraus war die Einführung einer Entwurfsphase. Ein weiterer Nachteil dieser Vorgehensweise ist, dass selbst gut entworfene Software nicht durch den Benutzer akzeptiert wurde, weil schlichtweg die Anforderungen des Benutzers nicht vollständig abgedeckt wurden. Als Folge dessen wurde die Definitionsphase eingeführt. Das Auffinden der Fehler in solchen Programmen stellt ebenfalls ein Nachteil dar, der unter anderem auch die Akzeptanz des Benutzers beeinträchtigt. Die Folgerung war die Einführung einer Testphase. Zusammenfassend kann man sagen, dass die Mängel der „Code and Fix“-Vorgehensweise zur Einführung von Projektphasen in der Anwendungsentwicklung geführt hat.


Phasen der traditionellen Softwareentwicklung


Die herkömmliche traditionelle Softwareentwicklung besteht aus den folgenden Phasen:


1. Systemanalyse
In der Systemanalyse erfolgt zunächst eine Untersuchung und Bewertung der Aufgabe der Software und ihre Stellung innerhalb ihrer Umgebung. In der Systemanalyse befasst man sich mit Komponenten der realen Welt und deren realitätsnahen Abstraktionen. Programmkomponenten spielen hier in der Regel keine Rolle. Bei einer Systemanalyse wird sich zunächst die Auftraggeberseite mit Zielen, Durchführbarkeit und Wirtschaftlichkeit des Vorhabens auseinandersetzen. Dann folgt eine erste Aufgabenspezifikation die dann im Dialog mit dem potentiellen Lieferanten zum vertraglich bindenden Pflichtenheft „reift“. Die Ergebnisse werden im  Allgemeinen in Textform festgehalten und teilweise durch Grafiken ergänzt. Am Abschluss der Systemanalysephase steht die Auftragsvergabe.


2. Programmentwurf
Der Programmentwurf setzt nach der Auftragsvergabe ein. In dieser Phase werden die Funktionen des Programms detailliert festgelegt im sogenannten Funktionsentwurf. Im Architekturentwurf wird über die Verteilung der Funktionen auf die Programmbausteine (Module) entschieden. Außerdem erfolgt die Festlegung der Datenelemente und des wesentlichen Daten- und Steuerfluss unter Berücksichtigung der Möglichkeiten und Grenzen der verfügbaren Hard- und Softwaresysteme.


3. Codierung
Die Codierung ist die Realisierung des Entwurfs in einer Programmiersprache.


4. Test- und Fehlerbeseitigung
Nach der Codierungsphase wird im Rahmen von Test und Fehlerbeseitigung umfassend überprüft, ob das Programm den gestellten Anforderungen genügt. Falls dies nicht der Fall ist, sind die erforderlichen Änderungen durchzuführen. Diese betreffen in den meisten Fällen nicht nur die Codierung, sondern reichen in vielen Fällen in den Entwurf und in die Systemanalyse zurück.


5. Dokumentation
In der Dokumentation werden Aufbau, Funktion und Bedienung des erstellten und geprüften Programms beschrieben, wobei ein und dasselbe Programm für unterschiedliche Zielgruppen ggf. in unterschiedlicher Form zu dokumentieren ist.


6. Betrieb und Programmpflege / Wartung und Weiterentwicklung
Aufgabe der Programmpflege ist die Beseitigung von Fehlern, die während des Betriebs bemerkt werden, sowie die Anpassung des Programms an eventuelle Änderungen der Aufgabenstellung und an die technische Entwicklung.
Die Beurteilung des traditionellen Modells der Softwareentwicklung ergibt ein einfaches Modell, dass in klare Projektphasen aufgeteilt ist. Jedoch ist die Darstellung weniger realistisch, da von einem sauberen, fehlerfreien Abschluss der Vorgängerphase ausgegangen wird. Ein weiterer Nachteil ist, dass Arbeitsfähige Versionen erst sehr spät existieren sowie eine lange Fehlerverweilzeit durch die nachgeschalteten Tests. Trotz der Schwächen dieses Modell, war es die Grundlage für alle weiteren Vorgehensweisen die in der Literatur genannt werden. Im Folgenden möchte ich auf einige Vorgehensmodelle eingehen, die auf diesem Grundmodell basieren und deren Eignung für die Applikationserstellung mit Visual Composer und einer SOA diskutieren.


Wasserfallmodell als Beispiel für ein lineares Vorgehensmodell


In der Literatur ist das Wasserfallmodell oft das erst genannte, das zu den linearen Phasenmodellen gehört. Es besteht aus den Phasen Initialisierung, DV-Konzept, DV-Entwurf, Implementierung, Test, Installation und Wartung.





Jede Phase ist sehr strikt getrennt und man kommt erst in die nächste Phase nach Abschluss der vorherigen Phase in der Regel durch Abnahmen. Rückschritte zur vorherigen Phase sind zwar möglich, jedoch unerwünscht. In der Praxis eingesetzt würde das Produkt dem Kunden erst nach der Testphase präsentiert werden, also wenn es fertig ist. Dies ist der Hauptnachteil des Wasserfallmodells, denn wenn  Änderungen von Seiten den Kunden kommen, müssen alle Phasen erneut durchlaufen werden.  Dieses Modell bindet  den Anwender erst sehr spät ein und ist deshalb nicht nur für Projekte auf Basis von SOA und Visual Composer ungeeignet, sondern auch für alle anderen IT Projekte, weil das Modell idealisiert und unbrauchbar  für die Praxis ist. Es ist lediglich als theoretischer Einstieg in die Phasenmodelle geeignet und wird deshalb auch sehr oft in der Literatur angeführt. Es zeigt sehr deutlich die Trennung zwischen den verschiedenen Phasen, so dass an diesem einfachen linearen Modell die Idee der Phasenmodelle schön deutlich wird und sich für die Lehre perfekt eignet.


V-Modell


Das Wasserfallmodell wurde weiterentwickelt zum V-Modell. Die Hauptschachstellen wurden beseitigt indem das V-Modell lediglich Aktivitäten und Ergebnisse definiert und keine strikte zeitliche Abfolge fordert. Insbesondere wurden die typischen Abnahmen am Ende einer Projektphase abgeschafft. Das V-Modell bindet den Auftraggeber mehr in das Projekt ein, indem es nun auch Vorgehensbausteine für diesen gibt. Trotz der Ausrichtung in Richtung agiler und inkrementeller Ansätze fehlt dem Vorgehen die notwendige Flexibilität und Einbindung des Endanwenders um die Vorteile einer Anwendungsentwicklung auf Basis von SOA und Visual Composer voll auszunutzen. Ein weiterer großer Nachteil dieses Vorgehensmodell ist der sehr hohe Detaillierungsgrad der vom Anwendungsmodellierer während der Entwurfsphase abverlangt wird.




Spiralmodell als Beispiel für ein inkrementelles Modell


Das Spiralmodell ist nicht mehr linear aufgebaut, sondern wie der Name schon sagt, wie eine Spirale. Es wird auch als iteratives und inkrementelles Phasenmodell bezeichnet, weil die Phasen des Wasserfall-Modells mehrfach durchlaufen werden. Das Ergebnis jeder Phase ist ein Prototyp und schließlich dann das fertige Produkt als Ergebnis der letzten Phase. Dieses Vorgehensmodell ist dadurch charakterisiert, dass die einzelnen Phasen iterativ durchlaufen werden und der Endanwender regelmäßig anhand der Prototypen am Ende jeder Phase überprüfen kann, ob sich
das Projekt in die richtige Richtung entwickelt und so mögliche Fehlentscheidungen noch relativ kostengünstig korrigiert werden. Dieses Modell eignet sich schon sehr gut für die Anwendungsentwicklung auf Basis von SOA und Visual Composer, jedoch wurde das Modell in einer Zeit (1988) beschrieben, als mit Software-Projekten häufig schlechte Erfahrungen gemacht worden sind. Aus diesem Grund ist das Modell sehr stark risikogetrieben und es wird nach jedem Durchlauf erneut eine Risikoanalyse durchgeführt. Dies bedeutet in der Praxis einen deutlichen Mehraufwand durch die erneuten Risikoanalysen und Verifikation der Zwischenschritte.


Fazit

Anhand der vorgestellten Beispiele ist zu erkennen, dass die klassischen Vorgehensmodelle viele Schwachstellen aufweisen. Dies sind insbesondere die sehr starke Trennung von Anforderungsanalyse und Implementierung sowie die sehr späte Einbindung des Endanwenders in das Projekt. Meistens muss der Endanwender seine sehr komplexen Anforderungen in Form eines Buchs, oder auch oft als Lastenheft bezeichnet, spezifizieren. Auf dessen Basis wird dann wieder ein neues Buch geschrieben, dass sich Pflichtenheft nennt. Wenn alles abgenommen ist wird die Anwendung entwickelt. Hat der Endanwender etwas vergessen oder es hat sich etwas in den Anforderungen geändert ist dies schlichtweg Pech.  Meistens entspricht die Anwendung dann nicht dem gewünschten Ergebnis. Verfechter der klassischen Vorgehensmodelle würden diese Tatsache eher als Ergebnis von schlechtem Projektmanagement und schlechten Spezifikationen oder sogar damit begründen, dass Endanwender und Entwickler zu wenig  Erfahrung in der Anwendungsspezifikation und -entwicklung aufweisen. Aber mal ehrlich bringt uns dies weiter? – Anwendungen werden nicht zum Spaß entwickelt, sie sollen einen Mehrwert für den Endanwender bringen. Aus diesem Grund soll der Endanwender möglichst früh eingebunden werden und nicht damit gegängelt werden, dass er tausende Seiten von Spezifikationen erfassen soll und am Ende dann doch nicht das erhält was er möchte.


Die Vorteile der Anwendungserstellung auf Basis einer SOA und Visual Composer wie zum Beispiel das sehr schnelle Erstellen von Prototypen anhand weniger Spezifikationen und dadurch das frühzeitige Entgegenwirken einer Fehlentwicklung des Projekts können nur dann ausgenutzt werden, wenn auf die klassischen Vorgehensmodellen und ihren Schwächen verzichtet wird. Trotzallem wird in der Praxis leider noch viel zu oft auf diese Modelle gesetzt und viel Zeit und Budget damit verwendet Papier zu produzieren das keinen Mehrwert bringt. In meinem nächsten Blog möchte ich neue innovative Vorgehensmodelle vorstellen, welche die Stärken von SOA und Visual Composer ausnutzen.

Die englische Version des Blogs können Sie wie immer im SDN lesen.

Getagged mit: ,
Ein Kommentar auf “Sind klassische Vorgehensmodelle für die Anwendungsentwicklung mit Visual Composer geeignet?
  1. Mike Bayerle sagt:

    „Ein weiterer Nachteil ist, dass arbeitsfähige Versionen erst sehr spät existieren sowie eine lange Fehlerverweilzeit durch die nachgeschalteten Tests“ – exzellent! 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*