Berichte zum 8. GI-WIVM Workshop

Autor: Norbert Claudel

Zum insgesamt achten Mal fand das Jahrestreffen der Fachgruppe WI-VM (ehemals 5.11) (Vorgehensmodelle für die betriebliche Anwendungsentwicklung) statt. Das diesjährige Tagungsthema 'leichte Vorgehensmodelle' sollte dazu beitragen, sowohl aktuelle Marktentwicklungen und Tendenzen kritisch zu hinterfragen, als auch zu Kritiken gegenüber der angeblichen Komplexität von Standardmodellen Stellung zu nehmen.

Zu diesem Zweck gab es unterschiedliche Vorträge, die sich allesamt von der pragmatischen und praktischen Seite mit den verschiedenen Sichten auf ein Vorgehensmodell (VM) beschäftigten und dabei verschiedenste Schwerpunktaspekte wie z.B. eXtreme Programming, Open Source, Rational unified process, Ergonomie und Toolunterstützung mit einbezogen.

Dabei ist es augenscheinlich, dass die mitunter schwerfällig anmutenden Vorgehensweisen in der Praxis immer mehr von wirtschaftlicher Vernunft bestimmt werden. Während man durchaus in den letzten Jahren den Eindruck gewinnen konnte, dass die Informatik als Wissenschaftsdisziplin gerne in bestimmten Teilaspekten eine Inselbetrachtung pflegt, halten in der gelebten IT-Welt mittlerweile, quasi durch die Hintertür, Erkenntnisse anderer Wissenschaftszweige Einzug. Themen wie Ergonomie, Mitarbeitermotivation, gruppendynamische Prozesse, Kosten-/Leistungsrechnung basieren dabei auf Erkenntnissen aus Psychologie, Soziologie und Betriebswirtschaft. Betrachtet man nun dabei die bewußt oder unbewußt in verschiedenen praktizierten Vorgehensmodellen angewandten Techniken und Methoden aus o.g Disziplinen, tritt deutlich zutage, dass dabei fast immer ein Qualitätszuwachs erreicht wird, und das auch noch basierend auf empirisch abgesicherten Theorien.

So kann zum Beispiel der Ansatz des eXtreme Programming, betrachtet durch die Brille der betriebswirtschaftlichen Organisationstheorie derart bewertet werden, dass dort besonders die Aspekte der partizipativen Mitarbeiterführung, der Grad der Eigenbestimmung und daraus resultierend die Stärke der Motivation hervorstechen. Dagegen finden in diesen Ansätzen klassische Punkte wie Mitarbeiterauswahl, Fortbildung und Führung kaum Berücksichtigung. Sie sind aber durchaus kritische Erfolgsfaktoren, nur werden sie implizit als vorhanden vorausgesetzt und in den Modellbeschreibungen quasi nur am Rande erwähnt.

Das Gleiche gilt für die Open-Source Entwicklungen, die ja explizit gar kein Vorgehensmodell im engeren Sinne haben, sondern nur auf der Basis eines gemeinsamen Zieles und der Einhaltung allgemeiner Spielregeln zum Erfolg kommen. Hier bleibt zum Beispiel die Frage nach der Effizienz einer solchen Entwicklung weitgehend offen, erste Untersuchungen scheinen jedoch zu ergeben, dass der Gesamtaufwand dabei der einer klassischen Entwicklung ähnlich ist. Es wird also der eventuelle Mangel an zentraler Projektkoordination durch erhöhte Eigenmotivation und vermeintlich höhere Qualifikation der Beteiligten kompensiert.

Nicht zuletzt auch aus der OO-Entwicklung kommen schon seit längerem Ansätze zu einer iterativen Entwicklung mit relativ kleinen Inkrementen. So ein dynamisch flexibles Vorgehen steht nicht unbedingt im Widerspruch zu klassischen Vorgehensmodellen, zeigt aber in der konkreten Durchführung einige neue Aspekte. Ein Ansatz ist dabei die These, dass eine vollständige, aktuelle und korrekte Spezifikation quasi nie existiert, da sich die fachliche und technische Umgebung eines Projektes permanent im Wandel befindet. Damit befindet es sich aber von Anfang an in einem Wartungszyklus. Der Schluß daraus ist, möglichst schnell Entwicklungsergebnisse zu erzeugen, die dann auch marktnah implementiert werden. Dazu muß die Entwicklung auf einer Architektur basieren , die den Aspekt der schnellen und effizienten Änderbarkeit im Vordergrund trägt. Das Endprodukt wächst somit quasi mit der Spezifikation. Aber auch hierfür gibt es wiederum eine Reihe kritischer Erfolgsfaktoren. Erfahrene Entwickler die entsprechende Architekturen aufsetzen können, Patterns und Standards kennen, sowie die notwendigen Werkzeuge beherrschen, sind zwingend notwendig. Ebenso sind die Ansprüche an die Kommunikationsfähigkeit höher, das Team muß zudem eine besondere Homogenität aufweisen. Das obere Management muß Vertrauen in diese im Detail eher anarchisch anmutende Projektführung haben und daran glauben, dass trotz des Risikos eines fehlerhaften oder unvollständigen Inkrements das Endziel dennoch erreicht wird. Die Planungssicherheit ist hierbei sicher reduziert. Das Team sollte weiterhin die Möglichkeit haben, über das konkrete Vorgehen/Tailoring selbst zu bestimmen und damit Aktivitäten und Produkte festzulegen. Bei kurzen Entwicklungszyklen sind natürlich die Verwendung moderner Tools mit umfangreichen Test- & Debugginghilfen und integriertem Konfigurationsmanagement erforderlich. Automatisierte Testabläufe sind wegen des permanenten Zeitdrucks unabdingbar, ebenso wie die starke Einbindung des Nutzers in den gesamten Entwicklungsprozeß. Es kann eben nicht mal eine Woche auf die Spezifikation gewartet werden. Der Entwicklungszyklus ist eng geschlossen.

In der Endbetrachtung zeigen sich somit deutlich die Unterschiede sogenannter moderner leichter Vorgehensweisen zu den klassischen Vorgehensmodellen. Sie sind eigentlich gar keine echte Alternative, sie betonen lediglich Teilaspekte des Ganzen, schaffen also andere Schwerpunkte, die allerdings viele kritische Erfolgsfaktoren beinhalten. Nichtsdestotrotz sollte man aus den neuen Ansätzen lernen. Ein flexibles Umgehen mit einem mächtigen VM ist angebrachter denn je. Die Fokussierung auf Fragen der Ökonomität, Ergonomie und Motivation ist in der Arbeitswissenschaft nicht neu, bisher aber explizit zu selten im Zusammenhang mit der Anwendung von Vorgehensmodellen betrachtet worden. Ähnlich wie vor einigen Jahren noch Methoden oder SE-Tools, sind Vorgehensmodellen oftmals als alleiniger Heilsbringer angepriesen worden, ohne zu erwähnen, dass die Umsetzung von Menschen getrieben wird - und die funktionieren eben nicht wie Maschinen - auch der angeblich rationale Softwareentwickler nicht.

Gemäß den Rückmeldungen der Teilnehmer waren die Vorträge mit dem besten Inhalt von Hrn. Reinhold, Fr. Wiemers und Hrn. Blum / Hrn. Gambert. Die besten Präsentationen boten Fr. Wiemers, Hr. Reinhold und Hr. Coldewey. Die Bewertungen für den Workshop bezüglich Programm, Organisation, Räumlichkeiten und dem Gesamteindruck ergaben eine Durchschnittsnote von 1,6.

Die nächste Sitzung der Fachgruppe wird im kommenden Jahr im März wieder in Glashütten stattfinden. Ein neuer Arbeitskreis zu Software-Qualitätsmanagement ist geplant. Als erstes soll dieser AK gemeinsam mit einem AK der FG 2.1.7 (Test, Analyse und Verifikation von Software) das Thema Qualifikation von QM-Personal angehen.

Norbert Claudel
Gorbit mbH
E-Mail: norbert.claudel(a)t-online.de

Autor: Michael Tonndorf

Am 7. und 8. März 2001 fand in der angenehmen Atmosphäre des Collegiums Glashütten im Taunus der 8. Workshop der Fachgruppe WI-VM (ehemals 5.11) der Gesellschaft für Informatik (GI) statt. Die Gesellschaft für Informatik e.V. (GI) umfasst über einhundert Fachgruppen und Arbeitskreise, in der Informatiker eine Vielzahl von wissenschaftlichen und aktuellen Fragestellungen bearbeiten. Interessenten am Thema Vorgehensmodelle haben sich in der Fachgruppe WI-VM der GI Vorgehensmodelle für die betriebliche Anwendungsentwicklung zusammengeschlossen.

Die rund 60 Teilnehmer von Hochschulen, Industrie und Wirtschaftsunternehmen, besonders Finanzdienstleistern und Beratungsunternehmen, diskutierten zwei Tage lang engagiert über das Thema des Jahres 2001 Leichte Vorgehensmodelle. Was ist darunter zu verstehen? Unstrittig ist, dass der angemessene Einsatz eines Vorgehensmodells bei der Entwicklung von professionellen IT-Systemen allgemein als notwendig angesehen wird. Gleichzeitig bedeutet die Entwicklung und unternehmensweite Einführung eines Vorgehensmodells einen Aufwand, fachlich und organisatorisch, damit personell und kostenmäßig. Die Furcht vor einem unkalkulierbaren Aufwand bei der Einführung und Verwendung eines Vorgehensmodells überlagert dabei oft genug den erwarteten Nutzen:

• Begriffliche Grundlagen für den SW-Entwicklungsprozess,
• Definierte und damit wiederholbare Prozesse,
• Gesamtrahmen für den Einsatz von Methoden und Werkzeugen im SW-Entwicklungsprozess,
• Standard für die SW-Dokumentation,
• Übertragung von etablierten "best practices" auf neue Projektsituationen,
• Bereitstellung von Einstiegspunkten für Projektmanagement und Qualitätsmanagement in das Projekt,
• Vertragsbasis für Ausschreibungen, Kooperationen, usw.

Das Thema Wirtschaftlichkeit von Vorgehensmodellen war bereits einer der Schwerpunkte der Tagung im Jahr 2000. Neben dem Versuch, die Kosten eines Vorgehensmodell-Einsatzes zu quantifizieren, werden aber auch ganz neue Wege gegangen. Diese Ansätze können unter dem Stichwort "minimale" oder "leichte" Vorgehensmodelle zusammengefasst werden. Vorbild dazu sind die in der englischsprachigen Literatur schon seit längerer Zeit grassierenden lightweight processes. Leitgedanke ist es dabei, nur die Teile eines Vorgehensmodells anzuwenden, die in einem IT-Projekt unbedingt erforderlich sind. Es stellt sicht natürlich sofort die Frage, wie und durch wen festgestellt werden kann, was in einem Projekt "unbedingt erforderlich" ist. Mit dieser Frage beschäftigte sich auch der eingeladene Vortrag von Jens Coldewey, München: Agile Prozesse (Anm. des Verfassers: das im Englischen wie Deutschen in der gleichen Bedeutung verstandene Adjektiv agil soll zukünftig das missverständliche Adjektiv leicht bzw. leichtgewichtig ersetzen.) Coldewey plädierte dafür, Selbstverständlichkeiten in Frage zu stellen, z.B. die These, dass zu einem guten IT-System auch ein gut dokumentierter Code gehört. Würde ein IT-Anbieter z.B. auf dem Gebiet des E-Business oder des E-Commerce diese Forderung strikt durchhalten, dann wäre er schlicht nicht überlebensfähig - sobald er seinen Code ordentlich dokumentiert hätte, käme die Konkurrenz gerade mit der übernächsten Version ihres Produkts auf den Markt. Wohltuend ist, dass Coldewey nicht eine allein erfolgbringende Methode zur Lösung dieses Konflikts vorschlägt, sondern ein Bündel von Ansätzen vorstellt und diskutiert. Allerdings muss auch klar sein, dass nicht jede Art von SW-Erstellung in einer derart extremen Wettbewerbs- und Terminsituation stattfindet - man denke nur an Software in sicherheitskritischen Systemen, deren Fehlfunktion weitreichende Konsequenzen haben kann. Dort ist der Einsatz eines Vorgehensmodells auch nur eine Maßnahme unter mehreren, um die Erfüllung von Qualitäts- und Zuverlässigkeitsanforderungen sicherzustellen.

Im Zusammenhang mit agilen Prozessen wird auch häufig die Frage erörtert, ob ein Ansatz wie Extreme Programming (XP) als Vorgehensmodell bezeichnet werden kann. Peter Wendorff von der ASSET GmbH in Oberhausen beleuchtete das Thema XP unter Managementaspekten, und stellte verblüffende, elementare Defizite fest. So lange in XP Themen wie "Staffing", "Leading" und auch "Controlling" gar nicht oder nur rudimentär angesprochen werden, kann XP wohl zu recht nicht Vorgehensmodell genannt werden, mögen einzelne Aspekte aus XP auch noch so faszinierend sein.

Eine Reihe weiterer Vorträge enthielten Erfahrungsberichte mit dem V-Modell `97 des Bundes. Für das V-Modell, dessen Philosophie ja gerade die projektspezifische Anpassung ist, ist ein "extremes Tailoring", d.h. ein extremes Verschlanken des vollen Regelungsumfanges, eine besonders häufig diskutierte Vorgehensweise, um das "unbedingt erforderliche Mindestmaß" für die Projektarbeit zu finden. Beispiele hierzu lieferten die Beiträge Mindestanforderungen im V-Modell '97 aus der Sicht von UNiQUARE, Martin Reichmann, UniQUARE Financial Solutions GmbH; Ein minimales Vorgehensmodell zur benutzerzentrierten Entwicklung ergonomischer Web-Anwendungen mit dem Schwerpunkt ´Navigation´, Roland Petrasch, Private Hochschule NORDAKADEMIE und V-Modell im eBusiness-Bereich, Thomas Blum, GIP AG, Mainz. Alle drei Autoren machten gute Erfahrungen bei der Anwendung des V-Modells und betonten die Notwendigkeit eines Prozessleitfadens im Projekt.

In zwei Beiträgen stand das Phänomen der "Open Software" im Vordergrund: warum teure Software-Projekte, wenn es auch freiwillig und kostenlos geht? Stefan Koch, Wirtschaftsuniversität Wien, räumte in seinem Beitrag Entwicklung von Open Source und kommerzieller Software: Unterschiede und Gemeinsamkeiten mit einigen dieser Mythen auf und gab gute Begriffsdefinitionen. Auch stellte er klar, dass Open Source Software-Entwicklung nicht als Vorbild für ein minimales Vorgehensmodell taugt. Carla Freericks von der Universität Bremen stellte den Stand des V-Modell-/Internet Projekts "GDPA" der Universität Bremen dar (V-Model Open Source). Wer das V-Modell `97 lernen und anwenden will, findet auf den Webseiten der Universität Bremen einen reichhaltigen Baukasten dafür.

Nur indirekt mit dem Thema der Veranstaltung in Verbindung standen die zwei Vorträge von Markus Reinhold (COCOO Putzbrunn) Rational Unified Process 2000 versus V-Modell 97 und Bernd Nawrot (MicroTOOL GmbH, Berlin) Chancen einer maschinell gestützten Prozesssteuerung von IT-Projekten, gleichwohl waren die Beiträge für Vorgehensmodell-Anwender von großem Interesse.

Dr. Kneuper, neben Manuela Wiemers Organisator der Veranstaltung, versuchte in seinem Beitrag Ein Vorgehensmodell zur Durchführung von Vorgehensmodell-Workshops einem potentiellen Organisator des Workshops 2002 die Arbeit schmackhaft zu machen. Das Konferenzpapier enthält eine umfassende Checkliste, die für jeden Organisator einer Fachtagung von Nutzen sein kann. Gleichzeitig ist es ein Beleg für die Universalität von generischen Vorgehensmodellen, hat man erst einmal die richtigen Tailoring-Regeln.

Manuela Wiemers, Gorbit mbH Bergisch-Gladbach, fasste den Stand der Diskussion zum Thema "Leichte Vorgehensmodelle" zusammen und zeigte deutlich die Defizite der verschiedenen neuen Ansätze auf (Kombination verschiedener Vorgehensweisen - Prozessarten). Es gibt keine strukturierte Vorgehensweise zum Nulltarif und kein projektspezifisches Vorgehensmodell "auf Knopfdruck". Es wird immer eine intellektuelle Anstrengung benötigt, um für ein IT-Projekt in einer sich rasch wandelnden Zeit die passende Vorgehensweise zu finden, die den Bedürfnissen der Entwickler wie der Organisation Rechnung trägt. Die Instrumente hierfür sind jedenfalls vorhanden.

Michael Tonndorf

Öffentlicher Sektor Süd
Sandstr. 7
80335 München
Tel.: +49 (89) 5908 6576
Mob.: +49 (173) 6556 815
Fax: +49 (89) 5908 6580
E-Mail: Michael.Tonndorf(a)cscploenzke.de