IUBH Qualitätssicherung im Softwareprozess IQSS

• Neben den Artefakten, die in einem Softwareprozess erzeugt werden, können Softwareprozesse bzw. Softwareprozessmodelle ebenfalls hinsichtlich deren Qualität geprüft und verbessert werden.
• Die Grundannahme hinter der Qualitätssicherung und Verbesserung von Softwareprozessen ist, dass es einen Zusammenhang zwischen der Prozessqualität und der Produktqualität gibt.
• Zur Bewertung von Softwareprozessen können verschiedene spezifische Prozessmerkmale herangezogen werden

• Um die Änderungsnotwendigkeit von Softwareprozessen zu erkennen, muss zunächst eine Prozessanalyse durchgeführt werden.
• Das kann recht pragmatisch durch eine Befragung der am Prozess beteiligten Stakeholder erfolgen.
• Eine weitere Möglichkeit ist das strukturierte Bewerten verschiedener Qualitätskriterien, beispielsweise durch Stakeholder des Software prozesses:
  • Verständlichkeit
  • Standardisierung
  • Sichtbarkeit
  • Messbarkeit
  • Unterstützbarkeit
  • Akzeptanz
  • Zuverlässigkeit
  • Stabilität
  • Wartungsfreundlichkeit
  • Schnelligkeit

• Capability Maturity Model Integration (kurz: CMMI) wurde vom amerikanischen Software Engineering Institute (SEI) ein Reifegradmodell für Softwareprozesse entwickelt.
• Das CMMI-Modell ist als Rahmenwerk für Prozessverbesserungen konzipiert. Es enthält dazu unter anderem ein Stufenmodell zur Beurteilung des Reifegrades von Softwareund Managementprozessen.
• Das CMMI-Modell ist sehr umfangreich und umfasst:
  • 22 Prozessgebiete aus dem Software Engineering;
  • Ziele, die spezifisch für jedes Prozessgebiet formuliert werden;
  • Vorgehensweisen, mit denen die Ziele erreicht werden können.
• Der aktuelle Fähigkeitsgrad zu einem Prozess wird dabei auf einer 5-stufigen Skala bestimmt.
• Die Bestimmung des Reifegrades basiert auf der Analyse der aktuellen IST-Prozesse eines Unternehmens.
• CMMI-Grad 1 ist dabei die niedrigste Stufe, Grad 5 entspricht der höchsten Fähigkeitsstufe.

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 erledi-
genden 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 identifi-
ziert 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.

• Für den Fall, dass bei der Prozessanalyse Verbesserungsvorschläge erarbeitet wurden, müssen diese strukturiert in das Softwareprozessmodell übernommen werden.
• Der Prozess ist ein zyklischer Prozess, das bedeutet, er wird grundsätzlich niemals endgültig sein.
• Die erste Aktivität im Verbesserungsprozess ist das Erkennen von Verbesserungsbedarf in der aktuellen Prozessversion und die Erarbeitung möglicher Verbesserungsvorschläge.
• Im Zuge der Priorisierung werden die Vorschläge auf deren Umsetzbarkeit und den für die Umsetzung erforderlichen weiteren Aktivitäten hin analysiert.
• Die Ergebnisse der Priorisierung sind zum einen ein Änderungsplan, der unter ande rem die Zeitpunkte und Verantwortlichkeiten für die Einführung von Prozessverbesserungen sowie mögliche Abhängigkeiten zwischen einzelnen Verbesserungsschritten dokumentiert.
• Darüber hinaus wird ein Schulungsplan erstellt, auf dessen Grundlage konkrete Schulungsmaßnahmen der von den Änderungen betroffenen Stakeholder durchgeführt werden.
• Neben dem Wissen um die Änderungen im Softwareprozess müssen für die Umsetzung der Prozessänderungen unter Umständen auch neue fachliche Kompetenzen erlangt werden.