Vergleich von Fagan-Inspektionen und werkzeuggestützter statischer Codeanalyse

Inhalt

1. Einleitung

2. Grundlagen
2.1. Qualitätsmanagement
2.2. Fehler
2.2.1. Definition Fehlerbegriff
2.2.2. Fehlerklassifikation nach Schwere
2.2.3. Fehlerklassifikation nach Typ
2.3. Metriken
2.4. Programmierstandards

3. Grundlagen der statischen Analyse
3.1. Automatisierte statische Analyse
3.1.1. Token- und Bug-Pattern-Analyse
3.1.2. Programm-, Kontroll- und Datenflussanalyse
3.1.3. Abstrakte Interpretation
3.2. Fagan-Inspektionen
3.2.1. Inspektionsanfrage
3.2.2. Planung
3.2.3. Kickoff-Meeting
3.2.4. Individuelle Prüfung
3.2.5. Logging-Meeting
3.2.6. Edit
3.2.7. Follow up
3.2.8. Exit

4. Studienbeschreibung
4.1. Forschungsfragen
4.2. Studiendesign und -implementierung
4.2.1. Das Unternehmen TomTec
4.2.2. Arbeitsumgebung
4.2.3. Akquise der Analysewerkzeuge
4.2.4. Studienimplementierung
4.3. Studienobjekte
4.3.1. Statische Analysewerkzeuge für C++
4.3.2. Das Softwareprodukt „ Quonos “

5. Fallstudie
5.1. Vorbereitungen
5.2. Studie 1: Analyse des Gesamtprojektes
5.2.1. Vorbemerkung
5.2.2. Ergebnisse
5.3. Studie 2: Fagan-Inspektion
5.3.1. Bericht der Inspektion
5.3.2. Ergebnisse
5.4. Studie 3: Vergleich der Ergebnisse im Detail
5.4.1. Vorbemerkung
5.4.2. Ergebnisse
5.5. Validitätsrisiken
5.5.1. Designfehler
5.5.2. Interne Fehler
5.5.3. Externe Fehler

6. Integration von automatischer Codeanalyse in Fagan-Inspektionen
6.1. Integrationsvorschläge
6.2. Bewertung der Vorschläge

7. Zusammenfassung und Ausblick

8. Anhang
8.1. Weitere Werkzeuge
8.2. Checklisten der Inspektion
8.3. Meinungen von Entwicklern
8.3.1. Von den Inspektoren
8.3.2. TomTec Developer Days

9. Literatur

1.Einleitung

Motivation

Software spielt, meist vollkommen unbemerkt, eine immer wichtigere Rolle in unserem Leben und damit auch ihre Fehler. Viele dieser Fehler werden von uns im Alltag gar nicht mehr wahr genommen, manche sind erheiternd und schnell wieder vergessen, andere wiederum folgenlose Ärgernisse wie beispielsweise die zahlreichen „Bluescreens“ großer Werbetafeln, Bank- und Fahrkartenautomaten. Für die Hersteller bleiben diese oft ohne Konsequenz, können aber auch schnell zum Verlust von Kundschaft führen.

Weniger erheiternd, sondern - zumindest für die Verantwortlichen - äußerst ernüchternd sind Softwarefehler, die direkte finanzielle Schäden verursachen. Hierfür gibt es viele bekannte Beispiele, wie die Explosion einer Ariane 5 Rakete im Jahre 1996, den Verlust des Mars Surveyor Orbiters der NASA 1999, das berühmte „Jahr 2000 Problem“ oder seit 2004 die Software A2LL^[1] zur Erfassung und Verwaltung von finanziellen Leistungen für Empfänger des „Arbeitslosengeldes II“ in der Bundesrepublik Deutschland.

Weniger bekannt sind Fälle, in denen Menschen aufgrund eines Softwarefehlers zu Schaden oder zu Tode kamen. Bis zum Jahr 2000 wurden 81 durch Software verursachte Todesfälle und 286 Mal akute Lebensgefahr für Menschen registriert[1]. Die Einzelaufschlüsselung dieser Daten ergibt, dass gemeinsam mit der zivilen Luftfahrt die Medizintechnik mit jeweils 17 Todesfällen Spitzenreiter in diesem Gebiet ist.

Traurige Berühmtheit erlangte das Bestrahlungsgerät Therac-25 der kanadischen Firma AECL, dessen fehlerhafte Software in den Jahren 1985 und 1986 mindestens sechs Un- fälle mit Todesfolge verursachte. Die Steuerungssoftware dieses Gerätes bestand aus - im Vergleich zu aktuellen Programmen - nur ca. 20 000 Zeilen. Die Software in moder- nen Herzschrittmachern oder Infusionspumpen dringt schnell in Größenordnungen von 80 000 bzw. 170 000 Zeilen vor, die von aufwändigeren Gerätschaften kann aus einer Million Zeilen Code oder mehr bestehen. [32, 33]

Nicht zuletzt gibt es noch ein weiteres, nicht zu unterschätzendes Problem fehlerbehafteter Software, das in der immer vernetzteren Welt zunehmend wichtig wird: Weniger Fehler sind gleichbedeutend mit weniger Ansatzpunkten für Angriffe auf die Software, also weniger Sicherheitslücken.[11]

Neben vielen anderen Verfahren der Qualitätssicherung stellt die statische Codeanalyse eine Möglichkeit dar, Fehler in Software zu finden. In Anbetracht immer größer werden- der Softwareprojekte und zunehmender Verbreitung von Qualitätsmanagement (QM) im Softwareentwicklungsprozess gewinnt die statische Analyse zudem an Bedeutung, da sich u. a. branchenspezifische, gesetzliche Auflagen in Deutschland, wie die DIN EN 62304 in der Medizintechnik, für die Nutzung der statischen Analyse aussprechen und sich damit hinter die amerikanische FDA^[2] stellen, die die Verwendung der statischen Analyse schon seit Jahren empfiehlt. [44, 45, 49]

Problem

Als Qualitätskriterium für gute Software gilt eine Fehlerrate von weniger als einem Fehler pro 100 Zeilen Code[27], eine Rate, die sich nur unter großem Aufwand erreichen lässt. Es liegt in der Natur des Menschen, nicht fehlerfrei zu arbeiten, daher lassen sich Fehler nicht vollständig vermeiden. Auch die Suche nach Fehlern ist aufwändig und lässt sich weder mit Erfolgsgarantie noch kostengünstig durchführen, die Auswahl möglicher Verfahren zur Fehlersuche erweist sich als kompliziert. Die Möglichkeiten der statischen Codeanalyse sind vielen Qualitätsmanagern nicht bekannt.

Die letzte große Veröffentlichung zu Fagan Inspektionen stammt aus dem Jahr 1993 [27], zu statischen Analysewerkzeugen existieren zwar vergleichende Studien für Java (beispielsweise[7],[12] oder[14] ), jedoch gibt es keine Veröffentlichungen, die aktuelle Analysewerkzeuge für C++ vergleichen und sie den Ergebnissen von Fagan-Inspektionen gegenüberstellen. Es ist unbekannt, welche Fehler die Techniken aufspüren können und wo sie versagen.

Beitrag

Diese Arbeit vergleicht und bewertet zwei verschiedene Methoden der statischen Analy- se. Auf der einen Seite die automatisierte, werkzeuggestützte Codeanalyse und auf der anderen formale Fagan-Inspektionen. Fünf statische Analysewerkzeuge für C++ wurden ausgewählt und mit ihrer Hilfe ein großes Softwareprodukt der in Unterschleißheim bei München ansässigen Firma TomTec Imaging Systems GmbH untersucht. Dabei konnte zusätzlich auf eine Datenbank mit von Kunden gemeldeten Fehlern zurückgegriffen und somit Aussagen über Korrelation und Verteilung der Fehler getroffen werden.

In einem zweiten Schritt wurde eine formale Softwareinspektion nach Fagan und Gilb geplant und durchgeführt. Die Ergebnisse dieser Inspektion konnten abschließend mit denen der Analysewerkzeuge und der vorhandenen Fehlerdatenbank verglichen werden.

Es stellte sich heraus, dass keines der Analysewerkzeuge in der Lage gewesen wäre, von Kunden gemeldete Fehler im Vorfeld zu erkennen, noch bestand ein statistischer Zusam- menhang zwischen den Klassen mit hoher Fehlerzahl und den protokollierten Feldfeh- lern^[1]. Die Inspektion war der automatisierten Analyse in Bezug auf einzelne Klassen sowohl qualitativ als auch quantitativ überlegen, ihre Durchführung ist jedoch zeitauf- wändig und kostenintensiv. Als weiteres Ergebniss konnte festgehalten werden, dass sich Analysewerkzeuge nur bedingt zur Unterstützung von Softwareinspektionen eignen.

Übersicht

Begriffsdefinitionen sowie Grundlagen der statischen Codeanalyse und der dort einge- setzten Techniken werden in Kapitel 2 sowie Kapitel 3 behandelt. Das Kapitel 4 erläu- tert die Konzeption der durchgeführten Studie und beschreibt die verwendeten Analyse- werkzeuge. In Kapitel 5 werden die Versuche und deren Ergebnisse vorgestellt. Ideen zur Integration dieser Werkzeuge in die Fagan-Inspektionen werden in Kapitel 6 vorgestellt und diskutiert. In Kapitel 7 werden Ergebnisse zusammengefasst, kurz diskutiert und ein Ausblick auf die Zukunft gegeben. Im Anhang in Kapitel 8 findet sich eine im Zuge dieser Arbeit entstandene Übersicht statischer Analysewerkzeuge, die für die Inspektion genutzten Checklisten und unkommentierte Anmerkungen, Meinungen und Fragen von Entwicklern zu den Themen dieser Arbeit.

Verwandte Arbeiten

- Eine Fallstudie mit drei Analyseprogrammen für Java und informellen Reviews wurde in[7] mit dem Fazit durchgeführt, dass Analyseprogramme eine Untermenge der Fehler finden, die in Reviews gefunden werden.

- Mit dem Schwerpunkt auf Kostenevaluierung vergleicht[12] zwei Analyseprogramme für Java in einer Fallstudie. Hier wurde festgestellt, dass Feldfehler nicht mit den Analyseprogrammen gefunden werden.

- Ein Zusammenhang zwischen der Anzahl der von Analyseprogrammen detektierten Fehlern und den insgesamt enthaltenen Fehlern konnte in[19] festgestellt werden. Es wurden zwei Analysewerkzeuge für C++ mit Tests verglichen.

- Der Vorschlag eines Meta-Analysewerkzeugs, welches mehrere Analysewerkzeuge kombiniert wird in[20] geäußert, nachdem ein Vergleich verschiedener Analysewerk- zeuge für Java ergeben hatte, dass jedes Werkzeug andere Arten von Fehlern findet.

- In[29] wurden mehrere Codeinspektionen durchgeführt, insbesondere auf die Inspektoren und für sie relevante Faktoren wird eingegangen.

2. Grundlagen

2.1.Qualitätsmanagement

Ein Qualitätsmanagementsystem und Qualität sind nach DIN EN ISO 9000 wie folgt definiert:

- Qualitätsmanagementsystem: „Jener Teil des übergeordneten Managementsystems, der die Organisationsstruktur, Planungstätigkeiten, Verantwortlichkeiten, Methoden, Verfahren, Prozesse und Ressourcen zur Entwicklung, Umsetzung, Erfüllung, Be- wertung und Aufrechterhaltung der Qualität umfasst.“

- Qualität: „Vermögen einer Gesamtheit inhärenter Merkmale eines Produkts, eines Systems oder eines Prozesses zur Erfüllung von Forderungen von Kunden und anderen interessierten Parteien.“

Demnach sinkt die Qualität, wenn die Forderungen von Kunden nicht erfüllt werden. In[34] wird das Nichterfüllen einer Forderung als Fehler definiert, insofern dienen Qualitätsmanagementsysteme schon ihrer Definition nach der Fehlervermeidung und Fehlerreduktion[6]. Diese Funktion wird dann am besten erfüllt, wenn ein Projekt von Beginn an vom Qualitätsmanagement begleitet wird.

Unter dem Begriff Qualitätssicherung fasst man „Verfahren, Aktivitäten und Prozesse die dazu dienen sicherzustellen, dass ein Produkt entsprechend definierten Anforderungen gerecht wird“ zusammen. Abbildung 1 zeigt einen kurzen Überblick über verschiedene Qualitätssicherungsverfahren in der Softwareentwicklung. Unter statischen, analysierenden Maßnahmen versteht man die Maßnahmen, die zur Lokalisierung und Erkennung von Fehlern dienen. Diese Arbeit beschäftigt sich mit den automatischen sowie den manuellen statischen analysierenden Verfahren. [1, 5, 78]

In der DIN EN ISO 9001 oder der auf die Softwareentwicklung zugeschnittenen Capa- bility Maturity Model Integration (CMMI) des Carnegie Mellon Software Engineering Instituts (SEI) werden konkretere Ansätze für Unternehmen genannt, um die oben ge- nannten Qualitätsziele zu erreichen, insbesondere das Festlegen von Zuständigkeiten, die Einführung von Prozessen aber auch die Verwendung von statischer Analyse. [6, 35, 69]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Überblicküber Qualitätssicherung in der Softwareentwicklung

2.2. Fehler

2.2.1.Definition Fehlerbegriff

Im Folgenden werden verschiedene Quellen und Definitionen des Begriffs Fehler vorgestellt, um Parallelen und Unterschiede verschiedener Quellen aufzuzeigen. Abschließend wird die in dieser Arbeit gültige Definition festgelegt.

Deutsches Institut für Normung (DIN)

Das Deutsche Institut für Normung definiert in seinen Publikationen wie beispielsweise in[34] und[38] den Begriff Fehler als „die Nichterfüllung einer Forderung“.

In der Softwareentwicklung existieren Forderungen verschiedener Formen und Quellen, u. a. die Produktspezifikation, die Sprachdefinition der verwendeten Programmiersprache oder auch die im Unternehmen gültigen Programmierrichtlinien bzw. Qualitätsmanagementrichtlinien. Dieser Definition nach können also auch nachträgliche Änderungen der Forderungen (z. B. der Spezifikation) Fehler nach sich ziehen.[74]

Institute of Electrical and Electronics Engineers (IEEE)

In[39] ist folgende, ausführliche Definition^[1] des Fehlerbegriffs zu finden. Es werden vier Arten von Fehlern unterschieden, deren englische Bezeichnungen vorerst absichtlich beibehalten wurden:

- Error: Der Unterschied zwischen einem berechneten, beobachteten oder gemessenen Wert oder Zustand und dem wahren, spezifizierten oder theoretisch korrekten Wert oder Zustand.
Beispiel: Differenz von 3 Metern zwischen berechnetem und korrektem Ergebnis.
- Fault: Eine falsche Anweisung, ein falscher Prozess, eine falsche Datendefinition. Beispiel: Eine falsche Programmanweisung.
- Failure: Ein falsches Ergebnis.
Beispiel: Ein berechnetes Ergebnis von 12, wenn 10 korrekt wäre.
- Mistake: Eine Aktion eines Menschen, die ein falsches Ergebnis zur Folge hat. Beispiel: Eine falsche Aktion des Programmierers oder Benutzers.

Weiterentwicklung der IEEE-Definition

In[41] wird bis auf kleine Abweichungen die obige IEEE-Definition aufgegriffen, verfeinert und in eine Kette kausaler Zusammenhänge modelliert:

- Fehlhandlung (Mistake): Eine Aktion eines Menschen, die einen Fehlerzustand zur Folge hat.
- Fehlerzustand (Fault): Ein Fehlerzustand ist die Ursache der Fehlerwirkung, z. B. falsche Anweisungen im Code. - Fehlerwirkung (Failure): Ein falsches Ergebnis.

Defekt (Defect) wird als Oberbegriff für Fehlerzustand und Fehlerwirkung festgelegt.

Softwareinspektion (Rösler / Gilb / Graham / Fagan)

Im Rahmen der Softwareinspektion wird der Begriff Defekt (Defect) ebenfalls verwendet. In[27] finden sich zwei Definitionen^[1]:

- Defekt: „Ein Defekt ist etwas, das an einem Arbeitsprodukt nicht korrekt ist.“
- Defekt: „Ein Defekt ist etwas, das auf die Wartung oder die Verbesserung der Qualität und Produktivität [negative] Auswirkung hat oder sie behindert.“

Der Begriff Issue wird eingeführt als „Auffälligkeit, die Aufmerksamkeit verlangt“.

Arbeitsdefinition

Die obigen, erweiterten IEEE-Definitionen aus[41] sollen auch in dieser Arbeit Gültigkeit besitzen, ergänzt durch die Definition von Defekt aus Software Inspektion[27], wobei Defekt mit dem Begriff Fehler gleichgesetzt wird. Gemäß[27] soll weiterhin Issue gleich- bedeutend mit dem Begriff Anomalie verwendet werden. Ein Issue bzw. eine Anomalie ist ein potentieller Fehler, der zu einem falsch oder richtig positiven Defekt ausgewertet werden kann.

2.2.2. Fehlerklassifikation nach Schwere

Fehler können nach verschiedenen Kriterien klassifiziert werden, dieser Abschnitt widmet sich dem Kriterium der Schwere, wie sie in[38] definiert ist: Unter Schwere versteht man den „Grad der Beeinträchtigung des Produkteinsatzes“.

Deutsches Institut für Normung (DIN)

Die Fehlerklassifizierung nach Schwere erfolgt in[34] anhand der Fehlerfolgen in drei Kategorien:

- Kritischer Fehler: Gefährliche, kritische Situationen werden geschaffen, z. B. Personengefährdung.
- Hauptfehler: Eventueller Ausfall oder die Brauchbarkeit wird wesentlich herabge- setzt.
- Nebenfehler: Brauchbarkeit oder Betrieb sind nur geringfügig beeinflusst.

Softwareinspektion (Rösler / Gilb / Graham / Fagan)

Im Kontext der Inspektion werden zwei Fehlerklassen der Schwere nach unterschieden. Deren genaue Definition ist anwendungsabhängig für allgemeine Inspektionen[27]. Im Rahmen der speziellen Codeinspektion lassen sich dennoch zwei Definitionen in[27] und in Rücksprache und Beratung mit einem Experten für Inspektionen, Herrn Peter Rösler (siehe auch[40] ), finden:

- Major Defect: Ein Defekt, der Auswirkung auf das Programmverhalten hat.
- Minor Defect: Ein Defekt, der keine Auswirkung auf das Programmverhalten hat.

Arbeitsdefinition

Diese Arbeit orientiert sich an den beiden gegebenen Definition, denen der DIN und denen für die Software Inspektion:

- Hauptfehler (Major Defect): Ein Defekt, der Auswirkungen auf das Programmver- halten hat und zum Ausfall führen kann oder die Brauchbarkeit wesentlich herab- setzt. - Nebenfehler (Minor Defect): Ein Defekt, der keine (direkten) Auswirkungen auf das Programmverhalten hat und die Brauchbarkeit oder den Betrieb nur geringfügig beeinflusst.

2.2.3. Fehlerklassifikation nach Typ

Es existieren eine Reihe von Ansätzen, Fehler weiter nach Typ zu klassifizieren, wie beispielsweise das Hewlett-Packard Scheme, die Orthogonal Defect Classification von IBM, die Standard Classification for Software Anomalies der IEEE oder das CUP-Schema. Eine solch allgemeine Klassifizierung von Fehlern nach ihrem Typ ist jedoch umstritten, da umfassende Studien ergaben, dass die Verteilung der auftretenden Fehlertypen stark projektabhängig ist und sich aus diesem Grund nur schwer verallgemeinern lässt[4]. Also wird in dieser Arbeit zugunsten einer eigenen Klassifikation der Fehler auf die Vorstellung und Anwendung der Standards verzichtet.

Fehlerklassen

Die folgenden Fehlerklassen sind zur besseren Vergleichbarkeit an die Studienarbeit von Claudia Koller[42] angelehnt, in der sie sich mit statischer Analyse von Java-Applikatio- nen beschäftigt.

- Rückgabewerte: Ignorierte oder falsche Verwendung von Rückgabewerten.
- Fehlerbehandlung: Fehlerhafte Fehlerbehandlung.
- Null-Pointer: Fehlender oder falscher Umgang mit Null-Zeigern.
- Buffer Overflows + Arrays: Pufferüberläufe und falscher Umgang mit Feldern.
- Input/Output: Fehler mit Datei-Operationen.
- Objektorientiertheit: Fehler mit objektorientierten Techniken.
- Wert nie gelesen: Initialisierte Variable wird nie gelesen.
- Variable nie verwendet: Initialisierte Variable wird nie verwendet.
- Überflüssige Anweisungen: Anweisungen ohne Effekt.
- Toter Code: Unerreichbarer Code, nicht aufgerufene Methoden, etc.
- Initialisierung: Nicht oder fehlerhaft initialisierte (member-)Variablen.

Des Weiteren wurden für diese Arbeit folgende zusätzliche Fehlerklassen definiert:

- Überläufe und Arithmetik: Divisionen durch 0, arithmetische Überläufe, etc.
- Speicherverwaltung: Doppelte oder fehlende Speicherfreigaben, etc.
- Sicherheit: Verwendung kritischer Methoden oder ungeprüfte Eingabe, etc.
- Switch-Anweisungen: Fehlende Break-Anweisungen, fehlender default-Fall, etc.
- Casting: Fehlerhafte (ggf. implizite) Typumwandlungen.
- Iteratoren: Falsche Verwendung von Iteratoren.

Grundlagen - Metriken

- String: Fehlende Terminierung, Überläufe, etc.

- Verdeckte Parameter: Durch lokale Deklaration verdeckte Variablen.

- Sonstige: Endlosschleifen, Zuweisung wo Vergleich gemeint war, Codesmells, in C++ undefiniertes Verhalten, Logikfehler.

2.3. Metriken

Im IEEE Standard 1061 von 1992 ist der Begriff Softwaremetrik wie folgt definiert:

„ Eine Softwaremetrik ist eine Funktion, die eine Software-Einheit in einen Zahlenwert abbildet. “

Die folgenden Definitionen von Metriken stammen aus[8] und[68], die ersten vier sind Zeilenmetriken und damit gleichzeitig die bekanntesten und die am einfachsten zu berechnenden Metriken, deren Aussagegrad jedoch begrenzt ist, da sie beispielsweise keine Auskunft über die Programmkomplexität geben.

- LOC (Lines of Code): Anzahl der Zeilen Code.
- BLOC (Blank Lines of Code): Anzahl der Leerzeilen im Code
- NLOC-P (Noncommented Lines of Code - Physical): Anzahl der physischen Programmzeilen ohne Kommentare und Leerzeilen.
- NLOC-L (Noncommented Lines of Code - Logical): Anzahl der terminierenden Semikolons und geschweiften Klammern.
- Zyklomatische McCabe-Komplexität v(G): Unter v(G) versteht man die Anzahl der konditionellen Zweige des Flussdiagramms eines Programms.

2.4. Programmierstandards

Eine Möglichkeit, fehleranfällige Konstrukte zu vermeiden ist das verbindliche Einhalten von Programmierstandards, welche den Sprachumfang einer Programmiersprache bewusst einschränken. Die Einhaltung der Programmierstandards können automatisiert durch statische Analysewerkzeuge geprüft werden. Beispiele für Programmierstandards für die Sprache C++ sind unter anderem:

- HICPP: Dieser Standard wurde von Programming Research entwickelt, die mit QA C++ ein eigenes statisches Analysewerkzeug anbieten, welches sich allerdings vornehmlich auf die Kontrolle von Programmierstandards konzentriert. [56, 72]
- JSF++: Der Joint Strike Fighter Air Vehicle C++ Coding Standard (JSF++) wurde 2005 von Lockheed Martin im Rahmen der Softwareentwicklung für den Joint Strike Fighter entwickelt und veröffentlicht.[73]
- MISRA C++: Der im Jahr 2008 von der Motor Industry Software Reliability Asso ciation veröffentlichte Programmierstandard MISRA C++ basiert auf den Standards MISRA-C und HICPP.[71]

Auch unternehmenseigene Kodierrichtlinien sind ein probates Mittel, innerhalb des Unternehmens für bessere Codelesbarkeit und damit bessere Wartbarkeit zu sorgen.

3. Grundlagen der statischen Analyse

Als statische Analyse von Programmen bezeichnet man - im Gegensatz zur dynamischen Analyse - die Untersuchung eines Programms bzw. seiner Quelltexte während das Programm nicht ausgeführt wird. Dies kann automatisiert durch Rechner mittels Software erfolgen oder durch Menschen in Form von Audits, Reviews und Inspektionen, womit die beiden Arten der statischen Analyse genannt sind.[11]

3.1.Automatisierte statische Analyse

Statische Analyse soll ein unentscheidbares Problem der Informatik lösen[21] ; ein statisches Analyseprogramm erhält als Eingabe den Quelltext eines anderen Programms und soll entscheiden, ob dieses zweite Programm fehlerfrei terminiert, also zu einem kontrollierten Ende kommt[11]. Dieses Problem ist bekannt als das Halteproblem, welches Alan Turing 1936 als unentscheidbar bewies.

Eine vollständige Korrektheitsanalyse ist nach Turing nicht möglich, aber sie ist auch nicht nötig, um sich auf die Suche nach Fehlern zu begeben. Reduziert man bei der Analyse die zu verarbeitende Informationsmenge, beispielweise durch Beschränkung auf Teile des Programms, auf eine Untermenge der möglichen Eingabewerte oder durch den Einsatz von Heuristiken und Approximationen, lassen sich durch statische Analyse viele wertvolle Informationen gewinnen[21].

Schon der Compiler führt eine automatisierte statische Codeanalyse durch, deren Er- gebnisse er dem Entwickler in Form von Warnungen und Fehlermeldungen präsentiert. Spezialisierte statische Analysewerkzeuge arbeiten ähnlich dem Compiler, gehen hier aber weiter. Sie benötigen als Eingabe ebenfalls den zu untersuchenden Quelltext und können dann, durch verschiedene Techniken, nach Fehlern suchen. Allen Techniken der maschinellen statischen Analyse ist gemein, dass sie über ein - oft vom Benutzer erwei- terbares - Regelwerk verfügen und nach Übereinstimmungen mit diesen Regeln fahnden [11] ; wie sie das genau machen, hängt von der eingesetzten Technik ab.

Ähnliche Regelsätze sind meist zu Detektoren oder Checkern zusammengefasst. Die Versuchung liegt nahe, statische Analysewerkzeuge anhand der Anzahl dieser Detektoren zu vergleichen, jedoch ist das nur ein ungenaues Vergleichskriterium, da manche Detektoren sehr vielseitig sein können und andere nur in einigen wenigen Spezialfällen anschlagen[11]. Besser ist der Vergleich dieser Werkzeuge anhand eines konkreten Beispielprojekts, was im Rahmen dieser Arbeit geschehen ist.

Ein weiteres nicht zu vernachlässigendes Qualitätskriterium für Analysesoftware ist die Form der Ergebnispräsentation, welche ebenso wichtig sein kann, wie die Ergebnisse selbst. Denn wenn gemeldete Fehler unverständlich oder umständlich dargestellt werden, kann es sein, dass sie im alltäglichen Routinebetrieb ignoriert werden[11]. Auch dieser Faktor sollte in einen Vergleich von Werkzeugen einfließen.

[...]

---

^[1] A2LL: Arbeitslosengeld II - Leistungen zum Lebensunterhalt

^[2] Food and Drug Administration, zuständig für die Zulassung von Medizinprodukten auf dem amerika- nischen Markt.

^[1] Fehler, der nicht von der Qualitätssicherung entdeckt, sondern vom Kunden gemeldet wurde.

^[1] Übersetzung durch den Verfasser

^[1] Übersetzung durch den Verfasser