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.

Ein Beispiel:
„Berichte in der Anwendung sollen innerhalb von 30 Sekunden bereitgestellt werden“
Ist das eine funktionale oder eine nicht-funktionale Anforderung? Viele werden argumentieren, dass dies eine nicht-funktionale Anforderung ist, da der Satz etwas über das „Wie“ der Leistungserfüllung aussagt. Aber dass die Anwendung „Berichte bereitstellen“ soll, ist eine funktionale Anforderung, und wenn die Berichte typischerweise erst ein Tag nach dem Aufruf des entsprechenden Menüpunktes bereitgestellt werden, dann ist das keine Funktionserfüllung, auch wenn alle Zahlen im Bericht korrekt sind.
Ein neuer Ansatz ist, zu sagen, dass jede Anforderung sowohl Aussagen zu der Frage, was umgesetzt werden soll als auch zu der Frage, wie es umgesetzt werden soll enthält. Anforderungen lassen sich dann generalisieren und spezialisieren, wie wir es aus der objektorientierten Sichtweise kennen.
Können wir damit die Anforderungen, die wir bisher in funktionale und nicht-funktionale unterschieden haben, komplett abbilden? Nicht ganz, ein Aspekt fehlt noch, es ist der der zeitlichen Veränderbarkeit der Anforderung. Ist zu erwarten, dass ein Bericht sich ändert, wenn ja, wie oft? Werden Datenmengen wachsen? Wird die Anforderung auch unter geänderten Bedingungen, z.B. bei neuen Infrastrukturen und Plattformen, bestehen bleiben? Dieser dynamische Aspekt von Anforderungen wird oft vernachlässigt, aber wenn wir ihn mit einbeziehen, dann haben wir quasi alles was wir brauchen, um eine gute Architektur zu entwerfen.
Dazu legen wir uns wie gesagt eine Anforderungs-Hierarchie an, eine Vererbungs-Struktur. Die Basis-Anforderungen sind das Fundament, sowohl für die abgeleiteten Anforderungen als auch für den Architektur-Entwurf der Software. Umso spezieller die Anforderungen werden, desto geringer ist ihr Einfluss auf die Architektur.

Der Beitrag Anforderungsaspekte: Was, Wie und Wie lange? erschien zuerst auf INDAL Software-Spezialist.