Eindverslag: Deliverance

Transcriptie

1 IN3405 Bachelor Project Eindverslag: Deliverance 6 juli 2011 Technische Universiteit Delft Opleiding: EWI - Technische Informatica - Software Technologie Studenten: Stefan van Wouw Lucas de Vries Bedrijf: Internationaal Instituut voor Sociale Geschiedenis Commissie: Ir. B.R. Sodoyer - Begeleidend docent en coördinator TU Delft Dhr. E. Tuskan - Projectleider IISG

2 Voorwoord Dit rapport is het eindverslag van het vak IN3405 Bachelor Project, dat deel uit maakt van de bachelor opleiding Technische Informatica aan de Technische Universiteit Delft. Het bachelor project is het laatste vak van de opleiding waarin het de bedoeling is dat de opgedane kennis wordt toegepast tijdens een 10 tot 12 weken durende stage bij een bedrijf. Wij hebben deze stage uitgevoerd bij het Internationaal Instituut voor Sociale Geschiedenis (IISG), te Amsterdam. Wij willen graag het IISG en alle betrokken medewerkers bedanken voor het mogelijk maken van deze leerzame stage. Daarnaast willen wij dhr. Tuskan bedanken voor het coördineren van het project binnen het IISG, en ir. Sodoyer voor de inhoudelijke begeleiding van de stage. Delft, juli 2011 Lucas de Vries Stefan van Wouw i

3 Samenvatting Het Internationaal Instituut voor Sociale Geschiedenis (IISG) beheert circa 3000 archieven, 1 miljoen boeken en tijdschriften en een rijke collectie beeld- en geluidsmateriaal. De meeste stukken die het IISG in beheer heeft zijn voor bezoekers vrij in te zien, wat mogelijk is op de speciaal daarvoor ingerichte studiezaal. Naast de fysieke collectie kunnen er ook reproducties van stukken (in de vorm van hoge resolutie bestanden en PDFs) worden besteld. Het IISG heeft hiervoor een aparte reproductie afdeling, die ervoor zorgt dat bestelde reproducties bij de klant terecht komen. De processen voor de inzage van fysieke stukken en voor de bestelling van een digitale reproductie binnen het IISG verlopen vooralsnog volledig handmatig. Om deze processen te automatiseren, te stroomlijnen en te versimpelen, is er tijdens de stage een prototype van een software systeem ontwikkeld dat dit bewerkstelligt. Voordat er begonnen is aan het ontwerpen en het implementeren van het systeem, is er eerst onderzoek gedaan naar zowel de bestaande systemen als bestaande standaarden binnen de archiveringswereld. Ook is er een bezoek gebracht aan het Stadsarchief Amsterdam ter verdere oriëntatie. Na deze oriëntatiefase zijn de eisen aan het systeem verzameld door het observeren van de processen op de werkvloer en door het houden van diverse gesprekken met betrokken medewerkers van het IISG. Er is daarna een globaal ontwerp gemaakt van het systeem, dat zowel het reserveren van fysieke stukken als het aanvragen van reproducties moet faciliteren. Hierbij is gekozen om een systeem op maat te maken, omdat de vereiste functionaliteit te veel afwijkt van de functionaliteit die bestaande systemen bieden. Aan het einde van de ontwerpfase is besloten om tijdens de stage slechts een deel van het systeem te implementeren. Dit betreft het deel dat verantwoordelijk is voor het afhandelen van reserveringen om fysieke stukken in te zien. Voor dit deel is een gedetailleerd ontwerp gemaakt en er is zowel een test- als implementatieplan opgesteld. Vervolgens is een prototype van dit deel van het systeem iteratief geïmplementeerd. Er zijn in totaal 2 iteraties geweest met na elke iteratie een evaluatie gesprek, waar werd gekeken in hoeverre de doelstellingen waren gehaald. Uiteindelijk is er een werkend prototype opgeleverd dat aan de gestelde formele eisen voldoet, en waarmee de opdrachtgever bovendien tevreden is. In dit prototype is het via een web interface mogelijk om reserveringen te plaatsen om stukken in te kunnen zien. Het systeem houdt de locatie van de stukken bij en het is mogelijk om te specificeren welke inzage- en gebruiksrestricties er op een stuk gelden. De medewerkers kunnen een reservering uitprinten, zodat ze kunnen zien welke stukken er waar en wanneer uit het magazijn moeten worden opgehaald. Door de barcode op een van de uitgeprinte vellen te scannen kan de status van een reservering worden aangepast. Om het prototype om te zetten tot een systeem dat in een productie-omgeving kan draaien, dienen er nog een aantal stappen uitgevoerd te worden. Hieronder vallen het integreren van de huisstijl van het IISG, het koppelen van gebruikersauthenticatie aan CAS/LDAP en het uitvoeren van acceptatietests. ii

4 Inhoudsopgave Voorwoord Samenvatting i ii 1 Inleiding 1 2 Organisatie Aanpak Fasering Deliverables Evaluatiemomenten Onderzoek Integrated Library Systems Standaarden Stadsarchief Amsterdam Analyse Requirements Toestandsovergangen Stukken Systeem Interacties Voorbeeldinterface Ontwerp Maatwerk vs Bestaand Systeem Subsystemen Database API Implementatie Planning en Resultaten Gebruikte Programmeertaal, Tools en Libraries Structureel Ontwerp Test Methodiek Code Evaluatie SIG Conclusies en Aanbevelingen Resultaten Aanbevelingen Reflectie Verklarende Woordenlijst 21 A Opdrachtomschrijving 25 B Plan van Aanpak 28 iii

5 C Logboek 34 D Oriëntatieverslag 40 E Requirements Document 51 F Architectural Design Document 84 G Technical Design Document 105 iv

6 Hoofdstuk 1 Inleiding Het Internationaal Instituut voor Sociale Geschiedenis (IISG) beheert circa 3000 archieven, 1 miljoen boeken en tijdschriften en een rijke collectie beeld- en geluidsmateriaal. De meeste stukken die het IISG in beheer heeft zijn voor bezoekers vrij in te zien, wat mogelijk is op de speciaal daarvoor ingerichte studiezaal. Er zijn ook een aantal stukken die pas na een bepaalde datum in te zien zijn, of als de eigenaar van het archief er expliciet toestemming voor heeft gegeven. Er bestaan gebruiksrestricties op stukken. Bepaalde stukken zijn te kostbaar om zonder speciale voorzorgsmaatregelen te worden ingezien. De originele exemplaren van deze stukken mogen daarom niet door bezoekers worden bekeken. In plaats daarvan wordt er een kopie van het origineel, zoals een microfilm, aan de bezoeker overhandigd. Naast de fysieke collectie kunnen er ook reproducties van stukken (in de vorm van hoge resolutie bestanden en PDFs) worden besteld. Het IISG heeft hiervoor een aparte reproductie afdeling, die ervoor zorgt dat bestelde reproducties bij de klant terecht komen. Probleemstelling De processen voor de inzage van fysieke stukken en voor de bestelling van een digitale reproductie binnen het IISG verlopen vooralsnog volledig handmatig. Om een stuk in te zien dient een papieren formulier ingevuld te worden. Doordat de status en locatie van een stuk niet centraal staan opgeslagen is het vaak pas bekend of stukken ingezien kunnen worden als bezoekers al ter plaatse zijn. Vervolgens moeten deze bezoekers vaak lang wachten totdat hun aangevraagde stuk uit het magazijn is gehaald omdat er veel tijd gemoeid is met het opzoeken van de status en locatie van de aangevraagde stukken. De status van de stukken wordt namelijk bijgehouden in een kaartenbak en de locatie in een spreadsheet, welke met de hand moeten worden doorzocht. Als het stuk na inzage weer teruggebracht wordt, moet opnieuw de locatie opgezocht worden om te weten waar het stuk in het magazijn hoort te staan. Het bestellen van reproducties gebeurt nu door het sturen van een naar de organisatie, waar na controle van de betaling handmatig de bestanden op een FTP server worden gezet. Een FTP account wordt aangemaakt voor de klant en daarna worden de inloggegevens met de hand in een naar de klant verstuurd. Projectdoel Dit project heeft als doel om de processen die bij de reservering van archiefstukken of de bestelling van een reproductie komen kijken te automatiseren en te stroomlijnen. Daarnaast dient het opzoeken en bijhouden van de status van de stukken versimpeld te worden. Er is tijdens de stage een software systeem ontwikkeld (in vorm van een prototype), dat dit doel bewerkstelligt. Structuur In dit verslag wordt beschreven hoe het ontwikkelde systeem tot stand is gekomen. Allereerst wordt de organisatie van het project beschreven in hoofdstuk 2. Daarna wordt in hoofdstuk 3 het vooronderzoek besproken, wat uitgevoerd is ter oriëntatie op de al aanwezige systemen en standaarden in de archiveringswereld. De eisen aan het systeem en de totstandkoming daarvan worden besproken in hoofdstuk 1

7 4. Het daaropvolgende ontwerp en de implementatie van het prototype is uiteengezet in respectievelijk hoofdstuk 5 en 6. Tot slot zijn in hoofdstuk 7 de conclusies, aanbevelingen en persoonlijke ervaringen te lezen. 2

8 Hoofdstuk 2 Organisatie Dit hoofdstuk beschrijft hoe we het stage project hebben gestructureerd en gefaseerd. Ook worden de deliverables en evaluatiemomenten besproken. 2.1 Aanpak Aan het begin van het project hebben we een Plan van Aanpak (bijlage B) opgesteld om duidelijk te maken wat precies de projectstructuur zou worden. Bij het schrijven van het plan van aanpak hebben we besloten om, na de oriëntatiefase, te beginnen met een analyse- en ontwerpfase gevolgd door een iteratief opgebouwde implementatiefase. Omdat de nodige concepten en structuren voor het systeem van te voren duidelijk moesten zijn hebben we allereerst documenten betreffende de eisen en het globale ontwerp opgesteld. Dit zijn het Requirements document (bijlage E) en het Architectural Design document (bijlage F). Het specifieke deel dat geïmplementeerd is binnen de context van dit project is later pas uitgewerkt in het Technical Design document (bijlage G). Al deze documenten zijn zowel naar aanleiding van feedback en tijdens de implementatiefase voortdurend aangepast op nieuw ontdekte situaties. Het deel van het systeem dat na afloop van het project werkend moest zijn hebben we milestone 1 genoemd. Binnen het IISG kunnen voor de overige functionaliteit (die wel globaal in het Architectural Design document is ontworpen) nog verdere milestones worden opgezet. De implementatie van milestone 1 heeft plaatsgevonden in twee iteraties met bijhorende systeem tests en evaluatiemomenten. Het betreft hier dus een 2-traps iteratief project. 2.2 Fasering Voor de planning van het project hebben we allereerst een globale fasering opgesteld aan de hand van de bedachte aanpak. Hoewel er overlap plaatsvindt, voornamelijk bij het updaten van de ontwerpdocumentatie tijdens de implementatie van de iteraties, hebben we de weken van het project als volgt ingedeeld: Week Taak 1 Plan van Aanpak en Oriëntatieverslag 2 Oriëntatieverslag 3 Requirements 4 Architectural Design 5 Technical Design 6 Iteratie Evaluatie Iteratie 1 + Iteratie 2 9 Iteratie 2 10 Eindverslag + Evaluatie Iteratie 2 11 Eindverslag / Eindpresentatie 3

9 Er is een logboek bijgehouden van de activiteiten per dag, te vinden in bijlage C. 2.3 Deliverables Gedurende het project zijn er na elke fase deliverables gemaakt en ingeleverd. Op de implementatie en gegenereerde code documentatie na zijn deze allen bij dit document bijgesloten. De gemaakte deliverables zijn: Plan van Aanpak (Zie bijlage B) Oriëntatieverslag (Zie bijlage D) Requirements (Zie bijlage E) Architectural Design (Zie bijlage F) Technical Design (Zie bijlage G) Implementatie (iteraties 1-2) inclusief unit tests Code Documentatie (doxygen) Eindverslag 2.4 Evaluatiemomenten Voor zowel het Architectural Design document als het Technical Design document zijn aan het begin van het project twee evaluatiemeetings gepland. De verificatie van de requirements heeft op een meer geïtereerde manier plaatsgevonden (Zie hoofdstuk 4). Tijdens deze evaluatiemeetings zijn de ontwerpconcepten en de genomen beslissingen besproken, waarna de documenten zijn aangepast naar aanleiding van de besproken veranderingen en opnieuw ingezonden. Het is na deze bewerking niet voorgekomen dat er een tweede evaluatie moest worden gepland, maar deze optie is niet uitgesloten. Na afloop van het implementeren van de gekozen functionaliteit in elke iteratie (zie hiervoor sectie 6.1) zijn de resultaten besproken en is het product gedemonstreerd tijdens de evaluatiemeetings. Tijdens de evaluatie van de iteraties is er besproken welke functionaliteiten er geïmplementeerd waren en welke functionaliteiten er nog moesten volgen in de volgende iteratie. Er is bij elke geplande functie een demonstratie gegeven met test data, waarna er feedback is gegeven en aanpassingen zijn besproken. Tijdens de presentatie van de laatste iteratie hebben we ook onze aanbevelingen voor de voortzetting van het project gegeven. 4

10 Hoofdstuk 3 Onderzoek Voordat er begonnen is aan het vergaren van eisen aan het systeem en het bouwen ervan, hebben we ons eerst georiënteerd op de al bestaande systemen die mogelijk gebruikt zouden kunnen worden voor het automatiseren van de dienstverlening bij het IISG. We kwamen er al snel achter dat er voor het automatiseren van de dienstverlening bij bibliotheken en soortgelijke instellingen als archieven en musea vaak gebruik wordt gemaakt van een een Integrated Library System (ILS). Een ILS biedt een oplossing voor diverse zaken die voorheen met de hand werden gedaan, zoals het beheren en doorzoeken van de catalogus, en het reserveren en uitlenen van stukken. Omdat het IISG van plan is om gebruik te gaan maken van twee van zulke ILS systemen, en er veel overeenkomsten zijn tussen de werkwijze van het IISG en de mogelijkheden die een ILS biedt, hebben we besloten om ons hier verder op te oriënteren. Naast de oriëntatie op de Integrated Library Systems hebben we gekeken wat de bestaande standaarden voor het beschrijven en uitwisselen van catalogus informatie zijn en hebben we het Stadsarchief Amsterdam bezocht om te kijken wat voor oplossingen zij hebben gevonden voor de problemen waar het IISG nu mee kampt. De waarnemingen tijdens het onderzoek zijn in dit hoofdstuk kort weergegeven. Voor een uitgebreidere documentatie verwijzen we naar het Oriëntatieverslag dat te vinden is in bijlage D. 3.1 Integrated Library Systems Er zijn diverse Integrated Library Systems op de markt, zowel open source als closed source. Tijdens de oriëntatie is er een selectie gemaakt uit de bestaande systemen, waarbij naast de hoeveelheid gebruikers en de innovativiteit ook veel gekeken is naar open source systemen, omdat het IISG een doelstelling heeft om alleen maar open source software te gebruiken. De systemen Evergreen, Koha, Aleph en VuFind zijn onderzocht en op een aantal veelvoorkomende Integrated Library System aspecten met elkaar vergeleken. Hiervoor is gebruik gemaakt van de documentatie en beschikbare demo s van deze systemen. De aspecten waar op vergeleken is, zijn: Catalogus beheer, Zoeken, Registratie, Circulatie, Authenticatie, Acquisitie, Reserveren, Digitale Afgeleiden, en Privacy. Uit deze vergelijking is gebleken dat behalve voor de digitale afgeleiden, elk van de systemen de gekozen aspecten voldoende ondersteunt. 3.2 Standaarden Om bekend te worden met de veelgebruikte standaarden voor datarepresentatie, aggregatie en indexatie in de archiveringswereld, hebben wij er een aantal onder de loep genomen. Deze zijn hieronder kort weergegeven. MARC en EAD MARC staat voor MAchine-Readable Cataloging en is een standaard voor het opslaan van bibliografi- 5

11 sche informatie. Datavelden zijn numeriek gerepresenteerd en kunnen subvelden hebben. Velden kunnen informatie bevatten over algemene eigenschappen (auteur, publicatiedatum, ISBN) maar ook specifieke informatie als de fysieke locatie en het aantal exemplaren. De Encoded Archival Description (EAD) is een andere standaard voor het representeren van informatie over stukken waarbij de nadruk ligt op hierarchische relaties. Hiermee kunnen bijvoorbeeld archieven worden gespecificeerd. Z39.50, SRU en Dublin Core Z39.50 is een standaard voor het uitvoeren van zoekqueries en het verzenden van informatie van computer databases. Zoekfunctionaliteiten voor het uitlenen van boeken tussen verschillende bibliotheken worden vaak geïmplementeerd als Z39.50 communicatie. Het SRU protocol is ontstaan na verschillende pogingen tot modernisatie van het Z39.50 protocol en dient hetzelfde doel. Het SRU formaat bevat naast alle andere velden een data veld, waarvan de inhoud vaak gespecificeerd is door de Dublin Core standaard. OAI-PMH Het OAI-PMH protocol, wat staat voor Open Archives Initiative Protocol for Metadata Harvesting is een protocol om grote hoeveelheden metadata op te vragen via een uniforme interface over het web. Het protocol wordt bijvoorbeeld gebruikt door Wikipedia, om artikel updates door te geven aan zoekmachines. 3.3 Stadsarchief Amsterdam Om te kijken hoe andere archiefinstellingen hun dienstverlening hebben geautomatiseerd, hebben we een bezoek gebracht aan het Stadsarchief van Amsterdam. Toen we daar aankwamen werden we naar een vergaderkamer geleid waar werd verteld hoe het Stadsarchief precies te werk gaat. Bij het Stadsarchief worden er in principe geen fysieke stukken meer ter inzage gegeven als deze reeds zijn gedigitaliseerd. Gedigitaliseerde stukken zijn in een te zien via een webinterface. Een bezoeker dient een account aan te maken en dan kunnen er scans worden besteld met het scantegoed dat op dat account staat. Reproducties van beeldmateriaal kunnen worden besteld in een webshop. Na het gesprek in de vergaderkamer kregen we een demonstratie van dit systeem. Daarna werd uitgelegd hoe het inzien van nog niet gedigitaliseerde stukken in zijn werk gaat. Bezoekers dienen een speciaal pasje aan te vragen welke wordt gebruikt om de bezoeker te kunnen identificeren. We kregen te zien hoe het proces om een stuk in te zien verloopt. Een bezoeker vraagt een stuk aan via een webinterface. Vervolgens komt deze aanvraag uit de printer bij de afdeling logistiek, die het aangevraagde stuk ophaalt uit het magazijn. De status van een archiefstuk wordt bijgehouden, en kan worden gewijzigd door de barcode op het printvel te scannen. Tijdens het bezoek aan het Stadsarchief hebben we een aantal dingen gezien die we hebben meegenomen bij het ontwerpen van het systeem voor het IISG. De workflow van de stukken bijvoorbeeld, lijkt erg op hoe de mensen van het IISG zich de toekomstige workflow hadden voorgesteld. 6

12 Hoofdstuk 4 Analyse In dit hoofdstuk worden de resultaten van de analyse fase van het project weergegeven. Dit zijn de eisen aan het systeem en afgeleiden daarvan zoals use cases en voorbeeldschermen. 4.1 Requirements Voor het opstellen van de requirements zijn verschillende gesprekken gevoerd met medewerkers uit zowel de studiezaal als de reproductie-afdeling. Daarnaast zijn een aantal processen op de werkvloer geöbserveerd, en zijn een aantal ideeën die ooit op papier waren gezet bestudeerd. Nadat de huidige situatie bekend was hebben we een tentatieve opsomming van requirements van het te maken systeem opgesteld, en zijn we vervolgens nogmaals in gesprek gegaan voor de evaluatie. Omdat er tijdens deze gesprekken verscheidene veranderingen aan de voorgestelde workflows zijn voorgesteld, hebben we hierna nog een keer over het requirements document geïtereerd en heeft er een tweede evaluatie plaatsgevonden. Na het verwerken van de feedback en het optimaliseren van de voorgestelde workflows is de volgende lijst met functionele requirements opgesteld. Voor gedetailleerde omschrijvingen van elke benoemde requirement en voor een lijst van niet-functionele requirements, zie hoofdstuk 2 van het Requirements document (bijlage E). [F:1] Uitleenstatus opvragen [F:2] Stukken aanvragen [F:3] Digitale reproductie kopen [F:4] Toestemming verzoeken [F:5] Inloggen medewerker [F:6] Metadata invullen/bewerken [F:7] Aanvragen bekijken [F:8] Status van een aanvraag aanpassen [F:9] Toestemming voor inzage bemiddelen [F:10] Offerte digitalisatie [F:11] Inscannen van stukken [F:12] Bijhouden status van een stuk [F:13] Bijhouden metadata over stukken [F:14] Aanvragen automatisch uitprinten [F:15] Geen registratie (account) voor bezoekers 7

13 4.2 Toestandsovergangen Stukken Een belangrijke vraag bij het onderzoeken van de requirements was welke verschillende statussen en statusovergangen van stukken op te nemen in het ontwerp. Het aantal interacties tussen de medewerkers en het systeem moet minimaal gehouden worden voor een soepele workflow. Omdat het systeem toch moet weten waar de stukken op het moment aanwezig zijn hebben we de volgende statussen geïdentificeerd. Dit diagram (figuur 4.1) is opgesteld naar aanleiding van gesprekken met verschillende medewerkers van het IISG die met deze workflow te maken zouden krijgen.! Figuur 4.1: Toestandsdiagram Stukken 4.3 Systeem Interacties Om de interacties tussen het systeem en de gebruiker weer te geven zijn er in het Requirements document voor de meest voorkomende acties use cases opgesteld. Elke use case beschrijft de stappen die door zowel de gebruiker als het systeem worden ondernomen en in welke volgorde dit gebeurt. De use cases zijn gepresenteerd aan de medewerkers van het IISG en er is hieruit nuttige feedback voortgekomen: de informatie- en plaatsvervangersvellen zouden automatisch uitgeprint moeten worden indien deze een reservering representeren die op de huidige dag is geplaatst. De use cases die in hoofdstuk 3 van het Requirements document (bijlage E) beschreven staan zijn: 8

14 3.1.1 Reserveren van stukken Bestel een digitale reproductie Toestemming aanvragen Inloggen Metadata aanpassen Aanvragen ophalen Toestemming geven/weigeren Reserveren van stukken Stuk wordt teruggebracht Stuk inscannen Prijsopgave invoeren 4.4 Voorbeeldinterface Om een visuele weergave te maken van het proces dat de gebruikers en medewerkers moeten doorlopen tijdens de use cases, zijn er in de analysefase ook mockups van de user interface opgesteld. Voorbeelden van de volgende schermen zijn in hoofdstuk 4 van het Requirements document (bijlage E) te vinden: 4.1 Printoverzicht 4.2 Stukken reserveren 4.3 Reproducties bestellen 4.4 Aanvraagoverzicht 4.5 Metadata Aanpassen 4.6 Aanvraag Toestemming 4.7 Toestemming Geven 9

15 Hoofdstuk 5 Ontwerp In de ontwerpfase hebben we alle globale elementen van het systeem gespecificeerd. Dit zijn de elementen die niet afhankelijk zijn van de specifieke implementatiedetails, zoals APIs die van buitenaf zichtbaar zijn, of het database ontwerp. Het opgeleverde ontwerpdocument is goedgekeurd in een evaluatiegesprek met de aanwezigheid van de projectleiding en een ontwikkelaar van het IISG. Tijdens de implementatiefase zijn geleidelijk elementen die nog in het ontwerp misten toegevoegd. Dit waren bijvoorbeeld nieuwe API calls of velden in de database waarvan duidelijk werd dat ze nodig waren. De rest van dit hoofdstuk beschrijft de afweging tussen een bestaand systeem en maatwerk, de opdeling in subsystemen, het database ontwerp, en de te implementeren API. 5.1 Maatwerk vs Bestaand Systeem De eerste beslissing die genomen moest worden bij het ontwerpen van het systeem was of er een volledig op maat gemaakt systeem zou worden opgezet of dat er een plugin zou worden gemaakt voor een bestaand systeem. Tijdens de onderzoeksfase hebben we een aantal systemen bekeken, waaronder systemen die al voor andere doeleinden binnen het IISG in gebruik zijn of worden genomen (Evergreen en VuFind). We hebben gekeken in hoeverre de functionaliteiten die tijdens de analysefase naar boven zijn gekomen al ondersteund werden door deze systemen, en hoeveel er gemodificeerd of toegevoegd zou moeten worden. Uiteindelijk hebben we om verschillende redenen gekozen om een eigen systeem te ontwikkelen. Een van de voornaamste redenen hiervoor was de harde eis vanuit het IISG dat er voor het reserveren van stukken geen accounts nodig moesten zijn: het invullen van een naam en adres moet voldoen. Omdat alle ILS systemen die we onderzocht hebben zich baseren op een leden en registratiesysteem, zouden we voor de implementatie van het reserveringsdeel een groot deel van de systemen moeten veranderen. Een van de functies van het systeem moest zijn dat er op inventarisnummer kon worden gereserveerd. Dat wil zeggen dat elk archief in onderdelen is opverdeeld en dat de onderdelen ook los kunnen worden aangevraagd. Dit was een level van detail dat niet door de ILS systemen ondersteund werd. Omdat het systeem ook andere metadata en gegevens over inzagerestricties bij moet houden, zouden deze ook los moeten worden ingevoerd in een gekozen systeem. Het IISG heeft ook aangegeven dat ze deze gegevens liever in een losse database wilden hebben staan. Hier komt bij dat de ILS systemen die door het IISG in gebruik zijn allemaal een erg specifiek afgebakende functie hebben binnen de volledige workflow, en het uitbreiden hiervan zou de netheid van de informatiestroom inperken. Om deze redenen hebben we gekozen om een nieuw systeem te implementeren. 10

16 5.2 Subsystemen Tijdens het ontwerpen hebben we het systeem opgesplitst in de in figuur 5.1 gespecificeerde subsystemen. Elk subsysteem beheert aparte functionaliteit en heeft aparte APIs en database entiteiten. Figuur 5.1: Globale decompositie in subsystemen Gebruikers Het subsysteem voor gebruikersbeheer laat administrators nieuwe accounts toevoegen en rollen/groepen aanpassen van bestaande gebruikers, en beheert bovendien de authenticatie en loginsessies van gebruikers Metadata Het record management subsysteem biedt functionaliteit om de opgeslagen metadata over stukken in de database op te vragen en aan te passen Reserveringen Met het subsysteem voor reservation management kunnen reserveringen worden aangemaakt door bezoekers en kunnen de medewerkers reserveringsinformatie opvragen, uitprinten en bewerken. Onder dit subsysteem valt ook het inscannen van barcodes voor stukken, waarmee de status reserveringen worden bijgehouden Permissies Permission management beheert de aanvragen voor toestemming die door bezoekers zijn aangemaakt. Bezoekers kunnen via dit subsysteem een formulier invullen om toestemming te vragen om een beperkt archief in te zien. Medewerkers kunnen daarna de aanvragen bekijken en, na bemiddeling met de contactpersoon van het archief, de aanvraag autoriseren of afwijzen. 11

17 5.3 Database Voor het representeren en opslaan van de metadata van stukken en overige informatie benodigd in het systeem hebben we gekozen om een relationele database te gebruiken. Na geanalyseerd te hebben welke gegevens er per requirement en use case moeten worden opgeslagen, hebben we het generieke database diagram in hoofdstuk 3 van het Architectural Design document (bijlage F) opgesteld. Deze database is zoals alle andere dingen in het Architectural Design document geëvalueerd in de daarvoor geplande meeting, en is nagekeken door een van de ontwikkelaars van het IISG. 5.4 API Vanuit de interface waaruit bezoekers naar stukken zoeken moet aan het reserveringssysteem kunnen worden opgevraagd of een stuk beschikbaar is en/of er inzagerestricties op zitten. Het zoeksysteem baseert hierop of er een knop om een reservering of bestelling te plaatsen aanwezig is. In overleg met de ontwikkelaar die deze functionaliteit binnen het zoeksysteem gaat implementeren hebben we besloten om een op REST-principes gebaseerde HTTP API te maken. De API maakt gebruik van JSON en JSONP voor het representeren en overgeven van data, en staat volledig gespecificeerd in hoofdstuk 4 van het Architectural Design document (bijlage F). 12

18 Hoofdstuk 6 Implementatie In de implementatiefase hebben we een prototype van het ontworpen systeem gebouwd. Deze fase wordt beschouwd als milestone 1 van het algehele ontwikkeltraject. Het ontwerp beschreven in hoofdstuk 5 is vrij globaal. Daarom is er, voordat er begonnen is aan het implementeren van het prototype, eerst een gedetailleerd ontwerp gemaakt voor dat deel van het systeem. Tijdens de implementatie is zowel dit Technical Design als het globale Architectural Design telkens bijgewerkt naar de nieuwe inzichten die we tijdens de implementatie kregen. In dit hoofdstuk wordt de implementatiefase van het project besproken. Zowel de planning en gebruikte tools en libraries, als het gedetailleerde ontwerp en de gebruikte test methodiek komen aan bod. Tot slot wordt de code evaluatie besproken die door de Software Improvement Group (SIG) gegeven is. 6.1 Planning en Resultaten In overleg met de ontwikkelaars en de projectleider hebben we afgesproken welk deel van het systeem geïmplementeerd zou worden. Het deel van het systeem wat het bestellen van reproducties mogelijk maakt is afhankelijk van nog niet bestaande externe systemen. Daarom hebben we ook gekozen om niet dit deel, maar het reserveringsgedeelte van het systeem te gaan implementeren. Er zijn twee iteraties geweest van elk twee weken. Na elke iteratie is er een evaluatie gesprek gehouden waar zowel de projectleider als een aantal ontwikkelaars bij aanwezig is geweest. We presenteerden het geleverde werk aan de hand van een demonstratie, en namen daarna feedback in ontvangst. Mensen dachten actief mee om oplossingen te vinden voor kleine problemen waar we tegenaan liepen. Over het algemeen waren ze tevreden met het resultaat. De opmerkingen die ze hadden gingen vooral over details (extra database velden e.d.). Deze opmerkingen hebben we na de evaluatie meteen verwerkt. Naast de evaluatie gesprekken hebben we na iteratie 2 ook een korte demonstratie gegeven van het prototype. Dit gebeurde tijdens een halfjaarlijkse personeelsbijeenkomst van het IISG, waarin alle huidige ICT projecten de revue passeerden. Hieronder volgt het MoSCoW schema per iteratie. Daarbij is respectievelijk met een vinkje of een kruisje aangegeven of wel of niet aan de requirement is voldaan. Dit is besloten aan de hand van het testscript bijgevoegd bij het Technical Design Document uit bijlage G. Er is bewust gekozen om het sturen van toestemmingsverzoeken naar contactpersonen niet te implementeren, omdat het achterliggende beleid nog niet aanwezig is. Het automatisch uitprinten van aanvragen hebben we niet geïmplementeerd omdat het ons uiteindelijk toch handiger leek om dat te doen bij het installeren van het systeem op een test/productieserver. Printfunctionaliteit is namelijk afhankelijk van het besturingssysteem en de aanwezige printers. 13

19 Legenda M S C W Must have Should have Could have Won t have (but would like) Iteratie 1 Prioriteit Timespan Requirement! M Week 1 [F:13] Bijhouden metadata over stukken! M Week 1 [F:12] Bijhouden status van een stuk! M Week 1 [F:6] Metadata invullen/bewerken! S Week 2 [F:2] Stukken aanvragen! S Week 2 [F:2a] Maximaal 3 stukken per aanvraag! S Week 2 [F:2c] Reserveren huidige dag voor 16:00! S Week 2 [F:1] Uitleenstatus opvragen! C Week 2 [F:7] Aanvragen bekijken! C Week 2 [F:2b] Wachtnummer aanvragen huidige dag! C Week 2 [F:14a] Informatie- en plaatsvervangingsvellen printen Iteratie 2 Prioriteit Timespan Requirement! M Week 3 [F:5] Inloggen medewerker! M Week 3 [F:15] Geen registratie (account) voor bezoekers! M Week 3 [F:7] Aanvragen bekijken! M Week 3 [F:8] Status van een aanvraag aanpassen! M Week 3 [F:1] Uitleenstatus opvragen! M Week 3 [F:2] Stukken aanvragen! M Week 3 [F:2a] Maximaal 3 stukken per aanvraag! M Week 3 [F:2c] Reserveren huidige dag voor 16:00! S Week 4 [F:4] Toestemming verzoeken! S Week 4 [F:2b] Wachtnummer aanvragen huidige dag! S Week 4 [F:9] Toestemming voor inzage bemiddelen! S Week 4 [F:14a] Informatie- en plaatsvervangingsvellen printen # C Week 4 [F:14] Aanvragen automatisch uitprinten! C Week 4 [F:4a] Bericht ter goedkeuring/afwijzing toestemming # W Week 4 [F:9a] Toestemmingsverzoek direct naar contactpersoon 6.2 Gebruikte Programmeertaal, Tools en Libraries Voordat we zijn begonnen met implementeren hebben we een aantal afwegingen moeten maken wat betreft de te gebruiken programmeertaal, tools en libraries. Deze afwegingen staan uitgebreid beschreven in hoofdstuk 2 van het Technical Design document (bijlage G). Hier volgt een kort overzicht. Programmeertaal De programmeertalen die we tegen elkaar afgewogen hebben zijn PHP, Python en Java. Uiteindelijk is voor Java gekozen omdat dit een veelgebruikte programmeertaal is (goedkoper/makkelijker onderhoud), en deze taal over een goede object georiënteerde standaard bibliotheek beschikt. 14

20 Framework We hebben het Spring MVC framework gebruikt om het systeem in te implementeren. Het Spring MVC framework wordt ook bij andere projecten van het IISG gebruikt. Door ook bij ons project dit framework te gebruiken is het systeem makkelijker onderhoudbaar en uitbreidbaar door andere ontwikkelaars van het IISG. Libraries We hebben gekozen om JUnit te gebruiken voor unit tests en Hibernate voor de database communicatie. Beiden zijn al in Spring geïntegreerd en dus makkelijk naast elkaar te gebruiken. Software en Tools Als database software hebben we PostgreSQL gebruikt en de project afhankelijkheden hebben we geregeld in Maven. Om taken te verdelen en bugs te melden is gebruik gemaakt van Trac. Het versiebeheer is bijgehouden in Git, en later geëxporteerd naar een centrale SVN repository naar wens van het IISG. Met Doxygen hebben we de code documentatie gegenereerd. 6.3 Structureel Ontwerp De implementatie bevat 4 hoofdonderdelen/packages van het systeem, namelijk: record, permission, user, en reservation. Om de globale werking en structuur van elk van deze packages te illustreren volgt een gesimplificeerd klassendiagram van de record package in figuur 6.1, waarin de stippellijnen de globale control flow aangeven. Elk package heeft een Controller klasse, welke de aanroepen van zowel externe systemen als van gebruikers afvangt. De controller roept vervolgens een Service klasse aan. Deze klasse vertegenwoordigt de service die een package biedt. De controller kan aanroepen doen naar de service laag van zijn eigen package, maar ook naar die van andere packages. De service laag kan op zijn beurt weer aanroepen doen naar de Data Access Object (DAO) laag, welke de objecten die data (stukken, locaties etc.) representeren beheert. De gekozen structuur bleek voor ons systeem goed te werken. Er zijn geen problemen ontstaan tijdens de implementatie omdat er met bepaalde dingen geen rekening was gehouden in het ontwerp. Het enige dat gezegd kan worden is dat er een aantal DAO klassen zijn die nauwelijks gebruikt worden. Zo wordt de LocationDAO uit de record-package alleen gebruikt om locaties van stukken uit de database te verwijderen. Het toevoegen van locaties aan de database gebeurt door het toevoegen van locaties aan een Record object, waardoor de locaties automatisch worden opgeslagen indien dat Record object wordt opgeslagen. Dat dit gebeurt is ook niet heel gek, want een Location is geen entiteit die zonder een bijbehorend Record in de database zou bestaan. 15

21 $ $ $ $!" # ""## ""## ""##!" # " # Figuur 6.1: Klassenvoorbeeld Record Package. 6.4 Test Methodiek In het testplan bijgesloten bij het Technical Design document (bijlage G) is gespecificeerd op welke manieren het systeem getest zou worden. Hieronder een overzicht hoe dit uiteindelijk heeft uitgepakt. Voor elke iteratie zijn er verschillende test categorieën: 1. Unit Tests: Binnen een klasse op methode niveau testen van code. Dit is gedaan bij alle niettriviale methoden. Het is gebleken dat er niet veel niet-triviale methoden waren die niet al door de volgende categorie van tests werd getest. Er zijn daarom ook niet veel van deze tests geschreven. 2. Integration Tests: Dit type tests zorgt ervoor dat de samenwerking tussen klassen wordt getest. Alle API aanroepen die geïmplementeerd zijn in het prototype zijn door middel van geautomatiseerde JUnit tests getest. We hebben hiervoor een test scaffold gebouwd die een aantal reserveringen en stukken in de database zet, en de HTTP Request aanroep nadoet (mockt). De web interface is met de hand getest. Geautomatiseerde tests hiervoor schrijven heeft volgens ons weinig zin. De user interface kan per iteratie veranderen (andere knop namen/ posities), wat de tests waardeloos maakt. 3. System Tests: Dit type tests zorgt ervoor dat er aan de requirements wordt voldaan. Aan de hand van het test script bijgevoegd bij het Technical Design document (bijlage G) is gekeken of het systeem aan de opgestelde functionele requirements voldoet. 16

22 4. Acceptance Tests: Dit type tests zorgt ervoor dat het systeem ook daadwerkelijk doet wat de gebruiker ervan verwacht. Aangezien er een prototype is opgeleverd, zijn er geen acceptance tests uitgevoerd. Dit zal worden gedaan in een vervolgproject dat wordt aanbevolen in sectie Code Evaluatie SIG De Software Improvement Group (SIG) heeft onze code tweemaal doorgemeten om te kijken hoe onderhoudbaar onze code is. Hieronder volgen de twee aanbevelingen die we hebben gekregen, en onze onderbouwing waarom we deze wel of niet hebben opgevolgd Meting na iteratie 1 Na de eerste iteratie hebben we de code uit zowel de reservation als de record-package opgestuurd ter evaluatie. De permission en user packages waren na iteratie 1 nog niet geïmplementeerd, en zijn daarom dus ook niet meegezonden. Aanbeveling SIG De code van het systeem scoort net 3 sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code gemiddeld onderhoudbaar is. De score wordt naar beneden gehaald door de Unit Complexity en de Unit Size. Voor Unit Complexity wordt er gekeken naar het percentage code wat bovengemiddeld complex is. Het opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elk onderdeel simpel wordt en daardoor makkelijker is om te begrijpen, te testen en daardoor te onderhouden. De meest complexe methode in dit systeem is te vinden in de ReservationController, maar ook in de RecordController zijn dit soort methodes te vinden. Commentaar regels zoals // Add result to model en // Set the current page geven meestal al aan dat er aparte blokken van functionaliteit te onderscheiden zijn binnen de methodes welke makkelijk los te trekken zijn. Op eenzelfde manier word er voor Unit Size gekeken naar het percentage code wat bovengemiddeld lang is. Ook hier geldt dat het opsplitsen van dit soort methodes in kleinere stukken ervoor zorgt dat elk onderdeel makkelijker te begrijpen, te testen en daardoor te onderhouden wordt. In dit geval komen de meest complexe methoden ook naar voren als de langste methoden, waardoor het oplossen van het eerste probleem ook dit probleem zal verhelpen. Alhoewel het systeem nu gemiddeld scoort lijkt het erop dat de onderhoudbaarheid makkelijk te verbeteren is met een relatief kleine inspanning. Daarnaast is het goed om te zien dat er al wat test-code aanwezig is om het systeem automatisch te testen, hopelijk zal het volume van de test code groeien op het moment dat er nieuwe functionaliteit toegevoegd wordt. Commentaar op Aanbeveling We hebben deze aanbeveling overgenomen omdat we zelf ook vonden dat er een aantal methoden waren die opgesplitst zouden kunnen worden, zodat de complexiteit zou verminderen. Het voorbeeld uit ReservationController dat in de aanbeveling wordt gegeven is een methode die het reserveringsoverzicht afhandelt. De resultaten die in het reserveringsoverzicht worden weergegeven kunnen met diverse filters worden verfijnd. Het toevoegen van die filters aan de database query gebeurde allemaal in dezelfde methode, wat we nu hebben opgesplitst in een aparte methode per filter. De andere aanpassingen die we hebben gedaan betreffen vooral het reduceren van code duplicaten die zijn ontstaan doordat er meerdere manieren zijn waarop het systeem kan worden aangeroepen. Dit kan zowel via de API als door bezoekers via de daarvoor aangewezen web interface worden gedaan. De foutafhandeling is het enige wezenlijke verschil tussen beide manieren van aanroepen. Desondanks is het toch best lastig gebleken om gedeelde code hiervoor te schrijven dat ook nog eens efficiënt is. Het is uiteindelijk gelukt om dit te doen voor het gros van alle methoden. Alleen het toevoegen van stukken zou naar ons insziens dermate inefficiënt worden als we deze duplicaten zouden proberen te verminderen, dat we deze hebben laten staan. Om dit probleem op te lossen is waarschijnlijk een extra 17

23 abstractielaag nodig, waar wordt besloten op welke manier de fout moet worden gepresenteerd aan de gebruiker, afhankelijk van de manier van aanroepen. Naast deze aanpassingen hebben we bij het implementeren van de resterende packages ook extra zorg besteed aan het voorkomen van nieuwe complexe/lange methoden Meting na iteratie 2 Na de tweede iteratie hebben we de code van alle packages meegezonden, aangezien ook alle packages uiteindelijk zijn geïmplementeerd. Aanbeveling SIG In de tweede upload zien we dat de omvang van het systeem bijna is verdubbeld en dat daarbij de score voor onderhoudbaarheid is gestegen. Deze stijging is voornamelijk toe te schrijven aan het feit dat het percentage code in zowel lange als complexe methodes flink is gedaald. Daarnaast is er ook een stijging waar te nemen in het percentage duplicatie binnen het systeem, wat de totale score iets naar beneden haalt. Als laatste laten de metingen voor abstractie zien dat Record.java wellicht een te prominente rol aan het innemen is binnen het systeem. Uit deze observaties kunnen we concluderen dat de aanbevelingen van de vorige evaluatie zijn meegenomen in het ontwikkeltraject. Alhoewel er op verschillende plaatsen nog ruimte over is voor verbetering lijkt de onderhoudbaarheid van het systeem de goede kant op te gaan. Commentaar op Aanbeveling De aanbeveling komt overeen met onze verwachtingen. We hebben namelijk inderdaad getracht de code complexiteit per methode te verminderen, maar dit is zoals gezegd in het commentaar op de eerste aanbeveling niet volledig gelukt. Wij zijn het niet eens met de uitspraak dat Record.java wellicht een te prominente rol aan het innemen is binnen het systeem (vanuit het onderhoudbaarheidsperspectief). De Record klasse, welke bevat is in het Record.java bestand en een (archief)stuk representeert, vervult zeker een prominente rol binnen het systeem. Maar als je dit in de context plaatst, en het doel van het systeem naast deze constatering legt, is het meer dan logisch dat er veel gebruik wordt gemaakt van deze klasse. Het is immers de verantwoordelijkheid van het systeem om allerlei metadata over stukken te beheren. Men reserveert stukken, vraagt toestemming aan om stukken in te zien, en past metadata aan over de stukken. De Record klasse is daarom ook in zowel de reservation, permission, als record package gebruikt. Dit is onvermijdelijk wil men het doel van het systeem naleven. De Record klasse vervult daarom naar onze mening niet een te prominente rol binnen het systeem, maar wordt alleen gebruikt op de plekken waar dat essentieel is. Dat wil zeggen dat er geen gebruik van de klasse binnen het systeem is dat leidt tot onnodige koppeling en daarmee de onderhoudbaarheid van het systeem omlaag haalt. 18

24 Hoofdstuk 7 Conclusies en Aanbevelingen In dit hoofdstuk worden zowel de conclusies wat betreft de resultaten als aanbevelingen van het project uiteengezet. Daarna volgt onze persoonlijke reflectie op de stage. 7.1 Resultaten Het doel van het project was om de processen die bij de reservering van archiefstukken of de bestelling van een reproductie komen kijken te automatiseren en te stroomlijnen, en tevens te versimpelen. Om dit doel te bereiken hebben we de workflows geanalyseerd, requirements opgesteld en een ontwerp gemaakt van het software systeem waarmee we dit doel wilden bereiken. Omdat het te veel tijd zou kosten om het hele systeem te implementeren, is er een prototype ontwikkeld van een deel van het systeem. In dit prototype is het via een web interface mogelijk om reserveringen te plaatsen om stukken in te kunnen zien. Het systeem houdt de locatie van de stukken bij en het is mogelijk om te specificeren welke inzage- en gebruiksrestricties er op een stuk gelden. De medewerkers kunnen een reservering uitprinten, zodat ze kunnen zien welke stukken er waar en wanneer uit het magazijn moeten worden opgehaald. Door de barcode op een van de uitgeprinte vellen te scannen kan de status van een reservering worden aangepast. Het opgeleverde prototype voldoet aan de formele eisen die zijn gesteld. De opdrachtgever is bovendien tevreden met het resultaat. Er kan dus geconcludeerd worden dat het project succesvol is afgerond. Na een aantal extra stappen kan het systeem in productie worden genomen. De aanbevelingen voor het in productie nemen van het systeem zijn beschreven in de volgende sectie. 7.2 Aanbevelingen Na afloop van het project is er een prototype van de geplande functionaliteiten van milestone 1 ingeleverd. Om dit prototype in productie te nemen zijn nog een aantal stappen vereist. In dit hoofdstuk zullen we zowel deze stappen en onze aanbevelingen over het uitvoeren er van geven. Voor het in productie nemen van milestone 1 moeten en nog een aantal integratie-features worden toegevoegd: het gebruikerssysteem moet gekoppeld worden aan het CAS/LDAP authenticatiesysteem dat al in de organisatie aanwezig is, en moet er een proces geschreven worden dat automatisch nieuwe aanvragen uitprint op de hardware in de studiezaal. Hiernaast moet de user interface van het systeem opgemaakt worden naar de huisstijl van het IISG, en moet deze door middel van acceptatie tests optimaal worden gemaakt voor gebruik. 19

25 Een mogelijke planning van alle nog te ondernemen stappen voor milestone 1 zou kunnen zijn: Week Taak Personeel 1 Stijl aanpassen aan huisstijl Ontwikkelaars 2 Koppeling gebruikersauthenticatie vanuit Ontwikkelaars CAS/LDAP 3 Implementatie automatisch uitprinten Ontwikkelaars Testen systeem met barcode scanners 4 Opzet server en implementatie op server Ontwikkelaars, Sysadmins 5 Acceptatietests Ontwikkelaars, Studiezaal Verwerken feedback acceptatietests Ontwikkelaars Tijdens dit gehele proces kunnen de gegevens/metadata over de stukken handmatig danwel gescript vanuit andere databases worden omgezet. 7.3 Reflectie Het is leuk om je opgedane kennis van drie jaar studeren in de praktijk te brengen. Het bachelor project is het eerste project in de opleiding waar je voor een echte opdrachtgever een systeem ontwerpt en implementeert. Daarnaast is het, op de vaste onderdelen na, volledig aan ons geweest hoe we het project vormgegeven werd. Het bezoek aan het Stadsarchief Amsterdam en de interviews met de medewerkers van het IISG vonden we interessant en nuttig, omdat je dan ook de menselijke kant leert kennen voordat je meteen een systeem begint te maken zonder de eindgebruikers er bij te betrekken. Tijdens de ontwerpfase van het project werkten we voornamelijk op onze toegewezen kamer op het IISG en tijdens de implementatiefase hebben we vooral vanuit huis gewerkt. We communiceerden dan via Skype met elkaar. Dat werkte op zich goed, aangezien we slechts met twee personen in de groep zaten. Met een groep van vier personen had dit waarschijnlijk minder goed gewerkt. Behalve tijdens de implementatiefase spraken we bijna elke dag de projectleider om de huidige status van het project te bespreken. Een aantal van de ontwikkelaars spraken we alleen tijdens tussentijdse evaluatie gesprekken. Het had misschien leuk geweest om op dezelfde verdieping als hen te zitten zodat we ze wat vaker konden spreken, ook al waren we dan waarschijnlijk minder productief geweest dan nu. De door ons gekozen project fasering was nieuw voor ons, maar het bleek goed te werken. We waren tevens niet bekend met het Spring MVC framework. Het kostte aardig wat tijd om aan dit framework te wennen. Het viel ons op dat er soms wel 4 manieren waren om een bepaalde functionaliteit voor elkaar te krijgen. Op het Internet stond vaak verouderde documentatie en het kostte dan vaak veel tijd om op te zoeken hoe je een bepaalde functionaliteit kon toevoegen die ook nog eens compatibel was met de door ons gebruikte versie van het framework. Het opleveren van het systeem in iteraties waar dan stapje voor stapje steeds meer functionaliteit bij kwam is goed bevallen. Het is ook leuk om te zien dat mensen tijdens de demonstraties enthousiast reageren en dat er zelfs wordt gezegd dat er van onze manier van documenteren wordt geleerd als zijnde een goed voorbeeld. Al met al is deze stage ons goed bevallen en we hopen ons systeem uiteindelijk een keer in productie te mogen meemaken. 20

26 Verklarende Woordenlijst Aanvraag Een bezoeker kan een aanvraag doen om bepaalde stukken in te zien. Een aanvraag is dus een verzameling stukken die gereserveerd danwel uitgeleend zijn voor inzage door een bezoeker. Actor Een type gebruiker van het systeem (bijv. bezoeker of studiezaalmedewerker). API Application Programming Interface; Een verzameling functies om de services die een bibliotheek of ander programma biedt te kunnen gebruiken/aanroepen. Bezoeker Een persoon die te gast is bij het IISG om danwel stukken in te zien, danwel reproducties te bestellen. De bezoeker kan zowel via het internet, als op locatie een service van het IISG gebruiken. Contactpersoon Persoon waarmee contact dient te worden opgenomen indien er een inzage restrictie op een archief(stuk) rust. Embargodatum Datum waarna een stuk vrij wordt gegeven voor inzage. De inzage restrictie zal dan automatisch naar Open veranderen. Framework Een raamwerk aan software componenten dat standaard-oplossingen biedt voor bepaalde handelingen die vaak worden uitgevoerd bij het schrijven van software. Voorbeeld: Django is een framework dat standaard-oplossingen biedt voor het schrijven van een web-applicatie in de programmeertaal Python. FTP File Transfer Protocol; een gestandaardiseerd protocol om bestanden uit te wisselen tussen verschillende computers. Functionele Requirement Eis die beschrijft wat het systeem moet kunnen. Dit type eis is direct af te leiden uit de probleemstelling. Gebruiksrestrictie Beperking wat betreft het gebruik van een stuk. Het kan bijvoorbeeld zijn dat alleen de microfilm mag worden uitgeleend en het origineel niet. Hoog Resolutie Bestand Een afbeelding met hoge resolutie/kwaliteit. Exacte resolutie/kwaliteit is door een extern systeem bepaald (De Shared Object Repository). 21