Werkzeuggestützte Reviews

Transkript

1 Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Werkzeuggestützte Reviews Bachelorarbeit im Studiengang Informatik von Danijel Stanić Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Wolfgang Nejdl Hannover, Mai 2006

2 Vorwort Reviews sind eine heute weit verbreitete und akzeptierte Qualitätssicherungsmaßnahme, die sich durch eine hohe Effektivität und Effizienz in der Praxis bewährt haben. Diese können in den verschiedenen Projektphasen eingesetzt werden, um möglichst früh Fehler zu erkennen und eine hohe Qualität des Endprodukts Software zu gewährleisten. Jedoch stellen Reviews gerade in der Belegung von Ressourcen einen hohen Kostenfaktor da. Außerdem benötigen Reviews eine strenge Zeitplanung und verursachen somit in einem Software- Entwicklungsprozess einen noch größeren Zeitdruck. Dieses sind die wesentlichen Gründe, warum Reviews in der Praxis oft unsystematisch eingesetzt werden, was zur Folge hat, dass die Praxis einen geeigneten Tool-Einsatz fordert, obwohl es zahlreiche Ansätze für verschiedene Tools gibt. Diese Bachelorarbeit beschäftigt sich damit verschiedene Ansätze von Review-Techniken und bereits vorhandenen Review-Tools zusammenzufassen, um daraus einen geeigneten Ansatz zu entwickeln, um den gegenwärtigen Forderungen für ein Review-Tool näherungsweise gerecht zu werden. i

3 Danksagung Ich bedanke mich bei Herrn Dipl.-Math. Thomas Flohr für die hervorragende Betreuung meiner Bachelorarbeit. ii

4 Inhaltsverzeichnis 1 Einleitung Zielsetzung Gliederung Qualitätssicherung Definition Qualitätssicherungsmaßnahmen Einordnung von Reviews in die Qualitätssicherung Reviews Rollen bei einem Review Features von Review-Techniken Lesetechniken Variationen von Review-Techniken Fagan Bisant Gilb Meetingless Inspection Active Design Review Britcher Phased Inspection N-fold Code Reading FTarm (Formal Technical Asynchronous Review Method) Structured Walkthroughs Humphrey Formal Technical Review (FTR) Weitere Review-Verfahren Inspektion nach IEEE Vergleich von Review-Techniken Ausblick: Review-Techniken Stand in der Praxis Exkurs: CSCW Klassifikationen Raum/Zeit-Matrix K-Modell Einordnung von Reviews in die Klassifikationen Herausforderungen Tool-Support für Reviews Features von Review-Tools Tools der 1. Generation Tools der 2. Generation Tools der 3. Generation Tools der 4. Generation Einführung in die nächste Generation Vergleich von Review-Tools Beispiel: Internet Based Inspection System (IBIS) Beispiel: ReviewPro iii

5 6 Eigener Ansatz für ein Review-Tool Features Ablauf Planung Übersicht Kick-Off Befundssuche Diskriminierung Dritte Stunde Rework Follow-Up Nacharbeit Zusammenfassung Bewertung des eigenen Ansatzes Ausblick für die Zukunft Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis iv

6 1 Einleitung Reviews sind eine akzeptierte und weit verbreitete Technik, um während des Software- Entwicklungsprozesses gezielt Fehler aufzudecken. Projekte in der Praxis haben gezeigt, dass Fehler, die sich früh im Entwicklungsprozess eingeschleicht haben, nicht nur in den späteren Phasen weiter getragen werden, sondern sich der Aufwand für ihre Behebung und somit auch die Kosten exponentiell ansteigt. Um dem entgegenzuwirken können Reviews schon möglichst früh und nach jeder Phase eingesetzt werden wie Abbildung 1 zeigt. Erfahrungen mit Reviews haben gezeigt, dass sie bis zu 80 % Fehler aufdecken können. Somit sind Reviews diesbezüglich sehr effektiv und effizient. Zusätzlich werden durch Reviews die Entwicklungsverfahren dokumentiert und auch Zwischenergebnisse fixiert, um Vertrauen des Entwicklungsprozesses zu schaffen. Durch den Einsatz von Metriken beim Review-Prozess kann auch der Projektfortschritt festgehalten werden, um sich mit dem bisherigen Verlauf kritisch auseinander zu setzen und damit gegebenenfalls die Projektplanung zu aktualisieren. Ein Vorteil von Reviews gegenüber anderen Testmethoden ist, dass Aspekte geprüft werden können, die man sonst nicht prüfen kann, da die zu viel Semantik enthalten. Darunter fallen die Aspekte Gebräuchlichkeit, Wiederverwendbarkeit, Portabilität und andere. Abbildung 1: Reviews in einem Software-Entwicklungsprozess [1] Nach den aufgezählten positiven Eigenschaften stoßen Reviews in der Praxis dennoch auf Widerstand. Gründe, die dafür genannt werden, sind, dass sie hohe Kosten verursachen. Der vorwiegende Faktor ist dabei die Belegung von Ressourcen. Es muss ein Raum mit den nötigen technischen Apparaturen verschafft und alle Teilnehmer auf einen festen Termin abgestimmt werden. Vor allem ist ein Review mit einem hohen Personalaufwand verbunden. Ein weiterer Grund ist, dass die enge Zeitplanung von Reviews in einem Projekt zusätzlich zu einem höheren Zeitdruck führt. Reviews sind demnach zeitintensiv und benötigen eine genaue Planung, um überhaupt effektiv und effizient zu sein. Dieses stellt eine Herausforderung an Unternehmen und spezifischen Projekten bei nicht gegebenen Möglichkeiten. Diese Gründe für einen Widerstand gegen Reviews haben zur Folge, dass man einen geeigneten Tool-Einsatz für die Praxis fordert, um die Kosten zu senken und den Zeitdruck zu minimieren. Durch den Tool-Einsatz für Reviews ergeben sich neue Möglichkeiten ein Review durchzuführen. Die häufigste Form von Arbeitsgruppen, die man im täglichen Projektgeschäft vorfindet, sind geographisch verteilte Gruppen. Ohne Tool-Einsatz ist es jedoch schwierig diese Form von geteilter Arbeit zu unterstützen. Tools sollen dazu beitragen die Gruppenmitglieder bei ihrer individuellen Arbeit zu unterstützen und deren Arbeit als Gesamtes zu koordinieren. Dieses macht auch eine Review-Sitzung überflüssig. Somit werden die Kosten gesenkt, da die Belegung von Ressourcen nicht mehr so stark und die Absprache von Terminen nicht mehr so eng ist. Der zeitliche Rahmen wird größer und der Aufwand der Koordination von Tätigkeiten der einzelnen Gruppenmitglieder kann durch den Tool-Einsatz verringert werden. 1

7 1.1 Zielsetzung Diese Bachelorarbeit umfasst mehrere Aufgaben. Eine Aufgabe ist es, Review-Verfahren zu beschreiben, sie zu vergleichen und zu bewerten. Nach einem kurzen Exkurs in die Rechnergestützte Gruppenarbeit (CSCW) werden bereits vorhandene Review-Tools klassifiziert und beschrieben. Dieses bildet den Schwerpunkt dieser Arbeit. Es wird insbesondere auf Tools eingegangen, die geographisch verteilte Gruppen unterstützen. Davon ausgehend wird ein eigener Ansatz für ein Review-Tool erstellt. Es werden alle nötigen Tätigkeiten beschrieben und in zeitlicher Folge gebracht. Dieser Ablauf wird mittels eines UML-Aktivitätsdiagramms dargestellt. Als Abschluss der Anforderungsbenennung wird ein Oberflächenprototyp erstellt, der die Anforderungen aufzeigt. Abschließend wird eine Bewertung des eigenen Ansatzes durchgeführt. Es sollen gezielt Schwachstellen ausgemacht werden, aber auch Vorteile gegenüber anderen Review-Tools benannt werden. 1.2 Gliederung Im zweiten Kapitel sollen grundlegende Begriffe des Qualitätsmanagements erläutert werden, um anhand davon Reviews im Gesamtkontext einordnen zu können. Dieses beinhaltet vor allem den Begriff der Software-Qualität, der Definition der Qualitätssicherung und der Qualitätssicherungsmaßnahmen. Der dritte Abschnitt geht schwerpunktmäßig auf die verschiedenen Review-Techniken und deren Variationen ein. Bevor jedoch dieses geschieht werden grundlegende Definitionen und Merkmale erläutert, um die Unterschiede der verschiedenen Review-Techniken aufzeigen zu können. Nach dem Aufzeigen der Unterschiede soll danach kurz ein Ausblick gegeben werden und der Stand in der Praxis erfasst werden. Der vierte Teil ergibt einen Exkurs in den Bereich Computer Supported Cooperative Work (kurz: CSCW). Es ist deswegen ein Exkurs, weil sich diese Arbeit nicht direkt mit der CSCW-Forschung beschäftigt, sondern lediglich Begriffe, Definitionen und Ergebnisse davon für die Charakterisierung von Review-Tools benutzt. Der Schwerpunkt dabei sollen verschiedene Klassifikationen von Tools für die Gruppenarbeit sein. Das fünfte Kapitel beschreibt zunächst die historische Entwicklung und darauf die allgemeinen Merkmale von Review-Tools. Es sollen die schon vorhandenen Tools klassifiziert werden und schließlich auch beschrieben werden. Nachdem dieses geschehen ist, wird eine Einführung in die nächste Tool-Generation gegeben, um auf dem aktuellsten Stand hinzuweisen. Der sechste Teil liefert schließlich einen eigenen Ansatz für ein Review-Tool. Dabei soll zunächst auf die allgemeinen Merkmale eingegangen werden, bevor der detaillierte Ablauf aufgezeigt wird. Hierbei verwende ich UML-Aktivitätsdiagramme und Screenshots eines selbst erstellten Oberflächenprototyps. Der letzte und siebte Abschnitt ergibt eine kurze Zusammenfassung. Er zeigt den aktuellen Stand, die Bewertung des eigenen Ansatzes und den Ausblick für die Zukunft. 2

8 2 Qualitätssicherung Eines der zentralen Begriffe bei der Qualitätssicherung ist der Qualitätsbegriff selber. Um das Verständnis dieses Begriffs zu verdeutlichen, wird hier Gebrauch von DIN-Normen gemacht. Qualität wird nach DIN Teil 11 wie folgt definiert: Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht Bevor speziell der Begriff der Software-Qualität erwähnt wird, soll der Begriff der Software selber geklärt werden. Der Begriff Software ist nach IEEE Std wie folgt definiert: Computerprogramme, Prozeduren und möglicherweise assoziierte Dokumentation und Daten, die den Betrieb eines Computersystems betreffen Entgegen dem Begriff der Software, der auch alle dazugehörigen Dokumentationen beinhaltet, meint Softwareprodukt alleine das ausführbare Programm oder im Falle von Open- Source-Software noch zusätzlich den Quellcode. Die Software-Qualität wird nach DIN ISO 9126 definiert als: 2.1 Definition Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen Für das Verständnis des Begriffs der Qualitätssicherung soll hier ihre Definition nach DIN EN ISO 8402 erfolgen: alle geplanten und systematischen Tätigkeiten, die innerhalb des Qualitätsmanagementsystems verwirklicht sind, und die wie erforderlich dargelegt werden, um angemessenes Vertrauen zu schaffen, dass eine Einheit die Qualitätsforderungen erfüllen wird 2.2 Qualitätssicherungsmaßnahmen Hier werden in drei unterschiedlichen Maßnahmen unterschieden. Diese sind analytische, konstruktive und organisatorische Maßnahmen. Manche Autoren wie Balzert [2] unterscheiden bei den analytischen Maßnahmen zwischen analysierenden und testenden Maßnahmen, was aber nicht genormt und standardisiert ist. Im Folgenden seien diese drei Maßnahmen nach Zuser et al. [3] beschrieben. 3

9 Konstruktive Maßnahmen sind diejenigen Aktivitäten, die a priori Qualität gewährleisten sollen. Im Wesentlichen fallen dabei drei Aufgaben an. Eine Aufgabe ist es technische Methoden und geeignete Werkzeuge einzusetzen, um den Software-Erstellungsprozess in eine bereits definierte Richtung zu lenken. Dadurch erreicht man, dass von Anfang an eines Prozesses Fehlerquellen vermieden werden, was aber nicht technische Fehler beinhaltet. Eine weitere Aufgabe ist Standards vor der Durchführung von Aktivitäten zu definieren und sie ggf. an das Projekt anzupassen. Vor allem der zweite Aspekt ist hier besonders zu erwähnen. Standards und Aktivitäten müssen immer angemessen sein. Sind diese Standards nicht konform mit dem Projekt oder der Organisation, so kann sich der Aufwand erhöhen, was aber nicht notwendig ist. Dieses führt zu einer Demotivierung, sinnlose Aktivitäten durchzuführen und mindert damit die Qualität des Prozesses oder des Produkts. Im Gegensatz zu den konstruktiven Maßnahmen versuchen analytische Maßnahmen die Qualität im Nachhinein zu beurteilen. Dabei werden vier Aufgaben benannt. Eine Tätigkeit ist es, die definierten Standards nach ihrer Einhaltung zu überprüfen. Eine weitere Aufgabe ist das Sammeln von Daten. Unterschieden werden dabei in Nutz- und Aufwandsdaten. Diese dienen dazu, Prozesse, Produkte und Zwischenergebnisse zu bewerten, um auch Änderungen vornehmen zu können und damit eine höhere Qualität zu garantieren. Charakteristisch hierfür ist der Einsatz von Metriken. Zwei Maßnahmen sind, das Unternehmen und deren Prozessen zum einen von außen als auch von innen zu beurteilen. Die äußeren Beurteilungen werden Audits genannt und zertifizieren ein Unternehmen. Die inneren Beurteilungen dienen zur internen strategischen Planung der Qualitätssicherung. Die letzte hier zu erwähnende Aufgabe ist es, Aufzeichnungen und Berichte zu erstellen. Zugänglich sollen diese für das Management und dem Kunden sein, um den aktuellen Stand des Projekts festzuhalten und auch Lösungsvorschläge abzugeben. Obwohl Zuser et al. diese Tätigkeit den konstruktiven Maßnahmen zuordnen, sind es jedoch analytische Maßnahmen oder zumindest Ergebnisse davon. Organisatorische Maßnahmen betten konstruktive und analytische Maßnahmen in die Organisationsstruktur ein. Hierzu dienen zwei Aufgaben. Eine Aufgabe ist das Anwenden eines Vorgehensmodells, was an die Projekte und Organisationsstrukturen angepasst werden soll. Eine weitere organisatorische Aktivität ist, Rollen zu definieren und Karriereplanung durchzuführen. Zentral dafür sind Aus- und Weiterbildung. Damit wird Mitarbeitern ein Anreiz gegeben, um auch längerfristig im Unternehmen zu verbleiben und somit Wissensund Erfahrungsaufbau im Sinne der Qualitätssicherung zu erlangen. 2.3 Einordnung von Reviews in die Qualitätssicherung Reviews lassen sich zu allen drei Qualitätssicherungsmaßnahmen in Beziehung setzen. Bei den konstruktiven Maßnahmen ist der Einsatz von Review-Werkzeugen wünschenswert, um damit den Prozess zu lenken. Auch sind für die hohe Effektivität eines Reviews die Definition und die Anpassung des Review-Prozesses notwendig, um eine hohe Effektivität zu gewährleisten. Organisatorische Maßnahmen müssen erfolgen, um Reviews in einem Unternehmen einbinden zu können. Daher muss ein Vorgehensmodell gewählt werden, wo man Reviews mit einschließen kann. Wichtig für Reviews ist auch das Definieren von Rollen. In Kapitel 3.1 soll da näher eingegangen werden. Besonders zu erwähnen ist der Moderator, der bestimmte Fähigkeiten mitbringen muss und ggf. für diese Rolle aus- oder weitergebildet werden muss. 4

10 Der Schwerpunkt des Einsatzes von Reviews ist jedoch in den analytischen Maßnahmen zu finden. Reviews versuchen nach der Erstellung von Dokumenten ihre Qualität zu beurteilen. Sie decken Schwachstellen auf und überprüfen auch die vordefinierten Standards. Bei einem Review-Prozess fallen auch Nutz- und Aufwandsdaten an, um auch den Prozess zu bewerten. Schließlich wird bei einem Review-Prozess auch ein Bericht für das Management erstellt. Damit sind Reviews eindeutig den analytischen Maßnahmen zuzuordnen. Um den analytischen Charakter zu betonen, sollen an dieser Stelle IEEE-Definitionen benutzt werden, die Software-Inspektionen (was hier als Synonym zu Reviews verwendet werden kann) und ihren Zweck zu definieren. Definition von Inspektionen nach ANSI/IEEE Std : eine formale Evaluationstechnik, bei der Anforderungen, Design oder Code von Software in Detail durch eine Person oder eine Gruppe, außer dem Autor, überprüft werden, um Fehler, Verletzungen von Entwicklungsstandards und andere Probleme zu entdecken Definition des Zwecks von Software-Inspektionen nach ANSI/IEEE Std (IEEE Standard for Software Reviews and Audits): um Software-Bestandteil-Defekte zu entdecken und zu identifizieren. Sie ist eine strenge und formale Entdeckungstechnik, die Folgendes zum Inhalt hat: verifiziert, dass die Software-Elemente den Anforderungen genügen verifiziert, dass die Software-Elemente zu den verwendeten Standards konform sind identifiziert Abweichungen von Standards und Anforderungen sammelt Software-Engineering-Daten (z.b. Fehler- und Aufwandsdaten) kümmert sich nicht um Alternativen oder stilistische Angelegenheiten 5

11 3 Reviews In diesem Kapitel sollen verschiedene Ansätze für Review-Techniken aufgezeigt werden. Bevor auf die Review-Techniken eingegangen werden, sollen zunächst die Grundlagen noch mal erwähnt werden. Das Kapitel schließt damit ab, die Verfahren zu vergleichen, den aktuellen Stand in der Praxis zu erfassen und einen Ausblick zu geben. 3.1 Rollen bei einem Review Eines der Grundlagen ist, welche Rollen dabei anfallen und was diese zu leisten haben. Frühauf et al. [4] beschreiben diese Rollen wie folgt: Der Manager, oder auch der Projektleiter, gibt den Auftrag für die Erstellung des Prüflings und ist verantwortlich für dessen Freigabe. Damit hat der Manager auch das größte Interesse, dass der Prüfling durch ein Review geprüft wird. Der Manager gibt den Auftrag für ein Review und wählt den Moderator aus. Danach zieht er sich zurück und überlässt dem Review- Team die Arbeit. Er ist nur an den Ergebnissen interessiert. Der Autor erstellt den Prüfling und nimmt sonst nur passiv an einem Review teil. Er sollte jedoch dem Review-Team für Fragen während des gesamten Reviews zur Verfügung stehen. Des Weiteren kann ihm der Auftrag erteilt werden, den Prüfling nachzubearbeiten. Der Moderator ist der Leiter des Reviews. Er ist für den ordnungsgemäßen Ablauf verantwortlich. Seine Aufgaben sind es, Reviews zu organisieren und zu planen. Ein wichtiger Aspekt sind seine sozialen Kompetenzen. Er muss dafür sorgen, dass bei einem Review stets der richtige Ton und unter den Gutachtern Konsens herrscht. Es wird der Prüfling und nicht der Autor geprüft. Das Review darf nicht ausarten und demnach steht ihm die Rolle des Lenkers zu. Hier sieht man, dass der Moderator besondere Fähigkeiten, nämlich die der Kernkompetenzen, benötigt, die entsprechend geschult werden müssen. Die Gutachter bewerten den Prüfling nach gegebenen Aspekten oder nach einem bestimmten Vorgehen. Ihr Ziel ist es also, Defekte im Prüfling auszumachen. Wichtig ist, dass sie nicht den Autor bewerten. Sie müssen zu einem Konsens kommen und eine Empfehlung abgeben. Der Aktuar nimmt die Rolle des Protokollanten ein. Nach Frühauf [4] et al. kann diese Rolle zusätzlich von einer an einem Review bereits teilnehmenden Person besetzt werden. Der Autor kann dafür in Frage kommen, da er bereits passiv teilnimmt und sowieso keine weiteren Aufgaben hat. Auch die Gutachter können abwechselnd diese Rolle einnehmen. Zu beachten ist, dass ein Gutachter nicht seine eigenen Befunde protokolliert. Der Moderator könnte auch die Rolle des Aktuars übernehmen, aber nur wenn er nicht mit dem gleichzeitigen Moderieren und Protokollieren überfordert ist. Das Review-Team setzt sich somit aus dem Moderator, den Gutachtern und dem Aktuar zusammen. Das ganze Team trägt die Verantwortung für die Ergebnisse aus dem Review. 6

12 3.2 Features von Review-Techniken Hier sollen die Merkmale benannt und beschrieben werden, die die Unterschiede zwischen verschiedenen Variationen von Review-Techniken besonders verdeutlichen. Dazu benutzen Porter und Votta [5] folgende Merkmale: Teamgröße: In den Variationen der Review-Techniken findet man auch Variationen in der Teamgröße. Hier werden in großen, kleinen und mittleren Teams unterschieden. Anzahl der Sitzungen: Dieses meint hier wie oft ein Prüfling einen Review-Prozess durchläuft. Bei multiplen Sitzungen werden mehrere Review-Teams mit der Prüfung des selben Prüflings beauftragt oder ein großes Review-Team wird in kleinere Teams aufgeteilt. Koordination von multiplen Sitzungen: Gibt es multiple Sitzungen, so müssen diese auch entsprechend koordiniert werden. Man unterscheidet da parallele und sequenzielle Sitzungen. Bei parallel-multiplen Sitzungen wird bei jeder Sitzung die selbe Version des Prüflings geprüft. Bei sequenziell-multiplen Sitzungen werden die entdeckten Befunde erst nachbearbeitet, bevor in die nächste Sitzung gewechselt wird. Kollektionstechnik: Man unterscheidet danach, ob eine Review-Sitzung des Review-Teams stattfindet oder nicht. Die Review-Sitzung meint in dieser Arbeit nicht die Sitzung wie vorher beschrieben, sondern das Zusammentreffen des Review-Teams. Defektdetektionsmethode: Als Synonym kann hierfür auch Lesetechnik benutzt werden. Damit meint man Techniken, die Gutachtern ermöglichen, nach bestimmten Kriterien oder nach einem bestimmten Vorgehen die Befunde zu entdecken. In Kapitel 3.3 soll gesondert darauf eingegangen werden. Gebrauch von Post-Collection-Feedback: Bei manchen Review-Techniken wird nach der Review-Sitzung noch eine weitere drangehängt. Das Ziel ist dabei, dass alle Teilnehmer Erfahrungen, die sie mit dem Review gemacht haben, austauschen und über den Verlauf des Reviews reflektieren. Dadurch soll der Lernprozess einer Gruppe gefördert werden. 3.3 Lesetechniken Lesetechniken ermöglichen es, Gutachtern nach bestimmten Kriterien oder nach einem bestimmten Vorgehen Befunde zu entdecken. Ein unsystematisches Vorgehen wird oft in diesem Zusammenhang als Ad Hoc bezeichnet. Es bestehen schon sämtliche Techniken, die systematisch angewendet werden. Im Folgenden werden diese Lesetechniken kurz erwähnt und beschrieben. 7

13 Checklistenbasiertes Lesen nach Frühauf et al. [4]: Bei dieser Lesetechnik arbeiten die Gutachter einen Fragenkatalog ab. Diese Fragenkataloge enthalten Richtlinien und Fragen zu vermuteten Schwachstellen im Prüfling. Diese Fragen müssen möglichst präzise formuliert werden und mit ja oder nein beantwortet werden. Eine Variation ist es einzelne Fragen bestimmten Gutachtern zuzuordnen. Dieses nennt man dann fokussierte Checkliste. Für ein Review muss zunächst ein Standard-Fragebogen erstellt werden und dann auch Fragen hinzugefügt werden, die spezifisch für ein Dokument in dieser Projektphase sind. Zusätzlich hat man die Annahme, dass bestimmte Autoren auch immer wieder bestimmte Fehler machen. Aus dieser Erfahrung heraus soll man dann auch entsprechend Fragen ausformulieren. Defektbasiertes Lesen nach Porter et al. [6]: Diese Lesetechnik gehört zur Gruppe der szenariobasierten Lesetechniken. In diesem Fall wird das Lesen von Anforderungsdokumenten unterstützt. Das Ziel des defektbasierten Lesens ist es, bestimmte Fehlertypen zu finden. Dazu werden Szenarios definiert, die genau beschreiben wie dabei vorzugehen ist. Porter und Votta [7] beschreiben drei Szenarios, um bestimmte Fehlerklassen zu entdecken. Die Szenarios zielen auf Datentypinkonsistenz, falsche Funktionalität und Zweideutigkeiten oder fehlender Funktionalität ab. Anders als beim checklistenbasierten Lesen wird zum einen mehr Struktur in das Lesen gebracht und zum anderen beschreibt diese Technik nicht nur, wonach man suchen soll, sondern auch wie genau dabei zu verfahren ist. Perspektivbasiertes Lesen nach Basili [8]: Auch das perspektivbasierte Lesen gehört zur Gruppe der szenariobasierten Lesetechniken. Anders als beim defektbasierten Lesen kann diese Lesetechnik auch für andere Dokumenttypen als nur den Anforderungsdokumenten verwendet werden. Hier werden Szenarios entsprechend verschiedener Sichten ausformuliert. Eine Annahme ist, dass ein Gutachter mit einem spezifischen Fokus bessere Performanz liefert als ein Gutachter, der alle Fehlerklassen prüfen muss. Eine weitere Behauptung ist, dass mehrere Foken kreiert werden können und diese eine vollständige Überdeckung des Ganzen gewährleisten. Eine wichtige These ist, dass es für einen Gutachter leichter ist Fehler zu entdecken, wenn er strukturiert arbeitet und aktiv liest. Ein Gutachter kann somit schon früher bestimmte Fehler entdecken, die sonst erst später entdeckt werden können. Basili et al. [8] nennt drei Perspektiven, die berücksichtigt werden müssen. Diese sind die Perspektive des Designers, des Testers und des Users. Traceability-basiertes Lesen nach Basili et al. [9]: Diese Lesetechnik gehört ebenfalls zu den szenariobasierten Lesetechniken. Diese Lesetechnik unterstützt das Lesen von objekt-orientierten Designdokumenten. Diese Methode wird in vertikales und horizontales Lesen geteilt. Das vertikale Lesen soll prüfen, ob das Design zu den Anforderungen korrespondiert. Das horizontale Lesen prüft die Design- Artefakte gegeneinander (z.b. Klassendiagramme usw.). Damit ist eine Verfolgbarkeit gewährleistet. Usage-basiertes Lesen nach Thelin et al. [10]: Die grundlegende Annahme dieser Lesetechnik ist, dass nicht alle Fehler entdeckt werden müssen, sondern man sich auf diejenigen Fehler konzentrieren muss, die den größten negativen Einfluss auf die Qualität der zu erstellenden Software haben. Diese Lesetechnik kann für jede Art von Dokumenten eingesetzt werden. Dabei werden dem Gutachter Use-Cases zur Verfügung gestellt. Diese beinhalten, was Benutzer oder eine Gruppe von Benutzern für wichtig halten und fokussiert die Gutachter darauf. 8

14 Bevor die Gutachter die Use-Cases durcharbeiten, müssen diese priorisiert werden. Der Gutachter arbeitet dann die Use-Cases nacheinander ab angefangen mit der am höchsten eingestuften. Man unterscheidet noch das rangbasierte Lesen und das zeitkontrollierte Lesen. Beim rangkontrollierten Lesen werden die Use-Cases ihrer Priorität entsprechend abgearbeitet. Beim zeitkontrollierten Lesen wird jedem Use-Case eine bestimmte Zeit vorgegeben, wonach es abgearbeitet werden soll. Hoch priorisierte Use-Cases sollen mehr Zeit zur Abarbeitung gegeben werden als niedrig priorisierten Use-Cases. Metrikbasiertes Lesen nach Bernardez et al. [11]: Das metrik-basierte Lesen ist eine Lesetechnik, die nur bei einem bestimmten Anforderungsdokument, nämlich den Use-Cases, zum Einsatz kommt. Dabei werden Heuristiken angewendet, die besagen, dass es eine Beziehung zwischen bestimmten Metriken in Use-Cases und bestimmten Neigungen zu möglichen Defekten gibt. Jede Heuristik definiert einen Schwellwert für eine Use-Case-Metrik. Beim Überschreiten dieser Schwellwerte nimmt man an, dass es sehr wahrscheinlich ist, einen Defekt vorliegen zu haben. Liegt ein Defekt vor, kann man ihn auch einer bestimmten Fehlerklasse durch die spezifischen Heuristiken zuordnen. Es existieren empirische Studien, die die Effektivität von Lesetechniken bewerten. Ohne an dieser Stelle in Detail zu gehen, kann man allgemein sagen, dass die szenariobasierten Lesetechniken, das usage-basierte Lesen und das metrikbasierte Lesen effektiver sind als der alleinige Einsatz von Checklisten. Man führt das zurück, dass Checklisten nur eine Orientierung geben, wonach gesucht werden soll, aber nicht explizit vorgeben, wie das geschehen soll. Zu beachten ist auch, dass bestimmte Lesetechniken auch nur in bestimmten Phasen des Projekts eingesetzt werden können bzw. sie sich auch nur dort als besonders effektiv erweisen. Alle empirischen Studien für eine bestimmte Lesetechnik versuchen diese mit dem checklistenbasierten Lesen zu vergleichen. Was aber immer noch außer Acht gelassen wird, ist auch andere Lesetechniken zum Vergleich zu verwenden. So lässt sich auch heute noch schwer sagen, welche der Lesetechniken für eine bestimmte Projektphase die effektivste ist. 3.4 Variationen von Review-Techniken Fagan Fagan [12] entwickelte 1976 die als erste bekannt gewordene Review-Technik, nämlich die Software-Inspektion. Obwohl seit jeher Jahrzehnte vergangen sind, ist diese Technik auch heute noch relevant. Diese Inspektionstechnik wird oft bei Variationen der Review-Techniken zum Vergleich als Referenz benutzt. Kennzeichnend für die Inspektion ist der hohe Formalisierungsgrad und ein strukturierter und klar definierter Inspektionsprozess. Die anfallenden Rollen sind bereits im Kapitel 3.1 beschrieben worden. Abbildung 2 zeigt diesen Inspektionsprozess. 9

15 Abbildung 2: Inspektionsprozess nach Fagan [55] Bei der Planungsphase wählt der Moderator das Team aus, sammelt alle benötigten Materialien ein und teilt diese an den Gutachtern aus und vereinbart alle benötigten Termine, die im Prozess stattfinden. In der optionalen Übersichtsphase kann der Moderator alle benötigten Informationen zum Inspektionsprozess und dem zu erstellenden Produkt zur Verfügung stellen. Vor allem wenn neue Personen erstmalig daran beteiligt sind, empfiehlt es sich, diese Phase abzuhalten. Die Vorbereitungsphase ist alleine den Gutachtern gewidmet. Sie sollen sich mit dem Prüfling auseinandersetzen und potentielle Defekte finden. Der essentielle Bestandteil ist das Inspektionstreffen. Dort wird ein Treffen aller Teilnehmer vereinbart. Alle Befunde der einzelnen Gutachter werden zusammengetragen und diskutiert. Darüber hinaus wird auch beim Treffen der Prüfling zusammen geprüft. Das heißt, die Befunde werden nicht nur zusammengetragen, sondern es wird auch nach Befunden gesucht. Beim Rework veranlasst der Moderator dem Autor, den Prüfling den Befunden entsprechend zu ändern. Der Moderator prüft beim Follow-Up, ob die Änderungen auch tatsächlich und auch in der Richtigkeit vorgenommen worden sind. Abschließend beendet er den Inspektionsprozess und sammelt Daten über den Prozess und das Produkt, um davon ausgehend nachhaltig den Prozess oder die Produktqualität zu verbessern. Von den Features aus Kapitel 3.2 ausgehend kann man festhalten, dass das Team hier als groß angesehen werden kann. Es wird nur eine einzige Sitzung durchlaufen und die Kollektionstechnik ist das Inspektionstreffen. Lesetechniken kommen nicht zum Einsatz und somit geschieht das Suchen nach Befunden Ad Hoc. Auch vom Post-Collection-Feedback wird kein Gebrauch gemacht Bisant Bisant und Lyle [13] verringern in ihrem Ansatz, dem Two-Person-Inspection, das Team auf zwei Personen, nämlich dem Autor und einem Gutachter, um dadurch die Kosten zu senken. 10

16 Die Teamgröße ist demnach klein und es findet eine Sitzung statt. Es kommt keine Lesetechnik zum Einsatz und somit prüft der Gutachter Ad Hoc. Auch vom Post-Collection- Feedback wird kein Gebrauch gemacht. Die Kollektionstechnik ist das Treffen vom Autor und einem Gutachter Gilb Gilbs Technik [14] ist der Technik von Fagan ziemlich ähnlich. Im Gegensatz zur Inspektionstechnik nach Fagan wird nach dem Inspektionstreffen noch eine Phase ergänzt. Nach dem Treffen schließt noch ein Brainstorming-Meeting an. Dort sollen Erfahrungen ausgetauscht werden, die den bisherigen Verlauf des Prozesses beinhalten, um aus denen zukünftig zu lernen. Es sollen Diskussionen stattfinden, die die Gründe für die aufgetauchten Defekte begründen sollen, um sie zukünftig vermeiden zu können und nachhaltig eine Prozessverbesserung zu gewährleisten. Die Features von Gilbs Technik sind denen von Fagan ähnlich. Anders als bei Fagan wird Gebrauch von Post-Collection-Feedback gemacht und zur individuellen Vorbereitung der Gutachter werden Checklisten eingesetzt Meetingless Inspection Nach einer anhaltenden Diskussion darüber, ob man unbedingt ein Treffen braucht, wo alle beteiligten Personen an einem Treffen mitwirken müssen, kamen sämtliche empirische Studien zum Ergebnis, dass dieses nicht notwendiger Weise der Fall sein muss. Dieser Sachverhalt wird in Kapitel 3.5 noch einmal vertiefter aufgegriffen. Daraus entwickelte Votta [15] einen Ansatz, dass ein gemeinsames Treffen eliminiert. Stattdessen trifft sich der Autor und optional der Moderator einzeln mit den Gutachtern, um so die Befunde zusammenzusammeln. Bei dieser Technik gibt es mehrere Teams, die aber immer nur aus einem Gutachter bestehen. Somit ergeben sich multiple Sitzungen. Jeder Gutachter durchläuft genau eine Sitzung und alle Sitzungen laufen parallel ab. Votta lässt dabei unspezifiziert, welche Lesetechnik dabei zum Einsatz kommen soll Active Design Review Active Design Reviews wurden von Parnas und Weiss [16] entwickelt. Sie kommen für das Begutachten von Design-Spezifikationen vor. Dieser Ansatz kritisiert die mangelnde Interaktion zwischen Autoren und Gutachtern. Daher müssen Autoren durch gezielte Fragen, einer Art Szenarios, die Gutachter durch ihre Befundssuche führen. Diese Fragen müssen von den Gutachtern beantwortet werden und dieses kann nur geschehen, wenn sie sich auch intensiv mit dem Prüfling befassen. Damit wird der Gutachter gezwungen nicht nur den Prüfling passiv zu lesen, sondern auch aktiver seine Befundssuche zu gestalten. Der Autor könnte dem Gutachter den Auftrag erteilen, ein Stück Code zu implementieren, nachdem das Design begutachtet worden ist. Das wäre ein mögliches Szenario. Hier wird auch in mehreren kleinen Teams aufgeteilt, das auf einen bestimmten Aspekt fokussiert. Dieses geschieht dann insgesamt parallel. Jede einzelne parallele Sitzung hat ein eigenes Treffen. 11

17 3.4.6 Britcher Ausgehend vom Active Design Review geht Britcher [17] noch einen Schritt weiter. Er benennt vier Szenarios, die enthalten sein müssen und die schließlich dann auch die vier Phasen bilden. 1. Topologie: Löst die Dekomposition in Teilprobleme das gesamte Problem? 2. Algebra: Bedeutet jede sukzessive Verfeinerung ein funktionales Äquivalent? 3. Invarianz: Haben die Variablen vor, während und nach der Ausführung den richtigen Wert? 4. Robustheit: In wie weit werden Exceptions behandelt? Phased Inspection Knight und Myers [18] beschreiben eine Methode, welche das Review in einzelne Phasen aufteilt. Dabei werden die Phasen sequenziell abgearbeitet. Das bedeutet vor allem, dass erst in die nächste Phase eingetreten werden kann, wenn die vorige schon abgearbeitet worden ist. Eine Phase kann einen oder mehrere Gutachter beinhalten. Anders als bei den bisherigen Ansätzen kümmert sich jede Phase genau um eine Fehlerklasse. Ein Inspektionstreffen findet nur statt, falls die Teams mehrere Gutachter beinhalten. Falls es der Fall ist, so dient das Treffen nur dazu die Befunde zusammenzutragen. Zur individuellen Vorbereitung der Gutachter werden Checklisten benutzt N-fold Ausgehend von der Hypothese, dass ein einziges Team nicht alle Defekte finden kann und mehrere Teams sich nicht behindern und nicht viele Duplikate finden würden, entwickelten Schneider et al. [19] diesen Ansatz. Mehrere Teams sollen am selben Prüfling parallel arbeiten. Der Moderator sammelt schließlich alle Befunde zusammen und eliminiert alle Duplikate. Jedes Team hält ein Treffen für sich selber ab. Lesetechniken haben auch hier keine Bedeutung. Die Befundssuche ist Ad Hoc Code Reading McConnell [20] führt in eine Technik ein, die für das Lesen von Codes bestimmt ist. Dabei verteilt der Autor den Prüfling an zwei oder drei Gutachtern, die ihn lesen sollen und dann nach Defekten suchen. Wichtig ist, dass das Lesen von nur einer begrenzten Anzahl an Zeilen gestattet wird. Optional kann der Autor sich dann mit jedem Gutachter einzeln treffen, um über die Befunde zu diskutieren. Der wichtigste Teil ist aber die Suche der Befunde durch die Gutachter. Es werden jedoch keine besonderen Lesetechniken benutzt, also ist es auch hier als Ad Hoc gekennzeichnet. Eine Variation hiervon ist das Code Reading mit schrittweiser Abstraktion. Basili und Mills [21] beschreiben es wie folgt: Es wird vom Devide-And-Conquer-Paradigma Gebrauch gemacht. Man teilt dabei den gesamten Code in einzelne Bestandteile, die einzelne Funktionen beinhalten. Alle einzelnen Funktionen werden dann zusammengetragen und mit der Spezifikation des Programms abgeglichen. 12

18 FTarm (Formal Technical Asynchronous Review Method) Johnson [22] entwickelte diese Methode, um gegenüber Fagans Inspektion effektiver und effizienter zu sein. Diese Methode ist immer mit dem Tool-Einsatz verbunden, da es ein Versuch ist Aktivitäten parallel zu gestalten. Auch wenn viele Tools (diese werden erst im 5. Kapitel behandelt) auch eigene Prozesse definieren, soll in diesem Kapitel in diesem Zusammenhang nur diese Methode beschrieben werden, da sie von den anderen stark abweicht. Abbildung 3 veranschaulicht die Phasen, die bei dieser Methode auftreten. Abbildung 3: Phasen der Methode FTarm [22] In der Setup-Phase wird das Review-Team zusammengestellt und die Dokumente bereitgestellt. Das Dokument wird in einzelne Knoten, die beispielsweise einzelne Funktionen oder Prozeduren enthalten können, unterteilt und mit Hyperlinks versehen. Die Orientation-Phase ist der von Fagan entsprechend. Anders ist jedoch, dass das auch über s gewährleistet werden kann. Beim Private-review suchen die Gutachter nach Befunden und bearbeiten diese systemspezifisch durch Kommentare von Knoten zu Knoten. In der nachfolgenden Phase, dem Public-Review, sind die bisher verborgenen Kommentare für alle sichtbar. Schließlich kann für jeden einzelnen Knoten abgestimmt werden. Wenn alle Knoten abgearbeitet worden sind, geht man in die Consolidation-Phase. Dort analysiert der Moderator die Ergebnisse aus dem Private- und Public-Review und erstellt einen Report. Sind die Ergebnisse nicht zufrieden stellend, so kann als letzte Phase ein Gruppentreffen stattfinden. Initiiert wird dieses Treffen, wenn die Gutachter nicht einer Meinung sind. Hier können dann die Gutachter einen Kompromiss aushandeln oder der Moderator kann hier intervenieren. 13

19 Structured Walkthroughs Nach Frühauf et al. [4] stellen Inspektionen einen großen Aufwand für kleine Organisationen dar. Um dennoch nicht auf Reviews verzichten zu müssen, empfiehlt es sich einen Walkthrough als Review-Technik einzusetzen. Sie sind weniger formalisiert und somit weniger aufwendig. Dafür sind sie aber auch weniger effektiv. Das Vorgehen eines Walkthroughs ist nach ANSI IEEE Std wie folgt definiert: Humphrey Ist ein Review-Prozess, bei dem ein Designer oder Programmierer ein oder mehrere Mitglieder des Entwicklungsteams durch ein Design- oder Codesegment, das er oder sie erstellt hat, führt, während die anderen Mitglieder Fragen stellen und Kommentare abgeben über die Technik, den Stil, mögliche Fehler und andere Probleme. Sapsomboon [1] beschreibt Humphreys (1989) Erweiterung von Fagans Inspektion um eine Phase, der Analyse-Phase, zwischen der individuellen Vorbereitung der Gutachter und dem Inspektionstreffen. Dabei werden alle Einzelbefunde dem Moderator übergeben, der diese dann analysiert und die Ergebnisse davon für das Treffen zur Verfügung stellt Formal Technical Review (FTR) Zurückzuführen ist dieses Verfahren auf Weinberg und Freedman [25]. Dabei handelt es sich um eine Variation von Fagans Inspektion. Der Unterschied ist, dass dieses Verfahren weniger formalisiert ist. Die Teamgröße ist hier mittelgroß. Die Phasen sind die der Inspektion nach Fagan ähnlich. Planung und Vorbereitung sind Fagans Ansatz entsprechend. Das Gruppentreffen wird hier aber auf maximal zwei Stunden beschränkt. Nach dem Gruppentreffen kann optional eine Dritte Stunde eingefügt werden, in der dann Lösungsvorschläge gemacht werden. Darauf erfolgt eine Nacharbeit des Autors genau wie beim Ansatz von Fagan. Diese Phase in der FTR beinhaltet auch noch das Follow-Up in der Inspektion. Anders als bei Fagan hängen Weinberg und Freedman noch eine Analyse-Phase an. Diese hat genau wie Gilbs Ansatz die Funktion, Erfahrungen zu sammeln, aus ihnen nachhaltig zu lernen und dadurch zukünftig den Prozess zu verbessern Weitere Review-Verfahren Frühauf et al. [4] benennen noch weitere Review-Verfahren. In diesem Abschnitt sollen diese nur kurz erläutert werden. Der Schreibtischtest ist ein Verfahren, bei welchem der Entwickler selber seinen erstellten Prüfling prüft, nachdem er einen gewissen Stand beim Erstellen des Prüflings erreicht hat. Wichtig ist, dass der Entwickler einen gewissen Abstand zum Prüfling bekommt und mehr über das reflektieren soll, was er erstellt hat. Bei der Stellungnahme werden weitere Personen berücksichtigt. Der Autor verschickt Kopien an mehreren Personen des Entwicklerteams, um sich deren Meinung einzuholen. Die Entwickler versehen den Prüfling mit Kommentaren und schicken es dem Autor zurück. Dieser korrigiert dann die Stellen im Prüfling, die mit negativen Kommentaren versehen wurden. 14

20 Das Round-Robin-Verfahren versucht nicht nach Befunden zu suchen, sondern Argumente zu finden, den Prüfling zu akzeptieren. Bei einem Treffen versucht jeder Gutachter eine Art Plädoyer zu halten. Kann er nicht überzeugen, so liegen wahrscheinlich Befunde vor. Beim Peer-Review werden nach Frühauf [4] et al. die Gutachter in einem Raum gesperrt und prüfen mehrere Prüflinge auf einmal. Das Team teilt die Aufgaben selber ein und bestimmt selber die Vorgehensweise. Dem Moderator kommen organisatorische Aufgaben zu. Das Ergebnis sind dabei Gutachten. Das Mini-Review enthält nur einen Gutachter und den Autor. Der Autor überlegt sich von Anfang an, was er finden will und erstellt eine Checkliste. Darauf arbeitet er die Checkliste ab und notiert Befunde. Bei einem Treffen mit dem Autor wird jeder Befund diskutiert Inspektion nach IEEE Nach den zahlreichen Variationen wurde der Inspektionsprozess durch IEEE als Standard festgelegt. Man sieht den typischen Ablauf nach Fagan. Jedoch wird die 3. Stunde als Post- Collection-Feedback hinzugefügt. Im Folgenden soll dieser standardisierte Prozess nicht erläutert werden, da schon alles in den vorigen Abschnitten erläutert worden ist und dieser Standard-Prozess die Ideen der bereits beschriebenen Techniken enthält. Abbildung 4 soll diesen Prozess selbsterklärend darstellen. Abbildung 4: Inspektionsprozess nach IEEE [1] 15

21 Vergleich von Review-Techniken Den größten Unterschied von Review-Verfahren stellt der Formalisierungsgrad dar. Auch anhand der typischen Features für Review-Verfahren sind Unterschiede erkennbar. Der grundlegende Verlauf ist jedoch bei allen Variationen ähnlich. Lediglich werden bestimmten Phasen mehr oder weniger Bedeutung nachgesagt. Der deutlichste Unterschied ist die Betonung der individuellen Vorbereitung der Gutachter zum einen, oder das Treffen des Teams zum anderen. Auch wenn alle Autoren ihren Ansatz als den besten preisen, so ist Fagans Inspektion immer noch der relevanteste Ansatz, wenn es darum geht neue Prozesse in Bezug auf Reviews zu gestalten. Tabelle 1 soll alle beschriebenen Review-Techniken anhand der Features übersichtlich vergleichen. Teamgröße Anzahl von Sitzungen Koordination von multiplen Sitzungen Defektdetektionsmethode Kollektionstechnik Post- Collection- Feedback Fagan 6-8 (groß) 1 - Ad Hoc Meeting - Bisant Ad Hoc Meeting - Gilb groß 1 - Checkliste Meeting ja Meetingless Inspection ADR Britcher mehrere kleine Teams mehrere kleine Teams mehrere kleine Teams >1 parallel unspezifiziert Meeting - >1 parallel Szenarios Meeting - 4 parallel Szenarios Meeting - Phased kleine >1 sequenziell Checklisten Meeting - Inspection Teams N-Fold mehrere >1 parallel Ad Hoc Meeting - Teams Code Ad Hoc Meeting - Reading FTarm groß 1 - Ad Hoc Meeting - Structured klein 1 - Ad Hoc Meeting - Walkthrough Humphrey groß 1 - Ad Hoc Meeting - FTR mittel 1 - Ad Hoc Meeting Ausblick: Review-Techniken Tabelle 1: Vergleich von Review-Techniken Nach einer empirischen Studie von Johnson et al. [23], der die Frage untersucht, ob ein Treffen notwendig ist, kommt er zum Schluss, dass es keins geben muss. Er zeigt, dass Reviews mit einem oder ohne einem Treffen sich nicht signifikant in der Effektivität unterscheiden. Dennoch nennt er auf beiden Seiten die Vor- und Nachteile. Der Vorteil eines Reviews ohne Treffen ist, dass das Review dadurch geringere Kosten verursacht. Der Nachteil aber ist, dass mehrere falsche Positive entstehen. Das heißt die Gutachter deklarieren einen Befund, der in Wirklichkeit keiner ist. Demgegenüber haben Reviews mit einem Treffen keine falschen Positive. Die Vorteile von Reviews mit einem Treffen sind, dass das Gruppenbewusstsein gestärkt wird und die Gruppenmitglieder voneinander Lernen. Zurückzuführen sind die Nachteile auf die mangelnde Kommunikation zwischen den einzelnen Gruppenmitgliedern. 16

22 Daher gibt er einen Ausblick, was man zukünftig erreichen will. Zum einen soll bewusst der Einsatz von Tools erfolgen. Das Ziel soll sein, das Review-Treffen zu eliminieren, da sie die größten Kosten verursachen. Zum anderen sollen die Vorteile, die Treffen bieten, erhalten bleiben. Obwohl man das Treffen eliminieren will, muss man geeignete Kommunikationsmechanismen betrachten, um den Kommunikationsgrad auf hohem Niveau zu halten. Ein hoher Kommunikationsgrad verspricht die Vorteile eines Review-Treffens zu erhalten und gleichzeitig die Kosten gegenüber einem Review-Treffen einzusparen. Frühauf et al. [4] schließen, dass es keine optimale Review-Technik gibt. Es ist immer von der Organisationsstruktur und dem spezifischen Projekt abhängig, welche Technik sich dafür besonders eignet. Projekten mit einer hohen Kritikalität ist ein hoch formalisiertes Review- Verfahren vorzuziehen, während unkritische Projekte auch eine kaum formalisierte Review- Technik benutzen können. Abhängig ist aber auch, welche Qualität man erreichen will. 3.6 Stand in der Praxis Der ViSEK-Report [24] aus dem Jahre 2002 deckt den aktuellen Stand von Reviews in der Praxis auf. Man kommt zum Schluss, dass Reviews zwar akzeptiert sind und auch oft eingesetzt werden, aber es oft unsystematisch geschieht. Anwender besitzen kaum speziell geschulte Kenntnisse. Die folgende Abbildung 5 soll die Verbreitung bestimmter Review- Techniken aufzeigen. 16,50% 13,20% 20,70% 49,60% Peer Review Inspektion Walkthrough andere oder keine Abbildung 5: Verbreitung von Review-Techniken Etwa ein Drittel benutzen keine Lesetechniken. Von denen, die welche benutzen, verwenden Checklisten. Szenariobasierte Lesetechniken oder andere Lesetechniken werden so gut wie gar nicht benutzt. Auch das Sammeln von Daten während eines Review-Prozesses ist nicht verbreitet. Etwa die Hälfte sammelt überhaupt keine Daten, 20% nur Aufwandsdaten und 20% nur Fehlerdaten. Gründe, die gegen Reviews benannt werden, sind Kosten (55%) und Zeitdruck (75%). Oftmals wird auch noch der fehlende Tool-Support als Grund genannt. 17

23 4 Exkurs: CSCW Das Computer Supported Cooperative Work (kurz CSCW) ist eine eigenständige Disziplin. Sie befasst sich mit theoretischen Grundlagen oder auch Methodologien für Gruppenarbeit verbunden mit dem Rechnereinsatz. Wilson [26] definiert CSCW wie folgt: CSCW is a generic term which combines the understanding of the way people work in groups with the enabling technologies of computer networking, and associated hardware, software, services and techniques. Dem entgegen meint der Begriff Groupware nach Schlichter et al. [28] die Systeme, die Gruppenarbeit unterstützen. Noch genauer meint es die Systeme, die die theoretischen Grundlagen realisieren, nachdem diese spezifiziert worden sind. Als Synonym wird oft auch der Begriff CSCW-System benutzt. Johansen [29] definiert diesen Begriff mit: Groupware is a generic term for specialised computer aids that are designed for the use of collaborative work groups. Typically, these groups are small project-oriented teams that have important tasks and tight deadlines. Groupware can involve software, hardware, services and/or group process support. Nach Borghoff und Schlichter [27] wird der Begriff des CSCW ins Deutsche als Rechnergestützte Gruppenarbeit übersetzt. Der Begriff des Gruppengewahrseins nach Schlichter et al. [28] meint, dass die Mitglieder einer Gruppe nicht voneinander isoliert sind. Jeder weiß über die Existenz des anderen Bescheid. Jede Änderung wird gegenseitig mitgeteilt. Dourish und Bly [30] definieren diesen Begriff als: group awareness as an understanding of the activities of others which provides a context for your own activity... In der CSCW-Forschung werden Kooperation und Kollaboration oft als Synonyme benutzt, obwohl sie unterschiedliches meinen. Kooperation meint die Zusammenarbeit mit gleichen Zielen, während Kollaboration die Zusammenarbeit mit unterschiedlichen Zielen meint. Kollaboration tritt vor allem da auf, wo verschiedene Rollen definiert sind, die unterschiedliche Aufgaben zu bewältigen haben. Als Beispiel kann hier ein Review dienen. Borghoff und Schlichter [27] unterscheiden synchrone und asynchrone Tätigkeiten. Synchrone Tätigkeiten sind Tätigkeiten, die zur selben Zeit ausgeführt werden, während asynchrone Tätigkeiten zeitlich versetzt erfolgen. Eine weitere Unterscheidung ist zwischen nominal und real. Häufig bezieht man diese Begriffe auf Gruppen oder Phasen, in denen die Gruppe eine Tätigkeit ausüben soll. Borghoff und Schlichter [27] beschreiben real als durch direkte Interaktion gekennzeichnet. Nominal dagegen besagt eine Kennzeichnung durch indirekte Interaktion mittels Systemen. 18

24 4.1 Klassifikationen In diesem Kapitel wird gezeigt, nach welchen Kriterien man CSCW-Systeme charakterisieren und sie dadurch klassifizieren kann. Im Wesentlichen sind es Klassifikationen nach der Raum/Zeit-Matrix und dem 3K-Modell. Eine dritte Klassifikation ist die nach Anwendungsklassen. Darauf soll aber nicht gesondert eingegangen werden, da sie eine Präzisierung des 3K-Modells ist. Einige Aspekte sollen aber in Kapitel 3.3 besonders im Zusammenhang mit Reviews aufgegriffen werden Raum/Zeit-Matrix Nach Schlichter et al. [28] unterscheidet man CSCW-Systeme in Raum und Zeit. Die Unterscheidung in Raum meint die geografische Lage der Gruppenmitglieder. Gruppenmitglieder können zum einen geografisch am selben Ort sein oder verteilt sein, wobei die geografische Verteilung nicht unbedingt meint, dass alle Gruppenmitglieder weit voneinander liegen, sondern auch nah liegen können, aber verschiedene Rechner benutzen. Die Unterscheidung in Zeit meint, dass Tätigkeiten der einzelnen Gruppenmitglieder entweder zur selben Zeit oder zu unterschiedlichen Zeiten erfolgen. Abbildung 6 zeigt dieses Modell grafisch da K-Modell Abbildung 6: Raum/Zeit-Matrix [28] Teufel et al. [31] charakterisieren CSCW-Systeme nach dem Grad der Zusammenarbeit innerhalb einer Gruppe. Dabei nennen sie drei Größen, die sich aus der Zusammenarbeit ergeben: Kommunikation, Koordination, Kooperation. Unter Kommunikation versteht man die Verständigung und den Informationsaustausch in einer Gruppe. Die Koordination meint die Abstimmung der Aktivitäten der Gruppenmitglieder und der Ressourcen. Kooperation meint hier die Verfolgung gemeinsamer Ziele. Abbildung 7 zeigt dieses Modell. 19

25 Je nach ihrem Zusammenwirken der drei Größen ergeben sich verschiedene Anwendungsklassen. Andere Autoren gehen genauer auf diese Anwendungsklassen ein und nehmen diese als Klassifizierung. Wie bereits erwähnt sollen diese aber nicht gesondert behandelt werden. Diese Klassifikation ist nicht als absolut anzusehen. Viele der Anwendungsklassen überschneiden sich. Eine totale Abgrenzung ist nicht möglich. Abbildung 7: 3K-Modell [28] 4.2 Einordnung von Reviews in die Klassifikationen In der Raum/Zeit-Matrix kann man Reviews drei Fällen zuordnen. Diese Fälle sind synchron und geografisch nah, synchron und geografisch verteilt und asynchron und geografisch verteilt. Auch wenn Gruppenmitglieder geografisch nah sind, so kann es der Fall sein, dass sie nicht gleichzeitig ihre Tätigkeiten ausführen. Somit ist der Fall geografisch nah und asynchron im Fall geografisch verteilt und asynchron mitberücksichtigt. In der Raum/Zeit-Matrix ist in Bezug auf Review-Tools eine historische Entwicklung erkennbar. Diese wird aber erst an geeigneter Stelle in Kapitel 5.1 erläutert. Reviews fordern einen hohen Grad an Koordination. Der Grad der Kooperation ist eher gering und der Grad der asynchronen Kommunikation soll möglichst hoch sein, wie in Kapitel 3.5 bereits erläutert. Damit kann man Reviews im 3K-Modell eingrenzen. So sind nicht alle Anwendungsklassen mehr relevant. Interessant sind die drei Anwendungsklassen Nachrichtensysteme, gemeinsame Informationsräume und Workflow-Management. An dieser Stelle sollen diese relevanten Anwendungsklassen nach Schlichter et al. [28] genauer beschrieben werden. Nachrichtensysteme: Kennzeichnend ist hierfür das asynchrone Austauschen von Textnachrichten. Die bekannteste Anwendung ist das -System. 20

26 Gemeinsame Informationsräume: Charakteristisch ist das Bearbeiten und die konsistente Verwaltung gemeinsamer Informationen. Dabei stehen Gruppendokumente im Vordergrund, die in Datenbanken gespeichert werden. Es werden geeignete Zugriffsmechanismen zur Verfügung gestellt. Man unterscheidet vier Kooperationsmodi je nach Art des Zugriffsmechanismus. Diese sind: - getrennte Verantwortlichkeit: jedes Gruppenmitglied bearbeitet seinen für ihn verantwortlichen Teil unabhängig von den anderen - wechselseitiger ausschließlicher Zugriff: immer nur ein Mitglied hat zur selben Zeit Zugriff auf das Dokument - alternative Version: jedes Mitglied bearbeitet eine Version und alle Versionen werden dann zu einer konsistenten Version zusammengefügt -synchroner Zugriff: Mitglieder arbeiten zur selben Zeit am selben Dokument Workflow-Management: Bedeutend ist hier die Koordinierung und Steuerung asynchroner Tätigkeiten in Gruppen. Man unterscheidet drei Typen von Koordinatonssystemen: - formularorientiert: orientiert sich am Datenfluss einer Organisation mittels Dokumenten, wobei erst bei Erhalt des Dokuments eine Tätigkeit ausgeübt werden kann, es abgesegnet wird, weitergeleitet wird und eine neue Tätigkeit angestoßen werden kann - konversationsorientiert: ausgehend von der Interaktion zwischen den Mitgliedern mittels sprachlichen Äußerungen resultiert daraus eine Aktion - kommunikationsorientiert: das Verfassen eines Dokuments hängt von den Rollen in der Organisation ab und drücken auch die Kommunikations- und Organisationsstruktur aus Nachdem die relevanten Anwendungsklassen benannt und beschrieben worden sind, soll jetzt deren Relevanz begründet werden. Review-Tools koordinieren schwerpunktmäßig. Sie stellen aber auch einen Raum bereit, wo gemeinsam Informationen verarbeitet werden, und benutzen auch asynchrone Kommunikationsmittel. Unter dem Workflow-Management ist das formularorientierte System relevant. Bei einem Review werden Aktivitäten bei Erhalt von Dokumenten angestoßen und erst durch die Absegnung der Einzelbefunde durch die Gutachter kann ein Treffen stattfinden. Von Bedeutung ist auch das kommunikationsorientierte System. Bei einem Review werden auch Rollen definiert und daraus ergibt sich das Verfassen der Dokumente. Im gemeinsamen Informationsraum ist die getrennte Verantwortlichkeit besonders hervorzuheben. Jeder Gutachter im Review erstellt unabhängig von den andern seinen Einzelprüfbericht. Diese Begründungen werden jedoch erst im 5. und 6. Abschnitt der Arbeit deutlicher. An geeigneter Stelle sollen diese Aspekte noch mal aufgegriffen werden. 4.3 Herausforderungen Grudin [32] wird oft in vielen Literaturangaben im Zusammenhang mit sozialen Herausforderungen bei der Erstellung von CSCW-Systemen genannt. Diese sollen kurz erläutert werden. a) Disparität zwischen Kosten und Nutzen beim Einsatz des CSCW-Systems Die Disparität bezieht sich zwischen denjenigen, die die Arbeit machen, und denjenigen, die die Vorteile aus dem Gebrauch ziehen. Für die meisten Benutzer ergibt sich eine Mehrarbeit und profitieren gleichzeitig nicht davon. Somit ist ein Profit nur für wenige erkennbar, so dass das Benutzen scheitert. 21

27 b) Notwendigkeit einer kritischen Masse an Benutzern Damit das System für die Gruppe überhaupt sinnvoll einsetzbar ist, muss eine hohe Anzahl an Benutzern dieses System verwenden. Wenn bereits ein Mitglied sich weigert, das System zu benutzen, so kann es sein, dass die gesamte Gruppe ihrer Arbeit nicht mehr nachgehen kann. c) Verletzung sozialer Tabus und Bedrohung organisatorischer Strukturen Wenn gegen soziale Tabus gebrochen wird, so führt es zu einer Demotivierung der Benutzer, was zur Abneigung des Benutzers führt, das System zu benutzen, und scheitert schließlich. d) Behandlung von Ausnahmen Entwickler von CSCW-Systemen berücksichtigen häufig nur feste Vorgehensweisen, die im Gruppenverhalten aber nur selten sind. Charakteristisch für Gruppen ist aber die Improvisation und Behandlung von Ausnahmen. e) Komplexität der Benutzerschnittstelle durch die Integration von CSCW-Funktionalität zusätzlich zur anwendungsorientierten Funktionalität Auch wenn man viel CSCW-Funktionalität mit einbauen möchte, so werden diese jedoch nicht häufig genutzt. Dadurch, dass es die aber gibt, erhöht sich die Komplexität für den Benutzer, der den Gebrauch wegen der Komplexität ablehnen kann. f) Schwierigkeit, CSCW-Systeme zu evaluieren und zu analysieren CSCW-Systeme können zwar langwierig evaluiert und analysiert werden, aber eine Herausforderung ist es, aus diesen gewonnen Ergebnissen allgemeine Schlüsse zu ziehen. g) Fehlende Erfahrung beim Entwurf von Mehrbenutzeranwendungen Entwickler erstellen oft Anwendungen, die schon in der Konzeptionisierung falsch sind. Sie berücksichtigen unter den Benutzern nur, wie Manager ihre Entscheidungen fällen. Noch schwieriger wird es dann, wenn es darum geht, wie eine Gruppe zu einer Entscheidung findet. Dahin sichtlich fehlt es den Entwicklern an Erfahrung. Oft überfüllen sie das System mit Funktionalitäten aus der Sicht der Manager, was für andere Benutzer als zu aufwendig angesehen werden kann und damit zur Ablehnung des Systems führt. Eine Lösung wäre, andere Benutzer möglichst früh in den Entwicklungsprozess einzubinden. h) Schwierigkeit, CSCW-Systeme in Organisationen einzuführen Kritisiert wird, dass Entwickler sich von ihren Kunden entfernen. Wichtig ist, dass möglichst viele Benutzer dieses System und besonders CSCW-Systeme akzeptieren müssen. Entwickler sollen sich ihren Kunden annähern und ihnen zur Verfügung stehen, um ihnen das System schmackhaft zu machen. 22

28 5 Tool-Support für Reviews Bevor auf die Tools eingegangen werden soll, soll hier die historische Entwicklung im groben aufgezeigt werden. Die erste Generation von Tools wurde mit der Idee kreiert, die das reale Meeting beibehalten, aber die Gutachter geographisch am selben Ort in ihrer Arbeit unterstützen. Der Übergang zur zweiten Generation behielt die Synchronität, aber es wurde die Unterstützung von geografisch verteilten Gruppen gewährleistet. Die dritte Generation konzentriert sich auf die asynchrone Kommunikation zwischen Gruppenmitgliedern, die geographisch verteilt sind. Mit der vierten Generation wurden technische Aspekte von Bedeutung. Die Asynchronität und die Verteilung von Gruppenmitgliedern blieben erhalten, nur der bewusste Einsatz von Web-Technologien wurde hier betont. Dieser Sachverhalt wird in Abbildung 8 mit Hilfe der Raum/Zeit-Matrix deutlich. Abbildung 8: Historische Entwicklung in der Raum/Zeit-Matrix [48] Folgende Tabelle 2 soll die Tools aufzählen mit der Berücksichtigung, wann sie entstanden sind und zur welchen Tool-Generation sie gehören. 1. Generation 2. Generation 3. Generation 4. Generation 1990 ICICLE, COMPAS 1991 InspeQ 1992 Scrunity 1993 CSI 1994 Quality Group 4000 CAIS, CSRS 1995 Notes Inspector 1996 TAMMi 1997 InspectA ASSIST AISA HyperCode 1998 WiT WiP/InWin GRIP/GSS IBIS Web-IPSE 2002 XATI, ReviewPro Tabelle 2: Review-Tools in den Tool-Generationen 23

29 5.1 Features von Review-Tools Mcdonald et al. [33] beschreiben die Merkmale, die ein Review-Tool besitzt. Wichtig ist dabei zu erwähnen, dass diese Merkmale nicht vor der Implementierung von Review-Tools festgelegt worden sind, sondern erst nach der Erstellung von einigen Review-Tools benannt worden sind, um die grundlegenden Unterschiede von verschiedenen Tools aufzeigen zu können und bilden dabei die Knackpunkte in der Forschung. Nach deren Ansicht sind ihre vier genannten Merkmale Document Handling, Individual Preparation, Meeting Support und Data Collection genau die Merkmale, worin sich die Tools am meisten unterscheiden, aber auch die wichtigsten Bereiche eines Review-Tools darstellen. Viele Entwickler von Review- Tools berücksichtigen diese Merkmale bei der Erstellung ihrer Tools. Man kann sagen, dass diese Merkmale einen breiten Konsens gefunden haben. Im Folgenden seien die Features erläutert. Document Handling: Dieses Feature beschreibt zwei Bereiche, die sich auf Dokumente beziehen. Zum einen soll aufgeschlüsselt werden, welche Arten von Dokumenten angezeigt werden. Unterschieden werden Textdokumente, Quellcode und Grafiken. Der andere Bereich ist die Beschreibung, wie mit den Dokumenten umgegangen wird. Dieser Bereich umfasst das Versionsmanagement, mögliche Änderungen am Dokument durch die Benutzer, das Navigieren durch die Dokumente, das Abspeichern der Dokumente und die Art wie die Dokumente den Benutzern zur Verfügung gestellt werden. Individual Preparation: Dieses Feature zeigt, wie das System den Gutachtern bei der Suche nach Defekten hilft. Im Wesentlichen sind damit Lesetechniken gemeint. Vor allem liefert es eine Beschreibung wie Lesetechniken realisiert worden sind. Des Weiteren zählt man auch noch dazu, welche sonstigen Tools mit eingebaut sind. Beispielsweise können es Tools sein, die einen Quellcode nach Programmierrichtlinien überprüfen. Zu diesem Feature zählt auch, wie die Gutachter ihre Befunde melden und welche Informationen diese Befunde enthalten. Meeting Support: Dieses Merkmal meint, wie ein Review-Meeting abgehalten wird. Man unterscheidet dabei ein synchrones oder asynchrones Meeting. Beim synchronen Meeting kann man noch nach nominal oder real unterscheiden. Dieses beinhaltet auch, welche Technologien dabei eingesetzt werden. Data Collection: Data Collection meint das Erstellen der Metriken während des ganzen Review-Prozesses. Dieser Bereich beschäftigt sich damit, welche Metriken zum Einsatz kommen und wie sie automatisiert worden sind. Gilb und Graham [34] gehen näher auf Metriken ein. Metriken sind dazu da, um den Review-Prozess zu bewerten und nachhaltig den Prozess zu verbessern. Dabei nennen sie 42 verschiedene Metriken. An dieser Stelle muss man aber aufpassen, da viele Metriken nicht aussagekräftig genug sind und nicht geklärt ist, wie sie sich und ob sie sich überhaupt automatisieren lassen. Als Beispiel soll die Metrik dienen, die misst, wie viele Befunde jeder einzelne Gutachter gemeldet hat. Mit Sicherheit ist es leicht automatisierbar, aber lässt oft nicht richtige Schlüsse zu. Ein niedriger Wert könnte bedeuten, dass der Gutachter nicht ausreichend gearbeitet hat, aber auch dass der Autor das Dokument mit großer Sorgfalt erstellt hat, so dass das Dokument wenig Befunde zulässt. 24

30 5.2 Tools der 1. Generation Das erste Review-Tool ICICLE [35] (Intelligent Code Inspection in a C Language Environment) erschien Dieses Tool ist auf Inspizieren von C-Code beschränkt. Die Autoren machen dabei das Meeting und die individuelle Vorbereitung der Gutachter als die Faktoren aus, die am zeitintensivsten sind und die meisten Kosten verursachen. Dennoch wird das Meeting auch weiterhin real abgehalten. Eine weitere Möglichkeit bietet dieses Tool, eine Audiokonferenz abzuhalten. Das Material wird jedem Gutachter gleichzeitig zur Verfügung gestellt. Dabei erhalten die Gutachter immer die selbe Version, worauf sie Befunde kommentieren können und gleichzeitig die Kommentare anderer lesen können. ICICLE sammelt automatisch Metriken und enthält Checklisten und Richtlinien für die Gutachter. COMPAS [50] ist ein Dokumentmanagementsystem. Im Prinzip stellt dieses Tool eine Datenbank dar, was die benötigten Materialien im System zur Verfügung stellt und Metriken verwaltet. Darüber hinaus gewährleistet dieses Tool Zeitplanung und unterstützt die Auswahl von Teilnehmern sowie ihre Benachrichtigung. InspeQ [18] (Inpecting Software in Phases to Ensure Quality) ist auf die Review-Technik Phased Inspection entwickelt worden, jedoch nicht nur auf diese beschränkt. Das Meeting entfällt bei diesem Tool komplett. Es werden nur einfache Textdokumente unterstützt. Alle im Prozess anfallenden Dokumente müssen in ein einheitliches Format transformiert werden, in diesem Fall in . Gutachter können ihre Kommentare frei verfassen, das heißt es existiert kein Standard, wie die Gutachter ihre Befunde melden sollen. Auch InspeQ enthält Checklisten und Prozess-Standards. Metriken werden wiederum automatisch gesammelt. Quality Group 4000 [51] beschreibt einen Tool-Set, was unter UNIX läuft. Auch in diesem System wird das Material zur Verfügung gestellt. Ein Report wird automatisch generiert. Die grundlegenden Charakteristika dieser Tool-Generation sind die Behandlung von Metriken und der Einsatz von Checklisten innerhalb eines Systems. Diese Tools unterstützen real durchgeführte Reviews. 5.3 Tools der 2. Generation Scrunity [36] war das erste Tool, was geografisch verteilte Gruppenmitglieder berücksichtigte. Die grundlegende Idee ist, dass die Mitglieder von ihrem Computer aus an einem Meeting teilnehmen sollen. Dieses Tool enthält synchrone und asynchrone Phasen. Zunächst ist der Moderator mit der Planung beschäftigt. Anschließend suchen die Gutachter nach Befunden. Die Autoren können dann eine Art Meeting verlangen, indem die Befunde über das System jedem Teilnehmer zugänglich gemacht wird. Das Tool beinhaltet auch Schnittstellen mit der Entwicklungsumgebung. Zum einen gewährleistet ein Versionsmanagementsystem, dass alle Gutachter immer die selbe Version zur Verfügung haben und zum anderen können die Defekte an einem Error-Tracking-System weitergegeben werden. CSI [37] (Collaborative Software Inspection) versucht den ganzen Review-Prozess als verteilt zu unterstützen. Dabei werden sowohl die benötigten Materialien als auch die gemeldeten Befunden an alle Teilnehmern verteilt. Das Tool enthält meist asynchrone Phasen, aber ein synchrones Meeting über eine Videokonferenzschaltung. 25

31 Groupware Support System (GSS) [53] enthält einen Set von Tools, die nominale Gruppen unterstützen. Zu ersten Mal tauchen sie 1996 auf und entwickelten sich von da an weiter. Anfangs unterstützten sie nur synchrone Kommunikation, aber während der Entwicklung wurden auch asynchrone Funktionalitäten eingebaut. Vorwiegend versuchen diese Tools Materialien im System den Teilnehmern zugänglich zu machen, die geografisch verteilt sind. Besonders ausgeprägt sind die Tools zur Planung. GRIP [54] basiert auf GSS. Hier werden nur Funktionalitäten zur synchronen Kommunikation übernommen. Unterstützt werden nur Textdokumente und verwenden für die Befundssuche Checklisten und Szenarios. Nicht alle Befunde müssen diskutiert werden. Vorher wird abgestimmt, welche Befunde unbedingt besprochen werden müssen. Das Tool erstellt automatisch mehrere Metriken. Zusammenfassend für diese Tool Generation kann man sagen, dass sie synchrone und asynchrone Phasen enthalten. Ein großer Wert wird auf das synchrone Meeting und auf die Verteilung der Materialien gelegt, so dass die Gruppenmitglieder nominal zusammenarbeiten. Ein weiterer Aspekt dieser Generation ist, dass auch Schnittstellen zur Entwicklungsumgebung vorhanden sind. 5.4 Tools der 3. Generation Die dritte Tool-Generation transformiert das synchrone Meeting in ein asynchrones. Damit sind in dieser Tool-Generation keine synchronen Anteile mehr vorhanden, sondern ist komplett nur in asynchrone Phasen übergetreten. CAIS [38] (Collaborative Inspection of Software) ist der Nachfolger des Tools CSI. Im Gegensatz zu CSI ist dieses Tool voll auf Asynchronität angesetzt. Das asynchrone Meeting ist nicht mehr eng auf höchstens zwei Stunden beschränkt, sondern man hat jetzt die Möglichkeit die Befunde über Tage hinweg zu diskutieren. Dieses Tool ermöglicht auch Lösungsvorschläge abzugeben. CSRS [22] (Collaborative Software Review System) geht näher auf die Konfiguration des Prozesses ein. Dabei wird der Prozess FTarm, wie in Kapitel beschrieben, abgebildet. Einen Schwerpunkt setzt Johnson hierbei auf die Integration des Prüflings in diesem System und auf die automatische Erfassung von Metriken. Diesbezüglich ist dieses Tool eine Neuerung. Notes Inspector [52] benutzt Lotus Notes als Umgebung. Dokumente werden in diesem System den Teilnehmern zur Verfügung gestellt. Es sind Annotationen direkt im Dokument möglich. Anders als bei vielen anderen Tools wird hier über jeden Befund abgestimmt, ob dieser diskutiert werden soll. Es stellt Funktionen zur asynchronen Kommunikation bereit und unterstützt auch Metriken. TAMMi [39] versucht nicht nur Textdokumente, sondern auch Grafiken für ein Review zu integrieren. Dabei wird ein Grafikdokument in Vertikale unterteilt, so dass ermöglicht wird, Befunde eindeutig im Dokument zu referenzieren. Das Tool unterstützt die individuelle Vorbereitung der Gutachter, aber lagert Dokument- und Prozessmanagement aus. ASSIST [40] (Asynchronous / Synchronous Software Inspection Support Tool) unterstützt nur Textdokumente. Einen Schwerpunkt setzt dieses Tool bei der Erfassung von Metriken. Neu bei der individuellen Vorbereitung der Gutachter ist, dass jeder Teilnehmer sehen kann, wo sich bei jedem der Cursor befindet, was dazu dienen soll, den Fortschritt zu erkennen. Einen anderen Schwerpunkt setzt dieses Tool auf die Bedürfnisse von Organisationen. 26

32 Durch die Modellsprache IPDL (Inspection Process Definition Language) soll es Organisationen ermöglicht werden, den Review-Prozess spezifisch zu konfigurieren. InspectA [41] benutzt s, um die Dokumente zu verteilen. Die grundlegende Hypothese dabei ist, dass die Veröffentlichung der Dokumente im Web die Teilnehmer demotivieren können. Einen besonderen Wert legt man auf Code-Dokumente. Aber auch Text-Dokumente werden unterstützt. Das Tool beginnt mit der individuellen Vorbereitung der Gutachter. Anschließend werden alle Befunde zusammengetragen. An dieser Stelle wird noch mal eine Prüfung vorgenommen. Abschließend können die Teilnehmer die Befunde asynchron diskutieren. Diese Tool-Generation enthält zu den vorigen einige Änderungen. Die Betonung dieser Tool- Generation liegt in der Abhaltung von Sitzungen von geografisch verteilten Gruppen, die nicht mehr gleichzeitig kommunizieren müssen. Eine weitere Neuerung ist das Konfigurieren des Prozesses, was es flexibler macht, an Organisationen anzupassen. Einige Tools dieser Generation beinhalten auch das Prüfen von Grafik-Dokumenten. 5.5 Tools der 4. Generation Auch die Entwicklung des Internets hatte Einfluss auf die Entwicklung von Review-Tools genommen. So wurden bewusst Web-Technologien zur Erstellung von Review-Tools eingesetzt, welche gewährleisteten, dass die Unabhängigkeit von Zeit und Ort noch stärker wurde. AISA [42] (Asynchronous Inspector of Software Artefacts) ist das erste Tool, das das Material in einer Web-Seite zeigte. Berücksichtigt werden meist nur Textdokumente, aber auch kleine Grafiken waren möglich. Kommentare der Gutachter werden auch auf diesen Web-Seiten hinzugefügt. Nach der individuellen Vorbereitung der Gutachter eliminiert der Autor Duplikate und alle Teilnehmer können asynchron Lösungsvorschläge abgeben. Als Metriken werden die Anzahl der Kommentare und die Dauer der Sitzungen angegeben. HyperCode [43] beinhaltet nur die Code-Inspektion. Das Material wird via Web veröffentlicht. Die Gutachter gehen den Code Zeile für Zeile durch, wo sie Kommentare abgeben können. Diese Kommentare werden dann im Web veröffentlicht und zusammengetragen. Das Review-Meeting entfällt. WiP [44] (Web Inspection Prototype) ist HyperCode sehr ähnlich. Der Unterschied, ist der, dass WiP als Java-Applet realisiert worden ist. Nach der Befundssuche durch die Gutachter werden alle Befunde zusammengetragen. Der so entstandene Report enthält Links von den einzelnen Befunden zum Prüfling. WiT [45] (Web Inspection Tool) und das leichtgewichtigere Tool InWin [46] (Inspection Window) [46] unterstützen Anmerkungen, die an den Seiten immer zu sehen sind. Der Prozess, der anfällt, gliedert sich in zwei Phasen, der privaten Inspektion und der öffentlichen Inspektion. Obwohl bei diesen Tools Dokumente im Web integriert sind, werden Links zwischen Befunden und Prüfling nicht berücksichtigt. 27

33 Web-IPSE [47] (Web-based Inspection Process Support Environment) erweitert das Konzept um ein Versionsmanagementsystem. In diesem werden Befunde verwaltet, um den Prüfling ggf. noch mal zu prüfen. Mit diesem Tool lassen sich auch mehrere Gruppen verwalten. XATI [49] (XML Annotation Tool for Inspection) benutzt XML, um im Browser mehrere Dokumenttypen darzustellen und an ihnen Modifikationen vornehmen zu können. Damit kann ein Befund der dazugehörigen Stelle im Dokument eindeutig zugeordnet werden. Dieses Tool unterstützt auch sämtliche Metriken, die durch Schnittstellen anderen Tools zur Auswertung verfügbar sind. Des Weiteren stellt XATI sämtliche Schnittstellen zu Tools in der Entwicklungsumgebung und Datenbanken bereit. Der Vollständigkeit halber sind noch das Tool IBIS (Internet Based Inspection System) und das kommerzielle Tool ReviewPro zu erwähnen. Diese sollen an dieser Stelle nicht nur kurz beschrieben werden, sondern wegen ihrer Aktualität und der gegenwärtigen Relevanz sollen ihnen jeweils ein Kapitel gewidmet werden, wo sie ausführlicher erläutert werden sollen. Diese Tool-Generation ist der der 3. von der Idee ähnlich, nur dass zur Implementierung der Tools dieser Generation Web-Technologien eingesetzt worden sind, die die Implementierung von Review-Tools im Allgemeinen leichter gestaltet hat. Dennoch wird von einer grundlegenden Technologie aus dem Web-Bereich kaum Gebrauch gemacht. Hyperlinks werden so gut wie gar nicht eingesetzt, obwohl sie wichtig wären, einen Befund eindeutig einer Stelle im Prüfling genauer zu lokalisieren. Mit der Weiterentwicklung von Web-Technologien werden sich auch für Review-Tools neue Möglichkeiten ergeben. 5.6 Einführung in die nächste Generation Hedberg [48] besagt, dass die bisherigen Features sich als nützlich erwiesen haben, aber heute nicht mehr ausreichend sind. Seiner Ansicht nach stellen die vorhandenen Tools eine Einschränkung für Organisationen dar, da sie immer nur einen einzigen Prozess zulassen. Darum erweitert er die bereits bekannten Features zusätzlich um die Features Integration und Flexibilität in Bezug auf den Prozess, den Dokumenten und den Metriken. Das Ziel soll sein, ein Tool zu erstellen, das möglichst allumfassend ist. Das bedeutet, dass nicht nur ein spezielles Review-Verfahren abgebildet werden soll, sondern mehrere konfigurierbar sein sollen. An geeigneten Stellen soll man das System auch verlassen können, wenn es ohne großen Aufwand und große Kosten möglich ist. Flexibilität bezüglich Dokumenten meint, dass möglichst viele verschiedene Dokumenttypen unterstützt werden müssen. Vor allem die Unterstützung von Grafikdokumenten sei immer noch nicht ausreichend. Integration von Dokumenten meint, dass die Mitglieder die Möglichkeit haben sollen, die Dokumente von ihrem ursprünglichen Ort zu beziehen. Zu achten sei dabei, dass alle Mitglieder der Gruppe immer die selbe Version zur Verfügung haben, was dazu führt, dass Versionsmanagement betrieben werden muss. Um auf die Ansprüche von Projekten und Organisationen eingehen zu können, müssen Prozesse flexibel gestaltet werden. Es reiche nicht, einen festen Prozess zu definieren und den mit dem Tool einer Organisation aufzuzwingen. Mehrere Prozesse müssen durch das Tool konfigurierbar sein. In manchen Projekten oder Organisationen ist ein hoch formalisierter Prozess unmöglich oder mit sehr hohen Kosten verbunden. Auch umgekehrt ist in sicherheitskritischen oder überhaupt kritischen Projekten ein hoch formalisierter Prozess unabdingbar. 28

34 Prozesse müssen ein integraler Bestandteil von Organisationen sein. Erst so erreicht man eine gewisse Qualität des eigenen Vorhabens und kann von Anfang an als eine konstruktive Maßnahme diese bestimmen. Tools sollen dabei helfen, die Tätigkeiten zu koordinieren und die Arbeit leichter zu bewältigen. Metriken stellen ein wichtiges Mittel den Prozess zu bewerten, um Schwachstellen im Prozess aufzuspüren und den Prozess nachhaltig zu verbessern. Ein Tool soll so viele Metriken wie möglich automatisiert erstellen können. Auch sollen sie genau referenzieren, auf was sie sich beziehen, um gezielt nach Ursachen zu suchen und eine Analyse durchführen zu können. Die Integration von Metriken meint auch das Abspeichern von Metriken in eine Datenbank. Dabei soll ein einheitliches Format benutzt werden, um ggf. diese Metriken in andere Tools auslagern zu können. Durch die Vereinheitlichung soll in einer Organisation eine Knowledge- Base entstehen, auf der zugegriffen werden kann. 5.7 Vergleich von Review-Tools Ein wesentlicher Unterschied zwischen den Review-Tools ist die Grundidee selber, was zu verschiedenen Generationen geführt hat. Ein weiterer Unterschied ist, dass jedes Tool seinen eigenen spezifischen Prozess implementiert. Aber manche Tools untereinander bilden mit geringen Abweichungen den selben Prozess ab. Folgende Tabelle 3 soll übersichtlich die Unterschiede in den Features zeigen. Document Individual Preparation Meeting Support Data Collection Handling 1. Generation ICICLE Quellcode Ad Hoc face to face JA COMPAS Text Ad Hoc face to face JA InspeQ Text Checklisten face to face - Text Ad Hoc face to face - Quality Group Generation Scrunity Text Ad Hoc synchron JA CSI alle Checklisten synchron JA GRIP/GSS Text Checklisten/Szenarios synchron JA 3. Generation CAIS Text Checklisten asynchron - CSRS Text Checklisten asynchron JA Notes Inspector alle Ad Hoc asynchron JA TAMMi alle Ad Hoc asynchron JA ASSIST alle Checklisten synchron/asynchron JA InspectA Text, Code Checklisten asynchron - 4. Generation AISA Alle Ad Hoc asynchron - HyperCode Quellcode Ad Hoc asynchron - WiP Text Checklisten asynchron - WiT Text Checklisten asynchron - InWin Text Checklisten asynchron - IBIS Alle Checklisten/Szenarios asynchron JA ReviewPro Text Checklisten asynchron JA XATI Alle Checklisten asynchron JA Tabelle 3: Vergleich von Review-Tools anhand der Features 29

35 Was noch ausbleibt ist der Vergleich zwischen der toolbasierten und papierbasierten Ausführung von Reviews. Obwohl einige Autoren preisen, sie hätten empirische Belege, nach denen man Schlüsse ziehen könnte, so handelt es sich nicht wirklich um empirische Belege, sondern eher um erste Erfahrungen. Lanubiles erste Erfahrung [55] mit seinem entwickelten Tool IBIS war, dass sich toolbasierte und papierbasierte Reviews sich in der Effektivität nicht signifikant unterscheiden. Auch andere Forscher haben solche erste Erfahrungen gemacht. Zu betonen ist, dass empirische Studien immer noch ausbleiben, aus denen man Schlüsse ziehen könnte. Es sind aber Studien in Planung, unter anderem von Lanubile. 5.8 Beispiel: Internet Based Inspection System (IBIS) IBIS (Internet Based Inspection System) wurde 2001 von Lanubile et al. [55] eingeführt. Bevor auf das Tool eingegangen werden soll, muss zunächst geklärt werden, was die grundlegenden Ideen sind, die bei der Erstellung dieses Tools eine Rolle gespielt haben. Auch Lanubile et al. betonen, dass das Tool den Zweck erfüllen soll, die Kosten eines realen Review-Prozesses zu senken, ohne an Effektivität zu verlieren. An dieser Stelle gebe es ein Problem, da reale Sitzungen die größten Kosten stellen, aber auch Vorteile haben, die schon in Kapitel 3.5 erläutert worden sind. Auf der anderen Seite seien reale Reviews auch oft nicht durchführbar, da in der Praxis immer mehr Gruppen geografisch verteilt seien. Daher müsse man einen Kompromiss finden, Reviews günstig zu halten, gleichzeitig ihre Effektivität zu behalten oder auch ggf. zu verbessern und auf die Gegebenheiten der geografischen Verteilung von Gruppen einzugehen. Als Lösung schlägt Lanubile ein Tool vor, welches asynchrone Kommunikation erlaubt und Gruppenmitglieder verteilt arbeiten lässt. Damit eliminiert er das reale und synchrone Meeting und spaltet dieses in zwei neue Phasen auf. Nachdem die Gutachter ihre Befunde erstellt haben, werden diese dann als Ersatz für ein Meeting nur zusammengesammelt. Dieses alleine reiche aber immer noch nicht aus. Daher fügt er eine optionale Phase an, die Diskriminierung, wo die Befunde diskutiert werden können. Dabei werden nur die Befunde diskutiert, die auch ausgewählt worden sind. Diese Phase dient dazu falsche Positive herauszufiltern. Aus dieser Idee heraus kreierten Lanubile et al. einen spezifischen Review-Prozess. Dieser Prozess hält sich nah an Fagans Inspektion, aber reale und synchrone Phasen werden durch nominale und asynchrone ersetzt. Abbildung 9 zeigt den prinzipiellen Ablauf, den das Tool IBIS abbildet. Abbildung 9: IBIS Prozess [55] 30