Man gjør systemet ferdig før det testes; endringer vil være vanskelige og kostbare.

Passer på systemer som er klare og oversiktlige; der man vet hva systemet skal gjøre; kravspesifikasjonen kan settes opp nøyaktig. (Styringsprogram for en Vaskemaskin). Analytisk metode er også nødvendig hvis systemet er stort; ellers blir det bare kaos.

Fordeler: Det går raskt og effektivt å lage systemet. Man kan få gode datamodeller.

Ulemper: Man kan ende opp med noe som ikke kan brukes.

Man eksperimenterer seg fram til et system som dekker brukernes behov. Brukerne er tett involvert i utviklingsprosessen; De tester ut de ulike forslagene og kommer med tilbakemelding. Ofte vil man utvikle et system og lage tilføyelser hele tiden.

Fordeler: Man får et system som er anvendelig og løser problemene som brukerne har

Ulemper:

Mye Tid og penger.

Hvis systemet er stort vil man kunne få en dårlig løsning, fordi man ikke har brukt modelltenking og analytiske metoder. Datamodellene kan bli dårlige. Hele tiden så føyer man til nye elementer i systemet; hvis systemet er stort så kan det da bli veldig rotete og uoversiktlig.

Man kan ha laget et system uten å lage modeller, kun gjennom prototyping. Så oppdager man, etter en stund at det trengs et mye større system. Og at man ikke har oversikten. Da må man inn med analytisk tenkning; lage modeller. Det betyr at man har kastet bort mye tid og penger.

DET BESTE ER Å: Bruke en kombinasjon av disse metodene. Avhengig av tid, penger, størrelse, viktighet.

For at et system skal bli bra er det altså to viktige elementer:

Når vi bruker Spiralmodellen vil vi velge mellom Den analytiske metode eller prototyping.

I tillegg vil vi i hver fase av utviklingsarbeidet foreta en risikoanalyse. Det vil si at vi kartlegger mange forskjellieg løsninger/valgalternativer med ulike risiko (For suksess og fiasko). Man vil så velge det alternativet med minst risiko (for fiasko) som samtidig fører til at målet nås.

Spiralmetoden har sitt navn etter det følgende: Etter hvert trinn, når man har foretatt et valg vil man gå tilbake og se på konsekvensene for personalet, organisasjon, kostnader og andre begrensninger og krav . Og så vil man eventuelt foreta et annet valg, hvis konsekvensene er negative.

Se figur side 103

Viktige grunner til at prosjekter(generelt) mislykkes:
*Menneskelig svikt

*Urealistiske framdriftsplaner og budsjetter

*Dårlig brukergrensesnitt (Uforståelig å bruker)

*For høyt ambisjonsnivå

*Endringer i krav

Disponerer tiden fritt: vi kan jobbe med det når vi har tid. Det vil derfor ikke gå utover annet arbeid.

Færre misforståeler: Det er vi som kjenner organisasjonen og hva systemet skal gjøre

Spare kostnader (dette kan slå begge veier)

Mangelfull dokumentasjon (Dvs: Skriftlig redgjørelse for hvordan det virker) Dette vanskliggjør Endringer

Dårlig kontroll av inndata. For å få gode inndata kreves gode inndatamasker og andre sperrer (referanseintegritet fx). Det er ofte kun eksperter som forstår betydningen av dette og hvordan det skal ordnes

Maktkamper internt i organisasjonen kan føre til at man får dårlige systemer, Pressgrupper kan prøve å få spesielle løsninger. En ekstern konsulent vil være uavhengig.

Dårlig samspill med andre systemer. Igjen: hvis et system skal arbeide med andre systemer; utvekslse data fx, så kreves det spesialkunnskap

Hvis bedriften ikke har gjort slikt før kan man få problemer med tod og kostnadsberegninger. Det kan derfor bli mye dyrere enn man hadde tenkt.

Slurv med sikkerhetskopiering

Manglende samsvar mellom Hard og Software. Det kreves mye kunnskaper for å ta gode besluttninger her.

Brukere i bedriften har en tendens til å se på kortsiktige problemer. Mens eksterne eksperter som har laget slike systemer før vil ha et bredere perspektiv. De vil se andre bruksområder for systemet, hva som kan bli ønskelig på sikt, etc