nlpmeijstage.files.wordpress.com · Web viewOok is er een opsplitsing in afdelingen (zie bijlage...

Fancy RorixPlan van Aanpak

Document: Plan van AanpakAuteur: Nick van der MeijDatum: 11-9-2014Plaats: Rosmalen

Versie: 2.1

Opdrachtnemer: Nick van der MeijOpdrachtgever: Osman YucekayaStagebegeleider: Osman Yucekaya

Plan van Aanpak – Pagina 1

InhoudVersiebeheer..........................................................................................................................................3

Achtergronden.......................................................................................................................................4

Rorix B.V.............................................................................................................................................4

Afdeling IT..........................................................................................................................................4

Mijn plaats bij Rorix............................................................................................................................4

Afspraken en overeenkomsten..........................................................................................................4

Opdrachtnemer..................................................................................................................................5

De stageopdracht...................................................................................................................................6

Doelstelling stage...............................................................................................................................6

Formulering opdracht.........................................................................................................................6

Probleemstelling................................................................................................................................6

Eisen en Requirementsanalyse...........................................................................................................6

Succesfactoren...................................................................................................................................7

Projectbereik..........................................................................................................................................8

Producten...............................................................................................................................................8

Plan van aanpak.................................................................................................................................8

Onderzoekverslag naar frameworks...................................................................................................8

Implementatie van het nieuwe systeem............................................................................................8

Risico’s....................................................................................................................................................8

Kosten en baten.....................................................................................................................................8

Kosten................................................................................................................................................8

Baten..................................................................................................................................................8

Planning..................................................................................................................................................9

Betrokkenen...........................................................................................................................................9

Verklarende woordenlijst.....................................................................................................................10

Bijlage...................................................................................................................................................11

Bijlage 1 – Rorix B.V..........................................................................................................................11

Bijlage 2 – Bedrijf structuur..............................................................................................................11

Bijlage 3 – Afdeling structuur...........................................................................................................11

Bijlage 4 - Requirementsanalyse.......................................................................................................12

Bijlage 5 – Globale planning.............................................................................................................25


VersiebeheerVersie Laatst aangepast0.1 2-9-20140.2 4-9-20141.0 5-9-20141.1 8-9-20142.0 10-9-20142.1 11-9-2014


AchtergrondenRorix B.V.Rorix B.V. is een overkoepeling voor een aantal dochterbedrijven, namelijk Relinks, Reworks en Redos BVBA. Echter deze dochterbedrijven werken nauw samen en de splitsing is eigenlijk alleen voor juridische redenen. (zie bijlage 1)

Relinks is verantwoordelijk voor alles wat met IT te maken heeft. Hier vallen onder andere de website en het IT personeel onder. Reworks houdt zich bezig met al het vastgoed en het andere, Nederlandse, personeel. Redos is opgericht voor België en is daar verantwoordelijk voor.

Ook is er een opsplitsing in afdelingen (zie bijlage 2). Helemaal bovenaan is de directie. Zij zijn het hoofd van het bedrijf en maken de belangrijke beslissingen. Je hebt de afdeling IT die zich bezig houd met werkzaamheden rondom de websites. De verkoopafdeling houdt zich bezig met de verkoop, zowel telefonisch of in de showroom, en bestaat uit 3 “subafdelingen” namelijk Verkoop Rosmalen, Amsterdam en België. Om bestellingen te verwerken is er een Magazijn/Logistiek afdeling die zorgen dat de bestellingen de deur uit gaan en er is een afdeling Financiën om te zorgen dat alles rondom financiën geregeld wordt. Als laatst de afdeling Marketing die zich bezig houdt met dingen zoals aanbiedingen, reclame en grafische vormgeving.

Afdeling ITDe afdeling IT bestaat uit 3 “lagen” (zie bijlage 3). Allereerst heb je de IT Manager, Osman Yucekaya. Daaronder vallen alle andere IT medewerkers en stagiaires. De taak van de afdeling IT is de website onderhouden en uitbreiden. Door de informele, maar wel professionele werksfeer wordt er goed samen gewerkt.

Osman Yucekaya is ook mijn stagebegeleider en dus mijn eerste aanspreekpunt als ik vragen heb. Ook is hij degene waar ik mee kan bespreken of ik in de goede richting zit met betrekking tot mijn opdracht. Sommige dingen zijn beter om te plannen en rustig voor te gaan zitten, zoals interviews met medewerkers of het doornemen van (bijvoorbeeld) het Plan van Aanpak.

De websites zijn gemaakt in een zelf gemaakt PHP MVC Framework, wat over de jaren heen erg uitgebreid is geworden. Er wordt ook gebruik gemaakt van meerdere talen en technieken, maar de talen en technieken die voor mij van belang zijn, zijn de volgende: SQL, HTML, CSS, PHP, Javascript, Smarty en AJAX.

Mijn plaats bij RorixMijn plek bij Rorix is op de afdeling IT als IT Stagiaire. Zoals al eerder genoemd is Osman Yucekaya mijn stagebegeleider en zal me begeleiden met zaken rondom mijn stageopdracht. Door mijn stageopdracht zal ik ook te maken krijgen met de afdeling marketing, aangezien hun de voornaamste eindgebruikers van het product zijn.

Afspraken en overeenkomstenEr zijn altijd evaluatiemomenten, soms geregeld vanuit school en soms geregeld vanuit de stagebegeleider. Voor vragen kan ik terecht bij mijn stagebegeleider Osman Yucekaya en voor vragen met betrekking tot school kan ik terecht bij mijn stagedocent, Ron van Wolffelaar.

De stagedocent vanuit de opleiding is eindverantwoordelijk voor de beoordeling en administratieve afhandeling.


OpdrachtnemerDe opdrachtnemer ben ik, Nick van der Meij, 3de jaars student bij Avans Hogeschool te ’s Hertogenbosch.


De stageopdrachtDoelstelling stageHet onderzoeken naar betere manieren om modals (pop-up schermen met functionaliteit binnen een website) te maken en het uit het onderzoek gekozen modal implementeren in het huidige systeem.

Formulering opdrachtOm te beginnen moet ik onderzoek doen naar verschillende javascript frameworks. Hierbij moet ik verschillende frameworks met elkaar vergelijken en een keuze maken welke het beste past bij de architectuur. Daarna moet ik deze keuze presenteren.

Daarna moet ik het gekozen framework implementeren in het systeem, zodat er een consistentie bestaat tussen welke framework er gebruikt wordt. Ook is één van de doelen om hiermee de gebruiksvriendelijkheid van de business applicatie te verhogen. Hiervoor moet ik dus ook met de gebruikers (medewerkers van Rorix) overleggen.

Probleemstelling De huidige technologie is verouderd De huidige schermen zijn te inconsistent De huidige schermen zijn niet gebruiksvriendelijk De modals zijn tijdrovend om te maken

Eisen en RequirementsanalyseEen volledige requirementsanalyse is te vinden in bijlage 4.

Hier staan alleen de meest noodzakelijke eisen:

De modals moeten consistent zijn. Het is de bedoeling dat de functionaliteit van de schermen niet wordt aangetast, maar dat

vooral de meeste van de problemen worden opgelost. Voordat het nieuwe systeem geïmplementeerd wordt moet het systeem eerst goed getest

worden of alles nog werkt naar behoren. Het gekozen framework moet overweg kunnen met AJAX, waardoor het systeem wat

dynamischer en fijner in omgang gebruikt kan worden. De gebruiker moet goed kunnen werken in de nieuwe schermen. Het moet

gebruiksvriendelijk zijn.


SuccesfactorenPlan van aanpak

Het plan is logisch opgebouwd. Het plan is in ABN geschreven en heeft een verzorgde lay-out. Het plan is consistent. Het probleem wordt van meerdere kanten bekeken. Het plan wordt binnen de deadline geleverd.

Onderzoek naar frameworks

Het onderzoek wordt binnen de deadline geleverd. Het onderzoek is in ABN geschreven en heeft een verzorgde lay-out. Het onderzoek bekijkt meerdere opties. Het onderzoek is uitgebreid genoeg om een goede keuze te maken tussen de gevonden

technologieën. Het onderzoek is voorzien van een logische en professionele opbouw. Het onderzoek is een aantal fases gemaakt, met daartussen reviews. Er moet consistentie komen in de website, waardoor het voor de mensen die met de admin

(de naam van het CMS) werken (zowel voor de programmeurs als de medewerkers van verkoop en marketing) een stuk makkelijker wordt om met de website te werken.

Tijdens het onderzoek wordt er regelmatig overlegt met de eindgebruikers wat zij van de verschillende frameworks vinden.

Implementatie van het nieuwe systeem

De implementatie wordt binnen de deadline geleverd. De implementatie voldoet aan de codestandaard opgesteld door de opdrachtgever. De implementatie is voorzien van commentaar. De implementatie is getest en gereviewt voordat hij wordt gereleased. De implementatie voldoet aan de eisen die gesteld zijn in dit plan. De implementatie gaat in 2 stappen, die voorzien zijn van reviewmomenten, interviews en

tests De implementatie past in de huidige programmeerstructuur

Communicatie met de opdrachtgever

Er zijn duidelijke afspraken met de opdrachtgever. Feedback naar de stagiaire wordt positief ontvangen. Er is gemakkelijk contact met de opdrachtgever.

De stage wordt beoordeeld d.m.v. de volgende criteria

De bedrijfsbegeleider stelt conform de hiervoor geformuleerde richtlijnen een beoordelingsadvies op. Ook de stagedocent en de stagiair formuleren een beoordelingsadvies.

De stagedocent stelt de eindbeoordeling op conform de richtlijnen genoemd in de stageregeling.

Alle evaluaties en beoordelingen worden met de stagiair besproken. De eindbeoordeling van de stage berust bij de examencommissie van de opleiding.


ProjectbereikHet bereik van dit project is het onderzoek en implementatie van het nieuwe systeem. Het onderzoek zal gaan over nieuwe manieren om modals te maken en om ze zo efficiënt mogelijk te maken met betrekking tot de eisen van de opdrachtgever. Daarnaast zal de beste manier geïmplementeerd worden in het systeem. De implementatie zal als bereik de modals van de producten bedragen in de admin. Indien dit succesvol is en er is nog tijd over, kan er nog gekeken worden naar andere delen waar de modals toe zijn aan vervanging.

ProductenPlan van aanpakDit document wordt opgeleverd aan de opdrachtgever. Hierin staan duidelijke overeenkomsten over wat er gedaan moet worden en wie de verantwoordelijke zijn.

Onderzoekverslag naar frameworksOm te beginnen is er een onderzoek naar de verschillende frameworks die op de markt zijn. In dit onderzoek wordt gekeken wat de plus en minpunten zijn van de gevonden frameworks en gaan we uiteindelijk een keuze maken wat het meest aansluitende framework is om te gebruiken.

Implementatie van het nieuwe systeemDe stagiaire bouwt de implementatie van het gekozen systeem naar aanleiding van het onderzoeksverslag naar frameworks. Wanneer deze implementatie is getest en goedgekeurd door de opdrachtgever en de afdeling Marketing, zal deze worden geïmplementeerd in het huidige systeem.

Risico’s De leercurve van het uit het onderzoek gekomen systeem is erg steil Het onderzoek kan uitlopen, wat als gevolg heeft dat er minder tijd is voor de implementatie De opdrachtnemer heeft niet genoeg kennis van AJAX om het gekozen systeem te

implementeren De opdrachtnemer heeft niet genoeg kennis van Javascript om de gewenste functionaliteiten

toe te passen in de website

Kosten en batenKostenDe kosten van dit project zijn alleen de eventuele aanschafkosten van het nieuwe framework, mits deze door een commercieel bedrijf is gemaakt en een licentie heeft.

BatenDe baten bij dit project zijn de volgende dingen:

Minder manuren om nieuwe schermen te maken Werken met het systeem gaat soepeler en is minder tijdrovend


PlanningEen uitgebreide planning kan worden gevonden in Bijlage 5

BetrokkenenStagiaireNaam : Nick van der MeijTelefoonnummer : 0633136241E-mail : [email protected]

: [email protected]

Opdrachtgever/Stagebegeleider Naam : Osman YucekayaTelefoonnummer : 0735223008 E-mail : [email protected]

StagedocentNaam : Ron van WolffelaarTelefoonnummer :E-mail : [email protected]


mailto:[email protected]




Verklarende woordenlijstWoord UitlegMVC Model View Controller (MVC afgekort) is een

software design pattern om die frontend en backend van een website gescheiden te houden

Framework Een softwareframework is een geheel van softwarecomponenten dat gebruikt kan worden bij het programmeren van applicaties

Modals Dit is de naam die de popup windows hebben in de webapplicatie. Als voornaamste reden is deze naam ontstaan omdat je hierdoor makkelijk op google kunt zoeken naar informatie voor deze schermen, in plaats van informatie te krijgen over Windows OS

Open source Software source code die gratis gebruikt mag worden bij het bouwen van applicaties

Reviews Momenten waar het desbetreffende product wordt nagekeken door iemand die er verstand van heeft. Na deze review zijn er open aanmerkingen (feedback) die verwerkt kan worden

Admin Als we over admin praten wordt hiermee de CMS (Content Management System) van Rorix B.V. bedoelt. Dit is het systeem waarmee de medewerkers van Rorix B.V. bijvoorbeeld de producten op de website beheren.


BijlageBijlage 1 – Rorix B.V.

Bijlage 2 – Bedrijf structuur

Bijlage 3 – Afdeling structuur


Bijlage 4 - Requirementsanalyse

Fancy RorixRequirementsanalyse

Document: RequirementsanalyseAuteur: Nick van der MeijDatum: 8-9-2014Plaats: Rosmalen

Versie: 1.0

Opdrachtnemer: Nick van der MeijOpdrachtgever: Osman YucekayaStagebegeleider: Osman Yucekaya


VersiebeheerVersienummer Datum van release0.1 8-9-20140.2 8-9-20141.0 9-9-2014


InleidingIn dit document zijn de requirements opgesteld voor het project met betrekking tot de vervanging van de modals. Informatie over dit project kunt u terug vinden in het Plan van Aanpak.

Voor het opstellen van de requirements zijn er 3 stappen ondernomen, namelijk:

Het vastleggen van de belanghebbenden van het project (hierna te noemen “stakeholders”). Het inventariseren van requirements door middel van interviews met stakeholders De gevonden requirements prioriteren in overleg met de stakeholders.

De requirements worden geprioriteerd door middel van de MoSCoW methode (“Must haves”, “Should haves”, “Could haves” en “Won’t haves”).


Stakeholder analyseHieronder worden de stakeholders en hun rol in het project beschreven.

Stakeholder Voordelen bij project

Bijdrage / opoffering

Invloeden

Afdeling IT Minder tijd kwijt aan onderhoud en uitbreiden van functionaliteiten

Tijd Opstellen requirements.Testen van geïmplementeerde functionaliteiten.

IT manager Minder tijd kwijt aan onderhoud en uitbreiden van functionaliteiten

Tijd Opstellen requirements.Testen van geïmplementeerde functionaliteiten.Verantwoordelijk voor het inlichten van IT medewerkers.

Afdeling Marketing

Minder tijd kwijt aan onderhoud van de productpagina

Tijd Opstellen requirements.Testen van geïmplementeerde functionaliteiten.

Marketing manager

Minder tijd kwijt aan onderhoud van de productpagina

Tijd Opstellen requirements.Testen van geïmplementeerde functionaliteiten.Verantwoordelijk voor het inlichten van marketing medewerkers.

Directie Minder personeelskosten

Tijd en geld Bepaling welk framework wordt gekocht.


Requirement interviewsHet doel van de interviews is om achter de behoeftes en eisen van de stakeholders te komen.

Voor het opstellen van de requirements worden interviews gehouden met de stakeholders. Deze interviews worden eerst geplant met de desbetreffende stakeholder. Tijdens de interviews wordt er door het systeem gelopen om zo een duidelijk beeld te krijgen van wat er veranderd moet worden.

Voorbeelden van vragen die tijdens het interview gesteld worden zijn:

Met welke functionaliteiten in het huidige systeem ben je tevreden en helpen je op eenpositieve manier in het uitvoeren van je taak?

Met welke functionaliteiten in het huidige systeem ben je ontevreden en belemmeren je inhet uitvoeren van je taak?

Welke veranderingen zou je zelf willen doorvoeren aan de functionaliteiten waar jeontevreden over bent zodat deze je op een positieve manier kunnen ondersteunen bij hetuitvoeren van je taken?

Welke functionaliteiten mis je in het huidige systeem en waarom zou je deze in het nieuwesysteem geïmplementeerd willen zien?


MoSCoW methodeDe MoSCoW methode is een veel gebruikte techniek in software ontwikkeling om de eisen aan hetresultaat van een project te prioriteren. Omdat projecten doorgaans een beperkt budget hebben engebonden zijn aan een tijdsbestek, moeten er prioriteiten gesteld worden aan de vaak velerequirements die de verschillende stakeholders hebben. Met MoSCoW is een requirement onder teverdelen in de volgende categorieën:

Must (M)Definieert een requirement die aanwezig MOET zijn in het uiteindelijk op te leveren resultaat. Eenrequirement van dit type is kritiek voor het slagen van een project.

Should (S)Dit zijn requirements van hoge prioriteit en zijn ook kritiek voor het slagen van een project. EenShould requirement is minder tijd kritisch als een Must requirement en zou op een later tijdstipmogen worden opgeleverd. Indien nodig kunnen er workarounds worden bedacht om alsnog aan derequirement te voldoen.

Could (C)Dit zijn gewenste requirements (ook “nice to have” genoemd). Het welslagen van een project is nietafhankelijk van deze requirements. Indien het budget en tijdsbestek het toelaat kan er voor gekozenworden de requirement alsnog te implementeren.

Won’t (W)Een requirement in deze categorie is iets wat stakeholders graag in de toekomst geïmplementeerdzouden willen zien. Een dergelijke requirement zal dus uitgesteld worden naar een volgende versie.Hieronder volgt per onderdeel van het systeem de inventarisatie en prioritering van requirements in overleg met de verschillende stakeholders.


Legenda ID code{Soort requirement}-{Groepering requirement}-{Requirementnummer}

Soorten requirements:

RF – Functionele requirement RN – Niet functionele requirement RH – Hoofdrequirement die onderverdeeld wordt in subrequirements (functionele of niet

functionele requirements)

Requirements over gedrag van de modals (GM)Na het uitvoeren van de interviews met de verschillende stakeholders zijn de onderstaanderequirements geformuleerd met betrekking tot het gedrag en uiterlijk modals.

RequirementsID RF-GM-1Titel ConsistentieOmschrijving Het uiterlijk van de modals moet consistent zijn.

ID RF-GM-3Titel Meerdere modalsOmschrijving Er kunnen meerdere modals tegelijkertijd worden geopend.

ID RF-GM-4Titel MinimaliserenOmschrijving Een openstaand modal kan worden geminimaliseerd.

ID RF-GM-5Titel ResizeOmschrijving De openstaande modals kunnen worden geresized naar de wens van de

gebruiker.

ID RF-GM-6Titel UiterlijkOmschrijving Het uiterlijk van de modal moet er verzorgt en duidelijk uit zien.

ID RF-GM-7Titel GebruiksvriendelijkOmschrijving De modals moeten gebruiksvriendelijk zijn. Dit betekent dat de eindgebruiker

zo min mogelijk irritatie mag hebben van bijvoorbeeld haperingen in de schermen wanneer je ze beweegt.


MoSCoW breakdown sheet

ID Titel M S C WBehaald (X/V) Opmerking

RF-GM-1 Consistentie X X

RF-GM-2 Framework X Eruit gehaald i.v.m. duplicatie requirement

RF-GM-3 Meerdere modals X X RF-GM-4 Minimaliseren X X RF-GM-5 Resize X X RF-GM-6 Uiterlijk X X RF-GM-7 Gebruiksvriendelijk X X


Requirements over functionaliteit van de modals (FM)Hier zijn de requirements opgesteld over de functionaliteiten binnen de modals.

RequirementsID RF-FM-1Titel ConsistentieOmschrijving De innerlijke lay-out van de modals moet consistent zijn.

ID RF-FM-2Titel DynamischOmschrijving De functionaliteiten binnen de modals zijn voorzien van AJAX functionaliteiten.

ID RF-FM-3Titel Lay-outOmschrijving De modals zijn voorzien van een aparte css library

ID RH-FM-4.0Titel FunctionaliteitenOmschrijving De huidige functionaliteiten blijven bestaan.

ID RF-FM-4.1Titel Meerdere productenOmschrijving Er is een mogelijkheid om meerdere producten tegelijk aan te passen

ID RH-FM-5.0Titel GebruiksvriendelijkheidOmschrijving Bij de functionaliteiten is gedacht aan de gebruiksvriendelijkheid

ID RF-FM-5.1Titel AJAXOmschrijving Met behulp van AJAX wordt ervoor gezorgd dat wijzigingen gelijk worden

opgeslagen

ID RF-FM-5.2Titel Drag and DropOmschrijving Drag and Drop functionaliteit wordt gebruikt waar dit de

gebruiksvriendelijkheid verhoogd.

ID RF-FM-5.3Titel ScrollpreventieOmschrijving De modals zijn voorzien van een manier om zo min mogelijk te hoeven scrollen.


ID RF-FM-5.4Titel FeedbackOmschrijving Er is een mogelijkheid om naar de gebruiker toe feedback te geven

ID RF-FM-5.5Titel Snel werkenOmschrijving De gebruiker wordt mogelijkheden geboden om technieken te gebruiken wat

het werk sneller kan maken

MoSCoW Requirements Breakdown


RF-FM-1 Consistentie X X RF-FM-2 Dynamisch X X RF-FM-3 Lay-out X X RH-FM-4.0 Functionaliteiten X RF-FM-4.1 Meerdere producten X X RH-FM-5.0 Gebruiksvriendelijkheid X RF-FM-5.1 AJAX X X RF-FM-5.2 Drag and Drop X X RF-FM-5.3 Scrollpreventie X X RF-FM-5.4 Feedback X X RF-FM-5.5 Snel werken X X


Requirements met betrekking tot de code (C)Hier zijn de requirements opgesteld die te maken hebben met de backend van het systeem

RequirementsID RH-C-1Titel Codestandaard en techniekenOmschrijving De code is opgebouwd aan de hand van de codestandaard en de huidige

gebruikte technieken.

ID RN-C-1.1Titel CommentaarOmschrijving De code is voorzien van duidelijk en nuttig commentaar

ID RN-C-1.2Titel SMARTYOmschrijving Voor een makkelijk opmaak van de lay-out wordt SMARTY gebruikt

ID RN-C-1.3Titel AJAXOmschrijving Voor een dynamisch effecten die te maken hebben met het database wordt

AJAX gebruikt.

ID RN-C-1.4Titel CSSOmschrijving Voor de grafische schil wordt CSS gebruikt

ID RN-C-1.5Titel HTMLOmschrijving Voor de opbouw van de schermen wordt HTML gebruikt

ID RN-C-1.6Titel JavascriptOmschrijving Voor dynamische effecten die niet met het database te maken hebben wordt

javascript gebruikt.

ID RN-C-1.7Titel PHPOmschrijving Voor backend programming wordt PHP gebruikt

ID RF-C-2Titel StructuurOmschrijving De implementatie past bij de huidige structuur van de website


ID RF-C-3Titel Opbouw modalsOmschrijving De modals kunnen worden gebouwd met relatief weinig code.

ID RF-C-4Titel FrameworkOmschrijving Het gekozen framework moet nog actief worden ontwikkeld.

ID RF-C-5Titel API DocumentatieOmschrijving Het gekozen framework moet een uitgebreide API hebben

ID RF-C-6Titel Gebruikers communityOmschrijving Er moet een grote gebruikers community zijn waardoor er dus veel hulp te

vinden is

ID RF-C-7Titel Veel widgetsOmschrijving Het gekozen framework moet genoeg widgets bevatten om het admin deel

geheel om te bouwen


MoSCoW Requirements Breakdown


RH-C-1.0 Codestandaard en technieken X RN-C-1.1 Commentaar X X

RN-C-1.2 SMARTY X X Afhankelijk van het gekozen framework

RN-C-1.3 AJAX X X

RN-C-1.4 CSS X X Afhankelijk van het gekozen

framework

RN-C-1.5 HTML X X Afhankelijk van het gekozen framework

RN-C-1.6 Javascript X X RN-C-1.7 PHP X X RF-C-2 Structuur X X RF-C-3 Opbouw modals X X RF-C-4 Framework X X RF-C-5 API Documentatie X X RF-C-6 Gebruikers community X X RF-C-7 Veel widgets X X


Bijlage 5 – Globale planningPeriode Taak Beschrijving taak Extra informatie

1-sep

Plan van aanpak

In dit deel ga ik een plan van aanpak maken om te bepalen wat onder andere de probleemstelling is en wat er precies gedaan moet worden.

12-sep15-sep

Onderzoek modals

Deze weken zijn voor het onderzoek naar modals. In dit onderzoek ga ik me verdiepen in de verschillende frameworks die modal support hebben en kijken welke het beste bij het systeem past.

24-sep27-sep

Verdieping framework

Nadat er een framework is gekozen, ga ik me de eerste 4 weken verdiepen in het framework. Ik ga kijken wat het framework allemaal kan en experimenteren om te kijken hoe het allemaal in elkaar zit.

24-okt27-dec

Implementatie Deel 1

Bij dit eerste deel van de implementatie ga ik me focussen op het hoofdscherm, wijzig afbeelding, wijzig attributen, stock data en inkoopalternatieven.

Bij de implementatie zijn reviews met de eindgebruiker inbegrepen. Als in de praktijk blijkt dat de implementatie sneller of langzamer gaat, wordt de planning aangepast.

28-nov1-dec - 5-dec Testen

8-dec

Implementatie Deel 2

Dit tweede deel ga ik de modals implementeren in het wijzig categorieën, wijzig toebehoren, toon log en alternatieve producten deel.

5-jan11-jan - 16-

jan Testen 19-jan

Afronding

Deze laatste weken zijn om de laatste dingetjes te doen zoals bug fixes en afronding van de stage. Eventueel kunnen deze weken ook gebruikt worden als andere onderdelen uitlopen.

30-jan


nlpmeijstage.files.wordpress.com · Web viewOok is er een opsplitsing in afdelingen (zie bijlage...

Documents

Transcript of nlpmeijstage.files.wordpress.com · Web viewOok is er een opsplitsing in afdelingen (zie bijlage...