Softwareprozesse und Projektmanagement - Reviews/Inspections

INHALT

1 Einleitung
1.1 Aufgabenstellung
1.2 Vorgehensweise
1.3 Begriffserklärung

2 Inspektionen bzw. Reviews
2.1 Grundlagen und Abgrenzung
2.2 Reviews vs. Tests
2.3 Besondere Merkmale von Reviews und Review-Arten
2.3.1 Inspektionen
2.3.2 Team Review
2.3.3 Walkthrough
2.3.4 Pair Programming
2.4 Auswahl der geeigneten Review-Methode

3 Wie sind Inspektionen aufgebaut?
3.1 Rollenverteilung einer Inspektion
3.2 Prozessschritte einer Inspektion
3.2.1 Die Planung
3.2.2 Der Überblick
3.2.3 Die Vorbereitung
3.2.4 Die Inspektionssitzung
3.2.5 Die Nacharbeit
3.2.6 Die Betrachtung
3.2.7 Die Analyse
3.3 Wichtige Review-Regeln
3.4 Eventuelle auftretende Hindernisse
3.4.1 Die Führungsebene
3.4.2 Die Unternehmenskultur
3.4.3 Die Beteiligten

4 Fazit

Literaturverzeichnis

1 Einleitung

1.1 Aufgabenstellung

Programme werden aus einer Vielzahl von Gründen heraus geschrieben. Hierbei beschränkt sich die Bandbreite der Entwickler teilweise nicht nur auf Angestellte oder Kleinunternehmer, die direkt oder indirekt vom Vertrieb ihrer Software leben, sondern auch auf all jene, die ein Programm hauptsächlich aus dem Grund heraus schreiben, sich das Leben ein wenig leichter zu machen oder einfach nur effektiver arbeiten zu können.

„Vor allem dort, wo aus gutem Grunde nur von Programmen, nicht von Software gesprochen wird, besteht oft nicht der Wunsch oder die Möglichkeit, systematische Prüfungen durchzuführen“^[1]. Ob dieses gängige Vorgehen, also der Verzicht auf eine eingehende Prüfung der entwickelten Programme, sinnvoll ist oder eher als leichtsinnig bzw. fahrlässig angesehen werden sollte, bleibt offen. Fest steht jedoch, dass geprüfte Software überall dort, wo sie wirklich gebraucht wird, weniger Probleme verursacht und damit letzten Endes auch geringere Kosten erzeugt.^[2]

Die Software-Prüfung ist somit als wichtiges Instrument im Rahmen des Software-Engineering anzusehen. Wie aber lässt sich eine solche Prüfung der Software in der Realität verwicklichen? Welche Möglichkeiten stehen zur Verfügung, um eine Software möglichst effektiv zu prüfen und entstehende Kosten so gering wie möglich zu halten?

Mit eben diesen Fragestellungen will sich die vorliegende Arbeit auseinander setzen. Dabei werden sich die Ausführungen jedoch auf einen Teilbereich der Software-Prüfung – die Reviews – konzentrieren. Im Verlauf dieser Abhandlung soll die Frage geklärt werden, wie Inspektionen richtig eingesetzt werden und welche Hindernisse eventuell auftreten können.

1.2 Vorgehensweise

Ausgehend von einer einführenden Begriffserklärung wird sich die vorliegende Arbeit im folgenden damit beschäftigen, was ein Review bzw. eine Inspektion grundsätzlich auszeichnet und welche Vorteile diese Methode der Softwareprüfung gegenüber dem Testen hat. Daran anschließend werden verschiedene Arten von Reviews beleuchtet. Dabei sollen die Unterschiede und deren jeweilige Vor- bzw. Nachteile genauer betrachtet werden. Ein Hauptteil dieser Arbeit wird sich mit der Frage beschäftigen, welche Hindernisse bei der Durchführung von Reviews auftreten können und welche Wege es gibt, um diesen Hindernissen möglichst aus dem Weg zu gehen.

Abschließend soll ein kurzes Fazit zusammenfassend Aufschluss über die aufgeworfenen Fragestellungen geben und dem Leser alle in der Arbeit aufgegriffenen nochmals gebündelt vor Augen führen.

1.3 Begriffserklärung

In diesem Kapitel sollen einige grundlegende Begriffe definiert werden, auf die im weiteren Verlauf der Arbeit immer wieder zurückgegriffen wird. Die Definitionen stammen, soweit dies möglich war, aus den gleichen Quellen.

„Software bezeichnet alle nichtphysischen Funktionsbestandteile eines Computers. Dies umfasst vor allem Computerprogramme sowie die zur Verwendung mit Computerprogrammen bestimmten Daten. […] Software umfasst auch Dokumentationen, Handbücher und wird gelegentlich bis in die Schulungen und die Supportleistungen begrifflich geführt. Software wird häufig im Gegensatz zu Hardware gesetzt, welche den physischen Träger bezeichnet, auf dem Software existiert und funktioniert, und allein mit Hilfe dessen sie ihre Funktion erfüllen kann.^[3] “

Unter einem Fehler wird „eine Abweichung von einem optimalen oder normierten Zustand oder Verfahren^[4] “ verstanden. Tritt ein Fehler in einer Software auf, wird dieser als Programm- oder auch Softwarefehler bezeichnet. „Ein Programmfehler tritt in Computerprogrammen auf, wenn der Programmierer einen bestimmten Zustand in der Programmlogik nicht berücksichtigt hat, oder wenn die Laufzeitumgebung selber fehlerhaft arbeitet. Auch Unvollständigkeit, Fehler, Ungenauigkeiten, Mehrdeutigkeiten o.ä. in der Spezifikation des Programms können zu Bugs führen, bzw. als solche interpretiert werden. Es gibt eine Regel, nach der ein Computerprogramm ab einer bestimmten Größe immer auch Programmfehler beinhaltet.^[5] “

„Peer Review bezeichnet (allgemein) die Bewertung eines Objekts oder Prozesses durch unabhängige Gutachter, die sogenannten „Peers“ (engl. für „Ebenbürtige“)“^[6].

Im Bereich der Softwareprüfung sind unter anderem die folgenden Begriffe von Bedeutung: Prüfling, Autor, Manager und Kollege.

Unter dem Prüfling wird dabei ein Software-Produkt oder Software-Bestandteil, der einer Prüfung unterzogen werden soll, verstanden.^[7] Erstellt wurde der Prüfling durch den sogenannten Autor. Software entsteht in den meisten Fällen nicht ohne einen entsprechenden Auftrag. Eine entscheidende Rolle kommt dabei dem Manager, also jener Person zu, in deren Verantwortungsbereich der Prüfling erstellt wurde. Typischerweise wird als Manager der direkte oder indirekte Vorgesetzte des Autors oder die für die Freigabe des Prüflings zuständige Person, bezeichnet. Während der Manager dem Autor somit in einer hierarchisch übergeordneten Position gegenüber steht, bewegt sich ein Kollege normalerweise auf gleicher hierarchischer Ebene wie der Autor. Ihn kennzeichnet jedoch die Fähigkeit, dem Prüfling zumindest in Aspekten beurteilen zu können.

Die Begriffserklärungen sollen an dieser Stelle nicht weiter ausgebaut werden; sollten weitere spezielle Wendungen gebraucht werden, so erfolgt eine Definition an geeigneter Stelle.

2 Inspektionen bzw. Reviews

2.1 Grundlagen und Abgrenzung

Grundsätzlich existieren zwei unterschiedliche Verfahren, um eine Software-Prüfung durchzuführen. Unterschieden werden dabei statische und dynamische Verfahren. Während die dynamischen Verfahren in Ausprägung von Tests den meisten Nutzern von Software wohl bekannt sein dürften, fristen Inspektionen bzw. Reviews ein eher unbeachtetes Dasein. Reviews sind statische Verfahren und bilden somit neben den Tests die zweite Gruppe möglicher Prüfverfahren für Software.

Während ein Test stets an den Rechner gebunden ist und somit bei weitem nicht alle Programmeigenschaften prüfen kann, vermag ein Review auch das beurteilen, was ein Rechner nicht „sieht“.^[8] Tests beschränken sich in der Regel auf den ausführbaren Quelltext des Programms. Dokumentationen, Spezifikationen, Handbücher etc. finden keine Beachtung. Reviews hingegen finden nicht am Rechner statt. Somit sind alle Beteiligten gezwungen, den Prüfling „per Hand“ zu untersuchen. Einem Review sind somit grundsätzlich alle Programmteile zugänglich, die in schriftlicher Form vorgelegt werden können. Das grundlegene Prinzip eines Reviews beruht darauf, den Prüfling abseits der rechnergestützten Verarbeitung auf verschiedene Aspekte hin zu untersuchen. Ziel ist es dabei, ähnlich wie beim Testen, Fehler ausfindig zu machen und nicht etwa, diese zu beseitigen. Um die erfolgreiche Durchführung von Reviews gewährleisten zu können, ist die Einhaltung verschiedener formaler Vorschriften von Nöten, auf die im weiteren Verlauf der Arbeit noch eingegangen wird. Nachdem bereits einführend erläutert wurde, worin der wesentliche Unterschied zwischen Tests und Reviews besteht, sollen im Weiteren die entscheidenden Vorteile der Reviews gegenüber den dynamischen Prüfverfahren dargestellt werden.

2.2 Reviews vs. Tests

Der wohl größte Vorteil der Reviews wurde bereits angesprochen, er besteht in der Möglichkeit, alle Entwicklungsergebnisse zu prüfen und keiner Beschränkung lediglich auf ausführbare Programmteile zu unterliegen. „Der Nutzen eines Software-Produkts ist bestimmt durch die Übereinstimmung zwischen Produkt und tatsächlichen Anforderungen sowie durch zusätzliche Leistungen und andere Eigenschaften, die nicht gefordert waren, aber als vorteilhaft empfunden werden.^[9] “ Die Entwicklung von Software verursacht Kosten, die sich nicht in die sogenannten Herstellungskosten und die Qualitätskosten unterteilen lassen. Für den Bereich der Softwareprüfung ist vor allem eine genauere Betrachtung der Qualitätskosten interessant, da diese „alle (zusätzlichen) Aufwendungen für das Verhüten, Erkennen, Lokalisieren und beheben von Fehlern sowie die eventuellen Folgekosten der Fehler, die erst im Betrieb auftreten^[10] “ umfassen. Das Fatale an Fehlerkosten ist, dass diese erst dann wirklich realistisch eingeschätzt werden können, wenn die Entwicklung der Software bereits abgeschlossen und das Programm ausgeliefert wurde. Die Investition in ausreichende Fehlerverhütungs- bzw. Prüfkosten ist somit auf lange Sicht gesehen in jedem Fall ratsam. Diese Erkenntnis wird umso mehr relevant, als dass es kein Geheimnis ist, dass insbesondere die Fehlerbehebungskosten „mit der Latenzzeit eines Fehlers exponentiell“^[11] ansteigen. Wird ein Fehler also bereits in der Anforderungsanalyse gemacht, steigen die Kosten für dessen Behebung auf das Mehrfache an, wenn dieser nicht umgehend, sondern beispielsweise erst nach der Auslieferung behoben wird. Fehler in den frühen Phasen des Softwareentwicklungsprozesses haben also den höchsten Kostenanteil an den Fehlerbehebungskosten und sollten folglich auch bei Prüfungen eine besondere Beachtung finden. Mit Hilfe von Tests können aber genau solche Fehler erst sehr spät erkannt werden; „das Mittel für die Früherkennung der Fehler sind daher Reviews“^[12]. Die Möglichkeit, alle Softwareartefakte einem Review zugänglich zu machen, trägt also dazu bei, Fehler bereits in frühen Phasen der Entwicklung ausfindig zu machen und verschafft Reviews hier einen entscheidenden Vorteil gegenüber der Softwareprüfung mit Hilfe von Tests.

Neben dem Kostenargument sprechen noch einige andere Faktoren für den Einsatz von Reviews. Während ein Test zwar das Vorhandensein eines Fehlers aufdecken kann, vermag er nicht die Fehlerursache aufzuzeigen. Die Lokalisierung der Fehlerursache stellt damit nicht selten ein weitaus größeres Problem dar, als die eigentliche Beseitigung des Fehlers.^[13] Ein Review stößt hingegen gleichzeitig auf Fehler und Fehlerursache. Die Behebung des Fehlers kann umgehend in der sich an das Review anschließenden Nacharbeitszeit behoben werden.

Da allerdings auch Reviews nicht frei von Nachteilen sind, sollte in keinem Fall der Eindruck erweckt werden, dass Tests komplett zu ersetzen seien. Vielmehr sollten Reviews zusätzlich zu Tests eingesetzt werden, um die volle Bandbreite der Softwareprüfung ausnutzen zu können und immer die Möglichkeit zu haben, das richtige und effektivste Instrument auswählen zu können.

2.3 Besondere Merkmale von Reviews und Review-Arten

In der Literatur existieren zum Teil keine klaren Definitionen des Begriffs Review bzw. Inspektion. Dementsprechend unterschiedlich fallen auch die Darstellungen diverser Unterarten des Reviews aus. Während bei Frühauf, Ludewig und Sandmayr (2004) der Begriff Inspektion gar nicht aufgegriffen wird, machen Gilb und Graham (1993) ihre eigene Auffassung von Inspektionen zum Thema eines kompletten Buches. Die Ausführungen dieser Arbeit werden sich ausschließlich auf die Darstellung in Wiegers (2002) beziehen.

[...]

^[1] Frühauf, Ludewig, Sandmayr / Software-Prüfung / 14

^[2] Vgl. Frühauf, Ludewig, Sandmayr / Software-Prüfung / 14

^[3] http://de.wikipedia.org/wiki/Software

^[4] http://de.wikipedia.org/wiki/Fehler

^[5] http://de.wikipedia.org/wiki/Programmfehler

^[6] http://de.wikipedia.org/wiki/Peer-Review

^[7] Vgl. Frühauf, Ludewig, Sandmayr / Software-Prüfung / 27

^[8] Vgl. Frühauf, Ludewig, Sandmayr / Software-Prüfung / 23

^[9] Frühauf, Ludewig, Sandmayr / Software-Prüfung / 17

^[10] Frühauf, Ludewig, Sandmayr / Software-Prüfung / 17 f.

^[11] Frühauf, Ludewig, Sandmayr / Software-Prüfung / 19

^[12] Frühauf, Ludewig, Sandmayr / Software-Prüfung / 19

^[13] Vgl. Frühauf, Ludewig, Sandmayr / Software-Prüfung / 23