Realisering vil si å utvikle selve systemet, for eksempel databasen. Realisering vil derfor i større eller mindre grad innebære programmering. Dvs å lage en Applikasjon. Applikasjonen lager man i et såkalt utviklingsverktøy. Utviklingsverktøyet kan være Access; Applikasjonen blir da En database. Alternativt kan man programmere HTML og JAVA i Notisbok. Og kan da få En hjemmeside.

Ofte vil man oppdage mangler ved Kravspesifikasjon og Datamodeller når man programmerer. De er da lurt å gå tilbake og korrigere modellene og Funksjonskravene.

Kriterier for at et system skal ha god kvalitet og brukervennlighet:

*Brukerne må kunne stole på systemet. Det betyr: få systemfeil, Ingen tap av data

*Riktige funksjoner i systemet, slik at brukerne får gjort det de skal.

*Sikkerhet mot misbruk, ulovlig tilgang, ulovlig kopiering, og uautorisert forandring av viktige data.

*Er dataene pålitelige?

*Kortest mulig opplæring

*Mest mulig effektivt system; mindre tid enn før, Færre operasjoner enn før for å gjøre det samme.

*Minst mulig behandlingstid

*Færrest mulig feil

*Lage brukergrensesnitt

*Kode programmer

*Teste programmer og rutiner

*Lage brukerveiledning

*Fullføre systemdokumentasjon.

Brukergrensesnitt er kontaktflaten mellom bruker og system. Dvs: den delen av systemet brukeren ser og kommuniserer med: Menyer, kommandotaster, mus, etc.

Grafisk brukergrensesnitt betyr at brukeren kommuniserer med datamaskinen ved å flytte på og klikke på grafikk (Figurer; IKONER, og kommandotaster)

I framtiden vil Lyd og film bli en stadig viktigere del av grensesnittet. (Altså: man vil kommunisere ved hjelp av lyd og Film)

Det er spesielt viktig at brukerne utarbeider ønsker om brukergrensesnitt når man lager kravspesifikasjon.

Nyttige tips for utvikling av et godt brukergrensesnitt:

1. Legg ikke inn for mye informasjon i skjermbilder. Et vindu kan fort bli uoversiktlig. Grupper informasjon som naturlig hører sammen.

2. Det må være kortest mulig svartid på kommandoer. Systemet må gi melding om at den arbeider.

3. Vinduer og skjermbilder bør være mest mulig like: Samme layout, fargebruk.

Knappetrykk bør ha samme effekt i alle menyer.

4. Det skal være lov til å angre. Man skal kunne lukke en meny, hvis man har åpnet feil. Hvis man har skrevet feil skal det være mulig å slette det man har skrevet.

5. Minst mulig støy i skjermbildene: ingen animasjoner eller lyd. Dempede farger.

Bruk mest mulig like skrifttyper.

6. Programmene må virke på samme måte som brukeren tenker. Dvs: Brukeren skal kunne gjøre jobben på sin vante måte i systemet, og slippe å forandre på prosedyrer. Språkbruken må være kjent av brukeren.

7. Samme type informasjon bør ha samme farge.

8. Unngå feilregistrering. Registrer data automatisk der det er mulig. Manuell registrering vil gi mye feil. Automasisk registrering kan bety å bruke ulike slags måleinstrumenter som leser tallkoder, eller å laste data ned fra andre systemer.

9. Bruk ulike kontroller på data som man legger inn:

Oppslagsfelt som henter data fra andre tabeller. Hvis vi skriver inn data selv, så blir det oftere feil.

Referanseintegritet: dette sikrer at sammenhørende data finnes i systemet. For eksempel så sikrer det at en utleid film ikke bare er registrert som utleid, men også som en film i filmregisteret med all nødvendig info.

Når man programmerer bør man alltid lage en prototype som brukerne får teste. Etter en test er det som regel nødvendig å forandre på programmet.

Del programmet opp i moduler som er klart adskilte og mest mulig enkle.

Dette gjør det enkelt å forandre og supplere applikasjonen.

I access: Lag Standardtabeller for fx. Postadresse, kundetyper, biltyper etc som kan brukes i mange systemer.

Lag en lukkemakro som kan brukes i alle skjemaer.

Utskrift av Datamodeller, Skjemaer, Feltdefinisjoner, relasjoner. Eventuell Programkode.

God dokumentasjon forenkler oppdatering.

Testing av flere årsaker:

For å oppdage feil

For å finne ut om det virker som det skal . Dere bør for eksempel teste alle skjemaer i Access

For å se om brukerne er fornøyde

For å test brukergrensesnittet

Veldig ofte er det nødvendig å forandre på en applikasjon etter testing.

Idealet er at systemet skal være selvdokumenterende. Det betyr at det skal være så enkelt at man skal greie seg uten veiledninger. Hjelpefunksjoner som er innarbeidet i systemet skal være nok.

I praksis lager man likevel brukerveiledninger. De bør inneholde det følgende:

*Hva systemet kan brukes til

*Krav til Hardware og Software

*Hvordan installere

*Forklaring av menyvalg

*Bruk av knapper

*Sikkerhetskopiering

*Alfabetisk oversikt over viktige feilmeldinger

• En komplett dokumentasjon bør inneholde:
• Kravspesifikasjon
• Krav til Hard og soft-ware
• Navn på utviklingsverktøy og versjon (Access 97)
• Dataflytdiagrammer
• Datakatalog og prosessbeskrivelse
• Datamodeller
• Liste med programkode
• Kopier av skjemaer og tabeller med feltkoder
• Definisjoner på rapporter og spørringer
• Makrokode
• Definerte brukere med ulik autorisasjon

VIKTIGE OPPGAVER:

• Opplæring
• Installasjon
• Konvertering av data og utstyr
• Godkjenning av systemet i drift

OPPLÆRING

Alle brukerne må få opplæring og anledning til å teste systemet med testdata.

I mange bedrifter i dag har man spesielle personer som driver med brukerstøtte. Som underveis hjelper og veileder brukerne av systemet.

KONVERTERING

Det vil si å kjøpe nytt Hardware, og å flytte data fra et gammelt system til et nytt.

Konvertering av data slik at det kan leses av andre dataprogrammer kan ofte være problematisk og tidkrevende. I verste fall må alt legges inn manuelt en gang til.

GODKJENNING

Til sist må systemet godkjennes av oppdragsgiver. Det må testes nøye, og man må vurdere om avtalen er overholdt.