| Create from Template | ||||||
|---|---|---|---|---|---|---|
|
...
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>
| View file | ||||
|---|---|---|---|---|
|
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. Ved denne løsningsmodel migreres integration til KSS'er m.fl. fra tykke WSRM'er til tynde WSRM'er og webserviceudstilling, dvs. KSS'erne vil blive påvirket af denne løsningsmodel.
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.
Tabellen angiver forventet ressourceforbrug. Best case (20% fraktil) er 20% lavere, mens worst case (90% fraktil) er 30% højere.
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 kan derfor planlægge migrationen ved at balancere risici forbundet med at anvende ikke supporteret AngularJS framework efter juli 2021 i forhold til øvrige udvikling og kvalitetsforbedring på VITAS og under hensyntagen til udviklingsressourcer.
Risici
Der er ikke særlige risici ved transitionen, da der kun anvendes teknologier og værktøjer, som allerede anvendes på VITAS. Risici omfatter derfor fortrinsvis usikkerhed i kompleksitet, som kan påvirke ressourceforbruget.
Leverandøranbefaling
Leverandøren anbefaler migrering til den fulde løsning med det samme, hvis STAR skal dog være opmærksom på, at har et ønske eller en forventning om at migrere til løsningsmodel "Fuld". Hvis STAR ikke har et ønske om at migrere til løsningsmodel "Fuld" på et senere tidspunkt, men er indstillet på at VITAS skal forsætte med det nuværende omfang af teknisk gæld og det tilhørende ressourceforbrug, så anbefaler leverandøren løsningsmodel "Lille".
Løsningens grænseflader
Løsningens omfang
...