Software Qualität: kein Thema der Informatik?
Heute, 2015, nähert sich die Wissenschaft des Software Engineerings ihrem 50-ten Geburtstag. Viel ist in diesen fünf Jahrzehnten erreicht worden, aber hinsichtlich zweier Kernprobleme der Informatik blieb Fortschritt aus:- Die Fehlerdichte in Software — und die Notwendigkeit, Softwarefehler zu reduzieren haben sich kaum reduziert
- und auch die Hilfslosigkeit, mit der man diesem Problem gegenüber steht, ist nach wie vor gegeben.
- Schlimmer noch: Man nimmt dieses Problem heute weniger ernst als früher — man scheint sich damit abfinden zu wollen, dass Software nicht fehlerfrei sein kann. Man scheint zu ignorieren, dass uns immer mehr peinliche Vorfälle zeigen, wie gefährlich dieser Standpunkt sein kann in einer Zeit, in der unentdeckte Sicherheitslücken oder beim Test unentdeckt gebliebene logische Fehler in unternehmenskritischen Systemen schnell Schäden in bis zu 3-stelliger Millionenhöhe verursachen können.
Da es sich hierbei um eines der wichtigsten Problemfelder des Software Engineerings überhaupt handelt, frägt man sich, warum es der Informatik (als Wissenschaft) immer noch nicht gelang, wirklich durchgreifende Lösungsansätze hierfür bereitzustellen.
Hat man resigniert? Oder befasst sich die Hochschul-Informatik heute vielleicht doch zu sehr mit eher nur trivialen Dingen (so dass heute schon gelegentlich mal der Verdacht aufkommt, sie könne sich als Wissenschaft überlebt haben)?
Softwarefehler sind grundsätzlich von zweierlei Art, denn jeder solche Fehler kann sein
- ein applikationslogischer Fehler oder
- ein codierungstechnischer Fehler.
Sie zu verhindern bedarf es völlig unterschiedlicher Methodik:
- Applikationslogische Fehler zu vermeiden (oder ausreichend früh zu entdecken) bedarf es peinlich genauer, höchst detaillierter Dokumentation aller applikationslogischen Anforderungen —
genau auf die aber wird heute — im Zeiltalter sog. agiler Methodik — allzu oft in allzu hohem Ausmaß verzichtet. Das muss abgestellt werden!
- Codierungstechnische Fehler zu reduzieren hilft nur eines: Man muss erreichen, dass der Anteil von Code, der von Hand geschrieben wird, sinkt.
Dies ist deswegen so, weil einschlägige Studien zeigen, dass die Dichte codierungstechnischer Fehler pro Lines of Code (LOC) weitgehend unabhängig von der gewählten Programmiersprache ist:
Sie liegt grob um die 7 Fehler pro KLOC (genauer: sie liegt zwischen 0.5 und 15 in Abhängigkeit davon, wie ausführliche Code-Inspektion stattgefunden hat).
Ich selbst habe 30 Jahre in einem lange Zeit recht angesehenen Softwarehaus gearbeitet. Zu Code-Inspektion oder gezielt angestrebter, personenübergreifender Schematisierung von manuell produziertem Code kam es über all diese Jahre hinweg weder bei uns noch bei unseren Kunden. Ernsthafte Bemühungen in dieser Richtung gibt es wohl nur für Software, deren Versagen menschliches Leben oder extrem kostpielige Investitionen gefähren würde.
Unter dem Zwang, Systeme heute fast nur noch zum Festpreis zu entwickeln, wird sich daran auch ganz gewiss nichts ändern. Den Einkäufern ist viel zu wenig klar, dass sie neben Funktionalität auch Qualität einzukaufen haben. Wie sie letztere dingfest machen können, wissen sie nicht wirklich, und so wird der Auftragnehmer denn auch gerade hier — vom Auftraggeber meist unbemerkt — zu sparen beginnen.
Letztlich beginnt das Problem also schon damit, dass niemand kontrolliert, in welchem Ausmaß es dem Einkäufer gelang, tatsächlich auch Qualität einzukaufen.
Traurig ist:
Die Informatik (als Wissenschaft) hat bisher kaum etwas dafür getan, die Qualität neu erstellter Software über Formalien hinaus transparent zu machen. Hierzu definiert die Informatik sich einfach noch nicht ausreichend allgemein. Sie erscheint mir in vieler Hinsicht immer noch zu verspielt als dass man sie — als konkurrenzlosen Experten für Informationsverarbeitung — ernst nehmen könnte.
Über normierbare Softwarequalität aus Anwendersicht projektübergreifend nachzudenken, haben Informatiker nur kurz versucht (man denke an die Gestaltung graphischer User Interfaces).
Wo bleibt der Ehrgeiz der Wissenschaft Informatik, denn nun tatsächlich auch Schwieriges in Angriff zu nehmen?
Wenn sie das nicht versucht, könnte es gut sein, dass die erfolgreiche Entwicklung brauchbarer Programmiersprachen und Entwicklungsumgebungen später mal als ihre vielleicht einzige Glanzleistung gesehen wird.
In meinen Augen sollte mit Nachdruck versucht werden, ähnlich hartnäckig an einer Methodik zur zuverlässigen Beherrschung anwendungstechnischer Komplexität zu arbeiten. Hier aber scheint die Informatik eher zu versagen. So jedenfalls suggeriert uns der nun schon zum zweiten Mal dramatisch misslungene Versuch, das Gehaltsabrechungssystem des Staates Kalifornien auf neue Technologie zu migrieren. Selbst SAP zeigte sich mit der Aufgabe überfordert, auch nur eine Schmalversion der Anwendung — etwa 5% — erfolgreich neu zu implementieren (Details hier und hier).
stw5492IFW — Informatik . Fehler . Wissenschaft — News?
Mehr + B G E + S H A + More