Hundertprozentige Vollkommenheit eines Produktes ist, abgesehen von der Realisierbarkeit, in der Regel schon aus wirtschaftlichen Gründen für den Ersteller nicht erstrebenswert: so lautet eine der Kernaussagen der ersten Folge dieser Fortsetzungsreihe von Hermann Wertheimer. In der heutigen Fortsetzung schildert und erläutert der Autor die Abhängigkeiten der verschiedenen Qualitätssicherungsmaßnahmen (QS) samt ihrer Wirtschaftlichkeit vom jeweiligen Projekt. Was für die eine Projektkonstellation kostenmäßig durchaus vertretbar sein kann, führt bei einer anderen Konstellation möglicherweise zum wirtschaftlichen Desaster. Exakte Abstimmung der Güteprüfkriterien mit den Projektgegebenheiten ist deshalb angezeigt.
Um die jeweiligen Organisationsformen der QS beurteilen zu können, ist es notwendig, Kriterien hierfür festzulegen und diese zu operationalisieren. Die Eignung der jeweiligen Organisationsform hängt entscheidend vom jeweiligen Profil des Projektes ab, bei dem die Qualität sichergestellt werden soll. Die Erfassung eines solchen Projektprofils kann durch Untersuchung einer Reihe hierfür relevanter Faktoren erfolgen.
Diese lassen sich unterteilen nach unmittelbar projektabhängigen Faktoren, der Qualifikation der Projektmitarbeiter und Qualitätssicherer und dem wirtschaftlichen Risiko. Einzelne Indikatoren der jeweiligen Faktoren beeinflussen nicht nur diese, sondern auch andere, so daß eine eindeutige Zuordnung der einzelnen Indikatoren zu den jeweiligen Faktoren nicht möglich ist. Im Folgenden sollen nun die Gegebenheiten, die die Wahl der geeigneten Organisationsform der QS entscheidend beeinflussen, zum Teil anhand von Indikatoren erläutert und operationalisiert werden.
Solche unmittelbar projektabhängigen Faktoren sind etwa der Projektumfang, die Komplexität des Projektes und die Qualität des Projektes.
Leistungsbeschreibung ist maßgebend
Hinweise für den Projektumfang und etwa die Anzahl der unterschiedlichen Datenelemente (Ausprägung zum Beispiel 100 - 500, 501 - 2000, >2000), die Zahl der zu verwaltenden Datensätze (zum Beispiel 100 000 - 1 Million, >1 Million), sowie die Anzahl der unterschiedlichen Eingabedaten (zum Beispiel 20 - 40, 41 - 100, >100). Angaben zu diesen Indikatoren müssen in der Leistungsbeschreibung ausgeführt sein.
Die Komplexität eines Projektes ist besonders durch die Anforderungen der (des) Nutzer(s) an die Flexibilität des Programmes, sowie durch die Anzahl der zu bearbeitenden und vor allem zu integrierenden Fachgebiete bestimmt. Es ist zu klären, ob ein neuartiger Lösungsansatz oder ein neues Modell für die Lösung der fachlichen und/oder technischen Probleme (Echtzeitbetrieb, Mehrrechnersteuerung) entwickelt werden muß oder ob die Anforderungen des Nutzers hinreichend konkretisiert sind, so daß auf bereits vorhandene Lösungen zurückgegriffen werden kann.
Die Komplexität eines Produktes beschränkt sich jedoch nicht nur auf dessen technische Seite, sondern ist auf der organisatorischen ebenso relevant: so ist hier weiter zu untersuchen, wieviele verschiedene Stellen an einem Projekt beteiligt sind und ob Transparenz und eine reibungslose Kommunikation zwischen Entwicklungspersonal und Management besteht. Diese Indikatoren beeinflussen auch die Produktivität eines Projektes.
Bei der Untersuchung der projektspezifischen Qualität sind die verschiedenen Arten der SW zu unterscheiden. Davon ausgehend ist zu untersuchen wieviele Einsätze für das zu entwickelnde Produkt bereits vorgesehen oder zu erwarten sind, weil dies das Ausmaß durchzuführender QS-Aktivitäten wesentlich determiniert.
Ferner ist zu überprüfen, ob und wie (schriftlich?) Requirements und entsprechende Qualitätsmerkmale festgelegt wurden. Ebenfalls sollte gescheckt werden, ob Fremdsoftware zugekauft werden muß, weil gerade dann eine sorgfältige Überprüfung der Qualität dieses Teiles sowie der Schnittstellen zu den eigenerstellten Teilen notwendig wird. Darüberhinaus können während der Projekterstellung (am Ende einer Prüfung) Kennzahlen zu einzelnen Qualitätsmerkmalen gebildet werden (Performance, Laufzeit).
Während des Einsatzes ist eine Beurteilung der Q-Aktivitäten, am Ende der Lebensdauer eine Beurteilung der Gesamtqualität eines Produktes zu Vergleichszwecken möglich.
Weiterhin ist die Einsatzdauer eines Produktes (Software Life Cycle) für die Qualität von großer Bedeutung: soll das Produkt später als relativ kurzfristige Problemlösung dienen, ist die Anforderung an dessen Qualität sicherlich nicht so hoch wie bei einer geplanten Verwendung auf unbestimmte Zeit (geplante Einsatzdauer: <1J, 1 - 4J, 5 - 10, >10J).
In diesem Zusammenhang ist auch die Frage nach der Zahl der zu erwartenden Anwender relevant: für den Entwickler ist es oft kostengünstiger, bei eventuell auftretenden Fehlern direkt zu den wenigen oder diesem einen Anwender zu gehen und diese Fehler zu beheben, als ein so gut wie fehlerfreies Produkt zu entwickeln. Ist die Zahl der Anwender dagegen groß, werden einerseits mehr in einem Produkt enthaltene Fehler entdeckt, andererseits ist eine Behebung dieser vor Ort aufgrund der großen Anwenderzahl sehr unwirtschaftlich.
MA müssen DV-Architektur beherrschen
Der Wissensstand der Mitarbeiter und der Qualitätsprüfer ist für den Fortgang des Projektes sowie für Produktivitätsüberlegungen relevant. Hierfür ist projektabhängig zu klären, welche Zeit ein Programmierer zum Erlernen der Schnittstellen, die in der Leistungsbeschreibung festgelegt wurden, benötigt; ebenso, wie groß seine Kenntnisse über die hauptsächlich verwendete Programmiersprache sind; oder ob die Probleme der zu bearbeitenden Fachgebiete und der DV-Architektur von den Projektmitarbeitern beherrscht werden.
Wie der Wissensstand ist auch der Erfahrungsstand der Projektmitarbeiter im Hinblick auf die Produktivität von Wichtigkeit. Es kann eine langjährige Programmiererfahrung notwendig sein oder praktische Erfahrung mit den im Projekt vorgesehenen Werkzeugen und/oder Problemstellungen.
Projektkosten nicht zuverlässig schätzbar
Das wirtschaftliche Risiko läßt sich nach den Faktoren Kosteneinhaltung, Termintreue und Produktivität beurteilen.
Von diesen Faktoren sind die Kosten und Termine durch Plangrößen vorzugeben. Die zu Projektbeginn vorgegebenen Sollwerte dienen nach Abschluß des Projektes als Vergleichsgrundlage.
Ausgehend von der Unterteilung der Kosten in Entwicklungs- und Wartungskosten und der Entwicklungskosten weiter in Kosten des Entwurfes, Kosten der Codierung und Kosten des Testens und Prüfens, wird deutlich, daß in der Regel diese mit zunehmender Qualität steigen. Dies ist bedingt durch eine Erhöhung der Kosten für den Entwurf sowie für Prüfungen.
Andererseits sinken hierdurch die Kosten für Codierung und Testen unter Umständen erheblich, so daß sich ein Maximierungsproblem mit Nebenbedingung ergibt. Doch zu Projektbeginn müssen die Kosten erst einmal geschätzt werden. Bisher ist es noch nicht gelungen, diese zuverlässig abschätzen zu können.
In dem Buch "Software Engineering Economics" durchleuchtet Boehm diese Probleme ausführlich. Es wird phasenabhängig ein Bereich angegeben, innerhalb dessen die später entstehenden realen Kosten in 80 Prozent der Fälle liegen werden.
Hierbei wird von einem relativen Kostenbereich ausgegangen. Dies geschieht dadurch, daß, abhängig vom Stand des Projektes, ein Faktor angegeben wird, der ein Maß für die Genauigkeit der Kostenschätzung zu diesem Zeitpunkt darstellt. Für die Phase der Projektidee (Nutzerforderungen, bei Boehm mit "Feasibility" bezeichnet) wird ein Faktor vier nach oben und nach unten angegeben; die geschätzten Entwicklungskosten können das Vierfache oder aber nur ein Viertel der realen Entwicklungskosten sein. Eine solche Schätzung kann zu diesem Zeitpunkt, bei realen Entwicklungskosten von 100 000 Mark, im Bereich 25 000 bis 400 000 Mark liegen. Selbst nach der Phase der Entwurfs-Spezifikation wird noch der Faktor 1,25 nach oben und unten angegeben.
Die Wartungskosten treten in Form von Gewährleistungskosten und Fehlerbeseitungskosten auf und schmälern dadurch den Gewinn. Es ist ein unmittelbarer Zusammenhang zwischen der Qualität (Zuverlässigkeit, Änderbarkeit) und der Höhe der Wartungskosten einerseits sowie der Zahl der Anwender eines Produktes andererseits erkennbar: Je höher die Qualität ist, desto niedriger sind die Wartungskosten.
Hohe Qualität - wenig Wartung
Dies läßt sich dadurch erklären, daß bei höherer Qualität weniger Fehler auftreten, die zu beheben sind. Anpassungen des Produktes an ein anderes System oder Änderungen können durch veränderte Ablaufbedingungen leichter durchgeführt werden.
Dagegen steigen die Wartungskosten, wenn sich die Zahl der User erhöht, weil es kein fehlerfreies Programm gibt und mehr Nutzer mehr Fehler entdecken. Neueste Untersuchungen lassen jedoch keinen Zusammenhang mehr zwischen Fehlereingang und Anzahl der Nutzer erkennen, wenn die Zahl der Nutzer 100 übersteigt.
Für die Termine ist die Einhaltung der geplanten Entwicklungsdauer von entscheidender Bedeutung. Konsequenzen bei Terminüberschreibung sind spätere Bezahlung, also Zinsentgang, desweiteren - insbesondere bei großen Projekten - Konventionalstrafen. Beide schmälern den geplanten Gewinn.
Einerseits werden sich umfangreiche QS-Aktivitäten gerade in der Entwurfsphase zeitverzögernd bemerkbar machen, andererseits ist eine Zeitverkürzung im Hinblick auf den Projekteinsatz gerade durch solche Maßnahmen feststellbar. Dies ist auf eine bessere theoretische Durchdringung und Strukturierung der Aufgabe von Anfang an zurückzuführen.
Bei der Beurteilung der Produktivität ist ebenso wie bei der der Qualität die Art der SW zu unterscheiden, weil nur die Produktivität bei gleichartigen Programmen sinnvoll verglichen werden kann. Grundsätzlich ist nur eine Ex-post-Beurteilung möglich. Anhaltspunkte bei der Produktivitätsplanung können Vergleiche des zu entwickelnden Projektes mit anderen, profilähnlichen Projekten aus der Vergangenheit liefern.
Einen weiteren, allerdings etwas vagen Anhaltspunkt kann die Kennzahl "Anzahl der Anweisungen (Lines Of Code, LOC) je Programmierer je Zeiteinheit" liefern. Hierbei ist jedoch die verwendete Programmiersprache und der jeweilige Arbeitsumfang zu berücksichtigen.
Bisher gibt es kein allgemein verwendetes und sinnvolles Maß für die Produktivität der Software-Entwicklung. Die Beurteilung der Gesamtproduktivität am Ende der Lebensdauer eines Produktes zu Vergleichszwecken ist jedoch möglich.
Es sei noch darauf hingewiesen, daß die angegebenen Ausprägungen der Faktoren als Anhaltspunkt für die Beurteilung der jeweiligen Organisationsform zu betrachten sind. Sie sind subjektiv nach den oben angeführten Überlegungen ausgewählt worden; eine exakte Abgrenzung der einzelnen Ausprägungen (klein, mittel, groß; oder: niedrig, durchschnittlich, hoch) ist nicht möglich.
Die beiden Spalten Kosten- und Termineinhaltung lassen sich mittelbar durch eine Qualitätskostenbetrachtung mit den jeweiligen Organisationsformen eines QS-Systems in Beziehung setzen.
* Hermann Wertheimer ist Cand. rer. nat. an der Ludwig-Maximilians-Universität, München.
Literaturverzeichnis:
1. Boehm, B. W. (Economics, 1981), Software Engineering Economics, Englewood Cliffs, 1981.
2. Boehm, B. W.; McClean, R. K.; Urfrig, D. B. (Experience, 1975), Some Experience with Automated Aides to the Design of Large-scale Reliable Software, in: IEEE, Transaction on Software Engineering SE-1, 1975,S. 125 - 133.
3. DIN 55 350 (Entwurf, 1979), Begriffe der Qualitätssicherung und Statistik, Teil 11, Entwurf, Berlin, Köln, 1979.
4. Juran J. M.; Gryna, F. M. (Planning, 1980), Quality Planning And Analysis, New York, 1980.
5. Schnupp, P.; Floyd, C. (Programmentwicklung, 1976).