Für die Bewältigung komplexer Probleme, kann man auch ausgefallene Methoden anwenden, dieses möchte ich hier an der Brainwriting-Technik Collective-Notebook Method zeigen.

Da diese Methode recht zeitaufwendig ist, ist sie auch zur Findung schnellere Lösungen nicht geeignet und sollte dann ggf. zum Einsatz kommen, wenn das Problem groß und/oder komplex genug ist.

Kernidee ist das jeder Teilnehmer ein Notizbuch mit sich führt und das über Wochen und rund um die Uhr.

Zu Anfang wird das Problem konkret definiert und es wird festgelegt, wer zur möglichen Lösung beitragen soll. Nun bekommt jeder Teilnehmer ein Notizbuch, an dessen Anfang das Problem niedergeschrieben ist.

Dieses Notizbuch soll den Teilnehmern in der Findungsphase quasi durchgehend zugänglich sein und ihnen die Möglichkeit bieten, im Fall einer guten Idee, diese sofort im Buch festzuhalten. Aber nicht nur Geistesblitze sind dort niederzulegen, sondern auch z.B. ein mal am Tag sollte grundlegend ein Eintrag erfolgen.

Nach den (wenigstens) 2 Wochen fassen alle Teilnehmer ihre eignen Ergebnisse zusammen und in einer gemeinsamen Sitzung werden dann die Ergebnisse ausdiskutiert und im Idealfall zu einer Gesamtlösung ausgearbeitet.

Falls Sie z.B. in der Anforderungserhebung oder bei sonstigen Ideenfindungen Probleme haben, u.a. vielleicht auch durch zu dominante/schwierige Teilnehmer, gibt es Methoden bzw. Kreativitätstechniken die es dem Einzelnen ermöglichen anonymer Betrag zu leisten, um so zu neuen Ideen zu kommen.

Eine davon ist die Methode 635.

Die Methode 635
Der Name ergibt sich aus:
6 Teilnehmer
3 Ideen
5 mal weitergeben

Man setzt sich mit 6 Personen in eine Runde. Jeder der Teilnehmer notiert, auf einem gleichgroßen Blatt Papier, 3 Ideen in der ersten Zeile einer Tabelle mit 3 Spalten. Jede Spalte hat 6 Zeilen.

Nach einer vordefinierten Zeit wird gleichzeitig das Blatt nach rechts weitergereicht.

Im nächsten Zeitintervall erweitert dann jeder die 3 Ideen, die er auf seinem Blatt hat.

Dieses wird solange wiederholt, bis alle einmal jedes Blatt in der Hand hatten.

Zettel

Danach kann das Ergebnis ausgewertet werden.

Auf diesem Weg kann man bei leichten bis mittleren Problemen ggf. schnell zu neuen Ideen und Lösungen kommen.

In diesem Artikel möchte ich darauf eingehen warum Softwaretests genügend beachtet werden sollten.

Das Testen eines Softwareproduktes wird gerne bei der Planung von Zeiten innerhalb des Projektmanagements vernachlässigt.
Nach Faustformel des iSTQB® sind um die 50% des Gesamtbudgets für Tests einzuplanen.

Man muss immer bedenken, dass der Aufwand für Tests ggf. weit niedriger ist, als die Folgekosten durch nicht aufgedeckte Fehlerzustände.

(z.B. Fehler in Steuerungsanlage s.u.)

Quelle: http://commons.wikimedia.org/wiki/File:Studenka_train_accident_3.jpg

Um einzugrenzen, wie hoch das Risko ist und in Folge der Testaufwand sein sollte, kann man nach folgender Formel gehen:

Wahrscheinlich des Schadenseintritts mal die Schadenshöhe

Das Testen fängt im Idealfall schon bei der Anforderungserhebung an, wenn es um die Qualitäts der erstellten Dokumente geht.

Vor einigen Tagen hatte ich darüber geschrieben, dass die Trennung von funktionalen und nicht-funktionalen Anforderungen eigentlich problematisch ist. Diesem Gedanken möchte ich noch einmal nachgehen:

Ein Beispiel:
„Berichte in der Anwendung sollen innerhalb von 30 Sekunden bereitgestellt werden“
Ist das eine funktionale oder eine nicht-funktionale Anforderung? Viele werden argumentieren, dass dies eine nicht-funktionale Anforderung ist, da der Satz etwas über das „Wie“ der Leistungserfüllung aussagt. Aber dass die Anwendung „Berichte bereitstellen“ soll, ist eine funktionale Anforderung, und wenn die Berichte typischerweise erst ein Tag nach dem Aufruf des entsprechenden Menüpunktes bereitgestellt werden, dann ist das keine Funktionserfüllung, auch wenn alle Zahlen im Bericht korrekt sind.
Ein neuer Ansatz ist, zu sagen, dass jede Anforderung sowohl Aussagen zu der Frage, was umgesetzt werden soll als auch zu der Frage, wie es umgesetzt werden soll enthält. Anforderungen lassen sich dann generalisieren und spezialisieren, wie wir es aus der objektorientierten Sichtweise kennen.
Können wir damit die Anforderungen, die wir bisher in funktionale und nicht-funktionale unterschieden haben, komplett abbilden? Nicht ganz, ein Aspekt fehlt noch, es ist der der zeitlichen Veränderbarkeit der Anforderung. Ist zu erwarten, dass ein Bericht sich ändert, wenn ja, wie oft? Werden Datenmengen wachsen? Wird die Anforderung auch unter geänderten Bedingungen, z.B. bei neuen Infrastrukturen und Plattformen, bestehen bleiben? Dieser dynamische Aspekt von Anforderungen wird oft vernachlässigt, aber wenn wir ihn mit einbeziehen, dann haben wir quasi alles was wir brauchen, um eine gute Architektur zu entwerfen.
Dazu legen wir uns wie gesagt eine Anforderungs-Hierarchie an, eine Vererbungs-Struktur. Die Basis-Anforderungen sind das Fundament, sowohl für die abgeleiteten Anforderungen als auch für den Architektur-Entwurf der Software. Umso spezieller die Anforderungen werden, desto geringer ist ihr Einfluss auf die Architektur.

Zum IT-Projekt gehört nicht nur die Umsetzung der Softwareanforderungen sondern auch das Einrichten neuer Geschäftsprozesse, denn selten bleiben die Abläufe im Unternehmen gleich, wenn die verwendete Software sich ändert.

Leider werden die Verantwortlichkeiten für beides meist schon zu Projektbeginn säuberlich getrennt. In verschiedenen Teams wird nebeneinander her gearbeitet. Man tut so, als ob die Softwareanforderungen alles Wichtige über die Software sagen und dass die Geschäftsprozesse in den frühen Anforderungserhebungen bereits hinreichend dokumentiert wurden. Aber das ist ein großer Fehler, der sich spätestens dann rächt, wenn die Lösung “live” gehen soll. Dann merkt man, dass die Software eben nicht genau zu den Prozessen passt.

Da die Änderung einer fertigen Software viel zu teuer ist, werden die Geschäftsabläufe mühsam an die Software angepasst, was aus vielen Gründen frustrierend ist und zu großen Akzeptanz-Problemen für das neue System führt.

Gibt es Alternativen? Idealerweise würde es überhaupt nur eine Dokumentation geben, in der die Geschäftsprozessänderungen genauso dargestellt werden wie die Spezifikation der Softwarelösung. Das ist leider nicht immer möglich. Wichtig ist aber eine enge Zusammenarbeit zwischen Software- und Prozess-Designern. Bei jedem Anwendungsfall muss gefragt werden: wie ändert er die Geschäftsprozesse? Und wie wirkt sich eine Änderung der Geschäftsprozesse auf die Software-Anforderung aus?

Vor längerer Zeit hatte ich schon einmal darüber geschrieben, dass die Kontextabgrenzung im IT-Projekt oft intuitiv falsch gezogen wird – man meint, das System, das sich ändert, bestehe nur aus Software. Das ist der Denkfehler: Die Geschäftsprozesse sind nicht Kontext, sie gehören zum System dazu.

Praktisch heißt das: Die Prozessverantwortlichen müssen mit den Systemdesignern ständig zusammenarbeiten, jedes Teilergebnis, jeder wichtige Vorschlag muss der anderen Seite vorgestellt und diskutiert werden. Soll mit einer geänderten Anforderung der Prozess oder die Software angepasst werden.

Das spart auch Kosten: Oft ist die Änderung eines Prozesses nur eine kleine Sache – wenn sie rechtzeitig und plausibel kommuniziert wird. Dagegen kann die Umsetzung einer Softwareanforderung entsprechend eines alten Prozesses großen Aufwand bedeuten.