Konklusion af Polsag-review fra 2009: Elendig kode hånd i hånd med elendig kontrakt

Afsløring: Der var allerede i 2009 ’betydelig risiko’ for, at Polsag-systemet ville blive plaget af performance-problemer. Men ordentlige svartider fra systemet var ikke inkluderet i konktrakten, viser ekstern konsulentrapport.

Det skortede ikke på advarsler, da den første store gennemgang af det nu skrottede Polsag var klar i august 2009.

Hvor kritikken i den slags konsulentrapporter normalt er holdt i et afdæmpet sprog, var der her ikke tvivl om, hvad evalueringen havde vist. Polsag var et usundt system, og fortsatte leverandørerne CSC og Scanjour på samme måde, uden at rette op på problemerne, ville det give ballade.

Det fremgår af rapporten med titlen Eksternt review af Polsag-programmet. Det er lykkedes Version2 af få fat i et eksemplar, selv om Justitsministeriet ellers angiveligt har forsøgt at mørklægge indholdet af rapporten ved at fjerne pdf'en på ministeriets hjemmeside.

Rapporten blev udarbejdet af Boston Consulting Group og blev bestilt, fordi CSC allerede dengang måtte bede om udsættelse og flere penge. Opgaven med at udvikle Polsag - det nye centrale it-system til Politiet - var gået til CSC i begyndelsen af 2007, så da konsulenterne går i gang med deres review i foråret 2009, har projektet altså to år på bagen.

Men da kvaliteten af arbejdet bliver undersøgt gennem stikprøver, er konsulenterne ikke imponerede. Alt peger på, at Polsag vil blive ramt af performance-problemer og lange svartider, lyder konklusionen.

»Vores analyse af den teknologiske platform understøtter også, at koden ikke er optimeret for performance. Ved gennemgang af udvalgte dele af koden kan vi konstatere, at standardteknikker for at fremme performance ikke er implementeret. (…) De valgte løsninger skaber derfor en betydelig risiko for, at systemets performance ikke vil være tilfredsstillende,« lyder det i rapporten.

Så længe der ikke er en samlet og mere dybdegående vurdering af performance-problemerne, er det uklart, hvad konsekvenserne kan blive, fortsætter vurderingen, men indtil da er det ’en ikke ubetydelig risiko’, skriver konsulentfirmaet.

Er der brug for større forbedringer, vil selv den reviderede tidsplan, der blev lagt dengang, ikke holde, lyder advarslen.

Og problemet kan heller ikke nødvendigvis løses ved, at Rigspolitiet holder CSC fast på at levere en god nok løsning.

Svartider ikke med i kontrakten

I kontrakten med CSC har Rigspolitiet nemlig ikke fået stillet krav om gode svartider på det samlede system, kun på Polsag isoleret set.

»For at vurdere risikoen for øgede omkostninger - som følge af performance-problemerne - skal det bemærkes, at kontrakterne med CSC/Scanjour efter vores opfattelse indeholder en væsentlig uhensigtsmæssighed, idet der i kontrakterne ikke er angivet et eksplicit (og kvantificeret) krav til end-to-end-performance,« konkluderer rapporten.

CSC kan derfor slippe af sted med at aflevere et it-system, hvor Polsag-programmet i sig selv er hurtigt nok, men hvor arbejdet med Polsag i praksis er umuligt, fordi datatræk fra de mange andre systemer hos Politiet kan tage evigheder - og i så fald kan Rigspolitiet ikke gøre andet end at punge ud og købe sig til ekstra forbedringer af systemet.

Rapportens samlede konklusion lyder, at CSC og Scanjour vil være i stand til at levere systemet i en tilfredsstillende kvalitet - hvis altså der bliver rettet op på problemerne. Det lovede leverandørerne, og projektet fortsatte.

Men da Polsag i december 2010 endeligt bliver klar til pilotdrift på Bornholm, hvor der kun er 80 betjente, lider Polsag stadig af performance-problemer og lange svartider.

Efter et helt år med pilotdrift, i hele 2011, har CSC stadig ikke fået løst problemerne. I februar 2012 vælger regeringen og Justitsministeriet derfor at lukke hele projektet ned.

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
Deleted User

Aflevere man et system der er ubrugeligt fordi det er for langsomt, så skal man have pengene tilbage eller kræve at det bliver løst uden tillæg. Synes CSC stiller udvikling i et dårligt lys.

  • 2
  • 2
Nikolaj Brinch Jørgensen

...viser det sig nok, at dette igen er et fejlslået off shoring eventyr. Jeg gætter, men jeg tror sgu det er her hunden ligger begravet. De fleste leverandører er ikke modne til at varetage off shore udvikling. Og så er manglen på kompetencer hos leverandøren nok også en meget stor del af forklaringen.

Der er så mange der lige nu gør sig kloge på hvorfor Polsag fejlede. Den seneste er en ny V2 blogger, der selvfølgelig har et ærinde om at sælge sit firmas projektledelsesegenskaber,.

  • 3
  • 5
Henrik Rathje

tjoee..men hvis performance IKKE var en kvalitet som kunden bad om, og som de måske har givet køb på(er set før!), for at få nogle andre kvaliteter (eks: korrekthed, alsidighed, guidende), så skal man ikke skyde med alt for skarpt på CSC.. men i øvrigt er denne artikel for tynd til at man kan konkludere noget som helst.

Jeg vil vente til rapporten offentliggøres, og om muligt med delvis kodeindsigt, før jeg dømmer nogen.

  • 2
  • 0
Adam Tulinius

Aflevere man et system der er ubrugeligt fordi det er for langsomt, så skal man have pengene tilbage eller kræve at det bliver løst uden tillæg. Synes CSC stiller udvikling i et dårligt lys.

Hej Martin. Problemet er at der i kravspecifikationen bør være verificér-bare krav til performance. Man kan ikke bare skrive "generér en rapport når den bliver efterspurgt", men bør skrive noget i stil med "95% af alle rapport-efterspørgsler skal være klar til brug, hos brugeren, inden for 10 sekunder" (og så passende lige inkludere noget med at det er tid taget fra request modtaget, til request afsendt, for at slippe uden om netværks forsinkelser).

Uden krav at overholde er der ingen grund for udvikleren til at optimere på noget som helst. Med kravet har man pludselig en kontrakt der først er opfyldt når performance er som ønsket.

Det virker selvfølgelig som regel-rytteri, men som udvikler med moral vil jeg da også gerne vide hvilken performance kunden ønsker, sådedes man ikke bruger unødvendig tid på at optimere steder kunden allerede er tilfreds.

  • 0
  • 0
Adam Tulinius

Jeg synes at det her motiverer til at få udviklet i Indien... der taber man ikke så mange penge på fejlslagne projekter...

Jeg synes nærmere det her burde motivere befolkningen til at kræve at børnene på Christiansborg, og ledere i det offentlige generelt, tager ansvar for de projekter de søsætter. Man kunne passende starte med at sørge for at kravspecifikationerne er overskuelige, utvetydige, og IKKE MINDST at de rent faktisk beskriver det ønskede produkt.

  • 2
  • 0
Jesper Frimann

@Nikolaj Brinch Jørgensen

Mht. offshoring, RL eksempel fra denne uge.

Projekt leder til Jesper frimann. "Kan du ikke løse problem XXX for mig ?" Jesper Frimann til Projekt leder: "I må aktså selv kunne løse problem XXX, det burde være BAU (business as usual)." Projekt leder til lokal teknisk person: "Kan du ikke specificere til teknisk person i Indien hvad der skal laves" Lokal teknisk person til teknisk person i Indien "Du skal lave XXX". Teknisk person i Indien til Jesper Frimann "Kan du lave XXX for mig ?"

Jesper Friman: "Arrrgghhhhh!!"

Og så er det ikke engang løgn.

// jesper

  • 4
  • 0
Robert Larsen

Det tænkte jeg også. Jeg har arbejdet i et firma, som sendte et par opgaver til Indien, og der lærte vi, at man aldrig tænker en selvstændig tanke. Hvis ikke vi specifikt bad om, at koden skulle virke, så gjorde den det ikke.

Men jeg troede da, at vi kunne tænke selv i Danmark.

  • 3
  • 1
Jimmy Frydkær Dürr

Jeg forstår det simpelthen ikke. Vi har så utroligt mange offentligt ansatte it-folk som dagligt servicerer tusindvis af brugere, og har nogle pænt store databaser til at køre 24/7 uden problemer. Hvorfor er der ingen af disse meget kompetente mennesker, som har været med i de indledende processer allerede FØR der er skrevet så meget som én linje kode?

For mig at se ligner hele processen én gang borgerlige skulderklap og forgyldte håndtryk.

"Vi ved godt, at skidtet sikkert ikke kommer til at virke. Men prøv alligevel. Du kan jo sagtens bruge pengene."

Ps. Før du skyder mig i sænk politisk: Jeg stemmer selv borgerligt.

  • 1
  • 1
Deleted User

Hej Adam

Jeg forstår det udemærket godt. Jeg ved godt at en kravspecifikation skal indeholde målbare krav. Men her er hvordan jeg ser det: De der har siddet og lavet systemet har været inde over fra starten, nok ikke alle sammen med nogen af dem. Her snakker vi om selve udviklerne. Der har også været nogle projektledere. I denne process er der blevet sparet med Politiet, skrevet user stories (eller hvad man har lyst til at kalde det). Efter processen er overstået er det blevet brudt yderligere ned, og udviklerne har fået opgaverne udstukket.

Sidder jeg som almen udvikler, eller som overordnet projektleder og laver tests, hvor det går langsom så ville JEG råbe vagt i gevær, for jeg ved hvad Politiet laver og hvad de skal bruge det til. Det kan godt være at det ikke står udspecificeret i en kravspecifikation, men jeg ville gå ind og optimere, eller ihvertfald gøre Politiet opmærksom på det, og ikke bare gemme mig bag en kontrakt. Det er tøset. Jeg kan blive så sur af at høre om udviklere som ikke gør det arbejde godt nok, og specelt i denne sag hvor alle disse penge kunne været gået til skoler, veje, ældre hjem, nedsættelse af offentlig transport eller husning af hjemløse.

Jeg ser dette som et designbrist fra CSC's side. Var CSC bygningskonstruktører på et nyt super sygehus, så havde de garenteret "glemt" at indbygge elevatorer som passede til sygesengene fordi målene ikke lige stod udspecificeret i kravspecifikationen. Ja de havde sikkert helt undladt at bygge elevatorer.

Det var vist min galde.

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