Projektplan for DIKU studenterprojekter

Transkript

1 Projektplan for DIKU studenterprojekter Forfatter: Anders Johansen, Softwareudvikler, Det Kongelige Bibliotek 29. januar, 2007 Projektplan version 1.0 Det Kongelige Bibliotek Postboks 2149, DK-1016 København K, (+45) , EAN:

2 Projektplan Generelt om projekter på Det Kongelige Bibliotek Vores oplæg til en projektplan ligner meget de omstændigheder vi selv arbejder under på Det Kongelige Bibliotek. Det betyder at planen er meget virksomhedsorienteret, med alt hvad det indebærer, for eksempel en iterationsorienteret opbygning med faste milepæle, og fokus på at afdække krav og lave opgavelister på et meget tidligt tidspunkt. Vi har med vilje forsøgt at fokusere på at eventuel programmering og andet eksperimentelt arbejde bliver udført så hurtigt som muligt, da det typisk er denne del af arbejdet der har en tendens til at vokse sig større end planlagt. Målet med projektforløbet er at få startet projektet på en god måde, etablere klare, konkrete mål og løbende følge op på dem. Det er som udgangspunkt også et mål at identificere de tilfælde hvor projektet ikke er levedygtigt på så tidligt et tidspunkt som muligt, til alles bedste. Vi forventer selvfølgelig ikke at dette vil ske, men i denne som vi bruger til vores rigtige projekter er det noget vi forsøger at lægge vægt på, da der altid er en risiko for at et projekt viser sig ikke at være levedygtigt når man lærer mere om det. Det er efter vores mening en væsentlig ting man kan lære af at skrive projekt i et virksomhedsorienteret miljø, og vi har derfor valgt at tage det med i projektplanen. Projektplanens struktur og faser Projektplanen har 5 milepæle, og derfor fire faser der hver varer 4 uger. Vi forventer at projektforløbet starter samtidigt med at gruppen og projektets titel ligger fast. Sidste milepæl i det egentlige projektforløb er aflevering af rapporten, men planen har også sat tid af til to generalprøver på projektforsvaret. Første milepæl: Projektstart, fastsættelse af hoved- og delmål En "kontrakt" udarbejdes i fælleskab. Dette er standard for bachelorprojekter, men bør også laves for andre typer projekter. Heri binder begge parter sig til at mødes 1 gang om ugen. Ved hvert møde forventer vi at den studerende har produceret noget skriftligt materiale, som vi kan forholde os til sammen, så det sikres at der er fremdrift i projektet. Dette skal være tilgængeligt for vejlederne senest klokken 12:00 dagen før mødet, så vi har tid til at forberede os. Kontrakten skal også indeholde en fælles forståelse af projektets indhold, omfang og mål, som vi sammen kan (og bør) revidere løbende. Der skal også udarbejdes en liste over konkrete delmål for projektet, gerne 5-10 punkter. Disse punkter kan vi så løbende diskutere fremdrift på undervejs i projektet. Punkterne bør deles op i "essentielle" og "ekstra kredit". De essentielle punkter skal - hvis de dækkes grundigt - gerne være tilstrækkeligt til at resultere i en rapport der kan opnå middelkarakter. Ekstra kredit punkterne skal give mulighed for at få højere karakter, hvis og såfremt de essentielle punkter er udført til mindst middelkarakter. Projektplan for DIKU projekter! 1

3 Endelig udarbejdes en læseplan for, hvilket baggrundsmateriale der skal læses op på, samt hvilke indledende undersøgelser der evt. skal laves. Ambitionsniveau for evaluering og test fastlægges og begrundes. Det kan indledende diskuteres, hvad den overordnede struktur skal være, såsom om programmet skal være batchorienteret eller interaktivt, hvilke udviklingsværktøjer der skal bruges, og eventuelt meget konkrete arkitektoniske overvejelser, såsom hvilke design patterns der kan være relevante for opgaven osv. På basis af diskussionerne om programmering udarbejdes en plan for test samt opsætning af testmiljø. Da dette er det første møde, er der ikke noget eksisterede arbejde der kan evalueres. Det kan dog med fordel overvejes, hvilken strategi der skal bruges her, og eventuelt hvilken rollefordeling der skal være i gruppen. Der skal gerne udarbejdes en skriftlig motivation og et midlertidigt abstract. Det midlertidige abstract er et godt redskab til at konkretisere, hvad målet med opgaven egentlig skal være i sidste ende. Anden milepæl: Konkretisering af arbejdsopgaver, udarbejdelse af detaljerede opgavelister Der skal ved dette møde udarbejdes en detaljeret plan for resten af forløbet. Listen over arbejdsopgaver fra sidste milepælsmøde genevalueres, og der udarbejdes målsætninger for, hvornår disse punkter skal være halvt og helt færdige, så man kan lave en midtvejsevaluering på hvert af dem. Dette gøres for at sikre at projektet ikke kommer ud på et sidespor, hvor der fokuseres for meget på enkelte punkter på bekostning af helheden. Det væsentligste er at løse de essentielle opgaver, så man ikke risikerer at der bruges for meget tid på at forsøge at opnå en høj karakter på bekostning af muligheden for overhovedet at blive færdig, eller at få en passende afrundet og ballanceret rapport. NB: Fra dette punkt skal hvert af punkterne på opgavelisten evalueres for fremdrift ved de ugentlige møder. Al nødvendig programmering til forarbejde forventes som minimum færdigplanlagt på dette tidspunkt, og skal helst eksistere som skelet/mock-up, eller - endnu bedre - som kørende programmer miljø skal være funktionelt, og i brug. Det kan evt. på dette møde evalueres om der kan være brug for yderligere (eller færre) redskaber her. Der bør på dette tidspunkt eksistere "use cases" for evaluering. For rapportens vedkommende skal enkelte indledende afsnit (motivation, introduktion, prior work) helst være næsten færdige på dette tidspunkt, og andre (designbeskrivelse, strukturbeskrivelse, plan for evaluering og test) forefindes som minimum som outline, helst på "tyk noteform". Afsnit om teststrategi og evaluering bør være delvist færdige, dvs. som outline, gerne Projektplan for DIKU projekter! 2

4 med så fyldige noter som muligt. Tredje milepæl: Midtvejsevaluering Midtvejsevalueringen er en mulighed for at gøre status over projektets tilstand. Det vurderes hvilket af de følgende fire scenarier man befinder sig i på nuværende tidspunkt: 1.Projektet er forud for planen og kan udvides med flere punkter for ekstra kredit 2.Projektet følger planen, og alt er OK 3.Projektet er lidt bagud, og kræver en ekstra indsats 4.Projektet er så langt bagud at det helt skal droppes på dette tidspunkt Dette er sidste chance for at tage flere punkter med i implementationsplanen for ekstra kredit, og det bør kun ske, hvis det vurderes at projektet er i scenarie 1, altså forud for tidsplanen. De ekstra kreditpunkter der vælges fra her skrives ind i rapporten med begrundelse for afgrænsning. På dette tidspunkt skal struktur for al kode helst være færdig. Det er et mål at der fremover i projektet kun introduceres mindre klasser mm., så resten af perioden kan fokuseres på test og evaluering af produktet, samt færdiggørelse af rapporten. Det skal evalueres om testmiljøet bruges som forventet (og nødvendigt). Hvis nogen dele af det nu er unødvendige, kan de passende droppes - skriv ind i rapporten, inkl. begrundelse hvis dette sker. Use cases for evaluering gennemgås og færdiggøres. For rapportens vedkommende skal indledende afsnit (motivation, introduktion, prior work, designbeskivelse, strukturbeskrivelse, plan for evaluering og test) helst eksistere i næsten færdig form på dette tidspunkt. Fjerde milepæl: Code freeze På dette tidspunkt kan projektet ikke længere udvides - kun beskæres. Hvis det ikke er meget sikkert at et af punkterne på opgavelisten kan færdiggøres i tide til rapportaflevering, skal det afgrænses, med begrundelse i rapporten. Dette punkt i planen skal helst svare til "code freeze", eg. kun trivielle eller absolut nødvendige ændringer laves i "produktet" herfra. På dette tidspunkt skal alt kodearbejde som tommelfingerregel være enten færdigt, eller næsten færdigt. Der udføres en kort evaluering af, om plan for løbende test overholdes. Projektplan for DIKU projekter! 3

5 af produktet bør være godt i gang, og helst færdig. Der skal på dette tidspunkt som minimum være fyldige noter til alle kapitler og afsnit. Femte milepæl: aflevering Som tommelfingerregel er det en god idé at planlægge med at rapporten skal være færdig en uge før den hårde deadline for aflevering. Årsagen er at der erfaringsmæssigt altid kommer en eller flere uforudsete hændelser i sidste øjeblik, såsom problemer med print af rapport, nedbrud af testmiljø, en bug i et centralt komponent, en artikel man burde have refereret dukker op eller lignende. Generalprøver Vi anbefaler at der afholdes mindst en, og gerne to generalprøver før fremlæggelsen. Målet er at fordele rollerne i fremlæggelsen så alle gruppemedlemmer får chancen for at give et individuelt bidrag, at sikre at der lavet et realistisk tidsbudget for fremlæggelsen, og at lave og afprøve en plan for fremlæggelse der som minimum dækker projektets hovedpunkter på en afrundet måde med en passende balance mellem detaljer og overordnet struktur. Husk at det ikke kan betale sig at prøve at få ekstra kredit, før det basale indhold er dækket fyldestgørende! Vi anbefaler at der som minimum laves et groft storyboard eller udarbejdes en liste over hoved- og underpunkter der skal dækkes. Punkterne bør deles op i essentielle og ekstra kredit, så man kan falde tilbage på de ekstra slides hvis der bliver tid til overs. Det er en god tommelfingerregel at hvert slide tager ikke under to minutter at præsentere, og helst ikke mere end fem minutter. Det er svært at gøre det hurtigere (prøv selv...), og hvis et slide tager mere end fem minutter betyder det oftest at man har prøvet at fylde for meget ind i ét slide - prøv i stedet at del det op i to eller flere. En anden god målsætning er at planlægge så der er ca. 10% tid i overskud. Så er der tid til at svare på eventuelle spørgsmål undervejs. Hvis I bliver færdige før tid, så har I muligheden for at falde tilbage på jeres ekstra slides for yderligere kredit. Projektfremlæggelse Med en grundig forberedelse og generalprøve(r) bør fremlæggelsen være en smal sag. Selvfølgelig kan der altid ske uforudsete hændelser, men her skal man så netop kunne falde tilbage på den træning man har givet sig selv i tiden op til præsentationen. Sørg helst for at have eventuelt materiale til præsentationen i flere formater, så I har noget at falde tilbage på, hvis teknikken svigter. Klassiske problemer er manglende kabler, præsentation i et format som den maskine der virker med projektoren ikke kan håndtere, slides lavet i en anden opløsning end projektoren understøtter... Projektplan for DIKU projekter! 4

6 Tidsplan Dato Opgave < 14. februar Interesserede deltagere kontakter KB, og projekter konkretiseres. 15. februar Projekttitel og deltagere ligger fast. DIKU informeres om dette. 16. februar Første milepæl: Projektstart og fastsættelse af hoved- og delmål. 22. februar Synops indlevers på DIKU. 23. februar Første faste ugentlige møde. 28. februar Synopsforsvar på DIKU. 2. marts, 9. marts Faste ugentlige møder. 16. marts Anden milepæl: Konkretisering af arbejdsopgaver, udarbejdelse af opgavelister. 30. marts, 6. april, 13. april Faste ugentlige møder. 20. april Tredje milepæl: Midtvejsevaluering. Projektet evalueres, og det besluttes om de skal udvides, beskæres eller i værste fald helt droppes. 27. april, 4. maj, 11. maj Faste ugentlige møder. 18. maj Fjerde milepæl: Code freeze. Projektet evalueres igen, og omfang kan evt. justeres. 25. maj, 1. juni, 8. juni Faste ugentlige møder. 13 juni aflevering. 13. juli Første generalprøve på fremlæggelse. 20. juli Anden generalprøve på fremlæggelse. 27. juli eller 28. juli Projektfremlæggelse. Faste deadlines er fremhævet med fed skrift. Bemærk at der både er interne deadlines/milepæle, og eksterne i forhold til DIKU, såsom afleveringsfrist for synops osv. Denne plan er kun et oplæg. Fredag formiddag er valgt som fast mødetidspunkt, men det er selvfølgelig muligt at aftale en anden mødedag, hvis andre forpligtigelser (kurser mm) gør det nødvendigt. Projektplan for DIKU projekter! 5