Softwarequalität - Einführung in eine neue Vorlesung

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/