Wenn alle begriffen haben, dass das Projekt in Schieflage geraten ist, ist es meistens zu spät. Und dann wird zumeist hektisch mit den falschen Maßnahmen reagiert. Aber Überstunden und Durchhalte-Strategien helfen nicht – genau so wenig wie es sinnvoll ist, in einer Sackgasse immer schneller zu rennen.

Wer Softwareprojekte auch in schwierigem Umfeld zum Erfolg führen will, muss zweierlei klären:

• Wie bemerke ich frühzeitig, dass etwas schief läuft?
• Was ist zu tun, wenn relativ spät gravierende Probleme erkannt werden?

Dummerweise kann man den Fortschritt eines Softwareprojektes nicht sehen wie den Baufortschritt beim Eigenheim. Aus der Menge des erstellten Codes lässt sich selten auf den Fertigstellungsgrad schließen. Erst wenn die Software in den Test geht, fällt auf, dass manches noch fehlt oder nicht richtig funktioniert, dass Anforderungen falsch verstanden wurden oder die Performance der Routinen nicht den Anforderungen des Alltags genügt.

Fortschritt muss man sehen

Eins ist klar: der beste Projektplan nützt nichts, wenn man die Fortschrittsmeldungen der Analysten, Designer und Entwickler nicht nachprüfen kann. Da hilft nur, von Anfang an eine parallele Qualitätskontrolle zu implementieren. Schon die Spezifikations- und Designdokumente können während ihrer Erstellung einem regelmäßigen Review unterzogen werden. Die Qualitätssicherung dieser Dokumente erst kurz vor der geplanten Fertigstellung vorzusehen, führt oft nur dazu, dass sie ganz weggelassen wird und dass in den Entwicklungsprozess dann mit unfertigen Vorgaben gestartet wird. Mancher mag das “agile Entwicklungmethodik” nennen – meist ist es nur ein Zeichen dafür, dass schon am Anfang des Projekts vieles falsch gelaufen ist.

Die Implementierung sollte so geplant werden, dass schon früh Teile des Systems in die Testumgebung ausgeliefert werden können. Darauf ist die Erstellung der Testfallkataloge zu synchronisieren. Entwickelertests müssen nachvollziehbar dokumentiert werden – und im Zweifel sollten sie auch nachvollzogen werden. So kann man zumindest ein Gefühl dafür bekommen, wie es um den Projektfortschritt wirklich bestellt ist.

Kein Vertrauen?

Mancher meint, solche Maßnahmen schaffen eine Atmosphäre des Misstrauens. Aber das Gegenteil ist der Fall. Wenn keine Zwischenergebnisse vorweisbar sind und für Qualitätssicherung und Tests nichts zur Verfügung steht, dann entsteht Misstrauen – zu Recht.

Was aber ist zu tun, wenn Verzögerungen und Qualitätsmängel auftreten, die nicht mehr ausgeglichen werden können, und der Terminplan des Projektes ernsthaft in Gefahr gerät?

Oft meint man, durch erhöhten Ressourceneinsatz (Überstunden, zusätzliches Personal) das Projekt auf Kurs halten, gegensteuern, zu können. So hofft man, irgendwie in der geplanten Zeit doch noch das Projekt zum Erfolg zu bringen. Aber mit den Überstunden steigt die Fehlerquote, die Produktivität sinkt. Und zusätzliche Entwickler verkürzen selten die Entwicklungszeit, wenn sie noch eingearbeitet werden müssen. Außerdem steigt der Koordinationsaufwand.

Gegensteuern oder neuer Kurs?

Gegensteuern bedeutet, das Schiff auf Kurs zu halten, auch wenn die Umstände sich ändern. Das ist lobenswert, kostet aber zusätzliche Kraft und funktioniert immer nur begrenzte Zeit. Frühzeitig muss man sich deshalb fragen, ob ein anderer Kurs gewählt werden sollte, oder ob ein neues Ziel angesteuert werden kann.

Neuer Kurs, das heißt, das Vorgehensmodell im Projekt wird überarbeitet. Getaktetes Liefern von Zwischenergebnissen, Umorganisieren der Teams, das sind mögliche Maßnahmen.

Ein neues Ziel ansteuern, das bedeutet, über Prioritäten bei den Projektzielen zu sprechen. Dazu ist ein offensives Anforderungsmanagement notwendig: Anforderungen müssen von Anfang an zerlegt und unterschiedlich priorisiert werden, Umsetzungsalternativen müssen bekannt und bewertet sein. Dann kann auch während des Projektes noch neu bestimmt werden, was zu welchem Termin auszuliefern ist, damit die Fachseite ihre Geschäftsziele erreicht.

Externe Unterstützung, etwa durch die INDAL-TaskForce, wird in solchen Situationen vor allem gebraucht, um effektiv die Möglichkeiten des Umsteuerns zu prüfen und umzusetzen. Externe Entwicklerressourcen, die dann zusätzlich zum Einsatz kommen können, unterstützen zielgerichtet diese Schritte. Nicht einfach mehr Ressourcen, sondern an den richtigen Stellen die richtigen Kompetenzen, dass ist die Methode, das “Ruder herumzureißen” – So wie bei einer Erkrankung manchmal eben akut nicht mehr Obst und Gemüse, sondern eine kleine Dosis bittere Medizin hilft.

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 der Wissenschaft ist ein Verfahren zur Qualitätssicherung bekannt, das unter dem Namen “Peer Review” dafür sorgt, dass in wissenschaftlichen Journalen möglichst nur qualitativ hochwertige Artikel erscheinen. Auch wenn dieses Verfahren nicht ohne Schwächen ist, kann man in IT-Projekten einiges aus der Methode der Wissenschaftler lernen.

Peer Review, die Qualitätskontrolle durch Kollegen, durch Fachleute, die den gleichen Job machen wie der Autor selbst, ist mehr als dass einer zum anderen sagt: “Hey, schau dir doch mal an, was ich da gemacht habe und sag mir mal, ob dir irgendwelche Fehler auffallen”. Peer Review ist ein organisierter und weitgehend formalisierter Prozess, und nur als solch ein Prozess ist er eine Methode zur Qualitätssicherung im Projekt.

Peer Review kann für die Qualitätsprüfung aller Lieferbestandteile eines Projektes eingesetzt werden, seien es Anforderungsdokumente, Spezifikationen, Projektpläne, Software-Module oder Handbücher. Besonders effizient ist es allerdings bei Anforderungsdokumenten und Spezifikationen, deren Qualität nicht wie bei Software im Black-Box.Verfahren getestet werden kann und bei denen (im Gegensatz zu Projektplänen und Handbüchern) meist eine ausreichende Zahl von Peers, also von Kollegen, die ebenfalls Dokumente dieses Typs schreiben, zur Verfügung stehen.

Ähnlich wie beim wissenschaftlichen Peer Review sollte sich auch im IT-Projekt der Autor nicht selbst seine Peers zur Kontrolle aussuchen, dazu wird die Rolle des Editors eingeführt. Der Editor wählt für jedes Dokument wenigstens zwei Peers aus, die dieses begutachten. Die Gutachter geben ihre strukturierten und formalisierten Gutachten (dafür gibt es entsprechende Templates) zum vereinbarten Termin an den Editor, möglicherweise mit einem Vorschlag zum weiteren Verfahren. Der Editor entscheidet dann, ob das Dokument freigegeben wird oder ob es nach Überarbeitung entweder direkt freigegeben werden kann oder erneut durch den Review muss.

Wie das Peer Review genau durchgeführt wird, hängt von einer reihe von Projektparametern ab, danach ist auch zu entscheiden, ob gemeinsame Sitzungen der Peers mit dem Autoren durchgeführt werden, was Vor- aber auch Nachteile hat. Wirklich effizient wird der Peer Review erst durch die Anpassung des Verfahrens an die konkrete Projektsituation.

Peer Review im Softwareprozess ist eine zeitsparende Methode zur Qualitätssicherung, die gleichzeitig das Projektwissen gut verteilt.