Nu werd het tijd om de gewenste situatie van het systeem uit te gaan werken. Hiervoor was allereerst meer kennis nodig van de doelgroep om de eisen van het systeem vast te kunnen stellen. In de omschrijving in de definitiestudie werd bewust gekozen om het systeem als geheel te beschrijven. Zodat het verslag niet beperkt zou blijven tot de, volgens de opdrachtomschrijving, te ontwikkelen delen. Dit had twee redenen: de eerste, omdat er nog helemaal geen omschrijving was uitgewerkt op papier. En ten tweede, omdat er enige twijfel bestond of het wel bij uitbouwen zou blijven.
6.1 De doelgroep(en) beschrijven
In het begin van het uitwerken van de doelgroep werd eerst gedacht aan een uitgebreide doelgroep: de klant. De klant zou een persoon zijn, mogelijk een leek op het gebied van web development, die werkte voor een middelgroot bedrijf. De sector kan variëren van de reissector, waarin ‘Bonaire Fun Travel’ zich in bevindt, tot de sportsector of de horeca.
De sector zou geen verschil mogen uitmaken.
Bij het uitwerken van de doelgroep werd tegelijkertijd gedacht aan de systeemeisen die het met zich mee zou brengen. Op deze manier kwam de stagiair erachter dat het niet juist was om slechts rekening te houden met maar één uitgebreide doelgroep. Er waren er drie: de klant, de bezoeker van de website van die klant en de beheerders van de applicatie; de programmeurs, ofwel de stagiair en de opdrachtgever.
Hieronder volgt een beschrijving van de doelgroepen waarin gelijk een aantal ideeën van het systeemconcept verwerkt zijn:
6.1.1 Klanten
De eerste doelgroep is de groep waar het nieuwe product in eerste instantie voor wordt ontwikkeld. De klant is de afnemer van Flexcite. De klant ‘koopt’ het CMS inclusief het ontwerp en de uitwerking van hun eigen website die door de beheerders wordt geleverd.
Hierna kan de klant zijn eigen website online onderhouden en desgewenst aanpassen.
De klant krijgt op een eigen ‘account’ met wachtwoord en heeft op deze manier toegang tot de centrale bestanden die het CMS Flexcite vormen. Daarnaast heeft hij een eigen database waarin zijn gegevens worden opgeslagen. In een centrale database staan zijn inloggegevens geregistreerd en eventuele nodige gegevens om de voorkant van het CMS op te bouwen. Hieruit ontstond het idee om twee databases uit te werken: een voor de beheerder, de admin-database, om de klanten en het CMS zelf in te beheren en per klant nog een database waar zij hun website in konden beheren.
Het CMS bestaat uit verschillende modules als bijvoorbeeld het winkelwagentje, sitemap en een forum (dit zijn advanced modules die voorlopig nog niet beschikbaar zouden zijn, maar wel gepland werden voor ontwikkeling). Welke van deze modules beschikbaar zijn voor de klant staan ook opgenomen in de admin-database. De klant kan zijn beschikbare modules uitbreiden door gewenste modules erbij te kopen. Hieruit kan opgemaakt
worden dat Flexcite als geheel dient als achterkant van de website van de klant.
6.1.2 Bezoekers
De bezoekers zijn bezoekers van de website van de klanten. Mogelijk kunnen zij producten kopen bij de klant of alleen informatie opvragen. De mogelijkheden die de bezoeker heeft op de website zijn beperkt naar het aantal modules waarover de klant beschikt. Eventuele wensen die een bezoeker zou hebben tegenover de klant zou hij bij de klant in kunnen dienen. De klant kan in zo’n geval contact opnemen met de beheerder van Flexcite om te vragen naar de mogelijkheden. Er is geen direct contact tussen de bezoeker en de beheerder.
Afstudeerverslag januari 2005
Pagina 22 van 267
6.1.3 Beheerder
De beheerder is de beheerder, de programmeur van Flexcite. Het product blijft centraal bij de beheerder en deze zal dan ook zorg dragen voor de verdere ontwikkeling van het product. De klant krijgt niet de bestanden tot zijn beschikking, maar maakt contact met Flexcite via dummy bestanden, die verwijzen naar de werkelijke bestanden. Afhankelijk van de gegevens van de klant in de centrale admin-database ‘weet’ Flexcite welke database hij aan moet spreken en in welke database hij de gegevens moet opslaan.
De beheerder houdt zich alleen in het begin bezig met de website van de klant. Na aflevering van het de website, dat uiteraard voorafgaand aan de aflevering door de klant zelf is goedgekeurd, komt het verdere onderhoud van de website voor rekening van de klant. De beheerder zorgt wel voor ondersteunend materiaal en is desnoods, mogelijk tegen betaling, bereikbaar als adviseur.
De doelgroepen werd vervolgens uitgewerkt door middel van persona’s. Er werd voor persona’s gekozen omdat er geen echte heldere doelgroep was om te beschrijven. De persona’s zijn gebaseerd op de bestaande klanten en geïnteresseerden en de
beschrijving van de doelgroepen waar de opdrachtgever zich op wilde richten. Het belangrijkste uit deze omschrijving is dat een leek op ICT-gebied het programma moet kunnen bedienen en zo een website kan opbouwen en onderhouden.
De volgende persona klopt het meest met de beschrijving van de doelgroep van de klant:
6.1.4 Persona: Pietje
Pietje is een man van 55 jaar en werkt voor een basisschool in een kleine plaats in Gelderland. De school loopt goed en had nogal vaak nieuws om uit te brengen. De wekelijkse schoolkrant voldeed niet meer aan het aanbod aan artikelen dat er binnenkwam (inclusief de vele creatieve inzendingen van de kinderen). De leiding van de school had besloten om op de website van de school een nieuwsrubriek aan te maken. Het standaard programma van Microsoft, Frontpage, dat tot nu toe werd gebruikt, maakte het niet
makkelijk om de inhoud steeds te updaten.
De oplossing die ze vonden was Flexcite en Pietje werd aangesteld als redacteur van het schoolkrant nieuws. Sindsdien werkt hij veel met ‘Edit content’ van de schoolsite. Ook het uiterlijk van de site was er flink op vooruit gegaan nu ze over waren gestapt op Flexcite.
Dit is slechts een voorbeeld van een persoon die Flexcite in gebruik zou kunnen nemen.
Later in de planning stond een uitgebreider onderzoek naar de doelgroep, met als doel nieuwe potentiële klanten aan te spreken die dan gelijk mee konden doen aan het testen.
Om echter nieuwe klanten te werven zou het mogelijk moeten zijn om een betere indruk van het systeem achter te laten dan een halve indruk. Dit uitgebreidere onderzoek staat zeker nog op de planning, maar niet meer binnen de afstudeerperiode.
Afstudeerverslag januari 2005
Pagina 23 van 267
6.2 Het vaststellen van de systeemeisen
Nadat de doelgroepen redelijk bekend en omschreven waren kon er met die groepen in gedachten gekeken worden naar de eisen die gesteld zouden worden aan het gehele programma.
Het doel van het programma is het opbouwen en onderhouden van een website. De eisen die aan het programma gesteld worden zijn de eisen die een klant aan zijn website stelt.
Er moet tenslotte een website mee opgebouwd kunnen worden die bevat wat de klant wil aanbieden aan zijn bezoekers. Vanuit deze gedachte is er nog een stap terug genomen naar de bezoekers op internet. Wat verwachten bezoekers op een website van een klant uit de betreffende doelgroep aan te treffen. Het eerste dat dan natuurlijk bedacht wordt is informatie over de eigenaar van die website. De functie om deze ‘content’ te plaatsen en te bewerken heeft zijn plaats gekregen in het systeem onder ‘Edit content’. Juist omdat dat deel zo belangrijk is was dit het eerste deel dat in de eerste versie van het programma aanwezig was. Samen met de mogelijkheid om bestanden (afbeeldingen) te uploaden om tekst af te kunnen wisselen met plaatjes.
Alle overige delen van een website, zoals de pagina indeling, gebeurde tot nog toe in de database. Door de gegevens en de instellingen hier rechtstreeks in te vullen.
Een andere belangrijke eis die veel aan websites gesteld wordt is dat er een bezoeker kan navigeren. Bezoekers op internet klikken graag door, op zoek naar iets wat hen interesseert. Om te kunnen navigeren is er een menu nodig. Klanten konden met eerste versie van Flexcite wel een dynamisch menu onderhouden als deze was gebaseerd op de titels van content, maar buitenom dat konden er geen vaste menu’s onderhouden
worden door de klant zelf. Dit was het doel achter het deel ‘Edit menu’ wat in de opdrachtomschrijving opgenomen was.
Zo waren er nog veel meer eisen te bedenken van wat een bezoeker op internet zou willen zien op een website of wat een klant zou willen kunnen
aanbieden, zoals bijvoorbeeld een webwinkel. Op deze toer zijn allerlei mogelijke systeemeisen bedacht. Ook is er een enquête opgezet en is er aan de huidige klanten van Flexcite gevraagd om hun wensen door te geven. Het was oorspronkelijk de bedoeling dat er een workshop gehouden zou worden om deze eisen op te stellen. Eerder is al vermeld dat deze niet kon doorgaan door een verbouwing in het pand van ‘Bonaire Fun Travel’.
Het resultaat van de enquête was vrij mager, maar deze zijn toch meegenomen bij het overleg wat volgde.
De stagiair had vervolgens een overleg gepland met de opdrachtgever om de aandachtspunten uit de ontwikkelmethode te bespreken. De stagiair had gekozen om de bespreking formeel op te stellen en had een vijfstappenplan uitgewerkt om in de bespreking de ideeën voor wijzigingen op de bestaande delen, de systeemeisen, het systeemconcept, de technische structuur en het pilotplan te bespreken. De termen van de ontwikkelmethode kwamen hier vooral in naar voren en het zou aan de stagiair zijn deze termen uit te leggen aan de opdrachtgever om vervolgens zeer gericht het overleg door te lopen.
De situatie waarin het overleg werd uitgevoerd werd echter vrij informeel. En de stagiair had moeite met het uitleggen van de termen van de ontwikkelmethode. Het resultaat
Afstudeerverslag januari 2005
Pagina 24 van 267
was een vrij vlot gesprek waaruit de conclusie kwam dat de stagiair dit beter zelf onder handen kon nemen waarna zijn werk in een overleg besproken zou worden. Dit was niet echt het doel van de stagiair, maar een betere oplossing was er op dat moment niet te vinden.
Bij nader inzien was het doel van de stagiair, een complete lijst met eisen, beter te verkrijgen geweest met andere vragen, waarin er helemaal geen termen van de
ontwikkelmethode naar boven waren gekomen. Een open vraag als “wat moet er met het programma gedaan kunnen worden” zou meer respons uitlokken dan de constatering dat er systeemeisen opgesteld moeten worden om het programma hierop te kunnen testen.
De stagiair is vervolgens zelfstandig verder gegaan met het opstellen van systeemeisen gebaseerd op de doelgroepen en op wat eerder besproken was. Hierbij is eerst rekening gehouden met wat een bezoeker zou verwachten tegen te komen, daarna wat een klant eventueel extra zou willen aanbieden en als laatst dat wat het ons als programmeurs gemakkelijker zou maken. Daarbij moest alles ook flexibel op te zetten zijn voor de klant.
Het prioriteren gebeurde volgende de door IAD gebruikte BCL-methode. Basis, Comfort, Luxe.
‘Edit content’ en ‘Upload images’ werden uiteraard op de basislijst geplaatst. Op het moment dat werd besloten de hele database om te gooien waren deze delen weer de eerste die ontwikkeld diende te worden. Hier zal later op terug gekomen worden. Na het bepalen van de systeemeisen werd namelijk eerst een systeemconcept uitgewerkt. De eerste stappen tot het besluit om ‘from scratch’ te beginnen werden hierbij gezet.
Naast deze eisen werden er ook interface-, integriteits-, performance- en operationele eisen opgesteld. Dit zijn veelal eisen die door middel van website principes tot stand zijn gekomen. Online zijn veel resultaten te vinden indien men zoekt op “web design
principles” of tips. De resultaten zijn veelal aandachtspunten waar veel mensen rekening mee houden bij het ontwerp van hun website. Ook vind je op die manier
aandachtspunten die door schrijvers als Ben Schneidermann en Donald Norman over user interface design opgesteld zijn.
Niet alle principes van met betrekking tot GUI-design gaan ook op voor het ontwerpen van websites. De applicatie is echter een combinatie van een programma en een website en er moest ook een tussenweg gevonden worden tussen de verschillen die er bestaan tussen de principes die er zijn voor GUI-design en webdesign.
Uit de lijst van principes en uit wat de stagiair vanuit de opleiding heeft meegekregen zijn een aantal belangrijke aandachtspunten gehaald. Met name valt hierbij te denken aan bruikbaarheid en flexibiliteit en de capaciteit van mensen om zeven dingen te onthouden, aldus Norman. Deze aandachtspunten zijn vervolgens besproken en wel of niet, of hoe er met het punt omgegaan zou worden, opgenomen bij deze eisen.
De meest geheugenwaardige eis die er hier tussen is gekomen is de eis dat het uitvoeren van een actie binnen het CMS bij een gebruiker die een internetverbinding heeft op een 56k modem niet langer mag duren dan 10 seconden. De reactie van de heer Smits was:
“Slik”. Na het testen is echter gebleken dat de nieuwe versie van Flexcite ook hieraan voldoet. Nadere testen moeten dit verder nog bevestigen als het systeem werkelijk in gebruik is, maar tot nu toe, aan het eind van de afstudeerperiode, zijn de resultaten positief.
6.3 Het systeemconcept voor de gewenste situatie opzetten
Om vanuit systeemeisen en de omschrijving van de huidige situatie over te gaan op de beschrijving van het systeemconcept bleek meer moeite te kosten dan verwacht. Voor het beschrijven van de huidige situatie was er gebruikt gemaakt van uitgebreide
Afstudeerverslag januari 2005
Pagina 25 van 267
scenario’s en taakdiagrammen. Het doel was in eerste instantie om ook dezelfde stukken te beschrijven voor de gewenste situatie en hier is vervolgens een start aan gemaakt.
Inmiddels zaten we in de vierde week sinds de start en volgens de planning was er na deze week nog een extra week om de
definitiestudie af te ronden en te beginnen aan de ontwikkeling van de eerste pilot; ‘Edit menu’. Dit maakte de tijd vrij krap voor een uitgebreide beschrijving.
figuur 5.1: taakdiagram ‘Edit content’
Bij het uitwerken van de taakdiagrammen voor de gewenste situatie werd er verder voornamelijk aandacht besteed aan de delen die uitgewerkt zouden worden. Andere delen die wel opgenomen waren in de systeemeisen, maar pas voor later tijdstip zouden zijn, werden zoveel mogelijk achterwege gelaten. Wel werd er gekeken naar mogelijke overeenkomsten, maar er werden geen schema’s en of diagrammen voor deze delen uitgewerkt.
Er werd getracht om de delen zoveel mogelijk te baseren op de bestaande delen, zodat de werkwijze consistent zou blijven en gebruikers van de eerste versie van Flexcite ook gemakkelijk de werkwijze van deze aanvullende modules zouden oppakken. Ondertussen werd er nagedacht over de technische details achter deze aanpak, zoals de aanpassingen aan de database. Ook werden er voor ‘Edit content’ een paar kleine wijzigingen
opgesteld, omdat deze in de gewenste situatie extra mogelijkheden zou krijgen.
6.4 De definitiestudie afronden
Om de definitiestudie af te ronden was er nog het een en ander aan informatie nodig. Zo moesten er nog systeemeisen worden gesteld voor de systemen die gebruikers zouden moeten hebben. Ook moest er nog informatie over de organisatorische inrichting gegeven worden. En als laatste, maar zeker niet minst belangrijke: een pilotplan.
De systeemeisen mochten niet te hoog zijn. Het systeem is tenslotte vormgegeven in een website en zal via internet moeten kunnen functioneren. Er zijn dan vrijwel geen eisen aan het systeem zelf te noemen. Zeker niet omdat de meeste computers tegenwoordig heel snel werken. Het punt waar het echter op fout kon lopen is de internetverbinding.
Toch is hiervoor als minimale eis gesteld: een 56kbps verbinding met modem. Ook de schermresolutie was iets waar rekening mee gehouden moest worden. De minimale eis daarvoor werd gesteld op 800 x 600. Het programma is daarom ook volledig zichtbaar binnen die resolutie.
De aanbevolen eisen zijn ook beperkt gehouden en zijn een beetje de configuratie die een gemiddeld gezin in Nederland toch wel heeft staan. Niet het beste van het beste. Dat mag voor dit CMS niet nodig zijn.
De veranderingen binnen een bedrijf met behulp van Flexcite zijn vrij moeilijk te
voorspellen. Om die reden is de beschrijving van de organisatorische inrichting beperkt gebleven.
Afstudeerverslag januari 2005
Pagina 26 van 267
Vervolgens werd het pilotplan opgezet, een opeenvolging van pilots. Dit plan werd gebaseerd op het oorspronkelijke idee, dat de opdracht bestond uit het ontwikkelen van vier delen van het systeem. Hierop volgden de delen die belangrijk waren voor een uitgebreid systeem. En als laatste de ideeën om het systeem volledig compleet te maken.
Inmiddels was er ook al een start gemaakt aan het uitwerken van de aanpassingen voor de database, voor de eerste pilot ‘Edit menu’. Voor de definitiestudie is als laatste nog een klassendiagram uitgewerkt. Om tijd te besparen is in eerste instantie opgenomen klassendiagram een representatie geworden van de bestaande database, aangevuld met de nodige tabellen om de nieuwe functionaliteiten te kunnen ondersteunen. Op dit
moment was de beslissing nog niet genomen om een nieuwe start te maken. Ook was de opdrachtgever niet erg enthousiast over het idee om een de gehele database opnieuw op te bouwen. Eerst was er meer informatie nodig om de opdrachtgever te overtuigen. Er zou ook duidelijk voordeel mee te behalen moeten zijn. Het zou namelijk veel meer werk kosten en het project zou er zeer waarschijnlijk langer door gaan duren.
Afstudeerverslag januari 2005
Pagina 27 van 267