Versions Compared

Old Version 2

changes.mady.by.user Rolf Marcher Arndt

Saved on

compared with

New Version Current

changes.mady.by.user Rolf Marcher Arndt

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning



Page Properties


STAR Projektleder (PL)Forretningsanalytiker (FA)STAR ReleaseEpic statusEksterne snitflader
Knud de Place (STAR)Rolf Marcher Arndt2021-120.1n/a




Jira Legacy
serverSystem JIRA
columnskey,po,fa,ux,sme,eksterne snitflader,interne snitflader,status,labels
maximumIssues4
jqlQueryissuetype = epic AND cf[10006] = 955.12 order by key
serverId479d1618-4a6f-3f88-8ee1-04c6b02c448a

Jira Legacy
serverSystem JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId479d1618-4a6f-3f88-8ee1-04c6b02c448a
keyDS-3581



Indholdsfortegnelse

Table of Contents
outlinetrue



Afgrænsning af epic

Afgrænsning

Som en ..

vil jeg ..

for at ..

Acceptkriterier

Nr.BeskrivelseRelevant for
955.12.1Som STAR og Arkitekt ønsker jeg implementeringen af den nye personadvancesearch analyse fra 955.12DFDG
955.12.2Som Intern aftager af Landssupport systemet, ønsker jeg at kunne fremsøge borgere i specifikke senarier, der forud er defineret.DFDG




Kriterier for tilsagn til serviceaftager i forhold til STARs snitfladerBerørte acceptkriterierBemæ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)

Jira Legacy
serverSystem JIRA
columnssummary,varslingstype,varslingsnote,eksterne snitflader,interne snitflader,project
maximumIssues100
jqlQueryissuetype = Varsling AND linkedIssue in (DS-3581) ORDER BY summary, Varslingstype, "Eksterne snitflader", "Interne Snitflader"
serverId479d1618-4a6f-3f88-8ee1-04c6b02c448a


Beskrivelse af epic

I denne epic vil der indhentes krav fra interessenter, beskrives mulige løsningsmodeller, herunder fordele og ulemper ved hver forskellige løsningsmodeller samt et grov estimat. 

Nedenstående i punkt form:

  • Behov for fabrikering af data, kontra avanceret udsøgning på data ud fra dataløft.
  • Interessenter
    • Jobnet, DFDG, SF Test, Kundesupport, CV projektet flere?
  • Kravsafdækning
    • Ud fra de forskellige interessenter
  • Løsningsmodeller
    • Fordele / Ulemper
    • Estimat


ProjektKrav/ØnskerAndet
Jobnet
  1. Når en borger er oprettet, skal vi få returneret brugernavn og adgangskode
  2. Man skal kunne oprette flere borgere på én gang og dermed få en samling af borgere retur
    1. Borgerne i samlingen skal være i samme rækkefølge, som vi har anmodet om dem
  3. Man skal kunne oprette borgere med følgende data:
    1. Jobcenter
    2. Kontaktgruppe
    3. Personkategori
    4. Klientkategori
    5. Alder
    6. Fravær (alle typer)
    7. Tilmeldt/Afmeldt
    8. Planer og aktiviteter
    9. Møder (både fremtidige og afholdte)
    10. Frist inkl. dato
    11. Overskredet frist (straksbookingramt)
    12. Rehabstatus 1, 2, 7, 3 og 4
      1. For status 3+4 gerne inkl. indstillingsdokument
    13. Krav til jobsøgning
  1. A-kasse og jobcenter
    1. Dagpengetællere
    2. Supplerende dagpengetællere
    3. 225 timersreglen
  1. Høj og lav hjælp (ydelsesniveau)
    1. Integrationskontrakt
Modtaget på mail d. 01-11-2019
DFDG
  • Borgere med:
    • Plan og aktiviteter (Evalueringer)
    • Kontaktpersoner (Rigtige -Mentor)

SF TestData oprettelse er så forskellig fra gang til gang, så der er ikke specifikke krav.27-01-2020
Kundesupport

CV projektet

Virk/sag

Ønske om mulighed for at søge borgere frem som har skjult adresse.

https://manuscript.star.dk/f/cases/164609/Det-skal-v-re-muligt-at-s-ge-borgere-med-skjult-adresse

05-06-2020


Løsningsmodeller


ForImod

Fabrikering af data

eg. Inttestrammeværk.

  • Borger kan oprettes i nøjagtigt den tilstand man ønsker.
    • Forud i tid/bagud i tid uden at valideringer fanger en.
  • CPR nummer kan være fiktivt ved oprettelse.
  • Man skal ikke tage stilling til andet end det man selv har oprettet på en fiktiv borger.
  • Hvis data ikke oprettes, i henhold til forretningsservices vil der være mulighed for at få data i forkert tilstand.
  • Løsning vil tidsmæssigt tage længere tid, samt længere tid i forbindelse med vedligeholdelse, da vi muligvis skal tilrette løsningen, hvis services/data ændres.
    • Dette hvis der skal være GUI til løsningen.
Udsøgning af data
  • Man kan benytte eksisterende funktionalitet/udvide eksisterende funktionalitet (PersonAdvanceSearch).
  • Man får data som de var oprettet i produktion.
  • Data på borgere som forringes over tid vil være svære at udsøge efter noget tid efter dataløft i TMiljøer.
  • Før vi begynder at scramble CPR numre vil det være "rigtige" CPR numre der udsøges.
Brug af Leapwork til oprettelse af testdata
  • Borger kan oprettes i nøjagtigt den tilstand man ønsker, ud fra at der er oprettet en case i Leapwork til det.
  • Data oprettes i henhold til forretningsservices så tilstand sikres via valideringerne.
  • Udbredelse af værktøjet som STAR har valgt at teste frontend.
  • Det kan være at man løber tør for CPR, hvis data benyttes til automatisering.
  • Før vi begynder at scramble CPR numre vil det være "rigtige" CPR numre der får tilføjet data.
    • Ovenstående to punkter kan adresseres, ved at oprette en service som kan oprette fiktive CPR numre.
  • Ud fra om denne er den første case i implementeringen af Leapwork, må man formode at der må være lidt opstarts omkostninger.
    • Ubekendt, oprettelse af test data via Leapwork i AmpDebugger.
  • Ved benyttelse af eksisterende services, vil vi ikke har mulighed for at oprette borgere som ved kald eks. er straksbookingramt. på kald tidspunktet.


Det kan i samme ombæring overvejes, hvorvidt vi skal have en service som opretter fiktive personer (CPR), som der blev gjort i forbindelse med 917.1, da BI gjorde for for DUPLA test personerne.

Denne service kunne udstilles på TMiljøerne og beskyttes med en Rolle som ikke skulle tildeles til nogen certifikater i Prod, indtil at det besluttes at der måske også skulle være mulighed for at oprette test personer i PROD.

  • Kunne muligvis adressere punktet: Dolly - Funktionalitet (SF)

Acc.kr 955.12.1 Som STAR og Arkitekt ønsker jeg en teknisk SPIKE udført på PersonAdvancedSearch, for at identificere den bedste løsning, for at kunne garantere svartider

Se mere under:

/wiki/spaces/ISB/pages/2032664577

Acc.kr 955.12.2 Som Intern aftager af Landssupport systemet, ønsker jeg at kunne fremsøge borgere i specifikke senarier, der forud er defineret.



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.
  • Kommunalt sagsbehandlingssystem
  • A-kasse sagsbehandlingssystem
  • Kommunalt bookingsystem
    • JobcenterPlanner (JCP)
    • WorkForcePlanner (WFP)
  • Kommunalt ydelsessystem

Særlige krav til test

Test scenarieBerø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.