Qualitätsverbesserung und Kostenreduktion bei der Softwareentwicklung durch Business Modellierung und Prototyping

Transkript

1 Qualitätsverbesserung und Kostenreduktion bei der Softwareentwicklung durch Business Modellierung und Prototyping Dr. Stefan Karkew, esop GmbH Die Botschaft dieses Artikels ist die Botschaft des agilen Vorgehens: Konzentrieren Sie sich bei der Softwareentwicklung auf das Entwickeln von Software und nicht auf das Schreiben von umfangreichen Dokumenten. Das Problem ist, dass durch die Trennung von Fach- und IT-Abteilung in vielen Unternehmen die Einführung einer agilen Vorgehensweise mit vielen Hürden verbunden ist. Die Problematik ist besonders verstärkt zu beobachten, wenn die Entwicklung offshore vergeben und betrieben wird. In diesem Artikel wird eine neuartige Vorgehensweise vorgestellt Agile Methoden bei der Softwareentwicklung einzuführen. Sie wurde in mehreren Projekten erfolgreich eingesetzt und führt zu deutlicher Qualitätsverbesserung und Kostenreduktion im Vergleich zu konventionellen Methoden. Das Vorgehen ist eine Synthese aus Domain Driven Design, Business Modellierung und Prototyping. Der Fokus liegt auf der Anforderungsanalyse und auf der effizienten Integration der Fachseite im Entwicklungsprozess. Die Business Vision frühzeitig im Projektzyklus richtig und vollständig und zu erfassen ist ausschlaggebend für den Erfolg eines Projektes. Wiedergutmachung von Missverständnissen in dieser Phase kann in späteren Phasen bis zu 100-fache Kosten verursachen. Die nachfolgende Abbildung zeigt als Metamodell die vorgeschlagene Vorgehensweise im Detail.

2 Konventionelle Vorgehensweise Betrachten wir zuerst die zurzeit dominierende Vorgehensweise. Die zwei zentralen fachlichen Artefakte der Anforderungsanalyse dabei sind das Domänenmodell und die Use Cases (der Teil im Bild rechts). Das Domänenmodell ist die visuelle Repräsentation (UML Klassendiagramm) der problemrelevanten Konzepte (Business Objekte) einer Domäne. Die Use Cases sind Textdokumente und Text lässt bekanntlich dem Lesenden viel Raum für Interpretationen. Mit Hilfe von Aktivitäten-, Sequenz- und Zustands-Diagrammen kann der Interpretationsfreiraum zwar minimiert werden, ein Restrisiko für Missverständnisse bleibt jedoch vorgehensbedingt immer bestehen. Im besten Fall endet die Anforderungsanalyse mit einer Abnahme durch die Fachseite anhand von definierten Abnahmekriterien. Ob allerdings alles richtig und vollständig verstanden ist, wird jedoch erst Monate bzw. sogar Jahre später frühestens bei den Systemund Integrations- Tests festgestellt. Fehler zu diesem Zeitpunkt zu korrigieren sind jedoch bekanntlich sehr kostspielig. Neuartige Vorgehensweise Die in diesem Artikel vorgeschlagene Vorgehensweise ARMEP (Agile Requirement Modeling and Evolutionary Prototyping) modifiziert und erweitert die konventionelle Vorgehensweise und führt zwei neue Konzepte als selbständige Tasks ein: Business Modellierung und Prototyping. Dabei werden vorrangig drei Ideen verfolgt: Integration der Fachseite im Projekt auf einer Abstraktionsebene, bei der direkter Wissenstransfer von der Fachseite zur Entwicklung stattfindet Evolutionäre Erarbeitung der Anforderungen durch Modellierung und Simulation an einem iterativ entwickelten Prototyp Abnahme des Prototyps durch die Fachseite, womit die Gefahr an den fachlichen Anforderungen vorbei zu realisieren de facto ausgeschlossen wird Zentrale Rolle bei dieser Vorgehensweise übernimmt das Business Modellierungsteam (im Bild der mittlere Kasten). Als optimale Arbeitsorganisation bietet sich das Modellieren in Paaren an. Ein Paar besteht aus einem Domänenexperten und einem Business Modellierer. Der Domänenxperte repräsentiert die Sicht (die Business Vision) des Auftraggebers und kennt sich bestens in dem Fachgebiet aus. Er hat klare Vorstellung, was das System tun soll, welche Ergebnisse zu erwarten sind und kann alle auftretenden Fragen entweder sofort oder nach Rücksprache beantworten. Der Business Modellierer kommt eher aus der technischen Ecke. Er verfügt über umfangreiche Modellierungs- und Programmier-Fertigkeiten und hat sich in dem Fachgebiet soweit eingearbeitet, dass er im Dialog mit dem Domänenexperten die Sachverhalte verstehen und modellieren kann. Die zwei zentralen Artefakte, die das Business Modellierungsteam erarbeitet, sind das Domänenmodell und der Prototyp.

3 Die Qualität des Domänenmodells ist bei dieser Vorgehensweise weit höher als bei der konventionellen Vorgehensweise, da das Modell parallel und als Teil des Prototyps evolutionär entsteht und anhand von fachgetriebenen Simulationen ständig überprüft und vervollkommnet wird. Es ist die Aufgabe des Business Modellierers den Domänenexperten in die Welt der objektorientierten Modellierung und der UML-Notation einzuführen. Erfahrungsgemäß ist dies i.d.r. kein einfacher Job. Die fachgetriebene Vorgehensweise (Domain Driven Design) hat sich dabei als enorme Hilfe erwiesen. Die Domäne des Fachexperten die Fachkonzepte werden direkt 1 zu 1 als Business Objekte in UML formuliert. Diese Methodik kommt der Denkweise des Domänenexperten sehr entgegen und erleichtert die Einführung der UML Notation. Die Visualisierung der Geschäftsszenarien ist weiterhin der Phantasie des Domänenexperten überlassen verblieben. Dies fällt den meisten Fachleuten erfahrungsgemäß sehr schwer. Das ist der Punkt, an dem das Prototyping ins Spiel kommt. Für den Prototyp gilt: Er ist die zentrale Kommunikations- und Simulationsplattform, um Geschäftsszenarien zu visualisieren und sie mit allen Stakeholdern abzustimmen Er ist kein Wegwerfprodukt sondern eine Referenzimplementierung, die die eigentliche Entwicklung steuert und justiert Er unterstützt die automatisierte Generierung von Test Szenarien für die endgültige Abnahme der Software. Er unterstützt bei Bedarf die Erstellung von Use Cases und die automatisierte Generierung von weiteren Dokumentationen. Er implementiert alle fachlich relevanten End-to-End Szenarien und ist nach einer umfassenden Simulationsphase durch die Fachseite abzunehmen Die nachfolgende Abbildung zeigt den Projektablauf unter Einsatz von ARMEP:

4 Naked Objects als Framework für Prototyping Für die Erstellung eines Prototyps, der alle diese Anforderungen erfüllt, hat sich das Open Source Framework Naked Objects ( sehr gut bewährt. Es erlaubt die gesamte Fachlogik in Fachobjekten abzubilden und übernimmt die Animation der Objekte und Business Szenarien in einer Art Avatar -Form. Bei der Entwicklung des Prototyps verbleibt das Modellierungspaar stets auf der konzeptionellen Ebene des Domänenexperten und wird nicht durch technische Details abgelenkt.

5 Werfen wir einen kurzen Blick auf die Arbeitsweise des Modellierungspaares. Zu einem Zeitpunkt arbeitet das Paar an einem Szenario (User Story) und den beteiligten Business Objekten. Die Aufgabe besteht darin, die Business Objekte zu identifizieren und sie mit Eigenschaften und Verhalten so auszustatten, dass sie den modellierten Business Prozess als Interaktion untereinander implementieren. Die Arbeitsweise ist interaktiv. Der Domänenexperte erläutert, der Business Modellierer modelliert und implementiert. Anders als bei der konventionellen Arbeitsweise, erfährt der Domänenexperte sofort, wie seine Anforderungen verstanden und realisiert werden. Am Szenario wird evolutionär soweit gearbeitet, bis die Erwartungen des Domänenexperten erfüllt sind. Der Mehrwert dieser Vorgehensweise besteht unter anderem auch darin, dass sie sehr viele AHA- Momente bei allen Stakeholdern hervorruft. Sehr oft stellt die Fachseite dabei fest, dass Anforderungen nicht bis zum Ende durchdacht und anders zu stellen sind. Die nachfolgende Abbildung zeigt ein Schnappschuss vom Desktop eines Prototyps, um einen groben Eindruck vom Umgang mit ihm zu vermitteln. Darauf zu sehen sind: einige Business Objekte in UML Notation als Teil des Domänenmodells Avatare für diese Objekte in Naked Objects Repositories, die Auswahl und Anschauen von Objekten ermöglichen eine dedizierte Repository mit End-to-End Szenarien, die per Klick ausgeführt werden können. Arbeitsdaten für die Simulation sind Business Objekte, die durch Factories generiert, durch Repositories aus einer Datenbank gelesen oder durch Adapter von anderen Systemen übernommen werden. Die Simulation selbst basiert auf demausführen der End-to-End Szenarien im Pool User Stories. Das Ergebnis sind neue Business Objekte oder Zustandsänderungen von bestehenden Objekten.

6 Das Umgehen mit dem Prototyp ist intuitiv und bietet Möglichkeiten, die weit über das hinaus gehen, was andere Plattformen für Rapid Prototyping leisten. Die zwei entscheidenden Unterscheidungsmerkmale sind: die Abstraktionsebene ist die Denkebene des Domänenexperten fachliche Konzepte werden exakt modelliert und mit Hilfe von Avataren in ihrer Dynamik visualisiert der Prototyp ist kein Seitenprodukt - er kann nahtlos in die weitere JEE Entwicklung übernommen werden Projektorganisation Als Organisationsform bietet sich die evolutionäre und iterative Prototypentwicklung an. Um schnell voranzukommen ist eine Iteration auf eine, maximal drei Wochen festzulegen (je risikoreicher das Vorhaben, desto kürzer sollten die Iterationen sein). Drei bis fünf Iterationen sind i.d.r. ausreichend, um einen fachlich anspruchsvollen Prototyp (z.b. Bestandsführungs- oder Trading System) zu erstellen. Eine Iteration besteht aus Arbeitseinheiten, wobei eine Arbeitseinheit mit Modellierung und Prototyping eines End-to-End Business Szenarios gleichzusetzen ist. Beispiele für End-To-End Szenarien sind z.b. bei einem Bestandsführungssystem das Auszahlen eines Darlehens oder das Verbuchen einer Sondertilgung. Die Erfahrung zeigt, dass ein Business Modellierungspaar i.d.r. eine Arbeitseinheit pro Tag erledigen kann, was pro Iteration bis zu 15 Arbeitseinheiten entspricht. Wird SCRUM für die Projektdurchführung angewendet, so besteht das Unterprojekt der Business Modellierung und Prototyping aus 3 bis 5 Sprints zu jeweils 1 bis 3 Wochen. Zum Abschluss sind die Artefakte (Domain Modell und Prototyp) durch die Fachseite offiziell abzunehmen. Die Transition zu der eigentlichen Entwicklung hängt vom Gesamtprojektrahmen ab. Ist die Fachseite an einem Festpreisprojekt interessiert, so empfiehlt es sich Business Modellierung und Prototyping als internes Projekt vorab durchzuführen. Ein fachlicher Prototyp gibt einem Festpreisprojekt reale Chancen zeitlich und kostenmäßig erfolgreich zu werden. Läuft Business Modellierung und Prototyping als Subprojekt, so kann die eigentliche Entwicklung im Prinzip nach dem Ende des ersten Sprints gestartet werden. Wenn der zeitliche Rahmen es erlaubt, ist es empfehlenswert, mit der Entwicklung erst nach der Abnahme des Prototyps durch die Fachseite zu beginnen. Dies ist besonders dann der Fall, wenn die Entwicklung offshore stattfindet.

7 Unternehmensweite aktive Wissensbank Ein sehr wertvoller Seiteneffekt der vorgeschlagenen Vorgehensweise soll noch kurz aufgeführt werden: Die Business Klassen, die Bausteine bzw. Ausgangsprodukte des Prototyps sind, können in einem unternehmensweiten Repository aufbewahrt werden. Dieses Repository ist eine Art Wissensbank und wird mit jedem neuen Projekt im Unternehmen (Community) iterativ ausgebaut. Letztendlich sind Business Klassen in Software implementierte und damit greifbare Fachkonzepte. Wenn ein neues Projekt das vorhandene Wissen nutzen will, kann das Business Modellierungsteam Business Klassen aus der Repository in die Laufzeitumgebung des zu erstellenden Prototyps übernehmen und wiederverwenden. Im Laufe der Anforderungsanalyse werden diese durch weitere Eigenschaften und Verhalten angereichert und neue Assoziationen zu anderen Business Klassen definiert. Projekte partizipieren aktiv am vorhandenen Wissen im Unternehmen (Community) und bauen es sukzessiv aus. Zusammenfassung Zum Abschluss eine kurze Zusammenfassung der Vorteile der vorgeschlagenen Vorgehensweise, die auf Erfahrungswerte von einigen Projekten basiert. Verbesserung der Qualität zweifelsfrei steht das Qualitätskriterium korrekte und vollständige Abbildung der fachlichen Anforderungen an erster Stelle und genau dies unterstützt das Vorgehen zu 100% durch frühzeitige Klärung der Fachlichkeit ermöglicht das Vorgehen die volle Konzentration auf die nicht funktionalen Anforderungen und damit optimiertes Design und Softwarearchitektur automatisiertes Generieren von Testszenarien womit die Testabdeckung erhöht werden kann Kostenreduktion Verkürzen der Phase der Anforderungsanalyse um einen Faktor von 2 bis 5 (Erfahrungswerte, hängen stark von den Stakeholdern ab). Beschleunigung der Entwicklung (geschätzte 10 bis 30%), durch die Vorgabe einer Referenzimplementierung (fachliche Architektur) und die Möglichkeit Abläufe gegenüber dieser Referenzimplementierung zu testen. echte Chancen für realistische Festpreisprojekte und offshore Entwicklung, da die Gefahr an den Anforderungen vorbei zu implementieren und am Ende nicht das Bestellte zu bekommen de facto ausgeschlossen ist.