WEBVTT 00:06.990 --> 00:11.450 Wir sind jetzt mit dem Testen noch länger nicht fertig. 00:11.630 --> 00:14.490 Ich hoffe, dass ich kann das Kapitel heute komplett machen. 00:14.630 --> 00:19.010 Dann machen wir als nächstes die Prozessmodelle und dann schauen wir 00:19.010 --> 00:22.990 noch, ob wir die übrigen zwei Kapitel noch reinkriegen, nämlich die 00:22.990 --> 00:24.190 Aufwandsschätzung zum Beispiel. 00:27.470 --> 00:31.310 Eigentlich ist das, was ich jetzt zu sagen habe, für Automaten total 00:31.310 --> 00:32.030 einfach. 00:33.390 --> 00:37.170 Wenn Sie einen Automaten testen, dann teste man alle 00:37.170 --> 00:38.050 Zustandsübergänge. 00:42.510 --> 00:47.190 Also man teste alle Übergänge und zwar so mindestens einmal, das ist 00:47.190 --> 00:50.350 so ähnlich wie bei den Kanten in einem Datenflussgraf oder 00:50.350 --> 00:51.810 Kontrollflussgrafen, viel mehr. 00:52.770 --> 00:56.950 Allerdings ist es noch nicht so vollständig, dass Sie noch nicht alle 00:56.950 --> 01:00.570 Zweige überdeckt haben, denn die Methoden, die dabei aufgerufen 01:00.570 --> 01:03.290 werden, können natürlich mehrere Zweige enthalten und das heißt, Sie 01:03.290 --> 01:06.810 müssen dann für die Zweigüberdeckung möglichst noch weitere Testfälle 01:06.810 --> 01:09.230 hinzunehmen. 01:10.070 --> 01:13.030 Aber zunächst einmal ist das Hauptziel, dass man sagt, in einem 01:13.030 --> 01:16.630 Automaten alle Übergänge testen, von jedem Zustand in jedem 01:16.630 --> 01:21.870 Zielzustand, der möglich ist, und die entsprechende Aktion dabei 01:21.870 --> 01:23.250 prüfen, ob sie ausgeführt wird. 01:24.050 --> 01:26.350 Das ist also ein Überdeckungskriterium, wie wir es auch von Ihnen 01:26.350 --> 01:29.050 schon kennen, nur diesmal angewandt. 01:33.110 --> 01:36.890 Damit Sie wissen, ob der zusätzliche Zustand auch wirklich erreicht 01:36.890 --> 01:40.810 worden ist, müssen Sie möglicherweise eine Ausgabe einbauen oder ein 01:40.810 --> 01:44.050 Assert, das sagt, jetzt müsste ich im Zustand so und so sein. 01:44.570 --> 01:46.330 Aber das wissen wir ja, wie das geht. 01:46.750 --> 01:48.590 Mit JUnit lässt sich das leicht veranstalten. 01:49.470 --> 01:52.570 Man spricht beim Testen von Zustandsautomaten von einem Alpha-Omega 01:52.570 --> 01:53.070 -Zyklus. 01:53.390 --> 01:55.730 Das ist ähnlich wie ein vollständiger Pfad durch einen 01:55.730 --> 01:59.610 Kontrollflussgrafen, nämlich der Alpha-Zustand ist der Initialzustand 01:59.970 --> 02:03.030 und ein Omega-Zustand ist einer der Endzustände. 02:03.130 --> 02:04.870 Wenn es mehrere gibt, habe ich natürlich mehrere. 02:09.650 --> 02:12.710 Bei den Endzuständen ist dann immer zu überprüfen, was passiert 02:12.710 --> 02:17.750 eigentlich mit den Daten, die dynamisch angelegt wurden. 02:17.850 --> 02:19.050 Werden die auch freigegeben? 02:19.170 --> 02:25.690 Werden nicht noch Referenzen gehalten, die vermeiden, dass die 02:25.690 --> 02:28.190 automatische Speicherbereinigung die Objekte beseitigt? 02:30.370 --> 02:33.610 Dann gibt es die Finalize-Methoden, die aufgerufen werden, wenn ein 02:33.610 --> 02:34.910 Objekt beseitigt wird. 02:37.530 --> 02:40.410 Und die Finalize-Methode läuft nur, wenn ein Objekt tatsächlich 02:40.410 --> 02:41.210 freigegeben wird. 02:41.650 --> 02:43.930 Und möglicherweise läuft die Finalize-Methode nicht, weil noch 02:43.930 --> 02:46.730 irgendjemand an irgendeiner Stelle einen anderen Verweis auf das 02:46.730 --> 02:47.250 Objekt hat. 02:48.120 --> 02:50.190 Schwache Referenzen brauchen wir jetzt nicht. 02:51.170 --> 02:54.650 Da kommt ein Beispiel, aber das können Sie gerne selber durchdenken. 02:55.710 --> 03:00.750 Als nächstes kommen ganz kurz die sogenannten Leistungstests. 03:00.870 --> 03:04.550 Da gibt es zwei Typen, nämlich den Last-Test und den Stress-Test. 03:04.950 --> 03:07.470 Die sind genauso, wie sie benannt sind. 03:09.090 --> 03:13.400 Der Last-Test lässt das System im erlaubten Grenzbereich laufen. 03:15.940 --> 03:18.500 Betonung auf erlaubt und Grenzbereich. 03:18.720 --> 03:22.320 Das heißt, Sie möchten wissen, ob das System die genannten 03:22.320 --> 03:28.540 Nutzerzahlen bedienen kann, garantierte Antwortzeiten einhalten kann, 03:28.560 --> 03:32.220 selbst wenn das System unter Last steht, und kann diese Last auch 03:32.220 --> 03:33.620 beliebig lange bewältigt werden. 03:35.440 --> 03:37.320 Dazu macht man eben diese Last-Tests. 03:37.500 --> 03:40.880 Und das heißt, dazu muss man sich natürlich auch Gedanken darüber 03:40.880 --> 03:44.820 machen, wie diese Last erzeugt wird. 03:46.180 --> 03:49.060 Die kann ich nicht durch manuelle Eingaben erzeugen, sondern auch das 03:49.060 --> 03:52.940 muss dann ein automatisch ablaufender Test sein, der eben unter 03:52.940 --> 03:57.480 Umständen mit mehreren anderen Maschinen arbeitet, um diese Last zu 03:57.480 --> 03:59.100 erzeugen, oder auf der gleichen Maschine. 04:01.440 --> 04:05.620 Wissen wir natürlich, ob das zu bejahen ist, diese Anforderungen über 04:05.620 --> 04:11.420 die Lastbewältigung, ob die erfüllt sind, und ob es irgendwelche 04:11.420 --> 04:16.580 Flaschenhälse gibt, wo eben eine Verlangsamung eintritt. 04:18.000 --> 04:21.200 Der Stresstest hingegen sagt so, und jetzt machen wir noch einen 04:21.200 --> 04:26.420 Lasttest, aber einen Lasttest, der über die geplante Grenze 04:26.420 --> 04:30.380 hinausgeht, um zu sehen, wie das System im Überlastbereich sich 04:30.380 --> 04:33.640 verhält, denn da kann es zu Überraschungen kommen. 04:34.520 --> 04:35.740 Wie ist das Leistungsverhältnis? 04:35.740 --> 04:39.540 Das könnte so sein, dass man das sogenannte Seitenflattern hat, dass 04:39.540 --> 04:42.980 sich so viele Daten im Hauptspeicher halten muss, dass Permanentdaten, 04:43.740 --> 04:46.540 Seiten aus dem Hauptspeicher und dem Hintergrundspeicher hin- und 04:46.540 --> 04:47.620 hergeschoben werden müssen. 04:50.420 --> 04:54.120 Sie wissen ja, der Hauptspeicher bei großen Anwendungen ist meistens 04:54.120 --> 04:57.560 kleiner als der virtuelle Speicher, mit dem eine Anwendung läuft, und 04:57.560 --> 05:04.280 der Speicherbereich wird aufgeteilt in Pixel-Elemente, die nennt man 05:04.280 --> 05:09.860 Seiten, und die werden im Hauptspeicher ausgelagert, wenn dazu zu 05:09.860 --> 05:12.600 wenig Platz ist, und dann andere von der Platte hereingeholt, und wenn 05:12.600 --> 05:16.860 das passiert, dann wandern die Seiten permanent hin- und her, und 05:16.860 --> 05:18.560 damit verlangsamt sich das System. 05:19.640 --> 05:23.100 Es kann auch sein, dass im Überlastbereich plötzlich ein 05:23.100 --> 05:27.640 exponentielles Ansteigen der Antwortzeiten ergibt, aus welchen Gründen 05:27.640 --> 05:31.920 auch immer, irgendwelche Flaschenhälse, die eine Verlangsamung 05:31.920 --> 05:35.620 verursachen, oder total als Stillstand, dass gar nichts mehr geht. 05:38.040 --> 05:42.220 Dann möchte man natürlich auch wissen, naja, Stillstand wollen wir auf 05:42.220 --> 05:47.020 keinen Fall haben, wir wollten zeigen, der Antwortzeit ist natürlich 05:47.020 --> 05:53.640 dann selbstverständlich zu erwarten, aber kein exponentielles, und 05:53.640 --> 05:56.440 dann wollen Sie auch wissen, und wenn die Last jetzt wieder nachlässt, 05:57.720 --> 06:00.780 wann kehrt das System in einen normalen Zustand zurück und läuft 06:00.780 --> 06:06.320 wieder richtig auch im Lastbereich. 06:08.320 --> 06:09.940 Also, das sind zwei einfache Konzepte. 06:12.160 --> 06:15.040 Das Nächste sind die manuellen Prüfungen, da haben Sie, diejenigen, 06:15.160 --> 06:20.440 die in der Übung waren, ja schon eine Übung durchgeführt, wie eine 06:20.440 --> 06:21.580 Inspektion abläuft. 06:22.100 --> 06:25.060 Das besprechen wir jetzt nochmal kurz durch, ich verlasse mich also 06:25.060 --> 06:26.600 darauf, dass Sie das Beispiel schon kennen. 06:30.380 --> 06:35.180 Die manuellen Prüfmethoden sind so, dass man Anforderungsdokumente, 06:35.300 --> 06:39.180 Entwürfe oder Quellcode per Hand inspiziert. 06:39.320 --> 06:41.520 Per Hand heißt es natürlich mit Augen. 06:43.020 --> 06:49.220 Und dazu gibt es sogenannte Inspektionsteams und zwei andere Methoden, 06:49.300 --> 06:51.400 die ich Ihnen zeige, die sind aber alle sehr ähnlich. 06:52.080 --> 06:56.060 Die Idee ist eben, dass man anstelle eines ablaufenden Tests, der 06:56.060 --> 06:58.680 vollautomatisch abläuft, an den ich natürlich für eine Anforderung 06:58.680 --> 07:02.200 oder einen Entwurf nicht einsetzen kann, dass ich das stattdessen 07:02.200 --> 07:03.600 manuell mache. 07:04.640 --> 07:08.020 Der Aufwand für diese, wenn man es richtig macht, die sogenannten 07:08.020 --> 07:10.320 Inspektionen, können bis zu 20 Prozent sein. 07:13.180 --> 07:16.300 Die Zeit für die Prüfungen muss eingeplant sein, sonst ist sie nie 07:16.300 --> 07:17.120 vorhanden. 07:17.840 --> 07:22.100 Und wir müssen darauf achten, dass Leute nicht schlecht gemacht werden 07:22.100 --> 07:22.800 für ihre Arbeit. 07:23.400 --> 07:26.780 Also der psychologische Druck, das Einzelne durch eine Gruppe, muss 07:26.780 --> 07:27.380 vermieden werden. 07:27.940 --> 07:30.520 Der Einzelne, der Software entwickelt hat, ist nicht auf der 07:30.520 --> 07:34.800 Anklagebank, bist du blöd, warum hast du sowas gemacht, sowas sagt man 07:34.800 --> 07:42.460 nicht, sondern man hält sich rein an die Defekte, die zu finden sind. 07:42.840 --> 07:44.940 Also die Arbeit wird begutachtet, nicht die Person. 07:45.660 --> 07:46.640 Und alle kommen dran. 07:47.840 --> 07:49.600 Das nimmt auch mal den Stress heraus. 07:50.820 --> 07:54.660 Wenn auch die Älteren, besseren, professionelleren schon können, dann 07:54.660 --> 07:58.460 ist das nicht nur ein Mangel, den man einem Neuling zumutet. 08:01.100 --> 08:05.920 Dabei sollten aber keine Kunden, keine höheren Manager anwesend sein, 08:06.060 --> 08:09.340 denn höhere Manager haben Personalverantwortung und da bekommt jeder 08:09.340 --> 08:09.880 Angst davor. 08:11.460 --> 08:13.180 Dann funktionieren sie auch nicht mehr. 08:16.480 --> 08:21.160 Auf Ablauf tun die Softwareinspektionen, so wie Sie es schon gesehen 08:21.160 --> 08:25.860 haben, wir nehmen zwei bis acht Inspektoren, acht ist allerdings etwas 08:25.860 --> 08:30.940 übertrieben, sie werden zu zweit gemacht in der Übung, untersuchen 08:30.940 --> 08:34.260 unabhängig, zunächst mal unabhängig voneinander, das war also nicht so 08:34.260 --> 08:37.840 wie in der Übung, dasselbe Artefakt, das könnte ein Programm sein, das 08:37.840 --> 08:41.520 könnte ein Testfälle sein, könnte eine Entwurf sein, könnte eine 08:41.520 --> 08:42.260 Anforderung sein. 08:43.760 --> 08:47.180 Die gefundenen Defekte werden aufgeschrieben, notiert und 08:47.180 --> 08:48.860 durchgesprochen im Team. 08:50.540 --> 08:53.300 Das Hauptaugenmerk ist, Probleme zu identifizieren. 08:54.180 --> 08:57.340 Die Lösung macht man später, wer ist derjenige, der dafür 08:57.340 --> 08:58.040 verantwortlich ist. 08:58.220 --> 09:01.200 Also es wird nicht gleich korrigiert, sondern nur notiert, was 09:01.200 --> 09:01.780 verkehrt ist. 09:03.100 --> 09:07.540 Für diese Prozesse gibt es dann Rollen und Formulare, da gibt es 09:07.540 --> 09:13.840 Leute, die etwas vorbereiten, das werden wir dann gleich sehen, die 09:13.840 --> 09:18.540 die eigentliche Arbeit durchführen und es gibt Prüflisten und 09:18.540 --> 09:19.620 sogenannte Perspektiven. 09:19.680 --> 09:21.600 Die Perspektiven werden wir diesmal auch überspringen. 09:24.120 --> 09:32.060 Also es gibt im Wesentlichen drei oder vier von diesen Methoden. 09:32.600 --> 09:36.460 Das erste, das oberste, nenne ich mal die Inspektion, englisch 09:36.460 --> 09:37.500 natürlich Inspection. 09:38.540 --> 09:42.900 Da wird überprüft, aber nicht einfach so, sondern anhand von 09:42.900 --> 09:43.440 Prüflisten. 09:44.120 --> 09:48.880 Das ist so ähnlich, wenn Sie zum TÜV fahren, weiß nicht, ob Sie schon 09:48.880 --> 09:52.300 mal waren, aber der geht auch nach bestimmter Prüfliste vor und muss 09:52.300 --> 09:57.020 die verschiedenen Dinge wie Zündung und Bremsen und Scheibenwischer 09:57.020 --> 10:00.400 und was da alles zu prüfen ist, das macht er nicht einfach frei 10:00.400 --> 10:02.640 Schnauze, sondern hat eine klare Prüfliste vor sich. 10:03.000 --> 10:05.020 Genauso geht das mit den Inspektionen. 10:05.160 --> 10:07.280 Da bekommen Sie Prüflisten, die ist angepasst auf die 10:07.280 --> 10:10.640 Programmiersprache, die Programmierumgebung, so dass Sie nichts prüfen 10:10.640 --> 10:13.980 müssen, was die Compiler und sonstige die Prüfumgebung selbst 10:13.980 --> 10:14.840 automatisch macht. 10:15.580 --> 10:18.200 Das ist die formalisierteste Form. 10:19.680 --> 10:24.140 Prüflisten ist das eine, das andere wäre sogenannte Lesetechniken, da 10:24.140 --> 10:29.360 stellt man sich vor, man wäre zum Beispiel ein Softwarewarter, der 10:29.360 --> 10:32.520 sagt, ist diese Software überhaupt wartbar, verstehe ich, was sie tut, 10:32.640 --> 10:33.900 ist sie ordentlich dokumentiert? 10:34.560 --> 10:35.940 Das ist eine bestimmte Perspektive. 10:36.400 --> 10:40.140 Oder ein Tester, der sagt, wenn ich dieses System jetzt testen müsste, 10:40.140 --> 10:41.920 ginge das überhaupt? 10:42.780 --> 10:46.000 Und dann bekommt man zusätzliche Fragen, die diese unterschiedlichen 10:46.000 --> 10:48.880 Lesetechniken aus einem bestimmten Blickwinkel 10:52.020 --> 10:53.800 vorschreiben und die man dann durchführen soll. 10:55.340 --> 10:59.500 Dann gibt es die unterste Qualitätsstufe, der sogenannte Walkthrough 10:59.500 --> 11:04.940 oder auch Durchsicht, da gibt es überhaupt keine Regeln, sondern Sie 11:04.940 --> 11:07.560 setzen sich mit einem oder mehreren anderen Kollegen zusammen als 11:07.560 --> 11:10.820 Entwickler und stellen ihnen das vor, was sie geschrieben haben. 11:10.900 --> 11:15.380 Sie erzählen also quasi ihr Programm nach oder gehen mit ihnen durch 11:15.380 --> 11:18.300 eine Anforderung hindurch, Anforderungsdokument oder erklären, warum 11:18.300 --> 11:19.920 sie den Turf so und so gemacht haben. 11:20.440 --> 11:22.900 Da gibt es keine Prüflisten, Checklisten oder sonst etwas. 11:24.900 --> 11:27.680 Aber sie kennen den Effekt, dadurch, dass sie etwas erklären müssen, 11:27.800 --> 11:31.020 fällt ihnen unter Umständen etwas auf und dann sagen, oh, da habe ich 11:31.020 --> 11:31.620 hier was vergessen. 11:31.960 --> 11:35.460 Die anderen, die zuhören, sagen, ich verstehe nichts, aber es wird 11:35.460 --> 11:36.140 schon richtig sein. 11:38.420 --> 11:42.040 Die Kollegen stellen also Fragen, machen Anmerkungen und 11:42.040 --> 11:46.800 Verbesserungen, aber ohne weitere Vorschriften. 11:47.800 --> 11:51.000 Also gibt es natürlich Defekte, die zu suchen sind, aber auch der 11:51.000 --> 11:55.320 Stil, die Namensgebung, die eingehalten werden muss, andere 11:55.320 --> 11:57.360 Entwicklungsstandards und so fort. 11:58.280 --> 12:02.800 Dazwischen liegt Review oder auch Deutsch könnte man sagen 12:02.800 --> 12:05.640 Überprüfung, die meisten sagen Review bei uns. 12:07.000 --> 12:13.180 Also es ist etwas mehr als die Durchsicht, etwas mehr formalisiert mit 12:13.180 --> 12:18.020 klaren Rollen für die einzelnen Teilnehmer, aber auch zur Überprüfung 12:18.020 --> 12:21.500 von schriftlichen Dokumenten durch einen Externen. 12:22.600 --> 12:23.640 Einen oder mehrere Externe. 12:26.120 --> 12:27.960 Was kann ich dazu jetzt noch sagen? 12:28.440 --> 12:31.340 Ah ja, hier ist eine Definition, übersetzt aus dem ANSI-Standard. 12:31.660 --> 12:35.380 Die Inspektion ist eine formale Qualitätssicherungstechnik, bei der 12:35.380 --> 12:42.020 Anforderungen Entwurf oder Code eingehen, ob eine verschiedene Person 12:42.020 --> 12:45.060 oder eine Gruppe von Personen begutachtet werden. 12:45.840 --> 12:48.400 Zweck ist das Finden von Fehlern, Verstößen gegen 12:48.400 --> 12:50.420 Entwicklungsstandards und andere Probleme. 12:52.640 --> 12:55.000 Das ist die ANSI-Definition. 12:56.060 --> 12:58.260 Was sind Vor- und Nachteile von Inspektionen? 12:58.440 --> 13:03.480 Naja, natürlich will man Fehler finden, aber die Technik ist anwendbar 13:03.480 --> 13:05.540 auf alles, was gemacht wird, nicht nur den Code. 13:06.620 --> 13:08.800 Wir können sie sogar auf Testfälle anwenden, wenn sie wollen. 13:09.600 --> 13:11.920 Wir können auch die Testfälle inspizieren, insbesondere einen 13:11.920 --> 13:12.660 Abnahmetest. 13:13.480 --> 13:15.180 Jederzeit und frühzeitig durchführbar. 13:15.620 --> 13:17.400 Wir müssen nicht warten, bis das Programm fertig ist. 13:18.100 --> 13:18.940 Und sie sind sehr effektiv. 13:20.200 --> 13:23.020 Nachteil ist natürlich, sie sind manuell, sind daher aufwendiger als 13:23.020 --> 13:26.060 ein Programm, das abläuft, verbraucht die Zeit mehrere Mitarbeiter, 13:26.520 --> 13:27.760 ist somit erstmal teurer. 13:28.700 --> 13:34.800 Es ist zum Testen kein Ablauf, der läuft, also nicht dynamisch, 13:34.940 --> 13:35.580 sondern statisch. 13:35.680 --> 13:39.340 Man muss also statische Prüfmethoden im Kopf anwenden. 13:40.660 --> 13:43.660 Die Frage, die sich Ihnen jetzt natürlich stellt, ist, und rentiert 13:43.660 --> 13:44.120 sich das? 13:44.720 --> 13:46.840 Ist das sinnvoll, dieser Aufwand? 13:48.960 --> 13:53.820 Nun, da gibt es mehrere Untersuchungen, die Inspektionen insbesondere 13:53.820 --> 13:58.960 sind vielleicht die empirisch am besten untersuchte Techniken, Klasse 13:58.960 --> 14:02.480 von Techniken in der Softwaretechnik, mit vielen interessanten 14:02.480 --> 14:04.140 Experimenten und Erfahrungen damit. 14:07.300 --> 14:10.580 Dazu jetzt ein paar Ergebnisse dieser Studien. 14:11.220 --> 14:17.200 Das eine Ergebnis ist, dass man sagt, dass mindestens 50% aller 14:17.200 --> 14:22.340 entdeckten Defekte werden in Inspektionen gefunden, sogar bis zu 90%. 14:22.340 --> 14:28.080 Aber Sie sollten auch damit, also das ist bei Software, und 50 bis 75% 14:28.080 --> 14:30.960 in den Tuchsfehlern werden durch Inspektionen gefunden, nicht durch 14:30.960 --> 14:31.700 Testen. 14:32.380 --> 14:35.700 Und achten Sie, dass das noch sehr frühzeitig ist. 14:37.120 --> 14:41.860 Die Kosten für die Fehlerbehebung, dazu muss man sich erstmal klar 14:41.860 --> 14:45.320 machen, dass ein Fehler, je später er gefunden wird, desto teurer wird 14:45.320 --> 14:45.480 er. 14:46.860 --> 14:50.600 Und man sagt also, was sind denn die Kosten für einen Defekt, den ich 14:50.600 --> 14:54.580 in Inspektionen finde, und einen, den ich erst spät im Test, im 14:54.580 --> 15:00.700 Regressionstest oder im Systemtest finde, da sind die Kosten zwischen 15:00.700 --> 15:02.540 1 und 10 pro Fehler. 15:03.080 --> 15:08.240 Also später wird das Finden der Defekte sehr viel teurer. 15:08.800 --> 15:09.700 In ganzer Größenordnung. 15:10.640 --> 15:12.600 Darum ist man natürlich interessiert daran, es möglichst früh zu 15:12.600 --> 15:12.800 machen. 15:14.540 --> 15:18.280 Und die Firmen, die es richtig machen und auf hohe Qualität Wert 15:18.280 --> 15:24.080 legen, sagen, die Return on Investment ist weit über 500%. 15:24.080 --> 15:28.560 Das heißt also, die Kosten sind das eine, aber sie sparen sich damit 15:28.560 --> 15:32.400 fünfmal die Kosten, die reingekommen sind, die entstanden sind. 15:33.080 --> 15:34.520 Es lohnt sich also. 15:36.820 --> 15:40.080 Es gibt eine etwas ältere Studie, wenn Sie die suchen wollen, von 15:40.080 --> 15:42.960 Feigern, Design and Code Inspection to Reduce Errors in Program 15:42.960 --> 15:47.900 Development, schon von 1976, also auch schon ziemlich alt, aber das 15:47.900 --> 15:52.440 ist einer der Originalartikel über diese Technik. 15:52.540 --> 15:56.080 Ich finde immer, es ist sehr interessant, die Originalartikel zu 15:56.080 --> 16:00.880 lesen, wo sich diese Ideen zum ersten Mal formieren. 16:02.380 --> 16:03.340 Müssen sie aber nicht. 16:03.920 --> 16:05.140 Und warum funktioniert das? 16:05.240 --> 16:08.500 Das Vier-Augen-Prinzip oder das Sechs- oder das Acht-Augen-Prinzip. 16:09.240 --> 16:10.560 Viele sehen halt mehr als einer. 16:12.100 --> 16:14.440 Die Inspektoren haben auch Abstand zum Dokument. 16:14.520 --> 16:16.100 Sie können einen anderen Blickwinkel sehen. 16:16.640 --> 16:21.040 Sie sind nicht so betriebsblind oder anders betriebsblind. 16:21.860 --> 16:24.340 Sie bringen Erfahrungen ein, die der Entwickler vielleicht nicht 16:24.340 --> 16:24.660 hatte. 16:26.700 --> 16:30.020 Und interessant ist, was dann eigentlich auch in der Inspektion 16:30.020 --> 16:34.220 passiert, denn es gibt viele Fälle, wo eigentlich gar kein Defekt 16:34.220 --> 16:34.860 vorliegt. 16:35.760 --> 16:40.520 Wo es aber sagt, naja, es ist einfach unschön oder unvorteilhaft. 16:40.520 --> 16:42.900 Da könnt ihr das noch besser machen. 16:43.460 --> 16:44.640 Es ist vielleicht ineffizient. 16:44.760 --> 16:46.900 Es ist vielleicht kryptisch, schwer zu verstehen. 16:49.140 --> 16:54.380 Es kann eine Schwäche sein, aber nicht zu einem Defekt, zu einem 16:54.380 --> 16:55.120 Ausfall führen. 16:55.920 --> 16:59.000 Und das wiederum, diese Diskussion führt zu einer gemeinsamen Einsicht 16:59.000 --> 17:03.000 und so, dass das Team an sich für sich auch etwas lernt und nicht nur 17:03.000 --> 17:06.300 der Entwickler und damit das Team insgesamt sich verbessert. 17:08.280 --> 17:11.880 Eine Inspektion läuft jetzt folgendermaßen ab. 17:12.000 --> 17:13.120 Es gibt eine Vorbereitung. 17:13.940 --> 17:19.180 Da gibt es den Koordinator, der dafür sorgt, dass alle Inspektoren, 17:19.420 --> 17:23.300 sagen wir mal, wir nehmen drei oder vier, die gleichen Unterlagen 17:23.300 --> 17:25.660 bekommen, teilt sie aus, natürlich digital. 17:26.280 --> 17:28.060 Dann erfolgt die individuelle Fehlersuche. 17:28.260 --> 17:30.580 Das heißt, der Einzelne nimmt sich die Dinge vor und arbeitet ein, 17:30.640 --> 17:33.980 zwei Stunden dran, um Defekte zu identifizieren oder auch eben nur 17:33.980 --> 17:35.500 Schwäche, Unschönheiten und so weiter. 17:35.940 --> 17:36.920 Wird alles notiert. 17:38.180 --> 17:39.620 Dann gibt es eine Gruppensitzung. 17:39.740 --> 17:44.320 In der Gruppensitzung kommen die Inspektoren zusammen und besprechen 17:44.320 --> 17:45.780 das, was sie gefunden haben. 17:46.840 --> 17:49.060 Und dann gibt es die sogenannte Nachbereitung. 17:49.520 --> 17:51.720 Die Nachbereitung heißt, ich muss jetzt die Fehler korrigieren. 17:52.460 --> 17:54.820 Und dann gibt es auch noch einen Prozessverbesserungsvorschlag. 17:55.240 --> 17:57.160 Das macht man wieder eher seltener. 17:57.480 --> 17:59.400 In der Prozessverbesserung sagt man, wie kann ich den 17:59.400 --> 18:01.040 Inspektionsprozess noch verbessern? 18:01.040 --> 18:03.580 Was hat denn hier nicht so richtig funktioniert? 18:03.940 --> 18:05.960 Vielleicht muss man die Inspektionsliste anpassen. 18:06.400 --> 18:08.600 Oder vielleicht muss man die Teams anders zusammenstellen. 18:09.160 --> 18:10.560 Das macht man in der Prozessverbesserung. 18:12.100 --> 18:15.960 Gut, die Vorbereitung ist klar, austeilen, zeitlichen Ablauf planen, 18:16.180 --> 18:18.800 gibt es möglicherweise auch ein erstes Treffen. 18:21.650 --> 18:24.590 Die Inspektion selbst für die einzelne Fehlersuche sollte nicht länger 18:24.590 --> 18:25.510 als zwei Stunden dauern. 18:25.590 --> 18:25.730 Warum? 18:25.850 --> 18:27.570 Weil man danach nicht mehr weiterkommt. 18:27.790 --> 18:31.810 Man kann nicht mehr, man ist erschöpft, der Kopf macht nicht mehr mit. 18:32.670 --> 18:36.970 Die individuelle Fehlersuche, man sagt, eine Stunde pro Seite, pro 18:36.970 --> 18:37.510 Inspektor. 18:37.910 --> 18:41.910 Das ist also, eine Stunde pro Seite, eine ganze Stunde. 18:42.790 --> 18:46.170 Aber diejenigen, die dabei waren letztes Mal, haben sicher gesehen, 18:46.250 --> 18:48.710 dass es gar nicht so leicht ist, sich einen fremden Code einzulesen. 18:49.270 --> 18:52.290 Bis man das kapiert hat, was der da macht. 18:57.270 --> 19:01.130 Durchgegangen werden können maximal ein bis vier Seiten netto. 19:01.630 --> 19:04.590 Man benutzt die vereinbarte Lesetechnik, zum Beispiel eine 19:04.590 --> 19:08.550 Inspektionsliste oder eine Perspektive, schreibt die Probleme genau 19:08.550 --> 19:12.410 auf, an der Stelle im Dokument selbst hin oder in ein spezielles 19:12.410 --> 19:19.750 Formular und macht eben dann mögliche Defekte, paar 19:19.750 --> 19:25.890 Verbesserungsschläge, Vorschläge und Fragen, nur eine Frage dazu, aber 19:25.890 --> 19:27.950 man versucht nicht, den Code zu korrigieren. 19:28.750 --> 19:30.730 Wieder zu beseitigen, das ist Aufgabe eines Nächsten. 19:32.630 --> 19:38.710 Also, etwa eine Seite pro Stunde, vielleicht noch fast zwei, manchmal 19:38.710 --> 19:44.070 auch weniger als eine Seite pro Stunde, bei dem Lesen. 19:44.670 --> 19:47.550 Dann gibt es, wie gesagt, die Gruppensitzung, da werden die 19:47.550 --> 19:50.610 individuellen Problempunkte gesammelt. 19:50.650 --> 19:53.710 Es kann sein, dass der gleiche Problempunkt mehrfach gefunden wurde, 19:53.810 --> 19:55.610 dann wird das natürlich konsolidiert. 19:55.710 --> 19:56.790 In einem Punkt ist klar. 19:57.270 --> 19:59.510 Es kann auch sein, dass es Problempunkte gibt, die nur ein einziger 19:59.510 --> 20:00.150 gefunden hat. 20:01.690 --> 20:06.590 Man diskutiert diese und klärt die Fragen. 20:08.570 --> 20:11.570 Man ist übrigens ursprünglich der Autor, dieses Dokument ist nicht 20:11.570 --> 20:11.850 dabei. 20:12.330 --> 20:15.850 Das macht nur die Gruppe, ohne Hilfe von dem Autor selbst. 20:18.230 --> 20:20.190 Da gibt es einen interessanten Punkt. 20:21.090 --> 20:25.210 Während der Diskussion kann es neue Defekte geben, die entdeckt 20:25.210 --> 20:26.750 werden, an die man vorher nicht dachte. 20:27.610 --> 20:30.730 Das nennt man im Englischen die sogenannten Meeting Gains, also der 20:30.730 --> 20:33.570 Gewinn des Treffens. 20:33.870 --> 20:39.550 Es gibt auch Meeting Losses, das heißt also, Verlust von Anmerkungen 20:39.550 --> 20:40.750 während des Treffens. 20:40.910 --> 20:45.170 Das liegt zum Teil daran, dass sie sich entweder erledigt haben, hat 20:45.170 --> 20:48.810 jemand was missverstanden, darum sagt er es nicht mehr, oder einer 20:48.810 --> 20:50.290 traut sich nicht, es zu sagen. 20:51.190 --> 20:55.310 Dem sollte man natürlich schon eine Atmosphäre schaffen, wo es möglich 20:55.310 --> 21:01.890 ist, auch unsichere Punkte mit besprechen zu können. 21:03.910 --> 21:07.650 Man kann Verbesserungsvorschläge diskutieren, man kann aber auch sie 21:07.650 --> 21:10.370 nur notieren und das dabei belassen. 21:11.630 --> 21:15.790 Okay, Nachbereitung, da wird der Autor oder Editor des Dokuments 21:16.350 --> 21:19.730 weitergeleitet, klassifiziert die Defekte, leitet die Änderungen ein, 21:20.150 --> 21:25.270 bearbeitet alle Problempunkte, dann kann er eine Liste herumschicken, 21:25.410 --> 21:27.150 der sagt, ich habe den Punkt, den Punkt, den Punkt und den Punkt 21:27.150 --> 21:28.570 gemacht und zwar so und so. 21:30.030 --> 21:33.750 Man kann dann auch Restdefekte schätzen. 21:34.210 --> 21:38.370 Das ist ziemlich hanebüchen, aber das ist das Beste, was wir haben. 21:38.370 --> 21:43.270 Also, Sie haben ein Dokument vor sich, Sie haben das Ding inspiziert, 21:43.390 --> 21:45.510 dann sagen Sie, gut, und wie viel haben wir jetzt nicht gefunden? 21:47.850 --> 21:51.150 Dann sagen Sie, ja gut, die Nicht-Defekte sind möglicherweise so viel, 21:51.210 --> 21:52.170 wie die gerade entdeckten. 21:53.010 --> 21:56.330 Je mehr ich entdeckt habe, desto wahrscheinlicher ist es, dass noch 21:56.330 --> 22:00.490 mehr drinstecken und außerdem muss ich noch darüber nachdenken, dass 22:00.490 --> 22:02.830 ein Sechstel der Korrekturen auch wiederum fehlerhaft sind. 22:03.830 --> 22:06.410 Entweder die Korrektur selbst fehlerhaft ist, oder etwas anderes 22:06.410 --> 22:07.070 kaputt machen. 22:08.030 --> 22:09.690 Auch das kann mir natürlich passieren. 22:10.790 --> 22:13.550 Und dann sage ich, okay, irgendwann muss ich ja freigeben, ich kann 22:13.550 --> 22:14.970 nicht bis zur Perfektion warten. 22:15.430 --> 22:19.050 Dann sage ich, wenn die geschätzte Defektanzahl kleiner als die 22:19.050 --> 22:23.330 vorgegebene Zahl oder eine bestimmte Dichte ist, also so und so viele 22:23.330 --> 22:28.150 Defekte pro tausend Zeilen Code geschätzt, akzeptieren wir, bevor wir 22:28.150 --> 22:29.950 zum Kunden gehen, dann können wir freigeben. 22:32.210 --> 22:34.650 Planung, Durchführung und Besserung haben wir schon gehabt. 22:34.990 --> 22:39.950 Dann gibt es den Inspektionsleiter, der die Vorbereitung macht und die 22:39.950 --> 22:43.450 einzelnen Phasen leitet, den Moderator, der die Gruppensitzung leitet. 22:44.030 --> 22:46.510 Das können die gleichen Personen sein, Inspektionsleiter und 22:46.510 --> 22:49.230 Moderator, die Inspektoren selbst, die prüfen das Dokument. 22:49.730 --> 22:55.350 Einen Schriftführer kann ich separat einsetzen, der die Defekte 22:55.350 --> 23:00.810 notiert und einen Editor klassifiziert und behebt die Defekte. 23:01.050 --> 23:05.170 Der Autor hat das Dokument verfasst, aber Autor und Editor müssen 23:05.170 --> 23:08.010 nicht die gleichen sein, können aber, sind aber meistens. 23:08.930 --> 23:10.130 Wie sieht so etwas aus? 23:10.190 --> 23:15.170 Ich habe ein Formular, das sage ich, Stelle ist Modul so und so, Zeile 23:15.170 --> 23:15.930 so und so. 23:18.210 --> 23:20.730 Ich habe eine kurze Beschreibung, die Wichtigkeit ist hoch oder 23:20.730 --> 23:23.290 gering, Problemtyp ist Defekt, Anregung, Frage. 23:25.030 --> 23:27.510 Defekttyp und dann behoben, ja, nein, nachgeprüft, ja, nein. 23:29.950 --> 23:32.830 Das ist eigentlich ganz einfach, so hat man das früher gemacht, als 23:32.830 --> 23:34.230 das noch alles Papier war. 23:34.450 --> 23:37.550 Kann man natürlich immer noch so machen, aber heute hat man digitale 23:38.290 --> 23:39.250 Versionen davon. 23:40.070 --> 23:42.730 Da zeige ich Ihnen dann vorher und nachher noch ein Beispiel. 23:44.330 --> 23:47.410 Natürlich kann ich das auf dem Bildschirm heutzutage machen und direkt 23:47.410 --> 23:49.490 in das Dokument eine Annotation einfügen. 23:52.490 --> 23:56.930 Defektklassifikation ist schwerwiegend oder leicht und Defekt sind 23:56.930 --> 24:00.370 Anregungen, sind Vorschläge etwas zu verbessern oder einfach nur eine 24:00.370 --> 24:03.870 Frage, was passiert an dieser Stelle, wenn das und das vorliegt oder 24:05.290 --> 24:07.030 oder was immer es ist. 24:08.410 --> 24:12.190 Defekttypen gibt es auch noch, das Ambiguous Information heißt das, 24:12.350 --> 24:16.850 Extraneous Information, also zu überflüssiges, Inconsistent 24:16.850 --> 24:20.350 Information, Incorrect Fact, Missing Information, Miscellaneous 24:20.350 --> 24:20.810 Defect. 24:28.450 --> 24:30.570 Dann machen wir einen kurzen Stopp. 24:31.030 --> 24:32.630 Gibt es Fragen soweit? 24:38.140 --> 24:39.160 Ich sehe keine. 24:40.000 --> 24:43.400 Die Lesetechniken sind ad hoc, das sind eben bei den Durchsichten, ich 24:43.400 --> 24:44.440 habe keinerlei Vorgaben. 24:44.900 --> 24:48.580 Ich habe eine Prüfliste oder Checklist mit Fragen zum Dokument. 24:48.840 --> 24:53.060 Das soll natürlich das Aufspüren von Defekten erleichtern und ich muss 24:53.060 --> 24:55.240 diese Fragen abhaken, Reihe nach, wie so eine Liste. 24:56.820 --> 24:59.900 Die Prüflisten sind natürlich abhängig von der Art des Dokumentes. 24:59.900 --> 25:03.060 Wenn ich ein Java-Programm habe, habe ich anderes zu prüfen, als wenn 25:03.060 --> 25:07.440 ich ein C-Programm prüfen muss, weil dort das Typprüfen nicht 25:07.440 --> 25:11.420 vorhanden ist, zum Beispiel nicht so stark ist wie bei Java. 25:13.540 --> 25:15.260 Bei Entwurfsdokumenten brauche ich etwas anderes. 25:15.680 --> 25:17.740 Da brauche ich eine völlig andere Prüfliste. 25:17.800 --> 25:21.220 Vielleicht muss ich sagen, ist das Geheimnisminzip eingehalten, sind 25:21.220 --> 25:29.620 alle Attribute privat und ähnliches. 25:29.860 --> 25:33.280 Oder ist ein innerer Zusammenhang des Moduls gegeben, also habe ich 25:33.280 --> 25:36.340 andere Fragen, als wenn ich Code inspiziere. 25:36.700 --> 25:38.020 Ich zeige Ihnen aber 25:41.660 --> 25:43.140 gleich so eine Prüfliste. 25:43.600 --> 25:46.660 Die Perspektiven aus Szenarien sind eine Anleitung, wie das Dokument, 25:46.780 --> 25:50.280 aus welcher Sichtweise es zu lesen ist, mit einem Satz und Fragen. 25:50.800 --> 25:54.380 Die überspringen wir heute aber aufgrund von Zeitmangel. 25:56.780 --> 26:00.880 Das sagt Ihnen etwas über, wie groß so eine Inspektionsliste sein 26:00.880 --> 26:01.160 soll. 26:01.320 --> 26:05.720 Sie wird leider ziemlich schnell ziemlich groß und je länger sie ist, 26:05.800 --> 26:08.720 desto mehr Punkte hat sie und desto mehr Arbeit erfordert sie. 26:09.220 --> 26:14.980 Da muss man irgendwie ein gutes Mittelmaß treffen, wenn so eine Hand 26:14.980 --> 26:18.660 so austräglich ist, dass man ein bis zwei Seiten hat. 26:20.120 --> 26:23.040 Hier wäre zum Beispiel so eine Prüfliste in der obersten 26:23.040 --> 26:26.340 Detaillierungsstufe, müssen Sie nicht auswendig lernen, keine Angst. 26:27.220 --> 26:32.840 Wenn wir Sie prüfen lassen, dann kriegen Sie eine Prüfliste in der 26:32.840 --> 26:33.320 Prüfung. 26:35.940 --> 26:38.840 Variablen, Attribute und Konstantendeklarationen anschauen, 26:39.640 --> 26:42.080 Methodendefinitionen durchsehen, Klassendefinitionen durchsehen, ist 26:42.080 --> 26:42.320 klar. 26:42.760 --> 26:45.340 Datenreferenzen, wie werden Daten angesprochen? 26:46.000 --> 26:47.160 Die Berechnungen, ist klar. 26:47.980 --> 26:51.960 Vergleiche, Bedingungen der Steuerfluss, Kontrollfluss der Ein- und 26:51.960 --> 26:55.000 Ausgaben, die Modulschnittstellen, Kommentare, Dokumentationen, okay. 26:56.180 --> 26:59.760 Ist die Grundformatierung sauber, die Modularität, die 26:59.760 --> 27:01.940 Speicherverwendung und die Ausführungsgeschwindigkeit. 27:03.480 --> 27:05.700 Und jetzt nur ein Beispiel. 27:07.580 --> 27:08.940 So war es, noch eins zurück. 27:09.380 --> 27:11.780 Die Variablen, Attribute und Konstantendeklarationen diesen Punkt 27:11.780 --> 27:12.460 genau anschauen. 27:12.900 --> 27:14.040 Den spalte ich jetzt auf. 27:14.740 --> 27:17.720 Sind die Variablen, Attribute und Konstantennamen aussagekräftig? 27:18.820 --> 27:21.240 Stimmen die Bezeichnungen mit den Programmierrichtlinien überein? 27:21.380 --> 27:23.860 Gibt es für Variablen und Attribute mit ähnlichen Namen wegen der 27:23.860 --> 27:24.700 Verwechslungsgefahr? 27:25.460 --> 27:28.060 Wurde jede Variable und jedes Attribut korrekt typisiert? 27:28.300 --> 27:28.980 Stimmen die Typen? 27:29.600 --> 27:30.860 Und wurde alles initialisiert? 27:31.820 --> 27:35.140 Ziemlich einfach, aber natürlich sind Variablen und Konstanten auch 27:35.140 --> 27:38.540 von sich aus ein einfaches Konstrukt. 27:38.700 --> 27:40.420 Bei Berechnungen wird das dann schon etwas anderes. 27:42.240 --> 27:44.640 Methodendefinitionen, sind die Methodennamen aussagekräftig? 27:45.360 --> 27:48.440 Wir haben so ein paar Beispiele in den Java-Passlern gehabt, wo die 27:48.440 --> 27:50.600 Methodennamen mangelhaft waren. 27:51.040 --> 27:53.160 Stimmen die Methodennamen mit den Programmierrichtlinien überein? 27:54.160 --> 27:58.180 Wird jeder Methodenparameter vor der Verwendung überprüft, also alle 27:58.180 --> 27:59.100 Eingabeparameter? 27:59.620 --> 28:00.480 Gibt es Prüfungen? 28:00.980 --> 28:02.800 Sind sie auf Richtigkeit geprüft? 28:03.480 --> 28:05.860 Gibt die Methode mit jedem Return den korrekten Wert zurück? 28:08.140 --> 28:11.580 Gibt es statische Methoden, welche nicht statisch sein sollten und 28:11.580 --> 28:12.120 umgekehrt? 28:15.100 --> 28:15.760 Okay. 28:16.740 --> 28:21.160 Eher ist es so, dass es eher umgekehrt ist. 28:21.200 --> 28:25.680 Habe ich eine nicht statische Methode, die eigentlich statisch sein 28:25.680 --> 28:28.500 könnte, weil sie keine Attribute benutzt. 28:32.200 --> 28:33.980 Nur statische Attribute. 28:34.320 --> 28:36.300 Es könnten also natürlich noch weitere Prüfungen ergänzen. 28:36.420 --> 28:37.840 Wie gesagt, muss ich nicht machen. 28:38.240 --> 28:40.080 Komplett Ihnen jetzt vorlegen. 28:42.240 --> 28:45.920 Aber es klingt alles ganz einfach, so ähnlich wie beim Entwurf. 28:46.080 --> 28:47.800 Ganz klar, das kann ich doch und so weiter. 28:47.940 --> 28:51.720 Und wenn man es davor sieht und es machen muss, ist es meistens aus. 28:52.120 --> 28:53.300 Was macht denn der da? 28:53.340 --> 28:54.140 Was soll dieser Code? 28:55.800 --> 28:56.200 Okay. 28:57.560 --> 28:57.960 Gut. 28:58.160 --> 29:01.620 Also die Perspektive und Szenarien, wie gesagt, die sparen wir uns. 29:02.280 --> 29:03.860 Können Sie natürlich selber durchlesen. 29:04.520 --> 29:08.240 Aber es gibt uns nicht sehr viel Zeit. 29:08.320 --> 29:10.340 Es waren bloß zwei Folien, wenn Sie es gesehen haben. 29:11.040 --> 29:11.360 Drei. 29:13.960 --> 29:16.040 Jetzt gibt es Werkzeuge der Inspektionsunterstützung. 29:17.660 --> 29:21.280 Agile Review Jupyter und so weiter, Fabricate Review Board, Road Code 29:21.280 --> 29:21.920 und so weiter. 29:23.280 --> 29:29.960 Und die Frage ist, wo im Entwicklungsprozess wird diese Inspektion 29:29.960 --> 29:30.900 eingespeist? 29:32.080 --> 29:37.000 Und eine Methode ist, dass sie eben, und das gilt jetzt hauptsächlich 29:37.000 --> 29:41.960 für Programme, also nicht für Anforderungen, sie buchen erst aus, aus 29:41.960 --> 29:46.380 Git oder so etwas, programmieren und speichern das, Änderungen in die 29:46.380 --> 29:51.100 Versionskontrollsystem ein, ohne dass eine Inspektion erfolgt. 29:51.220 --> 29:55.280 Das heißt, andere Entwickler können das übernehmen und bereits damit 29:55.280 --> 29:58.680 arbeiten, obwohl die Inspektion noch ansteht. 30:00.880 --> 30:04.780 Dann gehe ich her und übermittle das Ding in das Inspektionswerkzeug, 30:05.000 --> 30:07.980 da wäre jetzt wieder was zu inspizieren, kann aber schon benutzt 30:07.980 --> 30:11.060 werden, dann muss die Inspektion durchgeführt werden, dann werden 30:11.060 --> 30:16.180 Änderungen genehmigt und die Änderungen genehmigten werden natürlich 30:16.180 --> 30:18.740 auch wieder ins Versionssystem eingespeist. 30:20.180 --> 30:21.540 Das ist die Methode 1. 30:21.680 --> 30:25.280 Es gibt noch eine andere Methode, die sagt, ihr Entwickler könnt 30:25.280 --> 30:27.740 nichts von meinen Änderungen sehen, bis nicht die Inspektion 30:27.740 --> 30:28.500 abgelaufen ist. 30:29.000 --> 30:29.640 Was ist besser? 30:30.080 --> 30:30.660 Keine Ahnung. 30:30.660 --> 30:33.120 Es gibt noch keine Studie dafür. 30:34.460 --> 30:37.860 Also, wieder aus Versionskontrollsystem ausprogrammieren, die Arbeit 30:37.860 --> 30:43.560 machen, die Änderungen an das Inspektionswerkzeug zu übermitteln und 30:43.560 --> 30:47.600 die Inspektion durchführen, dann die geänderten Änderungen genehmigen 30:47.600 --> 30:51.660 lassen und dann erst in das Versionskontrollsystem einbuchen, das 30:51.660 --> 30:54.680 heißt, dann wird es sichtbar für andere Entwickler. 30:57.860 --> 31:01.400 Da wird also die Inspektion als Hürde im Entwicklungsprozess. 31:03.380 --> 31:07.360 Die Software ist eigentlich noch nicht da, bis die Inspektion 31:07.360 --> 31:11.020 durchgeführt wird und wenn man keinen Termin findet für Inspektionen, 31:11.080 --> 31:15.560 dann verzögert natürlich dieses Vorgehen die Verfügbarkeit der 31:15.560 --> 31:15.840 Software. 31:16.780 --> 31:18.600 Kann jetzt schlecht oder kann gut sein. 31:21.040 --> 31:25.240 Das ist also nicht gerade scharf, mal wieder, aber ich glaube, es ist 31:25.240 --> 31:27.040 auch überhaupt nicht so besonders scharf. 31:27.040 --> 31:30.960 Das Beispiel Agile Review, das können Sie also in die 31:30.960 --> 31:37.440 Programmierumgebungen eingeben, einblenden und können dann die 31:37.440 --> 31:40.760 einzelnen Dinge mit Metadaten und Kommentaren zu einem 31:41.440 --> 31:44.480 Inspektionsverwaltungssystem versehen. 31:46.620 --> 31:51.260 Interessanterweise, ich kann mich erinnern, als die Idee, dass man 31:51.260 --> 31:54.500 einen speziellen Editor hat, mit dem man Inspektionen durchführt, 31:54.500 --> 31:59.220 wurde vielleicht vor etwa 20 Jahren das erste Mal vorgeführt und zwar 31:59.220 --> 32:02.840 als Teil über einen Web- Editor. 32:03.720 --> 32:08.380 Das heißt, die Inspektionen konnte man, die Inspektionsergebnisse 32:08.380 --> 32:14.820 wurden auf Webformularen durchgeführt und die Leute, die darüber 32:14.820 --> 32:18.320 berichtet hatten, die stammten glaube ich von Agilent, sagten, das hat 32:18.320 --> 32:21.060 so eingeschlagen, dass wir unsere Experimente gar nicht fertig machen 32:21.060 --> 32:23.640 konnten, die Leute wollten das schon sofort benutzen. 32:25.760 --> 32:28.780 Nun, es kann gut sein, dass Sie von Inspektionen noch nichts gehört 32:28.780 --> 32:29.240 haben. 32:33.420 --> 32:39.120 Zum Beispiel weiß man nicht, dass etwa Microsoft Inspektionen 32:39.120 --> 32:39.820 durchführen würde. 32:39.980 --> 32:42.020 Wenn, dann tun sie es nicht sehr häufig. 32:45.720 --> 32:49.420 Es gibt andere Firmen, die führen Inspektionen seit den 70er Jahren 32:49.420 --> 32:52.380 durch und das sind gerade die Telekommunikationsfirmen und sind damit 32:52.380 --> 32:53.040 sehr erfolgreich. 32:54.320 --> 32:57.960 Die sagen immer, wenn es um Qualitätssoftware geht, wir wissen, wie 32:57.960 --> 33:00.660 man das macht, denn Sie müssen ja, wenn Sie sich erinnern, ich habe 33:00.660 --> 33:05.700 das schon mehrmals erwähnt, unglaublich harte Qualitätsanforderungen 33:05.700 --> 33:09.320 genügen, nämlich nicht mehr als eine Stunde Ausfall des Festnetzes in 33:09.320 --> 33:10.040 40 Jahren. 33:10.740 --> 33:13.800 40 Jahre, eine einzige Stunde, da soll das Festnetz stehen. 33:17.120 --> 33:20.340 Das heißt, da müssen Sie Investitionen machen, dass Sie auch wirklich 33:20.340 --> 33:21.820 möglichst alle Fehler finden. 33:22.520 --> 33:23.580 Und so früh wie möglich. 33:24.100 --> 33:27.800 Und das funktioniert mit Inspektionen und nicht mit Testen oder den 33:27.800 --> 33:28.880 Benutzer testen lassen. 33:30.060 --> 33:32.400 Nicht mit Alpha-Tests in der Benutzerhand. 33:33.920 --> 33:41.040 Es gibt Eclipse-Plugins, die arbeiten zusammen mit dem Git-System, das 33:41.040 --> 33:47.240 heißt, die durchzuführten neuen Versionen, die noch nicht inspiziert 33:47.240 --> 33:52.120 sind, bekommen gewissermaßen ein Vorarchiv und in das Hauptarchiv oder 33:52.120 --> 33:54.560 den Hauptarzt erst, wenn sie inspiziert worden sind. 33:56.500 --> 33:56.800 Okay. 33:57.660 --> 33:59.660 Das macht zum Beispiel das Werkzeug Garret. 34:00.600 --> 34:04.220 Das agiert als Einbuchungspuffer zwischen dem Entwickler und Git. 34:04.560 --> 34:07.900 Also alle Einbuchungen bis zur Genehmigung werden zurückgehalten, nach 34:07.900 --> 34:08.920 dieser zweiten Methode. 34:10.660 --> 34:13.720 Und dann erst nach Durchführung geht es weiter. 34:16.220 --> 34:16.740 Okay. 34:17.580 --> 34:18.500 Wo waren wir jetzt? 34:19.120 --> 34:20.980 Jetzt sind wir im Komponententest. 34:22.480 --> 34:23.520 Manuelle Prüfmethoden. 34:23.620 --> 34:25.340 Jetzt fehlen uns noch die Prüfprogramme. 34:25.860 --> 34:28.880 Da kann ich mich auch kurz fassen, denn das Konzept selbst ist ja 34:28.880 --> 34:31.920 nicht schwierig und Sie kennen ja Checkstyle und vielleicht sogar 34:31.920 --> 34:32.280 andere. 34:33.640 --> 34:37.780 Prüfprogramme sind also dazu da, statisch Programme zu überprüfen, 34:37.960 --> 34:39.340 ohne sie ablaufen zu lassen. 34:42.200 --> 34:44.080 Und was gibt es da zum Beispiel? 34:44.080 --> 34:47.880 Man möchte sehen, ob alle Variablen initialisiert sind. 34:48.040 --> 34:49.820 Das macht der Java-Übersetzer übrigens schon. 34:51.960 --> 34:55.480 Es gibt Fälle, wo natürlich Fehlermeldungen gibt, die nicht richtig 34:55.480 --> 34:55.740 sind. 34:55.880 --> 35:02.460 Da sagt er, ich meine, hier fehlt eine Initialisierung, aber die ES 35:02.460 --> 35:05.020 -Programmierer wissen, dass die Initialisierung doch passiert in einem 35:05.020 --> 35:07.360 bestimmten Ast, der immer ausgeführt wird. 35:08.700 --> 35:11.200 Es gibt nicht erreichbare Anweisungen, toten Code. 35:11.200 --> 35:14.600 Man kann auch ein statisches Prüfsystem identifizieren. 35:14.780 --> 35:18.620 Es kann unnötige Anweisungen geben, die nichts bewirken, deren Effekt 35:18.620 --> 35:19.840 gleich wieder überschrieben wird. 35:21.100 --> 35:24.880 Man möchte zum Beispiel wissen, ob jeder Monitoreintritt mit einem 35:24.880 --> 35:26.320 Monitoreintritt gekoppelt ist. 35:26.820 --> 35:31.200 Auch das kann man statisch überprüfen, egal wie verschlungen die Logik 35:31.200 --> 35:32.100 einer Methode ist. 35:32.400 --> 35:36.500 Es gibt halt Break- und Return-Anweisungen, mit denen Sie aus der 35:36.500 --> 35:40.640 Methode oder aus dem synchronisierten Block austreten und dann wollen 35:40.640 --> 35:43.960 Sie garantieren, dass auch dieser Monitor dann freigegeben wird, denn 35:43.960 --> 35:48.360 sonst könnte es vielleicht immer oder vielleicht auch nur in seltenen 35:48.360 --> 35:52.660 Fällen zu einer dauerhaften Sperre und einer Blockade führen. 35:54.040 --> 35:58.560 Sie können und das macht Sextal, programmierst du überprüfen, das 35:58.560 --> 36:01.880 überspreche ich jetzt nicht, denn das kennen Sie oder auch Fehler 36:01.880 --> 36:04.340 anhand von bestimmten Fehlermustern finden. 36:06.080 --> 36:08.740 Auch dafür gibt es die entsprechenden Prüfprogramme. 36:09.360 --> 36:11.980 So, also haben wir das auch schon hinter uns. 36:12.960 --> 36:15.080 Datenflussorientiert bleibt frei, das werden wir nicht machen. 36:17.900 --> 36:21.500 Und jetzt kommen die beiden Tests, die letzten Tests, Integrationstest 36:21.500 --> 36:25.320 und Systemtest und Abnahmetest, habe ich eigentlich schon besprochen 36:25.320 --> 36:28.180 aus der Übersicht am Anfang, wenn Sie sich erinnern. 36:28.740 --> 36:32.780 Also hier, Integrationstest kommt als nächstes, aber da ist nicht viel 36:32.780 --> 36:33.460 zu sagen mehr. 36:34.340 --> 36:38.600 Integrationstest ist einfach eine schrittweise Integration, das heißt, 36:38.700 --> 36:40.420 Sie spannen mehrere Komponenten zusammen. 36:40.960 --> 36:43.800 Jede einzelne Komponente ist bereits getestet worden mit 36:43.800 --> 36:48.480 entsprechenden Testprogrammen und Sie spannen sie jetzt zusammen und 36:48.480 --> 36:51.060 prüfen erneut, bis das System komplett integriert ist. 36:52.180 --> 36:57.140 Sie prüfen jetzt nicht so sehr die einzelnen Komponente, sondern das 36:57.140 --> 36:58.860 Zusammenwirken der Komponenten. 37:02.180 --> 37:05.620 Wenn Sie das so machen, haben Sie natürlich unter Umständen Aufrufe, 37:05.960 --> 37:09.440 Systemteile, die noch nicht hinzuintegriert sind, dann brauchen Sie 37:09.440 --> 37:14.040 dafür die Stummel und Sie wollen möglicherweise mit der Trappen 37:14.040 --> 37:16.580 arbeiten oder Nachahmungen. 37:17.000 --> 37:17.700 Die müssen Sie bauen. 37:19.160 --> 37:22.380 Die Frage ist aber, in welche Reihenfolge sollte ich integrieren und 37:22.380 --> 37:24.060 da gibt es erstaunlich viele Möglichkeiten. 37:26.300 --> 37:30.620 Da gibt es also eine Integrationsstrategie, die sagt, alles auf einmal 37:30.620 --> 37:31.640 oder unmittelbar. 37:32.820 --> 37:36.620 Das hat den Vorteil, dass Sie keinen Testtreiber und keine Platzhalter 37:36.620 --> 37:37.160 benötigen. 37:37.300 --> 37:40.080 Sie nehmen das Gesamtsystem auf einmal zusammen. 37:40.400 --> 37:42.080 Das heißt übrigens Big Bang. 37:42.580 --> 37:43.460 Der Big Bang Test. 37:43.980 --> 37:46.780 Und aus gutem Grunde, denn da geht erstmal gar nichts. 37:47.060 --> 37:48.980 In der Regel geht da erstmal gar nichts. 37:49.520 --> 37:52.520 Sie haben das Gesamtbetriebssystem zusammengehängt, sagen Sie, jetzt 37:52.520 --> 37:54.200 lassen wir es laufen und bringen uns schon Krachts. 37:58.000 --> 38:00.440 Es müssen alle Komponenten schon fertig sein. 38:00.560 --> 38:02.120 Defekte sind dann schwer zu lokalisieren. 38:02.240 --> 38:03.360 Sie haben ein sehr großes System. 38:03.980 --> 38:05.740 Testüberdeckung ist jetzt schwierig sicherzustellen. 38:05.840 --> 38:11.020 Jetzt haben Sie zig Millionen möglichen Ästen, Zweigen. 38:11.680 --> 38:15.720 Ist eigentlich für große Systeme nicht geeignet, dieser Big Bang Test. 38:16.260 --> 38:18.080 Big Bang, weil es dann richtig laut kracht. 38:19.920 --> 38:25.760 Inkrementell ist besser, denn Sie können fertiggestellte Komponenten 38:25.760 --> 38:27.980 schon testen, selbst wenn noch nicht alles da ist. 38:29.800 --> 38:33.480 Sie können unfertige Komponenten aber weiterhin entwickeln. 38:34.260 --> 38:36.980 Die Testfälle sind leichter konstruierbar, denn Sie in der Regel mit 38:36.980 --> 38:38.220 weniger Komponenten arbeiten. 38:38.700 --> 38:40.700 Und die Testüberdeckung ist auch überprüfbarer. 38:41.500 --> 38:43.300 Aber Sie brauchen jetzt Testtreiber. 38:44.260 --> 38:45.480 Na gut, das ist kein Problem mehr. 38:45.540 --> 38:47.060 Das macht funktioniert für uns automatisch. 38:47.640 --> 38:50.380 Und Sie brauchen Testhelfer, auch wieder Stummel und eine Trappe. 38:50.920 --> 38:51.680 Das ist inkrementelle. 38:54.740 --> 39:00.380 Vorgehensorientiert heißt, die Integrationsreihenfolge leitet sich von 39:00.380 --> 39:01.660 der Systemstruktur ab. 39:01.940 --> 39:06.000 Zielorientiert heißt, Sie wollen ein bestimmtes Ziel erreichen, zum 39:06.000 --> 39:08.500 Beispiel bestimmte Funktionalitäten überprüfen. 39:09.600 --> 39:12.680 Und da werden jeweils nur die benötigten Komponenten zusammen 39:12.680 --> 39:13.100 montiert. 39:14.940 --> 39:17.400 Okay, jetzt schauen wir an, den Big Bang haben wir schon. 39:17.780 --> 39:19.000 Nichts geht, bis alles geht. 39:19.920 --> 39:20.640 Alles auf einmal. 39:22.160 --> 39:24.200 Geschäftsprozessorientiert, alle Komponenten werden integriert, die 39:24.200 --> 39:27.440 vom Geschäftsprozess oder Anwendungsfall betroffen sind, die ich dazu 39:27.440 --> 39:27.840 brauche. 39:29.340 --> 39:32.900 Das kann man machen, ist unter Umständen aber auch sehr viel des 39:33.400 --> 39:33.880 Gesamtsystems. 39:35.760 --> 39:38.600 Funktionsorientiert, funktionale Testfälle zum Beispiel, die die 39:38.600 --> 39:40.760 funktionalen Anforderungen erfüllen, testen. 39:41.400 --> 39:44.060 Oder schrittweise Integration und Test der Komponenten, die durch 39:44.060 --> 39:45.140 Testfälle betroffen sind. 39:45.500 --> 39:46.340 Das machen sie hier. 39:47.220 --> 39:50.580 Und nach Verfügbarkeit ist, naja, was ich halt gerade fertig habe. 39:51.300 --> 39:55.160 Und die Fertigstellungseinfolge bestimmt jetzt, wie sie testen. 39:55.760 --> 39:59.520 Das ist nicht so geschickt, denn es ist extrem schlecht planbar. 40:01.520 --> 40:02.140 Okay, so. 40:02.400 --> 40:05.560 Jetzt schauen wir uns die anderen, die wirklich in Frage gekommen 40:05.560 --> 40:08.380 sind, eigentlich in diesem Kontranten. 40:08.960 --> 40:12.840 Der Top-Down ist, sagen Sie, Bienen mit den einfachsten Modulen oder 40:12.840 --> 40:16.800 Komponenten, die auf nichts anderes als auf den Bibliotheken aufbauen 40:16.800 --> 40:19.420 und testen sie und stellen sie zusammen. 40:19.640 --> 40:20.740 Entschuldigen, das war das Bottom-Up. 40:21.020 --> 40:22.640 Top-Down geht gerade umgekehrt her. 40:23.440 --> 40:27.680 Bei Top-Down fangen Sie mit dem Main-Programm an und schieben nach und 40:27.680 --> 40:31.280 nach zusätzliche Komponenten hinzu, aber die unteren fehlen Ihnen 40:31.280 --> 40:33.600 natürlich und dafür müssen Sie die Stummel haben. 40:33.600 --> 40:39.740 Ja, also diese Testhelfer sind dann unter Umständen aufwendig zu 40:39.740 --> 40:45.740 erstellen, aber Sie haben dann sehr früh das Gesamtrahmenprogramm zur 40:45.740 --> 40:48.880 Verfügung und können dann schon sehen, wie das Gesamtprogramm 40:48.880 --> 40:52.900 vielleicht sogar mit der Oberfläche schon aussieht und ob die 40:52.900 --> 40:56.660 Funktionen, die jetzt noch nicht richtig funktionieren, aber sie sind 40:56.660 --> 41:00.160 schon mal da und Sie geben vielleicht immer die gleiche Antwort, aber 41:00.160 --> 41:04.540 man kann sehen, dass das Gesamtsystem, wie das Gesamtsystem am Schluss 41:04.540 --> 41:05.240 aussehen wird. 41:06.840 --> 41:09.740 Nachteil ist natürlich jetzt auch, wenn Zusammenspiel zwischen 41:09.740 --> 41:12.920 Hardware und Software wichtig ist, dass das erst sehr spät geprüft 41:12.920 --> 41:13.160 wird. 41:13.560 --> 41:17.000 Wenn Sie spezielle Sensoren brauchen, zum Beispiel spezielle Geräte, 41:17.140 --> 41:21.460 spezielle Schnittstellen in einem eingebetteten System, dann wird 41:21.460 --> 41:24.900 dieses Teil erst ganz am Schluss getestet und das kann natürlich 41:24.900 --> 41:25.540 kritisch werden. 41:27.220 --> 41:29.000 So, Bottom-Up geht halt genau andersrum. 41:30.280 --> 41:34.540 Die Vorteile und Nachteile von Top-Down und Bottom-Up sind dann gerade 41:34.540 --> 41:37.360 immer umgekehrt, was Vorteil war beim einen ist jetzt der Nachteil 41:37.360 --> 41:38.440 beim anderen und so weiter. 41:39.340 --> 41:43.480 Jetzt brauchen Sie Testdriver statt Stummel, aber Sie haben ein 41:43.480 --> 41:48.420 leichteres Herstellen von Testbedingungen als bei Top-Down und leichte 41:48.420 --> 41:50.080 Interpretation der Testergebnisse. 41:51.760 --> 41:52.420 Outside-In. 41:53.460 --> 41:54.420 Eher ungewöhnlich. 41:54.560 --> 41:56.620 Outside-In, da sagt man, ich fange irgendwo in der Mitte, in der 41:56.620 --> 42:02.340 mittleren Ebene meines Gesamtsystems an und büge nach unten und nach 42:02.340 --> 42:05.660 oben in der Aufruf-Hierarchie oder Abhängigkeits-Hierarchie neue 42:05.660 --> 42:06.520 Methoden hinzu. 42:07.980 --> 42:09.400 Schrittweise in beiden Richtungen. 42:10.080 --> 42:11.660 Inside-Out, was hatten wir jetzt gesagt? 42:11.740 --> 42:12.280 Outside-In. 42:12.520 --> 42:14.620 Entschuldigung, jetzt habe ich wieder verkehrt herum erklärt. 42:15.060 --> 42:17.340 Ich habe das Inside-Out erklärt, jetzt erkläre ich das Outside-In. 42:19.340 --> 42:21.040 Das ist eigentlich unpraktikabel. 42:21.360 --> 42:25.240 Das Gegenteil von Inside-Out kann man eigentlich vergessen, denn es 42:25.240 --> 42:28.200 kombiniert eigentlich die Nachteile von Top-Down und Warm-Up. 42:30.440 --> 42:33.700 Man beginnt also gleichzeitig von oben nach unten aufeinander 42:33.700 --> 42:34.220 zuzuarbeiten. 42:34.900 --> 42:39.720 Da müssen Sie die Top-Down- Methoden in Kauf nehmen und die Warm-Up 42:39.720 --> 42:40.280 -Methoden. 42:40.800 --> 42:41.120 Nachteile. 42:42.220 --> 42:45.620 Inside -Out hatten wir und schließlich die kritischen Komponenten 42:45.620 --> 42:46.100 zuerst. 42:46.620 --> 42:49.900 Das ist durchaus vernünftig, wenn es solche identifizierbaren 42:49.900 --> 42:53.700 kritischen Komponenten gibt, dass man die als allererstes testet, denn 42:53.700 --> 42:57.540 die können unter Umständen die ganze Show zum Stehen bringen, wenn sie 42:57.540 --> 42:58.780 zu spät getestet werden. 43:00.760 --> 43:02.580 Okay, das sind die Integrationsstrategien. 43:02.680 --> 43:04.100 Schon sind wir mit dem Punkt fertig. 43:04.360 --> 43:05.900 Die Integrationsreihenfolge. 43:06.380 --> 43:08.600 Jetzt käme als nächstes das System-Test. 43:09.460 --> 43:13.780 Das System-Test ist jetzt eigentlich der letzte Integrations-Test, der 43:13.780 --> 43:15.620 alle Komponenten zusammenpackt. 43:18.900 --> 43:22.200 Jetzt wird auch das System als Blackbox betrachtet, nur die äußere 43:22.200 --> 43:23.840 Schnittstelle wird nur noch getestet. 43:24.060 --> 43:27.020 Die Benutzerschnittstelle und externen Schnittstellen zu anderen 43:27.020 --> 43:27.680 Systemen. 43:28.100 --> 43:31.540 Und es läuft auf einer realistischen oder realen Umgebung bereits. 43:32.240 --> 43:35.040 Zum Beispiel auf einer technischen Anlage, in einem Roboter, in einem 43:35.040 --> 43:38.460 Fertigungssystem, in einem Logistiksystem, in einem 43:38.460 --> 43:39.400 Lagerhaltungssystem. 43:45.160 --> 43:49.080 Wir hatten am Anfang ja immer dieses Problem, das Toll Collect gehabt, 43:49.360 --> 43:54.080 mit der Maut-Erfassung für Laster. 43:54.620 --> 43:59.520 Die haben das System tatsächlich getestet und mit echten Lastern und 43:59.520 --> 44:04.900 nur der Diesel für die Laster, die Kosten für den Diesel, war in den 44:04.900 --> 44:05.280 Millionen. 44:06.680 --> 44:08.940 Ich weiß nicht, wie viele Laster sie fahren hatten, um das 44:08.940 --> 44:10.200 Gesamtsystem zu testen. 44:11.260 --> 44:15.120 Allein das, nur der Treibstoff, war im Millionenbereich. 44:17.260 --> 44:17.660 Für den Test. 44:20.940 --> 44:24.180 Es gibt noch einen funktionalen und nicht funktionalen Systemtest. 44:24.380 --> 44:24.800 Das ist klar. 44:24.900 --> 44:27.340 Wir haben funktionale und nicht funktionale Anforderungen. 44:27.500 --> 44:29.660 Das ist das, was ich im Systemtest überprüfe. 44:30.540 --> 44:36.900 Also muss ich die Qualitätsmerkmale, die funktionalen Merkmale und die 44:36.900 --> 44:39.060 nicht funktionalen Merkmale, wie zum Beispiel Sicherheit, 44:39.240 --> 44:43.480 Benutzbarkeit, Interoperabilität, Dokumentation, Ausfallssicherheit 44:43.480 --> 44:45.660 testen und nicht nur die Funktion. 44:46.280 --> 44:50.400 Man denkt immer zuerst an die Funktion, aber ist das Ding auch 44:50.400 --> 44:51.240 sichtbar? 44:51.400 --> 44:53.640 Und natürlich führt man jetzt auch Leistungstests durch. 44:55.740 --> 44:57.420 Also Last- und Stresstests. 44:58.660 --> 45:00.420 Was ist eigentlich ein Regressionstest? 45:01.360 --> 45:07.820 Regressionstest ist einfach ein Test, unabhängig von wie viel man 45:07.820 --> 45:11.660 testet, sondern einfach die Wiederholung eines bereits bestehenden 45:11.660 --> 45:12.100 Tests. 45:12.100 --> 45:16.300 J -Unit macht Ihnen das ja sehr leicht, auf Knopfdruck wieder einen 45:16.300 --> 45:20.900 Testsuite abfahren zu lassen, um festzustellen, ob nach 45:20.900 --> 45:25.380 Pflegeänderungen, Wartung eines Systems es nicht weiter zurückgefallen 45:25.380 --> 45:27.580 ist und alte Fehler wieder auftauchen. 45:28.260 --> 45:31.940 Das ist die Regression, also das Rückfallen, das Regressieren auf 45:31.940 --> 45:35.840 einen früher schlechteren Stand und Eigenschaftspunkt. 45:38.160 --> 45:38.640 Jawohl. 45:43.150 --> 45:45.910 Abnahmetests, da habe ich jetzt nicht mehr viel zu sagen, da wirkt der 45:45.910 --> 45:53.610 Kunde mit, beobachtet, führt die Feder, das heißt, er schreibt auf, 45:53.670 --> 45:56.110 was passiert und schreibt vor, in welcher Reihenfolge alles gemacht 45:56.110 --> 45:56.350 wird. 45:57.190 --> 46:00.210 Die reale Einsatzumgebung beim Kunden wird dazu benutzt und nach 46:00.210 --> 46:02.610 Möglichkeit auch die Daten des Kunden verwendet. 46:07.770 --> 46:10.610 Und der Auftraggeber kann natürlich auch noch eigene Testszenarien 46:10.610 --> 46:12.170 sich hinzudenken. 46:13.470 --> 46:17.370 Die formale Abnahme ist diejenige, die sagt, jetzt sind wir fertig. 46:17.810 --> 46:21.350 Der Kunde sagt entweder ja, nehme ich ab, so wie es ist, selbst wenn 46:21.350 --> 46:22.750 es noch da und dort klemmt. 46:23.610 --> 46:27.890 Vielleicht gibt es dann eine oder andere Fehler oder Unschönheit, die 46:27.890 --> 46:29.530 noch beseitigt werden muss. 46:29.990 --> 46:34.330 Aber wenn der Kunde sagt, ich nehme es so, dann können wir den Rest in 46:34.330 --> 46:38.050 der Wartung korrigieren, aber ich kann das System schon benutzen, dann 46:38.050 --> 46:41.450 wäre die Abnahme erfolgreich und damit steht die Zahlung an. 46:41.670 --> 46:44.310 Das heißt, der Kunde muss jetzt für die Entwicklung zahlen und Sie als 46:44.310 --> 46:46.190 Entwickler freuen sich da natürlich. 46:46.370 --> 46:47.590 Jetzt endlich kommt Geld rein. 46:52.820 --> 46:55.000 Literatur, ja, gibt es viel. 46:56.900 --> 47:00.660 Lesen Sie den Teil. 47:01.960 --> 47:03.760 Im Brückenditor mindestens. 47:07.080 --> 47:10.360 Bedingungen über Deckungstechniken, die haben wir nicht besprochen, 47:10.600 --> 47:12.140 also das Thema ist vielleicht uninteressant. 47:13.060 --> 47:15.420 Jedenfalls nicht wichtig für die Klausur. 47:18.200 --> 47:20.520 Dann sind wir also erstmal mit dem Test durch. 47:24.160 --> 47:25.680 Es gibt noch Testhelfer. 47:26.740 --> 47:28.520 Die Testhelfer kennen Sie aber schon. 47:29.360 --> 47:31.940 Wesentlich war das J-Unit, das haben wir ja schon besprochen. 47:44.130 --> 47:50.070 Ich springe jetzt ein bisschen vor von Kapitel 5 auf Kapitel 8, weil 47:50.070 --> 47:52.730 wir jetzt noch eben diesen wichtigen Stoff der Prozessmodelle 47:52.730 --> 47:53.570 behandeln müssen. 48:01.350 --> 48:05.690 Wir werden einige Prozessmodelle oder auch Vorgehensmodelle 48:05.690 --> 48:11.270 besprechen, nämlich Programmieren durch Probieren, das ist ganz 48:11.270 --> 48:11.670 einfach. 48:11.910 --> 48:14.510 Das Wasserfallmodell kennen wir schon, das bespreche ich nicht mehr. 48:14.930 --> 48:17.110 Das Fahrmodell, also die Variante vom Wasserfallmodell. 48:18.210 --> 48:21.270 Das Prototypenmodell, iterative Modelle, synchronisiere und 48:21.270 --> 48:24.570 stabilisiere und schließlich die sogenannten agilen Methoden, die 48:24.570 --> 48:25.970 heute sehr modern sind. 48:27.590 --> 48:30.950 Erstmal soll ich Ihnen sagen, vielleicht fehlt eigentlich eine Folie, 48:31.530 --> 48:33.170 was ist ein Prozessmodell? 48:33.170 --> 48:40.770 Ein Prozessmodell sagt mir für die Softwareentwicklung, in welchen 48:40.770 --> 48:46.310 Schritten wir vorgehen, in welcher Reihenfolge, was die Eingabe und 48:46.310 --> 48:50.070 Ausgaben dieser Schritte sind, zum Beispiel Wasserfallmodell, kann man 48:50.070 --> 48:51.030 sich das gut vorstellen. 48:51.370 --> 48:55.470 Wir haben sechs Schritte und jeder muss komplett abgeschlossen sein 48:55.470 --> 48:59.530 und da kommt rein, was weiß ich, in den Turf die Anforderung, das 48:59.530 --> 49:03.370 Pflichtenheft und raus kommt ein Turf und ein Grobplan der 49:03.370 --> 49:04.450 Schnittstellen und so weiter. 49:06.650 --> 49:07.730 Wer macht es? 49:08.270 --> 49:09.430 Zu welchem Zeitpunkt? 49:10.130 --> 49:12.030 Und wann weiß ich, dass er fertig ist? 49:12.570 --> 49:14.230 Das sagt mir ein Prozessmodell. 49:15.330 --> 49:20.490 Die Arbeit in unterschiedliche Aufgaben und weist sie den 49:20.490 --> 49:22.950 entsprechenden Leuten zu. 49:24.730 --> 49:28.950 Das Programmieren durch Probieren wahrscheinlich das, was sie benutzen 49:28.950 --> 49:29.290 noch. 49:30.190 --> 49:34.030 Code and Fix oder Trial and Error, das sagt, ich fange einfach mal an 49:34.030 --> 49:37.730 und dann teste ich das Ding und wenn es nicht funktioniert, dann 49:38.510 --> 49:39.230 repariere ich es halt. 49:40.490 --> 49:46.290 Man bemerke, man stellt also ein vorläufiges Programm und testet es so 49:46.290 --> 49:47.830 lange, bis es passt. 49:50.830 --> 49:54.970 Also man kann schnell Code erzeugen, vielleicht ohne zusätzlichen, 49:54.970 --> 49:57.750 nutzlosen Anforderungsermittlungen und so weiter. 49:57.850 --> 49:58.310 Was soll das? 49:58.430 --> 49:59.450 Was soll ein Entwurf? 49:59.530 --> 50:00.370 Das mache ich im Kopf. 50:01.710 --> 50:02.530 Das stimmt schon. 50:04.090 --> 50:07.070 Der Code, der dabei entsteht, ist in der Regel unstrukturiert und 50:07.070 --> 50:09.570 schlecht zu warten und also auf Wartung nicht vorbereitet. 50:09.790 --> 50:11.010 Es gibt ja keinen Entwurf. 50:11.870 --> 50:15.610 Die Probleme, die dabei auftreten, ist, ich hatte auch gar keine 50:15.610 --> 50:16.590 Anforderungsanalyse. 50:16.710 --> 50:20.490 Das heißt, ob ich den Kundenwünsche jetzt treffe, ist eher mehr oder 50:20.490 --> 50:21.450 weniger zufällig. 50:21.450 --> 50:22.190 Ja. 50:23.350 --> 50:26.350 Das war übrigens auch der Grund, warum man von Code und Fix weg ist. 50:27.250 --> 50:29.490 Es wäre doch vernünftig, wenn wir ein bisschen planen, damit wir 50:29.490 --> 50:31.030 wenigstens wissen, was wir machen sollen. 50:33.230 --> 50:36.250 Die Wartung und Pflege ist kostspielig, weil das Programm nicht darauf 50:36.250 --> 50:37.070 vorbereitet wird. 50:38.230 --> 50:40.310 Die Dokumentation ist sowieso nicht vorhanden. 50:41.250 --> 50:45.270 Und für Teamarbeit ist das Modell sowieso komplett ungeeignet. 50:45.590 --> 50:49.710 Weil ich ja nie gesprochen habe darüber, wie ich das Gesamtsystem 50:49.710 --> 50:50.190 aufteile. 50:50.290 --> 50:52.630 Ich bin einfach hingegangen, habe zu codieren begonnen. 50:53.550 --> 50:57.750 Dann habe ich ein Spaghetti-Code erzeugt, der schwer zu lesen ist. 50:59.170 --> 51:01.130 Also, so hat man mal begonnen. 51:01.630 --> 51:03.570 So beginnt man vielleicht als erster Programmierer. 51:04.230 --> 51:06.830 Aber wenn Sie erstmal in einem größeren Team arbeiten, dann geht das 51:06.830 --> 51:07.610 einfach gar nicht. 51:09.690 --> 51:12.970 Die Gegenreaktion darauf war eben das Wasserfallmodell, das sagt, wir 51:12.970 --> 51:15.570 haben auch eine Planungsphase, eine Definitionsphase, da machen wir 51:15.570 --> 51:21.050 die Definition ganz exakt, sodass nichts mehr in Frage steht und dann 51:21.050 --> 51:24.610 brauchen wir niemanden mehr Fragen danach und entwerfen und 51:24.610 --> 51:28.390 implementieren das, machen eine gute Testphase dahinter und 51:28.390 --> 51:31.110 schließlich gehen wir in Einsatz und Wartung des fertigen Systems. 51:32.310 --> 51:34.090 Wunderbar, die Schritte kennen wir. 51:36.190 --> 51:41.190 Es wurde bereits 1956 als erstes Mal für Software vorgeschlagen, ist 51:41.190 --> 51:45.150 schon viel älter, für andere industrielle Fertigungsprozesse gab es 51:45.150 --> 51:48.890 die schon vorher, aber das ist das erste Mal auf Software adaptiert 51:48.890 --> 51:51.730 gewesen, also vor mehr als 50 Jahren schon. 51:55.050 --> 51:58.710 Die Rückkopplungen, die Pfeile, die wurden, auf die hat man erst 1970 51:58.710 --> 52:01.010 gedacht, dass man das eigentlich machen könnte, wenn hier etwas nicht 52:01.010 --> 52:03.750 stimmt, dass man nochmal in der Definition nachschaut und vielleicht 52:03.750 --> 52:05.170 sogar die Definition verbessert. 52:06.790 --> 52:10.570 Aber es gibt kein phasenübergreifende Rückkopplung. 52:10.770 --> 52:14.450 Es gibt keinen Fall, der im Wasserfallmodell vorgesehen wäre, dass ich 52:14.450 --> 52:16.310 von der Implementierung nochmal zur Planung gehe. 52:17.370 --> 52:23.570 Wollen wir mal schauen, was das Wasserfallmodell jetzt ein bisschen 52:23.570 --> 52:28.770 unhandlich macht und das ist, dass jede Aktivität in der vorgegebenen 52:28.770 --> 52:30.650 Reihenfolge vollständig durchführen muss. 52:31.570 --> 52:35.230 Also ich muss, selbst wenn ich gar nicht weiß, was ich genau machen 52:35.230 --> 52:40.210 muss, die komplette Planung und Definitionsphase jede für sich 52:40.210 --> 52:41.670 komplett durchführen. 52:42.030 --> 52:47.710 Ich darf an keiner Stelle etwas freilassen und eventuell einen 52:47.710 --> 52:52.790 Prototyp bauen oder explorativ entwickeln und sagen, so geht es nicht, 52:52.950 --> 52:56.450 ich muss das anders machen, ich muss alles vorher festlegen und damit 52:56.450 --> 53:01.770 legt man oft viel Unsinniges fest, was man dann unsinnigerweise auch 53:01.770 --> 53:05.730 noch implementieren und testen muss, weil es eben so dasteht. 53:07.250 --> 53:11.950 Dieses streng Sequenzselektivieren ist der eigentliche Nachteil des 53:12.490 --> 53:14.970 Wasserfallmodells, nicht die verschiedenen Phasen, denn die 53:14.970 --> 53:17.790 verschiedenen Tätigkeiten, habe ich Ihnen ja ganz von Anfang gesagt, 53:18.070 --> 53:19.270 brauchen wir in jedem Fall. 53:19.430 --> 53:22.490 Ich muss eine Anforderung machen, ich muss einen Entwurf machen, ich 53:22.490 --> 53:25.570 muss eine Implementierung machen, aber vielleicht muss ich nicht alles 53:25.570 --> 53:30.170 komplett vollständig machen, bevor ich mit der Teilimplementierung 53:30.170 --> 53:31.190 beginne. 53:32.570 --> 53:36.450 Nennt man übrigens auch dokumentgetriebenes Modell, weil jede Phase, 53:36.610 --> 53:42.610 jeder Schritt in diesem Wasserfallmodell einen Dokumentensatz liefert, 53:42.810 --> 53:44.770 der im nächsten Schritt weiter benutzt wird. 53:45.730 --> 53:51.150 Einfach und verständlich, die Benutzerbeteiligung ist nur bis zur 53:51.150 --> 53:54.930 Definitionsphase vorgesehen, danach ist sie überflüssig. 53:55.350 --> 53:58.850 Wir haben ja alles definiert und gerade das geht oftmals nicht. 53:59.950 --> 54:03.470 Daher, das habe ich schon gesagt, die phasenübergreifende 54:03.470 --> 54:06.550 Rückkopplung, Parallelisierungspotential ist möglicherweise nicht 54:06.550 --> 54:11.090 ausgeschöpft, denn die Entwickler, die warten jetzt, dass endlich mal 54:11.090 --> 54:13.890 die Anforderungsanalyse fertig ist, damit sie beginnen können. 54:14.130 --> 54:18.070 Aber, wenn die Anforderungsanalyse vielleicht zu 70% fertig wäre, 54:18.210 --> 54:20.890 könnten sie an den ersten 70% ja eigentlich schon arbeiten. 54:21.530 --> 54:23.950 Aber gerade das sieht das Phasenmodell nicht vor. 54:24.690 --> 54:26.990 Die mögliche Parallelisierung von Schritten. 54:28.330 --> 54:31.950 Sie erzwingt genaue Spezifikationen von Sachen, die vielleicht nicht 54:31.950 --> 54:36.010 ganz durchdrungen sind, von Benutzerschnittstellen und Funktionen und 54:36.010 --> 54:37.710 dann später zu nutzlosem Code. 54:39.710 --> 54:43.530 Daher ist das Wasserfallmodell eher ein pädagogisches Modell, mit dem 54:43.530 --> 54:48.110 ich klar sagen kann, welche Arten von Tätigkeiten wir durchführen 54:48.110 --> 54:48.430 müssen. 54:49.810 --> 54:51.990 Und dann können wir sie auch in reiner Form studieren, wie in dieser 54:51.990 --> 54:53.810 Vorlesung und erlernen. 54:55.910 --> 54:58.890 Und außerdem zeigt uns das Wasserfallmodell ganz klar, dass es nicht 54:58.890 --> 54:59.690 nur codieren ist. 54:59.690 --> 55:00.870 Codieren und testen. 55:01.130 --> 55:04.210 Ein bisschen mehr Anforderungsanalyse von der Definitionsphase, 55:04.310 --> 55:04.910 Entwurfsphase. 55:09.690 --> 55:11.470 Das nächste ist das V-Modell. 55:13.730 --> 55:17.150 Das V-Modell ist eigentlich nichts anderes als das Phasenmodell, das 55:17.150 --> 55:22.210 Wasserfallmodell, aber man hat nun gesagt, für jede dieser Phasen die 55:22.210 --> 55:26.170 Entwurfsphase ist etwas aufgegliedert, ein Grobentwurf und ein 55:26.170 --> 55:26.670 Feinentwurf. 55:26.670 --> 55:29.250 Sie wissen natürlich, was Grobentwurf und Feinentwurf ist. 55:29.350 --> 55:31.130 Wenn nicht mehr, bitte nachschauen. 55:31.450 --> 55:34.610 Ich habe es definiert, was der Grobentwurf und der Feinentwurf ist. 55:37.310 --> 55:39.890 Eine Modulimplementierung oder auch Komponentenimplementierung kommt 55:39.890 --> 55:43.190 hier unten, aber alle diese Schritte sind mit bestimmten Tests 55:43.190 --> 55:44.370 gekoppelt. 55:45.050 --> 55:49.890 Also es gibt keine große Testphase ganz am Schluss, obwohl den 55:49.890 --> 55:52.950 Abnahmetest, Systemtest, Integrationstest gibt es natürlich auch. 55:53.550 --> 55:57.790 Aber sie sagen, da im Integrationstest teste ich den Feinentwurf, 55:58.230 --> 55:59.150 passt alles zusammen. 55:59.490 --> 56:02.270 Das ist genau der Feinentwurf, wo ich ja die genauen Schnittstellen 56:02.270 --> 56:03.870 festlege und die Abhängigkeiten. 56:04.310 --> 56:07.470 Der Systemtest ist der Grobentwurf, passt alles zusammen. 56:08.150 --> 56:14.550 Und der Abnahmetest sagt, habe ich die Anforderungen erfüllt. 56:16.430 --> 56:19.570 Sie erinnern sich, ich sage nach vorhin, der Abnahmetest sagt ja, ich 56:19.570 --> 56:22.610 benutze das System an der äußersten verfügbaren Schnittstelle, das 56:22.610 --> 56:25.730 heißt, ich schaue eigentlich nach, ob es meine Anforderungen erfüllen 56:25.730 --> 56:26.030 kann. 56:27.690 --> 56:32.570 Okay, aber es kommt keine neue Tätigkeit hinzu, nur das Verständnis, 56:33.070 --> 56:37.170 dass wir alle diese Phasen auch testen müssen, überprüfen müssen, 56:37.310 --> 56:40.650 vielleicht auch manuell, und dass diese Kopplung besteht. 56:40.930 --> 56:45.670 So, jetzt meinen alle, das V-Modell heißt V-Modell wegen dieses Vs 56:45.670 --> 56:45.910 hier. 56:47.550 --> 56:49.750 Sie werden sich so merken, stimmt aber nicht. 56:49.750 --> 56:55.410 Das V-Modell heißt, das V kommt nur vom Vorgehensmodell. 56:58.270 --> 57:05.710 So, und dann gibt es ein V-Modell Extended, auch ein Vorgehensmodell, 57:06.310 --> 57:09.230 das ist die Oberbürokratie, die man sich vorstellen kann. 57:11.330 --> 57:15.750 Das V-Modell XT selbst, stellen Sie sich mal vor, 500 Seiten nur für 57:15.750 --> 57:16.730 das Vorgehensmodell. 57:18.050 --> 57:19.550 Ich erspare Ihnen das. 57:19.990 --> 57:22.490 Wir können hier in der Vorlesung ziemlich wenig darüber lernen. 57:22.770 --> 57:25.170 Es sind ein paar Handreichungen mitgegeben. 57:25.470 --> 57:27.990 Wenn Sie es mal benutzen müssen, prüfen tue ich das nicht. 57:29.310 --> 57:34.390 Aber wenn Sie immer Software für die öffentliche Hand, also für 57:34.390 --> 57:40.310 Landes, Bundes, Regierung, für öffentliche Behörden, Polizei und so 57:40.310 --> 57:46.710 weiter, schreiben müssen, dann ist es höchstwahrscheinlich, dass das 57:46.710 --> 57:46.870 nicht möglich ist. 57:47.510 --> 57:49.050 Und dann müssen Sie sich leider damit befassen. 57:50.710 --> 57:54.150 Außerdem ist das V-Modell XT auch so, dass es schon auch eine 57:54.970 --> 57:58.350 ordentliche Erweiterung von dem ursprünglichen V-Modell ist, weil es 57:58.350 --> 58:01.490 hier auch gekoppelte Hardware und Software Entwicklung erlaubt. 58:03.410 --> 58:06.130 Das Wasserfallmodell sagt nur etwas über Software. 58:06.610 --> 58:10.010 Was ist, wenn Sie Toll Collect machen müssen, wo Sie ein Gerät bauen 58:10.010 --> 58:11.770 müssen, das in jeden Laster rein muss? 58:12.410 --> 58:16.130 Wenn Sie ein mobiles System bauen, wo Sie speziell mobile Funkgeräte 58:16.130 --> 58:17.650 brauchen, wie geht das eigentlich? 58:17.950 --> 58:19.190 Wie stimme ich das ab? 58:19.570 --> 58:26.650 Und dann gibt es ein Vorgehensmodell im XT, im V-Modell XT, das Ihnen 58:26.650 --> 58:27.510 da ein bisschen hilft. 58:28.590 --> 58:30.030 Es nimmt Ihnen keine Arbeit ab. 58:30.210 --> 58:32.030 Das entwickeln müssen Sie alles noch selber machen. 58:32.670 --> 58:37.450 Nur, über was muss ich denn alles organisatorisch und prozessoral 58:37.450 --> 58:38.150 nachdenken? 58:38.890 --> 58:38.990 Okay. 58:40.830 --> 58:42.850 Jaja, da gibt es ziemlich viel. 58:43.590 --> 58:46.570 30 Rollen, Akquisiteur, Anwender und so weiter. 58:49.150 --> 58:51.170 Aber es ist alles schön definiert. 58:51.450 --> 58:52.930 Das hilft einem natürlich, wenn man es braucht. 58:55.970 --> 58:58.110 Wie gesagt, das überspringen wir. 58:59.250 --> 59:00.610 Sie sehen, das ist ziemlich viel Zeugs. 59:03.410 --> 59:12.950 Es gibt da übrigens auch ein Produktzustands- Erste Version des 59:12.950 --> 59:15.930 Produkts wird erstellt, dann ist es im Zustand in Bearbeitung. 59:16.850 --> 59:20.750 Dann kann es sein, dass es geprüft wurde durch eigenständige 59:20.750 --> 59:23.030 Qualitätssicherung und dann ist es im Zustand vorgelegt. 59:24.650 --> 59:27.810 Wenn es dann inhaltlich und formal korrekt ist, dann ist es im Zustand 59:27.810 --> 59:34.670 fertiggestellt und dann gibt es verschiedene Übergänge verschiedener 59:34.670 --> 59:34.950 Art. 59:35.990 --> 59:39.810 Also auch da ist natürlich die Informatik mit dabei. 59:40.570 --> 59:42.830 Wir schauen uns jetzt aber an das Prototyp-Modell. 59:44.790 --> 59:51.610 Beim Prototyp-Modell sagt man, ich bin nicht in der Lage, die 59:51.610 --> 59:55.790 Anforderungen, die benötigt sind, fertig, vollständig zu definieren, 59:56.950 --> 59:58.270 ohne etwas auszuprobieren. 59:59.630 --> 01:00:02.630 Oder aber ich weiß nicht, ob ich bestimmte Anforderungen überhaupt 01:00:02.970 --> 01:00:06.270 verwirklichen kann, ob es schnell genug läuft, ob ich entsprechende 01:00:06.270 --> 01:00:09.030 Ressourcen, Daten, Algorithmen habe. 01:00:09.250 --> 01:00:10.350 Ich muss auch das prüfen. 01:00:10.590 --> 01:00:12.370 Könnte gehen, könnte auch nicht gehen. 01:00:13.010 --> 01:00:17.250 Dazu macht man einen Prototypen. 01:00:18.110 --> 01:00:23.590 Der Prototyp ist also ein eingeschränkt funktionsfähiges System, das 01:00:23.590 --> 01:00:26.730 zum einen die Arbeitsmodelle und Vertrauen zwischen Arbeitern und 01:00:26.730 --> 01:00:32.550 Kunden stärkt, aber es muss auch wichtige Fragen klären. 01:00:32.550 --> 01:00:34.090 Das sehen wir dann gleich. 01:00:38.010 --> 01:00:41.810 Ein gewisser Frederick Brooks hat ein Buch geschrieben, das heißt The 01:00:41.810 --> 01:00:43.610 Mythical Man-Month. 01:00:44.410 --> 01:00:47.150 Das dürfte er heute gar nicht mehr sagen, dann müsste er heute Person 01:00:47.150 --> 01:00:47.710 -Month stehen. 01:00:50.270 --> 01:00:54.770 Das mythische Personenmonat, das sagt er eben, dass man Personenmonate 01:00:54.770 --> 01:00:57.790 nicht gegeneinander beliebig aufrechnen kann, indem ich mehr Leute in 01:00:57.790 --> 01:01:00.610 das gleiche Projekt stecke, wird das Projekt schneller abgewickelt. 01:01:00.990 --> 01:01:02.970 Das findet meist nicht statt. 01:01:03.530 --> 01:01:05.010 Es dauert dann eben noch länger. 01:01:05.550 --> 01:01:09.150 Aber er sagt auch, plan to throw one away. 01:01:09.650 --> 01:01:12.890 Also wenn du ein großes System brauchst, rechne damit, dass du eines 01:01:13.670 --> 01:01:16.790 wegwerfen wirst, weil selbst wenn du nicht damit rechnest, wirst du 01:01:16.790 --> 01:01:17.570 das sowieso tun. 01:01:18.110 --> 01:01:19.410 Plan to throw one away. 01:01:19.630 --> 01:01:20.390 You will, anyhow. 01:01:21.350 --> 01:01:22.570 Also Prototyp wegwerfen. 01:01:23.370 --> 01:01:25.030 Was macht das Prototyp Modell 1? 01:01:25.170 --> 01:01:29.670 Das sagt, ich muss bestimmte wichtige Fragen oder Unsicherheiten 01:01:29.670 --> 01:01:30.070 klären. 01:01:30.330 --> 01:01:33.630 Und das kann bedeuten, dass ich erstmal eine vorläufige Systemanalyse 01:01:33.630 --> 01:01:38.810 mache, sage, hier ist ein Problem, ich weiß nicht, wie ich das angehen 01:01:38.810 --> 01:01:41.250 soll, wie ich das spezifizieren soll, was ich da verlangen soll. 01:01:41.870 --> 01:01:44.650 Dann mache ich einen Prototypentwurf und Implementierung, wie gesagt, 01:01:46.310 --> 01:01:48.870 eingeschränktes System und führe den Prototypen vor. 01:01:52.450 --> 01:01:58.370 Und dann habe ich hoffentlich die wichtigen Unsicherheiten beantwortet 01:01:58.370 --> 01:02:01.690 und gehe dann über in ein anderes Entwicklungsmodell, das endgültige 01:02:01.690 --> 01:02:07.030 Modell, zum Beispiel ein Wasserfallmodell oder eines der agilen 01:02:07.030 --> 01:02:09.150 Modelle, die wir noch sehen wollen. 01:02:10.910 --> 01:02:12.150 Das ist Prototyp Modell 1. 01:02:12.310 --> 01:02:17.610 Prototyp Modell 2 sagt, ich orientiere mich wieder am Phasenmodell und 01:02:17.610 --> 01:02:20.290 sehe nach, wo ich diese Prototypen bauen muss. 01:02:21.710 --> 01:02:29.550 Also zum Beispiel könnte es sein, dass ich einen Prototyp eines 01:02:30.530 --> 01:02:33.510 Teilsystems machen muss, um zu sehen, wie ich die Arbeit verteile. 01:02:33.750 --> 01:02:36.350 Stellen Sie sich vor, Sie müssten GIT bauen. 01:02:37.730 --> 01:02:41.810 Sie müssten GIT neu bauen und da ist die Frage, wie verteile ich denn 01:02:41.810 --> 01:02:46.190 eigentlich die einzelnen Komponenten auf die verschiedenen 01:02:46.190 --> 01:02:48.990 Dienstgeber, auf die verschiedenen Rechner der Beteiligten. 01:02:49.390 --> 01:02:52.330 Ist überhaupt das zuverlässig genug? 01:02:53.730 --> 01:02:58.450 Wenn Leute ihre Rechner abstellen und wieder mal anstellen, was ist 01:02:58.450 --> 01:03:02.270 denn die Wahrscheinlichkeit, dass ich dann die aktuelle Software 01:03:02.270 --> 01:03:02.690 bekomme? 01:03:02.930 --> 01:03:04.310 Was muss ich denn da eigentlich machen? 01:03:04.730 --> 01:03:06.530 Wo muss ich die Caches anlegen und so weiter? 01:03:06.650 --> 01:03:09.110 Also die Datenverteilung und Verfügbarkeit. 01:03:09.870 --> 01:03:14.630 Und da kann es sein, dass Sie dazu einen Entwurf machen, der das ganze 01:03:14.630 --> 01:03:18.150 Ein - und Ausbuchen gar nicht richtig kann und viele der Schönheiten 01:03:18.150 --> 01:03:24.470 von GIT nicht bietet, aber dafür eben die Datenverteilung prototypisch 01:03:24.470 --> 01:03:27.690 implementiert und nachzusehen, ob es überhaupt im Prinzip 01:03:27.690 --> 01:03:28.570 funktionieren kann. 01:03:29.370 --> 01:03:33.210 Dann würde ich an der Stelle den Prototypen anwerfen, nämlich hier 01:03:33.210 --> 01:03:36.090 einen Entwurf machen und natürlich eine Implementierung davon. 01:03:36.750 --> 01:03:41.950 Oder aber wir sagen, da brauchen wir eine Nutzerschnittstelle, aber 01:03:41.950 --> 01:03:44.570 wie soll denn die eigentlich sein? 01:03:44.750 --> 01:03:48.850 Was ist denn eine schöne Nutzerschnittstelle für mein Mobilgerät und 01:03:48.850 --> 01:03:51.650 wie sieht das aus für mein Tablett und wie sieht das aus aus meinem 01:03:52.870 --> 01:03:54.930 Standrechner oder Tragbahnrechner? 01:03:55.610 --> 01:03:58.790 Da mache ich jetzt einen Prototyp für die Nutzerschnittstelle, da 01:03:58.790 --> 01:03:59.690 läuft noch nichts. 01:04:00.250 --> 01:04:04.770 Aber die ganzen Interaktionselemente und Anzeigen sind da und ich kann 01:04:04.770 --> 01:04:07.770 damit schon zum Kunden gehen und sagen, haben Sie sich das so 01:04:07.770 --> 01:04:08.330 vorgestellt? 01:04:08.730 --> 01:04:12.210 In der Reihenfolge werden die Daten abgefragt, die Eingaben gegeben, 01:04:12.330 --> 01:04:13.370 die Ausgaben geliefert. 01:04:13.610 --> 01:04:14.610 Ist es so richtig? 01:04:15.610 --> 01:04:19.830 Also machen Sie hier einen Nutzerschnittstellenprototyp, ohne dass Sie 01:04:19.830 --> 01:04:22.850 das Gesamtsystem spezifiziert haben und jetzt sehen Sie, warum Ihnen 01:04:22.850 --> 01:04:24.430 diese Prototypen helfen. 01:04:24.550 --> 01:04:26.930 Sie können sagen, aha, so wollen wir es. 01:04:27.950 --> 01:04:32.850 Vielleicht nicht exakt so wie der Prototyp, aber der Prototyp sagt mir 01:04:32.850 --> 01:04:34.730 dann, wie ich es richtig machen müsste. 01:04:35.870 --> 01:04:41.010 Und dann kann ich das System komplett spezifizieren, wenn ich in das 01:04:41.010 --> 01:04:42.910 Wasserfallmodell einsteigen wollte. 01:04:44.750 --> 01:04:46.810 Okay, aber es gibt noch mehr. 01:04:47.690 --> 01:04:52.290 Es gibt noch das Iterative Versions Modell. 01:04:55.950 --> 01:04:57.610 Das zeige ich Ihnen am besten am Bild. 01:04:59.910 --> 01:05:04.890 Beim Prototyp haben Sie jetzt zwei Versionen, den Prototypen und das 01:05:04.890 --> 01:05:05.530 echte System. 01:05:05.730 --> 01:05:09.130 Das Iterationsmodell sagt, wir haben mehrere Zwischenschritte, bevor 01:05:09.130 --> 01:05:10.750 wir ein System haben. 01:05:11.530 --> 01:05:16.110 Das heißt, wir fügen unserem Produkt nach und nach Funktionalität 01:05:16.110 --> 01:05:16.570 hinzu. 01:05:18.970 --> 01:05:20.930 Ähnliche Einsatzgebiete wie beim Prototypmodell. 01:05:21.190 --> 01:05:24.430 Unsicherheiten gibt es und wir wissen nicht, wie wir sie lösen. 01:05:26.350 --> 01:05:29.290 Aber wir versuchen jetzt, mehr zu verwenden, als beim Prototypmodell. 01:05:29.370 --> 01:05:32.550 Beim Prototypmodell sagten wir ja, wegwerfen, neu programmieren. 01:05:33.230 --> 01:05:35.250 Und nur die Erkenntnisse werden übertragen. 01:05:35.750 --> 01:05:38.650 Beim Iterationsmodell sagt man, ich baue schon Software, die nachher 01:05:38.650 --> 01:05:40.890 auch benutzt werden wird und erweitere sie Schritt für Schritt. 01:05:43.130 --> 01:05:44.870 Da gibt es jetzt zwei Ansätze. 01:05:45.210 --> 01:05:47.370 Das eine heißt evolutionär und inkrementell. 01:05:47.690 --> 01:05:51.370 Das ist nicht richtig deskriptiv, aber ich erkläre es Ihnen am 01:05:51.370 --> 01:05:51.810 Beispiel. 01:05:57.010 --> 01:06:00.330 Iterative Modelle orientieren sich ebenfalls am Wasserfall. 01:06:01.410 --> 01:06:07.370 Aber die sagen, wir planen hier oben mehrere Iterationen, sagen wir 01:06:07.370 --> 01:06:07.990 drei Stück. 01:06:09.530 --> 01:06:12.530 Und zwar haben wir drei Ausbaustufen des Systems. 01:06:12.850 --> 01:06:19.610 Version 1 hat den Funktionsumfang und Version 2 einen erweiterten und 01:06:19.610 --> 01:06:22.690 der dritte enthält den endgültigen Funktionsumfang. 01:06:23.730 --> 01:06:27.270 Und wir gehen jetzt hier und entwickeln nach dem Wasserfallmodell 01:06:27.270 --> 01:06:34.430 einfach Version 1, gehen in eine Art Test, wo der Betrieb und die 01:06:34.430 --> 01:06:35.730 Evaluierung schon ist. 01:06:36.150 --> 01:06:37.970 Sind wir jetzt damit fertig? 01:06:38.690 --> 01:06:46.330 Wenn nicht, dann entwerfen und implementieren wir Phase 2, Version 2 01:06:46.330 --> 01:06:51.370 und erneut gehen wir zurück und sagen, dann machen wir auch noch eine 01:06:51.370 --> 01:06:52.270 dritte Ausbaustufe. 01:06:53.070 --> 01:06:57.670 Der Punkt ist, bei der inkrementellen, bei der iterativen Version sind 01:06:57.670 --> 01:06:59.470 alle Ausbaustufen vorgeplant. 01:07:06.090 --> 01:07:11.410 Im Gegensatz zum evolutionären, da sagen wir, wir planen nur immer 01:07:11.410 --> 01:07:15.190 einen nächsten Schritt vorwärts, eine nächste Version und wenn wir 01:07:15.190 --> 01:07:17.350 noch nicht zufrieden sind, dann gehen wir noch mal ganz in den Anfang 01:07:17.350 --> 01:07:18.770 zurück und planen den Rest. 01:07:19.410 --> 01:07:21.310 Entschuldigung, planen die nächste Ausbaustufe. 01:07:24.110 --> 01:07:27.670 Hier sagen sie also schon, ich weiß, was ich alles machen muss, aber 01:07:27.670 --> 01:07:31.530 ich liefere in drei Phasen, in drei Stufen und der sagt, wir wissen 01:07:31.530 --> 01:07:35.510 ein bisschen was, wir können mal die erste Version liefern und die 01:07:35.510 --> 01:07:37.150 zweite überlegen wir uns überhaupt erst später. 01:07:39.630 --> 01:07:42.070 Es gibt natürlich auch so ein Zwischending, da gehe ich in die 01:07:42.070 --> 01:07:44.890 Definition zurück, aber auch das ist das evolutionäre Modell. 01:07:45.230 --> 01:07:50.190 Wichtig ist, inkrementell sagt, alle Versionen sind vorausgeplant, in 01:07:50.190 --> 01:07:52.850 voller Schönheit und wir fügen sie nur nach und nach hinzu. 01:07:52.850 --> 01:07:57.010 Das funktioniert am besten, wenn die Unsicherheiten im Entwurf oder in 01:07:57.010 --> 01:07:58.710 der Implementierung stecken. 01:08:00.490 --> 01:08:03.830 Das Evolutionäre fängt immer von vorne an und sagt, wenn da etwas 01:08:03.830 --> 01:08:07.850 komplett verkehrt war, dann können wir es hier oben auch schon in der 01:08:07.850 --> 01:08:09.030 Systemdefinition ändern. 01:08:09.870 --> 01:08:09.870 Okay, 01:08:14.230 --> 01:08:14.470 gut. 01:08:16.350 --> 01:08:18.070 Da sind wir mit dem Modell auch schon durch. 01:08:19.250 --> 01:08:20.830 Gibt es dazu Fragen vielleicht? 01:08:20.830 --> 01:08:21.350 Nein? 01:08:29.500 --> 01:08:33.560 Dann gehen wir zum Microsoft-Modell. 01:08:35.780 --> 01:08:40.260 Das kam 1995 heraus, also ist auch schon wieder 20 Jahre alt. 01:08:40.700 --> 01:08:43.920 Synchronisieren und Stabilisieren oder Synchronize and Stabilize. 01:08:44.520 --> 01:08:48.960 So hat Microsoft das 1995 gemacht. 01:08:49.100 --> 01:08:54.440 Da gibt es ein dickes Buch von Herrn Cusumano und Selby. 01:08:55.300 --> 01:08:58.160 Und natürlich wollte jeder wissen, wie Microsoft das macht. 01:08:58.940 --> 01:09:02.460 Denn das war auch damals einer der führenden Softwarehersteller. 01:09:02.880 --> 01:09:05.580 Wie macht Microsoft das eigentlich, wenn die ein neues Produkt geben? 01:09:06.140 --> 01:09:09.320 Und ich kann es Ihnen ganz kurz sagen, es ist eine Variante des 01:09:09.320 --> 01:09:12.300 iterativen Prototypmodells. 01:09:13.960 --> 01:09:15.240 Schauen wir uns das genau an. 01:09:15.660 --> 01:09:19.400 Das Problem ist, Sie haben ungefähr 200 Programmierer, manchmal auch 01:09:19.400 --> 01:09:21.220 mehr, für das Betriebssystem sind es noch viel mehr. 01:09:22.300 --> 01:09:26.980 Sie teilen die auf in kleinere Teams und geben Ihnen viel Freiheit, 01:09:27.580 --> 01:09:29.500 damit Sie Ihre eigenen Ideen verwirklichen können. 01:09:30.500 --> 01:09:33.980 Aber Sie synchronisieren regelmäßig, damit ein Gesamtsystem entsteht, 01:09:34.120 --> 01:09:35.360 das auch funktioniert. 01:09:35.780 --> 01:09:37.600 Und zwar heißt es regelmäßig jede Nacht. 01:09:38.080 --> 01:09:41.920 Jede Nacht wird das Gesamtsystem neu übersetzt, egal was es ist. 01:09:42.100 --> 01:09:46.680 Ob das jetzt Word ist oder Office oder Windows. 01:09:47.320 --> 01:09:47.700 Irgendwas. 01:09:49.780 --> 01:09:51.740 Wird jede Nacht übersetzt. 01:09:51.740 --> 01:09:53.380 Dazu haben Sie riesige Rechenparks. 01:09:55.100 --> 01:09:58.400 Dann gibt es eine Stabilisierungsphase, die ist auch regelmäßig, zwar 01:09:58.400 --> 01:10:02.120 nicht jede Nacht, aber in drei Monaten, da werden dann verbleibende 01:10:02.120 --> 01:10:04.600 Fehler heraus operiert. 01:10:05.640 --> 01:10:11.640 Die drei Phasen, die wir haben, sind eine Planungsphase, das ist 01:10:11.640 --> 01:10:16.440 tatsächlich so wie das inkrementelle Prototypmodell, da werden die 01:10:16.440 --> 01:10:22.620 Phasen, das ist die Planungsphase, aber die werden in drei 01:10:22.620 --> 01:10:27.320 Entwicklungsphasen geplant, in drei Subprojekten und danach erfolgt 01:10:27.320 --> 01:10:28.700 nochmal eine Stabilisierungsphase. 01:10:29.200 --> 01:10:31.880 Jeder dieser drei Entwicklungsphasen hat selbst wieder eine 01:10:31.880 --> 01:10:33.380 Stabilisierungsphase eingebaut. 01:10:34.480 --> 01:10:37.720 Also grafisch gesehen sieht es so aus, hier vorne ist die 01:10:37.720 --> 01:10:41.140 Planungsphase, dann kommt eine erste Entwicklungsphase, das schauen 01:10:41.140 --> 01:10:44.220 wir uns gleich an, dann eine zweite und eine dritte und dann 01:10:44.220 --> 01:10:45.760 schließlich die Stabilisierungsphase. 01:10:46.520 --> 01:10:48.660 So, dann schauen wir mal, was es hier alles gibt. 01:10:50.760 --> 01:10:51.820 Wo fangen wir an? 01:10:51.920 --> 01:10:54.500 Vielleicht mit den Dokumenten hier in der Planungsphase. 01:10:55.940 --> 01:10:59.340 Sie sehen, hier geht es noch weiter, da ist die Entwicklungsphase 01:10:59.340 --> 01:11:01.540 Nummer 3 und hier die Stabilisierungsphase hinten. 01:11:03.900 --> 01:11:05.140 Schauen wir uns das mal an. 01:11:05.980 --> 01:11:11.440 Also, am Anfang steht dieses sogenannte Vision Statement, könnte man 01:11:11.440 --> 01:11:12.800 als Wunschbild bezeichnen. 01:11:13.760 --> 01:11:15.200 Was wollen wir machen? 01:11:15.200 --> 01:11:21.220 Also 1995 war das Web noch jung, da könnte man sich also zum Beispiel 01:11:21.220 --> 01:11:25.840 einen Webbrowser vorstellen und den als Wunschbild machen und von 01:11:25.840 --> 01:11:30.060 einer Netscape abkupfern und sagen, so wollen wir es auch haben und 01:11:30.060 --> 01:11:30.500 noch besser. 01:11:31.300 --> 01:11:32.400 Das könnte das Wunschbild sein. 01:11:33.300 --> 01:11:35.660 Also identifiziere und priorisiere Produkteigenschaften aufgrund 01:11:35.660 --> 01:11:37.340 umfangreicher Sammlung von Kundenwünschen. 01:11:41.180 --> 01:11:44.300 Da gibt es nochmal mehr als 30% Änderungen während der 01:11:44.300 --> 01:11:45.000 Projektlaufzeit. 01:11:45.140 --> 01:11:49.360 Das wollen die auch, will Microsoft auch machen, dass sie trotz der 01:11:49.360 --> 01:11:53.640 Produktentwicklung ist, dass man noch rasch reagieren kann auf 01:11:53.640 --> 01:11:58.100 Neuerungen oder auch Erfindungen anderer Konkurrenten. 01:11:59.960 --> 01:12:02.660 Die Spezifikation kommt raus, Manager, Entwickler definieren die 01:12:02.660 --> 01:12:05.240 Funktion, Architektur und Komponentenabhängigkeit anhand des 01:12:05.240 --> 01:12:06.020 Wunschbildes. 01:12:06.420 --> 01:12:09.620 Dann gibt es Zeitplan und Teamstruktur, Aufteilung der Aufgaben von 01:12:09.620 --> 01:12:12.100 Produktfunktionsgruppen, mit denen eine Manager, drei bis acht 01:12:12.100 --> 01:12:14.640 Entwickler und genauso viel Tester. 01:12:14.800 --> 01:12:16.680 Das war auch etwas Unerhörtes. 01:12:17.360 --> 01:12:20.060 Wenn Sie ein Team haben mit acht Entwicklern, haben Sie darin auch 01:12:20.060 --> 01:12:20.660 acht Tester. 01:12:21.120 --> 01:12:22.980 Genauso viel Tester wie Entwickler. 01:12:23.280 --> 01:12:25.100 Die tun nichts anderes als testen. 01:12:26.140 --> 01:12:30.120 Hätte ich auch manchmal gerne, dass ich noch ein Tisch neben mir habe, 01:12:30.200 --> 01:12:32.280 der nichts anderes tut als testen, wenn ich da was schreibe. 01:12:33.780 --> 01:12:36.980 Kann ich mir nicht leisten, aber Microsoft kann das. 01:12:40.880 --> 01:12:45.920 So eine Phase dauert, diese erste Planungsphase, dauert ungefähr drei 01:12:45.920 --> 01:12:46.640 bis zwölf Monate. 01:12:46.880 --> 01:12:48.480 Das ist ziemlich lang, wenn Sie sich überlegen. 01:12:48.560 --> 01:12:51.100 Das ist also nicht so zwei Stunden oder was oder vielleicht ein 01:12:51.100 --> 01:12:56.760 Nachmittag oder ein Übungsblatt, sondern das ist drei Monate, bis zum 01:12:56.760 --> 01:12:58.640 ganzen Jahr, bis so ein Plan steht. 01:13:04.580 --> 01:13:07.360 Tester arbeiten natürlich den Entwicklern zu, die Manager 01:13:07.360 --> 01:13:08.320 koordinieren. 01:13:08.320 --> 01:13:12.800 Wir haben drei Meilensteine und es ist ungefähr aufgeteilt in erstes 01:13:12.800 --> 01:13:14.060 Drittel, zweites Drittel, drittes Drittel. 01:13:14.160 --> 01:13:15.480 Mehr Vorgabe gibt es da nicht. 01:13:16.640 --> 01:13:19.300 Im letzten Drittel sagt man eben, die unwichtigsten Funktionen werden 01:13:19.300 --> 01:13:22.400 das erste Drittel, die wichtigsten geplante Funktionalität hat. 01:13:22.740 --> 01:13:25.660 Aber wenn es dann schon etwas Neues gibt, kann ich bereits im zweiten 01:13:25.660 --> 01:13:28.680 oder dritten Drittel schon darauf reagieren und sagen, das können wir 01:13:28.680 --> 01:13:31.820 auch, diese Funktionalität, was weiß ich, Rechtschreibprüfung, das 01:13:31.820 --> 01:13:33.200 fügen wir auch gleich mit hinzu. 01:13:40.330 --> 01:13:44.130 Arbeiten mit Versionskontrollsystem, auch, wie gesagt, schon 1995. 01:13:45.490 --> 01:13:48.710 Das war noch relativ primitiv, aber hatten sie. 01:13:49.030 --> 01:13:51.750 Einbuchen in der Regel zweimal pro Woche, das heißt, sie können nicht 01:13:51.750 --> 01:13:55.510 hergehen und sagen, ich komme hier nicht weiter und tüftle vor mich 01:13:55.510 --> 01:13:58.790 hin und dann einen Monat später sage ich, ja, jetzt wäre ich soweit, 01:13:59.230 --> 01:13:59.810 das geht nicht. 01:14:00.930 --> 01:14:04.970 Sie müssen zweimal die Woche liefern an dem, was sie arbeiten. 01:14:06.450 --> 01:14:09.230 Nächtlich vollständig neu übersetzen aller Quellen, hatte ich schon 01:14:09.230 --> 01:14:09.510 erwähnt. 01:14:10.110 --> 01:14:12.010 Dann gibt es die automatischen Regressionstests. 01:14:12.190 --> 01:14:14.910 J-Unit gab es da noch nicht, aber die Regressionstests laufen 01:14:14.910 --> 01:14:16.810 automatisch ab, wie man das will. 01:14:18.650 --> 01:14:22.490 Und das Verursachen von Integrationsfehlern wird geahndet. 01:14:23.950 --> 01:14:27.350 Das heißt also, sie geben etwas ab und das bewirkt, dass das 01:14:27.350 --> 01:14:29.310 Gesamtsystem irgendwie nicht mehr funktioniert. 01:14:30.190 --> 01:14:31.590 Ihr Problem ist der Fehler. 01:14:33.190 --> 01:14:35.670 Und das muss sofort behoben werden, dass die anderen Entwickler 01:14:35.670 --> 01:14:36.210 aufhalten. 01:14:36.650 --> 01:14:39.350 Sie wissen, sie haben heute etwas abgeliefert, heute Nacht wurde 01:14:39.350 --> 01:14:42.750 übersetzt, es hat vielleicht gar nicht übersetzt, wegen Ihnen, oder 01:14:42.750 --> 01:14:45.990 aber es hat übersetzt und Sie haben geladen und das System läuft 01:14:45.990 --> 01:14:47.370 nicht, wegen Ihnen. 01:14:47.870 --> 01:14:48.750 Dann muss etwas passieren. 01:14:52.570 --> 01:14:55.370 Und zum Ende jeden Subprojekt, es werden alle entdeckten Fehler 01:14:55.370 --> 01:14:58.330 beseitigt, das ist die Subprojektstabilisierung. 01:15:05.440 --> 01:15:07.220 Dann kommt die Auslieferung. 01:15:09.340 --> 01:15:12.860 Also, am Schluss kommt natürlich noch die Stabilisierungsphase, da 01:15:12.860 --> 01:15:16.780 gibt es, das ist auch eine Erfindung von Microsoft, das sogenannte 01:15:16.780 --> 01:15:17.440 Beta -Tester. 01:15:17.900 --> 01:15:19.340 Alpha-Tester sind im Haus. 01:15:20.200 --> 01:15:26.860 Beta-Tester sind Sie und ich, wir dürfen, wenn wir brav sind, und dann 01:15:26.860 --> 01:15:31.300 dürfen wir schon die unfertige Software testen und für Microsoft frei 01:15:31.300 --> 01:15:35.360 Arbeit leisten, damit sie sagen, wir finden für sie Fehler, damit wir 01:15:35.360 --> 01:15:35.940 es fertig machen. 01:15:36.120 --> 01:15:38.240 Es ist toll, dass es Menschen gibt, die das machen wollen. 01:15:38.720 --> 01:15:41.780 Auch das wünsche ich mir manchmal, dass ich nicht nur einen Tichy-Klon 01:15:41.780 --> 01:15:44.580 habe, sondern auch noch eine Schaue von Leuten, die mich so bewundern, 01:15:44.820 --> 01:15:47.560 sagen, ja, Tichy, darf ich Ihre Software testen? 01:15:49.700 --> 01:15:51.960 Macht man nur mit Microsoft natürlich sowas. 01:15:53.120 --> 01:15:54.160 Das sind die Beta-Tester. 01:15:57.360 --> 01:16:01.180 So, und dann erfolgt eben Vorbereitung auf die Auslieferung. 01:16:01.380 --> 01:16:04.720 Das heißt, sagen Sie, jetzt wird das eingefroren, was wir haben, dann 01:16:04.720 --> 01:16:12.200 gibt es einen DVD oder CD, Kopie davon, die wird festgehalten und die 01:16:12.200 --> 01:16:15.640 Dokumentation und Anleitungen für den Druck aufbereitet und dann 01:16:15.640 --> 01:16:19.540 werden eben schließlich und endlich diese Kisten produziert mit der 01:16:19.540 --> 01:16:21.100 Anleitung, CDs, DVDs in. 01:16:21.700 --> 01:16:23.240 Hat sich heute auch wieder ein bisschen geändert. 01:16:23.460 --> 01:16:27.140 Heute liefert man natürlich alles übers Internet, soweit das geht. 01:16:28.500 --> 01:16:30.640 Aber man kann natürlich auch Boxen mit Software kaufen. 01:16:32.000 --> 01:16:33.460 Das dauert etwa drei bis acht Monate. 01:16:34.860 --> 01:16:37.380 Also, so etwa ist der Zeitplan. 01:16:38.160 --> 01:16:40.520 Drei bis zwölf Monate für die Planung, das hatten wir schon. 01:16:41.340 --> 01:16:44.880 Die Stabilisierungsphase am Schluss, drei bis acht Monate, auch etwa. 01:16:45.340 --> 01:16:52.520 Und dazwischen diese drei Teilprojekte, jeweils zwei bis vier Monate 01:16:52.520 --> 01:16:53.980 lang, also ein Vierteljahr etwa. 01:16:56.840 --> 01:17:00.720 Und da machen wir sechs bis zehn Wochen kodieren, optimieren, testen, 01:17:00.760 --> 01:17:02.140 Fehlersuche, stabilisieren. 01:17:02.480 --> 01:17:06.020 Dann gibt es einen Integrationstest, zwei bis fünf Wochen und dann 01:17:06.020 --> 01:17:08.160 fünf Wochen Pufferzeit zur Stabilisierung. 01:17:08.480 --> 01:17:11.980 Stabilisierung ist immer das Wort für Fehler finden. 01:17:15.500 --> 01:17:19.560 So läuft das und dann haben Sie also eine komplette Produktentwicklung 01:17:19.560 --> 01:17:20.720 in sechs bis zwölf Monaten. 01:17:22.880 --> 01:17:25.060 Wollen wir nochmal aufs Bild zurückgehen und schauen, ob wir was 01:17:25.060 --> 01:17:25.800 vergessen haben. 01:17:26.740 --> 01:17:27.700 Das war also hier. 01:17:31.380 --> 01:17:32.260 Jetzt sind wir da. 01:17:32.340 --> 01:17:33.260 Das hatte ich vorhin gezeigt. 01:17:33.400 --> 01:17:35.360 Also schauen wir uns nochmal die Planungsphase an, drei bis zwölf 01:17:35.360 --> 01:17:35.640 Monate. 01:17:38.280 --> 01:17:41.380 Da gibt es das Visionstatement, die Spezifikationen, die Prototypen, 01:17:41.640 --> 01:17:44.260 falls sie benötigt werden, auch das kann vorkommen. 01:17:45.840 --> 01:17:49.840 Design, Machbarkeitsstudien, Testingstrategie wird festgelegt und ein 01:17:50.200 --> 01:17:51.280 Plan wird festgelegt. 01:17:51.800 --> 01:17:53.580 Hier gibt es so einen Punkt, wo man sagt, jetzt ist der Plan 01:17:54.260 --> 01:17:54.580 vollständig. 01:17:56.480 --> 01:17:59.680 Da gibt es ein Review hier unten des Gesamtplans. 01:18:00.380 --> 01:18:01.840 Also, Sie wissen schon, was Sie wollen. 01:18:02.280 --> 01:18:06.080 Dann gibt es diese drei Unterprojekte und die sind jetzt aufgeteilt in 01:18:06.080 --> 01:18:11.320 Code und Optimierung testen und Integration und Wiedertesten und 01:18:11.320 --> 01:18:13.040 nochmal Pufferzeit für Stabilisierung. 01:18:14.860 --> 01:18:16.620 Und das wiederholt sich jetzt dreimal. 01:18:17.500 --> 01:18:18.680 Dann sind wir hier unten. 01:18:19.620 --> 01:18:24.720 Moment, Milestone 1, das ist das erste, zweite Drittel, drittes 01:18:24.720 --> 01:18:26.600 Drittel, dann kommt ja die 01:18:30.520 --> 01:18:32.040 nochmal so eine... 01:18:32.040 --> 01:18:33.300 Moment, habe ich das verkehrt gemacht? 01:18:33.620 --> 01:18:36.280 Entschuldigung, das ist nochmal ein Duplikat. 01:18:36.680 --> 01:18:40.960 Also hier sind wir fertig mit den drei Subprojekten und dann kommt die 01:18:40.960 --> 01:18:45.160 Vorbereitung auf die Freigabe und die Stabilisierung davor. 01:18:47.180 --> 01:18:49.840 Code Complete ist also dieses Schlagwort. 01:18:50.020 --> 01:18:52.000 Code Complete, wir haben erreicht Code Complete. 01:18:52.160 --> 01:18:58.820 Das heißt, alle Code ist entwickelt und das Ergebnis ist eingefroren. 01:18:59.600 --> 01:19:02.080 Dann gibt es noch eine Stabilisierungsphase, nochmal eine 01:19:02.080 --> 01:19:05.240 Stabilisierungsphase und dann die sogenannte Zero-Bug-Release. 01:19:06.180 --> 01:19:10.500 Das heißt, alle heißt nicht null Fehler, sondern null bekannte Fehler. 01:19:11.100 --> 01:19:13.200 Null bekannte Fehler, ein großer Unterschied. 01:19:16.780 --> 01:19:18.140 Gibt es dazu Fragen? 01:19:24.140 --> 01:19:30.400 Ja, also Sie sehen schon, es wird immer mehr iterativ gemacht, es wird 01:19:30.400 --> 01:19:34.460 nicht mehr alles geplant, sondern es wird durchaus hier in diesen 01:19:35.340 --> 01:19:38.400 Unterprojekten der Plan geändert, erweitert, was hinzugefügt. 01:19:38.740 --> 01:19:41.660 Und das will ja Microsoft erreichen, nämlich schneller reagieren zu 01:19:41.660 --> 01:19:43.700 können auf Markterfordernisse. 01:19:44.140 --> 01:19:44.960 Ja, da gibt es eine Frage? 01:19:54.880 --> 01:20:00.360 Ja, ich kann Ihnen schon, da müssten Sie aber dieses Buch von Kusumano 01:20:00.360 --> 01:20:01.120 und Selbe lesen. 01:20:01.920 --> 01:20:06.600 Ich weiß jetzt nicht, ob das aussagekräftige Informationen liefert, zu 01:20:06.600 --> 01:20:09.900 dem Zeitpunkt, aber es liefert sehr viel Daten. 01:20:10.640 --> 01:20:16.020 Also, es ist ein wirklich dickes Buch und ich handel das ab in fünf 01:20:16.020 --> 01:20:16.900 Folien oder so. 01:20:19.220 --> 01:20:20.860 Aber da können Sie gerne nachschauen. 01:20:21.420 --> 01:20:24.180 Ich würde aber nicht behaupten wollen, dass Microsoft das immer so 01:20:24.180 --> 01:20:27.640 macht oder ich weiß gar nicht, wie Microsoft 20 Jahre später das 01:20:27.640 --> 01:20:27.920 macht. 01:20:28.020 --> 01:20:33.160 Machen die das noch oder nehmen sie inzwischen auch Scrum oder Extreme 01:20:33.160 --> 01:20:34.660 Programming, was wir noch behandeln werden. 01:20:37.400 --> 01:20:41.600 Aber für uns ist es, glaube ich, ein wichtiges Modell, das sagt, aha, 01:20:41.720 --> 01:20:43.240 so kann man das auch organisieren. 01:20:46.900 --> 01:20:50.940 Weil wir eben eine klare Struktur bekommen damit und damit auch klarer 01:20:50.940 --> 01:20:54.900 wird, wer wann was zu tun hat und auch ein zeitliches Gerüst. 01:20:56.140 --> 01:20:58.800 Und wenn Sie mit Microsoft konkurrieren wollen, dann ist es gut zu 01:20:58.800 --> 01:20:59.720 wissen, wie die das machen. 01:21:02.900 --> 01:21:05.100 Man sollte immer wissen, was die Konkurrenz macht. 01:21:07.620 --> 01:21:09.360 Aber vielleicht wollen Sie ja dafür arbeiten. 01:21:10.020 --> 01:21:10.740 So, haben wir das? 01:21:11.420 --> 01:21:12.420 Also, Pro. 01:21:14.060 --> 01:21:19.060 Effektiv durch kurze Produktzyklen, halbes bis ganzes Jahr, kann ich 01:21:22.100 --> 01:21:26.200 in relativ kurzen Abständen ein neues Produkt herausbringen. 01:21:27.440 --> 01:21:27.980 ein neues Produkt herausbringen. 01:21:27.980 --> 01:21:30.480 Sie haben eine Projizierung der Funktionen, Sie erinnern sich, die 01:21:30.480 --> 01:21:33.180 wichtigsten Funktionen, die zentralen Funktionen, kommen in die erste 01:21:33.180 --> 01:21:33.920 Iteration. 01:21:36.720 --> 01:21:40.480 Sie haben damit auch eine natürliche Modulisierung nach Funktionen des 01:21:40.480 --> 01:21:41.740 Gesamtsystems. 01:21:42.520 --> 01:21:45.880 Ich habe einen Fortschritt, ohne dass ich eine komplette Spezifikation 01:21:45.880 --> 01:21:46.240 brauche. 01:21:46.980 --> 01:21:49.960 Ich kann mit dem arbeiten, was ich weiß, in der ersten Phase. 01:21:50.080 --> 01:21:52.380 In der zweiten Phase kann ich hinzufügen, was ich noch brauche. 01:21:55.760 --> 01:21:59.140 Der Hauptvorteil, der im Buch von Kusumano und immer wieder 01:21:59.140 --> 01:22:03.540 herausgestrichen wird, ist eben, dass viele Leute arbeiten, als wären 01:22:03.540 --> 01:22:04.720 sie in einem kleinen Team. 01:22:05.880 --> 01:22:09.600 Wir wissen aber, ein paar Fragen sind da noch offen, nämlich, wie sich 01:22:09.600 --> 01:22:11.540 die kleinen Teams untereinander abstimmen. 01:22:11.780 --> 01:22:12.820 Das ist nicht ganz klar. 01:22:14.320 --> 01:22:18.380 Und Rückmeldungen, Konkurrenzideen, konkurrierende Ideen können sehr 01:22:18.380 --> 01:22:19.000 schnell einfließen. 01:22:22.170 --> 01:22:26.610 Allerdings, wie ich es gerade erwähnt hatte, ist noch offen, wie sich 01:22:26.610 --> 01:22:29.570 die vielen Teams untereinander abstimmen. 01:22:30.310 --> 01:22:32.410 Und da gibt es in der Tat Architekturprobleme. 01:22:32.970 --> 01:22:35.570 Haben Sie einen Entwurf irgendwo gesehen? 01:22:36.610 --> 01:22:37.770 Ich habe ihn nicht gesehen. 01:22:40.430 --> 01:22:44.650 Entsprechend ist das System oftmals sehr unsauber strukturiert. 01:22:46.490 --> 01:22:48.430 Man hat mangelhafte Fehlertoleranz. 01:22:50.130 --> 01:22:52.730 Es gibt kein Lernen über Teamgrenzen hinweg. 01:22:52.890 --> 01:22:55.230 Es wird ja nichts dokumentiert, außer das, was ich für die Software 01:22:55.230 --> 01:22:55.910 selbst brauche. 01:22:56.890 --> 01:23:03.950 Und, was ein bisschen in die Richtung Ihrer Frage geht, ist, Guzman 01:23:03.950 --> 01:23:07.130 und Selvi beobachten das also, in so einem Projekt innerhalb von 18 01:23:07.130 --> 01:23:10.170 Monaten 50% des Codes weggeworfen wurden und ersetzt wurden. 01:23:12.890 --> 01:23:15.290 Ja, wie soll ich das jetzt interpretieren? 01:23:15.390 --> 01:23:19.510 Das heißt wohl, dass sie zum einen schnell programmieren, aber wohl 01:23:19.510 --> 01:23:22.010 auch viel für die Tonne ist. 01:23:23.710 --> 01:23:26.750 Dass viel weggeworfen werden muss. 01:23:29.930 --> 01:23:33.470 Das ist eine Vergleichsfolie, die ist eigentlich mehr zum Lernen 01:23:33.470 --> 01:23:35.150 gedacht, das bespreche ich jetzt nicht durch. 01:23:36.270 --> 01:23:39.730 Phasenmodell und Synchronize und Stabilize verglichen. 01:23:40.350 --> 01:23:40.870 Ja. 01:23:43.590 --> 01:23:45.910 So, jetzt bin ich doch ziemlich weit gekommen. 01:23:46.470 --> 01:23:47.810 Dann machen wir lieber nächstes Mal weiter. 01:23:48.110 --> 01:23:48.530 Vielen Dank.