Knooppunt 3.0 RFP. Frank Salliau. 12 februari 2014 V1.1

Transcriptie

1 Knooppunt 3.0 RFP Frank Salliau 12 februari 2014 V1.1 1

2 Historiek v1.0 6 februari 2014 Eerste draft v februari 2014 Wijzigingen na feedback stuurgroep & RvB 1 Over dit document Geheimhoudingsclausule Achtergrond & Context Historiek & Missie Doelgroepen Cijfers Wat is Knooppunt niet? Motivatie project Project Scope Tijdslijn Selectieproces leverancier Evaluatiecriteria Vereisten Projectmatig, Budgettair & Samenwerkingsmodel Architectuur Standaarden & Off- the- shelf oplossingen Website knooppunt.net en digiportail.be Backoffice Licentiekantoor Licensed Content Management & Content Repository Security: rollen en toegangsrechten Logging module Rapportage module API Infrastructuur

3 API Set Vereisten API Domein model UML Class Diagram Klassen Rollen UML Diagram Use Cases Overzicht use cases Gedetailleerde beschrijving use cases Functionaliteit met variabele scope Registratieproces Schoollicentie Niet- functionele vereisten Migratie data Security Gebruikersvriendelijkheid Platform & browseronafhankelijkheid Schaalbaarheid Performantie Disaster recovery Test & Acceptatie platform Deployment proces Documentatie, handleidingen & opleidingen Onafhankelijkheid Toegankelijkheid Business Cases Business case "Verbeterd registratieproces "

4 9.2 Business case Frauduleuze klasaccount Business case Fusie school Business case "Beveiligen externe content" Business case "Schoollicentie" Business case "Rollback na fout uitgever " Business case Migratie data Richtlijnen voor de aanbieders Inhoud voorstel Budget Planning Projectaanpak Projectaanpak Communicatie Testplan Acceptatieplan Releaseplan Integratie met 3 de partijen Architectuur & Technologie Architectuur Database(s) Website knooppunt.net/digiportail.be Backoffice Licensed Content Management Content Repository Licentiekantoor Authenticatie Logging Rapportage

5 API Business cases Niet- functionele vereisten Migratie data Security Gebruikersvriendelijkheid Platform & browser- onafhankelijkheid Schaalbaarheid Performantie Disaster Recovery Test & Acceptatieplatform Deployment proces Documentatie, handleidingen & opleidingen Onafhankelijkheid Toegankelijkheid Competenties & tarieven Technische vereisten 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

6 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

7 Knooppunt vzw is een dochtervereniging onder de koepel van sectorfederatie Boek.be vzw ( 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 (NL) & (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: +/ Aantal actieve licenties: +/

8 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: 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. 4 Motivatie project De uitgeverijen hebben dit project opgestart om volgende redenen: 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. 5 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

9 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 De tijdslijn voor het volledige project verloopt als volgt: Periode Fase nov 13 mrt 14 Scopebepaling & selectie leverancier 15 jan 14 RFI uitgestuurd 31 jan 14 Deadline antwoord RFI 12 feb 14 RFP uitgestuurd 5 mrt 14 Deadline antwoord RFP 7 mrt 14 Verdediging door aanbieders 21 mrt 14 Definitieve keuze aanbieder april 2014 februari 2015 Bouw platform 6 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: 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 Locatie & tijdstip worden nog meegedeeld aan de aanbieders. 7 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

10 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 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

11 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

12 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. 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

13 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

14 Deze informatie moet via de API kunnen ingelezen worden in externe systemen, in gebruikelijke formaten zoals JSON of XML 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 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 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

15 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 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 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

16 UML Class Diagram Klassen Het domein model omvat volgende klassen of types objecten: Gebruiker Een gebruiker refereert naar een eindgebruiker op Knooppunt en bevat volgende gegevens: Attributen 16

17 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 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: Wallonië: 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 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 Licentie Een Licentie beschrijft de modaliteiten waaronder een gebruiker toegang krijgt tot een content op Knooppunt. 17

18 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 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

19 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 AantalUniekeLACBatch Attributen AantalCodes: aantal unieke activatiecodes AantalHerbruikbareLACBatch Attributen AantalCodes: aantal unieke activatiecodes MaxActivaties: maximum aantal activaties per code EenHerbruikbareLACBatch Attributen MaxActivaties: maximum aantal activaties 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 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

20 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 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

21 Gedurende de verdere analysefase van het project is het mogelijk dat extra rollen gedefinieerd worden en bestaande rollen verfijnd worden 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

22 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 Overzicht use cases De tabel hieronder biedt een overzicht van de use cases in scope binnen Knooppunt 3.0. Belangrijke use case, volledig uitgeschreven Legende Minder belangrijke use case, wordt minder in detail beschreven 1 2 Nr ID Actor Naam Prioriteit 1 UC- 1.1 Eindgebruiker Registreren 1 2 UC- 1.2 Eindgebruiker Inloggen 1 3 UC- 1.4 Eindgebruiker Profiel wijzigen 2 4 UC- 1.5 Eindgebruiker Taal wijzigen 2 5 UC- 1.6 Eindgebruiker Lesmateriaal activeren 1 6 UC- 1.7 Eindgebruiker Lesmateriaal raadplegen 1 7 UC- 1.8 Eindgebruiker Vraag stellen aan helpdesk 2 8 UC- 1.9 Eindgebruiker Status systeem bekijken 2 UC Eindgebruiker FAQ Raadplegen UC- 2.1 LicentieBeheerder,Uitgever Licenties beheren 1 11 UC- 2.2 LicentieBeheerder,Uitgever LACs beheren 1 12 UC- 2.4 LicentieBeheerder,Uitgever GebruikersLicenties beheren 1 13 UC- 2.5 ContentBeheerder,Uitgever Content beheren 1 14 UC- 2.6 Uitgever Rapport Licenties 2 15 UC- 2.7 Uitgever Rapport GebruikersLicenties 2 16 UC- 2.9 Uitgever Rapport gebruikersdata 2 UC Uitgever Rapport gebruik content 2 UC Uitgever Zoeken 2 19 UC- Uitgever- Administrator Beheer accounts eigen uitgeverij 2 22