Lemmaspor
Eksempel · fiktivt tilfældeIndikation, ikke revision

Sagsportalen, Nordby Kommune

Levering
6 · 12. oktober 2026
Sammenlignet med
Levering 5 · 14. august 2026
Materiale
Backend-kode (1.208 filer) og tre dokumenter
Gemt hos Lemmaspor
Intet. Denne fil er den eneste kopi.

Overblik

Niveau: Forhøjet
  • 2 Advarsel
  • 5 Bemærkning

To fund kræver en beslutning denne måned: F-01 og F-02.

Siden levering 5: 1 ny · 1 forværret · 5 uændrede · 1 rettet

Rapporten har syv fund. De fire vigtigste står på den korte rapport. Her står alle syv, med beviser, grupperet efter hvad de handler om: er det leveret som aftalt, er der sikkerhedsproblemer, og kan en anden overtage.

Alle fund, i den rækkefølge de er rangeret. Rangeringen er forklaret i afsnit 7.
FundHvadLinseNiveauHvor sikre er viSiden sidst
F-01Et krav, I har betalt for, ser ikke ud til at være byggetIkke som aftaltAdvarselHøjÅben siden levering 4
F-02Adgangskoder ligger åbent i kodenSikkerhedAdvarselHøjNy
F-03Systemet hviler på leverandørens egen, lukkede værktøjskasseOvertagelseBemærkningMiddelUændret
F-04De mest følsomme dele er næsten ikke testetOvertagelseBemærkningLav til middelUændret
F-05Ændringer logges uden at sige, hvem der lavede demSikkerhedBemærkningHøjUændret
F-06Elleve af 58 eksterne pakker er mere end to år bagudOvertagelseBemærkningHøjForværret: 8 → 11
F-07Ca. 14 % af sagsbehandlingen ser ikke ud til at blive brugtOvertagelseBemærkningMiddelUændret

Sådan bruger I rapporten

  • Ledelsen

    Læs dette afsnit og den korte rapport. Tag spørgsmålene i afsnit 8 med til statusmødet.

  • En tekniker eller konsulent

    Læs afsnit 2 til 4 og 7. Hvert fund har sit bevis, så det kan efterprøves. Afsnit 8 har en liste over, hvad der bør undersøges først.

  • Leverandøren

    Fundene er formuleret som spørgsmål. Afsnit 5 viser, hvad vi har undersøgt og afvist, så ingen skal forklare noget, der ikke er et problem.

Leveret mod bestilt

Her følger rapporten jeres egen kravspecifikation (v2.1, kapitel 4 til 7). Hvert af de 31 krav er sammenholdt med koden. Det er det afsnit, ingen andre værktøjer kan lave, fordi de ikke kender jeres aftale.

«Fundet» siger, at der findes kode, som gør det, kravet beskriver. Det siger ikke, at den gør det godt.

De ni krav, der ikke er fuldt opfyldt

Krav sorteret efter nummer.
KravKravet sigerVi fandtStatusHvor sikre er vi
4.3Sagsbehandleren kan se hele sagens historikHistorikken viser kun de seneste 50 poster. Ældre poster ligger i databasen, men kan ikke ses (src/Sag/SagHistorik.cs:33).DelvistHøj
4.7Afgørelser sendes automatisk til borgerens digitale postkasseKun en tom funktion. Se F-01.Ikke fundetHøj
4.9Borgeren kan trække en ansøgning tilbageIntet endepunkt og ingen status «tilbagetrukket» i databasen. Frontend var ikke med, men uden endepunkt kan en skærm ikke gøre noget.Ikke fundetMiddel
5.2Sagsbehandler og leder har forskellige rettighederBegge roller har samme rettigheder i koden (src/Adgang/Roller.cs:12–29). Rettigheder kan også styres i en ekstern brugerkatalog, som vi ikke har set.DelvistMiddel
5.4Alle ændringer af en sag logges med bruger og tidspunktTidspunkt og sagens id logges. Brugeren logges ikke. Se F-05.Anderledes end kravetHøj
6.4Borgeren får kvittering, når en ydelse er udbetaltKvitteringen vises som skærmbesked. Den sendes ikke til borgeren.DelvistMiddel
6.6Månedlig afstemning mellem sagssystem og økonomisystemIngen kode fundet. Funktionen kan ligge i økonomisystemet, som ikke var med i materialet.Ikke fundet i materialetLav til middel
7.3Driftsdokumentation, også fejlsøgning og genetableringInstallationsvejledning findes (docs/install.md). Fejlsøgning og genetablering mangler.DelvistHøj
7.5Systemet kan bygges ud fra kildekoden med en byggebeskrivelseVi har ikke bygget systemet. Tre af leverandørens egne komponenter findes kun som færdige filer. Se F-03.Kan ikke vurderesUkendt

De 22 krav, der blev fundet

  • 4.1Borgeren kan oprette en ansøgning online
  • 4.2Borgeren logger ind med MitID
  • 4.4Borgeren kan vedhæfte dokumenter
  • 4.5Borgeren kan følge sagens status
  • 4.6Borgeren får besked ved statusskift
  • 4.8Ansøgningen kan gemmes som kladde
  • 5.1Borgeren kan kun se egne sager (kontrolleret, se afsnit 5)
  • 5.3Sagsbehandleren kan give en sag videre til en kollega
  • 5.5Afgørelser kan godkendes af en leder
  • 5.6Sager kan sendes i partshøring
  • 5.7Sagsbehandleren kan søge i sager
  • 6.1Ydelser beregnes efter gældende takster (næsten utestet, se F-04)
  • 6.2En beregning kan ses trin for trin på en lukket sag
  • 6.3Udbetalinger godkendes af to personer
  • 6.5En udbetaling kan stoppes, før den sendes
  • 6.7Udbetalingsfiler gøres klar til økonomisystemet
  • 6.8Tilbagebetalingskrav kan oprettes
  • 7.1Fejl skrives til en central log
  • 7.2Systemets tilstand kan overvåges
  • 7.4Alle ændringer i koden kan spores i versionsstyring
  • 7.6Tekster kan rettes uden en ny udgivelse
  • 7.7Systemet kan sættes op til test og produktion
F-01AdvarselIkke som aftaltÅben siden levering 4Høj

Et krav, I har betalt for, ser ikke ud til at være bygget

Hvad er galt
Krav 4.7 siger, at afgørelser sendes automatisk til borgerens digitale postkasse. I koden findes kun en tom funktion med det rigtige navn. Den bliver kaldt, men den gør ingenting.
Hvorfor det betyder noget
Kravet indgår i milepæl 3, som er markeret betalt i milepælsplanen. Hvis funktionen ikke findes, har I betalt for noget, I ikke har fået, og sagsbehandlerne sender stadig breve i hånden.
Hvor sikre er vi
Høj. Vi har ledt efter funktionen og efter spor af en anden måde at sende på. Der er ingen af dem.
Hvad kan få os til at tage fejl
Afsendelsen kan ske i et system uden for materialet. Vi har ikke set spor af det, men frontend og drift var ikke med.
Spørg leverandøren
«Vis mig, hvor en afgørelse sendes til borgerens digitale postkasse. Kan I vise det med en rigtig sag?»
Teknisk bevistil konsulent eller leverandør
Fundet i
src/Afgoerelse/DigitalPostService.cs, linje 38–42
Kaldt fra
src/Afgoerelse/AfgoerelseController.cs, linje 112. Kaldet giver indtryk af, at det virker, og giver hverken fejl eller log.
Mangler
Ingen indstilling for adresse, certifikat eller afsender i appsettings*.json. Ingen pakke til at sende digital post i låsefilen.
Historik
Metoden er uændret siden levering 4 (commit 7be1d90, 27. maj 2026).
Aftalegrundlag
Kravspecifikation v2.1, krav 4.7. Milepælsplan (bilag 3), milepæl 3 «Afgørelsesmodul», markeret betalt.
Metode
Værktøj (kaldegraf: tom metode, der kaldes) og AI-læsning af kravet. Tre af tre uafhængige gennemgange er enige.
src/Afgoerelse/DigitalPostService.cs
 38  public Task SendTilDigitalPost(Afgoerelse afgoerelse)
 39  {
 40      // TODO: implementeres i næste sprint
 41      return Task.CompletedTask;
 42  }

Sikkerhed

Her står de fund, der handler om, hvem der kan komme til jeres og borgernes oplysninger, og om I kan se, hvad der er sket. Alt, hvad værktøjet kan fastslå uden at gætte, er fastslået af værktøjet.

F-02AdvarselSikkerhedNy siden levering 5Høj

Adgangskoder ligger åbent i koden

Hvad er galt
Tre koder står i klar tekst i konfigurationsfiler: én adgangskode til sagsdatabasen, én nøgle til tjenesten, der sender beskeder til borgerne, og én adgangskode til en testdatabase. Alle med adgang til koden kan læse dem.
Hvorfor det betyder noget
Med databasekoden kan man læse og ændre borgernes sagsoplysninger, hvis man også kan nå databasen. Med nøglen kan man sende beskeder i jeres navn. Koderne ligger også i versionshistorikken, så de kan læses, selv hvis filerne rettes nu. Er koden delt uden for kredsen, kan det være et brud på persondata.
Hvor sikre er vi
Høj. Det er direkte læsbart i filerne. Vi har ikke prøvet koderne af og vil aldrig gøre det.
Hvad kan få os til at tage fejl
Koderne kan være skiftet efter levering 6, eller de gælder kun et testmiljø. Filnavnet siger «Production», men det er ikke bevis.
Spørg leverandøren
«Er koderne skiftet, og hvordan opbevarer I fremover hemmeligheder uden for koden?»
Teknisk bevistil konsulent eller leverandør
Fundet i
config/appsettings.Production.json, linje 14 og 31. deploy/docker-compose.yml, linje 22.
Tilføjet
Commit a3f9c21, 29. september 2026, altså efter levering 5.
Værdierne
Skjult i jeres browser, før materialet blev sendt. De gengives ikke i denne rapport.
Metode
Værktøj (hemmelighedsscanner: mønster og tilfældighedstest). Kan gentages. Tre af tre uafhængige gennemgange bekræfter fundene.
config/appsettings.Production.json
 12  "ConnectionStrings": {
 13    "Sagsdatabase": "Host=db-prod;Database=sag;User=sag_app;
 14                    Password=[SKJULT 1 af 3]"
 15  },
 30  "Beskedtjeneste": {
 31    "ApiNoegle": "[SKJULT 2 af 3]"
 32  }

deploy/docker-compose.yml
 22  POSTGRES_PASSWORD: [SKJULT 3 af 3]

Fund under den korte rapports grænse

F-05BemærkningSikkerhedUændret siden levering 5Ikke på den korte rapportHøj

Ændringer logges uden at sige, hvem der lavede dem

Hvad er galt
Krav 5.4 siger bruger og tidspunkt. Koden gemmer tidspunkt og sagens id, men ikke hvem.
Hvorfor det betyder noget
Ved mistanke om fejl eller misbrug kan I ikke se, hvem der ændrede en sag. Det gør det svært at dokumentere, hvem der har behandlet en borgers oplysninger.
Hvor sikre er vi
Høj. Logningen er læst direkte i koden.
Hvad kan få os til at tage fejl
Brugeren kan blive logget et andet sted, fx i en samlet logtjeneste, som ikke var med.
Spørg leverandøren
«Hvorfor logges brugeren ikke, som krav 5.4 beskriver, og hvornår bliver det rettet?»
Teknisk bevistil konsulent eller leverandør
Fundet i
src/Log/AuditLog.cs, linje 21–38. Posten har felterne Tidspunkt og SagId.
Metode
Værktøj (statisk læsning af logposten) og AI-læsning af kravet. Tre af tre gennemgange er enige.

Kan en anden overtage?

En anden leverandør skal kunne overtage systemet uden at starte forfra. Fem spørgsmål, vi stiller til koden:

  1. Er al kildekode med?

    Næsten. Tre af leverandørens egne komponenter findes kun som færdige filer. F-03

  2. Kan systemet bygges fra bunden?

    Kan ikke vurderes. Vi har ikke bygget det (krav 7.5).

  3. Er det dokumenteret?

    Delvist. Installationsvejledning findes. Arkitektur, fejlsøgning og genetablering mangler (krav 7.3).

  4. Er det testet, så en ny leverandør tør røre ved det?

    Næsten ikke i de følsomme dele. F-04

  5. Er det bygget på standardteknologi?

    Ja. Systemet bruger udbredte teknologier (.NET 8 og PostgreSQL) og offentlige pakker ud over leverandørens tre egne.

Samlet billede: en ny leverandør kan nok overtage systemet, men ikke uden at bruge penge på at forstå leverandørens egne komponenter og på at få styr på testene. Det er et skøn, ikke en dom.

F-03BemærkningOvertagelseUændret siden levering 5Middel

Systemet hviler på leverandørens egen, lukkede værktøjskasse

Hvad er galt
Tre komponenter (lev.kerne, lev.workflow og lev.formular) leveres kun som færdige filer. Omkring hvert tredje kald i forretningslogikken (412 af 1.208) går gennem dem. De er ikke dokumenteret.
Hvorfor det betyder noget
En ny leverandør skal lære komponenterne at kende uden at kunne læse dem, eller bygge det hele om. Begge dele koster penge og svækker jeres forhandlingsposition, når kontrakten skal fornyes.
Hvor sikre er vi
Middel. Afhængighederne er læst direkte. Vi kan ikke se, hvad kontrakten siger om rettigheder. Én af tre gennemgange vurderede komponenterne som mindre centrale, og uenigheden er grunden til, at vi siger Middel.
Hvad kan få os til at tage fejl
Kontrakten kan give jer ret til kildekode, deponering eller dokumentation. Kontraktens hovedtekst var ikke med.
Spørg leverandøren
«Hvilke dele er jeres egne komponenter, og hvor står det i kontrakten, at vi får kildekode og dokumentation?»
Teknisk bevistil konsulent eller leverandør
Fundet i
libs/lev.kerne.dll, libs/lev.workflow.dll og libs/lev.formular.dll. Færdigbyggede filer, ingen kildekode i materialet.
Omfang
412 af 1.208 kald i src/Forretning/ går gennem dem (afhængighedskort).
Findes andre steder?
Ingen af de tre findes på offentlige pakkeservere (søgt på navn).
Dokumentation
Ingen README og ingen API-beskrivelse i docs/.
Metode
Værktøj (afhængighedskort, kald talt) og AI-vurdering af, hvor bærende komponenterne er. To af tre gennemgange er enige.
src/Forretning/Sagsflow.cs
 88  var trin = await _kerne.Workflow.NaesteTrin(sag);   // lev.workflow
 91  _kerne.Formular.Valider(sag.Ansoegning);             // lev.formular
 97  await _kerne.Kerne.Gem(sag);                         // lev.kerne
F-04BemærkningOvertagelseUændret siden levering 5Lav til middel

De mest følsomme dele er næsten ikke testet

Hvad er galt
Systemet har 214 automatiske tests. Tre af dem rører koden, der beregner og udbetaler ydelser (src/Ydelse/, 24 filer, 1.860 linjer).
Hvorfor det betyder noget
Hver ændring dér bliver en lodtrækning. Fejl opdages af sagsbehandlere eller borgere i stedet for af leverandøren, og så er regningen jeres. Det kan være en del af forklaringen på, at ændringer i den del er dyre.
Hvor sikre er vi
Lav til middel. Vi har ikke kørt testene. Tallene viser, hvilke tests der peger på hvilken kode. Leverandøren kan teste på måder, vi ikke kan se i koden.
Hvad kan få os til at tage fejl
Der kan ligge tests i et andet system, eller beregningen kan være afprøvet i hånden. Så er den ikke automatisk beskyttet, men den er ikke uprøvet.
Spørg leverandøren
«Hvordan sikrer I, at ændringer ikke ødelægger ydelsesberegningen? Kan I vise de seneste tre leverancers testresultater?»
Teknisk bevistil konsulent eller leverandør
Fundet i
tests/: 214 tests i 61 filer. Tre rører src/Ydelse/, alle i tests/Ydelse/BeregningTests.cs.
Ikke rørt af nogen test
Tillæg (6 regler), takstskift pr. 1. januar og modregning.
Metode
Værktøj (kobling mellem tests og kode ud fra testenes henvisninger) og AI-vurdering af, hvad modulet gør. To af tre gennemgange er enige.
tests/Ydelse/BeregningTests.cs
 14  [Fact] Beregner_grundydelse_for_enlig
 27  [Fact] Beregner_grundydelse_for_par
 41  [Fact] Afrunder_til_hele_kroner

Fund under den korte rapports grænse

F-06BemærkningOvertagelseForværret: 8 → 11Ikke på den korte rapportHøj

Elleve af 58 eksterne pakker er mere end to år bagud

Hvad er galt
11 af 58 eksterne pakker har fået nyere udgaver, siden de blev valgt for mere end to år siden. Ved levering 5 var det 8. Ingen af dem har kendte sårbarheder i dag.
Hvorfor det betyder noget
Det er ikke et hul i dag. Men hver udsat opdatering gør den næste større og dyrere, og en ny leverandør arver efterslæbet.
Hvor sikre er vi
Høj. Låsefilerne er læst direkte, og antal og alder kan kontrolleres.
Hvad kan få os til at tage fejl
Nogle pakker kan være bevidst holdt tilbage af en god grund. Det står ikke i materialet.
Spørg leverandøren
«Hvad er planen for at holde pakkerne opdateret, og hvem betaler for det?»
Teknisk bevistil konsulent eller leverandør
Fundet i
src/packages.lock.json. Listen over de 11 pakker følger i den tekniske pakke.
Metode
Værktøj (låsefil sammenholdt med udgivelsesdatoer). Kan gentages.
F-07BemærkningOvertagelseUændret siden levering 5Ikke på den korte rapportMiddel

Ca. 14 % af sagsbehandlingen ser ikke ud til at blive brugt

Hvad er galt
Omkring 1.700 af 12.100 linjer i sagsbehandlingsmodulet bliver ikke kaldt af noget andet i koden.
Hvorfor det betyder noget
I betaler for at vedligeholde kode, der ikke bruges, og en ny leverandør skal læse den for at finde ud af, at den kan ignoreres.
Hvor sikre er vi
Middel. Kaldegrafen viser, at ingen kalder koden.
Hvad kan få os til at tage fejl
Kode kan kaldes via konfiguration eller udefra, som værktøjet ikke kan følge. Det kan kun afgøres ved at køre systemet. Se afsnit 5.
Spørg leverandøren
«Kan I bekræfte, hvilke dele af sagsbehandlingen der ikke bruges, og tage dem ud?»
Teknisk bevistil konsulent eller leverandør
Fundet i
src/Sag/: 41 af 312 metoder uden kald.
Metode
Værktøj (kaldegraf). Kan gentages, men afgør ikke, om koden bruges udefra.

Undersøgt og afvist

Før vi skriver et fund, prøver en skeptisk gennemgang at afvise det. Her er det, vi undersøgte og ikke kunne holde fast i. Havde vi skrevet, at borgere kan se andres sager, uden at det var rigtigt, havde vi spildt jeres tid og leverandørens tillid.

A-1AfvistSikkerhedHøj

«Borgere kan se andres sager ved at ændre et nummer i adressen»

Hvorfor vi undersøgte det
Det er en udbredt svaghed i sagssystemer, og krav 5.1 siger, at borgeren kun må se egne sager.
Hvad vi fandt
Alle seks endepunkter, der henter en sag, tjekker på serveren, at sagen tilhører den loggede borger (src/Sag/SagController.cs, linje 58, 91, 124, 160, 203 og 247).
Metode
Værktøj (alle endepunkter fundet og læst) og AI-læsning. Tre af tre gennemgange er enige.
A-2Afvist, med forbeholdSikkerhedMiddel

«Systemet sender data til en ukendt adresse uden for jeres net»

Hvorfor vi undersøgte det
Et udgående kald til en ukendt adresse kan være et dataudslip.
Hvad vi fandt
Der er ét kald til en adresse uden for jeres net (src/Drift/Telemetri.cs, linje 19–34). Adressen er leverandørens egen driftsovervågning og står i løsningsbeskrivelsen, kapitel 3.2. Kaldet sender tekniske målinger, ikke sagsdata.
Forbehold
Vi har set, hvad koden sender, ikke hvad der modtages eller gemmes.
Metode
Værktøj (alle udgående kald fundet) og AI-sammenligning med løsningsbeskrivelsen. To af tre gennemgange er enige.
A-3Ikke afgjortOvertagelseUkendt

«En del af betalingsmodulet er ubrugt kode»

Hvad vi fandt
Kaldegrafen viser ingen kald til to klasser i betalingsmodulet. Men modulet henter nogle regler via konfiguration, og det kan værktøjet ikke følge.
Hvorfor det står her
Det kan kun afgøres ved at køre systemet. Vi skriver det ikke som fund. Samme forbehold gælder F-07.

Siden sidst

Sammenlignet med levering 5 (kørt 14. august 2026). Det er den sammenligning, I ikke kan se i et statusmøde.

Ændringer siden forrige kørsel.
Siden sidstFundHvad skete der
NyF-02Tre koder lagt i konfigurationen 29. september 2026.
ForværretF-06Pakker mere end to år bagud: 8 ved levering 5, 11 nu.
UændretF-01, F-03, F-04, F-05, F-07Ingen ændring siden levering 5. F-01 har været åben siden levering 4.
RettetFra levering 5Et forældet login-bibliotek med en kendt sårbarhed er opgraderet fra version 4.2 til 4.9.

Kravspecifikationen, levering 5 mod levering 6

Levering 5
Levering 6

To krav er kommet til siden sidst: 4.6 (besked ved statusskift) og 6.7 (udbetalingsfiler). Antallet af fund er det samme, syv mod syv, men det er ikke de samme syv.

Materiale, metode og begrænsninger

Hvad vi fik

  • KodeBackend (.NET 8): 1.208 filer læst.
  • DokumenterKravspecifikation v2.1 (31 krav i kapitel 4 til 7), løsningsbeskrivelse v1.4 og milepælsplan (bilag 3).
  • Ikke modtagetFrontend-kode, drift og infrastruktur, kontraktens hovedtekst og økonomisystemets kode.

Hvad vi fjernede, før noget blev sendt

Det er gjort i jeres browser, så det forlod aldrig jeres computer.

  • 48.312 filer fjernet41.906 installerede biblioteker, 5.902 byggefiler og 504 billeder og andre binære filer.
  • 1.208 filer beholdtHerunder låsefilerne, som bruges til at se, hvilke pakker systemet bygger på.
  • 3 adgangskoder og nøgler skjultFilerne blev beholdt, værdierne erstattet. De tre er det, F-02 handler om.

Hvad der er gjort af hvad

Af værktøj (kan gentages)

  • Søgning efter adgangskoder og nøgler
  • Kontrol af pakker og låsefiler
  • Kaldegraf: tomme og ubrugte metoder
  • Kobling mellem tests og den kode, de rører

Et fund, værktøjet har fastslået, kan en anden køre igen og få det samme.

Af AI (vurdering)

  • At finde, hvor et krav hører hjemme i koden
  • At vurdere, hvad et fund betyder i penge og risiko
  • At skrive det på almindeligt dansk

Tre uafhængige gennemgange har kigget på materialet, og en skeptisk gennemgang har prøvet at afvise hvert fund (afsnit 5).

AI-vurderingerne er kørt hos jeres egen AI-udbyder. Lemmaspor har ikke gemt noget, men udbyderens egne regler for opbevaring gælder. De skal jeres databeskyttelsesrådgiver kende.

Hvor sikre er vi: skalaen

Høj
Vi har set det direkte i materialet, og værktøjet og mindst to gennemgange er enige.
Middel
Billedet er tydeligt, men noget mangler, før vi kan være sikre.
Lav til middel
Det kan være rigtigt, men der er rimelige forklaringer, vi ikke kan afvise.
Ukendt
Vi kan ikke afgøre det med det materiale, vi har. Det er i sig selv værd at spørge om.

Sådan er fundene rangeret

Først efter konsekvens i penge og risiko, derefter efter hvor sikre vi er. Derfor står F-03 (Middel) over F-05 (Høj): hvis det er rigtigt, koster det mere at være låst til én leverandør, end det koster, at en logpost mangler et navn.

Hvad vi ikke har set på

  • Vi har ikke kørt systemet. Vi har kun læst koden.
  • Frontend, drift og servere var ikke med. Derfor kan vi ikke sige, at noget mangler eller er ubrugt, hvis det kan ligge dér. Det gælder krav 4.9 og 6.6 og F-07.
  • Kontraktens hovedtekst var ikke med. Rettigheder til kildekode er derfor ikke vurderet (F-03).
  • Vi har ikke prøvet de tre koder af og vil aldrig gøre det.
  • Ingen fund i et område er ikke det samme som, at området er i orden. Det betyder kun: ingen fund i det materiale, vi har analyseret.

Giv det videre

Til en tekniker eller konsulent

Fem ting at se på, i den rækkefølge de betyder mest:

  1. Digital post. Få vist, at en afgørelse sendes fra systemet til en postkasse i et testmiljø (F-01, krav 4.7).
  2. De tre koder. Bekræft, at de er skiftet, at de gamle ikke virker, og at versionshistorikken er gennemgået for flere (F-02).
  3. Rettigheder. Læs kontraktens afsnit om kildekode, dokumentation og deponering for leverandørens tre komponenter (F-03).
  4. Ydelsesberegningen. Få testresultaterne og afprøv de mest følsomme regler (F-04).
  5. Det, vi ikke har set. Frontend og drift, især tilbagetrækning (krav 4.9) og afstemning (krav 6.6).

Til leverandøren: spørgsmålene samlet

Kopiér listen ind i en mail. Bed om skriftlige svar, før levering 6 godkendes.

  1. F-01
    «Vis mig, hvor en afgørelse sendes til borgerens digitale postkasse. Kan I vise det med en rigtig sag?»
  2. F-02
    «Er koderne skiftet, og hvordan opbevarer I fremover hemmeligheder uden for koden?»
  3. F-03
    «Hvilke dele er jeres egne komponenter, og hvor står det i kontrakten, at vi får kildekode og dokumentation?»
  4. F-04
    «Hvordan sikrer I, at ændringer ikke ødelægger ydelsesberegningen? Kan I vise de seneste tre leverancers testresultater?»
  5. F-05
    «Hvorfor logges brugeren ikke, som krav 5.4 beskriver, og hvornår bliver det rettet?»
  6. F-06
    «Hvad er planen for at holde pakkerne opdateret, og hvem betaler for det?»
  7. F-07
    «Kan I bekræfte, hvilke dele af sagsbehandlingen der ikke bruges, og tage dem ud?»

Næste kørsel

Kør Lemmaspor igen ved levering 7. Upload denne fil sammen med den nye kode, så sammenligner vi. Lemmaspor har ikke gemt noget, så filen her er jeres hukommelse.

  • lemmaspor-nordby-lev6.htmlDenne rapport. Én fil, ingen eksterne henvisninger.
  • lemmaspor-nordby-lev6.pdfSamme rapport til udskrift.
  • lemmaspor-nordby-lev6.jsonMaskinlæsbar udgave til næste sammenligning.

Om rapporten

Det her er en indikation af det materiale, der blev delt, ikke en revision, ikke juridisk rådgivning og ikke en garanti. Et fund betyder, at noget bør undersøges. «Ingen fund» betyder ingen fund i det analyserede materiale, ikke at noget er sikkert eller i orden.

Rapporten bygger på materiale, som Nordby Kommune har bekræftet, at den har ret til at dele med Lemmaspor. Lemmaspor har ikke gemt jeres kode eller dokumenter. Denne fil er den eneste kopi.

Eksemplet er konstrueret til at vise formatet. Ingen rigtige leverandører, kunder eller systemer.

Prøv med én rapport