Beurteilung der Qualität von Software. Software Benchmarking und die Entwicklung eines Plugins für Sonarcube

Inhaltsverzeichnis

1 Einleitung

2 Qualität von Software
2.1 Was ist „Qualität“?
2.2 Metriken
2.3 Regeln
2.4 Software-Qualitat

3 Statische Code-Analyse
3.1 Syntax-Analyse
3.2 Semantik-Analyse
3.3 Grafiken

4 Software Benchmarking
4.1 Vorgehen
4.2 Benchmark-Verteilung
4.3 Visualisierung - Das Boxplot

5 SonarQube
5.1 Funktionsweise

6 SBench
6.1 Konzept
6.2 Umsetzung
6.3 Anwendung
6.4 Erfahrungen

7 Zusammenfassung

8 Ausblick

Abbildungsverzeichnis

Kurzfassung

Software wird mittlerweile in fast allen Bereichen des Lebens eingesetzt. Sie muss möglichst fehlerfrei funktionieren und von hoher Qualitat sein. Doch was ist Qualitat von Software überhaupt und wie kann man sie bestimmen? Beide Teile dieser Frage sind zentrales Thema dieser Arbeit.

Zuerst wird versucht eine Definition für Software Qualitüt zu finden, bevor ein Vorgehen zur dessen Bestimmung, nümlich das Software Benchmarking, vorgestellt wird. Die nahere Betrachtung des Benchmarkings fuhrt anschließend zur Entwicklung eines Plug-Ins für SonarQube, welches das Benchmarking der einzelnen Softwareprojekte ermüglicht. Dieses Plug-In, namens SBench, errechnet, aufgrund der Regelverletzungen, alle vier Quartillen und ordnet die Projekte anschließend darin ein. Das Ergebnis wird in Form eines Boxplots und eines Benchmark Profils für den Benutzer grafisch dargestellt.

Die Anwendung des Plug-Ins zeigte, dass die Qualitaüt der Projekte, im Vergleich zu den Referenzprojekten, sehr schnell eingeschützt werden konnte und sich die Moglichkeit eröffnete gezielt Qualitatsverbesserungen durchzufuhren. Das einzige Manko stellt die doch lüngere Zeit in Anspruch nehmende Berechnung dar.

1 Einleitung

Die Informations- und Kommunikationstechnologien haben in den letzten Jahrzehnten eine immer bedeutungsvollere Aufgabe erhalten. Mittlerweile ist eine Welt ohne Computer, Smartphones und anderen Rechner unvorstellbar. Sie sind Bestandteil des täglichen Berufslebens, alle Bankgeschäfte werden mit ihrer Hilfe abgewickelt und in naher Zukunft wird es vermutlich mäglich sein, ein ganzes Haus durch wenige Tastendrucke zu steuern. All diese eingesetzten Geräte konnten jedoch nicht die gewänschten Funktionalitäten ausfähren, würde auf ihnen nicht eine geeignete Software laufen.

Ein Stäck Software ist inzwischen in mehr Dingen enthalten, als man es sich jemals vorstellen konnte. Von der Waschmaschine, äber Uhren bis hin zu Autos funktioniert alles nur noch mit Hilfe von Software. Man muss in gewisser Art und Weise dieser Software vertrauen, denn bei etwaigen Fehlern konnte es zu fatalen Folgen kommen. Doch auch wenn es sich „nur“um eine Software zur Verwaltung der Arbeitszeiten einer Firma handelt, ist es von großem Interesse fär diese Firma, dass sie ein Produkt erwerben, welches von hoher Qualitat ist. Doch wie kann man die Qualitat von Software beurteilen?

Diese Frage ist komplexer als sie auf den ersten Blick scheint. Viele Versuche wurden und werden unternommen um diese Frage besser beantworten zu kännen. Einen sehr guten Ansatz in diesem Gebiet stellt das Benchmarking dar. Diese Arbeit beschäftigt sich genau mit diesem Ansatz und versucht einen Bogen zu spannen, von der Definition von Software Qualität bis hin zu einem fertigen Produkt. Das zentrale Ziel dieser Arbeit ist es, ein Plug-In fär die Open-Source Software SonarQube zu entwickeln, welches dem Benutzer erlaubt, die eigene Software zu benchmarken.

Um dieses Ziel zu erreichen wird in Abschnitt 1 zuerst eine Definition gesucht um Qualität von Software zu beschreiben. Hierbei werden auch Metriken vorgestellt, welche bei der Beurteilung eine wichtige Rolle spielen. In Abschnitt 2.4 wird dann ein Verfahren vorgestellt, welches es erlaubt, Software hinsichtlich gewisser Regeln zu äberpräfen. Nachdem eine Vorstellung daruäber gegeben wurde, was Qualitaät von Software bedeutet und ein zentrales Verfahren zur Analyse von Software vorgestellt wurde, beschäftigt sich Abschnitt 3.3 näher mit dem Thema des Software Benchmarkings. Bevor die Entwicklung des Plug-Ins naher besprochen werden kann, wird in Abschnitt 4.3 die Open-Source Software SonarQube vorgestellt, fär die das Plug-In entwickelt wurde. Zum Abschluss kann dann das fertige Plug-In, in Abschnitt 5.1, vorgestellt werden, bevor noch eine Zusammenfassung (Abschnitt 6.4) und ein Ausblick (Abschnitt 7) folgt.

2 Qualität von Software

An vielen Stellen der Literatur und auf vielen Seiten des Internets liest man Uber den immer mehr verlorenen Fokus auf Qualität in der Softwareentwicklung. Doch Qualitat ist bei manchen Softwaresystemen ein sehr wichtiger Faktor und war schon Ursache fur große Katastrophen, wie die Explosion der Rakete „Ariane 5“, welche durch einen Overflow Fehler einen Schaden von ca. 500 Millionen US-Dollar verursachte (Huckle, 02.12.1999). Dies stellt nur ein Beispiel von einer Unzahl an kritischen Softwarefehlern mit schwerwiegenden Folgen dar. Es existieren viele sensible industrielle Bereiche die nach einer fehlerfreien Software streben, da Fehler große monetäre Verluste und sogar Menschenleben nach sich ziehen kännen. Qualität darf jedoch nicht mit „Fehlerfreiheit“gleichgesetzt werden, da diese lediglich einen Qualitätsaspekt darstellt (Balzert, 1998-2001), doch dies wird in Abschnitt 2.3 näher besprochen.

Die Qualitäat eines Softwareprodukts in anderen, nicht dermaßen sensiblen, Bereichen spielt jedoch auch eine große Rolle. So sehen Sanders und Curran (1994) Qualität unter anderem als kritischen Faktor um als Softwarehersteller erfolgreich zu sein bzw. gar auf dem Markt zu uberleben. Auch wirkt sich die Qualität von Produkten im Allgemeinen auf die damit zu erzielenden Einnahmen aus (Juran und Godfrey, 1999). So kännte es zum Beispiel passieren, dass durch eine mangelhafte Qualität der Käufer in Zukunft nicht mehr bei diesem Anbieter kauft oder das er gerade wegen der hohen Qualität bereit ist mehr zu bezahlen als für Vergleichsprodukte (Juran und Godfrey, 1999).

Diese Punkte sollen als Motivation dienen sich mit Qualitat von Softwaresystemen auseinander zu setzen. Im Folgenden wird versucht Definitionen fär Qualitat im Allgemeinen und Qualitat von Softwaresystemen im Speziellen zu finden. Dies erscheint als essentiell, da die anderen Bereiche dieser Arbeit, wie das Benchmarking, auf diesen Definitionen aufbauen und somit ein Grundverständnis äber diese Thematik zu einem besseren Verstandnis beitragt.

2.1 Was ist „Qualität“?

Die Einleitung in dieses Kapitel hat schon aufgezeigt wie vielschichtig und umfassend der Begriff Qualität sein kann. Er wird zudem im alltäglichen Sprachgebrauch verwendet (Kan, 2003) und er findet in fast jedem wissenschaftlichen Forschungsgebiet Platz . Dadurch kann an dieser Stelle auch keine eindeutige Definition formuliert werden, welche fär alle Bereiche des Lebens und der Wissenschaft anwendbar ist. Als Grund dafär, dass Qualität fär jeden etwas anderes bedeutet, sieht Kan (2003) darin, dass das Wort eher als Konzept zu verstehen ist und Konzepte auf unterschiedlichen Ebenen abstrahiert werden kännen. Um nun diese Fälle an Definitionen etwas einschränken zu können, werden zuerst verschiedene Ansatze vorgestellt und eruiert ob einer dieser Ansätze zu der Thematik dieser Arbeit passend ist oder nicht. Dadurch wird es mäglich den Fokus auf Definitionen von bestimmten Ansätzen zu legen und die Menge etwas einzuschranken. Danach wird in Abschnitt 2.3 versucht einen Uberblick über einige verschiedene Definitionen zu geben.

Nach Garvin (1984) lassen sich fär den Begriff „Qualitat“fänf verschiedene Ansatze von Definitionen unterscheiden:

- der transzendente Ansatz
- der auf Benutzer bezogene Ansatz
- der auf Prozesse bezogene Ansatz
- der auf den Wert bzw. auf Kosten und Nutzen bezogene Ansatz
- der auf Produkte bezogene Ansatz

Fär jeden dieser Ansätze fährt Garvin (1984) Beispiel-Definitionen aus der Literatur an. Nachfolgend werden kurz die einzelnen Ansätze erlautert.

Der transzendente Ansatz geht davon aus, dass Qualitat nur durch Erfahrung erkannt werden kann und es nicht mäglich ist sie genau zu definieren oder gar zu analysieren (Garvin, 1984) (Malich, 2008) (Balzert, 1998-2001). Qualitat ist zudem absolut, leicht zu erkennen und ist Kennzeichnung von großen Erfolgen und kompromisslosen Standards (Garvin, 1984)(Malich, 2008) (Balzert, 1998-2001).

Dieser Ansatz ist ein eher philosophischer und daher ungeeignet fär die Praxis (Balzert, 1998-2001) bzw. fur diesen Kontext.

Der auf Benutzer bezogene Ansatz sieht das Ganze aus der Kundensicht. In mancher Literatur ist speziell von der Erfüllung der Erfordernissen der Kunden die Rede wie in (Juran und Godfrey, 1999), (Sanders und Curran, 1994), (Kan, 2003), (Malich, 2008) und (Garvin, 1984). Das bedeutet, dass Kunden spezielle Wünsche an das Produkt besitzen bzw. mit dem Produkt bestimmt Aufgaben losen müchten. In diesem Zusammenhang ware Qualitüt also die Übereinstimmung mit den Kundenwünschen. In mancher Literatur wird diese Art der Sichtweise auf Qualitat mit dem Begriff „fitness for use“bezeichnet wie Kan (2003) und Garvin (1984). Also wie geeignet ist das Produkt für seinen Einsatz beim Kunden. Dieser Grad der Übereinstimmung drückt sich durch die Kundenzufriedenheit aus. Fur Kan (2003) ist die Kundenzufriedenheit sogar die beste Art Qualitat zu messen. Dieser Vorschlag von Kan macht in einem heutzutage übersattigten Markt auch viel Sinn, da Kundenzufriedenheit zu Kundenbindung und damit zu Ünternehmenserfolg führt (Töpfer und Mann, 2008). Es gibt jedoch zwei große Probleme in diesem Zusammenhang. Auf der einen Seite ist es schwer die Wünsche vieler verschiedener Kunden unter einen Hut zu bringen (Garvin, 1984), was jedoch bei speziell zugeschnittener Software nicht der Fall würe, da es hier nur einen Kunden gübe. Auf der anderen Seite kann man nach Garvin (1984) Qualitüt nicht mit dem maximieren von Kundenzufriedenheit gleichstellen, was das Problem aufwirft, welche Produktmerkmale nun Qualitat bedeuten und welche lediglich den Nutzen für den Kunden erhühen.

Es soll an dieser Stelle darauf hingewiesen werden, dass ein zentraler Bestandteil der Definitionen, der meisten untersuchten Literatur, sich lediglich auf die Erfüllung von Erfordernissen bezieht, ohne dabei explizit den Kunden zu erwühnen. Der Kunden-orientierte Ansatz ist ohnehin für den Bereich des Benchmarkings nur bedingt brauchbar, da man mit dem spaüter in dieser Arbeit vorgestellten Vorgehen die Qualitaüt nicht anhand von Kundenwünschen misst. Hierfür eigenen sich andere Ansütze besser. Jedoch darf er auch nicht komplett außer Acht gelassen werden, da er doch für viele eine sehr zentrale Rolle spielt und die anderen Ansaütze meist in einer gewissen Form mit diesem Ansatz in Verbindung stehen.

Der auf Prozesse bezogene Ansatz sieht Qualitat als den Grad der Übereinstimmung mit den Anforderungen (Garvin, 1984) (Malich, 2008). Mit Anforderungen ist in diesem Zusammenhang das Design beziehungsweise die Spezifikation des zu erstellenden Produktes gemeint (Garvin, 1984) (Malich, 2008). Eine Qualitütsminderung stellt somit jegliche Abweichung von diesen Vorgaben dar, selbst Nachbesserungen waren hier als Minderung zu verstehen (Garvin, 1984) (Malich, 2008). Der zentrale Fokus dieses Ansatzes liegt auf dem Herstellungsprozess und dass dieser ohne Probleme verläuft. Im weiteren Sinn umfasst er auch die Wünsche des Kunden, da diese ein qualitativ hochwertiges Produkt wünschen und sollte die Herstellung nicht von der Spezifikation abweichen, kann von einer hohen Qualität ausgegangen werden (Garvin, 1984) (Malich, 2008). Eine Nichtübereinstimmung wird als Defekt und somit als fehlende Qualitat betrachtet (Kan, 2003). Um Qualität nach diesem Ansatz zu gewahrleisten, versuchen Unternehmen schon fruhzeitig Fehler im Prozess zu finden und zu eliminieren, anstatt sie im Nachhinein auszubessern, was wiederum darauf abzielt Kosten zu minimieren (Garvin, 1984) (Malich, 2008). Ein Beispiel für diesen Ansatz wäre es wenn ein Hersteller eines Lautsprechers spezifiziert, dass der neue Lautsprecher mindestens 80 dB laut sein soll. Ist dieser nun nur 79 dB laut so ist dies eine Minderung der Qualität, da er nicht der Vorgabe entspricht. Das selbe gilt zum Beispiel fär Produkte von Apple. Apple hat an all seine Produkte wahrscheinlich bestimmte Vorgaben im Bezug auf die Verarbeitung, die Bedienfreundlichkeit, etc. Als Kaäufer von Apple Produkten geht man davon aus, dass die Produkte alle Vorgaben erfullen und somit Qualitätsprodukte darstellen. Grundsatzlich wirken sich alle Abweichungen von Vorgaben negativ auf die Qualität aus und es kann nicht mehr als Qualitaätsprodukt im Sinne dieses Ansatzes betrachtet werden. Fär jedes Produkt kännen hingegen eigene Vorgaben und Anforderungen gelten. So kännte man nun das Beispiel von Apple erweitern, sodass das gleiche Produkt auch von Microsoft nach deren Vorgaben gefertigt werden konnte, dieses Produkte wärde dann ebenso als Qualitätsprodukt gelten, obwohl diese zwei Firmen vermutlich sehr unterschiedliche Vorgaben fär die gleichen Produkte besitzen und dadurch auch Merkmale der Produkte ganz unterschiedlich ausgeprägt sein können. So kännte es fär Apple wichtig sein, dass ein neues Telefon mäglichst leicht und klein ist, wohingegen es fur Microsoft wichtig ist, dass es mäglichst viel Rechenleistung aufweist. In beiden Fallen wäre das jeweilige Produkt als Qualitätsprodukt zu betrachten.

Nach Kan (2003) ist dieser Ansatz sehr eng mit dem Kundenorientierten Ansatz verbunden, da der Kunden-orientierte Ansatz die Uä ber- einstimmung mit den Anforderungen misst und der Prozess-bezogene Ansatz die Uä bereinstimmung mit der Spezifikation. Die Spezifikation wird jedoch wiederum aus den Anforderungen des Kunden abgeleitet, darum ist sie sehr ähnlich, allerdings wird der Fokus unterschiedlich gesetzt (Kan, 2003). Dass diese beiden Ansatze jedoch auch in Konflikt stehen konnen zeigt Garvin (1984) anhand eines Beispiels einer japanischen Papierfabrik.

Diese hat zwar Papier produziert, welches vollkommen den Vorgaben des Industrie-Standards entsprach, jedoch die Kunden nicht zufriedenstellte (Garvin, 1984). Dadurch war zwar die Qualität des Prozesses ausgezeichnet, wohingegen die Qualitat im Bezug auf die Kundenzufriedenheit nicht äberwaltigend war.

Dieser Ansatz ist fär gewisse Bereiche des Benchmarkings sehr gut anwendbar, wenn man die Prozesse im Fokus haben sollte. Bei dieser Arbeit steht jedoch das Produkt im Zentrum, daher ist es fär dieses Anliegen nicht unbedingt passend.

Der auf den Wert bzw. auf Kosten und Nutzen bezogene Ansatz steht eng in Verbindung mit dem Prozess-bezogenen Ansatz (Garvin, 1984), jedoch stehen hier die Kosten und der Preis im Vordergrund (Garvin, 1984) (Malich, 2008). Qualitat misst sich alleine an diesen beiden Faktoren (Garvin, 1984) (Malich, 2008). Hohe Qualität entspricht demnach Leistung zu einem annehmbaren Preis oder die Erfällung der Vorgaben zu annehmbaren Kosten (Garvin, 1984) (Malich, 2008). Die Qualitat der Herstellung kännte nach dieser Art der Definition noch so hoch sein, solange der Preis auch zu hoch ist, ist die Qualitat nach diesem Ansatz niedrig. Zum besseren Verständnis betrachten wir ein Smartphone. Ein Unternehmen produziert ein Smartphone mit höchster Präzision und legt hohen Wert auf beste Materialien, die Produkt- und Fertigungsqualitat ist demnach hervorragend. Sollte dieses Smartphone allerdings für 10.000 Euro angeboten werden, hätte es nach diesem Ansatz eine sehr geringe Qualität, da sich bei diesem deutlich zu hohen Preis kaum Käufer finden wärden.

Auch dieser Ansatz ist fär den Fokus dieser Arbeit nicht geeignet, da er zu sehr auf die beiden Faktoren Preis und Kosten beschrankt ist.

Der auf Produkte bezogene Ansatz unterscheidet sich von allen anderen Ansätzen darin, dass er der einzige ist, welcher Qualität als messbare und präzise Variable sieht (Garvin, 1984) (Malich, 2008). Der Fokus liegt hier auf der Anzahl an Attributen bzw. Bestandteilen die ein Produkt aufweist (Garvin, 1984) (Malich, 2008). Je häher diese Anzahl ausfallt, desto häher ist auch die Qualitat des Produkts (Garvin, 1984). Diese Anzahl ist objektiv messbar und demnach sind Produkte der selben Sorte sortierbar (Garvin, 1984). Dies fährt jedoch auch dazu das hähere Qualität mit hoheren Kosten verbunden ist, da man mehr von einem gewissen Bestandteil produzieren muss (Garvin, 1984). Als Beispiele kann man einen Apfel und ein Navigationsgerät betrachten. Die Qualität eines Apfels kann sich zum Beispiel nach der Anzahl an Vitaminen richten, wohingegen sich die Qualität beim Navigationsgerät vielleicht nach der Genauigkeit der Positionsermittlung richtet. Nach Kan (2003) sind die beiden wichtigsten Messwerte die möglichst geringe Anzahl an Fehlern und die hohe Verlässlichkeit.

Fär die Qualität von Produkten findet man in der Literatur einige Charakteristiken, welche Produkte besitzen sollten, um eine hohe Qualitaät zu erlangen. Im Kern umfassen diese fär alle Produkte, egal welcher Warengruppe sie angehären, meist (Garvin, 1984) (Balzert, 1998-2001) (Kan, 2003) (Sanders und Curran, 1994):

- die Zuverlassigkeit,
- die Effizienz,
- die Funktionalität,
- und die Benutzbarkeit

In Abschnitt 2.3 werden diese Qualitatsmerkmale speziell für Softwareprodukte vorgestellt und durch speziell zutreffende Merkmale ergänzt.

Dieser Produkt bezogene Ansatz scheint fär diese Arbeit am Besten geeignet zu sein, da er messbare Kriterien ermoglicht. Dieser Umstand bietet die Mäglichkeit die Qualitat von Software anhand von bestimmten Kriterien bzw. Regeln zu äberpräfen. Diese Uberprufung wird mit Hilfe von statischer Code Analyse durchgefuhrt und durch das Benchmarking kann anschließend Auskunft daräber gegeben werden ob die gefundenen Werte, im Vergleich zu anderer Software, gut oder schlecht sind . Genau diese Vorgehensweise stellt den Kern der Arbeit da und wird noch genauer betrachtet und vorgestellt.

Die vorgestellten unterschiedlichen Ansatze besitzen natärlich Uberschneidungen und sind nicht klar abgrenzbar, doch bieten sie eine gute Mäoglichkeit der Zuordnung und Sortierung von Definitionen von Qualitat. Nach Garvin (1984) koännen die meisten der Definitionen in eine dieser Kategorien eingeordnet werden. Unterschiedliche Berufsgruppen und unterschiedliche Branchen legen den Fokus natärlich auf unterschiedliche Ansätze und definieren Qualitat fär sich selbst. Daher soll an dieser Stelle nochmals betont werden, dass es keine einheitliche Definition fär Qualität gibt, welche fur alle Situationen geeignet erscheint. Im nachsten Abschnitt wird nun versucht fär Software-Qualität eine geeignete Definition zu finden.

2.2 Metriken

Dieser Bereich der Arbeit soll als eine Hilfestellung verstanden werden, denn in den nachfolgenden Punkten ist stets die Rede von sogenannten Metriken. Dadurch erscheint es für das Verständnis essenziell, zuerst Metriken zu definieren und vorzustellen, bevor sie im Zusammenhang mit Software-Qualität, Benchmarks und dergleichen verwendet werden.

Der Begriff der Metrik kann, wie viele andere Begriffe auch, unterschiedlich definiert und verwendet werden. Das Spektrum der Definitionen reicht hier von strikten mathematischen, uber jene die im Zusammenhang mit Softwarequalitüt vorherrschend sind und erstreckt sich über eine Vielzahl von anderen Disziplinen. Nachdem diese Arbeit auf den Bereich der Soft- warequalitaüt ausgerichtet ist, wird auch diese Art der Definition an dieser Stelle als zentral angesehen und der Fokus auf sie gelegt.

Metrik bezeichnet eine genau definierte Methode, welche einem System eine Menge von Maßen zuordnet (Bähme und Freiling, 2008). Ein Maß ist ein quantitativer Wert eines Objekts und kann sowohl durch Zahlen als auch durch Symbole, Worte, etc. repräsentiert werden (Bähme und Freiling, 2008). Ein Beispiel für eine Menge von Maßen sind die natürlichen Zahlen oder eine festgelegt Menge an Klassifizierungen wie „gut“, „mittel“, „schlecht“. Diese Mengen von Maßen können teilweiße sortiert sein, müssen es aber nicht (Bohme und Freiling, 2008). Ein Maß, wird im Bezug auf ein Softwaresystem, meist einem Attribut dessen zugeordnet (Bühme und Freiling, 2008). So würde zum Beispiel die Metrik „Anzahl an Codezei- len“dem Softwaresystem als Maß (aus der Menge von natürlichen Zahlen) 9.000 Zeilen zuweißen.

Diese Metriken erlauben es nun gewisse Attribute von Softwaresystemen zu vergleichen. Die Findung einer passenden Metrik stellt sich jedoch teilweise als schwieriges Unterfangen heraus (Bohme und Freiling, 2008). Außerdem muss bedacht werden, dass jede Metrik immer nur einen Teil und niemals das gesamte System umfasst (Balzert, 1998-2001). Um Aussagen über ein System treffen zu künnen, müssen daher immer mehrere Metriken ausgewertet werden (Balzert, 1998-2001).

Metriken koünnen im Bezug auf unterschiedliche Eigenschaften, wie auf die Attribute die sie repräsentieren, die Art wie sie erstellt werden, die Granu- larität ihrer Messung oder ob es sich um eine direkte oder indirekte Metrik handelt, klassifiziert werden (Bähme und Freiling, 2008). Direkte Metriken beziehen sich auf das System selbst, wohingegen indirekte Metriken die Auswirkungen eines Systems auf ein anderes beschreiben (Bohme und Freiling, 2008) (Simon u. a., 2006). Metriken kännen auf zwei Arten erstellt werden, entweder durch die Analyse der Struktur oder einer Eigenschaft (analytical) oder durch Beobachtung des Verhaltens (empirical) (Bähme und Freiling, 2008).

Kan (2003) unterscheidet außerdem bei Metriken im Bezug auf Softwa- requalitat drei Kategorien. Die Produkt-Metriken, die Prozess-Metriken und die Projekt-Metriken (Kan, 2003). Die Produkt-Metriken sind Metriken welche die Attribute von Produkten umfassen, wie die Komplexität, Gräße, Anzahl der Codezeilen etc. (Kan, 2003) (Balzert, 1998-2001). Prozess-Metriken kännen für die Verbesserung der Software-Entwicklung und -Wartung verwendet werden und Projekt-Metriken beziehen sich auf Attribute von Projekten, wie Anzahl an Entwicklern, etc. (Kan, 2003). Manche Metriken koännen mehreren Kategorien zugeordnet werden (Kan, 2003), wie die Software Metrik, welche mit allen Dreien in Verbindung steht, jedoch den Fokus eher auf die Produkt- und Prozess-Metrik, als auf die Projekt-Metrik legt (Kan, 2003). Die Metrik fär Softwarequalität wird von Kan (2003) als Teil der Software Metrik verstanden, welcher sich auf die Qualitätsaspekte fokussiert.

Hoffmann identifiziert fär Software-Metriken sechs Gätekriterien die von einer Metrik erfällt sein sollten um sie gewinnbringend einsetzen zu können (Hoffmann, 2013):

- Objektivität Die Messung sollte weitgehend frei von subjektiven Einflässen sein.
- Robustheit Die Ergebnisse mässen bei wiederholten Messungen stets die gleichen sein.
- Vergleichbarkeit Messungen mit der selben Kenngröße mässen vergleichbar sein.
- (Ökonomie Die Erhebung einer Metrik soll mäglichst kostengunstig, wenn moglich automatisiert durchgefuährt werden koännen.
- Korrelation Die Korrelation einer Software-Metrik ist umso stärker, je besser man anhand einer Messung Räckschlässe auf die Kenngröße ziehen kann.
- Verwertbarkeit Metriken sollen nur erhoben werden, wenn diese auch verwendet werden. Unterschiedliche Ergebnisse sollten unterschiedliche Handlungen nach sich ziehen.

Nun nachdem ein Grundverstandnis äber Metriken geschaffen wurde wird im nächsten Abschnitt (2.3) die Qualität von Software naher betrachtet.

2.3 Regeln

Regeln bzw. Regelverletzungen bilden ein weiteres Maß, neben Metriken, um die Qualität von Software messen zu kännen. Im Gegensatz zu den Metriken wird bei den Regelverletzungen nicht ein gesamter Wert für den Quelltext ermittelt, sondern der Quelltext auf die Einhaltung von Regeln äberpräft und somit auf Probleme und Fehler hin untersucht (Harald Gruber, 2010) (Simon u. a., 2006). Zu diesem Zweck wird eine Menge von Regeln definiert, welche anschließend, manuell durch eine Person oder automatisiert, äberpräft werden. Eine Regeln stellt eine bestimmte Anforderung an die Software dar (Simon u. a., 2006). Regeln konnen äberdies hinaus metrikbasiert sein und somit gewisse Grenzen fär Werte von Metriken vorgeben (Simon u. a., 2006). Die Granularität von Regeln kann gänzlich unterschiedlich sein und von Regeln auf Codezeilen-Ebene bis zu Systemweiten Regeln reichen (Harald Gruber, 2010).

Das Ergebnis einer Regeläberpräfung sind einerseits die Anzahl an Verletzungen und andererseits die Stellen im Quelltext an denen die Verletzung begonnen wurde. Fär das Benchmarking selbst sind die genauen Stellen nicht von Bedeutung, die Anzahl hingegen ist ein wichtiger Wert.

Ein Vorteil der Verwendung von Regeln ist, dass sie leicht automatisiert oder aber auch von Personen ohne Expertenwissen durchgefährt werden kännen (Harald Gruber, 2010). Beispiele fär Regeln bzw. Regelverletzungen finden sich im Abschnitt 2.4. Regelverletzungen kännen auch in Form von Metriken auftreten, wie es zum Beispiel auch bei SonarQube der Fall ist (siehe Abschnitt 5).

2.4 Software-Qualität

Wie es zu Beginn im Abschnitt 2 besprochen wurde, ist Qualität eher als ein Konzept mit unterschiedlichen Interpretationsmöglichkeiten zu verstehen. Es wurden auch verschiedene Ansötze besprochen, um Definitionen von Qualitöt einordnen zu können. Der einzige Ansatz, der als passend angesehen werden kann, ist der Produkt bezogene Ansatz, welcher klar definiert, dass Produkte eine Ansammlung von Attributen und Bestandteilen sind und dass Qualitöt mit der Anzahl gewisser Attribute in Verbindung steht. Diese Anzahl kann ganz gezielt und genau gemessen werden und somit ist eine objektive Aussage über die Qualitöt eines Produktes möglich.

In diesem Abschnitt wird nun Software-Qualitöt im Speziellen erörtert und beschrieben was diese charakterisiert und ausmacht. Auch wird auf Qua- litötsmerkmale eingegangen und die am höufigsten verwendeten Charakteristiken von Qualitöt för Softwareprodukte vorgestellt. Dieses Wissen ist wichtig um zu verstehen, warum Benchmarking angewendet wird und welchen Zweck es verfolgt. Ziel ist es zu verstehen wie die Qualitöt zu bestimmen ist und nicht wie sie verbessert werden kann.

Die Qualitaöt von Software kann wie bereits erwöahnt aus zwei unterschiedlichen Blickwinkeln betrachtet werden. Einerseits ist es wichtig die Kundenzufriedenheit hoch zu halten und somit die Qualitat för den Kunden und andererseits die Produktqualitat hoch zu halten, was bedeutet, dass so wenige Fehler (Kan, 2003), im Englischen oftmals mit dem Wort „bug“bezeichnet (Kan, 2003), wie möglich auftreten sollten und auch andere Faktoren zu beröcksichtigen sind. Der Grad der Produktqualitöt wirkt sich auch auf die Kundenzufriedenheit und damit auf die wahrgenommene Qualitöt durch den Kunden aus. Eine hohe Zufriedenheit des Kunden wird, durch Erföllen der möglichst genauen Anforderungen an das Produkt, sichergestellt. (Juran und Godfrey, 1999) (Kan, 2003) (Sanders und Curran, 1994) (Garvin, 1984). Da Kundenzufriedenheit nur sehr schwer zu messen ist, ist eine der wenigen Möglichkeiten die Anwendung einer Umfrage direkt mit dem Kunden (Kan, 2003).

Bei der Produktqualitaöt sieht es anders aus, da diese wie bereits erwöahnt durch das Messen gewisser Attribute und Eigenschaften identifizierbar ist. Produktqualitöt kann nachfolgend mit Softwarequalitöt gleichgesetzt betrachtet werden, da der Fokus auf Software als Produkt gelegt wird. Demnach wird bei einem Produkt immer von einem Softwareprodukt gesprochen, außer es wird dezidiert erwöhnt.

Die einfachste und kürzeste der gefundenen Definitionen von Softwarequalität stammt von Balzert (Balzert, 1998-2001, S. 257) und lautet folgendermaßen:

Software-Qualitat ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfullen (nach (DIN ISO 9126, 1991))

Also ein bestimmtes Attribut eines Softwareprodukts muss bestimmte Werte besitzen oder in einer gewissen Anzahl vertreten sein. Dies steht wiederum mit dem Ansatz der Produktqualitaüt im Einklang, da von Merkmalen des Produktes, welche bestimmte Vorgaben erfüllen müssen, die Rede ist. Sollte dies nicht der Fall sein, so würde es sich wiederum negativ auf die Qualität auswirken. Darüber ob diese Merkmale quantifizierbar sind oder nur qualifizierbar wird nicht erwühnt, jedoch bezieht sich Balzert im weiteren Verlauf des Buches darauf, dass Qualitüts-Merkmale auch qualitativ sein künnen, diese aber aus einer benutzerorientierten Sicht zu sehen sind und in Kriterien verfeinert werden (Balzert, 1998-2001), welche anschließend quantitativ messbar sein sollen. Demnach gibt es auch hier Unterschiede wie man den Begriff Qualitüts-Merkmal spannen müchte. In dieser Arbeit ist die zentrale Sichtweise jene von Balzert, da sie auch in weiterer wichtiger Literatur dementsprechend gesehen wird.

Zentral in der Beurteilung von Softwarequalitüt scheinen die Merkmale bzw. die Qualitütsmerkmale der Software zu sein. Diese Qualitütsmerkmale waren schon oftmals Ziel von diversen Untersuchungen und es wurden einige zentrale Merkmale identifiziert. Nachfolgend werden nun einige dieser Merkmale gelistet. In der DIN ISO 9126 (DIN ISO 9126, 1991) wurden folgende 6 Merkmale identifiziert (Balzert, 1998-2001) (Sanders und Curran, 1994) (Dromey, 1995) (Malich, 2008) (Liggesmeyer, 2009) (Hoffmann, 2013) (Hofman, 2010) (Simon u. a., 2006):

- Funktionalitüt (Functionality)
- Zuverlüssigkeit (Reliability)
- Benutzbarkeit (Usability)
- Effizienz (Efficiency)
- Wartbarkeit bzw. Anderbarkeit (Maintainability) • Übertragbarkeit (Portability)

Diese 6 Merkmale werden oftmals in der Literatur angetroffen und sind meist in der einen oder anderen Form vertreten. Sie können jedoch nicht nur unter der Bezeichnung Qualitötsmerkmale auftauchen, teilweise werden sie auch als Qualitötscharakteristiken (Sanders und Curran, 1994) oder im englischen Sprachraum als factors”(Balzert, 1998-2001) bezeichnet. Im Folgenden werden diese zentralen Merkmale noch kurz beschrieben und um ihre Teilmerkmale erganzt.

Funktionalität Entsprechen die Funktionen den Anforderungen und er- föllen sie die expliziten und impliziten Wönsche (Sanders und Curran, 1994)

(Balzert, 1998-2001). Es wird unterteilt in

- Angemessenheit Ümfasst den Grad der Eignung von Funktionen fur die Durchföhrung der benötigten Aufgaben (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Richtigkeit Es werden die richtigen Ergebnisse geliefert bzw. die richtigen Wirkungen erzielt (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Interoperabilität Es ist möglich mit vorgegebenen Systemen zusammenzuarbeiten (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Ordnungsmäßigkeit Ümfasst den Grad der Einhaltung von anwendungsspezifische Normen, Vorschriften, Gesetzen und Standards (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Sicherheit Können nicht authorisierte Zugriffe auf Programme und Daten unterbunden werden, sowohl wenn der Zugriff unabsichtlich als auch gewollt geschehen ist (Balzert, 1998-2001) (Sanders und Curran, 1994).

Zuverlässigkeit Beschreibt die Föhigkeit der Software unter gewissen Bedingungen oder über einen gewissen Zeitraum hinweg die Leistungsfahig- keit aufrecht zu erhalten (Sanders und Curran, 1994) (Balzert, 1998-2001). Es wird unterteilt in

- Reife Beschreibt die Häufigkeit des Versagens der Software aufgrund von Fehlzuständen (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Toleranz von Fehlern Umfasst den Grad wie gut die Software ihre Leistungsfahigkeit beim Auftreten von Fehlzustanden oder einer falschen Benutzung der Schnittstellen aufrechterhalten kann (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Wiederherstellbarkeit Beschreibt die Fähigkeit nach einem Fehler verlorene Daten bzw. die Leistungsfähigkeit wiederherzustellen. Ausschlaggebend sind hierfär Zeit und Aufwand die benötigt werden (Balzert, 1998-2001) (Sanders und Curran, 1994).

Benutzbarkeit Umfasst die Menge von Attributen die beschreiben wie viel Aufwand eine bestimmte oder implizierte Person bzw. eine Gruppe von Personen benätigt um das System verwenden zu kännen (Sanders und Curran, 1994) (Balzert, 1998-2001). Es wird unterteilt in

- Verständlichkeit Attribute die beschreiben wie lange ein Benutzer benätigt um die Funktionen der Software und deren Konzept zu verstehen (Balzert, 19982001) (Sanders und Curran, 1994).
- Erlernbarkeit Umfasst den Aufwand der vom Benutzer betrieben werden muss um die Benutzung der Software zu erlernen (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Bedienbarkeit Umfasst den Aufwand der vom Benutzer betrieben werden muss um die Software zu bedienen (Balzert, 1998-2001) (Sanders und Curran, 1994).

Effizienz Umfasst die Menge von Attributen die beschreiben wie viel Aufwand eine bestimmte oder implizierte Person bzw. eine Gruppe von Personen benätigt um das System verwenden zu kännen (Sanders und Curran, 1994) (Balzert, 1998-2001). Es wird unterteilt in

- Zeitverhalten Umfasst wie lange die Software benotigt um auf Anfragen zu reagieren und diese zu verarbeiten und wie hoch der Durchsatz bei der Anwendung ihrer Funktionen ist (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Ressourcenverhalten Umfasst die Anzahl der verwendeten Ressourcen und die zeitliche Lange in der diese benötigt werden (Balzert, 1998-2001) (Sanders und Curran, 1994).

Änderbarkeit Umfasst die Menge von Attributen die beschreiben wie viel Aufwand es för bestimmte .Änderungen bedarf (Sanders und Curran, 1994) (Balzert, 1998-2001). Es wird unterteilt in

- Analysierbarkeit Umfasst den Aufwand der benötigt wird um die Software hinsichtlich entsprechender Fehler oder Ineffizienzen zu untersuchen oder Stellen zu finden die geöndert werden mössen (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Veränderlichkeit Umfasst den Aufwand der för eine Anderung, Fehlerbehebung oder Umgebungsönderung benötigt wird (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Stabilität Umfasst das Risiko, dass die Software nach einer .Anderung unerwartet reagiert (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Testbarkeit Umfasst den Aufwand die veränderte Software zu testen (Balzert, 19982001) (Sanders und Curran, 1994).

Übertragbarkeit Umfasst die Möglichkeit ein Software-System auf eine andere Umgebung zu öbertragen (Sanders und Curran, 1994) (Balzert, 1998-2001). Es wird unterteilt in

- Anpassungsfahigkeit Umfasst die Möglichkeiten die Software för verschiedene Umgebungen anzupassen ohne dabei andere ungeplante Aktionen und Schritte durchföhren zu mössen (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Installierbarkeit Umfasst den Aufwand um eine Software in einer bestimmten Umgebung zu installieren (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Konformität Umfasst den Grad, dem die Software im Bezug auf Normen, Standards und Konventionen betreffend der Ubertragbarkeit entspricht (Balzert, 1998-2001) (Sanders und Curran, 1994).
- Austauschbarkeit Umfasst die Möglichkeiten und den Aufwand die Software in der Umgebung einer bestimmten anderen Software zu betreiben (Balzert, 19982001) (Sanders und Curran, 1994). Manchmal wird sie auch als Kom- patibilitöt bezeichnet, dann wird jedoch dazu tendiert, sie mit Inter- operabilitat zu verwechseln (Sanders und Curran, 1994).

Kan (2003) listet noch weitere Merkmale in seiner Arbeit auf:

- Verfugbarkeit
- Installierbarkeit
- Dokumentation

Bei diesen zusatzlichen Attributen kommt es jedoch zu "Überschneidungen mit dem vorgestellten Merkmale. Kan sieht beispielsweise die Installierbarkeit als eigenes Merkmal obwohl sie bei der vorhergehenden Aufzahlung als Teil der Übertragung gelistet war. Die Verfögbarkeit wird zwar von Kan dezidiert gelistet, konnte jedoch auch als Teil der zuvor erwöhnten Zu- verlaössigkeit betrachtet werden. Das andere Merkmal, die Dokumentation, ist eher aus dem Standpunkt eines Kunden gesehen und beschreibt den Umfang der Dokumentation (Kan, 2003).

Die vorgestellten Teilmerkmale der Qualitötsmerkmale können auch als Kriterien bezeichnet werden (Balzert, 1998-2001). Diese definierten Kriterien sind eher softwareorientierte Charakteristiken und werden in Qua- litötsindikatoren bzw. Metriken verfeinert (Balzert, 1998-2001). Diese Indikatoren bilden sozusagen die Eigenschaften der Merkmale ab und bieten die Möglichkeit die Merkmale messbar und bewertbar zu machen (Balzert, 1998-2001). Diese Metriken werden bei der statischen Code Analyse (siehe Abschnitt 2.4) benötigt und in Abschnitt 2.1 nöher beschrieben.

Diese Art des Aufbaues in Qualitötsmerkmale, Teilmerkmale und Indikatoren ist auch als FCM-Qualitötsmodell bekannt, wobei FCM für factor- criteria-metrics steht (Balzert, 1998-2001). Abbildung 1 zeigt den kompletten Zusammenhang noch einmal grafisch dargestellt. Der Pfeil bedeutet wird bestimmt durch. Man sieht die Indikatoren bestimmen die Teilmerkmale, diese wiederum die Qualitätsmerkmale und diese schlussendlich die Qualität selbst. Unter dem Begriff der Indikatoren kännen jedoch nicht nur Metriken fallen, sondern auch, die in Abschnitt 2.2 kurz vorgestellten, Regelverletzungen. Diese Regeln kännen auch Teilmerkmalen zugeordnet werden. Des Weiteren erkennt man in dieser Grafik auch, dass gewisse Teilmerkmale mehrere Qualitatsmerkmale beeinflussen. Dies ist der Fall, weil die einzelnen Qualitätsmerkmale nicht zu 100 Prozent unterscheidbar sind und Überlappungen aufweisen. Das Gleiche gilt auch fur die Indikatoren, die natürlich mehrere Teilmerkmale betreffen kännen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Beispiel-Aufbau eines FCM-Qualitatsmodells (Balzert, 1998-2001, S. 257)

Es soll an dieser Stelle erwahnt werden, dass dieses Modell in der Literatur nicht ganz unumstritten ist. Da es aus einem internationalen Standard stammt ist es weit verbreitet und anerkannt, jedoch gibt es Einwäande gegen den Wirkungsgrad dieses Modells, wie ihn Dromey (1995) vorbringt. Doch diese Diskussion soll nicht Teil dieser Arbeit sein.

Natärlich gibt es in der Literatur noch weitere, teils ganz unterschiedliche Modelle zur Beschreibung von Qualität oder der Qualität eines Prozesses. Obwohl fär diese Arbeit das gerade beschriebene FCM Modell am interessantesten ist, sollen ein paar erwahnenswerte Modelle nachstehend angefährt werden. Die Beschreibung dieser Modelle kann im Rahmen dieser Arbeit nicht ins Detail gehen und es muss auf entsprechende Literatur verwiesen werden.

Zusätzlich zum FCM Modell verweist Balzert auf das Qualitätsmodell „FURPS“welches von Hewlett-Packard entwickelt wurde und zusatzlich zu Funktionalitat (Functionality), Benutzbarkeit (Usability) und Zuverlassig- keit (Reliability) noch umfasst (Balzert, 1998-2001). Diese Sicht ist sehr auf die Kunden ausgerichtet und mächte eine hohe Zufriedenheit erreichen (Balzert, 1998-2001). Auch wenn die Merkmale der Funktionalitäat und der Zuverlaässigkeit sehr deckungsgleich erscheinen, zeigen sich Unterschiede bei der Benutzbarkeit. Diese enthalt zum Beispiel die Dokumentation, die .Astethik und die Konsistenz, welche im FCM fehlen, und fasst die anderen Teilmerkmale als menschliche Faktoren (Human Factors) zusammen. Diese Teilmerkmale spiegeln wiederum deutlich die Ausrichtung auf Kunden wieder. Die vermeintlich zusätzlichen Merkmale, Leistung und UnterstUtzbarkeit sind bei genauerer Betrachtung auch sehr deckungsgleich mit dem FCM Modell, jedoch unterscheiden sich auch diese in gewissen Punkten.

- die Leistung (Performance)
- und die ,,Unterstätzbarkeit“(Supportability)

Die Leistung umfasst in diesem Zusammenhang die Teilmerkmale Geschwindigkeit (Speed), Effizienz (Efficiency), Ressourcenverbrauch (Resource consumption), Durchsatz (Thruput) und die Reaktionszeit (Response time) (Balzert, 1998-2001). Sie scheint großteils deckungsgleich mit dem Merkmal Effizienz des FCM Modells.

Die UnterstUtzbarkeit umfasst viele Teilmerkmale, welche auch im FCM Modell bei den Merkmalen Änderbarkeit und Übertragbarkeit zu finden sind. Zusaätzlich sind jedoch die Teilmerkmale Lokalisierbarkeit (Localizabi- lity) und die Erweiterbarkeit (Extensibility) im FURPS Modell enthalten.

[...]