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.

22.10.1982 - 

Qualität muß in die Software hineinentwickelt werden (Folge 2):

QS und Engineering Hand in Hand

Viele Software-Entwickler haben zur Zeit noch das Gefühl, daß sich die Qualitätssicherung nicht dem Software-Engineering dazugesellt, sondern vielmehr aufgedrängt habe. Ist die Qualitätssicherung (QS) ein zusätzlicher Baustein mehr im Verwirrspiel Software? Ein Kostenfaktor mehr? Hierzu kann die QS leicht generieren, wenn man die Disziplin sich selbst überläßt in der frohen Erwartung, Erträge und Arger im Softwaregeschäft allein durch die Beauftragung der Qualitätsüberprüfung optimiert zu haben.

Die Software war vor rund 15 Jahren eine kleine Beigabe, die man großzügig übersehen konnte. Schnell begann sie zu wuchern und hat der reinen Elektronik Funktion um Funktion abgenommen.

Plötzlich stand man vor der Situation, daß die Hardware nur noch Medium für das komplexe Gebilde eines Systems war. Daß deren Überprüfung und Abnahme noch so gut durchgeführt werden kann, ist für die Gesamtfunktion nicht mehr von entscheidender Bedeutung. Hier liegt eine ernsthafte Herausforderung für die Qualitätssicherung.

So mancher Qualitätsmann, der genau seine Elektronikprozeduren kannte, wurde aufgrund seiner bisherigen Leistungen über Nacht zum SW-Qualitätssicherer. Er hat bald gespurt, daß es mit den Analogien höchstens formal paßt, daß aber die SW-Entstehung und der SW-Betrieb ganz andere Gesetze haben, mehr dem Schreiben und Herausgeben eines Buches entsprechen, als der Herstellung eines Produktes. Das hat sich übrigens inzwischen auch in der Rechtssprechung manifestiert (Copyright statt Patent). Die Fertigung von Software ist ein schlichtes Kopieren und unproblematisch. Die Zuverlässigkeit von Software kann man zwar genauso messen wie die Hardware-Zuverlässigkeit, aber die Fehler sind von völlig anderer Natur. Hardwarefehler entstehen durch Alterung, Bauteilschwächen, sind also Ausfälle eines bestimmten, reproduzierten Individuums. Solche Fehler gibt es bei der Software prinzipiell nicht. SW-Fehler sind hier zu vergleichen mit Irrtümern im Hardware-Entwurf. Auch sie können im Einsatz noch auftreten, nur ist die Bedeutung dieser Fehler untergeordnet. Das liegt an der wesentlich geringeren Komplexität der Hardware. Das asymptotische Abklingen dieser Fehlerrate ist meist schon in der Erprobung sehr weit vorangeschritten.

Damit haben wir auch gleich das Problem des derzeitigen Softwarelebenszyklus aufgegriffen. Mangels geeigneter Methoden der Erkennung von Fehlern schon während Entwicklung und Erprobung wird der Hauptanteil der Fehlerkurve auf den Anwender verschoben. Mangelhafte Vorgehensweisen bei der Fehlerbehebung, also bei der Wartung, erzeugen statt Fehlerverringerung häufig Folgefehler - ein Januskopf, der viel zu oft ein Gewährleistungs- und damit Kostendebakel für eine Firma bewirkt. Abgesehen davon, daß das Vertrauen des Kunden in die Leistungsfähigkeit und Qualität des teuer erkauften Produkts dahin ist, wird eine weitere Akquisition äußerst erschwert. Überlagert wird das Problem noch dadurch, daß die Zuverlässigkeit, also die Fehlerfreiheit ganz und gar nicht das einzige Merkmal einer hohen Softwarequalität ist. Benutzbarkeit, Sicherheit, Effizienz oder die Portabilität sind Eigenschaften, die nicht ohne weiteres ihr Hardware-Analogon haben.

Was der Software bisher fehlt, ist die ingenieurmäßige Vorgehensweise. Und diese Vorgehensweise ist in allen Gebieten, nicht nur in der Elektronik, ein Miteinander von Erstellungsmethoden und Ergebnisprüfung. In diesem Sinne ist das Software-Engineering, das deutlich an Gestalt gewinnt, eine der beiden Komponenten. Aber eben nur eine. "Qualität kann man nicht in ein Produkt hineinprüfen, man muß sie hineinentwickeln", dieser Grundsatz stammt meines Wissens sogar aus der Qualitätssicherung. Was aber nicht heißt, daß man das Ergebnis nicht zu überprüfen braucht.

Es ist offensichtlich, daß Engineering-Methoden die Qualität verbessern, aber diese rein qualitative Aussage reicht heute nicht mehr aus. Aus wirtschaftlicher Sicht und aus systemtechnischer Sicht muß die Qualität quantifiziert werden. Man kann nicht bei jeder Software beliebig viel Qualitätsaufwand treiben und konkurrenzfähig bleiben. Und bei Systemaufgaben, in denen Fehler hohe Sachwerte oder sogar Menschenleben gefährden, kann die Aussage, daß das System "sehr zuverlässig" ist, keinesfalls ausreichen. Dies werden die eigentlichen Aufgaben der Software-Qualitätssicherung sein. Die Methoden hierfür sind allenfalls in ihren Grundzügen zu erkennen, der Rahmen, in dem sie abfaulen werden, ist bekannt. Viel mehr nicht.

Wie ist der derzeitige Stand?

Schon erwähnt ist das Phasenkonzept. Am Ende dieser Phasen müssen , die Kontrolle und Freigabe durch die Qualitätssicherung stehen. Charakterisieren wir kurz die Phasen:

- In der Anforderung müssen möglichst qualifiziert die Funktion des zu entwickelnden Systems und die Randbedingungen (HW und SW) festgelegt werden. Darüber hinaus ist es essentiell, daß auch die geforderten Nachweisverfahren beschrieben werden, als Maß für die letztliche Überprüfung des Endergebnisses. Im Hinblick auf das vorher Gesagte sollten auch die geforderten Qualitätsmerkmale beschrieben, quantifiziert und gewichtet sein. Auch wenn man heute noch über keine ausgereifte Möglichkeit der Qualitätsmessung verfügt.

- In der Entwurfsphase wird nach vorgegebenen Regeln die Anforderung umgesetzt. Sie ist meistens zweigeteilt; der sogenannte Grobentwurf zergliedert die Gesamtaufgabe in Moduln, im Feinentwurf werden die Moduln selbst bearbeitet. Die wesentliche Rolle der SW-QS in dieser wohl wichtigsten Phase ist die Überprüfung des Entwurfs auf Vollständigkeit, Konsistenz, auf Einhaltung der Entwurfsregeln und auf Erfüllung der Qualitätsmerkmale.

- Die Realisierungsphase besteht aus der eigentlichen Codierung, die nur noch ein Umsetzen des Feinentwurfs ist und aus dem Test der Moduln. Überprüft wird hier die Stimmigkeit des Codes zum Feinentwurf die Einhaltung der Codierregeln (insbesondere die Dokumentierung des Codes) und die Funktionserfüllung der Moduln.

- Die SW-Integration schließlich führt zum Endprodukt. (Bei Prozeßsystemen folgt dann natürlich die HW-/SW-Integration zum ganzen System. Dies wird schließlich als Gesamtes auf Erfüllung der Anforderungen überprüft.)

- Im SW-Betrieb ist die Aufgabe der SW-QS die Ausführung aller dieser Maßnahmen bezüglich durchgeführter Änderungen.

Es ist hier nicht der Platz und nicht das Thema, die einzelnen Engineering-Methoden und die Phaseneinteilung ausführlich zu diskutieren. Wir haben nur einen Rahmen vorgegeben, um uns im folgenden darauf beziehen zu können. Es gibt viele graduelle Unterschiede bei den verschiedenen Autoren; an der Essenz dieses Konzeptes besteht jedoch weltweit kein Zweifel mehr.

Es liegt nahe, die Vorgehensweisen in den einzelnen Phasen rechnergestützt zu kontrollieren. Dies ist das Ziel vieler neuer Entwicklungstools. Beispiele solcher umfassender Tools, die derzeit auf den Markt kommen, sind Epos von der Uni Stuttgart Plasma von Triumph-Adler, gefördert vom BMFT, PSL/PSA aus den USA, Sadt, ebenfalls aus den USA, ursprünglich ein rein manuelles Verfahren oder Boie von PSI, Berlin.

Gemeinsam ist diesen Systemen, daß sie die wesentlichen Regeln für eine vollständige SW-Anforderung, für den strukturierten Entwurf bis hin zur Codierung unterstützen, in dem sie dem Entwickler keine Chance lassen, andersartig vorzugehen. Unterschiede bestehen hauptsächlich in der Anwendungsorientierung und in der derzeitigen Realisierung.

Es handelt sich hier um echte Engineering-Tools, die Überprüfungen nehmen einen gewissen Raum ein, so wird zum Beispiel bei Epos überprüft, ob die Anforderungen im Entwurf alle berücksichtigt sind, in einem gewissen Sinne auch, ob der Entwurf konsistent ist. Auf die Qualitätssicherung in der Augabe der möglichst quantitativen Messung des Ergebnisses wird jedoch kaum reflektiert. Dafür ist dieses Thema einfach noch zu jung. Wir werden feststellen müssen was man im einzelnen trotzdem heute schon tun kann. An dieser Stelle sei noch ein kleiner Ausblick in die fernere Zukunft gestattet, natürlich auch aus der Sicht der für die Qualität Verantwortlichen. Gemeint ist die Software der vierten Generation.

Bestehende Idee

Es ist schon eine bestechende Idee mit ganzen vier Befehlen rein anwendungsbezogen sein Problem zu formulieren, ohne Spezialkenntnisse. Aber wird man dem Ergebnis trauen können, wie wird man vor allem mit sicherheitskritischen Aspekten fertig, wie löst solch ein System die Problematik konkurrierender Qualitätsmerkmale (zum Beispiel Speichereffizienz und Laufzeiteffizienz). Für die Qualitätssicherer lohnt es sich nicht, auf diese Generation zu warten. Erstens wird es noch lange dauern und viel SW zu produzieren geben, bis man eine breite Anwendung realisiert haben wird. Und zweitens werden sich die Aufgaben der QS verlagern, schwieriger werden, mehr Grundsatzarbeit fordern. Hier besonders muß man in der Gegenwart leben, um vorab die nahe Zukunft einigermaßen zu bewältigen. Es gibt viel zu tun . . . (Sie wissen schon, wie der Satz weitergeht.)

Friedrich Haugg ist als Diplom-Mathematiker bei MBB in Ottobrunn in der SW-Qualitätssicherung tätig.