VZ Altersvorsorgerechner - Studienarbeit Herbstsemester 2018 Marcel Keller Quoc Tin Tran - Institutional Repository
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Studienarbeit
VZ Altersvorsorgerechner
Herbstsemester 2018
Autoren
Marcel Keller
Quoc Tin Tran
Betreuer
Manuel Bauer
Projektpartner
VZ Holding AG, Zürich
HSR Hochschule für Technik Rapperswil
Abteilung Informatik
CH-8640 Rapperswil, Schweiz
Abstract
Die VZ VermögensZentrum GmbH, Deutschland, berät Kunden zu Themen wie Ver-
mögensverwaltung und Private Vorsorge. Im Bereich der Ruhestandsplanung ist die
Nachfrage sehr mager, obwohl diese für junge Menschen immer wichtiger wird. Um ihnen
ihre Situation im Alter und mögliche Verbesserungsvorschläge aufzuzeigen, soll im Rah-
men der Studienarbeit ein Rechner für die Altersvorsorge erstellt werden. Dieser soll dem
interessierten Benutzer seine Lücke im Ruhestand aufzeigen und seine Vorsorgeplanung
in einfachen Schritten ermöglichen.
Zu Beginn der Studienarbeit musste die Rentensituation in Deutschland analysiert und die
genauen Anforderungen des Projektpartners geklärt werden. Aus der Anforderungsanalyse
ging heraus, dass das System aus zwei Teilen besteht: einem User-Interface und einem
Backend. Als erster Schritt der Umsetzung wurde die Architektur aus Komponenten- &
Systemsicht ausgearbeitet. Als User-Interface wurde eine Webanwendung mit Angular
ausgewählt. Die Berechnungslogik sollte in einem Web API mit ASP.NET Core umgesetzt
werden. Die ausgearbeiteten Anforderungen wurden dann im Verlauf der Studienarbeit
mit einem agilen Ansatz umgesetzt, wobei der Kontakt mit dem VermögensZentrum für
kontinuierliches Feedback stets aufrecht erhalten wurde.
Entstanden ist ein dreiteiliger Vorsorgerechner. Im ersten Teil kann der Benutzer mit
einfachen Werten seine Rentenlücke berechnen. Für detailliertere Informationen zu dieser
Lücke können im zweiten Bereich der Plattform die Einnahmen, Ausgaben und Renten
erfasst werden. Präsentiert wird dem Benutzer auch hier nur ein Abbild der Situation
zu seinem Ruhestand. Damit der Verlauf des Ruhestandes und die Zeit bis dahin auf-
zeigt und genauer analysiert werden kann, werden im Ruhestandsfahrplan mithilfe von
Vermögenswerten und Ereignissen auf einer Zeitachse die Akkumulation- & Dekumula-
tionsphase des Kapitals dargestellt. Darin ist zu erkennen, wie viel Vermögen auf den
Ruhestandszeitpunkt in monatlichen Raten anzusparen ist.
i
Management Summary
Ausgangslage
Das VZ VermögensZentrum existiert in der Schweiz bereits seit über 25 Jahren und
hat sich in diesem Zeitraum einen Namen als unabhängiger Finanzdienstleister gemacht.
Doch auch in Bereichen wie Steuerberatung, Nachlass oder Pensionierungsberatung
bietet das VermögensZentrum in der Schweiz viele Dienstleistungen an. Seit einigen
Jahren betreibt das VZ in Deutschland eine Tochtergesellschaft, bis anhin mit Fokus
auf die Vermögensverwaltung. Nun möchte das VZ auch in Deutschland bei dem Thema
Pensionierungsplanung Fuss fassen und möglichst viele, besonders auch junge Personen,
ansprechen und diese als Kunden gewinnen. Das Thema Pensionierung und Vorsorgelücke
ist überwiegend in Deutschland brisant, da die staatliche und betriebliche Vorsorge
den Bedarf im Ruhestand nicht annähernd so gut deckt wie in der Schweiz. Um diese
Problem den potenziellen Kunden aufzuzeigen, soll eine Prototyp für eine Anwendung
erstellt werden, welche dem Kunden ermöglicht, seine Vorsorgelücke zu berechnen und
seine Pensionierung in groben Zügen zu planen. Dieser Prozess endet aus Sicht des
VZ idealerweise in einem Beratungs- und Umsetzungsmandat, in welchem der Kunde
langfristig an die Angebote des VermögensZentrums gebunden werden kann.
Vorgehen und Technologien
Als Vorgehensweise wurde eine Mischung zwischen iterativ und Wasserfall gewählt.
Die gesamte Projektdauer wurde dabei in 4 Phasen unterteilt: Inception, Elaboration,
Construction und Transition. Während den einzelnen Phasen wurde in zweiwöchigen
Iterationen gearbeitet. Der Projektplan wurde in der ersten Phase erstellt. In der Phase
Elaboration ging es darum, die Anforderungen aufzunehmen, mit dem VZ abzusprechen
und aufgrund diesen die Architektur der zu erstellenden Lösung zu planen. Gemeinsam
mit dem VZ wurde entschieden, dass die zu entwickelnde Anwendung aus zwei Teilen
besteht. Als Schnittstelle zum Benutzer sollte eine Webanwendung erstellt werden, da
diese ohne grosse weitere Installation bedient werden kann und dem aktuellen Trend
in Richtung Web folgt. Um jedoch in Zukunft auch weitere Schnittstellen anbieten zu
können, soll die Berechnungslogik in einen zweiten Teil, einem Web API, ausgelagert
werden. Zum Schluss dieser Phase wurde ein technischer Prototyp erstellt, um die
Machbarkeit dieser Entschlüsse zu testen. Während der Construction-Phase entstand so
in mehreren Iterationen der Prototyp der Anwendung. In der letzen Phase Transition
wurden Dokumente für die Abgabe der Projektarbeit und die Übergabe des Prototypes
an das VZ erstellt.
ii
Ergebnisse
Der erstellte Prototyp wurde in drei Teile gegliedert. Die Idee dahinter ist es, dem
Kunden anfangs ohne persönliche Daten erste Zahlen zu liefern und ihn nicht bereits
am Anfang zu verlieren, weil er sich anmelden muss. In diesem ersten Schritt kann er
unter einfachen Angaben wie Alter und Einkommen seine Rentenlücke, also die Differenz
zwischen der gesetzliche Rente und der Ausgaben im Ruhestand, berechnen. Nach einer
Registration mit Benutzernamen und Passwort kann der Kunde seine Vorsorgelücke unter
Berücksichtigung von erfassten Einnahmen, Ausgaben und Renten berechnen. Im letzten
Teil, seinem Ruhestandsfahrplan, kann der Kunde weitere Parameter, wie gewünschtes
Ruhestandsalter oder die theoretische Lebenserwartung anpassen und zukünftige Geld-
flüsse erfassen. Dabei wird ihm bei der Rechnung des Verlaufes seines Vermögens immer
ein Produkt des VermögensZentrums vorgeschlagen. Die Idee ist, dass er dadurch Kunde
des VermögensZentrums wird.
iii
Inhaltsverzeichnis
I. Technischer Bericht 1
1. Einleitung und Übersicht 2
1.1. VZ Holding AG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Altersvorsorgerechner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Vorgehen und Technologien 4
2.1. Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Zeitliches Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.3. Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Ergebnisse 6
3.1. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Exception Handling Middleware . . . . . . . . . . . . . . . . . . . 7
3.2.2. Automatische Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Datenspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Konfigurationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.2. Kundendaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Dokumentation Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Mandantenfähigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Zeitauswertung 10
4.1. Aufteilung Stunden nach Teammitglied . . . . . . . . . . . . . . . . . . . . 10
4.2. Aufteilung Stunden nach Aktivität . . . . . . . . . . . . . . . . . . . . . . 11
5. Schlussfolgerung 12
5.1. Umgesetzte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Optionale Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Nicht umgesetzte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.5. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5.1. Frontend Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . 15
iv
Inhaltsverzeichnis
5.5.2. Einsatz in weiteren Ländern . . . . . . . . . . . . . . . . . . . . . . 15
5.5.3. Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
II. SW-Engineering Dokumente 16
1. Anforderungsspezifikation 17
1.1. Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2. Allgemeine Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.1. Produktfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.2. Benutzercharakteristik . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.3. Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.1. Use Case Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.2. Aktoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.3. Abläufe und Zusammenhänge . . . . . . . . . . . . . . . . . . . . . 19
1.3.4. UC01 - Rentenlücke berechnen . . . . . . . . . . . . . . . . . . . . 20
1.3.5. UC02a - Registration . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.6. UC02b - Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.7. UC03 - Persönliche Vorsorgelücke berechnen . . . . . . . . . . . . . 21
1.3.8. UC04a - Detailierte Registration . . . . . . . . . . . . . . . . . . . 22
1.3.9. UC04 - Ruhestandsfahrplan erstellen . . . . . . . . . . . . . . . . . 22
1.4. Weitere Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.4.1. Randbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2. Domainanalyse 24
2.1. Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.1. Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.2. Wichtige Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3. Architekturspezifikation 27
3.1. Systemübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1. Simulierte Kundendaten . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.3. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2. Architektonische Ziele & Einschränkungen . . . . . . . . . . . . . . . . . . 28
3.2.1. Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2. Einschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3. Logische Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.3. Schnittstellen Frontend / Backend . . . . . . . . . . . . . . . . . . 35
3.4. Implementierte Patterns - Backend . . . . . . . . . . . . . . . . . . . . . . 36
3.4.1. Builder Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
vInhaltsverzeichnis
3.4.2. Strategy Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.3. Data Transfer Object . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.4. Repository Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.1. Frontend/Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6. Datenspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.1. Entscheidung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.2. Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4. Installationsanleitung 41
4.1. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.2. Entwickler-PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2. Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3. Ausführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.1. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.2. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.3. json-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Literaturverzeichnis 45
Glossar 47
Abbildungsverzeichnis 49
Tabellenverzeichnis 50
viTeil I. Technischer Bericht
1. Einleitung und Übersicht
1.1. VZ Holding AG
Die VZ Gruppe ist ein Finanzdienstleistungskonzern mit mehr als 30 Einheiten in der
Schweiz und Deutschland. Die VZ Holding ist die kotierte Gesellschaft im Konsolidie-
rungskreis der Gruppe. Zu den nicht kotierten Tochtergesellschaften der Holding gehören
u.a. Banken, Vermögensverwalter, eine Versicherung. Bekannt ist das VZ seit Jahren
für als erste Adresse für unabhängige Vermögensberatung. Jedes Jahr lassen sich mehre-
re tausend Kundinnen und Kunden zu Vorsorge- und weiteren Finanzthemen beraten
wie bspw. Pensionierung, Vorsorge, Finanzanlagen, Immobilienfinanzierung, Nachlass,
Versicherungen. Die wichtigste Zielgruppe des VZ sind Einzelpersonen und Paare ab
50 mit Wohneigentum. Die Kundenbetreuung findet on- und offline statt, wobei der
Onlinezugang das VZ Finanzportal ist.
1.2. Problemstellung
Privatpersonen vieler zentraleuropäischen Länder sind mit der Herausforderung einer
Rentenlücke im Alter konfrontiert. Eine Rentenlücke entsteht, wenn im Ruhestand die
Ausgaben mit den Einkünften nicht gedeckt werden können. Die vorherrschenden Vor-
sorgesysteme haben aber das Ziel, diese Lücke vollständig oder möglichst vollständig zu
decken. Die staatliche Rente übernimmt dabei eine zentrale Rolle, vermag jedoch meist
nicht alle Ausgaben zu decken. Die beruflich und speziell die private Vorsorge werden
immer wichtiger.
Beispielhaft ist Deutschland mit einem Drei-Säulen-System ähnlich wie in der Schweiz
ein Land, das mitten in dieser Herausforderung steckt. Die VZ Gruppe ist dort mit der
VZ VermögensZentrum GmbH, Deutschland, sowohl als Finanz- und Vermögensbera-
tungseinheit als auch als Bank präsent. In Deutschland ist die Nachfrage im Bereich der
Ruhestandsplanung sehr mager, obwohl diese auch für junge Menschen immer bedeutender
wird.
1.3. Altersvorsorgerechner
Die Relevanz und Herausforderung der Altersvorsorge soll neu dominanter und breiter
angesprochen werden. Dafür wird eine eigene Plattform entwickelt, auf welcher der poten-
zielle Kunde seine Rentenlücke berechnen und entsprechende Produkte für die Schliessung
dieser erwerben kann. Die geeigneten VZ Produkte sind ebenfalls in Entwicklung. Mit
21. Einleitung und Übersicht
der Plattform, dem Rechner und den Produkten könnten potenzielle Kunden neu bereits
während der Ansparphase angesprochen und so eine neue Kundengruppe bedient werden.
Um den Zielgruppen ihre Situation im Alter und mögliche Verbesserungsvorschläge
aufzuzeigen, soll im Rahmen der Studienarbeit ein Rechner für die Altersvorsorge erstellt
werden, welches in diese zukünftige Plattform eingegliedert werden soll. Dieser soll dem
interessierten Benutzer seine Lücke im Ruhestand und seine Vorsorgeplanung in einfachen
Schritten ermöglichen.
Der ganze Rechner soll aus drei Teilen bestehen, der je nach Funktionsteil einen anderen
Detaillierungsgrad der Angaben zur Altersvorsorge aufweisen soll (siehe Abbildung 1).
Im ersten Teil soll der Benutzer mit wenigen und einfach zu ermittelnden Angaben
wie Alter und Einkünfte die Rentenlücke bestehend aus der Differenz von staatlicher
Rente und Ausgaben berechnen können. Für detailliertere und weitere Informationen zu
dieser Lücke ist ein geschützter Bereich vorgesehen, wo mehr Angaben zu Einnahmen,
Ausgaben und weiteren Renten möglich sein soll. Damit der Verlauf einer Pensionierung
und die Zeit bis dahin aufzeigt und genauer analysiert werden kann, sollen ebenfalls in
diesem erweiterten geschützten Bereich mithilfe von Vermögenswerten und Ereignissen
von Geldzu- und abflüssen auf einer Zeitachse die Akkumulation- & Dekumulationsphase
des Kapitals dargestellt werden. Darin soll zu erkennen sein, wie viel Vermögen auf den
Ruhestandszeitpunkt in monatlichen Raten anzusparen ist, um die statistische Lebenser-
wartung ohne finanzielle Sorgen zu erreichen. Ein wichtiger Aspekt dieses Rechners soll
die Erweiterbarkeit und Mandantenfähigkeit sein, da beispielsweise Österreich ebenfalls
mit der Herausforderung der Altersvorsorge konfrontiert ist und man dort allenfalls Fuss
fassen möchte.
Abbildung 1.: Konzept
Quelle: Icons für Rentenlücke [4] und Ruhestandsfahrplan [6] von Freepik, Icon für
Vorsorgelücke [5] von itim2101, sonst eigene Darstellung
32. Vorgehen und Technologien
2.1. Vorgehensmodell
In der Studienarbeit wurde ein gemischtes Vorgehensmodell namens Scrum++ aus
Scrum und dem Unified Process gewählt. Durch den Zeitpunkt von “End of Elaboration”
im Unified Process wird ermöglicht, dass vor der eigentlichen Entwicklungsarbeit die
Anforderungen und die Architekturspezifikation stehen und der Industriepartner richtig
verstanden wurde. Damit man doch flexibel bleibt und auf Veränderungen schnell reagieren
kann, kommt Scrum mit seinem iterativen Ansatz während der gesamten Projektdauer
zum Einsatz.
2.2. Zeitliches Vorgehen
Für die Studienarbeit standen 14 Wochen mit je 17h pro Woche und Person zur Verfügung.
Scrum++ wurde mit zweiwöchigen Iterationen eingesetzt und Meilensteine wurden am
Ende einer Iteration angesetzt. Diese Meilensteine wurden zu Beginn des Projektes
definiert und steckten grob ab, was zu welchem Zeitpunkt abzuliefern ist. Der Projektplan
dient als Anlaufstelle für detailliertere Informationen.
Abbildung 2.: Übersicht zeitliches Vorgehen
Quelle: Eigene Darstellung
42. Vorgehen und Technologien
2.3. Technologien
Während des Projekts wurden verschiedene Technologien eingesetzt, die im Projektplan
beschrieben wurden. Nachfolgend befinden sich in den Abbildungen 3, 4 und 5 eine Liste
der effektiv eingesetzten Technologien in der Studienarbeit.
2.3.1. Frontend
Abbildung 3.: Technologien Frontend
Quelle: Eigene Darstellung
2.3.2. Backend
Abbildung 4.: Technologien Backend
Quelle: Eigene Darstellung
2.3.3. Infrastruktur
Abbildung 5.: Technologien Infrastruktur
Quelle: Eigene Darstellung
53. Ergebnisse
3.1. Frontend
Das User-Interface wurde als Webanwendung mit Angular 6 und TypeScript entwickelt.
In diesem kann der Benutzer folgende Tätigkeiten ausführen:
• Registration und Login
• Rentenlücke und Vorsorgelücke berechnen
• Ruhestandsfahrplan erstellen (Abbildung 6)
• Vermögenswerte erfassen und bearbeiten
Das Frontend dient hauptsächlich als Erfassungs- und Anzeigemaske. Die Kundendaten
werden von der Kundendaten-API geladen und dorthin gespeichert. Für die Berechnungen
der Rentenlücke und des Ruhestandsfahrplanes werden diese Daten weiter an unser
Backend geleitet und das Resultat dargestellt. Damit die Daten dem Kunden anschaulich
dargestellt werden können, werden diese in Form von Charts mit der Chart-Library
ngx-charts [12] dargestellt.
Abbildung 6.: Persönlicher Ruhestandsfahrplan
Quelle: Eigene Darstellung
63. Ergebnisse
3.2. Backend
Das Backend ist das Herzstück der neuen Anwendung. In diesem befindet sich die Logik
aller Berechnungen für die Rentenlücke, Vorsorgelücke und den Ruhestandsfahrplan. Dem
Frontend bietet das Backend ein Web API an, welches über HTTP angesprochen werden
kann. Daten werden im JSON-Format übertragen.
Das Backend wurde bewusst schlank gehalten und beinhaltet keinerlei Logik für die
Verwaltung der Kundendaten oder Vermögenswerte der Kunden. Diese werden dem
Backend als Input übergeben. So kann sich das Backend einfach in unterschiedlichste
Systemumgebungen einbinden, einzig die Schnittstelle zum Backend muss eingehalten
werden.
3.2.1. Exception Handling Middleware
Für das einfache Abfangen von unbehandelten Exceptions und Mappen in ein Resultat,
welches dem Client zurückgegeben werden kann, wurde eine Middleware für ASP.NET
Core erstellt. Dieser kann via Konfiguration pro Exception-Typ ein Mapping auf ein
Resultat und ein Status-Code definiert werden. Weitere Details zum Exception Handling
sind in der Architekturspezifikation unter dem Kapitel 3.3.1.2 Error Handling zu finden.
Abbildung 7.: Exception Handler Middleware - Code Snippet
Quelle: Eigene Darstellung
3.2.2. Automatische Tests
Unit Tests Einzelne Komponenten wie die Services auf dem Business Layer oder die
Repositories im Data Access Layer wurden mithilfe von Unit Tests mit dem Testframework
MS Test von Microsoft [21] getestet.
Integration Tests Der komplette Ablauf der Applikation von Controller bis Daten-
quelle wurde mithilfe von Integration Tests getestet. Dank der Erweiterung Micro-
soft.AspNetCore.Mvc.Testing von Microsoft [7] ist dies ohne grosses Aufsetzen von In-
frastruktur möglich. Diese Erweiterung abstrahiert einen Web-Server im Memory und
bietet einen HttpClient für Requests an. Da die Berechnungen der Lücke von Alter und
Datum abhängt wurde in den Integration Tests nur die Fehlerfälle getestet.
73. Ergebnisse
3.3. Datenspeicherung
3.3.1. Konfigurationen
Für die Berechnungen werden einige Para-
meter wie Inflation, durchschnittliches Ein-
kommen, erwartete Ausgaben im Ruhestand
in Prozent des Einkommens oder die statis-
tische Lebenserwartung benötigt. Da sich
diese Parameter mit der Zeit ändern kön-
nen, wurden diese konfigurierbar gemacht.
Bei diesem Parametern handelt es sich aber
nicht um komplexe, zusammenhängende Ob-
jekte sondern grundsätzlich nur Key-Value-
Paare. Als einfachste Lösung bot sich hier
die Konfiguration in einer JSON-Datei an.
Dies erleichtert auch die Integration in die Abbildung 8.: Parameter JSON-File
Infrastruktur des VZ.
Quelle: Eigene Darstellung
Ablösung durch Datenbank Das zukünftige Ablösen der JSON-Files als Datenquelle
wurde im Design des Backends berücksichtigt. Diese Datenquelle wurde mithilfe ei-
nes Data-Providers abstrahiert, welcher beispielsweise durch einen SQL-Data-Provider
ausgetauscht werden kann.
3.3.2. Kundendaten
Da sich das VZ während der Studienarbeit über das zukünftige Gesamtsystem, in welchem
sich der entwickelte Prototyp einfinden wird, nicht einig war, war auch nicht klar, wo die
Kundendaten und Vermögenswerte abgespeichert werden sollen. Klar war jedoch, dass
diese nicht Bestandteil des umzusetzenden Systems in der Studientarbeit sind. Gemäss
VZ war es aber als gegeben zu betrachten, dass die Kundendaten in Zukunft via einem
API über HTTP zugänglich sein werden. Um dies in unserer Studienarbeit simulieren zu
können, wurde des JSON-Server [9] verwendet. Dieser erstellt aufrund einer JSON-Datei
vollautomatisch ein RESTful Web API in wenigen Sekunden, inklusive Datenspeicherung
in einem JSON-File.
83. Ergebnisse
3.4. Dokumentation Schnittstelle
Für die Dokumentation der Schnittstelle des Backends wurde Swagger verwendet. Swag-
ger bietet eine einfache Möglichkeit, die Schnittstellendokumentation des Backends zu
betrachten und direkt im Browser zu testen. Angereichert wird die Dokumentation der
einzelnen Endpoints oder verwendeten Objektstrukturen über XML-Kommentare im
Code, welche hier ebenfalls ersichtlich sind.
Abbildung 9.: Auszug Swagger-Dokumentation
Quelle: Eigene Darstellung
3.5. Mandantenfähigkeit
Eine Anforderung an den Prototyp des Backends war die mögliche Erweiterung von
Mandanten, so dass die existierende Berechnungslogik ohne grossen Aufwand für weitere
Länder übernommen werden kann.
Backend Die Mandantenfähigkeit wurde in der Architektur des Backends berücksichtigt.
So wurden beispielsweise die Berechnungen der Renten und Konfiguration der Positionen
für die Berechnung des Ruhestandsfahrplanes in eigene, austauschbare Klassen abstrahiert.
Diese Klassen können entweder über verschiedene Mandanten verwendet oder pro Mandant
implementiert werden.
Frontend Das Frontend beinhaltet keine Business-Logik für die Berechnungen, darum
müsste im Falle eines weiteren Mandanten nur die Anzeige angepasst werden. Dabei
handelt es sich um Komponenten wie die Währung oder die Formatierung von Zahlen.
Weil im Vorhinein klar war, dass das Frontend nur als Prototyp verwendet und in
dieser Form nie Einzug in ein produktives System finden wird, wurde auf die einfache
Erweiterbarkeit für neue Mandanten verzichtet.
94. Zeitauswertung
Das Resultat der Studienarbeit wurde in ingesamt 429 Arbeitsstunden erreicht, was etwas
unter dem Soll von 480 Stunden liegt. Dies kommt von der grossen Erfahrung, die beide
Teammitglieder in dem Bereich der Infrastruktur und der Backend-Programmierung mit
in das Projekt gebracht haben. Im Rahmen des Engineering-Projektes an der HSR wurde
Projekt mit ähnlicher Struktur und Technologien umgesetzt, darum waren einige zu
erledigende Basisarbeiten bereits bekannt und konnten daher schneller umgesetzt werden.
4.1. Aufteilung Stunden nach Teammitglied
Die Aufteilung der Total Stunden von 429 auf die Teammitglieder beträgt ziemlich genau
50%/50%. Dem Zugrunde liegt, dass wir praktisch ausschliesslich an den gleichen Tagen
zusammen gearbeitet haben. Ebenso wurden gegenseitige Unterstützungen geboten, falls
ein Teammitglied bei einer Arbeit länger als gedacht hatte oder angestanden ist.
Abbildung 10.: Aufteilung Stunden nach Teammitglied
Quelle: Eigene Darstellung
104. Zeitauswertung
4.2. Aufteilung Stunden nach Aktivität
Die Aufteilung der Total Stunden nach Aktivität kommt wie erwartet mit einem grossen
Anteil von Entwicklung daher. Herausstechend ist, dass der Anteil der Infrastruktur sehr
klein ist. Dies lässt sich aber aufgrund des grossen Vorwissen von den verwendeten Tech-
nologien und eingesetzen Plattformen einfach nachvollziehen. Interessant, und sicherlich
etwas unterschätzt, ist der doch grosse Anteil von Meetings an der gesamtem Projektzeit.
Abbildung 11.: Aufteilung Stunden nach Aktivität
Quelle: Eigene Darstellung
115. Schlussfolgerung
In den 14 Wochen Studienarbeit wurde ein umfangreiches System entwickelt. Dank
dem eingespielten Projektteam, guter Projektplanung und stetigem Austausch mit dem
Projektpartner konnten alle zwingenden Anforderungen schneller als geplant umgesetzt
werden. In der so gewonnenen Zeit wurden auch einige optionale Anforderungen umgesetzt.
Diese wurden vor der Umsetzung durch den Projektpartner priorisiert oder ergänzt.
5.1. Umgesetzte Arbeiten
Während der Studienarbeit konnten alle zwingenden Features umgesetzt werden.
Rechner Rentenlücke Rentenlücke basierend auf einfache Angaben wie Nettoeinkom-
men, Alter und Geschlecht berechnen.
Rechner Vorsorgelücke Nach der Erfassung von eigenen Vermögenspositionen wie
Einkommen, Renten, Ausgaben und weiteren Vermögen die Vorsorgelücke berechnen.
Persönlicher Ruhestandsfahrplan Basierend auf den Vermögenspositionen aus dem
Rechner Vorsorgelücke einen zeitlichen Verlauf des Vermögenswertes und die monatliche
Sparquote aufzeigen.
Konfigurierbare Parameter Die für die Berechnung verwendeten Parameter wurden in
ein JSON-File ausgelagert und können ohne einen neuen Release angepasst werden.
125. Schlussfolgerung
5.2. Optionale Arbeiten
Zusätzlich zu den zwingenden Features konnten auch optionale Anforderungen umgesetzt
werden.
Erfassung von weiteren Soll/Haben Es können weitere Vermögenspositionen wie eine
Hypothek, Lebensversicherungen oder weitere Einnahmen erfasst werden. Diese fliessen
je nach Typ in die Berechnung mit ein oder dienen als informative Angabe.
Anpassung des Pensionierungsalters und der Lebenserwartung Der Benutzer kann
in der Berechnung des Ruhestandsfahrplanes seine persönlichen Angaben zum Pensio-
nierungsalter oder der statistischten Lebenserwartung tätigen und so beispielsweise eine
Frühpensionierung planen.
Planung von Ereignissen Im Rahmen des Ruhestandsfahrplanes können Ereignisse in
Form von Zu- und Abflüssen geplant werden.
Verschiedene Varianten des Ruhestandsfahrplanes Dem Benutzer werden im Ruhe-
standsfahrplan immer zwei Varianten berechnet: eine mit den Vorgaben des VZ und eine
mit seinen eigenen Anpassungen wie beispielsweise Ereignisse, eigene Ausgaben oder ein
angepasstes Pensionierungsalter.
5.3. Nicht umgesetzte Arbeiten
Web-UI auch auf mobilen Geräten aufrufbar Während der Aufnahme der Anforde-
rungen und der Konzeption eines Prototypen wurde klar, dass sich die technischen
Anforderungen und Vorstellungen des VZ mit der Anforderung an ein UI mit Ausrichtung
auf mobile Geräte beisst. Deshalb wurde gemeinsam entschieden, der Fokus des UI nicht
auf mobile Geräte zu setzen.
DSGVO Nach Absprache mit dem Projektpartner wurde die Nicht-Funktionale Anforde-
rung “in einfachen Zügen DSGVO-gerecht sein” nach hinten priorisiert, da die Umsetzung
dieser Anforderung nicht klar war und das UI nur als Prototyp entwickelt und nicht live
gehen wird.
135. Schlussfolgerung
5.4. Risikomanagement
Zu Beginn des Projektes wurde eine umfängliche Risikoanalyse durchgeführt und eine
Risikotabelle erstellt. Trotz einigen eingetretenen Risiken konnte dank den definier-
ten Massnahmen das Ausmass des Schadens gering gehalten und so alle Meilensteine
zeitgerecht erreicht werden. Nachfolgend wird auf die wichtigsten Risiken eingegangen.
Probleme mit Angular Dank der Investition von einigen Stunden in das Einarbeiten
und Ausprobieren von Angular in der Elaboration-Phase konnte die Entwicklung des
Frontends ohne grosse Probleme durchgeführt werden.
Problem mit Azure DevOps Gelegentlich war unsere DevOps-Umgebung, gehosted bei
Microsoft, nicht erreichbar. Durch häufiges Commits und Pushes von beiden Entwicklern
war der Code immer auf mindestens zwei Rechnern verfügbar. So konnte diese Zeit ohne
Probleme überbrückt werden.
Update von Software Auf einem Rechner wurde während der Projektphase ein Update
des Git-Clients durchgeführt. Diese Version war jedoch mit Azure DevOps inkompatibel,
deshalb konnte eine optimale Versionskontrolle des Codes nicht gewährleistet werden.
Mit einem Downgrade des Clients wurde dieses Problem behoben. In Zukunft sollten
Updates an kritischen Komponenten nicht mehr während der Projektphase, oder sonst
nur mit vorhergehender Evaluation, durchgeführt werden.
145. Schlussfolgerung
5.5. Ausblick
Mit dem Abschluss der Studienarbeit erhält der Projektpartner eine funktionsfähige
Webapplikation, welches in erster Linie als Proof of Concept dienen soll. Für das Projekt-
team ist mit der Übergabe die Entwicklung am VZ Altersvorsorgerechner beendet. Die
Ergebnisse unseres Projektes werden in einem grösseren Gesamtprojekt eingegliedert und
für weitere Evaluierungsschritte miteinbezogen.
5.5.1. Frontend Entwicklung
Im produktiven System soll das Frontend von einem externen Partner entwickelt werden,
der sich im Bereich User Experience und User Interaction Design spezialisiert hat.
Die Berechnungslogik im Backend soll zumindest in der aktuellen Form mit weiteren
Ergänzungen seitens VZ weiterverwendet werden.
5.5.2. Einsatz in weiteren Ländern
Das Backend mit der Berechnungslogik kann mit einigen Erweiterungen gut in weiteren
Ländern wie Österreich oder der Schweiz eingesetzt werden.
5.5.3. Erweiterungen
Durch das Konzept des Backends sind Erweiterungen ohne grösseren Aufwand möglich.
Beispielsweise stellt die Einführung von weiteren VZ-Produkten Erweiterungen dar, die
in der Architektur beachtet wurden.
15Teil II. SW-Engineering Dokumente
1. Anforderungsspezifikation
Dieser Abschnitt beschreibt die Anforderungen an das Projekt VZ Altersvorsorgerechner,
welches im Rahmen der Studienarbeit an der HSR umgesetzt wird.
1.1. Referenzen
Aufgabenstellung https://dev.azure.com/savzhsr/VZ%
20Altersvorsorgerechner/_git/VZ_
Altersvorsorgerechner?path=%2Fdocs%
2Faufgabenstellung%2F2018-07-05%
20Aufgabenstellung_VZ_Final.docx&version=
GBdevelop
Beschrieb Rechner https://dev.azure.com/savzhsr/VZ%
20Altersvorsorgerechner/_git/VZ_
Altersvorsorgerechner?path=%2Fdocs%
2Faufgabenstellung%2FVZ_Rechner_Beschrieb_V180918.
docx&version=GBdevelop
Projektplan https://dev.azure.com/savzhsr/VZ%
20Altersvorsorgerechner/_git/VZ_
Altersvorsorgerechner?path=%2Fdocs%2Fprojektplan%
2Fprojektplan-tex%2Fprojektplan.pdf&version=
GBdevelop
Tabelle 1.: Referenzen
1.2. Allgemeine Beschreibung
1.2.1. Produktfunktion
Die allgemein beschriebenen Produktfunktionen sind sowohl in der Aufgabenstellung als
auch im Projektplan zu finden. Die detaillierten Funktionalitäten sind im Kapitel 1.3 -
Use Cases erfasst.
1.2.2. Benutzercharakteristik
Der VZ Altersvorsorgerechner richtet sich an alle Privatpersonen, die sich mit ihrer
persönlichen Vorsorge auseinandersetzen wollen. Im Vordergrund steht die (private)
Vorsorge und deren Planung.
171. Anforderungsspezifikation
1.2.3. Abgrenzung
Es wird kein Login entwickelt, der den üblichen Standards entspricht, da dieses vermutlich
von einem externen Anbieter umgesetzt wird. Es wird auf alle komplexen Gamifications
verzichtet, diese müssen zu einem späteren Zeitpunkt realisiert werden. Es wird bei der
Umsetzung aber auf eine einfache Erweiterbarkeit geachtet, so dass diese Umsetzung
möglich ist.
1.3. Use Cases
1.3.1. Use Case Diagramm
Die roten gestrichelten Pfeile sind keine direkten Abhängigkeiten sondern stellen den
Ablauf dar.
Abbildung 12.: Use Case Diagramm
Quelle: Eigene Darstellung
181. Anforderungsspezifikation
1.3.2. Aktoren
Aktor Beschreibung
Potenzieller Kunde Ist im System nicht registriert oder nicht angemeldet
Kunde Ist im System registriert und angemeldet
Tabelle 2.: Aktoren
Quelle: Eigene Darstellung
1.3.3. Abläufe und Zusammenhänge
Dieser Abschnitt beschreibt die Zusammenhänge der einzelnen Use-Cases und die Abläufe,
welcher der Kunde durchschreitet um von seiner Rentenlücke zum Ruhestandsfahrplan
zu gelangen. Die Zahlen in klammern repräsentieren die Schritte im Use-Case Diagramm.
1. Als erstes berechne ich als potenzieller Kunde meine Rentenlücke. Diesen kann ich
ohne Registration oder Anmeldung durchführen.
2. Um mehr Funktionalität zu können, muss ich mich registrieren (1a) und danach
anmelden (1b). Nach der Registration werde ich von einem potenziellen Kunden zu
einem Kunden. Falls ich schon registriert bin kann ich mich direkt anmelden (1).
3. Nach der Anmeldung (2) meine Vorsorgelücke berechnen.
4. Möchte ich nach der Berechnung meiner Vorsorgelücke mehr erfahren, so muss ich
weitere persönliche Details im Schritt Detaillierte Registration erfassen (3).
5. Nach der Registration kann ich meinen Ruhestandsfahrplan berechnen (4).
191. Anforderungsspezifikation
1.3.4. UC01 - Rentenlücke berechnen
Als Kunde möchte ich unter Eingabe von Geschlecht, Alter und aktuellem Netto-
einkommen meine Rentenlücke berechnen. Dabei soll der Bedarf (Ausgaben) einem
prozentualen Anteil des letzten Nettoeinkommens vor dem Ruhestand entsprechen. Dieses
Nettoeinkommen soll automatisch berechnet werden, wobei besonders die Inflation
berücksichtigt werden soll. Als Ruhestandzeitpunkt soll der ordentliche Zeitpunkt
gelten. Die Rentenlücke setzt sich aus der Differenz zwischen Bedarf und staatlicher
Rente zusammen.
Details Die genaue Spezifikation vom VZ ist im “Beschrieb Rechner” im Kapitel
“Rechner „Rentenlücke“ (1)” zu finden.
Abbildung 13.: Screen Rechner Rentenlücke
Quelle: VermögensZentrum
1.3.5. UC02a - Registration
Um mich später im System anmelden zu können, registriere ich mich zuerst mit einem
Benutzernamen, meinem Geburtsdatum und einem Passwort.
1.3.6. UC02b - Login
Mit meinem Usernamen und Passwort möchte ich mich als Kunde anmelden, um auf
weitere Funktionalität zugreifen zu können.
201. Anforderungsspezifikation
1.3.7. UC03 - Persönliche Vorsorgelücke berechnen
Precondition Der Kunde ist im System angemeldet.
Als Kunde möchte ich unter Berücksichtigung sämtlicher Rentenleistungen resp. Vermö-
genswerte meine persönliche Vorsorgelücke berechnen.
1. Ich erfasse in einem ersten Schritt meine aktuellen Einkommen und meine voraus-
sichtlichen Rentenleistungen.
2. In einem nächsten Schritt kann ich meine Ausgaben erfassen oder diese vom System
berechnen lassen.
3. Im letzten Schritt kann ich meine aktuellen Vermögenswerte erfassen.
Die persönliche Vorsorgelücke setzt sich aus der Differenz zwischen Bedarf und Renten-
leistungen zum Pensionierungszeitpunkt zusammen. Dabei möchte ich im Detail sehen,
aus welchen Quellen sich meine Einnahmen und die Lücke zusamensetzt.
Details Die genaue Spezifikation vom VZ ist im “Beschrieb Rechner” im Kapitel
“Rechner „Persönliche Vorsorgelücke“ (2)” zu finden.
(a) Persönliche Vorsorgelücke (b) Ruhestands-Fahrplan
Abbildung 14.: Screens Rechner Persönliche Vorsorgelücke
Quelle: VermögensZentrum
211. Anforderungsspezifikation
1.3.8. UC04a - Detailierte Registration
Precondition Der Kunde hat die detailierte Registration noch nicht abgeschlossen.
Um meinen Ruhestandsfahrplan erstellen zu können, muss ich als Kunde zuerst mehr
persönliche Details angeben. Diese Details beinhalten Informationen zu meiner Person
und meinem aktuellen Wohnort.
1.3.9. UC04 - Ruhestandsfahrplan erstellen
Precondition Der Kunde ist im System angemeldet und hat die detailierte Registration
abgeschlossen.
Unter Berücksichtigung der in UC03 erfassten Einkommen, Ausgaben und Vermögens-
werte möchte ich mein benötigtes Vermögen zum Ruhestandszeitpunkt berechnen lassen.
Dieses soll aufgrund meiner Einnahmen und Ausgaben im Ruhestand und der statistischen
Lebenserwartung berechnet werden. Zudem soll mir aufgezeigt werden, wie viel ich pro
Monat bis zu meiner Pensionierung sparen muss, um das benötigte Vermögen ansparen
zu können.
Details Die genaue Spezifikation vom VZ ist im “Beschrieb Rechner” im Kapitel
“Darstellung „Ruhestands-Fahrplan“ (Rechner 3)” zu finden.
Abbildung 15.: Ruhestandsfahrplan
Quelle: VermögensZentrum
221. Anforderungsspezifikation
1.4. Weitere Anforderungen
Anforderung Erfüllt
(Ja/Nein)
Bedienbarkeit
Nach Aufruf der Seite muss der Benutzer nach 3 Angaben seine
Rentenlücke sehen.
5 Testpersonen vom VZ ohne Vorkentnisse der Applikation müssen
ihre Rentenlücke im Schnitt innerhalb von 10 Minuten berechnen
können.
Performance
Nach Angeben der Daten soll der Kunde innerhalb von 2 Sekunden
seine Rentenlücke sehen.
Nach Angeben der Daten soll der Kunde innerhalb von 4 Sekunden
seinen Ruhestandsfahrplan sehen.
Kompatibilität
Das UI muss mit Google Chrome in der Version 69.0.3497.100 oder
neuer kompatibel sein.
Tabelle 3.: Nicht-Funktionale Anforderungen
Quelle: Eigene Darstellung
1.4.1. Randbedingungen
1.4.1.1. Hosting
Das Frontend & Backend müssen in einem IIS mit der Version 10 als Site auf einem
Windows-Server 2016 R2 installierbar sein.
232. Domainanalyse
Dieser Abschnitt beschreibt die Analyse der Domain des Projektes VZ Altersvorsorge-
rechner, welches im Rahmen der Studienarbeit an der HSR umgesetzt wird.
2.1. Domain Model
Die Klassen im Domain Model beinhalten alle Eigenschaften.
2.1.1. Diagram
Abbildung 16.: Domain Model
Quelle: Eigene Darstellung
242. Domainanalyse
2.1.2. Wichtige Konzepte
2.1.2.1. Vermögen
Nebst dem VZ-Produkt gibt es verschiedene Vermögen, diese sind zur Übersichtlichkeit
nicht im Diagram vorhanden. Diese Typen sind:
• Liquidität
• Wertschriften
• Immobilien
• Hypothek
• Darlehen
• Kapitallebensversicherung
2.1.2.2. VZ-Produkt
Zur Laufzeit wird bei der Berechnung des Ruhestandsfahrplanes dem Kunden ein VZ-
Produkt basierend auf seinem Vermögen und Alter vorgeschlagen. Dieses fliesst als
Vermögen in die Berechnung ein.
2.1.2.3. Rente
Das deutsche Rentensystem basiert auf dem sogenannten 3-Schichten-Modell. Neben
der gesetzlichen Rente existiert die obligatorische betriebliche Rente. Dazu hat jeder die
Möglichkeit, private Renten abzuschliessen um so seine Rente aufzubessern.
2.1.2.4. Einflussfaktor
Ein Einflussfaktor bezeichnet einen durch das VZ vordefinierten Wert, welcher Einfluss auf
die Berechnung hat. Ein solcher ist beispielsweise die Inflationsrate, der Standardsteuersatz
oder das Ruhestandsalter.
2.1.2.5. Jahreswert
Da der Kapitalaufbau und Kapitalverzehr nicht linear sind, müssen die einzelnen Werte
pro Jahr ausgewiesen werden können.
2.1.2.6. Unterschied Kunde - potentieller Kunde
Zum Zeitpunk des Berechnens der Rentenlücke existiert noch kein Kunde aus Sicht
des Systemes, sondern es werden lediglich die benötigten Parameter für das Berechnen
angegeben. Für die Berechnung der Vorsorgelücke und des Ruhestandsfahrplanes muss
sich der potentielle Kunde registrieren, danach werden die Daten abgespeichert und es
kann von einem Kunde gesprochen werden.
252. Domainanalyse
2.1.2.7. Beziehung Ruhestandsfahrplan - Vermögen
ist Startvermögen Das vom Kunde erfasste Vermögen wird summiert als Startvermögen
für die Kapitalaufbau-Phase verwendet.
schlägt VZ-Lösung vor Für die Berechnung eines Ruhestandsfahrplanes wird vom
System automatisch eine VZ-Lösung anhand der Kundendaten (Alter, Einkommen,
Vermögen) vorgeschlagen.
263. Architekturspezifikation
Dieser Abschnitt beschreibt die Architektur der Umsetzung des Projektes VZ Altersvor-
sorgerechner, welches im Rahmen der Studienarbeit an der HSR umgesetzt wird.
3.1. Systemübersicht
Abbildung 17.: Systemübersicht
Quelle: Eigene Darstellung
3.1.1. Simulierte Kundendaten
Da gemäss VZ nicht bekannt ist, wo die Kundendaten in Zukunft gespeichert werden
und wie auf diese zugegriffen wird, können diese im Rahmen der Studienarbeit simuliert
werden. Dafür wird der JSON-Server [8] verwendet.
3.1.2. Frontend
Das Frontend läuft als Single-Page-Application im Browser.
3.1.3. Backend
Zugriffspunkt des Backends ist das API. Dieses ist als REST-Schnittselle implementiert
und verwendet JSON für die Serialisierung der Daten.
API Die Berechnungen laufen im API.
273. Architekturspezifikation
Datastore Als Datenspeicher wird auf eine Datenbank verzichtet, da dies so vom
VermögensZentrum gewünscht wurde. Die benötigten Daten werden in einem JSON-File
abgespeichert. Der DataAccess-Layer in der Architektur wird so abstrahiert, dass ein
späterer Wechsel zu einer Datenbank möglichst einfach ist.
3.2. Architektonische Ziele & Einschränkungen
3.2.1. Ziele
Das grobe architektonische Ziel ist es, das Frontend als simple Anzeige zu verwenden
und sauber von Business-Logik und Datenspeicherung zu trennen. Diese Aufgaben sollen
nur im Backend erledigt werden. Dies macht es möglich, diese Logik an einem Ort zu
haben und einfach auszutauschen.
3.2.2. Einschränkungen
3.2.2.1. Nicht-Funktionale Anforderungen
Die Nicht-Funktionalen Anforderungen haben nur Einfluss auf die Skalierbarkeit und
Performance, ansonsten haben die NFAs keinen Einfluss auf die Architektur. Da es sich
bei der Entwicklung um einen Prototypen handelt werden die nachfolgenden Punkte in
der Architektur berücksichtigt, jedoch nicht umgesetzt.
3.2.2.2. Skalierbarkeit
Die Architektur wurde so konzipiert ist, dass sie keine Abhängigkeiten von anderen
Systemen hat. Darum könnte in Zukunft einfach eine zweite Server-Instanz erstellt und
mittels Load-Balancing die Last verteilt werden.
3.2.2.3. Performance
Um die Performance-Anforderungen zu erfüllen könnte man Caching einbauen. Sinnvoll
wäre es auf dem DataAccess-Layer, da dort die Parameter als Einflussfaktoren für jede
Berechnungsanfrage gleich bleiben.
3.2.2.4. Security
Während des Projektes wird zwar auf Security geachtet und Grundprinzipien im Code
umgesetzt. Jedoch wird nicht darauf gesetzt, eine Sicherheit zu implementieren, die State
of the Art ist.
283. Architekturspezifikation
3.3. Logische Architektur
3.3.1. Backend
Das Backend ist in drei eigene Layers unterteilt: “Api”, “Business” und “DataAccess”.
Dabei gibt es ein Package “Domain” welches die Model beinhaltet und über alle Schichten
geteilt wird.
Abbildung 18.: Package-Diagramm Backend
Quelle: Eigene Darstellung
293. Architekturspezifikation
3.3.1.1. Wichtige Konzepte
Business Die einzelnen Services im Business-Layer sind nach den Use-Cases konzipiert.
Common in Business Das Package “Common” im Business-Layer beinhaltet Berechnun-
gen, welche aus allen anderen Services verwendet werden. Ein Beispiel ist das Hochrechnen
von Werten unter Berücksichtigung von Inflation.
Pension in Business Das Package “Pension” im Business-Layer beinhaltet Berechnungen
aus dem Bereich Rente. Darunter fallen beispielsweise das Berechnen der Regelaltersgrenze
oder der gesetzlichen Rente.
RetirementSchedule in Business Das Package “RetirementSchedule” im Business-
Layer beinhaltet verschiedene Komponenten für die Erstellung des Ruhestandsfahr-
plans. Dabei gibt es verschiedene Berechnungsarten im Package “Calculations”. Für die
verschiedenen Phasen werden unterschiedliche Konfigurationen mit verschiedenen Berech-
nungsarten benötigt. Im Package “Builder” findet man das Setup der Konfigurationen
basierend auf dem Package “Configuration”.
Business -> DataAccess Die einzelnen Business-Services verwenden je nach Bedarf
kein, ein oder mehrere Repositories aus dem DataAccess.
3.3.1.2. Error Handling
Bei Validierungsfehlern wird ein selbst definiertes Error Object mit HTTP Status Code
400 zurückgegeben. Dieses beinhaltet Type, Message und eine Map mit den betroffenen
Werten und den entsprechenden Fehlern. Bei unbekannten Fehlern wird ein HTTP Status
Code 500 und ein Error Object mit einer Standardmeldung zurückgegeben. Für genauere
Untersuchungen kann das Backend-Log analysiert werden.
Verwendete HTTP Status Codes Nebst den in ASP.NET Core integrierten Status
Codes (404 NotFound, 405 MethodNotAllowed) werden folgende HTTP Status Codes
direkt verwendet:
• 200 OK
• 400 BadRequest
• 500 Internal Server Error
Code 400 wird zurückgegeben, falls die Input-Validation nicht erfolgreich war oder
ein logischer Fehler in den Input-Daten existiert. Beispielsweise falls der Benutzer seine
Vorsorgelücke berechnen möchte, aber bereits pensioniert ist.
Code 500 wird zurückgegeben, falls entweder ein unbekannter Fehler aufgetreten ist
oder ein Fehler erkannt wurde, welcher aber nicht vom Client behoben werden kann
303. Architekturspezifikation
(beispielsweise das Parameter-File wurde nicht gefunden).
Als Basis dieses Entscheides wurden folgende Punkte berücksichtigt:
1. Im VZ werden in bestehenden Projekten keine anderen Status-Codes verwendet
(Ausnahme: 204 Created, im Backend werden jedoch keine Objekte erstellt).
2. Viele Best Practices und grosse Firmen die APIs anbieten schlagen vor, nicht zu
detaillierte Status Codes zu verwenden [16].
Umsetzung Für die einfache Umsetzung des spezifizierten Error Handlings und der
verwendeten HTTP Status Codes wurde eine Middleware [1] für ASP.NET Core entwickelt.
Die Middleware wurde konfigurierbar implementiert, so dass neue Exception-Typen und
das Mapping von diesen in HTTP Status Codes einfach hinzugefügt werden können. Die
Abbildung 19 zeigt ein Code-Beispiel für die Konfiguration dieser Middleware.
Abbildung 19.: Konfiguration der Exception Handling Middleware
Quelle: Eigene Darstellung
3.3.1.3. Designentscheidungen
Repository Pattern Das Repository Pattern [20] wurde eingesetzt, damit auf dem
Business-Layer die Logik des Ladens von Daten unabhängig von der eingesetzten Tech-
nologie im DataAccess-Layer geschehen kann. So sind die Layers sauber getrennt und
es kann beispielsweise ohne Probleme in Zukunft eine Datenbank als Datenspeicher
eingesetzt werden.
UnitOfWork Pattern Es wird kein UnitOfWork Pattern [15] eingesetzt, da keine Daten
geschrieben und deswegen auch keine Transaktionen über mehrere Repositories benötigt
werden.
3.3.1.4. Verwendete Libraries
NLog Als Logging-Library wird NLog verwendet. NLog bietet sehr gute und einfache
Konfigurationsmöglichkeiten und kann in ASP.NET ohne Probleme eingebunden werden
[3].
313. Architekturspezifikation
Json.NET Für das Deserialisieren von JSON-Dateien wird Json.NET [10] verwendet.
Diese Library ist ein defacto Standard für das Handling von JSON-Strukturen in C#
und wird in vielen Projekten verwendet [13].
SwashBuckle.AspNetCore Um die API Dokumentation zu erleichtern, wird Swash-
Buckle [19] genutzt, welche automatisch eine Swagger API Dokumentation generiert.
323. Architekturspezifikation
3.3.2. Frontend
Abbildung 20.: Package-Diagramm Frontend
Quelle: Eigene Darstellung
333. Architekturspezifikation
3.3.2.1. Wichtige Konzepte
Routing Je nach Route werden die verschiedenen Components der jeweiligen Module
geladen.
Layering Im Frontend gibt es kein klassiches Layering wie im Backend. Es wurde
entschieden pro Rechnertyp ein Modul zu erstellen, welche unabhängig voneinander sind.
So lassen sich diese in Zukunft leicht anpassen, austauschen und allenfalls dynamisch
nachladen (Lazy Loading). Es gibt jedoch innerhalb der drei Hauptmodule (PensionGap,
ProvisionGap, RetirementSchedule) ein Layering mit drei Schichten.
Modules Module werden nach den Use-Cases aufgeteilt und demnach auch so benannt.
Components Die Components stellen die Views und ViewModels dar.
Services Die Services koordinieren die Zugriffe auf die Daten.
RetirementScheduleRegister in RetirementSchedule Diese Komponente wird benö-
tigt, da dieses Modul eine weitere Registrierung des Users benötigt.
Shared Bei gemeinsam verwendeten Komponenten und Funktionalitäten greifen die
Module auf das Shared-Module zu. Beispielsweise könnte eine Component erstellt werden,
welches das Laden von Daten anzeigt.
Login in Shared.Components Da der User für die ProvisionGap- und RetriementSchedule-
Module eingeloggt sein muss, befindet sich die Login Komponente im Shared-Module.
Guards in Shared An diesem Ort befindet sich der AuthGuard, der dafür sorgt, dass
die definierten Routes durch den Login geschützt sind.
Pipes in Shared Pipes werden in den HTML-Templates der Komponenten benötigt,
um zum Beispiel Zahlen zu runden.
ConfigService in Shared.Services Da die Userdaten simuliert sind und von einer wei-
teren API bezogen werden, müssen die BaseURLs konfigurierbar sein.
3.3.2.2. Verwendete Frameworks & Libraries
Angular 6 Bei der Suche nach einem geeigneten UI-Framework stellte sich die Wahl als
schwierig heraus, da im Team noch keine grossen Erfahrungen vorhanden waren. Aufgrund
der guten Dokumentation und Reputation haben wir uns für Angular entschieden.
343. Architekturspezifikation
Material Design Nach dem Entscheid das Frontend mit Angular umzusetzen war auch
die Wahl der Design-Library eine einfache, denn Material Design wird ebenfalls vom
Angular-Team entwickelt und lässt sich somit gut zusammen verwenden. Da Google selber
viele dieser Komponenten in ihren Produkten verwendet sollte auch die Bedienbarkeit
kein Problem darstellen.
Bootstrap 4 Nach einer Evaluation der Material Design Library stellte sich heraus,
dass die Grid-Funktionalität nicht wirklich für unsere Bedürfnisse verwendbar ist. Da wir
in der Vergangenheit jedoch schon einmal etwas mit Bootstrap entwickelt und da gute
Erfahrungen gemacht haben, entschieden wir uns Bootstrap für diese Funktionalität zu
verwenden.
3.3.2.3. Wichtige interne Abläufe
Der Ablauf des UIs wurde vom VZ definiert und entworfen. Ersichtlich sind diese im
UI-Prototyp in Moqups [11]. Dieser Ablauf war aber als Anregung gedacht und wurde in
Absprache mit dem VZ im Rahmen der Studienarbeit in abgeänderter Version umgesetzt.
3.3.2.4. Naming Conventions
Components Die Komponenten eines Modules werden wie folgt benannt:
Modulname-Komponentenname. Selektoren beinhalten zudem das Präfix vz- um eine Ein-
deutigkeit zu erhalten. Komponenten im Shared-Module beinhalten keinen Modulnamen
im Komponentennamen.
3.3.3. Schnittstellen Frontend / Backend
Die aktuellste Schnittstellen-Dokumentation zwischen Backend und Frontend ist unter
auf Swagger [18] ersichtlich.
353. Architekturspezifikation
3.4. Implementierte Patterns - Backend
3.4.1. Builder Pattern
Das Builder Pattern [2] wurde für die Erstellung der AssetGroups für die einzelnen
Phasen verwendet.
Begründung Das Erstellen der einzelnen Gruppen ist komplex, da sie von vielen Fak-
toren wie beispielsweise Berechnungen, Vermögenspositionen und anderen Gruppen
abhängt. Zudem soll es in Zukunft möglich sein, andere Konstellationen (beispielsweise
für andere Länder) verwenden zu können. Für dies kann dann ein anderer “Concrete
Builder” implementiert und verwendet werden.
Abbildung 21.: Implementation des Builder Patterns
Quelle: Eigene Darstellung
363. Architekturspezifikation
3.4.2. Strategy Pattern
Das Strategy Pattern [17] wurde bei der Berechnung des Ruhestandsfahrplanes in etwas
abgeänderter Form implementiert. Der Unterschied zum klassischen Strategy Pattern
wird in der Abhängigkeit von Context zu Strategy sichtbar. Hier hat eine AssetGroup
mehrere Strategies, welche nacheinander angewendet werden.
Abbildung 22.: Implementation des Strategy Pattern
Quelle: Eigene Darstellung
3.4.3. Data Transfer Object
Für die Abkapselung der internen Klassenstruktur gegenüber den Clients wurde das Data
Transfer Object Pattern [14] implementiert.
373. Architekturspezifikation
3.4.4. Repository Pattern
Das Repository Pattern [20] wurde im Data Access Layer umgesetzt. Die einzelnen
Repositories wurden nach der Domäne unterteilt (Parametrierung, Produkte) und sind
für das Laden und Mappen der Daten verwantwortlich.
Begründung Dies stellt sicher, dass die Datenquelle in Zukunft geändert werden kann,
ohne den Business Layer anpassen zu müssen.
Abbildung 23.: Implementation Repository Pattern
Quelle: Eigene Darstellung
383. Architekturspezifikation
3.5. Deployment
Abbildung 24.: Deployment Diagramm
Quelle: Eigene Darstellung
3.5.1. Frontend/Backend
Das Frontend und Backend bestehen aus je einer IIS-Site. Beides läuft auf dem gleichen
Windows Server 2016. Das Deployment geschieht automatisch, sobald ein neuer Release-
Commit im Repository erstellt wurde.
Trennung von Frontend und Backend Das Frontend und Backend wurden bewusst
getrennt, damit das Frontend allenfalls auch von einem externen Partner entwickelt
werden kann. Ausserdem ist es möglich, dass das Frontend häufiger wechselt als das
Backend und bei einem Wechsel des Frontends nicht unbedingt das Backend nochmals
gebuildet und released werden muss.
393. Architekturspezifikation
3.6. Datenspeicherung
Die benötigten Parameter für die Berechnung werden in JSON-Files gespeichert.
3.6.1. Entscheidung
Die Daten werden nicht wie anfangs definiert in einer relationalen Datenbank gespeichert,
sondern in JSON-Files. Dies auf Wunsch vom VZ. Grund dafür ist, dass dies die Integration
in die Umgebung des VZ vereinfacht.
3.6.2. Konzepte
3.6.2.1. Einflussfaktoren
Die Einflussfaktoren werden in Gruppen nach Verwendungszweck unterteilt. In diesen
Gruppen sind die einzelnzen Werte als Key-Value-Paare abgespeichert.
3.6.2.2. Produkte
Die VZ-Produkte werden mit den Eigenschaften “Anlegerprofil” und “Rendite” abgespei-
chert.
40Sie können auch lesen
