Betrifft CW Nr. 48 vom 26. November 1993, Seite 1: "Time to market ist mit Cobol nicht zu realisieren"
Time to market ist weder mit Cobol noch mit 4GL zu realisieren! Der Anteil des Low-Level-Designs und der Codierung, und nur hier treten die Vor- und Nachteile von Sprachen zutage, ist im Vergleich zum Gesamtzeitraum "Time to market", also von der Idee bis zum auslieferbaren Produkt, sehr gering. Grosszuegige Schaetzungen gehen von 20 Prozent aus, andere Aussagen gehen sogar unter die Zehn-Prozent-Grenze, vor allem, wenn man Marketing und Vertriebsaufwaende mit in den "Time-to-market"-Zeitraum einrechnet.
Der Loewenanteil bei der Entwicklung von neuen Produkten liegt eher in der Umsetzung von Technologien in Softwarekomponenten. Hier sind Erfahrung und Augenmass gefordert, die dann zu einem schluessigen Softwarekonzept fuehren muessen. Im Gesamtablauf spielt die Codierung eine relativ geringe Rolle. Selbst integrierte 4GL- Systeme, die zur Zeit, neben den bekannten Nachteilen, vermutlich die hoechste Produktivitaet nachweisen koennen, koennen den notwendigen Uebersetzungsvorgang fuer organisatorische Ablaeufe und Technologien nicht beschleunigen.
Die gerade jetzt immer notwendiger werdende Erhoehung der Softwareproduktivitaet, und damit sind keine prozentualen Verbesserungen, sondern Vervielfachungen gemeint, koennen nur durch Wiederverwendung von Technologie, von fertigen Softwarekomponenten erreicht werden. Diese Wiederverwendbarkeit haengt natuerlich sehr stark von Standards ab, die sich aber auch im PPS-Bereich immer mehr abzeichnen.
Wo sind die Komponenten im PPS-Bereich, die wiederverwendet werden koennen? Es koennen natuerlich ganze Standardprodukte sein, die ueber intelligente Schnittstellen zu einem Komplettsystem gekoppelt werden.
Leider reicht das oft nicht aus, da die einzelnen Softwareprodukte meist auch noch fuer den Kunden konfiguriert werden muessen. Hier hilft ein Bausteinkonzept.
Damit koennte dann eine Flexibilitaet erreicht werden, in der technologische Einzelschritte frei komponiert werden koennen und man nahezu ohne Programmie- rung im herkoemmlichen Sinne einer prozeduralen Programmiersprache wie C oder Cobol auskommt.
Diese feine technologische Granularitaet war mit der bisherigen SW- Technik nicht zu erreichen, weder mit Sprachen der dritten noch der vierten Generation. Erst ueber die neueren Ansaetze aus der Objektorientierung erscheinen solche Vorstellungen erreichbar.
In einer objektorientierten Betrachtung eines PPS-Systems wird zum Beispiel das PPS-Objekt "Auftrag" nicht nur durch seine interne Datenstruktur mit Auftragsnummer, Status, Auftragsart etc. repraesentiert, sondern auch durch die Methoden, das heisst durch die Funktionen, die mit diesem Auftrag durchgefuehrt werden koennen, wie zum Beispiel Anlegen, Verschieben, Terminieren, Freigeben, Simulieren und einiges mehr.
Diese kleinen Einzelschritte koennen dann entweder direkt mit den Ereignissen des Benutzerdialogs angestossen werden oder auch ueber eine einfache Makrosprache zu Anweisungsgruppen nach Kundenwunsch zusammengestellt werden.
Auf dieser Ebene, und nur auf dieser, kann sich die notwendige Produktivitaet entfalten, mit der "Time to market" erzielbar wird. Die Programmiersprache ist dabei von voellig untergeordneter Bedeutung.
Eberhard v. Wietersheim
PSI Gesellschaft fuer Prozesssteuerungs- und Informationssysteme mbH, Hamburg