Planning applicatie Voor Tango

Planning applicatie Voor Tango

Frank Kaptein Bert Lobbezoo

Voorwoord Het verslag dat voor u ligt is het resultaat van ons bacheloreindproject wat uitgevoerd is als afsluiting van de bachelorfase van de studie Technische Informatica aan de Technische Universiteit te Delft. De opdracht voor ons bacheloreindproject was het ontwikkelen van een planningapplicatie waarbij niet het plannen, maar het proces van het plannen centraal stond. De opdracht kwam vanuit het bedrijf Tango. In de praktijk was Wim Antonissen de opdrachtgever, en daarnaast vervulde hij ook de klantrol. Dit verslag is bedoeld om de begeleiders van dit project te informeren. Aan de hand van dit verslag kunnen zij, de problemen, oplossingen en resultaten van ons eindproject toetsen en beoordelen. In het verslag en de bijlagen zijn de onderbouwingen uitgewerkt inclusief een toelichting van de gemaakte keuzes. . We willen graag onze opdrachtgever bedanken voor de ondersteuning en daadwerkelijke hulp die we in het hele traject hebben gekregen. Alleen door zijn meedenken, feedback en tips is het gelukt om tot dit eindresultaat te komen. Maar niet alleen in het project is hij een doorslaggevende factor geweest, maar ook op het persoonlijke vlak heeft hij ons gecoacht en geholpen. Zonder zijn bijdrage zouden wij nooit zoveel geleerd hebben van dit project. Om concreet te zijn: pas nu begrijpen we waarom object-geörienteerd programmeren een van de beste, misschien wel de beste, manier van programmeren is. We weten proefondervindelijk wat de voor- en nadelen van agile programmeren zijn. Deze praktijkervaring zullen we zeker meenemen in onze verdere ontwikkeling. Ook willen we onze TU-begeleider speciaal bedanken. Zijn praktische feedback zorgde telkens weer voor continuering en de projectvoortgang. Nog voordat we vastliepen, kregen we handvatten hoe we de voorziene problemen konden aanpakken. Dank ook dat hij dit verslag van inhoudelijk en opbouwend commentaar wilde voorzien. Tenslotte is het ook nodig de ouders van Frank te bedanken. Altijd stonden ze klaar om met ons te sparren en leverden ze tips en raadgevingen. Op vlak van documenteren konden we altijd bij hen terecht voor raadgevingen, formuleringen, misschien wel het belangrijkste, wat nu precies waar hoort te staan.

Inhoudsopgave Voorwoord .................................................................................................................. 2 Inhoudsopgave ........................................................................................................... 3 Inleiding ...................................................................................................................... 4 Het te verbeteren prototype........................................................................................ 5 Iteratie I – Verbeteringspunten van het oude prototype. ............................................ 8 Verbeterpunten oude prototype. ............................................................................. 8 Ontwerp .................................................................................................................. 8 Database ............................................................................................................. 8 Graphical user Interface ...................................................................................... 9 Implementatie.................................................................................................... 11 Iteratie II – De toevoegingen .................................................................................... 12 Analyse verbeterpunten voor vorige iteratie ......................................................... 12 De viewer .......................................................................................................... 12 Deelnemers beheren......................................................................................... 12 De voorkant van de applicatie ........................................................................... 12 Ontwerp ................................................................................................................ 13 De viewer .......................................................................................................... 13 Deelnemers beheren......................................................................................... 14 De voorkant van de applicatie ........................................................................... 16 Iteratie III – Het bezettingsprobleem......................................................................... 17 Analyse verbeterpunten voor vorige iteratie ......................................................... 17 Ontwerp ................................................................................................................ 17 Conclusies & aanbevelingen .................................................................................... 19 Bijlage I Bijlage II Bijlage III Bijlage IV Bijlage V Bijlage VI -

Opdracht omschrijving Plan van Aanpak Oriëntatieverslag Logboek Ontwikkeling in design Hiërarchische inlogstructuur

Alle bijlagen van het verslag zijn ook te vinden in het bijbehorende mapje van de meegeleverde zip file.

Inleiding Achtergronden De opdracht voor dit bachelor eindproject was een planningsapplicatie te ontwikkelen die commercieel benut zou gaan worden door de opdrachtgever Tango Planner. Wim Antonissen was zowel de opdrachtgever als de klant. De eerste stap in dit project voor ons was de opdracht te omschrijven en een plan van aanpak op te stellen wat uitgevoerd zou worden na een akkoord van de opdrachtgever. Plan van aanpak De eerste stap hierin was om in nauw overleg met de opdrachtgever het doel van het programma en functionele eisen en wensen scherp te stellen. . Wim vertelde ons dat naar zijn inzicht hedendaagse planningsapplicaties zich teveel bezig houden met het proces van het plannen waarbij de kaders en regelingen vaak belemmerend werken voor de planner. Zaken zoals de gebruiker blokkeren wanneer deze iets wil inplannen wat bijvoorbeeld niet aansluit op de arbeidstijdenwet. Zijn visie hierin is dat de planner zelf alle kennis over het planningsproces heeft en de applicatie alleen nodig heeft om te ondersteunen bij het planningproces. Het voordeel dat hieruit direct kan volgen is dat het programma dan ook in staat zal zijn voor meerdere bedrijfstakken de planningen te regelen. Onderwijsinstellingen, taxibedrijven en ziekenhuizen, kunnen allemaal gebruik maken van dit flexibele programma. Vervolgens bleek dat in een eerdere fase door Maarten van Zomeren een eerste prototype gemaakt was. In overleg is besloten om het basisprototype te verbeteren waarbij gebruik gemaakt zou worden van de Agile programmering als werkwijze. Het doel van deze stageopdracht was om het prototype te verbeteren wat betreft functionaliteit en (grafisch) design. Verder zijn er nog wat eisen en randvoorwaarden gesteld zoals het gebruik van een SQL database Aangezien gekozen is voor de werkwijze van agile programmering zullen De probleemanalyse, het ontwerp, en de implementatie van het product per iteratie behandeld worden We zullen ons, ten bate van de leesbaarheid van dit verslag, tot de drie grootste iteraties beperken. Voor een specifieker overzicht van het verloop van dit project of nadere uitwerking of detaillering van het ontwerp verwijzen wij graag naar de bijlagen van dit verslag. Voor een specifieker overzicht van het verloop van dit project verwijzen wij naar het logboek. Voor een specifieker overzicht van de ontwikkeling van het ontwerp verwijzen we naar het designdocument. Deze documenten zijn samen met enkele andere aanvullende documenten voor dit project te vinden in de bijlagen van dit verslag.

Het basisprototype In dit hoofdstuk wordt het basisprototype beschreven. Hierna zullen de belangrijkste verschillen tussen de eerste iteratie van het nieuwe prototype en dit oude basisprototype benoemd worden. In het basisprototype begint de gebruiker met een startscherm. In dit startscherm kan de gebruiker aangeven of deze een bestaande planning wil openen of een nieuwe planning wil aanmaken.

Als de gebruiker hier op ‘wat wilt u plannen’ klikt verschijnt het volgende scherm:

Gevolgd door (wanneer de gebruiker op ‘wat heeft u daar voor nodig’ klikt) een scherm waarin de gebruiker kan aangeven wat hij of zij verder nodig denkt te hebben.

Na ingevuld te hebben wat de gebruiker daadwerkelijk wil plannen opent het planningsscherm zelf.

In het planningsscherm kan de gebruiker specifieke schema’s in elkaar zetten of nazien. Dit is de basis van het programma en zal grafisch daarom er ook goed uit moeten zien. In de eerste iteratie moet naar dezelfde functionaliteit worden gewerkt als het prototype dat hierboven is uitgelicht. Waarbij is gesteld dat het programma in c# geschreven moet worden en de database met SQL gemaakt moet worden.

Iteratie I – Verbeteringspunten van het oude prototype. In deze eerste iteratie van het prototype was het belangrijk om de functionaliteit van het oude prototype te evenaren en verbeterpunten te vinden voor deze of voor aankomende iteraties.

Verbeterpunten oude prototype. Het oude prototype heeft een aantal nadelen. De voornaamste hiervan zijn dat het prototype grafisch onvoldoende was uit ontwikkeld en dat de performance onvoldoende was. Het kost veel tijd voordat het programma is opgestart en de schermen getoond worden. De functionaliteit van dit oude prototype is wel voldoende voor de eerste iteratie van het nieuwe prototype.

Ontwerp Om het nieuwe prototype te maken waren eerst ontwerpschetsen nodig van de database en de Grafische user interface, hierna te noemen GUI. Beide ontwerpen zullen hierna worden behandeld

Database Het ontwerp van de database gaat er vanuit dat een planning altijd is op te delen in ‘objecten’ die de planner wil inplannen. Deze zullen we vanaf nu in dit verslag ‘deelnemers’ noemen. Daarnaast zijn er koppelingen tussen deze deelnemers die op een tijdstip worden ingepland. Deze koppelingen zullen we vanaf nu ‘activiteiten’ noemen. Verder gaat deze database structuur ervan uit dat deze deelnemers altijd in specifieke groepen zijn op te delen. Zoals ‘Jan’ en ‘Gerrit’ die beide onder de groep ‘Personeel’ zouden vallen. Deze groepen waar deelnemers onder vallen noemen we ‘deelnemertypes’. Het ontwerp dat hieruit voortkwam is uitgewerkt in het hierna volgende schema: ····De tabel ‘gebruikt’ bevat alle koppelingen tussen een activiteit en zijn deelnemers. De tijd is in dit eerste ontwerp een deelnemer met als naam het tijdstip dat het moet voorstellen.

De tabel ‘gebruikt’ bevat alle koppelingen tussen een activiteit en zijn deelnemers. De tijd is in dit eerste ontwerp een deelnemer met als naam het tijdstip dat het moet voorstellen.

Graphical user Interface De interface is voor een groot deel gelijk aan die van het oude prototype. Er is echter al in dit stadium nagedacht over verbeteringen in gebruiksgemak en visualisatie.

Het bovenstaande plaatje toont het hoofdscherm van het prototype van de eerste iteratie. In de opties menu balk kan de gebruiker invullen welke deelnemers en deelnemertypes hij of zij wil inplannen.

In het scherm hierboven is het deelnemers beheren scherm te zien. De gebruiker kan zelf toevoegen en verwijderen wat hij of zij wil kunnen inplannen. Omdat de planningselementen naar wens kunnen worden toegevoegd is het dus mogelijk het programma zo te initialiseren dat bijvoorbeeld taxiritten worden ingepland maar ook de operaties in een ziekenhuis ingeregeld kunnen worden. Links onderin het hoofdscherm kan de gebruiker activiteiten toevoegen. Het activiteiten toevoegen scherm ziet er als volgt uit:

Bovenin dit scherm kan de gebruiker aangeven wat toegevoegd moet worden aan de activiteit. Daaronder wordt gepresenteerd wat is ingepland en hierbij kan de gebruiker tijden invullen voor de activiteit. Zoals te zien is in het bovenstaande plaatje werd in deze eerste iteratie tijd opgeslagen als deelnemer (met als type tijd). Dit aspect was direct een van de benoemde verbeterpunten voor de volgende iteratie daar zou tijd niet meer zichtbaar mogen zijn in het type lijst.

Implementatie De implementatie van het bovenstaande ontwerp is in 3 delen opgebouwd. De GUI die de communicatie naar de gebruiker regelt, de database die alle planningen opslaat en de databasecontroller die de communicatie tussen de interface en de database regelt.

Iteratie II – De toevoegingen In het agile programmeren proces is dit de eerste grootte iteratiestap geweest. Het vorige prototype is samen met Wim Antonissen geanalyseerd om verbeterpunten te vinden.

Analyse verbeterpunten voor vorige iteratie Na de analyse van het prototype met Wim Antonissen zijn er 3 belangrijke verbeterpunten gevonden. Ze zullen hier alle drie behandeld worden.

De viewer Het programma zal verschillende soorten gebruikers kennen. Tot nu toe is in de ontwikkeling van het prototype alleen rekening gehouden met de planner. Het idee van de applicatie is echter dat de werknemers in een bedrijf ook deze applicatie kunnen gebruiken om hun planningen te bekijken. Er is dus behoefte aan een viewer applicatie. Deze viewer applicatie moet dezelfde functionaliteit hebben als de plannerapplicatie met als enig verschil dat de viewers geen nieuwe activiteiten kunnen inplannen.

Deelnemers beheren Na de eerste iteratie was het programma alleen in staat deelnemers (en types) toe te voegen en te verwijderen. Soms is er echter behoefte extra informatie op te slaan voor een specifieke deelnemer. Een voorbeeld hiervan zou zijn: ‘deze deelnemer werkt 32 uur per week’. Verder zou het prettiger zijn voor de gebruiker wanneer deze de opgeslagen informatie voor een deelnemer ook kan wijzigen zonder hem te verwijderen en opnieuw toe te voegen. Het deelnemersscherm miste dus nog enige functionaliteit.

De voorkant van de applicatie In deze eerste iteratie kon een planning wel vrij worden opgezet in het deelnemersscherm; maar er was behoefte aan een intuïtieve manier die de gebruiker direct bij het opstarten van het programma door de stappen van het initialiseren leid. Het kan verder ook zo zijn dat een groot bedrijf behoefte heeft aan

meer dan één planning. Het prototype moet daarom in staat zijn om planningen op te slaan en te openen

Ontwerp Bij het ontwerp van deze verbeterpunten zijn nog enkele tussenliggende iteratiestappen geweest. Hier zullen deze verdere stappen kort behandeld worden. Voor een volledig overzicht van de ontwikkeling van het ontwerp wordt nogmaals verwezen naar het ‘ontwikkeling in design’ document welke te vinden is in de bijlagen van dit document.

De viewer Het ontwerp van de viewer applicatie is in twee stappen gegaan. Het eerste idee was om de planner applicatie een inlogscherm te geven en een aparte applicatie te maken voor de viewer. Deze viewerapplicatie zou dan de mogelijkheid hebben alle planningen te openen maar geen functionaliteit om deze te beheren. Redelijk snel werd er echter besloten toch weer van dit idee af te wijken. Aangezien de plannerapplicatie nu toch een inlogscherm had gekregen werd besloten om de viewerapplicatie weg te laten en de plannerapplicatie de mogelijkheid te geven planningen te bekijken zonder in te loggen. Het inloggen is dan alleen nog nodig om de extra rechten te krijgen die de planner nodig heeft. Het ontwerp van het hoofdscherm zag er na afloop van dit ontwerpproces als volgt uit:

Rechtsboven in dit scherm is de login knop te zien. Met dit inlogsysteem kwamen vragen naar boven over welke rechten de planner en de viewer precies moesten hebben. Ook kwam de vraag naar boven of er behoefte was aan één of meerdere administrators. Om deze vragen goed te beantwoorden is er een apart document gemaakt. Met behulp van dit document is samen met Wim Antonissen een uiteindelijke beslissing over de rechten van de verschillende gebruikers gemaakt. Het ‘Hiërarchische inlogstructuur’ document dat voor dit doeleinde is gemaakt is te vinden in de bijlagen van dit eindverslag. De uitkomst van de analyse van dit document is als volgt: Administrator Er is één administrator account. De administrator mag planner accounts aanmaken en bestaande planningen verwijderen. Planner Er kunnen meerdere planners zijn. Een planner mag nieuwe planningen aanmaken en alle bestaande planningen aanpassen. Viewer Viewers hoeven niet in te loggen. Een viewer kan alle planningen zien maar er geen aanpassingen in maken. Als laatste moet over dit hoofdscherm gemeld worden dat de knoppen ‘deelnemers beheren’ en ‘activiteit toevoegen’ zijn veranderd in respectievelijk: ‘Wat wilt u plannen?’ en ‘Welke, wanneer, waar?’. Voor specifieke uitleg over het tot stand komen van deze namen wordt weer verwezen naar het logboek.

Deelnemers beheren Voor het ‘deelnemers beheren scherm’ is besloten een bewerken knop toe te voegen voor de deelnemers en de deelnemertypes. Wanneer de gebruiker hierop klikt kan deze een beschrijving meegeven of wijzigen voor de deelnemer (of voor het deelnemerstype). Deze beschrijving kan vrij worden ingevuld en later worden nagelezen door in het hoofdscherm met de rechtermuisknop te klikken op de deelnemer. Op deze manier kan de planner snel de specifieke informatie zien van de verschillende deelnemers. Op de volgende bladzijde kunt u een paar screenshots zien van het deelnemersscherm.

De voorkant van de applicatie Voor de planner is het belangrijk om gemakkelijk tussen verschillende planningen van het bedrijf te kunnen wisselen. Om dit te bewerkstelligen moet het programma niet alleen de bestaande planningen opslaan maar verder ook in staat zijn snel een andere planning te openen. Het ontwerp hiervan laat de applicatie automatisch de planningen opslaan bij iedere wijziging die de planner aanbrengt. Het openen en maken van nieuwe planningen heeft de planner na deze iteratie een startscherm voor gekregen.

In het startscherm is een lijst te zien met bestaande planningen. De planner kan er ook voor kiezen om een nieuwe planning aan te maken.

Iteratie III – Het bezettingsprobleem Na de vorige iteratie was er een planningsprogramma dat alle functionaliteit bevatte die Wim Antonissen had gevraagd voor de applicatie. Wim Antonissen liep echter tijdens het testen tegen een probleem aan leek te vragen om een omzetting van de functionaliteit van het programma.

Analyse verbeterpunten voor vorige iteratie Om het probleem te begrijpen moet men zich eerst in de schoenen van de planner verplaatsen. We zullen het probleem uitleggen aan de hand van een voorbeeld. Voor een uitgebreidere uitleg wordt weer verwezen naar het logboek of het design document. Een planner in een restaurant zal beginnen met obers aan tafels koppelen. Hierna zal de planner zo nu en dan gebeld worden om gasten aan de tafels toe te voegen. Het probleem dat hier ontstaat, is dat een activiteit (de koppeling tussen een ober en een tafel) niet in delen gesplitst kan worden. De activiteit van de klant heeft echter een andere tijdsduur dan de koppeling tussen de ober en de tafel.

Ontwerp De eerste oplossing die in het ontwerp naar voren kwam was om de planner de mogelijkheid te geven deelactiviteiten te maken, gekoppeld aan de hoofdactiviteit. In het voorbeeld zou de hoofdactiviteit dan de koppeling tussen de obers en de tafels zijn en zouden de gasten aan deze tafel deelactiviteiten zijn gekoppeld aan deze hoofdactiviteit. Hieronder is een plaatje (gemaakt met een exporteer functie uit het programma zelf) te zien van deze implementatie.

De planning ziet er met deze implementatie erg rommelig uit. Er was dus behoefte aan nog een andere oplossing. Na nog een analyse met Wim Antonissen kwam de oplossing naar boven om (in plaats van de deelactiviteiten) een bezettingsview te

implementeren. Deze view zou alle verschillende deelnemertypes (obers, tafels, gasten) op de verticale as tonen zodat in één oogopslag de volledige bezetting te zien is. Het uiteindelijke ontwerp gaf de gebruiker de mogelijkheid om tussen de volledige ‘bezettingsview’ en de ‘normale view’ zoals het programma tot nu toe kende te wisselen. De ‘bezettingsview’ met op de verticale as per ober alle koppelingen van deze ober en de andere deelnemertypes.

De ‘normale view’ met de obers gekoppeld aan de gasten.

Met de functionaliteit nu toereikend om het bezettingsprobleem op te hebben gelost was er nog één laatste toevoeging voor het programma. Om de bezettingsview overzichtelijk te houden moesten de activiteiten meerdere verschillende kleuren krijgen. Op die manier is het in één oogopslag te zien welke activiteit bij welke koppeling tussen deelnemer en deelnemertype hoort. Het uiteindelijke resultaat is hieronder te zien.

Conclusies & aanbevelingen Het doel van het project was om het oude prototype te verbeteren. Hoewel het programma wat betreft functionaliteit en visueel design goed vooruit is gegaan zitten er aspecten in het programma die de gebruiker niet direct intuïtief zal begrijpen. Om dit programma nu op te markt te kunnen brengen is het daarom belangrijk het programma te ondersteunen met duidelijke tutorials. Deze tutorials zullen niet nodig zijn om de basis van het programma te begrijpen maar als de gebruiker snel goede planningen wil kunnen maken zal deze veel hebben aan ondersteunende tutorials waar dit wordt voorgedaan. Er zitten verder ook onderdelen in het programma die de gebruiker wellicht erg nuttig zal vinden wanneer deze erop wordt gewezen maar welke de gebruiker niet direct uit zichzelf zal vinden. In dit project hebben we moeten werken met agile programmeren. Dit hield in dat het proces van analyseren, ontwerpen en implementeren steeds opnieuw werd doorlopen. Wij geloven dat dit een van de beste werkwijzen is voor projecten van deze omvang. Vele van de ontwikkelingen die het programma heeft ondervonden zouden nooit plaats hebben gevonden zonder het agile programmeren proces. Het belangrijkste voorbeeld hiervan is het bezettingsprobleem dat de laatste iteratie moest oplossen. Zonder het agile proces was dit probleem waarschijnlijk pas te laat ontdekt en had er of erg veel extra tijd aan het product besteed moeten worden of zou het product van veel lagere kwaliteit zijn geweest. In toekomstige projecten zullen wij graag weer de agile programmeer methode toepassen.

Bijlage I - Opdrachtomschrijving

Tango Advies & Support Bachelor project - Tango Planner

Hoeveel software hebben jullie al geschreven die daarna in de kast verdwijnt? Best wel wat volgens mij. Dit project, als jullie het goed doen, verdwijnt niet in de kast. Dit software project gaat mensen helpen om hun plannings probleem op te lossen. Dan hebben we het niet alleen over het plannings probleem van ouders die de vrije tijds besteding van hun kinderen moeten plannen. Maar ook over de plannings uitdagingen waar een taxi centrale, roostermaker op een school of een personeel functionaris mee te maken heeft. Jullie kunnen deze mensen helpen om makkelijker en beter te plannen. Het gaat hier om een innovatief stuk software, wat voor de gebruiker zo simpel mogelijk moet zijn. Meestal betekent dit dat het voor de ontwerpers en programmeurs van de software, jullie, een behoorlijke uitdaging is. Er is al een proof of concept gemaakt en er zijn al klanten erg enthousiast. Nu is de vraag aan jullie om het idee verder uit te werken en er een verkoopbaar product van te maken. De opdracht is zeer gevarieerd. De kern van het concept is heel goed en duidelijk, maar dit moet nog verder uitgewerkt worden. Het is belangrijk dat dit goed aan de gebruiker wordt gepresenteerd. Er zitten dus user interface en usability uitdagingen aan deze opdracht. Verder mogen het duidelijk zijn dat een goed concept met een goede interface zonder backend het niet doet. Deze moet dus ook gemaakt worden. De lengte van de opdracht bedraagt 11 weken en kan door een team van 2 tot maximaal 4 studenten worden uitgevoerd. Gedurende deze 11 weken zullen jullie intern bij Tango Advies en Support werken in Krimpen aan den IJssel. Aangezien jullie goed werk gaan leveren krijgen jullie ook een goede maandelijkse stage vergoeding.

De opdrachtgever

Tango Advies en Support is een bedrijfsadviserings bureau. Buiten de bedrijfsadvisering levert Tango Advies en Support hardware en maakt Tango software die mensen echt helpt. Zo is er bijvoorbeeld een Verslagen Generator gemaakt, waarmee basisschool leraren makkelijk verslagen kunnen maken en printen. Wim Antonissen de eigenaar van Tango Advies en Support zal voor jullie optreden als klant. Technische en project ondersteuning zullen jullie krijgen van Maarten van Zomeren. Hij is eigenaar van Curiehom “Your innovative idea up and running”. Voor diverse klanten heeft hij software gemaakt variërend van serious games, iPhone applications tot Augmented Reality applicaties.

Actie!

Als jullie geïnteresseerd zijn in het maken van software die mensen echt helpt, dan kunnen jullie contact opnemen met Maarten van Zomeren.

Maarten van Zomeren 06 - 41 39 53 23 [email protected] www.curiehom.nl

Wim Antonissen 06 - 54 67 38 36 [email protected] www.tangoas.nl

Bijlage II - Plan van aanpak

Plan van aanpak

bron: http://www.mozet.nl/images/puzzle werkwijze.jpg

Door: Bert Lobbezoo Frank Kaptein

Inhoudsopgave

1. Introductie ................................................................................................................. 23 1.1 Aanleiding ............................................................................................................ 23 1.2 Accordering en bijstelling ..................................................................................... 23 1.3 Toelichting op de opbouw van het plan ............................................................... 24 2. Projectopdracht ......................................................................................................... 25 2.1 Projectomgeving .................................................................................................. 25 2.2 Doelstelling project .............................................................................................. 25 2.3 Opdrachtformulering ............................................................................................ 25 2.4 Op te leveren producten en diensten ................................................................... 27 2.5 Eisen en beperkingen .......................................................................................... 27 2.6 Cruciale succesfactoren ...................................................................................... 27 3. Aanpak ...................................................................................................................... 28 3.1

Het plan van aanpak ........................................................................................ 28

3.2

Orientatiefase ................................................................................................... 28

3.3

Ontwikkelingsfase ............................................................................................ 28

3.3.1 Voorbereidingsfase ................................ Fout! Bladwijzer niet gedefinieerd. 3.3.2 Ontwerpfase ........................................... Fout! Bladwijzer niet gedefinieerd. 3.3.3

Implementatiefase ............................... Fout! Bladwijzer niet gedefinieerd.

3.3.4

Testfase ............................................... Fout! Bladwijzer niet gedefinieerd.

3.4

Afrondingsfase ................................................................................................. 28

4. Projectinrichting en voorwaarden .............................................................................. 30 5. Plannen ..................................................................................................................... 31 5.1 Planning ............................................................................................................... 31 5.2 Mijlpalenplan ........................................................................................................ 31

1. Introductie Dit Plan van Aanpak is bedoeld als informatie over de opzet van het bacheloreindproject, voor de opdrachtgevers van project Tango planner, voor de begeleidende docent, en als hulpmiddel voor de ontwikkelaars van het te maken product.

1.1 Aanleiding Het probleem bij hedendaagse planningsprogramma’s is dat ze nooit precies werken zoals de gebruiker het wil. Ze denken eigenlijk teveel mee met de gebruiker en blokkeren dingen zoals iets dubbel inplannen. Dit met als gevolg dat de gebruiker niet precies kan plannen zoals hij of zij dat wil. Ook zijn de programma’s vaak voor een bepaalde doelgroep gemaakt. Taxicentrales kunnen geen gebruik maken van een applicatie die ontworpen is voor restaurantmanagers.

Wim Antonissen wilde een planningsapplicatie maken die deze beperkingen niet had. Het idee is dat de planner zelf alle kennis heeft over het proces van het plannen zodat de planningsapplicatie hier slechts beperkte feedback over hoeft te geven en nooit iets zou moeten blokkeren. Een applicatie die zich minder met deze zaken bezig houd krijgt daarmee de mogelijkheid om voor verschillende gebruikers verschillende dingen in te plannen. Deze planningsapplicatie moet in staat zijn om voor zowel ziekenhuizen als restaurants als taxibedrijven als nog veel meer bedrijfstakken de planning te regelen.

Om een bachelor af te ronden voor de opleiding Technische Informatica moeten de studenten een eindstage lopen. Een van de mogelijkheden voor een eindstage is een project bij Tango. In dit project moeten de studenten een planningsprogramma implementeren. De opdracht heeft als doel om het prototype dat nu al aanwezig is te verbeteren rekening houdend met de genoemde zaken in de bovenstaande paragraaf.

1.2 Accordering en bijstelling Na het ontvangen van het Plan van Aanpak is het de bedoeling dat de opdrachtgever eventuele wijzigingen zal voorstellen. De voorgestelde wijzigingen zullen doorgevoerd worden in het Plan van Aanpak. Wanneer de opdrachtgever geen nieuwe wijzigingsvoorstellen heeft, is het Plan van Aanpak goedgekeurd, en zal begonnen worden met het daadwerkelijk uitvoeren hiervan.

1.3 Toelichting op de opbouw van het plan In dit Plan van Aanpak staat de projectopdracht beschreven. Samen met een afbakening van het project en een overzicht van de benodigde middelen. Het doel van het Plan van Aanpak zal zijn om de projectdoelstellingen te formuleren en de mogelijke projectrisico’s in kaart te brengen.

2. Projectopdracht In dit hoofdstuk wordt de opdracht in beeld gebracht. De opdracht zal duidelijk worden afgebakend en geformuleerd.

2.1 Projectomgeving Wanneer de opdrachtgever planningsprogramma´s gebruikte, bleek dat deze programma´s steeds dezelfde beperkingen hadden. De programma´s gaan teveel in op het proces van het plannen, waardoor de programma´s de gebruiker teveel beperkten in zijn mogelijkheden. Een voorbeeld van zo’n beperking is wanneer de gebruiker iets wil inplannen maar de applicatie hem verteld dat dit niet mag vanwege voorgeprogrammeerde restricties. Indien deze restricties niet correct zijn kunnen dergelijke programma’s zich meestal niet aanpassen. De visie van de Tango planner is dat de gebruiker het beste weet wat gepland kan worden en zal de gebruiker daar dus niet blokkeren.

2.2 Doelstelling project Aan het begin van dit project is de ontwerpers een prototype getoond. Het doel is nu om dit prototype te verbeteren. De belangrijkste verbeteringen die het nieuwe prototype moet bezitten zullen we hier alvast uitlichten. De lay-out van het oude prototype moet verbeterd worden zodat het nieuwe prototype er aantrekkelijk uitziet. Het oude prototype maakt gebruik van een database in xml codering, het nieuwe prototype moet gebruik maken van SQL codering zodat het eenvoudig voor zowel grote bedrijven als single-users te gebruiken is. Belangrijk voor het ‘verbeterde prototype’ is dat het niet automatisch gaat plannen. Het uiteindelijke doel is namelijk een product te maken dat generiek kan plannen. Het product gaat dus niet voor de gebruiker beslissen wat wanneer gepland moet worden maar bied de gebruiker de mogelijkheid om handmatig zijn planningen in te voeren.

2.3 Opdrachtformulering Het gaat hier om het ontwerpen en implementeren van een verbeterd prototype, dat gebruikers helpt planningsproblemen op te lossen. Het product moet bruikbaar zijn voor taxicentrales, maar ook voor roostermakers, personeelsfunctionarissen of restaurant managers. De gebruiker moet dus, bij het opstarten van het programma, aangeven wat hij/zij wil inplannen en welke eventuele restricties aan een planningsschema moeten zitten. Dit houdt dus in dat er een zeer duidelijke user interface in moet zitten, en dat het programma zo min mogelijk beperkingen aan de gebruiker mag opleggen over wat deze in wil plannen.

De verantwoordelijkheid van de projectgroep bestaat uit het ontwerpen en implementeren van dit prototype. Als dit prototype verder uitgebreid moet worden kan er worden overleg worden gehouden over een vervolg project om dit prototype verder te verbeteren. Het verkopen van het uiteindelijke product valt onder de verantwoordelijkheid van de opdrachtgever.

Aan deze opdracht zal gedurende elf weken fulltime gewerkt worden. De leden van de projectgroep mogen zelf inplannen op welke tijdstippen dit gebeurd. Bij elkaar moet er minimaal 420 uur gewerkt worden aan het project.

2.4 Op te leveren producten en diensten Deze paragraaf specificeert de op te leveren deelproducten. Het gaat hier zowel om de producten specifiek voor de TU Delft als om de producten voor de opdrachtgever.

De volgende producten zullen worden opgeleverd in dit project. 1) Het plan van aanpak. 2) Een planning als onderdeel van het plan van aanpak. 3) Een eindverslag waarin de ontwikkeling van het product en het project als zodanig worden uitgelegd. 4) In dit eindverslag zal als bijlage ook een oriëntatieonderzoek, gerelateerd aan de opdracht, worden meegeleverd. 5) Het product; namelijk een verbeterd prototype van de planningsapplicatie inclusief de source code van dit product.

2.5 Eisen en beperkingen De deelproducten beschreven in de vorige paragraaf worden ter accordering aangeboden aan de opdrachtgever en de begeleider vanuit de TU Delft. Indien er geen accordering plaatsvind zullen de overeengekomen afspraken niet worden behaald.

2.6 Cruciale succesfactoren Belangrijk is dat de opdrachtnemers toegang krijgen tot de testomgeving van Tango. Ideaal gezien zouden de opdrachtnemers hier vrije toegang tot hebben. Verder moeten de werknemers contact kunnen hebben met de opdrachtgever om te specificeren hoe het programma er uit moet zien.

3. Aanpak In dit hoofdstuk worden de doelstellingen die in het vorige hoofdstuk zijn gespecificeerd omgezet in een concrete wijze van aanpak. Het doel is hier dus om, na het beantwoorden van de ‘wat-vraag’, ook de ‘hoe-vraag’ te beantwoorden. In dit hoofdstuk zal inzicht worden verkregen over de te volgen weg, zodat uiteindelijk het gewenste resultaat wordt behaald.

3.1 Het plan van aanpak In de eerste weken van dit project wordt het plan van aanpak opgesteld. Hierin zal ook een voorlopige planning worden opgenomen. Wanneer het plan van aanpak is goedgekeurd zullen verdere wijzigingen betreffende de requirements of de planning worden opgenomen in het logboek. Het logboek zal ook de wekelijkse actiepunten bijhouden en alle besproken zaken met de opdrachtgever en begeleider zullen hierin genoteerd worden.

3.2 Oriëntatieonderzoek Voor dit project zal ook een oriëntatieonderzoek worden gedaan. Het onderwerp van dit onderzoek is hedendaagse planningsapplicaties. Dit oriëntatieverslag zal in de tweede week worden afgerond. Parallel aan dit onderzoek zal worden gewerkt aan het ontwerpen van de database en de GUI.

3.3 Ontwikkeling Vanaf de derde week zal er daadwerkelijk begonnen worden met het implementeren. Vanaf dat moment zal er iedere week een nieuw prototype opgestuurd worden naar de opdrachtgever. Iedere week zal opnieuw worden ontworpen, geïmplementeerd en getest. Er is dus sprake van agile programming. Tijdens het ontwikkelen zal ook wekelijks de voortgang worden gerapporteerd aan de opdrachtgever en iedere 2 weken worden gerapporteerd naar de begeleider.

3.4 Afronding

In de laatste weken van het project komen er extra in te leveren producten. Er zal een eindverslag moeten worden opgeleverd aan de begeleider van TU Delft en de organisator van TU Delft. In dit eindverslag zal ook een handleiding als bijlage worden meegeleverd. Aan het einde van het project zal ook een presentatie worden gegeven in Delft over het verloop van het project en het product.

4. Projectinrichting en voorwaarden Dit hoofdstuk behandeld de inrichting van het project en aan welke voorwaarden de opdrachtnemer en opdrachtgever moet voldoen, om zo het project tot een succesvol einde te brengen.

4.1 Project inrichting In deze paragraaf zal in kaart worden gebracht hoe het project moet worden opgericht om de opdracht uit te voeren volgens de voorgestelde aanpak. Hierbij zal worden gekeken naar de resultaten van de risicoanalyse van de eisen en cruciale succesfactoren.

De opdrachtnemers zullen op thuislocatie werken. Dagelijks zal ‘s ochtends worden overlegd over de voortgang. Er zal fulltime aan deze opdracht gewerkt worden. Wekelijks zal de vooruitgang worden opgestuurd naar de opdrachtgever zodat deze inzicht houdt op het geleverde werk. De begeleider vanuit Delft zal eens in de twee weken een tussentijdse rapportage ontvangen welke grotendeels zal bevatten wat er in het logboek staat.

De opdrachtnemers zullen gebruik maken van de database in de testomgeving geleverd door de opdrachtgever. Dit is van groot belang omdat het product dan eenvoudig kan worden geïntegreerd in de omgeving van Tango. Het uiteindelijke product is Intellectual Property van Tango Advies & Support. Alle rechten op het uiteindelijke product en de source code worden overgedragen op Tango Advies & Support.

4.2 Voorwaarden aan opdrachtnemer De projectgroep is verantwoordelijk voor het tot stand brengen van het ontwikkelingsplan. Er zal wekelijks contact met de opdrachtgever moeten zijn om de voortgang van het project te communiceren. De projectgroep is verantwoordelijk voor het voltooien van de opdrachten binnen de gestelde planning of anders de afwijkingen hiervan te communiceren met de opdrachtgever.

4.3 Voorwaarden aan opdrachtgever De opdrachtgever is verantwoordelijk voor het leveren van de testomgeving (database) binnen Tango waarbinnen het project uitgevoerd zal worden. Ook is de opdrachtgever verantwoordelijk voor het bieden van technische ondersteuning binnen het bedrijf wanneer de projectgroep dat nodig heeft.

5. Plannen In dit hoofdstuk wordt de globale planning beschreven, evenals het mijlpalenplan.

5.1 Planning Week 1-2: Voorbereiding (23 april -27 april) ● ● ●

Plan van Aanpak schrijven en bespreken met begeleiders Het doen van het orientatieonderzoek Ontwerpen van GUI en database lay-outs.

Week 3-9: Ontwikkelen (7 mei – 22 juni) ● ● ●

Ontwerpen van de Graphical User Interface. Ontwerpen van de databasestructuur Klassendiagrammen ontwerpen voor de architectuur met de bijbehorende beschrijvingen van de methodes ● Implementeren van de ontworpen klassendiagrammen ● Implementeren van de ontworpen methodes ● Bespreken van het ontwerp met begeleiders en opdrachtgevers. Alle punten in deze weken zullen iteratief worden doorlopen. Het doel is elke week een verbeterd prototype te leveren.

Week 10: Afronden (25 juni - 29 juni) ●

In deze week zal er niet veel nieuwe functionaliteit meer worden toegevoegd. Met de opdrachtgever zal worden besproken wat nog essentieel is voor het product en het prototype zal worden getest. Het doel van deze week is dus om alle onvolkomenheden uit het programma te halen.

Week 11: Afrondingsfase (2 juli - 6 juli) ● ● ●

Eindverslag Eindpresentatie Eventueel nog enkele onvolkomenheden die van week 10 zijn overgebleven verhelpen.

5.2 Mijlpalenplan Aan het einde van elke week zal een mijlpaalproduct naar de begeleider en de opdrachtgever gestuurd worden. Zo kan de voortgang nauwkeurig in de gaten

gehouden worden, en worden eventuele problemen op tijd ontdekt waardoor ze ook weer op tijd verholpen kunnen worden.

Bijlage III - Orientatieverslag

Oriëntatieverslag

Bert Lobbezoo Frank Kaptein

Inhoudsopgave Inleiding Definitie plannen Soorten planningssystemen Voor- en nadelen van de soorten Samenvatting en conclusie Literatuurlijst Overige literatuur

Inleiding Dit orientatieverslag is voor onze stageopdracht ‘Tango Planner’. Het doel van deze opdracht is een planningsapplicatie te maken die alle verschillende soorten planningen kan maken. Het gaat dus om zowel planningen als welke taxichauffeur moet met welke taxi rijden om de klant op te halen, als de agenda van een individu. Het idee is dat deze planningen niet automatisch hoeven te worden ingepland, dit omdat de planner zelf wel weet wat hij/zij wel en niet kan plannen.

Het doel van het orientatieonderzoek is om hedendaagse planningssystemen te onderzoeken om te ontdekken in welke opzichten het wenselijk is dat de Tango planner hiervan zal afwijken. De opdrachtgever gaf namelijk aan dat de huidige planners niet planden op de manier die hij wilde. Daarom is het belangrijk om duidelijk te krijgen hoe hedendaagse systemen plannen, en in welke opzichten ons systeem hiervan zal afwijken.

De resultaten van dit onderzoek zijn in dit verslag te vinden. Allereerst zal een definitie van plannen gegeven worden. Vervolgens zullen de verschillende soorten planningssystemen behandeld worden. Aan de hand van deze globale indeling zullen eigenschappen waarin de planners verschillen afgeleid worden. De voor- en nadelen van elke eigenschap zullen besproken worden, om te eindigen in een conclusie waarin het resultaat van het onderzoek samengevat wordt.

Definitie plannen Plannen is het ordenen van wat bereikt moet worden [1]. Voorbeelden van planning kunnen zijn: een rooster met colleges, de koppeling tussen chauffeurs en klanten in een taxibedrijf, een schema met onderling afhankelijke projecten. Al deze planningen gaan over de dimensie tijd. In de eerste twee voorbeelden zal iedere activiteit waarschijnlijk aan een exact tijdstip gekoppeld zijn. In het laatste voorbeeld kan tijdstip abstracter zijn door alleen een volgorde van uitvoering in te plannen.

Een belangrijke vraag die opkomt is: moet plannen altijd over tijd? De definitie spreekt over zaken die bereikt moeten worden. Plannen heeft dan altijd met de toekomst te maken. Een vrachtauto die op goede wijze ingeladen moet worden is echter ook ‘iets dat bereikt moet worden’ en heeft nog geen directe referentie met tijd maar eigenlijk met de dimensie ruimte. Blijkbaar kunnen planningen dus over verschillende dimensies gaan.

Soorten planningssystemen In dit hoofdstuk zullen planningssystemen worden ingedeeld aan de hand van de doelgroep waarvoor ze gemaakt zijn. Een planningssysteem kan voor een specifieke klant zijn gemaakt (op maat), een specifieke doelgroep (ziekenhuizen, taxibedrijven, enz..), of voor alle mogelijke gebruikers (agenda’s). In dit hoofdstuk zullen deze verschillende soorten planningssystemen worden besproken.

Op maat Om een planning te maken, moet er in de meeste gevallen een planningssysteem op maat gemaakt. Dit houdt in dat voor een specifiek bedrijf een planningsprogramma wordt gemaakt. Dit systeem kan dan beheerd worden door degene die de planning wilde. Er wordt bij deze systemen nauwkeurig geanalyseerd wat er nu precies gepland moet worden. Aan de hand van deze informatie maakt een verkoper een op maat gemaakt systeem, dat alleen voor de klant geschikt is. Voorbeelden hiervan zijn: Quintiq [8], Plan4[9], Planning.nl [13], PlanIt [14].

Specifiek doel Andere planningssystemen zijn ontwikkeld voor een bepaalde organisatie of doelen. Ze zijn ontwikkeld voor scholen, ziekenhuizen, restaurants, enz. Een aantal voorbeelden hiervan zijn: School management system [2], Club member system [3], GT Restaurant Reservation software [4], Pabx Billing System and Hotel Management [5], Advanced Hospital Management System [6], OpenProj [16].

Algemeen gebruik Tenslotte zijn er ook nog planningsprogramma’s die voor algemeen gebruik zijn bedoeld. Typische voorbeelden hiervan zijn agenda applicaties zoals: Google Calendar [10], Yahoo Calendar [11], Zoho Calendar [12], Sokati [15]. Deze programma’s hebben geen restricties voor wat de gebruiker wel en niet kan plannen. Automatisch planningschema’s creëren is dan ook geen optie bij deze programma’s. Planningssystemen waarvoor alle restricties bekend zijn hebben vaak wel de mogelijkheid de applicatie zelf automatisch een schema te laten creëren. Deze applicaties hebben dus de functionaliteit om een optimaal rooster te creëren voor een specifieke situatie.

Verschillende eigenschappen In dit hoofdstuk bespreken we verschillende typerende eigenschappen van planningssystemen. In het volgende hoofdstuk zullen we de voordelen en beperkingen van deze eigenschappen bespreken.

Automatisch plannen Een belangrijk verschil tussen huidige planningssystemen is dat sommigen automatisch plannen, en anderen weer handmatig. Met automatisch plannen wordt bedoeld dat de applicatie een ‘oplossing’ bedenkt aan de hand van de vooraf gestelde voorwaarden. Bij handmatig plannen moet de gebruiker elke activiteit handmatig invoeren. Planningssystemen zijn niet in te delen in ‘automatische’ en ‘handmatige’. Eigenlijk zitten ze er tussen in. Bij een automatisch systeem kan de gebruiker altijd activiteiten toevoegen, bewerken of verwijderen. Daarom zal het ene systeem ‘automatischer’ zijn dan een andere, oftewel, het ene systeem is meer gefocust op het genereren van een zo optimaal mogelijke oplossing dan een ander systeem. Duidelijke voorbeelden van ‘automatische’ planners zijn: Senang [7], Preactor [17], ScheduleIt [18].

Handmatig plannen Als er handmatig geplant moet worden, kan de planning naar eigen inzicht gemaakt worden. Niet het systeem bepaald wanneer een bepaalde afspraak gemaakt moet worden, dat doet de gebruiker zelf. Voorbeelden van ‘handmatige’ planningsapplicaties zijn: OpenProj [16], 2-plan team [19]

Kant en klaar pakket Met een kant en klaar pakket wordt een planningssysteem bedoeld waarvan het type planning al vast staat. De gebruiker hoeft alleen nog maar activiteiten en restricties toe te voegen. Het tegenovergestelde van een kant en klaar pakket is zelfbouw. De gebruiker moet zelf definieren wat hij precies wil plannen. Ook nu kunnen planningssystemen niet opgedeeld worden in een kant en klaar pakket of zelfbouw. Sommige zullen meer kenmerken hebben die op een kant en klaar pakket wijzen, andere systemen hebben meer zelfbouwmogelijkheden. Een aantal voorbeelden van kant en klaar pakketten zijn: GT Restaurant Reservation Software [4], SUMit's Roostergenerator [7], Plan-4 [9].

Zelfbouw Planners waarin de gebruiker zelf moet invoeren wat hij wil plannen, zijn er niet veel. Natuurlijk hebben veel planners wel enkele zelfbouw mogelijkheden, maar deze mogelijkheden zijn beperkt. Op maat gemaakte systemen vallen niet onder zelfbouw omdat niet de gebruiker het systeem opbouwt maar de verkoper die het systeem levert. Het beste gevonden voorbeeld is Sokati [15].

Uitbreidbaar Een eigenschap die veel voordelen biedt voor planners is de uitbreidbaarheid. Als een gebruiker naast personeelsplanning ook een evenementenplanning wil, is het erg handig voor deze gebruiker als het geen twee losse planners zijn, maar als deze twee planners ook met elkaar kunnen communiceren. Vooral op maat gemaakte systemen zijn uitbreidbaar, maar dat vereist wel weer tussenkomst van de verkoper. Andere mogelijkheden zijn downloadbare modules. Voorbeelden van systemen die uitbreidbaar zijn, zijn GB Solutions [20] en Monaco Planning [21].

Alleen tijdsplanningen? Een belangrijke vraag voor planningssystemen is over welke dimensie ze moeten plannen. De meeste systemen plannen over tijd en bieden dan de mogelijkheid om de tijdseenheden in te stellen zoals dag, week of maand. Sommige bieden de mogelijkheid specifiekere tijdseenheden in te plannen. Er zijn echter ook planningssystemen die over andere dimensies plannen zoals het inplannen van gebruikte ruimte in pakhuizen. De dimensie hier is dus ruimte. Duidelijke voorbeelden van plannen over een onveranderbare dimensie zijn kalenders, zoals die van Google [10], Yahoo [11] en Zoho [12], en projectplanners zoals OpenProj [16] en Openbrave [22]. Planning waarbij de dimensie waarover gepland wordt aangepast kan worden, hebben we niet gevonden. In geen van de gevonden applicaties is het mogelijk om een tijds-dimensie planner te veranderen naar een ruimte-dimensie planner, of om andere dimensies toe te voegen.

Analyse eigenschappen In dit hoofdstuk zullen we de verschillende eigenschappen, besproken in het vorige hoofdstuk, onderzoeken op de voordelen en beperkingen die ze een planningsprogramma geven. Deze analyse zal ons een helder inzicht geven over welke eigenschappen de Tango planner wel of juist niet moet hebben en welke gevolgen dit met zich meebrengt.

Automatisch De voordelen van het automatisch plannen zijn tijdsbesparing en de optimale oplossing. Het eerste nadeel is dat het opzetten van het systeem veel tijd en geld kost. Het tweede nadeel is dat het systeem niet kan plannen wat de gebruiker precies wil. Dit kan verholpen worden door een analyse van het probleem, maar deze analyse kan bedrijven en organisaties afstoten het product aan te schaffen. Het derde nadeel is dat de werkelijkheid aan het systeem aangepast moet worden. Het systeem is een beperking van de werkelijkheid, en het is onmogelijk de restricties van de gehele ‘werkelijkheid’ in het systeem in te voeren.

Handmatig Het belangrijkste voordeel van handmatig plannen is dat de planning zich aanpast aan de werkelijkheid. De nadelen van handmatig plannen zijn de soms niet optimale oplossing, de tijd die het vergt om alle activiteiten in te voeren, en de hoge foutdichtheid als de gebruiker een foutje maakt bij het invoeren.

Kant en klaar pakket De voordelen van een kant en klaar pakket zijn dat het simpel te gebruiken is. De koper kan gelijk aan de slag. Verder is de kansdichtheid kleiner. Het systeem is namelijk door ‘experts’ opgezet, die weten hoe het beste gepland kan worden. Als de koper zelf de planning moet configureren, is de kans op fouten veel groter. De nadelen van een kant en klaar pakket zijn eigenlijk dezelfde als die van een automatische planner. De gebruiker kan alleen plannen binnen de mogelijkheden van het systeem, als hij bijvoorbeeld een speciale restrictie wil, is dat niet mogelijk.

Verder moet de werkelijkheid zich aanpassen aan het systeem, in plaats van dat het systeem zich aanpast aan het systeem.

Zelfbouw Het hebben van veel meer mogelijkheden is het grootste voordeel van zelfbouw. Zo kan een systeem naar eigen inzicht worden ingericht, wat ervoor zorgt dat het systeem zich aanpast aan de werkelijkheid en niet andersom. De andere kant is dan weer dat er een hogere kansdichtheid is. Een gebruiker kan gemakkelijk fouten maken, zonder dat hij dat zelf doorheeft. Er is niets dat zegt dat de gebruiker een fout maakt. Verder geldt ook hier weer dat de gebruiker gebonden is aan de mogelijkheden van het systeem. Een systeem dat bedoeld is voor het inplannen van personeel, kan niet gebruikt worden om een capaciteitsplanning te maken.

Uitbreidbaar Als een planningsapplicatie uitbreidbaar is, heeft dat een aantal voordelen. De belangrijkste zijn wel dat het een stuk goedkoper is, er hoeft namelijk geen totaal nieuw systeem opgezet te worden. Ook kunnen de modules goed met elkaar samenwerken, waardoor de gebruiker geen last heeft van conflicterende planningen. Grote nadelen zijn er niet. Wat wel vaak gebeurd is dat de overzichtelijkheid een beetje zoek is. De gebruiker ziet door de bomen het bos niet meer.

Voorbepaalde dimensies Het grootste voordeel van vooraf bepaalde dimensies is dat de gebruiker veel overzicht heeft. Dit heeft tot gevolg dat de gebruiker de planning beter begrijpt,en daarom ook beter aanvoelt hoe hij moet plannen. Het ligt voor de hand dat het grootste nadeel van vooraf bepaalde dimensies is dat de gebruiker gebonden is aan deze dimensies. Zo kun je geen capaciteits-planning maken op een kalender-planningssysteem.

Andere dimensies mogelijk De voor- en nadelen die voor vooraf bepaalde dimensies gelden, gelden omgekeerd voor planningssystemen waarbij andere dimensies wel mogelijk zijn. Een extra

voordeel is de door de gebruiker gedefinieerde dimensies gemakkelijk kunnen samenwerken, zodat een betrouwbaardere planning mogelijk is.

Samenvattend

Soort systeem

Voordelen

Nadelen

Automatisch

- Tijdsbesparing

- Kost veel tijd en geld om te creëren.

- Optimale oplossing

- Planner plant niet wat de gebruiker wil - Werkelijkheid moet zich aanpassen aan het systeem Handmatig

- Planning past zich aan aan de werkelijkheid

- Geen optimale oplossing - Hoge foutdichtheid - Planning maken kost veel tijd

Kant en klaar pakket

- Geen zelfbouw - Lage foutdichtheid

- Werkelijkheid moet zich aanpassen aan het systeem - Planner plant niet wat de gebruiker wil

Zelfbouw

Uitbreidbaar

- Veel meer mogelijkheden

- Hoge foutdichtheid

- Planning kan zich aanpassen aan de werkelijkheid

- Gebruiker is gebonden aan de mogelijkheden van het systeem

- Goedkoper

- Onoverzichtelijk

- Samenwerking tussen verschillende modules Vooraf bepaalde dimensies

- Overzichtelijk

- Werkt alleen voor bepaalde typen planningen (bijvoorbeeld kalenders)

Andere dimensies mogelijk

- Samenwerking tussen verschillende dimensies - Alle planningen zijn mogelijk

- Onoverzichtelijk

Samenvatting en conclusie Er zijn dus veel verschillende planningsapplicaties. Sommige applicaties zijn specifiek voor grootte bedrijven of juist single-users. Andere zijn voor algemeen gebruik en kunnen dus door alle klanten gebruikt worden voor hun roostering. Een ander onderscheid tussen de verschillende applicaties is dat sommige applicaties voor een specifiek doel of specifieke klant zijn gemaakt terwijl andere deze restricties juist niet hebben.

Hierna hebben we de verschillende typerende eigenschappen van planningssystemen besproken. In het hoofdstuk analyse eigenschappen sluiten we af met een tabel waarin alle voor en nadelen van deze eigenschappen staan. De Tango planner zal bij iedere eigenschap de meest flexibele keus moeten maken voor de gebruiker. We kunnen nu dus voor al deze eigenschappen bepalen of de Tango planner de betreffende eigenschap wel of niet moet bezitten.

De eerste vraag is: handmatig of automatisch? In de tabel is af te lezen dat een automatische planner in sommige gevallen ervoor zorgt dat de gewenste planning zich moet aanpassen aan wat de automatische planner voorschrijft dat mogelijk is. Dit houdt in dat de Tango planner een handmatige planner moet zijn. De volgende keuze die gemaakt moet worden is of de Tango planner een zelfbouw pakket of een kant en klaar pakket moet zijn. In de tabel is af te lezen dat zelfbouw de gebruiker meer opties geeft; de tango planner moet dus zelfbouw zijn.De volgende vraag is of de planningsapplicatie uitbreidbaar moet zijn. Het antwoord spreekt weer voor zich; uitbreidbaar bied de gebruiker meer mogelijkheden dus de Tango planner moet uitbreidbaar zijn. De laatste keuze, namelijk alleen tijdsplanningen of verschillende soorten planningen, ligt ingewikkelder voor de Tango planner. Ideaal gezien zou de Tango planner over alle dimensies moeten kunnen plannen omdat dit weer meer mogelijkheden bied. In het prototype van dit project is dit echter een optionele toevoeging. Het mag de overzichtelijkheid van het programma niet te veel aantasten; de beslissing of dit wordt toegevoegd moet dus nog gemaakt worden.

De vraag is nu wat ons dit heeft geleerd ten opzichte van de stage opdracht. Wat belangrijk is op te merken, is dat ons planningsprogramma voor verschillende planningen gebruikt moet kunnen worden. Het is in dat opzicht dus een algemene planner. Zoals echter besproken in hoofdstuk: ‘soorten planningssystemen’ hebben algemene planners meestal de eigenschap niet met de gebruiker mee te denken over hoe deze kan plannen. De ‘Tango planner’ wijkt hiervan af door de gebruiker in te laten stellen aan welke restricties het schema moet voldoen. Een voorbeeld hiervan kan zijn dat chauffeurs in een taxibedrijf niet twee klanten op twee

verschillende locaties tegelijk kan ophalen. De ‘Tango planner’ moet dan waarschuwen wanneer de gebruiker zich niet aan deze, door zichzelf opgelegde, restricties houdt.

Referenties [1] http://www.encyclo.nl/begrip/plannen [2] http://www.ialda.com/ [3] http://www.swifttec.com/products/ClubMembership/index.html [4] http://www.globaltechnologiesllc.com/gtrestaurantreservationsoftware/index.html [5] http://www.bicsoft.net/ [6] http://www.arpitsofts.pcriot.com [7] http://www.sum-it.nl/generator.html [8] http://www.quintiq.nl/ [9] http://www.ewingsict.nl/producten/planning-software/ [10] https://www.google.com/calendar/ [11] http://calendar.yahoo.com/ [12] http://www.zoho.com/calendar/ [13] http://www.planning.nl/ [14] http://www.planningit.nl/ [15] http://www.sokati.nl/main/planning/lang/NL [16] http://sourceforge.net/projects/openproj/ [17] http://www.planbord.nl/preactor [18] http://www.scheduleit.co.uk/ [19] http://2-plan.com/open-source-project-software-2-plan-team.html [20] http://www.gbsolutions.nl/ [21] http://www.monacoplanning.nl [22] http://sourceforge.net/projects/openbravo/

Overige literatuur http://www.projectinabox.org.uk/planner.asp http://www.ionprojects.com/nl http://www.professionalplanner.nl/ http://www.planbase.nl/ http://www.planningforce.com/ http://www.myscheduling.net/index.php http://www.atrex.com/atrex.asp http://sourceforge.net/projects/openbravo/ http://www.almyta.com/abc_inventory_software.asp

Bijlage IV – Logboek Logboek

Bron: http://dagmarvalerieboer.wordpress.com/2011/09/09/plan-van-aanpak/

Door:

Bert Lobbezoo Frank Kaptein

Inhoudsopgave Week 1 ...................................................................................................................... 51 Gesprek met begeleider ........................................................................................ 51 Gesprek met opdrachtgever .................................................................................. 51 Vorderingen ........................................................................................................... 53 Actielijst ................................................................................................................. 53 Week 2 ...................................................................................................................... 54 Actielijst vorige week ............................................................................................. 54 Gesprek met opdrachtgever .................................................................................. 54 Vorderingen ........................................................................................................... 56 Actielijst ................................................................................................................. 56 Week 3 ...................................................................................................................... 58 Actielijst ................................................................................................................. 58 Gesprek met begeleider ........................................................................................ 58 Vorderingen ........................................................................................................... 59 Actielijst ................................................................................................................. 59 Week 4 ...................................................................................................................... 60 Gesprek met opdrachtgever .................................................................................. 60 Week 5 ...................................................................................................................... 62 Gesprek met opdrachtgever .................................................................................. 62 Gesprek met opdrachtgever .................................................................................. 62 Week 6 ...................................................................................................................... 64 Actielijst ................................................................................................................. 64 Week verslag ......................................................................................................... 64 Week 7 ...................................................................................................................... 65 Gesprek onderling ................................................................................................. 65 Gesprek met opdrachtgever .................................................................................. 66 Week 8 ...................................................................................................................... 68 To do list ................................................................................................................ 68 Gesprek met opdrachtgever .................................................................................. 70 Week 9 ...................................................................................................................... 71

Gesprek met opdrachtgever .................................................................................. 71 Gesprek met begeleider ........................................................................................ 72 Gesprek met opdrachtgever .................................................................................. 72 Week 10 .................................................................................................................... 74 Weekverslag .......................................................................................................... 74 Week 11 .................................................................................................................... 75 Gesprek met opdrachtgever .................................................................................. 75 Actielijst gesprek ................................................................................................ 75 Gesprek met opdrachtgever .................................................................................. 75

Week 1 In dit hoofdstuk staan de belangrijkste dingen voor het project van week 1.

Gesprek met begeleider Datum:

26 april 2012

Aanwezig:

Pascal Wiggers (begeleider), Frank Kaptein en Bert Lobbezoo

Onderwerp: Begeleiding vanuit de TU

Reactie werknemers: 1. Voor het oriëntatieonderzoek kan het beste onderzoek gedaan worden naar de huidige planningssystemen. Voor de tekortkomingen van de huidige systemen, die uit het onderzoek volgen, kan een oplossing bedacht en geïmplementeerd worden. 2. In het Plan van Aanpak moet aandacht besteed worden aan de volgende zaken: a. Er wordt agile geprogrammeerd. b. Elke ochtend zal de code die de vorige dag geschreven is gecontroleerd worden door de projectleden. Dit zal het opmaken en becommentariëren van de code, voor zo ver dat de vorige dag niet is gedaan. 3. Het contact met de begeleider zal bestaan uit een wekelijkse mail. Afspraken kunnen naar behoefte gemaakt worden. 4. Elke twee weken moet er een vooruitgangsformulier naar de begeleider gestuurd worden.

Gesprek met opdrachtgever Datum:

27 april 2012

Aanwezig:

Wim Antonissen (opdrachtgever), Frank Kaptein en Bert Lobbezoo

Onderwerp: Plan van Aanpak en bijeenkomst Hotel Delft Centrum

Reactie opdrachtgever: 1. Aanpak Plan van Aanpak. Geen inhoudsopgave in inhoudopgave 2. Geen waterval methode maar iteratieve methode. Er zijn verschillende soorten dus maak een keuze. Het woord fase hoort bij de waterval methode. 3. Er staat nog niets over klant requirements. Dus hierbij:

• •

Programmeren in C-sharp Een vorm van repository zoeken zodat de source code op de server staat • Werken met Sequel server • Er moet iets staan dat het IP of Intellectual Property van Tango Advies & Support is en blijft 4. Het maken van een logboek in het kader van afspraken en uitvoering daarvan. Daarin is goed te volgen wie wat doet van jullie beiden, wat Tango voor jullie doet en alle aanpassingen naar het eindproduct.

Vorderingen 1. Onderwerp oriëntatieverslag duidelijk 2. Voorlopig ontwerp databasestructuur 3. Voorlopig ontwerp GUI

Actielijst 1. 2. 3. 4. 5. 6.

Oriëntatieverslag (Frank en Bert) Plan van Aanpak verbeteren aan de hand van feedback (Frank) Technisch schema maken van de database structuur (Bert) GUI ontwerp verbeteren (Frank) Logboek maken (Frank en Bert) Tussentijdse rapportage aan Pascal Wiggers (Frank & Bert)

Week 2 Actielijst vorige week 1. 2. 3. 4. 5. 6.

Oriëntatieverslag (Frank en Bert) Plan van Aanpak verbeteren aan de hand van feedback (Frank) Technisch schema maken van de database structuur (Bert) GUI ontwerp verbeteren (Frank) Logboek maken (Frank en Bert) Tussentijdse rapportage aan Pascal Wiggers (Frank & Bert)

Gesprek met opdrachtgever Datum:

04 mei 2012

Aanwezig:

Wim Antonissen (opdrachtgever), Frank Kaptein en Bert Lobbezoo

Onderwerp: Plan van Aanpak, oriëntatieverslag en design Gui/ Database

Het plan van aanpak is wederom besproken met de opdrachtgever. De wijzigingen zijn goedgekeurd. Indien ook de begeleider vanuit Delft de wijzigingen goedkeurt zal het Concept Plan van Aanpak worden omgezet in een definitief Plan van Aanpak. Verder zal in dit logboek worden besproken welke verdere wijzigingen in requirements, in design of in de planning zijn besproken. Het oriëntatieverslag is getoond aan de opdrachtgever. Het logboek is besproken. De lijst van requirements, opgenomen in dit logboek, is (voorlopig) goedgekeurd. In het gesprek kwam het idee naar voren om een constraints kopje hierin aan te brengen (i.p.v alleen must/should/could) om vereisten zoals programmeren in c# te zetten.

Het design van de database in wederom besproken. Het oorspronkelijke plan van de opdrachtgever was om een executable van het programma op de server te hebben staan. De klant kan dan inloggen op de server van Tango om daar het programma op te starten en te draaien. De database zou dan dus ook standaard op de Tango server staan. Het idee dat wij gepresenteerd hebben is om het programma

op de computer van de klant zelf te draaien. De klant kan dan als single user een database hebben op zijn eigen computer terwijl de klant als bedrijf verbinding kan maken met de database op de server van Tango. Beide opties zou het programma automatisch voor de klant instellen, de klant hoeft dus alleen aan te geven of hij single user is of een bedrijf.

Oorspronkelijk plan

Nieuw plan

Stap 1

Log in op server

Start programma op computer

Stap 2

Start programma op server

Maak contact met database op server (of als single user op de locale computer)

Stap 3

Beginnen

Beginnen

De uitkomst van het bespreken van deze mogelijkheden was om voorlopig voor het nieuwe plan te gaan omdat dat met implementeren in elk geval makkelijker is. De opdrachtgever kan dan nog wel wekelijks het programma uittesten dus ziet hier geen beperking in. De uiteindelijke keuze voor het eindproduct zal op een later moment in het project worden besloten.

De ‘Graphical user interface’ hebben wij deze week onderzocht of een datagrid een goede manier is om het planningsscherm in te delen. Het alternatief is een scherm waar ‘button achtige objecten’ in gesleept kunnen worden. De overwegingen die wij hebben gehad hierover zijn het ‘uiterlijk’; dus welke keuze we mooier vinden. De snelheid waarmee het programma blijft draaien wanneer er erg grootte tabellen zijn. De eenvoud van het programmeren. Een andere vraag was of het mogelijk was detail informatie te krijgen van een specifieke activiteit die in de tabel staat wanneer we met een datagrid werken. De moeilijkheid die wij hierin zagen kwam vanuit het gegeven dat het datagrid ingewikkelde query’s toont aan de gebruiker.

Tijdens het gesprek was onze conclusie dat een datagrid waarschijnlijk erg veel problemen met zich mee zou brengen tijdens het programmeren. Dit voornamelijk vanwege de hierboven genoemde query’s. Nu na het gesprek hebben wij het er nogmaals over gehad en hebben we onze mening toch weer herzien. De

ingewikkelde query’s hebben we nu oplossingen voor en de snelheid van het programma en eenvoud van het programmeren lijken daardoor nu met een datagrid toch beter te gaan. We zullen maandag een mail naar de opdrachtgever Wim Antonissen sturen met onze (voor deze week) definitieve beslissing hierover.

Datagrid

Handmatig gemaakte tabel

Eenvoud bij het programmeren

Erg eenvoudig. Query’s zijn geen groot probleem.

Details opvragen van activiteiten is eenvoudig omdat iedere ‘button’ (activiteit in het scherm) zijn eigen informatie heeft. Het tonen van de juiste tabel informatie is ingewikkelder.

Snelheid bij grote tabellen

Blijft altijd snel

Wordt vooral langzaam wanneer in het planningsschema kan worden ingezoomd omdat dan objecten moeten worden gemaakt en verwijdert terwijl het programma draait.

Uiterlijk

Een eenvoudige tabel

Mogelijkheid erg mooie tabellen te creëren.

Vorderingen 1. 2. 3. 4. 5.

Plan van Aanpak verbeteren aan de hand van feedback (Frank) Technisch schema maken van de database structuur (Bert) GUI ontwerp verbeteren (Frank) Logboek maken (Frank en Bert) Tussentijdse rapportage aan Pascal Wiggers (Frank & Bert)

Actielijst

1. Oriëntatieverslag en feedback hierover uitwerken (Bert & Frank) 2. Beslissing maken over het wel of niet gebruiken van de datagrid (Bert & Frank) 3. Het implementeren van de database structuur (Bert) 4. Het implementeren van een (aan de hand van de feedback van de opdrachtgever) verbeterde GUI (Frank) 5. Aan het einde van de week een executable hebben met de GUI en de database structuur voor de opdrachtgever (Bert & Frank) 6. Afspraak met begeleider voor feedback orientatieverslag en bespreken documentatie RAD en het ontwerpen (Begeleider & Bert & Frank) 7. De maandag na deze week een gesprek op Skype met de opdrachtgever over vorderingen en te ontwikkelen features voor die week (Opdrachtgever & Frank & Bert)

Week 3 Actielijst 1. Oriëntatieverslag en feedback hierover uitwerken (Bert & Frank) 2. Beslissing maken over het wel of niet gebruiken van de datagrid (Bert & Frank) 3. Het implementeren van de database structuur (Bert) 4. Het implementeren van een (aan de hand van de feedback van de opdrachtgever) verbeterde GUI (Frank) 5. Aan het einde van de week een executable hebben met de GUI en de database structuur voor de opdrachtgever (Bert & Frank) 6. Afspraak met begeleider voor feedback orientatieverslag en bespreken documentatie RAD en het ontwerpen (Begeleider & Bert & Frank) 7. De maandag na deze week een gesprek op Skype met de opdrachtgever over vorderingen en te ontwikkelen features voor die week (Opdrachtgever & Frank & Bert)

Gesprek met begeleider Datum:

(wo) 9 mei 2012

Aanwezig:

Pascal Wiggers (begeleider), Frank Kaptein en Bert Lobbezoo

Onderwerp: Begeleiding vanuit de TU

In dit gesprek zijn het orientatieverslag, het (Concept) PvA, het logboek, het GUI ontwerp, en de databasestructuur besproken. Verder is ook het nog te maken RAD document besproken. Voor dit laatste document zal gelden dat de requirements die in het Logboek staan ook in dit document moeten komen te staan. Verder zullen de UML diagrammen, die nu alleen in ruwe schetsvorm zijn, aan het RAD document toegevoegd moeten worden.

Voor het (Concept) PvA en het oriëntatieverslag geldt dat het nog specifieker gedocumenteerd moet worden ‘wat’ er daadwerkelijk gemaakt word. In het plan van aanpak houdt dit in dat hoofdstuk 2 nog uitgebreid moet worden. In het oriëntatieverslag moet duidelijker gemaakt worden wat de consequenties zijn van het onderzoek voor de tango planner.

Het logboek zal fungeren als tussentijds verslag aan Pascal Wiggers. Eventueel met het checklijstje van opgeleverde producten, dat in het oorspronkelijke concept tussentijdsverslag staat, als bijlage. De requirements in het logboek moeten iets specifieker. Als voorbeeld werd genoemd: ‘een groot planningsscherm in de GUI’. Verder zal in het logboek nu ook worden gedocumenteerd wat de ontwikkelingen in ontwerp zijn.

Ter afsluiting zijn nog wat organisatorische afspraken gemaakt. Wanneer mail wordt gestuurd naar de opdrachtgever zal normaal gesproken een cc’tje worden gestuurd naar de begeleider en visa versa. Het voordeel hiervan is dat beide altijd een overzicht hebben van wat is besproken. Verder is afgesproken dat alle opgestuurde documenten versie nummers zullen krijgen zodat wanneer een nieuwer document word opgestuurd voordat het oude document is doorgelezen er geen verwarring zal ontstaan.

Vorderingen 1. Oriëntatieverslag en feedback hierover uitwerken (Bert & Frank) 2. Beslissing maken over het wel of niet gebruiken van de datagrid (Bert & Frank) 3. Het implementeren van de database structuur (Bert) 4. Het implementeren van een (aan de hand van de feedback van de opdrachtgever) verbeterde GUI (Frank) 5. Aan het einde van de week een executable hebben met de GUI en de database structuur voor de opdrachtgever (Bert & Frank) 6. Afspraak met begeleider voor feedback orientatieverslag en bespreken documentatie RAD en het ontwerpen (Begeleider & Bert & Frank)

Actielijst 1. Oriëntatieverslag feedback hierover uitwerken (Bert & Frank) 2. PvA feedback hierover uitwerken (Bert & Frank) 3. Activiteit toevoegen ontwerp en implementatie

Week 4 Gesprek met opdrachtgever Datum:

(ma) 14 mei 2012

Aanwezig:

Wim Antonissen (opdrachtgever), Frank Kaptein en Bert Lobbezoo

Onderwerp: Prototype Tango planner.

Voor deze Skype afspraak was het prototype opgestuurd naar de werkgever. Helaas waren er enkele problemen wanneer het programma op een ander platform werd gedraaid. De grootte van de items is bij verschillende operatie systemen niet gelijk en wat 10 pixels is bij windows 7 is bij bijvoorbeeld xp zo’n 8 pixels. Wij zullen deze week oplossingen proberen te vinden voor deze problemen zodat een volgend prototype wel functioneel en testbaar is voor de opdrachtgever.

In het screenshot is te zien dat aan de rechterkant en onderkant van het programma een gedeelte van het beeld wegvalt. Hieronder is een screenshot van hoe het er op windows 7 uitziet.

Week 5 Gesprek met opdrachtgever Datum:

(ma) 21 mei 2012

Aanwezig:

Wim Antonissen (opdrachtgever), Frank Kaptein en Bert Lobbezoo

Onderwerp: Prototype Tango planner.

In deze korte skype afspraak heeft de opdrachtgever 3 dingen met ons besproken. 1. Er zaten helaas een aantal fouten in het prototype die te maken hadden met het draaien op verschillende platformen. Het is daarom raadzaam voor ons om te zorgen dat het in elk geval zal draaien op de server zodat het programma getest kan worden door de opdrachtgever en verkoopbaar zou zijn aan klanten. Deze klanten kunnen dan inloggen op de server en het programma vanaf daar benaderen. Dit was ook het oorspronkelijke verkoopplan dus lijkt de beste oplossing voor deze ‘platform afhankelijkheidsproblemen’. 2. Het ontwerp van de GUI moest meer rekening houden met een zo kort mogelijke afstand houden tussen de verschillende knoppen (zie het ‘ontwikkeling in ontwerp’ document voor meer informatie hierover). 3. Het datagrid moet standaard tijd op de horizontale as krijgen (in latere prototypes eventueel instelbaar naar andere dimensies). Wim Antonissen heeft ons aangeraden op internet te zoeken naar oplossingen die andere mensen hiervoor hadden zodat we dit grotendeels zouden kunnen gebruiken en dus niet nogmaals hetzelfde hoeven te ontdekken als deze mensen.

Gesprek met opdrachtgever Datum:

(vr) 25 mei 2012

Aanwezig:

Wim Antonissen (opdrachtgever), Frank Kaptein en Bert Lobbezoo)

Onderwerp: Vorderingen afgelopen week en actiepunten volgende week

In dit gesprek zijn de volgende dingen aan de orde gekomen: 1. Een belangrijke omschakeling in het ontwerp, de viewer moet namelijk hetzelfde scherm zien als de beheerder/administrator, met alleen het verschil dat hij of zij geen aanpassingen kan maken. Er komt dan een login

2.

3. 4.

5.

6.

functionaliteit voor planners en administrators zodat ze daarmee toegang krijgen tot extra functionaliteit in het programma. Er is dus slechts één executabel, waarvan de viewer én de administrator gebruik van maken. Actiepunten: a. De viewer moet alles kunnen zien. Dat betekent dat het programma speciaal bedoeld voor de viewer weg kan. Het programma bedoeld voor de beheerder moet zo gemaakt worden dat de viewer alles kan zien, en alleen iemand met een wachtwoord ook de planning daadwerkelijk kan veranderen. Eventueel kan de viewer voorstellen doen over veranderingen die hem en anderen beter uitkomen b. Er moeten meerdere databases komen. Deze moeten bewerkt kunnen worden met een nieuw/openen/opslaan knop in het bestand-menu. Alleen beheerders kunnen dit doen. Zij bezitten dan gelijk een beheerdersaccount voor deze databases, en kunnen naar gelang accounts aanmaken voor degene die ook beheerrechten mogen hebben voor deze subdatabase c. Zo wordt een hiërarchische structuur verkregen. Vervolgens is de vraag welke rechten de verschillende soorten gebruikers hebben. We moeten voor do 31 mei drie scenario’s uitwerken welke soorten gebruikers welke rechten hebben. d. Verder moeten we testen met mogelijke planningen, zoals taxiritten. Zo kunnen we achter eventuele onvolkomenheden komen e. Het moet mogelijk zijn om op events (de buttons in het grote scherm) te klikken. Het schermpje om activiteiten toe te voegen moet dan verschijnen, maar dan ingevuld met de informatie van het event waar op is geklikt f. Het moet mogelijk zijn om specifieke (planning gerelateerde) informatie over deelnemers toe te voegen De opdrachtgever heeft gevraagd om onze uren bij te houden. Hoe het product verkocht wordt, hoeven wij ons niet mee bezig te houden. Dat is de taak van de opdrachtgever. Concreet betekent dit dat wij geen rekening hoeven te houden tijdens het ontwerpen en implementeren met hoe het product het best verkocht kan worden De opdrachtgever gaf aan dat hij een grote toekomst zag voor de smartphone. Papier heeft veel nadelen, zoals achterhaalde info, verkeerde info, papieren raken door elkaar zodat je niet meer weet welke de goede is, de kosten voor inkt en papier en de milieuonvriendelijkheid. Daarom hoeft de planning niet uitgeprint te worden. De applicatie moet zo intuïtief mogelijk zijn, zodat de gebruiker op zijn smartphone kan kijken wanneer hij moet werken en met wie. Wim wilde graag het prototype op de server kunnen draaien. Zo kan hij het programma voorleggen aan mensen die eventueel geïnteresseerd zijn in het product, om zo feedback te verzamelen.

Week 6 Er is deze week geen bijeenkomst geweest. Wel hebben we een prototype opgestuurd. In plaats van de gebruikelijke bijeenkomstverslagen heeft deze week daarom een kort weekverslag.

Actielijst 1. View applicatie in algemene applicatie. 1.1 Login functionaliteit voor planners en/of admins. 2. De voorkant van de applicatie: nieuwe database creëren of bestaande database openen / opslaan. 1.2 Mogelijkheid nieuwe databases aan te maken voor beheerders. 1.3 Mogelijkheid een bestaande database te openen. 1.4 Opslaan gebeurt al automatisch.. 2. De hiërarchische structuur voor verschillende gebruikers (admin / planner / viewer). 3. Planning exporteren naar pdf. 4. Programma op server draaien.

Week verslag Voor deze week hebben we een prototype ingeleverd en een document gemaakt over de login hiërarchie van de applicatie. Dit verslag over de login hiërarchie gaat over de vraag wat voor verschillende gebruikers het programma kent en welke rechten deze verschillende gebruikers hebben in de applicatie. Het programma zal onderscheidt kunnen maken tussen deze verschillende gebruikers d.m.v. een inlogscherm waar gebruikers met speciale rechten hun gebruikersnaam en wachtwoord kunnen invoeren.

Verder is deze week ook weer een prototype opgestuurd. Wim heeft aangegeven dat het prototype voorlopig niet op de server kan draaien omdat het bedrijf de server aan het aanpassen is. Wim zal daarom het prototype op zijn eigen computer testen.

Week 7 Gesprek onderling Datum:

(wo) 06 juni 2012

Aanwezig:

Frank Kaptein en Bert Lobbezoo

Onderwerp: Vorderingen prototype deze week.

We hebben onderling een korte vergadering gehouden over welke acties we nu moeten nemen voor het prototype zodat we aanstaande vrijdag een goed functionerend prototype kunnen opsturen. We zullen samen met dit prototype ook de code dit weekend moeten opsturen naar zowel SIG van TU Delft als naar Wim Antonissen die er een programmeur van Tango naar zal laten kijken.

Voor het prototype van aanstaande vrijdag vonden wij het erg belangrijk om alle kernfunctionaliteiten van een planningsprogramma er goed functionerend in te hebben. We hebben daarom een lijstje gemaakt voor deze week met dingen die we er in moeten hebben voor het volgende prototype en dingen die we er binnen korte termijn (Het prototype hierna waarschijnlijk) in hebben willen zitten. Dit lijstje kunt u hieronder lezen:

In het hoofdscherm: 1. Activiteiten zijn zichtbaar in het datagrid maar de cellen hebben nu alleen een rode box die aantoont dat er een activiteit is. De gebruiker kan dan op deze box klikken om de activiteitsinformatie te zien maar wij willen voor vrijdag dat ook op het datagrid zelf al de naam van de activiteit te lezen is. 2. Deelnemers die niet staan ingepland zijn nu ook niet zichtbaar in het datagrid. In dit gesprek waren we het er snel over eens dat dit eigenlijk een gebrek is van het programma. We zullen dus op de verticale as alle deelnemers tonen (van het type dat de gebruiker heeft geselecteerd in de combobox voor de verticale as). In het ‘activiteit toevoegen scherm’:

1. Een al bestaande activiteit kan geopend worden via het datagrid. Deze activiteit kan echter nog niet gewijzigd worden door de gebruiker. Dit vonden wij ook een cruciaal gebrek voor het komende prototype. 2. Meerdere deelnemers tegelijk selecteren en toevoegen bij een activiteit werkte correct maar helaas is ergens in het proces van agile programmeren er een fout in geslopen. Dit willen we graag hersteld voor het volgende prototype. 3. De tijd is nu zichtbaar als deelnemer in het activiteit toevoegen scherm. Dit is contra-intuïtief en zullen we daarom ook wijzigen voor het komende prototype. 4. De boxen voor eindtijd en duur in dit scherm updaten elkaar nog steeds niet automatisch wanneer de gebruiker er iets invoert. In het startscherm: 1. De gebruiker kan bestaande databases openen maar we willen hem ook de mogelijkheid gaan bieden een nieuwe te creëren. Dit is, volgens ons, ook een cruciale functionaliteit voor het volgende prototype. Overig: Verder zijn er nog een aantal zaken die we niet in het aankomende prototype maar wel voor het prototype daarna willen:

1. Login informatie toevoegen was mogelijk maar gezien de ontwikkelingen en hiërarchie die we vorige week hebben moeten bedenken is ook de database structuur hiervoor aangepast. De functionaliteit moet daarom ook weer opnieuw worden gemaakt. 2. Het datagrid tekent niet helemaal goed wanneer er gescrolld wordt door de gebruiker. Dit is functioneel geen probleem maar oogt wel een beetje raar. 3. We willen gebruikers de mogelijkheid geven het datagrid te kunnen exporteren. Hier zijn we al mee begonnen maar er waren een paar complicaties die we liever pas wilden aanpakken wanneer de functionaliteiten in de bovenstaande lijstjes waren afgerond. 4. Als laatste willen we administrators de mogelijkheid bieden databases ook weer te verwijderen.

Gesprek met opdrachtgever Datum:

(do) 7 juni 2012

Aanwezig:

Wim Antonissen (opdrachtgever), Frank Kaptein en Bert Lobbezoo

Onderwerp: Bespreking prototype.

We hebben een skype gesprek gehad over het ingeleverde prototype. Wim heeft feedback gegeven, welke wij hieronder hebben gedocumenteerd.

-In het westen denken wij van links naar rechts dus de knop die de deelnemers instelt moet links (dus eigenlijk ‘eerst’) staan en de knop waarmee de gebruiker daadwerkelijk planningen maakt moet rechts staan. -De namen op de knoppen (namelijk: Deelnemers en Activiteiten) zijn eigenlijk niet intuïtief. Wim zal er over nadenken welke namen hier beter voor zouden zijn en zou hier later op terug komen. -‘Deelnemers’ moeten een beschrijving kunnen meekrijgen zodat de planner daarin kan aangeven of en zo ja wat voor voorwaardes deze deelnemer heeft in de planningen. - Er kunnen nu oneindig veel schermen worden geopend (zowel planningsschermen als bijvoorbeeld ‘deelnemers beheren’ schermen). Dit is niet wenselijk en hiervoor moeten we dus ook een oplossing vinden. -Wim wilde graag dat wanneer de gebruiker iets aanpast in een scherm dat dit direct ook op het datagrid te zien is. -Als laatste vertelde Wim ons dat het programma niet op de server kan draaien voorlopig omdat ze bezig zijn met wijzigingen doorvoeren op de server. Misschien dat het over een paar weken wel alsnog moet maar voorlopig test hij het programma op zijn eigen computer.

Week 8 To do list We hebben aan het begin van deze week weer een ‘to do lijst’ gemaakt. Het leek ons goed deze ook weer in het logboek op te nemen.

MUST 1) Afspraak met Pascal maken. (begin volgende week) 2) Afspraak met Wim maken voor deze week. 3) Nieuwe database maken netjes maken 3.1) Checken of naam al bestaat. 3.2) Deelnemers toevoegen. 3.3) Verversen datagrid, openen database. 4) Buttons op goede hoogte tekenen. 5) logboek updaten en opsturen. 6) Openen nieuwe database moet datagrid resetten. 7) Activiteits info toevoegen. 8) Activiteitsnaam kunnen wijzigen. 9) Inloggen voor admin en planner appart maken. (We gaan voorlopig van 1 bedrijf uit) 10) Hoveren van muis opent infobox.

SHOULD 1) Tijden niet voorgeprogrammeerd. 2) Delete knopje herstellen in deelnemersbeheren scherm.

COULD

1) Deelnemers beheren scherm openen wanneer in datagrid op deelnemer wordt geklikt. 2) Bewerken van cellen en headercellen verbeteren. 3) Meerdere selecteren in datagrid moet goed gaan. 4) Exporteren van datagrid. (screenshot) 5) Het resizen probleem op lossen.

WON'T (Taken die, in principe, voor volgende week zijn.) 1) Tijden kunnen instellen. 2) Activiteiten op hetzelfde tijdstip overdenken. 3) Exporteren datagrid. (met schaal (Een bepaalde tijdsspan om te exporteren))

Gesprek met opdrachtgever Datum:

(di) 12 juni 2012

Aanwezig:

Wim Antonissen (opdrachtgever), Frank Kaptein en Bert Lobbezoo

Onderwerp: Bespreking prototype.

In dit gesprek hebben we wederom een prototype besproken. De volgende zaken zjin aan de orde gekomen:

-Het activiteiten scherm kan nu oneindig vaak geopend worden. Voor het volgende prototype moeten alle schermen een maximum aantal keer open kunnen. Dit houdt in dat in principe alle schermen 1 keer kunnen worden geopend. Omdat de gebruiker eventueel verschillende activiteiten wil kunnen openen om ze te kunnen vergelijken bij het inplannen mag het activiteitenscherm maximaal 3 maal geopend worden. -Het hiërarchie probleem is weer ter sprake geweest en er is afgesproken dat het programma 1 administrator zal kennen (en natuurlijk meerdere planners). -Wim wilde graag dat alle aanpassingen die in het deelnemersscherm werden gemaakt direct zichtbaar zouden zijn in het planningsscherm. Het moeten klikken op de opslaan knop vond hij hier niet nodig. -De naam voor de button die het activiteiten scherm moet openen is na overleg: ‘Welke, wanneer waar’ geworden. -Wanneer in het planningsveld meerdere deelnemers van het zelfde type (bijvoorbeeld meerdere schoonmakers) tegelijk staan ingepland kunnen niet alle namen zichtbaar zijn. De oplossing hiervoor zou zijn om na de naam van de eerst ingeplande schoonmaker een ‘*’ gevolgd door een getal te plaatsen. Dit getal geeft dan het aantal ingeplande schoonmakers aan.

De besproken zaken zullen op het to-do lijstje voor het volgende prototype komen te staan.

Week 9 Gesprek met opdrachtgever Datum:

(di) 19 juni 2012 (11:00)

Aanwezig:

Wim Antonissen (opdrachtgever), Frank Kaptein en Bert Lobbezoo

Onderwerp: Bespreking prototype.

In deze week is er een probleem naar voren gekomen in het functionele ontwerp dat ons geschetst is. Om dit probleem uit te leggen moeten we ons verplaatsen in de gebruiker. In het prototype zoals het nu is kan de gebruiker activiteiten toevoegen op een bepaald tijdstip en deze activiteiten vullen met deelnemers.

Als we nu het voorbeeld van een restaurant nemen hebben we te maken met tafels, obers en gasten. Het meest intuïtieve voor de planner is nu om een ober aan een aantal tafels te koppelen op een dag en zo nu en dan een gast aan zo’n tafel te koppelen. Met het huidige prototype is dit echter niet mogelijk omdat alle deelnemers in een activiteit, de zelfde tijdsduur hebben in deze activiteit. (namelijk de volledige tijdsduur van de activiteit zelf.)

Er zijn een aantal oplossingen bedacht in dit gesprek. De eerste oplossing was om iedere deelnemer een eigen tijdsduur te geven in een activiteit. Het grootste probleem van deze oplossing zit hem in het datagrid. De gebruiker krijgt dan een grote activiteit te zien voor de hele dag en als hij hier gasten aan toevoegt kan hij niet in één oogopslag zien wanneer deze gasten zijn ingepland. Ook kan hij niet in het datagrid al klikken op het tijdstip dat hij de klant wil toevoegen waardoor het plannen volledig plaatsvindt in het activiteiten scherm.

De volgende oplossing was hoopgevender. Het idee was om, als planner, subactiviteiten te kunnen creëren. Aan de grote activiteit van ober en tafel kunnen dan meerdere gast activiteiten worden toegevoegd.

Deze laatste oplossing zullen wij deze week proberen te implementeren.

Gesprek met begeleider Datum:

(di) 19 juni 2012 (15:00)

Aanwezig:

Pascal Wiggers (begeleider), Frank Kaptein en Bert Lobbezoo

Onderwerp: Bespreking verslag en presentatie.

In dit gesprek hebben we wat organisatorische zaken besproken. Het verslag moet (zonder bijlagen) zo’n 10-15 pagina’s bevatten. We missen verder nog 1 belangrijke bijlage namelijk het RAD document.

Voor het RAD document hebben we afgesproken het designdocument te gebruiken dat we wekelijks updaten. In dit design document moeten dan wel nog UML diagrammen worden toegevoegd.

We hebben het verder ook nog over de datum van de eindpresentatie gehad. Deze zal waarschijnlijk op 23 juli in de middag plaats gaan vinden.

Gesprek met opdrachtgever Datum:

(vr) 22 juni 2012

Aanwezig:

Wim Antonissen (opdrachtgever), Frank Kaptein en Bert Lobbezoo

Onderwerp: Bespreking prototype.

Wim wilde nogmaals met ons afspreken om een oplossing te bespreken die hij had bedacht voor het besproken probleem van het vorige gesprek. Wij hadden net de subactiviteiten geïmplementeerd maar deze zagen er wel wat rommelig uit en leken ons achteraf ook inderdaad niet de meest ideale oplossing.

Wim sprak in dit gesprek over het kunnen zien van de bezetting van deelnemers. Dit zou een aparte knop in de horizontale combobox moeten zijn die de gebruiker dan kan indrukken om voor iedere deelnemer te kunnen zien wat zijn bezetting is. Wij

hebben deze gedachtegang opgepakt en tijdens dit gesprek geprobeerd er achter te komen hoe Wim dit precies voor ogen zag en wat wij aan het idee moesten toevoegen / verwijderen om het te laten werken voor de applicatie. Het idee dat hieruit voortkwam was om in plaats van het oorspronkelijke idee dat steeds 1 type deelnemer (bijvoorbeeld ‘schoonmakers’) tegenover 1 ander type deelnemer te zien is (bijvoorbeeld ‘tafels’) nu de view zo te maken dat de gebruiker meerdere deelnemers tegelijk kan zien. Hierdoor kan hij de totale bezetting zien (door alle deelnemers zichtbaar te laten zijn) of een gedeeltelijke bezetting.

Het (uitgewerkte) idee is te vinden in het design document. Wim heeft aangegeven dat we de andere actiepunten voor het prototype moeten laten liggen en deze functie prioriteit moeten geven.

Week 10 Weekverslag Deze week zijn we druk aan de slag gegaan met het implementeren van de bezettingsknop. We zijn deze week verder tot een belangrijke conclusie gekomen wat betreft het design. De bezettingsview zoals beschreven in het laatste gesprek geeft inderdaad de gebruiker de mogelijkheid om de bezetting te zien maar kost overzicht op andere planningsmomenten. We willen de gebruiker de mogelijkheid geven om de kunnen wisselen tussen de bezettingsview en de ‘normale’ view zodat hij van beide implementaties de voordelen kan benutten.

Week 11 Gesprek met opdrachtgever Datum:

(di) 3 juli 2012

Aanwezig:

Wim Antonissen (opdrachtgever), Frank Kaptein en Bert Lobbezoo

Onderwerp: Bespreking prototype.

In dit voorlaatste gesprek met Wim Antonissen hebben we de implementatie van de bezettingsview besproken. Wim was erg tevreden over de functionaliteit en het kunnen wisselen tussen de bezettingsview en de ‘normale’ view. In dit gesprek heeft Wim de laatste paar kleine dingen voor het prototype genoemd waarvan hij graag wilde dat we het zouden implementeren.

Actielijst gesprek •

• • • • •

Wanneer de gebruiker op het planningsschema klikt wordt het activiteit toevoegen scherm geopend. Wanneer de gebruiker op deze manier dit scherm opent kan direct worden geselecteerd dat hij/zij bijvoorbeeld ‘tafels’ wil inplannen omdat de gebruiker klikte op de rij met ‘tafels’. Dubbelklikken op een deelnemer in het activiteit toevoegen scherm moet deze deelnemer toevoegen aan de activiteit. Tijd in het planningsview moet nog een kleine lay-out aanpassing hebben. Verschillende kleuren voor verschillende activiteiten voor meer overzicht. Activiteiten Scherm ‘resizeble’ + onthouden grootte bij opnieuw openen. Alle lay-out instellingen die de gebruiker had toen hij het programma de vorige keer opende onthouden. De gebruiker kan dan snel en eenvoudig verder waar hij/zij was gebleven.

Gesprek met opdrachtgever Datum:

(za) 7 juli 2012

Aanwezig:

Wim Antonissen (opdrachtgever), Frank Kaptein en Bert Lobbezoo

Onderwerp: Bespreking prototype en afsluiting project.

De laatste actiepunten zijn geïmplementeerd. We hebben bij dit gesprek nog eenmaal het programma naar Wim opgestuurd en de aankomende eindpresentatie besproken.

Bijlage V - Design document

Ontwikkeling in design

Bron: http://wvzandvoort.nl/wp-content/uploads/2012/03/klussen1.jpg

Door: Bert Lobbezoo Frank Kaptein

Inhoudsopgave Inhoudsopgave ......................................................................................................... 78 Inleiding .................................................................................................................... 79 De Graphic User Interface........................................................................................ 80 Week 0 ................................................................................................................. 80 Week 1 ................................................................................................................. 82 Week 2 ................................................................................................................. 84 Week 3 ................................................................................................................. 87 Week 4 ................................................................................................................. 90 Week 5 ................................................................................................................. 91 Week 6 ................................................................................................................. 95 Week 7 ................................................................................................................. 96 Week 8 ................................................................................................................. 99 Week 9 ............................................................................................................... 102 Week 10 ............................................................................................................. 103 Week 11 ............................................................................................................. 105 De database ........................................................................................................... 106 Iteratie 1.............................................................................................................. 106 Iteratie 2.............................................................................................................. 106 Iteratie 3.............................................................................................................. 107 Iteratie 4.............................................................................................................. 108 UML diagram .......................................................................................................... 109

Inleiding In dit verslag zal te zien zijn hoe het ontwerp van de database en de GUI is ontwikkeld. Steeds wanneer er significante verschillen zijn in ontwerp zullen wij dit tonen aan de hand van screenshots van het programma en een korte uitleg over waarom de aanpassingen gemaakt zijn.

De Graphic User Interface Week 0 Hier zijn een aantal screenshots van het prototype van Maarten van Zomeren. Dit is het prototype dat verbeterd en uitgebreid moet worden.

Week 1 Nu zullen we de eerste ontwerpen voor het nieuwe prototype tonen.

Dit was het eerste idee. Een activiteitenscherm waarin de activiteiten worden getoond als balkjes met een bepaalde grootte. Links staan de verschillende activiteiten die het scherm laat zien. Al snel kwamen hier de deelnemer balken bij. De deelnemerbalk linksonder toont de content van de y-as. De deelnemerbalk bovenin toont de content van de cellen in de tabel. Op de x-as staat in dit ontwerp altijd tijd.

Als laatste iteratie in deze week werd de menubalk voltooid en de inhoud van het scherm verbeterd.

Week 2 In deze week zijn er meer schermen bij gekomen behalve alleen het hoofdscherm. Hoofdscherm

Activiteit toevoegen scherm

Deelnemers werden hier toegevoegd in een panel zodat het scherm ook werkt wanneer de planner met erg veel verschillende deelnemers werkt. Deelnemerscherm

Dit scherm is bereikbaar vanaf de menubalk. Hier kan de planner soorten deelnemers toevoegen (of selecteren uit de combobox) en specifieke deelnemers onder zo’n categorie (type deelnemer) toevoegen. Deelnemerscherm

In dit nieuwe verbeterde scherm werd het intuïtiever hoe deelnemer types en deelnemers werden toegevoegd. In de listbox waren de namen van de deelnemers, van het type geselecteerd in de combobox ‘type deelnemer’, te zien. Het voordeel hiervan is dat de planner kan zien dat zijn deelnemer daadwerkelijk is toegevoegd.

Week 3 Na overleg met de opdrachtgever zijn er weer nieuwe ideeën ontstaan over het ontwerp voor de GUI. Wat de opdrachtgever vooral belangrijk vond was om een groot planningsscherm te hebben. Hoofdscherm

Het deelnemers scherm kan worden bereikt vanaf de rood omcirkelde menuknop. Het deelnemersscherm heeft deze week een verandering in design ondergaan.

Deelnemerscherm

Activiteit toevoegen scherm

Dit nieuwe ontwerp maakt het overzichtelijker wat je wilt toevoegen of verwijderen. Dit is nu alleen wel een onvolledig ontwerp waar we volgende week mee verder

gaan.

Week 4 Het activiteit toevoegen scherm is verder uitgewerkt naar het nieuwe ontwerp dat wij vorige week geïntroduceerd hebben. Activiteit toevoegen scherm

Week 5

In het korte skype overleg van maandag (22-05-2012) heeft de opdrachtgever ons een nieuwe visie over het design gegeven. Het idee is dat de afstand tussen de verschillende knoppen en het datagrid zo klein mogelijk moet zijn. Hoofdscherm

Oorspronkelijk zouden de knoppen en de comboboxen onderaan het scherm moeten komen zodat de layout eventueel ook verder ontwikkeld zou kunnen worden naar tablets. Wanneer het datagrid echter gevuld is staat de data van boven naar beneden in het datagrid. Zolang de applicatie muisbediend wordt is het daarom logischer de knoppen boven te hebben (dan is de afstand van de knoppen naar de data in het datagrid het kleinst). In het deelnemersscherm is de mogelijkheid toegevoegd om van bestaande deelnemers de naam of het type te wijzigen. Ook is het mogelijk een deelnemer een gebruikersnaam en wachtwoord te geven welke hij dan kan gebruiken om in te loggen bij de view applicatie. Het design van de view applicatie staat na het deelnemersscherm ook in het design verslag van deze week.

Deelnemerscherm 1

Deelnemerscherm 2a

Deelnemerscherm 2b

De view applicatie zal er als volgt uitzien: Hoofdscherm view applicatie:

Login scherm:

Week 6 Wim wilde dat de view applicatie en de hoofdapplicatie 1 programma werden. De ‘login knop’ is daarom verplaatst naar de hoofdapplicatie en de deelnemers en activiteiten knoppen worden pas beschikbaar wanneer de gebruiker inlogt.

Week 7 Deze week zijn er een aantal dingen veranderd in design. Ten eerste noemde Wim een kleine verandering in het hoofdscherm. De deelnemers beheren knop moest namelijk links staan in het scherm omdat de gebruiker begin met instellen wat hij wil kunnen plannen voordat hij daadwerkelijk activiteiten gaat inplannen.

Het deelnemersscherm moest in staat zijn om deelnemertypes te wijzigen en om zowel deelnemertypes als deelnemers een beschrijving mee te geven die de gebruiker kan gebruiken om specifieker te plannen. In zo’n beschrijving zou bijvoorbeeld kunnen staan dat een werknemer slechts 32 uur in de week werkt in

plaats van de gebruikelijke 40.

Als laatste is er ook een ‘voorkant’ in de applicatie gekomen. Een startscherm waarin de gebruiker planningen kan open of aanmaken.

Week 8 In deze week had Wim nieuwe namen voor de activiteiten en deelnemersschermen bedacht. In een skype gesprek hebben we deze namen besproken en uitgewerkt. Het design van de schermen is daarom iets aangepast. Waar normaal deelnemers stond staat nu de vraag: Wat wilt u plannen? En waar activiteiten stond staat nu de vraag: Wie, welke, wanneer.

Ook hebben we geëxperimenteerd met verschillende ontwerpen voor het activiteitenscherm. Het oude ontwerp en twee nieuwe ontwerpen zullen we laten zien in dit document.

Oud:

Nieuwe ontwerpen:

Het laatste ontwerp hebben we voorlopig gekozen. Het nadeel van dit ontwerp is dat het erg druk wordt in het scherm. Het voordeel is dat het intuïtiever werkt dan de andere ontwerpen en minder ruimte op het scherm van de gebruiker in beslag neemt.

Week 9 De onderstaande tekst is ook in het logboek opgenomen en staat hier nogmaals ter verduidelijking van het design probleem dat hier naar voren was gekomen. In deze week is er een probleem naar voren gekomen in het functionele ontwerp dat ons geschetst is. Om dit probleem uit te leggen moeten we ons verplaatsen in de gebruiker. In het prototype zoals het nu is kan de gebruiker activiteiten toevoegen op een bepaald tijdstip en deze activiteiten vullen met deelnemers. Als we nu het voorbeeld van een restaurant nemen hebben we te maken met tafels, obers en gasten. Het meest intuïtieve voor de planner is nu om een ober aan een aantal tafels te koppelen op een dag en zo nu en dan een gast aan zo’n tafel te koppelen. Met het huidige prototype is dit echter niet mogelijk omdat alle deelnemers in een activiteit, de zelfde tijdsduur hebben in deze activiteit. (namelijk de volledige tijdsduur van de activiteit zelf.) Er zijn een aantal oplossingen bedacht in dit gesprek. De eerste oplossing was om iedere deelnemer een eigen tijdsduur te geven in een activiteit. Het grootste probleem van deze oplossing zit hem in het datagrid. De gebruiker krijgt dan een grote activiteit te zien voor de hele dag en als hij hier gasten aan toevoegt kan hij niet in één oogopslag zien wanneer deze gasten zijn ingepland. Ook kan hij niet in het datagrid al klikken op het tijdstip dat hij de klant wil toevoegen waardoor het plannen volledig plaatsvindt in het activiteiten scherm. De volgende oplossing was hoopgevender. Het idee was om, als planner, subactiviteiten te kunnen creëren. Aan de grote activiteit van ober en tafel kunnen dan meerdere gast activiteiten worden toegevoegd. Deze laatste oplossing hebben wij geïmplementeerd. Verder hebben we ook een exporteer functie geïmplementeerd die het zichtbare datagrid met kader en naam van de planning opslaat. Hieronder is een plaatje zichtbaar van de subactiviteiten gecreëerd met deze export functie.

Week 10 De subactiviteiten zagen er naar onze en naar Wim zijn mening niet erg goed uit. Ze lossen het besproken probleem wel op maar kosten erg veel overzicht voor de gebruiker. Er was dus behoefte aan een alternatieve oplossing. Deze oplossing ging om een aparte knop in de horizontale combobox die de bezetting laat zien van alle deelnemers. De gebruiker kan deze dan indrukken om voor iedere deelnemer te kunnen zien wat zijn bezetting is. Wij hebben deze gedachtegang opgepakt en tijdens dit gesprek geprobeerd er achter te komen hoe Wim dit precies voor ogen zag en wat wij aan het idee moesten toevoegen / verwijderen om het te laten werken voor de applicatie. Het idee dat hieruit voortkwam was om in plaats van het oorspronkelijke idee dat steeds 1 type deelnemer (bijvoorbeeld ‘schoonmakers’) tegenover 1 ander type deelnemer te zien is (bijvoorbeeld ‘tafels’) nu de view zo te maken dat de gebruiker meerdere deelnemers tegelijk kan zien. Hierdoor kan hij de totale bezetting zien (door alle deelnemers zichtbaar te laten zijn) of een gedeeltelijke bezetting. De zichtbare deelnemers kunnen nu aangevinkt worden in de horizontale combobox.

In de geopende combobox kan de gebruiker aanvinken welke deelnemertypes hij/zij wil zien. In het datagrid zijn deze deelnemertypes zichtbaar.

We vinden deze implementatie nuttig voor het geschetste probleem in week 9 en beter dan de subactiviteiten maar hebben nog steeds het idee dat het overzicht slechter wordt wanneer de gebruiker erg veel heeft ingepland en veel verschillende deelnemertypes heeft. Een kleine aanpassing die we daarom zelf al zullen toevoegen is dat wanneer de gebruiker op ‘Bezetting’ klikt gaat hij terug naar de ‘normale view’.

Hierboven is een plaatje te zien van de ‘normale view’. Wanneer de gebruiker dus nogmaals op bezetting klikt zal de view weer verspringen naar de bezettingsview.

Week 11 Na het gesprek met Wim Antonissen van deze week is de functionaliteit van de bezettingsview definitief. Wim was blij met het kunnen wisselen tussen de verschillende views en was het hier dus met ons eens. Wel wilde hij nog graag verschillende kleuren zien bij verschillende deelnemers om het overzicht te verbeteren.

Deze kleuren hebben we met Wim besproken. Wim had nog twee kleine aanpassingen. Hij wilde de basis kleuren gebruiken en wilde dat alleen de activiteiten zelf een kleur hadden. Buiten de kleuren wilde Wim ook graag duidelijker zien welke rijen bij een specifieke deelnemer horen. De oplossing die we daarvoor aanboden was om de rij die de gebruiker geselecteerd heeft een grijzige achtergrond kleur te geven en de andere rijen behorende bij dezelfde deelnemer een (iets lichtere) grijze tint te geven.

De database De database structuur is minder aan verandering onderhevig dan de GUI dus we zullen deze per iteratie behandelen en niet per week.

Iteratie 1

Iteratie 2 Er was behoefte aan een view applicatie voor de werknemers. Deze werknemers moeten dan inloggen in de applicatie en kunnen hun eigen planningen zien. Er was

dus behoefte aan een tabel die deze informatie opslaat.

Iteratie 3 Op de horizontale as in zowel de hoofdapplicatie als de view applicatie moest standaard tijd komen te staan. De database kon dit ondersteunen door een aparte tijdstabel te maken.

Iteratie 4 Login informatie moest los staan van de databases voor planningen.

UML diagram Hieronder is een diagram van de voornaamste communicatie tussen de klassen in verschillende namespaces.

Bijlage VI – Hiërarchische inlogstructuur

Tango planner Hiërarchie van het inloggen

Bron: http://7gabriel73.punt.nl/upload/definition_de_la_hierarchie-custom-2.jpg

Door: Bert Lobbezoo Frank Kaptein

Inhoudsopgave Soorten gebruikers ................................................................................................. 112 Scenario’s .............................................................................................................. 113 Scenario 1 .......................................................................................................... 113 Scenario 2 .......................................................................................................... 113 Scenario 3 .......................................................................................................... 114

Soorten gebruikers Voor het inloggen bij de tango planner definiëren we in principe drie soorten gebruikers. Deze soorten zijn: 1. Administrator 2. Planner 3. Viewer

Voor deze verschillende gebruikers moet het programma ook verschillend functioneren. In dit korte verslag bespreken we welke rechten deze verschillende gebruikers moeten hebben en hoe het programma zal functioneren. Hieronder zullen we nu eerst deze verschillende gebruikers bekijken. We zullen bespreken wat hun functies voor de tango planner zijn en welke vragen er bij ons opkwamen voor deze gebruikers.

Administrator: Kan bij iedere database van een bedrijf inloggen. Administrator kan nieuwe accounts aanmaken voor andere planners. Administrator kan nieuwe databases aanmaken. (Dit is dan een ‘lege’ database met alleen de structuur er in. De planners en/of administrators kunnen dan deelnemers en parametrisatie toevoegen aan deze planning.) Keuzes: 1. Kunnen er meerdere administrators zijn? 1.1. Is er in dat geval behoefte aan een super administrator die als enige nieuwe administrators kan aanstellen of heeft iedere administrator dan de mogelijkheid dit te doen? Planner: Kan inloggen in een database om daar alle planningsgerichte zaken aan te passen. Keuzes: 1. Kan een planner nieuwe databases aanmaken? 2. Kan een planner nieuwe planners aanstellen? Viewer: Kan alleen zien wat er op de verschillende planningen staat.

Scenario’s In dit hoofdstuk zullen wij een paar verschillende mogelijkheden behandelen voor de inlogstructuur. Uit deze mogelijkheden zal de opdrachtgever een keuze maken welke dan door ons geïmplementeerd zal worden in het programma.

Scenario 1 Het scenario dat we hier schetsen gaat ervan uit dat administrators alle rechten hebben in deze applicatie. Zo’n administrator kan dus in iedere database inloggen die dit bedrijf heeft opgesteld en voor iedere database accounts voor planners toevoegen en verwijderen. Verder kunnen alle administrators andere administrator accounts toevoegen of verwijderen zolang er maar tenminste 1 administrator overblijft. Het maakt dan dus niet uit welke administrator dat is. De planners in dit scenario kunnen, in de database waarvoor ze een planner zijn, inloggen. Eenmaal ingelogd kunnen ze activiteiten en deelnemers beheren voor deze database. Planners kunnen andere planners aanstellen voor de database waar ze zelf planner van zijn. Viewers kunnen alleen de data zien die al in de database staat. Ze kunnen geen wijzigingen aanbrengen in de database. Alle gebruikers kunnen alle databases van 1 bedrijf zien.

Scenario 2 In het scenario dat we hier schetsen is het mogelijk een privé database aan te maken. In een privé database is de inhoud van de activiteiten verborgen. Administrators hebben als enige het recht om de inhoud van alle activiteiten in te zien. De viewers en planners kunnen dus wel zien dat er iets gepland staat maar ze kunnen niet zien wat. Wanneer een planner een nieuwe activiteit inplant is in principe alleen deze planner gerechtigd om de inhoud van zo’n planning te zien of te wijzigen. Viewers krijgen in een privé database ook een account om mee in te loggen. De viewers zijn gebonden aan een deelnemer (resource) en kunnen alleen de activiteitsinformatie zien van planningen waar ze zelf aan deelnemen.

Scenario 3 Een mogelijke variant is dat administrators geen planningsrechten hebben. Ze kunnen dan dus alleen accounts toevoegen of verwijderen. Verder zou het systeem dan functioneren zoals geschetst in de vorige twee scenario’s.