Prototyping betyder systemudvikling ved hjælp af prototyper (modeller), og skal ses i modsætning til traditionel systemudvikling fx vandfaldsmodel eller gradvis udvikling .

Generelt kan prototyper opdeles i to kategorier, nemlig prototyper, der skal indgå i det færdige system , og prototyper, der skal smides væk.

Den anden kategori har udelukkende til formål at hjælpe med at komme til klarhed over, hvilke krav der skal stilles til et nyt system.

En " smid-væk-prototype " kan i sin simpleste form blot være papirudgaver af skærmbilleder, eller det kan være et mere avanceret kørende system med mulighed for inddatering, beregninger osv.

Ved systemudvikling med prototyper bør brugerne inddrages i en aktiv rolle, frem for bare passivt at godkende eller afvise det, som systemudviklerne har lavet.

I visse tilfælde er det fx brugeren selv, der designer skærmbilleder, men det kræver naturligvis, at man har et 4.generationsværktøj til rådighed, således at bruger og designer kan sidde sammen og direkte lave en interaktiv prototype.

Traditionel systemudvikling er ekspertstyret, og kører i en stram tidsplan efter en bestemt fasemodel , hvor hver fase afsluttes med en rapport før næste fase igangsættes, og der kan ikke vendes tilbage til en tidligere fase.

Systemer, der udvikles ved prototyping kan enten ende med at blive smidt væk eller indgå i det færdige system.

Prototyper kan også forfines til færdige systemer, hvilket ikke er tilfældet med traditionel udvikling efter vandfaldsmodellen, hvor udviklingsprocessen er stramt fremadskridende

Ifølge SYSKON bør systemudvikling systematiseres ved opdeling i en række klare velafgrænsede faser. SYSKON angiver otte faser, som hver især defineres som afsluttet, når der er udarbejdet en rapport.

• Idéfasen
• Analysefasen
• Skitsefasen
• Projekteringsfasen
• Specifikationsfasen
• Programmerings- og testfasen
• Konverteringsfasen
• Driftsfasen

I dag betragtes SYSKON som en forældet systemudviklingsmetode, dels fordi den har en meget stram faseopdeling, der ikke levner mulighed for iterativ systemudvikling, og dels at brugerne i praksis nærmest slet ikke inddrages.

Et noget mere moderne udgangspunkt skulle være en (modificeret) socioteknisk fasemodel , hvor der jo som bekendt sker en brugerinddragelse, og hvor oplæring af brugerne allerede starter i initial-fasen før den egentlige udvikling igangsættes. Her er fordelen at der er styr på både økonomi og det juridiske, medens ulempen er, at der grundlæggende set, er tale om en sekventiel proces.

"XP er en proces, der tillader frembringelse af software, som kan leveres til tiden, opfylder kundens behov, fungere, vedligeholdes og udvides." - ja det lyder jo vældig flot, men der er ikke nogle nye teknikker i XP. Alle fremgangsmåderne er gammelkendte og har været forsøgt før. Og alle er de havnet på den metodiske losseplads i tidens løb. Det nye i XP er sammenstillingen af teknikkerne på en måde, der tillader dem at holde hinandens svagheder i skak. Der er ikke tale om ekstreme handlinger, men om at bruge nogle snusfornuftige teknikker, i en ekstremgrad.

XP er baseret på fire værdier:

Det første skridt i XP er, at et softwareprojekt kan ses som et kontrolleret system med fire indbyrdes afhængige variable: Pris[cost], kvalitet, tid og indhold[scope]. At de variable er afhængige betyder, at når de tre af dem holdes fast, vil systemet give den fjerde.

XP er empirisk, hvilket blot betyder at den er opstået igennem praksis. XP går i bund og grund ud på at gøre det vi godt ved, er det rigtige.

XP anvendes kun i projekter af begrænset størrelse. Da XP er kendetegnet af kommunikation, er det antallet af deltagere der gør et XP projekt større eller mindre. Der kan arbejdes med op til 10-12 projektdeltagere. Man kan derefter enten dele op i flere selvstændige projekter, eller bruge nogle af de mekanismer der tilbydes i de andre 'Agile' metodikker, for eksempel i SCRUM.

XP er iterativ og bruger dermed ikke en såkaldt 'Over-the-Wall' kravspecifikation.

XP har to målgrupper, der derfor støttes kraftigt og direkte af de 12 'Practices', men som det vil føre for vidt at redegøre for her, men se evt. nedenfor under referencer.

• Den ene er kunden der oplever at få det maksimale udbytte af sin investering.
• Den anden målgruppe er udviklerne, der får professionelle arbejdsforhold. De gives muligheder for at gøre det de gerne vil: levere software af høj kvalitet. De får et afklaret grundlag at arbejde på, de får mulighed for at teste resultatet af deres arbejde, og de får klar feedback.

Referencer.

Systemudvikling er den proces, som gennemløbes, når et nyt it-system skal udvikles. Systemudvikling indebærer normalt fire typer aktiviteter:

• Systemanalyse, dvs. den proces at studere og beskrive noget eksisterende, fx et eksisterende edb-system samt nogle manuelle arbejdsrutiner. Uddata fra denne aktivitet vil ofte være en kravspecifikation
• Systemdesign, dvs. den proces at beskrive noget nyt. Uddata fra denne aktivitet vil ofte være en detaljeret design-specifikation
• Systemkonstruktion, dvs. den proces at omsætte design-specifikationen til et program, der kan køres på en computer. Endvidere vil denne proces omfatte afprøvning
• Indførelse, dvs. den proces, hvor IT-systemet tages i brug i organisationen. Denne aktivitet omfatter fx uddannelse af fremtidige brugere samt idriftsætning af det afprøvede edb-system

Ovenstående fire typer aktiviteter bliver i forskellige systemudviklingsmetoder opdelt i en række faser, der enten gennemløbes på en bestemt måde, som i vandfaldsmodellen , eller hvor der er mulighed for at vende tilbage til en tidligere aktivitet (iterativ systemudvikling), hvilket er den grundlæggende idé i prototyping.