Software am Stand der Technik

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

Open-Source Frameworks und Libraries werden heutzutage in beinahe jeder Software massiv eingesetzt. 1 Weil etwas alle machen, ist es aber noch lange nicht Stand der Technik. Es stellt sich daher die Frage, ob der Einsatz von Open-Source Frameworks und Libraries dem Stand der Technik entspricht bzw. was dabei zu beachten ist. Beim Einsatz von Open-Source Frameworks und Libraries sind selbstverständlich die 4 Grundsätze des Standes der Technik (Entwicklungsstand, fortschrittlich, bewährt, zielgerichtet)  zu beachten. Ein Großteil der Frameworks und Libraries entspricht demgemäß per se nicht dem Stand der Technik: Viele Frameworks und Libraries sind technisch oder funktional derart veraltet, dass sie nicht mehr dem Entwicklungsstand entsprechen, obwohl sie noch weiter gewartet werden - z.B . RMI-IIOP via  CORBA . Viele wurden schon lange durch ein fortschrittlich eres Framework oder Library ersetzt - z.B. wurde AngularJS 2018  durch Angular ersetzt . Ein Großteil der ...

Software muss am Stand der Technik sein - ansonsten drohen Gewährleistungs- und Schadenersatzforderungen. Was aber, wenn man Freeware oder Open-Source Software entwickelt? Wer Freeware oder Open-Source Software entwickelt, fühlt sich oft durch die gewählten OS-Lizenzen geschützt. Die Lizenzen müssen dafür aber - wie auch bei kommerzieller Software - expliziter Vertragsbestandteil sein. Eine allgemeine Klausel z.B. in den allgemeinen Geschäftsbedingungen oder ein einfaches Mitschicken der Lizenz mit der Software reicht nicht ( §311 BGB , §879(3) ABGB ). Darüber hinaus kann weder durch Verträge noch Lizenzen jede Art von Haftung und Gewährleistung ausgeschlossen werden: Im B2C Bereich kann weder Haftung noch Gewährleistung ausgeschlossen werden ( §476 BGB ,  §922 ABGB ). Im B2B Bereich kann nur Haftung wegen leichter Fahrlässigkeit ausgeschlossen werden (siehe §309-310 BGB bzw.  OGH RS0016582 ). Die Gewährleistung kann maximal auf 1 Jahr verkürzt werden und auch hier ko...

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

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

Angenommen ein Unternehmen entwickelt oder verwendet Software, die rein für den internen Gebrauch gedacht ist. Die Software wird also weder verkauft noch verschenkt, noch kann sie von anderen als den Mitarbeitern des Unternehmens verwendet werden. Muss so eine Software dem Stand der Technik entsprechen? Üblicherweise wird diese Frage mit "Nein" beantwortet. Interne Software ist ja wie ein Werkzeug: Wenn es mangelhaft ist, so kann das ja nur dem eigenen Unternehmen schaden. Ganz so einfach ist die rechtliche Lage aber nicht: Unternehmenshaftung:  Es können durch mangelhafte interne Software (so wie bei mangelhaften Werkzeugen) Personen zu Schaden kommen - z.B. durch eine Verfehlung des Standes der Technik gemäß Datenschutzrecht (vgl.  §32 DSGVO ) bei der Verarbeitung personenbezogener Daten. Schäden für die das Unternehmen genauso wie bei extern erreichbarer Software haftet. ➝ Die Nicht-Einhaltung des Standes der Technik darf zu keinen Schäden außerhalb des Unternehmens (z.B...

Kann man wissen, wie viele Fehler sich in einer Software verstecken? Exakt kann man das mit akzeptablem Aufwand nie wissen – aber es lässt sich abschätzen. Das ist notwendig zur Bewertung potentieller Risiken einer Software, aber auch zur Abschätzung der Fehlerdichte (siehe Wieviele Bugs darf eine Software haben? (Teil 1 - Fehlerdichte) ). Dazu kann man sich folgender Erkenntnisse aus der Literatur bedienen: Während der Entwicklung entstehen programmiersprachenunabhängig zwischen 30 und 50 Fehler pro 1.000 Zeilen Sourcecode (= KSLOC). 1 Mittels Unit-Tests bzw. TDD können im Schnitt 30 - 45 % der Fehler gefunden bzw. vermieden werden. 2 Formale Code-Inspections finden/verhindern 45-70% der restlichen Fehler 3 Gutes Pair-Programming findet/verhindert 40- 60 % der (restlichen) Fehler 3 Code-Reviews finden/verhindern 20- 40 % der restlichen Fehler 3 Basierend auf diesen Erkenntnissen kann man nun abschätzen, wieviele Fehler in der Software nach den typ...

"Fehlerfreie Software gibt es nicht" - dieser Ausspruch ist zwar nicht korrekt 1 , üblicherweise aber verlangt der Stand der Technik (da er zielgerichtet und somit wirtschaftlich sein muss) keine Fehlerfreiheit bei Software. Aber ist es deshalb ok, wenn eine Software beliebig viele Fehler enthält? Ab wievielen Fehlern gilt eine Software als mangelhaft bzw. nicht einsatzbereit? Die Antwort auf diese Frage lässt sich an Hand der sogenannten Fehlerdichte (en. defect-density ) klären: In der Informatik bezeichnet die Fehlerdichte die Anzahl an Fehlern pro 1.000 Zeilen Code. Die angestrebte Fehlerdichte ist idealerweise vertraglich festgelegt oder zumindest während der Analysephase mit dem Auftraggeber definiert worden. Wenn nicht, gilt der Stand der Technik, der diesbezüglich durch die Fachliteratur klar definiert ist: 2 Unbrauchbar - also nicht einmal für Previews, Teststellungen oder user-acceptance-tests verwendbar - ist eine Software bei einer Fehlerdichte > 10 Produkti...

Software veraltet schnell. Neue Techniken und Technologien übertreffen bestehende oft nach wenigen Jahren. Neue Versionen der verwendeten Technologien kommen meist in noch kürzeren Abständen (Monate, Wochen) und ersetzen oft zwangsweise (Security-Fixes, Bugfixes, Supportende) die alten Versionen: Software bleibt nur am Stand der Technik, wenn sie auch laufend am Stand der Technik gehalten wird. Die Frage, die sich stellt, ist, ob man aus legalen Gründen Software am Stand der Technik halten muss.  Ist es legal veraltete Software zu betreiben oder im Rahmen der Wartung den Stand der Technik zu vernachlässigen? Die Antwort auf diese Frage ist wie so oft: "Kommt darauf an": Gemäß Datenschutzrecht (vgl.  §32 DSGVO ) ist der Stand der Technik während des gesamten Verarbeitungsvorgangs zu gewährleisten und demnach auf Basis einer Risikobeurteilung fortlaufend anzupassen.  ➝ Der Betreiber einer Software macht sich strafbar, wenn die Software hinsichtlich des Datenschutzrechtes n...

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

Wer Software schreibt, macht sich oft Gedanken darüber, welche Techniken und Technologien denn für die Software geeignet sind. Aber müssen diese auch dem Stand der Technik bei Software entsprechen? Was kann den passieren, wenn Software nicht dem Stand der Technik entspricht? Entwickelt man Software, so muss diese Tätigkeit, so wie auch die entstandene Software wie jede Dienstleistung bzw. jedes Produkt zumindest den Regeln der Technik entsprechen. Ansonsten drohen Gewährleistungs- und Schadenersatzforderungen. Die (allgemein anerkannten) Regeln der Technik gehören zu den „Beschaffenheiten, die … üblich und vom Käufer erwartbar sind“ ( §434 BGB ) bzw. „gewöhnlich vorausgesetzten Eigenschaften“ ( § 922 ABGB ). 1 Entspricht ein Produkt oder eine Dienstleistung wie Software oder Softwareentwicklung nicht den Regeln der Technik (ohne dass dieser Mangel explizit vereinbart wurde), so kann gemäß Gewährleistungsrecht ( § 437ff BGB bzw. § 932 ABGB ) der Käufer eine Verbesserung verlangen...

Üblicherweise versteht man in der Softwareentwicklung unter dem Stand der Technik bei Software all das, was aktuell in aller Munde ist, was auf Fachkonferenzen besprochen wird, was man zumindest in neuen Projekten einsetzen möchte. Doch entspricht das tatsächlich dem Stand der Technik? Ob in der Informatik eine bestimmte Technologie oder Technik dem Stand der Technik entspricht, lässt sich mittels der 4 Grundsätzen des Standes der Technik bestimmen: Entwicklungsstand  - gibt es dazu beispielsweise aktuelle Bücher, Veröffentlichungen oder Fachvorträge? Fortschrittlich  - gibt es dazu eine neuere Version oder gar andere Technologie bzw. Technik, die als Nachfolger dafür betrachtet werden kann? Bewährt  - hat es sich in anderen Projekten bewährt, gibt es dazu beispielsweise Praxisberichte, regen Austausch auf Stack-Overflow oder aktive Benutzergruppen? Zielgerichtet  - lässt sich die gegebene Aufgabenstellung damit überhaupt lösen und ist diese Lösung auch wirt...