Naamgeving en versiebeheer van documenten binnen RdMC

Naamgeving en versiebeheer van documenten binnen
RdMC
Naam document
Verantwoordelijke
Auteurs
Versienummer
Datum eerste versie
Laatst bijgewerkt
Trefwoorden
Voorstel-Naamgeving en versiebeheer documenten-1.2.doc
Schuwer, R.
Schuwer, R.; Jansen, D.; Vries, F. de
1.4
26-11-2003
11-02-2004
naamgeving, versiebeheer, documentkenmerken, archief, kluis,
poortwachter
Historie
Versie 1.0 d.d. 26-11-2003 voor Jansen, D.
Versie 1.1 d.d. 04-12 commentaar Jansen, D. verwerkt
Versie 1.2 d.d. 11-12 commentaar VWL projectgroep verwerkt
Versie 1.3 d.d. 16-12 commentaar VWL projectgroep verwerkt
Versie 1.4 d.d. 11-02 goedgekeurd door stafoverleg RdMC d.d. 15-1 en
kleine wijzigingen n.a.v. overleg met Marc Liedekerken en Bert Magermans
Definitief
Definitief
Richtlijnen voor status- en versiebeheer, borging van documenten,
naamgeving en vastleggen van overige documentkenmerken.
Projectstatus
RdMC-status
Samenvatting
Inleiding
Deze notitie bevat een voorstel voor uniformiteit in naamgeving van documenten die in de projecten
van het RdMC worden gemaakt en de wijze waarop met status, versies en archivering van
documenten moet worden omgegaan.
Dit voorstel is een uitgangspunt om archivering en ontsluiting van documenten binnen het RdMC beter
te regelen. Daarbij wordt er naar gestreefd om te allen tijde te kunnen beschikken over de gewenste
versie van specifieke documenten, duidelijkheid te verkrijgen over de documentstatus, en de
informatie voor iedereen binnen RdMC via de project-/samenwerkomgeving toegankelijk te maken. Dit
betekent dat via het Internet, dus ook van buiten de reguliere OUNL-lokaties, alle belangrijke RdMCdocumenten, (alléén!) voor RdMC-ers, vindbaar en toegankelijk zijn. Een centrale functie hierbij zal
door een kluis worden ingevuld.
Een belangrijk voordeel is dat men steeds op de hoogte kan komen van de meest actuele versie van
een document, dus ook van huis af. Documenten hoeven zelf niet meer in veelvoud te worden
rondgestuurd per e-mail of op papier, omdat iedere RdMC-er toegang heeft tot de opslagplaats van
deze documenten. Uniforme naamgeving, gebruik van documenten, versiebeheer en status zijn
belangrijke voorwaarden om e.e.a. makkelijk en snel toegankelijk te maken.
De indeling van dit document is als volgt. Allereerst wordt het voorstel gepresenteerd. Vervolgens
worden de argumenten en achtergronden die aan het voorstel ten grondslag liggen nader uitgewerkt.
Het lezen van deze uitwerking is niet per se nodig om het voorstel te kunnen toepassen.
Vooralsnog beschrijft deze notitie een voorstel voor documentbeheer. De voorgestelde wijze van
werken en gebruik van de status- en versieattributen kan echter onverkort ook worden toegepast voor
andere artefacten dan documenten. Met name voor de leerobjecten die in het kennisbankproject
worden ontwikkeld zouden de voorstellen kunnen worden gebruikt.
1
Voorstel
Samenvatting
Over de volgende onderwerpen worden voorstellen gedaan:
1. Status van een document
2. Versie van een document
3. Naamgeving van documenten
4. Overige documentkenmerken
5. Een kluis van documenten
De eerste vier voorstellen betreffen in feite een implementatie van een deel van de administratieve
organisatie. Aan projecten binnen het RdMC wordt geadviseerd te gaan werken volgens de eerste vier
voorstellen. Voor projectresultaten die de kluis moeten worden opgenomen zullen de voorstellen 1 t/m
4 voorgeschreven zijn.
De status van een document geeft aan in welke fase van zijn levenscyclus het document zich bevindt.
Voorbeelden van waarden die dit attribuut kan hebben zijn “Concept”, “Definitief”,.. Een verandering
van status(waarde) van een document is meestal het gevolg van een besluit dat door een of meerdere
personen wordt genomen gedurende een proces. Zo kan in een projectvergadering besloten worden
om de status van een projectplan van “Concept” naar “Definitief” te transformeren.
De versie van een document is een uitgave van dat document waarin aanpassingen zijn aangebracht
ten opzichte van een eerdere uitgave. Wanneer er bij de uitgave van een document geen eerdere
uitgave bestaat, is die uitgave de eerste versie. Uit de omschrijving van versie volgt direct dat dit
begrip een volgtijdelijkheid aangeeft in de levenscyclus van documenten.
1. Voorstel voor status
Er wordt uitgegaan van een proces waarbij documenten uiteindelijk een formele goedkeuring krijgen in
een of ander projectgremium. Goedkeuring kan daarbij op twee niveaus worden verkregen:
1. Projectniveau. Dit betreft documenten die in principe alleen van belang zijn voor gebruik
binnen het project waarin ze zijn ontstaan. Denk bv. aan een projectplan of een
ontwerpdocument voor een tool.
2. RdMC niveau. Dit betreft documenten die een projectoverstijgend karakter hebben en
daardoor van belang zijn voor andere gremia dan het project waarin het document is ontstaan.
Denk bv. aan projectplannen op RdMC-niveau of casusbeschrijvingen die door meerdere
projecten worden gebruikt.
Een document op projectniveau hoeft alleen in het projectgremium geaccordeerd te worden.
Documenten op RdMC niveau worden, na goedkeuring op projectniveau, uiteindelijk goedgekeurd
door een RdMC gremium (bv. het projectleidersoverleg).
Er wordt voorgesteld twee statusattributen te definiëren: Projectstatus en RdMC-status. Voor deze
statusattributen worden de volgende waarden voorgesteld:
Projectstatus
Waarde
Concept
Ter goedkeuring
Definitief
Ter verbetering
Afgekeurd
Omschrijving
Het document is in wording, moet worden geredigeerd, verbeterd, aangevuld etc.
De maker(s) van het document beschouwen het document als voltooid en bieden
het aan ter formele goedkeuring
Er is een besluit genomen dat het document voltooid is en goedgekeurd voor
gebruik binnen het project
Aan het document moeten verbeteringen (aanvullingen) worden gedaan om het
goedgekeurd te krijgen
Er is een besluit genomen dat het document afgekeurd is. Het document maakt
geen deel meer uit van de verzameling documenten die in het project zijn
ontstaan.
2
RdMC-status
Waarde
Ter goedkeuring
Definitief
Ter verbetering
Afgekeurd
Omschrijving
Het document is alleen van belang op projectniveau
Het projectgremium biedt het document aan aan het RdMC gremium ter formele
goedkeuring
Het RdMC gremium besluit dat het document voltooid is en goedgekeurd voor
gebruik binnen het RdMC
Aan het document moeten verbeteringen (aanvullingen) worden gedaan om het
goedgekeurd te krijgen vooor gebruik binnen het RdMC
Er is een besluit genomen dat het document afgekeurd is voor gebruik binnen het
RdMC.
Het volgende schema geeft aan welke waardenovergangen zijn toegestaan:
Projectniveau
Concept
Ter verbetering
Afgekeurd
Ter goedkeuring
Definitief
RdMC-niveau
Ter verbetering
Afgekeurd
Ter goedkeuring
Definitief
Enkele kanttekeningen:
- Ieder document begint zijn levenscyclus met de waarde “Concept” voor het attribuut
“Projectstatus” en de waarde “-“ voor het attribuut “RdMC-status”.
- De stippellijn geeft aan dat een document dat op RdMC-niveau de status “Ter verbetering”
heeft ook op projectniveau kan worden aangeboden ter goedkeuring op projectniveau. In de
achtergronden bij dit voorstel staan enkele mogelijke processen beschreven ter illustratie.
- Alleen documenten met de waarde “Definitief” voor het attribuut “Projectstatus” kunnen de
waarde “Ter goedkeuring” voor het attribuut “RdMC-status” krijgen. Dit weerspiegelt een
goedkeuringsproces waarbij een document eerst op projectniveau een status “Definitief” moet
hebben vóórdat het projectoverstijgend kan worden aangeboden.
- Het gremium dat uiteindelijk beslist of een document de status “Definitief” of “Afgekeurd” krijgt
kan ook uit één persoon bestaan (afhankelijk van de af te spreken procedure binnen RdMC).
- Volgens dit schema kan de levenscyclus van een document op projectniveau alleen eindigen
met de status “Definitief” of status “Afgekeurd”. Om allerlei redenen kan het echter ook
gebeuren dat een document tussentijds “uitvalt” (bv. als de maker besluit het concept niet
verder uit te werken of als de maker een document met de status “Ter verbetering” niet verder
meer uitwerkt, bv. omdat externe gebeurtenissen de inhoud van het document achterhaald
hebben (een projectplan met de status “Ter verbetering” wordt niet meer verder opgepakt
omdat inmiddels besloten is het project te stoppen)). Het wordt aan ieder project overgelaten
of deze situaties toegestaan worden.
3
2. Voorstel voor versienummering
- Een versienummer heeft het format: n.m (n >= 1, m >= 0)
- Wanneer een document “van scratch” wordt gecreëerd, krijgt het versienummer 1.0
- Wanneer een document versienummer n.m heeft en er vinden grote wijzigingen plaats aan de
inhoud, dan krijgt het document versienummer (n+1).0.
- Wanneer een document versienummer n.m heeft en er vinden kleine wijzigingen plaats aan
de inhoud, dan krijgt het document versienummer n.(m+1).
De volgende lijst van soorten wijzigingen zijn “kleine wijzigingen”
- Verbeteringen van spelfouten
- Toevoegen of verwijderen van delen van het document die de inhoud van het document niet
wezenlijk wijzigen. (Deze regel is niet erg eenduidig te formuleren. Denk bij wijzigingen die de
inhoud niet wezenlijk wijzigen bijvoorbeeld aan: toevoegen van een verduidelijkend plaatje,
toevoegen of verwijderen van een tabel, toevoegen van een index. Denk bij wijzigingen die de
inhoud wel wezenlijk wijzigen aan: toevoegen van een nieuw hoofdstuk, verwijderen van een
hoofdstuk of paragraaf, verplaatsen van een tekstdeel van de hoofdtekst naar een bijlage,...)
3. Voorstel voor naamgeving van documenten
De volgende naamgevingsconventie wordt voorgesteld voor documenten binnen het RdMC. We
geven hierbij de situatie aan voor Word-documenten, maar de naamgeving is analoog voor alle typen
documenten. Alleen hetachtervoegsel zal veranderen daarbij (bv. .xls in plaats van .doc wanneer het
document een Excel spreadsheet betreft).
De naam voor een document heeft het format:
Soort-Naam-Versie.doc
 Soort = soort document. Is voor het RdMC nog niet gestandaardiseerd. De volgende soorten lijken
in ieder geval voor te komen:
 Plan
 Ontwerp
 Verslag
 Handleiding
 Naam = naam van het document. Eén of meer woorden die niet gescheiden worden door een
streepje. Bij voorkeur een “sprekende” naam waarmee de inhoud van het document wordt
gekarakteriseerd.
 Versie = versie nummer volgens het format zoals hierboven voorgesteld.
Bv: Ontwerp-Peerassessment-1.0.doc
4. Voorstel voor vastleggen van overige documentkenmerken
Om een document te kunnen karakteriseren en informatie over het document snel toegankelijk te
hebben wordt voorgesteld voor ieder document de volgende kenmerken aan het begin ervan op te
nemen.
Naam document
Gemaakt binnen
project
Verantwoordelijke
Auteurs
Versienummer
Datum eerste versie
Laatst bijgewerkt
Trefwoorden
<<Dit veld wordt in de office-suite automatisch toegekend op basis van de
feitelijke bestandsnaam.>>
<<Officiële naam van project zoals die naar OC&W wordt gebruikt>>
<<Officiële naam van projectcode, 64.510.xxx>>
<< Naam van de documentverantwoordelijke (format: Achternaam,
voorletter, tussenvoegsels)>>
<< Namen auteurs (format: Achternaam, voorletter, tussenvoegsels)>>
<<Versienummer>>
<<Datum eerste versie in dd-mm-yyyy formaat>>
<<Datum laatste versie in dd-mm-yyyy formaat>>
<< Minstens één trefwoord, waarmee het document kan worden
gekarakteriseerd. Meer trefwoorden mogen ook. Verwacht wordt dat
geleidelijk een reeks van trefwoorden zal ontstaan die zich lenen voor
hergebruik.>>
4
Historie
Projectstatus
RdMC-status
Samenvatting
<<Beschrijf kort versie historie, wat is er veranderd t.o.v. vorige versie of
op welke documenten is de eerste versie gebaseerd >>.
<<Eén uit Concept, Ter goedkeuring, Definitief, Ter verbetering,
Afgekeurd>>
<<Eén uit “-“, Ter goedkeuring, Definitief, Ter verbetering, Afgekeurd.
Default “-“>>
<<Een korte samenvatting van de inhoud van het document>>
5. Voorstel voor een RdMC-kluis
Documenten met de Projectstatus of RdMC-status “Definitief” moeten geborgd worden. Borging
gebeurt door het betreffende document op te nemen in een kluis. Dit is niet meer dan een database
waarbij bepaalde personen bepaalde rechten hebben t.a.v. beheer en anderen inzagerechten hebben
in de documenten die daarin zijn opgenomen. Een kluis maakt het mogelijk de status van ieder project
na te gaan en te zoeken naar resultaten over de projecten heen. Nieuwe medewerkers kunnen snel
de huidige status van een project inzien en verkrijgen middels de kluis. Daarnaast bevat een kluis de
“waarheid” voor het RdMC: alleen documenten in de kluis kunnen uitgangspunt zijn voor discussies en
voortgaand werk. Wanneer dus ergens twijfel bestaat over welke versie van een document nu de
“huidige versie” is, kan in de kluis de waarheid worden gevonden.
De kluis wordt beheerd door een of meer personen met de rol van poortwachter. Alleen de
poortwachter heeft rechten om documenten toe te voegen of te verwijderen.
De procedure rondom het opnemen van documenten in de kluis is als volgt:
- Alleen documenten met Projectstatus of RdMC-status “Definitief” worden opgenomen in de
kluis
- De verantwoordelijke voor het document levert het document aan aan de poortwachter. De
verantwoordelijke zorgt er daarbij voor dat de volgende documentvelden zijn ingevuld (zie ook
de voorgestelde documentattributen van een eerdere paragraaf):
o Naam van het document
o Naam eerste auteur (meestal de documentverantwoordelijke) (format: Achternaam,
voorletter, tussenvoegsels)
o Namen overige auteurs. Wanneer er slechts 1 auteur is wordt hier een “-“ ingevuld.
o Versienummer
o Datum eerste versie
o Datum laatst bijgewerkt
o Trefwoorden
o Historie
o Status (met waarde “Definitief”)
- De poortwachter controleert of de status inderdaad “Definitief” is en of de andere velden naar
behoren zijn ingevuld. Zo nee, dan retourneert hij/zij het document naar de verantwoordelijke.
- Indien alles correct is kent de poortwachter een uniek nummer toe aan het document (het
documentkluisnummer). Dit nummer wordt gecommuniceerd aan de
documentverantwoordelijke.
- De poortwachter voegt het document, in pdf format conform huistijl, toe aan de kluis.
Naast een volledig elektronische omgeving kan ook van ieder document een afdruk worden gemaakt
die wordt opgeslagen in een fysieke kluis.
5
Achtergronden
In dit hoofdstuk worden de achtergronden van dit voorstel beschreven. Tevens worden ter illustratie
enkele veel voorkomende documentgerelateerde processen beschreven.
Begripsafbakening
De projecten van het RdMC zullen over het algemeen resultaten opleveren die vastgelegd zijn in
documenten en niet in fysieke producten zoals een maquette. In deze notitie zal een pragmatische
omschrijving van “document” worden gehanteerd:
Een document is een elektronisch artefact dat voornamelijk tekst bevat en als doel heeft
middels die tekst over projectresultaten in de meest brede zin van het woord te
communiceren.
Daarbij kan een verschil worden gemaakt tussen de volgende situaties:
1. Het document is het eind-, deel- en/of tussenresultaat van een project of projectactiviteit.
Voorbeelden: een plan van aanpak bij projectactiviteit Planning, een beoordelingsformulier
voor een assessment bij een Project Assessment op de werkplek, een handleiding voor
gebruik van een softwareproduct.
2. Het document beschrijft een ander “niet-schriftelijk” projectresultaat. Voorbeelden van “nietschriftelijke” projectresultaten zijn softwareproducten, webformulieren,...
Dit onderscheid wordt gemaakt omdat met name in situatie 2 er een verschil kan zijn tussen versies
en status van het “niet-schriftelijk” projectresultaat en het beschrijvende document. Dit onderscheid
speelt met name sterk in engineering omgevingen. Zo kan een beschrijvend document voor een
softwareproduct versie 6.2 hebben en de status “definitief”, terwijl het softwareproduct zelf versie “0.9”
en status “in bewerking” heeft. Deze notitie gaat niet verder in op het verband tussen versienummering
van producten en hun beschrijvende documenten, maar richt zich slechts op documenten.
Samenhang tussen versie en status van een document
Versie en status van een document zijn twee begrippen die nauw aan elkaar gerelateerd zijn. Beide
begrippen beschrijven een document onafhankelijk van zijn inhoud. Anders gezegd: het zijn beide
labels die aan een document kunnen worden gehangen en die ieder een waarde hebben.
De status van een document geeft aan in welke fase van zijn levenscyclus het document zich bevindt.
Voorbeelden van waarden die dit attribuut kan hebben zijn “Concept”, “Definitief”,.. Een verandering
van status(waarde) van een document is meestal het gevolg van een besluit dat door een of meerdere
personen wordt genomen gedurende een proces. Zo kan in een projectvergadering besloten worden
om de status van een projectplan van “Concept” naar “Definitief” te transformeren.
De versie van een document is een uitgave van dat document waarin aanpassingen zijn aangebracht
ten opzichte van een eerdere uitgave. Wanneer er bij de uitgave van een document geen eerdere
uitgave bestaat, is die uitgave de eerste versie. Uit de omschrijving van versie volgt direct dat dit
begrip een volgtijdelijkheid aangeeft in de levenscyclus van documenten. Statusveranderingen zijn het
gevolg van besluiten door een of ander gremium, versieveranderingen zijn het gevolg van inhoudelijke
wijzigingen aan het document zelf.
Een document met een bepaalde status kan meerdere versies hebben. Een document van een
bepaalde versie kan ook meerdere statussen hebben. Een voorbeeld van het eerste: een
softwareontwerp met Projectstatus “Concept” kan door inhoudelijke veranderingen eraan een ander
versienummer krijgen, maar nog steeds voor het attribuut Projectstatus de waarde “Concept” hebben.
Een voorbeeld van het tweede: datzelfde softwareontwerp kan, door een besluit van de projectgroep,
overgaan van Projectstatus “Ter goedkeuring” naar Projectstatus “Definitief”, terwijl het versienummer
niet verandert (omdat de inhoud van het document ongewijzigd is gebleven).
Versienummering heeft met name tot doel de afstamming van documenten achteraf na te kunnen
gaan. Op die wijze wordt het mogelijk de ontstaansgeschiedenis van een document te reconstrueren.
Daarnaast identificeert een versienummer een document uniek, zodat wanneer documenten verspreid
worden personen kunnen nagaan of de exemplaren die ze onderling hebben hetzelfde versienummer
hebben en dus dezelfde inhoud bevatten. Op ieder moment kunnen meerdere versies van een
6
document bestaan, maar slechts één versie is de “huidige versie”. De “huidige versie” is die versie
van het document dat door de projectgroep wordt beschouwd als het uitgangspunt voor verdere
ontwikkeling van activiteiten. Het hoeft daarbij niet per se zo te zijn dat de “huidige versie” het hoogste
versienummer heeft. De “huidige versie” is veeleer een combinatie van versienummer en status zoals
het volgende voorbeeld duidelijk maakt.
Voorbeeld
Een project heeft een projectplan met tatus “Definitief” en versie 6.4 als “huidige versie” gekenschetst.
Het project krijgt een aantal extra taken toegewezen en voor de uitvoering ervan moet het plan
worden aangepast. Iemand neemt de “huidige versie” van het document als uitgangspunt voor een
aangepast projectplan. De status van dat nieuwe document wordt “Concept” en het versienummer
wordt 7.0. Zolang echter de status van het document niet “Definitief” is blijft het vigerende projectplan
de “huidige versie”.
Wanneer in het voorbeeld voor het nieuwe document versienummer 1.0 zou zijn genomen is het niet
duidelijk dat dat document is ontstaan uit versie 6.4 van het document en kan dus achteraf niet meer
de ontstaansgeschiedenis worden gereconstrueerd. Het is daarom wenselijk versienummering altijd
oplopend te nemen.
Versieverandering van een document is het gevolg van inhoudelijke aanpassingen. Wanneer het
maken en aanpassen van een document gebeurt door één persoon, zonder input van anderen, dan is
het steeds laten veranderen van versienummers niet echt noodzakelijk. Wanneer echter meerdere
personen werken aan eenzelfde document of wanneer het document verspreid wordt naar anderen,
dan is het noodzakelijk dat wijzigingen aan documenten tot uiting komen in een gewijzigd
versienummer.
Documentverantwoordelijke
Om geen conflicten in versienummering te krijgen wordt aangeraden bij ieder document een
verantwoordelijke aan te wijzen. Meestal zal dat de persoon zijn die de eerste versie van het
document maakt (dus het document laat ontstaan). Alleen de verantwoordelijke mag de
versienummering van een document wijzigen.
Wanneer twee exemplaren van een document dezelfde inhoud hebben, dan hebben ze ook hetzelfde
versienummer. Er geldt echter ook dat wanneer twee exemplaren van een document verschillende
inhoud hebben ze verschillende versienummers hebben. Onderken dat, wanneer een document
gewijzigd wordt, maar de verantwoordelijke voor dat document besluit om toch geen nieuw
versienummer toe te kennen, het oude exemplaar wordt overschreven en als zodanig dus niet meer
bestaat. Deze situatie zal veel voorkomen tijdens de (initiële) creatie van het document. Immers: je
werkt aan het document, slaat het op op de harde schijf, gaat na enige tijd verder met een kopie ervan
in het werkgeheugen van de PC en bewaart de veranderingen op dezelfde plek op de harde schijf
onder dezelfde naam. Het reeds opgeslagen (oudere) exemplaar is dan overschreven.
Proces: verwerking van opmerkingen op een versie
Een proces dat veelvuldig voorkomt is het aanbieden van een document door de verantwoordelijke
van het document aan meerdere personen met het doel op- en aanmerkingen te verzamelen op dat
document. Deze opmerkingen worden vervolgens door de document-verantwoordelijke verwerkt in
een nieuwe versie van het document. Voordat die opmerkingen verwerkt zijn bestaan er verschillende
tijdelijke versies van het document naast elkaar, ieder uitgaande van de oorspronkelijke versie met
de op- en aanmerkingen erin vermeld. Deze tijdelijke versies krijgen geen nieuw versienummer: het
zijn slechts tijdelijke “tussen”versies en alleen de verantwoordelijke van een document mag nieuwe
versienummers toekennen. Wel moeten de verschillende documenten van elkaar kunnen worden
onderscheiden. Het voorstel is om dit te doen door aan de bestandsnaam een zinsnede toe te voegen
van de vorm “opmerkingen <naam>”. Met de naamgevingsconventies die eerder zijn behandeld kan
dat bijvoorbeeld tot de volgende situatie leiden:
Oorspronkelijke document:
Ontwerp-Peerassessment-1.0.doc
Dit document wordt verspreid naar Jan Bateson, Piet Thom en Annet Huizinga.
De geretourneerde documenten:
Ontwerp-Peerassessment-1.0-opmerkingen Bateson, Jan.doc
7
Ontwerp-Peerassessment-1.0-opmerkingen Thom, Piet.doc
Ontwerp-Peerassessment-1.0-opmerkingen Huizinga, Annet.doc
Het document na verwerking van de opmerkingen:
Ontwerp-Peerassessment-1.1.doc
Deze naamgeving zorgt er tevens voor dat de documenten verschillende namen krijgen en zo elkaar
dus niet overschrijven wanneer de geretourneerde (elektronische) documenten in dezelfde map
worden opgeslagen.
Proces: veranderen van een document voor goedkeuring op RdMC-niveau
Wanneer een document RdMC-status “Ter verbetering” heeft, heeft dat ook op projectniveau
gevolgen. Immers, de waarde voor Projectstatus was “Definitief”. Verbetering van het document
betreft een verandering aan de inhoud en bijgevolg dus een nieuw versienummer. Dat betekent dat
het nieuwe document meestal ook op projectniveau ter goedkeuring moet worden aangeboden om
een nieuwe versie te krijgen met Projectstatus “Definitief”. Deze versie zal uiteindelijk dan op
projectniveau de “Huidige versie” vervangen.
Proces: creatie van een nieuw document uit meerdere andere documenten
Wanneer een document gecreëerd wordt door meerdere andere documenten samen te voegen, dan
zal dat nieuwe document versienummer 1.0 krijgen. Om echter achteraf na te kunnen gaan dat het
betreffende document ontstaan is uit andere documenten, wordt aangeraden aan het begin van het
nieuwe document op te nemen welke documenten (titel, versienummer) de bron vormden (bv. via het
documentkenmerk “historie”).
Verplichting uniforme naamgeving en vastlegging overige documentkenmerken
Ieder project is vrij zich aan de hier voorgestelde naamgevingsafspraken en vastlegging van overige
documentkenmerken te houden. Documenten die worden aangeboden aan de poortwachter van de
RdMC-kluis moeten echter voldoen aan de voorwaarden die hier staan opgenoemd. De volgende
voor- en nadelen kunnen worden genoemd bij het volgen van de voorstellen binnen een project.
Voordelen
- Duidelijkheid voor iedere betrokkene over status en inhoud van document zonder de inhoud te
hoeven lezen.
- Wanneer binnen een project gebruik wordt gemaakt van een centrale opslag waarin ook
documenten met een status anders dan “Goedgekeurd” worden opgenomen, dan zijn de
documenten beter terugzoekbaar.
Nadelen
- Extra administratiewerk voor de documentverantwoordelijke, ook bij versies waarvan bijna
zeker is dat ze nog veranderd gaan worden
- Hangt helemaal af van de discipline van de projectmedewerkers. De genoemde voordelen
worden slechts ten dele gehaald wanneer niet iedereen meedoet.
8