Garbage in garbage out: Wie das Anforderungsmanagement die Softwarequalität beeinflusst

Transkript

1

2 Garbage in garbage out: Wie das Anforderungsmanagement die Softwarequalität beeinflusst iks Thementag Mehr Softwarequalität Ausgewählte Themen Autor: Jörg Vollmer

3 Was stört Sie im IT-Alltag am meisten? Befragt wurden 142 Software-Entwickler: 1. Unklare Anforderungen % 2. Zu häufig & schnell wechselnde Anforderungen % 3. Termindruck => Quick & Dirty % 4. Schlechtes Projektmanagement % 5. Unverständlicher Code (z.b. hist. gewachsen) % 6. Geringe oder fehlende Testabdeckung % 7. Unzureichende Kommunikation im Team % 8. Ineffektive (Entwicklungs-) Prozesse % 9. Unnötige Meetings & Diskussionen % 10. Nicht machbare Aufwandsschätzungen % Quelle: (Stand 14. Okt. 2013) Seite 3 / 76

4 Unklare Anforderungen (51.41%) Requirements Engineering = Unklare Anforderungen beseitigen! Konstruktive Maßnahmen Welche Fertigkeiten des RE helfen dabei? Sieben typische Fallen beim RE Welchen Einfluss haben Werkzeuge auf das RE? Analytische Maßnahmen Kann das RE selbst qualitativ und quantitativ bewertet werden? Wie lässt sich RE-Qualität messen und sichern? Wirkt sich RE-Qualität auf die Software-Qualität aus? Seite 4 / 76

5 Agenda Anforderungen aufnehmen Dokumentieren von Anforderungen Der Effekt von Akzeptanztests Anforderungen vermessen und validieren Verwalten von Anforderungen Zusammenfassung Seite 5 / 76

7 Aufgaben zum Projektbeginn Eine initiale Bestandsaufnahme des Projektumfelds ist unverzichtbar Auch im agilen Umfeld Wichtige Aufgaben sind Ziele des Produkts und dessen Nutzen ermitteln Ermitteln aller Stakeholder Systemkontext und -grenzen bestimmen Qualitätsanforderungen identifizieren denn sonst bleiben sie unklar Unklare Anforderungen! Seite 7 / 76

8 Beobachtungstechniken Apprenticing: Der RE wird wie ein Lehrling eingearbeitet Der RE lernt hierbei den Fachjargon kennen Arbeitsschritte hinterfragen und ineffiziente Prozesse entdecken!... Die (neue) Software ist eng mit den Geschäftsprozessen verwoben Seite 8 / 76

9 Falle 1 Ineffiziente Meetings Seite 9 / 76

10 Unnötige Meetings & Diskussionen Der RE sollte wissen: Jede Debatte, die nicht in fünf Minuten beigelegt werden kann, kann nicht durch Debattieren gelöst werden (Kent Beck) Selbstdarsteller machen andere ratlos und stumm Häufig geht es dann nicht mehr um die beste Lösung s. auch [bdw] Moderationstechniken anwenden Risiko von falschen Entscheidungen Software-Qualität Seite 10 / 76

11 Falle 2 Faule Kompromisse Seite 11 / 76

12 Unzulässige Verallgemeinerungen Stakeholder A: Bei einem Fehler muss das System anhalten Stakeholder B: Bei einem Fehler muss das System neustarten RE einigt sich mit A und B auf Im Fehlerfall wird eine Ausnahmeroutine veranlasst Fauler Kompromiss! Eine Mehrdeutigkeit in einem Anforderungsdokument steht oft für einen Konflikt bei den Stakeholdern (de Marco) Seite 12 / 76

13 Falle 3 Designfehler bei Geschäftsobjekten Seite 13 / 76

14 Das Auto soll verschiedene Farben haben Was der RE verstand: Was der Kunde wollte: Seite 14 / 76

15 Unterschiede ziehen sich durch alle Schichten Datenbank Datenmodell Service-Schicht Benutzeroberfläche Fachobjekte und deren Beziehungen identifizieren (DDD) Hohe Korrekturkosten es geht auf Kosten der Softwarequalität Seite 15 / 76

16 Falle 4 Unklare Fachbegriffe Seite 16 / 76

17 Unklare Fachbegriffe Was meinte der Banker mit Engagement? Meinte er persönlichen Einsatz oder doch eine vertragliche Verpflichtung wie beim Theater? Wikipedia Risiko bzw. Chance eines Kursverlusts oder -gewinns Die Fachabteilung Das, was die Bank verliert, wenn der Kunde bankrott ist Fachbegriffe analysieren, Glossar, ubiquitäre Sprache Seite 17 / 76

18 Best Practices Überprüfen Sie: Wurden Ihre Prozesse jemals untersucht und hinterfragt? Verlaufen Ihre (RE-) Meetings effizient und effektiv? Welche Stakeholder-Konflikte behindern Entscheidungsfindungen? Sprechen alle Stakeholder eine gemeinsame Fachsprache? Existiert ein Glossar? Seite 18 / 76

20 Anforderungen dokumentieren Anforderungen aufschreiben, das kann doch jeder Aber: Meinungen zu bestehender Dokumentation Versteht nur der, der s geschrieben hat Ist nicht mehr aktuell Die kniffligen Sonderfälle fehlen Bis man dort die richtige Stelle findet Das Wichtigste ist die Telefonliste von Ansprechpartnern Sehr viel Dokumentation wird gar nicht erst gelesen! Seite 20 / 76

21 Nichts Halbes, nichts Ganzes Seite 21 / 76

22 Wie entsteht gute (Anforderungs-) Dokumentation? Es empfiehlt sich die Verwendung einer Standardgliederung / Template RUP IEEE 830 V-Modell Volere Einleitung Zweck, Stakeholder Referenzen Übersicht Systemumfeld Architektur Benutzer Randbedingungen Anforderungen Funktionalität Qualitätsanforderungen Abnahme Akzeptanzkriterien Testszenarien Anhang Glossar Index Seite 22 / 76

23 Dokumentation in Form von Prosatext Vorteile Wird von allen Beteiligten verstanden Kein Stakeholder muss eine neue Notation erlernen Themenunabhängig universell einsetzbar Nachteile Mehrdeutigkeit leicht möglich Kann je nach Kontext verschieden interpretiert werden Es gehört zum guten Ausdruck, die Wortwahl zu variieren Missverständnisse Seite 23 / 76

24 Falle 5 Unverständliche Formulierungen Seite 24 / 76

25 Negativbeispiel Auszug aus einer Spezifikation: Funktionalität In einer Übersicht über alle noch nicht zugeordneten Geschäftspartner werden alle Geschäftspartner aller Mandanten ungleich Mandant 0 angezeigt, die bisher keinem Geschäftspartner im Mandanten 0 zugeordnet wurden. Satzstruktur zu komplex Seite 25 / 76

26 Falle 6 Versteckte Annahmen Seite 26 / 76

27 Negativbeispiel Auszug aus einer Spezifikation: Funktionalität In einer Übersicht über alle noch nicht zugeordneten Geschäftspartner werden alle Geschäftspartner aller Mandanten ungleich Mandant 0 angezeigt, die bisher keinem Geschäftspartner im Mandanten 0 zugeordnet wurden. Fragen: Was ist die Übersicht? Wo befindet sich diese? Wer ordnet was wem zu? Was ist Mandant 0? Was bedeutet im Mandanten sprachlich? Seite 27 / 76

28 Das Sophist-REgelwerk Passiv unterschlägt den Täter Beispiel: Ein Auftrag kann storniert werden Frage: Von wem? Von jedem, immer? Analyse des Prozesswortes Beispiel: Das System zeigt das Ergebnis nach der Berechnung an Prozesswort ist anzeigen. Fragen: Wem, Wie, Wann, Warum, Vergleiche und Steigerungen Beispiel: Die GUI muss schneller reagieren als beim Altsystem Frage: Um wie viel schneller? Ist eine Millionstel Sek. auch gültig? etc. Seite 28 / 76

29 Vorschlag: Satzschablonen Beispiel: Die User-Story Agile Methoden verwenden sog. User-Stories Aufbau: As a <role> I want <goal/desire> so that <benefit> Als ein Autor will ich meine Präsentation speichern können, damit ich nicht noch einmal alles eingeben muss Das damit hinterfragt den Geschäftswert Man beantwortet somit das Wer, Was und Warum / Wozu Seite 29 / 76

30 Formale Spezifikationen, Modelle Beispiele: ER-Diagramme, UML, BPEL, BPMN, DSLs, Vorteile Sind eindeutiger und aussagekräftiger Kompaktere übersichtliche Darstellung Für den geübten Leser verständlicher Der Implementierung bereits viel näher Zum Teil lässt sich Code daraus generieren Nachteile Sind nicht universell einsetzbar Syntax / Semantik muss vom Leser verstanden bzw. erlernt werden Zusätzliche Tools müssen erlernt werden evtl. Schulungen Seite 30 / 76

31 Die Mischung beider ergänzt sich positiv Vorteile Modelle können durch natürlich-sprachliche Ergänzungen verständlicher werden Prosatext kann durch Modelle eindeutiger und exakter werden Beispiel: Mathematische Texte Aus jeder nicht-negativen reellen Zahl lässt sich die Wurzel ziehen Häufig verschwindet die (Beweis-) Idee hinter der Abstraktion Seite 31 / 76

32 Beispiel Seite 32 / 76

33 Funktionale Anforderungen Prosa Der Nikolaus verteilt am eines jeden Jahres Geschenke an Kinder Die Geschenke sind unterschiedlich viel wert Jedes Kind bekommt ein oder mehrere Geschenke Ziel: Der Summenwert der Geschenke soll für jedes Kind möglichst gleich sein Aufgabe: Eine Software soll bei Eingabe der Kinderzahl und der Geschenkwerte eine gerechte Verteilung berechnen Seite 33 / 76

34 Funktionale Anforderungen Illustriert Seite 34 / 76

35 Funktionale Anforderungen Formal Voraussetzung Geschenke Gegeben seien natürliche Zahlen Kinder und eine Preisfunktion. Aufgabe Finde eine Partitionierung, sodass minimal wird, wobei. Gesamtgeschenkwert beim Kind n Seite 35 / 76

36 Abnahme: Der war Nikolaus nicht ganz testet glücklich. und Seite 36 / 76

37 Warum? Version 0.9 Die Lösungen waren anfangs z.t. völlig falsch. Der Entwickler hatte die Idee hinter der Formel zunächst nicht ganz verstanden. Version 1.0 Die Verteilung der Geschenke gefiel dem Nikolaus gar nicht: Manche Kinder bekamen viele wertlose Geschenke. Die Geschenke sollten sich doch möglichst gleich verteilen! Version 1.1 Der katastrophale Fall Kinderheim : 50 Geschenke, 20 Kinder: Die Anwendung antwortet nicht mehr! Seite 37 / 76

38 Falle 7 Seite 38 / 76

39 Erkenntnis Selbst eine vollständige Doch und widerspruchsfreie wie lässt sich das Spezifikationen Problem bekämpfen? garantiert keine gute Software! Seite 39 / 76

40 Specification by Example Zwei Kinder, 6 Geschenke im Wert von 1, 2, 2, 4, 6, 9 Euro Lösung: = 12 = Ungültig: = 11 < 13 = Zwei Kinder, 6 Geschenke im Wert von 1, 2, 2, 4, 5, 9 Euro Lösung: = 11 < 12 = Zwei Kinder, 10 Geschenke im Wert von 1, 1, 1, 1, 1, 1, 1, 1, 4, 4 Euro Lösung: = 8 = Schlecht: = 8 = Kinder, 50 Geschenke im Wert von jeweils 1 Euro Lösung: 10 Kinder: 1 + 1, 10 Kinder: usw. Seite 40 / 76

41 Klassisch: Stille Post Klassisches Vorgehen: Kunde anhand von Beispielen Requirements Engineer Der RE abstrahiert und formuliert eine Spezifikation Entwickler Tester Kunde anhand der Spezifikation anhand der Spezifikation anhand von Akzeptanzkriterien Software Testfälle Abnahme Seite 41 / 76

42 Idee des Acceptance Test Driven Development Beispiele werden zu Tests reflektieren verifizieren Anforderungen Seite 42 / 76

43 Wer schreibt Akzeptanztests? RE und Entwickler erstellen zusammen Akzeptanztests Diese werden in natürlicher Sprache verfasst Vorrangiges Ziel ist ein gemeinsames Verständnis der Anforderung! Schön wäre ein einheitliches Format (Satzschablone)...mit dem Ziel, daraus Test-Code generieren zu können Dies ist die Idee das sog. Behavior Driven Development (BDD) Seite 43 / 76

44 Angenommen falls dann Ergänzend zur User-Story werden sog. Scenarios formuliert (zusammen bilden sie ein sog. Feature) User Story Als ein will ich um Nikolaus dass meine Geschenke an Kinder gerecht verteilt werden, Enttäuschungen der Kinder zu vermeiden. Scenario1: Zwei Kinder, vier Geschenke Angenommen Nikolaus gibt»2«beim Feld Kinder ein, und Nikolaus gibt»1, 2, 3, 4«beim Feld Geschenke ein. Falls Nikolaus auf Rechnen drückt, dann muss im Feld Ergebnis erscheinen:»kind 1: 1 + 4, Kind 2: 2 + 3«Seite 44 / 76

45 Beispiel mit JBehave Die Datei nikolaus.story: Given Nikolaus gibt 2 beim Feld Kinder ein Given Nikolaus gibt 1,2,3,4 beim Feld Geschenke ein When Nikolaus auf Rechnen drueckt Then muss im Feld Ergebnis erscheinen: Kind 1: = 5, Kind 2: = 5 Die gibt $kinder beim Feld Kinder ein") public void eingabekinder(int kinder) { this.kinder = kinder; gibt $geschenke beim Feld Geschenke ein") public void eingabegeschenke(list<integer> geschenke) { this.geschenke = geschenke; auf Rechnen drueckt") public void rechnendruecken() { rechner = new Rechner(kinder, geschenke); solution = rechner.calculate(); im Feld Ergebnis erscheinen: $ergebnis") public void dasergebnismusssein(string ergebnis) { String loesung = rechner.solutiontostring(solution); Assert.assertEquals(ergebnis, loesung); } s. auch [JBehave] und [Cucumber] Seite 45 / 76

46 Beispiel mit JBehave Die Log-Datei im Erfolgsfall: Running story com/javacook/nikolaus/nikolaus.story Scenario: Given Nikolaus gibt 2 beim Feld Kinder ein Given Nikolaus gibt 1,2,3,4 beim Feld Geschenke ein When Nikolaus auf Rechnen drueckt Then muss im Feld Ergebnis erscheinen: Kind 1: = 5, Kind 2: = 5 Die Log-Datei im Fehlerfall: Running story com/javacook/nikolaus/nikolaus.story Scenario: Given Nikolaus gibt 2 beim Feld Kinder ein Given Nikolaus gibt 1,2,3,4 beim Feld Geschenke ein When Nikolaus auf Rechnen drueckt Then muss im Feld Ergebnis erscheinen: Kind 1: = 5, Kind 2: = 9 (FAILED) (org.junit.comparisonfailure: expected:<... 5, Kind 2: = [9]> but was:<... 5, Kind 2: = [5]>) Seite 46 / 76

47 Vergleich der Entwicklung: klassisch & BDD Kunde wird interviewt Kunde wird interviewt RE spezifiziert Anforderungen RE spezifiziert Anforderungen RE & Entwickl. Akzeptanztest Implementierung Implementierung QA testet QA & autom. Akzeptanztests Auslieferung & Abnahme Auslieferung & Abnahme Seite 47 / 76

48 Fazit Das Erstellen von Akzeptanztests erzwingt eine detailliertere Auseinandersetzung bereits zu Beginn Es fördert die Kommunikation zwischen Auftraggeber, RE und Entwicklung Es entstehen (nebenbei) automatisierte Tests, die das System unmissverständlich dokumentieren Seite 48 / 76

49 Best Practices Überprüfen Sie (stichprobenartig) einige Anforderungsdokumente Sind die Dokumente auffindbar, versioniert? Sind die Dokumente einheitlich strukturiert? Ist der Text (auch für Uneingeweihte) klar und verständlich? Wurden formale Methoden verwendet? Enthalten sie Akzeptanzkriterien? Sind in Ihren Dokumenten ausreichend Musterfälle enthalten? Seite 49 / 76

51 Anforderungen vermessen und validieren Warum? Anforderungsdokumente sind häufig Grundlage für Verträge Einen Qualitätsstandard sicherstellen Qualität der Anforderungen wirkt sich auf die Software-Qualität aus Fehler & Mängel frühzeitig zu finden, denn Seite 51 / 76

52 Kosten von RE-Fehlern bezogen auf Projektphasen Seite 52 / 76

53 Qualitätsmerkmale für Anforderungen Wann ist eine Anforderungsspezifikation gut? Aktualität (insb. Kundenwunsch-konform) Eindeutigkeit Widerspruchsfreiheit Identifizierbarkeit Vollständigkeit Änderbarkeit Prüfbarkeit Realisierbarkeit Verständlichkeit Seite 53 / 76

54 Konkrete Qualitätsmetrik Eindeutigkeit Prozessworteindeutigkeit in Satz i Bezugspunkteindeutigkeit in Satz i Begriffseindeutigkeit in Satz i Anzahl aller Sätze nach [RuppSoph] Seite 54 / 76

55 Review-Prüfmethoden Stellungnahme Eine weitere Person (am besten fachfremd) wird gebeten, das Dokument zu prüfen Inspektion Sehr strenger aufwändiger Prozess mit vielen Beteiligten (Moderator, Prüfer, Termine, Checklisten, Abschlussbericht) Walkthrough Leichtgewichtiges Review (Autor trägt vor, Prüfer, Protokollant) Automatisiert durch Tools Befindet sich in der Forschung Seite 55 / 76

56 Prüfungsnachbereitung Ergebnisse standardisiert dokumentieren Bei Unterschreitungen der Toleranzgrenze Ursachen bestimmen! Prozesse anpassen Evtl. nachschulen Seite 56 / 76

57 Bezug zur Software-Qualität (exemplarisch) Funktionalität Korrektheit Wartbarkeit Aktualität x Eindeutigkeit x Widerspruchsfreiheit x Identifizierbarkeit x Vollständigkeit x Änderbarkeit x Prüfbarkeit x x Realisierbarkeit x Verständlichkeit x x... Seite 57 / 76

58 Best Practices Werden Qualitätsprüfungen bzgl. der Anforderungen bei Ihnen durchgeführt? Planen Sie den Prozess sorgfältig und passen ihn gezielt auf Ihre Bedürfnisse an Qualitätsprüfungen sind bislang noch nicht die Regel Tun Sie es, nutzen Sie den Vorsprung! Seite 58 / 76

60 Anforderungen verwalten Ist eine Hauptaufgabe des agilen RE! Wird umso wichtiger, je mehr Anforderungen zu verwalten sind mehr Stakeholder auf die Informationen zugreifen mehr Änderungen zu erwarten sind länger das Produkts (erwartungsgemäß) in Betrieb ist Die Wahl des(r) richtigen Tools bringt entscheidende Vorteile Entscheidend für das Software-Qualitätsmerkmal Wartbarkeit Seite 60 / 76

61 Erwartungen an ein Management-Tool Notwendige Eigenschaften: Anlegen, Ändern, Löschen von Anforderungen Strukturierbarkeit Gute Suchmöglichkeiten Versionsverwaltung / Versionierung Einfache Handhabung von Grafiktypen Verfolgbarkeit (Traceability) Wünschenswert Konfigurierbarkeit von Eingabemasken und Workflow Benutzer- und Rechteverwaltung Automatische Analyse von Texten Seite 61 / 76

62 Tools Word & Excel: immer noch üblich Grund: Wird von jedem beherrscht Im Kommen: Issue-Tracker & Wikis Grund: Einfaches Erlernen, einfache Bedienung Offen für den Aufbau einer Werkzeugkette (!) Auswahl verschiedener RE-Tools (alphabetisch): Caliber RM Contour Cradle DESIRe DOORS Enterprise Architect HP Quality Center IrQA Lotus Notes OptimalTrace ProR RequisitePro YAKINDU [VolereTools] enthält eine weitaus größere Übersicht Seite 62 / 76

63 Traceability so wichtig und doch kaum vorhanden Typische Wartungsaufgabe: Im Risiko-Report vom 31.3 stimmt das Ausfalldatum nicht Findet der Entwickler folgende Informationen effizient? Woher stammt das Datum (Eingabe, Import)? In welchen Klassen wird es verarbeitet? Welche Datenbankfelder sind involviert? Welche fachlichen Abhängigkeiten gibt es zu anderen Daten? Wie groß sind die Risiken von Änderungen? Seite 63 / 76

64 Ideale Welt RE-Tool Modellierung "Ausfalldatum" RE-Tool Lösung Fachklassen RE-Tool Source Suchergebnis Anforderung Verarbeitung Seite 64 / 76

65 Die Realität Source DB-Tool Word Source-Code-Analysen können das zig-fache an Zeit kosten! Seite 65 / 76

66 Vision: Traceability innerhalb der Werkzeugkette Issue Tracking Collaboration IDE Monitoring Modellierung Build- Management Delivery Anforderungsmanagement Projektmanagement BP- Management Configuration- Management Persistenz Seite 66 / 76

67 Best Practices Prüfen Sie, ob bei Ihnen die passenden Werkzeugkette im Einsatz ist Erwägen Sie eine Neuanschaffung: Nehmen Sie sich Zeit für die richtige Wahl Lassen Sie sich von Experten beraten Planen Sie auch den Einsatz von Schulungen Seite 67 / 76

69 Warum ist RE wirtschaftlich? Seite 69 / 76

70 Zusammenfassung Einsparungen beim RE bewirken wenig Qualität bei hohen Kosten! Eine gute Anforderungsanalyse erfordert spezielle RE-Fertigkeiten Mit direkten Auswirkungen auf die Softwarequalität Gute Dokumentation erfordert Talent, Technik und Disziplin Sprachkonventionen, Modelle, neue Verfahren (BDD) Ziel: Formales und systematisches Vorgehen Gute RE-Management-Tools helfen nennenswert Auch Anforderungen lassen sich qualitätsprüfen Ziel: Qualitätssteigerungen durch kontinuierliches Messen Qualität bei den Anforderungen Software-Qualität Seite 70 / 76

71 Referenzen [RuppSoph] Chris Rupp, die SOPHISTen; Requirements-Engineering und Management, 5. Auflage, Hanser, 2009, ISBN: [VolereTools] [Cucumber] [Jbehave] [bdw] Seite 71 / 76

72 Weiterführende Literatur Klaus Pohl, Chris Rupp; Basiswissen Requirements Engineering; 2. Auflage, Dpunkt Verlag, 2010, ISBN: S. Robertson, J. Robertson; Mastering the Requirements Process; Addison Wesley, 1999, ISBN: U. Vigenschow, B.Schneider, I. Meyrose; Soft Skills für Softwareentwickler; 2. Auflage, Dpunkt Verlag, 2010, ISBN: Rainer Gerlich; 111 Thesen zur erfolgreichen Softwareentwicklung; 1. Auflage, Springer, 2005, ISBN: Seite 72 / 76

73 Weiterführende Literatur Mr. Malcolm Tredinnick, Behaviour Driven Development, Gojko Adzic; Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing; Neuri Limited, 2009, ISBN: Gojko Adzic; Specification by Example: How Successful Teams Deliver the Right Software; Manning, Juni 2011, ISBN: Seite 73 / 76

74 Bildernachweise Folie 9: Folie 13: Folie 19: Folie 29: 800px-Lage-_und_Verhältnisbestimmung_Zahn.jpg Folie 32: Folie 33: Seite 74 / 76

75 Bildernachweise Folie 33: Folie 38: Folie 55: Folie 63: Folie 64: Sämtliche hier nicht aufgeführte Bilder bzw. Grafiken wurden vom Autor selbst erstellt. Seite 75 / 76

76 Abkürzungen ATDD BDD BPEL BPMN DDD DSL ER QA QS RE TDD UML Acceptance Test Driven Development Behavior Driven Development Business Process Execution Language Business Process Model and Notation Domain-Driven Design Domain-Specific Language Entity Relationship Quality Assurance Qualitätssicherung Requirements Engineering bzw. Requirements Engineer Test-Driven Development Unified Modeling Language Seite 76 / 76

77 Fragen?

78