Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

25.05.1979

"Standard-Anwendungen verkaufen den Schnee von gestern"

Mit Jörg E. Richter, Geschäftsführer der ADVIS Software-Partner KG, Hannover, sprachen Dieter Eckbauer und Elmar Elmauer

- Herr Richter, ADVIS bot auf der Hannover-Messe Software- Werkzeuge für die Programmentwicklung an und als Neuheit in Online-Version für Siemens und IBM-Maschinen einen Dialogarbeitsplatz für die gesamte Programmentwicklung, Dokumentation und für den dialogischen Test. Haben Sie denn ein bißchen Konkurrenzvergleich gemacht: Wer bietet denn noch tatsächliche Online-Programmierung, wer machteÆ s möglich ? Und bei wem istÆ s nur eine achtzigstellige Erfassung?

Ich kann ohne Übertreibung sagen, wir sind so ziemlich die einzigen, die wirklich eine Programmentwicklung im Dialog machen. Denn untergliedern wir mal den Begriff Programmentwicklung in die drei Parts, die ihm zukommen. Und zwar erstens das Programmdesign oder der Programmentwurf, zweitens die Programmierung, die sich wieder untergliedert in a: Kodierung, und b: Test. Damit haben wir als Ebenen also Entwurf, Kodierung und Test. Alles das, was Sie bis jetzt im Dialog sehen konnten was zwar alles als Programmentwicklung im Dialog bezeichnet wurde, behandelt aber gar nicht die Programmentwicklung: Es schloß vielmehr den Programmentwurf aus, und behandelte ausschließlich die Programmierung - das Coding im Dialog und unter Umständen auch das Testen im Dialog, obwohl bei den meisten ein dialogisches Testen im wahren Sinne gar nicht möglich ist.

- Bisher ist der größte Zeitgewinn bei der Kodierung, bei der reinen Zeilenschreiberei rausgeholt wurden. Können Sie durch tatsächliche Online-Programmentwicklung die Phase der Entwicklung des Entwurfs verkürzen und fehlerfreier gestalten?

Das machen wir dadurch, daß wir die Philosophie auf den eigentlichen Programmentwurf ausgerichtet haben, also auf den Teil der Programmentwicklung, der den größten Arbeitsaufwand ausmacht. Wir decken überhaupt keinen Zeitvorteil in der Kodierung ab, weil die Kodierung unserer Erfahrung - und das ist ja allgemein bekannt - nur 20 Prozent des gesamten Systementwicklungsprozesses ausmacht. Die Software-Werkzeuge ADVIS-Serie 400 sind ausgerichtet auf den Programmentwurf, und im Rahmen des Programmdesigns auf den Programmtest.

- Sie sind naturgemäß von Ihrem neuen Produkt überzeugt: Aber ist es das Ende einer Entwicklung? Oder haben Sie bei der Realisierung des Konzeptes festgestellt, daß hier doch noch einige Dinge abzudecken sind?

Sicher werden wir immer wieder auch unsere Produkte den neuen Erkenntnissen anpassen, aber: Wir erheben ja nicht den Anspruch, mit diesen Software-Werkzeugen nun den gesamten System-Entwicklungsprozeß abzudecken, ganz und gar nicht. Der System-Entwicklungsprozeß besteht ja wiederum aus drei wesentlichen. Teilen, erstmal die konkrete Definition einer Aufgabenstellung, zweitens die vernünftige Systemschnittbildung und drittens die Beschreibung des Systems und die Dokumentation - und hierbei müssen wir unterscheiden: Die Beschreibung des deklaratorischen Teils eines Systems und andererseits die Beschreibung des prozeduralen Teils. Wenn Sie das alles mal nehmen, dann bieten wir mit der Serie 400 zum Beispiel keine Hilfe für die deklaratorische Beschreibung, wir bieten eine sehr wirksame Hilfe für die prozedurale Beschreibung eines Systems, also für den zeitlich logischen Ablauf, für die Darstellung der Strukturen und für die Darstellung der Systemhierarchie. Alles andere überlassen wir den Produkten, die bereits erfolgreich am Markt sind.

- Aber auch Sie gehen mit der Werkzeugentwicklung in Richtung Entwurfsund Designverbesserung?

Richtig.

- Lassen sich durch solche Tools die Zeitanteile bei der Produktion eines Programms zugunsten der Entwicklung beschleunigen? Oder wird der Fortschritt beim Kodieren dem Fortschritt beim Entwurf weiter voraneilen?

Ich glaube schon, daß durch den Einsatz dieser Werkzeuge ein gewisser Zeitvorteil zu erreichen ist. Wir haben es in der Praxis erlebt, daß man mit einer bestimmten Routinezeit mit diesen Werkzeugen schneller Systementwicklung betreiben kann - nur liegt unser Hauptschwergewicht nicht unbedingt darin schnellere, sondern vor allem bessere Systeme zu entwickeln: qualitativ besser in bezug auf Lesbarkeit und funktionale Richtigkeit.

- Wieviel Pflegeaufwand, wieviel Nachbesserung ist später Ihrer Erfahrung nach notwendig, weil ein Programm vom Design her spießt?

Grundsätzlich ist es so, daß zwei Drittel der Systemfehler beim Entwurf passieren, und ein Drittel bei der Kodierung. Und es ist grundsätzlich so, daß die Programmpflege und -wartung aufgrund eines schlecht lesbaren Programmentwurfs etwa das zwei- bis vierfache der Entstehungskosten ausmachen.

- Herr Richter, welche Bereiche decken denn Ihrer Meinung nach Programme wie SPMO und EFTS von IBM oder PET von Softlab ab?

Die Tools, die IBM anbietet, sind nach meiner Einschätzung darauf ausgerichtet, eine bestimmte Übersicht in die Programme hineinzubringen, mit denen speziell IBM-Anwendungen gemacht werden. Wenn Sie sich mal das Konglomerat der Spaghetti-Programmierung angucken, die alleine dadurch hervorgerufen wird, daß CICS-Systeme implementiert werden müssen, wobei die Aera der 60er Jahre mit ihrer Spaghetti-Programmierung und die Codierung hier Fortsetzung findet. Wenn Sie sich in der Praxis angucken, welche Klimmzüge die Programmierer machen müssen, um CICS-Anwendungen zu realisieren und wie nicht lesbar diese Systeme sind, dann muß natürlich von seiten der IBM hier etwas geliefert werden, was gerade eine solche Anwendung auch in der Zukunft auf Datenbank- und Dialog-Anwendung lesbarer macht. Ich sehe nicht, daß die IBM bestrebt ist, nun grundsätzlich Transparenz in den ganzen Systementwicklungsprozeß zu bringen. Ich sehe eher, daß die IBM bestrebt ist, Transparenz nur soweit zuzulassen, wie sie den Marktinteressen dieses Herstellers entgegenkommt.

- Welche Nachteile hat die Undurchsichtigkeit für den Anwender?

Die Nachteile für den Anwender bestehen darin, daß er einmal mehr Maschinenzeit für den Systemtest benötigt. Denn nicht lesbare Systeme verursachen erhöhten Testaufwand und wenn man ein System funktional richtig stellen will, indem man seine Arbeit auf den Test verlagert, dann hat man so ziemlich die teuerste Systementwicklung. Auf der anderen Seite muß man berücksichtigen, daß man dadurch natürlich mehr Manpower gewinnen wird und ich kann mir nicht vorstellen, daß irgendein Hersteller - auch die IBM nicht - an Anwendung von höherer Manpower Interesse haben kann.

- Herr Richter, wenn man es mal vom Marktanteil her sieht, dann haben sicher IBM-Anwender den größten Anwendungsappetit und IBM-Programmierer - also jetzt an IBM-Installationen - den größten Berg an Arbeit auf dem Tisch liegen. Wenn die Wirkzeuge, die IBM jetzt anbietet - wie Sie andeuteten, nicht optimal sind - warum ergreifen Sie nicht die Chance, eine Alternative zu IBM zu bieten, die sich auch verkaufen lassen müßte?

Ich glaube schon, daß wir mit der Serie 400 eine Alternative zu dem gesamten Angebot ans Tools bieten, nicht nur das Angebot von IBM, sondern auch von anderen Anbietern. Grundsätzlich halte ich es aber nicht für richtig, wenn man eine Tool-Philosophie auf das Coding aufbaut, sondern ich halte es für sehr viel richtiger, wenn man versucht, vom Programmdesign her soviel Automatismus hineinzubringen, daß das Coding nur noch zur Nebensache wird.

- Nun hat aber gerade die Praxis gezeigt, daß sich bei dieser höchst komplexen Aufgabe, im Bereich des Entwurfs praktikable Lösungen zu bieten, eben einige Softwarehäuser übernommen haben. Denen fehlte die Manpower, denen fehlte das Kapital. Kann so etwas vielleicht doch nur der große Hersteller machen ?

Sie müssen eins sehen: Wenn Sie Software-Tools entwickeln, dann haben Sie es mit einem Systementwicklungsprozeß zu tun wie bei sämtlichen anderen Anwendungen oder anderen Softwareprodukten auch. Sie können also für ein Produkt, das eine ganz bestimmte methodische Vorgehensweise unterstützt, wenn es hoch kommt ein Vier- bis Sechs-Mann-Team einsetzen. Auch IBM ist nicht in der Lage, durch größeren Einsatz von Manpower bessere Tools zu entwickeln. Die Schwierigkeit liegt einzig und allein in de Vermarktung. Die kleineren Softwarehäuser - und ich zähle unser Haus zu den kleineren Häusern - haben ja die Schwierigkeit die Software entsprechend zu vermarkten. Auf der anderen Seite bin ich der Auffassung, wenn Sie Versuchen Softwaretools zu vermarkten, ohne den methodischen Background dabei zu kennen, dann können wir wie die IBM weitermachen. Ich habe bis jetzt nicht gesehen, daß IBM in den vergangenen Jahren vor den wirklich schlagkräftigen Softwarehäusern auch nur eine einzige brauchbare Methode für den gesamten Programmentwurf und für die Programmrealisierung rausgebracht hätte. Wir sprechen von IPT, wir sprechen von HIPO, alle diese Dinge haben sich, obwohl sie von IBM kamen, nicht auf dem Markt durchgesetzt. Deshalb räume ich den kleineren Softwarehäusern in diesem Punkt eine ebenso große Chance ein wie den großen Herstellern.

- Aber, Herr Richter, wenn schon IBM solche Dinge nicht vermarkten kann, wie wollen es dann die kleinen Softwarehäuser schaffen?

Dadurch, daß in erster Linie das Know-how der Anwender durch Methoden-Training auf einen Level gebracht wird, daß sie in der Lage sind, gerade den Software-Tool-Markt zu beurteilen. Dann, da bin ich sicher, wird der potentielle Anwender sehr wohl unterscheiden können, wo die Qualitätskriterien der einzelnen Methoden und Werkzeuge liegen.

- Sie sagten, man müsse das Verständnis bei den Anwendern für derartige Supertools dadurch erhöhen, daß man das Know-how anhebt. Damit ist doch ein kleines Softwarehaus schlichtweg überfordert. Wäre nicht der direkte Weg besser, solche Produkte dem Hersteller selbst anzubieten, weg vom Endbenutzermarkt, hin zum Software-OEM? Wäre das ein Weg in die Zukunft?

Ich will den Weg nicht ausschließen. Ich kann nur aus unserer Sicht sagen, wir haben in dem letzten Jahr 1978 zum erstenmal den Geschäftsbereich Methoden-Training ins Leben gerufen, wir hatten über 300 EDV-Manager als Teilnehmer auf unseren Seminaren. Die Folge davon waren eine Kette von In-Haus-Seminaren und wir haben feststellen können, daß der Schneeballeffekt bei diesem Know-how-Transfer sehr hoch ist, dadurch nämlich, daß die potentiellen Teilnehmer ja in irgendwelchen Guides sitzen. Sie finden auf der anderen Seite auch kein so großes Personalpotential auf dem Markt, daß Sie nun mit Macht in eine Seminarveranstaltung gehen könnten, so wie es die IBM beispielsweise in den 60er Jahren mit den Programmiertechniken gemacht hat. Es gibt nur ganz wenige Instruktoren, die in der Lage sind, praxisbezogen die Technik und die Methodik, die wissenschaftlichen Ansätze zu erklären und eine Brücke zwischen Wissenschaft und Anwendung zu schlagen. Und wenn uns das zu einem kleinen Part in dem letzten Jahr gelungen sein sollte, dann bin ich damit schon zufrieden.

- Setzen wir jetzt mal - analog zur Hardware, bei der das technisch Machbare fast erreicht ist - das gedachte Ideal in bezug auf die Produktivität von Software mit 100 an. Wo stehen wir denn jetzt auf der Skala?

Ich würde sagen: Die Methoden und Techniken, die wir für die Software haben, können heute weit über dieser fünfzig-Prozent-Schwelle liegen. Ich möchte fast sagen, wir haben eine technologische Basis, die bis zu 75 oder 80 Prozent hinaufreichen könnte - die Praxis sieht leider anders aus. Aber an der Stelle möchte ich gerne eine Aussage unterbringen: Man versucht ja jetzt verstärkt mit Standardanwendungs-Software den Preisverfall der Hardware zu kompensieren. Dies ist ein völlig ungeeignetes Mittel. Denn wenn Standard-Software ausgereift sein soll muß sie mindestens 50 oder 100 Mal beim Kunden installiert und erprobt sein. Dann stammt sie heute aber aus der Ära der frühen 70er Jahre, zwischen 1970 und 75 sind diese Dinge irgendwann mal entwickelt worden. Jedenfalls zu einer Zeit, als die technologische Basis für die Softwareproduktion fast gar nicht vorhanden war. Man verkauft heute mit Standardanwendungs-Software den Schnee von gestern und versucht damit, die Software-Misere in den Griff zu bekommen. Das ist ein gänzlich falscher Weg. Man soll jetzt mal Standardanwendungs-Software nach den Erkenntnissen der heutigen Technologie produzieren.

- Dafür kündigt IBM den Blütenregen von übermorgen an.

Das hat IBM immer getan

- Ist das der richtige Weg, zu Anwendungssoftware zu kommen, die wirklich einsetzbar ist?

Ich sehe den Weg für die Standardisierung der Anwendungen dadurch, daß man kleinere Einzelfunktionen in einer Funktionsdatenbank unterbringen sollte. Deshalb sollte man nach der heutigen Philosophie ein Unternehmen erst mal in die einzelnen Bereiche aufsplitten und nach den Grundsätzen der Systemtheorie, von oben nach unten herunterbrechen, und zwar bis zur untersten Funktionsebene. Aus diesen Funktionen kann man eine Funktionsdatenbank bekommen, für die es dann letzen Endes möglich ist, eine funktionale Programmierung durch funktionale Gliederung und Programmkomposition durchzuführen. Dies ist der Weg und nicht einfach fertige Anwendersysteme anbieten, an die sich der Anwender ja doch irgendwie a anpassen muß, statt daß es umgekehrt wäre und sich die Software an die Bedingungen der Anwender anpaßt.

- Herr Richter, wie weit haben denn Leute, die sich heute als DV-Spezialisten e mit der Erstellung von Anwendungs-Software

befassen, die Betriebswirtschaft verstanden?

Die Betriebswirtschaft zu verstehen, ist schon deshalb Aufgabe eines Softwarehauses, weil ja ein Softwarehaus selbst produktiv tätig sein muß. Wenn Sie die Ökonomie des gesamten Marktes ansprechen, glaube ich nicht, daß Softwarehäuser irgendwann in der Lage gewesen waren, einen Trend zu verhindern den Die Softwarehäuser nicht angerichtet haben, sondern für den ganz andere verantwortlich sind.

- Die Frage zielte auf den Unternehmungs-Organismus ab. Wie weit sind denn Leute, die Anwendungen programmieren, überhaupt imstande, betriebswirtschaftliche Zusammenhänge in einem Unternehmen über die Schnittstelle hinaus zu berücksichtigen?

Ich habe die Frage noch nicht ganz verstanden!

- Programmierer kommen in der Regel von der DV her und sollen den Organismus Betrieb in den Griff kriegen, ohne diesen Organismus, ohne die Betriebswirtschaft zu kennen. Das ist doch das Problem!

Das ist richtig, wenn Sie Programmierer meinen. Aber man muß doch sehen, daß man Leute die Software produzieren, nicht einteilen darf: Man darf nicht die Organisation von der Programmierung trennen: Dies muß man als Einheit sehen. Man muß auch sehen, daß auch die Leute, die zum Fachbereichsmanagement gehören, am Softwareentwicklungsprozeß beteiligt sind. Sicher darf man eines dabei nicht vergessen: Der technische Fortschritt hat natürlich an bestimmten Stellen irgendwas überholt und es fällt eben manchen, die in den letzten zehn Jahren erfolgreich aktiv gewesen sind, schwer, sämtliche technischen Neuerungen zu berücksichtigen.

- Uns scheint es aber generell so zu sein, als wären sehr oft weder Programmierer, noch Systemanalytiker in der Lage, betriebliche Zusammenhänge zu sehen: Die hauen darauf los und machen eine Beteiligtenlösung diese in sich zwar sicherlich stringent, aber. . .

Ich glaube nicht, daß Systemanalytiker und Programmierer dafür verantwortlich sind. Ich bin eher der Auffassung, daß diejenigen, die eine EDV-gerechte Lösung in Auftrag geben, verantwortlich sind.

- Ist das nicht Verantwortung einfach abwälzen?

Nein, Sie müssen die Arbeitsteilung berücksichtigen. . .

- Aber der Manager sagt doch nur: Ich will dies oder jenes Ergebnis haben! Und der Fachmann sagt, das kriegst du nur in der und der Form, mit den und den Restriktionen.

Wir sind uns einig, daß das noch viel zu oft passiert und wir sind uns darüber (...) klaren, daß das falsch ist. Aber: Je mehr die Software Möglichkeiten bietet, (...) Wünsche der Auftraggeber wirklich (...)befriedigen, desto mehr werden auch (...) Probleme dann verschwinden.

- Aber bisher mußte vorwiegend die Hardware solche Wünsche befriedigen. (...) Software ist dem Wunsch des (...), des Managements, langsamer (...) gengekommen.

Das kann man so nicht sehen. Es gibt(...) keine Hardwaretechnologie, (...) einen solchen Wunsch befriedigen (...). Denn man muß die Hardwaretechnologie immer im Zusammenhang (...) der Software sehen und ohne die Software ist der Weg gar nicht denkbar. Wenn Sie darauf abheben, daß die Hardware an irgendeiner Stelle einen Schritt vorausgehen wollte, dann ist das auch insofern nicht richtig, als die Anforderungen, die an Hardware- und Softwarelösungen gestellt werden, immer insgesamt gesehen wenden müssen . . .

- . . . schon, bloß Herr Richter, Hardware wird nach ingenieursmäßigen Gesichtspunkten entworfen . . .

. . . ich hoffe, Software in Zukunft auch.

- Ja, in Zukunft. Nur jetzt ist Software noch Kunst. Und insofern ist die Integration der Datenverarbeitung im Betrieb immer an den Schwächen der Software gescheitert, nie an den Schwächen der Hardware.

Das ist völlig richtig, da stimme ich Ihnen zu. Deshalb sehen wir auch den größten Rationalisierungseffekt für die nächsten Jahre in der Anwendung der softwaretechnischen Möglichkeiten. Räumen Sie doch den Softwarehäusern oder Softwareherstellern, da sind die Hardwarehersteller auch damit gemeint räumen sie diesen diese Zeitspanne doch einmal ein.

- Aber offensichtlich haben die größeren Hersteller nach wie vor kein Zutrauen zu den Softwarehäusern. Deshalb nehmen sie bisherige Kernfunktionen der Software mehr und mehr in die Maschine hinein. Die sagen sich: Was in Hardware gelöst ist, kann in Software nicht mehr verhunzt werden.

Die Motivation für eine solche Denkweise ist eine völlig andere. Die Hardwarehersteller wissen sehr gut, daß sie auf die Innovation der Softwarehäuser nicht verzichten können. Wir beispielsweise, das kann ich für unser Haus sagen, werden von den Hardwareherstellern, die Rang und Namen haben, bombardiert mit Anfragen, ob wir nicht in irgendeiner Weise für die Leute tätig werden wollen. Nicht nur Manpower sondern Know-how. Denn wir sind als Softwarehaus in der Lage, aufgrund unserer Know-hows, das wir in Methoden und Werkzeugen zugrunde gelegt haben, die Hardware-Hersteller zu befruchten. Wenn Hardwarehersteller ganz bestimmte Funktionen hardwaremäßig so realisieren, daß sie von der Software nicht mehr verhunzt werden kann, dann gibt es nur ein einziges Argument dafür: Das ist ein Profitdenken der Marktmacht, um Mixed-Software für die Zukunft zu verhindern und nichts anderes.

- Steckt nicht doch noch ein anderer Gesichtspunkt dahinter. Man will zwar schon diesen Bedarf an Standardanwendungen abdecken. Da diese Standardanwendungen aber noch nicht vorhanden sind, hält man den Anwender mit Versprechungen hin und geht für zwei, drei Jahre auf Tauchstation um genau diese Dinge zu realisieren, um dann den anwendungs-, benutzungsfreundlichen Computer anbieten zu können, der quasi als Black Box die komplette Anwendung enthält.

Richtig.

- Halten Sie diesen Weg für richtig, den Anwender für eine gewisse Zeit von den Entwicklungsüberlegungen auszuschließen . . .

. . . was halten Sie denn von mir. Ich kann doch nicht einen Weg für richtig ansehen, der den Markt hinhält. Auf der anderen Seite muß man eines dabei bedenken: Wenn die Hardwarehersteller die neue Technologie bei der Produktion der neuen Anwendungssoftware wirklich berücksichtigen, dann würde es sich für den Anwender tatsächlich lohnen, die Jahre abzuwarten. Aber der Hersteller sollte das nicht damit tun, daß er den Anwender für dumm verkauft, sondern den Anwender ob dieser Dinge wirklich aufklären. Aber das was wir hier sehen ist doch eine Autorität, die von den Hardwareherstellern ausgekippt wird. Und autoritäre Erziehung ist genau das, was wir nicht wollen.