DALLAS (CW) - Die meisten Programmstrukturen sind Überwiegend von den eigenen Vorstellungen des Entwicklers geprägt. Geht die Kreativität mit dem Softwarekünstler durch und verletzt er dabei die allgemein anerkannten Regeln, stehen sehr schnell alle Zeichen auf Sturm: Selbst erfahrene Systemanalytiker finden sich dann bei nachfolgenden Wartungsaufgaben nicht mehr zurecht.
Abhilfe will hier eine Forschungsgruppe der Yale University im US-Bundesstaat Connecticut schaffen. Elliot Soloway, Assistant-Professor an der Hochschule Yale, warnte anläßlich einer Tagung zum Thema "Maintenance" in Dallas vor den Folgen einer solchen "Selbstverwirklichung".
"Es gibt einen Riesenunterschied zwischen dem Verstehen eines IF-Statements und dem Know-how, diese Erkenntnis in ein lauffähiges Programm umzusetzen", konstatierte die Experte für künstliche Intelligenz. Jede natürliche Sprache folge bestimmten grammatikalischen Regeln; ähnliches gelte auch für die Programmierung. Ein unorthodoxer Umgang mit einer Computersprache könne genauso ins Auge gehen wie eine ungeschickte Ausdrucksweise in einer "normalen" Sprache.
Debugging läßt SW-Profis zu Anfängern werden
Als Beweis für die Richtigkeit seiner Behauptungen verwies Soloway auf die Ergebnisse einer Untersuchung, die an der amerikanischen Elite-Universität durchgeführt wurde. Das Forschungsteam experimentierte mit jeweils zwei Versionen desselben Programms: einer korrekten Fassung und einer, die in einigen Punkten vom allgemein anerkannten Weg abwich.
Belegt werden sollte Soloways Hypothese, daß die Leistungsfähigkeit eines Super-Programmierers auf die Effizienz eines Anfängers reduziert wird, wenn er erst einmal ein fehlerhaftes Programm "entwanzen" muß. "Das Befolgen der Ablaufregeln ist notwendig, um einen guten Code zu erstellen", gab der Yale-Experte zu bedenken. Je mehr ein Programm aktualisiert und erweitert werde, desto weniger gehorche es für gewöhnlich den sanktionierten Ablaufgesetzen. Fazit: Die Wartung arte zur Sklavenarbeit aus (siehe CW Nr. 21 vom 24. Mai 1985, Seite 15, "Gut gepflegte Programme sind ein wertvoner Aktivposten").
Um die Maintenance-Probleme noch krasser herauszuarbeiten, führte Soloway einen Versuch mit Top-Softwerkern und Programmier-Neulingen durch: Jede der beiden Gruppen bekam zwei Stunden Zeit, um zwei Erweiterungen in einem Programm vorzunehmen. Am Ende der vorgegebenen Zeit hatten 55 Prozent der "alten Hasen" und 25 Prozent der "Greenhorns" ihre Aufgabe mehr oder weniger erfolgreich abgeschlossen.
Interessant erschien den Testern die unterschiedliche Aufteilung der zur Verfügung stehenden Zeit in den beiden Gruppen. Die Profis verwendeten im Schnitt zwölf Minuten auf das Lesen der Dokumentation, sechs Minuten auf das Studieren der vorgegebenen Aufgabenstellung, 36 Minuten auf die Programmanalyse und gut eine Stunde für die reine Codierung.
War bei den "Newcomern" das Ergebnis in den ersten beiden Punkten noch identisch, so ergaben sich im folgenden entscheidende Abweichungen: Auf die Programmanalyse wurden lediglich gute zehn Minuten verwendet, die Restzeit entfiel aufs Codieren.
Kommentierte Soloway: "Die Experten ließen sich mehr von Gedankenmodellen leiten. Wenn sie sich mit Dokumentation und Code auseinandersetzten, so geschah das mehr oder weniger, um die eigenen Erwartungen bestätigt zu sehen. Die Anfänger hingegen klebten am Code."
Die ausgefuchsten Praktiker versuchten bei der Codeanalyse erst einmal, die Qualifikation des Programmentwicklers abzuschätzen. Bekamen die Mitglieder dieser Testgruppe den Eindruck, sie hätten es mit dem Produkt eines Könners zu tun, verlief die weitere Arbeit relativ problemlos.
Sobald die Top-Leute allerdings auf Unstimmigkeiten in der Software stießen, wurden sie mißtrauisch. Sie fingen an, alles in Frage zu stellen und verloren sich im "If-Then-Dschungel".
Nach Abschluß ihrer Analyse machten sich die erfahrenen Tüftler zuerst einen Ablaufplan für die zu bewältigende Aufgabe. Die unerfahrenen Programmierer hingegen glaubten, sich diese Mühe sparen zu können - sie stürzten sich gleich Hals über Kopf auf die Codiererei.
"Die Profis setzten weitaus stärker ihre Beobachtungsgabe ein", resumierte Soloway, "sie arbeiteten wesentlich mehr mit der Dokumentation und versuchten zunächst, sich einen generellen Überblick zu verschaffen."
Mangelhafte Dokumentation blockiert Programmpflege
Setze man hingegen Neulinge auf Debugging und Programmerweiterungen an, könne die Sache sehr unproduktiv werden, warnte der Spezialist: "Maintenance wird viel zu oft Leuten übertragen, die keines der ursprünglich verwendeten Programm-Modelle im Kopf haben".
Deshalb Bit-Tüftler und Code-Fuchser auf Wartungsaufgaben anzusetzen, ist nach Ansicht der amerikanischen Forscher aber noch keine Erfolgsgarantie. Die Gefahr sei groß, so die Ergebnisse der Untersuchung, daß die Kreativität mit den "alten Hasen" auch bei der Maintenance durchgehe. Ein anderer Wartungsprogrammierer habe dann kaum noch eine Chance, die verschlungenen Gedankenpfade seines Vorgängers zu durchblicken.
Allerdings sei ein solches Chaos im softwaretechnischen Unterholz nicht notwendigerweise ein Fehler des ursprünglichen Entwicklers.
Vielmehr sei das Übel nicht selten auf eine - mangelhafte Dokumentation zurückzuführen. Wenn diese keine Aufschlüsse darüber gebe, welche Prinzipien das Management in der Software realisiert sehen wolle, könne man dem Programmierer keinen Vorwurf machen. DV- Chefs sollten deshalb strikt darauf achten daß die Dokumentation über Maintenance-Ziele- und -Plane des Unternehmens detaillierten Aufschluß gibt, riet Soloway.