Her er rapporterne, der dumpede Politiets skandaleramte Polsag-system

23. januar 2013 kl. 11:2715
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.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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.

Artiklen fortsætter efter annoncen

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:

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.

Remote video URL
Remote video URL
Remote video URL
Remote video URL
Remote video URL
Remote video URL

15 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
12
24. januar 2013 kl. 11:58

Dårlig kode fra leverandører eller dårlig offentlig styring?

14
24. januar 2013 kl. 14:08

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?

15
28. januar 2013 kl. 11:46

Du har fuldstændig ret Bjørn

80% egenudvikling og 20% standardsystem

Man tog simpelthen Scanjour/Captia, som kunne en brøkdel af det man skulle bruge, og så prøvede man at bygge et GIGANT højhus oven på det lille skrøbelige fundament. Og nej, det gik selvsagt ikke godt.

13
24. januar 2013 kl. 14:04

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.

10
24. januar 2013 kl. 00:47

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.

9
23. januar 2013 kl. 21:03

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

5
23. januar 2013 kl. 12:23

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 :)

6
23. januar 2013 kl. 12:33

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)

3
23. januar 2013 kl. 12:13

jo der er en download hvis du går ind på script også logger ind med bugmeno f.eks.

1
23. januar 2013 kl. 11:55

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
23. januar 2013 kl. 12:38

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 ...

4
23. januar 2013 kl. 12:20

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.