requirements mit den Themen UML und Anfoderungsmanagement

Software ist allgegenwärtig: Fliegen, Telephonieren, Überweisen, Autofahren - all das wäre ohne Software unmöglich. Wie hat die Welt funktioniert, als es noch keine Software gab?

Mann sollte meinen, daß Software-Ingenieure inzwischen gelernt haben, wie man Software baut. Aber sie können es noch immer nicht:

Softwareprojekte dauern zu lange, kosten zu viel, scheitern zu oft, und selbst wenn sie das Ziel der Inbetriebnahme erreichen, ist das Ergebnis zu oft mangelhaft: Bei der Inbetriebnahme sind Probleme wie mangelnde Performanance oder mangelnde Stabilität die Regel, nicht die Ausnahme.

Was wir uns wünschen sind Effizienz und Sicherheit in der Projektdurchführung und hohe Qualität des fertigen Systems. Dabei helfen uns viele Ansätze: Neue Verfahren der Anforderungsanalyse, moderne Vorgehensmodelle, sorgfältige Qualitätssicherung, Wiederverwendung von Software, um nur einige zu nennen.

Ein ganz entscheidender Erfolgsfaktor ist dabei die Softwarearchitektur. Es geht um die Frage, wie man die Millionen Programmzeilen großer Systeme so strukturiert, daß im Ergebnis die gewünschte Qualität erreicht wird: Wartbarkeit, Flexibilität, Performance und andere Eigenschaften. Dabei gilt Softwarearchitektur oft als akademisches Thema: Hauptsache, die Software läuft, die Architektur ist nicht so wichtig. Aber in Wirklichkeit ist gute Softwareachitektur die Voraussetzung dafür, daß andere Erfolgsfaktoren überhaupt zum Tragen kommen - das zeigen die folgenden Überlegungen:

Anforderunganalyse

Nicht selten stellt man bei der Systemeinführung fest, daß man das falsche System gebaut hat. Hier helfen neuere Verfahren der Anforderungsananlyse (etwa Volere, siehe [Robertson&Robertson 2000]). Sie gestatten es die Anforderungen unterschiedlicher Interessengruppen strukturiert aufzunehmen und zu gewichten. Die Anforderungsanayse ist ein Prozeß, der das Projekt während seiner ganzen Laufzeit begleitet; jeder weiß, daß sich die Anforderungen laufend ändern, egal wie gut sie aufgeschrieben sind. Sich ändernde Anforderungen beeinflußen den Projektplan, das Budget und vor allem die Architektur der Software. Aber auch die beste Änderungsverwaltung läuft in die Leere, wenn sich die Software den gewünschten Änderungen widersetzt - und deshalb ist gute Softwarearchitektur die Voraussetzung dafür, daß erhobene Anforderungen in die Software eingebaut werden können.

Vorgehensmodelle

Softwareprojekte sind schnell, wenn es gelingt, die Arbeit zu parallelisieren, und sie werden billiger, wenn die Arbeit wenigstens teilweise in Ländern mit niedrigem Lohnniveau durchgeführt wird. Aber bevor man erste Budgetüberlegungen mit niedrigen Stundensätzen anstellt, sollte man überlegen, wie man die Arbeit zu Hause (on shore) und in der Ferne (off shore) sinnvoll aufteilt. Das Ziel ist klar: Jedes Teilteam befaßt sich mit einer wohl definierten Aufgabe; die Schnittstellen zwischen den Teams sind eindeutig festgelegt; jedes Team weiß genau, was es zu liefern hat und auf welchen Ergebnissen es aufbaut. Das alles funktioniert nur unter der Voraussetzung, daß die Softwarearchitektur eine solche Aufteilung überhaupt zuläßt. Wenn sie es nicht tut, sind die schönsten Projektpläne Makulatur.

Qualitätssicherung

Qualität entsteht nicht von alleine, sondern sie muß gesichert werden. Die Qualität des Gesamtsystems ergibt sich aus der Qualität seiner Bestandteile, und man kann die Qualität des Ganzen nur sichern, indem man die Qualität der Bestandteile überprüft. Auch das kann nur glücken, wenn das Gesamtsystem in vernünftig gestaltete Komponenten aufgeteilt ist.

Wiederverwendung

Man wird schneller fertig, wenn man vorhandene Software wieder verwendet, anstatt sie jedes Mal neu zu schreiben - das leuchtet ein. Aber trotzdem ist der Produktivitätsgewinn durch Wiederverwendung bis heute außerodrdentlich gering, wenn er überhaupt meßbar ist. Der Grund dafür liegt darin, daß sich Software zur Wiederverwendung nur dann eignet, wenn sie den Prinzipien guter Softwarearchitektur folgt: klare, einfach Schnittstellen und minimale Abhängigkeiten. Aber damit tun wir uns schwer: Oft sind die Schnittstellen zu kompliziert, die Abhängigkeiten verborgen - und so ist Wiederverwendung ausgeschlossen.

Diese Überlegungen zeigen, daß Softwarearchitektur kein akademisches Thema ist, sondern daß Softwarearchitektur trotz der unverbindlichen Ästhetik, die im Namen mitschwingt, eine notwendige (leider keine hinreichende) Voraussetzung ist für effiziente und sichere Projektabwicklung. Es gibt eigentlich nur einen, allerdings entscheidenden Erfolgsfaktor, der wirklich nichts mit Softwarearchitektur zu tun hat, nämlich:

Beauftragung mit Augenmaß

Jedes Softwaresystem hat eine — mehr oder (oft) weniger gute — Struktur. Wir sprechen in diesem Zusammenhang von Softwarearchitektur und meinen damit den systematisch strukturierten, sachgerechten, modularen Aufbau eines Softwaresystems. Dieser Aufbau spiegelt sich nicht nur in dem maschinell les- und verarbeitbaren Code wieder, sondern er drückt sich vor allem auch in der begleitenden Dokumentation aus.

Menschen machen Projekte.

© 1996-2009 icoup-consulting.de | Kontakt | Impressum