Zum Hauptinhalt springen
Nachbericht

Nachbericht: 9. Workshop der Fachgruppe WI-VM

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

Über 50 Teilnehmer aus Wissenschaft und Wirtschaft diskutierten lebhaft über das diesjährige Thema Angepasste Vorgehensmodelle. Angesichts der Vielzahl unterschiedlicher Projektarten sind standardisierte Vorgehensmodelle in den wenigsten Fällen ohne Anpassungen anwendbar. Der Workshop konzentrierte sich darauf wie bereits bewährte Ansätze und Methoden auf spezifische Projektgegebenheiten angepasst werden und inwieweit Vorgehensmodelle, Vorgehensweisen, Methoden, aber auch pragmatische Lösungen durch Anpassungen ineinander greifen können. Auch leichtgewichtige Vorgehensmodelle, die das Schwerpunktthema der Tagung im Jahr 2001 bildeten, wurden wieder diskutiert.

Ist es möglich, mit Hilfe einer Softwarewerkbank ein generisches Prozessrahmenwerk zu konstruieren, aus dem ein auf die individuellen Bedürfnisse eines Projektes zugeschnittenes Vorgehensmodell abgleitet werden kann? Zu dieser Frage gab Jörg Noack, Informatikzentrum der Sparkassenorganisation, Bonn, eine Antwort. Er entwickelte eine Werkbank für den Zuschnitt von objektorientierten Softwareprozessen, mit deren Hilfe das sogenannte "Tailoring" auf das V-Modell und den Rational Unified Process (RUP) angewendet werden kann. Der Anwender des Systems sollte in der Regel ein Prozessberater sein, der über eine Windowsoberfläche vorgegebene Aktivitäten auswählt. Aus dieser Auswahl wird eine MS-Projekt-Datei erzeugt, die sich in alle Projektmanagementsysteme mit einer MS-Projekt-Schnittstelle einlesen läßt. Der Einsatz der Werkbank eignet sich besonders in der Phase Projektinitialisierung. Die Projektfortschreibung erfolgt ausschließlich im verwendeten Projektmanagementsystem. Eine Schnittstelle zurück in die Werkbank existiert derzeit noch nicht.

Clemens Herrmann vom Institut für Wirtschaftsinformatik an der Universität St. Gallen stellte ein Vorgehensmodell zur Data-Warehouse-Entwicklung am Beispiel eines Allfinanzkonzerns nach einer Fusion vor. Die Entwicklung eines vollständigen, konsistenten Vorgehensmodells für den Aufbau von Data-Warehouse-Systemen bildet einen Forschungsschwerpunkt des am Institut angesiedelten Kompetenzzentrums Data Warehouseing 2. Auf Basis einer Studie, die auf ein erfolgreich durchgeführtes Projekt nach der Fusion von drei Unternehmen zu einem Allfinanzkonzern aufsetzt, entstand ein Rahmenkonzept, das jede Projektphase bis auf die Aktivitätenebene verfeinert. Herr Herrmann betonte, dass trotz der mittlerweile großen Verbreitung von Data-Warehouse-Systemen derzeit noch kein anerkanntes generisches Soll-Vorgehensmodell für Data-Warehouse-Entwicklungsprojekte existiert. Das Kompetenzzentrum 2 will weitere Forschungsarbeiten innerhalb dieses Themenkomplexes durchführen und wird zukünftig mehrere Dokumentationen bereits abgeschlossener Entwicklungsprojekte analysieren.

Der Beziehung zwischen Vorgehensmodell und Projekt-Organisation widmete sich Gerhard Grams von der IBM Unternehmensberatung, München mit seinem Beitrag Anpassung von Vorgehensmodellen und Projektorganisationen zur Verbesserung der Zusammenarbeit von Fachabteilungen und Anwendungsentwicklung. Vor allem in komplexen Projekten mit langer Laufzeit, die neue, wenig erprobte Technologien einsetzen, ergibt sich während der Laufzeit die Notwendigkeit zu Modifikationen des definierten Vorgehensmodells. Meist ist die Beziehung zwischen Vorgehensmodell und Projekt-Organisation so eng, dass Veränderungen in dem einen Bereich auch Konsequenzen für den anderen Bereich nach sich ziehen. Herr Grams sieht die Prozesse im Rahmen der Anforderungsanalyse und des Anforderungsmanagements als kritische Faktoren, die maßgeblich über den Erfolg oder Misserfolg von großen Projekten entscheiden. Anhand eines praktischen Projektbeispiels unterstreicht er die Wichtigkeit eines geregelten Anforderungsprozesses. Sein Vorschlag ist die Schaffung eines sogenannten "Anforderungs-Managers". Die wesentliche Aufgabe dieser speziellen Projekt-Rolle besteht in der Etablierung entsprechender Prozesse für das projektweite Anforderungs-Management sowie in der Schaffung der infrastrukturellen Voraussetzungen. Er koordiniert und steuert Einreichung, Prüfung, Abnahme, Dokumentation sowie Umsetzung aller Anforderungen.

Warum gibt es so wenig gut ausgebildetes QM-Personal im Bereich Softwareentwicklung? Professor Roland Petrasch von der Fachhochschule für Technik und Wirtschaft, Berlin, befaßte sich mit dieser Frage in seinem Vortrag Berufsbilder im Bereich Software-Qualitätsmanagement: Grundlage für die personelle Ausgestaltung von Rollen in Vorgehensmodellen. Die Schwierigkeiten bei der Ausbildung von QM-Personal sind zahlreich. So machen sich beispielsweise der nicht abgeschlossene "Selbstfindungsprozess" der Informatik und die problematische Formulierung von quantifizierbaren Qualitätskriterien von Software insbesondere dann bemerkbar, wenn entsprechende Rollen in Vorgehensmodellen zu besetzen sind. Die Rolle des Qualitätsmanagers wird im V-Modell 97 sowie im Rational Unified Process (RUP) widersprüchlich und rudimentär definiert. Eine Stellenanzeige einer bekannten Unternehmensberatung macht die defizitäre Situation im Bereich QM-Personal deutlich: Gesucht wird ein Software-Qualitätsmanager, der nicht unbedingt Kenntnisse im Software-Qualitätsmanagement mitbringen muß!

Zur Verbesserung der Situation empfiehlt Professor Petrasch die Zertifizierung von QM-Berufen, wie sie in anderen Ländern existieren. So gibt es beispielsweise in den USA den Certified Software Quality Engineer der American Society for Quality.

Eine anforderungsgetriebene Auswahlmethode für Vorgehensmodelle am Beispiel E-Commerce-Projekte von Start-Up-Unternehmen stellte Simone Koenen-Schähling von der Universität Erlangen-Nürnberg vor. Dabei handelt es sich um eine vom Quality Function Deployment (QFD) abgeleitete Auswahlmethode für Vorgehensmodelle, die am Beispiel von E-Commerce-Projekten bei Start-Up-Unternehmen vorgestellt wurde. Der Ansatz ermöglicht die systematische Auswahl desjenigen Vorgehensmodells, welches auf die projektspezifischen Bedingungen am besten ausgerichtet ist. In drei Stufen werden verschiedene Matrizen durchlaufen; die Matrizen beziehen die Projektanforderungen und Rahmenbedingungen als Bewertungsfaktoren ein. Das Verfahren beruht maßgeblich auf den wesentlichen Variationen der Vorgehensmodelle, der Modellmerkmale sowie der Gewichtungs- und Korrelationswerte. Es eignet sich vor allem für große Softwarehäuser, IT-Dienstleister und große IT-Unternehmensabteilungen, da diese wiederholt Projekte einer Projektkategorie verwirklichen und auf einen großen Erfahrungsschatz zurückblicken, wodurch sie die notwendigen Entscheidungsparameter kontinuierlich validieren können.

Die spezifikationsbasierte Entwicklung ist das Ideal ingenieurmäßiger Softwareentwicklung. Um die Nachteile der spezifikationsbasierten Entwicklung zu vermeiden, entwickelte Professor Werner Mellis von der Universität Köln (Lehrstuhl für Wirtschaftsinformatik I Systementwicklung) ein evolutionäres Vorgehensmodell, das auf empirischen Untersuchungen und bekannten Managementtheorien basiert. Es ist ein Vorgehensmodell für die flexible Softwareentwicklung, für dessen Konzeption er vor allem Gestaltungsprinzipien erforschte, die empirisch aus der Organisationslehre belegbar sind. Da in evolutionären Vorgehensmodellen keine detaillierten Spezifikationen vorliegen, entstehen für die Entwickler erhebliche Gestaltungsspielräume in technischer und funktionaler Hinsicht. Deshalb ist es notwendig, die Nutzung der Gestaltungsspielräume durch die Entwickler im Sinne des Gesamtziels der Entwicklung zu steuern. Der erhöhte Koordinationsaufwand wird durch die drei Führungsrollen Projektleiter, Architekt und Produktmanager gelöst. Professor Mellis hebt hervor, dass in evolutionären Vorgehensmodellen ein besonders hohes Augenmerk auf Qualität, insbesondere der Architektur und Software gelegt werden muß.

Klaus Ploegert (IABG mbH) berichtete über Erfahrungen bei der Einführung von angepassten Vorgehensmodellen auf der Basis des V-Modells. Er zeigte auf, warum derartige Anpassungen sinnvoll und notwendig sind und in welchen Schritten sie am besten durchgeführt werden. Auf dem Weg zur firmenspezifischen Anpassung empfiehlt Herr Ploegert die Iterationsschritte Rohversion, Basisversion und Schlussversion durchzuführen. Nach der Schulung der Basisversion sollte auf keinen Fall auf die Durchführung eines Pilotprojektes verzichtet werden.

Während der Einsatz des V-Modells seit vielen Jahren in der Praxis erprobt ist, kann bei dem Einsatz von agilen Prozessen auf weit weniger Erfahrungswerte zurückgegriffen werden. Stefan Roock von der Universität Hamburg (Fachbereich Informatik, Arbeitsbereich Softwaretechnik) hat Erfahrungen mit agilen Methoden, die er mit "Expeditionen" vergleicht. Er stellte zum Abschluß der Veranstaltung seine Erfahrungen mit Extreme Programming (XP) bei der Firma Apcon Workplace Solutions GmbH vor. In seinem Vortrag XP Integrativ berichtete er von mehreren erfolgreich durchgeführten Software-Projekten, die konsequent den XP-Entwicklungsansatz verwendeten. Die ausgesprochen positiven Erfahrungen müssen vor dem Hintergrund gesehen werden, dass es sich ausschliesslich um Projekte mittlerer Größenordnung handelte, die auf das Objektorientierte Paradigma aufsetzten und ein durchschnittliches Entwickleralter von 30 Jahren auswiesen. Herr Roock unterstrich, dass der Einsatz XP nur dann zum Erfolg führen wird, wenn alle von Kent Beck vorgeschlagenen Kerntechniken (Practices) zum Einsatz kommen; XP ist eben mehr als nur "Pair Programming". Herr Roock schlägt ergänzend zu Kent Beck täglich ein 10-minütiges Stand-Up-Meeting und die regelmäßige Durchführung von Tuning-Workshops, in denen die dringlichsten Probleme besprochen werden, vor. Wer XP anwenden will, darf nicht unterschätzen, dass es bis zu einem Jahr dauern kann, bis sich neue Entwickler mit den Kerntechniken von XP vertraut gemacht haben.

Autor: Dr. Thorsten Maier