Technische Schuld, Teil 2 16.07.2018, 00:00 Uhr

Dem Problem ein ­Preisschild geben

Die technische Schuld ist schwer zu schätzen, das Verfahren lässt sich trotzdem gut anwenden.
Der Code für ein Softwareprojekt ist schnell geschrieben und die von Kunden gewünschten Funktionalitäten sind mit minimalem Aufwand in sehr kurzer Zeit umgesetzt. Wird dabei jedoch die Qualität des Erzeugten außer Acht gelassen, entsteht im Lauf des Projekts eine Abweichung der Ist-Situation vom eigentlich zu erreichenden Soll-Zustand. Diese Abweichung wird technische Schuld (Technical Debt) genannt.
Der erste Artikel zu diesem Thema [1] hat die Grundlagen gelegt und gezeigt, was genau die absolute und die relative technische Schuld ist, und dazu noch zahlreiche mögliche Einsatzszenarien beschrieben. Diese sind ungemein hilfreich, wenn es um qualitative Entwicklung eines Softwareprojekts geht. Dieser zweite Teil von Davids Deep Dive zu diesem Thema wird nun etwas genauer darauf eingehen, wie sich diese technische Schuld messen lässt, oder besser gesagt schätzen lässt.

dotnetpro

Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde
  • 2 Monate Gratis testen
  • Über 4.000 qualifizierte Fachartikel
  • Auf jedem Gerät verfügbar