E-DEPOT 2004 DOEN! Het projectplan in het kort

Transcriptie

1 E-DEPOT 2004 DOEN! Het projectplan in het kort

2 Inhoudsopgave Inleiding 3 1 Het doel 3 2 Projectontwerp 3 A. Producten en resultaten 3 B. Besturing van het project 4 C. Het veranderingsproces 4 3 Projectinhoud 5 A. Producten en resultaten 5 a.1 Resultaat, product en toelichting 5 a.2 Methoden en technieken 7 a.3 Ontwikkelstappen 8 a.4 Fasering 9 B. De besturing van het project 9 b.1taakverdeling en verantwoordelijkheden 9 b.2 Relaties met andere projecten en partnerships 11 b.3 Kwaliteitsborging 11 C. Veranderingsproces 13 Bijlage 1 14 Beknopte beschrijving van de ontwerpmethode 14 2

3 Inleiding 1 Het project E-depot, projectjaar 1 maart 2004 tot en met februari 2005, is een samenwerkingsverband van het Gemeentearchief Rotterdam met de Stichting Archiefschool. Dit document is een bewerking van van het projectplan E-depot 2004, versie 1.0. In hoofdstuk 1 wordt het doel en de uitgangspunten beschreven. Daarna volgt in hoofdstuk 2 het projectontwerp aan de hand van de drie gehanteerde invalshoeken, te weten: de producten en resultaten, de besturing van het project en het bijbehorende veranderingsproces. In hoofdstuk 3 wordt, ook aan de hand van de genoemde invalshoeken, de projectinhoud beschreven. 1 Het doel De oorspronkelijke, ruim gestelde opdracht voor het project E-depot: het opzetten van de functionaliteiten voor een digitaal depot, met instructies, procedures en opgeleide medewerkers, zodat het Gemeentearchief Rotterdam na 2004 digitale documenten (archiefdocumenten, publicaties, beeld- en geluid) in een goede, geordende en toegankelijke staat kan beheren, acquireren en ter beschikking stellen. Het begrip digitaal depot of E-depot is gedefinieerd als het geheel van apparatuur, programmatuur, procedures, methoden, kennis en vaardigheden waarmee het gemeentearchief in staat is zijn digitale informatie te beheren en beschikbaar te stellen. Van zowel de opdracht als de definitie is aangegeven dat lopende het project bijstelling kan plaatsvinden. Daarnaast zijn, gezien de korte doorlooptijd en de hooggespannen verwachtingen, de uitgangspunten en begrenzingen zo duidelijk mogelijk geformuleerd: - Voor het project kiest het gemeentearchief voor een preserveringsstrategie gebaseerd op standaardisatie en migratie; deze strategie is ook elders toegepast en beproefd. - Het organisatiemodel is primair custodial, dat wil zeggen het archief doet het zelf. De consequenties van een mogelijk gemengde bewaarvorm (custodial en non-custodial) worden wel in kaart gebracht ten behoeve van het ontwikkelen van beleid. Non-custodial wordt globaal verkend. - De hard- en softwareomgeving is gebaseerd op open standaards en open source, met als basis software DSpace. Hierbij speelt de overweging een rol dat lange termijn duurzaamheid alleen te realiseren is onder open standaards en met open source. Naar verwachting heeft DSpace de eerste noodzakelijke functionaliteit, de software is open en reeds een groot aantal malen geïmplementeerd in (universiteits)bibliotheken, waaronder die van de Erasmus Universiteit Rotterdam. 2 Projectontwerp De inrichting van het project is gebaseerd op drie invalshoeken: A. Producten en resultaten Onder producten en resultaten valt de creatieve invalshoek, met andere woorden het zijn de producten als resultaten van het ontwikkel- en ontwerpproces. De uitgangspunten daarvan zijn: De ontwikkelmethode is cyclisch, waarbinnen prototyping centraal staat. Elke cyclus levert een gedefinieerde bijdrage aan de ontwerpdocumenten. De cyclische aanpak waarborgt flexibiliteit en ondersteunt het leerproces. Na afloop van het project blijft het prototype gehandhaafd als begin van het operationele systeem. Dat betekent dat het prototype voldoende robuust en gedocumenteerd moet zijn. 1 Dit document is een bewerking van het projectplan E-depot 2004, versie 1.0 3

4 B. Besturing van het project Onder de besturing van het project valt de procesmatige of economische invalshoek, met andere woorden het projectmanagement. De uitgangspunten daarvan zijn: Het project is low cost, met als leidende gedachte dat wanneer een depot niet met bescheiden middelen kan worden ontwikkeld en ingericht, het toekomstig beheer van digitale informatie de facto onmogelijk is. Het project is afhankelijk van de beschikbaarheid van de projectgroepleden voor het project; dit is een logisch gevolg van de low cost benadering; er is nauwelijks budget voor externe consultancy beschikbaar. De actieve betrokkenheid van de projectgroepleden past ook in het projectontwerp (zie hierna) waarin het leren centraal staat Niet alle functionaliteiten van het E-depot zullen volledig hoeven te worden uitgewerkt. Tot het project hoort niet het daadwerkelijk vullen van het E-depot. Het prototype geeft een eerste aanzet voor een E-depot. Hierna begint de praktijk en de werkelijke toetsing van het resultaat. De software, kennis en procedures die het project oplevert, zijn daarvoor de basis. C. Het veranderingsproces Onder het veranderingsproces vallen de gevolgen voor de organisatie, in brede zin. De uitgangspunten daarvan zijn: Het belang van het leereffect voor het gemeentearchief, te verwerven kennis of te vragen advies moet steeds gebaseerd zijn op het op te lossen probleem en de daarmee verbandhoudende vragen die in het project gesteld worden. Ontwikkelen gaat vooraf aan formeel ontwerpen, met andere woorden: het ontwerp is het resultaat van ontwikkelen. Het prototype staat centraal in het creatieve proces waardoor het leereffect gestimuleerd wordt. Het cyclische verloop van het ontwikkelproces; leereffecten worden toegepast in een tweede ontwikkelcyclus. In verband met de korte doorlooptijd van het project blijft het aantal cycli beperkt tot twee. Dat voorkomt ook het risico van rondzingen. Het prototype dient eerst om vertrouwd te raken met de mogelijkheden van de software, vervolgens om de functionaliteit van het E-depot te bepalen en tenslotte om de mogelijkheden en beperkingen van de gekozen software vast te stellen. De modulariteit (de verschillende stappen) ondersteunt de beheersing van de cyclische benadering. Onderstaande figuur schetst de samenhang tussen de modules. beperkingen testset testplan Identificatie 1e ontwerpschets 1e prototype cyclus 2e prototype cyclus generalisatie middelen Ontwerp documente n Generiek model 4

5 3 Projectinhoud A. Producten en resultaten a.1 Resultaat, product en toelichting We onderscheiden drie resultaatgebieden voor het project die onderstaande producten gaan opleveren: 1. de directe resultaten van het ontwikkel- en ontwerpproces Een werkend prototype van een E-depot, waarmee de vereiste functionaliteiten kunnen worden vastgesteld, de werking gedemonstreerd aan medewerkers van het gemeentearchief en andere belangstellenden en dat als uitgangspunt dient voor de verdere ontwikkeling na Toelichting prototype Gezien de onzekerheid over de noodzakelijke functionaliteit, de financiële haalbaarheid van de ontwikkeling van een E-depot, de projectdoelstellingen en het beperkte budget ligt het voor de hand een prototype te ontwikkelen. Dit prototype zal in beginsel alle gewenste functionaliteit omvatten, maar hoeft niet noodzakelijk klaar te zijn. Het gaat in de eerste plaats om de definiering van de functionaliteit; vervolgens om een beoordeling van de geselecteerde software, een inzicht in de eisen die aan interfaces gesteld worden, inzicht in de organisatorische voorwaarden en uiteindelijk het vervaardigen van adequate ontwerpdocumenten (systeemdocumentatie). Niet in de laatste plaats is het prototype een instrument voor het verwerven van kennis over en vaardigheden in beheer en gebruik van een E-depot. Het prototype is uitdrukkelijk bedoeld als start van een volledig E-depot; het is geen "proof of concept". Het wordt na afloop niet weggegooid maar het gemeentearchief wil het na afronding van het project operationeel inzetten en verder geleidelijk uitbouwen. De centrale positie die het prototype in het project in neemt stelt enerzijds eisen aan de flexibiliteit van de ontwikkelings- en projectmanagementmethoden, anderzijds aan de volledigheid van de op te leveren documentatie. Het ontwikkelen van de documentatie is onderdeel van het proces van prototypen, maar de kwaliteit ervan mag niet ten koste gaan van de energie die in het bouwen van een systeem gestoken wordt. De documentatie is immers een gelijkwaardig eindproduct, mede omdat daarin de uiteindelijke specificaties van het systeem vastgelegd zijn die de grondslag vormen voor de verdere ontwikkeling. Een formeel systeemontwerp voor een E-depot, dat gaat fungeren als de basis voor de verdere uitbouw, bestaande uit een organisatiemodel (organisatieontwerp), een Logisch Ontwerp (conceptueel ontwerp) en een implementatie model (technisch ontwerp). Toelichting systeemontwerp Het systeemontwerp is te zien als de formele weergave van het prototype. Het beschrijft de architectuur van het E-depot. Het maken van het systeemontwerp verloopt grotendeels parallel met het uitvoeren van het prototype. Door middel van het prototype ontwikkelt de projectgroep de gewenste functionaliteit. Deze functionaliteit wordt vervolgens formeel vastgelegd in een document dat onderdeel uitmaakt van het systeemontwerp (procesmodel, zie bijlage 1). Het systeemontwerp omvat ook een beschrijving van de gegevens die het systeem zelf genereert en/of nodig heeft voor beheer en gebruik. Het systeemontwerp bevat een document waarin deze gegevenstypen formeel worden beschreven (metadata model). De wijze waarop het systeemontwerp tot stand komt, stelt eisen aan de ontwerp-methode; deze moet geleidelijke en cyclische ontwikkeling ondersteunen (zie a.2 Methoden en technieken). 2. Het implementatieresultaat: het E-depot is verankerd in het gemeentearchief en op termijn zal de projectverantwoordelijkheid overgaan naar lijnverantwoordelijkheid. Aan het einde van het project moet deze overgang van verantwoordelijkheden aan iedereen duidelijk zijn. (Dit laat onverlet dat 5

6 het management van het gemeentearchief in 2005 kan beslissen een nieuw project te starten voor de uitwerking van functionaliteiten die in het prototype onvoldoende aan bod zijn gekomen). Het implementatieresultaat bestaat concreet uit: Ontwerp van de veranderingen in de organisatie van het gemeentearchief, die eventueel noodzakelijk zijn om een effectief E-depot in te richten, te gebruiken en te beheren. Het project brengt de IST situatie in kaart, beschrijft de SOLL situatie, implementeert deze voor zover binnen het project mogelijk en geeft aan langs welke weg de organisatie verder moet veranderen (organisatiemodel). Toelichting organisatie Het E-depot heeft invloed op de procedures en methoden voor archiefbeheer. Het is dan ook niet onwaarschijnlijk dat de organisatiestructuur zich zal moeten aanpassen aan de introductie van een E-depot. Het in kaart brengen van de organisatorische consequenties maakt nadrukkelijk onderdeel uit van het project. De ontwikkelmethode voorziet in een beschrijving van de gewenste organisatie (organisatiemodel). Formele vastlegging van de kennis, in de vorm van regels, richtlijnen, voorschriften, procedures, taakbeschrijvingen enzovoort, noodzakelijk voor een effectief gebruik en beheer van een E-depot. Het Logisch Ontwerp legt deze kennis vast in een kennismodel. Toelichting formele vastlegging van kennis Het zijn in de eerste plaats de medewerkers die de benodigde kennis en vaardigheden verwerven; zij zullen immers straks het systeem gebruiken en beheren. Persoonsgebonden kennis is evenwel vluchtig, ze gaat verloren wanneer de medewerker de organisatie verlaat. Daarom wordt de kennis over het systeem zoveel als mogelijk vastgelegd in de vorm van instructies, handleidingen, systeembeschrijvingen en procedures. Deze beschrijvingen maken deel uit van het systeemontwerp (Logisch Ontwerp). De methode voor systeemontwerp moet dus niet alleen voorzien in het ontwikkelen van een structuur voor de beschrijving van de functionaliteit en metadata, maar ook om de kennis vast te leggen en te onderhouden. De gekozen methode SDF voldoet ook aan deze eis. 3. Het leerresultaat: een basis voor continu verbeteren. Verwerven van competenties door medewerkers van het gemeentearchief in het gebruik en beheer van een E-depot, aangevuld met een beschrijving van de noodzakelijk nog te verwerven kennis en vaardigheden. Toelichting competenties Een belangrijk doel van het project is dat medewerkers van het gemeentearchief competenties verwerven die nodig zijn om succesvol een E-depot te kunnen ontwikkelen, beheren en gebruiken. Medewerkers zullen dan ook actief bij het project betrokken worden; in beginsel definieren zij de problemen en zoeken de oplossing. De externe projectleider (zie projectorganisatie) treedt daarbij in de eerste plaats coachend op. Het project heeft sterk het karakter van een cursus of onderwijsmodule volgens moderne didactische principes. Het projectmanagement wordt daarop afgestemd, ondermeer door een min of meer modulaire opbouw van het project zelf. Deze aanpak draagt onder meer bij aan het veranderingsproces dat het gemeentearchief als organisatie zal ondergaan. Generalisatie en abstractie van projectresultaten in een zodanige vorm dat deze gebruikt kunnen worden door het Nederlandse archiefwezen. Dit zal in hoofdzaak neerkomen op het bewerken van het Logisch Ontwerp. Toelichting generalisatie en abstractie Een expliciet doel van het project is de beschikbaarstelling van de verworven kennis en opgedane ervaringen aan het (Nederlandse) archiefwezen. De laatste fase van het project decontextualiseert de resultaten; dat wil zeggen het systeemontwerp wordt ontdaan van die 6

7 elementen die specifiek gelden voor het gemeentearchief. De ontwikkelingsmethode moet dus voorzien in een mechanisme voor generalisatie en abstractie. Het onderscheid dat SDF maakt in een essentieel model en een implementatie model is daarvoor zeer geschikt (zie bijlage 1). Door bovendien het essentieel model te baseren op bestaande referentiemodellen (OAIS, InterPares) wordt aansluiting verkregen bij internationale ontwikkelingen. Implementatie E-depot Resultaat Proces van leren Continu verbeteren Verankeren Leren is een continu proces. Aan alle bovengemelde resultaten zal het gemeentearchief de komende jaren substantieel aandacht moeten besteden, door middel van opleidingen, trainingen, communicatie enzovoort. Voor de mentale inbedding in de organisatie is een goede communicatie onmisbaar. Een afzonderlijk communicatieplan heeft vanaf het begin van de projectplanning een onderdeel uitgemaakt van projectbeheersing. a.2 Methoden en technieken Ontwikkelen en ontwerpen Ontwikkelen. De ontwikkeling van het systeem en de verwerving van kennis wordt gerealiseerd door middel van prototyping. Op basis van globale specificaties wordt direct een werkend systeem gebouwd. De methode die daarbij gehanteerd wordt is time-boxing. Tevoren wordt in een workshop vastgesteld hoe lang een ontwikkelcyclus mag duren en welke functionaliteit idealiter moet worden gerealiseerd. Ontwerpen. Bij prototyping komt de ontwerpdocumentatie gaandeweg tot stand. Prototyping is bij uitstek een cyclische aanpak en niet alle methoden en technieken ondersteunen zo n benadering effectief. Daar staat tegenover dat bij prototyping dikwijls juist weinig aandacht aan documentatie wordt besteedt: het prototype zelf wordt gezien als voldoende documentatie. De beide tegenstelde eisen in dit project stellen dus bijzondere, tegengestelde eisen aan aan de ontwerpmethode, projectaanpak en modellering: flexibiliteit en zorgvuldigheid van documentatie. Een methode die aan deze eisen tegemoet komt is SDF (System Development Framework, ontwikkeld door het Kenniscentrum Cibit (Utrecht) voor de ontwikkeling van kennisintensieve systemen (zie bijlage 1). 7

8 a.3 Ontwikkelstappen Het project is opgedeeld in de hieronder kort beschreven ontwikkelstappen (modules). Voor elke stap/module wordt een afzonderlijk plan van aanpak geschreven in de vorm van een modulehandleiding of -draaiboek. Steeds wordt vastgesteld wat de problemen zijn en hoe deze zullen worden opgelost. Voor elke module wordt een werkgroep ingesteld en steeds wordt de module formeel afgesloten met een rapport aan de stuurgroep. 1. Identificatie, analyse en ordening van de op te lossen problemen. Het gegeven probleem (de ontwikkeling van een E-depot) wordt nader opgedeeld in concrete vragen. De basis voor die analyse vormen bestaande referentiemodellen voor digitale depots, zoals het Open Archives Information System Model (OAIS), het InterPares model van de preservation function en het functioneel ontwerp Depot 2000 van het Nationaal Archief. Aan de hand van literatuur worden de onderzoeksvragen verder gespecificeerd. Het primaire resultaat van deze module is een beschrijving van de oplossingsrichting; een eerste versie van het essentiële model wordt opgesteld. De verworven kennis wordt vastgelegd in documenten die deel uitmaken van de systeemdocumentatie. 2. Bijeenbrengen van een testset. Een representatief aantal digitale objecten (documenten) van verschillende typen wordt geselecteerd om het prototype te testen. 3. Opstellen van een testplan. Het essentieel model dient als uitgangspunt; de vereiste kwaliteiten van het systeem zijn daarin vastgelegd. Het testplan beschrijft in operationele termen welke activiteiten verricht worden en aan de hand van welke criteria de prestaties van het systeem worden beoordeeld. 4. Eerste cyclus prototyping. 4.1 Prototypeontwerp en prototypebouw. Op basis van de oplossingsrichting en de gehanteerde referentiemodellen wordt een eerste ontwerp voor het prototype gemaakt en een eerste versie van het prototype zelf gebouwd. Ten behoeve daarvoor wordt de hard- en softwareomgeving ingericht. Het ontwerp wordt vastgelegd in de systeemdocumentatie (implementatiemodel). Kennis van de software wordt expliciet vastgelegd. De eerste versie van het prototype behoeft nog niet alle functies te bevatten. De keuze welke functies in het eerste prototype gerealiseerd gaan worden maakt onderdeel uit van het ontwerpproces. 4.2 Uitvoeren prototype. Alle functies die in het prototype zijn gerealiseerd worden getest, in beginsel met alle typen digitale documenten. De resultaten worden verwerkt in de systeemdocumentatie, zowel essentieel model als implementatiemodel. Van het testen worden een rapport opgesteld dat dient voor de tweede prototypingcyclus. 5. Tweede cyclus prototyping. Op basis van de testresultaten en de eerder gemaakte ontwerpafspraken worden de stappen 2 tot en met 4 herhaald. Het essentiële model wordt voltooid, dat wil zeggen volledig beschreven. Het implementatiemodel verder bijgesteld. 6. Op basis van de tweede ronde prototyping wordt het systeem geëvalueerd. Voltooiing en validatie van: Het essentiële model Het implementatiemodel Het organisatiemodel Alle verworven en expliciet gemaakte kennis wordt in de systeemdocumentatie opgenomen. 7. Generalisatie en abstractie. De projectresultaten worden in een zodanige vorm gegoten dat ze bruikbaar zijn voor het hele Nederlandse archiefwezen. Het essentiële model vormt daarvoor het uitgangspunt. 8

9 a.4 Fasering De modules volgen elkaar gedeeltelijk op of worden deels parallel doorlopen. In die zin is er niet echt sprake van fasen. In onderstaande fasering zijn de modules in tijd uitgezet: Module Start Eind 1 Identificatie, eerste ontwerpschets /4 2 Selectie testset /4 3 Opstellen testplan /5 4.1 Prototype 1 ste ontwerp en bouw Uitvoeren 1 ste prototype Rapportage Tweede cyclus prototype, 2 de ontwerp en bouw Uitvoeren 2 de prototype Rapportage prototyping Generalisatie en abstractie Eindrapportage Formele afsluiting van het project 13-1 B. De besturing van het project Het doel van het project vereist een bijzondere aanpak. Een van de belangrijkste invalshoeken van het project is de inbedding van het systeem in de organisatie. Het gemeentearchief heeft gekozen voor het leereffect, dat wil zeggen dat het verwerven van de noodzakelijke competenties leidend is. In grote trekken komt het project zo overeen met een onderwijsmodule. Het beginpunt is het organisatieprobleem: hoe moet het gemeentearchief een E-depot inrichten en wat is er vervolgens voor nodig om dat depot te onderhouden. Projectmanagementmethode Als projectmanagementmethode wordt Prince2 gebruikt. De methode zal worden afgestemd met het cyclische karakter van het project. Behalve op de producten van elke fase of cyclus wordt het project beheerst in tijd, kwaliteit en middelen. Elke fase wordt primair begrensd door de tijd (time boxing). Voor elke fase zal worden vastgesteld wat de producten moeten zijn, welke inzet nodig is en welke risico s voor het niet bereiken van het gewenste resultaat een rol spelen (zie ook hierna sub risicomanagement). Kenmerken van Prince2 zijn: Management georiënteerd in plaats van techniek georiënteerd Heldere projectorganisatie Planning gericht op het opleveren van (tussen) producten Opdeling van het project in beheersbare fasen Prince2 voldoet aan ISO-9000 en ISO norm, een zeer hoge standaard voor een organisatie die aan professioneel projectmanagement doet. b.1 Taakverdeling en verantwoordelijkheden Opdrachtgever Opdrachtgever is de gemeentearchivaris van Rotterdam. 9

10 Stuurgroep De stuurgroep bewaakt de voortgang van het project; de projectgroep voert het project uit. De projectgroep kan voor specifieke activiteiten werkgroepen instellen. De stuurgroep bestaat uit 2 medewerkers van het gemeentearchief en 1 medewerker van de Archiefschool. Beide projectleiders (zie hierna) wonen de vergaderingen van de stuurgroep bij. De stuurgroep vergadert bij de overgang tussen fasen en wanneer een go/nogo beslissing genomen moet worden. Voorts vergadert de stuurgroep zo dikwijls als dat nodig blijkt te zijn. De taken van de stuurgroep zijn: Sturen op resultaten, mensen en middelen Toezicht op de voortgang Toewijzen van budget Nemen van een go/no go beslissing na elke fase Zorgdragen voor communicatie Projectleiding Het project heeft een externe en een interne projectleider. De interne projectleider bewaakt in de eerste plaats de voortgang in procedurele zin. De externe projectleider fungeert als coach en is verantwoordelijk voor de kwaliteit van de ontwerpdocumenten. De taken van de interne projectleider zijn: Voorzitten van de projectgroep Zorgdragen voor continuiteit van het project, in het bijzonder wat betreft de participatie van projectgroepleden Organiseren van de interne projectorganisatie, waaronder de ondersteuning van het projectsecretariaat Regelen van de noodzakelijke middelen Doen uitgaan van formele brieven Samen met de externe projectleider voorbereiden van te nemen besluiten (zowel door de projectgroep als van de stuurgroep) Verzorgen van de interne en externe communicatie (Doen) inrichten van de ontwikkel- en testomgeving (Doen) verzamelen van kennis, deze uitdragen en borgen in de organisatie van het gemeentearchief. De taken van de externe projectleider zijn: Opstellen en bewaken van de projectplanning Bijhouden van het projectdossier Opzetten en onderhouden van een teamsite ten behoeve van samenwerking binnen de projectgroep Coordineren van de inzet van andere medewerkers van de Archiefschool Ontwikkelen, cq doen ontwikkelen van de ontwerpdocumenten Adviseren van de Stuurgroep bij te maken keuzen Samen met de interne projectleider voorbereiden van te nemen besluiten (zowel door de projectgroep als van de stuurgroep) Onderhouden van contacten met externe partners Redigeren van het eindrapport Generaliseren en abstraheren van de bevindingen tbv het Nederlandse archiefwezen Mede vormgeven van de in- en externe communicatie De extern projectleider wordt binnen de Archiefschool bijgestaan door twee medewerkers, die in voorkomende gevallen bij het project betrokken kunnen worden. 10

11 Projectgroep In de projectgroep hebben zitting de afdelingshoofden van de beherende afdelingen (Atlas, Bibliotheek, Archieven), van Baliediensten, Bedrijfsvoering, Atelier Materieel Beheer en de eerste medewerker Atelier Materieel Beheer; deze laatste vanwege zijn specifieke competenties op het gebied van digitalisering. De multidisciplinaire samenstelling van de projectgroep vergroot het vermogen tot kennisverwerving over digitale duurzaamheid. De projectgroepleden maken de tijd vrij die noodzakelijk is voor het slagen van het project; bovendien zorgen ze dat hun medewerkers op de hoogte zijn van de voortgang en stellen hen, waar nodig, in staat een actieve bijdrage aan het project te leveren. Immers, alle medewerkers die zich uit hoofde van hun functie bezighouden met acquisitie, beheer, behoud en toegankelijk maken van digitale informatie binnen het gemeentearchief, zijn direct of indirect bij het project betrokken. Met vakspecifieke deskundigheid bepalen zij mede de uiteindelijke vorm van het E-depot. De projectgroep vergadert in beginsel elke twee weken. b.2 Relaties met andere projecten en partnerships E-depot 2004 is een samenwerkingsproject van het Gemeentearchief Rotterdam en de Stichting Archiefschool, die de externe projectleider levert. Voor het gemeentearchief levert het project allereerst een werkend E-depot op; voor de Archiefschool gaat het vooral om de toetsing van de praktijk aan de theorie, om kennis die gebruikt kan worden in het onderwijs. Het Nationaal Archief (NA) is een mogelijke derde partner, minimaal op basis van uitwisseling van ervaringen. Gemeentearchief Rotterdam en Nationaal Archief zullen parallel aan hun projecten werken en benchmarken. Voor de feitelijke inrichting wordt samengewerkt met HP Nederland, in het bijzonder wat betreft DSpace. b.3 Kwaliteitsborging Kwaliteitszorg wordt uitgevoerd door het bewaken van het projectplan in de meest brede zin, het correcte gebruik van standaarden, optimale toepassing van bestaande kennis en inzichten, aansluiting op gebruikerswensen en de juiste inzet van de juiste mensen. Vooralsnog is nog geen expliciet verantwoordelijke voor kwaliteitsbewaking aangewezen en zal de stuurgroep de rol van kwaliteitsbewaker moeten vervullen. Ontwerpdocumenten zullen in elk geval aan een interne toetsing binnen de Archiefschool worden onderworpen. Raadpleging van experts behoort eveneens tot de kwaliteitsverhogende maatregelen. In overleg met de stuurgroep zullen de projectleiders vaststellen welke kwaliteitseisen (normen) gesteld worden aan de producten en zullen ze de verwachtingen van de toekomstige gebruikers inventariseren. De projectleiders zullen een voorstel doen aan de hand van een Project Break Down en de bijbehorende productbeschrijving. Binnen de projectgroep worden de verantwoordelijkheden voor de op te leveren producten vastgelegd. De stuurgroep beoordeelt steeds de kwaliteit van de tussenresultaten en het eindresultaat. Basis voor referentie van de resultaten van het prototype zijn de bestaande referentiemodellen voor digitale conservering (zie a.3 Ontwikkelstappen). Toetsing van de projectresultaten aan bestaande best practices (vergelijking met reeds werkende digitale depots) behoort eveneens tot de kwaliteitsverhogende maatregelen. 11

12 Communicatie en informatie-uitwisseling Allerlei communicatiemiddelen worden ingezet om mensen bij het project te betrekken. Hieronder volgt een opzet voor het communicatieplan voor interne en externe doelgroepen: Interne Middelen Planning Toelichting doelgroepen stuurgroep en projectgroep stuurgroep en projectgroep Kick-off bijeenkomst Projectplan en opzet van het project. Motivatiebijeenkomst Projectinformatie op permanent de kennisbank (teamsite) Op online kennisbank van de Archiefschool staan alle projectdocumenten, verslagen, literatuurverwijzingen en links naar relevante sites. stuurgroep Rapportages volgens fasering Rapportages van tussenresultaten, bijsturing van het project (go/no go) stuurgroep Overleg 2-wekelijks toelichting op rapportages, informeren, tussentijdse ingrepen projectgroep Overleg Volgens fasering overlegvorm met kennisoverdracht. Voortgangsbewaking afdelingshoofden en medewerkers medewerkers gemeentearchief medewerkers gemeentearchief Bilateraal wanneer nodig, in regulier afdelingsoverleg probleeminventarisatie bij alle afdelingen GAR-net/ intranet Permanent Informeren en betrokkenheid krijgen bij alle betrokkenen bij digitale informatie Nieuwsbrief 3x in project Informeren en betrokkenheid krijgen bij alle betrokkenen bij digitale informatie Extern Middelen Planning Toelichting Doelgroepen Nationaal Archief Benchmarking Wanneer nodig Ervaringen uitwisselen Collegaarchiefdiensten, bezoekers Symposium met NA September 2004 Tussentijdse resultaten naar buiten toe uitdragen, samen met Nationaal Archief (NA) Collegaarchiefdiensten, bezoekers Persbericht; website Tussentijds en december 2004/ januari 2005 Project en projectresultaten naar buiten toe uitdragen, in het bijzonder naar collegaarchiefdiensten 12

13 Risico management Elk project is onderhevig aan risico s. Voor het project E-depot 2004 zijn de volgende risico s onderkend en gewogen (op een schaal van 1-5): risico kans gevolg gewicht maatregelen Nieuwe technologie (DSpace) Onvoldoende tijd en prioriteit voor het project bij leden projectgroep Onvoldoende middelen beschikbaar voor het project Prioriteitstelling van doelen onduidelijk belangen gemeentearchief en Archiefschool lopen deels uiteen Opleiden medewerkers I&A; consultancy stuurgroep draagt belang uit; duidelijke planning; medewerkers doordringen van noodzaak tijd vrij te maken stuurgroep zorgt voor aanvullend budget projectleiders signaleren, stuurgroep prioriteert stuurgroep neemt tijdig maatregelen. C. Veranderingsproces Zoals aangegeven in het projectontwerp is een van de drie gehanteerde invalshoeken het veranderingsproces. Dit veranderingproces is zichtbaar in de gekozen uitgangspunten en de te behalen resultaten (implementatie- en leerresultaat). Vervolgens is de relatie gelegd met de projectinhoud (het ontwikkelproces en de stappen). Kennisverwerving Het verwerven van de noodzakelijke kennis om een E-depot te kunnen gebruiken en beheren is een belangrijk onderdeel van het project. Vandaar de didactische opzet. De voornaamste methode is die van probleemgestuurde kennisverwerving. De op te lossen problemen bepalen welke kennis noodzakelijk is. De voornaamste technieken voor kennisverwerving zijn: - literatuurstudie (vooral archivistische kennis mbt digitale archivering) - externe advisering (o.a. gebruik van de software) - participatie (prototyping, workshops) De verworven kennis wordt zoveel mogelijk expliciet gemaakt en vastgelegd in het systeemontwerp. 13

14 Bijlage 1 Beknopte beschrijving van de ontwerpmethode De methode is gebaseerd op Yourdon Systems Method, een cyclische methode bestaande uit een reeks modellen, die steeds een specifiek aspect van het systeem beschrijven. Deze modellen (zeg hoofdstukken) worden gedurende het project geleidelijk ingevuld. De wijze van invullen is niet willekeurig, maar volgt de cycli of iteratieslagen van het project (zie de paragraaf over methode en fasering.) SDF voegt aan Yourdon een tweetal belangrijke componenten toe. De eerste is de modellering van kennis. Daarvoor gebruikten de opstellers van de methoden de resultaten van een Europees project voor het ontwikkelen van een methode voor het ontwerpen van kennisintensieve systemen: CommonKads. De tweede component is de aandacht die SDF besteedt aan de organisatorische aspecten. Dat laatste heeft o.a. te maken met de opvatting dat een kennisintensief systeem niet zozeer een expert system is, maar een informatiesysteem dat zelf kennis (omgevingskennis, procedurele kennis) gebruikt om goed te functioneren. Juist deze toevoegingen gepaard aan de centrale rol van modellen - maken SDF geschikt voor het project. SDF onderscheidt drie centrale modellen: het Organisatiemodel, het Logisch Ontwerp en het Implementatie model. Het Logisch Ontwerp en het Implementatiemodel bestaan elk weer uit een aantal deelmodellen. Organisatiemodel Beschrijving van de organisatie waarbinnen het systeem moet functioneren. In het organisatiemodel is ook ruimte voor het aangeven van noodzakelijke veranderingen. Idealiter is het uiteindelijke Organisatiemodel dan ook een Soll-model. Logisch Ontwerp (voorheen Essentieel model) Het Logisch Ontwerp beschrijft het te ontwikkelen systeem op abstract functioneel niveau, dat wil zeggen onafhankelijk van de wijze waarop het gerealiseerd gaat worden. Voor het project zal het Logisch Ontwerp het belangrijkste product zijn voor verspreiding in het archiefwezen. Het Logisch Ontwerp bestaat uit de volgende deelmodellen: - Omgevings model (voorheen Context model). De interactie van het systeem met zijn omgeving (andere systemen, gebruikers, beheerders). Het Omgevings model is de basis voor de externe functionaliteit, dwz wat het systeem voor zijn gebruikers betekent. - Proces model. De processen waarmee het systeem zijn taken vervult, zoals opnemen, opslag, verwijderen, conversie etc. Het proces model is de basis voor de interne functionaliteit, wat het systeem daadwerkelijk moet doen om de gewenste externe functionaliteit te verwezenlijken. - (Meta) Data model. De gegevens die het systeem opneemt, genereert en/of communiceert om zijn taken uit te voeren. Voor een archiefbeheersysteem, zoals een digitaal depot, is dit dus een metadatamodel. - Kennis model. De kennis die het systeem opslaat en gebruikt om zijn taken naar behoren te vervullen. Dit kan bestaan uit kennis over de organisatie of de gebruikers, kennis over de archieven, en procedures, criteria, regels etc. Het domeinmodel krijgt nadrukkelijk de aandacht in het project. - Besturings model. Een beschrijving van de wijze waarop de activiteiten van het systeem worden aangestuurd; bijvoorbeeld wanneer een conversie plaats moet vinden of hoe een gebruikersverzoek wordt beoordeeld. Implementatiemodel Het implementatiemodel bestaat uit vier deelmodellen: - Processormodel. Een beschrijving van de processoren (mensen, machines) die de processen uit het essentiële model uitvoeren. - Het Mens machine interface model (voorheen Human Computer Interface model): de communicatie tussen taken die door mensen worden uitgevoerd en taken die door computers worden verricht. 14

15 - Software omgeving model. De beschrijving van de basis software (software eenheden, zoals pakketten) die voor de realisatie van de applicaties wordt gebruikt, zoals het database management system, opslagsoftware, retrieval pakketten etc. - Module model. Een beschrijving van de modulaire structuur van de software eenheden. Het resultaat is een programma ontwerp per software eenheid. Idealiter komt het module model in hoge mate overeen met de structuur van het proces model. Voor het beschrijven van een model staan verschillende technieken ter beschikking, variërend van natuurlijke taal tot en met diverse grafische representaties. Voor de vastlegging worden de volgende technieken toegepast: Organisatie model: Tekst in natuurlijke taal, aangevuld met organogrammen. Logisch Ontwerp: Data Flow Diagrams (volgens De Marco) voor het omgevings model en het proces model; aangevuld met tekstuele toelichting; Entity Relationship Diagrams of Nyssen voor het metadata model; aangevuld met tekstuele toelichting; Tekst in natuurlijke taal of formele regels voor het kennismodel. Implementatie model Tekst in natuurlijke taal, aangevuld met diagrammen voor module model. Inpassing van de ontwikkelmethode in de fasering De modellen hoeven niet sequentieel te worden ontwikkeld. Elke fase van het project of afzonderlijke activiteit kan bijdragen aan een model. In de ontwikkeling van een model onderscheiden we drie niveaus: identificatie (i), beschrijving (b), validering (v). Identificering wil zeggen dat alle componenten (attributen) waaruit het model bestaat zijn vastgesteld. Beschrijving betekent dat deze componenten zijn beschreven (de attributen zijn van waarden voorzien). Validatie betekent dat het model, dus het betreffende hoofdstuk van het uiteindelijke systeemontwerp, is vastgesteld en dus voltooid. Door te bepalen welke status de modellen in welke fase van het project bereikt moeten hebben, kan de voortgang van het project bewaakt worden. 15