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.

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.

“Test case driven software development” – das ist ein Trend der durchaus seine Berechtigung hat. Es geht darum, Testfälle schon in der Anforderungsspezifikation zu entwickeln und die Entwicklung der Lösung an diesen Testfällen auszurichten. Auch Designdokumente können an solchen früh entwickelten Testfällen geprüft werden – und der Entwickler weiß jederzeit, was bei der Implementierung in bestimmten Fällen (nicht in allen) herauskommen soll.

Allerdings scheinen manche große Software-Dienstleister den Sinn der Sache anders zu interpretieren. Sie fordern von ihren Kunden riesige Mengen von Testdaten, möglichst produktionsnah, und erwecken den Eindruck, dass es ohne solche Daten gar nicht möglich sei, die Anforderungen, insbesondere die nicht-funktionalen, der Kunden zu erfüllen.

Braucht man, um z.B. performante Anwendungen zu entwickeln, tatsächlich Testdaten aus der Produktion? Werden nicht vielmehr die Grundlagen für die Erfüllung solcher Anforderungen bereits in der Design-Phase gelegt, lange vor den ersten Performance-Tests, und wird performantes Verhalten nicht mehr durch erfahrene Entwickler und Datebank-Experten gesichert.

Man gewinnt den Eindruck, manche Anbieter kümmern sich während des Designs und der Realisierung nur um Funktionalität und “testen” die Performance dann während der Abnahme und Produktivsetzung in die Lösung hinein – Frust beim Anwender ist dann genauso vorprogrammiert (im wahrsten Sinne des Wortes) wie suboptimale Lösungen – denn was im Design falsch gemacht wurde, kann auf diese Weise nur geflickt, aber niemals wieder ausgebügelt werden.

Aus guten Gründen werden große Softwareprojekte nach Vorgehensmodellen abgewickelt, die Informatiker, die gerade frisch von der Uni kommen, gern als angestaubt und konservativ bezeichnen. Dem Wasserfall- und V-Modell wollen sie gern agile Methoden, Scrum und Extreme Programming entgegensetzen.

Aber Auftraggeber von kommerziellen Großprojekten erwarten Budget- und Terminsicherheit bei gleichzeitig klar definierten funktionalen und nicht-funktionalen Anforderungen, abgesichert in eindeutigen und verbindlichen Verträgen – und diese Sicherheit erwartet man eher von einfach und linear strukturierten Prozessen als von einer ungewissen Anzahl von Iterationen mit unbekanntem Ergebnis.

Allerdings können auch noch so gut vorbereitete Projekte mit erstklassig vordefinierten Phasen und Ergebnistypen selten die ursprünglichen Termin- und Kostenvorgaben einhalten. Ausgerechnet die zielgenaue und dosierte Anwendung agiler Methoden kann hier helfen – unter dem (wieder etwas konservativ klingenden) Begriff “Prototyp”.

Es gibt zwei Arten von Prototypen: Der eine ist vor allem unter dem Begriff “Klickprototyp” bekannt: Er modelliert bestimmte Aspekte des zukünftigen Systems ohne wirklich zu “funktionieren” – z.B. die Benutzeroberfläche oder die Verhaltensweise einer Schnittstelle.

Die andere Art von Prototyp wird oft als “Durchstich” bezeichnet – dabei wird ausprobiert, ob eine konzipierte Lösung wirklich funktioniert, d.h., der Prototyp liefert “echte” Ergebnisse.

Prototypen werden in der Konzeptionsphase des Softwareentwicklungsprozesses eingesetzt um Unsicherheiten über die Erfüllbarkeit funktionaler oder nicht-funktionaler Anforderungen auszuräumen. Sie kosten selbst allerdings Zeit und Ressourcen. Deshalb wird oft darauf verzichtet, insbesondere, weil Prototypen nach ihrem Einsatz oft weggeworfen werden und nicht in die endgültige Lösung eingehen.

Wenn die Prototypen nach agilen Methoden entwickelt werden, kann man aber dafür sorgen, dass sie zum Kern der späteren Lösung werden. Einfach gesagt kommt es darauf an, dass beim Erstellen des Prototypen nicht “quick and dirty” gearbeitet wird, sondern entsprechende Programmier-, Dokumentations- und Testrichtlinien angewendet werden.

Das hilft nicht nur, Doppelentwicklungen zu vermeiden, es wird auch sicher gestellt, dass die Ergebnisse der Arbeit am Prototyp wirklich in der Entwicklung berücksichtigt werden.

Wenn ein Unternehmen sehr lange mit dem gleichen Softwarelieferanten bei der Weiterentwicklung einer Software zusammenarbeitet kann es leicht passieren, dass die IT-Mitarbeiter des Kunden Stück für Stück das Wissen über die Anwendung verlieren. So begibt sich der Kunde in eine immer stärkere Abhängigkeit von der Entwicklerfirma: Er weiß nicht mehr, wie die Anwendung eigentlich funktioniert, welche Verbesserungen mit welchem Aufwand möglich sind, ob Probleme im Betrieb auf unzureichende Softwarequalität zurückzuführen sind und ob Preiskalkulationen für Neuerungen wirklich angemessen sind.

Für den Lieferanten scheint es eine komfortable Position zu sein. Irgendwann ist der Moment erreicht, in der der Kunde gar keine Chance mehr hat, ohne den Lieferanten auszukommen und sich vielleicht einen neuen Partner zu suchen.

Aber der Schein trügt. Zunehmende Abhängigkeit ist mit abnehmender Entscheidungsfreude beim Kunden verbunden. Bald wird an der Software nur noch das Nötigste getan, und innovative Neuerungen, an denen beide Seiten Spaß hätten, werden vermieden. Irgendwann entschließt sich der Kunde, das alte System zu beerdigen und eine Neuentwicklung in Auftrag zu geben – vorzugsweise bei einem anderen Anbieter.

Ein weitsichtiger Softwarelieferant überlegt deshalb von Anfang einer Partnerschaft an, wie er seinen Kunden mit ausreichendem, aktuellem und wirklich präsentem Wissen über die Anwendung versorgen kann. Ihm nur zu zeigen, „wo die Dokumentation steht“ und ihm großzügig zu erlauben, diese jederzeit abrufen zu können, reicht dafür nicht aus.

Zentrales Element eines partnerschaftlichen Wissensmanagements kann ein regelmäßiger Wissens- und Innovationsworkshop sein, in dem der Lieferant den Kunden über relevante technische Neuerungen informiert und die Konsequenzen für die Applikation diskutiert werden. In diesem Workshop sollten auch die aktuellen Veränderungen in der Softwarearchitektur demonstriert werden.

Natürlich hat auch der Kunde seinen aktiven Beitrag zu leisten. Dazu gehört, dass er kompetente Mitarbeiter benennt, die durch den Lieferanten auf dem Laufenden gehalten werden sollten. Diese werden dann regelmäßig per Newsletter über Neuigkeiten informiert.

Ein aussagefähiger Release-Letter, der bei Neuauslieferungen alle technologischen Konsequenzen der letzten Änderungen enthält, ist ebenso Bestandteil des Wissensmanagements. In einem Workshop sollte dieses Dokument diskutiert werden.

Häufig erweist sich ein Wiki als Wissensspeicher als geeignet. Dieses muss aber sinnvoll strukturiert und verschlagwortet sein – aber das soll ein andermal dargestellt werden.