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

2. Garbarge in - garbage out: Wie das Anforderungsmanagement die Softwarequalität beeinflusst iks Thementag „Mehr Softwarequalität – Ausgewählte Themen“ 23.04.2013 Autor: Jörg Vollmer

3. Was stört Sie im IT-Alltag am meisten? Befragtwurden 103 Software-Entwickler: • UnklareAnforderungen 50.49 % • Zu häufig & schnell wechselnde Anforderungen 40.78 % • SchlechtesProjektmanagement 29.13 % • Geringe oder fehlende Testabdeckung 28.16 % • Unzureichende Kommunikation im Team 27.18 % • Termindruck => Quick & Dirty 24.27 % • Unverständlicher Code 21.36 % • Unnötige Meetings & Diskussionen 19.42 % • Ineffektive (Entwicklungs-) Prozesse 18.45 % • SchlechteTeamstimmung 15.53 % Quelle: http://www.clean-code.info/umfrage

4. Unklare Anforderungen (50.49%) 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?

5. Anforderungen aufnehmen • Dokumentieren von Anforderungen • Der Effekt von Akzeptanztests • Anforderungen vermessen und validieren • Verwalten von Anforderungen • Zusammenfassung

6. Aufgaben zum Projektbeginn • Eine initiale Bestandsaufnahme des Projektumfelds 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!

7. 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.

8. Falle 1 Ineffiziente Meetings

9. Unnötige Meetings & Diskussionen (Platz 8) • 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  Moderationstechniken anwenden s. auch [bdw] Risiko von falschen Entscheidungen  Software-Qualität

10. Falle 2 Faule Kompromisse

11. 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)

12. Falle 3 Designfehler bei Geschäftsobjekten

13. Ein Auto kann verschiedene Farben haben Was der RE verstand: Was der Kunde wollte:

14. 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

15. Falle 4 Unklare Fachbegriffe

16. UnklareFachbegriffe • 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

17. Best Practices • Überprüfen Sie: • Wurden Ihrer 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?

18. Anforderungen aufnehmen • Dokumentieren von Anforderungen • Der Effekt von Akzeptanztests • Anforderungen vermessen und validieren • Verwalten von Anforderungen • Zusammenfassung

19. 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!

20. Nichts Halbes, nichts Ganzes

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

22. 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

23. Falle 5 Unverständliche Formulierungen

24. Negativbeispiel • Auszug aus eine Spezifikation: • Funktionalität In einer „Liste“ über alle noch nicht zugeordneten Kunden werden alle Kunden aller Typen ungleich Typ 0 angezeigt, die bisher keinem Kunden vom Typ 0 zugeordnet wurden. … Satzstruktur zu komplex

25. Falle 6 Versteckte Annahmen

26. Negativbeispiel • Auszug aus eine Spezifikation: • Funktionalität In einer „Liste“ über alle noch nicht zugeordneten Kunden werdenalle Kunden aller Typen ungleich Typ 0 angezeigt, die bisher keinem Kunden vom Typ 0zugeordnet wurden. … • Fragen: • Was ist die „Liste“ • Wo befindet sich diese? • Wer ordnet was wem zu? • Was ist Typ 0?

27. 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.

28. Vorschlag: Satzschablonen • Beispiel: Die User-Story • Agile Methoden verwenden sog. User-StoriesAufbau: • As a <role> I want <goal/desire> so that <benefit> • Als ein Autor will ichmeine 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“

29. 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

30. 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

31. Beispiel

32. Funktionale Anforderungen - Prosa • Der Nikolaus verteilt am 6.12. 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 bei jedem Kind möglichst gleich sein. • Aufgabe: Eine Software soll bei Eingabe der Kinderzahl und der Geschenkwerte eine gerechte Verteilung berechnen.

33. Funktionale Anforderungen – Illustriert + + ≈ + ≈ … …

34. Funktionale Anforderungen - Formal • Voraussetzung • Gegeben seien natürliche Zahlen • und eine Preisfunktion . • Aufgabe • Finde eine Partitionierung, sodass minimal wird, wobei .

35. Abnahme: Der Nikolaus testet und war unglücklich…

36. 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 gleichmäßig verteilen! • Version 1.1 • Der katastrophale Fall „Kinderheim“: • 50 Geschenke, 20 Kinder: • Die Anwendung antwortet nicht mehr!

37. Falle 7

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

39. SpecificationbyExample • Zwei Kinder, 6 Geschenke im Wert von 1, 2, 2, 4, 6, 9 Euro • Lösung: 2 + 4 + 6 = 12 = 1 + 2 + 9 • Ungültig: 1 + 4 + 6 = 11 < 13 = 2 + 2 + 9 • Zwei Kinder, 6 Geschenke im Wert von 1, 2, 2, 4, 5, 9 Euro • Lösung: 2 + 4 + 5 = 11 < 12 = 1 + 2 + 9 • Zwei Kinder, 10 Geschenke im Wert von 1, 1, 1, 1, 1, 1, 1, 1, 4, 4 Euro • Lösung: 1 + 1 + 1 + 1 + 4 = 8 = 1 + 1 + 1 + 1 + 4 • Schlecht: 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 = 8 = 4 + 4 • 20 Kinder, 50 Geschenke im Wert von jeweils 1 Euro • Lösung: 10 Kinder: 1 + 1, 10 Kinder: 1 + 1 + 1 usw...

40. Klassisch: Stille Post Klassisches Vorgehen: • Kunde Requirements Engineer • Der RE abstrahiert und formuliert ein Spezifikation. • Entwickler Software • Tester Testfälle • Kunde Abnahme anhand von Akzeptanzkriterien anhand von Beispielen anhand der Spezifikation anhand der Spezifikation

41. Idee des Acceptance Test Driven Development werden zu Beispiele Tests verifizieren reflektieren Anforderungen

42. 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. BehaviorDriven Development (BDD)

43. Angenommen … falls … dann … • Ergänzend zur User-Story werden sog.Scenariosformuliert(zusammenbildensieeinsog. Feature) User Story Als ein Nikolaus will ich dass meine Geschenke an Kinder gerecht verteilt werden, um Enttäuschungender Kinder zuvermeiden. Scenario1: Zwei Kinder, vierGeschenke Angenommen Nikolaus gibt »2«beim Feld Kinder ein, und Nikolaus gibt »1, 2, 3, 4« beim Feld Geschenke ein. Falls Nikolaus auf Rechnendrückt, dann muss im Feld Ergebnis erscheinen: »Kind 1: 1 + 4, Kind 2: 2 + 3«

44. Bespiel mit JBehave • Die Datei nikolaus.story: • Die Test-Klasse: 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: 1 + 4 = 5, Kind 2: 2 + 3 = 5 @Given("Nikolaus gibt $kinder beim Feld Kinder ein") publicvoideingabeKinder(int kinder) { this.kinder = kinder; } @Given("Nikolausgibt$geschenkebeimFeldGeschenkeein") publicvoideingabeGeschenke(List<Integer> geschenke) { this.geschenke = geschenke; } @When("Nikolaus auf Rechnen drueckt") publicvoidrechnenDruecken() { rechner = newRechner(kinder, geschenke); solution = rechner.calculate(); } @Then("muss im Feld Ergebnis erscheinen: $ergebnis") publicvoiddasErgebnisMussSein(String ergebnis) { String loesung = rechner.solutionToString(solution); Assert.assertEquals(ergebnis, loesung); } s. auch [Jbehave] und [Cucumber]

45. Beispiel mit JBehave • Die Log-Datei im Erfolgsfall: • 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: 1 + 4 = 5, Kind 2: 2 + 3 = 5 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: 1 + 4 = 5, Kind 2: 2 + 3 = 9 (FAILED) (org.junit.ComparisonFailure: expected:<... 5, Kind 2: 2 + 3 = [9]> but was:<... 5, Kind 2: 2 + 3 = [5]>)

46. 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

47. 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.

48. 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?

49. Anforderungen aufnehmen • Dokumentieren von Anforderungen • Der Effekt von Akzeptanztests • Anforderungen vermessen und validieren • Verwalten von Anforderungen • Zusammenfassung

50. 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…