# Qualitätsmanagement

## Benotung etc.
Prüfungsstoff: Buch Agile + Folien + Moodle Seiten (Multiple + offene Fragen)
Präsentationen: Inhalte des Buches - kapitelweise

# Block 1: Qualitätsmanagement allgemein
## Allgemeine Gedanken
Im 20. Jahrhundert Entwicklung von Verkäufermarkt -> Käufermarkt: Bessere Lage für Käufer, Käufer bestimmen den Markt.
Verkäufermarkt: nicht notwendig hohe Qualität zu liefern, bestimmen den Markt, Produkte werden sowieso gekauft

Produktionsorientierung -> Marktorientierung: Qualität ist gestiegen weil auch Nachrichten über schlechte Qualität sich schneller verbreiten
Heute besteht der Käufermarkt aus aufgeklärten indiv. Kunden

Qualitätsbegriff - stark geprägt ihn den 60er/70er:
>"Quality is free" - Crosby, Qualität rentiert sich

**Allgemeine Definition: Qualität ist die Überlappung von geforderten und gelieferten Eigenschaften. je größer Überlappung -> größere Qualität, Eigenschaften sind implizite und explizite Anforderungen**

Qualität schafft Wettbewerbsvorteil - aber nicht alles optimierbar (Qualität, Kosten, Zeit) - widerspricht Crosby nur zum Teil, da dieser auf lange Sicht denkt

## Software Qualitätsmanagement
Software Qualität = Gesamtheit aller Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, Anforderungen zu erfüllen

Software Quality Model ISO 9126
Wie wichtig welche Eigenschaft ist hängt von Software ab. Internal Quality: Design, Code Qualität aus Entwicklersicht
External: aus Benutzer Sicht

**Wofür Qualitätsmanagement?**
* Damit wir wissen warum wir keine Probleme haben
* Qualitätsmanagement stellt sicher das Qualitätsptobleme identifiziert und prevented werden können.
* Schwierig ohne klare Anweisungen selben Prozess immer wieder gut auszuführen.
* Prozessen, Rollen und Verantwortlichkeiten sollten dokumentiert sein und verfolgt werden

**Zeitliche Entwicklung QA**
1. Quality Control and sorting - fokus auf produkt mittels Reaktion
2. Quality testing with statistical basis - fokus auf produktfertigungsprozess
3. Quality actions in all sectors - fokus auf entwicklungsprozess, im vorhinein verhindern
4. Total Quality concepts (TQM) - ISO 9001 verkörpert das, heute noch gültig

**Quality Gurus**
Demming: Statistiker und Mathematiker
Demming Kreis oder PDCA Zyklus beschreibt Kreislauf zurkontinuierlichen Verbesserung.
Demming Chain
Demming's 14 points
1. Create constancy of purpose toward improvement of product and service, with
the aim to become competitive and stay in business, and to provide jobs.
2. Adopt the new philosophy. We are in a new economic age. Western
management must awaken to the challenge, must learn their responsibilities, and
take on leadership for change.
3. Cease dependence on inspection to achieve quality. Eliminate the need for
massive inspection by building quality into the product in the first place.
4. End the practice of awarding business on the basis of price tag. Instead,
minimize total cost. Move towards a single supplier for any one item, on a longterm relationship of loyalty and trust.
5. Improve constantly and forever the system of production and service, to
improve quality and productivity, and thus constantly decrease costs.
6. Institute training on the job.
7. Institute leadership (see Point 12). The aim of supervision should be to help
people and machines and gadgets to do a better job. Supervision of management
is in need of overhaul, as well as supervision of production workers.
8. Drive out fear, so that everyone may work effectively for the company.
FH Campus Wien | 28
Deming's 14 Points
9. Break down barriers between departments. People in research, design, sales,
and production must work as a team, to foresee problems of production and in
use that may be encountered with the product or service.
10. Eliminate slogans, exhortations, and targets for the work force asking for
zero defects and new levels of productivity. Such exhortations only create
adversarial relationships, as the bulk of the causes of low quality and low
productivity belong to the system and thus lie beyond the power of the work
force.
11. Eliminate work standards (quotas) on the factory floor. Substitute leadership.
Eliminate management by objective. Eliminate management by numbers,
numerical goals. Substitute leadership.
12. Remove barriers that rob the hourly worker of his right to pride of
workmanship. The responsibility of supervisors must be changed from sheer
numbers to quality. Remove barriers that rob people in management and in
engineering of their right to pride of workmanship. This means, inter alia,
abolishment of the annual or merit rating and of management by objective.
13. Institute a vigorous program of education and self-improvement.
14. Put everybody in the company

**Total Quality Management**
Bezeichnet die fortwährende und ale Bereiche einer Orga erfassende Tätigkeit, die dazu dient Qualität asl Systemziel einzuführen und zu garantieren.

Total
* Prozesse
* Kunden
* Mitarbeiter
* Gesellschaft

Qualität umfasst alle
Quality
* Company
* Work
* Potentials
* Prozesse
* Results

Management
* Leadership (vorleben was man sich wünscht)

In der Mitte von TQM -> QIP Kontinuirlicher Verbesserungsprozess

**ISO 9000 serie**
Wichtig 9001: Nur dafür gibts ein Zertifizierung
Alle 3 Jahre muss die erneuert werden, jedes Jahr Überprüfung
ISO 9000: QM - Definitionen
ISO 9001: QM-Systeme - Anforderungen
ISO 9000-3: Anwendung von ISO 9000 auf Software
ISO 9004: Leiten und Lenken für den nachhaltigen Erfolg einer Organisation - Ein QMansatz

**ISO 9001**
Was wird verlangt:
Ein Set von Prozeduren dass alle Prozesse covert im Business
Müssen beobachten und dokumentiert werden. Fehlerüberprüfung, Review von Przessen, Continuous Improvement
Kritik: ISO 9001 fördert vor allem nur Prozessabwicklung -> es kann trotzdem noch ein schlechtes Produkt rauskommen

**Qualitätsmanagementsystem (QMS) (ISO9000)**
* Ein QMS umfasst Aktivitäten, mit denen die Organisation ihre Ziele identifiziert und die Prozesse und Ressourcen bestimmt, die zum Erreichen der gewünschten Ergebnisse erforderlich sind.
* Das QMS steuert die interagierenden Prozesse und Ressourcen, die erforderlich sind, um Werte zu schaffen und Ergebnisse für die relevanten interessierten Parteien zu erzielen.
* Das QMS ermöglicht es der obersten Leitung, den Einsatz der Ressourcen unter Berücksichtigung der lang- und kurzfristigen Folgen ihrer Entscheidungen zu optimieren.
* Ein QMS bietet die Möglichkeit, Maßnahmen zur Behebung beabsichtigter und unbeabsichtigter Folgen bei der Bereitstellung von Produkten und Dienstleistungen zu ermitteln

**Implementing Quality Managements**
1. Management Decision and strategy plan
a. Funktioniert nur mit Support von oben
b. Stakeholder, Strategic objectives identifizieren
2. Identify Requirements
a. Was genau will ich erreichen
3. Structure Q-System and processes
a. Aufbau (Hierarchien) vs Ablauforganisation (prozesse) - Aufbau meistens klar, Ablauf oft nicht so klar
b. Daher geht es vor allem darum Ablauforganisationen zu dokumentieren - Dazu Einteilung in Kern (Software), Unterstützungs -und Managementprozesse
c. Was sind Inputs/outputs von Prozessen wer ist verantwortlich, Wie kann der Prozess gemessen und verbessert werden
4. Document Quality System
a. Quality Policy
b. Quality Handbook...
5. Quality Management Handbook Contents
a. Verantwortlichkeiten, Rollen, Wie werden Fehler erfasst
6. Auditing and Recertification
a. Zertifikat hält 3 Jahre mit jährliche Überwachungsaudit
7. Continous Improvement
# Block 2: Qualitätsmanagement Software

**Software Crisis (1969) -> Software Hell (1999)**
1969 Berchtesgaden: Programmieren von Software -> Software Engineering, Und Software Crisis wegen Bugs....
1999: Software Hell -> Jahr 2000

**Unterschiede Software vs Brücken**
Im Gegensatz zu anderer Architektur ist man mit Software oft mit späten Change-Requests konfrontiert weil der Kunde oftmals die Konsequenzen nicht kennt.
Unterschiede:
* Software fällt nicht (zufällig) von alleine aus - nur systematische Fehler
* Software noch nicht so lange wie Brückenbau
* Software ist nicht stetig
* Konzepte aus physischer Welt treffen nicht zu
* Software hat keine Fertigungsphase
* Software kann leicht geändert werden
* exhaustive testing is impossible

## History of SDE Process

**70er: Wasserfall**
* Ältestes Model
* Backwards steps zu vorherigen Schritt
* In Relität überlappen sich die Phasen
* War nie als klassischer Wasserfall vorhergesehen
* Sehr populär, aber offen missverstanden aufgrund Einfachheit

**80er Vmodell**
* Abhängikeiten zwischen development and testing stages
* Outputs of early stages are tested late -> errors late detected
* Verification vs Validation: Validation = erfüllt die Programmierung den Zweck - wurde das richtige implementiert, Verification = Wurde es richtig implimentiert - Validation nur bei Acceptance Tests ansonsten Verification

**Late 80er Spiral Modell**
* sehr anders und komplex
* Softwareentwicklung geht in Zyklen
* Idee der großen Iteration erstmal aufgetreten

**Late 90er: Incremental Development/Rashman Unified Process**
* Alles passiert paralell
* Several builds, each build implements additional functionality
* a succession of waterfalls

**2001 Agile Manifest**
* Values
* Individuals and Interactions over Processes and tools
* Working software over comprehensive docs
* Customer collaboration over contract negotiation
* Responding to change over following plans
* Values on the right sind trotzdem wichtig aber links höhere value

**Prinzipien des Agilen Methods**
1. Customer at center
2. Team self organize
3. Work at sustainable pace
4. Develop minimal Software
5. Accept change
6. Iterative develoment
7. Tests as a key resource
8. Express reqs through scenarios

**XP: eXtreme Programming (Kent Beck)**
Prinzipien:
* Pair Programming
* Shared Office
* Coding Standards
* Customer Integration
* Permanent Module Tests
* Short Release Cycles
* Refactoring for simplicity

**Scrum Process**
* 1 Goal: working software
* 2 Lists: Product + Sprint Backlog
* 3 Roles: Product Owner, Scrum Master, Scrum Team
* 4 Meetings: Sprint Planning, Daily Scrum, Sprint Review, Retrospektive

Trend zu agil in den letzten 10 Jahren stark gestiegen - phasenorientiert immer weniger, ohne vorgehensweise recht gleich aber niedrig

Agil liefert im Durchschnitt bessere Kundenzufriedenheit, 2. Planungsphase, 3. Ohne Vorgehensweise

Schwerwiegende Fehler: Meisten 1. Ohne Vorgehensweise, 2. Agil, 3. Planung

=> Daher in Hochsicherheitssystemen nicht in scrum

**Software Engineering Science**
* Meistens nur Anekdoten, Fallstudien, Erfahrungsberichte die geralisiert werden. Brauchen empirisches software engineering, die scientif criterias erfüllen
* Mythen (mit null evidence)
* 10x claim on programmer productivity
* Cone of uncertainty
* Expontiaö cost curve

**Zukunftsaussichten**
Problem: Ist Scrum skalierbar?
Ideen aber nicht durchgesetzt:
* Scrum of Scrums
* SAFe
* Disciplined Agile Delivery
* Nexus, Large Scale Scrum
* LeSS

**Gegenbewegungen zu Agil**
* Anti-Agile Manifesto
* Manifesto for Sofrrware Craftsmanship
* Kanban - vielleicht besser für schon bekannte prozesse die einfach abgearbeitet gehören

## Software Quality and Dependability

Portability/Maintainability ->interne Software Quality
Rest von ISO -> exterm

**IEC/IEEE 25000**
Definitionen:

**Maintenance Costs for Software System**
67% der Kosten geht in die Wartung. Qualitätsmetriken (internal quality) erhöhen Verständlichkeit und Wartbarkeit. Wartung wird einfacher durch Code Quality

**Dependability tree (Laprie)**

Faults vs Errors vs Failures
im Deutschen fälschlicherweise alle Fehler
* Fault: etwas dass nicht passt in einer Software (Bug), (Fehlerursache Bsp. Programmierfehler)
* Error: Fehlzustand: Diskrepanz zwischen berechneten, beobachteten Wert und Soll-Zustand (Fehlerzustand Bsp. falsch berechnete Variable)
* Failure: Eine gewollte Funktion funktioniert nicht mehr (Ausfall, Fehlfunktion)

**Failure Chain (Laprie)**
Wenn Fault aktiviert wird kommt es zu einem Error. Erst wenn der Error propagiert wird (nach außen sichtbar wird) ist er ein Failure. Kein 1:1 Verhältnis sondern m:n.
Operational profile = Benutzungsart der Software
Failures hängt von op profile ab und sind meist multi-causal

Für die verschiedenen Arten gibt es verschiedene Metriken zum Messen. Fault -> Anzahl an Bugs pro 1000Zeilen Code, Failure -> Ausfälle pro Zeiteinheit

Rückschluss von Failure auf Bug = Debugging

**OP Profile**
= Ausführungsumgebung, Menge der Lauftypen, die das Programm ausführen kann, sowie die Wahrscheinlichkeiten, mit denen sie auftreten

**Systematische vs Random Faults/Failures**
* Systematic Fault: Reinprogrammierter Fehler, Bug
* Systematic Failure: Resultiert aus Systematic Fault
* Random Fault: Hardware geht plötzlich kaputt
* Random Error: Failure occuring at a random time

Was liegt dazwischen?
* Bohrbug:
* Software fault dass einen Fehler produziert der durch gleichen Input wieder entsteht
* Heisenbug (Quasirandom Faults):
* Software fault der manchmal einen Fehler hevorrufft unter Umständen die zufällig wirken
* können in Hardware und Software vorkommen
* auch quasirandom faults -> wirken nur zufällig sind nicht echt zufällig (sind durch statische/systematische Bugs verursacht)
* Bsp. Race Condition, Priority inversion, Resource depletion, reaction to limit conditions, accumulation of floating point rounding errors, reaction to rare environmantal conditions, counter overflows


# Block 3 + 4
## Software Reliability and Availability
Zuverlässlichkeit vs Verfügbarkeit

**Definitions**
* Mean Time Between Failures: Average time between two failures, average time system is running -> zum Messen von Reliability. Inverser Wert -> Fehlerrate
* Mean Time to Repair: Durchschnittszeit für Restart (Downtime)
* Reliability: Wahrscheinlichkeit dass das system in einer richtigen Weise Läuft -> nimmt mit der Zeit ab
* Availability: Wird in Prozent gemessen. Wie viel Zeit ist der Service down. Berechnung MTBF/(MTBF+NTTR)

**Failure Rate**
* Hardware: Badewanne-Graph. Viele Fehler am Anfang, dann weniger und am Ende wieder mehr nach gewisser Lebensdauer (burn in, useful life, wear out)
* Software: Zeigt eine sinkende Fehlerrate (Integrations + Testphase, useful life, obsolete)
* Funktioniert nur unter Behauptungen -> zu stark, daher schwierig Fehlerrate zu skizzieren
* Software ist ständig gewartet
* Faults are removed over time and no new faults are introduces
* OP profile ändert sich nicht
* keine neuen Features

Fault Density (Fault pro Kilo Lines of Code) auch schwer aber leichter vorherzusagen. <1 fault/KLOC ist sehr gut meistens mehr -> bug frei ist unrealistisch

Verschiede Versuche Fault Estimation zu berechnen
zb. based on Coding Standard -> nur für einige Standards gilt daran halten ergibt weniger Fehler

Methoden:
* Historische Daten -> vermutlich am sinnvollsten wenn Daten zur Verfügung
* Software Reliability Models
* sehr mathematisch keinen Praktischen Erfolg
* Simulation
* Experten Fragen

**Conclusio**
Software Reliability models sollen zukünftige Fehlverhalten vorhersagen (MTTF, Availability, Failure Rates). Ermitteln scheint immer noch schwierig außer in der Retrospektive. Dafür können historische Daten verwendet werden. AUch nur dann wenn es die selbe Software mit gleichem op profile betrifft, die lange in Betrieb war um statistisch signifilante Daten zu haben.

## Requirements Engineering
Es muss sich auf einfach verständliche Begriffe geeinigt werden.

**Properties of High Quality Requirements**
* lesbar und eindeutig interpretierbar
* testbar
* wartbar
* konsistent
* vollständig
* atomar / nicht teilbar
* lösungsoffen
* von acquirer und provider agreed
* so wenig wie möglich, so viel wie nötig

**Probleme mit Reqs**
* Undkokumentiert
* Zu viele Details (lösungsweg wird beschrieben)
* Mehrdeuting und unkomplett

**Gute Reqs**
* Simple Sätze
* Aktiv statt Passiv
* negatice reqs vermeiden
* jedes pronomen muss eine unmissverständliche referenz haben
* gewisse adjektive/adverbe vermeiden

**Keywords**
Gute Reqs verwenden diese Keywords
* Shall -> muss
* Should -> sollte
* may -> optional

Reqs werden in natürlicher Sprache beschrieben weil sie weit verbreitet ist:
Vorteil: kann jeder verstehem und kann fast alles ausdrücken
Nachteil: Mehrdeutig, keine automatische Verifikation, reqs consistency hard to verify

Mögliche Lösungen: Structured language, defined vocabulary, alternative Notaionsn (use case, formal methods)

## Software Architektur und Design
**Software Design**
Modellierung der Software Lösung: Architektur, Algorithmen, Klassen, Schnittstellen etc.

**Properties of good Design**
* well understood
* possible to reason about design language
* domainen spezifische erweiterungen verwenden
* design soll implementierung vorhersagen können
* design muss durch code verifizierbar sein
* assurance needed für verwendete tools (code generators)

**Design Tools and Methods**
* UML
* Use Cases, Sequenz, Klassen, Zustandsdiagramme...
* powerful language für viele Diagrammtypen
* Design Patterns
* Designs wiederwendbar machen
* designs für oft auftretbare Probleme
* Kohäsion
* Beantwirtet wie nahe die Teile einer Komponente miteinander verwandt sind zb. Klassen und Methoden -> wie gut passen die Methoden in diese Klasse
* high cohesion erwünscht
* Kopplung
* = wie unabhängig ist eine Komponente, wie stark ist die Interaktion zwischen Komponenten
* schwache Kopplung erwünscht
* Understandability
* Wie einfach ist die Funktionalität einer Komponente zu verstehen
* Versuche zu KISS prinzip (Keep It Small and Simple)
* meist schwer zu finden
* Verwende standardmäßige Formate
* Bei grafischen Representationen -> Bedeutung der Symbole erklären
* Nutze bewährte Design Patterns
* Adaptabiliy
* Wie leicht kann eine Komponente verändert werden

**Design Quality Metrics**
Bsp. Klasse die von anderen Komponenten benutzt wird
* Fan-in -> Anzahl die diese Klasse benutzen
* hoher Fan-in -> hohe Kopplung
* Fan-out -> Anzahl der Klassen die benötigt werden von der Ausgangsklasse
* Komplexität bei hoher Fan-out wahrscheinlich zu hoch

Komplexität der Komponente = Länge x (Fan-in x Fan-out)²
Länge: zb. LOC

Eher ein Vergleichswert kein absoluter

**Design for Software Fault Tolerance**
Idee mit Fehlern in SW zu leben.
Def. Fehler können entdeckt und von ihnen erholt werden. Basiert auf Annahme dass Fehler im System existieren

Typische Technik: Redundanz
Software Redundanz: Unterschiedliche SW-Versionen
* N-Version Programming
* Recovery Blocks

Correct by Construction ist Gegenteil fon Fault Tolerance: nasiert auf Annahme das Fehler direkt eliminiert werdn können (Cleanroom approach)

## Software Implementation
**Coding**
Implementierung einer vorgegebenen Lösung
2 wichtige Eigenschaften müssen erfüllt werden:
* lesbar -> wegen Wartbarkeit
* funktionieren -> verlangt Tests

Bei Code gilt auch 80% / 20% Regel mit Implementierung von Features/Zeit.

**Coding Standards**
Ziele:
* SW lesbar machen
* Erhöht wartbarkeit, wiederverwendbarkeit und debugging
* Vemeidet Programming Pitfalls

80% of SW geht in Wartung
Coding Standards sind ein kontroverses Topic - jeder hat sein eigenes

Regeln und Empfehlungen
* Wenn eine Regl gebrochen wird muss das dokumentiert werden
* Sinnvolle Variablennamen
* Max. SLOcs per file/function
* Prefixes for variables
* File and function layout

**Software Metriken**
werden verwendet um qualitätsattribute von Code/Design zu messen
* Understandability, COmplexity, Maintainability, Reliability, Usabitlity

Gute Metrik muss
* messbar sein
* Infos liefern
* wenn was hinzugefügt wird darf die komplexität nicht sinken
* muss für alle Programme funktionieren

Lines of Code: ohne empty lines SLOC
= einfachste Metrik - bei 1 Bug pro 1000LOC -> modernes Auto 100 000 Bugs

Cyclomativ Complexity (CC)
= stellt Komplexität des Flussgraphen dar. Misst die innere Komplexität eines Programms. Misst Kanten und Knoten

Kanten + Knoten + 2 = CC, Je höher CC -> desto mehr Fehler und Fehlerdichte (Fehler/LOC), sollte nicht über 10 gehen
Messbar mit Tools wie SonarCube

Halstead Metrics
* basiert auf operanten (variablen) und operatoren (rechenops, keywords)
* n1: Number of distinct operators
* n2: number of distinct operands
* N1: Totale Anzahl von Operanten
* N2: Totale Anzahl

**Software Static Analysis**
Analysieren der Software ohne sie auszuführen
Geben Statistiken wie LOC, CC aus..

Metrics Interpretationen
* Kleinere Systeme können mehr ABweichungen tolerieren,
* Weniger Kommunikation notwendig
* Vergleiche besser nur innerhalb von Programmiersprachen
* Höhere CC -> Höhere Fehlerdichte - aber nicht umbedingt viel Code -> Fehler

**Defensive Programming**
immer von einer schadhaften Umgebung ausgehen, Fehler, Inputs abfangen...
Das bedeutet:
* Range checks
* Plausibility checks (ist wert plausibel)
* Konfigurationen und Checksummen
* default statement im switch
* Divide / 0 überprüfen
* Paramter Checks
* Reihenfolge des Flows checken
* Mehrfachberechnungen

Vorteil:
* resilienter gegen Fehler (robustness)

Kosten:
* steigende Komplexität
* extra code

**Code Review**
* formales Review
* code wird sematisch gecheckt

**Code Inspections**
* verschiedene Rollen und Lesetechniken
* formaler Prozess
* Doku

## Software Testing
Entwickler und Tester haben unterschiedliche Ziele -> Tester will Bugs finden, Entwickler will dass System abgenommen wird

Testing Ziele
* So viele Fehler so früh wie möglich
* FInd faults
* Kosten vermeiden durchs frühe finden

In der Praxis ist Testen der wichtigste Teil zu demonstrieren dass ein System funktioniert obwohl nur die PRäsenz von Bugs nachgewiesen werden kann und nicht die Abwesenheit. Funktioniert nicht gleich fehlerfdrei

**Bug Taxonomy**
Fehler überall können vorkommen
* Code
* Anforderungen
* Data.....

**Exhaustive Testing**
nicht möglich in praxis daher müssen die richtigen Testfälle gefunden werden. Das heißt diese die möglich einen Fehler aufdecken.

Eine der schwierigsten Probleme ist zu wissen wann man mit dem Testen aufhört.

**Testing Methods**
Auf verschiedenen Leveln (Unit, Module, System)
mit verschiedenen Methoden (Code Revide, Grenzwert, Dynamic analyse (white vs black box), regressions test)
verschiedene dinge testen (Feautures, load, architectur)

Unterschiedlicher Testmethoden finden verschiedene Fehler.

Prinzipielle Unterscheidung: Black vs White Box
Black:
Ich kenn die Anforderungen und weiß wie Input und Output zueinander stehen. Testklassen leiten sich von Anforderungen ab. Kein Wissen über die Struktur. Dann fertig wenn alle Anforderungen getestet sind

White:
Information über die Architektur, Implementierung, interne Struktur ist verfügbar und wird für die verschiedenen Testfälle verwendet. Testfälle basiert auf Design/Code.

**Code Coverage**
Manche SAfety Critical Standards benötigen eine gewisse Anzahl an SW Coverage

Arten von Coverage
* Statement Coverage (misst Lines of Code die getestet wurde)
* Decision Coverage (Beide ENtscheidungspfade werden ausgeführt)
* Decision/condition (Nicht nur beide wege müssen gegangen werden sondern alle)
* Full path coverage

**Failure Finding Analyse**
Es sollte in einer realistischen Testumgebung getestet werden damit viele Fehler schon vor dem Produktivgehen gefunden werden können.

## Software Redundanz und Diversität
Redundanz = mehrfach vorhanden
Diversität = mehrfach aber auch unterschiedlich

**Fault Tolerance**
Fehler sollen erkannt werden und recoverd. In der HW klappt das über Redundanz wegen Zufallsfehler was in der SW nicht gut geht wegen Systematischen Fehler

Möglichkeit wäre Software Redundanz -> braucht allerdings Diversität
* N-Version Programming (von unterschiedlichen Teams/Programmiersprachen wird die gleiche Software produziert)
* bei hochkritischen System üblich sonst zu teuer
* Recovery Blocks

**What is diversity**
diverse = widely varied, the state of being diverse
Wenn eine Berechnung mit unterschiedlichen Methoden gemacht wird und dasselbe rauskommt -> dann ziemlich sicher das es passt

Typische domänen:
* Railway interlocking and signalling, reactors, aerospace, air traffic control

Bsp. Reaktor mit Ventil wenn Druck zu hoch ist
Software die Druck misst muss durch SW Redunzanz implementiert werden

Fragen:
* Welche gemeinsamen Fehler können die Systeme haben
* Was muss divers sein
* Wie viel Diversität braucht es
* Kann man diversität messen
* sind die systeme wirklich unabhängig von einander
* Safety vs Reliability

**Examples of Diversity**
Design Diversity
* Software ist unterschiedlich designed von verschiedenen Teams und dann gibt es einen Voter der entscheidet über das Ergebnis (beide müssen übereinstimmen oder 2 aus 3)

NVP ist Form davon. Gibt unterschiedliche Meinungen wie sinnvoll das wirklich ist
Ergebnisse:
* Unabhängigkeit oft nicht gegeben weil Fehlerwahrscheinlichkeit bei komplexen Tasks bei allen System höher
* Trotzdem besser als Einzelsystem
* Qualität von Fehlerdetektion variert stark zwischen den Varianten
* Eliminiert Systematische Software Faults (Programmierfehler)
* Probleme können machen
* Anforderungsfehler
* Unabhängigkeit von Teams
* Denken Menschen ähnlich
* Ist der gemeinsame Voter nicht immer das Problem?
* Muss diversität vielleicht geforced werden (Sprache, IDE...)
* Consistant Comparison Problem
* Back to back testing possible
* cost

Compiler Diversity
Verwendung von verschiedenen Compilern für die selbe Software.
* Hilft gegen Compiler Fehler
* Auch gegen manche Quasirandom errors
* Auch gegen manche Hardware Fehler/Bitflips -> durch mehrfache Ausführung

Issues:
* Würde auch it verschiedener Konfig eines COmpilers funktionieren
* Unabhängigkeit verschiedener Compiler muss garantiert sein

Bsp. Boeing
Keine SOftware Diversität dafür Hardware und Compiler Diversität, weil lieber aufwand für fehlerfreie Software

Unterschied Airbus: Diversität in der Applikation

Es gibt kein richtig oder falsch bei Software Diversität

# Block 5 Referate
## Agile Overview
### Manifesto
* Dokument das grundlegende Konzepte beschreibt
* 2001 erstellt und legt fokus auf Flecibilität und ständige Verbesserunge

4 Grundwerte
* Individuen und Interaktionen > Prozesse und Werkzeuge
* Prozesse sind nicht streng, Zusammenarbeit ist wichtiger - direkte Kommunikation im Vordergrund
* Real Life Probleme
* ineffektive Kommunikation innerhalb und Team übergreifend
* Hierarchische Strukturen die gegenströmen
* Mangelnde EInbeziehung Mitarbeiter in Entscheidungsprozesse
* FUnktionierende Software > Doku
* Anforderungen erfüllen ist am wichtigsten, Doku zwar auch aber nur zweitrangig
* RFP:
* Doku überbetont -> Zeit
* Mangelnde Priorisierung auf funktionsfähige Software
* unzureichende Tests
* Schlechte Qualität -> schwierige Einbindung neuer Mitarbeiter
* Zusammenarbeit mit Kunden > Vertagsverhandlung
* Prozesse sind nicht streng, Zusammenarbeit ist wichtiger - direkte Kommunikation im Vordergrund
* Real Life Probleme
* schwierige Komm mit Kunden
* Kunden zu wenig miteinbezogen
* Starre Vertragsvereinbarungen die Änderungen erschweren
* Reagieren > Plan
* Veränderungen sind unvermeidlich - muss flexibel sein. Auf Änderungen wird reagiert stat streng Plan zu verfolgen. Erhöht Wert des Endprodukts
* RFP:
* Management Widerstand
* Prozesse nicht flexibel gegnüber Änderungen
* Mangelnde Kommunikation über Änderungen

Ungewollte Nebeneffekte:
* Starre Infra - Unwille zur Investition in neue Werkzeuge
* Ewige Planung - zu viel Börukratie
* Häuptling - kontra zur Kommunikation
* Agil - Kaschieren von schlechten Management
### Values
= verdeutlichen den agile Ansatz wie es in der Praxis umgesetzt werden soll

Werte:
* Flexible Rollen (Verantwoortung mehr beim Team)
* Iterative Entwicklung statt ewige Planung
* Enge Zusammenarbeit mit Kunden
* Kontinuierliches Testen
* Ständige Verhandlung und Konzentration auf wesentliche Funktionen
* Qualität im Fokus - durch Tests gesichert

Mögliche Probleme:
* Neue Rollen -> Konflikte
* Nicht bereit für Prozessänderungen
* Kommunikation nicht gut -> unklare Anforderungen
* Fehlende Klarheit bei Priorisierung -> Konflikte
* Falsche Teststrategien

Lösungen:
* Schulungen, Planung, Kulturveränderung, schrittweise EInführung der agilen Methoden
* klare Vision und Führung von Management
### Principles
Orga Prinzipien bilden Grundlage für Projektorga, autonome Teams, fleicibilität gegenüber Änderungen, Kundenzentriertheit, Arbeitsbelastung, Minimalistische
* Kundenorientierung
* Selbstorga der Teams
* NAchhaltiges Arbeitstempo
* Minimalistischer Ansatz
* Akzeptanz von Veränderungen

Technische Prinzipien: Grundlage für agile Entwicklung, Qualitätstest, qualitätsorientierte Entwicklung
* Iterativer Entwicklungsprozess
* Testfokussierung
* Nutzung von Szenarien zur Definition von Funktionalität
* kommen von Kunden
### Roles
Es gibt verschiedene Rollen in selbstorganisierten Teams. Scrum definiert zusätzlich
* Product Owner (Definition der Produkteigenschaften)
* Scrum Master (Methodenverantwortlicher)
* Kunden nehmen eine explizite Projektrolle ein
### Practices
Orga Practices
* Daily: Kurzes Update, täglich
* Planning: einschätzen der Entwicklungszeit (Planning Game/Poker)
* CI: innerhalb Tage/Wochen, vermeidet falsche Dev Ergebnisse durch fehlende Kommunikation
* Retro: Nach Sprint Ergebnisse reflektieren
* Shared Code Ownership: Code sollte von jedem bearbeitet werden dürfen

Tech PRactises
* TDD: Test -> Develop -> Refactor
* Refactoring
* Pair programming: nur in xp pflicht
* SSTCPW: minimalistische Lösungen "Simplest solution that can possibly work"
* Conding standards
### Artifacts
Virtual
* Use Case/User Story
* Burndown Chart

Material
* Story card
* Story board
* Open Room - offene Arbeitsräume
### Pros and COns
Not new and not goog
* User Stories als Ersatz für Anforderungen (gut zu Validierung aber nicht zu Definition)
New and not good
* Pair programming - effizienz
* minimaler Code - keine Wiederverwendbarkeit
* Upfront Reqs fehlen -> kann Problene machen

Not New but good
* kurze Iterationen
* Änderungsfokus

New and Good
* Team empowerement
* Viele Meetings um Interaktion zu forcen
* Keine Änderung während Sprint
* Testen hat wichtige Rolle

## Deconstructing agile texts
Schriftlich vs Mündlich
Mündlich nicht immer besser (präzision, doku, durchsuchbar)

Top 7 Rhetorical Traps
* Proof by anecdote
* Slander by association
* Assozationen um argument zu verstärken abzuschwächen
* Intimidation
* Einschüchterung durch negative Einstellung
* oft auch Schlafschafe argument
* Catastrophism
* Im Moment Katastrophe
* All or nothing
* Als Ausrede wenn was nicht klappt
* Cover your behind
* Radikale Ideen mit Warnungen die aber nur warnen aber nicht sagen wovor
* Auch ABsicherung
* Unverifiable claims
* Studien schwierig im Agilen
* "Scrum spart" etc.

## The Enemy: Big Upfront Anything
Software Engineering = Prädiktiv

**Req Engineering**: Beschreibt Probleme nicht Lösungen
Herausforderung: Anforderungen eines Problems finden - ansonsten teuer
Validierung vs Verfizierung
Richtige Software vs SOftware richtig

Req Techniken
* Interviews, Workshops...
* Req Dokument
* Anforderung
* Plänen

**Verschwendungskritik**
Dokumente oftmals zu groß und ohne direkte nutzen. Nicht ail: Alles vorab planen und priorisieren. Agil: Starten mit Anforderung und validieren

=> Mittelweg ist das Ziel

**Änderungskritik**
* Anforderungen und Meinungen werden sich immer ändern
* Kunde weiß oft nicht was er will
* Erstelltes Dokument soll dynamisch betrachtet werden

**Domäne und Maschine**
* Anforderungen an Domäne
* Eigentschaften eines Modells teil der Domäne
* Unabhängig von Projekt
* zb Regeln für Account Verwaltung
* ANforderungen an Maschine
* Eigenschaften des Systems für das Projekt
* wie wird eine Zahlung verarbeitet

**Architektur und Design**
Anforderungsanalyse = Beschreibung des Problems
Design = Teil der Lösung

Design Decisions zb.
* Patterns
* Vererung
* Spezifikation von Interfaces

**Trennung Design und Implementierung**
Trad: AUfgabe fürs Produzieren von Doku
Software Engineering: Prozess der Definition der Gesamtstruktur des Codes
- Design vor während unf nach Implementierung
- Program Design Language zur Codeerstellung

**Agile Methoden und Design**
* Iterative Prozesse statt Wasserfall
* Minimalistisch statt Wiederverwendbar
* Refactoring statt beste Lösung sofort

Challenges:
* Planung
* Aufteilung der Arbeit
* Projektteam will Gesamtarchitektur
* Refactoring ist unvermeidlich

**Lebenszyklus Modell**
ABfolge der Phasen ist zu definieren und standardisieren egal ob Agil oder nicht

ZWei verschiedene ROllen
* beschreibend : wie funktionieren Teams
* vorschreibend: wie sollte es sein

Wasserfall mehr aus historischen und pädagogischen Gründen immer noch Thema

**Rationaler einheitlicher Prozess**
RUP
ISt MIschung aus Wasserfallmodell mit paar Empfehlungen aus SED
* Iterativ
* Anforderungen verwalten
* Komponentenbasiert
* Visuelle Darstellung von Modellen
* Kontinuierliche QA
* Änderungskontrolle

4 Phasen
* Anfang (Anforderungen/ANalyse)
* Ausarbeitung (Design)
* Bau
* Übergang (Deployment)

RUP nicht beliebt in agilen weil immer noch zu sequentiell

**CMMI**
Stufenstruktur aus Sammlung von Best Pratices mit Fokus auf Konzepte und Praktiken

* Initial
* Managed
* Defined
* Quantitavely Managed
* Optimizing

gedacht für große ORgas.

**Personal Software Process**
Fördert Ingeneurwesen in Software
* PRotokolle
* Aufgewendete Zeit verfolgen
* Fehler dokumentieren
* Statistische QA

CMMI und Agilität oft als unvereinbar gesehe obwohl es keinen Widerspruch gibt
agile Praktiken auch in CMMI Kontext anwendbar, beide fordern starkes Engagement von Orgas

**Agile Maturity Scale**
Instrument zur Messung Reifegrad einer Orga in Bezug auf Agil

basieren oft auf SHu-Ha-Ri (Prozesse befolgen, variieren, meistern)

## Agile Prinzipien
### Was sind gute Prinzipien?
* Abstrakt principle vs practice
* Falsifiable - principle vs platitude
* Optional: prescriptive > descriptive

### Orga Principles
1. Put the customer at the center.
2. Let the team self-organize.
3. Work at a sustainable pace.
4. Develop minimal software:
4.1. Produce minimal functionality.
4.2. Produce only the product requested.
4.3. Develop only code and tests.
5. Accept change
5.1 Change akzeptieren aber nicht begrüßen. Change managen
### Technical Principles
6. Develop iteratively:
6.1. Produce frequent working iterations.
6.2. Freeze requirements during iterations.
7. Treat tests as a key resource:
7.1. Do not start any new development until all tests pass.
7.2. Test first.
8. Express requirements through scenarios
8.1 Szenarien fählt es an Abstraktion -> daher Reqs needed
8.2 USe Case = Kompletter Durchlauf
8.3 USer Story = Beschreibt Unit of Interaction
# Block 6 Referate
## Goldis, Leo, Mehmet Agile Roles & Practices: Managerial

### Roles
Manager
sollte nicht
* nicht aufgaben aufteilen
* entscheiden was impleementiert wird
* direkt steuern Mitglieder
sollte
* Umgebung schaffen
* Ressourcen verwalten
* interaktion sicherstellen

Product Owner
* entscheidet über Produkt
* wählt User story aus
* teil des kunden

Team
* Selbstorganisierend
* entscheidet selbstständig
* cross-functional
* teams mit fähigkeiten für unabhängige Lieferung
* ermöglicht höhere Flexibilität

Members & Observers
Pigs and Chicken
Pigs -> kritisch, sind im Mittelpunkt, treffen Entscheidung
Chicken -> Beobachter, äußern Meinung

Kunden
* stehen im Mittelpunkt
* können auch Projektmitglieder sein
* Product Owner repräsentiert Kunden

Coach, Scrum Master
* Zuständig um agile Methoden durchzusetzen
* Coach -> beratend, Scrum Mester -> managed
* Scrum Master als Programmierer schwieriger als Coach
* Scrum Muster beseitigt Hindernisse

Separating Roles
Scrum besteht aus Scrum Master, Team und Product Owner
Manager als Projektleiter schwierig projekt vs geschäftliche Ziele -> daher externer Product Owner

### Praktiken
= Tätigkeit oder Arbeitsweise die sich wiederholt wird und geregelt ist

Sprint
* iterativ ist Grundprinzip
* Aufgaben (user storys im Backlog)
* Sollte ca. 1 monat dauern
* Aufgabenliste eines Sprints sollte währenddessen nicht erweitert werden
* wichtige arbeiten verzögert
* projekt ausgliedern
* Sprint kann aber vorzeitig beendet werden wenn eine Funktion ein Show-Stopper ist und implementiert werden muss

Daily Meetings
* zentrale agile Praktik
* 15min
* manchmal mehr Aufwand
* remote (Zeitzonen, technische Probleme)
* Fokus auf drei fragen?
* Was habe ich gemacht
* Was werde ich machen
* Was gibt es für Hindernisse
* org
* technisch
* Kein Fokus auf
* technische Diskussionen
* kokrete Lösungen?

Planning Game
= Praktik um Kosten von Funktionen zu schätzen
* Einheit: Personentage..
* 2 müssen sich einigen
* kommt von XP

Planning Poker
* Gruppe entscheidet
* Einheiten: T-Shirt, Fibernaci
* Entwickler, Kundenvertreter, Product Owner
* Vorstellung, Diskussion, Abstimmung (geheim), Diskussion
* bei keiner Einigung Prozess wird abgebrochen und weitere Vorgehensweise besprochen
* Problem: Experte gibt durch Druck vielleicht nach

Onsite Customer
= Kunden + Vertreter wird aktiv eingeschlossen

Open Space
* Agile Methoden betonen die physische Org,
* keine geschlossenen Büros
* Optimal
* Großraumbüro
* Whiteboards für Diskussion
* Ruhiger Besprechungsraum
* Offene Kommunikation soll gefördert werden
* -> Individuelle Bedürfnisse müssen aber beachtet werdden, verschiedene Lösung für verschiedenen Menschen

Process Miniature
= Eine Entwicklungsmethode soll durch anwendung auf nicht Softwarebezogene Aufgaben erlebbar werden
* abstrakte Techniken sollen visualisiert werden
* Dynamik der Gruppeninteraktion in einem selbstorganisierenden Team zu verstehen
* Trotzdem beachten dass Visualisierungen nicht immer übereinstimmen müssen

Iteration Planning
* 3 Ziele
* Beschreibung des Ziels der Iteration
* Backlog in Sprint
* Auswahl von User-Stories
* Aufsplitten
* AKs definieren
* Aufwandschötzung durch Team mit Planning Poker/Game
* Product Owner und Team vor allem Teilnehmer -> möglichst ohne Kunden
* Zeit: 1 Tag -> kann aufgesplittet werden

Review Meeting
= Ergebnisse betrachten, was wurde erreicht
* wie viel wurde geschafft
* Reflektion für nächsten Sprint
* Prozess wird nicht betrachtet

Retro
* was ist gut/schlecht gelaufen - Prozess wird betrachtet
* Verbesserungspotential identifizieren

Scrum of Scrums
* Agile Methiden für große Projekte
* Lösung für mehrstufige Projekte
* Tägliche Treffen mit einem pro Team (2-3mal die woche
* )
* Koordinatioon ist eine Herausforderung

Collective Code Ownership
* jeder im Team darf Code anzupassen
* Abhängigkeiten auflösen
* Schlüsselwort Zusammenarbeit und kontinuierliche Verbesserungen
* Muss man abwägen
* wann macht es sinn=
* Barrieren für Änderungen
* balkanisierung des systems
* Änderungskontrolle wichtig -> kein Code soll verschwinden

## Agile Practices Technical
Agile Prinzipien haben einen großen Einfluss. Von Programmierern für Programmierern

### Daily Build and CI

Integration
* combine software componants
* compile together
* run regression tests

Avoid big bang
* through code versioning
* short integration cycles

Daily Builds (Microsoft)
* Integrate at end of day
* If integration is broken -> fix it

XP recommends CI
* integration and testing in several hours
* focus on maintaining quality
* find a right frequency about keeping quality -> also okay to integrate less often

Change from Bigbang to CI changed teams working together

### Pair Programming

Also one cornerstone of XP
Today other agile practices aare considered more important. Has benefits and drawbacks

= 2 persons work together, one inputs while expresses his thoughts, other person corrects, roles should be reversed

Misconception that two programmers will halve the output

Benefits
* hold each other accountable
* koppeing one another on task
* brainstorming on ideas
* take initiave when other is stuck

Often used wrongly as mantoring (one experienced, one junior)
* senior woll not get help with difficult tasks
* will only explain easy parts -> less time
* junior will slow down

Mob Programming
Why only 2 people?
No more separation of roles, Team thinks and programs as if it were a single person

Could be too much people, hard to achieve code quality

Pair Programming useful for difficult/critical parts of an assignment, forcing people will fail
Side-by-Side: own project but close to each other

### Coding Standards
Benefits are related to collaboration and communication
Controversial when introduced: creativity and individuality gone

Refactoring:
= Continoues search of code smells. EG. Duplication of Code
Functionality/Semantics must be the same and refactored code must be higher quality
There are now tools for
Code Quality -> not defined but criteria for code smells

Still no replacement for Upfront Design
* but there is no perfect design -> refactoring useful

Big Refactoring can be done in small steps -> often not true
Starting from MVP and implement more -> might not yield good software

Incidential vs Essential imperfections
incidental can be refactored essention not

### TTD and TFD

TTD = is not a testing technique but an dev method

TFD = a subset of TDD where are tests are written before corresponding program elements

TFD: Just add test and change (not running, fail success, refactor)

TDD
* test driven: write first test
* extremely incremental: one test at a time that covers functionality
* refactoring
* rules of testing: all tests must succeed. Regression suite grows provideing progressively larger guarantee of quality if all succeed

Criticism: Tests are not enough to specify programs
Challenges: often not folloewed stricly
Contribution: Assosiaction of Code and Tests was brought up through TDD
Future Adoption: Integrated Tests with new code has gained acceptance

## Agile Artifacts (Turgut)
Definition
artifacts are tangible or intangable items

### USer Stories
describe funtionality

### Agile Modeling
provide insights into system structure and behaviour

### Agile Docu
flexible and simple docu that captures essention information

### Agile Prototypes
interactive mockups, or early versions to get feedback

### Release Plans
provide overview of features in next release

### Burn-Down Charts
viseal represantation of work and time

### Task boars
wisualize worklfow and progress of tasks

### Retro artefacts
capture learnings, insights of retro

### DOD
What it means for a task or user story to be complete

### Test artifacts
test cases, scripts

Benefits:
* collaboration
* fac communi
* support itera dev
* aid in visualization

## Agile Methoden yining shabbir elna

### Lean Software & Kanban
Lean Software
Hauptziel: Reduzierung der Verschwendung in SW Projekt. Verschwendung alles was nicht an den Kunden geht

Prinipien:
* Beseitigung der Verschwendung
* weniger detailierte Dokumente
* teile der arbeiten die nicht in produktion gehen
* bugs
* unnötige prozesse (lange wartezeiten)
* Verstärken des Lernens
* Entscheiden so spät wie möglich
* Lieferung so schnell wie möglich
* Team ermächtigen eigene Entscheidungen zu treffen
* Integrität aufbauen
* Systemdesugn konsistent halten
* Gesamtbild betrachten nicht im Detail verlieren

Kanban
= Produktionsmethode aus Toyota
Hauptziel: auf Work in Progress fokussieren
Kanban Board
enthält Kanban Karten (USer Stories, Bugs) in Spalten gegliedert

Stärken
* Minimierung von verschwendung
* Fördern des lernens

Schwächen
* Ursprung aus physicher Umgebung nicht geistig wie Software
* Gibt Unvorhersebarkeiten in SW
* So spät wie möglich entscheiden kann auch negativ sein
* Schwierigkeiten mit just in time Techniken

Methoden sollten gemainsam verwendet werde mit anderen, sind aber effiziente Methoden

### XP
= ursprüngliche agile Methode, heute aber weniger genutzt aber konstruktiven Prinzipien werden noch verwendet

If P is good we apply it all the way

Konzept
Inkrementieren und dann vereinfachen
Basic cycle wie TDD:
* Test functi
* Add funct
* Refactor

Vorgang wiederholt bis Team und Benutzer zufrieden sind.

Grundelegende Techniken
1. Short iterations 1-2 wochen
2. pair programming
3. user stories (Funktionalität wird dadurch beschrieben)
4. refactoring
5. Open workspace
6. Collective Code ownership
7. CI
8. TFD or TDD

Meinung von Autor
Extrem = vollen Umfang verwenden, ist Markenzeichen, ist die größte Stärke
kaum einen Raum für Komprommise -> sehr streng
Testen wichtig und ständige Integration sind contribution von XP
### Scrum and Crystal
Scrum
= eher eine organisatorische Technik, hat XP überholt
Close Window RUle = Anforderugnen für Iteration eingefroren.
Ausnahmen nur ohne die momentante Iteration zu stören

Key Scrum Practices
* Sprintplanung am Anfang
* Closed window rule
* USer stories als Definition für die Arbeit
* Daily Scrum
* DOD
* Aufgabentafel und borndown Diagramm um Geschwindigkeiten zu bewerten

Meinung des Autors
* Scrum Idee zur präzisen Standard
* Gute Marketingstrategie
* Begrenzung in der Anwendunf der Methode - wenig Raum für Nuancen
* Braucht eine bessere ausgewogenere Gestaltung
* wirkt vor allem organisatiorusch und nicht auf entwickelt

**Crystal**
* Betonung auf interaktion
* Osmotische Kommunikation
* Fragen und Antworten verlaufen natürlich und mit wenig Störung
* Starke Betonung auf offenes Klima
* Prjekte können aufgrunf schlechter Komm. zu verspäteten Reaktionen kommen -> hohe kosten soll durch crystal verhindert werden

Varianten
* Crystal Clear: 6 people, small projekte
* Yesllow:
* ORange
* Red
* Maroon
* Diamonf

Prinzipien
1. Regelmäßige Lieferung
2. Regelmäßigw Verbesserung
3. Osmotische Kommunikation
4. Persönliche Sicherheit
5. Fokus
6. Früher Zugang zu Experten
7. Technische Umgebung mit automatisierten Tests, Konfigmanagement und frequente Integration

Meinung des Autors
* Keine umfassende Methode
* Konzentration auf weisheiten
* Verweigerung von Rechthaberei und Akzeptanz von klassischen Methoden
* Vorsorge der Methode angepasst
* Unrealistisch aufgrunf Größe und Bedeutung die Methode zu bestimmen
* Crystal könnte SCRUM ersetzen -> Nope

## Dealing with agile teams + the ugly, the hype and the good Ebu, Eren, Lisa

Einwände
* Agile ist nicht geignett für regulierte Umgebungen
* Agile bedeutet dass wir nicht wissen was geliefert wird
* Agile skaliert nicht

-> Wird belegt

Nominale Kosten vs Zeit
Kosten können nur durch mehr ZEit kompensiert werden

Für Kunden passt was oder wann nciht -> aber geht nicht anders
Agile Autoren empfehlen Kunden zu belehren
Beides versprechen ist nicht sinnvoll -> lieber in Zwischenschritte aufteilen

The Ugly, Hype and Good, Brilliant

Ugly
* User Stories als Basis für Anforderungen
* Anforderungen sollten nicht ersetzt werden
* Feature basierte Entwicklung
* schwierig mit Abhängigkeiten
* Generalisierung wird zu Beginn vermieden
* Test-driven Development schlechter als TFD
* Vermeidung der Analyse und Anforderungsphase
* Ablehnung von Dokus
* Ablehnung von Dependency Tracking charts
* Agile Rollen
* Embeded Customer
* Coach als separate Rolle (überbewertet)
* Ablehnung von Aufgbaen eines trad. Manager

Hyped
* Pair Programming
* Großraumbüros
* Nachhaltige Arbeits"geschwindigkeit"
* Gemeinsame Code Ownership
* Minimale Funktionalität
* Planning game/poker
* Selbstorganisierte Teams
* Teammitglieder und Beobachter
* Funktionsübergreifende Teams

Good
* Refactoring
* Müll aufdacken und entfernen
* Kommunikation im Team
* Kurze daily

Brilliant
* CI und Regressionstests
* Fokus auf Auslieferung funktionierender Software
* Jede Funktionalität muss mit einem Test assoziiert sein
* Kurze iterationen
* closed window
* time boxing
* product owner
* fortschrittsübersicht

# Pflichtlektüre
## Qualitätsmanagement Einführung
### Einleitung
**Perceived Quality**
Qualität an Produkt oder Leistungeigenschaften zu messen -> intuitiv aber lediglich sinvoll für Skalen.
Tatsächlich Qualität = Versprechen funktionale oder emotionalle Bedürfnisse zu befriedigen, die durch Marke aufgebaut werden.

Qualität drückt sich somit in der umfassenden Zufriedenheit der Kunden aus.
Mangelnde Beschaffenheit wird gemeldet, mangelnde Qualität wird weitererzählt. In heutiger Zeit geht das schnell (Internet).

Zehnerregel: Je später Fehler gefunden wird in Bezug auf Entstehung steigt um Faktor 10

Fehlermeldung vs Fehlerveidung (präventiv vs reaktiv)
* beides Maßnahemn gegen Fehler
* Zusammenspiel wichtig

**Produkt und Prozessqualität**
Präventive Maßnahmen nur sinvoll wenn nicht als Kontrollinstrument sondern Charakter der Infoerhebung, aufbereitung, verteilung verstanden.
Ermöglichen Eingriff in den Produktionsprozess bei Q.abweichungen.

Statistikbasierte Methoden: vergleichen IST mit SOlL Zustand der Prozessplanung und leiten Maßnahmen ab. Größter Einfluss der Qualität -> Anfang der Entstehung bei Einbeziehung der Kunden

Produktqualität nur kleiner Teil des Spektrums. Vermeidung von Fehlleistungen. Wertschöpfungssysteme in EInklang mit Wertesystem der Gesellschaft.

Ziel jedes Unternehmen -> Gewinnmaximierung (p*Kv)*n - KF
PReis und ANzahl => Kundenwünsche, K => Geschäftsprozesse.
Unternehmen muss beides beachten um Qansprüche zu erfüllen.

Kosten - Zeit - Qualität Dreieck -> nicht unbedingt wahr weil wenn Qualität als unternehmerische Leitgröße gesehen wird dann kann es andere Bereiche senken -> Hebel

**Unternehmerisches Qualitätsmanagement**
Qualität = Kernalement dass durch Technologiemanagement und Innomanagement ergänzt wird

Oft noch nur Qualitätssicherung und nicht anderen 3 Phasen beachtet teils wegen Unkenntnis der Methoden.

**Paradigmenwechsel un Qualitätsverständnis**
Letzten JAhren krisenhafte Zuspitzungen auch wegen Kosten, Qualität, Innovation, Management Krisen.
Auto Beispiel:
USA -> Autos für Masse (Preis/Leistung)
GER -> Technik (Innovation)
Grenze erreicht als Produkte nicht mehr gewünschte Höhe an Faktoren erreicht haben.

Dagegen JAP: Prinzipien mit Fokus auf Prodprozesse, Verschwendung vermeidend, Wertschöpfung erhöhend + alle Miarbeiter eingebunden in ständiger Verbesserung

Mit änderenden Qualitätsbegriff auch Änderung im Q.MAnagement: keine isolierten Tätigkeiten. Durchdringung auf allen Ebenen.

**Wertschöpfungsintegration des QM**
Qualitätsmanagement wird zunehmen in Wertschöpfungskette integriert.

**Aktivitäten im modernen QM**
Weites Spektrum wie Risiko, Sicherheiten, Ressourcen, UMwelt, Product VAlue

Qualtitäsbegriff in 3 Formen:
- Produktqualität: Umsetzung der Anforderungen
- Prozessq: GÜte mit der alle betrieblichen Prozesse auf Ziele ausgelegt sind
- Systemq: Gestaltung der Strukturen zu Definition und Erreichung der Ziele
Daher nicht mehr nur Produktqualität im Modernen

Entscheidungen werden durch Stakeholder beeinflusst.

### Entwicklung vom QM
Unterscheidung zwischen philosophischer Qualität (Beschaffenheit) und pragmatischer (Abgleich mit Erwartungen)

In philosophischer -> objektive und sunbjektive Qualitäten

Später Technische vs Geschmackliche Qualitöt (Zweck vs Gestaltung)

## Software Testing
Zwei verschiedene Ziele
* Fehler finden
* Komponenten/Defect Tests
* Akzeptanz gegenüber Anforderungen
* Akzeptanztests/Systemtests/Validation Test

Testen kann nicht die Abwesenheit von Fehlern zeigen. Testen teil von Verifikation und Validierung

- Valididerung: Bauen wir das richtige PRodukt? (Anforderungen verstanden)
- entspricht Kundenerwartungen
- Verifizierung: Bauen wir das Produkt richtig? (Anforderungen erfüllt)
- entsprichts funktionallen und nicht funktionallen ANforderngewn

Das erforderliche Maß an Vertrauen hängt ab von dem dem Zweck des Systems, den Erwartungen der Systemnutzer und dem aktuellen Marktumfeld Umfeld für das System ab.

statische V & V Prozesse: Software wird nicht ausgeführt. Beispiel Inspektion & Review
Fehler treten in Gruppen auf und können andere maskieren. WÄhrend Inspektion können mehrere Fehler gefunden werden.

Inspektionen können kein Software Testing ersetzwn.
Traditionelles Testen beinhaltet Plan-Driven Development. Jemand der sich auskennt schreibt Testcases für Input und Output. Nur Testausführung kann automatisiert werden nicht Testplanung

3 Stages of testing
- Dev: Testing during development, developers are responsible
- Release Testing: Testing with complete version -> requirements are tested, separate team
- User Testing: Acceptance Testing can be part of, customers or users

In practice automated and manual tests are used

### Development Testing
All test activities that can be done by devteam.

3 types of granularity
- Unit (objects or methods)
- Component (component interfaces)
- System (component interactions)

Goal: Discover Bugs

**Unit Testing**
Test all attributes, methods, states of objects.
Vererbung macht Testen komplizierter -> vererbte Methoden Verhalten sich vielleicht anders.

Automatisiere Unit Tests wenn möglich.
- Setup: Inputs Outputs definiert
- Call: Method or Object aufgerufen
- Assertion: COmparison

Mock: Simuliert Verhalten von anderen Softwareteilen. Zb. DB

**Wählen von Unit Tests**
Effective Unit Tests sind
- welche die zeigen das Komponente funktioniert
- Fehler in Komponente aufzeigen

Daher verschiedene Testfälle:
Zeigen wie Komponente funktioniert vs. Testfälle die potentiell Probleme machen -> Erfahrung

Testwahlstrategien
- Partition: Testgruppen mit ähnlichen Verhalten, Randgruppen beachten
- Guideline based

Klassisches Equivalence classes Testing -> Black-box
KAnn mit White-box ergänzt werden um Testklassen zu finden

Guidelines nützlich um Erfahrungen zu erhalten wie man mit welchen Dingen testet.Guideline-Testing inkludiert zb. für testen mit Sequenzen.
- Single Sequence Testing
- Sequences of different sizes in different tess
- Boundaries of sequences

Gibt Whittakers Guidelines

**Component testing**
Komponenten werden oft zusammengefügt. Testet wie sich das Interface verhält. Testcases inkludieren die Komponenten die zusammengefügt wurden.

Arten von Interfaces:
* Parameter interfaces
* Data or function references are passed (Used by methods in objects)
* Shared memory Intefaces
* Data is placed and retrieved from separate components
* Procedural interfaces
* Message passing interfaces

Interface errors
* Interface misuse
* Interface misunderstanding
* wrong assumptions about behavior are made
* timing errors

Testing interfaces ist schwierig weil manchmal Fehler erst in späterer Folge auftreten oder nur in ABhängigkeit zu anderen verhalten.

Generelle Guidelines
* Teste jeden externen call
* bei pointer passing -> test null pointer parameters
* design procedural tests to fail
* stress tests in message interfaces
* When serveral components share memory, vary the order

Sometimes static tests can be more cost effective than dynamic for component tests.

**System Testing**
Testet die Interaltion der Komponenten. Ünterschied zu Komponententests
* Reused und neue Komponenten werden gemeinsam getests
* Komponenten von verschiedenen Teams werden hier zusammengefügt

Weil es so auf Interaktion besteht eignen sich USe case based testing. Meistens sind use-cases über mehrere Komponenten implementiert. Sequenzdiagramm kann helfen Test Cases zu spezifizieren, da es zeigt welche Inputs welche Outputs kreieren.

Wann aufhören bei System Tests - Exhaustive Tests sind unmöglich
Daher sollen Policys bestehen die bestmmen was zu testen ist.
Automatisiertes Systemtesting ist schwieriger als andere. Da entgegen dem Unit Testing hier Input und Output nicht so leicht predicted werden können.
### Test-driven development
Tests udnd Code werden inkremmentel geschrieben. Erst wenn COde Test besteht wird nächster Part geschrieben bzw. Refactor.

Sind in separierten Programm embeded um Laufen zu können. TDD hilft Developern zu verstehen was Code bezwecken soll. Aber wenn zu wenig Erfahrung für Tests da ist wird auch Code failen. -> hilft TDD nicht
Ander Benefits
* Code Coverage
* Regression testing
* Simplified Debugging
* System documentation

Regression Tests größter Faktor des TDD da normalerweise aufwändig. TDD ist immer automatisiert -> daher billigere Regressuintests.

Ersetzt aber nicht System Tests zur Validierung der Reqs und Performance, Reliability tests.
### Release Testing
Ist der Prozess einen bestimmten Release zu testen. ISt normalerweise für Kunden und Nutzer:innen. Kann aber auch für andere dev teams sein.
Unterschiede zu System Testing

* Separates Team testet
* Release testing ist validation testing kein defect testing

Validiert das System gegenüber allen Requirements nicht nur von USern. Ist Black-Box Testing (Functional Testing)

#### Requirements based testing
Reqs sollten testbar sein. ISt ein systematischer Test wo aus Reqs Test Cases designed werden. Meistens entstehen mehrere Tests aus einem Req.

#### Scenario Testing
Typische Szenarien werden verwendet um Test Cases daraus zu erstellen. Diese sollten realistisch und nachvollziehbar für USer sein. Szenarien aus dem Req Testing können wieder verwendet werden. Sollte eine erzählte Geschichte und leicht zu validieren sein um Komplexität raus zu nehmen.

Mit dieser Methode werden meistens mehrere Reqs auf einmal getestet. Dadurch wird auch getestet dass die Kombi dieser keine Probleme macht.

#### Performance testing

Sind da um zu testen ob sie mit dem Load umgehen können. Das wird meistens gemacht in dem solange Load hinzugefügt wird bis das System nicht mehr akzeptabel performt. Es ist sowohl Defect als auch Validation Testing.

Es kann ein OP Profile geben entgegen dessen getestet werden muss. Sagt aus welche Aktionen wie oft verwendet werden.

Für Defect Testing ist Stress Test besser. Load wird immer erhöht bis System failt
* Überprüft Fehlverhalten wenn System ist unter Stress
* Überprüft ob Fehler auftreten die sonst nicht auftreten würden.

Vor allem bei distributed systems wichtig.
### User Testing
In diesem Prozess liefern User und Kunden Inputs in den Testprozess. ISt wichtig selbst wenn Release Testing erfolgreich war. Devs können ware Systemumgebung nicht in Tests miteinbeziehen (Krankenhaus)

3 Typen
* Alpha testing - users testen an devs seite
* Andere Faktoren als Reqs werden miteinbezogen
* User bekommen früher access zu Produkt
* Beta testing - release ist für user verfügbar zu testen
* Können eine selektiert Gruppe sein oder für jeden verwendbar sein
* vor allem verwendet für Software die in verschiedenen Umgebungen verwendet wird
* auch eine Form von Marketing
* Acceptance testing - Kunden testen System um zu entscheiden ob System ready ist
* Acceptance impliziert Bezahlung
* passiert nach Release Testing
* Stages
* Acceptance Criteria definieren (bevor Verrag unteschrieben wird)
* Acceptance Testing planen
* Accentance Test ableiten sollte alles covern
* Acceptance tests durchführen - am besten in echten environment
* Test Ergebnisse verhandeln
* Reject/accept system
* In XP acceptance tests User ist Teil des devs und gibt User Stories bzw. Tests vor. Tests sind automatisiert
* User müssen repräsentiv sein
* Akzeptanz keine boolean entscheidung - oft akzeptiert aber doch einigung auf bug fixes

## Quality Management
Probleme mit Qualität schon in 1960er und durch 20.Jh. Führte zu formalen Techniken des QM die sich aus Manufactoring abgeleitet haben. Kombiniert mir neuer Technologie und besseres Testing haben die Qualität verbessert

3 concerns of QM
* Orga Level: Finden von org. Prozessen und Frameworks um Software Qualität zu steigern. QM team soll Verantwortung für Prozesse und Standards übernehmen
* Project Level: Anwendung verschiedener Qualitätsprozesse und Konfirmation das Output den Standards entspricht dass auf das Projekt angewendet wird
* Ebenfalls PRoject Level: Quality Plan für das Projekt. SOllte Qualitätsziele und gewählte PRozesse sowie Standards beinhalten

QA = Prozesse und Standards die zu höhere Qualität führen sollen
Quality Control = Anwendung dieser Standards und Prozesse

QA wird oft durchmischt. Er bezieht auch Verifikation und Validierung dass Prozesse angewendet wurden mitein. QC geht dadurch verloren - nicht viel verwendet in Software Industry
QA Teams machen auch Release Testing, sollte unabhängig von Devs sein und eher orga Rolle, damit sie unabhängig von PRojektleiter sind (Budget). QM Teams checks das Outputs des Projekts mit orga Standards übereinstimment.
Quality Planning = Prozess des Planens der Qualität für Projekt. Sollte die Qualitäten und wie diese zu erreichen sind beschreiben. Ohne diese Definition is es schwierig. Ist ein Teil von Plan-based Software.
Im Agilen ist es ein wenig weniger formal.

Qualität Plan Struktur
* Product intro
* Product plans (Release, Verantwortungen)
* Process description
* Quality goals
* Risks and risk management

Sollten so kurz wie möglich sein.
FÜür QM reichen Standards und PRocesse nicht aus sondern es sollte auch eine gewisse Kultur herrschen, die Qualität im Projekt von jedem einzelnen verantwortbar macht.

Je größer das Projekt umso formaler sollte QM im Projekt geführt und dokumentiert werden. Für kleinere Projekte ist die Kultur wichtigere
### Software quality
Software: Reqs sind immer ein Kompromiss zwischen Stakeholdern, Interpretation immer verschieben und Softwaregrößen schwierig messbar (Wartbarkeit)

Daher ist Software Quality subjektiv. QM muss wissen ob Software den für ihn vorgesehenen Zweck erfüllt.

Generell sollte Software gegen Reqs getestet werden und auf grund dessen eine Entscheidung getroggen werden.
Non functional reqs meist subjektiv. Software Quality muss die auch miteinbeziehen. Man kann nicht alle Werte optimieren daher braucht es einen Quality Plan.

In SD ist die Beziehung zwischen Prozess und Produktq mehr komplex als im traditionnellen Engineering. In Software wird designed und nicht manufaktiert und das kann beeinflussen das bei Standardisierung das eher zu schlechterer SOftware führt aber generell kann man schon sagen dass bessere Prozess zu besserer Software führt.

### Software standards
QA beschließt standards die im Prozess angewendet qwerden sollen + unterstützende Tools. Wenn sie beschlossen wurden müssen Monitorprozesse für diese beschlossen werden.

Standards wichtig weil
* Beinhalten Weisheiten der Org
* Liefern Framework um Quality für Projekt zu definieren, weil subjektiv
* Helfen bei Kontinuität der Arbeit

Product Standards
* eg. Document standards, object class def, coding standards

Proccess Standards
* eg. def. of SPezifikationen, Design...

Standards müssen kosten und zeiteffektiv sein. Product standards müssen anwendbar sein und process standards müssen eine definition der prozesse beinhalten die die product standards überwachen.

QM standards sollten an internationalen und nationalen Standards orientiert sein. QA sollte ein handbook definen wo alle benötigten Standards + Beispiele drin sind.

Se offen sind faul zu dokumentieren obwohl sie Standards sinnvoll finden. Daher sollten QAs das machen:
* SE in Auswahl miteinbeziehen
* Reviewen und Reflektioeren
* SOftware Tools zur Unterstützung anbieten

Für jedes Projekt sind andere Standards wichtig und müssen auf das Team abgestimmt sein

#### ISO 9001
Internationales Standardset ISO 9000. ISO 9001 nicht nur fpr software development aber für entwickeln von SOftware standards.
Es beschreibt Qualitätsprozesse, Qualitätsprinzipien und bestimmt Org. Standards und Prozeduren. 9 Core Processes

Product Delivery Processes
* Business Acquisition
* Design and Development
* Test
* Production and Delivery
* Service and Support

Supportinh Proc
* Business Management
* Supplier MAnagement Inventory Management
* Configuration MAnagement

Um den ISO 9001 zu entsprechen müssen die Prozesse den Core Prozessen angelehnt sein und das ganze muss dokumentiert werden. Aber der Standard beschreibt nicht welche spezifischen Prozesse befolgt werden müssen. Das erlaubt Flexibilität aber macht es schwierig zu vergleichen. Auch Doku kann an Formalität abweichen.


Man kann zertifiziert werden wenn das Quality Manuel wo die Prozesse defined sind konform ist. Zertifizierung sagt nur dass sie eine QM verfolgen nicht das Software zwingend besser ist. Agile Dev Teams seltener zertifiziert wegen Doku Overhead

### Reviews and inspections

Sind QA Aktivitäten um Qualität zu checken. Werden neben Testing als Verifikation und Validation von SOftware verwendet

**Review**
Gruppe schaut sich Software und Doku an. Schaut nach Problemen und non-Konformität mit Standards. Quality Reviews schauen Dokus an die während SED entstanden sind. Checken Quality Standards und Vollstäändigkeit. Außerdem finden sie Probleme. Conclusion sollte aufgezeichnet werden.

Ziel = Qualität zu steigern nicht Personen bewerten.
Review ist öffentlicher Process der Fehlerfindung, wo eine angenehme Kultur herrschen muss.

#### Review Prozess
3 Phasen
Review sollte geleitet sein und max. 2 Stunden, 3-4 Leute. Mind. 1 Senior. Manchmal Experten für bestimmte Bereiche eingeladen. Projekt Manager muss nicht dabei sein. Alle dev team Mitglieder sollten anwesend sein. Im Agilen ist es informell. In Scrum gibt es ein Sprint Review nach jedem Sprint aber sie sind nicht von Standards getrueben was Probleme haben kann in Firmen die starke QM prozesse haben. Daher besser in einem Plan drive dev process.

#### Program Inspektions
= Peer Reviews um bugs zu finden
Braucht Mitglieder mit verschiedenen Background die SOurce-Code durchgehen. Probleme und Anomalien werden gekennzeichnet. Können Checklisten verwendet werden, die gewartet werden sollen.

Trotzdem wird sich oft gewehrt von Dev und Manager Seite weil es extra GEld kostet. Agile Prozess verwenden es kaum, aber team member sollen code reviewen for check in bzw. PAir Programming als ALternative. Führt zur großem Verstädnis wodurch mehr Bugs gefunden werden können, kann aber auch zu Missverstehen von Reqs führen wenn beide gleich denken. Außerdem wenn Sorge PRojekt zu verlangsamen dann auch nicht hilfreich
### Software measurement and metrics
Software MEssungen will numerische Werte für Systeme Komponenten und Prozesse finden, um diese vergleichen zu können und daraus Schlüsse zu ziehen. Long time Goal: Verwenden um Urteil über Software QUalität statt reviews zu treffen.

Eine Metric ist eine Charakteristik von einem System oder PRozess dass objektiv gemessen werden lann. Bsp. LOC
Gibt Control und Predictor Metrics je nach dem um Characteristiken vorrauszusagen oder Prozess Management zu untersützen.

Control Prozesse: Average Time to repair defect
Predictor: cyclomatic complexity

Beide beeinflussen die Entscheidungsfindung. Control Metrics um zu schauen ob Prozesse geändert werden müssen und Predictor um AUfwand an Software Changes abzuschätzen.

2 Arten der Verwendung von Software MEssungen
* Wert an Software Qualität Attribut zuweisen
* Komponenten mit unzureichender Qualität identifizieren

Viele Quality attributes sind aber schwer messbar bsp understandability, usability weil sie an Empfindungen geknüpft sind (subjektiv)
Um diese beweren zu können müssen interne Attribute gemessen werden and angenommen werden dass diese zu den externen in eienr Beziehung stehen.
Dabei müssen 3 Dinge gelten
* Interne Attribute müssen gescheit gemessen werden
* Beziehung muss besehen
* Beziehung muss verstanden und in Formel oder Modell ausgedrückt sein

Oftmals werden zu Messungen auch tools verwendet. Es ist schwierig zu wissen ob sich Messungen systematisch dazu eigne Software zu vergleichen oder den Impact von Änderungen zu messen. Gründe
* ROI kann nicht auf org metrics Programm zurückgeführt werden
* Keine Standards für MEtriken
* Oftmals auch keine Standard Software PRozesse was es schwierig macht Measurements zu validieren, wegen hoher VAriablität
* Viel Research fokussiert sich auf Code based Metrics und Plan driven dev. Wenig info über cots und agilem.
* Messungen führen im Agilen zu Overhead der nicht gewollt ist.

Aber Messungen und Metriken sind empirisch. Selbst wenn objektiuve Entscheidungsbasis möglich wäre werden ENtscheidungen trotzdem oft subjektiv getroffen.

#### Product metrics
Sind Predictor MEtrics um interne Attribute von Software tu messen. (LOC, Size...) Aber wie besprochen einfach messbare Werte oft keine eindeutige Relation zu Quality attributes.

2 Klassen
* Dynamic: Messungen während Ausführung (zeitanalyse)
* Static: Ohne Ausführung (Size)

Klassen sind related zu Quality attributes
* Dynamic: Efficieency, Reliability
* Static: Complexity, Understandability, Maintainability

Verschiedenen Metriken

#### Software Component analysis
Jedes Komponent kann anhand von Metriken analysiert werden. Und so können Komponenten vergliche werden.
Beispiele:
Key Stages von Komponenten Messungen
1. Messung wählen
2. Komponente wählen
3. Messung der Charakteristiken
4. ANomalien Identifizieren
5. Anomalien analysieren

Daten sollten immer aufgehoben werden um sie für Vergleiche heraziehen zu können und Beziehungen zwischen internen und externen Komponenten Attributen herstellen zu können.

#### Mehrdeutigkeit bei Messungen
Kontext der Daten immer miteinbeziehen. Daten können leicht misinterpretiert werden. Gründe warum diese Werte entstehen müssen ergründet werden um Werte deuten und nutzen zu können.