Afstudeerverslag. 14 januari Mw. J.M.A. Ruigt

(1)

Auteur: Arjan Bos

In opdracht van Coro Reizen & IT services BV en Interactief Smeedwerk Haagse Hogeschool - Studentnummer 99004648 – Afstuderen I&I VIA 2004-2.1

Afstudeerperiode van 30 augustus 2004 tot 14 januari 2005

Afstudeerverslag

14 januari 2004

Examinatoren: Dhr. J.H. Graven

Mw. J.M.A. Ruigt

(2)

Afstudeerverslag januari 2005

Pagina 2 van 267

Afstudeerverslag

(3)

Referaat

Arjan Bos, eindverslag Flexcite, Coro Reizen en IT services BV, Baarn januari 2005.

Stagiair, Arjan Bos, heeft in de periode van 30 augustus 2004 tot 14 januari 2005 zijn afstudeeropdracht voltooid bij Coro Reizen en IT services BV, te Baarn. Dit verslag gaat dieper in op de achtergronden van het project en de opgeleverde producten. Daarnaast zal uitvoerig een beschrijving worden gegeven van de uitgevoerde werkzaamheden.

Tenslotte worden het proces en het product door de auteur geëvalueerd.

Descriptoren:

- Content Management Systeem (CMS) - PHP;

- MySQL;

- JavaScript;

- (D)HTML;

- Internet;

- Online;

- IAD;

- GUIDE;

(4)

Voorwoord

Baarn, 14-01-2005

Als afstudeeropdracht heb ik in de periode van 30 augustus 2004 tot 14 januari 2005 het deelproject Flexcite succesvol voltooid bij ‘Coro Reizen en IT services BV’. Mijn

bedrijfsbegeleider daar was Sander de Rooij. De opdracht diende ter afsluiting van mijn opleiding ‘Vormgeving en ontwerp van InterActie’ (VIA). Dit is een ‘Informatie en Informatiekunde’ (I&I) opleiding aan de Haagse Hogeschool. Het doel van dit verslag is om u, als lezer, een duidelijk inzicht te geven over het proces dat ik heb doorlopen om tot het eindresultaat te komen en wat het eindresultaat werkelijk is geworden.

Graag wil ik hier van de gelegenheid gebruik maken om een aantal mensen te bedanken.

Als eerste wil ik graag mijn bedrijfsmentor, Sander de Rooij, bedanken voor de fijne samenwerking en zijn inzichten in het programmeerwerk. Daarnaast wil ik Koen Smits bedanken voor het werk dat hij in de ontwerpen heeft gestoken en de leerzame opmerkingen met betrekking tot mijn verslaglegging. Verder bedank ik mijn examinatoren, Jim Graven en Hanriëtte Ruigt, voor hun uitvoering van een ondersteunende taak bij mijn afstuderen. Ook wil ik de heer Mark Parisi, van

www.offthemark.com bedanken voor zijn komische, computergerelateerde strips die mijn verslag een luchtige tint meegeven. Als laatste, maar zeker niet de minste, wil ik graag de medewerkers van ‘Bonaire Fun Travel’ en ‘Selamat Jalan Tours’ bedanken voor de gezelligheid op de werkvloer.

Bedankt!

Arjan Bos

(5)

Inhoudsopgave

1. Inleiding... 7

2. Het bedrijf en de achtergrond van de opdracht ... 8

3. Het uitwerken van de opdrachtomschrijving en het plan van aanpak... 10

3.1 Het concept van Flexcite beschrijven... 10

3.2 De probleemstelling opstellen... 11

3.3 Doelstelling uitwerken... 11

3.4 De uitgangssituatie beschrijven... 12

3.5 Te gebruiken methoden en technieken uitzoeken ... 12

3.5.1 IAD of DSDM... 12

3.5.2 De technieken ... 14

3.6 Op te leveren producten en diensten uitwerken ... 14

3.7 Werkzaamheden (fasering en activiteiten) onderscheiden... 15

3.8 Risicofactoren bepalen en opvangen ... 16

3.9 Plannen... 17

4. Het analyseren van de bestaande delen van Flexcite... 18

5. Het beschrijven van de huidige situatie... 20

6. De definitiestudie uitwerken ... 21

6.1 De doelgroep(en) beschrijven ... 21

6.1.1 Klanten... 21

6.1.2 Bezoekers ... 21

6.1.3 Beheerder ... 22

6.1.4 Persona: Pietje... 22

6.2 Het vaststellen van de systeemeisen... 23

6.3 Het systeemconcept voor de gewenste situatie opzetten ... 24

6.4 De definitiestudie afronden ... 25

7. Het ontwikkelen van de pilots... 27

7.1 Het ontwerpen van ‘Edit menu’ ... 27

7.2 Het herontwerpen van de gehele database ... 28

7.3 Een verbeterd concept uitwerken ... 29

7.4 De algemene opbouw opnieuw uitwerken... 30

7.5 Het opbouwen van de nieuwe versie ... 31

7.6 De definitiestudie aanpassen ... 32

7.7 Uitwerken van de nieuwe planning ... 34

7.8 Het uitwerken van pilot 3; Edit/Settings 1 ... 35

7.8.1 Een nieuwe werkwijze... 35

7.8.2 Het gebruik van brede functies ... 36

7.8.3 De formulieren... 38

7.8.4 Uitzonderlijk multimedia ... 38

7.8.5 De ‘save’-module ... 39

7.8.6 Iframe ‘action’... 39

7.8.7 Nieuwsfunctie... 40

8. Het testen van Flexcite ... 41

8.1 Testen tijdens het programmeren ... 41

8.1.1 Kleine problemen ... 41

(6)

8.1.2 Problemen met ‘Div’-tags... 42

8.1.3 Aanpassingen op de database... 43

8.1.4 Speciale HTML tekens... 43

8.1.5 Afwijkingen tussen verschillende browsers... 44

8.2 Testen na afloop van het programmeren ... 45

9. Functionaliteiten van Flexcite... 46

10. Projectorganisatie... 48

10.1 Gebruikte technieken ... 48

10.2 Rolverdeling en verantwoordelijkheden... 49

10.3 Gebruikte software ... 49

11. Evaluatie... 50

11.1 Proces... 50

11.2 Product ... 50

11.3 Conclusie ... 51

12. Samenvatting ... 52

(7)

1. Inleiding

In dit document vindt u een beschrijving van het proces dat stagiair, Arjan Bos, heeft afgelegd bij de realisatie van zijn afstudeeropdracht, getiteld Flexcite, bij ‘Coro Reizen en IT services BV.’

Flexcite is een online website ontwerppakket en content management systeem (CMS) waarmee het mogelijk is om een website op te zetten en de inhoud hiervan te

onderhouden. Op de website http://www.flexcite.nl vindt u ook informatie over dit online programma.

Dit document beschrijft het proces dat is doorlopen, door middel van een aantal

activiteiten. Deze activiteiten zijn onderverdeeld in verschillende fasen waaruit het proces bestaat. Die fasen zijn weer gerelateerd aan de fasen van de gebruikte

ontwikkelmethode, IAD; definitiestudie, pilotontwikkeling en invoering.

De activiteiten zullen behandeld worden in een logische volgorde. Het kan bijvoorbeeld zo zijn dat er al een start was gemaakt aan een volgend document terwijl de ontwikkeling van het voorgaande deel nog niet was afgerond. In de beschrijving hiervan zal eerst het eerste deel worden afgerond, voordat de beschrijving van het volgende document zijn plek zal krijgen.

In hoofdstuk 2 wordt een beschrijving van de werkplek gegeven om voor u, als lezer, duidelijk te maken hoe deze was en in welke omstandigheden er werd gewerkt.

Vervolgens zal de opdrachtomschrijving tezamen met het plan van aanpak in hoofdstuk 3 worden beschreven. Dit waren de eerste documenten die tot stand kwamen en deze beschrijven de opstart en de planning voor de hele afstudeerperiode. Naarmate het project verder op gang kwam is de planning enigszins gewijzigd. In eerste instantie beginnen we met de planning zoals deze initieel was. Op deze manier kunnen we vanaf het begin de ingeslagen wegen volgen. Zo is ook het moment, dat er gekozen werd om een andere weg in te slaan, duidelijker aan te geven in een later hoofdstuk.

Na hoofdstuk 3 gaan we verder met de beschrijving van de uitvoering van de activiteiten.

Welke worden benoemd in de planning in hoofdstuk 3. Te beginnen met het analyseren van de eerdere versie van Flexcite in hoofdstuk 4. In aansluiting hierop wordt in

Hoofdstuk 5 en 6 de totstandkoming van de definitiestudie beschreven.

Hoofdstuk 7 is vervolgens de plaats waar veel informatie gevonden kan worden over de wijzingen in de planning en de doelstelling van het project. Tijdens het onderzoek voor het programmeerwerk en het uitwerken van de pilotontwikkelplannen, werd het duidelijk dat een andere aanpak noodzakelijk was.

In hoofdstuk 8 gaan we dieper in op de problemen die ontstonden tijdens het

programmeren. Om deze problemen te kunnen onderbouwen, wordt er daar ook meer aandacht gegeven aan de technische details.

Ter afronding zal in hoofdstuk 9 een kort overzicht gegeven worden van de uiteindelijke functionaliteiten die Flexcite zal vervullen. Hoofdstuk 10 maakt vervolgens duidelijk welk mogelijke onderscheid gemaakt kan worden in de projectorganisatie.

Hoofdstuk 11 geeft persoonlijke conclusie van de auteur over het product en het proces.

Besloten zal worden met een korte samenvatting van dit verslag in hoofdstuk 12.

(8)

2. Het bedrijf en de achtergrond van de opdracht

In dit hoofdstuk zal het bedrijf nader beschreven worden om een indruk te geven van de werkomgeving waarin de stagiair zich bevond, tijdens het uitvoeren van de

afstudeeropdracht.

Via de website www.studentenvacature.nl is de stagiair terecht gekomen bij het

familiebedrijf ‘Coro Reizen & IT services BV. Zij werken, onder de handelsnaam ‘Bonaire Fun Travel’ (BFT), voornamelijk als een touroperator. Het bedrijf deelt het pand, waarin zij werken, samen met een andere touroperator, namelijk ‘Selamat Jalan Tours’. Om de link met ICT duidelijk te maken is het een en ander aan achtergrond nodig. Hieronder eerst een overzicht van de indeling van het pand aan de Nieuwstraat in Baarn. Het aantal medewerkers in de ruimtes staat tussen haakjes aangegeven.

Figuur 2.1: plattegrond bedrijven met (#medewerkers), niet op schaal

‘Coro Reizen en IT services BV’ is een familiebedrijf en is met hun handelsnaam ‘Bonaire Fun Travel’ tot stand is gekomen door een sterke affiniteit met Bonaire. De heer Sander de Rooij, opdrachtgever en begeleider van de stagiair, is sinds eind 2001 fulltime deel van het familiebedrijf en werkt daar onder andere aan ICT diensten en producten.

Onder de naam van het familiebedrijf levert de heer De Rooij deze ICT-producten en diensten ook aan externe klanten. Sander de Rooij heeft door middel van zelfstudie het programmeren eigen gemaakt. Hierdoor heeft hij inmiddels een flinke kennis opgebouwd waar het coderen betreft, alsmede vindingrijkheid met betrekking tot het zoeken van oplossingen. Hieronder zullen we een korte geschiedenis geven van het werk dat de heer De Rooij heeft gedaan.

In 1988 is de heer de Rooij begonnen op de automatiseringsafdeling van Lotto Benelux, het sportmerk. Er werd daar een applicatie gebruikt van Triathlon. Hier heeft hij veel fouten uit gehaald, waarna Triathlon hem in dienst nam. Aldaar maakte hij kennis met de

(9)

‘stropdassen’ cultuur, zoals hij dat noemt: werken in groot groepsverband. Kort na zijn start is hij daar nog in zijn proeftijd weer vertrokken.

Hierna werkte hij voor klanten van Triathlon om de problemen in hun pakket aan te pakken. Ook zette hij voor Lotto een netwerk op.

Vanaf ongeveer 1992 begon hij samen met anderen een eigen bedrijf, ‘Fivestar’, waarmee zij als eerste in Nederland zogenaamde kloon-pc’s op de markt brachten. Dit was in het begin een groot succes, maar concurrentie, zoals Vobis en dergelijke, drukte deze business de kop in. Dit bedrijf heeft 3 à 4 jaar geopereerd.

Voordat hij uiteindelijk fulltime bij het familiebedrijf ging werken is hij nog werkzaam geweest voor ECI op de ICT-afdeling en is hij betrokken geweest bij BOL.COM. ECI was eerder een klant van hem in de tijd van ‘Fivestar’.

Voor de touroperator heeft Sander de Rooij inmiddels enkele ICT-producten, als een boekingssysteem en Flexcite, ontwikkeld. Flexcite heeft hij samen ontwikkeld met een goede vriend van hem: Koen Smits. De heer Smits werkt onder de naam ‘Interactief Smeedwerk’ aan dit project. Met name de vormgeving wordt door de heer Smits uitgevoerd. Locatie van de heer Smits is niet van toepassing. Voor overleg is de heer Smits steeds aanwezig op locatie in Baarn.

Vanuit vrienden- en kennissenkring is er interesse getoond in de producten die de heer De Rooij heeft ontwikkeld. Vervolgens zijn de ICT-producten van de heer de Rooij bij verschillende klanten ondergebracht. Deze zitten in diverse sectoren. Zo kan gedacht worden aan de reis-, entertainment- en sport sector.

Inmiddels is een eerdere zeer beperkte versie van Flexcite ondergebracht bij enkele klanten. Nu onderhoudt de heer De Rooij zijn kennis door verder te werken aan verbeteringen aan Flexcite en andere ICT producten.

Bedrijfsgegevens

Naam: Coro Reizen & IT Services BV en Interactief Smeedwerk Locatie: Bonaire Fun Travel / Selamat Jalan Tours

Bezoekadres: Nieuwstraat 11

Postcode: 3743 BK

Plaats: Baarn

Email: info@bonairefuntravel.nl Homepage: www.bonairefuntravel.nl

Indien het web ontwerppakket met CMS goed van de grond komt wordt het mogelijk om eventueel extra personeel in dienst te nemen. Zo kan er steeds meer tijd beschikbaar komen om het pakket verder te ontwikkelen. Ook zouden er eventueel ook nog andere, niet gedefinieerde, ICT-producten ontwikkeld kunnen worden.

Figuur 2.2: verhouding van de bedrijven tot elkaar

Interactief Smeedwerk Pand aan de Nieuwstraat 11 te Baarn:

Selamat Jalan Tours Coro Reizen (BFT) en IT services B.V.

(o.a. Flexcite)

(10)

3. Het uitwerken van de opdrachtomschrijving en het plan van aanpak

De titel van de opdracht draagt de naam van het product: Flexcite. Oorspronkelijk was de opdracht het uitbreiden van de bestaande delen van de applicatie tot een compleet systeem dat het gehele concept van Flexcite tot uiting bracht. Tijdens het eerste gesprek tussen opdrachtgever en de stagiair werd er een uitleg gegeven over het concept van Flexcite en werd er verteld wat er van de stagiair zou worden verwacht. Vanuit de

informatie die onder andere tijdens dit gesprek is verkregen, in de vorm van een verhaal en enkele documenten, is de opdrachtomschrijving uitgewerkt. Deze

opdrachtomschrijving is later uitgewerkt tot een plan van aanpak. Dit hoofdstuk beschrijft de totstandkoming van beide documenten.

3.1 Het concept van Flexcite beschrijven

Flexcite is een website ontwikkelpakket met daarin een content management systeem, waarmee een leek op het gebied van web development zijn eigen website kan opbouwen en onderhouden. Dit kan door middel van een specifieke opzet die als volgt is uitgewerkt.

Een website bestaat uit inhoud. Deze inhoud kan op verschillende manieren worden weergegeven op een website en veelal kan er tussen de verschillende artikelen genavigeerd worden.

Ten tijde van de start van de afstudeerperiode bestond Flexcite uit 2 verschillende hoofddelen, ‘Content’ en ‘Settings’, en twee ondersteunende delen, ‘Stats &

Data’ en ‘Support’. De ondersteunende delen laten we achterwege, omdat dit vrij simpele functies zijn met weinig betekenis voor het project.

Figuur 3.1: het hoofdmenu van Flexcite

Onder ‘Content’ vallen alle delen voor het uitwerken van inhoud: ‘edit content’, ‘edit menu’ en ‘upload images’. Onder settings vallen vervolgens ‘module editor’, ‘style editor’, ‘page structure’, ‘specs settings’

en ‘language settings’. De belangrijke delen zullen later in dit document beschreven worden, om daarna gelijk de nieuwe situatie naast te kunnen leggen.

Op het moment dat het project van start ging waren de delen ‘Edit Content’ en ‘Upload Images’ voltooid.

Het concept van Flexcite ging er oorspronkelijk vanuit dat een website opgebouwd zou worden vanuit modules volgens figuur 3.2: Een header met maximaal drie modules, 4 kolommen met in iedere kolom maximaal 3 modules en een footer met

maximaal 2 modules. Al deze modules werden onder elkaar geplaatst.

Figuur 3.2: de opbouw van een website

(11)

Een module is misschien wel het beste te omschrijven als een groep instellingen om een stuk inhoud op een bepaalde manier weer te geven. Een voorbeeld van een module is het winkelwagentje overzicht, dat bijvoorbeeld alleen de titel van artikelen toont met de specificatie van de prijs. De omschrijving van het artikel wordt in die module niet getoond.

3.2 De probleemstelling opstellen

Hieronder volgt de probleemstelling zoals die voorafgaand aan de opdrachtomschrijving is opgegeven.

Veel bedrijven hebben tegenwoordig wel een website. Vaak zijn deze bedrijven echter afhankelijk van ontwikkelaars die hun website bij moeten houden. Dit komt, omdat de

technieken en kennis bij kleinere bedrijven vaak niet aanwezig zijn. In de meeste gevallen kost het een bedrijf veel geld en tijd om hun website actueel te houden door externen. Flexcite zorgt ervoor dat een leek op het gebied van web development de website van het bedrijf zelf kan onderhouden en aanpassen zonder dat dit hem veel moeite kost.

De heren De Rooij en Smits hadden een start gemaakt met het bouwen van een CMS dat zo uitgebreid zou zijn dat het meer een soort web ontwikkelpakket zou worden. Met Flexcite is een website op te bouwen vanaf het indelen van de onderdelen op de website tot het aanpassen van de Style Sheet. De persoon in kwestie die de website opbouwt hoeft niets af te weten van HTML, CSS, JavaScript, PHP of MySQL. Hierbij komt kijken dat de begrippen zodanig moeten worden omgezet, dat ze ook te begrijpen zijn voor deze gebruikers.

Door de werkdruk van het familiebedrijf, die op de heer De Rooij rust, gaat de ontwikkeling van Flexcite niet erg snel en zeer

ongestructureerd. Tevens bestaat de vraag welke plaats het product kan innemen op de markt.

3.3 Doelstelling uitwerken

Het oorspronkelijke doel van de afstudeeropdracht, was het voltooien van de delen ‘Edit menu’, ‘Module editor’, ‘Page structure’ en ‘Style editor’. Deze delen zouden zijn voltooid indien; de database deze delen ondersteunde, deze delen van de database door middel van formulieren in te vullen zouden zijn en de ondersteunende documentatie, zoals een handleiding, geschreven zou zijn.

Daarnaast zou er een onderzoek gedaan worden naar de plaats van dit programma binnen de markt van het groot en klein bedrijf. Tevens zou het in gebruik worden genomen door enkele klanten die nog met het oudere CMS werkten.

Het uiteindelijke doel van Flexcite is het bieden van een betaalbaar, online programma waarin een leek op het gebied van web development zelf zijn website kan aanpassen, aanvullen, uitbreiden en zelfs kan vormgeven. Met vormgeven bedoelen we dan het bewerken van de Cascading Style Sheet (CSS) en het indelen van modulen. Ook door middel van het uploaden en in gebruik nemen van afbeeldingen is het mogelijk om een website vorm te geven.

(12)

3.4 De uitgangssituatie beschrijven

Voor de eerste versie van Flexcite was een opzet gedaan. Deze opzet was gemaakt met PHP en MySQL. Dit zijn talen waarmee de opdrachtgever bekend is. De oorspronkelijke opdracht was om het bestaande deel uit te breiden met enkele delen. Hierdoor was het een logische keuze om verder te werken met PHP en MySQL.

Op het moment dat het eerste gesprek plaats vond met de opdrachtgever, zou de

stagiair op zeer korte termijn kennis maken met PHP en MySQL. Dit zou gebeuren in een project binnen de opleiding van de stagiair. Eerder had de stagiair nog helemaal niet met deze talen gewerkt. Doordat het project, voorafgaand aan de afstudeerperiode, niet helemaal was gelopen zoals gepland, had de stagiair na afloop van dat project nog steeds niet veel kennis van PHP en MySQL. Wel was er een klein deel van de basis duidelijk geworden, zoals het verschil in werking tussen PHP en JavaScript (server- en clientsided). Ook had de stagiair vanuit de opleiding kennis opgedaan van databases en SQL en zijn interesse hiernaar bleek er wel op aan te sluiten.

Tijdens de ontwikkeling van die eerste versie was er geen documentatie bijgehouden voor externe ontwikkelaars. Om deze reden is er besloten om, voorafgaand aan de afstudeerperiode, een aantal weken in te lassen om voor de eerste versie van Flexcite de systeemdocumentatie aan te leggen. Ook het feit dat de stagiair een gebrekkige kennis had van PHP en MySQL, droeg hieraan bij.

3.5 Te gebruiken methoden en technieken uitzoeken

In eerste instantie is er gekozen om de indeling van de werkzaamheden, volgens de IAD methodiek, aan te houden. De reden achter deze keuze was de beperkte tijd voor het uitwerken van de opdrachtomschrijving. Op deze manier kon er een voorlopige planning opgesteld worden. In de eerste week van de afstudeerperiode volgde een kort onderzoek naar DSDM.

De student had zijn kennis van IAD vergaart via zijn opleiding. Daarnaast was er op www.dsdm.org veel informatie te vinden over DSDM. De twee methodes werden vervolgens tegen elkaar afgewogen.

Vanuit het bedrijf zelf werd geen specifieke werkwijze gehanteerd. Hierdoor werd de stagiair vrijgelaten om zijn eigen werkmethode te hanteren.

3.5.1 IAD of DSDM

In de eerste week van het project is er een kort lopend onderzoek gestart naar DSDM.

Hierin werd DSDM afgewogen tegen IAD om zo tot een keuze te komen welke ontwikkelmethode gehanteerd zou worden.

Een groot probleem met beide bovengenoemde ontwikkelmethodes is een grote afhankelijkheid van gebruikersinput. Dit was een probleem, omdat er niet echt

gebruikers beschikbaar waren voor de productie van het programma. Wel waren er al enkele klanten van Flexcite die mogelijk mee hadden kunnen werken. Op momenten dat hun inzet nodig was bleken de omstandigheden er niet gunstig voor te zijn door

verbouwingen in het pand waar gewerkt werd, of het drukke seizoen in december. Het bleek, mede daardoor, niet mogelijk om een team van gebruikers samen te stellen.

Het belangrijkste verschil tussen IAD en DSDM is dat IAD meer nadruk legt op diepgaand vooronderzoek, verslaglegging en beschrijvingen. DSDM richt zich meer op modelleren en een snelle start. Toch zijn er grote overeenkomsten tussen IAD en DSDM zoals prioritering. Bij IAD gaat dit volgens de indeling van de systeemeisen in Basis, Comfort en Luxe en bij DSDM gaat dit volgens het MoSCoW principe.

(13)

MoSCoW staat voor:

• Most haves (IAD’s basis eisen)

• Should haves (IAD’s comfort eisen)

• Could haves (IAD’s luxe eisen)

• Won’t haves (dit laat IAD achterwege. DSDM bedoeld hiermee dat wat gemaakt kan worden, maar niet opgenomen wordt in het project. De reden hiervoor kan tijd- en/of geldgebrek zijn).

Uiteindelijk zijn de principes afgewogen tegen elkaar. Ook zijn de vraagpunten bij IAD uit hoofdstuk 1.4.3, van het boek van auteur R.J.H Tolido, meegenomen om te bepalen of de methode wel geschikt was. Tolido stelt onder andere dat IAD goed toepasbaar is in een situatie waarin er een aantal soortgelijke applicaties ontwikkeld worden. Daarbij zou met name hergebruik tot een stijging van productiviteit kunnen leiden. Dit ging zeker op in ons project, omdat formulieren per onderdeel op een soortgelijke manier opgebouwd konden worden. Door een goede opbouw te nemen zou een script op vele plaatsen bruikbaar kunnen worden.

Een ander belangrijk punt dat mee speelde, was het feit dat er al een eerdere versie van het CMS gebouwd was. Deze zou volgens de oorspronkelijke opdrachtomschrijving uitgebreid worden. Hiervoor moest veel vooronderzoek verricht worden, mede omdat dit inzicht zou geven in de programmeertaal PHP. Hierdoor was een snelle start ook niet echt mogelijk. Ook zou eerst de systeemdocumentatie van de eerdere versie opgezet moeten worden. Om deze redenen is er besloten om uiteindelijk ook met de IAD methode te werken.

Met het idee van het maken van een nieuw deel van het programma, wat daarna gelijk ingevoerd kon worden bij de klant, was er gekozen voor de iteratiestrategie (of

ontwikkelcyclus) ‘incrementeel opleveren’ binnen IAD.

IAD staat voor ‘Iterative Application Development’ wat, zeer kort gezegd, in houdt dat er verschillende fasen meerdere keren worden doorlopen. IAD onderscheidt drie hoofdfasen die hierna kort beschreven zullen worden:

• Definitiestudie: in de definitiestudie worden de eisen vastgesteld die aan het product en/of dienst gesteld worden. Hierin worden deze eisen gecategoriseerd en geprioriteerd zodat, aan de hand hiervan, verder kan worden gewerkt. Hierop volgt een systeemconcept.

• Pilotontwikkeling: uit het systeemconcept en de prioritering van de eisen volgen een aantal verschillende pilots. Deze zullen tevens kunnen worden opgesplitst in pilot delen. De ontwikkeling volgens het in deze fase uitgewerkte

pilotontwikkelplan zal leiden tot een uitgewerkte pilot.

• Invoering: als het gedeelte, of het gehele, product is ontwikkeld, zal dit worden ingevoerd.

Een iteratiestrategie geeft aan in welke van deze drie fasen worden geïtereerd.

Incrementeel opleveren houdt in dat de definitiestudie een keer wordt doorlopen.

Vervolgens worden de fasen pilotontwikkeling en invoering geïtereerd. Dit betekend dat telkens als er een deel is ontwikkeld, deze direct kan worden ingevoerd.

Figuur 3.3: IAD – Incrementeel opleveren

Tijdens het verloop van het project bleek dat IAD erg veel documentatie vereiste en er zo veel tijd ging zitten in het bijhouden van documentatie, dat er uiteindelijk voor een tussenweg is gekozen tussen documenteren, aantekeningen en modellen. Bij het

beschrijven van de werkmethode tijdens het programmeren zal er hier op teruggekomen worden.

Definitiestudie Pilotontwikkeling Invoering

(14)

3.5.2 De technieken

In de opdrachtomschrijving zijn een aantal technieken gekozen die toegepast zouden worden binnen het project. Dit waren de volgende:

• Prototyping: Bestaande delen van de applicatie konden gezien worden als

evolutionaire prototypes (incomplete versies van wat het moet worden). Alle nog te bouwen modulen waren dan operationele prototypes. Ook konden prototype ontwerpen van nog niet uitgewerkte delen een hulpmiddel zijn bij het testen van de delen die wel uitgewerkt waren. Dit kon het totale beeld voor de gebruiker verhelderen, zie ook ontwerp GUI’s.

• Workshops: Ten tijde dat de systeemeisen vastgesteld moesten worden zijn er enige voorbereidingen getroffen om een workshop te organiseren. Het bleek achteraf onmogelijk om dit uit te voeren, omdat er door een verbouwing in het pand van ‘Coro Reizen en IT services BV’ geen plaats was om gebruikers bij elkaar te brengen. Het idee van workshops is hierna vervallen. In dit geval van de

systeemeisen is er uiteindelijk een enquête opgesteld, welke is opgenomen in de externe bijlagen. Deze enquête was online door verschillende gebruikers te

beantwoorden. De resultaten hiervan vielen ernstig tegen. Een betere manier was misschien geweest om klanten, indien mogelijk, persoonlijk te interviewen.

• Ontwerp van GUI’s: Deze zouden gebruikt worden bij het testen en evalueren van nog niet bestaande delen van Flexcite. Door middel van het opzetten van deze ontwerpen kon gekeken worden of de ideeën van de opdrachtgever en de stagiair overeen kwamen. Ook stond het gebruik hiervan gepland bij het testen met gebruikers. Door het feit dat de opdracht uiteindelijk het restylen zou zijn van het systeem bleek er echter meer werk in de ontwikkeling te zitten. Om succesvol te kunnen testen zijn de testen zelf verplaatst naar een later tijdstip na de

afstudeerperiode.

• Hergebruik: het hergebruiken van eerder ontworpen delen. Bij het uitwerken van de nieuwe delen is gekeken naar de al bestaande delen, om deze zoveel mogelijk overeen te laten komen met de bestaande werkwijze van het systeem. Ook bij het restylen heeft hergebruik een rol gespeeld.

• Time-boxing: het inperken van de verschillende delen in een planning. Een techniek die een tijdsindeling erg overzichtelijk maakt. Het bleek uitermate lastig om de globale planning om te zetten in specifiekere timeboxen, omdat het vrij lang duurde voordat het project werkelijk vorm aan begon te nemen. Doordat er veel vooronderzoek nodig was en dit onderzoek voortgezet werd bij het

programmeren, werd het steeds moeilijker om gericht naar de doelstelling toe te werken. Later werd ook de koers gewijzigd, waarmee een eind kwam aan het worstelen om de pilots te verdelen over de planning. Op deze nieuwe koers waren ze beter te verdelen.

• UML (Unified Modelling Language) zal worden toegepast bij het weergeven van verscheidene schema’s. Er was gekozen voor UML, omdat dit een breed

geaccepteerde verzameling is van modellen. Onder andere is er een poging gedaan om use-cases te modelleren. Echter door gebrek aan kennis van deze modellen zijn ze niet helemaal compleet afgeleverd. Wel hebben ze bijgedragen aan het tot stand komen van het uiteindelijke beeld van het systeem.

3.6 Op te leveren producten en diensten uitwerken

Uit de gekozen werkmethode en de doelstellingen waren een aantal op te leveren producten opgesteld. Voor IAD waren dit voornamelijk de rapporten Definitiestudie, de pilotontwikkelplannen per deel van het systeem, een testplan en het testverslag. Naar aanleiding van de doelstelling kwam hier het rapport voor de marktvraagstukken bij. In dat rapport zou het onderzoek met resultaten beschreven worden met als onderwerp de vraag die er naar dit product is, op de markt die ‘Coro Reizen & IT services BV’ wil bereiken. In het oorspronkelijke plan van aanpak is hiervoor de volgende lijst opgenomen:

(15)

• Algemeen plan van aanpak voor het overzicht van de te volgen werkwijze (dit verslag)

• Een draaiende proefversie van Flexcite bij enkele bestaande klanten,

• Rapport analyse van het bestaande gedeelte van Flexcite (gedeeltelijk opgenomen in de Definitiestudie en verder verwerkt in systeemdocumentatie),

• Rapport doelgroepanalyse,

• Definitiestudie Flexcite,

• Systeemdocumentatie van bestaande en nieuwe delen van Flexcite,

• Pilotontwikkelplan 1; Edit menu,

• Werkende Module: Edit menu,

• Pilotontwikkelplan 2; Module editor,

• Werkende Module: Module editor,

• Pilotontwikkelplan 3; Page structure,

• Werkende Module: Page structure,

• Pilotontwikkelplan 4; Style editor,

• Werkende Module: Style editor,

• Rapport testplan,

• Rapport testverslag (hierin opgenomen verbeterpunten voor eventuele nieuwe versies),

• Rapport marktvraagstukken (mogelijk marketingplan),

• Handleiding van de vier modules,

• Helpfunctie van de vier modules.

Met name is het belangrijk om te letten op de indeling in vier pilots. Voornamelijk dit deel werd later aangepast naar drie totaal anders opgestelde pilots, door de wijzigingen in de structuur van het programma.

3.7 Werkzaamheden (fasering en activiteiten) onderscheiden

Om tot de hierboven genoemde producten te komen werden een aantal werkzaamheden onderscheiden en als volgt in een lijst opgenomen in het plan van aanpak:

• Schrijven van het algemene plan van aanpak voor de gehele periode,

• Omzetten oude CMS naar Flexcite bij enkele huidige klanten,

• Bestuderen leermateriaal; PHP, XHTML, MySQL, JavaScript en CSS,

• Analyseren van het bestaande gedeelte van het CMS Flexcite,

• Analyseren van de doelgroep en dit rapporteren.

Definitiestudie Flexcite;

• beschrijven huidige situatie,

• bepalen systeemeisen,

• opstellen van het systeemconcept met speciale aandacht voor de modules ‘Edit menu’, ‘Module Editor’, ‘Page structure’ en ‘Style editor’,

• vastleggen van de technische structuur,

• bepalen van de organisatorische inrichting,

• opstellen van een pilotplan.

• Systeemdocumentatie opzetten voor bestaande en nieuwe delen van het CMS, Pilotontwikkeling pilot 1; Edit menu:

• vaststellen van de globale functionele structuur voor pilot 1,

• vaststellen van de organisatorische structuur voor pilot 1,

• opstellen van een pilotontwikkelplan voor pilot 1,

• uitwerken pilot 1.

Pilotontwikkeling pilot 2; Module editor:

(16)

Pilotontwikkeling pilot 3; Page structure:

Pilotontwikkeling pilot 4; Style editor:

Testen van Flexcite als geheel met speciale aandacht voor de vier nieuwe modules:

• opstellen testplan,

• benaderen (potentiële) gebruikers,

• uitvoeren tests,

• schrijven testverslag.

• Beantwoorden van marktvraagstukken en dit rapporteren,

• Schrijven en uitwerken van de helphoofdstukken over de pilots, zowel digitaal (helpfunctie) als analoog (handleiding).

Het zal direct opvallen dat de pilots niet specifiek uitgewerkt zijn. De reden hiervoor is dat in dat stadium nog niet bekend was hoe dit het beste aangepakt kon worden. In elk pilotontwikkelplan zou hiervoor een specifiekere planning opgenomen worden.

Bij het begin aan de pilots bleek dit vrijwel onmogelijk, omdat de ideeën voor het optimaliseren niet technisch ondersteund waren. Hiervan was de oorzaak, dat de mogelijkheden van PHP, MySQL en JavaScript, niet helemaal helder waren en er steeds betere oplossingen uit onderzoek naar boven kwamen. Veel van de plannen voor optimalisatie moesten worden onderzocht zodat kon worden vastgesteld of ze te realiseren waren.

3.8 Risicofactoren bepalen en opvangen

Aan ieder project zijn een aantal risico’s verbonden. Deze kunnen de voortgang van het project in de weg komen te staan of zelfs tot beëindiging leiden. Om deze risico’s in te perken is het belangrijk hier vooraf over na te denken. Het volgende is geschreven alsof we aan het begin van het project staan. De volgende risicofactoren werden in acht genomen:

• Een gedeelte van Flexcite is al gebouwd en er zijn al klanten die deze versie gebruiken, hierdoor zal grotendeels gebouwd moeten worden op dit bestaande deel. Het kan echter wenselijk zijn, of zelfs noodzakelijk, om een deel van het bestaande programma aan te passen. Dit veroorzaakt meer werk dan van tevoren is vastgesteld bij de opdrachtomschrijving. Om dit risico in te perken zal er in de definitiestudie een uitvoerige beschrijving van de huidige situatie worden

opgenomen en zal al het bestaande werk worden gescand op overbodige scripts.

• Het is tevens een mogelijkheid om na deze eerste versie over te gaan op versie 1.1, of direct naar versie 2.0, waarbij het voor bestaande klanten nodig zal zijn om een bedrag te betalen voor de upgrade naar deze nieuwe versie. Een betaling maakt het interessant om meer werk te steken in het overzetten van klanten naar de nieuwe versie van Flexcite.

• In geval van langdurige ziekte of afwezigheid van een van de collega’s is het mogelijk om op afstand te werken aan het project. Via e-mail en (mobiele)

telefoon is het mogelijk om te communiceren. Hiervoor zijn de e-mail adressen en telefoonnummers al uitgedeeld. De stagiair zal eveneens ten allen tijde zijn werk

(17)

mee naar huis nemen, omdat dit op een laptop tot zijn beschikking staat. Een kopie van dit werk wordt op locatie in Baarn bewaard, zodat dit ook toegankelijk is voor de opdrachtgevers. Bij langdurige afwezigheid van locatie in Baarn kan er tevens een backup ruimte op de FTP server in gebruik worden genomen.

• Het zou het geval kunnen zijn dat de kennis van de stagiair niet voldoende is voor het uitwerken van de opdracht. Om dit op te vangen heeft de stagiair een aantal boeken in huis gehaald. Ook op internet zijn genoeg oplossingen te vinden voor vraagstukken met betrekking op programmeren in PHP en MySQL. Indien de opdrachtgevers aanwezig zijn op locatie in Baarn zijn deze tevens bereid hun kennis over te brengen op de stagiair. De stagiair heeft een

geheimhoudingscontract getekend ter voorkoming dat hij interne informatie zou lekken.

• In geval dat het niet lukt om de planning, zoals hieronder beschreven, aan te houden zal hier snel een overleg over gepleegd moeten worden. In dit geval is het mogelijk om de opdrachtomschrijving in te perken indien blijkt dat deze te ruim is genomen. Dat het zover zal komen zal echter beperkt worden door het uitsplitsen van de eisen in de definitiestudie.

3.9 Plannen

Vervolgens werd er een planning opgezet voor de hele periode. Deze verschilde in de eerste versie van de definitiestudie niet veel van de planning zoals die was opgenomen in de opdrachtomschrijving. Enkele extra wensen van de opdrachtgever waren nu nog doorgevoerd en sloten beter aan op hoe de werkelijkheid zou zijn voor zover op dat moment bekend was.

In de planning staan de weken benoemd zoals ze op de kalender staan. De donkere kleur is de tijd die gereserveerd is voor de activiteit die vooraan benoemd is. De lichte kleur is de mogelijke uitlooptijd. De officiële afstudeerperiode liep van week 36 t/m week 03 - 14 januari moest het verslag ingeleverd worden.

Het idee was om voor iedere pilot twee weken te gebruiken voor het uitwerken van de nodige onderzoeken en documentatie. Om vervolgens te beginnen met programmeren en de documentatie voor de volgende pilot.

Nu het plan van aanpak op tafel lag kon de stagiair zich gaan verdiepen in Flexcite.

Werkzaamheden / week w32 w33 w34 w35 w36 w37 w38 w39 w40 w41 w42 w43 w44 w45 Plan van aanpak

Omzetten oud -> nieuw Bestuderen leermateriaal Analyseren Flexcite Definitiestudie Flexcite Analyseren Doelgroep Opzetten systeemdoc.

Pilotontwikkeling pilot 1 Pilotontwikkeling pilot 2 Pilotontwikkeling pilot 3 Pilotontwikkeling pilot 4

Werkzaamheden / week w46 w47 w48 w49 w50 w51 w52 w53 w01 w02 w03 w04 w05 w06 Omzetten oud -> nieuw

Opzetten systeemdoc.

Pilotontwikkeling pilot 4 Testen Flexcite

Beantwoorden van markt vraagstukken

Uitwerken help stukken

(18)

4. Het analyseren van de bestaande delen van Flexcite

Om een indruk te krijgen van het eerste programma werd er door de opdrachtgever een aanvullende uitleg gegeven over de werking van het programma en hoe het technisch in elkaar zat. Door middel van het doorlopen van de database en de structuur van de bestanden, terwijl hiernaast het functionele deel van het programma gedraaid werd om de uitwerking ervan te kunnen ondervinden, heeft de stagiair een globale indruk

gekregen.

Met deze globale kennis is het systeem de eerste weken in kaart gebracht. Door te werken met de bestaande delen, ‘Edit Content’ en ‘Upload Images’, deze door te lopen, te testen en de resultaten te documenteren, is er een uitgebreide beschrijving gemaakt van hoe het systeem werkte. De stappen die gezet werden om een opdracht, als het

invoeren van content, uit te voeren, werden in een taakdiagram ondergebracht.

In deze eerste weken is er een promotiesite gemaakt voor het product zelf. De vormgeving en de content voor deze site werden door de heer Smits aangeleverd en de heer de Rooij leidde de stagiair door het opbouwen van de website. De stappen die hiervoor werden ondernomen, als het aanmaken van een webomgeving en een CMS- omgeving met wachtwoord, werden eveneens in een taakdiagram verwerkt.

Het meeste werk voor het opbouwen van een website bleek te zitten in het bewerken van gegevens en bestanden via FTP-programma’s, bestanden met log-gegevens, en

rechtstreeks in de database via phpMyAdmin. Om deze reden was de database ook zodanig opgezet dat de data daarin gemakkelijk leesbaar zou zijn. Ook bleek alle informatie in de database, wat met hetzelfde onderdeel van een website te maken had, als attributen in een enkele tabel, te zijn ondergebracht. Als voorbeeld is te nemen de indeling van modules op een pagina. In figuur 4.1 is een illustratie gegeven van de attributen die in de tabel ‘pages’ waren opgenomen om een webpagina te vullen.

pgH1 pgH2 pgH3

pgC1D1 pgC2D1 pgC3D1 pgC4D1

pgF1 pgF2

Figuur 4.1: de opbouw van een website en tabel indeling

Tabel: ‘pages’ pgC2D1mod pgH3css

pgid pgC2D2mod pgC1D1css

TS pgC2D3mod pgC1D2css

pgLang pgC3D1mod pgC1D3css

pgDesc pgC3D2mod pgC2D1css

pgKeyw pgC3D3mod pgC2D2css

pgTableWidth pgC4D1mod pgC2D3css

pgT1width pgC4D2mod pgC3D1css

pgT2width pgC4D3mod pgC3D2css

pgT3width pgF1mod pgC3D3css pgT4width pgF2mod pgC4D1css pgH1mod pgT1css pgC4D2css pgH2mod pgT2css pgC4D3css pgH3mod pgT3css pgF1css

pgC1D1mod pgT4css pgF2css

pgC1D2mod pgH1css pgC1D3mod pgH2css

(19)

Links zien we nogmaals de pagina indeling met de benaming van de delen zoals die in de database is gebruikt. Per deel wordt een module ingevuld en een CSS naam opgegeven.

De CSS naam is dan de ‘class’ die in de Style Sheet staat en deze bepaald de vormgeving, de stijl, van dat deel van de pagina.

Een ander voorbeeld is dat van de tabel modules. Een module, afhankelijk van zijn functie, heeft verschillende instellingen, maar het doel van de instellingen is

verschillende. De oorspronkelijke tabel was zo opgezet dat er per module 30

verschillende instellingen meegegeven konden worden. Dit aantal was ontstaan naarmate er in verloop van tijd meerdere modules bijkwamen, waar deze nieuwe instellingen bij nodig waren. De tabel zag er uit zoals weergegeven in figuur 4.2.

Al vrij snel is er een overzicht in elkaar gezet in welke situatie welke modSets werden gebruikt en met welk doel. Deze overzichten zijn opgenomen in de externe bijlagen bij de definitiestudie.

Het ontwerp was in de eerste versie op deze manier uitgewerkt, met zoveel mogelijk attributen bij elkaar in een tabel, omdat het

‘openen’ van meerdere MyISAM tabellen (MyISAM is het type) in MySQL vertragen werkt op het systeem. Hiervoor is een onderzoek ingesteld naar MySQL en het resultaat hiervan was dat deze

vertraging kon worden opgevangen door indexen, d.m.v. ‘join’

selecties en door een grotere cache op de tabellen. Hierdoor werd de eerdere reden verworpen.

Al met al ontstond steeds meer het idee dat de database op een veel betere manier aan te pakken was door middel van het gebruik van vreemde sleutels die verschillende tabellen met elkaar linken.

De stagiair wist op dat moment nog niet dat vreemde sleutels niet zonder meer

geaccepteerd werden binnen MySQL. Er werd besloten om de discussie betreffende het omgooien van de database uit te stellen tot nader onderzoek was verricht. En verder onderzoek naar het systeem werd uitgevoerd. De beschrijving van de huidige situatie leidde uiteindelijk tot een vervroegde start met de definitiestudie.

De opdrachtgever had het idee om verschillende pakketten aan te willen bieden: small, medium en advanced. De wens van de opdrachtgever was om voor deze drie

verschillende mogelijkheden een sjabloon op te zetten in de database, van waaruit websites voor klanten sneller geproduceerd konden worden. Hiervoor werden standaard pagina’s opgezet in de database. De kennis van de stagiair was inmiddels aardig

gevorderd om te werken met de applicatie en de database. Hij wist welke handelingen er verricht moesten worden, ook buiten het systeem om, om een website op te zetten.

Zelfstandig heeft hij vervolgens een sjabloon opgesteld en heeft zijn bevindingen ook gelijk meegenomen in de beschrijving van de huidige situatie.

Een andere wens van de opdrachtgever die hier snel op volgde was om nog een paar klanten van het oude CMS om te zetten naar de eerste versie van Flexcite. Het was echter voor het project niet nodig om deze klanten over te zetten. De stagiair beschikte inmiddels over genoeg informatie om de uitbreidingen op het systeem uit te kunnen werken. Ook koste het nog steeds relatief veel werk om een website op te zetten. Dit legde de stagiair vervolgens voor bij de opdrachtgever. Uiteindelijk is er besloten om één klant over te zetten. Deze klant was al langere tijd aan te wachten om met Flexcite te kunnen gaan werken. Bij het opzetten van deze website kwamen de beschrijvingen van de huidige situatie, die tot zover waren gemaakt, gelijk van pas.

Tabel:

‘modules’

modID TS modLang modName modPHP modSet1 modSet2 modSet3 modSet4 modSet29 modSet30

Figuur 4.2: tabel modules

(20)

5. Het beschrijven van de huidige situatie

In het vorige hoofdstuk is al genoemd dat tijdens de analyse van de eerste versie van Flexcite een start is gemaakt aan de beschrijving van de huidige situatie. Deze

beschrijving is erg uitgebreid opgenomen in de eerste versie van de definitiestudie en omvat scenario’s en een heleboel taakdiagrammen. Later is deze uitgebreide beschrijving verplaatst naar de externe bijlagen van de definitiestudie. De externe bijlagen van de definitiestudie lijken daardoor ook meer op systeemdocumentatie van de eerste versie van de applicatie.

Na het beschrijven van de werkwijze is de structuur van de bestanden en de werking van deze bestanden in kaart gebracht. Hierbij viel het oog ook op de merkwaardige manier van het opbouwen van de pagina’s van het CMS zelf; delen die op elke pagina hetzelfde waren, zoals het hoofdmenu, werd geladen in een iframe in elke pagina. Deze moest bij iedere pagina opnieuw geladen worden. Samen met andere opmerkingen, die niet meteen in de beschrijving van de huidige situatie opgenomen konden worden, werd ook deze opmerking genoteerd. Later zouden deze bij het ontwerp van de gewenste situatie nog eens ingekeken worden. Ook versterkte dit soort opmerkingen de wens van de stagiair om een verse start te maken.

Bij het uitwerken van de huidige situatie kwam de opdrachtgever zelf ook telkens met nieuwe goeie ideeën. Verschillende uitbreidingen op de applicatie kwamen zo naar boven en werden genoteerd voor mogelijk gebruik bij de systeemeisen. De

opdrachtgever wilde graag delen uitgewerkt zien.

De indruk die hij achterliet was er duidelijk een van

“liever vandaag dan morgen”. Dit is natuurlijk ook heel begrijpelijk, maar deze manier van werken paste niet bij de werkwijze die de stagiair wilde handhaven. Indien de stagiair had gekozen voor DSDM was dit waarschijnlijker bevredigender geweest voor de opdrachtgever. Oriëntatie was echter heel belangrijk voor de stagiair. Om de veelvuldige stroom van wensen te beperken en de hoofdlijn van het project te bewaken heeft de stagiair vervolgens een systeemencyclopedie opgezet. Hierin stond afgebakend aan welk document er gewerkt werd en wat de resultaten hiervan zouden zijn en wat hierop zou volgen. Dit document, samen met de planning in het plan van

aanpak vormden een goede basis voor een doelgericht project. Ook kon de stagiair op deze manier de voortgang van het project zichtbaar maken naar de opdrachtgever.

Nu de beschrijving van de huidige situatie vrijwel geheel in kaart was, en hiermee een deel van de definitiestudie klaar was, was het een logische stap de definitiestudie verder uit te werken.

(21)

6. De definitiestudie uitwerken

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.

(22)

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.

(23)

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

(24)

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

(25)

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.

(26)

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.