Suchen

ESE Management Summit 2015 Gute Software ist machbar!

| Redakteur: Franz Graser

Softwarequalität ist kein unerreichbares Ideal. Davon überzeugte Professor Dr. Jochen Ludewig von der Universität Stuttgart die Zuhörer beim ESE Management Summit in Würzburg.

Firma zum Thema

Professor Jochen Ludewig hielt den Eröffnungsvortrag beim ESE Management Summit in Würzburg. In seinem Referat ging er darauf ein, dass der Preis für schlechte Software-Qualität im Embedded-Umfeld sehr häufig in sichtbaren oder schleichenden Katastrophen besteht.
Professor Jochen Ludewig hielt den Eröffnungsvortrag beim ESE Management Summit in Würzburg. In seinem Referat ging er darauf ein, dass der Preis für schlechte Software-Qualität im Embedded-Umfeld sehr häufig in sichtbaren oder schleichenden Katastrophen besteht.
(Bild: Universität Stuttgart)

Was hat der Besuch einer Opernaufführung von Mozarts „Cosi fan tutte“ mit einem Embedded-Softwareprojekt zu tun? Der emeritierte Professor Jochen Ludewig von der Universität Stuttgart erläutert, dass für einen erfolgreichen Opernbesuch verschiedene Vorbedingungen zu ermitteln sind.

Diese wären: „Man muss feststellen, wann die Oper gespielt wird, man muss sich rechtzeitig die Karten und bezahlen, man muss sich pünktlich (und im Besitz der Karten) im Opernhaus einfinden und man sollte dabei in leidlich guter Verfassung sein. Dann steht dem Operngenuss nichts im Wege.“

Wenn man sich nun aber ohne Karte und mit 39 Grad Fieber zur falschen Uhrzeit am falschen Theaterhaus einfindet, dann wird der Plan des Kunstgenusses nicht aufgehen, sagt Ludewig: „Das war dann aber keine Panne! Das war planvolles Versagen!“, schreibt er den verhinderten Opernfreunden ins Stammbuch.

Ähnlich ist es auch bei der Softwarequalität, so Ludewig. All zu häufig werde von einer Panne gesprochen, wo planvolles Versagen mit im Spiel war – zum Beispiel, wenn die Kostenschätzung völlig daneben lag, Kollege A über die Änderungen des Kollegen B nicht informiert war, ein eigentlich behobener Fehler in einem neuen Release wieder auftritt oder die Software kaum wartbar ist.

„Was Sie sehen, sind direkte und absehbare Folgen der Organisation und Technik, mit denen die Software entwickelt und bearbeitet wurde“, so Ludewig. Das Wort Panne werde oft benutzt, wenn man sehenden Auges in ein Problem hineingelaufen sei. Ludewig nannte etwa das Beispiel, dass man mit einer Planung, an die man von Beginn an nicht geglaubt habe, in ein Projekt hineingegangen sei.

Der emeritierte Professor warnte unter anderem vor falschen oder oberflächlichen Qualitätsbekenntnissen. Commitments zur Qualität seien oft Lippenbekenntnisse, die man wie Modeschmuck trage („Natürlich ist man für Softwarequalität wie für Eier aus Bodenhaltung“). Andere trügen die Softwarequalität wie eine Monstranz vor sich her, die aber nach der Prozession wieder in der Krypta verschwinde, weil sie für den Alltag viel zu schade sei. Wieder andere – vor allem Vertreter bestimmter Institutionen – behaupteten von sich, dass die die Softwarequalität an sich verkörperten.

Video zum Thema: Keynote Prof. Dr. Ludwig auf dem ESE Kongress 2014

All diesen Gruppen, die die Softwarequalität in dieser oder einer anderen Form verehrten, rief Ludewig zu: „Verlassen Sie den vertrauten Holzweg!“

Qualitätsmodelle helfen, Qualität zu messen

Im Weiteren ging der Softwareexperte auf den Qualitätsbegriff an sich ein. Neben einer sogenannten transzendenten – also nicht messbaren – Qualität, der zum Beispiel einem guten Steak innewohnt, gibt es die modellierte Qualität – also ein Modell, das anhand einer Sammlung vergleichbarer Merkmale ein Qualitätsurteil erlaubt.

Dieser Begriff der Qualität könne sich auf den Entwicklungsprozess, das Produkt, die Qualität aus Benutzersicht und die Qualität aus Sicht des Bearbeiters – also die Wartungsqualität – beziehen. Alle Aspekte lassen sich laut Ludewig differenzieren und weiter auffächern, um zu einem detaillierten Modell zu kommen.

Ein solches Modell könne einerseits dem Verfasser einer Softwarespezifikation ermöglichen, die für das jeweilige Projekt besonders wichtigen Qualitätsaspekte zu priorisieren. Andererseits sei es damit möglich, die Augen aller Beteiligten für das Qualitätsproblem zu öffnen.

Softwarequalität ist nicht nur eine Sache der Tester

Ganz eindringlich warnte Ludewig davor, die Softwarequalität nur den Testern zu überlassen, auch wenn man die Testabteilung beschönigend als „Qualitätssicherung“ bezeichne.: „Qualität lässt sich nicht in die Software hineinprüfen oder hineintesten. Ein Haus, dessen Architekltur falsch ist und das aus minderwertigem Material gebaut ist, kann nicht gerettet werden. Da hilft nur der Abriss“, so der Professor.

Stattdessen plädierte Ludewig für aktives Software-Qualitätsmanagement. Dessen Kosten seien durchaus plan- und kalkulierbar. Allerdings würden diese Aufgaben häufig von Management als unproduktiv angesehen und seien deshalb von Einsparungen bedroht.

Am Software-Qualitätsmanagement zu sparen, werde aber im Endeffekt fast immer deutlich teurer. Es gebe nämlich zwei Zahlungsmodalitäten – zum einen als spektakuläre Katastrophe wie den Fehlstart der Ariane 5 im Jahr 1996 oder die schleichenden Katastrophen. Fast immer würden diese schleichenden Katastrophen durch unklare Zielsetzungen, unbestimmte Anforderungen, unrealistische Terminvorgaben, Versäumnisse im Projektablauf und mangelnde Transparenz im Projekt begünstigt.

Abschließend sagte Ludewig, dass man bei der Softwarequalität nicht mogeln könne. Viele Manager verhielten sich zwar wie Autofahrer, die gegen die Verkehrsregeln verstoßen, aber mit Glück nicht erwischt werden. Dem setzte Ludewig entgegen: „Im Software Engineering braucht es keine Blitzer. Die Software selbst ist das Gedächtnis. Sie registriert die Fehler unauffällig. Bis die Rechnung kommt, kann es eine Weile dauern – aber sie kommt.“

Maßnahmen gegen chaotische Projekte

Daher plädierte der Professor für Maßnahmen zur Hebung der Qualität. Er riet eindringlich zu einem realistischen Projektplan, der auch einer kritischen Prüfung standhalte, einer guten Planung der Prüfungen und der Dokumentation sowie zur klaren Identifikation und transparenten Verwaltung der Ergebnisse in einem Konfigurationsmanagement-System.

Weiter riet er dazu, Aufgaben erst zu stellen und sie dann zu lösen, sowie die Zwischenresultate erst zu prüfen und dann zu verwenden. Zudem mahnte er die Verwendung von Checklisten für alle Arbeiten an sowie Code-Templates und Codierrichtlinien. Darüber hinaus riet er dazu, Fehler und Änderungswünsche kontrolliert zu bearbeiten, Fehlerstatistiken zu führen und jedes abgeschlossene Projekt kritisch zu analysieren.

Zuletzt warnte der Stuttgarter Professor vor falscher Heldenverehrung. Nicht der heroische Entwickler, der ganze Projekte im Alleingang programmiert, sei das anzustrebende Ideal, sondern der der Entwickler der in der Lage ist, komplexe Probleme anschaulich zu beschreiben, in handhabbare Teile zu zerlegen und auf dieser Grundlage eine Lösung zu finden.

Dann komme man auch einem anderen Ideal nahe: „Gute Software zu entwickeln, macht allen Beteiligten Spaß“.

(ID:43500767)