Project Final Report

DISSCO 2004-2006 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 Review....................................................................... 3 2.1 Project Management and Organisation.............................................. 3 2.1.1 General....................................................................... 3 2.1.2 Project Management............................................................. 3 2.1.3 Research Groups................................................................ 4 2.1.4 Working Groups and Implementation Teams.......................................... 4 2.1.5 Project Management and Organization Issues......................................... 5 2.1.5.1 Withdrawal of SCK-CEN and KMSKB-MRBAB......................................... 5 2.1.5.2 Reduced Software Development Team............................................... 6 2.1.5.3 Organizational Change within the Partner Institutions.................................... 6 2.2 Development................................................................... 6 2.2.1 Application..................................................................... 8 2.2.1.1 System Entity Types Definition..................................................... 8 2.2.1.2 Metadata...................................................................... 9 2.2.1.3 Search Engine.................................................................. 9 2.2.1.4 Closing Rules, Workflow, Retention & Scheduler....................................... 10 2.2.1.5 Graphical User Interface.......................................................... 10 2.3 Implementation and testing....................................................... 13 2.3.1 General....................................................................... 13 2.3.2 CEGES-SOMA................................................................. 14 2.3.3 IRM-KMI....................................................................... 14 2.3.3.1 Planification.................................................................... 15 2.3.3.2 Résultat....................................................................... 15 2.3.3.3 Observation.................................................................... 16 2.3.4 VUB.......................................................................... 16 2.3.5 Implementation and testing issues: ULB.............................................. 17 2.4 Research and Valorization........................................................ 18 2.5 Communication and Promotion.................................................... 18 2.5.1 Communication and Promotion Tools................................................ 18 2.5.1.1 Website....................................................................... 18 2.5.1.2 Folder......................................................................... 19 2.5.1.3 Newsletter..................................................................... 19 2.5.2 Communication with and Promotion in the Partner Institutions............................. 19 2.5.3 External Communication and Promotion.............................................. 20 2.6 Communication and Promotion Issues: Promotion Event................................ 21 3 Conclusions and Recommendations.............................................. 22 3.1 Conclusions................................................................... 22 3.1.1 In what ways was the project a success?............................................. 22 3.1.2 What factors brought success?..................................................... 22 3.1.3 What factors brought neither success nor failure?...................................... 23 3.1.4 What factors brought failure?....................................................... 24 3.2 Recommendations to Federal Science Policy......................................... 25 4 Research Results.............................................................. 27 4.1 Application.................................................................... 27 4.1.1 Functionalities Review............................................................ 27 4.1.2 Technical Review................................................................ 27 4.2 Knowledge Database............................................................ 28 4.2.1 Methodology for Organizational Analysis............................................. 28 4.2.2 Metadata Model and Mapping...................................................... 28 4.2.2.1 Metadata Model................................................................. 28 4.2.2.2 Metadata Mapping............................................................... 28 4.2.3 Software Requirements Description................................................. 29 4.2.3.1 Software Requirements Document.................................................. 29 4.2.3.2 Software Requirements Database................................................... 30 4.2.4 General User Documentation...................................................... 30

Table of Contents 4.2.4.1 User Manual................................................................... 30 4.2.4.2 Technical Manual................................................................ 30 4.2.5 Supplementary User Documentation................................................. 30 4.2.5.1 CEGES-SOMA................................................................. 30 4.2.5.2 IRM-KMI....................................................................... 31 4.2.5.3 KMSKB-MRBAB................................................................ 31 4.2.5.4 ULB.......................................................................... 32 4.2.5.5 VUB.......................................................................... 32 4.2.6 Master Test Plan and Test Unit Description........................................... 32 4.2.6.1 Master Test Plan................................................................ 32 4.2.6.2 Test Unit Description and Test Form................................................. 33 4.2.7 Bibliography (organizational sociology, records management)............................. 33 4.2.8 Standards inventory (records/archives management, IT)................................. 34 4.2.9 URL inventory.................................................................. 35 4.2.10 Publications.................................................................... 35 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

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 om een valoriseringsproject en verdere afterprojectstructuren op te zetten. 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, IRM- KMI, 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 implementatie van een knowledgemanagementapplicatie voor de directie prioritair was 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 /src Répertoire de compilation de l'ide Contient l'ensemble des fichiers sources /java /test /rsc Contient l'ensemble des sources des classes java du sous-projet Contient l'ensemble des JUnit tests relatifs aux classes java du sous-projet Contient l'ensemble des ressources qui ne sont pas des fichiers java /jar /test 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 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 /xcods * Répertoire de compilation de Maven 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 * /project.properties * /maven.xml* /build.properties.sample * Fichier de description du sous-projet Fichier de définition des propriétés du sous-projet. Fichier de définition des scripts (tests, déploiements ) du projet ou sous-projet. 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