Hallo, liebe Studierende. Viertel nach zwei in Deutschland,
ich bin's wieder. Wie schön, dass ihr trotz Brückentag,
Deutschland, den Brückentag heute den Weg hierhin gefunden habt.
Ich hoffe, ich kann euch anderthalb Stunden was erzählen,
wo sie nicht denkt, dass es Zeitverschwendung war, hier gewesen zu sein.
Drei Uhr machen wir wieder eine kleine Pause.
Ansonsten zweiter Teil der Vorlesung, Vorgehensmodelle. Womit haben wir
uns letzte Woche beschäftigt? Um erstmal zum kleinen Ausflug gemacht,
so was ist das eigentliche Problem bei Vorgehensmodellen,
wieso muss man sich überhaupt mit sowas beschäftigen,
wieso kann man nicht einfach losprogrammieren.
Ich hoffe, diese Motivation, ja doch. Also ich bin
danach vollständig motiviert gewesen, mich mit Vorgehensmodellen weiter zu beschäftigen.
Ich hoffe, das ist bei euch genauso.
Wir haben dann eine, so die erste,
die klassische Antwort in der leere Forschung über Vorgehensmodelle, haben wir uns angeschaut.
Das waren die sogenannten Phasenmodelle oder auch Einbahnstraßenmodelle, wie sie
von Ludewick Lichter genannt werden. Und ich habe dann aufgehört,
letzte Woche damit, so Phasenmodelle, ja, Gut,
einen Schritt in die richtige Richtung,
aber hilft noch nicht so wirklich,
dass so das aufgebaute Problemsszenario zu lösen.
Den ersten Schritt in die Richtung, was kommt nach Phasenmodellen?
Damit haben wir letzte Woche aufgehört. Der Autor Kritikerzyklus als
grundsätzliche Idee, der Abkehr vom Phasenmodell.
Die Haltung dieses jungen Mannes ist nicht beispielhaft für das,
wie man in dieser Vorlesung sitzen sollte.
Aber gut
So, der Autor-Kritiker-Zyklus, was macht der grundsätzlich aus? Naja,
zu allem hier, man kann ja nicht sagen,
wo es anfängt und wo es aufhört,
das ist ja gerade das Wesensmerkmal zyklischer Vorgehensmodelle,
dass man sich in einem Kreislauf befindet,
sagen wir mal so, das ist vielleicht keine schlechte Idee,
zunächst mal mit einer Situationsbestimmung anzufangen,
könnte man aber auch genauso gut sagen, naja,
bevor ich nicht eine Zielvorstellung erarbeitet habe,
brauche ich auch keine Situationsbestimmung zu machen.
Weil wie ich eine Situation wahrnehme,
ist ja dann auch durchaus abhängig davon,
welches Ziel
ich eigentlich erreichen möchte
Und was wohl unstrittig ist, ist, dass man dann nach so einer Situationsbestimmung,
dass man dann anfängt zu modellieren und zu konstruieren,
um auf der Basis dessen, was man da,
also modelliert, konstruiert hat, seine Zielvorstellung zu schärfen.
Das ist jetzt so die Idee, die ja,
also die überhaupt nicht, also mit, sagen wir mal,
die wirklich eine grundsätzliche Abkehr von einem linearen,
von einem Phasenmodell ist, weil die Zielvorstellung,
was man bauen will,
wird ja dort,
also einmal am Anfang des Projektes festgelegt und dann ist da keine weitere,
also Überarbeitung mehr
im Modell vorgesehen
Möglichen Modelle, alle verschiedenen zyklischen Modelle,
die ich heute hier diskutieren werde, sind Verfeinerung dieses Outdoor-Kritikerzyklus.
Ich werde so ungefähr, kann ich die jetzt abzählen,
so ungefähr so ein halbes Dutzend von diesen Modellen,
werde ich hier vorstellen, die so unterschiedlich fein ausgearbeitet sind bezüglich
ihrer bezüglich ihrer Detailtiefe, die sich auch für unterschiedlich große
Arten von Projekten eineignen. Also es fängt an bei Nein,
wir fangen nicht an, aber wenn man so bei den Grundlagen,
werde ich erst mal jetzt ein paar Worte über Prototyping, Prototypenkonstruktion verlieren.
Das hat also mit Vorgehensmodellen, zeitlicher Planung, Management von Projekten,
zunächst mal weniger zu tun. Wird dann so ein paar Projektplanungsgrundlagen legen,
um dann so in der zweiten Hälfte der Vorlesung so ausgereifte zyklische Vorgehensmodelle vorzustellen,
so wie sie heute, also nicht nur Stand der Kunst sind,
sondern sich auch, je nachdem, wo man hinschaut,
also wie sie auch im industriellen Alltag dann eingesetzt werden.
So, zum Abschluss dann werde ich, werde ich kurz vorstellen,
was es mit sogenannten agilen Vorgehensmodellen auf sich hat.
Das ist so die letzte Welle von Vorgehensmodellen,
die so über die Softwaretechnik gekommen ist oder die so in der Softwaretechnik diskutiert werden.
Da ist möglicherweise, habt ihr den einen oder anderen Begriff,
also ob das jetzt Extreme Programming ist oder Scrum,
habt ihr schon mal gehört.
Das werde ich also zum Schluss vorstellen. Zunächst,
was ist all diesen zyklischen Vorgehensmodellen, was ist dem gemein?
Hier die drei Grundbegriffe, die hier stehen,
also lassen sich jeweils unterschiedlicher Art,
aber also bei allem mehr oder weniger stark lassen die sich wiederfinden.
Also zunächst mal ist evolutionär,
also wenn wir hier über die Grundbegriffe evolutionärer Softwareentwicklung sprechen,
evolutionär bedeutet, ich möchte eine Vorgehensweise wählen,
die darauf ausgerichtet ist, dass sich etwas in meinem Kontext oder in meinem Verständnis einer Situation verändert.
Das nennt, die Amerikaner bringen das so in diesen agilen Vorgehensmodellen,
bringen die das so in den sogenannten Agile Manifesto,
also das agile Manifest,
das Manifest der agilen Softwareentwicklung,
bringen das auf den Punkt Imbrace Change
Man soll Change, so Wechsel soll man,
also nicht nur wahrnehmen, sondern man soll das gut heißen,
dass sich die Wahrnehmung ändert, die man über ein Projekt hat.
Und man soll also das in seinem Vorgehensmodell, wenn man das auch entsprechend berücksichtigen. Also wir,
auch wenn so bestimmte Anforderungen sich in der Zeit nicht verändern,
wir wollen ein Vorgehensmodell haben, uns an einem Vorgehensmodell ausrichten, das auf Änderungen, das Änderungen akzeptiert. Inkrementell,
also in Inkrementen, denkend, in Inkrementen bauend,
also inkrementell bedeutet vom Wort her wachsend,
Anders als bei den zyklischen Vorgehensmodellen, Entschuldigung,
anders als bei den Phasen-Modellen, die darauf ausgerichtet gewesen sind,
etwas mit einem Big Bang, also in die Organisation,
in die Auftraggeber-Organisationen einzuführen, sind diese zyklischen Modelle darauf ausgerichtet,
dass man in Inkrementen, in Ausbaustufen etwas in die Organisation hineinträgt,
um so eine Idee davon zu bekommen, baue ich das Richtige.
Das ist also diese Frage ist gar nicht so trivial,
also gerade bei größeren Entwicklungsvorhaben ist das also so,
wie man das, man kann sich natürlich so mal so 30.000 Fußflughöhe,
ist das ziemlich einfach, das Richtige zu bauen,
aber je näher man, also so an an den Boden herankommen,
je näher man ins Detail schaut, also desto schwieriger wird es doch,
also festzustellen, also baue ich das Richtige,
um dann im Nachklapp die Frage auch beantworten zu können,
baue ich das Richtige richtig?
Also zunächst mal in frühen Phasen eines Projektes kommt es stark darauf an,
dieses Verständnis für das Richtige, also nicht zu bekommen,
aber das herauszuarbeiten, weil ohne diese,
also ohne diesen Lernerfolg, kann ich mir nicht sicher sein,
ob ich am Ende des Projektes, also das gewünschte,
ein gewünschtes Ergebnis hergestellt haben werde.
Iterativ, bedeutet in diesem Zusammenhang,
dass die Entwicklungsschritte eben nicht wie im Phasenmodell einfach,
also einfach im Sinne von einmalig durchgeführt werden,
sondern dass die sich so im Zyklus ständig wiederholen,
so wie wir jetzt diesen Grundzyklus der iterativen evolutionären Softwareentwicklung,
den Autor-Kritikerzyklus, ja in dieser Grafik auch schon gesehen haben.
Also nicht einfach einmalig die Anforderungen erheben,
sondern im Zyklus immer wieder,
bis man also zu einem Endergebnis gekommen ist
So, diese Grundbegriffe werden wir jetzt an verschiedenen Stellen,
in verschiedenen Ausprägungen werden wir, die jetzt wiedersehen und werden die
auch immer wieder so im Kontext der einzelnen Entwicklungsmethoden dann diskutieren.
So, Anwendungsexperten im Entwicklungsprozess. Ich habe schon letzte Woche
so vom Unausgesprochenen Leitbild der Phasenmodelle gesprochen,
sodass das also so eher mit dem Fenstersturz vergleichbar ist.
Wir werden noch das unausgesprochene Leitbild der agilen Entwicklungsmethoden
uns noch anschauen
Also ein Punkt,
der nicht wirklich mit Phasenmodellen oder zyklischen Modellen verbunden ist,
der aber auch eine Rolle spielt, also was die Haltung von Softwareentwicklern anbetrifft,
der häufig also in Tateinheit tat, Mehrheit mit Phasenmodellen,
also gefunden wird, ist die Rolle des Benutzers.
Ich sage jetzt schon Benutzer, die Rolle des Benutzers in Entwicklungsprojekten.
Der typische Softwareentwickler baut Software für den sogenannten dümmsten Anzunehmenden Benutzer
So die Haltung, also unausgesprochene Haltung,
also ausgesprochen wird die natürlich nie in solchen Entwicklungsprojekten.
Ich baue Software, ich weiß, wie, also ein Tagesgeschäft,
wie das am besten, also zu organisieren ist.
Und es ist meine vornehmste Aufgabe, die Daten,
die ich verwalte, vor dem Dümmsten anzunehmenden Benutzer zu beschützen.
Das heißt, und dann will ich,
also das ist ja auch ein Terminus, nicht ein Terminus-Technikus,
aber das habt ihr sicherlich auch schon mal gehört,
wir bauen sogenannte Idioten
sichere Systeme
Umgekehrt bedeutet das, ein idiotensicheres System ist ein System für Idioten.
Leute, die keine Ahnung haben und die man also durch eine Aufgabenerledigung möglicherweise steuern muss.
Jetzt ist es aber im Großen und Ganzen,
kann man wohl behaupten, dass die Anwender,
für die wir Software bauen, keine Idioten sind.
Es sind Fachleute der Anwendungswelt. Und diese Fachleute wollen also in ihrer Fachsprache,
wollen die verstanden werden. Und jetzt ist es zunächst mal,
und das ist also eine eine Einsicht, eine Haltung,
die dann eben häufig mit zyklischen Vorgehensmodellen auch in Verbindung gebracht wird,
obwohl, wie gesagt, es nicht notwendigerweise so ist.
Wir betrachten unsere, die Leute, für die wir Software bauen,
nicht als die Benutzer, sondern als die Anwendungsexperten im Entwicklungsprozess.
Und denen begegnen wir im Großen und Ganzen,
sollen wir denen auf Augenhöhe begegnen.
Es ist also zunächst mal eine Bringschuld von Softwareentwicklern,
sich auf die Fachsprache der Anwender zum Beispiel einzulassen,
um mit denen über ihre Arbeit im weiteren Entwicklungsprozess sprechen
zu können
Das ist also so die Grundidee,
also die ganz eng verbunden ist mit zyklischen Entwicklungsvorgaben, Vorhaben.
Dass also die Einbeziehung aller beteiligten Gruppen über die gesamte Projektlaufzeit stattfinden soll.
Ihr erinnert euch vielleicht an die Folie, die ich gezeigt habe,
so das kundenorientierte Grundproblem von Wasserfallmodellen. Das ist vorgesehen,
dass man mit Anwendern am Anfang des Projektes spricht und dann
in den weiteren Phasen nicht mehr mit denen spricht,
weil man hat ja überhaupt nichts, worüber man mit denen sprechen kann.
Erst in dem Moment, wo man was ausgeliefert hat,
kann ja wieder eine Kommunikation stattfinden über das, was man letztendlich gebaut hat.
Wenn man jetzt inkrementell in Ausbaustufen zyklisch etwas baut,
dann hat man natürlich auch ständig eine sehr viel bessere Grundlage,
um mit Anwendern darüber zu sprechen, bauen wir hier das Richtige.
Oder sind wir hier auf dem Holzweg? So,
in diesem Sinne, verstärkte Einbeziehung über die gesamte Projektlive-Zeit wird
erst durch zyklische Vorgehensmodelle ermöglicht und ist durch Phasenmodelle wird das nicht wirklich,
also durch solche Einbahnstraßenmodelle wird das nicht unterstützt.
Wir können ja mal so kurz ein Experiment machen,
Worüber kann man sich denn eigentlich unterhalten,
wenn man also nach einem Phasenmodell vorgeht, na klar,
man kann am Anfang mit den Anwendern über deren Anforderungen sprechen.
Und dann hat man da so,
baut man im Wesentlichen seine technischen Dokumente auf, also Entwurfsspezifikation,
man kann von mir aus noch Use Cases aufschreiben, so irgendwas,
also wovon man glaubt, dass es also den Anforderungen entspricht.
Aber man kann, glaube ich, ich glaube,
da sind wir uns einig,
man kann mit Anwendern schlecht über Klassenmodelle sprechen,
so nach dem Motto,
entspricht dieses Klassenmodell oder entspricht ein bestimmtes Datenmodell,
entspricht das
euren Anforderungen
Und jetzt sagen wir, naja, könnte schon sein.
Jetzt kommt ein Kunde vor, Konto kommt vor, Vertrag, Komfort.
Sieht eigentlich ganz gut aus. Was das bedeutet,
also kann ein Anwender ja überhaupt nicht einschätzen. Das heißt,
man hat also, so wie wir das ja letzte Woche
auch schon festgestellt haben und hat eigentlich gar keine tragfähige Grundlage.
Jetzt haben so diejenigen,
die jetzt also so sich viel mit Phasenmodellen beschäftigt haben und das auch einsehen,
dass man sich mit Anwendern schlecht über Klassenmodelle unterhalten kann,
haben dann gesagt, naja gut,
dann schulen wir doch unsere Anwender zum Beispiel in Datenmodellierung.
Dann können wir mit den Anwendern über Datenmodelle sprechen
Hm. Hat man mit denen über Datenmodelle gesprochen?
Das Interessante ist also, was interessant, ja,
was ich so interessant finde, was dann passiert,
kann man sich an einem anderen Experiment versuchen klarzumachen.
Also ich mache unter anderem so Hans Zülikoven und andere auch,
wir haben einen Lehrauftrag, also in dem wir Medizinstudenten Informatik beibringen.
Das ist mal was anderes. Und also das,
was ich das Experiment, das ich jetzt mit euch durchführe,
das klappt auch in Wirklichkeit.
Und zwar teile ich euch jetzt mal in zwei Hälften auf
Kennt euch nicht. Ihr wisst nicht, dass es jeweils eine andere Hälfte gibt.
Jetzt nehme ich mal hier diese Hälfte und das Experiment,
das wir machen, ist,
ich habe hier eine Blutprobe und dann treufle ich da was drauf und dann kann man anhand,
so wie sich jetzt das Blut,
wie das so gerinnt, so hoffe ich,
wird jetzt niemandem schlecht.
Kann man erkennen, was für eine Blutgruppe ist das?
Und das mache ich jetzt mit euch ein paar Mal.
Und so nach einer kurzen Weile kriegt man das raus,
also aha, das ist also jetzt die Blutgruppe A,
B, was ist null,
was es halt
so alles gibt
Was ich euch nicht erzähle, dieser Hälfte hier,
ist, dass ich euch immer die Wahrheit sage.
Das heißt also, wir lernen das jetzt,
also wie man so eine Blutprobe bestimmt, wie man die Blutgruppe dieser Blutprobe bestimmt.
Und nach relativ kurzer Zeit habt ihr so ein intuitives Modell darüber entwickelt,
wie kann man anhand einer Blutprobe die Blutgruppe bestimmen.
Gut. So. Jetzt komme ich zu dieser Hälfte und wir machen dasselbe Experiment.
Es braucht jetzt nicht zu wiederholen, ihr habt ja mitgehört. Das,
was ich euch jetzt nicht erzähle, ist,
Ich halte euch eine Blutprobe hin und sagte, ah,
das ist Blutgruppe A, dann sage ich, nein,
das ist Blutgruppe B. Ihr denkt, ich sage euch die Wahrheit,
tue ich aber gar nicht.
Manchmal lüge ich euch an. Sage ich einfach,
nee, ist eine andere Blutprobe. Andere Blutgruppe. Was
passiert jetzt? Jedes Mal, wenn ihr so denkt,
ah, jetzt habe ich es verstanden, nee,
habe ich wohl doch noch nicht verstanden.
Das baut ihr in etwas komplizierteres Modell darüber auf.
Also wie man jetzt eine Blutprobe bestimmt.
Soweit so gut. Und irgendwann sage ich so,
jetzt ist aber genug. Und jetzt kommt der entscheidende Teil
des Experimentes
Aus jeder der beiden Hälften kommt jetzt jeweils einer dazu und
ich zeige also diesem Team von zwei Leuten,
zeige ich jetzt eine Blutprobe und dann sage ich, welche Blutgruppe ist es denn?
Und dann kann man statistisch nachweisen, diejenigen,
die ich angelogen habe, gewinnen in den Diskussionen darüber,
um welche Blutprobe, Blutgruppe es sich handelt,
häufiger als diejenigen, denen ich immer die Wahrheit gesagt habe.
Das ist komisch, oder? Und warum ist es so,
diejenigen können besser darüber reden,
welche Blutprobe es sich handelt,
irgendwelche Blutgruppe es sich handelt
Es hat nichts mit, also Wahrheit, Wirklichkeit,
sonst was zu tun. Die können einfach, weil sie
sich mehr Gedanken drüber gemacht haben, können die besser drüber reden.
Und jetzt übertragen wir das mal auf Softwareentwicklung. Sind also
diese wunderbar ausgebildeten Softwareentwickler, die können Entity Relationship Modellierung,
die können Use Cases, die können UML-Diagramme.
Wunderbar. Und dann zeigen die so einem einfachen Benutzer,
der eigentlich nur seine Arbeit machen will, sagen die,
hier ist das Datenmodell für deine Anwendung.
Das ist doch toll, oder? Ist doch völlig klar.
Ein Kunde hat Konten. Und ein Konto ist ein,
bla bla bla,
Und dann sagt der Anwender, ja,
wenn du das so sagst, dann wird das wohl stimmen.
Also wir haben in dem Moment, wo die Sprache der Techniker,
die Grundlage für den Dialog mit den Anwendern ist,
haben wir eigentlich schon gar keine Grundlage mehr,
keine Möglichkeit mehr, mit denen über deren fachliche Anliegen zu sprechen.
Das ist eine Zeit lang, ist das also auch,
das ist jetzt nicht, dass das die herrschende Meinung gewesen ist,
also die herrschende Meinung oder sagen wir lieber die herrschende Praxis ist,
man redet lieber gar nicht mit Anwendern, also darüber,
was man da jetzt eigentlich tut,
weil sie verstehen eh nichts davon,
was man da so treibt
Von dieser ganzen Denkweise von dieser Haltung müssen wir uns verabschieden.
Und deswegen steht da auch, also diese, sagst du jetzt nochmal,
diese ständige Rückkopplung der Ergebnisse durch anwendungsorientierte Dokumente und vor allem Prototypen.
Und das bedeutet also für euch als zukünftige Softwareentwickler
in solchen Anwendungsprojekten die Sprache der Anwendung.
Das ist das Allererste, was ihr lernen müsst.
Und das ist das mit Deutsch ist es nicht getan,
in internationalen Projekten dann eben eine andere natürliche Sprache.
Es geht um die Fachsprache der Anwendung,
die wir beherrschen müssen
Und wenn man das nicht beherrscht, hat man wenig Grundlagen,
um so eine ständige Rückkopplung zu ermöglichen. Diese Fachsprache der Anwendung zu lernen,
das ist eine Bringschuld, die Softwareentwickler erstmal einlösen müssen.
Nicht die Anwender müssen sich an unsere Modelle gewöhnen,
sondern wir müssen uns an die Sprach- und Denkwelt der Anwendung gewöhnen und solche Rückgekoppelten zyklischen Prozesse,
also beinhalten das, dass dieser Prozess Teil des Vorgehensmodells ist,
dann können wir uns dann, also dann ist eben dieses hier möglich,
die ständige Rückkopplung über etwas,
also worüber sich Anwender dann eben auch unterhalten können,
nämlich anwendungsorientierte Dokumente, Dokumente,
in deren Fachsprache und Prototypen.
Das hier ist jetzt also
der letzte Punkt
Also nicht, dass ich jetzt irgendeiner Entwicklungsabteilung jemals unterstellen wollte,
dass die also ein Selbstverständnis als Closed Job haben.
Nein, haben die nicht. Es ist eher umgekehrt,
also wir wollen jetzt, die Entwickler sollen sich so in
einer Haltung, wir sind ein Dienstleister für unsere Anwendung.
Das soll also die Grundhaltung sein mit der Software-Anwendungssoftware entwickelt wird. So,
ich glaube, ich hatte beim letzten Mal versprochen,
ich nehme diese ganzen Teile mit der Aufblendtechnik,
ich nehme das raus, Habe ich nicht geschafft.
Was ist also Prototyping? Prototyping hatte so,
oder hat auch immer noch in weiten Teilen der Anwendungsentwicklung in
der industriellen Praxis, hat einen extrem schlechten Ruf.
Prototyping wird übersetzt mit, wir frickeln was hin und wenn es läuft,
ist gut und wenn es nicht läuft, dann war es nur ein Prototyp.
Das, also ist so eine Haltung, die,
also viel, also viel Flurschaden angelegt hat. Und deswegen hier,
weil ich werde jetzt ein paar Minuten über Prototyping und Prototypenkonstruktion sprechen,
Das, was ihr euch bitte merkt mit der Konstruktion eines Prototypen,
ist jeweils eine Fragestellung verbunden.
Wenn ich keine Fragestellung habe, die ich anhand eines Prototypen
beantworten möchte, dann brauche ich keinen Prototypen zu bauen.
Dann baue ich irgendwas. Dann baue ich einfach irgendwas.
Kann man ja machen. Bloß, man soll dann bitte
nicht behaupten, dass es irgendetwas mit Prototyping zu tun hat.
Portotyping bedeutet, ich habe eine Frage und die
möchte ich beantworten mit der Hilfe eines laufenden Stücks Software.
Und das können unterschiedliche Fragestellungen sein und je nachdem,
welche Fragestellung ich habe,
werde ich auch unterschiedliche Arten von Prototypen bauen und die
kann ich unterschiedlich im weiteren Entwicklungsprozess einsetzen
Und das gucken wir uns jetzt an. Welche unterschiedlichen Arten von Prototyping
gibt es und welche unterschiedlichen Arten von Prototypen sind damit verbunden?
Das ist übrigens eine Art von, oder dieser Art,
dieser Beitrag zur Software-Technik wurde von Christiane Floyd.
Die habt ihr, glaube ich, gerade verpasst. Frau,
Professor Dr. Christianne Floyd wurde letztes Semester oder vorletztes Semester emeritiert.
Die hat also in diesem Bereich, also der Software-Technik-Forschung,
maßgeblich mitgeprägt. So, was bedeutet das?
Bewusst gestaltete Lernprozesse anhand von ausführbaren Vorversionen des geplanten Software-Systems
Punkt, den ich hier machen möchte, ausführbar,
wenn das Ding nicht läuft, ist es kein Prototyp.
Dann ist es was anderes, kommen wir auch noch dazu,
es kann auch sinnvoll sein, aber Prototypen sind immer ausführbar.
Frühzeitig, relevante Systemteile, entwickeln, erproben und bewerten.
Also hier wieder ganz deutlich der Schwerpunkt auf Fragestellung.
Die Frage ist wichtig, und wenn ich eine Frage habe,
kann ich die mit Hilfe eines unterschiedlich gestalteten Prototypen beantworten.
Rückkopplung für die weitere Entwicklung. Also es ist nicht nur,
dass wir Prototypen bauen, die im Dialog, also im Dialog mit zukünftigen Anwendungen oder dem Management eingesetzt werden.
Auch technische Entwurfsfragen lassen sich natürlich durch Prototypen beantworten. Und dann, also zum weiteren Entwicklungsprozess, positiv beitragen. Softwaretechnik,
also da sind auch andere schon drauf, also nicht drauf gekommen,
aber wir sehen mal die Jahreszahlen seht,
das ist also alles aus dem letzten Jahrhundert und zwar nicht ziemlich weit,
aber so in Ende der 80er Jahre,
so Mitte der 90er Jahre war eigentlich das Grundverständnis dafür,
dann auch schon gelegt,
dass also Prototyping in der Softwaretechnik zur Unterstützung des Entwicklungsprozesses eingesetzt werden kann und dann in diesem Forschungsfeld namens Software Ergonomie,
also wo es so im Wesentlichen um Gebrauchstauglichkeit von Softwaresystemen geht,
dass man natürlich auch unterschiedliche Arten von Benutzern zu evaluierenden Prototypen konstruieren kann.
Experiment und Erfahrung, einer auf Experiment und Erfahrung gegründete Vorgehensweise,
ja, wir müssen uns das halt eingestehen,
dass wenn wir nicht wissen, was wir bauen wollen,
also das möglicherweise auch noch gar nicht wissen können zu einer frühen,
in einer frühen Phase des Entwicklungsprozesses,
dass wir dann Experimente durchführen Typen sind in diesem Sinne nichts anderes als Experimente,
um möglicherweise eine bestimmte Art der Benutzung,
eine bestimmte Art der Verwendung von Software zu evaluieren.
Entwurstdokumente stoßen an prinzipielle Grenzen. Und das ist extra
das Spielen ist hier in Anführungsstrichen gesetzt
Ihr werdet wahrscheinlich an der einen oder anderen Stelle im Entwicklungsprozess,
werdet ihr mal anfangen, sogenannte Szenarien zu schreiben, sozusagen so kleine Handlungsstudien.
Also wie eine bestimmte Art der Aufgabenerledigung erfolgen kann.
Das kann man sich jeweils durchlesen. Also erstmal muss man sowas schreiben können. Das ist schon schwer genug. Und dann müssen Benutzer das lesen können,
was intellektuell keine besondere Hürde ist,
weil die meisten Leute können lesen,
bloß was das bedeutet, was da steht,
Das kann man sich in der Regel nur schwer vorstellen,
weil, das ist ja eine bestimmte Art von technischem Sachverstand auch voraussetzt und in diesem Sinne ist also so ein geschriebenes Entwurfsdokument,
also schön und gut, bloß,
dass man damit eine Handlungsfolge mal durchspielen kann.
Also auch im Sinne dessen,
was wir letzte Woche so besprochen haben, bekanntes Unwissen,
unbekanntes Unwissen, unbekanntes Wissen, das kann man mit textuellen Dokumenten,
kann man diese Art von Unsicherheit, Unwissenheit nicht ausräumen.
Insofern, der spielerische Umgang gerade in frühen Phasen eines Projektes
mit einem Prototypen. Also kann da extrem hilfreich sein,
um also nicht nur eine Frage zu beantworten, sondern auch,
um weitere Fragen zu stellen, die dann zum Lernen im Entwicklungsprozess beitragen.
So, Mock-ups. Das ist ein eingeführter technischer Begriff.
Also etwas aus Papier und Pappe zu basteln. Man glaubt es kaum,
aber das ist also in, je nachdem,
in welcher Art von Projekt man es zu tun hat,
also mal aus Papier und Pappe etwas zu schnipsen und dann
so zu tun
Als würde man jetzt mit einer Maus irgendwo drüber fahren und dann so ein Menü runterrollen zu lassen,
das aus echtem Papier ist. Also kann auch,
also das trägt nicht nur zur Belustigung der Anwender dabei,
sondern also bevor man also jetzt konstruktiv die konstruktiv anfängt,
die Finger so sich wohnen zu tippen, mal,
also mit solchen, mit diesen Techniken zu arbeiten,
kann also in frühen Phasen eines Projektes also enorm hilfreich sein.
Das veranschaulichte so die Arbeitsmöglichkeiten, die mit einem solchen System,
also zukünftig mal möglich sein soll, doch ganz enorm.
Was wir so im industriellen Alltag mitunter tun, ist, dass wir sogenannte PowerPoint-Prototypen bauen.
Und das ist nicht, also ich halte das mittlerweile,
früher habe ich so ein bisschen die Nase gerümpft darüber,
aber mittlerweile halte ich das für nichts Schändliches mehr,
dass man einfach mal eine Handhabungsfolge für ein Software-System,
dass man das mit PowerPoint demonstriert.
Und so tut, als würde man also da was eingeben und
dann kommt also eine neue Maske oder es verändert sich was, entsprechend. Und das kann man mit geringem Aufwand,
kann man dann da so Aha-Effekte, Lerneffekte erzielen,
die ansonsten konstruktiv nur schwer zu erzielen sind,
wenn man sich auf irgendwas, sowas schwergewichtige Programm Mehrsprache wie Java,
bis man da mal also diejenigen, die meisten von euch hören,
auch OOPM, bis man mal so eine Oberfläche gebaut hat,
also die sich so halbwegs so aussieht,
wie sie später mal aussehen soll, da vergeht schon ein bisschen Zeit.
Da gibt es jetzt gut, es gibt spezialisierte Sprachen,
mit denen man also sehr schnell grafisch auch ansprechende Oberflächen bauen kann,
aber warum soll man nicht auch mal sowas wie PowerPoint nehmen,
um also klar zu machen,
das ist die grundsätzliche Richtung, in die etwas geht.
Das hat sogar noch einen weiteren Vorteil,
also wenn man das mit sowas baut wie PowerPoint,
Man stelle sich nur mal den angenehmen Fall vor.
Man führt also diesen, so einen Demonstrationsprototypen vor.
Der hat also fast, der besteht fast ausschließlich aus Oberfläche.
Und der Auftraggeber sagt, toll, das möchte ich haben.
Können Sie das Anfang nächster Woche dann bitte gleich installieren?
Halt, stopp, wir sind noch nicht so weit.
Es ist nur eine Fassade, wie nur eine Fassade.
Sie können doch da überall drücken und es passiert doch was.
Ja, ja, aber also wenn man es mit unerfahrenen
Auftraggebern zu tun hat, kann einem das durchaus passieren,
dass die denken,
man ist fertig
Da fängt man gerade erst an, also das zu bauen.
Wenn man es mit PowerPoint baut, weiß jeder,
ach so, ja, es ist nur ein Holzmodell.
Es ist nur eine Kiste, die da steht,
die so tut, als wäre sie ein Auto.
Wir bauen das jetzt mit Pop mit PowerPoint und damit ist die Sache klar.
Also das ist immer auch eine Frage des wechselseitigen Lernens,
also zwischen Auftraggebern und Auftragnehmern,
welche Konsequenzen hat also oder welche Rückschlüsse ziehen eigentlich Auftraggeber aus dem,
was man da konstruiert.
Insofern wenn man nur mit einem genügend mächtigen Auftraggeber zu tun hat.
Und man zeigt eben einen Demonstrationsprototypen und der sagt, das ist es.
Nächste Woche will ich das haben und man hat dann einen Projektleiter,
der nicht mit genügend Rückgrat ausgestattet ist.
Dann sehe ich schon, also 24-Stunden-Schichten vor ihnen.
Also diesen Prototypen jetzt in Windeseile zum Laufen zu kriegen.
Und zwar in echt. Alles schon passiert. Deswegen,
also wenn Sie als zukünftige Projektleiter, da schließt sich Führungskräfte,
die hier ausgebildet werden.
Also ich habe es Ihnen hiermit gesagt,
der Kollege hat es aufgenommen
Machen sie sich vorher klar, so was sie mit einem
Prototypen erreichen wollen und machen sie es vor allem denjenigen,
die den Prototypen sehen, klar,
zu welchem Zweck dieser Prototyp da ist und was der kann und was er nicht kann.
Ja, Begriffliches nach Floyd, 1984, da wurde es dann niedergeschrieben,
wir erinnern uns, also Software Engineering, diese Provokation,
weil wir haben kein, es gab zu Beginn der,
also 60er Jahre, gab es keinen Software-Engineering.
Jetzt haben wir uns eine weitere in den traditionellen Ingenieurwissenschaften etablierte Technik,
haben wir uns angeeignet, nämlich also die Konstruktion von Prototypen.
Frau Floyd unterscheidet drei Arten von Prototyping und die sind in
der Welt der Softwaretechnik weltweit bekannt als die drei Es.
Und das sollten sie am Ende dieses Semesters dann auch,
also nachts um drei, selbst wenn sie vorher Alkohol konsumiert haben sollten,
sollten sie die drei Es,
sollten sie also in einem Satz rauskriegen können, explorativ,
experimentell und evolutionäres Prototyping.
Was ist es? So, exploratives Prototyping. Wird gerne
in frühen Phasen eines Projektes eingesetzt. Wenn noch ziemlich unklar
ist, also wie soll es denn überhaupt ausschauen?
Also was wollen wir denn jetzt überhaupt zum Problem erklären?
Welches, was gehört zum Problem und was gehört nicht mehr dazu?
Dann macht man exploratives Prototyping. Dann nennt man das auch so am Anfang eines Projektes,
dass man sagt, wir müssen jetzt erstmal so eine kurze Phase haben,
in der wir das Problem als solches versuchen,
Was er zu umfassen und zu sagen,
was gehört zum Problem und was wollen wir nicht zum Problem eines Projektes machen.
Das ist also die Grundidee von Explorativen Prototyping. Experimentelles Prototyping
. Kann das überhaupt klappen, was wir da vorhaben?
Was sind die kritischen Teilaspekte dessen, was wir machen wollen?
Wir müssen Experimente durchführen, um sicherzustellen, dass das,
was wir vorhaben, technisch überhaupt realisierbar ist.
Keiner von Ihnen wird auf die Idee kommen,
ich baue jetzt einen Prototypen,
so ein Mock-up oder auch von mir aus mit PowerPoint Point kriege ich das nicht hin,
nicht hin.
Eine automatische Echtzeitübersetzung. Den Prototypen dafür, den baue ich
echt schnell. Der kann dann drei Sätze übersetzen und also
auf der anderen Seite kommt dann also das Übersetzte raus.
Aber dann werden sie mich die nächsten 20 Jahre nicht wiedersehen,
weil ich werde, also ich schaffe es nicht, dass dieses Experiment durchzuführen.
Daran scheitern also die maschinellen Übersetzer mittlerweile auch seit einigen Jahrzehnten.
Also sie kriegen es einfach noch nicht hin. Also man sollte nicht Prototypen,
auch nicht explorative Prototypen, ohne die zugehörige konstruktive Gewissheit bauen,
dass man das also irgendwie schon hinbekommt, dass man explorativ den Anwendern versprochen hat.
Insofern, also der Raum für Experimente ist begrenzt. Nichtsdestotrotz,
also ein paar Experimente sind in der Regel notwendig,
vor allem, wenn man es mit neuen Technologien zu tun hat,
haben wir das schon mal,
also irgendeine Art von Datenbankanbindung schon mal mit dieser Technologie gebaut,
für dieses Mengengerüst innerhalb dieser zeitlichen Randbedingungen.
Also dafür ist experimentelles Prototyping gut. Evolutionäres Prototyping,
das geht jetzt schon in Richtung schrittweise,
so wie das auch bei den Grundbegriffen der evolutionären Softwareentwicklung genannt wurde,
evolutionäres Prototyping sagt, Ausbaustufen eines Systems werden schrittweise in die Organisation eingeführt.
Klar, definierte Aufgabenbereiche werden unterstützt und das System wächst in Ingrementen.
Die drei Es merken, merken, merken, explorativ, experimentell und evolutionär.
Haben Sie schon eine ganze Bandbreite, also von Techniken,
um unterschiedliche Arten von Fragestellungen beantworten zu können. So,
ein Ich hatte schon gesagt, dass das also typischerweise,
also zu in frühen Phasen eines Projektes, das explorative Prototyping eingesetzt wird.
Und so ein Begriff, der damit häufig in Zusammenhang auch gebracht wird,
ist also die Projektetablierung. Dass denen ein Projektbeteiligten klar wird,
wo läuft dieses Projekt insgesamt hin? Welchen Typ von Arbeitsplatz
werden wir unterstützen? Ich habe vorhin von dem Dümmsten einzunehmenden Benutzer gesprochen,
Ist es der, für den wir was bauen?
Oder bauen wir etwas für Experten in der Anwendungswelt?
Was wollen wir uns eigentlich, wie wollen wir uns da eigentlich positionieren?
Weil das wird auch für sie innerhalb eines Entwicklungsteams, wird es ganz wichtig sein,
da ist eine gemeinsame Haltung jeweils zu entwickeln, weil,
also dass ja auch sie davor schützt, also bestimmte Fehlentwicklung im Projekt durchzuführen.
Das noch zur Projektetablierung, Exploratives Prototyping.
Experimentelles Prototyping
Wie gesagt, technische Umsetzung eines Entwicklungsziels. Das wird also viel
auch so in der Phase Softwareentwurf, wird diese Technik eingesetzt. Wie gesagt,
es macht ja auch erst dann, also nicht erst dann,
aber spätestens dann macht es Sinn oder ergibt es einen Sinn,
also sich mit dieser Fragestellung zu beschäftigen,
also ob die und wenn ja,
wie diese bestimmte Konstruktionsmöglichkeiten überhaupt umgesetzt werden können.
Und der letzte evolutionäres Prototyping Konstruktion des Zielsystems,
also es geht hin auf die Konstruktion des Zielsystems.
Wir wollen schon für Anwender erfahrbare Aufgabenbereiche schon im alltäglichen Einsatz überprüfbar machen,
möglicherweise auch im Parallelbetrieb, zu der bestehenden Lösung,
um eine tatsächliche Rückkopplung über das, was wir gebaut haben,
zu bekommen.
Und man kriegt die direkteste Rückkopplung,
kriegt man halt dann, wenn man dann so das,
was man bauen will,
wenn das also schon im Arbeitsalltag eingesetzt wird
Das ist nicht immer möglich. Ich will jetzt auch nicht behaupten,
also wenn sie jetzt als zukünftige Projektleiter,
wenn ihnen jemand sagt, also wir müssen Big Bang machen,
dass sie sich dann schreiend abwenden und sagen, nee,
das machen wir nicht, weil ich habe an der Uni gelernt,
Big Bang ist Big Bang und deswegen machen wir das nicht.
Es gibt einfach Randbedingungen manchmal in Projekten, da geht es gar nicht anders.
Dann nehmen Sie mal die Umstellung eines Kernbanksystems, einer Bank,
einer Sparkasse, das können Sie nicht sukzessive machen,
können Sie nicht schrittweise machen,
weil an dem einen Tag läuft doch das eine System und
drei Tage später muss halt also das andere System laufen.
Das muss halt
dann organisatorisch begleitet werden
Es ist zwar schön, wenn man dieses ganze Instrumentarium beherrscht,
aber mitunter ist die Welt halt doch eckiger,
als man sich das so wünscht.
So, dann muss man eben mit solchen Randbedingungen müssen wir dann
halt leben. So, Prototyping, was gibt es denn
da noch an Schritten zu unterscheiden oder überhaupt an Begrifflichkeit?
Ich bringe ihn jetzt einfach, weißt du,
dass es möglicherweise auch ein bisschen zäh,
aber diese ganzen Begriffe sollten sie einfach mal gehört haben,
damit sie sie verinnerlichen können
Horizontales Prototyping. Also ich beschäftige mich im Wesentlichen mit der Oberfläche.
Vertikales Prototyping, ich mache Durchstiche bis also runter,
typischerweise zu einer Datenbank-Anbindung, dass ich also ganze Aufgabenbereiche erledigen kann.
Ich bin mir gleich über die unterschiedlichen Arten von Prototypen sprechen,
dann werden sie diesen Prototypen, werden sie dann auch,
also noch kennenlernen. Das habe ich ihn schon genannt.
Das ist der sogenannte Tee-Prototyp. Der hat eine breite Oberfläche,
sieht so aus, als könnte man alles damit machen.
Sie als Softwareentwickler wissen, sie haben einen Durchstich an
genau einer Stelle gemacht
Und können dann also diesen Prototypen im Entwicklungsprozess einsetzen, um andere Fragen zu klären.
Das nennt man dann den Tee-Prototypen. Also das ist so
eine Kombination aus horizontalem und vertikalen vertikalen Prototyping. Wer mit wem,
auf welcher Grundlage, ja,
also die Frage ist dann immer, also na nicht die Frage,
ich habe ja gesagt, es gibt keine Prototypenkonstruktion,
ohne dass damit eine Frage,
eine konkrete Frage verbunden ist,
die man
mit der Konstruktion eines Prototypen
beantworten möchte
Und hier geht es halt darum,
also im Vorfeld der Prototypenkonstruktion schon klarzumachen, wer ist derjenige,
der diesen Prototypen nachher bewertet und was bedeutet das,
dass dieser Prototyp dann von demjenigen bewertet worden ist.
Jetzt noch kurz vor der Pause noch die unterschiedlichen Arten von Prototypen.
Fangen wir mal hier mit dem Demonstrationsprototypen an.
Der kann, also so gut wie nicht,
demonstriert die grundsätzliche Art und Weise,
wie eine Lösung
angegangen werden soll
Dieses Ding wird man auch typischerweise, nachdem die mit der Demonstration verbundene Fragestellung geklärt ist, wegschmeißen.
Weil die Art und Weise, wie dieses Ding konstruiert ist,
in der Regel nichts damit zu tun hat, wie das eigentliche Zielsystem nachher konstruiert wird.
Also sie bauen den Demonstrationsprototypen, der sieht hübsch aus,
aber ist aber schnell und vergänglich und hat nichts damit zu tun,
wie das eigentliche Softwaresystem nachher von innen konstruiert wird.
Und das ist das, was ich vorhin ganz am Anfang meinte,
warum Prototyping so einen schlechten Ruf hat,
wenn man dann nämlich sagt, also ein Projektleiter,
der auch die Kosten im Auge hat, sagt dann,
Sieht gut aus, läuft, weitermachen an dem Ding.
Nächste Woche will ich die nächste Version dieses Prototypen sehen. Dann sollte der Verantwortungsvolle Softwareentwickler,
sollte seine mahnende Stimme erheben und sagen,
das Ding sieht ganz gut aus, aber,
also die Art und Weise, wie es gebaut wird,
wird uns spätestens drei Wochen,
wird es uns Verzeihung um die Ohren fliegen,
weil es eben nicht nach soliden technischen Konstruktionsprinzipien gebaut ist.
Anders sieht das aus hier bei diesen Arten von Prototypen,
der funktionelle Prototyp oder das Labormuster, Die gebaut werden,
um zum Beispiel festzustellen, ist unsere Datenbankanbindung schnell genug.
Wenn ich das mal mit einer soliden technischen Lösung nachgewiesen habe,
dass meine Idee tragfähig ist,
warum soll ich diesen Tee-Prototypen oder diesen Teil eines Tee-Prototypen,
warum soll ich den dann wegschmeißen?
Dann werde ich natürlich nicht tun, sondern ich werde den
in das Zielsystem einbauen. Ja, beim Pilotsystem,
denke ich, stellt sich die Frage schon gar nicht mehr.
Also das werde ich ja, das ist ja gerade,
wird das ja entwickelt,
um es also iterativ inkrementell in Ausbaustufen weiter zu verwenden und
im Echtbetrieb schon einzusetzen.
Ja, da haben wir jetzt schon einiges zu gesagt.
Es fasst es nur nochmal zusammen. So, und nach
der Pause mache ich hier weiter. Die Grundidee ist jetzt gelegt,
jetzt werden wir uns noch zwei, drei verschiedene Modelle anschauen,
die so böhm, den Namen haben sie auch schon gehört.
Also das ist der, der das Phasenmodell ursprünglich mal bekannt
gemacht hat. Nicht, dass er es erfunden hätte,
aber er hat es bekannt gemacht.
Und der hat also seine Überlegung zum Vorgehensmodellen dann unter anderem
hier in diesem Modell, also verdichtet dem sogenannten Spiralmodell.
Und wir sehen uns hoffentlich um fünf
nach drei wieder
Das Spielhallenmodell. Mann. Ja. Jetzt gucken Sie sich das mal so,
lassen Sie das so eine Sekunde auf sich wirken?
Das kann man sogar lesen. Schauen Sie mal,
dass dieses Spiralmodell heißt, also in der Literatur auch,
ist es bekannt als Risk-Driven-Software-Development. Das ist so die Aufgabe,
die der Projektleiter, wenn er sich an diesem Vorgehensmodell orientiert,
ist unter anderem, dass der jederzeit sagen können muss,
was sind die zehn größten Risiken des Projektes
Welche Risiken haben sie, die sie daran hindern,
also den Projekt, den geplanten Projekterfolg zu erzielen?
Das müssen sie immer sagen können. Und man hofft man doch,
dass diese Risiken sich so im Laufe des Projektes verändern.
Es sollten nicht immer dieselben Risiken sein. Würde ich auch
sagen, als Projektleiter, da ist irgendwas falsch gelaufen.
Und was tut man, um so seine Risiken benennen und beherrschen zu können?
In jeder Iteration werden also Prototypen konstruiert, die dazu dienen sollen,
dass also als solches erkannte Risiko zu minimieren,
das auszuschalten
Sehen Sie hier so in diesen einzelnen Zyklen, was da so von,
das wird von innen nach außen, wird das, also wird das interpretiert, dieses Modell.
Das ist also der Prototyp 1, damit verbunden ist überhaupt erst mal so ein Lebenszyklus für dieses Projekt herzustellen. Dass man,
wenn man spätestens nach diesem Modell, was heißt spätestens,
so im Entlang der weiteren Prototyp-Konstruktion,
soll also das System spezifiziert werden, also eigentlich genau die Phasen,
die schon aus dem Phasenmodell bekannt gewesen sind,
werden hier zyklisch durchlaufen und man sieht ja,
je weiter man also so nach außen in diesen in diesen,
in dieser Spirale kommt, desto näher ist man also am Einsatzkontext.
Bis hin also zu dieser äußersten Spirale hier, wo schon operationale Prototypen,
also das, was ich vorhin als evolutionäres Prototyping bezeichnet habe,
dass so ein operationaler Prototyp eingesetzt wird und dann folgen jetzt in diesem,
also sobald man so einen operationalen Prototypen hat, der,
also das kann man jetzt so interpretieren, dass dieser Prototyp dann,
also nicht weggeschmissen wird, aber dass also die Code,
in diesem Moment klar ist, was ist das,
was wir bauen wollen.
Und dann kann man auch eine Aussage darüber machen.
Also wie soll es denn gebaut werden? Und dann können also
die Einzelnen aus dem Phasenmodell schon bekannten Phasen, können diese Phasen durchlaufen werden.
Also das ist so die Antwort, sagen wir mal,
die Weiterentwicklung des klassischen Einbahnstraßenmodells gewesen, das Spiralmodell,
auch eben Risk-Driven, Software-Development.
Das ist also versucht, diese Idee,
die ja auch mit der Lehmannischen Klassifikation von Softwaresystemen verbunden ist,
Einführung von Software verändert, auch also die Art und Weise,
wie wir über das zu lösende Problem nachdenken.
Und das Spiralmodell ist also eine Ausprägung eines zyklischen Vorgehensmodells,
das in der Praxis nur eigentlich relativ weit verbreitet ist.
So, ups. Also Phasen,
das kann ich jetzt auch nur noch mal betonen,
also es ist, es spricht überhaupt nichts dagegen,
also dass so Softwareentwicklung in Phasen zu unterteilen, was halt wichtig ist,
also um das so ist die Art und Weise,
also wie man mit diesen Phasen, mit den Ergebnissen von Phasen umgeht.
Und das ist hier so eine ganz tragfähige Interpretation,
so im Sinne des Softwareentwicklung ist ein Lernprozess,
dass diese Phasen dann iterativ durchlaufen werden und Rückgriffe auf sogenannte frühere Phasen immer möglich sind.
So, jetzt noch mal, also jetzt wissen wir unheimlich viel darüber,
also wie man so in Projekten vorgehen kann,
was heißt wissen unheimlich viel, das wissen schon viel mehr als jedenfalls,
so noch vor zwei Wochen.
Und jetzt stellen wir uns mal die Frage,
ja auch ganz am Anfang, jetzt nicht der heutigen,
aber der letzten Vorlesung eine Rolle gespielt hat.
Also welche Fragen kann man denn jetzt so,
was will denn so ein Projektmanager?
Was will das Projektmanagement? Typischerweise von einem Entwicklungsprojektwissen,
unter anderem war da zum Beispiel die Frage, wie weit seid ihr denn?
Wann kann ich damit rechnen, dass es fertig wird?
Gab es Änderungen an dem ursprünglichen Plan? Und wir schauen uns
jetzt mal auf unseren ganz kleinen Blick so in die Richtung.
Wie kann denn so eine Projektplanung auf Basis eines Vorgehensmodells dann eigentlich aussehen?
Dazu ist es so der Begriff, der der einzige Begriff,
der jetzt hier eigentlich eine Rolle spielt,
ist also die Erarbeitung einer Zielvorstellung
Das heißt, ich will schon am Anfang des Projektes,
also möglichst schnell jedenfalls, nach Beginn eines Projektes, eine solche Zielvorstellung erarbeitet haben.
Und das Modell, das jetzt das Vorbild für all die Überlegungen,
die jetzt hier eine Rolle spielen, ist, sie überlegen mal im Hinterkopf,
während ich hier erzähle, wie sie ihre Geburtstagsfeiern planen.
Wobei ich ein, das einzige, so unterschiedlich,
wie wir unsere Geburtstage möglicherweise durchführen, das, was,
denke ich, allen Geburtstagsfeiern gemeinsam ist, Wenn man nicht gerade,
also doch selbst die Königin von England,
also macht ihren Geburtstagsfeier an einem bestimmten Tag,
das ist nicht notwendigerweise ihr Geburtstag,
aber eine Geburtstagsfeier findet zu einem vorherbestimmten Termin statt.
Und daraufhin muss die Planung ausgerichtet sein.
Und das gucken wir uns mal an. Die Grobplanung,
also hier bei dem Grundkonzepten, sieht also so aus,
ich möchte ein Softwareentwicklungsprojekt, möchte ich, wie das hier steht,
von hinten nach vorne planen. Und das bedeutet,
ich nehme mir jetzt den geplanten Endtermin und dann werde ich also Etappenweise,
werde ich dieses Projekt bis zum heutigen Datum so zurückplanen.
Eben von hinten nach vorne eben Zeitstrahl. Und jetzt kann es
aber passieren, das ist ja Risk-Driven-Software-Development, dann at its best.
Ich weiß also ziemlich genau, nehmen wir mal an,
unser Projekt soll am 31.12. des Jahres eingeführt werden.
Das bedeutet, ich muss zum 30.09., also mache ich einen sogenannten Code Freeze.
Ab dann darf nicht mehr entwickelt werden, es wird nur noch getestet.
Um das machen zu können, muss ich zum 30.09.,
muss ich also bestimmte Vorleistungen erbracht haben.
Um das machen zu können, müsste ich so eigentlich am 31.03.
das System vollständig so im Griff konzeptionell im Griff haben.
Jetzt gucke ich auf den Kalender und stelle fest,
es ist, was haben wir heute, 14.05.
irgendwas von der er kannte. So, es ist gar
nicht 31. 30. Das heißt, ich weiß heute schon,
ich bin sechs Wochen hinterher. Also werde ich als erstes
jetzt mal zu meinem Auftraggeber gehen und sagen,
sechs Wochen, also sind wir hinter dem Zeitplan.
Dann können wir bitte am 15. 4. Fe 5. 40. 5,
5, nein. d. Am 30. 32. 3. 3. 3.
3. 3. 3. 3. 3. 3. 3. 3. . 3..
4. Das ist 3. 3. Das ist das 3. .
Das ist, 3. 3. . . Das ist das . .
Das ist, 3. d. . d. . min d. .
. da. . .
Können Sie zusätzlich Leute einstellen und dann hoffen,
dass das so Projekt schneller fertig wird.
Noch Vorschläge? Das Einfachste ist, wir liefern weniger.
Ja, wie machen Sie denn
das mitmachen
Ja keine, man darf ja nie was ausschließen. Das ist also,
also man darf nicht weniger abliefern als das Minimum dessen,
was also jetzt am 31.12. verlangt wird.
Aber irgendwie müssen wir ja aus dem Schlamassel rauskommen. So,
und jetzt können sie sich auch überlegen, also machen sie sich das,
also ich will es jetzt wirklich nicht, also zu sehr banalisieren,
aber sie machen ihre Geburtstagsfeier dann halt an dem Tag,
an dem sie Geburtstag haben.
Und wenn es dann halt statt zwei Nudelsalaten
nur einen gibt, gibt es halt
nur einen
Oder sie laden nur die Hälfte der Leute ein und merken
die anderen nicht, das ist nur die Hälfte.
Aber so, worauf ich hinaus möchte, die Grobplanung,
die muss von hinten nach vorne, muss die passieren.
Und dann können sie eine einzelne Projektetappe dann von vorne nach hinten planen.
Also dann haben wir, sagen wir mal,
eine ungefähr dreimonatige Projektetappe, wo sie genau wissen,
das ist das, was am Ende rauskommen soll.
Und die plane ich jetzt mal von vorne nach hinten.
Wer tut was in den nächsten drei Monaten?
Und das allererste, was sie machen, ist ein Urlaubsplan.
Es ist immer wunderbar, so festzuhalten,
wer ist in dem Projekt eigentlich, war nicht da,
was also die Kapazität schon mal in der Regel um
20 Prozent verringert
Dann stellen Sie neue Leute ein, schon klar. So,
dann zeige ich Ihnen jetzt mal gleich so ein paar Beispiele für solche Planungszielsetzungen,
so das Übliche, Firmenkundengeschäft einer Bank soll so reorganisiert werden,
dass pro Jahr ein Gewinn von einer Million in dieser Sparte erwirtschaftet wird.
Vielleicht sollte man in Zeiten der Finanzkrise jetzt auch mal langsam
ein paar andere Beispiele hier einführen.
Aber das sind dann halt Es sind dann halt so die Leitideen
für eine Zielsetzung anhand derer sich also ein Projekt anfangen kann zu organisieren und wo wir jetzt,
also wenn das so der Auftrag ist,
den kann man ja dann im Rahmen eines, einer Projektetablierung,
kann der ja dann auch entsprechend verfeinert werden.
Das Mittel, mit dem wir das Projekt,
also wenn es denn mal in solchen Etappen von hinten
nach vorne so grob durchgeplant ist,
habe ich schon genannt,
das sind also die sogenannten Projektetappen und jede Projektetappe
ist also typischerweise mit einem Prototypen der unterschiedlichen Arten,
also von den unterschiedlichen Arten verbunden
Sodass man also die erste Projektetappe zum Beispiel damit verbringt,
also sich darüber im Klaren zu werden,
was will ich denn jetzt eigentlich genau bauen und dann einen entsprechenden Demonstrationsprototypen herstelle.
Das ist also Kernpunkt, also der jeweiligen Projektetappe und es ist so
von der Vorgehensweise dann denke ich auch so relativ kompatibel zu dem,
was das Spiralmodell vorsieht.
Das ist eine Projektetappe ist mit mindestens der Konstruktion eines Prototypen
verbunden und anhand dieses Prototypen wird festgelegt,
ob das Ziel der Projektetappe erreicht ist.
Hier sehen Sie so ein Beispiel für so eine Projektplanung von hinten nach vorne.
Hier ist also der So, das ist das eigentliche Projektende.
Was soll da erreicht sein? Also die erste Ausbaustufe von was auch immer.
Also ist da vom Vorstand des Auftraggebers sich da akzeptiert.
Und wie wollen wir diese, wie wollen wir das Ziel,
das erfolgreiche Ziel dieser Etappe, wie wollen wir das feststellen?
Naja, es gibt halt einen Workshop mit Anwendern. Und jetzt sehen Sie so,
wenn Sie hier diese Etappen so mal nach hinten,
also von hinten nach vorne gehen, also bis zu nahe an dem Datum,
an dem wir uns jetzt befinden, Was ist da so ein Prototypen gebaut worden?
Na, zunächst mal ein Handhabungsprototyp mit den begleitenden Dokumenten,
dann ein Laborprototyp, in dem schon mal so das Haussystem,
also so die zentrale Datenverarbeitung stattfindet, das ist hier,
also dann ist der Durchstich, ist da schon gelungen,
dann geht es an den Arbeitsplatz und die heißen die halt Account-Manager an den Arbeitsplätzen,
die durften schon mal mit Handhabungsprototypen dann umgehen,
bis dann zu dem Zeitpunkt,
also hier ist dann da so im Echtbetrieb.
Das heißt, hier ist schon, also mindestens so eine Art von Pilotsystem,
ist hier im Einsatz, um dann,
also das eigentliche Projektziel einsetzt in allen Filialen, an allen Arbeitsplätzen, also um das vorzubereiten.
So, das ist so die Art und Weise, wie, also so wie das Denken in solchen Spiralmodellen beziehungsweise in solchen Autokritikerzyklen dann nochmal organisiert werden kann. So,
Namen Leute, die große Beiträge zu dieser Diskussion geleistet haben,
Eva Jakobsson, so einer der Gewinner des sogenannten,
also Method, der sogenannten Method Wars,
so das war ein bisschen vor ihrer Zeit,
dass sich so in der Welt der Vorgehensmodelle,
dass die sich im Rahmen der objektorientierten Softwareentwicklung auch noch viele Leute viel gestritten haben,
wie man eigentlich vorgehen soll, das Ergebnis,
also heute ist bekannt unter diesen beiden Kürzeln hier,
einerseits ist die Unified Modeling Language,
also ist die Menge von Diagramm Typen,
mit denen man also alle möglichen Aspekte eines Entwicklungsprozesses eines Entwicklungsprojektes beschreiben kann und der Entwicklungsprozess selbst,
der sich durchgesetzt hat,
über die Jahre ist der sogenannte Rational Unified Prozess,
kurz Rupp.
Und nach diesem Entwicklungsprozess, der auch zyklische Elemente enthält,
also werden Software können auch sehr,
sehr große Softwareprojekte mit mehreren hundert bis tausend Mitarbeitern durchgeführt werden.
Da gibt es jetzt mittlerweile dann auch eine etablierte,
ein etabliertes Vorgehensmodell für diese Art von,
oder für diese Größenordnung von Projekten Iva Jakobson ist derjenige gewesen,
der sich sehr stark also mit sogenannten Use-Cases beschäftigt hat.
Also der hat also eine Methode entwickelt, hier Object Oriented Software Engineering.
Und das ist das sogenannte Use-Case-Driven Software Development, Softwareentwicklung auf Basis von sogenannten Anwendungsfällen.
Es werden kleine Geschichten geschrieben und diese Geschichten sind in der Sprache des Anwenders formuliert.
Und die Aufgabe des Softwareentwicklungsprojektes besteht darin, diese Geschichten,
so weit herunterzubrechen, dass also das ausführbare Software draus abgeleitet werden kann.
Und das ist auch Teil, also Use-Cases, Use-Case Dialgrams,
sind auch Teil der UML und damit so auch Teil,
also dieses Vorgehensmodells, Rupp. So,
das Modell sieht jetzt also ein bisschen anders aus als,
aber nur ein bisschen, also das ursprüngliche Autor-Kritiker-Zyklusmodell,
dass ich ihn ganz am Anfang dieser Vorlesung gezeigt habe.
Also insbesondere ist es erstmal im Uhrzeigersinn,
was ja bekanntlich gute Laune macht und dann, das,
was die, was dieses Management ja schätzt,
also es hat einen Anfang und es hat ein Ende.
Das ist auf den ersten Blick erkennbar. Wir machen also
eine initiale Planung, in der also Anforderungen erhoben werden.
Etwas, was über den eigentlichen Kern,
also der Softwareentwicklung hinausgeht
Findet also im Rupp auch, findet sich im Rupp wieder.
Geschäftsprozessmodellierung. Das heißt, der organisatorische Kontext eines Entwicklungsprojektes wird explizit berücksichtigt.
Und die Anforderung, Anforderungen werden im Rahmen einer Geschäftsprozessmodellierung, werden die erhoben.
Analysedesign, Implementierung, Testbewertung. Das ist also die Phasen,
die klassischen Phasen eines Entwicklungsprojektes nach dem Phasenmodell.
Das müssten Sie jetzt mittlerweile auch langsam beten könnten,
beten können
Also da passiert jetzt nichts Neues mehr. Das sind so die Phasen,
oder das denken wir mal, das sind die Tätigkeiten in einem Entwicklungsprojekt.
Und das, was der Unified Process geschafft hat,
ist diese Idee eines zyklischen Vorgehens auch für sehr,
sehr große Projekte handhabbar zu machen.
Sie können sich das in ihren Unterlagen dann auch noch mal
im Detail anschauen. Ich wollte das nur noch mal hier
einmal so auf der Ebene so einer Grafik zeigen.
Also typischerweise werden nach Rupp oder Unified Process durchgefolgte Projekte werden
also in Zyklen durchgeführt und jeder Zyklus beinhaltet Phasen.
Und jede Phase beinhaltet Iterationen. Und jetzt kann sie sich mal,
können sie sich ja anschauen, also diese ein einzelne,
Entschuldigung,
ein einzelner Zyklus enthält also verschiedene Phasen und innerhalb einer Phase
gibt es dann typischerweise eine bis mehrere Iterationen und jede einzelne Iteration
enthält also alle Phasen des ursprünglichen Phasenmodells
Jetzt können sie, das ist jetzt,
legt jetzt so wie ein offenes Buch,
liegt also dieses Vorgehensmodell vor ihnen und sie sagen,
ja, ich entwickle nach einem zyklischen Vorgehensmodell,
nämlich dem Unified Process und was sie machen, ist,
ein Zyklus, eine Phase, eine Iteration,
sprich ein klassisches Wasserfallmodell.
Ist alles drin. Was so nichts anderes heißt,
also machen sie sich im Projekt einfach klar,
welchen Typ von Antwort mit welchem Typ von Anforderungen sie es
zu tun haben und wie viel sie da in Anführungsstrichen zykeln wollen oder müssen, um positives Projektergebnis hinzubekommen.
Der Unified Process als Vorgehensmodell lässt ihn da die ganze Freiheit,
also von mehreren Zyklen mit mehreren Phasen und ständigen Wiederholungen,
also bis hin zu, wir gehen einmal durch,
also das Vorgehensmodell, das ist so richtig so ein Catch-all für alle Vorgehensmodelle oder für alle Möglichkeiten vorzugehen.
Einen Punkt möchte ich aber dann doch noch hervorheben,
also der Use-Case-Driven hatten wir gesagt, Anwendungsfälle sind also der Ausgangspunkt der Modellierung.
Wir haben jetzt in der ganzen Diskussion Über Vorgehensmodelle habe ich
noch kein einziges Wort über Architektur verloren.
Das hat sich so in der letzten, in den letzten Jahren,
hat sich das also immer stärker eigentlich so,
ist dieses Thema etwas mehr in den Vordergrund gerückt.
Christiane Floyd hat das mal so hübsch zusammengefasst. Also im
Mittelpunkt steht der Mensch und im Zentrum steht die Architektur.
Kurz nachdenken. Das ist wie wenn sie nach Berlin fahren,
also von Hamburg aus müssen sie sich irgendwann entscheiden,
ob sie ins Zentrum West oder Zentrum Ost fahren wollen.
Eigentlich ist das Quatsch
Es gibt halt ein Zentrum. Man kann nicht gleichzeitig
im Mittelpunkt den Menschen sehen und im Zentrum die Architektur.
Was soll denn das? Was sie damit sagen wollte.
Und der Gedanke ist schon richtig, Architektur, Blaupausen spielen eine
immer größere Rolle, auch in der Diskussion über Vorgehensmodelle.
Welche Art von Software-System wollen wir bauen und wie sieht die prinzipielle Architektur aus?
Das wissen wir mittlerweile. Welche Arten von Architekturen, also bewähren sich,
weil wenn ich jetzt also ein paar von ihnen in ein Projekt stecken würde,
mögen sie möglicherweise, also einigen sie sich schnell auf eine gemeinsame Vorgehensweise,
bis sie sich aber auf eine gemeinsame Architekturvorstellung geeinigt haben,
das dauert dann möglicherweise noch ein bisschen länger.
Also die Idee, Architektur zentriert, vorzugehen. Also es
gibt also nochmal einen zusätzlichen Gesichtspunkt in dieser Diskussion über Vorgehensmodelle.
Diese Diskussion finden wir weder im Wasserfallmodell noch,
also klassisch bei den zyklischen Modellen, beim Spiralmodell,
haben wir das auch nicht gesehen, wie man Prototypen baut,
ist da ja, was die Architektur anbetrifft, wird da überhaupt keine Aussage zu getroffen.
So, zum Schluss sogenannte agile Methoden.
Der letzte Hype bei den Vorgehensmodellen
First things first et zeuge möglichst schnell, möglichst viel Geschäftswert.
Wie das definiert ist, steht hier sogar.
Also es ist die Inkrement, die agilen Methoden kommen jetzt
heutzutage alle aus den USA und sind sehr knackig typischerweise formuliert.
Deliver Early, Deliver Orphen. Man bringt es jetzt auf
den Punkt, es ist so schnell wie möglich,
so viel wie möglich zu implementieren.
Jeden Tag, also möglichst so irgendwas funktional, Sinnvolles herzustellen.
Gestalte den Entwicklungsprozess möglichst leicht gewichtig. Das ist auch eine
Gegenreaktion zu, also dem, was man so mit dem
Unified Process verbindet
Regal meterweise Dokumente erstellen, bevor man anfängt zu entwickeln.
Agile Entwicklungsmethoden sind typischerweise leichtgewichtig, der Prozess des Entwickelns
steht im Vordergrund nicht der Prozess des Dokumentierens. So,
ein Punkt, den ich noch nicht,
also der noch nicht, also bei den anderen Vorgehensmodellen,
so jetzt wiederum als Erweiterung vorgekommen ist,
der Prozess selbst steht regelmäßig zur Diskussion
Das heißt, das, was typischerweise in Entwicklungsprojekten nachagieren,
Entwicklungsmethoden passiert, ist, dass das Entwicklungsteam nimmt sich die Zeit,
um über, also in bestimmten Abständen,
um über den eigenen Entwicklungsprozess zu reflektieren.
Was können wir in der nächsten Iteration in der nächsten Phase,
im nächsten Zyklus, was können wir besser machen,
was ist nicht so gut gelaufen,
wo können wir uns noch in unserer Effizienz steigern.
Collective Code Ownership, insbesondere ein Mittel,
um den sogenannten Truck-Factor zu minimieren.
Truck-Factor,
sagt Ihnen das was
Vielleicht schon mal irgendwo aufgeschnappt. Wenn Sie mich als Projektleiter fragen,
was ist also das, was sind so nach dem Spiralmodell,
was sind die größten zehn Risiken?
Und mir fällt ein, wenn der Kollege Meyer vom Bus
überfahren wird oder vom Laster-Truck-Factor, dann steht das Projekt still.
Da muss ich was tun. Der Truck-Factor gibt an,
wie hoch ist das Risiko Ihres Projektes,
wenn ein Mitglied des Projektes vom Laster überrollt wird.
Als Projektleiter muss ich
dieses Risiko minimieren
Jetzt kann ich sagen, du Meier fährst nicht
mehr Bus und also ich bleibe es immer hier.
Das ist eine Möglichkeit, wie weit das mit Arbeitsschutz und
so Verbindung gebracht werden kann, glaube ich nicht.
Also mache ich was anderes, das ist sozialverträglicher.
Ich setze zwei Leute an die Aufgabe. Zack,
habe ich also meinen Truck-Factor, was diesen Bereich anbetrifft,
auf den 0,5 gebracht. Und dann kann ich mir halt
eine Grenze setzen, wie tief will ich runter?
0,3. So zum Beispiel, weiß ich aber auch genau,
das kostet mich mehr. Und dann habe ich halt drei Leute,
die sich mit einer Funktionalität auskönnen,
die muss ich erstmal in diese Funktionalität eingearbeitet haben
Ich muss jetzt also, ich kann jetzt anfangen,
also mit Größen zu spielen, in Anführungsstrichen.
Aber ein Punkt in dieser Diskussion und deswegen komme ich da
eben genau an der Stelle drauf, oh Gott,
was ist das denn?
Collective Code Ownership. Jeder ist berechtigt,
an jeder Stelle des Systems etwas zu ändern.
Ist er dann auch dafür verantwortlich? Das verringert auch,
also die Gefahr von einzelnen Personen abhängig zu werden.
Kunde ist Teil des Entwicklungsprozesses, ja,
so wie wir das bei der Grundidee der zyklischen Vorgehensmodelle
auch schon gesehen hatten
Das Manifest für agile Softwareentwicklung. Das ist also ein berühmt gewordenes Papier.
Also wenn Sie das hier googeln, Manifesto for edgile Software Development,
da kriegen Sie ganz sicher genau diesen Treffer hier.
Worauf kommt es den Unterzeichnern dieses Manifestes an? Naja,
Individuen und die Beziehungen zwischen den Individuen sind wichtiger als Prozesse
und Werkzeuge. Funktionierende Software, laufende Software ist wichtiger
als so Dokumentation
Zusammenarbeit mit dem Kunden ist wichtiger als Anwälte zu beschäftigen,
sich auf Veränderungen einzulassen, ist wichtiger als einen Plan zu folgen.
Jetzt sagen die, das, was uns wichtiger ist als das,
was uns unwichtiger ist, das steht zwar im Vordergrund,
aber das andere werden wir nicht vernachlässigen.
Entscheidend ist der Grundgedanke. Wir sind ständig,
also segeln wir hart am Wind,
was also Veränderungen anbetrifft und sind jederzeit bereit,
Veränderungen in unseren Plan aufzunehmen.
Genau diese Haltung hat dann auch so die Gegenbewegung wiederum,
siehe Ludeweg Lichter,
Die sagt, jaja, ja, also ist ja schön und gut,
wenn man immer auf, also Veränderungen reagieren möchte.
Aber wenn man so einen Planungshorizont hat, der ungefähr so weit ist,
also dann kann man auch nicht verantwortungsvoll größere Softwareentwicklungsprojekte durchführen.
Also da, wir werden das im Laufe des Studiums,
werden sie da, werden sie dann noch so ein bisschen,
also differenziert darüber sprechen. Jetzt geht es ja erstmal darum,
überhaupt also zur Kenntnis zu nehmen, dass es sowas gibt,
wie agile Softwareentwicklung und damit verbundene Techniken.
Axel Schmolitzky wird in der anderen Vorlesung,
OOPM wird ja noch was, also variierter über Extreme-Programming sein,
sagen, ich werde jetzt hier nur noch so ein paar grundsätzliche Bemerkungen machen.
Und wenn sich das Ding noch weiterdreht, werde ich wahnsinnig.
So, das sind also die Leitlinien aus dem agilen Manifest.
Und die Werte, die also mit agiler Softwareentwicklung verbunden sind,
sehen sie hier. Also eine Nummer einen möchte ich da
rausgreifen, Einfachheit im Englischen ist es das KISS-Prinzip.
Keep it simple and stupid
Wir bauen die einfachstmögliche Lösung, die funktioniert.
Wir bauen also nicht, also der Softwareentwickler, nicht,
dass ich ihnen was unterstellen möchte, neigen dazu,
Technologie auf Vorrat zu bauen.
So, es könnte ja sein, dass auch noch diese
Anforderungen auf uns zukommt. Nein, wir bauen das,
was also eine gegebene Anforderung braucht und unser Code soll unsere Architektur,
unser Code, also soll so einfach wie möglich sein.
So seht dann also,
jetzt also zyklischer kann man sich ja jetzt
kaum noch vorstellen
So sieht also die Grundidee aller agilen Methoden aus.
Etwas, was also eigentlich so, und das muss man,
was heißt muss man? Also das, agile Methoden,
also es sind insofern nichts Neues, als dass die jetzt
im Großen und Ganzen mit etwas unterschiedlicher Betonung, bekannte Techniken zusammenführen.
Oder es geht dann zum Beispiel, das geht hier unten bei den,
also kürzesten Zyklen geht das los per Programming.
Einer sitzt an der Tastatur, einer guckt zu,
Pilot, Co-Pilot, der Co-Pilot fragt die ganze Zeit,
was machst du da, wie machst du das,
warum machst du das, die unterhalten sich darüber, programmiert wird.
Auch, also Minimierung des Truck-Factors. Es wird ständig getestet,
bis hin also zu denjenigen, die einen sogenannten Test-Driven-Development propagieren.
Wir schreiben erst den Test für eine Software, dann die zu testende Software.
So per Negociation, also Abstimmung zwischen den Paaren, alle paar Stunden.
Jeden Tag ein Stand-Up-Meeting. Alle stellen sich hin für eine halbe Stunde,
Viertel, Viertelstunde, je nachdem, wie groß das Projekt ist.
Also man sollte sich nicht acht Stunden am Tag hinstellen und Meetings
machen nach dem Motto, was habt ihr die letzten 24 Stunden gemacht.
Aber die Grundidee ist, also sich ständig,
darüber auszutauschen, was haben wir gemacht,
was machen wir in den nächsten 24 Stunden,
wie soll das Projekt so ist, sind wir im Plan bei der Umsetzung unserer, bei der Umsetzung unserer Aufgaben.
Akzeptanz, Test, Iterationsplan, auf Wochenebene und Release-Plan,
also das sind dann die Monatsebene,
so typischerweise alle drei,
maximal sechs Monate ein neues Release für ein Stück Software
So, das sind so die, das ist so ziemlich herausfordernd,
also nach diesen Methoden zu arbeiten,
aber so die Grundidee ist, qualitativ hochwertige Software,
entsteht dadurch, dass so ständig Leute miteinander darüber sprechen,
was sie da eigentlich bauen und also so Code-Inseln, wo jemand sagt,
das ist mein Code und danach darf auch kein anderer drauf gucken und so,
das ist alles, also Schnee von gestern, so ein typisches,
agiles Team, das ist eher so ein Bienenschwarm,
also die alle zusammen an etwas bauen und ständig darüber reden,
weiß ich nicht, ob Bienen das machen,
aber jedenfalls wirkt es, also so von außen so,
Entwicklungsprojekt.
Alle reden ständig darüber, was sie denn jetzt nun machen und was als nächstes passiert.
So, wer sind relevante Vertreter von agilen Methoden? Also das,
was ich jetzt hier im Großen und Ganzen,
also kann man davon, kann ich nicht empirisch belegen,
aber diese Methode hier Scrum, die scheint sich also durchzusetzen,
das ist eher eine Managementorientierte, agile Methode,
Extreme Programming, habe ich schon darauf hingewiesen,
Axel Schmolitzki wird es noch wieder etwas detaillierter.
Darüber sprechen ist eher eine aus dem,
also aus der stellt in den Vordergrund, so Programmiertechniken und wie man sich,
wie sich Programmierer in einem Projekt organisieren werden.
In diesem Sinne hatte ich schon davon gesprochen,
also der Fenstersturz, boom, Big Bang,
das ist also das Phasenmodell versus, also agile Softwareentwicklung,
ständige Rückkopplung über das, was passiert.
Das stellen sie sich dann eben vor wie ein Fenstersturz,
jede Treppenstufe tut weh,
aber sie haben eine gute Chance,
unten lebend am zu kommen
Beide Vorgehensarten von Vorgehensmodellen haben gemeinsam, also die Einsicht,
es ist Softwareentwicklung, ist ein schmerzhafter Prozess. Nur diese Art von Schmerz,
also überlegen Sie typischerweise viel einfacher, als also den Big Bang-Ansatz, der mit einem Phasenmodell verbunden ist. Noch ein Name noch,
das ist auch gut, Can't Back,
der wird uns noch an anderer Stelle begegnen,
nämlich dann, wenn es um sogenannte Entwurfsmuster geht,
also das ist auch so ein richtiger Tausendsasser,
der hier hat, also diese ganzen Techniken,
das Extreme-Programming, die sie auch noch kennenlernen werden,
die hat er auf den Begriff gebracht und ist,
also das hat auch einen wirklichen Einfluss gehabt auf,
also auf die Diskussionen in Vorgehensmodellen und so vielfältig wird das also auch schon heutzutage in der Praxis so eingesetzt.
So, liebe Mädchen, liebe Jungs, das war's für heute.
Ich hoffe, es fanden nicht alle alles stinklangweilig.
Ein paar Sachen haben sie hoffentlich mitgenommen, da müssen sie
jetzt mal durch. Diese ganze Begrifflichkeit bei den Vorgehensmodellen
Und ich hoffe, sie kam jetzt so in ihrer Methoden-Schrankwand.
Da haben sie so ein paar neue Schubladen drin und können die
dann in einem Entwicklungsprojekt in der Praxis so bald wie möglich anwenden.
Schönes Wochenende, danke, dass Sie hier waren.
Bis bald