Garbarge in - garbage out: Wie das Anforderungsmanagement die Softwarequalität beeinflusst iks Thementag Mehr Softwarequalität – Ausgewählte Themen 23.04.2013

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

Seite 3 / 75Garbarge in - garbage out: Wie das Anforderungsmanagement die Softwarequalität beeinflusst

Was stört Sie im IT-Alltag am meisten?

Befragt wurden 103 Software-Entwickler:

1. Unklare Anforderungen 50.49 %

2. Zu häufig & schnell wechselnde Anforderungen 40.78 %

3. Schlechtes Projektmanagement 29.13 %

4. Geringe oder fehlende Testabdeckung 28.16 %

5. Unzureichende Kommunikation im Team 27.18 %

6. Termindruck => Quick & Dirty 24.27 %

7. Unverständlicher Code 21.36 %

8. Unnötige Meetings & Diskussionen 19.42 %

9. Ineffektive (Entwicklungs-) Prozesse 18.45 %

10. Schlechte Teamstimmung 15.53 %

Quelle: http://www.clean-code.info/umfrage

http://www.clean-code.info/umfrage


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?


Agenda

Anforderungen aufnehmen

Dokumentieren von Anforderungen

Der Effekt von Akzeptanztests

Anforderungen vermessen und validieren

Verwalten von Anforderungen

Zusammenfassung


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!


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.


Falle 1Ineffiziente Meetings


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

Risiko von falschen Entscheidungen Software-Qualität

s. auch [bdw]


Falle 2Faule Kompromisse


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)


Falle 3Designfehler bei Geschäftsobjekten


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)

Hohe Korrekturkosten ↔ es geht auf Kosten der Softwarequalität


Falle 4Unklare Fachbegriffe


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


Agenda






Zusammenfassung


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!


Nichts Halbes, nichts Ganzes


Wie entsteht gute (Anforderungs-) Dokumentation?

Es empfiehlt sich die Verwendung einer Standardgliederung / Template– RUP– IEEE 830– V-Modell– Volere

EinleitungZweck, StakeholderReferenzen

ÜbersichtSystemumfeldArchitekturBenutzerRandbedingungen

AnforderungenFunktionalität Qualitätsanforderungen

AbnahmeAkzeptanzkriterienTestszenarien

AnhangGlossarIndex


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


Falle 5Unverständliche Formulierungen


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


Falle 6Versteckte Annahmen


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

Fragen:– Was ist die „Liste“– Wo befindet sich diese?– Wer ordnet was wem zu?– Was ist Typ 0?


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.


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


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


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– yxxyyx 2:0gilt Dann IR.,seien Es

Häufig verschwindet die (Beweis-) Idee hinter der Abstraktion


Beispiel


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.


Funktionale Anforderungen – Illustriert

≈+ ≈+ +

…

…


Funktionale Anforderungen - Formal

Voraussetzung

– Gegeben seien natürliche Zahlen

– und eine Preisfunktion .

Aufgabe

– Finde eine Partitionierung , sodass

minimal wird, wobei .

},...,1{...,,1

nNmii

0mn

NI},...,1{: np

)()(maxmj i1

jPiP

iNk

kpiP )(:)(


Abnahme: Der Nikolaus testet und war unglücklich…


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!


Falle 7


Erkenntnis

Selbst eine vollständige und widerspruchsfreie

Spezifikationen garantiert keine gute Software!

Doch wie lässt sich das Problem bekämpfen?


Specification by Example

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


Klassisch: Stille Post

Klassisches Vorgehen:

Kunde Requirements Engineer

Der RE abstrahiert und formuliert ein Spezifikation.

Entwickler Software

Tester Testfälle

Kunde Abnahme

anhand von Beispielen

anhand der Spezifikation

anhand der Spezifikation

anhand von Akzeptanzkriterien


Idee des Acceptance Test Driven Development

Beispiele Tests

Anforderungen

werden zu

verifizierenreflektieren


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)


Angenommen … falls … dann …

Ergänzend zur User-Story werden sog. Scenarios formuliert (zusammen bilden sie ein sog. Feature)

User Story

Als ein Nikolaus

will ich dass meine Geschenke an Kinder gerecht verteilt werden,

um 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«


Bespiel mit JBehave

Die Datei nikolaus.story:

Die Test-Klasse:

Given Nikolaus gibt 2 beim Feld Kinder einGiven Nikolaus gibt 1,2,3,4 beim Feld Geschenke einWhen Nikolaus auf Rechnen druecktThen muss im Feld Ergebnis erscheinen: Kind 1: 1 + 4 = 5, Kind 2: 2 + 3 = 5

@Given("Nikolaus gibt $kinder beim Feld Kinder ein")public void eingabeKinder(int kinder) { this.kinder = kinder;}@Given("Nikolaus gibt $geschenke beim Feld Geschenke ein")public void eingabeGeschenke(List<Integer> geschenke) { this.geschenke = geschenke;}@When("Nikolaus auf Rechnen drueckt")public void rechnenDruecken() { rechner = new Rechner(kinder, geschenke); solution = rechner.calculate();}@Then("muss im Feld Ergebnis erscheinen: $ergebnis")public void dasErgebnisMussSein(String ergebnis) { String loesung = rechner.solutionToString(solution); Assert.assertEquals(ergebnis, loesung);}

s. auch [Jbehave]und [Cucumber]


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 einGiven Nikolaus gibt 1,2,3,4 beim Feld Geschenke einWhen Nikolaus auf Rechnen druecktThen 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]>)

Running story com/javacook/nikolaus/nikolaus.story

Scenario: Given Nikolaus gibt 2 beim Feld Kinder einGiven Nikolaus gibt 1,2,3,4 beim Feld Geschenke einWhen Nikolaus auf Rechnen druecktThen muss im Feld Ergebnis erscheinen: Kind 1: 1 + 4 = 5, Kind 2: 2 + 3 = 5


Vergleich der Entwicklung: klassisch & BDD

Kunde wird interviewt

RE spezifiziert Anforderungen

Implementierung

QA testet

Auslieferung & Abnahme

Kunde wird interviewt

RE spezifiziert Anforderungen

RE & Entwickl. → Akzeptanztest

Implementierung

QA & autom. Akzeptanztests

Auslieferung & Abnahme


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.


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?


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 (insb. Kundenwunsch-konform)– Eindeutigkeit– Widerspruchsfreiheit– Identifizierbarkeit– Vollständigkeit– Änderbarkeit– Prüfbarkeit– Realisierbarkeit– Verständlichkeit


Konkrete Qualitätsmetriken

1 wobei,100#

wvugssätzeAnforderun

BEwBPEvPEueitEindeutigk

sindt beantworteJA mit zu Fragen alle falls ,1sonst ,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üfungsnachbereitung

Ergebnisse standardisiert dokumentieren

Bei Unterschreitungen der Toleranzgrenze– Ursachen bestimmen!– Prozesse anpassen– Evtl. nachschulen


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


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

Die Wahl des(r) 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


Tools

Word & Excel: immer noch üblich– Grund: Wird von jedem beherrscht

Im Kommen: Jira & Wikis– Grund: Einfaches Erlernen, Einfache Bedienung– Offen für den Aufbau einer Werkzeugkette

Auswahl verschiedener RE-Tools (alphabetisch):– Caliber RM Contour Cradle– DOORS DESIRe Enterprise Architect – HP Quality Center IrQA Lotos Notes – OptimalTrace ProR RequisitePro– YAKINDU …

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


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


Ideale Welt

RE-Tool

Suchergebnis

Source

Verarbeitung

Lösung

RE-Tool

Anforderung

RE-Tool

"Ausfalldatum"

Modellierung

Fachklassen


Die Realität

Source DB-Tool

Source-Code-Analysen können das zig-fache an Zeit kosten!

Word

X


Vision: Traceability innerhalb der Werkzeugkette

Anforderungs-management

IDE

Projekt-management

Build-Management

Issue Tracking

Modellierung

Persistenz

Delivery

Collaboration

BP-Management

Monitoring

Configuration-Management


Best Practices

Prüfen Sie, ob bei Ihnen die passenden Werkzeugkette 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


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 qualitätsprüfen– Ziel: Qualitätssteigerungen durch kontinuierliches Messen– Qualität bei den Anforderungen 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

[Jbehave]

http://jbehave.org

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

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



http://cukes.info/

http://cukes.info/

http://cukes.info/

http://jbehave.org/

http://jbehave.org/

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




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


Weiterführende Literatur

Mr. Malcolm Tredinnick, Behaviour Driven Development, http://www.youtube.com/watch?v=XXHknWKuG2U

Gojko Adzic; Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing;Neuri Limited, 2009, ISBN: 978-0955683619

Gojko Adzic; Specification by Example: How Successful Teams Deliver the Right Software;Manning, Juni 2011, ISBN: 978-1617290084

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


Folie 9: http://openclipart.org/image/800px/svg_to_png/169415/discussion.pnghttp://openclipart.org/image/800px/svg_to_png/169418/go-round.png

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

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

Folie 29: http://upload.wikimedia.org/wikipedia/commons/thumb/d/d0/Lage-_und_Verhältnisbestimmung_Zahn.jpg/800px-Lage-_und_Verhältnisbestimmung_Zahn.jpg

Folie 32: http://openclipart.org/detail/1956/santa-and-his-bag-by-johnny_automatic

Folie 33: http://www.wpclipart.com/people/children/girls/girls_3/girl_with_pigtails.png.htmlhttp://www.wpclipart.com/people/children/boys/little_boy.png.htmlhttp://www.wpclipart.com/holiday/Christmas/gifts/gift_box_silver.png.htmlhttp://www.wpclipart.com/holiday/Christmas/gifts/gift_black.png.html

…

Bildernachweise

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

http://openclipart.org/image/800px/svg_to_png/169418/go-round.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/detail/1956/santa-and-his-bag-by-johnny_automatic






Folie 33: http://www.wpclipart.com/holiday/Christmas/gifts/gifts_w_tags.png.htmlhttp://www.wpclipart.com/holiday/Christmas/gifts/gift_box_blue_ribbon/package_blue_ribbon_and_blue.png.htmlhttp://www.wpclipart.com/holiday/valentines/candy_and_gifts/valentine_gift_box.png.html

Folie 55: http://openclipart.org/detail/29647/quality-control:-rejected-by-stijnbern

Folie 64: http://openclipart.org/image/800px/svg_to_png/94723/db.png

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

Bildernachweise




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

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


Abkürzungen

ATDD Acceptance Test Driven Development

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

Documents

Garbarge in - garbage out: Wie das Anforderungsmanagement die Softwarequalität beeinflusst iks Thementag Mehr Softwarequalität – Ausgewählte Themen 23.04.2013