Warum Codierung und Test nur die halbe Miete sind
Software erfolgreich zu entwickeln bedarf eines über Jahrzehnte hinweg entstandenen, wirklich gut erprobten Vorgehensmodells.Das naheliegende, aber allzu naive Modell der 70-er Jahre des vorigen Jahrhunderts Code, test and Fix Errors hat sich als absolut unzureichend herausgestellt. Hier die Gründe dafür:
- In existierendem Code Fehler zu beheben, war allzu oft nur möglich unter Anfügen sog. Rucksäcke (zusätzlicher Code, der vorher Vergessenes nachträgt, sich in existierende Codestruktur aber nicht so richtig einfügen will). Daraus hat man gelernt: Es bedarf einer Entwurfsphase, die verhindert, dass mit dem Schreiben von Code begonnen wird noch bevor alle Anforderungen und Lösungsideen ausreichend verstanden sind.
- Man hat zudem gelernt, dass selbst gut realisierte Software vom Benutzer oft nicht akzeptiert wurde und es daher v o r w e g einer Definitionsphase bedarf, an deren Ende Benutzer und Entwickler Einigkeit darüber erzielt haben sollen, wie das entstehende Produkt auszusehen hat — und welche Funktionalität es haben muss — damit die Nutzer es gut akzeptieren und wirklich gerne nutzen.
- Bis heute noch steht man immer wieder vor der Situation, dass entstandene Software (als Black Box) nur allzu ungenügend testbar ist —
und daher auch wirklich vor Inbetriebnahme viel zu wenig getestet wurde. Konsequenz daraus:
Wo Software entsteht wird, muss Testbarkeit mit implementiert werden.
Dass der Auftragnehmer sie kaum je explizit fordert, liegt einfach daran, dass er — allzu blauäugig — der Kompetenz des Auftragnehmers zu sehr vertraut. Der aber will Kosten sparen (bzw. im Preis günstig sein, um das Projekt zu gewinnen) und plant entsprechenden Aufwand so gut wie NIE mit ein.
Dies wird kaum je berücksichtigt, weswegen es dann auch zuweilen zu ganz fürchterlichen Projektkatastrophen kommt, die Millionen verschlingen und alle am Projekt Beteiligten als inkompetent dastehen lassen.
Der etwa um die Jahrtausendwende entstandene Wunsch nach zunehmend schneller abwickelbaren Projekten erfordert vorher nicht dagewesene Agilität, darf aber dennoch auf keinen Fall dazu führen, die Definitionsphase weniger ernst zu nehmen. Es wird nun aber wichtig, sie ganz grundsätzlich als niemals abgeschlossen zu betrachten.
Was sie als Ergebnis zu liefern hat — genaue Dokumentation sämtlicher Anforderungen an die vom Entwickler abzuliefernde Lösung — muss laufend überdacht, entsprechend fortgeschrieben und dem zufolge auch ständig mit dem Auftraggeber neu abgestimmt werden. Das heute mit Sicherheit beste Vorgehensmodell für Software-Entwicklung — SST: Specify, Subcontract, Test — trägt gezielt beiden dieser Notwendigkeiten Rechnung: Es vergisst keine der seit 1970 gemachten Erfahrungen, kann aber dennoch auch den Wunsch nach zunehmend mehr Agilität wirklich berücksichtigen.
Erfolgreich einsetzbar ist dieses Modell vor allem dann, wenn das Anforderungsdokument extrem modular (also wirklich mühelos fortschreibbar) aufgebaut wird: Es darf auf keinen Fall mehr die klassische Aufsatzform haben, sondern muss aus einer Menge hierarchisch angeordneter Seiten bestehen, die man Specification, Collaboration oder Responsibility Cards nennt und deren jede man stets relativ leicht austauschen sowie gut (und noch dazu automatisch) verlinkt in HTML präsentieren kann.
Der ihre Transformation nach HTML bewirkende sowie die Verlinkung erzeugende Mechanismus wird zudem in der Lage sein, Konsistenz sicherzustellen sowie auf noch bestehende Dokumentationslücken aufmerksam zu machen.
Leider hat dieses Verfahren sich noch keineswegs auf breiter Basis durchgesetzt. Die wenigen Firmen, die es inzwischen konsequent einsetzen, finden es dennoch weit nützlicher als alles, was sie vorher hatten. Der Systemintegrator BFE etwa dokumentiert mit einer spezifischen Variante dieses Verfahren äußerst erfolgreich und weit transparenter als jemals vorher Broadcasting Prozesse.
Siehe übrigens auch, was BFE über gezieltes Anforderungsmanagement zu sagen weiß.
stw5811AEV — Agile . Entwicklung . Vorgehensmodell — News?
Mehr + B G E + S H A + More