Software am Stand der Technik

Microservices haben zwar jede Menge Vorteile, aber auch viele Nachteile. Nur wenn die Vorteile die Nachteile überwiegen, macht der Einsatz einer Microservice-Architektur Sinn. Nur wenn die Verhältnismäßigkeit zwischen Vor- und Nachteilen besser ist als bei alternativen Architekturen gilt eine Microservice-Architektur als fortschrittlicher. Dies ist aber Voraussetzung für den Stand der Technik, und dieser üblicherweise Vertragsbestandteil oder gewöhnlich vorausgesetzte Eigenschaft. Eine Microservice-Architektur ist somit nur dann vertragskonform, wenn sich ihre Fortschrittlichkeit für das jeweilige Projekt nachweisen lässt. Im letzten Blogpost wurde dargelegt, dass Microservice-Architekturen generell zwei der drei Bedingungen für den Stand der Technik erfüllen. Diesmal geht es darum zu prüfen, welche Vor- und Nachteile eine Microservice-Architektur gegenüber einem Modulithen 1  - der typischen Alternative zu einer Microservice-Architektur - haben. Dazu lässt sich viel z.B. im Intern

Noch vor wenigen Jahren waren Microservices in aller Munde.  Microservice-Architekturen versprechen jede Menge Vorteile: Verteil- und skalierbarer, verfügbarer, wartbarer, paralleler entwickelbar, schneller und öfter ausrollbar, ... sollten sie sein. Doch stimmt das auch tatsächlich und macht das Microservice-Architekturen zum Stand der Technik? Zweifelsohne kann man Software mit einer Microservice-Architektur umsetzen. Es gibt schon seit vielen Jahren erfolgreich mit einer Microservice-Architektur umgesetzte Projekte. Vorreiter war Netflix 2009, inzwischen hat Netflix tausende Microservices die teilweise hunderte Male täglich ausgerollt werden. → Damit ist die Funktionstüchtigkeit von Microservice-Architekturen als erprobt und erwiesen anzusehen - eine der Bedingungen für die Erfüllung des Standes der Technik . Die zweite Bedingung für die Erfüllung des Standes der Technik ist, ob das geprüfte Verfahren (also eine Microservice-Architektur) auf wissenschaftlichen Erkenntnissen beruh

Pair Programming ist eine Arbeitstechnik der agilen Softwareentwicklung die in den 1990er Jahren mit Extreme Programming eingeführt wurde und bereits seit den 2000er Jahren breite Verwendung findet. Ist Pair Programming somit am Stand der Technik? Darf bzw. muss man es überall einsetzen? Ist es vielleicht schon längst durch modernere Arbeitstechniken wie Mob Programming überholt? Um diese Fragen korrekt beantworten zu können, muss man nicht nur wissen, was Pair Programming genau ist und welche Alternativen es dazu gibt, was die Klausel "Stand der Technik" bedeutet und welche Verpflichtungen sich daraus ableiten . Man muss (gegebenenfalls sogar vor Gericht haltbar) nachweisen können, warum die Antworten nur so und nicht anders lauten können. Hier der diesbezügliche Nachweis basierend auf dem bereits früher vorgestellten gerichtlich haltbaren Prüfschema : Beruht Pair Programming auf wissenschaftlichen Erkenntnissen? Ist die Funktionstüchtigkeit von Pair Programming

Software muss (wie alle Produkte und Dienstleistungen) dem Stand der Technik bzw. zumindest den anerkannten Regeln der Technik entsprechen. Das wird oft vertraglich festgelegt und auch von den Softwareentwicklern meist behauptet. Doch wie kann man das auch belegen? Stand der Technik, (allgemein anerkannte) Regeln der Technik und Stand der Wissenschaft (und Forschung) sind juristische Technikklauseln , die in verschiedenen Rechtsgebieten Verwendung finden. Zur exakten Wortwahl und deren juristische Interpretation siehe Technikstandards . Aber wie kann man nachvollziehbar und auch vor Gericht haltbar nachweisen bzw. prüfen, ob ein Produkt bzw. eine Dienstleistung dem geforderten Standard entspricht? 1 Geprüft werden muss jedes Verhalten auf technischem Gebiet (also jede Technik, jedes Tool, jede Technologie) ob es dem folgenden Schema entspricht. Sobald auch nur ein Punkt nicht eingehalten ist, so gilt dieses Verfahren und somit das gesamte Produkt bzw. die Dienstleistung als nicht de

Viele Verträge enthalten einen Passus, der beschreibt an welchen Technikstandard sich das zu liefernde Produkt bzw. die Dienstleistung zu halten hat. Hier wird bei Softwareverträgen oft auf den Stand der Technik , die Regeln der Technik oder Normen verwiesen. Das alleine reicht jedoch bei weitem nicht , da weder der Stand der Technik, noch die Regeln der Technik, noch IT Normen gut genug definiert sind, um deren Einhaltung unzweifelhaft festzustellen. Aber es ist zumindest ein grober Hinweis darauf, was diesbezüglich geschuldet wird. Doch wie unterscheiden sich diese Technikstandards überhaupt? Stand der Technik und Regeln der Technik sind juristische Technikklauseln , die in verschiedenen Rechtsgebieten Verwendung finden (z.B. für Gewährleistung oder Schadenersatz). Es wird zwischen folgenden 3 Stufen unterschieden: 1 Regeln der Technik - " technische Regeln, die aus Wissenschaft oder Erfahrung auf technischem Gebiet gewonnene Grundsätze enthalten und deren Richtigkeit u

In der Informatik gibt es wie in anderen Bereichen auch Normen: Weniger länderspezifische DIN oder ÖNORMen, aber insbesondere viele internationalen ISO/IEC/IEEE Normen für die unterschiedlichsten Bereiche der Informatik. Diese Normen beschreiben alle Prozesse rund um Software - von der ersten Idee bis zur Ablöse einer Software. Muss man sich als Softwarehersteller an diese Normen halten? IT Normen sind extrem teuer. Es gibt nicht nur ca. 100 Software betreffende Normen, sie sind auch teils recht umfangreich und um ein Vielfaches teurer als Fachliteratur (oft mehrere Euro pro Seite). Viele davon werden mehr oder weniger regelmäßig (ca. alle 10 Jahre) zum Teil mit drastischen Änderungen erneuert oder durch eine neuere Norm abgelöst. Es ist nicht verwunderlich, dass sich die meisten in der Informatik tätigen Unternehmen scheuen, die mehreren 10.000€ aufzuwenden, um die Normen zu kaufen. Und die Unternehmen, die bereit sind das Geld dafür aufzuwenden, finden nur selten Mitarbeiter, die

Wenn der Einsatz von Künstlicher Intelligenz (KI) legal ist, dann sollte er auch dem Stand der Technik entsprechen. Nur weil eine Technologie neu (wobei KI eigentlich eine schon uralte Technologie ist) und in aller Munde ist, heißt das ja nicht, dass sie auch dem Stand der Technik entspricht. Und entspricht der Einsatz von KI nicht dem Stand der Technik, so ist er auch in vielen Fällen nicht legal . Damit Software dem Stand der Technik entspricht muss sie den 4 Grundsätzen des Standes der Technik entsprechen. Die Frage ist also: Entspricht der Einsatz von KI 1) dem Entwicklungsstand, ist er 2) fortschrittlich und 3) bewährt und darüber hinaus auch 4) zielgerichtet? Wenn die KI auf aktuellen Technologien beruht - also beispielsweise Frameworks für neuronale Netze oder maschinelles Lernen verwendet - entspricht der Einsatz der KI zweifelsohne dem Entwicklungsstand und gilt als fortschrittlich, solange aktuelle Versionen der Frameworks eingesetzt werden. In den meisten Projekten wer

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? Bearbeit

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üssen diese

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 diesbezügliche

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. Bugs oder te

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