Quality Gates

Mangelhafte Qualität von Software ist heutzutage ein allgegenwärtiges Problem. Die Norm EN ISO 8402 definiert Qualität folgendermaßen: "Die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen". Ein Hauptproblem der Softwareentwicklung und insbesondere des Anforderungsmanagements sind dabei die vorausgesetzten Erfordernisse. Im Entwicklungsprozess sind solche vorausgesetzten Erfordernisse meistens dem Entwickler nicht bewusst, da zwischen Kunden und Entwickler eine Barriere – die berühmte "Symmetry of Ignorance" – besteht.

Ein Defekt in der Software ist dann eine Abweichung zwischen der erwarteten und der tatsächlichen Eigenschaft der Software. Defekte können zweierlei Eigenschaften der Software betreffen: funktionale und nicht-funktionale Eigenschaften. Nicht-funktionale Eigenschaften umfassen dabei Eigenschaften wie Flexibilität, Bedienbarkeit und Sicherheit und sind häufig nur sehr oberflächlich in einer Anforderungsspezifikation beschrieben. Durch Konkretisierung dieser Eigenschaften mit Hilfe von Qualitäts-Modellen kann dieses Problem entschärft werden.

Die Qualitätssicherung in einem Unternehmen umfasst drei Maßnahmenbereiche: analytische, konstruktive und organisatorische Qualitätssicherung. Das Fachgebiet Software Engineering umfasst sich vorrangig mit der analytischen Qualitätssicherung. Grob gesprochen umfasst analytische Qualitätssicherung Methoden, um Software nach ihrer Erstellung zu prüfen und zu verbessern. Dabei sind Quality-Gate-Prozesse ein besonderer Forschungsschwerpunkt.

Abbildung 1: Das Referenzmodell des Quality-Gate-Prozesses
Abbildung 1: Das Referenzmodell des Quality-Gate-Prozesses

Quality-Gate-Prozesse

Viele Unternehmen mit Softwareentwicklungsabteilungen wenden bereits Quality-Gate-Prozesse (QGPe) an. Kernziele sind dabei, die Produktqualität zu sichern und Entwicklungskosten zu kontrollieren. Quality-Gate-Prozesse unterscheiden sich von Unternehmen zu Unternehmen leicht, was den Bedarf nach einem übergeordneten Referenzmodell erhöht. Der Stage-Gate-Prozess von Cooper ist beispielsweise ein solches Referenzmodell, welches allerdings den Nachteil hat, nicht speziell auf die Bedürfnisse der Softwareentwicklung einzugehen. Abbildung 1 zeigt grafisch unseren Ansatz eines Referenzmodells. Oberflächlich betrachtet beinhaltet der Prozess zwei Elemente:

Quality-Gates und Meilensteine

Quality-Gates unterscheiden sich von Meilensteinen! Meilensteine werden projektspezifisch gesetzt, während Quality-Gates für alle Projekte immer gleich gesetzt sind. Das Ziel ist es, Projekte durch einen immer gleichen formalen Qualitätssicherungsprozess zu steuern. Zu prüfende Aspekte werden in einer Checkliste festgehalten, um die Konsistenz der Prüfungen zu wahren.

Möglichkeiten des Tailorings

Referenzmodelle von Prozessen sind zu abstrakt, als das sie direkt in einem Unternehmen genutzt werden können. Dies gilt ebenfall für das Referenzmodell des QGPs. Durch das Zurechtschneidern (Tailoring) des Referenzmodells ist es aber möglich, ein anwendbares und nicht zu überladenes Modell zu erhalten. Der QGP kann dann so zurechtgeschneidert werden, dass er beispielsweise für eine bestimmte Klasse von Projekten verwendet werden kann. Abbildung 2 zeigt einen auf drei Phasen zurechtgeschneiderten QGP.

Abbildung 2: Ein typischer Quality-Gate-Prozess
Abbildung 2: Ein typischer Quality-Gate-Prozess

Werkzeugunterstützung für Quality-Gate-Prozesse

Wegen ihres formalen Charakters und der wiederholenden Aktivitäten kann der QGP leicht und effektiv durch ein Werkzeug unterstützt werden. Dieses Werkzeug NetQGate ist bereits prototypisch implementiert und eingesetzt worden. Dadurch wurden neue Verbesserungsmöglichkeiten aufgezeigt: globale Verteilung des QGPs, automatische Prüfung der Erzeugnisse und die Integration von Prozessverbesserungsverfahren.

Kontakt

Prof. Dr. Kurt Schneider

Literatur

  • 2005
  • [1] Thomas Flohr, Thorsten Schneider: An XP Experiment with Students - Setup and Problems, In Profes 2005, 2005, Bibtex.
  • 2006
  • [2] Thomas Flohr, Thorsten Schneider: Lessons learned from an XP Experiment with students: Test-First needs more teachings, In Profes 2006, Amsterdam, Netherlands. Springer-Verlag Berlin-Heidelberg, 2006, Bibtex.