(Tore Berg Hansen og Greta Hjertø) I UP utvikles løsningen inkrementelt, i flere iterasjoner. Også UP har faser, se figuren nedenfor. Hver av fasene har en klar hensikt, men i motsetning til Fossefallsmodellen har ikke hver av fasene hovedfokus på én oppgave (som fullføres i fasen). Tvert imot vil man i hver av fasene i UP "gjøre litt av alt". Tanken bak er at dette er nødvendig nettopp for å oppfylle fasens hensikt. Veldig kort er dette hovedhensikten med fasene i UP:
Fasene, antaglig med unntak av Inception, gjennomføres i flere iterasjoner, . Hovedaktivitetene er i UP kalt disipliner, og som vi ser av figuren inneholder alle fasene alle disipliner, men hvilken disiplin vi har hovedvekten på, vil variere.
I UP organiserer vi resultatene i henhold til disiplinene og ikke i henhold til fasene. Det vil si at vi normalt samler resultatet av kravanalysen i ett dokument og av design i ett dokument, selv om vi arbeider med dette gjennom flere faser. Disse dokumentene vil da utvikle seg i flere iterasjoner, frem til det endelige resultatet. Versjonskontroll av disse dokumentene er derfor sentralt og viktig. Nedenfor finner du lenke til maler og retningsliner som er aktuelle når du skal følge en iterativ prosess som UP. Planlegging i UP.Dette er retningsliner for planlegging av et iterativt prosjekt med krav til innhold i planene. I tillegg til det som står i dette dokumentet, vil vi understreke at det også for et UP-prosjekt sterkt anbefales å gjennomføre en risikoanalyse. For retningslinjer for gjennomføring av risikoanalyser, henvises til Hansen, Tore Berg og Greta Hjertø: Kvalitet og programvareutvikling, kapittel 17.
Retningslinjer og mal VisjonsdokumentetRetningslinjer og mal KravdokumentetRetningslinjer og mal Designdokumentet (inkl. maler for beskrivelse av arkitektur og objektorientert design)Om testing og testdokumentasjon
|
|