Agiles Qualitätsmanagement

Transkript

1 Hochschule für Oekonomie und Management Essen Berufsbegleitender Studiengang zum M.A. IT-Management 2. Semester Seminararbeit im Fach Software-Engineering Agiles Qualitätsmanagement Dozent: Prof. Dr. Gregor Sandhaus Autor: Björn Berg (285557) Mülheim an der Ruhr, 27. Juni 2012

2 I Inhaltsverzeichnis Abbildungsverzeichnis Abkürzungsverzeichnis Tabellenverzeichnis III IV V 1 Mangelnde Softwarequalität 1 2 Softwarequalitätsmanagement Einführung in das Qualitätsmanagement Qualitätsmerkmale ISO 9001-Ansatz Kundenorientierung Prozessorientierung Dokumentation Kontinuierliche Verbesserung Produktrealisierung Agile Softwaremethoden Agiles Manifesto Extreme Programming Stories und Real Customer Involvement Cycles und Incremental Design Test-Driven Development Continuous Integration Continuous Delivery Agiles Qualitätsmanagement Qualitätsmerkmale Kundenorientierung Prozessorientierung Dokumentation Kontinuierliche Verbesserung Produktrealisierung Test-Driven Development Continuous Integration Continuous Delivery

3 II 5 Fazit 17 A Teilmerkmale aus der ISO A.1 Funktionalität A.2 Zuverlässigkeit A.3 Benutzbarkeit A.4 Effizienz A.5 Änderbarkeit A.6 Übertragbarkeit B Struktur von ISO 9001: C Deployment-Verfahren 22 C.1 Blue-Green-Deployment C.2 Canary Releasing C.3 Dark Launching

4 III Abbildungsverzeichnis 2.1 Prozessmodell der ISO 9000: Agile Entwicklung im Vergleich Test Driven Development Kreislauf Continuous Integration und Continuous Delivery

5 IV Abkürzungsverzeichnis CI Continuous Integration CD Continuous Delivery CMM Capability Maturity Model IEC International Electrotechnical Commission ISO International Standardization Organisation KMU Kleine und mittelständische Unternehmen KV kontinuierliche Verbesserung KVP kontinuierlicher Verbersserungsprozess NSN Nokia Siemens Networks SCM Source Code Management SPICE Software Process Improvement and Capability Determination TDD Test-Driven Development XP Extreme Programming

6 V Tabellenverzeichnis B.1 Struktur der ISO 9001:

7 1 1 Mangelnde Softwarequalität In Software-Projekten, die nach einem klassischen Modell (z.b. Wasserfallmodell, V-Modell) ausgerichtet sind, kommt es nicht selten kurz vor dem Liefertermin zu Engpässen: Testfälle fehlen oder sind unzureichend. Lücken zwischen Spezifikation und Implementierung werden zu spät entdeckt. Änderungen an Querschnittsfunktionen gefährden die Stabilität der Software 1. Zur Bewältigung dieser Probleme hat sich die Einführung von Prozessen aus der agilen Softwareentwicklung bewährt. Es ist allerdings verbreitete Meinung, dass agile Softwareentwicklung zu Chaos führt, denn es gibt keinen detaillierten Projektplan und keine messbaren Größen 2. Mangelhafte oder fehlende Dokumentation steht im Konflikt zu den Methoden der Qualitätsicherung nach ISO 9001 oder CMM. Die Zertifizierung von Qualitätssicherungsmaßnahmen ist ein nicht zu unterschätzender Wettbewerbsvorteil und eine notwendige Voraussetzung, wenn Software an regulierte Branchen geliefert wird 3. Weder die Normen der ISO, noch Zertifizierungen nach CMM oder SPICE 4 schreiben einen Entwicklungszyklus vor, der agilen Methoden vollständig widerspricht 5. Vielmehr muss die richtige Mischung aus sequenzieller Projektsteuerung, agilen Entwicklungstechniken und Dokumentationsaufwand gefunden werden, um mit agilen Methoden die geforderte Konformität zu erreichen. Der Fokus dieser Seminararbeit liegt auf den agilen Ansätzen zur Qualitätssicherung in Softwareprojekten. Zunächst wird der Begriff Qualität definiert und ausgesuchte Metriken vorgestellt, um Qualität messbar zu machen. Kern für die Methodik ist die Norm ISO 9001:2000 für die offizielle Zertifizierung. Anschließend werden agile Methoden vorgestellt, deren primärer Fokus auf Qualitätssicherung und -steigerung gerichtet ist. Dies beinhaltet wiederum Metriken zum Nachweis der Qualitätsverbesserung und auch Performancesteigerungen bzgl. Time-to-Market und Defect Management. In Kapitel 4 werden die Kernaussagen der agilen Modelle mit den Anforderungen des Qualitätsmanagements nach ISO 9001 abgeglichen und versucht, Best Practice-Ansätze aufzuzeigen. Als Beleg für die Umsetzbarkeit und Machbarkeit der vorgestellten theoretischen Grundlagen werden Forschungsarbeiten von Nokia Siemens Networks (NSN) 6 herangezogen. Abschließend wird ein Fazit zur Anwendbarkeit gezogen. 1 Vgl. Tysiak/Vegh (2011), S Vgl. Stober/Hansmann (2010), S. 94 f. 2 Vgl. Kriescher/Markgraf (2011), abgerufen am: Vgl. Cohn (2010), S Vgl. Lami/Falcini (2009), S Vgl. Cohn (2010), S Vgl. Marchenko/Abrahamsson/Ihme (2009); Korhonen (2009).

8 2 2 Softwarequalitätsmanagement Soll Software an regulierte Branchen geliefert werden, kann eine Zertifizierung nach einer ISO-Norm Bedingung sein, um den Zuschlag für einen Auftrag zu erhalten. Exemplarisch seien hier ISO 9001 (Qualitätsmanagement) oder ISO/IEC (Leistungsfähigkeit des Softwareentwicklungsprozess) genannt. Abhängig von der Branche können weitere Zertifizierungen gefordert sein. Wird Software an einen Generalunternehmer geliefert, kann dieser eine Zertifizierung nach CMM oder SPICE (ISO/IEC 15504) fordern; betreibt ein börsennotiertes Unternehmen in den USA die Software, muss sie konform zum Sarbanes-Oxley-Act sein. Die Menge der zu erfüllenden Kriterien und beizubringenden Dokumente, um Qualität und Fehlerfreiheit einer Software zu gewährleisten, können folglich je nach Branche und Land umfangreich werden. Im Verlauf des weiteren Kapitels werden zunächst die Begriffe Qualität und Qualitätsmanagement definiert. Anschließend wird die ISO 9001 kurz vorgestellt. 2.1 Einführung in das Qualitätsmanagement Bevor Qualitätsmanagement betrachtet werden kann, muss der Begriff Qualität definiert werden. Normungsausschüsse und Softwareentwickler, die sich mit Qualitätsssicherung beschäftigt haben, liefern unterschiedliche Ansätze zur Definition von Qualität. Die ISO/IEC (früher ISO 9126) definiert Qualität für Software als...die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen 7. Rätzmann 8 wählt eine einfachere Definition: Qualität kann nicht hergestellt werden: Es können nur Qualitätsmängel festgestellt werden. Dieser pragmatische Ansatz zeigt zwei Probleme auf: Zum einen kann die Qualität für ein Produkt nicht gewährleistet werden, sondern nur die Abwesenheit von Fehlern unter definierten Bedingungen. Zum anderen können die Prozesse zur Softwareentwicklung fehlerbehaftet bzw. unvollständig sein, so dass Qualitätsmängel nicht oder zu spät aufgedeckt werden. Das bedeutet, dass grundsätzlich zwischen der Qualität des Produkts und der Qualität des Entwicklungs-, Betriebs- und Wartungsprozesses unterschieden werden muss 9. Daraus 7 Balzert (1998), S Vgl. Rätzmann (2004), S Vgl. Wallmüller (2001), S. 7.

9 3 lässt sich eine Definition für ein produkt- und prozessorientiertes Qualitätsmanagement ableiten 10 : Produktorientiertes Qualitätsmanagement bedeutet, Software-Produkte und Zwischenergebnisse auf vorher festgelegte Qualitätsmerkmale zu überprüfen. Bei Anwendungssoftware gehören Gütebedingungen und Prüfbestimmungen dazu, die Gegenstand einer Zertifizierung sein können. Prozessorientiertes Qualitätsmanagement bezieht sich auf den Erstellungsprozess der Software. Dazu gehören Methoden, Werkzeuge, Richtlinien und Standards. Die Erfahrungen der Vergangenheit haben gezeigt, dass die Produktqualität maßgeblich durch die Qualität des Erstellungsprozesses beeinflusst wird. Werden Mängel frühzeitig erkannt, können die relativen Fehlerbehebungskosten gering gehalten werden. Es gibt verschiedene Ansätze, um die Prozessqualität zu verbessern 11 : ISO 9001, Total Quality Management, Capability Maturity Model, SPICE (ISO/IEC 15504), Business Engineering. Im weiteren Verlauf der Arbeit wird der ISO 9001-Ansatz betrachtet und zur Bewertung des Reifegrades auf den SPICE-Ansatz verwiesen, der in dieser Arbeit aufgrund seiner Komplexität nicht genauer betrachtet werden soll. 2.2 Qualitätsmerkmale Software-Qualität wird im Allgemeinen durch Qualitätsmerkmale beschrieben, die durch Teilmerkmale/ Kriterien weiter verfeinert werden. Der Anhang der ISO definiert Vorschläge für Teilmerkmale/ Kriterien. Diese sind dem Anhang A der Arbeit beigefügt. Die zu definierenden Kriterien spiegeln softwareorientierte Charakteristika wider, während die Qualitätsmerkmale eher der benutzerorientierten Sichtweise entsprechen. Durch Qualitätsindikatoren bzw. Metriken werden die Kriterien mess- und bewertbar gemacht 12. Die ISO definiert sechs Qualitätsmerkmale für Software-Produkte 13 : Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit. Um Software-Qualität messen zu können, muss zunächst definiert werden, an welchen Stellen im Entwicklungsprozess Mängel auftreten können. Dazu dienen Modelle wie der ISO 9001-Ansatz, CMM oder SPICE. 2.3 ISO 9001-Ansatz Der ISO 9001-Ansatz gehört zu einer Normenreihe bestehend aus den Normen ISO 9001 (Qualitätsmanagementsystem-Forderungen), ISO 9004 (Qualitätsmanagementsystem-Leitfaden 10 Vgl. Balzert (1998), S Vgl. ebd., S Vgl. ebd., S Vgl. ebd.

10 4 zur Leistungsverbesserung), der Norm ISO 9000 (Grundlagen und Begriffe) und dem Auditleitfaden ISO Die ISO 9001 beschreibt die Forderungen an das Qualitätsmanagementsysten zum Nachweis der Fähigkeit, Kundenforderungen zu erfüllen und fehlerfreie Produkte zu erstellen 14. Zur Zeit werden zwei verschiedene Normen durch die International Organization for Standardization (ISO) für das Qualitätsmanagement gepflegt: ISO 9001:2000 und ISO 9001:2008. Die hintere Zahl gibt jeweils das Jahr der Version an. Die Norm dient dazu die acht Grundsätze des Qualitätsmanagements nachweislich zu erfüllen, um die geforderten Qualitätsziele zu erreichen 15 : Kundenorientierte Organisation, Führung, Einbeziehung der Mitarbeiter, Prozessorientierter Ansatz, Systemorientierter Managementansatz, Kontinuierliche Verbesserung, Sachlicher Ansatz zur Entscheidungsfindung, Lieferantenbeziehung zum gegenseitigen Nutzen. Auf ausgewählte Grundsätze wird im Folgenden detaillierter eingegangen Kundenorientierung Die Norm fordert von der Leitung der Organisation, die Prozesse des Managementsystems auf die Forderungen der Kunden auszurichten... [und die] Forderungen und Erwartungen der Kunden 16 in der gesamten Organisation bekannt zu machen Prozessorientierung Der Norm liegt das in Abbildung 2.1 dargestellte Prozessmodell zugrunde. Dieses verdeutlicht die Notwendigkeit geschlossener Regelkreise. Abbildung 2.1: Prozessmodell der ISO 9000:2000 Entnommen aus: Wallmüller (2001), S Vgl. Wallmüller (2001), S Vgl. ebd. 16 Vgl. ebd., S. 317.

11 5 Die Umsetzung des Produkts beginnt beim Kunden mit der Ermittlung seiner Forderungen und endet beim Kunden nach der Lieferung und der Ermittlung seiner Zufriedenheit. Aufgabe der Organisation und insbesondere des Managements sind die Ermittlung und Bereitstellung der benötigten Ressourcen, die Erarbeitung und Überwachung der Prozesse zur Produktrealisierung sowie die Messung, Analyse und Verbesserung der internen Prozesse. Die Kundenzufriedenheit stellt ein Maß für die Leistung des Managementsystems dar. Dazu gehören beispielsweise Aussagen zur Benutzbarkeit, Funktionalität und Zuverlässigkeit des erstellen Produkts (vgl. Kapitel 2.2) 18. Die Norm selbst ist folglich kein Qualitätsmerkmal für eine Software, sondern definiert lediglich, die bei der Erstellung eines Produktes einzuhaltenden formalen Praktiken. Ein Großteil der Arbeit zur Erfüllung der Zertifizierung besteht in der Pflege eines Qualitätshandbuchs Dokumentation Die alte ISO 9001:1994 hatte den Nachteil, dass sie viele dokumentierte Verfahrensanweisungen forderte, die beispielsweise von kleinen Organisationen schwierig zu erfüllen waren und in Bürokratismus ausarteten 20. Das oben bereits erwähnte Qualitätshandbuch 21 kann als ein umfangreiches Dokument oder eine Reihe von Webseiten geführt werden, worin die Organisation die befolgten Praktiken beschreibt. Dazu gehören beispielsweise eine ausführliche Designdokumentation 22, ein Handbuch zum Konfigurationsmanagement, ausführliche Testdokumentationen u.v.m 23. Seit der ISO 9001:2000 ist eine gewisse Flexibilität eingebaut, so dass der Dokumentationsumfang abhängig von der Größe und Art des Unternehmens, der verwendeten Methoden und Praktiken sowie der Komplexität der Prozesse ist. Die Normenabschnitte 4-8 benennen die mindestens zu dokumentierenden Verfahren explizit. Diese müssen im Qualitätshandbuch beschrieben oder zumindest referenziert sein. Dazu gehören exemplarisch 24 : Planungsmethoden, Kommunikation, Kundenorientierung, Ressourcen, Monitoring der Prozesse, Verfahren zur kontinuierlichen Verbesserung, etc Kontinuierliche Verbesserung Eine weitere Forderung ist die kontinuierliche Verbesserung (KV) der Wirksamkeit des Managementsystems. Nur ein ausgereiftes und optimiertes System kann die Organisation unterstützen, die gewünschte Qualitätspolitik zu etablieren und die definierten Qualitätsziele zu erreichen. Insbesondere kleine und mittelständische Unternehmen (KMU) sehen 18 Vgl. Wallmüller (2001), S. 317 f. 19 Vgl. Cohn (2010), S Vgl. Wallmüller (2001), S Vgl. Glaap (1993), S. 83 f. 22 Vgl. Cohn (2010), S Vgl. Balzert (1998), S Die grobe Struktur der ISO 9001:2000 ist in Anhang B auf S. 21 dargestellt. 25 Vgl. Wallmüller (2001), S. 319.

12 6 diese Argumentation kritisch und argumentieren, dass ein funktionierendes System nicht kontinuierlich verbessert werden muss Produktrealisierung Zur Produktrealisierung gehört ebenfalls die Qualitätsplanung (bspw. Festlegung der Qualitätsmerkmale) und die Festlegung der Prozesse zur Realisierung. Dabei werden zunächst die Kundenforderungen ermittelt und bewertet sowie nicht spezifizierte Forderungen identifiziert, die für den Verwendungszweck notwendig sind 27. Vor dem Eingehen einer Lieferverpflichtung sind die Kundenforderungen zur Lieferbarkeit, Auslieferung und Unterstützung (Support-Level) zu ermitteln, zu überprüfen und dem Kunden gegenüber zu bestätigen 28. Im Rahmen der Kundenkommunikation muss festgehalten werden, wie Angebots- und Auftragsbearbeitung, Kundenbeschwerden und die Meldung von Fehlern (Defects) gehandhabt werden 29. Im Designhandbuch müssen die Kundenanforderungen, gesetzliche und behördliche Forderungen, Forderungen des Marktes und Umweltforderungen dargelegt sein. Ebenfalls ist neben der Designdokumentation eine Testdokumentation zu führen, die die Ergebnisse der Verifizierung der Design- und Entwicklungsvorgaben aufzeichnet. Bei Durchführung von Änderungen am Code sind die daraus resultierenden Wirkungen zu ermitteln und ebenfalls aufzuzeichnen. 26 Wallmüller (2001), S Vgl. ebd., S Vgl. ebd. 29 Vgl. ebd., S. 323.

13 7 3 Agile Softwaremethoden Dieses Kapitel gibt zunächst einen Überblick über die Gemeinsamkeiten agiler Softwareentwicklungsmethoden (Kapitel 3.1) und beschreibt anschließend in Kapitel 3.2 das Extreme Programming nach Beck, das am umfassendsten die Grundsätze der Lean Software Production in eine Methodik überführt hat und neben organisatorischen Maßnahmen auch Maßnahmen zur Qualitässicherung definiert. 3.1 Agiles Manifesto In der Automobilbranche herrscht der durch Toyota initiierte Ansatz Kaizen bzw. der Ansatz des kontinuierlichen Verbesserungsprozesses (KVP) vor 30. Verschlankte Produktionen stehen seitdem für Produktivität, Flexibilität, Geschwindigkeit und Anpassbarkeit an sich ändernde Gegebenheiten. Dieser Ansatz führt zu einer Lean Production, die weder besonders bürokratisch noch stark reguliert ist. Zu den Best Practice-Ansätzen der Lean Production gehören neun Kernaussagen: Suche nach der Wurzel für einen Fehler, Fokus liegt auf dem Kunden, dezentrale Verantwortung, Fokus auf Teamarbeit und -zusammenarbeit, kontinuierliche Verbesserung, Flexibilität bezogen auf die Änderungswünsche von Kunden, Standardisierung von Prozessen, vorausschauendes und planerisches Denken, einfache und pragmatische Tools 31. Die Softwareentwicklung als Ingenieurwissenschaft hat diese Denkweise aufgegriffen und neue Modelle gesucht, um ein Lean Software Development in der IT-Industrie zu etablieren. Verschiedene Modelle zur Organisation von Teams und Strukturierung der Entwicklungszyklen sind entwickelt worden. Cockburn fasst die Gedankenmodelle als...verwendung von einfachen aber erfolgreichen Regeln zum Projektverhalten sowie der Gebrauch von mensch- und kommunikationsorientierten Regeln zusammen 32. Im Februar 2001 trafen sich in Snowboard (Utah) die prominentesten Vertreter der verschiedenen Methodiken der agilen Softwareentwicklung, um Gemeinsamkeiten zu finden und diese in einfachen Leitsätzen festzuhalten. Auf der Konferenz wurde neben den Leitsätzen auch der Begriff agil geprägt, da die Versammelten der Meinung waren, dass leichtgewichtig (lean) eher eine Abneigung gegen etwas vermittelt Vgl. Beck/Andres (2010), S Vgl. Stober/Hansmann (2010), S Cockburn (2003), S Vgl. ebd., S. 281 f.

14 8 Festgehalten wurden vier Werte oder Leitsätze, die durch zwölf weitere Prinzipien unterstützt werden und die aus der Lean Production abgeleitet sind 34 : 1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. 2. Funktionierende Software ist wichtiger als umfassende Dokumentation. 3. Kundenzusammenarbeit ist wichtiger als Vertragsverhandlungen. 4. Auf Änderungen reagieren ist wichtiger als einen Plan zu verfolgen. Im Folgenden wird auf Extreme Programming (XP) genauer eingegangen, denn die dort genutzten agilen Praktiken werden auch von anderen Methoden wie Scrum oder Pragmatic Programming genutzt. Lediglich organisatorische Aspekte differieren in diesen Modellen. 3.2 Extreme Programming Extreme Programming (XP) 35 ist eine agile Methode, die von Beck definiert worden ist und auf gelebten Werten, Prinzipien und Praktiken beruht. XP basiert auf dem Paradigma der Veränderung. Software ist kein statisches Produkt, sondern wird getrieben und verändert durch neue Anforderungen, Designänderungen, gesetzliche Regelungen u.v.a 36. Beck definiert nicht die Veränderung als Problem, sondern den Umgang mit der Veränderung. Starre, klassische Modelle können mit kurzfristigen Veränderungen weniger gut umgehen, als dies mit agilen Modellen möglich ist. Hinzu kommen wirtschaftliche Aspekte, wie der zeitliche Wert von Geld und der zukünftige Wert eines Softwareproduktes. Je eher mit einem Produkt Geld verdient werden kann, um so besser ist dies für die Organisation, denn Geld ist heute mehr wert als morgen 37. Abbildung 3.1: Agile Entwicklung im Vergleich zu klassischen Modellen In Anlehnung an: Stober/Hansmann (2010), S Vgl. Cockburn (2003); Stober/Hansmann (2010). 35 Vgl. Beck/Andres (2010), S. 1 f. 36 Vgl. ebd., S Vgl. ebd., S. 25.

15 9 Klassische Modelle gehen davon aus, dass frühzeitig sorgfältig ein langfristiger Plan aufgestellt werden muss, der zukünftiges Design und zukünftige Anforderungen berücksichtigt. Agile Methoden schaffen den Wert früher. Es werden keine Aussagen über die langfristige Zukunft getroffen, sondern es geht um die Herausforderungen des Jetzt. Langfristige Planung nach traditionellem Design liefert den Wert später zurück und sorgt dafür, dass keine Fehler für die Zukunft gemacht werden 39. Um die Geschwindigkeit der Softwareentwicklung zu erhöhen und trotzdem eine hohe Qualität zu gewährleisten, definiert Beck die Praktiken: Pair Programming, Stories, Cycles, Ten-Minute Build, Continuous Integration, Test-First Programming, Incremental Design, Real Customer Involvement, Shared Code, Automatic Testing, Daily Deployment. Cockburn definiert die Essenz von XP wie folgt: XP ist eine hochdisziplinierte Methodik. XP verlangt die enge Befolgung der strikten Code- und Designstandards, strenge Verfahren für Unit-Tests, die jederzeit bestanden werden müssen, gute Akzeptanztests, konstantes paarweises Arbeiten, Gespür für einfaches Design und aggressive Refaktorisierung 40. Einige dieser Praktiken werden in den nachfolgenden Abschnitten detaillierter beschrieben. 3.3 Stories und Real Customer Involvement Stories sind in XP schriftlich fixierte Anforderungen des Kunden oder der Entwickler an Features. Beck schlägt vor, den Kunden über den gesamten Entwicklungszyklus eines Features mit einzubeziehen und regelmäßig Feedback einzufordern 41. Das neue Feature wird entweder direkt durch den Kunden oder die Entwickler prosaisch formuliert und auf einer Karteikarte festgehalten. Stories auf einem Storyboard (Wandtafel) sind somit vergleichbar mit dem Anforderungsdokument (System Requirements) der klassischen Lebenszyklusmodelle wie Wasserfalloder Spiralmodell und werden nach Wichtigkeit bewertet umgesetzt 42. Die Programmierer schätzen die benötigte Zeit für eine Story; anschließend kann der Kunde Prioritäten setzen bzw. verändern, damit die neue Funktionalität in der gesetzten Zeit fertiggestellt werden kann Cycles und Incremental Design Beck schlägt in seinem Buch Extreme Programming Explained vor, die Entwicklung in Zyklen bzw. Iterationen aufzuteilen 44. Jede Iteration führt zu funktionierendem, getesteten 38 Vgl. Stober/Hansmann (2010), S Vgl. ebd., S. 97 f. 40 Cockburn (2003), S Vgl. Beck/Andres (2010), S Vgl. ebd. 43 Vgl. Cockburn (2003), S Vgl. Beck/Andres (2010), S. 46.

16 10 Code, der dem Kunden direkt zur Verfügung steht 45. Dabei wird zwischen Entwicklungszyklen und Freigabezyklen unterschieden. Entwicklungszyklen können aus einem Zeitraum von einer bis drei Wochen bestehen, wobei der Freigabezyklus spätestens nach zwei bis fünf Iterationen stattfinden sollte (siehe auch Abb. 3.3). Durch diese Zyklen ist ein inkrementelles Design notwendig, wie es auch beim Rapid Prototyping genutzt wird. 3.5 Test-Driven Development Unter Test-Driven Development (TDD) oder Test-First Programming wird das kontinuierliche Testen von einzelnen Modulen nach Änderungen verstanden. Nach jeder Änderung Tests manuell erneut auszuführen, ist zeit- und kostenintensiv 46. Daher ist die Forderung von Beck, die Tests weitestgehend zu automatisieren und nach jeder Änderung durch das System ausführen zu lassen 47. Dies setzt voraus, dass eine hohe Testabdeckung für den Code geschaffen wird. Eine Maßnahme, um eine hohe Testabdeckung zu erreichen, ist das Vorgehen nach dem TDD-Modell 48. Abbildung 3.2: Test Driven Development Kreislauf Entnommen aus: Stober/Hansmann, S Beim TDD wird zunächst die neue Funktionalität kreiert, d.h. die Schnittstellen geschaffen und als Methodenrümpfe implementiert und im Anschluss die automatischen Tests erstellt. Die Tests dienen der Validierung eines schlanken Designs: Es werden nur die Funktionen implementiert, die notwendig sind, um den erstellten Testfall erfolgreich durchzuführen (vgl. Abbildung 3.2). Die Entwicklung findet in kleinen inkrementellen Zyklen von wenigen Stunden statt und die Implementierung wird anhand der Testfälle erweitert, bis alle Testfälle erfolgreich zum 45 Cockburn (2003), S Vgl. Stober/Hansmann (2010), S Vgl. Beck/Andres (2010), S Vgl. Stober/Hansmann (2010), S Vgl. ebd., S. 48

17 11 Abschluss kommen. Durch die parallele Entwicklung der Funktionalität und der Testfälle wird sichergestellt, dass eine hohe Testabdeckung (Test Coverage) erreicht wird Continuous Integration Ein automatisierter, täglicher Build-Prozess der Software ist die Mindestvoraussetzung für Continuous Integration (CI). CI soll das Problem der Integration von Code in das allen Entwicklern gemeinsam zugängliche Source Code Management-Tool (SCM) lösen 51. Codeänderungen und die zugehörigen Unit-Tests werden täglich mehrmals durch die Entwickler in das SCM eingespielt und das CI-System prüft auf Veränderungen im SCM, baut die Software und führt die entsprechenden Tests durch. Bedingung dabei ist, dass der gesamte Prozess vom Bau der Software bis zum getesteten Produkt nicht länger als zehn Minuten dauern darf (Ten-Minute Build) 52. Schlägt die Integration des Codes fehl, wird der Entwickler umgehend durch das System per , SMS oder optische Feedback-Systeme informiert. Je später modifizierter Code zurückgegeben wird, desto höher sind die Kosten, um Konflikte zwischen geänderten Codepassagen zu lösen und den Code erneut in das System zu integrieren Continuous Delivery Ziel von Continuous Delivery (CD) ist, kontinuierlich neue Funktionen in Betrieb zu nehmen. Dies führt zu einer häufigen Veröffentlichung von neuen Releases; gleichzeitig wird die Gefahr minimiert, dass schwere Fehler unbemerkt in das System gelangen 54. Die Idee wurde in Becks Extreme Programming Explained als auch im Agilen Manifest erwähnt: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 55. Durch die kontinuierliche Integration und die anschließende automatische Testdurchführung wird dafür gesorgt, dass jeder durch die Qaulitätssicherung akzeptierte Build als Release ausgeliefert werden kann (siehe auch Punkt Deployment QA). Der Deployment Cycle besteht aus drei aufeinander aufbauenden Stufen. Die Unterschiede der Stufen liegen in den zu erfüllenden Vorbedingungen und der Absicherung der Ausführung 56 : Deployment QA Der Deployment-Prozess wird durch einen Tester angestoßen. Aus dem Build-Server oder Artefakt-Repository wird das zu testende Produkt auf ein Test- System transferiert. Dort werden verschiedene Smoke-Tests und Health-Checks durchgeführt, um die grundlegende Funktionalität des Produkts zu überprüfen. Fallen die Tests negativ aus, wird der Kandidat aus dem Delivery-Prozess ausgeschlossen. 50 Vgl. Beck (2011), S. ix f. 51 Vgl. Beck/Andres (2010), S Vgl. ebd., S Vgl. ebd., S Vgl. Kamann/Wendt (2012b), S Beck/Andres (2010), S Vgl. Kamann/Wendt (2012a), S. 73.

18 12 Deployment Performance und Lasttest Die technische Basis für den Performancetest und Lasttest sollte möglichst mit dem Produktionssystem identisch sein. Die Tests werden automatisiert ausgeführt, die Ergebnisse gesammelt und durch einen Tester verifiziert. Auf dem Build-Server wird der Status des Kandidaten aktualisiert und festgehalten, dass dieser für ein Release tauglich ist. Deployment Production Die Auslieferung auf ein Produktionssystem ist stark abhängig von der Absicherung der Systeme und den Personen, die administrativen Zugriff haben. Größtes Hindernis beim Continuous Delivery ist die Bereitstellung der neuen Funktionalität, ohne dass Benutzer im Tagesgeschäft unterbrochen werden oder dass der Austausch für einen Stopp der produktiven Systeme sorgt. Hierfür gibt es theoretische Konstrukte wie Blue-Green-Deployment, Canary Releasing oder das Dark Launching 57. Abbildung 3.3: Continuous Integration und Continuous Delivery In Anlehnung an: Kamann/Wendt (2012), S Das Deployment des Produkts ist nicht Gegenstand der Arbeit, so dass auf diese Verfahren nicht weiter eingegangen wird. Im Anhang C ist eine kurze Erläuterung zu den drei Verfahren zu finden (s. S. 22). 58 Vgl. Kamann/Wendt (2012a), S. 72

19 13 4 Agiles Qualitätsmanagement Kapitel 2 hat die Grundlagen und Definitionen für Qualität und die Messung von Qualität gelegt. In Kapitel 3 wurden ausgesuchte agile Entwicklungstechniken vorgestellt, die Maßnahmen zum Qualitätsmanagement beinhalten. In diesem Kapitel sollen die Maßnahmen dem Qualitätsbegriff der ISO 9001 gegenübergestellt werden und Best Practice-Ansätze gezeigt werden, wie agile Softwaremethoden mit der ISO 9001 konform gehen können. In Kapitel 2 wurden neben Qualitätsmerkmalen ausgewählte Grundsätze des Qualitätsmanagements betrachtet. Diese dienen im Folgenden der Strukturierung des Vergleichs und der Zuordnung der agilen Ansätze zu den Forderungen der ISO Qualitätsmerkmale Oberstes Qualitätsmerkmal agiler Methoden ist die Auslieferung funktionierender Software, die den Anforderungen des Kunden entspricht und die durch umfangreiche Tests keine Defects aufweist. Durch die Automatisierung von Unit- und Integrationstests werden Kriterien der Qualitätsmerkmale wie Richtigkeit, Interoperabilität, Effizienz, u.a. automatisch geprüft. Die oberste Messgröße bzw. das aussagekräftigste Qualitätsmerkmal ist in vielen Organisationen die Anzahl der Defects 59. Diese Messgröße hat den Vorteil, dass sie sich weitestgehend automatisch erfassen lässt. Weiterhin kann diese Größe eine Aussage über die Qualität nach jeder Iteration und nach jedem Release geben und steht stellvertretend für die Merkmale Zuverlässigkeit und Änderbarkeit (siehe auch Anhang A). Eine Studie von NSN hat gezeigt, dass angepasste Metriken des Wasserfallmodells oder der ISO in agilen Projekten nützlich sind 60. Dazu kann beispielsweise auch die Time-tomarket gehören. 4.2 Kundenorientierung In XP ist der Kunde ein gleichberechtigter Partner. Er schreibt zusammen mit der Organisation die Anforderungen in Form von Stories auf und lässt diese durch die Entwickler zeitlich bewerten, so dass diese Anforderungen anhand des vorgegebenen Zeitrahmens zur Realisierung priorisiert werden können Vgl. Korhonen (2009), S Vgl. ebd., S Vgl. Cockburn (2003); Beck/Andres (2010).