---
# System prepended metadata

title: ASQ

---

# ASQ
- different views of Quality 01-18
- Quality Management: Aktivitäten, die Qualitätspolitik, Ziele und Verantwortlichkeiten enthalten 01-21f
- Quality Assurance (Qualitätssicherung): 01-23 f
- Software quality assurance (SQA) is not testing.

### Software: Unterschied zu z.B. Maschinenbau
- Abstract: Es ist für Entwickler schwierig, dynamische Systemaktionen, -reaktionen und -daten zu visualisieren
- avg Error rate ist bei web am größten 01-28
- Fehler Erkennung mit Preis 01-29f (Früheres fehlerfinden ist billiger und führt zu weniger Folgefehlern)
- Einfluss von Fehlern 01-31

# 2. Requirements
- Ermitteln / validieren / verhandeln von Projektziele und -anforderungen so effizient wie möglich
- Ideal zwischen Risikominderung (zu wenig) und Kostenexplosion (zu viel)
- **Stakeholders** 02-10

### KAOS
02-50
KAOS = Knowledge Acquisition in autOmated Specification
or Keep All Objects Satisfied.
- Ziel: Zielorientiert

- gutes Req: 02-56

# 3. Model Based Testing
- Nutzung von Modellen zum testen 
- Generierung von Testfällen aus Modell (UML)
- schon Testerstellung teilautomatisiert

# 4. Dynamic Testing
- Finden von Fehlern und gewinnen von Vertrauen in Programm
- nicht um Fehlerfreiheit zu zeigen sondern Vertrauen
- Black vs Whitebox 04-10
### Test Driven Development
04-26
- automated Tets vor Code 
- Test bestehen -> Korrektes Verhalten

CRUD 04-35
Terminologie 04-43


# 5. Code Quality 
### Technical Debt (Technische Schuld)
- need for refactoring to non-technical stakeholders
- langsamer, teuerer "Clean Code" vs schneller, billiger "messy code"
05-5 unsichtbar

### Refactoring
- Teil des Codes neustrukturieren/umschreiben, ohne die externe Funktion zu Ändern
- Bad code smells 05-21 (Code thats seems to be wrong)

### Reviews
05-25
- frühe Erkennung von Fehlern
- risiko minimierung
- effizient und effektiv
- zeitintensiv teuer
- Wettkampf zwischen personen kann entstehen

### Debugging
05-36f

### Safety and Reliability
05-41
- Safety: Fokus auf Konsequenzen um Menschheit nicht in Gefahr zu bringen
- Reliability: Verlass dass System Funktionieren wird für bestimmte Zeit


# 6. SAFe
Framework siehe skript

# 7. Design
## Architektur
- ist Struktur
- von der Analyse zur Relisation
- wichtig um Risiko von zukünftigen Problemen zu minimieren
- System Verständlich machen

### Goals of SW Architecture
07-7
- Risiko minimieren
- Verständniss generieren
- Grundwissen erhalten
- efiziente Entwicklung
- Aufrechterhaltung der konzeptionellen Integrität

Wichtig weil...
07-9
- technische Risiko Reduzierung
- implementation kann schlechte Architektur nicht fixxen
- Rahmenbedingungen
- Komplexität managen
Issues 07-10

## Patterns
Patterns addresieren wiederauftretende Design Probleme mit Dokumentierter, bekannter Design Erfahrung.
Besteht aus:
- kontext
- problem
- Lösung

## Kopplung vs. Kohäsion
07-21
Kopplung: Grad der Abhängigkeit zwischen Teilen (units)
Kohäsion: Grad der Abhängigkeit inerhalb eins Teils
weniger Kopplung -> bessere Wartbarkeit
hohe Kohäsion -> niedrige Kopplung -> bessere Verständlichkeit

Design Principles 07-23