Warum ist Softwareentwicklung in guter Qualität, in Time und in Budget so schwierig?

Jan 21, 2013 | CIO Wissen

Eigentlich sollte es einfach sein, qualitativ hochwertige Software zu entwickeln. Die Softwareentwicklungs-Technologie, -Methodik und -Werkzeuge sind in den letzten zwanzig Jahren enorm gereift. Es gab so viele schlechte Beispiele, aus denen sich lernen ließ, und Unternehmen investierten bereits – und investieren immer noch einen nicht unerheblichen Anteil – des Softwareentwicklungsbudgets in Softwarequalität. Also, warum verfehlen Softwareentwicklungsprojekte Fristen und überschreiten Budgets?
 

Zur Softwareentwicklung werden Navigationswerkzeuge benötigt

Lange Rede, kurzer Sinn: Groß angelegte Softwareentwicklung ist wie die Suche nach einer neuen Passage nach Indien im fünfzehnten Jahrhundert. Es gibt so viele Hindernisse und Einflussfaktoren, dass – wenn nicht über entsprechende Navigationswerkzeuge verfügt wird – am Ende ganz einfach die Entdeckung eines neuen Kontinents stehen kann. Obwohl dies sicherlich richtig ist, bietet dieser Blog-Post bisher nicht wirklich eine Hilfestellung dazu. Also lassen Sie uns ein wenig tiefer graben, um die Geheimnisse von Softwareentwicklungsprojekten zu entwirren.

Groß angelegte Softwareentwicklungsprojekte verhalten sich ein wenig wie die Modernisierung eines Hauses, in dem die Heizung oder die Elektroinstallationen ersetzt werden müssen. Nur wenn die Arbeiter des Bauleiters die Mauern geöffnet haben, kann dieser sicher sagen, welche Rohre, Leitungen oder Kabel neu installiert werden müssen, wie lange die Reparatur dauern wird und wie hoch die Kosten dafür sein werden. In Softwareentwicklungsprojekten stehen das Management, Projektmanager, Qualitätsmanager und Entwickler vor ähnlichen Schwierigkeiten.
 

Softwareentwicklung verlangt detailliertes Wissen des Systems

Alles, was Sie wissen wollen, ist: Was sind die Probleme, wie lange dauert die Softwareentwicklung und wie viel wird es kosten? Und, wie bei der Renovierung eines Gebäudes, arbeiten die Manager mit vielen Schätzungen und Erfahrungswerten. Es ist kein Zufall, dass hier viele Bauprojekte die ursprünglich berechneten Budgets übersteigen.

Um den Erfolg des Softwareentwicklungsprojekts oder den Betrieb der Anwendungslandschaft zu gewährleisten, benötigen deshalb alle Beteiligten dringend detaillierte Kenntnisse über das System:

  • Der CIO muss die Abteilungen davon überzeugen, Geld für die Modernisierung und Nachhaltigkeit der Anwendungen zu investieren. Dies kann durch die Sichtbarmachung technischer Risiken auch für Nicht-Techniker auffallend sichtbar erreicht werden.
  • Der Development Manager benötigt einen Überblick über die Aktivitäten seiner verteilten Entwicklungsteams und Werkzeuge, um zu überprüfen, ob die externen Lieferanten die vereinbarte Qualität liefern.
  • Auch der Qualitätsmanager braucht echtes Wissen über den Stand der Software, er muss die Punkte sehen, an denen die Software zu komplex ist und in der die kritischen Entwicklungs-Hotspots liegen, um die Software entsprechend zu testen.
  • Die Entwickler hätten gerne einen Beleg, warum es notwendig ist, in Refactorings bestimmter Module oder Softwareobjekte zu investieren.

Um einen Überblick zu bekommen verwenden Projektmanager die meiste Zeit Methoden und Werkzeuge, die vor allem eine Code-Analyse umfassen, etwa durch Berücksichtigung der Anzahl der Codezeilen oder der Komplexität eines Algorithmus.
 

Reine Code-Analyse zeigt nicht viel auf

Die große Schwäche dieses Ansatzes ist: Die Analyse des Quellcodes erlaubt nur einen selektiven Blick. Beispielsweise kann ein Qualitätsmanager nur einen Blick auf die Anzahl der Abhängigkeiten innerhalb eines Programmteils werfen, nicht über die gesamte Anwendung. Obwohl er eine Vorstellung von der Komplexität innerhalb des Moduls bekommt, kann er nicht sehen, ob diese Komplexität gerechtfertigt ist oder ob die Entwickler einfach eine schlampige Programmierung abgeliefert haben.

Darüber hinaus bedeutet ein hohes Maß an Komplexität nicht, dass Maßnahmen erforderlich sind. Um zu entscheiden, ob Maßnahmen erforderlich sind oder nicht, sind weitere Informationen und Datenquellen wie das Konfigurationsmanagement-System notwendig. So zeigt die reine Codeanalyse selbst nicht viel. Sie muss in den größeren Zusammenhang der entwickelten Anwendung gesetzt werden, die alle verfügbaren Softwareentwicklungs-Datenquellen enthält.
 

Softwarekarten in der Softwareentwicklung

Darüber hinaus sind die Informationen aus bestehenden Analyse-Tools einfach nicht „benutzerfreundlich“, schon gar nicht „Management-freundlich“ gestaltet. In vielen Fällen sind es unglaublich lange Excel-Tabellen, durch die sich aufwändig gekämmt werden muss. Um diese Mängel zu beheben und nicht im Abseits zu enden, setzen Unternehmen wie Adidas, die Deutschen Börse und Daimler auf seereneTM, die alle Daten aus dem Quellcode, der Laufzeitanalyse und den bestehenden Repositories zu einer sinnvollen Datenbasis zusammen bringt – und diese dann mit Data-Mining-Methoden analysiert.

Bereits die Kombination von Metriken für die Komplexität und die Lage der neuesten Codeänderungen führen zu wertvollen Hinweisen. Dies zeigt, in welchen Programmteilen Bugs sehr wahrscheinlich zu finden und umfangreiche Tests erforderlich sind. Um komplexere Zusammenhänge aufzudecken, können Algorithmen zur Mustererkennung eingesetzt werden. Mit diesen können die Entwickler versteckte Abhängigkeiten, beispielsweise Änderung des Moduls A führt zu einer erforderlichen Änderung des Moduls B identifizieren.

Ergebnisse wie diese können in einer Softwarekarte angezeigt werden. Die Form einer Karte ermöglicht einen vollständigen Überblick über das System. Blaue, schlanke Häuser auf der Karte stellen unproblematische Programmteile dar. Rote Türme mit Fläche weisen auf die Gefahr eines Zusammenbruchs hin. Ein rotes Gebäude stellt Programmteile von großen, monolithischen Strukturen dar, die einen hohen Grad an Komplexität mit sich bringen und häufig geändert werden.

Eine Sammlung von Gebäuden in einem Bezirk ist ein Modul. Dies erlaubt es, Risiken und Hindernisse sehr früh zu erkennen, bevor sie zu Hochhäusern werden. Ein Projektmanager kann auf einen Blick sehen, wie viel Aufwand notwendig ist, um das Modul zu reparieren, oder ob es sich lohnt, diesen Bereich zu zerstören und wieder vollständig durch Refactorings aufzubauen. Alle Hotspots kennend, können Qualitätsmanager Tester auf die kritischen Punkte lenken und damit sicherstellen, dass das Projekt nicht aus dem Ruder läuft.

Pin It on Pinterest