Seminar Software Qualität im WS 2017/18 · 2017-07-13 · Mail an junkerm@in.tum.de bis Mittwoch,...

Vorbesprechung am 13. Juli 2017

Prof. Dr. Dr. h.c. Manfred Broy

Dr. Maximilian Junker, Dr. Elmar Jürgens,

Dr. Daniel Mendez, Dr. Benedikt Hauptmann,

Henning Femmer, Dr. Sebastian Eder,

Roman Haas, Daniel Veihelmann

Seminar Software Qualität

im WS 2017/18

Seminar Software Qualität

Anforderungen TestImplementierung

- Unvollständige

Anforderungen

- Missverständliche

Dokumentation

- …

- Schlecht getestet

- Copy & Paste

- Keine

Kommentare

- …

- Fragile Tests

- Copy & Paste

- Nicht

deterministisch

- …

Qualität von

Anforderungen

Qualität von

Code

Qualität von

Tests

Mail an junkerm@in.tum.de

bis Mittwoch, 19. Juli

Inhalt

• Motivation für Seminarteilnahme u. Themen (<1 Seite)

• Stand im Studium

• Erfahrungen (Arbeit, Praktikum, Open-Source-Projekt, …)

• Themenwünsche (sortiert nach Priorität)

Rückmeldung Ende Juli über das Matching System

Teilnahme am Seminar

Anfang des Semesters: Auftaktveranstaltung

• Überblick Software Qualität

• Literaturrecherche

• Effektiv Präsentieren

vstl. Januar 2018: Seminar als Blockveranstaltung

• Block: 3 Tage Vorträge mit Diskussion

• genaue Termine klären wir zum Semesterstart

Ablauf

Inhalt

• Theorie

• Anwendung des Seminarthemas in der Praxis

Ergebnisse

Erfahrungen

Probleme & Grenzen

Abgaben

• Seminararbeit: 2 Wochen vor Vortrag

• Probevortrag (verpflichtend): 2 Wochen vor Vortrag

Umfang

• Arbeit: max. 15 Seiten (wir stellen Vorlage bereit)

• Vortrag: 25min + 20min Diskussion

Seminararbeit und Vortrag

Qualität von Anforderungen

1. Walkthroughs, Inspektionen, Prototypen: Techniken für manuelle

Requirements Reviews

(Henning)

2. Wie gut sind meine Anforderungen? Defekte in Anforderungen

automatisch detektieren.

(Henning)

3. Model-based Requirements Engineering: Bessere

Anforderungsqualität durch Modellierung?

(Maximilian)

6

Themen (I)

Walkthroughs, Inspektionen, Prototypen

- Techniken für manuelle Requirements Reviews

• Bei der NASA sind Fehler in Anforderungen manchmal nicht

mehr zu fixen.

• Deshalb machen sie strenge Reviews, so wie in diesem

Prozess.

• Wie funktioniert das, was kann man (anders) machen?

The shop system sends an E-Mail to

registered customers, optionally with

attachment.

• Schlechte Anforderungen sind riskant

• Manuelle Qualitätssicherung ist teuer und langsam.

• Deshalb: Automatisierung!

1. Was lässt sich automatisch erkennen?

2. Was nicht?

3. Wie funktioniert das?

Wie gut meine Anforderungen? Defekte in

Anforderungen automatisch detektieren

Qualität von Anforderungen

1. Walkthroughs, Inspektionen, Prototypen: Techniken für manuelle

Requirements Reviews

(Henning)

2. Wie gut sind meine Anforderungen? Defekte in Anforderungen

automatisch detektieren.

(Henning)

3. Model-based Requirements Engineering: Bessere

Anforderungsqualität durch Modellierung?

(Maximilian)

9

Themen (I)

10

Model-based Requirements Engineering

Dokumentenbasiertes RE

• Redundante und inkonsistente Informationen

• Missverständliche Beschreibungen

• Zusammenarbeit schwierig

Modellbasiertes RE

Sensor

AutoMode

OperationOn

Crane1Action

Crane2Action

SupplyBand

DeliveryBand

Funktionen des TransportationController

Sensor

AutoMode

OperationOn

Crane1Action

Crane2Action

SupplyBand

DeliveryBand

Sensor

AutoMode

Bewegungsauftrag

Crane1

Bewegungsauftrag

Crane2OperationOn

Sensordaten v erarbeiten

Sensor

AutoMode

Bewegungsauftrag

Crane1

Bewegungsauftrag

Crane2OperationOn

SupplyBand

DeliveryBandOperationOn

Förderbandbewegungen

berechnenSupplyBand

DeliveryBandOperationOn

Crane1ActionBewegungsauftrag

Crane1

Wegpunkte für Crane1

berechnen

Crane1ActionBewegungsauftrag

Crane1

Crane2ActionBewegungsauftrag

Crane2

Wegpunkte für Crane2

berechnen

Crane2ActionBewegungsauftrag

Crane2

«block»

UserInput

«block»

OperationOn

«block»

AutoMode

«block»

Sensor

«block»

Crane1Sensor

«block»

Crane2Sensor«block»

SupplyBandSensor

«block»

Deliv eryBandSensor

«block»

SensorSignal

«block»

Crane1SensorSignal

«block»

Crane2SensorSignal«block»

SupplyBandSensorSignal

«block»

Deliv eryBandSensorSignal

«block»

SystemOuput

«block»

Action

«block»

Crane1Action

«block»

Crane2Action

«block»

SupplyBandAction

«block»

Deliv eryBandAction

«block»

ActionSignal

«block»

Crane1ActionSignal

«block»

Crane2ActionSignal

«block»

SupplyBandActionSignal

«block»

Deliv eryBandActionSignal

+Raw Data translated by IOAdapter +Translated Signal

+determins

Determination

+determined

+Bus-conformant Data translated by IOAdapter +Raw Signal

+represented Information

Representation

+Displayed data

Initial

Anlage eingeschaltet

Anlage ausgeschaltet

Final

AutoMode ManualMode

Initial

[UserInput = AutoMode]

[UserInput = !AutoMode]

[UserInput: einschalten][UserInput:

terminieren]

[UserInput:

einschalten]

• Alle Informationen im zentralen Model-Repository, keine Redundanz (?)

• Eindeutige Interpretation (?)

Bessere Qualität?

Qualität von Code

4. Statische Analyse: Automatisches Auffinden von Bugs in Quellcode.

(Sebastian)

5. Clone Detection: Wo ist kopierter Quelltext im System?

(Elmar)

6. Clone Management: Wie wurde kopierter Quelltext gewartet?

(Elmar)

7. Sinn und Unsinn von Metriken zur Komplexität von Quellcode

(Daniel Veihelmann)

8. Code-Nutzungsanalysen: Welcher Code wird (nicht) genutzt?

(Daniel Veihelmann)

11

Themen (II)

Qualität von Code

4. Statische Analyse: Automatisches Auffinden von Bugs in Quellcode.

(Sebastian)

5. Clone Detection: Wo ist kopierter Quelltext im System?

(Elmar)

6. Clone Management: Wie wurde kopierter Quelltext gewartet?

(Elmar)

7. Sinn und Unsinn von Metriken zur Komplexität von Quellcode

(Daniel Veihelmann)

8. Code-Nutzungsanalysen: Welcher Code wird (nicht) genutzt?

(Daniel Veihelmann)

17

Themen (II)

1659 LOC / 1301 SLOC

Qualität von Code

4. Statische Analyse: Automatisches Auffinden von Bugs in Quellcode.

(Sebastian)

5. Clone Detection: Wo ist kopierter Quelltext im System?

(Elmar)

6. Clone Management: Wie wurde kopierter Quelltext gewartet?

(Elmar)

7. Sinn und Unsinn von Metriken zur Komplexität von Quellcode

(Daniel Veihelmann)

8. Code-Nutzungsanalysen: Welcher Code wird (nicht) genutzt?

(Daniel Veihelmann)

19

Themen (II)

Qualität von Code

9. Historienanalyse: Wie entwickeln sich Teams und wer kennt welchen

Code?

(Roman Haas)

10. Refactoring Empfehlungen: Automatische Generierung von

Verbesserungsvorschlägen für Code.

(Roman Haas)

11. Code-Zentralität: Was sind in diesem Softwaresystem die wichtigsten

Klassen?

(Roman Haas)

21

Themen (III)

Einarbeitung

abgebrochen

Neues Team

Knowledge-Transfer

UI

Core

Effects

Docking

Tools

TextTool.cs (17 Entwickler)

PintaProject/Pinta

Qualität von Code

9. Historienanalyse: Wie entwickeln sich Teams und wer kennt welchen

Code?

(Roman Haas)

10. Refactoring Empfehlungen: Automatische Generierung von

Verbesserungsvorschlägen für Code.

(Roman Haas)

11. Code-Zentralität: Was sind in diesem Softwaresystem die wichtigsten

Klassen?

(Roman Haas)

24

Themen (III)

1659 LOC / 1301 SLOC

Qualität von Code

9. Historienanalyse: Wie entwickeln sich Teams und wer kennt welchen

Code?

(Roman Haas)

10. Refactoring Empfehlungen: Automatische Generierung von

Verbesserungsvorschlägen für Code.

(Roman Haas)

11. Code-Zentralität: Was sind in diesem Softwaresystem die wichtigsten

Klassen?

(Roman Haas)

26

Themen (III)

Bild: http://en.wikipedia.org/wiki/File:Centrality.svg

Qualität von Tests

12. Natural Language Test Smells: Qualitätsdefekte in manuellen Tests

automatisch erkennen.

(Benedikt)

13. Warum zerbrechen meine automatisierten GUI-Tests? Statische

Analyse von automatisierten Tests.

(Benedikt)

14. Anforderungsbasiertes Testen: Wie stimme ich meine Tests auf die

Anforderungen ab?

(Maximilian)

29

Themen (IV)

30

Natural Language Test Smells: Qualitätsdefekte in manuellen Tests automatisch erkennen.

30

Automated Test 01 – Login Dialog

1. Open application C:\programs\keepass\2.0\keepass.exe

2. Validate Windows is visible “Open Database – New Datbase.kdbx”

3. Enter value “Master Password” “123mysecret$”

4. Click Button “Cancel”

… … …

31

Warum zerbrechen meineautomatisierten GUI-Tests?Statische Analyse von automatisierten Tests.

Qualität von Tests

12. Natural Language Test Smells: Qualitätsdefekte in manuellen Tests

automatisch erkennen.

(Benedikt)

13. Warum zerbrechen meine automatisierten GUI-Tests? Statische

Analyse von automatisierten Tests.

(Benedikt)

14. Anforderungsbasiertes Testen: Wie stimme ich meine Tests auf die

Anforderungen ab?

(Maximilian)

32

Themen (IV)

33

Anforderungsbasiertes Testen: Wie stimme ich

meine Tests auf die Anforderungen ab?

Qualität von Tests

15. Qualitätssicherung von Tests durch Mutation Testing

(Daniel Veihelmann)

16. Test Gap Analyse: Werden Systemänderungen auch wirklich von

Tests erfasst?

(Daniel Veihelmann)

34

Themen (V)

Qualität von Tests

15. Qualitätssicherung von Tests durch Mutation Testing

(Daniel Veihelmann)

16. Test Gap Analyse: Werden Systemänderungen auch wirklich von

Tests erfasst?

(Daniel Veihelmann)

36

Themen (V)

• = Modifiziert & ungetestet

• = Neu & ungetestet

• = Unverändert

• = Geändert & ausgeführt

im Test

Prozessqualität / Anforderungsqualität

17. Besserer Prozess durch bessere Anforderungen? Wie hängen die

Qualität von Artefakten und die Qualität des Prozesses zusammen?

(Daniel)

18. Prozessverbesserung im Requirements Engineering: Prinzipien

und Ansätze

(Daniel)

38

Themen (VI)

Fragen? Anmerkungen?