Portal
 Portal
Portal

 
Beiträge:

Stand: online seit 03/06

Von Olaf Stefan Göhrs, Büttelborn*
Kundengetriebenes Software-Qualitätsmanagement

Einleitung

Obwohl schon seit den 60er Jahren von der Softwarekrise gesprochen wird, hat sich die Erfolgsquote von Softwareentwicklungsprojekten bislang nur wenig verbessert. Im vielzitierten Chaos-Report der Standish-Group von 1995 wurde aufgezeigt, dass nur 16,2% aller untersuchten Softwareentwicklungsprojekte erfolgreich waren, hingegen 31,1% scheiterten. 52,7% der Projekte hatten entweder das Budget oder den Zeitrahmen deutlich überzogen oder lieferten ein Produkt, dass die vorgegebenen Anforderungen in großen Teilen nicht erfüllte. Im Jahr 2004 sah die Bilanz mit 29% erfolgreicher Projekte (bei 18% gescheiterter) nur unwesentlich besser aus. Als ein Hauptfaktor für den Erfolg eines Projekts wurde in allen Jahren die Einbindung des Anwenders in die Entwicklung genannt. Dennoch wird dieser Aspekt noch immer häufig vernachlässigt, mit der Folge, dass das entwickelte Produkt die Erwartungen nur teilweise oder gar nicht erfüllt.
Agile Methoden stellen den Kunden und seine Anforderungen in den Mittelpunkt der Entwicklung. Mit der Praktik des "On-Site Customer" fordert das eXtreme Programming sogar die permanente Mitarbeit des Kunden. So ist nicht verwunderlich, dass Agilität im Chaos-Report 2004 erstmals zu den 10 wichtigsten Erfolgsfaktoren für Softwareentwicklungsprojekte gerechnet wurde. Dies zeigt, dass die Einführung agiler Methoden ein wichtiger Schritt zur Qualitätsverbesserung von Softwareentwicklungsprojekten ist1. Dennoch muss hinterfragt werden, ob Agilität auf Entwicklungsseite alleine schon ausreicht, Projekte zum Erfolg zu führen. Bei Überlegungen, inwieweit der Kunde selbst in die Qualitätssicherung aktiv eingreifen sollte, müssen folgende Fragen beantwortet werden:

  • Welche Forderungen seitens des Kunden werden an die Entwicklungsprojekte gestellt?
  • Welche Anforderungen kommen bei der Umsetzung auf die Kunden selbst zu?
  • Wie kann der Kunde direkt Einfluss auf die Software-Qualität nehmen?


    • Kundenanforderungen

    Kunde, Anwender, Auftraggeber

     Spricht man von "dem Kunden", wird häufig impliziert, dass der Kunde eine einzelne Person oder zumindest eine einzelne Rolle darstellt. Tatsächlich existiert in den seltensten Fällen ein einzelner Kunde. Vielmehr können eine Reihe von Rollen auf der Auftraggeberseite unterschieden werden.
    Die wichtigsten Rollen sind:
  • der Anwender (auch hier kann es bisweilen notwendig oder zumindest sinnvoll sein, verschiedene Anwendergruppen zu unterscheiden) und der
  • eigentliche Auftraggeber, also der auf Kundenseite für das Projekt verantwortliche Entscheidungsträger.

    • Weitere Rollen können z. B. sein:
  • Finanzier,
  • IT-Administrator oder
  • IT-Sicherheitsbeauftragter.
    • Ein Anwender sollte dem Projekt möglichst kontinuierlich zur Verfügung stehen. Vom Auftraggeber selbst kann dies nicht erwartet werden. Damit seine Interessen aber hinreichend vertreten werden, sollten diesbezügliche Maßnahmen, wie regelmäßige, in kurzen Abständen stattfindende Treffen, vereinbart werden.

    Kundenanforderungen an die Softwareentwicklung

     Die Erwartungen an das Softwareentwicklungsprojekt können je nach Kundenrolle gänzlich unterschiedlich sein. Im Allgemeinen lassen sich diese Erwartungen in zwei Gruppen einteilen, in die
  • Anforderungen an das Produkt und die
  • Erwartungen an das Projekt.
    • Anwender, sowie auch Administratoren oder Sicherheitsbeauftragte haben vor allem Anforderungen an die neu zu erstellende Software. Bei dem Auftraggeber (sowie ggf. bei dessen Vorgesetzten und Geldgebern) stehen in der Regel ökonomische Gesichtspunkte im Vordergrund, d. h. sowohl die Anforderungen an das Produkt als auch die Erwartungen an das Projekt sind von Relevanz.
    Die Ansprüche, die auftraggeberseitig an ein Projekt gestellt werden, betreffen im Wesentlichen das Budget, den zeitlichen Rahmen sowie Planbarkeit und Risiko. Die Gewichtung dieser Faktoren kann projektspezifisch unterschiedlich ausfallen. Je mehr der Auftraggeber selbst in das Projekt involviert ist, desto wichtiger wird ein weiterer Faktor: die Transparenz. Er muss über den Projektstatus und -verlauf hinreichend informiert sein, um die richtigen Entscheidungen treffen zu können.
    Neben den projektbezogenen Anforderungen können auch Eigenschaften der fertigen Software wirtschaftliche Auswirkungen haben. Es kann nicht im Interesse des Auftraggebers liegen, in ein Abhängigkeitsverhältnis vom Auftragnehmer bzgl. der im Einsatz befindlichen Software zu geraten. Daher können eine einfache Erweiterbarkeit und eine partielle Austauschbarkeit, die Wartungsfreundlichkeit sowie eine umfassende und verständliche Dokumentation (insbesondere der Schnittstellen) wichtige Forderungen sein.
    Weitere wichtige Produktanforderungen können Robustheit, Fehlerfreiheit, Sicherheitsrichtlinien2, Performanz oder Echtzeitanforderungen sein.
    Die wesentlichen Anforderungen sind aber in der Regel fachlicher Natur. Die zu entwickelnde Software muss die Geschäftsprozesse des Kunden derart verbessern, dass die Ausgaben für ihre Erstellung in einer angemessenen Zeit kompensiert werden können. Diese anwendungsbezogenen Anforderungen können sich auf fast alle Bereiche der Software, wie Datenhaltung, Darstellung, Usability oder die eigentliche Fachlogik, beziehen.
    Eine Reihe von Vorgaben stehen zu Beginn eines Softwareentwicklungsprojekts bereits fest. Andere, insbesondere anwendungsbezogene Erwartungen entwickeln, konkretisieren und ändern sich erfahrungsgemäß erst während eines laufenden Projekts. Daher wird es in der modernen Softwareentwicklung immer wichtiger, auf derartige Änderungen schnell, angemessen und flexibel reagieren zu können. Agile Methoden3 bieten eine Basis für eine flexible Handhabung von sich ändernden Kundenanforderungen.

    Anforderungen an die Kunden

     Mit den gesteigerten Möglichkeiten, direkt in das laufende Entwicklungsprojekt eingreifen zu können, erhöht sich zugleich die Verantwortung des Kunden. Er darf nicht nur Entscheidungen treffen, es wird vielmehr von ihm verlangt. Damit hat die - häufig sehr bequeme - Rolle des passiven Auftraggebers ein Ende. Um zielführende Vorgaben machen zu können, muss der Kunde nun den genauen Überblick über den Stand des Projekts behalten und vor allem auch die Zielrichtung bestimmen können.
    In der Regel wird sich die Vorstellung über die zu erstellende Software im Laufe des Entwicklungsprozesses verändern oder zumindest konkretisieren. Dem Kunden obliegt es daher, neue Anforderungen rechtzeitig vorherzusehen und in das Projekt einfließen zu lassen.
    Daraus ergeben sich eine Reihe von Forderungen an den Kunden:
    • Pläne, Ziele und Randbedingungen des Projekts müssen seitens des Kunden transparent gemacht werden. Der Auftragnehmer muss wissen, was von ihm erwartet wird. Sind die Anforderungen zu unklar, besteht das Risiko, dass das Projekt in eine falsche Richtung abdriftet.
    • Der Kunde selbst muss agil bleiben. Sollte sich im Projektverlauf herausstellen, dass bestimmte Anforderungen aus technischen Gründen nicht umgesetzt werden können, muss er in der Lage sein, darauf flexibel zu reagieren, und adäquate neue Ziele zu formulieren.
    • Dies erfordert weiterhin ein gewisses Maß an Verständnis für die Softwareentwicklung. Um Probleme zu begreifen und Lösungsvorgaben machen zu können, muss eine gemeinsame Sprache als Basis gefunden werden.
    • Schließlich muss der Kunde erreichbar sein. Ständige Kommunikation ist einer der wichtigsten Erfolgsfaktoren in agilen Softwareprojekten. Unklarheiten über neue Anforderungen müssen möglichst zeitnah beseitigt werden, um einen Entwicklungsstau zu verhindern.
    Wesentliche Forderungen wie Agilität oder Transparenz werden also gleichermaßen an den Auftragnehmer wie den Auftraggeber gestellt4.

    Schritte zum kundengetriebenen Software-Qualitätsmanagement

    Vertragliche Vereinbarungen

     Im Wesentlichen hat der Kunde zwei Möglichkeiten, aktiv in den Softwareentwicklungsprozess einzugreifen:
      1. durch vertraglich geregelte, organisatorische Vorgaben bzgl. des Projekablaufs, und
      2. durch fachliche Spezifikation der Anforderungen an die zu erstellende Software.
    In klassischen Softwareprojekten werden diese Anforderungen an Zeitrahmen, Budget oder Funktionalität vor Projektbeginn festgelegt; eine Überprüfung erfolgt dann in großen Zeitspannen oder gar erst gegen Projektende. Auf diese Art und Weise hat der Auftraggeber kaum Möglichkeiten, die Qualität der Software später noch maßgeblich zu beeinflussen.
    Somit ist es offensichtlich, dass eine starre, vertragliche Festlegung aller funktionalen Inhalte schon zu Projektbeginn für ein aktives, kundengetriebenes Software-Qualitätsmanagement kontraproduktiv ist. Anstelle eines (bzgl. der Funktionalität) vollständigen Pflichtenhefts sollten daher Vereinbarungen darüber getroffen, mit welchen Mitteln und auf welche Weise die erwünschte Qualität des Produkts erreicht werden soll. Hierbei kommt es darauf an, möglichst kurze Intervalle zu definieren, nach deren Ablauf die erreichte Qualität überprüft wird sowie neue Zielvorgaben für den folgenden Entwicklungszeitraum gemacht werden.
    Die vertragliche Umsetzung ist dann in den unterschiedlichsten Varianten, vom Aufwandspreis bis zum Festpreis, denkbar5. Der mehrstufige Festpreis, bei dem Verträge nur für einzelne Phasen des Gesamtprojekts abgeschlossen werden, eignet sich ideal für das kundengetriebene Software-Qualitätsmanagement. Aber auch innerhalb eines Vertrages über die gesamte Projektlaufzeit (wie z. B. dem agilen Festpreis) können und sollten kurze, feste Abschnitte vereinbart werden, nach denen dem Auftraggeber explizit Einfluss- und Kontrollmöglichkeiten eingeräumt werden. Falls ein ausreichendes Vertrauensverhältnis zwischen Auftraggeber und Auftragnehmer bestehen sollte, kann gegebenenfalls aber auch auf die explizite vertragliche Festlegung der Kontrollzeiträume verzichtet werden.

    Modelle als gemeinsame Sprache

     Wenn das gemeinsame Vorgehen bereits definiert wurde, so ist weiterhin notwendig, eine gemeinsame Sprache zu finden, die sowohl vom Auftraggeber als auch vom Auftragnehmer verstanden wird.
    In der Regel existieren nämlich gewaltige Unterschiede in der Art und Weise, wie Entwickler und Anwender eine zu entwickelnde Software beschreiben. Während der Anwender das System aus dem Blickwinkel seiner täglichen Arbeitsabläufe heraus betrachtet und er dementsprechend zu einer Systembeschreibung in Prosa tendiert, bildet sich der Entwickler relativ rasch ein Bild über die zu entwickelnden Programmstrukturen und er entwirft ein Design-Konzept. Seine Sprache ist somit stark von der technischen Umsetzung und der späteren Codierung geprägt.
    Beide Arten der Beschreibung haben in ihrem eigenen Umfeld ihre Berechtigung, sind aber für die jeweils andere Seite zum Teil nur schwer zu verstehen. Für ein kundengetriebenes Qualitätsmanagement ist es jedoch notwendig, Anforderungen und Probleme transparent zu halten; Missverständnisse vermindern letztendlich die Qualität. Es gilt also, den kommunikativen Graben zwischen Anwendern und Entwicklern bestmöglich zu überbrücken.
    eXtreme Programming (XP) bietet hierzu zwei Hilfsmittel an:
      1. Metaphern, durch die in kürzester Form ein System oder Systemteil in allgemeinverständlicher Form umschrieben wird, und
      2. Story Cards, auf denen in kurzer, prosaischer Form ein Anwendungsfall beschrieben wird.
    Bei beiden Techniken wird durch extreme Fokussierung das Wesentliche einer Funktionalität oder einer Anforderung herausgearbeitet. Dies erzeugt ein gemeinsame Sicht auf die zu entwickelnde Software und ermöglicht allen Beteiligten einen Überblick über das Projekt. Dies ist eine Voraussetzung für kundengetriebenes Software-Qualitätsmanagement; jedoch ist es insbesondere aus Sicht des Kunden noch nicht ausreichend. Dieser benötigt, wenn er aktiv das Qualitätsmanagement vorantreiben will, eine tiefere Einsicht in die Entwicklung, um deren Stand vernünftig beurteilen zu können.
    Ein tieferes Verständnis der Software kann aber ein Kunde nur dann erzielen, wenn er sich auf die Sprache der Entwickler einlässt6. Allerdings ist es ihm kaum zuzumuten, ein komplettes Programm direkt auf Code-Ebene zu analysieren. Hiermit sind selbst erfahrene Programmierer bei fremden (insbesondere schlecht strukturiertem) Code oftmals überfordert. Es ist daher erforderlich, die codierten Inhalte in einer abstrakteren, überschaubaren Form darzustellen.
    Die graphische Darstellung von Modellen ist in fast allen Fachbereichen weit verbreitet. So sind z. B. Datenfluss- oder Ablaufdiagramme sowohl im betriebswirtschaftlichen als auch im technischen Umfeld üblich. In der objektorientierten Softwareentwicklung hat sich die Unified Modeling Language (UML)7 als de facto Standard etabliert. Die Umstellung von den kundenseitig gewohnten Diagrammen auf UML ist in der Regel gut machbar, wenngleich auch nicht immer trivial8. Für denjenigen Kunden aber, der über längere Zeiträume hinweg Softwareentwicklungsprojekte begleitet9, ist das Erlernen der UML fast immer vorteilhaft.
    Die UML unterstützt sowohl die objektorientierte Analyse (OOA) als auch das objektorientierte Design (OOA). Gerade bei der OOA, bei der die fachliche Domäne modelliert wird, ist die Mitarbeit des Kunden äußerst förderlich. In Anbetracht neuerer Entwicklungen wie der "Model Driven Architecture" (MDA)10 oder des "Model Driven Software Developments" (MDSD)11 ist damit zu rechnen, dass die Möglichkeiten des Kunden auf eine direkte Einflussnahme auf die Domänenmodellierung noch weiter wachsen werden.
    Neben dieser Art der Steuerung stellt die UML aber auch dem Kunde eine Hilfe zur Überwachung des Projektverlaufs zur Verfügung. Sie liefert nämlich, sofern die Modelle fortlaufend aktualisiert werden12, auch eine gut überschaubare Dokumentation des Programmcodes.

    Testgetriebene Entwicklung

     Wichtiger als eine formale Überprüfung des Codes ist jedoch eine Überprüfung der erstellten Software selbst, d. h. der Software-Test. Und auch hier hat sich in den letzten Jahren die Erkenntnis durchgesetzt, dass Controlling sinnvoller ist als Kontrolle. Softwaretests gegen Ende eines Projekts können Fehler nur feststellen, erhöhen aber die Qualität der Software direkt nicht. Der Aufwand zur Beseitigung spät entdeckter Fehler ist zudem sehr hoch. Bilden jedoch die Tests einen fortlaufenden, integralen Bestandteil der Entwicklung, wird nicht nur dieser Aufwand erheblich reduziert, sondern darüber hinaus auch ein übersichtliches Design gefördert.
    Genau diesen Ansatz verfolgt die testgetriebene Softwareentwicklung (TDD, "Test Driven Development")13; und sie geht darüber hinaus, indem sie das "Test First"-Prinzip vertritt. Der Test dient also nicht mehr alleine der Kontrolle der Fehlerfreiheit, sondern er wird zur eigentlichen Antriebsfeder der gesamten Entwicklung. Jeder Testfall stellt eine Spezifikation und zugleich eine Veranschaulichung einer Anforderung dar. Testgetriebene Entwicklung wird sowohl von systemübergreifendem Akzeptanztests als auch von einzelne Methoden betreffenden Unit-Tests ausgehen. Die Komplexität ist dabei unterschiedlich, die Prinzipien bleiben jedoch die gleichen:
      1. Jede Änderung am Code soll durch einen Test motiviert sein.
      2. Durch ständiges Refactoring soll das Design einfach und überschaubar bleiben.
      3. Häufige Integration des Quellcodes soll jederzeit einen lauffähigen und getesteten Build garantieren können.
    Alle drei Prinzipien stellen eine ideale Basis für kundengetriebenes Software-Qualitätsmanagement dar.
    Durch die Test-First Maxime hat der Kunde (hier genauer gesagt der Anwender) die Möglichkeit, durch einfache, praxisnahe Beispiele, d. h. Testfälle die Entwicklung zu steuern. Der kommunikative Graben kann auf diese Weise leicht überwunden werden. Darüber hinaus kann der Kunde später selbst die Funktionalität schnell überprüfen; der passende Test wird ihm bereitgestellt. Bis zu welcher Tiefe der Kunde schließlich die Entwicklung begleitet ist variabel. In der Regel wird er es bei Akzeptanztests bewenden lassen. Bisweilen kann aber auch die Vorgabe von speziellen Unit-Test gewinnbringend sein.
    Wenn das Refactoring ebenso selbstverständlich zu jedem Entwicklungszyklus gehört wie der Test selbst, hat dies positive Auswirkungen auf das Design. Ein evolutionäres, wachsendes Design passt zu den aktuellen Anforderungen. Es werden keine unnützen Strukturen mitgeschleppt, Designfehler, oder auch einfach nur ein hässlicher Code, werden zeitnah korrigiert. Dadurch bleibt der Code sauber, das Design einfach und überschaubar. Für den Kunden ist dies mit zwei Vorteilen verbunden: Erstens ermöglicht es ihm ein Verstehen des Codes, und damit eine bessere Kontrollmöglichkeit. Zweitens, und wichtiger: Die Software bleibt leichter veränderbar. Neue Anforderungen sind leichter zu integrieren.
    Um eine Software testen zu können, benötigt der Kunde einen lauffähigen Build. Die häufige Integration garantiert ihm, dass er immer mit einer aktuellen Version testet. Fehler können somit schneller entdeckt werden, und werden dadurch auch erheblich schneller behoben. Weiterhin werden einige neue Wünsche erst dann für den Anwender offensichtlich, wenn er an einem laufenden System arbeitet. Diese Anforderungen können dann in einer späteren Iteration in die Anwendung integriert werden.
    Der Kunde hat also in einem testgetriebenen Softwareentwicklungsprojekt die Möglichkeit, aktiv an der Qualität des Produkts mitzuwirken. Er kann durch die Vorgabe von Testfällen die Entwicklung steuern und anhand der Tests (und ggf. weiterer Testfälle) den Stand des Projekts zeitnah überprüfen.

     Fazit

     Kundengetriebenes Software-Qualitätsmanagement ist immer agil.
    Es fordert sowohl vom Auftraggeber als auch vom Auftragnehmer ein erhöhtes Maß an Flexibilität und Verständnis für die jeweils andere Partei. Dafür erhält der Kunde ein qualitativ hochwertiges und preiswertes14 Produkt.
    Agile Entwicklung bedeutet auch Veränderung. Sowohl Anforderungen als auch Design unterliegen einem evolutionärem Wandel, bei dem langsame Anpassung genauso vorkommt wie sprunghafte Änderung. Vor Projektbeginn sollten daher die gemeinsamen Vorgehensweisen und die (möglichst kurzen) Intervalle der Entwicklungszyklen vereinbart werden, um angemessen auf jede Veränderung reagieren zu können.
    Denn Kommunikation zwischen allen Parteien ist ein unverzichtbarer Bestandteil des kundengetriebenen Software-Qualitätsmanagements. Eine gemeinsame Sprache vereinfacht diese Kommunikation erheblich. Eine Sprache wie die UML ist geeignet, den gemeinsamen Wortschatz zur Verfügung zu stellen.
    Die testgetriebene Softwareentwicklung stellt das ideale auftragnehmerseitige Gegenstück zum kundengetriebenen Software-Qualitätsmanagement. Durch die Formulierung von Testszenarien kann der Kunde die Entwicklung steuern und die Ergebnisse zeitnah überprüfen. Testgetriebene und modellgetriebene Softwareentwicklung sind dabei keine Gegensätze, sondern können sich hervorragend ergänzen.

    Kudengetriebenes Software-Qualitätsmanagement bedeutet also für einen Auftraggeber zunächst einmal einen Mehraufwand. Er wird aus seiner bisherigen, für ihn sehr bequemen Passivität herausgerissen und trägt mehr Verantwortung für das zu entwickelnde Produkt. Weiterhin ist er gezwungen, sich intensiver mit der Entwicklung selbst auseinanderzusetzen. Angesichts der immer noch erschreckend hohen Quoten, mit denen Softwareentwicklungsprojekte scheitern, sollte dieser Mehraufwand jederzeit in Kauf genommen werden. Schließlich muss er auch mit dem fertigen Produkt (so es denn überhaupt fertiggestellt wird) leben. Und eine qualitativ hochwertige, explizit auf die Anforderungen zugeschnittene Software wird die zusätzlichen Kosten sehr schnell wettmachen.

    * Dr. rer. nat. Olaf Stefan Göhrs über Informationsflüsse in chaotischen Systemen promoviert und ist seither in unterschiedlichen Bereichen der Softwareentwicklung und des Qualitätsmanagements tätig.

    1 Siehe dazu auch: Olaf Göhrs, Total Quality Management und agile Softwareentwicklung, ius-IT.de 02/2006

    2 Sowohl bezüglich der Datensicherheit (Security) als auch der Vermeidung von Gefährdungen bei technischen Systemen (Safety).

    3 Siehe hierzu z. B. http://www.agilealliance.com

    4 Vgl.: Olaf Göhrs, Transparenz und Agilität in Softwareentwicklungsprojekten, ius-IT.de, 11/2005

    5 Vgl.: Bernd Oestereich, "Der agile Festpreis und andere Preis- und Vertragsmodelle", Objekt Spektrum 1/2006

    6 Was für in der Regel jedoch mit einem zusätzlichen Arbeitsaufwand verbunden ist.

    7 Vgl.: http://www.uml.org/

    8 Prinzipiell lässt sich auch die Geschäftsprozessmodellierung selbst mit der UML durchführen (vgl. Oestereich u.a.: Objektorientierte Geschäftsprozessmodellierung mit der UML, dpunkt, 2004).

    9 Und nur für den ist das kundengetriebene SW-Qualitätsmanagement tatsächlich sinnvoll.

    10 Siehe http://www.omg.org/mda/

    11 Einen sehr guten Überblick über MDSD bietet: Stahl, Völter: Modellgetriebene Softwareentwicklung - Techniken, Engineering, Management, dpunkt, 2005.

    12 Dies ist bei einer modellgetriebenen Softwareentwicklung zwangsläufig der Fall.

    13 Einen hervorragenden Einstieg liefert: Frank Westphal, Testgetriebene Entwicklung mit JUnit & FIT, dpunkt, 2005

    14 Billige Produkte sind selten preiswert!