Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

30.04.1982 - 

Viele glauben, im Systemtest alle Datenkonstellationen zu berücksichtigen (Teil IV, Schluß):

Softwarequalität darf kein Zufallsprodukt sein

Softwarequalität ist ein Problembereich, der gerade in der letzten Zeit zunehmend an Interesse und Beachtung in der Praxis gewonnen hat. Der Zustand, daß Softwarequalität weder geplant noch gemessen oder grob beurteilt wird, ist für die Zukunft nicht akzeptabel. Die Planung der Softwarequalität und der hierfür geeigneten Maßnahmen sowie die Kontrolle der Softwarequalität sind notwendige Voraussetzungen für eine Verbesserung der gegenwärtigen Situation. Nachdem in den Teilen 1 und 2 dieser Serie generelle, im Zusammenhang mit der Qualität von Software stehende Aspekte und im Teil 3 das Testen als eine analytische Maßnahme angesprochen wurden, wird in diesem letzten Teil unter anderem auf die Operationalisierung der Planung und Kontrolle der Qualität von Software eingegangen: darüber hinaus sind zielgruppenbezogen - für Projektleiter, Entwickler und Anwender/Fachabteilungen - checklistenartig Fragen aufgeführt, anhand derer dem Leser eine erste Möglichkeit zur Beurteilung der Situation der Qualitätssicherung im eigenen Bereich gegeben wird.

Aus den vorangegangenen Ausführungen dürfte deutlich geworden sein, daß Softwarequalität nichts ist, was ein Softwareprodukt (Zwischen- oder Endprodukt) entweder hat oder nicht hat. Vielmehr ist es so, daß die Softwarequalität nach der Definition der Qualitätsanforderungen durch gewissenhafte und detaillierte Planung der Maßnahmen, die zur Erreichung der angestrebten Qualität geeignet sind, sichergestellt werden muß. Von gleicher Bedeutung ist die Kontrolle der erreichten Qualität.

Zentrale Kenngröße der Planung und Kontrolle sind die Qualitätsmaße. Qualitätsmaße stellen objektive, meßbare Größen dar, die "sensitiv in bezug auf unterschiedliche Ausprägungen eines oder mehrerer Qualitätsmerkmale" sind. Qualitätsmaße dienen der qualitativen Bewertung von Software-Zwischen- und -Endprodukten; sie bringen den Berechnungsalgorithmus, nicht aber die Höhe der erreichten Werte zum Ausdruck. So ist etwa der Quotient "Anzahl ausgeführter Moduln" zu "Anzahl vorhandener Moduln" ein Qualitätsmaß, während der für ein konkretes Softwareprodukt ermittelte tatsächliche Wert die Qualitätsmaßzahl darstellt. Der angestrebte Wert eines Qualitätsmaßes wird als Qualitätsziel bezeichnet (siehe Abbildung).

Qualitätsziele sind meßbare Größen, die von dem Projektverantwortlichen (Projektleiter) für das zu entwickelnde Softwareprodukt vorgegeben werden, und bei deren Erreichen die Qualität als hinreichend betrachtet wird. Anhand der Qualitätsziele sind die - konstruktiven und analytischen - Maßnahmen festzulegen, die geeignet sind, die Qualitätsziele zu erreichen.

Während der Durchführung und als Aufgabe der Kontrolle werden die Qualitätmaßzahlen bestimmt, die den Qualitätszielen gegenübergestellt werden und anhand derer über die Freigabe oder Abnahme oder die Notwendigkeit von Korrekturmaßnahmen bei Nichterreichen der Qualitätsziele entschieden wird. Die Qualitätsmaßzahlen sind die zentralen Bestimmungsfaktoren für die Freigabe oder Abnahme im Software-Entwicklungsprozeß. Sie beziehen sich nicht nur auf Endprodukte, sondern können ebenfalls für die Freigabe oder Abnahme von Zwischenprodukten herangezogen werden.

Die Problematik der Verwendung von Qualitätsmaßnahmen als Planungs- und Kontrollgrößen im Software-Lebenszyklus ist zu einem großen Teil dadurch bedingt, daß einerseits die für die einzelnen Qualitätsmerkmale vorhandenen Qualitätsmaße nicht allgemein verbreitet, bekannt oder anerkannt sind, und andererseits eine mangelnde Akzeptanz bezüglich der Verwendung von Qualitätsmaßen in der Praxis festzustellen ist.

Die mangelnde Kenntnis von Qualitätsmaßen drückt sich etwa darin aus, daß bisher primär programmorientierte Testabdeckungsmaße sich wenn auch nicht durchgesetzt, so doch Eingang in das Bewußtsein von Entwicklern gefunden haben. Darüber hinaus sind teilweise Komplexitätsmaße (so das Halstead-Maß) oder Testergebnismaße (Beispiel: Mean Time Between Failure) in der Diskussion; hierdurch werden jedoch in keiner Weise sämtliche Qualitätsmerkmale zieladäquat zum Ausdruck gebracht. In diesem Bereich ergibt sich aus der jetzigen Sicht ein erhebliches Know-how-Defizit bei den Softwareentwicklern.

Die wichtigste Voraussetzung ist die Kenntnis und Akzeptanz von Qualitätsmaßen. Verschiedene Analysen der Vorgehensweise in der Praxis, die von den Autoren durchgeführt wurden, haben gezeigt, daß Qualitätsmaße im Sinne objektiv meßbarer Größen nicht oder nur in wenigen Fällen angewendet werden. Bezogen auf das Testen ergab sich etwa, daß lediglich globale Qualitätsmerkmale wie "Testen aller praktisch relevanten Pfade, Aufgaben oder Funktionen" formuliert werden.

Daneben ist vielfach eine mangelhafte Einschätzung der Zielerreichung festzustellen. So wurde von rund der Hälfte der Befragten einer Informationsveranstaltung (Veranstaltung mit kombinierter Wissensvermittlung und Befragung) angegeben, sie gingen davon aus, daß auch bei nichtvorhandenen systematischen Verfahren zur Testfallermittlung zwischen 75 Prozent und 99 Prozent der vorhandenen Programmverzweigungen sowie der Programmpfade ausgeführt würden.

Im Rahmen einer anderen Untersuchung zeigte es sich, daß bei der Frage zur Anwendung von Testzielen für den Modul- und Systemtest von einem hohen Prozentsatz der befragten Institutionen unrealistische Angaben gemacht wurden (so gaben beispielsweise 60 Prozent der Befragten an, im Systemtest ein Programm mit allen theoretisch möglichen Datenkonstellationen auszuführen). Diese Ergebnisse zeigen, daß das theoretisch Sinnvolle und praktisch Machbare in der Meinung der Praxis (heute noch) teilweise recht wirklichkeitsfremd eingeschätzt wird.

Umdenken erforderlich

Das Bewußtsein, daß die augenblickliche Situation unbefriedigend ist, zeigt sich beispielsweise darin, daß nur etwa 10 Prozent der Befragten an der Informationsveranstaltung keine Verbesserungsmöglichkeit sahen, während 80 Prozent sich dafür aussprachen (bei etwa 10 Prozent Enthaltungen), im praktischen Testen quantifizierbare Testziele vorzugeben und entsprechende Testmaßzahlen zu verwenden.

Die Notwendigkeit, in bezug auf die Objektivierung und Quantifizierung der Qualität von Softwareprodukten etwas zu tun, wird in der Praxis durchaus gesehen. Bisher scheitert der Schritt, dieses Bewußtsein in die Tat umzusetzen, im allgemeinen daran, daß hohe/höhere Softwarequalität zwar als erstrebenswertes Ziel angesehen wird, aber - wie in nahezu allen Softwareprojekten - die durch Kosten und Zeit gegebenen Restriktionen vielfach hemmend wirken. Hierbei wird allerdings - bewußt oder unbewußt - übersehen, daß höhere Qualität zwar höhere Kosten während der Softwareentwicklung verursachen kann, diese jedoch durch geringere Kosten während des Einsatzes und in der Wartung im allgemeinen mehr als ausgeglichen werden. Diese Tatsache wird so lange keine Berücksichtigung bei der Durchführung von Softwareprojekten finden, wie zunächst einmal die Kosten und die Zeit während der Softwareentwicklung im Vordergrund stehen, und nicht die Gesamtkosten im Software-Lebenszyklus beziehungsweise die Lebensdauer.

Kritische Analyse der eigenen Vorgehensweise

Der vorliegende Bericht sollte einen Überblick über einige wesentliche Aspekte der Qualität und der Qualitätssicherung vermitteln. Abschließend sind einige Fragen aufgeführt, die dem Leser eine erste Möglichkeit geben, die Situation in der eigenen Softwareentwicklung kritisch zu analysieren.

Beantworten Sie jede entsprechend Ihrer Funktion in Softwareprojekten - für Sie relevante Frage vollständig und mit gutem Gewissen. Machen Sie sich die Mühe, zur Beantwortung der Fragen auch noch einmal den einen oder anderen Abschnitt dieses Berichts nachzulesen.

Wenn Sie in den beiden rechten Spalten eines oder mehrere Kreuze stehen haben, ist es dringend erforderlich, für die Qualitätssicherung etwas zu tun. Sofern Sie bei Fragen Zweifel hatten, sollten Sie ebenfalls Ihr derzeitiges Konzept der Qualitätssicherung kritisch prüfen.

*Dipl.-Kfm. Heinz Bons und Dipl.-Kfm. Rudolf van Megen sind als Unternehmensberater auf dem Gebiet der Software-Qualitatssicherung (generell) und des Software-Tests (speziell) tätig. Die Büroanschrift lautet: Universitätsstr. 79, 5000 Köln 41, Tel.: 02 21/40 20 97.