Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
Indholdsfortegnelse
Afgrænsning af epic
Afgrænsning | ||
---|---|---|
Som en .. vil jeg .. for at .. | ||
Acceptkriterier | ||
Nr. | Beskrivelse | Relevant for |
967.6.1 | Virksomhed skal kunne søge om forlængelse på mentor (KC68722) (MVP 2020) (AFKLARING) | VITAS |
967.6.2 | Ophørsfunktionalitet og forlængelse? (KC64130) (MVP 2020) (AFKLARING) | VITAS |
Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | |||
---|---|---|---|---|---|
Acceptkriterie <nr.> | Acceptkriterie <nr.> | Acceptkriterie <nr.> | Acceptkriterie <nr.> | ||
Oversigt over berørte webservices
Manuel oversigt som er synlig for eksterne (links i listen virker kun med STAR Jira konto):
Automatisk oversigt (vi arbejder på løsning på at gøre den synlig)
Beskrivelse af epic
967.6.1 Virksomhed skal kunne søge om forlængelse på mentor (KC68722) (MVP 2020) (AFKLARING)
Det skal afklares om dette kan afløses ved en fælles forlængelses/ophørsfunktion se:
FEATURE 64130(AFKLARING) - ophørsfunktionalitet og forlængelse? (mentor/hjælpemidler/PA)
Alternativt laves funktion på virksomhedens read only side hvorfra virksomheden kan op rette forlængelse, som kan modtages i jobcentret - Der sætte ikke effort på denne da der mangler yderligere afklaring herunder hvad virksomhed skal kunne indtaste i en evt. forlængelses side + hvordan jobcentrets forlængelsesbehandlingsside skal se ud.
967.6.2 Ophørsfunktionalitet og forlængelse? (KC64130) (MVP 2020) (AFKLARING)
kolonnerne 'bevilling ophører' i svømmebane-dokumentet adskiller sig lidt fra ordning til ordning.
Det skal afklares om vi kan ensrette forlængelses- og ophørskonceptet og dermed spare udvikling.
På de eksisterende tillægsbevillinger findes simpel ophørs- og forlængelse funktionalitet på jobcenterside. - Det skal også afklares om dette skal adskille sig på de nye selvstændige mentor, hjælpemidel og PA bevillinger?
Overvej for hvert acceptkriterie hvilke systemer der berøres af ændringen:
- DFDG
- Services
- WSRMer
- Kodelister
- PersonStatusService (PSS)
- PersonHistoryService (PHS)
- LSS (Landssupportsystem) og herunder Registerudtræk (hvis STAR har dataejerskab og der er lavet PHS på domænet)
- Jobnet
- VITAS
- JobKon
- JobAG
- BI integrationsplatform
- Alle områder
- Nye batchjobs
- Dokumentation af jobbet til SF (jf. skabelon: xxx link til skabelon)
- Dataløft
- Hvis der i Databaser tilføjes eller fjernes kolonner med personfølsomme data (f.eks. person navne, adresser, email, telefonumre etc.), så skal SF informeres så disse data fremadrettet tilføjes eller fjernes fra scrambling.
- Nye batchjobs
- Kommunalt sagsbehandlingssystem
- A-kasse sagsbehandlingssystem
- Kommunalt bookingsystem
- JobcenterPlanner (JCP)
- WorkForcePlanner (WFP)
- Kommunalt ydelsessystem
Særlige krav til test
Test scenarie | Berørte systemområder (herunder nye batchjobs*) | Identificeret af |
---|---|---|
* Batchjobs
- bør testes både med delta og fuldt load,
- bør hvis der er afhængigheder køres med normalt load fra BI i ét testmiljø i hele testperioden
- bør testes i samarbejde med teams som har afhængigheder
- kørselstid, særligt hvis det er en del af NightlyBatch
Konsekvenser for drift/idriftsættelse
I forbindelse med idriftsættelse:
- Skal der køres et fuldt dataload ved første kørsel af et batchjob - aftal med SF hvornår load skal køres
- skal der køres konvertering
- Skal der køres databasescripts for opdatering af tabeller i databasen
Efter idriftsættelse:
Arkitektur- og implementeringsnoter
Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:
- Nye dataområder
- Nye snitflader
- Nye komponenter
- Nye miljøer
- Nye teknologier
- Nye aftagertyper
- Eller afvigelser fra principperne
- Eventuelle behov for reduktion af teknisk gæld skal afdækkes
Der gives en beskrivelse af hvorledes disse tænkes håndteret/implementeret i løsningen og om dette har været vendt med STAR arkitekten.