Publicatie:Lastenboek voor de Beeldbank Mechelen

Uit Cultureel Erfgoed Standaardentoolbox
Naar navigatie springen Naar zoeken springen

Dit is de neerslag van een pilootproject dat uitgevoerd werd in het kader van het project Blauwdruk Gedistribueerd Beeldebeheer

Samenvatting

Zomer 2015 kreeg Erfgoedcel Mechelen van Picturae de mededeling dat ze een verouderd CMS- en DAM-systeem gebruikten dat vanaf januari 2016 niet meer ondersteund zou worden. Musea en Erfgoed Mechelen besliste om de markt te verkennen en de aanbesteding te doen voor zowel een nieuwe website als een nieuw DAM-systeem. Deze gevalstudie beschrijft het traject voor het opstellen van lastenboeken tot de toewijzing van de opdrachten aan resp. ZAP en DEVENTit.

Auteur(s)

  • Nastasia Vanderperren (PACKED vzw)

Status

De aanbestedingen werden afgerond in juni 2016. In de zomer van 2016 is DeventIT aan de slag gegaan voor het opzetten van het DAM-systeem. Doordat DeventIT geen RESTful API voorzien had zoals afgesproken, liep het opzetten van de beeldbank vertraging op. Door problemen met de API is ZAP nog bezig met de ontwikkeling van de website. Er wordt verwacht dat de website in de loop van 2017 online komt.

Probleemstelling

Beeldbank Mechelen bestaat sinds 2011. Het was een beeldbank waarbij zowel de website als het DAM-systeem (het systeem waarin de beelden beheerd worden) door Picturae ontwikkeld waren en die samen één geheel vormden. In juli 2015 kreeg Musea & Erfgoed Mechelen het nieuws dat hun contract met Picturae ging vervallen. Bovendien was het CMS- en DAM-systeem van hun beeldbank verouderd en zou het vanaf januari 2016 niet meer ondersteund worden. De CMS-software die de beeldbank gebruikte, was Joomla! 1.7.x. Deze software was uitgekomen op 19 juli 2011 en werd reeds in februari 2012 niet meer door Joomla! ondersteund.[1] Als DAM-software werd Memorix Beeld gebruikt. Ook deze software was enorm verouderd en diende vervangen te worden door Memorix Maior 3.0.

Musea & Erfgoed Mechelen kreeg van Picturae twee opties:

  1. ofwel een upgrade naar de laatste versie van Joomla! en migratie naar de nieuwste versie van Memorix Maior.
  2. ofwel een export van alle data en beelden uit de systemen van Picturae. Dit hield in dat Mechelen beslist om de samenwerking met Picturae stop te zetten. De exitprocedure werd daarmee in gang gezet.

In oktober 2015 contacteerde Musea & Erfgoed Mechelen PACKED vzw met de vraag om samen naar een oplossing te zoeken. Musea & Erfgoed Mechelen vroeg aan Picturae een tijdelijke oplossing om de huidige website een half jaar langer in de lucht te houden zodat ze meer tijd hadden om beslissingen te nemen. Picturae stemde toe om de website tot 1 maart 2016 in de lucht te houden; Memorix Maior werd vanaf 1 maart 2016 tot 1 juli 2016 bevroren. Het kon wel nog geraadpleegd worden en de data bleven bestaan, maar er konden geen nieuwe records toegevoegd worden.

Methode

Erfgoed en Musea Mechelen koos voor optie 2: een export van de data opvragen en de exitprocedure in gang zetten. Mechelen was al langer niet meer tevreden over de diensten van de leverancier. Bovendien moest er omwille van wettelijke bepalingen een nieuwe marktverkenning gebeuren alvorens de opdracht gegeven kon worden om de website en achterliggende databank te vernieuwen.

Keuze voor aanbesteding

Er werd geopteerd om twee aanbestedingen te doen: een voor het DAM-systeem en een voor de website. Niet iedere leverancier van een DAM-systeem is immers goed in het maken van een website, en vice versa. DAM-systemen zijn ook robuuster en worden voor langere tijd gebruikt, terwijl een website de tijdsgeest volgt en sneller verouderd is. Bovendien heb je veel minder leveranciers van DAM-systemen, terwijl er veel website-ontwikkelaars actief zijn. DAM-leveranciers bieden standaardpakketten aan: al hun producten zien er min of meer hetzelfde uit. Een opsplitsing van de twee systemen kon voor vernieuwing zorgen.

Daarnaast kun je, door de twee systemen te ontkoppelen, de twee delen los van elkaar vervangen en maak je je minder afhankelijk van een leverancier. De twee delen worden met elkaar verbonden door middel van een RESTful API. Een API is een geheel van commando's waarmee verschillende computersystemen met elkaar kunnen communiceren. Met een API kun je dus verschillende systemen aan elkaar koppelen en een modulair systeem opbouwen. Je kan eveneens verschillende websites laten voeden met content uit het DAM-systeem door middel van de API.

REST (Representational State Transfer)[2] is de standaard voor het uitwisselen van gegevens over het web.

Functionele vereisten definiëren

Om de technische en functionele eisen te bepalen, werd het stappenplan voor een SRS (software requirements specification)[3] doorlopen. Een SRS is een geheel van documenten waarin aan een ontwikkelaar verduidelijkt wordt wat men wil bereiken met het project. Omdat opdrachtgever en opdrachtnemer niet uit dezelfde sector komen, is er vaak een vertaalslag nodig. Een SRS moet het voor een leverancier helder maken wat de wensen van de opdrachtgever zijn. Het beschrijft functionele en non-functionele vereisten en bevat use cases die de gewenste interacties met de software beschrijven.

Bestand:Stappenplan SRS.pdf

Scope bepalen

Allereerst werd de reikwijdte voor het project vastgelegd. Musea & Erfgoed Mechelen bepaalde de doelstellingen en de gebruikers die ze wilden bedienen. Dit vormt de context voor het lastenboek. Het doel werd kort, duidelijk en concreet verwoord. Hieruit konden functionaliteiten, gebruikers en stakeholders afgeleid worden.

Voor het DAM-systeem was dit het beheren en online ontsluiten van iconografische collecties. Beeldbank Mechelen is een regionale beeldbank, waardoor het voor partnergemeentes en andere organisaties mogelijk moet zijn om hun beelden en bijhorende metadata te beheren en ontsluiten via het systeem. Er werd ook verwacht dat via het DAM-systeem externen beelden kunnen zoeken en gebruiken voor bv. publicaties.

Van de publiekswebsite werd verwacht dat die de iconografische collecties uit het DAM-systeem aan het publiek beschikbaar stelt.

Gebruikers bepalen

Vervolgens werden de verschillende gebruikers en hun rollen gedefinieerd. Uit de samenstelling van stakeholders en gebruikers konden nieuwe functionaliteiten en vereisten gedistilleerd worden. Wanneer een gebruikersgroep bijvoorbeeld over beperkte computervaardigheden beschikt, is het belangrijk dat het systeem eenvoudig en intuïtief is. Gebruikers waren de groepen actoren die het systeem daadwerkelijk gingen gebruiken; stakeholders waren diegene met wie rekening gehouden moesten worden, maar die zelf niet het systeem gaan gebruiken. Gebruikers en stakeholders zijn niet noodzakelijk personen. Dit kunnen ook andere computersystemen zijn.

Voor de gebruikers werden gebruikersrollen gedefinieerd. In een gebruikersrol werd vastgelegd wat een gebruiker mag doen in het systeem.

Musea & Erfgoed Mechelen identificeerde volgende gebruikers:

  • Musea & Erfgoed Mechelen als algemeen beheerder en inhoudelijke partner met een collectie
  • Stadsarchief Mechelen die een iconografische collectie beheert
  • Inhoudelijke partners die over een publieksrelevante collectie beschikken
  • Partnergemeenten die over een iconografische collectie beschikken
  • Externe partners die beelden gebruiken, maar geen iconografische collectie hebben

De voornaamste gebruikers van de website zijn het publiek die afbeeldingen wil bekijken, downloaden en becommentariëren, websitebeheerders en contentbeheerders die inhoud toevoegen aan de website.

Met onze lijst gebruikers konden we nu per gebruikersgroep use cases opstellen.

Use cases opstellen

Use cases[4] zijn korte beschrijvingen van processen die een bepaalde gebruiker wil doen in het systeem. Het werd uitgeschreven als korte scenario's waarin workflows en handelingen met het systeem beschreven worden. De use cases hadden steeds een doel: een gebruiker wil iets bereiken door de software te gebruiken. In een use case werd beschreven wat de gebruiker doet, niet hoe hij dit doet. Zo werd er vastgelegd wat van de software verwacht werd. Het kan beschouwd worden als een contract tussen opdrachtgever en leverancier. De leverancier kreeg er een duidelijk beeld mee welke functionaliteiten verwacht werden.

Uit de use cases konden we in een volgende fase functionele en niet-functionele vereisten afleiden en het bood Musea & Erfgoed Mechelen de mogelijkheid om de wensen voor een systeem duidelijk over te brengen zonder dat ze zelf over een uitgebreide IT-kennis moesten beschikken.

De use cases werden op volgende manier geschreven: Als <gebruikerstype> willen wij <doel om te bereiken + taken die hiervoor uitgevoerd worden> omdat <waarde van het proces>. Ze werden in gewone taal en in korte zinnen opgesteld zodat ze duidelijk en begrijpbaar zijn. Bijvoorbeeld: "Als beheerder van de beheersinterface die de Regionale Beeldbank voedt, willen wij partners met bijhorende collecties kunnen toevoegen en de toegangsrechten tot die collecties beheren, zodat de beeldbank collecties van uiteenlopende oorsprong kan ontsluiten. Wij willen ook op een flexibele manier kunnen bepalen hoe de metadata bij de beelden in de collecties worden ingevoerd opdat de beelden samen met zinvolle inhoudelijke content beschikbaar worden."

De use cases voor website en DAM-systeem werden in deze fase gelijktijdig opgesteld.

Functionele vereisten afleiden

Uit deze use cases werden vervolgens de requirements of features afgeleid. Ze werden kort en duidelijk opgesteld, maar werden niet te gedetailleerd uitgewerkt. Net als bij use cases gaan de vereisten enkel over wat de software moet doen; hoe het gedaan wordt - de implementatie - behoort tot het takenpakket van de leverancier. De vereisten werden wel concreet gemaakt. Metadatamodellen, coderingen van data, bestandsformaten die het systeem moest kunnen opnemen..., werden duidelijk in het document vermeld. Op deze manier waren we zeker dat de leveranciers die intekenden deze functionaliteiten konden verzien. In het geval van dit lastenboek werden een metadatamodel volgens Dublin Core, codering van data in JSON-LD, de beschikking over een RESTful API, en de opslag van JPEG, TIFF en PNG geëist.

Uit het voorbeeld dat aangehaald werd bij het opstellen van use cases, konden volgende features afgeleid worden:

Een beheerder:

  1. Kan partners toevoegen en rechten geven. Partners hebben automatisch rechten op hun eigen items.
  2. Bepaalt welke velden de partners invullen. Partners kunnen niet alle metadatavelden invullen.
  3. Voegt metadatavelden toe en past ze aan.
  4. Beheert centrale thesauri.
  5. Laadt beelden van partners op.

Voor ieder gebruikerstype werden use cases opgemaakt. Per gebruiker kon op deze manier gemiddeld vijf functionaliteiten afgeleid worden.

Prioriteiten bepalen

Binnen de vereisten werden vervolgens prioriteiten opgesteld. Op basis van het budget en de timing was het niet mogelijk om een product op maat van Beeldbank Mechelen te maken. Bovendien riskeer je je op deze manier afhankelijk te maken van je leverancier. Er werd bijgevolg gekozen voor off the shelf-software. Dit is software die aangeboden wordt als een standaardpakket, en die in de mate van het mogelijke aangepast wordt aan de noden van de opdrachtgever. Er vindt geen nieuwe ontwikkeling plaats.

Prioriteiten werden opgesteld volgens de keywords die het IETF, Internet Engineering Task Force[5], hiervoor gedefinieerd heeft.[6] Het bestaat uit drie prioriteitsniveaus:

  • MUST/REQUIRED/SHALL: deze vereiste moet aanwezig zijn, anders is de software onbruikbaar. Zijn tegenhanger, MUST NOT, wijst op features die niet aanwezig mogen zijn.
  • SHOULD/RECOMMENDED: deze vereiste moet aanwezig zijn, maar mag op een alternatieve manier uitgewerkt worden. Afwijkingen zijn toegestand op basis van onderling overleg.
  • MAY/OPTIONAL: deze vereiste is optioneel. De leverancier mag bepalen of hij dit implementeert of niet.

Op basis van deze prioriteiten konden er keuzes gemaakt worden. Zo wordt er een onderscheid gemaakt tussen de essentie en alle toeters en bellen. Wanneer het totale kostenplaatje te groot werd, was er de mogelijkheid om kosten te laten drukken door MAY-features niet te laten implementeren of door afwijkingen of alternatieven voor SHOULD-features te zoeken.

Lastenboek opmaken

De technische bepalingen werden opgemaakt volgens dit sjabloon: Bestand:Software Requirements Document Template.docx. Ze werden opgesplitst in drie delen:

  • Context: hier werden de doelstellingen en de verschillende gebruikers opgelijst. Er werd ook in opgenomen met welke systemen de software rekening moest houden (nl. de nieuwe website die door het DAM-systeem gevoed zou worden door middel van een RESTful API) en op welke manier de export van de gegevens uit de oude beeldbank moest gebeuren. Er werd verduidelijkt dat de oude beeldbank niet meer in de lucht zou zijn op het moment van de gunning en dat er van de oude data een export in csv gemaakt werd die door de nieuwe leverancier in de beeldbank ingeladen moet worden zonder verlies van gegevens.
  • Terminologie: er werd een verklarende woordenlijst toegevoegd om belangrijke termen in het lastenboek te verklaren.
  • Functionele vereisten: dit gedeelte bestaat uit functionele vereisten en niet-functionele vereisten. De functionele vereisten werden afgeleid uit de use cases en zijn de kerntaken die de software moet uitvoeren en waarvoor de software aanbesteed werd. Niet-functionele vereisten zijn taken die een software en leverancier moet uitvoeren, maar die los van een gebruiker staan. Denk bv. aan de beveiliging van het systeem, de uptime, het exit-scenario, de service level agreement (SLA), etc. Musea & Erfgoed Mechelen nam ook de lijst van gebruikers en de bijhorende use cases op in het lastenboek.

Naast de technische bepalingen bestond het lastenboek uit administratieve en contractuele bepalingen. Hiervoor werd het Draaiboek Overheidsopdrachten[7] gevolgd.

Opvragen offertes

De overheidsopdracht werd toegewezen via een onderhandelingsprocedure zonder bekendmaking. Op deze manier kon Musea & Erfgoed Mechelen zelf een aantal leveranciers kiezen naar wie het lastenboek verstuurd zou worden. Dit gaf ook de mogelijkheid om voor het lastenboek voor de website enkel webbedrijven aan te schrijven. Bovendien kan er in de onderhandelingsfase nog bijgestuurd worden. De opdrachten waren:

  • de ontwikkeling van een beeldbank, d.i. een systeem voor het beheren van iconografisch materiaal en metadata (los van een publiekscomponent). De beeldbank beschikt over een RESTful API waarop een website gebouwd kan worden.
  • de ontwikkeling van een website regionale beeldbank, d.i. een website die beeldmateriaal en metadata uit een achterliggend beheersysteem op een dynamische manier ontsluit voor het publiek. Deze website maakt gebruik van de RESTful API van het DAM-systeem om beelden en metadata op te halen.

Het bestek voor het DAM-systeem werd naar een vijf leveranciers gestuurd in binnen- en buitenland: DeventIT, Picturae, Extensis, ADAM Software en Montala Limited. Slechts twee van de vijf reageerden: DEVENTit en Artoos.

Voor de website werden de webbedrijven Inuits, Glue, 10to1, CoreCrew, Tobania, Gents en Zap All People aangeschreven. Ook hier reageerden slechts twee bedrijven: ZAP en Gents.

Gunning en toewijzing

Het beoordelen van de offertes gebeurde in twee fases. In de eerste fase werd iedere offerte beoordeeld. In de tweede fase konden intekenaars hun project voorstellen aan de jury. Onduidelijkheden of tekortkomingen werden via mail gevraagd en beantwoord. Als gunningscriteria werden prijs (50%) en kwaliteit (50%) gebruikt.

De offertes werden beoordeeld door een jury, die bestond uit:

  • een vertegenwoordiger van Musea & Erfgoed Mechelen
  • een vertegenwoordiger van de grootste inhoudelijke partner, Stadsarchief Mechelen
  • een vertegenwoordiger van de Dienst Informatica van de Stad Mechelen
  • twee vertegenwoordigers van PACKED vzw

Voor het toekennen van punten werd een scoreformulier gebruikt dat opgesteld werd door de IT-dienst van Stad Mechelen en moest controleren of aan alle MUST- en SHOULD-criteria voldaan werd.

De opdrachten werden toegewezen aan de kandidaten die de meeste punten behaald hadden. Voor het DAM-systeem was dit DeventIT; voor de website ZAP. Zij haalden de bovenhand voornamelijk op basis van hun prijszetting.

Resultaten

  • Use cases voor het DAM-systeem en de website van Beeldbank Mechelen: Bestand:Beeldbank-Mechelen use-cases.pdf
  • Op basis van de use cases werden twee lastenboeken opgesteld:
  • De gunning voor het DAM-systeem werd toegewezen aan DeventIT. Zap Them All ontwikkelt de website.

Contact

Nastasia Vanderperren
medewerker PACKED vzw
E: nastasia@packed.be
T: +32 (0)2 217 14 05

Referenties

  1. ↑ Joomla, Wikipedia
  2. ↑ Representational State Transfer, Wikipedia
  3. ↑ Software Requirements Specification, Wikipedia
  4. ↑ Use case, Wikipedia
  5. ↑ Internet Engineering Task Fore
  6. ↑ IETF, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119
  7. ↑ e-draaiboek Overheidsopdrachten, Bestuurszaken
Overgenomen van "https://www.projectcest.be/w/index.php?title=Publicatie:Lastenboek_voor_de_Beeldbank_Mechelen&oldid=25527"