In diesem Artikel diskutieren wir, inwiefern die Forschung auf dem Gebiet der Software-Prozeßmodellierung und rechnergestützten Durchführung von Software-Prozessen Einfluß auf die industrielle Praxis der Software-Entwicklung hatte und hat. Wir unterscheiden dabei verschiedene Phasen: von anfänglicher Euphorie über vollständige Desillusionierung bis hin zur Anwendung von Prozeßtechnologie auf Geschäftsprozesse und schließlich bis zur beispielhaften Anwendung von Prozeßmodellierung und rechnergestützter Durchführung auf bestimmte Teile von Software-Prozessen. Wir diskutieren ein Beispiel der Anwendung von Software-Prozeß-Technologie auf einen Fehlerverfolgungsprozeß in der industriellen Praxis. Abschließend erörtern wir, wie die Forschung in Modellierung und rechnergestützter Durchführung von Software-Prozessen fokussiert werden könnte, um schneller zu in der Praxis nutzbaren Ergebnissen zu führen.

Schlüsselwörter:

Software-Prozeßmodellierung, rechnergestützte Durchführung von Software-Prozessen, Workflow-Management, FUNSOFT-Netze

In der akademischen Software-Technologie-Forschung hat sich seit gut zehn Jahren das Gebiet der Software-Prozeßmodellierung und der rechnergestützten Durchführung von Software-Prozessen als Forschungszweig etabliert. Es gibt regelmäßige European Workshops on Software Process Technology [23], International Software Process Workshops [11] und eine Reihe von International Conferences on the Software Process [21]. Die meisten Software-Engineering-Konferenzen umfassen eine oder mehrere Sitzungen, die sich mit Software-Prozeß-Themen beschäftigen [3,1].

Der Fokus dieser hauptsächlich akademisch ausgerichteten Forschungsarbeit hat sich im Laufe der Jahre gewandelt. Die späten 80er Jahre waren von der Frage geprägt, ob Software-Prozeßmodelle wie Programme behandelt werden sollten [22] oder ob Software-Prozesse zu sehr von menschlicher Interaktion und Kreativität geprägt sind als daß das möglich wäre [20]. Ohne, daß bezüglich dieser Frage ein Konsens erzielt worden wäre, waren die frühen 90er durch heftige Diskussionen bezüglich der Frage bestimmt, welchem Sprachparadigma eine Software-Prozeßmodellierungssprache folgen sollte. Die prominentesten Vertreter solcher Sprachen umfassen regelbasierte Sprachen, Petri-Netz-basierte Sprachen und objektorientierte Sprachen [1,2,4,17].

Gleichermaßen zeigen die letzten Jahre einen neuen Trend: es wird akzeptiert, daß verschiedene Prozeßmodellierungssprachen ihre Berechtigung haben und es gibt einen wachsenden Konsens, daß graphische Sprachen helfen, um Prozeßmodellierung auch für Nichtexperten zu ermöglichen. Gleichzeitig ist ein Forschungsschwerpunkt im Bereich der Software-Prozeßevolution entstanden. Unter Prozeßevolution wird verstanden, daß Software-Prozeßmodelle geändert werden während sie als Grundlage der rechnergestützten Durchführung von Software-Prozessen verwendet werden. Die Notwendigkeit ist schon vor Jahren erkannt worden [5,2]. Mittlerweile wird allgemein akzeptiert, daß Software-Prozesse komplexe Entitäten sind, die inhärent auf permanenter Änderung und Fortentwicklung basieren. Das bedeutet, daß die Evolution von Prozeßmodellen nicht auf Modellierungs- oder Planungsfehler zurückzuführen ist, sondern auf die Tatsache, daß Software-Prozesse in stetiger Wechselwirkung mit ihrer Umgebung stehen und daß diese zu Prozeßmodelländerungen führt.

Parallel zu diesen Änderungen in der Hauptausrichtung der Software-Prozeß-Forschung, haben viele Forschungsgruppen weltweit Prototypen von Werkzeugen zur Software-Prozeßmodellierung, zur Analyse von Software-Prozeßmodellen und zur rechnergestützten Durchführung von Software-Prozessen entwickelt. Zu ihnen zählen unter anderem:

• ALF [7], das im Rahmen eines ESPRIT-Projektes entwickelt wurde und eine teilweise deskriptive und teilweise präskriptive Beschreibung unterstützt.
• Arcadia [18], das unter Mitwirkung verschiedener amerikanischer Universitäten entwickelt wurde und als eine lose Kopplung verschiedener Werkzeuge zur Prozeßmodellierung und -ausführung verstanden werden kann.
• MELMAC [6], das auf der Basis von FUNSOFT-Netzen zur Prozeßmodellierung und Modellanalyse eingesetzt wird.
• Merlin/Escape [17], das als Prozeßmodellierungsumgebung auf der Grundlage einer regelbasierten Sprache begonnen wurde und mittlerweile über eine graphische Benutzungsoberfläche zur Eingabe von Objektmodellen, Zustandsübergangsdiagrammen und Berechtigungen verfügt.
• SPADE [2] ist eine Umgebung, die Software-Prozeßmodellierung und -simulation und die rechnergestützte Durchführung von Software-Prozessen unterstützt. SPADE basiert auf der Petrinetz-Sprache SLANG. Ähnlich wie FUNSOFT-Netze umfaßt SLANG eine Reihe von Konstrukten, die die Modellierung von Prozessen vereinfachen. Ein besonderes Merkmal von SPADE ist, daß die Integration von Fremdwerkzeugen relativ leicht möglich ist.

Neben diesen Prototypen gibt es eine Reihe von Ansätzen, die noch nicht durch Werkzeuge unterstützt werden, die aber der Dynamik von Software-Prozessen durch geeignete Modellierungsmittel Rechnung tragen (Dynamite [15], SOCCA [4]).

Trotz dieser Vielfalt von Prototypen und Konzepten ist es bisher nur zu experimentellen Anwendungen von Software-Prozeßmodellierung und rechnergestützter Durchführungsunterstützung auf industrielle Software-Prozesse gekommen. Erfahrungen bei der Durchführung solcher Experimente werden beispielsweise in [9], [4] und [14] beschrieben.

In diesem Abschnitt beschreiben wir einige Erfahrungen bei dem Versuch, Ergebnisse der Software-Prozeß-Forschung in die industrielle Software-Entwicklung zu transferieren. Diese Erfahrungen beruhen auf dem Transfer von MELMAC und MELMAC-Konzepten.

Das Prozeß-Management-Werkzeug MELMAC ist Ende der 80er Jahre im akademischen Kontext entstanden. Die Entwickler waren zutiefst davon überzeugt, daß die industrielle Software-Entwicklung händeringend auf Software-Prozeß-Management im allgemeinen und MELMAC im besonderen warten würde.

2. Phase 2: Frustration

Leider stellte sich bei Versuchen der Anwendung von MELMAC auf industrielle Software-Prozesse heraus, daß MELMAC zwar tragfähige Konzepte verwirklichte, aber weder stabil noch ausreichend dokumentiert war. Zudem war die Handhabung von MELMAC gewöhnungsbedürftig und entsprach nicht den gängigen Anforderungen an Benutzungsoberflächen. Unabhängig von diesen konkreten Hindernissen bei der Anwendung eines konkreten Werkzeuges, ließen die genannten Bemühungen allgemeine Zweifel an der Relevanz des Software-Prozeß-Managements aufkommen. Während die Software-Prozeß-Forschergemeinde in der Terminologie von Prozessen, Objektmodellen, Prozeßmodellierungssprachen, und präskriptiven und deskriptiven Modellierungssprachen miteinander diskutierte, sprachen industrielle Softwareentwickler über Programmiersprachen, Budgetüberschreitungen, Fehlerbeseitigungen und Transaktionsmonitore. Die Schnittmengen zwischen beiden Terminologien war nahezu leer, so daß es relativ schwierig und langwierig war, eine einheitliche Kommunikationsgrundlage zu schaffen. Auf der Basis dieser Grundlage stellte sich dann heraus, daß die allgemeinen Prozeßverbesserungsansprüche des Prozeß-Managements weit von der täglichen Praxis der Software-Entwicklung entfernt waren. Diese bedurfte konkreter Verbesserungen des Konfigurations-Managements, des systematischen Tests, der Abstimmung zwischen Vertriebsleuten und Entwicklern oder auch der Änderungskontrolle für einen Softwareentwurf. Diese konkreten Probleme erforderten zunächst nicht primär rechnergergestützte Durchführung, sondern erst einmal eine klare Organisation des Software-Prozesses. Insofern war es nützlich, Software-Prozesse zu modellieren. Die Anforderungen an die reine Modellierung wurden jedoch von den zur Verfügung stehenden Werkzeugen und Modellierungssprachen nur ungenügend erfüllt. Statt der klaren Darstellung der verschiedenen Aspekte von Software-Prozessen (organisatorischer Kontext, Struktur von Dokumenten, Abläufe, Berechtigungen beteiligter Personen) war die Software-Prozeßmodellierung sehr stark auf die Ausführbarkeit der Prozeßmodelle ausgerichtet. Auf diese Weise konnten zwar alle Facetten von edit-compile-test-Zyklen [6] beschrieben werden, aber der organisatorische Gesamtzusammenhang der Software-Entwicklung blieb zumeist unbeachtet. Abgesehen davon stellte sich die Vielfalt der Ausnahmen in den industriellen Prozessen als ein Hindernis für die Anwendung der Prozeßmodellierung heraus. Gemäß des Capability Maturity Models [19] waren die meisten der untersuchten Prozesse zwischen Stufe 1 (initial) und Stufe 2 (wiederholbar). Das bedeutet, sie waren in weiten Teilen unklar und die Zusammenhänge zwischen den Aktivitäten waren nicht allen beteiligten Personen klar. Anders ausgedrückt: die prozeßorientierte Sicht auf die Software-Entwicklung war wenig ausgeprägt. In dieser Weise wirkten die ganz konkreten Probleme und der niedrige Reifegrad der Software-Entwicklung nahezu prohibitiv auf die Anwendung des Prozeß-Managements, das keinen kurzfristigen return-on-investment versprach.

Nachdem erst einmal unverkennbar war, daß Software-Prozeß-Management kaum auf reale Software-Prozesse anwendbar war, ergab sich die Gelegenheit, die Geschäftsprozesse, die durch ein neu zu entwickelndes Softwaresystem unterstützt werden sollten, zu untersuchen. Bei dem neuen Softwaresystem handelt es sich um das wohnungswirtschaftliche Informationssystem WIS, das von LION (zwischenzeitlich: Vebacom Service, heute: o.tel.o) im Auftrag eines Konsortiums von acht Kunden entwickelt worden ist. Beispiele für die Geschäftsprozesse, die durch WIS unterstützt werden, sind:

• Von der Ausschreibung über die Beauftragung zur Rechnungskontierung und -begleichung.
• Vom Eingang einer Kündigung, die Wohnungsabnahme, die Mieteanpassung zur Neuvermietung.
• Von der Sollstellung bis zur letzten Mahnstufe.

WIS wurde vollständig prozeßorientiert entwickelt. Das bedeutet, daß die zu unterstützenden Geschäftsprozesse zunächst modelliert wurden (Abläufe mit FUNSOFT-Netzen, zugrundeliegende Daten mit Hilfe von erweiterten Entity-Relationship-Modellen [13] und der organisatorische Kontext mit Hilfe von Organigrammen und Berechtigungen), dann analysiert wurden und letztlich auf der Basis eines Workflow-Management-Systems durchgeführt wurden.

Die Gründe für die prozeßorientierte Entwicklung waren:

• Die zu unterstützenden Geschäftsprozesse sind gut verstanden und klar strukturiert.
• Sie sind arbeitsteilig. Verschiedene Personen bearbeiten verschiedene Aktivitäten in vorgegebenen Reihenfolgen.
• Sie sind von wenig Ausnahmen geprägt und haben eine hohe Wiederholungszahl.
• WIS wurde durch ein Kundenkonsortium in Auftrag gegeben. Die einfache Anpaßbarkeit der Standard-Geschäftsprozesse an unternehmensspezifische Eigenheiten war deshalb eine unbedingte Notwendigkeit.
• Ein anderer - sicherlich weniger technisch geprägter - Grund war, daß die Debatte um Prozeßorientierung im Kontext der Software-Prozeßverbesserung schon eine Weile geführt worden war, so daß die Anwendung der Prozeßorientierung auf stabile Prozesse der Bau- und Wohnungswirtschaft argumentativ gut vorbereitet war.

Ausgehend von diesen Gründen wurden verschiedene Werkzeuge, die die prozeßorientierte Entwicklung unterstützen, untersucht. Bei dieser Untersuchung wurden sowohl reine Prozeßmalwerkzeuge einbezogen (also solche, die bunte Bilder liefern und den Ersteller aus der Pflicht entlassen, sich über die Bedeutung dieser Bilder allzu viele Gedanken zu machen) als auch traditionelle Workflow-Management-Systeme, die die Programmierung von Prozeßmodellen mit recht proprietären Sprachen unterstützen. Eine dritte untersuchte Werkzeugklasse bildete kombinierte Workflow-Management- und Entwicklungswerkzeuge, die fast immer auf der Generierung von Programmcode aus graphisch beschriebenen Prozeßmodellen beruhen. Als Ergebnis dieser Untersuchung wurde 1992 entschieden, die Workflow-Management-Umgebung LEU [8] zu entwickeln. LEU basiert auf den Konzepten des Prototypen MELMAC und setzt diese vollständig um.

Wesentliche Idee von LEU ist es, genau eine Repräsentation der zu unterstützenden Prozeßmodelle zu verwenden. Prozesse werden modelliert, Prozeßmodelle werden analysiert und schrittweise realisiert und die realisierten Prozeßmodelle werden durch die Workflow-Engine [16] zur Laufzeit zur Durchführung gebracht [12]. LEU wurde als einziges Entwicklungswerkzeug für WIS eingesetzt und steuert heute die Geschäftsprozesse mehrerer großer Wohnungsunternehmen.

Die zeitgleiche Einführung von WIS bei mehreren Kunden hat zu der Identifikation vieler Fehler in WIS geführt. Die Gleichzeitigkeit der Einführung hat zudem bewirkt, daß derselbe Fehler von verschiedenen Seiten gemeldet wurde. Abgesehen von Fehlern wurden zahlreiche neue Anforderungen offensichtlich, die zu großen Teilen kundenseitig ebenfalls als Fehler gemeldet wurden.

Um diese Flut von Fehlern und Anforderungen zu bewältigen (teilweise bis zu 50 pro Tag), mußten alle eingehenden Meldungen klassifiziert, elektronisch erfaßt und beantwortet werden. Eine Antwort konnte dabei so aussehen, daß die Berücksichtigung einer Anforderung für ein zukünftiges WIS-Release angekündigt wurde oder daß für einen Fehler ein Beseitigungszeitpunkt oder ein Workaround (also eine behelfsmäßige Vermeidungsstrategie) genannt wurde. Für jeden Fehler mit hohem Schadenspotential mußten darüber hinaus alle WIS-Anwender umgehend benachrichtigt werden.

Dieser Fehlerverfolgungsprozeß wurde mit LEU realisiert. Diese Vorgehensweise paßt zu den Ergebnissen aus [24]. Hier wird geschildert, daß Softwareentwickler am ehesten dazu neigen, den Bereich der Fehlerverfolgung zu automatisieren. Der Umweg über WIS hat auf diese Weise dazu geführt, daß zumindest Teile eines Software-Prozesses mit den Mitteln der Software-Prozeß-Technologie unterstützt wurden. In den folgenden Abschnitten wird dieser Software-Prozeßteil und seine Durchführung detailliert diskutiert.

Die Kundeneinführung und Wartung des Softwaresystems WIS verlangt nach einer professionellen Unterstützung durch entsprechende Software, wie ein Helpdesk mit umfangreicher Fehlerdatenbank. Die Aufgabengebiete dieser Software liegen vor allem in der Unterstützung und Durchführung der Prozesse Problemverfolgung, Anforderungsmanagement und Software-Konfigurationsmanagement. Diese Prozesse sind stark arbeitsteilig und haben eine extrem hohe Wiederholungszahl. Darüber hinaus sind sie gut dokumentiert und definiert, da mit der Einführung eines Qualitätsmanagement-System (QMS) bei o.tel.o-Bochum zur ISO-9000-Zertifizierung alle hausinternen Geschäftsprozesse (GP) untersucht und beschrieben worden sind. Aufgrund dieser Voraussetzungen wurde beschlossen ein geschäftsprozeß-basiertes Problem Tracking System (PTS) mit LEU zu entwickeln.

Folgende Hauptanforderungen werden an das System gestellt:

• Alle auftretenden Problemmeldungen können erfaßt und in einer unternehmensweiten Problemdatenbank gespeichert werden.
• Die Aktivitäten aller beteiligter Personengruppen müssen koordiniert werden.
• Das System übernimmt Konsistenzsicherungsmaßnahmen.
• Der Status eines Problems kann jederzeit ermittelt werden.
• Die Zusammenfassung von Problembehebungen zu neuen Softwarekonfigurationen ist möglich.
• Anforderungen können verwaltet werden.
• Die durch das QMS beschriebenen Verfahren werden unterstützt.
• Die Anbindung von Kunden und externen Mitarbeitern durch Intra- oder Internet ist möglich.

Die Einführung einer software-gestützten und geschäftsprozeß-orientierten Problemverfolgung soll den Weg des Problemreports nachvollziehbar machen. Informationen über die bearbeiteten Probleme müssen jederzeit und von jedem abrufbar sein. Auf diesem Wege kann dann z.B. schnell erkannt werden, ob ein Problem bereits aufgenommen oder sogar gelöst wurde. Auch können dadurch Kundenanfragen bezüglich Bearbeitungsstatus und -dauer schneller beantwortet werden. Der Aufwand und die Fehleranfälligkeit beim Erfassen eines Problemreports soll wesentlich gesenkt und die Gesamtbearbeitungszeit für einen Problemreport verkürzt werden. Verschiedene Tätigkeiten wie z.B. das Schreiben von Kundenbriefen können automatisiert und Controlling-Möglichkeiten geschaffen werden. Die Fehleranfälligkeit des Problemverfolgungsprozesses selbst soll durch Konsistenzsicherungsmaßnahmen, die schon in den Dialogen greifen und die z.B. ein Eintragen von falschen Werten verhindern, verringert werden. Jeder Mitarbeiter soll an seinem Arbeitsplatz in einer Agenda nur die Aktivitäten zur Ausführung angeboten bekommen, die ihm laut QMS-Verfahren zustehen.

Die Modellierung eines LEU-Projektes setzt sich aus Objektmodell, Organisationsmodell und Ablaufmodellen zusammen. Diese Bestandteile des PTS werden nachfolgend vorgestellt.

Jeder Problem Report erhält einen eindeutigen Schlüssel, der im Attribut Problemnummer abgelegt wird. Der Inhalt der Problemmeldung wird in den Attributen Problembeschreibung, Fehlercode, Kurzbeschreibung und Auswirkungen des Problems dokumentiert. Ebenso wird der Auftraggeber und ein Ansprechpartner sowie dessen Telefonnummer festgehalten. Zu jedem Problem wird vermerkt, auf welcher Installation welches Kunden, mit welchem Release und in welchem Softwarebestandteil es aufgetreten ist. Die möglichen Werte dieser Attribute werden vor der Inbetriebnahme des PTS festgelegt. Auf diese Weise wird sichergestellt, daß beim Arbeiten mit dem PTS z.B. nur zugelassene Installationen gültiger Kunden eingegeben werden können. Desweiteren hat jeder Problemreport einen aktuellen Bearbeiter, der zudem historisiert wird. Das bedeutet, daß sowohl der Name des jeweiligen Bearbeiters als auch Zeitpunkt und Status des Problemreports in einer Liste festgehalten werden. Diese Liste stellt dann die gesamte Bearbeitungshistorie des Problemreports dar und kann jederzeit eingesehen werden, um z.B. Eskalationsmechanismen anzustoßen. Der Zustand eines Problemreports wird durch die Attribute Status und Ergebnis dokumentiert. Status beschreibt, welcher Arbeitsschritt zur Zeit an diesem Problemreport durchgeführt wird. Ergebnis wird erst beim Abschluß eines Problemreports von ‘Offen’ auf entweder ‘Behoben’, ‘Anwender-Fehler’ oder ‘Nicht reproduzierbar’ gesetzt. Nicht alle eingehenden Probleme sind auch solche. Stellt sich z.B. während der Bearbeitung heraus, daß es sich in Wirklichkeit um einen Änderungswunsch handelt, so wird dies mit dem Boolean-Attribut Anforderung dokumentiert. So können auch Anforderungen mit dem PTS verwaltet werden.