Technische Schuld, Teil 1 18.06.2018, 00:00 Uhr

Was noch (zu tun) bleibt

Um die Defizite von Projekten zu beziffern, leistet die „technische Schuld“ gute Dienste.
Bevor ein Softwareprojekt gestartet wird, sollten die Rahmenbedingungen mit allen Projektbeteiligten abgesteckt werden: Welche System- und Softwarearchitektur wird verwendet? Soll die Software mit System-, Integrations- oder Unit-Tests getestet werden? Nach welchen Richtlinien soll der Code geschrieben werden? Wie wichtig sind Usability und Laufzeitverhalten? Diese Liste der Entscheidungen ließe sich ohne Probleme weiter fortführen, so umfangreich und vielschichtig kann das Thema Softwarequalität sein. Aber wie oft haben Sie ein solches Projekt schon erlebt? Ich leider viel zu selten. Die möglichen Gründe für diese Versäumnisse sind meist ebenso zahlreich und vielschichtig wie die eingangs erwähnten Aspekte der Softwarequalität.
Während diese Versäumnisse am Anfang noch nicht besonders auffallen, zeigen sie sich meist im weiteren Projektverlauf. Wann sie zum Vorschein kommen und welchen Einfluss sie auf das Projekt haben können, hat diese Kolumne bereits erläutert [1]. Wichtig ist jedoch: Wenn das Problem vorhanden ist, muss es mit entsprechendem Aufwand wieder entfernt werden. Dieser Aufwand wird technische Schuld genannt.

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