Software am Stand der Technik

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

Es gibt Situationen, wo es nicht möglich ist Software am Stand der Technik zu entwickeln bzw. zu halten. Das kann vielerlei Gründe haben - z.B. dass der Releasetermin feststeht und bekannte Mängel hinsichtlich des Standes der Technik nicht rechtzeitig beseitigt werden können, oder dass aus fachlichen Gründen Libraries verwendet werden müssen, die selbst nicht dem Stand der Technik entsprechen. Wie kann man in diesen Fällen Gewährleistungs- und Schadenersatzforderungen vermeiden? Zunächst einmal sollte geprüft werden, ob der Stand der Technik tatsächlich nicht erreicht werden kann. Releasetermine sind beispielsweise meist willkürlich festgelegt und eine Verschiebung des Termins ist mehr im Interesse des Unternehmens, als eine zeitgerechte Release einer dann mangelhaften Software. In den meisten Fällen wäre das die wirtschaftlichere Variante . Das lässt sich aber nicht in allen Fällen machen. Was dann? Muss man darauf hoffen, dass die Mängel nicht aufgedeckt werden, keinen Schaden ver