Für Folgeschäden beim Einsatz fehlerhafter Software haften die Weichware-Manufakturen neben der üblichen Gewährleistungspflicht allenfalls noch moralisch, nämlich mit ihrem guten Ruf im Markt. Qualität aber haben sich die Unternehmen groß auf ihre Fahnen geschrieben. Nach Meinung verschiedener Experten, die sich mit der Qualitätssicherung bei Softwareprodukten befassen, ist es zur Sicherstellung einer größtmöglichen Güte der Programme, insbesondere was Funktionalität und Richtigkeit angeht, jedoch gleichgültig, nach welchem Konzept die Entwicklungsarbeiten vorgenommen werden. Wichtigster Aspekt ist in jedem Fall die Integration der Maßnahmen in das Gesamtprojekt. Hier aber, so zeigt die Erfahrung, liegen in der praktischen Arbeit einige Stolpersteine.
Diese Hindernisse auf dem Weg zu einer wirklichen Einbindung der qualitätssichernden Maßnahmen ergeben sich aber nicht nur auf der technischen Seite.
So hat es sich in der Praxis als positiv erwiesen, Review-Maßnahmen bereits bei Projektbeginn zu planen und feste Checktermine und -zeiten einzuräumen. Diese Reviews sollten, so Gerd Eickers, Leiter der Systementwicklung der General Electric Informations Service (Geisco) aus Hürth, von dritter Seite aus vorgenommen und flächendeckend nach einem standardisierten Schema durchgeführt werden.
Flächendeckend bedeutet hier, daß Tests auf verschiedenen Ebenen stattfinden, wobei alle Modelle, ihre Integration sowie aber auch reine Projektfaktoren (Kosten, logischer Aufbau, Dokumentation, Nachvollziehbarkeit oder Funktionstüchtigkeit) nach einem bestimmten Anforderungs- und Maßzahlensystem bewertet, Aufschluß über das Entwicklungsprojekt geben.
Es empfiehlt sich dabei, nach Aussage des Geisco-Experten, auch jeweils andere Reviewgruppen mit den Tests zu beauftragen.
Je nach Komplexität des Programmes und der Reviewstufe schlägt Eickers vor, die Testverantwortung hierarchisch den Reviewgruppen zuzuordnen. Diese Gliederung sollte jedoch auch in kleineren Unternehmen nicht nach der Position innerhalb der Managementhierarchie erfolgen, sondern streng nach dem Spezialisierungsgrad der einzelnen Mitarbeiter
Damit wird gleichzeitig ein wichtiger menschlich bedingter Stolperstein auf dem Weg zu einem qualitativ hochwertigen Produkt ausgeschaltet: Die mangelnde Anerkennung des Prüfbeauftragten durch den Entwicklungsingenieur. Seine konstruktiv-kritischen Verbesserungsvorschläge werden bei fachlicher Wertschätzung nicht mehr als "bloße Besserwisserei" ausgelegt, sondern öffnen einer erfolgreichen Kommunikation schon während der Software-Entwicklung die Tore.
Wie entscheidend dieser Aspekt für die Qualitätssicherung ist, lassen Zahlen erkennen, die Harry M. Sneed in einem Fachtagungsvortrag des Softwaretest e. V. bekannt gab. Demnach produziert der Mensch durchschnittlich 1,5 Fehler pro 100 Zeilen. Davon erkennt er selbst rund die Hälfte und korrigiert sie dann. Es bleibt nach dieser Erfahrungsrechnung also ein Fehlerrestbestand von 0,75 je 100 Zeilen. Bei einem Programm mit 20 000 Anweisungen errechnet sich somit die Zahl von nicht weniger als 150 Fehlern. Diese Werte verändern sich nach Aussage Sneeds auch nicht bei Einsatz einer höheren Programmiersprache - es werden lediglich weniger Anweisungen bei gleichem Funktionsumfang benötigt.
Ein weiterer Wert aus der Praxis läßt aufhorchen: Die Fehlerbehebung nach der Installation kostet das Zehnfache gegenüber der Fehlerbehebung vorher - ganz zu schweigen von den Folgeschaden.
Projektbegleitende Qualitätssicherungsmaßnahmen zu festgelegten Meilensteinen sind hier ein kostendämpfendes Mittel, ebenso, wie die vertrauensvolle Zusammenarbeit zwischen Entwicklung und Prüfingenieur.
Die Geisco ist bei ihren QS-Maßnahmen dazu übergegangen, vom Projektleiter einen eigenen externen Reviewleiter ernennen zu lassen, der für die Auswahl der Prüfgruppenteilnehmer aus fachlich geeigneten Abteilungen verantwortlich zeichnet.
Der Aufbau einer speziellen Check-Gruppe läßt sich nach Eickers Aussagen aus zweierlei Gründen nicht bewerkstelligen.
Zum einen ist die Komplexität und Vielschichtigkeit der durchzuführenden Projekte nicht nur einigen wenigen Spezialisten zu übertragen. Zum anderen würde aus diesem Grund der Aufbau einer solchen Mannschaft zu hohen Personalinvestitionen bei zu geringer Auslastung führen.
Darüber hinaus scheitert der Einsatz einer fest installierten Review-Mannschaft auch an den Gegebenheiten des derzeitigen Personalmarktes, der schon allein im Entwicklungsbereich unter chronischem Mangel an wirklichen Top-Spezialisten leidet.