• No results found

Java open source portaal

N/A
N/A
Protected

Academic year: 2021

Share "Java open source portaal"

Copied!
73
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

Procesverslag

Afstuderen

Auteur: Jaap van Hoek

Opleiding: AIB, Avans Hogeschool

Organisatie: Indicia Nederland B.V.

(2)

Pagina 2 van 40

Procesverslag

Afstuderen

Auteur: Jaap van Hoek

Studentnummer: 2003919

Email: j.vanhoek1@student.avans.nl Organisatie: Indicia Nederland B.V. Bedrijfsbegeleider: Niels Wijsbeek Docentbegeleider: Harrie de Swart Rapport versie: 1.0

Studiejaar: 2009 – 2010

Periode: Werkend Leren 2

Datum: 11-01-2010

Academie: Academie voor ICT en Business Opleiding: Informatica

(3)

Pagina 3 van 40

Documentbeheer

Versiehistorie:

Versie Datum Auteur(s) Omschrijving

1.0 11-01-2010 Jaap van Hoek 1e versie van het procesverslag

Student:

Naam Functie

Jaap van Hoek Stagiaire

Distributielijst:

Onderstaande personen ontvangen dit document:

Naam Functie

Niels van Wijsbeek Bedrijfsbegeleider Harrie de Swart Docentbegeleider

(4)

Pagina 4 van 40

Voorwoord

Dit rapport is geschreven naar aanleiding van de afstudeeropdracht die ik, Jaap van Hoek, heb uitgevoerd bij Indicia Nederland B.V. te Tilburg. Dit rapport vormt de procesbeschrijving van het project dat is voortgekomen uit de afstudeeropdracht, dit afstuderen is onderdeel van de Academie voor ICT en Business aan de Avans Hogeschool te Breda.

Met dit schrijven wil ik iedereen bedanken die heeft bijgedragen aan de voortgang van het project. In het bijzonder wil ik Dhr. N. Wijsbeek bedanken die in de rol van bedrijfsbegeleider mij ondersteund heeft tijdens het project; tevens wil ik Dhr. H. de Swart bedanken voor zijn rol als docentbegeleider en de feedback op documentatie en vragen.

Tilburg, 11 januari 2010, Jaap van Hoek

(5)

Pagina 5 van 40

Samenvatting

Dit rapport geeft een beschrijving van het uitgevoerde project bij Indicia Nederland B.V. te Tilburg. Indicia biedt met haar grote ontwikkelafdeling vele mogelijkheden op het gebied van E-commerce, Portals, EDI en content management. Door de beschikbare kennis van diverse programmeertalen kan Indicia op vele verschillende manieren een passende oplossing bieden aan haar klanten. Op het gebied van portals en online samenwerking is het pakket Microsoft SharePoint een veel geleverde oplossing. Er zijn echter veel organisaties en instellingen die niet met Microsoft producten willen werken of de kosten van dit pakket te hoog vinden. Vanuit dit perspectief is de opdracht ontstaan om op basis van een Java gebaseerd open source pakket een portaaloplossing te creëren die een alternatief biedt voor SharePoint. Deze portaaloplossing zal volledig Microsoft onafhankelijk zijn en een vele malen lagere kostenpost met zich meebrengen.

Om te komen tot een geschikt open source pakket dat moet dienen als basis van het eindproduct, is er een pakketselectie uitgevoerd. Allereerst zijn de eisen waaraan het pakket moet voldoen

opgesteld, dit is gedaan aan de hand van de functionaliteiten van SharePoint. Nadat de eisen duidelijk waren opgesteld is het selectietraject van start gegaan. Hierbij is begonnen met het opstellen van een longlist, uiteindelijk is er één pakket over gebleven. Dit pakket is Liferay, een open source portaal met een grote gebruikersgroep en vele jaren ervaring.

Liferay is aan de hand van een vooraf opgestelde businesscase in een testomgeving

geïmplementeerd. Deze businesscase representeert een praktijk situatie en is dus een goede testomgeving voor het pakket. Het portaal is grondig geanalyseerd en de verschillen met de businesscase zijn gedocumenteerd. Aan de hand van deze verschillen is er gekeken wat er nog zelf ontwikkeld moest worden in de vorm van portlets; portlets zijn de onderdelen waaruit een portaal is opgebouwd. In overleg is er besloten om een FAQ portlet te ontwikkelen om extra functionaliteiten aan het standaard portaal toe te voegen en de uitbreidbaarheid van het systeem aan te tonen. De FAQ portlet is ontwikkeld aan de hand van de ontwikkelmethode RUP. Hiervoor is gekozen omdat de functionaliteiten van deze portlet niet vast stonden omdat nog onbekend was wat de

mogelijkheden van een portlet waren. Zo is er per iteratie gekeken wat er mogelijk was en is het eindresultaat bereikt. De portlet is ontwikkeld in de ontwikkelomgeving van Netbeans en maakt gebruik van het Hibernate framework voor database interactie.

Het eindresultaat van het project is een werkend geheel dat door de sales afdeling gedemonstreerd kan worden met behulp van de demonstratieversie. Het product heeft vele mogelijkheden voor uitbreiding waardoor het interessant is voor vele verschillende gebieden. Dit is ook het doel dat de opdrachtgever voor ogen stond bij het opstellen van de opdracht.

(6)

Pagina 6 van 40

Inhoudsopgave

1. Inleiding ... 8 2. De organisatie ... 9 2.1. Beschrijving organisatie ... 9 2.2. Cultuur ... 11

2.3. Plaats binnen de organisatie ... 12

2.4. Invloed van de organisatie ... 12

3. Probleemanalyse ... 13

3.1. Situatie ... 13

3.2. De probleemstelling ... 13

3.3. Doelstellingen ... 14

3.4. Eindproduct ... 14

4. Plan van aanpak ... 15

4.1. Producten ... 15 4.2. Kwaliteit ... 15 4.3. Planning ... 16 5. Methoden en technieken ... 17 5.1. Methoden ... 17 5.2. Technieken ... 18 5.3. Tools ... 19 6. Uitvoering ... 21 6.1. Voorbereiding ... 21 6.2. Vooronderzoek ... 21 6.3. Pakket selectie ... 22

6.4. Businesscase implementatie & analyse ... 22

6.5. Portlet ontwerp ... 23

6.6. Portlet realisatie ... 23

6.6.1 Eerste iteratie ... 24

6.6.2 Tweede iteratie... 25

6.7. Testen FAQ portlet ... 25

6.7.1. Whiteboxtests ... 25

6.7.2. Blackboxtests ... 26

6.8. Implementatie en oplevering ... 26

7. Resultaten ... 27

(7)

Pagina 7 van 40 7.2. FAQ portlet ... 27 7.3. Handleiding ... 28 7.4. Eindproduct ... 28 8. Conclusie en aanbevelingen ... 31 8.1. Eindproduct ... 31

8.1.1. Conclusie ten opzichte van het eindproduct ... 31

8.1.2. Aanbevelingen ten opzichte van het eindproduct ... 31

8.2. Conclusies Open source... 32

8.2.1. Voordelen ... 32 8.2.2. Nadelen ... 33 8.2.3. Problemen ... 33 8.3. Project evaluatie ... 34 8.3.1. Vooronderzoek ... 34 8.3.2. Ontwikkeling ... 35 9. Zelfreflectie ... 36 9.1. Samenwerken ... 36 9.2. Communiceren ... 36 9.3. Projectmatig werken ... 36 9.4. Analyseren en oordeelsvorming ... 37 9.5. Leren en ontwikkelen ... 37

9.6. Omgevingsbewust denken en handelen ... 37

10. Bronvermelding ... 38

10.1. Literatuurlijst ... 38

10.2. Internet bronnen ... 38

(8)

Pagina 8 van 40

1.

Inleiding

Binnen de hedendaagse bedrijfsvoering is samenwerken en informatie delen heel erg belangrijk. Er is een grote hoeveelheid aan informatie, maar deze is niet gemakkelijk te benaderen en/of er moet veel gezocht worden naar de juiste stukken. De oplossing voor dit probleem is een, via een

internetbrowser te bereiken, portaal waarop medewerkers moeten inloggen om toegang te krijgen tot de bestanden en mededelingen die zij mogen bekijken en openen. Deze portalen zijn er in vele verschillende soorten en maten; een grote speler op deze markt is Microsoft SharePoint.

Op het gebied van portalen biedt Indicia Nederland B.V. onder andere de SharePoint

portaaloplossing aan haar klanten. Er zijn echter veel organisaties en instellingen die niet met

Microsoft producten willen werken of de kosten van dit pakket te hoog vinden. Hieruit is de opdracht ontstaan om met behulp van een Java gebaseerd open source pakket hiervoor een alternatief te bieden. De nieuwe portaaloplossing zal een vele malen lagere kostenpost met zich meebrengen en volledig Microsoft onafhankelijk zijn.

Dit rapport is geschreven om de lezer inzicht te geven in het gevolgde proces om van opdracht tot eindproduct te komen en wat daarbij kwam kijken. Dit rapport kan tevens gebruikt worden om meer over het eindproduct te weten te komen en wat het zo al omvat.

Dit rapport gaat in op zaken die belangrijk zijn met betrekking tot het project; zo zal er in de eerste hoofdstukken inzicht gegeven worden in de organisatie waar het project is uitgevoerd. Vervolgens wordt het probleem dat tijdens het project centraal stond uiteengezet in de probleemanalyse en wordt de achtergrond van het probleem verduidelijkt. Daarna is er een hoofdstuk opgenomen dat ingaat op het gemaakte plan van aanpak voor het project; dit hoofdstuk bevat de belangrijkste zaken van het plan van aanpak zoals planning en producten.

Na de achtergrond en de aanpak van het project wordt er ingegaan op de gebruikte methoden en technieken in het gelijknamige hoofdstuk. Hierin worden de technische aspecten van het project en het eindproduct verduidelijkt. De daarop volgende hoofdstukken zijn een beschrijving van het proces en het eindproduct; dit zijn de hoofdstukken uitvoering en resultaten. Bij de uitvoering wordt ingegaan op de genomen acties en gemaakte keuzes, de resultaten hiervan zijn opgenomen in het hoofdstuk resultaten.

Tot slot van dit rapport zijn er na afloop van het project conclusies getrokken en worden er aanbevelingen gedaan voor de toekomst van het eindproduct. Bij de conclusies is er een aparte paragraaf opgenomen die ingaat op open source; de voor- en nadelen ervan en de tegengekomen problemen. Het laatste hoofdstuk bevat een zelfreflectie op basis van de competenties die tijdens het project nodig waren.

(9)

2.

De organisatie

In dit hoofdstuk wordt van macroniveau naar microniveau de

organisatie beschreven, als toevoeging daarop is beschreven wat mijn plaats binnen de organisatie is.

2.1.

Beschrijving organisatie

De Indicia Groep is een overkoepelende organisatie met een zestal dochterondernemingen. Afbeelding 2.1

van de overkoepelende organisatie.

Afbeelding 2.1: De Indicia groep

De Indicia Groep is een aantal jaren geleden ontstaan door een samenwerking tussen Indicia Nederland en een aantal zusterbedrijven. Sinds toen heeft de Indicia Groep zich uitgebreid tot een grote organisatie met vestigingen in binnen

afbeelding 2.1, een Roemeense vestiging die zich vooral richt op ontwikkeling in .NET.

Wanneer we een stapje dichterbij gaan en inzoomen op Indicia Nederland, dan komen we bij de vestiging uit waarbinnen ik werkzaam ben. Indicia Nederland is actief op verschillende vakgebieden waaronder E-commerce, EDI, Content management en portaalsoftware. Indicia Nederland heeft ruim 12 jaar ervaring in het bieden van oplossingen voor zowel de publieke als de zakelijke secto

De organisatie binnen Indicia Nederland is in afbeelding 2

In deze afbeelding is de opsplitsing in de verschillende afdelingen te zien. Alle afdelingen in de afbeelding zijn te vinden binnen de vestiging

die op locatie werken, zoals bij Philips ongeveer 60 medewerkers.

Pagina

In dit hoofdstuk wordt van macroniveau naar microniveau de

organisatie beschreven, als toevoeging daarop is beschreven wat mijn

Beschrijving organisatie

De Indicia Groep is een overkoepelende organisatie met een zestal

chterondernemingen. Afbeelding 2.1, “De Indicia Groep", is een weergave van het organigram van de overkoepelende organisatie.

De Indicia Groep is een aantal jaren geleden ontstaan door een samenwerking tussen Indicia Nederland en een aantal zusterbedrijven. Sinds toen heeft de Indicia Groep zich uitgebreid tot een grote organisatie met vestigingen in binnen- en buitenland. Zo is Camelweb, uiterst rechts in

1, een Roemeense vestiging die zich vooral richt op ontwikkeling in .NET.

Wanneer we een stapje dichterbij gaan en inzoomen op Indicia Nederland, dan komen we bij de rkzaam ben. Indicia Nederland is actief op verschillende vakgebieden commerce, EDI, Content management en portaalsoftware. Indicia Nederland heeft ruim 12 jaar ervaring in het bieden van oplossingen voor zowel de publieke als de zakelijke secto

De organisatie binnen Indicia Nederland is in afbeelding 2.2, “Organigram Indicia Nederland”, te zien. In deze afbeelding is de opsplitsing in de verschillende afdelingen te zien. Alle afdelingen in de afbeelding zijn te vinden binnen de vestiging in Tilburg met uitzondering van sommige medewerkers

zoals bij Philips, een klant van Indicia. In totaal bestaat Indicia Nederland uit

Pagina 9 van 40

, “De Indicia Groep", is een weergave van het organigram [1]

De Indicia Groep is een aantal jaren geleden ontstaan door een samenwerking tussen Indicia Nederland en een aantal zusterbedrijven. Sinds toen heeft de Indicia Groep zich uitgebreid tot een

buitenland. Zo is Camelweb, uiterst rechts in

Wanneer we een stapje dichterbij gaan en inzoomen op Indicia Nederland, dan komen we bij de rkzaam ben. Indicia Nederland is actief op verschillende vakgebieden commerce, EDI, Content management en portaalsoftware. Indicia Nederland heeft ruim 12 jaar ervaring in het bieden van oplossingen voor zowel de publieke als de zakelijke sector [14].

, “Organigram Indicia Nederland”, te zien. In deze afbeelding is de opsplitsing in de verschillende afdelingen te zien. Alle afdelingen in de

in Tilburg met uitzondering van sommige medewerkers . In totaal bestaat Indicia Nederland uit

(10)

Afbeelding 2.2: Organigram Indicia Nederland

Hieronder volgt een korte beschrijving van de afdelingen die in het organigram te vinden zijn, de afdelingen die relevant zijn voor mijn werkzaamheden of waar ik mee te maken heb gehad zijn nader beschreven.

• Bedrijfsbureau

Onder het bedrijfsbureau vallen de afdelingen Finance & Con

worden de financiële zaken, personeelszaken en interne zaken behandeld. • Capaciteitsplanning

Bij capaciteitsplanning worden de werkzaamheden van de medewerkers van verschillende afdelingen gepland. Dit wordt gedaan opdat iedere

projecten besteed.

Pagina : Organigram Indicia Nederland

beschrijving van de afdelingen die in het organigram te vinden zijn, de afdelingen die relevant zijn voor mijn werkzaamheden of waar ik mee te maken heb gehad zijn nader

Onder het bedrijfsbureau vallen de afdelingen Finance & Control, P&O en office. Hierin worden de financiële zaken, personeelszaken en interne zaken behandeld.

Bij capaciteitsplanning worden de werkzaamheden van de medewerkers van verschillende afdelingen gepland. Dit wordt gedaan opdat iedere medewerker zijn uren aan de juiste

Pagina 10 van 40

beschrijving van de afdelingen die in het organigram te vinden zijn, de afdelingen die relevant zijn voor mijn werkzaamheden of waar ik mee te maken heb gehad zijn nader

trol, P&O en office. Hierin

Bij capaciteitsplanning worden de werkzaamheden van de medewerkers van verschillende medewerker zijn uren aan de juiste

(11)

Pagina 11 van 40

• Sales

Op de sales afdeling worden de verkopen gedaan en wordt het contact met de klanten onderhouden. Klanten kunnen hier terecht voor product informatie of het aanschaffen van producten. De sales afdeling bereikt overeenstemming over eisen en wensen met betrekking tot nieuwe systemen.

• Operations

De operations afdeling is een verzameling van verschillende uitvoerende afdelingen zoals: o Customer Service

Customer Service is het aanspreekpunt van de klant betreffende de aangeschafte producten of lopende projecten. Op deze afdeling zitten ook de servicedesk voor afgeronde projecten en het projectmanagement voor lopende projecten. o Development

Dit is de algemene naam waarmee de ontwikkelafdeling wordt aangeduid. Binnen deze afdeling is er ook weer een indeling op vakgebied gemaakt, waaruit de

verschillende verantwoordelijkheden en projecten naar voren komen. De afdelingen zijn Java / open source, Microsoft (.NET), EDI, ICT en test. Deze afdelingen werken in dezelfde ruimte maar wel afzonderlijk van elkaar.

o Quality ensurance

Deze nieuwe afdeling moet op het moment van schrijven nog een definitieve vorm krijgen, maar deze afdeling zal zich volledig bezig gaan houden met de kwaliteit van de producten die opgeleverd worden. Dit zal voornamelijk te maken hebben met de programmatuur.

2.2.

Cultuur

Iedere afdeling en iedere werknemer heeft zijn eigen functie en de taken die daarbij horen. Ze zijn zeer zelfstandig met betrekking tot de werkzaamheden die uitgevoerd moeten worden. Dit heeft mede te maken met de regels en procedures die gehanteerd worden binnen Indicia. Ondanks de zelfstandigheid is er veel communicatie tussen de afdelingen om bijvoorbeeld de voortgang van een project vast te stellen. Het is naar mijn mening van groot belang dat binnen bedrijven met een dergelijke omvang zoals bij Indicia regels en procedures gehanteerd worden, omdat er anders veel chaos zou ontstaan. Nu weet iedereen wat hij op welk moment moet doen en hoeveel tijd hiervoor staat gepland.

Wanneer de cultuur binnen Indicia vergeleken wordt met de theorie [17], dan blijkt hieruit dat er een combinatie is tussen een rollen- en een taakcultuur. Dit is te merken door de procedures en regels, maar ook door de taakgerichtheid van de werknemers van Indicia.

(12)

Pagina 12 van 40

2.3.

Plaats binnen de organisatie

Mijn plaats binnen Indicia is binnen het Java development team. Omdat ik mijn eigen project heb, zal ik tot het einde hiervan niet veel te maken krijgen met de dagelijkse activiteiten van het team. Ik zal echter af en toe meehelpen met de activiteiten van het team mocht dit nodig zijn. Op het moment dat mijn opdracht afgerond is zal ik volledig met de activiteiten van het team gaan meewerken; maar tot die tijd zal de opdracht voorrang krijgen op andere activiteiten.

Mijn werkplek bevindt zich op de development verdieping, dit is de derde verdieping in het pand van Indicia. Hierop zijn alle development teams werkzaam en zo ook het Java development team. Ik heb een vaste plaats net naast de andere teamleden van het Java team; eventuele ondersteuning van verschillende teamleden is dus dichtbij.

2.4.

Invloed van de organisatie

Het project is voortgekomen vanuit de organisatie waarna we in overleg tot de opdrachtformulering zijn gekomen. In overleg hebben we besloten de aandacht voornamelijk te leggen op de ontwikkeling en minder op het vooronderzoek met betrekking tot de pakketten. Mede hierdoor is de invloed die de organisatie op het project heeft gehad goed te zien, vooral in de beginfase van het project was dit het geval. Zo is er tijdens het onderzoek vanuit de organisatie een bepaalde voorkeur uitgesproken, deze voorkeur is daarna nader bekeken en heeft meer aandacht gehad dan andere mogelijkheden. De voorkeur betrof een combinatie van twee pakketten die gekoppeld de basis voor het portaal moest vormen.

Later tijdens het project is er in overleg een besluit genomen over welke portlet zelf ontwikkeld moest worden en over welke functionaliteiten deze moest beschikken. Hierbij heeft de organisatie dus ook invloed gehad, echter in veel mindere mate dan bij het bovenstaande.

(13)

Pagina 13 van 40

3.

Probleemanalyse

Dit hoofdstuk verschaft een overzicht van de opdracht die centraal staat tijdens het project en hoe deze ingevuld is. Om de opdracht, het probleem, goed te benaderen is er een probleemanalyse gemaakt waarin het probleem uiteen gezet wordt, om het zo in delen aan te pakken en tot een goed resultaat te leiden.

3.1.

Situatie

Indicia biedt een oplossing voor portaalsoftware in de vorm van Microsoft Sharepoint. Sharepoint is een portaal pakket dat met behulp van zogenoemde webparts opgebouwd kan worden door de beheerder. Deze webparts bieden allerlei verschillende functionaliteiten die samen een

portaalpagina kunnen vullen met onder andere informatie en documenten. Sharepoint is op basis van het .NET framework en dus komen de klanten terecht bij de .NET kant van Indicia. Het Java ontwikkelteam zoekt naar een soortgelijk systeem op basis van een Java open source pakket.

Wanneer het Java team deze oplossing kan bieden zijn de klanten niet meer gebonden aan Microsoft en .NET, iets wat bijvoorbeeld overheidsinstanties graag zien. Vanuit deze gedachte is de opdracht ontstaan en later verder uitgewerkt door de leider van het Java ontwikkelteam en mijzelf.

3.2.

De probleemstelling

De opdracht die uit bovenstaande situatie tot stand gekomen is luidt als volgt:

Onderzoek doen naar een aantal Java-gebaseerde open source systemen en met behulp van een longlist en shortlist een selectie maken. De selectie zal plaats vinden aan de hand van requirements die vastgesteld worden op basis van de functionaliteiten van Microsoft Sharepoint. Het geselecteerde systeem moet uit te breiden zijn met extra maatwerk functionaliteiten in de vorm van JSR168 portlets om een (beperkt) alternatief te kunnen bieden voor het niet open source systeem Microsoft Sharepoint, met als doel een volwaardig intranetportaal te kunnen opzetten met dit systeem. Als laatste zal met behulp van een businesscase aangetoond worden dat het geheel goed werkt.1

De opdracht kan opgesplitst worden in twee deelproblemen, deze deelproblemen zijn onlosmakelijk met elkaar verbonden en zullen pas na elkaar aangepakt kunnen worden. Hieronder staan de twee deelproblemen:

1

De opdrachtformulering wijkt af van de oorspronkelijke opdracht, zoals deze ingediend is, omdat uit het onderzoek is gebleken dat het niet nodig is meerdere systemen te koppelen om de basis van het portaal te vormen. De opdracht is aangepast in overleg met beide begeleiders; hieruit is de keuze naar voren gekomen om het ontwikkel deel van de opdracht te richten op het ontwikkelen van eigen maatwerk portlets met de JSR 168 standaard.

(14)

Pagina 14 van 40

• Onderzoek

Het eerste deelprobleem is in de vorm van een onderzoek; in dit onderzoek zullen verschillende systemen onderzocht worden met als eerste MS Sharepoint [13] voor de functionele requirements en daarna de diverse open source kandidaten. Uit dit onderzoek moet minimaal één kandidaat naar voren komen waarmee in de ontwikkelfase van het project gewerkt kan worden.

• Ontwikkeling

Het tweede deelprobleem is het ontwikkelen van extra functionaliteiten voor het in het onderzoek gekozen systeem. De extra functionaliteiten zullen tijdens en na afloop van het onderzoek bepaald worden, ze moeten het standaard systeem aanvullen waar het te kort schiet. De functionaliteiten van een portaal zijn in de vorm van portlets, de te ontwikkelen portlets zullen moeten voldoen aan de JSR 168 [2] standaard, zodat deze eventueel hergebruikt kunnen worden in andere portaaloplossingen.

3.3.

Doelstellingen

In dit project zijn er een aantal doelstellingen die behaald moeten worden om het project succesvol af te ronden. Deze doelstellingen zijn:

• Tijdens het onderzoek dat in de eerste fase van het project gedaan zal worden moeten de mogelijkheden van MS Sharepoint in kaart gebracht worden.

• Tijdens een pakketselectie traject moet een selectie gemaakt worden uit het aanbod van open source systemen die beschikken over een aantal functionaliteiten waarover MS Sharepoint ook beschikt. Tevens dient dit traject te worden gedocumenteerd.

• Er dient een businesscase opgesteld te worden om de gemaakte oplossing te toetsen op volledigheid. Wellicht moet Indicia zelf deze businesscase aanleveren of een soortgelijke praktijksituatie omschrijven. De businesscase zal een beschrijving moeten vormen van een totale situatie zoals die gerealiseerd moet worden.

• Aan het einde van het project, 29 januari, moet er een portaaloplossing op basis van een Java open source pakket gerealiseerd zijn. Het portaal moet als een alternatief kunnen dienen voor MS Sharepoint.

• Het systeem moet gemakkelijk uit te breiden zijn met extra functionaliteiten, zodat het ook in de toekomst als alternatief voor MS Sharepoint kan blijven dienen.

3.4.

Eindproduct

Aan de hand van bovengenoemde doelstellingen zal het eindproduct tot stand komen. Het eindproduct zal bestaan uit een open source pakket met de basisfunctionaliteiten waarover MS Sharepoint ook beschikt. Dit zal leiden tot een (beperkt) alternatief voor MS Sharepoint waarmee een volwaardig intranetportaal opgezet kan worden. Het eindproduct zal gemakkelijk uit te breiden moeten zijn waardoor specifieke functionaliteiten zonder problemen toegevoegd kunnen worden aan het portaal. Dit moet te realiseren zijn met de mogelijkheid om extra JSR168 portlets aan het portaal toe te voegen.

(15)

Pagina 15 van 40

4.

Plan van aanpak

In het plan van aanpak is het project nader beschreven; het plan van aanpak dat ik geschreven heb tijdens de eerste drie weken van het project is bijgevoegd als bijlage II. Dit hoofdstuk is een korte samenvatting van het plan van aanpak met daarin onder andere de producten die ik wil opleveren en de planning van het project. 2

4.1.

Producten

In het plan van aanpak is aandacht besteed aan de producten die gepland staan om opgeleverd te worden. Bij deze producten staan een aantal andere documenten die niet direct gerelateerd zijn aan het eindproduct. De producten die opgeleverd worden aan Indicia zijn onder andere een SAD en een pilot versie van de portaaloplossing die gecreëerd zal worden.

SAD: Dit staat voor “Software Architecture Document”, dat is een ontwerp document waarin de architectuur en de opbouw van de te ontwikkelen onderdelen nader wordt beschreven. Pilot versie portaaloplossing: Dit is een eerste versie van het systeem; deze versie bevat zoveel mogelijk functionaliteiten om aan te kunnen tonen dat het systeem een alternatief kan zijn voor MS Sharepoint. Tevens kan deze versie van het systeem gebruikt worden om aan afdelingen en

potentiële klanten te demonstreren over welke functionaliteiten het beschikt. De functionaliteiten van het systeem zullen de basis van een portaal vormen en enkele maatwerk functionaliteiten zullen erin worden opgenomen.

4.2.

Kwaliteit

Om de kwaliteit van de producten te waarborgen zijn er in het plan van aanpak enkele acties en regels opgesomd. Door deze aan te houden zullen de producten van een goede kwaliteit zijn, waardoor ze eventueel later nog in te kijken zijn om bepaalde zaken op te zoeken.

Tevens wordt er gebruik gemaakt van delen van de ontwikkelmethode RUP, om zo de ontwikkeling van het eindproduct te ondersteunen en te documenteren aan de hand van een standaard. Omdat RUP te groot is voor dit project, zijn hiervan alleen de relevante delen gekozen.

2

Bij dit hoofdstuk moet opgemerkt worden dat het plan van aanpak geschreven is voorafgaand aan het onderzoek naar de open-source pakketten. Dit houdt in dat er in het oorspronkelijke plan van aanpak een andere opdrachtomschrijving gehanteerd wordt dan in dit procesverslag.

(16)

4.3.

Planning

In het plan van aanpak is ook een planning opgenomen om de op te leveren producten af te zetten tegen de tijd van het project. Hierdoor is snel te zien waar het project is en wat er wanneer opgeleverd moet worden. De planning die ook in het plan van aanpak zit is hieronder opgenomen.

(17)

Pagina 17 van 40

5.

Methoden en technieken

Dit hoofdstuk bevat de methoden, technieken en tools die ik gebruikt heb bij de totstandkoming van de verschillende producten. Sommige keuzes hoefden niet gemaakt te worden omdat deze als standaard binnen Indicia gebruikt worden. Daarentegen was ik vrij om andere keuzes te maken, de argumenten voor deze keuzes worden in dit hoofdstuk beschreven.

5.1.

Methoden

Een belangrijk aspect bij software ontwikkeling is de ontwikkelmethode; hiervoor zijn vele

verschillende modellen en technieken bedacht met ieder zijn eigen karakteristieke eigenschappen. Voor ieder project en iedere aanpak kan een bepaalde manier van ontwikkeling beter geschikt zijn dan een andere.

Gezien het project en de voorkeur vanuit Indicia hebben we gekozen voor een “agile”

ontwikkelmethode. Hierin staat het iteratief en incrementeel werken centraal en is er veel interactie met de opdrachtgever en eindgebruiker. Het eindproduct wordt in incrementen ontwikkeld, dit wil zeggen dat steeds delen van het systeem besproken worden met de opdrachtgever, die daarna worden ontworpen en ontwikkeld. Er wordt dus steeds naar een prototype van het systeem toegewerkt waarbij de functionaliteiten groeien naarmate het ontwikkeltraject vordert. Deze prototypes worden besproken en hierbij kan worden aangegeven of er nog veranderingen moeten plaats vinden. Tevens wordt het volgende increment bepaald dat ontwikkeld moet worden. Dit proces wordt meerdere malen doorlopen tot dat de deadline bereikt is. Het uitbreiden van het systeem gebeurt op basis van de prioriteit van de functionaliteiten, de meest belangrijke eerst en zo verder tot de minst belangrijke.

Een van de ontwikkelmethoden die op deze manier te werk gaat is het Rational Unified Process [11], beter bekend als RUP. Bij RUP is een project verdeeld in een viertal fasen:

• inceptiefase (aanvang)

Tijdens deze eerste fase wordt de haalbaarheid van het project vastgesteld; zo worden de inhoud en de begrenzingen bepaald. Dit wordt gedaan door middel van het omzetten van het idee naar een productvisie in het vision document. Tevens worden de globale kosten en de verwachte baten geschat en worden de belangrijkste risico’s in kaart gebracht. Dit alles met het doel om te bepalen of er een “Go” of “No Go” gegeven wordt voor het project.

• elaboratiefase (detaillering)

Wanneer het project het groene licht krijgt kunnen de functionele requirements worden gespecificeerd door middel van use cases. Tevens wordt tijdens deze fase de architectuur van het systeem bepaald en ontworpen; hierbij wordt de technische haalbaarheid beoordeeld. Hierbij is het Software Architecture Document (SAD) een belangrijk document dat gebruikt wordt bij de bouw van het systeem. De producten van deze fase zijn een plan voor het project (Plan van Aanpak) en het SAD.

• constructiefase (bouw)

(18)

Pagina 18 van 40

beschreven gebeurt dit in de vorm van incrementen en iteraties. Het systeem wordt stukje bij beetje vorm gegeven en wordt doorontwikkeld tot het gewenste resultaat of de deadline bereikt is.

• transitiefase (overdracht)

Wanneer het systeem ontwikkeld is wordt er overgegaan op het valideren van het systeem met behulp van de belanghebbende. Tevens vinden er tijdens deze fase andere activiteiten plaats zoals het voorbereiden van de implementatie, de nazorg en de overdracht van de verantwoordelijkheden.

Ik heb ervoor gekozen om RUP als ontwikkelmethode te gebruiken voor het project. Dit heeft voornamelijk te maken met de vaststaande deadline en de functionaliteiten die tijdens het project groeien. We willen een zo compleet mogelijk product opleveren, maar weten nog niet hoe het zal verlopen en welke functionaliteiten wel en niet haalbaar zijn. We zijn afhankelijk van de beschikbare open source systemen en het onderzoek naar de functionaliteiten van MS Sharepoint. Dit is de reden waarom we met incrementen willen gaan werken; zo wordt er eerst een basis gecreëerd en vanuit deze basis breiden we uit naar het gewenste resultaat.

Het nadeel van RUP met betrekking tot mijn project is de grootte van de projecten waarvoor RUP bedoeld is. Dit vonden ook de mensen achter “ RUP op maat”: bij een kleiner project is het moeilijk te bepalen welke onderdelen wel en welke niet te doen. RUP op maat [12] is van Nederlandse afkomst en is bedoeld voor projecten van 10 tot 15 personen die ongeveer 1 jaar de tijd hebben voor een project. Ook dit is nog veel te groot voor mijn project, daarom heb ik een selectie gemaakt van de belangrijkste en meest nuttige onderdelen van RUP op maat. Dit heeft als resultaat dat er een aantal documenten opgeleverd worden, onder andere een SAD, vision document en use case document.

Test methoden

Voor het testen van het eindproduct is er gekozen om gebruik te maken van een testplan en Unit tests. Deze twee methoden van testen richten zich beide op verschillende gebieden van de software, het testplan richt zich de functionaliteit van het programma daarentegen zijn Unit tests gericht op de interne werking van de code van het programma. Er is gekozen voor deze methoden omdat hiermee met een groot gedeelte van de software getest kan worden, zowel intern als functioneel. Een bijkomend voordeel van Unit tests is dat ze steeds bij iedere aanpassing zonder al te veel moeite uitgevoerd kunnen worden en de interne werking te controleren.

5.2.

Technieken

UML

UML staat voor Unified Modeling Language en is een modelmatige taal om ontwerpen en

diagrammen te maken voor een informatiesysteem. UML kenmerkt zich door de grafische weergave van bepaalde aspecten van een informatiesysteem. UML is platform onafhankelijk en kan dus gebruikt worden om een systeem te ontwerpen zonder dat het platform hiervan bekend is.

Java

(19)

Pagina 19 van 40

opdracht afkomstig is van het Java ontwikkelteam. Java is een object georiënteerde taal met heel veel standaard bibliotheken. Dit houdt in dat het hergebruik van eigen code en code van andere programmeurs heel veel voorkomt. Hierdoor hoeft vaak het wiel niet opnieuw uitgevonden te worden, waardoor veel tijd bespaard kan worden tijdens de ontwikkeling.

JSP

JSP (Java Server Pages) is een techniek om dynamische HTML, XML of andere inhoud te genereren op basis van statische en dynamische elementen. Dit wil zeggen dat bijvoorbeeld een webpagina opgebouwd kan worden met een inhoud afhankelijk van de acties die de gebruiker ondernomen heeft.

JSP wordt in combinatie met Java gebruikt voor de weergave en werking van een portlet. Volgens de gehanteerde standaard JSR 168 moet een portlet met behulp van deze technieken ontwikkeld zijn, hierdoor stond het gebruik van JSP al vast.

Hibernate [7]

Het hibernate framework is een open source ORM-oplossing (Object/Relational Mapping) speciaal voor Java. Met dit framework wordt er een koppeling gelegd tussen Java-klassen en

databasetabellen. Het zorgt tevens voor ophaalfuncties, waardoor de ontwikkelaar aanzienlijk minder tijd kwijt is aan het schrijven van database interactie code. Liferay en haar portlets maken gebruik van het Hibernate framework; ik heb ervoor gekozen om dit voor de maatwerk portlets ook te gebruiken om de standaard aan te houden.

MySQL

MySQL is een open source database managementsysteem dat gebruik maakt van SQL. Dit type database wordt heel veel gebruikt bij webapplicaties omdat het snel en gemakkelijk in gebruik is. Liferay ondersteunt vele soorten dataopslag methoden, toch heb ik juist voor MySQL gekozen. Dit heb ik gedaan omdat er binnen Indicia veel ervaring met MySQL is en de ondersteuning vanuit de gemeenschap rondom Liferay is op dit gebied heel groot.

5.3.

Tools

Tijdens de ontwikkeling van de producten heb ik gebruik gemaakt van verschillende programma’s of hulpmiddelen. Hierin was ik helemaal vrij om te kiezen en hier staan dan ook de argumenten voor de gemaakte keuzes.

MS Office Visio

Voor het modelleren van de diagrammen die in de verschillende RUP-documenten te vinden zijn, heb ik gebruik gemaakt van Microsoft Office Visio 2007. Nadat ik met verschillende programma’s zoals Eclipse en Netbeans met UML plugins geprobeerd had om de modellen te maken, bleek dat dit met beide programma’s niet gemakkelijk of zelfs helemaal niet ging. Zo bevat bijvoorbeeld Netbeans maar een beperkt aantal modellen, waardoor er geen standaard stijl aangehouden kan worden. Om deze redenen heb ik gekozen voor Visio dat wel alle benodigde modellen ondersteunt, gemakkelijk werkt en waarbij één uniforme stijl aangehouden kan worden.

Netbeans

(20)

Pagina 20 van 40

portlets. Deze plug-in zorgt er onder andere voor dat Netbeans de gewenste portlet structuur in een project hanteert. Ik heb voor deze combinatie gekozen omdat hierdoor de portlets automatisch volgens de JSR168 standaard opgezet worden. Volgens deze standaard zijn portlets op een bepaalde manier opgebouwd en ingedeeld; deze structuur wordt door Netbeans gegenereerd.

Liferay plug-ins SDK

De plug-ins SDK [3] (Software Development Kit) van Liferay is een klein progamma dat gebruik maakt van de Ant technologie om een basis project te genereren voor thema’s en portlets. Ik vind echter het portlets gedeelte niet fijn werken en ik gebruik dus alleen het thema gedeelte. Voor een thema worden onder andere de benodigde “CSS” bestanden gegenereerd, zoals deze in het gedefinieerde basis thema zijn. Hierin kunnen gemakkelijk aanpassingen gedaan worden om zo de stijl aan te passen. Voor deze tool heb ik gekozen omdat dit zeer handig is om een project te starten en er niet helemaal opnieuw begonnen hoeft te worden. Wanneer er dus een standaard stijl is voor alle portalen kan deze steeds weer opnieuw gegenereerd worden. Tevens is het speciaal gemaakt voor Liferay waardoor het perfect aansluit op het portaal.

MySQL query browser

Met deze tool van Sun Microsystems kan er connectie gemaakt worden met een MySQL server. Deze server kan één of meerdere databases bevatten die bekeken, aangemaakt, gewijzigd en verwijderd kunnen worden met de query browser. Een deel van deze acties kan met behulp van de menu’s en een deel van de acties moet door middel van SQL code uitgevoerd worden. Deze tool is zeer handig om de inhoud van de tabellen te bekijken en om zelfgeschreven queries te testen vooral als deze complexer worden.

Ik heb ervoor gekozen om deze tool te gebruiken omdat deze tool een goede en overzichtelijke output biedt en mogelijke fouten in de SQL duidelijk worden aangegeven.

TortoiseSVN

Om over de Liferay broncode te kunnen beschikken moet deze gedownload worden van de centrale Liferay SVN. Dit is een versiebeheer systeem op een server van Liferay waar ze de broncode van het portaal en de portlets verzamelen en bewaren. Wanneer iemand de broncode wijzigt of aanvult kan dit naar de server gestuurd worden zodat ook andere mensen van de nieuwe code gebruik kunnen maken.

Ik heb gebruik gemaakt van TortoiseSVN om delen van de broncode te downloaden, zoals de portal en een aantal voorbeeld portlets.

(21)

Pagina 21 van 40

6.

Uitvoering

Dit hoofdstuk bevat een beschrijving van hoe het project verlopen is en welke werkzaamheden er uitgevoerd zijn om tot het eindproduct te komen. De werkzaamheden zijn in chronologische volgorde beschreven.

6.1.

Voorbereiding

Ter voorbereiding op het project heeft er een opfrissing van de aan bod komende technieken plaats gevonden, dit was voornamelijk in de eerste vier weken van het project. Tijdens deze opfrissing is er vooral ingegaan op de technieken die door het Java team bij Indicia gebruikt worden zoals JSP, Hibernate en Struts. Deze technieken worden veel gebruikt in de lopende projecten van Indicia. Een andere taak die is uitgevoerd tijdens de voorbereidingsfase is het opstellen van de eerste

projectgerelateerde documenten, zoals een plan van aanpak en een oriëntatieverslag om kennis over de organisatie en het project op te doen.

Om voor afwisseling te zorgen tijdens de voorbereidingsfase zijn de bovengenoemde taken naast elkaar uitgevoerd, zodat de werkzaamheden gevarieerd bleven en niet eentonig werden. De voorbereidingsfase heeft een aantal documenten als resultaat; zo zijn de volgende documenten opgeleverd: Oriëntatieverslag, Plan van aanpak en Vision document.

6.2.

Vooronderzoek

Toen de voorbereidingsfase was afgerond kon er daadwerkelijk begonnen worden met de uitvoering van het project. De eerste stap bij de uitvoering van het project was het vooronderzoek van de functies waarover Microsoft Sharepoint beschikt. Dit was nodig omdat het eindproduct van het project een alternatief moet bieden voor Sharepoint. Zo is er aan de hand van de functionaliteiten van Sharepoint een lijst met functionele eisen opgesteld die gebruikt is bij het onderzoek naar de open source pakketten. De functionaliteitenlijst met beschrijving en afbeelding is opgenomen in het vision document alsmede een tabel met daarin de prioriteit van de functionaliteit.

Aan de hand van de functionele eisen zijn er een aantal pakketten op een longlist gezet die nader onderzocht dienden te worden. Nadat de longlist was samengesteld en er begonnen kon worden aan het omzetten van longlist naar shortlist, is er in een bespreking door de organisatie een voorkeur uitgesproken voor twee pakketten op de longlist. Deze voorkeur heeft het vooronderzoek dusdanig beïnvloed dat er niet meer gesproken kan worden van een echte pakketselectie. Dit heeft als nadeel dat niet alle mogelijkheden evenveel aandacht hebben gehad, waardoor de kans bestaat dat er een ander pakket zou zijn geselecteerd. Daarentegen is het voordeel hiervan dat er minder tijd besteed hoefde te worden aan het vooronderzoek waardoor de twee overgebleven pakketten uitgebreider getest konden worden.

Bij het aannemen van de opdracht was afgesproken dat er een vooronderzoek gedaan zou worden, maar dat de aandacht van de opdracht op de ontwikkeling zou komen te liggen. Mede hierdoor woog de voorkeur vanuit de organisatie zwaar en is de uiteindelijke shortlist ontstaan met daarop twee portaal pakketten, Liferay en Alfresco.

(22)

Pagina 22 van 40

6.3.

Pakket selectie

Doordat de shortlist maar twee pakketten bevat konden beide pakketten uitgebreid getest worden, zodat er een indruk opgedaan kon worden hoe de pakketten werken en wat de mogelijkheden ervan zijn.

Alfresco (Community Edition) is het eerste pakket dat geïnstalleerd en getest is op haar

functionaliteiten en “look & feel”; de bevindingen hiervan zijn opgenomen in het document Pakket selectie. De installatie van Alfresco maakt gebruik van een standaard “wizard” waarin bepaalde keuzes gemaakt moeten worden die de installatie en configuratie van het pakket beïnvloeden. Nadat het pakket was geïnstalleerd is er een analyse uitgevoerd met behulp van de lijst met functionele eisen. Deze zijn één voor één aan bod gekomen en is er gekeken of de functionaliteit ondersteund wordt.

Dezelfde werkwijze is ook gehanteerd om het pakket Liferay (Standard Edition) te testen, ook hier zijn de functionele eisen één voor één aan bod gekomen en zijn de bevindingen ervan

gedocumenteerd. Hierbij moet opgemerkt worden dat de installatie van Liferay niet middels een wizard verloopt, de geteste versie van Liferay wordt geïnstalleerd door het uitpakken van een bestand dat een bundel bevat van Liferay en tomcat [4].

Nadat beide pakketten getest waren zijn de bevindingen besproken met de leider van het Java team van Indicia. In dit gesprek is de conclusie getrokken dat beide pakketten te weinig van elkaar verschillen om op basis van functionaliteiten een keuze te maken. Hierdoor is er besloten om het technische aspect van beide portalen te beoordelen en de keuze hierop te baseren. Ook op het technische vlak voldoen de pakketten aan de opgestelde eisen en zijn de verschillen minimaal, waardoor er wederom een ander aspect bij betrokken moest worden. Ditmaal kwam het kostenplaatje van beide pakketten in beeld, omdat ondanks het open source karakter er betaald moet worden voor licenties en ondersteuning. Dit onderzoek kon op dat moment niet voltooid worden omdat de precieze kosten van Liferay alleen op aanvraag beschikbaar zijn en dit lang op zich heeft laten wachten, dus ook op het kostenplaatje kon de keuze niet gebaseerd worden.

In overleg is besloten om de keuze te baseren op het gebruiksgemak van beide pakketten waardoor Liferay de voorkeur geniet en dus het pakket is geworden dat gebruikt wordt voor de rest van het project. Een aantal weken nadat de keuze op Liferay gevallen was kwam ook de prijsaanvraag binnen en hieruit bleek dat een Liferay portaal minder kosten met zich mee brengt dan een Alfresco portaal.

6.4.

Businesscase implementatie & analyse

Nadat het vast stond dat Liferay de basis zou gaan vormen voor het project, kon over gegaan worden naar de volgende fase; in deze fase is er aan de hand van een bestaande situatie een businesscase opgesteld. De businesscase representeert een situatie die in de praktijk voor kan komen en dient dus als een goede verificatie voor het portaal.

Aan de hand van de businesscase is het testportaal omgebouwd tot een implementatie zoals deze in de businesscase zou zijn. De stijl van het portaal is te vergelijken met die van de businesscase, ook is de configuratie van het portaal specifieker ingericht en wordt er gebruik gemaakt van een database in plaats van bestanden om data op te slaan. Tevens zijn hier ook de functionaliteiten van de

(23)

Pagina 23 van 40

businesscase geïmplementeerd en zijn er met behulp van rechten bepaalde instellingen gedaan om ook het rechtensysteem in werking te zien.

Een ander groot en belangrijk punt in de businesscase en voor het project is de uitbreidbaarheid van het portaal. Om dit te testen is er een zelf ontwikkelde portlet in het bestaande portaal

geïmplementeerd. Deze portlet is op basis van functionaliteiten en techniek te vergelijken met andere portlets, omdat het gebruik maakt van een database en door middel van het Hibernate [7] gegevens ophaalt en wegschrijft.

Tijdens de businesscase analyse zijn alle aandachtspunten nadrukkelijk bekeken en beoordeeld op de mate waarin ze voldoen aan de businesscase. Zo zijn er een aantal belangrijke punten naar voren gekomen die extra aandacht vereisen. Hieruit is ook gebleken welke functionaliteiten er nog extra ontwikkeld dienen te worden in de volgende fasen van het project.

6.5.

Portlet ontwerp

Uit de businesscase analyse is onder andere gebleken dat er met de standaard Liferay portlets geen mogelijkheid is voor een degelijk FAQ systeem met een beheerders gedeelte. In overleg is er besloten om deze functionaliteit zelf te gaan realiseren en hiermee invulling te geven aan het ontwikkel gedeelte van de opdracht.

Allereerst is er gekeken naar de functionele eisen van de FAQ portlet, aan de hand van deze eisen is de volgende RUP documentatie tot stand gekomen:

• Use case document

In het use case document is beschreven wat het systeem moet kunnen alsmede de actoren die interactie hebben met het systeem. Middels een use case diagram wordt getoond wat de samenhang tussen verschillende use cases is en welke actor er gebruik van maakt. Tevens worden de use cases in de opgenomen use case specificaties nader toegelicht.

• Software Architecture Document

In het SAD wordt de technische kant van het systeem toegelicht. Dit document bevat verschillende “views” op het systeem en geeft middels verschillende diagrammen aan hoe het systeem er uit moet komen te zien.

Deze twee documenten zijn gebruikt bij het ontwikkelen van de portlet en dienen als leiddraad tijdens het ontwikkeltraject. Tevens kunnen ze gebruikt worden om als buitenstaander te weten te komen wat de portlet doet en hoe hij in elkaar zit.

6.6.

Portlet realisatie

Na de ontwerpfase kon de realisatie fase van start gaan met de eerste iteratie. Deze iteratie moest de functionaliteiten bevatten zoals die zijn beschreven in de ontwerpdocumenten. Aan de hand van de MoSCoW-lijst in het use case document is bepaald wat de prioriteit is van de functionaliteiten. Op volgorde van prioriteit moesten de functionaliteiten gerealiseerd worden, zodat de belangrijkste functionaliteiten zeker in de portlet opgenomen zijn. De prioriteit loopt van “Must have” als belangrijkste naar “Would have” als minst belangrijk.

(24)

Pagina 24 van 40

Voor de ontwikkeling van de FAQ portlet is er gebruik gemaakt van het open source pakket Netbeans. Dit pakket in combinatie met de plug-in “Generic Portlet” is uitermate geschikt voor de ontwikkeling van een JSR 168 portlet.

6.6.1

Eerste iteratie

De eerste stap in de ontwikkeling was het realiseren van een basis waarop de FAQ portlet verder gebouwd kon worden. Deze basis bevat het weergeven van een voorbeeld tekst in de vorm van twee afzonderlijke portlets die samen in één pakket geïnstalleerd kunnen worden, ook wel deployen genoemd. Om dit te realiseren moesten beide portlets in één pakket zitten en dit moest ook in de portlet-configuratiebestanden aangepast worden [5]. Tevens moest er in de basis een hibernate connectie naar de database gelegd worden voor het ophalen en wegschrijven van gegevens. Nadat de basis van de beide portlets correct was opgezet konden de functionaliteiten gerealiseerd worden. Als eerste was dit de weergave van de vragen met de mogelijkheid om erop te klikken zodat de betreffende vraag met bijbehorend antwoord zichtbaar worden. De vragen en antwoorden worden opgeslagen in één tabel in dezelfde MySQL database als de rest van het portaal. Deze tabel is te zien in afbeelding 6.1. De eerste gegevens zijn met de hand direct in de database ingevoerd omdat hiervoor nog geen mogelijkheid was in de portlet. Met de realisatie van de eerste functionaliteiten was er al een groot gedeelte van de displayportlet, de portlet die een gebruiker van het portaal te zien krijgt, afgerond. Er restte voor dit gedeelte van de portlet alleen nog een teller functie die bijhoudt hoe vaak een bepaald antwoord bekeken is. Dit was echter geen “Must have” op de MoSCoW-lijst, dus gingen anderen functionaliteiten voor.

Afbeelding 6.1: FAQ database tabel

Andere “Must have” functionaliteiten op de lijst waren die van het beheren van de FAQ’s. Deze omvatten het toevoegen, verwijderen en deactiveren van een FAQ. Het verwijderen en deactiveren van een FAQ kan vanuit een overzicht gedaan worden, dit overzicht is de “startpagina” van het beheerders gedeelte van de portlet, in het systeem heet dit gedeelte adminportlet.

Voor het toevoegen van een FAQ is er binnen een JSP pagina een formulier gecreëerd waarop alle benodigde informatie ingevuld dient te worden, deze pagina is te bereiken via de “startpagina” van het beheerders gedeelte van de portlet. Met de afronding van deze functionaliteiten waren ook alle “Must have” functionaliteiten op de lijst afgerond en kon er begonnen worden met het realiseren van de “Should have” functionaliteiten op de lijst. Deze functionaliteiten zijn niet noodzakelijk voor de correcte werking van het systeem en hebben dus een lagere prioriteit.

De “Should have” functionaliteiten op de lijst bestonden uit de eerder genoemde teller functie en het bewerken van een bestaande FAQ. De teller functie hoogt het aantal malen bekeken op met 1

(25)

Pagina 25 van 40

wanneer er op een bepaalde vraag geklikt wordt in de displayportlet.

Voor het bewerken van een FAQ wordt hetzelfde formulier gebruikt als dat voor het toevoegen, alleen is het ingevuld met de bestaande gegevens. Toen ook deze functionaliteiten in de portlet waren opgenomen en getest, was de gehele MoSCoW-lijst afgewerkt, dus het einde van de eerste iteratie bijna bereikt. Om deze iteratie af te ronden is het product in een korte sessie aan de

opdrachtgever getoond waarna er feedback gegeven is over het product. Uit deze feedback bleek dat de portlet toch nog enkele functionaliteiten miste die wel opgenomen hadden moeten worden. Om dit te corrigeren is er een tweede iteratie van start gegaan.

6.6.2

Tweede iteratie

In de tweede iteratie is er begonnen met het ontwerpen van het systeem, de bestaande

documentatie is aangepast aan de nieuwe eisen en wensen. Dit heeft onder andere geresulteerd in een nieuwe versie van het use case document en het Software Architecture document, hierdoor is van beide documenten de versie opgehoogd tot versie 2.0.

De functionaliteiten die in deze iteratie aan bod kwamen zijn aan de MoSCoW-lijst toegevoegd met een prioriteit. Wederom is er begonnen met de functionaliteit met de hoogste prioriteit, dit was het toevoegen van een zoekfunctie aan de displayportlet. Met de zoekfunctie kan de gebruiker de actieve FAQ’s doorzoeken met één of meerdere woorden. Daarna is er een XML exporteer functie ontwikkeld die benaderd kan worden door gebruikers en andere systemen.

Als laatste is er een sorteer functionaliteit toegevoegd zodat een gebruiker de FAQ’s kan sorteren op datum en meest bekeken. Na de afronding van deze functionaliteiten is het product weer voorgelegd aan de opdrachtgever.

6.7.

Testen FAQ portlet

Het testen van de FAQ portlet is gedaan op twee vlakken, de interne code en functionaliteiten. De interne code is getest met whiteboxtests, bij deze tests draait het om het testen van interne programmacode. Hierbij is de code bekend en kan er dus op kleine delen van de programmacode getest worden.

De functionaliteiten van de FAQ portlet zijn getest met blackboxtests, hierbij draait het om het testen van een functionaliteit en de werking ervan. Dit gebeurt meestal aan de hand van een aantal

testcases die vooraf opgesteld zijn.

6.7.1. Whiteboxtests

Om de interne werking van de portlet te testen is er gebruik gemaakt van zogehete Unit tests, deze tests kunnen automatisch uitgevoerd worden en geven aan of een test geslaagd of mislukt is. Omdat de tests in dit project niet automatisch uitgevoerd kunnen worden, is er gebruik gemaakt van een link in de portlet. Door op deze link te klikken worden alle tests na elkaar uitgevoerd. Deze tests zijn expliciet gericht op de gegevens verwerking; zo zijn er tests gericht op het toevoegen, het wijzigen en het ophalen van gegevens. In de output van de server wordt het resultaat van deze tests

weergegeven, hieruit kan worden opgemaakt of de interne functies van de FAQ portlet correct werken.

Het voordeel van Unit tests is dat ze steeds bij een wijziging in de code uitgevoerd kunnen worden om de methode te testen, zonder dat hiervoor vele handmatige handelingen gedaan moeten worden. Het is hierbij echter wel van belang dat de output van de server inzichtelijk is, omdat hierin het resultaat van de tests getoond wordt.

(26)

Pagina 26 van 40

Na het doorlopen van de Unit tests was het resultaat dat alle tests succesvol waren uitgevoerd zonder foutmeldingen. Dit betekend dat de portlet correct werkt en dus klaar is voor de volgende stap in de testfase.

6.7.2. Blackboxtests

Nadat de Unit tests correct waren uitgevoerd en daarmee de ontwikkeling van de FAQ portlet bijna was afgerond, kon er aan de laatste stap begonnen worden. Deze stap is het testen van de

functionaliteiten, hiervoor is de portlet getest aan de hand van het vooraf opgestelde testplan. Hierin worden alle functionaliteiten aan de hand van scenario’s getest. In een scenario staat precies

beschreven waar geklikt, en wat er waar ingevuld dient te worden; hierbij kan het zijn dat er expres verkeerde gegevens worden ingevuld om te testen of hiermee rekening gehouden is.

Nadat het complete testplan was uitgevoerd waren alle tests geslaagd op één na, het sorteren werkte niet helemaal goed. Deze fout is opgespoord en opgelost, daarna is de portlet opnieuw geïnstalleerd en is de test nogmaals uitgevoerd. Nu was het resultaat wel goed en kan er dus

geconstateerd worden dat alle functionaliteiten correct werken. De bevindingen tijdens deze testfase zijn in het testplan opgenomen, hierdoor is het testplan een testrapport geworden.

6.8.

Implementatie en oplevering

Om het project af te ronden is het portaal op de server geïnstalleerd, deze installatie is ingericht als demonstratieversie van het project en het Liferay portaal. Deze demonstratieversie van het portaal kan door de afdeling sales gebruikt worden om de mogelijkheden van het pakket te tonen aan klanten. De testdata en de businesscase data zijn uit deze versie verwijderd en vervangen door demonstratie data.

Voor de afronding van de FAQ portlet is er een handleiding geschreven die gebruikt kan worden bij het gebruik van de portlet of om de werking van de portlet beter te begrijpen. De handleiding gaat in op de indeling van de portlet in de twee delen, de werking en het gebruik van de beide delen. Met behulp van schermafbeeldingen en plaatjes van de knoppen worden de handelingen verduidelijkt. Tevens zijn de geschreven Unit tests opnieuw uitgevoerd op de server ter controle van de code van de FAQ portlet. Deze tests werden allemaal met een goed resultaat afgerond, waaruit geconcludeerd kan worden dat de FAQ portlet naar behoren werkt.

Om het gehele portaal af te ronden is er een SSO (Single-Sign-On) functionaliteit op de server geïnstalleerd, door deze functionaliteit wordt de gebruiksvriendelijkheid van het portaal verhoogd. Door SSO kan de autorisatie van gebruikers geautomatiseerd worden. Een voorbeeld hiervan is dat een gebruiker zich aanmeldt op een werkstation op zijn werkplek; wanneer deze gebruiker het portaal benadert worden zijn inloggegevens automatisch doorgegeven en hoeft hij niet nogmaals in te loggen.

(27)

Pagina 27 van 40 Afbeelding 7.1: Vergelijkingstabel pakketselectie rapport

7.

Resultaten

In dit hoofdstuk staat beschreven welke resultaten er geboekt zijn na de in hoofdstuk 6 beschreven uitvoering. Sommige van deze resultaten zijn opgeleverd en ander zijn belangrijk geweest voor de verdere ontwikkeling van het project.

7.1.

Vooronderzoek

Voorafgaand aan de ontwikkelfase van het project is er een rapport opgesteld naar aanleiding van het vooronderzoek. In dit rapport staat de afweging tussen de pakketten Liferay en Alfresco vermeld; zo zijn de functionaliteiten, de technische aspecten en de kosten, op welke punten de pakketten zijn vergeleken, in dit rapport opgenomen. Aan het einde van het rapport is de conclusie opgenomen, waarin de keuze voor Liferay duidelijk wordt.

7.2.

FAQ portlet

Voorafgaand aan de realisatie van de portlet zijn er een aantal documenten geschreven waarin onder andere het ontwerp van de portlet verduidelijkt wordt. Deze documenten kunnen gebruikt worden voor eventuele aanpassingen of ter verduidelijking van de werking van de portlet. De

ontwerpdocumentatie is met de oplevering van het systeem overhandigd zodat het in het beheer van Indicia komt. De ontwerp documentatie bestaat onder andere uit een use case document, SAD en Testplan.

Tijdens de ontwikkelfase van het project is de nadruk gelegd op de ontwikkeling van een portlet voor het eerder opgezette Liferay portaal. De portlet die is ontwikkeld, is een FAQ portlet die bestaat uit twee delen, een beheergedeelte en een weergavegedeelte. Beide portlets zitten in één pakket zodat ze tegelijk geïnstalleerd kunnen

worden binnen een portaal of op een server. Het weergavegedeelte kan alleen gebruikt worden voor het opzoeken van een FAQ en het antwoord er van te bekijken. In afbeelding 7.2 is een

schermafbeelding te zien van het weergavegedeelte.

Afbeelding 7.2: Schermafbeelding weergavegedeelte FAQ portlet

Het beheergedeelte, weergegeven in afbeelding 7.3, kan gebruikt worden om het weergavegedeelte te voorzien van gegevens. Zo kunnen in het beheergedeelte FAQ’s worden toegevoegd, bewerkt en verwijderd.

(28)

Pagina 28 van 40

worden zonder dat dit invloed heeft op de werking. De twee gedeeltes kunnen dus onafhankelijk van elkaar bestaan, maar ze hebben elkaar wel nodig om het gewenste resultaat te bereiken.

Afbeelding 7.3: Schermafbeelding beheergedeelte FAQ portlet

7.3.

Handleiding

Een ander document dat is opgeleverd aan Indicia is de handleiding voor de FAQ portlet. In deze handleiding is stap voor stap beschreven hoe de portlet werkt en hoe men ermee dient om te gaan.

7.4.

Eindproduct

Aan het einde van het project is het eindproduct en de bijbehorende documentatie opgeleverd aan Indicia; dit eindproduct is de totale Liferay installatie inclusief MySQL database. Het eindproduct is geïnstalleerd op een server in het serverpark van Indicia en is overgedragen aan de Java

ontwikkelafdeling, die het vanaf de overdracht in handen heeft. Het eindproduct is zo ingericht dat het door de sales afdeling gebruikt kan worden ter demonstratie en door de Java ontwikkelafdeling om zich op het pakket te oriënteren.

Het eindproduct is voorzien van een vorm van Single-Sign-On functionaliteiten. In de opgeleverde versie van het systeem is het portaal gekoppeld met de active directory server, waardoor het mogelijk is voor gebruikers die wel in de active directory staan maar niet in de database van het portaal om toch in te loggen op het portaal; dit kan dan met dezelfde gegevens als van hun Windows account. Gebruikers die op deze manier inloggen worden voorzien van een gast account, de

beheerder van het portaal hoeft hen alleen nog maar in te delen en de juiste rechten te verlenen. Hieronder, in afbeelding 7.4, is een grafische weergaven van het gehele eindproduct opgenomen om een impressie te geven wat dit zo al bevat; de lichtelijk gearceerde onderdelen geven aan wat er tot het eindproduct behoord.

In deze afbeelding is te zien dat er op de Indicia server een Tomcat installatie staat die fungeert als webserver. Op de webserver staat het Liferay portaal dat is geconfigureerd voor deze specifieke situatie. Binnen het Liferay portaal met de standaard functionaliteiten is de ontwikkelde FAQ Portlet geïnstalleerd. Het portaal en de portlets maken gebruik van Hibernate voor database interactie met de MySQL database. Het laatste onderdeel van het eindproduct is de Single-Sign-On functionaliteit, hiervoor is er een koppeling met de Active directory van Indicia.

(29)

Pagina 29 van 40 Afbeelding 7.4: Grafische weergave eindresultaat

Bovengenoemde onderdelen vormen samen het portaal zoals dat beschikbaar is als

demonstratieversie; in afbeelding 7.5 is een schermafbeelding van de “home-pagina” van de

demonstratieversie van het Liferay portaal weergegeven. De demonstratieversie van het portaal is zo ingericht dat het enkele verschillende functionaliteiten van het portaal weergeeft. De teksten die in het portaal zijn opgenomen zijn gericht op Indicia en het portaal om zo wat extra informatie te verschaffen over het portaal.

(30)

Pagina 30 van 40

In de bovenstaande afbeelding is te zien hoe de demoversie van het portaal eruit ziet. De stijl van het portaal is geheel aanpasbaar door middel van de CSS opmaak bestanden, die ingeladen worden als thema van het portaal.

Pagina’s van het portaal zijn opgebouwd uit verschillende portlets zoals onder andere een Log-in portlet, Content portlets en de zelfgemaakte FAQ portlet. Deze portlets kunnen door gebruikers met de juiste rechten verplaatst, geminimaliseerd en gemaximaliseerd worden. Links boven op de pagina is het logo van het bedrijf te zien met daarnaast de naam van het portaal. In de rechter bovenhoek is het menu zichtbaar, vanuit dit menu zijn de vele opties van het portaal beschikbaar. Voor de

beheerder zitten hier onder andere de opties bij om extra portlets aan de pagina toe te voegen of naar het configuratiescherm te gaan.

(31)

Pagina 31 van 40

8.

Conclusie en aanbevelingen

De conclusies die getrokken zijn uit de uitvoering en resultaten van het project zijn in dit hoofdstuk beschreven. Tevens worden er in dit hoofdstuk aanbevelingen gedaan met betrekking tot het product en waar op gelet moet worden in eventuele vervolgprojecten.

8.1.

Eindproduct

In deze paragraaf zijn de conclusies en aanbevelingen ten opzichte van het eindproduct opgenomen. De aanbevelingen zijn gericht op een mogelijk vervolgproject.

8.1.1. Conclusie ten opzichte van het eindproduct

Het eindproduct is een werkend geheel dat geïmplementeerd kan worden bij, en in gebruik

genomen kan worden door, klanten. Het systeem is in een vroeg stadium waarin het portaal nog niet volledig getest is, omdat dit te groot is en buiten de scope van het project valt. De vereiste

functionaliteiten zijn echter wel getest en goed bevonden zoals in het testplan staat

gedocumenteerd. Het is mogelijk om met het eindproduct een Liferay portaal op te zetten dat een volwaardig alternatief is voor Microsoft SharePoint, hetgeen het doel van de opdracht was. Zoals in het hoofdstuk “Resultaten” staat vermeld, is het eindproduct overgedragen aan de Java ontwikkelafdeling van Indicia en is het klaar voor gebruik. Een demonstratieversie van het portaal is aanwezig op de server van Indicia en kan gebruikt worden door de sales afdeling .

Nadat het systeem op de server was geïnstalleerd, werd pas goed zichtbaar hoe het bij een echte klant zou kunnen gaan draaien. De volledige functionaliteit van het portaal, de mogelijkheid om zeer gemakkelijk uitbreidingen toe te voegen en de Single-Sign-On integratie zorgen ervoor dat het product goed functioneert en er prima uit ziet. Dit leidt tot de conclusie dat ik zeer tevreden ben over het eindresultaat, en ik hoop dat met de afronding van dit project er een start is gemaakt voor een goede portaaloplossing die in de toekomst verder uit zal groeien tot een volwaardige tegenhanger van Microsoft SharePoint. Het is nu aan de leiding van het ontwikkelteam om ervoor te zorgen dat er intern draagvlak wordt gevormd, zodat het product ook daadwerkelijk verkocht gaat worden.

8.1.2. Aanbevelingen ten opzichte van het eindproduct

Na afloop van het project zijn er nog een aantal aanbevelingen ten opzichte van het eindproduct om dit te verbeteren en/of uit te breiden.

Documenten-portlet

Een belangrijk punt in deze aanbeveling is dat er een verbetering van de documenten-portlet

geïmplementeerd moet worden. Deze standaard Liferay portlet is niet goed genoeg waneer hij wordt ingezet binnen organisaties waarbij vertrouwelijke documenten gedeeld worden via het portaal. Het probleem zit hem in het toepassen van het rechten systeem waarvan deze portlet gebruik maakt. Het delen van bestanden en mappen en hierop rechten toepassen werkt prima, echter heeft de portlet ook een “recente documenten” optie waarin de nieuwste documenten komen te staan. Bij deze optie worden de rechten niet toegepast waardoor alsnog iedereen deze bestanden kan inzien.

Mogelijke oplossingen hiervoor zijn om de portlet zo aan te passen dat de rechten op de juiste manier toegepast worden; een andere manier is om het “recente documenten” tabblad te verbergen zodat deze niet meer toegankelijk is.

(32)

Pagina 32 van 40

Uitbreidingen

Tijdens het project was er vanuit de organisatie belangstelling voor het eindproduct, en hebben een aantal collega’s een korte demonstratie gekregen van het product op dat moment. Vanuit

verschillende afdelingen zijn er suggesties gedaan om het project uit te breiden en het zo te laten aansluiten op wensen van de betreffende afdelingen. Zo kwam de sales afdeling met de suggestie om er een grafieken portlet in te integreren zodat het portaal gebruik zou kunnen worden voor een nieuw project. Binnen Indicia is er al ervaring met een grafieken pakket genaamd Jasper Reporting, dit is ook een open source pakket en is dus wellicht geschikt om te integreren met Liferay.

Een andere suggestie kwam vanuit een projectmanager die graag een integratie zou zien tussen het Liferay portaal en een aantal interne systemen. Deze integratie zou gebruikt kunnen worden om aan te tonen dat er vele mogelijkheden zijn op het gebied van koppelingen met andere systemen. Uit het oogpunt van deze projectmanager zou door deze uitbreiding het product vele malen interessanter worden voor organisaties omdat ze hiermee alles in één systeem kunnen zien.

Beide suggesties kunnen een meerwaarde vormen voor het eindproduct, maar wegens de scope en de duur van het project is dit niet opgenomen in het eindproduct. Om deze reden is het een

aanbeveling voor een mogelijk vervolgproject, zodat ze opgenomen kunnen worden in latere versies van het systeem.

8.2.

Conclusies Open source

Dit project heeft zich geheel afgespeeld binnen open source systemen, hierdoor is er een extra paragraaf opgenomen omdat dit een zeer belangrijke rol gespeeld heeft tijdens het project. Deze paragraaf richt zich op de voordelen, nadelen en problemen die zich tijdens dit project voorgedaan hebben met betrekking tot open source.

8.2.1. Voordelen

De voordelen die ik heb ondervonden tijdens het project zijn hieronder vermeld met een korte uitleg waarom dat ik het als voordeel zie.

Gratis probeerversies

Eén van de grootste voordelen van open source is wel dat er vrijwel altijd een gratis versie beschikbaar is. Dit kan zijn voor een bepaald aantal dagen maar ook een wat minder goede en stabiele versie. Hierdoor kan het pakket voordat er eventueel kosten gemaakt worden voor een licentie of support contract goed bekeken worden of het pakket geschikt is voor een bepaalde situatie.

Veel voorbeelden

Doordat van de meeste pakketten de broncode inzichtelijk is, kan iedereen aanpassingen en uitbreidingen maken op het standaard pakket. Vaak worden deze aanpassingen met andere gedeeld zodat ook zij er gebruik van kunnen maken. Hierdoor zijn er voor de meeste open source pakketten veel voorbeelden beschikbaar die ook weer gebruikt kunnen worden om andere aanpassingen van af te leiden.

(33)

Pagina 33 van 40

Snel resultaat

Door gebruik te maken van een open source pakket hoeft een project niet vanaf de grond af opgebouwd te worden, dit bespaart veel tijd die aan andere dingen besteed kan worden. Doordat het een bestaand werkend pakket is, is er vaak al snel resultaat zichtbaar zodat dit bijvoorbeeld getoond kan worden aan een klant.

Uitbreidbaarheid

Door het open source karakter van de pakketten is een pakket meestal gemakkelijk uit te breiden, er vanuit gaande dat de broncode inzichtelijk is. Dit komt omdat er precies gekeken kan worden hoe het pakket werkt en wat er precies gebeurt. Op deze gebeurtenissen kan mogelijk ingehaakt worden zodat de eigen functionaliteiten uitgevoerd kunnen worden.

8.2.2. Nadelen

Tijdens het project zijn er ook nadelen van het gebruik van open source pakketten aan het licht gekomen; deze nadelen staan hieronder opgesomd.

Afhankelijkheid

Bij veel open source pakketten is er geen tot weinig ondersteuning vanuit de ontwikkelaar. Om dit op to lossen neemt de community dit vaak over waardoor je afhankelijk bent van de ondersteuning die de community kan bieden. Wanneer er gebruik wordt gemaakt van een pakket met een kleine community, dan kan het probleem ontstaan dat de ondersteuning niet optimaal is.

Onduidelijke ondersteuning community

Wanneer de community om ondersteuning gevraagd wordt, kan het gebeuren dat de reactie onduidelijk is. Dit kan vele oorzaken hebben zoals: miscommunicatie, slecht taalgebruik of onduidelijkheid over het probleem. Een bijkomend probleem is dat ook andere hun probleem erbij kunnen zetten waardoor het mogelijk de focus verliest.

Andermans code

Wanneer er aanpassingen aan de code van een open source systeem gedaan worden heb je altijd te maken met de code van iemand anders. Het is mogelijk dat deze code niet goed is gedocumenteerd, waardoor deze onduidelijk wordt; het kost dan veel tijd om precies te begrijpen wat er gebeurt.

Verschillende programmeerstijlen

Bij Open source pakketten en/of uitbreidingen hierop is vaak te zien dat er vele verschillende programmeurs aan gewerkt hebben, doordat de verschillende programmeerstijlen goed zichtbaar zijn. Wanneer hiermee gewerkt dient te worden dan is dit niet een optimale situatie; vaak is het tijdrovend om te wennen aan de verschillende stijlen.

8.2.3. Problemen

De problemen waarmee het project in aanraking is gekomen met betrekking tot open source staan hieronder vermeld. Deze problemen waren lastig te traceren en hebben voor vertraging gezorgd, waardoor de betreffende activiteiten langer duurden dan gepland.

Missende bestanden

Referenties

GERELATEERDE DOCUMENTEN

· soorten van moties. Zij kun- nen variëren van vrij onschuldig en welwillend tot min of meer duidelijke betuigingen van afkeu- ring of wantrouwen. Zij kunnen een

In uw motie van 11 november 2016 (reg.nr 6022760) verzoekt u het college zich in te spannen voor een gezamenlijke strategie met Dimpact-gemeenten en/of de VNG op het gebied van

Open source solutions have multiple sources of information which a tool can process to evaluate the quality of an OS component.. In this research data available through GitHub

publiceren van software voor sommige partijen ook een negatieve impact kan hebben (software die openbaar gemaakt is en hergebruikt mag worden hoeft niet opnieuw geschreven te

Dat betekent dat als je kennis nodig hebt, je zelf je weg moet zoeken tot je iemand gevonden hebt die je verder kan helpen hetgeen en dat kost veel tijd en moeite (wat een barrière

Aangezien de printkop en de zuigers aangestuurd wordt door stappen motoren kan naar aanleiding hiervan een uitspraak gedaan worden over de nauwkeurigheid van deze motoren.. -

Despite the scale and complexity a lot of information could be extracted from the real-world data. Of the methods developed in chapter 3 only the cluster analysis and the Bass

During the first phase a case study has been carried out to gain more insight in vertical collaboration in OS business and in the second part a survey has been carried out in order