7. Systematische QS von Anforderungen, Architekturen und Prozessen

• SW-Systeme

• SW-Prozesse

• Anforderungen

• Architekturen

  
  

1. Freigabe der Anforderung

2. Nach Ermittlung der fachlichen Anforderung und nach Erstellung der technischen Spezifikation

3. fachlich, handwerklich und abgestimmt

4. Konflikte

   • widersprechende Anforderungen von unterschiedlichen SH mit wiedersprechenden Zielen

   • widersprechende Anforderungen und Ansichten SH

   Gründe:

   • unterschiedliches Verständnis von Begriffen, Zuständigkeiten und Motivation

5. 1. Prüfkriterien festlegen

   1. Prüfprinzipien und Prüftechniken auswählen

   2. Prüfung durchführen und Ergebnisse dokumentieren

   3. Abstimmen der Anforderungen/ Konflikmanagement

1. Ziele

   Prüfung auf Einhaltung Architekturbeschreibung

   • ex ante: vor der Implementierung auf Basis der Architekturbeschreibung

   • ex post: während/ nach Implementierung

2. Art und Zeitpunkt der Technik

1. Beurteilung der Eignung einer Architektur für ein System, bevor es umgesetzt wird.

2. Bewertung, ob die Qualitätseigenschaften (z. B. Performance, Sicherheit) und Randbedingungen erfüllt werden. Diese haben den größten Einfluss auf die Architekturwahl.

3. Szenariobasierte Architekturanalyse, oft mit der ATAM (Architecture Tradeoff Analysis Method).

   —> Die Architektur wird anhand konkreter Anwendungsszenarien des Systems bewertet. Es wird geprüft, ob die Architektur die geforderten Qualitätseigenschaften unterstützt.

1. Bewertung von Architekurdefinition und FInden möglicher Alternativen

2. 
   

2.1 Phase 1: Vorbereitung & Präsentation

• Ziel: Gemeinsames Verständnis der Anforderungen und des Architekturentwurfs herstellen.

• Phase 2: Untersuchung & Analyse

  • Ziel: Architekturvarianten identifizieren und grob auf ihre Eignung prüfen.

• Phase 3: Test

  • Ziel: Die beste Architekturvariante durch detaillierte Analyse finden und Kompromisse dokumentieren.

• Phase 4: Berichterstattung

  • Ziel: Alle Entscheidungen und Ergebnisse nachvollziehbar dokumentieren.

2.2 Phase 1: Vorbereitung und Präsentation

• Schritt 1: Vorstellung der ATAM-Vorgehensweise an alle Beteiligten.

• Schritt 2: Klärung der wichtigsten Anforderungen (Business Driver) für das System, um ein gemeinsames Verständnis zu schaffen.

• Schritt 3: Präsentation der aktuellen Basisarchitektur, um den Stand der Dinge zu zeigen und offene Fragen zu klären.

  Phase 2: Untersuchung und Analyse

  
  

  • Schritt 4: Erstellung verschiedener Architekturvarianten basierend auf der Basisarchitektur.

  • Schritt 5: Entwicklung und Priorisierung von Anwendungsszenarien, die die geforderten Qualitätseigenschaften beschreiben ("Utility Tree" = Menge der Szenarien mit Qualitätseigenschaften).

  • Schritt 6: Grobe Prüfung der Architekturvarianten, um festzustellen, wie gut sie die Szenarien erfüllen, und Erstellung einer priorisierten Liste.

  
  

  Phase 3: Test

  
  

  • Schritt 7: Verfeinerung und Erweiterung der Szenarien aus Schritt 5, unter Einbeziehung aller Stakeholder.

  • Schritt 8: Detaillierte Analyse der Architekturvarianten anhand der verfeinerten Szenarien, um die am besten geeignete Variante zu finden und Kompromisse (Trade-offs) zu identifizieren.

  
  

  Phase 4: Berichterstattung

  
  

  • Schritt 9: Zusammenfassung und Dokumentation aller Erkenntnisse und Entscheidungen aus den vorherigen Schritten, um die Nachvollziehbarkeit der Architekturentscheidungen sicherzustellen.

1. Sicherstellen, dass die tatsächliche Software den Vorgaben der Architekturdefinition entspricht.

2. Architecture Compliance Checking.

   Ein Softwaremodell wird aus dem Programmcode erstellt (z.B. ein UML-Diagramm) und mit dem ursprünglichen Architekturentwurf verglichen. Abweichungen müssen bewertet und behoben werden.

• Befragung der Stakeholder

• Bewerten des SW-Prozesses durch Stakehaolder anhand Qualitätskriterien

  (Verstädnlichkeit, Standardisierung, SIchtbarkeit, Messbarkeit, Stabilität)

1. Rahmenwerk für Prozessverbesserungen

2. Beurteilung des Reifegrades von Software - und Managementprozessen

3. 
   

• Stufe 1 – Initial: Es gibt keine Prozessdefinition; die Aktivitäten finden ad hoc statt bzw. werden chaotisch durchgeführt. Der Prozess ist in der Regel nicht wiederholbar.

• Stufe 2 – Geführt: Der Prozess ist wiederholbar. Umfang und Ergebnis der zu erledigenden Aktivitäten ist den Teammitgliedern bekannt. Es gibt aber keinen detaillierten Prozess, der Aktivitäten, Rollen, Ergebnisse und deren Abhängigkeiten explizit definiert.

• Stufe 3 – Definiert: Es gibt einen definierten Prozess, in dem Aktivitäten, Rollen und Ergebnisse verbindlich dokumentiert sind. Der Prozess enthält konkrete Methoden und Vorgehensweisen zu den einzelnen Software Engineering Aktivitäten.

• Stufe 4 – Quantitativ geführt: Die Prozessqualität kann über Messung quantitativer Prozesseigenschaften festgestellt und gesteuert werden. Über erhobene Kennzahlen zu Aktivitäten der Prozesse sowie zu den erzeugten Ergebnissen können Havarien identifiziert und entsprechend gegengesteuert werden.

• Stufe 5 – Prozessoptimierung: Prozess- und Produktmessungen werden kontinuierlich erhoben und zur Prozessverbesserung eingesetzt. Je nach Messwert kann der Prozess auf den aktuellen Bedarf hin angepasst werden.

1. stufenweise von einem niedrigen zu einem höheren Grad

1. Nein, es ist ein zyklischer Prozess

2. Prinzip der ständigen Verbesserung des TQM

3. 
   

1. Verbesserungsbedarf erkennen & Vorschläge entwickeln: Zunächst werden Schwachstellen im aktuellen Prozess identifiziert und Verbesserungsideen gesammelt.

2. Vorschläge priorisieren: Die gesammelten Vorschläge werden bewertet, um ihre Umsetzbarkeit zu prüfen und die nächsten Schritte festzulegen.

3. Änderungs- und Schulungsplan erstellen: Es wird ein detaillierter Plan erstellt, der festhält, wann, wie und von wem die Änderungen umgesetzt werden. Zudem wird ein Schulungsplan entwickelt, um die betroffenen Mitarbeiter auf die neuen Abläufe vorzubereiten.

4. Prozessänderungen einführen & anpassen: Die geplanten Änderungen werden umgesetzt, und begleitend dazu werden Dokumente, Werkzeuge und Vorgehensweisen angepasst.

5. Anpassungsphase: Nach der Einführung werden die Änderungen beobachtet und bei Bedarf feinjustiert, um sicherzustellen, dass sie in der Praxis funktionieren und vom Team angenommen werden.

6. Stabilität erreichen: Wenn die Anpassungen abgeschlossen sind, ist der Prozess stabil, und der Zyklus kann von Neuem beginnen.