PROJECTPLAN Digitalenklas: Realisatie ELLIPS (WP2)
Rapport aan:
Consortium Digitalenklas Project
Referentie:
Referentie
Versienummer:
1.0
Status:
FINAL versie
Auteur(s):
Ron Otten
Digitalenklas – ELLIPS projec t ‘s-Hertogenbosch, 22 mei 2002
INHOUDSOPGAVE
1.
INLEIDING ...............................................................................................................3 1.1 Doelstelling van dit document ...........................................................................3 1.2 Onderdelen projectplan......................................................................................3
2.
PRIORITERING.......................................................................................................4 2.1 Achtergrond .......................................................................................................4 2.2 Wijziging t.o.v. oorspronkelijke eisenpakket (CD) ...........................................4 2.3 Status FO............................................................................................................5 2.4 Weging van Functionaliteiten ............................................................................5
3.
PLANNING ...............................................................................................................6 3.1 Stand van zaken .................................................................................................6 3.2 Tussenproducten ................................................................................................6 3.3 Globale Planning Realisatiefase WP2 ...............................................................7
4.
TECHNISCHE ASPECTEN....................................................................................8 4.1 Aanbieding audio- en videofragmenten .............................................................8 4.2 Schaalbaarheid ...................................................................................................8 4.3 Browserafhankelijkheid .....................................................................................8 4.4 Export Hologram................................................................................................8 4.5 Programmatuuronderzoek..................................................................................9 4.6 .NET...................................................................................................................9
5.
RISICOANALYSE .................................................................................................12
ELLIPS_ProjectPlan_Versie Final 1.doc 5/22/2002
Pagina 2 van 12
1.
INLEIDING
1.1
Doelstelling van dit document Dit document dient als brug tussen de ontwerpfase en de realisatiefase te functioneren. Het doel is om de praktische zaken die hiermee aan de orde komen te presenteren en de richting te geven voor uitvoering. De basis voor het projectplan is de afgelopen maanden uitvoerig besproken en vastgelegd in het Inventarisatie Rapport (IR) en het Functioneel Ontwerp (FO). Zoals het begrip Projectplan in de Controlling Document (CD) wordt gebruikt is het FO onderdeel van het Projectplan. In de praktijk zijn het twee aparte documenten geworden. Dit projectplan (in combinatie met het FO) wordt ter goedkeuring aan de opdrachtgever van het Digitalenklas project aangeboden met het oog op een snelle voortzetting van de werkzaamheden. Gezien de veelheid aan documentatie die al bestaat zal dit projectplan zich alleen richten op essentiële onderwerpen. Reeds genoemde onderwerpen zoals bijvoorbeeld de doelstelling van het project worden dus niet opnieuw beschreven.
1.2
Onderdelen projectplan Het projectplan heeft als doel het beschrijven van de essentiële punten die betrekking hebben op de realisatie van het programma ELLIPS door Aebly. Het programma dat gerealiseerd zal worden wordt in het FO beschreven. Het FO functioneert als blauwdruk voor het nog te realiseren product en is als zodanig de leidraad voor dit projectplan. Er komt een viertal onderwerpen aanbod: • • • •
Prioritering: in hoeverre is het ontworpen programma te realiseren binnen de oorspronkelijke begroting. Techniek. Planning. Risicoanalyse
ELLIPS_ProjectPlan_Versie Final 1.doc 5/22/2002
Pagina 3 van 12
2.
PRIORITERING
2.1
Achtergrond De prioritering van gewenste functionaliteiten is vooral tijdens de tweede helft van het ontwerpproces een belangrijk thema geweest. De doelstelling hierbij was om zoveel mogelijk de onderdelen te ontwerpen die ook gerealiseerd zouden worden. Dit is vaak lastig geweest omdat de tijd die nodig is voor het bouwen van een bepaalde functionaliteit altijd samenhangt met de andere functionaliteiten. Een software routine voor een onderdeel die vervalt is misschien nodig om een andere juist vlot te kunnen programmeren. Deze onderlinge afhankelijkheid betekent dat inschattingen tijdens het ontwerpproces altijd een indicatieve karakter hebben gehad. Gedurende het project kwam het Consortium in aanraking met de software van Universiteit Gent. Dit levert een externe afhankelijkheid op. Omdat de structuur en kwaliteit van deze software (webrecorder) nog niet bij Aebly bekend is, blijft het moeilijk te voorspellen hoeveel tijd zal gaan zitten in het implementeren hiervan. De weging van de verschillende onderdelen is gebaseerd op een gedetailleerde urenplanning. Wij zijn uitgegaan van de realisatie-uren die in het SURF controlling document worden begroot. Uren die gereserveerd staan voor activiteiten zoals testen en revisie worden gehandhaafd. Het ontwerpproces heeft ook voor Aebly veel meer uren gekost dan oorspronkelijk waren begroot. Dit heeft ertoe geleid dat alle marges die normaliter in een fixed-price begroting zitten nu volledig zijn uitgeput. Om de applicatie zoals deze in het FO is beschreven te realiseren binnen de begrote uren zullen er nog een aantal concessies moeten worden gedaan. De concessies slaan vooral op drie gebieden: 1. Wensen die uitgesteld moeten worden. Dit lijstje hebben wij vrij kort kunnen houden omdat er al veel hiernaar is gekeken in de afgelopen weken. 2. Geen marges voor tegenvallers. Bijvoorbeeld, implementatie Gent software of onverwachte problemen bij het importeren van gegevens uit Hologram mogen niet veel onverwachts met zich meebrengen. Dit betekent dat we tijdens het realisatieproces ons erg strak aan het functioneel ontwerp moeten houden en dat echte tegenvallers tot overschrijdingen kunnen leiden. Hoe moeten we hiermee omgaan? Er is geen budgetaire ruimte om tegenvallers op te vangen. Hier moeten alle partijen zich volledig van bewust zijn tijdens de realisatiefase om tijdig te kunnen bijsturen mocht het nodig zijn. 3. Het schrijven van een handleiding. Is dit een activiteit die eventueel door een andere partner van het Consortium uitgevoerd kan worden?
2.2
Wijziging t.o.v. oorspronkelijke eisenpakket (CD) • Er wordt geen Cd-rom voor assets geproduceerd. • Webrecorder wordt niet door Aebly gebouwd maar door Aebly geïmplementeerd.
ELLIPS_ProjectPlan_Versie Final 1.doc 5/22/2002
Pagina 4 van 12
2.3
Status FO Het goedgekeurde FO is een bindend document. Het document beschrijft het te bouwen product.Toevoegingen of wijziging tijdens de realisatiefase kosten bijna altijd extra tijd en worden dus als revisiepunten beschouwd.
2.4
Weging van Functionaliteiten De volgende onderdelen zullen worden gerealiseerd. Achter elke onderdeel is het percentage van de uren begroot voor de realisatie te zien.
Ref
Onderdeel van programma
1 1.1 1.2 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4
Voorkant Uitlevering van contentpagina’s en navigatie Oefeningen (5 types) Voor- en achterzijde Unicode ondersteuning Cesuur, adaptiviteit, scoring Dossier Cursus ontsluiting/autorisatie Oefening kiezen + reeksen bijhouden Sessiemanagement (evt. .NET) Implementeren Webrecorder + oefentypen* Achterkant Hologram assetmodel Metadata Gebruikers, groepen en rechten Onderhoud cursus Onderhoud content (incl. hergebruik) Onderhoud sleutels Onderhoud oefeningen Reeksonderhoud Onderhoud assets Overig Totaal Wensen Periodieke import studentgegevens Meldingen bij inbewerkingzijnde objecten Handleiding
5 5.1 5.2 6
Percen t 3% 19 % 5% 2% 3% 1% 5% 4% 7% 3% 6% 7% 4% 6% 2% 15 % 5% 1% 2% 100 % 2% 3% 6-10 %
* inschatting is op moment uitsluitend indicatief
ELLIPS_ProjectPlan_Versie Final 1.doc 5/22/2002
Pagina 5 van 12
3.
PLANNING
3.1
Stand van zaken Het project loopt op het moment van schrijven ongeveer vier weken achter op schema. Dit kwam onder andere doordat er gehoor werd gegeven aan de noodzaak het ontwerpproces grondig aan te pakken. Een goed doordacht ontwerp voorkomt dat er allerlei discussies en onzekerheden het realisatieproces zullen storen. In de voorbereiding voor dit projectplan heeft Aebly gekeken naar mogelijkheden om de oorspronkelijke planning zoals in het CD wordt gegeven te hanteren. 1. Enerzijds is het zo dat het Functioneel Ontwerp een bindend document is waardoor er nu volop gerealiseerd kan worden zonder omkijken. Dit zal efficiency opleveren tijdens het productieproces. 2. Anderzijds zijn er altijd momenten tijdens een realisatiefase dat problemen die niet van tevoren “bedacht” konden worden ter plekke opgelost moeten worden. Om de planning op dit soort van momenten te handhaven wordt een hoge mate van bereikbaarheid gevraagd tijdens de realisatie. De door Aebly aangedragen oplossingen moeten snel afgehandeld kunnen worden door de Consortium. Beslissingen moeten bij wijze van spreken binnen 48 uur gemaakt kunnen worden om het productieproces niet in vertraging te brengen. 3. Meerdere mensen inzetten en parallel aan Ellips laten werken zodat de planning haalbaar blijft. Wij hopen op deze manier twee van de vier weken achterstand te kunnen terug winnen.
3.2
Tussenproducten De voortgang van het project zal voor het consortium van universiteiten te volgen zijn. Dit zal geschieden op basis van milestones. Bij elke milestone is er de mogelijkheid om een deel van de ELLIPS applicatie te bekijken. Hiervoor zal het betreffende deel van de software op een acceptatieserver worden geplaatst. De delen hebben dan de status van een alfaversie. In feite zijn deze delen tussenproducten. Door deze tussenproducten als alfaversies op te leveren zal de beta- en finaaltestfasen minder onderhevig zijn aan bugmeldingen. Ook dit zal bijdragen aan het halen van de planning in de laatste kritische weken. Er zal minimaal één tussenproduct per maand worden opgeleverd (als alfaversie).
ELLIPS_ProjectPlan_Versie Final 1.doc 5/22/2002
Pagina 6 van 12
3.3
Globale Planning Realisatiefase WP2
Activiteit Begin Realisatiefase Milestone 1: Bijvoorbeeld Alfaversie Paragraaf/Navigatie Editor Milestone 2: Bijvoorbeeld Alfaversie Sleutel/reeks onderhoud Milestone 3: Alfaversie oefentypes Milestone 4: Alfaversie Dossier Betatest hele applicatie Revisie Final Test Implementatie Oplevering
ELLIPS_ProjectPlan_Versie Final 1.doc 5/22/2002
Pagina 7 van 12
Week nr. 14 16 20 22 24 25-26 27-28 29 30-31
4.
TECHNISCHE ASPECTEN
4.1
Aanbieding audio- en videofragmenten De precieze invulling van de afhandeling van audio- en videofragmenten in de applicatie ELLIPS kan pas aanbod komen als het Technisch Ontwerp wordt afgerond. De wens van het Consortium is dat streaming technologie wordt toegepast bij het aanbieden van de verschillende audio en video elementen (assets). Verder is het dat de bedoeling dat de adressering van verschillende “gestriemde” assets via het aanroepen van URL’s zal gebeuren. Het implementeren hiervan heeft geen vergaande gevolgen voor de ELLIPS applicatie op zich. Er zijn echter wel een paar consequenties waar er rekening mee gehouden moet worden. Een van de nadelen van deze aanpak is dat de eindgebruiker te maken kan krijgen met toegangsrechten en eventueel met servers of verbindingen die lage prestaties met zich meebrengen. Doordat assets niet centraal worden beheerd zijn ze meer afhankelijk van de regels die “externe” beheerders van de verschillende servers hanteren. In een aparte technische sessie zullen deze punten nog verder worden toegelicht.
4.2
Schaalbaarheid Tijdens de realisatiefase wordt er sterk rekening gehouden met de eisen van schaalbaarheid. Belangrijkste element daarvan is het splitsen van functionaliteit over verschillende servers. In beginsel wordt er ontworpen voor drie servers: (1) een applicatieserver, (2) een database server en (3) een assetserver. Bij de oplevering is het mogelijk om de applicatie op een enkele server te plaatsen. Gezien de verwachte userload is het waarschijnlijk dat er op vrij korte termijn meerdere servers ingezet zullen moeten worden.
4.3
Browserafhankelijkheid Veel functionaliteit die bijvoorbeeld in de oefentypes zit wordt sterk ondersteund door Microsoft, en dus door Internet Explorer 5.5 (en hoger) op het Windows Platform. Door deze afhankelijkheid zal Aebly ontwikkelen voor deze combinatie, en niet voor Netscape of Macintosh IE.
4.4
Export Hologram Er is afgesproken met Andre R. dat het schrijven van een programma voor het exporteren van gegevens uit Hologram door de Universiteit Groningen zal worden uitgevoerd. Aebly zal hiervoor de benodigde datastructuur aanleveren. Tijdens de testfase zullen de problemen met conversie gezamenlijk worden opgelost. Hierna komt de verantwoordelijkheid voor een correcte aanlevering van de exportbestanden bij de Universiteiten liggen. Er dienen hier nog verdere afspraken overgemaakt te worden.
ELLIPS_ProjectPlan_Versie Final 1.doc 5/22/2002
Pagina 8 van 12
4.5
Programmatuuronderzoek Tijdens WP1 is een programmaonderzoek uitgevoerd. Er werden drie categorieën genoemd, en wij hebben een aantal conclusies hieraan verbonden: 1. Invoerhulpprogramma's: er is een programmaatje, Visual Keyboard, dat wel interessant kan zijn voor een student. Met dit programma kan er in plaats van invoeren met het toetsenbord, met de muis tekens worden ingevoerd. Dit (Microsoft) programma is gratis en heeft geen impact op de softwareontwikkeling van Ellips. 2. Audio-opname programma's: deze zijn veelal commercieel. Besloten is om de oplossing van Gent in te zetten. 3. Complete Leeromgevingen: zijn verder niet relevant voor Ellips omdat Ellips juist een aanvulling moet zijn op bestaande DLO’s.
4.6
.NET
Wij denken dat het gebruik van de nieuwe Microsoft .NET technologie op bepaalde terreinen voordeel kan bieden bij de realisatie en gebruik van het ELLIPS programma. Wij spreken dan met name over het gebruik van ASP.NET. Aebly overweegt ASP.NET toe te passen op de voorkant van de applicatie. Enige terughoudendheid hierin is zeker op zijn plaats gezien het feit dat.NET een recente toevoeging is aan de lijst van Microsoft programmeermogelijkheden. Voordat het volledig wordt ingezet zal het eerst toegepast worden op één van onderdelen aan de voorkant. Op deze manier kunnen wij de toepasbaarheid en voordelen van .NET eerst testen voordat we ons committen om het verder toe te passen. Overigens is het mogelijk om ASP en ASP.NET naast elkaar op dezelfde server te gebruiken. Op deze manier zouden we alleen voor de gebieden waar ASP.NET voordeel biedt het ook daadwerkelijk in kunnen zetten. We kunnen dan door middel van ASP onze al eerder geschreven componenten blijven gebruiken. Er zijn vier gebieden waar .NET vooral interessant zou kunnen zijn voor het ELLIPS project (zie paragraaf 4.6.1. tot en met 4.6.4).
4.6.1
Meertalige ondersteuning Meertalige ondersteuning is één van de pijlers van het Ellips-programma. Ellips dient in principe alle talen te ondersteunen. Hierbij is het niet alleen noodzakelijk dat de juiste lettertypes getoond worden, maar ook dat de afhandeling daarvan correct verloopt (Arabisch wordt bijvoorbeeld van rechts naar links gelezen – input dient dus ook van rechts naar links te gebeuren).
ELLIPS_ProjectPlan_Versie Final 1.doc 5/22/2002
Pagina 9 van 12
Standaard ASP kan gebruik maken van Unicode. De afhandeling van de correcte lettertypes is echter grotendeels afhankelijk van de gebruikte browser en Windowsversie. Het kan namelijk noodzakelijk zijn dat bepaalde lettertypes dienen te worden geïnstalleerd op een pc voordat de applicatie alle lettertypes correct kan tonen. De ondersteuning vanuit ASP.NET gaat verder doordat daarbinnen gebruik gemaakt wordt van standaard ondersteuning van ‘cultures’. Een ‘culture’ geeft voor de programmeur aan welke taalinstelling er gebruikt wordt. Vervolgens is het mogelijk om de userinterface grotendeels automatisch aan te passen aan deze instelling. Hierdoor wordt het werk voor de programmeur makkelijker. Het is bijvoorbeeld mogelijk om automatisch de juiste lettertypen te downloaden indien deze nog niet geïnstalleerd zijn.
4.6.2
Sessiemanagement Voor het bijhouden van scores, autorisatie, etc. zal er een uitgebreid sessiemanagement onderdeel geschreven moeten worden. Omdat een webapplicatie “stateless” is, dien je alle functionaliteit voor het bijhouden van gebruikersinformatie zelf te schrijven. De mogelijkheden die ASP hiervoor heeft zijn wel krachtig, maar belemmeren de schaalbaarheid. Bij het gebruik van deze mogelijkheden ben je gebonden aan één server. Ook zorgt het gebruik van deze mogelijkheden voor een groot verlies aan performance omdat sessies door de server een bepaalde tijd vast gehouden worden. Door deze nadelen wordt er daarom door programmeurs vaak gekozen voor een eigen implementatie van het sessiemanagement. Deze oplossingen zijn altijd maatwerk en daarom nogal arbeidsintensief. De makers van ASP.NET onderkennen dit probleem en hebben van sessiemanagement een integraal onderdeel van ASP.NET gemaakt. Het sessiemanagement is op dezelfde manieren te gebruiken als in standaard ASP, doch zonder de grote performanceproblemen die ASP met zich meebrengt. Hierdoor is het mogelijk om snel een sessiemanagement onderdeel te kunnen gebruiken, zonder zelf een maatwerk oplossing hiervoor te hoeven maken.
4.6.3
Snelheid / caching Snelheid is altijd belangrijk. De gebruiker moet niet het gevoel hebben dat hij of zij zit te wachten op de applicatie. Webapplicaties kunnen aanzienlijk worden versneld door gebruik te maken van caching. Hierdoor dient bij het opvragen van een pagina niet elke keer de database gelezen te worden, maar kan gebruik worden gemaakt van een opgeslagen kopie. Deze kopie kan
ELLIPS_ProjectPlan_Versie Final 1.doc 5/22/2002
Pagina 10 van 12
dan eens in de zoveel tijd opnieuw aangemaakt worden (bijvoorbeeld bij het doorvoeren van wijzigingen op die pagina). Binnen Ellips willen we graag gebruik gaan maken van caching vanwege het grote aantal te verwachten gebruikers. ASP kent slechts een beperkte ondersteuning voor het cachen van gegevens. Hiervoor is het noodzakelijk om een maatwerk oplossing te schrijven als je gebruik wilt maken van caching. Ook voor dit punt geldt dat de makers van ASP.NET dit probleem ook grondig hebben aangepakt. Net als het sessiemanagement is caching een integraal onderdeel van ASP.NET. Het cachen van pagina’s kan zelfs op meerdere manieren gebeuren: • Page Level Caching (het cachen van hele pagina’s) • Page Fragment Caching (het cachen van onderdelen van pagina’s) • Programmatic / Data Caching (het cachen van bijvoorbeeld variabelen of gebruikergegevens)
4.6.4
Autorisatie Binnen Ellips zal een aantal rollen gebruikt gaan worden. Zo’n rol is gekoppeld aan een gebruiker en bepaalt welke rechten deze gebruiker heeft. Deze rechten zouden in principe per pagina verschillend kunnen zijn. Een student ziet bijvoorbeeld bepaalde onderdelen niet en heeft geen toegang tot de onderhoudsomgeving. ASP heeft standaard geen voorziening voor autorisatie. Elke vorm van autorisatie zal daarom zelf geschreven moeten worden. Meestal gebeurt dit door het schrijven van een component dat op elke pagina wordt aangeroepen om te kijken welke onderdelen van een pagina wel of niet toegankelijk zijn. Binnen het .NET Framework is veel aandacht besteed aan beveiliging en autorisatie. Zoveel dat autorisatie op basis van rollen standaard in het framework is verwerkt. Dit wil zeggen dat je op codeniveau kan bepalen of iemand toegang heeft tot een bepaald onderdeel. Het enige wat je zelf dan nog hoeft te doen is te bepalen welke rollen toegang hebben tot welk onderdeel van het systeem. Het framework regelt zelf de onderliggende beveiliging.
ELLIPS_ProjectPlan_Versie Final 1.doc 5/22/2002
Pagina 11 van 12
5.
RISICOANALYSE De risico’s die genoemd moeten worden voor het ELLIPS zijn allemaal van technische aard. 1. Afhankelijkheid van infrastructuur (bijvoorbeeld ondersteuning Utrecht tijdens implementatie). 2. Specificaties van de Gent software zijn nog onbekend. Dit levert een externe afhankelijkheid op. Omdat de structuur en kwaliteit van deze software (webrecorder) nog niet bij Aebly bekend is, blijft het moeilijk te voorspellen hoeveel tijd zal gaan zitten in het implementeren hiervan. 3. .NET technologie is betrekkelijk jong en dus nog op zich een risico. Risico wordt gedeeltelijk opgevangen door tijdens realisatie het toepassen van .NET eerst op kleine schaal in te voeren. Zie hoofdstuk 4.6. 4. Zoals al in het Prioritering hoofdstuk werd genoemd, zijn alle veiligheidsmarges voor overschrijdingen al gebruikt en of ingezet om zoveel mogelijk functionaliteit te kunnen realiseren. Dit betekent dat tegenvallers gelijk voelbaar zullen zijn. Hier zal rekening mee gehouden moeten worden tijdens het hele realisatietrajekt. Punten die tot overschrijdingen zouden kunnen leiden met telkens vroeg worden aangegeven en er moet onmiddelijk bijgestuurd worden.
ELLIPS_ProjectPlan_Versie Final 1.doc 5/22/2002
Pagina 12 van 12