Skemaet nedenfor angiver efter hvilke kriterier SF visiterer sagerne, og ligeledes hvilke kritierier KSS’er, A-kasser, STAR mfl. bør anvende når der sættes Priroritet på sager i Manuscript.
Hvis en sag nedprioriteres i visitationsprocessen, skal STAR og Sagsopretter altid informeres om dette.
Hvis sagsopretter ændrer prioritet på en sag, skal denne assignes til Systemforvaltning til gen-visitering, og årsag angives ved opprioritering.
Prioritet
Beskrivelse
Eksempler
1 – Kritisk
Major Incident
Kræver handling med det samme.
Alt andet tilsidesættes
Ved kritisk fejl i Produktionsmiljøet: Foretag altid opringning til SF når en kritisk sag er oprettet, så det sikres at sagen får den nødvendige opmærksomhed. Tlf: 72 18 30 05
Angiv altid begrundelse for at en sag er Kritisk.
Kritisk fejl der gør at systemet eller dele af systemet ikke er tilgængeligt
Påvirker hele forretningen - alle eller et meget omfattende antal brugere
Resulterer i tab af data eller fejlagtig data
Der findes ikke en brugbar workaround
Kandidater til en Emergency Patch
I Produktionsmiljøet:
Produktionsmiljøet eller betydelige dele heraf (f.eks. Jobnet, AMP, LSS) er utilgængeligt/svarer ikke eller opfører sig meget uhensigsmæssigt
Performanceproblemer i en grad så systemet ikke kan anvendes
Det er ikke muligt at tilmelde, afmelde eller sygemelde borgere
Kritiske batchjobs fejler i Produktion – medfører f.eks. datakorrumption
Sager der har økonomisk konsekvens (f.eks. om borgere får udbetalt dagpenge korrekt)
Fejlen har alvorlige økonomiske konsekvenser
Sager der kræver datagenopretning på et større antal borgere
Blokeret WSRM kø i produktion
Jobcenter kan ikke arbejde
Kræver datagenopretning
I Next Testmiljøerne:
Blokerende fejl i Next Continuous Deploy miljø (medfører at ingen kode deployes videre til øvrige miljøer)
Blokeret WSRM kø i testmiljø under testfaserne
Blokerende for test i testmiljø under testfaserne
Testmiljø er utilgængeligt / svarer ikke under testfaserne
Fejl i testmiljø, der kan have ovennævnte konsekvenser i produktions miljøet, hvis de ikke rettes inden idriftsættelse.
2 - Alvorlig
Kritisk fejl der gør at systemet eller dele af systemet ikke er tilgængeligt, men der findes en workaround
Fejl der vil påvirke/påvirker en betydelig del af forretningen
Forringet service/ nedsat performance i produktions- eller testmiljø
Fejl kandidater til en Planlagt Patch eller næste release.
Som eksemplerne ovenfor, men der findes en workaround.
I Produktionsmiljøet:
Brugeren kan fortage sig noget i applikationen, der ikke burde være muligt, (f.eks. raskmelding, selvom det ikke burde være muligt).
En misvisende fejlbesked
Delvist tab af funktionalitet
Sager der påvirker data
Sager der påvirker gennemførsel af proces eller gennemførsel af samtale
Sager der kræver datagenopretning på en eller flere borgere
I alle testmiljøerne:
Blokerende for udvikling og test
I next next testmiljøer (med Sub priority 1 i følgende tilfælde):
Blokeret WSRM kø i testmiljø
Blokerende for test i testmiljø
Testmiljø er utilgængeligt / svarer ikke
Fejl i testmiljø, der kan have ovennævnte konsekvenser i produktions miljøet, hvis de ikke rettes inden idriftsættelse.
3 – Ikke Kritisk
Fejl der vil påvirke/påvirker et mindre, ikke kritisk område af forretningen
Der er konstateret fejl i funktionen, men den kan stadig anvendes
Fejl som betyder at systemet ikke fungerer efter hensigten
Omgåelse er mulig / Workaround er tilgængelig
Fejl der vil medføre/medfører gene for brugere
Man trykker gem, og kommer ikke tilbage til hovedsiden som man burde
Søgning af datointerval, men hele måneden vises
Der vises en forkert knap for borgeren, men der ikke er tegn på, at den medfører ”ulykker”
Manglende visning af et mindre vigtigt felt i et brev (f.eks. sluttidspunkt for, hvornår borgeren kan ringe til jobcenteret).
Fejl i input i et servicekald fanges af en anden validering end forventet, men der returneres som sådan ikke nogen forkert fejlmeddelelse (f.eks. giver manglende slutdato på visse fravær fejlen ”Varighed må ikke være længere end 3 måneder” i stedet for ”Slutdato skal angives”).
4 - Kosmetisk
Fejl af kosmetisk karakter, der medfører mindre gene for brugeren.
Manglende indrykning
Stavefejl
Forkert farve
Forkert fontstørrelse mv.
Forkert format på dato
Sub Priority (STAR Intern Prioritering)
Dette felt er til intern anvendelse for STAR og STARs leverandører
Prioritet
Beskrivelse
Prioritet
Beskrivelse
-
Default - Der er ikke taget stilling og løses efter aftale med CPO/PO
1 - Meget høj
Meget høj (løses først og prioriteres ind i sprint/release/patch)
2 - Høj
Løses først sammen med 1 prioritet og prioriteres ind i sprint/release alt efter bemanding
3 - Middel
Tildelt til udvikler og løses ved ledig kapacitet
4 - Lav
Løses ved rettelser i samme kodeområde
Når en bruger i dag opretter en sag i Manuscript vil Systemforvalter (SF), der modtager sagen, foretage den første vurdering af henvendelsen. Det er vigtigt at SF har den nødvendige information til at vurdere, hvor hurtigt fejlen skal rettes, og til at videregive sagen til den rette team (se guide til oprettelse af sag).
Efter SF´s indledende visitering, vil kritiske fejl blive sendt til analyse af en medarbejder hos den relevante leverandør, som vil fastlægge dens endelige kategorisering og betydning. I tilfælde af ændring af sagens prioritet, vil dette ske efter aftale med sagsopretter. Fejlens karakter og omfang vil være afgørende for, i hvilken rækkefølge, og med hvor kort tidsperspektiv, sagen vil blive rettet. Formålet med den korrekte kategorisering af sagerne, er at sikre, at vi prioriterer og retter de vigtigste fejl først. Derudover bliver det muligt, at planlægge fejlrettelser i større klumper, og idriftsætte dem sammen med de officielle releases. En release indeholder således både nyudviklet funktionalitet og fejlrettelser.
Formålet med planlægning af fejlrettelser over en længere periode (mellem hver release) er, at udviklerne får dedikeret tid til at løse fejl. Derved vil effektiviteten stige, eftersom de ikke-akutte sager ikke i samme omfang, afbryder et kontinuerligt flow i fejlretning.
Fordelen for brugerne er, at de vigtigste fejl bliver rettet i den rækkefølge der giver mest værdi. Derudover vil det være muligt tidligere at give brugere information om, hvornår fejlrettelsen forventes idriftsat.