Her er rapporterne, der dumpede Politiets skandaleramte Polsag-system

Illustration: REDPIXEL.PL/Bigstock
Læs hvorfor Rigspolitiet og Justitsministeriet droppede Polsag-systemet, efter at have brugt en halv milliard kroner på at få det udviklet. Her er de hidtil hemmelige rapporter, der vurderer CSC's kodearbejde og økonomien i projektet.

Da Rigspolitiet for knap et år siden kasserede det store Polsag-projekt, der på det tidspunkt havde kostet skatteyderne over en halv milliard kroner, var begrundelsen, at Polsag ikke var godt nok, og at det ville være for dyrt at rette op på systemet, som CSC leverede.

Men de eksterne evalueringer, som førte til den konklusion, blev holdt hemmelige. Først med den begrundelse, at det ville skade forhandlingerne med CSC om et forlig. Men da forliget med CSC faldt på plads i juni 2012, blev forklaringen i stedet, at det tog noget tid at gå igennem de mange dokumenter. Hver sjette uge sendte ministeriet og Rigspolitiet så en standardbesked om, at sagen stadig var under behandling.

Version2 søgte aktindsigt i rapporterne allerede i efteråret 2010 og har siden da løbende fulgt op med nye aktindsigtsanmodninger og rykkere på henvendelserne, som offentlige institutioner ifølge loven skal behandle i løbet af højst to uger.

I stedet kom det til at tage over et år. Først fredag den 21. december, få minutter før fyraften og juleferie, sendte Justitsministeriet rapporterne til Version2 og andre medier, som havde søgt aktindsigt. Det blev til følgende artikler om Polsag-skandalen:

Læs også: Hemmelig rapport afslører CSC's og Scanjours katastrofale Polsag-kode

Læs også: Derfor blev Polsag skrottet: Ville koste 1,4 milliarder kroner

Læs også: Politiets analoge papirnusseri koster 100 millioner kroner ekstra om året

Her kan du læse alle rapporterne, som fældede Polsag. Dokumenterne er fra Justitsministeriets side printet ud og scannet ind igen - et trick der skal forhindre journalister og andre i at fritekstsøge i dokumenterne.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lasse Lindgård

Dokumenterne er fra Justitsministeriets side printet ud og scannet ind igen - et trick der skal forhindre journalister og andre i at fritekstsøge i dokumenterne.

Man skal ikke tilskrive ondskab til noget, som kan forklares med inkompetence. ;-)

  • 7
  • 1
Torben Mogensen Blogger

Enig. Hvis dokumentværktøjet ikke direkte har en "eksport til PDF" knap, er der mange, der vælger at skrive ud og scanne med en scanner, der kan e-maile resultatet som en PDF -- hvad mange scannere nu om dage kan.

  • 1
  • 0
Thomas Schmidt

Jeg stod næsten af da jeg nåede til "over halvdelen af POLSAGs kodebase er javascript"..

Må lige nærlæse det hele lidt senere, men det lyder ikke helt som om det udvildige firma har styr på unit tests, lyder som om de mener at mængden af unit tests er afgørende (f.eks. 20 unit tests på en klasse med 10 metoder) fremfor f.eks. hvor stor % code coverage der er eller en anden måle metode, men antal unit test afspejler næppe kvaliteten af produktet.

Nå det bliver spændende læsning senere på dagen :)

  • 1
  • 0
Morten Wegelbye Nissen

Må lige nærlæse det hele lidt senere, men det lyder ikke helt som om det udvildige firma har styr på unit tests, lyder som om de mener at mængden af unit tests er afgørende (f.eks. 20 unit tests på en klasse med 10 metoder) fremfor f.eks. hvor stor % code coverage der er eller en anden måle metode, men antal unit test afspejler næppe kvaliteten af produktet.

Husk inden du laver konklusioner på sådan noget at analysen bliver nød til at opstille generelle krav. Jeg syntes ikke deres krav, overordnet set, er helt forkert. (10 metoder plus triangulering bør i snit give omkring 20 unit tests.) Mængden af unittests eller code coverage kan IMHO ikke stå alene. Jeg har dælme set mange bemærkelsesværdige unittests der alene har til formål at få code coverage op. (Ak ak, den slags sker når handelsskoleelever vil have KPI'er)

  • 4
  • 0
Jørn Wildt

Der er også andre, mere valide årsager, til at printe og gen-indscanne - så er man helt sikker på 1) at der ikke siver noget meta data fra det oprindelige dokument ud (som f.eks. revisionssporet og forfatternavne), og 2) sorte overstregninger kan ikke fjernes, hvilket der har været eksempler på tidligere hvor man havde brugt et værktøj til at lave sorte overstregninger direkte i en PDF ...

  • 6
  • 0
Jesper Frimann

Nu har jeg skrevet en hel del af den her type rapporter. Det må da være første gang i mine snart 20 år i branchen, jeg har set et uddannelses system brugt til performance evaluering. Det virker jo helt hul i hovedet.

Og når man så læser: "Den opfølgende performanceanalyse i performancetestmiljøet indikerer, at der er sket en væsentlig forbedring i svartider og ydeevne. Leverandøren har oplyst, at problemerne i forhold til skalerbarhed og stabilitet også skulle være løst samt at der er gennemført optimeringer i forhold til døgnrapporten. Der vurderes dog, at være en høj grad af usikkerhed forbundet med hvilke resultater leverandøren reelt har opnået, samt om de er tilvejebragt på en måde, som kan overføres til Rigspolitiets produktionsmiljøer."

Så performance test udført i uddannelsesmiljøet, er mere valide end test udført i performance test miljøet ? Det giver .. meget lidt mening.

Tja ja.. Hvad var det Mogens Nørdskov kaldte de her rapporter ?

// Jesper

  • 2
  • 0
Kristoffer Søholm

Det er ret trist at de har overstreget al koden med en sort tusch, jeg ville godt have set hvor slemt det stod til med egne øjne.

De vil nok påstå det er pga. deres "copyright" at det er blevet gjort, men jeg tror også at de måske ikke er helt stolte over at vise deres arbejde frem.

  • 1
  • 0
Martin Eriksen
  • 0
  • 0
Henrik Korsgaard

Styring er vel et spørgsmål om tillid i kontraktmæssig forstand. Hvis ikke der er indskrevet fornuftige del-test eller lignende undervejs - hvilket jeg antager der ikke er, siden der csc ikke er konsekvente omkring test på koden - så er det svært at styre. Det er svært at 'styre' noget man ikke kender i detaljen og er udenfor egen organisation. Det er en opgave for kontraktforhandling og del-leverancer. Så min omformulering af dit relevante spørgsmål vil være:

Er det et spørgsmål om dårlig kode og/eller dårlige kontrakter/projektrammer?

Men, dårlige kontrakter eller kravsspecifikationer udelukker ikke en håndværksmæssig stolthed. Jeg synes det er skræmmende med det lave testniveau og den komplekse kodebase. Uanset kontrakten, så er det vel et spørgsmål omkring faglighed.

  • 0
  • 0
Bjørn Anker-Møller

Den reelle årsag skal man efter min mening ikke analysere kodekvalitet eller performance for at finde. I rapporten fra Boston Consulting Group står det jo allerede i indledningen.

Politiets udbud gik på en løsning baseret på et FESD-standardsystem, men i realiteten blev det til 80% egenudvikling og 20% standardsystem.

Man krævede at Polsag skulle levere præcis den samme funktionalitet som det gamle Polsas-system, det såkaldte "1:1 krav". Dette skyder enhver intention om brug af et standard-system i sænk, og det giver samtidig et skræmmende indtryk af Politiets holdning til projektet.

I overensstemmelse af at intet skulle ændres (jf. ovenstående) betragtede man projektet som et infrastruktur-projekt.

Min konklusion er at ingen leverandør kunne have leveret under disse betingelser. Projektet var dømt til at fejle fra dag 1, da det var startet med den fejlagtige antagelse at det var et implementeringsprojekt for et standardsystem - og ikke en egenudviklet løsning. Hele diskussionen om kodekvalitet og performance har således intet at gøre med den fundamentale årsag, men lægger et røgslør som nogen måske er glade for?

  • 3
  • 0
Log ind eller Opret konto for at kommentere