Als letzter Abschnitt von sechs, von Kapitel 6 haben wir
hier noch den Abschnitt 6.4, Einbindung in Prozessmodelle.
Ich möchte gerne hier noch einen kleinen Schwenk machen,
dazu, wie wir das in den Entwicklungsprozess organisatorisch aufnehmen.
Organisatorisch bedeutet, dass wir in den Unternehmen bei großen Projekten typischerweise ein Vorgehensmodell haben.
Es gibt natürlich Unternehmen, da ist das Vorgehensmodell nur eine reine Theorie.
Es gibt einen Aktenordner im Strang und wenn da jemand mal irgendwie fragt danach,
also es fragt dann in diesen Unternehmen keiner danach,
aber wenn, dann würden sie sagen,
ja ja, wir haben eins.
Man arbeitet nicht danach
Empfehlung ist, wenn es eins gibt und das ist halbwegs sinnvoll
, arbeiten Sie danach? In manchen Unternehmen gibt es auch
gar keine Wahl, Sie müssen ganz genau danach handeln.
In jedem Fall möchte ich Ihnen hier vorstellen,
wie Sie in ein typisches Vorgehensmodell für große Projekte das Ganze einbinden können.
Dazu haben wir hier eine Folie, nein, das war sie noch nicht.
Hier mit der Nummer 9 in den Unterlagen, die uns
einen Ausschnitt auf den Intergrafik, einen Ausschnitt zeigt aus dem V-Modell.
Dieses V-Modell, ich habe hier extra mal eins gewählt,
was eher schwergewichtig ist,
also für wirklich große Projekte geeignet ist und auch das Jammer mit dran geschrieben,
damit Sie sehen, ja, also 1997 hatte man schon einen Test-First-Strategien.
Ich möchte diejenigen, die von Ihnen,
die bei mir in Bachelor Software-Technik gehört haben,
haben das schon mal in der gleichen Form gesehen,
aber das ist ja vermutlich für Sie eine Weile her.
Deswegen ist es nicht so schlimm, wenn ich es Ihnen nochmal zeige.
Ich möchte daraufhin tatsächlich die Folie direkt da vorher genommen.
Ich möchte einfach auf die Punkte nochmal eingehen und die
in Bezug zu unserem Reengineering-Vorgehen, Refactoring, gehen.
Das eine war, das ist Ihnen völlig klar,
inkrementelles Vorgehen ist das, was wir wollen zur Risikovermeidung.
Also kein Big Bang, wir machen das alles Risiko
Eulen optimiert. Das nächste ist, wir machen einen Test-First.
Dieses Test-First sollten wir nicht nur in der Entwicklung von Queenfield,
also wir machen etwas neu, sondern wir sollten das vor
allen Dingen im Refactoring machen, weil es uns absichert.
Cover in Modify hat, wird das genannt, oder wir haben es hier genannt,
dass wir die Charakterisierungstest machen, um überhaupt das durchzuführen.
Wir hatten darüber gesprochen, kleine Tests zu machen,
all das ist ein wichtiger Punkt, dass wir das vor der Entwicklung erarbeiten.
Das nächste Wartbarkeit, klar, das ist das primäre Ziel bei Software Regineering,
das ist jetzt hier, was hier auf der Folie steht,
ist eigentlich dafür gedacht, eine neue Entwicklung macht,
dass man nicht nur an Funktionen denkt.
Unser Austraggeber wird schätzungsweise während der Erwartungsphase von Software auch,
vor allen Dingen an Features denken, die er gerne haben möchte.
Wir denken bei Re-Engineering vor allem daran, die Wartbarkeit zu erhöhen.
Und sie alle haben hoffentlich das Stage Model im Hintergrund,
was ihnen sagte, also wenn ich die für die Wartbarkeit nichts tue,
rutsche ich ganz gleich schnell ab aus dem Zustand Evolution,
wo ich morgens noch evolutionäre Veränderungen machen kann,
ab in den Zustand, wo wir nur noch Patches machen,
Flickwerk,
gerade die Software Not dürfte ich
am Laufen halten
Ja, ich hatte schon gelegentlich darauf hingewiesen,
dass wir nicht erwarten können, dass der Auftraggeber Re-Engineering explizit wünscht,
weil Wartbarkeit als inneres Qualitätsmerkmal für ihn typischerweise nicht sichtbar ist.
Maximal die Folgen bleiben für ihn, für den Austraggeber sichtbar,
wie zum Beispiel, man schafft die neuen Gesetze,
die im November rauskommen, nicht mehr bis Dezember fertigzustellen,
weil es einfach zu lange dauert.
Dann wird er sagen, okay, wir müssen hier etwas
für Wartbarkeit tun. Aber das ist auch der einzige Fall,
der mir so bekannt ist als Argument, was wirklich mal greift.
Ansonsten habe ich so den Spruch gehört,
in meiner Projektleiterzeit Herr Rebisch,
wir wollen
keinen Architekturpreis gegeben
Ja, also typischerweise gibt es dafür kein Verständnis.
Es gibt deswegen auch keinen Auftrag. Im Gegenteil gibt es so einen hohen Druck,
neue Features, Veränderungen, Optimierungen, Anpassungen von Geschäftsregeln,
Anpassungen an neue technische Plattformen, möglichst schnell durchzuführen.
Das heißt, eigentlich gibt es nur den Druck,
Erweiterungen, Anpassungen zu machen. Und wir sollten,
und das ist dann eine Frage, wie sie das Projekt leiten,
wie sie die Architektur entwickeln, wie sie das System pflegen,
wie sie sich auch verantwortlich fühlen,
dass sie Reengineering aus eigenem Antrieb immer mit dazupacken,
immer ein Bündel machen,
nie nur die Migration machen
Sondern nie nur die Erweiterungen machen, die Anpassung machen,
sondern immer sagen,
erst machen wir das Re-Engineering für diesen Teil Refactoring,
um die Qualitätsvorbesserung und dann das funktionale Erweiterung.
Und dann gibt es hier noch den Punkt Reifegrad,
Reifegrad wäre in dem Fall etwas für langfristige Verbesserungen tun.
Ja, ich schreibe das mal, sonst schreibe ich hier nicht
so viel Teilen. Ja, das ist eine ganz misswerten,
langfristige Verbesserung soll das werden
Ja, und das, was wir hier stehen hatten,
Dokumentationsbasis verbessern, das ist vor allen Dingen Charakterisierungstests.
Die Architekturqualität verbessern, das ist vor allen Dingen Refactoring.
Und Modellqualität verbessern, das ist vor allen Dingen
Architektur Recovery
Sie merken schon anhand der viele Menge von Rückblicken,
die ich herstelle, dass wir so uns dem Ende der Lehrveranstaltungen widmen.
Ich möchte nähern und ich möchte gern diese Gedanken widmen,
den Punkt widmen, dem Ziel widmen, dass es ihm leichter gelingt,
den Bogen zu schließen zwischen diesen Fächer von Maßnahmen,
die wir hier dargestellt haben.
So, jetzt will ich aber nicht das beenden,
ohne noch das Bildchen erklärt zu haben.
Dieses Bildchen ist tatsächlich so ähnlich aus den Unterlagen des Fondmodells
genommen. Es gibt mittlerweile noch eine Version,
eine Fondmodell XT für XT steht für Extreme Tayering,
was also besser noch anpassbar ist,
wo angeblich inkrementelles Arbeiten wirklich unterstützt wird
Ich sag mal, meiner Meinung nach, in Teilen,
ja, aber wir schauen uns an, was hier passiert.
Was wir hier sehen, ist eigentlich ein Aktivitätsdiagramm.
Beim Aktivitätsdiagramm der UML kennen Sie, dass es solche Bereiche gibt.
Das sind die senkrechten Linien, hier so Swim Lanes,
ja, das ist der Bereich Konfigurationsmanagement.
Das ist der Bereich Systementwicklung bei dem Modell,
hier hieß es sogar noch Surfwareentwicklung, also Systementwicklung und Qualitätssicherung.
Ja, und was wir hier dargestellt haben, ist,
dass wir dieses Test First im Kernel darstellen,
man kann sich irgendwie Entwicklung von irgendetwas, hier ist das Beispiel Architektur,
aber man kann hier auch sagen, Softwareentwicklung oder Schnittstellenentwicklung oder Irgendetwas.
Ja, dass man, also die Entwicklungen vorher,
die Abnahmevorbereitung nach, die Abnahme durchführt. Ja,
das ist eigentlich dieses Testfirst und danach prüft man und wenn
es nicht in Ordnung wird, machen wir doch mal.
Das ist also für jeden Entwicklungsschritt und bitter,
wenn Ihnen jemand erzählt test, First,
wollen wir es für zu null für unser Projekt,
1997 war das schon dabei.
Also das hat man schon sehr lange in den Vorschriften und das
ist tatsächlich gültiges Ausschreibungsbasis für öffentlich geförderte Projekte oder öffentlich finanzielle Projekte der Bundesministerien.
So, Genau, und das Konfigurationsmanagement spielt hier nur die Rolle noch dabei,
dass es das bereitstellen, also Checkout und das Einfrieren,
also Check-In, hier gleich mit festgeschrieben ist.
Erst dann, wenn sie Produkte geprüft sind,
dass dann geht es dazu, dass der nächste Entwickler damit arbeiten kann,
sie sichtbar sind für andere in dem Projekt.
Diese kurzen Ausführungen nur dazu, um ihnen zu zeigen,
ja, wir haben das Refactoring, können wir das Reengineering,
können wir wirklich in Vorgehensmodelle einbinden, in Vorgehensmodelle,
die in den Firmen existieren.
Das ist hier ein Beispiel, ein firmenspezifisches Vorgehensmodell kann ich Ihnen nicht zeigen,
weil die meistens Firmengeheimnisse sind, auch wenn ich zwei, drei kenne.
Aber dieses ist hier sehr weit, hat sehr viele Firmen beeinflusst,
weil sehr viele Firmen Subauftragnehmer von irgendwelchen öffentlichen Projekten für Verkehrsministerium,
Bauministerium, Finanzministerium oder was auch immer sind.
Und da ist das immer festgeschrieben, dass auch die Superauftragnehmer das machen müssen.
Deswegen, er hat das Eingang in viele Vorgehensmodelle,
deutsche Unternehmen gefunden und auch das bei der NASA ist nicht
so sehr viel abweichend davon.
Soweit zum Abschnitt