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.

20.06.1980

Neue Wege in der Proglammierung - ganz alt

Wer heute aufmerksam die EDV-Fachzeitungen liest, dem kann angst und bange werden. Die Kosten für Hardware nähern sich dem Taschenrechner-Niveau, für Software-Entwicklungen müssen aufgrund steigender Personalkosten Millionen investiert werden. "Die Programmierung stirbt aus, Standardpakete machen das Rennen", hört man bisweilen. Die zweite Aussage ist richtig, die erste nicht. Individualprogrammierung wird immer notwendig sein, und Standardpakete müssen auch programmiert werden.

Ausgehend von einer Lebensdauer von sechs Jahren für ein EDV-Projekt, müssen ein Drittel der Gesamtkosten für die Entwicklung und zwei Drittel für Wartung und Pflege aufgewandt werden. Das heißt: Planung und Architektur (die Geistesarbeiten) werden stiefmütterlich behandelt, während Wartung und Reparatur (die Handwerksarbeiten) Vorrang haben. Das deckt sich mit Untersuchungen, die ergaben, daß zirka 60 bis 65 Prozent der entdeckten Fehler im EDV-Projekt in der Planungs- und Analysephase gemacht wurden. Woran liegt das?

Sehen wir uns seine 08/15 Programmiergruppe an. Ein Programm soll erstellt werden. Nach kurzer gedanklicher Problemdefinierung setzt sich der Programmierer ans Terminal und tastet die ersten Befehle ein (Einführungstermin und Entwicklungskosten sind bereits zwischen Verkäufer beziehungsweise EDV-Abteilung und Anwender vertraglich festgelegt). Aller Augen richten sich nun erwartungsvoll auf den Programmierer in wochen- oder monatelanger Tag- und Nachtarbeit entsteht ein undurchschaubares Programmungetüm. Der Programmierer ist überfordert.

Nachdem die zweite Nachfrist verstrichen ist, der Kunde ungehalten reagiert, wird man nervös. Die Geschäftsleitung übt stärker Druck aus, die Anstrengungen der Programmierer verdoppeln sich, und irgendwann kommt das Programm schließlich doch noch zum Laufen. Es bleiben Ärger, Sorge und ein bitterer Nachgeschmack. So war es vor 15 Jahren - und heute ist es nicht anders.

Viele Programmierer arbeiten planlos. Sie lieben die Codierung und stürzen sich dann ohne Vorbereitungen darauf. Je mehr man sich dem Ende des Projektes nähert, desto umfangreicher und schwieriger sind die Probleme. Gerade wenn die Planungs- und Architekturphase vernachlässigt wird, häufen sich die Probleme. Ein unerfahrener Programmierer und der läßt besonders gern die Planungsphase aus - steht dann fast unüberwindlichen Aufgaben gegenüber. Das Projekt wird nicht mehr kalkulierbar, die Kosten steigen unaufhörlich, Termine können nicht genannt werden.

Hier setzt die Wissenschaft ein und versucht, durch neue Programmentwicklungs-techniken dem Dilemma zu begegnen. Da entstehen Generatoren, Bildschirmentwik-klungstechniken und so weiter. Das ist gut und wichtig, sonst würden wir in der Entwicklunq stehen hleiben.

þOft sind es erst Ansätze zur Lösung, die sich in langwierigem Prozeß zur praktikablen Anwendung abschleifen müssen.

þDie Sprache der Generatoren ist teilweise so kompliziert wie eine Programmiersprache. Der Programmierer kann damit zusätzlich überfordert werden.

þViele Generatoren verlangen eine interaktive Arbeit am Bildschirm und können so nicht die Denkarbeit der Planung und Architektur ersetzen.

Ich bin überzeugt, daß sich die Probleme in der Programmierung auf wenige Punkte konzentrieren:

þEs fehlt an Ausbildung und Erfahrung. Die EDV ist so kompliziert geworden, daß man mindestens fünf Jahre praktische Erfahrung braucht, um als "mittelqualifizierter Programmierer zu gelten. Wo gibt es diese Leute in der geforderten Zahl?

þEs mangelt an der Fähigkeit, systematisch und methodisch vorzugehen.

þEs fehlt an Disziplin, an Beweglichkeit. Man ist zu träge und zu bequem. Wieviele besuchen Seminare, erarbeiten neue Techniken, sind von der Effizienz dieser Techniken überzeugt. Aber wer hält sich daran? Das ist ein Disziplin-Problem!

Beim Militär und in der Industrie findet man das weniger. Warum? Frühzeitig wurde hier unter Erfolgszwang jeder Prozeß analysiert, wurden Arbeitsschritte festgelegt, Ziele vorgegeben, Maßstäbe gesetzt, Kontrollen eingeführt. Daraus entwickelte sich ein Verfahren. Die Basis für die Kalkulation von Termin und Kosten war gelegt.

Auch in der Programmierung gibt es feste Arbeitsschritte, für die man Ziele, Maßstäbe und Kontrollen formulieren kann. Ein erfahrenes Team wird nach gründlicher Ausarbeitung die einzelnen Arbeitsschritte wie Analyse, Codierung, Compilierung und Test formulieren und definieren können.

Zu jedem Punkt können wiederum mehrere Unterpunkte und Checklisten entwickelt werden. Diese Phasen müssen bei jedem Projekt in bestimmter Reihenfolge durchlaufen werden. Dabei kann ein Problem dann mit einem Arbeitseinsatz gelöst werden, der gleichmäßig über den Entwicklungszeitraum verteilt ist.

Ein Problem bleibt ungelöst: die Disziplin und Trägheit. Hier sei das Management aufgerufen, etwas zu unternehmen. Vorbild sein, Motivieren, Überzeugen ist ein guter Weg.

Um die Ergebnisse der Programmierung zu verbessern, sind nicht unbedingt moderne Programmentwicklungstechniken notwendig.

Dem langfristigen Ausbildungsplan für die Mitarbeiter folgt eine intensive Grundausbildung in Sprachen und System. Vorbilder aus dem Management und den Mitarbeitern leiten die Kollegen zu Disziplin und Beweglichkeit an. Ein erfahrenes Team arbeitet ein Konzept für methodisches Vorgehen in der Programmierung und bildet die Mitarbeiter aus Ständige Überwachung des Managements sichert den Erfolg.