Endstation Wien - Harry M. Sneed - E-Book

Endstation Wien E-Book

Harry M. Sneed

0,0

Beschreibung

"Endstation Wien" ist erlebte IT-Geschichte von den Anfängen der EDV in 1970 bis zum heutigen Einstieg in die sogenannte Digitalisierung. Der Autor – Harry Sneed – hat als reisender Analytiker, Entwickler, Tester und Projektleiter im mitteleuropäischen Raum an mehr als 50 Projekten teilgenommen. Nebenbei hat er an 9 verschiedenen Hochschulen und Fachhochschulen unterrichtet und mehr als 450 Fachartikel in deutscher und englischer Sprache verfasst. In diesem, seinem 23. Buch zieht er Bilanz über seinen beruflichen Lebens- bzw. Leidensweg. Es heißt "Endstation Wien" weil dieser Weg dort zu Ende geht. Der Autor beendet sein berufliches Leben in Wien als Tester und Re-engineer in zweitrangigen Projekten. In Deutschland schon längst abgeschrieben, konnte er in Wien noch lange nach seinem Pensionsalter weiterarbeiten. In dem vorliegenden Buch werden die unterschiedlichsten Software- Projekte in den unterschiedlichsten Fachbereichen beschrieben und ausgewertet. Bis zum Wende im Jahre 1989 waren die Projekte meistens Entwicklungsprojekte. In dem Jahr hat der Autor sich geschworen, nie wieder Anwendungssoftware zu entwickeln. Danach sind die Projekte nur noch Wartungs-, Migrations- und Testprojekte. Der Autor geht der Frage nach, warum Projekte scheitern und spart nicht mit Selbstkritik. Oft scheitern Projekte, weil sie falsch aufgesetzt sind, aber ebenso oft scheitern sie an den Fehlentscheidungen der Projektverantwortlichen. Die Menschen sind durch die Softwaretechnologie schlicht überfordert. Wir brauchen viel mehr Wissen und Erfahrung, um den Projekterfolg auf diesem Gebiet zu sichern. Das Buch ist ein bescheidender Beitrag dazu, zumindest was die Dokumentation der Erfahrung anbetrifft.

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern
Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 488

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android
iOS
Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Inhaltsverzeichnis

Vorwort

Wien wartet

Datenverarbeitung in den 70er Jahren

2.1 Anfang bei der H.I.S in Hannover

2.2 Projekte in der deutschen Hochschulverwaltung

2.3 Veröffentlichungen bei der H.I.S.

2.4 Das Kommunale Verwaltungsprojekt in Göttingen

2.5 Projekte bei Siemens in München

2.6 Prüfstand - das erste deutsche Testwerkzeug

2.7 Vom Entwickler zum Tester

2.8 Das Caroline Testprojekt der Firma Spardat in Wien

Das Budapester Testlabor

3.1 Zum Ursprung des Testlabors

3.2 Meine Vision eines Software Testlabors für das I.T.S Projekt

3.3 Ausflug in eine fremde Welt

3.4 Die Vision wird Wirklichkeit

3.5 Der Modultestprozess mit Prüfstand

3.6 Bilanz des I.T.S. Modultestprojektes

3.7 Rausschmiss von Siemens

3.8 Probleme mit dem Staatssicherheitsdienst in Ungarn

3.9 Das unrühmliche Ende des I.T.S. Projektes

Die SoftOrg Toolentwicklung in Ungarn

4.1 Der Software Lebenszyklus zu Beginn der 80er Jahren

4.2 Das SoftOrg Projekt wird aufgestellt

4.3 Die Entwicklungswerkzeuge – von den Anforderungen zum Code

4.4 Die Testwerkzeuge – vom Code zur Abnahme

4.5 Das übergeordnete Lebenszyklus Management Werkzeug

4.6 Die unvollendete Vision

Softwareentwicklung im Deutschland der 80er Jahre

5.1 Kundenspezifische Testwerkzeugentwicklung

5.2 Software Reengineering bei Bertelsmann

5.3 SoftSpec schafft den Durchbruch

5.4 Der omnipräsente Konflikt zwischen IT und Fachbereich

5.5 Mein unfreiwilliger Abgang von BMW

5.6 Die Bundesbahn setzt Softorg ein

5.7 Programmierung bei Krupp-Atlas

5.8 Der große Test bei Thyssen Stahl

5.9 Der Test eingebetteter Realtime Software

5.10 Das unglückliche Ende des Thyssen Projektes

5.11 Der Verlust von Bertelsmann als Stammkunde

5.12 Verlegung des Testbetriebes nach München

5.13 Der Umstieg auf Reengineering

Die Wende

6.1 Konsequenzen aus der Niederlage bei Thyssen-Stahl

6.2 Die letzten Anwendungsentwicklungsprojekte

6.3 Das Ende des Sozialismus zeichnet sich ab

6.4 Eine Welt bricht zusammen

6.5 Das Ende der Mainframe-Entwicklung

6.6 Der Versuch auf den PC umzusteigen

6.7 Die Abwicklung des SoftOrg Geschäfts

6.8 Die EU-Forschungsprojekte

6.9 Vom Praktiker zum Forscher

Als Reengineer in der Schweiz

7.1 Ein Anruf aus der Schweiz

7.2 Das Promega Migrationsprojekt

7.3 Das Kehraus Reverse Engineering Projekt

7.4 Weitere Projekte in Zürich

7.5 Ein missglückter Abstecher nach Deutschland

7.6 Das große ABACUS Migrationsprojekt

7.7 Die Inder kommen

Migrationsprojekte am Ende des Jahrhunderts

8.1 Das FISKUS Projekt

8.2 Das SKA Assembler Migrationsprojekt

8.3 Migrationsplanung für die bayerische Versorgungskasse

8.4 COBOL Reengineering für das deutsche Auswärtige Amt

8.5 Assembler Migration bei der bayerischen Kommunalverwaltung

8.6 Anwendung der Softwarekapselungstechnik bei der Sparkasse Informatik

Der Ruf nach Wien

9.1 Rückkehr nach Wien

9.2 Als Test-Tool Entwickler im GEOS Projekt

9.3 Impaktanalyse der Wartungsaufträge

9.4 Aufwandsschätzung der Wartung und Weiterentwicklung

9.5 Produktivitätsmessung und Verletzung des Österreich. Arbeitsschutzes

9.6 Verbahnung in die Testabteilung

9.7 Abschied von der SDS

9.8 Beginn meiner Lehrtätigkeit an der Hochschule

Neuanfang als Tester in Wien

10.1 Fehlersuche in einem Telekommunikationsbetrieb

10.2 Regressionstest eines migrierten DotNet Systems

10.3 Der Test eines Landes-Webportals in Dresden

10.4 Testmessung für eine Versicherung an der Mosel

10.5 Qualitätssicherung in einer mitteldeutschen Bundesbehörde

10.6 Der Test eines Data Warehouse Systems

10.7 Der Test eines Internet-Wettsystems

10.8 Testplanung für die Wiener Krankenhäuser

10.9 Meine letzten Testplanungsprojekte

Vom Tester zum Vermesser

11.1 Das größte Messprojekt aller Zeit

11.2 Produktivitätsmessung in einer Java Umgebung

11.3 Migrationsaufwandsschätzung eines 4GL Systems

11.4 Produktivitätsmessung in einer DotNet Umgebung

11.5 Schätzung der Wartungskosten für ein PPS System

11.6 Der Software Turm von Babel

11.7 Weiterentwicklung der Messwerkzeuge

11.8 Das Ziel ist die Vergleichbarkeit

Das Ende in Wien

12.1 Umsetzung von BULL-COBOL in Java für den Wiener Flughafen

12.2 Die Umstellung auf Web Services

12.3 Mein letztes Projekt für die ANECON

12.4 Zwischen drei Städten

12.5 Mein Abgang von der ANECON

12.6 Wohin mit den älteren Softwareentwicklern

12.7 Fünfzig Jahre Software Engineering

12.8 Wien hat auf mich gewartet

Referenzen

Vorwort

Das vorliegende Buch schildert die Geschichte der deutschsprachigen IT-Welt von den Anfängen bis zum heutigen Tag aus den Augen eines Zeitzeugen. Ich kam 1970 als junger amerikanischer Programmierer nach Deutschland. Ich hatte schon vorher drei Jahren im amerikanischen Marine-Ministerium als Systemanalytiker gearbeitet. Begonnen habe ich hier als Entwickler in der deutschen Hochschulverwaltung. Später bin ich zu Siemens rüber gewechselt und habe dort in der Datenbankentwicklung mitgearbeitet. Von Siemens aus bin ich nach Budapest gegangen um dort ein Software Testlabor für Siemens Projekte aufzubauen. Daraus ist später eine Software-Toolfabrik hervorgegangen in der CASE Werkzeuge für den deutschen Markt entwickelt wurden. Mit jenen Werkzeugen und dem SoftOrg Lebenszyklusmodell bin ich in mehrere namhafte deutsche Unternehmen hineingekommen und half dort die IT-Welt zu gestalten. In den 80er Jahren des vorigen Jahrhunderts erlebte ich hautnahe das Projektgeschehen in den bundesdeutschen Großbetrieben, mal als Held, mal als Schurke. Ich nahm Teil an den innerbetrieblichen Machtkämpfen und wurde nicht selten deren Opfer. Das Buch schildert nicht nur die damalige Technologie, sondern auch die vorherrschenden Methoden und Vorgehensweisen jener Zeit. Ich habe sie alle durch gemacht angefangen mit der strukturierten Programmierung, über CASE und 4GL Sprachen, bis zur objektorientierter Programmierung. Meine Erfahrungen habe ich in 23 Büchern und über 400 Fachartikel festgehalten.

Ich war lange Zeit ein Wanderer zwischen zwei Welten – der sozialistischen in Ungarn und der marktwirtschaftlichen in Deutschland. In Ungarn war ich Entwicklungsleiter, in Deutschland Projektberater. Mit der Wende verlor ich meine Entwicklungsunterstützung durch den ungarischen Staat und musste dort die Produktentwicklung einstellen. Danach bin ich in die Schweiz gegangen um dort Reengineering-Projekte für eine Großbank durchzuführen. Dort habe ich eine andere IT-Welt miterlebt – eine straff organisierte Welt. Über sieben Jahre habe ich in der Schweiz an vorderster Front der Softwaremigration mitgewirkt. Es war beruflich meine erfolgreichste Zeit. Nebenbei blieb ich weiterhin in der wissenschaftlichen Welt aktiv sowohl auf der deutschen Szene durch die GI und auf der internationalen Szene durch die IEEE Konferenzen. 1997 musste ich die Schweiz verlassen. Nach einem kurzen Aufenthalt in Deutsch bekam ich 1998 eine Einladung nach Wien zu kommen und dort bin ich auch bis zum heutigen Tag hängen geblieben, nicht weil ich Wien so mag, sondern weil die Wiener die Einzigen sind die mich beschäftigt haben.

Der Titel „Endstation Wien“ ist an dem Buch von Tom DeMarco und Tim Lister angelehnt. Das letzte Kapitel in ihrem Buch heißt „Wien wartet auf Dich“. Eigentlich geht es in diesem Buch darum den Leidensweg eines Softwareentwicklers und –Testers zu schildern. Der Wandel der IT-Welt ist hier anhand von Projekterfahrungen geschildert – gute und schlechte. Leider dreht sich die IT-Welt oft im Kreis. Auf der einen Seite ändert es sich, auf der anderen Seite werden dieselben Fehler wiederholt - La plus change, la plus de meme chose. Um aus diesem Teufelskreis herauszubrechen muss die nächste Generation aus den Erfahrungen der letzten lernen. Die entscheidende Frage ist ob es sich lohnt an diesem Wettbewerb teilzunehmen. Jeder muss das für sich entscheiden. Ich habe mich daran beteiligt und ich bereue es nicht, obwohl ich in Wien als alter Tester gelandet bin. Es ist nicht das Ende was zählt, sondern der Weg dahin.

Harry M. Sneed

Arget, 2017

1 Wien wartet

Die erste Ausgabe eines Buches mit dem Titel „Peopleware – Productive Projects and Teams“ von Tom De Marco und Tim Lister erschien in New York im Jahre 1987 [DeMa87]. Die zweite Ausgabe erschien 10 Jahre später. In dem Buch geht es darum, Menschen in IT-Projekten zu führen. De Marco und Lister waren nämlich der Meinung, dass die meisten Probleme in IT-Projekten weniger technischer Natur, sondern viel mehr menschlicher Natur sind. Sie entstehen durch fehlende Motivation, fehlende zwischenmenschliche Kommunikation und fehlende Führung. Die Menschen in einem IT-Projekt werden nicht geführt, sondern nur verwaltet und wenn sie geführt werden, dann allzu oft in eine falsche Richtung. Die beiden Autoren mit ihrer 30jährigen Projekterfahrung haben es sich vorgenommen, ein Buch für IT-Projektleiter zu schreiben, die sie auf die gefährlichsten Tücken und die wichtigsten Erfolgsfaktoren hinweist. Das Buch war in Amerika ein großer Renner. Deshalb hat der Hanser Verlag bereits 1990 entschieden, das Buch ins Deutsche zu übersetzen. Der Übersetzer war der renommierte Software-Berater Dr. Peter Hruschka aus Wien, der lange Zeit in Deutschland mit der CASE Entwicklung beschäftigt war und der später zu der Beratungsassoziation von De Marco und Lister, das Atlantic Guild zugestoßen ist. In Anbetracht der vielen soziologischen und psychologischen Aspekte, die in dem Buch behandelt werden, hat Hruschka es ziemlich frei übersetzt und der mitteleuropäischen Denkweise angepasst. Der neue Titel hieß: „Wien wartet auf dich! Der Faktor Mensch im DV-Management“. Der deutsche Titel wurde aus einem Kapitel des Buches mit der Überschrift „Vienna is waiting on you“ abgeleitet. Das Kapitel erzählt von gescheiterten Projektleitern, die in der Psychologie landen, weil sie die Prinzipien, die in dem Buch propagiert werden, missachtet haben.

In der zweiten Ausgabe, die 1999 erschien, wurde ein neuer Teil hinzugefügt, ein Teil über Prozessverbesserungsprogramme, lernende Organisationen, interner Wettbewerb und Projektpolitik. Dieser neue Teil trug den Titel “Wien wartet noch immer“ [DeMa99]. Was aber, um Gottes Willen, hat Wien mit überarbeiteten Projektleitern zu tun? Warum nicht New York oder San Francisco, Berlin oder Zürich? Warum ausgerechnet Wien, wo die Wiener von der Mentalität her am wenigsten unter solchem Stress leiden. Sie haben zwar viele Wehen, über die sie ständig raunzeln aber diese Krankheit bleibt ihnen erspart. Man fragt sich also, warum De Marco und Lister Wien als Endstation ausgewählt haben.

Über diese Frage könnte man eine Doktorarbeit schreiben. Es gibt verschiedene Interpretationen. Alle gehen auf ein Lied von Billy Joel aus den 70er Jahren zurück, eine Zeit in der viele Protestsänger den Sinn der Arbeit in Frage stellten.

„Da kommt ein Tag in Wien“

übersetzt von Ulla Meinecke

Langsam, du verrücktes Kind!

Dein Ehrgeiz ist zu sehen wo die Juwelen sind.

Doch sag, wenn du so gut bist,

wovor hat du dann so viel Angst? hmm

Ey, wo brennt's? Wozu der Alarm?

Du zündest alles an.

Doch es wird noch nicht warm.

Du hast so viel zu tun, dass du endlose Tage verlangst. hmm

Da kommt ein Tag, da zählt nur heiß und kalt.

Da wirst du sein was du willst oder du wirst nur alt.

Wenn du nur Sterne siehst fällst du auf's Gesicht. hmm

Und warum merkst du nicht:

Wien wartet auf dich.

Langsam, du machst es gut!

Du kannst nicht ernten bevor die Zeit das ihre tut,

obwohl es so romantisch ist auf Messers Schneide

heut' Nacht, heut' Nacht.

Zu lang mit Vollgas gehst du drauf.

Du bist dir so weit voraus, dass du verlierst was du brauchst.

Obwohl du weißt was dir fehlt kannst du nicht seh'n was du hast!

Du hast, hast deinen Stolz und deine Leidenschaft.

Doch nur ein Narr kann glauben er hat endlos Kraft.

Mach's gut! Doch steh' nicht da und sag: Es werde Licht!? hmm

Und warum merkst du nicht:

Wien wartet auf dich.

Langsam, du verrücktes Kind!

Lass das Telefon geh'n und gib dir Sonne und Wind.

Es ist okay für ein paar Tage nur ein kleines Licht. hmm

Und warum merkst du nicht:

Wien wartet auf dich.

Kommt ein Tag, da zählt nur heiß und kalt.

Da wirst du sein was du träumst oder du wirst nur alt.

Wenn du nur Sterne siehst fällst du auf's Gesicht. hmm

Und warum merkst du nicht:

Wien wartet auf dich.

Und warum merkst du nicht:

Wien wartet auf dich! [Mein77]

Es gab in der 70er Jahren viele Lieder dieser Art. Die deutsche Version dieses Liedes gibt Hruschka in seiner Übersetzung wieder:

„Aber du verstehst, wenn dir jemand die Wahrheit sagt,

du kannst haben, was du willst, oder einfach nur alt werden,

du wirst vielleicht ins Gras beißen, bevor du die Hälfte der Strecke erreichst

Wann merkst du endlich, dass Wien auf dich wartet!“

Laut Hruschka, der es als geborener Wiener wissen sollte, ist das Wien, das in dem Lied von Billy Joel auf dich wartet, die letzte Station in einer persönlichen Reise. Wenn du dort ankommst, ist alles vorbei. Warum aber Wien als Endstation eines arbeitsreichen Lebens? Dafür gibt es mindestens drei Erklärungen.

Zum einen haben viele Amerikaner Wien als Reiseziel im Auge. So wie viele Deutsche sich eine Reise nach Bangkok wünschen, wünschen viele Amerikaner sich eine Reise nach Wien, aber nicht wegen der schönen Frauen, die es dort gibt, sondern wegen der vielen Schlösser. Außerdem drängen ihre Ehefrauen sie dazu, weil sie in einem Wiener Café sitzen und echte Sachertorte essen wollen. Die Nachbarfrau war auch schon dort und es darf nicht sein, dass sie überall über ihre Erlebnisse erzählt und die eigene Frau kann nicht mitreden. Nach dieser Auslegung ist Wien ein fernes Reiseziel, das wegen Überbeschäftigung immer wieder verschoben wird.

Zum zweiten ist Wien der Geburtsort der Psychotherapie. Welcher Platz wäre besser geeignet für die Behandlung eines arbeitssüchtigen Projektleiters, der mit seinen Nerven am Ende ist, als die Heimat von Sigmund Freud und Alfred Adler. Man musste schnell nach Wien zur Behandlung noch vor dem endgültigen Nervenzusammenbruch. So geht das Lied von Billy Joel weiter:

„Sei nicht so verrückt, schalte einen Gang zurück,

lege den Hörer ab und verschwinde für einige Zeit.

Das ist schon ok, du kannst dir ein, zwei freie Tage leisten,

wann merkst du endlich, dass Wien auf dich wartet.“

Also, was auf dich wartet, ist die Psychiatrie, die in Wien ihren Ursprung hatte. In diesem Zusammenhang gehen De Marco und Lister auf die Grenzen des Menschen ein. Man darf weder von sich noch von seinen Projektmitarbeitern unmenschliches erwarten. Jeder stößt an seine Grenzen. So schreibt das Autorenduo „Kein Mensch kann wirklich viel mehr als vierzig Stunden arbeiten, zumindest nicht über längere Zeiträume hinweg und mit der Intensität, die für kreative Arbeit erforderlich ist...“ Und wenn er das tut, denn endet er früher oder später in der Psychiatrie, bzw. in Wien.

Dies ist eine unbewiesene Hypothese. Früher haben alle Menschen weit mehr als 40 Stunden die Woche gearbeitet und sind nicht daran erkrankt. Wer 60 Stunden oder mehr die Woche arbeitet, ist noch lange kein Fall für den Psychiater. Es kommt darauf an, wie er zu der Arbeit steht und was er mit den restlichen Stunden macht. Ich habe in den letzten 40 Jahren kontinuierlich mehr als 50 Stunden die Woche gearbeitet. Vielleicht bin ich seelisch krank, das merkt man selber nicht, aber beim Psychiater bin ich noch nicht gelandet, auch wenn mich das Leben nach Wien geschlagen hat.

Zum dritten ist Wien, zumindest in den 70er Jahren, als das Lied „The Stranger“ von Billy Joel entstand, eine Grenzstadt gewesen [Joel75]. Hinter Wien kam gleich der Eiserne Vorhang. Die westliche Zivilisation hörte auf. Wien war in diesem Sinne eine wahre Endstation. Hier war die Reise zu Ende, zumindest für westliche Touristen. In dem Lied von Billy Joel kommt das zum Vorschein.

„Tritt doch ein wenig auf die Bremse, du bist ohnehin gut.

Du kannst nicht alles jetzt erreichen, deine Zeit kommt noch

obwohl es draußen an der Grenze sicherlich spannend ist.

Wann merkst du endlich, dass man auf dich wartet?“

Welche Grenze ist hier gemeint? Es kann wohl nur die hinter Schwechat gemeint sein. Dort endet die gute Welt, so wie es die Amerikaner gekannt haben, und es beginnt das Reich des Bösen sowie es Präsident Reagan betitelt hat. Also, gehe nicht über Wien hinaus, auch wenn es sicherlich spannend ist. In Wien müssen alle aussteigen. Es ist die Endstation.

Eine letzte Erklärung kommt von Billy Joel selbst. Als Autor des Liedes musste er es am besten wissen. Das Lied hat er gerade nach einem Besuch in Wien, wo sein Vater wohnte, geschrieben. Dort hat es ihn sehr beeindruckt, wie respektvoll alte Menschen behandelt werden. Er meinte, dort könnte man als alter Mensch gut leben. Also braucht man keine Angst vor dem Alter zu haben, nur ab nach Wien. Dort kann man sein Lebensende genießen. Wien, als Paradies für Rentner. Wer das weiß, muss sich in jüngeren Jahren nicht abhetzen, denn Wien wartet auf ihn.

Eigentlich passen alle diese Interpretationen. Wien ist auf jeden Fall ein lohnenswertes Reiseziel, vor allem für gestresste amerikanische und asiatische Manager. Dort werden sie von der Last der Gegenwart durch eine Reise in die Vergangenheit abgelenkt, denn Wien riecht nach dem Vergangenen. Die Stadt ist ein einziges Denkmal für eine glorreiche Vergangenheit. Wer also der Gegenwart entkommen will, der reist nach Wien. Wien symbolisiert nach Stephan Zweig die Welt von Gestern [Zweig82].

Wer eine psychotherapeutische Behandlung braucht, ist ebenfalls in Wien gut aufgehoben. Pro Kopf der Bevölkerung hat Wien mehr Psychiater als irgendeine andere Stadt einschließlich New York. Das soll nicht heißen, dass Wien so viele psychisch Kranke hat, obwohl die Wiener in der Tat zu Depressionen neigen und die Selbstmordrate hoch ist. Es liegt eher an der staatlichen Krankenversicherung, die jeden gegen alles versichert. In Amerika können die wenigsten es sich leisten zum Psychiater zu gehen, in Wien kann es sich ein jeder leisten, eine Folge von 60 Jahren sozialdemokratischer Herrschaft.

Auch das mit der Grenze hat was für sich. Hinter Wien beginnt nicht mehr das Reich des Bösen, sehr wohl aber der wilde Osten. Bis Wien herrscht Recht und Ordnung. Darüber hinaus folgt Armut und Kriminalität. Nach dieser Ansicht ist Wien sehr wohl eine Grenzstadt. Als Einer, der fast wöchentlich zwischen Wien und Budapest pendelt, werde ich an den Unterschied im Lebensstandard ständig erinnert. Hier gibt es nach wie vor zwei Welten, die zwar nur durch einen Grenzstreifen getrennt sind aber doch so unterschiedlich sind wie Tag und Nacht. Alle hoffen, dass dies sich mal ändert aber bis jetzt ist das nur eine Vision geblieben.

Schließlich haben wir Wien als Paradies für Rentner. In der Tat werden alte Menschen dort recht gut behandelt und nicht wie in vielen anderen Orten missachtet. Gescheiterte IT-Projektleiter können sicherlich dort noch einen Platz unter einer Brücke mit den restlichen Sandlern finden, aber so gut haben sie es auch nicht. Und weil jeder Wiener weiß, dass dieser Zustand auf ihn wartet, sehnt er sich danach. Statt sich mit dem jeweiligen Projekt zu beschäftigen, beschäftigt er sich lieber mit seiner Rente und jeder IT-Manager neigt dazu, die Probleme vor sich her zu schieben in der Hoffnung, er wird vorher den Ruhestand erreichen ehe die Probleme ihn einholen. Der Wiener IT-Manager muss nicht auf Wien warten, er ist schon angekommen. Auf ihn wartet nur noch ein schattiger Platz im Zentralfriedhof, hoffentlich nicht zu weit vom Eingang, damit seine alten IT-Kollegen ihn gelegentlich besuchen. Vielleicht ist es deshalb so schwierig, IT-Projekte mit Wienern durchzuführen. Sie sind schon einen Schritt voraus.

Jedenfalls ist Wien das Ende meiner persönlichen Reise durch die IT-Welt in Mitteleuropa. Begonnen hat sie in Hannover bei der H.I.S. Hochschul-Informationssystem im Jahre 1970 und enden tut sie in Wien bei der ANECON GmbH. Dazwischen liegen viele Zwischenstationen bei Anwendern und Herstellern von Softwaresystemen in Deutschland, der Schweiz, Österreich, Italien und Ungarn. In den 40 Jahren habe ich an mehr als 100 Projekten teilgenommen, über 50 Softwarewerkzeuge entwickelt, 22 Bücher verfasst oder mitverfasst, an 14 verschiedenen Universitäten und Fachhochschulen gelehrt und mehr als 400 Fachartikel veröffentlicht. Dabei habe ich viele Erfahrungen gesammelt, Erfahrungen, die ich mit diesem Buch weitergeben möchte. Denn trotz der äußerlichen Veränderungen in der IT-Technologie in dieser Zeit ist vieles gleichgeblieben. Es sind weniger die Probleme der neuen Technologie, die uns in den IT-Projekten zu schaffen machen, als vielmehr die uralten Probleme der Projektplanung und der Arbeitsorganisation, wie De Marco in seinem Peopleware Buch feststellt. Insofern sind die Erfahrungen aus der IT-Welt doch noch zeitlos.

Die junge IT-Generation tut gut daran, aus den Erfahrungen der letzten Generation zu lernen. Sie könnte dadurch manche Falle vermeiden. Außerdem helfen Kenntnisse der alten DV-Methoden und Techniken die neuen IT-Technologien besser zu verstehen. Es ist erstaunlich viel von den alten Problemlösungsansätzen in den neuen übernommen worden, viel mehr als die neue Generation ahnen kann. Wer versteht wie und warum diese alten Ansätze zustande gekommen sind, wird die neuen Ansätze besser einschätzen können. Leider fehlt hierfür die Einsicht. Es ist erstaunlich, wie wenig die junge Generation von Informatikern von der bisherigen Informatik wissen. Dabei wäre dies für das Verständnis der Welt, in der sie arbeiten von großer Wichtigkeit. Sie würden nämlich wissen, dass die neuen Konzepte, die sie für die endgültige Lösung halten, weder neu noch endgültig sind. Sie sind nur eine weitere Iteration in einer endlosen Schleife bei der immer nur ein paar Variablen sich ändern. Die Mehrzahl der Daten bleibt konstant.

Es wäre deshalb anzustreben, so etwas wie eine Geschichte der Informatik als Pflichtfach für alle angehenden Informatiker vorzuschreiben. Sie sollen damit lernen, wie die Welt in der sie arbeiten wollen, zustande gekommen ist, welche Probleme ihre Vorgänger hatten und wie sie sie gelöst haben. Vor allem sollten sie lernen, warum sie so gelöst wurden wie sie sind. Dann hätten sie mehr Verständnis für die vielen alten Systeme, die heute noch die Hauptlast der IT-Welt tragen und die sie ablösen sollten.

Dieses Buch sollte dazu einen Beitrag leisten. Es beginnt mit der Datenverarbeitung am Anfang der 70er Jahre und endet mit der Cloud Technologie des 21. Jahrhunderts. Vier Jahrzehnte IT-Geschichte liegen dazwischen. Sie werden aus der Sicht eines Zeitzeugen geschildert, der immer bemüht war, die neuesten Themen in die Praxis umzusetzen. Es ist also kein Geschichtsbuch, das nur Fakten und Daten weitergibt, sondern eine Erlebnisgeschichte, die die erlebten Erfahrungen des Autors im Kampf ums Überleben in einer hart umkämpften IT-Welt schildern. Nichts hilft mehr, den Blick für das Wesentliche einer Welt zu schärfen, als die Notwendigkeit darin bestehen zu müssen. Dies war ja auch die Lebenssituation des Autors, der als selbstständiger Unternehmer sich immer am Rande des Überlebens bewegte, im Spannungsfeld zwischen dem großen Erfolg und dem totalen Absturz. Zum Glück ist weder das eine noch das andere passiert. So konnte es der Autor schaffen, als freischaffender Software-Berater in einem kleinen Ziviltechnikerbetrieb in Wien dieses Buch zu Ende zu bringen.

Software Strandgut als Schichtenmodell

Das Buch beginnt mit dem Deutschland der 70er Jahre als die meisten DV-Systeme im Batchbetrieb liefen. Der Autor begann als Angestellte bei der HIS in Hannover und wechselte später zu Siemens in München wo er im Datenbankbereich tätig war. Dann kam das große I.T.S. Projekt und der Beginn seiner Karriere als Softwaretester. Die Umstände haben dazu geführt, dass er zusammen mit dem amerikanischen Testexperte Ed Miller in Budapest ein Testlabor gründete. Dieses Software Testlabor war das erste seiner Art in Europa. Mit dem Ende des Testlabors ging die Kooperation mit den Ungarn auf dem Gebiet der Software Engineering Werkzeuge weiter. Der Autor hatte eine Vision den gesamten Softwareentwicklungszyklus von der Projektplanung bis zur Produktabnahme zu automatisieren. Diese Vision wollte er mit einer Werkzeugkette namens SoftOrg verwirklichen. Zu einer Zeit waren 26 Institutsmitarbeiter in Ungarn an dem SoftOrg Projekt beteiligt. Um die Werkzeuge zu vertreiben gründete er eine Firma in Deutschland – Software Engineering Services – zur Förderung der deutschen Softwaretechnologie. Die 80er Jahre waren das Jahrzehnt des IT-Aufbruches. Es gelang tatsächlich viele der Werkzeuge bei großen Anwenderfirmen einzubringen und damit Projekte abzuwickeln. Die Anwender gehörten zu den führenden Unternehmen Deutschlands. Ein Kapitel befasst sich mit der Entwicklung der Werkzeuge in Ungarn und ein anderes mit dem Einsatz der Werkzeuge in Deutschland. Dort stellte sich heraus, dass die klassische Top-Down, phasenweise Entwicklung nicht immer zum gewünschten Ziel führt, auch dann nicht, wenn sie von Tools unterstützt wird.

Dann folgt der Zusammenbruch der sozialistischen Länder und das Ende der SoftOrg Entwicklung. Der Autor war gezwungen einen neuen Weg einzuschlagen. Dieser Weg führte über das Reengineering in die Schweiz. Dort hat der Autor zusammen mit einigen seiner ehemaligen ungarischen Mitarbeiter jahrelang Reengineering und Migrationsprojekte durchgeführt. Nach 7 Jahren wurde die Arbeitsbewilligung für den Autor und die Ungarn nicht länger gebilligt. Er musste die Schweiz verlassen. Nach dem Abschied von der Schweiz folgten einzelne Reengineering, bzw. Kapselungsprojekte in Deutschland, aber ein dauerhafter Auftrag blieb aus. So kam es, dass er 1998 nach Wien zu einem großen Bankprojekt gezogen ist. Dort hat er Jahre lang geprüft, getestet und neue Werkzeuge entwickelt bis er 2003 zusammen mit 140 Anderen entlassen wurde. Der Versuch in Deutschland wieder Fuß zu fassen ist nicht gelungen, so kehrte er bald wieder als Tester nach Wien zurück. Zwischen 2003 und 2013 hat er bei der Firma ANECON an mindestens 20 Testprojekten teilgenommen. Aber nicht nur an Testprojekten. Er war auch an Migrations- und Messprojekten beteiligt oder hat sie federführend durchgeführt. Wieder kam eine Menge Projekterfahrung dazu, so dass bis zu seiner Entlassung von der ANECON im Jahre 2014, er beinahe 45 Jahre Projekterfahrung im deutschsprachigen IT-Raum gesammelt hat. Über die späteren Erfahrungen im Bereich der Qualitätssicherung gibt es zwei Kapitel, eins über die Testprojekte und eins über die Messprojekte.

Diese Geschichte erstreckt sich über vier Jahrzehnte. Jedes Jahrzehnt war von einer bestimmten Technologie geprägt. Die 70er Jahren waren das Jahrzehnt der standalone-Batch-Systeme, die 80er Jahren waren das Jahrzehnt der integrierten Online-Systeme, die 90er Jahren das Jahrzehnt der verteilten, objektorientierten Systeme und die 00er Jahren das Jahrzehnt der Web-basierten Systeme. Jedes Jahrzehnt hatte seine eigene Ideale und Risiken. Die IT-Welt ist immer dabei sich neu zu definieren. Die Lösungen des einen Jahrzehnts sind die Probleme des Nächsten. Es ist eine endlose Schleife aus der es kam Entkommen gibt.

Die ständig wandelnde IT-Praxis wird hier aus der Sicht eines Beteiligten geschildert, der viele Rollen in diesem Geschehen wahrgenommen hat:

als Programmierer

als Designer

als Manager

als Tester

als Toolentwickler

als Publizist und

als Lehrer.

Dabei werden die Ereignisse immer aus der Sicht der jeweiligen Rolle betrachtet. Der Fortschritt in der Informatik wird zum einen von den Visionen der Forschenden und zum anderen von den Herausforderungen der Praxis vorangetrieben. Diese beiden Triebkräfte bedingen sich gegenseitig. Ohne den Druck die alltäglichen Probleme zu lösen gebe es keine Visionen. Es ist keineswegs so, dass die IT-Welt von oben bzw. von der Vision der Verantwortlichen ausgetrieben wird. In der IT-Welt sind die Verantwortlichen eher die Getriebenen. Sie reagieren auf die Ereignisse, die von unten ausgelöst werden. Die treibende Kraft ist die Hardware und Kommunikationstechnologie. Sie bestimmt die Basis-Software, die Betriebssysteme, Datenbanksysteme und die Kommunikationssysteme. Diese bestimmen wiederum welche Werkzeuge bzw. welche Sprachen zur Verfügung stehen und diese bestimmen die Entwicklungsmethoden. Die Prozesse folgen erst am Ende dieser Kausalkette. Ausschlaggebend für die Entstehung der Werkzeuge, Methoden und Prozesse einer Epoche sind die typischen Projekte, die in einer Epoche ausgeführt werden. Sie stellen die Ziele, die angestrebt werden und die Ziele verbinden die herrschende Technologie und die verfügbaren Werkzeuge mit den Entwicklungsmethoden und der Managementphilosophie. Die Teilaspekte bekommen erst durch zielgerichtete Projekte einen Sinn und schmelzen zu einem Ganzen zusammen, was wir als IT-Technologie eines Zeitalters bezeichnen können. Zu Beginn eines jeden Zeitabschnittes findet einen technologischen Durchbruch statt. Dieser zieht neue Produktionsmittel, bzw. Sprachen, Techniken und Werkzeuge nach sich. Nach Marx bestimmen die Produktionsmittel die Produktionsweise [Marx94], d.h., die Sprachen, Techniken und Werkzeuge bestimmen hier die Methoden und diese bestimmen die Prozesse. Am Ende entsteht eine Vision wie die Prozesse zu gestalten sind. D.h. zuerst kommt die Praxis, dann folgt die Theorie. Die Entstehung einer sozio-technologischen Welt wäre nicht möglich ohne die Zielrichtung, die von den laufenden Projekten gegeben wird. Es sind vor allem die Projektanforderungen, die die IT-Technologie vorantreiben. Deshalb ist es so wichtig, die Lösungen der Vergangenheit zu kennen um die Probleme der Gegenwart zu lösen. Die größte Herausforderung der Informatik ist die Bewältigung der eigenen Vergangenheit. Durch die Schilderung vergangener Projekte soll dieses Buch dazu einen Beitrag leisten.

2 Datenverarbeitung in den 70er Jahren

2.1 Anfang bei der H.I.S in Hannover

Es war 1970 als ich auf Wunsch meiner Frau meinen Job als Programmierer / Analyst im U.S. Navy Department in einem Vorort von Washington D.C. aufgab und nach Deutschland auswanderte. Meine Frau ist Deutsche und wollte in ihr Heimatland zurückkehren. In Amerika standen mir zwei Wege offen – an der Universität Maryland zu bleiben, zu promovieren und eventuell Professor zu werden oder im Civil Service zu bleiben und eventuell Manager zu werden.

Ich habe weder den einen noch den anderen Weg eingeschlagen. Ich bin nach Deutschland gekommen. Das Schicksal wollte es so. Meine Frau war schon früher zurückgekehrt und hatte für mich in der Zeitung inseriert. „Amerikanischer Programmierer / Analytiker mit Masters Degree in Public Administration, zwei Jahre Berufserfahrung und guten Deutschkenntnissen sucht Stelle in der Bundesrepublik als Systemanalytiker“. Daraufhin bekam sie sage und schreibe 33 Angebote. Wir haben 7 ausgewählt und nachdem ich angekommen war, alle 7 aufgesucht – von Konstanz am Bodensee bis nach Hamburg an der Elbe. Es gab darunter einige sehr interessante Möglichkeiten in der Industrie zu arbeiten, aber da ich zum öffentlichen Dienst neigte – ich hatte nämlich eine Abneigung gegen die freie Marktwirtschaft – entschied ich mich für eine Gesellschaft des öffentlichen Rechts – die Hochschulinformationssystem Gesellschaft in Hannover. Es schien mir der Platz zu sein, wo ich am wenigsten dem Leistungsdruck der Marktwirtschaft ausgesetzt wäre. Ich suchte eine freundliche, stressfreie Umgebung mit Anschluss an die akademische Welt, in der ich mich in Ruhe entfalten konnte. Ich spielte damals noch mit dem Gedanken, die Promotion nachzuholen und doch noch Professor zu werden. Was konnte man sich besseres wünschen, als Professor in Deutschland zu werden? Bei der HIS wäre ich wenigstens in der Nähe dieses Traumes, und die Arbeitsatmosphäre war auch ansprechend. Viele junge Akademiker mit dem Ziel, die deutsche Hochschullandschaft aufzukrempeln. Da es unter ihnen kaum welche gab mit IT-Erfahrung, hatte ich dort die Chance, mich zu profilieren. Und so kam es auch. Ich konnte mich bei der HIS richtig ohne allzu großen Leistungsdruck entfalten und meine Sicherheit in einer fremden Welt gewinnen. Es war also der Wunsch, dem Leistungsdruck zu entgehen, der mich zu Beginn meiner Laufbahn in Europa nach Hannover schlug und es war der Wunsch, dem Leistungsdruck zu entkommen, der mich am Ende dieser Laufbahn nach Wien brachte.

2.2 Projekte in der deutschen Hochschulverwaltung

IT-Projekte zu Beginn der 70er Jahre und insbesondere Projekte im öffentlichen Dienst waren weit entfernt von dem Hochdruck, termingetriebener Projekte, die wir heute kennen. Die Beteiligten hatten Zeit. Ob der Termin um 6 Monate überschritten wurde, hat niemand gestört. Man war froh, dass sie überhaupt fertig geworden sind. Der Entwickler, oder der Programmierer, so wie er damals bezeichnet wurde, genoss eine ziemlich große Freiheit. Keiner wagte ihn in irgendwelcher Weise zur Rechenschaft zu ziehen, nicht einmal der Projektleiter. Zu kostbar waren seine Talente und zu wenig Programmierer waren es überhaupt. Ergo, konnte der Programmierer relativ ungestört ohne jegliche Kontrolle arbeiten. Dies ist der Hauptgrund für den katastrophalen Zustand mancher Legacysysteme, die in den 70er Jahren entstanden sind, aber das ist ein anderes Kapitel.

Es herrschte damals das Wasserfallmodell und keiner hätte gewagt, es in Frage zu stellen [Royce70]. Die Arbeitsteilung und damit die berufliche Rangordnung waren davon abhängig. Tester hat es noch nicht gegeben, getestet haben die Endanwender selbst, so dass der Programmierer trotz seiner großen Freiheiten am Ende der Rangordnung stand. Über ihn gab es einen Designer, der heutige Architekt, und über den der Systemanalytiker. Es war die Aufgabe des Analytikers, die Anforderungen der Benutzer zu analysieren und in ein sogenanntes Fachkonzept niederzuschreiben. War das Fachkonzept einmal fertig, konnte der Analytiker für den Rest des Projektes zuschauen. Seine Arbeit war erledigt. Der Designer hatte die Aufgabe, das Fachkonzept in ein technisches Konzept umzusetzen. Das tat er in Absprache mit dem vorgesehenen Programmierer. Danach übernahm der Programmierer das Design und setzte es in Codes um. So war es zumindest in der Theorie. In der Tat musste der Programmierer sehr viel nacharbeiten, die Lücken im Fachkonzept schließen und die Fehler im Design ausbügeln.

So kam es, obwohl der Programmierer der niedrigste in der Rangordnung war, hatte er die größte Verantwortung. Er musste dafür sorgen, dass aus der inkonsistenten, unvollständigen Spezifikation und dem oft realitätsfernen Entwurf doch noch eine lauffähige IT-Lösung entstand, welche die Bedürfnisse der Anwender halbwegs abdeckte. Diese Rolle habe ich akzeptiert und versuchte das Beste daraus zu machen.

Außer mir gab es kaum jemand bei der HIS der programmieren konnte. Die meisten sahen sich als Systemanalytiker, einige andere als Designer und der Programmierer war ich – der nützliche Amerikaner. So sah es auch in den Projekten aus. Mein erstes Projekt war an der Universität Erlangen. Verantwortlich dafür war Professor Mertens von der betriebswirtschaftlichen Fakultät. Später sollte er einer der Gründer der Wirtschaftsinformatik werden. In dem Projekt waren seine Assistenten ergänzt durch ein paar Leute von der HIS. Eine externe Beratungsfirma aus der Schweiz, die B&O, war für die Implementierung zuständig. Diese Firma war an der Entwicklung der normierten Programmierungsmethodik maßgeblich beteiligt und schrieb sie für das Projekt vor. Diese Methode war dazu gedacht, mehrere vorsortierte sequentielle Dateien zusammenzuführen und immer die nächsten Sätze aus jeder Datei auszuwählen. Es gab einen Gruppenwechsel, wenn der nächst höhere Schlüssel vorkam und eine Gruppenendverarbeitung. Das Ganze wurde über GO TO Anweisungen gesteuert [Helm70]. Das konnte mich nicht so begeistern, denn Edger Djikstra hatte gerade seine bahnbrechende Erkenntnis veröffentlicht, dass die GO TO Anweisung schädlich sei [Dijk67]. Davon war jedoch in diesem Projekt nichts zu merken. Der Vorteil der normierten Programmierung war, dass alle Programme den gleichen Aufbau und die gleiche Ablauflogik hatten und das war schon ein Gewinn. Über die vielen GO TO Anweisungen konnte man hinwegsehen. Das habe ich auch getan und mich mit der Methodik abgefunden. Kurz danach habe ich die normierte Programmierung mit der strukturierten Programmierung in meinem ersten deutschsprachigen Fachartikel in der Zeitschrift für Datenverarbeitung verglichen [Sned71].

2.2.1 Das Studenten Operationssystem

Das SOS-Projekt – kurz für Studenten Operationssystem – litt wie alle HIS Projekte unter der Uneinigkeit der Hochschulen. Es sollte ein System für die Verwaltung der Studenten in allen Hochschulen sein mit Immatrikulation, Exmatrikulation und Fortschrittsverfolgung. Da die Hochschulen alle unterschiedlichen Rechner hatten, sollte es zunächst nur auf einem Siemens Rechner mit dem Betriebssystem BS 1000 laufen. Es sollte jedoch so konstruiert sein, dass es später auf die anderen Rechnertypen transportiert werden konnte. Die Programmiersprache war COBOL-60. Damit wurde schon genug verlangt, denn es war damals nicht einfach, ein portables System mit einer so beschränkten Sprache zu bauen. Die verfügbare Speicherkapazität spielte eine ausschlaggebende Rolle. Die Daten wurden deshalb in sequentiellen Dateien auf Magnetbänder gespeichert. Die Schwierigkeit lag darin, die Verarbeitungsschritte in viele aufeinander folgende Batch-Jobschnitte aufzuteilen [Mert72].

Hinzu kamen die unterschiedlichen Anforderungen der beteiligten Hochschulen. Im Prinzip wollte jede Hochschule ein eigenes System haben. Über ein einheitliches Datenmodell konnten sie sich nicht einigen. Von Bundesland zu Bundesland gab es sowohl unterschiedliche Daten als auch unterschiedliche Vorschriften, sprich Geschäftsregeln. Sie auf einen Nenner zu bringen, war wie die Quadratur des Kreises.

25 Jahre später sollte ich mit der gleichen Problematik im Fiskus Projekt konfrontiert sein. Der Föderalismus in Deutschland erschwert die Entwicklung einheitlicher IT-Systeme. Man kann die Systeme noch so parametrisieren und flexibel gestalten, sie passen nicht, solange die Geschäftsprozesse anders ausgelegt sind. So war das auch mit den ersten Projekten für die deutsche Hochschulverwaltung. Das gekoppelt mit der Inkompatibilität der Rechnersysteme schaffte unüberwindbare Hindernisse. Kurzum stellten sich die ursprünglich gesetzten Ziele als unerreichbar heraus.

Um überhaupt weiterzukommen, mussten die Ziele geändert werden. Es sollten nur modellhafte, maßgeschneiderte Systeme für einzelne Hochschulen auf einem bestimmten Rechnertyp realisiert werden. Statt alle Hochschulen mit den gleichen Verwaltungssystemen auszustatten sollte jede Hochschule zusehen, wie sie zu eigenen Systemen mit ähnlichen Funktionen kommen. Die IT-Systeme, die HIS zusammen mit ausgewählten Hochschulen entwickelte, sollten als Muster für die anderen Hochschulen dienen. So wurde das Studenten-Operationssystem letztendlich nach den Anforderungen der Universität Erlangen fachlich ausgerichtet und auf einem Siemens BS 1000-Rechner zum Laufen gebracht. Ich habe das Ende des Projektes nicht mehr miterlebt, da ich inzwischen für ein anderes Projekt abgezogen wurde, aber dank der Einsatzbereitschaft des Erlanger Teams unter der Leitung Professor Mertens, ist das System tatsächlich zwei Jahre später in Betrieb genommen worden.

2.2.2 Das kameralistische Abrechnungssystem

Das nächste Projekt, wozu ich aus Erlangen abberufen wurde, war das Haushaltsverwaltungssystem. Der Auftrag für die Entwicklung dieses Systems wurde an die Universität Köln vergeben, nämlich an den Lehrstuhl des Professor Grochlas. Zuständig für die Durchführung des Projekts war ein gewisser Dr. Strünz, der später Geschäftsführer des MBP Softwarehauses in Dortmund wurde. Damals war er bekannt für seine Veröffentlichungen über die Entscheidungstabelle als Mittel zum Entwurf von EDV-Programmen [Stru72]. Um ihn herum gab es jede Menge Doktoranden, die alle mit Entscheidungstabellen gut umgehen konnten, aber nicht mit COBOL, der vorgesehenen Programmiersprache. Dazu war ich, der Programmierer aus Amerika zuständig. Der Lehrstuhl war wie in Erlangen für Betriebswirtschaft und kein angehender Betriebswirt wollte sich mit Codierung befassen. Diese gleiche Einstellung herrscht heute noch in der Wirtschaftsinformatik, wo jeder sich als Modellierer empfindet. Das Programmieren, sprich codieren, überlässt man den Indern. Damals gab es noch keine Inder, zumindest nicht am Rhein. Dafür gab es einen Amerikaner. Später kamen auch noch ein pakistanischer Kollege und zwei Studenten der Betriebswirtschaft hinzu. Wir waren die Programmiermannschaft. Es hat deshalb entsprechend lange gedauert bis die ersten COBOL Programme auf der Siemens-BS1000-Maschine der Universität liefen. Die Vorschriften für die öffentliche Haushaltsführung waren schon immer sehr komplex, viel komplexer als die der Studentenverwaltung. Ich war mit vielen neuen Begriffen konfrontiert. Es gab eine Haushaltsaufstellung, einen Haushaltsvollzug und eine Haushaltsabrechnung. Aus der Zeit habe ich gelernt, dass es in der deutschen Verwaltung auch einen Antrag auf einen Antrag gibt. Zu der Haushaltsaufstellung gehörten:

die Mittelanforderung durch die mittelbewirtschaftenden Stellen

die Mittelplanung auf der Grundlage der Mittelanforderungen

die Mittelgenehmigung und

die Mittelbereitstellung

Zum Haushaltsvollzug gehörten

die Anordnung von Auszahlungen

die Entgegennahme von Zahlungen und

die Führung von Überwachungslisten.

Zur Haushaltsabrechnung gehörten schließlich

die Sachkontenführung

die Zeitbuchführung und

die Jahresabschlüsse.

Da mit dem kammeralistischen Rechnungswesen keine Wirtschaftlichkeitskontrolle möglich war, kam noch eine Kostenrechnung dazu mit

Kostenartenrechnung

Kostenstellenrechnung und

Kostenanalyse [

Mund74

].

Die letzteren Funktionen waren auf den kammeralistischen Funktionen aufgestülpt. Dies führte zu einer weiteren Steigerung der Komplexität. Neben den HIPO Funktionsbäumen gab es Bäume von verschachtelten Entscheidungstabellen mit Verweise auf die Knoten in den HIPO Bäumen.

All das baute auf einer netzartigen Datenbank mit allen haushaltsrelevanten Daten. Das Datenbanksystem war das SESAM System der Firma Siemens, das gerade von dem späteren Gründer der Software AG – Peter Schnell – für Siemens entwickelt worden war. Es war noch äußerst unstabil, so dass man nicht nur mit der Komplexität der Haushaltsführung, sondern auch mit den Unwägbarkeiten einer unberechenbaren Datenhaltung zu kämpfen hatte. Aus dieser Zeit habe ich gelernt, was die Datenmodellierung für das Projekt bedeutet. Neben dem komplexen Funktionsmodell gab es ein ebenso komplexes Datenmodell, allerdings ohne Entity/Relationship Diagramme, da sie zu diesem Zeitpunkt noch gar nicht erfunden waren. Für solche komplexen Projekte waren weder die Datenbanktechnik noch die Modellierungstechnik ausgereift.

Als Konsequenz hat sich das Projekt in Köln ewig herumgeschleppt. In dem Jahr, in dem ich dort war, sind nur einzelne Probeprogramme fertiggestellt worden. Es würde noch vier Jahre dauern, bis das System einsatzfähig war. Das machte aber nichts aus. Niemand in der Hochschulverwaltung drängte darauf. Im Gegenteil. Sie sahen es eher als eine Bedrohung, die es möglichst abzuwehren galt. Die Nächte in Köln waren lang und im Institut gab es viel zu feiern – Eintritte, Austritte, Promotionen, Geburtstage und Karneval. Dort lernte ich, dass das Arbeitsleben in Deutschland eher ein Ritual ist. Es kommt weniger auf die Leistung als auf die Integration in der Gruppe an – soziale Kompetenz nennt man das heute. Ich ließ mich gut integrieren vor allem mit den Sekretärinnen dort am Institut, und so verging die Zeit zwischen dem Kampf mit der unzulänglichen Technik und dem stressvollen Feiern in den Kölner Kneipen. Am Ende hatte ich genug von beidem und war froh, dass ich nach eineinhalb Jahren und zwei Karnevaljahreszeiten aus Köln abgezogen wurde.

2.2.3 Das Raumbestandsaufnahmesystem

Mein drittes Projekt für die Hochschulverwaltung war die Raumbestandsaufnahme. Dieses Vorhaben war im Gegensatz zu dem Haushaltsverwaltungsprojekt in Köln wohl definiert und überschaubar. Es gab auch einen Termin und einen Anwender – die Universität Karlsruhe, die daran interessiert war, das Ergebnis so bald wie möglich zu bekommen. Hier ging es darum, die Daten über sämtliche Lehrräume der Universität, z. B. die Fläche, die Höhe, die Fenster usw. zu sammeln, zu speichern und auszuwerten. Vorgesehen waren zwei sequentielle Dateien und eine Gebäudedatei und eine Raumbestandsdatei, die über Matrizen im Kernspeicher zu vereinigen waren. Der Kernspeicher war groß genug. Benutzt wurde der für die damalige Zeit Superrechner, der CDC-6600, an der Universität Stuttgart-Vaihingen. Als Programmiersprache sollte die Sprache FORTRAN dienen. Dies kam mir sehr entgegen, denn FORTRAN war neben Englisch meine Muttersprache. Meine ersten Programme beim Marine Forschungslabor außerhalb von Washington, wo ich programmieren gelernt habe, waren FORTRAN Programme. So gesehen war dieses Projekt für mich ein Heimspiel.

In dem Erlanger Projekt hat es viele Mitstreiter gegeben, auch wenn sie keine Entwickler waren. Die paar Entwickler außer mir kamen von außen. In dem Kölner Projekt war ein ganzer Lehrstuhl an dem Projekt beteiligt. In dem Raumprojekt blieb ich alleine und in diesem Fall war es auch gut so. Über mir gab es einen Raumplanungsspezialisten von der HIS, der vorgab welche Daten zu beheben und welche Berichte zu produzieren sind. Was dazwischen passierte, war mir überlassen. Die erhobenen Daten waren auf Lochkarten, meine FORTRAN Programme ebenso. Einmal fielen sie mir aus den Händen und ich verbrachte eine Nacht damit, sie wieder aufzusammeln und zu sortieren.

Der Rechenbetrieb mit dem großen CD-6000 Rechner an der Uni Stuttgart war sehr streng. Man musste seine Lochkartenkiste an der Pforte abgeben und fand sie zusammen mit den Listen in den Ausgangsfächern, wo jeder Benutzer ein eigenes Fach hatte. Falls es einen Computerfehler gab, wurde der Job abgebrochen und ich bekam eine Diagnostikliste. Falls es einen Laufzeitfehler gab, bekam ich einen Dump – eine dicke Papierrolle mit endlos vielen hexadezimalen Zeichen. Einen Dump zu lesen war für die damaligen Programmierer eine große Herausforderung. Man musste sich mit der Adressierungstechnik auskennen und diese war bei den verschiedenen Computerherstellern immer anders. Im Gegensatz zu den IBM und Siemens Rechnern, die Bytemaschinen waren, war der CDC-Rechner eine Wortmaschine. Die Daten wurden in Wörtern à 60 Bit abgespeichert. Dies war für die Speicherung nummerischer Werte, vor allem Gleitkommazahlen eine gute Einrichtung, aber für die Speicherung von Zeichenfolgen ein Graus. CDC und die anderen Wortmaschinenhersteller hatten auf die nummerische Datenverarbeitung gesetzt. Sie optimierten die Rechenoperationen und die Speicherung in Zahlen auf Kosten der Zeichenverarbeitung. Insofern war es nicht leicht, gewöhnliche Datenverarbeitungsaufgaben mit ihnen zu erledigen.

Zum Glück bestanden die Raumdaten größtenteils aus nummerischen Daten – Flächen, Höhen, Abständen usw. Es ist mir gelungen, sämtliche Raumdaten einer Universität wie Karlsruhe in eine einzige große Kernspeichermatrix unterzubringen, zu vergleichen und auszuwerten. Innerhalb von sechs Monaten war das Projekt Raumdatenerhebung abgeschlossen. Ich musste einige Nächte im Rechenzentrum in Stuttgart-Vaihingen verbringen, um meine Fehler zu beseitigen, aber es war bald überstanden. Dies war das erste HIS-Projekt, dessen Ende ich erleben konnte. Die anderen beiden – das Studenten-Operationssystem und das Haushaltsverwaltungssystem schleppten sich ewig hin und erreichten erst nach Jahren einen Stand, den man benutzen konnten.

Das Raumerhebungsprojekt war kurz und preiswert. Zwei Mitarbeiter waren sechs Monate damit beschäftigt. Am Ende konnten alle Auswertungen abgeheftet werden. Der Erfolg lag mit der Größe und Überschaubarkeit zusammen. Es gab auch keine Konflikte. Der eine gab vor was zu tun war und der andere hat es ausgeführt. Lehman und Belady würden dies als Wegwerfsystem bezeichnen. Die anderen beiden Systeme waren evolutionäre Systeme bei denen sich die Ziele erst im Verlaufe des Projektes herausstellten. Es waren viele Beteiligte und jeder hatte eine andere Sicht auf die Dinge. Es dauerte schon Jahre, nur einen Konsens zu bilden.

Mir war das eine gute Lehre im Projektmanagement. Man muss zwischen Projekttypen streng unterscheiden: Es gibt planlose und nicht planbare Projekte, technische und politische Projekte. Wo viele Menschen beteiligt sind, überwiegt das Politische über das Technische? Die Probleme liegen weniger an der Implementierung, obwohl das auch schwer genug ist, sondern an der Definition dessen, was zu implementieren ist. Und je länger ein Projekt dauert, desto mehr unterliegt es den Änderungen in der Umgebung, die es selber verändern will. Somit entsteht eine Art Zyklus Virtuos.

Das Raumdatenerhebungsprojekt war mein letztes Feldprojekt bei der H.I.S. Danach wurde ich nach Hannover zurückgeholt um die EDV Ausbildung zu übernehmen. Von da an sollte ich nur noch Kurse für die Anderen organisieren und zum Teil selber halten nach dem Motto: „If you can’t do it, teach it.“ Der Hauptvorteil dieser Tätigkeit war, dass ich einige interessante Leute kennen lernte, u.a. Frau Dr. Heidi Heilmann vom Integrata Institut mit der ich später zusammen Bücher schreiben sollte. Frau Dr. Heilmann brachte ein Jahresband heraus – das Handbuch für Datenverarbeitung – und bat mich um Beiträge [Sned75]. Ich hatte durch meine neue Position mehr Zeit Fachartikel zu schreiben und konnte nebenbei für das erste Buch arbeiten – Informationssysteme für Hochschulen.

2.3 Veröffentlichungen bei der H.I.S.

Schon im Frühjahr 1970 habe ich zusammen mit zwei Kollegen von der H.I.S. einen Artikel für die Zeitschrift für Datenverarbeitung mit dem Titel „Aufbau eines Informationssystems für Hochschulen“ verfasst [Mund75]. Es war nicht nur mein erster Fachartikel in deutscher Sprache, sondern meine erste Veröffentlichung überhaupt. Der Artikel wurde sehr lange und dehnte sich über drei Ausgaben der Zeitschrift hinaus. Darin stellten wir ein DV-System vor, das alle Bereiche der Hochschulverwaltung abdecken sollte - Studentenoperationen wie Anmelden, Abmelden, Ausstellen von Bescheinigungen, usw., Personalabrechnung, Haushaltswesen, Kassenwesen, Raumverwaltung und vieles mehr. Das sollte alles von einem zentralen Rechner aus gesteuert werden. Ich habe beschrieben wie dieses allumfassende Management-Informationssystem zu implementieren wäre, natürlich nur rein theoretisch. Wie so ein komplexes System in Wirklichkeit zu entwickeln wäre konnte ich damals nicht ahnen. Später haben wir drei entschieden ein Buch darüber zu schreiben. Dieses erste Buchprojekt hat sich lange hingezogen. Als das Buch endlich im Jahre 1974 im deGruyter Verlag erschien war ich schon lange nicht mehr bei der H.I.S.

Das Buch war um einiges detaillierte als der erste Artikel war, nicht nur weil es länger war, sondern weil wir in der Zwischenzeit viel mehr Erfahrung gesammelt hatten. Ich hatte persönlich mitgewirkt an der Entwicklung des Studenten-Operationssystems, an dem Finanzverwaltungssystem, an dem Personalverwaltungssystem und zuletzt an der Raumverwaltung. Ich konnte daher zumindest meine Teile des Buches mit vielen Berichten aus der Entwicklungspraxis untermauern. Neben den diversen Anwendungssystemen habe ich ein allumfassendes, integriertes Datenmodell für die Hochschule vorgestellt. Die Mindest-Hardware Konfiguration habe ich auch vorgegeben, obwohl das nicht gerade mein Gebiet war. Das Schwierige war, dass sowohl die Anwendungssoftware als auch das Datenmodell auf alle damals gängige Rechner übertragbar sein sollte. Das war zu dieser Zeit ein großer Wurf und konnte nur gelingen, wenn die Systemarchitektur möglichst dehnbar und die Systemkomponente möglichst austauschbar blieben. Das Buch ist gut gelungen, aber leider haben sich nur wenige für dieses Thema interessiert.

Inzwischen hatte ich begonnen mich mehr technischen Themen zu widmen. Mit dem H.I.S. Entwicklungsleiter zusammen, habe ich Ende 1971 einen Fachbeitrag zum Thema „Modularprogrammierung“ für die Zeitschrift für Datenverarbeitung verfasst [Sned71]. Mein Anliegen war die großen, monolithischen COBOL Programme von damals nicht nur in einzelnen internen Prozeduren die per Perform-Anweisung aufgerufen werden, sondern darüber hinaus die Programme in möglichst viele, getrennt compilierbare Module aufzuteilen, die per Call-Anweisung aufgerufen werden. Es sollte dabei darauf geachtet werden, dass möglichst viele Module in verschiedenen Programmen wiederverwendet werden. Ich befürwortete sogar eine gemeinsame Bibliothek wiederverwendbarer Softwarebausteine. Dies war das erste Mal, dass der Begriff Softwarebaustein vorgekommen ist. Derartige Modulbildung war zu dem Zeitpunkt ein innovativer Ansatz und wurde in der Fachpresse oft zitiert.

Danach folgten weitere Artikel über den Aufbau großer Programme in der gleichen Zeitschrift. Ich zitierte Edgar Dijkstra und setzte mich für die strukturierte Programmierung ein. Mit Beispielen habe ich gezeigt wie man zumindest in COBOL die GOTO Anweisung vermeiden konnte [Sned73]. In der gleichen Zeitschriftausgabe erschien der erste Artikel in deutscher Sprache über Struktogramme als Entwurfstechnik von Peter Schnupp und Christianne Floyd von der Firma SoftLab. Zu diesem frühen Zeitpunkt habe ich auch begonnen mich mit dem Thema Test auseinander zu setzen. Ich hatte erkannte wie wichtig es war der Test vom Anfang an zu berücksichtigen. Später als ich bei Siemens war, setzte ich meine Berichtserstattung mit Beiträgen über Programmier-Management und Programmiersprachen fort. Ich hatte schon mit dem nächsten Buch angefangen – Strukturierte Programmierung in der Praxis. Meine Karriere als Fachspezialist für Softwareentwicklung war auf einem guten Wege. Aufgrund meiner vielen Fachartikel wurde ich eingeladen öffentliche Seminare zum Thema „Programmierung und Programmmier-Management“ zu halten. Deutschland stand damals erst an der Schwelle zur Software-Engineering.

2.4 Das Kommunale Verwaltungsprojekt in Göttingen

Ende 1973 ist die Aufgabe als Oberlehrer bei H.I.S mir doch zu langweilig geworden. Ich sehnte mich wieder nach der Projektarbeit. Also habe ich bei der H.I.S. gekündigt und bin zu der Siemens Geschäftsstelle in Hannover übergegangen. Ich hatte in meiner Tätigkeit als Lehrer bei H.I.S einen Mitarbeiter von Siemens kennen gelernt der mir erzählte Siemens würde nach Projektleiter für Projekte der öffentlichen Hand in Niedersachsen suchen. Ich bekam sofort ein Projekt und zwar bei der kommunalen Verwaltung in Göttingen. Ich müsste zwar jeden Tag von meinem Zuhause bei Lehrte mit der Bahn nach Göttingen reisen aber das schien mir das geringste Übel zu sein. Im Zug konnte ich die Zeit nutzen neue Fachartikel zu schreiben.

Das System für die kommunale Verwaltung in Göttingen habe ich so gut wie alleine ohne fremde Hilfe geschaffen. Es gab von der Stadtverwaltung einen Projektleiter der mir sagen konnte was ich machen sollte und zwei junge Entwickler die mir zugearbeitet habe. Heute würde man dieses Projekt als agile bezeichnen. Ich habe das Ganze in Pakete aufgeteilt und ein Paket nach dem Anderen in COBOL auf der Siemens BS1000-Anlage implementiert. Die Zeit dafür war sehr knapp, das System musste spätestens im März des Jahres 1974 in Produktion gehen und ich habe erst im September 73 mit der Implementierung begonnen. Als ich begann hatte das System nur einen Namen – KOFAS für Kommunales Finanzsystem - und einige Anforderungsdokumente sowie ein halbfertiges Datenmodell. Ich habe mit dem Datenmodell begonnen und es zu Ende gemacht. Währenddessen habe ich meine zwei Hilfsentwickler zu den Fachabteilungen geschickt um die Verarbeitungsregel mit Entscheidungstabellen zu dokumentieren.

Es sollte sechs Stammdateien geben:

Eine Textdatei mit Textbausteine für die Aussendungen

Eine Adressdatei mit den Adressen aller Bürger

Eine Bankdatei mit den Bankdaten aller Bürger

Eine Sachbuchbestandsdatei mit einem Bestandssatz für jedes Sachbuchkonto

Eine Geldbestandsdatei mit einem Bestandssatz pro Geldinstitut

Eine Kontendatei einem Hauptsatz für jede Buchungsstelle und einem untergeordneten Satz für jede Buchung.

Dazu kamen fünf Bewegungsdateien:

Eine Buchungsdatei mit einem Satz pro Einnahme-, bzw. Ausgabebuchung

Eine Fälligkeitsdatei mit einem Satz für jede Zahlungsrate

Eine Überweisungsdatei mit einem Satz für jede fällige Ausgabe

Eine Lastschriftdatei mit einem Satz für jede fällige Einnahme

Eine Mahnungsdatei mit einem Satz für jede überfällige Zahlung.

Die Bewegungsdateien waren reine sequentielle Dateien auf Magnetbändern. Sie wurden mit Lochkarten erstellt, die in den Fachabteilungen erfasst worden. Die Stammdateien waren index-sequentielle Dateien auf dem Plattenspeicher. Sie lagen im direkten Zugriff über mehrere alternative Suchmerkmale und wurden durch die Bewegungsdateien regelmäßig aktualisiert.

Auf der Funktionsseite gab es zehn Batch-Transaktionen. Heute würde man sie als Anwendungsfälle bezeichnen.

Einrichtung der Stammdateien

Fortschreibung der Text- und Anschriftendateien

Korrektur der Buchungs- und Fälligkeitsdaten

Abfrage der Kontendatei

Bereitstellung der Kontoauszüge

Durchführung des Lastschriftverfahren

Durchführung des Mahnverfahrens

Bereitstellung des Sachbuches

Monats- und Jahresabschluss

Sicherung der Stammdaten

In diesen Transaktionen wurden 17 verschiedene Listen erzeugt.

Diese Funktionen wurden durch 27 COBOL Hauptprogramme und 26 Unterprogramme sowie drei JCL Dienstprogramme – Sort, Merge und Split – abgedeckt. Die COBOL Programmen umfassten genau 13.606 Anweisungen.

Es lagen knapp 17 Arbeitswochen zwischen dem Anfang des Projektes im September 1973 und dem Ende des Projektes am 10. Feb. 1974.

Die Systemanalyse und das Systemdesign dauerten 5 Wochen.

Die Programmierung dauerte 5 Wochen

Der Test nahm 6 Wochen in Anspruch.

Zum Schluss gab es noch eine für die Inbetriebnahme des Systems.

Bezogen auf den Codeumfang von 13.606 COBOL Anweisungen ergab sich bei 390 gebuchten Personentagen (über 100 für meine Person) für Design, Kodierung und Test eine Produktivität von 35 Anweisungen pro Personentag, bzw. 700 Anweisungen pro Personenmonat. Siemens verlangte für mich damals DM 500,- pro Tag. Für die internen Mitarbeiter wurden DM 3000,- pro Monat berechnet. Die Personalkosten kamen insgesamt auf DM 152.000. Das machte knapp über DM 11,- pro Code-Anweisung. Eigentlich hatte der Kunde jeden Grund zufrieden zu sein. Der Termin wurde eingehalten, das System erfüllte die Erwartungen und die Kosten lagen im Rahmen des geplanten Budgets. Außerdem war das System mit strukturierten Diagrammen gut dokumentiert. Die zwei internen Entwickler konnten das System übernehmen und weiterführen. Die Stadtverwaltung bedankte sich mit einem schönen Bilderbuch über die Stadt Göttingen. Zuletzt habe ich zusammen mit dem Projektverantwortlichen von der fachlichen Seite aus einen Fachartikel über das Projekt verfasst [Walt74]. Schon im Februar 1974 trat ich meinen neuen Posten in München an. Siemens wollte mich dort in der Datenbankentwicklung haben.

2.5 Projekte bei Siemens in München

2.5.1 Das Interaktive Datenbank Query System - IQS

In der ersten Hälfte der 70er Jahren war Siemens gerade dabei ein neues universales Datenbanksystem – UDS – zu entwickeln. An diesem Mammutprojekt waren viele Teams in verschiedenen Dienststellen beteiligt. Das ganze Produkt war in mehrere Teilprodukte aufgeteilt. Jedes Team war für ein Teilprodukt zuständig. Mein Team war für den Datenbankabfragedienst zuständig. Dazu gehörte eine Abfragesprache, angelehnt an die IQF Abfragesprache der IBM, eine Abfrageschnittstelle und eine Reihe Komponente um die Abfragen zu bearbeiten. Die Komponente waren in SPL zu schreiben – eine abgemagerte PL/I Sprache mit Assembler Elementen.

Wir waren in unserem Team zu Dritt – ein langjähriger Assembler Programmierer, ein ehemaliger Telefunken Mitarbeiter und ich. Später kam noch einen Praktikanten von der TU München dazu. Zwischendurch gab es einen Austauschmitarbeiter von Philips aus Schweden. Damals war Philips und Bull Partner von Siemens in einem gemeinsamen europäischen IT-Konsortium - UniData. Ich wurde zum Teamleiter ernannt, wahrscheinlich wegen meiner englischen Sprachkenntnisse. Englisch war die Sprache des europäischen Konsortiums. So viel zum Hintergrund dieses Projektes, das zwei Jahre von Frühjahr 74 bis Frühjahr 76 gedauert hat. Am Ende dieser Zeit habe ich für das Jahrbuch der Frau Heilmann einen Artikel darüber geschrieben [Sned76].

Das IQS Projekt war das erste Mal für mich in der IT andere Menschen anzuleiten. Bei H.I.S. war ich selbst nur Projektmitarbeiter. In Göttingen hatten die Stadtangestellten mir nur zugearbeitet. Den überwiegenden Anteil der Arbeit habe ich selber geleistet. Mir war die Rolle als Teamleiter nicht ganz fremd, in der Armee bin ich Sargent gewesen und genoss eine Ausbildung als Unteroffizier. Ich wusste also schon wie man andere Menschen führen sollte. Ich entdeckte aber bald, dass es in der Softwareentwicklung ganz anders zugeht. Man kann nicht einfach befehlen, etwas zu tun, die Untergebenen müssen es von sich aus tun wollen. Die Kunst dabei ist sie dazu zu bringen, es tun zu wollen. Es beginnt damit, dass jeder einen eigenen Arbeitsbereich hat der zu seinen Fähigkeiten passt – nicht zu schwer und auch nicht zu leicht. Das allein ist keine einfache Aufgabe. Hinzu kommt, dass der Teamleiter die Schnittstellen zwischen den Bereichen wohl definiert und selber programmiert. Über die Schnittstellen steuert der Leiter die Teamarbeit. Damit stellt er den Rahmen bereit in dem die Anderen werken können. Ebenso wichtig war es, den Stand der Arbeit, bzw. den SPL Code, regelmäßig, mindestens einmal die Woche zu kontrollieren. Dies habe ich im Gespräch mit den Mitarbeitern getan. Jede zweite Woche hatten wir ein großes Team-Meeting bei dem wir die bisherigen Ergebnisse zur Diskussion stellen und bei dem wir die nächsten Schritte geplant haben. Jedes Team-Mitglied müsste zu seinen Modulen ein Struktogramm und ein Datenflussdiagramm zeichnen und einen kommentierten Code liefern mit Datenerläuterungen und Prozedurköpfen. Jeder führte einen Projektordner mit seinem Code und seinen Dokumenten. Eigentlich hatten wir von der agilen Entwicklung vieles vorweggenommen – kurze Release-Intervalle, regelmäßige Berichte durch die Mitarbeiter, gegenseitige Kontrollen, usw. Das hat alles recht gut funktioniert und wir kamen schnell voran bis wir auf den Test stießen.

Mein Vorbild damals war das Chief-Programmer Teamkonzept von Harlan Mills [Mills72]. Ich habe mich selbst in der Rolle des Chefprogrammier gesehen. Ich sollte den Weg für die Anderen bahnen und kontrollieren, dass sie auf dem richtigen Weg auch blieben. Leider konnte ich nicht alles umsetzen was ich mir vorgenommen habe. Einen Assistenz-Programmierer, nämlich einen Architekten, habe ich gehabt. Das war der eine Schwede mit den tiefsten Kenntnissen von SPL. Ohne seinen Rat hätte ich manche Fehlentscheidung getroffen. Was fehlte war ein Tester im Team, um die abgelieferten Komponenten zu testen sowie ein Projektsekretär, jemand der die Dokumentation formatiert und aktualisiert, die Besprechungen protokolliert und Buch führt über das Projekt – die abgelieferten Ergebnisse, die offenen Fehlern, die anstehenden Aufgaben, usw. Vieles was heute unter Agile Entwicklung verstanden wird, haben wir praktiziert, aber wir hatten nicht das Personal um alle Rollen zu erfüllen. Die Rollen des Testers und des Projektsekretärs, bzw. Trackers, blieb aus und ich müsste zugleich Produkt-Owner, Tester und Leitprogrammierer spielen.

Da schon die ersten Change Requests gekommen sind, habe ich ein Tool entwickelt um sie zu registrieren, priorisieren und zuzuteilen. Darüber hinaus hatte ich den BS2000 Editor erweitert um die Änderungen in den Code zu platzieren und einen Trace-Pfad zu hinterlassen. Der schwedische Architekt hat mir damit geholfen. Im Rahmen dieses Projektes habe ich also schon begonnen mich mit der Softwarewartung zu befassen. Ich musste lernen, dass Software nie fertig ist.

Immerhin konnte das Produkt erfolgreich abgenommen werden und 1976 habe ich darüber einen Beitrag darüber in dem Integrata Handbuch der EDV veröffentlicht mit dem Titel „Planung, Organisation und Steuerung der Softwareherstellung und –wartung“. In diesem Beitrag ging ich auf die Rollen und Aufgaben eines Programmierteams ein.

Was ich darin weggelassen habe war die Rolle des Testers. Ich habe bald gemerkt, dass die Programmierer sich schwer taten mit dem Test und die meiste Zeit mit Testen verbracht haben. Erst gegen Ende des Projektes begann ich einen Testrahmen zu entwickeln mit Testtreiber, Teststubs und Testmonitor, aber es war eigentlich zu spät. Die meisten Module waren schon in Produktion. Das war jedoch für mich eine Lehre für die Zukunft. Fortan würde ich den Test in den Vordergrund stellen.

Mein Beitrag zum Integrata Handbuch endete mit einem Plädoyer für mehr Disziplin in der Softwareentwicklung:

„Lange Zeit galt die Programmierung als exzentrische Kunst und der Programmierer als freischaffender Künstler. darin steckt immer noch ein Kern Wahrheit. die Ideenfindung beim Entwurf eines komplexen DV-Systems sowie die Lösung verknoteter Kodierungsprobleme ist sicherlich ein Kreativer Akt. Ohne kreative Programmierer wird keine Software-Abteilung Erfolg haben. Man braucht ständig neue Ideen um voranzukommen.

Andererseits braucht eine Software-Abteilung Disziplin. Ohne Disziplin wird die Kreativität der Programmierer vergeudet. Sie werden ihrem Hang zum Spiel nachgeben, ihre Aufgaben selber definieren und sich immer weiter von den wahren Bedürfnissen der Anwender entfernen. Die Programmierung wird damit zum Selbstzweck.

Um diesen Zustand zu verhindern, ist eine aktive und fähige technische Führung erforderlich, die in der Lage ist Entwicklungs- und Wartungsprojekte zu planen, zu organisieren und zu steuern. Kreativität genügt nicht. Sie muss durch konkrete Ziele und strenge Kontrollen kanalisiert werden. Das gewünschte Ergebnis soll eine Synthese von Kreativität und Disziplin sein. Dies ist der Schlüssel zum Erfolg in der Herstellung und Wartung komplexer Softwareprodukte…“ [Sned77].

2.5.2 Mein erstes Reengineering Projekt

Im Leben eines Menschen gibt es bestimmte Schlüsselereignisse, die sein Leben in die eine oder die andere Bahn lenken. Bei mir waren es drei die dicht aufeinander folgten. Die erste war eine neue für mich absolut fremde Aufgabe. Das IQS Projekt, über das im letzten Kapital berichtet wurde, war abgeschlossen. Ich sollte beginnen mit einem Projekt zur Sanierung der SESAM Datenbanksystemsteuerung, mein erstes Reengineering Projekt. Das Steuerungsmodul zu diesem quasi-relationalen Datenbanksystem, das aus der gleichen Quelle wie das spätere Datenbanksystem ADABAS entsprang,