Ganz letzte Frage in diesem Abschnitt Qualitätsmanagement, statische Methoden,
Reviews, möchte ich mit Ihnen durchgehen,
warum oder woher kommen denn die Kriterien?
Wir hatten hier solche Punkte, dass wir wenige Kriterien brauchen,
damit man das Ganze beherrschen kann. Wir haben zwei Stunden Zeit,
da kann man nicht eine Stunde lang vorher die Kriterien durchlesen,
aus dem behält die keiner.
Wir müssen uns also auf wenige konzentrieren, wie machen wir das?
Und da machen wir dafür eine Anleihe bei Methoden,
die eigentlich dafür entwickelt worden sind, Metriken aufzusetzen.
Metriken sind ja etwas, um quantinative Kenngrößen zu ermitteln,
auch über Softwarequalität, klar, aber dafür beschäftigen wir uns damit nicht.
Wir wollen Qualitätsmerkmale zerlegen oder analysieren. Ja,
und wir starten mit Qualitätszielen, die der Auftraggeber festgelegt hat und legen fest,
welche von den Teilmerkmalen sind besonders wichtig.
Und manchmal müssen wir dabei mehrere betrachten und wir versuchen,
das zu priorisieren. Und diese Methode,
die ich Ihnen vorstellen möchte, Methode ist eigentlich fast so hochgegriffen.
Low-Tech ist immer, ist etwas, was ich immer empfehlen möchte.
Eine Vorgehensweise, wie kann ich das machen? Die hilft
uns, so etwas zu finden. Hier geht es zwar vor allen Dingen darum,
bei diesen Metrikens und Qualitätsindikatoren, die etwas messbar machen,
aber uns interessiert vor allen Dingen, was sind denn wichtige Kriterienqualitäten,
Entwurfsprinzipien, die man prüfen sollte.
Ich stelle ihnen die Methode im Original vor und dann sage ich,
was wir daraus entnehmen für die Priorisierung von Dingen,
die über eine Checkliste schreiben
Für zunächst startet man mit einem Qualitätsziel, diese Qualitätsziel haben wir ja besprochen.
Und hier wäre es Wartbarkeit. Und da gibt es Unterziele,
Kriterien für die Bewertung, Analysierbarkeit, Änderbarkeit, Stabilität, Testbarkeit.
Das wären jetzt die Untermerkmale von Wartbarkeit in der etwas älteren Qualitätsnorm.
Und was man für die Metriken dann macht,
man stellt verschiedene Metriken hier raus.
Hier möchte ich aber mit Ihnen gar nicht durchgehen.
Ich möchte mit Ihnen durchgehen, was machen wir denn für
unsere Inspektion,
für unsere Tests
Die Inspektionen, nehmen wir, sagen wir, okay,
Analysierbarkeit ist besonders wichtig, worauf kommt es da an,
nicht so tief geschachtelt der Klassen,
das ist irgendwie sowas hier, nicht so große Schnittstellen.
Wie gesagt, ich wollte hier eigentlich nicht durchgehen,
sondern nur sagen, wir versuchen dann Kriterien aufzustellen, die dazu passen.
Und das ist genau das, was wir machen,
wenn wir eine Checkliste aufstellen. Ja,
wir machen diese, versuchen rauszusuchen, was ist wichtig,
das oder ist das am wichtigsten oder ist das am wichtigsten.
Und für die wichtigsten wollen wir
etwas tun
Eine ganz ähnliche Vorgehensweise Methode ist das Factor Strangy Modell.
Die geht aus von den Qualitätsfaktoren und sucht eine Erkennungsstrategie,
die da gut passt. Auch wieder das Gleiche,
was wir eben hatten, ein bisschen anders aufgesetzt von anderen Autoren.
Wir finden viele Methoden, die hier irgendwie ähnlich sind.
So, ich versuche so rauszukriegen, woran erkenne ich das denn?
Oder ich versuche rauszukriegen, wo gibt es denn ein hohes Problem?
Typischer Fall wäre Buffer Overflows. Oder das von
der Fehlerbehandlung,
was fehlt
Und das versuche ich mich darauf zu konzentrieren,
was ist das Wesentliche, auch das ist nun vorgehensweise,
die uns hilft, sich auf das Wesentliche zu konzentrieren und solche Sachen,
die man hier noch zusätzlich hat, dann eben nebenbei auch noch zu finden.
Ich illustriere das auch mit dem Bildchen, ja,
also wir haben hier zunächst die Qualitätsfaktoren, die wir vielleicht brauchen,
Wartbarkeit ist hier so ein ganz zentraler und dann haben wir Prinzipien,
Entwurfsprinzipien, manchmal auch Entwurfsregeln,
zum Beispiel,
dass wir Gott Glas nicht wollen,
dass wir Data Class nicht wollen
Sprich, das sind also Namen von Refactorings oder Namen von Betsmerz,
die hier eine Rolle spielen. Hier in wieder Metriken,
wie gesagt, da möchte ich nicht weiter drauf eingehen,
ist nicht unser Beispiel. Wir nutzen diese Methoden,
die eigentlich für Regeln gedacht sind dafür, um zu sagen,
nach was für Sachen suchen wir denn?
Und das sind vor allen Dingen Prinzipien mit ihrem Namen, Regeln und Heuristik.
Ja, ich glaube, damit bin ich schon ganz am Ende des Abschnittsqualitätsmanagement.
Ich möchte Ihnen für Ihre wirkliche Arbeit in einem Projekt mal vorschlagen,
dass Sie so ein Styleguide für eine oder eine Checkliste verwenden für Inspektionen,
seien Sie vielleicht derjenige,
der Codeinspektion andstattet oder beteiligen sich auf jeden Fall dabei.
Alle können nur profitieren. Man muss sich dabei nicht
schlecht fühlen. Es muss natürlich entsprechend organisiert werden.
Was kommt in so ein Style, in so eine Checkliste?
Natürlich zunächst, dass man, gibt es da Sachen,
die ich übernehmen kann von sprachspezifischen Regeln?
Was macht man in Java? Was macht man in sich
haben? So etwas, dann könnte man sagen,
wir brauchen ein paar Sachen wie Namen vergeben werden. Gut,
den Namen sind total wichtig für die Verständlichkeit und damit das,
auch wenn die Verständlichkeit durchgeben ist,
dass das dann entsprechend gut separiert werden kann bezüglich ihrer Zugehörigkeit zu Themen.
Und dann finde, gibt es noch eine weitere Klasse.
Also hier ist nur ein Beispiel, wo wir was mal verwenden können.
Ich glaube, hier habe ich gleich auch noch,
oder den Linkern, die ihnen da mitgeben.
Und dann gibt es noch Style-Guides für bestimmte APIs oder für bestimmte Produkte.
Wie arbeite ich damit? Auch das ist sehr hilfreich,
weil es manchmal im Handbuch nicht so richtig dasteht.
So, wir hatten dazu Fragen. Wir schauen mal,
ob wir die Fragen alle beantwortet hatten.
Die waren mir, ja. Also wir hatten den Ablauf
einer Inspektion eines Reviews besprochen
Die Rollen aber noch nicht besprochen. Doch haben wir gesagt,
dass es gibt den Autor und den Experten.
Und manchmal gibt es noch den Moderator. So, die Ziele,
das sind die, die wir auf dieser Tabelle vorhin hatten.
Ja, wir wollen also, ich gehe nochmal ganz zurück,
das war ziemlich am Anfang dieses Kapitels.
Ich finde es auch irgendwo hier. Ja, das war,
dass wir, das ist so die Gegenüberstellung, ja,
und die Stärken sind halt bei den Reviews sind,
dass wir alle Arten von Produkten verwenden können,
also auch Sachen, die schon kurz vor der Feststellung sind,
genauso wie welche,
die das Kronen überdacht sind
Und wir können das Ganze frühzeitig machen.
Und wir machen das vor allen Dingen für innere Qualitätsmerkmale,
für Korrektheit kriegen wir das mit den Testen ganz gut hin.
So, beginnen wir zu den Fragen.
Wo sind Sie denn hier? Ja,
also die Ziele wären dann genau solche Schwachstellen zu finden,
den Nutzer, den Übertrag von Know-how, wo haben wir das stehen?
Ja, hier, dass wir Anerkennung zeilen,
dass wir durch neue Fragestellungen neue Erkenntnisse über Code gewinnen.
Das ist ganz effektiv, arbeitet effektiver als Test,
ist auch ein wichtiger Punkt.
Und dass wir motivieren für guten Programmierstil.
Das war hier auch noch gut. Also die Folie zeigt,
dass alles,
was wir hier brauchen