Wir sind jetzt mit dem Testen noch länger nicht fertig.
Ich hoffe, dass ich kann das Kapitel heute komplett machen.
Dann machen wir als nächstes die Prozessmodelle und dann schauen wir
noch, ob wir die übrigen zwei Kapitel noch reinkriegen, nämlich die
Aufwandsschätzung zum Beispiel.
Eigentlich ist das, was ich jetzt zu sagen habe, für Automaten total
einfach.
Wenn Sie einen Automaten testen, dann teste man alle
Zustandsübergänge.
Also man teste alle Übergänge, und zwar so mindestens einmal, das ist
so ähnlich wie bei den Kanten in einem Datenflussgraf oder
Kontrollflussgrafen, vielmehr.
Allerdings ist es noch nicht so vollständig, dass noch nicht alle
Zweige überdeckt haben, denn die Methoden, die dabei aufgerufen werden
können, natürlich mehrere Zweige enthalten, und das heißt, Sie müssen
dann für die Zweigüberdeckung möglichst noch weitere Testfälle
hinzunehmen.
Aber zunächst mal ist das Hauptziel, dass man sagt, in einem Automaten
alle Übergänge testen, von jedem Zustand in jedem Zielzustand, der
möglich ist, und die entsprechenden Aktionen dabei prüfen, ob sie
ausgeführt werden.
Das ist also ein Überdeckungskriterium, wie wir es auch von Ihnen
schon kennen, nur diesmal angewandt.
Damit Sie wissen, ob der zusätzliche Zustand auch wirklich erreicht
worden ist, müssen Sie möglicherweise eine Ausgabe einbauen oder ein
Assert, das sagt, jetzt müsste ich im Zustand so und so sein.
Aber das wissen wir ja, wie das geht.
Mit JUnit lässt sich das leicht veranstalten.
Man spricht beim Testen von Zustandsautomaten von einem Alpha-Omega
-Zyklus.
Das ist ähnlich wie ein vollständiger Pfad durch einen
Kontrollflussgrafen, nämlich der Alpha-Zustand ist der Initialzustand
und ein Omega-Zustand ist einer der Endzustände.
Wenn es mehrere gibt, habe ich natürlich mehrere.
Bei den Endzuständen ist dann immer zu überprüfen, was passiert
eigentlich mit den Daten, die dynamisch angelegt wurden.
Werden die auch freigegeben?
Werden nicht noch Referenzen gehalten, die vermeiden, dass die
automatische Speicherbereinigung die Objekte beseitigt?
Dann gibt es die Finalize-Methoden, die aufgerufen werden, wenn ein
Objekt beseitigt wird.
Und die Finalize-Methode läuft nur, wenn ein Objekt tatsächlich
freigegeben wird.
Und möglicherweise läuft die Finalize-Methode nicht, weil noch
irgendjemand an irgendeiner Stelle einen anderen Verweis auf das
Objekt hat.
Schwache Referenzen brauchen wir jetzt nicht.
Da kommt ein Beispiel, aber das können Sie gerne selber durchdenken.
Als nächstes kommen ganz kurz die sogenannten Leistungstests.
Da gibt es zwei Typen, nämlich den Last-Test und den Stress-Test.
Die sind genauso, wie sie benannt sind.
Der Last-Test lässt das System im erlaubten Grenzbereich laufen.
Betonung auf erlaubt und Grenzbereich.
Das heißt, Sie möchten wissen, ob das System die genannten
Nutzerzahlen bedienen kann, garantierte Antwortzeiten einhalten kann,
selbst wenn das System unter Last steht und kann diese Last auch
beliebig lange bewältigt werden.
Dazu macht man eben diese Last-Tests und das heißt, da muss man sich
natürlich auch Gedanken darüber machen, wie diese Last erzeugt wird.
Die kann ich nicht durch manuelle Eingaben erzeugen, sondern auch das
muss dann ein automatisch ablaufender Test sein, der eben unter
Umständen mit mehreren anderen Maschinen arbeitet, um diese Last zu
erzeugen.
Oder auf der gleichen Maschine.
Wissen wir natürlich, ob das zu bejahen ist, diese Anforderungen über
die Lastbewältigung, ob die erfüllt sind und ob es irgendwelche
Flaschenhälse gibt, wo eben eine Verlangsamung eintritt.
Der Stresstest hingegen sagt so, und jetzt machen wir noch einen
Lasttest, aber einen Lasttest, der über die geplante Grenze
hinausgeht, um zu sehen, wie das System im Überlastbereich sich
verhält.
Denn da kann es zu Überraschungen kommen.
Wie ist das Leistungsverhältnis?
Es könnte so sein, dass man das sogenannte Seitenflattern hat, dass
sich so viele Daten im Hauptspeicher halten muss, dass Permanentdaten,
Seiten aus dem Hauptspeicher und dem Hintergrundspeicher hin und her
geschoben werden müssen.
Sie wissen ja, der Hauptspeicher ist meistens bei großen Anwendungen
meistens kleiner als der virtuelle Speicher, mit dem eine Anwendung
läuft und die werden, der Speicherbereich wird aufgeteilt in Pixel
-Elemente, die nennt man Seiten und die werden im Hauptspeicher
ausgelagert, wenn dazu zu wenig Platz ist und dann andere von der
Platte reingeholt und wenn das passiert, dann wandern die Seiten
permanent hin und her und damit verlangsamt sich das System.
Es kann auch sein, dass im Überlastbereich plötzlich ein
exponentielles Ansteigen der Antwortzeiten ergibt, aus welchen Gründen
auch immer, irgendwelche Flaschenhälse, die eine Verlangsamung
verursachen oder total als Stillstand, dass gar nichts mehr geht.
Dann möchte man natürlich auch wissen, Stillstand wollen wir auf
keinen Fall haben, wir wollten zeigen, der Antwortzeit ist natürlich
dann selbstverständlich zu erwarten, aber kein exponentielles und dann
wollen sie auch wissen und wenn die Last jetzt wieder nachlässt, wann
kehrt das System in einen normalen Zustand zurück und läuft wieder
richtig auch im Lastbereich.
Also zwei einfache Konzepte.
Das nächste sind die manuellen Prüfungen, da haben sie diejenigen, die
in der Übung waren, ja schon eine Übung durchgeführt, wie eine
Inspektion abläuft.
Das besprechen wir jetzt nochmal kurz durch.
Ich verlasse mich also darauf, dass Sie das Beispiel schon kennen.
Die manuellen Prüfmethoden sind so, dass man Anforderungsdokumente,
Entwürfe oder Quellcode per Hand inspiziert.
Per Hand heißt natürlich mit Augen.
Und dazu gibt es sogenannte Inspektionsteams und zwei andere Methoden,
die ich Ihnen zeige, die sind aber alle sehr ähnlich.
Die Idee ist eben, dass man anstelle eines ablaufenden Tests, der
vollautomatisch abläuft, an den ich natürlich für eine Anforderung
oder einen Entwurf nicht einsetzen kann, dass ich das stattdessen
manuell mache.
Der Aufwand für diese, wenn man es richtig macht, die sogenannten
Inspektionen können bis zu 20% sein.
Die Zeit für die Prüfungen muss eingeplant sein, sonst ist sie nie
vorhanden und wir müssen darauf achten, dass Leute nicht schlecht
gemacht werden für ihre psychologische Arbeit.
Also der psychologische Druck als Einzelner durch eine Gruppe muss
vermieden werden.
Der Einzelne, der Software entwickelt hat, ist nicht auf der
Anklagebank.
Bist du blöd, warum hast du denn sowas gemacht?
Sowas sagt man nicht, sondern man hält sich rein an die
Defekte, die zu finden sind.
Die Arbeit wird begutachtet, nicht die Person.
Und alle kommen dran.
Das nimmt auch mal den Stress heraus.
Wenn auch die älteren, besseren, professionelleren schon können, dann
ist es nicht nur ein Mangel, den man einem Neuling vermutet.
Dabei sollten aber keine Kunden, keine höheren Manager anwesend sein,
denn höhere Manager haben Personalverantwortung und da bekommt jeder
Angst davor.
Dann funktionieren sie auch nicht mehr.
Aber ablaufend tun die Softwareinspektionen so, wie Sie es schon
gesagt haben, gesehen haben.
Wir nehmen zwei bis acht Inspektoren.
Acht ist allerdings etwas übertrieben.
Sie haben es zu zweit gemacht in der Übung.
Sie untersuchen zunächst mal unabhängig voneinander.
Das war also nicht so wie in der Übung.
Dasselbe Artefakt, das könnte jetzt ein Programm sein, das könnte ein
Testfälle sein, könnte ein Entwurf sein, könnte eine Anforderung sein.
Die gefundenen Defekte werden aufgeschrieben, notiert und
durchgesprochen im Team.
Das Hauptaugenmerk ist, Probleme zu identifizieren.
Die Lösung macht man später, wer ist derjenige, der dafür
verantwortlich ist.
Also es wird nicht gleich korrigiert, sondern nur notiert, was
verkehrt ist.
Für diese Prozesse gibt es dann Rollen und Formulare.
Da gibt es eben Leute, die etwas vorbereiten, das werden wir dann
gleich sehen.
Die eigentliche Arbeit durchführen und es gibt Prüflisten und
sogenannte Perspektiven.
Die Perspektiven werden wir diesmal auch überspringen.
Also es gibt im Wesentlichen drei oder vier von diesen Methoden.
Das erste, das oberste, nenne ich mal die Inspektion.
Englisch natürlich Inspection.
Da wird überprüft, aber nicht einfach so, sondern anhand von
Prüflisten.
Das ist so ähnlich, wenn Sie zum TÜV fahren.
Zum TÜV fahren müssen, weiß nicht, ob Sie schon mal waren, aber der
geht auch nach bestimmter Prüfliste vor und muss die verschiedenen
Dinge wie Sündung und Bremsen und Scheibenwischer und was da alles zu
prüfen ist.
Das macht er nicht einfach frei Schnauze, sondern hat eine klare
Prüfliste vor sich.
Genauso geht das mit den Inspektionen.
Da bekommen Sie Prüfliste, die ist angepasst auf die
Programmiersprache, die Programmierumgebung, sodass Sie nichts prüfen
müssen, was die Compiler und sonstige Prüfumgebung selbst automatisch
macht.
Das ist die formalisierteste Form.
Prüflisten ist das eine.
Das andere wäre sogenannte Lesetechniken.
Da stellt man sich vor, man wäre zum Beispiel ein Softwarewarter, der
sagt, ist diese Software überhaupt wartbar?
Verstehe ich, was sie tut?
Ist sie ordentlich dokumentiert?
Das ist eine bestimmte Perspektive.
Oder ein Tester, der sagt, wenn ich dieses System jetzt testen müsste,
ginge das überhaupt?
Und dann bekommt man zusätzliche Fragen, die diese unterschiedlichen
Lesetechniken aus einem bestimmten Blickwinkel vorschreiben und die
man dann durchführen soll.
Dann gibt es die unterste Qualitätsstufe, der sogenannte Walkthrough
oder auch Durchsicht.
Da gibt es überhaupt keine Regeln, sondern Sie setzen sich mit einem
oder mehreren anderen Kollegen zusammen als Entwickler und stellen
Ihnen das vor, was Sie geschrieben haben.
Sie erzählen also quasi Ihr Programm nach oder gehen mit Ihnen durch
eine Anforderung hindurch, Anforderungsdokument oder erklären, warum
Sie den Turf so und so gemacht haben.
Da gibt es keine Prüflisten, Checklisten oder sonst etwas.
Aber Sie kennen den Effekt.
Dadurch, dass Sie etwas erklären müssen, fällt Ihnen unter Umständen
etwas auf.
Dann sagen Sie, oh, da habe ich etwas vergessen.
Die anderen, die zuhören, sagen, ich verstehe nichts, aber es wird
schon richtig sein.
Die Kollegen stellen also Fragen, machen Anmerkungen und
Verbesserungen, aber ohne weitere Vorschriften.
Also gibt es natürlich Defekte, die zu suchen sind, aber auch der
Stil, die Namensgebung, die eingehalten werden muss, andere
Entwicklungsstandards und so fort.
Dazwischen liegt Review oder auch Deutsch könnte man sagen
Überprüfung, die meisten sagen Review bei uns.
Also es ist etwas mehr als die Durchsicht, etwas mehr formalisiert mit
klaren Rollen für die einzelnen Teilnehmer, aber auch zur Überprüfung
von schriftlichen Dokumenten durch einen externen, einen oder mehrere
externe.
Was kann ich dazu jetzt noch sagen?
Ah ja, hier ist eine Definition, übersetzt aus dem ANSI-Standard.
Die Inspektion ist eine formale Qualitätssicherungstechnik, bei der
Anforderung Entwurf oder Code, also schon alle drei, eingehen, eine
von verschiedenen Personen oder eine Gruppe von Personen begutachtet
werden.
Zweck ist das Finden von Fehlern, Verstößen gegen
Entwicklungsstandards und andere Probleme.
Das ist die ANSI-Definition.
Was sind Vor- und Nachteile von Inspektionen?
Naja, natürlich will man Fehler finden, aber die Technik ist anwendbar
auf alles, was gemacht wird, nicht nur den Code.
Sie können sie sogar auf Testfälle anwenden, wenn sie wollen.
Sie können auch die Testfälle inspizieren, insbesondere den
Abnahmetest.
Jederzeit und frühzeitig durchführbar.
Wir müssen nicht warten, bis das Programm fertig ist.
Und sie sind sehr effektiv.
Nachteil ist natürlich, sie sind manuell, sind daher aufwendiger, als
ein Programm, das abläuft, verbraucht die Zeit mehrere Mitarbeiter,
ist somit erstmal teurer.
Es ist zum Testen kein Ablauf, der läuft, also nicht dynamisch,
sondern statisch, man muss also statische Prüfmethoden im Kopf
anwenden.
Die Frage, die sich Ihnen jetzt natürlich stellt, ist, und rentiert
sich das?
Ist das sinnvoll, dieser Aufwand?
Nun, da gibt es mehrere Untersuchungen, Inspektionen, insbesondere
sind vielleicht die empirisch am besten untersuchte Techniken, Klasse
von Techniken, in der Softwaretechnik, mit vielen interessanten
Experimenten und Erfahrungen damit.
Dazu jetzt ein paar Ergebnisse dieser Studien.
Das eine Ergebnis ist, dass man sagt, dass mindestens 50 Prozent aller
entdeckten Defekte werden in Inspektionen gefunden.
Sogar bis zu 90 Prozent, aber Sie sollten auch damit, also das ist bei
Software, und 50 bis 75 Prozent in den Turfsfehlern werden durch
Inspektionen gefunden, nicht durch Testen.
Und achten Sie, dass das noch sehr frühzeitig ist.
Die Kosten für die Fehlerbehebung, dazu muss man sich erstmal klar
machen, dass ein Fehler, je später er gefunden wird, desto teurer wird
er.
Und man sagt also, was sind denn die Kosten für einen Defekt, den ich
in Inspektionen finde, und einen, den ich ja spät im Test, im
Regressionstest oder im Systemtest finde, da sind die Kosten zwischen
1 und 10 pro Fehler.
Also später wird das Empfinden der Defekte sehr viel teurer, in ganzer
Größenordnung.
Darum ist man natürlich interessiert dran, es möglichst früh zu
machen.
Und die Firmen, die es richtig machen und auf hohe Qualität Wert
legen, sagen, die Return on Investment ist weit über 500 Prozent, das
heißt also, die Kosten sind das eine, aber sie sparen sich damit
fünfmal die Kosten, die reingekommen sind, die entstanden sind.
Es lohnt sich also.
Es gibt eine etwas ältere Studie, wenn Sie die suchen wollen, von
Feigern, Design and Code Inspection to Reduce Errors in Program
Development, schon von 1976, also auch schon ziemlich alt, aber da
wird, das ist einer der Originalartikel über diese Technik.
Ich finde immer, es ist sehr interessant, die Originalartikel zu
lesen, wo sich diese Ideen zum ersten Mal formieren.
Müssen sie aber nicht.
Und warum funktioniert das?
Naja, das Vier-Augen-Prinzip oder das Sechs- oder das Acht-Augen
-Prinzip, viele sehen halt mehr als einer.
Die Inspektoren haben auch Abstand zum Dokument, sie können also einen
anderen Blickwinkel sehen, sie können, sie sind nicht so betriebsblind
oder anders betriebsblind.
Sie bringen Erfahrungen ein, die der Entwickler vielleicht nicht
hatte.
Und interessant ist, was dann eigentlich auch in der Inspektion
passiert, denn es gibt viele Fälle, wo eigentlich gar kein Defekt
vorliegt.
Wo es aber sagt, naja, es ist einfach unschön oder unvorteilhaft.
Das könnte das noch besser machen.
Es ist vielleicht ineffizient, es ist vielleicht kryptisch, schwer zu
verstehen.
Es kann eine Schwäche sein, aber nicht zu einem Defekt, zu einem
Ausfall führen.
Und das wiederum, diese Diskussion führt zu einer gemeinsamen Einsicht
und so, dass das Team an sich für sich auch etwas lernt und nicht nur
der Entwickler und damit das Team insgesamt sich verbessert.
Eine Inspektion läuft jetzt folgendermaßen ab.
Es gibt eine Vorbereitung, da gibt es den Koordinator, der dafür
sorgt, dass alle Inspektoren, sagen wir mal, wir nehmen drei oder
vier, die gleichen Unterlagen bekommen, teilt sie aus, natürlich
digital.
Dann erfolgt die individuelle Fehlersuche, das heißt, der Einzelne
nimmt sich die Dinge vor und arbeitet ein, zwei Stunden dran, um
Defekte zu identifizieren oder auch eben nur Schwäche, Unschönheiten
und so weiter.
Wird alles notiert.
Dann gibt es eine Gruppensitzung.
In der Gruppensitzung kommen die Inspektoren zusammen und besprechen
das, was sie gefunden haben.
Und dann gibt es die sogenannte Nachbereitung.
Die Nachbereitung heißt, ich muss jetzt die Fehler korrigieren.
Und dann gibt es auch noch einen Prozessverbesserungsvorschlag.
Das macht man wieder eher seltener.
Bei der Prozessverbesserung sagt man, wie kann ich den
Inspektionsprozess noch verbessern, was hat denn hier nicht so richtig
funktioniert.
Vielleicht muss man die Inspektionsliste anpassen.
Oder vielleicht muss man die Teams anders zusammenstellen.
Das macht man bei der Prozessverbesserung.
Gut, die Vorbereitung ist klar.
Austeilen, zeitlichen Ablauf planen, gibt es möglicherweise auch ein
starkes, starkes Treffen.
Die Inspektion selbst für die einzelne Fehlersuche sollte nicht länger
als zwei Stunden dauern.
Warum?
Weil man danach nicht mehr weiterkommt.
Man kann nicht mehr, man ist erschöpft, der Kopf macht nicht mehr mit.
Die individuelle Fehlersuche, man sagt, eine Stunde pro Seite, pro
Inspektor.
Das ist also, wenn wir überlegen, eine Stunde pro Seite, eine ganze
Stunde.
Aber diejenigen, die dabei waren letztes Mal, haben sicher gesehen,
dass es gar nicht so leicht ist, sich einen fremden Code einzulesen.
Bis man das kapiert hat, was der da macht.
Durchgegangen werden können maximal ein bis vier Seiten netto.
Man benutzt die vereinbarte Lesetechnik, zum Beispiel eine
Inspektionsliste oder eine Perspektive, schreibt die Probleme genau
auf, an der Stelle im Dokument selbst hin oder in ein spezielles
Formular und macht eben dann mögliche Defekte, hat Verbesserungsläge
und Vorschläge und Fragen, nur eine Frage dazu, aber man versucht
nicht, den Code zu korrigieren.
Wie das zu beseitigen, das ist die Aufgabe eines Nächsten.
Etwa eine Seite pro Stunde, vielleicht noch fast zwei, manchmal auch
weniger als eine Seite pro Stunde, schreibt man bei dem Lesen.
Dann gibt es, wie gesagt, die Gruppensitzung, da werden die
individuellen Problempunkte gesammelt.
Es kann sein, dass der gleiche Problempunkt mehrfach gefunden wurde,
dann wird das natürlich konsolidiert.
In einem Punkt ist klar, es kann auch sein, dass es Problempunkte
gibt, die nur ein einziger gefunden hat.
Man diskutiert diese und klärt die Fragen.
Man ist übrigens, der Autor dieses Dokuments ist nicht dabei.
Das macht nur die Gruppe, ohne Hilfe von dem Autor selbst.
Da gibt es einen interessanten Punkt.
Während der Diskussion kann es neue Ergebnisse geben, also neue
Effekte, die entdeckt werden, an die man vorher nicht dachte.
Das nennt man im Englischen die sogenannten Meeting Gains, also der
Gewinn des Treffens.
Es gibt auch Meeting Losses, das heißt also, Verlust von Anmerkungen
während des Treffens.
Das liegt zum Teil daran, dass sie sich entweder erledigt haben, hat
jemand was missverstanden, oder einer traut sich nicht, es zu sagen.
Dem sollte man natürlich eine Atmosphäre schaffen, wo es möglich ist,
auch unsichere Punkte mit besprechen zu können.
Man kann Verbesserungsvorschläge diskutieren, man kann aber auch sie
nur notieren und das dabei belassen.
Nachbereitung, da wird der Autor oder Editor des Dokuments
weitergeleitet, klassifiziert die Defekte, leitet die Änderungen ein,
bearbeitet alle Problempunkte, dann kann er eine Liste herumschicken,
der sagt, ich habe den Punkt, den Punkt, den Punkt und den Punkt
gemacht und zwar so und so.
Man kann dann auch Restdefekte schätzen.
Das ist ziemlich hanebüchen, aber das ist das Beste, was wir haben.
Sie haben ein Dokument vor sich, Sie haben das Ding inspiziert, dann
sagen Sie, gut, und wie viel haben wir jetzt nicht gefunden?
Dann sagen Sie, ja gut, die Nicht-Defekte sind möglicherweise so viel,
wie die gerade entdeckten.
Je mehr ich entdeckt habe, desto wahrscheinlicher ist es, dass noch
mehr drinstecken.
Und außerdem muss ich noch darüber nachdenken, dass ein Sechstel der
Korrekturen auch wiederum fehlerhaft sind.
Entweder die Korrektur selbst fehlerhaft ist oder etwas anderes kaputt
machen.
Auch das kann mir natürlich passieren.
Und dann sage ich, okay, irgendwann muss ich ja freigeben, ich kann
nicht bis zur Perfektion warten.
Dann sage ich, wenn die geschätzte Defektanzahl kleiner als die
vorgegebene Zahl oder eine bestimmte Dichte ist, also so und so viele
Defekte pro tausend Zeilen Code geschätzt, akzeptieren wir, bevor wir
zum Kunden gehen, dann können wir freigeben.
Planendurchführen und Bessern haben wir schon gehabt.
Dann gibt es den Inspektionsleiter, das war derjenige, der die
Vorbereitung macht und die einzelnen Phasen leitet, den Moderator, der
die Gruppensitzung leitet.
Das können die gleichen Personen sein, der Inspektionsleiter und
Moderator, die Inspektoren selbst, die prüfen das Dokument.
Einen Schriftführer kann ich separat einsetzen, der die Defekte
notiert und ein Editor klassifiziert und behebt die Defekte.
Der Autor hat das Dokument verfasst, aber Autor und Editor müssen die
gleichen sein, können aber, sind aber meistens.
Wie sieht sowas aus?
Naja, ich habe ein Formular, da sage ich, Stelle ist Modul so und so,
Zeile so und so.
Ich habe eine kurze Beschreibung, die Wichtigkeit ist hoch oder
gering, Problemtyp ist Defekt, Anregung, Frage.
Defekttyp und dann behoben, ja, nein, nachgeprüft, ja, nein.
Das ist eigentlich ganz einfach.
So hat man das früher gemacht, als das noch alles Papier war, kann man
natürlich immer noch so machen, aber heute hat man digitale Versionen
davon.
Da zeige ich Ihnen dann vorher und nachher noch ein Beispiel.
Natürlich kann ich das auf dem Bildschirm heutzutage machen und direkt
in das Dokument eine Annotation einfügen.
Defektklassifikation ist schwerwiegend oder leicht und Defekt sind
Anregungen, sind Vorschläge etwas zu verbessern oder einfach nur eine
Frage, was passiert an dieser Stelle, wenn das und das vorliegt oder
nicht oder was immer es ist.
Defekttypen gibt es auch noch.
Ambiguous information heißt das, extraneous information, also zu
überflüssiges.
Inconsistent information, incorrect fact, missing information,
miscellaneous defect.
Okay.
Dann machen wir mal kurz einen Stopp.
Gibt es Fragen soweit?
Ich sehe keine.
Gut, die Lesetechniken sind ad hoc, das sind eben bei den
Durchsichten, ich habe keinerlei Vorgaben.
Ich habe eine Prüfliste oder Checklist mit Fragen zum Dokument.
Das soll natürlich das Aufspüren von Defekten erleichtern.
Und ich muss diese Fragen abhaken, Reihe nach, wie so eine Liste.
Die Prüflisten sind natürlich abhängig von der Art des Dokumentes.
Wenn ich ein Java-Programm habe, habe ich anderes zu prüfen, als wenn
ich ein C- Programm prüfen muss, weil dort das Typprüfen zum Beispiel
nicht so stark ist wie bei Java.
Bei Entwurfsdokumenten brauche ich etwas anderes.
Da brauche ich völlig andere Prüfliste.
Vielleicht muss ich sagen, ist das Geheimnisprinzip eingehalten, sind
alle Attribute privat und ähnliches.
Oder ist ein innerer Zusammenhang des Moduls gegeben, also habe ich
andere Fragen, als wenn ich Code inspiziere.
Ich zeige Ihnen aber
gleich so eine Prüfliste.
Die Perspektiven aus Szenarien sind eine Anleitung, wie das Dokument,
aus welcher Sichtweise es zu lesen ist, mit einem Satz und Fragen.
Die überspringen wir heute aber aufgrund von Zeitmangel.
Es sagt etwas über, wie groß so eine Inspektionsliste sein soll.
Sie wird leider ziemlich schnell, ziemlich groß und je länger sie ist,
desto mehr Punkte hat sie und desto mehr Arbeit erfordert sie und da
muss man irgendwie ein gutes Mittelmaß treffen.
So eine Hand Ausregel ist, dass man ein bis zwei Seiten hat.
Hier wäre zum Beispiel so eine Prüfliste in der obersten
Detaillierungsstufe, müssen Sie nicht auswendig lernen, keine Angst.
Wenn wir Sie prüfen lassen, dann kriegen Sie eine Prüfliste in der
Prüfung.
Variablen, Attribute und Konstantendeklarationen anschauen,
Methodendefinitionen durchsehen, Klassendefinitionen durchsehen, ist
klar.
Datenreferenzen, wie werden Daten angesprochen?
Die Berechnungen ist klar.
Vergleiche, Bedingungen, der Steuerfluss, Kontrollfluss der Ein- und
Ausgaben, die Modulschnittstellen, Kommentare, Dokumentation okay.
Ist die Kodformatierung sauber?
Die Modularität, die Speicherverwendung und die
Ausführungsgeschwindigkeit.
Und jetzt nur ein Beispiel.
So war es, noch eins zurück.
Die Variablen, Attribute und Konstantendeklarationen, diesen Punkt
genau anschauen.
Den spalte ich jetzt auf.
Also sind die Variablen, Attribute und Konstantennamen aussagekräftig?
Stimmen die Bezeichnungen mit den Programmierrichtlinien überein?
Gibt es für Variablen Attribute mit ähnlichen Namen wegen der
Verwechslungsgefahr?
Wurde jede Variable und jedes Attribut korrekt typisiert?
Stimmen die Typen?
Und wurde alles initialisiert?
Ziemlich einfach, aber natürlich sind Variablen und Konstanten auch
von sich aus ein einfaches Konstrukt.
Bei Berechnungen wird das dann schon etwas anderes.
Methodendefinitionen?
Sind die Methodennamen aussagekräftig?
Wir haben so ein paar Beispiele in den Java-Puzzlen ja gehabt, wo die
Methodennamen mangelhaft waren.
Stimmen die Methodennamen mit den Programmierrichtlinien überein?
Ähnlich wie da oben.
Wird jeder Methodenparameter vor der Verwendung überprüft?
Also alle Eingabeparameter.
Gibt es Prüfungen?
Sind sie auf Richtigkeit geprüft?
Gibt die Methode mit jedem Return den korrekten Wert zurück?
Gibt es statische Methoden, welche nicht statisch sein sollten und
umgekehrt?
Okay.
Eher ist es so, dass es eher umgekehrt ist.
Habe ich eine nicht-statische Methode, die eigentlich statisch sein
könnte, weil sie keine Attribute benutzt?
Nur statische Attribute.
Es könnten also natürlich noch weitere Prüfungen ergänzen.
Wie gesagt, muss ich nicht machen.
Komplett Ihnen jetzt vorlegen.
Aber es klingt alles ganz einfach.
So ähnlich wie beim Entwurf.
Ist ganz klar, das kann ich doch.
Und wenn man es davor sieht und es machen muss, ist es aus.
Was macht denn der da?
Was soll dieser Code?
Okay, so.
Gut, also die Perspektive und Szenarien, wie gesagt, die sparen wir
uns.
Können Sie natürlich selber durchlesen, aber es gibt uns nicht sehr
viel Zeit.
Es waren bloß zwei Folien, wenn Sie es gesehen haben.
Drei.
So, jetzt gibt es Werkzeuge der Inspektionsunterstützung.
Agile Review Jupyter und so weiter, Fabricate Review Board, Road Code
und so weiter.
Und die Frage ist, wo im Entwicklungsprozess wird diese Inspektion
eingespeist?
Und eine Methode ist, dass Sie eben, und das gilt jetzt hauptsächlich
für Programme, also nicht für Anforderungen, Sie buchen erst aus, aus
Git oder so etwas, programmieren und speichern die Änderung in die
Versionskontrollsystem ein, ohne dass eine Inspektion erfolgt.
Das heißt, andere Entwickler können das übernehmen und bereits damit
arbeiten, obwohl die Inspektion noch ansteht.
Dann gehe ich her und übermittle das Ding in das Inspektionswerkzeug
und sage, da wäre jetzt wieder etwas zu inspizieren, kann aber schon
benutzt werden, dann muss die Inspektion durchgeführt werden, dann
werden Änderungen genehmigt und die Änderungen genehmigten werden
natürlich auch wieder ins Versionssystem eingespeist.
Das ist die Methode 1.
Es gibt noch eine andere Methode, die sagt, Ihr Entwickler könnt
nichts von meinen Änderungen sehen, bis nicht die Inspektion
abgelaufen ist.
Was ist besser?
Keine Ahnung, es gibt noch keine Studie dafür.
Also, wieder aus Versionskontrollsystem ausprogrammieren, die Arbeit
machen, die Änderungen an das Inspektionswerkzeug zu übermitteln und
die Inspektion durchführen, dann die geänderten Änderungen genehmigen
lassen und dann erst in das Versionskontrollsystem einbuchen, das
heißt, dann wird es sichtbar für andere Entwickler.
Ja, da wird also die Inspektion als Hürde im Entwicklungsprozess.
Die Software ist eigentlich noch nicht da, bis die Inspektion
durchgeführt wird und wenn man keinen Termin findet für Inspektionen,
dann verzögert natürlich dieses Vorgehen die Verfügbarkeit der
Software.
Kann jetzt schlecht oder kann gut sein.
Ja, okay, das ist also nicht gerade scharf mal wieder, aber ich
glaube, es ist auch überhaupt nicht so besonders scharf.
Also, das ist das Beispiel Agile Review, das können Sie also in die
Programmierumgebungen eingeben, einblenden und können dann die
einzelnen Dinge mit Metadaten und Kommentaren zu einem
Inspektionsverwaltungssystem versehen.
interessanterweise, ich kann mich erinnern, als die Idee, dass man
einen speziellen Editor hat, mit dem man Inspektionen durchführt,
wurde vielleicht vor etwa 20 Jahren das erste Mal vorgeführt, und zwar
als Teil über einen Web-Editor.
Das heißt, die Inspektionen konnte man, Inspektionsergebnisse wurden
auf Webformularen durchgeführt und die Leute, die darüber berichtet
hatten, die stammten, glaube ich, von Agilent, sagten, das hat so
eingeschlagen, dass wir unsere Experimente gar nicht fertig machen
konnten.
Die Leute wollten das schon sofort benutzen.
Nun, es kann gut sein, dass Sie von Inspektionen noch nichts gehört
haben.
Zum Beispiel weiß man nicht, dass etwa Microsoft Inspektionen
durchführen würde.
Wenn, dann tun sie es nicht sehr häufig.
Es gibt andere Firmen, die führen Inspektionen seit den 70er Jahren
durch, und das sind gerade die Telekommunikationsfirmen und sind damit
sehr erfolgreich.
Die sagen immer, wenn es um Qualitätssoftware geht, wir wissen, wie
man das macht.
Wenn Sie sich erinnern, ich habe das schon mehrmals erwähnt,
unglaublich harte Qualitätsanforderungen genügen, nämlich nicht mehr
als eine Stunde Ausfall des Chess-Netzes in 40 Jahren.
40 Jahre, eine einzige Stunde, da soll das Festnetz stehen.
Das heißt, da müssen Sie Investitionen machen, dass Sie auch wirklich
möglichst alle Fehler finden.
Und so früh wie möglich.
Und das funktioniert mit Inspektionen und nicht mit Testen oder den
Benutzer testen lassen.
Und nicht mit Alpha-Tests in der Benutzerhand.
Es gibt Eclipse-Plugins, die arbeiten zusammen mit dem Git-System, das
heißt, die durchzuführten neuen Versionen, die noch nicht inspiziert
sind, bekommen gewissermaßen ein Vorarchiv und in das Hauptarchiv oder
in den Hauptarzt erst, wenn sie inspiziert worden sind.
Okay.
Das macht zum Beispiel das Werkzeug Garret.
Das agiert als Einbuchungspuffer zwischen dem Entwickler und Git.
Also alle Einbuchungen bis zur Genehmigung werden zurückgehalten.
Nach dieser zweiten Methode.
Und dann erst nach Durchführung geht es weiter.
Okay.
Wo waren wir jetzt?
Wo sind wir denn jetzt?
Jetzt sind wir im Komponententest.
Manuelle Prüfmethoden.
Jetzt fehlen uns noch die Prüfprogramme.
Da kann ich mich auch kurz fassen, denn das Konzept selbst ist ja auch
nicht schwierig und Sie kennen ja Checkstyle und vielleicht sogar
andere.
Prüfprogramme sind also dazu da, statisch Programme zu überprüfen,
ohne sie ablaufen zu lassen.
Und was gibt es da zum Beispiel?
Man möchte sehen, ob alle Variablen initialisiert sind.
Das macht der Java-Übersetzer übrigens schon.
Es gibt Fälle, wo natürlich Fehlermeldungen gibt, die nicht richtig
sind.
Da sagt er, ich meine, hier fehlt eine Initialisierung, aber wir als
Programmierer wissen, dass die Initialisierung doch passiert in einem
bestimmten Ast, der immer ausgeführt wird.
Es gibt nicht erreichbare Anweisungen, toten Code, kann auch ein
statisches Prüfsystem identifizieren.
Es kann unnötige Anweisungen geben, die nichts bewerken, deren Effekt
gleich wieder überschrieben wird.
Man möchte zum Beispiel wissen, ob jeder Monitoreintritt mit einem
Monitoreintritt gekoppelt ist.
Auch das kann man statisch überprüfen.
Egal, wie verschlungen die Logik einer Methode ist und gibt es halt
Break - und Return-Anweisungen, mit denen Sie aus der Methode oder aus
dem synchronisierten Block austreten und dann wollen Sie garantieren,
dass auch dieser Monitor dann freigegeben wird, denn sonst könnte es
vielleicht immer oder vielleicht auch nur in seltenen Fällen zu einer
dauerhaften Sperre und einer Blockade führen.
Sie können, und das macht Sextal, den Programmierstuhl überprüfen.
Das überspreche ich jetzt nicht, denn das kennen Sie.
Oder auch Fehler anhand von bestimmten Fehlermustern finden.
Auch dafür gibt es die entsprechenden Prüfprogramme.
Also haben wir das auch schon hinter uns.
Datenflussorientiert bleibt frei, das werden wir nicht machen.
Und jetzt kommen die beiden Tests.
Die letzten Test, Integrationstest und Systemtest und Abnahmetest habe
ich eigentlich schon besprochen aus der Übersicht am Anfang, wenn Sie
sich erinnern.
Integrationstest kommt als nächstes, aber da ist nicht viel zu sagen
mehr.
Integrationstest ist einfach eine schrittweise Integration, das heißt,
Sie spannen mehrere Komponenten zusammen.
Jede einzelne Komponente ist bereits getestet worden mit
entsprechenden Testprogrammen und Sie spannen sie jetzt zusammen und
prüfen wir erneut, bis das System komplett integriert ist.
Sie prüfen jetzt nicht so sehr die einzelnen Komponente, sondern das
Zusammenwirken der Komponenten.
Wenn Sie das so machen, haben Sie natürlich unter Umständen Aufrufe,
Systemteile, die noch nicht hinzuintegriert sind, dann brauchen Sie
dafür die Stummel und Sie wollen möglicherweise mit Ertrappen arbeiten
oder Nachahmungen.
Die müssen Sie bauen.
Die Frage ist aber, in welche Reihenfolge sollte ich integrieren?
Und da gibt es erstaunlich viele Möglichkeiten.
Da gibt es also eine Integrationsstrategie, die sagt, alles auf einmal
oder unmittelbar.
Das hat den Vorteil, dass Sie keinen Testtreiber und keinen
Platzhalter benötigen.
Sie nehmen das Gesamtsystem auf einmal zusammen.
Das heißt übrigens Big Bang, der Big Bang Test.
Und aus gutem Grunde, denn da geht erstmal gar nichts.
In der Regel geht da erstmal gar nichts.
Sie haben das Gesamtbetriebssystem zusammengehängt, sagen, jetzt
lassen wir es laufen bringen und schon kracht es.
Es müssen alle Komponenten schon fertig sein, Defekte sind dann schwer
zu lokalisieren, Sie haben ein sehr großes System, Testüberdeckung ist
jetzt schwierig sicherzustellen, jetzt haben Sie zig Millionen
möglichen Ästen, Zweigen, ist eigentlich für große Systeme nicht
geeignet, dieser Big Bang Test.
Big Bang war es dann, richtig laut kracht.
Inkrementell ist besser, denn Sie können fertiggestellte Komponenten
schon testen, selbst wenn noch nicht alles da ist.
Sie können unfertige Komponenten aber weiterhin entwickeln.
Die Testfälle sind leichter konstruierbar, da Sie in der Regel mit
weniger Komponenten arbeiten und die Testüberdeckung ist auch
überprüfbarer.
Aber Sie brauchen jetzt Testtreiber, na gut, das ist kein Problem
mehr, das macht JUnit für uns automatisch und Sie brauchen Testhelfer,
auch wieder Stummeln und eine Trappe, das ist inkrementelle.
Vorgehensorientiert heißt, die Integrationsreihenfolge leitet sich von
der Systemstruktur ab.
Zielorientiert heißt, Testzielorientiert heißt, Sie wollen ein
bestimmtes Ziel erreichen, zum Beispiel bestimmte Funktionalitäten
überprüfen.
Und da werden jeweils nur die benötigten Komponenten zusammen
montiert.
Okay, jetzt schauen wir an, den Big Bang haben wir schon, nichts geht,
bis alles geht.
Alles auf einmal.
Geschäftsprozessorientiert, alle Komponenten werden integriert, die
vom Geschäftsprozess oder Anwendungsfall betroffen sind, die ich dazu
brauche.
Das kann man machen, ist unter Umständen aber auch sehr viel des
Gesamtsystems.
Funktionsorientiert, funktionale Testfälle zum Beispiel, die die
funktionalen Anforderungen erfüllen, testen.
Oder schrittweise Integration und Test der Komponenten, die durch
Testfälle betroffen sind.
Das machen sie hier und nach Verfügbarkeit ist, naja, was ich halt
gerade fertig habe und die Fertigstellungseinfolge bestimmt jetzt, wie
sie testen.
Das ist nicht so geschickt, denn es ist extrem schlecht planbar.
So, jetzt schauen wir uns die anderen, die wirklich in Frage gekommen
sind, sind eigentlich in diesen Kontranten.
Der Top-Down ist, sagen Sie, Bienen mit den einfachsten Modulen oder
Komponenten, die auf nichts anderes als auf den Bibliotheken aufbauen
und testen sie, stellen sie zusammen, entschuldigen, das war das
Bottom -Up.
Top-Down geht gerade umgekehrt her.
Bei Top-Down fangen sie mit dem Main-Programm an und schieben nach und
nach zusätzliche Komponenten hinzu, aber die unteren fehlen ihnen
natürlich und dafür müssen sie die Stummel haben.
Also diese Testhelfer sind dann unter Umständen aufwendig zu
erstellen, aber sie haben dann sehr früh das Gesamtrahmenprogramm zur
Verfügung und können dann schon sehen, wie das Gesamtprogramm
vielleicht sogar mit der Oberfläche schon aussieht und ob die
Funktionen, die jetzt noch nicht richtig funktionieren, aber sie sind
schon mal da und sie geben vielleicht immer die gleiche Antwort, aber
man kann sehen, dass das Gesamtsystem, wie das Gesamtsystem am Schluss
aussehen wird.
Nachteil ist natürlich jetzt auch, wenn Zusammenspiel zwischen
Hardware und Software wichtig ist, dass das erst sehr spät geprüft
wird.
Wenn sie spezielle Sensoren brauchen zum Beispiel, spezielle Geräte,
spezielle Schnittstellen in einem eingebetteten System, dann wird
dieses Teil erst ganz am Schluss getestet und das kann natürlich
kritisch werden.
Bottom-Up geht halt genau andersrum.
Die Vorteile und Nachteile von Top-Down und Bottom-Up sind dann gerade
immer umgekehrt, was Vorteil war beim einen ist jetzt der Nachteil
beim anderen und so weiter.
Jetzt brauchen sie Testtreiber statt Stummel, aber sie haben ein
leichteres Herstellen von Testbedingungen als bei Top-Down und
leichtere Interpretation der Testergebnisse.
Outside-In.
Eher ungewöhnlich.
Outside-In, da sagt man, ich fange irgendwo in der Mitte, in der
mittleren Ebene meines Gesamtsystems an und büge nach unten und nach
oben in der Aufruf-Hierarchie oder Abhängigkeits-Hierarchie neue
Methoden hinzu.
Schrittweise in beiden Richtungen.
Inside-Out, was hatten wir gerade?
Outside-In.
Entschuldigung, jetzt habe ich wieder verkehrt herum erklärt.
Ich habe das Inside-Out erklärt, jetzt erkläre ich das Outside-In.
Das ist eigentlich unpraktikabel.
Das Gegenteil von Inside-Out kann man eigentlich vergessen, denn es
kombiniert eigentlich die Nachteile von Top-Down und Warm-Up.
Man beginnt also gleichzeitig von oben nach unten aufeinander
zuzuarbeiten.
Da müssen Sie die Top-Down-Methoden in Kauf nehmen und die Warm-Up
-Methoden.
Nachteile.
Inside -Out hatten wir und schließlich die kritischen Komponenten
zuerst.
Das ist durchaus vernünftig, wenn es solche identifizierbaren
kritischen Komponenten gibt, dass man die als allererstes testet, denn
die können unter Umständen die ganze Show zum Stehen bringen, wenn sie
zu spät getestet werden.
Okay, das sind die Integrationsstrategien.
Schon sind wir mit dem Punkt fertig.
Die Integrationsreihenfolge.
Jetzt käme als nächstes der Systemtest.
Der Systemtest ist jetzt eigentlich der letzte Integrationstest, der
alle Komponenten zusammenpackt.
Jetzt wird auch das System als Blackbox betrachtet.
Nur die äußere Schnittstelle wird noch getestet.
Die Benutzerschnittstelle und externen Schnittstellen zu anderen
Systemen.
Und es läuft auf einer realistischen oder realen Umgebung bereits.
Zum Beispiel auf einer technischen Anlage, in einem Roboter, in einem
Fertigungssystem, in einem Logistiksystem, in einem
Lagerhaltungssystem.
Wir hatten am Anfang ja immer dieses Problem, das Toll Collect gehabt,
mit der Mauterfassung für Laster.
Die haben das System tatsächlich getestet und mit echten Lastern und
nur der Diesel für die Laster, die Kosten für den Diesel, war in den
Millionen.
Ich weiß nicht, wie viele Laster sie fahren hatten, um das
Gesamtsystem zu testen.
Allein das, nur der Treibstoff, war im Millionenbereich.
Für den Test.
Es gibt noch einen funktionalen und nicht funktionalen Systemtest.
Ist klar, wir haben funktionale und nicht funktionale Anforderungen.
Das ist das, was ich im Systemtest überprüfe.
Also muss ich die Qualitätsmerkmale, die funktionalen Merkmale und die
nicht funktionalen Merkmale, wie zum Beispiel Sicherheit,
Benutzbarkeit, Interoperabilität, Dokumentation, Ausfallssicherheit
testen und nicht nur die Funktion.
Man denkt immer zuerst an die Funktion, aber ist das Ding auch
sichtbar?
Und natürlich führt man jetzt auch Leistungstests durch.
Also Last- und Stresstests.
Was ist eigentlich ein Regressionstest?
Regressionstest ist einfach ein Test, unabhängig von wie viel man
testet, sondern einfach die Wiederholung eines bereits bestehenden
Tests.
J -Unit macht Ihnen das ja sehr leicht, auf Knopfdruck wieder einen
Testsuite abfahren zu lassen, um festzustellen, ob nach
Pflegeänderungen, Wartung eines Systems es nicht weiter zurückgefallen
ist und alte Fehler wieder auftauchen.
Das ist die Regression, also das Rückfallen, das Regressieren auf
einen früher schlechteren Stand und Eigenschaftspunkt.
Jawohl.
Abnahmetests, da habe ich jetzt nicht mehr viel zu sagen, da wirkt der
Kunde mit, beobachtet, führt die Feder, das heißt, er schreibt auf,
was passiert und schreibt vor, in welcher Reihenfolge alles gemacht
wird.
Die reale Einsatzumgebung beim Kunden wird dazu benutzt und nach
Möglichkeit auch die Daten des Kunden verwendet.
Und der Auftraggeber kann natürlich auch noch eigene Testszenarien
sich hinzudenken.
Die formale Abnahme ist diejenige, die sagt, jetzt sind wir fertig.
Der Kunde sagt entweder ja, nehme ich ab, so wie es ist, selbst wenn
es noch da und dort klemmt.
Vielleicht gibt es dann eine oder andere Fehler oder Unschönheit, die
noch beseitigt werden müssen.
Aber wenn der Kunde sagt, ich nehme es so, dann können wir den Rest in
der Wartung korrigieren, aber ich kann das System schon benutzen, dann
wäre die Abnahme erfolgreich und damit steht die Zahlung an.
Das heißt, der Kunde muss jetzt für die Entwicklung zahlen und Sie als
Entwickler freuen sich da natürlich.
Jetzt endlich kommt Geld rein.
Literatur, ja, gibt es viel.
Lesen Sie den Teil im Brückenditor, mindestens.
Bedingungen über Deckungstechniken, die haben wir nicht besprochen,
also das Thema ist vielleicht uninteressant.
Jedenfalls nicht wichtig für die Klausur.
Dann sind wir also erst mal mit dem Test durch.
Es gibt noch Testhelfer.
Die Testhelfer kennen Sie aber schon.
Wesentlich war das JUnit, das haben wir ja schon besprochen.
Ich muss das Ding loswerden.
Ich springe jetzt ein bisschen vor, vom Kapitel 5 auf Kapitel 8, weil
wir jetzt noch eben diesen wichtigen Stoff der Prozessmodelle
behandeln müssen.
Wir werden einige Prozessmodelle oder auch Vorgehensmodelle
besprechen.
Nämlich Programmieren durch Probieren.
Das ist ganz einfach.
Das Wasserfallmodell kennen wir schon, besprechen nicht mehr.
Das Fahrmodell, also die Variante vom Wasserfallmodell.
Das Prototypenmodell, iterative Modelle, synchronisieren und
stabilisieren und schließlich die sogenannten agilen Methoden, die
heute sehr modern sind.
Erstmal soll ich Ihnen sagen, vielleicht fehlt eigentlich eine Folie,
was ist ein Prozessmodell?
Ein Prozessmodell sagt mir, für die Softwareentwicklung, in welchen
Schritten wir vorgehen, in welcher Reihenfolge, was die Eingabe und
Ausgaben dieser Schritte sind.
Zum Beispiel Wasserfallmodell, kann man sich das gut vorstellen.
Wir haben sechs Schritte und jeder muss komplett abgeschlossen sein
und da kommt rein, was weiß ich, in den Turf die Anforderung, das
Pflichtenheft und raus kommt ein Turf und ein Grobplan der
Schnittstellen und so weiter.
Wer macht es?
Zu welchem Zeitpunkt?
Und wann weiß ich, dass er fertig ist?
Das sagt mir ein Prozessmodell.
Es bietet also die Arbeit in unterschiedliche Aufgaben und weist sie
den entsprechenden Leuten zu.
Das Programmieren durch Probieren, wahrscheinlich das, was Sie
benutzen noch, Code and Fix oder Trial and Error, das sagt, ich fange
einfach mal Codieren an und dann teste ich das Ding und wenn es nicht
funktioniert, dann repariere ich es halt.
Man bemerke, man stellt also ein vorläufiges Programm und testet es so
lange, bis es passt.
Also man kann schnell Code erzeugen, vielleicht ohne zusätzlichen,
diese Anforderungsermittlung und so weiter.
Was soll das?
Was soll ich in den Turf?
Das mache ich im Kopf.
Das stimmt schon.
Der Code, der dabei entsteht, ist in der Regel unstrukturiert und
schlecht zu warten und also auf Wartung nicht vorbereitet.
Es gibt ja keinen Turf.
Die Probleme, die dabei auftreten, ist, ich hatte auch gar keine
Anforderungsanalyse.
Das heißt, ob ich den Kundenwünsche jetzt treffe, ist eher mehr oder
weniger zufällig.
Das war übrigens auch der Grund, warum man von Code and Fix weg ist.
Es wäre doch vernünftig, wenn wir ein bisschen planen, damit wir
wenigstens wissen, was wir machen sollen.
Die Wartung und Pflege ist kostspielig, weil das Programm nicht darauf
vorbereitet wird.
Die Dokumentation ist sowieso nicht vorhanden.
Und für Teamarbeit ist das Modell sowieso komplett ungeeignet, weil
ich ja nie gesprochen habe darüber, wie ich das Gesamtsystem aufteile.
Ich bin einfach hingegangen und habe zu codieren begonnen.
Und dann habe ich einen Spaghetti-Code erzeugt, der schwer zu lesen
ist.
Also, so hat man mal begonnen.
So beginnt man vielleicht als erster Programmierer.
Aber wenn Sie erstmal in einem größeren Team arbeiten, dann geht das
einfach gar nicht.
Die Gegenreaktion darauf war eben das Wasserfallmodell, das sagt, wir
haben auch eine Planungsphase, eine Definitionsphase, da machen wir
die Definition ganz exakt, sodass nichts mehr in Frage steht.
Und dann brauchen wir niemanden mehr Fragen danach und entwerfen und
implementieren das, machen eine gute Testphase dahinter und
schließlich gehen wir in den Einsatz und Wartung des fertigen Systems.
Wunderbar, die Schritte kennen wir.
Es wurde bereits 1956 als erstes Mal für Software vorgeschlagen, ist
schon viel älter, für andere industrielle Fertigungsprozesse gab es
die schon vorher, aber das ist das erste Mal auf Software adaptiert
gewesen, also vor mehr als 50 Jahren, schon, 60 Jahren.
Die Rückkopplungen, die Pfeile, die wurden, auf die hat man erst 1970
gedacht, dass man das eigentlich machen könnte, wenn hier etwas nicht
stimmt, dass man nochmal in der Definition nachschaut und vielleicht
sogar die Definition verbessert.
Aber es gibt keine phasenübergreifende Rückkopplung, es gibt keinen
Fall, der im Wasserfallmodell vorgesehen wäre, dass ich von der
Implementierung nochmal zur Planung gehe.
Wollen wir mal schauen, was das Wasserfallmodell jetzt ein bisschen
unhandlich macht und das ist, dass jede Aktivität in der vorgegebenen
Reihenfolge vollständig durchführen muss.
Also ich muss, selbst wenn ich gar nicht weiß, was ich genau machen
muss, die komplette Planung und Definitionsphase, jede für sich
komplett durchführen.
Ich darf an keiner Stelle etwas freilassen und eventuell ein Prototyp
bauen oder explorativ entwickeln und sagen, nein, so geht es nicht,
ich muss das anders machen, ich muss alles vorher festlegen und damit
legt man oft viel Unsinniges fest, was man dann unsinnigerweise auch
noch implementieren und testen muss, weil es eben so dasteht.
Dieses streng sequenzielle Vorgehen ist der eigentliche Nachteil des
Wasserfallmodells, nicht die verschiedenen Phasen, denn die
verschiedenen Tätigkeiten, habe ich Ihnen ja ganz von Anfang an
gesagt, brauchen wir in jedem Fall.
Ich muss eine Anforderung machen, ich muss einen Entwurf machen, ich
muss eine Implementierung machen, aber vielleicht muss ich nicht alles
komplett vollständig machen, bevor ich mit der Teilimplementierung
beginne.
Nennt man übrigens auch dokumentgetriebenes Modell, weil jede Phase,
jeder Schritt in diesem Wasserfallmodell einen Dokumentensatz liefert,
der im nächsten Schritt weiter benutzt wird.
Einfach und verständlich, die Benutzerbeteiligung ist nur bis zur
Definitionsphase vorgesehen, danach ist sie überflüssig.
Wir haben ja alles definiert.
Und gerade das geht oftmals nicht.
Daher, das habe ich schon gesagt, die phasenübergreifende
Rückkopplung, Parallelisierungspotential ist möglicherweise nicht
ausgeschöpft, denn die Entwickler warten jetzt, dass endlich mal die
Anforderungsanalyse fertig ist, damit sie beginnen können.
Aber, wenn die Anforderungsanalyse vielleicht zu 70% fertig wäre,
könnten sie an den ersten 70% ja eigentlich schon arbeiten.
Aber gerade das sieht das Phasenmodell nicht vor.
Die mögliche Parallelisierung von Schritten, sie erzwingt genaue
Spezifikationen von Sachen, die vielleicht nicht ganz durchdrungen
sind, von Benutzerschnittstellen und Funktionen und dann später zu
nutzlosem Code.
Daher ist das Wasserfallmodell eher ein pädagogisches Modell, mit dem
ich klar sagen kann, welche Arten von Tätigkeiten wir durchführen
müssen.
Und dann können wir sie auch in der Reihenform studieren, wie in
dieser Vorlesung, und erlernen.
Und außerdem zeigt uns das Wasserfallmodell ganz klar, dass es nicht
nur Codieren und Testen ist.
Ein bisschen mehr Anforderungsanalyse von der Definitionsphase,
Entwurfsphase.
Das nächste ist das V-Modell.
Das V-Modell ist eigentlich nichts anderes als das Phasenmodell, das
Wasserfallmodell, aber man hat nun gesagt, für jede dieser Phasen, die
Entwurfsphase ist etwas aufgegliedert in den Grobentwurf und den
Feinentwurf.
Sie wissen natürlich, was Grobentwurf und Feinentwurf ist.
Wenn nicht mehr, bitte nachschauen.
Ich habe es definiert, was der Grobentwurf und der Feinentwurf ist.
Eine Modulimplementierung oder auch Komponentenimplementierung kommt
hier unten, aber alle diese Schritte sind mit bestimmten Tests
gekoppelt.
Also es gibt keine große Testphase ganz am Schluss, obwohl den
Abnahmetest, Systemtest, Integrationstest gibt es natürlich auch.
Aber Sie sagen, da im Integrationstest teste ich den Feinentwurf,
passt alles zusammen.
Das ist genau der Feinentwurf, wo ich die genauen Schnittstellen
festlege und die Abhängigkeiten.
Das Systemtest ist der Grobentwurf, passt alles zusammen und der
Abnahmetest sagt, habe ich die Anforderungen erfüllt.
Sie erinnern sich, ich sagte auch vorhin, der Abnahmetest sagt ja, ich
benutze das System an der äußersten verfügbaren Schnittstelle, das
heißt, ich schaue eigentlich nach, ob es meine Anforderungen erfüllen
kann.
Okay, aber es kommt keine neue Tätigkeit hinzu, nur das Verständnis,
dass wir alle diese Phasen auch testen müssen, überprüfen müssen,
vielleicht auch manuell und dass diese Kopplung besteht.
So, jetzt meinen alle, das V-Modell heißt V-Modell wegen dieses Vs
hier.
Sie werden sich so merken, stimmt aber nicht.
Das V-Modell heißt, das V kommt nur vom Vorgehensmodell.
Dann gibt es ein V-Modell Extended, auch ein Vorgehensmodell, das ist
die Oberbürokratie, die man sich vorstellen kann.
Das V-Modell XT selbst, stellen Sie sich mal vor, 500 Seiten nur für
das Vorgehensmodell.
Ich erspare Ihnen das, wir können hier in der Übersetzung ein paar
Handreichungen mitgegeben.
Wenn Sie es mal benutzen müssen, prüfen tue ich das nicht, aber wenn
Sie immer Software für die öffentliche Hand, also für Landes,
Bundesregierung, für öffentliche Behörden, Polizei und so weiter
schreiben müssen, dann ist es höchstwahrscheinlich, dass das V-Modell
XT vorgeschrieben ist.
Und dann müssen Sie sich leider damit befassen.
Außerdem ist das V-Modell XT auch so, dass es schon auch eine
ordentliche Erweiterung von dem ursprünglichen V-Modell ist, weil es
hier auch gekoppelte Hardware und Softwareentwicklung erlaubt.
Das Wasserfallmodell sagt nur etwas über Software.
Was ist, wenn Sie Toll Collect machen müssen, wo Sie ein Gerät bauen
müssen, das in jeden Laster rein muss.
Wenn Sie ein mobiles System bauen, wo Sie speziell mobile Funkgeräte
brauchen.
Wie geht das eigentlich?
Wie stimme ich das ab?
Und dann gibt es ein Vorgehensmodell im XT, im V-Modell XT, das Ihnen
da ein bisschen hilft.
Es nimmt Ihnen keine Arbeit ab.
Das entwickeln müssen Sie alles noch selber machen.
Nur, über was muss ich denn alles organisatorisch und prozessoral
nachdenken?
Jaja, gibt's ziemlich viel.
30 Rollen, Akquisiteur, Anwender und so weiter.
Aber es ist alles schön definiert.
Das hilft einem natürlich, wenn man es braucht.
Wie gesagt, das überspringen wir.
Sie sehen, es ist ziemlich viel Zeugs.
Es gibt da übrigens auch
ein Produktzustandsübergangsdiagramm.
Das sagt, die erste Version eines Produktes wird erstellt.
Dann ist es im Zustand in Bearbeitung.
Dann kann es sein, dass es geprüft wurde, durch eigenständige
Qualitätssicherung.
Dann ist es im Zustand vorgelegt.
Wenn es dann inhaltlich und formal korrekt ist, dann ist es im Zustand
fertiggestellt.
Und dann gibt es verschiedene Übergänge, verschiedener Art.
Da ist natürlich die Informatik mit dabei.
Wir schauen uns jetzt aber an das Prototypmodell.
Also beim Prototypmodell sagt man, ich bin nicht in der Lage, dass die
Anforderungen, die benötigt sind, fertig, vollständig zu definieren,
ohne etwas auszuprobieren.
Oder aber, ich weiß nicht, ob ich bestimmte Anforderungen überhaupt
verwirklichen kann, ob es schnell genug läuft, ob ich entsprechende
Ressourcen, Daten, Algorithmen habe.
Ich muss auch das prüfen.
Könnte gehen, könnte auch nicht gehen.
Dazu macht man einen Prototypen.
Der Prototyp ist also ein eingeschränkt funktionsfähiges System, das
zum einen die Arbeitsmaterialvertrauen zwischen Arbeitern und Kunden
stärkt, aber es muss auch wichtige Fragen klären.
Das sehen wir dann gleich.
Ein gewisser Frederick Brooks hat ein Buch geschrieben, das heißt The
Mythical Man-Month.
Das dürfte er heute gar nicht mehr sagen, dann müsste er heute Person
-Month stehen.
Das mythische Personenmonat, das sagt er eben, dass man Personenmonate
nicht gegeneinander beliebig aufrechnen kann.
Indem ich mehr Leute in das gleiche Projekt stecke, wird das Projekt
schneller abgewickelt.
Das findet meist nicht statt.
Es dauert dann eben noch länger.
Aber er sagt auch, plan to throw one away.
Also wenn du ein großes System brauchst, rechne damit, dass du eines
wegwerfen wirst, weil selbst wenn du nicht damit rechnest, wirst du
das sowieso tun.
You will, anyhow.
Also Prototyp wegwerfen.
Was macht das Prototyp Modell 1?
Das sagt, ich muss bestimmte wichtige Fragen oder Unsicherheiten
klären.
Und das kann bedeuten, dass ich erstmal eine vorläufige Systemanalyse
mache, sage, hier ist ein Problem, ich weiß nicht, wie ich das angehen
soll, wie ich das spezifizieren soll, was ich da verlangen soll.
Dann mache ich einen Prototypentwurf und Implementierung, wie gesagt
eingeschränktes System und führe den Prototypen vor.
Und dann habe ich hoffentlich die wichtigen Unsicherheiten beantwortet
und gehe dann über in ein anderes Entwicklungsmodell, das endgültige
Modell, zum Beispiel ein Wasserfallmodell oder eines der agilen
Modelle, die wir noch sehen wollen.
Das ist Prototyp Modell 1.
Prototyp Modell 2 sagt, ich orientiere mich wieder am Phasenmodell und
sehe nach, wo ich diese Prototypen bauen muss.
Also zum Beispiel könnte es sein, dass ich einen Prototyp eines
Teilsystems machen muss, um zu sehen, wie ich die Arbeit verteile.
Stellen Sie sich vor, Sie müssten GIT bauen.
Sie müssten GIT neu bauen.
Und da ist auch die Frage, wie verteile ich denn eigentlich die
einzelnen Komponenten auf die verschiedenen Dienstgeber, auf die
verschiedenen Rechner der Beteiligten?
Ist überhaupt das zuverlässig genug, wenn Leute ihre Rechner abstellen
und wieder mal anstellen?
Was ist denn die Wahrscheinlichkeit, dass ich dann die aktuelle
Software bekomme?
Was muss ich denn da eigentlich machen?
Wo muss ich die Caches anlegen?
Also die Datenverteilung und Verfügbarkeit.
Und da kann es sein, dass Sie dazu einen Entwurf machen, der das ganze
Ein - und Ausbuchen gar nicht richtig kann und viele der Schönheiten
von GIT nicht bietet, aber dafür eben die Datenverteilung prototypisch
implementiert und nachzusehen, ob es überhaupt im Prinzip
funktionieren kann.
Dann würde ich an der Stelle den Prototypen anwerfen, nämlich hier den
Entwurf machen und natürlich eine Implementierung davon.
Oder aber Sie sagen, da brauchen wir eine Benutzerschnittstelle, aber
wie soll denn die eigentlich sein?
Was ist denn eine schöne Benutzerschnittstelle für mein Mobilgerät und
wie sieht das aus für mein Tablett und wie sieht das aus aus meinem
Standrechner oder Tragbahnrechner?
Da mache ich jetzt einen Prototyp für die Benutzerschnittstelle.
Da läuft noch nichts.
Aber die ganzen Interaktionselemente und Anzeigen sind da und ich kann
damit schon zum Kunden gehen und sagen, haben Sie sich das so
vorgestellt?
In der Reihenfolge werden die Daten abgefragt, die Eingaben gegeben,
die Ausgaben geliefert.
Ist es so richtig?
Also machen Sie hier einen Benutzerschnittstellenprototyp, ohne dass
Sie das Gesamtsystem spezifiziert haben und jetzt sehen Sie, warum
Ihnen diese Prototypen helfen.
Sie können sagen, aha, so wollen wir es.
Vielleicht nicht exakt so wie der Prototyp, aber der Prototyp sagt mir
dann, wie ich es richtig machen müsste.
Und dann kann ich das System komplett spezifizieren, wenn ich in den
Wasserfallmodell einsteigen wollte.
Aber es gibt noch mehr.
Es gibt noch das Iterative Versions Modell.
Das zeige ich am besten am Bild.
Beim Prototyp haben Sie jetzt zwei Versionen, den Prototypen und das
echte System.
Iterationsmodell sagt, wir haben mehrere Zwischenschritte, bevor wir
ein Endsystem haben.
Das heißt, wir fügen unserem Produkt nach und nach Funktionalität
hinzu.
Ähnliche Einsatzgebiete wie beim Prototypmodell.
Unsicherheiten gibt es und wir wissen nicht, wie wir sie lösen.
Aber wir versuchen jetzt, mehr zu verwenden als beim Prototypmodell.
Beim Prototypmodell sagen wir ja, wegwerfen, neu programmieren.
Und nur die Erkenntnisse werden übertragen.
Beim Iterativmodell sagt man, ich baue schon Software, die nachher
auch benutzt werden wird und erweiter sich Schritt für Schritt.
Da gibt es jetzt zwei Ansätze.
Das eine heißt evolutionär und inkrementell.
Das ist nicht richtig deskriptiv, aber ich kläre es Ihnen am Beispiel.
Also Iterative Modelle orientieren sich ebenfalls am Wasserfall.
Aber die sagen, wir planen hier oben mehrere Iterationen, sagen wir
drei Stück.
Und zwar sagen wir, wir haben drei Ausbaustufen des Systems.
Version 1 hat den Funktionsumfang und Version 2 einen erweiterten und
der dritte enthält den endgültigen Funktionsumfang.
Und wir gehen jetzt hier und entwickeln nach dem Wasserfallmodell
einfach Version 1.
Gehen in eine Art Test, den der Betrieb und Evaluierung schon ist.
Sind wir jetzt damit fertig?
Wenn nicht, dann entwerfen und implementieren wir Version 2 und erneut
gehen wir zurück und sagen, dann machen wir auch noch eine dritte
Ausbaustufe.
Der Punkt ist, bei der iterativen Version sind alle Ausbaustufen
vorgeplant.
Im Gegensatz zum Evolutionären, da sagen wir, wir planen nur immer
einen nächsten Schritt vorwärts, eine nächste Version und wenn wir
noch nicht zufrieden sind, dann gehen wir nochmal ganz in den Anfang
zurück und planen den Rest.
Entschuldigung, planen die nächste Ausbaustufe.
Hier sagen sie also schon, ich weiß, was ich alles machen muss, aber
ich liefere in drei Phasen, drei Stufen und der sagt, wir wissen ein
bisschen was, wir können mal die erste Version liefern und die zweite
überlegen wir uns überhaupt erst später.
Es gibt natürlich auch so ein Zwischending, da sage ich, gehe ich in
die Definition zurück, aber auch das ist das evolutionäre Modell.
Wichtig ist, inkrementell sagt, alle Versionen sind vorausgeplant, in
voller Schönheit und wir fügen sie nur nach und nach hinzu.
Das funktioniert am besten, wenn die Unsicherheiten im Entwurf oder in
der Implementierung stecken.
Das Evolutionäre Modell fängt immer von vorne an und sagt, wenn da
etwas komplett verkehrt war, dann können wir es hier oben auch schon
in der Systemdefinition ändern.
Sind wir mit dem Modell auch schon durch?
Gibt es dazu Fragen vielleicht?
Dann gehen wir zum Microsoft-Modell.
Das kam 1995 heraus, das ist auch schon wieder 20 Jahre alt.
Synchronisiere und Stabilisiere oder Synchronize und Stabilize.
So hat Microsoft das 1995 gemacht.
Da gibt es ein dickes Buch von Herrn Cusumano und Selby.
Und natürlich wollte jeder wissen, wie Microsoft das macht, denn das
war auch damals einer der führenden Softwarehersteller.
Wie macht Microsoft das eigentlich, wenn die ein neues Produkt geben?
Und ich kann es Ihnen ganz kurz sagen, es ist eine Variante des
iterativen Prototypmodells.
Schauen wir uns das genau an.
Das Problem ist, Sie haben ungefähr 200 Programmierer, manchmal auch
mehr, für das Betriebssystem sind es noch viel mehr.
Sie teilen sich auf in kleinere Teams und geben Ihnen viel Freiheit,
damit Sie Ihre eigenen Ideen verwirklichen können.
Aber Sie synchronisieren regelmäßig, damit ein Gesamtsystem entsteht,
das auch funktioniert.
Und zwar heißt es regelmäßig jede Nacht.
Jede Nacht wird das Gesamtsystem neu übersetzt, egal was es ist, ob es
jetzt Word ist oder Office oder Windows, irgendwas, wird jede Nacht
übersetzt.
Dazu haben Sie riesige Rechenparks.
Dann gibt es eine Stabilisierungsphase, die ist auch regelmäßig, zwar
nicht jede Nacht, aber in drei Monaten, da werden dann verbleibende
Fehler heraus operiert.
Die drei Phasen, die wir haben, sind eine Planungsphase, das ist
tatsächlich so wie das inkrementelle Prototypmodell, da werden die
Phasen, das ist die Planungsphase, aber die werden drei
Entwicklungsphasen geplant, in drei Subprojekten und danach erfolgt
nochmal eine Stabilisierungsphase.
Jeder dieser drei Entwicklungsphasen hat selbst wieder eine
Stabilisierungsphase eingebaut.
Grafisch gesehen sieht es so aus, hier vorne ist die Planungsphase,
dann kommt eine erste Entwicklungsphase, das schauen wir uns gleich
an, dann eine zweite und eine dritte und dann schließlich die
Stabilisierungsphase.
Schauen wir mal, was es hier alles gibt.
Wo fangen wir an?
Vielleicht mit den Dokumenten hier in der Planungsphase.
Sie sehen, hier geht es noch weiter, da ist die Entwicklungsphase
Nummer drei und hier die Stabilisierungsphase hinten.
Schauen wir uns das mal an.
Am Anfang steht dieses sogenannte Vision Statement, könnte man als
Wunschbild bezeichnen.
Was wollen wir machen?
1995 war das Web noch jung, da könnte man also sich zum Beispiel einen
Webbrowser vorstellen und den als Wunschbild machen und von einem
Netscape abkopfern und sagen, so wollen wir es auch haben und noch
besser.
Das könnte das Wunschbild sein.
Also identifiziere und provisiere Produkteigenschaften aufgrund
umfangreicher Sammlung von Kundenwünschen.
Da gibt es noch mal mehr als 30% Änderungen während der
Projektlaufzeit.
Das wollen die auch, will Microsoft auch machen, dass sie trotzdem,
dass ein Produkt Entwicklung ist, dass man noch rasch reagieren kann
auf Neuerungen oder auch Erfindungen anderer Konkurrenten.
Die Spezifikation kommt raus.
Manager, Entwickler definieren die Funktion, Architektur und
Komponentenabhängigkeit anhand des Wunschbildes.
Dann gibt es einen Zeitplan an Teamstruktur, Aufteilung der Aufgaben
von Produktfunktion, Gruppen, Idee, eine Manager, drei bis acht
Entwickler und genauso viele Tester.
Das war auch etwas Unerhörtes.
Wenn Sie ein Team haben mit acht Entwicklern, haben Sie darin auch
acht Tester.
Genauso viele Tester wie Entwickler.
Die tun nichts anderes als testen.
Hätte ich auch manchmal gerne, dass ich noch einen Tisch neben mir
habe, der nichts anderes tut als testen, wenn ich da was schreibe.
Kann ich mir nicht leisten, aber Microsoft kann das.
So eine Phase dauert, diese erste Planungsphase dauert ungefähr drei
bis zwölf Monate.
Das ist ziemlich lang, wenn Sie sich überlegen.
Das ist also nicht so zwei Stunden oder vielleicht nur Nachmittag oder
ein Übungsblatt, sondern das ist drei Monate bis zum ganzen Jahr, bis
so ein Plan steht.
Tester arbeiten natürlich den Entwicklern zu, die Manager
koordinieren.
Wir haben drei Meilensteine und es ist ungefähr aufgeteilt in erstes
Drittel, zweites Drittel, drittes Drittel.
Mehr Vorgabe gibt es da nicht.
Im letzten Drittel sagt man eben, die unwichtigsten Funktionen werden
das erste Drittel, die wichtigsten geplante Funktionalität hat.
Aber wenn es dann schon etwas Neues gibt, kann ich vielleicht im
zweiten oder dritten Drittel schon darauf reagieren und sagen, ah, das
können wir auch.
Diese Funktionalität, was für sich Rechtschreibprüfung das fügen wir
auch gleich mit hinzu.
Arbeiten mit Versionskontrollsystem, auch wie gesagt schon 1995 war
noch relativ primitiv, aber hatten sie.
Einbuchen in der Regel zweimal pro Woche.
Das heißt, sie können nicht hergehen und sagen, ich komme hier nicht
weiter und tüftle vor mich hin und dann einen Monat später sage ich,
jetzt wäre ich soweit, das geht nicht.
Sie müssen zweimal die Woche liefern, an dem, was sie arbeiten.
Nächtlich vollständig neu übersetzen aller Quellen, hatte ich schon
erwähnt.
Dann gibt es den automatischen Regressionstest.
J-Unit gab es da noch nicht, aber die Regressionstests laufen
automatisch ab, wie man das will.
Und das Verursachen von Integrationsfehlern wird geahndet.
Das heißt also, sie geben etwas ab und das bewirkt, dass das
Gesamtsystem irgendwie nicht mehr funktioniert.
Ihr Problem ist der Fehler.
Und das muss sofort behoben werden, da sie andere Entwickler
aufhalten.
Sie wissen, sie haben heute was abgeliefert, heute Nacht wurde
übersetzt.
Es hat vielleicht gar nicht übersetzt, wegen Ihnen, oder aber es hat
übersetzt und Sie haben geladen und das System läuft nicht, wegen
Ihnen.
Dann muss was passieren.
Und zum Ende jeden Subprojekt, es werden alle entdeckten Fehler
beseitigt.
Das ist die Subprojektstabilisierung.
Dann kommt die Auslieferung.
Am Schluss kommt natürlich noch die Stabilisierungsphase.
Da gibt es, das ist auch eine Erfindung von Microsoft, die sogenannten
Beta -Tester.
Alpha-Tester sind im Haus.
Beta-Tester sind Sie und ich.
Wir dürfen, wenn wir brav sind, dann dürfen wir schon die unfertige
Software testen und für Microsoft freie Arbeit leisten, damit sie
sagen, wir finden für Sie Fehler, damit wir es fertig machen.
Das ist toll, dass es Menschen gibt, die das machen wollen.
Auch das wünsche ich mir manchmal, dass ich nicht nur einen Tichy-Klon
habe, sondern auch noch eine Schar von Leuten, die mich so bewundern,
sagen, ja Tichy, darf ich Ihre Software testen?
Macht man nur mit Microsoft natürlich sowas.
Das sind die Beta-Tester.
Dann erfolgt eben Vorbereitung auf die Auslieferung.
Das heißt, sagen Sie, jetzt wird das eingefroren, was wir haben, dann
gibt es ein DVD oder CD, Kopie davon, die wird festgehalten und die
Dokumentation und Anleitungen für den Druck aufbereitet und dann
werden eben schließlich und endlich diese Kisten produziert, die mit
Anleitungen, CDs, DVDs sind.
Hat sich heute auch wieder ein bisschen geändert.
Heute liefert man natürlich alles übers Internet, soweit das geht.
Aber man kann natürlich auch Boxen mit Software kaufen.
Das dauert etwa drei bis acht Monate.
Also so etwa ist der Zeitplan.
Drei bis zwölf Monate für die Planung, das hatten wir schon.
Die Stabilisierungsphase am Schluss, drei bis acht Monate, auch etwa.
Und dazwischen diese dreieinhalb Projekte, jeweils zwei bis vier
Monate lang, also ein Vierteljahr etwa.
Und da machen wir sechs bis zehn Wochen kodieren, optimieren, testen,
Fehlersuche, stabilisieren.
Dann gibt es einen Integrationstest, zwei bis fünf Wochen und dann
fünf Wochen Pufferzeit zur Stabilisierung.
Stabilisierung ist immer das Wort für Fehler finden.
So läuft das und dann haben Sie also eine komplette Produktentwicklung
in sechs bis zwölf Monaten.
Wollen wir nochmal aufs Bild zurückgehen und schauen, ob wir was
vergessen haben.
Das war also hier
noch eines.
Jetzt sind wir da, das hatte ich vorhin gezeigt.
Also schauen wir uns nochmal die Planungsphase an, drei bis zwölf
Monate.
Da gibt es das Visionstatement, die Spezifikationen, die Prototypen,
falls sie benötigt werden, auch das kann vorkommen.
Design, Machbarkeitsstudien, Testingstrategie wird festgelegt und ein
Plan wird festgelegt.
Hier gibt es so einen Punkt, wo man sagt, jetzt ist der Plan
vollständig.
Da gibt es ein Review hier unten des Gesamtplans.
Also, Sie wissen schon, was Sie wollen und dann gibt es diese drei
Unterprojekte und die sind jetzt aufgeteilt in Code und Optimierung
testen und Integration und Wiedertesten und nochmal Pufferzeit für
Stabilisierung.
Und das wiederholt sich jetzt dreimal.
Dann sind wir hier unten, Moment, Milestone 1, das ist das erste,
zweite Drittel, drittes Drittel, dann kommt ja die nochmal so
eine...Moment, habe ich das verkehrt gemacht?
Entschuldigung, das ist nochmal ein Duplikat.
Also hier sind wir fertig mit den drei Subprojekten und dann kommt die
Vorbereitung auf die Freigabe und die Stabilisierung davor.
Code Complete ist also dieses Schlagwort.
Code Complete, wir haben erreicht Code Complete, das heißt, alle, Code
ist entwickelt und das Ergebnis ist eingefroren.
Dann gibt es noch eine Stabilisierungsphase, nochmal eine
Stabilisierungsphase und dann die sogenannte Zero Bug Release.
Das heißt, alle, heißt nicht Null Fehler, sondern Null bekannte
Fehler.
Ein großer Unterschied.
So, gibt es dazu Fragen?
Ja, also Sie sehen schon, es wird immer mehr iterativ gemacht, es wird
nicht mehr alles geplant, sondern es wird durchaus hier in diesen
Unterprojekten der Plan geändert, erweitert und was hinzugefügt.
Und das will ja Microsoft erreichen, nämlich schnell reagieren zu
können auf Markterfordernisse.
Ja, da gibt es eine Frage?
Ja, ich kann Ihnen schon, da müssten Sie aber dieses Buch von Kusumano
und Selbe lesen.
Ich weiß jetzt nicht, ob das aussagekräftige Informationen liefert, zu
dem Zeitpunkt, aber es liefert sehr viel Daten.
Es ist wirklich ein dickes Buch und ich handle das ab in fünf Folien
oder so.
Aber da können Sie gerne nachschauen.
Ich würde aber nicht behaupten wollen, dass Microsoft das immer so
macht.
Ich weiß gar nicht, wie Microsoft 20 Jahre später das macht.
Machen die das noch?
Oder nehmen sie inzwischen auch Scrum oder Extreme Programming, was
wir noch behandeln werden?
Aber für uns ist es, glaube ich, ein wichtiges Modell, das sagt, aha,
so kann man das auch organisieren.
Weil wir eben irgendwie eine klare Struktur bekommen damit und damit
auch klarer wird, wer wann was zu tun hat.
Und auch ein zeitliches Gerüst.
Und wenn Sie mit Microsoft konkurrieren wollen, dann ist es gut zu
wissen, wie die das machen.
Man sollte immer wissen, was die Konkurrenz macht.
Aber vielleicht wollen Sie ja dafür arbeiten.
Also, Pro.
Es ist effektiv durch kurze Produktzyklen, halbes bis ganzes Jahr,
kann ich
in relativ kurzen Abständen ein neues Produkt herausbringen.
Ich habe eine Projizierung der Funktionen, Sie erinnern sich, die
wichtigsten Funktionen, die zentralen Funktionen kommen in die erste
Iteration.
Sie haben damit auch eine natürliche Modulisierung nach Funktionen des
Gesamtsystems.
Ich habe einen Fortschritt, ohne dass ich eine komplette Spezifikation
brauche.
Ich kann mit dem arbeiten, was ich weiß, in der ersten Phase.
In der zweiten Phase kann ich hinzufügen, was ich noch brauche.
Der Hauptvorteil, der im Buch von Kusumano und immer wieder
herausgestrichen wird, ist eben, dass viele Leute arbeiten, als wären
sie in einem kleinen Team.
Wir wissen aber, ein paar Fragen sind da noch offen.
Nämlich, wie sich die kleinen Teams untereinander abstimmen.
Das ist nicht ganz klar.
Und Rückmeldungen, Konkurrenzideen, konkurrierende Ideen können sehr
schnell einfließen.
Allerdings, wie ich es gerade erwähnt hatte, ist noch offen, wie sich
die vielen Teams untereinander abstimmen.
Und da gibt es in der Tat Architekturprobleme.
Haben Sie einen Entwurf irgendwo gesehen?
Ich habe ihn nicht gesehen.
Entsprechend ist das System oftmals sehr unsauber strukturiert.
Man hat mangelhafte Fehlertoleranz.
Es gibt kein Lernen über Teamgrenzen hinweg.
Es wird ja nichts dokumentiert, außer das, was ich für die Software
selbst brauche.
Und was ein bisschen in die Richtung Ihrer Frage geht, ist Guzman und
Selvi beobachten, dass also in so einem Projekt innerhalb von 18
Monaten 50% des Codes weggeworfen wurden und ersetzt wurden.
Wie soll ich das jetzt interpretieren?
Das heißt wohl, dass sie zum einen schnell programmieren, aber wohl
auch viel für die Tonne ist.
Dass viel weggeworfen werden muss.
Das ist eine Vergleichsfolie, die ist eigentlich mehr zum Lernen
gedacht, das bespreche ich jetzt nicht durch.
Phasenmodell und Synchronize und Stabilize verglichen.
Jetzt bin ich doch ziemlich weit gekommen.
Dann machen wir lieber das nächste Mal weiter.
Vielen Dank.