Create from Template
templateName 762773974 templateId 762773974 buttonLabel Opret ny epic

...

ISB'en omfatter specielt ansvar for at migrere VITAS fra AngularJS til Angular 10, da AngularJS ikke længere er supporteret. ISB'en indeholder et selvstændigt afsnit om denne migrering, herunder estimater, epics og roadmap.

Migrering af VITAS fra AngularJS til Angular 10

Leverandøren og STARs arkitekt har gennemført en estimeringsworkshop d. 6. august 2020, som resulterede i migreringsmodeller, nedbrydning i epics, estimering af epics og afdækning af afhængigheder til brug for roadmap.

Baggrund

VITAS består i dag af to forskellige applikationer med forskellig arkitektur, som driftsafvikles på en måde, så brugerne i al væsentlighed opfatter VITAS som én applikation:

• Den gamle applikation "Gammel AngularJS", der er baseret på AngularJS, indeholder VITAS' rammefunktioner (forsider, login, dashboard, lister ...) samt de gamle ordninger (løntilskud, virksomhedspraktik, voksenlærling, IGU, mentor tillægsbevilling, hjælpemidler tillægsbevilling). Den gamle applikation anvender en arkitektur, der betragtes som forældet i forhold til den nye applikation. Der anvendes bl.a. Windows Worflow Foundation, MVC, fede WSRM'er og en mindre hensigsmæssig datamodel, ligesom arkitekturen ikke understøtter genbrug, men i vid udstrækning er baseret på kodekopiering. Det er den gamle VITAS applikation, som skal migreres fra AngualrJS til Angular.
• Den nye applikation "Ny Angular", der er baseret på Angular 7, indeholder de nye ordninger (Fleksjob, Mentor, Personlig assistance, Hjælpemidler og Jobrotation. Den nye applikation har en mere hensigtsmæssig arkitektur end den gamle applikation, så selv om der forsat er en række uhensigsmæssigheder i arkitekturen (hardkodede tekster, ingen versionering af ordninger mv), så kan den nye applikations arkitektur opfattes som målarkitektur for migrering af den gamle applikation.

Den gamle applikation skal migreres fra AngularJS til Angular 10, da AngularJS ikke længere supporteres efter juli 2021. Dermed vil der ikke blive foretaget fejlrettelser, herunder rettelse af evt. sikkerhedsproblemer efter juli 2021. Der er ingen egentlig migrationsvej fra AnguarlJS til Angular, hvilket betyder, at der skal gennemføres en egentlig omprogrammering af hele brugergrænsefladen på VITAS' gamle applikation.

Der er identificeret to løsningsmodeller.

Løsningsmodel "Lille"

Den lille løsningsmodel omfatter den billigst mulige migration fra AngularJS til Angular 10, hvilket svarer til STARs ønsker til migreringen.

Løsningsmodellen omfatter migrering af såvel rammefunktioner som ordninger:

• Rammefunktionernes brugergrænseflader vil blive omprogrammeret i VITAS' eksisterende nye applikation. Rammefunktionernes eksisterende forretningslogik og databaseunderstøttelse er relativ enkel og bibeholdes. Arbejdsgruppen finder, at denne migrering er i overensstemmelse med arkitekturen for den eksisterende nye applikation i tilstrækkeligt omfang til, at der ikke efterlades teknisk gæld på rammefunktionerne.
• De gamle ordninger vil blive omprogrammeret til en selvstændig Angular 10 baseret applikation "Gammel Angular" (brugergrænseflade i browser) med et tilhørende nyt WebAPI lag, der gennemstiller til den gamle applikations back-end, som beholder uændret arkitektur. Dvs. de gamle ordninger vil have samme omfang af teknisk gæld som de har i den nuværende gamle applikation "Gammel AngularJS". Det er ikke muligt at implementere de gamle ordningers brugergrænseflader i den eksisterende, nye VITAS applikation og samtidig bibeholde de gamle ordningers back-end uden at der i uhensigtsmæssigt omfang introduceres teknisk gæld i den eksisterende, nye applikation.

Det betyder, at der i migreringsperioden vil være tale om 3 webapplikationer, men at der efter migreringsperioden igen vil være tale om 2 webapplikationer: "Ny Angular", som indeholder rammefunktioner og de nye ordninger med den pt. ønskede målarkitektur, samt "Gammel Angular", der indeholder de gamle ordninger . Figuren herunder illustrerer den nuværende arkitektur, arkitektur i migrationsperioden og arkitektur efter migrationsperioden:

<figur indsættes her>

Løsningsmodel "Fuld"

Denne løsningsmodel efterlader VITAS med én webapplikation med samme arkitektur som den nuværende nye webapplikation "Ny Angular", idet alle funktioner fra den gamle webapplikation migreres til den nye applikation. I denne løsningsmodel omskrives de gamle ordninger fuldstændigt, og data migreres fra VITAS' gamle database "VITAS" til den nye database "VITAS2". Dermed efterlades der ikke teknisk gæld svarende til uhensigsmæssighederne i den gamle applikation, men uhensigtsmæssighederne i den eksisterende nye applikation adresseres ikke.

Migrering fra løsningsmodel "Lille" til løsningsmodel "Fuld"

Det vil være muligt at migrere fra løsningsmodel "Lille" til løsningsmodel "Fuld" på et senere tidspunkt. Omkostningerne ved at først migrere fra løsningsmodel "Lille" til løsningsmodel "Fuld er imidlertidig væsentligt større end at migrere til løsningsmodel "Fuld" fra starten, hvilket fremgår af epicsoversigten. Leverandøren anbefaler derfor, at der migreres til den fulde løsning med det samme, hvis STAR har et ønske eller en forventning om at migrere til løsningsmodel "Fuld".

Epics og estimater

Migreringen er nedbrudt i et antal epics, som hver især kan implementeres uafhængigt af de andre, herunder i forskellige releases. Dog skal den første epic "1 Opgradering fra Angular 7 til Angular 10" implementeres før de øvrige epics for at der kan migreres fra AnguarlJS til nyeste version af Angular.

...

• Estimat lille
  Estimat for at lave minimal migrering af funktionen fra AngularJS til Angular 10 jf. model ???"Lille", som efterlader teknisk gæld.
• Estimat fuld
  Estimat for at genimplementere funktionen i VITAS' nye Angular baserede applikation jf. model ???"Fuld", som ikke efterlader teknisk gæld
• Estimat lille → fuld
  Estimat for at migrere funktionen fra model ??? "Lille" til model ??? "Fuld" på et senere tidspunkt. 

Roadmap

Da der er meget få afhængigheder mellem epics i migrationen, kan epics implementeres uafhængigt af hinanden, dog skal den første epic implementeres før de øvrige. Dermed har STAR stor frihed til at prioritere fordeling af migrationen mellem releases. Det vil dog være mest effektivt at migrere en ordning ad gangen.  STAR skal dog være opmærksom på, at 

Løsningens grænseflader

Løsningens omfang

...