Både i dine projekter her på uddannelsen og senere ude i den forsknings- og erhvervsmæssige virkelighed får du brug for at kunne producere en projektbeskrivelse.
Det er et tilbagevendende spørgsmål hvad en projektbeskrivelse egentlig går ud på. Hvad er det, hvorfor laver man den og hvordan?
Du bør som udgangspunkt gøre dig klart, hvad den skal gøre godt for: Den skal forklare projektets mål, indhold og rammer overfor projektets (mulige) interessenter. Denne målgruppe rummer typisk også personer uden forudgående kendskab til dit arbejde. Her på uddannelsen er det oftest din vejleder, der skal gives mulighed for at vurdere projektets muligheder og faglige potentiale tidligt i forløbet.
Derfor skal projektbeskrivelsen indeholde information om
projektets praktiske udgangspunkt - hvem, hvad, hvor, hvornår? d.v.s. basale oplysninger om navn, fag, uddannelse, tidspunkt, institution o.s.v.
projektets problemstillinger - hvad er det konkret, du vil løse gennem projektarbejdet og hvilken sammenhæng indgår dit projekt i. Det kan være du allerede har en konkret case i tankerne, og ellers kan der ofte med fordel opstilles en tænkt use case for den sammehæng projektet vil indgå i. Kom frem til den afgrænsede problemstilling (eller "opgave" om du vil), som bliver projektets overordnede mål (projektets problem-/opgaveformulering).
projektets gennemførsel - diskuter de tekniske løsningsmuligheder, du ser på baggrund af afgrænsningen og problem-/opgaveformuleringen og argumenter for, hvilken du vil arbejde med i projektet. Evt. løsningsskitser kan beskrive forskellige designaspekter (visuelle, interaktive, informationsmæssige, algoritmiske) produktet kan indeholde og/eller overordnede principper eller koncepter - henvis gerne til lignende produkter, der allerede eksisterer (referenceprodukter), men husk at holde fokus på hvad du vil i dit projekt. Hvordan har du i øvrigt tænkt dig at indsamle den viden, der er nødvendig for at projekt og produkt opnår faglig og teknisk kvalitet (litteratur, personer, undersøgelser o.s.v.). Tids- og ressourceplanlægning, hvor du overvejer faser, aktiviteter, milepæle samt får sat nogle ralistike rammer for projektet.
projektets dokumentation - hvordan disponerer du din rapport og hvad skal i det hele taget med i formidlingen af projektet
Der er ikke een rigtig måde at lave en projektbeskrivelse på, men ved at bruge ovenstående som retningslinje skulle du gerne få det centrale med. Vigtigst er, at du tænker på formålet med dokumentet og hvad læseren skal have ud af det. En disposition af projektbeskrivelsen kunne f. eks. se således ud:
Titel (undertitel), navn(e), datering, fag, sted
Introduktion
Indledende problemanalyse (case, interessenter og problemfelt)
Projekt- og produktmål
Diskussion af løsningskoncept - argumenter for det valgte produktprincip (f.eks. i kravmatrix mod alternativer)
Værktøjer (hardware, software mv) og metoder (modeller og fremgangsmåder)
Planlægning (f.eks. en foreløbig backlog og sprintplan afhængig af metodeplatform)
(Udkast til rapportens overordnede disposition)
Foreløbig litteratur/kilde-liste
Der er ikke noget endeligt facit for, hvordan man strukturerer ens projekt rapport, men den skal overfor en fremmed læser præsentere og dokumentere projektarbejdet og de resultater, der er opnået.
Nedenstående opremsning skal ikke forstås som en absolut skabelon for enhver projektrapport, og ikke som overskrifter på afsnit, men nærmere et bud på de elementer man bør have med i en god rapport. Det er desuden en god idé at lade en stor del af strukturen følge den metodeplatform og kronologi, man har fulgt i projektforløbet.
1. Indledning (tematisk mv. ramme)
Redegør for projektets rammer. Hvad handler projektet overordnet om? Hvorfor netop dette projekt, hvad gør det interessant? Hvor er vi henne fagligt og praktisk, dvs. hvad har du fundet ud af i forhold til det faglige område og de begreber der måtte knytte sig hertil?
2. Problem-/opgaveformulering
Konkret beskrivelse af det produkt der skal udvikles og de grundlæggende problemstillinger/opgaver der skal løses. Er der tale om en specifik case med konkrete interessenter, eller har du en simpel use case der beskriver anvendelsen af produktet? Det er ikke et absolut krav, men ofte en god ide at udarbejde en case beskrivelse, da det er med til at skabe klarhed om hvor du vil hen med produktet.
3. Planlægning og Projektudvilingsmetode
Redegørelse for de fremgangsmåder og metodeplatforme, projektgruppen har tænkt sig at benytte i forbindelse med analyserne og udviklingsarbejdet i øvrigt.
4. Indledende analyse og beskrivelse af projektets krav
Afdækning og undersøgelse af projektområdet med henblik på opstilling af projekt- og produktmål, herunder en indledende og teknisk funderet kravspecifikation som efterfølgende kan danne baggrund for f.eks. product backlogs i SCRUM eller lignende, alt efter hvilken projektudviklingsmetode man har valgt at følge. Indledende skitser, flowcharts og evt. klassediagram kan også udgøre en del af den indledende beskrivelse i forhold til at skabe overblik over hvad der skal med i projektet.
Følger man SCRUM vil det også være her at man, ud fra ovenstående, opstiller userstories og lignende til brug i første sprints product backlog.
5. Design og udvikling (kronologi og teknisk dokumentation)
Beskrivelse af hele den tekniske del af udviklingsprocessen. Dette vil generelt være det mest omfattende afsnit, og alt efter projekt vil det se meget forskelligt ud og typisk kunne underopdeles i flere underafsnit. Det afhænger i høj grad også af projektet, så det er meget svært at sige hvad det præcis skal indeholde
Eksempler på underopdeling kunne være:
planlagte sprints
diagrammer (skitser, flowcharts og klassediagrammer)
3D modellering
kommentarer til kode
tests
Opdelingen er ikke absolut, og men kan f.eks. godt have en opbygning med sprints som så til hvert sprint indeholder skitser, flowcharts, klassediagrammer, kommentarer til kode og/eller tests udført indenfor det enkelte sprint. Som nævnt i starten giver det ofte god mening at forsøge at beskrive arbejdet i den rækkefølge det også rent kronologisk har fundet sted.
6. Resultatopgørelse og konklusioner
Hvorvidt er målene fra problemformuleringen opfyldt. Hvor langt er løsningen i forhold til de krav (evt. user stories), man havde sat op. Hvad er opfyldt, hvad mangler (og evt. hvorfor)
7. Perspektivering
Kan den viden og de resultater, projektet har kastet af sig være relevant i andre sammenhæng og hvor? Hvilke potentialer kan ses?
8. Kilder
Faglitteratur, tutorials o.s.v. som I har benyttet. Det forventede omfang af fagligt stof er normalt svarende til 350-550 sider i løbet af året. På et enkelt projekt forventer man så ca. 50-100 sider. A/V-materiale kan godt indgå.
9. Bilag
Kildekode, logs, dokumentation af undersøgelser, større tabeller, test mv.