Freitag, 18. Juli 2014

Ohne Abnahmekriterien läuft nichts.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im folgenden Post möchte ich ein sehr wichtiges Thema im Requirements Engineering behandeln, die Kriterien für die Akzeptanz bzw. die Abnahme von Software. Immer wieder habe ich erlebt, wie der Kunde sich auf den Standpunkt stellte, das wollte ich aber ganz anders. Zu diesem Zeitpunkt war das entsprechende Feature die gesamte Produktionskette durchlaufen. Es waren Tage, manchmal auch Wochen investiert. Nun musste der bestehende Zustand analysiert werden und die gewünschten Änderungen aufwendig in das schon Bestehende eingebaut werden. Manchmal hat man zu einem späteren Zeitpunkt immer noch nicht begriffen, wie wichtig eine sorgsame Analyse ist. Mehrere dieser Arbeitsgänge werden ausgeführt, bevor der Kunde sein Feature bekommt und richtig glücklich ist er dann zu diesem Zeitpunkt verständlicherweise auch nicht mehr.

Eine gute Analysetätigkeit wird am Ende auch nicht verhindern, dass es zu diesen Situationen kommen kann. Die Häufigkeit dieser Situationen wird jedoch erheblich minimiert. Durch die erforderliche Kommunikation zwischen Kunden und Entwicklung wird zudem ein viel höheres Verständnis aufgebaut. Natürlich müsste man die gesparte Zeit statistisch nachweisen, aber ich behaupte einmal, gefühlt ist es so und ich nehme es zurück, wenn statistisch erwiesen wird, dass eine Software langsamer entwickelt werden kann, wenn es ein mehr an Zusammenarbeit und Kommunikation mit dem Kunden und gut beschriebene Abnahmekriterien gibt. Für Firmen, die sich die Zeit natürlich doppelt und dreifach bezahlen lassen, ist die Vorgehensweise der vermiedenen Abnahmekriterien ideal. Sie würden ihre Einnahmen schmälern. Die Moral der Geschichte ist, repariere alles doppelt und dreifach und lasse es dir auch doppelt und dreifach bezahlen. Der Kunde als goldene Gans.



In unserem Vorgehen streben wir jedoch eine systematische Arbeitsweise an, die im Gesamtzusammenhang ökonomisch ist und die mit dem geringsten Einsatz genau zum Ziel führt. Einige Posts zurück haben wir User Stories angelegt. User Stories entstehen durch enge Kommunikation mit dem Kunden. Zu einer guten User Story gehören Akzeptanztests. "Akzeptanztests werden unter anderem geschrieben, weil damit viele Details zum Ausdruck gebracht werden, die sich aus dem Gespräch zwischen Kunden und Entwicklern ergeben. Anstatt ellenlange Listen mit Anforderungen zu schreiben (>>Das System soll ...<<), werden Tests eingesetzt, um Details in einer User Story einzupflechten." [S.87, COHN10]

Auch wenn wir keine ellenlangen Listen von Anforderungen schreiben wollen, so sind wir bemüht, eine gute Dokumentation unserer Anforderungen zu erreichen. Dazu haben wir die Mittel der UML benutzt. Mit Aktivitätsdiagrammen modellieren wir Szenarien, setzen diese zu Use Cases zusammen, die wir in Use-Case-Diagrammen zusammenfassen. Durch Klassen-, Aktivitäts- und Statusdiagramme finden wir Einzelanforderungen. Während dieses Prozesses helfen uns Akzeptanztests. "Akzeptanztests liefern auch grundlegende Kriterien, mit denen festgelegt werden kann, ob eine Story vollständig implementiert ist. Wenn Sie mithilfe von Kriterien bestimmen können, wann etwas fertig ausgeführt ist, ist das der beste Weg, um zu vermeiden, dass zu viel Zeit oder zu wenig Zeit und Mittel in das Projekt gesteckt werden." [S.88, COHN10]

Unser Vorgehen ist geeignet für langfristige Projekte bzw. Produkte, die durch mehrere Projekte entstehen und wo ein Stein auf dem anderen aufbaut. Hier soll nicht vergessen werden, was die Anforderungen waren und warum etwas getan wurde. Deshalb überführen wir die User Stories und ihre Akzeptanzkriterien in Use Cases und Abnahmekriterien. [COHN10] hat die Verantwortung des Kunden in zwei kurzen Sätzen beschrieben. "Sie sind für das Schreiben von Akzeptanztests verantwortlich. Sie sind für das Ausführen der Akzeptanztests verantwortlich." [S.93, COHN10] Wenn es nicht Kunden geben würde, die sich diesem Grundsatz entgegenstellen, man müsste es als kategorischen Imperativ der Programmierung bezeichnen. Auch an den Abnahmekriterien muss sich der Kunde auf gleiche Weise beteiligen. Natürlich kann ihn keiner dazu zwingen, mit den Folgen muss er dann allerdings leben. Die Entwicklung kann sich aber nur von der Verantwortung befreien, wenn sie alles versucht hat, den Kunden von dieser Notwendigkeit zu überzeugen.

[RUPP07] definiert ein Abnahmekriterium wie folgt: "Ein Abnahmekriterium ist eine Anweisung für den Test bezüglich einer Anforderung (oder eines Anforderungsteils), welche die Prüfung und Bewertung des erstellten Produkts oder durchgeführten Prozesses gegenüber dieser Anforderung (oder des Teils) beschreibt." [S.324, RUPP07] Bezieht sich das Akzeptanzkriterium auf eine User Story, so ist das Abnahmekriterium eine Verfeinerung auf Anforderungsebene oder sogar auf einem Teil davon. Abnahmekriterien gibt es für alle Arten von Anforderungen, für funktionale Anforderungen, für Qualitätsanforderungen und für Randbedingungen. An dieser Stelle zeigt sich, dass der Aufwand Abnahmekriterien zu entwickeln ungemein höher ist, als Akzeptanzkriterien für User Stories. Deshalb wird die Begeisterung beim Kunden auch begrenzt bleiben. Jedoch ist jede erreichte Teilmenge schon ein Sieg guter Überzeugungsarbeit.



[POHL08] bezieht Abnahmekriterien auf Anforderungsartefakte. "Abnahmekriterien für Anforderungsartefakte legen fest, welche Bedingungen ein Anforderungsartefakt bzw. das Anforderungsdokument erfüllen muss, damit es abgenommen wird." [S.224, POHL08] Ein Anforderungsartefakt ist bei [POHL08] ein Ziel, eine Szenario oder eine Anforderung. Diesen Umstand machen wir uns zunutze, wenn es darum geht, Abnahmekriterien gemeinsam mit dem Kunden zu entwickeln, bevor ihm die Puste ausgeht. Zuerst entwickeln wir Abnahmekriterien für Use Cases. Die Beschreibung der Abnahmekriterien kann sich an den entsprechenden Szenarien entlanghangeln, aus denen sich der Use Case zusammensetzt. Für Use Cases sollten wir möglichst eine vollständige Abdeckung mit Abnahmekriterien erreichen. Als nächstes gehen wir in die Tiefe und entwickeln Abnahmekriterien für einzelne Anforderungen. Ich denke, die meisten werden hier keine Vollständigkeit erreichen.

Sollten wir auch Abnahmekriterien beschreiben, wenn der Kunde zur weiteren Zusammenarbeit keine Zeit oder keine Lust mehr hat? Ich denke wir sollten es soweit treiben, wie wir es als nötig ansehen. Die durch die Entwicklung erstellten Abnahmekriterien müssen jedoch einen anderen Namen bekommen. Sie müssen von Abnahmekriterien unterschieden werden können, die der Kunde entwickelt hat, weil wir uns bei der Abnahme niemals sicher sein können, dass der Kunde dem Gedankengang der Entwicklung folgt. Dieses Kriterium nenne ich Entwicklerabnahmekriterium. Im späteren Verlauf ist es möglich, dass der Kunde dieses Kriterium kritisiert und so ein wirkliches Abnahmekriterium daraus wird. Abnahmekriterien liegen in unserem System also in zwei verschiedenen Status vor.

Im nächsten Post werde ich die Möglichkeiten beschreiben, wie wir Akzeptanz- und Abnahmekriterien dokumentieren. Diese Kriterien sind für uns Opener in die Welt der testgetriebenen Entwicklung.

  • [COHN10] Mike Cohn: "User Stories", 1. Auflage, mitp, Heidelberg, 2010
  • [POHL08] Klaus Pohl: "Requirements Engineering", 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008
  • [RUPP07] Chris Rupp & SOPHISTen: "Requirements Engineering und – Management", 4. aktualisierte und erweiterte Auflage, Carl Hanser Verlag, München, Wien, 2007


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen