Das nachfolgende Kapitel beschreibt eingeführte analytische Qualitätssicherungsmaßnahmen sowie ausgewählte isolierte Einzelaspekte weiterer Ansätze.

In diesem Zusammenhang wird bewußt von analytischer Qualitätssicherung und nicht von empirischer Qualitätssicherung gesprochen. Jede menschliche Auseinandersetzung mit inhaltlichen und nicht nur rein formalen Aspekten eines Sachverhaltes ist eine analytische Tätigkeit, die menschlichen Geist voraussetzt.

In der kurzen Beschreibung wird hier zwischen Inspektion nach M. Fagan und Structured Walkthrough nach E. Yourdon nicht noch einmal unterschieden, obwohl hier deutliche Nuancen klar erkennbar sind.

Die folgenden drei Mechanismen beruhen auf der gleichen Grundlage, jedoch ist der am Evaluierungsprozeß beteiligte Personenkreis jeweils anders zusammengesetzt. Der zugrundeliegende Ablauf ist im folgenden Diagramm dargestellt.

Die beteiligten Gruppen sind der (die) Autor(en) und der (die) Leser. Vor einem Treffen über das Thema (Pflichtenheft, Entwurf) verteilt der Autor das Dokument 1 an die Leser. Diese haben ausreichend Zeit, um sich mit dem Material vor der Besprechung auseinanderzusetzen. In der Diskussion teilen die Leser dem Autor ihre kritischen Stellungnahmen 2 zu seinem Dokument mit. Der Autor oder eine beauftragte Person sammelt die Meinungen der Leser. Der Autor seinerseits nimmt dieses Protokoll zur Kenntnis und nimmt gegebenenfalls nach Überarbeitung seines Dokumentes Stellung 3 zu den einzelnen Punkten unter Angabe der erfolgten Maßnahmen.

Dies ist die informelle Form der Qualitätskontrolle. Der Autor des Dokumentes übergibt einem Mitarbeiter seiner Wahl das von ihm erstellte Dokument. Es liegt in seiner Verantwortung und in seinem Interesse, diesen Schritt durchzuführen, um sich von der Qualität seiner Arbeit zu überzeugen beziehungsweise erforderliche Korrekturen gegebenenfalls möglichst früh zu erledigen. Durch die freie Partnerwahl hat er die Möglichkeit, eine ihm genehme, geeignete Person zu bestimmen. Dadurch ist eine offene und erfolgreiche Diskussionsführung möglich.

Der "Structured Walkthrough" ist eine Besprechung im größeren Kreis. Die Verantwortung für die Durchführung liegt hier beim Projektteam. Jedoch wird hier immer noch auf eine Beteiligung des Managements verzichtet, um einer offenen Diskussion breiten Raum zu lassen. Durch diese Besprechung wird das Dokument dem Projektteam vorgestellt, das damit auch Verantwortlichkeit dafür übernimmt. Der größere Kreis von Kritikern, der jetzt vom Team bestimmt wird, bietet mehr Möglichkeit, Meinungen zu dem Dokument zu diskutieren. Das Team ist sowohl fachlich als auch projektbezogen eine Stelle, die den Gesamtzusammenhang des Dokuments gut überschauen können sollte.

Der "Review" ist schließlich ein formaler Akt. An ihm sind die Projektverantwortlichen inklusive Management und gegebenenfalls Kunden beteiligt. Er ist gleichzeitig ein Meilenstein in der Projektabwicklung. In der Regel wird er je Phase nur einmal stattfinden. Als Autor tritt das Projektteam an. Die Leser, die Kritik am Dokument üben, sind die Abnehmer des Systems und die Manager der erstellenden Firma. Durch diese Personenkonstellation erhält der Review einen bindenden Charakter, allerdings steht zu befürchten, daß in der Diskussion nicht mehr die Offenheit herrscht, die die beiden anderen Formen auszeichnet.

Bei großen Systemen nehmen die Anforderungsanalyse und -definitionsphase und die Softwareentwurfsphase viel Zeit in Anspruch. Dabei werden die Anforderungen des Benutzers festgehalten und finden ihren Niederschlag in Dokumenten (Pflichtenheft, Systemspezifikation), die im heutigen Entwicklungsprozeß meistens die einzige Rückkopplung darstellen.

Erst während der Implementierungsphase können dem Benutzer

Teilstücke seines zukünftigen Systems in einer Form zur Verfügung gestellt werden, die eine Überprüfung in seiner Arbeitsumgebung erlauben. Allzuoft werden erst hier mangelhafte Analyse- und Designergebnisse festgestellt.

Im Gegensatz dazu steht der Ansatz des "Prototyping". Anhand einer vollständigen Anforderungsanalyse werden die Schritte Anforderungsdefinition/Systementwurf, Prototypentwicklung/Verfeinerung und Prototypevoluierung solange durchlaufen, bis ein stabiler Prototyp erreicht wird. Das zugrundeliegende Konzept kann dabei mit der Planung größerer Bauvorhaben (Bauzeichnungen, Modellerstellung) verglichen werden. Analog wird hier eine faßbare Perspektive der ganzen Entwicklung ohne hohe Investitionen gegeben.

Der Prototyp wird hierbei als ein Arbeitsmodell verstanden, das nur einige Eigenschaften des zu entwickelnden Systems unterstützt. Als wesentlich wird angesehen, daß schon frühe Versionen die Probleme am Mensch-Maschine-Interface behandeln. Spätere Versionen können dann die Auswirkungen wesentlicher Entwurfsentscheidungen untersuchen.

Die Prototypentwicklung kann unter zwei Aspekten betrieben werden: Weiterverwendung des Prototypen zur Erstellung des endgültigen Softwaresystems oder Schaffung eines vollständig neuen Systems, das auf den gewonnenen Erkenntnissen beruht.

"Rapid prototyping" beschreitet den zweiten Weg. Es ist deshalb nicht erforderlich, bei der Entwicklung des Prototyps auf eine qualitativ hochwertige Software zu achten. Das entstehende Modell dient lediglich zwei Zielen: der endgültigen Bestimmung der Benutzeranforderungen und der Erstellung eines besseren Entwurfs. Dabei bietet es wertvolle Rückkopplung bezogen auf die echten Bedürfnisse des Benutzers. Es ist jedoch Disziplin erforderlich, um nicht den vorhandenen Prototypen als Grundlage der weiteren Entwicklung zu verwenden (code first and design later). Zur besseren Unterstützung dieser Evoluierungstechnik werden zur Zeit Sprachen entwickelt. Diese Arbeiten befinden sich jedoch noch im konzeptionellen Bereich.

Dieser Ansatz besteht darin, daß man die Softwarequalitätsfaktoren, die man als wesentlich erachtet, je Phase auswählt. So ist zum Beispiel die Portabilität für das Dokument der Requirementphase nicht wesentlich, da man hier nur das "Was" eines Systems und nicht das "Wie" beschreibt. Hingegen könnte sie für die Erstellung des Softwaresystems wichtig sein, wenn das System auf mehreren DV-Anlagen unterschiedlicher Art genutzt werden soll. Nach der Auswahl der entsprechenden Qualitätsfaktoren werden die anzuwendenden Qualitätskriterien festgelegt. Die die Metrik festlegenden Elemente werden im nächsten Schritt bestimmt. Die Wichtung der Qualitätselemente bedarf einer eingehenden Betrachtung.

Damit ist das vollständige Metriksystem erstellt. Nach dieser Vorarbeit kann jetzt mit der Auswertung der einzelnen Produkte begonnen werden. Gemäß der festgelegten Elemente werden die entsprechenden Berechnungen durchgeführt. Die Methode der Software Quality Metrics kommt zwar der anfangs aufgestellten Forderung an nächsten, eine Zahl zwischen 0 und 1 zu bestimmen, aber 1 bedeutet lediglich, daß die Erfüllung der dem Metriksystem zugrunde gelegten Elemente erreicht wurde. Nicht betrachtete Elemente können das Qualitätsniveau völlig anders aussehen lassen.

Der kurze, nur skizzenhafte Überblick sollte aufzeigen, daß die Qualitätssicherung im Bereich der Softwareerstellung erst in den Kinderschuhen steckt. Umso wichtiger ist es, erste Erfahrungen auf diesem Gebiet zu machen und die festgestellten Ergebnisse auszutauschen.

Literaturstellen:

H. Balzert

Quantitative Ansätze zur Bestimmung der Komplexität von Software-Systemen in: W. Brauer (Editor): GI- 11. Jahrestagung Springer Verlag, Informatik-Fachberichte 50, 1981

E. Bersoff et al

Software Configuration Management - An Investment in Product Integrity Prentice Hall

F. Buckley

A Standard for Software Quality Assurance Plans Computer, August 1979, Seite 43 - 50

Deutsche Gesellschaft für Qualität

Organisation der Qualitatssicherung in Unternehmen Beuth-Vertrieb GmbH

J. L. Elshoff

The Influence of Structured Programming on PL/ Programming Profiles ECE, Trans. on Se, Okt. 1977, S. 364 ff.

M. Fagan

Design and Code Inspections to Reduce Errors in Programm Development IBM Systems Yournal Vol.15, No.3, 1976

Ch. Floyd

A Process-Oriented Approach to Software Development in: Systems Architecture, Proc. of the 6th ACM European Regional Conf., 1981

M. H. Halstead

Elements of Software Science Elsevier, North Holland, 1977, NY

H. Keutgen

Eine Metrik zur Bewertung der Modularisierung in: W. Brauer (Editor): GI- 11. Jahrestag, Springer Verlag, Informatik-Fachberichte 50, 1981

Management Enzyklopädie

Das Managementwissen unserer Zeit Fischer Taschenbuch Verlag, vmi

T. J. McCabe

A Complexity Measure ECE Trans. on SE, Dec. 1976

H. D. Mills

Software Engineering Education Proc. of ECE Vol 69, September 1980

C.E. Murine

Applying Software Quality Metrics in the Requirements Analysis Phase of a Distribuve System Softech Internal Paper, 1979

G. J. Myers

The Art of Software Testing John Wiley & Sons, NY

L J. Peters Software

Design: Methods & Techniques Yourdon Press, 1981, NY

RADC

Quality Factors Methodology RADC-TR-77-369 Vol I-III, revised 1979

B. Schneidermann

Software Psychology Human Factors in Computer and Information Systems Wintrop Computer Systems Series, Cambridge, Mass.

T.A. Standisk

ARCTURUS - An Advanced Highly-Integrated Programming Environment in: H. Hünk (Editor), Software-Engineering Environments, North Holland, 1981

U. Voges

Quantifizierung der Qualitat von Software in: W. Bauer (Editor), GI-II. Jahrestagung Springer-Verlag, Informatik-Tachberichte 50, 1981

R.R. Willis et al

Computer Aided Design of Software Systems 4. ICSE, München 1979

Ed Yourdon

Structured Walkthrough Yourdon Press, NY, 1978