Die Einführungsfolien zur Vorlesung Softwarequalität.

1. Softwarequalität
Einführung in eine neue Vorlesung
Prof. Dr. Wolfgang Golubski Gerrit Beine, M.Sc.
golubski@fh-zwickau.de mail@gerritbeine.com
1

2. Zur Motivation
2

3. ROTI
Maximise Your Return On Time Invested!
3

4. Vorstellung
4

5. Wolfgang Golubski, Prof. Dr. rer.nat. habil.
● Jahrgang 1960
● Seit 2004 an der Westsächsischen Hochschule Zwickau
● Aktivitäten und Forschung auf den Gebieten
● Software-Entwicklung und -technologien und -Architekturen
● von Systems Engineering über Modellierung zum Programm
● Seit Anfang der 80er Software- und Tool-Entwicklung, auch im industriellen Umfeld
● Projektleitung in verschiedenen Vorhaben
● Objekt-orientierte Sprachen (Smalltalk-80, Eiffel, Java, JEE, etc.) und Methoden sowie
Modell-getriebene Entwicklung
● Zahlreiche (wissenschaftliche) Veröffentlichungen zu den Themen „Programmiersprachen
und Modell-getriebene Software-Entwicklung“
5

6. Gerrit Beine, M.Sc.
● Jahrgang 1980
● Selbständig seit 1998, zunächst im Bereich Linux/Unix Support
● Ab 2000 Einführung von Agilen Methoden, Test Driven Development, Continuous
Integration bei verschiedenen Unternehmen
● Nebenbei Informatik-Studium in Zwickau
● Ab 2006 Fokussierung auf ganzheitliche Softwarequalität
● Nebenbei Master-Studium in Zwickau
● 2008-2011 Software-Architekt bei AUDI
● Seit 2011 Scrum Master bei Saxonia Systems
● Dozent bei Open Source School (Test Driven Development, UML)
● Nebenbei MBA-Studium in Leipzig
● Seit einigen Jahre Speaker auf Linux- und Open Source Konferenzen
● Contributer für FreeBSD und openSUSE
6

7. Und was qualifiziert uns für diese Vorlesung?
7

8. Unterschiede im Ablauf
8

9. Vorbereitung & Ablauf
● 2 Wochen vor jeder Vorlesung geben wir eine Reihe von Artikeln aus
● 1 Woche vor jeder Vorlesung muss jeder zu jedem Artikel drei qualifizierte Fragen stellen
● Denn: Ein Drittel der Vorlesung basiert auf Euren Fragen!
● Aktive Teilnahme ist Zulassungsvoraussetzung zur Prüfung!
● Wer mehr als einmal keine Fragen schickt, kann nicht an der Prüfung teilnehmen.
● Jede Vorlesung gliedert sich in drei Teile
● Theorieteil – aktueller Stand der Forschung, Begriffe, Hypothesen
● Praxisteil – was passiert im Projekt, Anwendung der Theorie
● Teilnahme – Diskussion und Beantworten der Fragen, Erfahrungsberichte
9

10. Nach der Vorlesung...
...ist jeder verpflichtet seinen ROTI anzugeben!
10

11. Und das Projekt sowie die Prüfung?
● Finden statt
● Projekt
● Jeder verfasst ein Paper.
● Zur Form:
● 8-12 Seiten A4
● Arial, Schriftgröße 11
● 1,5-zeilig
● Zum Inhalt:
● Aus der Vorlesung werden zwei Aspekte von Softwarequalität ausgewählt
● Aus seinem reichhaltigen Erfahrungsschatz wählt jeder ein Projekt
● Das Projekt wird unter diesen beiden Aspekten reflektiert
● Was lief gut? Was lief schlecht?
● Was würde man nach der Vorlesung anders machen?
● Prüfung: mündlich
11

12. Und die Inhalte?
12

13. Softwarequalität aus unterschiedlichen Perspektiven
● Die Macht der Zahlen: Source Code Metriken
● Die falsch verstandene Methode: Testen wird überbewertet
● Qualitätsaspekte im Requirements Engineering
● Denn sie wissen nicht was sie tun: Modellierung
● Wir bauen auf, wir reißen nieder: Architektur und Qualität
● Retrospektiven: Auf dem besten Weg bleiben
13

14. Einführung und Grundlagen
14

15. Regelfall ???
15

16. Qualität
● Was ist das ?
● Wer spielt mit ?
16

17. Softwarequalität – was ist das?
● Qualität entsteht nicht von selbst.
● Qualität bezieht sich auf Produkte und Prozesse und Projekte.
● Qualität muss definiert werden.
● Qualität muss konstruiert werden.
● Versuch einer Definition (nach [Wallmüller])
ist die Summe aller relevanten Eigenschaften eines Software-Produkts, mit denen seine
Kunden zufriedengestellt werden, und die Summe der dazu notwendigen Eigenschaften
von Software-Prozessen wie z. B. erreichte Reifegrade, die zur Erstellung, zum Betrieb und
zur Pflege gefordert werden.
17

18. Softwarequalität – was ist das?
● Definition (ISO 9126)
ist die Gesamtheit von Funktionen und Merkmalen eines Software-Produkts, das die
Fähigkeit besitzt, angegebene oder implizierte Bedürfnisse zu befriedigen.
● Was fehlt für eine praktische Verwendung?
● Merkmale
● Aber was sind nun wieder Merkmale?
● Hier kann wieder ISO 9126 helfen
● Unterscheide funktionale und nicht-funktionale Anforderungen
18

19. ISO/IEC 9126 bzw. ISO/IEC 25000
● Eine Norm, die eins (von vielen) Modellen ist, dass Produktqualität und
Qualitätsmerkmale beschreibt
● DIN ISO/IEC 25000 Software-Engineering – Qualitätskriterien und Bewertung von
Softwareprodukten (SQuaRE) – Leitfaden für SquaRE
http://www.ehealthkarriere.de/tag/iso-9126
19

20. Qualitätsbegriff aus verschiedenen Sichten
● Produkt
● Qualität ist präzise messbar
● Anwender
● Qualität wird vom Anwender festgelegt
● Prozess (bzw. Hersteller)
● Qualität im Entwicklungs-/Herstellungsprozess durch Kontrolle, Audits, Inspektionen
● Preis/Nutzen
● Verhältnis von Kosten, Nutzen und Qualität
20

21. Wechselwirkungen der Qualitätssichten
[Wallmüller, Software Quality Engineering, Hanser-Verlag, 2011, S. 13]
21

22. Software-Entwicklung
Testen
Implementierung Anforderungen
Softwarequalität
Modellierung Design
Konfigurieren
22

23. Prozessmodelle – nur ein paar
[Wallmüller, Software Quality Engineering, Hanser-Verlag, 2011, S. 30]
23

24. Qualitätsmanagement
● Qualitätsplanung
● Festlegen der Ziele, Prozesse und der notwendigen Ressourcen
● Qualitätslenkung
● Erfüllen der Qualitätsanforderungen
● Präventiv
● Konstruktiv
● analytisch
● Qualitätssicherung
● Prüfung des QM
● Dokumentation
● Zertifizierung
● Nachweis von Verbesserungsprogrammen inkl. Nachverfolgung
● Qualitätsverbesserung
24

25. Qualitätsprobleme - Architektur
"Hauptsache billig"
E.Rauschenbach
Deutscher Karikaturpreis 2003
25

26. Qualitätsprobleme – Ist vs Soll
Anforderungen
des Implementierte
Kunden Funktionalität
26

27. Softwarequalität in der Praxis
27

28. Thesen von Praktikern
● Qualität kommt von Quälen
● Qualität wird nicht gesichert, Qualität wird produziert
● Qualität ist nicht verhandelbar
● Qualität ist ein Prozess
● Wer 80% anstrebt, bekommt auch nur 80% dieser 80% (das sind dann 64% ;-)
● Die Kosten für Qualität sind konstant,
die Kosten für fehlende Qualität wachsen exponentiell
● Was an Qualität gespart wird, muss an Zeit investiert werden
● Man kann Qualität nicht in Software hineintesten
28

29. Thesen von Praktikern
● Qualität kommt von Quälen
● Qualität wird nicht gesichert, Qualität wird produziert
● Qualität ist nicht verhandelbar
● Qualität ist ein Prozess
● Wer 80% anstrebt, bekommt auch nur 80% dieser 80% (das sind dann 64% ;-)
● Die Kosten für Qualität sind konstant,
die Kosten für fehlende Qualität wachsen exponentiell
● Was an Qualität gespart wird, muss an Zeit investiert werden
● Man kann Qualität nicht in Software hineintesten
29

30. Zwei Geschichten aus dem wahren Leben
● Die unerträgliche Leichtigkeit des Seins: 100% API-Dokumentation
● Der Scrum-Dopplereffekt: Test Driven Sprint Planning
30

31. Das magische Dreieck
● Klassisches Projektmanagement definiert
den Umfang von Projekten als konstant
● Zeit, Kosten, Qualität sind verhandelbar
● Auf Softwareprojekte praktisch nicht
anwendbar
● Reduktion der Qualität führt immer zu
einer Erhöhung der Kosten und Zeit
● Umfang sollte verhandelbar sein
● Qualität ist die einzige echte Konstante
Quelle: http://it-wissenschaft.de/333/magisches-dreieck-kosten-zeit-oder-qualitat/
31

32. Wissen ist die einzige Ressource,
die sich vermehrt, wenn man sie teilt.
32

33. Schneller Wissensaufbau in Teams
● Aufteilen der Artikel
● Jedes Teammitglied bearbeitet einen Artikel
● Pro Artikel wird eine Zusammenfassung erstellt (s.u.)
● Die Zusammenfassung wird im Team besprochen und Fragen geklärt
● Anschließend kann jedes Teammitglied anhand der Zusammenfassung durch den
Artikel navigieren und Details nachlesen
● Bearbeiten eines Artikels
● Artikel durchblättern und alle Überschriften in eine Mindmap packen
● Jeden Abschnitt durchlesen und Fakten extrahieren
● Worum geht es? Was wird erklärt? Warum ist das wichtig?
● Erkenntnisse unter der jeweiligen Überschrift in die Mindmap stecken
● Die Mindmap mit Verweisen ergänzen, wo es notwendig erscheint
● Grafiken und Diagramme vor dem Team komplett entwickeln
33

34. Verwendung dieser Unterlagen
● Wir stellen diese Unterlagen unter der Creative Commons Lizenz CC-BY-NC-SA zur allen
am Thema Interessierten Verfügung.
● Es ist erlaubt, die Unterlagen unter gleichen Bedingungen zu
● kopieren
● verteilen
● übertragen und
● adaptieren, wenn
● die ursprünglichen Autoren genannt werden und
● die Verwendung nicht zu kommerziellen Zwecken stattfindet.
● Details zur Lizenz sind hier zu finden:
http://creativecommons.org/licenses/by-nc-sa/3.0/
34