Software am Stand der Technik

Künstliche Intelligenz (KI) bzw. Artificial Intelligence (AI) ist derzeit in aller Munde. Auch wenn das erste Interesse an ChatGPT , Dall-E , Midjourney , Copilot ,  Fireflies oder Superhuman - um nur ein paar bekannte zu nennen - inzwischen schon merkbar abgeflaut ist und lt. Gartner Hype Cycle noch vielen KI Technologien das Tal der Tränen erst bevorsteht. Dennoch ist eine Zukunft ohne massive und disruptive Änderungen durch KI undenkbar. Dementsprechend oft wird für neue oder bestehende Software gefordert, dass diese KI Funktionalitäten enthalte, um z.B. einen Teil der Aufgaben der Benutzer zu übernehmen. Doch was kaum wer bedenkt: Sind KI Funktionalitäten auch legal und Stand der Technik? Zunächst müssen bei der Betrachtung der Legalität von KI die oft bespochenen Urheberrechtsfragen geklärt werden. Dazu zählen insbesondere die folgenden 3 Fragen: Nutzungsrecht der Trainingsdaten: Dürfen die für das Training der KI verwendeten Daten auch dafür genutzt werden? ...

Nicht immer kann eine Software von denselben Personen und Unternehmen über ihre gesamte Lebenszeit betreut werden - oft findet sogar ein Wechsel bereits während der Umsetzungsphase statt. Übernahmen sind bei Software juristisch problematisch und alles andere als einfach oder günstig. Es benötigt viel diesbezügliche Erfahrung, damit es auch möglichst effizient und effektiv umgesetzt wird: Oft wird hier zwischen freundlicher und feindlicher Übernahme unterschieden , je nachdem ob der bisherige Auftragnehmer die Übernahme involviert wird und sogar aktiv unterstützt oder eben nicht bzw. nichts davon mitbekommen darf, weil befürchtet wird, dass er aktiv gegen die Übernahme arbeiten könnte. Solange nur alle Artefakte (insbesondere Sourcecode und Dokumentation) historisch gesichert werden, ist auch eine feindliche Übernahme bei Software möglich. → Der Auftraggeber sollte vor einer Übernahme sicherstellen, dass alle Artefakte der Software (wie auch üblich) in einem Repository gesichert sind ...

Auch der beste Wartungsvertrag kann nicht verhindern, dass die Wartung vorzeitig eingestellt wird . Sei es, weil der Vertrag ausläuft, die Software aber weiter verwendet werden soll, sei es weil der Auftragnehmer den vertraglich geschuldeten Wartungsleistungen nicht nachkommt oder gar nicht nachkommen kann. Was kann und darf man in so einer Situation tun bzw. wie kann man so eine Situation entschärfen? Hier muss zunächst zwischen Software und Services unterschieden werden: Bei Services, also beispielsweise Software as a Service (SaaS) , wo die Software in der Cloud läuft und als Service angeboten wird, hat man keinen Wartungsvertrag, sondern einen Servicevertrag. Dieser sollte zwar sicherstellen, dass eine laufend gewartete Software als Service zur Verfügung gestellt wird, macht aber üblicherweise keinerlei Zusicherungen hinsichtlich der Lebensdauer des Services. Man hat hier weder technische noch vertragliche Möglichkeiten um Wartung (und Betrieb) der Software zu verlängern: Bei So...

Während der Softwarewartung kommt es in den allermeisten Fällen auch zu fachlichen Änderungen oder Weiterentwicklungen. Diese werden unter dem Begriff Änderungsanforderungen bzw Change Request subsumiert, aber der Umgang mit ihnen in den seltensten Fällen in Wartungsverträgen behandelt. Dabei haben Fragen wie beispielsweise "Wer bezahlt / wartet diese Change Requests?" einen enormen Einfluss auf den Erfolg der Wartung einer Software. Bei Standardsoftware sind Change Requests technisch und juristisch problematisch und gehören daher unbedingt frühzeitig bedacht und im Wartungsvertrag behandelt: Spezifisch vs. allgemein sinnvoll: Es gibt Change Requests, die sind für alle Kunden einer Standardsoftware potentiell sinnvoll (bzw. haben zumindest keine negativen Auswirkungen) - und solche, die nur für einen oder wenige Käufer der Standardsoftware Sinn machen. Letztere müssen technisch derart vom Rest der Software getrennt werden, dass sie nur bei den Kunden bzw. Benutzern d...

Wartungsverträge sollten Service-Level Agreements  (SLAs) enthalten oder darauf verweisen. Ansonsten ist unklar was, in welchem Umfang, bis wann im Rahmen des Wartungsvertrages gemacht wird. Diese Service-Levels sind üblicherweise pönalisiert um auch ein Druckmittel in der Hand zu haben, wenn sie nicht erreicht werden. Üblicherweise werden die Service-Levels aber derart vereinbart, dass sie zwar leicht zu messen sind, aber dennoch wenig Nutzen haben: Oft sind SLAs gar nicht einhaltbar oder fokussieren auf Dinge, die nichts bringen: SLAs sollten sich nicht an dem orientieren, was möglich ist, sondern daran, was nützlich ist: Beispielsweise macht es keinen Sinn eine höhere Verfügbarkeit als nötig oder Hochverfügbarkeit außerhalb der Betriebszeiten zu vereinbaren. Andererseits bedeutet das, dass SLAs potentiell sehr herausfordernd sein können. Aber nur wenn diese Herausforderungen gemeistert werden, sind die diesbezüglichen SLAs auch nützlich.  → Damit SLAs nützlich sind, müss...

Software hat üblicherweise Fehler - auch produktionsreife Software am Stand der Technik muss nicht völlig fehlerfrei sein . Fehler sind Mängel und gehören daher allesamt im Rahmen der Gewährleistung oder Wartung behoben. Doch welche zuerst? Was, wenn ein Fehler sich nicht beheben lässt. Und wie Fehler von Verbesserungswünschen abgrenzen? Das (und viel mehr) fehlt üblicherweise in Wartungsverträgen . Kritische Fehler müssen immer zeitnah gelöst werden. Tatsächlich?  Gemäß IEEE 1 ist die Kritikalität (impact bzw. severity) eines Fehlers: "Die aus Sicht des Software-Engineerings stärkste Auswirkung, die der Fehler hat bzw. haben könnte". Auch die ISTQB berücksichtigt die Kritikalität für Anwender nicht. 2   →  Möchte man sicherstellen, dass für die Anwender kritische Fehler zeitnah gelöst werden, so muss man das vertraglich festhalten. Dabei kann man sich einer Kategorisierung der Fehler nach Fehlerfolgen angelehnt an DIN 55350-31 bzw DIN 40080 bedienen und diesbe...

Softwarewartungsverträgen fehlen erfahrungsgemäß viele Vereinbarungen , die für eine gelungene Softwarewartung geklärt werden sollten. Beispielsweise fehlt oft eine Vereinbarung hinsichtlich des Beginns der durch den Wartungsvertrag abgedeckten Wartungstätigkeiten. Dieser Blogpost enthält die diesbezüglich in der Praxis oft angetroffenen Mängel (ohne Anspruch auf Vollständigkeit): Gewährleistung vs. Wartungsbeginn:  Zumindest ein Teil der Wartungstätigkeiten (korrektive und präventive Wartung) sind bereits durch Gewährleistungsansprüche abgedeckt. Diese Ansprüche können auch im B2B Bereich vertraglich nicht ausgeschlossen (nur auf max. 1 Jahr verkürzt) werden.  → Es ist in einem Wartungsvertrag daher sinnvollerweise abzuklären, wie inhaltlich und finanziell während der Gewährleistungsphase mit Wartungstätigkeiten umzugehen ist. Gewährleistung für Mängelbehebung vs. Wartungsbeginn:  Werden - wie bei Software üblich - innerhalb der Gewährleistungsfrist Mängel entdeckt (z.B...

Wer Software entwickeln lässt, oder Standardsoftware kauft, muss auch mit nicht unerheblichen Wartungskosten rechnen. Diese werden oft vertraglich über einen jährlichen Pauschalbetrag, der sogenannten "Wartungspauschale" geregelt. Doch welche Tätigkeiten umfasst Softwarewartung, egal ob pauschaliert oder nicht? Blöde Frage - das ist ja ohnedies alles vertraglich vereinbart. Nein - ist es leider nicht. Die meisten der folgenden Fragestellungen werden durch die Wartungsverträge, die mir bisher untergekommen sind, nicht geregelt: Umfasst die Wartung neben der korrektiven auch die präventive Wartung  - die Behebung von Fehlern, die dem Auftragnehmer bekannt, aber beim Auftraggeber noch nicht in Erscheinung getreten sind? Umfasst die Wartung auch die perfektionierende Wartung - die Verbesserung von Attributen wie etwa der Usability, Performance oder Wartbarkeit? Darunter fällt u.A. die Behebung von technischen Schulden durch Reengineering, Refactoring usw. Umfasst die Wartung ...

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...

Bei Verfehlungen des Standes der Technik ist eine nachträgliche Verbesserung potentiell extrem aufwändig:  Es reicht meist nicht aus, sich ein, zwei Sprints oder Monate mit dem Aufräumen der Dinge zu befassen, die man in den Monaten oder Jahren davor eingebaut hat. Mängel in Softwarearchitektur, -Design oder auch bei den Tests können oft weder zeitnah noch ohne unerwünschte Nebeneffekte behoben werden. Zur Abschätzung von Aufwand und Durchlaufzeit der Verbesserung hilft eine Bestandsaufnahme und Gliederung der Mängel. Eine Bestandsaufnahme der Mängel hinsichtlich des Standes der Technik sollte spätestens mit der Abnahmeprüfung erstellt worden sein, ansonsten muss man davon ausgehen, dass die Software diesbezüglich nicht geprüft wurde und ihr Einsatz grob fahrlässig wäre.  Eine Gliederung der Mängelbehebungen sollte hinsichtlich ihres Aufwandes und dem damit verbundenen Risiko gemacht weden. Jede Veränderung an einer Software trägt ja das Risiko mit sich, dass die Softwa...

Software muss hinsichtlich der Entsprechung des Standes der Technik geprüft werden . Ansonsten kann nicht gesagt werden, dass die Software den Anforderungen entspricht , was zur Verweigerung der Abnahme und (auch bei nur intern verwendeter Software) rechtliche Konsequenzen  führt. Spätestens zum Zeitpunkt der Abnahme bzw. vor In-Betriebnahme sollte eine derartige Prüfung durchgeführt werden.  Da der Stand der Technik zu den „Beschaffenheiten, die … üblich und vom Käufer erwartbar sind“ ( §434 BGB ) bzw. „gewöhnlich vorausgesetzten Eigenschaften“ ( § 922 ABGB ) gehört, kann der Auftraggeber zwar auch noch nach der Abnahme diesbezüglich Verbesserung verlangen, aber das wird für beide Seiten deutlich teurer: Sobald die Software eingesetzt wird, führen einerseits diesbezügliche Mängel potentiell zu Schäden, andererseits ist eine Behebung der Mängel dann potentiell deutlich teurer (weil beispielsweise Produktivdaten korrigiert werden müssen. Wie aber stellt man bei A...

Bereits im Rahmen der Entwicklung einer Software werden oft Verletzungen des Standes der Technik eingebaut. Kaum ein Entwicklungsteam kann von sich behaupten, dass die Software an allen Stellen dem Stand der Technik entspricht. Allzuoft erkennt man bereits während der Entwicklung Mängel, findet aber keine Zeit sie auszubauen. Dasselbe gilt für die Wartung - bereits bestehende Mängel werden nicht ausgebaut und neue Mängel kommen durch Wartungsarbeiten bzw. verabsäumte Anpassungen der Software an den geänderten Stand der Technik hinzu. Die Frage lautet also: Wie kann man während der Softwareentwicklung verhindern, dass Mängel hinsichtlich des Standes der Technik eingebaut werden bzw. dass verabsäumt wird, diese auszubauen? Alle Menschen machen Fehler, das gilt selbstverständlich auch für gute Softwareentwickler. Aber unterschiedliche Softwareentwickler machen unerschiedliche Fehler, darum ist die Wahrscheinlichkeit, dass ein Fehler (oder ein Mangel hinsichtlich des Standes der Tech...

Bei Software ist der Stand der Technik weder allgemein definiert oder bekannt , noch wird er üblicherweise eingehalten . Spätere Streitereien bzw. der Einsatz einer nicht dem Stand der Technik entsprechenden Software mit all den juristischen Problemen für Auftraggeber und Auftragnehmer, sind vorprogrammiert. Man tut also gut daran, bereits bei der Vertragsgestaltung bzw. Ausschreibung den Stand der Technik zu berücksichtigen. Dieser Blog enthält viele Posts, die vertraglich zu berücksichtigende Punkte enthalten  - siehe  Label Vertragsgestaltung . Diese sollten idealerweise alle berücksichtigt werden, um den Stand der Technik sicherzustellen und spätere Streitereien zu vermeiden. Einige davon lassen sich trivial durch einzelne Sätze in den Verträgen festhalten, andere aber wiederum benötigen tiefergehendes technisches Wissen. Die Vertragsgestaltung einzig den Juristen zu überlassen ist daher nicht zielführend. Üblicherweise findet man in Softwareverträgen und -ausschreibung...

Im B2B Bereich kann Haftung wegen leichter Fahrlässigkeit ausgeschlossen werden (siehe  §309-310 BGB  bzw.  OGH RS0016582 ). Die Gewährleistung kann bei B2B maximal auf 1 Jahr verkürzt werden und auch hier kommt es auf den Grad der Fahrlässigkeit an. Aus diesem Grund findet man auch in vielen Softwareverträgen den Ausschluss der Haftungs- und Gewährleistungsansprüche bei leichter Fahrlässigkeit. Es stellt sich daher die Frage: "Sind Verfehlungen des Standes der Technik leicht oder grob fahrlässig?" Grobe Fahrlässigkeit ist gesetzlich nicht exakt von leichter Fahrlässigkeit abgegrenzt.  Darunter wird im Allgemeinen folgendes verstanden: Ein Handeln, bei dem die erforderliche Sorgfalt in einem ungewöhnlich hohen Maße verletzt worden ist. Ein Verhalten, das einem ordentlichen Menschen in derselben Situation keinesfalls unterlaufen würde. 1 Wird bei Verfehlungen des Standes der Technik also die erforderliche Sorgfalt in einem ungewöhnlich hohen Mape verletzt? Unterlau...

Software ist zum Abnahmezeitpunkt erfahrungsgemäß oft nicht am Stand der Technik .  Entspricht ein Produkt bzw. eine Dienstleistung zum Abnahmezeitpunk (~ "Zeitpunkt des Gefahrenübergangs") nicht dem Stand der Technik, so handelt es sich um einen Mangel. Gemäß Gewährleistungsrecht ( § 437ff BGB  bzw.  § 932 ABGB ) kann der Käufer nun Austausch oder Verbesserung verlangen und wenn diese Maßnahmen nicht zielführend oder unzumutbar ist, vom Vertrag zurücktreten bzw. bei geringfügigen Mängeln eine Preisminderung verlangen. Dazu muss aber zunächst einmal die Abnahme verweigert werden. Mit der Abnahme würde der Auftraggeber nämlich bestätigen, dass der Auftragnehmer seinen Leistungspflichten nachgekommen sei. Nur bei geringfügigen Mängeln (z.B. teilweise Verfehlung der Einhaltung von Naming-Conventions, Einsatz von Libraries mit veralteten aber noch gewarteten Versionen) fehlt die rechtliche Grundlage, um die Abnahme zu verweigern. Die Mängel müssen aber dennoch im Rahme...

Neben dem nicht unerheblichen  Aufwand für präventive und korrektive Wartung muss man in der IT gemäß IEEE 1  mit Aufwand für perfektionierende (Verbesserung von Attributen wie Performanz, Usability, Wartbarkeit) und adaptive Wartung (Anpassung an veränderte Bedingungen der Umgebung) rechnen. Ansonsten veraltet die Software und muss potentiell schon nach wenigen Jahren durch neue Software ersetzt werden Aufwand perfektionierender Wartung  (Verbesserung von Attributen) Dabei handelt es sich um alle nicht-funktionalen Anforderungen wie beispielsweise Performanz, Usability und Wartbarkeit der Software. Dazu gehört beispielsweise auch sämtliche in der ISO/IEC 25000 Normenreihe beschriebenen Qualitätsanforderungen. In der Praxis sind einige der geforderten Attribute (insbesondere die Wartbarkeit der Software) zum Einsatzzeitpunkt oft nicht erfüllt. Deren Erreichung (bzw. die Erreichung des diesbezüglichen Standes der Technik, wenn diesbezügliche Vereinbarungen fehlen) fäl...

Softwarewartung ist gemäß IEEE 1 die "Veränderung eines Softwareprodukts nach dessen Auslieferung, um Fehler zu beheben, Performanz oder andere Attribute zu verbessern oder Anpassungen an die veränderte Umgebung vorzunehmen". Daraus lassen sich folgende Aufwandsfaktoren ableiten: Fehlerbeseitigung: Die Beseitigung von beim Anwender auftretenden (korrektive Wartung) bzw. anderweitig bekannten (präventive Wartung) Fehlern. → Kennt man die Anzahl an pro Jahr zu beseitigenden Fehlern und den durchschnittlichen Aufwand für die Fehlerbeseitigung, lässt sich dieser Aufwandsfaktor leicht eruieren. Verbesserungen von Attributen: Die Verbesserung von Attributen wie Performanz, Usability, Wartbarkeit (perfektionierende Wartung). Dazu gehört beispielsweise sämtliche in der ISO/IEC 25000 Normenreihe beschriebenen Qualitätsanforderungen. → Bei einer einsatztauglichen Software müssen diese Attribute alle gemäß Vertrag erfüllt sein. Diesbezüglich ist nur dann Aufwand zu erwarten, w...