Der Prototyp sollte einen Durchstich durch alle Schichten der Anwendung realisieren, somit etwa das Lesen und Schreiben von Daten, die Businesslogik und die Oberfläche umfassen. Allerdings muss hier genauer hingesehen werden. Wenn z.B. die GUI verschiedene Typen von Funktionen umfasst, sollte jeder Typ im Prototypen repräsentiert sein, Masken ebenso wie die Programmsteuerung und Reports. Das Gleiche gilt für die anderen Schichten der Anwendung.

Der Prototyp soll zeigen, wie die Migration erfolgen kann, und das betrifft zweierlei:

1. Wie wird aus den Architekturzusammenhängen der Altanwendung die Architektur der zukünftigen Anwendung? Wenn die Altanwendung z.B. eine Client-Server-Anwendung ist, die in eine Webumgebung migriert werden soll, dann ist damit zumeist auch eine neue Anwendungsarchitektur verbunden. Ein Prototyp ist also immer auch Architekturprototyp.
2. Wie kann der Code der Altanwendung möglichst systematisch (automatisch oder nach engen Programmierrichtlinien) in die neue Architektur übertragen werden? In der Regel ist das mit einem Refactoring der Businesslogik verbunden. Der Prototy sollte es erlauben, strikte Anweisungen für die “Umarbeitung” einer Anwendungsfunktion auf die neue Plattform zu definieren, oder sogar Codegeneratoren zu konzipieren, die aus dem alten Code den neuen erzeugen – wenigstens zum großen Teil.

Schließlich sollte ein Migrationsprototyp möglichst auch ein Oberflächenprototyp sein. An der Oberfläche muss eine Applikationsmigration immer den größten Spagat vollbringen: Einerseits soll der Anwender die vertrauten Funktionen ohne weiteres intuitiv wiederfinden, andererseits hat er zumeinst auch eine Erwartung, wie eine Anwendung in der neuen Umgebung auszusehen hat. Eine PC-Anwendung hat bestimmte typische Oberflächenelemente, die eine Web-Applikation nicht oder anders implementiert – und umgekehrt. Ein Oberflächenprototyp kann zeigen, wie die vertrauten Elemente sich plausibel in der neuen Umgebung wiederfindenlassen – Migration von Anwendungen ist immer ein bisschen so wie behutsame Fassadensanierung, man möchte modernisieren, aber den vertrauten Charme auch bewahren.

Der Beitrag Migrations-Prototypen erschien zuerst auf INDAL Software-Spezialist.

Wie können wir diesen Herausforderung gerecht werden?
Lösung:

• Komplexität beherrschbar machen (Wiederverwendung von Software-Bestandteilen)
• Entwicklungs- und Prozessverbesserung durch Softwarearchitektur
• Risiko bzw. Risiken besser einschätzen

Wir sind auf Software angewiesen!
Die IT entwickelt sich rasend schnell dadurch bieten sich eine Menge neuer Möglichkeiten.

• Diese Möglichkeiten befähigen, Software zu entwickeln, die immer größere Teile der betriebswirtschaftlichen Prozesse eines Unternehmens übernehmen kann. Aus diesem Grund steigt der Grad der Abhängigkeit zwischen Unternehmen und Software weiter rasant.
• Durch die vielen neuen Möglichkeiten bekommt die Software einen großen Funktionsumfang und nimmt somit an Komplexität zu.

Die Abhängigkeit birgt Risiken z.B. durch einen Fehler in einem Flugsicherungssystem können viele Menschenleben gefährdend werden. Aber auch ein Fehler in einer Software, die dem Unternehmen Wettbewerbsfähigkeit gewährleistet, kann schwerwiegende Folgen haben z.B. für den Unternehmenserfolg.

Komplexität
Um den wachsenden Anforderungen und der steigenden Komplexität gewachsen zu sein und die Risiken zu minimieren, sollten diese drei wesentlichen Ziele bei der Softwareentwicklung verfolgt werden:

• Verkürzung der Entwicklungszeiten (Zeit)
• Reduzierung der Wartungs- und Entwicklungskosten (Kosten)
• Verbesserung der Qualität (Qualität)

Wiederverwendung
Um den Zielen gerecht zu werden muss der Grad der Wiederverwendung erhöht und der Entwicklungsprozess verbessert werden.
Die wiederverwendeten Module wurden schon in einem anderen System verwendet und ausführlich auf ihre Funktionalität und Qualität getestet. Durch die Übernahme dieser Module ist somit die Qualität erfüllt, es entstehen keine zusätzlichen Kosten oder zu kalkulierende Zeiten.

Entwicklungs- und Prozessverbesserung durch Softwarearchitektur
In den Bereichen Entwicklungs- und Prozessverbesserung spielt die Softwarearchitektur eine Schlüsselrolle. Durch die iterativ, inkrementellen Bewertung und Kommunikation des Entwurfs kann der Entwurf solange angepasst werden bis eine stabile und ausgereift Architektur gefunden wurde. Getroffene Entscheidungen sollten dokumentiert werden. Wichtig ist es, dass auch für andere Architekten nachvollzogen werden kann, aus welchen Gründen eine Entscheidung getroffen wurde. Bewährte, dokumentierte Entscheidungen ermöglichen anderen Architekten in den gleichen Situationen genau so oder ähnlich zu entscheiden. Das Wissen, welches sonst nur der einen Architekten besitzt, steht durch das Dokumentieren für alle zur Verfügung.

Risiko besser einschätzen
Softwarearchitektur befähigt Unternehmen bereits vor Implementierungsbeginn, fundierte Aussagen über die Qualitätsmerkmale und Risiken des Systems wie Laufzeiten, Robustheit oder Änderbarkeit zu treffen. Je eher im Entwicklungsprozess Risiken erkannt werden, desto eher kann der Softwarearchitekt die richtigen Maßnahmen treffen.

Der Beitrag Warum Software-Architektur? erschien zuerst auf INDAL Software-Spezialist.