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.

27.08.1976

Programme müssen konstruiert werden

Dr. rer. nat. Roland Schneider

Entwicklungsleiter des Dokumentations- und Programmiersystems DPS (DEMAG,Programmiersystem) bei Gemini Computer Systems Deutschland GmbH in Düsseldorf

Progamme müssen konstruiert werden

EDV ist heute die unsicherste Technologie. Man stelle sich vor, der Automobilbau hätte erst einen solch unsicheren Stand erreicht. Dann müßten wir bei einer zweitätigen Urlaubsreise damit rechnen, daß wir sieben Systemzusammenbrüche erleben. Auf unser Auto übertragen bedeutet ein Systemzusammenbruch: Aus allen Reifen ist die Luft raus, Benzin, Öl und Wasser sind restlos ausgelaufen, und wir müssen mühsam mit Reservekanister, Ölbüchse und Luftpumpe unser Auto wieder fahrbereit machen. Wer von uns würde sich damit abfinden, mehrmals am Tage?

In der EDV herrschen vergleichsweise noch Fahrlässigkeit und Leichtfertigkeit in einem Maße, wie sonst in keinem anderen Industriezweig. Als Hauptursache kann man getrost das Fehlen des Wissenschaftszweiges konstatieren, der heute als Software-Technologie bezeichnet wird.

Die Elektrotechniker, Maschinenbauer, Bauingenieure - um nur einige zu nennen - haben längst umfassende Theorien. Und sie haben eine klare Trennung von Konstruktion und Fertigung. Die Konstruktion erfolgt auf der Basis einer vorhandenen Theorie, deren Zuverlässigkeit innerhalb gewisser Bereiche durch systematische Meß- und Prüfmethoden gesichert ist.

Jedes gefertigte Objekt wird auf Übereinstimmung mit der Konstruktionszeichnung und auf sein Verhalten in einigen ausgewählten Situationen Überprüft. Die Konstruktion muß sicherstellen, daß in allen anderen vorgesehenen Situationen ebenfalls das gewünschte und nach der Theorie zu erwartende Verhalten eintritt.

Auf die Software übertragen brauchen wir zuerst eine Theorie als Basis der Software-Konstruktion. Die Software, die Programme müssen konstruiert werden. Betriebssicherheit und Zuverlässigkeit der Software müssen die wichtigsten Ziele einer solchen Konstruktionslehre für Software und Programme sein, gefolgt von Flexibilität, Wartungsfreundlichkeit, Austauschbarkeit. Die meist viel zu stark betonte technische Effizienz kann als letztes rangieren. Da sind wir ohnehin schon weit genug durch die im Gegensatz zur SoftwareTechnologie vorhandene und ausgereifte Hardware-Technologie. Eine Software-Konstruktionslehre, die sich an den technischen Realitäten orientiert, wird technische Effizienz von selbst gewährleisten.

Nur ein konstruiertes Programm sollte gefertigt, also programmiert werden. So wie eine konstruierte Steckplatte durch Zusammenfügen und Löten von Transistoren, Widerständen - usw. gefertigt wird. Wir müssen das Programmieren trennen in Programmkonstruktion und Programmfertigung. Die Programmfertigung ist wie das Löten bestimmt der harmlosere Teil.

Die Ansätze für eine Theorie der Programmkonstruktion sind bescheiden, aber vorhanden. Am weitesten scheinen die Compilerbauer zu sein, weit danach dürften die weniger erfolgreichen Betriebssystemkonstrukteure einzuordnen sein.

Als zweites braucht die Software-Technologie eine Fertigungstechnik. Sie sollte uns weniger Kopfzerbrechen bereiten. Denn es ist ein technisch und wirtschaftlich zu betrachtender Aspekt, ob maschinelle oder manuelle Fertigung, halb- oder vollautomatisch, mit oder ohne Verwendung von Lagerteilen zweckmäßig ist. Wenn die Konstruktionsmethoden erst gesichert sind, wird die Bereitstellung maschineller Hilfsmittel zur Fertigung nicht lange auf sich warten lassen, zumal auf dem Software-Sektor die Fertigungstechnik der Programmkonstruktionslehre weit voraus eilt.

Als drittes muß die Software-Technologie um Prüf- und Testmethoden erweitert werden. Die gebräuchliche Methode, etliche Fälle durchaus systematisch zu prüfen, reicht nicht aus. Es muß zwischen Prüfungen unterschieden werden, deren Ziel es ist, erstens Konstruktionsfehler und möglicherweise Grenzen der Theorie aufzudecken und zweitens solchen, die nur die Übereinstimmung von Programm-Konstruktion und Programm bestätigen sollen. Solange die Theorie mangelhaft oder sehr unvollständig ist, sind die ersteren besonders wichtig. Wenn die Theorie ausgereift ist, werden Konstruktionsfehler seltener und können meist vor der Fertigung erkannt werden. Fehler in der Fertigung können durch gute Fertigungsmethoden sehr reduziert, aber niemals ausgeschlossen werden. Die Übereinstimmung von Konstruktion und Programm kann durch Tests niemals vollständig nachgeprüft werden. Daher sind die letztgenannten Prüfungen durch eine dritte Art die laufenden Stichprobenkontrollen in der Tagesproduktion, zu erweitern, was in anderen Industriezweigen erfolgreich praktiziert wird.

Vor einiger Zeit erzeugte die Nachricht Aufsehen, dafür eine Firma in der EDV eine Abteilung für Qualitätssicherung ins Leben gerufen hat. (CW Nr. 17 vom 23. April 1976 Interview der Woche "Produktsicherung als Qualitätskontrolle für DV-Bereich".) Man fragt sich, warum das nicht schon längst überall üblich ist.