Ein wesentliches Hindernis, um die Integration in einem Unternehmen erfolgreich realisieren zu können, ist die Struktur der existierenden Anwendungssysteme. Denn bestehende Prozeduren der Softwareentwicklung laufen dem CIM-Gedanken an sich zuwider. Gerald Kitzinger* begründet, warum sein Unternehmen sich daher für Ada als CIM-Sprache entschieden hat.
Aus der CIM-Definition (siehe Kasten) wird klar, daß wir mit einer informationstechnischen Lösung nach diesem Prinzip im Unternehmen nicht mehr langer nur die außenliegenden Prozeduren automatisieren, sondern die Informationstechnik in den eigentlichen Fertigungsprozeß integrieren müssen. Dies bedeutet, daß die Informationstechnik Teil des Produktionsapparates ist. Damit ist es also unmöglich, ohne Informationstechnik beziehungsweise bei ihrem Versagen, weiterzuproduzieren. Die Unternehmen hängen von der Funktionsfähigkeit der Computersysteme in einer CIM-Organisation für die Produktion genauso ab, wie von ihren traditionellen Fertigungsmaschinen. Damit aber stellt sich automatisch die Frage nach der Qualität der Software.
Wird die Informationstechnologie in den Arbeitsprozeß integriert, sind die Anforderungen an ihre Qualität der Software.
Wird Informationstechnologie in den Arbeitsprozeß integriert, sind die Anforderungen an ihre Qualität genauso hoch zu setzen wie an den übrigen Produktionsapparat. Qualität hat dabei vor allem drei Aspekte:
- Verfügbarkeit, also Lauffähigkeit ohne Unterbrechungen, mit einer korrekten Verarbeitung und Ausgabe.
- Nutzung, also Bedienerfreundlichkeit und Unterstützung der eigentlichen Anwender und Benutzer beim Erfüllen ihrer Arbeit.
- Flexibilität bei Einführung und Nutzung.
Entscheidend ist hier, daß als Maßstab für die Qualität keine informationstechnischen Kriterien herangezogen werden können. Maßstab ist der Anwender und die von ihm benötigte Funktionalität.
Betrachten wir den Aspekt der Verfügbarkeit genauer, so erwarten Fertigungsunternehmen in der Regel von Maschinen eine Verfügbarkeit in der Gegend von 99,8 Prozent. Das gleiche müßte damit auch für die informationstechnischen Komponenten von CIM gelten. Die heutigen Hardwaresysteme haben dies Ziel erreicht. Zweifel sind bei den meisten Betriebssystemen, vor allem nach neuen Releases, angebracht.
Sehr starke Zweifel bestehen, ob Applikationssoftware heute generell diesen Standard erreicht. Man muß sich vor Augen halten, daß 99,8 Prozent Verfügbarkeit (etwa bei einem Zweischicht-Betrieb) bedeutet, daß die gesamte Ausfallzeit über ein Jahr gerechnet kleiner gleich sechs Stunden sein muß, je nach Matrix.
Geht man davon aus, daß selbst ein gut ausgetesteter Cobol- oder Fortran-Code zwischen 1,8 und 2,2 Fehler pro 1000 Zeilen Code hat, so dürfte diese Qualitätszielsetzung, wenn überhaupt, erst nach einer sehr langen Phase der Nutzung erreicht werden. Dazu kommt, daß einfach die Notwendigkeit besteht, Systeme periodisch anzupassen und zu verbessern, was sie zwangsläufig wiederum destabilisiert. Wir haben es hier mit einer klassischen Catch-22-Situation zu tun.
Darüber hinaus ist zu bedenken, daß natürlich drei Systemkomponenten, etwa Hardware, Betriebssystem und Applikationssoftware jeweils mit einer 99,8-prozentigen Verfügbarkeit zusammen keine ebenso hohe Verfügbarkeit haben, da Fehler die unangenehme Angewohnheit haben, sich zu potenzieren.
Die "Fix on Fail"-Mentalität vergangener Zeiten kann im Rahmen von CIM-Installationen nicht toleriert werden. Der Stabilisierungsprozeß darf nicht zu Lasten der Anwender gehen. Nach Untersuchungen von Strässle gibt es keinen Weg, diese Forderung mit den herkömmlichen Methoden der Programmierung in konventionellen Sprachen zu erfüllen.
Ähnlich verhält es sich bei dem nächsten Qualitätsaspekt der Nutzung. Je mehr Informationstechnologie in den eigentlichen Arbeitsprozeß integriert wird, je weniger können wir erwarten, daß Benutzer sich EDV-gerecht verhalten. Das Maß aller Dinge für Kommunikation mit dem Menschen kann und darf daher auf keinen Fall das Denken des Systementwicklers sein, noch weniger die Hardwaregegebenheiten des Systems. Die "menschengerechte"
Benutzeroberfläche, die in der Lage ist, natürlich zu kommunizieren, diese natürliche Kommunikation erst danach in für die Informationstechnologie verständliche Logik umsetzt, ist keine Forderung an die Zukunft, sondern ein Muß heute.
Diese Oberflächen müssen sich vom Benutzer selbst individuell anpassen lassen. Er muß in der Lage sein, sie für seine Bedürfnisse zurechtzuschneiden. Und seien es nur so triviale Dinge, daß ein Anwender, der schlecht sieht, die Schrift auf einem Bildschirm doppelt so groß repräsentieren kann. Die Forderung kann einfach nicht mehr lauten: Der Benutzer wird am Computer geschult, umgekehrt ist die korrekte Richtung: Informationstechnologie muß sich dem Benutzer anpassen.
Ganz entscheidende Bedeutung kommt hier einer variablen und flexiblen Technologienutzung zu. Wir müssen in der Lage sein, beliebig Grafik zu benutzen, Fenstertechniken auf großen Bildschirmen zu realisieren sowie Eingabe über Tastatur, Maus, Lichtstift, etc. zu ermöglichen. Änderungen der Oberfläche dürfen jedoch auf keinen Fall jeweils eine Änderung der Applikationsprogramme nach sich ziehen, da dies wiederum zur Destabilisierung führen würde und der Forderung nach hoher Verfügbarkeit entgegenstünde. Daß derartige Oberflächen auch offen für neue Technologien, etwa Sprach-Ein- und -Ausgabe und Hybrid-Präsentationsmedien sein müssen, versteht sich von selbst.
Bei der Qualitätsanforderung in Richtung Flexibilität haben wir es im Prinzip mit drei getrennten Kriterien zu tun, die zusammengenommen die Flexibilität eines CIM-Systems bestimmen.
Trotz Inselbereichen zur Integration kommen
Die Flexibilität bei der Implementierung ist wichtig. Betriebliche und wirtschaftliche Notwendigkeiten in den einzelnen Unternehmungen sind nicht identisch, die Reihenfolge der Einführung von Teilsystemen muß sich den Betrieben anpassen. Die durch die Software "Konstruktion" vorgegebenen Reihenfolgen stimmen nur im Sonderfall mit den Anforderungen des Betriebes überein. Darüber hinaus muß es im Rahmen einer CIM-Architektur möglich sein, parallel an der Einführung von verschiedenen, vorerst getrennten, Inselbereichen zu arbeiten und trotzdem am Ende zu einer Integration zu kommen.
Flexibilität ist aber auch bei der eigentlichen Anwendung nötig. Die Gesamtarchitektur des CIM-Systems muß so beschaffen sein, daß alternative Modelle für Planung und Steuerung eingeführt und benutzt werden können, ohne daß sich Umfeldapplikationen dadurch notwendigerweise ebenfalls ändern müssen. Es wäre tödlich für ein Unternehmen (und dies ist leider jedoch heute zumeist der Fall), wenn eine Änderung der Planungsmethode für den Fertigungsdurchlauf gleichzeitig Änderungen in der Materialwirtschaft, im Einkauf und in der Konstruktion erzwingen würden. Eine Integration, die derart starr ist, ist innovationsfeindlich und wird auf Dauer den betrieblichen Anforderungen nicht gerecht.
Der dritte entscheidende Aspekt der Flexibilität ist die Möglichkeit im Rahmen einer CIM-Architektur bestehende oder neue Fremdapplikationen und Lösungen zu integrieren und im positiven Sinne eine Koexistenz herzustellen. Dies ist unabdingbar, geht man davon aus, daß Unternehmungen heutzutage nahezu ausnahmslos Lösungsinseln installiert haben, von denen sie abhängen und die nicht einfach ersetzt werden können. Ein CIM-Ansatz, der allein auf das Endziel fixiert ist, ohne den Weg in Betracht zu ziehen, der ja notwendigerweise die Integration von bestehenden Inseln einschließen muß ist gefährlich und in den meisten Fällen vom wirtschaftlichen Aspekt her sinnlos.
Architektur von Funktion trennen
Faßt man nun diese Anforderungen zusammen und setzt sie in Software-Design-Kriterien um, so lassen sich für eine CIM-Architektur Regeln ableiten, die sich nur mit einem konsequenten Software-Engineeringansatz verwirklichen lassen.
Wir sehen die Notwendigkeit, eine strikte Trennung von Architektur und Funktion vorzunehmen, denn nur so ist die Einbindung von Fremdsystemen oder das Auswechseln von funktionalen Bereichen möglich, ohne die Lauffähigkeit der gesamten CIM-Installation zu gefährden. Unternehmungen rein vom Datenmodell (Relation-Entity) zu betrachten, ist gefährlich, da hier ein statisches Modell entsteht, das die Dynamik des Produktionsprozesses nicht nachbilden kann. Und schließlich ist die strikte Trennung von Funktion und Oberfläche ebenfalls notwendig. Es soll auf der einen Seite die unnötige Destabilisierung der eigentlichen Applikation durch Änderungen in der Oberfläche vermieden werden. Auf der anderen Seite soll trotzdem die flexible Anpassung an Benutzerforderungen in der Oberfläche möglich sein.
Die Architektur, der Architekturrahmen, ist damit eine separate Einheit, die unabhängig von den Funktionen definiert und implementiert werden muß. Die Architektur ist das Gefäß, in das verschiedenartige alternative Funktionen eingefüllt werden können. Es muß möglich sein, Funktionseinheiten auszutauschen, neue einzufügen oder einzelne zu ändern, ohne die Gesamtstruktur zu beeinträchtigen.
Trennung bei der Datendefinition
Die Notwendigkeit für strikte Trennung sehen wir ebenfalls bei der Datendefinition. Ein an sich statisches Datenmodell reicht nicht aus, um dynamische Prozesse zu beschreiben, daher sollte von den Prozessen her, von unten nach oben, ein logisches Datenmodell ausgehend von den einzelnen Funktionseinheiten aufgebaut werden. Die Generierung des physischen Datenmodells, also die Umsetzung in eine konkrete Datenbank, sei diese nun relational oder hierarchisch, verteilt oder homogen definiert, hat mit der eigentlichen Verarbeitungslogik wenig zu tun und sollte daher auch hiervon ferngehalten werden. Eine zu frühe Umsetzung in das physische Datenmodell oder die Verknüpfung des physischen Datenmodells mit der Architektur beziehungsweise mit den Funktionen, hebt jede Flexibilität auf und macht das System starr.
Diese Anforderungen führen eigentlich zwangsläufig zu einer Integrationsarchitektur, die auf Schnittstellenintegration beruht und nicht auf Datenintegration. Wer Ja sagt zu der Möglichkeit, alternative Funktionen einzusetzen, Funktionskreise auszutauschen, Fremdsysteme zu integrieren, kann logischerweise keine Integration über Datenbanken fordern, da dies Veränderungen an den Applikationen voraussetzen würde, die diese destabilisieren würden.
Der Versuch, heterogene Applikationen über eine Datenbank zu integrieren, ist unter den Qualitätsaspekten Verfügbarkeit und Flexibilität ungünstig und den Zielen zuwiderlaufend.
Bei der Schnittstellenintegration ist es wichtig, genormte Handhabungen, Strukturen und Prozeduren zu haben. Strässle hat dafür spezielle Techniken für die Integration über Schnittstellen entwickelt, die den Individualaufwand für die Definition reduzieren, Testbarkeit gewährleisten und das Risiko vermindern.
Von den Qualitätsanforderungen her entstand auch die Forderung, bei der Implementierung von Funktionen, also bei der eigentlichen Programmierung der Applikationen, radikal neue Wege zu beschreiten. Flexibilität und Nutzbarkeit, aber auch die mit der hohen Verfügbarkeit erzwungene Notwendigkeit, Applikationen wesentlich besser als bisher zu testen, verbieten es, Funktionseinheiten von vornherein zu größeren Programmen zusammenzubinden, wie wir es etwa von Cobol oder Fortran her gewohnt sind.
Es ist notwendig, logische Funktionseinheiten zu definieren, mit ihrem logischen Datenmodell zu implementieren und getrennt zu testen. Der Einbau dieser Funktionen in die eigentliche Architektur sowie die Generierung des physischen Datenmodells (beziehungsweise der physischen Datenmodelle) sollte erst gemäß den spezifischen Anforderungen der Anwender mittels Automatenlogik erfolgen. Die variablen Anforderungen der Zielumgebungen müssen ohne Kompromiß erfüllbar sein.
Gründlichere Tests als bei Programmen
Diese Art der Implementierung ermöglicht wesentlich gründlicheres Testen, als es bei Programmen der Fall ist. Gleichzeitig jedoch werden die aufwendigen Regressionstests überflüssig die bei Systemen, die über Daten integriert sind, unabdingbar sind.
Zusätzlich wollten wir mit dieser Art der Implementierung eine bessere Wartbarkeit der Systeme erreichen. Der eigentliche Code ist, da er sich weder mit der Oberfläche, noch mit dem Datenhandling befaßt, wesentlich besser lesbar, die Dokumentation ist besser. Wir planen darüber hinaus, mit dieser Methodik zu einem späteren Zeitpunkt auf die sogenannte Designwartung überzugehen, die es ermöglicht, Systeme, die auf einem Design basieren, aber verschieden implementiert sind, zentral zu warten.
Konkret sehen Systeme dann wie folgt aus: Wir haben den operationalen Code strikt durch klare Schnittstellen von der Anwenderoberfläche und vom physischen Datenmodell getrennt. Der operationale Code ist als Prozeß ausgebildet, die Zusammenfügung der Prozesse zum System innerhalb der Architektur wird durch Automatenlogik vorgenommen. Bei Änderungen der physischen Datenimplementation oder Anwenderoberfläche ist jeweils nur der nach außen gerichtete Teil der Oberfläche anzupassen.
Das Vorprodukt, das zu dieser Art der Implementierung führt: Die Funktionen sind jeweils mit ihrem lokalen logischen Datenmodell separat gespeichert. Die für die spezielle Applikation notwendigen Funktionen werden identifiziert. Da die lokalen logischen Datenmodelle über das logische Gesamtmodell miteinander verknüpft sind, werden auch Sekundärdaten beziehungsweise Sekundärprozesse, die später für die Lauffähigkeit des Systems entscheidend sind, mit identifiziert. Mittels Automaten wird der Code zusammengestellt, und die notwendigen Informationen zur Generierung der physischen Datenbanken aus dem logischen Datenmodell entwickelt.
Diese Art der Implementierung war jedoch nicht mit herkömmlichen Programmiersprachen wie Cobol durchzuführen. Wir benötigen eine Sprache, die diese Architektur komplementieren würde, gleichzeitig die Qualität des Objekt-Codes, also weniger Fehler im Code verursacht und trotzdem eine gute Wartbarkeit herstellen könnte. Zusätzlich mußte die Implementierungssprache individuelle Anpassungen und Ergänzungen nicht nur zulassen, sondern aktiv unterstützen und in ein den Architekturanforderungen gemäßes Software Engineering Environment einbettbar sein.
Es war klar, daß wir eine Sprache mit innenliegender Strukturvorgabe benötigen, um die Einheitlichkeit des Vorgehens und der Logistik unabhängig vom einzelnen Programmierer sicherzustellen. Neben all den hier aufgeführten Forderungen war besonders bedeutsam, daß die Sprache jeden in die Lage versetzen mußte, die Datendefinition getrennt von der eigentlichen Datenbankdefinition vorzunehmen. So kamen konventionelle Sprachen wie Cobol, Fortran, aber auch C, nicht in Frage.
Konventionelle Sprachen kamen nicht in Frage
Nach einem längeren Untersuchungsprozeß fiel die Entscheidung für die Sprache Ada. Ausschlaggebend für die Entscheidung war die Tatsache, daß die Sprache streng genormt ist. Sie ist von ihrem Aufbau her für die von uns angestrebte Architektur geeignet. Sie ist portierbar, sie garantiert exzellente Wartbarkeit und letztlich und endlich wurden wir durch die Tatsache ermuntert, daß weltweit wesentliche Investitionen in die Pflege und Weiterentwicklung dieser Sprache gehen. Gegen Ada als Sprache standen eigentlich nur zwei Argumente: das schlechte Image und der Mangel an Know-how bei der heutigen Generation der Programmierer.
Ada ist eine problemorientierte Programmiersprache der vierten Generation, die basierend auf Spezifikationen des amerikanischen Verteidigungsministeriums entwickelt wurde. Die Zielrichtung der Sprache ist die Fehlerfreiheit, die Portierung auf beliebige Hardware ohne Rücksicht auf das Betriebssystem, die Echtzeit-Orientierung und die Möglichkeit der Wiederverwendung von Teilen. Ada ist Muß-Sprache im militärischen Bereich.
Suche nach einem geeigneten SE-System
Parallel mit der Identifikation der Sprache lief die Suche nach einem geeigneten Software-Engineering-System, mit dem wir unser konsequentes Software-Engineering-Konzept umsetzen können. Es war von vornherein klar, daß wir ab dem Zeitpunkt der Einführung alle Projekte unter strenger Beachtung der Software-Engineering-Methoden durchführen wollten. Als Grundlage nahmen wir den sogenannten Software Lifecycle als Phasenkonzept. Ziel war es vor allem, bei den der Implementierung vorgelagerten Phasen, die künstlerischen Freiräume auszuschalten, das heißt, Fehlerquellen auszuräumen, die durch die Interpretationsfähigkeit der jeweils übergebenen Dokumente automatisch in den Entwicklungsprozeß hinein kommen. Oberstes Ziel war die Sicherstellung unserer Qualitätsanforderungen mit einem System.
In der Analysephase legten wir hohen Wert auf Strukturbildung und Kommunikation. Wir konnten mit reinem "Relation Entity Modeling" nicht zufrieden sein. Methoden nach Art "Petrinetze" werden von uns bevorzugt. Vor allem, da wir hierdurch Nebenlauffähigkeiten modellieren und Schnittstellenverhalten untersuchen können. Prototyping ist ebenfalls auf dieser Basis möglich.
Im Design lag die Priorität auf korrekter Umsetzung von Gedanken und auf Erarbeitung präziser, nicht mehr interpretierbarer Vorgaben für die eigentliche Implementierung. Wichtig war auch die parallele Führung der Dokumentation. Wir haben uns schließlich für einen Ansatz auf Basis von PDL entschieden, da wir hierdurch formal prüfbare Schnittstellenbeschreibungen erhalten. Dieses Vorgehen ist konform mit dem Einsatz von Ada.
Bei der Implementierung hätten wir gerne eine effiziente Umsetzung des Pseudocodes in die eigentliche Sprache gehabt. Hier allerdings sind immer noch einige Haken und Ösen, an deren Beseitigung wir zusammen mit dem Lieferanten des Software Engineering Environments arbeiten. Entscheidend für uns war darüber hinaus, daß die Software-Engineering-Umgebung nicht nur die Implementierung unterstützt, sondern auch gleichzeitig durchgehend bis zur Verifizierung, also dem eigentlichen Testen, den Life Cycle begleitet. Nach Überprüfung mehrerer Systeme fiel die Entscheidung für "Epos". Die Hauptentscheidungsfaktoren waren:
Die Durchgängigkeit des Gesamtsystems
- Es waren sicher Systeme vorhanden, die in einzelnen Phasen stärker sind, aber keines konnte die konsequente Durchgängigkeit nachweisen.
Methodenvielfalt
- Wichtig war, daß Epos die Methoden bot, die wir anwenden wollten - und dies vollständig.
Projektmanagement
- Das Vorhandensein eines integrierten Projektmanagements war für uns ebenfalls ein wesentliches Entscheidungskriterium.
Die Hardwareplattform für das Gesamtsystem besteht aus drei HP-9000-Anlagen in Stuttgart, die alle jeweils grafische, interaktive Arbeitsplätze haben und eine Vielzahl von alphanumerischen Terminal (diese sind zumeist PCs). Verbunden hiermit über Datex P ist eine PCS-Cadmus-Anlage, die im Strässle-Ada-Beratungszentrum in Lorsch steht und auf der ebenfalls Epos gefahren wird. Diese Umgebung ist über einen LAN mit der Test- und Entwicklungsumgebung für unser PPS-System PSK 2000 und für CAD verbunden, das sich aus mehreren HP-Prozessoren zusammensetzt. Angeschlossen hieran ist wiederum eine Data-General-Systemumgebung, die aus drei Anlagen besteht. Auf einem DG-System fahren wir im Moment ebenfalls noch eine Epos-Version.
Unsere Erfahrungen sind nach zirka sechs Monaten Einsatz sehr positiv. Wir sind der Überzeugung, daß CIM-Architektur und -Implementierung auf die Dauer ohne konsequentes Software Engineering, sowohl im Ansatz als auch in den Methoden und Werkzeugen, nicht machbar ist. Unser Ziel ist es, mit der Zeit ein umfassendes sogenanntes APSE zu entwickeln (Ada Programming System Environment), das unsere Vorhaben noch vollständiger unterstützt.
Noch ein Wort zur Arbeitsbelastung: Durch die konsequente Anwendung des Software Engineerings waren wir in der Lage, die Entwicklung von der Architektur zu trennen und separat zu betreiben. Dies gibt uns erhöhte Flexibilität. Es zeigt sich bereits jetzt, daß sich der Aufwand für die einzelnen Phasen innerhalb der Projekte verschiebt. Generell kann man sagen, daß mehr Zeit für Design Analyse aufgewendet wird, weniger für Implementierung und vor allem für das Testen. Dies ist durchaus konsistent mit unserem Denkansatz.
Bei der Realisierung Probleme erwartet
Bei der Realisierung haben wir allgemein relativ große Schwierigkeiten erwartet und uns entsprechend gewappnet. Gleichzeitig eine vollständig neue Sprache und ein durchgängiges Software Engineering Environment einzuführen, ist sicher keine einfache Sache. Wir waren jedoch überrascht, wie wenig Widerstände wir im einzelnen hatten, obwohl zu sagen ist, daß der eine oder andere Mitarbeiter eine längere Phase der Umgewöhnung benötigte. Vor allem sogenannte "Machertypen" (Devise: "Schreiben wir erst mal ein Programm") hatten Probleme mit einem konsequenten Software-Engineering-Ansatz, bei dem Stufe für Stufe hierarchisch abgearbeitet werden muß. Insgesamt kann man sagen, daß die Erwartungen erfüllt wurden.
*Gerald Kitzinger ist Mitglied der Geschäftsleitung der Strässle Unternehmensgruppe, Stuttgart