So, den nächsten Blog ändern wir auch gleich die Überschrift ein bisschen.
Und zwar nicht nur die Nummer, 3, 4,
sondern wir nennen, ändern auch den Titel analytische, statische Maßnahmen.
Denn wir werden danach zu den dynamischen Maßnahmen auch noch kommen.
Wir hatten ja im vorhergehenden gesehen, bei den statischen,
bei den analytischen Maßnahmen gibt es hier die statischen,
wo Reviews Inspektionen dazu sind, das ist der Punkt,
den wir jetzt behandeln.
Das ist 3.4 und danach werden wir
zu den dynamischen kommen
Ja, analytische statische Maßnahmen. Generell analytische Maßnahmen,
da geht es uns darum, Qualität zu prüfen.
Es geht uns, wir haben ja schon gesagt, konstruktive Maßnahmen,
vermeiden Fehler, finden Probleme, vermeiden die Probleme überhaupt erstmal.
Das ist natürlich das Bessere. Aber wenn wir die Probleme finden,
hilft es uns auch. Bei diesem Prüfen gibt es verschiedene
Ziele und das hängt sehr von der Perspektive ab. Der Kunde,
der Auftraggeber, der möchte vor allen Dingen ein System,
was das erfüllt, was er möchte,
also erfüllt das Produkt die Anforderung des Endprodukt
Der Projektleiter ist darin interessiert, dass das ganze Projekt erfolgreich läuft.
Und deswegen will er auch schon frühzeitig steuern können.
Er möchte also auch schon bei Zwischenprodukten schon wissen,
bei vorgehenden Phasen, wie gut sind die denn,
wie gut erfüllen sie denn die Ziele?
Und der Entwickler möchte natürlich auch gerne wissen,
ob er das gut gemacht hat,
ob er vielleicht etwas anders machen soll.
Ja, also das möchte jeder hat so ein bisschen seine
eigene Ziele dafür. Für solche Prüfungen gibt es zwei Begriffe,
diese beiden Begriffe haben wir hier auf der Folie Verifikation
und Validation
Da wir in dieser Veranstaltung nicht so sehr vertieft drauf eingehen,
möchte ich den Unterschied auch gar nicht so klar machen.
Wir halten es ein bisschen mit den Amerikanern, die machen einfach we and we.
Ja, sie machen sich nicht die Mühe, dass beides auseinanderzuhalten.
So, so dürfen sie das durchaus für diese Veranstaltung
auch halten. Auf dieser vor dir steht nun mal,
worin da wirklich der Unterschied besteht. Denn das eine,
weil das erste geht, bei dem ersten geht es darum,
sind denn passen denn die Sachen zueinander zwischen den verschiedenen Phasen.
Das heißt, erfüllt der Entwurf das, was die Anforderungen machen,
macht die Implementierung das, was der Entwurf sagt.
Also diese erfüllen wir das Vorgehende,
während das bei der Validation prüfen wird, die Ergebnisse insgesamt.
Ob sie das tun, was sie sollen. Aber wir erinnern uns insgesamt,
egal ob wir das Validation, Verifikation nennen und so weiter,
insgesamt geht es uns um dieses frühzeitig.
Ja, wir erinnern uns, was hatten wir mit dieser Fehlerfortpflanzung?
Das war ja der große Punkt,
den wir hier vor kurzem besprochen haben,
wenn wir auf Fehlern aufbauen, dann vergeht viel Aufwand.
Das heißt, wir wollen
das Ganze frühzeitig machen
Ja, also deswegen, wir wollen frühzeitig die Krisiken erkennen
und wir wollen diesen Aufwand für die Nacharbeit senken.
Das ist das, was uns wirklich hilft und was wir gut machen können.
Und deswegen machen wir zum Beispiel diese Test-First-Strategie.
Aber jetzt sprechen wir erst mal darüber, über analytische Maßnahmen.
Ich möchte kurz zeigen, wie wir das einbinden in den Entwicklungsprozess.
Ich habe hier mal ein Bildchen genommen, das soll ein Aktivitätstiagramm sein. Das heißt,
sie sehen hier, gibt es solche Swimlanes,
das sind diese Linien, es gibt ja eine Folge,
Das ist der Steuerfluss,
der geht hier lang und das sollen die Aktivitäten sein,
die hier in diesem Aktivitätsdiagramm drin sind und dass der Kern ist jetzt eigentlich dieses Produkt entwickeln.
Ja, ich mache das mal, mache das mal hier ein bisschen rot.
Ja, das ist das, wo wir eigentlich drüber reden.
Zum Beispiel, wir reden darüber, einen Entwurf zu bauen.
Ja, dann würde das Vorgängerprodukt, wäre dann eben
die Anforderungsbeschreibung und die Anforderungsbeschreibung, die kommt aus den Konfigurationsmanagement
Die wird da freigegeben vom Konfigurationsmensch. Wir haben eine Anforderungsbeschreibung,
die irgendwie verabschiedet, eingefroren ist. Und die verwende ich,
um das Produkt zu bauen. Aber bevor ich das tue,
und das ist jetzt der Punkt,
der für uns besonders interessant ist, bevor ich das tue,
mache ich hier, bereite ich die Abnahme vor.
Ich sage dem Entwickler, dem Entwerfer,
dein Entwurf muss die und die Ziele erfüllen.
Er muss die und die formalen Kriterien aussehen.
So muss er dokumentiert sein. Das sage ich ihm vorher
. Das Gleiche kennen wir bei Entwicklung. Dann ist natürlich
das Vorgängerprodukt hier zum Beispiel der Entwurf und das,
was wir hier gerade machen, ist dann den Code entwickeln.
Und dann wollen wir den Test vorher haben
Und indem wir die Schnittstellenbeschreibung nehmen und die Vor- und Nachbedingungen,
die im Entwurf beschrieben sind, können wir daraus den Test bauen,
das Test First, diese Test-First-Strategie.
Sie werden Sie vielleicht fragen, warum wir in der Universität immer so drauf rumreiten.
Ja, bei SEN so ein SE2 haben Sie das schon gehört,
Test-First, ja, wie machen wir das mit diesen Unitests?
Das Problem ist, es wird in der Industrie nicht überall gemacht.
Es ist eigentlich völlig einleuchtend, ich muss den Test sowieso machen,
ja, aber die Leute machen es häufig nicht so,
dass sie den Test vorher entwickeln.
Und das ist das, was eben die Diagramme zeigt,
nebenbei bemerkt, Dieses V-Modell ist 1992 schon veröffentlicht worden.
Das ist also nichts von heute. 18 Jahre und es hat noch nicht,
es gibt immer noch viele Projekte, die das nicht tun,
weil die Entwickler irgendwie sagen, oh,
wir testen es nicht so schön und testen es nicht so nett und ich will doch lieber entwickeln.
Sie müssen doch sowieso den Test schreiben. Also sollten sie
es vorher machen. Sollten sie vorher klären,
was die Software denn tatsächlich tun muss,
bevor sie die Software entwickeln und dann machen wir den Test der Vollständigkeit halber mal,
weil das auch nur mit blau hier,
vielleicht nehmen sie es überhaupt unterscheiden können, blau und schwarz,
ja.
Und dann geht das, ja, und das ist dieses Testfirst,
das gilt eben auch für Abnahmen.
Und das ist dieser Punkt frühzeitig,
Das machen wir möglichst inkrementell, das wissen Sie schon alle,
weil uns das hilft, in kleinen Schritten noch zu klären,
was denn noch unklar ist, den Auftraggeber noch zu fragen,
was machen wir denn machen zum Beispiel,
wenn das Verhalten noch nicht so ganz klar ist,
ja, wir machen, das ist ja dieses Test First,
sieht eben so aus, dass wir die Testfälle,
aber eben auch, wenn wir nichts testen wie beim Entwurf,
wenn wir eine Abnahme durchführen,
diese Kriterien für die Abnahme vorher bereitstellen.
Zusätzlich ist es wichtig, auch Qualitätsziele wie eben Wartbarkeit,
der Weiterbarkeit und so weiter,
wir haben die am Anfang dieses Kapitels besprochen,
wenn wir diese Qualitätsziele mit in die Anforderungen aufnehmen
Ja, und dass wir auch die Dokumentation mit aktualisieren, ändern, überarbeiten, wenn wir denn was ergänzen und überarbeiten. Und dass wir dafür sorgen,
in extierenden, vorhandenen Projekten, dass wir nach und nach und besser werden,
dass wir also die Dokumentation verbessern, verbessern heißt nicht unbedingt mehr,
sondern heißt aktueller, schlanker, angepasster für die Ziele,
dass wir die Qualität, die Struktur des Entwurfs,
wie heißt das Wort, Architekturqualität,
aber Sie können auch gerne Entwurfsprinzipien, Einhaltung nehmen,
dass wir das schrittweise verbessern oder die Qualität von Modellen,
die den Überblick darstellen.
Alles das wollen wir relativ, wollen wir tun,
um Qualität zu verbessern
Ja, weiter geht es damit, dass ich jetzt mal,
bevor ich zu den einzelnen Maßnahmen komme,
die mal gegenüberstellt, die statischen und die dynamischen Maßnahmen.
Dieser Gegenüberstellung bezieht sich jetzt oder wird unter anderem in einer Frage besprochen,
angefragt, zu dieser Frage möchte ich mal kurz springen.
Ja, das ist die Frage 4 und die Frage
5. Hier geht es darum, warum macht,
soll man das zusätzlich machen und worin unterscheiden sie sich?
Vor allen Dingen geht es bei dieser Stelle die Tabelle,
die wir hier gerade anschauen, genau das, was hier Frage 5 ist.
Ich bin mir zurück zu der Tabelle. In dieser Tabelle
habe ich mal gegenübergestellt, wie sich diese beiden Sachen unterscheiden.
Die statischen Maßnahmen, aneydytische statische Maßnahmen und analytische, dynamische Maßnahmen.
Ich habe jeweils ein Beispiel genommen. Sie hatten schon,
vielleicht erinnern Sie sich kurz an diese Baumstruktur, die wir hier im Überblick hatten.
Also wir unterscheiden jetzt zwischen diesen statischen und dynamischen.
Und hier nehmen wir als Beispiel Reviews und Inspektionen.
Bitte sehen Sie mir Nachricht, wir machen das hier ein bisschen einfacher.
Wir unterscheiden zwischen den beiden nicht. Es gibt Autoren,
die da dem halt noch einen Unterschied zwischen beiden machen.
Für uns geht das mal in die gleiche Richtung und bei den dynamischen geht es um Tests.
Wir sagen dann gleich noch ein bisschen genauer darum,
warum das, warum die, wie der Test läuft,
aber jetzt erstmal nur so einen Überblick, die statisch,
heißen die statischen Maßnahmen deswegen, weil das Prüfobjekt,
also das Stück Software oder so,
weil das nur vorliegt und begutachtet wird.
Deswegen heißen die Dinger statisch. Da tut niemand etwas,
man schaut nur drauf,
Dynamisch, da passiert etwas, es wird ausgeführt.
Das Prüfobjekt wird ausgeführt, das ist das, was beim Test passiert.
Beim Test wird ein Stück gut laufen gelassen und wir schauen, was passiert.
Also das Verhalten wird beobachtet, wenn man das ein bisschen schöner formuliert.
Ja, das kriegen wir hin. So,
das ist ihnen soweit vermutlich klar und vielleicht würden sie bei diesem Punkt,
wo sie weiterschauen, würden sie sagen, ja super,
ausführen ist immer besser als nur drauf gucken.
Ja, aber dieses Ausführen geht natürlich nur für Sachen,
die wir auch ausführen kann.
Das heißt, sie gehen nur für Quellcode und auch nur,
wenn das mindestens teilweise fertig ist. Das bedeutet,
es gibt viele Sachen, die wir nicht testen können.
Zum Beispiel eine Anforderungsbeschreibung. Zu großen Teilen, Text können sie nicht testen.
Ein Entwurf, Kästchen und Linien können sie nicht testen.
Testdaten können sie nicht auf Vollständigkeit prüfen mit einem Test.
Also viele Sachen kann man tatsächlich,
sind diesen Sachen nicht zugänglich
Während begutachten können sie alles. Das ist ja für Menschen gemacht,
das heißt, wir können eine Antwortungsbeschreibung prüfen, ob sie denn vollständig ist, widerspruchsfrei.
Sie erinnern sich an das erste Kapitel,
da haben wir darüber gesprochen, was sind die Abnahmekriterien,
da kann ich das erreichen, dass ich frühzeitig teste.
Ja, also hier unsere Fehlervorweilzeit, ja,
wo wir nochmal darauf hingehen, ja, wir hatten hier gesagt,
wenn ich bei der Anforderungsanalyse die Sachen gleich finde,
sind sie mit viel geringerem Aufwand zu beheben.
Und dafür brauchen wir diese Reviews-Inspektionen und dabei sind wir bei der Frage 4,
ich springe mal vor zu Utschuld zu den Fragen hier,
warum sind die zusätzlich sinnvoll?
Oder hier, wieso hat das denn der Einsatzzeitpunkt Einfluss auf die Produktivität?
Ja, wir können das eher machen. Und weil wir
es eher machen können, haben wir eine bessere Produktivität und haben wir weniger Rework.
Und das ist der Punkt, der uns hier hilft.
Also zurück zu unserer Tabelle. Wir können viel zeitiger,
indem wir alle Sachen, die irgendwie vorliegen,
auch wenn sie nicht ausführbar sind, indem wir sie begutachten können,
können wir sehr viel zeitiger da etwas tun und können sehr viel zeitiger Fehler finden,
Probleme finden, bevor sehr weitere Arbeit mit diesen Fehlern arbeitet,
das dann alles wieder neu gemacht werden muss,
Rework.
Wir verringern die Weber. Daraus merken Sie schon,
diese statischen Maßnahmen sind etwas total Wichtiges.
Das Problem ist, man macht sie zu wenig.
Testen machen schon, ich sag mal, 95 Prozent der Leute.
Ja, es gibt tatsächlich Leute, die mich testen.
Ich habe mit so einem Projekt schon zu tun gehabt oder
gelegentlich Leute beraten,
die tatsächlich nicht testen
Weil der Kunde das bezahlt,
weil der nicht bezahlt den Test und weil der Kunde mit den Problemen,
die da gelegentlich auftreten, zufrieden sind,
weil die ganzen Sachen nicht so komplex sind.
Man testet nicht. Ja, aber gut, das ist
ein anderer Punkt. 95 Prozent der Projekte testen, aber
viel weniger. Ich kann jetzt kaum eine Zahl sagen,
weil das ja von den Bereichen eine Abhängigung,
von der Projektkultur viel weniger machen, Inspektionen.
Inspektionen und Reviews sind jetzt hier für uns zwei Synonyme.
Wir kommen gleich noch ein bisschen genauer zum Ablauf und was
das eigentlich ist. Und dabei werden wir auch merken,
das sage ich Ihnen jetzt erst mal nur,
wir können nicht nur Fehlverhalten testen, wie merken,
Der Test merkt halt, wenn das Verhalten nicht dem entspricht.
Sondern wir merken auch, weil wir ja drauf schauen,
merken wir auch, ist etwas schwer verständlich,
ist etwas tricky, ist dort irgendwie ein Problem versteckt,
was die wenig spätere Wattbarkeit verändert, behindert oder Portabilität behindert.
So, wieder ein Punkt auf der positiven Seite für diese
statischen Maßnahmen, aber damit nicht nur genug ist.
Ich sehe, da gibt es noch eine Zeile.
Effizienz, was bedeutet Effizienz nochmal? Kurz nachdenken,
wenn Sie die Antwort sagen, Es gibt ja Effektivitäten und Effizienz,
also sehr Effektivität kann ich ja mit,
wie viel Aufwand kann ich ein Ergebnis erreichen, Effizienz,
mit wie viel Aufwand kann ich, wie viel Ergebnisverreich, das Aufwandnutzenverhältnis.
Also wenn das Aufwand, Nutzenverhältnis hoch ist und hier niedriger,
dann ist das auf jeden Fall besser.
Und warum ist denn das so? Ja,
wenn sie zwei Stunden testen, dann sind sie froh,
wenn sie ein paar Fehler gefunden haben,
aber in zwei Stunden Inspektion oder Review können sie eine
ganze Latte von Mängeln und Problemen finden in einem Code,
der Fehler,
die sich irgendwann später ausgewirkte
Das heißt, hier sind wir in der gleichen Zeiteinheit sehr viel effizienter.
Ja, also deswegen sind, das war die Frage,
5, ich gehe mir nochmal zurück zu den Fragen.
Zum Teil auch die Frage 4. Ja, also die Frage 5,
sie sollen die gegenüberstellen und warum sind die zusätzlich sinnvoll,
weil sie halt viel mehr bringen,
weil sie viel mehr pro Zeiteinheit bringen,
andere Sachen bringen und hier unten über den Einsatzzeitpunkt,
haben wir bei der Gelegenheit auch schon gesprochen.
Nicht damit nicht genug, ich möchte ihnen noch ein paar statistische Daten geben,
nämlich ich habe aus verschiedenen Literaturquellen zusammengetragen,
deswegen sind die Zahlen hier ein bisschen Autor hat ein bisschen andere Zahlen,
je nachdem, auch in welcher Domänen,
was für eine Art von Software das erhoben wird.
Wenn wir jetzt mal sehen,
hier gibt es sozusagen so eine Art Trennlinie zwischen den beiden,
also oberhalb sind die Reviews unterhalb,
also die statischen Maßnahmen unterhalb hier sind die dynamischen Maßnahmen,
ich mache hier das mal durch eine Klammer,
deutlich,
So, und jetzt schauen wir uns mal an,
was hier eigentlich zusammengezählt wird. Man sagt also,
wenn ich die funktionale Spezifikation, die Anforderungsbeschreibung prüfe,
dann finde ich so durchschnittlich zwei bis fünf Prozent der Fehler.
Klingt nicht so besonders viel, aber wir erinnern uns ja dran,
dass wenn wir diese Fehler erst später finden, bauen wir ein falsches System.
Ja, falsch verstandene Anforderungen. Es führt zu einem
falschen System und dann haben wir sehr viel mehr Nacharbeit.
Also jeder diese zwei Prozent Fehler, die wir hier finden, ist uns sehr hilfreich. Wenn wir den Grobentwurf,
manche sagen auch lieber dazu,
Architektur prüfen können wir 10 bis 16 Prozent der Fehler finden,
sagt verschieden je nach Domäne und je nach Arzt der Software und der Art der Organisation,
Feinentwurf, das ist eher das, was der Entwickler macht,
wie ist die Klassenstruktur, wenn ich das prüfe,
würde ich hier 17 bis 22 Prozent Fehler finden.
Das ist eine relativ hohe Zahl. Und wenn ich
eine Code-Inspektion oder ein Review durchführe,
dann finde ich hier ein Fünftel bis sogar ein Drittel aller Fehler,
die ich da finden kann.
Wenn Sie das zusammenzählen, wird das mit den 100 Prozent
nicht hinkommen.
Aber die Größenordnung hilft uns sehr
So, wenn wir testen, dann gibt es verschiedene Testebenen.
Also wir werden dann hier ist von Kleiner und zum Größeren,
wir gehen da noch drauf ein im Abschnitt, Test.
Wenn ich auf der Ebene Module teste,
finde ich hier zwischen einem Achtel und einem Sechsel der Fehler bei einem Funktionstest,
der basierte, hoffentlich haben wir ja Fehler vorher schon gefunden,
findet nicht mehr so viele.
Hier ein Zehntel bis ein Siebtel der Fehler, der Komponententest,
ein Zwölftel bis ein Siebtel der Fehler und das Systemtest findet nochmal,
je nachdem wie viel ich vorher schon gefunden habe,
nicht mehr so sehr viele,
Ja, weil wenn schon alles zusammengebaut ist,
ist es sehr viel aufwendiger und nochmal überall hin zurückzugehen.
Aber ganz interessant wird es jetzt,
wenn wir jetzt diese Trennung nochmal anschauen, ja,
die Fehler, die wir hier oberhalb finden,
wenn sich da mal eine Summe bilden von den Mittelwerten,
dann sind wir sehr viel höher als die hier unten.
Und deswegen müssen ist es so wichtig, diese Inspektionen,
Reviews zu machen. Und mit die Dokumente anzuschauen,
eine Antwortungsbeschreibung zu prüfen, einen Entwurf zu prüfen,
weil ich das viel frühzeitiger machen kann und auch eine Code-Inspektion sehen Sie mal,
wie viel mehr das als Stan Test,
als der Test bringt.
Ja,
also das ist enorm wichtig
Soweit zu den Fehlern und Maßnahmen. Gleich gehen wir,
jetzt gehen wir dazu über die analytischen Maßnahmen im Detail
ein bisschen anzuschauen