BERLIN (hh)- Das Thema "Gütezeichen für Software" hat bis jetzt noch nichts von seiner Brisanz eingebüßt. Im Umfeld der Fachvorträge zur Qualitätssicherung (QS) von Softwareprodukten diskutierten Teilnehmer und Referenten intensiv über die Problematik - freilich ohne eine Sofortlösung zur Hand zu haben. Einigkeit allerdings herrschte darüber, daß Qualität nicht im nachhinein in ein Produkt geprüft werden kann, sondern daß qualitätssichernde Maßnahmen projektbegleitend eingesetzt werden müssen.
Problembewußtsein für einen geschickteren und menschlicheren Einsatz bestehender und kommender Werkzeuge zur Qualitätssicherung wollte Andreas Haase von der PU Partnerschaftliche Unternehmensberatung GmbH aus Hamburg wecken. Ihm ging es darum, Aspekte in den Vordergrund zu stellen, die zwar allgemein bekannt sind, in der täglichen Arbeit aber immer wieder vergessen werden.
Vor diesem Hintergrund unterschied Haase zwischen konstruktiven QS-Maßnahmen (Wahl einer Sprache oder eines bestimmten Compilers) und analytischen Aktionen. Hierzu zählen Inspektionen, Walk Throughs, Reviews, Programm-Verifikationen und Tests. Probleme beim Einsatz dieser Vorkehrungen gibt es nach Meinung des Referenten vielerlei: Ungeschickter Einsatz der Aktivitäten, eine mangelnde Akzeptanz seitens der Betroffenen, oder ein zu später Einsatz von Qualitätssicherungsmaßnahmen sind Kennzeichen für die heutige Situation.
Hilfe zur Selbsthilfe durch handliche Software-Tools und Checklisten sollte eine Methode sein, um diesem Dilemma zu entgehen. Der rechtzeitige Einsatz von QS-Maßnahmen zählt aber ebenso zu den konzeptionellen Überlegungen auf dem Weg zu besserer Software wie die Festlegung von Gütemerkmalen und eine interne Verbesserung des Image - wobei die gleichberechtigte Einbettung der QS-Aktionen in die Projektarbeit sich als sinnvoller erweist als eine unnötig überspitzte Hervorhebung der Prüf- und Kontrollfunktionen.
Skala nicht verfeinert
Um die Qualitätsaussagen über ein bestimmtes Produkt zu präzisieren, hat sich die Siemens AG nach den Worten des Referenten Wolfgang Heidrich für eine vierstufige Skala zur Bewertung der Qualität fertiggestellter Softwareprodukte: ohne Mängel, leichte Mängel, schwere Mängel und ausschließende Mängel. Diese Skala wurde nicht verfeinert, da eine Vertiefung bei der Art der verfügbaren Kriterien keine bessere Information ergeben hätte, sondern, so die Aussage, lediglich zu Diskussionen über die Wahl der zu vergebenden Bewertungen geführt hätte.
Aber nicht nur der Hersteller muß zur Güte des Produktes beitragen - auch der Anwender ist nach Worten Heinz Bons von der SQS GmbH aus Köln aufgerufen, seinen Beitrag zu besserer Software zu leisten. Ihm allerdings ist von den Fachspezialisten der Entwicklungsseite Hilfestellung zu leisten.
Den Anwender zu einem echten Projektmitglied zu machen, ist somit eine der wichtigsten Aufgaben der Zunft. Die Haupterfordernis liegt darin, Kommunikationshemmnisse abzubauen, denn die Praxis zeigt vielfach, daß er User erst am Endergebnis die Realisierung seiner Anforderungen prüft und Abweichungen mit extrem hohem Aufwand nachträglich eingearbeitet werden müssen.
Bewährte Mittel zur Einbindung des Endusers in den Produktionsprozeß sind strukturierte Gruppengespräche sowie der Einsatz methodischer Konzepte wie Prototyping, bei dem der Endbenutzer probeweise mit Prototypen des Zielsystems arbeiten kann, um aufgestellte Anforderungen frühzeitig auf ihre Brauchbarkeit und Vollständigkeit hin abzuchecken.
Wichtig erscheint Heinz Bons darüber hinaus die aktive Mitarbeit des Anwenders bei der Abnahme von Zwischenergebnissen und der Testfallermittlung. Die Anwender-Testfallermittlung sollte dabei möglichst losgelöst von der Darstellung der Vorgaben erfolgen. Der Anwender, der die Testdaten ausarbeitet, erfaßt dabei relevante Informationen, die zur Vollständigkeit der Bearbeitung zwingen.
Sind Testdaten durch Testfallbeschreibungen definiert, so ergibt sich darüberhinaus die Möglichkeit, diese Daten sinnvoll für Regressionstests zu nutzen, sowie sie bei Änderungen oder Erweiterungen anzupassen. Durch organisatorische Regelungen kann auch dazu beitragen werden, gezielt aus Testdatenbeständen Datensätze und Soll-Ergebnisse auszuwählen, die später im Wartungscheck benötigt werden.
So einig sich Referenten und Zuhörer auf dieser Fachkonferenz darüber waren, daß Qualitätssicherungsmaßnahmen unter Einbeziehung aller Beteiligten projektbegleitend eingesetzt werden müssen, so einig waren sie sich aber auch darüber, daß in die Produktszene mehr Transparenz gebracht werden muß. Einen Weg hierzu stellt die Vergabe eines Gütezeichens dar - an der Frage des "Wer" und "Wie" allerdings entzündeten sich lange Diskussionen.
Sowohl die Gütegemeinschaft Software e.V. aus Ulm als auch die RAL Deutsches Institut für Gütesicherung und Kennzeichnung e.V., der VDMA und der TÜV befassen sich mit dieser Thematik.
Ziel ist es, die Güte sichtbar zu machen und glaubhaft zu dokumentieren, so der allgemeine Tenor der Repräsentanten. Dies allerdings setzt genau definierte Güteniveaus voraus, die - so RAL-Direktor Wolfgang Schirmer - in ihrer Einhaltung permanent durch außenstehende Dritte überwacht werden müssen. Ein Problem insbesondere bei Softwareprodukten, wie die Referenten übereinstimmend feststellten.
Darüber hinaus ist es nach Meinung der Beteiligten erstrebenswert, daß die Verteilung eines Gütesiegels eine vom Hersteller freiwillig in Anspruch genommene Leistung bleibt. Um den freien Wettbewerb gerade in diesem schnellebigen, expandierenden Markt aufrechtzuerhalten, sollte von staatlich verordneten Regelungen Abstand genommen werden, so das Diskussionsergebnis.
Davon abgesehen ist aber auch der Hersteller aufgerufen, die Arbeit dieser Organisation zu unterstützen - durch projektbegleitende QS-Maßnahmen, gute Dokumentationen und aufklärende PR-Arbeit für den Anwender.
Diesem Aufruf der Referenten verleiht eine Zahl Nachdruck, die vom TÜV Essen errechnet wurde: Durch projektbegleitende QS-Aktivitäten lassen sich nachweislich, so der TÜV bis zu 50 Prozent der Kosten des Gesamtlebenszyklus eines Softwareproduktes einsparen.