Softwarequalitätssicherung
Steuerung der Entwicklung

Prozesssteuerung

Der Prozess selbst durchläuft für jedes Teilprodukt sechs verschiedene Zustände mit ebenso vielen Zustandsübergängen:

Dieses System bietet eine Reihe von Vorteilen:

• Die Aufgaben innerhalb des Teams sind exakt festgelegt.

• Das Kontrollsystem ist äußerst flexibel und für die Erfordernisse des jeweiligen Projekts optimal konfigurierbar: Es besteht aus insgesamt 46 Programmen und Funktionen zur Prozesssteuerung, schreibt jedoch keinerlei Methoden für die Entwicklung, die Tests oder die Integration der bearbeiteten Produkte vor. Die diesbezüglichen Verfahren können für jedes Produkt speziell konfiguriert werden, weshalb etwa für Entwicklung oder Konfigurationsmanagement von Software und Dokumenten jeweils die optimal geeigneten Systeme eingesetzt werden können.

• Die einzelnen Phasen sind klar voneinander abgegrenzt, wobei der Übergang von einer Phase zur nächsten nur unter bestimmten Voraussetzungen möglich ist, die einerseits vom Administrator und andererseits von der CASE-Software selbst bestimmt werden.

• Alle Vorgänge und Zustandsübergänge werden exakt protokolliert und sind jederzeit nachvollziehbar.

• Ebenso sind alle früheren Produktversionen verfügbar und können bei Bedarf wiederhergestellt werden.

• Die Vorgänge werden in einer solchen Weise gesteuert, dass alle Aspekte der Qualitätssicherung berücksichtigt werden. Zum Beispiel ist es nicht möglich, dass ein Entwickler Reviews mit seinen eigenen Produkten durchführt.

• Sämtliche zur Überprüfung der Entwicklungsarbeiten benötigten Tests müssen schon bei der Spezifikation der geplanten Aufgabe festgelegt werden und werden vom System im Zuge der Integration vollautomatisch ausgeführt. Eine Einschränkung besteht diesbezüglich nur beim Test von GUI-Anwendungen die eine Interaktion mit dem Benutzer erfordern, etwa dem Testen von Mausfunktionen. Schlägt auch nur einer der vorgesehenen Tests fehl, wird die Freigabe des gesamten Entwicklungsprojekts vom Kontrollsystem unterbunden.

• Das System überwacht eine Reihe von Abhängigkeiten: Wird beispielsweise eine Schnittstelle in einem Programm verändert, so müssen alle anderen Programme angepasst werden, welche dieselbe Schnittstelle verwenden, bevor das System eine Freigabe zulässt.

• Auch die Konfiguration der Prozesssteuerung selbst unterliegt der Versionskontrolle: Alle Änderungen werden aufgezeichnet, früher verwendete Versionen sind jederzeit rekonstruierbar.

• Es können auch mehrere Entwickler gleichzeitig dasselbe Produkt bearbeiten und unterschiedliche Änderungen daran vornehmen. Alle Modifikationen werden vom Kontrollsystem automatisch zusammengeführt.

• Da die Kontrollsoftware alle Produkte in einer eigenen Datenbank verwaltet und Zugriffe nur entsprechend dem jeweiligen Entwicklungsstatus den dazu befugten Teammitgliedern erlaubt, sind Änderungen an der Software unter Umgehung des Kontrollsystems ausgeschlossen.

Die von diesem CASE-System überwachten Projekte können einen beliebigen Umfang mit unbegrenzter Zahl von Teilprodukten und jeder benötigten Anzahl von Teammitgliedern aufweisen.

In den Entwicklungsprojekten der Dialog Data werden die zuvor beschriebenen Ebenen der Softwareentwicklung streng eingehalten: Für Module und Programme werden jeweils eigene Entwicklungsprojekte eingerichtet. Bei Anwendungssystemen wird dieses System derzeit nicht eingesetzt, weil hier nur Konfigurationsarbeiten ohne eigentliche Softwareentwicklung vorgenommen werden.

Die Prozesssteuerungssoftware wird nicht nur zur Steuerung sämtlicher Softwareentwicklungsprojekte verwendet, sondern auch für die Ausarbeitung von Dokumenten eingesetzt, welche der Versionskontrolle unterliegen. Sie wird auch in derselben Form sowohl für Neuentwicklungen wie für Änderungen an bereits vorhandenen Produkten verwendet: Eine Neuentwicklung unterscheidet sich von einer Änderung nur dadurch, dass zu Beginn eine leere Datei anstelle einer früheren Produktversion verwendet wird.

Methoden und Verfahren in der Entwicklungsphase

Für jede Teilaufgabe erhält der Entwickler einen eigenen Arbeitsauftrag mit einem Modulentwurf, welcher die Schnittstellen der Funktionen, die benötigte Funktionalität und alle Testfälle enthält. Wenn alle Voraussetzungen erfüllt und die erforderlichen Unterlagen verfügbar sind, wird die Entwicklung des im Arbeitsauftrag bezeichneten Moduls oder Programms vom Administrator freigegeben. Der Arbeitsauftrag enthält auch eine Checkliste mit allen vom Entwickler selbst durchzuführenden Prüfverfahren, um den Aufwand bei den Reviews durch entsprechend gute Vorbereitung minimal zu halten.

Der Entwickler kann vom System die benötigten Dateien anfordern und in der vorgegebenen Weise modifizieren oder neu erstellen. Nach Abschluss der Entwicklungsarbeiten übergibt der Programmierer seine Dateien wieder dem System, das automatisch alle Änderungen aufzeichnet. Wenn mehrere Programmierer an demselben Modul arbeiten, führt das CASE-System die einzelnen Änderungen automatisch zu einer neuen Sourcedatei zusammen. Die Entwicklungsphase ist im übrigen der einzige Zustand, in welchem das CASE-System Veränderungen an Dateien des Projektes zulässt.

Dieses Verfahren wird bei der Programmierung ebenso angewendet wie bei der Ausarbeitung von Dokumentationen. In den meisten Fällen erfolgen diese Arbeiten ohnehin gleichzeitig, weil parallel zur Softwareentwicklung alle zugehörigen Dokumente im Rahmen eigener Entwicklungsprozesse - eventuell auch mit anderer Teamzusammensetzung - zu erstellen sind.

Reviews von Dokumenten und Programmen

Zu Beginn der Reviewphase hat das Kontrollsystem folgenden Zustand sichergestellt:

• Alle an der Aufgabe beteiligten Personen haben dem System den Abschluss ihrer Entwicklungsarbeiten bekannt gegeben und die von ihnen bearbeiteten Dateien an das Kontrollsystem retourniert.

• Das zu prüfende Produkt liegt in der aktuellsten Version vor und enthält alle von den Entwicklern vorgenommenen Änderungen.

• Handelt es sich beim Gegenstand des Reviews um ein Programm und nicht um ein Dokument, ist sichergestellt, dass es fehlerfrei kompiliert werden kann.

• Außerdem hat das Kontrollsystem alle in der Entwicklungskonfiguration vorgesehenen automatischen Tests fehlerlos ausführen können und dabei die vorgegebenen Ergebnisse erhalten.

Der Reviewer (oder die Reviewgruppe) ist mit den Zusammenhängen im Gesamtprojekt vertraut. Da etliche Voraussetzungen schon gegeben sind, kann er sich auf die Einhaltung der vorgegebenen Standards, Implementierungsaspekte und die Überprüfung der Vollständigkeit konzentrieren. Er kann sich dabei auf umfassende Informationen stützten:

• Die aktuelle Version des Produktes liegt in ausgedruckter Form vor.
• Zusätzlich zur Sourceliste ist bei Programmen der Output der statischen Syntaxanalyse verfügbar.
• Es wird weiters eine umfassende Crossreferenceliste erzeugt, die eingebundene Dateien, Präprozessordefinitionen, Typdefinitionen, alle Variablen sowie die internen und externen Funktionen und deren Verwendung darstellt.
• Daneben wird eine graphische Darstellung der Hierarchie von Funktionsaufrufen angefertigt, die externe und interne Funktionen einbezieht und sowohl die von jeder Prozedur verwendeten Funktionen in Form eines Baumes darstellt wie auch für jede Funktion angibt, von welchen Prozeduren aus sie aufgerufen werden.
• Die Ausführungsprofile je Sourcezeile und je Funktion zeigen, wie oft und in welcher Folge die einzelnen Anweisungen bei der Ausführung der geprüften Routinen verwendet wurden.
• Alle automatisch ermittelten Metriken sind ebenfalls verfügbar.
• Es sind nicht zuletzt die Protokolle aller automatisch oder händisch durchgeführten Tests vorhanden.

Diese Auswertungen werden im Zuge der Testabwicklung vom CASE-System automatisch erstellt, sind online verfügbar und können jederzeit ausgedruckt werden. Diese Informationen geben dem Reviewer schon einleitend ein umfassendes Bild über die Struktur und die Abläufe der geprüften Verarbeitung.

Eine wichtige Aufgabe bei Reviews besteht darin, alle Vorgaben bezüglich der Wiederverwendung zu überwachen und sicherzustellen, dass als Bibliotheksfunktionen verfügbare Prozeduren nicht ein zweites Mal ausprogrammiert wurden. Neben der zusätzlichen Fehlerquelle würde eine derartige Vorgangsweise dazu führen, dass künftige Änderungen der Bibliotheksroutinen dieses Produkt nicht einbeziehen würden.

Ebenso ist es Aufgabe des Reviews, alle jene Tests mit dem Produkt auszuführen, die vom CASE-System nicht automatisch bewältigt werden können. Diese Tests beschränken sich auf die in das Review einbezogenen Produkte, während globalere Tests in der Integrationsphase erfolgen.

Nicht zuletzt erfolgt im Zuge des Reviews die Softwarebewertung nach den standardisierten Kriterien der Dialog Data (siehe Softwarebewertung in einem der folgenden Kapitel).

Jedes Review wird nach einem standardisierten Reviewplan abgewickelt und protokolliert.

Das Ergebnis des Reviews wird dem Kontrollsystem vom Reviewer mitgeteilt, worauf das System entweder zur Entwicklung zurückkehrt oder die Integration erwartet. Falls das Review negativ endet, muss der Reviewer dem System eine Datei übergeben, in welcher die Gründe für die Ablehnung beschrieben sind. Diese Datei wird vom CASE-System in die Projektdokumentation übernommen.

Integration und Freigabe

Zu Beginn der Integration werden alle benötigten Bestandteile vom System nochmals automatisch kompiliert und getestet, um sicherzustellen, dass auch das aus den Teilprodukten zusammengesetzte Integrationsobjekt einwandfrei erzeugt und getestet werden kann und dass keine Fehler mehr vorhanden sind, wenn diese Produkte in den aktuellen Stand der Projektdateien übernommen werden.

Wenn er entsprechende Gründe dafür hat, kann der Integrator die Integration abbrechen und das System in den Entwicklungszustand zurückversetzen. Das wird dann der Fall sein, wenn das Integrationsergebnis irgendwelche Vorgaben verletzt, die nicht automatisch geprüft werden können. Die Rolle des Integrators enthält also auch eine weitere Reviewfunktion.

Wenn der Integrator zustimmt, wird die integrierte Version des Produktes in den aktuellen Stand des Produktes übernommen und ersetzt logisch die Vorgängerversion in der Datenbank des Kontrollsystems (selbstverständlich bleiben auch alle vorherigen Versionen erhalten, sind aber für Änderungen nicht mehr zugänglich). Parallel dazu werden alle Protokolldateien archiviert, in welchen die einzelnen Vorgänge im Projekt aufgezeichnet sind. Gleichzeitig erfolgt die Freigabe des Produktes, womit die neue Version auch für andere Projekte zugänglich wird.

Die Integration ist auch bei Dokumenten erforderlich, weil hier alle eingebundenen Teildateien und Graphiken zu einem Dokument zusammengeführt werden und erst in dieser Phase die Korrektheit hinsichtlich fortlaufender Nummerierung von Kapiteln, Abbildungen und Tabellen sowie der verschiedenen Inhaltsverzeichnisse überprüft werden kann.