Qualitätsmanagement erobert Europa

Konkreter Anlass für dieses Gespräch sind die beiden Konferenzen, die von 5. bis 7. April 2000 in Köln-Bonn in der Beethovenhalle stattfanden: Der 5. Kongress "Software-Qualitätsmanagement" (SQM 2000) und die "International Conference of Software Testing" (ICS-TEST). Sie boten einen guten Anlass, um das Thema Software-Qualitätsmanagement auch in Österreich bewusst zu machen. Doch lassen wir Rudolf van Megen selbst zu Wort kommen:

"Diese Veranstaltung gibt es nun zum fünften Mal, bisher waren gerade aus Österreich und der Schweiz noch relativ wenige Interessenten dabei, deshalb haben wir auch in Österreich einiges dafür getan. Dass es dabei zwischen Österreich und Deutschland keine Sprachprobleme gibt, ist ein weiterer Vorteil. Noch dazu ist das Thema Software-Qualitätsmanagement gerade jetzt sehr aktuell.

Wie es dazu kam

So um 1980 waren die Amerikaner auf dieses Thema gekommen, sie lösten es anfangs vor allem durch mehr oder weniger lange Checklisten. Da wurde jeder Vorgang abgehakt - und das alleine war uns zu wenig.

Wir versuchten, es besser zu machen. Eine der Grundlagen war ein Forschungsprojekt mit dem deutschen BMFT (Bundesministerium für Forschung und Technik), damals begann man, die theoretische Grundlagen hierfür zu erarbeiten.

So gibt es in der Qualitätssicherung grundsätzlich zwei Bereiche: die konstruktive und die analytische Qualitätssicherung.

Fehler vermeiden

Der erste Bereich, die konstruktive Qualitätssicherung, betrifft vor allem die Frage: "Wie können wir Fehler überhaupt vermeiden?". Möglich ist dies im einzelnen beispielsweise durch eine bestimmte Methode, durch bestimmte Verfahren, wie man etwas anfängt, oder dass man beispielsweise ein Fachkonzept erstellt - all das sind Teile davon.

Schon die "requirements definition", die Definition der genauen Zielvorgaben, machen hier schon rund ein Drittel des gesamten Aufwandes aus - ein Drittel, das in diesem Bereich trotzdem eine der besten Investitionen an Aufwand und Arbeitszeit ist, die man machen kann.

Man sollte unserer Erfahrung nach tatsächlich rund ein Drittel der gesamten Entwicklungsarbeit in eine möglichst exakte und umfassende Definition jenes Produktes investieren, das man dann schlußendlich haben will. So vermeidet man Leerläufe schon einmal dadurch, dass man zum Beispiel durch genau festgeschriebene Details und Parameter verhindert, dass verschiedene Entwickler einzelne Teile des Produktes auf unterschiedliche (weil nicht exakt in einem Pflichtenheft festgehaltene) Parameter hin entwickeln - ein Vorgang, der unweigerlich zu späteren, mehr oder weniger umfangreichen Änderungen führen muss.

Ein weiterer Effekt mangelnder oder unpräziser Spezifikationen ist, dass man unter Umständen etwas bekommt, von dem man dann nicht genau weiß, ob man es auch tatsächlich in dieser Form haben wollte.

Das ist, wie gesagt, unser erster Schritt: Wir bringen die Menschen dazu, dass sie rund dreißig Prozent des Aufwandes in Requirement-Definitionen investieren.

Was die weiteren Teile des Entstehungsprozesses betrifft, so wird dann beispielsweise fünfzehn Prozent in das System Design investiert, weitere dreißig Prozent in die Codierung gesteckt und der Rest ins Testen, das scheint uns eine vernünftige Aufteilung.

Die Konstruktive Qualitätssicherung ist also damit zu beschreiben, dass man von vornherein systematisch vorgeht und dadurch versucht, Fehler von vornherein zu vermeiden.

Fehler erkennen

Der zweite Bereich, die analytische Qualitätssicherung, dreht sich generell um die Erkennung von Fehlern, die trotzdem passiert sind. Getreu dem Sprichwort "Nur wer nichts tut, macht keine Fehler" sind Fehler grundsätzlich niemals völlig auszuschließen.

Wir wollen die Fehler aber nicht erst am Ende erkennen, wenn das fertige Produkt (fehlerhaft) dasteht. Wir wollen vielmehr jeden Fehler schon lange vorher entdecken und eliminieren. Zu diesem Zweck gibt es schon nach jedem erfolgten Schritt, beispielsweise schon nach der Fertigstellung des erwähnten Pflichtenheftes, sogenannte "Reviews". Dabei wird geprüft, ob bei der bisherigen Arbeit nicht schon Fehler zu finden sind, die gleich jetzt beseitigt werden können - je früher, desto weniger Kosten werden dabei verursacht.

Als Vergleichsmodell kann man sich einen Hausbau vorstellen: Wird beim Plan schon festgestellt, dass etwa ein Zimmer fehlt, so ist der Aufwand für die Änderung mit Sicherheit wesentlich geringer, als wenn bei einem fertig errichteten Haus ein ganzes Zimmer nachträglich neu geplant und angebaut werden müsste. Und das ist auch der Zweck dieser "Reviews": möglichst frühzeitig Fehler finden.

Alleine dadurch finden wir aber nicht alle Fehler. Wir müssen also noch mehr tun. Und dieses "Mehr" bedeutet unter anderem, dass wir zum Beispiel jetzt einen SQS-spezifischen Ansatz haben, indem wir in Teilbereichen den Testprozeß selbst von der Fertigstellung weg möglichst weit nach vorne schieben. Wir beginnen damit sehr viel früher, als es vorher üblich war. Dadurch haben wir jetzt eine zusätzliche Möglichkeit, schon frühzeitig beispielsweise in den Fachkonzepten vorhandene Fehler zu erkennen. Das alles führt dazu, dass wir bereits nach der ersten Entwicklungsphase zwischen dreißig und fünfzig Prozent der Fehler entdecken, die wir sonst erst am Ende der Entwicklung finden.

Ein weiterer Vorteil ist dabei, dass die Änderungen zu einem Zeitpunkt anfallen, zu dem die Mitarbeiter noch nicht so extrem ausgelastet sind wie später, zum Abschluss der Entwicklung. Dadurch steht für die Änderung mehr Zeit zur Verfügung, andererseits wird später, bei der Phase der Fertigstellung, viel weniger Arbeitszeit durch die berüchtigten "Änderungen in letzter Minute" gebunden. Der gesamte Ablauf wird somit günstiger.

Deshalb sage ich immer: Mit systematischer Qualitätssicherung zum richtigen Zeitpunkt kann man in kürzerer Zeit mit weniger Kosten das Projektziel erreichen. Denn einen Fehler schon früh im Entwicklungsprozess zu erkennen und zu beseitigen, ist auf jeden Fall immer kostengünstiger, als ein Produkt "falsch" fertig zu entwickeln und erst dann die gleichen Fehler zu korrigieren - inklusive aller durch diese "Nachbesserung" erforderlichen weiteren Änderungen.

Von der Historie her betrachtet waren dies die beiden Aspekte, die wir als erstes eingebracht haben. Hinzu kommt nun noch ein dritter Aspekt, das Management der Qualitätssicherung.

Das ist jener Bereich, wo wir den gesamten Prozess betrachten und die Gesamtqualität hinterfragen. Das umfasst die Fragestellungen "wie gut sind wir eigentlich hier?" und "wo können wir noch etwas verbessern?", sowie "welche Prozesse laufen gut und welche beinhalten Verbesserungspotenzial?". Dann überprüfen wir auch die Prozesse der Organisation, das ganze Umfeld, etc. bis hin zu den Metriken und Kennzahlen, was diese Kontrolle kostet - und was sie bringt.

Was bringt es überhaupt?

Diese Frage sollten wir seinerzeit einem Kunden aus dem Bereich der Finanzverwaltung konkret beantworten, und so mussten wir selbst erst einmal diese Parameter feststellen. Am Anfang stand ein Finanzministerium eines deutschen Bundeslandes, in dem ein maßgebender Verantwortlicher einfach behauptete: "Wozu brauchen wir Qualitätssicherung - das haben wir doch überhaupt nicht nötig!"

Grund genug für uns, darauf eine fundierte Antwort zu liefern. Das war übriges für uns ebenfalls spannend: ein Modell zu erarbeiten, an dem wir konkret feststellen können, was Software-Qualitätsmanagement eigentlich nützt. In diesem Modell wurde beispielsweise gefragt: Wieviel Arbeitszeit kostet ein Softwarefehler einen Mitarbeiter in der Finanzverwaltung im Durchschnitt? Und ähnliches.

Dabei wurde festgestellt: Bei einem Projekt mit einer Verteilung von einem Drittel systematischen Testens und zwei Dritteln "eigentlicher" Entwicklungsarbeit erspart jede einzelne Arbeitsstunde beim Testen ungefähr dreieinhalb bis sechs Arbeitsstunden, die sonst durch eine spätere Beseitigung der gefundenen Fehler notwendig würden - abhängig davon, ob dieser Testprozess nicht automatisiert oder vollautomatisiert abläuft. Beim vollautomatischen Testen sind die Einsparungen am gravierendsten.

Kleine Ursache - große Wirkung

Bei vielen Großprojekten ist der Anteil an Software wertmäßig zwar gering, die Auswirkungen eines Softwarefehlers sind hier aber unverhältnismäßig groß. Beispiele dafür sind etwa die Schwerindustrie, wenn beispielsweise ein ganzes Walzwerk erst um Monate verspätet ausgeliefert werden kann, weil die mitgelieferte Software (mit einem Wert von nicht einmal fünf Prozent der Investitionssumme) nicht wie erwartet funktioniert. Oder eine neu errichtete Kaianlage in einem Hafen: Wenn da die Software für die Logistik und die Steuerung der Warenströme nicht perfekt funktioniert, ist bloß noch das Chaos perfekt - obwohl diese Software nur einen Bruchteil der Gesamtsumme kostet, die für die gesamte Anlage veranschlagt wurde.

Nicht bei jedem Kunden können wir übrigens gleichzeitig "mit allem" anfangen. Wir untersuchen also ein neues Projekt am Anfang einmal danach, wo der größte "Leidensdruck" ist und wo die größte Möglichkeit einer Verbesserung besteht. Hier beginnen wir mit unserer Tätigkeit und erstellen einen Verbesserungsplan.

In alledem sind wir so ausgerichtet, dass wir dem Kunden nicht nur dicke Bücher mit Analysen schreiben, sondern vor allem konkrete Vorschläge machen und jene Mittel nennen, mit denen diese Vorschläge bestmöglich umgesetzt werden können. Deshalb bezeichnen wir uns als "Softwaretechnologieberater". Wir sind also ein Dienstleistungsanbieter, der sich direkt auf die Arbeit bezieht.

Das Unternehmen

In Deutschland sind wir flächendeckend vertreten, mit 300 Mitarbeitern in der SQS-Gruppe. Darunter sind keine Freiberufler oder Teilzeitkräfte, sondern nur "fulltime"-Mitarbeiter. Übrigens sind wir gerade bei der Umstrukturierung in eine AG; der Börsegang wird aber noch ein wenig dauern - auch deshalb, weil wir kein "Startup-Unternehmen" sind, das heute an die Börse muss, um morgen noch genügend Geld zu haben. Wir dagegen sind schon seit 18 Jahren eine "Erfolgsfirma", der Umsatz beträgt derzeit europaweit 78 Mio DM.

Dabei beraten wir Firmen in praktisch allen Branchen, von Banken und Versicherungen über Finanzdienstleister bis hin zu Industrieunternehmen, beispielsweise in der Autoindustrie.

Die SQS selbst bearbeitet dabei in Deutschland die Branchen Financial Services, Telekommunikation, e-Business & Retail sowie Public Administration & Care.

Der Bereich "Industrie & embedded Systems" ist in die Tochterfirma DTK ausgelagert, die arbeitet für Firmen wie Daimler-Chrysler Alcatel oder die Eisenbahnen (etwa elektronische Stellwerke).

Sie finden ja - nur als Beispiel - in jedem modernen Automobil zwischen zehn und dreißig Systeme, von Airbag und ABS bis zur Motorregelung, die alle auch Software beinhalten - Software, die erst getestet und entwickelt werden will. Alle diese Systeme verbindet bei modernen Fahrzeugen ein gemeinsames Kommunikationsnetz (CAN-Bus), für den wir ebenfalls kürzlich ein diverse Testverfahren und Tools entwickelt haben, um ihn als Gesamtheit "in einem Stück" zu testen - ebenfalls ein Novum in dieser Branche.

Die FTT, seit 1999 ein weiteres Unternehmen der SQS-Gruppe, befaßt sich vor allem mit IT-Sicherheitskonzepten, beispielsweise mit intrusion detection Systemen.

Das "Bootstrap Institute" wiederum ist eine Institution europäischen Rechts, die ein Verfahren entwickelt hat, um das Management der QS-Assessements durchzuführen. Dabei arbeiten wir auch mit internationale Fachleuten zusammen, beispielsweise mit Herrn Günther Koch vom Austrian Research Center in Seibersdorf.

Soweit die Struktur in Deutschland. 1998 haben wir den Schritt nach Spanien gemacht und dort die erste "SQS - Software Quality Systems" gegründet - das Unternehmen soll in Zukunft dann übrigens europaweit diesen Namen führen - diese Firma macht in Spanien nun all das, was wir in Deutschland auch tun.

In Deutschland sind wir die Nummer 1, der nächste logische Schritt ist die Ausbreitung in Richtung Europa, um dieses Know-how auch EU-weit zu nutzen. Hier gilt auch die Überlegung: "Um in Deutschland die Nummer 1 zu bleiben, muss man in Europa Nummer 1 werden". Dabei sind Firmen, die - zum Beispiel in Großbritannien - das Gleiche betreiben, unter Umständen durchaus Akquisitionskandidaten für uns.

Veranstaltungen wie die "ICS TEST" und der "SQM 2000 Kongress" helfen uns natürlich dabei, unsere Botschaft zu verbreite und den Anwendern die Bedeutung des Qualitätsmanagements nahezubringen. Dabei haben wir uns auf etwa 700 Teilnehmer vorbereitet, im letzten Jahr waren es 420.

In Zukunft werden wir übrigens ab dem zweiten Quartal 2000 einige unserer Veranstaltungen - wir haben vierzig verschiedene Seminare - auch in Wien anbieten. Darunter vor allem Basiskurse wie "Acceptance Testing", einen Dreitageskurs für SW-Entwickler oder Tester. Das stellt dann auch eine neue, zusätzliche Möglichkeit für Klein- und Mittelbetriebe dar, sich über dieses Thema zu informieren."

Umfangreiche Informationen sind auf der Homepage von SQS "http://www.sqs.de/" zu finden, weiterführende Links zu dem Thema unter "http://www.sqs.de/pages/links.htm".

Das Gespräch führte Ing. Adolf Hochhaltinger