Anbieter zum Thema

Mixed Mode GmbH

MicroConsult Academy GmbH

Wirtschaftliche Folgen undurchschaubaren Codes

Dass fehlerhafte Produkte Kosten verursachen können, ist trivial. Diese Kosten sind aber kaum genau zu beziffern, weswegen sie schwer gegen die weitaus besser abzuschätzenden Kosten angesetzt werden können, die durch einen neu eingeführten oder erweiterten Testprozess entstehen. Darin liegt das Kernproblem der Argumentation für die, die dem Testen gerne mehr Raum und Budget zugestehen wollen. Tendenziell werden abstrakte Risiken zu niedrig und konkrete Risiken zu hoch angesetzt.

Diese Erkenntnis stammt aus der Spieltheorie, die auch belegt, dass insbesondere Risiken bei fehlenden negativen Erfahrungen negiert oder zu gering angesetzt werden: Bei wem beispielsweise (zum Glück) noch nicht in die eigene Wohnung eingebrochen wurde, der kann sich diesen Umstand kaum realistisch genug vorstellen und wird daher ohne Anstoß und Beratung kaum genügend Vorkehrungen treffen. Eine adäquate Gegenmaßnahme unter anderen ist die Schaffung eines qualitätssichernden Systems, das zumindest gegen die zwar verhältnismäßig selten auftretenden schweren Fehler immunisiert, die aber in ihrer Auswirkung vernichtend sein können. Hierfür gibt es eine Reihe von Beispielen wie den bekannten Elchtest, die missglückte Ariane-Mission, die Raumsonde Pathfinder und dergleichen.

Vermeiden von logischen Wucherungen

Die Maßnahmen, die dem schlecht kontrollierten Wachstum von Programmlogiken den Boden entziehen sollen, zielen letztlich darauf ab, Voraussetzungen für so viel wohlstrukturierten und spezifizierten Code wie möglich zu schaffen.

1. Schaffung eines angemessenen Mindsets bei Entwicklern und Projektleitern: Bei den Entwicklern selbst, die für die Tester- und Reviewerrolle eingesetzt werden können, ist eine Schulung in den entsprechenden Techniken unerlässlich. Beim Führungspersonal sollte zumindest die Kenntnis des Fundamentalen Testprozesses (ISTQB) vorhanden sein sowie eine Vorstellung von den heute verfügbaren Testprozessmodellen jenseits des vielfach noch gelebten Wasserfallmodells.

2. Festlegung von Qualitätszielen und dorthin führende Richtlinien: Kenntnisse selbst von erprobten Techniken und Herangehensweisen sind nur insoweit sinnvoll und nützlich, wie sie an die Lebenswirklichkeit der jeweiligen Entwicklungsmannschaft angepasst sind. Der Versuch, zu große oder als fremd empfundene Prozesse oder Regelwerke einer Entwicklungsmannschaft überzustülpen, wird scheitern. Die umzusetzenden Richtlinien mit und aus dem Team heraus schrittweise zu entwickeln, zu testen, anzupassen und zu erweitern, erzielt ungleich bessere Resultate. Dabei sollten die etablierten Techniken als Vorlage genommen werden.

Für Reviews beispielsweise ist es unerlässlich, immer anhand einer Checkliste vorzugehen, die dem Autor des zu reviewenden Arbeitsergebnisses schon vorher vorlag und mit ihm abgestimmt wurde. Den Review-Kriterien müssen ausschließlich objektive Qualitätsziele (vgl. ISO/IEC 25000, früher ISO 9126) zugrunde liegen sowie die Sicherstellung einer grundlegenden Testbarkeit.

Oft sind es tatsächlich nur wenige Schritte, die zu einer nachhaltigen Verbesserung der Arbeitsergebnisse führen, beispielsweise die Einführung von Code Guides und regelmäßigen Code Reviews. Richtig durchgeführte Code Reviews haben eine ganze Reihe positiver Effekte auf die Entwicklungsmannschaft.

Daneben sind sie eine der kostengünstigsten Maßnahmen, weswegen ihre Einführung nur sehr empfohlen werden kann: In den Entwicklungsmannschaften werden in der Regel hochqualifizierte Fachleute wie Elektrotechniker, Maschinenbauer, Physiker und dergleichen eingesetzt, die ihre Domäne hervorragend überblicken.

Dennoch ist es Fakt, dass sie bisweilen die Anforderungen ihres spezifischen Fachbereichs nicht in angemessener Weise in eine Programmlogik übertragen können. Hierzu gehören beispielsweise objektorientiertes Design und Architektur, Begriffe wie Kapselung, Modularität und dergleichen. In diesen Fällen genügen oft geringfügige Maßnahmen wie Reviews durch erfahrenere Kollegen oder externe Fachleute, um Defizite zu beheben. Guten Code zu schreiben ist wie gute Texte zu schreiben: Ohne beständige Anleitung, Übung und Review wird kaum jemand über ein gewisses radebrechendes Niveau hinauskommen.

3. Einrichtung von mitwachsenden Prozessen: Wesentlich für eine auf Dauer erfolgreiche und Fehlerkosten vermeidende Entwicklung ist eine dynamische Anpassungsfähigkeit der Entwicklungsprozesse an die sich verändernden Produkte und Produktumgebungen. Ein gestern noch adäquater Entwicklungs- und Testprozess kann durch eine heute neu auftretende Anforderung schleichend ungeeignet werden. Gerade in dem schleichenden Herausfallen aus der Angemessenheit besteht die Gefahr für den Entwicklungsprozess, zu einer begünstigenden ökologischen Nische für logisches Gestrüpp zu werden. Deshalb sollte in regelmäßigen Abständen geprüft werden, ob diese Angemessenheit noch gegeben ist.

* Dr. Richard Kölbl ist Experte für Embedded-Software bei Mixed Mode in Gräfelfing bei München.

(ID:43694157)