In der iX 02/2012 ist der Artikel “Das Schöne und der Code” von Jörg Friedrich und Cornelia Gaebert erschienen. Den Anfang des Textes gibt es online auf der Homepage der iX. Für Rückfragen zum Artikel stehen die Autoren hier gern zur Verfügung.

„Die Dokumentation von Softwarearchitektur klingt viel zu aufwändig für mein Projekt. Das will mein Kunde nicht bezahlen!“

Unsere Erfahrung aus vielen Projekten mit unterschiedlicher Größe ist, dass der Umfang der Dokumentation angemessen an die Projektgröße erfolgen muss. So kann der Softwarearchitekt entscheiden mit welchem Detailgrad die Bausteine beschrieben werden.

Durch die Nutzung von einem Template, mit dem die Softwarearchitektur unternehmensintern dokumentiert wird, kann eine Dokumentation in kurzer Zeit erstellt werden. Die feste Struktur des Templates ermöglicht einen schnellen Start und es gewährleistet, dass sich der Softwarearchitekt mit allen notwendigen Punkten auseinandersetzt.

Nutzen der Dokumentation von Softwarearchitektur

Der Nutzen der Dokumentation von Softwarearchitektur ist, dass das Wissen nicht nur bei dem Architekten bleibt, der die Architektur erstellt hat. Das Wissen wird an neue Mitarbeiter oder auch externe, zukünftige Architekten vermittelt. In dem Projekt selbst ist die Software-Architektur Dokumentation ein Kommunikationsinstrument für alle Projektbeteiligten. Die Softwarearchitektur-Dokumentation kann als Basis für die Systemanalyse verwendet werden.

Was sollte auf jeden Fall in der Softwarearchitektur Dokumentation stehen?

Die getroffenen 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.

Alle relevanten Sichten eines Systems sollten beschrieben werden. Es existieren unterschiedliche Klassifizierungen von Sichten. Eine typische Unterteilung der Sichten für die Architekturdokumentation sind die folgenden Sichten:

• Kontextsicht: Betrachtung des Systems von außen
• Struktursicht: Betrachtung der statischen Struktur des Innenlebens
• Verhaltensicht: Betrachtung des dynamischen Verhaltens des Innenlebens
• Abbildungssicht: Betrachtung der Abbildung auf Artefakte, Prozessoren oder Teams

Softwarearchitektur: Sichten der Architekturdokumentation

Zusätzlich sollte eine Beschreibung über das Zusammenspiel der relevanten Schichten existieren. Die Dokumentation sollte die Frage beantworten, wie die Sichten ineinander greifen. Eine Beschreibung des Aufbaus der Architektur sollte dokumentiert werden. Eine Hilfestellung für den Leser sollte soweit notwendig existieren.

Wer gehört zur Zielgruppe des Software-Architektur Dokuments?

Zur Zielgruppe gehören:

• Projektleiter
• Architekt (auch Architekten aus anderen Projekten)
• Entwickler

Softwarearchitektur beschreibt die wesentlichen Strukturen und Mechanismen der Software auf den obersten Abstraktionsebenen in Form von Bausteinen des Systems und deren Beziehungen zueinander.
Die Gesellschaft und Unternehmen sind abhängig von Software. Diese Abhängigkeit birgt Risiken. Die Anforderungen an Software wachsen und die Komplexität steigt.

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.

Für die Bewältigung komplexer Probleme, kann man auch ausgefallene Methoden anwenden, dieses möchte ich hier an der Brainwriting-Technik Collective-Notebook Method zeigen.

Da diese Methode recht zeitaufwendig ist, ist sie auch zur Findung schnellere Lösungen nicht geeignet und sollte dann ggf. zum Einsatz kommen, wenn das Problem groß und/oder komplex genug ist.

Kernidee ist das jeder Teilnehmer ein Notizbuch mit sich führt und das über Wochen und rund um die Uhr.

Zu Anfang wird das Problem konkret definiert und es wird festgelegt, wer zur möglichen Lösung beitragen soll. Nun bekommt jeder Teilnehmer ein Notizbuch, an dessen Anfang das Problem niedergeschrieben ist.

Dieses Notizbuch soll den Teilnehmern in der Findungsphase quasi durchgehend zugänglich sein und ihnen die Möglichkeit bieten, im Fall einer guten Idee, diese sofort im Buch festzuhalten. Aber nicht nur Geistesblitze sind dort niederzulegen, sondern auch z.B. ein mal am Tag sollte grundlegend ein Eintrag erfolgen.

Nach den (wenigstens) 2 Wochen fassen alle Teilnehmer ihre eignen Ergebnisse zusammen und in einer gemeinsamen Sitzung werden dann die Ergebnisse ausdiskutiert und im Idealfall zu einer Gesamtlösung ausgearbeitet.

Wer einen Dienstplan oder einen komplexen Schichtplan erstellen muss, muss eine Unmenge von Randbedingungen berücksichtigen: Unterschiedliche Verfügbarkeit von Mitarbeitern durch Krankheit, Urlaub und Telzeitbeschäftigung, unterschiedlicher Personalbedarf, der nie zur Verfügbarkeit der Mitarbeiter passt. Und dann gibt es immer wieder Änderungswünsche und Ausfälle.

Wir haben für dieses Problem die Software IntraSail Rota  entwickelt, die diese Herausforderungen in drei Stufen angeht:

1. In einem Online-Portal können die Mitarbeiter ihre Verfügbarkeit, ihre Lieblingszeiten und ihre weiteren Präferenzen angeben.
2. Das System erstellt Dienstpläne, bei denen die Flexibilität der Mitarbeiter berücksichtigt wird. Lieblingszeiten und Präferenzen werden bei den flexibelsten Mitarbeitern zuerst berücksichtigt.
3. Der Dienstplan wird im Online-Portal zur Verfügung gestellt, dort können auch Änderungswünsche erfasst werden. Wer wenig Änderungswünsche hat und bereit ist, auch mal eine Lücke auszufüllen, dessen Lieblingszeiten werden zukünftig ebenfalls stärker berücksichtigt.

So verbinden wir ein effizientes Dienstplanmanagement mit einer Motivation der Mitarbeiter zu Kooperation und Flexibilität. Wenn Sie wissen wollen, wie das genau funktioniert, erhalten Sie hier weitere Informationen.