Software Engineering

© Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, 2010.

13 Software-Qualitätssicherung und -Prüfung

13.1 Software-Qualitätssicherung

13.2 Prüfungen

13.3 Mängel und Fehler

13.4 Prüfungen im Überblick

13.5 Reviews

13.6 Varianten der Software-Inspektion

Motivation für die Qualitätssicherung - 1

Allgemeine Erfahrung in der fertigenden Industrie, insbesondere in der Automobilindustrie des frühen 20. Jahrhunderts:

Gute Qualität kommt nicht von selbst.

Mit schlechter Qualität muss man vor allem dann rechnen, wenn

● die Arbeiter schlecht ausgebildet sind,

● keine soziale Kontrolle des Verhaltens stattfindet,

● die Produkte den einzelnen Arbeitern nicht zugeordnet werden können oder

● die erreichte Qualität für die Verursacher ohne Wirkung bleibt.

Die Folge war die Produktion von Gütern (Autos), die billig, aber von schlechter Qualität waren.

2

Motivation für die Qualitätssicherung - 2

Als Gegenmittel entstand die (industrielle) Qualitätssicherung.

Prinzip: Am Ende der Fertigung folgt eine Prüfung.

Nur Produkte, die den Prüfkriterien entsprechen, werden ausgeliefert.

Das setzt die Existenz eines Ideals voraus (real oder gedacht, z.B. eine Konstruktionszeichnung. Prüfung = Vergleich mit dem Ideal (s.u.).

Große Stückzahlen: statistische Qualitätssicherung (Prüfung einer Stichprobe, Anwendung mathematischer Modelle).

Softwaretechnik: keine Produktion, nur Entwicklung (d.h. Herstellung eines Ideals). Es gibt kein Ideal zur Prüfung!

Wir brauchen also eine QS der Entwicklung, nicht der Fertigung.3

13.1 Software-Qualitätssicherung

Software-Qualitätssicherung - 1

Die Bedeutung (2) ist obsolet, denn die Prozessbewertung ist zu einem eigenen Thema geworden.

Einfacher

● SQS = alle Aktivitäten, die dem Ziel dienen, gute Software-Qualität zu erreichen

5

software quality assurance — See: quality assurance.

quality assurance — (1) A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements.

(2) A set of activities designed to evaluate the process by which products are developed or manufactured.

IEEE Std 610.12 (1990)

Software-Qualitätssicherung - 2

Die Bedeutung (1) entspricht dem üblichen Verständnis von Software-Qualitätssicherung: Alles, was zu tun ist, damit man der Qualität eines Produkts trauen kann, gehört dazu.

Die Doppeldeutigkeit dieser Definition ist sinnvoll:

Damit man dem Produkt traut, kann man es besser machen oder nachweisen, dass es gut ist. Beides ist Qualitätssicherung.

● Software-Qualitätssicherung hat unmittelbar zum Ziel, das Vertrauen in eine Software zu erhöhen;

● mittelbar wirkt sie sich, wie jede angekündigte Prüfung, auf das Qualitätsniveau aus, steigert also die Fähigkeit, qualitativ hochwertige Produkte zu entwickeln.

 

6

Maßnahmen zur Hebung der Qualität - 1Viele Maßnahmen tragen dazu bei, die Qualität zu heben (oder genauer: Qualitätsmängeln vorzubeugen).

Beispiele:

● Einen Projektplan erstellen

● Dabei nicht nur die Konstruktion, sondern auch Reviews, Tests und andere Prüfungen einplanen

● Die Dokumentation planen

● Identifikation und Verwaltung der Arbeitsergebnisse regeln (Konfigurationsverwaltung)

● Aufgaben erst stellen, dann lösen

● Resultate erst prüfen, dann verwenden

● Für alle wiederkehrenden Arbeiten Checklisten verwenden

7

Maßnahmen zur Hebung der Qualität - 2

Beispiele:

● Hohe Programmiersprachen einsetzen

● Muster (Templates) und Codierrichtlinien vorgeben

● Fehler und Änderungswünsche kontrolliert bearbeiten

● Fehlerstatistiken führen

● Jedes abgeschlossene Projekt kritisch analysieren

In der Praxis werden solche Regeln oft durch Richtlinien kodifiziert; deren Einhaltung muss aber auch kontrolliert werden.

Regeln ohne Kontrollen sind wirkungslos; nur wenn sich alle an die Richtlinie halten, bringt sie erheblichen Nutzen. 

8

Schwerpunkte der SW-Qualitätssicherung

Software-Qualitätssicherung zerfällt in organisatorische, konstruktive und analytische Maßnahmen.

● Software-Projektmanagement

● konstruktives Software Engineering

● Software-Prüfung

Qualität lässt sich nicht in das Produkt „hinein prüfen“!

Organisatorische und konstruktive Maßnahmen sind wesentlich wichtiger, sie werden durch analytische Maßnahmen ergänzt.

9

Aufgaben des QS-Ingenieurs

Die Aktivitäten der Qualitätssicherung werden definierten Rollen im Projekt (z. B. dem Tester) und in der Organisation zugeordnet.

Eine besondere Stellung hat der QS-Ingenieur. Er ist insbesondere für die organisatorischen Qualitätssicherungsmaßnahmen verantwortlich. Zu den Aufgaben dieser Rolle zählen:

● Erstellen von Richtlinien, Musterdokumenten, Checklisten usw.

● Auswählen und Einführen von Werkzeugen

● Schulung und Beratung der Projektmitarbeiter in Methoden und Techniken der Qualitätssicherung

● Aufstellen von Plänen, insbesondere von Prüfplänen

● Mitwirkung oder Teilnahme an Prüfungen, insbesondere bei den formalen Prüfungen an Meilensteinen

● Überwachen aller Maßnahmen, die im Interesse höherer Qualität durch Pläne, Richtlinien usw. vorgesehen sind

10

13.2 Prüfungen

Sinn und Wirkung von Prüfungen

Prüfungen haben den Zweck, die Qualität des Prüflings festzustellen, vor allem, ob er im Sinne der Anforderungen fehlerfrei ist.

Nutzen und Wirkungen von Prüfungen am Beispiel der Schule:

● implizite, sehr konkrete Definition der Leistungskriterien

● Anzeige kollektiver und individueller Schwächen, Rückmeldung über den Erfolg des Unterrichts

● meist keine direkte Wirkung auf die Leistungen der Prüflinge

● Erkennung extrem guter und extrem schlechter Kandidaten (Ansporn der Guten, Förderung der Schlechteren)

● Ausschluss als Ultima Ratio

● Motivation zum Lernen (d.h. zur Änderung der Prüfungsresultate)

● Prüfung der Lehrer

12

Übertragung auf die Software-Prüfung

● Prüfungen liefern implizit eine Definition der Qualitätskriterien.

● Prüfungen zeigen kollektive und individuelle Schwächen der Prüflinge (also der Dokumente, Programme usw.). Sie geben damit Hinweise für das Software Engineering (allgemein und speziell).

● Direkt erhöhen Prüfungen die Qualität der Prüflinge nicht.

● Prüfungen schaffen die Möglichkeit, die extrem guten und die extrem schlechten Prüflinge zu erkennen.

● Die Erwartung einer Prüfung beeinflusst das Verhalten der Entwickler und damit (indirekt) die Qualität des Produkts.

● Durch Audits kann und muss überprüft werden, ob die festgelegten Regeln zur Durchführung des Projekts auch eingehalten werden. Damit wird auch die Qualität des Managements geprüft.

13

13.3 Mängel und Fehler

Definitionen der ISO 9000

Anforderung = Erfordernis oder Erwartung, das oder die festgelegt, üblicherweise vorausgesetzt oder verpflichtend ist

Anforderung nicht erfüllt → Fehler

Mangel = Nichterfüllung einer Anforderung in Bezug auf einen beabsichtigten oder festgelegten Gebrauch.

Wenn ein Fehler die Verwendbarkeit nicht beeinträchtigt, liegt kein Mangel vor.

Ein Mangel kann juristische Folgen haben (z. B. die Forderung nach Schadensersatz).

15

Kleine Theorie der Fehlersuche - 1

Wir suchen nach Fehlern, (fast) ohne etwas über sie zu wissen.

Wir wissen nur, dass sie sich (falls überhaupt welche vorhanden sind)

● an irgendeiner Stelle manifestieren (z. B. im Code einer Prozedur)

● unter mehr oder minder speziellen Umständen zeigen (z. B. bei Ausführung des Codes mit bestimmten Eingabedaten). 

Fehlersuche wäre effektiv (wenn auch nicht notwendig effizient) möglich, wenn zwei Bedingungen erfüllt wären:

1. Die Eigenschaften des Programms sind – i. A. durch die Spezifikation – eindeutig und vollständig festgelegt.

Prinzipiell möglich für funktionale Anforderungen, praktisch unmöglich für die NFRs.

16

Kleine Theorie der Fehlersuche - 2

2. Die Eigenschaften lassen sich durch Prüfungen eindeutig und vollständig feststellen.

Nur für extrem primitive Algorithmen möglich, sonst ausgeschlossen durch die Größe des Zustandsraums 

Konsequenz:

Ein Korrektheitsbeweis durch Prüfung ist ausgeschlossen.  

Praktischer Ansatz

● Mit möglichst geringem Aufwand möglichst viel Schaden verhindern.

Jede Suche geht von Annahmen über das Gesuchte aus, jeder Prüfung liegt also eine Fehlertheorie zu Grunde – die sich allerdings allzu oft als unbrauchbar erweist!

17

Fazit

Prüfung ist keine moralische, sondern eine praktische Forderung:

Die Prüfung der Software ist also – wie das ganze Software Engineering – nicht Selbstzweck, sondern wirtschaftlich geboten.

18

13.4 Prüfungen im Überblick

Schema von Prüfungen

Alle Prüfungen folgen grundsätzlich dem gleichen Schema.

In jeder Prüfung wird das

● Resultat (der Ausbildung, der Entwicklung, ...) mit den

● Erwartungen an das Resultat

verglichen.

Eine dabei festgestellte Diskrepanz weist auf einen Fehler hin

Sie zeigt aber nicht, wo der Fehler liegt, im Prüfling oder sonstwo.

 

20

Das Prinzip der Prüfung

Jede Prüfung beruht auf dem Prinzip der Zweigleisigkeit (oder Mehrgleisigkeit).

Um die (angebliche) Lösung zu prüfen, wird sie

● mit einer vermutlich richtigen verglichen

● oder an Kriterien gemessen, die aus den Anforderungen abgeleitet sind.

21

Validierung und Verifikation - 1

Für Prüfungen in der Entwicklung gibt es zwei Prinzipien:

a) Wurde entwickelt, was gewünscht ist?

b) Wurde der Entwicklungsschritt x richtig durchgeführt?

Boehm nennt diese Ansätze

a) Validation (Validierung):

● to establish the fitness or worth of a software product for its operational mission.

● „Am I building the right product?”

b) Verification (Verifikation):

● to establish the truth of the correspondence between a software product and its specification.

● „Am I building the product right?”

22

Validierung und Verifikation - 2

Vergleich mit einer Fahrt auf der Basis einer Wegbeschreibung:

a) Haben wir das vorgesehene Ziel (oder Zwischenziel) erreicht?

b) Sind wir, wie es die Beschreibung verlangt, an der richtigen Stelle auf die richtige Straße abgebogen?

(a) ergibt die wichtigere Aussage, lässt sich aber nur anwenden, wenn das Endziel oder ein definiertes Zwischenziel erreicht wurde.

(b) lässt sich nach jedem Schritt anwenden.

Vergleich mit einer Rechenaufgabe:

● Zu bestimmen ist die Wurzel einer positiven reellen Zahl.

● Nach a kann man das Resultat quadrieren und damit überprüfen.

● Nach b kann man bei einer iterativen Lösung feststellen, ob der Algorithmus richtig ist.

23

Validierung und Verifikation - 3

Man beachte aber, dass die Wörter Validierung und Verifikation auch anders gebraucht werden, nämlich

● Validierung als Oberbegriff für alle Prüfungen,

● Verifikation speziell für Prüfungen formaler Art (Programmbeweis und Ähnliches).

Zur Vermeidung von Missverständnissen spricht man dann von externer und interner Validierung (entsprechend a und b)bzw. von formaler Verifikation.

24

Positive und negative Prüfresultate - 1

Prüfung führt zu einem Befund: Prüfergebnis ist positiv (!)

● Vgl. die ähnliche Terminologie in der Medizin, wo man von einem positiven oder negativen Befund spricht.

Wenn der Grund für den Befund nicht in einem Fehler des Prüflings liegt, ist das Prüfergebnis falsch positiv.

● Mögliche Ursachen: Falsch bestimmte Sollresultate, falscher Prüfling, Fehler beim Vergleich

Falsch positive Resultate machen unnötig Arbeit, sind aber sonst harmlos.

Viel schlimmer: falsch negative Resultate, bei denen ein tatsächlich vorhandener Fehler nicht entdeckt wird.

Daher ist es bei jeder Prüfung weit wichtiger, falsch negative als falsch positive Resultate zu vermeiden.

25

Positive und negative Prüfresultate - 2

Wenn Fehler bei der Prüfung nicht entdeckt werden, liegt das daran,

a) dass nicht nach ihnen gesucht wurde

b) dass die Ergebnisse falsch negativ waren. 

 

Achtung, der Übergang ist fließend:

● Wenn ein bestimmter Teil der Spezifikation nicht zur Prüfung herangezogen wurde, liegt Fall a (Unterlassung) vor.

● Wenn anschließend behauptet wird, das Programm sei gegen die Spezifikation getestet worden, liegt Fall b (falsche Interpretation der Resultate) vor.

 

26

Feststellungen für alle Prüfungen● Alles, was gefordert wurde, muss auch geprüft werden.

● In jeder Prüfung gibt es zwei Pfade von der Vorgabe zum Resultat, die eigentliche Produktion und den Prüfpfad.

● Die Prüfung kann nur Fehler aufdecken, die auf einem der beiden getrennten Pfade liegen, aber keine Fehler, die in den gemeinsamen Teilen liegen. Diese Teile sind also besonders kritisch, sie müssen speziell (und anders) geprüft werden.

● Werden Fehler entdeckt, so ist das Prüfresultat positiv. Liegt der Fehler (nur) im Prüfzweig, so ist es falsch positiv.

● Werden Fehler nicht entdeckt, so wurde entweder nicht nach ihnen gesucht, oder das Prüfresultat war falsch negativ. Solche Resultate entstehen durch zufällige Fehlerkompensation oder (sehr viel öfter) durch unzulässige Verallgemeinerung negativer Resultate oder durch Fehler in den gemeinsamen Teilen.

Falsch negative Resultate sind schlimmer als keine Resultate, denn sie suggerieren falsche Sicherheit!

27

Möglichkeiten und Prinzipien der PrüfungEine mechanische Prüfung setzt voraus, dass der Prüfling einer mechanischen Analyse zugänglich sind.

Darum kommt ganz überwiegend (nur) die Inspektion in Frage.

 

28

Das Dokument … ist prüfbar durch Inspektion Test

Lastenheft X

Pflichtenheft X

Systementwurf X

Benutzerhandbuch X

Testdaten X

Definition der Daten und Algorithmen X

Code X X

Anleitungen etc. X

Für alle Software-Prüfungen gilt

● Nur gegen Vorgaben (Anforderungen, Vergleichsresultate) prüfen! Um die Anforderungen zu prüfen, brauchen wir die Klienten, von denen die Anforderungen kommen.

● Prüfungen planen! Prüfungen benötigen Zeit und Ressourcen.

● Prüfverfahren müssen wohldefiniert sein und reproduzierbare Ergebnisse liefern! Die Reproduzierbarkeit ist bei subjektiven Verfahren begrenzt, aber auch nicht so schlecht, wie viele Leute befürchten.

● Prüfergebnisse müssen dokumentiert werden! Für die rasch wachsenden Datenmengen ist eine geordnete Ablage in der Konfigurationsverwaltung anzulegen.

● Beim Prüfen erkannte Fehler müssen behoben werden! Die Korrektur ist eine notwendige Konsequenz, aber kein Teil der Prüfung.

29

Trennung der Korrektur von der Prüfung

Auf den ersten Blick wirkt es umständlich, die Prüfung nach Erkennung eines Fehlers fortzusetzen, ohne den Fehler gleich zu beheben. Diese Überlegung ist aber vordergründig:

● Schrott darf gar nicht erst in die Prüfung kommen.(Prozess in Ordnung bringen, Entwickler schulen)

● Nur definierte Objekte prüfen! (nicht beliebige Zwischenstände)

● Grundsätzliche Mängel durch komplette Prüfung offenlegen! (Nicht die Symptome bekämpfen, sondern die Ursachen erkennen und beseitigen; additive Änderungen vermeiden!)

● Änderungen erst nach reiflicher Überlegung! (Änderungen sind besonders fehlerträchtig.)

● Fehler registrieren, nicht unter den Teppich kehren!

● Rollen Entwickler und Prüfer trennen, Überläufer vermeiden!

Es gibt also viele gute Gründe, Prüfung und Korrektur zu trennen!

30

Schwerpunkte der Qualitätssicherung

31

Inspektionsverfahren

Es gibt viele Verfahren, Software zu inspizieren.

1. die Durchsicht (der „Schreibtisch-Test“)

2. die Stellungnahme

3. das Technische Review

4. der Walkthrough

5. die Design- and Code Inspections

Gesprächsrunden – vor allem zur Klärung der Anforderungen – werden ebenfalls als Reviews bezeichnet werden.

Wir sprechen in diesem Fall von Workshops. Sie sind sehr sinnvoll, haben aber eine andere Zielsetzung als die Reviews.

32

13.5 Reviews

Technisches Review

Nachfolgend wird das Technische Review beschrieben. In der Praxis gibt es zahlreiche Varianten. Zwischen diesen Formen gibt es keine simple Qualitätsordnung!

Eine Software-Einheit wird (dezentral) von mehreren Gutachtern inspiziert; in einer gemeinsamen Sitzung werden die Mängel zusammengetragen und dokumentiert.

Ziel des Reviews ist es, Fehler zu finden, nicht, die Fehler auch zu beheben.

Prüfling kann jeder in sich abgeschlossene, für Menschen lesbare Teil von Software sein — ein einzelnes Dokument, ein Codemodul, ein Datenmodul.

Zur Prüfung werden Referenzunterlagen benötigt (Vorgabe oder Spezifikation, Richtlinien, evtl. auch Fragenkataloge).

34

Rollen im Technischen Review

Zuständigkeiten und Verantwortlichkeiten sind im Review klar durch folgende Rollen definiert:

● Der Moderator leitet das Review, ist also für den ordnungsgemäßen Ablauf verantwortlich.

● Der Notar führt das Protokoll.

● Die Gutachter sind Kollegen, die den Prüfling beurteilen können.

● Der Autor ist der Urheber des Prüflings oder ein Repräsentant des Teams, das den Prüfling erstellt hat.

● Der Manager (Linienvorgesetzte oder Projektleiter) hat den Auftrag zur Erstellung des Prüflings gegeben und somit auch die Verantwortung für die Freigabe des Prüflings. Er sollte (vor allem in den ersten Versuchen) nicht am Review teilnehmen!

35

Das Review-Team

Das Review-Team bilden alle Teilnehmer des Reviews außer dem Autor.

36

a

Gutachter

Notar

Autor

Moderator

Prüfling

Aufträge an die Gutachter - 1Die Gutachter erhalten im Technischen Review immer konkrete Aufträge. Diese haben einen doppelten Sinn:

● Fehler, die immer wieder vorkommen, werden sehr wahrscheinlich entdeckt.

● Ein Gutachter, der nach bestimmten Mängeln sucht, ist insgesamt aufmerksamer als ohne speziellen Prüfauftrag.

 

37

Fragenkatalog für Gutachter - Art des Dokuments: SpezifikationBereiten Sie die Review-Sitzung vor, indem Sie den Prüfling speziell unter den Ihnen in

der Einladung zugeordneten Aspekten aus der folgenden Liste prüfen:

Aspekt "Form": Ist die Darstellung im Dokument sinnvoll?1. Sind alle Anforderungen erkennbar, d. h. von Erklärungen unterscheidbar?2. Sind alle Anforderungen eindeutig referenzierbar?3. Ist die Spezifikation jeder Anforderung eindeutig?4. Sind alle Anforderungen überprüfbar formuliert?

Aufträge an die Gutachter - 2

38

Aspekt "Schnittstellen": Sind alle Schnittstellen eindeutig spezifiziert?

5. Sind alle Objekte der Umgebung (Benutzer, andere Systeme, Basis-Software etc.) sowie alle Informationsflüsse von und nach diesen Objekten spezifiziert?

6. Sind alle Benutzerklassen des Systems (Dauerbenutzer, gelegentliche Benutzer, System-Administrator etc.) identifiziert?

7. Ist die Bedienschnittstelle für jede der Benutzerklassen festgelegt?8. Ist die Bedienphilosophie einheitlich?9. Ist das beschriebene Bedienkonzept den Vorkenntnissen der Benutzer

angemessen?…

Organisation und Ablauf - 1

Die eigentliche Review-Sitzung ist eingerahmt von je etwa zwei Wochen Vorbereitung und Nacharbeit; unmittelbar nach der Sitzung kann die „Dritte Stunde“ folgen.

39

Organisation und Ablauf - 2● Anstoß: von der Konfigurationsverwaltung. Der Moderator wird

informiert, er verteilt die Einladungen an die Gutachter; Prüfling und Prüfaufträge sind Teile der Einladung.

● Vorbereitung: Die Gutachter lesen das zu prüfende Dokument und prüfen es nach den ihnen zugeteilten Gesichtspunkten.

● Review-Sitzung: Die Gutachter tragen die in der Vorbereitung entdeckten Mängel vor. Gemeinsam erheben, gewichten und protokollieren sie die Befunde.

● Resultat: Liste der Schwächen mit Empfehlung, welche Arbeiten vor der Freigabe des Prüflings durchgeführt werden sollten.

● Dritte Stunde: Die Gutachter und der Autor reden ohne Regeln und ohne Protokoll.

● Nacharbeit: Sache des Autors oder der Autoren; Umfang legt der Manager fest.

Planung und Analyse finden lange vor/nach dem Review statt.

40

Review-Regeln - 1

1. Der Moderator organisiert das Review, lädt dazu ein und führt es durch. (Zweckmäßig: fester Review-Termin)

2. Die Review-Sitzung ist auf 2h beschränkt. Falls nötig wird eine weitere Sitzung, frühestens am nächsten Tag, einberufen.

3. Der Moderator sagt oder bricht die Sitzung ab, wenn die Sitzung nicht erfolgreich durchgeführt werden kann. Der Grund des Abbruchs ist zu protokollieren.

4. Der Prüfling, nicht der Autor steht zur Diskussion. Das heißt:

● Gutachter müssen auf Sprache und Ausdrucksweise achten.

● Der Autor darf weder sich noch den Prüfling verteidigen.

5. Die Rollen werden nicht vermischt. Insbesondere darf der Moderator nicht gleichzeitig als Gutachter fungieren.

6. Stilfragen (außerhalb der Richtlinien) werden nicht diskutiert.

41

Review-Regeln - 27. Problemlösen ist keine Aufgabe des Review-Teams. Befunde werden

nicht als Anweisungen an den Autor protokolliert.

8. Jeder Gutachter bekommt Gelegenheit, seine Befunde angemessen zu präsentieren.

9. Konsens der Gutachter zu jedem Befund wird laufend protokolliert.

10.Die einzelnen Befunde werden gewichtet als:

● Kritischer Fehler, Hauptfehler, Nebenfehler

● Gut (kein Fehler festgestellt)

11.Das Review-Team gibt eine Empfehlung über die Annahme des Prüflings ab:

● Akzeptieren ohne Änderungen

● Akzeptieren mit Änderungen

● Nicht akzeptieren

12.Am Schluss unterschreiben alle Teilnehmer das Protokoll.

42

Das Review als soziales Experiment

Wo Reviews eingeführt werden, bedeuten sie für die Beteiligten eine große Veränderung.

Zuerst werden die negativen Folgen sichtbar:

● Die Aussicht, als Autor im Review zu sitzen, macht Angst.

● Viele Entwickler sind Autodidakten!

Regeln, die die Anfangsprobleme entschärfen sollen:

● der Ausschluss des Vorgesetzten

● das Verbot, über Stilfragen zu diskutieren

● die Leitung des Reviews durch den erfahrenen Moderator

● die Dritte Stunde, die den Emotionen Auslauf gibt

● der regelmäßige Rollentausch

● ein objektives, technisches Kriterium, welche Resultate einem Review unterzogen werden.

43

Lohnt sich denn die ganze Mühe?

Klares Ja!

● Viele Fehler werden zu insgesamt akzeptablen Kosten entdeckt.Es wäre weit teurer, die Fehler nicht (oder nicht so) zu suchen.

● Die Zusammenarbeit der Entwickler wird besser, das Vertrauen zwischen den Software-Leuten deutlich höher; niemand fürchtet sich davor, die anderen um Rat zu fragen. Richtlinien werden nicht belächelt, sondern gelebt.

● Die Beteiligten entwickeln ein sachlich fundiertes Selbstbewusstsein und einen begründeten Stolz auf ihre Arbeit.

Wer einmal an Reviews gewöhnt ist, möchte auf keinen Fall mehr darauf verzichten.

44

Ein Erste-Hilfe-Kasten - 1

Reviews sind weltweit seit langem als wichtigste Technik der Software-Prüfung anerkannt

Ihr Nutzen ist klar nachgewiesen und von allen, die regelmäßig und systematisch Reviews durchführen, bestätigt.

Trotzdem gibt es viele Fälle, in denen die Einführung von Reviews gescheitert oder zu einer ohne Überzeugung betriebenen Formalübung degeneriert ist.

1. Für die Vorbereitung oder sogar für die Review-Sitzung selbst fehlt die Zeit → Reviews in der Planung berücksichtigen

2. Die Reviews finden in einer bis zur Unkenntlichkeit reduzierten Form statt → Standard (Minimalreview) vorgeben

3. Gute Moderatoren fehlen → Leute aussuchen und ausbilden

45

Ein Erste-Hilfe-Kasten - 2

4. Bezugsdokumente fehlen → suchen, anpassen, bereitstellen

5. Entwickler haben Angst → Erste Reviews gründlich vorbereiten (und auf die Ängste eingehen, selbst wenn sie geleugnet werden)

6. Reviews beißen sich an Äußerlichkeiten fest → ihre Bedeutung klarstellen, dann weiter. Beim zweiten Review aber diesen Punkt erneut betonen, nicht schleifen lassen.

7. Bezugsdokumente sind ungeeignet → diskutieren u. verbessern

8. Zeitdruck sabotiert Prüfungen → Klare Entscheid. der Prioritäten

9. Geprüfte Dokumente werden verändert → CM verbessern

10. Interesse an Reviews sinkt → mit Statistiken Erfolg nachweisen

46

Wann sind Reviews (noch) nicht sinnvoll?

Nur in wenigen Situationen ist von der Review-Einführung abzuraten:

a) wenn ein Projekt praktisch bereits gescheitert ist und die Verantwortlichen nach einem Wunder Ausschau halten,

b) wenn keinerlei Bezugsdokumente vorliegen,

c) wenn die Entwickler in feindliche Lager gespalten sind.

Was tun?

a) Retten, was zu retten ist, z.B. zentrale Dokumente (Spezifikation, Planung für das Rest-Projekt) in akzeptablen Zustand bringen.

b) Versuchsreview durchführen, Defizite erkennen, Arbeit an Bezugsdokumenten anstoßen.

c) Reviews zunächst separat weiterlaufen lassen, Gutachter zwischen den Lagern austauschen

47

13.6 Varianten der Software-Inspektion

Durchsicht

Führt der Entwickler allein durch.

Es ist zweckmäßig, dazu den Bildschirm zu verlassen und das (Teil-) Resultat in Ruhe, aus einer gewissen Distanz, zu überprüfen.

Die Durchsicht sollte selbstverständlich und obligatorisch sein!

Sie wird durch Reviews o.ä. nicht überflüssig.

In Zeiten der (reinen) Stapelverarbeitung war die Durchsicht einfach notwendig.

Heute wissen wir (u.a. durch Humphreys PSP), dass die Durchsicht effizienter ist als jeder (spontane) Test.

 

49

Stellungnahme

Ein „off-line“-Review unter der Regie des Autors.

Vorteile

● geringer Organisationsaufwand

Erhebliche Nachteile

● Ein Manager ist nicht beteiligt. Der Aufwand für die Stellungnahmen ist nicht geplant.

● Der Autor ist gleichzeitig Moderator. Er wählt die Gutachter aus, deren Engagement ungewiss bleibt.

● Das Dokument ändert sich während der Ausarbeitung der Stellungnahmen, ein Teil der Kommentare geht ins Leere.

● Ein Protokoll über die Befunde gibt es nicht. Die Nachbearbeitung geschieht nach dem Gutdünken des Autors und wird nicht kontrolliert.

50

Structured Walkthrough

Die Billig-Variante des Reviews

● Der Autor ist Moderator

● Er stellt sein Arbeitsergebnis Schritt für Schritt vor, die Gutachter werfen (vorbereitete oder spontane) Fragen auf und versuchen so, mögliche Probleme zu identifizieren. Die Probleme werden protokolliert.

● Der Autor kompensiert durch seine Präsentation die Einsparung (oder Reduktion) der Vorbereitung.

● Während seiner Vorbereitung entdeckt er selbst viele Fehler.

Varianten mit oder ohne Vorbereitung der Gutachter

Typische Anwendung: Programmcode.

Die Effizienz ist niedriger als beim Review!

51

Design and Code Inspection

Eingeführt von Michael Fagan, IBM

Die Edel-Variante der Reviews

● Mit Einführungssitzung. Dort werden der Prüfling und sein Umfeld vorgestellt, die Ziele des Reviews werden allen Beteiligten nochmals deutlich gemacht.

● Gutachter-Notizen, die abgegeben werden.

● Vorleser, der den Prüfling Seite für Seite vorliest, bevor dann zu dem vorgelesenen Teil die Befunde erfasst werden.

● Entscheidungskompetenz für die Freigabe des geprüften Arbeitsergebnisses

● Erhebung von Metriken

52

Fazit

Allgemein und für die Inspektionen im besonderen gilt:

„You get what you pay for!“

53