Requirements Engineering und Geschäftsprozessmodellierung zwei Seiten dergleichen Medaille

Transkript

1 Requirements Engineering und Geschäftsprozessmodellierung zwei Seiten dergleichen Medaille Heinz Ehrsam 1,Ralf Fahney 2,Kurt McKeown 1 1 Credit Suisse, CH-8070 Zürich {heinz.ehrsam kurt.mckeown}@credit-suisse.com 2 FahneyAnforderungsingenieurwesenGmbH, Scheideggstrasse 73, CH-8038 Zürich. rf@fahney.com Abstract: Lassen sich Requirements Engineering und Geschäftsprozessmodellierung im Kontext service-orientierter Architektur überhaupt noch trennen? Die Autoren sind der Auffassung: Ja! Und es ist sinnvoll, die Disziplinen voneinander zutrennen. Die Autoren begründen dies, beschreiben die bei Credit Suisse geplante Integration und zeigen die Implikationen auf für Projektarbeit. Die dargestellten Konzepte und Erfahrungen basieren auf einem Projekt, welches zum Ziel hat, einen umfangreichen Teil historisch gewachsener IT-Systeme der Credit Suisse binnen der nächsten sechs bis sieben Jahre abzulösen durch Neuentwicklung in service-orientierter Architektur. 1Das Projekt Aus geschäftsstrategischen Überlegungen heraus, also getrieben vom Fachbereich, führt Credit Suisse ein Projekt durch, welches einen umfangreichen Teil ihrer historisch gewachsenen Backoffice-Applikationen binnen der nächsten sechs bis sieben Jahre durch zukunftsorientierte Technologien ablösen soll. Daher erarbeitet und pilotiert die Bank derzeit die Grundlagen anhand eines in sich abgeschlossenen Teils der vom neuen SystemzuunterstützendenGeschäftsprozesse. Im Fokusstehen sowohldie Lösungstechnologien Integration von Geschäftsprozess-, Use Case-, Daten- und Regelmodell auf der konzeptionellen Ebene Automatisierte Transformation der modellierten Geschäftsprozesse in eine Business Process Engine Einsatz einer Business Rule Engine Serviceorientierte Architektur (SOA) Codegenerierunggemäß Model-DrivenArchitcture (MDA) 205

2 als auchdie Prozesse zur Lösungsentwicklung Projektmanagement gemäss SCRUM Requirements Engineering (RE) und Geschäftsprozessmodellierung (Business Process Modelling, BPM) alsgleichberechtigte Verfahren zur Spezifikation Implementierung auf Basis der Geschäftsprozessmodelle Testdurchführung auf Basis der Requirements Automatisierte Regressionstests Die Ergebnisse und Erfahrungen aus den pilotierten Prozessen werden wesentlich die zentralen Prozessvorgaben beeinflussen, auch im Hinblick auf die Zertifizierung gemäss CMMI Maturity Level 3, welchecredit Suisse für2010plant. Dieser Beitrag beschreibt die bisherigen Erfahrungen von Credit Suisse aus der PilotierungimBereich RequirementsEngineering undgeschäftsprozessmodellierung. 2Die Herausforderung Zu Beginn des erwähnten Projektes sprachen die Experten für BPM und SOA über Begriffe wie Business Process, Business Rule, Business Service, IT Service oder Business Object. In den von den Experten ausgearbeiteten Metamodellen gab es den Begriff Anforderung nicht. Gemäß der Planung dieser Experten sollten die Prozessbeschreibungen z.b. Ausführungen enthalten, was unter einem Business Process oder einer Business Rule zu verstehen sei, welche Arten von IT Services es gibt und wie Modelle des Computation Independent Model (CIM) zu transformieren sind in Modelle des Platform Independent Model (PIM) und Platform Specific Model (PSM) 1.Die Prozessbeschreibungen hätten jedoch keine Ausführungen enthalten darüber, wie Anforderungen andas zukünftige System systematisch zu erheben, zu dokumentieren undzuverwalten, derprojektumfang zu definieren, zu verhandeln und zu vereinbaren, das Projekt auf Basis der Anforderungen zuplanenoder dieanforderungen inmodelle zu transformieren sind. Aus den Gesprächen mit dem Fachbereich erarbeiteten die Experten für BPM und SOA Modelle für Geschäftsprozesse oder Geschäftsobjekte, dokumentierten jedoch nicht die den Modellen zugrundeliegenden Anforderungen. Dies sahen die Experten für BPM und SOA als redundante Nacharbeit und mithin überflüssigen Aufwand an. Auf diese Weise war z.b. die Entstehungsgeschichte und Begründung von Modellen im besten Fall unvollständig rekonstruierbar. Dies erschwerte u.a. Verhandlungen mit dem Fachbereich überden geforderten Projektumfang. 1 DieBegriffeComputation Independent Model, Platform Independent Model und Platform Specific Model sowie die Abkürzungen CIM, PIMund PSM entstammen [OMG03].Dort sind auch die Bedeutungen der Begriffe eingehend erläutert. 206

3 Es entstand der Eindruck, dass den Experten für BPM und SOA der Einsatz bewährter Verfahren des RE unbekannt, zu aufwändig oder nicht sinnvoll erschien. Die Experten für BPM und SOA sahen nicht die Notwendigkeiten des Projektmanagements (z.b. Verhandlung von Anforderungen mit dem Fachbereich auf Basis geschätzter Kosten) unddes Qualitätsmanagements(z.B. anforderungs-getriebener Test). Die Herausforderung bestand darin, bei den Experten für BPM und SOA das Verständnis zu wecken für den Sinn und die Notwendigkeit eines systematischen RE. Weiters war es erforderlich, ein Modell und ein Vorgehen zu finden, welches die Bedürfnisse von BPM/SOA aufder einenund RE aufder anderen Seite abdeckt. 3Der Lösungsansatz Dieser Beitrag versteht unter Requirements Engineering sämtliche Tätigkeiten, welche erforderlich sind, um(produkt- und Projekt-) Anforderungen zu erheben,zu analysieren, zu verstehen und zu dokumentieren. Dies betrifft Anforderungen an alle Arten von Ergebnissen, nichtnur Anforderungen angeschäftsprozesse oder IT-Systeme. Business Process Modelling ist diejenige Lösungsdisziplin, welche Anforderungen an Geschäftprozesse umsetzt in Modelle, welche auf konzeptioneller Ebene die Geschäftsprozesse beschreiben, die eine Lösungfürdiese Anforderungensind. Die Integration der beiden Disziplinen RE und BPM besteht in der Zusammenführung der beiden Sichten auf Systementwicklung in ein dreidimensionales Modell und die Positionierung von RE als diejenige Disziplin, welche die Grundlagen dafür liefert, dass BPM die richtigen Geschäftsprozessekonzipiert. 3.1Drei Dimensionen der Systementwicklung Credit Suisse verwendet in dem erwähnten Projekt die dreidimensionale Sicht auf die Systementwicklung, welche Forsberg und Mooz in [FM91] einführten unter dem Namen Vee-Model und Vee-Chart.Die drei Dimensionensind Abstraktionsebenen, in Abb. 1 dargestellt in der senkrechten Dimension. Credit Suisse verwendet die Ebenen Business Request, CIM, PIM, PSM und Implementierung 2. Anforderungen, Rahmenbedingungen und Überprüfung deren Erfüllung, in Abb.1 dargestellt in der waagrechten Dimension. Credit Suisse verwendet u.a. die Konzepte Request, Feature und Requirement, dokumentiert in Request- und Anforderungslisten. MS Excel kommt hierbei genauso zum Einsatz wie einschlägigewerkzeuge fürdas RE. 2 Zur Erläuterung der Akronyme CIM, PIM und PSM verweisen wir auf [OMG03] 207

4 Definition, Dekomposition, Vereinbarung Business Request CIM -Computation Independent Model 1. Vereinbarung PIM -Platform Independent Model 2. Vereinbarung PSM Platform Specific Model "Trace To" Implementation Integration auf PIM-Ebene Integration auf PSM-Ebene Integration auf Ebene Bus.Rqst. Integration auf CIM-Ebene Integration, Verifikation, Abnahme Anforderungen, Rahmenbedingungen &Abnahme Abstraktionsebene Ergebnis /Produkt/Lösung Abbildung 1: Anforderungs-orientierte Sicht auf die Systementwicklung =Blick auf die Systementwicklung gemäß [FM91]durch die Brille von Experten für RE Ergebnisse /Produkte /Lösungen, in Abb. 1 senkrecht zum Papier zu denken und angedeutet durch die schräggestellt gezeichnete Matrix. Credit Suisse verwendet dieergebniskategoriengeschäftsprozess,daten,services, Regeln. Forsberg und Mooz sprechen von Konfigurationseinheiten statt von Ergebnissen, Produkten oder Lösungen. Das Vee-Model beschreibt auf der linken Seite des V die schrittweise Verfeinerung der Anforderungen an ein Produkt über die verschiedenen Abstraktionsebenen hinweg bis hinunter auf eine Granularität, in welcher die Implementierung möglich wird. Auf der rechten Seite des V beschreibt das Vee-Model die schrittweise Integration des Produkts aus seinen Komponenten über die Abstraktionsebenen hinweg, sowie die Verifikation der Funktionalität anhand der auf der jeweiligen Ebene ermittelten Anforderungen. Die Vereinbarung des Funktionsumfangs mit dem Fachbereich findet zu zwei Zeitpunkten im Projekt statt: Das erste Mal nachdem die Business Requests 208

5 Abstraktions ebene Business Request CIM PIM PSM Ergebnis kategorie Implementation Geschäftsprozess Daten Ergebnis, Produkt, Lösung Services Anforderungen, Rahmenbedingungen & Abnahme Abbildung 2: Lösungs-orientierte Sicht auf die Systementwicklung =Blick auf die Systementwicklung gemäß [FM91] durch die Brille von Experten für BPM/SOA: Die drei Dimensionen des Vee-Model gedreht um 90 Grad im Uhrzeigersinn um die Achse der Abstraktionsebenen verstanden und angemessen dokumentiert sind. Das zweite Mal nachdem die CIM- Modelle ausreichend weit fortgeschritten erstellt wurden. Auf jeder Abstraktionsebene gibt es sowohl Anforderungen als auch Lösungen für diese Anforderungen. Dies ist angedeutet durch die dritte Dimension, welche man sich senkrecht zum Papier stehend denken muss. Sie ist in Abb. 1angedeutet durch die schrägstehende Matrix und den Pfeil Ergebnis /Produkt /Lösung. Abb.2zeigt diese Matrix als Hauptaspekt. Kapitel 3.2 enthält ein Beispiel. "Lösungen" auf den Ebenen CIM, PIM und PSM meint Modelle und Konzepte, welche auf der Ebene CIM z.b. die Umsetzung von Marktanforderungen in Geschäftsprozesse beschreiben und auf der Ebene PIM die IT-Unterstützung für diese Geschäftsprozesse. "Lösungen" auf den Ebenen CIM, PIM und PSM sind nicht Implementierungen in einer konkreten Programmiersprache. Der fundamentale Zusammenhang zwischen den Modellen und Konzepten einer Ebene undden Anforderungen allerdarunter liegenden Ebenen ist wie folgt: Regeln Abstraktionsebene 209

6 Die Einhaltung dermodelle undkonzepteder übergeordneten Ebenen ist implizit eine Anforderung an die LösungenallerdarunterliegendenEbenen. Die Abbildungen 1 und 2 zeigen und definieren anhand des Vee-Model aus [FM91] die anforderungs- unddie lösungsorientierte Sichtauf diesystementwicklung. 3.2 Ein Beispiel Abstraktionsebene Anforderung Lösung Business Request Der Fachbereich benötigt Unterstützung für die Abwicklung von Geschäften mit physischen Schweizer Namenaktien Entscheid des Fachbereichs, die Durchführung von Lieferaufträgen von Namenaktien als eigenständigen Geschäftsprozess zu betrachten. Computation Independent Model (CIM) Platform Independent Model (PIM) Platform Independent Model (PSM) Der Geschäftsprozess Lieferauftrag Namenaktie durchführen muss umfassen, die notwendigen Kundendokumente zu erzeugen Das System muss diejenigen Kundendokumente erzeugen, deren Dokumenttypen das System zuvor aus den Lieferinstruktionen des Kunden ermittelt hat System muss OraBPM als Process Engine verwenden Das Projekt muss XPDL verwenden umepk in die OraBPM-interne Prozessdarstellung zu transformieren Das Projekt muss berücksichtigen, dass ARIS und OraBPM den XPDL Standard unterschiedlich interpretieren EPK des Geschäftsprozess Lieferauftrag Namenaktie durchführen. Dieses EPK enthält die Funktion Kundendokumente erzeugen. EPK der Funktion Kundendokumente erzeugen. Dieses EPK enthält die Aufrufe der IT Services Liste der Kundendokumenttypen berechnen und Kundendokumente drucken XPDL-Datei für die Funktion Kundendokumente erzeugen, exportiert aus ARIS und angepasst an die OraBPM Import-Funktionlität 210

7 Implementierung Die von der XPDL-Datei beschriebende Funktionalität Die nach dem Import der Datei in die OraBPM von OraBPM erzeugte interne Repräsentation 3.3. Nutzen der gewählten Lösung Mit dem beschriebenen Vorgehen wurde es möglich, zu erklären, dass Experten für RE und Experten für BPM/SOA aus unterschiedlichen Blickwinkeln auf das zu entwickelnde Systemschauen. den Experten für BPM und SOA zu erläutern, dass RE ein wesentlicher Bestandteil ihrer Arbeit auch dann ist, wenn sie die Anforderungen nicht ausdrücklich dokumentieren oder Anforderungsanalyse (noch) nicht als Bestandteilihrer Tätigkeitsehen.[HFW07] zeigt ebenfalls diesen Aspekt auf zu erklären, weswegen die Metamodelle für BPM und SOA den Begriff Anforderung nicht enthalten: Diese Metamodelle beziehen sich lediglich auf die zweidimensionale Sicht der Experten für BPM/SOA, bestehend aus den Dimensionen Abstraktionsebene undergebnis/produkt/lösung. 4Erfahrungen aus der Anwendung der Konzepte 4.1 Anforderungs-orientierte Sicht als temporäre Sicht während der Projektarbeit, lösungs-orientierte Sicht als dauerhafte Sicht über denlebenszyklus hinweg Aus der Erfahrung von Credit Suisse hat es sich als wenig praktikabel erwiesen, Anforderungen in Anforderungslisten in vollem Detaillierungsgrad auszuformulieren und über den gesamten Lebenszyklus eines ITSystems hinweg zu pflegen und aktuell zu halten: Je weiter die Spezifikationsarbeit voran schreitet, umso mehr liegt der Fokus auf der unmittelbaren Arbeit an Modellen. Die ursprünglich in Anforderungslisten aufgeschriebenen Texte müssten aufwändig und sogar redundant nachgepflegt werden. Die Motivation der Mitarbeiter für derartige Pflege ist eher wenig ausgeprägt. In manchen Situationen eignen sich Modelle schon für den Einstieg in die Analysearbeit besser als textuelle Repräsentationen von Anforderungen. Daher verwendet Credit Suisse Anforderungslisten lediglich als Mittel zur Strukturierung und Planung der Spezifikationstätigkeit innerhalb eines Projektes. Anforderungslisten verlieren ihre Bedeutung nach Projektabschluss. Bedeutung über den Projektabschluss hinaus hat die lösungsorientierte Sicht, alsodie Produktspezifikationen. Nachteil dieses Vorgehens ist, dass die Begründungen und Quellen für eine bestimmte Modellierung nicht vollständig nachvollziehbar sind. Die Granularität der Historienführung bei den Modellen ist nicht geeignet, jedes Detail der Anforderungsklärung und jeden detaillierten Entscheid auch so detailliert zu 211

8 Undokumentierte Anforderungen % CIM 1. Vereinbarung 30 60% 'Business-View' Anforderungsdatenbank = Explizit dokumentierte Anforderungen 10 40% 5 20% % PIM PSM 2. Vereinbarung RE & Sol.Eng. Sol.Eng % Abbildung 3: Geschätzter Grad der Vollständigkeit von Anforderungslisten in einem ausgewählten Projekt bei Credit Suisse protokollieren.hier sind diemöglichkeiten eines einschlägigen Requirement-Werkzeugs deutlich höher. Derzeit gewichtet Credit Suisse diesen Nachteil jedoch geringer als den Vorteilder geringeren Redundanz zwischenmodellenund Anforderungslisten. Abbildung 3 zeigt den geschätzten Grad an Vollständigkeit der Anforderungslisten in dem eingangs erwähnten Projekt. Auf der Ebene CIM z.b. wurden nur 30-60% der Anforderungen an Geschäftsprozesse in den Anforderungslisten dokumentiert % der Anforderungen an die Geschäftsprozesse wurden jedoch nie in die Anforderungslisten eingetragen. Stattdessen setzten die Geschäftsprozessingenieure nach der Anforderungsanalyse diese 40-70% der Anforderungen direkt um in Geschäftsprozessmodelle. Auf den Ebenen PIM und PSM liegt der Anteil der nicht in Anforderungslisten dokumentierten Anforderungen noch deutlich höher. Diese Schätzung ist spezifisch für dieses Projekt zum Zeitpunkt der Erstellung dieses Beitrags. Die Schätzung kann anders ausfallen sowohl in anderen Projekten und Unternehmen als auch zu späteren Zeitpunkten im gleichen Projekt. Um die Vollständigkeit der Umsetzung von Anforderungen in Produktspezifikationen prüfen zukönnen, setzt Credit Suisse Traceability ein. 4.2Auswirkungder Erfahrungenauf Projektplanung, Kostenschätzung und Test Ursprünglich plante das Test Team, die Anforderungslisten als Basis für die Ableitung von Testfällen zuverwenden. Dies vor allem, weil zwischen Requirements-Werkzeug und dem Werkzeug für das Testmanagement eine Schnittstelle für die automatisierte Übernahme von Anforderungen existiert und funktioniert. Wie erwähnt sind die Anforderungslisten nicht mehr zwingend vollständig und existieren auch nicht in dem 212

9 Detailgrad, welcher für die Ableitung von Testfällen erforderlich wäre. Ein alternatives Vorgehen ist deswegen erforderlich und wird derzeit ausgearbeitet. Es bietet sich an, die Testfälle aus den Modellen abzuleiten. Eine Schnittstelle zur automatisierten Übernahme von Modellen indas Werkzeugfürdas Testmanagementist derzeitjedochnicht bekannt. Ähnliches gilt für die Kostenschätzung. Die Projektleitung wünscht für die Verhandlungen mit dem Projektauftraggeber eine Kostenschätzung pro Anforderung. Derart geschätzte Kosten, über alle Anforderungen der Anforderungsliste summiert, würden jedoch nicht die Gesamtkosten beziffern. Eine Kostenschätzung auf Basis der Produktspezifikationen erscheint unumgänglich, könnte jedoch weniger leicht mit dem Fachbereich verhandelbar sein. Das am Ende geeignete Verfahren ist noch nicht festgelegt. Die Projektleitung hat fürein Vorgehen gemäss SCRUM entschieden. Dies nicht nur für dieprogrammierung, sondern auch dort, wo es um dieerstellung von Modellenund anderer Dokumentation geht. Ursprünglichwar angedacht, die Inhalte jeder Iteration auf Basis von Anforderungen zu planen. Es zeigt sich, dass die Mitarbeiter eine Iterationsplanung auf Basis von zu implementierenden Produktspezifikationen bevorzugen. 4.3 Wie passen Use Cases zu Geschäftsprozessmodellierung und SOA? Zu Beginn des Projektes überwog die Ansicht, dass der Begriff Use Case seine Bedeutung verliert, wenn Geschäftsprozesse so weit ausmodelliert werden, dass sie automatisch in eine Business Process Engine transformierbar sind und noch im Modell mit ITServices verknüpft werden können. Gestützt hat diese These Ivar Jacobson anlässlich eines Referates bei Credit Suisse. Er vertrat die Ansicht, dass Business Process und Business Use Case synonym verwendbare Begriffe sind. Denkt man diese Analogie weiter, könnte man das aus [COCK05] bekannte Konzept "System Use Case" auch "System Process" nennen. Ungewöhnlich zwar, aber möglich. Credit Suisse hat entschieden, von "Business Process" (gibt es auf Ebene CIM und PIM) und "(System) Use Case" (gibt es auf Ebene PIM) zusprechen. Erfahrene Geschäftsprozessmodellierer bei Credit Suisse ziehen eine Analogie zwischen der Spezifikation eines System Use Case mittels EPK und der grafischen Modellierung der in einer Java-Methode programmierten Funktionalität z.b. mittels Sequenzdiagrammen: Einen System Use Case sollte man textuellbeschreiben. Die Integration von Geschäftsprozessmodellen, anderen Modellen und Process Engines ist nicht nahtlos, die Umsetzung der Visionen von SOA daher noch nicht möglich. Also gibt es derzeit nicht die Notwendigkeit, im EPK auch diejenigen Details einschliesslich der aufgerufenen IT Services zu modellieren, die CreditSuisse derzeitinuse Case Spezifikationen textuellbeschreibt. In der Methodik der Credit Suisse ist der Begriff Use Case tief verankert. Auf ihn zu verzichten hätte einer umfänglichen Überzeugungsarbeit bedurft, welche angesichts der bereits erwähnten Argumente, insbesondere der nicht nahtlos 213

10 miteinander integrierten Modelle und Process Engines, schwierig zu leisten gewesen wäre. 5Zusammenfassung Die Erfahrungen von Credit Suisse deuten darauf hin, dass produkt-orientierte Spezifikation von Anforderungen den Erfordernissen der Lösungsentwicklung im Umfeld von BPM und SOA besser gerecht wird als eine detaillierte textuelle Ausformulierung von Anforderungen in Form von Anforderungslisten. Trotzdem helfen Anforderungslisten, den Prozess der Anforderungsspezifikation zu planen und zu strukturieren. Insofern ergibt es weiterhin Sinn, eine anforderungs-orientierte und eine lösungs-orientierte Sicht voneinander zu trennen und das Sammeln von Anforderungen als Aktivitätinder Lösungsentwicklungnicht nur zuzulassen, sondern einzufordern. Noch nicht vollständig abgeschlossen sind bei Credit Suisse die Überlegungen, welche Konsequenzen sich aus dieser Erkenntnis für die Organisation von Tests, die Kostenschätzung, deren Verhandlung mit dem Auftraggeber, und die Projektplanung ergeben. Entsprechende Erfahrungen wird Credit Suisse anlässlich des geplanten Workshopsjedochberichten können. Literaturverzeichnis [COCK05] Alistair Cockburn, "Writing Effective Use Cases", Addison-Wesley, 2005 [FM91] Kevin Forsberg, Harold Mooz, The Relationship of System Engineering to the Project Cycle, presented at the joint conference sponsored by: National Council On Systems Engineering (NCOSE) and American Society for Engineering Management (ASEM), Chattanooga, TN, October 1991, abrufbar 20of% 20SE% 20to% 20 Proj% 20Cycle.pdf [HFW07] Andrea Herrmann, Ralf Fahney, Rüdiger Weißbach, Wie viel Requirements Engineering steckt im Software Engineering im gleichnamigen Workshop, Hamburg, Deutschland, März 2007,abrufbar: ersion.pdf [OMG03] Joaquin Miller, Jishnu Mukerji, "MDA Guide Version 1.0.1", 2003, abrufbar: 214