Knooppunt 3.0 – RFP
Frank Salliau 12 februari 2014 V1.1
1
Historiek v1.0 v1.1
6 februari 2014 12 februari 2014
Eerste draft Wijzigingen na feedback stuurgroep & RvB
1 Over dit document ...................................................................................................................................................... 5 2 Geheimhoudingsclausule ......................................................................................................................................... 6 3 Achtergrond & Context ............................................................................................................................................. 6 3.1 Historiek & Missie .............................................................................................................................................. 6 3.2 Doelgroepen ......................................................................................................................................................... 7 3.3 Cijfers ....................................................................................................................................................................... 7 3.4 Wat is Knooppunt niet? ................................................................................................................................... 8 4 Motivatie project ......................................................................................................................................................... 8 5 Project .............................................................................................................................................................................. 8 5.1 Scope ........................................................................................................................................................................ 8 5.2 Tijdslijn ................................................................................................................................................................... 9 6 Selectieproces leverancier ...................................................................................................................................... 9 7 Evaluatiecriteria .......................................................................................................................................................... 9 8 Vereisten ....................................................................................................................................................................... 10 8.1 Projectmatig, Budgettair & Samenwerkingsmodel ........................................................................... 10 8.2 Architectuur ........................................................................................................................................................ 10 8.3 Standaarden & Off-‐the-‐shelf oplossingen .............................................................................................. 11 8.4 Website knooppunt.net en digiportail.be .............................................................................................. 11 8.5 Backoffice ............................................................................................................................................................. 12 8.6 Licentiekantoor ................................................................................................................................................. 12 8.7 Licensed Content Management & Content Repository .................................................................... 13 8.8 Security: rollen en toegangsrechten ......................................................................................................... 13 8.9 Logging module ................................................................................................................................................. 13 8.10 Rapportage module ...................................................................................................................................... 14 8.11 API Infrastructuur ......................................................................................................................................... 14
2
8.11.1 API Set ........................................................................................................................................................ 14 8.11.2 Vereisten API ........................................................................................................................................... 15 8.12 Domein model ................................................................................................................................................. 15 8.12.1 UML Class Diagram ............................................................................................................................... 16 8.12.2 Klassen ....................................................................................................................................................... 16 8.13 Rollen .................................................................................................................................................................. 20 8.13.1 UML Diagram .......................................................................................................................................... 21 8.14 Use Cases ........................................................................................................................................................... 21 8.14.1 Overzicht use cases .............................................................................................................................. 22 8.14.2 Gedetailleerde beschrijving use cases .......................................................................................... 23 8.15 Functionaliteit met variabele scope ...................................................................................................... 23 8.15.1 Registratieproces .................................................................................................................................. 23 8.15.2 Schoollicentie .......................................................................................................................................... 24 8.16 Niet-‐functionele vereisten ......................................................................................................................... 24 8.16.1 Migratie data ........................................................................................................................................... 24 8.16.2 Security ...................................................................................................................................................... 25 8.16.3 Gebruikersvriendelijkheid ................................................................................................................ 25 8.16.4 Platform & browseronafhankelijkheid ........................................................................................ 25 8.16.5 Schaalbaarheid ....................................................................................................................................... 25 8.16.6 Performantie ........................................................................................................................................... 26 8.16.7 Disaster recovery .................................................................................................................................. 26 8.16.8 Test & Acceptatie platform ............................................................................................................... 26 8.16.9 Deployment proces .............................................................................................................................. 26 8.16.10 Documentatie, handleidingen & opleidingen ......................................................................... 26 8.16.11 Onafhankelijkheid .............................................................................................................................. 26 8.16.12 Toegankelijkheid ................................................................................................................................ 27 9 Business Cases ............................................................................................................................................................ 27 9.1 Business case "Verbeterd registratieproces " ...................................................................................... 27
3
9.2 Business case “Frauduleuze klasaccount” ............................................................................................. 27 9.3 Business case “Fusie school” ....................................................................................................................... 27 9.4 Business case "Beveiligen externe content" ......................................................................................... 28 9.5 Business case "Schoollicentie" .................................................................................................................... 28 9.6 Business case "Rollback na fout uitgever " ............................................................................................ 28 9.7 Business case “Migratie data” ..................................................................................................................... 28 10 Richtlijnen voor de aanbieders ........................................................................................................................ 28 11 Inhoud voorstel ....................................................................................................................................................... 29 11.1 Budget ................................................................................................................................................................. 29 11.2 Planning ............................................................................................................................................................. 29 11.3 Projectaanpak .................................................................................................................................................. 29 11.3.1 Projectaanpak ......................................................................................................................................... 29 11.3.2 Communicatie ......................................................................................................................................... 29 11.3.3 Testplan ..................................................................................................................................................... 30 11.3.4 Acceptatieplan ........................................................................................................................................ 30 11.3.5 Releaseplan .............................................................................................................................................. 30 11.3.6 Integratie met 3de partijen ................................................................................................................. 30 11.4 Architectuur & Technologie ...................................................................................................................... 30 11.4.1 Architectuur ............................................................................................................................................ 30 11.4.2 Database(s) .............................................................................................................................................. 30 11.4.3 Website knooppunt.net/digiportail.be ........................................................................................ 31 11.4.4 Backoffice ................................................................................................................................................. 31 11.4.5 Licensed Content Management ....................................................................................................... 31 11.4.6 Content Repository ............................................................................................................................... 31 11.4.7 Licentiekantoor ...................................................................................................................................... 31 11.4.8 Authenticatie ........................................................................................................................................... 31 11.4.9 Logging ...................................................................................................................................................... 31 11.4.10 Rapportage ............................................................................................................................................ 31
4
11.4.11 API ............................................................................................................................................................. 31 11.5 Business cases ................................................................................................................................................. 32 11.6 Niet-‐functionele vereisten ......................................................................................................................... 32 11.6.1 Migratie data ........................................................................................................................................... 32 11.6.2 Security ...................................................................................................................................................... 32 11.6.3 Gebruikersvriendelijkheid ................................................................................................................ 32 11.6.4 Platform & browser-‐onafhankelijkheid ...................................................................................... 32 11.6.5 Schaalbaarheid ....................................................................................................................................... 32 11.6.6 Performantie ........................................................................................................................................... 32 11.6.7 Disaster Recovery ................................................................................................................................. 32 11.6.8 Test & Acceptatieplatform ................................................................................................................ 32 11.6.9 Deployment proces .............................................................................................................................. 33 11.6.10 Documentatie, handleidingen & opleidingen ......................................................................... 33 11.6.11 Onafhankelijkheid .............................................................................................................................. 33 11.6.12 Toegankelijkheid ................................................................................................................................ 33 11.7 Competenties & tarieven ............................................................................................................................ 33 11.8 Technische vereisten .................................................................................................................................... 33
1
Over dit document
Knooppunt vzw is op zoek naar een technologische partner voor de bouw van Knooppunt 3.0. Knooppunt 3.0 is een nieuwe versie van het reeds bestaande Knooppunt platform, het centrale platform voor distributie van digitale leermiddelen van de Vlaamse educatieve uitgeverijen. Om het selectieproces van een technologische partner te faciliteren werd naar een 10-‐tal software bouwers, hierna aanbieders genoemd, een RFI of Request for Information uitgestuurd. Na evaluatie van de antwoorden op de RFI werd een shortlist van aanbieders geselecteerd. Deze aanbieders ontvangen een RFP of Request For Proposal (dit document). De RFP moet leiden tot een finaal voorstel en een bindende offerte, op basis waarvan de opdracht zal toegekend worden aan de gekozen aanbieder. Van de geïnteresseerde aanbieder wordt verwacht dat hij een antwoord biedt op de vragen gesteld in deze RFP.
5
Bijlagen: • Appendix 1: Use Cases (PDF) • Vendor Score Card (Excel) • Vendor Rate Card (Excel)
2
Geheimhoudingsclausule
De informatie vervat in dit document is confidentieel en eigendom van Knooppunt vzw. Bij het accepteren van deze RFP verbindt de aanbieder zich tot het naleven van de geheimhoudings-‐clausule of NDA, die hij reeds ondertekend heeft bij het indienen van het antwoord op de RFI.
3
Achtergrond & Context
3.1 Historiek & Missie Digitaal lesmateriaal werd klassiek gedistribueerd via CD-‐ROM’s, die meegeleverd werden met schoolboeken. Deze aanpak had een aantal nadelen: • •
Geen controle over toegang: de uitgeverij had geen controle over wie toegang had tot de content. Pirateren van CD-‐ROM’s was schering en inslag. Updates: distributie van updates was omslachtig en duur
In 2009 namen 2 educatieve uitgeverijen, Plantyn en Van In, het initiatief om samen een platform op te zetten om digitaal lesmateriaal eenvoudiger en goedkoper te ontsluiten, wat leidde tot het opzetten van het Knooppunt platform. Het idee was om digitaal lesmateriaal op een website te plaatsen, deze te beveiligen met een licentiemodel (bvb. gebruiker krijgt toegang tot bepaald lesmateriaal gedurende bepaalde periode) en deze te ontsluiten a.d.h.v. een activatiecode, die meegeleverd wordt met het schoolboek. Daarenboven kozen beide uitgeverijen voor een collectieve aanpak met een aantal voordelen: • • •
One stop shop: eindgebruikers kunnen op 1 platform terecht, met 1 gebruikersnaam en wachtwoord voor alle digitale content van de deelnemende uitgeverijen Controle: via de beveiligde licenties houden de uitgeverijen controle over wie toegang heeft tot het lesmateriaal Kostenreductie: de investering in een gemeenschappelijk platform opzetten kost de uitgeverij minder dan een eigen platform
Dit leidde tot de bouw van het Knooppunt platform, ontwikkeld door de Nederlandse firma Three Ships. In 2010 waren andere educatieve uitgeverijen ook geinteresseerd om in te stappen in dit initiatief, wat leidde tot de oprichting van Knooppunt vzw.
6
Knooppunt vzw is een dochtervereniging onder de koepel van sectorfederatie Boek.be vzw (www.boekenvak.be), en heeft volgende educatieve uitgeverijen als leden: Averbode, Die Keure, mjPublishing, Pelckmans, Plantyn en Van In. Knooppunt vzw heeft een voltijdse projectleider in dienst, bijgestaan door een helpdeskmedewerker die vragen van eindgebruikers behandelt. De uitgeverijen die lid zijn van Knooppunt vzw bepalen de roadmap en verdere ontwikkeling van Knooppunt i.s.m. de projectleiding. Het Knooppunt platform is momenteel beschikbaar via een aantal kanalen: • •
Websites www.knooppunt.net (NL) & www.digiportail.be (FR) Knooppunt kiosk: native & web app voor iOS/Android/Windows/Desktop (FR/NL)
3.2 Doelgroepen De huidige versie van Knooppunt focust zich op volgende doelgroepen: • •
Leerkrachten secundair onderwijs & basisonderwijs Leerlingen secundair onderwijs
Voor Knooppunt 3.0 wensen we de doelgroepen uit te breiden naar: • • •
Studenten en docenten lerarenopleiding Schoolbibliotheken Volwassenenonderwijs, opleidingscentra, privé-‐opleidingen
Doelgroepen niet in scope binnen Knooppunt 3.0, maar relevant voor latere uitbreiding: • • •
Leerlingen basisonderwijs Docenten en studenten hoger onderwijs Ouders
Het is de bedoeling dat Knooppunt 3.0 flexibel genoeg is om, zonder ingrijpende aanpassingen aan de basisinfrastuctuur, deze doelgroepen op termijn te bedienen. Hierbij moet rekening gehouden worden met de specifieke dynamiek, noden en wensen voor deze doelgroepen. Het meest sprekende voorbeeld is dat van leerlingen basisonderwijs, voor wie de huidige interface van Knooppunt niet geschikt is, en voor wie andere authenticatieprocedures nodig zijn. Om deze doelgroep te bedienen zal een grondige studie moeten gebeuren en de nodige interfaces op maat moeten gebouwd worden. Deze interfaces moeten op een eenvoudige manier kunnen aansluiten op de infrastructuur van Knooppunt 3.0, maar zijn hier dus niet in scope.
3.3 Cijfers Momenteel bedient Knooppunt het gros van het secundair onderwijs in Vlaanderen. Ter illustratie geven we enkele cijfers in januari 2014: • •
Aantal actieve gebruikers: +/-‐ 250.000 Aantal actieve licenties: +/-‐ 600.000 7
• •
Volume lesmateriaal: ongeveer 3 TB > 4000 pakketten lesmateriaal
3.4 Wat is Knooppunt niet? De scope en missie van Knooppunt wordt ook duidelijker door te vermelden wat Knooppunt niet is: •
•
4
Knooppunt is geen webshop: via Knooppunt wordt geen lesmateriaal verkocht, rechtstreeks noch onrechtstreeks. Knooppunt focust zich uitsluitend op distributie. Verkoop van licenties voor lesmateriaal valt uitsluitend onder de bevoegdheid van de uitgeverijen Knooppunt is geen leeromgeving: het is niet de wens en de missie van Knooppunt om zich op het terrein van leeromgevingen als Smartschool, ELOV, Moodle etc te bewegen. De strategie is om waar dat nuttig en zinvol is om samen te werken met deze partijen.
Motivatie project
De uitgeverijen hebben dit project opgestart om volgende redenen: • •
•
5
Modernisering: de applicatie is aan een modernisering toe, zowel op vlak van technologie als gebruikersvriendelijkheid Business model: Knooppunt is momenteel gebaseerd op een business model van shared revenue, waarbij per actieve licentie een klein bedrag afgestaan wordt aan de leverancier (Three Ships). De uitgeverijen wensen binnen Knooppunt 3.0 een business model te hanteren dat voor hen financieel voordeliger is, en dat hen onafhankelijk maakt van de leverancier. Ownership & IP: Knooppunt vzw wil onafhankelijkheid van de leverancier en (intellectueel) eigendomsrecht op de software.
Project
5.1 Scope De scope van Knooppunt 3.0 is in grote lijnen dezelfde als de scope van de huidige versie van Knooppunt. De blokken die in scope zijn zijn de volgende: • • • • •
Basisinfrastructuur authenticatie, gebruikersaccounts & profielen, security, logging Licentiekantoor Rapportagemodule Content Repository Kanalen websites knooppunt.net en digiportail.be
Binnen het ecosysteem Knooppunt vinden we ook nog volgende zaken: • •
Content Creatie Tool (Auteursomgeving) waarmee digitale boeken gemaakt worden Knooppunt Kiosk: native & web apps voor gebruik op tablets
8
Deze laatste 2 zaken zitten niet in scope voor deze RFP omdat ze nader overleg en studie vereisen. Deze onderwerpen worden opgenomen in secundaire projecten. Voor uitleg over deze secundaire projecten verwijzen we naar de voorgaande RFI.
5.2 Tijdslijn Het project is opgestart in november 2013 en moet klaar zijn tegen 1 februari 2015. De tijdslijn voor het volledige project verloopt als volgt: Periode nov 13 – mrt 14 15 jan 14 31 jan 14 12 feb 14 5 mrt 14 7 mrt 14 21 mrt 14 april 2014 – februari 2015
6
Fase Scopebepaling & selectie leverancier RFI uitgestuurd Deadline antwoord RFI RFP uitgestuurd Deadline antwoord RFP Verdediging door aanbieders Definitieve keuze aanbieder Bouw platform
Selectieproces leverancier
De keuze van de leverancier voor de bouw van het Knooppunt 3.0 platform wordt bepaald in 2 stappen: 1. RFI naar longlist aanbieders In een eerste stap werd een RFI uitgestuurd naar een longlist van een 10-‐tal aanbieders. Op basis van de schriftelijke voorstellen wordt een eerste selectie gemaakt, om tot een shortlist van een 4-‐tal aanbieders te komen. 2. RFP naar shortlist aanbieders Aan de shortlist van aanbieders wordt een RFP (dit document) uitgestuurd, die een gedetailleerde beschrijving bevat van de specificaties van Knooppunt 3.0. De aanbieders wordt gevraagd om een gedetailleerde offerte en uitgewerkt voorstel op te stellen, die, eenmaal geselecteerd, bindend zal zijn voor de rest van het project. Een definitieve leverancier zal geselecteerd worden op basis van: • •
7
het schriftelijke voorstel van de aanbieder, aan te leveren tegen 5 maart 2014 de presentatie en verdediging voor de stuurgroep van de leden van Knooppunt. Deze vindt plaats op 7 maart 2014. Locatie & tijdstip worden nog meegedeeld aan de aanbieders.
Evaluatiecriteria
Het voorstel zal geëvalueerd worden door de projectleider en de uitgevers (stuurgroep van Knooppunt vzw), op basis van volgende criteria: •
Evaluatie van het antwoord op de RFI
9
• • • • • • • •
Graad waarin het voorstel beantwoordt aan de vereisten Kwaliteit van de visie op de gevraagde business cases Projectaanpak Voorgesteld budget Planning Expertise van de aanbieder (project management/technisch/grafisch) Ervaring & referenties met gelijkaardige projecten Kwaliteit van de verdediging
De stuurgroep van Knooppunt vzw zal op basis van het voorstel een advies uitbrengen naar de Raad van Bestuur, die finaal beslist of de gekozen aanbieder in aanmerking komt voor de opdracht.
8
Vereisten
Dit document bouwt voor een aantal zaken verder op de vereisten beschreven in de RFI, waar nodig voor de RFP worden de vereisten in detail uitgediept..
8.1 Projectmatig, Budgettair & Samenwerkingsmodel Voor de bouw van Knooppunt 3.0 geven we de voorkeur aan een iteratieve projectaanpak, volgens een gedegen project management methodologie, waarbij gedurende het volledig traject er een continue oplevering is die gevalideerd wordt door de uitgevers en de projectopleiding. We wensen langs de kant van de aanbieder een vaste project manager, die fungeert als centraal aanspreekpunt voor dit project. Deze project manager bewaakt de kwaliteit, het budget en de timing langs de kant van de aanbieder. Voor dit project wensen we te werken op basis van een fixed price aanpak. De prijszetting moet bindend zijn, en zal ook opgenomen worden in het contract dat resulteert uit de offerte. Waar de scope onvoldoende duidelijk is moet de aanbieder dit aangeven in het voorstel, en een prijsvork voorstellen.
8.2 Architectuur De architectuur van Knooppunt 3.0 moet voldoen aan een aantal vereisten: • • • •
We verkiezen een modulaire, service oriented architectuur (SOA) De architectuur bestaat uit aparte, onafhankelijke modules met eigen functionaliteit en welomschreven verantwoordelijkheden Communicatie tussen de diverse modules verloopt via welomschreven API’s De architectuur moet opgebouwd worden volgens het 3-‐tier model: o Presentatie o Business Logica o Storage
De verschillende blokken binnen Knooppunt 3.0 zijn de volgende: •
Presentatie: o Website knooppunt.net / digiportail.be
10
•
•
o Backoffice website office.knooppunt.net Business Logica o Licentiekantoor o Licensed Content Management module o Rapportage o Logging module o Security module (rollen & toegangsrechten) Storage o Knooppunt database (accounts, licenties…) o Content Repository
De architectuur wordt hieronder schematisch voorgesteld:
8.3 Standaarden & Off-‐the-‐shelf oplossingen Waar voor bepaalde problematieken standaard oplossingen bestaan, zijn deze te verkiezen boven maatwerkoplossingen. Zo denken we aan: • oAuth voor authenticatie • CMIS-‐compliant systemen voor de content repository We vragen de aanbieder om waar mogelijk maatwerk en niet-‐standaard oplossingen tot een minimim te beperken.
8.4 Website knooppunt.net en digiportail.be Deze website is de toegangspoort voor gewone eindgebruikers tot het gebruik van Knooppunt.
11
De functionaliteit op deze website omvat: • • • • • •
Registratie & login Profielbepaling Activering van licenties Overzicht van en toegang tot geactiveerd lesmateriaal Meertaligheid (min NL en FR) Standaard CMS functionaliteit zoals: o Accountbeheer o Content beheer o Navigatie beheer
De vereisten qua interface en layout zijn de volgende: • • •
Gebruiksgemak en eenvoud staan voorop Aantrekkelijke, frisse en eigentijdse layout Responsief karakter, met 2 “breekpunten” o Desktop naar tablet o Tablet naar mobiel
We geven er de voorkeur aan om deze websites te laten implementeren a.d.h.v een standaard CMS platform (bvb. Drupal, of een gelijkaardig platform).
8.5 Backoffice In tegenstelling tot de huidige versie van Knooppunt, is het een optie om de geavanceerde gebruikers (Uitgevers, Helpdeskmedewerker, Administrator) te laten werken op een aparte website, met een meer zakelijke interface. Hier zien we 2 opties: • •
Een andere website, met een eigen URL, bvb. http://office.knooppunt.net Dezelfde website als voor de eindgebruikers, maar met een andere layout voor het beheersgedeelte (zoals op bestaande CMS’en vaak gebruikelijk is)
Het staat de aanbieder vrij om een voorstel te doen voor een van beide. Een responsief karakter is voor deze website niet per se nodig. Via deze website kunnen de gebruikers volgende functionaliteiten gebruiken: • • • • •
Beheer licenties, activatiecodes Beheer content Beheer gebruikers Helpdesk Rapportage
8.6 Licentiekantoor Het licentiekantoor is de module dat de kern omvat van Knooppunt. Via deze module kan de gebruiker:
12
• • •
Licenties beheren LicentieActivatieCodes beheren Gebruikerslicenties beheren
Deze module zorgt ook voor de beveiliging van content, zowel op de gemeenschappelijke Content Repository als op externe web servers (mits die in staat zijn met het Licentiekantoor te communiceren) Deze module bevat geen GUI, maar hoort thuis in de laag Business Logica en communiceert via API’s met de andere modules en de presentatielaag.
8.7 Licensed Content Management & Content Repository De content repository is een gemeenschappelijke opslagruimte voor digitaal lesmateriaal, aangeboden door Knooppunt aan de uitgeverijen die niet wensen te investeren in eigen infrastructuur. De Licensed Content Management module (business logica) en de Content Repository (storage) zorgen samen voor beheer en opslag van content. De Content Repository is opgedeeld in een aantal “partities”, waar elke uitgeverij zijn eigen lesmateriaal kan opslaan onafhankelijk van en onzichtbaar voor de andere uitgeverijen. De repository is via de GUI van de backoffice toegankelijk via een verkenner-‐achtige interface, waar de uitgeverij een mappenstructuur kan aanmaken en binnen een map digitaal lesmateriaal kan opladen. De uitgever heeft de mogelijkheid om een of meer bestanden op te laden. Voor meerdere bestanden wordt een zipbestand opgeladen, dat op de server uitgepakt en opgeslagen wordt. Het moet mogelijk zijn om de content ook te metadateren. Welke set metadata hiervoor relevant is moet nog verder uitgewerkt worden, maar komt aan bod binnen de RFP.
8.8 Security: rollen en toegangsrechten Deze module zorgt voor beheer van rollen en toegangsrechten voor de gebruikers.
8.9 Logging module Deze module zorgt voor de afhandeling en opslag van logberichten uit de andere modules. Het is belangrijk om diverse gebeurtenissen te loggen: • • •
Errors Waarschuwingen Info o Registratie o Inloggen en uitloggen o Activatie o Gebruik van content o …
13
Deze informatie moet via de API kunnen ingelezen worden in externe systemen, in gebruikelijke formaten zoals JSON of XML.
8.10 Rapportage module Een belangrijke vereiste in Knooppunt 3.0 is een correcte meting van het gebruik en de bijhorende rapportages, voor zowel de uitgevers als de administrator, met het oog op een transparant inzicht in gebruik en een correcte facturatie naar de uitgevers toe. De rapportagemodule leest, consolideert en verwerkt ruwe data uit de logging module. Deze rapportages staan ter beschikking van de uitgevers en de administrator van Knooppunt en kunnen gedownload worden of via API’s ingelezen worden in eigen ERP systemen. Er moet o.a. rapportage voorzien worden rond: • • • • •
Licenties GebruikersLicenties Activaties Gebruik van het lesmateriaal Gebruikersdata
(zie ook verder bij de Use Cases) Rapportages en ruwe data moeten voorzien worden: • • • •
In tabel-‐ en grafiekvorm Via export naar csv of andere formaten, zoals JSON of XML Via FTP Via een API
We vragen de aanbieder ook om na te denken over een Google Analytics-‐achtige vorm van rapportage.
8.11 API Infrastructuur Een belangrijk vereiste voor Knooppunt 3.0 is de machine-‐aanstuurbaarheid van de applicatie. Dit betekent dat er API’s of Application Programming Interfaces moeten voorzien worden, welomschreven protocollen via dewelke de diverse modules met elkaar communiceren. 8.11.1 API Set Het service-‐oriented karakter van Knooppunt 3.0 leent zich tot de opzet van een brede en rijke API. Elke use case die door een menselijke gebruiker kan uitgevoerd worden, moet ook via een API call uitgevoerd kunnen worden. Zo zien we API calls voor: • • • • • •
Registratie Inloggen Single Sign On (SSO) Activeren lesmateriaal Raadplegen lesmateriaal Beheren van Licenties, LACs, GebruikersLicenties 14
•
Etc…
We vragen de aanbieder om bij het opstellen van de offerte een zo volledig mogelijke lijst op te stellen van API functies. Tijdens het ontwikkeltraject zal deze lijst verfijnd en bijgestuurd worden. 8.11.2 Vereisten API Om de API te beveiligen willen we gebruik maken van een security key (zoals Google dat doet voor zijn API sets). Aanbevelingen voor de API zijn de volgende: • • • • •
Mogelijkheid tot beveiliging via een security key Lightweight en eenvoudig Ondersteunt SSL Goed gedocumenteerd Retourneert data in standaard formaten zoals JSON of XML
De RESTful web services van Google zijn een goed voorbeeld voor de Knooppunt API.
8.12 Domein model Hieronder geven we een beschrijving mee van het domein model, als high-‐level conceptueel model van alle entiteiten gerelateerd aan Knooppunt 3.0. Het domein model wordt voorgesteld a.d.h.v een klassendiagram in UML en een tekstuele beschrijving van de verschillende entiteiten, hun eigenschappen en onderlinge relaties.
15
8.12.1 UML Class Diagram
8.12.2 Klassen Het domein model omvat volgende klassen of types objecten: 8.12.2.1 Gebruiker Een gebruiker refereert naar een eindgebruiker op Knooppunt en bevat volgende gegevens: Attributen
16
• • • • •
ID: unieke identifier E-‐mailadres: het e-‐mailadres waarmee de gebruiker aanlogt, moet uniek zijn Voornaam Achternaam Profiel: verzameling profielgegevens, een samengesteld veld: o School o Klas o Vak
Relaties • Gebruiker is gekoppeld aan 0 of meer GebruikersLicenties • Gebruiker is gekoppeld aan 0 of meer Scholen 8.12.2.2 School Een School bevat naam-‐ en adresinformatie over de scholen in Vlaanderen, Brussel en Wallonie. De data voor een school is akomstig uit officiële scholenlijsten: • Vlaamse scholenlijst: http://ond.vlaanderen.be • Wallonië: http://www.enseignement.be • Brusselse scholen bevinden zich, afhankelijk van de taal in een van beide lijsten. Attributen • ID: unieke identifier • Instellingsnummer: het officiële instellingsnummer van de school • Naam: officiële naam • Adres: straat & huisnummer • Postcode • Gemeente • Regio: Vlaanderen, Wallonië, Brussel (?) • Bron: ond.vlaanderen.be of enseignement.be Relaties • School is gekoppeld aan 0 of meer Gebruikers 8.12.2.3 Uitgever Een Uitgever bevat data over de aangesloten uitgevers op Knooppunt. Attributen • ID: unieke identifier • Naam: officiële naam • Logo: beeld met het logo van de uitgeverij Relaties • Uitgever is gekoppeld aan 0 of meer GebruikersLicenties • Uitgever is gekoppeld aan 0 of meer Licenties • Uitgever is gekoppeld aan 0 of meer Content Packages 8.12.2.4 Licentie Een Licentie beschrijft de modaliteiten waaronder een gebruiker toegang krijgt tot een content op Knooppunt.
17
Attributen • ID: unieke identifier • ReferentieCode: code voor intern gebruik bij de uitgever • Titel: titel zoals getoond aan de gebruiker • Icoon: afbeelding zoals getoond aan de gebruiker • Taal: taal van de licentie • Omschrijving: omschrijving van de licentie • ISBN: ISBN van het boek gelinkt aan het lesmateriaal • Vak: uit lijst vakken • Methode: uit lijst methodes van de uitgever • Jaar • ProfielRestricties: bijkomende voorwaarden waaronder de gebruiker toegang krijgt tot de content: o Rol “leerkracht” verplicht o Schoolkeuze verplicht o Persoonsgegevens verplicht • Voorwaarden: tekstuele voorwaarden die de gebruiker moet accepteren om toegang te krijgen tot de content • StartActivatie: vroegste datum waarop activatie kan gebeuren • EindeActivatie: laatste datum waarop activatie kan gebeuren • LicentieDuur: duur van de licentie, momenteel 2 vormen o Aantal dagen na activatie o Tot bepaalde einddatum • ProductCode: door de uitgever gekozen 4-‐letterige code die in de LACs opgenomen wordt Relaties • Licentie is gekoppeld aan 1 Uitgever • Licentie is gekoppeld aan 0 of meer Content Packages • Licentie is gekoppeld aan 0 of meer GebruikersLicenties • Licentie is gekoppeld aan 0 of meer LACBatches 8.12.2.5 LACBatch Een LACBatch (licentie-‐activatiecode batch) groepeert een aantal LACs of licentie-‐activatiecodes, gegenereerd volgens een van de bestaande licentiemodellen. Attributen • ID: unieke identifier • Omschrijving: tekstuele omschrijving voor administratieve doeleinden • LicentieModel: een van de gangbare licentiemodellen o Aantal unieke activatiecodes o Aantal herbruikbare activatiecodes o Herbruikbare activatiecode • EindeActivatie: verloopdatum voor activatie o Kan open zijn o Kan ingesteld worden • EindeBeschikbaarheid: geldigheid voor content
18
o o
Kan overgeërfd worden uit licentie Kan ingesteld worden
Relaties • LACBatch is gekoppeld aan 1 Licentie • LACBatch is gekoppeld aan 0 of meer LACs Voor elk licentiemodel definieren we een aantal subklassen. De subklassen erven eigenschappen van LACBatch, maar hebben daarnaast ook eigen eigenschappen en gedrag. 8.12.2.5.1 AantalUniekeLACBatch Attributen • AantalCodes: aantal unieke activatiecodes 8.12.2.5.2 AantalHerbruikbareLACBatch Attributen • AantalCodes: aantal unieke activatiecodes • MaxActivaties: maximum aantal activaties per code 8.12.2.5.3 EenHerbruikbareLACBatch Attributen • MaxActivaties: maximum aantal activaties 8.12.2.6 LAC Een LAC of licentie-‐activatiecode is een code van 16 of 20 tekens die de gebruiker toelaat een licentie te activeren. Attributen • Code: reeks van 16 of 20 tekens, letters en cijfers • Status: o Ongebruikt o Gebruikt o Geblokkeerd • EindeActivatie: datum einde activatie, overgeërfd van moederobject LACBatch, maar aanpasbaar. Relaties • LAC is gekoppeld aan 1 LACBatch • LAC is gekoppeld aan 0 of meer GebruikersLicenties 8.12.2.7 GebruikersLicentie Een GebruikersLicentie bevat informatie over een licentie die geactiveerd is door een gebruiker d.m.v. een LAC. De GebruikersLicentie wordt aangemaakt bij het activeren en op status “Actief” gezet. Bij het verstrijken van de verloopdatum wordt de status op “Verlopen” gezet. De uitgeverij kan een GebruikersLicentie ook blokkeren, dan wordt de status op “Geblokkeerd” gezet. Attributen • ID: unieke identifier • ActivatieDatum • Duur: looptijd • Status:
19
o o o
Actief Verlopen Geblokkeerd
Relaties • GebruikersLicentie is gekoppeld aan 1 Licentie • GebruikersLicentie is gekoppeld aan 1 Gebruiker • GebruikersLicentie is gekoppeld aan 1 Uitgever • GebruikersLicentie is gekoppeld aan 1 LAC 8.12.2.8 Content Package Een Content Package bevat informatie over het lesmateriaal dat aangeboden wordt. Het kan bestaan uit meerdere bestanden en is het instappunt voor een gebruiker bij de toegang tot het lesmateriaal. Attributen • ID: unieke identifier • Titel • URL: URL van de content package, kan zowel: o Verwijzen naar content op de gemeenschappelijke Content Repository o Verwijzen naar een externe URL op de webserver Relaties • Content Package is gekoppeld aan 0 of meer Licenties • Content Package is gekoppeld aan 1 Uitgever
8.13 Rollen Knooppunt 3.0 moet rol-‐gebaseerde toegangscontrole ondersteunen. Gebruikers kunnen 1 of meer rollen toegekend krijgen. Elke rol heeft specfieke toegangsrechten tot bepaalde aspecten van de software. Het rollenmodel hieronder beschreven bevat overerving, m.a.w een rol die erft van een andere rol erft alle toegangsrechten van de ouder-‐rol. De rollen binnen Knooppunt 3.0 zijn de volgende: • • • • • • •
Eindgebruiker: een standaard eindgebruiker Uitgever: heeft read-‐only toegang tot informatie van de uitgever rond content, licenties, gebruikerslicenties en activatiecodes LicentieBeheerder: heeft schrijftoegang tot licenties, gebruikerslicenties en activatiecodes ContentBeheerder: heeft schrijftoegang tot content op de gemeenschappelijke content repository Uitgever-‐Administrator: heeft schrijftoegang tot alle data van de uitgever en beheert de accounts van de eigen uitgeverij Helpdeskmedewerker: heeft toegang tot de helpdeskfunctionaliteiten en kan data opzoeken over alle uitgevers heen Administrator: heeft onbeperkte toegang tot alle functionaliteiten van het platform
20
Gedurende de verdere analysefase van het project is het mogelijk dat extra rollen gedefinieerd worden en bestaande rollen verfijnd worden. 8.13.1 UML Diagram
8.14 Use Cases De functionaliteit van Knooppunt 3.0 wordt hieronder verder beschreven a.d.h.v use cases. Hieronder wordt een overzicht gegeven van de use cases in scope binnen dit project. Merk op dat enig voorbehoud moet gemaakt worden bij de detailuitwerking van de use cases. Afhankelijk
21
van de antwoorden op de gevraagde Business Cases (zie verder) en inzichten opgedaan tijdens de uitwerking van het project zullen deze use cases verder verfijnd en bijgestuurd worden. Merk tevens op dat de nummering van de use cases niet doorlopend is. Tijdens het schrijven van dit document zijn use cases samengevoegd, aangepast en verwijderd. De use cases zijn geprioritiseerd: • •
Prioriteit 1 (groen): deze use cases zijn redelijk volledig uitgeschreven Prioriteit 2 (geel): deze use cases zijn iets minder belangrijk en worden verderop beknopt toegelicht. De informatie verstrekt geeft hopelijk voldoende informatie om het project verder in te schatten.
Use cases zijn verbonden aan een Actor, de gebruiker of het systeem dat de use case uitvoert. Een actor is in dit overzicht synoniem met een rol, beschreven hierboven. We benadrukken hier dat alle use cases hieronder beschreven moeten kunnen uitgevoerd worden via een of meer API calls, zie ook de paragraaf over de API. 8.14.1 Overzicht use cases De tabel hieronder biedt een overzicht van de use cases in scope binnen Knooppunt 3.0. Legende Belangrijke use case, volledig uitgeschreven
1
Minder belangrijke use case, wordt minder in detail beschreven
2
Nr 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
ID UC-‐1.1 UC-‐1.2 UC-‐1.4 UC-‐1.5 UC-‐1.6 UC-‐1.7 UC-‐1.8 UC-‐1.9 UC-‐ 1.10 UC-‐2.1 UC-‐2.2 UC-‐2.4 UC-‐2.5 UC-‐2.6 UC-‐2.7 UC-‐2.9 UC-‐ 2.10 UC-‐ 2.12 UC-‐
Actor Eindgebruiker Eindgebruiker Eindgebruiker Eindgebruiker Eindgebruiker Eindgebruiker Eindgebruiker Eindgebruiker
Naam Registreren Inloggen Profiel wijzigen Taal wijzigen Lesmateriaal activeren Lesmateriaal raadplegen Vraag stellen aan helpdesk Status systeem bekijken
Prioriteit 1 1 2 2 1 1 2 2
Eindgebruiker LicentieBeheerder,Uitgever LicentieBeheerder,Uitgever LicentieBeheerder,Uitgever ContentBeheerder,Uitgever Uitgever Uitgever Uitgever
FAQ Raadplegen Licenties beheren LACs beheren GebruikersLicenties beheren Content beheren Rapport Licenties Rapport GebruikersLicenties Rapport gebruikersdata
2 1 1 1 1 2 2 2
Uitgever
Rapport gebruik content
2
Uitgever Uitgever-‐Administrator
Zoeken Beheer accounts eigen uitgeverij
2 2 22
20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
36
2.13 UC-‐3.1 UC-‐3.2 UC-‐3.3 UC-‐4.1 UC-‐4.2 UC-‐4.3 UC-‐4.4 UC-‐4.5 UC-‐4.6 UC-‐4.7 UC-‐4.8 UC-‐4.9 UC-‐ 4.10 UC-‐ 4.11 UC-‐ 4.12 UC-‐ 4.13 UC-‐ 4.14
Helpdeskmedewerker Helpdeskmedewerker Helpdeskmedewerker Administrator Administrator Administrator Administrator Administrator Administrator Administrator Administrator Administrator
Accounts opzoeken GebruikersLicenties opzoeken Tijdelijk inloggen als gebruiker Beheren accounts Beheren machine accounts Beheer rollen & toegangsrechten Vertalen interface Beheren content Beheren navigatie Beheren lijsten Beheren webformulieren Status monitoren
2 2 2 2 2 2 2 2 2 2 2 2
Administrator
Applicatie online/offline zetten
2
Administrator
Gebruikers contacteren
2
Administrator
Parameters configureren
2
Administrator
Rapportages raadplegen
2
Administrator
Rapportages samenstellen
2
8.14.2 Gedetailleerde beschrijving use cases Een gedetailleerde beschrijving van de individuele use cases wordt gegeven in Appendix 1.
8.15 Functionaliteit met variabele scope Enkele belangrijke functionaliteiten zijn op het moment van opstellen van deze RFP nog niet uitgeklaard, en zullen nadere studie vereisen, in samenwerking met de aanbieder. De 2 belangrijkste problematieken die nog “hangende” zijn zijn de volgende: 8.15.1 Registratieproces De registratieprocedure vormt in de huidige versie van Knooppunt een hindernis. Binnen Knooppunt 3.0 is het belangrijk om deze procedures verder te optimaliseren. De issues die momenteel op tafel liggen zijn de volgende: •
•
Gebruikersvriendelijkheid: het registratieproces is omslachtig, vergt vrij veel stappen en is foutgevoelig. Registratie van leerlingen wordt vaak onder begeleiding van een leerkracht uitgevoerd in het begin van het schooljaar en neemt doorgaans een volledig lesuur in beslag Rolbepaling: de gebruiker kan arbitrair een rol kiezen naar eigen goeddunken. Het verifiëren van een rol is op dit moment niet mogelijk. We kunnen terecht de vraag stellen of het kiezen van een rol zinvol is en een meerwaarde biedt.
23
•
Schoolkeuze: de keuze van een (of meer) school/scholen is ook een minder gebruikersvriendelijk proces.
We zien een aantal mogelijke pistes: 1. Een expliciete wens is de ondersteuning voor oAuth: We zien meer en meer dat het pure authenticatiegedeelte op platformen verloopt via populaire, gekende oAuth-‐ ondersteunde systemen (zoals Facebook, Google-‐account, Microsoft-‐account, …). We vragen de aanbieder om ondersteuning voor oAuth (en bij uitbreiding voor Single Sign On) mee te nemen in het voorstel. 2. Bulk registratie mogelijk maken via de school: a. Door het aanbieden van een bulk upload mogelijkheid aan ICT-‐coördinator en/of leerkracht b. Door te koppelen met de leerlingendatabank van een school 3. Geassisteerde registratie, waarbij de leerkracht hulpmiddelen krijgt om zijn leerlingen op een eenvoudige en snelle manier zichzelf te laten registreren. Het registratieproces komt ook als vraag terug bij de Business Cases. We vragen de aanbieder om hier grondig over na te denken en een gedegen en creatief voorstel te formuleren. 8.15.2 Schoollicentie Binnen de huidige versie van Knooppunt vormt activatie van lesmateriaal ook vaak een hindernis voor gebruikers. Een mogelijke oplossing is hiervoor de schoollicentie of groepslicentie. Het idee hierachter is vrij eenvoudig: 1. De uitgever biedt voor een bepaald lesmateriaal een licentie aan een groep (school of combinatie school en klas) aan voor een aantal gebruikers 2. De activatiecode voor deze licentie wordt gedistribueerd naar de school, waar een ICT-‐ coördinator of leerkracht de code activeert. 3. Leerlingen die gekoppeld zijn aan de groep hebben toegang tot het lesmateriaal. Belangrijke zaken om rekening mee te houden: 1. Hoe verloopt een bulk activatie? 2. Hoe kan garanties geboden worden dat een gebruiker gekoppeld is aan de correcte school en klas? De school-‐ of groepslicentie komt ook als vraag terug bij de Business Cases. We vragen de aanbieder om hier grondig over na te denken en een gedegen en creatief voorstel te formuleren.
8.16 Niet-‐functionele vereisten Naast de functionele vereisten kent Knooppunt 3.0 ook een aantal niet-‐functionele vereisten, die reeds vermeld werden in de RFI, en hieronder verder in meer detail beschreven worden. 8.16.1 Migratie data Migratie van data van het bestaande Knooppunt platform naar Knooppunt 3.0 is een cruciaal, en risicogevoelig onderdeel van het traject.
24
In grote lijnen moet een migratie gebeuren van: • • • •
3 TB aan content, onder de vorm van bestanden op een web server 250K actieve gebruikersaccounts & -‐profielen 600K gebruikerslicenties 4K licenties + bijhorende activatiecodes
Een datamigratie zal naar alle waarschijnlijkheid meerdere keren tijdens het traject voorkomen. Deze vraag vormt ook een onderdeel van de Business Cases. De aanbieder wordt gevraagd om een doordachte aanpak uit te werken. 8.16.2 Security Ondersteuning voor SSL ter bescherming van bvb gebruikersinformatie is een vereiste. Knooppunt 3.0 moet ook beschermd zijn tegen aanvallen, zoals DoS attacks. De aanbieder wordt gevraagd om hiervoor de nodige beveiligingen te voorzien. 8.16.3 Gebruikersvriendelijkheid De ervaring leert dat gebruiksgemak en gebruikersvriendelijkheid een issue is op de huidige versie van Knooppunt. Het is van het grootste belang dat hier op wordt ingezet. De aanbieder moet zich realiseren dat het doelpubliek niet “voor zijn plezier” Knooppunt bezoekt. Knooppunt wordt gebruikt binnen een schoolcontext en dat wordt niet geassocieerd met plezier. Gevolg is dat gebruikers ook minder gemotiveerd zijn om moeite te doen en bijgevolg de taken die ze moeten uitvoeren sneller opgeven. De aanbieder wordt gevraagd om best practices rond usability te volgen. 8.16.4 Platform & browseronafhankelijkheid Knooppunt 3.0 moet ondersteund worden door volgende platformen en browserversies: •
•
Platformen o Windows Vista, Windows 7, Windows 8 en hoger o Mac OS x o iOS o Android o Windows RT (tablets) Browsers, met ondersteuning voor de versies gebruikt in minstens 95% van de markt o Internet Explorer o Firefox o Chrome o Safari
Het is ook belangrijk dat een proces uitgetekend wordt waarbij compatibiliteit met toekomstige browserversies gegarandeerd wordt. 8.16.5 Schaalbaarheid Knooppunt moet schaalbaar zijn om performant te blijven bij toename van gebruiksintensiteit.
25
De architectuur moet toelaten om op te schalen (extra servers, verzwaring van servers…) bij te plaatsen zonder dat hiervoor aanpassingen aan de software nodig zijn. 8.16.6 Performantie De gekozen technologie en architectuur een hoge performantie en korte responstijden toelaten, volgens de gangbare usability normen (gewenste antwoordtijden van grootteorde 1/10 seconde). We vragen de aanbieder om te bekijken hoe performantie gemeten en getest zal worden. 8.16.7 Disaster recovery Er moet een dagelijkse backup genomen worden van alle data, zowel de database als bestanden. De architectuur moet toelaten om snel en foutloos de software en data te herstellen na een calamiteit tot de toestand van de vorige dag. Rollback van de data moet mogelijk zijn op niveau van een uitgever: als door een menselijke fout bijvoorbeeld bepaalde data verwijderd worden, moet het mogelijk zijn om voor de uitgever in kwestie data te herstellen zonder hinder voor de andere uitgeverijen. Deze vraag wordt ook behandeld in de Business Cases. 8.16.8 Test & Acceptatie platform Er moeten verschillende platformen voorzien worden voor: • • •
Testen Acceptatie Productie
8.16.9 Deployment proces De software moet gemakkelijk en foutloos te deployen zijn na updates. We vragen de aanbieder om hiervoor de nodige processen & infrastructuur te beschrijven. 8.16.10 Documentatie, handleidingen & opleidingen Er zijn nodig: • •
Technische documentie, met volledige beschrijving software (architectuur, databank schema’s…) Handleidingen & opleidingen voor de geavanceerde gebruiker, helpdeskmedewerker en administrator
8.16.11 Onafhankelijkheid Het is belangrijk om de applicatie te kunnen beheren zonder tussenkomst van de leverancier, zoals: •
•
Standaard CMS functionaliteit voor de front-‐end toepassingen: o Aanpassingen aan teksten op websites en in mails o Navigatie Configuratie van diverse parameters
26
Deze vereiste wordt ook aangehaald in de use cases, maar moet nog grondig verder uitgewerkt worden. 8.16.12 Toegankelijkheid Een vereiste is ook dat de software toegankelijk is voor gebruikers met beperkingen. Hierbij denken we aan: • •
9
Mensen met dyslexie Blinden en slechtzienden
Business Cases
Dit hoofdstuk beschrijft een aantal concrete problematieken (hierna business cases genoemd) waar gebruikers mee geconfronteerd worden binnen Knooppunt. We vragen de aanbieder om hierop een grondig antwoord formuleren rond hoe deze business cases kunnen aangepakt worden in Knooppunt 3.0. Antwoorden op de business cases zullen geëvalueerd worden door de projectleider en de leden uitgevers van Knooppunt.
9.1 Business case "Verbeterd registratieproces " Het huidige registratieproces vormt een struikelblok voor veel gebruikers, zowel leerlingen als leerkrachten. Voor Knooppunt 3.0 wensen we in te zetten op een verbeterd registratieproces, met als belangrijkste criterium gebruiksgemak. Gebruikers moeten zo eenvoudig mogelijk een account en bijhorend profiel kunnen aanmaken (of kunnen laten aanmaken), waarbij de nodige info over rol, school, klas, vakken verkregen wordt zonder dat dit een hinderpaal vormt. Een gebruiker kan zich registreren als leerkracht. Maar hoe kunnen we verifiëren of een leerkracht effectief leerkracht is? Een leerling kan zich zonder problemen als leerkracht registreren en toegang krijgen tot content en functionaliteit die niet voor hem bedoeld is. Ziet de aanbieder hiervoor een (meer) sluitende oplossing? Is een rolbepaling binnen Knooppunt überhaupt een goed idee, of zijn er hiervoor alternatieven? We vragen de aanbieder om hier creatief over na te denken en een voorstel te formuleren. Alle opties zijn bespreekbaar: zelfregistratie, geassisteerde registratie binnen school of klas, automatisering.
9.2 Business case “Frauduleuze klasaccount” We hebben in het verleden gemerkt dat in klassen een gemeenschappelijk e-‐mailadres gebruikt wordt waarmee 1 account aangemaakt wordt voor de hele klas. Bijvoorbeeld “
[email protected]” . Alle leerlingen loggen in met deze account en activeren maar 1 licentie voor meerdere leerlingen, wat tot een oneigenlijk gebruik van Knooppunt leidt en tevens een vorm van fraude is. Ziet de aanbieder een manier om deze vorm van oneigenlijk gebruik tegen te gaan?
9.3 Business case “Fusie school” De data over scholen is afkomstig uit officiële bronnen (Ministerie v. Onderwijs, zowel voor Vlaanderen als Wallonië). Het gebeurt dat scholen tot een fusie overgaan. Wat zijn de implicaties voor gebruikersprofielen gekoppeld aan deze scholen? Hoe gaat de aanbieder hier mee om?
27
9.4 Business case "Beveiligen externe content" Een leerling surft rechtstreeks vanuit zijn browser naar de methodewebsite (URL bvb http://deuitgeverij.com/specifieklesmateriaal) van een uitgeverij met de bedoeling om lesmateriaal te raadplegen. Hoe zorgt de aanbieder er voor dat de beveiliging van Knooppunt hier in werking treedt?
9.5 Business case "Schoollicentie" De schoollicentie is een nieuw gegeven binnen Knooppunt. Het is bedoeld om een licentie voor een bepaald aantal gebruikers toe te wijzen aan een school. Leerlingen die op Knooppunt ingelogd zijn en aan de school verbonden zijn krijgen zonder het expliciet invoeren van een activatiecode door een individuele leerling toegang tot het lesmateriaal. Een leerling van een andere school kan zich evenwel ook registreren als behorend tot deze specifieke school en toegang krijgen tot dit lesmateriaal, waar hij geen recht op heeft. Hoe kan de aanbieder er voor zorgen dat dit soort (al dan niet bewuste) fraude vermeden wordt?
9.6 Business case "Rollback na fout uitgever " Een uitgever is bezig met het beheren van zijn content en overschrijft per ongeluk een stuk content dat niet mocht overschreven worden. De content blijkt niet recupereerbaar zonder een rollback naar de situatie van de vorige dag. Hoe kan de aanbieder er voor zorgen dat een rollback uitgevoerd wordt zonder dat de andere uitgeverijen hierdoor hinder ondervinden?
9.7 Business case “Migratie data” Bij het in productie nemen van Knooppunt 3.0 moet een grote hoeveelheid data overgezet worden. In concreto gaat het over ongeveer 3 TB aan data. Deze data bestaat uit: • • • •
Content: bestanden, opgeslaan op filesystem, is de bulk van het volume Content metadata: database records mbt content (mappenstructuur,…) Accounts & Profielen: database records van ongeveer 250K gebruikers Licentiedata: database records ivm licenties, activatiecodes (> 600K records)
Er zal naar alle waarschijnlijkheid moeten samengewerkt worden met de huidige leverancier van Knooppunt om dit migratietraject in goede banen te leiden. Gezien de huidige leverancier voor Knooppunt 3.0 uit beeld verdwijnt vormt dit een risico. Hoe ziet de aanbieder de concrete aanpak van dit migratietraject?
10 Richtlijnen voor de aanbieders 1. Inhoud voorstel: de aanbieder wordt gevraagd om een voorstel te formuleren met een antwoord op de vragen die verder in dit document beschreven staan. 2. Informatie uit de RFI: informatie verkregen uit de RFI (bvb. bedrijfsprofiel & referenties) hoeft niet opnieuw ingediend te worden, maar wordt wel meegenomen in de finale evaluatie. 3. Formaat voorstel: de aanbieder wordt gevraagd om het voorstel op te sturen via e-‐mail. 4. Contactpersoon: het voorstel mag via e-‐mail gestuurd worden naar de projectleider, Frank Salliau, op het e-‐mailadres
[email protected]. Vragen voorafgaand aan het voorstel kunnen ook via hetzelfde e-‐mailadres gesteld worden.
28
5. Deadline indienen voorstel: een antwoord op de RFP wordt verwacht uiterlijk op woensdag 5 maart 2014 voor middernacht. Antwoorden die binnenkomen na het vermelde tijdstip komen niet in aanmerking voor evaluatie. 6. Verdediging: de verdediging van het voorstel vindt plaats op 7 maart 2014. Locatie & tijdstip worden nog meegedeeld aan de aanbieders.
11 Inhoud voorstel De aanbieder wordt gevraagd om een antwoord te geven op onderstaande onderwerpen en vragen, onder 2 vormen: 1. Tekstueel antwoord op elk punt, bij voorkeur in Word 2. Een beknopte samenvatting van de gevraagde punten in de Vendor Score Card (zie Excel bestand, als bijlage meegestuurd met deze RFP), die gebruikt zal worden om de voorstellen van de aanbieders naast elkaar te leggen
11.1 Budget • • • • •
Wat is het totaal benodigd budget voor het project? Welk samenwerkingsmodel stelt de aanbieder voor, gezien de budgettaire vereiste van een fixed price model? Graag een gedetailleerd budgetvoorstel per onderdeel en/of per fase van het project, voor de verschillende profielen ingezet in het project (PM, UX, Ontwikkeling etc). Voor welke onderdelen kan de aanbieder nog geen fixed price voorstel geven? Hoe ziet de aanbieder het samenwerkingsmodel voor deze onderdelen?
11.2 Planning • •
•
Doorlooptijd o Hoe ziet de aanbieder de doorlooptijd van het volledige project? Gefaseerd karakter o In welke fases wordt het project opgedeeld? o Hoe lang duurt elke fase? o Hoe worden de fases geprioritiseerd? Gelieve een detailplanning op te geven voor het project
11.3 Projectaanpak 11.3.1 Projectaanpak • Welke methodologie stelt de aanbieder voor? • Waarom is deze methodologie bij uitstek geschikt voor dit project? 11.3.2 Communicatie • Communicatiestructuur o Welke communicatiekanalen worden voorzien binnen het project? o Wie is aanspreekpunt bij de aanbieder? Projectleider, ontwikkelaars, grafici? o Hoe verloopt de communicatie tussen aanbieder, projectleider en uitgeverijen? • Statusrapportering o Hoe en in welke vorm wordt de status van het project gerapporteerd? o Hoe frekwent?
29
•
o Via welke kanalen? Vergaderingen o Welke vergaderingen worden er voorzien? o Hoe frekwent? o Wie wordt geacht aanwezig te zijn? o Waar worden ze gehouden?
11.3.3 Testplan • Aanpak o Hoe pakt de aanbieder het testen aan? o Is er een testmethodologie? o Zijn er testscenario’s? Zo ja, hoe worden die opgemaakt? o Zijn er dedicated testers? • Rol klant o Hoe ziet de aanbieder de rol en het engagement van de klant (in casu projectleider & uitgeverijen) in het testproces? 11.3.4 Acceptatieplan • Aanpak o Hoe verloopt het acceptatieproces? o Wie accepteert releases? o Hoeveel tijd wordt voorzien voor acceptatie? • Rol klant o Hoe ziet de aanbieder de rol en het engagement van de klant (in casu projectleider & uitgeverijen) in het acceptatieproces? 11.3.5 Releaseplan • Aanpak o Hoe verloopt het releaseproces? o Worden er release notes voorzien? Zo ja, onder welke vorm en waar worden die gedistribueerd? • Rol klant o Hoe ziet de aanbieder de rol en het engagement van de klant (in casu projectleider & uitgeverijen) in het releaseproces? 11.3.6 Integratie met 3de partijen • Aanpak: hoe verloopt communicatie en samenwerking met externe partijen (bvb. uitgeverijen, schoolplatformen) die informatie willen uitwisselen via de Knooppunt API’s?
11.4 Architectuur & Technologie 11.4.1 Architectuur • Hoe ziet de architectuur voor het platform er uit? 11.4.2 Database(s) • Welke technologieën wordt voorzien voor de database(s)? • Gelieve voor de database(s) een entity-‐relationship model op te maken.
30
11.4.3 Website knooppunt.net/digiportail.be • Welk CMS voorziet de aanbieder? • Wat is de verhouding maatwerk tov het off-‐the-‐shelf product dat nodig is volgens de vereisten? 11.4.4 Backoffice • Welk CMS voorziet de aanbieder? • Wat is de verhouding maatwerk tov het off-‐the-‐shelf product dat nodig is volgens de vereisten? 11.4.5 Licensed Content Management • Welk systeem/technologie voorziet de aanbieder voor deze module? 11.4.6 Content Repository • Welk systeem/technologie voorziet de aanbieder voor de opslag van content? Is er een off-‐the-‐shelf product dat hiervoor in aanmerking komt? • Wat is de verhouding maatwerk tov het off-‐the-‐shelf product dat nodig is volgens de vereisten? 11.4.7 Licentiekantoor • Welk systeem/technologie voorziet de aanbieder voor deze module? 11.4.8 Authenticatie • Welk systeem/technologie voorziet de aanbieder voor deze module? • Hoe is de aanpak van de ondersteuning voor standaard protocols zoals oAuth? 11.4.9 • • •
Logging Welk systeem/technologie voorziet de aanbieder voor deze module? In welke formaten wordt gelogd? Wat zijn de verschillende niveaus waarop wordt gelogd?
11.4.10 Rapportage • Welk systeem/technologie voorziet de aanbieder voor deze module? Is er een off-‐the-‐ shelf product dat hiervoor in aanmerking komt? • Wat is de verhouding maatwerk tov het off-‐the-‐shelf product dat nodig is volgens de vereisten? • Via welke kanalen worden rapporten uitgeleverd? • In welke formaten zijn rapporten beschikbaar? 11.4.11 API • Welk type API stelt de aanbieder voor? (REST/SOAP/andere…) en waarom? • Hoe wordt de API beveiligd? • Gelieve een lijst te voorzien van API calls die nu reeds gedefinieerd kunnen worden. • Gelieve een voorbeeld te voorzien van een concrete API functie.
31
11.5 Business cases We vragen de aanbieder om op elk van de business cases, beschreven in Hoofstuk 9, een uitgebreid antwoord te formuleren. Graag een visie op aanpak, technologische implicaties, risico’s en onduidelijkheden.
11.6 Niet-‐functionele vereisten 11.6.1 • • •
Migratie data Wat is de aanpak voor de migratie van de grote volumes data? Wat zijn volgens de aanbieder de “juiste” momenten om data te migreren? Hoe beperkt de aanbieder de risico’s bij dit proces?
11.6.2 Security • Hoe garandeert de aanbieder beveiliging & bescherming tegen hacking? 11.6.3 Gebruikersvriendelijkheid • Wat is de aanpak (methodologie/best practices) hanteert de aanbieder op het vlak van usability? Worden bvb. gebruikerstests voorzien? • Hoe en op welke momenten in het project wordt usability gevalideerd? • Hoe ziet de aanbieder de rol van de projectleiding en de uitgeverijen in dit proces? 11.6.4 Platform & browser-‐onafhankelijkheid • Welke gangbare platformen en browserversies moeten volgens de expertise van de aanbieder ondersteund worden? • Hoe wordt de compatibiliteit getest? • Hoe wordt compatibliteit met toekomstige versies gegarandeerd voor de komende jaren? 11.6.5 Schaalbaarheid • Wat is de aanpak rond een schaalbare architectuur? • Welke garanties kan de aanbieder leveren rond de vlotte schaalbaarheid van het platform? 11.6.6 Performantie • Hoe wordt performantie gemeten en getest? • Wat zijn mitigerende maatregelen bij een ondermaatse performantie? 11.6.7 Disaster Recovery • Wat is de aanpak rond disaster recovery? • Welke garanties kan de aanbieder leveren om een rollback van data te garanderen per uitgever zonder dat andere uitgevers getroffen worden? 11.6.8 Test & Acceptatieplatform • Welke test-‐ & acceptatiestructuur voorziet de aanbieder? (development, test, preproductie..) • Wie heeft toegang tot welk platform? • Worden deze platformen gehost bij de aanbieder of bij een externe partij?
32
11.6.9 Deployment proces • Wat is de aanpak rond deployment? • Heeft de aanbieder geautomatiseerde deployment instrumenten? Zo ja, welke? 11.6.10 Documentatie, handleidingen & opleidingen • Wat is de aanpak rond het schrijven van documentatie & handleidingen? o In-‐house of uitbesteed? o Onder welke vorm? o In welke fases van het project? • Wat is de aanpak rond trainingen? o In-‐house of uitbesteed? o Hoeveel tijd wordt voorzien voor training? o Voor welke onderdelen voorziet de aanbieder training? 11.6.11 Onafhankelijkheid • Op welke manier garandeert de aanbieder onafhankelijkheid en een beheerbaarheid van de applicatie door Knooppunt vzw zonder tussenkomst van de aanbieder? • Wat zijn de grenzen hiervan? 11.6.12 Toegankelijkheid • Wat is de aanpak rond toegankelijkheid van het platform? • Door welke instanties wordt dit gevalideerd?
11.7 Competenties & tarieven (deze vragen zijn niet in de Vendor Score Card opgenomen) •
•
Graag CV's van de teamleaden die de aanbieder voor dit project wenst in te zetten. Indien de aanbieder deze reeds geleverd heeft bij de RFI, dan hoeft hij deze niet meer opnieuw mee te sturen. Vendor Rate Card: gelieve in de excel “VendorRateCard.xlsx” in bijlage de uurtarieven te noteren voor de verschillende profielen die de aanbieder wenst in te zetten.
11.8 Technische vereisten (deze vragen zijn niet in de Vendor Score Card opgenomen) We vragen de aanbieder om de vereisten voor de serverinfrastructuur in kaart te brengen, t.b.v de hosting partij: • • • • •
Type servers Operating System Server Software Grootte diskruimte Benodigd geheugen
33
