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.11.1987

Sprachbarrieren zwischen DV- und Fachabteilungen müssen überwunden werden:Klassisches Projektmanagement wandelt sich

Nicht mehr das "Wie", sondern das "Was" ist bei der Realisierung von DV-Projekten relevant. Denn häufig kommt es schon beim Erstellen der Anforderungsprofile durch Verständigungsprobleme zwischen dem technisch-orientierten DV-Team und den künftigen Benutzern zu Verzögerungen. Reiner Petereit* zeigt in seinem Beitrag auf, wie die Umstellung von der klassischen Systemanalyse zur Problemkreisanalyse dabei helfen kann, ein DV-Projekt erfolgreich durchzuziehen.

Das Management industrieller DV-Projekte beinhaltet grob gesagt die Fertigstellung der Anwendung, die exakte Abdeckung der gestellten Anforderungen und die Einhaltung eines vorgegebenen Zeit- und Kostenplans. Während das erste Ziel weitgehend immer erreicht wird - jedes Software-Entwicklungsprojekt ist irgendwann fertig - ergeben sich bezüglich der beiden übrigen immer noch erhebliche Probleme, wie zum Beispiel Zeit- und Kostenüberschreitungen oder qualitative Fehlschläge.

Personelle Ausstattung läßt zu wünschen übrig

Normalerweise ist der eigentliche Auftraggeber, ein Fachbereich im Unternehmen oder ein Verwaltungsressort, personell nicht so ausgestattet, daß er den Anwendungsumfang (Anforderungsprofil, Fachkonzept) eigenständig festlegen kann. Selbst in Fällen, wo bereits die Fachbereiche an den Software-Entwicklungsprojekten beteiligt sein konnten, wird die Verantwortung - auch in fachlicher Hinsicht - an einen Projektleiter des zentralen DV-Bereiches mit meist DV-technischer Ausrichtung übertragen.

So wird zunächst einmal ein Konzept erarbeitet. Die Mitarbeiter des Fachbereiches liefern hierzu den Input, die DV-Organisatoren oder Organisationsprogrammierer setzen diese Anforderungen normalerweise in ein DV-Konzept mit technischer Ausrichtung um. Meist entstehen hier aufgrund der Sprachbarrieren die ersten Verständigungsprobleme und Mißverständnisse zwischen dem technisch-orientierten DV-Team und den künftigen Benutzern. Deutlich wird dies häufig erst nach "Fertigstellung" der Anwendung, wenn die Benutzer von Qualität und Umgang des Anwendungssystems enttäuscht sind. Das DV-Team beruft sich hingegen selbstbewußt darauf, daß der Auftrag wie besprochen formuliert und verabschiedet wurde. In vielen Fällen ergeben sich Differenzen bezüglich des Anwendungsumfangs bereits im Laufe der Realisierung. Folglich rückt das dritte Ziel, also die Einhaltung eines vorgegebenen Zeit- und Kostenplans, durch die späten Konzeptänderungen und -erweiterungen immer weiter weg.

Projektstrukturen werden kooperativer ausgelegt

Um hier für Abhilfe zu sorgen und zudem die Anwendungsentwicklung teilweise zu dezentralisieren (Linderung des Anwendungsstaus), werden verstärkt kooperative Projektstrukturen angestrebt, die eine gleichgewichtige Beteiligung von DV- und Fachbereichen an Projekten ermöglichen. Das bedeutet, daß die Konzeption und das Anwendungsdesign weitgehend auf Mitarbeiter des Fachbereichs übertragen werden, die Leitung des Projektes übernimmt ein neutraler, gegebenenfalls externer, Projektleiter. Er sollte helfen, die Sprachbarrieren zwischen dem DV-Team und dem Fachbereich zu überbrücken und zu überwinden. Mit diesem Schritt könnten die Anforderungsanalyse und das Fachkonzept überwiegend im Fachbereich durchgeführt werden. Nach gemeinsamer Definition der Benutzerschnittstelle seitens des DV- und Fachbereichs (Feinkonzept) übernimmt dann das DV-Team den Programm- beziehungsweise Modul-Entwurf und die softwaretechnische-Realisierung (Programmierung und Test).

Benutzerwünsche fallen nicht unter den Tisch

Ein geeignetes Instrument zur Analyse eines Anforderungsprofils ist eine sogenannte Problemkreisanalyse, die auch Führungskräfte erfolgreich in den Definitionsprozeß miteinbezieht. Sie hat den Vorzug, daß sie intensiver auf die fachliche Problematik - Abläufe, Prozesse, Informationen - der einzelnen Bereiche, Abteilungen oder Arbeitsplätze eingeht und diese wiedergibt. Das Umfeld wird stärker miteinbezogen. Die Anliegen der künftigen Benutzer bekommen ein stärkeres Gewicht. Vor allem wird zunächst einmal das "Was" geklärt. Die Problemkreisanalyse ist so ausgelegt, daß auch weniger strukturierte Aspekte mitfordern. Auch müßte er wissen, wie das Wesentliche vom Unwesentlichen zu trennen ist und dies vermitteln können. Wichtig ist natürlich auch die Persönlichkeitsstruktur mit sozialer Kompetenz.

Mit der Abnahme, respektive der Freigabe, ist das Projektgeschehen wieder weitgehend auf den Fachbereich verlagert. Die anschließende Integration und Einführung kann wieder gemeinsam durchgeführt werden.

Ein entscheidender Bestandteil eines modernen Planungskonzeptes ist die Organisation der Datenbasis. Erforderlich ist die Definition einer integrierten, konsistenten und weitgehend redundanzfreien, logischen Datenstruktur. Sie bildet für alle beteiligten Mitarbeiter des Projektes eine verständliche konzeptionelle Basis und ist der Schlüssel zu einer qualifizierten erfolgreichen Kooperation zwischen den DV- und den Fachbereichen.

Analyse erfolgt nach logischen Beziehungen

Soll zum Beispiel ein Vertriebsinformations-System konzipiert werden, so brauchen die Mitarbeiter zugängliche und verständliche Begriffe - sogenannte Objekte oder Entities wie Produkt, Auftrag, Artikel, Kunde, Mitbewerber. Diese werden nach logische n Beziehungen, zum Beispiel "Kunde - Auftrag" analysiert. Ziel ist die Ermittlung und realitätsgetreue Strukturierung der anwendungsrelevanten Daten. Wesentliche Elemente dieses Ansatzes sind natürliche, allgemein verständliche Begriffe und grafische Darstellungstechniken zur Visualisierung der Datenstrukturen.

Die methodische Basis für die Darstellung der Datenstruktur sind der "Entity Relationship Approach" nach Chen, sowie die aus dem Relationen-Modell stammenden Normalformen (Codd), deren Anwendung zu sogenannten kanonischen Datenstrukturen führt. Damit wird die Transparenz und Übersicht über den künftigen Informationsbedarf und das -angebot geschaffen. Dies trägt insbesondere der Tatsache Rechung, daß künftig mehr und mehr die Bereitstellung von Informationen gegenüber der "Verarbeitung" in den Vordergrund tritt. Redundanzen und Inkonsistenzen können vermieden werden.

Objektorientierter Ansatz bringt viele Vorteile

Die rechtzeitige Erkennung von System- und Anwendungsschnittstellen wird gewährleistet und die Wartungsfreundlichkeit der Software erhöht. Gleichzeitig werden moderne und effektive Methoden der Verfahrens- und Software-Entwicklung unterstützt. Erfahrungen haben gezeigt, daß das Vorteilspotential der Objektorientierung sogar erheblich größer ist als das der funktionsgebunden Methoden des Software Engineerings. Sie führen in zunehmendem Maße zu einer Verbürokratisierung der SW-Entwicklung.

Die Vorgehensweise ist abgesehen von dem dabei anfallenden Design- und Realisierungsaufwand bei der Auswahl und beim Kauf von Standard-Softwareprodukten (Anforderungsprofil) ebenfalls mit positivem Erfolg anwendbar.

Dr. Reiner Petereit ist Geschäftsführer der Dr. Reiner Petereit Unternehmensberatung GmbH in Mannheim.