So, wir setzen fort im Abschnitt 1.2, also wir sind hier im Kapitel 1
und beantworten die Frage der Änderungen. Wir hatten gerade gesagt,
dass Änderungen und, nein, das war hier,
dass ein gewisser Konflikt durchsteht zwischen der Forderung nach hoher Stabilität und gleichzeitig,
das ist das, die lange Nutzungsdauer, die wir brauchen,
weil das System halt die Geschäftsprozesse unterstützt und deswegen geschäftskritisch ist und den häufigen Änderungen,
die daraus resultieren, dass wir viele Sachen haben in der Umgebung,
die sich ändern.
Aber warum ist das überhaupt ein Problem?
Na, das sollte sich jetzt hier schieben lassen.
Ja, hier tut es das. Und da brauchen wir
einen schwarzen Stift. 1.2 Auswirkungen von Änderungen auf Langfristige Nutzbarkeit
Damit beziehen wir uns auf die Frage 1 und 2,
die Änderungen für die Anwendbarkeit eines solchen Systems.
Und die Rolle des Re-Engineering, die dabei entsteht.
Einerseits haben wir gerade festgestellt, wir haben komplexe Systeme,
komplex im Sinne von viele Teile, Viele Beziehungen,
viele Abhängigkeiten darin.
Vielleicht können wir noch sagen, große Systeme.
Und deswegen ist es schwierig, diese Systeme zu verstehen.
Zunächst können wir erstmal einfach sagen,
wir brauchen einen hohen Aufwand.
Für das Verstehen
Das ist erst mal so weit einleuchtend, aber es kommt noch zusätzlich hinzu,
dass man auch für das Durchführen einer Änderung,
wenn viele Abhängigkeiten bestehen, viele Sachen zu berücksichtigen hat.
Also für das Verstehen, weil einfach viele Abhängigkeiten
zu erfassen sind und für das Durchführen von Änderungen,
weil viele Sachen zu berüchtigen, sich nur bitteschön alle korrekt.
Das führt dazu, Das Fehler entsteht. Menschen machen Fehler
, das ist keine Überraschung. Man sagt typischerweise, Menschen
machen drei Prozent Fehler. Das bedeutet also schon bei,
wenn man sich ganz viel Mühe gibt übrigens, ein Prozent Fehler.
Also sehen wir an, wir geben uns alle
ganz viel Mühe und machen nur ein Prozent Fehler.
Das bedeutet bei 100 Anweisungen ist vielleicht eine falsch.
Bei 10.000 Lines of Code, das ist wirklich ein kleines
System, dann hätten wir 100 Fehler eingebaut.
Ja, also das ist schon mal Risiko von Fehlern.
Das ist schon mal ein wesentliches Problem. Wenn Änderungen unvollständig,
solche Fehler können sein, Änderungen passieren unvollständig oder Zusammenhänge sind
nicht komplett verstanden
Änderungen werden also wirklich falsch durchgeführt. Oder manchmal auch einfach
nur unvollständige Sachen. Das soll eine Klammer sein hier,
unvollständige Sachen führen dazu, dass Änderungen nicht nachgeführt werden.
Nachgeführt als Strukturänderungen
Was meine ich damit? Damit meine ich so etwas wie,
ich mache eine Ergänzung eines Datenbankfelders und noch eine Ergänzung eines Feldes,
eine Spalte in einer Tabelle,
eines Datenbankfeldes und noch einem, noch eine.
Aber irgendwann wird die Tabelle zu groß. Ich soll sie die Tabelle splitten.
Ich sollte die Datenbank umstrukturieren. Das hat aber zur Folge,
dass ich dann weitere Änderungen machen muss in der Anwendung,
auf die auf diese Datenbank zugreift.
Das ist schwierig. Oder ich füge zu einer Klasse
eine Methode hinzu
Nach einer Weile führe ich noch eine Methode zu und dann
noch eine Methode. Irgendwann wird diese Klasse zu groß,
zu unübersichtlich, sie kümmert sich um mehrere Sachen,
das ist kein gutes Design mehr, wir sollten diese Klasse aufteilen.
Und diese, wenn das nicht passiert, haben wir so etwas wie Strukturverlust.
Ja, und diese Strukturverlust, der führt dazu,
dass Nachfolgende Änderungen Mit noch höherer Fehlerquote oder höherem Aufwand.
Passier. Also das ist tatsächlich ein großes Problem,
was wir hier haben
Wir haben also hier einen Konflikt zwischen Änderungen,
die durchgeführt werden müssen und langfristiger Nutzbarkeit, die dazu führt,
dass diese Qualität sinkt und das ist das eigentliche Problem für die Nutzbarkeit.
Damit hätten wir, haben wir das große Risiko,
wir müssen etwas dafür tun, das große Risiko besteht darin,
dass wir die Software nicht lange verwenden können und das Risiko besteht darin,
dass wir jetzt die Änderungen einerseits nicht machen,
andererseits nicht vollständig machen.
Und jetzt die Nutzbarkeit riskieren. Wenn wir nochmal die Frage anstauen,
so steckt in der Frage 1 auch noch drin,
dass wir hier Re-Engineering durchführen.
Tatsächlich kommt hier der erstmalig der Begriff Re-Engineering bei Re-Engineering,
sollen wir, geht es ja darum,
die Änderungen nochmal zu machen, Änderungen nochmal.
Da werden wir uns langsam der Sache annähern.
Wir gehen erstmal zum nächsten Punkt zum Begriff Wartung