Musterklausur

Softwarearchitekt

1. Wie gut sind Tutorials, HowTos und Experten zu dieser Sprache verfügbar?

2. Ist die Unterstützung der Sprache für zukünftige Systemplattformen gesichert?

3. Gibt es bereits ausgereifte Frameworks und Bibliotheken für typische Probleme?

4. Ist sichergestellt, dass das Wissen zu einer Technologie über den gesamten geplanten Lebenszyklus des Systems verfügbar ist?

Je reifer eine Programmiersprache ist, umso mehr Bibliotheken, Know-how und Support ist dazu verfügbar.

Wenn das System auf einer veralteten Technologie basiert und keine vollständige Dokumentation existiert. Dann wird das Herauslösen zu einer kritischen Angelegenheit, da technische Abhängigkeiten ggf. nicht vollständig erschlossen werden können und andere Systeme in der Systemlandschaft durch die Abschaltung in Mitleidenschaft gezogen werden können. Aufgrund der fehlenden Dokumentation muss der Programmcode analysiert werden, allerdings droht hierbei, dass die Wissensträger der alten Technologie bereits das Unternehmen verlassen haben.

In dem abzuschaltenden System werden Daten nicht nur verarbeitet, sondern auch gespeichert. Diese müssen im Rahmen der Abschaltung migriert werden. Das bedeutet, die im Altsystem vorliegenden Daten müssen für die weitere Verwendung in ein anderes System übertragen werden.

Die Herausforderung bei der Migration von Daten ist zum einen die Abbildung des alten Datenschemas auf das neue Datenschema und zum anderen die Menge der zu migrierenden Daten. Weiterhin muss die für das abzuschaltende System benötigte Infrastruktur dahingehend analysiert werden, ob laufzeitgebundene Lizenzen und Nutzungsrechte erworben wurden. Entsprechende Verträge müssen gekündigt beziehungsweise dürfen nicht automatisch verlängert werden. Dabei müssen auch Wartungsverträge mit externen Dienstleistern berücksichtigt werden.

Das Wasserfallmodell ist ein Prozessparadigma, das die schrittweise, jeweils vollständige Bearbeitung einzelner Phasen in einer festgelegten Reihenfolge vorschreibt.

Strikte Trennung der Phasen und große Bedeutung der vollständigen Dokumentation.

Der Prozess geht um eine Phase zurück, um den Fehler zu beheben.

Architekt ist eine konstruktive Rolle. Ziel des Architekten (auch: Designer) ist die erfolgreiche technische Umsetzung der fachlichen Anforderungen in ein Softwaresystem. Systemtechniker ist eine betreibende Rolle. Ziel des Systemtechnikers ist das Bereitstellen und Gewährleisten von technischen Ressourcen zum Betrieb eines Softwaresystems.

Die Architektur des Systems muss zur Betriebsinfrastruktur passen, die der Systemtechniker zur Verfügung stellt.

Beide Rollen folgen den Vorgaben des Qualitätsmanagements. Somit hat das Qualitätsmanagement nachweislich sowohl Einfluss auf die konstruktiven Rollen/Phasen als auch auf die betreibenden Rollen/Phasen → übergreifenden Einfluss.

In der Kernaktivität „Entwerfen einer Architektur“ erstellt der Architekt in der Regel eine erste Version der Architekturbeschreibung. Anschließend müssen die getroffenen Entscheidungen gegen die Anforderungen geprüft und bewertet werden. Gegebenenfalls muss die IT-Architektur überarbeitet werden. Fällt das Ergebnis der Bewertung positiv aus, wird die IT-Architektur so lange weiter verfeinert und detailliert, bis eine ausreichende Lösung gefunden ist. Anschließend werden die getroffenen Entscheidungen in Form einer Architekturbeschreibung dokumentiert. Wie im Requirements Engineering erfolgt hier abhängig vom aktuellen Kenntnisstand eine entsprechend detaillierte Darstellung. Das heißt, je detaillierter die Entscheidungen zur Architektur werden, umso technischer und präziser müssen die Ergebnisse dokumentiert werden. Vergleichbar mit den Kernaktivitäten des Requirement Engineerings finden die Aktivitäten zur Architekturbeschreibung iterativ (in mehreren Zyklen) statt. Jede zusätzliche Anforderung, die im Verlauf der Softwareentwicklung erkannt wird und als erforderlich eingestuft wird, muss durch den Softwarearchitekten bewertet und in die bestehende Architekturbeschreibung eingebracht werden.

Ein Merkmal des Software Engineerings ist es, dass Anforderungen an das zu erstellende System erst im Verlauf des Softwareprozesses erkannt werden. Allerdings bilden die Anforderungen an das System den Ausgangspunkt für alle weiteren Aktivitäten innerhalb eines Softwareprojekts. In der Regel werden relevante Anforderungen von Anwendern und Kunden erst erkannt, nachdem sie eine erste Version des Systems gesehen haben.

Ein Software Engineer steht nun vor folgendem Dilemma: Fängt man an, ein System zu entwickeln, zu dem die Anforderungen nicht klar sind, geht man ein hohes Risiko ein, dass die erstellte Anwendung nicht die gewünschten Funktionen umsetzt. Ein Anwender kann jedoch zu Beginn oft nicht genau sagen, welche Funktionen er genau benötigt. Denn er erkennt wichtige und relevante Funktionen oft erst dann, wenn er eine erste Version des Systems ausprobieren kann.

Eine Rolle ist gekennzeichnet durch ihren Namen, spezifische Aufgaben und spezifische Zielsetzungen. Eine am Projekt beteiligte Person nimmt mindestens eine bestimmte Rolle ein. Je nach Größe des Projektes werden Rollen mehrfach vergeben. Das heißt, eine Person kann mehrere Rollen wahrnehmen und eine Rolle kann durch mehrere Personen wahrgenommen werden. Sowohl die Möglichkeit der Expertenbildung und Spezialisierung ist ebenso zu beachten wie der Einsatz vorhandener Spezialisten und Experten.

Der Architekt gestaltet die Architektur auf Basis der Ergebnisse des Requirements Engineers und des Spezifizierers unter Berücksichtigung zusätzlicher Vorgaben durch die Rollen, die für Implementierung, Betrieb und Weiterentwicklung verantwortlich sind. Der Architekt muss darüber hinaus Vorgaben durch das Projekt- und Qualitätsmanagement einhalten, von denen er auch geprüft wird.

Rollen mit übergreifendem Einfluss sind in allen Kernaktivitäten des Software Engineerings aktiv.

(Beispiel: Projektmanager)

Konstruktive Rollen sind aktiv an der Entwicklung beteiligt.

(Beispiel: Architekt)

Betreibende Rollen sind im Anschluss an die Entwicklung für Integration und Betrieb zuständig.

(Beispiel: Integrator)

Ziel des Projektmanagers ist die erfolgreiche Durchführung des Projekts. Die Aufgaben des Projektmanagers umfassen insbesondere:

• Planung, Organisation und Kostenschätzung des Projekts

• Steuerung und Koordination der Projektaktivitäten und Personen

• Kontrolle und Verfolgung der erzielten Ergebnisse