Göm menyn

TDDI02 Programmeringsprojekt

Erfarenhetsrapport


Nedan instruktioner härrör från Olle Willen med tillägg av Klas A.

Erfarenhetsrapport, Reflektionsdokument, Efterstudie

Detta dokument ska ni skriva för att få anledning att begrunda den process ni gått igenom, samla ihop de tankar den givit upphov till, och summera erfarenheter som kan ligga till grund för framtida projekt/verksamhet. Rapporten i sin helhet bör vara ett par A4-sidor.

Relatera till den 'tidsplan' ni (väl?) satt upp, eller de förväntningar ni med all säkerhet haft. Reflektera annars om hur en bättre planering kunde undvikit några problem ni haft eller hjälpt er på annat sätt.

Gå igenom projektets olika faser (krav, design, implementation, leverans), en i taget. Skriv för var och en ner hur er plan sett ut, och huruvida ni lyckats hålla er till den eller ej. Analysera orsakerna till att ni eventuellt blev sena, och beskriv hur ni löste de problem ni stötte på. Eller tvärtom; av vilket skäl gick det bättre än ni förväntat er. Blev denna fas' slutprodukt bra nog för att ligga till underlag för nästa fas, eller inte? Vad bestod dess brister i? Vad kunde gjorts bättre, sett ur det perspektivet?

Blev till sist slutprodukten vad ni från början hade hoppats? Vilka faktorer bidrog till att det gick som det gick?

Slutligen ska varje gruppmedlem för sig (ange vem!) beskriva den allra viktigaste personliga erfarenheten/kunskapen som projektarbetet bidragit till, och som säkerligen kommer till nytta i kommande programmeringsprojekt (eller 'yrkesliv').

OBS! Dokumentet är INTE en kursutvärdering, utan en samling arbetserfarenheter som är värda att komma ihåg till nästa projekt ni är med i. En form av "självutvärdering". Har ni synpunkter på kursen lämnar ni dem separat till examinator.

Vad räknas (inte) som en dokumenterad erfarenhet?

Att skriva ned sina erfarenheter kräver lite eftertanke. Det gäller att skriva ned tillräckligt för att en oinsatt läsare skall kunna göra samma positiva erfarenhet i ett eget projekt, alternativ kunna undvika en negativ erfarenhet. Det bör för varje erfarenhet framgå:

  • Hur ni gick tillväga, vad ni gjorde, hur ni gjorde, och varför ni valde den metoden
  • Vad resultatet blev, om tillvägagångssättet ledde till något positivt eller negativt
  • Varför ni är nöjda eller missnöjda med resultatet och varför det blev som det blev
  • Lite reflektion (efterklokhet) om hur ni tror ni kunde gjort istället för att få (ännu) bättre resultat

Exempel på en bristfällig/intetsägande "erfarenhet": "Revisionshantering via SVN har fungerat mycket bra och hjälpt alla utvecklare i projektet."

Exempel på en bättre formulerad erfarenhet: "Vi använde revisionshantering via SVN. Detta hjälpte alla utvecklare hålla reda på senaste versionen och underlättade distributionen av färdiga moduler mellan utvecklarna. Vid två tillfällen kunde vi hitta fel som uppstod snabbt tack vara historiken. Ett problem var att kod som inte fungerade checkades in vid flera tillfällen och det slarvades även med att kommentera vad som checkades in. Detta gjorde att utvecklare spenderde onödig tid på felsökning. Vi borde kommit överens om att bara checka in testad och fungerande kod, men ändå ofta, en modul i taget."

Döm själv vad som saknas i de två exemplen enligt punkterna ovan. Döm vilket exempel du själv helst skulle vilja läsa i förberedelsefasen för ett projekt.


Sidansvarig: Klas Arvidsson
Senast uppdaterad: 2012-10-30