******    Projektkursen  ******
          En kort mall för
 slutdokumentationen av projekt
****** preliminär version *******

Slutdokumentationen ska finnas dels i en form anpassad för papper (typ
word, pdf) och dels i en form anpassad för www (typ html) och ska där
ligga på en projektarea, som finns kvar även efter kursen och ha formen
http://www.nada.kth.se/projects/proj03/eget-projektnamn
(skicka mejl till system för att få en area för detta).
En "form anpassad för www" kan också vara pdf, men i det fallet måste
det dock finnas en översiktlig beskrivning motsvarande åtminstone en
A4-sida text på html-format så att man inte behöver starta Acrobat Reader
för att för att få veta vad det handlar om.
Det är mycket trevligt om man direkt via www kan köra prototypen (men
det går naturligtvis inte alltid att realisera).

Se till att planera dokumentationen i god tid så  att ni hinner bearbeta
texterna och upplägget. Tänk igenom vilken funktion  och vilka läsare de olika
delarna i dokumentationen har: systembeskrivningen  och användarhandledningen
vänder sig förmodligen till olika läsare, t ex. Användarhandledningen
kanske måste bestå av  flera olika delar: en installationsinstruktion
och en körinstruktion, t ex, och dessa läsare är förmodligen inte
desamma.

Det är önskvärt att ni använder bilder i er dokumentation.

Sist, men inte minst, ni måste tänka på den språkliga kvaliten. Se till
att texten har en vettig språklig stil  - om ni är flera som arbetar med olika
avsnitt är det viktigt att slutresultatet ändå är enhetligt  vad gäller
terminologi, språklig stil, tilltal etc.
Var försiktig med kryptisk terminologi.
Låt någon utomstående läsa igenom texten och ge synpunkter (Använd gärna
checklistan nedan!).
Använd  datorhjälpmedel för att kontrollera stavfel och andra detaljer .

På grund av projektens olika karaktär kan dokumentationerna variera en
del i hur de är upplagda. Här följer ett förslag på vilka delar som kan
finnas med.

**Projektpresentation**
(Mottagare/läsare av texten kan vara en relativt bred publik)
- Projektets namn, uppdragsgivarens namn, deltagare i gruppen,
  ansvarsfördelning i gruppen, adress till www-dokumentationen
- Kort "säljande" sammanfattning av projektet
- Kort bakgrund, problembeskrivning, vilka användare är systemet
  tänkt för, vilken kontakt har gruppen haft med presumtiva användare,
  har särskild prototyp tagits fram?
- Datormiljö och programvara som använts
- Funktioner i systemet, genomgång av vad man kan göra
- Användargränssnittet (helst med bilder från prototypen), kan bakas
  ihop med föregående punkt om det passar
- Körexempel
- Referenser
- Appendix: Systematisk metod som gruppen använt under genomförandet,
  kort genomgång av hur det fungerat och eventuella dokument som
  visar på detta.

**Användarhandledning**
(Mottagare/läsare av texten är den specifike användaren)
Kort beskrivning av programmets syfte och funktioner
Presentation av användargränssnitt med kort körexempel
Instruktion (beroende på användare: installation, användning etc)

** Systembeskrivning **
(Mottagare/läsare av texten är den som vill förstå hur det är uppbyggt tekniskt)
Systemskiss
   Moduler
   Diagram
   T.ex, dataflödesdiagram, meddelandediagram
   Eventuellt delar av programkoden
Referenser
(Det kan vara mindre text i systembeskrivningen än i de andra
delarna, men det måste dock finnas text som binder ihop diagram
och som tydliggör strukturen och gör det hela begripligt).

VIssa punkter återkommer på två ställen. Beroende på textens funktion
blir dock utformningen olika. T ex skiftar förmodligen tilltalet i
körexemplet beroende på om det står i projektbeskrivningen eller i
användarhandledningen. Var noga med att ge dokumentationen en
tydlig struktur i form av en innehållsförteckning, sidnumrering och
tydliga rubriker.
Om ni lägger vissa delar i bilaga, glöm inte att ange det i
innehållsförteckningen.
****************************************************************
Checklista för bedömning av skriftlig presentation:
(listan tar inte upp innehållsmässiga aspekter)

1. Faller dokumentet in i den form som är önskvärd?
2. Har dokumentet ett prydligt och funktionellt utseende?
3. Ar texten disponerad på ett ändamålsenligt sätt?
4. Framgår syftet med texten klart?
5. Är det annonserade syftet detsamma som textens faktiska syfte?
6. Är rubriker och mellanrubriker talande och konsekventa?
7. Fungerar styckeindelningen?
8. Är styckena disponerade på ett bra sätt och hänger styckena ihop sinsemellan?
9. Fungerar textbindningen?
10. Hanteras termer och fackord pä ett sätt som hjälper mottageren att
förstå texten?
11. Är den språkliga stilen anpassad efter mottagare, syfte och texttyp?
12. Ar texten korrekturläst och typografiskt lyckad?
13. Uppfyller texten sitt syfte och fungerar den for mottagaren? - om inte,
vad fattas?
*************************************************************
Exempel på brister som kan förekomma:
- ojämn språklig kvalité
- oklar mottagare av texten
- oklar struktur på dokumentationen
*************************************************************