Institutionen för Datavetenskap
Att skriva en vetenskaplig rapport
Umeå universitet

 

Det förekommer nästan alltid delade meningar om vad en rapport ska (och bör) innehålla för att den ska vara bra. Denna mall är något som fungerar vid (i stort) de flesta kurserna som ges av Institutionen för datavetenskap.

Nedan följer en rad guidelines som anses vara grunden för en bra rapport. En måste dock tänka på att uppgiftens specifikation och innehåll (och kurserns FSR) styr rapportens exakta utformning.



Den bästa rapporten är inte den som följer dessa punkter exakt, utan har anpassats väl mot uppgiften med punkterna som inspiration.

Teknisk-Naturvetenskaplig Fakultets guide till rapportskrivande finnes här

Rapportens innehåll

  • Försättsblad
  • Sammanfattning (abstract)
  • Innehållsförteckning
  • Problembeskrivning
  • Kompilering och körning
  • Åtkomst och användarhandledning
  • Algoritmbeskrivning
  • Systembeskrivning
  • Lösningens begränsningar
  • Resultat
  • Diskussion/reflektion
  • Testkörningar
  • Referenser
  • Källkod
  • Bilagor


Försättsblad

  • Kursens namn
  • Laborationsnamn och laborationsnummer
  • Ditt namn
  • CS användarnamn (CAS om inlämning via Cambro)
  • Eventuell sökväg till källkod
  • Datum
  • Samtliga handledares namn
  • Lämna utrymme för kommentarer


Sammanfattning (abstract)

  • Gäller endast större projekt


Innehållsförteckning

  • Innehåller en lista av samtliga avsnitt i rapporten
  • Innehåller inte sig själv
  • Innehåller (helst) alla bilagor
  • Om en själv gör innehållsförteckningen, se till att den verkligen stämmer (Tips: Skrivs sist av allt)
  • Sidnummer för varje avsnitt skall framgå tydligt


Problembeskrivning

  • Ska beskriva vad uppgiften går ut på
  • Ska kunna ge en bild av uppgiften utan att läsa orginalspecifikationen
  • Använd egna ord, d.v.s. kopiera inte från specifikationen
  • Sammanfatta problemet
  • Hänvisa till orginalspecifikationen


Kompilering och körning

  • Beskriver hur din lösning kompileras och körs på institutionens maskiner, via terminal om inget annat framgår


Åtkomst och användarhandledning

  • Beskriver var din lösning ligger. Kom ihåg att om originalspecen specificerar var så ska detta följas
  • Om ett antal filer ingår är det bra att kort nämna vad varje fil har för syfte


Algoritmbeskrivning

  • Beskrivning, i vanligt språk, som beskriver icke-triviala delar av lösningen
  • Försök undvika att använda element som är direkt kopplade till koden, t.ex. variabelnamn och dylikt (Tips: Foo)
  • Syftet med detta avsnitt är att en läsare ska kunna få förståelse för hur en komplicerad del löses utan att behöva läsa kod
  • Designa dina algoritmer innan du börjar skriva kod!


Systembeskrivning

  • Den mest centrala delen i rapporten
  • Ska beskriva systemets interna uppbyggnad och struktur
  • Alla egendefinerade datatyper och strukturer beskrivs
  • En beskrivning utifrån ett designperspektiv
  • Ofta bra med figurer som illustrerar centrala delar samt programmets flöde, d.v.s. hur olika delar är sammankopplade
  • Bättre med små tydliga figurer än ett enda stort spindelnät
  • Objektorienterad utveckling (Java m.fl.):
    • Beskriv relationer mellan klasser med figurer och kommentarer till dessa


Lösningens begränsningar

  • Beskriver de begränsningar som du kan komma att tänka på, eller har stött på under testningen
  • Uppriktighet är ALLTID positivt
  • Hur kan/kunde begränsningarna undvikas?


Resultat

  • Presentera det resultat du fått


Diskussion/reflektion

  • Vilka problem har du stött på?
  • Vad tyckte du om laborationen?
  • Har du några åsikter du vill framföra?
  • Finns det personer som varit till särskild hjälp? Tacka dessa


Testkörningar

  • Hitta och testa specialfall
  • Visa utdata med typsnitt där alla tecken är lika breda, t.ex. Consolas
  • Kommentera testerna. Vad testas? Tolka resultatet
  • Dela gärna upp testerna på ett lämpligt sätt


Referenser

  • Referera till kurslitteratur och de hemsidor du hittat information från
  • Det finns standarder för hur referenser skrivs, Umeå universitets lista för riktlinjer finnes här


Källkod

  • Ska skrivas ut med typsnitt där alla tecken är lika breda, t.ex. Consolas
  • Koden ska vara indenterad på ett konsekvent sätt
  • Koden ska se bra ut även på papper, max 80 tecken/rad
  • Det finns vissa verktyg vars syfte enbart är att skriva ut källkod snyggt (t.ex.a2ps)
  • Koden ska vara kommenterad där det inte är klart vad du gjort
  • Varje funktion/metod föregås av kommentarer som beskriver dess syfte, in-/utdata o.s.v.

Kommando för att skriva ut med a2ps:
a2ps ---line-numbers=1 -T4 <samtliga kodfiler> -o code.ps



Bilagor

  • Används vid behov, ex enkäter och resultatdata


Slutliga tips och råd

  • Endast resultat, diskussion (och eventuellt testkörningar) får skrivas med personliga pronomen
  • Umeå Universitets logo får INTE användas
  • Använd ett korrekt och formellt språk
  • Normalt är språkvalet svenska/engelska fritt
  • Sidnumrering ska användas och börjar först efter innehållsförteckningen
  • Rapporten ska vara ihophäftad om den lämnas in i labblåda
  • Rapporten ska vara i PDF-format om den lämnas in elektroniskt
  • Använd rättstavningskontroll

Sidan skapades av Marcus Bergner, bergner@cs.umu.se (2009)

Uppdaterad av Lina Ögren, linao@cs.umu.se (2016)



 
Navigera på www.umu.se

 



Umeå universitet
Teknisk-naturvetenskaplig
fakultet
Institutionen för
Datavetenskap
 
  Nyhetsarkiv
Forskning
För våra anställda
För våra studenter
Support
Datorguide
Tentaanmälan
Miscellaneous
Studiehandbok C/DV
Supplemental Instruction
Inloggade studenter
Studerandeföreningar
Studievägledarna
Kursutbud VT 2011
Kursutbud HT 2010
Kursutbud VT 2010
Kursutbud HT 2009
Kursutbud VT 2009
Examensarbete
Labbrapporter
Lediga Tjänster
Personal
Presentation
Utbildning
Slutförda examensarbeten
Support
 
 

----------------------------------------------------
Institutionen för Datavetenskap
Umeå universitet
Informationen ändrades 2016-05-17
Ansvarig för sidan: Amanuenserna
 
Postadress: 901 87 Umeå
Tel: 090-786 50 00
Fax: 090-786 61 26
E-post: datavetenskap@cs.umu.se