 |
| aus Tom DeMarco: "Controlling Software Projects"  Sebastian Dietrich |
Funktionierende Software != Geringe Wartungskosten.
Das gilt leider für Software genauso wie für Autos, Häuser, etc. Nur weil etwas zum Zeitpunkt der Inbetriebnahme vollständig den damaligen Anforderungen entsprach, heißt das nicht, dass das für die gesamte Lebensdauer auch Gültigkeit hat. Unter die Wartungskosten fallen nämlich nicht nur korrektive Maßnahmen wie Fehlerbeseitigung, sondern auch insbesondere die Adaptive Wartung, nämlich die Anpassung der Software an sich verändernde technische und juristische Rahmenbedingungen. Software kann also 100% fehlerfrei sein und dennoch enorme Wartungskosten verschlingen.
Wartungskosten sind indirekt proportional zur Wartbarkeit einer Software. Die Wartbarkeit einer Software ergibt sich größtenteils aus der technischen Qualität der Software, also der Qualität der Architektur, des technischen Designs und des Codes. Spaghetticode beispielsweise ist unleserlich - eine einzige Zeile Code zu ändern kann schon mal Tage in Anspruch nehmen (mein persönlicher Rekord liegt bei 3 Wochen um eine einzige Methode zu verstehen - diese war ausgedruckt mehr als 30 Meter lang).
 |
| Pressman: "Software Engineering" Sebastian Dietrich |
Geringe Wartbarkeit = Hohe Wartungskosten UND hohe Weiterentwicklungskosten. In den meisten Fällen wird eine Software im Laufe ihres Produktiveinsatzes noch laufend um zusätzliche Funktionalitäten erweitert. Ist die Wartbarkeit gering, so steigen nicht nur die Kosten für die Wartung, sondern auch die Kosten für die Weiterentwicklung - lt. Pressman auf das 10 bis 66 fache der Entwicklungskosten.
Wie aber erreicht man eine hohe Wartbarkeit? Dokumentation ist das einzige, was den meisten Managern dazu einfällt. In der Praxis jedoch ist Dokumentation meist wertlos, da sie fast immer veraltet ist, zumeist schlecht geschrieben und daher in den wenigsten Fällen gelesen wird. Metriken sagen andere, jedoch sind auch Metriken in der Praxis zumeist wertlos, da sie zwar gemessen werden, aber von sich aus keine Konsequenzen haben.
Wer hohe Wartbarkeit sicherstellen möchte, der muss unumgehbare Hürden in den Softwareentstehungsprozess einbauen. Diese Hürden ("Quality Gates" genannt) sind Metriken, die bei Nicht-Erreichung den Build-Prozess fehlschlagen lassen. Wird beispielsweise die Architektur nicht eingehalten, so erkennt das ein Tool am Continuous Integration Server und bricht den Build ab. Kein Build à keine Auslieferung.
Welche Quality Gates sichern eine hohe Wartbarkeit? Es gibt eine große Menge an Architektur-, Design-, Code- und Testmetriken für die man alle Quality Gates einführen könnte. Nicht alle sind in jedem Softwareentwicklungsprojekt geeignet. Quality Gates bei Java Entwicklung behandelt das Thema, welche davon die geeignetsten sind, und wie man sie bestmöglich sicherstellt.
P.S. Dazu eine Literaturempfehlung: Tom deMarco: "Warum ist Software so teuer?... und andere Rätsel des Informationszeitalters"
Ich finde es schön, daß die "Größe" einer Methode nicht in LoC gemessen wurde, sondern in Metern (!) ... :)
AntwortenLöschenWas ist mit Projekten, die nicht in Java (oder C oder einer anderen zu compilierenden Sprache) geschrieben wurden? Dort wo es also keinen Build Prozess gibt, weil nicht ausgeliefert werden muss?
AntwortenLöschenDort gilt dasselbe. Die Entwicklungskosten steigen laufend, die Wartung ist kaum bezahlbar. Build Prozess gibt es überall (auch wenn der im schlechtesten Fall nur aus einem lokalen Compiler besteht). Quality Gates kann man daher überall und in allen Programmiersprachen einbauen - und tut gut daran es auch zu machen.
AntwortenLöschen