Kristien Piersma
k.i.piersma@rc.rug.nl
Frank den Hollander f.j.den.hollander@ub.rug.nl
 |
Erik Saaman (links) en Roel Vandewall (rechts)
|
Hoe gaat het met het RUG Webplatform-project? In de eerste Pictogram van
dit jaar vertelden de projectleiders Bert Wiersema en Hans Beldhuis van het
ECCOO (Expertisecentrum voor ComputerOndersteund Onderwijs) over hun plannen
voor de nieuwe website van de universiteit. Wat is er in de tussentijd
allemaal gebeurd?
In deze laatste Pictogram van 2002 komen de technische projectleiders aan het
woord. Erik Saaman en Roel Vandewall zijn beide afkomstig van Informatica.
Samen geven ze leiding aan het technisch team dat aan de nieuwe website werkt.
Wat is jullie taak in het webplatformproject?
Saaman: Als technisch projectleider heb ik in eerste instantie het
functioneel ontwerp geschreven, de nodige workshops geleid en besprekingen
gehouden met de toekomstige gebruikers om te evalueren. Van daaruit zijn we
begonnen het verdere ontwerp uit te werken waarbij steeds meer mensen worden
ingezet.
Er was een startdocument met strategische informatie als een omschrijving van
de doelgroep, de benodigde uitstraling en dat we tot de top drie sites van
Nederland moeten gaan behoren. Dat soort informatie is voor een informaticus
niet voldoende om een product te ontwikkelen, daar kan nog op allerlei
verschillende manieren invulling aan worden gegeven.
In een functioneel ontwerp wordt veel gedetailleerder al een stukje onder de
motorkap beschreven, bijna al op het niveau van de webpagina’s. Dat er
verschillende portals moeten komen, welke structuur de webpagina heeft,
wat voor soort knoppen er op staan. Zonder zo’n functioneel ontwerp kan een
project nooit echt goed lopen.
Stapje voor stapje
Normaal gesproken maak je vervolgens een technisch ontwerp waarin de
details onder de motorkap nog verder worden uitgewerkt. Dat hebben wij in dit
geval niet gedaan omdat we vrij veel nieuwe technieken moesten gaan gebruiken.
We zijn al doende aan het technisch ontwerp gaan werken, het wordt steeds
stapje voor stapje uitgewerkt. Maar we schrijven wel van te voren op een vrij
abstract niveau op wat er moet gaan gebeuren en vervolgens gaat een
programmeur dat in programmacode uitwerken.
Eerst wordt bijvoorbeeld uitgebreid ontworpen wat voor soort objecten er
komen: personen, colleges, nieuwsberichten en welke informatie daar in komt.
Daar komt nog geen programmeur aan te pas. Vervolgens wordt alles stap voor
stap ontwikkeld. Tegen de tijd dat het ontwerp ongeveer stabiliseert, worden
alle programmeurs erbij betrokken die er een eerste versie van gaan maken.
Daarna volgt een terugkoppeling en wordt de eerste versie weer bekeken door
het ontwerpteam en worden er weer aanpassingen gedaan.
Vandewall: Ik fungeer hierbij als hoofdontwikkelaar van het
technisch team, degene die tussen enerzijds de wensen en het globale plaatje
zit, en anderzijds het concrete programmeren. Ik probeer die abstracte plannen
te vertalen met de programmeurs, maak daar een planning voor, en bekijk hoe we
het gaan testen, die hele cyclus.
Er zit vaak nog een heel gat tussen een plan en een technische uitwerking die
helemaal in het systeem past en doet wat gebruikers ook verwachten. Soms heb
je situaties dat iets het op de ene pagina wel doet en op de andere niet. Mijn
rol is om dan de goede tests te doen zodat je weet dat de nieuwe
functionaliteit in alle situaties voor iedereen goed gaat werken.
Saaman: Het is een extreem interactief proces dat aan de ene kant
tot hele drastische wijzigingen heeft geleid in het ontwerp. Nou moet ik
zeggen dat wanneer je het ontwerp nu terug zou lezen, het er nog steeds
globaal staat.
Aan de andere kant zorgt die wisselwerking er ook voor dat je heel erg focust
op wat je wel en niet belangrijk vindt. Er moeten keuzes gemaakt worden wat
eerst en wat later wordt gedaan. En dat bepalen we eigenlijk nauwelijks zelf.
Dat zijn toch uiteindelijk wel de gebruikers, in dit geval de
tussengebruikers, de webmasters, de beheerders.
Deze werkwijze heeft als voordeel dat er een grote betrokkenheid is bij
iedereen, maar heeft het niet als nadeel dat het langzaam gaat?
Saaman: Wellicht gaat het gevoelsmatig langzamer voor de mensen die
pilotmedewerkers, proefgebruikers zijn. Die zijn er al in een heel vroeg
stadium bij betrokken en die moeten er heel erg aan wennen dat het telkens
weer uitgesteld wordt. Ze worden toch een beetje onderdeel van het
ontwikkelteam. Het is voor het eerst dat we dat zo drastisch hebben gedaan;
daar hebben we wel van geleerd dat we in het vervolg de verwachtingen
misschien iets beter duidelijk moeten maken.
Vandewall: Je hebt ook maar een beperkte capaciteit om dingen te
ontwikkelen. Het ECCOO heeft een bepaald aantal programmeurs in dienst en die
kunnen maar een bepaalde hoeveelheid zaken af krijgen binnen een bepaalde
tijd. Dan moeten er prioriteiten worden gesteld. Daarbij kun je een
programmeerteam ook niet oneindig groot laten groeien, want op een bepaald
moment gaat de groepsgrootte in een project tegen je werken.
Implementation bias
Saaman: Er is nog een hele belangrijke reden waarom we de rollen
tussen ontwerpteam en technisch team gescheiden wilden houden. Als degene die
bovenop de implementatie zit teveel met de opdrachtgever of de klant praat,
kun je last krijgen van een zogenaamde ‘implementation bias’. Dat betekent
dat er op de wensen van de mensen wordt toegepraat naar wat technisch op dat
moment goed uitkomt. Daar moet je heel erg mee uitkijken. Je kunt ook niet
willekeurig iets maken, je moet altijd rekening houden met de wensen van de
opdrachtgever.
Mijn rol is om een beetje daar tussenin te manoeuvreren. Je moet een wat vrije
blik hebben, je moet brutaal kunnen zijn en zeggen ‘jij zegt nou wel dat het
niet kan, maar laten we daar nog eens even heel goed naar kijken’. We hebben
heel vaak discussies waarbij Roel of een programmeur in eerste instantie zegt
‘Dat kan niet’. Dan moet ik voor de bewijzen zorgen en de schetsen maken
om te laten zien hoe het wel kan. Er wordt dan wat uitgeprobeerd en uitgetest
en dan blijkt het uiteindelijk wel te kunnen.
> Het is nog
niet klaar,
maar wanneer is
iets klaar? <
|
Er is naar verhouding veel overleg met de opdrachtgever, de uiteindelijke
gebruiker. We zijn nu bijvoorbeeld bezig te kijken hoe we
onderwijsbeschrijvingen kunnen opnemen in het webplatform, dus van cursussen,
van stages, van afstudeerrichtingen en noem maar op. Dat kost veel overleg om
dat op een zodanige manier te doen dat het voor de hele universiteit bruikbaar
is. Daarnaast moet er gekeken worden naar systemen die er nu al zijn, wat voor
informatie daarin is opgeslagen. Dus daar ligt de nadruk op praten.
Vandewall: Dan kom je de omvang van de organisatie tegen. Het
liefst wil je iedereen bedienen in één systeem, maar je kan niet alles
mogelijk maken, dan wordt het chaotisch door het teveel aan mogelijkheden. Je
moet een gulden middenweg vinden tussen flexibiliteit en overzichtelijkheid.
Niemand heeft zin om een formulier met 500 velden in te vullen om één
bericht aan te maken.
Is één systeem wel haalbaar?
Vandewall (lacht): Dat is het uitgangspunt van het
Webplatformproject. Dus we gaan het proberen.
Saaman: Het kost vrij veel moeite, maar ik denk dat we er wel
uitkomen. Over het algemeen zijn daar wel goeie trucs voor te verzinnen. Als
je dat niet doet, stort het hele kaartenhuis als het ware in elkaar. Als op
een gegeven moment iedereen z’n eigen definitie heeft van wat bijvoorbeeld
een cursus of een college is, geeft dat veel extra programmeerwerk. Dat moet
voor al die mensen apart worden geprogrammeerd, maar voor de eindgebruiker
zijn de gegevens onderling ook niet meer vergelijkbaar met elkaar. Het wordt
ook heel moeilijk om in één keer door alle cursussen heen te gaan zoeken.
Het is duidelijk dat het een hele organisatieverandering is, omdat mensen
ineens gedwongen worden om in meer uniforme terminologie te praten over hun
bedrijfsprocessen.
Vandewall: Dat gezamenlijke systeem dat er straks komt, moet op een
of andere manier voordelen bieden die er anders niet waren geweest. Eén
daarvan is het schaalvoordeel. Een bepaalde functionaliteit hoef je maar één
keer uit te programmeren om hem daarna binnen verschillende portals te kunnen
gebruiken. Daar kun je winst op boeken in termen van tijd.
Een ander argument is de uniformiteit naar buiten toe, de uitstraling. En als
er eenmaal een goed systeem is, wordt het voor de gebruikers steeds
eenvoudiger om mee te werken. Als je eenmaal een bepaalde functie hebt
geleerd, dan kun je die meenemen naar de andere plek waar je er mee werkt,
want het is ongeveer hetzelfde systeem.
Wat vinden jullie eigenlijk van de keuze voor dit Content Management
Systeem? Want die was al gemaakt voordat jullie bij het project betrokken
raakten.
Saaman: Ik ben wel een beetje blij dat die beslissing al genomen
was, dat ik me daar niet mee bezig hoefde te houden. Eigenlijk moet je bij dit
soort situaties gaan kijken wat er gebeurt met bestaande systemen die op de
markt beschikbaar zijn. De consensus daarover in het veld is dat daar nog geen
goed systeem voor is. En dan kom je op de hele moeilijke beslissing of je
gedeeltelijk zelf moet gaan ontwikkelen.
Voor alle duidelijkheid: wij ontwikkelen niet alles helemaal zelf. Dat lijkt
misschien wel zo, maar wij gebruiken een basissysteem waarop wij onze eigen
toepassingen bouwen. En dat is waar de mensen mee geconfronteerd worden.
Daarom lijkt het misschien of we alles zelf maken, maar dat is beslist niet
waar.
Wat je nu ook wat meer ziet zijn projecten die zich bezig houden met portals.
Daar worden de sites en toepassingen gelaten zoals ze zijn en er wordt een
schilletje overheen gebouwd die informatie uit de verschillende websites trekt
en tot een persoonlijke startpagina samenbundelt. Dat zijn wat andere
benaderingen. Aan de andere kant denk ik wel dat er instellingen moeten zijn
die de nek uitsteken en nieuwe systemen ontwikkelen, anders gebeurt het nooit.
Blackboard
Blackboard, het programma voor de elektronische leeromgeving Nestor, was
wel een product toen we het kochten, maar is ook ontstaan als een project dat
op een universiteit draaide. Al dat soort dingen zijn ontstaan op de plek waar
de behoefte bestaat. Wij merken nu ook landelijk dat er erg veel
belangstelling voor ons project is. Onze opzet is toch vrij vernieuwend. We
hebben veel rondgevraagd en met andere mensen gesproken over wat zij van deze
opzet vonden. En eigenlijk is het unanieme oordeel dat dit de manier is waarop
je het zou moeten doen.
De Universiteit van Amsterdam maakt gebruik van het Content Management
Systeem van Spectra, dat was hier ook eerst de bedoeling. Waren jullie ook
betrokken bij de beslissing om daar vanaf te zien?
Vandewall: We hebben een experiment gedaan met de programmeertaal
van Spectra, Cold Fusion en vanuit Informatica-oogpunt was dat niet zo
positief. Het is een scripttaal en het heeft dus niet de betrouwbaarheid van
een taal als Java. Wij vroegen ons af of daarin wel zo’n enorm groot systeem
gebouwd kon worden. Oracle – wat we nu gebruiken - biedt daarbij met Java
samen sowieso een betere basis. Daarnaast ging het verhaal dat Spectra niet
verder werd ontwikkeld door de makers.
Saaman: Dat ligt nu inderdaad ook echt stil. De UvA had al
uitgebreide ervaring met het programmeren in Cold Fusion, wij niet. Er waren
wel mensen die een cursus hadden gedaan, maar de ervaring hadden ze niet.
Volgens de visie van de fabrikant zou je minstens een jaar lang Cold
Fusion-ervaring moeten hebben voordat je met Spectra kan beginnen.
En wat ook heel belangrijk is, wij hebben ons functioneel ontwerp naast
Spectra gelegd en advies gevraagd aan externe bedrijven met de vraag of we dit
met Spectra kunnen bouwen. De uitkomst was dat het wel kan, maar eigenlijk
moet je alles zelf bouwen. Spectra bevat een programmeertaal, dus kan dat,
maar het idee van Spectra was dat een heleboel dingen al voor ons gedaan
zouden zijn. Maar die dingen, bijvoorbeeld het opbouwen van webpagina’s en
het maken van editors zijn zo fundamenteel anders dan wat wij wilden, dat het
er uiteindelijk op neerkomt dat je dat of allemaal niet moet gebruiken of
allemaal moet gaan aanpassen. Dat zie je ook terug bij bestaande projecten. Er
wordt eigenlijk heel weinig van Spectra gebruikt, maar met de programmeertaal
Cold Fusion wordt er van alles omheen geprogrammeerd. Dus alhoewel het wel
even slikken was, denk ik dat we uiteindelijk wel heel erg blij zijn dat we
daar niet mee verder zijn gegaan.
Dus jullie zijn ongetwijfeld tevreden met de stand van zaken op dit moment?
Vandewall: Ja. Het is nog niet klaar, maar wanneer is iets klaar?
Er zijn nog altijd nieuwe wensen. In die zin is het nog niet klaar.
Saaman: Dat is heel moeilijk omdat we vrij veel tijd hebben moeten
besteden aan een aantal basisprincipes die er in gelegd zijn, maar waar we
straks op kunnen oogsten en voordeel mee kunnen behalen. Met deze aanpak krijg
je in het begin al heel snel het gevoel dat wanneer we op de ouderwetse manier
een paar sites hadden gebouwd, we veel sneller klaar waren geweest. Het
oogsten komt pas daarna, omdat er met het oog op de toekomst is gebouwd. Dat
moet het komende jaar gaan blijken.
Omdat we al wat langer rondlopen bij de universiteit, weten we wat voor soort
projecten er zijn en wat voor soort behoeftes er zijn. Daar hebben we op
ingespeeld. Dan kunnen we bewijzen dat we veel sneller in staat zijn op dingen
in te spelen dan daarvoor mogelijk was. Dat is absoluut een succesmaatstaf.
Hoe zit het met de functionaliteiten van de huidige site die in de nieuwe
situatie nog niet werken?
Saaman: Een groot gedeelte van het basiswerk daarvoor is al wel
verricht. Alleen moet het dan in de applicatie, die specifieke website, nog
wel worden toegepast. En we weten niet helemaal zeker wat daar nog achter weg
komt. De formulieren bijvoorbeeld, die waren er al lang maar we hebben heel
duidelijk eerst de prioriteit gesteld bij het statische gedeelte, het
verzamelen en presenteren van de informatie, en dan de meer
transactieverwerkende dingen pas later.
Vandewall: En de layout, de uitstraling, daar wordt ook veel tijd
in gestoken. Dat er een heel aantrekkelijke website wordt gemaakt. Dat zijn de
dingen die je bij zo’n eerste keer live gaan als eerste voelt.
En het is zo dat de oude site door ons niet wordt afgeschaft op het moment dat
de nieuwe bestaat. Er mag dus best worden ‘gelinked’ naar functionaliteit
die niet door ons wordt aangeboden. Maar op termijn komt daar gewoon een
oplossing voor. En het idee is dan dat die oplossing – dat proberen wij altijd –
mooier is dan wat er tot nu toe is. De mensen denken misschien ‘nou,
formuliertje erin gooien, dat is toch niet zo moeilijk’. Maar wil je dat
mooi doen, wil je een stapje verder komen dan de stand van zaken van vijf jaar
geleden, in gebruiksvriendelijkheid bijvoorbeeld, of in layout, dan kost dat
meer tijd. In die zin proberen wij allerlei functies naar een hoger niveau te
tillen.
Alleen de oude site van een nieuwe smoel voorzien moet eigenlijk geen einddoel
zijn voor de nieuwe website. We willen inhoudelijk uiteindelijk ook een beter
product leveren.
Wat is jullie grootste frustratie op dit moment wat betreft het
webplatform?
Saaman: Ik denk dat de grootste frustraties de technische
verrassingen zijn die je steeds weer tegenkomt. Die zijn absoluut niet te
voorspellen bij dit soort trajecten, waardoor de planning heel erg lastig is.
Mensen hebben daar wat onbegrip voor, die willen van tevoren weten hoeveel
weken het duurt. Dat kan je alleen maar doen met projecten die je al eens
eerder hebt gedaan. Bij de Deltawerken konden ze van tevoren ook niet precies
zeggen hoe lang dat zou gaan duren, want dat hadden ze nog niet eerder
gemaakt.
Vandewall: Je wilt als universiteit graag vooruitstrevend zijn,
maar dan moet je als universiteit er mee akkoord gaan dat bepaalde dingen niet
voorspoedig lopen of onvoorspelbaar zijn. Dat is iets waar je tegenaan loopt.
Maar dan vind je ook wel weer begrip als je uiteindelijk wel iets oplevert wat
vernieuwend is.
Maar soms moet je even je adem inhouden en anderen er ook van
proberen te overtuigen dat ze even de adem moeten inhouden om te wachten op de
volgende versie.
Halen we 1 februari?
Vandewall: Ja. Technisch gezien dan, want er moet wel nog een
heleboel informatie worden overgezet. Mensen die alvast een kijkje willen
nemen, kunnen dat doen op
index Pictogram 6
