Stand: online seit 02/06

Von Olaf Stefan Göhrs, Büttelborn^*

Total Quality Management und agile Softwareentwicklung

Softwarequalität

Trotz vieler Bemühungen ist der Qualitätsstandard bei Softwareentwicklungsprojekten häufig immer noch ausgesprochen mangelhaft. Probleme wie die folgenden sind keine Ausnahmen:

Kunden beschweren sich über Probleme mit der Software.

Entwicklungsprojekte werden nicht termingerecht abgeschlossen.

Das eingeplante Budget wurde erheblich überzogen.

Die fertige Software entspricht nicht den Erwartungen des Kunden.

Nacharbeiten an der fertigen Software kosten Geld und führen zu weiterer Kundenunzufriedenheit.

Wenn derartige Symptome vermehrt auftreten, ist es allerhöchste Zeit zu reagieren. Einige Warnsignale wurden in diesem Fall schon lange vorher übersehen¹.
Aber unabhängig davon, wann die Qualitätsprobleme entdeckt werden, muss die Geschäftsführung geeignete Maßnahmen ergreifen, mit Hilfe derer der jeweilige Missstand behoben werden kann.
Eine Vielzahl von Ansätzen zur Qualitätsverbesserung existiert bereits. Alle diese Ansätze haben ihre unterschiedlichen Stärken und Schwächen, doch die Kombination der verschiedenen Vorgehensweisen ist leider nicht trivial. Wenn die einzelnen Methoden jedoch flexibel und pragmatisch verwendet werden, ist es möglich, von den jeweiligen Stärken zu profitieren.

Vor dem Versuch, die Qualität in der Softwareentwicklung zu verbessern, sollte allerdings zunächst der Begriff der Qualität geklärt werden. Denn Softwarequalität kann von verschiedenen Gesichtspunkten aus definiert werden.

Kundenbezogene Qualität
Ausschlaggebend für die Akzeptanz eines erstellten Softwareprodukts sind einerseits anwendungsbezogene Faktoren, wie funktionelle Vollständigkeit, Fehlerlosigkeit oder Performanz, und andererseits auftragsbezogene Aspekte wie Kosten oder Termine. Qualität kann daher als Erfüllungsgrad der vom Kunden gestellten Anforderungen definiert werden. Mängel bei dieser kundenbezogenen Qualität werden am ehesten offenkundig und haben die gravierendsten Folgen.

Produktqualität
Weiterhin besitzt das Produkt selbst eine Qualität. Diese kann sich in der &Uuuml;bersichtlichkeit des Codes, der Einhaltung von Programmierstandards und Sicherheitsrichtlinien, der Performanz, in der der Definition der Schnittstellen oder auch der Wartbarkeit und Erweiterbarkeit des fertigen Programms ausdrücken.

Prozessqualität
Grundlage für ein qualitativ hochwertiges Produkt ist die Qualität der Prozesse, die zu seiner Erstellung führen. Die für die Softwareentwicklung relevanten Prozessgebiete, wie Anforderungs- und Changemanagement, Projektplanung, Qualitätssicherung oder Konfigurationsmanagement, müssen also zunächst definiert sein und angewendet werden. Bedeutsam für die Prozessqualität ist dann die Qualität der einzelnen Prozesse und insbesondere auch die des Zusammenspiels der unterschiedlichen Maßnahmen.

Da die kundenbezogene Qualität und die Produktqualität aus der Güte des kompletten Softwareentwicklungsprozesses resultieren, ist die wichtigste Maßnahme zur Erhöhung der Softwarequalität eine Optimierung der Prozesse der Softwareentwicklung.

Total Quality Management

Schnell stellt sich die Frage der Verantwortlichkeit für die Qualität der Software.
Antworten wie das Qualitätsmanagement oder die Entwickler sind dabei ebenso einfach wie falsch. Das Qualitätsmanagement kann keine Qualität generieren, es kann lediglich die aktuelle Qualität beurteilen und Hilfestellung zu deren Verbesserung geben. Die Entwickler hingegen können nur so gute Software produzieren wie es ihr Umfeld gestattet. Fehlt beispielsweise eine ausreichende Anforderungsanalyse, so wird das Endprodukt mit Sicherheit nicht den Erwartungen des Kunden entsprechen. Ebenso können auch fehlende Hardware oder Entwicklungswerkzeuge eine qualitativ hochwertige Entwicklungsarbeit verhindern.
Die Gewährleistung von Softwarequalität kann also nicht dem Verantwortungsbereich einzelner Gruppen zugeordnet werden; sie ist wesentliche Aufgabe aller an der Softwareentwicklung Beteiligten.

Das Total Quality Management (TQM)² ist ein Ansatz, der dieser allgemeinen Verantwortung Rechnung trägt. Dabei ist dieses umfassende Qualitätsmanagement keine neue Idee; schon nach Beendigung des 2. Weltkriegs führte der Amerikaner W. Edward Deming seine Ideen des Total Quality Managements in Japan ein, wo es seitdem äußert erfolgreich praktiziert wurde. 1987 wurde in Kooperation einiger namhafter europäischer Unternehmen ein europäisches TQM-Modell, das " EFQM Excellence Model" (http://www.efqm.org/), entwickelt. TQM ist ein zwar branchenunabhängiges Modell, das aber aufgrund des geforderten Primats der Qualität richtungweisend für die heutige Softwareentwicklung ist.
Aus der Erkenntnis heraus, dass Aufwände zur Qualitätsverbesserung, aufgrund der Ersparnisse bei der Nacharbeit oder der Fehlerbeseitung, die Produktivität tatsächlich erhöhen³, wird beim TQM das magische Dreieck aus Budget, Zeit und Qualität zugunsten der Qualität verschoben. Diese wird zum obersten Geschäftsziel; die Einhaltung des Budgetrahmens und der zeitlichen Vorgaben werden zu wesentlichen Aspekten der Qualität.

TQM besteht aus einer Reihe von Prinzipien, die von allen Mitarbeitern eines Unternehmens verinnerlicht werden müssen. Demings 14 Punkte für eine holistische Unternehmensführung sind:

1. Schaffung eines gemeinsamen Leitziels zur Verbesserung von Prozessen, Produkten und Dienstleistungen.
2. übernahme einer Philosophie der Zusammenarbeit, bei der alle gewinnen.
3. Verzicht auf nachträgliches Prüfen zugunsten von aktiver Qualitätsplanung.
4. Ein Vertrauensverhältnis und intensive Zusammenarbeit mit den Lieferanten.
5. Permanente Verbesserung aller Prozesse.
6. Training alle Mitarbeiter zur Verbesserung ihrer Fähigkeiten.
7. Führung als Dienstleistung am Mitarbeiter.
8. Verminderung und Vermeidung eines Angstklimas in allen Formen.
9. Eliminierung der Barrieren zwischen den unterschiedlichen Abteilungen.
10. Verzicht auf Schlagworte und Ermahnungen seitens des Managements.
11. Gelebte Führerschaft anstelle von Leistungsnormen, Leistungsvorgaben und -bewertungen.
12. Beseitigung von Hindernissen, die Mitarbeiter daran hindern, ihre Arbeit gerne zu tun.
13. Schulung und Förderung jedes Einzelnen.
14. Einbeziehung der ganzen Organisation bei Vorbildfunktion der Geschäftsführung.

Das Total Quality Management kann nicht als einmaliges Projekt eingeführt werden, das direkt nach Abschluss grundsätzlich bessere Qualität liefert . Vielmehr ist TQM ein niemals endender Prozess, bei dem vorhandene Probleme permanent analysiert und Maßnahmen zur Verbesserung der Qualität ergriffen werden. Daher empfiehlt es sich auch, TQM schrittweise einzuführen.
Zunächst müssen dazu alle Führungskräfte von der Notwendigkeit eines umfassenden Qualitätsmanagements überzeugt sein. Ihre Aufgabe ist dann, für ein Umfeld zu sorgen, dass es den Mitarbeitern ermöglicht, qualitativ hochwertige Ergebnisse zu liefern.
Der Vorgesetzte versteht sich also nicht mehr als Kommandant, sondern als Dienstleister seiner Mitarbeiter. Dabei ist die Verbesserung der Prozesse, die in seinen Kompetenzbereich fallen, eine seiner wichtigsten Aufgaben.

Die Prozessverbesserung ist jedoch nicht allein Aufgabe des Führungspersonals, sondern die jeden einzelnen Mitarbeiters. Daher sollten die Mitarbeiter von Anfang an bei der Planung und Umsetzung der qualitätsverbessernden Maßnahmen nicht nur involviert sein, sondern diese auch initiieren. Probleme im Entwicklungsprozess sind meistens dort am schnellsten zu identifizieren und zu beheben, wo sie auftreten.
Diese inkrementelle Prozessverbesserung des TQM hat den Vorteil, dass sie einfach umzusetzen ist und auf breite Akzeptanz bei den Mitarbeitern stößt. Größere, von der Geschäftsführung angeordnete Maßnahmen zur Prozessoptimierung oder gar ein Business-Reengineering können hingegen leicht zu einer anfänglichen Demotivation der Mitarbeiter führen. Doch auch ein inkrementelles Vorgehen muss innerhalb eines geordneten Rahmens stattfinden, um tatsächliche Verbesserungen zu bewirken.

Prozessqualität

Das prozessorientierte Qualitätsmanagement stellt diesbezüglich eine Ergänzung zum Total Quality Management dar.

DIN EN ISO 9000-9004
Die ISO 900x Normenfamilie ist vermutlich die bekannteste Standardisierung im Bereich des Qualitätsmanagements. Die für die Softwareentwicklung wesentliche Norm ist die ISO 9001 mit den Schwerpunkten: Design, Produktion, Montage und Kundendienst. Mit der ISO 9000 Teil 3 wird ein Leitfaden zur Anwendung von ISO 9001 für die Softwareentwicklung bereitgestellt. Untergliedert in drei Bereiche (Rahmen-Maßnahmen⁴, unterstützende Tätigkeiten⁵ und direkte Lifecycle-Tätigkeiten⁶) werden an die identifizierten QM-Elemente spezifische Forderungen gestellt⁷.
Obwohl alle wichtigen QM-Maßnahmen durch ISO 900x abgedeckt werden und damit ein sinnvoller Rahmen für qualitätsverbessernde Maßnahmen gegeben ist, hat die Einführung der Norm nur in den seltensten Fällen zu einer Qualitätsverbesserung in der Softwareentwicklung geführt⁸. Vielmehr verkam die Zertifizierung zum Selbstzweck; sie wurde zu einem Marketinginstrument, das zudem mit der Zeit seine Wirkung verlor.
Der Nutzen der ISO 900x für die Prozessverbesserung ist auch deshalb vergleichsweise gering, weil ihre Anforderungen für einzelne Projekte nicht richtig zugeschnitten sind (und sein können). Denn der ISO 900x Standard stellt nur einen relativ allgemeinen Rahmen für das Qualitätsmanagement dar. Wenn er als solcher verstanden wird und seine Inhalte auch tatsächlich bei der Entwicklung präsent sind, kann er jedoch eine wichtige Hilfe bei der Qualitätssteigerung sein.

ISO 15504 / SPICE
Besser auf den Softwareentwicklungsprozess zugeschnitten sind die Prozessmodelle ISO 12207 und CMMI ("Capability Maturity Model Integration")⁹ mit dem Assessmentverfahren SCAMPI¹⁰, die in den letzten Jahren zunehmend an Bedeutung gewinnen.
Die ISO 15504 (SPICE¹¹), die an die ISO 9000 angelehnt ist, stellt eine internationale Norm für Prozesse und Assessmentverfahren dar. Sowohl CMMI/SCAMPI als auch ISO 12207 erfüllen diese Norm. SPICE ist das exemplarische Assessmentmodell der ISO 15504 (Teil 5), das auch für die ISO 12207 relevant ist.
Mit der Reifegrad-Dimension einerseits und der Prozess-Dimension andererseits stellt SPICE ein zweidimensionales Modell dar, durch das sowohl die Existenz als auch die Güte der geforderten Prozesse geprüft werden können.
Über die Prozess-Dimension, die in die Kategorien

Kunden-Lieferanten-Prozesse (10 Prozesse),

Entwicklungsprozesse (11 Prozesse),

Unterstützende Prozesse (10 Prozesse),

Managementprozesse (4 Prozesse) und

Organisationsprozesse (12 Prozesse)

unterteilt ist, wird ein Maß für die Vollständigkeit bestimmt.
In der Reifegrad-Dimension kann jedem einzelnen Prozess einer der Fähigkeitsgrade

0. unvollständig (incomplete),
1. durchgeführt (performed),
2. gesteuert (managed),
3. Reaktion auf Veränderung über den von Einhaltung eines Plans,
4. definiert (established),
5. vorhersagbar (predictable) oder
6. optimierend (optimizing)

zugeordnet werden. Insgesamt sind neun Attribute (wie z. B. Durchführung der Prozesse oder Messung der Prozesse) auf die Fähigkeitsgradstufen verteilt. Zu jedem dieser Attribute existiert weiterhin ein Erfüllungsgrad ("nicht vorhanden", "teilweise vorhanden", "im Wesentlichen vorhanden" oder "vollständig vorhanden"). Während eines Assessments muss nachgewiesen werden, dass die entsprechenden Anforderungen erfüllt werden.

Durch SPICE oder dem ähnlich gearteten SCAMPI definierte Assessments sind eine deutliche Verbesserung zur einfachen Zertifizierung nach ISO 9000. Die detailliertere Überprüfung der Aktivitäten zur Softwareentwicklung liefert eine erheblich verbesserte Analyse der vorhandenen Qualitätsprobleme und ermöglicht dadurch eine umfassende Identifizierung des Verbesserungspotenzial.
Allerdings kann auch ISO 15504 nicht verhindern, dass Qualität vorgetäuscht anstatt gelebt wird. Werden jedoch Self-Assessments mit dem allgemeinen Willen zur Prozessoptimierung durchgeführt, so ist diese Gefahr relativ gering. Die Assessmentergebnisse geben dann neue Zielrahmen vor, die dann aber immer noch mit konkreten Inhalten gefüllt werden müssen.

Agile Softwareentwicklung

Die agile Softwareentwicklung stellt nicht die Qualität der Prozesse in den Vordergrund, sondern stattdessen den Kunden und diejenigen Menschen, die an Erstellung des Softwareprodukts beteiligt sind. Sie kommt damit den Prinzipien des TQM nach Kundenorientierung und Einbeziehung aller Mitarbeiter nach.
Im "Manifesto for Agile Software Development" gibt sie entscheidende Werte vor:

Menschen und Zusammenarbeit sind wichtiger als Prozesse und Werkzeuge,

funktionierende Software wichtiger als eine umfassende Dokumentation,

Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen,

Reaktionsvermögen auf Veränderung wichtiger als die genaue Einhaltung eines Plans¹².

Diese Bewertung stellt dabei eine Priorisierung dar; die Wichtigkeit der Punkte auf der rechten Seite wird keineswegs geleugnet.
Das "Agile Manifesto" konkretisiert die vier oben genannten Leitlinien durch zwölf Prinzipien, deren wichtigstes die Zufriedenheit des Kunden aufgrund früher und regelmäßiger Lieferung von brauchbarer Software¹³ ist.

Agile Methoden
Verschiedene agile Methoden mit zum Teil recht unterschiedlichen Ansätzen richten sich nach diesen Prinzipien. Bei der "Agile Alliance (http://www.agilealliance.com/)" sind die folgenden Methoden zusammengefasst: Agile Database Techniques (AD), Agile Modeling (AM), Adaptive Software Development (ASD), Crystal, Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Lean Software Development, Scrum, Test-Driven Development (TDD), XBreed, eXtreme Programming (XP).
Agile Methoden setzen viele Ideen des Total Quality Managements um:
Das Lean Software Development beruft sich zum Beispiel explizit auf die Ideen des "Lean Manufacturings" und des TQM und leitet daraus zehn Regeln für eine "schlanke Softwareentwicklung" ab.
Die Kundenzufriedenheit soll durch schnelle und regelmäßige Auslieferung einer laufenden Software gewährleistet werden. In Scrum wurde dazu die Praktik des Sprints eingeführt, bei dem in einem vorgegebenen Zeitraum von etwa einem Monat zuvor gewählte Anforderungen umgesetzt werden müssen. Dieses Abarbeiten einer Auswahl von kleineren Anforderungen ist auch der Ansatz des Feature Driven Developments. Die Selektion und Priorisierung der zu implementierenden Teilanforderungen ermöglicht es dem Kunden, unmittelbar Einfluss auf Funktionalität und Qualität des Produkts zu nehmen.
Die aktive Qualitätsplanung ist das Leitmotiv des Test Driven Developments. Durch die Praktik des "Test First" wird eine in die Entwicklung integrierte Qualitätssicherung generiert. Noch bevor das eigentliche Modul implementiert wird, sind schon die Testfälle dafür definiert und programmiert.

eXtreme Programming (XP)
Auch das eXtreme Programming¹⁴, die bekannteste und am weitesten verbreitete agile Methode verwendet diese Praktik. Insgesamt basiert XP auf den vier Werten Einfachheit, Kommunikation, Feedback und Mut sowie, ähnlich wie das TQM, auf 15 Prinzipien, wie "Einfachheit anstreben", "Qualitätsarbeit", "Veränderungen begrüßen", "inkrementelle Veränderung" oder "unmittelbares Feedback". Ergänzend stellt XP 14 Praktiken zur Verfügung:

Einfaches Design

Pair Programming

Test First

Refactoring

Gemeinsame Verantwortlichkeit

Kontinuierliche Integration

Nachhaltiges Tempo

Programmierstandards

Metapher

Standup-Meeting

Kurze Iterationen

Retrospektive

Planungsspiel

Kunde vor Ort

Diese Techniken stellen nicht nur eine lose Sammlung von Best Practices dar, sondern sie besitzen untereinander zahlreiche Abhängigkeiten. Damit stellt XP eine Vorgehensweise dar, die sogar in weiten Teilen dem Level 3 des SW-CMM¹⁵ genügt¹⁶.

Grenzen der Agilität
Agile Methoden haben sich in den letzten Jahren als wichtiges Mittel zur Steigerung von Softwarequalität bewährt. Der Einsatz agiler Methoden verringert zudem das Risiko des Scheiterns von Softwareentwicklungsprojekten. Allerdings ist die Einführung agiler Methoden keinesfalls als Allheilmittel anzusehen. Insbesondere der unbedarfte Einsatz nur einzelner agiler Techniken kann sogar zu einem erheblichen Qualitätsverlust führen. Aber auch bei regulärer Anwendung sind die Einsatzmöglichkeiten agiler Methoden begrenzt.
Damit die Vorteile agiler Softwareentwicklung optimal genutzt werden können, ist eine Begrenzung der Teamgröße auf etwa 2 bis 10 Personen sinnvoll. Bei größeren Projekten ist es meist möglich, diese in kleinere, agile Teilprojekte zu untergliedern. Dabei entsteht dann ein zusätzlicher Aufwand durch die Koordination der einzelnen Entwicklungsstränge. Dieser Koordinationsprozess muss in adäquater Weise kontrolliert durchgeführt werden.
Bei der Entwicklung sicherheitskritischer Anwendungen ist eine unabhängige Qualitätssicherung angeraten und teilweise vorgeschrieben. Diese Qualitätssicherung ist eine Ergänzung zur aktiven Qualitätsplanung und kann diese nicht ersetzen. Gerade auch im Fall sicherheitskritischer Anwendungen kann nicht auf Dokumentation verzichtet werden. Aber auch bei anderen Entwicklungsprojekten ist ein gewisses Maß an Dokumentation angebracht. Bei agiler Softwareentwicklung sollte daher nicht darauf verzichtet werden, es muss lediglich geprüft werden, was tatsächlich dokumentiert werden muss.
Im Allgemeinen sind auch in der agilen Softwareentwicklungen Änderungen nicht zu jeder Zeit umsetzbar. Mit jeder neuen Iteration wird der Aufwand größer, neue oder geänderte Anforderungen umzusetzen.

Agile Methoden stellen ein wohlüberlegtes und geplantes Vorgehen in der Softwareentwicklung dar, sie sind also keinesfalls mit "Hacking" zu verwechseln¹⁷. Nicht jedes Projekt lässt sich aber gleichermaßen gut mittels agiler Methoden umsetzen. Vor dem eigentlichen Projektstart sollte daher sorgfältig abgewogen werden, ob und wie das Projekt agil umgesetzt werden soll.

Eine exemplarische Anleitung zur Qualitätsverbesserung

Wie oben teilweise gezeigt existieren eine Reihe von sinnvollen Ansätzen, wie die Qualität von Software gesteigert werden kann. Diese Vielfalt macht aber die Umsetzung der angebrachten Maßnahmen nicht unbedingt leichter. Mit dem prozessorientierten Qualitätsmanagement und der agilen Softwareentwicklung liegen zudem zwei scheinbar völlig unterschiedliche Ansätze vor: Bei der Prozessorientierung wird Qualität von einer übergeordneten Position aus bewertet, wodurch eine größere Objektivität erreicht werden kann. Agile Methoden setzen auf Qualitätsverbesserung schon auf Entwicklerebene. Qualität soll direkt bei der Entstehung eines Produkts gefördert werden. Dadurch kann eine schnellere Akzeptanz erreicht werden.
Tatsächlich existiert kein Königsweg zur Qualität. Qualitätsverbessernde Maßnahmen müssen für das Unternehmen passen, Prozesse müssen richtig zugeschnitten sein. Daher soll die nachfolgende Liste auch nicht als Ultima Ratio erscheinen, sondern lediglich eine Hilfestellung auf dem Weg zur besseren Softwarequalität darstellen.

10 Schritte zur Qualitätsverbesserung:
Schritt 1: Stellen Sie einen Konsens darüber her, dass Qualität das oberste Ziel darstellt. Diese zentrale Forderung des TQM ist heutzutage wichtiger denn je. Schneller und billiger können viele produzieren. Der entscheidende Geschäftsvorteil kann nur in hochwertiger Qualität liegen (in der geforderten Zeit zu einem akzeptablen Preis).
Schritt 2: Führen Sie ein ehrliches Assessment durch. Dies kann ein Selbst-Assessment sein. Wichtig ist die Probleme offen aufzudecken, ohne Schuldzuweisungen zu machen. Achten Sie dabei auf den Stellenwert der einzelnen Prozesse für Ihr Unternehmen. Nicht alle Prozesse müssen für Ihr Unternehmen relevant sein.
Schritt 3: Sorgen Sie für Transparenz und Offenheit. Nur wer ausreichend informiert ist, kann auch die richtigen Entscheidungen treffen. Verheimlichen von Informationen führt zu Misstrauen.
Schritt 4: Suchen Sie Lösungen dort, wo die Probleme auftreten. Vertrauen Sie dabei Ihren Mitarbeitern. Diese kennen die Probleme am besten und können daher in der Regel auch die besten Vorschläge zur Problemlösung machen. Soweit es möglich ist, sollten Verbesserungen direkt lokal umgesetzt werden und nicht erst auf Anordnung einer übergeordneten Stelle.
Schritt 5: Werden Sie agil. Setzen Sie agile Methoden ein, wann immer es geht. Aber überprüfen Sie vorher sorgfältig, ob Ihr Einsatz auch tatsächlich sinnvoll ist. Viele Probleme lassen sich elegant auf eine "schlanke" Art und Weise lösen, auch wenn dies nicht von vornherein offensichtlich ist.
Schritt 6: Nutzen Sie Erkenntnisse und Verbesserungen aus einzelnen Projekten für das ganze Unternehmen. Führen Sie Qualitätszirkel ein. Füllen Sie einen Qualitätswissenspool mit bewährten Methoden.
Schritt 7: Integrieren sie die Software-Qualitätssicherung in die Entwicklung. Qualität sichern heißt weniger geleistete Arbeit zu kontrollieren als dabei zu helfen, Arbeit qualitativ hochwertig zu leisten.
Schritt 8: Binden Sie Ihre Kunden in Ihre Projekte ein. Überzeugen Sie sie von den Vorteilen, die Ihnen Ihre aktive Mitarbeit bringt. Auch hier schaffen Transparenz und Offenheit Vertrauen.
Schritt 9: Seien Sie für Ihre Zulieferer der Kunde, den sie sich selbst wünschen. Ihre aktive Unterstützung fördert letztendlich die Qualität Ihres eigenen Produkts.
Schritt 10: Wiederholen Sie Self-Assessments regelmäßig. Es gibt immer etwas zu verbessern. Erreichte Verbesserungen erhöhen die Motivation, weitere qualitätsverbessernde Maßnahmen durchzuführen.

Sowohl Planbarkeit als auch Flexibilität sind im modernen Software-Qualitätsmanagement erforderlich. Wägen Sie stets das richtige Verhältnis von Ordnung einerseits und Agilität andererseits ab.

---

^* Dr. rer. nat. Olaf Stefan Göhrs ist Mitanbieter der Website www.jur-psv.de - juristisches Projekt Supervising; Herr Göhrs hat über Informationsflüsse in chaotischen Systemen promoviert und ist seither in unterschiedlichen Bereichen der Softwareentwicklung und des Qualitätsmanagements tätig.

¹ Derartige Warnsignale können z. B. fehlende Motivation und ein hoher Krankenstand im Entwicklerteam, eine Anhäufung von Überstunden, Stillstand der Entwicklung bei Ausfall eines Entwicklers oder auch fehlende Kommunikation zwischen den Projektteilnehmern sein.

² Siehe dazu z. B.: Hummel, Malorny: "Total Quality Management", Hanser, 2002.

³ Und keineswegs, wie häufig angenommen, die Produktivität mindert.

⁴ z.B.: Verantwortung der obersten Leitung oder interne Audits.

⁵ z.B. Konfigurationsmanagement oder Schulung.

⁶ z.B. Design und Implementierund, Spezifikation oder Testen und Validierung.

⁷ Wie das Erstellen eines QM-Handbuchs oder die Festlegung von Designregeln.

⁸ Vgl.: Herzwurm, Mellis, Stelzer: "Total Quality Management in der Softwareentwicklung" (http://www.bwi.uni-stuttgart.de/fileadmin/abt9/Publikationen_Herzwurm/tqmswe.pdf), 1995.

⁹ Siehe z. B.: Kneuper, "CMMI", dpunkt.verlag, 2003. (http://www.sei.cmu.edu/cmmi/)

¹⁰ "Standard CMMI Appraisal Method for Process Improvement".

¹¹ "Software Process Improvement and Capability dEtermination".

¹² "- Individuals and interactions over processes and tools, - Working software over comprehensive documentation, - Customer collaboration over contract negotiation, - Responding to change over following a plan."

¹³ "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

¹⁴ Siehe z. B.: http://www.extremeprogramming.org oder http://www.xprogramming.com.

¹⁵ "Software Capability Maturity Model", Vorläufer des CMMI.

¹⁶ Siehe: Paulk, M. C., "Extreme Programming From a CMM Perspective," IEEE Software, 18(6), S. 19-26, 2001.

¹⁷ Da agile Methoden wie eXtreme Programming derzeit en vogue sind, wird planlose Entwicklung bei fehlender Dokumentation derzeit leider gerne als agil verkauft.