Fakultät für Wirtschaftswissenschaften

Transkript

1 Hochschule Wismar Fakultät für Wirtschaftswissenschaften Softwarequalität und Softwarealterung eingereicht von: Dozent: Anne Moormann, geboren in Ankum Benedikt Scholz, geboren in Hamburg Michael Herbener, geboren in Wolfenbüttel Studiengang Wirtschaftsinformatik Prof. Dr. J. Cleve

2 Inhalt I. ABBILDUNGSVERZEICHNIS... III 1 EINLEITUNG ZIELSETZUNG VORGEHEN SOFTWAREQUALITÄT DEFINITION SOFTWAREQUALITÄT EXTERNE QUALITÄTSFAKTOREN Funktionalität Effizienz Benutzbarkeit Zuverlässigkeit INTERNE QUALITÄTSFAKTOREN Transparenz Übertragbarkeit Wartbarkeit Testbarkeit QUALITÄTSMANAGEMENT / QUALITÄTSSICHERUNG Qualitätsplanung Qualitätssteuerung Qualitätssicherung Qualitätsverbesserung SOFTWAREALTERUNG DEFINITION SOFTWAREALTERUNG GRÜNDE FÜR SOFTWAREALTERUNG Fehlerbehebung Funktionelle Software-Erweiterung Personalwechsel Abwärtskompatibilität Nachträgliche Portierung Externe Einflüsse ERKENNUNGSMERKMALE ALTERNDER SOFTWARE Unterstützung beim Erkennen der Alterung HERLEITUNGSKETTE DER SOFTWAREALTERUNG MAßNAHMEN GEGEN SOFTWAREALTERUNG REFACTORING Methoden zusammenstellen Eigenschaften zwischen Objekten verschieben Daten organisieren I

3 4.1.4 Bedingte Ausdrücke vereinfachen Methodenaufrufe vereinfachen Umgang mit Generalisierung Refactoring am Beispiel REDESIGN EINSATZ EINES QUALITÄTSMANAGEMENTS FAZIT LITERATURVERZEICHNIS ANLAGENVERZEICHNIS... IV EHRENWÖRTLICHE ERKLÄRUNG II

4 I. Abbildungsverzeichnis ABBILDUNG 1: WHITE-BOX- UND BLACK-BOX-TEST ABBILDUNG 2: ZYKLOMATISCHE KOMPLEXITÄT ABBILDUNG 3: URSACHE-WIRKUNGS-ZUSAMMENHANG DER SOFTWAREALTERUNG ABBILDUNG 4: CODEBEISPIEL RECHNER ABBILDUNG 5: CODEBEISPIEL NACH REFACTORINGMAßNAHMEN ABBILDUNG 6: EINFLUSS DER QUALITÄTSSICHERUNG AUF DIE QUALITÄTSMERKMALE III

5 1 Einleitung 1.1 Zielsetzung Die Projektarbeit Softwarequalität und Softwarealterung wird im Modul Formale Methoden im dritten Semester des Masterstudiengangs Wirtschaftsinformatik an der Hochschule Wismar erstellt. Grundlage für das Modul ist das Buch Software-Qualität von Dirk W. Hoffmann. Die Projektarbeit orientiert sich maßgeblich am siebten Kapitel Software-Lebenszyklus dieses Buches. Ziel dieser Arbeit ist es, Softwarequalität und das Phänomen der Softwarealterung von allen Seiten zu beleuchten und Möglichkeiten aufzuzeigen, der Softwarealterung entgegen zu wirken. 1.2 Vorgehen Nach der Einleitung enthält die Arbeit eine Einführung in den Bereich der Softwarequalität. Dabei wird auf den Begriff der Softwarequalität im Allgemeinen und auf die einzelnen Kriterien im Speziellen eingegangen. Anschließend werden die einzelnen Qualitätsmerkmale getrennt nach internen und externen Gesichtspunkten betrachtet. Da zur Einhaltung und Überprüfung der einzelnen Kriterien das Qualitätsmanagement eine entscheidende Rolle spielt, enthält das zweite Kapitel auch einen Ausblick in den Bereich des Qualitätsmanagements. Anschließend an die Softwarequalität wird im dritten Kapitel das Thema der Softwarealterung beleuchtet. Analog des vorigen Kapitels erfolgt hier zunächst eine Definition für den Begriff der Softwarealterung, um anschließend auf die verschiedenen Gründe für das Altern von Software eingehen zu können. Weiterhin werden Erkennungsmerkmale alternder Software aufgezeigt und wie die Erkennung unterstützt werden kann. Am Ende des Kapitels werden noch einmal die Wirkzusammenhänge bei der Alterung zusammengefasst. Nachdem ein Verständnis der Begriffe Softwarequalität und Softwarealterung in den vorherigen Kapiteln erarbeitet worden ist, folgt im vierten Kapitel die Be- 1

6 handlung von Maßnahmen gegen die Softwarealterung. Es werden in diesem Kapitel Möglichkeiten erläutert, auf welche Weise die Softwarealterung verlangsamt werden kann. Damit einhergehend wird die Verzögerung der Qualitätsminderung aufgezeigt. Diese Maßnahmen haben sowohl vorbeugenden als auch behebenden Charakter. Es wird zudem aufgezeigt, dass die Softwarealterung permanent im Entwicklungsprozess betrachtet werden muss, unabhängig vom realen Alter einer Software. Das abschließende Fazit fasst noch einmal die Erkenntnisse dieser Arbeit zusammen und hebt die wichtigsten Punkte hervor. 2

7 2 Softwarequalität 2.1 Definition Softwarequalität Um den Begriff Softwarequalität zu erläutern, wird er zunächst in seine beiden Teilbegriffe Software und Qualität zerlegt. Für diese Arbeit genügt es, Software als ein auf einem Computer lauffähiges Programm mit beliebiger Komplexität zu definieren. Qualität ist ein Begriff, der vom lateinischen Wort qualitas abstammt. Übersetzt werden kann qualitas mit Beschaffenheit. 1 Es zeigt sich, dass Qualität auf die Beschaffenheit bzw. Eigenschaft einer Sache abzielt. Im umgangssprachlichen Gebrauch wird mit dem Wort Qualität häufig eine positive Wertung assoziiert. Diese Annahme, dass Qualität gleichzeitig etwas Gutes ist, ist streng genommen nicht korrekt. Vielmehr ist der Begriff Qualität wertungsfrei. Die Norm DIN EN ISO 9000 beschreibt Qualität als Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen 2. Diese Norm zeigt eine grundsätzliche Problemstellung auf, die bei der Qualitätsbeurteilung in Erscheinung tritt. Für die Beurteilung der Qualität müssen verschiedene Eigenschaften insgesamt betrachtet werden. So ist zum Beispiel ein Fernseher nicht pauschal gut oder schlecht. Er kann einen geringen und damit guten Stromverbrauch haben aber eine langsame und somit schlechte Reaktionszeit bei Befehlen besitzen. Ebenso gilt es, bei Software verschiedenste Eigenschaften zur Qualitätsbewertung zu betrachten. Dies besagt auch die DIN EN ISO 9126, welche die Softwarequalität folgender Maßen definiert: Softwarequalität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen. 3 Bei diesen Merkmalen handelt es sich um Transparenz, Wartbarkeit, Testbarkeit, Portabilität, Benutzerfreundlichkeit, Effizienz, Funktio- 1 Vgl. (Paul Hemetsberger IT-Dienstleistungen). 2 (Vigenschow, 2010), S Vgl. (Hoffmann, 2008), S. 6. 3

8 nalität und Zuverlässigkeit. Eine genauere Erörterung dieser Qualitätskriterien erfolgt in den Kapiteln 2.2 und Um zu einem Gesamteindruck der Softwarequalität zu gelangen und sie zu beurteilen, bedarf es einer genaueren Betrachtung der oben genannten Qualitätsmerkmale von Software. Eine Möglichkeit, diesen Gesamtendruck zu erhalten, ist die Software in einer Nutzwertanalyse zu bewerten. Dort werden verschiedene Kriterien miteinander verglichen und durch Bewertung und Gewichtung der Kriterien eine Gesamtbeurteilung gebildet. Bei der Durchführung einer Nutzwertanalyse für Software können zur Bewertung alle oder eine Auswahl der genannten Qualitätsmerkmale herangezogen werden Externe Qualitätsfaktoren Unter externen Qualitätsfaktoren werden alle Qualitätsmerkmale verstanden, die direkt oder indirekt durch Kunden beurteilt werden können. Aus diesem Grund werden sie auch kundenorientierte Qualitätsfaktoren genannt. Dabei spielen alle Artefakte eine Rolle, die während der Laufzeit einer Software ermittelt werden können. Diese sind die Funktionalität, die Zuverlässigkeit, die Benutzbarkeit und die Effizienz. Da diese vier Merkmale durch den Anwender bewertet werden können, spielen sie eine direkte Rolle bei der Kaufentscheidung, bilden jedoch keine ganzheitliche Sicht auf die Qualität einer Software Funktionalität Die Funktionalität ist für den Kunden, der ein Produkt erwirbt, eines der wichtigsten Qualitätsmerkmale. Denn die Funktionalität beschreibt, in welchem Ma- 4 Vgl. (Hoffmann, 2008), S Vgl. (Klempien, 2009). 6 Vgl. (Hoffmann 2008) S. 9f. 4

9 ße ein Softwaresystem die erwarteten Funktionen bereitstellt. 7 Implizite Anforderungen, also Selbstverständlichkeiten wie beispielsweise eine Rechnungserstellung, die frei von Rechtschreibfehlern ist, sind ebenfalls im Merkmal Funktionalität enthalten, ohne in den Anforderungen explizit genannt werden zu müssen. 8 Grundsätzlich lässt sich die Qualität einer Software in Bezug auf das Merkmal Funktionalität daran bewerten, ob die Software die an sie gestellten funktionalen Anforderungen erfüllt. Eine genauere Bewertung lässt sich vornehmen, indem das Gesamtkriterium Funktionalität weiter aufgegliedert wird. In dieser Aufgliederung lassen sich fünf Unterkriterien bestimmen. Diese sind Angemessenheit, Genauigkeit bzw. Richtigkeit, Interoperabilität, Sicherheit und Konformität der Funktionalität. 9, 10 Unter dem Begriff der Angemessenheit sind die vom System bereitgestellten Funktionen zusammengefasst. Dabei ist die Fragestellung, ob das System nur die Funktionen bereitstellt, die auch aus den Anforderungen stammen, zu beantworten. Sind zusätzliche Funktionen enthalten, ist dies für den Nutzer nicht unbedingt von Nachteil. Diese Funktionalitäten bewirken jedoch, dass der Code-Umfang ansteigt, sowie das Risiko von Fehlern. Ebenso erhöht sich der Wartungs- und Pflegeaufwand mit jeder zusätzlichen nicht geforderten Funktion. Die Genauigkeit bzw. Richtigkeit beschreibt, ob das Software-System bzw. die einzelnen Funktionen korrekte Ergebnisse aus der Verarbeitung zurückgeben. Dieses Kriterium betrachtet nicht, wie eine Funktion auf das Ergebnis kommt sondern lediglich, ob das geforderte Ergebnis erreicht wird. Mit der Interoperabilität ist die Fähigkeit der Software gemeint, über definierte Schnittstellen mit anderen Systemen Daten austauschen. Dieses Kriterium lässt sich vernachlässigen, wenn die Software als autarke Lösung, d.h. ohne Kommunikation mit weiteren Systemen funktionieren soll. 7 Vgl. (Hoffmann, 2008), S Vgl. (Grechenig, 2009), S Vgl. (Hoffmann, 2008), S Vgl. (Vigenschow, 2010), S

10 Der Sicherheitsaspekt des Merkmals Funktionalität beschreibt die vorhandenen Sicherheitsmechanismen des Software-Systems. Diese Mechanismen sollen den nicht autorisierten Zugriff auf Daten durch Menschen oder andere Systeme verhindern. Außerdem muss die Datenintegrität, also die Korrektheit der Daten, durch geeignete Funktionalität der Software gewährleistet werden. Datenschutz und Datenintegrität müssen zu jeder Zeit sichergestellt sein. Unter der Konformität der Funktionalität ist die Einhaltung bestimmter Normen der Software zu verstehen. Hierunter fallen internationale Standards und Normen, unternehmens- und kundenspezifische Absprachen, sowie gesetzlichen Vorschriften. Die funktionalen Kriterien lassen sich während der Entwicklungsphase durch ein gezieltes Qualitätsmanagement (vgl. Kapitel 2.4) überprüfen. Die Herausforderung besteht darin, auch bei großen und komplexen Software-Systemen möglichst viele Fehler durch gute Tests abzufangen. Die Fehlerhäufigkeit, mit denen Nutzer heutzutage konfrontiert werden, veranlasst viele Nutzer, die Softwarequalität auf das Kriterium der Funktionalität zu reduzieren Effizienz Grundlegend gibt die Effizienz an, ob ein vorgegebenes Ziel mit sparsamem Ressourceneinsatz erreicht wird. 12 Die Zielerreichung als solche wird bereits durch die Funktionalität (siehe Kapitel 2.2.1) gewährleistet. Die Effizienz einer Anwendung betrachtet der Kunde meist als die Zeit, die die Anwendung für eine bestimmte Aufgabe benötigt. Hierbei setzt sich die benötigte Zeit aus mehreren Teilen zusammen. Der erste Teil stellt die eigentliche Arbeitszeit dar. Diese Prozessorzeit ist die Zeit, in der der Prozessor für das Softwaresystem arbeitet. Der zweite Teil der Laufzeit ist die Zeit, in der das Softwaresystem auf den Prozessor wartet, da dieser anderen Programmen zur 11 Vgl. (Hoffmann, 2008), S Vgl. (Gabler Wirtschaftslexikon, Stichwort Effizienz). 6

11 Verfügung steht. Kunden erhalten über das Verhältnis von Warte- und Prozessorzeit nur selten Informationen, und können dem entsprechend nur die Gesamtzeit bewerten. Die Laufzeit spielt als Kriterium je nach Software-System eine unterschiedliche Rolle. In Echtzeitsystemen, die viele Daten jederzeit aktuell halten und diese schnell verarbeiten müssen, spielt die Laufzeit eine große Rolle und wird hier zu einem Teil der Funktionalität. 13 Neben dem zeitlichen Aspekt spielt die Frage der in Anspruch genommenen Hardwareressourcen durch die Anwendung eine Rolle bei der Bewertung des Effizienzmerkmals. 14 Der Ressourcenverbrauch war früher besonders eine Frage des Speicherbedarfs. Denn während dieser früher ein besonders rares und teures Gut war, ist heute die benötigte Prozessorleistung und teilweise Grafikleistung entscheidender Benutzbarkeit Unter Benutzbarkeit, auch Usability oder Benutzerfreundlichkeit genannt, werden die Merkmale zusammengefasst, die den notwendigen Aufwand beschreiben, eine Software zu benutzen und zu erlernen. Diese sind Verständlichkeit, Erlernbarkeit und Bedienbarkeit. 15, 16 Die Verständlichkeit beschreibt als Unterkriterium der Benutzbarkeit, wie gut die Dialoge zu verstehen sind. Also wie gut ist zu erkennen, was ein Dialog von einem erfahren will, aber auch ob Ergebnisse, die aus Funktionsaufrufen erzeugt werden, für den Nutzer gut zu interpretieren sind. Das Unterkriterium der Erlernbarkeit wiederum bewertet die Intuitivität eines Softwaresystems. Lässt sich der Umgang mit einer Software in relativ kurzer Zeit erlernen, so ist dies positiv. Zu diesem Punkt zählt auch die Dokumentation einer Software, beispielweise ein Handbuch, die dem Nutzer zur Verfügung 13 Vgl. (Hoffmann, 2008), S Vgl. (Vigenschow, 2010) S Vgl. (Hoffmann, 2008) S Vgl. (Vigenschow, 2010) S

12 gestellt wird. Anhand dieser Dokumentation können weniger intuitive Anwendungen vereinfacht erlernt werden. Das dritte Teilmerkmal der Benutzbarkeit ist die Bedienbarkeit einer Software. Hierunter fallen die Anzahl der Nutzeraktionen, bis eine gewünschte Funktion aufgerufen ist, die Fragestellung, ob Dialogmasken auf bestimmte Anforderungen angepasst werden können, und weitere. Dieses Merkmal beschreibt also, wie komfortabel mit einer Anwendung gearbeitet werden kann Zuverlässigkeit Das Kriterium der Zuverlässigkeit bei Software-Qualität wird beschrieben als die Bewahrung eines spezifizierten Leistungsniveaus unter festgelegten Bedingungen über einen definierten Zeitraum hinweg 17. Dabei wird auch von der Robustheit der Anwendung gesprochen. Auch dieses Kriterium lässt sich in mehrere Unterkriterien aufspalten. Diese Kriterien sind Reife, Fehlertoleranz und die Wiederherstellbarkeit bei Fehlern. 18 Das Unterkriterium der Reife drückt aus, wie häufig das Softwaresystem Fehler produziert. Sind Fehler häufig, so kann die Reife des Programms als eher gering eingestuft werden. Die Fehlertoleranz hingegen beschreibt das Maß, in dem auftretende Fehler durch das Programm behandelt werden. Ein fehlertolerantes Programm wird in Fehlersituationen nicht sofort abstürzen, sondern den Fehler für den Benutzer zum Beispiel durch Fehlermeldungen erkennbar machen. Weiterführend wird eine tolerante Anwendung eine Möglichkeit zum Weiterarbeiten nach einem Fehler bieten. Das dritte Unterkriterium der Zuverlässigkeit ist die Wiederherstellbarkeit bei Fehlern. Die Wiederherstellbarkeit meint die Fähigkeit einer Software, nach ei- 17 (Vigenschow, 2010), S Vgl. (Kletzin, 2007). 8

13 nem nicht abgefangen Fehler zu einem konsistenten Daten- und Softwarezustand zurück zu gelangen. Die Zuverlässigkeit als Qualitätsmerkmal der Software erhält eine immer höhere Bedeutung. Dies ist dem Umstand geschuldet, das Software-Systeme eine stärker werdende Rolle in der menschlichen Umwelt spielen. Vor allem in der Luftfahrt- und Automobilindustrie ist eine hohe Zuverlässigkeit der Software besonders in Bezug auf Reife und Fehlertoleranz ein Muss, um das Leben zu schützen. Bei der IT-gestützten Finanzbranche ist die Wiederherstellbarkeit der Daten und der Systeme als Teil der Zuverlässigkeit wichtig. 19 Ohne die Umsetzung der anderen Kriterien ist Zuverlässigkeit jedoch nicht möglich, weil eine starke Kopplung zu den anderen genannte und folgenden Qualitätsmerkmalen besteht. So hängt die Häufigkeit von Fehlern stark mit der Funktionalität zusammen. Sind Funktionalitäten falsch implementiert oder ändern sich Schnittstellen, die nicht auf aufrufender Seite nachgepflegt werden, treten Fehler auf. Aber auch zwischen Benutzbarkeit und Zuverlässigkeit bestehen Verbindungen. So wird durch eine schlechte Benutzbarkeit zum Beispiel in Form von unübersichtlichen Oberflächen und schlecht interpretierbaren Eingabeaufforderungen, eine fehlerhafte Bedienung der Anwendung begünstigt. Hierdurch kann es zu Fehlern in der Verarbeitung kommen. An diesem Punkt kommt die Zuverlässigkeit mit ihrer Fehlertoleranz zum Tragen. 2.3 Interne Qualitätsfaktoren Interne Qualitätsfaktoren bezeichnen die Merkmale der Softwarequalität, die bei der reinen Benutzung der Anwendung nicht erfahrbar sind. Sie können nur wahrgenommen werden, wenn auch die innere Struktur einer Software in Augenschein genommen wird. Dafür relevant sind alle Artefakte aus dem Entwicklungsprozess der Software (z. B. Quellcode, Dokumentation, Datenmodelle und Testfälle). Da diese Informationen im Allgemeinen nur dem Hersteller zugängig 19 Vgl. (Hoffmann, 2008) S. 8. 9

14 sind, werden die damit verbundenen Kriterien auch herstellerbezogene Kriterien genannt. Diese Qualitätsfaktoren umfassen Transparenz, Übertragbarkeit, Wartbarkeit und Testbarkeit einer Software Transparenz Eine Software wird als transparent bezeichnet, wenn ihre Implementierung dem Betrachter nicht verschleiert, welcher Zweck auf welche Art und Weise erreicht wird. Ebenso ist wichtig, dass das Programm einer logisch nachvollziehbaren Struktur folgt. Auf diesen Aspekt wird im weiteren Verlauf dieser Arbeit noch häufiger Bezug genommen, da er großen Einfluss auf die Softwarealterung hat. Wie die meisten Qualitätsfaktoren lässt sich die Transparenz einer Software nur schwer messen. 21 Mit Softwaremetriken existiert jedoch die Möglichkeit, Kennzahlen aus dem Quelltext zu ermitteln und zu interpretieren. Mit einigen Kennzahlen kann im Ansatz auch die Transparenz des Quellcodes beurteilt werden. Eine solche Kennzahl ist die zyklomatische Komplexität nach McCabe. Sie geht darauf ein, wie viele Schleifen und Verzweigungen ein Stück Code enthält und bildet auf dieser Basis einen Wert. 22 Je geringer die Transparenz eines Codeabschnitts ist, desto höher ist die Einarbeitungszeit, die ein Entwickler benötigt, den vorhandenen Code zu verstehen. Metriken bieten eine Möglichkeit, zu erkennen, wie transparent der Code ist. Im Detail werden verschiedene Metriken in Kapitel behandelt. 20 Vgl. (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S Vgl. (Schneider, 2007), S. 58, 61 ff. 10

15 2.3.2 Übertragbarkeit Übertragbarkeit oder auch Portabilität bezeichnet die Möglichkeit, eine Software an neue oder veränderte Umgebungen anzupassen. Der Begriff Umgebung kann hierbei verschiedene Bedeutungen annehmen. Es kann eine Hardwarearchitektur gemeint sein. Eine Änderung der Hardwareumgebung wäre zum Beispiel der Wechsel von einer 32-Bit-Architektur auf eine 64-Bit-Architektur. Ebenso kann der Umgebungswechsel bedeuten, dass eine neue Geräteart mit dieser Software versorgt werden soll. Je größer die Übertragbarkeit ist, desto geringer fällt der Aufwand für Anpassungen an eine neue Umgebung aus. Ein Beispiel für Übertragbarkeit ist die Veröffentlichung des ipads durch Apple im Jahr Dieses nutzt im Kern das gleiche Betriebssystem wie auch das bereits einige Jahre zuvor veröffentlichte iphone. Durch die Veröffentlichung wurde auch eine Namensänderung des Betriebssystems von iphone OS auf das allgemeingültigere ios vollzogen. 23 Im Vorfeld der Veröffentlichung des ipads wird Apple mit hoher Wahrscheinlichkeit Anpassungen am Betriebssystem vorgenommen haben, damit es auch auf dem ipad optisch ansprechend und fehlerfrei funktioniert. Umso geringer der Aufwand für diese Anpassungen war, desto größer ist die Übertragbarkeit des Betriebssystems iphone OS gewesen. Da es sich bei der Abschätzung der Übertragbarkeit um keine absolute Messgröße handelt, bietet es sich an, hier einen Vergleich zu ziehen. Durch die Schaffung einer Relation kann zumindest eine eingeschränkte Vergleichbarkeit erreicht werden. Es bieten sich hierbei vor allem zwei Vergleiche an. Der Vergleich mit anderen, ähnlich gelagerten Projekten bietet eine Möglichkeit einzuschätzen, wie gut oder schlecht es um die eigene Software in Bezug auf die Portabilität steht. Die Referenzwerte sind jedoch nicht einfach zu erhalten. Im Falle der Anpassungen des Betriebssystems für das ipad würde ein Ver- 23 Vgl. (Patel, 2010). 11

16 gleich der erfolgten Anpassungen der Betriebssystem WebOS und Android sich anbieten, da diese ebenfalls später für Tablets veröffentlicht wurden. 24 Ein anderer möglicher Vergleich kann mit anderen Lösungsalternativen erfolgen. Um bei dem Beispiel der Anpassung vom Smartphone- zum Smartphoneund Tablet-Betriebssystem zu bleiben, bietet es sich an, die geschätzten Aufwände für drei Umsetzungsmöglichkeiten zu vergleichen. Die erste Möglichkeit stellt die Anpassung des bestehenden Betriebssystems für die neue Plattform dar. Die zweite Möglichkeit ist die komplette Neuentwicklung des Betriebssystems, um es von Grund auf flexibler zu gestalten. Die letzte Möglichkeit stellt eine parallele Entwicklung eines zweiten Betriebssystems dar. Wenn der Aufwand für die Anpassung höher als der Aufwand der anderen Optionen ist, dann ist die Portabilität als gering einzustufen. Dabei sind bei allen Möglichkeiten neben dem Einmalaufwand auch die Folgeaufwände zu berücksichtigen Wartbarkeit Die Wartbarkeit ist unmittelbar verknüpft mit der Transparenz. Sie wird dann erreicht, wenn die Behebung eines Fehlers in der Software oder die Erweiterung der Software um neue Funktionalitäten möglichst einfach und intuitiv durchführbar ist. Somit ist Transparenz eine Grundvoraussetzung für Wartbarkeit, jedoch nicht die alleinige Bedingung dafür. Ebenfalls in die Betrachtung mit einbezogen werden müssen andere Artefakte der Softwareentwicklung. So kann eine umfangreiche und aktuelle Dokumentation Mängel in der Nachvollziehbarkeit oder der Kommentierung des Programmcodes teilweise aufwiegen. Es wird deutlich, dass auch die Wartbarkeit in einem gewissen Rahmen von der subjektiven Wahrnehmung abhängt. Messungen der Wartbarkeit sind vor allem durch Messung der Transparenz möglich Daten dazu sind den Autoren unbekannt. 25 Vgl. (Hoffmann, 2008), S

17 Von großer Bedeutung ist die Wartbarkeit für nahezu jede Software. Dafür gibt es zwei Hauptursachen. Zum einen ist Software so gut wie nie fehlerfrei. Dadurch ist die Wahrscheinlichkeit hoch, dass früher oder später Code von Fehlern bereinigt werden muss. Zum anderen bringen die Weiterentwicklung der Gesellschaft, der technischen Möglichkeiten aber auch gesetzliche Anforderungen mit sich, dass neue Funktionalitäten ergänzt oder bestehende verändert werden müssen. Je nachdem, wie sich das Unternehmen und seine Mitarbeiter weiterentwickeln, muss entweder einer der ursprünglichen Anwendungsentwickler oder ein neuer, nicht mit der Software vertrauter Entwickler die Änderungen vornehmen. Daher ist die Wartbarkeit für neue Anwendungsentwickler wichtig, aber auch für bereits eingearbeitete Entwickler von großer Bedeutung. Aufgrund der Verbindung zur Transparenz und der hohen Bedeutung der Wartbarkeit wird auch diese im weiteren Verlauf der Arbeit wieder aufgegriffen werden Testbarkeit Testbarkeit ist eine wichtige Eigenschaft, um Fehler zu erkennen, bevor eine Softwareversion veröffentlicht wird. Für die Testbarkeit sind viele Faktoren von Bedeutung. Ist der Softwarecode komplett verfügbar, erleichtert dies das Testen. Sind jedoch Codebestandteile durch andere Firmen oder Abteilungen entwickelt worden und nur als Bibliothek verfügbar, kann dies das Testen erschweren. Ebenfalls relevant ist der Komplexitätsgrad der Software. Je mehr verschiedene Konstellationen eine Software berücksichtigen muss, desto schwieriger wird es, alle möglichen Parameterausprägungen im Rahmen von Tests zu berücksichtigen. 26 Doch neben den Codeeigenschaften ist auch eine passende Anforderungsdefinition wichtig. Funktionale Anforderungen lassen sich in aller Regel testen. Nicht funktionale Anforderungen, z.b. Anforderungen an die 26 Vgl. (Hoffmann, 2008), S

18 Laufzeit eines Systems, müssen erst in testbarer Art und Weise formuliert werden. Je mehr Rahmenbedingungen bei der Anforderungsdefinition konkretisiert werden, desto besser lässt sich die Erreichung dieser Anforderung testen. Das Thema Softwaretest wird in Kapitel als Teil der Qualitätssicherung behandelt Qualitätsmanagement / Qualitätssicherung In der Softwareentwicklung spielt die Qualität, wie auch in anderen Bereichen, eine entscheidende Rolle. Angestrebt wird vorrangig die Zufriedenheit des Kunden. Sie zeigt sich, wenn ein Produkt seinen ursprünglich gestellten Anforderungen entspricht und den in Kapiteln 2.2 beschrieben Qualitätsmerkmalen genügt. Ist ein Produkt qualitativ nicht hochwertig, wird der Kunde das entwickelnde Unternehmen nicht weiterempfehlen. Zudem folgen Nachbesserungen des Produkts, in die zusätzlich Zeit, Geld und Ressourcen investiert werden müssen. Diese Ressourcen wiederum sind in der Regel für die Zeit nach dem Projekt anders eingeplant, was wieder Einbußen bei den Folgeprojekten bedeuten kann. Um diesem Teufelskreis entgehen zu können, ist das Qualitätsmanagement eine sinnvolle Methode. Es befasst sich insbesondere mit den organisatorischen Maßnahmen zur Erreichung und zum Nachweis einer hohen Produktqualität 28. Dafür werden ein oder mehrere Mitarbeiter beauftragt, die Rolle des Qualitätsbeauftragten zu übernehmen. Dies kann übergeordnet in der Organisation der Fall sein, wird in der Regel aber auf einzelne Bereiche übertragen und dort im Bedarfsfall auch auf einzelne Projekte. Primäres Ziel des Qualitätsmanagements ist ein Wirtschaftliches: Die Einsparung von Kosten. Dies kann, wie oben schon angedeutet, dadurch ermöglicht werden, dass die Maßnahmen zur Erreichung der gewünschten Qualität eingehalten werden. Dann 27 Vgl. (Schneider, 2007), S. 51f. 28 (Liggesmeyer, 2009), S

19 steigen die Chancen enorm, dass eine Software das Unternehmen ohne schwerwiegende Fehler verlässt und Fehlerkorrekturen ausbleiben oder deutlich geringer ausfallen. Natürlich wird ein Teil der Einsparung auf der anderen Seite für ein gutes Qualitätsmanagement verwendet, dennoch sind unter dem Strich in der Regel Kosteneinsparungen zu verzeichnen. Auch ein Imageschaden des Unternehmens kann durch den Einsatz eines Qualitätsmanagements verhindert werden. 29, 30 Das Qualitätsmanagement setzt sich aus den vier Bereichen Qualitätsplanung, Qualitätssteuerung, Qualitätssicherung und Qualitätsverbesserung zusammen. Sie werden in den folgenden Kapiteln erläutert. Der Schwerpunkt der Betrachtung liegt auf der Qualitätssicherung, welche generell den größten Part des Qualitätsmanagements für sich einnimmt. 31, Qualitätsplanung Die Qualitätsplanung ist der erste Schritt im Rahmen des Qualitätsmanagements. Es befasst sich laut der Norm DIN EN ISO 8402, mit der Planung von Tätigkeiten, welche die Ziele und die Qualitätsanforderungen sowie die Forderungen für die Anwendung der Elemente des QM-Systems [QM = Qualitätsmanagement] festlegen 33. Abhängig vom zu erstellenden Produkt o- der der zu erstellenden Dienstleistung werden die oben beschriebenen Qualitätsmerkmale auf den Grad der möglichen Realisierbarkeit untersucht. Pro identifiziertem Qualitätsmerkmal wird festgelegt, was das genau für das betrachtete Produkt bedeutet. Was wird beispielsweise unter Benutzbarkeit für das spezielle Produkt verstanden, ist eine zu klärende Frage. Neben der Festlegung der Bedeutung der Qualitätsmerkmale für den konkreten Fall gehört auch die Festlegung von Maßnahmen zur Erreichung der Qualität in den Be- 29 Vgl. (Liggesmeyer, 2009), S. 10f. 30 Vgl. (Frühauf, 2002); S Vgl. (Liggesmeyer, 2009), S Vgl. (Qualitätsdatenbank, Stichwort Qualitätsmanagement, 2003). 33 (Qualitätsdatenbank, Stichwort Qualitätsplanung, 2003). 15

20 reich der Planung. Beispiele für solche Maßnahmen können regelmäßige Meetings zum Austausch des aktuellen Stands und zur Diskussion von möglichen Problemen innerhalb des gesamten Teams sein. Das können aber auch die Art der Entwicklung oder Tests sein. Es könnte beispielsweise festgelegt werden, dass der Quellcode von einem anderen Entwickler einem Review unterzogen werden muss, oder dass Testfallbeschreibung und Testfallausführung nicht von der gleichen Person durchzuführen sind. Zu guter Letzt fällt die Planung des Qualitätsmanagementsystems in diesen Bereich, sofern eines verwendet wird. 34, 35, Qualitätssteuerung Der Bereich der Qualitätssteuerung befasst sich im Wesentlichen mit der Überprüfung, ob die im Rahmen der Qualitätsplanung festgelegten Maßnahmen eingehalten werden. Hier ist der zu Anfang des Kapitels 2.4 angesprochene Qualitätsbeauftragte gefragt, der in Persona diese Überwachung übernimmt. Werden die Maßnahmen nicht eingehalten, muss dies entsprechend durch den Qualitätsbeauftragten an die Projekt- oder Abteilungsleitung kommuniziert werden. Es muss daraufhin abgestimmt werden, welche Gegenmaßnahmen eingeleitet werden müssen, um eine Erreichung der festgelegten Maßnahmen zur Erreichung der geforderten Qualität sicherzustellen Qualitätssicherung Die Qualitätssicherung umfasst alle geplanten und systematischen Tätigkeiten, die ausgeführt werden, um eine Qualitätsanforderung zu erfüllen 38. Es gibt vie- 34 Vgl. (Qualitätsdatenbank, Stichwort Qualitätsplanung, 2003). 35 Vgl. (Wirtschaftslexikon24, Stichwort Qualitätsplanung, ) 36 Vgl. (Voigt). 37 Vgl. (Voigt). 38 (Qualitätsdatenbank, Stichwort Qualitätssicherung, 2004). 16

21 le verschiedene Möglichkeiten, den Begriff der Softwarequalitätssicherung zu strukturieren. In dieser Arbeit wird die Unterteilung nach Produkt- und Prozessqualität, wie im Buch Software-Qualität von Dirk W. Hoffmann, gewählt und in den nachfolgenden Kapiteln erläutert Produktqualität Die Produktqualität setzt sich mit der Erfüllung der in der Qualitätsplanung festgelegten Qualitätsmerkmale auseinander. Zu ihr gehören die Bereiche Konstruktive Qualitätssicherung und Analytische Qualitätssicherung Konstruktive Qualitätssicherung Die konstruktive Qualitätssicherung befasst sich mit Maßnahmen, die schon während der Planungs- und Entwicklungsphase der Software eingehalten werden sollten. So können beispielsweise Richtlinien für den einheitlichen Gebrauch der Programmiersprache verwendet werden, oder grundsätzlich bestimmt werden, dass nur typisierte Programmiersprachen verwendet werden. So können nur bestimmte definierte Datentypen verwendet werden, die dann in der Folge nicht zu Inkonsistenzen führen. Denkbar ist auch die sogenannte vertragsbasierte Programmierung, bei der es darum geht, innerhalb des Codes zu spezifizieren, wie sich Software-Fehler durch die gezielte Angabe von Vor- und Nachbedingungen, Invarianten und Zusicherungen bereits während der Programmerstellung erkennen lassen 40. Weiterhin sollten mögliche Fehler in der Bedienung, oder auch Laufzeit- und Grenzwertfehler bereits in der Entwicklungsphase berücksichtigt werden, damit die Software nicht abstürzt. Weitere Maßnahmen sind die Erhöhung der Portabilität, beispielsweise durch Vermeidung von plattformspezifischem Code, die Dokumentation innerhalb des Quell- 39 Vgl. (Hoffmann, 2008), S (Hoffmann, 2008), S

22 codes sowie entsprechende Konzepte zur Spezifikation und Umsetzung der Anforderungen Analytische Qualitätssicherung Die analytische Qualitätssicherung befasst sich mit der Bewertung und Analyse einer bestehenden Software, beziehungsweise mit der Überprüfung, ob die Erfüllung der Qualitätsmerkmale der Software gelungen ist. Sie lässt sich einteilen in die Bereiche Softwaretests, Statische Analyse und Softwareverifikation Softwaretest Der Softwaretest ist die wohl bekannteste Methode der Überprüfung einer Software. Vor dem eigentlichen Test werden Testfälle erfasst, die beschreiben, was genau zu testen ist. Es bietet sich an, hierbei zunächst zu beschreiben, was genau Inhalt des Testfalls ist und wie der Tester die zu testende Situation herbeiführen kann. Anschließend sollte ein erwartetes Ergebnis formuliert werden. So kann der Tester während des Tests abgleichen, ob das tatsächliche Ergebnis mit dem Soll-Ergebnis übereinstimmt. 43, 44 Das Quality Center von HP ist ein Produkt, das die Möglichkeit bietet, Softwaretests zu erfassen und Ergebnisse zu protokollieren. Es wird in Unternehmen eingesetzt, um die Testausführung planbar, einheitlich und übersichtlich darstellen zu können. Zunächst werden die Testfälle mit einer Beschreibung der zu testenden Funktion, und einer Beschreibung dessen, was der Tester bei diesem Testfall zu tun hat, bestückt. Zudem wird das erwartete Ergebnis formuliert. Im Rahmen der Testfallausführung kann der Tester an jedem Testfall verschiede Status vergeben. Sie beschreiben beispielsweise, ob der Testfall erfolgreich ausgeführt wurde, ob er sich in der Ausführung befindet, ob er noch 41 Vgl. (Hoffmann, 2008),S Vgl. (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S Vgl. (Vigenschow, 2010), S

23 nie ausgeführt wurde, ob der Testfall fehlerhaft ist, oder ob der Testfall nicht ausgeführt werden kann. Eine Testart ist der Blackbox-Test, auch funktionsorientierter Test genannt. Black-Box-Tests werden direkt aus der Spezifikation abgeleitet, welche die Neuerungen beschreibt, die zu testen sind. Das heißt, es ist keine Kenntnis über den Quellcode vorhanden, wenn die Testfälle verfasst und abgearbeitet werden. 45, 46 Dem Blackbox-Test gegenüber steht der Whitebox-Test, auch strukturorientierter Test genannt. Dieser beinhaltet auch die Methoden des Blackbox-Tests, vor der Testausführung wird jedoch der Code inspiziert und die erwartete Ausgabe eines Programms beurteilt. Eine Unterscheidung beider Testarten lässt sich der folgenden Grafik entnehmen: 47, 48 Abbildung 1: White-Box- und Black-Box-Test 49 Neben Black- und Whitebox-Test gibt es noch die Testmetriken. Sie helfen, die Güte einer Testmenge quantitativ zu bestimmen 50. Dafür können verschiedene 45 Vgl. (Hoffmann, 2008), S Vgl. (Schneider, 2007), S Vgl. (Hoffmann, 2008), S Vgl. (Liggesmeyer, 2009), S (Liggesmeyer, 2009), S (Hoffmann, 2008), S

24 Kennzahlen ermittelt werden, die beispielsweise den Grad der Testabdeckung, die vermutete Anzahl Fehler oder den Grad der bisher ausgeführten Tests anzeigen. Diese Zahlen können bei gleicher Ermittlungsstrategie zu Kennzahlen eines anderen Projekts ins Verhältnis gesetzt werden. So ist eine Einschätzung über den Stand des Tests im eigenen Projekt möglich. 51, Statische Analyse Die statische Analyse beinhaltet im Gegensatz zu den Softwaretests keine Ausführung des Quellcodes. Sie befasst sich beispielsweise mit der Überprüfung, ob die oben bereits angesprochenen Programmierrichtlinien eingehalten wurden, oder mit der Inspektion von Quellcode. Letztendlich geht es um die Nutzung des Mehraugenprinzips. Das heißt, der Entwickler lässt seine Arbeit von jemand anderem qualitätssichern, aber nicht per Softwaretest. Mögliche Methoden sind die Nutzung von Softwaremetriken, die Konformitätsanalyse, die Exploit-Analyse, die Anomalieanalyse und die manuelle Softwareprüfung. Softwaremetriken sollen helfen, einige der in Kapitel 2.2 und 2.3 beschriebenen Qualitätsmerkmale quantitativ zu erfassen 53. Die drei bekanntesten Metriken sind Lines of Code, die McCabe-Metrik und die Halstead-Metriken, die im Folgenden kurz erläutert werden. 54, 55 Bei der Lines-of-Code-Metrik werden die Quellcode-Zeilen gezählt, um dann bei verschiedenen Programmen Vergleiche anhand der Zeilenanzahl ableiten zu können. Hierbei ergibt sich die Schwierigkeit, dass im Sinne der Vergleichbarkeit festgelegt werden muss, welche Zeilen alle gezählt werden. Denkbar ist beispielsweise, nur die Zeilen zu zählen, die keinen Kommentar aufweisen und keine Leerzeile sind. Es könnten aber auch nur die Zeilen mit Anweisungen gezählt werden, so bleiben das Setzen von Variablen oder Zeilen mit Klammern 51 Vgl. (Testmetriken, 2011). 52 Vgl. (Hoffmann, 2008), S (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S Vgl. (Liggesmeyer, 2009), S

25 außen vor. Um die Vergleichbarkeit sicherzustellen, sollte sich innerhalb eines Projekts oder Unternehmens auf eine Zählweise geeinigt werden. 56,57 Die McCabe-Metrik der zyklomatischen Komplexität soll, wie der Name verrät, die Komplexität einer Software messen. Dies geschieht anhand der Ablaufmöglichkeiten des Programms. Beispielsweise kann ein case-statement beliebig viele Verzweigungen haben, bei for- oder while-schleifen gibt es keine, eine oder mehrere Möglichkeiten. Die Metrik berechnet sich wie folgt: 58, 59 Abbildung 2: Zyklomatische Komplexität 60 Die Halstead-Metriken befassen sich mit der Messung verschiedener Softwareeigenschaften und basieren auch auf dem Quellcode. Es werden jedoch Operanden und Operatoren gezählt. Die vier Basisgrößen sind: η 1 = Anzahl der unterschiedlichen Operatoren η 2 = Anzahl der unterschiedlichen Operanden N 1 = Gesamtzahl der verwendeten Operatoren N 2 = Gesamtzahl der verwendeten Operanden Mit Hilfe dieser vier Grundgrößen soll unter anderem die Frage beantwortet werden, wie viele Fehler sich vermutlich im Programm befinden. Dafür werden zunächst die Programmlänge N = N1 + N2 und die Größe des Vokabulars η = η 1 + η 2 bestimmt, und anschließend das Volumen des Programms mit der Formel V = N log 2 η. Die geschätzte Fehlerzahl bestimmt sich abschließend mit B = V : Es können noch weitere Maße bestimmt werden um beispielsweise den Aufwand zur Kodierung eines Algorithmus zu errechnen, der nach 56 Vgl. (Hoffmann, 2008), S Vgl. (Schneider, 2007), S Vgl. (Hoffmann, 2008), S Vgl. (Schneider, 2007), S (Schneider, 2007), S

26 Halstead proportional zur Programmgröße und zur Schwierigkeit der Kodierung steht. 61, 62 Eine weitere Form der statischen Analyse ist die Konformitätsanalyse. Hierunter wird die Einhaltung der in Kapitel zur konstruktiven Qualitätssicherung beschriebenen Richtlinien verstanden. 63 Mit der Exploit-Analyse können mögliche Sicherheitslücken aufgedeckt werden. Viren oder Hackerangriffe können sich diese Sicherheitslücken zunutze machen, wenn sie nicht vor der Inbetriebnahme der Software erkannt und geschlossen werden. 64 Mit Hilfe der Anomalieanalyse können Programme auf ungewöhnliche Anweisungsabläufe geprüft werden. Eine Anomalie wird hierfür beschrieben als jede Abweichung bestimmter Eigenschaften eines Programms oder Moduls von der korrekten Ausprägung dieser Eigenschaften 65. Oft werden Fehler nicht direkt erkannt, sondern Fehlersymptome aufgedeckt. 66, 67 Die manuelle Softwareprüfung beinhaltet keine technische Unterstützung beim Test, sondern beschränkt sich auf das Mehraugenprinzip. Beispielsweise wird der Quellcode nicht ausgeführt, sondern von einem anderen Programmierer durchgelesen und auf Fehler geprüft. Hierfür können Checklisten eingesetzt werden, die zu prüfenden Punkte enthalten. Bekannte Techniken sind Walkthrough, Review und Inspektion. Sie unterscheiden sich in der Tiefe und Ausrichtung der Prüfung Vgl. (Liggesmeyer, 2009), S Vgl. (Schneider, 2007), S Vgl. (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S (Liggesmeyer, 2009), S Vgl. (Liggesmeyer, 2009), S Vgl. (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S

27 Software-Verifikation Die Software-Verifikation beinhaltet mehrere Methoden, die auf mathematischem Wege versuchen, bestimmte Eigenschaften eines Programms formal zu beweisen 69. Da die formale Verifikation den Anspruch erhebt, alle möglichen Fälle zu testen und die vollständige Korrektheit des Systems anstrebt, ist diese Methode sehr zeitintensiv. Sie kann in der Konsequenz nur für kleinere Programme angewendet werden, da die Komplexität des Testalgorithmus und die Zeit für dessen Erstellung sehr hoch sind. Die semiformale Verifikation erhebt keinen Anspruch auf vollständige Korrektheit, und ist daher auch für größere Softwareprojekte eine Alternative der Qualitätssicherung. Die Erkennung von Fehlern erfolgt auch hier über Algorithmen. 70, Prozessqualität Die Prozessqualität beinhaltet sämtliche Maßnahmen, die eine geregelte Entwicklung eines Software-Produkts in Form eines definierten Prozesses gewährleisten 72. Zu ihr gehören die Bereiche Software-Infrastruktur und Managementprozesse Software-Infrastruktur Der Bereich Software-Infrastruktur umschreibt alle Einrichtungen und Maßnahmen, die den Entwickler aus technischer Sicht in die Lage versetzen, seiner täglichen Arbeit in geregelter und vor allem produktiver Weise nachzugehen 73. Zum einen kann der Programmierer durch das Konfigurationsmanagement unterstützt werden, was vor allem den Einsatz von Versionierungssysteme wie 69 (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S Vgl. (Liggesmeyer, 2009), S (Hoffmann, 2008), S (Hoffmann, 2008), S

28 ClearCase oder ähnlichen bedeutet. So kann er immer auf alte Stände seines Quellcodes zurückgreifen und parallele Entwicklung für verschiedene Releases betreiben. Zusätzlich kann eine Build-Automatisierung genutzt werden. Sie dient der automatisierten Kompilierung des Quellcodes. Ähnlich der Build- Automatisierung funktioniert auch die Testautomatisierung, die ohne manuelle Eingriffe vor allem im Bereich der Regressionstest punkten kann. Zudem ist ein Defektmanagement eine Unterstützung für den Entwickler. Hier erfolgt eine Erfassung nicht erwartungskonformer Reaktionen der Software in einer zentralen Datenbank. Im bereits oben erwähnten Quality Center können Fehler direkt am betroffenen Testfall protokolliert werden. Der Entwickler wird automatisch über den dokumentierten Fehler informiert und kann die Fehlerbehebung durchführen. Anschließend kann der Re-Test erfolgen, der wiederum protokolliert werden kann, so dass der Testfall letztendlich als erfolgreich ausgeführt gekennzeichnet werden kann Managementprozesse Der Bereich Managementprozesse stellt Methoden und Vorgehensweisen zur geregelten Durchführung eines Software-Projekts 75 in den Fokus. Vorgehensmodelle legen grundlegend fest, wie ein Projekt durchgeführt werden soll. Bestandteile sind Planungen, Schätzungen und Rollendefinitionen. Auch Reifegradmodelle sollen die Prozessqualität erhöhen. Mit ihnen können bestehende Prozess analysiert und anschließend verbessert werden Vgl. (Hoffmann, 2008), S (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S

29 2.4.4 Qualitätsverbesserung Der Bereich der Qualitätsverbesserung zielt nicht auf ein bestimmtes Projekt oder eine bestimmte Software, die zu entwickeln ist, ab. Vielmehr geht es darum, das Qualitätsniveau in Summe in einem Unternehmen zu steigern. Sie ist im Rahmen des einmalig ablaufenden Einzelprojekts nur bedingt möglich [ ], sehr wohl jedoch im projektorientierten Unternehmen projektübergreifend von größter Bedeutung 77. Es können unternehmensübergreifend Handlungsanweisungen und Hilfestellungen gegeben werden, die es zum einen ermöglichen, Einheitlichkeit in der Qualitätsplanung, Qualitätssteuerung und Qualitätssicherung zu schaffen. Zum anderen kann dafür Sorge getragen werden, dass auch miteinander verzahnte Projekte oder voneinander abhängige Softwareentwicklungen besser miteinander kommunizieren und gemeinsam reagieren. 78, (Patzak, 2010), S Vgl. (Patzak, 2010), S Vgl. (Qualitätsdatenbank, Stichwort Qualitätsverbesserung, 2003). 25

30 3 Softwarealterung 3.1 Definition Softwarealterung In den Anfängen der Softwareentwicklung wurde Software so entwickelt, dass die verwendete Hardware nahezu komplett ausgeschöpft wurde. Wurden neue und bessere Hardwareplattformen auf den Markt gebracht, wurde die Software neu entwickelt und die neuen Möglichkeiten wiederum ausgeschöpft. Die Komplexität der Systeme wuchs. Plattformen und auch die Softwareentwicklungswerkzeuge wurden immer besser und leistungsfähiger. Bei den heutigen Systemen ist es nur noch schwer möglich, deren scheinbar grenzenlose Möglichkeiten auszuschöpfen. Immer größere, komplexere und langlebigere Softwaresysteme können entwickelt werden. In diese großen Systeme wird bis heute viel Geld investiert, so dass einem Unternehmen daran gelegen ist, diese Investition durch entsprechende Wartung zu schützen. 80 Die Möglichkeit, Systeme in nahezu beliebiger Größe zu erstellen, erfordert einen hohen Wartungsaufwand. Durch die Größe des Systems und die einbezogenen Themenfelder sind sich ändernde Anforderungen an das System nicht selten. Da große Systeme zusätzlich eine lange Lebensdauer besitzen, sind sie permanenten Änderungen unterworfen. Es wurde der Begriff der Softwarealterung oder auch Softwarefäulnis geschaffen. 81 Softwarealterung wird beschrieben als schleichende Degradierung verschiedener Qualitätsparameter über die Zeit 82. Durch wechselnde und neue Anforderungen wird der Code sukzessive ergänzt und bestehender Code an neue Gegebenheiten angepasst, und nicht mehr wie zu Anfangszeiten der Softwareentwicklung komplett neu geschrieben. 83, Vgl. (Bommer, 2008), S Vgl. (Bommer, 2008), S (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S Vgl. (Bommer, 2008), S

31 Softwarealterung zeigt sich anhand verschiedener Merkmale. Diese Merkmale und auch die Gründe für zunehmende Softwarealterung werden in den folgenden Kapiteln betrachtet. 3.2 Gründe für Softwarealterung Es gibt nicht nur einen Grund dafür, dass Software altert. Vielmehr sind die Gründe vielfältig und kommen aus unterschiedlichsten Bereichen. Maßgeblich relevant sind die Einflüsse auf den Softwarecode sowie Änderungen des Entwicklungsumfeldes. In diesem Kapitel werden die häufigsten Gründe für Softwarealterung erläutert sowie ihre Auswirkungen exemplarisch angesprochen. Weitere Auswirkungen sind möglich, werden jedoch aufgrund ihrer Vielfältigkeit nicht angesprochen. Gründe für die Alterung von Software sind Fehlerbehebung, funktionale Erweiterung, Rückwärtskompatibilität, nachträgliche Portabilität und Personalwechsel Fehlerbehebung Einer der Gründe für die Degeneration von Software Code sind nicht ausgereifte Fehlerbehebungen. Fehler sind in Softwaresystemen nicht immer zu vermeiden. Innerhalb der Lebensdauer werden solche Fehler nach und nach entdeckt und behoben. Je stärker der Zeitdruck für eine Fehlerbehebung ist, desto eher wird das Problem mit einem Workaround behoben. Dabei wird meist nicht die Ursache tiefergehend analysiert oder auf die Code-Architektur geachtet, sondern lediglich auf die fachliche Korrektheit der Lösung Wert gelegt. Die Anhäufung solcher Fehlerkaschierungen an Stelle von echten Fehleranalysen und -behebungen hat ihre Ursache neben dem Zeitdruck vor allem darin, dass der Code für Außen- 27

32 stehende unsichtbar ist und nur die korrekte Funktionsweise der Software bewertet wird. 85 Die Möglichkeit, Fehler auf diese Weise verschwinden zu lassen, begünstigt diese sogenannten Quick-Fixes erst. Zur Rechtfertigung wird häufig angeführt, dass der Fehler nur vorübergehend durch diese schnelle und unsaubere Lösung unterbunden werden soll. Eine ursächliche Behebung solle dann mit dem nächsten Release erfolgen. Aufgrund der für das folgenden Release zur Verfügung stehenden Zeit und den zusätzlichen Aufgaben bei der Softwareentwicklung fällt die weitere Fehlerbehebung zu Gunsten dieser anderen Aufgaben häufig unter den Tisch Funktionelle Software-Erweiterung Wie in Kapitel angedeutet besteht ein wichtiger Grund für das Degenerieren von Software in der Erweiterung des Systems um neue Funktionalitäten. Werden durch Kunden oder auf Grund von unternehmensinternen Entscheidungen neue Anforderungen an das System gestellt, so müssen diese implementiert werden. Bei solchen nachträglichen Erweiterungen muss auf die vorhandene Architektur des Grundsystems geachtet werden. Wird dies nicht gemacht oder lassen sich die neuen Anforderungen nicht mit dieser Architektur vereinbaren, werden häufig parallele Strukturen aufgebaut. Diese neuen Strukturen enthalten dann die neuen Funktionen und werden an die bestehende Architektur angehängt ohne sie dabei in passender Weise zu integrieren. 87 Wird die Architektur des bestehenden Software-Systems beachtet, so ist dies noch kein Garant dafür, dass die Software bei der Erweiterung nicht oder langsamer degeneriert. Mit neuen Funktionen steigt sowohl die Anzahl der Schnitt- 85 Vgl. (Hoffmann, 2008), S. 385 ff. 86 Vgl. (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S. 381ff.. 28

33 stellen unter den einzelnen internen Modulen als auch nach außen. Eine neue Funktion benötigt beispielsweise eine Funktion, die schon für andere Funktionalitäten vorhanden ist, aber mit anderen Aufrufparametern. In diesem Fall entsteht eine neue Schnittstelle, über die die Parameter der neuen Funktion auf die Aufrufparameter der Unterfunktion gemappt werden. Ein weiteres Problem entsteht durch Code-Verdopplung, d.h. mehrere Funktionen erfüllen denselben Zweck. Eine solche Verdopplung entsteht durch schlecht lesbaren oder schlecht dokumentierten Programmcode. Ist einer Funktion nicht zu entnehmen, was sie tut, sichern sich Programmierer meist ab und entwickeln ein neue, eigene Funktion, die mit Sicherheit ihren Anforderungen entspricht. Auch bei Bibliotheken tritt dieses Problem auf, da hier eine genauere Analyse des Quellcodes nicht möglich ist. 88 Diese Ursache der Softwarealterung setzt nicht nur bei der Erweiterung um neue Funktionalitäten ein, sondern kann schon bei der Entwicklung des Grundsystems entstehen. Werden zu einem späten Zeitpunkt während der Entwicklung bestehende Anforderungen verändert, kann das dazu führen, dass zwar große Teile des bestehenden Codes beibehalten werden können, kleinere aber nicht mehr benötigt werden. Sind diese Passagen jedoch in andere Funktionen ausgelagert, wird der Aufruf unter Umständen zwar entfernt, die Funktion selbst jedoch bleibt als ungenutztes Code-Fragment in der Anwendung zurück Personalwechsel Neben der Software-Alterung durch Erweiterungen und Fehlerbehebung liegt ein weiteres Problem in den verschiedensten Programmierstilen von Anwendungsentwicklern. Wie in vielen anderen Bereich herrscht auch in der Software- Entwicklung eine Vielfalt an Entwicklungsstilen vor. Mit jedem neuen Entwickler, der an einer Software arbeitet, fließt dessen Programmierstil in den Code und die Mikroarchitektur ein. Dies führt langfristig zu einem unübersichtlichen 88 Vgl. (Hoffmann, 2008), S. 383 ff. 89 Vgl. (Hoffmann, 2008), S

34 Mix verschiedener Programmierstile. Auch die zuvor genannten Probleme der Code-Dopplung oder die Entstehung von ungenutztem Code können auftreten. Dieses Problem betrifft vor allem langlebige Software-Systeme, die über mehrere Release hinweg wachsen. Dass an langlebigen Software-Systemen verschiedene Entwickler und auch Entwicklerteams arbeiten, liegt zum einen an der Größe der Projekte, die unter Umständen weltweit entwickelt werden. Zum anderen liegt dies an der hohen Fluktuation der Mitarbeiter in der IT-Branche, in der die durchschnittliche Verweildauer eines Mitarbeiters in einem Unternehmen zwischen drei und fünf Jahren liegt Abwärtskompatibilität Ein weiterer Grund für das Altern von Software liegt in der Anforderung begründet, Software-Systeme bei einem Releasewechsel abwärtskompatibel zu früheren Versionen zu entwickeln. 91 Eine solche Anforderung wird meistens aus Sicht des Marketings und des Vertriebs formuliert. Für viele Käufer ist die Möglichkeit, nach einem Update des Software-Systems auf gewohnte Weise weiter zu arbeiten, eine wichtige Entscheidungsgröße dafür, ein neues Release einzusetzen. Werden zu viele Änderungen umgesetzt, die Schulungen oder aufwändige Migrationen erfordern, besteht die Gefahr, dass Kunden sich nach Konkurrenzprodukten umsehen, da sie ohnehin einen erhöhten Aufwand durch den Versionswechsel haben werden. 92 Aus diesem Grund ist Abwärtskompatibilität wichtig. Dabei bedeutet die Abwärtskompatibilität, dass Schnittstellen zu älteren Versionen und deren Schnittstellen verträglich sein sollen. 93 So soll beispielsweise bei der Einführung neuer Dateiformate die Verarbeitung der bisherigen Dateiformate weiterhin unterstützt 90 Vgl. (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S. 389ff. 92 Vgl. (Hoffmann, 2008), S Vgl. (Vogel). 30

35 werden. Durch die Bereitstellung dieser Versionsverträglichkeit zu früheren Versionen wächst der Softwarecode in Bezug auf Schnittstellen permanent. Ein weiteres Problem, das die Abwärtskompatibilität mitbringt, besteht darin, dass nicht nur die Schnittstellen sondern auch die bisherige Verarbeitung beibehalten werden muss, und somit neue Ideen und Verbesserungen gehemmt werden Nachträgliche Portierung Auch die Anforderung, ein Softwaresystem nachträglich für mehrere Plattformen verfügbar zu machen, führt häufig zu einer Softwarefäulnis. Viele Softwaresysteme werden zunächst für eine bestimmte Systemplattform entwickelt. Ist die Software auf dieser Plattform erfolgreich, entsteht oftmals der Wunsch, diese auch auf weiteren Plattformen verfügbar zu machen, um neue Märkte zu erreichen. In der Entwicklungsphase werden jedoch zum Teil bestimmte Eigenschaften einer Plattform in die Entwicklung mit einbezogen, um die Performance zu verbessern. So kommt es vor, dass bestimmte Berechnungen auf einer Plattform ein anderes Ergebnis liefern, als auf der neuen. Wurden solche plattformspezifischen Eigenschaften ausgenutzt, müssen bei späteren Anpassungen für die neue Plattform zusätzliche Funktionen geschrieben werden, die diese Eigenschaften nachimplementieren. Weiterhin besteht die Gefahr, dass die notwendigen Anpassungen nicht alle entdeckt werden und sich so Fehler in die portierte Software einschleichen. Auch wenn keine Fehler durch die Portierung entstehen, kann Software dabei altern. Eine derartige Umstellung kann es z.b. erforderlich machen, die Architektur oder Aufteilung der Anwendung zu überarbeiten. Falls dies jedoch nicht geschieht und die alte, unpassendere Architektur weiter verwendet wird, ist die Software gealtert. 94 Vgl. (Hoffmann, 2008), S. 389ff. 31

36 3.2.6 Externe Einflüsse Neben der Softwarealterung durch Code-Anpassungen kann Software auch durch externe Faktoren altern. Damit ist sowohl die Änderung von Standards und Normen gemeint als auch die Änderung der Schnittstellen oder Funktionsweise anderer Systeme, die Schnittstellen für das Software-System bereit stellen oder das Software-System nutzen. Auch eingeschlossen sind Standards, die die Softwareentwicklung an sich betreffen, also Programmiervorgaben oder technische Weiterentwicklungen. Sich ändernde Standards und Normen wirken sich bei jeder Erweiterung der Software aus, da die Erweiterungen nach diesen neuen Vorgaben umgesetzt werden müssen. Bei einer späteren Code- Überprüfung kann festgestellt werden, dass der Code nicht mehr aktuellen Standards entspricht und somit Alterungserscheinungen aufweist, ohne zwangsweise modifiziert worden zu sein. Ändern sich externe Software-Systeme bzw. deren Schnittstellen, so besteht in den Fällen Handlungsbedarf, in denen eine Abwärtskompatibilität wie unter beschrieben vorliegt. Anderenfalls kann eine korrekte Verarbeitung nicht gewährleistet werden und ein kompletter Ausfall der Software kann die Folge sein. Auch in diesem Fall ist eine Code-Degeneration möglich, wenn die neuen Schnittstellen sich stark von den bisherigen unterscheiden, so dass die Befüllung dieser über neue Module erfolgt ohne ältere Module zu entfernen. 3.3 Erkennungsmerkmale alternder Software Um das Problem der Softwarealterung zu verstehen und ihm entgegen zu wirken, ist es zunächst wichtig, zu wissen, woran erkannt werden kann, dass Software gealtert ist. Das echte in Monaten und Jahren messbare Alter einer Software ist kein zuverlässiger Indikator für die Aussage, eine Software sei gealtert. Zwar kann eine Korrelation zwischen dem echten und dem qualitativen Alter der Software be- 32

37 stehen, doch immer gegeben ist diese Eigenschaft nicht. Vielmehr ist die Alterung der Software an mindestens einem von drei Merkmalen zu erkennen. Ein steigender Änderungsaufwand ist das erste Erkennungsmerkmal. Die Dauer von Änderungen an der Software steigt mit dem Grad der Softwarealterung. D.h. gleichartige Änderungen am Code benötigen bei junger Software weniger Zeit als bei gealterter. Damit einhergehend kann bei der Einarbeitung neuer Mitarbeiter in die Entwicklung der betrachteten Software die Softwarealterung tendenziell daran erkannt werden, dass die Einarbeitung unverhältnismäßig viel Zeit in Anspruch nimmt. 95 Qualitätseinbußen in der Wartung und Weiterentwicklung sind der zweite Bereich, in dem sich Softwarealterung ausdrückt. Jede Änderung kann meist auch bei gealterter Software implementiert werden, doch die Qualität ist dann nicht selten eingeschränkt. So können Änderungen am Code anfangs noch stark fehlerbehaftet sein und bedürfen mehrfacher Korrektur. Teilweise können Änderungen gar nur über Umwege implementiert werden, so dass Einschränkungen in der Bedienbarkeit, der Performance, der Transparenz oder auch dem Funktionsumfang in Kauf genommen werden müssen. 96 Als dritter Bereich ist die grundsätzliche Umsetzbarkeit betroffen. Die verheerendste Auswirkung der Softwarealterung ist eine Einschränkung der Machbarkeit. Wenn die Software einen sehr hohen Alterungsgrad hat, kann es sein, dass eine Anforderung sich nicht mehr implementieren lässt bzw. die Implementierung einer Anforderung einen grundlegenden Eingriff in die Anwendungsstruktur erfordert Vgl. (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S. 374, , 385 ff. 97 Vgl. (Hoffmann, 2008), S. 375 ff. 33

38 3.3.1 Unterstützung beim Erkennen der Alterung Wie in diesem Kapitel bereits erörtert wurde, ist der entscheidende Faktor, der Softwarealterung so bedeutend werden lässt, dass sie letzten Endes immer den Aufwand in die Höhe treibt, der bei Veränderungen an der Software investiert werden muss. Sei es der Weiterentwicklungs- oder auch der Wartungsaufwand. Für jede Änderung wird verhältnismäßig mehr Zeit benötigt, als bei nicht gealterter Software notwendig wäre. Es besteht die Möglichkeit, diesen erhöhten Aufwand festzustellen. Der Erkennung durch die Mitarbeiter selbst ist auf jeden Fall Beachtung zu schenken und ihre Bedeutung nicht zu unterschätzen. Die Entwickler, die regelmäßig an einer Software entwickeln, können gut beurteilen, wie es um die Alterung einer Software steht. Um ein Budget für die Ausführung von Maßnahmen gegen die Softwarealterung zu erhalten, kann es von Vorteil sein, neben der subjektiven Einschätzung der Mitarbeiter einen objektiveren Beurteilungsweg zu haben. Es bietet sich an, die Zeit, die Mitarbeiter mit der Weiterentwicklung und der Fehlerbehebung zubringen, festzuhalten. Im Idealfall sollte für jeden einzelnen Fehler festgestellt werden können, welches Modul betroffen ist und wie lange seine Behebung gedauert hat. Wenn diese Information kontinuierlich beobachtet wird, kann eine erste Abschätzung getroffen werden, wann Alterung sichtbar wird. Für außenstehende kann eine entsprechende Kennzahl gebildet werden, die beispielsweise den durchschnittlichen Fehlerbehebungsbedarf in einem Modul pro Quartal beschreibt. Kritisch zu bewerten ist dabei, dass jeder Fehler andere Ursachen haben kann und damit von Natur aus einen unterschiedlichen Bearbeitungsaufwand erfordert. Über einen entsprechend großen Zeitraum sollte sich diese Schwankung jedoch glätten, so dass eine Betrachtung auf Quartalsebene verlässlicher sein müsste als auf Wochenebene. Weiterhin ist diese Kennzahl vor allem von Bedeutung, wenn eine Software kontinuierlicher Weiterentwicklung unterliegt. Bei Software, an die kaum neue Anforderungen gestellt werden, wird die Anzahl 34

39 der Fehler mit der Zeit abnehmen, so dass auch die Grundgesamtheit an zu betrachtenden Fehlerbehebungsmaßnahmen schwindet. Dennoch können so ermittelte Kennzahlen eine wichtige Unterstützung bei der Darstellung der Auswirkungen der Alterung sein. Es sei noch angemerkt, dass schon vor dem Einsetzen der Alterung Gegenmaßnahmen ergriffen werden sollten. 3.4 Herleitungskette der Softwarealterung Wie die vorangegangenen Kapitel gezeigt haben, gibt es vielfältige Ursachen und Erkennungsmerkmale von Softwarealterung. Bei genauerer Betrachtung offenbart sich eine Verkettung von Ursache-Wirkungs-Beziehungen, an deren Ende die Softwarealterung steht. Fehler! Verweisquelle konnte nicht gefunden werden. zeigt diese Verkettung. 35

40 Abbildung 3: Ursache-Wirkungs-Zusammenhang der Softwarealterung 98 Die Abbildung zeigt alle den Autoren bewussten Wirkungszusammenhänge an. Weitere Verkettungen sind denkbar. Doch auch so wird deutlich, wie stark der Einfluss von Softwarealterung auf die Softwarequalität ist. Am Anfang steht immer einer Modifikation der betrachteten Software bzw. ein Einfluss, den der Entwicklungsprozess erfährt (Abbildung 3, linker Bereich). Bei den Modifikationen kann es sich um eine Fehlerbehebung, eine funktionelle Erweiterung, das Erschaffen von Abwärtskompatibilität oder aber auch eine Portierung der Software auf eine andere Plattform handeln. Ein Einfluss auf den Entwicklungsprozess kann ein Personalwechsel bei den beteiligten Personen sein oder aber auch ein unternehmensinterner Einfluss. Die eben genannten Einflüsse auf die Software oder ihre Entwicklung können in eine Vielzahl von positiven wie negativen Folgen münden. Für die Betrachtung der Softwarealterung sind nur die negativen Folgen von Bedeutung (Abbildung 3,mittlerer Bereich). Diese können die Code-Verdopplung, die Entstehung eines Architektur- oder Stil-Mixes, die Entstehung von Fehlern und ungenutztem Code sowie die Entstehung von systemspezifischem Code sein. Auf diese Auswirkungen und warum sie für die Qualität so bedeutend sind, wurde in Kapitel 3.2 eingegangen. Das Einsetzen der Softwarealterung erfolgt als unmittelbare Folge dieser Software-Auswirkungen. Da, wie bereits in Kapitel 3.1 erwähnt, die Alterung von Software kurz als Degradierung der Qualitätsparameter bezeichnet wird, äußert sie sich in einem negativen Einfluss auf die Qualitätskriterien (Abbildung 3, rechter Bereich). Dieser Einfluss kann alle Qualitätskriterien betreffen: Funktionalität, Zuverlässigkeit, Effizienz, Benutzbarkeit, Übertragbarkeit, Änderbarkeit, Testbarkeit, Transparenz. 98 Eigene Darstellung. 36

41 4 Maßnahmen gegen Softwarealterung 4.1 Refactoring Wie in den vorangegangen Kapiteln aufgezeigt, ist eine langlebige Software ständigen Erweiterungen und Änderungen in ihrer Funktionalität und dem Programmcode unterworfen. Diese Änderungen führen zu Degenerationen, die von Zeit zu Zeit behoben werden sollten. Eine Möglichkeit, dies durchzuführen, besteht in dem Prozess des Refactoring. Refactoring beschreibt Maßnahmen zur Erneuerung der inneren Struktur eines Software-Systems 99. Bei diesen Maßnahmen sollen Änderungen im äußeren Verhalten und Aussehen des Systems vermieden werden. Mit anderen Worten soll mit dem Refactoring zwar der Softwarecode verbessert werden, die Benutzer sollen dies jedoch beim Gebrauch der Software nicht bemerken. Nach außen bleibt die Software gleich, es finden keine Funktionserweiterungen statt. Das Prinzip des Refactorings geht auf Kent Beck und Howard Cunningham zurück, die in den 1980ern verschiedene Möglichkeiten beschrieben den Code lesbarer zu machen. Populär machte es Martin Fowler. 100, 101 Refactoring geht weiter als einfache Clean-up Arbeiten, die ein Entwickler von Zeit zu Zeit durchführt um den Code lesbarer zu machen, da es die gesamte Struktur einer Anwendung verändert. Mit den Maßnahmen des Refactorings werden mehrere Qualitätsmerkmale verbessert. So lässt sich durch einen aufgeräumten Code die Transparenz für den Entwickler erhöhen. Auch werden hierdurch die Wartbarkeit und die Erweiterbarkeit verbessert. 102 Auch Martin Fowler beschäftigte sich in dem Buch Refactoring mit dieser Materie. Dort beschreibt er verschiedenste Techniken, um degenerierten Code zu erkennen und wie diese Code-Degenerationen behoben werden können. Dabei 99 (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S. 396f. 101 Vgl. (Fowler, 2009), S. 51f. 102 Vgl. (Fowler, 2009), S. 53ff. 37

42 sieht er Refactoring als Methode, schlechtes und verunstaltetes Softwaredesign in einen gut designten und strukturierten Code zu überführen. 103 Diese Techniken lassen sich in sechs Bereiche zusammenfassen. Diese sind: Methoden zusammenstellen, Eigenschaften zwischen Objekten verschieben, Daten organisieren, Bedingte Ausdrücke vereinfachen, Methodenaufrufe vereinfachen und Umgang mit Generalisierung. In den folgenden Kapiteln werden die einzelnen Bereiche betrachtet Methoden zusammenstellen Unter den Bereich der Zusammenstellung von Methoden verbergen sich Maßnahmen, den Softwarecode auf Methodenebene neu zu strukturieren. Dabei stehen zum einen überflüssige und unverständliche Variablen auf dem Prüfstand. Zum anderen gehören hier Techniken dazu, um die Methodenstruktur zu verbessern. Diese Techniken beziehen sich auf Code-Änderungen innerhalb einer Klasse Eigenschaften zwischen Objekten verschieben Die Refactoring-Maßnahmen im Bereich des Verschiebens von Eigenschaften zwischen Objekten sind für Programme mit vielen Modulen relevant, da sie auf den Aufbau von Modulabhängigkeiten abzielen. Das Hauptaugenmerk liegt dabei auf der Frage, ob eine Methode noch an der richtigen Stelle steht. Ist dies nicht der Fall, bieten diese Maßnahmen einen Ausweg. 103 Vgl. (Fowler, 2009), S. XVf. 104 Vgl. (Fowler, 2009), S Vgl. (Fowler, 2009), S. 101ff. 38

43 Ebenfalls zeigen diesen Maßnahmen Möglichkeiten auf, auf welche Weise überfrachtete Klassen neu strukturiert werden können. Diese Techniken erhöhen die Transparenz einer Klasse und erleichtern somit die Wartung Daten organisieren Ein weiterer Bereich des Refactoring ist das Organisieren von Daten. Hier geht es darum, wie Daten, also Variablen und Objekte, organisiert sind. Mit anderen Worten, auf welche Weise wird auf diese Daten zugegriffen. Für übersichtlichen und einheitlich aussehenden Code sollte auf Daten immer gleichartig zu gegriffen werden. Techniken die zu diesem Bereich gehören zeigen, wie unstrukturierte Daten überarbeitet werden können. Zum anderen zeigen diese Techniken wie Variablen, die bisher auf eine falsche Art genutzt werden, durch neue Datenstrukturen ersetzt werden sollten Bedingte Ausdrücke vereinfachen Refactoringmaßnahmen aus dem vierten Bereich sollen die Komplexität von Prüfungen innerhalb einer Methode verringern. Komplexe Prüfungen und tief verschachtelte Methoden werden mit jeder Verschachtelungstiefe unübersichtlicher, und somit für Entwickler intransparent. Um diese Komplexität zu reduzieren, sollten Prüfungen, die aus mehreren Teilprüfungen bestehen, extrahiert werden. Sind innerhalb aller Stränge gleiche Code-Fragmente enthalten, also werden Anweisungen immer ausgeführt, sollten diese aus den einzelnen Strängen ausgelagert und hinter die Fallunterscheidung verschoben werden Vgl. (Fowler, 2009), S. 167ff. 107 Vgl. (Fowler, 2009), S. 187ff. 108 Vgl. (Fowler, 2009), S. 261ff. 39

44 4.1.5 Methodenaufrufe vereinfachen Um Methodenaufrufe zu vereinfachen, beschreibt Martin Fowler verschiedene Maßnahmen. Diese Refactoringtechniken sollen das Zusammenspiel einzelner Methoden transparenter machen. Außerdem soll mit diesen Techniken die Aufgabe einer Methode für Entwickler schneller erkennbar werden. Dies kann durch Umbenennung des Methodenkopfes und durch bessere Kommentierung der Methoden geschehen. Neben der Transparenz soll bei der Vereinfachung von Methodenaufrufen die Zahl der Übergabeparameter pro Methodenaufruf reduziert werden. So wird die Wartbarkeit erhöht und Methoden lassen sich einfacher Wiederverwenden Umgang mit Generalisierung Refactoringmaßnahmen zum Umgang mit Generalisierung spielen lediglich in den objektorientierten Programmiersprachen eine Rolle. Hier geht es darum, innerhalb von Vererbungshierarchien Objekteigenschaften an eine besser passende Stelle zu verschieben. Aber auch das verbergen von Funktionen hinter Interfaces wird hinter dieser Refactoringart behandelt Refactoring am Beispiel Um die Maßnahmen des Refactoring zu verdeutlichen, soll an dieser Stelle auf ein Beispiel im Bereich Methoden zusammenstellen zurückgegriffen werden. Es erläutert anhand von Pseudocode, wie eine Methode verbessert und vereinfacht werden kann. 109 Vgl. (Fowler, 2009), S. 297ff. 40

45 Abbildung 4: Codebeispiel Rechner. Die in Abbildung 4 dargestellte Methode Rechner beinhaltet die vier Grundrechenarten. Am Anfang der Methode werden einzeln die Übergabeparameter geprüft, anschließend das jeweilige Ergebnis berechnet und das Ergebnis wird sofort ausgegeben. Wird in den ersten Prüfungen ein Fehlen von einem Übergabeparameter festgestellt, wird anstelle eines Ergebnisses immer der gleiche Fehler ausgegeben. Diese Methode ist aus mehreren Gründen nicht gut durchdacht. Zum einen wird die Untermethode schreiben() achtmal aufgerufen. Zum anderen entsteht durch die große Verschachtelungstiefe ein schlecht lesbarer Code mit vielen Klammern, die eine Wartung erschweren. Eine Möglichkeit diese Methode zu verbessern besteht darin, die Prüfungen zu extrahieren und wie in Abbildung 5 ersichtlich in eine eigene Untermethode auszulagern. 41

46 Abbildung 5: Codebeispiel nach Refactoringmaßnahmen. Hierfür wird geprüft, welche Bestandteile einer Methode nicht direkt mit der Funktionsbeschreibung der Methode zusammenhängen und welche Teile einer großen Methode ohne Schwierigkeiten ausgelagert werden können. Um die hohe Aufrufanzahl der schreiben()-methode zu verringern und so bei Anpassungen in der Aufrufart zu verringern, kann das Ergebnis der Berechnungen zunächst in einer aussagekräftigen Variablen gespeichert werden, die nach der Switch-Anweisung der schreiben()-methode übergeben wird. 4.2 Redesign Das Redesign einer Software beschreibt die partielle oder vollständige Neuimplementierung einer Software 110. Dieser Schritt wird in Erwägung gezogen, wenn eine Weiterentwicklung des bestehenden Systems nicht mehr zweckmäßig erscheint. Im Gegensatz zum Refactoring werden beim Redesign einer 110 (Hoffmann, 2008), S

47 Software nicht nur softwareintern Anpassungen vorgenommen, sondern auch die äußeren Schnittstellen auf den Prüfstand gestellt 111. Entsprechend können Verbesserungen in der Funktionsweise des Software-Systems erzielt werden. Sie lassen sich mit Refactoring Maßnahmen (siehe Kapitel 4.1) nicht erreichen, da hier die Funktionsweise nicht verändert wird. Schwierig zu beantworten ist die Frage nach dem richtigen Zeitpunkt, eine Software neu zu implementieren. Denn wenn sich erkennen lässt, dass Software gealtert ist, ist es im Grunde bereits zu spät, mit der Neuentwicklung zu beginnen. Es lässt sich prinzipiell festhalten, dass zum Zeitpunkt der Etablierung eines Systems am Markt bereits das Redesign geplant und umgesetzt werden sollte. So ist die neue Software fertig gestellt, wenn die ältere Version größere Alterserscheinungen aufweist. 112 Ein Risiko beim frühzeitigen Beginn des Redesigns kann das Auftreten von Ressourcenengpässen sein. Auf der einen Seite müssen Mitarbeiter abgestellt werden, die sich mit der Neuentwicklung befassen. Auf der anderen Seite müssen jedoch genügend Mitarbeiter für die Wartung des bestehenden Systems beibehalten werden. Nur so lässt sich die Stabilität des Systems gewährleisten, um Kunden nicht zu verärgern. Um das Redesign durchzuführen, können zwei verschiedene Ansätze verfolgt werden, der Ansatz der Rückwärtskompatibilität und den des Second Systems. Der Ansatz der Rückwärtskompatibilität belässt Codefragmente und Schnittstellen des bestehenden Systems bestehen, um dem Kunden eine schnellere Eingewöhnung zu ermöglichen. Für den Hersteller bedeutet dieser Kundenvorteil allerdings einen Nachteil, da der Code stetig wächst, um die Rückwärtskompatibilität (siehe Kapitel 3.2.4) zu erhalten. Jede Kompatibilitätsebene, die erhalten bleiben soll, erhöht den Aufwand für Wartungen und Tests. 111 (Hoffmann, 2008), S Vgl. (Hoffmann, 2008), S

48 Eine andere Möglichkeit des Redesigns besteht darin, ein komplett neues System (Second System) zu entwickeln. In diesem Fall wird bewusst auf Abwärtskompatibilität verzichtet, um sich von Fehlern und bisherigen Vorgaben zu lösen. Dieses Redesign ist aus Sicht des Herstellers das einfacher zu handhabende Vorgehen. Es ermöglicht, das System auf Grund der Erkenntnisse aus dem Vorgängersystem alterungsresistenter zu gestalten. Ebenfalls kann ein solches Vorgehen die Zahl der Schnittstellen verringern und somit die Transparenz und die Wartbarkeit erhöhen. Da ein komplett neues System dem Kunden einen hohen Einarbeitungsaufwand abverlangt, besteht die Möglichkeit, im neuen System eine Umgebung zu schaffen, in der die älteren Versionen lauffähig sind. Diese Umgebung wird auch als Kompatibilitätsumgebung bezeichnet, da sie eine Rückwärtskompatibilität simuliert. Dies bietet dem Kunden die Möglichkeit sowohl das bestehende als auch die Vorteile des neuen Systems nutzen. So kann eine Umstellung nach einem Individuellen Zeitplan vorgenommen werden. Gleichzeitig werden Schnittstellen zur Gewährleistung der Kompatibilität auf ein Minimum reduziert Einsatz eines Qualitätsmanagements Der folgenden Grafik kann entnommen werden, welche Qualitätssicherungsmaßnahmen sich auf welche Qualitätsmerkmale positiv auswirken. Die Erreichung der Qualitätsmerkmale ist ein erfolgsversprechender Schritt zur Verlangsamung des Alterungsprozesses von Software: 113 Vgl. (Hoffmann, 2008), S

49 Abbildung 6: Einfluss der Qualitätssicherung auf die Qualitätsmerkmale 114 Die konstruktive Qualitätssicherung befasst sich mit Vorgaben zur Vorgehensweise in der Entwicklungsphase. So kann die Bestimmung von Richtlinien oder die Entscheidung für eine einheitliche Programmiersprache dafür sorgen, dass das Qualitätsmerkmal der Übertragbarkeit besser erfüllt wird. Es können beispielsweise Vorgaben gemacht werden, die den Grad des allgemein gehaltenen Codes festlegen, der wiederum die Portabilität vereinfacht. Auch wenn sich innerhalb eines Unternehmens auf bestimmte Programmiersprachen geeinigt wird, steigert das die Übertragbarkeit, denn es müssen keine Datentypen konvertiert werden, um in eine neue Hardwareumgebung zu passen. 114 Eigene Darstellung. 45

50 Auch die Transparenz lässt sich durch den Einsatz konstruktiver Qualitätssicherung erhöhen. Indem Vorgaben zur Programmiersprache, zur Codeformatierung und zur Lösung von Problemsituationen bzw. Anwendung von Software- Pattern gemacht werden, steigt die Nachvollziehbarkeit des Codes. Wird zum Beispiel in Richtlinien und Programmiervorgaben hinterlegt, wie bestimmte Situationen zu handhaben sind, kann im Rahmen der konstruktiven Qualitätssicherung festgestellt werden, ob der Quellcode durch die vorhandenen Dokumentationen angemessen verständlich ist und ob die Richtlinien eingehalten wurden. Einhergehend mit der Transparenz kann die konstruktive Qualitätssicherung auch die Änderbarkeit bzw. Wartbarkeit erhöhen. Indem wie zuvor beschrieben die Transparenz steigt aber auch Vorgaben zur Dokumentation und Kommentierung gemacht werden, kann ein Entwickler schneller in den bestehenden Code einsteigen. Die Kommentare an den Funktionen etc. helfen, den Einstieg zu erleichtern und auch schneller Stellen zu finden, an denen Anpassungen vorgenommen werden müssen. Dokumentation kann beispielsweise den Gesamtüberblick über ein Software-System ermöglichen. Der Softwaretest kann die Funktionalität einer Software steigern. Indem der Test auf die Software ausgelegt und konsequent durchgeführt wird, können mehr Fehler und Feinheiten aufgedeckt werden. Dafür ist es notwendig, sich eingehend mit der entstehenden oder weiterentwickelten Software zu befassen, um auch geeignete Testfälle vollständig zu erfassen, und beispielsweise alle möglichen Eingabewerte und auch die nicht zugelassen Eingabewerte zu prüfen. Der zweite positive Aspekt des Softwaretests ist die Möglichkeit, die Zuverlässigkeit zu steigern. Es können verschiedene Szenarien entworfen werden, die Extrembedingungen enthalten, die die Zuverlässigkeit beeinträchtigen können. Diese Szenarien können in Tests nachgebildet und so verprobt werden. Ein weiterer Pluspunkt des Softwaretests ist, dass eine Steigerung der Effizienz durch Lasttests möglich ist. Es fällt nicht erst im Produktiveinsatz beim Kunden 46

51 auf, dass eine Software mit einer bestimmten Auslastung nicht zurechtkommt. Dieses Verhalten kann simuliert und bei nicht zufriedenstellenden Ergebnissen korrigierende Maßnahmen ergriffen werden. Der Softwaretest kann auch die Benutzbarkeit steigern. Beim Ausführen der Testfälle kann sich der Tester in den Kunden, der die Software abnimmt, hineindenken und so noch Impulse zur Steigerung der Bedienbarkeit geben. Möglich ist dies, weil der Tester mehr Distanz zur Software-Implementierung hat und unter anderem die Verwendung der Software so vornehmen soll, wie der Kunde es im Endeffekt auch tun würde. Die statische Analyse kann die Übertragbarkeit verbessern, indem beim manuellen Prüfen des Quellcodes bereits darauf geachtet wird, dass der Anteil Plattformspezifischen Codes das Mindestmaß nicht übersteigt. Auch die Wartbarkeit lässt sich mit den Mitteln der statischen Analyse steigern. Direkt bei der Prüfung des Quellcodes können unzureichende Dokumentationen an den einzelnen Funktionen aufgedeckt werden. Die Methoden der statischen Analyse können die Testbarkeit verbessern, indem vor dem eigentlichen Softwaretest der Quellcode manuell geprüft wird. Da hier schon erste grobe Fehler ausgemerzt werden können, können die Tests früher auf einem höheren Niveau ausgeführt werden, ohne über grobe Fehler zu stolpern. Der in der Regel fest definierte Testzeitraum kann so besser genutzt werden. Die Tester können sich auch mit den Feinheiten der Funktionalitäten auseinandersetzen, da die Software an sich durch die statische Analyse bereits lauffähig bzw. lauffähiger ist. Die Erhöhung der Transparenz ist auch eine Stärke der statischen Analyse. Wenn der Quellcode per Review oder Walkthrough geprüft wird, und dem Prüfer auffällt, dass er den Quellcode nicht nachvollziehen kann, ist die vorhandene Transparenz nicht ausreichend. Es besteht so jedoch rechtzeitig die Möglichkeit, die Transparenz zu erhöhen. Auch die Dokumentation der Anforderungen und wie diese umgesetzt werden, erhöht die Transparenz. Es ist aus den Dokumenten ersichtlich, was umgesetzt wurde. 47

52 Mit den Methoden der Softwareverifikation kann ein Schritt in zur Verbesserung der Funktionalität unternommen werden. Es können Algorithmen implementiert werden, die mögliche Eingaben automatisch prüfen und die Reaktion der Software protokollieren. So muss ein Tester nicht jede Eingabe selbst tätigen und die Reaktion der Software festhalten, sondern kann sich auf das Entwerfen von Testfällen und die Ergebnisse der algorithmisch ausgeführten Testfälle konzentrieren. Die Prozessqualität wirkt sich nicht speziell auf ein Merkmal aus, sondern liefert eher allumfassend die Kontrolle sämtlicher Maßnahmen, die eine geregelte Entwicklung eines Software-Produkts in Form eines definierten Prozesses gewährleisten 115. Das Qualitätsmanagement kann als Methode gesehen werden, den Alterungsprozess einer Software zu verlangsamen, in dem vorbeugend Maßnahmen zur Qualitätssicherung durchgeführt werden. Wird der Fokus bereits in der Planungsphase des Projekts auch auf die Softwarealterung gelegt, können proaktiv die oben beschriebenen Punkte berücksichtigt werden. Ist eine Software qualitativ hochwertig, altert sie auch langsamer. Denn die Erkennungsmerkmale alternder Software (siehe Kapitel 3.3) und auch die Gründe (siehe Kapitel 3.2), warum Software altert, können über Qualitätsmaßnahmen eingedämmt werden. 115 (Hoffmann, 2008), S

53 5 Fazit Abschließend kann gesagt werden, dass der Bereich der Softwarealterung kein neuer Begriff ist, aber dennoch ein Begriff, dem häufig zu wenig oder zu spät Beachtung geschenkt wird. Die Softwarealterung ist ein bedeutendes Phänomen, da sie auf alle Kriterien der Softwarequalität Auswirkungen hat. Oft wird eine Software lange nur um die notwendigen Funktionen erweitert, ohne gleichzeitig zu prüfen, ob andere Funktionen dafür wegfallen oder alte und neue Funktionen zusammengefasst werden können. Ein weiteres Problem spiegelt sich im Ressourcenmangel wider. In der Regel fehlen Zeit, Budget und Personal, um die laufende Software zu warten und gleichzeitig an einer neuen Implementierung zu arbeiten. Auch Tätigkeiten zur Verlangsamung des Alterungsprozesses einer Software, die bereits während der Entwicklungsphase durchgeführt werden können, bleiben oft aus Zeitmangel aus. Es wurde aufgezeigt, dass die Messung von Softwarequalität nicht einfach ist, da sie von vielen Kriterien beeinflusst wird, die einzeln betrachtet bereits schwer messbar sind. Ebenso verhält es sich mit der Softwarealterung. Sie kann sich in einem nachlassen aller Qualitätskriterien manifestieren und ist nur schwer greifbar. Es ist wichtig, mit dem Fokus auf die Verlangsamung der Alterung einer Software proaktiv den Programmierstil, Programmierrichtlinien, Testvorgehen und ähnliches im Vorhinein zu planen und während der Entwicklung immer wieder kritisch zu überprüfen. Ein Unternehmen muss sich über die Konsequenzen im Klaren sein, die eintreten, wenn nicht ab Beginn der Planungsphase einer neuen Software auch das Thema Softwarealterung berücksichtigt wird. Die in der Einleitung gesteckten Ziele, den Bereich der Softwarealterung näher zu betrachten und in einen Zusammenhang zum Thema Softwarequalität zu bringen, sind erreicht worden. Es wurden die drei Methoden Refactoring, Redesign und Umsetzung eines Qualitätsmanagements betrachtet und damit drei 49

54 Wege aufgezeigt, dem Alterungsprozess entgegenzuwirken bzw. ihn durch konsequente Neuentwicklung gar nicht erst aufkommen zu lassen. 50

55 6 Literaturverzeichnis Qualitätsdatenbank, Stichwort Qualitätsmanagement. (11. Januar 2003). Abgerufen am 20. September 2011 von Qualitätsdatenbank, Stichwort Qualitätsplanung. (08. Januar 2003). Abgerufen am 23. September 2011 von Qualitätsdatenbank, Stichwort Qualitätsverbesserung. (09. Januar 2003). Abgerufen am 23. September 2011 von Qualitätsdatenbank, Stichwort Qualitätssicherung. (31. Januar 2004). Abgerufen am 23. September 2011 von Wirtschaftslexikon24, Stichwort Qualitätsplanung. ( ). Abgerufen am 23. September 2011 von g.htm Testmetriken. (2011). Abgerufen am 29. September 2011 von Balzert, H. (2009). Lehrbuch Der Softwaretechnik: Basiskonzepte Und Requirements Engineering (3 Ausg., Bd. 1). Heidelberg: Springer. Bommer, C. u. (2008). Softwarewartung - Grundlagen, Management und Wartungstechniken (1. Ausg.). Heidelberg: dpunkt-verlag. Fowler, M. u. (2009). Refactoring, Ruby Edition. Boston: Pearson Education. Frühauf, K. u. (2002). Softwre-Projektmanagement und -Qualitätssicherung (4. Ausg.). Zürich: vdf Hochschulverlag AG an der ETH Zürich. Gabler Wirtschaftslexikon, Stichwort Effizienz. (kein Datum). Abgerufen am 24. September 2011 von Gall, H. (2006). Software Wartung und Evolution. Zürich. Geiger, W. u. (2005). Handbuch Qualität (4. Auflage Ausg.). Wiesbaden: Vieweg+Teubner. Grechenig, T. u. (2009). Softwaretechnik: Mit Fallbeispielen aus realen Entwicklungsprojekten (1. Ausg.). München: Pearson Studium. 51

56 Hoffmann, D. W. (2008). Software-Qualität (1. Ausg.). Heidelberg: Springer. Klempien, D. ( ). Controlling-Portal.de Die Nutzwertanalyse. Abgerufen am von Controlling-Portal.de Die Nutzwertanalyse: Nutzwertanalyse.html Kletzin. (2007). Hochschule Wismar. Abgerufen am 24. September 2011 von Qualitaet.pdf Liggesmeyer, P. (2009). Software-Qualität - Testen, Analysieren und Verifizieren von Software (2. Auflage Ausg.). Heidelberg: Spektrum Akademischer Verlag. Masak, D. (2010). Der Architekturreview: Vorgehensweise, Konzepte und Praktiken. Heidelberg: Springer. Patel, N. ( ). engadget.com iphone OS 4 renamed ios 4, launching June 21 with 1500 new features. Abgerufen am von engadget.com iphone OS 4 renamed ios 4, launching June 21 with 1500 new features: renamed-ios-gets-1500-new-features Patzak, G. u. (2010). Projektmanagement (4. Ausg.). Wien: LINDE Verlag. Paul Hemetsberger IT-Dienstleistungen. (kein Datum). dict.cc qualitas Wörterbuch Latein-Deutsch. Abgerufen am von dict.cc qualitas Wörterbuch Latein-Deutsch: Schneider, K. (2007). Abenteuer Softwarequalität - Grundlagen und Verfahren für Qualitätssicherug und Qualitätsamangement (1. Ausg.). Heidelberg: dpunkt.verlag. Vigenschow, U. (2010). Testen von Software und Embedded Systems (2. Auflage Ausg.). Heidelberg: dpunkt.verlag. Vogel, M. (kein Datum). lexikon.martinvogel.de. Abgerufen am von Voigt, K.-I. (kein Datum). Gaber Wirtschaftslexikon, Stichwort Qualitätssicherung, Abschnitt Teilfunktionen. Abgerufen am 23. September 2011 von 52

57 7 Anlagenverzeichnis ANLAGE 1: QUALITÄTSDATENBANK, STICHWORT QUALITÄTSPLANUNG... V ANLAGE 2: QUALITÄTSDATENBANK, STICHWORT QUALITÄTSMANAGEMENT... VII ANLAGE 3: WIRTSCHAFTSLEXIKON24, STICHWORT QUALITÄTSPLANUNG... VIII ANLAGE 4: GABLER WIRTSCHAFTSLEXIKON, STICHWORT QUALITÄTSSICHERUNG, ABSCHNITT TEILFUNKTIONEN... IX ANLAGE 5: QUALITÄTSDATENBANK, STICHWORT QUALITÄTSSICHERUNG... X ANLAGE 6: TESTMETRIKEN... XI ANLAGE 7: QUALITÄTSDATENBANK, STICHWORT QUALITÄTSVERBESSERUNG... XII ANLAGE 8: LEXIKON.MARTINVOGEL: ABWAERTSKOMPATIBEL...XIV ANLAGE 9: DICT.CC QUALITAS WÖRTERBUCH LATEIN-DEUTSCH...XV ANLAGE 10: DIE NUTZWERTANALYSE...XVI ANLAGE 11: IPHONE OS 4 RENAMED IOS 4, LAUNCHING JUNE 21 WITH 1500 NEW FEATURES...XVII IV

58 Anlage 1: Qualitätsdatenbank, Stichwort Qualitätsplanung V

59 VI

60 Anlage 2: Qualitätsdatenbank, Stichwort Qualitätsmanagement VII

61 Anlage 3: Wirtschaftslexikon24, Stichwort Qualitätsplanung VIII

62 Anlage 4: Gabler Wirtschaftslexikon, Stichwort Qualitätssicherung, Abschnitt Teilfunktionen IX

63 Anlage 5: Qualitätsdatenbank, Stichwort Qualitätssicherung X

64 Anlage 6: Testmetriken XI

65 Anlage 7: Qualitätsdatenbank, Stichwort Qualitätsverbesserung XII

66 XIII

67 Anlage 8: lexikon.martinvogel: abwaertskompatibel XIV

68 Anlage 9: dict.cc qualitas Wörterbuch Latein-Deutsch XV

69 Anlage 10: Controlling-Portal.de Die Nutzwertanalyse XVI

70 Anlage 11: engadget.com iphone OS 4 renamed ios 4, launching June 21 with 1500 new features XVII