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.

TOOLKONFLIKTDivergierende Konzepte kennzeichnen die aktuelle Marktsituation für SW-Produktionsumgebungen. Vier Thesen zu dem Thema stellte die COMPUTERWOCHE sieben Software- und Systemhäusern in einer Blitzumfrage zur Diskussion. Die Antworten machen al

08.03.1985

- garantieren. Nicht mehr die gute Idee und Realisierung wäre entscheidend, sondern überwiegende Masse und Macht.

Die übertriebene Forderung der totalen Integration und der totalen Abdeckung verhindert lediglich, daß ein Anwender zum Beispiel neben der Hochsprache des Anbieters A das bessere Projektmanagementsystem des Anbieters B anwenden kann. Hinzu kommt, daß derartige "Dinosaurier" nur für große Anwender, die überwiegend große, komplexe Systeme realisieren, erschwinglich und rentabel wären.

Zu These 2:

Die nicht genormten Sprachen und die Sicherheit des SW-Lieferanten sind nicht das Hauptproblem. Wer kann wissen, ob nicht in einigen Jahren das ganze Konzept der Hochsprachen überholt ist - so wie vor einigen Jahren RPG für viele Anwender überholt war - und bessere Methoden und Werkzeuge verfügbar sind.

In diesem Fall steht der Anwender vor dem gleichen Problem: er muß umstellen (meist = Neuerstellung) oder das alte Werkzeug weiter bezahlen. Das Problem liegt also darin daß die meisten Ersteller von Hochsprachen ihr Produkt als Alternative zu den prozeduralen Sprachen empfinden.

Gute Hochsprachen hingegen sind "stubenrein" wie gute Hunde, sie hinterlassen keinen Code, den man nicht anfassen kann. Sie setzen die Eingaben des Anwenders um in ein gut wartbares Programm einer genormten Zielsprache (beispielsweise Cobol), das ohne weitere Eingriffe des Anwenders ausgeführt wird.

Das hat den Nachteil, daß dus Ergebnis erst nach einigen Minuten vorliegt. Dem stehen jedoch wesentliche Vorteile gegenüber: Die Anwendungen sind gesichert, unabhängig von dem SW-Lieferanten oder von der Weiterverwendung des Werkzeuges, da die erzeugten Programme zeitlos und unabhänig von allen Modeerscheinungen sind.

Die Anwendungen können - einschließlich Pflege - an Benutzer weitergegeben werden, die nicht über das Werkzeug verfügen, und sie lassen sich über die Möglichkeiten der Hochsprache hinaus erweitern oder optimieren.

Trotz anderslautender Behauptungen einiger Anbieter oder der Möglichkeit, eigene Unterprogramme einzubinden: Hochsprachen verfügen über eine geringere Flexibilität als prozedurale Sprachen, da sie leicht anwendbar bleiben sollen. Das führt in der Praxis dazu, daß Anwendungen entweder in der Hochsprache oder ohne Unterstützung des Werkzeuges in einer prozeduralen Sprache realisiert werden (alles oder nichts).

Ein nach den oben genannten Regeln konzipiertes Tool hingegen bietet bei den komplexeren Anwendungen einen nahtlosen Übergang vom Komfort einer Hochsprache zur Flexibilität einer prozeduralen Sprache.

Zu These 3:

Hier sei auf die Erläuterungen zu These 1 verwiesen, da sie die gleiche Fragestellung wie These 1 betrifft, es ist gewissermaßen die "Kontrathese" zur "Prothese" 1. Sie gibt jedoch Gelegenheit, noch etwas zur Situation der SW-Lieferanten zu sagen, die in ihrer Personalkapazität nicht den in These I geforderten Gigantismen entsprechen.

Wenn ein Softwarehaus ein gutes Konzept realisiert und gleichzeitig mit anderen Softwarehäusern, die in anderen Teilbereichen des SW-Engineering ebenfalls gute Konzepte realisiert haben (zum Beispiel ProjektManagement-Systeme und so weiter), kooperiert oder Schnittstellen abstimmt, ist die Integration trotzdem realisierbar und der Anwender hat Gelegenheit, die für ihn optimalen Tools auszuwählen.

Es wäre also wichtig, daß mehr Softwarehäuser den Mut zur Kooperation hätten (nicht zuletzt wegen These 1).

Zu These 4:

Selbstverständlich wird langfristig kein Softwarehaus umhinkönnen, seine Produkte der IBM-Welt zugänglich zu machen, aber doch nicht nur! Denn hier gilt wie bei den Softwarehäusern: die Größten sind ja nicht unbedingt und überall auch die Besten. Außerdem: was ist mit den armen, aber vielen DOS-Anwendern?