mboost-dp1
CSC
At skylde skyden over på CSC er da helt forkert. Da kommunerne stod for gældsindrivelsen, var der ikke det store problem i det.
Problemet opstod først da SKAT overtog opgaven, uden at være parate til det. Hvad ville der mon ske, hvis kommunerne fik opgaven tilbage igen?
Der var en grund til at der lød et ramaskrig fra kommunerne, da staten offentligjorde at SKAT skulle stå for inddrivelsen.
Men vi kan vel gøre som i USA og sagsøge CSC - Viola! Penge til DK!
Problemet opstod først da SKAT overtog opgaven, uden at være parate til det. Hvad ville der mon ske, hvis kommunerne fik opgaven tilbage igen?
Der var en grund til at der lød et ramaskrig fra kommunerne, da staten offentligjorde at SKAT skulle stå for inddrivelsen.
Men vi kan vel gøre som i USA og sagsøge CSC - Viola! Penge til DK!
Det er da rart at de endelig vil se en tidsplan på projektet. Måske burde det have været aftalt på forhånd..
Skat burde forlænge forældelsestiden på sagerne på baggrund af dette, eller i det mindste true med at gøre det. Med udmeldinger som disse, så opfordrer de jo nærmest til mere svindel.
Personligt synes jeg ikke at offentlig gæld burde kunne forældes, når først den er konstateret. Det er fair nok at de ikke roder rundt og leder efter fejl i bilag fra 80erne, men hvis først de har fundet dokumentation for svindel, så skal de da ikke bare smide det ud bare fordi det ikke er opkrævet indenfor 5 år..
Skat burde forlænge forældelsestiden på sagerne på baggrund af dette, eller i det mindste true med at gøre det. Med udmeldinger som disse, så opfordrer de jo nærmest til mere svindel.
Personligt synes jeg ikke at offentlig gæld burde kunne forældes, når først den er konstateret. Det er fair nok at de ikke roder rundt og leder efter fejl i bilag fra 80erne, men hvis først de har fundet dokumentation for svindel, så skal de da ikke bare smide det ud bare fordi det ikke er opkrævet indenfor 5 år..
Har SCS ikke levet op til kravene, så må CSC naturligvis erstatte den tabte inddrivelse. Det kan ikke passe, at CSC kan slippe afsted med at lave en brøler til 37 mia. kr. og så slippe afsted med det.
Eller har kontrakten med CSC spøgefulde ligheder med DSB's kontrakt med Ansadobreda?
Hvem skal betale underskudet på de 37 mia. kr?
Det er jo godt halvdelen af Danmarks gæld vi taler om her.
Eller har kontrakten med CSC spøgefulde ligheder med DSB's kontrakt med Ansadobreda?
Hvem skal betale underskudet på de 37 mia. kr?
Det er jo godt halvdelen af Danmarks gæld vi taler om her.
Laver CSC egentlig software mere? jeg synes efterhånden det er lang tid siden man har hørt om et egentlig softwareprodukt - og i såfald; et funktionelt softwareprodukt.
Jeg tillader mig at stille tvivl ved om det overhovedet er software de laver! Mit umiddelbare bud er at der produceres mere varm luft i den butik end software.
Jeg tillader mig at stille tvivl ved om det overhovedet er software de laver! Mit umiddelbare bud er at der produceres mere varm luft i den butik end software.
Enig med #3
Vi høre gang på gang i medierne at CSC er skyld i forsinkelserne på det offentlige IT systemer - havde det været i USA var virksomheden blevet sagsøgt langt ned i helvedet.
#1 - det er da lige præcis CSC der er skyld i forsinkelserne. Hvis CSC havde leveret til tiden, ville SKAT jo ikke stå med det problem.
Det er på tide, at det får konsekvenser.
Vi høre gang på gang i medierne at CSC er skyld i forsinkelserne på det offentlige IT systemer - havde det været i USA var virksomheden blevet sagsøgt langt ned i helvedet.
#1 - det er da lige præcis CSC der er skyld i forsinkelserne. Hvis CSC havde leveret til tiden, ville SKAT jo ikke stå med det problem.
Det er på tide, at det får konsekvenser.
Ravensholt (6) skrev:Det er på tide, at det får konsekvenser.
Hvilken offentlig ansat vil dog indlægge konsekvenser i en sådanne kontrakt. Ud over at den pågældende person altså skal have et lukrativt konsulentjob, hvor man intet skal lave til en høj hyre lidt senere?
Er der ikke noget med, at kommunerne ikke bare må skifte leverandør uden at der skal ske et alvorligt kontraktbrud? Gælder det også for SKAT? Hivs det er rigtigt, så må forsinkelse og forhøjelse af prisen ikke være noget alvorligt at snakke om. Der skal åbenbart andet til. Men så igen; hvis der ikke står noget specifikt i kontrakten, så kan CSC gøre hvad de lyster. Er der noget hold i det jeg skriver her? :)
Er jeg den eneste der har fulgt sagen bare lidt?
Cheferne i skat har givet stærkt udtryk for, at den daværende minister, igen blå blok (ligesom med sygehussystemet), bare sagde "det skal vi have" - "Det er klart om to år" uden på nogen som helst måde at have undersøgt sagen nærmere er årsagen til, at tidsrammen er overskredet.
Vi må håbe at de nye ministre bare har lidt mellem ørerne og ikke køre Danmark af sporet med uholdbare lommefilosofier.
Cheferne i skat har givet stærkt udtryk for, at den daværende minister, igen blå blok (ligesom med sygehussystemet), bare sagde "det skal vi have" - "Det er klart om to år" uden på nogen som helst måde at have undersøgt sagen nærmere er årsagen til, at tidsrammen er overskredet.
Vi må håbe at de nye ministre bare har lidt mellem ørerne og ikke køre Danmark af sporet med uholdbare lommefilosofier.
Hvilke kommuner?Hånter (1) skrev:Hvad ville der mon ske, hvis kommunerne fik opgaven tilbage igen?
Det kan da bestemt ikke være deres opgave at fastsætte forældelsesfrister. Og der er da heller ingen rimelighed i at det skal komme de berørte borgere til skade, at CSC ikke kan levere software til tiden.1000tusind (2) skrev:Skat burde forlænge forældelsestiden på sagerne på baggrund af dette
Det er ikke CSCs skyld at pengene ikke er blevet inddrevet. De kan da allerhøjst skulle betale hvad det nu ville koste at holde det gamle system kørende indtil det nye var klart.ufomekaniker (3) skrev:Har SCS ikke levet op til kravene, så må CSC naturligvis erstatte den tabte inddrivelse.
Hvis nogen i staten har valgt at droppe det gamle system før det nye var i drift, så må det da være dem der er skyld i at pengene ikke er blevet inddrevet.
De kan ikke undskylde sig med at de ikke vidste at et nyt IT system kunne blive forsinket.
Nej, så simpelt er det altså ikke!
Da Thor Möger for nylig omtalte sagen (om de opgivne milliarder) i P1's Orientering, var den altoverskyggende årsag, at man valgte at erkende, at skyldnerne simpelthen ikke er i stand til at betale.
Det handlede om folk, der er gået ned med virksomheder, folk der lever på kanten af samfundet (som Thor Möger så fint siger det), virksomheder, der er gået konkurs - til forskel for folk, der er gået ned med dem - og des lige.
Det han nævnte om Debitormotor var, at man håber, at det nu stærkt forsinkede system vil gøre SKAT i stand til at bruge færre ressourcer på opgaven, for det ER besværligt at koordinere indsatsen, når de nuværende systemer taler lige så dårligt sammen som .. nå ja, som de nuværende ansatte gør det.
Det er sensationalisering at skrive at "det offentlige [i værste fald ]må opgive at inddrive 37 milliarder kr. i gæld" på grund af forsinkelsen.
Derudover, lad os få nogle årsager til forsinkelsen på bordet. Der er især én stærkt dominerende årsag til, at offentlige IT-projekter (og andre typer projekter) så ofte løber af sporet:
Det Offentlige (DO)! Udbudsmaterialet er tit ekstremt ringe, og det kan være hamrende svært for en virksomhed at finde ud af, hvad det egentligt er, DO vil have. Ofte er det også ekstremt svært for DO selv at finde ud af, hvad det vil have, for beslutningstagerne, de, der autoriserer projekterne, har ofte absolut ikke en hat forstand på det, de sender i udbud - en naturlig konsekvens af, at det kan være de samme mennesker, der sender IT-projektor, motorvejsbygning og indkøb af undervisningsudstyr i udbud.
Resultatet er alt for ofte, at der løbende sker så store ændringer i forhold til det oprindelige udbudsmateriale, at hele konktrakter må omskrives og halve projekter starte forfra.
Eller omvendt.
Så, hvorom alting er, tag nyheden med et gran salt, og spørg jer selv , hvorfor situationen er som den er - svaret kan være interessant.
Da Thor Möger for nylig omtalte sagen (om de opgivne milliarder) i P1's Orientering, var den altoverskyggende årsag, at man valgte at erkende, at skyldnerne simpelthen ikke er i stand til at betale.
Det handlede om folk, der er gået ned med virksomheder, folk der lever på kanten af samfundet (som Thor Möger så fint siger det), virksomheder, der er gået konkurs - til forskel for folk, der er gået ned med dem - og des lige.
Det han nævnte om Debitormotor var, at man håber, at det nu stærkt forsinkede system vil gøre SKAT i stand til at bruge færre ressourcer på opgaven, for det ER besværligt at koordinere indsatsen, når de nuværende systemer taler lige så dårligt sammen som .. nå ja, som de nuværende ansatte gør det.
Det er sensationalisering at skrive at "det offentlige [i værste fald ]må opgive at inddrive 37 milliarder kr. i gæld" på grund af forsinkelsen.
Derudover, lad os få nogle årsager til forsinkelsen på bordet. Der er især én stærkt dominerende årsag til, at offentlige IT-projekter (og andre typer projekter) så ofte løber af sporet:
Det Offentlige (DO)! Udbudsmaterialet er tit ekstremt ringe, og det kan være hamrende svært for en virksomhed at finde ud af, hvad det egentligt er, DO vil have. Ofte er det også ekstremt svært for DO selv at finde ud af, hvad det vil have, for beslutningstagerne, de, der autoriserer projekterne, har ofte absolut ikke en hat forstand på det, de sender i udbud - en naturlig konsekvens af, at det kan være de samme mennesker, der sender IT-projektor, motorvejsbygning og indkøb af undervisningsudstyr i udbud.
Resultatet er alt for ofte, at der løbende sker så store ændringer i forhold til det oprindelige udbudsmateriale, at hele konktrakter må omskrives og halve projekter starte forfra.
Eller omvendt.
Så, hvorom alting er, tag nyheden med et gran salt, og spørg jer selv , hvorfor situationen er som den er - svaret kan være interessant.
Illum (7) skrev:De laver systemet til vores skole... Og fuck noget crap. Hvis man er på login siden for længe, før man logger ind, er man inaktiv, og skal logge ind igen.. o.O'
OK? Hvis man er på login siden for længe, FØR man logger ind; er man inaktiv og må logge ind IGEN? - That sux, jeg hader også at logge ind igen før jeg logger ind;-)
...( sorry )
OPUS systemerne, Digital Flytning, LABKA, LUDUS og NOTUS er nogle dem jeg lige kan på rygraden.Kian (5) skrev:Laver CSC egentlig software mere? jeg synes efterhånden det er lang tid siden man har hørt om et egentlig softwareprodukt - og i såfald; et funktionelt softwareprodukt.
Udover du ikke giver mening så er det altså ikke unormalt at man logges ud af systemer når man er inaktiv. Det kaldes sikkerhed.Illum (7) skrev:De laver systemet til vores skole... Og fuck noget crap. Hvis man er på login siden for længe, før man logger ind, er man inaktiv, og skal logge ind igen.. o.O'
Jeg tror lige så meget det er et spørgsmål om at udviklerne ikke har styr på hvilke oplysninger om tilstanden der skal gemmes på klienten, og hvilke oplysninger der skal gemmes på serveren.Magten (19) skrev:så er det altså ikke unormalt at man logges ud af systemer når man er inaktiv. Det kaldes sikkerhed.
Ved at gemme oplysninger relateret til en session på serveren og ikke have nogen mulighed for at vide om de relaterede data stadig findes på klienten ender man i en situation hvor serveren bliver nødt til at smide data væk, og hvis klienten derefter vender tilbage er man nødt til at starte forfra.
Fænomenet er så udbredt også i situationer hvor argumentet omkring sikkerhed ikke kan bruges, at jeg tror et fåtal af webudviklere har evnerne til at lave et system der tillader at en session kan være idle vilkårligt længe.
At man derefter vælger at slette data baseret på et timeout i stedet for at basere det på om man har kapacitet til at opbevare dem gør bare situationen endnu mere besværlig for brugerne.
Hvis jeg skal overbevises om at det er gjort af hensyn til sikkerheden og ikke fordi at udviklernes evner blot ikke rakte til mere, så skal der et par ting til.
Timeout tælleren skal kun køre når det er relevant. At starte timeout tælleren før man overhovedet er logget ind er forkert.
Desuden skal et timeout ikke slette alle oplysninger fra sessionen, det skal blot kræve at man validerer sig igen og så kan vende tilbage til nøjagtigt det sted man var.
#20
Jeg vil nu til hver en tid mene at timeout på en session er fornuftigt, lige så vel som min computer låser automatisk efter X minutter uden aktivitet. Hverken server eller klient ved hvem der sidder ved computeren, så det er alt andet lige bedre at jeg skal logge ind igen end at andre folk kan bruge min session.
Oplysninger i sessionen er jeg enig i ikke skal slettes, men det skrev #7 intet om.
Jeg vil nu til hver en tid mene at timeout på en session er fornuftigt, lige så vel som min computer låser automatisk efter X minutter uden aktivitet. Hverken server eller klient ved hvem der sidder ved computeren, så det er alt andet lige bedre at jeg skal logge ind igen end at andre folk kan bruge min session.
Oplysninger i sessionen er jeg enig i ikke skal slettes, men det skrev #7 intet om.
Jeg kan ikke se det fornuftige i et timeout når man ikke er logget ind eller på sites, hvor der slet ikke er noget der hedder et brugernavn.Magten (21) skrev:Jeg vil nu til hver en tid mene at timeout på en session er fornuftigt
Første eksempel:
1. Jeg åbner et website med en login dialog.
2. Efter et par timer kommer jeg tilbage til det faneblad og taster brugernavn og password ind.
3. Login fejler fordi sessionen er timet ud.
Andet eksempel:
1. Jeg skal med offentlig transport til et sted jeg ikke har været før, så aftenen før laver jeg en søgning på rejseplanen.dk for at se hvornår jeg skal afsted.
2. Næste morgen klikker jeg på linket for at se detaljer om hvilke transportmidler jeg skal med
3. Fejl fordi sessionen er timet ud.
Tredje eksempel:
1. Jeg skal på ferie og har åbnet sas.dk for at finde en mulig forbindelse og tidspunkt.
2. Jeg lader siden være åben mens jeg sikrer mig at der ikke er nogen konflikter der forhindrer mig i at rejse på det tidspunkt.
3. Jeg går tilbage til siden og indtaster kortnummer for at betale for den billet jeg har fundet.
4. Fejl fordi sessionen er timet ud.
Jeg kan ikke se fornuften i nogen af de eksempler.
Min desktop computer er det kun mig selv der anvender. Og hvis jeg har været væk fra den er skærmen låst før de websites ville have timet ud. Hvis mit password bliver indtastet igen for at låse computeren op, så ved klienten hvem der sidder ved computeren.Magten (21) skrev:Hverken server eller klient ved hvem der sidder ved computeren
Jeg tror vi snakker forbi hinanden. Jeg mener timeout når man er logget ind er fornuftigt. Timeout når man ikke er logget ind giver ikke nogen mening.kasperd (22) skrev:Jeg kan ikke se det fornuftige i et timeout når man ikke er logget ind eller på sites, hvor der slet ikke er noget der hedder et brugernavn.
Netop. Min pointe var at mange websites har timeout uanset om der er en login funktion eller ej. Og det indikerer at årsagen til at der er timeout ikke har noget med sikkerhed at gøre.Magten (23) skrev:Jeg tror vi snakker forbi hinanden. Jeg mener timeout når man er logget ind er fornuftigt. Timeout når man ikke er logget ind giver ikke nogen mening.
At der kan være situationer hvor timeout er en fordel for sikkerheden kan vi sagtens blive enige om. Jeg har bare ikke set et site hvor det var fuldstændigt åbenlyst at formålet med timeout var sikkerhed.
De fleste giver indtryk af at timeout har til formål at spare server resurser og udvikleren har ikke ville bruge tid på at finde en løsning som var mere brugervenlig. Og at det i nogle tilfælde er bedre for sikkerheden end at slet ikke have et timeout ligner mest af alt en bieffekt.
Hvis man vil overbevise mig om at det er af hensyn til sikkerheden man gør det, og at man ikke prøver på at vælge den nemme udvej i stedet for at tænke på brugervenlighed, så kunne man gøre følgende:
Når brugeren er logget ind gemmes oplysninger om sessionen både på serveren og på klienten. Oplysningerne på klienten er krypteret og autentificeret således at serveren kan stole på dem når de kommer tilbage. Efter et timeout slettes sessionen fra serveren. Hvis sessionen alligevel stadig er aktiv overføres oplysningerne fra klienten til serveren, og serveren kan så bede om at password indtastes igen før sessionen reetableres.
kasperd (22) skrev:Tredje eksempel:
1. Jeg skal på ferie og har åbnet sas.dk for at finde en mulig forbindelse og tidspunkt.
2. Jeg lader siden være åben mens jeg sikrer mig at der ikke er nogen konflikter der forhindrer mig i at rejse på det tidspunkt.
3. Jeg går tilbage til siden og indtaster kortnummer for at betale for den billet jeg har fundet.
4. Fejl fordi sessionen er timet ud.
Jeg kan ikke se fornuften i nogen af de eksempler.
Hvis du er kommet så langt, så kan pladsen jo godt være reserveret i systemet i fx ½ time indtil du får betalt, ellers kan du jo få hele flyet booket op, ved at starte nye sessioner, hvis der ikke er noget timeout.
Hvis pladsen ikke bliver reserveret på en eller anden måde før du har betalt kan en anden jo komme til at få samme plads, imens du er ved at købe.
Ellers er jeg enig i resten :-)
På dette tidspunkt i forløbet er der ikke tildelt nogen specifik plads, så det ville kun være et problem hvis alle pladser var reserveret. Men det kan også nemt løses i softwaren. Reservationen skal kun gælde et passende tidsrum. Når sessionen reaktiveres skal reservationen laves på ny. Så vil reaktivering kun fejle hvis flyet er blevet fuldstændigt booket op i mellemtiden.freesoft (25) skrev:Hvis du er kommet så langt, så kan pladsen jo godt være reserveret i systemet i fx ½ time indtil du får betalt, ellers kan du jo få hele flyet booket op, ved at starte nye sessioner, hvis der ikke er noget timeout.
Men det er jo velkendt at flyselskaber er ligeglade med det problem. De afholder sig jo ikke fra at sælge lidt flere biletter end der er pladser på flyet. Så kan de jo altid afvise passagerer ved gaten.
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