Software am Stand der Technik

Software hat sehr oft technische Schulden, in vielen Fällen eine ganze Menge davon. Vor der Abnahme bzw. Einsatz der Software sollten diese alle behoben werden, ansonsten drohen finanzielle und juristische Probleme.  Steht man aber noch nicht unmittelbar vor der Abnahme/Einsatz der Software, so gibt es eine Möglichkeit, um technische Schulden ohne nennenswerte Aufwände abzubauen. Die Lösung dafür nenne ich "Limbotanzen mit Softwarequalität": Die Basis dafür sind Quality-Gates  - Prüfungen der Software die, wenn sie nicht erfolgreich bestanden werden, zwingend zu einer unmittelbaren Beseitigung der gefundenen Mängel führen. Idealerweise werden diese Prüfungen automatisiert und verhindern auch technisch, dass vor Beseitigung der Mängel weitergearbeitet werden kann. Beispielsweise sind Pull-Requests derartige Quality-Gates, wenn 1) sichergestellt wird, dass Code nur mittels Pull-Request in den Hauptbranch gelangen kann und 2) bei diesen Pull-Requests z.B. automatisiert auch die...

Oft erkennt man erst im Laufe eines Projektes, dass der Stand der Technik auf Grund technischer Schulden nicht einhaltbar ist, was prinzipiell einsatzverhindernd wäre. Was nun? Zunächst gilt es unmittelbar darauf rechtlich korrekt zu reagieren und gemeinsam mit dem Auftraggeber einen geeigneten Kompromiss zu finden. Oft wird dabei vereinbart, dass der Stand der Technik erst nach der Inbetriebnahme der Software nachgereicht wird. Dabei stellt sich aber folgende Frage: Ist es rechtlich ok, wenn mit dem Auftraggeber vereinbart wird, bestimmte technische Schulden nicht oder erst nach der Inbetriebnahme der Software abzubauen? Prinzipiell spricht nichts gegen beliebige Vereinbarungen zwischen Auftraggeber und Auftragnehmer, solange sie nicht Gesetzen widersprechen . Beispielsweise muss sichergestellt sein, dass die technischen Schulden keinen negativen Einfluss auf die Sicherheit personenbezogener Daten haben, ansonsten wäre ein Einsatz gemäß DSGVO nicht zulässig. Darüber hinaus müssen bei...

"Technische Schulden" sind gemäß Wikipedia "eine in der Informatik gebräuchliche Metapher für die möglichen Konsequenzen schlechter technischer Umsetzung von Software." Sie beschreiben also juristisch gesehen einen versteckten Mangel, der zwar die Erfüllung der funktionalen Anforderungen nicht behindert, aber zu höheren Kosten führt und einklagbar ist . Schlechte technische Umsetzung entspricht auch  nicht dem "auf einschlägige wissenschaftlichen Erkenntnissen beruhenden Stand der Entwicklung", was Voraussetzung für den Stand der Technik wäre. Darum gilt: Software mit technischen Schulden ist mangelhaft und  nicht am Stand der Technik. Viele Informatiker werden nun einwenden, dass es eine schier endlose Zahl an möglichen technischen Schulden gibt: Software kann aus vielen tausenden Zeilen Code bestehen, es gibt Unmengen an technisch mehr oder weniger geeigneten Architekturen , Designs , Architektur- ,  Analyse- und Entwurfsmuster , Libraries und ...

Als Gerichtssachverständiger muss ich oft bewerten, ob eine Software dem Stand der Technik entspricht - ob aus technischen Gründen beispielsweise die Abnahme der Software verweigert, Nachbesserungen verlangt oder Schadenersatz gefordert werden kann. Meine Erkenntnis daraus ist: Software, auch die von den besten Mitarbeitern der renommiertesten Unternehmen, entspricht meiner Erfahrung nach in vielen Fällen nicht dem Stand der Technik. Das ist meine persönliche Einschätzung, die - da ich zumeist bei Individualsoftware und oft erst bei für den Auftraggeber offensichtlichen Problemen beigezogen werden - vielleicht nicht dem Durchschnitt von Software entspricht. Es ist also notwendig genauer darzulegen, welche Beobachtungen ich immer wieder mache, dass ich zu dieser Einschätzung komme: Einsatz ohne Einsatzfähigkeit:  Beinahe jede von mir untersuchte Software wurde ohne Wissen zu ihrer Einsatzfähigkeit in Betrieb genommen. " Die Release war für heute angekündigt ", " Alle Sto...

Wie  bereits ausgeführt  muss kommerzielle Software dem Stand der Technik entsprechen. Ansonsten drohen Gewährleisungs- und Schadenersatzkosten, die den Hersteller der Software bzw. den mit der Software beauftragten Dienstleister in den Ruin treiben könnten. Aber auch wenn der Stand der Technik aus vertraglicher Sicht nicht eingehalten werden muss, beispielsweise bei Software die nur für den internen Gebrauch bestimmt ist oder nur für freundliche Kunden (z.B. Konzernmutter oder -tochter), so sollte man überlegen, was der Stand der Technik kostet bzw. ob es sich nicht vielleicht auch da auszahlt, Software am Stand der Technik zu entwickeln bzw. zu halten. Die Frage ist also: "Was kostet der Stand der Technik" bzw. "Kostet der Stand der Technik mehr als er bringt?" bzw. "Ist es wirtschaftlich Software am Stand der Technik zu entwickeln?".  Eines der  4 Kriterien des Standes der Technik  ist die Zielgerichtetheit - der Stand der Technik ist per definitionem w...