Die S Rating und Risikosysteme GmbH (SR) pflegt als zentraler Methodendienstleister der Sparkassen-Finanzgruppe in Zusammenarbeit mit der LBS-Gruppe deren gemeinsames Kollektivsimulationsmodell. Ein solches Kollektivsimulationsmodell dient Bausparkassen allgemein zur Fortrechnung von Bestandsgrößen und Zahlungsströmen ihres Bausparerkollektivs unter bestimmten Szenarioannahmen als wesentlicher Teil von deren Planung und Risikosteuerung. Das Kollektivsimulationsmodell der LBS-Gruppe war bislang als lokal in den einzelnen Instituten ausführbare Anwendung umgesetzt. Es sollte nach methodischer Weiterentwicklung nun auch in seiner technischen Umsetzung als „State-of-the Art“-Web-Architektur in puncto Benutzeroberfläche und Laufzeitumgebung unter Beibehaltung des methodischen Kerns grundlegend modernisiert werden. So soll es künftigen fachlichen, aufsichtlichen und strategischen Anforderungen der Bausparkassen gerecht werden.
Die Projektdurchführung einschließlich Vorstudie erfolgte durch die SR, die hierbei durch viadee beraten und unterstützt wurde. Die Vorstudie und das Projekt wurden in der geplanten Zeit von drei Jahren und sogar unter dem geplanten Budget mit maximaler Funktionalität und verschiedenen weiteren wünschenswerten Funktionen umgesetzt, die in den Feedbackschleifen als nützlich evaluiert wurden. In diesem Blogartikel wollen wir die Erfolgsfaktoren des Projekts beschreiben.
User-Stories helfen, die passenden Anforderungen an die Anwendung zu finden
In einer Vorstudie zum Projekt wurde gemeinsam die Architektur und der Scope definiert. Hier fand der Schnitt der Funktionen in User Stories statt, die zum Teil aus der Alt-Anwendung abgeleitet werden konnten. Die Erhebung der zu betrachtenden User Stories beinhaltete eine Schärfung der gewünschten und eine Ermittlung der noch nicht bekannten Anforderungen mit der Frage: „Was soll die Anwendung warum für wen leisten?“. Das Verständnis ermöglichte eine Reduktion der Bandbreite für die Aufwandsschätzung des Umsetzungsprojekts und diente zur Priorisierung der zu realisierenden Funktionen.
„Es war hilfreich, den Gesamtprozess in viele kleine Teile, in Form von User Stories, zu zerlegen. So konnte man sich bei den Prozessen, die man tagtäglich ganz selbstverständlich durchführt auf die einzelnen Schritte fokussieren.“ Endanwenderin Frau Nagel
„Ursprünglich war eine andere Lösungsidee da und gemeinsam wurde durch die strukturierte Anforderungsanalyse ein neues, viel passenderes Zielbild entwickelt. Das Vorgehen hat uns zu dem geführt, was wir wirklich brauchen.“ Endanwender Herr Kienecker
„Da frühzeitig in der Vorstudie ein gemeinsames Bild entstanden ist, konnte der Aufwand für das Umsetzungsprojekt realistisch eingeschätzt werden.“ Endanwender Herr Geister
Gemeinsam mit Endanwender:innen wird in der Feinkonzeption das Expertenwissen in ein gutes Anwendungsdesign übersetzt
Mit dem Beginn des Umsetzungsprojekts fand die Feinkonzeption mit den Endanwender:innen der LBS-Gruppe als künftige Nutzer:innen und den SR-Projektleitern statt. Entwickelt wurden das Oberflächendesign, die Benutzerführung und die Business Rules im Sinne von Validierungen und Statusübergängen, sowie von nicht funktionalen Anforderungen und hierzu erforderlichen Architekturentscheidungen. Zur Erarbeitung wurden 17 gemeinsame Workshops mit künftigen Nutzern, SR-Projektleitern, einer Business Analystin und einem Softwarearchitekten durchgeführt, sodass der Nutzen, die Machbarkeit, der Kostenaufwand sowie die Konsistenz der einzelnen Funktionen direkt im Workshop bewertet werden konnten. Zur besseren Planbarkeit der gezielten Einbindung von Expert:innen wurden alle Workshop-Termine zu Beginn direkt mit konkretem Themenbezug vereinbart. Zusätzlich wurden zu jedem Thema Puffertermine vorgesehen, sodass sichergestellt war, dass alle offenen Punkte direkt in der gleichen Woche abschließend besprochen werden konnten.
„In der Feinkonzeption ist klar geworden, dass einige selbstverständlich genutzten Begriffe zwischen den Nutzern mehrdeutig verwendet werden. Die gemeinsame Erarbeitung von trennscharfen Definitionen erhöhte das gemeinsame Verständnis und bildete damit eine gute Grundlage für das Design der neuen Anwendung.“ Projektleiter Herr Chevalier
„viadee hat uns gut an die Hand genommen, um uns klar zu werden, wer welche Rolle einnimmt und wie der künftige Workflow laufen könnte“ Endanwenderin Frau Nagel
„Die Workshops waren effizient virtuell organisiert. Die Puffertermine waren sehr nützlich, damit nichts liegen bleibt.“ Projektleiter Herr Chevalier
„Durch das Statusmodell war mir auf einmal klar, wie wir mit dem System arbeiten werden.“ Endanwender Herr Geister
Wireframes veranschaulichen skizzenhaft konkrete Ideen
In den Workshops bildeten Vorschläge für Benutzeroberflächen in Form von klickbaren Wireframes die Grundlage für ein gemeinsames Verständnis zu diskutierten Varianten. Sie wurden direkt im Workshop angepasst und boten eine frühe User Experience. Im Projekt wurden bewusst Lowfidelity Wireframes eingesetzt, erstellt mit Balsamiq, die eine Benutzeroberfläche nur schematisch in Form einer Bleistiftskizze darstellen. Sie zeigte die einzelnen Elemente mit Beschriftung, konkrete Icons, Defaultwerte und Auswahloptionen, stellt Pflichteingaben sowie das Anwendungsverhalten und die Benutzerführung dar, nicht jedoch das konkrete Design. So erfolgt visuell eine klare Unterscheidung zwischen Konzeption und der tatsächlich programmierten Benutzeroberfläche. Die Wireflows wurden als PDF nach jedem Workshop den Teilnehmer:innen ins Review gegeben. In dem generierten PDF wurden die einzelnen Oberflächen untereinander über die Interaktionselemente verlinkt, sodass der Eindruck entsteht, sich durch eine skizzierte Anwendung zu klicken und die Benutzerführung erlebbar wird.
„Bauen und Umbauen der Oberfläche vor den Augen der Anwender:innen war sehr hilfreich.“ Endanwenderin Frau Nagel
„Die Wireflows haben den Verlauf hervorragend dargestellt. Es war direkt erlebbar, wo mich ein Dialog hinführt und welche Informationen angezeigt werden.“ Projektleiter Herr Schickling
„Durch das Durchklicken in den Wireframes konnte ich eine bessere Vorstellung von der neuen Anwendung bekommen und mich leichter von Althergebrachtem lösen.“ Projektleiter Herr Chevalier
Auftraggeber formuliert die Akzeptanzkriterien
Zusätzlich zu den Wireframes wurden textuell 85 User Stories beschrieben, welche die Beschreibung der Vorbedingungen und das Verhalten beinhalten, das ein Akteur entsprechend des Rechte- und Rollenkonzepts ausführen kann. Zu jeder User Story formulierte der Auftraggeber die Akzeptanzkriterien bzgl. Verhalten und Fehlerbehandlungsroutinen. Die insgesamt 228 Akzeptanzkriterien dienten im Projekt als Basis für die anforderungsbezogenen Entwicklertests der Software. Sie wurden in manuellen und automatisierten Testfällen genutzt, um sicherzustellen, dass keine Lücken und Abweichungen zwischen den Anforderungen und der Realisierung der Anforderungen zu erkennen sind. Darüber hinaus ermöglichte die Orientierung an Akzeptanzkriterien einen zielgerichteten und optimierten Einsatz vorhandener Testressourcen. Die Testfallermittlung auf Basis der Akzeptanzkriterien brachte eine hohe Transparenz über die Testergebnisse und die Testabdeckung schon im Rahmen des Entwicklertests mit sich.
„Die Formulierung der Akzeptanzkriterien war für mich eine intensive Auseinandersetzung mit der Konzeption und hat zu einer weiteren Schärfung beigetragen.“ Projektleiter Herr Schickling
"Durch die Formulierungen der Akzeptanzkriterien konnte ich sicherstellen, dass wir ein gemeinsames Verständnis hatten. Die Aspekte, welche dem Auftraggeber bei der Anwendung wichtig waren, wurden klar benannt. " Business Analystin Frau Filius
"Das hervorragende Fachkonzept, bestehend aus User Stories und Akzeptanzkriterien, hat es ermöglicht, gut strukturierte Testfälle für die Entwicklung von automatisierten Softwaretests abzuleiten." Test Analyst und Automation Herr Engelking
Entwicklerteam gestaltet die Oberflächen innerhalb der Vorgaben
Die Umsetzung erfolgte inkrementell in Entwicklungszyklen. Bei der Gestaltung der Anwendung wurde das Corporate Design der LBS-Gruppe mit den Material-Design-Leitlinien verbunden. Gemeinsam mit den nicht funktionalen Anforderungen waren damit Layout, Farben, Typografie und Icons, sowie Formen und Animation der einzelnen Elemente vorgegeben. Anwendungsübergreifend wurde definiert, wie die Navigation in der Anwendung erfolgt, in welchen Fällen und auf welche Weise Fehler, Warnungen und Informationen dargestellt werden und welche Aktionen eine Bestätigung durch die Benutzer:innen erfordern. So waren die Interaktion und Kommunikation der Anwendung mit den Nutzer:innen einheitlich. Das Entwicklungsteam gestaltete die konkrete Benutzeroberfläche innerhalb dieser Vorgaben anhand der in den User Stories beschriebenen Elemente selbst. Die Anwendung ist responsive, d. h. ihre Darstellung und Funktionsweise passt sich an die Gegebenheiten (z. B. Auflösung, Eingabe via Maus oder Touchscreen, …) des Endgeräts des Endanwenders an.
”Bei der Entwicklung der Oberflächen habe ich die Freiheit geschätzt, die Dialoge innerhalb der Vorgaben selbst gestalten zu können.” Entwickler Herr Moog
„Beim Oberflächendesign spürt man die Expertise der Entwickler. Man kann sich voll auf die fachlichen Inhalte konzentrieren, weil die Nutzerführung so intuitiv ist.“ Projektleiter Herr Schickling
„Die Erfahrungen aus ersten Entwicklungszyklen sind in die Konzeption und Entwicklung der nächsten Schritte eingeflossen.“ Softwarearchitekt Herr Staab
Business Analystin testet die Anwendung
In jedem Entwicklungszyklus fanden intensive Modultests und Benutzeroberflächen-Tests der umgesetzten User Stories statt. Dem Grundsatz der Funktionstrennung folgend, wurden die Tests auf Oberflächen-Ebene von der Business Analystin sowie von projektunabhängigen Expert:innen für den Test von Web-Entwicklungen durchgeführt. Jedes Akzeptanzkriterium wurde manuell getestet. Darüber hinaus wurden intuitive und explorative Tests durchgeführt. Die Tests der Business Analystin stellten sicher, dass die Erkenntnisse der Workshops in den Softwaretest einfließen, wodurch die Wahrscheinlichkeit erhöht wurde, dass die Software den Bedürfnissen der Stakeholder entspricht. Das Audit durch die Expert:innen überprüfte zusätzlich mögliche Nutzereingaben, Datenkonstellationen und Grenzfälle, sodass das Projekt von dem großen Erfahrungsschatz von Fehlerzuständen in Web-Anwendungen - beispielsweise bezüglich Security - profitieren konnte.
"Bei den Tests habe ich mich in die einzelnen Endanwender:innen hineinversetzt. In den Workshops zuvor wurde deutlich, wie individuell die angestrebte Nutzung der einzelnen Funktionen war." Business Analystin Frau Filius
„Die Oberflächen sind intuitiv und dadurch sehr schnell nutzbar. Neue Kolleg:innen hatten schnell ein Verständnis dafür, was an welcher Stelle zu finden ist und was zu tun ist.“ Endanwenderin Frau Nagel
Regelmäßige Feedbackschleifen geben dem Kunden Sicherheit
Durch die inkrementelle Entwicklung entstanden in regelmäßigen Abständen während des Arbeitsprozesses fertige Zwischenergebnisse, welche den künftigen Nutzern in Feedbackschleifen bereitgestellt wurden. Die Nutzer:innen hatte damit die Möglichkeit frühzeitig Änderungswünsche zu Artefakten zu kommunizieren und sich regelmäßig über den Projektfortschritt zu informieren. So konnten die Nutzer:innen ihre individuellen Workflows durchspielen und das Zusammenspiel der Komponenten sowie die Usability überprüfen. Durch die Feedbackschleifen bestand maximale Transparenz bezüglich Aussehen und Bedienung des Systems, Qualität der Software und Fortschritt im Projekt, sodass die SR-Projektleitung eine Kostentransparenz und eine Steuerungsmöglichkeit über die Priorisierung der nächsten Schritte besaß. Die Rückmeldungen im Laufe des Entwicklungszeitraums gaben die Sicherheit, dass sich das Projekt auf einem guten Weg befindet.
„Aus Projektleitersicht haben die Feedbackschleifen großes Vertrauen geschaffen. Der Projektfortschritt war keine abstrakte prozentuelle Zahl, sondern ein Produkt, das man sich konkret anschauen konnte.“ Projektleiter Herr Schickling
"Es war toll, dass wir das Feedback von den Endanwender:innen während der Entwicklung bekamen. So konnten wir von der Nutzung der Software in konkreten Anwendungsszenarien lernen." Business Analystin Frau Filius
Automatisierte Tests verschlanken die Regressionstests
In inkrementellen und iterativen Entwicklungsvorgehen wie in diesem Projekt, in denen Code-Änderungen stetig erfolgen, spielen automatisierte Komponentenregressionstests eine Schlüsselrolle und stellten daher von vorneherein auch eine sehr wesentliche Anforderung dar. Nach jeder Feedbackschleife wurden die Akzeptanzkriterien der umgesetzten User Stories in automatisierte Tests überführt. Als Testwerkzeug zur Automatisierung wurde mateo eingesetzt. Die automatisierten Tests schafften das Vertrauen, dass Änderungen bestehende Komponenten nicht beschädigt haben, sodass sich manuelle Tests auf neue Funktionalitäten fokussieren konnten und Regressionstests enorm verschlankt wurden. Am Ende des Projekts konnten 94 Prozent der Akzeptanzkriterien in automatisierte Tests überführt werden und so eine stabile Basis für Weiterentwicklungen gelegt werden.
„Es war spürbar, wie intensiv die Software bereits vor dem Abnahmetest geprüft wurde und beeindruckend, wie wenig Fehler später noch im Abnahmetest gefunden wurden.“ Projektleiter Herr Schickling
"Mit der Testautomatisierungs-Software mateo konnte die Anwendung sehr schnell und zuverlässig gesteuert werden, sodass automatisierte Akzeptanztests nach jedem Build die Qualität der Software sicherstellen konnten." Test Analyst und Automation Herr Engelking
zurück zur Blogübersicht