Startside
Sjangere

Oppgaver og stiler



Laste opp stil
Legg inn din oppgave!
Jeg setter veldig stor pris på om dere gir et bidrag til denne siden, uansett sjanger eller språk. Alt fra større prosjekter til små tekster. Bare slik kan skolesiden bli bedre!
Legg inn oppgave


propaganda.net : Skole & Jobb
Hvem har ansvaret for år 2000?Skriv ut Utskrift
Om det tidligere år 2000-problemet.
Bokmål - ResonnerendeForfatter:

Verden begynner etterhvert å innse at årtusenskiftet ikke bare er et spørsmål om valg av champagne og om hvordan festen skal organiseres. Mange av de datasystemer og mikroprosessorer vi har gjort oss avhengige av skjuler tidsinnstilte bomber: De er ikke i stand til å håndtere overgangen til et nytt århundre. De fleste av bombene som man ikke har klart å uskadeliggjøre, utløses 1. januar 2000. Systemer som ikke håndterer årtusenskiftet vil enten stoppe eller feilfunksjonere. I mange situasjoner vil feilfunksjonering være mer alvorlig enn full stopp, fordi man da risikerer ikke å oppdage feilen før den har fått alvorlige konsekvenser. Det er bedre at et navigasjonssystem ikke fungerer, enn at det tilsynelatende er i orden, men gir feil informasjon.

 

Problemet er såre enkelt: Det har inntil nylig vært vanlig å angi årstall bare ved de to siste sifrene. Året 1998 angis bare som 98. Når man går inn i et nytt århundre, starter man på 00 i stedet for å øke med et hundretall. Hvis man f.eks. skal regne rente for perioden 1996 til 2001, blir regnestykket 01 minus 96, som gir svaret -97. Men beregningen skulle ha vært 2001 minus 1996, eller eventuelt 101 minus 96, og svaret skulle blitt 5. Datamaskiner har stor regnekraft, men lite intelligens. Så de forstår ikke at dette blir galt med mindre de er programmert slik at svaret ikke godtas som gyldig. Så de vil beregne rente for -97 år i stedet for 5 år. I noen systemer vil minus i datofelt bli ignorert, slik at det regner 97 år, eller det vil oppfattes som feil slik at systemet stopper.

 

Også andre datoer enn 1. januar 2000 kan være kritiske. Mange systemer har utløpsdato 9/9/99. Noen systemer bruker 99 som verdi for "ubegrenset", som feil kode, m.m. Det globale navigasjonssystemet GPS teller uker, og kalenderen i systemet løper ut 21. august 1999. Den dagen bør man kanskje unngå å reise med fly. Det er også noen systemer som vil klare år 2000, men som tiden bokstavelig talt vil løpe ut for noen år senere. Man kan i dag undres over hvorfor man i utgangspunktet valgte en løsning basert på to sifre. Forklaringen er at datakraft og lagringskapasitet var dyrt. I 1963 kostet det $175 pr. måned å leie 1Mb maskinhukommelse (1Mb er ca 1 mill tegn). I dag kjøper man maskinminne for 20 kr pr. Mb. Et tall med 4 sifre er opptil 100 ganger så stort som et tall med 2, og beregninger med fire sifre krever tilsvarende mer kapasitet enn beregninger med to. Man valgte å spare penger, skjøv problemet foran seg og hadde vel en tro på at det ville bli løst før man møtte deadline.

 

En skulle tro at det er enkelt å rette en slik feil. I utgangspunktet er problemet trivielt. Men det har så stort omfang. Man må finne alle systemer som har en innebygget klokke og kalender, undersøke om de klarer overgangen til nytt årtusen, og eventuelt rette feil eller skifte dem ut. Og ingen vet hvor alle disse systemene befinner seg. I praksis betyr det at man må gå igjennom hver eneste programlinje. Det er ingen som til nå har klart å lage programmeringsverktøy som automatiserer denne oppgaven, selv om mange med jevne mellomrom har hevdet å ha klart det.

 

Det er visstnok bare 1% av alle mikroprosessorer som brukes i det vi til daglig forbinder med datamaskiner. De resterende 99% styrer varmeregulering, heiser, ABS-bremser på biler, faksmaskiner, telefoner, radioer, adgangssystemer, måleinstrumenter, doseringssystemer, osv. Slike systemer er ofte dårlig dokumentert, og har ikke et grensesnitt som gjør det mulig å gjennomføre omfattende tester eller å rette feil man måtte oppdage. Det har vært hevdet at en uoppdaget feil i en slik databrikke i en ventil på en gassrørledning i verste fall kan stanse norsk gasseksport til Europa. Og skulle man klare å identifisere databrikker med årtusen feil, så er det likevel lite man får gjort dersom den befinner seg i en kommunikasjonssatellitt i bane over jorden. Ingen kan si sikkert hvor stort problemet er. Et ofte referert anslag fra Gartner Group sier at det vil koste $600 mrd. på verdenbasis å rette feilene. Dette anses for et ganske konservativt anslag. Andre analyseselskaper har kommet med anslag som varierer fra $200 til nær $2.000 mrd. For Norge har Kontor- og Datateknisk Landsforening (KDL) anslått kostnadene til 30 mrd. kroner. Aftenposten refererer anslag på 50-60 mrd. kr. for Norge.

 

Det er vanskelig å få sikre opplysninger om kostnadene hos enkeltselskaper. Dels vet ikke selskapene dette selv, dels er de tilbakeholdne med å gå ut med opplysninger. Men selskaper som har gått løs på problemet sier ofte at problemet viste seg å være større enn de hadde trodd på forhånd. Av tall som har blitt kjent gjennom media, fremgår det f.eks. at Telenor regner med å bruke 750 mill. kr., Storebrand 50 mill. og Rikstrygdeverket 30 mill. Svenske Telia regner med å bruke 2,4 mrd. SEK, og British Airways skriver i sin siste årsrapport at de regner med å bruke £100 mill. på å løse dette problemet. I oljeindustrien regner man med at det vil koste 10 mill. kr. pr. installasjon.

 

Noen mener at problemet er blåst opp av konsulenter som ser at det er mye penger å tjene på dette. Kanskje har de rett. Selv har jeg etterhvert blitt overbevist om at det er et reelt problem. Og uansett hva man tror: Den dagen man vet svaret, er det for sent å gjøre noe. Regningen kan bli stor om det skulle vise seg at man ikke har forberedt seg på de problemer mange har varslet om. Men jeg har ikke sett noen forsøk på å beregne hva det vil koste ikke å gjøre noe for å løse problemet.

 

Problemet reiser også en rekke juridiske spørsmål. De fleste av dem gjelder spørsmålet om hvem som har ansvaret for å rette feilene, og hvem som har ansvaret eller må bære risikoen for tap som oppstår fordi feielen ikke er rettet. De fleste saker om dette må antas å komme etter årtusenskiftet, når man ser hvilke saker man ikke har klart å løse. Det har vært hevdet at år 2000 problemet har gjort 1990-tallet til gullår for konsulenter, mens det første tiår i det neste årtusen vil være gullår for advokater. Det er vanskelig å finne tidligere tilfeller som ligner på år 2000 problemet, så det er ikke mulig å gi sikre svar. Man kommer ikke lenger enn til å formulere de viktigste juridiske problemstillingene og stille opp noen utgangspunkter for vurderingene. Hvis det blir klart at et system ikke lenger vil fungere etter 31.12.1999, er det da en mangel? Spørsmålet er ikke så opplagt som det umiddelbart kan synes. Hvis systemet blir solgt i dag, uten at leverandøren gjør oppmerksom på forholdet, kan det ikke være tvil om at det foreligger en mangel. Men det er ikke like klart at det er en mangel dersom systemet ble solgt for 10 år siden. Systemet kan da få en kortere levetid enn hva kunden hadde regnet med. Men det er ikke nødvendigvis en mangel at et produkt viser seg å ha en levetid på f.eks. 8 år, selv om kunden hadde regnet med å kunne bruke det i noen flere år.

 

Spørsmålet om kortere varighet enn forventet skal anses som mangel, har stort sett vært drøftet i forhold til slitasje, materialtretthet, og lignende. Dataprogrammer slites ikke. I den grad et dataprogram blir foreldet, så er det fordi kundens krav utvikler seg. Verden utvikler seg videre, mens programmet står stille. Problemet med forventet varighet for produktet blir derfor et annet enn for gjenstander som er utsatt for slitasje. Spørsmålet blir ikke hvor lenge programmet lever, men i hvor lang tid kunden kan regne med at programmet dekker hans behov.

 

Jeg har ikke funnet noe praksis som gir utgangspunkt for en slik mangelsvurdering. Noe eksakt svar vil det heller ikke være mulig å gi. Det kommer bl.a. an på hva slags program det gjelder. For et skattebregningsprogram for privatpersoner må det være tilstrekkelig at det kan håndtere ligningen for det inntektsår programmet er laget for. Gjelder det derimot et stort transaksjonssystem eller produksjonsstyringssystem, må man vente en mye lenger brukstid, i alle fall for basisprogrammene. Man kommer ikke særlig mye lenger enn til å si at det er en mangel dersom programmet ikke har den levetid som må forventes for den aktuelle programtype.

 

Noen av leverandørene går langt i å fraskrive seg ansvar for selv ganske nye produkter. Verdens største produsent av PC’er, Compaq, sier at de garanterer at alle PC’er som er solgt etter 7. oktober 1997 skal kunne håndtere år 2000 problemet. For eldre maskiner hevder Compaq at det ikke er en mangel som omfattes av "garantien", og at kunden selv er ansvarlig for å foreta nødvendige oppgraderinger, i den grad dette er mulig. Etter min vurdering er det åpenbart at en maskin kjøpt i 1997 vil være mangelfull dersom den ikke er i stand til å håndtere år 2000 problemet.

 

Andre leverandører har, så langt jeg har kunnet se, ikke satt en like klar dato. Men de vil bare akseptere ansvar for maskiner som har blitt sertifisert som "klar for år 2000". Heller ikke dette kan frita en leverandør for mangelsansvar for eldre maskiner som ikke håndterer dette problemet. Men vi finner ikke svaret på hvor langt tilbake vil skal gå. At man på et klart angitt tidspunkt går inn i et nytt århundre, er ikke en uforutsett begivenhet som man ikke kunne ventes å forutse. Ingen kan vente å bli trodd, enn bli tatt alvorlig om de hevder at de ikke visste at man ville gå inn i et nytt årtusen 1. januar år 2000. Det er derfor ikke bli et spørsmål om hvorvidt man forutså begivenheten, men om man forsto eller burde ha forstått hvilke konsekvenser dette kunne ha. Man har hele tiden vært klar over at systemer med datofelt basert på to årstallsiffer, ikke kunne anvendes etter årtusenskiftet. Det man står tilbake med, er at man kanskje ikke forsto hvor omfattende problemet faktisk kan være, at man ikke regnet med at gamle systemer skulle overleve i så lang tid, og at man holdt fast ved gammel praksis for lenge. Det blir nærmest et spørsmål om hvor lenge man kunne holde hodet i sanden, uten å pådra seg ansvar.

 

Det eldste tilfelle av et år 2000-problem som jeg har sett omtalt, er fra 1980. En engelsk bank hadde en finansieringsplan over 20 år. Da sluttdatoen for passerte år 2000, stoppet hele datasystemet. Flyselskapet British Airways begynte visstnok sitt arbeid med å gjennomgå alle sine systemer for å sikre år-2000 resistens i 1987. Den eldste omtalen av problemet som jeg selv har funnet, er en artikkel i den amerikanske utgaven av Computerworld fra 28. januar 1991. Jeg har ikke grunnlag for å hevde at dette faktisk er den første omtalen, sannsynligvis har problemet vært omtalt tidligere. Men på dette tidspunkt var problemet også kjent i den populære del av fagpressen. Jeg har også sett andre hevde at 1991 er et skjæringspunkt, uten at dette har vært begrunnet nærmere.

 

Det er vanskelig ellers å peke på noen klare skjæringspunkter. Problemet har vært der hele tid2en, og bevisstheten omkring det har utviklet seg gradvis. Noen har, med et visst glimt i øyet, hevdet at ingen kan ha vært uvitende om dette etter september 1996, da problemet ble berørt i tre striper av tegneserien Dilbert. Man bør kunne kreve at produsentene "våkner" før de som selger deres produkter, og at disse igjen bør ha blitt oppmerksom på problemet før deres kunder. Ettersom man har blitt mer bevisst år 2000-problemet, har man også begynt å regulere dette i kontrakter. Reguleringene har enten karakter av ansvarsfraskrivelser, eller garantier for at man vil være i stand til å møte problemet. Hvis man i dag anskaffer nytt utstyr eller nye programmer, må man kunne kreve at leverandøren garanterer at dette vil kunne håndtere årtusenskiftet. Men mange ønsker også år 2000-garantier fra tjenesteleverandører. Slike garantier bør man være varsom med å gi. Man skal ha meget god oversikt over status både for systemer i eget hus, og hos alle underleverandører. Det hjelper lite om man selv har sørget for alt i egen organisasjon, om telenettet bryter sammen. Og det er liten grunn til at man skal overta denne risikoen fra egne kunder. Det bør også være et tankekors at de bedrifter som har tatt problemet alvorlig, er lite villige til å gi slike garantier, mens de som har gjort lite internt synes å være mer villig til å gi garantier overfor kunder. Man bør neppe strekke seg lenger enn til å erklære at man har gjennomgått egne systemer og rettet de feil man har funnet, og at man vil gjøre det som med rimelighet kan kreves for å unngå problemer for seg selv og ens kunder. Som en liten avslutning vil jeg bare si at når ankommer neste årtusen, er det mye som tyder på ragnarok i infomasjonsverden. Så vidt jeg kan se er det enhver mann/kvinne for seg selv. Det er ingen som kommer til å ”holde deg i hånda” når klokka tikker mot 12 på nyttårsaften. Ta derfor ansvar selv, og se om du kan gjøre noe med ditt eget informasjonssystem hvis du føler at det trengs. Meningen med å skrive denne stilen er å vekke ”det norske folk”, og få alle til å innse hvilke problemer dette kan skape.

 

Godt nytt år!

Kontakt oss  

© 2007 Mathisen IT Consult AS. All rights reserved.
Ansvarlig utgiver Mathisen IT Consult AS
Publiseringsløsning: SRM Publish