Balancierte Extreme in der Software-Entwicklung

25.07.1980

Hans-Joachim Habermann Mitarbeiter der GMO, Hamburg

Extreme haben auf mich schon immer einen besonderen Reiz ausgeübt. Ob es nun der Flug zum Mond oder die "Reise" ins Innere der Atome ist. Jedesmal stand am Anfang die Idee eines aus der Norm gerückten Menschen. Dieser Mut zum Ver-rücken eines scheinbar festen Bildes hat den Menschen wertvolle Erkenntnisse gebracht. Wir haben aber auch gelernt, daß sich unser "normales" Leben eben nicht in den Extremen abspielt, sondern in einer dem Menschen angemessenen Mitte (="Norm") bewegt.

Universelle Sprache fasziniert

In gleicher Weise bin ich während meines Studiums fasziniert gewesen von den Ideen einer universellen Programmiersprache, der vollautomatischen Sprachübersetzung und zentralen Universalrechnern, die gleichermaßen technisch-wissenschaftliche wie auch kommerziell-verwaltungstechnische Aufgaben lösen können sollten.

Diesen hohen Erwartungen folgte die Zersplitterung der Programmiersprachenentwicklung in ganz spezielle Sprachen, am besten für jede Anwendung eine - so stellte es sich mir dar.

Die Übersetzung natürlicher Sprache spezialisierte sich auf fachspezifische Insellösungen eines vorgegebenen Kontextes und der Zentralrechner-Euphorie folgte die Welle der dezentralisierten Systeme, wobei möglichst jeder sein Eigenes erhalten sollte.

Auch die Beschäftigung mit diesen Ansätzen hat uns wertvolle Erkenntnisse gebracht. Vor allem die, daß in Zukunft die Entwicklung weniger extrem und hektisch, somit für die Betroffenen effektiver verlaufen dürfte.

Die Erfahrungen im Bereich der Entwicklung von Anwendungssystemen sind ähnlich verlaufen: Es begann mit meist guten Einfällen, aber oft unstrukturierten Realisierungen in Maschinencode oder Assembler unter der Devise: "So wenig Speicherplatz wie möglich, so schnell wie nötig". Die Wartungskosten waren wohl erst den wenigsten bewußt. Überhaupt standen für viele die technischen Aspekte des DV-Design im Vordergrund - der Anwender bekam eine Lösung vorgesetzt, im Extrem vielleicht ohne daß sie den realen Problemen angepaßt war.

Im Laufe der Zeit wurde die Perspektive länger, spätestens dann, wenn die Wartungskosten begannen die Entwicklungskosten zu übersteigen. So hielten höhere Programmiersprachen (Cobol), strukturiertes Vorgehen (SP) und Einsatz von Werkzeugen (ET, NP, Generatoren) ihren Einzug in die Systementwicklung .

Dem Anwender brachte diese Besinnung die Mitbestimmung: Partizipierte Systementwicklung, besonders in den Phasen Vorstudie (Pflichtenheft) und Funktionen-Design.

Die Systementwicklung als Ganzes geht jedoch einer zunehmenden Bürokratisierung entgegen. - Müssen wir auch hier erst das Extrem auskosten? Oder können wir Erkenntnisse aus der dynamischen Organisationsentwicklung übertragen?

Richtiger Realitätsausschnitt

Lernen wir doch aus den Erfahrungen in anderen Bereichen unseres Lebens! Die Entwicklung eines Systems, das den Menschen gerecht werden soll, muß die Balance auf vielen Ebenen halten:

- Für den Menschen, aber wirtschaftlich vertretbar.

- Strukturiert, transparent, aber nicht starr zerbrechlich.

- Verwaltet, geordnet, aber nicht bürokratisch.

- Umfassend in der Grundfunktionen, aber nicht kleinlich detailliert. (Jackson: "Richtigen Ausschnitt der Realität modellieren! ").

- Dezentral, aber nicht zersplittert (zum Beispiel Kennzahlen auf Zentralrechner) .

- Schutz der Privatphäre, ohne Schaden für die Allgemeinheit.

Sicher gibt es weitere Aspekte die zu beachten sind Jedes Team sollte sich am Anfang einer Entwicklung seine Ziele deutlich machen und Prioritäten setzen. Nur so wird man unberechtigte Wünsche sicher zurückstellen.

Da die Anwender in den Fachabteilungen immer kritischer werden (auch bis zum Extrem?), zeichnet sich die Entwicklung von Systemen ab, die den Menschen soviel Routinearbeiten wie möglich abnehmen, ohne ihn jedoch in seinen kreativen, eigentlichen Aufgaben zu behindern.