At skrive en teknisk rapport

Af ren nysgerrighed må man så spørge, hvor du skriver bachelor projekt henne?

Jeg plejer at arbejde ud fra noget i retning af:

1) Problemformulering og/eller kravspecifikation
En specifik specifikation af problemet du prøver at løse og en præcis specifikation af hvilke krav den skrevne software skal leve op til, og ikke mindst, hvad det IKKE skal kunne, altså samtidig en afgrænsning af hvad du vil beskæftige dig med. Hvis din opgave i forvejen er defineret ved en kravspecifikation behøver du nok inkludere dette.

2) Analyse
Analyse af problemet. Det er ikke altid relevant, men ofte. F.eks. beskrivelse af forskellige løsningsmodeller, diskussion for/imod forskellige løsninger og beskrivelse af en specifik løsning du har valgt at implementere.

3) Design
Hvordan softwaren er designet. Her hører UML og klassebeskrivelser til, klasse-ansvarsområder, etc. Beskrivelser af public methods, evt. også private hvis det er relevant. Spidsfindige detaljer i koden som måske ikke er indlysende hvis man læser koden, kan forklares med pseudokode, state-charts eller lignende, alt efter hvad der findes mest anvendeligt til det specifikke problem.

4) Test
Hvordan softwaren er testet; hvordan det er sikret at softwaren lever op til de stillede krav. Evt. kort beskrivelse af unit test kode, hvis du bruger det. Gennemgang af accepttest specifikation og resultat, hvis en sådan er defineret.

Jeg er iøvrigt ingeniørstuderende, ovenstående er min normale arbejdsproces for større projekter.

bromer > Jeg læser på Syddansk Universitet i Kolding

driis > MANGE tak, det er i øvrigt den oprindelige model jeg havde i tankerne. Da det er et bachelorprojekt er der ikke stillet en kravspecifikation, så jeg er selvfølgelig nødt til at have et afsnit med Problemformulering. Mht. Analyse er jeg mere i tvivl, men det må drøftes med vejlederen :-)

Har du evt. noget litteratur du kan anbefale?

Jeg har selv læst "Real-Time UML" og "Håndbog i struktureret programudvikling" om emnet, men jeg vil ikke anbefale nogle af dem. Real-Time UML er primært om UML og har ikke så meget med selve rapportskrivningen at gøre. "Håndbog i struktureret programudvikling" omhandler netop emnet og udviklingsprocessen, men jeg synes ikke den er ret godt skrevet, og den lægger op til en meget formel struktur uden at angive nogle gode alternativer.

OK, tak for kommentaren - jeg holder mig indtil videre til det svar du kom med før.

Jeg ville nok lave:

1)  opgave formulering
2)  opstille diverse hypoteser
3)  beskrivelse af projekt forløb
    a)  krav specifikation
    b)  design
    c)  implementation
    d)  test
    e)  kundens (medstuderendes) reaktioner
4)  konklusioner

Hvem underviser i den slags på Engstien nu om dage ?

arne_v > Tak for bidraget! Nu er der pludselig to (gode) fremgangsmetoder, men i sidste ende er det et spørgsmål om at koge det ned til de mest relevante afsnit... Jeg kan evt. altid skrive en kommentar om mine valg, som jeg skal have på plads i løbet af næste uge :-) Jeg er færdig med at kode programmet, så jeg mangler bare at skrive rapporten.

Det er professor Klaus Robering (tysker) der underviser i Java og multimedieprogrammering - dog ikke i Java 3D, som er rent selvstudie for mit vedkommende.

Min metoder er ikke et alternativ til driis'es - bare en udvidelse.

Klaus Robering kender jeg ikke (men der er også 9 år siden jeg arbejdede
på HHS i Kolding).