1. Hensikten med kurset - Lars Marius Garshol

2. Programutvikling
2.1 Et programs livssyklus
Innføring i databaser
Å utvikle et programsystem er på ingen måte enkelt, og jo større programmet skal være jo
vanskeligere blir det. Det forskes mye på hvordan dette bør gjøres, og det kan være lurt å
bruke litt tid på dette før vi går videre. Egentlig kan det hele oppsummeres i en setning: Tenk
deg om før du gjør noe! Dette kan kanskje høres ut som mas, men hvis du har tenkt å bruke
Access (eller et annet utviklingsverktøy) til noe seriøst bør du følge nøye med.
Som regel når du utvikler et program er det tre aktører involvert. Det er deg selv (utvikler),
den som er oppdragsgiver og bestemmer hvordan programmet skal bli (oppdragsgiver) og de
som skal bruke sluttresultatet (brukerne). Alle disse har hver sine ønsker og behov, og disse er
ikke alltid forenlige med hverandre, og programutvikling kan fort bli en balansegang mellom
disse behovene. Et annet problem er at det kan være vanskelig å forstå hva oppdragsgiver vil
og det behøver ikke nødvendigvis være hva brukerne trenger osv. Derfor kan det fort bli en del
omarbeiding av det man trodde var ferdig, og dette gjør at planlegging blir veldig viktig.
Derfor har jeg tatt med en oversikt over hvordan programutvikling vanligvis forløper, og
hvordan det er vanlig å dele prosessen inn i faser.
• Behov
Her starter det hele. Ofte finner bedriften ut at bestemte arbeidsoppgaver er svært
tidkrevende og rutinepreget, og man ønsker seg et dataprogram som kan løse disse
oppgavene. Men like ofte er visjonene bredere og mer uklare (typisk for mange
bedriftsledere har vært at de ønsker å få hele bedriften inn på data, “information at your
fingertips”), og det er særlig da neste stadium er viktig. Som regel vil det vise at noen av de
planlagte delene er enklere å gjøre på andre måter, og litt sunn skepsis til at absolutt alt må
gjøres på data kan også lønne seg.
• Analyse
Man finner ut at man trenger et program, og bestemmer seg for å lage det. Problemet er:
oppdragsgiver er sjelden helt sikker på akkurat hva det er som trengs. Dette kan det ofte
være svært vanskelig å finne ut av, og resultatet kan fort bli mye fram og tilbake uten at man
får fastlåst en endelig versjon av programmet. Brukerne er sjelden de som lager det, og
dette kan skape problemer fordi det kan være vanskelig å garantere at utvikleren lager det
programmet brukeren vil ha.
• Design
1096 - Lars Marius Garshol 8