Nun kommen wir zum letzten Punkt des Kapitels Einordnung.
Da geht es um den Begriff Re-Engineering und die Abgrenzung von der Ablösung durch ein neues System.
Dazu haben wir eine ganze Reihe von Fragen,
nämlich die Fragen von Fragen 5 bis 8 hier,
die wir, also die Risiken der Ablösung durch ein System,
die Begriffe und wie geht man dabei vor?
All die werden wir jetzt in diesem Abschnitt behandeln
Wir setzen die Überschrift 1.5,
ist das Le-Engineering versus Ablösung.
Es soll ein Ö sein
Entwickeltes System. Re-Engineering, wobei, worum geht es dabei?
Wie Engineering in 9, nicht ganz so. Engineering,
da haben wir Folien dazu, Re-Engineering nochmal, das Engineering durchführt.
Lassen Sie uns die Folien auf die Begriffe mit den Folien dazu nutzen.
Zunächst, es gibt eine ganze Reihe, solche Begriffe mit R. Ja,
diese Erbegriffe, fangen wir mal an mit Reverse Engineering.
Ich habe hier drei schon recht alte Definitionen gebracht und hier unten sehen sie,
dass es hier mit dem Laserpointer auch machen, ja,
werden wir betrachten, den normalen Ablauf,
die Folge von Tätigkeiten, egal ob Wasserfall oder nicht,
wir haben ja immer so eine Folge,
man beginnt mit Anforderungen, macht sich Gedanken über die Struktur,
ob man das jetzt Ende Wurf nennt,
Design und kommt dann dazu, dass man Code entwickelt,
das wäre diese Richtung hier mit weißen Pfeilen dargestellt,
das Vorwort Engineering
Und das Gegenüber, dem Gegenüber, das Reverse Engineering,
der erste dieser Begriffe, mit R, mit Re, Reverse Engineering.
Klingt so ein bisschen wie Re-Engineering, ist aber doch was anderes.
Der nächste Begriff, den wir manchmal haben, gibt es,
heißt Recovery, etwas weder herherstellen oder Redokumentation nochmal dokumentieren.
Ja, also Recovery gibt es vor allen Dingen als Architekturrekonstruktion.
Die Architektur ist uns verloren gegangen, wir versuchen sie wieder herzustellen.
So ist auch die deutsche Erläuterung dazu, ja,
Reverse Engineering mit dem Ziel, die Architektur wiederherzustellen,
ja auch schon relativ alte Definitionen, das sagt uns schon durchaus,
dieses Problem gibt es schon lange.
Ja, wenn man jetzt mal wiederum das Betrachten in dem Bildchen wieder,
wir haben die Anforderungen, Entwurf und Code,
dann bezieht sich das Rekonstruieren.
Ich schaue mir den Code an und versuche zu verstehen,
was für Entwurfsideen dahinterstehen. Das ist das Rekonstruieren der Architekturekonstruieren
des Entwurfs. Und ansonsten die Redokumentation bedeutet,
ich dokumentiere nochmal, also ich habe vorher Code,
habe hinterher wieder Code,
aber besser dokumentiert
Ich habe vorher einen Entwurf, aber ich habe ihn dann aktualisiert.
Ich habe die Beschreibung verbessert. Das Gleiche kann es auch für allen Förderungen geben.
Ich habe vorher Anforderungen, bin aber nicht sicher,
ob ich sie gut verständlich habe oder es fehlen Teile,
deswegen führe ich das nochmal durch.
Und dann haben wir noch einen weiteren Begriff mit Refondran,
Restrukturierung, Refactoring. Refactoring, denke ich,
kennen Sie alle, weil es zu dem objektorientierten Grundvorrat gehört.
Restrukturierung, ja, wir wollen es irgendwie in vom etwas neu machen. Ja,
hier ein bisschen eine abstrakte Definition von Chikowski und Cross,
schon mittlerweile 30 Jahre alt, Transformation in einer anderen, auf derselben Ebene.
Das heißt, von Code Tukot, aber besser strukturiert,
von Entwurf, Zuentwurf, aber besser strukturiert,
vollen Anforderungen zu Anforderungen, besser strukturiert und bei Code,
da gibt es diesen Begriff Refactoring dazu.
Ja, also den Begriff Refactoring,
der ist vor allen Dingen gebräuchlich für die Restrukturierung von Code,
während Restrukturierung ansonsten in Allgemeinautbegriff ist. Ja, so,
jetzt haben wir schon ganz viele zusammengetragen und nun,
wenn wir diese Bildchen mal alle übereinander legen,
alles das zusammen, zeichnen wir mit dem Sammelbegriff Re-Engineering.
Also zum einen wollen wir es untersuchen, analysieren,
das wäre das Reverse-Engineering, ja, diese Analyse,
dann die Änderung des Systems, das wäre durchaus ein bisschen Vorwort-Engineering,
ja, aber das Ganze, um zur Abgrenzung von normalen Entwicklungstätigkeiten,
es geht darum, dass wir keine Änderungen der Funktionalität direkt vorsehen.
Also es geht darum, die gleiche Funktion zu haben, nur mit einer besseren Struktur.
Und das bringt uns wieder zurück zu dem Staged Murdle,
wo es darum ging, Wartbarkeit zu verbessern. Ja,
da in der Praxis das immer ein bisschen schwierig ist,
weil der Kunde möchte ja eigentlich neue Funktionalität,
geänderte Funktionalität haben und dafür möchte er bezahlen und Softwarequalität ist leider
für den Kunden ein wenig sichtbares Konzept, ein wenig sichtbares Problem.
Wir werden dazu ganz häufig in dieser Lehrveranstaltung kommen,
wie die Praxis des Projektmanagements darauf Rücksicht nehmen muss.
Das ist etwas, was ich Ihnen gerne auch hier mitgeben möchte.
Deswegen macht man das häufig,
dass man es doch eben nicht so ganz klar keine Änderung der Funktionalität ganz klar trennt,
sondern es gibt halt diese Erweiterung des Re-Engineering,
dass man tatsächlich erst Ich unterstreiche das zweimal, dieses Dun hier.
Man analysiert das und da um danach gleich die Funktionalität zu werden.
Man verbindet die Sachen also miteinander. Während das Rhein-Re-Engineering die Funktionalität nicht ändert,
dass danach das ändert, hier, das ändert man.
So, für diese Tätigkeiten des Re-Engineering, dieser Darstellung,
über diese drei Ebenen, gibt es noch einen ganz schön anschauliches Modell.
Das sogenannte Horrorschuhmordel, Horrorschuh, der Pferdehuf,
der soll uns diese Sachen zusammenstellen.
Ich habe hier mal eine Literatur von Casman genommen
Einen der Nestorinnen der Softwarearchitektur und Softwarequalitätsliteratur. Ja, und
ich habe hier dargestellt. Also zunächst sehen wir erstmal hier
drüben das Vorwort Engineering. Wir fangen an mit Architektur,
mit Anforderungen, machen einen Entwurf, eine Architektur,
machen Funktionalität daraus. Und am Ende haben wir Quellcode.
Ja, und der wird natürlich irgendwo zum Sourcecode übersetzt.
Das ist das klassische Vorwort Engineering
Wir hatten noch das Reverse Engineering, das wäre das Gegenüberliegende.
Das heißt, wir haben den Quellcode und wollen den Quellcode verstehen.
Das wäre also hier von da nach da, das wäre
sozusagen das Entwurf wiederherstellen. Oder hier zur Architektur wiederherstellen.
Das war Recovery, diesen Begriff Recovery hat mir,
und manchmal muss man auch dahin gehen, die Anforderungen wiederherzustellen.
Ja, dann hatten wir diesen Begriff Restructuring immer auf der
gleichen Ebene. Architektur zur Architektur, Funktionalität,
wieder restrukturieren oder auch nur durch den Code restrukturieren.
Ja, also dann diese Ebene. Und da das Ganze
in diesem Kreis passiert, sprechen wir,
hat das sich hier der Name Horst Schuhmodel
dafür eingeprägt
Ja, hier gibt es noch eine zweite Zeichnung von jemandem anderes.
Ich habe hier nicht mal mehr den Namen mir notiert,
das habe ich schon sehr lange mal irgendwo gefunden.
Da war das noch nicht so ganz üblich,
so ganz genau auf die Quellen zu haben.
Also wenn jemand den Tipp hat, wo das jetzt herstammt,
dann würde ich das gerne ergänzen.
Bitte um Hinweise, falls ich da mal irgendwo drauf stoßen.
Das war also irgendwie ein Kollege, der das in seinen
Folien mal hatte. Ich bin aber leider nicht mehr,
komme nicht mehr nach, wo es herkommt. Ja,
also letztlich sehen wir hier, hier sind viel mehr Pfeile,
hier sehen Sie das, was ich gerade sagte,
Restrukturierung auf der gleichen Ebene oder hier, Blauüberarbeitung nochmal hier rüber,
das Recovery, was wir eben hatten, als von unten nach oben.
Ja, und natürlich das klassische Vorwort-Engineering hierüber auch. Ja,
also das zeigt das Ganze mit ein bisschen mehr Pfeilen.
Das bringt uns zu der Frage, was davon müssen Sie
in der Prüfung wiedergeben können? Sie müssen den Inhalt verstanden haben können,
das ist auch der Vorteil, den wir eine mündliche Prüfung miteinander durchführen,
dass ich Sie nachfragen kann, dass Sie mir erklären können,
uns erklären können,
wie Sie
das Ganze verstanden haben
Ja, soweit zu den Begriffen lassen Sie uns zu den Fragen gehen,
hier vorne, ja, also das wäre die Frage sechs,
erläutern Sie die Begriffe, Reverse-Engineering, Re-Engineering,
Refactoring oder die Frage 9,
erklären Sie die Vorgehensweisen mithilfe des Hors Schulmeutels.
Dazwischen gibt es die Frage 8,
die eigentlich genau die gleiche Antwort erwartet,
wie die Frage 9, was ist denn das typische Vorgehen?
Ich gehe mal wieder ganz nach hinten
zu denen
Zu diesem Hochschuhmodel, ja, also das Vorgehen wäre,
egal ob sie das oder das Bild nehmen,
das Vorgehen wäre ja, dass ich erst mal verstehen muss.
Ich habe meistens den Code, als die wirklich sichere Quelle bei der Architekturbeschreibung,
die so weit bin ich nicht ganz sicher, ob die aktuell ist.
Ich muss es erst mal verstehen, ja,
das ist dieses Reverse-Engineering, um am Ende dazu zu kommen,
welche Anforderungen stehen denn hier überhaupt hinter, so für was tut die Software?
Das sind ja eigentlich Anforderungen, was sie tut. Ja,
und dann kommen neue Anforderungen, Änderungen, irgendwas dazu und Verbesserungen, Restrukturierung.
Das heißt, es geht hier wieder rüber. Das heißt,
erst steht immer das Verstehen, zuordnen, zur Funktionalität,
die wir eigentlich irgendwie ändern wollen,
die Veränderung getroffen ist oder was sind die relevanten Teile für eine bestimmte Funktionalität und dann kommt das Vorwort-Engineering.
Das wäre so das ganz grundsätzliche Vorgehen,
was am Ende auch wieder durchaus dem Vorausschuhmodel spricht.
Ja, damit haben wir schon ziemlich viel erklärt,
aber die Frage 5 und die Fragen, Frage 7 steht noch offen.
Ich möchte erst mal dazu kommen zur Frage 7,
denn Risiken des Reengineering, wenn das,
was ich Ihnen alles jetzt gerade erklärt habe,
mit dem Stage Model und das ist geschäftskritisches System,
es sind so, kann man nicht anderes akzeptieren,
als im Zustand Evolution und da müssen wir hinkommen durch Reengineering.
Ja, dann gibt es doch gar keine Alternative, oder?
Das Problem ist aber, in der Praxis findet Reengineering selten
viel zu selten statt und wenn man sich dann dazu entschließt,
häufig zu spät. Und das hat seinen Hintergrund nicht darin,
dass die Leute faul sind oder dass sich das jetzt nicht trauen,
die Risiken nicht eingehen wollen,
sondern dass die Risiken einfach gigantisch groß sind.
Lassen Sie uns deswegen kurz auf die Risiken eingehen
Tatsächlich? Sind Leute, sind die Entwickler, sich der Risiken
sehr bewusst? Ja, sie kennen alle diesen Spruch,
never change a winning team und das bezogen auf Softwareentwicklung,
never change a running system.
Also wenn es irgendwie läuft, don't touch it. Ja,
also machen sie damit, ändern sie es möglichst nicht,
wenn es denn irgendwie läuft
Soweit, aber es sind ja Änderungen notwendig. Die Software
muss geändert werden und deswegen kommen wir nicht drum herum.
Wir sollten das aber sehr risikobewusst tun. Und diese Risiko,
auf dieses Risikobewusstsein ist den Entwicklern, es den Entwicklern sehr eingebrannt sozusagen.
Ja, und lassen wir uns die Risiken kurz mal benennen.
Das erste Risiko ist natürlich der hohe Aufwand. Ja,
hoher Zeitaufwand ist ein großes Risiko. Man muss sehr viel können,
man muss ja nicht nur die Änderungen durchführen können und komplexe Systeme beherrschen,
sondern man muss auch noch eine normalerweise fremde Software verstehen können.
Ja, also Man muss, braucht eine hohe Qualifikation und das
wäre das Risiko, fehlende Qualifikation. Für den Einzelnen wäre das,
ich kann das nicht, für den Projektleiter wäre das,
dass wir die Entwickler nicht haben, die das durchführen können.
Am Ende läuft es, auf das beide, beides hinaus.
Fehlende Entwickler. Und damit fehlende Entwickler meinten nicht,
dass sie gar nicht da sind,
aber für eine bestimmte Technologie
Für eine bestimmte Plattform. Für eine Sprache.
Oder sei es nur auch für die Domäne. Ja,
wir brauchen also jemanden, der dann von Versicherungssoftware was versteht,
wenn Versicherungssoftware zu ändern ist.
Oder der von Cobol was versteht oder von dieser angejahrten, sequenziellen Datenbank.
Ja, also diese Fragen, diese Qualifikation brauchen wir.
Weiteres Risiko ist, dass man das System nicht komplett versteht.
Ich nenne es mal auch fehlend.
Verständnis der es existierenden Systems. Diese Systeme wurden früher mit
anderen Technologien entwickelt, mit anderen Vorgehensweisen.
Fehlendes Wissen über frühere Entwurfstechnologien
Und Methoden. Natürlich gehört auch dazu, dass wir gerne
eine Dokumentation hätten, dass es führt zu einem Risiko,
wählende Dokumentationen, von Entwurfsentscheidungen. Oder manchmal auch tatsächlich,
wenn es sich um wirklich alte Software haltet,
dann gibt es den Rechner nicht mehr.
Dann gibt es den, auf dem für den das entwickelt
, war die Hardware.
Da gibt es den Compiler nicht mehr,
mit dem
das geschrieben war
Fehlende Ort- und Softwareblattform. Ja,
wenn Sie diese Risiken jetzt alle so betrachten,
so ist doch eigentlich schon deutlich,
dass tatsächlich viele von den Auftraggebern von den Kunden,
von den Managern auf Kundenseite Reengineering nicht so richtig toll finden.
Ja, es kostet viel, wir haben keine Leute dazu,
wir wissen gar nicht, ob da was Gutes rauskommt,
warum nicht wegschmeißen,
neu entwickeln.
Das ist doch die naheliegende Idee,
Tatsächlich ist das in ganz vielen Fällen ein wichtiger Punkt.
Hier brauchen wir eine neue Seite. Wir sehen, wie
das jetzt hier geht. Allen neue Seite unterhalten hinzuüben.
Hier ist die neue Seite. Viele Kunden sehen
in Ablösung durch Neuentwicklung
Eine gute Lösung des Problems. Tatsächlich sind das in vielen Fällen genau die Kundenauftraggeber,
die vorher einem Re-Engineering sich total verweigert haben,
weil sie immer neue Features, neue Features, neue Features wollten.
Aber dazu werden wir im Laufe der Veranstaltung noch ganz häufig kommen.
Vielleicht sollte ich vielleicht noch dazu sagen,
dass ich hier ein bisschen auch aus Erfahrung spreche.
Ich habe einige Jahre als Software-Projektleiter und Architekt gearbeitet, in großen objektorientierten Projekten.
Das liegt natürlich jetzt schon eine Weile zurück,
weil ich eine Weile schon im universitären Umfeld lehrend tätig bin
Aber ich kann Ihnen sagen,
wir haben jetzt gerade in der vergangenen Zeit hier drüber gesprochen,
von wegen, ja, alte Plattformen, alte Entwurfsmethoden.
Die Zeit, die ich jetzt hier als Entwickler
aktiv mitgemacht habe, seit Mitte der 90er Jahre.
Wir haben ganz viel gute, schöne, wunderbare,
schlecht und schlecht wartbare Software im objektorientierten Bereich in C Plus Plus und Java geschrieben.
Ja, gut, also neue Entwicklungen könnte doch die tolle Idee sein.
Der Manager denkt, ach super, wir investieren mal richtig,
aber dann haben wir doch richtig was Gutes.
Ja, wie ist denn das damit
Leider hat dieser Ansatz eine ganze Reihe von Nachteilen. Und
die kann ich Ihnen nicht, oder möchte ich Ihnen auch nicht vorenthalten.
Nachteile sind zum ersten hohe Kosten. Ja, und zwar
diese hohen Kosten. Klar, wir müssen ein ganzes System
nochmal entwickeln, ja. Und zwar diese hohen Kosten treten aus,
obwohl das Ergebnis eigentlich das Gleiche leistet wie vorher.
Obwohl Ergebnis mit Gleicher Funktionalität, wie diese Altsoftware.
Das ist das erste, der erste große Nachteil. Aber es gibt noch einen,
ja und der zweite könnte natürlich sein, dass die Altsoftware,
die hat ja auch viel Geld gekostet,
wenn wir die dann einfach wegschmeißen, Investitionen in,
nehmen wir den gleichen Begriff nochmal alt, Software,
die ist einen verloren, wenn wir da über die Jahre zwei Millionen reingesteckt haben,
dann sind die zwei Millionen plötzlich null.
Wir müssen die Software abschreiten. Das ist einfach Kosten,
das ist einfach weg. Aber noch viel kritischer ist es,
dass wir nicht wirklich wissen, was diese alte Software tat.
Unbekannte Anforderungen
Die, die Altsoftware erfüllt. Insbesondere dann, wenn Softwareänderungen
in der Vergangenheit auf Zuruf passiert sind. Wenn es also ganz häufig dazu gekommen ist,
Das Softwareänderungen nicht in einem geordneten Fall mit einem Ticketsystem gemacht sind,
wo man wenigstens noch im Ticketsystem nachschauen kann, was ist denn da getan,
sondern wo der Entwickler direkt von dem Auftraggeber kontaktiert worden sind,
bau mal das ein, bau mal das ein,
bau mal das ein.
Und dann können Sie sich vorstellen,
ist es noch viel schwieriger, eine Software zu entwickeln,
die genau das tut, was ich denn brauche,
weil ich ja gar nicht weiß, was gebraucht wird.
Und das Problem bedeutet, hat zur Folge,
insbesondere oder ein ganz besonders kritischer Fallsinn ist,
dass Vielleicht machen wir hier ein anderes Zeichen zur Einrückung.
Die Geschäftsregeln sind eigentlich nur in der Software beschrieben.
Man hat zum Beispiel ein Feintuning gemacht. Nehmen wir mal an,
eine Firma, die im Versandhandel betreibt,
hat im Laufe der Zeit Regeln entwickelt, bewegen Kunden,
welchen Kunden erlaubt sich denn Kauf auf Rechnung und unter welchen Sonderfällen, mit welcher Entwicklungshistorie,
der hat in letzter Zeit immer genau gut bezahlt und verlangt,
tragt immer ungefähr so Sachen unter 1000 Euro.
Dann können wir ihn nach der vierten Bestellung Kauf auf Rechnung
ermöglichen. Und jemand, der plötzlich 10.000 Euro,
nee, der kriegt da nicht Kauf auf Rechnung.
Solche Kleinheiten von Geschäftsregeln, so ihr Details,
die hat man im Laufe der Zeit entwickelt.
Und wenn man das auf Zuruf gemacht hat, das heißt,
der Entwickler wurde direkt vom Auftraggeber von den Menschen,
der diese Entscheidungen am Ende in Software abgelegt haben will,
kontaktiert, dann sind die nirgendwo beschrieben, außer in der Software.
Und kriegen sie mal in einer schlecht strukturierten Software raus,
wie genau die Regeln sind. Ja, also das ist,
Wir können die also als Unbekannt betrachten.
Das ist ein bisschen schlecht beschrieben. Das können wir Öps,
das können wir besser. Das ist der eine Punkt.
Der Nächste, wenn wir das also so entwickeln,
dann enthält das System diese Geschäftsregeln nicht.
Und die Geschäftsregeln sind aber genau das Know-how der Firmen.
Das zweite ist, Dass häufig Software für Dinge verwendet wird,
für die sie ursprünglich nicht gemacht wurde.
Also ein System zur Schlüsselverwaltung in einem Gebäude wird dann auch verwendet,
um die Raumbelegung zu erfassen. Und dieses System wird dann auch verwendet,
um die Abteilungsstruktur zu erfassen, welcher Mitarbeiter gehört zu welchem Chef.
Das steht aber eigentlich in dem Auftrag,
das gehört eigentlich nicht zu einem Schlüsselverwaltungssystem.
Man macht ein neues Schlüsselverwaltungssystem mit einmal schreien,
kriegen sie große Antwort, großes Geschrei, wenn dieses System kommt.
Ja, die Mitarbeiterstrukturverwaltung ist nicht mehr möglich.
Also es ist ganz häufig so, dass Zweckentfremdete Nutzungsfälle nicht
bekannt sind
Zweck, End. Fremdende. Nutzungsfälle nicht bekannt. Das heißt,
sie müssten eigentlich erst mal durch die ganze Firma gehen mit dem Altsystem und gucken,
was macht jeder Einzelne mit diesem System,
um zu sehen, was passiert denn da,
damit sie diese Anforderungen auch erfassen.
Sie müssen also in wirklichen umfangreiche Anforderungsanalyse machen.
Die Folge wäre, dass diese fremden,
unbekannten Nutzungsfälle durch die neue Software
nicht unterstützt wird
Und was wir auch noch sagen müssen,
dass es häufig so ist, dass Anschlusssysteme existieren,
Schnittstellen zu weiteren Systemen,
ich nenne sie jetzt mal Trittsysteme, irgendwie externe Systeme.
Diese Schnittstellen sind irgendwie vielleicht auch nicht ganz korrekt,
sind ein bisschen fehlerhaft. Man hat aber im Laufe der
Zeit diese Fehler erkannt und hat da was eingebaut.
Unter dem und dem Fall liefert das Ergebnis,
das System nicht null zurück, sondern irgendeine astronomische Zahl.
Und die müssen wir bitte ignorieren
Oder in dem und dem Fall muss das System erstmal
eine Anfrage kriegen, bevor es die richtige,
eine Erhöhung eines Einrichtung eines neuen Lagerplatzes kriegt oder irgend sowas.
Also gibt es da irgendwelche Besonderheiten im Ablauf in den Wertebereiche
oder irgendwelche Sachen? Fehler, die eigentlich nicht sein sollten.
Diese Schnittstellen sind jedenfalls nicht so genau bekannt.
Nur in der Software ist das abgelegt. Und wenn Sie also
eine neue Software entwickeln und nicht genau definierte Schnittstellen haben,
dann wird das erstmal nicht funktionieren
All das sind größere Probleme. Und dann haben wir
das kurzsätzliche Problem. Wie immer bei Neuentwicklung, ist,
dass wir Terminvorzug riskieren müssen,
befürchten müssen
Aber vor allen Dingen ist es, dass wir unreife erwarten müssen.
Also dieser befürchtete Bananensoftware, wir haben ein neues System entwickelt,
es soll besser sein als das Alter,
aber es hat erstmal viele Bugs zu anfangen.
Und was wir auch noch sagen müssen, viele der alten
Kunden sind, der Allwender sind das alte System gewöhnt.
Menschen lieben keine Veränderungen. Das heißt,
wir haben damit zu kämpfen,
dass das neue System das abgelöste System nicht akzeptiert wird
Fehlende Akzeptanz durch die Nutzung. All diese Punkte führen dazu,
dass wir eine Reihe von Risiken haben,
die wir ja irgendwie behandeln müssen.
Wenn wir noch mal zu den Fragen gehen,
das waren also die Risiken Punkt Nummer 4,
die Risiken des Re-Engineerings und die Risiken der Ablösung eines Neuesystems