1. Hensikten med kurset - Lars Marius Garshol

Innføring i databaser
Når man har kommet så langt vet man hva som trengs, og begynner å planlegge hvordan
dette skal løses på datamaskinen. Tar man de gale avgjørelsene her kan det koste svært mye
tid og krefter senere.
• Implementasjon
Så er alt klart. Man vet hva man skal ha, og hvordan det skal lages. Da gjenstår bare å lage
det. Denne delen betraktes ofte som 100% (eller 90%) av jobben; men det er feil!
• Feilsjekking
Så fort programmet komplett og har alt det skal tror man ofte at det er ferdig. Det er feil
(igjen). Programmet vil nå inneholde feil. Alle programmer (unntatt de aller minste og
enkleste) har feil. Det gjelder også både Windows og Access.
• Bruk
Etterhvert tas programmet i bruk, selv om det sannsynligvis gjenstår feil. Alle programmer
som er store nok til å være nyttige inneholder feil. (Det er vanlig under utviklingen av store
programsystemer å utgi programmet når antall feilrapporter pr uke har kommet ned i et
passelig tall.)
• Nye behov
Men selv når programmet er tatt i bruk og alle feil fjernet er ikke programmererens oppgave
over. Svært ofte finner man ut at ‘det hadde jo vært fint om programmet også kunne gjøre
sånn og sånn’ eller ‘det var ikke slik det skulle være’ eller oppgavene programmet skal
utføre endres. Da må man til med ny analyse, nytt design og så endre implementasjonen
(systemet), sjekke feil osv nok en gang.
I praksis vil man ikke kjøre gjennom hele denne sekvensen, ihvertfall ikke så grundig som det
er beskrevet her, når man skal lage mindre/middels programmer. Ved større seriøse
programmeringsprosjekter er det utenkelig å ikke kjøre gjennom et nøye planlagt program for
utviklingen. Programutvikling (også kalt software engineering) er altfor vanskelig og dyrt til at
man tør å gjøre noe annet. Det er alt for mange eksempler på utviklingsprosjekter som har
trukket ut i det uendelige uten å komme noen vei. Her hjemmefra kan vi jo nevne
Rikstrygdeverkets TRS’90-system (som et av mange), og også i resten av verden er problemet
velkjent.
Det lønner seg å hele tiden ha i tankene at programmet du lager kan komme til å leve lenge.
Mange av programmene som brukes idag (særlig større administrasjonsprogrammer hos banker
og i offentlig forvaltning) har vært ibruk siden slutten av 60-tallet. Det er ikke uvanlig at
programmer overlever sin utvikler i en bedrift, slik at andre må jobbe videre med det du har
utviklet. Det er da det er viktig at man hadde et godt gjennomtenkt design i begynnelsen.
Dette kan kanskje høres ut som overdrevent mas om å “være grundig og nøyaktig blablabla”,
og så lenge du bare lager programmer for deg selv er det det, men i det øyeblikk andre
mennesker blir involvert som brukere/utviklere blir det svært viktig.
1096 - Lars Marius Garshol 9