Knooppunt 3.0 – RFI
Frank Salliau 17 januari 2014 V1.1
1
Historiek V1.0 V1.1
2 januari 2014 9 januari 2014
Eerste draft Aanpassingen na feedback Deloitte
1 Over dit document ...................................................................................................................................................... 4 2 Geheimhoudingsclausule ......................................................................................................................................... 5 3 Achtergrond & Context ............................................................................................................................................. 5 3.1 Historiek & Missie .............................................................................................................................................. 5 3.2 Doelgroepen ......................................................................................................................................................... 6 3.3 Cijfers ....................................................................................................................................................................... 6 3.4 Wat is Knooppunt niet? ................................................................................................................................... 7 4 Motivatie project ......................................................................................................................................................... 7 5 Project .............................................................................................................................................................................. 7 5.1 Scope ........................................................................................................................................................................ 7 5.2 Tijdslijn ................................................................................................................................................................... 8 6 Selectieproces leverancier ...................................................................................................................................... 8 7 Evaluatiecriteria .......................................................................................................................................................... 8 8 Richtlijnen voor de aanbieders ............................................................................................................................. 9 9 Inhoud voorstel ............................................................................................................................................................ 9 9.1 Informatie over de aanbieder ....................................................................................................................... 9 9.1.1 Contactgegevens ......................................................................................................................................... 9 9.1.2 Bedrijfsinformatie ..................................................................................................................................... 9 9.1.3 Activiteiten .................................................................................................................................................... 9 9.1.4 Personeel & Competenties ..................................................................................................................... 9 9.1.5 Projectaanpak ............................................................................................................................................ 10 9.1.6 Motivatie ...................................................................................................................................................... 10 9.2 Functionele informatie ................................................................................................................................... 10 9.2.1 Algemeen ..................................................................................................................................................... 10 9.2.2 Specifieke business cases ..................................................................................................................... 10
2
10 Appendix 1: Functionele vereisten ................................................................................................................. 12 10.1 Inleiding ............................................................................................................................................................. 12 10.2 Rollen .................................................................................................................................................................. 12 10.2.1 Eindgebruikers ....................................................................................................................................... 12 10.2.2 Geavanceerde gebruikers .................................................................................................................. 12 10.2.3 Helpdeskmedewerker ......................................................................................................................... 12 10.2.4 Administrator ......................................................................................................................................... 12 10.3 Gebruikersscenario’s huidige versie ..................................................................................................... 13 10.3.1 Leerling & leerkracht ........................................................................................................................... 13 10.3.2 Uitgever ..................................................................................................................................................... 13 10.3.3 Administrator ......................................................................................................................................... 14 10.3.4 Helpdeskmedewerker ......................................................................................................................... 15 10.4 Functionele architectuur ............................................................................................................................ 15 10.4.1 Basislaag .................................................................................................................................................... 15 10.4.2 Modules ..................................................................................................................................................... 15 10.5 Kanalen ............................................................................................................................................................... 16 10.5.1 Huidige situatie ...................................................................................................................................... 16 10.5.2 Kanalen in scope .................................................................................................................................... 16 10.5.3 Kanalen niet in scope ........................................................................................................................... 16 10.6 Website knooppunt.net en digiportail.be ............................................................................................ 17 10.6.1 Meertaligheid .......................................................................................................................................... 17 10.6.2 Responsief karakter ............................................................................................................................. 17 10.6.3 Registratie & Login ............................................................................................................................... 17 10.6.4 Profielbepaling ....................................................................................................................................... 18 10.7 Licentiekantoor .............................................................................................................................................. 18 10.7.1 Beveiliging lesmateriaal ..................................................................................................................... 18 10.7.2 Licenties .................................................................................................................................................... 19 10.7.3 Licentieactivatiecodes (LAC) en licentiemodellen ................................................................. 20
3
10.8 Content Repository ....................................................................................................................................... 21 10.9 Rapportage ....................................................................................................................................................... 21 10.10 Machine-‐aanstuurbaarheid .................................................................................................................... 22 10.10.1 Modulair karakter .............................................................................................................................. 22 10.10.2 Koppeling met externe systemen ................................................................................................ 22 11 Appendix 2: Niet-‐functionele vereisten ........................................................................................................ 23 11.1 Migratie content ............................................................................................................................................. 23 11.2 Secure web applicatie .................................................................................................................................. 23 11.3 Gebruikersvriendelijkheid ......................................................................................................................... 23 11.4 Platform, device & browser onafhankelijkheid ................................................................................ 23 11.5 Schaalbaarheid & performantie .............................................................................................................. 23 11.6 Backup & Disaster recovery ...................................................................................................................... 23 11.7 Monitoring ........................................................................................................................................................ 24 11.8 Loggen ................................................................................................................................................................ 24 11.9 Test & Acceptatie platform ........................................................................................................................ 24 11.10 Deployment ................................................................................................................................................... 24 11.11 Documentatie & handleidingen ............................................................................................................ 24 11.12 Beheerbaarheid ........................................................................................................................................... 24 11.13 Uitbreidbaarheid ......................................................................................................................................... 24 11.14 Toegankelijkheid (Accessibility) .......................................................................................................... 24
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 wordt naar een 10-‐tal software bouwers, hierna aanbieders genoemd, deze RFI (Request For Information) uitgestuurd. Hosting en infrastructuur maakt geen onderdeel uit van deze RFI, enkel de bouw van het platform. Van de geïnteresseerde aanbieder wordt verwacht dat hij een antwoord biedt op de vragen gesteld in deze RFI.
4
De RFI omvat volgende elementen: • • • • • • •
2
Geheimhoudingsclausule Achtergrond & Context Knooppunt Richtlijnen voor de aanbieders Omschrijving van het selectieproces Verwachte inhoud van het voorstel Functionele vereisten Niet-‐functionele vereisten
Geheimhoudingsclausule
De informatie vervat in dit document is confidentieel en eigendom van Knooppunt vzw. Bij het accepteren van deze RFI gaat de aanbieder akkoord met volgende voorwaarden: (Tekst met NDA voorwaarden invoegen, tekst te bekomen bij Evi/Kris/Jef)
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.
5
In 2010 waren andere educatieve uitgeverijen ook geinteresseerd om in te stappen in dit initiatief, wat leidde tot de oprichting van Knooppunt vzw. 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 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 kan 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:
6
• • • •
Aantal actieve gebruikers: +/-‐ 250.000 Aantal actieve licenties: +/-‐ 600.000 Volume lesmateriaal > 1 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: Knooppunt vzw wil onafhankelijkheid van de leverancier en 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. Zie Appendix 1 voor uitleg. De blokken die in scope zijn zijn de volgende: • • • • •
Basisinfrastructuur authenticatie, gebruikersaccounts & profiele, security, logging Licentiekantoor Rapportagemodule Content Repository Kanalen websites knooppunt.net en digiportail.be
Binnen het ecosysteem Knooppunt vinden we ook nog volgende zaken:
7
• •
Content Creatie Tool (Auteursomgeving) waarmee digitale boeken gemaakt worden Native & web apps voor gebruik op tablets
Deze laatste 2 zaken zitten niet in scope voor deze RFI omdat ze nader overleg en studie vereisen. Deze onderwerpen worden opgenomen in secundaire projecten. In Appendix 1 worden ze wel toegelicht.
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 2013 – maart 2014 april 2014 – februari 2015
6
Fase Scopebepaling & selectie leverancier 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 wordt op een RFI (dit document) uitgestuurd naar een longlist van aanbieders (een 10-‐tal). Op basis van de schriftelijke voorstellen wordt een eerste selectie gemaakt, om tot een shortlist van 3 aanbieders te komen. 2. RFP naar shortlist aanbieders Aan de shortlist van aanbieders wordt een RFP 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 de presentatie en verdediging voor de stuurgroep van de leden van Knooppunt
Evaluatiecriteria
Het voorstel zal geëvalueerd worden door de projectleider en de uitgevers (stuurgroep van Knooppunt vzw), op basis van volgende criteria: • • • •
Graad waarin het voorstel beantwoordt aan de vereisten Appreciatie van de visie op de gevraagde business cases Expertise van de aanbieder (project management/technisch/grafisch) Ervaring & referenties met gelijkaardige projecten
8
8
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. Formaat voorstel: de aanbieder wordt gevraagd om het voorstel op te sturen via e-‐mail onder de vorm van een PDF-‐document of een Word document. 3. 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. 4. Deadline indienen voorstel: een antwoord op de RFI wordt verwacht uiterlijk op 31 januari 2014 voor middernacht. Antwoorden die binnenkomen na 31 januari 2014 komen niet in aanmerking voor evaluatie.
9
Inhoud voorstel
De aanbieder wordt gevraagd een antwoord te geven op volgende onderwerpen en vragen.
9.1 Informatie over de aanbieder 9.1.1 • •
Contactgegevens Naam & functie contactpersoon bij de aanbieder Telefoon, e-‐mail, adres contactpersoon
9.1.2 •
Bedrijfsinformatie Basisinformatie over het bedrijf (bedrijfsnaam, adres, rechtsvorm, jaar oprichting, website) Bedrijfsstructuur (moederbedrijf, consortium, eventuele joint ventures) Bedrijfsgrootte (jaarlijkse omzet, solvabiliteit)
• • 9.1.3 • • • •
Activiteiten Welke diensten en producten biedt de aanbieder aan? In welke sectoren is de aanbieder actief? Klantenportfolio (belangrijkste klanten, aard projecten) Ervaring & referenties gelijkaardige projecten o Naam en omschrijving project o Opdrachtgever o Contactpersoon bij opdrachtgever (naam, functie, telefoon, e-‐mail)
9.1.4 • • •
Personeel & Competenties Totaal aantal personeelsleden Competenties in huis / outsourcing? (welke profielen, verhouding in house/uitbesteed) Voor projectleider, technische staf en grafici: o Niveau ervaring (senior/junior) o Achtergrond & opleiding o Relevante certifiëringen/trainingen Expertise in welke technologieën? Wordt aan Research & Development gedaan? (hoeveel, op welke vlakken?)
• •
9
9.1.5 • • •
Projectaanpak Project management skills (projectgrootte, project type) Project management methodologie (welke, certifiëringen) Samenwerkingsmodel (fixed price, time & material, andere)
9.1.6 •
Motivatie Wat zijn de USP’s om als aanbieder in aanmerking te komen voor dit project?
9.2 Functionele informatie Op basis van de functionele vereisten omschreven in Appendix 1 wordt de aanbieder gevraagd een antwoord te bieden op volgende onderwerpen en vragen: 9.2.1 • •
•
• •
Algemeen Een schematische voorstelling en tekstuele omschrijving van de globale architectuur, rekening houdend met zowel de functionele als niet-‐functionele vereisten Welke technologie(ën) word(en) gekozen voor welke onderdelen van de software? Geef hierbij een: o motivatie voor de keuze van de technologie o inschatting van het risico dat de keuze met zich meebrengt op lange termijn, naar upgrades en onderhoud toe Worden er standaard 3rd party componenten gebruikt? Geef hierbij een o motivatie voor de keuze o een overzicht van de implicaties hiervan (licenties, support, upgrades) Toelichting op de keuzes Hoe kan het risico op vendor lock-‐in beperkt worden door de gemaakte keuzes? Een ruwe inschatting van de kost voor de bouw van het platform. Een gedetailleerde kostenstructuur zal gevraagd worden in de RFP.
9.2.2 Specifieke business cases De aanbieder wordt gevraagd om een visie te geven op een de hieronder opgesomde problematieken, die toegelicht worden in Appendix 1 en 2. Voor elk onderwerp wordt gevraagd om (in grote lijnen) op een schematische en/of tekstuele manier toelichting te geven bij de visie op de aanpak van elk probleem. 9.2.2.1 Machine-‐aanstuurbaarheid Hoe ziet de aanbieder de machine-‐aanstuurbaarheid van de software? Wat zijn de mogelijke technische oplossingen? Wat zijn mogelijke risico’s en beperkingen waar rekening mee moet gehouden worden? 9.2.2.2 Registratie & profielbepaling Hoe ziet de aanbieder de registratieprocedure en profielbepaling? Graag een toelichting via enkele wireframes. 9.2.2.3 Single Sign On Hoe ziet de aanbieder de manier waarop Single Sign On verzorgd kan worden? 9.2.2.4 Meertaligheid Hoe ziet de aanbieder de oplossing van meertaligheid in de software?
10
9.2.2.5 Beveiliging content Rekening houdend met de vereiste dat lesmateriaal zowel op de centrale content repository als op externe webservers geplaatst kan worden, hoe ziet de aanbieder de technische oplossing op beveiliging van dit lesmateriaal? 9.2.2.6 Migratie van data Hoe ziet de aanbieder de aanpak van de migratie van de omvangrijke hoeveelheid data van de huidige versie van Knooppunt naar de nieuwe versie?
11
10 Appendix 1: Functionele vereisten 10.1 Inleiding Knooppunt 3.0 is een webgebaseerde toepassing waarmee digitaal lesmateriaal van educatieve uitgeverijen op een beveiligde manier gedistribueerd wordt naar eindgebruikers. De uitgeverijen plaatsen hun digitaal lesmateriaal op een beveiligde omgeving en voorzien deze van een licentie via dewelke eindgebruikers toegang kunnen krijgen. De eindgebruiker is gemachtigd om gedurende een bepaalde periode lesmateriaal te raadplegen na activatie van een licentie d.m.v. een licentieactivatiecode (LAC). Deze codes worden door de uitgeverijen verspreid via de (papieren) schoolboeken, via e-‐mail of via andere wegen aan de eindgebruiker die recht hebben op toegang tot het lesmateriaal. Bij het aanmelden op Knooppunt krijgt de eindgebruiker een overzicht van het lesmateriaal waarvoor hij een actieve licentie heeft. Via dit overzicht kan hij doorklikken naar het lesmateriaal in kwestie. Het lesmateriaal op zich staat los van en maakt geen deel uit van Knooppunt. De uitgeverij bepaalt zelf hoe het lesmateriaal er uit ziet en hoe het zich gedraagt. De enige voorwaarde voor het lesmateriaal is dat het kan geopend worden in een browser.
10.2 Rollen We onderscheiden volgende rollen of types gebruikers: 10.2.1 Eindgebruikers Onder eindgebruiker verstaan we het gros van de gebruikers die naar Knooppunt komen om lesmateriaal te raadplegen. 10.2.2 Geavanceerde gebruikers Onder de geavanceerde gebruikers verstaan we de medewerkers van de uitgeverijen die o.a. volgende taken uitvoeren: • • •
Content opladen Licenties & licentiecodes aanmaken Rapportages raadplegen
Vanzelfsprekend, maar cruciaal in dit gegeven is dat uitgeverijen enkel toegang krijgen tot data van de eigen uitgeverij. 10.2.3 Helpdeskmedewerker De helpdeskmedewerker behandelt de vragen die via de mailbox van de helpdesk binnenkomen en heeft daarvoor een aantal instrumenten ter beschikking om informatie op te zoeken. 10.2.4 Administrator De administrator heeft toegang tot alle beheerstaken op Knooppunt. De exacte omschrijving van deze taken wordt uitgeschreven in de RFP, maar zal zeker volgende taken omvatten: • •
Gebruikersbeheer Rapportages raadplegen
12
•
CMS functionaliteit (teksten/vertalingen)
10.3 Gebruikersscenario’s huidige versie Hieronder beschrijven we de meest gangbare gebruiksscenario’s van Knooppunt per type gebruiker. De scenario’s beschrijven de situatie zoals ze bestaat in de huidige versie van Knooppunt en zijn bedoeld om een beeld te krijgen van de werking van Knooppunt, niet als exacte vereiste. Binnen Knooppunt 3.0 zullen de scenario’s om redenen van gebruikersvriendelijkheid, efficientie en andere vereisten afwijken van wat hieronder beschreven wordt. 10.3.1 Leerling & leerkracht Een leerling of leerkracht (hierna gebruiker genoemd) bezoekt Knooppunt om digitaal lesmateriaal te raadplegen. Het gebruikersscenario verloopt als volgt: 1. Bij het eerste bezoek registreert de gebruiker zich: a. Hij vult zijn e-‐mailadres in en een zelfgekozen wachtwoord b. De gebruiker vult zijn profiel aan: • Voornaam en achternaam • Aanduiding van de school (of scholen) waar hij les volgt of geeft via een zoekformulier op postcode en/of naam van de school c. Na het invullen van een CAPTCHA en acceptatie van de voorwaarden wordt een bevestigingsmail gestuurd naar het ingevulde e-‐mailadres. d. De bevestigingsmail bevat een hyperlink waarmee de gebruiker zijn account kan bevestigen.. e. Eenmaal de gebruiker op de activatielink klikt is hij ingelogd op Knooppunt 2. Bij een herhaald bezoek logt de gebruiker in met zijn e-‐mailadres en wachtwoord. 3. Indien de gebruiker zijn wachtwoord vergeten is, wordt een mail verzonden naar het e-‐ mailadres met een link waarmee de gebruiker eenmalig toegang krijgt tot Knooppunt en zijn wachtwoord kan wijzigen 4. Eenmaal ingelogd, activeert de gebruiker de licentie van het lesmateriaal door het invoeren van een licentie-‐activatiecode. Deze licentie-‐activatiecode vindt hij in het schoolboek dat bij het lesmateriaal hoort of wordt (voor leerlingen) via de leerkracht verkregen. 5. Na acceptatie van de voorwaarden wordt de licentie van het lesmateriaal geactiveerd en heeft de gebruiker toegang tot het lesmateriaal gedurende de periode gedefinieerd in de licentie. 6. Via de link “Mijn lesmateriaal” krijgt de gebruiker een overzicht van het lesmateriaal waarvoor hij een actieve licentie heeft. 7. Klikken op de link in het overzicht opent het lesmateriaal in kwestie. Het staat de aanbieder vrij om bovenstaand scenario zelf uit te proberen via www.knooppunt.net of www.digiportail.be. 10.3.2 Uitgever 10.3.2.1 Content beheren 1. De uitgever logt in met zijn e-‐mailadres en wachtwoord
13
2. Via de link “Content beheren” wordt de uitgever doorverwezen naar de content repository (in de huidige versie ook CDS genoemd, Content Distribution System), waar het lesmateriaal opgeslagen wordt 3. Via een mappenstructuur navigeert de uitgever naar de plaats waar de content opgeladen moet worden 4. Desgewenst maakt de uitgever een of meer nieuwe mappen aan 5. De uitgever laadt een zip-‐bestand op, dat op de server uitgepakt en opgeslagen wordt 10.3.2.2 Licentiebeheer De uitgever logt in met zijn e-‐mailadres en wachtwoord en navigeert naar het onderdeel licentiebeheer. Hier kan hij: 1. Zoeken naar licenties, op basis van een aantal zoekvelden a. De lijst met zoekresultaten wordt getoond b. Hij heeft de mogelijkheid om licenties te wijzigen, te verwijderen, de inhoud te wijzigen of bijhorende licentie-‐activatiecodes te beheren 2. Een nieuwe licentie aan te maken via een webformulier 3. Binnen een licentie nieuwe inhoud te selecteren (afkomstig uit het CDS, of een link naar lesmateriaal op een eigen web server) 4. Binnen een licentie activatiecodes te beheren via a. Een overzicht van bestaande codes b. Mogelijkheid om nieuwe codes te genereren op basis van een aantal modellen (zie verder voor een beschrijving van de modellen) 10.3.2.3 Rapportages raadplegen De uitgever logt in met zijn e-‐mailadres en wachtwoord en navigeert naar het onderdeel statistieken. Hier kan hij een aantal rapportages raadplegen: • • • • • • • • • •
Maandoverzicht aantal actieve activaties Detailoverzicht activaties Aantal licenties en activaties per uitlevergebied Overzicht aantal gebruikers Looptijd van activaties Overzicht van aantallen activaties Analyse Mijn profiel Gebruik van content Gebruikersgegevens ophalen Licentiegegevens ophalen
Voor de aanbieder is het belangrijk te weten dat voor Knooppunt 3.0 deze rapportages opnieuw zullen gedefinieerd worden in de RFP. 10.3.3 Administrator 10.3.3.1 Rapportages raadplegen 1. Na inloggen navigeert de administrator naar het onderdeel “Statistieken” 2. De administrator downloadt een of meer rapportages. De meest courante rapportage is deze van de actieve licenties over de uitgeverijen heen voor een bepaalde periode, die gebruikt wordt voor de facturatie van Knooppunt vzw naar de uitgeverijen
14
10.3.4 Helpdeskmedewerker 1. Na inloggen navigeert de helpdeskmedewerker naar het onderdeel “Helpdesk”. 2. Via een zoekformulier kan hij volgende zaken opzoeken om problemen te behandelen: a. Gebruikers, op e-‐mailadres b. Licenties, via i. licentiecode ii. licentie-‐activatiecode meegegeven in de mail aan de helpdesk
10.4 Functionele architectuur
Legende • • •
Beige: modules in scope. Paars: modules buiten scope, maar die nader onderzoek vereisen en in secundaire project(en) opgenomen worden Wit: externe systemen buiten, maar die wel informatie uitwisselen met Knooppunt
Merk op dat in bovenstaande figuur voor de overzichtelijkheid niet alle datastromen (pijltjes) weergegeven zijn. 10.4.1 Basislaag De onderste laag in het diagram bevat een aantal basale, doch, zeer belangrijke functionaliteiten zoals: • • • •
Authenticatie van gebruikers Toegang tot gebruikersprofielen Beveiliging (role-‐based security): wie heeft toegang tot welke functionaliteit? Logging: opslaan van data over gebruik, activaties etc.
10.4.2 Modules • Kanalen: de eindgebruiker zal Knooppunt benaderen via een aantal kanalen, zie 10.5
15
•
• •
•
Het Licentiekantoor is de meest belangrijke module binnen Knooppunt. Deze module controleert de toegang van de gebruiker tot de content, volgens het licentiemodel gekozen door de uitgeverij. Het Content Repository (CR) is een gemeenschappelijke opslagplaats voor content die de uitgeverij wenst aan te bieden op Knooppunt. De Rapportagemodule leest, consolideert en verwerkt ruwe data uit de logging module. Deze rapportages staan ter beschikking van de uitgeverij en de administrator van Knooppunt en kunnen gedownload worden of via API’s ingelezen worden in eigen ERP systemen. Content Creatie Tool (Auteursomgeving): deze module maakt in se geen onderdeel uit van het Knooppunt ecosysteem, maar is er nauw aan gelieerd. De Content Creatie Tool laat de uitgever toe om content aan te maken, deze te deployen naar het CR of naar eigen webservers en te beveiligen via het licentiekantoor. Deze module is niet in scope binnen deze RFI, maar het staat de aanbieder vrij om hieromtrent een visie te geven binnen het antwoord op de RFI.
10.5 Kanalen 10.5.1 Huidige situatie Op dit moment worden de gebruikers van Knooppunt bediend via een veelheid aan kanalen: • • •
Websites knooppunt.net / digiportail.be (2) Webapps Knooppunt Kiosk/ Digiportail Kiosk (2) Native apps Knooppunt Kiosk/Digiportail Kiosk voor iOS/Android/Windows (2 x 3)
Het aanbieden van het geheel van kanalen uit bovenstaande lijst impliceert het ontwikkelen en onderhouden van 10 platformen. Dit is een dure en complexe zaak en noopt tot vereenvoudiging. 10.5.2 Kanalen in scope We nemen voor deze RFI enkel de website binnen scope: www.knooppunt.net / www.digiportail.be 10.5.3 Kanalen niet in scope Via de Knooppunt kiosk worden zgn “bordboeken” aangeboden. Dit zijn digitale boeken die verrijkt zijn met extra lagen (bijvoorbeeld voor het tonen van oplossingen) en die via een zgn. “bordboekenplayer” persoonlijke verrijkingen en notities toelaten. Bordboeken worden zowel via een klassikale oplossing als via een individuele tablet-‐oplossing aangeboden. Vooral deze laatste oplossing, bestaande uit een aantal native apps, is onderhevig aan een groot aantal problemen, en wordt door de uitgevers in vraag gesteld als duurzame oplossing. Om de gangbare markt van tablets en mobiele toestellen te bedienen moeten per taal immers 3 verschillende apps ontwikkeld worden: één voor iOS, één voor Android en één voor Windows devices. Dit zorgt voor een hoge ontwikkel-‐ en onderhoudskost. De native apps binnen Knooppunt ondervinden daarnaast ook stabiliteitsproblemen. De huidige leverancier heeft niet “van nature” de nodige expertise in huis om op een kwalitatieve manier native apps te ontwikkelen. Ook het uitrollen van de diverse apps (vooral in de App Store van Apple) verloopt
16
moeizaam en zorgt voor vertragingen. De uitgevers stellen zich terecht de vraag of het gebruik van native apps een duurzame oplossing is naar de toekomst toe. Deze kanalen vereisen dus nader overleg en worden behandeld in een secundair, parallel project. Het staat de aanbieder evenwel vrij om over deze tabletoplossingen een visie te formuleren in het antwoord op deze RFI.
10.6 Website knooppunt.net en digiportail.be Deze websites vormen de belangrijkste kanalen voor toegang tot Knooppunt. 10.6.1 Meertaligheid Knooppunt moet beschikbaar zijn in zowel het Nederlands via de website www.knooppunt.net en het Frans via www.digiportail.be . De taal van de interface moet kunnen ingesteld worden door de gebruiker. Een preset van de taal wordt automatisch gemaakt: • •
Surfen naar www.knooppunt.net leidt tot een automatische taalkeuze voor Nederlands Surfen naar www.digiportail.be leidt tot een automatische taalkeuze voor Frans
In de marge hiervan moet het systeem open zijn voor een uitbreiding naar andere talen, en een eenvoudige manier voorzien worden om de interface te vertalen zonder tussenkomst van de leverancier. 10.6.2 Responsief karakter De website moet responsief zijn, m.a.w. zich aanpassen aan het toestel waarop deze getoond wordt. Hierbij zijn er 2 “breekpunten”, waarop de site zich aanpast. • •
Desktop naar tablet Tablet naar mobiel
10.6.3 Registratie & Login Gebruikers moeten zich zelf kunnen registreren op Knooppunt De registratieprocedure omvat: • • •
registratie met e-‐mailadres en zelfgekozen wachtwoord profielbepaling (zie verder) verificatie van het e-‐mailadres met een activeringsmail
Verder stellen we voor om de klassieke procedures te behouden: • •
inloggen met e-‐mailadres en wachtwoord procedure voor “wachtwoord vergeten”: versturen van e-‐mail met link voor eenmalige toegang + mogelijkheid voor instellen nieuw wachtwoord
De registratieprocedure vormt in de huidige versie van Knooppunt een hindernis. Binnen Knooppunt 3.0 is het belangrijk om deze procedures verder te optimaliseren. Een aantal pistes zijn mogelijk:
17
• • •
Gebruikersvriendelijkheid van de registratieprocedure verder optimaliseren Bulk registratie mogelijk maken via een ICT-‐coordinator of leerkracht Hulp bieden bij individuele registratie door "empowerment" van meer ervaren gebruikers, bvb leerkrachten of ICT-‐coordinatoren (hoe dit dan precies in zijn werk zal gaan is nog verder uit te werken)
Een simultane Knooppunt registratie moet mogelijk zijn tijdens het registreren op bvb. een methodewebsite van een van de uitgevers. Hiervoor moeten de nodige API’s voor voorzien worden. 10.6.4 Profielbepaling Momenteel wordt de gebruiker gevraagd om volgende gegevens in te vullen tijdens het registratieproces: •
•
Type gebruiker: o Leerkracht of docent o Leerling o Andere De school of scholen waar de leerkracht of leerling les geeft of volgt (enkel voor type gebruiker leerkracht of leerling)
Hier stellen zich verschillende problemen: • • •
het invullen van deze gegevens vormt een extra hindernis in het registratieproces, vooral op het vlak van gebruikersvriendelijkheid (bvb. Google maps selectie van een school) het is onmogelijk om te verifieren of een gebruiker daadwerkelijk leerkracht of leerling is (lerarenkaartnummer vragen is geen sluitend mechanisme) de profielgegevens komen niet altijd overeen met de situatie van de gebruiker (bvb. student lerarenopleiding wil materiaal voor leerkrachten, maar is verplicht een school te kiezen, wat niet klopt met de realiteit)
Voor de bestaande doelgroepen zijn de uitgevers geen vragende partij om veel extra informatie te vragen. Er wordt gesuggereerd om volgende extra info te vragen, maar enkel op voorwaarde dat dit op een eenvoudige manier kan gebeuren zonder hinder bij het registreren: • •
Leerkrachten: School / Vak Leerlingen: School / Klas
Voor de nieuwe doelgroepen moet bekeken worden welke profielinformatie relevant is en hoe het op een vlotte manier kan opgevraagd worden bij de gebruiker.
10.7 Licentiekantoor Het licentiekantoor vormt het centrale hart van Knooppunt waarmee de uitgeverij de toegang tot het lesmateriaal regelt adhv licenties en licentie-‐activatiecodes. 10.7.1 Beveiliging lesmateriaal Beveiliging van lesmateriaal behoort tot de kernfunctionaliteit van Knooppunt. In grote lijnen werkt dit als volgt:
18
•
• •
Content wordt opgeslagen op een server die toelaat de content te beveiligen. Dit kan zowel: o het gemeenschappelijke content repository zijn o een eigen webserver bij de uitgeverij, ingericht voor beveiliging via Knoopunt Aan de content wordt een licentie gekoppeld volgens een van de gangbare modellen Voor deze licentie worden een aantal activatiecodes gegenereerd, via dewelke de eindgebruiker toegang krijgt tot het lesmateriaal, voor de duur gespecifieerd in de licentie
Wanneer een gebruiker probeert toegang te verkrijgen tot lesmateriaal, worden 2 controles uitgevoerd: • •
Is de gebruiker geauthenticeerd op Knooppunt? Indien niet, wordt de inlogprocedure opgestart. Indien ja, wordt gecontroleerd of de gebruiker in kwestie de licentie voor dat lesmateriaal geactiveerd heeft. Indien dit niet zo is, dan wordt gevraagd om een licentieactivatiecode in te voeren, en wordt de toegang initieel geweigerd.
10.7.2 Licenties Onder een licentie verstaan we een stukje data dat bepaalt of een gebruiker toelating heeft om een bepaald stuk lesmateriaal te raadplegen of niet. Een licentie omvat o.a. volgende kenmerken: • • • • • • • • • • • • • •
Licentiecode Eigen code (identificatie binnen de uitgeverij) Titel Icoon (afbeelding voor eindgebruiker) Vak (lijst) Methode (lijst) Jaar (lijst) Niveau (lijst) Omschrijving Profiel: toegankelijk voor leerling, leerkracht, beide Voorwaarden (tekst) Activeerbaar vanaf (datum) Activeerbaar tot (datum) Licentieduur: o X dagen na activatie o Tot einddatum X
Deze velden worden herbekeken binnen Knooppunt 3.0 en duidelijk gedefinieerd binnen de RFP.
19
10.7.3 Licentieactivatiecodes (LAC) en licentiemodellen Een licentie-‐activatiecode (LAC) is een code bestaande uit doorgaans 16 karakters1 waarmee de gebruiker de licentie ontsluit. Een LAC kan 1 of meerdere keren gebruikt worden, afhankelijk van het licentiemodel. Knooppunt moet verschillende licentiemodellen2 ondersteunen; binnen elk model worden activatiecodes op een andere manier aangemaakt. Een licentiemodel heeft een aantal vaste kenmerken: • •
•
Licentie waarop de activaties betrekking hebben Verloopdatum o Geen verloopdatum o Activatie kan plaatsvinden tot datum X Geldigheid (uiterste datum waarop de content beschikbaar is) o Datum wordt overgeërfd van de licentie o Content blijft beschikbaar tot datum X
10.7.3.1 Model 1: aantal unieke activatiecodes • De applicatie genereert X unieke activatiecodes • Elke activatiecode kan slechts 1 x gebruikt worden • X wordt bepaald door de uitgeverij • Wordt nu reeds gebruikt in huidige versie van Knooppunt 10.7.3.2 Model 2: aantal herbruikbare unieke activatiecodes • De applicatie genereert X unieke activatiecodes • Elke activatiecode kan Y keer gebruikt worden • X en Y worden bepaald door de uitgeverij • Wordt nu reeds gebruikt in huidige versie van Knooppunt 10.7.3.3 Model 3: één herbruikbare activatiecode • De applicatie genereert 1 herbruikbare activatiecode • De activatiecode kan X keer gebruikt worden • X wordt bepaald door de uitgeverij • Wordt nu reeds gebruikt in huidige versie van Knooppunt 10.7.3.4 Model 4: schoollicentie (nieuw!) • De applicatie koppelt de licentie aan een welbepaalde school via een referentie naar een school uit de scholenlijst (zie paragraaf over profielbepaling) • Voor deze school kan de licentie X keer geactiveerd worden • Is geimplementeerd in huidige versie van Knooppunt, maar is niet in gebruik. • Dit licentiemodel vergt nog nadere studie en wordt verder uitgewerkt
1 De code is in sommige gevallen langer dan 16 karakters, omwille van overerving bestaande niet-‐Knooppunt codes
van een uitgeverij 2 Strikt genomen moeten we hier spreken over “licentie-‐activatiemodellen”, aangezien ze betrekking hebben op de licentie-‐activatiecodes. Het begrip licentiemodel is evenwel reeds ingeburgerd binnen Knooppunt, dus we zullen verder deze term hanteren.
20
10.7.3.5 Model 5: abonnement (nieuw!) • Dit model is nog niet geimplementeerd in de huidige versie van Knooppunt, en moet uitgewerkt worden • Bij dit licentiemodel is de geldigheidsdatum open, en blijft de licentie actief tot de uitgeverij beslist om deze af te sluiten (bvb. als het abonnement opgezegd wordt, of als de gebruiker niet meer betaalt)
10.8 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. In de huidige versie van Knooppunt wordt deze repository CDS genoemd (Content Distribution System). Voor Knooppunt 3.0 hanteren we evenwel de naam Content Repository. Deze 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 biedt 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 zip-‐bestand op te laden, 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. Alle bovenstaande functionaliteiten moeten ook uitgevoerd kunnen worden door een machine via het aanroepen van een of meer API’s.
10.9 Rapportage 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: • •
Activaties Gebruik van het lesmateriaal
Rapportages en ruwe data moeten voorzien worden: • • •
In tabel-‐ en grafiekvorm Via export naar csv of andere formaten Via een API
21
10.10 Machine-‐aanstuurbaarheid 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. Deze externe systemen kunnen beschouwd worden als niet-‐menselijke gebruikers. Elke handeling die door een menselijke gebruiker uitgevoerd kan worden moet ook door een machine gebruiker uitgevoerd kunnen worden. Een volledige lijst van API’s wordt in dit document niet gegeven. Het definiëren van de diverse API’s komt aan bod in de RFP. Machine-‐aanstuurbaarheid is belangrijk o.a. om volgende redenen: 10.10.1 Modulair karakter Een belangrijke vereiste voor Knooppunt 3.0 is het modulair karakter van de architectuur, om volgende redenen: • • •
Robuustheid Onderhoudbaarheid Scheiding van verantwoordelijkheden
Dit brengt de noodzaak mee om communicatieprotocollen te voorzien tussen de onderlinge modules. Hiervoor moeten de nodige API’s voorzien worden. 10.10.2 Koppeling met externe systemen Knooppunt 3.0 zal informatie uitwisselen met diverse externe systemen: •
•
•
Eigen ERP-‐systemen: de uitgevers wensen in Knooppunt 3.0 koppelingen te leggen met eigen systemen (vooral ERP-‐systemen) teneinde informatie uit te wisselen rond bvb. licenties, activaties etc. Hiervoor moeten eveneens de nodige API’s voorzien worden. ELO’s of Electronische Leeromgevingen zijn platformen die in scholen gebruikt worden door leerlingen en leerkrachten om informatie uit te wisselen. De bekendste voorbeelden hiervan zijn Smartschool en ELOV. Via deze systemen is het mogelijk dat een koppeling gemaakt zal worden om SSO (Single Sign On) te voorzien. Andere: op dit moment is het nog niet duidelijk met welke systemen in de toekomst nog koppelingen gemaakt zullen worden. Het systeem moet open en flexibel genoeg zijn om andere systemen op een eenvoudige manier aan te sluiten op Knooppunt.
22
11 Appendix 2: Niet-‐functionele vereisten Naast de functionele vereisten zijn er voor Knooppunt 3.0 ook een aantal niet-‐functionele vereisten:
11.1 Migratie content Alle bestaande content in Knooppunt moet gemigreerd worden. Concreet gaat het over: • • •
Gebruikersaccounts & profielen Licenties & licentie-‐activatiecodes Content
Het hoge volume brengt een groot risico met zich mee. Het is belangrijk hier een goed uitgedacht plan van aanpak voor op te stellen
11.2 Secure web applicatie Knooppunt maakt gebruik van standaard web protocollen. Gebruik van SSL is een vereiste.
11.3 Gebruikersvriendelijkheid Uit ervaring met de huidige versie van Knooppunt blijkt dat zwaar moet ingezet worden op gebruikersvriendelijkheid.
11.4 Platform, device & browser onafhankelijkheid Knooppunt moet beschikbaar zijn op gangbare platformen, toestellen en recente browsers: • • •
Windows, Mac Desktop, Tablet, Mobiel IE, Chrome, Firefox, Safari
De exacte client-‐vereisten worden verder uitgeschreven in de RFP.
11.5 Schaalbaarheid & performantie Knooppunt moet schaalbaar zijn om performantie behouden bij uitbreiding gebruik. De architectuur moet toelaten om extra servers bij te plaatsen, zonder aanpassingen aan de software Daarnaast moet de gekozen technologie en architectuur een hoge performantie en korte responstijden toelaten, volgens de gangbare usability normen (gewenste antwoordtijden van grootteorde 1/10 seconde).
11.6 Backup & 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. Herstellen 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.
23
11.7 Monitoring Naast monitoring van de infrastructuur (hier niet in scope, is voor de hosting partner), moet het ook mogelijk zijn om de status van de software te monitoren. Via een dashboard, zichtbaar voor de administrator, moet de correcte werking van de diverse onderdelen zichtbaar gemaakt worden.
11.8 Loggen Het is belangrijk dat er een correcte logging gebeurt, om verschillende redenen: • •
Inzicht in gebruik & rapportage Opvolgen van incidenten, fouten
11.9 Test & Acceptatie platform Hoewel deze vereiste meer betrekking heeft op hosting, vermelden we toch dat er verschillende platformen moeten voorzien worden voor: • • •
Testen Acceptatie Productie
11.10 Deployment Software moet gemakkelijk en foutloos te deployen zijn na updates
11.11 Documentatie & handleidingen Er zijn documentatie & handleidingen nodig: • •
Technische documentie nodig, met volledige beschrijving software (architectuur, databank schema’s…) Handleidingen voor de geavanceerde gebruikers
11.12 Beheerbaarheid Het is belangrijk om de applicatie te kunnen beheren zonder tussenkomst van de leverancier, zoals: • •
Aanpassingen aan teksten Configuratie van parameters
11.13 Uitbreidbaarheid De architectuur moet toelaten om functionaliteit toe te voegen zonder impact te hebben op de reeds bestaande software, vandaar de noodzaak voor een modulaire opbouw.
11.14 Toegankelijkheid (Accessibility) Een vereiste is ook dat de software toegankelijk is voor gebruikers met beperkingen. Hierbij denken we aan: • •
Mensen met dyslexie Blinden en slechtzienden
24
