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.

19.06.1981 - 

Marksteiner: Statt Unbehagen ein eigenes Konzept entwickeln

Vorschläge für ein pragmatischeres Software-Engineering, Folge 3

Zu diesen Themen sind in der Literatur bis heute sehr allgemeine Ansätze zu finden; praktische Lösungen oder Regeln zur Lösung fehlen weitgehend.

Dadurch wird vielfach Entwicklungsaufwand am falschen Ort betrieben, indem Namensregelungen immer wieder neu festgelegt werden oder indem Verschlüsselungsfragen immer wieder neu gelöst werden. Für die formalen Festlegungen gilt übrigens auch hier, daß es nicht so sehr auf das Ergebnis der Festlegung ankommt, als darauf, daß etwas festgelegt und in seiner Festlegung eingehalten wird.

c) Regeln, die die DV-Lösung von Einzelproblemen betreffen.

Dazu gehören alle Regelungen die mit der Programmerstellung unmittelbar zusammenhängen wie:

- Regeln für Programmsteuerung und -ablauf

- Sammlung von algorithmischen Lösungen (Stichwort: Methodenbank)

- Regeln für den formalen und logischen Aufbau von Programmen (Stichwort: Strukturierte Programmierung)

- Einsatz von Programmgeneratoren etc.

In diesem Bereich der "Mikroprogrammierung" war Software-Engineering bisher am fruchtbarsten, sowohl, was den methodischen Ansatz, als auch was die Regeln für den praktischen Einsatz betrifft.

5. Normalisierung der Darstellung der Ergebnisse des Software-Erstellungsprozesses.

Hier kann man eher von einer Überproduktion der Software-Engineering-Fabrik sprechen, zumindest was die Vielzahl angebotener Methoden und Werkzeuge betrifft.

Ohne deren Nützlichkeit im einzelnen zu bestreiten, ist hier darauf hinzuweisen, daß dadurch die grundlegenden - unter Punkt 1 bis 4) dargestellten - Probleme der Software-Erstellung nicht gelöst werden.

Die Qualität von Software wird gemessen an dem Grad, mit dem sie die gesetzten Ziele erfüllt. Sie ist darin weitgehend unabhängig von der Wahl einer bestimmten Darstellungsform im Rahmen des Entwicklungsprozesses.

Diese kritische Wertung der bisher erzielten Ergebnisse des Software-Engineering zeigt, daß im Vorfeld und in den ersten Phasen des Projekts "Software-Engineering" noch eine Menge Arbeit zu leisten ist.

Der DV-Anwender kann aus diesen Ergebnissen bis heute sicher wenig praktische Anleitungen zur Software-Erstellung gewinnen, zumindest ist aber sein Problembewußtsein für die zur Lösung anstehenden, drängenden Probleme geschärft, für die bisher der Begriff "Software-Engineering" lediglich als Versprechen steht.

Angesichts der heutigen Probleme des DV-Bereichs (Stichworte: Wartungsaufwand, Dialogisierung, Distributed Processing, weiterer Verfall der Hardwarepreise, weiter steigende Softwarekosten, Standardsoftware, Personalfluktuation), die sich in den nächsten Jahren noch zuspitzen werden, wäre es nicht empfehlenswert, auf ein abgerundetes, vollständiges Software-Engineering-Konzept zu warten.

Im Gegenteil: Der Anwender hat heute durchaus die Möglichkeit, aus den vorliegenden Ansätzen sowie aus seinen eigenen Erfahrungen ein auf eigene Bedürfnisse abgestimmtes Softwue-Engineering-Konzept auszuarbeiten.

Top-Down mit Praxisnähe

Und zwar in Form eines eigenen Projekts "Software-Engineering". Voraussetzung für den Erfolg dieses Projekts ist in erster Linie eine pragmatische Einstellung und eine Top-Down-Vorgehensweise, mit etwa den folgenden Projektphasen:

- Definition des Planungshorizonts

- Definition der kurz- und mittelfristigen Planungsziele

- Bestandsaufnahme der verwendeten Richtlinien und Methoden

- Definition der Form einer Projektaufbauorganisation

- zeitliche Strukturierung der Projekte in Phasen, Festlegung der Phasenaktivitäten (Stichwort: Checklisten)

- Festlegung von Projektplanungs- und -steuerungsmechanismen

- Definition von Entwurfsmethoden den und -richtlinien

- Formulieren von Dokumentationsrichtlinien

- Entwurf eines Formularsystems für Projektentwicklung und -planung

- Festlegung der Ergebniskontroll- und -abnahmeprozeduren

- Festlegung der Implementierungsrichtlinien

- Entwurf/Konzeption eines Testsystems

- Konzept zur Einführung von DV-Systemen in die Fachabteilungen

- eventuell Aktivitäten zur Planung, Realisierung, Einführung von Tools für eine/mehrere der genannten Funktionen (erst zu diesem Zeitpunkt, nicht am Anfang des Projekts!)

Planung und Durchführung von Ausbildung und Schulung zum Thema Software-Engineering

Randbedingungen, die im Projekt "Software-Engineering" ebenso zu beachten sind wie in anderen Projekten:

- Beachtung einer betriebsspezifischen Aufwand-/Nutzenrelation

- Abstimmung der Mittelauswahl auf die betroffenen Personengruppen

Wird fortgesetzt