Living Specification und Qualität der Software

Bereits an anderer Stelle habe ich über die Rolle von „guten“ Anforderungen im Softwareentwicklungsprozess geschrieben, und bin zu dem Ergebnis gekommen, daß es sich durchaus lohnt, Anforderungen so sauber und detailliert zu beschreiben, wir irgend möglich.

Auch ist es wichtig, professionelle Methoden zu verwenden, um zu prüfen, ob das entwickelte System die Anforderungen auch so abdeckt, wie von ihr verlangt.

Heute habe ich das Konzept der lebenden Spezifikation kennengelernt, das eine wichtige Rolle in der Schnittstelle zwischen Produkt-Owner, Entwicklung und Qualitätsicherung spielt. Dies will ich heute kurz skizzieren.

Warum wird eine lebende Spezifikation benötigt?

Die Mitarbeiter im Scrum Team entwickeln regelmäßig Software, die sie auf unterschiedlichen Ebenen testen. Die einzelnen Funktionen sind in den jeweiligen Backlog Items beschrieben, die der Produkt Owner zur Verfügung stellt. Im Sprintreview stellt man fest, inwieweit die Backlog Items fertig entwickelt wurden.

Die Anforderung, die der Kunde an die fertige Software stellt, taucht daher sehr häufig in verschiedenem Zusammenhang auf. So zum Beispiel taucht die Anforderung auf der Backlog Item Ebene auf, wenn der Produkt Owner dem Team den Kundenbedarf erklärt, oder sie taucht eben auch in den einzelnen Tests auf, die Entwickler durchführen, um die Entwicklungen durchzutesten. Schliesslich taucht sie aber auch in dem Coding selbst auf, das die Anforderung implementiert.

Je genauer diese Anforderungen beschrieben sind, und je genauer und zweifelsfreier die erwarteten Ergebnisse behandelt werden, desto besser. Früher haben wir papierbasierte Spezifikationen geschrieben. Diese haben zwei Nachteile:

  • Es ist nahezu unmöglich, diese Dokumente up-to-date zu halten, wenn sich Änderungen einstellen, oder fehlende Angaben nachgeklärt werden.
  • Man kann sie nur schlecht für Tests verwenden, da sie oft erst einmal aufwendig in eine maschinenlesbare Form gebracht werden müssen.

Hier die Definition des Begriffes „Lebende Spezifikation“ (siehe →What is living specification)

„Set of flexible requirements that concentrate on form, fit, and function, and are designed to readily accommodate incorporation of new products, processes, and more advanced requirements. Through a sensitive feedbacksystem, living specifications promote continuous quality improvements without a major change.“

Eine lebende Spezifikation soll einfach zu erweitern sein, und man soll sie dynamisch ändern können. Es soll ferner möglich sein, die spezifizierten Anforderungen direkt in der Entwicklung zu verwenden, um zu prüfen, ob die Software arbeitet, wie erwartet.

Hierfür bietet es sich an, die wesentlichen Teile der Anforderungen in einem System abzubilden (z.B. einer Datenbank), das jedem Teammitglied zur Verfügung steht. Darüberhinaus sorgt man dafür, daß jeder, der von Änderungen erfährt, die Angaben in der Datenbank erweitert.

Testen

Auf einer eher unteren Ebene eines Entwicklungsprojektes verwendet man Unit Tests, mit denen sichergestellt wird, daß die Software, und jeder einzelne Baustein richtig entwickelt wurde. Hier benötigt man also Daten mit denen man beurteilen kann, ob einzelne Module richtig arbeiten (z.B. enthält die ausgegebene Tabelle richtige Werte? Stimmen die Ergebnisse insbesondere an den jeweiligen Grenzen? etc)

Auf einer höheren Ebene in der Softwarehierarchie laufen zum Beispiel die Acceptancetests, mit denen man feststellt, ob die entwickelte Software auch die Geschäftsanforderungen abdeckt, die von ihr erwartet werden. Hierbei konzentriert man sich auf die Integrationsaspekte, und damit die Objekte, die die einzelnen Tabellen, Fehler, etc zusammenfassen (z.B. Wird der Kundenauftrag richtig bearbeitet, der aus unterschiedlichen Rabattklassen, Einzelitems, Mengen, etc besteht?)

Allen diesen Tests gemein ist, daß sie Testdaten verwenden, die die Realität möglichst gut abdecken. Hier beginnt jedoch das eigentliche Problem:

  • In der Entwicklung finden Tests statt, die der Endabnehmer oft nicht richtig versteht (da zum Beispiel Programmiererfahrung notwendig wäre).
  • Der Kunde verwendet oft Angaben, die sich nicht einfach in Testfälle übersetzen lassen (z.B. da erwartete Ergebnisse oft „implizit“ sind)

Dazwischen findet eine ausgiebige Kommunikation statt. Eine lebende Spezifikation besitzt daher neben der gemeinsamen Datenbasis zwei wichtige Schnittstellen:

  • Eine Benutzerschnittstelle, die es Produktowner und Kunde erlauben, die einzelnen Angaben während des Anforderungsgesprächs in Tabellenform zu erfassen (z.B. zu erfassen, daß es 3 Rabattklassen gibt, die von dem Umsatz abhängen).
  • EIne Schnittstelle, die es einem Test erlaubt, diese Daten automatisch zu lesen und mit dem berechneten Ergebnis zu vergleichen, um sicherzustellen, daß das System z.B. die Rabattklassen richtig zurückgibt.

Weiterführende Informationen

… im Internet

Im Internet finden Sie weiterführende Artikel:

… auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

Kontakt

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

    I

    This entry was posted on Mittwoch, Oktober 19th, 2011 at 7:32 pm. It is filed under PM-Themen, Thema des Tages and tagged with , , . You can follow any responses to this entry through the RSS 2.0 feed.

    Andreas Rudolph - Fotoshop Andreas Rudolph - AS-Photo-Project.de

    Comments are closed.