Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
Indholdsfortegnelse
Afgrænsning af epic
| Afgrænsning | ||
|---|---|---|
Som en STAR vil jeg kunne opbygge en ny version af ESCO-STAR baseret på den foregående version, samt på en ny version af ESCO fra EU for at STAR kan vedligeholde ESCO-STAR baseret på forretningsmæssige behov såvel som på ændringer i ESCO fra EU | ||
| Acceptkriterier | ||
| Nr. | Beskrivelse | Relevant for |
| 976.7.1 | ESCO-STAR Silo udstiller et administrationsinterface, som Admin Værktøj kan anvende til at udtrække den aktuelle version af ESCO-STAR, samt til at idriftsætte en ny version af ESCO-STAR | ESCO-STAR |
| 976.7.2 | ESCO-STAR Admin Værktøj kan opbygge en ny version af ESCO-STAR baseret på den aktuelle version af ESCO-STAR. Den nye version har status "kladde" indtil den idriftsættes. | ESCO-STAR |
| 976.7.3 | Der kan kun være én "kladde" version ad gangen. Kladden kan løbende gemmes og kan genåbnes på et senere tidspunkt | ESCO-STAR |
| 976.7.4 | Kladden kan sættes i produktion, hvorefter den ikke længere kan redigeres. Note: Der skal tænkes en god mekanisme mellem test og produktion, fx staging | ESCO-STAR |
| 976.7.5 | Indholdet i en ny version af ESCO kan flettes ind i en kladde uden at tidligere tilpasninger i ESCO-STAR går tabt. Der er funktioner til at håndtere ændringer med konflikter | ESCO-STAR |
| 976.7.6 | Det er ikke muligt at slette en stillingsbetegnelse, som tidligere har været idriftsat, men man kan deaktivere en stillingsbetegnelse, så den ikke kan vælges ved nye data, men kan bruges ved eksisterende data. Der kan vælges status jf. schema (Aktiv, Inaktiv, Fravalgt). | ESCO-STAR |
| 976.7.7 | Det er muligt at slette synonymer (alias), selv om det har været idriftsat | ESCO-STAR |
| 976.7.8 | Det er muligt at tilføje nye synonymer | ESCO-STAR |
| 976.7.9 | N/A | ESCO-STAR |
| 976.7.10 | Det er muligt at ændre den brugerrettelse tekst på en stillingsbetegnelse | ESCO-STAR |
| 976.7.11 | Det er muligt at ændre beskrivelsen af en stillingsbetegnelse | ESCO-STAR |
| 976.7.12 | Det er muligt at tilføje en stillingsbetegnelse til ESCO-STAR, som ikke findes i ESCO. Forretningsregler jf. schema. | ESCO-STAR |
| 976.7.13 | ESCO-STAR Admin Værktøj har ambitionsniveau og budget: stor / mellem / lille? | ESCO-STAR |
| 976.7.14 | Det er kun muligt for én bruger ad gangen at redigere en kladde. Flere brugere kan se kladden samtidigt, men uden automatiske opdateringer | ESCO-STAR |
| Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | |||
|---|---|---|---|---|---|
| Ikke relevant | |||||
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
Der skal laves et administrationsværktøj, som kan anvendes til at vedligeholde ESCO-STAR. Der vil kun være ganske få brugere af værktøjet, og disse brugere forventes at have dybtgående kendskab til ESCO og til ESCO-STAR. Brugerne vil være ansatte hos STAR. Man kan overveje at give yderligere brugere read-only adgang til ESCO-STAR, så værktøjet også kan anvendes til at få indsigt i ESCO-STAR.
Roller:
a) ESCO-STAR administrator: Skal autoriseres af værktøjet for at undgå, at uvedkommende kan ændre på ESCO-STAR.
b) Read-only bruger. Optionel rolle som kan anvendes af alle uden autorisation, idet ESCO-STAR ikke indeholder følsomme data.
Ambitionsniveauet bør afspejle disse få roller, så udviklings- og vedligeholdesesomkostninger holdes på et lavt niveau.
Forslag til navigering i ESCO-STAR: Hierarkisk baseret på ISCO (øverste niveauer) / ESCO (EU niveauer under ISCO) / ESCO-STAR (danske extensions) hierarki.
Forslag til redigering: Én node (stillingsbetegnelse) ad gangen. ISCO og ESCO felter er read-only, da de er referencedata, mens ESCO-STAR felter er redigerbare.
Forslag til løsning: Simpel webapplikation, fx. det af LSS.
976.7.13 ESCO-STAR Admin Værktøj har ambitionsniveau og budget: stor / mellem / lille?
Produktets behov skal afstemmes ift. MVP. Minimum Viable Product, lige præcis (hverken mere eller mindre) indeholder funktionalitet, som tillader VOA at administrerer og vedligeholde nomenklaturen brugervenligt, nemt og sikkert.
Der er tale om en fuldt ud ESCO-kompatibel model, hvilket betyder mindst vedligeholdelse i forhold til forretningsimplementering samt it-løsning og administration,, når der kommer fremtidige opdateringer i ESCO.
Beslutning fra WS2 (16.03.2020)
Jørgen (BI) fremsender eksempler fra en "Sharepoint" løsning.
Applikation (Positivliste, der administrere data mellem Jobnet og DFDG, som et bud på et system som vil kunne anvendes.
Mockup
Her præsenteres en mockup, som illustrerer ESCO-STAR Admin Værktøj .
Felter jf. epic 976.3, krav 4 (fra Krav til ESCO-STAR schema).
Datagrundlag jf. ESCO: https://ec.europa.eu/esco/portal/occupation
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
Der er følgende arkitekturkrav, som afstemmes med STARs arkitekt:
- Forberedelses af admin.modul ift. mulighed for indarbejdelse af hierarki for kompetencer.
- Forberedelse ift. mulighed for anvendelse af STARs eget nationale kompetenceprojekts kompetencer i samspil med ESCO-skill da kompetenceprojektet ikke er kompatibel med ESCO færdigheder/kompetencer og udvekling med Eures.
- Forberedelse ift. mulighed for anvendelse af Uddannelse, herunder integration til (Euro-pass).
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.