Softwarequalität: Garbage in - garbage out
-
Upload
iks-gesellschaft-fuer-informations-und-kommunikationssysteme-mbh -
Category
Technology
-
view
1.992 -
download
2
description
Transcript of 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
Seite 4 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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 (?)
Seite 5 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
Standardprobleme zu Projektbeginn
Unklare Zielvorstellungen
Veränderliche Anforderungen
Stakeholder stehen nicht zur Verfügung
Kommunikationsbarrieren
Hohe Komplexität
Seite 6 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
Qualitätseigenschaften des Requirements Engineers
Moderationsfertigkeiten
Eloquenz
Perspektivenwechsel
Diplomatie
Sorgfalt
Ausdauer
Spezielle RE-Techniken (gleich…)
Analytisch unmessbar, aber Auswirkung auf die Softwarequalität
Seite 7 / 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
Seite 8 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 9 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 10 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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]
Seite 11 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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)
Seite 12 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
3. Falle: Ein Auto kann verschiedene Farben haben
Was der RE verstand:
Was der Kunde wollte:
Seite 13 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
Unterschiede ziehen sich durch alle Schichten
Datenbank
Datenmodell
Service-Schicht
Benutzeroberfläche
Fachobjekte und deren Beziehungen identifizieren (DDD)
Fehler hierbei sind teuer!
Seite 14 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 15 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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 16 / 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
Seite 17 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 18 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 19 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 20 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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.
Seite 21 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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 22 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 23 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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.
Seite 24 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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…)
Seite 25 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 26 / 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
Seite 27 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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 28 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
Kosten von RE-Fehlern bezogen auf Projektphasen
Seite 29 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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!
Seite 30 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 31 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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]
Seite 32 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 33 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
Prüfungsvorbereitungen
Qualitätsmerkmale auswählen
Qualitätsmetriken auswählen
Sollwerte festlegen (Indikatoren)
Prüfzeitpunkte festlegen
Prüfer gezielt auswählen
– Qualifikation!
Seite 34 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
Prüfungsnachbereitung
Ergebnisse standardisiert dokumentieren
Bei Unterschreitungen der Toleranzgrenze
– Ursachen bestimmen
– Prozesse anpassen
– Evtl. nachschulen
Seite 35 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 36 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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 37 / 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
Seite 38 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 39 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
– …
Seite 40 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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?
Seite 41 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 42 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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.
Seite 43 / 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
Seite 44 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 45 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 46 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 47 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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!
Seite 48 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 49 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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)
Seite 50 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 51 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
Agenda
Motivation
Anforderungen aufnehmen
Dokumentieren von Anforderungen
Verwalten von Anforderungen
Anforderungen vermessen und validieren
Paradigmenwechsel: Vom Vorarbeiter zum Mitarbeiter
Zusammenfassung
Seite 52 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
Warum ist RE wirtschaftlich?
Seite 53 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 54 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 55 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 56 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 57 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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
Seite 58 / 58 iks Thementag: „Mehr Softwarequalität“ – Garbage in – garbage out
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