Inhalt:
- Warum sind Digitalisierungsprojekte so teuer?
- Wo fließt das Geld hin?
- Wie können Kosten vermieden werden?
- Ramp-Up
- Umsetzung
- Betrieb
- Fazit
- Quellen
Die Kosten für die Entwicklungen digitaler Produkte im Zuge von Digitalisierungsprojekten können sehr stark schwanken. Von einigen tausend Euro für die Integration und das Customizing von digitalen Produkten, bis hin zu einigen hunderttausend (>100.000€) Euro für die individuelle Entwicklung von digitalen Produkten schwanken die Ausgaben und Kosten in diesem Bereich sehr stark.
Für jemanden der sich nicht gut in der Thematik auskennt, sind diese Schwankungen der Kosten oft nicht nachvollziehbar. Unternehmen versuchen dabei natürlich die Kosten möglichst zu minimieren und den Mehrwert zu maximieren, denn Software-Entwickler (Stundensätze zwischen 75€ – 150€ und mehr), IT-Spezialisten und Equipment sind teuer. Um hier den besten Wirkungsgrad zu erreichen, können vor allem bei der Umsetzung massiv Kosten entstehen oder eben auch verhindert werden. Die eigentliche Implementierung, also das Schreiben von Source-Code ist dabei nur ein sehr geringer Anteil des Projekts. Wie verschiedene Studien1 2 aufzeigen entsteht in der Programmierung nur etwa ein Anteil von 40%3 der Kosten eines Software/IT-Projekts. Dieser Artikel beschäftigt sich nun mit diesen Pattern und Antipattern zur Kostenvermeidung bzw. Kostenverringerung
Diese Frage wird mir immer wieder gestellt. Dabei stößt diese Frage bei mir auf absolutes Unverständnis, denn meiner Meinung nach sind Digitalisierungsprojekte Investitionen, die sich auszahlen müssen. Rentiert sich die Investition nicht, so ist die Frage warum die Investition überhaupt gemacht wurde. Dabei meine ich nicht, dass Digitalisierungsprojekte immer einen wirtschaftlichen Erfolg nachweisen müssen. Es gibt genügend Beispiele wo digitale Produkte aus Marketing- und Prestige-Zweck gemacht wurden und nur indirekt zu einem Erfolg des Unternehmens beigetragen haben. Viel mehr glaube ich geht es denjenigen die sich diese Frage stellen um die Investitionssumme und die mit dem Digitalisierungsprojekt verbundenen Risiken. Es ist oft so, dass Manager die ihre ersten Digitalisierungsprojekt umsetzen und ihre ersten digitalen Produkte entwickeln vorher noch nie etwas mit IT, Digitalisierung und Programmierung zu tun hatten. Und das fehlen dieser Erfahrungen führt dazu, dass Misstrauen und Verwunderung vorherrschen und Fehleinschätzungen gemacht werden. Es stimmt dass Stundensätze von IT-Spezialisten wie Software-Entwicklern und IT-Equipment hochpreisig sind. Die Nachfrage ist enorm weil wir uns mitten in einer großen Digitalisierungswelle befinden. Umso wichtiger ist es Ressourcenschonend zu arbeiten und Kosten und Risiken gering zu halten. Digitalisierungsprojekte werden oft deswegen teuer, weil aufgrund von fehlenden Knowhow Fehler gemacht werden. Daher ist es notwendig und Ratsam sich neutrale IT-Spezialisten ins Haus zu holen und die Umsetzung gut zu planen und zu gestalten.
Ein Digitalisierungsprojekt kann grob in verschiedene Phasen unterteilt werden. Diese Phasen bauen einerseits aufeinander auf und verlaufen andererseits etwas in einander. Gerade die agile Vorgehensweise durch beispielsweise Scrum führt dazu, dass diese Phasen durchaus auch ineinander verschwimmen. Zur besseren Verständnis werden die Phasen aber jetzt aufeinander aufbauend kurz beschrieben.
- Phase: Ramp-up und Ideenfindung/Geschäftsmodell definieren
- Phase: Umsetzung und Implementierung
- Phase: Einführung und Change-Prozess
- Phase: Betrieb und Wartung
Diese vier Phasen können wiederum in Kategorien eingeteilt werden
- technische Lösung
- organisatorische Herausforderungen
Die Phasen 2 und 4 werden in die technische Kategorie eingeteilt während die Phase 1 und 3 in die organisatorische Kategorie eingeordnet werden.
In den meisten Organisationen werden bei der Budgetierung nur jene Phasen der technischen Kategorie berücksichtigt während organisatorische Aufgaben meist nicht Budgetiert werden, sondern als Gemeinkosten verbucht werden. Obwohl die organisatorischen Kosten nicht in der Projektbudgetierung Berücksichtigung finden stellen sie dennoch eine hohe Belastung für ein Unternehmen dar und müssen als Kosten dringend vermieden werden. Es ist hier jedoch sehr schwierig wissenschaftlich fundierte Daten statistisch auszuwerten, weil derartige Daten oft nicht aufgezeichnet werden. Dazu wäre es nämlich notwendig im gesamten Unternehmen kostenrein auf das Projekt zu buchen, was eine große zusätzliche organisatorische Aufgabe darstellt und somit selbst wieder Kosten und Aufwände verursacht – Aufwände die sich die meisten Unternehmen nicht aufbürden.
Statistisch und wissenschaftlich fundiert auswertbar ist jedoch das Verhältnis zwischen Phase 2 und 4. Also das Verhältnis der Kosten zwischen einerseits der Implementierung und andererseits des Betriebs und der Wartung.
Die meisten Budgetverantwortlichen unterschätzen dieses Verhältnis, welches bei 1:4 liegt4 und reservieren viel zu wenig Budget für Betrieb und Wartung der Software. Das bedeutet5 dass nur 20% des gesamt benötigten Budgets eines Digitalisierungsprojekts in die ursprüngliche Entwicklung der Software fließen, während 80% danach in Wartung und Betrieb verbraucht werden.
Die beste Strategie um Digitalisierungsprojekte möglichst Günstig zu gestalten ist es Kosten erst gar nicht entstehen zu lassen. Es gibt zahlreiche Momente in einem Digitalisierungsprojekt in denen es notwendig ist Zeit zu investieren um spätere Kosten zu verhindern.
Die folgenden Punkte umfassen derartige Momente und Themen und zeigen klare Pattern und Antipattern auf.
Anerkennen der Ist-Situation und Respekt.
Ein Digitalisierungsprojekt umzusetzen ist immer mit einer hohen Investitionssumme verbunden die sich letzten Endes auszahlen muss. Bei der Einführung der neuen Software kann es zu allerlei Gefühlen und Konflikten kommen, denn Software wird immer noch von Menschen bedient. Außerdem greifen Digitalisierungsprojekte sehr oft in die bestehende Aufbau- und Ablauforganisation ein. Ein großes Change-Projekt entsteht6.Um bei der Einführung der Software und somit dem Change-Projekt weniger Widerstände zu haben ist es notwendig bei der Ist-Analyse die vorhandenen Lösungen und die bereits investierte Vorarbeit der Mitarbeiter zu würdigen und anzuerkennen.
Dabei kostet eine Anerkennung in Form freundlicher Worte kaum etwas, während Konflikte bei der Einführung der neuen Software extreme Kosten verursachen können.
Die richtigen Features umsetzen
Die größten Kosten die in der Softwareentwicklung entstehen können, sind jene die entstehen wenn Features umgesetzt werden die für den User keinen Mehrwert bringen. Es ist notwendig, dass das Team und vor allem der Produkt-Manager (Product-Owner) zu Beginn des Projekts viel Zeit investiert die Bedürfnisse der User zu erkunden. Dabei ist es ratsam die Userbedürfnisse mit Hilfe des Kano-Modells7 in Basis- Leistungs- und Begeisterungsanforderungen zu gliedern.. Um hier effizient und strukturiert vorzugehen sollten die User in verschiedene Usergruppen zerlegt werden und dabei Personas8angelegt werden die diese Usergruppen beschreiben. Danach werden pro Usergruppe mit Hilfe des Value-Proposition Canvas die die Pains9,Gains und User-Jobs erkundet und das Passende Wertangebot ausformuliert, um einen möglichst guten Product-Market-Fit10 zu erreichen.
Das richtige Team in den richtigen Rollen
Viele Kosten die in der Umsetzung eines Digitalisierungsprojekts entstehen basieren auf Konflikten und Problemen des Teams. Einerseits kann es sein, dass die Kompetenzen und Fähigkeiten im Team nicht so gestreut sind wie es in agilen Scrum-Teams notwendig wäre. Denn agile Umsetzungsteams müssen interdisziplinäre Fähigkeiten und Kenntnisse haben und somit müssen sich die persönlichen Skills und Fähigkeiten der einzelnen Teammitglieder gut zusammen ergänzen.
Andererseits ist den Beteiligten oft ihre jeweilige Rolle11 nicht klar, die sie im Team besetzten müssen und somit die Verantwortung die sie tragen. Werden Rollen nicht richtig ausgeführt entstehen Defizite, Fehler und Konflikte und dies führt unweigerlich zu extremen Kosten.
Wahl der richtigen Umsetzungsmethode
Antipattern: Plangetriebenes Vorgehen bei der Entwicklung digitaler Produkte.
Abhängig von der Produktvision und der Komplexität der Umsetzung sowie der technologischen Herausforderungen sind verschiedene Umsetzungsmethoden und Frameworks effizient. Die Stacey-Matrix veranschaulicht dies:
Scrum ist nicht immer die erste Wahl, denn für einfache und bekannte repetitive Aufgaben ist Scrum mit zu viel Overhead behaftet. In den aller meisten Fällen sind Digitalisierungsprojekte und die Umsetzung digitaler Produkte jedoch hoch Komplex und technologisch sehr herausfordernd. Scrum kombiniert mit Design-Thinking12, Lean Startup13und anderen Agilen Methoden14 wie Kanban und XP sind daher meist die richtige Wahl. Wer glaubt, Software plangetrieben mit Lasten- und Pflichtenheft in Wasserfallmanier umsetzen zu müssen, um Kosten zu vermeiden und effizient zu arbeiten macht einen großen fehler, der im Nachhinein viele Kosten verursacht und das Projekt gefährdet. Plangetriebene Ansätze führen nämlich dazu, dass die Stärken digitaler Produktentwicklung15 nicht ausgenutzt werden können, und die Nachteile der Plangetriebenen Vorgehensmethode massiv tragend werden.
Outcome nicht Output
Ein großer Fehler und somit großer Kostentreiber, den viele Scrum-Teams machen ist es den Blick auf das Wesentliche, nämlich das Befriedigen der User Bedürfnisse und das Schaffen von Mehrwert, zu verlieren und in einen Trott zu verfallen bei dem Feature um Feature erstellt wird. Dabei verfällt das Team in ein Output Mindset16, bei dem es darum geht Effizienter mehr Funktionalität zu liefern. Feedback der User wird dabei nicht oder wenig eingeholt. Die teuersten Features in einem digitalen Produkt sind immer die, die implementiert wurden aber vom User nicht verwendet wurden und somit nicht bezahlt werden. Dadurch entstehen zu Beginn hohe Entwicklungskosten die dann durch hohe Wartungskosten und Betriebskosten verschärft werden. Effiziente Scrum-Teams sind auf effektive Scrum-Teams, die im Idealfall bei jedem Sprint-Review Userfeedback einholen und auf den Outcome17 fokussiert arbeiten. Dadurch werden nur jene Features implementiert die auch wirklich vom User gewünscht sind und Kosten können vermieden werden.
Usability und User-Experience
Oftmals besteht das Umsetzungsteam eines digitalen Produkts aus sehr technisch fokussierten Mitgliedern, die grafische UI- und die Ux-Kompetenz18 im Team ist hingegen sehr oft unterrepräsentiert. Dies führt dazu dass die Software zwar für diejenigen die sie programmieren intuitiv wirkt, jedoch für den normalen User zu komplex und schlecht zu bedienen ist. Das Team wird „Betreibsblind“ und sieht die Komplexität des eigenen Produkts nicht mehr. Dies wiederum führt zu einer schlechten Akzeptanz der Oberfläche bei den Usern und wirkt verkaufshindernd. Um dieses Problem zu lösen sollte einerseits die Ux-Kompetenz des Teams aufgebaut oder durch zusätzliche Teammember ergänzt werden, andererseits durch Feedback von Usern abgesichert werden.
Involvieren von Key-Usern
Um effektiv und Outcome-fokussiert zu Arbeiten müssen Key-User in das Projekt und die Produktentwicklung involviert werden. Bei internen Digitalisierungsprojekten ist dies viel einfacher möglich, als bei externen, da hier der Kunde im eigenen Haus sitzt. Aber egal wo die User sind, sie müssen rechtzeitig und regelmäßig involviert werden und das Team muss Feedback von ihnen einholen. Im Idealfall identifiziert der Product-Owner/Produktmanager Personengruppen mit Hilfe von Personas und mobilisiert eine Hand voll Key-Usern, die bei den regelmäßigen Scrum-Reviews19 anwesend sind. Oftmals ist dies auf einer regelmäßigen Basis jedoch nicht möglich, weshalb der Produktmanager dann Feedbackgespräche mit Keyusern parallel zum Scrumbetrieb und den Reviews organisieren muss. Durch dieses Feedback können Hypothesen die der Produktmanager/Product-Owner und das restliche Scrum-Team aufgestellt haben bestätigt oder falsifiziert werden und somit frühzeitig Kosten und Aufwände, die in unnötige Features fließen würden, eingespart werden. Das gesamte Scrum-Team lernt durch das ständige Involvieren der Key-User mehr und mehr über deren Bedürfnisse und kann ein Produkt mit gutem Product-Market-Fit20 bauen.
Adaptieren auf neue Marktbedürfnisse
Das Suche nach dem Product-Market-Fits21 muss sich ständig an veränderte Bedingungen am Markt und veränderte Kundenbedürfnisse anpassen. Der Product-Market-Fit ist kein statisches stationäres Ziel, was erreicht wird und sich nie mehr ändert, sonder ist volatil und dynamisch. Aus diesem Grund sind agile Umsetzungsmethode und Lean Produktmanagement22 perfekt für diese dynamische Aufgabe, da sie ständig den Status-Quo reflektieren und sich auf veränderte Bedingungen anpassen.
Ist ein Umsetzungsteam jedoch zu Output getrieben und reflektiert zu wenig die Kundenbedürfnisse so kann dies dazu führen, dass Ziele verfolgt werden die bei der Zielerreichung bereits obsolet sind.
Beweisen des Geschäftsmodells und involvierung des Marketings
Auch Vertriebs- und Marketingsstrategien wie Growth-Hacking23 sollte unbedingt in den Entwicklungszyklus mit integriert werden. Ob ein Produkt einen Guten Product-Market-Fit erreicht kann nur dann mit Sicherheit festgestellt werden, wenn bereits während der Entwicklung Vertriebs- und Marketingexperimente durchgeführt werden, und das Team es erreicht zahlende Kunden zu generieren. Nur dann kann bewiesen werden, dass das Geschäftsmodell auch funktioniert, das Pricing in Ordnung ist und das Wertangebot stimmt. Mit Growth-Hacking fließen Marketingaufgaben und neue Features mit in das Produkt ein und erweitern somit die Aufgaben des Scrum-Teams. Das führt primär zu mehr Kosten, mindert aber das Gesamtrisiko. Es wird dadurch verhindert, dass das Produkt über die Marktreife hinaus gebaut wird, erst sehr spät einen Markteintritt erfährt und dann dem Unternehmen nicht klar ist wie es das Produkt zum Kunden bekommt. Viel zu oft scheitern Produkte nicht an der Technik sondern daran, dass erst viel zu spät mit Vertrieb und Marketing begonnen wurde und die benötigte Vertriebsinfrastruktur nicht vorhanden ist. Dies wiederum führt zu enormen organisatorischen Kosten beim Markteintritt.
Involvieren von internen Stakeholdern
Ein weiterer versteckter Kostentreiber für Digitalisierungsprojekte sitzt oft in den eigenen Unternehmensreihen. Wenn interne Stakeholder wie Marketing-Abteilungen oder IT-Abteilungen nicht eingebunden werden, kann die bei der Einführung des digitalen Produkts oder der Vermarktung zu hohen Mehraufwand und hohen Kosten führen. Daher ist es ratsam Entscheider aus anderen Abteilungen, zu denen das Projektteam eine gewisse Abhängigkeit hat, frühzeitig ins Projekt einzubinden. Wenn beispielsweise bei der Umsetzung des digitalen Produkts die Corporate Identity nicht berücksichtigt wurde, dann kann dies vor der Veröffentlichung des Produkts noch zu erheblichen Mehrkosten führen, oder eine Veröffentlichung verhindern.
Projektmarketing
Ein ebenso großer und nicht zu unterschätzender Faktor für den Projekterfolg ist ein gutes internes Projektmarketing. Wird es verabsäumt hier intern das Projekt gut zu vermarkten kann es zu erheblichen Mehrkosten führen. Daher muss der Product-Owner nicht nur Entscheider anderer Abteilungen sondern auch Führungskräfte und Projektsponsoren am aktuellen Stand halten und für gute Stimmung sorgen. Es ist wichtig dass die direkten Führungskräfte immer im Bild sind und ein kompetenter Eindruck vom Team vermittelt wird. Andernfalls könnte es sein dass Ressourcen abgezogen werden oder Entscheidungen von außerhalb des Teams getroffen werden die zu Mehrkosten führen.
Testen
Viele unterschätzen den Aufwand der bei Softwareprojekten ins Testen gesteckt werden muss. In einem durchschnittlichen Entwicklungsprojekt wird von 10-50% Testaufwand ausgegangen24. Andere Quellen25 rechnen auch oft mehr als 50% des Projektaufwandes dem Testaufwand zu. Um manuelle Testzeit zu sparen gibt hat sich im Software-Engineering die Verwendung von Frameworks für Testautomatisierung durchgesetzt. Dabei werden Unit-Tests und Integrationstests entwickelt die dann automatisch durchgeführt werden können. Dies ersetzt jedoch nicht manuelle Systemtests und Akzeptanztests26. Das sind natürlich Kosten die ins Projektbudget eingeplant werden müssen. Werden diese Kosten nicht eingeplant und spart das Team am Testaufwand, so führt dies meist dazu dass Fehler und Instabile Systemteile veröffentlicht werden was im Nachgang dann zu massiveren Kosten führen kann.
Schlechtes Change-Management und schlechte Einführung des Produkts
Immer wieder werden die Change-Management aufwände eines Digitalisierungsprojekts unterschätzt. Neue digitale Produkte zu betreuen und einzuführen bedeutet immer auch große Veränderungen in der Aufbau- und Ablauforganisation eines Unternehmens. Bei derart massiven Änderungen ist es nur Menschlich dass Gefühle aufkochen und es zu Ängsten und Widerständen kommt. Genau damit muss professionell umgegangen werden. Es müssen Widerstände abgebaut und Ängest genommen werden und ein professioneller Change-Prozess durchgeführt werden. Diese Change-Management27 muss von erfahrenen Coaches begleitet werden und das sind wiederum versteckte Kosten die oft in der Kalkulation nicht berücksichtigt werden. Ein effektives Mittel um Mitarbeitern die Bedenken zu nehmen ist es diese gut auf die Einführung des Produkts zu schulen. Egal ob die User innerhalb oder außerhalb des Unternehmens sitzen benötigen diese eine gute Einführung in das Produkt. Es müssen Informationsmaterialien, Blogs und Tutorials geschrieben werden all dies sind ebenfalls Themengebiete die viele nicht am Radar haben und letzten Endes zu hohen Zusatzkosten führen.
Keinen Support, keine Wartung
Selbst wenn bei der Einführung der Software alles richtig gelaufen ist können im Betrieb massiv Kosten entstehen. Der Betrieb, die Wartung und Pflege als auch der Support von Software ist aufwändig und beträgt oft zwischen 60 % – 80 % der Gesamtkosten28 29. Wird den Kunden kein oder nur schlechter Support bzw. Wartung durch das Unternehmen angeboten werden diese über kurz oder lang die Software nicht mehr einsetzen wollen. Ein Wirtschaftlicher schaden kann bist zum Totalausfall des digitalen Produkts gehen. Die Kosten wären extrem hoch. Oft werden aber die Kosten für Wartung und Support massiv unterschätzt und erst nach Einführung der Software werden Support und Wartungsteams aufgebaut. Diese Kosten werden dann oft erst nachträglich in der Projektabrechnung sichtbar und somit stellt sich oft ein kleinerer Gewinn ein als ursprünglich erhofft.
Schlechter Umgang mit Bugs
Ein weiterer Punkt der im Nachgang der Entwicklung des digitalen Produkts zu zusätzlichen Kosten führt ist der Umgang mit Bugs. In jeder Software könne Bugs auftreten. Treten Bugs auf so ist es essentiell wie das Unternehmen mit diesen Fehlern umgeht. Es hat sich mittlerweile herausgestellt dass es für Unternehmen sinnvoll ist Fehler und Bugs einzugestehen und professionell und rasch diese zu beseitigen. Damit dies Möglich ist muss allerdings ein Team an Technikern und Softwareentwicklern jederzeit einsatzfähig sein und bereit sein die Fehler auszubessern. Dies Verursacht wiederum Kosten die oft zu Projektbeginn nicht berücksichtigt wurden. Geht ein Unternehmen schlecht mit Bugs um, versucht diese zu vertuschen oder braucht zu lange um diese auszubessern ist dies jedoch noch kostspieliger und riskanter, dann dadurch wird riskiert Kunden zu verlieren und eine Software die sich nicht gut verkaufen lässt ist die teuerste Software die es gibt.
Digitalisierungsprojekte sind ein Investment welches sich lohnen muss. Um dies festzustellen müssen zahlreiche versteckte Kostentreiber berücksichtigt werden. Als Verantwortlicher in einem Unternehmen ist es notwendig die Richtigen Entscheidungen zu treffen und die richtigen Investitionen zu tätigen um Kosten vermeiden zu können. Dabei sind die organisatorischen Kosten und Kosten im Nachgang nicht zu vernachlässigen, da hier massive Mehraufwände drohen können.
1Effort Distribution in Model Based Development, W. Heijstek et. al. 2007 Fig. 4
2Anecon Präsentation: https://images.app.goo.gl/dyj4hohheJcE7HAb8
3http://www.pawanjaswal.com/2013/08/conventional-approach-to-test-effort.html
4Universität Stuttgart IAS 2015 – 5 Wartung und Pflege von Software (Punkt5.1.) Folie 212 https://docplayer.org/2745460-5-wartung-pflege-von-software.html
5Technische Universität Kaiserslautern – Professor Dr. Liggesmeyer – GSE Abnahme und Wartung Folie 34 https://silo.tips/download/grundlagen-software-engineering-abnahme-und-wartung
6https://digitalisierungscoach.com/2018/12/05/change-management-in-der-digitalisierung/
7https://digitalisierungscoach.com/2020/01/31/der-einsatz-des-kano-modells-in-der-entwicklung-digitaler-produkte/
8https://digitalisierungscoach.com/2020/07/03/personas-verwenden-fuer-die-digitalisierung/
9https://digitalisierungscoach.com/2020/06/25/das-value-proposition-canvas-als-ausgangslage-fuer-die-entwicklung-digitaler-produkte/
10https://digitalisierungscoach.com/2020/08/13/was-ist-product-market-fit/
11https://digitalisierungscoach.com/2018/10/21/scrum-auf-diese-dinge-sollten-sie-als-product-owner-bei-der-priorisierung-achten/
12https://digitalisierungscoach.com/2018/11/20/design-thinking/
13https://digitalisierungscoach.com/2018/11/23/lean-startup-und-die-digitale-transformation-in-industrie-4-0-und-konzernen/
14https://digitalisierungscoach.com/2018/12/11/design-thinking-agile-entwicklung-lean-startup-change-management-growth-hacking-die-5-wichtigsten-methoden-fuer-die-digitalisierung/
15https://digitalisierungscoach.com/2020/01/19/staerken-digitaler-produktentwicklung/
16https://digitalisierungscoach.com/2018/11/02/outputorientierte-vs-outcomeorientierte-scrum-teams/
17https://digitalisierungscoach.com/2018/11/02/outputorientierte-vs-outcomeorientierte-scrum-teams/
18https://digitalisierungscoach.com/2020/03/21/agiles-produktmanagement-und-user-experience-ux/
19https://digitalisierungscoach.com/digitalisierung/scrum/scrum-meetings/sprint-review/
20https://digitalisierungscoach.com/2020/08/13/was-ist-product-market-fit/
21https://digitalisierungscoach.com/2020/08/13/was-ist-product-market-fit/
22The lean Product-Playbook von Dan Olsen Mai 2015
23https://digitalisierungscoach.com/2018/11/30/growth-hacking-in-der-digitalen-transformation/
24 Frühauf et al. (2002), Software-Projektmanagement und -Qualitätssicherung, 4. Aufl., Zürich 2002 Seite 16.
25 Kit, Edward (1995), Software testing in the real world: improving the process, New York u. a. 1995
26https://digitalisierungscoach.com/2020/06/20/softwarequalitaet-testen-und-unittesting/
27https://digitalisierungscoach.com/2018/12/05/change-management-in-der-digitalisierung/
28Technische Universität Kaiserslautern – Professor Dr. Liggesmeyer – GSE Abnahme und Wartung Folie 34 https://silo.tips/download/grundlagen-software-engineering-abnahme-und-wartung
29Universität Stuttgart IAS 2015 – 5 Wartung und Pflege von Software (Punkt5.1.) Folie 212 https://docplayer.org/2745460-5-wartung-pflege-von-software.html
Kommentar verfassen