So, es geht gleich los, bitte nehmen Sie Platz, machen Sie Ihre
Ablenkungsgeräte aus.
Und machen Sie mit.
Ein paar Sekunden gibt es noch.
So, also wir waren jetzt bei den Schätzmethoden, die machen wir heute
fertig.
Und dann fangen wir an mit den Prozessmodellen, da kommen natürlich
alte Bekannte, wie das FAST-Modell nochmal vor, aber auch Extreme
Programming und Scrum und das Microsoft-Modell.
Ich habe da was Interessantes für die nächste, für die letzte
Vorlesung aufbewahrt.
Muss ja sein, oder?
Etwas, was Spaß macht.
Und also heute machen wir jetzt die Schätzmethoden fertig.
Wir hatten letztes Mal von der sogenannten Analogie-Methode gehört.
Die Analogie-Methode sagt einfach nur, wir haben ein ähnliches Projekt
schon mal durchgeführt.
Wir wissen, wie teuer das war.
Wir können in etwa abschätzen, was wir von dem alten Projekt wieder
benutzen können, wenn es sowas gibt.
Wir wissen, wie viel davon wir überarbeiten können, müssen und wie
viel neu hinzukommt.
Und das schätzen wir einfach mit den gleichen
Aufwandsfaktoren wie bei der ursprünglichen Entwicklung.
Wenn etwas komplizierter ist, dann legen wir da noch etwas zu.
Das war die Analogie-Methode.
Es ist natürlich einfach, global Schätzung.
Es wird nicht aufgeteilt in große Unterprojekte oder so etwas.
Ist aber relativ ungenau.
Es gibt noch eine Variante davon, die heißt der Planungspoker.
Den schauen wir uns aber noch genauer an.
Da sagt man einfach in einem Treffen, wie viel man meint, dass es
kosten wird oder dauern wird.
Und dann schaut man sich die verschiedenen Schätzungen der Teilnehmer
der Gruppe an.
Und dann diskutiert man so lange rum, bis man auf eine gemeinsame
Schätzung kommt.
Aber ich werde Ihnen das noch einmal genauer zeigen.
Da gibt es sogar Spielkarten dazu.
Darum heißt es Planungspoker.
Jetzt schauen wir uns noch etwas anderes an.
Das ist eigentlich verwandt mit den Methoden, die wir als übernächstes
nehmen.
Die Kokomo-Methode.
Und zwar wird hier schon mal so hergegangen, dass man das entstehende
Produkt in Teilprodukte zerlegt und diese einzeln schätzt.
Und zwar sowohl vom Umfang her als auch vom zusätzlichen Aufwand, ob
der nominal ist oder höher ist, zurechnend ist.
Ich zeige Ihnen ein Beispiel.
Angenommen, wir unterscheiden uns Steuerprogramme, Ein- und
Ausgabeprogramme, also die, die eine Ausgabe betätigen,
Datenverwaltungsroutinen, Algorithmen.
Das wäre eine mögliche Kategorisierung, aber die Kategorisierung ist
nicht fest.
Die können Sie festlegen, so wie Sie für Ihren Betrieb oder
Softwarehaus benötigen.
Dann schaut man sich die Anzahl der Teilprodukte an, die zu jedem
dieser Kategorien gehören und multipliziert mit dem Aufwand diese
Kategorie und dann addiert man das Ganze auf.
Man nennt das auch Aufwand-pro-Einheit-Methode.
Hier wäre also ein Beispiel.
Man hat hier vier Kategorien, Steuerprogramme, Ein- und Ausgabe,
Datenverwaltung, Algorithmen.
Man schaut sich an, wie viele Teilprodukte man hat und wie umfangreich
die sind.
Also zum Beispiel hat man ein Steuerprogramm mitgeschätzt, also wieder
die Schätzung, 500 Zeilen und nachdem ein Steuerprogramm teuer ist,
aufwendig ist, kompliziert ist, gibt man einen Aufwandsfaktor von 1,8.
Dann sagt man also, das ist so gut wie 900 Zeilen normal.
Dann bei den Ein- und Ausgabe-Programmen, das haben wir drei, nämlich
einmal mit 700 Zeilen geschätzt, einmal mit 500, zweimal mit 500
Zeilen geschätzt, gibt 1.700, der Aufwandsfaktor ist auch etwas höher
als nominell, einfach nur runterschreiben kann, also gibt das aus der
1.700 Summe bewerte 2.500.
Datenverwaltung ist einmal 800, zweimal 250, insgesamt 1.300, der
Aufwandsfaktor ist hier nominell, das ist ein relativ einfaches
Programm.
Also gut, das ist gleich 1.300.
Unsere Algorithmen sind wieder kompliziert, da gibt es also sechs
Stück davon, einmal 300, einmal 5 mal 100 wären eigentlich 800, aber
da weiß man, dass man viele Fehler macht.
Daher sagen wir, das ist der doppelte Aufwand verglichen mit einem
Datenverwaltungsanwendung.
Und dann addiert man das auf und schon hat man 6.350 Zeilen Code.
Und jetzt muss man natürlich sagen, okay, und jetzt?
Jetzt muss ich das nur in Personenmonate umwandeln.
Dazu brauchen Sie auch wieder einen Aufwandsfaktor, den man auch
wieder aus der Erfahrung gewinnen kann.
Also auch hier wieder die Erfahrung, ich sagte Ihnen ja gerade mal, so
drei Zeilen Code pro Tag ist extrem wenig.
Und das hoffe ich, dass dann meistens etwas mehr herauskommt.
Aber Sie müssen bedenken, dass bei dieser geringen Zahl eben alles
eingerechnet ist.
Nicht nur das Zeilen Code, das man schreibt, sondern auch die
Vorbereitung, Planung, Definition und Entwurf und Test.
Gehört also alles dazu.
Und dann kommt letztendlich ein niedrigerer Wert raus, als man wohl
denkt, wenn man am Anfang nur vor sich hin programmiert.
Los drauf los programmiert, ohne lange Planung.
Jetzt brauchen Sie also eine umfangreiche empirische Datensammlung,
damit Sie diese Aufwandsfaktoren kennen und die Umwandlung in
Personenmonate.
Und man muss sie permanent überprüfen, ob sie noch stimmen.
Weil es sich ja mit neuen Methoden, neuen Programmiersprachen, anderen
Programmiersprachen, neuen Werkzeugen, verbesserten Werkzeugen,
verbesserten Testwerkzeugen, neue Strategien beim Testen.
Also ich kann sich der Aufwand wieder verschieben.
Aber so ist es.
Wir arbeiten hier mit Schätzungen.
Wir können hier nicht exakt sagen, auf das Personenmonat genau, wie
viel wir brauchen werden.
Okay, dann kommt als nächstes das Kokomo 2.
Kokomo 2 heißt, es gab auch ein Kokomo 1, natürlich.
Das ist jetzt sehr kompliziert.
Das ist ein typisches Berechnungsmodell.
Und das schätzt die Gesamthauer eines Softwareprojektes in
Personenmonaten.
Vorausgesetzt man hat natürlich Zahlencode.
Und hat auch so etwas wie diese zusätzlichen Aufwandsfaktoren mit
berücksichtigt.
Außerdem berücksichtigt dieses Modell, dass bei steigender Größe die
Dauer überproportional steigt.
Wenn Sie Millionen Zahlencode erfordern, ist die Produktivität
geringer, als wenn Sie nur 1.000 Zahlencode benötigen.
Und das erkläre ich Ihnen jetzt.
Da gibt es eine komplizierte Formel.
Ist aber nicht so wild.
Wir wollen also ausreichend Personenmonate.
Das ist das PM.
A ist eine Konstante für die Kalibrierung des Modells.
Es wird an allen Ecken und Enden an dem Modell kalibriert.
Aber das ist diejenige, die sagt, arbeite ich z.B.
mit Lines of Code oder arbeite ich mit sogenannten Funktionspunkten.
Funktionspunkte kennen wir nicht.
Das ist auch eine weitere Schätzmethode.
Wir würden es also zu weit führen.
Aber bei Funktionspunkten, da sagt man, man hat eine
Geschäftsanwendung und man zählt die einzelnen Funktionen und deren
Komplexität, ohne überlegen zu müssen, wie viel Zahlencode man dafür
braucht.
Und die Funktionen können also sein Verarbeitung, sie können sein
Eingabe, sie können sein Ausgabe, sie können Benutzerschnittstelle
sein oder so etwas.
Und da rächt man also Funktionspunkte aus.
Und die sind natürlich mehr wert als eine Zeile Code.
Und diese Kalibrierung steckt dann z.B.
in diesem A.
Gut.
Das nächste, das ist die Größe.
Und zwar in 1000 Zeilen Codeneinheiten.
Das müssen Sie also leider schätzen.
Kann ich jetzt z.B.
in Planungsbroker schätzen.
Oder mit den anderen Methoden, mit der Analogie-Methode, die wir
vorhin hatten.
So, und jetzt kommt ein Exponent drüber über die Größe und dieser
Exponent verursacht jetzt, dass die Anzahl Personenmonate mit der
Größe nicht linear steigt, sondern etwas überlinear, also etwas
überproportional.
Sie sehen schon, der Exponent ist 1,01 plus dieses Zeug hier, 0,01 mal
die Summen hier.
Ich erkläre gleich, was das ist.
Und am Schluss wird er auch noch mit weiteren Faktoren multipliziert.
Erkläre ich auch natürlich noch.
Also, SF, das sind die Dinger hier.
Das sind die sogenannten Skalierungsfaktoren.
Die variieren von 1 bis 5.
Es gibt 5 dieser Skalierungsfaktoren.
Ich zeige Ihnen gleich, jetzt muss ich das erste Rechnen erklären.
Es gibt 5 Stück.
Wenn ich also z.B.
den niedrigsten Wert wählen würde, dann wäre das eine 0.
Dann kommt hier eben kein Beitrag hinzu.
Wenn ich den größten Wert habe, dann kommt hier immer eine 5.
Mal 5 ist 25, aber ich nehme mal 0,01, also bleibt mir höchstens 0,25
Zusatz hier übrig.
Das heißt, diese Skalierungsfaktoren erhöhen die exponentielle
Steigung.
Aber die ist sehr schwach wegen 1,0 irgendwas.
Das waren also die sogenannten Skalierungsfaktoren.
Ich erkläre gleich, was da alles reingeht.
Und schließlich, das sind multiplizative Kostenfaktoren.
Die stehen jetzt nicht im Exponenten, sondern die wirken sich einfach
auf die Gesamtdauer aus.
Dann schauen wir mal, was diese komischen Skalierungsfaktoren sind.
Die gehen also von 0 bis 5.
Von 0 bis 5.
0 heißt kein Einfluss.
5 ist der maximale Einfluss, wohlgemerkt.
Multipliziert mal mit 0,01.
Und diese Skalierungsfaktoren sind also folgendes.
Das eine ist die Presidentedness.
Presidentedness könnte...
Ich weiß nicht so recht, wie ich das übersetzen soll.
Erfahrung damit.
Hat man diesen Typ von System schon geschrieben?
Hier drüben wäre also...
Ich bin total vertraut damit, mit dieser Anwendung.
Und hier noch nie gesehen.
Und hier drin, somewhat unprecedented.
Also ein bisschen neu.
Da gibt es eine Abstimmung von 0 bis 5.
Und die anderen gehen etwa ähnlich.
Auch immer von 0 bis 5.
Development Flexibility, die man hat.
Allgemeine Ziele bei der Flexibilität.
Und hier hat man sehr große...
Anforderungen an die Produktentwicklung.
Dann sagt man, was ist das Risiko an der Architektur?
Beziehungsweise daran, die Risiko...
die Risikoauflösung zu betreiben.
Und da sagt man...
Ist das sehr groß?
Also sind wir hier voll vertraut, dann kommt hier der Faktor 0 dazu.
Andernfalls 5.
Team Cohesion, also der Zusammenhalt des Teams.
Das ist also seamless interactions.
Wir passen alle wunderbar zusammen, verstehen uns.
Bis zu very difficult interactions, wenn das Team nicht gut
miteinander auskommt.
Dann kann man auch noch die Prozessreife mit berücksichtigen, die
Process Maturity.
Da gibt es einen CMM Capability Maturity Model, heißt das.
Einen Fragebogen, den man ausfüllen kann, um auch hier einen Wert zu
bekommen.
Und zwar die Anzahl der Antworten, Ja-Antworten.
Sehen wir natürlich auch nicht, aber Sie sehen schon, wir haben da 1,
2, 3, 4, 5 Stück.
Maximal ist es 5, also haben wir maximal den Wert 25 und minimal den
Wert 0.
Also der Skalierungsfaktor wird irgendwo zwischen 0,25 und 0
variieren.
Und kommt im Exponenten vor.
Jetzt kommen die anderen.
Das sind ziemlich viel Stück.
Da gibt es also Produktfaktoren, Plattformfaktoren, Personalfaktoren
und Projektfaktoren.
Oh Gott, das muss ich jetzt alles ausfüllen.
Es sind 17 Faktoren.
Normalerweise wird ein Nominalwert von 1 eingestellt, aber den kann
man erhöhen.
Meistens will man den nur erhöhen und nicht erniedrigen.
Zum Beispiel die Zuverlässigkeit, die Datenbankgröße, die
Produktkomplexität, die erforderte Wiederverwendbarkeit, die treibt
natürlich die Kosten hoch, die Dokumentation, die den entsprechenden
Phasen im Entwicklungszyklus angepasst sein muss, Plattformfaktoren
haben, gibt es Beschränkungen bei der Laufzeit, gibt es Probleme mit
dem Hauptspeicher, muss ich mich da sorgfältig darum kümmern, dass
nicht zu viel Hauptsparer verbraucht wird, wie schnell, Plattform
Volatility heißt natürlich, wie oft ändert sich die Plattform, auf der
ich laufe, laufen kann, und wie schnell muss die Antwortzeit sein, die
Turnaroundzeit.
Dann gibt es noch die Personalfaktoren, wie gut sind die Leute, die
ich habe, die Analystenfähigkeiten, die Programmierfähigkeiten, die
Erfahrung mit der Anwendung, die Erfahrung mit der Plattform, auf der
es laufen soll, die Erfahrung mit Sprache und Werkzeugen und
Personalkontinuity, das heißt also, bleibt das Personal dabei oder
habe ich mit einem hohen Personalwechsel zu rechnen.
Und schließlich Projektfaktoren, nehme ich moderne
Programmierpraktiken her, moderne Werkzeuge nehme ich her, muss ich
die Entwicklung an mehreren Stellen durchführen, also geografisch
verteilt, möglicherweise sogar über Kontinente hinweg, das kann also
sehr viel extra Aufwand erfordern, ist der Entwicklungszyklusplan sehr
stark komprimiert, das kennen wir schon vom Teufelsquadrat, das wird
uns auch zusätzliche Kosten verursachen und muss ich außerdem noch
eine sichere Anwendung machen, die außerdem noch klassifiziert werden
muss.
Okay, wie soll man das alles machen?
Naja, da gibt es einen Rechner dafür.
Erst schauen wir uns mal das überproportionale Wachstum an.
Also, wir schauen uns ein vereinfachtes Modell an, das ist nochmal die
Formel.
Wir nehmen jetzt folgendes an.
Wir nehmen an, A hat den Wert 3.
Ist auch egal, warum der gerade 3 ist, ist uns jetzt mal egal.
Dann sagen wir, alle Kostenfaktoren haben den Wert 1, also den
Nominalwert, das war das Produkt hier hinten.
Das sind diese Kostenfaktoren.
Dann nehmen wir an, die Skalierungsfaktoren, da schauen wir uns drei
verschiedene Fälle an.
Wir nehmen einmal an, alle haben den Wert 5.
Dann kommt der 1,01 plus 0,01 mal 25 dazu, also 1,26.
Dann nehmen wir an, wir haben einen mittleren Wert, nämlich 3 für
alle.
Da käme dann 1,16 raus und schließlich hätten alle den Wert 0.
Dann kommt eben hier ein 0 raus und wir haben als Ergebnis für das B
nur 1,01.
Damit vereinfacht sich unsere Formel.
Nämlich zu dem hier.
Dreimal die Größe hoch diesen B.
Drei verschiedene Varianten.
Also dreimal Size hoch B.
Das ist das, was rauskommt.
Wir variieren die Größe zwischen 10.000 und 200.000.
Dann schauen wir uns mal die Kurve an.
Die Kurve sieht so aus.
Schauen Sie sich erst die Kurve an.
Die Zahlen brauchen wir im Augenblick noch nicht.
Hier haben wir also, die Skalierungsfaktoren sind hoch, weil unsere
Fähigkeiten sehr flach sind.
Beziehungsweise hier sind unsere Skalierungsfaktoren niedrig, weil wir
große Fähigkeiten haben.
Zum Beispiel das System ist uns vertraut.
Die Teaminteraktionen funktionieren problemlos und so weiter.
Diese fünf Faktoren.
Sie sehen schon, es ist ein leichter Anstieg hier zu verzeichnen.
Vergleichen wir mal 205.000 Zeilencode.
Das kann man hier in der Tabelle ablesen.
205.000 Zeilencode, Einheitenpersonenmonate und hier 2648 zu 2454.
Das ist also schon mal eine Spanne von Faktor 4, der dazwischen liegen
kann.
Zwischen dem optimistischsten Wert und dem pessimistischsten Wert.
Faktor 4.
Aufgrund der exponentiellen Wachstums, wir sind noch ganz am Anfang
des exponentiellen Wachstums hier, wird der Unterschied natürlich
immer größer.
Wenn wir in die Richtung gehen, wird er kleiner.
Schauen wir uns zum Beispiel den Hunderttausender an.
Ne, haben wir den Wert nicht.
Was haben wir denn für einen Wert?
20.000.
Schauen wir uns dafür den Wert bei 20.000 Zeilencode an.
Da ist ein Verhältnis von 61 zu 130.
Das ist nur ein Faktor 2.
Okay, das haben wir also verstanden, dass diese Kurven dann
berücksichtigen, dass mit größeren Projekten die Ineffizienz schlimmer
wird.
Das ist die Erfindung von dem Barry Boehm, der das gemacht hat.
Und natürlich gibt es dazu einen Rechner.
Das ist der Kokomo 2 Rechner.
Das werden Sie jetzt wahrscheinlich nicht lesen, aber oben ist die
Webseite.
Wenn nicht, dann gehen Sie halt aufs Internet und suchen Kokomo 2.
Dann finden Sie genügend Zeugs, unter anderem diese Webseite.
Und da können Sie einfach alles eintragen, was Sie brauchen.
Im Moment steht noch gar nichts drin.
Also hier zum Beispiel können Sie antragen, wie viel Zeilencode Sie
neu brauchen.
Sie können auch sagen, wie viel davon Sie wieder benutzen können, wie
viel davon Sie modifizieren können oder ein paar andere Anteile mit
eintragen.
Also wir haben jetzt nur diesen Fall betrachtet, dass wir alle neue
Zeilen berechnen.
Das kann das also auch.
Und dann sind hier die ganzen Kostentreiber mit eingefügt.
Zum Beispiel Analyst Capability, also die Plattform, der Personal, das
Produkt.
Presidentedness, Development Flexibility, alles Zeug, was wir vorhin
hatten, die fünf Stück.
Hier stehen sie, dürfen sie dann einstellen, nominal oder schlimmer
oder besser.
Und dann kommt hier unten irgendwo, und das ist jetzt nicht mehr auf
dem Bildschirm natürlich, die Ergebnisse.
Das ist ja praktisch, oder?
Also Sie können sich die Excel-Seite Cocoboat 2 bei uns herunterladen,
da können Sie es mit einer Excel-Seite berechnen.
Brauchen Sie niemanden dazu, brauchen Sie kein Internet, gar nichts.
Ist allerdings nicht ganz so schön wie dieser Rechner hier, auf CSS,
EUSC, EDU.
Entschuldigung, das ist der hier.
Das hier ist noch mal eine Beschreibung von den Leuten, die das
gemacht haben.
Und dann gibt es natürlich noch Veröffentlichungen dazu, zum Beispiel
diesen Barry Bim, ist einer der bekanntesten Leute im Gebiet der
Software -Schätzung.
Auch das Cocoboat und Cocoboat 2 und andere Methoden entwickelt hat.
Gibt es Fragen dazu?
Wenn ich unterschiedliche Systeme verwende, kommt dann das gleiche
raus?
Sehr unwahrscheinlich.
In einem gewissen Bereich wahrscheinlich, wenn nicht, dann kann ich ja
immer sagen, haben Sie schlecht geschätzt.
Das ist wirklich eine schwierige Angelegenheit, weil man ja nicht
weiß, was die Wahrheit ist.
Dadurch kann ich nicht sagen, ist der falsch oder ist der falsch, wenn
Sie divergieren.
Aber ja, man könnte mal versuchen, Cocoboat zu vergleichen mit der
Analogie -Methode, die ich hatte.
Aber Sie sehen auch, dass das Cocoboat natürlich sehr viel mehr
berücksichtigt.
Das kann die Analogie-Methode gar nicht.
Das kann sie auch, also was es neu wiederverwendet und modifiziert.
Und das war es dann aber schon.
Wenn es also noch auf die Fähigkeiten der Entwickler eingehen würde,
das kann ich in der Analogie-Methode nicht sagen.
Darum wird da sicher etwas anderes rauskommen.
Gibt es sonst noch Fragen?
Okay.
Es gibt aber noch andere Schätzmethoden, ein paar erwähne ich noch.
Entschuldigung, zwei erwähne ich noch.
Das Planungsblock hatte ich schon erwähnt, das schauen wir uns nochmal
genauer an.
Und dann gibt es noch die sogenannte Delphi-Methode nach dem Orakel
von Delphi.
Die Delphi setzt eine Menge von Schätzern, die mit der geplanten
Software Erfahrung haben.
Und in einer oder mehreren Runden wird folgendes gemacht.
Jeder Schätzer gibt anonym einen Schätzwert plus eine Begründung dabei
ab.
Kostet uns, zwei Personenjahre oder sowas.
Der Moderator fasst das Ergebnis zusammen und sucht sich vor allen
Dingen die am weitesten entfernt liegenden Schätzungen aus.
Wenn die Werte noch weit auseinander liegen, wird eine neue Runde
gemacht, in der die Schätze ihre Schätzung ändern dürfen.
Und die Hoffnung ist, dass dann die Schätzwerte irgendwann mal zu
einem richtigen Wert konvergieren.
Man muss eben dann diskutieren, warum der eine meint, dass es sehr
lange dauert und der andere meint, es ist sehr schnell zu machen.
Und diese Diskussion führt dann meistens zu einem besseren Ergebnis
als einfach so, ich meine, das ist zwei Personenjahre und fertig.
Und wenn sich dann nichts mehr ändert, dann nimmt man einfach den
Durchschnittswert.
Was soll ich denn sonst machen?
Wichtig ist aber, dass die erste Schätzung unbeeinflusst ist von den
anderen.
Die weiteren Schätzungen nicht mehr, weil dann muss man ja
diskutieren.
Und der Planungsfokus ist einfach nur eine Variante davon.
Die Variante sieht so aus, dass alle Teile immer einen Kartenstapel
bekommen mit stark wachsenden Werten.
Zum Beispiel 0, 1,5, 1, 2, 3, 5, 8, 13, 20, 40 und dann so eine Skala
immer stärker in jeder Größenordnung wieder springen.
100 unendlich, werden wir nie fertig und Fragezeichen kann ich dich
schätzen.
Jeder Teil legt jetzt eine Karte für seine Schätzung mit der Zahl nach
unten auf, verdeckt.
In Einheit kann man sagen, was man will.
Wir schätzen das in Tagen oder in Monaten oder in Jahren oder in
Stunden, wenn Sie wollen.
Das wird vorher abgemacht und ich lege also meine Karte auf und Sie
auch und alle anderen auch und dann sagen wir okay, jetzt umdrehen und
dann schauen wir uns mal die Werte an und jetzt erfolgt die
Diskussion.
Wieso meinst du denn eigentlich, das soll jetzt 10 Jahre dauern?
Quatsch, das können wir doch viel schneller, weil wir haben diese und
jene Software schon mal geschrieben, wir können das und das
wiederverwenden und dann machst du das mit der und der Sprache und
dann bist du in einem halben Jahr fertig.
So ungefähr geht die Diskussion dann.
Die Schätzer mit den hohen und niedrigsten Werten begründen ihre
Schätzung und dann hofft man, dass man einen Konsens herstellt.
Wir wären natürlich nicht auf dieser Welt, wenn es dazu nicht auch
noch Apps gäbe, die das natürlich machen.
Wir können das mit normalen Spielkarten, die gibt es übrigens auch,
können Sie im Internet bestellen, bei Amazon, oder aber Sie haben eben
diese Bewertung, das sind die Werte, die Sie vorher auch gesehen
haben, geben Sie ein und dann werden Ihre verschiedenen Mobilgeräte
schon irgendwie zusammenarbeiten, sodass Sie die Schätzungen der
anderen zu sehen bekommen.
Wir sprechen jetzt aber hier nicht weiter.
Das ist eine ganz witzige Methode.
Und was soll ich jetzt machen?
Welche dieser Methoden soll ich denn eigentlich anwenden?
Und da gibt es so etwas, je nach Zeitpunkt und was Sie schon wissen
über die Anwendung, wenn Sie zum Beispiel schon einen Teil der
Anwendung geschrieben haben, in einem Vorprodukt, in der Forschung, in
der Vorentwicklung oder so etwas, dann wissen Sie schon etwas über die
Anwendung.
Und daran hängt davon ab, welche Schätzmethode wir nehmen.
Also für frühzeitige, grobe Schätzungen, ganz grobe Schätzungen,
können Sie natürlich den Planungsbroker nehmen oder die Analogie
-Methode.
Da haben Sie nur ganz grobe Schätzungen.
Die Relationsmethode haben wir nicht besprochen.
Die können Sie jetzt mal ignorieren, auch für die Klausur.
Sind die Einflussfaktoren während der Entwicklung schon bekannt, dann
kann ich natürlich, und ich habe eine Schätzung für die Zeilencode,
dann würde ich CoCoMo2 benutzen.
Wenn Daten im Unternehmen gesammelt werden über Schwierigkeiten, Sie
erinnern sich, ich muss Zeilencode für die einzelnen Typen von
Teilprodukten schätzen und ich weiß, was die mir kosten in Aufwand,
sowohl die Erhöhung des Aufwandsfaktors als auch die Umrechnung in
Personenmonate, dann würde ich die Multiplicator-Methode benutzen.
Die erfordert aber zum Beispiel, wenn Sie sehen, ich kann das erst
machen, wenn ich die einzelnen Kategorien kenne und deren Anzahl, zum
Beispiel eine Ausgabe Steuersoftware oder so etwas, das wiederum
bedeutet, dass ich schon einen Vorentwurf, einen Grobentwurf gemacht
haben muss, damit ich das überhaupt sagen kann.
Während hier oben CoCoMo2 und da, da gehen wir einfach nur von wilden
Schätzungen der Zeilencode aus.
Hier brauche ich ja schon eine Unterteilung.
Also ich muss einen Grobentwurf gemacht haben.
Ich muss also nicht die einzelnen Schnittstellen bestimmt haben, ich
muss mindestens wissen, was die einzelnen Komponenten sein werden in
meinem Gesamtsystem.
Genau, an der Stelle sind wir fertig.
Nur einmal zurück, wenn ich Glück habe.
Gibt es jetzt noch Fragen?
Das waren die Schätzmethoden, also keine Angst haben davor, Sie als
Informatiker.
Wir müssen halt machen, wir müssen halt etwas tun, so gut wir können,
um die Kosten vorauszusehen, denn sonst wagt sich keiner an ein großes
Projekt.
Ein kleines Projekt ist nicht so problematisch, wenn man sich
verschätzt oder so, aber bei einem großen Projekt muss man sich halt
doch Gedanken machen.
Ja, gibt es eine Frage?
Ob ich ein Beispiel für eine Firma, die CoCoMo2 benutzt, kenne.
Jetzt aus dem Stehgreif nicht, aber ich würde mal in die Literatur
schauen, die Literaturstellen anschauen, die es da gibt.
Da stehen sicher welche drin.
Also CoCoMo2 wird vielfach übersehen, dabei ist es so einfach.
Die schlimmste Schätzung ist, wenn Sie alle Skalfaktoren auf Nominal
oder 1 stellen und einfach nur Zahlen und Code eingehen, dann kriegen
Sie schon eine erste Schätzung.
Dann sagen Sie, oh, das ist aber viel zu viel.
Was ist, wenn wir da ein besonders gutes Team hätten?
Würde es sich dann verbessern?
Ist ziemlich praktisch.
Noch Fragen?
Okay.
So, jetzt kommen wir zu den Prozessmodellen.
Wir werden uns heute noch beschäftigen.
Da habe ich schon mal gesucht.
Da habe ich aber schon, oder?
Machen wir es nochmal auf.
Entschuldigung, das waren die falschen.
Die kommen erst am Schluss.
Die kommen jetzt.
Prozessmodelle, ja?
So.
Erstmal, was ist das?
Was ist eigentlich ein Prozessmodell?
Ein Prozessmodell sagt mir lediglich, wer was wann macht.
Das ist, was ein Prozessmodell sagt.
Was sind die Aufgaben?
Und in welcher Reihenfolge werden sie ausgeführt?
Von welcher Art von Personal?
Das ist einfach ein Prozessmodell.
Wie wir uns anschauen, ist Programmieren durch Probieren.
Das Wasserfallmodell, das kennen wir ja schon in- und auswendig.
Das V-Modell ist eine Variante des Wasserfallmodells.
Prototypmodell, iterative Modelle, sind nochmal Varianten vom
Wasserfallmodell.
Zu sich synchronisieren, stabilisieren.
Das ist das Microsoft-Modell.
Ich weiß nicht, ob wir heute noch dazukommen.
Und dann kommen die agilen Methoden.
Also, Programmieren durch Probieren, oder auch Code and Fix genannt,
ist, ich fange einfach mit dem Codieren an.
Und dann teste ich ein bisschen.
Und wenn es nicht stimmt, dann korrigiere ich das halt.
Das ist so, wie Sie wahrscheinlich Ihre Aufgaben bearbeiten.
Sie machen sich keine Gedanken über, was der Kunde will.
Sie haben keinen wirklich durchdachten Entwurf gemacht.
Und Sie fangen einfach zu Programmieren an.
Und ja, kann man machen.
Aber was sind die Nachteile davon?
Die Nachteile sind, das Vorgehen ist, erst ein vorläufiges Programm
erstellen, Entwurf testen und warten.
Und dann Entwurf testen, warten und überlegen.
Und dann das Programm entsprechend verbessern.
Fehler suchen.
Das hat den Vorteil, dass ich schnell einen Code habe, der vielleicht
läuft, ohne einen nutzlosen Zusatzaufwand.
Ich habe keine Dokumentation zu schreiben, muss keinen Entwurf machen,
muss mich nicht blöden Kunden rumplagen und fragen, was sie wollen.
Es geht doch so viel schneller.
Und erzeugt natürlich auch unstrukturierten Code, der nicht so wartbar
ist.
Hat keine Entwurfsphase.
Die Probleme sind natürlich, ich habe eine mangelnde
Aufgabenerfüllung, denn ich habe mir keine Gedanken darüber gemacht.
Ich dachte einfach, ich weiß das.
Warten und Pflege ist kostspielig.
Das Programm ist nicht darauf vorbereitet.
Es gab keinen Entwurf.
Es gibt keine Struktur.
Es ist wahrscheinlich Spaghetti-Code.
Der ist 23.000 Mal korrigiert worden.
Es kennt sich nur der Erfinder drin aus, wenn überhaupt noch.
Das ist alles ganz schlecht für Wartung und für Erweiterungen.
Und Dokumentation gibt es ja auch keine.
Haben wir ja keine gemacht.
Wir wollten ja schnell sein.
Und für Teamarbeit ist es noch dazu verständlich ungeeignet, denn es
gibt keinen Entwurf.
Der Entwurf war ja das, was uns erlaubte, das Problem in Teile zu
zerlegen und die Teile dann unabhängig voneinander zu bearbeiten.
Ich sehe da Beine rumwandern.
Es gab also keine Aufgabenverteilung.
Und wissen Sie, die Probleme mit dem...
Es gibt übrigens auch keine Testphase.
Ich bin halt immer am Codieren, Testen, Codieren, Testen.
Es gibt keine ordentliche Integrationsphase.
Es gibt keinen Abnahmetest.
Ich habe einfach irgendwas geschrieben, so wie am Anfang.
Und um diese Probleme zu beseitigen, hat man das Wasserfallmodell
eingeführt.
Das Wasserfallmodell hat mir gesagt, hier überlegen wir uns, was der
Kunde will, damit wir das nicht falsch machen und am Schluss
feststellen, oh, das hätte es ja gar nicht gebraucht, den Software,
den wir geschrieben haben.
Und es fehlt an allen Ecken und Enden.
Die Definitionsphase spezifiziert das Problem dann genauso, dass
andere Leute damit arbeiten können, unabhängig davon.
Wir haben einen Entwurf, der bereitet uns darauf vor, erstens auf
Parellverarbeitung und auf Arbeitsteilung und später auf die Wartung
und die Pflege des Systems, die überarbeitet werden müssen.
Und dann erst kommt die Implementierung.
Das ist das Phasenmodell.
Und dann haben wir noch einen Integrationstest, eine Phase und einen
Systemtest.
Dann gibt es im Phasenmodell natürlich auch eine Rückkopplung.
Wenn Sie in der Implementierung feststellen, dass der Entwurf verkehrt
ist, dann bessere ich den Entwurf eigentlich nach.
Allerdings gibt es im Phasenmodell keine phasenübergreifende
Rückkopplung.
Das scheint zwar darzustellen, weil immer wieder diese Pfeile sind,
aber die Wahrheit ist, wenn wir bei der Definition einen Fehler in der
Planung finden, dann wird die Planung korrigiert.
Wenn wir bei dem Entwurf einen Fehler in der Planung finden, dann ist
es blöd.
Dann müssen wir von vorn anfangen und die Definition durchlaufen und
nochmal machen.
Es ist eigentlich im Phasenmodell äußerst aufwendig, mehrere Phasen zu
überspringen.
Wenn Sie also hier hinten im Integrationstest einen Fehler in der
Planung entdecken, das ist ganz schlecht im Phasenmodell.
Dann ist alles wirklich an Arbeit schon geschehen, die Sie jetzt nicht
mehr rückgängig machen können.
Außer indem Sie im wahrsten Fall von neu starten.
Gut, die stammen also von einem Bennington von 1956 erstaunlicherweise
und wurde dann von Royce für Software nochmal überarbeitet, in diese
Phasen aufgeteilt und die Rückkopplung mit eingeführt.
Stören Sie sich nicht daran, wenn bei manchen Phasenmodellen die
Anzahl der Phasen variiert.
Zum Beispiel wird manchmal der Entwurf aufgeteilt in einen groben
Entwurf und einen feinen Entwurf.
Manche haben Planung und Definition in einer Phase.
Da gibt es Variationen des Phasenmodells.
Wichtig ist für uns, dass beim Vorgehen jede Aktivität in der
angegebenen Reihenfolge vollständig durchgeführt wird.
Es geht nicht an, dass wir die Planung halb machen und dann mit der
Definition und Entwurf und der Implementierung schon starten, ohne
dass wir die Planungsphase komplett haben.
Das ist der große Nachteil des Phasenmodells, dass die einzelnen
Phasen im Prinzip komplett abgeschlossen sein müssen, bevor wir in die
nächste Phase eintreten.
Dadurch kriegen wir Probleme mit Sachen, die wir nicht besonders gut
verstanden haben und daher nicht spezifizieren können.
Es gibt ein streng sequentielles Vorgehen und am Ende jeder dieser
Aktivität steht ein Dokument oder mehrere, die das Ergebnis dieses
Phasenmodells sind.
Daher nennt man dieses Modell auch manchmal Dokumentgetriebenes.
Die Planung muss am Schluss die vorgesehenen Planungsdokumente liefern
und der Entwurf muss die Entwurfsdokumente liefern.
Dann muss man dieses Zeug schreiben.
Was wir übrigens im PSE machen werden, also im Praktikum Software
Engineering, das im nächsten Semester auf Sie zukommt, da wird nicht
agil gearbeitet, sondern nach dem Phasenmodell.
Auch wieder aus pädagogischen Gründen, damit Sie die einzelnen
Tätigkeiten lernen.
Die Projekte sind ja nicht so groß, dass man das nicht machen könnte.
Und außerdem haben Sie Hilfe, sodass Sie tatsächlich die
Planungsphase, Definitionsphase abschließen können, bevor Sie sich in
den Entwurf stürzen.
Das ist einfach und verständlich.
Benutzerbeteiligung ist nur in der Definitionsphase gedacht,
vorgesehen, aber die Probleme sind keine phasenübergreifende
Rückkopplung, Parallelisierungspotenzial möglicherweise nicht
ausgeschöpft, weil Leute warten, dass sie mit der Planung und der
Definition fertig sind und die dürfen nichts machen.
Dürfen also nicht schon einen Teil des Systems schon mal vorentwerfen
und sofort mit der Implementierung beginnen, bis sich die anderen
Sachen klären.
Wenn ich eine gute Aufteilung habe, dann wäre das möglich, aber das
Phasenmodell sieht das einfach nicht vor.
Und es zwingt dadurch auch zur Spezifikation der Definitionsphase, da
muss ich ja sogar Benutzerschnittstellen schon angeben, skizzieren,
auch schlecht verstandene Benutzerschnittstellen und Funktionen, die
ich nicht gut verstanden habe, die muss ich jetzt exakt spezifizieren.
Wenn es besser wäre, einen Prototyp zu schreiben und zu sagen, ach so
geht das ja oder so funktioniert es ja gar nicht oder das will der
Benutzer nicht oder das muss ich umstellen oder erst muss ich das
angeben, bevor ich das überhaupt abfragen darf und so fort.
Und das führt eben dann oftmals zu auf dem Papier fertig
spezifizierten Zeug, das aber nicht stimmt und das muss ich dann schön
brav entwerfen, implementieren, testen und dann erst stelle ich fest,
das ist ja gar nicht, was der Benutzer wollte.
Also habe ich nutzlosen Code und Arbeit geleistet.
Daher benutze ich natürlich auch in unserer Vorlesung als auch im PSE
eher das als pädagogisches Modell, sodass wir die verschiedenen
Tätigkeiten kennenlernen.
Es wäre schlecht vom Lehren und Lernen Standpunkt, wenn Sie Planung
und Definition ohne Turf und auch gleich die Implementierung und den
Test dazu alles immer auf einmal machen müssten.
Wir werden später andere Gliederungen sehen, wo das dann besser
funktioniert.
Leider ist das Code und Fix noch sehr üblich.
So, dem Namen nach gibt es jetzt noch eine Variante, über die Sie
wenigstens ein bisschen Bescheid wissen müssen.
Das ist das V-Modell 97 und es gibt auch ein neueres V-Modell.
Manche denken, das kommt von diesem V hier.
Die Benennung, das stimmt aber nicht.
Das V kommt eigentlich von Vorgehensmodell oder Prozessmodell.
Wir sehen also hier auch eigentlich ein Phasenmodell, eine
Anforderungsdefinition.
Wir hatten dafür Planung und Definitionsphase gehabt.
Das ist hier zum Beispiel zusammengefasst.
Dann ist der Turf aufgegliedert in grob und feine Turf.
Dann gibt es die Modulimplementierung und zugehörig der Modultest.
Und so wird es in dieser schönen Struktur angezeigt, dass jede Phase
hier drüben eine weitere Phase des Überprüfens hat.
Und ich sage also, Modulimplementierung wird natürlich im Modultest
oder im Unitest geprüft.
Der feine Turf wird im Integrationstest geprüft, denn da prüfe ich das
Zusammenspiel.
Sie erinnern sich, Integration war Zusammenspiel der Module oder
Klassen oder Pakete.
Und der grobe Turf sind das Systemtests.
Da ist die Gesamtstruktur getestet und schließlich der Abnahmetest
überprüft die Anforderungen.
Und da sehen Sie natürlich auch, wie im normalen PaaS-Modell auch,
diese Abprüfung im Abnahmetest ist erst ganz am Schluss.
Und wenn wir hier etwas falsch definiert haben, haben wir ein Problem,
denn das merken wir erst ganz am Schluss.
Darum brauchen wir andere Methoden oder Kompensationen dafür, dass wir
in den Anforderungsdefinitionen manchmal einfach nicht alles wissen
können über das, was der Kunde will, wie die interne Struktur aussieht
oder wie die Benutzerschnittstelle aussieht.
Oder ob ein bestimmter Algorithmus überhaupt funktioniert.
Und dazu gibt es dann später die Prototypmodelle und die iterativen
Modelle, die diesen Nachteil ausgleichen.
So weit, so gut.
Jetzt gibt es auch noch das XP-Modell XT.
Das ist also eine Flexibilisierung dieses Vorgehensmodells, das wir
gerade gesehen haben.
Da können Sie eigentlich alles definieren.
Sie können sich einen neuen eigenen Prozess definieren.
Auch einen, der Hardwareentwicklung mit einschließt, wenn Sie wollen.
Werden wir aber nicht im Einzelnen besprechen.
Ich möchte nur, dass Sie es wissen.
Der Standard dafür ist über 500 Zeiten lang.
Möglicherweise ist er inzwischen gewachsen, weil er verbessert werden
ist.
Wenn Sie jemals in einer Firma arbeiten, die für die Regierung
Software entwickelt, dann werden Sie nach diesem Modell noch vorgehen
müssen, denn das wird die Regierung vorschreiben.
Und dann müssen Sie die 500 Seiten lesen.
Aber das machen wir jetzt in dieser Vorlesung nicht.
Ich gebe nur einen kleinen Ausblick.
Es gibt also Aktivitäten, Produkte und Verantwortlichkeiten.
Aber keine feste Phasenreihenfolge.
Diese Phasenreihenfolge können Sie selbst bestimmen.
Sie können also jeden Prozess in der Reihenfolge anordnen, wie Sie
wollen.
Oder wie es am geeignetsten ist für das, was Sie haben.
Eine Aktivität, also eine Tätigkeit, die genau beschrieben werden
kann, zum Beispiel implementieren oder definieren oder entwerfen oder
testen oder integrieren oder System testen und so fort.
Das können wir also alles beschreiben.
Produkt ist das Ergebnis einer Aktivität.
Ich kann selbstverständlich im V-Modell XT das ganz normale
Wasserfallmodell definieren.
Sie sehen schon, die Aktivitäten sind die einzelnen Phasen und die
Produkte sind das Ergebnis, das aus der Phase herauskommt, die in die
nächste übergeben wird.
Insofern passt das.
Das Projekt wird auch noch aus verschiedenen Perspektiven und Rollen
beschrieben.
Auf das gehe ich jetzt nicht weiter ein.
Aber was noch wichtig ist, dass jedes Produkt vier Zustände hat.
Nämlich in Planung, das ist das erste, in Bearbeitung, vorgelegt und
fertiggestellt.
Schauen wir uns mal diesen Automaten an.
Das ist ein Zustandsautomat, das wissen wir schon.
Wir sind Informatiker, das können wir gut lesen.
Die erste Version des Produktes wird erstellt.
Da gebe ich von Inplanung in die Inbearbeitung.
Da werde ich wohl die meiste Zeit in diesem Zustand in Bearbeitung
verbringen.
Dann erfolgt eine Prüfung durch eine eigenständige Qualitätssicherung
und die Konsistenz ist geprüft.
Dann geht es in den Zustand vorgelegt.
Vorgelegt heißt noch nicht endgeprüft.
Und schließlich noch ein Überprüfungsschritt am Schluss.
Das Produkt ist formal und inhaltlich korrekt.
Dann ist es fertiggestellt.
In der Regel wird das nicht so geradlinig gehen.
Das heißt, es gibt da Abkürzungen und Rücksprünge.
Also wenn die Prüfung durch die Qualitätssicherung nicht erfolgreich
war, dann gehe ich zurück in die Bearbeitung.
Andernfalls gehe ich in den Fertigstellen.
Also in diesem Schritt hier, wenn ich bereits vorgelegt bin, dann ist
es einfach nur noch ein Überprüfen, ob die Prüfungen alle durchgeführt
wurden und erfolgreich waren.
Also vollständig inhaltlich und formal korrekt.
Ich kann natürlich in der blöden Situation sein, dass ich zwar schon
fertiggestellt habe, aber was vergessen.
Oder was doch Mist gebaut.
Dann gibt es eine erneute Bearbeitung des Produktes, was heißt, es
geht zurück in Bearbeitung.
Und schließlich gibt es dann hier noch eine Abkürzung.
Fertiggestellt in Bearbeitung und fertiggestellt, wenn keine Prüfung
durch eine Qualitätssicherungsinstanz notwendig ist, aber Konsistenz
geprüft und das Produkt inhaltlich und formal korrekt ist.
Also das könnte ich zum Beispiel in einem Prozess definieren, in dem
ich Inspektionen durchführe.
Inspektionen haben wir gehört, also ein Kompliment zum Test, der sehr
früh eingesetzt werden kann.
Und da kann ich natürlich sagen,
die Prüfung, die hier durchgeführt wird in der Qualitätssicherung, ist
eine Inspektion.
Mit vorgeschriebenen Inspektionslisten.
Das kann ich also mit diesen Produktzuständen machen, dass ich die
Übergänge von einem Zustand in den nächsten genau sage, was da zu tun
ist.
Kann ich mit bestimmter Klasse von Produkt machen, zum Beispiel
implementieren, kann ich natürlich auch mit den Türfen oder
Spezifikationen machen.
Das ist eigentlich alles, was ich zum XT-Modell sagen will.
Ich hatte früher noch mehr Material dazu, aber ich fand das nicht
besonders erhellend, wenn man es eigentlich nicht machen muss.
Wenn man es machen muss, dann schaut man sich das genau an und dann
sagt man, so ist das gedacht.
Jetzt wissen Sie von mir, dass es das V-Modell XT gibt, wird für
Regierungsarbeiten benötigt
und da gibt es Aktivitäten.
Das sind eigentlich die Prozesse, die man durchführt, die Schritte und
es gibt Produkte und Leute, die es machen, rollen.
Gibt es Fragen zum V-Modell XT?
Vorgehensmodell XT?
Bitteschön.
Das weiß ich jetzt nicht, wer die Marke hat, wer die Marke besitzt.
Ich denke nicht die Bundesregierung, sondern wahrscheinlich eine Firma
in München, die von der TU München entwickelt wurde.
Ja, bitte.
Das habe ich jetzt akustisch nicht verstanden.
Zum Normalfachmodell.
Ja, okay, ich gehe eins zurück.
Moment, machen wir gleich.
Noch eins, jawohl.
Hier.
Ach so, nein, nein, nein, man macht die Tests nicht gleichzeitig, sie
werden erst hier durchgeführt, aber sie werden beschrieben.
Ja, genau, da haben Sie recht.
Also hier beschreibe ich zum Beispiel, welche Anforderungstests
später, Abnahmetests später durchgeführt werden müssen und führe es
dann im Abnahmetest durch.
Also die Planung ist auf der Seite und die Durchführung auf der
rechten Seite.
Ja, sehr gute Frage, das hatte ich nicht klar gesagt.
Danke.
Weitere Fragen?
Okay, dann gehen wir...
Heute Morgen war da noch voll.
So, das haben wir da.
Jetzt kommt das Prototypmodell.
Also Prototyp ist, wenn Sie keine vollständige Spezifikation geben
können, genau für den Fall.
Sie wissen nicht, ob ein bestimmter Algorithmus schnell genug läuft.
Vielleicht müssen Sie dann einen anderen wählen.
Sie wissen nicht, was die grafische Benutzoberfläche zeigen soll.
Also bauen Sie mal eine und arbeiten mit ihr ein bisschen, um zu
sehen, ob sie so stimmt.
Sie müssen also erstmal explorativ etwas ein bisschen entwickeln und
dann sagen, jetzt wissen wir, wie es geht, jetzt können wir
spezifizieren und dann gehen wir über in den ganz normalen
Phasenmodell.
Das ist also die Kompensation dafür, dass ich nicht alles komplett
spezifizieren kann im Phasenmodell, Wasserfallmodell.
Der Prototyp kann außerdem die Zusammenarbeit und die Zusammenarbeit
mit dem Kunden verbessern und das Vertrauen des Kunden in die
Entwicklungsabteilung erhöhen.
Und ein berühmtes Zitat heißt If you plan to throw one away, you will
anyhow.
Das ist ein bestimmter Fred Brocks, der das erste große Betriebssystem
für IBM geschrieben hat, das OS 360, und ein Buch geschrieben hat, das
The Mythical Man-Month bedeutet.
Das heißt, es ist ein Klassiker, der ist schon uralt, stammt aus den
70er Jahren, wenn ich mich täusche, war es immer noch toll zu lesen.
Also der hat zum Beispiel auch schon gesagt, er sagt zum Beispiel so
etwas wie Adding people to a late project makes it later.
Also zu einem verspäteten Projekt nochmal Leute hinzuzufügen,
verspätet es noch mehr, denn die Leute müssen erst eingearbeitet
werden und erklärt werden, was alles schon gesehen ist, bis sie
überhaupt produktiv werden können, zum Beispiel.
Und er hat nichts von einem Prototyp gesagt, sondern er sagt, wenn du
ein großes System schreibst, plan daran, dass du eins wegwerfen wirst,
die erste Version wegwerfen wirst, das wird bestimmt passieren.
Und das ist eigentlich so etwas, was man im Prototyp-Modell macht.
Also Prototyp ist gedacht dafür, dass das wirklich nicht ein
flugfähiger Prototyp ist, sondern einen, den ich benutze, um meine
Spezifikation zu schärfen und den plane ich also auch wegzuwerfen.
Wie läuft das also jetzt ab?
Was wir brauchen, ist Klärung wichtiger Fragen oder Unsicherheiten.
Die muss ich natürlich erkennen können.
Dazu mache ich eine vorläufige Systemanalyse, einen Prototyp-Entwurf
und Implementierung und dann meistens eine Vorführung.
Also z.B.
für die Benutzeroberfläche würde ich eine Vorführung machen.
Wenn ich das so und so und so mache, mit diesen drei Fenstern und
diesen 28 Webseiten, ist das so, wie Sie gedacht haben?
Nein, nein, nein, das ist viel zu umständlich, das muss anders gehen.
Okay, wie denn?
Und dann versuchen Sie das eben hinzukriegen, dass es praktisch ist
für den Benutzer, so wie er es in seinem Arbeitsablauf am besten
brauchen kann.
Nach der Vorführung haben Sie wahrscheinlich ein bisschen Nacharbeit
zu leisten, aber dann können Sie spezifizieren und mit diesem
Erkenntnis gehen Sie dann über in den ganz normalen Wasserfall.
So ist das gedacht.
Prototyp oben drüber, wichtige Unsicherheiten klären.
Wohlgemerkt, Sie können ja sagen, im Wasserfall ist das
Prototypisieren einfach noch mal eine Phase, die da vorgestellt ist,
die Analyse hat, die ein Turf hat und eine Implementierung und eine
Vorführung.
So können Sie das sehen.
Das ist also eine Strukturierung.
Dann gibt es das iterative Modell.
Das iterative Modell ist wahrscheinlich dasjenige, was am besten
funktioniert.
Das iterative Modell liegt zum Beispiel auch XP zugrunde und es liegt
dem Microsoft-Modell zugrunde und es liegt Scrum zugrunde.
Das iterative Modell sagt einfach, ich baue das System nicht als
Ganzes, sondern ich baue es in mehreren Iterationen.
Ich füge also zu einer ersten Version weitere Funktionalität hinzu,
überprüfe die erneut, füge ein drittes oder ein viertes Inkrement
hinzu.
Das ist es, was das iterative Modell macht.
Da sagt man zumindest, Teile davon lassen sich schon mal spezifizieren
und die baue ich und realisieren.
Wird also Produkt, Schritt für Schritt werden neue Funktionalitäten
hinzugefügt, hat jetzt die gleichen Vorteile wie Einsatzgebiete wie
das Prototyp-Modell.
Wenn ich etwas nicht weiß, dann mache ich es als erstes.
Erledige das, habt die Unsicherheit erklärt und kann weitermachen.
Es wäre blöd, das, was unsicher ist, erst am Schluss zu machen.
Denn dann habe ich schon möglicherweise viel Falsches gebaut, das
jetzt natürlich mit diesem Unbekannten nicht mehr zusammenpasst, wenn
es geändert werden muss.
Und man versucht, im iterativen Modell eben nichts wegzuwerfen,
sondern möglichst viel weiter zu verwenden.
Da gibt es jetzt zwei verschiedene Ansätze, diese Iterationen zu
planen und durchzuführen.
Das eine ist das sogenannte evolutionäre Modell und das andere ist das
inkrementelle Modell.
Ich zeige Ihnen das am besten am Bild, dann verstehen Sie das besser.
Nehmen wir mal an, das ist unser ganz normaler Wasserfall-Modell, das
Bild kennen wir schon gut.
Und es ist so, dass Sie jetzt hier hinten in den Betrieb gehen können,
wenn das System in der ersten Iteration gut genug ist.
Aber Sie haben meistens dann eine Evaluierung und wenn Sie nicht
zufrieden sind, nicht fertig sind oder nicht zufrieden sind, dann
gehen Sie zurück in die Entwurfsphase.
Das heißt aber, dass Sie Planung und Definition für alle Iterationen
als erstes gemacht haben.
Also Sie haben bereits alle drei oder vier Versionen des Systems und
Iterationen, wie wir das nennen, schon vorausgeplant.
Das heißt, Sie müssen, ist hier alles schon definiert, Sie müssen es
nur noch machen.
Das heißt, Sie gehen dann in den Entwurf.
Das muss aber nicht so sein, ich könnte auch in die Planung
zurückgehen und sagen, ich mache auch die Planung inkrementell.
Eine inkrementelle Planung heißt dann das sogenannte Evolutionäre
Modell.
Ich plane ein Stück, entwerfe, implementiere, teste, führe vor,
bewerte und gehe dann zurück in die Planung für das nächste Inkrement.
So machen es hauptsächlich die agilen Methoden, die sagen, wir machen
nur, planen nur das, was wir als nächstes machen und nicht mehr.
Und selbstverständlich gibt es dann auch noch den hier, dass Sie hier
in die Definitionsphase eingreifen und die Planung nicht mehr geändert
wird.
Aber wichtig ist, dass beim inkrementellen Vorgehen die einzelnen
Versionen fertig durchgeplant sind.
So, jetzt gehen wir zurück zu meiner Schreibung.
Manchmal geht es, manchmal geht es nicht.
Evolutionär, Phase und Analysieren nur den Teil, der als nächstes
hinzugeführt wird.
Das ist also gewissermaßen ein x-faches Wasserfallmodell.
Das kann natürlich sein, dass der nächste Teil aufgrund der
strukturellen Schwierigkeiten sich nicht mehr anpassen lässt.
Das heißt, ich muss dann nochmal extra Arbeit machen.
Dafür hat man jetzt in den agilen Methoden ein neues Wort entdeckt,
das heißt Refactoring.
Das heißt also, gut, wenn das nicht passt, dann müssen wir halt
refactoren oder neu umstrukturieren.
Das ist eine anerkannte Aufgabe, die müssen wir halt dann durchführen.
Damit müssen wir rechnen.
Inkrementell ist Plane und Analyse alles und nur iteriere dann einmal.
Sie analysieren also Plane und analysieren alle N-Iterationen und
führen sie dann nur noch durch.
Und das erfordert wieder mal eine vollständige Analyse und Planung,
was ich einfach eigentlich in diesem Modell verhindern wollte.
Daher ist wohl das Evolutionäre besser.
Weil es auch auf Änderungen, die spät kommen, noch reagieren kann.
Das kann zum Beispiel das inkrementelle Modell nicht mehr.
Wenn ich zum Beispiel einen Konkurrenten habe, der mit einer neuen
Funktionalität daherkommt, ich habe schon alles durchgeplant, dann
stehe ich ein bisschen blöd da, denn ich kann das nicht mehr einfügen.
Evolutionäre Modelle können das.
Ja, jetzt hatte ich da kurz eine Hand gesehen.
Hat sich das erledigt?
Keine Meldung?
Okay.
Gut.
Also, das haben wir jetzt gesehen.
Das haben wir als Prototyp-Modell gesehen.
Und das Sprungziel hängt, wie gesagt, davon ab, ob ich evolutionär
oder inkrementell arbeite.
Als nächstes kommt das synchronisierende und stabilisierende Modell
oder auch das Microsoft-Modell.
Das wurde in einem Buch veröffentlicht, das hatte den reißerischen
Titel Microsoft Secrets.
Das ist ein richtig dicker Wälzer und das ist die Essenz daraus.
Diesen 500 Seiten Wälzer handeln wir jetzt in ein paar Folien ab.
Also, die Idee ist, organisiere eine große Anzahl von Programmierern,
sagen wir 200, für ein riesiges Projekt, das war z.B.
Windows 95, Windows 98 und später dann XP.
Ich weiß nicht, wie es heute gemacht wird.
Microsoft ist so groß, dass man sicher alles findet.
Aber man möchte also kleine Hacker-Teams zulassen und eine Freiheit
für die eigenen Ideen und Entwürfe zugestehen und das trotzdem
irgendwie organisiert bekommen.
Das machen wir so, dass wir täglich oder nächtlich synchronisieren.
Das heißt, nächtlich wird das Gesamtsystem zusammengebaut, übersetzt,
zusammengebaut und getestet.
Das nennen sie synchronisieren nächtlich, am nächsten Morgen weiß man
dann, welche Fehler aufgetreten sind.
Wir stabilisieren regelmäßig.
Es gibt also Meilensteine ungefähr alle 3 Monate und eigentlich geht
mein Ding hier zum Verrücktwerden.
Liegt vielleicht von meinem Standort weg.
Und es gibt 3 Phasen.
Es gibt immer Phasen.
Eine Planungsphase, dann eine Entwicklungsphase.
Die Entwicklungsphase ist in 3 verschiedenen Stufen 2 Subphasen oder
Subprojekten organisiert, so muss ich sagen.
Und es ist eine Stabilisierungsphase, da werden Fehler gesucht und
gefunden und beseitigt.
Ich bleibe besser gleich hier.
Okay.
Das ist die Grundidee.
Ich zeige Ihnen ein kleines Bildchen, damit das deutlicher wird.
Also hier oben ist diese Planungsphase, die soll also 3 bis 12 Monate
dauern.
Dann kommt ja die Entwicklungsphase, das sind 3 Stufen.
Da gibt es also 3 Meilensteine, Meilensteine 1, 2 und 3.
Das ist auf der nächsten Folie, das sind also Entwicklungsphasen hier.
Entwicklungsschritte.
Und die schauen also etwa so genau aus.
Da kommen wir gleich dazu.
Dann schauen wir uns als erstes die Planungsphase an.
Da gibt es zum Beispiel...
der Project Plan Approval, das ist das Ende der Planungsphase.
Dauert, wie gesagt, zwischen 3 Monaten und 12 und einem Jahr.
Das ist ungefähr die Größenordnung.
Begonnen wird mit einem Vision Statement, einer Vorstellung des
zukünftigen Systems.
Das ist ziemlich kurz, wenige Seiten.
Dann soll ein Spezifikationsdokument daraus werden, das ist dann etwas
umfangreicher.
Das wird in einem Specification Review untersucht, geprüft, ob es
vollständig ist.
Man merkt, aha, die machen Inspektionen.
In der Tat, machen Inspektionen oder Reviews hier eigentlich.
Dann soll es in der Planungsphase bereits erst die Prototypen geben.
Aha, die Prototypen gibt es da auch noch.
Die Erkenntnisse fließen eigentlich schon alle mit ein.
Das sieht man ganz deutlich.
Für Unsicherheiten.
Dann soll es Design Feasibility Studies geben.
Das heißt, kann ich überhaupt etwas erreichen?
Kann ich überhaupt eine Lösung dafür finden?
Oder wie müsste die Lösung denn aussehen?
Dann gibt es eine Teststrategie, die festgelegt wird und schließlich
ein Project Review.
Achso, den Plan gibt es natürlich auch noch.
Ist aber, wie soll ich sagen, im Gegensatz zum Phasenmodell, wo ich ja
auch die Planungs- und Definitionsphase habe, nicht so ausführlich.
Da gibt es keine so riesen Dokumente, die alles bis ins kleinste
Detail festlegen.
Sondern da gibt es mehr so eine Vorstellung davon.
Was hätte ich denn gerne von einem Excel?
Von einer Tabellenkalkulation, was muss das alles können?
Und dann gibt es Prototypen.
Ist das überhaupt schnell genug?
Kann ich überhaupt im Gegenwärtigen...
Das war übrigens nicht klar.
Heute nimmt man an, das funktioniert ja alles so wunderbar.
Ich fahre mit der Maus herum und alles mögliche flackert und leuchtet
auf und wird aktiv und wieder deaktiviert.
Das hat am Anfang nicht so toll funktioniert, weil die Rechner einfach
nicht schnell genug waren, die grafischen Benutzeroberflächen
durchzusteuern auf diese Art und Weise.
Das ist schon ein großer Fortschritt geworden.
Dann gibt es einen Implementierungsplan.
Und dann gehen wir in die Implementierung.
Die Implementierung ist jetzt diese drei Phasen.
Ich sage immer Phasen dazu.
Das ist eigentlich nicht so ganz richtig.
Wir hatten ein Subprojekt, dem wird es eigentlich immer genannt.
In drei Stufen.
Dann fragt man sich, wie drei Stufen?
Das ist wie beim iterativen Modell.
Ich habe die ersten, die wichtigsten Funktionalitäten.
Die werden hier durchgeführt.
Dann kommen die nächstwichtigsten Funktionalitäten und anschließend
die schönen Sachen, die Abrundungen am Schluss.
Die werden hinzugefügt.
Natürlich auch ganz nützlich.
Ich habe dann möglichst schon ein funktionierendes System an dieser
Stelle.
Wenn ich die wichtigsten Funktionen bereits habe, dann kann ich schon
etwas damit anfangen.
Und das werden wir auch wiederfinden im Scrum-Modell, als auch im XP
-Modell.
Die Idee ist, nach jeder Entwicklungsstufe, das heißt, die haben dann
andere Namen, die heißen dann Sprint oder sowas, dass dann ein
funktionsfähiges System entsteht.
Des Weiteren ist wichtig bei diesen drei Phasen, dass ich neue
Funktionalitäten natürlich hier an diesen Stellen einfügen kann.
Das steht jetzt nicht einzeln auf den Folien, aber von den Browser
-Wars wissen Sie wahrscheinlich nichts mehr.
Haben Sie einen Film gesehen, Browser-Wars vielleicht?
Hat den jemand gesehen?
Also es ging darum, dass in der Mitte der 90er-Jahre eine Firma gab,
die heißt Netscape, die hat den ersten Internetbrowser entwickelt.
Und das hat Microsoft lange verschlafen.
Aber dann war Microsoft drauf und hat dann eine Aufholjagd gestartet.
Und dann gab es also wirklich so eine Phase, wo sowohl Netscape als
auch Microsoft irgendeine neue Funktionalität eingeführt haben.
Das wurde dann in der Presse besprochen.
Das war alles furchtbar wichtig.
Manchmal so trivial, dass man sagt, ich kann jetzt zum Beispiel eine
der Verbesserungen war, ich kann jetzt eine Internet- oder WWW-Adresse
direkt an jemand anderen verschicken.
So toll ist das auch wieder nicht.
Aber es ging eben um all diese Funktionalitäten und da wurde wirklich
mit harten Bandagen gespielt.
Die härteste Bandage war natürlich, dass Netscape Geld gekostet hat
und Microsoft hat seinen als Teil des Betriebssystems vertrieben, also
für nichts, für umme.
Und das hat letztendlich Netscape trotz immer wieder technisch
Vorreiter zu sein, das Genick gebrochen.
Das war das Ergebnis der Browser Wars.
Und da war es tatsächlich so, dass einfach neue Funktionalität erdacht
wurde und Microsoft musste meistens hinten nachziehen.
Und das geht gerade in so einem Modell ziemlich gut, wo ich sage, ich
habe hier ein lieferbares System, das ist der Internet Explorer, der
wird jetzt geliefert und ein paar Wochen später gibt es eine neue
Version, die hat jetzt noch diese Funktionalität hinzu, die Netscape
schon längst hatte.
So ist das gedacht, dass ich auch neue Funktionalität hinzufügen kann.
Wie sieht so eine Phase aus?
Es sieht so aus, dass ich also sechs, zehn Wochen habe, da wird
gehackt.
Da wird einfach, sagen wir es ganz offen, hier wird gehackt.
Man hat eine Vorstellung, was gemacht werden muss und das machen wir
jetzt einfach.
Also entwickeln, testen und stabilisieren.
Dann gibt es zwei bis fünf Wochen Integration, Integrationstest, jetzt
wird alles zusammengefügt und wieder getestet.
Und dann haben wir noch eine Pufferzeit von zwei bis fünf Wochen,
sodass wir, falls wir einen ganz großartigen Mist gemacht haben, den
noch ausbessern können.
Ja, so ist die Idee.
Immer wieder stabilisieren hier drin, zwischendrin nächtlich natürlich
fertig integrieren, aber am Schluss dann diese Integrationsphase, wo
diese Fehler, die erst in der Integration auftauchen, beseitigt
werden.
Noch etwas, was man hinzufügen muss, bei diesem Modell gibt es genauso
viele Tester wie Entwickler.
Jeder Entwickler hat gewissermaßen seinen eigenen Tester.
Entwickler und Tester sind umgleich viele Leute.
Da wird ein sehr hoher Wert gelegt, bei Microsoft jedenfalls in diesem
Modell, auf das Testen.
So, gut, dann können wir das noch durchgehen.
Diese Milestones werden dann erledigt.
Hier ist also die dritte Phase passiert, das dritte Subprojekt an der
Stelle fertig.
Und jetzt kommt nochmal eine Stabilisierungsphase, das ist die hier.
Das sind insgesamt fünf Phasen.
Eins, zwei, drei, fünf Stück.
Was passiert dann?
Da wird noch optimiert und Probleme gesucht.
Da kommt zuerst mal ein Visual Freeze, das heißt, die
Benutzeroberfläche wird festgehalten, die wird jetzt eingefroren und
die bleibt jetzt so.
Und dann gibt es Feature Complete, da werden also auch noch die
letzten Funktionen implementiert und fertiggestellt.
Und schließlich kommt der Punkt Code Complete.
Der Punkt heißt, jetzt beginnt das interne Testen des Gesamtsystems
und das externe Testen danach, das sind also die Alpha- und die Beta
-Tests.
Das ist normalerweise der Begriff dafür.
Beta heißt, ich suche mir Organisationen oder auch Freiwillige, die
mein System testen und die freuen sich, die neueste Software von mir
zu haben und die schenken mir ihre Zeit, indem sie mein System auf
Fehler untersuchen und mir die dann checken, sodass ich sie
korrigieren kann.
Auch da war Microsoft führend, sich über externe Tester Zeit und Geld
zu sparen.
Und am Schluss kommt die sogenannte Zero-Bug-Release.
Zero-Bug, wer es glaubt, aber so heißt es.
Release to Manufacturing heißt, zu dem Zeitpunkt hat man noch weniger
über Internet verteilt, sondern hat man eben diese Kisten gemacht und
CDs gebrannt und Handbücher gedruckt und in Plastik eingewickelt und
jetzt liefert man natürlich alles über das Internet.
Aber da muss ich natürlich auch eine Vorbereitung treffen, damit das
geht.
Das funktioniert als das Synchronisieren und Stabilisieren effektiv
durch kurze Produktzyklen, Projizierung nach Funktionen, das heißt,
ich mache erst die wichtigsten zuerst, dann die zweitwichtigsten, den
drittwichtigsten und kann jederzeit neue Funktionalität einführen.
Natürliche Modularisierung nach diesen Funktionen habe ich, ich kann
weitermachen auch ohne vollständige Spezifikation, unser großes
Problem beim Wasserfall.
Viele Entwickler arbeiten in kleinen Teams zusammen und damit genauso
effektiv wie wenige und Rückmeldungen können frühzeitig Wettbewerber,
Wettbewerbsfunktionen können jederzeit eingefügt werden.
Es gibt natürlich auch ein Kontra.
Das Kontra sagt,
ungeeignet für manche Art von Software, also für Software, die
Architekturprobleme aufweisen kann, wo die Architektur sehr wichtig
ist, wo ich, dieses Verfahren führt auch zu mangelhafter
Fehlertoleranz und bei Echtzeitfähigkeit ist es auch nicht möglich.
Haben Sie diesen berühmten Film mit Bill Gates von Windows 98 schon
gesehen?
Eine Vorführung von Windows 98?
Wer hat das gesehen?
Suchen Sie es mal auf dem Internet Windows 98 Bill Gates führt es also
vor und das System bricht in der Vorführung ab.
Also stürzt ab, das gesamte Betriebssystem schaltet sich aus.
Blaue Blue Screen am Schluss.
Ja, das ist mangelhafte Fehlertoleranz, Architekturprobleme durch
diese mangelhafte Kooperation zwischen den einzelnen Teams entsteht
das.
Es sind Ad-Hoc-Prozesse in jedem Team, da ist leider nichts
vorgeschrieben.
Also im Team selbst, jedes Team kann machen, was es will.
Sie haben ja gesehen, dass wir zwar Reviews vorgeschrieben haben, aber
nur in der Planungsphase, nicht in der Entwicklungsphase.
Und es hat sich dann herausgestellt, dass innerhalb von 18 Monaten 50%
des Kodens überarbeitet werden musste.
Das ist ziemlich viel.
In eineinhalb Jahren die Hälfte der Software neu schreiben oder
überarbeiten ist problematisch.
Das ist ein großer Aufwand.
Und hängt eben damit zusammen, dass es sonst in den Entwicklungsphasen
eigentlich keine weiteren Regeln mehr gibt.
Da können Sie natürlich viel dazu lesen.
Das...
Moment...
Microsoft Secrets, ich glaube so heißt das, das ist der Untertitel
Microsoft Secrets.
Das ist das Buch dazu.
Gibt es Fragen dazu?
Also wir haben jetzt gesehen Code & Fix
Phasenmodell, Prototypmodell wir haben das iterative Modell mit zwei
Varianten gesehen iteratives Modell und jetzt haben wir Synchronize &
Stabilize.
Sie sehen schon, dass die Modelle besser werden, in gewisser Weise
voneinander gelernt haben.
Und die sage ich mal zur Zeit üblichen Modelle sind aber andere.
Das sind XP für Extreme Programming und Scrum.
Und das zeige ich Ihnen als nächstes.
Da haben wir heute sogar noch eine Viertelstunde Zeit dafür.
Das ist gut, denn am Freitag müssen wir auch noch etwas anderes
machen, nämlich eine Preisverleihung für den Paralysierungswettbewerb.
Gut, also agile Prozesse
agil wie leicht, physisch, schnell und da gibt es ein agiles Manifest
eine Gegenreaktion zu den plangetriebenen Prozessen, insbesondere dem
Wasserfall.
Sie müssen sich jetzt in folgende Situation stecken.
Stellen des Microsoft Modell ist noch nicht so richtig bekannt, aber
das was man permanent predigt in allen Schulungen, Universitäten als
auch in der Industrie ist das Wasserfallmodell mit Prototyp davor und
so weiter.
Und Sie wissen, dass das Zeug dokumentgetrieben ist.
Man muss jede Menge an Dokumenten machen, mehr noch als wir besprochen
haben, weil man sagt, da gibt es ein Problem, da erfinden wir noch
einen weiteren Überprüfungsschritt dazu und dieser Überprüfungsschritt
wird natürlich aufgrund eines Dokumentes gemacht.
Das heißt, ich muss immer noch mehr in diesen Planungsprozess
hineinpacken, noch mehr Dokumente beschreiben und irgendwann mal wurde
das den Entwicklern zu viel.
Das ist wirklich, das müssen Sie wirklich so sehen.
Das wird ja immer noch schlimmer.
Ich muss immer noch mehr, werde ich vom Programmieren abgehalten,
gewissermaßen, indem ich irgendwelche Dokumente schreibe.
Das war also gewissermaßen eine anarchische Gegenreaktion zu dem
übermäßigen Planen.
Und dann haben sich Leute zusammengesammelt, Schluss damit, Schluss
damit, wir machen das anders.
Uns sind jetzt nicht mehr die Dokumente so wichtig, sondern was uns
wichtig ist, Individuen und die Interaktion dazwischen ist wichtiger
als Prozesse und Werkzeuge, wie man es macht und so weiter.
Die Zusammenarbeit, laufende Software ist wichtiger als vollständige
Dokumentation.
Kundenmitarbeit ist wichtiger als Vertragsverhandlungen.
Im Extreme Programming geht das so weit, dass es verlangt, dass bei
größeren Softwareentwicklungen immer ein Kunde vor Ort ist, der also
beim Entwicklungsteam anwesend ist, den man dann fragen kann.
Und sich auf Änderungen einstellen ist wichtiger als Verfolgung eines
Plans.
Das ist das agile Manifesto.
Manifest finden Sie auch am Internet, das ist natürlich klar, mit
jeder Menge
Argumentation dazu.
Aber ich glaube, ein Manifest muss sich auch selbst erklären und ich
glaube, die Sätze tun das.
Okay.
Was ein agiler Prozess jetzt sagt, wir arbeiten mit einem Minimum an
Vorausplanung, denn die ganze Planung kann verkehrt sein und dann
haben wir uns nur einen Haufen Arbeit gemacht und das ist
verschwendete Zeit.
Die Planung erfolgt inkrementell, genauso wie wir es gesehen haben, im
iterativen Modell, vermeiden unterstützende Dokumente, das ist auch
ganz lustig zu sagen, wir brauchen keine Dokumente, der Code muss sich
selbst erklären, aber wenn du Dokumente haben willst, wenn du
Dokumentation haben willst, dann machen wir das, kostet halt extra.
Wir machen das, wäre erforderlich, aber eigentlich nicht.
Im Grundzustand erstmal nicht.
Wir wollen aber schnell reagieren auf Änderungen, auf Änderungswünsche
des Kunden, das wollen wir möglich machen und möglichst den Kunden in
die Entwicklung mit einbeziehen.
Das ist der Kunde vor Ort.
Da gibt es mehrere Vertreter, das Extreme Programming, das ich jetzt
Nexus nenne und das Scrum, das wir über Nexus durchbesprechen und da
gibt es noch weitere, inzwischen wahrscheinlich noch fünf andere, aber
die beiden sind die wichtigsten Vertreter und die schauen wir uns
jetzt an.
Das Extreme Programming geht also so vor, das sind die 1, 2, 3, 4, 5,
6, 7, 8, 9, 10 wichtigsten Techniken, die benutzt werden im Extreme
Programming.
Das ist übrigens auch ein Extreme Programming, das lehnt sich so an,
an Extreme Sports.
Das ist also auch ein guter Marketing-Ausdruck.
So, was kommt da vor?
Manches davon kennen wir noch gar nicht.
Das eine heißt das Paar-Programmieren.
Paar-Programmieren heißt, das heißt, jede Zeile Produktiv-Code wird
von zwei Leuten geschrieben, vor einem Rechner.
Revolutionär.
Wie?
Das verdoppelt ja meine Kosten.
Die Kosten gehen zwar hoch, aber die Qualität geht auch hoch.
Darüber werden wir noch sprechen.
Paar-Programmieren, immer Produktions-Code.
Das Test-Code zum Beispiel ist kein Produktions-Code.
Den dürfen Sie alleine schreiben.
Aber das, was in das endgültige System geht, immer mit einem zweiten
Kollegen oder Kollegin, die gewissermaßen eine Inspektion durchführt,
während wir arbeiten.
Dann gibt es das getriebene Entwicklung.
Ist ganz schwierig zu erklären.
Test-Getriebene Entwicklung heißt, wenn Sie eine neue Methode
schreiben, also eine Methode hinzufügen zu einer Klasse, dann
schreiben Sie zuerst den Test-Code.
Zuerst alle Tests schreiben für diese Methode.
Nur für diese Methode, nicht für alle Methoden.
Für diese Methode die Tests schreiben und dann den Code dafür und den
Code so lange massieren, bis alle Tests bestehen, es sei denn, wir
müssen noch weitere Tests hinzufügen.
Das ist Test-Getriebene Entwicklung.
Das stellt den Entwicklungsprozess auf den Kopf.
Normal sagt man, ich schreibe erst mal mein Zeugs und dann teste ich
es.
Das ist normal.
Wir sagen genau umgekehrt.
Schreib erst deine Tests.
Das hat eine wichtige Funktion.
Da es keine Dokumentation gibt, gibt es auch keine Spezifikation.
Niemand sagt dir, was die Schnittstellen sein sollen zwischen den
Modulen.
Aber die Test-Getriebene Entwicklung zwingt den Programmierer dazu,
das festzulegen.
Denn er kann den Test nicht schreiben, wenn er nicht weiß, welche
Parameter die Methode braucht und was die Funktion ist.
Er kann nur Rückgabewert ist und was er sonst alles anstellt.
Das muss ja dann getestet werden im Test.
Also muss ich mir jetzt statt ein Spezifikationsdokument zu schreiben
einen Test und damit lege ich die Spezifikation fest.
Die dokumentiere ich dann natürlich als Kommentar à la JavaDoc im Code
selbst.
Das ist die Test-Getriebene Entwicklung.
Dann inkrementelle Entwurfung und Mitumstrukturierung.
Das hatte ich vorhin schon erwähnt bei der inkrementellen oder
prototypischen Entwicklung.
Wir haben mehrere Phasen.
Da ist jetzt keine Festlegung auf drei Phasen wie bei Microsoft,
sondern es sind beliebig viele Phasen.
Und die fügen einfach immer wieder ein neues Inkrement hinzu.
Und wenn es nicht passt, dann wird einfach umstrukturiert.
Das ist Teil der Aufgabe.
Wenn ich keinen vorausschauenden Turf gemacht habe, der sagt, ich bin
vorbereitet auf die und jene Änderung und jetzt kommt diese Änderung,
bin aber nicht vorbereitet drauf, dann strukturiere ich halt um.
Das ist auch etwas auf den Kopf gestellt.
Sie erinnern sich, wenn ich über den Turf gesprochen habe, da sagte
ich immer, Vorsicht beim Entwurf, achten Sie drauf, was noch kommen
könnte.
Ich könnte die Algorithmen ändern, ich könnte die Datenstrukturen
ändern, ich könnte eine Ausgabeformate ändern, ich könnte ziemlich
viel anpassen müssen und denk dran, dass du eine Schnittstelle machst,
die änderungsunempfindlich ist.
Wir sagen, die ist nicht erforderlich.
Mach nur so viel, wie gerade notwendig.
Also, iterative Planung in kurzen Zyklen, das nennen sie Planungsspiel
oder Planning Game, ich weiß nicht, warum das ein Spiel ist, das ist
todernst, aber so heißt es.
Aktive Beteiligung des Kunden, hatte ich schon erwähnt.
Der Kunde ist vor Ort.
Fortlaufende Integration, das kennen wir auch schon von Synchronize &
Stabilize.
Hier wird permanent auf Knopfdruck, mehrmals am Tag, wenn Sie wollen,
integriert.
Allerdings mit dem Kaviar, das machen Sie in Ihrer eigenen Sandbox, in
Ihrer eigenen Entwicklungsumgebung.
Und erst wenn das bei Ihnen alles stimmt, wird es sichtbar gemacht für
das Gesamteam.
Und derjenige, der etwas Unfertiges abliefert, der kriegt eine kleine
Strafe.
Es gibt Programmierrichtlinien, das wissen Sie, was das ist, das
bespreche ich jetzt nicht mehr weiter.
Gemeinsamer Quelltextbesitz, das heißt, niemand ist der alleinige
Besitzer einer bestimmten Komponente und nur er oder sie darf sie
ändern und verbessern.
Das ist kein persönlicher Besitz.
Jeder, der kompetent ist, darf das Ding ändern, wenn es notwendig ist.
Betonung auf kompetent.
Textuelle Beschreibung der Anwendungsfälle auf Karteikarten.
40 Stunden in der Woche verstehen Sie auch.
Textuelle Beschreibung der Anwendungsfälle.
Anwendungsfälle gibt es, so viel Planung muss sein.
Es gibt die Anwendungsfälle, die ich Ihnen ja schon beschrieben habe,
ganz am Anfang der Vorlesung, die gibt es, die werden auf Karteikarten
notiert, natürlich digital.
Und wie man dann vorgeht, in diesem iterativen Planung, ist, dass man
sich aus diesen Karteikarten die nächsten Funktionalität herausholt
und sagt, die machen wir in der nächsten Iteration.
Okay, jetzt zu einigen diesen Punkten etwas mehr Detail.
Bitteschön.
Die Frage ist, werden die 40 Stunden wirklich eingehalten oder gibt es
da auch Überstunden?
Die gibt es sicher auch.
Aber es ist so, dass sowohl Powerprogrammieren und Testgetrieben
Entwicklung, wenn Sie es richtig machen, richtig anstrengend sind.
Also denken Sie mal an Powerprogrammieren.
Sitzen Sie mit dem Kollegen vor dem Spielschirm.
Es ist nicht so, dass Sie da Kaffee trinken.
Sie sind ein gut eingespieltes Paar, das arbeitet wirklich intensiv.
Und Sie schaffen nicht mehr als 8 Stunden am Tag.
So intensiv zu arbeiten, das geht gar nicht.
Also genau.
Aber es ist ein Ziel, sagen wir mal so.
Jetzt schauen wir uns Powerprogrammieren genauer an.
Was haben wir noch?
5, 6 Minuten.
Arbeiten an einer Tastatur einer Maus, einem Bildschirm.
Obwohl es da auch schon Abwandlungen gibt.
Es kann auch sein, dass Sie einen Bildschirm haben, aber zwei
Tastaturen, zwei Mäuse.
Dass man nicht dauernd um die Tastatur kämpfen muss.
Sonst muss man sich immer so hin und her schubsen.
Diejenigen, die mit zwei Tastaturen Maus arbeiten, sagen, das ist
eigentlich besser.
Dann gibt es eine Rollenverteilung, die sagt Fahrer und Beifahrer.
Der Fahrer denkt die Implementierung des augenblicklichen Algorithmus
und tippt eigentlich den Code ein.
Während der Beifahrer strategisch denkt, dann sagt er, der macht jetzt
das.
Ich schaue mal schon, ob das jetzt stimmt.
Führt also ständig eine Durchsicht durch.
Betrachtet also den Code oder denkt voraus und sagt, ok, als nächstes
müssen wir die und die Funktion machen und die mit der und der
Bibliothek, die brauche ich jetzt kombinieren.
Da müssen wir gleich mal nachschauen.
Aber die Hauptaufgabe ist die Durchsicht.
Das führt jetzt zu nachweisbar höherer Qualität und auch höherem
Tempo.
Und dieses Paarprogrammieren könnten Sie sagen, kompensiert für das,
was wieder mal fehlt, nämlich die fehlenden Inspektionen und Reviews.
Drittig ist jetzt, ob das wirklich ein Vorteil ist.
Also man weiß jetzt, es gibt endlose Studien übrigens über
Paarprogrammierung.
Man weiß zum Beispiel, dass die meisten Leute erstmal mit großer
Begeisterung Paarprogrammieren beginnen, auch wirklich
Paarprogrammieren durchführen, aber über die Zeit, sagen wir ein
halbes bis zum ganzen Jahr, der Anteil der Paarprogrammierung immer
weiter absinkt.
Anscheinend finden Sie, dass es nicht mehr erforderlich ist, im Paar
zu programmieren oder so etwas.
Man weiß nicht genau, warum das absinkt.
Außerdem ist das Paarprogrammieren sehr, sehr günstig für das
Einführen eines Neulings in die Software.
Jemand, der sich noch nicht in der Software auskennt oder der
vielleicht die Programmierumgebung nicht so gut kennt, wissen Sie, was
jeder Schalter in ihrer Programmierumgebung, in Eclipse oder so etwas,
tut.
Sie kennen wahrscheinlich 10% dessen, was Sie machen könnten.
Das lernt man also im Paarprogrammieren sehr schnell, aber die Kosten
verdoppeln sich nahezu.
Wenn man nur Zahlencode liest, die überzeugt werden, dann sind die
Kosten etwa, naja, ich weiß es nicht genau, eine letzte Studie sagt so
zwischen 80 und 90% höhere Kosten.
Und es ist nicht klar,
ob das durch die höhere Qualität kompensiert wird.
Dazu gibt es noch keine Studie.
Was heißt also eine Studie, die sagen würde, ja, wir investieren die
extra Zeit und die extra Kosten, aber dann fällt hinterher beim Testen
weniger Zeitaufwand an.
So eine Studie kann ich Ihnen leider nicht verweisen, denn ich denke,
es gibt sie nicht.
Es gibt aber ein großes Experiment mit 300 Teilnehmern über
Paarprogrammieren.
200 wurden in Paaren eingesetzt und 100 als Einzelprogrammierer und
deren Qualität und Produktivität verglichen.
Und da hat man unter anderem festgestellt, erstens, dass die Kosten
eben um 80-90% hochgehen, aber dass das der Nutzen für den erfahrenen
Entwickler keiner ist und er eher den unerfahrenen Entwicklern nützt.
Okay.
Also da gibt es jede Menge Studien.
Wenn Sie später mal in Vorlesungen gehen, dann bespreche ich die
empirische Softwaretechnik genauer.
Moment.
Ferner.
Und das hatte ich jetzt vorhin übersprungen.
Ich sagte ja Ihnen, dieser Beifahrer führt quasi ein Review durch,
während der Fahrer arbeitet.
Das kann ich natürlich auch sagen.
Na gut, das könnte ich doch auch trennen.
Ich könnte also hergehen und sagen, ich programmiere einzeln, führe
aber dann ein Review durch und was sind dann die Qualität und die
Kosten.
Und es stellt sich also heraus, dass die vergleichbar sind.
Ich kann also entweder ein paar programmieren oder einzeln
programmieren, aber dann eine Inspektion nachschalten, dann bekomme
ich den gleichen Qualitätsvorteil für etwa die gleichen Kosten.
Das heißt, Sie müssen gar nicht, um hohe Qualität zu erreichen, ein
paar programmieren.
Sie können das auch erreichen, indem Sie Inspektionen durchführen.
Aber Sie wissen ja, die kostet natürlich auch Zeit.
Vielleicht etwas weniger als permanent ein paar zu programmieren.
Okay, das wäre also das, was zu Ihr paar Programmieren zu sagen ist.
Wir haben auch Praktika durchgeführt mit paar Programmieren.
Ich kann Ihnen sagen, Studenten sind immer begeistert.
Sie finden das gut.
Das kann ich auch gut verstehen.
Aber als Dauerzustand ist so die Frage, ob man das wirklich die ganze
Zeit durchhält.
Gibt es Fragen dazu?
Okay, wenn es keine Fragen mehr gibt, das nächste Punkt wäre das
Testen.
Ist natürlich zeitnah zum Programmieren, automatisiert und damit
wiederholbar.
Das machen Sie ja schon alles selber.
Sollte Spaß machen, das heißt, dass man sich schnell schreiben kann.
Man hat entsprechende Umgebung, das JUnit und Ähnliches.
Das JUnit kommt übrigens aus dem Extreme Programming Teil her.
Und man soll Fehler finden, nicht Fehlerfreiheit beweisen.
Der Erfinder oder Apostel von XP sagt also, any program feature
without an automated test simply doesn't exist.
Programmierer schreiben also automatische Komponententests, Kunden
spezifizieren Akzeptanztests, die die Programmierer implementieren und
andere Testarten, Testtests und so weiter sind natürlich auch möglich.
Testausführung häufig und automatisch.
Was wir nächstes anschauen müssen, ist die testgetriebene Entwicklung,
aber das machen wir dann am Freitag.
Vielen Dank.
Bis Freitag.