mboost-dp1
www.politi.dk
Det handler vel om at kravsspecifikationerne fra politiet ikker har været klare nok. CSC har vel være nød til at rive ned og bygge op i et væk for at lave noget der 1. reelt kunne det det skulle og 2. være brugervenligt nok til at menig mad kunne anvende det eller?
vatnissen (8) skrev:Det handler vel om at kravsspecifikationerne fra politiet ikker har været klare nok. CSC har vel være nød til at rive ned og bygge op i et væk for at lave noget der 1. reelt kunne det det skulle og 2. være brugervenligt nok til at menig mad kunne anvende det eller?
Nu skal jeg ikke kunne sige hvordan kravspecifikation har været, men når jeg læser rapporten at CSC ikke kodet efter best practice
blandt andet har man kopieret hele kodeblokke, i stedet for at lave funktioner.
man har ændre koden i standart system, i stedet for lave et ap, som kommuniker mellem frontend og det standart beckend system som var brugt. Det vil have gjort det let at opdater api, hvis backend system blev opdateret og der med fungere anderledes end i dag.
vatnissen (8) skrev:
Det handler vel om at kravsspecifikationerne fra politiet ikker har været klare nok. CSC har vel være nød til at rive ned og bygge op i et væk for at lave noget der 1. reelt kunne det det skulle og 2. være brugervenligt nok til at menig mad kunne anvende det eller?
Du har en 75 sides rapport omkring projektet og problemer i samme og du vælger at gætte på en årsag som ikke fremhæves i rapporten.
Hvis du var en typisk dansk udvikler så skulle man jo helt droppe krav spec for danske IT projekter.
Well, fra min egen erfaring... Indere kan være dygtige til mange ting, men de kan sjældent tage nogle beslutninger, hvis der findes andre mennesker i firmaet med mere ansvar end dem selv. :P
Og så følger de kravspec/dokumentation slavisk, uden hensyn til common sense.
Ellers er jeg enig med dig.
Og så følger de kravspec/dokumentation slavisk, uden hensyn til common sense.
Ellers er jeg enig med dig.
#0
Jeg synes at det meste af rapporten er ret tynd i substans med hensyn til kritikken af CSC.
Men på et område er der virkeligt kød på sagen.
Det er f...... slemt.
Og jeg forstår ikke hvordan noget sådant har kunnet få lov til at ske.
Jeg synes at det meste af rapporten er ret tynd i substans med hensyn til kritikken af CSC.
Men på et område er der virkeligt kød på sagen.
Ifølge ScanJour er alle modifikationer af Captia-kernen22, som har vist sig nødvendige i forbindelse med POLSAG-programmet, blevet inkorporeret i den seneste version af Captia-kernen.
...
Der eksisterer dog en risiko for, at Captia-kildekoden fejlagtigt er blevet ændret, fordi POLSAG er blevet udviklet på baggrund af Captia-kildekoden i stedet for at benytte binær API. Således kan det ikke udelukkes, at Captia-kildekoden er blevet modificeret.
Ingen klar separation af name spaces mellem Captia-kernen og POLSAG-objekterne.
Det er blandt andet ikke etableret en klar adskillelse mellem Captia og POLSAG i forhold til systemets database.
Det er f...... slemt.
Og jeg forstår ikke hvordan noget sådant har kunnet få lov til at ske.
#0 resten
Hmm. Sådan endte det som bekendt ikke.
Det var jo slemt i et først års programmerings kursus med henblik på at lære god programmerings stil.
Men jeg har svært ved at se det som noget der kan vælte et XXX mio. kroners projekt.
Og ved det code review var projektet ikke færdigt, så det var ikke engang sikkert at disse problemer ville eksistere ved levering.
For et system i den størrelses orden synes 4 sprog ikke at være mange.
Et sprog er helt urealistisk.
Så jeg forstår ikke kritikken.
Der er jo ingen tvivl om at det giver hurtigere svartid at hente nogle data fra cache fremfor faktisk at hente nyeste data.
Men er man helt sikker på at det er godt nok at vise "nogle data" uden at vide om det er nyeste data.
Det er langtfra givet. Så "best-practice" er lidt billig at fyre af.
Synspunktet at man ikke bør putte forretningslogik i stored procedures og triggers er velkendt.
Jeg er enig i det.
Jeg tror at der pt er ca. 80%-20% support for synspunktet blandt udviklere idag.
Men det er altså ikke en generelt accepteret best practice og at forsøge at gøre det til det er misvisende.
Leverandørerne af POLSAG (CSC/Scan Jour) er i stand til at levere et system, som opfylder de kvalitetskrav, der er fastsat i deres kontrakt med Rigspolitiet, og at POLSAG vil indeholde den funk-tionalitet, der er beskrevet i Aktstykke 119 – bortset fra udviklingen af et datawarehouse, der bliver erstattet af forbedrede rapporteringsfaciliteter i POLSAG.
Det vurderes, at den oprindelige aktstykkebevilling stort set overholdes. Udgifterne til anskaffel-se og etablering af POLSAG, jf. Aktstykke 119, på 221 mio. kr. (pristalsreguleret til 229 mio. kr.) forventes på nuværende tidspunkt således alene overskredet med ca. 5 mio. kr.
Hmm. Sådan endte det som bekendt ikke.
• Hele kodeblokke der er udkommenteret
• Unødigt lange og sammensatte moduler
• Unødvendig gentagen kode, fordi kodesekvenser er blevet kopieret og delvist tilpasset i stedet for at benytte parametre til at holde koden koncis
Det var jo slemt i et først års programmerings kursus med henblik på at lære god programmerings stil.
Men jeg har svært ved at se det som noget der kan vælte et XXX mio. kroners projekt.
Og ved det code review var projektet ikke færdigt, så det var ikke engang sikkert at disse problemer ville eksistere ved levering.
Trifork observerede, at POLSAG er implementeret i samlet set fire programmeringssprog (JavaScript, C#, C++ og PL/SQL). Dette skaber unødig kompleksitet og kræver et mere specialiseret kundskab for at vedligeholde og videreudvikle POLSAG-kodebasen i fremtiden.
For et system i den størrelses orden synes 4 sprog ikke at være mange.
Et sprog er helt urealistisk.
Så jeg forstår ikke kritikken.
Alle web-services med undtagelse af DCS relaterede web-services er implementeret som synkrone kald. Denne beslutning medfører en betydelig risiko for performancesvagheder idet:
• Det øger ventetiden af transaktioner for svar af eksterne systemer
• Det forhindrer kontinuiteten af behandling, hvis fjernsystemer er nede eller ikke svarer inden for på forhånd definerede time-out grænser
Det er BCGs vurdering, at løs kobling gennem asynkrone web-servicekald er best-practice for im-plementering af web-services i service orienteret arkitektur, hvilket kan benyttes til at lette de be-skrevne performanceproblemer. Andre velkendte fremgangsmåder så som at tillade brugerbeslut-ninger om at fortsætte i tilfælde af forsinkede svartider fra fjernsystemer eller caching af data fra fjernsystemer er ej heller blevet implementeret.
Der er jo ingen tvivl om at det giver hurtigere svartid at hente nogle data fra cache fremfor faktisk at hente nyeste data.
Men er man helt sikker på at det er godt nok at vise "nogle data" uden at vide om det er nyeste data.
Det er langtfra givet. Så "best-practice" er lidt billig at fyre af.
Trifork observerede i databaselaget, at der foretages datavalidering i visse stored procedures. Dette bryder designpraksis om at koncentrere forretningslogik og validering i forretningslogiklaget.
Et begrænset brug af database triggers ville som udgangspunkt være en rimelig designbeslutning, men en grov screening af kildekoden afslørede et uventet højt antal triggers. På tidspunktet for dette review havde vi ikke mulighed for at fastslå om disse triggers rent faktisk anvendes korrekt. Hvis triggers ikke bliver anvendt korrekt, dvs. hvis de indeholder forretningslogik, øger dette kom-pleksiteten af koden betydeligt og unødigt.
Synspunktet at man ikke bør putte forretningslogik i stored procedures og triggers er velkendt.
Jeg er enig i det.
Jeg tror at der pt er ca. 80%-20% support for synspunktet blandt udviklere idag.
Men det er altså ikke en generelt accepteret best practice og at forsøge at gøre det til det er misvisende.
#19
ScanJour vil vel sikkert gerne have betaling for det som de har leveret.
Og det kan ikke udlukkes at de kan have krav på fuld betaling.
Hvis de har været ren underleverandør og:
- leveret licenser til deres software
- tilrettet deres software efter specifikation fra CSC
så bliver CSC vel nødt til at betale.
Hvis de har været partner i projektet og derfor har ansvar for hele løsningen, så må man formode at de kommer til at bære en del af tabet.
ScanJour vil vel sikkert gerne have betaling for det som de har leveret.
Og det kan ikke udlukkes at de kan have krav på fuld betaling.
Hvis de har været ren underleverandør og:
- leveret licenser til deres software
- tilrettet deres software efter specifikation fra CSC
så bliver CSC vel nødt til at betale.
Hvis de har været partner i projektet og derfor har ansvar for hele løsningen, så må man formode at de kommer til at bære en del af tabet.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund