Softwarequalitätssicherung
Der Designprozess

Das Funktionenmodell

Hier werden die Schnittstellen zur Umgebung und der zugehörige Transfer von eingehenden und ausgehenden Daten definiert. Gleichzeitig wird das System strukturiert und die Anwendungsarchitektur festgelegt.

Dabei orientiert sich der Designprozess an der für Software allgemein gültigen Hierarchie:

• Ein Anwendungssystem (etwa ein Warenwirtschaftssystem) wird bei entsprechendem Umfang nach fachlichen und systemtechnischen Gesichtspunkten in möglichst unabhängige Teilsysteme (Inventur, Bestellwesen, Lagerverwaltung und andere) gegliedert.

• Das Anwendungssystem oder die Subsysteme werden in einzelne Anwendungsprogramme zerlegt, wobei darauf zu achten ist, dass zwischen den einzelnen Programmen möglichst wenig Abhängigkeiten bestehen.

• Alle von einem Programm zu bewältigenden Teilaufgaben werden als Prozeduren oder Funktionen definiert, wobei Funktionen mit verwandter Aufgabenstellung zu Modulen zusammengefasst werden.

Diese Strukturierung entspricht den zuvor dargestellten Ebenen der Softwareentwicklung und liefert eine Gliederung der Entwicklungsaufgaben nach unterschiedlichen Anforderungen an die fachliche Qualifikation der Entwickler.

Datenmodellierung

Aus der Konzeption der Anwendungsarchitektur ergibt sich die grundlegende Datenorganisation, die in allen Anwendungen der Dialog Data strikt eingehalten wird:

• Die Stammdaten enthalten über längere Zeit gleichbleibende Informationen und stehen völlig unter Kontrolle des Anwenders.

• Die Bewegungsdaten enthalten Transaktionen, die ebenfalls nur von Anwender verändert werden.

• Die Bestandsdaten umfassen jene Daten, die das System aus den Stammdaten und Bewegungsdaten erzeugt hat, zum Beispiel die Salden je Buchhaltungskonto. Diese Daten stehen unter Kontrolle der Software, der Anwender hat unter normalen Umständen keine Möglichkeit eine Veränderung. Er kann lediglich die Ausgangsdaten (Stammdaten oder Bewegungsdaten) modifizieren und die Verarbeitung wiederholen, mit welcher die Bestandsdaten erzeugt werden.

Hier wird die Zuständigkeit für die Datenbestände eindeutig geregelt und systemweit beachtet: Der Benutzer verwaltet Stammdaten und Bewegungsdaten, während das System die Bestandsdaten kontrolliert, was nicht zuletzt auch eine klarere Abgrenzung der Quelle für eventuelle Fehler erlaubt.

Das Ablaufmodell

Gleichzeitig erfolgt eine Gliederung nach den Bearbeitungsformen der Datenbestände, wobei folgende Formen unterschieden werden:

• Mit Erfassungsprogrammen für Stammdaten und Bewegungsdaten gibt der Anwender die benötigten Informationen in das System ein. Er kann sich darauf verlassen, dass das System die von ihm erfassten Daten in keiner Weise verändert.

• Die Verarbeitungsprogramme erzeugen aus den erfassten Daten neue Informationen, die als Bestandsdaten bezeichnet werden. Sofern nicht gesetzliche Vorschriften dagegen sprechen, müssen diese Verarbeitungen so gestaltet sein, dass sie jederzeit wiederholt werden können und aus den Eingangsdaten - sofern diese nicht mittlerweile verändert wurden - dieselben Bestände erzeugen wie bei allen vorangegangenen Ausführungen. In speziellen Fällen können diese Verarbeitungen in die Erfassungsprogramme integriert sein.

• Schließlich liefern Auswertungsprogramme Informationen aus den vorhandenen Stammdaten, Bewegungsdaten und Bestandsdaten. Diese Programme zeichnen sich dadurch aus, dass sie unter keinen Umständen die gespeicherten Daten verändern und vom Anwender beliebig oft ausgeführt werden können.

• Daneben werden in manchen Anwendungen Programme zur Reorganisation der Datenbestände benötigt, die jedoch hinsichtlich ihrer Funktionalität zu den Erfassungsprogrammen zählen und nur dazu dienen, Datenmanipulationen auszuführen, die der Anwender sonst händisch erledigen müsste, etwa wenn aus einer Adressenkartei alle Kunden gelöscht werden sollen, die seit mehr als fünf Jahren nichts gekauft haben.

Diese Abgrenzung ermöglicht unter anderem eine Klassifizierung der Programme nach ihrem Gefahrenpotential und eine entsprechende Anpassung des Entwicklungsprozesses und der Testprozeduren. Die Auswertungsprogramme haben beispielsweise nur lesenden Zugriff auf die Dateien, verändern keinerlei Datenbestände und können damit keine Fehler enthalten, die zu Folgeschäden im System führen. Andererseits stellen Verarbeitungsprogramme und Reorganisationsfunktionen in der Regel keine besonderen Anforderungen an die Benutzerschnittstellen, sind jedoch hinsichtlich der Konsistenz der Datenbestände besonders kritisch.

Modulstruktur

Dazu wird der Softwareentwurf unter Berücksichtigung der obigen Grundsätze nach vier Gesichtspunkten gegliedert:

1. Die Modellierung des Datensystems analysiert die von der Software bearbeiteten Daten, speziell jene, die auf externen Massenspeichern abgelegt werden, fasst sie zu sinnvollen Einheiten zusammen und erstellt für jede Einheit einen Entwicklungsauftrag an die Modulentwicklung. Kein Programm darf auf externe Datenbestände direkt zugreifen, sondern muss für die Zugriffsoperationen ausschließlich die dafür vorgesehenen Modulfunktionen verwenden. Die physische Speicherung der Daten bleibt den Anwendungsprogrammen damit vollständig verborgen und kann jederzeit gegen ein anderes Modell ausgetauscht werden.

2. Bei der Analyse der Funktionen wird die Aufgabenstellung so weit in Teilaufgaben zerlegt, dass jede Teilaufgabe nur noch eine spezielle Funktion zu erfüllen hat. Für jede dieser Funktionen wird geprüft, ob in den Softwarebibliotheken bereits eine Lösung dazu verfügbar ist, was im Durchschnitt bei 80 % der benötigten Funktionen der Fall ist, weshalb dieser Anteil der Software keine Entwicklungsarbeit erfordert, sondern durch Wiederverwendung gelöst wird. Für alle nicht verfügbaren Funktionen werden wie bei Dateioperationen Entwicklungsaufträge an die Modulentwicklung vergeben.

3. Die Gestaltung der Benutzerinterfaces legt das Layout von Bildschirmmasken und Listen fest. Für diese Benutzerinterfaces werden ausschließlich bereits verfügbare Standardprozeduren verwendet, weshalb hier lediglich Konfigurationsaufgaben zu bewältigen sind. Für Benutzerinteraktionen gelten dieselben Grundsätze wie für Dateizugriffe: Kein Anwendungsprogramm darf derartige Operationen selbst ausführen, sondern muss dazu die Standardfunktionen aus den entsprechenden Softwarebibliotheken verwenden.

4. Die Analyse der Dynamik legt die programminternen Abläufe und Interaktionen fest, wobei sich die Struktur der eigentlichen Anwendungsprogramme ergibt.

Auch in dieser Gliederung zeigt sich das Grundkonzept der Softwareentwicklung der Dialog Data: Drei Viertel der Aufgaben (nämlich die ersten drei Punkte in der obigen Übersicht) werden in standardisierter und wiederverwendbarer Form über Bibliotheksfunktionen gelöst, während die Anwendungsprogramme (Punkt 4) sich darauf beschränken, diese Funktionen in einer sinnvollen Reihenfolge anzuwenden.

Wiederverwendung

Neben den nachstehend noch behandelten Vorteilen der Wiederverwendung ergibt sich aus diesem Konzept eine wesentlich höhere Produktivität der Softwareentwicklung, da ein neues Programm im Durchschnitt zu 80 % aus wiederverwendeten Funktionen besteht. Auch die Softwarewartung profitiert ganz wesentlich davon, da Anpassungen der Funktionalität nur beim jeweiligen Modul vorgenommen werden müssen und danach automatisch in der gesamten Software verwendet werden.

Dem Benutzer zeigt die Software auch über mehrere Anwendungssysteme hinweg ein einheitliches Verhalten. Die Funktionalität ist dem Anwender oft schon aus anderen Anwendungen bekannt, was den Einarbeitungsaufwand ebenso wie die Möglichkeiten zur Fehlbedienung reduziert.

Fehlervermeidung durch Design

Der Designprozess sichert nicht nur die qualitativen Eigenschaften der Software, sondern beinhaltet durch entsprechende Konzeption und Gliederung der Programme, Module und Funktionen wesentliche Voraussetzungen für eine umfassende Fehlervermeidung:

Zunächst werden Fehlerquellen durch das strikte Wiederverwendungskonzept reduziert: Wenn Softwareteile nicht neu entwickelt werden müssen, können dabei auch keine neuen Fehler auftreten. Bei einem Wiederverwendungsanteil von 80 % werden bereits auf diese Weise vier Fünftel aller möglichen Fehler ausgeschlossen. Die wiederverwendeten Funktionen haben neben etlichen weiteren den Vorteil, dass sie bereits in der Praxis eingesetzt werden, extrem gut getestet sind und wegen der permanenten Verbesserungsmaßnahmen die Anforderungen des konkreten Entwicklungsauftrags in den meisten Fällen von vornherein übertreffen.

Da die Softwareentwicklung der Dialog Data für praktisch alle in kommerziellen Anwendungen benötigten Standardaufgaben bereits vorgefertigte, wiederverwendbare und sehr robuste Funktionen in Softwarebibliotheken verfügt, können bereits auf diesem Weg zahlreiche Fehlerquellen eliminiert werden. Gerade die kritischen und fehleranfälligen Routinen mit komplexer Aufgabenstellung sind längst entwickelt, extrem gut getestet und haben sich in der Praxis vielfach bewährt.

Insgesamt stehen derzeit etwa 9.000 wiederverwendbare Funktionen zur Verfügung, was in einer weiteren Hinsicht zu einer Verringerung der Fehlerquellen führt: Die Programmierung kann sich auf die wirklich neuen Verarbeitungen konzentrieren und sich bei vielen Teilaufgaben auf Funktionsaufrufe beschränken, was zu entsprechend handlichen Routinen und Programmen führt. Das Ergebnis dieser Bemühungen ist an der derzeit verfügbaren Software erkennbar: Die durchschnittliche Länge einer Sourcedatei beträgt 133 Textzeilen, es gibt insgesamt nur drei Module mit mehr als 1000 Zeilen, wobei der größte eine Länge von 1500 Zeilen hat. Die durchschnittliche Länge einer Funktion beträgt überhaupt nur 25 Zeilen.

Damit ist jede Funktion auf die absolut notwendige Komplexität reduziert, hat einen mit freiem Auge überschaubaren Umfang und kann mit 100 % Abdeckung getestet werden. Die Fehlerfreiheit jeder einzelnen Funktion ist daher mit beinahe absoluter Sicherheit gegeben, was ein wesentlicher Grund dafür ist, dass ein Programm der Dialog Data niemals abstürzt.

Als Nebeneffekt dieser Konzeption hat jeder Programmierer die Möglichkeit, mit einfachsten Mitteln unter Verwendung der verfügbaren Bausteine hochintelligente und komplexe Verarbeitungen zu entwickeln, ohne große Folgeprobleme befürchten zu müssen. Das ist nicht zuletzt auch eine Voraussetzung dafür, dass Firmen mit eigener Softwareentwicklung die Bibliotheken der Dialog Data auch für Eigenentwicklungen verwenden.

Ein weiterer Aspekt der Fehlervermeidung durch Modularisierung und Wiederverwendung besteht in der drastischen Reduzierung der Fehlergefahr bei Programmänderungen: Falls die Arbeitsweise einer Funktion anzupassen ist oder die Funktionalität erweitert werden soll, muss nur ein klar abgegrenzter Modul verändert werden.

Zusätzlich haben derartige Änderungen globale Auswirkungen: Nach der Neukompilation enthalten alle Programme - oft über mehrere Anwendungssysteme hinweg - die neue Funktionalität, ohne dass bei der Änderung des Moduls überhaupt bekannt ist, in welchen Programmen die betreffende Funktion tatsächlich verwendet wird. Durch Änderung einer einzelnen Funktion können 30 oder 50 Programme verbessert werden, ohne dass die Programmentwicklung die Sourcedateien dieser Programme auch nur betrachtet, was die Fehlergefahr eminent vermindert.

Durch die Modularisierung und die damit zusammenhängende detaillierte Konzeption aller Funktionen werden nicht nur Designfehler und Inkonsistenzen frühzeitig erkannt, der weitere Entwicklungsablauf ist vielmehr in so kleine Einheiten gegliedert, dass er weitgehend automatisiert und in Eigenverantwortung durch den Entwickler erledigt werden kann (siehe Entwicklungsprozess im nächsten Abschnitt).

Prototyping

In der Entwicklung sind für bestimmte, immer wieder benötigte Verarbeitungsformen Prototypen vorhanden, die für eine konkrete Aufgabe nur noch entsprechend adaptiert werden müssen. Beispielsweise arbeitet die Erfassung für die meisten Stammdaten nach demselben Muster. Zur Entwicklung eines neuen Erfassungsprogramms müssen im Prototyp nur noch die benötigten Datenfeldoperationen eingebaut und die Zugriffe auf den entsprechenden Dateiverwaltungsmodul eingebaut sowie die Benutzerinterfaces konfiguriert werden.

Schließlich werden Prototypen beim Test der Software verwendet, wenn von einem System erst einzelne Module fertiggestellt sind. Ein Datenzugriffsmodul kann nicht getestet werden, wenn die entsprechenden Erfassungsfunktionen noch nicht entwickelt sind. In solchen Fällen werden die fehlenden Systembestandteile durch Prototypen ersetzt, welche unter Verwendung derselben Schnittstellen verwenden wie die geplanten Module deren Funktionalität simulieren.