Einer Pressemitteilung des Unternehmens, mit der auch das Bild des wütenden Chefs verbreitet wurde, kann man entnehmen, dass Fehler und Probleme in der neuen Software für das Chaos verantwortlich wären. Sicherlich gibt es bei der Einführung neues Software immer Situationen, in denen Fehler auftreten, die zuvor trotz intensiver Tests nicht entdeckt worden sind. Aber wie kann es kommen, dass durch die Umstellung auf eine neue Software ein ganzes Unternehmen ins Schleudern gerät.

Wenn ein Einzelner über Jahrzehnte eine Software betreut

Ein Satz im FAZ-Bericht gibt einen interessanten Hinweis. Dort heißt es:

Während aber die alte IT auf Cobol-Basis von einem einzigen Mitarbeiter am Laufen gehalten wurde, hakt es jetzt an allen Ecken und Enden

Was so klingt, als sei die alte Software um vieles besser gewesen als das neue System, verweist in Wirklichkeit darauf, dass die Probleme womöglich eher in der Vergangenheit liegen. Oft werden nämlich in Unternehmen tatsächlich individuelle Lösungen von einzelnen Experten über Jahrzehnte gepflegt, erweitert, verändert, ergänzt. Auf Zuruf und oft dringend wird immer wieder an einzelnen Modulen programmiert, werden Algorithmen für spezielle Fälle angepasst, wird hier und da noch eine Besonderheit eingebaut.

Es entsteht ein unübersichtliches System, von dem niemand mehr weiß, was es wirklich tut, was davon überhaupt noch gebraucht wird und unter welchen besonderen Umständen welche spezielle Bedingung zu einem einzelnen Ergebnis führt. Am Ende weiß jeder nur: Es läuft irgendwie, und so, wie es läuft, ist es auch gewollt.

Solche Systeme sind nur selten dokumentiert, die Geschäftsanforderungen stehen nirgends als im Programmcode, keiner weiß noch, welche Anforderungen wann zu welcher Funktion beigetragen haben.

Wenn ein neues System spezifiziert wird

Leider erinnert sich auch keiner an diese vielen Einzelfälle und Besonderheiten, wenn es an die Anforderungsanalyse für das neue System geht. Da werden oft nur die Standardfälle beschrieben, die vielen Ausnahmen werden eher zufällig aufgeführt. Dass der alltägliche Geschäftsprozess vor allem aus Ausnahmen besteht, will da nur selten jemand wahrhaben. Es herrscht das Prinzip Hoffnung: Wenn wir das neue System erst mal haben, gibt es diese Ausnahmen vielleicht auch nicht mehr.

Die Ernüchterung folgt in der Praxis, wenn die gewohnten, optimierten und vertrauten Geschäftsprozesse auf die neue Software treffen, die von all den Ausnahmen nichts weiß. Dann fällt den Mitarbeitern plötzlich auf, dass in diesem speziellen Fall ja jene Ausnahmebedingung gilt, dass man ja vor Jahren den einzigen Programmierer gebeten hatte, in der Situation die Schnittstelle so anzupassen, dass jenes Feld ja manchmal doch einen anderen Wert enthalten kann usw. usf.

Gerade für Altsysteme endlich ein Anforderungsmanagement einrichten

Ob die Probleme bei Liqui Moly von dieser Art sind, weiß ich nicht. Aber die Geschichte sollte jedem, der mit jahrzehntealten “gewachsenen” Software-Lösungen arbeitet, eine Lehre sein: Endlich ein Anforderungsmanagement einzurichten, das möglichst auch rückwirkend alle Spezialfälle, Besonderheiten, Anpassungen, Änderungen und Erweiterungen am System Stück für Stück dokumentiert. Auf dieser Basis kann man bei der Einführung einer neuen Lösung dann zweierlei machen:

1. Vollständige Anforderungsdokumentationen für die neue Software erstellen
2. Für Spezialfälle, die von der neuen Software nicht abgedeckt werden, rechtzeitig Änderungen in den Geschäftsprozessen vornehmen.

Und dann klappt es auch mit der neuen Software.

Der Beitrag Macht neue Software alles schlimmer? erschien zuerst auf INDAL Software-Spezialist.

Was für eine Art von Tätigkeit ist das Programmieren eigentlich? Die Philosophin Hannah Arendt unterschied in ihrem Buch “Vita activa” drei Arten von Aktivitäten: das Arbeiten, das Herstellen und das Handeln. Während das Arbeiten nach ihrer Unterscheidung dazu dient, das tägliche Überleben zu sichern, schafft das Herstellen Dinge, die der Mensch zum Arbeiten braucht, und das Handeln gestaltet die soziale Welt. So scheint die Sache erst einmal eindeutig: Softwareentwicklung ist Herstellen, so wie man auf den ersten Blick klar sagen kann, dass eine Software ein Werkzeug ist, das andere Aktivitäten unterstützt, so wie es der Hammer oder auch schon der Speer des Urmenschen tat.

Weiterlesen auf heise developer

Der Beitrag Ohne Ölwechsel erschien zuerst auf INDAL Software-Spezialist.

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.

Der Beitrag Das Ruder herumreißen erschien zuerst auf INDAL Software-Spezialist.

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.)

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.

Der Beitrag Softwartests sind unabdingbar erschien zuerst auf INDAL Software-Spezialist.

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.

Der Beitrag Wozu sind Testdaten da? erschien zuerst auf INDAL Software-Spezialist.

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.

Der Beitrag Peer Review im Softwareprojekt erschien zuerst auf INDAL Software-Spezialist.