Toelichting bij de offerte voor de ontwikkeling van het
collectieve e-boek-platform voor de Vlaamse uitgeverijen
Nederlands/Frans
Ter attentie van: Mevrouw Goedroen Vanlerberghe Projectleider Knooppunt.net Boek.be Het Huis van het Boek Te Boelaerlei 37 B-2140 Borgerhout
Projectteam Vooraleer we ingaan op de verschillende fasen van dit project, toch ook even een woordje over het projectteam. Om de communicatie zo kort en transparant mogelijk te houden, lijkt het ons aangewezen dat de projectleiders langs beide kanten hiervoor verantwoordelijk zijn. Dit betekent dat dit bij EPYC Bram Van den Borre zal zijn, bij Boek.be Goedroen Vanlerberghe (of hun vervangers in geval van ziekte/verlof). In de praktijk betekent dit dus dat alle communicatie van de kant van Boek.be via Goedroen zal verlopen. Individuele uitgevers die in het projectteam zitten en bv. actief mee testen, bedenkingen of vragen hebben, maken deze over aan Goedroen. Zo kan aan de klantzijde alles gebundeld en afgewogen worden alvorens door te sturen naar EPYC. Enkel de beide projectleiders kunnen bv. issues rapporteren-toewijzen-sluiten, change requests indienen-aanvaarden-weigeren enz.. Verder in dit document gaan we ook even in op de projecttool die we voorstellen te gebruiken om deze communicatie te verzamelen.
Overzicht houden Voor dit project, waarbij heel wat stakeholders graag de voortgang volgen, spreken we bij de start van het project goed af : -
Wie heeft welke functie binnen het projectteam Hoe verloopt de communicatie Waar en hoe houden we changes request bij We overlopen de gekozen projecttool Toelichting van de releasekalender Testing & debugging
Hoe? De tool die we binnen EPYC reeds geruime tijd gebruiken, zij het nu vooral voor bugtracking, is de project management webtool van Redmine (http://www.redmine.org/ en http://redmine.epyc.be). Voor een project als dit, met een vrij uitgebreide groep van stakeholders die elk hun zeg zullen hebben in het project, is het meer dan anders aangewezen om een en ander in goede banen te leiden. In onze EPYC-bugtracker kunnen we bv. voor de uitgevers een ‘view’ account aanmaken zodat iedereen het project kan volgen, zonder zelf dingen te kunnen wijzigen of ingeven. (Evt. wel change requests, die door de projectleiders worden afgetoetst met de andere belanghebbende partijen, en dan een andere status kunnen krijgen; cf. infra)) Zodra een release migreert naar de testomgeving, zal in Redmine een nieuw hoofdstuk aangemaakt worden om de bugs te verzamelen. Bugs door Boek.be gerapporteerd kunnen door EPYC aanvaard of 2
geweigerd worden. Eens een bug opgelost is, kan deze door Boek.be aanvaard en gesloten worden. Op die manier hebben we per release steeds een mooi overzicht van de openstaande issues. Belangrijk hierbij zal ook het loggen van wijzigingen zijn. Heel waarschijnlijk zullen tijdens het project bepaalde dingen net iets anders besproken en uitgewerkt worden dan initieel beschreven in de projectbrief. Door deze change-requests in te geven en te laten valideren door de andere partij in de project tool, is het ook achteraf voor iedereen duidelijk wat de gemaakte afspraken waren. Belangrijke change-requests die een invloed op budget en planning hebben, worden na begroting en planning in de tool door beide partijen terug aanvaard.
3
Project fasen Als maatwerk-ontwikkelaar ontwikkelaar van multimedia-toepassingen multimedia en e-Learningcursussen Learningcursussen is EPYC een echt project-gebaseerd gebaseerd bedrijf. Onze teamleden zijn het dan ook allemaal goed gewend om in een projectmatige jectmatige omgeving te werken. In de volledige doorloop van een project, onderscheiden we een aantal fasen. Je kan deze in een diagram mooi achter elkaar plaatsen, maar uiteraard is de realiteit wel complexer ; zo zullen een aantal fasen enkele keren doorlopen open worden (bv. ontwikkeling & testing voor elke release).
Definitie
Ontwerp
Ontwikkeling
Testing
Oplevering
Nazorg
Definitie De projectbrief is de blauwdruk van de applicatie, applicatie de definitie als het ware.. Hierin wordt middels beschrijvingen en wireframes de opbouw en werking van de applicatie tot in detail beschreven. De projectbrief gaat heen en weer tussen Boek.be en EPYC,, om uiteindelijk te resulteren in een definitieve versie, door beide partijen goedgekeurd en aanvaard. Definitie en ontwerp vallen hier dus voor een stuk samen. Wat betreft het ontwerpen vann interface onderdelen, dan deze ook tijdens de ontwikkelfase gebeuren, wanneer over bepaalde onderdelen of functionaliteiten tijdens het project onduidelijkheid zou bestaan. De projectbrief zal de beschrijving van de 6 releases bevatten, zodat steeds duidelijk elijk is wat wanneer zal beschikbaar zijn. Omdat voor dit project al heel wat onderdelen duidelijk zijn, zal dit in praktijk betekenen dat we deze projectbrief niet vanaf nul moeten doorworstelen, maar dat over 80-90% 80 90% van de functionaliteiten waarschijnlijkk geen discussie bestaat. We kunnen ons dus toespitsen op de bespreken en uitklaren van die 10-20% 20% waarin jullie nog keuzes kunnen maken of het project een bepaalde weg op sturen. Het is dus niet de bedoeling dat de uitgeverijen veel tijd verliezen in het nadenken over de basis, maar wel om hen de kans te geven om de toepassing via maatwerk-aanpassingen maatwerk aanpassingen helemaal naar hun hand te kunnen zetten. Aan het einde van deze fase wordt deze projectbrief door alle partijen goedgekeurd en bevroren. Eventuele change requests quests aan deze projectbrief die tijdens het project doorgevoerd worden, moeten in de projecttool ingegeven en aanvaard worden, om zo ten allen tijde een goed beeld te hebben van de gemaakte afspraken en het eindresultaat te kunnen vergelijken met de vooropgestelde vooropgestelde oplossing.
4
Ontwerp Hiermee bedoelen we in dit project vooral de structurele en grafische opbouw van de verschillende interface schermen. In realiteit zal deze fase dus een stukje overlappen met de Definitie fase. Zoals je verder ook in de timing kan zien, is het grafisch ontwerp van de frontoffice voorzien voor release I. Bedoeling is alleszins dat jullie van elk scherm op voorhand duidelijk kunnen inschatten hoe het er zal uitzien, en hoe tools, knoppen en menu’s zullen werken. Het ontwerp voor de pc-versie en dat voor de tablet-versies zal uiteraard verschillen, in functie van de specifieke vereisten van de gebruikte hardware en usability-conventies.
Ontwikkeling De e-boek applicatie wordt ontwikkeld in 4 omgevingen: -
Lokale dev-omgeving Publieke test-omgeving Publieke accept-omgeving Live omgeving
De ontwikkeling van de e-boek toepassing zal in 6 grote releases gebeuren. Wat in deze releases zit, is afhankelijk van de definitieve projectbrief en de keuzes die Boek.be nog kan maken. De flow voor deze 6 releases zal steeds de volgende zijn:
Development: Local dev Ons ontwikkelingsteam werkt de requirements uit zoals deze zijn afgesproken en uitgeschreven in de projectbrief. Eens de onderdelen van de volgende release klaar zijn en lokaal getest, migreren we de onderdelen naar de test-omgeving. De local-dev omgeving is dus niet extern bereikbaar, en bij gevolg enkel relevant voor het EPYC ontwikkelteam.
Test Eens een release stabiel genoeg is, migreren we die naar de ‘publieke’ (paswoord-beschermde) test omgeving. Hier wordt een nieuwe release door ons intern test team getest, worden de gerapporteerde bugs opgelost en opnieuw in de test omgeving geplaatst. Daarna krijgt het Boek.be projectteam een ‘go’ om de release uittesten. Hiervoor krijgen jullie een testscript zodat duidelijk is welke functionaliteiten afgewerkt zijn, en welke onderdelen ingepland zijn voor een volgende release.
5
De gerapporteerde bugs uit het testrapport worden opgelost, en eens de release door Boek.be aanvaard is, migreren we die release naar de acceptatie omgeving.
Acceptatie De acceptatie omgeving is dus steeds de recentste stabiele release zoals die door Boek.be is goedgekeurd. Enkel releases die in de testomgeving zijn aanvaard door Boek.be kunnen dus gemigreerd worden naar de acceptatie omgeving. Het is dus in deze acceptatie omgeving dat ook de finaal afgewerkte versie van het e-boek zal getest en aanvaard worden, waarna deze gemigreerd wordt naar de Live omgeving.
Live In deze Live omgeving worden alle functionaliteiten nogmaals getest door zowel het intern test team van EPYC, als het test-team van Boek.be. Eens geen bugs meer gerapporteerd worden, zal een officiële oplevering volgen, waarmee Boek.be aanvaardt dat de applicatie conform de projectbrief is ontwikkeld en aanvaard.
6
Testing Op de vorige pagina hebben we reeds een woordje uitleg gegeven bij het testen van de verschillende releases. Maar uiteraard gaan we de applicaties ook buiten ons projectteam uitvoerig laten testen, zowel technisch-functioneel als qua usability.
‘Monkey’ testing Tijdens de fase die we intern graag ‘monkeytesting’ noemen, laten we een aantal users los op de applicatie, die totaal geen uitstaans hebben met dit type applicatie of de sector waarvoor ze is bedoeld. Belangrijk hierbij is die feedback eruit te filteren waaruit kan blijken dat de interface logische fouten zou bevatten die door het projectteam niet meer opgepikt worden (wegens te hard betrokken bij de ontwikkeling). Om deze testing in goeie banen te leiden, stellen we een kort rapport op met daarin een aantal basis opdrachten die de gebruikers moeten voltooien (bv. Ga op 2 verschillende manieren naar een volgende pagina ; Ga rechtstreeks naar bladzijde 30; Speel het filmpje op bladzijde 10 af en pauzeer het even..). De manier waarop en snelheid waarmee ze dit doen, plus de feedback die nadien volgt, kan heel waardevol zijn.
Usertesting Met echte usertesting willen we in een volgende fase dan de applicaties ook laten testen door mensen uit de sector. Dit kan een pilootschool zijn, een plaatselijk klasje of een bekende leerkracht.. Ook zij krijgen een lijstje met opdrachten, zij het dan iets uitgebreider en meer toegespitst op het dagelijks gebruik van de tools (bv. zelf assets toevoegen). Ook de informatie die hieruit naar voor komt, gebruiken we om de interface nog intuïtiever te maken, en nauw aansluitend bij het verwachtingspatroon van de gebruikers.
De kosten voor het organiseren en rapporteren van deze testings zitten in ons budget. Het eventueel verzorgen van de logistiek (bv. locatie afhuren, 20 tablets ter beschikking stellen..) vallen buiten het budget. Binnen de verder in dit document vooropgestelde timing, willen we deze beide testings in de loop van de maand januari inrichten.
7
Oplevering Timing Om het project e-boek binnen de vooropgestelde termijn te kunnen opleveren, geven we hier alvast graag een retroplanning mee. De vermelde onderdelen bij de releases zijn onder voorbehoud en afhankelijk van de uiteindelijke keuzes bij begin van het project. Aangezien dit project zich helemaal toespitst op de ontwikkeling van een tablet oplossing, gaan we ervan uit dat over de functionaliteiten van de desktop versie grotendeels consensus bestaat.
14 september:
Project brief klaar en aanvaard
Beschrijving van alle functionaliteiten Wireframes van de front- en backoffice opbouw
12 oktober: Release I Opzetten Backoffice + CDS uitgevers Frontoffice desktopversie klaar GUI tabletversie goedgekeurd
2 november:
Release II
BO: converteerscripting boeken voor tablets Start tablet ontwikkeling Open en bladeren van boeken op iPad en Android Basis besturing tablet mogelijk (pinch/zoom, rotate)
30 november:
Release III
Navigatie in e-boek Openen media assets Ontsluiten oplossingen
21 december:
Release IV
Alle functies in frontoffice beschikbaar op iPad en Android*
*Nota: Adobe en Microsoft hebben voor het nieuwe Windows 8 besturingssysteem heel nauw samengewerkt. Het is dan ook de allereerste Windows versie waar Flash ingebakken zit in de core van het OS, en bv. ook zal geüpdatet worden met de gewone Windows update. Op dit moment legt Adobe ook de laatste hand aan de ondersteuning voor Windows 8 tablet
8
vanuit de Adobe Air tools. Zodra deze uitgerold wordt, kunnen we ook heel snel een Windows 8 tablet versie uitrollen. Voorlopig schatten we dit in tegen 31/1/13, maar deze timing is dus afhankelijk van de Adobe release. Aangezien het aandeel van Windows 8 tablets ook aan het jaareinde nog marginaal zal zijn, lijkt ons dit alleszins geen groot probleem.
1 februari:
Release V
Windows 8 tablet versie Koppeling met Knoopunt operationeel
8 maart:
Release VI
HTML 5 versie: ! zoals ook vermeld in de offerte, lijkt ons een HTML5 versie op dit moment nog voorbarig, vooral omdat deze qua functionaliteiten en performantie zal moeten onderdoen voor de andere versies van de tool. Toch hebben we oor naar de wens van de uitgeverijen om deze versie te ontwikkelen. We vegen dit dus zeker niet van tafel, wel integendeel! Zodra de Desktop-versie klaar is (lees: zodra de belangrijkste hordes qua functionaliteit genomen zijn) , start EPYC immers parallel ook met het onderzoeken wat in een HTML5 versie haalbaar is met de dan gangbare hardware-devices. De uiteindelijke wishlist mét bijhorend extra budget bespreken we tijdens het project met Boek.be. De ontwikkeling van een eventuele HTML5 versie kan dan eventueel ingepland worden als een 6e release.
15 maart:
eerste import script uitgeverij 1
Met dit eerste script importeren we de bestaande bordboeken van een eerste uitgeverij.
22 maart:
import content uitgeverij 2
29 maart:
import content uitgeverij 3
29 maart:
finale oplevering: tablet app beschikbaar in Appstore, Google Play en Windows store
5 april – 19 april:
import content uitgeverij 4-6
9
10
11
Nazorg Support & SLA Eens de oplossing is opgeleverd en aanvaard door Boek.be, gaat onze support & SLA periode in. EPYC hanteert in dit project een buggarantie van 9 maand op alle onderdelen die in de oorspronkelijke release zaten. Dit betekent dat EPYC binnen deze periode alle gerapporteerde bugs oplost binnen het oorspronkelijk budget, voor zover dat de bug gerapporteerd wordt door de projectverantwoordelijke van Boek.be en aanvaard wordt door EPYC. 3 levels van bugsupport: -
Critical: het normaal gebruik van een tool is zwaar gestoord of onmogelijk Major: de tool kan gebruikt worden, maar één of meerdere functionaliteiten zijn voor minstens 30% van de gebruikers niet beschikbaar Minor: de tool kan gebruikt worden, maar de bug zorgt bij gebruikers soms voor onduidelijkheid of bepaalde niet-essentiële functionaliteiten zijn gestoord.
Critical bugs worden tijdens een werkdag binnen de 4 uur aangepakt, buiten de werkdagen binnen de 12 uur. Major bugs worden de volgende werkdag aangepakt. Minor bugs worden in overleg met de klant ingepland, maar nooit later dan 5 werkdagen na rapportering.
Het rapporteren van bugs kan ook na oplevering via het Redmine platform voor het project (het platform stuurt automatisch e-mail warnings uit). Maar in geval van Critical of Major bugs kan het sneller of duidelijker zijn eerst via telefoon iets te melden, en nadien voor opvolging in te geven in de Redmine tool. We spreken met de klant een ‘telefoonlijst’ af, waarop ook buiten de kantooruren issues kunnen gemeld worden. RFC’s en FR’s worden ten laatste binnen de 5 werkdagen gebudgetteerd en in samenspraak met Boek.be ingepland. Kleine requests kunnen meestal vrij snel op de planning gezet worden (1-2 werkweken), grotere ontwikkelingen bespreken we samen en zijn uiteraard in te plannen in functie van resources en workload.
Kwartaal meeting De wereld van mobiele toestellen en applicaties is razendsnel in beweging. Bij EPYC volgen we deze evoluties op de voet. Daarom lijkt het ons nuttig om na de oplevering van dit project, elk kwartaal even samen rond de tafel te zitten om de bewegingen en evoluties van de technologie te bespreken, en te kijken wanneer aanpassingen/uitbreidingen aan de bestaande tools nuttig kunnen zijn. Voor EPYC is een dergelijke 3-maandelijkse meeting ook een moment waarop we samen ideeën en wilde voorstellen kunnen bespreken en toetsen. Omdat deze meetings voor EPYC ook een commerciële
12
kant hebben (met het oog op eventuele uitbreidingen of nieuwe ontwikkelingen), beschouwen we deze dan ook als commerciële tijd, en worden deze meetings dus niet in rekening gebracht. Een eerste kwartaalmeeting kan wat ons betreft in de 2e helft van juni ingepland worden.
13
Het financiële plaatje Nog even wat verduidelijking bij onze offerte, bij de ‘neens’ uit onze offerte die mits toekenning van het corresponderende budget een ‘ja’ worden.
Ontwikkeling zoals vermeld in onze offerte:
124.000 €
+ versiebeheer annotaties (verschillende klassen)
1.500 €
+ plugins (per plugin, door EPYC geïntegreerd in e-boek)
1.500 €
+ text2speech*
7.500 €
Hosting** (2 TB opslag, 1 TB traffic/maand)
22.500 €
Jaarlijkse fee per aangesloten uitgever (vanaf schooljaar 2014-2015)
2.500 €
* Voor text2speech hebben we de tekstdata van een boek nodig. Deze zit uiteraard niet in een JPG formaat van een pagina. Daarom stellen we voor om voor de conversie van boeken te starten met een PDF waarin alle Indesign data aanwezig is (dus geen platte PDF). Hieruit kunnen we dan Hi- en Low-res JPG files maken om te tonen in de applicatie én maken we van elk onderdeel ook een SVG bestand. Om te verhinderen dat een tablet alle vector elementen van een pagina zou moeten renderen (performance!), houden we in de actieve pagina enkel een verwijzing naar alle SVG files van die pagina bij. Wanneer een gebruiker dan een stuk tekst wil laten voorlezen, kan hij bv. een paragraaf aanklikken, waarna de applicatie die ene SVG achter de schermen opent in converteert naar audio. * * Ons hosting voorstel omvat dus 3 dedicated server (1 voor backoffice, 2 voor frontoffice), met een totale schijfruimte van 2 TB per machine 1 TB verkeer per maand. Dus zolang geen van deze limieten wordt overschreden, zal de hostingkost niet meer bedragen. Voor de duidelijkheid: dit betekent dus GEEN extra software licenties, geen extra database users of licenties, geen extra database ruimte… Deze prijs omvat alle versies van de applicatie te hosten binnen de vooropgestelde data limieten. Ter vergelijking: in onze huidige tools komen +/- 100 boeken neer op een schijfruimte van een kleine 10 GB. Uiteraard spelen aantal pagina’s en het aantal toegevoegde assets hier ook steeds een belangrijke rol.
14
Mogelijke ‘hidden’ costs Hosting Extra dataverkeer hosting:
215 € / TB / server / maand
Extra schijfopslag hosting:
850 € / TB / server / jaar
Manuren Dit zijn onze dagprijzen voor ontwikkelingen of besprekingen die niet binnen het afgesproken budget vallen. Consultancy:
750 € / d
Flex & mobile development:
650 € / d
Project management & opleiding:
750 € / d
Andere uitgevers Uitgevers die nu niet in dit start project zitten, maar later instappen, betalen vanaf het eerste jaar de jaarlijkse fee van 2.500 € + 1.750€ voor het aanmaken van een eigen skin. Indien ook hier bestaande boeken worden gemigreerd, zal het importscript en het manuele werk begroot worden.
15
