Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
Indholdsfortegnelse
Automatisk oversigt
Ikke synlig for eksterne, men indeholder ikke andre oplysninger end kopieret til den manuelle oversigt ovenfor.
Afgrænsning af epic
| Afgrænsning | ||
|---|---|---|
Som STAR ønsker jeg at oplysninger om herkomst udgår som variabel i profilafklaringsværktøjet (forberedelsesskemaet) og i PersonStatusService for at undgå at brug af oplysningen om herkomst bliver et tilbagevende emne, som skaber negativ omtale og dermed uvilje imod brugen af værktøjet. | ||
| Acceptkriterier | ||
| Nr. | Beskrivelse | Relevant for |
| 829.8.1 | Herkomst udgår som oplysning i PersonStatusService | DFDG |
| 829.8.2 | Variablen herkomst udgår af profilafklaringsværktøjet | DFDG |
| Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | |||
|---|---|---|---|---|---|
| 829.8.1 | 829.8.2 | ||||
| KSS og a-kasser er opmærksomme på, at feltet herkomst i responset i PersonStatusService.GetVariablePersonStatus altid vil være tomt | X | ||||
| KSS og a-kasser er opmærksomme på, at oplysninger om herkomst udgår af profilafklaringsværktøjet | X | ||||
Oversigt over berørte webservices
Manuel oversigt som er synlig for eksterne
Links i listen virker kun med STAR Jira konto og kan derfor ikke tilgås af eksterne. Links under Summary indeholder ikke andre oplysninger relevant for eksterne end hvad der fremgår af tabellen.
Summary | Varslingstype | Varslingsnote | Eksterne Snitflader | Interne Snitflader | Project |
|---|---|---|---|---|---|
Automatisk oversigt
Ikke synlig for eksterne, men indeholder ikke andre oplysninger end kopieret til den manuelle oversigt ovenfor.
Beskrivelse af epic
829.8.1 - Herkomst udgår som oplysning i PersonStatusService
I den eksisterende version af PersonStatusService (version 20).GetVariablePersonStatus vil oplysninger om herkomst i Core-info kollektion altid returnere et tomt resultat (feltet PersonOriginCode).
Ændringen foretages uden løft af serviceversion, da der er forekomst 0-1 for feltet.
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 |
|---|---|---|
| Herkomst kan ikke længere aflæses i LSS | PersonStatusService.GetVariablePersonStatus - oplysninger om herkomst i Core-info kollektion skal altid returnere et tomt resultat (feltet PersonOriginCode). | Knud |
| Forberedelsesskemaet kan udfyldes på Jobnet selvom herkomst er udgået som variabel | CitizenScreeningService | Knud |
| Screeningsresultater / svar på forberedelsesskemaet besvaret før idriftsættelsen kan fortsat hentes af sagsbehandlere | ScreeningService - forskellige Get-metoder | Knud |
| Screeningsresultater / svar på forberedelsesskemaet besvaret før idriftsættelsen kan fortsat hentes af borgerne på Jobnet | CitizenScreeningService | Knud |
* 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.