Eindverslag Silverlight Project Argentum

Eindverslag Argentum Ardon Hendrickx ₁

Eindverslag

Silverlight Project Argentum

Cursus: Werkend Leren 2 Schooljaar: 2009/2010 Periode: Kwartaal 3 en 4.

Student(nummer): Ardon Hendrickx (2003749)

Datum: 14-6-2010

Versie: 1.0

Afstudeer bedrijf: Datamex Breda B.V. Bedrijfsbegeleider: Dhr. E. Beijer Docent begeleider: Dhr. E.J. de Voogt

Voorwoord

In de periode tussen februari 2010 en juni 2010 heb ik, Ardon Hendrickx, mijn afstudeerstage mogen doen bij Datamex Breda BV. Dit document is de afsluiting van het Argentum project, zoals de

stageopdracht binnen Datamex is benoemd. Het doel van het Argentum project is het opleveren van een ‘Proof of Concept’ van een CRM applicatie geschreven in Silverlight 4.

De afstudeeropdracht is onderdeel van de studie Informatica aan de Avans Hogeschool te Breda. Het tussenverslag is een onderdeel van deze afstudeeropdracht en daarom zowel bestemd voor de docent begeleider als het afstudeerbedrijf.

Voordat ik begon bij Datamex Breda B.V. had ik totaal geen kennis van Silverlight en de

achterliggende technieken. Tijdens de afstudeerstage heb ik niet alleen ontzettend veel geleerd van Silverlight maar ben ik ook erg goed ondersteund met betrekking tot het gehele proces van schets naar applicatie. Zowel mijn bedrijfsbegeleider Erik Beijer alsook Michael Jepson en Jasper Siegmund hebben mij hierin ondersteund en deze zou ik voor al hun inzet, via deze weg, graag willen

bedanken. Daarnaast ben ik uiteraard ook dhr. Arno Bouman dankbaar voor het geven van de mogelijkheid om binnen Datamex te mogen afstuderen.

Ardon Hendrickx. Breda, 14-6-2010

Eindverslag Argentum Ardon Hendrickx ₃

Samenvatting

Is het mogelijk om in Silverlight 4, de nieuwe ontwikkelomgeving van Microsoft, een professionele bedrijfsapplicatie te maken?

Om deze vraag te beantwoorden is binnen Datamex Breda B.V. het interne project Argentum opgestart. Het doel van dit project is het uitwerken van diverse functionele eisen om zo inzicht te krijgen in de mogelijkheden van Silverlight 4.

Allereerst is gestart met het onderzoeken welke menustijl het beste bij een, op het internet gebaseerde, bedrijfsapplicatie past. Hierin is gekeken naar meeste gebruikte resoluties en

webbrowsers en daarnaast zijn de verschillende menustijlen uitgelicht. Dit onderzoek heeft geleid tot de keuze van een Ribbon en Accordeon menu.

Het project is voortgezet met een onderzoek naar geschikte toolkits voor het Argentum project. Voor Silverlight zijn diverse toolkits beschikbaar welke ondersteuning bieden aan de ontwikkeling van Silverlight applicaties. Voor dit onderzoek zijn eerst de functionele eisen van het Argentum project bepaald. Deze eisen zijn grotendeels geëxtraheerd uit het huidige ‘Customer Relationship Management’ (CRM) applicatie (PRO/CRM) van Datamex Breda B.V. en volgens de DSDM

ontwikkelmethode uitgewerkt in een MoSCoW lijst, welke de eisen naar prioriteit indeelt. Aan de hand van dit onderzoek is een tweetal toolkits gekozen voor gebruik binnen het Argentum project. Om tot de uiteindelijke aanbeveling te komen is een praktijk onderzoek gestart in de vorm van applicatie ontwikkeling. Elke verplichte functionele eis is hierbij geprobeerd uit te werken. Hiertoe is een ‘proof of concept’ applicatie, in de vorm van een CRM, ontstaan.

Het gehele project is uitgevoerd volgens de DSDM ontwikkelmethode. Deze methode ondersteunt iteratieve ontwikkeling en variabele functionele eisen.

Uiteindelijk is aan Datamex Breda B.V. een positieve aanbeveling gedaan met betrekking tot het gebruik van Silverlight 4 voor het ontwikkelen van professionele bedrijfsapplicaties.

Inhoudsopgave

2.2 Plaats en rol binnen Datamex ... 9

3 Opdracht ... 10 3.1 Aanleiding ... 10 3.2 Afstudeeropdracht ... 10 4 Ontwikkelmethode ... 11 4.1 Afstudeer proces ... 11 4.2 Vooronderzoek ... 11 4.3 Ontwikkelmethode: DSDM ... 12 4.3.1 DSDM: De principes ... 12 4.3.2 DSDM: De fasen ... 12 4.3.3 Timeboxing ... 14 4.4 Verantwoording ontwikkelmethode ... 15 4.4.1 Onzekere factoren ... 15 4.4.2 Vaste factoren ... 15 4.4.3 Overweging ... 15 5 Uitvoering project ... 16 5.1 Oriënterende fase ... 16

5.1.1 Oriëntatieverslag en plan van aanpak ... 16

5.1.2 Onderzoek ontwikkelmethoden ... 18

5.1.3 Onderzoek menustijlen ... 20

5.1.4 Onderzoek toolkits ... 22

5.2 Functionele iteratie fase ... 25

5.2.1 Functioneel ontwerp ... 25

5.2.2 Uitwerking User Interface ... 27

5.2.3 Technisch ontwerp / Onderzoeksplan ... 29

5.3 Design en Build iteratie fase ... 36

5.3.1 Menu structuur ... 36

Eindverslag Argentum Ardon Hendrickx ₅

5.3.3 Authenticatie... 39

5.3.4 Autorisatie ... 40

5.3.5 Cliëntside loggen ... 42

5.3.6 Outlook integratie, E-mail verzenden ... 43

5.3.7 Exceptions afvangen ... 45

5.3.8 Relatiebeheer (CRUD) ... 47

5.3.9 Contactpersoonbeheer (CRUD) en koppeling contactpersoon met relatie. ... 49

5.3.10 Paging ... 52 5.3.11 Filteren (zoeken) ... 52 5.3.12 Afdrukvoorbeeld ... 53 5.3.13 Afdrukken ... 53 6 Conclusie ... 55 6.1 De Argentum applicatie. ... 55 7 Aanbevelingen ... 56 7.1 Datamex ... 56 7.1.1 Ontwikkelmethodiek. ... 56 7.1.2 Omschrijving afstudeerproject. ... 56

7.1.3 Uitleg gebruik van interne middelen. ... 56

7.2 Avans ... 56

7.2.1 Tijdige oplevering documentatie en informatie. ... 56

8 Evaluatie ... 57

8.1 Projectmethodiek ... 57

8.1.1 Keuze van ontwikkelmethodiek. ... 57

8.1.2 Afwijkingen ontwikkelmethodiek ... 57

8.2 Waardeoordeel over eigen werk. ... 58

8.2.1 Documentatie ... 58

8.2.2 Applicatie ... 58

8.3 Persoonlijke ontwikkeling ... 59

9 Literatuurlijst ... 60

1 Inleiding

Binnen Datamex krijgen de projecten een projectnaam, zo ook het afstudeerproject. Project Argentum was origineel een ‘Proof of Concept’ CRM applicatie in Silverlight 4 welke gebruik zou maken van SharePoint 2010. Vanwege diverse omstandigheden is de aanpak van het project en de inhoudelijke opdracht halverwege de stageperiode gewijzigd. Argentum blijft een ‘Proof of Concept’ CRM applicatie welke gebouwd zal worden in Silverlight 4, echter een koppeling met SharePoint 2010 is van de functionele eisen lijst geschrapt.

Het doel van het project is om Datamex te laten zien of het mogelijk is om in Silverlight 4 een professionele bedrijfsapplicatie te maken.

Tijdens de stageopdracht wordt kennis gemaakt met het MVVM ontwerp patroon, C# programmeertaal, XAML, Silverlight 4, en uiteraard het achterliggende .NET framework.

Dit document beschrijft de aanpak van het project. In hoofdstuk 2 wordt de Datamex organisatie toegelicht en de plaats van de student binnen de organisatie. Hoofdstuk 3 zal de opdracht

specifieker uitwerken en in hoofdstuk 4 gaan we verder in op de ontwikkelmethode. De uiteindelijke uitvoering zal worden omschreven vanaf hoofdstuk 5. De gebruikte literatuur voor de

totstandkoming van dit document kunt u terugvinden in de literatuurlijst welke te vinden is in hoofdstuk 6.

Initieel zou het Argentum project door een tweetal stagiaires gemaakt worden. Halverwege de afstudeerperiode is Duncan echter dusdanig ziek geworden dat hij heeft besloten om te stoppen met afstuderen. Door dit besluit is het Argentum project gewijzigd en zijn enkele onderdelen geschrapt. Een belangrijk onderdeel welke geschrapt is, is de koppeling tussen Silverlight en SharePoint. Deze keuze is gemaakt omdat er te weinig tijd is om een degelijke applicatie neer te zetten en tegelijkertijd in te lezen in SharePoint. De onderdelen welke geschrapt zijn, zijn niet uit het eindverslag verwijderd maar voorzien van commentaar. Hierdoor blijft de opzet van het Argentum project helder. De mogelijkheid bestaat dat in dit document gesproken wordt met meervoud. De meervoudige verwijzing verwijst dan zowel naar mij als ook naar Duncan de Waard.

In dit document zijn diverse afkortingen gebruik. Deze afkortingen worden in paragraaf 1.1 toegelicht.

Eindverslag Argentum Ardon Hendrickx ₇

1.1 Definities en afkortingen

API

Application Programming Interface: Een verzameling definities op basis waarvan een programma kan communiceren met een ander onderdeel of programma. Vaak in de vorm van een bibliotheek.

C#

[See Sharp]: Programmeertaal ontworpen door Microsoft.

CRM

Customer Relationship Management. Een methode/tool om contactmomenten met relaties en contactpersonen vast te leggen.

MVC

Model-View-Controller. Ontwerp patroon welke de applicatie opdeelt in een drietal lagen; Model, View en Controller laag. Het MVC principe wordt als basis gebruikt bij het MVVM model, welke is toegepast op de Argentum applicatie.

MVVM

Model-View-ViewModel. Een ontwerp patroon gebruikt in software engineering afkomstig van Microsoft en gebaseerd op het MVC model. Gebruikmakend van dit patroon deelt men de applicatie architectuur op in een 3 tal lagen. Namelijk de ‘Model’-laag, waarin de logica geschreven wordt voor communicatie met de database (of overige databronnen). De ‘View’-laag, waarin het interface ontwerp staat en de ‘ViewModel’-laag welke de ‘View’ en het ‘Model’ koppelt.

MoSCoW

De MoSCoW-methode is een wijze van prioriteiten stellen over functionele eisen. De functionaliteiten worden opgedeeld in de volgende prioriteiten:

 Must Have

Deze functionaliteiten zijn noodzakelijk voor het systeem. Zonder deze functionaliteiten kan een CRM niet (goed) functioneren. Het is dus belangrijk dat deze functionaliteiten als eerste gerealiseerd worden.

 Should Have

De functionaliteiten die als prioriteit ‘Should have’ hebben, zijn niet noodzakelijk voor de werking van het systeem. Deze functionaliteiten bieden extra mogelijkheden en kunnen in het systeem worden opgenomen, indien de tijdsplanning dit toelaat.

 Could have

Dit zijn functionaliteiten die eventueel opgenomen kunnen worden in de applicatie. Deze functionaliteiten worden alleen toegevoegd, wanneer de klant hier specifiek om vraagt. De uren hiervoor worden normaliter doorbelast aan deze klant.

 Won’t Have

Dit zijn de functionaliteiten die geheel buiten het bereik van het project vallen.

POC

Proof of Concept. Afkorting welke staat voor een applicatie welke zijn dienst moet bewijzen. Een ‘Proof of Concept’ is vaak een applicatie welke alleen hoeft aan te tonen dat iets mogelijk is. Een PoC is dus geen applicatie welke na oplevering in gebruik genomen zal worden bij een klant.

2 Organisatie

2.1 Datamex Automatisering

Datamex Breda B.V. is actief als automatiseringsbedrijf in Breda en is marktleider op gebied van ERP-Software in onder andere de staalsector binnen Nederland. De hoofdactiviteit bestaat uit de

ontwikkeling van software, onder andere in .NET, maar voornamelijk in Progress.

Datamex biedt kantoorautomatisering voor vele MKB bedrijven. Op basis van bedrijfsprocessen richt ze zich op de volledige automatisering van het bedrijf van de klant. Datamex bestaat uit ongeveer 60 man personeel.

Directeur

Onder directeur _P&O

Sales Operations

Business Services Office

Services Projects

Service Desk Consultancy Progress

Development

Microsoft Development

Afbeelding 1: Organigram van Datamex

Datamex Minervum 7368 4817 ZH BREDA t: (076) 5 730 730 f: (076) 5 877 757 e:info@datamex.nl i: www.datamex.nl

Eindverslag Argentum Ardon Hendrickx ₉

2.2 Plaats en rol binnen Datamex

Tijdens de WL2 afstudeerstage zal ik op de Microsoft Development afdeling werken (zie paarse blok in afbeelding 1). Op deze afdeling zitten in totaal vier software ontwikkelaars. Er is dus voldoende kennis en ondersteuning aanwezig om te helpen tijdens het afstudeertraject.

Grotendeels zal ik bezig zijn met het ontwikkelen van een Proof of Concept (PoC) CRM systeem in het nieuwe Silverlight 4. Voorafgaand kijken we naar het bestaande CRM systeem van Datamex (PRO/CRM) om daaruit de belangrijkste functionaliteiten te extraheren. Alle documenten en beslissingen worden teruggekoppeld aan de afstudeerbegeleiders, dhr. Erik Beijer en dhr. Arno Bouman. Zij zullen mij ook voorzien van de nodige feedback en ondersteuning.

Het ontwikkeltraject zal ongeveer als volgt lopen:

 Functionaliteiten PRO/CRM extraheren;

 Functioneel ontwerp / Technisch ontwerp;

 Theoretische onderzoeken;

 Maken Proof of Concept CRM.

Tijdens het maken van de applicatie zal kennis worden opgedaan van de diverse programmeertalen en ontwikkelmethoden.

3 Opdracht

Hoofdstuk ‘Opdracht’ beschrijft de aanleiding van de opdracht en de daadwerkelijke opdrachtomschrijving.

3.1 Aanleiding

Datamex Breda BV wil graag meer kennis opdoen met betrekking tot Microsoft Silverlight 4. Om het bedrijf te oriënteren is gekozen om tijdens de afstudeerperiode een ‘Proof of Concept’ te maken. Het huidig CRM systeem van Datamex (PRO/CRM) zal hiervoor als basis dienen. Hierbij is vereist dat de applicatie kan functioneren vanuit een internet omgeving maar ook als stand-alone programma.

3.2 Afstudeeropdracht

Het maken van een Proof of Concept van een CRM. Het CRM dient als webservice te draaien op basis van het .NET framework. Hiervoor onderzoekt de student de mogelijkheden van Silverlight 4 met betrekking tot het gebruik als bedrijfsapplicatie. Uiteindelijk wordt er een PoC opgeleverd welke zal laten zien of een vervolg project, het daadwerkelijk uitwerken van een CRM in Silverlight 4, kans van slagen heeft.

Er is geen probleem met het huidige CRM programma, echter Datamex wil zich via deze weg ‘inlezen’ in de nieuwe technieken die recent op de markt zijn verschenen.

De student doet kennis op van C#, Silverlight 4 en XAML en het achterliggende Microsoft .NET Framework.

Eindverslag Argentum Ardon Hendrickx ₁₁

4 Ontwikkelmethode

Een ontwikkelmethode is de manier van aanpak voor het ontwikkelen van software. In de IT branche zijn diverse soorten ontwikkelmethoden. Voor het toepassen van een methode op het Argentum project is een vooronderzoek gedaan naar de mogelijke methoden en welke het beste aansluit op het Argentum project.

4.1 Afstudeer proces

Voordat men begint aan een software ontwikkeltraject bepaalt men welke ontwikkelmethode gebruikt gaat worden. Voor het afstudeerproject ben ik gestart met een onderzoek naar

ontwikkelmethoden maar vrij vroeg kwam al naar voren dat Datamex een eigen manier van werken heeft. Omdat het afstudeertraject dient aan te tonen dat je als student geschikt bent om in het bedrijfsleven te participeren, hebben we de Datamex methode doorgenomen en gekeken wat de aanpak van Datamex is met betrekking tot dit soort software ontwikkeltrajecten. Hiertoe hebben we in een sessie besloten dat we niet een standaard methode aanhouden maar gebruik maken van de manier waarop het in het bedrijfsleven bij Datamex gaat. De ‘Datamex software ontwikkelmethode’ zou dus dé methode worden voor aanpak van het Argentum project. Dit houdt in dat we eerst kijken naar de functionele eisen van het programma en vervolgens plan van aanpak in elkaar zetten. Daarnaast maken we een functioneel- en technisch ontwerp en een productverslag. Deze verslagen zouden voldoende houvast moeten bieden tijdens het afstudeerproject.

Halverwege het afstudeertraject kwamen echter naar voren dat het tijdens de afstudeerstage aangeraden wordt om een bestaande ontwikkelmethode te kiezen. Hiertoe hebben we besloten om het Argentum project nog eens goed tegen het licht te houden en te kijken welke ontwikkelmethode het beste aansluit en het meest geschikt is.

4.2 Vooronderzoek

Voor het maken van een PoC is geen standaard ontwikkelmethode beschikbaar. Om toch houvast te hebben tijdens de stageperiode is gekeken naar diverse bestaande software ontwikkelmethoden, zoals de Watervalmethode, DSDM, RUP en XP. Het vooronderzoek heeft een ontwikkelmethode opgeleverd welke, tijdens de stageperiode, als leidraad zal dienen. Het vooronderzoek wordt nader besproken in paragraaf 5.1.2 en is te vinden in de bijlagen. Uit dit onderzoek is naar voren gekomen dat DSDM de meest geschikte methode is voor het Argentum project. In de volgende paragraaf zal kort worden toegelicht wat DSDM nu precies inhoud. De daaropvolgende paragraaf beschrijft de verantwoording voor de keuze van DSDM.

4.3 Ontwikkelmethode: DSDM

DSDM is een ‘Agile’ software ontwikkelmethode, dit houdt in dat een project iteratief (herhalend) aangepakt zal worden. Het project zal hierbij opgedeeld worden in kleine stukjes (‘timeboxing’) en deze zullen afgewerkt worden. In de volgende paragraaf worden de basisprincipes van DSDM besproken, welke onderdelen zijn noodzakelijk om gebruik te kunnen maken van DSDM. De opvolgende paragraaf 4.2.2 bespreekt de hoofdfasen welke DSDM doorloopt. Tot slot wordt in paragraaf 4.2.3 het onderdeel ‘timeboxing’ toegelicht.

4.3.1 DSDM: De principes

DSDM komt voort uit ervaringen van diverse bedrijven, deze bedrijven hebben de krachten gekoppeld en een ontwikkelmethode bedacht. De bedrijven zijn voor DSDM tot een aantal basis principes gekomen. Deze principes zijn belangrijk voor het toepassen van de DSDM methode tijdens een project;

1. Actieve betrokkenheid van gebruikers is noodzakelijk; 2. DSDM-teams moeten gemachtigd zijn besluiten te nemen; 3. De aanpak is gericht op het frequent opleveren van producten;

4. Geschiktheid voor bedrijfsdoeleinden is het essentiële criterium voor de acceptatie van producten;

5. Iteratieve en incrementele ontwikkeling is noodzakelijk om te convergeren tot een juiste bedrijfsoplossing;

6. Alle wijzigingen tijdens de ontwikkeling zijn terug te draaien; 7. Eisen worden op hoog niveau vastgelegd;

8. Testen is geïntegreerd in de levenscyclus;

9. Een samenwerkende en coöperatieve houding van alle belanghebbenden is essentieel.

4.3.2 DSDM: De fasen

DSDM bestaat uit een viertal fasen, elke fase zal iteratief worden doorlopen totdat het gewenste resultaat bereikt is. De fasering binnen DSDM is als volgt;

1. Oriënterende fase

Tijdens de oriënterende fase wordt de geschiktheid van DSDM voor het project bepaald. Ook zal tijdens deze fase gekeken worden naar de functionele- en niet-functionele eisen van het project. Na afloop van deze fase worden de volgende producten opgeleverd:

Haalbaarheidsonderzoek en eerste opzet MoSCoW-lijst. De oriënterende fase bestaat uit de volgende elementen:

a. Men start met het haalbaarheidsonderzoek, ook wel ‘Feasibility study’, om te bepalen of het systeem, met de gekozen technische realisatie, kosten en tijdsduur, geschikt is voor het bedrijf;

b. Om de algemeen primaire functies van het systeem te bepalen en de gewenste betrouwbaarheid en prestaties vast te leggen voert men de ‘Business study’ uit. Als resultaat levert de business studie de MoSCoW lijst op. (zie ook paragraaf 4.2.4)

Eindverslag Argentum Ardon Hendrickx ₁₃ 2. Functionele Iteratie fase.

Men vervolgt met het doorlopen van de ‘Functional Model Iteration’. Tijdens deze fase probeert men door middel van o.a. prototyping gebruikerseisen te bepalen, informatie te verzamelen, de functionaliteit te tonen en niet-functionele eisen te achterhalen. Deze fase wordt net zo vaak herhaald (iteratie) als dat nodig is. Na afloop van deze fase worden de volgende producten opgeleverd: Functioneel ontwerp, Time Boxes (planning),

Onderzoeksplan en afgeronde vooronderzoeken. 3. Design en Build iteratie fase.

De opvolgende fase, ‘Design & build iteration’ kan al starten alvorens de ‘Functional Model Iteration’-fase voorbij is. Tijdens de ‘Design & Build Iteration’ werkt men het functionele prototype verder uit, met het doel om een design prototype op te leveren dat voldoet aan de functionele en niet-functionele eisen. Deze fase wordt, evenals de functionele iteratie fase, herhalend uitgevoerd. Na afloop van deze fase worden de volgende producten opgeleverd: Versie van de software welke geschikt is voor unit tests.

4. Implementatie fase.

Tot slot sluit men de opdracht af met de ‘Implementation’-fase, waarin het systeem wordt opgeleverd naar de eindgebruikers voor evaluatie en een project audit (hoe is het project verlopen) wordt uitgevoerd. Indien het systeem in orde is zal deze definitief worden opgeleverd. Indien dit niet het geval is zal het project terug gaan naar een eerdere fase. Na afloop van deze fase worden de volgende producten opgeleverd: Geïmplementeerd systeem, handleiding en gebruikerspresentatie.

Onderstaande afbeelding geeft een overzicht van de fasering van DSDM weer:

4.3.3 Timeboxing

DSDM gaat uit van een vaste opleverdatum en budget. Doordat deze twee onderdelen binnen het project vast staan dient men op een andere manier te managen. Het managen van het project gebeurd binnen DSDM dan ook op basis van functionaliteiten, deze manier van managen wordt ‘timeboxing’ genoemd.

De functionaliteiten worden opgesteld aan de hand van prioriteit. Functionaliteiten welke erg belangrijk zijn worden eerder gemaakt en opgeleverd dan functionaliteiten met minder hoge prioriteit. Bij de start van het project worden de eisen opgesteld. Op basis van deze eisen wordt een planning opgezet. Zodra er verschuivingen optreden worden de prioriteiten opnieuw bekijken. Het kan dus zijn dat er vooraf wordt besproken dat een bepaalde functionaliteit erg belangrijk is, maar later, bij vertraging van het project toch een minder hoge prioriteit krijgt. Uiteraard gebeurt het wijzigen van prioriteit in overleg met de klant. Deze manier van opdelen van functionaliteit op prioriteit heet binnen DSDM; ‘De MoSCoW methode’.

Eindverslag Argentum Ardon Hendrickx ₁₅

4.4 Verantwoording ontwikkelmethode

Het Argentum project heeft te maken met een aantal onzekere factoren en een aantal vaste factoren.

4.4.1 Onzekere factoren

Het concept dat we tijdens de stageperiode maken, dient aan te tonen dat het mogelijk is om diverse functionaliteiten uit te voeren in een voor Datamex onbekende ontwikkelomgeving,

Silverlight 4. Bij het maken van dit POC is vooraf niet of nauwelijks vast te stellen of het schrijven van de applicatie haalbaar is. Het doel van het POC is immers om te bewijzen dat een vervolg project haalbaar zou kunnen zijn (of misschien niet). De iteratieve ontwikkelmethode, DSDM is hier het meest op zijn plaats. Bij DSDM zijn immers de specificaties van het te realiseren project variabel. In het begin van het project worden op globaal niveau zowel de functionele- als de niet-functionele specificaties ingedeeld op prioriteiten met behulp van de MoSCoW lijst.

4.4.2 Vaste factoren

DSDM is een methode die de ontwikkeling van software vastlegt in een raamwerk van een tijdsplanning genaamd: ‘Timeboxing’. De duur van het project, de te gebruiken resources en de kosten staan hierbij vast. Binnen de verschillende ‘Timeboxes’ zullen de onderdelen van het Argentum project opgeleverd worden.

Er is gekozen voor de ontwikkelmethode DSDM, omdat deze het beste aansluit op het tijdsgebonden en onduidelijke verloop van het te ontwikkelen systeem. Deze methode is zeer geschikt voor

prototyping. Uiteraard is ook een haalbaarheidsonderzoek uitgevoerd welke eveneens aantoont dat DSDM geschikt is voor toepassing tijdens het Argentum project.

4.4.3 Overweging

De ontwikkelmethode DSDM gaat uit van vooraf gedefinieerde incrementen, ook wel, ‘Timexboxes’ (zie ook paragraaf 4.3.3.). Voor het Argentum project is wel gekozen om incrementele opleveringen te doen, maar is niet aan het begin van de periode vastgesteld wat er in welk increment opgenomen dient te worden. Hiervoor hebben we gekozen om wekelijks een vergadering te houden waarin besproken wordt wat het volgende increment zal omvatten en waar we dus komende weken mee aan de slag gaan.

Voor meer informatie over ontwikkelmethoden en het voorafgaande onderzoek naar de meest geschikte ontwikkelmethode voor het Argentum project zie paragraaf 5.1.2 verder in dit document.

5 Uitvoering project

Het hoofdstuk ‘Uitvoering project’ bespreekt de huidige voortgang van het project. Omdat er volgens de DSDM ontwikkelmethode is gewerkt is het hoofdstuk opgedeeld in drie van de vier hoofdfasen. De uiteindelijke applicatie zal namelijk enkel en alleen dienst doen als demo applicatie voor klanten van Datamex. De Argentum applicatie zal niet binnen een bedrijf geïmplementeerd worden daar het een concept applicatie betreft. Hierdoor is fase 4 van het DSDM traject,

implementatie, voor deze afstudeerstage niet van toepassing.

Paragraaf 5.1 beschrijft de oriënterende fase, waarin onder andere het haalbaarheidsonderzoek uitgeschreven wordt. Tijdens deze fase is ook een grove planning gemaakt en worden de verschillende vooronderzoeken uitgewerkt. Paragraaf 5.2 zal door de functionele iteratie lopen terwijl paragraaf 5.3 de ‘Design and Build’ iteratie fase beschrijft.

5.1 Oriënterende fase

Tijdens de afstudeerstage hebben we ons als eerst georiënteerd. Zowel binnen het bedrijf als ook de voor mij onbekende C# en .NET

technieken. De oriënterende fase beschrijft niet hoe ik me ingelezen heb in de C# programmeertaal, ik heb immers gewoon boeken door zitten werken en veel geoefend. Wel wordt beschreven hoe het plan van aanpak, de verschillende onderzoeken en de MoSCoW lijst tot stand zijn gekomen.

De oriënterende fase is de eerste fase van het DSDM traject.

5.1.1 Oriëntatieverslag en plan van aanpak

Als aanvang van stage is gestart met het schrijven van het oriëntatieverslag. Het oriëntatieverslag biedt onder andere; inhoudelijke houvast aan de stageopdracht, zorgt ervoor dat duidelijk is wat de stageopdracht precies inhoud, welke competenties de student zal verwerven, welke producten opgeleverd dienen te worden en hoe het stagebedrijf in elkaar steekt.

Tevens is in het begin van de stage gestart met het ontwikkelen van het plan van aanpak. Het Plan van Aanpak (PvA) bevat een planning welke is gebaseerd op de oplevering van de verschillende incrementen. Deze planning is gedurende het project gewijzigd in verband met ziekte van de medestagiair, Duncan de Waard, als ook uitlopende activiteiten (functionaliteiten die achteraf moeilijker bleken dan verwacht) of juist vanwege activiteiten die sneller uitgewerkt waren dan vooraf verwacht. De huidige planning gaat uit van een wekelijks feedback moment waarin gekeken wordt wat er uitgevoerd is en wat er komende week gaat gebeuren. Per week wordt dus bepaald wat er gedaan gaat worden. De planning, te vinden op de volgende pagina, dient hierbij wel als houvast.

Eindverslag Argentum Ardon Hendrickx ₁₇

Stage week

Datum Week Fase Omschrijving

1 08-02-2010 6 Oriëntatie Oriëntatie en inleveren afstudeer overeenkomst.

2 15-02-2010 7 Oriëntatie [Avans] Oriëntatieverslag inleveren.

3 22-02-2010 8 Oriëntatie [Avans] Definitieve opdrachtomschrijving inleveren.

4 01-03-2010 9 Oriëntatie Theoretisch onderzoek: Menustijlen opleveren.

5 08-03-2010 10 Oriëntatie

6 15-03-2010 11 Oriëntatie Oplevering Functioneel ontwerp en Onderzoeksplan.

7 22-03-2010 12 Func. Iteratie Onderzoek: Toolkits opleveren.

8 29-03-2010 13 Func. Iteratie 9 05-04-2010 15 Func. Iteratie 10 12-04-2010 17 Func. Iteratie 11 19-04-2010 18 Func. Iteratie 12 26-04-2010 19 Func. Iteratie 13 03-05-2010 20 Func. Iteratie

14 10-05-2010 21 Func. Iteratie [Avans] Tussenverslag inleveren.

15 17-05-2010 22 Func. Iteratie

16 24-05-2010 23 Func. Iteratie

17 31-05-2010 24 Func. Iteratie [Avans] Poster, Webpagina en Samenvatting inleveren.

18 07-06-2010 25 Func. Iteratie

19 14-06-2010 26 Oplevering [Avans] Eindverslag inleveren.

20 21-06-2010 27 Oplevering

5.1.2 Onderzoek ontwikkelmethoden

Zoals besproken in paragraaf 4.3. (Verantwoording ontwikkelmethode) is voorafgaand aan het kiezen van de geschikte ontwikkelmethode een onderzoek opgesteld. Het onderzoek kijkt naar diverse beschikbare ontwikkelmethoden en de mogelijkheid van toepasbaarheid op het Argentum project. Omdat binnen Datamex met een eigen ontwikkelmethode gewerkt wordt, is het onderzoek met een ietwat andere insteek gebeurd. Er is gekeken welke methode past binnen het bedrijf welke methode grotendeels past bij de huidige bedrijfsvoering. Tevens is gekeken naar eventuele

toevoegingen / verbeteringen voor de huidige ontwikkelmethode van Datamex. De ontwikkelmethoden welke tijdens het onderzoek tegen het licht zijn gehouden zijn:

 De watervalmethode, deze methode deelt het gehele project op in een zevental fasen welke achtereenvolgens, als zijnde een waterval, afgewerkt worden. Deze methode is niet iteratief wat wel een eis is voor het Argentum project en valt hierdoor dus al direct af.

 Scrum, welke als basis de watervalmethode aanhoudt maar niet al de experts

achtereenvolgens laat werken, maar allen tegelijk elke fase laat doorlopen. Zodat iedereen vanaf het begin af aan bij het project betrokken is. De Scrum methode vereist veel tijd en inzet van alle partners van het project, binnen Datamex is de tijd die Scrum vereist niet beschikbaar dus is ook deze methode niet geschikt.

 RUP, waarbij het project wordt opgedeeld in een viertal fasen welke achtereenvolgens doorlopen worden. RUP probeert zoveel mogelijk eisen en wensen vooraf afgebakend te krijgen en staat eigenlijk niet toe om deze eisen en wensen gedurende het project te wijzigen. Voor het Argentum project is het vooraf niet mogelijk om specifiek alle eisen, wensen en kosten vast te leggen. RUP is hierdoor niet geschikt als ontwikkelmethode voor het project.

 DSDM, Zoals uitgelegd in hoofdstuk 4 (Ontwikkelmethode).

 eXtreme Programming (XP), waarbij een geselecteerde hoeveelheid ontwikkelprincipes tot in het extreme worden doorgevoerd. Het Argentum project bevat echter teveel

functionaliteiten om XP te kunnen toepassen. Om al de functionaliteiten binnen de beperkte tijd af te krijgen is het niet handig om in paren te programmeren (één van de vele extreme principes van XP). Ook het extreem veel test welke volgens XP moeten worden doorgevoerd zijn niet rendabel voor een Proof of concept.

Uit het onderzoek is dus, zoals eerder besproken, naar voren gekomen dat DSDM de meest geschikte methode is voor het Argentum project.

Voordat we aan de slag zijn gegaan met DSDM hebben we een haalbaarheidsonderzoek uitgevoerd. De technische en organisatorische aspecten van het project worden tijdens dit onderzoek tegen het licht gehouden. Dit gebeurd aan de hand van een zogenaamde: ‘suitability list’. Deze lijst bekijkt per aspect hoe hoog het risico is. Bij teveel hoge risico’s is het project niet geschikt voor de DSDM ontwikkelmethode en wordt geadviseerd uit te wijken naar een andere methode.

Eindverslag Argentum Ardon Hendrickx ₁₉ Het haalbaarheidsonderzoek bevat een achttal groepen waarover vragen zijn beantwoord. Een

voorbeeld vraag uit de groep ‘Cultuur’; Zijn mensen bereid hun kennis te delen met anderen? Dit is een gesloten vraag dus men heeft maar twee mogelijke antwoorden. Indien men antwoordt met; Ja, dan vormt dit onderdeel een laag risico voor het project. Indien met antwoordt met; Nee, dan vormt dit onderdeel een hoog risico voor het project. Uiteindelijk levert elke vraag maximaal 10 punten op. Een laag risico antwoord betekent 0 punten risico, een hoog risico antwoord betekent 10 punten.

Het uiteindelijke resultaat van het haalbaarheidsonderzoek, voor toepassing van DSDM binnen Datamex, is verwerkt in de onderstaande grafiek.

Afbeelding 3: Resultaten DSDM onderzoek voor het Argentum project. Bron: 20100416_AH_DSDM_Haalbaarheidsonderzoek.docx

Per groep wordt een verschillend aantal vragen gesteld. Zo bevat de groep Management Organisatie slechts 3 vragen (maximaal 30 punten te behalen), terwijl de groep cultuur 7 vragen bevat (maximaal 70 punten te behalen). Te zien is dat elke groep een minimaal tot zelfs geen risico bevat. DSDM is dus een prima methode om toe te passen op het Argentum project.

In de bijlagen is het haalbaarheidsonderzoek terug te vinden.

10 0 5 10 10 15 0 0 60 50 60 70 60 60 30 40 0 10 20 30 40 50 60 70 80 90 Gebruikers Gebruikersmngt Organisatie Cultuur IT Werkn. IT Mngt. Mngt Organisatie. Technieken Resultaat Max

5.1.3 Onderzoek menustijlen

Binnen Datamex ontstond de discussie dat niet alle typen menu’s geschikt zouden zijn voor een webapplicatie. De discussie welke min of meer het hoogt oplaaide had betrekking op het Ribbon menu. Doordat de Argentum applicatie initieel binnen een webbrowser draait en niet direct op de desktop ben je standaard al veel ruimte kwijt aan menubalken e.d. De discussie ging over het feit dat een Ribbon menu nog veel minder ruimte over zou laten voor de echtelijke applicatie schermen. Omdat het menu de basis is van de applicatie heb ik een onderzoek ingesteld naar menustijlen en beschikbare ruimte binnen een webbrowser.

Allereerst is gekeken naar de huidige trend van meest gebruikte browsertypen. Elk type browser heeft immers zijn eigen afmetingen omdat elke browser gebruik maakt van een andere

menustructuur en lay-out. De ene browser gebruikt standaard meer menubalken dan de ander, waardoor er minder ruimte overblijft voor de applicatie. Voor dit onderzoek hebben we gekeken naar meerdere statistieken en bronnen. Over het algemeen kwam naar voren dat zowel Mozilla Firefox als Microsoft Internet Explorer de meest gebruikte webbrowsers zijn op dit moment.

Afbeelding 4: Meest gebruikte webbrowsers, februari 2010. Cijfers in procenten. Bron: stats.nedstars.nl

Vervolgens zijn we gaan kijken naar de meest gebruikte schermresolutie, op dit moment. Ook weer met in het achterhoofd dat het programma zoveel mogelijk ruimte moet houden en niet dat al de ruimte wordt opgeslokt door te grote menu’s of dergelijke.

Uit dit onderzoek is naar voren gekomen dat de top 3 schermresoluties wordt gevormd door de resoluties: 1024x768, 1280x800 en 1280x1024.

Afbeelding 5: Meest gebruikte resolutie, januari 2010. Cijfers in procenten. Bron: w3schools.com 37,4 22,5 15 8,1 5,23,8 1,7 1,3 1,1 0,9

Webbrowser

Resolutie

Eindverslag Argentum Ardon Hendrickx ₂₁ Tot slot hebben we een combinatie gemaakt van de driefactoren; Resolutie, webbrowser en

menustijlen. Door deze drie factoren te combineren was het mogelijk om een impressie te krijgen van de applicatie. Hieruit kon subjectief een oordeel worden geveld, welk menu het meest geschikt zou zijn voor de Argentum applicatie. Menustijlen welke we onder andere hebben getest zijn:

 Het Apple menu, waarin de knoppen zich onderin het scherm bevinden en vergroten als men over de knopen heen zweeft. Dit menu werd als mooi, maar onhandig beschouwd, voor een bedrijfsapplicatie welke in de browser draait.

 Een Cirkel menu, hierin bevinden de menucategorieën en knoppen zich in cirkels welke uitvouwen over het gehele scherm. Dit menu is niet geschikt voor een bedrijfsapplicatie omdat er simpelweg geen ruimte meer overblijft voor de applicatie.

 Een Accordeon menu, welke zich aan de zijkant van het scherm bevindt en waar de knoppen eveneens in categorieën worden verdeeld.

 Een Ribbon menu, welke de categorieën en knoppen aanpast aan de getoonde inhoud van het scherm.

Uiteindelijk zijn er een achttal menustijlen getest waarvan een combinatie van het Ribbon menu en het Accordeon menu als meest favoriet uit de bus kwamen. De rest van de menu’s waren vaak erg onpraktisch of hadden simpelweg geen subjectieve voorkeur. Voor het project is, op basis van dit onderzoek, de discussie over het Ribbon menu redelijk getemperd en is gekozen om als hoofdmenu het Accordeon menu te gebruiken en als context gerelateerd menu de befaamde Ribbon.

5.1.4 Onderzoek toolkits

Voor de techniek Silverlight zijn diverse toolkits beschikbaar. Toolkits bevatten kant-en-klare producten welke men kan gebruiken voor de applicatie. Hierbij kan men denken aan menustijlen, zoals een kant-en-klaar ribbon menu, of speciaal uitgevoerde ‘datagrids’ waarin men op een nette manier data kan weergeven. Omdat het natuurlijk onzin is om ‘het wiel nogmaals uit te vinden’ en bestaande functies zelf te gaan schrijven, heeft Datamex voorgesteld om te gaan kijken naar beschikbare toolkits en de voor- en/of nadelen van iedere toolkit. Hierop volgend is een onderzoek gestart welke zowel theoretisch als praktijk onderdelen bevat.

Voorafgaand aan het onderzoek hebben we een lijst met eisen opgesteld, of zoals men dit volgens de DSDM methode noemt, de MoSCoW lijst. Deze MoSCoW lijst bevat geprioriteerde functionele eisen voor het Argentum project. Tijdens diverse brainstorm sessies en vergaderingen zijn de eisen onderverdeeld in de vier: Must, Should, Could Won’t ofwel MoSCoW groepen. Het doel van het onderzoek naar de Silverlight toolkits was het naar voren brengen welke toolkit de meeste en beste uitwerkingen bevat voor de ‘Must-have’ functionaliteiten.

De eerste stap was onderzoeken welke toolkits er zoal beschikbaar zijn. Hieruit kwam een achttal toolkits van diverse makelij zoals; Telerik, Microsoft, Infragistics en ComponentOne.

Vervolgens onderzoeken we welke van de beschikbare toolkits de meeste ‘Must-have’

functionaliteiten bevat. Dit levert de volgende grafiek op waarbij verticaal het aantal ‘Must-have’ functionaliteiten staan (op een schaal van 26) en horizontaal de onderzochte toolkits.

Afbeelding 6: Toolkit onderzoek resultaten.

Zoals te zien, zit er standaard in de Silverlight 4 omgeving al erg veel functionaliteit. Daarbij komt het feit dat de MS Codeplex toolkit van Microsoft gratis te gebruiken is. Hierdoor kunnen nog veel meer functionaliteiten zonder extra kosten, daar overige toolkits veel geld kosten, uitgewerkt worden. Echter, de fabrikant kan natuurlijk wel beweren dat zijn toolkit de functionaliteiten bevat die wij zoeken, maar werken deze functionaliteiten in de praktijk ook net zo goed als dat de beweren? Om antwoord te krijgen op deze vraag hebben we een vervolg onderzoek ingesteld en hebben we enkele toolkits in de praktijk getest. De resultaten van het theoretische onderzoek leidde tot het besluit dat we niet elke toolkit in de praktijk zouden gaan testen maar alleen de toolkits met een degelijk resultaat, lees; negen of meer beschikbare functionele eisen.

15 9 15 4 10 6 6 12 13 0 5 10 15 20 25

Eindverslag Argentum Ardon Hendrickx ₂₃ Voor het praktijk testen van de toolkits hebben we de toolkits geïnstalleerd en de ‘Must-have’

functionele eisen geprobeerd in de praktijk uit te werken. Ik had bedacht dat het handig zou zijn om de eisen in een tabel te zetten en overzichtelijk weer te geven hoe de uitwerkingen van de eisen verlopen was. Functionele eisen welke middels de betreffende toolkit gemakkelijk uit te werken zijn kregen in de tabel een: . Eisen welke wat moeilijker uit te werken zijn kregen een: en eisen die helemaal niet of nauwelijks uit te werken zijn kregen een: Uiteindelijk kregen we een mooi overzicht welke terug is te vinden in de bijlagen.

Afbeelding 7: Voorbeeld toolkit praktijk onderzoek.

Na het theoretisch en praktijkonderzoek volgen de aanbeveling en conclusie. Omdat de meeste functionaliteiten al afgevangen worden door de standaard en gratis beschikbare toolkits hoeven maar enkele functionaliteiten echt onder de loep bekeken te worden. Deze functies zijn: Filtering, Ribbon menu en Excel export.

Als we deze functies filteren krijgen we onderstaande tabel:

Toolkit  Eisen ↓ Stan d aard M S C o d epl ex Te lerik Rad Co n tr o ls In frag is ti cs SyncF u sio n Esse n tial S tud io Co m p o n ent One 2a Filtering _- 18ab Ribbon _{- -} 22 Excel export _-

Afbeelding 8: Toolkit praktijk onderzoek resultaat.

Hieruit kan geconcludeerd worden dat de Infragistics toolkit de meeste ‘Must-have’ functionaliteiten bevat.

Tijdens een bijeenkomst zijn bovenstaande resultaten voorgelegd. Hierbij werd de vraag gesteld welke toolkit ik zelf zou kiezen en waarom ik deze toolkit zou kiezen. Ik heb gekozen voor de Telerik RadControl Toolkit, omdat, ondanks dat ik absoluut geen ervaring had met Silverlight en

achterliggende techniek, deze toolkit vele malen fijner werkte en de ondersteuning, handleidingen en fora veel actiever zijn dan bij de Infragistics toolkit. Het definitieve besluit is uiteindelijk genomen naar aanleiding van het onderzoek en de combinatie van eigen ervaringen. Er is hierbij besloten om verder te gaan met de Telerik Toolkit.

Achteraf is dit een prima keuze geweest, na het vertrek van Duncan is namelijk het belangrijkste puntje waarop de toolkits verschillen, Excel export, veranderd van ‘Must-have’ naar ‘Should-have.’

Eindverslag Argentum Ardon Hendrickx ₂₅

5.2 Functionele iteratie fase

De functionele iteratie beschrijft de tweede fase van het DSDM traject. Voor Argentum betekende dit het schrijven van het functioneel ontwerp en het technisch ontwerp.

5.2.1 Functioneel ontwerp

In de functionele iteratie fase is er begonnen met te achterhalen wat precies de functionele eisen zijn voor de applicatie. Het functioneel ontwerp bevat; zowel de functionele- als niet functionele eisen van de applicatie en scherm mock-ups welke de gebruikers interface grof weergeeft. Het functioneel ontwerp bevat normaliter ook Use case diagrammen, tijdens een bijeenkomst is echter naar voren gekomen dat ‘Use Cases’ voor een concept applicatie wat Datamex betreft niet nodig zijn. De beargumentering hierbij was dat we het gros van de functionaliteiten uit de huidige CRM applicatie zouden kunnen doornemen mocht iets niet helemaal duidelijk zijn en het zwaarte punt van de opdracht lag op het ontdekken van Silverlight mogelijkheden en niet op de specifieke werking van de functionele eisen.

Achteraf is het, niet gebruiken van ‘Use Cases’, op sommige momenten toch wel minder prettig uit de bus gekomen dan verwacht. Er waren momenten bij waarin niet helemaal duidelijk was wat nu precies de bedoeling was van de uit te voeren functionaliteit. Een voorbeeld; één van de

functionaliteiten betrof het ‘Cliënt side loggen’. Hierbij dacht ik dat het de bedoeling was dat fouten die in de applicatie voorkomen op de lokale gebruikers pc zouden moeten worden opgeslagen. Hier heb ik een tijdje aan gewerkt en toen ik de functie zeker voor 80% gereed had liep ik vast. De hulp ingeroepen van één van de medewerkers die al snel liet blijken dat ik dit punt waarschijnlijk niet helemaal goed begrepen had en dat niet alleen foutmelding gelogd zouden moeten worden maar eigenlijk AL de acties van de gebruiker. Zodat men in het geval van een foutmelding precies zou kunnen terug kijken wat de gebruiker had gedaan alvorens de foutmelding optrad. Deze verkeerde interpretatie van mij leverde uiteindelijk dus een erg vervelende situatie welke absoluut voorkomen had kunnen worden door het schrijven van Use Cases. Een wijze les voor een volgende opdracht.

5.2.1.1 Functionele- en niet-functionele eisen

Tijdens de oriënterende fase zijn al veel functionaliteiten uitgewerkt volgens de MoSCoW lijst. De functionele eisen van het Argentum project zijn onttrokken uit de huidige CRM applicatie van Datamex, genaamd PRO/CRM. Na het opstellen van een grove lijst hebben we tijdens een

vergadering deze lijst besproken en grof eisen toegevoegd en weggestreept. Langzaam maar zeker zijn we door middel van meerdere sessies gekomen tot een definitieve MoSCoW lijst (zover als mogelijk definitief binnen de DSDM methode) De MoSCoW lijst heeft eveneens als basis gediend voor het opstellen van de planning van het project en tijdens de wekelijkse sessie voor het bepalen van de opleveringen. De MoSCoW lijst is verwerkt als bijlage.

Zoals ook vermeld in de inleiding is halverwege het project Duncan dusdanig ziek geworden dat hij niet meer kon participeren aan de stageopdracht. Dit zou inhouden dat ik, Ardon, de gehele stage opdracht alleen zou moeten afronden. Vooraf is echter rekening gehouden met een applicatie welke door een tweetal personen geschreven zou worden. Ook het opstellen van de MoSCoW is uitgegaan

van een stageperiode met twee personen. Nu Duncan niet meer mee werkt is besloten om de MoSCoW lijst onder de loep te nemen en te kijken welke Must eisen toch als ‘Should-have’ of misschien zelfs als ‘Could-have’ gezet zouden kunnen worden. Het is immers niet mogelijk dat ik voor twee personen werk verricht. In een overleg met Datamex is besloten om onderstaande functionaliteiten in eerste instantie niet meer als ‘Must-have’ te rekenen maar als ‘Should-/Could-have’. Ook zijn er enkele eisen verzet van ‘Could-have’ naar ‘Must-have’ omdat deze tijdens het project toch als ‘belangrijk’ bestempeld worden. De volgende functionele eisen zijn gewijzigd:

 Encodering (beveiliging van de dataoverdracht) is verzet van ‘Must-have’ naar ‘Should-have’.

Er is tijdens de sessie aangegeven dat men wel gelooft dat encodering werkt binnen Silverlight. Dit hoeft dus niet als prioriteit bewezen te worden.

 Cliëntside loggen is verzet van ‘Could-have’ naar ‘Must-have’.

Tijdens het project is gebleken dat cliëntside loggen interessanter is om te bekijken dan serverside loggen. Met namen omdat Silverlight de mogelijkheid biedt om Out-Of-Browser te draaien (dus buiten de webbrowser om). Men wil weten hoe het loggen op dat moment dan afgevangen wordt.

 Serverside loggen is gewijzigd van ‘Must-have’ naar ‘Could-have’.

Zoals hierboven vermeld, is men meer geïnteresseerd in cliëntside loggen dan serverside loggen, dat is de reden dat deze twee onderdelen gewisseld zijn van prioriteit.

 SharePoint integratie is compleet gewijzigd van ‘Must-have’ naar ‘Could-have’.

Dit gedeelte is simpelweg vanwege tijdgebrek niet meer mogelijk om te integreren binnen de applicatie en valt na overleg buiten de scope (het bereik) van de opdracht.

 Excel export vanuit een Silverlight datagrid is gewijzigd van ‘Must-have’ naar ‘Could-have’.

De Outlook COM is hierbij leidend, indien de Outlook COM werkt gelooft men wel dat Excel export ook werkt.

 Outlook integratie onderdeel; E-mail sjabloon is verzet van ‘Must-have’ naar ‘Shoud-have’.

Men zou wel graag zien dat het klikken op een contactpersoon binnen de applicatie een koppeling met Outlook aanroept. Als dat werkt gelooft met ook wel dat het werken met Sjablonen te doen is.

 Word sjabloon is gewijzigd van ‘Must-have’ naar ‘Could-have’.

Om dezelfde reden als de Excel export is ook deze functionele eis verzet naar ‘Could-have’.  Koppeling van contactpersoon met activiteiten wordt compleet gewijzigd naar; Koppeling

van contactpersoon met talen.

De reden van deze wijziging is als volgt; Met wil graag weten wat er allemaal mogelijk is binnen Silverlight. In de applicatie hebben we al laten zien dat het mogelijk is om relaties te koppelen met activiteiten. Het zou dan uiteraard ook mogelijk zijn om een relatie te leggen tussen contactpersonen en activiteiten. Datamex heeft liever inzicht op een ‘veel-op-veel’ koppeling. simpel Om een veel op veel koppeling te creëren is besloten om een optie te maken waarbij een contactpersoon diverse talen toegewezen kan krijgen. Door een

contactpersoon te koppelen aan meerdere talen wordt een ‘veel-op-veel’ relatie gecreëerd. Ofwel, het koppelen van een contactpersoon aan een activiteit wordt wel geloofd, omdat dit ook wel werkt bij een relatie en een activiteit. Liever hebben ze dat de tijd gestoken wordt om uit te zoeken hoe een ‘veel-op-veel’ relatie werkt. Vandaar deze wijziging.

 Documenten [CRUD] is gewijzigd van ‘Must-have’ naar ‘Could-have’.

Waarbij CRUD staat voor de functionaliteiten: Create, Read, Update and Delete

(respectievelijk: Aanmaken, lezen, wijzigen en verwijderen). Dit onderdeel is verwant aan de SharePoint integratie en mede daarom ook gewijzigd.

 Vrije velden is ten slotte gewijzigd van ‘Must-have‘ naar ‘Should-have’.

Eindverslag Argentum Ardon Hendrickx ₂₇

5.2.2 Uitwerking User Interface

Voordat we aan de slag zijn gegaan met het maken van de applicatie moest er nagedacht worden over de User Interface (UI). Het was namelijk niet de bedoeling dat de applicatie een bijeen geraapt zooitje van functionele eisen zou worden, de applicatie zou bruikbaar moeten zijn als demonstratie richting klanten van Datamex. De Argentum applicatie moet daarom als bedrijfsapplicatie ogen en moet goed verzorgd overkomen.

5.2.2.1 Balsamiq

Datamex werkt met het programma Balsamiq voor het uitwerken van de User Interface (UI). In Balsamiq ontwerpt men de UI, print deze uit, en toont de schermen aan de klant. Deze maakt op zijn / haar beurt wat op en aanmerkingen en de ontwerpers gaan terug naar het Balsamiq tekenbord. Wanneer de klant akkoord is, worden de schermen opnieuw aangemaakt in de applicatie.

5.2.2.2 Blend SketchFlow

Voor Silverlight heeft Microsoft een programma, genaamd Blend 3.5 SketchFlow. Met SketchFlow zou het mogelijk zijn om de geschetste applicatie, met enkele simpele handelingen, om te zetten naar een werkende basis applicatie. Men schetst de UI in SketchFlow en converteert de schets naar een digitaal formaat welke de klant in de webbrowser kan openen. De klant geeft in de digitale schets zijn of haar opmerkingen en stuurt vervolgens het digitale document, inclusief opmerkingen en aantekening, terug. De opmerking kunnen direct worden omgezet, volgens Microsoft, naar schetsen en zo ontstaat een interactieve ‘ontwerp relatie’ met de klant. Wanneer de klant akkoord is met de UI kan de ontwerper de applicatie middels enkele simpele handelingen omzetten naar een werkende applicatie.

Klinkt allemaal erg interessant en zowel bij de stagiaires als bij Datamex was de interesse gewekt en is gekozen om, voor het Argentum project, gebruik te maken van SketchFlow boven Balsamiq. Door te kiezen voor SketchFlow ontstond voor Datamex meteen een mooie gelegenheid om te kijken of SketchFlow, met betrekking tot eventuele toekomstige Silverlight projecten, beter geschikt zou zijn dan Balsamiq. Ofwel, minder werk voor de stagiaire en een mooie gelegenheid voor Datamex om zich in te lezen in de nieuwe Blend Sketchflow applicatie van Microsoft.

5.2.2.3 SketchFlow in de realiteit

Het schetsen met de SketchFlow applicatie werkt erg prettig. Men kan vanuit de toolbox zowel standaard als speciale SketchFlow componenten slepen en positioneren. Het omzetten van de geschetste SketchFlow applicatie naar een écht werkende applicatie werkt echter totaal niet zoals gewenst. Zo mooi als het omschreven wordt zo slecht werkt het eigenlijk. Het becommentariëren van de applicatie door de klant via de digitale applicatie werkt best handig. Tijdens de door mij gegeven demo sessie van de applicatie heb ik hier een mooi voorbeeld van kunnen geven. Helaas is, zoals MS belooft, het omzetten van de, door de klant aangebrachte wijzigingen niet mogelijk. In de voorbeelden en demo’s die MS meegeeft, wordt gezegd dat de klant in de applicatie, met

bijvoorbeeld een marker, kan aantonen dat hij of zij nog een extra tekstvak zou willen op het formulier (of iets dergelijks). De ontwerper zou dan, na het ontvangen van de feedback, de, door de klant, getekende textbox kunnen aanklikken en omzetten naar een UI textbox. Dit heb ik meerdere malen geprobeerd en volgens de handleiding doorlopen maar kreeg ik met geen mogelijkheid voor elkaar.

Dan het omzetten van de getekende applicatie naar een werkende applicatie. Dit gaat ‘iets’ anders dan MS ons had beloofd. Vol goede moed ging ik met de getekende applicatie aan de slag,

handleiding erbij en omzetten maar. Deze handleiding bestaat echter al uit een elf tal stappen welke soms wel erg diep in de code doken. Na al de regels te hebben voltooid was het moment daar, de applicatie zou worden omgezet. Na even geduld te hebben, was daar onze applicatie. Niet dus. Wat er uitkwam was een applicatie met werkende functionaliteiten maar nog steeds in de stijl van SketchFlow. Tijdens een bijeenkomst is deze uitkomst getoond en is besloten af te stappen van het ontwerpen in SketchFlow daar deze, gezien de kosten, te weinig voordelen biedt ten opzichte van Balsamiq.

De schermen die we al hadden gemaakt in SketchFlow konden behouden blijven als mockups voor het project. Deze hoefden we niet alsnog te gaan schetsen in Balsamiq.

5.2.2.4 Uitwerking

De schermen bieden een basis voor de applicatie schermen, tijdens het ontwikkelen van de

applicatie is bij sommige schermen naar voren gekomen dat ze niet zo werken zoals gewenst. Tijdens diverse sessies is destijds besloten om schermen in dit soort gevallen naar eigen inzicht te wijzigen. De schermen van de applicatie zijn allen grotendeels identiek aan onderstaande afbeelding. Aan de linkerzijde het hoofdmenu en aan de bovenzijde het context gerelateerde ribbon menu. Het contentframe bevat in dit geval een overzicht van al de relaties en gekoppelde activiteiten per relatie. Hier is dus sprake van een master/detail verhouding. Dit houdt in dat het onderste datagrid wijzigt afhankelijk van de selectie in het bovenste grid. Verder zijn er ook schermen waarin men gegevens kan invoeren, wijzigen en eventueel een pop-up krijgt ter bevestiging van het verwijderen van een relatie of contactpersoon.

Eindverslag Argentum Ardon Hendrickx ₂₉ Afbeelding 10: Scherm uitwerking Argentum SketchFlow met SketchFlow componenten.

Tijdens diverse vergaderingen is de voorkeur met betrekking tot de schermen uitgesproken en zijn er diverse wijzigingen aangebracht. De uiteindelijke applicatie bevat in grote lijnen wel de schermen zoals afgesproken, hier en daar zijn wat kleine logische wijzigingen doorgevoerd.

5.2.3 Technisch ontwerp / Onderzoeksplan

Het schrijven van een technisch ontwerp voor een ‘Proof of Concept’ bleek in ons geval moeilijker dan gedacht. We liepen regelmatig tegen punten aan die gewenst zijn in een technisch ontwerp, maar die we, door onze gebrek aan kennis niet konden uitwerken. Hiertoe hebben we besloten om het technisch ontwerp te hernoemen naar een onderzoeksplan. Een technisch ontwerp omschrijft exact hoe de applicatie in elkaar steekt, op wat voor manier de applicatie is opgebouwd,

architectuur en welke technieken gebruikt zullen worden. Het onderzoeksplan, zoals wij het document hebben genoemd, bevat ook deze onderwerpen echter in onderzoeksvorm. Het onderzoeksplan zal de gewenste functionaliteiten bespreken en kijken naar mogelijke uitwerkingen, maar zal niet ingaan op de daadwerkelijk gekozen uitwerking. De daadwerkelijk gekozen uitwerking zal worden uitgewerkt in het eindverslag. Hierbij wordt gekeken naar het doel van de functionaliteit, de mogelijke uitwerkingen en de voorkeuren voor uitwerkingen gebaseerd op bestaande kennis binnen Datamex. De doelstellingen van het onderzoeksplan zijn: Het grafisch weergeven van de software architectuur, mogelijkheden tot uitwerken van functionaliteiten omschrijven, materiaal ter ondersteuning bij het programmeren van de applicatie. Het

enkele wijzigingen achteraf doorgevoerd en het document afgerond. Het onderzoeksplan is te vinden in de bijlagen.

5.2.3.1 De werking van Silverlight

Het onderzoeksplan omschrijft de werking van Silverlight en kijkt hierbij ook naar het verschil met ASP.NET. Hierbij komt naar voren dat ASP.NET serverside georiënteerd is. De cliënt pc doet een aanvraag naar een webpagina en op de server wordt vervolgens de gewenste pagina opgezocht en opgesteld. Al het rekenwerk gebeurt op de server. Silverlight daar en tegen werkt grotendeels op de cliënt pc. En dat is ook meteen de kracht achter Silverlight. Doordat Silverlight in principe alleen resources opvraagt (database informatie e.d.) wordt de server ontlast van zware berekeningen.

Afbeelding 11: De werking van Silverlight en ASP.NET

5.2.3.2 Opdeling van de applicatie

Silverlight maakt gebruik van verschillende ‘lagen’. Men vindt het grootste deel op de cliënt pc, maar ook een deel op de server, welke bijvoorbeeld zorgt door data communicatie met de database. We maken voor het Argentum project gebruik van WCF RIA Services. Dit is een belangrijke software verbinding tussen de cliënt business logica en de server business logica. Omdat Argentum een servicegeoriënteerde applicatie betreft bevindt een deel van deze business logica zich op afstand en niet direct in de bron van de applicatie welke op de cliënt draait. De Application Programming Interface (API) die voor deze communicatie gebruikt wordt is het Windows Communication Foundation (WCF) uit het .NET Framework. Specifiek maken we gebruik van de Rich Internet Application Services (RIA Services). Onderstaande afbeelding verduidelijkt het een en ander.

Eindverslag Argentum Ardon Hendrickx ₃₁ Afbeelding 12: Opdeling van de applicatie en toepassing van WCF RIA Services

De View, ook wel User Interface genoemd, bevat de schermen welke de interactie met de gebruiker afhandelt. De View is gekoppeld aan het ViewModel. Het ViewModel zorgt voor directe controle van bijvoorbeeld formulieren. Er wordt dus geen, tot minimaal, gebruik gemaakt van code-behind en alle logica voor de schermen wordt afgehandeld in het ViewModel. Het ViewModel verzorgt

communiceert met de DomainContext. De DomainContext verzorgt de wijzigingen in bijvoorbeeld de formulieren.

Voorbeeld:

Zodra een wijziging in een formulier o.i.d. plaatsvindt en men drukt in de View op ‘opslaan’ gaat het ViewModel controleren of de data correct is ingevoerd (bijvoorbeeld of het wachtwoord wel overeenkomt aan de gestelde eisen van minimaal 5 letters). Indien het ViewModel besluit dat de wijzigingen correct zijn wordt de gewijzigde data opgeslagen in de DomainContext. Pas als de DomainContext van het ViewModel de actie: SubmitChanges() toegewezen krijgt, worden de gegevens naar de Domainservice op de server verzonden. Welke op zijn beurt controleert of de data niet al bestaat in de database. Dit gebeurd via de DataAccesLayer (DAL) met de database. De DAL is in dit geval het Model. De database tabellen worden opgenomen in de DAL. Domain Services zijn WCF Services welke de business logica van de applicatie omvatten.

5.2.3.3 M-V-VM

Zoals ook te zien op afbeelding 12 is voor het Argentum project gebruikt gemaakt van het M-V-VM ontwerp patroon. M-V-VM staat voor Model-View-ViewModel, ontwikkeld door Microsoft en is grotendeels gebaseerd op het Model-View-Controller (MVC) ontwerp patroon.

De belangrijkste reden om voor het Argentum project voor M-V-VM te kiezen zijn:

 Vergemakkelijken van werk tussen ontwikkelaar en designer en er voor zorgen dat beide partijen onafhankelijk van elkaar aan de applicatie kunnen werken. Omdat we in het begin met twee studenten aan het werk waren leek het een goed idee dat Duncan zich zou bezighouden aan de techniek achter de applicatie terwijl ik mezelf ging bezighouden met de user interface. Achteraf konden we de applicatie zonder al teveel problemen samenvoegen.

 Bevorderen van de onderhoudbaarheid. Datamex wilde dat de applicatie na afloop gemakkelijk bijgehouden zou kunnen worden. M-V-VM sluit prima aan bij deze vraag doordat de applicatie wordt opgedeeld in diverse lagen. Onderhoud van de applicatie is hierdoor gemakkelijker te doen, men kan bijvoorbeeld nieuwe schermen schrijven tegen de

business logica zonder dat de gebruiker hier iets van merkt. Als de schermen gereed zijn kan de update worden doorgevoerd.

 Wens van Datamex om te kijken naar deze, voor hen, onbekende techniek.

De M in het M-V-VM staat voor: Model, dit is de Data Acces Layer welke de database content vertegenwoordigd. Dit werkt hetzelfde als bij het MVC patroon.

De V staat voor: View, zoals omschreven in de vorige paragraaf omvat de view de schermen welke de interactie met de gebruiker verzorgen, eveneens hetzelfde als bij het MVC patroon.

Ten slotte de VM, dit staat voor ViewModel. Om het ViewModel uit te leggen is eerst wat informatie nodig over het fenomeen ‘Databinding’. Databinding houdt in dat de View via de context verbonden is aan het Model. Delen van het Model worden ingeladen in de context. De context is een soort buffer welke een kopie van de database informatie opslaat. Vervolgens kunnen de context gegevens worden weergegeven in de View door middel van ‘one-way-databinding’. Andere delen van het Model kunnen mogelijk direct worden gewijzigd door te binden middels ‘two-way-databinding’. Bijvoorbeeld, een Boolean (true of false) in het Model kan gewijzigd worden door deze te binden aan een checkbox in de View. Als de gebruiker gegevens wijzigt in het formulier, wordt de gewijzigde data direct in de context gewijzigd. Zodra de gebruiker op ‘Gegevens opslaan’ klikt wordt de context naar de database geschreven.

In een echte applicatie is het echter niet altijd mogelijk om direct de View te binden aan het Model simpelweg omdat data eerst gecontroleerd moet worden alvorens deze in de database gestopt wordt. Hiervoor is het ViewModel in het leven geroepen.

Het ViewModel bevat operaties welke niet direct achter de View gehangen kunnen worden en ook niet, vanwege de complexiteit, in het Model passen. Ook bevat het ViewModel Commands.

Commands worden gebruikt door de View om te communiceren met het Model. Het ViewModel wordt ook gebruikt om ‘states’ van schermen in op te slaan. Denk hierbij aan; Indien een gebruiker is geselecteerd, pas dan mag de knop ‘printen’ klikbaar zijn. Onderstaande afbeelding geeft M-V-VM weer in vorm van een reguliere Silverlight applicatie.

Afbeelding 13: MVVM voorbeeld.

Mijn ervaring met het M-V-VM model is deels positief maar ook wel een beetje negatief. Doordat de code achter de View(V) in principe geheel verhuisd wordt naar het ViewModel (VM) oogt de code een stuk netter dan wanneer je de applicatie zou schrijven in bijvoorbeeld het MVC model of zonder model. Persoonlijk vind ik dat echt een pluspunt aan M-V-VM. Nadeel van deze techniek is wel dat je goed moet nadenken over de opdeling van de interface. Het is niet mogelijk om vanuit de VM een bestaand V component te wijzigen zonder een nieuwe instantie van de V aan te maken. Dit maakt

Eindverslag Argentum Ardon Hendrickx ₃₃ uitvoeren ben kan ik niet zeggen dat ik in het V de gerelateerde button uitgeschakeld wil hebben

totdat de berekening gereed is. Ook was het voor mij een flinke uitdaging om überhaupt het M-V-VM model in de applicatie onder de knie te krijgen.

5.2.3.4 Database diagram

Een MSSQL database wordt als basis genomen voor het Model van de applicatie. Het project dient een CRM applicatie na te bootsen en hiervoor zijn de volgende onderdelen vereist;

Contactpersonen, Relaties en Activiteiten. Onderstaand diagram geeft een impressie van de database. Contact PK ContactID Lastname Firstname Initials Prefix Gender Department FunctionName Phone Fax Email Note NotePush CreatedOn CreatedBy ModifiedOn ModifiedBy FK1 RelationshipID Language PK LanguageID Code Name Country Contact_Language_Link PK,FK1 LanguageID PK,FK2 ContactID Preferred Relationship PK RelationshipID Code Name Phone Fax Email Website NoMailings CreatedOn CreatedBy ModifiedOn ModifiedBy FK1 AddressID Address PK AddressID AddressLine1 AddressLine2 City Country CreatedOn CreatedBy ModifiedOn ModifiedBy Occupation PK OccupationID Name Subject Description CreatedOn CreatedBy ModifiedOn ModifiedBy FK1 ContactID FK2 RelationshipID ErrorLog PK EventID Priority Severity Title Timestamp MachineName AppDomainName ProcessID ProcessName ThreadName Win32ThreadId Message FormattedMessage LogId

Diagram 1: Argentum Database

Om inzicht te geven in het database diagram wordt hieronder elke tabel kort toegelicht. Specifieke toelichting per tabel is terug te vinden, in de bijlagen, in het onderzoeksplan.

Eindverslag Argentum Ardon Hendrickx ₃₅

Tabel Omschrijving

Contact De tabel Contact bevat al de contactpersonen opgenomen in de applicatie. Contactpersonen zijn directe contacten en werken bij een Relatie.

Occupation De benaming Occupation is gekozen omdat er in eerste instantie problemen waren met de naamgeving Activity. Deze bleek binnen .NET al gereserveerd te zijn. Achteraf was hier wel een work-around voor te verzinnen maar we hebben gekozen voor een andere benaming om het geheel wat overzichtelijker te houden. De vertaling van Occupation in dit zinsverband is dus niet ’bezigheid‘ maar activiteit.

Relationship De tabel Relationship vertegenwoordigt de relaties, ofwel de bedrijven.

Address De tabel Address vertegenwoordigt het adres van de relatie. Een relatie kan 1 of meerdere adressen hebben daar een postadres kan verschillen van een bezoekadres.

Language De (voorkeurs)taal van een contactpersoon. Deze tabel heeft een veel-op-veel relatie met Contact. Hiervoor is de koppeltabel Contact_Language_Link aangemaakt.

Contact_Language_Link Deze tabel verbindt de veel-op-veel relatie tussen Language en Contact.

ErrorLog ErrorLog bevat de foutmeldingen welke optreden in de applicatie. ErrorLog is niet gekoppeld aan een andere tabel uit de database. De ErrorLog tabel is gebaseerd op de Enterprise Library Logging tabel. Deze database is niet in één keer ontstaan hier zijn wel enkele vergaderingen en wijzigingen aan vooraf gegaan. De initiële database ging teveel uit van een definitieve versie van een CRM inclusief allerlei kleine details zoals rijbewijsgegevens en paspoortnummer van de contactpersoon. Ook ging de initiële database uit van een koppeling van documenten aan contacten en relaties. Deze optie is niet meer opgenomen in het project nadat Duncan definitief stopte met het project.

Deze definitieve database is vastgesteld met de gedachte dat de applicatie echt en alleen is bedoeld als voorbeeld voor mogelijkheden van Silverlight, en niet met om de specifieke werking van het CRM.

5.3 Design en Build iteratie fase

Nu de applicatie is opgedeeld en is opgezet volgens het M-V-VM model met ondersteuning van de WCF RIA Services is er een goede basis voor de Argentum applicatie. En kan gestart worden met de ‘Design en Build iteratie’ ofwel, de derde fase uit het DSDM traject.

De MoSCoW lijst heeft als basis gediend voor het ontwerpen en bouwen van de applicatie. Elk onderdeel is vaak eerst apart gebouwd en daarna toegevoegd aan de applicatie. Het hoofdstuk is ingedeeld volgens de Must eisen van de MoSCoW lijst (zie ook de bijlagen).

5.3.1 Menu structuur

Prioriteit: Must.

Onderbouwing prioriteit: De menustructuur dient als basis voor de applicatie. Een goede menustructuur is hierom erg belangrijk. Een must prioriteit lijkt hier op zijn plaats.

Vraagstelling: Is het mogelijk om in Silverlight de menustructuur aan te houden welke in het vooronderzoek (zie paragraaf 5.1.3) gekozen is.

Uitwerking: Als menustructuur is gekozen voor een hoofdmenu en een context gerelateerd ribbon. De applicatie is in de basis opgedeeld in een ‘frameset’, welke 3 ‘frames’ bevat. Het topframe voor de ribbon, het frame voor het accordeon aan de linkerzijde en het hoofdframe voor de inhoud van applicatie. Het accordeon en de ribbon zijn beide onderdelen van de toolkit van Telerik (zie

paragraaf 5.1.4) Deze beide onderdelen konden, na opdeling van het hoofd grid, in de eigen frames geplaatst worden.

Om de ribbon inhoudsafhankelijk te maken dient deze te communiceren middels het ViewModel (VM) met het contentframe. Het contentframe geeft als het ware aan de ribbon door welke pagina zojuist geopend is, waardoor de ribbon de gerelateerde knoppen kan weergeven en overige knoppen kan ‘verstoppen’. Verder zijn de knoppen van de ribbon door middel van ‘binding’

verbonden aan de Commands in het VM. In het VM wordt aangegeven of het ‘Command überhaupt uitgevoerd mag worden.

Bijvoorbeeld: Een knop: ‘gebruiker verwijderen’ mag en kan alleen ingedrukt worden indien een gebruiker geselecteerd is. Indien er geen gebruiker geselecteerd is dan wordt het

‘canExecuteCommand’ op ‘false’ gezet. Hiermee wordt het commando op inactief gezet en is het ook niet mogelijk om de knop in te drukken.

Onderstaande afbeelding geeft aan de linkerzijde een stukje Ribbon weer van het relatiescherm waarbij er geen relatie geselecteerd is. De rechterzijde van de afbeelding geeft hetzelfde stukje Ribbon weer waarbij er wel een relatie geselecteerd is.

Eindverslag Argentum Ardon Hendrickx ₃₇ Afbeelding 14: Inhoudsafhankelijke ribbon.

Links is er geen relatie geselecteerd. Rechts is er wel een relatie geselecteerd en worden de knoppen geactiveerd.

Het hoofdmenu bestaat uit een accordeon welke uitvouwt wanneer een selectie wordt gemaakt. Een drietal hoofdopties is beschikbaar: Relatie, Contactpersoon en Instellingen. Wanneer men klik op één van deze drie buttons, zal het accordeon uitvouwen en submenu onderdelen tonen. Tegelijkertijd wordt de gerelateerde hoofdpagina getoond in het ‘contentframe’. Het accordeon is een onderdeel van de Telerik toolkit (zie paragraaf 5.1.4).

Resultaat: Onderstaande afbeelding toont het resultaat van de menustructuur en de frameset opdeling.

Afbeelding 16: Argentum frameset indeling

Conclusie: Het resultaat toont aan dat het mogelijk is om de gewenste menustructuur toe te passen binnen een Silverlight applicatie.

5.3.2 Multi-Language

Prioriteit: Must.

Onderbouwing prioriteit: Er was in het begin nog onduidelijkheid over het feit of meertaligheid uitgezocht zou moeten worden. Omdat via diverse demo’s op internet al wel duidelijk was dat de Afbeelding 15: Accordeon