Die Cleanroom-Methode setzt sich aus einer ganzen Anzahl von Maßnahmen zusammen, die ineinandergreifen.
Große Systeme werden in Teile zerlegt, die von kleinen Teams aus etwa sechs bis acht Personen hergestellt werden. Das erzwingt zum einen eine sorgfältige Spezifikation und zieht zum anderen zwei weitere Vorteile nach sich: Die Gesamtentwicklungszeit kann reduziert werden, da die einzelnen Teams unabhängig voneinander arbeiten können, und die Teams sind effizient und motiviert, weil weder eine Isolation einzelner Entwickler erfolgt, noch starke Reibungsverluste wie in großen Teams auftreten. Die Mitglieder solcher Teams begutachten ihre Arbeit gegenseitig, um ständig ein hohes Qualitätsniveau zu sichern. Ein wichtiger Aspekt von Cleanroom ist, daß die Teams sehr entschieden darauf eingeschworen werden, höchste Qualität abzuliefern. Die geringe Teamgröße erleichtert es, diesen Vorsatz auch umzusetzen, weil sich einzelne Mitglieder bei Mängeln nicht so sehr hinter einer großen Zahl anderer möglicher Schuldiger verstecken können.
Es gibt zwei völlig getrennte Arten von solchen Teams: Entwicklungsteams und Testteams.
Entwicklungsteams sind ausschließlich für die Herstellung der Software zuständig. Sie sollen von vornherein ein Produkt höchster Qualität abliefern. Zur Herstellung und Sicherung dieser Qualität verwenden sie ausschließlich Betrachtungen des Programms selbst, sowohl in seiner Quellcodeform als auch vor allem auf der Ebene seiner Entwurfsrepräsentationen. Ein Entwicklungsteam führt die Software niemals aus.
Testteams hingegen sind ausschließlich für die Feststellung der Zuverlässigkeit der Software zuständig. Dazu bedienen sie sich der Methode des statistischen Testens. Ein Testteam führt niemals eine Änderung an der Software aus und betrachtet niemals die Software von einem anderen Standpunkt als dem der Ausführung.
Die Spezifikation von Software wird möglichst mit mathematischen Sprachmitteln beschrieben, d.h. mit solchen Sprachmitteln, die eine genau definierte Semantik haben. Dem liegt die Annahme zugrunde, daß erstens ein großer Teil von Softwarefehlern daher stammt, daß die Aufgabenstellung nicht klar genug beschrieben war und daß zweitens überhaupt nur mit einer exakten Definition der Aufgabe auch exakt definiert werden kann, was eigentlich ein Softwarefehler ist. Im Kontrast hierzu kursiert im Softwarebereich stellenweise immer noch der fliegende Spruch ``It's not a bug, it's a feature!''. Eine exakte Spezifikation ist natürlich auch Voraussetzung dafür, mathematische Methoden bei der Korrektheitsprüfung einsetzen zu können.
Eine exakte Spezifikation wird nicht nur am Anfang der Entwicklung erzeugt, sondern ist auch das Produkt jeder Zwischenstufe beim Entwurf. Konkret werden dafür z.B. Spezifikationssprachen wie Z oder VDM eingesetzt oder auch die Kastenspezifikation (box structuring method). Auch problemspezifische Methoden (Spezialgrammatiken) kommen in Frage, welche sich weitgehend einer natürlichsprachlichen Spezifikation annähern können; jedoch ist immer darauf zu achten, daß alle Teile der Spezifikation wohldefiniert sind, also eine und nur eine Bedeutung haben.
Offensichtlich verlangt diese Herangehensweise, daß die Anforderungen an die Software bei Beginn der Entwicklung feststehen. Da dies in realen Situationen nur selten der Fall ist, scheint Cleanroom kaum je wirklich anwendbar zu sein. Tatsächlich bedeutet ,,feststehen`` aber nicht, daß nichts mehr an den Anforderungen geändert werden kann, sobald die Entwicklung begonnen hat, sondern nur, daß überhaupt erst einmal Anforderungen festgeschrieben werden müssen, damit eine Basis für eine zielgerichtete Entwicklung vorliegt. Sollten Änderungen in den Anforderungen nötig werden, müssen diese zu einem geeigneten Zeitpunkt eingebracht werden und werden dann quasi als eigener Entwicklungsauftrag gehandhabt.
Der Entwurf erfolgt nach der Methode der schrittweisen Verfeinerung. Dabei wird eine Spezifikation in mehreren Schritten in Richtung einer Implementation konkretisiert. Eingabe jedes Schrittes ist eine Spezifikation, Ausgabe ist eine Zerlegung der spezifizierten Funktion in mehrere Teile, deren Zusammenwirken beschrieben wird und die jeweils wiederum spezifiziert werden und dann entweder Eingabe eines weiteren Verfeinerungsschrittes sind oder als elementar betrachtet werden können.
Jeder Verfeinerungsschritt wird einer Prüfung unterzogen, die in Cleanroom Verifikation genannt wird. Da auf jeder Verfeinerungsstufe alle Teile entweder schon realisiert oder genau spezifiziert sind, kann man für jede solche Verfeinerung einen Korrektheitsbeweis konstruieren, der zumindest annähernd der mathematischen Bedeutung dieses Wortes genügt. Ein solcher Beweis wird in Cleanroom vom Entwerfer einer Verfeinerungsstufe konstruiert und dann in einer Teaminspektion begutachtet, wobei die einzusetzenden Verfahren der Form der Spezifikation und dem jeweiligen Anwendungsfall angepaßt werden, aber in jedem Fall in mathematischer Logik gründen. Das Inspektionsteam versucht sich unter der Leitung der Erfinder der Verfeinerung von der Korrektheit der Verfeinerung zu überzeugen. Echte mathematische Verifikationen mit mathematischer Notation werden nur in einem sehr kleinen Teil der Fälle durchgeführt, zumeist für die kritischen Transaktionskerne einer Anwendung.
Damit die Entwicklung beherrschbar bleibt, werden stets nur Komponenten überschaubarer Größe entwickelt. Eine Spezifikation wird deshalb in Teile von höchstens etwa 10000 Zeilen Code zerlegt. Diese Teile werden Inkremente genannt. Ein Inkrement kann entweder auf einem früheren Inkrement aufbauen (inkrementelle Entwicklung) oder von anderen Inkrementen unabhängig sein (separate Entwicklung). In beiden Fällen müssen Inkremente jedoch so definiert werden, daß nach Abschluß der Entwicklung eines Inkrements dieses ausführbar ist und ohne spezielle Testtreiber getestet werden kann.
Bei herkömmlicher Softwareentwicklung sind als Testmethoden vor allem das Funktionstesten (black box test) und das Strukturtesten (white box test) üblich.
Funktionstesten orientiert sich für die Definition der Testfälle nur an der Spezifikation der Software und strebt üblicherweise eine gute Abdeckung der diversen Äquivalenzklassen von Eingaben an, die unterschiedliche Klassen von Ausgaben erzeugen.
Das Strukturtesten legt demgegenüber die konkrete Implementation der Software bei der Auswahl der Testfälle zugrunde und versucht, eine möglichst gute Abdeckung gewisser Ausführungspfade des Programms zu erreichen. Ein Beispiel für eine Technik dieser Art ist der strukturorientierte Datenflußtest, der in der Vorlesung Softwaretechnik besprochen wird.
In Cleanroom wird ausschließlich das Funktionstesten verwendet. Dies hat den Vorteil, daß Testfälle bereits während der Programmentwicklung definiert werden können. Die Testfälle werden dabei nicht wie üblich von Hand definiert, sondern als Zufallsstichprobe aus einer Grundgesamtheit ausgewählt, die das erwartete tatsächliche Benutzungsprofil der Software widerspiegelt.
Wie erhält man diese Grundgesamtheit? Dazu ist ein Prozeß nötig, der in Cleanroom die Benutzungsmodellierung genannt wird: Es wird ein stochastisches mathematisches Modell aufgestellt, das den Prozeß modelliert, der die Programmeingaben erzeugt. Dieses Modell wird dann ausgeführt, um die Testfälle zu erhalten. Das Modell oder eine etwas weniger genaue Beschreibung davon ist Bestandteil der Spezifikation, die am Anfang der Entwicklung steht.
Zweck des Testens in Cleanroom ist nicht die Suche von Fehlern, sondern die Beurteilung der Zuverlässigkeit der Software, die bereits zu Beginn des Testens als weitgehend fehlerfrei angenommen wird.
![\includegraphics[scale=1]{Bild/cleanprozess.ps}](img70.gif)
Abbildung 7.2 zeigt nochmals grob im Überblick die Abfolge der Arbeitsschritte und den Datenfluß zwischen ihnen für eine Cleanroom-Softwareentwicklung: Nach der Erstellung der Gesamtspezifikation wird jeweils ein Inkrement definiert und bearbeitet (im allgemeinen werden natürlich alle Inkremente zu Beginn vorgeplant). Innerhalb jedes Inkrements wird zunächst parallel von der Entwicklungsgruppe das Programm sowie von der Testgruppe das Benutzungsmodell und daraus die Menge der Testfälle erstellt. Dabei erfolgt die Programmentwicklung nach der Methode der schrittweisen Verfeinerung mit Begutachtung und Verifikation jedes Verfeinerungsschritts. Nach Fertigstellung des Programms wird vom Testteam der statistische Test durchgeführt, der zu einer quantitativen Aussage über die Zuverlässigkeit führt.
Es sei hier noch angemerkt, daß die obenerwähnten Techniken und Ansätze nicht unabdingbar oder unersetzlich für die Cleanroom-Methode sind. Cleanroom verlangt nur, daß Fehlervermeidung im Vordergrund steht und abschließend eine gewisse Zuverlässigkeit zugesichert werden kann. Jeder der obengenannten Ansätze kann im Prinzip durch andere Techniken ergänzt oder ersetzt werden. Die geschilderten Ansätze sind lediglich die wichtigsten derzeit für günstig befundenen Methoden, die zum angestrebten Ziel führen. Insbesondere können alle Anforderungen aufgeweicht werden und werden das auch häufig mehr oder weniger stark: Die Spezifikation ist nur teilweise mathematisch, ein Teil bleibt natürlichsprachlich; die Verifikationsschritte werden zum Teil mit nichtmathematischen Schlußweisen durchgeführt; Fehler, die im statistischen Testen noch auftreten, werden eventuell mit Debugging-Methoden gesucht und dann entfernt. Eine klare Abgrenzung, wann man einen Entwicklungsprozeß sinnvollerweise als Cleanroom-Prozeß bezeichnen kann, gibt es nicht.