Spezifikation und ihr Umfeld

Die Spezifikationsmethoden sind nur ein Teilaspekt, ohne deren richtige Anwendung zwar jede Systementwicklung zum Scheitern verurteilt ist, die aber andererseits für sich allein auch kein Gelingen garantieren. Der Erfolg hängt vom Zusammenspiel etlicher weiterer Faktoren ab. Der Erkenntnisprozeß über diese Zusammenhänge nahm Jahrzehnte in Anspruch und ist noch nicht abgeschlossen. Er äußert sich in immer neuen Reizwörtern und Herangehensweisen.

Deswegen fängt diese Zusammenstellung mit einem historischen Abriß über die Entwicklung an und zeigt, wie immer mehr dieser Einflußfaktoren als relevant erkannt worden waren. Die Methoden wurden deswegen immer ausgefeilter, aufwendiger und umfassender. Das terminologische Gerüst wuchs, weil immer mehr Begrifflichkeiten in eine konsistente Terminologie gebracht werden mußten. Anmerkungen zu einigen Spezifikationsmethoden folgen. Zum Abschluß wird das weitgespannte Netz der Abhängigkeiten beleuchtet.

geschichtlicher Abriß

Nach dem ‘Urknall’ - also der Erfindung der ersten frei programmierbaren Rechenautomaten durch Zuse und fast zeitgleich Eckert, Mauchly, Goldstine, von Neumann u.a. - waren die IT-Abteilungen der Bibliotheken wüst und leer. Es gab keine Bücher, wie man entwickeln solle, und schon gar keine Bücher, nach welchen Verfahren und Richtlinien denn so ein “Programm” herzustellen sei.

So entwickelte man nach Bedarf und die Entwicklungen dauerten solange, wie sie brauchten und kosteten, was ausgegeben wurde. Natürlich konnte es nicht ausbleiben, daß manche hoffnungsfroh begonnenen Entwicklungen nie zu einem Ergebnis führten und viele andere die Verantwortlichen über die Kosten erschrecken ließen. Der menschliche Organisationsdrang erkannte das als Problem und versuchte, den Wildwuchs in geordnete Bahnen zu lenken. Zunächst versuchte man natürlich, das Problem zu klassifizieren. Man stellte fest, daß man mit grundsätzlich neuen Zusammenhängen zu tun bekommen hatte und rief einen neuen wissenschaftlichen Studiengang ins Leben: die Informatik. {1}  Außerdem stellte man fest, daß schon viel zu viel schief gegangen war und rief eine Krise aus: die Software-Krise. {2} 

Während vorher Verbesserungen eher in kleinen Schritten in die Praxis eingingen, versuchte man sich jetzt im großen Wurf. Ein theoretischer Über- oder Unterbau (je nach Standpunkt) mußte her: die Zeit der ‘Methoden-Gurus’ hatte begonnen.

== IN ARBEIT ==
_ SA Phasenmodelle (Wasserfall) strukturierte Methoden OO Objektorientierte Methoden UML V-Modell agile Methoden Anwendungsgebiete von Spezifikationsmethoden Geschichte Warum Projekte trotzdem scheitern (nicht systematisch angewandt; nur Formalismus, aber kein Geist (Methodenbürokratie); keine Sicherheitsmargen (im Gegensatz zu physikalischen Gesetzen), Ausreizen über alle Grenzen) Der Faktor Mensch (Dueck) Das Problem ist vielschichtig und tangiert viele Interessen in einer Organistation: HW & SW, Prozesse (Geschäftsprozesse), Organistation (Projekt oder Produkt), Finanzen, rechtliche Rahmenbedingungen, Schnittstellen nach außen, Standardisierung Die Unsicherheit ist groß; ständig erleben wir neue Trends und neue Euphorie; die Paradigmen werden laufend umgekrempelt. Irgendwie erinnert das Szenario an die Lage der Physik: von 3 Elementarteilchen seit dem Bohr'schen Atommodell sind wir mittlerweile bei einer verwirrenden Vielfalt angekommen, die größtenteils alles andere als 'unteilbar' sind. Schien es zu gewissen Zeiten möglich, die Anforderungen vollständig in einer sowohl für Anwender als auch Entwickler verständlichen und hinreichend präzisen Sprache zu beschreiben, haben wir uns zwischenzeitlich von diesem Ziel recht weit entfernt. Die SA schien - bei hinreichender Sorgfalt durch den Analytiker und etwas gutem Willen durch den Anwender - eine für beide Seiten beherrschbare und verbindliche Spezifikation zu ermöglichen. Mit der OOA mußte man sich von dieser naiven Vorstellung verabschieden. So kehrt zwangsläufig wieder etwas vom Kunsthandwerker zurück: die Handlanger machen die Routinearbeit, der Künstler das Besondere. Die Herausforderung an das Management besteht darin, zu erkennen, was Routine ist und was einen Könner erfordert. Trend zu Standardsoftware und zu einheitlicher Middleware: die Entwickler oder die Anwender (oder beide) machen die Analyse so nebenbei mit; die spezielle Rolle des Analytikers wird oft gar nicht mehr besetzt. Effekte: Programmpakete werden immer monströser, obwohl im Vergleich zur Vorgängerversion gar nicht so viele Funktionen dazugekommen sind. Das hat sicher mit der Entwicklungsmethodik zu tun: immer mehr Standardklassen werden eingebunden. Einerseits soll der vorhandene Code wiederverwendet werden, um Entwicklungszeit und Testzeit zu sparen, andererseits ist natürlich auch der Speifikationsaufwand für komplett neue Grundfunktionen zu vermeiden. Die Pakete werden immer komplexer und die Weiterentwicklung ist nur noch beherrschbar, wenn auf bekannte Grundbausteine zurückgegriffen wird. Insofern hat sich die Informatik tatsächlich den klassischen Ingenieurwissenschaften angenähert.

einzelne Methoden

=== IN ARBEIT === Modellierungswerkzeuge: Aris (IDS Scheer) :: komplex, relationale DB; untersucht Prozeß Bonapart (Pikos) :: objektorientiert, Petri-Netze; untersucht Informationsfluß UML 2 Neu: Standard zum Austausch von Diagramminformationen (DI) zwischen Werkzeugen. Erste Implementationen gibt es bereits.
Gentleware mit Webseite UML-Derby: Übersicht über die UML-Werkzeuge am Markt.

Das Umfeld des Entwicklungsprozesses



   zur Wurzel!