Qualitätssicherung in der agilen Softwareentwicklung von Web-Applikationen

Inhaltsverzeichnis

1 | Einleitung

2 | Software-Qualität - Fluch oder Segen?
2.1 Qualitätssicherung als Führungsaufgabe (Top-Down)
2.2 Standards und Richtlinien für (Software-) Qualität
2.2.1 CMMI for Development (CMMI-DEV)
2.2.2 IEEE 610.12 (auch →IEEE 1219 und →ISO/IEC 14764)
2.2.3 ISO 9000/9001/9004
2.2.4 ISO/IEC 9126
2.2.5 ISO 9241
2.2.6 ISO/IEC 12207 (Teil der ISO/IEC 14764)
2.2.7 ISO/IEC 15504 (SPICE Norm)
2.2.8 ISO 20000
2.2.9 ISO/IEC 20926
2.2.10 →KVP/→PDCA/→KAIZEN
2.2.11 V-Modell des Bundes
2.3 Softwaremetriken
2.3.1 Lines of code, kurz LOC
2.3.2 Zyklomatische Komplexität von Thomas J. McCabe
2.3.3 Halstead Metriken
2.3.4 Wahl der Metrik(en)
2.4 Dashboards - Unterstützung des Managements
2.5 Release Management

3 | Testgetriebene Entwicklung
3.1 Software as a (Test-) Box
3.2 Testarten - Die Qual der Wahl?
3.2.1 Smoke-Tests (als Komponenten-Tests)
3.2.2 Regressionstests
3.2.3 Integrationstest und funktionaler Systemtest
3.2.4 Benutzbarkeitstest (Usability-Test)
3.2.5 Wiederherstellbarkeitstest (Recovery-Test)
3.2.6 Sicherheitstest (Security-Test)
3.2.7 Last- und Performanztest (Stresstest)
3.2.8 Akzeptanz- bzw. Abnahme-Test
3.3 Ermittlung von Testfällen
3.4 Tools zur Test-Unterstützung
3.4.1 HUDSON
3.4.2 BUGZILLA
3.5 Reviews

4 | Agiles Vorgehen mit modernen Websprachen
4.1 Semantik und HTML 5
Beispielhafter Vergleich von Semantik in HTML 4.01/XHTML 1.0 zu HTML 5
4.2 Agile Entwicklung
4.3 Methodik Scrum

5 | Ausgewählte Tools im Test
5.1 Szenario 1 - Oberflächen- und Link-Test
5.2 Umsetzung Szenario 1 mit Selenium 2 und JUnit 4
5.3 Szenario 2 - Performanz-Test
5.4 Umsetzung Szenario 2 mit JMeter 2.4
5.5 Potenzial und Grenzen der vorgestellten Tools

6 | Fazit

Abbildungsverzeichnis

Quellen und Literatur
Bücher
Zeitschriften
Internetseiten

Glossar (→)

1 | Einleitung

Noch vor einigen Jahren haben statische HTML-Seiten genügt, um Informationen zu präsentieren. Heute hat sich das World Wide Web (WWW) zu einem nicht mehr wegzudenkenden multimedialen Informationssystem entwickelt. Soziale Netzwerke wie Facebook oder Twitter und Videoportale wie YouTube sind allgegenwärtig. Jeder ist mit Hilfe einer Web-Anwendung mit seinen Freunden oder Kollegen vernetzt. Dieses moderne Medium ist nutzerorientiert und stellt ein interaktives Dokument dar.¹

Wenn man im Internet ein Produkt im Sinne von „ Software as a Service “ (kurz →SaaS) anbietet, kommt man um Maßnahmen zur kontinuierlichen Verbesserung und Sicherung der Software- Qualität nicht herum. Unternehmen in der Softwareentwicklung verwenden immer mehr agile Vorgehensmodelle wie beispielsweise →Scrum, um Prozesse und Projekte flexibel durchführen zu können. Immerhin über ein Drittel der Befragten IT-Professionals wählen eine agile Methode bei der Softwareentwicklung.²

In meinem Praktikum durfte ich solch einen Alltag in der agilen Softwareentwicklung miterleben. Die Flexibilität der Mitarbeiter in der Entwicklung war bemerkenswert, im Gegensatz zu der vermittelten Vorgehensweise im Projektmanagement. Doch ob die Qualität einer Software schlecht ist, merkt man oftmals erst wenn es bereits zu spät ist. Dann müssen die Entwickler im Nachhinein nachbessern, was einen hohen zeitlichen und finanziellen Aufwand nach sich zieht. Daher ist es wichtig, bei der Entwicklung den geschriebenen Code systematisch zu testen und ggf. zu optimieren.

Ein weiter Grund für die Wahl dieses Themas ist die immer schneller wachsende Datenmenge und die damit verbundene Komplexität, die es zu beherrschen geht. Insbesondere im Bereich eingebetteter Software gibt es einen stark wachsenden Forschungsbedarf, der durch den immer höheren Software-Anteil in solchen eingebetteten Systemen verursacht wird. Beispielsweise betrug 2003 die Datenmenge in PKWs mit gehobener Ausstattung ca. 70 MB, dieses Jahr überschreiten wir bereits die Gigabyte-Grenze.³

Der neue Web-Standard →HTML 5 wird lt. dem →W3C erst 2014 erhoben.⁴ Doch moderne Browser unterstützen bereits jetzt viele Features dieses Standards. Um gegenüber den Mitbewerbern eine möglichst hohe Effizienz zu erreichen, ist es notwendig sich an die erarbeiteten Qualitätsmaßnahmen zu halten und stetig zu verbessern um nachhaltig in der Branche erfolgreich zu sein.

Dieses Thema verbindet die Informatik mit wirtschaftlichen Faktoren, und stärkt somit die Brisanz der Wirtschaftsinformatik. In der Software-Entwicklung, gerade in der Cloud, müssen ökonomische Aspekte immer mehr beachtet werden, um nachhaltige Software zu entwickeln und damit die Marktposition zu sichern.

Zu Beginn werde ich auf den Begriff „ Qualität “ und in diesem Kontext verbreitete Standards und Richtlinien hinsichtlich der Entwicklung von Software eingehen und aufzeigen, wie sich Qualität unter Zuhilfenahme von Metriken messen lässt. Die Rolle des Release Managements werde ich ebenfalls dabei erläutern.

Im darauffolgenden Kapitel wird auf die Wichtigkeit von Testverfahren und deren Arten hingewiesen. Es werden Methoden, Werkzeuge und Hilfsmittel, die zur Qualitätssicherung beitragen, vorgestellt. Die Ermittlung von Testfällen und deren Automatisierung gehören ebenfalls in das Kapitel 3. Da Unternehmen ihre Software sehr detailliert spezifizieren müssen, wird nicht auf die Behebung von Fehlern eingegangen, sondern lediglich fiktive Lösungsvorschläge aufgezeigt bzw. genannt.

Welche Technologien zum Entwickeln von Web-Applikationen existieren und benötigt werden, wird im Kapitel 4 beschrieben, ebenfalls die praktische Anwendung mit dem zukünftigen Web- Standard HTML 5 und seinen kommenden Neuerungen. Des Weiteren setzt sich das Kapitel mit agilen Entwicklungsmethoden auseinander und Scrum wird dabei genauer betrachtet.

Im letzten Kapitel werden Tools vorgestellt, welche die qualitätsorientierte Entwicklung unterstützen können. Ein praktisches Anwendungsbeispiel mit den vorgestellten Test-Tools wird das Kapitel abrunden.

Ich verwende die Wörter „Software“, „Anwendung“ und „Applikation“ synonym für Webseiten mit entsprechend funktionellem Umfang. Eine Webseite erreicht einen solchen Umfang, wenn Besucher einen hinreichenden Nutzen mit dieser Seite erzielen können.

2 | Software-Qualitat - Fluch oder Segen?

Was ist gute und was ist schlechte Qualität? In erster Linie ist es persönliches Empfinden, welches durch die stetige Nutzung von Produkten geprägt wird. In der Textilindustrie beispielsweise kann der Verbraucher kaum wissen, ob das Kleidungsstück seiner Wahl, eine hohe Qualität aufweist oder nicht. Und der Preis ist nicht immer aussagekräftig über die Qualität eines Produktes.

Bei Software sind die Punkte Usability, also wie gut der Benutzer mit dem Programm zurechtkommt, und die Erwartungshaltung wichtige Kriterien zur Messung der Qualität. Es existiert sogar eine ISO-Norm (ISO 9241 - Softwareergonomie), die sich damit befasst. Dabei kann die Einschätzung eines erfahrenen Anwenders gegenüber einem Neuling, der selten einen Computer benutzt, sehr unterschiedlich sein. Deshalb ist es auch sehr schwierig Qualität zu beschreiben und zu messen. Man muss eine Vielzahl an Kriterien festlegen und definieren damit ein Produkt ein gewünschtes Ziel erreichen kann. Diese sollten individuell an jedes Produkt angeglichen werden und nur begrenzt statisch sein (z.B. max. 5% erkannte Fehler in den automatisierten Tests). Solche Anforderungen an ein Produkt legt der Auftraggeber, i.d.R. ist das das Unternehmen selbst, fest.

Laut der ISO Norm 8402 ist „ Qualität die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen. “⁵ Testfälle prüfen solche Erfordernisse mit Vor- und Nachbedingungen an einem Testobjekt (zu testende Komponente). Folglich sind die definierten Testfälle Indizien für die Qualität. Daraus lässt sich schließen, dass man je mehr erfolgreiche Tests man hat eine höhere Qualität zu erwarten ist.

Auch die Schnelligkeit einen Fehler zu finden ist ein wichtiges Kriterium der Qualität, nämlich der Code-Qualität. Kommentare, strukturierte Absätze und Dokumentationen sind die Regeln der guten Programmierung. Damit macht man es Mensch und Maschine einfacher, bestimmte Stellen im Quellcode zu finden, um die Nachvollziehbarkeit und Wartbarkeit von Code zu erhöhen.

Um die Qualität zu messen werden Tests benötigt, sowie Techniken und Verfahren, um diese zu ermitteln. Softwarefehler sind teuer und sollten nicht wiederholt vorkommen. Eine Abteilung, die für die Überwachung und Sicherung der Softwarequalität zuständig ist, ist essentiell für die Unterstützung der Programmierer hinsichtlich der Code-Qualität. Die Qualitätsbeauftragten, sogenannte Test-Analysten, sollen jedoch nicht die Arbeit der Entwickler abnehmen, sondern auf mögliche Risiken, Schwachstellen und Optimierungsmöglichkeiten hinweisen. Sie sind vergleichbar mit Beratern für eine Abteilung und stellen die Schatten in der Aufbauorganisation dar. Denn leider wird häufig die Software-Qualität aus wirtschaftlicher Sicht nur prosaisch beurteilt. Daher sollten die Analysten weder weisungsbefugt noch Weisungen der Abteilung entgegennehmen. Um Voreingenommenheit zu verhindern bietet es sich ebenfalls an, in einem unbekannten Team zu unterstützen. Dies muss jedoch zwingend kommuniziert werden um Spannungen präventiv entgegenzuwirken.⁶ Um Qualitätsziele zu erreichen, ist es erforderlich eine ökonomische Balance zwischen Aufwand und Nutzen zu finden, denn es wird immer Fehler und Optimierungsbedarf geben.

Bei der Einführung eines Qualitätsmanagements wird in der bestehenden Software analytisch nach Fehlern gesucht. Diese Erfahrungen und Ursachen werden festgehalten und dokumentiert und bei der zukünftigen Entwicklung berücksichtigt, um diese Fehler nicht noch einmal hervorzurufen. Diese Prozesse müssen organisiert und nachhaltig angewendet werden.⁷ Bei der Durchführung der Qualitätssicherung ist daher eine einheitliche und abgestimmte Vorgehensweise von allen Beteiligten notwendig. Wenn man konstruktiv, also vorausschauend Maßnahmen ergreift, spart man sich unnötig entstehende Fehler und den analytischen Aufwand für deren Behebung. Dazu müssen konkrete Qualitätsaspekte wie Flexibilität, Bedienbarkeit und Effizienz benannt und gefördert werden. Dies kann allein schon mit der Wahl einer Architektur (z.B. MVC mit dem Qualitätsaspekt der Wartbarkeit des Codes) geschehen. Die nachfolgende Abbildung 1 zeigt, dass die notwendigen Maßnahmen zur Qualitätssicherung für die Erhaltung der geforderten Software-Qualität sorgen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 - Maßnahmen zur Erhaltung der Softwarequalität

2.1 Qualitätssicherung als Führungsaufgabe (Top-Down)

Es nützt nicht viel wenn ein paar Mitarbeiter qualitätsbewusst denken und handeln, wenn diese Ideen regelmäßig durch Entscheidungen von Vorgesetzten zunichte gemacht werden. Vielmehr müssen Führungskräfte und das Unternehmen selbst Qualitätsrichtlinien vorgeben und nachhaltig durchsetzen. Wenn das Management Wert auf Qualität setzt, Kundenorientierung im Mittelpunkt steht und die Mitarbeiter in die Gestaltung der Geschäftsprozesse einbezogen werden, kann Qualitätsmanagement nachhaltig im Unternehmen etabliert werden und ist zugleich ein großer Schritt in Richtung Total-Quality-Management.

2.2 Standards und Richtlinien für (Software-) Qualität

Es existieren zahlreiche Normen und Standards die helfen können unternehmensspezifische Qualitätsrichtlinien herzuleiten. Sie sind nützliche Hilfen bei der Klärung von Begriffen und deren Charakteristik. Folgende sind wesentliche Quellen in der Welt der Softwareentwicklung und dessen Qualitätsrichtlinien:

2.2.1 CMMI for Development (CMMI-DEV)

Das →CMMI ähnelt der →SPICE-Norm und ist ebenfalls ein Reifegradmodell sowie Sammlungen von Best-Practices für die Verbesserung von Prozessen zur Entwicklung von Produkten und Dienstleistungen. Sie sind jedoch detaillierter und besitzen ein Stufenkonzept womit sich Unternehmen und Organisationen einordnen lassen können.

2.2.2 IEEE 610.12 (auch →IEEE 1219 und →ISO/IEC 14764)

In diesem über 20 Jahre alten SE-Standard werden Begriffe wie Metrik und Komplexität beschrieben. Es geht um die Entwicklung von Software und deren Wartung, denn diese hat im Gegensatz zur Hardware keine Verschleißerscheinungen. Aber sie hat in der Regel immer Fehler die zu finden und zu beheben sind.

Die Wartung einer Software ist die Modifikation einer oder mehrerer Komponenten dieser, nach dessen Auslieferung. Man unterscheidet zwischen adaptiver (Anpassung an die Systemumgebung), korrektiver (Bug-Fixing), perfektionierender (Optimierung der Eigenschaften), präventiver (latente Fehler finden, bevor sie zu effektiven Fehlern werden) und funktionaler Wartung. Wird die Software mit Fehlern ausgeliefert, wird eine korrigierende Wartung durchgeführt.

2.2.3 ISO 9000/9001/9004

Mit der Normenreihe ISO 9000 ff. sind Normen geschaffen worden, die die Grundsätze für Maßnahmen zum Qualitätsmanagement dokumentieren. Es sind allgemein gehaltene Regelwerke, u. a. für die Einhaltung von Qualitätsrichtlinien. Viele Unternehmen lassen sich daher zertifizieren, um ihren Kunden gegenüber das Qualitätsbewusstsein nachweisen zu können.

2.2.4 ISO/IEC 9126

In dieser Norm werden u. a. die Softwarequalität und die Qualitätsmerkmale (→FURPS) definiert welche jedoch an die zu testende Software speziell angepasst werden müssen. Die Prozesse werden in der ISO/IEC 15288 behandelt.

2.2.5 ISO 9241

Die Aspekte der Benutzerfreundlichkeit werden in dieser Norm ausführlich behandelt. Sie besteht aus über 30 Kapiteln und befasst sich in einigen (11-17; 110) mit der Softwareergonomie (Usability), also der Interaktion mit dem Nutzer. Darüber hinaus wird u. a. die Verwendung von Formularen und Dialogfeldern erläutert. Die Kernziele der ISO-Norm sind daher die Effektivität, Effizienz sowie die Zufriedenheit des Anwenders.

2.2.6 ISO/IEC 12207 (Teil der ISO/IEC 14764)

Diese Norm beschreibt neben der Softwarewartung auch die Prozesse im Lebenszyklus von Individual-Software. Prozessarten sind Primär-, unterstützende und organisatorische Prozesse.

2.2.7 ISO/IEC 15504 (SPICE Norm)

Zur Durchführung der Bewertungen (Assessments) von Software- und Systementwicklungsprozessen in Unternehmen setzt diese Norm mit Schwerpunkt auf der Softwareentwicklung an. Es wird also ein Prozessmodell für die Softwareentwicklung abgeleitet (aus der ISO/IEC 12207). Die SPICE-Initiatoren wollten sich vom CMM(I) absetzen und entwickelten eine Norm, die international anerkannt wurde.

2.2.8 ISO 20000

Aus →ITIL (V2) entstand die britische Norm BS15000 welche 2004 wegen der hohen internationalen Resonanz zur ISO-Norm umgeschrieben wurde. Eine Zertifizierung nach dieser Norm beweist die Fähigkeit zur richtigen Umsetzung von Qualitätsrichtlinien mit wirtschaftlichem Kostendenken. Nicht umsonst wird dieser Standard als „… ein wesentlicher Treiber der Industrialisierung der IT. “⁸ betrachtet. Hierbei wird die Orientierung am Kunden propagiert, welcher die Anforderungen an Kosten und Qualität klar abgrenzen sollte und in →SLA´s festlegen muss. Bei internen Kunden wie die firmeneigene Entwicklungsabteilung sind solche Vereinbarungen beispielsweise in Protokollen festzuhalten. Laut dem →ITSMF sind mit Stand 01.07.2009 nur 27 deutsche Unternehmen von weltweit 421 zertifiziert. Diese Zahl wird voraussichtlich in nächster Zeit stark zunehmen, weil immer mehr Kunden einen Beleg für Mindestanforderungen, in Hinsicht auf Qualitätsorientierung, fordern.⁹

2.2.9 ISO/IEC 20926

Der Ursprung dieser Norm war die Entwicklung eines Verfahrens zur Aufwandsschätzung von Software-Projekten für das Unternehmen IBM. Um Software zu bewerten, werden „Function Points“ verwendet. Dieses Verfahren ist ein weiteres Größenmaß für Geschäftsanwendungen und für Spezifikationen gedacht. Es existieren unterschiedliche Varianten z. B. für Web- Anwendungen „ Web object points “. Es wurde von der →IFPUG entwickelt und 2003 als Standard von der ISO anerkannt, 2009 kam es zu einer Aktualisierung in Form der →CPM.

2.2.10 →KVP/→PDCA/→KAIZEN

Diese Begriffe geben die Inhalte des Total Quality Managements wieder und besagen, dass sich alle Prozesse eines Unternehmens ständig verbessern sollen. Diese Unternehmenskultur soll für nachhaltiges Wirtschaften sorgen unter Einbeziehung von Mitarbeitern und Kunden.

2.2.11 V-Modell des Bundes

Das V-Modell XT ist ein Vorgehensmodell zur Planung und Durchführung von Projekten. Aber auch bei der Entwicklung hilft es Software und Systeme mit den Anforderungen, Schnittstellen und Abläufe besser zu organisieren. Es geht um die Betrachtung des gesamten System- Lebenszyklus bereits während der Entwicklung und der Verbesserung und Gewährleistung der Qualität.

2.3 Softwaremetriken

Grundsätzlich gesehen ist eine Softwaremetrik eine Funktion, die einen Teil einer Software in einen Zahlenwert abbilden kann. Dieser berechnete Wert ist nach dem IEEE Standard 1061 von 1992 interpretierbar als der Erfüllungsgrad einer Qualitätseigenschaft dieser Software-Einheit.¹⁰ Derzeit existiert noch kein einheitlicher Standard für ein Software-Maßsystem, sondern lediglich ein IEEE-Standard (IEEE 93) für die Vorgehensweise bei der Definition von SoftwareMaßen.¹¹ Dieser baut sich folgendermaßen auf:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 - Vorgehensweise bei einer Maßdefinition nach IEEE 93

Der sinnvolle Einsatz einer Softwaremetrik soll einen spürbaren und für den Kunden nachweislichen Erfolg nach sich ziehen, daher ist es wichtig die folgenden Gütekriterien zu erfüllen:¹²

Korrelation/Validität:

Eine starke Korrelation zeichnet sich dadurch aus, dass die Messergebnisse einen fundierten Rückschluss auf die Kenngröße geben

Objektivität:

subjektive Einflüsse sollten mit Hilfe der IT-Unterstützung vermieden werden

Ökonomie:

Die Kosten sollten minimal gehalten werden und deswegen durch entsprechende Tools die Messungen automatisiert werden

Robustheit/Zuverlässigkeit:

Bei wiederholter Messung muss das gleiche Ergebnis geliefert werden

Vergleichbarkeit:

Gleiche Kenngrößen müssen auch bei unterschiedlichen Messungen verglichen werden können (Relation)

Verwertbarkeit:

Die erzielten Messergebnisse müssen einen praktischen Nutzen erfüllen

In der Praxis werden die nachfolgend Vorgestellten Verfahren angewendet, da sie einfach zu verstehen und umzusetzen sind.

2.3.1 Lines of code, kurz LOC

Bei diesem einfachen und häufig verwendeten Verfahren wird der Umfang der Software (Größenmaß für Quellcode) bestimmt. Dazu müssen nur die Regeln zur Messung festgelegt werden. Diese Regeln bestimmen, was alles gezählt werden soll, nur Programmzeilen (→ELOC bzw. →NCSS) oder auch Kommentare oder Leerzeilen. Nachteil ist, dass es sprachabhängig ist, d.h. die gemessene Codelänge von der Programmiersprache abhängt. Es wird zwar zu den Metriken gezählt, sollte jedoch nicht als Maß für Komplexität verwendet werden.

2.3.2 Zyklomatische Komplexität von Thomas J. McCabe

Dieses Verfahren gehört zur Gruppe der Strukturmetriken und ist klar definiert. Daher ist auch keine Abweichung möglich. Es kann mit jeder strukturierten Programmiersprache angewendet werden. Eine Rationalskala von eins bis unendlich stellt den Grad der Komplexität des Programmcodes dar, welche hierbei im Fokus steht. Es werden alle Verzweigungen, Schleifen und deren Zweige gemessen bzw. addiert. Eine weitere Addition von 1, soll einen Nullwert z.B. bei einem sehr kleinen oder noch leeren Programm verhindern. Daran kann man bereits erahnen, dass selbst ein scheinbar simples Programm eine höhere Code-Komplexität aufweist, als ein umfangreiches Programm, welches kaum Verzweigungen hat. Eine subjektive Bewertung des Programmes wäre also unangebracht. Je höher der Wert wird, desto schwieriger werden die Testbarkeit und somit auch die Fehleranfälligkeit. Die Berechnung erfolgt aus dem Kontrollflußgraphen des Programmes und ist mit der nachfolgenden Formel zu berechnen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 - Formel der Code-Komplexität nach McCabe

Mehrere Studien haben gezeigt, dass mit einem MCC-Wert über 11, der Grad der Wahrscheinlichkeit von eintretenden Fehlern stark steigt.

Das folgende triviale Beispiel soll zeigen dass nur durch das Ändern der Kontrollstruktur die Komplexität von 4 auf 1 Pfaden gekürzt werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 - Überprüfung mit 4 Pfaden

Die Validierung ob ein Jahr ein Schaltjahr ist, muss innerhalb von 3 Prüfungen durchgeführt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 - Überprüfung mit einem Pfad

Dieselbe Prüfung kann auch in einem Pfad vollzogen werden, wodurch zwar die Komplexität vermindert wird, jedoch die Übersichtlichkeit leidet.

2.3.3 Halstead Metriken

Ein System aus textuellen Metriken zur Messung der Komplexität, des Umfanges und des Aufwandes sind die Metriken von M. H. Halstead. Grundlage dieser Metriken sind das Finden und somit Einsparen von Operatoren (z.B. Bezeichner für Methoden) und Operanden (z.B. Parameter). Dieses Verfahren gehört wie die LOC-Metrik zur Gruppe der Größenmetriken. Es ist einfach zu ermitteln und zu berechnen und für alle Programmiersprachen nutzbar. Die Programmlänge wird durch die Anzahl der Operatoren und Operanden ermittelt. Die Praxis zeigt, dass Halstead-Metriken gute empirische Komplexitäts-Maße sind. Die Durchführung einer solchen Messung könnte folgendermaßen aussehen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 - Java-Methode zur Berechnung des ggT

In diesem Programmteil existieren 20 Operatoren (n1) und davon sind 12 unterschiedlich (n2). Operanden (m1) sind 16 vorhanden, wovon 4 unterschiedlich (m2) sind. Daraus ergibt sich die Programmlänge (N) aus n1 + m1 = 36.¹³ Für das Vokabular (voc) werden die unterschiedlichen Werte addiert (n2 + m2), was in diesem Beispiel 16 ergibt. Eine weitere wichtige Berechnung ist die des Volumens (V), also der Umfang des Programms. Diese wird wie folgt ermittelt: [Abbildung in dieser Leseprobe nicht enthalten] Somit: ist V in diesem Beispiel 144. Dieser Wert ist für den Vergleich anderer Programmteile vorgesehen. Laut [wwwVSHM] sollte er mindestens 20 und höchstens 1.000 betragen. Falls das Volumen 1.000 übersteigt, ist die Funktion wahrscheinlich zu komplex.¹⁴

Auf die anderen Größen von Halstead, wie die Schwierigkeit des Verstehens (difficulty) oder der Aufwand (effort) das gesamte Programm zu verstehen, wird hierbei verzichtet.

2.3.4 Wahl der Metrik(en)

Für die Wahl der Metriken zur Anwendung in Unternehmen, lässt sich keine pauschale Empfehlung aussprechen. Die Qualität, die man erreichen möchte, ist das Ziel, welches den Einsatz der Metriken bestimmt. Das gleiche besagt auch das →GQM-Modell, welches bei der Entscheidungsfindung unterstützt und benötigte Qualitätskriterien identifizieren kann.

Qualität und Kosten bei der Entwicklung und Wartung von Programmen hängen entscheidend von der Code-Komplexität ab. Deshalb sollte, um vereinfachte Software-Tests und Wartungen durchzuführen, die Komplexität so gering wie möglich, aber so hoch wie notwendig sein.

Wendet man alle hier genannten Metriken an, kann man daraus den von Hewlett Packard entwickelten Wartungs-Index herleiten, der besagt, wie schwer ein Programm zu warten ist.¹⁵

Abbildung in dieser Leseprobe nicht enthalten

Wenn der ermittelte Wert kleiner als 65 ist, spricht man von einer schwierigen Wartung.¹⁶

2.4 Dashboards - Unterstützung des Managements

Das Management fordert immer schnellere und einfachere Übersichten zur Entscheidungsfindung. Dazu werden Kennzahlen benötigt, wie Leistungsindikatoren (Key Performance Indicator, kurz KPI), die auf kleinem Raum viele und aussagekräftige Informationen abbilden, die das Management dahingehend unterstützen. Diese Form der Darstellung nennt man Dashboards, diese können große Datenmengen aus verteilten Systemen aufbereiten und in Echtzeit in verdichteter Form darstellen. Sie dienen dem Verlauf von Messwerten und somit auch der nachhaltigen Analyse für das Management.

[...]

¹ Vgl. [MW] Seite 28/29

² [wwwFDGDTS]

³ Vgl. [MSBdSE] Seite 9 des Manifests

⁴ [wwwW3CH5]

⁵ ISO 8402

⁶ diese können entstehen, wenn man einen unbekannten, objektiv handelnden Mitarbeiter einem bereits bekannten, evtl. subjektive betrachtenden Mitarbeiter vorzieht

⁷ vgl. [ASQ] Seite 5

⁸ [WI0609] Seite 533

⁹ Vgl. [WI0609]

¹⁰ Vgl. [ASQ] Seite 54

¹¹ Vgl. [SE] Seite 148

¹² Vgl. [SQ] Seite 247 ff.

¹³ McCabe verwendet für die Gesamtzahl N1 bzw. N2 und für unterschiedliche Operatoren/Operanden n1 bzw. n2

¹⁴ [wwwVSHM]

¹⁵ Vgl. [SETaP] Seite 559

¹⁶ Vgl. [wwwHPMI]