Von der Qualität eines Computerprogrammes wird zwar viel gesprochen. Tatsache aber ist, daß nur die wenigsten Softwareentwickler eine institutionalisierte Qualitätssicherung betreiben. Dabei birgt gerade das phasenbegleitende Überprüfen der Programmgüte Möglichkeiten, Kosten zu sparen. Denn eine Vielzahl der Fehler eines Produktes die erst im Nachhinein geortet und dann aufwendig behoben werden müssen, lassen sich noch in der Entwicklungsphase erkennen und ausmerzen. Der Nachweis allerdings, welchen Nutzen Maßnahmen zur Sicherung der Güte eines Softwareproduktes bringe, ist im Einzelfall nur schwierig zu erbringen - mit ein Grund. warum die Investition "Qualitätssicherung" beim Management nur äußerst ungern akzeptiert wird.
Daß Softwarequalitätssicherung- bisher -im Gegensatz zur Qualitätssicherung in der industriellen Produktion (Automobilindustrie, Haushaltsgerätebau) weder personell noch organisatorisch und technisch
die eigentlich erforderliche Beachtung gefunden hat, ist - wenn man die "Szene" kennt -unzweifelbar.
Beachtung sollte der Qualitätssicherung (QS) innerhalb der Softwareproduktion zukommen, da die finanziellen Aufwendungen für die Softwareproduktion immer größer werden. Insbesondere die vielfach geäußerten -und für die Praxis durchaus zutreffenden - Angaben hinsichtlich des Wartungsaufwands (40 Prozent bis 60 Prozent der Gesamtaufwendungen für die Software-Entwicklung), der teilweise schon in Unternehmungen dazu führt, daß Neuentwicklungen zurückgestellt werden müssen, müssen verantwortungsvolle Führungskräfte in der nächsten Zeit dazu veranlassen, in diesem Bereich geeignete Maßnahmen zu ergreifen.
Bloße Institutionalisierung reicht nicht
Geeignete Maßnahmen für die Qualitätssicherung innerhalb der Softwareproduktion - verstanden als Umsetzung des aufzubringenden Kapitals-können und sollten sich nicht darauf beschränken, daß nun in der Unternehmung/Institution eine Stelle geschaffen wird, die die Bezeichnung " Qualitätssicherung" enthält; dies kann nur ein erster kleiner Schritt sein zum Aufbau des QS-Systems.
Hier stellt sich insgesamt eine Aufgabe, die nicht auf eine Person oder eine Stelle in der Software-Entwicklung verlagert werden kann, sondern in ihrer Gesamtheit verschiedene Personengruppen wie Management, Projektleitung, Systemanalyse und Programmierung anspricht.
Was neben bekannten Hilfsmitteln wie Büchern oder Werkzeugen vielfach fehlt oder in zu geringem Maße vorhanden ist, betrifft die organisatorische Einbettung der QS, klare Schnittstellen zwischen der funktionalen und der strukturellen QS, quantitative Angaben zu Fehlerkosten als Nachweis gegenüber dem Management, abgestimmt durchgängige Werkzeugkonzepte, die den Anforderungen der QS Rechnung tragen, sowie die Unterstützung bestimmter Aufgabenträger (so Techniken für Anwender) und quantitative Angaben zu Fehlerkosten, Qualitätsmaßzahlen, Ergebnissen oder Aufwand von QS-Maßnahmen.
Strikte Aufgabentrennung
Grundsätzlich kann die QS sich sowohl auf Produkte beziehungsweise das Erstellen von Produkten als auch auf die Softwareproduktion selbst beziehen.
Dabei muß es insgesamt das Ziel der Qualitätssicherung sein, festzulegen, was, wann, wie, wer, womit zur Erreichung der geforderten Qualität zu tun hat.
Zur Erreichung des Zieles kann davon ausgegangen werden, daß die strukturelle von der funktionalen Qualitätssicherung streng zu trennen ist.
Während sich die strukturelle QS auf solche Aktivitäten bezieht, die von einer zentralen QS-Stelle durchgeführt werden, wird die funktionale QS innerhalb der Projekte von den Systementwicklern und der Projektleitung direkt durchgeführt.
Aufgaben der funktionalen QS sind die Anwendung von QS-Techniken, das Erstellen des QS-Plans oder auch das Bearbeiten von Testaufgaben. Zu den Aufgaben der strukturellen QS zählen das Festlegen des QS-Systems, das Beschaffen und Einführen von QS-Techniken und die Unterstützung bei der Anwendung von QS-Techniken in Projekten, um nur einige zu nennen.
QS übt grundlegenden Einfluß aus
Insgesamt sind die Aufgaben der strukturellen QS mehr oder weniger grundlegend für die gesamte Unternehmung/Institution, wobei durchaus projektspezifische Aspekte bei der Betreuung der Anwendung von QS-Techniken vorhanden sind.
Eine allgemeingültige Beantwortung der Frage nach der Stellung der QS ist nicht möglich. Vielmehr ist aufgrund der unterschiedlichen unternehmungs-/institutionsspezifischen Gegebenheiten zu entscheiden, welchem Bereich die QS - und hierbei insbesondere auf die strukturelle QS abgestellt - unterstellt ist.
Generell kann man aber sagen, was nicht wünschenswert ist. Hierzu gehören:
-Einordnung als isolierte Gruppe unter der Projektleitung,
- Macht über das Projektmanagement,
- Ämterverquickung zwischen Entwicklung und QS (obwohl teilweise unumgänglich),
- Entwicklungsverantwortung.
Die Festlegung einer geeigneten Einordnung der strukturellen QS in das Organigramm ist mit von der Unternehmungs- und Projektgröße, dem Produkttyp, den Risiken und der Projektorganisationsform abhängig.
In bezug auf die Zuständigkeiten sollte der Projektleiter in der Regel nicht weisungsbefugt sein gegenüber der QS. Balance zwischen Unabhängigkeit und Nähe zum Projekt ist erforderlich.
Für Manager nur Globalinfos
Die Festlegung der Berichtswege steht in unmittelbarem Zusammenhang mit den Zuständigkeiten. Es sollte insbesondere darauf geachtet werden, daß die richtigen Informationen in der richtigen Aufbereitungsform zu den entsprechenden Personengruppen gelangen.
Festlegungen hinsichtlich der Berichtswege sind erforderlich und müssen in Abhängigkeit von den insgesamt für notwendig erachteten Berichten und Dokumenten bestimmt werden.
Wenn auch allgemein ein Mangel hinsichtlich quantitativer Angaben zu unterschiedlichen Aspekten der Notwendigkeit und Wirkungsweise von QS-Maßnahmen gegeben ist, so existieren dennoch einige Erfahrungswerte. Hierbei muß allerdings darauf hingewiesen werden, daß derartige Erfahrungswerte häufig nicht in der Bundesrepublik Deutschland, sondern in den USA ermittelt worden sind; dies ist sicherlich nicht nachteilig, führt aber leicht zu der Aussage/Vermutung, daß die Zahlen für die hiesigen Verhältnisse nicht zutreffen würden, da man dort technologisch bereits sehr viel weiter sei oder organisatorisch andere Möglichkeiten habe.
QS-Auswirkungen nicht quantitativ meßbar
Es ist eine mehr philosophische Frage, ob die Investitionsentscheidung "Qualitätssicherung" notwendigerweise nur aufgrund lückenloser unternehmungsspezifischer Rentabilitätsnachweise
getroffen werden kann, wenn erst einmal die Notwendigkeit erkannt ist; oder ob bei der Frage der Wirtschaftlichkeit nicht auch prohibitive Angaben zur Wirksamkeit eines (verbesserten) QS-Systems ausreichen. Zur Zeit ist die Unterstützung für die Verbesserung der QS häufig (noch) nur anhand konkreter Zahlen zu finden. Von dem "Management Point of view" ist dies sicherlich richtig, insbesondere da auch in den meisten Bereichen Investitionsentscheidungen immer aufgrund mehr oder weniger glaubwürdiger, quantitativer Angaben getroffen werden: Warum dies nicht auch bei der Software-QS?
Gründe sind insbesondere in dem Innovationsgrad der Software-QS begründet.
Auf die Frage, was bringt die Qualitätssicherung, können vielfach keine fundierten Angaben gemacht werden; allerdings müßte heute eigentlich jeder verantwortungsvolle Manager erkannt haben, daß es dringend Zeit ist, etwas zur Verbesserung der Softwarequalität zu tun und daher auch bereit sein, eine vielleicht nicht gänzlich in quantitiven Angaben zu beurteilende Investitionsentscheidung zu unterstützen.
Fehler können früher entdeckt werden
Die Tatsache, daß der Anteil von Fehlern, die in Softwarezwischenoder Endprodukten im gesamten Softwarelebenszyklus gefunden werden und aus Fehlern in den entsprechenden Vorgaben resultieren, zirka 60 Prozent beträgt, muß jeden Verantwortlichen aufschrecken. Nicht, daß man diesen Prozentsatz der Fehler, die erst in späteren Phasen gefunden werden, gänzlich vermeiden könnte; aber es besteht sicherlich die Möglichkeit, einen hohen Prozentsatz derartiger Fehler eher zu erkennen.
Betrachtet man weiterhin, daß die Kosten zur Fehlerbehebung für Behebung von Vorgabefehlern und Behebung von Fehlern in Programmen nach der Fertigstellung des Programm(systems) in hohem Maße unterschiedlich ist, dann wird die Bedeutung der frühzeitigen QS deutlich. Während die Kosten der Fehlerbehebung für Vorgabefehler generell rund 80 Prozent des Gesamtaufwands für die Fehlerbehebung aus macht - wobei "nur" 60 Prozent der Fehler in Vorgaben auf Vorgabefehler zurückzuführen sind, machen die Kosten der Fehlerbehebung in Programmen nur 20 Prozent der Gesamtkosten aus.
Wo soll man ansetzen?
Die darüber hinausgehende Frage, wo man denn nun mit den Maßnahmen der QS ansetzen sollte, ist sicherlich für den einzelnen eine wichtige Frage. Für das Verhältnis der Aufwendungen für die unterschiedlichen Klassen von Aktivitäten in der Entwicklung beziehungsweise Pflege und Anpassung gilt folgendes:
- In der Software-Entwicklung ist das Verhältnis der Aufwendungen für Spezifizieren/Entwerfen, Programmieren und Analysieren/Testen etwa 40 zu 10 zu 50.
- In Pflege und Anpassung kann für Spezifizieren/Entwerfen, Programmieren einerseits und Analysieren/ Testen andererseits ein Verhältnis von zirka 30 zu 70 zugrundegelegt werden.
- Das Verhältnis der Gesamtaufwendungen für Entwicklung sowie Pflege und Anpassung ist in etwa so, daß für die Pflege und Anpassung zwischen 100 und 300 Prozent der Entwicklungsaufwendungen kalkuliert werden müssen.
Geht man von diesen Zahlen aus dann würde sich aufgrund dessen anbieten, die stärksten Bemühungen auf das Analysieren/Testen zu konzentrieren, da der Aufwand hierfür im Softwarelebenszyklus zirka 65 Prozent der Gesamtaufwendungen beträgt. Hierbei muß man allerdings berücksichtigen, daß ein nicht zu vernachlässigender Analyse-/Testaufwand zu vermeiden wäre, wenn die Aktivitäten Spezifizieren/Entwerfen/Programmieren besser, also mit höherer Qualität bezüglich der Zwischen-/Endergebnisse durchgeführt würden.
Insofern sollte man aufgrund einer derartigen Berechnung nicht allein die Entscheidung treffen, wo mit der QS anzusetzen ist; vielmehr sollte man in beiden Bereichen Maßnahmen ergreifen.
Der schnelle Erfolg bei der QS ist allerdings nicht so leicht realisierbar; vielmehr sind die Auswirkungen in hohem Maße "erst" in der Wartung zu erkennen. Für den Projektleiter, der das Projekt durchführt, ist dies aber zunächst nicht so wichtig, wie der "erfolgreiche" Abschluß seines Projekts; dies ist nicht zuletzt dadurch bedingt, daß Projekte heute immer noch als erfolgreich bezeichnet werden, wenn sie innerhalb der vorhandenen Zeit mit den projektierten Kosten abgewickelt werden, wobei die Qualität nur in geringem Maße berücksichtigt wird.
Aufwendungen für die QS sind Investitionen, die dementsprechend unter langfristigen Zielsetzungen betrachtet werden müssen.
Auswirkungen erst spät erkennbar
Hat man zunächst einmal die Notwendigkeit erkannt, die Investition "Qualitätssicherung" betreiben zu müssen, dann stellt sich für das verantwortliche Management die Frage, wo man ansetzen soll.
Insgesamt soll noch einmal darauf hingewiesen werden, daß es nicht ausreicht, QS-relevante Techniken zu beschaffen und einmal eine Schulung durchzuführen, sondern
- eine systematische Betreuung in der Einführungsphase erforderlich ist,
- insbesondere der Gesamtrahmen für die QS, das QS-System, zu schaffen ist, um so die systematische Anwendung in dem Projekt sicherzustellen, wobei dies insgesamt auch einzuführen und durchzusetzen ist.
- eine Betreuung/Unterstützung zur systematischen Anwendung des QS-Systems - insbesondere - im ersten Projekt erforderlich ist.
- daß Problembewußtsein notwendig ist, um so die Akzeptanz der QS-Maßnahmen und Techniken sicherzustellen.
Wünschenswert hinsichtlich der phasenübergreifenden Maßnahmen sind das Erstellen des Qualitätsplans spätestens bei der Definition der Anforderungen (Qualitätsprodukt-Planung), Erstellen des QS-Plans (Qualitätsproduktions-Planung), frühzeitige Beteiligung der Anwender bei Maßnahmen der QS, Abstimmung QS mit der Projektplanung sowie die Verfügbarkeit von QS-Spezialisten.
Standards unumgänglich
Die Standardisierung von Aktivitätengruppen kann einerseits durch Beschreibung der Vorgehensweise im Sinne des Aufzeigens von Einflußgrößen, Handlungsalternativen oder Interdependenzen erfolgen. Daneben ist ergänzend die Festlegung der Ergebnisse möglich. In das Klassifikationsraster sind unterschiedliche, allgemein verfügbare QS-Standards mit ihren inhaltlichen Schwerpunkten eingeordnet. Es zeigt sich - allein aufgrund der rein quantitativen Beschreibung, daß
- wesentliche Teile der konstruktiven Maßnahmen insbesondere die zur Vorgehensweise) sowie
- die Qualitätskontrolle der Produkte bisher nicht oder kaum in QS-Standards enthalten sind.
Grundsätzlich läßt sich feststellen, daß eine umfassende Software-QS unter wirtschaftlichen Gesichtspunkten nur auf der Grundlage von QS-Standards möglich ist. Die Funktion der Standardisierung kann jedoch nur dann erreicht werden, wenn die Standardvorgaben umfassend sind und ein möglichst breites Spektrum der Software-QS abdekken.
Standards, die sich allein auf die Vorgaben zur Darstellung der Ergebnisse der unterschiedlichen Maßnahmen beschränken, stellen nur eine Teillösung dar. Diese Vorgaben implizieren nur scheinbar Aussagen zur Vorgehensweise bei der Realisierung dieser Ergebnisse.
Hinsichtlich der phasenübergreifenden Techniken sind folgende wünschenswerte Aspekte zu nennen:
- Systematische Anwendung strukturierter Gruppengespräche (Walk Through, Inspection, Review) anstelle informaler Gespräche
- Verfahren zur systematischen Testfallermittlung (zum Beispiel Test-Cadett, symbolische Ausführung, Äquivalenzklassenanalyse, Bedingungstabellen)
- Einführung von Qualitätszirkeln
- Sicherstellung der integrierten Testdokumentation.
Abstimmung tut not
Insgesamt sind abgestimmte Techniken für alle Maßnahmen im Software-Entwicklungsprozeß erforderlich. Ansätze - teilweise erfolgversprechende und verschiedentlich auch praxiserprobte Ansätze - hinsichtlich der Integration von Techniken sind durch sogenannte "Software Engineering Environments (SEE)" beziehungsweise Softwareproduktionsumgebungen realisiert. Charakteristisch bei diesen phasenübergreifenden Techniken ist, daß nahezu alle behaupten, einen integrierten Ansatz zu verfolgen, in der Richtung werden aber - heute noch -nur Teilbereiche der insgesamt im Software-Entwicklungsprozeß
durchzuführenden Aktivitäten der QS unterstützt.
Darüber hinaus unterscheiden sich die SEEs auch dadurch, daß es sich teilweise nur um eine Sammlung von Einzelwerkzeugen handelt, die dann eventuell integriert sind, während teilweise auch realiter integrierte Systeme oder zumindest Ansätze hierzu erkennbar sind.
Wichtig bei den SEEs ist insgesamt daß QS-Funktionen meistens nicht besser sind als bei Stand-alone-Techniken. So werden in einzelnen SEEs zwar auch die standardmäßig immer wieder geforderten, aber so selten verfügbaren Teststatistiken erstellt andere für die QS wichtige Aktivitäten wie das Erstellen des Qualitätsplans oder des Qualitätssicherungs-Plans werden bisher überhaupt nicht oder in geringem Maße unterstützt. Insofern sind zwar bei den SEEs gewisse Vorteile hinsichtlich der konstruktiven Aspekte der Qualitätssicherung gegeben.
Insgesamt sind aber auch dort keine umwerfenden Fortschritte hinsichtlich der QS zu verzeichnen, auch dann nicht, wenn ein Teil des Vorgehensmodells mit der Bezeichnung "QS" überschrieben wird - aber ohne Inhalt bleibt.
In die Klasse der phasenspezifischen Maßnahmen und Techniken werden auch solche einbezogen, die die Detaillierung und Revision der Ergebnisse bestimmter Aktivitäten in allen Phasen oder nur bestimmte Aktivität in allen Phasen oder nur bestimmte Activitätsgruppen der Qualitätssicherung für alle Phasen (zum Beispiel Standards zur Testplanung in allen Phasen) unterstützen.
Standards sind selten
Die Situation hinsichtlich der verfügbaren Standards und Techniken für Planung und Kontrolle der Produkte und der Produktion stellt sich wie folgt dar:
- Zur Qualitätsprodukt-Planung/ -Kontrolle sind Checklisten vorhanden.
- Zur Planung konstruktiver Maßnahmen sind nur in geringem Maße Standards oder Techniken vorhanden. Die projektspezifische Planung ist häufig dann gegeben, wenn eine Methodenbank zugrundeliegt, aus der aufgrund der projektspezifischen Anforderungen die geeigneten Konstruktions-Standards/-Techniken zusammengestellt werden. Meist wird davon ausgegangen, daß die einzusetzenden Standards oder Techniken generell gelten. Diese Annahme wird sicherlich dadurch gestützt, daß keine eindeutigen Aussagen über die Eignung von Techniken vorliegen ("Methodenstreit ), und es insofern in der Regel auch nicht sinnvoll ist unterschiedliche Methoden anzubieten, die projektspezifisch zu konfigurieren wären. Im wesentlichen wird die Planung der Konstruktion durch Handbücher oder Stand-alone-Werkzeuge unterstützt.
- Die Planung der analytischen Maßnahmen wird in gewissen Maße durch traditionelle Vorgehensmodelle unterstützt. Eine wesentlich detailliertere Unterstützung wird durch speziell auf das Testen ausgerichtete Standards bereitgestellt.
- Die Kontrolle der konstruktiven Maßnahmen ist einerseits in Handbüchern/Vorgehensmodellen festgeschrieben; andererseits sind in einigen Werkzeugen Möglichkeiten der automatisierten Überwachung der Anwendung gegeben.
- Die Kontrolle der analytischen Maßnahmen wird nur in geringem Maße durch Verfahren beziehungsweise Werkzeuge unterstützt. Eine wesentliche Unterstützung ist durch entsprechende Standards (Teststandards) gegeben.
Für die Durchführung des Analysierens stehen phasenspezifisch schwerpunktmäßig folgende Hilfsmittel zur Verfügung:
- Verfahren und Werkzeuge, wobei der Funktionsumfang derartiger Werkzeuge weit gestreut ist, er erstreckt sich von der Testvorbereitung mit Aktivitäten zur Testfallermittlung, Testdatenerstellung Erstellen von Testumgebung über die Testausführung mit Unterstützung der Aktivitäten mit Ablaufprotokollierung bis zu der Testauswertung mit unterstützenden Verfahren/Werkzeugen zum Erstellen von Ablaufstatistiken, Teststatistiken zur Ergebnisprüfung. Die in Betriebssystemen integrierten Techniken zur Durchführung des Analysierens sind vielfach auf Cross-Referenz-Listen, Testdatengeneratoren, einfache Funktionen zum Erstellen von Ablaufstatistiken begrenzt. Der Funktionsumfang von Techniken für die Durchführung des Analysierens in Software-Engineering-Environments entspricht meist denjenigen von Stand-alone-Systemen.
- Für die Durchführung des Analysierens existieren Standards.
Für die Dokumentation der Ergebnisse des Analysierens stehen sowohl Betriebssystem-Optionen, Stand-alone-Techniken, Funktionen in Software-EngineEring-Environments sowie Standards zur Verfügung.
Insgesamt sind die für die Qualitätssicherung zur Verfügung stehenden Standards und Techniken nur unzureichend. Es fehlen insbesondere integrierte, sämtliche Funktionen der Qualitätssicherung in den verschiedenen Phasen umfassende Standards und Techniken. Bisher sind zwar- hier auch durchgängig -für einzelne Aktivitätengruppen geschlossene Systeme vorhanden, allerdings nicht für alle Aktivitäten.
Trend: QS im Produktionsprozeß
Die zukünftige Entwicklung der Qualitätssicherung kann generell wie folgt gekennzeichnet werden:
- Die bisher im wesentlichen auf die Qualität der zu erstellenden Produkte ausgerichtete Qualitätssicherung wird in zunehmenden Maße auf die Qualitätssicherung der Produktionsprozesse ausgerichtet werden (müssen). Nur hierdurch kann sichergestellt werden, daß die erforderliche Qualität mit dem geringstmöglichen Aufwand erreicht wird. Hierzu ist insbesondere das Erfassen quantitativer Kenngrößen zum Aufwand und zum Nutzen von QS-Maßnahmen und Techniken erforderlich; die quantitativen Angaben müssen im wesentlichen aus dem Betrieb oder aus der Softwarewartung kommen, um anhand dessen zunächst Aussagen über die Qualität der Produkte zu erhalten und daraus die geeigneten Schlußfolgerungen zu ziehen.
- Es müssen mehr quantitative Kenngrößen (Maßzahlen) für die Qualitätssicherung bereitgestellt werden, um eine systematische Planung und Kontrolle der Qualität und der Qualitätssicherung sicherzustellen. Die bisher verfügbaren Maße sind zwar durchaus aussagefähig, ihr Anwendungsbereich ist allerdings auf Teilbereiche beschränkt (hier: das Testen als eine Maßnahme). Insbesondere fehlen Maße für Qualitätsmerkmale wie Benutzerfreundlichkeit oder Änderbarkeit. Auch für Merkmale wie Richtigkeit -wofür die Testmaße zwar eine Hilfsgröße sind die allerdings aus dem Prozeß resultieren und nicht direkt auf das Produkt bezogen sind - fehlen Maße, die unmittelbar zur Beurteilung der Produktqualität herangezogen werden können-vergleichbar zur Hardware oder der allgemeinen Produktion.
- Die vorhandenen Lücken im Klassifikationsraster der QS-Aktivitäten müssen geschlossen werden:
- Es müssen Standards insbesondere für die Qualitätsprodukt-Planung, die Qualitätsproduktions-Planung und die Qualitätsproduktions-Kontrolle sowie die Qualitätsprodukt-Kontrolle-zumindest in Teilbereichen zur Verfügung gestellt werden. Hier existieren zwar einige Hilfsmittel, die allerdings meist nur Teilbereiche abdecken. Standards sind insbesondere daher von Bedeutung, weil hierdurch der Rahmen für die Vorgehensweise bei der QS festgeschrieben wird. Die hierdurch erzielte Vereinheitlichung der Vorgehensweise bei der Qualitätssicherung muß ein wichtiges Ziel sein.
- Die Techniken für die Durchführung der QS müssen verbessert und ergänzt werden. Hierbei ist es nicht immer notwendig, Werkzeuge zu r Verfügung zu stellen, teilweise sind nichtautomatisierte Vorgehensweisen durchaus ausreichend; bestimmte Aktivitäten sind zunächst (Testfallermittlung) - zumindest nicht in den nächsten zwei bis drei Jahren oder überhaupt nicht (strukturierte Gruppengespräche) - automatisierbar oder durch Werkzeuge ersetzbar.
- Die Anforderungen an die Qualität von Softwaresystemen steigen aufgrund der Komplexität der in zunehmendem Maße integrierten Softwaresysteme stark an.
- Die Beteiligung der Fachabteilung bei der Festlegung der eigentlich erforderlichen Qualität muß sichergestellt werden. Dies hat zusätzlich den Vorteil, daß aufgrund der damit gegebenen Verantwortung im Nachhinein Klagen über mangelnde Anforderungen - wenn diese vorher nicht definiert waren- keinen Bestand haben. Qualitätsprodukt-Planung und Qualitätsprodukt-Kontrolle ist Anwendersache!
- Die praktische Erprobung der vorhandenen Standards (beispielsweise GI-QS-Plan) ist erforderlich um anhand dessen notwendige Erweiterungen beziehungsweise Änderungen durchführen zu können.
- Erweiterungen der Standards um eine Vielzahl von Aspekten, die sich auf die Vorgehensweise beziehen- gegenüber der vielfach vorhandenen Ergebnisdarstellungen (so GI-QS-Plan, IEEE 729, IEEE 830)-sind notwendig, da der Weg zur Erstellung der Ergebnisse die eigentliche Unterstützung darstellt.
- Es sind unternehmensspezifische QS-Systeme zu definieren, zu realisieren und einzuführen, die von der QS-Policy über die Festlegung der einzusetzenden Techniken einschließlich der organisatorischen Einbettung die Qualitätssicherung insgesamt umfassen.
- In der Softwareproduktion müssen Stellen (Qualitätssicherer, Qualitätssicherungsgruppe) geschaffen werden, die unternehmungsspezifisch das notwendige Know-how haben, um zumindest die systematische QS sicherzustellen. Der grundsätzliche Aufbau des QS-Systems kann auch unter Einschaltung von Externen erfolgen.
- Für die Einführung von neuen Techniken beziehungsweise Standards wird wegen der vorhandenen Komplexität eine Projektbetreuung durch den/die Qualitätssicherer erforderlich, um so sicherzustellen daß die Hilfsmittel auch angewendet werden.
- Die Unterstützung durch das Management ist erforderlich, um eventuell aufgrund neuer Techniken oder Standards erforderliche grundsätzliche Verschiebungen des Projektablaufs- so mehr Aufwand in den Phasen vor der DV-Realisierung - durchsetzen zu können. Insbesondere muß seitens des Management gerade bei knapper Zeit- und für welches Projekt gilt dies nicht- besonderer Wert auf die systematische Qualitätssicherung gelegt werden- sofern die Qualitätsanforderungen dies verlangen.
*Rudolf von Megen ist Geschäftsführer der SQS GmbH und Lehrbeauftragter der Universität Köln.