Project Final Report

2004-2006

DISSCO Document Management: Integrated System for Scientific Organisations

Project Final Report

A project of the multiannual information society support program financed by the Belgian Federal Science Policy Office

Table of Contents

1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.5.1 2.1.5.2 2.1.5.3 2.2 2.2.1 2.2.1.1 2.2.1.2 2.2.1.3 2.2.1.4 2.2.1.5 2.3 2.3.1 2.3.2 2.3.3 2.3.3.1 2.3.3.2 2.3.3.3 2.3.4 2.3.5 2.4 2.5 2.5.1 2.5.1.1 2.5.1.2 2.5.1.3 2.5.2 2.5.3 2.6

Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Management and Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Research Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working Groups and Implementation Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Management and Organization Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Withdrawal of SCK-CEN and KMSKB-MRBAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reduced Software Development Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organizational Change within the Partner Institutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Entity Types Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Search Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Closing Rules, Workflow, Retention & Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementation and testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CEGES-SOMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IRM-KMI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementation and testing issues: ULB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Research and Valorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication and Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication and Promotion Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Folder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Newsletter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication with and Promotion in the Partner Institutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . External Communication and Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication and Promotion Issues: Promotion Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 3 3 4 4 5 5 6 6 6 8 8 9 9 10 10 13 13 14 14 15 15 16 16 17 18 18 18 18 19 19 19 20 21

3 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.2

Conclusions and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . In what ways was the project a success? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What factors brought success? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What factors brought neither success nor failure? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What factors brought failure?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommendations to Federal Science Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22 22 22 22 23 24 25

4 4.1 4.1.1 4.1.2 4.2 4.2.1 4.2.2 4.2.2.1 4.2.2.2 4.2.3 4.2.3.1 4.2.3.2 4.2.4

Research Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functionalities Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Technical Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Knowledge Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Methodology for Organizational Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata Model and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Requirements Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Requirements Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Requirements Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General User Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 27 27 28 28 28 28 28 29 29 30 30

Table of Contents

4.2.4.1 4.2.4.2 4.2.5 4.2.5.1 4.2.5.2 4.2.5.3 4.2.5.4 4.2.5.5 4.2.6 4.2.6.1 4.2.6.2 4.2.7 4.2.8 4.2.9 4.2.10

User Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Technical Manual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supplementary User Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CEGES-SOMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IRM-KMI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . KMSKB-MRBAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ULB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Master Test Plan and Test Unit Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Master Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test Unit Description and Test Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliography (organizational sociology, records management) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standards inventory (records/archives management, IT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . URL inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

Application Support Arrangements (After Project) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Annexe A DISSCO Folder Annexe B DISSCO Newsletter Annexe C Workshop for Partner Institutions Annexe D Promotion Event Annexe E Questionnaire for Priority Analysis Annexe F Questionnaire for Organizational Analysis Annexe G DISSCO Metadata Model Annexe H Metadata Mapping Annexe I Software Requirements Document Annexe J Software Requirements Database (Access database) Annexe K User Manual Annexe L User Documentation CEGES-SOMA Annexe M User Documentation IRM-KMI Annexe N User Documentation KMSKB-MRBAB (obsolete) Annexe O User Documentation ULB (obsolete) Annexe P User Documentation VUB Annexe Q Master Test Plan Annexe R Test Unit Description and Test Forms Annexe S Bibliography (Access database) Annexe T URL inventory Annexe U Publications Annexe V Meeting Reports

30 30 30 30 31 31 32 32 32 32 33 33 34 35 35

DISSCO - Document management: Integrated System for Scientific Organisations

1 Introduction

Het DISSCO-project (Document management: Integrated System for Scientific Organisations) startte op 1 december 2001, na ruim een jaar voorbereiding. Het was een samenwerkingsverband tussen twee onderzoeksgroepen die apart en zonder het van elkaar te weten een gelijkaardig projectvoorstel hadden ingediend om een recordsmanagementapplicatie te ontwikkelen. De ene onderzoeksgroep was een samenwerkingsverband tussen IRM-KMI en de Facultés Universitaires Notre-Dame de la Paix van Namen. De andere bestond uit CEN-SCK, CEGES-SOMA, KMSKB-MRBAB, ULB en VUB. Op aandringen van het Federaal Wetenschapsbeleid zijn beide projectvoorstellen geïntegreerd en is er tussen alle partijen een samenwerkingsverband gesloten. Dat samenwerkingsverband legt nu zijn eindrapport voor. Het doel van het project was: •

een methodologie voor de analyse van administratieve basisprocessen in wetenschappelijke instellingen te ontwikkelen

•

een breed toepasbare softwareapplicatie (bij voorkeur open source) te ontwikkelen ter ondersteuning van het geautomatiseerd beheer van administratieve basisprocessen (hoewel het beheer van het 'papieren' archief niet werd vergeten)

•

voor elk van de applicatiepartners (CEN-SCK, CEGES-SOMA, IRM-KMI, KMSKB-MRBAB, ULB en VUB) een applicatie te ontwikkelen voor een door hen aangeduid prioritair administratief proces

Alle doelstellingen zijn uitgevoerd, met enkele belangrijke wijzigingen voor de applicatiesoftware. Het project werd halverwege geëvalueerd door een comité van externe buitenlandse specialisten, die wij hier bedanken voor hun kritische en zinvolle opmerkingen. Zij hebben het project zeker verrijkt. Hun conclusie was dat het een goed project was, maar dat er (ook na de beslissing van CEN-SCK om uit het project te stappen) moest worden gesnoeid in het aantal partners of het aantal applicaties. Het comité zag een breed basissysteem voor het beheer van de recordsmanagementfunctionaliteiten met daarop één (of hoogstens twee) applicatie(s), afgestemd op het profiel van de applicatie-instelling, als ideaal. Snoeien in de partners of de applicaties was halverwege het project echter geen haalbare bestuursoptie, omdat ze als unfair werd aangevoeld naar de partners toe. KMSKB-MRBAB heeft echter bij de onderhandelingen van het tweede contract laten weten niet verder te gaan met het project, terwijl de ontwikkeling van de applicatie voor de ULB vertraging heeft opgelopen door institutionele wijzigingen in de ULB enerzijds en door vertrekkend personeel van het DISSCOproject anderzijds. Het resultaat van de softwareontwikkeling, de kern en drie applicaties, is nog altijd ruimer dan wat het internationaal comité als ideaal zag. Bovendien heeft IRM-KMI zijn prioritair proces laten vallen en DISSCO algemeen in zijn beheer geïmplementeerd, waardoor zijn applicatie heel wat ruimer is dan wat de doelstellingen voorzagen. Dat had als voordeel dat kon worden getest en aangetoond dat de kern enorme toepassingsmogelijkheden heeft die veel verder gaan dan de enkele gebouwde applicaties. De ULB krijgt de mogelijkheid om de applicatie van de VUB te implementeren, waardoor ze ook een praktisch resultaat van haar inspanningen heeft. 1


De waarde van het project ligt ook in de breedte waarmee DISSCO kan worden toegepast. Uiteindelijk hoeft DISSCO niet beperkt te blijven tot wetenschappelijke instellingen, maar zijn zowel de methodologie als de software van de kern (en mogelijk ook van de applicaties) bruikbaar voor en toepasbaar in om het even welke publieke instelling. De Belgische publieke instellingen kunnen dan ook optimaal van DISSCO profiteren, zodat het project een veel grotere reikwijdte heeft gekregen dan oorspronkelijk was voorzien. Met recht en reden kan worden gezegd dat het project de doelstellingen van het meerjarig programma ter ondersteuning van de informatiemaatschappij met brio heeft gehaald. Ook moet hier de waarde van DISSCO in een internationaal perspectief worden bekeken. Opensourcesoftware voor recordsmanagementapplicaties is (ook internationaal gezien) nagenoeg onbestaande. Er bestaan meerdere opensourceapplicaties voor document management, maar de term 'document management' kan veel ladingen dekken. Vaak gaat het om heel beperkte toepassingen, die slechts één of enkele functionaliteiten van document management ondersteunen. Opensourcetoepassingen voor records management zijn nog uitzonderlijker. Alfresco RM lijkt voorlopig de enige te zijn. Bovendien richt die applicatie zich op het bedrijfsleven, terwijl DISSCO zich op de openbare sector richt. De publiciteit van Alfresco RM zegt niet in welke mate standaarden in het systeem zijn verwerkt. Bij DISSCO vormden internationale normen, standaarden en aanbevelingen (ISO 15489, MoReq, enz.) de leidraad voor de opbouw van het systeem. DISSCO vormt daardoor voorlopig nog een unicum. Op het moment dat dit eindrapport wordt ingediend, loopt een aanvraag om het project nog zes maanden te verlengen. Dat heeft alles te maken met het vroegtijdige vertrek van informaticus D. Honoré, die in de maand juli het project inruilde voor een vaste betrekking. Daardoor zijn de blijvende medewerkers zwaarder belast en heeft de softwareontwikkeling vertraging opgelopen. Een sneeuwbaleffect was onvermijdelijk: vertraging in de verbetering van de applicaties op basis van de opmerkingen van de sleutelgebruikers, vertraging van de promotie en beperkte mogelijkheden om in geïnteresseerde instellingen presentaties te geven. De laatste projectverlenging moet dan ook dienen om: •

de laatste verbeteringen aan de applicatiesoftware aan te brengen

•

de implementatie van de VUB-applicatie in de ULB mogelijk te maken, indien daar behoefte aan is

•

de gebruikers samen te brengen in één of meerdere gebruikersgroepen

•

een studiedag/workshop te organiseren waarop de resultaten bekend worden gemaakt

•

verder te speuren naar de mogelijkheden afterprojectstructuren op te zetten.

om

een

valoriseringsproject

en

verdere

Tenslotte wens ik de werkende leden van de stuurgroep en het onderzoeksteam van het DISSCOproject te bedanken. De meest trouwe medewerkers van het onderzoeksteam, Anthony Jonckheere en Stephanie Waeyenbergh, verdienen een eervolle vermelding voor hun niet aflatende inspanningen. Van de stuurgroep verdient vooral de vice-coördinator, de heer Buu Huynh, extra bloemetjes omdat hij de tweede fase van het project, de softwareontwikkeling, gecoördineerd heeft. Het DISSCO-team hoopt dat vele instellingen voordeel zullen kunnen halen uit de realisaties van het project. Het team meent daarmee een wezenlijke bijdrage aan de nationale en internationale toekomst van de informatiesamenleving te hebben geleverd.

2


2 Review

2.1 Project Management and Organisation 2.1.1 General L’organigramme du projet est montré dans la figure suivante.

Figure 1. Diagramme organisationnelle

2.1.2 Project Management Het projectmanagement bestaat uit: •

de Stuurgroep

•

het Opvolgingscomité

•

de projectcoördinator en de vice-coördinator

De taken en de samenstelling van die organen zijn in beide projectcontracten bepaald.

3


In Fase 1 kwam de Stuurgroep (7 partners) vooral in het begin van het project frequent bijeen, om uiteindelijk op een ritme van ten minste één vergadering elke twee maanden te vallen. Tijdens de evaluatiefase werd er meer vergaderd. In Fase 2 bleven er nog vier partners over, alle zowel onderzoeks- als applicatie-instellingen. Daardoor werd de informele communicatie tussen de vier onderzoeksdirecteurs, die tegelijkertijd als vertegenwoordiger van hun instelling optraden, belangrijker. Het aantal stuurgroepvergaderingen nam bijgevolg af, want de onderzoeksdirecteurs wilden de last van de vergaderingen in het algemeen beperken. In Fase 1 werd halfjaarlijks met de externe experten van het Opvolgingscomité vergaderd. In Fase 2 is het Opvolgingscomité met experten van de FUNDP, onderzoekspartner in Fase 1, uitgebreid. Tijdens de evaluatieronde van Fase 1 vond er een intensiever informeel overleg met de externe experten plaats, die een cruciale rol in de voortzetting van het project speelden. Omwille van hun waardevolle bijdrage is er dan beslist om in Fase 2 een intranet en een discussielijst op te zetten om de communicatie tussen het onderzoeksteam en de externe experten te stimuleren. De externe experten bleken tijdens de verdere afwikkeling van het project echter weinig behoefte te hebben aan een discussielijst, mede omdat hun werklast hoog was. Zij vroegen wel om meer in functie van de resultaten te vergaderen. Bijgevolg bestond het overleg met de externe experten enerzijds uit informele communicatie met de onderzoekers, anderzijds uit de halfjaarlijkse vergaderingen, waarop de vooruitgang van het project werd getoond. De externe experten werden op de hoogte gehouden via de rapporten die aan het Federaal Wetenschapsbeleid moesten worden voorgelegd en die vooraf door het Opvolgingscomité moesten worden goedgekeurd, alsook via de nieuwsbrief en de website (zie sectie 2.5.1). De projectcoördinator en de vice-coördinator verdeelden het werk volgens hun specialisme. In Fase 1 vervulde de eerste de belangrijkste coördinerende rol via de werkgroep 'Analyse en onderzoek', terwijl in Fase 2 de vice-coördinator de belangrijkste coördinerende rol vervulde met de softwareontwikkeling. De coördinator zorgde in samenwerking met de Stuurgroep voor de oplossing van de administratieve problemen in het project. 2.1.3 Research Groups In Fase 1 werd het onderzoek en de softwareontwikkeling door twee onderzoeksgroepen uitgevoerd. De groep 'Analyse en onderzoek' was verantwoordelijk voor het voorbereidend onderzoek, de uitwerking van een analysemethodologie en de uitvoering van de prioriteiten- en de organisatieanalyse. De groep 'Softwareontwikkeling' was verantwoordelijk voor de ontwikkeling van de applicatie. Beide onderzoeksgroepen voerden elk in hun domein theoretisch onderzoek uit. Dat gebeurde gedeeltelijk apart en gedeeltelijk samen. De verwerking van de onderzoeksresultaten gebeurde in nauwe samenwerking. Bij de start van Fase 2, toen het voorbereidend onderzoek en de analyses waren afgerond, werden de twee groepen samengevoegd met als doel de applicatie te ontwikkelen en ze in de partnerinstellingen te implementeren. De samenvoeging heeft geleid tot een verbetering van de communicatie en de informatie-uitwisseling tussen de onderzoekers, die in verschillende instellingen tewerkgesteld zijn, onder andere door de organisatie van wekelijkse werkvergaderingen. Het zwaartepunt kwam daardoor uiteraard op ontwikkeling en implementatie te liggen. 2.1.4 Working Groups and Implementation Teams In Fase 1 werd de communicatie met de partnerinstellingen verzekerd door de werkgroepen, die in elk van de partnerinstellingen waren opgericht. In de werkgroepen waren de verschillende belangengroepen in de instellingen vertegenwoordigd: het hogere management (indien mogelijk), de ICT-afdeling, de archiefdienst en andere betrokkenen bij het proces. De werkgroepen stelden de prioriteiten voor de applicatie-instellingen voor, keurden de analyserapporten, de voorstellen voor 4


verbetering van het proces en het lastenboek goed en brachten verslag uit in de instellingen. Bij de oprichting van de implementatieteams in Fase 2 werd hun rol beperkt tot het opvolgen van de beslissingen van het hogere management. In de praktijk zijn zij niet meer samengekomen. Bij de start van Fase 2 werd in elke instelling naast de werkgroep een implementatieteam opgericht. De implementatieteams zijn verantwoordelijk voor de implementatie van de DISSCO-applicatie, de communicatie, de promotie, het overleg, de samenwerking en de kennisoverdracht van het project naar de instelling. De implementatieteams bestaan uit rechtstreekse betrokkenen bij het proces en de procesautomatisering: ICT-verantwoordelijke(n), verantwoordelijke(n) voor het archiefbeheer, de verantwoordelijke(n) voor het proces en andere toekomstige gebruikers van de DISSCO-applicatie, naast de vertegenwoordiger van de instelling in de Stuurgroep. Sommige leden maakten in Fase 1 al deel uit van de werkgroep. Het ontbreken van vertegenwoordiging van het hogere management in de implementatieteams is een probleem gebleken bij de directiewissel in het SOMA. Het implementatieteam, dat onder de vorige directie is opgericht, is ondanks zijn kennis van zaken, door de nieuwe directie niet gemachtigd om implementatiebeslissingen te nemen. Het gevolg daarvan is dat de implementatie van de DISSCOapplicatie in het SOMA onzeker is. Dat wordt verder besproken in het hoofdstuk over de implementatie en de testen in het SOMA (zie sectie 2.3.2). Vertegenwoordiging van het hogere management had het implementatieteam misschien meer autoriteit kunnen verlenen. 2.1.5 Project Management and Organization Issues 2.1.5.1 Withdrawal of SCK-CEN and KMSKB-MRBAB

Het project is gestart met zeven deelnemende instellingen (CEGES-SOMA, CEN-SCK, FUNDP, IRMKMI, KMSKB-MRBAB, ULB en VUB) en één instelling om de administratie van het project te ondersteunen (InfoPOLE): •

de FUNDP waren uitsluitend als onderzoeksinstelling en in Fase 1 bij het project betrokken

•

CEGES-SOMA, IRM-KMI, ULB en VUB fungeerden als onderzoeks- en als applicatie-instellingen

•

CEN-SCK, en KMSKB-MRBAB waren uitsluitend als applicatie-instellingen bij het project betrokken

CEN-SCK en KMSKB-MRBAB hebben zich respectievelijk kort vóór en kort na Fase 1 uit het project teruggetrokken. De redenen voor de terugtrekking van het SCK zijn in het Assessment Report en het Extended Report uiteengezet. Samengevat zijn ze de volgende: •

ten eerste besparingen bij het SCK, waarbij de knowledgemanagementapplicatie voor de directie prioritair was

implementatie

van

een

•

ten tweede bleek tijdens het voorbereidend onderzoek dat het prioritaire proces van het SCK van een heel andere aard was dan de administratieve basisprocessen waarop DISSCO zich richtte, en archiefstukken van een heel andere aard genereerde. Het vroeg een specifiek onderzoek, dat de planning zou hebben beïnvloed en de werkzaamheden zou hebben gehinderd ten koste van de andere partners.

De redenen voor de terugtrekking van de KMSKB, besproken in het Extended Report, zijn de volgende: •

het ICT-beleid van de KMSKB lag al vóór de start van DISSCO vast

•

de KMSKB kampten met een gebrek aan ICT-personeel 5


•

een lange afwezigheid van het hogere management (machtsvacuüm) had vertragingen in Fase 1 tot gevolg

De impact van het verlies van het SCK en de KMSKB is beperkt gebleven. Het globale resultaat van het project is niet in gevaar gekomen, noch heeft de ontwikkeling van de andere modules geleden onder de afwezigheid van die voor het SCK en de KMSKB. Hoewel er gevreesd werd dat het door de terugtrekking van beide instellingen moeilijker zou worden om te beoordelen of de DISSCO-applicatie al dan niet in andere, onbekende instellingen zou kunnen worden toegepast, is die vrees onterecht gebleken. 2.1.5.2 Reduced Software Development Team

Selon le budget, le projet DISSCO pouvait compter sur un effectif de 4 personnes à temps plein. À la première phase, cet effectif est formé de 2 chercheurs et de 2 informaticiens. À la deuxième phase, il était prévu que l’effectif serait d’un chercheur et de 3 informaticiens. Le quota de 3 informaticiens n’a jamais été atteint en raison de la non-disponibilité sur le marché du travail d’informaticiens répondants au profil recherché. Il est à noter que le profil recherché est assez particulier: jeune informaticien sans expérience professionnelle tout en étant un hardcore développeur en Java. Étant donné que le budget ne permet pas d’engager un informaticien expérimenté, les jeunes diplômés en informatique sont donc favorisés. Mais la plupart des jeunes informaticiens du niveau universitaire ne sont pas des hardcores développeurs. On entend par hardcores développeurs les informaticiens qui se sont perfectionnés eux-mêmes dans travail du développement de logiciel, en langage Java ou autres, grâce aux projets personnels ou collectifs. L’effectif en informaticiens pour la deuxième phase est un effectif réduit (2 informaticiens au lieu de 3). Mais l’économie ainsi obtenue a permis de prolonger le projet d’un an. 2.1.5.3 Organizational Change within the Partner Institutions

De verlenging van het project van vier tot vijf jaar heeft het project kwetsbaar gemaakt voor organisatiewijzigingen in de applicatie-instellingen: •

de reorganisatie van de afdeling waarmee in de ULB werd samengewerkt, heeft vertraging tot gevolg gehad

•

in het SOMA heeft door een directiewijziging de onvoorwaardelijke steun voor de applicatie plaats gemaakt voor een voorwaardelijke steun

•

het prioritaire proces van de VUB is licht gewijzigd, maar dat heeft geen gevolgen voor DISSCO gehad. De testen en de implementatie hebben echter wel vertraging opgelopen doordat de ICTafdeling van de VUB te veel werklast had om DISSCO te ondersteunen.

•

in het KMI heeft een beleid van versnelde automatisering een snelle toepassing van DISSCO mogelijk gemaakt.

2.2 Development Cette section présente le résultat final du travail de l'équipe de développement durant l'ensemble de la deuxième phase du projet en ce qui concerne le développement de la solution DISSCO. Ce travail couvre la conception logicielle et le codage de la solution. Cette section ne couvre pas le détail des tâches effectuées durant la deuxième phase du projet, pour de plus amples informations, se référer aux rapports intermédiaires et lettres d'information publiées durant la période mentionnée.

6


La solution DISSCO à été développée en Java (compatible 1.4 et 5), sur le modèle d'une architecture 3 tiers. L'architecture choisie respecte celle qui avait été détaillée dans le rapport final de la première phase du projet. La couche data (stockage) propose une indépendance vis-à-vis de la base de donnée utilisée. La couche business (application serveur) se compose de la solution Slide du Jakarta Project au-dessus de laquelle à été développé le core system de la solution DISSCO. Ce core system prend en charge l'ensemble des fonctionnalités d'archivage. La couche client se compose d'une application web utilisant les technologies Java Server Pages et Struts du Jakarta project. DISSCO est délivré avec un ensemble de tags et d'actions pour le développement d'interfaces web personnalisés aux besoins des diverses institutions. Parallèlement au core system, des modules additionnels qui viennent se greffer sur celui-ci ont été développés. Ces modules prennent en charge les fonctionnalités spécifiques d'archivage des emails, de l'envoi d'information du system vers les utilisateurs via email, de la capture automatique de métadonnées pour les types de documents les plus courants dans la bureautique actuelle, de l'indexation des propriétés et du contenu des documents ainsi que les possibilités de recherche, d'exportation et importation de données (format propriétaire uniquement), et la définition de scripts pour la définition des règles de clôture. La méthodologie utilisée lors du développement de la solution est très largement inspirée des méthodes de l'X-treme programming, principalement en ce qui concerne les tests et le développement itératif. La solution DISSCO contient un nombre important de tests qui couvrent l'ensemble des fonctionnalités et du code du système. Ces tests ont pour but d'illustrer le fonctionnement et le comportement du système au niveau du code et de permettre le développement itératif par la validation du bon fonctionnement du système à la suite de changements. Le code source du projet (voir CD-Rom en annexe) s'organise comme un ensemble de sous-projets qui héritent du projet principal Dissco, chacun de ces sous-projets représente une librairie java. L'ensemble de ces sous-projets sont : Dissco_core, Dissco_script, Dissco_slide, Dissco_importExport, Dissco_mailserver, Dissco_plugins_metadataHarvester, Dissco_search, Dissco_tagLib, Dissco_webapp. L'organisation de ces sous-projets est basée sur le framework Maven (version 1.0.x) et est comme suit : Table 1: Organisation des sous-projets /bin

Répertoire de compilation de l'IDE

/src

Contient l'ensemble des fichiers sources /java

Contient l'ensemble des sources des classes java du sous-projet

/test

Contient l'ensemble des JUnit tests relatifs aux classes java du sous-projet

/rsc

Contient l'ensemble des ressources qui ne sont pas des fichiers java /jar

Contient l'ensemble des ressources qui ne sont pas des fichiers java et qui doivent être ajoutées à la librairie liée au sous-projet

/test

Contient l'ensemble des ressources qui ne sont pas des fichiers java et qui sont nécessaire au fonctionnement des tests du sous-projet

/target

Répertoire de compilation de Maven

/xcods *

Contient l'ensemble des documentations inhérentes au sous-projet ./

Contient l'ensemble des documentations au format xdoc inhérentes au sous-projet

7


Table 1: Organisation des sous-projets /docs

Contient l'ensemble des documentations inhérentes au sous-projet et de leurs ressources qui ne sont pas sous le format xdoc.

/project.xml *

Fichier de description du sous-projet

/project.properties *

Fichier de définition des propriétés du sous-projet.

/maven.xml*

Fichier de définition des scripts (tests, déploiements…) du projet ou sous-projet.

/build.properties.sample *

Fichier de définition des propriétés personnalisables du projet ou sous-projet. Doit être renommé en build.properties.

* relatif au framework Maven 1.0.x (voir http://maven.apache.org) Les projets suivants ont également été développés durant la deuxième phase du projet : •

Dissco_public_site : contient les sources du site internet public de DISSCO (http://www.meteo.be/ DISSCO)

•

dissco-missing-test-plugin : plug in maven qui permet de vérifier que chaque méthode publique d'une classe possède un test associé.

•

maven-reqs-plugin : permet d'établir un report sur la réalisation des exigences du cahier des charges.

2.2.1 Application Cette section présente une introduction aux fonctionnalités de la solution DISSCO. De plus amples informations sur ces fonctionnalités et le paramétrage de celles-ci sont disponibles dans la documentation des sous-projets de DISSCO (voir source sur CD-ROM répertoire /docs) et dans le SRD. Description des principales fonctionnalités du système par thèmes: 2.2.1.1 System Entity Types Definition

Les types d'entité représentent des descriptions qui définissent la nature (ou type) des éléments présents dans le système. La gestion d'entités de nature différente permet à la solution DISSCO de : •

Gérer les niveaux d'agrégation : permet la conformité aux standards (ISO 15489, MoReq, ISAD(G)) ou au besoins "business", par l'association de chaque entité à un niveau d'agrégation (MoReq: class, file, volume, record). Chaque niveau d'agrégation peut être une spécialisation d'un autre niveau d'agrégation afin d'hériter des définitions de ce dernier.

•

Gérer les relations structurelles des entités : permet la conformité aux standards (ISO 15489, MoReq, ISAD(G)) ou aux besoins "business", par la définition de contraintes qui régissent les relations de type parent-enfant au sein d'un fonds d'archive (Moreq: un file est une sous-entité d'une class).

•

Gérer les descriptions : permet la conformité aux standards (ISO 15489, MoReq, ISAD(G)) ou aux besoins "business", par la définition des ensembles de propriétés qui sont requises et optionnelles pour chaque entité d'un même niveau d'agrégation.

•

Gérer les périodes de rétention : permet la conformité aux standards (ISO 15489, MoReq, ISAD(G)) ou aux besoins "business", par la planification de la rétention des entités du système.

8


•

Gérer la validation des données : par la validation des descriptions des entités, la validation des règles structurelles et la possibilité de définir des règles de validité pour un niveau d'agrégation (ex. un ProjectFile devrait contenir un agenda et deux rapports).

•

Automatiser les processus : par l'interfaçage de DISSCO avec le moteur de workflow Shark de Enhydra.

•

Personnaliser le rendu des entités : par la définition de modules de visualisation propres aux ensembles d'entités qui ont un même niveau d'agrégation.

2.2.1.2 Metadata

Chaque entité doit être décrite sur base de métadonnées obligatoires et optionnelles précisées dans la définition de son niveau d'agrégation. Ses métadonnées sont, pour une part importante, capturées automatiquement. Principales fonctionnalités : •

Définition et documentation de la nature des métadonnées reconnues par le système.

•

Possibilité de définir plusieurs ensembles de définitions de metadonnées et d'effectuer des correspondances entre des métadonnées issues d'ensembles de définitions différents (DISSCO/ MoReq/ISAD(G)/Dublin Core/Microsoft Office …). L'une des applications de cette fonctionnalité est de lier les propriétés extraites d'un document issu d'une suite bureautique (ou des autres formats pouvant être analysés par le système) avec les métadonnées définies par MoReq et ainsi automatiser la mise à jour des métadonnées obligatoires et optionnelles pour les entités du fonds d'archive.

•

Extraction des informations utiles contenues dans les documents soumis ou dans les transactions de soumission de ces documents dans le système. L'extraction des propriétés contenues dans les documents est valable pour les documents suivants : •

Microsoft Office Suite : .doc, .xsl, .ppt

•

Open Office Suite : .swx

•

RTF : .rtf

•

Adobe PDF : .pdf

•

XML Editor : .html, .htm et tout contenu xml

•

MIME (email format)

•

DISSCO définit un framework afin de permettre le développement futur pour le support d'autres formats.

•

Visualisation des métadonnées dans différentes nomenclatures (Business defined, MoReq, ISAD(G), ….)

2.2.1.3 Search Engine

Deux types de moteur de recherche sont disponibles par défaut. Un moteur simple qui permet d'effectuer une recherche dans l'ensemble des contenus et descriptions sous un niveau précis et un moteur complexe qui permet d'effectuer une combinaison de recherches sur une ou plusieurs métadonnées sous un niveau précis.

9


Ces deux moteurs de recherche sont basés sur le moteur d'indexation Lucene du Jakarta Project intégré à la solution DISSCO, ce moteur d'indexation peut être paramétré afin d'indexer tout ou une partie des contenus (full text) et ou des descriptions pour tout ou une partie des fonds d'archive. 2.2.1.4 Closing Rules, Workflow, Retention & Scheduler

La solution DISSCO permet de gérer et de définir des règles de clôture des entités par la définition de scripts de validation. La clôture d'une entité est l'action combinée de la validation et la mise sous lecture seule de cette entité et des ses sous-entités. La solution DISSCO permet de gérer et de définir des règles de rétention d'une entité et de ses sousentités. Une règle de rétention détermine la durée durant laquelle une entité et ses sous-entités doivent être conservées. Ces règles de rétention sont définies par une période, la propriété indiquant la date de début de cette période et de la raison de la conservation. La solution DISSCO peut-être interfacée avec le moteur de workflow Shark du projet Enhydra. Cet interfaçage est actuellement en production à l'Institut royal de météorologie. 2.2.1.5 Graphical User Interface

La solution DISSCO est livrée avec une interface générique inspirée graphiquement par l'explorateur de Microsoft Windows. Cette interface permet une compréhension facile et intuitive de l'application et d'effectuer la quasi-totalité des fonctionnalités de la solution DISSCO. La visualisation des entités est entièrement paramétrable par l'assignation de viewers spécifiques pour chaque niveau d'agrégation. La solution DISSCO est également livrée avec un ensemble de tags permettant le développement rapide de nouvelles interfaces graphiques ou de l'intégration des fonctionnalités de la solution DISSCO dans un site web existant.

10


Figure 2. Interface principale de DISSCO

11


Figure 3. Interface Metadata

12


Figure 4. Intégration de DISSCO dans le système de gestion des fichiers par le biais de web-folders.

2.3 Implementation and testing 2.3.1 General Organisatie van de implementatie en de testen Om de implementatie en de testen in de applicatie-instellingen in goede banen te leiden, is er in elke instelling een implementatieteam opgericht en zijn er sleutelgebruikers aangeduid. De implementatieteams zijn eerder in deze tekst besproken (zie sectie 2.1.4). De sleutelgebruikers (indien mogelijk minstens twee personen per instelling, onder wie een informaticus) worden ingeschakeld in de testen van de softwareapplicatie, de opleiding van de eindgebruikers en de ondersteuning van de eindgebruikers. De sleutelgebruikers blijken een grote invloed te hebben op de perceptie en de acceptatie van de applicatie in de instelling, in het bijzonder bij de toekomstige gebruikers. Er kan uit worden geconcludeerd dat het belangrijk is om de sleutelgebruikers zorgvuldig te kiezen. De testen worden volgens een globaal testplan uitgevoerd. Er staat een testhandleiding ter beschikking van de testers, die ze ook kunnen gebruiken om de testresultaten vast te leggen. Beide documenten worden uitvoeriger besproken bij de onderzoeksresultaten van DISSCO (zie sectie 4.2.6). De implementatie en de testen in het KMI zijn anders verlopen dan in de andere instellingen. Dat wordt verder in dit rapport besproken (zie sectie 2.3.3).

13


2.3.2 CEGES-SOMA Testen •

Het prototype gamma werd in juni 2006 geïnstalleerd.

•

Zowel het nieuwe ordeningsplan als de applicatie en de grafische gebruikersinterface, die in samenwerking met implementatieteam van het SOMA ontworpen is, werden getest.

•

Vóór het prototype gamma, is ook het prototype beta door eindgebruikers getest.

•

In november startte een nieuwe testfase. De testen werden geïntensifieerd met als doel de efficiëntie van de applicatie te testen: er wert met een groter aantal documenten en simultane gebruikers getest. De oorspronkelijke groep testers, bestaande uit de ICT-verantwoordelijke en twee sleutelgebruikers, werd uitgebreid tot zes personen.

Rollout •

Het nieuwe ordeningsplan wordt vanaf januari 2007 in gebruik genomen.

•

Op het moment van schrijven heeft de directie nog niet beslist of de DISSCO-applicatie al dan niet in gebruik zal worden genomen. Afhankelijk van die beslissing zal in december in samenwerking met het implementatieteam een voorstel voor de rollout van de DISSCO-applicatie worden uitgewerkt of zullen alternatieven worden voorgesteld. Als de applicatie niet in gebruik wordt genomen, vallen de noodzakelijke bijkomende zoekfunctionalteiten die de DISSCO-applicatie bovenop het ordeningsplan aanbiedt, namelijk weg. Bovendien moet het ordeningsplan dan in een papieren omgeving worden geïmplementeerd.

Specifieke gebruikersdocumentatie In samenwerking met het implementatieteam van het SOMA is de volgende gebruikersdocumentatie opgesteld: •

een functieclassificatieschema

•

een ordeningsplan

•

een voorstel voor een beleid met betrekking tot de behandeling en het beheer van de briefwisseling

•

een voorstel voor de bepaling van de verplichte en de optionele metadatasets

•

een gebruiksaanwijzing voor het ordeningsplan

•

een gebruiksaanwijzing voor de opname van e-mail in DISSCO

•

een gebruiksaanwijzing voor de creatie van nieuwe entiteiten in DISSCO

De documentatie is in bijlage aan dit rapport toegevoegd (zie bijlage L). 2.3.3 IRM-KMI L’IRM a choisi d’intégrer DISSCO dans son système d’information de façon progressive. Ce choix a été dicté par 3 facteurs: 1) L’effectif réduit en personnel TIC (Technologie de l’Information et de la Communication); 2) L’approche non-intrusive quant à l’introduction de nouvelles technologies; 14


3) La maturité de la solution DISSCO. Avec son effectif réduit en informaticiens TIC, l’IRM ne pouvait se permettre de déployer une nouvelle solution technologique de façon massive et complète. On estime qu’il faudrait de 2 à 3 informaticiens à temps plein, sur une période minimum d’un an, pour implémenter DISSCO à travers tout l’Institut et le rendre à 100% opérationnel. Cela comprend les activités de formation et de support aux utilisateurs, la révision et conception de plusieurs plans de classements, l’inventaire et la migration des documents électroniques, la gestion et du débuggage du système, etc. Si l’implémentation de façon massive et complète d’une nouvelle solution technologique a ses avantages telles que l’effet d’entraînement, la réduction des états intermédiaires et un meilleur support du Management (le Management préfère avoir tout et le plus rapidement possible), elle a aussi un grand désavantage: une forte intrusion susceptible de modifier la manière dont les gens travaillent. Comme il n’existe pas à l’IRM une seule manière de travailler en ce qui concerne la gestion des documents électroniques ou non-électroniques, une forte intrusion risque de causer de fortes perturbations. Une implémentation ciblée (groupes cibles suivant un calendrier adapté) a été préférée. Étant donné le degré de maturité de la solution de DISSCO, il est plus prudent pour l’IRM d’implémenter cette dernière module par module, après qu’un travail d’analyse et de compréhension soit complété. 2.3.3.1 Planification

Il n’y a pas de plan d’implémentation spécifique à la solution DISSCO. Ce dernier fait partie du plan de développement du système d’information qui comprend en outre: l’intranet, le content management system, le workflow, le wiki, le forum, etc. Le développement du système d’information de l’IRM est fait de façon itérative, comprenant d’un part l’upgrade des technologies existantes et d’autre part, l’ajout de nouvelles fonctionnalités provenant de différentes solutions - différents systèmes. La planification de la mise à niveau du système d’information tient compte du calendrier du développement des versions Alpha et Beta de DISSCO. Elle assure que la mise à niveau résulte à un niveau de support (hardware, serveur) adéquate pour le bon fonctionnement de DISSCO. 2.3.3.2 Résultat

•

Le noyau de DISSCO (Slide) est utilisé en opérationnel et sert à gérer les documents ainsi que les contenus de l’Intranet de l’IRM. La gestion des documents ainsi que les contenus se fait par WEBDAV et par le web-folder.

•

À ce jour, plus de 1000 documents sont pris en charge par le système dont 320 notes de services, 135 rapports de réunions de différents groupes du Management, 110 documents relatifs aux différents projets et environ 150 publications récentes. À ces chiffres s’ajoutent plus d’une centaines de records électroniques de nature technique tels que des graphiques et des cartes, des rapports et des status, des contenus en XML des différentes listes.

•

Les fonctions principales de DISSCO utilisées: ajout/retrait/modification des documents, capture automatique des metadata, gestion (simplifiée) des metadata, indexation et recherche, affichage et listing des documents. Les fonctions en cours d’implémentation: gestion des types d’entité, gestion de la période de rétention, gestion de plusieurs sets de metadata et du metadata mapping, rercherche complexe.

15


•

La partie workflow de DISSCO en est à sa deuxième évolution avec un nouveau moteur. Deux workflows sont déployés de façon opérationnelle avec chacun plusieurs dixaines d’utilisations au cours de la dernière année.

•

La création du plan de classement du secrétariat de la Direction est quasi complète avec l’accent mis sur les documents qui ont besoin d’être archivés. La création du plan de classement pour le Sevice du personnel est en cours de réalisation.

2.3.3.3 Observation

L’IRM croit que le succès de l’introduction d’une nouvelle technologie telle que DISSCO au sein d’une petite organisation (200-250 personnes) ne peut être atteint sans les 3 éléments suivants: •

Ressource humaine et temps;

•

Connaissances des domaines de gestion des records (électroniques et non-électroniques), archivage, technologie de l’information et gestion organisationnelle;

•

Stratégie adaptée;

•

Support du Management.

Il est impensable d’implémenter DISSCO au sein de l’IRM sans avoir au minimum un ou plusieurs informaticiens. L’effectif doit être dédié à 100% à cette tâche d’implémentation. Il sera difficile pour la personne devant implémenter DISSCO d’exécuter cette tâche à “temps partiel”, surtout si elle ne fait pas partie de l’équipe développeur originale de DISSCO. Avoir moins d’effectif nécessitera plus de temps et peut se traduire par une perte d’efficacité. Contrairement aux solutions commerciales, où on pourrait sous-traiter le travail d’implémentation grâce à des ressources financières, DISSCO ne le permet pas. Pour les informaticiens, il est difficile de prendre en main DISSCO sans avoir une bonne connaissance en technologie de l’information et, en particulier, en développement d’applications web et de language Java. Pour les gestionnaires des records et ceux qui doivent implémenter le(s) plan(s) de classement, une bonne connaissances en gestion des records et en archivage est primordiale. À l’IRM, il n’existe pas de gestionnaire des records, ni d’archiviste. L’informaticien responsable de DISSCO doit alors remplir ces rôles. L’efficacité de ces fonctions n’est plus optimale. La stratégie d’implémentation doit tenir compte des effectifs présents, des niveaux de connaissances et de l’état organisationnel. Une stratégie avec une approche lente et progressive a peut-être plus de chance de succès qu’avec une “en fanfare”. Une approche lente est même nécessaire dans le cas où l’organisation ne possède aucune méthodologie ou connaissance en gestion documentaire, parce ce qu’il s’agit alors d’introduire, non pas seulement un outil, mais aussi une façon de faire - façon d’organiser et probablement une certaine réorganisation Avec une stratégie en fanfare, on peut produire des résultats spectaculaires qui plaisent au Management. Optant pour une stratégie progressive demande un meilleur support et une meilleure compréhension de la part de ce dernier car le côté spectaculaire est absent. Cette absence ne signifie pas nécessairement manque de résultat. Le Management ne doit pas confondre “introduction de nouvelles technologies” avec “achat de nouveaux systèmes commerciaux”. Dans le cas d’un système commercial, en fonction de l’investissement financier, on peut s’attendre à des résultats spectaculaires dès le départ. 2.3.4 VUB Testen 16


•

Het prototype gamma werd in juni 2006 geïnstalleerd. Het is het eerste prototype dat door de eindgebruikers van het Secretariaat van de Raad werd getest.

•

De testen dienden vooral voor de configuratie van de applicatie en de implementatie van het actuele ordeningsplan van het Secretariaat van de Raad in DISSCO.

•

De groep testers, oorspronkelijk bestaande uit 1 sleutelgebruiker (een medewerker van het Secretariaat van de Raad), werd in november uitgebreid tot vijf medewerkers van het Secretariaat van de Raad.

Rollout Op 8 december 2006 heeft een vergadering van het implementatieteam over de ingebruikname van DISSCO in de VUB plaatsgevonden. Om de dienst Administratieve Informatieverwerking (AIV) in staat te stellen DISSCO te onderhouden, zal worden onderzocht of het niet kan worden opgenomen in het ERP-project door de VUB wordt opgestart. Op die manier is er geld beschikbaar om ofwel een voltijdse informaticus voor DISSCO aan te werven, ofwel, indien mogelijk, een onderhoudscontract voor DISSCO met de firma Dolmen af te sluiten. Op de vergadering zijn ook technische kwesties behandeld met het oog op een optimale werking van DISSCO in het Secretariaat van de Raad: het probleem van de werking van de webfolders in DISSCO, de configuratie van Office op de computers van het Secretariaat van de Raad, de relatie tussen DISSCO en de Filemaker-database in het Secretariaat van de Raad. Specifieke gebruikersdocumentatie In samenwerking met het implementatieteam van de VUB is de volgende gebruikersdocumentatie opgesteld: •

een voorstel voor de implementatie van het actuele ordeningsplan van het Secretariaat van de Raad in DISSCO, inclusief de bepaling van de verplichte en de optionele metadatasets

•

een gebruiksaanwijzing voor de creatie van nieuwe entiteiten in DISSCO

De documentatie is in bijlage aan dit rapport toegevoegd (zie bijlage P). 2.3.5 Implementation and testing issues: ULB Voor de specifieke module ter ondersteuning van de voorbereiding en de opvolging van de onderzoekscontracten voor de Cellule de Recherche van de ULB is het nodige voorbereidende onderzoek uitgevoerd: de analyses zijn uitgevoerd, het lastenboek is opgesteld en er hebben in 2005 verschillende vergaderingen van het implementatieteam plaatsgevonden (besproken in het tussentijds rapport van 30/06/2005). De module kan echter niet worden uitgewerkt en afgeleverd door verschillende factoren: •

de vertraging die DISSCO bij de ontwikkeling door personeelsproblemen heeft opgelopen (zie sectie 2.1.5.2)

•

de administratieve hervormingen in de ULB en in het bijzonder de Cellule de Recherche, die in de loop van dit jaar hebben plaatsgevonden. De resultaten van het voorbereidend onderzoek hebben daardoor gedeeltelijk hun waarde verloren.

•

het gebrek aan sleutelgebruikers en samenwerking met het Département Informatique in de ULB.

De projectverantwoordelijken en de ULB zijn daarom overeengekomen dat de ULB de module ter ondersteuning van het beheer van de beslissingen van de Raad van Bestuur van de VUB kan overnemen, indien daar behoefte aan is. 17


2.4 Research and Valorization Het onderzoek uitgevoerd in DISSCO had tot doel: •

een methodologie uit te werken om de noden van de gebruikers op het vlak van werkprocessen, archiefvorming en archiefbeheer te bepalen en om de vereisten voor de applicatie te bepalen;

•

de ontwikkelingen op het vlak van aanbevelingen, standaarden en normen in het archivistisch en ICT-onderzoeksgebied op te volgen en en toe te passen in DISSCO.

Het onderzoek wordt in detail behandeld in deel 4 (Research Results) van dit rapport. De onderzoeksresultaten zijn bekend gemaakt in de vorm van publicaties en presentaties. Ze zijn ook ten dienste van internationaal onderzoek gesteld. Voor de lijst van publicaties: zie sectie 4.2.10. Presentaties: •

Presentatie van de DISSCO-methodologie tijdens een postersessie op de " Onderzoeksdag" in de FUNDP.

•

Presentatie van de DISSCO-methodologie tijdens een workshop in de universiteit van Louvain-laNeuve (09/05/2003).

•

Presentatie van de DISSCO-methodologie tijdens Informatie 2003 (VVBAD, 18-19/09/2003).

•

Presentatie over de samenwerking met de gebruikersinstellingen bij de softwaretesten en de voorbereiding van de implementatie van de DISSCO-applicatie tijdens Informatie 2005 (VVBAD, 2223/09/2005).

•

College over aanbevelingen, standaarden en normen voor records management voor de studenten van de MA Archivistiek (18/03/2003, 09/12/2003 en 13/12/2004).

Deelname in internationaal onderzoek: •

Aanbevelingen voor de herziening van de MoReq-specificatie vanuit de ervaring van DISSCO met de toepassing van MoReq.

2.5 Communication and Promotion 2.5.1 Communication and Promotion Tools 2.5.1.1 Website

De DISSCO-website ging on line op 1 september 2004 (http://www.meteo.be/DISSCO/ ). Het doel van de website was een gedetailleerde voorstelling van het project en het DISSCO-systeem. De website bevat: •

algemene informatie over het project: doelstellingen, organisatiestructuur, onderzoeksteam, deelnemende instellingen

•

technische informatie over de DISSCO-software

•

publicaties van de onderzoekers 18


•

links naar websites die voor het DISSCO-onderzoek relevant zijn

•

een contactadres voor bijkomende informatie over het project en de softwareapplicatie

Doelgroepen: intern (partnerinstellingen) en extern (onderzoekers, potentiële cliënten, enz.) 2.5.1.2 Folder

De DISSCO-folder is beschikbaar sinds 2005. De folder geeft een beknopte beschrijving van het project en de applicatie, waarbij instellingen worden aangemoedigd om meer informatie te verzamelen via de website en/of het contactadres, aan te sluiten bij de gebruikersgroep van de DISSCO-applicatie en de applicatie te implementeren. De folder is vooral gebruikt voor verspreiding bij wetenschappelijke en commerciële presentaties. Doelgroepen: extern (onderzoekers, potentiële cliënten, enz.). De folder is in bijlage aan dit rapport toegevoegd (zie bijlage A). 2.5.1.3 Newsletter

In Fase 2 van het project is elke twee à drie maanden een nieuwsbrief naar de partnerinstellingen en de externe experten van het Opvolgingscomité gestuurd. De nieuwsbrief had een informatie- en promotiefunctie. Het doel van de nieuwsbrief was vooral het personeel van de partnerinstellingen op de hoogte te houden van het project en zo het project regelmatig onder de aandacht te brengen. De nieuwsbrief bevatte het laatste nieuws over het project en een overzicht van de voltooide, lopende en geplande ontwikkelingsactiviteiten. In totaal zijn er 10 nieuwsbrieven verstuurd (op het moment van schrijven moet de laatste nieuwsbrief nog worden verstuurd). Doelgroepen: intern (partnerinstellingen en externe experten van het Opvolgingscomité) De nieuwsbrieven zijn in bijlage aan dit rapport toegevoegd (zie bijlage B). 2.5.2 Communication with and Promotion in the Partner Institutions Communicatie met en promotie in de partnerinstellingen werd via de volgende kanalen geregeld: •

de werkgroepen, de implementatieteams en de sleutelgebruikers

•

occasionele, informele contacten tussen de onderzoekers en partnerinstellingen tijdens de analyse- en de implementatieactiviteiten

•

de nieuwsbrief

medewerkers

van

de

In Fase 1 was de communicatie vooral gericht op het overtuigen van het hoger management in de partnerinstellingen via de werkgroepen. Instellingen waar die werkgroepen niet sterk genoeg bleken om het project te promoten, werden door de coördinator en een aantal medewerkers extra bezocht. Zo heeft er een extra vergadering plaatsgevonden om de steun van het hoger management van het SCK-CEN te verkrijgen. Ook zijn er verschillende vergaderingen en presentaties georganiseerd om het bestuur van het KMSKB-MRBAB te overtuigen om het project in hun beleidslijnen op te nemen en te houden. Daarnaast is er bij de aanvang van Fase 2 een workshop voor de applicatie-instellingen georganiseerd. In de workshop werden de onderzoeksresultaten van Fase 1 voorgesteld en de geplande activiteiten

19


voor Fase 2, alsook de samenwerking daarvoor met de applicatie-instellingen, toegelicht. De documentatie van de workshop is in bijlage aan dit rapport toegevoegd (zie bijlage C). Tenslotte zijn er in de applicatie-instellingen presentaties van de DISSCO-applicatie voor de ICTverantwoordelijken en/of de eindgebruikers gegeven: •

CEGES-SOMA: 14 juni 2006, 10 november 2006

•

IRM-KMI: juni 2005 (DISSCO-project), april 2006 (workflow), november 2006 (intranet, workflow en DISSCO-applicatie), (gepland voor 2007: een promotie-evenement voor het operationeel gebruik van de DISSCO-applicatie)

•

ULB: 7 januari 2005 (voor de Cellule de Recherche en het Département Informatique)

•

ULB: Presentatie aan de Service du Greffe van de ULB op 16/02/2006

•

VUB: 15 maart 2006 en 6 november 2006 (voor het Secretariaat van de Raad), 17 mei 2006 (voor het AIV)

Vaststellingen: •

Het zou bevorderlijk voor de communicatie en de promotie in de applicatie-instellingen geweest zijn als er ook in Fase 1 een nieuwsbrief was verspreid.

•

De projectverantwoordelijken van de instellingen die betrokken waren bij het onderzoek hadden een grote invloed op de communicatie en de promotie in de instellingen.

•

Voor de promotie van de DISSCO-applicatie lijken de sleutelgebruikers en in mindere mate ook de implementatieteams belangrijker dan de nieuwsbrief. De sleutelgebruikers zijn pas een rol beginnen spelen toen ze de prototypes in de instellingen moesten testen. Doordat DISSCO vertraging in de softwareontwikkeling en de installatie van het prototype gamma in de instellingen (SOMA en VUB) heeft opgelopen, zijn de sleutelgebruikers soms pas laat bij het project betrokken. Er is namelijk voor gekozen om geen gebruik te maken van een grafische interface die in feite nog een 'lege doos' was, omdat men enerzijds de ontwikkeling van de basisfunctionaliteiten als prioritair beschouwde en anderzijds vreesde voor teleurstelling bij de sleutelgebruikers wanneer het prototype te veel gebreken zou vertonen. Achteraf kan men zich afvragen of een vroegere ontwikkeling van de interface van de applicatie (per instelling) en het zo snel mogelijk starten van de testen door de eindgebruikers de promotie niet ten goede zou zijn gekomen. Die vraag is onbeantwoordbaar, omdat het moeilijk is om de nadelen en de voordelen van beide situaties in te schatten. Momenteel zijn de sleutelgebruikers in het KMI, het SOMA en de VUB echter enthousiast, wat bewijst dat de genomen opties wel het juiste effect hebben geressorteerd.

•

Om dezelfde redenen is ook het aantal presentaties in de applicatie-instellingen beperkt gebleven. Het zou beter geweest zijn als de presentaties eerder hadden kunnen starten.

2.5.3 External Communication and Promotion Er is in DISSCO de voorkeur aan gegeven om met de externe promotie van de applicatie te wachten tot het gros van de functionaliteiten van de applicatie beschikbaar was. Door de vertraging in de softwareontwikkeling is de grafische gebruikersinterface echter pas laat ontwikkeld. Daardoor is de externe promotie zoals de interne promotie beperkt gebleven. Bovendien is de ondersteuning van de applicatie na het project op dit moment nog niet verzekerd, waardoor ze moeilijk verkoopbaar is. Er zijn drie nieuwsberichten over DISSCO in het maandelijkse berichtenblad van de Vlaamse Vereniging voor Bibliotheek-, Archief- en Documentatiewezen geplaatst:

20


•

Info 2004-6: verlenging van het project

•

Info 2004-10: nieuwe website van het project

•

Info 2007-1 (of 2007-2): einde van het project, update van de website, contactpersonen

Tenslotte zijn er externe presentaties van de DISSCO-methodologie en -applicatie gegeven: •

Presentatie van de DISSCO-methodologie tijdens een workshop in de universiteit van Louvain-laNeuve (09/05/2003).

•

Presentatie van de DISSCO-methodologie tijdens Informatie 2003 (VVBAD, 18-19/09/2003).

•

Presentatie van de applicatie aan de medewerkers van het stadsarchief van Shangai op 20/09/2005

•

Presentatie over de samenwerking met de gebruikersinstellingen bij de softwaretesten en de voorbereiding van de implementatie van de DISSCO-applicatie tijdens Informatie 2005 (VVBAD, 2223/09/2005).

•

Presentatie van de applicatie voor het Ministerie van Bestuurszaken van de Vlaamse Overheid op 12/09/2006

•

Presentatie van de applicatie voor de studenten van de MA Archivistiek op 19/04/2005 en 18/04/ 2006

•

Presentatie van de applicatie voor de Service informatique van de FUNDP (gepland)

•

Presentatie van de applicatie in de Erasmushogeschool Brussel (gepland)

2.6 Communication and Promotion Issues: Promotion Event Het promotie-evenement dat zou worden georganiseerd wanneer het prototype gamma getest en afgewerkt is, wordt in de eerste jaarhelft van 2007 georganiseerd. Omdat er nog wordt gewerkt aan de ondersteuning van de applicatie na 31 december, is het immers zinloos om te proberen de applicatie nu te commercialiseren. Bovendien is de aard van de ondersteuning bepalend voor de promotie die moet worden gevoerd. Er zijn echter al voorbereidingen getroffen opdat het evenement in de toekomst zou kunnen doorgaan: er zijn adressenlijsten en een programmaconcept beschikbaar (zie bijlage D).

21


3 Conclusions and Recommendations

3.1 Conclusions 3.1.1

In what ways was the project a success?

Het project heeft beloofd de volgende tastbare resultaten af te leveren: 1. Een methodologie voor een organisatieanalyse met het oog op het modelleren van administratieve basisprocessen. 2. Een analyse van de prioritaire administratieve basisprocessen van de applicatie-instellingen volgens de methodologie. 3. Een software requirements document voor het kernsysteem en de applicaties. 4. Een softwareapplicatie in de vorm van twee prototypes en een stabiele versie, die, met het oog op de continuïteit in het beheer van dynamisch en semi-dynamisch archief enerzijds en statisch archief anderzijds, een exportfunctie naar een geautomatiseerd systeem voor statisch archiefbeheer bevat. 5. De implementatie van de softwareapplicatie in de vier applicatie-instellingen op voorwaarde dat ze de onderzoeksplanning die door de Stuurgroep en het Opvolgingscomité is overeengekomen, naleven. 6. Gebruikersdocumentatie, inclusief een technische handleiding en een gebruikershandleiding, en opleiding. 7. Een afsluitende workshop/studiedag om het project te promoten in andere wetenschappelijke instellingen en in de wetenschappelijke wereld. 8. Een projectrapport. Resultaten 1, 2 en 3 werden in Fase 1 van het project afgeleverd. Resultaten 4, 5, 6 en 8 werden in Fase 2 afgeleverd, met uitzondering van de exportfunctie naar een geautomatiseerd systeem voor statisch archiefbeheer en de implementatie van een applicatie in de ULB. Resultaat 7 zal in de komende zes maanden worden afgeleverd en gedurende die periode zullen de andere resultaten verder worden uitgewerkt (inclusief de exportfunctie naar een geautomatiseerd systeem voor statisch archiefbeheer en de implementatie van een applicatie in de ULB). Dit overzicht bewijst dat het project over het algemeen zijn doelen heeft bereikt.

3.1.2

What factors brought success?

Een eerste factor was de samenwerking van de verschillende personen en groepen die bij het project betrokken waren. •

De belangrijkste factor die het succes heeft beïnvloed, was de samenwerking tussen de onderzoekers betrokken bij het project. Twee medewerkers van het onderzoeksteam (Anthony Jonckheere en Stephanie Waeyenbergh) hebben vanaf de start tot het einde van het project meegewerkt. Ze waren gemotiveerd en voerden de taken uit, vergaarden en bewaarden de 22


knowhow en hielpen later aangeworven medewerkers om mee in het project stappen. Het management van het project heeft geprobeerd ervoor te zorgen dat die onderzoekers tot het einde van het project konden blijven, alhoewel administratieve moeilijkheden soms een belemmering vormden en demotivatie in het onderzoeksteam veroorzaakten. •

Op dezelfde manier was de samenwerking tussen de onderzoekers van de onderzoeksgroepen 'Research and Analysis' en 'Software Development', met inbegrip van de vorsers van de Facultés Universitaires Notre-Dame de la Paix van Namen, vruchtbaar en gaf ze uitstekende resultaten.

•

De collegialiteit en zelfs de vriendschap tussen de projectverantwoordelijken in CEGES-SOMA, IRM-KMI, ULB en VUB hadden -in de tweede helft van het project- een positieve invloed op het project.

•

De constructieve houding van het Opvolgingscomité in de evaluatiefase na de eerste helft van het project ondersteunde de onderzoeksgroepen en het management van het project en speelde een belangrijke rol in de voortzetting van het project.

•

Het enthousiasme van de werkgroepen en de implementatieteams was een motivatie voor de onderzoekers om voort te werken, alhoewel het einde van het project naderde.

Een tweede factor was een les geleerd in Fase 1 van het project: alleen flexibiliteit en volharding hielpen om te gaan met de wisselende visies van het hogere management in de instellingen op de ondersteuning van het project, het tempo van de activiteiten, enz. Door die flexibiliteit vermeed het onderzoeksteam demotivatie. Een derde factor was de degelijke manier waarop het onderzoek en de softwareontwikkeling zijn uitgevoerd. Om de voornoemde doelen te bereiken, werd literatuuronderzoek en onderzoek naar standaarden uitgevoerd en werd de technologische ontwikkeling continu gevolgd.

3.1.3

What factors brought neither success nor failure?

De volgende problemen hebben zich voorgedaan: •

De terugtrekking van sommige instellingen uit het project: de terugtrekking van CEN-SCK en KMSKB-MRBAB is besproken in sectie 2.1.5.1. De impact van het verlies van CEN-SCK en KMSKB-MRBAB is beperkt gebleven. Het globale resultaat van het project is niet beïnvloed, noch hebben de andere applicaties geleden onder de afwezigheid van die van CEN-SCK en KMSKBMRBAB.

•

Om verschillende redenen, uitgelegd in sectie 2.3.5, was de ULB niet in staat om het tempo van het project te volgen en de deadlines na te leven, zodat er geen specifieke module voor het prioritaire proces van de ULB is ontwikkeld. De overname van de VUB-applicatie is echter een valabel alternatief voor de ULB. Het globale resultaat van het project is door die wijziging niet beïnvloed.

•

De gebruikerscommentaren mondden uit in meer eisen die op een flexibele manier werden beantwoord. De vertraging in de softwareontwikkeling veroorzaakte een vertraging in het verzamelen van de gebruikerscommentaren. Enthousiaste gebruikers wilden het maximum uit het systeem halen en stelden wijzigingen of uitbreidingen voor. De onderzoekers hebben geprobeerd om in te gaan op die suggesties, wat meer werk met zich meebracht dan voorzien. Voor CEGESSOMA ontwierpen de onderzoekers een nieuw ordeningsplan. In IRM-KMI beperkte DISSCO zich niet tot één applicatie, maar werd het systeem gebruikt om verschillende applicaties te ontwikkelen voor een meer algemene ondersteuning. In de VUB gaat het verzamelen van gebruikerscommentaren nog door. Een aantal voorstellen vielen buiten het bereik van het project: ze waren niet in het originele projectplan, noch in de contracten bepaald. Het doorvoeren van de wijzigingen zou nieuw onderzoek hebben gevergd. 23


•

De kennisoverdracht, die belangrijk is voor het afterproject, is op het moment van schrijven nog niet voltooid, maar zou in de komende zes maanden moeten worden voltooid. De vertraging in de softwareontwikkeling veroorzaakte ook een vertraging in de kennisoverdracht. Het projectplan voorzag dat het DISSCO-project de applicatie-instellingen in staat zou stellen om: 1. de DISSCO-applicatie te onderhouden 2. de DISSCO-applicatie uit te breiden door nieuwe modules te ontwikkelen 3. de DISSCO-applicatie te promoten in andere wetenschappelijke instellingen De eerste en de tweede opdracht zijn volbracht door: •

softwaredocumentatie ter beschikking te stellen (gedaan)

•

de verantwoordelijke voor de technische implementatie opleiding te laten geven aan de informatici van de applicatie-instellingen met als doel het onderhoud en de verdere ontwikkeling van de DISSCO-applicatie te verzekeren. In IRM-KMI, waar de ICT-afdeling nauw bij DISSCO betrokken is, is de opleiding afgerond. In CEGES-SOMA, ULB en VUB moet ze in de komende zes maanden worden afgerond. In CEGES-SOMA zullen de informatici worden opgeleid. In ULB en VUB lijken de informatici te veel werk te hebben om zich met de DISSCO-applicatie vertrouwd te kunnen maken. Een nieuw informatiebeleid in de instellingen voorziet echter meer informatici en creëert mogelijkheden om de kennis van DISSCO over te dragen.

Met de derde opdracht is een aanvang genomen, maar op het moment van schrijven heeft de geplande interinstitutionele gebruikersgroep, die de applicatie-instellingen bijeenbrengt en dient voor de verdere ontwikkeling, een zeer beperkt aantal leden. •

Deelname aan internationaal onderzoek is (bewust) beperkt: voor de deelname aan het INTERPARES-project waren grote werkingsbudgetten nodig doordat het project vele reizen van de leden vraagt. In Fase 2 waren die budgetten beperkt, net zoals de tijd van de onderzoekers om aan het project te besteden. DISSCO had de budgetten nodig voor personeel en ontwikkeling. Bijgevolg hebben de onderzoekers zich op een meer beperkte internationale samenwerking voor de herziening van de MoReq-specificatie gericht. Het DISSCO-project is ook gepromoot via artikels in het Frans en het Engels (van Scheelings en Temmerman) en de website.

3.1.4

What factors brought failure?

•

Tijdens het project is de samenstelling van het softwareontwikkelingsteam gewijzigd. De oorzaken daarvan zijn in sectie 2.1.5.2 opgenoemd. In augustus dit jaar heeft de junior software developer het project verlaten omdat het einde van het project naderde en hij een vaste betrekking had gevonden. Dat was een cruciaal verlies: het was onmogelijk om een informaticus met dezelfde ervaring te vinden. Door de deadlines verhoogde de druk op de senior software developer. De laatstgenoemde moest het werk van de junior software developer overnemen. Het was duidelijk dat het onmogelijk was om alle doelen van het project voor 31 december 2006 volledig te bereiken. De voortzetting van het project met een half jaar biedt slechts gedeeltelijk een oplossing, want op het einde van het jaar zal het onderzoeksteam uiteengaan. De overblijvende informaticus zal alleen moeten werken.

•

Het project heeft ook geleden onder de beperkte mogelijkheden voor interne en externe promotie. Het systeem is wel op vergaderingen en seminaries gepromoot, maar het was onmogelijk om die te organiseren zonder een uitgewerkte demoversie. Men zou kunnen zeggen dat de keuze om pas aan het einde van de softwareontwikkelingscyclus een grafische gebruikersinterface te ontwikkelen, de promotie heeft tegengehouden. Tijdens de presentaties echter, vroeg het publiek DISSCO in werking te zien. De presentatie verzwakte wanneer een functie nog niet (volledig) was ontwikkeld. Met andere woorden: de functies moesten eerst worden ontwikkeld, wat overeenstemde met de 24


aanvankelijke keuze van de Stuurgroep. Het probleem kon niet worden opgelost. Toen de grafische gebruikersinterface gereed was en verbeterd was, verloor het project zijn tweede informaticus (zoals hierboven beschreven) en de organisatie van promotieactiviteiten werd bij gebrek aan personeel beperkt. •

Om dezelfde reden wordt de beperkte afterprojectondersteuning als een falen aangevoeld. Ze beperkt zich tot: •

het ter beschikking stellen van softwaredocumentatie

•

de opleiding van de informatici van de applicatie-instellingen met als doel het onderhoud en de verdere ontwikkeling van de DISSCO-applicatie te verzekeren (zoals hierboven beschreven).

•

het voorstel om van DISSCO een opensourceapplicatie (Apachelicentie) te maken

Hoewel die afgeleverde producten gepland waren, hadden de partnerinstellingen een meer structurele oplossing in de vorm van een helpdesk en een institutionele onderhoudsstructuur voor ogen. Verschillende mogelijkheden werden nagegaan om het probleem op te lossen. Oproepen voor valoriseringsprojecten waren in 2006 beperkt, net zoals de mogelijkheden om promotieactiviteiten te organiseren. Daarnaast probeerden verschillende leden van de Stuurgroep de aandacht van investeerders te trekken. Verschillende instellingen zijn geïnteresseerd in het project (als gebruikers of als investeerders), maar willen duidelijkheid over de onderhoudsstructuren na het project vooraleer ze tijd of geld investeren. Het zal zeer moeilijk zijn om uit die vicieuze cirkel te geraken. De werking van de DISSCO-applicatie in de applicatie-instellingen zal beslissend zijn voor haar succes.

3.2 Recommendations to Federal Science Policy Als men de successen en de gebreken van het project bekijkt, dan kunnen er conclusies worden getrokken die niet aan één project gebonden zijn, maar die opgaan voor softwareontwikkelingsprojecten in het algemeen. De resultaten van het theoretisch en het methodologisch onderzoek dat aan de softwareontwikkeling is voorafgegaan (bijvoorbeeld de procesanalyse), zijn blijvend verworven en dus bruikbaar in de komende jaren. Het onderzoek was noodzakelijk voor de softwareontwikkeling,en het is duidelijk dat de ontwikkeling zonder dat luik niet mogelijk was geweest. Softwareontwikkeling op zich kan dus nooit een alleenstaand project zijn. De softwareontwikkeling bleek een complex gegeven, dat zich nog moelijker laat plannen dan het gewone onderzoek. Zoals bij gewoon onderzoek moeten een heleboel pistes en technologieën worden onderzocht op hun bruikbaarheid voor de te ontwikkelen applicatie, zonder dat de onderzoekers zeker zijn of de piste ook werkelijk iets opbrengt. Daarbij komt nog de complexiteit van het programmeren. Dat alles maakt softwareontwikkelingsprojecten weinig voorspelbaar qua timing. Vanuit die visie kan men zich afvragen of projecten die vier of vijf jaar duren en waarbij een softwareapplicatie wordt ontwikkeld, niet meer open termijnen zouden moeten hebben, mits uiteraard regelmatige rapportering over de vorderingen. Het gebruik van de software hangt af van de ondersteuning die na de implementatie van de software kan worden gegeven. Er kan binnen de projecten wel worden gewerkt aan het vormen van gebruikersgroepen (via een opvolgingscomité), maar ook die moeten blijvend worden ondersteund. Praktisch komt het neer op het opzetten van een helpdesk en een juridische en institutionele structuur. Dat laatste past echter niet in een project van beperkte duur. Het vergt een marktstudie, een SWOTanalyse en gespecialiseerd personeel van een totaal andere aard dan in een softwareontwikkelingsproject kan worden voorzien (handelsingenieurs!). Voor de coördinatie van een dergelijk economisch project zijn de wetenschappelijke specialisaties van de projectpromotoren 25


(documentbeheer, informatica) nagenoeg nutteloos. De benodigde structuren overstijgen de partnerinstellingen van het project en dat is ook noodzakelijk. Anders blijven de resultaten beperkt tot de partnerinstellingen, wat een te smalle basis is. Ook vanuit die invalshoek bevelen wij aan het Federaal Wetenschapsbeleid aan om, mogelijk in overleg met Fedict, één (overheids)structuur in het leven te roepen die geslaagde softwareontwikkelingsprojecten ondersteunt, tenminste door een helpdesk, zodat de gebruikers van de softwareapplicaties verzekerd worden van ondersteuning, maar ook door een groep vorsers die de software verder kan ontwikkelen. Via die structuur kunnen de daarin ondergebrachte softwareapplicaties worden gepromoot, verspreid en benut door instellingen die niet direct bij de softwareontwikkelingsprojecten betrokken waren. Daardoor kunnen de eenmalige projectinspanningen blijvend rendabel worden gemaakt en hebben de geïnvesteerde onderzoeksgelden uiteindelijk een grotere return.

26


4 Research Results

4.1 Application 4.1.1

Functionalities Review

De DISSCO-applicatie bevat recordsmanagement-, documentmanagementen workflowmanagementfunctionaliteiten. Die functionaliteiten, alsook de plaats van de applicatie tussen recordsmanagement-, documentmanagementen contentmanagementapplicaties zijn in detail in het Extended Report besproken. De combinatie van recordsmanagement- en documentmanagementfunctionaliteiten heeft tot gevolg dat bij opname van documenten in DISSCO de inhoud en de metadata niet worden gefixeerd, wat bij een zuivere recordsmanagementapplicatie wel het geval is. Het wordt aan de gebruikers overgelaten om de documenten te "sluiten". De sluiting van documenten en van aggregaten van documenten wordt door zgn. "sluitingsregels" bepaald. Als basis voor de bepaling van de recordsmanagementfunctionaliteiten is MoReq gebruikt. Archiefstukken in DISSCO kunnen naar een applicatie voor het beheer van statisch archief worden geëxporteerd met behulp van EAD (op het moment van schrijven moet die functionaliteit nog worden uitgewerkt). De uitgebreide functionaliteiten van DISSCO kunnen worden teruggebracht tot de volgende hoofdfunctionaliteiten: •

Centraal elektronisch depot

•

Beheer van elektronische en papieren documenten/archiefstukken, aggregaten van documenten/ archiefstukken, workflows, versies, metadata, gebruikers

•

Bewaring van archiefstukken in overeenstemming met sluitings- (validatie) en selectieregels

•

Gecontroleerde toegang

•

Automatische opname van metadata

•

Zoekmogelijkheden via het ordeningsplan, metadata en full text

•

Import/export (bv. naar een applicatie voor het beheer van statisch archief m.b.v. EAD)

4.1.2

Technical Review

Pour une description technique de l'application: voir section 2.2.

27


4.2 Knowledge Database 4.2.1

Methodology for Organizational Analysis

De organisatieanalyse is in Fase 1 uitgevoerd om de gebruikersnoden en de vereisten voor de DISSCOapplicatie te bepalen. De methodologie voor de organisatieanalyse werd door de FUNDP in samenwerking met de ULB en de VUB uitgewerkt (onderzoeksgroep Research & Analysis). Ze werd uitgewerkt op basis van de onderzoekstradities van de drie disciplines aanwezig in het DISSCO-project: de archivistiek, de organisatiesociologie en requirements engineering. Eigen aan de methodologie is ten eerste dat de analyse driedimensionaal is: mechanisch, politiek en cultureel. Ten tweede is de betrokkenheid van de toekomstige gebruikers groot: ze worden bij elke fase in de analyse geraadpleegd. Het conceptuele raamwerk en de methodologie werden in het Assessment Report (hoofdstuk 3.1.1) uitvoering beschreven. De vragenlijsten voor de prioriteitenanalyse en de organisatieanalyse zijn in bijlage aan dit rapport toegevoegd (zie bijlage E en F). De methodologie wordt in verschillende publicaties van DISSCO behandeld (zie sectie 4.2.10).

4.2.2 4.2.2.1

Metadata Model and Mapping Metadata Model

Het metadatamodel bepaalt de metadata die volgens archivistische aanbevelingen door de DISSCOapplicatie moeten worden ondersteund. Het is gebaseerd op MoReq, UK TNA 2002 en de resultaten van het eerste InterPARES-project. Het beschrijft niet het geheel van metadata die door de DISSCO-applicatie worden gebruikt. Het beschrijft evenmin metadata die betrekking hebben op specifieke noden van de applicatieinstellingen van DISSCO. Die zijn opgenomen in de specifieke gebruikersdocumentatie (zie sectie 4.2.5). Het metadatamodel is in bijlage aan dit rapport toegevoegd (zie bijlage G).

4.2.2.2

Metadata Mapping

De mapping van metadatamodellen heeft twee functies. Ten eerste kan de DISSCO-applicatie dankzij de mapping automatisch metadata overnemen uit de bureausoftware waarmee de opgenomen archiefstukken zijn opgemaakt. Ten tweede maakt de mapping het mogelijk om metadata volgens verschillende modellen te importeren of te exporteren. Met het oog op de mapping is onder andere een vergelijkende studie van archivistische metadatamodellen uitgevoerd. De studie maakte het mogelijk de gemeenschappelijke en de modelspecifieke metadata te onderscheiden en de onderliggende concepten te vergelijken. De studie bestond uit twee delen: een vergelijking van verschillende aanbevelingen, standaarden en normen voor records management onderling en een vergelijking van die standaarden met de internationale norm voor archivistische beschrijving ISAD(G). De standaarden voor records management waren:

28


•

ISO 15489: de internationale norm voor records management, die een basissmetadataset voor archiefstukken voorstelt

•

MoReq: een Europese modelspecificatie voor recordsmanagementapplicaties, die metadata voor archiefstukken, bestanddelen en rubrieken voorstelt

•

UK TNA 2002: een modelspecificatie voor recordsmanagementapplicaties die door het Britse nationaal archief uitgewerkt is. De modelspecificatie heeft niet alleen als basis voor MoReq gediend; ze heeft ook MoReq toegepast in een specifieke geografische context. Ze bepaalt metadata voor archiefstukken, bestanddelen en rubrieken.

•

'Archiefbeheer in de praktijk': bepaalt een basismetadataset voor de registratie van briefwisseling (een van de gekozen processen in het DISSCO-project);

•

Interpares 1: bepaalt een basismetadataset met het oog op de langetermijnbewaring van authentieke elektronische archiefstukken

Uit de vergelijking van de standaarden voor records management onderling kan worden besloten dat MoReq slechts een onvolledig uitgewerkt metadataschema aanbiedt. Het bestaat slechts uit een opsomming van metadata, waarbij de informatie die nodig is voor de toepassing, ontbreekt, bijvoorbeeld een eenduidige definitie en toepassingsregels. UK PRO 2002 blijkt onontbeerlijk te zijn voor de interpretatie van de metadata van MoReq. ISO 15489, Archiefbeheer in de praktijk en Interpares 1 bieden bijkomende informatie voor de registratie van briefwisseling. Uit de vergelijking met ISAD(G) kan worden besloten dat hoe hoger het beschrijvingsniveau is, hoe minder metadata van ISAD(G) kunnen worden vergeleken met die van de standaarden voor records management en hoe ze specifieker ze worden. Er kan een onderscheid worden gemaakt tussen: •

metadata die specifiek zijn, hoewel dat niet noodzakelijk betekent dat de informatie niet door een recordsmanagementapplicatie zou kunnen worden geleverd

•

metadata die vergelijkbaar zijn, maar een andere waarde hebben in de dynamische en semidynamische fase enerzijds en de statische fase anderzijds

•

identieke metadata, waar de waarden in de dynamische en semi-dynamische fase enerzijds en de statische fase anderzijds overeenstemmen

De vergelijkingen zijn in detail besproken in het Assessment Report. De concordantietabellen zijn in bijlage aan dit rapport toegevoegd (zie bijlage H).

4.2.3 4.2.3.1

Software Requirements Description Software Requirements Document

Het software requirements document (SRD) is het lastenboek van de DISSCO-applicatie, op basis waarvan de applicatie is ontwikkeld. Het is het belangrijkste resultaat van het voorbereidend onderzoek, bestaande uit het theoretisch onderzoek en de analyses in de applicatie-instellingen. Het SRD is opgesteld door de onderzoekers van de FUNDP volgens het Volere-sjabloon. Het gebruik van een sjabloon maakt het mogelijk de instelling-specifieke lastenboeken te vergelijken, gemeenschappelijke vereisten te onderscheiden en de volledigheid van de vereisten na te gaan. Het SRD bestaat uit zes delen. Een deel bevat de algemene vereisten voor de DISSCO-applicatie, op basis waarvan de basisfunctionaliteiten van de applicatie op het vlak van archivering, document management en workflow management zijn ontwikkeld. De algemene vereisten zijn ontleend aan het archivistisch en 29


het ICT-onderzoek. Daarnaast is er voor elk van de applicatie-instellingen (CEGES-SOMA, IRM-KMI, KMSKB-MRBAB, ULB, VUB) een deel dat de instelling-specifieke vereisten voor de DISSCO-applicatie bevat, op basis waarvan de instelling-specifieke functionaliteiten van de applicatie zijn ontwikkeld. De instelling-specifieke vereisten zijn ontleend aan de organisatieanalyse. Het SRD is in detail besproken in het Extended Report. Het SRD is in bijlage aan dit rapport toegevoegd (zie bijlage I).

4.2.3.2

Software Requirements Database

De vereisten uit het SRD zijn opgenomen in een Access-databank om het beheer ervan te vergemakkelijken. De Software Requirements Database is in bijlage aan dit rapport toegevoegd (zie bijlage J).

4.2.4 4.2.4.1

General User Documentation User Manual

De handleiding bij de DISSCO-applicatie voor de eindgebruikers bestaat uit twee delen. Het eerste deel bevat uitleg bij archivistische begrippen. Het tweede deel bevat een overzicht van de functies van de applicatie en een stapsgewijze beschrijving van de handelingen die de gebruikers moeten verrichten. De handleiding voor eindgebruikers is in bijlage aan dit rapport toegevoegd (zie bijlage K).

4.2.4.2

Technical Manual

La rédaction du manuel technique est en cours. Il sera disponible pour le 31 décembre 2006.

4.2.5

Supplementary User Documentation

Voor elke applicatie-instelling is er naast de algemene gebruikersdocumentatie, specifieke gebruikersdocumentatie beschikbaar. Die bestaat uit de documentatie die geschreven is naar aanleiding van de analyse- en de implementatieactiviteiten in de instellingen.

4.2.5.1

CEGES-SOMA

Documentatie Documentatie naar aanleiding van de analyse: •

rapport van de prioriteitenanalyse

•

rapport van de instellingenanalyse

•

rapport van de procesanalyse

•

UML-model van de "as is"-situatie

•

UML-model van de "to be"-situatie 30


Documentatie naar aanleiding van de implementatie: •

functieclassificatieschema

•

ordeningsplan voor de archiefstukken

•

voorstel voor een beleid met betrekking tot de behandeling en het beheer van de briefwisseling

•

voorstel voor de verplichte en de optionele metadatasets

•

gebruiksaanwijzing voor het ordeningsplan

•

gebruiksaanwijzing voor de opname van e-mail in DISSCO

•

gebruiksaanwijzing voor de creatie van nieuwe entiteiten in DISSCO

De documentatie is in bijlage aan dit rapport toegevoegd (zie bijlage L). Toelichting bij het ordeningsplan van het SOMA In samenwerking met het implementatieteam van het SOMA is een ordeningsplan voor de archiefstukken van het SOMA opgesteld. Om archivistische redenen is de voorkeur uitgegaan naar een ordeningsplan naar functies. De functies zijn in kern- en ondersteunende functies onderverdeeld. Op vraag van de directie zijn de kern- en de ondersteunende functies opgesplitst volgens het nieuwe organigram van het SOMA, dat geldig is sinds 1 september 2005. Ter voorbereiding van het ordeningsplan is het huidige ordeningssysteem ontleed en is er een functieclassificatieschema opgesteld. Als basis voor de beschrijving van de kernfuncties zijn het ministerieel besluit van 3 maart 2000 tot vaststelling van het statuut, de opdrachten en de wijze van beheer van het Studie- en Documentatiecentrum "Oorlog en Hedendaagse Maatschappij" (S.O.M.A.) (BS 4 april 2000) en de jaarverslagen van het SOMA gebruikt. Als basis voor de beschrijving van de ondersteunende functies is Keyword AAA: A Thesaurus of General Terms van de National Archives of Australia gebruikt. De opstelling van het ordeningsplan is in detail beschreven in het rapport van 30/06/2005.

4.2.5.2

IRM-KMI

Documentatie naar aanleiding van de analyse: •


•


•


•


•

UML-model van de "to be"-situatie

De documentatie is in bijlage aan dit rapport toegevoegd (zie bijlage M). Gedetailleerdere technische resultaten zijn beschreven in sectie 2.3.3.2.

4.2.5.3

KMSKB-MRBAB

Documentatie naar aanleiding van de analyse (opmerking: niet meer van toepassing, zie sectie 2.1.5.1): •

rapport van de prioriteitenanalyse 31


•


•

bronnenlijst

De documentatie is in bijlage aan dit rapport toegevoegd (zie bijlage N).

4.2.5.4

ULB

Documentatie naar aanleiding van de analyse (opmerking: niet meer van toepassing, zie sectie 2.3.5): •


•

rapport van de organisatieanalyse

•

model van de "as is"-analyse

De documentatie is in bijlage aan dit rapport toegevoegd (zie bijlage O).

4.2.5.5

VUB

Documentatie naar aanleiding van de analyse: •


•


•


•


•

UML-model van de "to be"-situatie

Documentatie naar aanleiding van de implementatie: •

documentatie van de integratie van het actuele classificatieschema van de VUB in de informatiestructuur van DISSCO (in samenwerking met het Secretariaat van de Raad, in voorbereiding)

•

een voorstel het ordeningsplan, de verplichte en optionele metadatasets en de sluitingsregels (in samenwerking met het Secretariaat van de Raad, in voorbereiding)

De documentatie is in bijlage aan dit rapport toegevoegd (zie bijlage P).

4.2.6 4.2.6.1

Master Test Plan and Test Unit Description Master Test Plan

Het globale testplan legt voor elk prototype en de stabiele versie van de DISSCO-applicatie de organisatie van de testen vast. Het plan is vooral bedoeld om de samenwerking met de eindgebruikers en de ICT-afdelingen van de instellingen bij het testen van het prototype beta en volgende te stroomlijnen. Ten eerste bepaalt het plan per prototype welke soorten testen moeten worden uitgevoerd en door welk type testers. Ten tweede bepaalt het per test en per type tester welke kwaliteitskenmerken moeten worden getest en hoe belangrijk ze zijn. De kwaliteitskenmerken zijn door de ISO 9126-norm vastgelegd. Verder bepaalt het de testplaats, de infrastructuurvereisten, de startvoorwaarden, de

32


beperkingen, door wie de tester wordt ondersteund, de rapporteringswijze, aan wie moet worden gerapporteerd, de rapporteringsfrequentie en de geschatte duur van de test. Het globale plan omvat: •

een inhoudsopgave

•

algemene informatie betreffende het testplan: opdrachtgever, opdrachtnemer, testsoorten, beschouwingsgebied, doel, randvoorwaarden en uitgangspunten

•

uit te voeren testen, inclusief testdetails, voor het prototype alfa

•

uit te voeren testen, inclusief testdetails, voor het prototype beta

•

uit te voeren testen, inclusief testdetails, voor het prototype gamma

•

uit te voeren testen, inclusief testdetails, voor de stabiele versie

•

te testen kwaliteitskenmerken, inclusief hun belang, per testsoort en per tester voor het prototype alfa

•

te testen kwaliteitskenmerken, inclusief hun belang, per testsoort en per tester voor het prototype beta

•

te testen kwaliteitskenmerken, inclusief hun belang, per testsoort en per tester voor het prototype gamma

•

te testen kwaliteitskenmerken, inclusief hun belang, per testsoort en per tester voor de stabiele versie

•

definities van de kwaliteitskenmerken die door de ISO 9126-norm bepaald zijn

Het globale testplan is in bijlage aan dit rapport toegevoegd (zie bijlage Q).

4.2.6.2

Test Unit Description and Test Form

Om de prototypes en de stabiele versie van de applicatie te kunnen testen, zijn de vereisten uit het SRD omgezet in testeenheden. Dat is gebeurd voor de vereisten van de kern van de DISSCO-applicatie. De testeenheden zijn onderverdeeld per onderwerp en verwante onderwerpen zijn volgens het logisch verloop van de testen gebundeld. De beschrijving van de testeenheden bestaat uit een identificatienummer, een naam, een toelichting (niet altijd aangegeven), een opsomming van de gerelateerde vereisten, een beschrijving van de handelingen die de tester moet uitvoeren (niet altijd aangegeven), door welke soorten testers de test moet worden uitgevoerd en voor welk prototype. Op basis van de beschrijving van de testeenheden is een testformulier opgesteld dat de testers kunnen gebruiken om te rapporteren. Zowel het testformulier als de beschrijving van de testeenheden is in bijlage aan dit rapport toegevoegd (zie bijlage R).

4.2.7

Bibliography (organizational sociology, records management)

De bibliografie met betrekking tot de organisatiesociologie is in de activiteitenrapporten van 30/06/2002 en 20/12/2002 opgenomen.

33


De archivistische bibliografie is systematisch bijgehouden tot mei 2006 en telt een 300-tal titels. In overeenstemming met het theoretische onderzoek dat met het oog op de ontwikkeling en de implementatie van de DISSCO-applicatie is uitgevoerd, behandelt de bibliografie de volgende onderwerpen: •

archiveringssystemen

•

beheer van elektronische archiefstukken

•

recordsmanagementapplicaties

•

metadata

•

internationale en binnenlandse onderzoeksprojecten

•

aanbevelingen, standaarden en normen

De archivistische bibliografie is als bijlage aan dit rapport toegevoegd (zie bijlage S).

4.2.8

Standards inventory (records/archives management, IT)

De studie van aanbevelingen, standaarden en normen is uitgevoerd met het oog op: •

het kunnen voortbouwen op onderzoek in het domein van de archivistiek en de informatica

•

het in overeenstemming brengen van de DISSCO-applicatie met standaarden die kwaliteit en in sommige gevallen ook interoperabiliteit tussen systemen verzekeren

Er werd een stand van zaken van de standaardisering opgemaakt. De belangrijkste archivistische standaarden die in het DISSCO-project zijn gebruikt, zijn: •

ISAD(G): de algemene internationale norm voor archivistisch beschrijven

•

ISO 15489: de internationale norm voor records management

•

MoReq: een Europese modelspecificatie voor recordsmanagementapplicaties

•

UK TNA 2002: een modelspecificatie voor recordsmanagementapplicaties die door het Britse nationaal archief uitgewerkt is. De modelspecificatie heeft niet alleen als basis voor MoReq gediend; ze heeft ook MoReq toegepast in een specifieke geografische context.

De recordsmanagementstandaarden kunnen worden onderverdeeld in standaarden voor archiveringssystemen, modelspecificaties voor recordsmanagementapplicaties en metadatamodellen, al dan niet deel uitmakend van een modelspecificatie voor recordsmanagementapplicaties. De belangrijkste technische standaarden waren: •

NEDLIB, OAIS: referentiemodel voor het ontwerp van een "open archival information system"

•

WFMC: aanbeveling voor het ontwerp van een workflowsysteem

•

WEBDAV - DELTA-V: protocol voor informatieverspreiding met het oog op collectief werk

De standaarden zijn in detail besproken in het Assessment Report. De resultaten van de studie van de archivistische standaarden zijn ook verwerkt in een publicatie (zie 4.2.10). Een volledig overzicht van de archivistische standaarden is terug te vinden in de url-inventaris (zie sectie 4.2.9).

34


4.2.9

URL inventory

De url-inventaris bevat de webadressen van organisaties, onderzoeksprojecten, aanbevelingen, standaarden en normen enz. die voor het theoretische onderzoek in het DISSCO-project zijn gebruikt. De url-inventaris in in bijlage aan dit rapport toegevoegd (zie bijlage T). Hij zal ook op de DISSCOwebsite ter beschikking worden gesteld.

4.2.10 Publications De onderzoeksresultaten van het DISSCO-project zijn verwerkt in de volgende publicaties: - Scheelings, Frank & Temmerman, Patrick, Developing a records management system : Human and technical challenges, in: Essays in honor of Michael Cook. Liverpool: Liverpool University Center for Archive Studies, 2003, p.29-45. - Scheelings, Frank, Développer un système de gestion globale des archives. Le projet DISSCO et les aspects humains, in: Les archives électroniques. Quels défis pour l'avenir? Louvain-la-Neuve: Archives de l'Université Catholique de Louvain, 2004, p.37-49. - Waeyenbergh, Stephanie, Standaarden voor dynamisch archiefbeheer, in: Bibliotheek en Archiefgids, 80 (2004), 2, p.10-17. - Waeyenbergh, Stephanie, Voorbereidend onderzoek voor de recordsmanagementapplicatie (ontwerp) (http://www.meteo.be/DISSCO)

implementatie

- Waeyenbergh, Stephanie, Modelbestek voor de implementatie recordsmanagementapplicatie (ontwerp) (http://www.meteo.be/DISSCO) Beide publicaties in voorbereiding zijn in bijlage aan dit rapport toegevoegd (zie bijlage U).

35

van

van

een

een


5 Application Support Arrangements (After Project)

Door het vroegtijdige vertrek van de junior software developer en het uitstellen van de promotieactiviteiten is er nog geld over om aan een laatste fase van het project te besteden. Daarom wordt er een laatste verlengingsaanvraag van 6 maanden ingediend. Daarmee krijgt de informaticus nog een contractverlenging. De verlenging moet dienen om: •

de laatste implementatieproblemen te regelen en de VUB-module in de ULB te implementeren

•

opleiding te geven aan de eindgebruikers die nog geen opleiding hebben gekregen (ULB)

•

opleiding te geven aan de informatici van de apllicatie-instellingen en knowhow door te geven (vooral in CEGES-SOMA, ULB en VUB)

•

een finale workshop/studiedag te organiseren waarop de resultaten van het project bekend worden gemaakt.

•

de gebruikers te organiseren in een (interinstitutionele) gebruikersgroep of in meerdere groepen (per instelling)

•

de voorbereiding van het after-project verder te zetten.

Voor de voortzetting van het project na 30 juni 2007 is een juridische structuur nodig. Voorbereidende gesprekken zijn gevoerd met DISC, een coördinatie- en expertisecentrum voor ICT-onderzoek. DISC kon ondersteuning bieden in projectpromotie, het zoeken naar partners, het opzetten van een helpdesk, het organiseren van vorming en het aanwerven van personeel. Ook kon DISC als vzw de boekhouding voeren. DISC moest daarbij worden gezien als een overgangsstructuur, waar een eventuele commercialisering van DISSCO kon rijpen. Een groot voordeel was dat de human resources en de knowhow van DISSCO in een kader konden worden gegoten, tenminste indien er geld voor valorisering en verdere ontwikkeling werd bijeengebracht. DISC fungeert al als structuur voor PALLAS, waardoor een combinatie PALLAS-DISSCO haalbaar was. Die combinatie heeft verschillende voordelen, omdat ze zowel het veld van het dynamisch en semi-dynamisch als van het statisch archiefbeheer dekt. Helaas kwam begin november het bericht dat de toekomst van DISC onzeker is. De activiteiten van DISC worden ofwel door een andere vzw overgenomen, ofwel blijft de structuur alleen bestaan om de contracten van PALLAS uit te voeren. In beide gevallen moet de plaats van DISSCO in zo'n structuur worden herbesproken. Met het DISC-scenario in het achterhoofd werd prospectie gedaan naar extra fondsen en naar mogelijkheden om het project voort te zetten. Er is contact opgenomen met verantwoordelijken uit de openbare en de privésector en van de universiteiten zelf. Er hebben enkele lobbyingsvergaderingen plaatsgevonden om de academische overheden te informeren. Daarbij zijn drie pistes bekeken: 1. valorisering en commercialisering via een spin-off: de haalbaarheid daarvan is met de afdeling R&D van de VUB besproken. Het voordeel is dat de universiteiten een bestaand 'valoriseringstraject' kunnen bieden. Maar het is nog te vroeg om een marktstudie uit te laten voeren; daarvoor zijn professionelen en welomschreven commerciële doelstellingen nodig. 2. onderhoud van DISSCO en verdere ontwikkeling via de openbare sector (federale overheid, gewestelijke overheden...) en de privé-sector door middel van nieuwe projectwerking en 36


valoriseringsprojecten. Er bestaat bijvoorbeeld een grote interesse voor de uitbreiding van het project naar audiovisuele en driedimensionale documenten, waarbij tegelijk een sterkere integratie van PALLAS en DISSCO wordt vooropgesteld. Een dergelijk programma kan worden ondersteund door een privépartner met veel expertise op het gebied van klank- en beeldarchivering. 3. Valorisering en commercialisering via een partner uit de privésector: er zijn zeker partners geïnteresseerd, maar de Stuurgroep wil vermijden dat DISSCO uiteindelijk aan de initiële doelgroep van het project (overheden, semi-overheden en instellingen van openbaar nut) voorbij gaat. Daarom werd voorlopig de tweede mogelijkheid weerhouden. Oproepen voor valoriseringsprojecten waren in 2006 echter schaars. Er is geprobeerd om via enkele demonstraties publieke instellingen als investeerders aan te trekken. Die instellingen zijn in het systeem geïnteresseerd (als gebruikers of als investeerders) maar ze willen een klare kijk op de ondersteuning die na het project kan worden geboden vooraleer ze geld en/of tijd investeren. De uiteindelijke implementatie van DISSCO in de applicatieinstellingen en de promotie van DISSCO op de studiedag is dus van beslissend belang. De komende zes maanden volgt de Stuurgroep in elk geval elke mogelijkheid op om een valoriseringsproject te lanceren. Zoals eerder aangegeven zijn de gebruikersgroepen van vitaal belang voor de leefbaarheid van DISSCO op langere termijn. Daarom zullen die groepen in de komende zes maanden en ook daarna regelmatig worden bijeengeroepen. Dat moet toelaten om: •

de applicaties van de andere applicatie-instellingen te leren kennen en zo de visie van de gebruikers op DISSCO te verbreden

•

problemen die zich zouden voordoen, te bespreken en oplossingen te zoeken

•

gezamenlijk te ijveren bij het hogere management van de instellingen om steun te verlenen aan de verspreiding van de applicatie

•

een helpdeskstructuur mee te helpen voorbereiden.

37

DISSCO - Document management Integrated System for Scientific Organisations

Annexe A - DISSCO Folder


Annexe B - DISSCO Newsletter


Annexe C - Workshop for Partner Institutions


Annexe D - Promotion Event


Annexe E - Questionnaire for Priority Analysis


Annexe F - Questionnaire for Organizational Analysis


Annexe G - DISSCO Metadata Model


Annexe H - Metadata Mapping


Annexe I - Software Requirements Document


Annexe J - Software Requirements Database (Access database)


Annexe K - User Manual


Annexe L - User Documentation CEGES-SOMA


Annexe M - User Documentation IRM-KMI


Annexe N - User Documentation KMSKB-MRBAB (obsolete)


Annexe O - User Documentation ULB (obsolete)


Annexe P - User Documentation VUB


Annexe Q - Master Test Plan


Annexe R - Test Unit Description and Test Forms


Annexe S - Bibliography (Access database)


Annexe T - URL inventory


Annexe U - Publications


Annexe V - Meeting Reports

Project Final Report

Recommend Documents