Mit diesem Dokument versuche Ich 2 Klappen mit einer Fliege zu schlagen.
Wer jetzt eine Methode erwartet, dass ein Programm dieses analysiert und eine Zahl für die Qualität erhofft, den muss Ich enttäuschen. Sie können eine vernünftige Aussage, nur dann geben, falls Sie die Anforderungen kennen. Anforderungsmanagement und Qualtitätssicherung gehören zusammen, wie das Ferrari Beispiel verdeutlichen sollte. Eine Anforderung, aus der sich kein Test ableiten lässt, ist Geschwafel und hat wenig Wert.
Ich habe ein Foto des aktuellen Ferraris der Formel 1 Saison 2020
Sind Sie Sebastian Vettel und wollen möglichst viele Rennen gewinnen, so mag dies das optimale Auto sein. Zu diesem Zeitpunkt ist noch kein Rennen gelaufen, von daher ist die Aussage schwierig.
Wollen Sie lediglich Ihre Kinder in die Schule bzw. Kita fahren und ab und zu die Großeltern besuchen, haben Sie ein überteuertes Produkt, das die Aufgabe leidlich erfüllt. Ggf. müssen Sie mehrfach fahren, denn mehr als ein Passagier werden Sie nicht mitnehmen können.
Sind Sie Handwerker, der zum Kunden viele sperrige Materialien mitnehmen muss, dann ist der Ferrari vollkommen unbrauchbar. Ok - vielleicht gelingt es diesen Ferrari mit Anhängerkopplung zu verkaufen. Bei Unternehmen, die eine rein wirtschaftliche aber keine Qualitätskontrolle durchführen, werden Sie ggf. sogar dafür einen Orden erhalten. Diese Firmen sollten sich aber fragen ob der Sinn eines Unternehmens ausschließlich in der Gewinnmaximierung liegt, oder ob die notwendigen Gewinne sich nicht daraus ergeben sollen den Bedürfnissen der Kunden zu entsprechen.
Aber selbst, wenn die Anforderungen nicht bekannt sind, muss man an auf eine Bewertung nicht verzichten. Der folgende Ferrari ist nicht zu gebrauchen, unabhängig von den Anforderungen.
Das Beispiel soll motivieren, Qualitässicherung und Anforderungsmanagement immer gemeinsam zu betrachten. In vielen Firmen ist Qualitätsicherung ein nachgelagerter Prozeß. Die Grundsätzliche Architektur wird aber anfangs festgelegt. Sie muss natürlich mit neuen Anforderungen immer neu angepasst werden. Qualitässicherung sollte aber immer als ein vorgelagerter Prozeß betrachtet werden. Eine Anforderung ist nur dann von hoher Qualität, wenn sie testbar ist.
In diesem Dokument geht es um die Bewertung von Artefakte, d.h. SourceCode, Handbücher und Dokumentation jeglicher Art
Qualitative Bewertungen bewerten die Qualitätsmerkmale von Anforderungen. Qualitative Bewertungen sind kontextabhängig von den Anforderungen.
Ändern sich die Anforderungen, ändert sich häufig auch die Bewertung.
Quantitative Bewertungen sind meist unabhängig von den Anforderungen. Sie ergeben sich häufig durch statische Codeanalyse. Typische Quantitative Bewertungen sindDiese Unterscheidung gibt es noch vor allen in älteren Lehrbücher. Es setzt sich aber mehr und mehr die Erkenntnis durch, dass eine exakte Unterscheidung nicht möglich ist.
Ohne Zweifel können Metriken sinnvolle Hinweise über die Qualität aufzeigen. Allerdings ist es extrem gefährlich komplexe Zusammenhänge in wenigen Zahlen auszudrücken. Die Gefahr ist die gemessenen Werte mit der Realität zu verwechseln. Die Entscheidungsträger stützen sich gerne auf Metriken, da sie meist von der Fachlichkeit wenig Ahnung haben. Sind sie selbst rechenschaftsabhängig werden die Entscheidungsträger nicht wagen, eine Entscheidung zu treffen, die nicht durch die Messresultate begründet sind.
In meiner Reha wurde das Kinderspiel Die Türme von Hanoi benutzt, um meine logische Denkfähigkeiten zu messen. Als KPI (Key Performance Indicator) wurde die Anzahl der verwendeten Züge und die benötigte Zeit verwendet. Jetzt variieren die Ergebnisse abhängig davon, ob der Patient das Spiel noch nicht kennt, schon oft gespielt und ggf. wie Ich im Studium selbst programmiert hat. In meinem Beispiel wurden nicht meine Fähigkeit zur Konzentration und zum logischen Denken, sondern meine Erfahrung gemessen. Ich konnte der Studentin, die die Tests durchführte, sagen dass Ich die Lösung auswendig kenne. Ein Algorithmus oder ein Sachbearbeiter, der Angst hat für seine Entscheidung belangt zu werden, würde diesen scheinbaren Erfolg des Spiels dazu nutzen, um mich gesund zu schreiben und ggf. die Finanzierung der Reha zu verweigern. Metriken sind nun mal nicht die Realität, sondern immer nur eine starke Vereinfachung dieser Realität.
Die Metriken täuschen eine Objektivität vor, die es nicht gibt. Die Auswahl, welche Metrik über welchen Zeitraum verwendet wird, ist eine Werteentscheidung. Pisa im Bildungssystem misst nicht die sozialen Fähigkeiten oder die Motivation der Schüler. Es reduziert Schule auf reine Wissensvermittlung. Es berücksichtigt nicht die Gründe schlechter Ergebnisse. Häufig spiegeln sich die sozialen Probleme der Schüler in den Ergebnissen. Richtig gefährlich wird es falls die Metriken gleichzeitig zur Bewertung verwendet werden. Es kann dazu führen, dass die besten Mitarbeiter sich auf die leichtesten Aufgaben konzentrieren und die Aufgaben mit den höchsten Risiken von denjenigen Mitarbeiter durchgeführt werden, die am wenigsten dafür geeignet sind.
Ich habe schon in mehreren Firmen erlebt, dass das obere Management Entscheidungen trifft, basierend auf Daten, die das mittlere Management so aufbereitet hat – dass sie selbst gut dastehen. Mit aufbereiten meine ich ausdrücklich nicht fälschen, aber es gibt in der Interpretation von Statistiken immer genügend Spekulationsspielräume.
Zusammenfassung: Metriken können sinnvolle Hinweise geben, solange diese von den Menschen interpretiert werden, die das fachliche Wissen haben diese zu interpretieren. Leider sind Entscheidungsträger selten Fachexperten, sondern rein ökonomisch geschult.
CBO misst für jede Klasse, die Anzahl der Klassen, die direkt mit ihr gekoppelt sind. Eine Kopplung ergibt sich durch:
Die Grundidee von McCabe ist es den Kontrollfluss eines Softwaremoduls durch einen Graphen darzustellen. Jede Anweisung wird durch einen Knoten dargestellt. Die Kanten des Graphen zeigen die Reihenfolge der Anweisungen:
Es gilt die Formel: M = e -n + 2p
| M | misst die Komplexität und sollte möglichst klein sein. Es wird ein Wert unter 10 angestrebt |
| e | Anzahl der Kanten im Graphen |
| n | Anzahl der Knoten im Graphen |
| p | Anzahl der der Graphen des Moduls. I.a. wird jede Funktion und jede Prozedur durcch einen Graphen repräsentiert. |
Die McCabe Metriken empfinde Ich als praxisfern. Entscheidet für die Verständlichkeit sind z.B. die sinnvolle Benennung der Variablennamen. Ich denke die McCabe Metriken sollten Inspektionen (Code Reviews) nicht ersetzen. Praxisnäher empfinde Ich die 90 Sekunden Regel. Eine Methode sollte von einem nicht eingearbeiteten Mitarbeiter in 90 Sekunden verstanden werden. Es wird nicht gemessen, ob die Variablen konsistent und sinnvoll benannt werden, o-der ob der Code ausreichend kommentiert ist.
Die meisten Softwareentwickler kennen den Effekt, dass ein Projekt anfangs relativ zügig läuft, aber es mit der Zeit immer schwieriger wird, das Projekt zu warten oder neue Features einzuführen. Der Grund liegt meistens in mangelnder Softwarearchitektur, besonders das Nicht Beachten der Abhängigkeiten. Ist jede Komponente von jeder Komponente abhängig, so muss man bei neuen Komponenten die Auswirkungen auf die anderen zu beachten. Der Aufwand für Änderungen steitgt exponential. Haben diese komponenten eine gut durchdachte Struktur, kann man diesen Effekt sogar vermeiden und nach Martin Fowler sogar umdrehen
Ich bin begeistert von dem Vortrag von Martin Fowler, da er aufzeigt, dass die Aufgabe eines Softwarearchitekten in erster Linie eine soziale und kommunikative Aufgabe ist. Zweitens zeigt er eine gute wirtschaftliche Begründung in die Notwendigkeit von Architekturen ein.
Martin Fowler beschreibt die Design Stamina Hypothesis. Die deutsche Übersetzung des englischen Wortes stamina ist Ausdauer bzw. Stehvermögen.
Unsere Alltagserfahrung, dass man mit Verzicht auf interner Qualität die Kosten senkt, lässt sich auf Softwareentwicklung nicht übertragen. Dem Kunde interessiert nur die äussere Qualität und deswegen ist es schwer dem Management in Investitionen in die innere Qualität zu üerzeugen. Bei Hinzufügen von neuen Features, ist es notwendig die Auswirkungen auf den Rest der Software zu beachten. Deshalb lohnt es sich explizit die Abhängigkeiten zwischen den Softwaremodulen zu ordnen und zu überwachen.
In der folgenden Abbildung haben wir 3 Komponenten, die auf eine Komponente mit dem Element X zugreifen. Die oberen Komponenten sind abhängig von der unteren Komponente. Ein Fehler in der unteren Komponente würde ein Scheitern der oberen Komponente verursachen. Da die untere Komponente selbst von keinen anderen Komponenten abhängig ist, gilt sie als stabil.
| Fan-In | Eingehende Abhängigkeiten. Diese Messgröße beschreibt die Anzahl der Klassen außerhalb der betreffenden Komponente, die von Klassen innerhalb der Komponente abhängig sind. |
| Fan-Out | Ausgehende Abhängigkeiten. Diese Messgröße beschreibt die Anzahl der Klassen innerhalb der betreffenden Komponente, die von Klassen außerhalb der Komponente abhängig sind. |
| Instabilität | I=Fan-out/(Fan-in+Fan-out). Der Wertebereich dieser Messgröße beträgt [0,1]. Dabei entspricht I=0 einer maximal stabilen Komponente und I=1 einer maximal instabilen Komponente. |
Abstrakte Klassen haben keine konkreten Ausprägungen. Mit abstrakten Klassen er-hofft man sich eine größere Wiederverwendbarkeit. Die konkreten Details werden dann von den konkreten Unterklassen der abstrakten Klasse implementiert.
Wie misst man nun den Grad der Abstraktheit von Komponenten bzw. Pakete? Es ist der Anteil der enthaltenen abstrakten Klassen, an der Gesamtheit der Klassen.
| Nc | Anzahl aller Klassen bzw. Schnittstellen in der Komponente |
| Na | Anzahl abstrakter Klassen bzw. Schnittstellen in der Komponente |
| A | A=Na/Nc |
Die Komponenten bzw. Pakete lassen sich in ein I_A Diagramm eintragen. Die x-Achse besteht aus dem Grad der Instabilität und die y-Achse wird der Grad der Abstraktheit eingetragen. Das Ziel sollte es sein, dass die Pakete bzw. Komponenten sich in der Nähe der Hauptreihe liegen. Die Qualität des Gesamtsystems lässt sich durch den Abstand der einzelnen Komponenten bzw. Pakete zu der Hauptreihe ablesen.
Die Qualität des Gesamtsystems lässt sich durch den Abstand der einzelnen Komponenten bzw. Pakete zu der Hauptreihe messen.
| D=ΙA+I-1Ι | Der Wertebereich dieser Messgröße beträgt [0,1]. Dabei gibt der Wert 0 an, dass sich die Komponente unmittelbar auf der Hauptreihe befindet. Der Wert 1 weist hingegen aus, dass die Komponente in der größtmöglichen Distanz zur Hauptreihe positioniert ist. |
| Quelle | Robert Cecil Martin, Clean Architecture Kapitel 14.4.8 |
Komponenten, die gleichzeitig abstrakt und stabil sind, gelten als sinnlos, und sollten vermieden werden.
| Funktionale Eignung |
|
Functionality |
| Zuverlässigkeit |
|
Reliability |
| Benutzbarkeit |
|
Usability |
| Leistungseffizienz |
|
Performance, Efficiency |
| Sicherheit |
|
Security |
| Kompatibilität |
|
Compatilibity |
| Wartbarkeit |
|
Maintainabality |
| Übertragbarkeit |
|
Portability |
Ein weiteres Qualitätsmerkmal wird die Skalierbarkeit genannt. Mit der Skalierbarkeit wird die Anpassbarkeit der Hard- und Software bei zunehmenden Anforderungen bezeichnet.
Es wird zwischen vertikaler und horizontaler Skalierbarkeit unterschieden.
Unter vertikaler Skalierung versteht man ein Steigern der Leistung durch das Hinzufügen von Ressourcen zu einem Knoten/Rechner des Systems. Beispiele dafür wären das Vergrößern von Speicherplatz, das Hinzufügen einer CPU, oder das Einbauen einer leistungsstärkeren Grafikkarte. Charakteristisch für diese Art von Skalierung ist, dass ein System unabhängig von der Implementierung der Software schneller gemacht werden kann. Das heißt, es muss keine Zeile Code geändert werden, um eine Leistungssteigerung durch vertikales Ska-lieren zu erfahren. Der große Nachteil dabei ist jedoch, dass man früher oder später an eine Grenze stößt, bei der man den Rechner nicht weiter aufrüsten kann, wenn man bereits die beste Hardware verwendet, die zu diesem Zeitpunkt am Markt ist.
Im Gegensatz zur vertikalen Skalierung sind der horizontalen Skalierung keine Gren-zen (aus Sicht der Hardware) gesetzt. Horizontale Skalierung bedeutet die Steigerung der Leistung eines Systems durch das Hinzufügen zusätzlicher Rechner/Knoten. Die Effizienz dieser Art der Skalierung ist jedoch stark von der Implementierung der Software abhängig, da nicht jede Software gleich gut parallelisierbar ist.
Ein KPI ist eine Messgrösse, die Aufschluss darüber gibt, ob ein Ziel erreichct wird, oder nicht
Die folgende Tabelle habe ich von der Firma ScienceSoft
Der Wartbarkeitsindex ist eine sehr komplizierte Formel, mit den Anzahl der Codezeilen und den Anzahl der Kommentarzeilen als Argument.
Diese Metrik geht einfach davon aus, dass ein gut kommentiertes Programm einfahcer zu warten ist, als ein schlecht kommentiertes Programm. Meine Erfahrung ist aber das Gegenteil. Ich erlebe regelmässig, dass Kommentar und Code auseinanderlaufen. Viele ändern die Methode ab, ohne den Kommentar zu aktualisieren. Kent Beck meinte deswegen. Do not comment bad code, rewrite it. Die Metrik misst nur das Vorhandensein von Kommentaren und nicht die Qualität der Kommentare. Um die Metrik mit wenig Aufwand zu erfüllen, reicht es Texte aus einem Gebetsbuch in die Methoden einfach automatisiert hereinzugenerieren. Bei vielen Projekten, an denen Ich beteiligt war ist wahrscheinlich Beten die letzte und einzige Hoffnung.
Eine Metrik kann und sollte kein Code Review ersetzten. Desweiteren sollte man ein gemeinsames Verständnis aufbauen, was wie zu kommentieren ist. Die Funtkionalität einer Methode sollte durch einen passenden Methodennamen erfolgen. Kommentieren sollte man nur das, was aus dem Code selbst nicht ersichtlich ist. Z.B. Ein Hinweis auf eine Quelle (Literatur), oder warum man sich für einen speziellen Algorithmus entschieden hat, und warum man nicht die Alternative genommen hatte
;
Szenarios sind elementare Bestandteile von Anforderungen. Szenarios sind immer konkret und fördert das Prinzip Anforderungen immer an konkreten Beispielen fest-zumachen. Konkrete Beispiele verhindern Missverständnisse und erleichtert die Testbarkeit. Sind diese mit Qualitätsattributen und den dazugehörigen KPI's(Key Performance In-dicator) verknü:pft, so kann das Szenario als Test verwendet werden.
| Anwendungsszenarien | beschreibt, wie das System auf bestimmte Auslöser reagieren soll. |
| änderungsszenarien | Es wird beschrieben, was bei einer Modifikation des Systems oder seiner direkten Umgebung passiert. Z.B. wenn eine zusätzliche Funktion implementiert werden soll. |
| Stress- und Grenzszenarien | Wie soll das System auf Extremsituationen reagieren? |
Da die ursprüngliche Quelle ein englischsprachiges Buch ist, wurde die englische Übersetzung in Klammern geschrieben.
Wie oben beschrieben, benötigt ein Sezenario eine Antwortarithmetik, die beschreibt ob das Szenario richtig oder falsch ist. Dies wird mit spezifischen Qualitätsbämen gemacht.
ATAM steht für Architecture TradeOff Analysis Method und dient dazu, zusammen mit den Stakeholdern in einem oder mehr Workshops Szenarien und dazugehörige Qualitätsbäume zu finden. Die vorgestellte Methode besteht aus 4 Phasen, wobei die 3. Phase - die Bewertungs-phase - iterativ ggf. mehrfach wiederholt werden. Die Phasen sind
Das folgende Bild stammt aus dem Buch Effektive Softwarearchitekturen
| Risiken | Dies sind die Teile der Architektur, die die Geschäftsziele gefährden und Probleme bereiten können. | Empfindliche Stellen | Dies sind diejenigen Stellen der Architektur, bei denen kleine änderungen weitreichende Folgen haben können. |
| Kompromisse | Die Kompromisse geben an, wie eine Entwurfsentscheidung eventuell mehrere Qualitätsmerkmale wechselseitig beeinflussen kann. |
| Nicht-Risiken | Welche Szenarien werden auf jeden Fall erreicht? |