Softwarequalität: Garbage in - garbage out

iks Thementag

„Mehr Softwarequalität – Best practices für alle Entwicklungsphasen“

19.06.2012

Garbage in - garbage out:

Wie das Anforderungsmanagement die

Softwarequalität beeinflusst

Autor:

Jörg Vollmer

Seite 3 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out

Agenda

Anforderungen aufnehmen

Dokumentieren von Anforderungen

Anforderungen vermessen und validieren

Verwalten von Anforderungen

Paradigmenwechsel: Vom Vorarbeiter zum Mitarbeiter

Zusammenfassung


Vorgehen

Im Folgenden soll untersucht werden:

Konstruktiv

– Welche Fertigkeiten des RE beeinflussen die Software-Qualität?

Analytisch

– 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?

Mit neuen RE-Techniken zu besserer Qualität (?)


Standardprobleme zu Projektbeginn

Unklare Zielvorstellungen

Veränderliche Anforderungen

Stakeholder stehen nicht zur Verfügung

Kommunikationsbarrieren

Hohe Komplexität


Qualitätseigenschaften des Requirements Engineers

Moderationsfertigkeiten

Eloquenz

Perspektivenwechsel

Diplomatie

Sorgfalt

Ausdauer

Spezielle RE-Techniken (gleich…)

Analytisch unmessbar, aber Auswirkung auf die Softwarequalität


Agenda






Zusammenfassung


Aufgaben zum Projektbeginn

Die initiale Bestandsaufnahme des Projektumfelds ist unverzichtbar

– Auch im agilen Umfeld

Wichtige Aufgaben sind

– Ermitteln aller Stakeholder

– Ziele des Produkts und deren Nutzen ermitteln

– Systemkontext und -grenzen bestimmen

– Qualitätsanforderungen (des Produkts) identifizieren

Fehler hierbei werden später teuer bezahlt


Beobachtungstechniken

Apprenticing: Der RE wird wie ein Lehrling eingearbeitet

Der RE lernt hierbei den Fachjargon kennen

Arbeitsschritte hinterfragen und ineffiziente Prozesse entdecken ...

…die Chance, somit die Qualität zu verbessern, ist schnell verspielt


1. Falle: Diskussionen in Meetings

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

– Eine Gruppe orientiert sich viel schwerer um als ein Einzelner

Moderationstechniken anwenden

Risiko von falschen Entscheidungen Software-Qualität

s. auch [bdw]


2. Falle: Faule Kompromisse

Stakeholder A:

– Bei einem Fehler muss das System anhalten

Stakeholder B:

– Bei einem Fehler muss das System neu starten

RE einigt sich mit A und B auf

– Im Fehlerfall wird eine Ausnahmeroutine veranlasst

Schlecht!

Eine Mehrdeutigkeit in einem Anforderungsdokument steht oft für

einen Konflikt bei den Stakeholdern (de Marco)


3. Falle: Ein Auto kann verschiedene Farben haben

Was der RE verstand:

Was der Kunde wollte:


Unterschiede ziehen sich durch alle Schichten

Datenbank

Datenmodell

Service-Schicht

Benutzeroberfläche

Fachobjekte und deren Beziehungen identifizieren (DDD)

Fehler hierbei sind teuer!


4. Falle: 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


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?


Agenda






Zusammenfassung


Anforderungen dokumentieren

Anforderungen aufschreiben, das kann doch jeder

Aber: Meinungen zu bestehender Dokumentation

– Versteht nur der, der‘s geschrieben hat

– Ist nach kurzer Zeit überholt

– Bis man dort die richtige Stelle findet

– Die interessanten Sonderfälle fehlen eh

Sehr viel Dokumentation wird gar nicht erst gelesen


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

Annahmen

Anforderungen Funktionalität

Qualitätsanforderungen

Anhang Verzeichnisse

Glossar

Index


Dokumentation in Form von Prosatext

Vorteile

– Wird von alle 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


Negativbeispiel

Original

– Wenn das Feld kundeVorhanden 'J' entspricht, dann wird über

kunde.item.sector das Feld branche gesetzt.

Besser

– Falls das Feld kundeVorhanden 'J' ist, dann erhält branche

den Wert von kunde.item.sector.

Formaler

– Ist kundeVorhanden = 'J', so setze

branche:= kunde.item.sector.


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


Eine Mischung ist optimal

Vorteile

– Modelle können durch natürlich-sprachliche Ergänzungen

verständlicher werden

– Prosatext kann durch Modelle eindeutiger und exakter werden

– D.h. beide Arten können die Schwächen der anderen kompensieren

Vorbild: Mathematische Texte

– Aus jeder nicht-negativen reellen Zahl lässt sich die Wurzel ziehen

–

.:0gilt Dann R.I,seien Es 2 yxxyyx


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, Wie oft, etc.

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.


Satzschablonen, z.B. die der User-Story

Agile Methoden verwenden sog. User-Stories

Aufbau:

– As a <role> I want <goal/desire> so that <benefit>

Beispiel:

– Als Autor möchte ich meine Präsentation speichern können,

damit ich nicht noch einmal alles eingeben muss

„so that <benefit>“ hinterfragt den Geschäftswert

Kurzfassung des klassischen Use-Case

Akzeptanztests kompensieren den knappen Inhalt (dazu später…)


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?

– Wenn nicht, warum nicht? Schulungen


Agenda






Zusammenfassung



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…


Kosten von RE-Fehlern bezogen auf Projektphasen


Qualitätsmerkmale für Anforderungen

Wann ist eine Anforderungsspezifikation gut?

– Aktualität (insbesondere Kundenwunsch-konform)

– Eindeutigkeit

– Widerspruchsfreiheit

– Identifizierbarkeit

– Vollständigkeit

– Änderbarkeit

– Prüfbarkeit

– Realisierbarkeit

– Verständlichkeit

All diese Merkmale beeinflussen die Software-Qualität!


Zusammenhang 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


Konkrete Qualitätsmetriken

1 wobei,100#

wvugssätzeAnforderun

BEwBPEvPEueitEindeutigk

sindt beantworteJA mit zu Fragen alle falls ,1

sonst ,0)(),(),( iA

iii ABEABPEAPE

tndeutigkeiBegriffsei

keitteindeutigBezugspunk

keitteindeutigProzesswor

BE

BPE

PE

nach [RuppSoph]


Review-Prüfmethoden

Stellungnahme

– Eine weitere Person 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


Prüfungsvorbereitungen

Qualitätsmerkmale auswählen

Qualitätsmetriken auswählen

Sollwerte festlegen (Indikatoren)

Prüfzeitpunkte festlegen

Prüfer gezielt auswählen

– Qualifikation!


Prüfungsnachbereitung

Ergebnisse standardisiert dokumentieren

Bei Unterschreitungen der Toleranzgrenze

– Ursachen bestimmen

– Prozesse anpassen

– Evtl. nachschulen


Prozesse anpassen, Vorschläge

Verwendung von Bugtrackern auch bei Anforderungen

– Beispiele: Jira, Mantis, Bugzilla, Trac

– Wird bislang kaum praktiziert. Warum eigentlich nicht?

– Zudem ist die Anzahl der Tickets (normiert) eine Qualitäts-Metrik

Definition of Done

– Qualitätsrichtlinien festlegen

– Stellungnahme gehört „zum Done“ dazu


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!


Agenda






Zusammenfassung


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 Produkt (erwartungsgemäß) in Betrieb ist.

Die Wahl des richtigen Tools ist außerordentlich wichtig!

Entscheidend für das Software-Qualitätsmerkmal Wartbarkeit


Erwartungen an ein Management-Tool

Notwendige Eigenschaften:

– Anlegen, Ändern, Löschen von Anforderungen

– Strukturierbarkeit (hierarchisch, verlinkbar)

– Gute Suchmöglichkeiten (Volltext, unscharf, Stichwörter)

– Versionsverwaltung / Versionierung

– Einfache Handhabung von Grafiktypen (Einfügen, Bearbeiten)

– Verfolgbarkeit (Traceability)

Wünschenswert

– Konfigurierbarkeit von Eingabemasken und Workflow

– Benutzer- und Rechteverwaltung

– Automatische Analyse von Texten und Generieren von Fragen

– …


Automatisches Erzeugen von Fragen

Gegeben sei die User-Story

– Als Nutzer möchte ich meine Präsentation speichern, damit

ich nicht noch einmal alles eingeben muss

Exemplarisch generiertes Fragen-Set – Wer muss speichern?

– Wann soll speichern stattfinden?

– Wann ist speichern komplett abgeschlossen?

– Wie häufig / oft / groß / schnell soll speichern sein?

– Wo / wie kann geprüft werden, ob speichern durchgeführt wurde?

– Was geschieht, wenn man nicht speichern kann?

– Was könnte speichern verhindern, und was wird dann erwartet?

– Welche mögl. Fehleingaben müssen im Zusammenhang mit speichern abgefangen werden?

– Welche Inhalte kommen in Präsentation vor?

– Welche optionalen / verpflichtenden Aspekte gelten für Präsentation?

– Wie sieht das Layout von Präsentation aus?


Tools

Word & Excel: immer noch üblich

– Grund: Werden von jedem beherrscht

Mehr im Kommen: Jira & Wikis

– Grund: Einfaches Erlernen, einfache Bedienung

Auswahl verschiedener Tools:

– Caliber RM Cradle Contour

– DOORS DESIRe Enterprise Architect

– HP Quality Center IRQA Lotus Notes

– OptimalTrace RequisitePro

– [VolereTools] enthält eine weitaus größere Übersicht


Best practices

Prüfen Sie, ob bei Ihnen das passende Tool im Einsatz ist

Erwägen Sie eine Neuanschaffung, so…

– nehmen Sie sich Zeit für die richtige Wahl,

– lassen Sie sich von Experten beraten,

– planen Sie auch den Einsatz von Schulungen.


Agenda






Zusammenfassung


Probleme des bisherigen RE-Ansatzes

Das Wissen des Auftraggebers gelangt über folgende

Transformationen hin zur Software

– Kundenvorstellung Anforderung (teils modelliert)

– Anforderung Software-Design

– Software-Design Programmcode

Ähnliches gilt für Tests

– Kundenvorstellung Anforderung

– Anforderung Test-Design

– Test-Design Testcode


Probleme der Transformationen

Diese Transformation ist zu komplex:

– Anforderung Software-Design

Gründe

– Die Anforderung ist zu wenig formalisiert bzw. „algorithmisiert“

– Hochmut der Entwickler (wir machen das eh noch mal anders)

– Code-Styles (Übersetzung ins Englische)

Folge

– Man findet die Anforderung nicht mehr im Code wieder

Qualitätseinfluss auf Korrektheit & Änderbarkeit


Probleme der Transformationen

Diese Transformation bereitet ähnliche Schwierigkeiten

– Anforderung Test-Design

Gründe

– Die Anforderungen enthalten zu wenige (meist gar keine)

Akzeptanzkriterien

Folge

– Der Tester muss die Sollwerte anhand der Anf. selbst ableiten

– Gefahr besteht, dass Testszenarien ganz vergessen werden


Behavior-Driven Development

Ziel

– Systematisierung der Transformation

Anforderung Software-Design bzw. Test-Design

Lösung

– RE und Entwickler erstellen zusammen Akzeptanzkriterien

und -tests (keine Unit-Tests!)

– Sie werden zum Bestandteil der Anforderungsspezifikation

(der User-Story)

– Sie haben ein einheitliches Format…

– Ziel: Automatisierung!


Given When Then

Ergänzend zur User-Story werden in der ubiquitären

Sprache sog. Szenarien formuliert:

As a: Rechenmuffel

I want: dass ein Rechner Zahlen addiert

In order to: vermeiden von dummen Kopfrechenfehlern

Scenario1: Addieren von Zahlen

Given: Rechenmuffel gab „27“ in den Rechner ein,

And: Rechenmuffel gab „39“ in den Rechner ein,

And: Rechenmuffel gab „11“ in den Rechner ein,

When: Rechenmuffel „Summe” drückt,

Then: muss Rechner „77“ als Ergebnis anzeigen.

Scenario2: … Mehr dazu z.B. bei [Cucumber]

Story


Testgetriebenes Requirements Engineering

Standard

1. Kunde wird interviewt

2. RE spezifiziert Anforderungen (und erwartet Schätzung)

3. Architekt / Entwickler erstellen Software-Design

4. Entwickler implementieren Software und (Unit- & Integrations-) Tests

5. QA testet meist von Hand Iteration zu 1, 2, 3, 4

6. Abnahmetests

Neu

1. Kunde wird interviewt

2. RE spezifiziert Anforderungen

3. RE spezifiziert zusammen mit Entwicklung Akzeptanztests (Iteration zu 1, 2)

4. Schätzung

5. Entwickler erstellen Software, Tests und Akzeptanztests (automatisierte)

6. QA testet Bugfix-Iteration zu 5 (idealisiert)

7. Abnahmetests (Ziel: starke Einsparung)


Fazit

Szenarien erhöhen die Qualitätsmerkmale Verständlichkeit,

Eindeutigkeit und Prüfbarkeit der Anforderungen signifikant

Mit Hilfe von neuen Frameworks lassen sich diese Strukturen

halbautomatisch in Code überführen

Das führt zu ausführbaren Akzeptanztests


Agenda

Motivation






Zusammenfassung


Warum ist RE wirtschaftlich?


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 auf Qualität prüfen

– Ziel: Qualitätssteigerungen durch kontinuierliches Messen

– Gute Anforderungsqualität gute Software-Qualität


Referenzen

[RuppSoph]

Chris Rupp, die SOPHISTen; Requirements-Engineering und –

Management, 5. Auflage, Hanser, 2009, ISBN: 978-3446418417

[VolereTools]

http://www.volere.co.uk/tools.htm

[Cucumber]

http://cukes.info

[EbertDumke]

Christof Ebert, Reiner Dumke; Software-Metriken in der Praxis,

Springer, 1996, ISBN: 978-3540603726




http://cukes.info/

http://cukes.info/

http://cukes.info/


Referenzen

[Deißendorfer]

F. Deißendörfer (Diss. 2009),

Continuous Quality Control of Long-Lived Software Systems

http://mediatum2.ub.tum.de/doc/737380/737380.pdf

[Sanego]

http://www.sanego.de

[StandishGroup]

http://www.standishgroup.com

[bdw]

http://www.bild-der-wissenschaft.de/bdw/bdwlive/heftarchiv/index2.php?object_id=32911270



http://www.sanego.de/

http://www.sanego.de/

http://www.standishgroup.com/

http://www.standishgroup.com/









Weiterführende Literatur

Klaus Pohl, Chris Rupp; Basiswissen Requirements Engineering;

2. Auflage, Dpunkt Verlag, 2010, ISBN: 978-3898646130

S. Robertson, J. Robertson; Mastering the Requirements Process;

Addison Wesley, 1999, ISBN: 978-0201360462

U. Vigenschow, B.Schneider, I. Meyrose; Soft Skills für Softwareent-

wickler; 2. Auflage, Dpunkt Verlag, 2010, ISBN: 978-3898646710

Rainer Gerlich; 111 Thesen zur erfolgreichen Softwareentwicklung;

1. Auflage, Springer, 2005, ISBN: 978-3540209102

Mr. Malcolm Tredinnick, Behavior Driven Development,

http://www.youtube.com/watch?v=XXHknWKuG2U

http://www.youtube.com/watch?v=XXHknWKuG2U


Folie 10: http://openclipart.org/image/800px/svg_to_png/169415/discussion.png

http://openclipart.org/image/800px/svg_to_png/169418/go-round.png

Folie 12: http://www.clker.com/cliparts/7/1/a/f/11949851591518961590dodge_neon_green_ganson.svg.med.png

Folie 17: http://www.clker.com/clipart-15442.html

Folie 34: http://openclipart.org/image/800px/svg_to_png/29647/QualityControl_rejected2.png

Folie 35: http://openclipart.org/image/800px/svg_to_png/29641/1267371838.png

Sämtliche hier nicht aufgeführte Bilder bzw. Grafiken wurden vom Autor selbst erstellt.

Bildnachweise

http://openclipart.org/image/800px/svg_to_png/169415/discussion.png




http://www.clker.com/cliparts/7/1/a/f/11949851591518961590dodge_neon_green_ganson.svg.med.png

http://www.clker.com/clipart-15442.html



http://openclipart.org/image/800px/svg_to_png/29647/QualityControl_rejected2.png

http://openclipart.org/image/800px/svg_to_png/29641/1267371838.png

http://www.rottenplaces.de/

http://www.rottenplaces.de/


Abkürzungen

BDD Behavior-Driven Development

BPE Business Process Execution Language

BPMN Business Process Model and Notation

DDD Domain-Driven Design

DSL Domain-Specific Language

ER Entity Relationship

QA Quality Assurance

QS Qualitätssicherung

RE Requirements Engineering bzw. Requirements Engineer

TDD Test-Driven Development

UML Unified Modeling Language

Fragen?

www.iks-gmbh.com

Technology

Softwarequalität: Garbage in - garbage out