1
Softwarequalität
Einführung in eine neue Vorlesung
Gerrit Beine, [email protected]
Prof. Dr. Wolfgang [email protected]
2
Zur Motivation
3
ROTI
Maximise Your Return On Time Invested!
4
Vorstellung
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“
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
7
Und was qualifiziert uns für diese Vorlesung?
8
Unterschiede im Ablauf
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
10
Nach der Vorlesung...
...ist jeder verpflichtet seinen ROTI anzugeben!
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
12
Und die Inhalte?
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
14
Einführung und Grundlagen
15
Regelfall ???
16
Qualität
● Was ist das ?
● Wer spielt mit ?
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.
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
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
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
21
Wechselwirkungen der Qualitätssichten
[Wallmüller, Software Quality Engineering, Hanser-Verlag, 2011, S. 13]
22
Software-Entwicklung
Softwarequalität
Modellierung
Anforderungen
Design
Implementierung
Testen
Konfigurieren
23
Prozessmodelle – nur ein paar
[Wallmüller, Software Quality Engineering, Hanser-Verlag, 2011, S. 30]
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
25
Qualitätsprobleme - Architektur
"Hauptsache billig"
E.Rauschenbach
Deutscher Karikaturpreis 2003
26
Qualitätsprobleme – Ist vs Soll
Anforderungendes
Kunden
ImplementierteFunktionalität
27
Softwarequalität in der Praxis
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
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
30
Zwei Geschichten aus dem wahren Leben
● Die unerträgliche Leichtigkeit des Seins: 100% API-Dokumentation
● Der Scrum-Dopplereffekt: Test Driven Sprint Planning
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/
32
Wissen ist die einzige Ressource,die sich vermehrt, wenn man sie teilt.
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
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/