Rapporteren een handreiking bij het schrijven van verslagen en rapporten Inhoudsopgave



Dovnload 64.38 Kb.
Datum17.08.2016
Grootte64.38 Kb.
RAPPORTEREN

Een handreiking bij het schrijven van verslagen en rapporten

Inhoudsopgave


  1. Samenvatting 1

  2. Inleiding 1

  3. Verslagen en rapporten: algemeen 2

  4. Verslagen en rapporten: informatica 3

  5. Conclusies 4

  6. Literatuurlijst 4

Bijlagen

Bijlage 1 Sjabloon projectverslag (product) 5

Bijlage 2 Enkele voorbeelden 6

Bijlage 3 Checklist rapport (algemeen) 7

Bijlage 4 Hoe schrijf ik mijn verhaal? 8

Bijlage 5 Software Project Progress Report 10




1. Samenvatting
Deze notitie bevat een aantal aanwijzingen voor het schrijven van rapporten toegespitst op de OGO-verslagen.

Let op: De eisen die aan het verslag (of de verslagen) worden gesteld kunnen van project tot project verschillen. De coördinator van een project kan aanvullende eisen aan het verslag stellen of besluiten dat bepaalde onderdelen kunnen worden weggelaten.

2. Inleiding
Rapportage en documentatie spelen een belangrijke rol in ICT-projecten. Zinvolle rapportage voldoet aan een aantal eisen, zoals:

  • De informatie wordt geschreven voor de lezer, niet voor de schrijver

  • De informatie is overzichtelijk ingedeeld

  • Hoofd- en bijzaken worden onderscheiden

  • Het is geen verslag van een schoolreisje:
    technische informatie wordt in het juiste technische format gepresenteerd

De eisen die in de OGO-projecten, inclusief het software engineering project, aan de verslaglegging worden gesteld vinden hierin hun oorsprong.
Eindhoven, 24 augustus 2004

Ria van Ouwerkerk

OGO- coördinator

3. Verslagen en rapporten: algemeen
Probeer bewust te schrijven. Daarbij kun je de volgende richtlijnen in acht nemen:


  • Bedenk van tevoren wat ongeveer de omvang van het rapport zal worden.

  • Werk de hoofdstukken eerst puntsgewijs uit, alsof je een PowerPoint-presentatie aan het maken bent. Vul de punten daarna aan met de informatie die je bij een presentatie mondeling zou geven.

  • Verdeel de stof tussen hoofdtekst en bijlagen, zodat de lijn van je betoog goed kan worden gevolgd.

  • Lees het rapport kritisch door als je de eerste versie van het rapport af hebt. Kan een buitenstaander je verhaal begrijpen? Voeg, waar nodig, wat uitleg toe en verwijder overbodige informatie.

  • Visualiseer belangrijke gegevens. Een diagram zegt vaak meer dan een lang verhaal.

In bijlage 4 vind je enkele aanwijzingen die je bij het schrijven zelf kunnen helpen.

Een waarschuwing

Veel wetenschappelijk werk rust op het werk van voorgangers. Veel documenten zijn on-line beschikbaar op Internet; copy-paste is eenvoudig en het is zodoende verleidelijk om in een document fragmenten van bestaande documenten op te nemen. Daar is niets op tegen, maar als je zonder bronvermelding stukken uit andermans werk overneemt is dat plagiaat en als je het met opzet doet en het presenteert als je eigen werk is het fraude. Houd dus in gedachten dat je het duidelijk vermeldt als je werk van anderen gebruikt. Zie bijlage 2 voor een correcte manier van verwijzen.



De volgende twee onderdelen kunnen je een steuntje in de rug geven bij het schrijven.
Maak gebruik van een standaardindeling:

  • Titelblad
    Hierop worden enkele essentiële gegevens vermeld, zoals de titel van het verslag, namen van de auteurs, plaats en datum, instelling of bedrijf.

  • Inhoudsopgave
    Een wegwijzer door het verslag die de namen van de onderdelen bevat en de bladzijden waarop deze zijn te vinden.
    Door goede namen te kiezen voor de onderdelen schep je alvast een beeld van de grote lijn van het verslag.

  • Samenvatting
    Deze moet kort en bondig zijn, maar wel zelfstandig leesbaar.

  • Inleiding
    Dit is de toegang tot het verslag en bevat een antwoord op de vragen Wat en Hoe. Indien nodig kun je hier ook het Waarom aan de orde laten komen en wat achtergrondinformatie vermelden:

    • Wat = de probleemstelling of opdracht

    • Hoe = de gekozen strategie of werkwijze

    • Waarom = bijvoorbeeld informatie over de opdrachtgever of de historie van het probleem

  • Hoofdstukken
    De kern van het verslag bestaat uit een of meer genummerde hoofdstukken die vaak zijn onderverdeeld in paragrafen. De verdeling van de stof over de hoofdstukken moet logisch zijn. Je kunt bijvoorbeeld indelen volgens de fasering van het project, maar ook volgens de diverse onderdelen van het uiteindelijke product.

  • Conclusies
    Houd er rekening mee dat sommige lezers (managers bijvoorbeeld) direct zullen doorbladeren naar de conclusies.
    Dat betekent dat conclusies zelfstandig leesbaar moeten zijn, kernachtig geformuleerd, voldoende nauwkeurig en direct moeten volgen uit de voorgaande hoofdstukken.

  • Literatuurlijst
    Deze bevat de gegevens van het materiaal waarnaar in het verslag wordt verwezen. De verwijzingen volgen een vast format, zie bijlage 2. De verwijzingen zijn genummerd en worden of in alfabetische volgorde, of in de volgorde waarin er naar wordt verwezen, opgenomen.

  • Bijlagen
    Met behulp van bijlagen kun je de kern van het verslag leesbaar en overzichtelijk houden.
    De hoofdtekst moet ook zonder de bijlagen duidelijk zijn en de bijlagen moeten zelfstandig leesbaar zijn. Naar elke bijlage moet tenminste één keer worden verwezen. Begin elke bijlage op een nieuwe bladzijde.

  • Begrippenlijst of index
    Als je in je werk bijzondere afkortingen, definities, vaktermen of symbolen hebt gebruikt kan het prettig zijn voor de lezer deze in een aparte lijst terug te kunnen vinden.

Bijlage 1 bevat een sjabloon voor een OGO-verslag en bijlage 3 een checklist bij deze onderdelen.

4. Verslagen en rapporten: informatica
Het technische karakter van het werk legt een aantal extra eisen op aan de verslaglegging. Je wilt (in het algemeen) niet alleen het eindproduct, maar ook het proces beschrijven. Het is verstandig deze onderdelen te scheiden en apart een productdocument en een procesdocument op te stellen.
Het productdocument is een zakelijk, technisch document. Een voorbeeld vind je in bijlage 5: de structuur van een van de documenten die bij Software engineering projecten wordt gehanteerd. Je vindt daarin veel van de elementen uit deze notitie terug en het geeft je een beeld van de zaken die in dit soort rapporten van belang zijn.

Een technisch verslag dient duidelijk te zijn, maar ook leesbaar. Dat betekent dat het heel belangrijk is om hoofd- en bijzaken te onderscheiden. Technische details, zoals grote stukken programmatekst of de technische gegevens van een gebruikte processor, horen in een bijlage thuis. Omschrijvingen van het gedrag van software in schoolreisjesstijl zijn uit den boze, een schematische voorstelling is duidelijker en exacter.



Formules, diagrammen en tabellen

Deze vormen een essentieel onderdeel van de verslagen. Door formules, diagrammen en tabellen te gebruiken kun je precies beschrijven waar het over gaat, terwijl je toch je verslag beknopt houdt. Houd rekening met je lezers en voeg, waar nodig, een lijst met de gebruikte symbolen en afkortingen toe.



  • Formules
    Zorg dat de formules eruit springen en goed leesbaar zijn. Het is de gewoonte alleen die formules te nummeren waarnaar op andere plaatsen in het verslag wordt verwezen.

  • Diagrammen
    Denk hierbij bijvoorbeeld aan ER-diagrammen of UML-schema’s.
    Een diagram wordt al gauw onleesbaar als er veel gegevens in staan. Je kunt bijvoorbeeld beginnen met een diagram waarin de belangrijkste delen staan en daarna inzoomen op de onderdelen. Elk diagram dient te worden voorzien van een nummer en een titel.

  • Tabellen
    Je kunt in een tabel op overzichtelijke wijze een grote hoeveelheid gegevens presenteren. Bovendien dwingt het maken van een tabel je tot nadenken over de ordening van de gegevens. Elke tabel dient te worden voorzien van een nummer en een titel.

Programmatekst

Neem alleen die stukjes programmatekst in de kern van je verslag op die noodzakelijk zijn om de gedachtegang te begrijpen. Plaats grotere stukken programmatekst in de bijlagen. Zorg dat de naam van de bijlage de lading dekt.


Het procesdocument beschrijft de gang van zaken tijdens het project. Het document kan bijvoorbeeld ook beschouwingen over je eigen functioneren bevatten.

Zorg ervoor je administratie gedurende het project goed op orde te houden om aan het eind het proces te kunnen beschrijven. Werkplannen, logboeken en notulen van vergaderingen spelen hierbij een belangrijke rol. Met behulp hiervan kun je het ontwerpproces, inclusief de ontwerpbeslissingen, reconstrueren.



Evaluatie van het project

Het is gebruikelijk in het verslag van een OGO-project een evaluatie van het project op te nemen. De eisen die aan deze individuele beschouwingen van de groepsleden worden gesteld variëren van project tot project. De projectcoördinator of je tutor kunnen je hierover informeren.



Zorg in elk geval voor een zakelijke stijl, ook hier is een schoolreisjesstijl uit den boze. Geef je eigen ervaringen weer (Wat heb je geleerd?) en beperk je tot de hoofdzaken.

5. Conclusies
Bij het schrijven van rapporten in het algemeen, en het verslagleggen over een informaticaproject in het bijzonder, dienen een aantal richtlijnen in acht te worden genomen.

6. Literatuurlijst
Als je meer wilt weten over het onderwerp kun je een beroep doen op velerlei boeken. Er is niet naar deze boeken verwezen in de tekst van deze notitie. We noemen er hier enkele (in afwijking van de richtlijnen).

  1. Rien Elling, Bas Andeweg, Jaap de Jong, Christine Swanhuisen, Rapportagetechniek, Wolters Noordhoff, Groningen, 2000

[2] Jan Renkema, Schrijfwijzer, SDU Uitgeverij, ’s-Gravenhage, 2002
Er is een handige website http://wwww.schrijfwijzer.nl . Als je taal- of stijlkundige vragen hebt kun je ook terecht op http://www.onzetaal.nl .
Bijlage 1 Sjabloon projectverslag (product)
Een projectverslag kun je verdelen in voorwerk, hoofdwerk en nawerk. Elk van deze delen heeft een standaardonderverdeling.
Voorwerk

  1. Titelblad
    Een aantal essentiële gegevens, zie voorbeeld hieronder en bijlage 2.

    1. titel van het verslag

    2. nummer en naam van het project

    3. projectgroep

    4. namen en identiteitsnummers van de groepsleden

    5. naam tutor

    6. naam opleiding

    7. plaats en datum van verschijning

  1. Inhoudsopgave
    Overzicht van de onderdelen van het verslag met bladzijdenummers

  2. Samenvatting
    Beknopte (!), maar duidelijke weergave van de kern van het verslag


Hoofdwerk

  1. Inleiding
    Probleemstelling (opdracht en eigen doelstelling) en opbouw van het verslag

  2. Hoofdstukken
    Deze bevatten de kern van het verslag.
    Zorg voor een duidelijke en logische indeling in hoofdstukken en paragrafen. Kies welk deel van de informatie hier thuishoort, welk deel in de bijlagen en wat je weg kunt laten.

  3. Conclusies
    Hierin komen onderwerpen aan de orde zoals: wat is er bereikt is en wat niet, of en hoe de doelstelling is bereikt, wat er nog meer zou kunnen worden gedaan, ….


Nawerk

  1. Literatuurlijst (indien nodig)
    De boeken/artikelen waarvan je gebruik hebt gemaakt en waarnaar in het verslag wordt verwezen. Zie voorbeeld hieronder.

  2. Bijlagen (indien nodig)
    Een uitwerking van onderdelen van de hoofdtekst waarnaar in het verslag wordt verwezen.

  3. Begrippenlijst of index (indien nodig)
    Hier staan de gebruikte afkortingen, definities, vaktermen, symbolen.


Bijlage 2 Enkele voorbeelden
Voorbeeld van een titelblad:


HET ZORGVLIET ZIEKENHUIS
Projectverslag 2IO20 OGO 1.2
Technische informatica
Technische universiteit Eindhoven


Groep 2b:

212121 Alex Anders

212122 Boudewijn Blok

212123 Clarisse Ceelen

212124 Diederik Dorst

212125 Evert Eindeloos

212126 Floris Flierefluiter
Tutor:

Grardus Gordijn


Eindhoven, 8 maart 2003




Voorbeeld van een literatuurverwijzing:


In de literatuurlijst staat bijvoorbeeld:
[17] Abraham Silberschatz, Henry F. Korth, S. Sudarshan, Database System Concepts, 4th edition, McGraw-Hill, Boston etc., 2002, p. 135-187
Dus:
[nummer] naam auteur(-s), titel, naam uitgever, plaats van uitgifte, jaar van uitgifte, bladzijdenummer(-s) of hoofdstuk(-ken)
In de tekst wordt bijvoorbeeld hiernaar verwezen met:
Een uitgebreide beschrijving van SQL is te vinden in Database System Concepts [17].

Bijlage 3 Checklist rapport (algemeen)
Tip
Laat deze checklist bij voorkeur nalopen door iemand anders dan de schrijver(-s).
Controle vooraf

  • Controleer of alle onderdelen aanwezig zijn

  • Controleer of de indeling klopt

  • Hoe zit het met de spelling?


Inhoudsopgave

  • Paginanummers bij alle onderdelen

  • Correcte indeling

  • Informatieve titels

  • Bijlagen hebben een nummer en een titel

  • Titels en paginanummers zijn gelijk aan de titels en nummers in het rapport


Samenvatting

  • Probleemstelling

  • Richting van de oplossing

  • Werkwijze

  • Resultaat

  • Eventuele vervolgstappen


Inleiding

  • Probleemstelling

      • Achtergrondinformatie

      • Probleem

  • Richting van de oplossing

      • Overwegingen bij de keuze

      • Aanpak

  • Randvoorwaarden


Hoofdstukken

  • Beginnen met een inleiding


Conclusies

  • Volgen uit eerdere hoofdstukken

  • Overzichtelijk gepresenteerd


Literatuurlijst

  • Alfabetisch geordend

  • Correcte titelbeschrijvingen

  • Correcte bronvermeldingen in het rapport

  • Bevat alleen werken waarnaar in de tekst is verwezen



Bijlage 4 Hoe schrijf ik mijn verhaal?



Inleiding

Om een goed verslag of rapport te schrijven is de structuur van groot belang: hoe deel ik de tekst in zodat wat er komt te staan leesbaar, overzichtelijk en duidelijk is. Het gaat dan dus om de indeling in hoofdstukken en paragrafen, en vooral ook wat voor soort onderdelen er zijn: samenvatting, inleiding, probleemstelling... Over wat een goede structuur is, wordt veel gezegd in het voorafgaande. Maar een goede indeling is niet genoeg, elk van de paragrafen moet nog gevuld worden met tekst. En hier duikt een nieuw probleem op: hoe schrijf ik een helder verhaal over mijn werk? Daarover gaat deze bijlage, in het bijzonder over het schrijven in alinea’s.



Schrijftip: alineagewijs schrijven
Experts op het gebied van schrijven (denk aan journalisten en voorlichters) hanteren altijd het principe van het alineagewijs schrijven. Een alinea is een rij zinnen die op een nieuwe regel begint en doorloopt tot de eerstvolgende nieuwe regel. (De tekstverwerker breekt natuurlijk wel netjes af aan het eind van de regels.) Tussen alinea’s zie je soms hele of halve ‘regels wit’, maar dat hoeft niet. De tekst die je nu voor je ziet (vanaf ‘Experts...’) is een alinea. Deze alinea eindigt NU.
Het principe van alineagewijs schrijven bestaat uit twee richtlijnen:

  1. één alinea drukt één gedachte uit,

  2. de kern van die gedachte staat in het algemeen in de eerste zin van de alinea.

Nu moet je natuurlijk zelf beslissen wat die ene ‘gedachte’ nu wel is. Dat is, kort gezegd, het eerste wat je op een bepaald moment wilt gaan zeggen in het vertellen van je ‘verhaal’. Het begin, de eerste alinea dus, is het moeilijkst. Allerlei ‘gedachten’ strijden om de voorrang. Zoek er één uit die boeiend is voor de lezer en hem/haar als het ware in je verhaal trekt. Dat kan dus heel goed een regelrecht opstapje zijn voor wat je verder in de paragraaf (of het hoofdstuk) gaat zeggen, bijvoorbeeld een feit waarmee je recht op je doel af gaat (zie als voorbeeld de eerste alinea van deze paragraaf). Maar soms is ook een inleidend zijstapje de moeite waard, bijvoorbeeld een anekdote of een korte terugblik. Dit laatste geldt meer voor wat langere achtergrondsartikelen, en eigenlijk maar zelden voor verslagen en rapporten; maar het kán wel degelijk.


Als de eerste alinea eenmaal geschreven is, plak je de volgende eraan vast: de ene gedachte lokt de andere uit en voor je het weet staan er een aantal alinea’s op papier. Op een gegeven ogenblik is je stroom aan gedachten even op. Dan beslis je wat de belangrijkste gedachte is die nog niet aan bod is gekomen en daarmee begin je een nieuwe reeks alinea’s.
Dat wat betreft de eerste richtlijn: één gedachte per alinea. Wat de tweede richtlijn betreft moet je ernaar streven om al in de eerste zin van de alinea de kern van die gedachte neer te schrijven (of in ieder geval een aanzet daartoe). Meer dan die kern hoeft natuurlijk niet, je hebt de rest van de alinea tot je beschikking om de gedachte verder uit te werken, in of aan te vullen, van argumenten te voorzien, of zelfs tegen te spreken (“Maar er zijn ook mensen die het hier niet mee eens zijn, omdat...”). Let op: als die extra informatie nogal omvangrijk wordt, is het een goede zaak om niet alles in deze alinea op te nemen, maar een deel naar de volgende alinea (of alinea’s) te verschuiven. Pak daarvoor díe informatie die je als een nieuwe gedachte kunt zien.
In de tweede richtlijn staat dat het in het algemeen goed is om de hoofdgedachte in de eerste zin op te nemen. Dat is dus niet altíjd nodig. Soms schrijf je eerst een recapitulerende zin, waarin je samenvat op welk punt je bent aangeland met het vertellen van je verhaal, om de nieuwe kerngedachte pas daarna (dus in de tweede zin) te gaan verwoorden. Een voorbeeld daarvan zie je in de vorige alinea. In de rest van de tekst die je nu leest staat de hoofdgedachte wél steeds in de eerste zin.
Als je alineagewijs schrijven serieus beoefent, maak je het niet alleen voor jezelf veel makkelijker, maar zeker ook voor de lezer voor wie je verhaal bestemd is. Controleer de schrijftip van het alineagewijze schrijven maar eens door een paar nieuwsberichten uit de krant met deze ogen te bekijken. Je zult zien hoe nauwkeurig journalisten zich aan de twee richtlijnen houden. En wat het belangrijkste is: elk bericht bevat (als het goed is) een vlot leesbaar verhaal, waarvan de informatie (alweer als het goed is) moeiteloos tot jou komt. Het ‘werkt’ dus. Je geest vraagt steeds tijdens het verhaal: waar gaat het over en hoever ben ik nu? Daarvoor heb je ankerpunten nodig. Dat zijn steeds die eerste zinnen. Probeer ook maar eens een krant te snel-lezen door alleen de eerste zinnen van de alinea’s te lezen. Vaak krijg je dan al een heel goede indruk, al is de totale informatie nog klein.
Uit de vorige alinea wordt heel duidelijk dat een schrijver voor de lezer schrijft. Dat moet je altijd voor ogen houden. Wie voor zichzelf schrijft kan beter op een onbewoond eiland gaan zitten.
Ten slotte: een alinea kan verschillende lengtes hebben, ze kan flink lang zijn maar ook heel kort. Probeer die lengte wat te variëren, dat maakt je tekst aantrekkelijker. Een alinea kan zelfs uit één enkele zin bestaan, zie bijvoorbeeld de slotzin, hieronder:
Veel succes bij het schrijven.

Rob Nederpelt



Bijlage 5 Software project progress report
Onderstaande tabel is afkomstig uit 2IP40 Software engineering project
The layout of a progress report is as follows:

a.

Abstract

 

b.

Table of Contents

 

c.

Document Status Sheet




d.

Document Change Records




1. Introduction

1.1

Purpose

Project name, reporting period, reference to contract and SPMP.

1.2

Summary

Main activities and results during the reporting period. Any changes in total cost to completion and workpackage resource estimates.

1.3

List of definitions

The definitions of all used terms, acronyms and abbreviations.

1.4

List of references

All applicable documents.

2. Technical status

2.1

Work package technical status

Work packages completed, continued, and/or started.

2.2

Configuration status

Changes in the configuration status: documents produced/changed, RID, SCR, SPR, SMR statistics, software releases.

2.3

Forecast for the next reporting period

Expected progress and events (milestones, deliveries).

3. Resource status

3.1

Staff utilization

A table of hours spent and forecasted for each person.

3.2

Work package resource status

A table of hours spent and forecasted for each work package.

3.3

Resource summary

Total effort spent for the project.

4. Schedule status

4.1

Milestone trends

An updated milestone trend chart.

4.2

Schedule summary

An updated Gantt chart showing work packages completed and milestones achieved.

5. Problems

Any problems that may affect the progress.

6. Financial status report

6.1

Costs for the reporting period

Costs (hours worked, rates) for each team member. Also non-labor costs.

6.2

Cost to completion

Accumulated cost so far and planned cost to completion.

6.3

Limit of liability

 

6.4

Payments

Payments due for the reporting period.




OGO Handleiding rapporteren 2004






De database wordt beschermd door het auteursrecht ©opleid.info 2019
stuur bericht

    Hoofdpagina