Qualitätssicherung (QS) ist als Schlagwort in aller Munde. Doch nur darüber zu reden, macht Software noch nicht besser. Aber gerade an der konsequenten Durchführung von QS-Maßnahmen fehlt es meist.
Betroffene nach den Gründen für zwar geplante und begonnene, dann jedoch still und leise vergessenen QS-Maßnahmen befragt, geben überwiegend als Begründung an, daß im Projektverlauf die Zeit zu knapp oder das Ganze zu teuer wurde. Der erwartete Erfolg habe sich nicht eingestellt, lautet eine weitere Feststellung oder die Mitarbeiter haben sich dagegen gewehrt.
Daß diese und ähnliche Argumente nicht stichhaltig sind, sollen die nachfolgenden Erläuterungen untermauern.
Wie die Erfahrung nämlich zeigt, kann man mit relativ geringem Aufwand erfolgreiche Qualitätssicherung vornehmen, wenn die Aufgabe systematisch und konsequent verfolgt wird.
Zur Erläuterung möchten wir eine grobe Darstellung unseres QS-Verständnisses geben. In der Literatur finden sich mehrere Dutzend Software-Qualitätsmerkmale, relevant für ein Softwaresystem ist in den meisten Fällen allerdings nur eine geringe Auswahl aus diesem Spektrum. Trotz der großen Anzahl von Software-Qualitätsmerkmalen - es sind etwa 80 zu zählen - sind sie Qualitätsaspekten der funktionalen Sicherheit und der realisierungstechnischen Qualität zuordnen.
Die funktionale Qualität bringt zum Ausdruck, wie gut der Anwender durch das Softwaresystem bedient wird, etwa hinsichtlich Problemlösung, Benutzerfreundlichkeit, Antwortzeitverhalten, Datensicherheit, etc.
Die realisierungstechnische Qualität drückt die Güte hinsichtlich der Modifizierbarkeit des Systems aus. Typische realisierungstechnische Software-Qualitätsmerkmale sind Anpassungsfähigkeit, Wartbarkeit oder Portierbarkeit.
Software-Qualitätssicherung ist die Summe aller Maßnahmen zur Erhöhung der Qualität von Softwaresystemen. Die konsequente Einhaltung der drei Schritte: Planung, Durchführung und Kontrolle durch alle Phasen des Software-Lebenszyklus ist entscheidender Bestandteil erfolgreicher Qualitätssicherung.
QS-Planung beinhaltet zunächst das Festlegen der Qualitätsziele, die Definition von Standards und das Bereitstellen von Werkzeugen, die zum Erreichen der Ziele notwendig oder hilfreich sind. Zuständig hierfür sind QS-Verantwortliche.
Mit der Entwicklung (Wartung) der Software geht die QS-Durchführung einher. Für die Durchführung der QS-Maßnahmen ist - im Rahmen der durch die QS-Planung vorgegebenen Standards und Werkzeuge der Bearbeiter zuständig.
QS-Kontrolle hat zu überprüfen, ob und in welchem Grade die verlangte Qualität erreicht wurde. Die Kontrolle muß von QS-Verantwortlichen vorgenommen werden. Nur so kann auch unter Zeit- und Kostendruck Qualität garantiert werden.
Alle Qualitatssicherungen müssen nach dem Prinzip "small is beautiful" vorgenommen werden. Die Qualitätssicherung muß also an kleinen überschaubaren Teilergebnissen erfolgen. Die Teilergebnisse wiederum sind einzeln und nach "artspezifischen" Verfahren zu überprüfen.
Die drei Basismethoden sind Reviews, als Verfahren zur Begutachtung von Entwicklungsergebnissen, Produkt-/Projektverwaltung zur systematischen Ablage aller Teilergebnisse und Überwachung des Projektfortschritts sowie regressionsfähige Tests.
Daß erfolgreiche QS von Werkzeugen unterstützt sein muß leuchtet ein. Doch nicht jede Werkzeugunterstützung bewirkt erfolgreichere QS: nämlich dann nicht, wenn die benutzten "Tools" nicht auf die jeweiligen Bedürfnisse abgestimmt sind. Als erfolgreich eingesetzte Werkzeuge lassen sich zum einen Projektbibliotheken zur Produkt- und Projektverwaltung und zum anderen leistungsfähige Testunterstützungs-Systeme nennen.
Die Erfahrung, gewonnen aus vielen Projekten, hat einige "goldene" Regeln hervorgebracht:
- Qualitätssicherung muß integraler Bestandteil der Projektarbeit in allen Phasen des Software- Lebenszyklzus sein.
- Qualitätssicherung ist sorgfältig und frühzeitig zu planen.
- Qualitätssicherung muß in kleinen Schritten durchgeführt werden.
- Unterschiedliche Qualitätsmerkmale erfordern unterschiedliche, adäquate QS- Maßnahmen. Und:
- In QS- Maßnahmen müssen alle Projektbeteiligten einen Vorteil auch für sich erkennen können.
Zurück zu den gegen QS vorgebrachten Argumenten. Der Vorwand der fehlenden Zeit ist simpel ein Planungsfehler. Daß QS während der Entwicklungsphase Zeitaufwand bedeutet, ist unbestritten. Darum muß gerade dieser Aufwand bereits in der Projektplanung berücksichtigt werden. QS gehört zur Projektdurchführung wie Spezifikation und Programmierung. Es ist daher für das Gesamtprojekt ein fataler Fehler, bei den scheinbar unvermeidlichen Zeitengpässen besonders bei der QS Abstriche zu machen.
Was die Kosten angeht, so gelten hier Ähnliche Argumente wie bei dem oben genannten Vorwand. QS- Maßnahmen kosten zunächst einmal Geld müssen deshalb im Projektbudget vorgesehen werden. Obwohl der Nutzen der QS sehr schwer quantifizierbar ist, sind wir überzeugt, daß der in die QS investierte Aufwand häufig bereits schon bis zur Erstinstallation durch Einsparungen kompensiert wird. Dies gilt insbesondere wegen der Chance Fehler frühzeitig zu erkennen und der problemloseren Integration. Der längerfristige Nutzen ist allemal unbestritten. Zu einem günstigen Kosten-Nutzen-Verhältnis kommt aber nur derjenige, der die richtigen QS-Maßnahmen mit den für seine Umgebung geeignetsten Hilfsmitteln durchführt.
Aus dem zuletzt Gesagten ergibt sich schon unsere Antwort auf den dritten Einwand: Es gibt nicht den "allein selig machenden" Weg zu erfolgreicher QS. Welche Maßnahmen wie und durch wen einzusetzen sind, hängt immer von der konkreten Situation ab. Diese maßgeschneiderte QS läßt sich nur schrittweise erarbeiten durch Übernahme erprobter Verfahren und Einbeziehung neuer Ideen. Qualifizierte Hilfe Von außen kann den Prozeß notwendige, oftmals leidvolle Erfahrungen zu sammeln, abkürzen.
Bleibt der Einwand der Mitarbeiter-Akzeptanz. QS-Maßnahmen werden nur dann angenommen, wenn für jeden Betroffenen der Sinn und die Notwendigkeit einleuchtend sind. Unterstützt wird die Akzeptanz insbesondere, wenn angemessene und benutzerfreundliche Werkzeuge und Hilfsmittel bereit stehen. Selbst "ungeliebte" Verfahren wie Reviews werden bei Beachtung einiger Regeln erstaunlich gut akzeptiert. So sollten Reviews stets der Beurteilung über die Qualität eines Ergebnisses dienen, aber niemals der Beurteilung des Bearbeiters.
Das Fazit unserer Darstellung: Die gegen QS vorgebrachten Argumente sind nicht stichhaltig. QS kann heute erfolgreich und preiswert durchgeführt werden, vorausgesetzt, es wird dabei systematisch vorgegangen und - wo immer möglich - mit geeigneten und abgestimmten Werkzeugen und Verfahren gearbeitet.
Wie geht es weiter mit der Qualitätssicherung? Künftig wird der Bedarf sicherer wartungsarmer, portabler, anpassbarer, generell gesagt: qualitativ hochwertiger Software stark steigen. Dies erfordert entsprechende QS-Maßnahmen bei der Realisierung dieser Software. Werkzeuge werden verstärkt in diesen Bereich der Software-Entwicklung vordringen. Dies gilt insbesondere für den realisierungstechnischen Aspekt. Es gibt beispielsweise schon heute Verfahren und Tools zur Bewertung der Wartbarkeit eines Softwaresystems. Überhaupt wird man versuchen, über die realisierungstechnischen Eigenschaften Metriken zu legen, um objektivere Qualitätsmaßstäbe zu bekommen.