Peer Review, die Qualitätskontrolle durch Kollegen, durch Fachleute, die den gleichen Job machen wie der Autor selbst, ist mehr als dass einer zum anderen sagt: “Hey, schau dir doch mal an, was ich da gemacht habe und sag mir mal, ob dir irgendwelche Fehler auffallen”. Peer Review ist ein organisierter und weitgehend formalisierter Prozess, und nur als solch ein Prozess ist er eine Methode zur Qualitätssicherung im Projekt.

Peer Review kann für die Qualitätsprüfung aller Lieferbestandteile eines Projektes eingesetzt werden, seien es Anforderungsdokumente, Spezifikationen, Projektpläne, Software-Module oder Handbücher. Besonders effizient ist es allerdings bei Anforderungsdokumenten und Spezifikationen, deren Qualität nicht wie bei Software im Black-Box.Verfahren getestet werden kann und bei denen (im Gegensatz zu Projektplänen und Handbüchern) meist eine ausreichende Zahl von Peers, also von Kollegen, die ebenfalls Dokumente dieses Typs schreiben, zur Verfügung stehen.

Ähnlich wie beim wissenschaftlichen Peer Review sollte sich auch im IT-Projekt der Autor nicht selbst seine Peers zur Kontrolle aussuchen, dazu wird die Rolle des Editors eingeführt. Der Editor wählt für jedes Dokument wenigstens zwei Peers aus, die dieses begutachten. Die Gutachter geben ihre strukturierten und formalisierten Gutachten (dafür gibt es entsprechende Templates) zum vereinbarten Termin an den Editor, möglicherweise mit einem Vorschlag zum weiteren Verfahren. Der Editor entscheidet dann, ob das Dokument freigegeben wird oder ob es nach Überarbeitung entweder direkt freigegeben werden kann oder erneut durch den Review muss.

Wie das Peer Review genau durchgeführt wird, hängt von einer reihe von Projektparametern ab, danach ist auch zu entscheiden, ob gemeinsame Sitzungen der Peers mit dem Autoren durchgeführt werden, was Vor- aber auch Nachteile hat. Wirklich effizient wird der Peer Review erst durch die Anpassung des Verfahrens an die konkrete Projektsituation.

Peer Review im Softwareprozess ist eine zeitsparende Methode zur Qualitätssicherung, die gleichzeitig das Projektwissen gut verteilt.

Der Beitrag Peer Review im Softwareprojekt erschien zuerst auf INDAL Software-Spezialist.

Zunächst einmal ist eine begriffliche Klärung notwendig. Viele Projektbeteiligte bezeichnen quasi alles, was in irgendeiner Form bereitgestellt wird, damit die Entwicklungs-Firma ihre Arbeit machen kann, als Spezifikation – oft als Anforderungs-Spezifikation, bezeichnet. Das erweckt den Eindruck, als ob in all diesen Dokumenten irgendwie das Gleiche stehen würde. Aber es gibt riesige Unterschiede.

Ein Beispiel aus einem ganz anderen Bereich soll das verdeutlichen:

Stellen Sie sich vor, Sie wollen ein Haus für Ihre Familie bauen. Sie gehen also zum Architekten, und der fragt Sie erst einmal aus:

• Wieviele Personen sollen in dem Haus wohnen, welches Alter haben diese Menschen (Kinder, Großeltern,…)?
• Welche Hobbies haben Sie, kochen Sie gern, sind Sie Handwerker,…?
• Was ist Ihnen sonst noch wichtig?

Das alles fasst der Architekt in einem Dokument zusammen und stimmt es mit Ihnen ab. Das ist das Anforderungsdokument.

Dann macht der Architekt Ansichten, Zeichnungen, Grundrisse, das alles sind Modelle, die Ihnen zeigen, wie Ihr Haus einmal aussehen wird, die Ihnen schon jetzt sichtbar machen, was Sie auch später einmal sehen werden. Diese Modelle bilden das, was wir im Software-Projekt das Fachkonzept nennen. Das Fachkonzept zeigt, wie das fertige System einmal für den Nutzer aussehen wird, wie es sich sozusagen an der Außen-Schnittstelle zeigt.

Dann kommen die Ingenieure ins Spiel. Sie entwerfen die eigentliche Struktur des Hauses:

• Wie sind die Wände und die Decken aufgebaut?
• Wie wird die Statik sicher gestellt?
• Woraus besteht das Dach?

Diesen Dokumenten entspricht das DV-Konzept im Softwareprojekt.

Es ist klar, dass Sie als Bauherr nicht an der Statik erkennen können, ob Ihre Kinder sich in dem Haus einmal wohl fühlen werden. Deshalb wird ein guter Architekt mit Ihnen zuerst Ihre Anforderungen aufschreiben, und Ihnen dann zeigen, wie diese Anforderungen in den Außenansichten und Grundrissen umgesetzt werden.

Damit ein gutes Ergebnis entsteht, sind also drei Schritte notwendig, und in jedem Schritt braucht man

• eine geeignete Sprache, in der die Beteiligten das Dokument verstehen,
• einen optimalen Detaillierungsgrad
• ein spezielles Know-How bei dem, der das jeweilige Dokument erstellt.

Genauso ist es beim Software-Projekt.

1. Der Business Analyst erfasst die Anforderungen und dokumentiert diese in einer strukturierten Form. Er stellt sicher, dass alle Anforderungs-Typen berücksichtigt werden und mögliche Wechselwirkungen zwischen Anforderungen bereits frühzeitig mit dem Nutzer erkannt werden.
2. Der Funktionale Analyst stellt dar, wie das System für externe Akteuer aussieht. Dabei kann es sich um Benutzer, aber auch um andere Systeme handeln.
3. Der System-Architekt konstruiert das eigentliche System, er entwirft Schichten und Module. Diese Arbeit kann in unterschiedlichem Detaillierungs-Grad erfolgen.

Wichtig ist, dass sich jeder Autor mit sowohl mit dem versteht, der ihm Informationen liefert, als auch mit demjenigen, der als Adressat seine Ergebnisse weiter verarbeitet.

Der Beitrag Der Sinn unterschiedlicher Spezifikationen erschien zuerst auf INDAL Software-Spezialist.