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.

29.09.1995

Softwarequalitaet/ISO 9000 ist kein Garant fuer Produktqualitaet Qualitaetsmodelle sind in der Software-Entwicklung ein Muss

Wird Softwarequalitaet fuer Standardprodukte oder individuelle Loesungen gefordert, so sind in der Regel zuvor festgelegte oder erwartete Eigenschaften gemeint. Die Forderungen bestimmen den Entwicklungsprozess und muessen permanent ueberwacht werden. Dieter Burgartz* stellt ein Qualitaetsmodell vor, das Mitarbeitern in Softwareprojekten als Grundlage fuer die Auswahl geeigneter Qualitaetsmerkmale dienen soll.

Mit der wachsenden Bedeutung der internationalen Normen nach DIN ISO 9000 ist der Begriff der Qualitaet auch in der Software- Entwicklung neu belebt worden. Ein Indiz dafuer sind nicht zuletzt die steigenden Zahlen der System- und Softwarehaeuser, die ein Qualitaets-Managementsystem nach DIN 9001 aufbauen, betreiben und zertifizieren lassen. Der Trend ist erfreulich, darf jedoch ueber folgendes nicht hinwegtaeuschen: Ein noch so gut funktionierendes Qualitaets-Managementsystem ist noch kein Garant dafuer, dass die Qualitaetsforderungen an beispielsweise eine kundenspezifische Software auch tatsaechlich erreicht werden. Ein Qualitaets- Managementsystem stellt lediglich sicher, dass konstruktive, analytische und administrative Massnahmen zum Qualitaets-Management geplant und gelenkt sowie die vorgesehenen Qualitaetspruefungen durchgefuehrt und dokumentiert werden.

Qualitaetsmerkmale sind festzulegen

Ein Qualitaets-Managementsystem nach DIN 9001 ist daher kein Ersatz und keine Alternative zu konkreten Qualitaetsforderungen an eine Software. Diese muessen sich aus dem jeweiligen Entwicklungsauftrag ergeben und werden bei Bedarf durch weitere Forderungen der Software-Entwickler ergaenzt. Dazu muessen konkrete Qualitaetsmerkmale fuer das Softwareprodukt festgelegt werden, die mit Qualitaetsmassen und den eigentlichen Qualitaetsforderungen versehen sind.

Als Qualitaetsmerkmal kann beispielsweise die Antwortzeit fuer eine Online-Transaktion oder auch die Widerspruchsfreiheit zwischen Software und Dokumentation hergenommen werden. Das Qualitaetsmass waere dann die Masseinheit, mit der die Einhaltung des Qualitaetsmerkmals beurteilt wird: beispielsweise die fuer eine Online-Transaktion benoetigten Sekunden oder der Grad der Vollstaendigkeit einer Dokumentation. Als Qualitaetsforderung ist schliesslich die Vorgabe des Anwenders oder Projektteams zu bezeichnen; die Transaktion soll in 95 Prozent aller Faelle nicht mehr als drei Sekunden dauern, oder: Die Qualitaet einer Dokumentation muss auf einer Skala von 0 (Dokumentation liegt unvollstaendig oder gar nicht vor) bis 5 (sie liegt vollstaendig vor) mindestens den Wert 4 (weitgehend gegeben) erreichen.

In manchen Faellen gelingt es, sich auf Qualitaetsmasse abzustuetzen, die sich als Zahlenwert direkt oder mittelbar aus einer Messung oder Beobachtung ergeben. Meistens stehen jedoch keine direkten Messzahlen oder -methoden zur Verfuegung. Hier muss man ueber Audits, Reviews, Beobachtungen, Abschaetzungen oder Vorhersagen zu einer Einschaetzung des Erfuellungsgrades eines Qualitaetsmerkmals kommen und diesen - wie im Beispiel der Dokumentation geschehen - auf numerische Hilfsgroessen abbilden.

Da hierbei eine gewisse Subjektivitaet in der Beurteilung nicht ausgeschlossen werden kann, sollte ueber moeglichst exakte Prueffragen oder Checklisten zum Qualitaetsmerkmal das zugeordnete Qualitaetsmass "objektiviert" werden. Aussagefaehige Qualitaetsforderungen sollten Kriterien, wie Eindeutigkeit, Messbarkeit, Objektivitaet, Reproduzierbarkeit, Unabhaengigkeit oder Gewichtung der Bedeutung erfuellen.

Eindeutigkeit, Messbarkeit und Objektivitaet sind, wie bereits oben dargelegt, in vielen Faellen nur bedingt erreichbar. Die Reproduzierbarkeit erfordert, dass das gewaehlte Verfahren zur Ermittlung und Bewertung eines Qualitaetsmerkmals wiederholbar ist und dabei die gleichen Ergebnisse wie vorher erbringt. Dieses Kriterium ist natuerlich am ehesten zu erreichen, wenn maschinell gestuetzte Verfahren angewendet werden (zum Beispiel ein Programm zur Ermittlung der Verhaeltniszahl zwischen Kommentarzeilen und Programmzeilen in einem Modul).

Das Kriterium der Unabhaengigkeit bezieht sich auf den Sachverhalt, dass zwei Qualitaetsmerkmale zueinander indifferent, konkurrierend oder verstaerkend sein koennen. Indifferent sind beispielsweise die Qualitaetsmerkmale Funktionsabdeckung und Uebertragbarkeit, die keine Wechselwirkung miteinander haben. Soll eine Software besonders zuverlaessig sein, verschlechtert sich im allgemeinen ihre Effizienz bezueglich Zeitverhalten und Speicherbedarf. Das bedeutet: Zuverlaessigkeit und Effizienz sind konkurrierende Merkmale. Eine gegenseitig verstaerkende Wirkung ist beispielsweise moeglich, wenn als Qualitaetsmerkmale Robustheit und Korrektheit herangezogen werden.

Die verschiedenen Qualitaetsforderungen an ein Produkt haben nicht alle die gleiche Bedeutung fuer den Kunden. Es empfiehlt sich, sie untereinander zu gewichten, um zu einer aussagefaehigen Gesamtbeurteilung zu kommen. Ausnahmen bilden sogenannte K.O.- Kriterien. Werden sie nicht erfuellt, muss die Software abgelehnt werden. Die relative Gewichtung von Qualitaetsforderungen kann auch dazu fuehren, dass Forderungen mit geringem Einfluss auf die Gesamtbewertung ganz weggelassen werden. Das gilt erst recht, wenn die Ermittlung der jeweiligen Auspraegung sehr aufwendig oder von hoher Subjektivitaet ist.

Die bisher aufgefuehrten Beispiele umfassen ausschliesslich Qualitaetsmerkmale, die das eigentliche Softwareprodukt im Zwischen- oder Endzustand betreffen. Ebenfalls von grosser Bedeutung sind jedoch die Eigenschaften, die Auskunft ueber den Prozess der Software-Entwicklung geben. Denn wenn die Taetigkeiten des Konzipierens, Spezifizierens, Implementierens etc. mit geringer Sorgfalt, unzureichenden Methoden und Werkzeugen oder ohne ausreichende Planung und Kontrolle durchgefuehrt werden, lassen sich die Qualitaetsforderungen an das Produkt nicht erfuellen.

Prozessmerkmale haengen in starkem Masse vom gewaehlten Vorgehensmodell und den eingesetzten Methoden und Werkzeugen der Entwicklung ab. Sie sind nur schwer generalisierbar und werden im weiteren nicht behandelt. Grundsaetzlich lassen sich jedoch mit einem leistungsfaehigen Qualitaets-Managementsystem die Prozessmerkmale in der Regel ausreichend sicherstellen, so dass man in den meisten Faellen auf die direkte Festlegung derartiger Forderungen verzichten wird. Treten bei der Ueberpruefung der Produktforderungen jedoch wiederholt gravierende Maengel auf, so sollte dies Anlass fuer eine kritische Ueberpruefung der Prozessablaeufe in der Software-Entwicklung sein.

Um den unscharfen Begriff der Softwarequalitaet greifbar zu machen, spezifiziert man ein Qualitaetsmodell durch uebergeordnete Qualitaetsmerkmale und deren mehrstufiges Zerlegen in Unterbegriffe bis hin zu elementaren Merkmalen (siehe Abbildung 1). Den Merkmalen der untersten Ebene werden Qualitaetsmasse (Kenngroessen) mit einer Dimension zugeordnet, die durch Messungen, Reviews, Audits, Beobachtungen etc. ermittelbar sind. Fuer eine Anwendung gestaltet sich dann eine Qualitaetsforderung als eine konkrete Wertauspraegung (Einzelwert, Bereichsangaben, Intervalle) zu einem Qualitaetsmerkmal.

Eine grundlegende Problematik liegt darin, dass die hierarchische Zerlegung der Qualitaetsmerkmale in Tiefe und Breite ueberschaubar und handhabbar sein muss. Zuviele Wiederholungen einer Produkteigenschaft in mehreren Qualitaetsmerkmalen sind moeglichst zu vermeiden. Zu bevorzugen sind indifferente Qualitaetsmerkmale; die Zahl derer mit konkurrierendem Charakter ist dagegen klein zu halten. In der Praxis wird man meist nicht mehr als vier bis sechs Qualitaetsmerkmale auf der ersten Ebene und eine Strukturierungstiefe von hoechstens drei bis vier Ebenen waehlen.

Was ist fuer die Qualitaet wichtig?

Spaetestens bei der relativen Gewichtung der Qualitaetsforderungen untereinander wird sich zeigen, dass Merkmale mit geringem Einfluss auf die Gesamtqualitaet haeufig ganz weggelassen werden koennen. Dies sollte auch fuer Eigenschaften gelten, die sich einer systematischen oder objektiven (objektivierbaren) Erfassung und Beurteilung entziehen. Nach dem Grundsatz "weniger ist mehr" sind letztlich die Qualitaetseigenschaften entscheidend, die fuer das jeweilige Softwareprodukt wirklich bedeutsam sind. Nur von geringem Wert sind dagegen Qualitaetsforderungen, die unscharf formuliert sind oder deren Erfuellung mit einem weiten Interpretationsspielraum bewertbar ist.

Typische Beispiele, die man in Kundenauftraegen immer wieder findet, sind globale Forderungen wie "das System muss leicht erlern- und bedienbar sein" oder "die Software muss portabel sein". Forderungen auf derartigem Spezifikationsniveau sind fuer die Entwickler nicht konkret umsetzbar und fuehren spaetestens bei den Abnahmetests zu Diskussionen mit dem Auftraggeber.

Qualitaetsforderungen werden als numerische Werte (Einzelwerte, Bereichsangaben etc.), als Ja-Nein-Aussage oder in Form von Umschreibungen wie "gut", "maessig" oder "nicht ausreichend" formuliert. Um die erreichte Auspraegung eines Qualitaetsmerkmals mit der gestellten Qualitaetsforderung zu vergleichen, sind die moeglichen Dimensionsbereiche des Qualitaetsmasses auf ein einheitliches Erfuellungsraster abzubilden (siehe Abbildung 2).

Dies kann etwa eine Skala von null bis fuenf sein, wobei null der schlechteste und fuenf der beste Wert ist. Fuer Qualitaetsmerkmale, deren Auspraegung ueber Reviews, Beobachten, Abschaetzen, Vorhersagen etc. ermittelt werden, wird man ein solches Erfuellungsraster haeufig direkt als Qualitaetsmass festlegen. Sind Qualitaetsforderungen von unterschiedlicher Bedeutung fuer eine Software, so fuehrt man in der Regel eine Gewichtung der Qualitaetsmerkmale durch.

Ein differenziertes Verfahren ist es, die Qualitaetsforderungen in Prioritaetenklassen einzuteilen, und fuer jede eine Mindesterfuellung vorzugeben. Ausgenommen bleiben natuerlich die K.o.-Kriterien, die bei Nichterfuellung zu einer Rueckweisung des Produktes fuehren. Ein Beispiel fuer eine zweistufige Gewichtung enthaelt die Abbildung 3.

Qualitaetsmerkmale unterschiedlich gewichtet

Ein Qualitaetsmodell, das aus 16 Hauptmerkmalen besteht, ist in Abbildung 4 zu sehen. Die dort aufgelisteten Merkmale sind in die drei Kategorien Produktbetrieb, -revision und -veraenderung eingeteilt, die in Abhaengigkeit vom Anwendungsfall unterschiedlich zu gewichten sind. Beispielsweise lassen sich die neun Merkmale fuer den Produktbetrieb mit 60 Prozent, die drei Merkmale fuer die Produktrevision mit 30 Prozent und die vier Merkmale der Produktveraenderung mit zehn Prozent klassifizieren.

Die Qualitaetsmerkmale fuer den Produktbetrieb bestimmen die Gebrauchstauglichkeit der Software (einschliesslich Dokumentation) in den Phasen Einfuehrung und Betrieb. Zur Produktrevision werden alle Merkmale gezaehlt, die sich mit dem Erkennen und Beheben von Fehlern und Maengeln befassen, wobei der funktionale Rahmen der Software unveraendert bleibt. Qualitaetsmerkmale, die die funktionale Aenderbarkeit und Erweiterbarkeit, die Integrationsfaehigkeit mit anderen Produkten und die Uebertragbarkeit auf andere Systemumgebungen umfassen, werden der Kategorie Produktveraenderung zugeordnet.

Hauptmerkmale sind weiter zu untergliedern

Diese oberste Ebene der Qualitaetsmerkmale laesst sich natuerlich noch nicht operationalisieren. Die jeweils relevanten Hauptmerkmale muessen in weitere Untermerkmale gegliedert werden, fuer die Masse vorgebbar und die erreichten Erfuellungen ermittelbar sind.

Wie bereits dargelegt, wird man fuer eine Software-Entwicklung meist nur einige Hauptmerkmale festlegen und nach entsprechender Untergliederung als Qualitaetsforderungen formulieren. Dabei ist es hilfreich, bereits ueber ein generisches Qualitaetsmodell zu verfuegen, dem die geeigneten Merkmale, Qualitaetsmasse und entsprechenden Methoden und Werkzeuge zur Erfassung, Dokumentation und Beurteilung entnommen werden koennen. Wer darueber nicht verfuegt, wird aus Kostengruenden und wegen der Gefahr der fehlenden Praxisnaehe den Aufwand fuer die Erstellung eines umfassendes Qualitaetsmodells scheuen.

Sinnvoller ist es hier, sich zunaechst auf einige wenige, jedoch haeufig benoetigte Qualitaetsmerkmale zu beschraenken und diese in anstehenden Projekten zu erproben. Denn ergaenzend zu den oben angefuehrten Kriterien (Eindeutigkeit, Messbarkeit, Objektivitaet, Reproduzierbarkeit, Unabhaengigkeit und Gewichtbarkeit), die ein Qualitaetsmerkmal erfuellen sollte, gilt auch, dass die Verfahren zur Ermittlung seiner Auspraegung praktikabel und wirtschaftlich sein muessen. Sie sollten von den Entwicklern und Qualitaetssicherern akzeptiert werden.

Die Praktikabilitaet spricht die Aspekte Aussagefaehigkeit und Handhabbarkeit an. Die Wirtschaftlichkeitsbetrachtung beurteilt die Verhaeltnismaessigkeit der Kosten zum Nutzen beziehungsweise den potentiellen Folgekosten, sollten die Qualitaetsforderungen nicht erfuellt werden. Und die Akzeptanz ist ein wichtiger Aspekt, der ohnehin bei allen Massnahmen des Qualitaets-Managements zu beachten ist.

Kriterien richten sich nach dem Anwendungsbereich

Die Auswahl von prioren Qualitaetsmerkmalen richtet sich nach den Anwendungsbereichen. Soll eine Realtime-Anwendung zur Steuerung einer Anlage fuer die Produktion gefaehrlicher Stoffe entwickelt werden, liegen die Schwerpunkte naturgemaess auf einer zuverlaessigen, robusten und effizienten Software mit hoher Verfuegbarkeit. Treten in der Anlagensteuerung Stoerungen auf, entsteht die Gefahr von wirtschaftlichem Schaden durch Produktionsausfall, moeglicherweise sogar die der Gefaehrdung von Menschen und Guetern.

Anders verhaelt es sich bei der Beurteilung eine "Prototyp- Projekts", bei dem etwa ein neues Datenbank-Managementsystem (DBMS) beurteilt werden soll, das auf unterschiedlichen Hardwareplattformen eingesetzt werden kann. Hier stehen die Aspekte Portabilitaet des DBMS und Wiederverwendbarkeit von Anwendungskomponenten klar im Vordergrund.

Benutzbarkeit geniesst hoechste Prioritaet, wenn beispielsweise ein "Vertriebsinformationssystem" realisiert werden soll, das Vertriebsmitarbeiter ueber Artikel, Preise, Kunden, Angebote und Auftraege informiert. Zwar ist Benutzbarkeit auch beim Prototyp- Projekt gefordert, doch es bestehen erhebliche Unterschiede. Waehrend im Vertriebsinformations-System der gelegentliche oder staendige Benutzer ein Endanwender ohne tiefere DV-Kenntnisse ist, sind die Benutzer des DBMS Software-Experten mit umfangreicher Ausbildung. Die detaillierten Qualitaetsforderungen fuer den Oberbegriff der Benutzbarkeit sind in diesen beiden Faellen sehr verschieden.

Die Beispiele zeigen, dass globale Qualitaetsforderungen wenig helfen. Man muss sich schon die Muehe machen, die fuer die jeweilige Software typischen und aussagefaehigen Merkmale zu spezifizieren. Nach dem Grundsatz "You cant control what you cant measure" sollte zunaechst mit solchen Merkmalen begonnen werden, die mess- und quantifizierbar sind. Wo dies nicht moeglich ist (und leider gilt dies fuer die meisten Qualitaetsmerkmale), kann man ueber vorgegebene Prueffragen, Checklisten, Musterbeispiele etc. eine Vereinheitlichung, Vergleichbarkeit und Objektivierung erreichen.

Messungen sollten automatisiert werden

Messungen sollten - soweit moeglich - durch Verwendung von Pruefprogrammen, Pruefgeraeten etc. automatisiert werden. Geringerer Aufwand, weniger Fehler und Reproduzierbarkeit sind die Vorteile. Unternehmen, die regelmaessig groessere Software-Entwicklungen durchfuehren, werden die Qualitaetsaufzeichnungen in Datenbanken ablegen und bei neuen Entwicklungen zu Rate ziehen. Hierzu gehoeren etwa Aufzeichnungen, die Auskunft ueber Fehler (wann wurden Fehler erzeugt, erkannt und behoben?) und stoeranfaellige Komponenten geben.

Da Softwarefehler, die bis zur Auslieferung an den Kunden nicht entdeckt werden, die schwerwiegendste Qualitaetsminderung darstellen, sind Verfahren zu erarbeiten, die eine Prognose von potentiell besonders stoeranfaelligen Softwarekomponenten erlauben. Je frueher man mit dieser Untersuchung beginnt, um so weniger Zeit und Kosten fallen an, um diese Kandidaten einer speziellen Analyse zu unterziehen.

Die Probleme sind keineswegs geloest

Dies ist ein schwieriges Unterfangen, das in der Informatik noch nicht zufriedenstellend beherrscht wird. Einen durchaus brauchbaren Ansatz hierzu liefert eine Pareto-Analyse, die von dem Ansatz ausgeht, dass "wenige Komponenten fuer viele Fehler" verantwortlich sind (80-20-Regel).

Die Problematik der Qualitaetseigenschaften und -messungen ist trotz umfangreicher Literatur noch nicht ausreichend geloest. Zudem besteht die Gefahr, dass bei der aktuellen Diskussion um Qualitaets- Managementsysteme und Zertifizierung nach DIN ISO 9000 das eigentliche Problem vernachlaessigt wird. Die Frage lautet nicht "Qualitaet oder Zertifikat?" sondern "Zertifikat ja, aber wie definiere und messe ich Qualitaet?".

Tabelle 3: Hauptmerkmale eines Qualitaetsmodells

Produktbetrieb

01 Funktionsabdeckung: Vollstaendigkeit der Funktionen eines Produkts in bezug auf die Forderungen.

02 Widerspruchsfreiheit: Ausmass, in welchem sich Funktionen sowie die Dokumentation eines Produktes widersprechen.

03 Korrektheit: Ausmass, mit welchem ein Produkt seine Spezifikationen erfuellt.

04 Zuverlaessigkeit: Mass fuer die Erwartung, dass ein Produkt seine spezifizierten Funktionen waehrend der Anwendungsdauer erfuellt.

05 Integritaet: Ausmass, in welchem unberechtigte Zugriffe sowie unerwuenscht Veraenderungen und Zerstoerungen verhindert werden.

06 Robustheit: Ausmass, in welchem ein Produkt auch bei Verletzung der festgelegten Betriebs- und Benutzungsvoraussetzungen seine Funktionalitaet bewahrt.

07 Effizienz: Umfang an DV-Ressourcen (zum Beispiel CPU-Zeit, externer/interner Speicherbedarf, Antwortzeitverhalten), die ein Produkt zur Erfuellung seiner Funktionen benoetigt.

08 Benutzbarkeit: Aufwand zum Erlernen und Bedienen eines Produkts.

09 Verfuegbarkeit: Ausmass, in welchem ein Produkt dem Benutzer zur Verfuegung steht (im Sinne von Ausfallsicherheit).

Produktrevision

10 Testbarkeit: Aufwand fuer das Testen eines Produkts.

11 Korrigierbarkeit: Aufwand zur Lokalisierung und Behebung von Fehlern im Produkt.

12 Aenderbarkeit: Aufwand zur Modifikation eines Produkts im bestehenden funktionalen Rahmen.

Produktveraenderung

13 Erweiterbarkeit: Eigenschaft eines Produkts, um neue Funktionen erweiterbar zu sein.

14 Verknuepfbarkeit: Aufwand zur Verknuepfung eines Produkts mit einem anderen.

15 Uebertragbarkeit: Aufwand zur Uebertragung eines Produkts auf eine andere Hard-/Software-Umgebung.

16 Wiederverwendbarkeit: Aufwand zur Verwendung eines Produkts in einer anderen Anwendung.

*Dieter Burgartz ist Fachautor und IT-Berater in Wesseling.