Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

11.05.1984

QUALITÄTSSICHERUNG - Sisyphusarbeit mit Erfolgschance

Noch immer ist die Unsitte, Qualität in Softwareprodukte eher hineinzutesten als hineinzuentwickeln, weit verbreitet. Dabei ist es offensichtlich, daß sich bereits die Vorgehen und einschränkenden Umgebungseinflüsse auf die Güte des Gesamtproduktes auswirken.

Die Möglichkeiten, bei der Erstellung von Softwareprogrammen Fehler zu machen, ziehen sich durch den gesamten Entwicklungsprozeß, können aber andererseits auch auf einen Nenner gebracht werden. Die Verletzung grundlegender Regeln, die theoretisch hinlänglich bekannt sind, führt in der Praxis häufig zu einem Vorgehen, das ins Chaos mündet - und nicht nur Unzufriedenheit, sondern auch erhöhte Kosten mit sich bringt.

Formalisiertes Vorgehen schon in der ersten Phase des Prozesses erfordert aber auch eine genaue Analyse der Anforderungen an das Produkt durch den Auftraggeber. Wie der Autor in seinem Beitrag feststellt, wird hier vielfach mit einer nicht zu vertretenden Unbekümmertheit vorgegangen. Verschiedene theoretische Ansätze, die zum größten Teil aus den Vereinigten Staaten stammen, sollen Hemmnisse auf dem Weg zu wirklich ausgereifter Software abbauen und der Qualitätssicherung im Bereich der Softwareerstellung aus den Kinderschuhen helfen. (Teil 1 )

Grundsätzliche Überlegungen zum Management von DV-Projekten werden - nicht nur in Spezialistenkreisen - mehr und mehr diskutiert. Dieser Beitrag konfrontiert einzelne Aspekte der Qualitätssicherung mit den Erfahrungen eines System- und Softwarehauses.

Der erste Teil legt kurz einige Begriffsbestimmungen fest, während der zweite Teil die Qualitätssicherung im Rahmen begleitender Maßnahmen einordnet.

Die Deutsche Gesellschaft für Qualität verwendet folgende Definition:

Qualität ist die Gesamtheit der Merkmale, die eine Ware oder eine Dienstleistung zur Erfüllung vorgegebener Forderungen geeignet macht. Die vorgegebenen Forderungen ergeben sich im allgemeinen aus dem Verwendungszweck.

Dabei werden sowohl objektive als auch subjektive Einschätzungen betrachtet. Um die Forderungen des Abnehmers zu realisieren, gliedert man das Gesamtgebiet "Qualität" im Zusammenhang mit Softwareprojekten in Qualität des Pflichtenheftes, des Entwurfes, der Implementierung, des Produktes und Qualität der Wartung.

Mit der so festgelegten Definition sind die nicht spezifischen, qualitätsrelevanten Anforderungen eindeutig bestimmt. Im allgemeinen folgt daraus, daß der Produktersteller die Vorstellungen des Benutzers genau ermitteln, das entsprechende Produkt nach wirtschaftlichen Aspekten fertigen und für die Nutzungszeit adäquat pflegen sowie weiterentwickeln muß.

Qualitätssicherung wird vom amerikanischen Department of Defense wie folgt definiert:

Qualitätssicherung ist ein geplantes und systematisches Modell für alle Tätigkeiten, die erforderlich sind, um angemessenes Vertrauen zu erreichen, daß der Gegenstand oder das Produkt den aufgestellten technischen Anforderungen entspricht.

Es ist deshalb erforderlich, daß Qualitätssicherungssysteme folgende Anforderungen abdecken:

- Erfüllung der vorgegebenen Kundenforderungen,

- Übereinstimmung mit Normen und Standards,

- Erhöhung der Gesamtwirtschaftlichkeit,

- transparente Dokumentation,

- Überprüfung der Qualitätssicherungsmaßnahmen und gegebenenfalls Korrekturmaßnahmen.

Der Begriff "Software" wird zwar im deutschsprachigen Raum sehr häufig benutzt, aber es gibt bisher keine DIN-Norm, die eine einheitliche Verwendung vorschreibt.

Software ist eine Menge von Programmen zusammen mit begleitenden Dokumenten, die für ihre Nutzung notwendig und hilfreich sind.

Diese Definition schließt auf den ersten Blick die Entwicklungsdokumentation aus. Ein Softwareprodukt wird aber erst wartbar durch die Gesamtheit der systembegleitenden Dokumentation, die damit Bestandteil der Software ist. Dieser Softwarebegriff hat sich in der amerikanischen Literatur immer stärker durchgesetzt.

Neben dem eigentlichen Produzieren von Software haben sich in den letzten Jahren vier wesentliche Disziplinen des Software-Engineering in Großprojekten der amerikanischen Raumfahrt und Verteidigung entwickelt, nämlich QA Quality Assurance (Qualitätssicherung), V&V Verification and Validation (Zielkontrolle), T&E Test and Evaluation (Systemtestdurchführung) und CM Configuration Management (Änderungskontrolle).

Die Disziplinen neben der QA sollen hier kurz charakterisiert werden.

V&V - oft auch als IV&V (independant V&V) bezeichnet - hat die Aufgabe, unabhängig vom Entwicklungsteam die technische Lösung zu evaluieren und jeden Entwicklungsprozeß zu kontrollieren. Die amerikanische Literatur versteht dabei unter Verifikation die Überprüfung, die die richtige Ableitung einer Entwurfsstufe i+1 aus der Stufe i zum Gegenstand hat, und unter Validation die Kontrolle, ob die Entwurfsstufe i+ 1 noch zu den ursprünglichen Anforderungen an das System konsistent ist.

Das T&E-Team, das unabhängig von dem Entwicklungsteam arbeitet, definiert und entwickelt eine möglichst lebensechte Testumgebung für den Systemtest. Für dieses Testszenarium erstellt es Pläne und führt die Checks danach durch. Die Auswertung wird in einem entsprechenden Bericht zusammengefaßt.

CM ist eine Tätigkeit, die nicht nur den Entwicklungsprozeß, sondern auch den sich anschließenden Wartungszeitraum umfaßt. Das Einbringen von Änderungen in die festgelegten Anforderungen ist eines der wesentlichen Probleme des Projektmanagements während der gesamten Software-Lebensgeschichte. Durch Verwaltung von festgelegten Dokumenten und deren identifizierten Teilen, durch festgelegte Prozeduren für den Änderungsprozeß und durch strikte Regeln zur Verfolgung von Änderungen wird bei CM versucht, die Risiken durch notwendige Modifikationen weitgehend auszuschließen.

Die Aufgaben der vier Disziplinen sind nicht disjunkt, so daß die Vertreter der einzelnen Richtungen jeweils versuchen, den eigenen Aufgabenbereich auf Kosten der anderen zu vergrößern. Dies gilt insbesondere für die Bereiche QA, V&V und CM. Bersoff1 geht in einem Beitrag über CM sogar so weit, die Aufgaben der QA auf das bloße Abprüfen von vorgegebenen Checklisten zu degradieren, während die Aufgaben von V&V vollständig in den Bereich des CM übergehen.

In den folgenden Ausführungen sollen die speziellen Ansätze der V&V-, T&E- und CM-Aktivitäten nicht unterbewertet werden. Da die Sicht eines Softwareerstellers aber im Vordergrund stehen soll, wird die Qualitätssicherung hier als Kontrollinstanz des Entwicklers angesehen die alle Teile der anderen Aktivitäten integriert. Die Trennung beruht wesentlich darauf, daß unterschiedliche, unabhängige Unternehmen vom Auftraggeber mit der Durchführung der Kontrollmechanismen gegen die softwareerstellende Firma beauftragt werden. Der Auftraggeber übernimmt dabei dann die Koordinierung und Wertung der Ergebnisse.

Die Definition der Qualität läßt offen, welche Maße an ein Produkt angelegt werden und ob diese überhaupt quantifizierbar sind. Selbst wenn alle Kriterien, die zur qualitativen Bewertung eines Produktes oder einer Dienstleistung herangezogen werden sollen, quantifizierbar sind, führt die Verteilung von Wichtungen aufgrund verschiedener Anwendungen zu subjektiven Ergebnissen. In aller Regel treten aber bei Qualitätsvergleichen auch nicht quantifizierbare Kriterien (zum Beispiel der Geschmack) auf, so daß man selten eine objektive Wertung fällen kann.

Zum besseren Verständnis sollen zunächst kurz einige Begriffe erläutert werden:

Unter Qualitätsfaktor soll eine wünschenswerte, quantifizierbare Charakteristik eines Softwaresystems verstanden werden.

Die Qualitätskriterien sind die Attribute, die einen Qualitätsfaktor definieren.

Ein Qualitätselement ist ein bestimmtes Maß (gegebenenfalls unter vielen) eines Qualitätskriteriums.

Eine Qualitätsmetrik ist der numerische Wert eines Qualitätselementes oder eines Qualitätskriteriums.

Wenn über Qualität von Software gesprochen wird, fallen jedem Begriffe ein, wie beispielsweise Modularität, Lesbarkeit, Effizienz, Portabilität, Testbarkeit, Benutzbarkeit, Sicherheit, Verständlichkeit, Dokumentation, Entwicklungskosten, Lebensdauer, Wartbarkeit, Komplexität.

Es ist zu überlegen, welche dieser zunächst einleuchtenden Eigenschaften im Sinne der oben genannten Definition wirklich als Qualitätsfaktoren anzusehen sind.

Auszuscheiden sind alle die Begriffe, die die direkten Softwareeigenschaften ansprechen und nicht am Benutzer orientiert sind. Dies sind aus den Beispielen: Modularität, Komplexität. Nicht quantifizierbar und deshalb zu eliminieren sind Begriffe wie Lesbarkeit und Verständlichkeit. Sicherheit ist eine Frage des Umgangs mit Softwaresystemen und deshalb im allgemeinen eine Frage der operationellen Gesamtumgebung. Die Entwicklungskosten sind eine Grundlage zur Bewertung des Managementerfolges und nicht des technischen Erfolges, dem die Qulitätssicherung ausschließlich zu dienen hat. Die Lebensdauer ist eine vom Systemnutzer zu stellende Vorgabe, aus der bestimmte Qualitätsfaktoren abzuleiten sind. Die Dokumentation endlich ist ein integraler Bestandteil der Softwareerstellung und nach Definition "Software" im weiteren Sinne, weshalb sie selbst der Qualitätsbeurteilung unterworfen ist.

Neben den bisher herauskristallisierten Begriffen Effizienz, Portabilität, Testbarkeit, Benutzbarkeit und Wartbarkeit streicht das Rome Air Development Centre (RADC) in einer Studie die folgenden Qualitätsfaktoren heraus Korrektheit, Zuverlässigkeit, Integrität, Kopplungsfähigkeit, Wiederverwendbarkeit und die Flexibilität. Mögliche weitere Faktoren sind Sicherheit, Überlebensfähigkeit, menschliche Faktoren (Bedienbarkeit). Die hier verwendeten Qualitätsfaktoren werden gemäß Tabelle 1 in ihrer Verwendung festgelegt.

Die für eine Softwareentwicklung gesetzten Vorgaben (objektives) bestimmen wesentlich die Faktoren, die von Bedeutung sind. Eine vorn Kunden explizit gewünschte Lösung, die möglichst billig sein soll, beeinflußt alle Qualitätsfaktoren negativ.

Hängen von der Entwicklung Menschenleben ab, so ist insbesondere auf Zuverlässigkeit, Korrektheit und Testbarkeit zu achten. Software mit hoher Lebensdauer muß wartbar, portabel und flexibel sein. Neben diesen Vorgaben haben auch einschränkende Umgebungseinflüsse (policies) Auswirkungen auf die Qualifikatoren. Die Anforderung, "es ist äußerst effiziente Assemblerprogrammierung zu verwenden", hat negative Auswirkungen auf die Faktoren Wartbarkeit, Flexibilität, Portabilität und Testbarkeit, während der Faktor Effizienz deutlich betont wird. Die Forderung nach einer höheren Programmiersprache gemäß definiertem Standard hat entsprechend den umgekehrten Effekt.

Es ist aber offensichtlich, daß sich bereits die Vorgaben und die einschränkenden Umgebungseinflüsse auf die Qualität des Gesamtproduktes auswirken. Daneben ist die Qualität der Entwicklungsprodukte (Pflichtenheft, Systementwurf, Programmentwurf, codiertes System, integriertes System) von entscheidender Bedeutung, da auf dieser Grundlage jeweils der nächste Entwicklungsschritt vollzogen wird. So kann aus einem widersprüchlichen Pflichtenheft zum Beispiel kein widerspruchsfreies System abgeleitet werden; auf der Grundlage einer unsauberen Softwarearchitektur kann kein wartbares System entwickelt werden. Das erste Entwicklungsdokument - das Pflichtenheft - muß alle Anforderungen an das zu realisierende System enthalten. Aufgrund eines ordnungsgemäßen QS-Prozesses werden genau die Anforderungen dieses Grundlagenpapiers im entstehenden System realisiert - nicht mehr und nicht weniger. Die Qualität des Endproduktes ist deshalb nicht ohne die Qualität der Zwischenprodukte zu gewährleisten. Um so erstaunlicher ist es, industrieübliche Praktiken zu beobachten.

Es werden auf der Grundlage einer inkonsistenten, unvollständigen Ausschreibung Festpreisangebote erstellt, wobei manchmal die Erstellung des Pflichtenheftes die erste Aktivität ist. Die Unbekümmertheit mit der Software- und Vertriebsspezialisten an diffizile Problemstellungen herangehen und hochwertige Qualität versprechen, ist dennoch oft äußerst erstaunlich.

Eine kritische Bemerkung verdient auch die Testphase, die zur Zeit nach amerikanischen Erhebungen zirka 50 Prozent der Entwicklungskosten ausmacht. Wie oft sieht man zu nächtlicher Stunde, Programmierer verbissen ihre Programme austesten, die seit Wochen 90 Prozent fertig sind und deren letzter Fehler bereits vor vielen Tagen angeblich behoben wurde. Man könnte noch interpretieren, daß nun die Qualität in die Software hineingetestet wird. In Wirklichkeit geht hier die Saat der Fehler und Sünden in den frühen Phasen zum ersten Male richtig auf. Ein mangelhaftes Pflichtenheft und der Ansatz des "code first, design later", verbunden mit chaotischem Testen, sind allzuoft die Ursache des zu beobachtenden Phänomens.

Nicht zu eliminieren sind auch die Änderungen der funktionalen Anforderungen an das System. Diese sind jedoch nicht der Grund eines oft zu beobachtenden Disasters, sondern die Art und Weise, wie Softwareersteller mit Änderungen allzuoft umgehen, führt zu den katastrophalen Ergebnissen. Da meist keine festen Prozedurvorschriften für das Einbringen von Änderungen existieren, modifiziert ein Programmierer ein paar Statements, weil sein "Freund" - der Kunde - ihm eben auf dem Flur von seinen neuesten Ideen überzeugt hat. Dabei wird weder die funktionale Anforderung im Pflichtenheft modifiziert, noch untersucht, ob die Modifikation zu Inkonsistenzen führen kann. Das unkontrollierte Einbringen - meist von keinem mehr überblickbar - hat zwangsweise eine veraltete Entwicklungsdokumentation und damit ein unwartbares - also qualitativ minderwertiges - Produkt zur Folge.

Dieser kurze Exkurs soll um ein weiteres Element ergänzt werden. Die Dokumentation, die in einem ordentlichen Projekt zum Integrationstest vorliegt, ist in unzählbaren Fällen nie erstellt worden. Der Zeitdruck der Entwickler dient meist als faule Entschuldigung eines schlampigen Arbeitsstils. Noch schlimmer sind die Fälle, wo der Kunde auf Dokumentation verzichtet, weil vermeintlich pfiffige Vertriebsleute damit die Gesamtkosten zu senken beabsichtigen, da ihnen bekannt ist, daß die Programmierer noch Monate nach Projektabschluß muffig damit verbringen, unnützes Papier zu produzieren.

Auf diesem Hintergrund muß man die schüchternen Versuche sehen, mit Qualitätssicherung Ordnung in den "Augiasstallö zu bringen, der mit dem freundlichen Decknamen "Softwarekrise" bezeichnet wurde.

Wie bereits die Definition von Qualitätssicherung festlegt, handelt es sich um ein geplantes und systematisches Modell für bestimmte Tätigkeiten Die Planung zu Beginn des Projektes, das heißt, vor allen technischen Aktivitäten, ist deshalb unabdingbare Voraussetzung für eine effektive Qualitätssicherung. Sie muß die Grundlage für einen systematischen Prüfvorgang darstellen.

Es ist eine vordringliche Aufgabe des Projektleiters, parallel zum Projektabwicklungsplan einen Qualitätssicherungsplan für das von ihm betreute Projekt zu erstellen. In diesem Plan sind die Organisation der Qualitätssicherung, die minimalen Dokumentationsanforderungen, die gültigen Standards und Vereinbarungen, der minimale Umfang der Qualitätskontrolle, das zu verwendende Konfigurationsmanagement und die zum Einsatz kommenden Werkzeuge zu beschreiben.

Einen guten Anhaltspunkt für die Erstellung des Qualitätssicherungsplans ist der 1979 von IEEE auf Empfehlung des "Software Engineering Standards Subcomittee" vorgelegte Standardentwurf. Er leistet Hilfestellung bei der Vorbereitung und inhaltlichen Abfassung von Qualitätssicherungsplänen. Erstellte Pläne können gegen das vorliegende Muster quergeprüft werden. Der Standard wurde besonders für die Entwicklung und Wartung kritischer Software bereitgestellt.

Qualitätssicherungsprogramme beruhen im wesentlichen auf drei Forderungen:

- gesetzliche Haftung (Nachweis der qualitativ hochwertigen Arbeit),

- Kosteneffizienz (Nachweis der Einhaltung der administrativen Projektarbeit),

- Kundenanforderung (Nachweis der Einhaltung der Projektvorgaben).

Deshalb ist ein Qualitätssicherungsplan so zu erstellen, daß er sowohl den Benutzern, den Entwicklern als auch den von der Entwicklung Betroffenen dient.

Da es sich bei der Software im wesentlichen um eine geistige Leistung handelt, muß hier eine andere Form von Qualitätsprüfung stattfinden als im übrigen industriellen Bereich. Die aus den anderen Zweigen der Ingenieurwissenschaften bekannten Verfahren können nicht angewandt werden.

Für Softwareprojekte wurden folgende Methoden und Verfahren entwickelt:

- Einsatz von Werkzeugen des Software-Engineering,

- Standards und Vereinbarungen,

- Qualitätskontrolle,

- Testmanagement,

- Konfigurationsmanagement.

Als Auszug aus dem IEEE-Papier werden hier zu den wesentlichen Punkten des QS-Planes noch skizzenhafte Bemerkungen gemacht.

Jedes Projekt legt die zu verwendenden Standards und Vereinbarungen fest. Außerdem ist anzugeben, wie die Einhaltung der Vorschriften gewährleistet wird und überprüft werden kann. Die behandelten Themen sollen alle technischen Aktivitäten von der Pflichtenhefterstellung bis zum Systemtest umfassen. Als Mindestumfang sind Dokumentationsstandards (Umfang und Form), Standards zur logischen Struktur, Programmierungsstandards, und Kommentierungsstandards anzusehen.

Das Konfigurationsmanagement ist in Großsystemen eine sehr wichtige Aufgabenstellung. Zur Generierung einer bestimmten Systemkonfiguration ist ein Bibliotheksystem mit Versionshaltung dringend erforderlich. Um die Pflege und Haltung von kontrollierten Versionen zu ermöglichen, ist eine Beschreibung der verwendeten Methoden und Verfahren sowie deren Möglichkeiten zu erstellen.

Für die kontrollierte Änderung eines Softwaresystems müssen die üblichen Verfahren und Vorgehensweisen beschrieben werden, die eingeschlagen werden sollen, um über Softwareprobleme Bericht zu erstatten, sie zum verfolgen und zu lösen. Dazu sind die Methoden festzulegen, die verwendet werden, um die betroffenen Softwareteile festzustellen, Änderungen zu kontrollieren sowie zu implementieren und den Änderungsstand festzuhalten. Darüber hinaus müssen die organisatorischen Verantwortlichkeiten ausgewiesen werden, die sich mit der Implementierung von Änderungen befassen.

(wird fortgesetzt)

*Hans Keutgen ist Leiter der GEI-Niederlassung in Aachen.