Der nächste Abschnitt 3-2 hat den Titel Fehler Fortpflanzung
und es geht tatsächlich um etwas, sich fortpflanzen.
Wie wirkt sich das aus? Die dazugehörige Frage ist die Frage,
Moment, ich schalte mal schnell zurück zu der Seite mit den Fragen, Folie 2.
Da geht es darum, den Zusammenhang zwischen dieser Fehlervorweihzeit und
den Fehlerbehebungskosten zu erklären,
das darstellen zu können
Es geht, häufig haben wir, erkennen wir Fehler erst daran,
dass sie irgendwo eine Wirkung entfalten,
dass sie also zu einer Störung führen, dass sie ein sichtbares Fehlverhalten.
Und dann ist es häufig ganz schwierig, den Fehler,
die fehle Ursache zu finden, die Rückfahrt, Rückfahrt zu verfolgen.
Das eigentliche Debugging, wenn man sagt, okay,
ich finde, behebe den Fehler,
ist das wirkliche Beheben nur ganz geringen Aufwand,
das deutlich aufwendigerer ist, das Finden, das Auffinden der Ursache.
Gerade manchmal gibt es so Fehler,
die nur selten auftreten
Dabei ist zu beobachten, dass wir manchmal Fehler zu finden haben,
die eigentlich viel früher entstanden sind. Und da kommt man darauf,
dass nicht diese Rückverfolgung nur sehr viel schwieriger ist,
sondern es ist doch sehr viel besser wäre,
wenn wir das finden würden,
bevor wir Folgeschritte auf diesen Federn aufbauen.
Denn Entwicklungsschritte, die Fehler produzieren, haben Nachgefolger,
das heißt die Vorläuferprodukte, die schon fehlerhaft sind,
bauen darauf auf. Und wenn wir dann überarbeiten müssen,
müssen wir nicht nur das überarbeiten,
wo der Fehler entstanden ist,
sondern wir müssen auch das überarbeiten,
was alles darauf aufbaut
Alle Entwicklungsschritte, die darauf aufbauen müssen, wiederholen.
Neudeutsch, Rework, Arbeit nochmal machen. Und je umfangreicher,
je später wir etwas erkennen, desto umfangreicher ist dieser Rework.
Das Ziel muss also darin bestehen,
und das ist der Inhalt, das ist das,
was ich eben mit dieser Einheit kurz erklären möchte,
sie motivieren möchte, versuchen sie frühzeitig Fehler zu finden.
Deswegen ist das eigentlich nicht die Fehlerfortpflanzungszeit, sondern eher die Fehlerverweilzeit,
wenn wir es noch genauer wollen, auch nicht die Zeit allein,
sondern die Und die Menge der Schritte, die darauf aufbauen,
wo man noch Fehler weiter mit Fehlern arbeitet.
Ja, ganz Extremfall, ein falsch verstandenes System.
Und das ist der eigentliche Schlüssel zur Produktivitätssteigerung.
Wir können Produktivitäten der Softwareentwicklung nicht dadurch steigern, schneller arbeiten.
Und in vielen Projekten können wir auch und wollen wir auch nicht dadurch die Produktivität steigern.
Das ist auch nicht Produktivität, dass wir mehr arbeiten.
Wir können maximal das Output steigern. Und keiner ist zehn Stunden
am Tag wirklich konzentriert, sondern was wir wirklich vermeiden können,
ist, verringern können, ist dieses Rework.
Und darum möchte ich es jetzt, also es gehen in
meine Argumentation, möchte ich aufbauen mit einem kleinen Zeitstrahl.
Ich habe hier nicht wirklich die Zeit aufgetragen,
sondern eher die Entwicklungsphasen, Einforderungsanalyse, Entwurf, Implementierung,
Integration, die in Betriebnahme und der Betrieb, ja, Anforderungsanalyse sehen.
Klar, ich verstehe den Anfänder, was er denn macht.
Im Entwurf setze ich das um, was ich verstanden habe,
ja, irgendwo ist dazwischen auch die fachliche Analyse,
setze ich um in eine technische Lösung, dann Implementierung,
ist im Wesentlichen, also ich verwirkliche das in Consumer Rekorationen von existierenden Produkten in technische Entscheidungen in Code schreiben.
Ich baue das Ganze zusammen, bei der Inbetriebnahme geht es um Nutzerschulung,
um Datenübernahme, um Dinge passend zu machen,
zu konfigurieren und während des Betriebs habe ich immer noch Fehlerbewirkungen oder Fehler zu beheben,
weil man falsch das benutzt vielleicht oder so etwas.
So, jetzt relativ und diese Achse,
die senkrechte Achse habe ich hier logorithmisch, das heißt,
das sieht irgendwie so aus, dass wir hier Werte haben wie Eins,
ähm, zehn, 100, 1000,
vielleicht können wir das noch unterteilen in, ähm,
in das wir hier dazwischen irgendwo die drei haben und hier die 30 und hier die 300.
Irgendwie sowas ist das, ähm, ist das ein lokorithmischer Wert.
Und diese Werte sind auch nur relativ, es steht keine Maßeinheit dran.
Wir nehmen also das erste Mal als Faktor ein,
so lassen sie uns durchaus anfangen. Wir haben einen Fehler
in den Anforderungen Wir haben Anforderungen irgendwie falsch verstanden. Nicht,
dass wir gleich komplett die Datenstrukturen falsch verstanden haben,
sondern vielleicht einfach nur irgendwo einen Aspekt in der Fehlerreaktion,
die, wenn nicht richtig verstanden haben,
die sich der Kunde anders gedacht hat oder fachlich anders,
wie es fachlich anders korrekt wäre.
Und wenn wir den beheben, ja, das bedeutet,
wir müssen die Anforderungsanforderungsdokument etwas umschreiben.
Vielleicht ist da ein Aktivitätsdiagramm, was wir überarbeiten müssen,
dann müssen wir es nochmal prüfen. Ist das so richtig?
Spiegel mit dem Urheber? Dann nehmen wir mal an,
das wäre der Wert 1. Ja, so relativ,
ob das jetzt eine Stunde oder ein Tag ist,
sei jetzt
mal dahingestellt
Wenn wir das im Entwurf erst finden, diesen Fehler,
wenn er es im Urentwurf uns auffällt, wir bauen eine Architektur,
wir stellen fest, welche Komponenten haben welche Aufgaben,
wir ordnen Aufgaben zu Komponenten zu,
also was passiert ja im Entwurf.
Wir entwickeln ein fachliches Modell, dann ist der Aufwand schon etwas höher.
Ich möchte mal hier den Faktor 3 annehmen. Das ist
natürlich irgendwie etwas grob, aber wir müssen ja mehreres überarbeiten.
Wir müssen nicht nur den Entwurf überarbeiten und die ganze Zeit für den Entwurf ist dann verloren,
sondern vielleicht hat er sich beim Auswirkungen,
obwohl das eigentlich nur ein Use-Case betraf,
auswirken auf mehrere Teile des Entwurfs.
Deswegen ist der Aufwand größer
Schon Faktor 3. Wenn wir angenommen,
wir entdecken den Fehler nicht, dem Entwurf,
sondern wir entdecken ihn eben später erst in der Implementierung.
Das heißt, während des Tests fällt uns auf,
oh, das und das ist ein falsches Verhalten zum Beispiel.
Dann wäre der Wert schon etwas höher. Ich nehme mal
wieder den Faktor 3 ungefähr. Das würde also ungefähr bei
der 10 landen. Wir sind ja hier wirklich sehr allgemein.
Deswegen ist die Genauigkeit hier nicht so hoch. Das ist deswegen
höher, weil wir nicht nur den Entwurf überarbeiten müssen,
sondern auch Anpassungen an der Embition
Elementierung vornehmen müssen, vielleicht Entscheidungen über Technologien revidieren.
Das ist ein gigantischer Aufwand, wenn wir vielleicht nochmal die Plattform wechseln.
Und die Tests müssen wir natürlich auch nochmal machen. Wenn wir es aber,
angenommen wir merken es dann, dann ist das schon schmerzlich,
aber noch schlechter ist es, wenn wir es später erst merken,
wenn wir es erst merken, bei der Integration, beim Zusammenmenbauen,
zu einem größeren System und bei den größeren Tests, die dann sind.
Und dann nehmen wir mal den Wert wiederum dreifach höher.
Das ist so eine Daumenregel, die sich aus Erfahrungen von verschiedenen Projekten ableiten lässt.
Es gibt sogar Autoren, die sagen zehnfach jedes Mal,
ich gehe hier von der Stufe frei, das wäre entsprechend später entsprechend höher. Der Aufwand,
wenn wir es bei der Inbetriebnahme erst merken,
wir haben es schon an tausende Versionen,
tausend Stationen vielleicht installiert, wir haben die Nutzerschulung,
sind schon alle gelaufen und alle wollen damit starten und wir fangen an,
die Daten zu übertragen und dabei merken wir, oh,
da stammt was nicht,
dann hätten wir hier schon wieder dreifach mehr Faktor 100 insgesamt ungefähr.
So, wenn es während des Betriebs erst auftritt,
dann ist das natürlich nochmal ein Stück schwieriger und hier wäre
dann der Faktor
So, wenn Sie sich vorstellen,
das Ganze wäre jetzt mit dem Faktor 10 gerechnet,
ja, dann wären wir jetzt schon deutlich höher,
dann wäre das hier die Zehen und dass die 100 und dass die 1000,
dass die 10.000, dass die 100.000. Das kann schnell passieren,
weil wir ja nicht berücksichtigt haben,
was wir an Reputationsverlust, an Gesichtsverlust heißen.
Das heißt so schon, schon wieder haben die Informatiker
das falsch gemacht, schon wieder.
Dabei haben wir nur hier vorne etwas Kleines nicht verstanden.
Wie jetzt nochmal zu diesem Punkt auf der vorhergehenden Folie,
die Fehler pflanzen sich fort
Müssen die Dinge, die Vorläuferprodukte überarbeiten, wiederholen wie Rehwork.
Dadurch wird das so aufwendig. Und das ist deswegen sollten wir versuchen,
Fehler, die in der Anforderungsanalyse auftreten, auch hier zu finden.
Fehler, die im Entwurf auftreten, auch hier zu finden,
Fehler in der Mantierung auch hier zu finden und nicht eben erst,
wenn sie beim Auftraggeber, beim Kunden, beim Anwender angekommen sind.
Das ist die Einleitung dafür, dass wir in den Folgeschritten,
wir reden zwar erst über Tests,
aber dann reden wir über Inspektionen, Inspektionen sind etwas,
was ich auch mit Anforderungsanalyse und Entwurf
schon machen kann
Kann ich erst mit Implementierung machen. Das werde ich noch ein paar Mal erzählen,
weil das so wichtig ist, dass wir frühzeitig testen. Ja,
wenn wir jetzt einfach mal das gleiche Diagramm nehmen und sagen,
okay, ein Fehler ist ein Entwurf, wird aufgetreten,
dann wäre das hier die Schiene 1, ja,
Aufwand, Behebungsaufwand 1 und dann wäre es mal drei,
mal zehn, mal 30, mal 100.
Also auch hier haben wir den gleichen Faktor, wir sollten versuchen,
das zeitig zu erheben und das wäre auch gleich die Antwort auf die Frage,
was ist der Zusammenhang, der Zusammenhang ist über dieses Rework,
ja, das ist die Frage, ne,
eins zurück, ja,
über die Folge vor Schritte,
das ist das Problem