zurück zur Startseite der Softwaretechnik-Trends , zu Band 15 Heft 4

Klassische Fehler in der Software-Entwicklung

CEFE - CAD/CAM-Entwicklungsgesellschaft
Arbeitsgruppe 19 Software Engineering1

Einleitung

In diesem Artikel werden einige typische Fehler behandelt, die im Rahmen der Software-Entwicklung häufig auftreten. Anhand von allgemein gehaltenen Beispielen zu den Ursachen, den möglichen Folgen und entsprechenden Maßnahmen soll das Problembewußtsein der Entwickler und ihrer Vorgesetzten zu den einzelnen Punkten gestärkt werden. Obwohl viele dieser Fehler zwar seit langem bekannt sind, ist die Vermeidung dieser Fehler trotzdem weitaus schwieriger, als es auf den ersten Blick scheint. Bei immer kürzer werdenden Entwicklungszyklen und ständig steigender Komplexität der äußeren Rahmenbedingungen muß mit dem zur Verfügung stehenden Budget in möglichst kurzer Zeit qualitativ hochwertige Software entwickelt werden, die außerdem noch entsprechenden Konkurrenzprodukten überlegen ist. Die Kosten für die Beseitigung von Produktmängeln stellen in der Regel direkt entgangenen Gewinn dar. Der Entwicklungsprozeß ist deshalb unter vertretbarem Aufwand so zu gestalten, daß Mängel gar nicht erst auftreten.

Übersicht

Die einzelnen Fehler werden zunächst in Kategorien eingeteilt, die zum Teil mit den Phasen des Software-Entwicklungssprozesses identisch sind. Anschließend werden im nächsten Kapitel zu jedem der Fehler verschiedene Ursachen, Folgen und Maßnahmen zur Vermeidung dieser Fehler im Detail ausgeführt.

Vorgehensmodell:

Verifizierung und Validierung: Problem- und Systemanalyse: Systementwurf: Codierung: Betrieb und Wartung:





Abbildung: Einflußfaktoren auf die Fehlerkosten betrachtet über den Lebenszyklus



Erläuterungen

  1. Vorgehensmodell

    Das Vorgehensmodell zerlegt den Software-Entwicklungsprozeß in überschaubare Phasen und definiert Aktionen und Ergebnisse. Erst dadurch kann der Schritt von ''chaotischer Software-Bastelei'' zur industriellen Software-Produktion vollzogen werden. Ist ein unstrukturiertes Vorgehen bei Quick & Dirty Wegwerf-Software noch zu tolerieren, so hat das bei allen Systemen, die einer Wartung unterliegen, vernichtende Konsequenzen. Das Fehlen oder auch Nichtbefolgen eines Vorgehensmodells bedeutet, daß der Software-Entwicklungsprozeß nicht beherrscht wird.

    Ein Vergleich: Ein Schreiner, der eine Tür bauen soll, nimmt das Maß auf, läßt sich die Details der Tür vom Bauherren (schriftlich) bestätigen, fertigt eine Skizze an, stellt Tür und Zarge in der Werkstatt her, geht zur Baustelle und setzt sie ein. Käme der Mann aus der Software-Entwicklung, unterläge er der Versuchung, sein Werkzeug und einen großen Stapel Holz aus dem Lager an die Baustelle zu transportieren und dort solange zu sägen, bohren, schrauben und hämmern, bis das Loch in der Wand geschlossen ist, mit mehr oder minder zufälligem Ergebnis.

    Und dort liegt die Krux in der Software-Entwicklung. Die Umgebung gestattet es in der Regel, bis zum letzten Moment an dem Produkt zu ändern, ohne daß man es diesem sofort ansieht, während der Schreiner aus dem Beispiel ohne sein strukturiertes Vorgehen den Auftrag nicht mit wirtschaftlichem Erfolg und für den Kunden zufriedenstellend abschließen könnte. Das geht auch in der Software-Entwicklung nicht, nur merkt man es nicht so schnell!

    Software-Projekte laufen immer Gefahr, Termin und Budget zu überschreiten. Durch die Zerlegung in überschaubare Phasen gewinnt man mit einem Vorgehensmodell Planungssicherheit und erhält durch die eingebauten Meilensteine und Verifizierungen ein Lenkungsinstrument, mit dem frühzeitig Abweichungen erkannt und Korrekturmaßnahmen ergriffen werden können. Eine Koordination mehrerer in das Projekt eingebundener Personen oder Stellen ist ohne Vorgehensmodell praktisch nicht möglich. So wird oft bei großen und kritischen Projekten das anzuwendende Modell vom Auftraggeber (z.B. ESA) vorgeschrieben.

    Es wird direkt mit der Codierung angefangen

    Ursachen:

    Folgen:

    Maßnahmen:

    Das Vorgehensmodell fehlt bzw. wird nicht befolgt

    Ursachen:

    Folgen:

    Maßnahmen:

    Die Terminvorgaben sind unrealistisch

    Ursachen:

    Folgen:

    Maßnahmen:

    Die Weiterbildung der Mitarbeiter ist nicht zielgerichtet

    Ursachen:

    Folgen:

    Maßnahmen:

    Auswahl und Einsatz der Werkzeuge bzw. Methoden ist unzureichend vorbereitet

    Ursachen:

    Folgen:

    Maßnahmen:

    Ein Risikomanagement wird nicht betrieben

    Ursachen:

    Folgen:

    Maßnahmen:

  2. Verifizierung und Validierung

    Qualitätsprüfungen müssen in jeder Phase des Entwicklungsprozesses durchgeführt werden. Idealerweise sollte jedes Zwischenprodukt überprüft werden: Definition, Spezifikation, Entwurf, Code, Benutzer-Dokumentation, mit einem Wort: alles.

    Um diese Prüfungen und Tests durchführen zu können, muß selbstverständlich vorher definiert werden, welche (Qualitäts-)Eigenschaften die jeweiligen Zwischenprodukte haben sollen. Das heißt, daß aus den Anforderungen an das Endprodukt die Anforderungen an das jeweilige Zwischenprodukt abgeleitet werden müssen.

    Qualitätssicherung wird in der Software-Entwicklung durch Verfikations- und Validierungs-Aktivitäten geleistet. Bei der Verifizierung wird die Frage ''Haben wir das System richtig entwickelt?'' beantwortet, d.h. es wird geprüft, ob es die Anforderungen der Spezifikation der jeweiligen Entwicklungsphase erfüllt. Die Validierung hingegen soll die Frage ''Haben wir das richtige System entwickelt?'' beantworten; es wird überprüft, ob die Anforderungen des Kunden erfüllt werden.

    Wir können und sollten prüfen jede Spezifikation bezüglich ihrer internen Folgerichtigkeit und Widerspruchsfreiheit, jede Spezifikation (außer der ersten) in Hinblick auf die Vorgänger- Spezifikation (Vollständigkeit, genaue funktionale Entsprechung), jedes Programm-Modul bezüglich der zugehörigen Spezifikation auf Vollständigkeit und funktionale Gleichwertigkeit, jedes Programm-Modul hinsichtlich der internen Folgerichtigkeit und Widerspruchsfreiheit

    Eine Abnahme der Phasenergebnisse erfolgt nicht

    Ursachen:

    Folgen:

    Maßnahmen:


    Entwicklungsphase Gefundene Fehler
    Review der funktionalen Spezifikation
    Review des Grobentwurfes
    Review des Feinentwurfes
    Review des Codes
    Modultest
    Funktionstest
    Komponententest
    Systemtest
    2 ... 5 %
    10 ... 16 %
    17 ... 22 %
    20 ... 32 %
    12 ... 17 %
    10 ... 14 %
    8 ... 14 %
    0,5 ... 7 %



    Es wird nicht systematisch bzw. unzureichend getestet

    Ursachen:

    Folgen:

    Maßnahmen:

  3. Problem- und Systemanalyse

    Viele Entwicklungsprojekte scheitern letztendlich daran, daß der Problemanalyse im Vorfeld nicht genügend Beachtung geschenkt worden ist. Fehler, die in dieser Phase gemacht werden, lassen sich später, wenn überhaupt, nur mit sehr hohem Aufwand korrigieren. In dieser Phase wird grob beschrieben, was das zukünftige System leisten soll. Hierzu werden die Methoden zur Funktions- und Datenmodellierung eingesetzt, um Modelle in einer groben Detaillierung zu erstellen. Der Detaillierungsgrad muß eine Aussage über die Wirtschaftlichkeit des geplanten Vorhabens ermöglichen. In dieser Phase gibt es eine enge Zusammenarbeit zwischen Anwendern und Systemanalytikern.

    Die Anforderungen und Qualitätsmerkmale werden nicht festgelegt

    Ursachen:

    Folgen:

    Maßnahmen:

    Es fehlen eindeutige Begriffsdefinitionen

    Ursachen:

    Folgen:

    Maßnahmen:

  4. Systementwurf

    Der Schritt von der Analyse zur Codierung - die Entwurfsphase - beschäftigt sich hauptsächlich mit folgenden Teilproblemen:

    Weiter zu beachtende Aspekte sind die Wartungsfreundlichkeit, eine eventuelle Wiederverwendbarkeit sowie die Datensicherheit der zu entwickelnden Software. Nach Schätzungen beträgt der Anteil der Wartungskosten etwa 70% der gesamten Entwicklungskosten.

    Die Systemarchitektur ist gar nicht oder nur mit großem Aufwand erweiterbar

    Ursachen:

    Folgen:

    Maßnahmen:

    Das System ist nicht modular aufgebaut, die Daten sind nicht gekapselt

    Ursachen:

    Folgen:

    Maßnahmen:

  5. Codierung

    Die Codierung ist die Umsetzung des Systementwurfs in durch den Rechner interpretierbare ''Objekte'', z.B. Programme, Module, Makros usw., also in auf dem Computer lauffähigen Code. Man erwartet, daß alle wesentlichen technischen Entscheidungen bereits im Systementwurf festgelegt worden sind, so daß die Implementierung weitgehend mechanisch aus dem Systementwurf herleitbar ist. Die einzelnen Programmodule sollen am Schluß dieser Phase in codierter, dokumentierter und getesteter Form vorliegen. Die Fehler, die in dieser Phase entstehen, führen zu unübersichtlichen Programmen, die keiner warten möchte.

    Programmier-Standards bzw. -Richtlinien werden nicht beachtet

    Ursachen

    Folgen

    Maßnahmen

    Die Namensvergabe ist ungünstig

    Ursachen

    Folgen

    Maßnahmen

  6. Betrieb und Wartung

    Auch für die Zeit nach der Auslieferung von Software an Kunden müssen geeignete Maßnahmen getroffen werden, um die Anforderungen immer komplexerer Software-Produkte zu beherrschen.

    Dem Anwender müssen Zugang zum Produkt und dessen Möglichkeiten und Vorteile transparent gemacht werden. Dies erreicht man i.d.R. durch entsprechende Dokumentation und Schulungen.

    Die Entwickler müssen darauf vorbereitet sein, u.U. Software-Versionen mit unterschiedlichen Leistungsmerkmalen bereitzustellen, bzw. ältere Software-Versionen weiterzupflegen. Zudem muß zu jeder Software-Version die richtige Dokumentation zur Verfügung stehen. Hierzu bedarf es eines geeigneten Konfigurationsmanagement-Systems.

    Die Dokumentation fehlt ganz, ist veraltet oder nicht adäquat

    Ursachen:

    Folgen:

    Maßnahmen:

    Die Schulung der Anwender wird vernachlässigt

    Ursachen:

    Folgen:

    Maßnahmen:

    Das Konfigurationsmanagement ist unzureichend

    Ursachen:

    Folgen:

    Maßnahmen:

Zusammenfassung

Wie anfangs bereits erwähnt, müssen viele der beschriebenen Fehler und Probleme immer in Zusammenhang mit den jeweiligen Unternehmensstrukturen gesehen werden. Ein allgemeingültiges Lösungskonzept gibt es nicht. Vielmehr gilt es, in einer Gratwanderung zwischen Reglementierungen und Vorschriften einerseits sowie Freiräumen für die individuelle Kreativität andererseits in der Praxis den besten Mittelweg zu finden. Es bleibt jedoch ein schwieriges Unterfangen, alle Personen zufriedenzustellen, die an der Software-Entwicklung direkt und indirekt beteiligt sind: Entwickler, Anwender und Management.

Literatur

1
Beims, H.D.: Praktisches Software Engineering, Hanser Verlag, 1995

2
Davis, A.D.: 201 Principles of Software Development, McGraw-Hill, 1995

3
DeMarco, T.: Software-Projektmanagement, Wolfram's Fachverlag, 1989

4
Denert, E.: Software-Engineering, Springer-Verlag, 1992

5
Frick, A.: Der Software-Entwicklungsprozeß - Ganzheitliche Sicht, Hanser Verlag, 1995

6
Frühauf, K.; Ludewig J.; Sandmayr H.: Software-Projektmanagement und -Qualitätssicherung, vdf Verlag der Fachvereine Zürich, 1988

7
Krüger, M.: Prüfen von Software - aber richtig, Elektronik Nr. 24, 1993

8
Martin, J.; Odell, J. : Object Oriented Analysis and Design, Prentice Hall 1992

9
Myers, Glenford J.: Methodisches Testen von Programmen, 4.Auflage, Oldenbourg, 1991

10
Schäfer, S.: Objektorientierte Entwurfsmethoden, Addison-Wesley, 1994

11
Wallmüller, E.: Software-Qualitätssicherung in der Praxis, Hanser, 1990



Footnotes

... Engineering1
Specher der Arbeitsgruppe: Dierk Wendt, GDV-E, Hella KG, 59552 Lippstadt, 02941/387614, wendt@hella.de


zurück zur Startseite der Softwaretechnik-Trends , zu Band 15 Heft 4