• Projektgruppen
• Lärare: projektledning, säkerhet, systemprogramvara, MTS

• Skriftlig projektrapport: grupp-x-rapport.pdf
• Intern-PM: grupp-x-pm.pdf
• Rapport över grupp-processen: grupp-x-process.pdf

Presentation

Det är viktigt att anpassa presentationen till en bred publik. Följande punkter bör ingå i presentationen:

• En översikt över kraven på systemet - funktionella och icke-funktionella.
• En beskrivning av viktiga arkitektur- och designbeslut, med fokus på sådana som är motiverade av funktionella eller icke-funktionella krav.
• En genomgång av systemets säkerhet och tillförlitlighet, knutet till riskanalysen.
• Projektets utfall i förhållande till den ursprungliga planeringen avseende syfte, mål, krav, risk, grov tidsplanering och budget, samt teamets generella lärdomar kring projektplanering, projektorganisation, mm.

Demonstration

Vid demonstrationen ska ni visa hela ert system, och demonstrera att kraven på det är uppfyllda. Demonstrationen kommer att ske inomhus, vilket innebär att GPS-mottagaren inte kommer att fungera. Ni måste utforma något sätt att komma runt denna begränsning (till exempel genom att simulera GPS-koordinater).

Vid demonstrationen förväntas ni demonstrera:

• Att den viktigaste funktionaliteten är implementerad och fungerar, och att handenheterna hålls uppdaterade med korrekt information.
• Att kommunikation mellan handenheter fungerar.
• Att systemet klarar att nätverket försvinner.
• Att systemet klarar differentiering av meddelanden vid låg batterinivå.
• Att systemet klarar kraven på feltolerans.

Projektrapport

Den skriftliga slutrapporten av projektet ska innehålla en sammanfattning på en halv till en sida som beskriver problemet och hur er lösning svarar mot behoven. Det här är en så kallad "executive summary" riktad till personer utanför projektet och till personer som vill få en snabb överblick över resultaten.

I inledningskapitlet beskrivs projektets bakgrund, syfte, och begränsningar. Här knyter ni samman alla deluppgifterna och förklarar vad rapporten ska handla om och beskriver hur den är upplagd.

Därefter följer en beskrivning av produkten.

Därefter följer ett avsnitt som beskriver identifierade krav, samt aspekter som pålitlighet och säkerhet. En uppdaterad riskanalys och en analys av tillförligheten i systemet ska ingå i rapporten.

Därefter följer en mer detaljerad beskrivning av projektresultaten, inklusive krav (med motiveringar och anknytningar till t.ex. MTS och etik-ämnena), arkitektur och de delar av den detaljerade designen som är viktig för produktens egenskaper eller kravuppfyllnad. Om ni under projektets gång har dokumenterat varje backlog item ordentligt, så bör det här avsnittet nästintill vara skrivet vid varje givet tillfälle i projektet.

Avslutningsvis knyter ni ihop hela arbetet genom att dels se tillbaka, dels blicka framåt. Det kan till exempel finnas förslag på framtida utvecklingsmöjligheter och alternativa användningsområden. Systemet kanske med bara smärre modifieringar skulle fungera i andra tilllämpningar än just krishantering.

Rapporten kan behöva flera bilagor (tabeller, bilder, diagram, etc.) vilket gör att längen på rapporten växer. Men för den skriftliga delen beskriven ovan skall inte mer än 8 sidor disponeras (normalstor text och marginal).

Intern-PM

I intern-PM ska ni utvärdera och reflektera över hur grupp-processen samt ert arbete med projektet fungerade, för att ni själva eller de som kommer att arbeta med projektet i framtiden ska kunna dra nytta av de erfarenheter ni gjort.

Intern-PM består av två delar, uppföljning av projektarbetet och uppföljning av grupp-processen.

Dokumentera erfarenheterna från att arbeta i projektform och att använda Scrum. Hur blev utfallet i förhållande till den plan ni tog fram för arbetet? Hur fungerade rolltilldelningen internt i gruppen? Hur hanterade ni externa intressenter och den omgivande organisationen? Kunde ni uppnå synergier genom att samverka med andra projekt? Hur? Vad har ni lärt er om arbetssättet under projektets gång? Vad kan ni göra annorlunda för att arbetet ska fungera ännu bättre nästa gång? Vad har fungerat bra? Vad har fungerat mindre bra? Körde ni fast? Hur kom ni vidare? I efterhand har ni kanske reflektioner om hur svårigheterna skulle kunna lösas snabbare än vad ni gjorde. Reflektera även över skillnaderna mellan basgruppsarbete och projektarbete.

Redovisa även tidsåtgången för själva projektet. Ur redovisningen ska gå att läsa tidsåtgång för varje enskild projektmedlem. Tid för egen kompetensutveckling som är nödvändig för projektets genomförande bör också belasta projektet. Förklara vilka principer ni har använt för tidsmätning och vilka lärdomar ni har gjort inför framtida projekt.

Grupp-processen

En gruppvis skriftlig redovisning av projektgruppens bildande, arbete och avslutning med fokus på utvecklingen av gruppens inre arbetsprocesser. Teoretiskt bör grupputvecklingen således förankras i någon etablerad grupputvecklingsteori som ni stött på under terminen. Redovisa era reflektioner över hur de händelser av uppgiftskaraktär som förekommit har påverkat gruppen. Av gruppens redovisning ska också framgå hur man på olika sätt försökt att utnyttja beteendevetenskaplig konsultation för att underlätta den egna arbetsprocessen. Saker som kan ha bidragit till ett effektivt utnyttjande av denna resurs respektive faktorer som lagt under i vägen för nyttjande av denna resurs ska framgå.

Som underlag för denna redovisning ska man i första hand referera till den gruppdagbok som varje projektgrupp ska ha fört och i andra hand till andra informationskällor. När det gäller teoretiska utgångspunkter ska man referera till de källor man hämtat dessa ur.