Aus der Zukunft

Ein Zeitreisender aus einer fernen Zukunft entschließt sich eines Tages zu einer Portation ins Jahr 2006. Als Softwarekreator betrachtet er die heutige Zeit durch eine romantisch getönte Brille. Über die prähistorische Informatik des Jahres 2006 hat er schon einige Literatur verschlungen. Nun möchte er sich ein eigenes Bild von ihr machen. In seiner Zeit erfolgt der größte Teil der Softwareentwicklung automatisiert. Lediglich für die Erzeugung neuer, individueller Komponenten schließen sich vernetzte Entwicklerteams zusammen, die weltweit nach demselben Prozess agieren.

Funktionale Anforderungen und gewünschte Anforderungsszenarien spezifiziert der Domänenmodellierer in natürlicher Sprache, aus denen intelligente Quantencomputer in Bruchteilen von Sekunden fertige Softwarearchitekturen generieren. Zuvor erfolgt eine netzweite Suche nach schon vorhandenen Softwareartefakten. Dienste und Komponenten stellen den Treibstoff der Zivilisation dar. Softwarefabriken fungieren als Tankstellen, aus denen Anwender die gewünschten Komponenten gegen Entgelt beziehen. Das Netz dient als Informationsdrehscheibe und zugleich als Basis für die weltweite Softwarefabrik. Industrielle Generatoren erfragen noch die operativen und architektonischen Eigenschaften, bevor sie diese Aspekte automatisch in die Rahmenarchitektur einweben.

Der Zeitreisende weist sein Quantennetz an, für die Reise ein passendes Wurmloch zu erzeugen. Er begibt sich an den Anfang des holographischen Zeittunnels. In der Gegenwart verlädt eine Speditionsfirma gerade in einem ruhigen Hinterhof die neue Ausgabe der iX. Eine Palette löst sich und fällt. Unglücklicherweise gerade zu dem Zeitpunkt, als der Zeitreisende durch das Portal die heutige Zeit betritt. Richtige Zeit, falscher Ort. Schmerz, Dunkelheit, Amnesie. Als er in der iX-Redaktion erwacht, kann er sich nicht mehr erinnern, wer er ist und woher er kommt. Nur seine Rolle als Softwarekreator schiebt sich aus dem Dunkel seiner Erinnerungslosigkeit ins Bewusstsein. Die Redaktion gibt ihm auf seinen Wunsch ein paar iX-Jahresausgaben und weitere Fachliteratur zur Lektüre. So langsam beginnt sich aus den Puzzleteilen ein vollständiges Bild zu formen.

Scheitern und seine Ursachen

Marktanalysten und IT-Experten schätzen, dass nach wie vor lediglich 20 % aller Softwareprojekte zu einem erfolgreichen Abschluss kommen. Bei den restlichen 80 % kommt es im schlimmsten Fall zu einem vorzeitigen Abbruch, während der „Normalfall“ aus Projekten mit Zeit- und Budgetüberschreitung oder unvollständigem Auslieferungsvolumen besteht. Die Ursachen dafür sind so vielfältig wie das Scheitern selbst. Softwareentwickler stehen einer wachsenden Menge neuer Techniken gegenüber, die jede für sich ohne Zweifel einen enormen Fortschritt darstellt, aber deren Vielzahl dem Entwickler zunehmend die Luft abschnürt. Die Geschichte vom Schlaraffenland drängt sich in diesem Zusammenhang auf.

Zum systematischen Erlernen neuer Techniken und Werkzeuge stehen nicht die dafür benötigten Freiräume zur Verfügung. Stattdessen müssen die Kundenprojekte als Lernvehikel dienen - das Credo heißt „learning by doing“ -, weshalb Kunden ohne ihr Wissen zu Versuchskaninchen mutieren. Zudem erweisen sich Werkzeuge und Techniken als zu wenig ausgereift, weil deren Entwickler mit genau denselben Schwierigkeiten zu kämpfen haben. Softwareentwicklung präsentiert sich als letzte Manufaktur des 21. Jahrhunderts: statt Automatisierung dieselben, immer wiederkehrenden Tätigkeiten. Noch dazu fordert der Markt schnellere Produktzyklen bei wachsender Zahl gewünschter Anforderungen, wobei die kontinuierliche Änderung und Erweiterung der Anforderungen zur Projektlaufzeit eher die Regel als die Ausnahme darstellt.

Zu Abstrichen an der Qualität der Endprodukte ist allerdings niemand bereit. Leider fehlen zumeist die Ressourcen für systematische Qualitätssicherung, ein schwerwiegendes Problem in Zeiten, da Outsourcing und Offshoring en vogue sind und global verteilte Projektteams ihre Ergebnisse synchronisieren müssen. Die praktische Ausbildung der Softwareentwickler lässt ebenfalls zu wünschen übrig. Zwar betrachten viele das Thema Softwarearchitektur als essenziell, widmen sich ihm in der Praxis aber unzureichend, von der fehlenden Rolle des Softwarearchitekten ganz zu schweigen. Womit wir beim Thema Management angelangt wären, das der Softwareentwicklung zu allem Überfluss noch weitere Hindernisse in den Weg stellt. Exemplarisch seien aus dem breiten Spektrum der „Foltermethoden“ inadäquate Organisations- und Projektstrukturen, fehlende Maßnahmen zur gezielten Automatisierung und Wiederverwendung von Bausteinen sowie überbordende Meetingkulturen genannt.

Lamentieren hat nur selten zu Verbesserungen geführt. Wie lautet daher der Ausweg aus diesem Dilemma? Anders gefragt: Wie lässt sich bessere Software effizient herstellen? Der Zeitreisende könnte im Vollbesitz seiner Erinnerungen eine vollständige und zusammenhängende Landkarte zeichnen. Aus heutiger Sicht stehen lediglich Lösungsfragmente zur Verfügung, die die Vision einer fernen, besseren Zukunft im Nebel durchschimmern lassen.

Der adäquate Entwicklungsprozess

Am Anfang steht eine Binsenweisheit: Wer qualitativ gute Produkte effizient zu fertigen beabsichtigt, benötigt hierfür einen adäquaten Entwicklungsprozess. Softwareentwicklung weist in der Regel eine hohe Komplexität auf, weil deren Endprodukte entweder sehr kundenspezifische Softwaresysteme oder Standardprodukte mit notwendiger Anpassungsfähigkeit an vielschichtige Kundenbedürfnisse darstellen. Noch dazu sind Änderungswünsche während der gesamten Projektlaufzeit an der Tagesordnung.

Gerade aus diesen Gründen hinkt der Vergleich von Informatik mit anderen Ingenieursdisziplinen. Beide oben genannten Faktoren muss ein Entwicklungsprozess berücksichtigen. Agile Methoden wie Scrum oder XP (Extreme Programming) gehen von der Hypothese aus, dass Änderungen bei Softwareprojekten allgegenwärtig sind. Eines der Zitate von Kent Beck, dem Schöpfer des Extreme Programming, offenbart dieses schlichte Mantra: „embrace change!“. Statt von der irrigen Annahme auszugehen, alle Anforderungen ließen sich zu Projektbeginn endgültig klären, um dann in ihrer Gesamtheit gleichzeitig und nahtlos in ein fertiges Endprodukt einzufließen, klassifizieren agile Methoden die Anforderungen nach Prioritäten und Risiken und ermitteln dazu passende Anforderungsszenarien beziehungsweise Features, deren Umsetzung inkrementell und stufenweise erfolgt, beginnend mit den Produkteigenschaften höchster Priorität beziehungsweise denen mit dem höchsten Umsetzungsrisiko. Die Realisierung jeder Eigenschaft erfolgt in fest vorgegebenen Zeiträumen von wenigen Wochen. Am Abschluss jedes Inkrements steht ein unvollständiges, aber lauffähiges Endprodukt, das die Integration aller bisherigen Inkremente repräsentiert.

Erfolgen mitten im Projekt Änderungs- und Erweiterungswünsche, lassen sich diese im weiteren Verlauf systematisch integrieren. Zwei wichtige Implikationen ergeben sich aus diesem Vorgehen. Da am Anfang jedes neuen Inkrements das Ergebnis der vorhergehenden die Ausgangsbasis darstellt, kommen Entwickler nicht umhin, an den bestehenden Softwareartefakten wie fachlichen und technischen Klassen Änderungen und Erweiterungen vorzunehmen. Damit sich dies systematisch und fehlerfrei bewerkstelligen lässt, kommt das so genannte Refaktoring zum Einsatz: das gezielte, systematische, lokale und semantikinvariante Ändern und Erweitern von bestehenden Softwarearchitekturen.

Vertrauen ist gut, Kontrolle ist besser. Diesem Leitmotiv folgend, spezifizieren Softwareentwickler beim agilen Vorgehen Bausteine anhand von Unit-Tests. Die Funktionstüchtigkeit eines Bausteins gilt erst dann als erwiesen, wenn er die ihm zugeordneten Tests erfolgreich absolviert hat. Im Anschluss an Refaktoring-Maßnahmen können Unit-Tests helfen, unerwünschte Seiteneffekte aufzudecken. Fundamentale Eigenschaften agiler Methoden wie Scrum sind übrigens ihre Schlankheit und die Abkehr vom Bürokratismus konventioneller Ansätze.

Fast unnötig zu erwähnen, dass Softwareentwickler - nicht nur bei agilen Prozessen - gute Werkzeugunterstützung benötigen, angefangen von effektiven Entwicklungs- und Testumgebungen bis hin zu einem leistungsfähigen Build- und Konfigurationsmanagement.

Den ganzen Artikel finden Sie in der Printausgabe der aktuellen iX. Ausserdem können Sie dort einen Artikel zu den sozialen Faktoren, die bei der Softwareentwicklung ein Rolle spielen, lesen -- sowie einen weiteren Artikel zu sicherer Programmierung mit C.

Mehr Infos

iX-TRACT

• Nach wie vor kommen lediglich 20 % aller Softwareprojekte zu einem erfolgreichen Abschluss. Bei den restlichen 80 % kommt es schlimmstenfalls zu einem vorzeitigen Abbruch, während der Rest Zeit- und Budgetüberschreitung oder eine unvollständige Auslieferung bedeutet.
• Da die Anforderungen an den Entwicklungsprozess differenziert sind, haben sich mittlerweile generische Prozessbaukästen etabliert, aus denen sich kundenspezifische Entwicklungsprozesse konfigurieren lassen.
• In industriellen Softwareprojekten setzen sich zunehmend hybride Ansätze durch, die agile Praktiken in Prozessrahmen wie den Rational Unified Process einbetten.
• Bei heutigen Produktzyklen ist es von Vorteil, mit Komponenten und Patterns einen Satz wiederverwendbarer Artefakte zu nutzen statt Softwaresysteme immer wieder neu entwerfen zu müssen.

(hb)