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.
Jetzt 1 Monat kostenlos testen!
Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde.
- + Digitales Kundenkonto,
- + Zugriff auf das digitale Heft,
- + Zugang zum digitalen Heftarchiv,
- + Auf Wunsch: Weekly Newsletter,
- + Sämtliche Codebeispiele im digitalen Heftarchiv verfügbar