Udviklingsmetoder

Indenfor systemudvikling findes der en række metoder, man kan bruge til at planlægge og organisere sit arbejde på. Alle metoder arbejder med disse:

• Forudundersøgelse
  Her undersøger man målgruppen og deres behov. Udefra målgruppen og brugernes behov, vurdere man hvad der er vigtigst at udvikle på først og hvornår det skal gøres.
  
• Kravspecifikation
  Her finder man ud af hvilke krav produktet har. Det kunne eksempelvis være hvad produktet skal kunne, hvilken kvalitet og med hvilken teknologi skal man bruge.
  
• Design
  Udefra kravene designes løsningen. Der designes på produktets opbygning, struktur og grænseflade.
• Konstruktion
  Her påbegyndes programmeringen af produktet på baggrund af designet, så det kan anvendes af brugerne. Her tester man undervejs for fejl. Før produktet bliver frigivet, udføre man en række accepttest af brugerne.
• Videreudvikling
  Her har man fokus på at produktet forsat bliver videreudviklet, efter det er taget i brug.

Udviklingsmetodernes grundlæggende syn

Lineært syn
Dette syn afspejles blandt andet i vandfaldsmodellen, som bygger på at alle krav til et system kan defineres på forhånd. Man analyserer og designer systemet i dybden først, og derefter udvikler. Kaldes en plandrevet proces, da man laver planer for projektet i starten af processen.

Evolutionært syn
Med dette syn mener man ikke, at man kan definere kravene på forhånd, men først når man er færdig vil man kende kravene. Her udvikler man lidt af gangen, hvor brugeren undervejs giver feedback og man tilpasser løbende, ud fra de nye erkendelser.

Store projekter
Ved større projekter, hvor en større virksomhed f.eks. har et ønske om at få udviklet et system der understøtter deres daglige arbejdsopgaver, bliver der foretaget en analyse af organisationen og dets brugere og opgaver. Analysen udarbejdes med henblik på at vurdere behovet for it-systemet og forbedringer af arbejdsgangene. Når opgaven bliver sat i gang laves der en kravspecifikation.

Vandfaldsmodellen

Vandfaldsmodellen er en af de første udviklingsmodeller og er inspireret af (Fowler 2000). Det er er en klassisk lineær model der går igennem faserne: Forundersøgelse, krav, design, konstruktion og test. Her laver man en forundersøgelse og derefter beskriver man kravene. Dernæst begynder man, at designe løsningen og til slut konstrueres og testet. I hver fase producere man et eller flere dokumenter, som skal godkendes af både udvikler og kunde, før fasen kan ses som afsluttet. Her involveres brugeren ikke før produktet er færdig og testet. Vandfaldsmodellen er en plandrevet proces. I en plandrevet proces skal alle aktiviteter være planlagt, før man kan begynde at udvikle på det.

Fordele og ulemper ved modellen:

• Den er nem at bruge
• Nemt at videreudvikle produktet pga. den grundige dokumentation
• Klare ansvarsområder
• Der er risiko for at man laver fejl i og med at brugeren ikke inddrages tidligt i processen.

Modellen er god at anvende, hvis kunden ved hvad han/hun skal have. Modellen bliver stadig meget anvendt og passer godt på kortvarige projekter, hvor man kender kravene og domæne.

• Man kan ikke kende alle de krav og behov der er. Det med at stille krav fra starten af er vanskeligt da krav kan ændre sig på 2 måder. Krav reelt ændrer sig. Eksempelvis:” vi skal lave noget der køre i en bestemt opløsning der er moderne – men 3 år efter er denne opløsning ikke moderne. Hvad er det for en platform vi arbejder på – platformen kan ændre sig.
• Kundegruppen ændrer sig
• Har vi et langvarigt projekt kan ting ændre sig.
• Nye elementer, teknologier kan gøre at vi ændre kravene.

• Ofte overraskelser undervejs
• Ofte forsinkelser og dyre
• Man kan opleve at det produkt vi ude med ikke dækker behovene. (kan skyldes at man har planlagt dårligere)

Prototyping og evolutionær systemudvikling

Her bygger man på en antagelse af, at kravene er uforudsigelige og at man ikke har mulighed for at fastlægge dem på forhånd. Man danner kravene i takt med udviklingen ved at simulere hvordan man har tænkt sig at produktet skal virke. Der udvikles lidt af gangen samtidig med at man viser resultatet til brugeren, så man kan videreudvikle på deres feedback. En prototype er med andre ord en grovskitse i form af en tidlig version af systemet, som man bruger til at vise sin ide med, så man kan få feedback på sin ide og dermed danne nye ideer.

Agil udvikling

Agil udvikling kan oversættes til fleksibel udvikling. Og er en udviklingsmetode hvor man har en grundlæggende antagelse om, at verden forandre sig hurtigt og kræver derfor at vi har en omstillingsdygtig udviklingsproces, hvor man hurtigt kan håndtere de skiftende krav.

Et opgør med dokumentation og administration: Man dokumenterer meget tidligt og dokumenterne låser sig fast. Hvis vi kan dokumentere lidt mindre, kan man være mere effektiv. SCRUM er en af de mest anvendte agile metoder.

Det agile manifest

• Individer og samarbejde frem for processer og værktøjer
  Der kan gå for meget proces i det – i stedet for at arbejde meget i processen kan man vælge at arbejde sammen. Gør projektdeltagerne til mindre maskine og mere individ, ved fx ikke at styre deltagerne for stramt.
• Velfungerende software frem for omfattende dokumentation
  Hænger sammen med ovenstående. Her tager man fat i dokumentationen og kigger på hvad fokus man skal have, på software og måske lidt mindre på dokumenter. Et vigtigt dokument er kontrakten.
• Samarbejde med kunden frem for kontraktforhandling
  Kontraktforhandlingen er vigtig, men er ikke det vigtigste. Nogle gange er det bedre at samarbejde med kunden fremfor at gå op i kontraktforhandlingen. Kunden frem for det juridiske. (måden vi er på)
• Håndtering af forandringer frem for fastholdelse af en plan
  Hænger sammen med ovenstående. (Måden vi ser os på)

Scrum

Er en agil metode, der bruges til at beskrive hvordan man skal planlægge og gribe projekter an. Metoden tager ikke stilling til hvordan udviklingen skal foregå. Der findes bliver brugt rigtig meget i tiden, idet mange virksomheder bruger denne metode til at få styr på deres projekter. I Scrum udarbejdes et såkaldt ”sprint”, som er et forløb. Ved hver sprints afslutning, skal der være noget færdigt, der i teorien kan gives til kunden. Scrum bruges for at opnå en effektiv kommunikation og commitment.

• De tre roller, som består af en produktejer, Scrum-master og et team.
• Der foregår 3 ceremonier, som er: Sprintplanlægningsmøde, dagligt stand up-møde og sprint review samt ”retrospective”
• Består af 3 værktøjer, som er produktbacklog, sprintbacklog og burn down-graf

Elementer i scrum

Produktejer:
Er den produktansvarlig, der prioritere og bestemmer hvad der skal laves. Den produktansvarlige skal sørge for at prioritere kundernes interesser og opstille et mål for et sprint.

Produktbacklog
Backloggen fungere som en slags kravspecifikation og det er her alle krav og ønsker registreres. Backloggen skal danne overblik over krav og specifikation. Man opstiller de højst prioriterede krav øverst i backloggen.

Sprint
Før man kan begynde på et nyt sprint, skal produktejer prioritere produktbackloggen på ny sammen med kunden, hvor man derefter kan fastlægge målet for sprintet.

Når udviklingen af et nyt sprint sættes i gang må produktejer ikke ændre på tingene eller tilføje nye opgaver.

Sprintplanlægningsmødes
Denne fase træder i kraft efter at man har gennemgået produktbackloggen med kunden. Springplanlægningsmødet går ud på at produktejer sammen med teamet beslutter hvad der skal ske i næste sprint. Her tager man udgangspunkt i mål, prioriteringer, estimater samt teamet udviklingshastighed. Efterfølgende flytter man kravene fra produktbackloggen til en sprintbacklog, hvor man så nedbryder kravene til mindre opgaver (tasks) og man laver en taskboard (to do liste)

Scrummaster
Fungere som en slags coach og er en mellemmand mellem teamet og produktejeren. Scrummasterens ansvar er at holde støj væk fra teamet, sørge for ressourcer og holde lede det daglige standup møde.

Story
Er kravene og kan skrives på følgende måde eksempelvis: ”Som bruger vil jeg gerne kunne finde billige rejser”

Standup møde
På dette møde er det vigtigt ikke at diskutere. Det er teammedlemmerne der må tale. Andre må gerne deltage i mødet, dog uden at sige noget. På dette møde opfølger man på planen og man får fordelt opgaver gennem disse spørgsmål:

• Hvad fik vi lavet igår?
• Hvad skal vi have lavet i dag?
• Er der forhindringer?

Sprintbackloggen og taskboard
Vises som ”stories” i venstre side af taskboardet. Disse storys nedbrydes til tasks, der prioriteres og sættes ind i to-do feltet, udefra den story den hører til. De tasks man skal arbejde på til dagen efter, smides ind ”in Progress” under dagens standup møde. Hvis en task er udført smides den over i ”verify” feltet, hvor den bliver gennemset af et andet teammedlem, som tester eller kommentere på den. Når den er godkendt flyttes tasken over i ”done” feltet. Med denne metode kan man bedre holde styr på hvad man er noget til og hvad man mangler.

Kilde: https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/task-boards

Kilder: