Observera att vilken dokumentation, vilken grad, etc. styrs av hur man arbetar och med vilken processmodell. Nedanstående är exempel, riktlinjer, etc.

Projektplan

Projektplanen beskriver för er själva hur ni skall arbeta, vad ni skall arbeta med, när, hur, etc.

• * Projektorganisation
• - Roller och ansvar
• - Bemanning
• * Beskrivning av er arbetsform med möten, kommunikationskanaler, etc.
• * Era processer
• - Uppföljning
• - Versionshantering
• - Dokumenthantering
• - Testhantering
• * Tidsplanering
• - Systemets livscykel
• - Aktiviteter i projektet
• - Ganttschema på delgrupp- eller helst personnivå
• * Era resurser
• - Er tid och handledningstid
• - Resursåtgång på individ- och gruppnivå i persontimmar
• * Riskhantering
• - Identifierade risker och sannolikheter
• - Hantering av ovanstående

Programvaruspecifikation

Programvaruspecifikationen beskriver programmet som ni har tänkt att implementera för er själva men också för beställaren. Den bör vara formulerad på ett sådant sätt att krav inte går att misstolka, så att det klart och tydligt går att avgöra om ett krav är uppfyllt etc. Som med alla andra dokument är det bra att undvika ord som t.ex. "på ett enkelt sätt", om man inte klart och tydligt förklarar det. Annars blir det svårt att t.ex. avgöra om kravet är uppfyllt eller ej.

• * En kortfattad beskrivning av systemet
• * Systemet i sitt sammanhang (bra vid tolkningsfrågor)
• * Speciell teknik som används
• * Eventuella avgränsningar och begränsningar som ni känner till
• * Hur systemet skall användas
• - Användarprofiler, finns olika roller, etc.
• - Omständigheter kring användningen (säkerhet, prestanda, etc.)
• * Användningsfall hör hemma här
• * Eventuella utökningar
• - Tänkbara framtida utökningar som kan vara bra att ha i beaktande
• * Kravlistningar

Designdokument

Designdokumenten beskriver hur systemet är tänkt att fungera och implementeras. Här hör många UML-diagram hemma, men också beskrivningar av UML-diagrammen. Att bara klämma in 28 interaktionsdiagram säger inte så mycket. Försök att sätta dem i sammanhang, relatera dem till varandra och förklara dem. Ofta vill man först ha en textuell förklaring men återkomma till diagrammet många gånger sedan.

• * Arkitekturdesign
• - Principen för moduluppdelning
• - Hur kommunikationen går i systemet/kontrollflöde
• * Datadesign
• - Speciella data som systemet hanterar och som borde beskrivas, t.ex. meddelanden, kontakter (representationen och formaten är inte uppenbara)
• - Databasdesign (om tillämpligt) hör hemma här också
• * Identifiera systemets olika komponenter
• * Hur sitter dessa ihop och hur svarar de mot funktioner/krav
• * Beskriv varje komponent för sig
• - Vad är komponentens syfte?
• - Klassdiagram kan vara tillämpliga här
• - Gränssnitt mot omvärlden
• - Tänk om någon vill skriva kod som använder en modul innan modulens kod är skriven
• - Beskrivningar av algoritmer etc. kan kanske skrivas direkt i JavaDoc och inte här?
• - Vikiga saker att känna till i sammanhanget
• - Begränsningar
• * Interaktion mellan komponenter
• * Användargränssnittsdesign

Testdokumentation

Testdokumentation består dels av testplanen dels av ett dokument som beskriver utfallet för testen. Testplanen bör finnas tidigt, och skrivas för varje komponent i samband med att de designas. Testutfall fylls i efterhand som testen utförs.

Postmortemanalys

I postmortemanalysen skall ni beskriva och analysera ert eget arbete med projektet. Vad gick fel? Vad gjordes bra? Vad borde man ha gjort annorlunda och hur? Hur upprepar man det som gick bra i nästa projekt? Hur unviker man att upprepa misstag? Resultatet av postmortemanalysen bör vara vettig för er själva att ta fram i nästa projekt, oavsett om det sker på DSV eller i arbetslivet. Diskutera inte enskilda individer utan endast gruppen som helhet.

Projektdokumentation

Koden skall dokumenteras med JavaDoc-kommentarer. Förutom att det skall framgå vad som faktiskt händer i koden skall dokumentationen utgöra underlag för de utvecklare som, om ett eller flera år, skall gå in i koden och utföra ändringar eller göra tillägg. Kommentarerna skall skrivas kontinuerligt under arbetet.

Modulbeskrivningar. En kort beskrivning av de olika kodmodulerna och klasserna så att deras funktion etc. klart framgår för en programmerare som skall sätta sig in i systemet för att t.ex. underhålla det. Skrivs med fördel som JavaDoc-kommentarer.

Dokumentation av koden skall inte lämnas till handledaren på papper. Koden skall göras tillgänglig via Internet. Endast url:en till dokumentationen skall lämnas.