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.

11.04.1986 - 

Organisatorische Spielregeln müssen auch für die Projekteinführung gelten:

Exakte Analyse entscheidet über Erfolgschancen

Ein methodisches Vorgehen ist bei der Einführung von Softwareengineering unerläßlich. Der Anwender sollte sich deshalb zuerst eine Reihe von Fragen stellen und diese so ehrlich wie möglich beantworten. Erst wenn das Ergebnis zufriedenstellend ausfällt, lohnt es sich, ein Projekt zur Einführung von Software-Engineering voranzutreiben.

Frage 1: Was ist unter dem Begriff Software-Engineering inhaltlich zu verstehen?

Es ist von besonderer Bedeutung, sich zu Beginn der Einführung von Software-Engineering darüber klar zu werden, was dieser Begriff eigentlich bedeutet und was damit be zweckt werden soll. Bei allen Diskussionen über technische und methodische Konzepte sowie Details geht letztendlich kein Weg daran vorbei, daß Software-Engineering das Verhalten von Menschen beeinflussen, ja in eine bestimmte Norm zwingen soll. Wird also die Einführung von Software-Engineering als eine gewollte Verhaltensänderung von Menschen verstanden, so erscheinen Fragen wie die der Akzeptanz nicht mehr so völlig unverständlich. Vielleicht ist es auch möglich, bereits zu Beginn einer derartigen Vorgehensweise prophylaktische Maßnahmen zu ergreifen, um derlei Probleme erst gar nicht aufkommen zu lassen. Software-Engineering ist kein rein technologisches Problem, sondern eine Richtlinie zur Verhaltensbeeinflussung von Menschen.

Frage 2: Welches sind die Erwartungshaltungen an die Einführung von Software-Engineering innerhalb des Unternehmens?

Hier muß zwischen den beteiligten Gruppen unterschieden werden. Zu diesen zählen die Anwendungsentwickler, aber auch Bereiche der Fachabteilungen. Diese sollen später mit Hilfe von Methoden des SE mit den Anwendungsentwicklern kommunizieren. Beteiligt ist aber auch im besonderen Maße das DV-Org-Management, das hier primär die Aufgabe hat, seine Vorstellungen präzise zu formulieren und zu begründen. Wie schwierig es fällt, solche Ziele klar darzustellen und letztlich auch noch mit Meßgrößen zu versehen, weiß jeder, der einmal versucht hat, ein spezielles Projekt zur Softwareentwicklung durchzuführen. Andererseits läßt sich aber ohne eine klare Zielsetzung der Erfolg oder Mißerfolg der Einführung von SE nicht feststellen. Oder anders ausgedrückt: Die spätere Frustration, die späteren Mißverständnisse und Unstimmigkeiten sind bereits vorprogrammiert. Ohne eine klare Zielvereinbarung ist ein Erfolg also nicht feststellbar.

Frage 3: Sind die notwendigen organisatorischen Voraussetzungen gegeben?

Die Grundeinstellung, die der Anwender hierbei an den Tag legen sollte, heißt: Die Einführung von SE ist nichts Besonderes. Die Konsequenz bedeutet, daß dieses Projekt auch eine entsprechende Organisation braucht. Es muß also Projektleiter und -mitarbeiter geben. Die Projektressourcen Zeit und Geld sind unerläßlich und ohne Projektplanung und -koordinierung geht gar nichts. Alle diese organisatorischen Spielregeln sind in fast jedem Unternehmen bekannt und sollten für das Thema SE genutzt werden. Zu einem Projekt gehört aber auch ein Auftraggeber, der in diesem Falle mindestens das DV-Org-Management sein muß, wenn nicht gar eine hierarchisch noch höher angesiedelte Ebene. Denn von diesem Projekt sind auch andere Fachbereiche und laufende Projekte indirekt betroffen.

Frage 4: Welche methodischen Voraussetzungen sind gegeben?

Es ist immer wieder erstaunlich festzustellen, mit welcher Konsequenz versucht wird, "unmethodische Methoden" einzuführen. Daß das inhaltlich nicht unbedingt zum Erfolg führen muß, ist die Kehrseite der Medaille. Ist die Entscheidung gefallen, die Einführung von Softwareengineering als ein Projekt zu verstehen, so scheint es nur konsequent, dies auch methodisch gemäß einem Vorgehensmodell durchzuführen.

Frage 5: Welche technischen Voraussetzungen sind gegeben?

Im einfachsten Fall kann eine technische Unterstützung durch Textsysteme gewährleistet sein. Sollten aber bereits umfangreichere Werkzeuge verfügbar sein - beispielsweise ein Data-Dictionary für den Bereich der Datenadministration - so steht auch der Dokumentation der Metadaten für das Software-Engineering innerhalb des Data-Dictionary nichts Grundsätzliches im Wege.

Frage 6: Ist das notwendige Know-how vorhanden?

Es ist kaum vorstellbar, daß beispielsweise eine Großbank sich ein komplettes Buchungssystem von einem Projektteam entwickeln läßt das ausschließlich aus Mitarbeitern ohne praktische Bankerfahrung besteht.

Die gleiche Anforderung müssen wir an das Thema Software-Engineering stellen. Die Know-how-Zuführung durch Ausbildungsmaßnahmen, Erfahrungsaustausch oder Know-how-Einkauf ist eine notwendige Voraussetzung zur erfolgreichen Einführung von SE. Vergegenwärtigt man sich, daß nach Abschluß des Einführungsprozesses in Großunternehmen bis zu hundert Anwendungsentwickler mit einem solchen Verfahren arbeiten und ihrerseits ein riesiges Quantum an Programmen erstellen, wird klar, daß die Konsequenzen von Fehlentscheidungen kaum abschätzbar sind.

Frage 7: Sind die psychologischen Voraussetzungen gegeben?

Das Thema Software-Engineering hat bei vielen Anwendern bereits ein durch Erfahrungen innerhalb oder außerhalb des Unternehmens geprägtes Image. Dieses möglichst unvoreingenommen und, nüchtern zu analysieren, ist eine wichtige Voraussetzung für den Projekterfolg. Dabei bedarf es schon einer gehörigen Portion Selbstvertrauen, auch Sätze wie: "Laß die nur mal mit ihrem neuen Phasenkonzept kommen, das kriegen wir schon klein" unvoreingenommen und möglichst emotionslos zu registrieren.

Bei der Analyse dieser Situation muß konsequent vorgegangen werden. Die Grundsatzüberlegung lautet, ob ein eventuell negatives Image des Themas Software-Engineering durch bestimmte Personen geprägt wird. Ist diese Frage zu bejahen, so muß untersucht werden, ob diese Personen innerhalb oder außerhalb der Projektgruppe agieren. Oft sind die für das schlechte Image verantwortlichen Ereignisse auch in historischen Entwicklungen begründet, beispielsweise in bereits gescheiterten Einführungsversuchen zum Thema Software-Engineering. Auf der Basis dieser nüchternen Analyse kann und muß man von Beginn des Projektes an eine aktive Einführungsstrategie zur positiven Beeinflussung dieser psychologischen Rahmenbedingungen betreiben.

Bei der Ist-Aufnahme sind bestehende Verfahren und Techniken des Software-Engineerings zu erheben und zu bewerten, so daß die Anforderungen an die neue Software-Engineering-Umgebung klar spezifiziert sind.

Bevor das erste Tool angeschafft wird, muß das organisatorische Konzept vorliegen. Es sollte festgelegt sein, welche Funktionen bei der Entwicklung von Software durchzuführen sind und welche Daten dazu verwaltet werden müssen. Ebenso sind die Methoden für das Software-Engineering auszuwählen und den Unternehmensbelangen anzupassen. Erst danach ist die Basis geschaffen, um eine Tool-Konzeption (Werkzeuglandschaft) zu entwickeln.

Die Realisierung beinhaltet normalerweise eine Implementierung von Standardwerkzeugen. Ergänzend wirken Schnittstellen zwischen diesen Werkzeugen, die teilweise noch von den Anwendern selbst geschrieben werden müssen. Eigenentwicklungen runden diese Entwicklungslandschaft ab.

Die Einführungsstrategie beginnt nicht erst, wenn das Werkzeug und die Methoden im Haus sind, sondern mit dem ersten Tag des Projekts. Sehr wichtig ist es dabei, Software-Engineering nicht zum Thema einer elitären Gruppe innerhalb des Unternehmens zu machen, sondern es zur akzeptierten Hilfestellung der Betroffenen zu überführen. Die Einrichtung einer internen Benutzergruppe, die die Weiterentwicklung des gesamten Vorgehensmodells intensiv mitbeeinflußt und auch die entsprechende Kompetenz hat, erscheint als gute organisatorische Hilfestellung. Damit wird die Einführungsstrategie zum ersten, aber entscheidenden Schritt einer Weiterentwicklungsstrategie.

*Hartmut Skubch ist Geschäftsführer der Innova Consulting GmbH, Wiesbaden.