Softwarequalität und technische Schulden - In vielen Zusammenhängen, vom Quellcode eines Systems bis hin zur IT-Landschaft eines Großkonzerns, taucht der Begriff der technischen Schulden auf. Hinter dessen Vielgestaltigkeit steckt die Komplexität von Softwarequalität. (Artikel von Matthias.Kraaz(at)zuehlke.com) iX 9/2012 Kontakt: http://xing.to/kraaz
Unter dem Druck eines nahenden Re-lease-Termins implementieren Ent-wickler Features zeitweise schnel-
ler als gewöhnlich, indem sie auf guteAngewohnheiten wie Unit Tests, Kom-mentierung, Refaktorisierung et ceteraverzichten. Das kann den Eindruck erwe-cken, dass die ursprüngliche Schätzungdes Zeitaufwands durch das Team höherals nötig war.
Um dieses Bild zu korrigieren, hatWard Cunningham den Begriff der tech-nischen Schulden (technical debt) einge-führt: Entwickler haben den gewünschtenFunktionsumfang nicht mit weniger Auf-wand bekommen – sie haben einen Kre-dit aufgenommen und von diesem den
vollen Preis für die Features bezahlt. Die-sen Kredit müssen sie aber so schnellwie möglich zurückzahlen, sonst entste-hen hohe Zinsen (siehe Onlinequellen[a]). Mittlerweile ist der Begriff verbrei-tet und benennt allgemein eine Abwei-chung von der geforderten Softwarequa-lität, deren Nicht-Beseitigung Kostenverursacht.
Vom Kostentreiber zur Hypothek
Technische Schulden finden vermehrtBeachtung als Kostentreiber. Der aktu-elle CRASH-Report des CAST Research
Labs [b] schätzt die Kosten zur Besei -tigung der technischen Schulden aufdurchschnittlich 3,61ˇUS-$ pro Code -zeile – daraus ergibt sich eine Hypothekvon gut 1ˇMillion Dollar für eine Appli-kation von 300ˇ000 Codezeilen.
Kosten entstehen durch Abweichungen
Der Standard ISO/IECˇ25010:2011 [c]definiert Softwarequalität als den Erfül-lungsgrad ausdrücklich spezifizierter,aber auch unausgesprochener Anforde-rungen der Stakeholder. Ein Qualitäts-modell macht diese abstrakte Definitionanwendbar. Es definiert eine Auswahlrelevanter Qualitätsmerkmale wie Wart-
barkeit, Sicherheit, Benutzbarkeit oderBenutzerzufriedenheit. Diese Ei-
genschaften werden so lange inTeilmerkmale zerlegt, bis dieser
Vorgang zu direkt messbaren Quali-tätseigenschaften führt, sich also eine
Metrik für die Messung angeben lässt.Ein Qualitätsmodell definiert also eineauf Metriken aufbauende Hierarchie vonMerkmalen und macht so Softwarequa-lität messbar (siehe Abbildungˇ1).
Für verschiedene Zwecke gibt es unter-schiedliche Qualitätsmodelle. ISOˇ25010definiert zwei: eins für die Produkt- undeins für die Nutzungsqualität. Ersteresetzt sich auf oberster Ebene aus denQualitätsmerkmalen funktionale Eig-nung, Effizienz, Kompatibilität, Benutz-barkeit, Zuverlässigkeit, Sicherheit, Wart-barkeit und Übertragbarkeit zusammen.Das Modell betrachtet also Eigenschaf-ten der Software, sowohl interne wie dieWartbarkeit des Quellcodes als auch vonaußen sichtbare wie die Effizienz.
Die Nutzungsqualität hingegen setztden Fokus darauf, welchen Wert dieSoftware für die Nutzer hat. Auf obers-ter Ebene stehen die QualitätsmerkmaleEffektivität, Effizienz, Benutzerzufrie-denheit, Risikofreiheit und Abdeckungder Nutzungsumgebungen. Bei unpassen-der Umgebung oder aufgrund des verän-derten Fokus kann trotz hervorragenderProduktqualität die Nutzungsqualität un-genügend sein.
ISOˇ25012 [d] bietet ein weiteres Mo-dell für Datenqualität, Modelle für Code-qualität finden weiter unten Erwähnung.
Für jedes der genannten Merkmalelassen sich zahlreiche Beispiele nennen,wie durch eine Abweichung von der ge-forderten Qualität Kosten entstehen: –ˇUnzureichende Wartbarkeit verteuertÄnderungen. Sie verursachen einen hö-heren Aufwand, und Entwickler machen
!" iX #/"$%"
REPORT | SOFTWAREPROJEKTE
Softwarequalität und technische Schulden
Vorsicht, Zinsen!Matthias Kraaz
In vielen Zusammenhängen, vom Quellcode eines Systems bishin zur IT-Landschaft eines Großkonzerns, taucht der Begriffder technischen Schulden auf. Hinter dessen Vielgestaltigkeitsteckt die Komplexität von Softwarequalität.
bei ihrer Umsetzung mehr Fehler. Ab ei-ner kritischen Schwelle löst jede Modi-fikation am System eine Lawine vonFehlern aus, die Kosten steigen ins Un-ermessliche.–ˇSchlechte Benutzbarkeit erhöht denAufwand für die Anwender und erzeugtKosten für den Support.–ˇAufgrund mangelnder Effizienz ent-stehen Kosten für mehr CPU-Leistungoder Speicherplatz.–ˇNach einem erfolgreichen Einbruchüber Sicherheitslücken muss die Soft-ware verbessert werden. Zudem gehenwährend der Stilllegung Umsätze ver -loren und Ausgleichszahlungen an dieNutzer werden fällig.
Bei der Betrachtung einer IT-Land-schaft tritt die Produktqualität der einzel-nen Systeme in den Hintergrund. Statt-dessen rücken die Nutzungsqualität derAnwendungen sowie die Produktqualitätdes Gesamtsystems in den Fokus:–ˇEine Anwendung wird mit einer Mes-saging-Middleware realisiert. Die Pro-duktqualität ist hervorragend. Als einzigeihrer Art in der IT-Landschaft verursachtsie jedoch unverhältnismäßig hohe Li-zenzkosten und erfordert den Aufbau zu-sätzlicher Kompetenzen im Rechen -zentrum. Effizienz und Benutzbarkeit imSinne der Nutzungsqualität sind unge -nügend. –ˇDie einzelnen Anwendungen haben fürsich genommen eine gute Produktqua -lität. Sie bilden jedoch miteinander diemaximale Menge von n2-n Schnitt -stellen, das Gesamtsystem ist schlechtwartbar.
Wie man technische Schulden aufnimmt
Ein Projektteam kann technische Schul-den ganz bewusst und aus gutem Grundeaufnehmen, um es schneller auf denMarkt zu bringen oder zeitweise Entwick-lungskosten zu senken. Weniger gut be-gründet ist das bewusste Ignorieren vonBest Practices oder Unternehmensstan-
dards, weil man schlichtweg die Vorteileihrer Einhaltung nicht einsehen möchte.
Die bewusste Entscheidung zur Auf-nahme technischer Schulden kann aufder einen Ebene einer Organisation be-kannt und gleichzeitig auf anderen Ebe-nen unbekannt sein oder dort auf hef -tigen Widerstand stoßen. Beispiele sindder Verstoß gegen die IT-Governance(siehe unten) durch einen Abteilungslei-ter, der stattdessen seine eigenen Zieleverfolgt, oder die heimliche Aufnahmetechnischer Schulden, um Abgabeter -mine halten zu können.
Softwarequalität als treibender Faktor
Auch unbewusst können Entwicklertechnische Schulden aufnehmen, zumBeispiel weil sie Best Practices oder Un-ternehmensstandards nicht kennen odersich nicht überwachte Qualitätsmerk maleschleichend verschlechtern. Die Fusionvon Firmen durch die Kombi nation meh-rerer IT-Landschaften kann ebenfalls zutechnischen Schulden führen – ob nunbewusst oder unbewusst. Große Konzer-ne, die viele Zukäufe tätigen, kämpfenpermanent mit der Homogenisierung undIntegration ihrer IT-Systeme. Weitere Ur-sachen sind beispielsweise der Kauf einesOff-The- Shelf- Produkts oder eine nachaußen vergebene Entwicklung.
Während der Softwareentwicklungtritt wohl am häufigsten die schleichen-de Verschlechterung nicht überwachter
iX 9/2012 83
Qualitätsmerkmal Qualitätsmerkmal
Index IndexIndex
Metrik Metrik Metrik Metrik
Qualitätsmodelle leiten Qualitätsmerk-male von direkt messbaren Eigenschaf-ten (Metriken) ab, optional über Unter-merkmale oder Indizes (Abb.ˇ1).
x-TRACT� Der Begriff der technischen Schulden bezeichnet Abwei chungen von der
geforderten Softwarequalität, durch die Kosten entstehen.
� Um diese Schulden zu beseitigen, muss man Softwarequalität messen; verschiedene Qualitätsmodelle können Entwickler dabei unterstützen.
� Mit Werkzeugen lässt sich zudem die Codebasis kontinuierlich überwachen, um technische Schulden möglichst gar nicht erst entstehen zu lassen.
Qualitätsmerkmale sowie die bewussteAufnahme technischer Schulden zwecksEinhaltung von Abgabeterminen auf. Oft-mals sind dem Projektteam diese Schul-den zuerst bewusst, dem Sponsor derEntwicklung hingegen zunächst unbe-kannt oder nicht verständlich.
Technische Schulden definieren sichüber die Anforderungen an die Soft-warequalität. Je nach Lage der Anforde-rungen kann dieselbe Software unter-schiedlich stark belastet sein. Senkt mandie Anforderungen, werden aus Kosten,die daraus entstehen, dass man Mängelnicht beseitigt, akzeptierte Gesamtbe-triebskosten (Total Costs of Ownership)und umgekehrt.
Die Ermittlung der Anforderungenbirgt im schlimmsten Fall die ganzeKomplexität des Requirements Enginee-ring nichtfunktionaler Anforderungen: –ˇdie Aufdeckung von Lücken, etwa auf-grund unausgesprochener Erwartungen,–ˇdas Identifizieren widersprüchlicherAnforderungen inklusive der Analyseund Auflösung von Kompromissen (sie-he auch die Architecture Tradeoff Ana-lysis Method der Carnegie-Mellon-Uni-versität [e]) sowie die–ˇAuflösung von Interessenskonfliktenzwischen den Beteiligten.
Im Falle einer IT-Landschaft gehörenzu den Beteiligten nicht nur die direktenBenutzer der Software, sondern auch dasmit ihrem Betrieb betraute Personal imRechenzentrum sowie alle verantwort -lichen Entscheidungsträger. Eine voll-ständige und messbare Spezifikation derAnforderungen an die Softwarequalitätfindet man daher selten.
Stattdessen muss man sich gemein-sam an die Anforderungen herantasten,die den teilweise unausgesprochenen Er-wartungen aller Beteiligten am ehestenentsprechen. Während der Entwicklung
beispielsweise gilt es, allmählich das rich-tige Maß für Testabdeckung, Kommen-tierung, Verständlichkeit des Codes undso weiter zu finden, das den gewünschtenAusgleich zwischen Kosten, Entwick-lungsgeschwindigkeit, Fehlerhäufigkeit etcetera schafft. Domänenspezifisch kön-nen konkrete Mindestanforderungen andie Softwarequalität in Form regulatori-scher Vorgaben existieren, zum Beispielbezüglich der Testabdeckung gemäß derRTCA-Empfehlung DO-178C [f].
Die Bewertung und Verbesserung derSoftwarequalität ist der analytischenQualitätssicherung zuzurechnen. Kon-struktive Qualitätssicherung setzt an, bevor technische Schulden entstehen.Durch Weiterbildung und Coaching wer-den Mitarbeiter unterstützt, bessere Ent-scheidungen zu treffen und technischeSchulden nicht aus Unwissenheit aufzu-nehmen. Eine IT-Governance [g] definiertdie Verantwortlichkeit für die strategischeWeiterentwicklung der IT und legt damitfest, wer für Entscheidungen über dieAufnahme und Beseitigung technischerSchulden auf der Ebene der gesamtenIT-Landschaft zuständig ist.
Umdefinieren kann Schulden verstecken
Nur wenn sowohl die Kosten, die ent -stehen, wenn man technische Schuldenbeseitigt, als auch die, wenn man diesunterlässt, bekannt sind, können die Ver-antwortlichen eine informierte Entschei-dung treffen, ob und wie schnell einProjektteam technische Schulden ab-bauen muss. Diese Entscheidung stehtüblicherweise dem Sponsor der Ent-wicklung zu. Er hat dabei nicht nur dieobigen Kosten im Blick, sondern auchsonstige sich ergebende wirtschaftliche
Vor- und Nachteile (siehe David Chap-pell [h]).
Auf Basis bekannter Kosten kann derSponsor sowohl die expliziten als auchdie angenommenen Anforderungen andie Softwarequalität nach unten oderoben verändern. Durch eine Senkung dergeforderten Qualität kann er technischeSchulden wegdefinieren. Die Folgekostenverschwinden dadurch natürlich nicht.Aus den zu vermeidenden Kosten dertechnischen Schulden werden schlichtwegakzeptierte Kosten im Laufe des normalenSoftware-Lebenszyklus.
Bei der Abschätzung der Kosten, diedurch Beseitigung und Nicht-Beseiti-gung entstehen, kann es nicht um einen100%ig korrekten Wert gehen. Wichti-ger ist, die richtige Größenordnung zutreffen und das Vorgehen bei der Be-rechnung und den Schätzfehler offenzu-legen, um so zu erreichen, dass der Spon-sor der Kostenschätzung vertraut. DieBerechnung der Beseitigungskosten istein übliches Verfahren. Eine relativ neueForderung aus der agilen Communityhingegen ist es, auch die Kosten zu be-rücksichtigen, die sich ergeben, wennman die technische Schulden nicht be-seitigt. Dieser Zustand wird als Moneta-risierung der technischen Schulden be-zeichnet (siehe dazu Isral Gat [i]).
Viele Fragen, die sich bei der Pflegevon IT-Landschaften stellen, sind ver-klausulierte Aufforderungen zur Mone-tarisierung der technischen Schulden.Zum Beispiel: „Können wir noch zweiJahre mit der Ablösung dieses Systemswarten?“ Hier geht es darum, die Kostenzu schätzen, die in den nächsten zweiJahren aufgrund der Qualitätsproblemevoraussichtlich entstehen werden. Oder:„Sollten wir dieses System weiterpfle-gen oder ablösen?“ Diese Frage lässtsich ebenfalls durch eine Schätzung dererhöhten Pflegekosten und dem Ver-gleich mit dem pekuniären Aufwand fürdie Neuentwicklung beantworten.
Qualitätsmodelle als Spürhunde im Code
Als der Begriff der technischen Schul-den geprägt wurde, kam gleichzeitig dieEmpfehlung auf, eine Liste zu führen, inder jede Abweichung vermerkt wird. Andieser Liste sollte sich die Höhe dertechnischen Schulden ablesen lassen.Aufgrund der vielfältigen Modalitätenbei der Aufnahme solcher Schulden isteine derartige Liste meistens nicht ver-fügbar. Stattdessen muss ein Projekt-team Abweichungen von der geforderten
!' iX #/"$%"
REPORT | SOFTWAREPROJEKTE
Qualitätsmanagement-Werkzeuge wie Sonar geben schnell einen Überblick über dietechnischen Schulden (Abb.ˇ2).
Softwarequalität im Nachhinein identifi-zieren, beispielsweise mit Reviews. Ge-genstand eines Review kann Quellcode,ein Dokument zur Softwarearchitekturoder die Beschreibung einer IT-Land-schaft sein.
Für die Codebasis eines einzelnenSystems, also vor allem während derSoftwareentwicklung, ist eine Analysemit Qualitätsmanagement-Werkzeugenwie Sonar [j] genauer, aktueller undvollständiger als die manuelle. Anhandobjektiver Metriken prüft das Tool diegesamte Codebasis. So kann es nichtpassieren, dass ausreichend guter Codeversehentlich auf der Liste landet oderder Prüfer Abweichungen übersieht. DieErgebnisse der Analyse werden aggre-giert, sodass sofort die Gesamtgröße dertechnischen Schulden ersichtlich ist(Abbildungˇ2). Per Drill-down lässt sichschnell herausfinden, welche Codeteilein besonderem Maße zu den technischenSchulden beitragen.
Manuelle Ergänzungen des Automatismus
Eine manuell gepflegte Liste kann alsErgänzung der automatischen Analysedienen, da sich manche Abweichungenautomatisiert nur schwer finden lassen.Zudem kann man das Ergebnis der auto-matischen Analyse durch den Vergleichmit der Liste auf Plausibilität prüfen.
Um aus der riesigen Zahl von Metri-ken, die ein solches Werkzeug messenkann, die Codequalität abzuleiten, benö-tigt man wieder ein Modell. Die Kombi-nation von Metriken zu Qualitätsmerk-malen erleichtert auch das Aufspürenvon Hot Spots, also besonders schlech-ten Codeteilen. Ein Modell ermöglichtaußerdem eine weitere Art von Drill-
down: Der Tester kann Abweichungenvon der geforderten Softwarequalitätentlang der Hierarchie von Qualitätsin-dizes auf die Verletzung einer Metrik zu-rückverfolgen, anstatt sich entlang derCodestruktur zu bewegen. Beide Metho-den des Drill-down lassen sich kombi-nieren.
Im Folgenden wird als Beispiel dasQualitätsmodell SQALE (Software Qua-lity Assessment based on Lifecycle Ex-pectations, [k]) betrachtet, das dabei un-terstützt,– genau zu beschreiben, worin die tech-nischen Schulden besteht, und– sowohl die Kosten für deren Beseiti-gung– als auch die für ihre Nicht-Beseitigungzu berechnen.
SQALE hat den Anspruch, möglichstobjektiv, genau, reproduzierbar und vorallem automatisierbar zu sein. Die Be-wertung von Code gemäß dem Quali-tätsmodell soll vollständig über ein Pro-gramm erfolgen. Das Modell betrachtetauf oberster Ebene folgende Merkmale:Wiederverwendbarkeit, Übertragbarkeit,Wartbarkeit, Sicherheit, Effizienz, Än-derbarkeit, Zuverlässigkeit und Testbar-keit. Mittlerweile implementieren meh-rere Produkte SQALE, beispielsweisegibt es auch ein Plug-in für Sonar.
Wartbarkeit ist nur eins der Qualitätsmerkmale
Weitere Modelle für Codequalität sowieentsprechende Produkte stehen unter an-derem mit SQUALE (Software QualityEnhancement) [l] und Qualixo [m] zurVerfügung. Das SQUALE-Projekt stelltneben dem Qualitätsmodell eine Open-Source-Implementierung für verschiede-ne Programmiersprachen bereit.
iX 9/2012 85
SQALE sieht auch die automatisierte Berechnung der Kosten zur Beseitigung dertechnischen Schulden vor, hier am Beispiel von Sonar (Abb.ˇ3).
In der Praxis wird Codequalität gernemit guter Wartbarkeit gleichgesetzt. Die-se Einschränkung auf ein Qualitätsmerk-mal verengt den Fokus – meist ungewolltund mit dem Resultat, dass man Mängelim Code übersieht. Teilweise werdenauch beliebige unerledigte Aufgaben dentechnischen Schulden zugerechnet. So-fern diese die Softwarequalität nicht be-rühren, entstehen dem Unternehmenaber keine Kosten durch ihre Nicht-Be-seitigung – es werden keine „Zinsen“fällig. Gleichermaßen entsprechen Ab-weichungen von dem, was individuelleEntwickler als ästhetisch empfinden,per se nicht den Kriterien für technischeSchulden.
Kosten der Schulden automatisiert berechnen
Sobald die Bewertung der Softwarequa-lität vollständig automatisiert ist, lässtsie sich beliebig oft durchführen. Damitkann man jede Verschlechterung sofortfeststellen, auf ihre Ursache zurückver-folgen und – falls ungewollt – korrigie-ren. Für diese permanente Überwachunghat sich in Anlehnung an Continuous In-tegration der Begriff Continuous Inspec -
tion eingebürgert. Continuous Inspectionsollte ein Qualitätsmodell wie SQALEverwenden, um die gemessenen Metri-ken nicht nur über die Codestruktur,sondern auch zu übergeordneten Quali-tätsmerkmalen zu aggregieren.
SQALE sieht die automatisierte Be-rechnung der Kosten zur Beseitigungder technischen Schulden vor. DieseKosten ergeben sich aus der Menge derAbweichungen und dem anfallendenAufwand, um eine einzelne zu beseiti-gen, beispielsweise die zu niedrige Test-abdeckung einer Klasse oder die zu hoheKomplexität einer Funktion.
Dazu muss der Anwender zu jeder Artvon Abweichung eine Funktion festlegen,die in jedem Einzelfall die Kosten ermit-telt, die bei ihrer Beseitigung entstehen.Eine solche Funktion kann auch denKontext der Abweichung berücksichti-gen. Beispiele sind Funktionen zum Be-rechnen der Kosten, die beim Entferneneiner duplizierten Zeile anfallen, oder dieein Unit Test verursacht, wenn er um einenoch nicht abgedeckte Bedingung erwei-tert wird. Meistens reicht ein simplerFaktor als Funktion. Dafür sind Richt-werte verfügbar, die in der Regel bereitsgute Ergebnisse liefern. Eine allmählicheAnpassung an die eigenen Entwicklungs-
bedingungen lohnt sich dennoch (sieheErik Hegemann [n]).
SQALE wendet die entsprechendeKostenfunktion auf alle Abweichungenan. Beispielsweise wird die Gesamtzahlaller duplizierten Zeilen sowie die An-zahl aller nicht abgedeckten Bedingun-gen mit dem jeweiligen Faktor multipli-ziert. Die Summe der Ergebnisse ergibtden Gesamtaufwand für die Beseitigungder technischen Schulden (siehe Abbil-dungˇ3).
Wird eine Abweichung von der gefor-derten Softwarequalität nicht beseitigt,verursacht sie Kosten. Die Wirkung einerAbweichung ist stark kontextabhängig. Je nach Art der Software und Situation der Entwicklung und des Unternehmens können beispielsweise Sicherheitslücken,reduzierte Wartbarkeit und schlechte Ef -fizienz unterschiedlich hohe Kosten ver-ursachen. Die durch reduzierte Wart -barkeit anfallenden beispielsweise lassensich abschätzen, wenn man erfahrene Ent-wicklern nach dem Faktor fragt, um dender Aufwand für Änderungen durch dietechnischen Schulden gestiegen ist. Alter-nativ kann man die optimistischen Schät-zungen weniger erfahrener Entwickler mitdem tatsächlichen Aufwand für Änderun-gen plus nachfolgenden Bug Fixes ver-gleichen. Je nach Qualitätsmerkmal ist eine Schätzung der Kosten schwierig, be-sonders dann, wenn in einer IT-Land-schaft die Auswirkung auf andere Anwen-dungen beachtet werden muss.
Beseitigen oder nicht beseitigen
Seit der Version 1.0 berechnet SQALEdie Kosten der Nicht-Beseitigung analogzu denen, die bei der Beseitigung anfal-len. Auch in diesem Fall definiert derQualitätsprüfer für jede Art von Abwei-chung eine Funktion, die in diesem Fallaber die Kosten der Nicht-Beseitigung er-mittelt. Diese Kostenfunktionen werdenauf alle entsprechenden Abweichungenangewendet. Die Summer der einzelnenErgebnisse ergibt die Gesamtkosten dertechnischen Schulden.
Abzuschätzen, wie sich eine nicht be-seitigte Abweichung auswirkt, wirddurch SQALE nicht einfacher, sonderndurch die obligatorische Kostenfunktioneher schwieriger. Da die Wirkung tech-nischer Schulden stark kontextabhängigist, kann es keine übertragbaren Richt-werte für diese Funktionen geben. DerLohn für die Mühe besteht in der auto-matisierten Berechnung der anfallendenKosten.
!) iX #/"$%"
REPORT | SOFTWAREPROJEKTE
[a] Ward Cunningham et al.; Technical Debtc".com/cgi/wiki?TechnicalDebt
[b] CAST Research Labs; The Crash Report"$%%/"$%"www.castsoftware.com/resources/cast-research-labs
[c] ISO/IEC "($%$:"$%%; Systems and soft-ware engineering – Systems and softwareQuality Requirements and Evaluation(SQuaRE) – System and software qualitymodelswww.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=&(*&&
[d] ISO/IEC "($%":"$$!; Software engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Data quality modelwww.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=&(*&)
[e] Software Engineering Institute Carnegie Mellon; Architecture Tradeoff Analysis Methodwww.sei.cmu.edu/architecture/tools/evaluate/atam.cfm
[f] RTCA; DO-%*!C; Software Considerations in Airborne Systems and Equipment Certificationwww.rtca.org/
[h] David Chappell; The Three Aspects of Software Qualitydavidchappell.com/writing/white_papers/The_Three_Aspects_of_Software_Quality_v%.$-Chappell.pdf
[i] Israel Gat; Technical Debt on Your Balance Sheettheagileexecutive.com/"$$#/$#/"#/technical-debt-on-your-balance-sheet/
[j] Sonarsonarsource.org
[k] SQALE (Software Quality Assessment based on Lifecycle Expectations)sqale.org
Möchte man die Ergebnisse vonSQALE nur verwenden, um die Besei-tigung von Abweichungen nach ihrerWirkung zu priorisieren, kann man sichdie Sache erleichtern. Dann reicht esaus, wenn die Kostenfunktionen Ver-hältniszahlen statt absoluter Werte lie-fern.
Der zügigste Abbau technischerSchulden erfolgt, wenn sich das gesamte Entwicklungsteam für eine bestimmteZeitdauer auf deren Beseitigung konzen-triert. Vorab sollte das Team die konkre-ten Maßnahmen und die Zielwerte fürdie zu verbessernden Metriken festlegenund priori sieren, am besten anhand einerautomatischen Analyse der Codebasis,damit es keinen Aufwand auf wenigerwichtige Abweichungen oder auf dieÜbererfüllung der Qualitätsanforderungenverschwendet. Die Priorisierung sollteentsprechend den Kosten der Nicht-Be-seitigung erfolgen.
Verbietet der Zeitdruck diesen Mo-dus, ist die punktuelle Verbesserung derSoftwarequalität im Zuge einer vorzu-nehmenden Änderung eine beliebte Al-ternative: Zunächst weitet man die Test-abdeckung aus und refaktorisiert denCode, bevor man sich der Modifikationselbst zuwendet. Dieses Vorgehen hatden Charme, dass es genau dort techni-sche Schulden beseitigt, wo sich die re-duzierte Wartbarkeit am ehesten aus-wirkt.
Schulden tilgen oder neu entwickeln
Ein anderer Weg, technische Schuldenloszuwerden, ist, die alte Software zu ver-werfen und durch eine Neuentwicklungzu ersetzen. Wie bei einer Währungsre-form geht zwar das gesamte Vermögen(die alte Software) verloren, gleichzeitigverschwinden aber auch die (technischen)Schulden. Vor dieser Entscheidung soll-te man die technischen Schulden be-rechnen und sie den geschätzten Kostenfür die Neuentwicklung gegenüberstel-len.
Im Vorfeld der geplanten Ablösungeines Systems kann die Softwarequalitätgeplant vernachlässigt werden, um Kos-ten zu sparen. Verzögert sich die Ablö-sung jedoch, muss das Team am Endeüber viele Jahre ein System pflegen,dessen Qualität es systematisch ver-nachlässigt hat – mit den anfallendenZusatzkosten. Die schlechte Software-qualität des Altsystems holt das Teamauch dann ganz schnell wieder ein,wenn es Anforderungen per Reverse
Engineering aus diesem System gewin-nen oder Teile des alten Codes wieder-verwenden soll.
Fazit
Als technische Schulden bezeichnet manKosten verursachende Abweichungen vonder geforderten Softwarequalität. Sowohldie Kosten für deren Beseitigung als auchdie von den Abweichungen verursachtenKosten muss ein Entwicklerteam bezif-fern, um fundiert über die Beseitigungtechnischer Schulden entscheiden zukönnen.
Die Operationalisierung von Soft-warequalität erfolgt durch ein Qualitäts-modell, dessen Wahl vom Fokus der Be-trachtung abhängt. ISOˇ25010 definiertzwei Modelle für Produkt- und Nut-zungsqualität. Für das Assessment einerIT-Landschaft stehen diese beiden Grö-ßen des Gesamtsystems zusammen imVordergrund, während der Entwicklungliegt das Augenmerk eher auf der Pro-duktqualität der Einzelanwendung. DasQualitätsmodell SQALE ermöglicht dieautomatisierte Messung der Qualität ei-ner Codebasis und unterstützt eine trans-parente und nachvollziehbare Kostenbe-rechnung.
Vor dem Abbau technischer Schuldensollte ein Team die durchzuführendenMaßnahmen sowie Zielwerte für die zuverbessernden Metriken sorgfältig defi-nieren. Mit dem einmaligen Abbau tech-nischer Schulden ist es aber nicht getan.Tools wie Sonar helfen dabei, die Qua-lität der gesamten Codebasis permanentzu überwachen und so Continuous In-spection umzusetzen.
Leider kann man sich auf der Stabili-tät der Softwarequalität nicht zu langeausruhen: Wie so oft in der Softwareent-wicklung fällt ein stillstehendes Teamgegenüber dem sich weiterentwickeln-den Stand der Technik permanent zu-rück. Und auch wenn die Continuous In-spection grünes Licht gibt, sollte manweiter auf Ausschläge in der WTF-Met-rik [o] achten. (ka)
Matthias Kraaz
arbeitet bei der Zühlke Engineering GmbHals Lead Software Architect. Seine Spezialgebiete sind Konstruktion undTest sicherheitskritischer und einge -betteter Systeme.
