Ja, jetzt kommen wir zum letzten Teil der Vorlesung am 29.4.,
Vorlesung zwei Softwareentwicklung zwei. Wir haben bis jetzt drüber gesprochen,
wie wir Fehlerwirkung verhindern, verrieren können durch defensiven Programmierstil,
was Fehler sind da in diesem Zusammenhang und wie wir Fehler vermeiden können,
zu dem wir das Vertragsmodell einsetzen.
Da wir Fehler nicht ganz vermeiden können,
geht es jetzt im letzten Teil der Vorlesung um das Fehlerfinden
und dabei um Reviews und Tests
Fragen dazu sind diese,
Frage 6, stellen Sie das gegenüber, Frage 7,
wie kann das Vertragsmodell bei Tests helfen und 8 für Test, First-Ansatz.
Wir fangen damit mal an zu erinnern, uns zu erinnern,
was wir bei SE1 hatten. In SE1 ging es um zum einen,
um die statische Analyse, wie Experten, Quelltext analysieren,
Review und Werkzeuge, Quelltextanalysierung, Metriken, Strukturanalyse.
Mit diesem Review werden wir beginnen und dann werden wir
zur dynamischen Analyse kommen,
wie Software ausgeführt wird
Statische Analyse. Dabei geht es darum, statisch,
es passiert nichts, könnte man sagen, alles ist still,
ja, der Quellcode wird nicht ausgeführt.
Und zwar, was hier gemanalysiert wird, ist in dem Entwickler und zusammensitzen.
Also im Wesentlichen ist der Autor, plus jemand weiteres,
wir könnten sagen, ein Experte oder ein anderer Entwickler.
Und dabei werden Fragen gestellt, es werden Erläuterungen gemacht.
Und das führt zu einem Erkenntnisgewinn. Diese Erkenntnisbewinn besteht darin,
wir kennen dieses Vier-Augen-Prinzip, was hier der nächste Punkt sagt.
Die beiden Personen oder vielleicht noch mehr beteiligte Personen stecken ihre kognitiven Fähigkeiten zusammen.
Und es entstehen durch die Fragestellungen, die ein neuer Beteiligter stellt.
Nicht nur der Autor selber, entstehen neue Erkenntnisse beim Autoren. Also im Wesentlichen,
ich habe das persönlich so erlebt, den Projekten,
in denen ich gearbeitet habe,
dass am Ende die meisten Hinweise auf Mängel vom Autor selbst gekommen sind,
weil ja das erläutert hat, jemand anders und da fiel ihm ein,
oh,
das und das könnte man so und so verbessern.
Das ist tatsächlich ihm mehr eingefallen aus dem anderen.
Ja, und er ist auch damit möglich,
Mängel der Verständlichkeit zu prüfen, Mängel bezüglich Wartungsaufwand zu hoch,
Mutterverletzung für Entwurfsprinzip
Außerdem haben diese Art und Weise der Vorstellung gegenüber das Auto
durch den Autohof gegenüber jemand anders auch noch einen Anerkennungsaspekt,
nämlich so ein, dass mal jemand den Quellcode liest,
außer nur der Compiler, der hat das eh akzeptiert.
Und dass es vielleicht auch Verbesserungshinweise gibt, wenn dieser Experte jemand ist mit mehr Erfahrung,
mit Erfahrung aus einem anderen Gebiet. Und natürlich,
was man nach weiterem positiven Punkt sehen, sie merken,
das sind alles positive Punkte hier, die für Reviews sprechen,
dass man motiviert wird, eine Dokumentation zu machen.
Diese Motivation kommt ja auch daher, dass ich weiß am Ende,
es findet ein Dokument, ein Review, eine Inspektion statt.
Ich werde dazu motiviert, ein Programm mit dem Programmierstil meines Projektes gut einzuhalten.
Es ist möglich, durch diese gemeinsame Arbeit zwischen Autor und
Experte oder Autor einen weiteren, auch Wissenstransfer zu machen.
Es gibt dieses Schlagwort Kollektiv Code Ownership, was meint,
nicht nur einer ist Experte für Einstümper im bestimmten Bereich einer Software,
sondern andere auch.
Und das wäre hier auch eine gute Möglichkeit,
die da rauskommt
Und als weiter wesentlicher Punkt, der dafür spricht,
das Ganze ist sehr viel effektiver als Teste.
Effektiver im Sinne von, es kommt mehr Effekt heraus,
in zwei Stunden finde ich richtig viele Menge, zwei Stunden Inspektion,
aber in zwei Stunden testen, nicht so besonders viel.
Also da können Sie manchmal eine Woche testen, um 20 Fehler zu finden.
Das Ganze hat auch noch Nachteile, das müssen wir einfach sagen.
Und leider ist es der Fall, dass in vielen Projekten
diese Inspektionen, Reviews viel zu wenig eingesetzt werden.
Sie merken schon,
ich nehme den Begriff Inspektionen im Review hier fast als Synonym,
ja trennen das hier nicht
so ganz genau
Es gibt bestimmte Unterschiede, das ignorieren wir.
Wir nehmen die als gemeinsam. Warum werden denn diese Inspektionen
und Reviews praktisch nicht so häufig durchgeführt? Ja,
weil sie doch sehr stark personenabhängig sind, klimaabhängig sind.
Es ist schwierig, mit jemandem zusammen über Sachen zu diskutieren,
die nicht so gut sind. Das passt nicht so richtig
zu unserer Kultur. Wir wollen dann über Erfolge reden.
Aber mir geht es darum, zur Verbesserung beizutragen.
Und diese Verbesserung wäre ganz gut oder das ist nicht so einfach,
Personen, die Personen dazu zu bringen,
dass sie ohne sich gegenseitig anzugreifen und ohne in eine Verteidigungshaltung
zu kommen,
das zu machen
Projektteams, die das einmal eingeführt haben, wollen das nicht
wieder vermissen, aber das Einführen ist tatsächlich nicht so leicht.
Ich habe das als Projektleiter gemacht. Es gelingt, Leute zu motivieren,
über den Vorteil von den Vorteilen zu überzeugen und man lässt einfach die,
die das nicht mögen und ständig die keine Kritik vertragen,
weil oder sie ständig angegriffen fühlen,
die lässt man es einfach außen vor.
Und mit der Zeit werden die dann trotzdem beteiligt,
einfach weil sie sich nicht mehr fühlen, sich nicht mehr ausschließen zu können.
Lassen Sie uns durchgehen, wie denn diese Reviews-Inspektionen funktionieren.
Hier, das Bild zeigt den Ablauf der Kernes, die eigentliche Reviews-Sitzung.
Dabei geht es darum, dass man Menge sammelt.
Das Ergebnis ist also eine Menge Liste. Es geht darum,
weil man wegen der Konzentrationsfähigkeit sollte die Dauer nicht größer als zwei Stunden sein.
Und er muss darauf achten, ein konstruktives Klima zu haben,
eben genau diesen Effekt zu erreichen,
dass am Ende der Autos selber die meisten Menge entdeckt, weil er das erklärt.
Wenn wir dann Verteidigungshaltung haben oder jemand sich angegriffen fühlt,
dann würde er das alles so darstellen,
it's know the bug it's a fischer, sie kennen diesen Spruch,
dass man also versucht, das immer so zu erklären,
dass das unabdenkbar, man muss es genauso machen,
um ja keinen Fehler zuzugeben,
dann geht dieses Review schief
So, und wie diese Zeiteinhaltung ist die allgemeine Regel,
dass man nur Fehler entdeckt. Wenn man einen Fehler kennt,
Fehler oder einen Mangel gefunden hat,
dann schreibt ihn auf und geht zum Nächsten.
Man diskutiert nicht, wo kommt er her, warum ist das,
was wäre eine bessere Lösung, gerade diese Lösungsdiskussion würde endlos führen.
Das Beheben der Menge passiert in der Nachbereitung,
nach der eigentlichen Sitzung durch den Autor alleine.
Und möglicherweise gibt es anschließend noch eine Prüfung,
ob das denn öffentlich gemacht worden ist.
Bevor man die Sitzung durchführen kann, sollte man das Ganze irgendeiner vorbereiten.
Also zum einen gibt es natürlich eine Terminfestsetzung.
Manchmal gibt es aber auch eine Vorbereitung im Sinne von der Nichtautor schaut sich das Ganze nochmal an darauf hin,
versucht schon mal formale Fehler zu sammeln,
anhand einer Checkliste oder man macht eine Vorbesprechung,
wo man nochmal einordnen, worum geht es,
was sind die Schwerpunkte oder sowas.
Aber der Kern ist diese Reviewsetzung. So viel nur dazu,
wir haben nicht viel Zeit, da ganz im Detail einzugehen,
aber ich möchte Ihnen in der nächsten Tabelle das mal darstellen,
wie die sich verhält zu dem Test, zu dem wir gleich anschließend kommen.
Also hier ist gegenübergestellt, die statische Analyse,
über die wir gerade gesprochen haben, am Beispiel eines Reviews,
Inspektionen als Synonym dazu und die dynamische Analyse,
wo wirklich eine Software ausgeführt wird, Zum Beispiel Andystes.
Wir hatten eben schon gesagt, der Prüfgegenstand, also die Software,
der Quellcode, liegt vor und wird begutachtet von den beiden Personen oder vielleicht noch mehr Personen.
Während bei der dynamischen Analyse wird die Software ausgeführt.
Das Verhalten wird beobachtet. Während man das Begutachten für alle Arten von Gegenständen machen kann,
also auch Sachen,
die noch nicht lauffähig sind und die bis jetzt nur auf dem Papier existieren,
zum Beispiel ein Entwurf, eine Antwortungsbeschreibung,
ja selbst ein Benutzerheimbuch kann man begutachten.
Geht dieses Ausführen nur für Sachen,
die halt ausführbar sind, nämlich Quellcode auf einen bestimmten,
auf einen bestimmten Stand der Fertigstellung
Deswegen kann man sowas auch in frühen Phasen machen.
Also auch wenn es nur Anforderungen gibt. Und wenn es nur Skizzen gibt,
kann man diese Skizzen schon mit jemandem diskutieren und keinen Mängel finden.
Was kann man da finden? Ihr dadurch,
dass man wirklich gegen Quellcode anschaut,
kann man auch solche Sachen wie Verständnisprobleme, Fehler,
die gegenüber in Verletzungen der Entwurfsregeln oder auch Mängel bezüglich Änderbarkeit,
Wartbarkeit, die kann man auch finden.
Da war noch dazu das, was ich zum Abschluss
sagte bei der letzten Folie.
Ich finde pro Zeiteinheit
sehr viele
Mängel und Fehler im Sinne von Quellcode-Defiziten.
Beim Test ist es so, dass ich, wie gesagt,
den erst machen kann, wenn er implementiert ist.
Und ich kann nur das Verhalten beobachten. Ich finde also
nur Fehler bezüglich des Verhaltens. Ich merke nicht,
ob da jemand mit Tricks gearbeitet hat,
ob der gut dokumentiert ist, der gut.
Sowas merke ich nicht. Und ich brauche relativ viel Zeit,
um eine bestimmte Menge zu Fehler zu finden.
Testen ist einfach sehr auffällig. Soweit das entspricht auch der Folie
der Frage. Sex hier, stellen Sie das gegenüber.
Damit haben wir erstmal diesen Punkt erreicht