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.

30.04.1982 - 

ADV-Tagung über Software-Entwicklungswerkzeuge:

Suche nach selbstkorrigierendem Zeichenbrett

WIEN (eks) - Im Einleitungsreferat der ADV-Tagung "Werkzeuge zur Entwicklung von EDV-Anwendungen" umriß Professor Kerner von der TU-Wien Strategien gegen die Softwarekrise. Herstellervorträge und Anwenderberichte gaben dann einen systematischen Überblick der meisten in Österreich verfügbaren Softwaretools.

Aus der mittlerweile Gemeingut gewordenen Verteilungskurve der relativen Kosten von Hardware, Software-Entwicklung und Software-Wartung (etwa 25 Prozent, 15 Prozent und 60 Prozent der EDV- Gesamtkosten mit weiterhin zunehmendem SW-Anteil) leitet Kerner seine erste Strategie ab. Sie heißt: Keine Programmierkünste zur Hardware-Einsparung.

Die Behebung eines Fehlers, der erst während des Einsatzes entdeckt wird, kostet ein Vielfaches davon, was die Behebung während der Entwicklung kostet.

Daraus folgt die zweite Strategie: Lieber mehr Entwicklungsaufwand oder SW-Beschaffungskosten, wenn dadurch die Wartung (also Änderungen und Fehlerkorrekturen) vereinfacht werden können.

Zwei Drittel aller Fehler entstehen in den Phasen vor der Realisierung, sind also Analyse- oder Entwurfsfehler. Nur ein Drittel sind Codierungsfehler. Daher die dritte Strategie: Schwerpunkt bei Werkzeugen, die Frühphasen unterstützen.

In einer Untersuchung von 63 Softwareprojekten mit einem Gesamtumfang von etwa 500 Mannjahren analysierte B. W. Boehm 1980 in den USA den Einfluß verschiedener Faktoren auf die SW-Produktivität.

Die Untersuchung zeigte, daß ein erfahrenes und überdurchschnittliches Team viermal so produktiv war wie ein unterdurchschnittliches mit Unterstützung durch SW-Tools. Andererseits kann jedoch ein unterdurchschnittlicher Stab mit allen Entwicklungsunterstützungs-Werkzeugen praktisch ebenso produktiv sein wie ein überdurchschnittlicher ohne Hilfsmittel.

Sicherlich ist Produktivität etwas recht mühsam zu Definierendes und noch schwieriger zu Messendes Setzt sie sich doch nicht nur aus Programmzeilen zusammen, sondern eben auch aus Termintreue, vermiedenen Fehlern, Flexibilität gegenüber Änderungen während des Projekts und im künftigen Einsatz sowie Erfüllung von Benutzeranforderungen unter gegebenen Hardwarerestriktionen. Daher wird der überdurchschnittliche Stab mit alle Hilfsmitteln kaum 25mal produktiver sein als der unterdurchschnittliche mit nackter Faust, wie es sich nach Anwendung aller Faktoren ergäbe. Auch ist zu berücksichtigen, daß US-Anwendungsprogramme meist wesentlich weniger komplex sind als europäische, was vermutlich auch den Wert von Werkzeugen beeinflußt. Was in Amerika eine Drehbank ist, erweist sich in Europa oft genug als Beißzange.

Jedenfalls gilt als vierte Strategie: Erhöhung der Produktivität im SW-Entwicklungsprozeß.

Für den Anwender verwirrend ist die große Zahl ihm angebotener Werkzeuge, unter denen sich auch viele mit schönem Namen, aber geringer Wirkung befinden. Kerner klassifiziert Werkzeuge nach

- Funktion

- Niveau

- Anwendungsgebiet

- Grad der Integration von Entwicklungsphasen

- Niveau der Beschreibungssprache

- Phasen des Einsatzes im SW-Lebenszyklus (siehe Abbildung).

Zunächst stößt der Benutzer auf das Problem der vergleichenden Bewertung von Werkzeugen. Dies wird ihm allerdings im allgemeinen durch das vorhandene System insofern abgenommen, als die Portabilität von Werkzeugen heute noch gering ist. Der Nixdorf-Benutzer beispielsweise hat keine Chance Autoform einzusetzen, so sehr es ihm auch gefallen mag.

Nächste Schwierigkeit ist trotz aller Produktivitätsaspekte die Rentabilitätsrechnung. Denn die Aufwände für Neuentwicklung und Wartung des Vorhandenen verhalten sich heute wie eins zu vier. Und die alten Programmbestände sind für moderne Tools nicht zugänglich. Ist ein Werkzeug zusätzlich nur teilweise oder gar nicht über mehrere Projektphasen integriert, so sinkt die Einsatzmöglichkeit weiter. Derartigen Überlegungen ist allerdings entgegenzuhalten, daß eine Benutzungsfrequenz noch nichts über den Bedarf aussagt. Auch die Toilette in einer Wohnung wird, verglichen mit anderen Räumen nur geringfügig genutzt. Trotzdem fiele es niemandem ein, darauf zu verzichten.

Schließlich stellt sich noch die Frage der Integration verschiedener Werkzeuge untereinander. Also noch viel Arbeit für die Werkzeugmacher.