Mathematische Rechenkerntests: Testumfang und -qualität mittels geeigneter Tools und Automatisierung maximieren

Artikel von Dr. Björn Medeke , Principal & Geschäftsführer Cominia Aktuarielle Services GmbH, und Tobias Wessels, Head of Software Development

Die wichtigste Grundvoraussetzung für den erfolgreichen Systemtest ist ein Referenzrechenkern, in den man schnell und effizient, aber auch mit hoher Qualität die zu testenden Tarife einstellen kann. Wir bei Cominia haben einen solchen Referenzrechner entwickelt und produktiv bei unseren Kunden im Einsatz, der sich durch eine ausgeklügelte Rechenkernarchitektur auszeichnet. Diese versetzt uns und unsere Kunden in die Lage, neue Tarifgruppen inklusive des notwendigen Customizings in kürzester Zeit umzusetzen. Zur Sicherstellung der Qualität sowie zum dauerhaften Abgleich gegen das produktive System haben wir Tools entwickelt, mit deren Hilfe ein automatisierter Test anhand eines umfangreichen, produktiven Testbestands in regelmäßigen Abständen möglich ist.

Beim Aufbau des Rechenkerns und im Rahmen des Customizings für unsere Kunden haben sich einige Stärken unseres Rechenkerns herauskristallisiert, die durch die folgenden Punkte gut zusammengefasst werden können und unseren Erfahrungsschatz in der Rechenkernentwicklung widerspiegeln:

1. Eine konsequente Trennung von technischer und fachlicher Rechenkernarchitektur ermöglicht es auch Aktuaren ohne umfangreiche Programmierkenntnisse, schnell neue Tarife in den Referenzrechner einzubauen und erhöht somit die Entwicklungsgeschwindigkeit.
2. Eine fachliche Beschreibung der Datenmodelle in einer Meta-Programmiersprache vereinfacht die Weiterentwicklung und kann als Basis für die Generierung der notwendigen Codebasis (Datenklassen, Schnittstellen zu Randsystemen, Datenhaltung) verwendet werden. 
3. Eine modulare Modellierung der Produktdaten, die dem Zielsystem möglichst nahekommt, aber zugleich Freiheitsgrade bezüglich der konkreten Tarif-Schlüsselung lässt, ermöglicht eine zeitnahe und unabhängige Implementierung der Tarife.
4. Ein hoher Automatisierungsgrad und Schnittstellen zum Produktivsystem erhöhen die Akzeptanz im Team und sind essenziell für Massentests.

Auch wenn diese Feststellungen vermutlich auf viel Resonanz stoßen werden, scheitert es leider oft an der konkreten Umsetzung, sodass die Rechenkernentwicklung mit zunehmendem Tarif- und Funktionsumfang unnötig kompliziert wird und somit nur von Experten übernommen werden kann. Dies führt zu Zeitverzögerungen und Kostensteigerungen und bedroht letztlich den Projekterfolg.  Es lohnt sich also, diese Punkte sowie die von uns entwickelten Ansätze im Folgenden noch einmal genauer zu betrachten.

Aufbau einer nachhaltigen Rechenkernarchitektur

Beim Aufbau unserer Rechenkernarchitektur haben wir durchgängig auf eine strikte Trennung von Fachlichkeit und Technik geachtet. Dies betrifft einerseits die Implementierung neuer mathematischer Rechenwerke und die Abläufe innerhalb eines Bearbeitungsschritts, welche möglichst ohne tiefgreifendes Wissen über die technischen Abläufe, wie zum Beispiel Caching oder Logging, aber auch die Interpolation von Werten zwischen zwei Stichtagen oder Iterationen innerhalb eines Vorgangs, möglich ist. Andererseits haben wir Frameworks verwendet oder implementiert, welche die Erweiterung der bestehenden Rechenkernarchitektur erleichtert, wie zum Beispiel die Modellierung der benötigten Datenstrukturen. Oft geht hiermit die Anpassung von Schnittstellen zu Randsystemen einher. Wir haben jedoch unsere Frameworks direkt daraufhin konzipiert, dass solche technischen Anpassungen von den fachlichen Entwicklern nicht notwendig sind oder zumindest automatisch generiert werden.

Abbildung 1 zeigt eine Barwertklasse unseres Referenzrechenkerns. Auch wenn diese Klasse nicht frei von technischen Details ist, ist sie trotzdem für jeden Aktuar – egal ob mit oder ohne Programmierkenntnisse – leicht verständlich und könnte ohne Probleme abgeändert oder zur Implementierung eines neuen Barwerts kopiert werden.

Abb. 1

Abbildung 2 zeigt eine Klasse zur Modellierung unseres Produktdatenmodells. Hierfür haben wir in unserem Rechenkern eine eigene Meta-Programmiersprache zur Beschreibung der Datenfelder und Relationen zwischen verschiedenen Komponenten des Datenmodells entwickelt. Dadurch ist es ebenfalls für nicht technik-affine Aktuare möglich, dieses Datenmodell zu erweitern. Zudem kann unser Framework die Informationen zur Generierung der Datenbankschnittstelle und der notwendigen Datenklassen verwenden, sodass vom Fachentwickler keine weiteren Anpassungen notwendig sind.

Abb. 2

Unabhängige Entwicklung eines Produktdatenmodells

Bei der Entwicklung unseres Produktdatenmodells haben wir verschiedene Aspekte berücksichtigt, die Einfluss auf die Umsetzbarkeit der Tariflandschaft im Referenzrechenkern haben und uns nun alle Möglichkeiten bieten, flexibel und ohne große Aufwände notwendige Erweiterungen für neue Kunden umzusetzen.

Erstens ist es uns möglich, sehr einfach und effizient neue Tarife in den Rechenkern einzubauen. Hierfür ist es neben den Anpassungen am Programmcode notwendig, die Tarifparameter und das Tarifregelwerk in einem Produktdatenmodell zu erfassen. Da sich unterschiedliche Tarife derselben Tarifgruppe jedoch häufig nur in wenigen Merkmalen unterscheiden, haben wir uns für die Umsetzung des Produktdatenmodells nach dem Baukastenprinzip entschieden: ein Tarif besteht bei uns im Rechenkern zum Beispiel unter anderem aus den Bausteinen „Ratenzuschlagssystem“, „Regeln für den vorgezogenen Ablauf“, „Kostenparameter“ und „Tarifbaustein“, wobei auf Tarifbausteinebene das Tarifregelwerk für unterschiedliche Zustände und Vertragsbestandteile eines Vertrags abgelegt ist. So können wir große Teile der vorhandenen Einstellungen wiederverwenden, um neue Tarife abzubilden.

Zweitens gibt es in unserem Produktdatenmodell vielfach die Möglichkeit, durch geeignete Vertragsschlüssel unterschiedliche Tarifvarianten – zum Beispiel unterschiedliche Rabattierungen – abzubilden. So können wir problemlos mehrere Tarifvarianten oder Alttarife zu einem Tarif zusammenfassen, falls dies im Produktivsystem so gewünscht ist. 

Drittens haben wir zudem darauf geachtet, uns bei der Schlüsselung der Tarife, d.h. der Benennung der Tarifvarianten und der Einteilung der Produktdaten in unterschiedliche Module, nicht zu sehr vom produktiven System abhängig zu machen. Eine häufige Forderung der IT-Dienstleister des produktiven Systems ist es, dass Referenzwerte frühzeitig und bestenfalls vor Beginn der Umsetzungen im produktiven System bereitgestellt werden. Daher ist es oft notwendig und in unserem Referenzrechenkern leicht möglich, Umsetzungen im Referenzrechenkern zu starten, bevor die endgültigen Tarifschlüssel im Zielsystem bekannt sind. Fehlende Informationen können dann einfach und aufwandsarm zu einem späteren Zeitpunkt ergänzt werden.

Schließlich haben wir, wie schon bei der Rechenkernarchitektur, auch bei der Entwicklung des Produktdatenmodells darauf geachtet, dass die Pflege und Weiterentwicklung des Datenmodells von Fachentwicklern durchgeführt werden kann. Unterstützt werden sie dabei durch eine geeignete Auswahl von Tools und Technologien, die unserer Erfahrung nach von den Aktuaren in unseren bisherigen Projekten sehr gut angenommen wurden.

Einsatz und Akzeptanz des Referenzrechenkerns im Projekt

Für den Erfolg eines Referenzrechners ist es essenziell, dass er im Projekt auf eine breite Akzeptanz stößt. Wenn die Erwartungshaltung an den Referenzrechenkern nicht zwischen allen beteiligten Projektteilnehmern abgestimmt wurde oder wenn die Anforderungen der Nutzer nicht hinreichend analysiert und berücksichtigt wurden, entsteht Frust, der letztlich dazu führt, dass der Referenzrechner im Test nicht ausreichend eingesetzt wird. Oft kommt es dann vor, dass für einzelne Tests die Werte wieder händisch nachgerechnet werden. Dadurch kann der Referenzrechner sein Potential nicht voll entfalten und die Investitionen in den Referenzrechner verpuffen.

Im Einsatz unseres Referenzrechners bei Kunden haben wir zum Beispiel festgestellt, dass die manuelle Eingabe von Testfällen über ein Benutzerinterface sowie die anschließende Bewertung der Ergebnisse anhand der Excel-Ausgabe eine große Hürde für die Anwender darstellt. Selbst die Möglichkeit, Testfälle aus dem Produktivsystem einzulesen und berechnen zu lassen, hat nur teilweise zu einer Verbesserung der Situation geführt.

Wir sind dann konsequent den Schritt gegangen und haben sowohl die Berechnung der Testfälle als auch die Verarbeitung der berechneten Ergebnisse vollautomatisiert. Heute müssen lediglich noch die Testfälle durch die Tester definiert und Traces aus dem produktiven System bereitgestellt werden. Diese Traces dienen unserem Referenzrechner dann als Testbestand und werden automatisch in regelmäßigen Abständen berechnet. Der Abgleich der berechneten Ergebnisse mit den produktiven Werten sowie eine übersichtliche Darstellung der Abweichungen erfolgt ebenfalls automatisch, sodass sich die Tester darauf konzentrieren können, diese Abweichungen zu analysieren, ohne sich mit der Bedienung des Referenzrechners auseinandersetzen zu müssen.

Aufgrund des hohen Automatisierungsgrades ist es kein Problem, diese Testfälle beliebig oft zu wiederholen. Es ist also möglich, die bereits erfolgreichen Testfälle weiterhin mit neuen Abzügen der produktiven Traces durchlaufen lassen und so einen großen Testbestand an produktiven Testfällen aufzubauen. Dadurch wird nicht nur sichergestellt, dass sich weder die Werte im produktiven System noch die Referenzwerte ungewollt ändern, sondern wir haben gleichzeitig ein Tool entwickelt, das bei notwendigen Änderungen im Produktivsystem einen großen Vorrat an Testfällen bereitstellt und nach erfolgter beiderseitiger Anpassung aufwandsarm im Test eingesetzt werden kann.

Schlussfolgerungen für eine effiziente Referenzrechenkernentwicklung

Die Entwicklung eines Referenzrechenkerns und die Einbindung in einen bestehenden Testprozess ist komplex und bindet in der Regel viele Kapazitäten. Durch eine durchdachte Rechenkernarchitektur haben wir es geschafft, die Komplexität insgesamt stark zu verringern und soweit zu separieren, dass die Entwicklung auf mehrere, stärker spezialisierte Fachkräfte aufgeteilt werden kann. Dies ermöglicht es uns und unseren Kunden, das Customizing für neue Bestände schnell und effizient vorzunehmen und in kürzester Zeit mit einem ausgereiften und hochautomatisierten Tool in den Systemtest zu starten.

Factsheet