Planning applicatie Voor Tango

Transcriptie

1 Planning applicatie Voor Tango Frank Kaptein Bert Lobbezoo

2 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.

3 Inhoudsopgave Voorwoord... 2 Inhoudsopgave... 3 Inleiding... 4 Het te verbeteren prototype... 5 Iteratie I Verbeteringspunten van het oude prototype Verbeterpunten oude prototype Ontwerp... 8 Database... 8 Graphical user Interface... 9 Implementatie Iteratie II De toevoegingen Analyse verbeterpunten voor vorige iteratie De viewer Deelnemers beheren De voorkant van de applicatie Ontwerp De viewer Deelnemers beheren De voorkant van de applicatie Iteratie III Het bezettingsprobleem Analyse verbeterpunten voor vorige iteratie Ontwerp Conclusies & aanbevelingen Bijlage I - Opdracht omschrijving Bijlage II - Plan van Aanpak Bijlage III - Oriëntatieverslag Bijlage IV - Logboek Bijlage V - Ontwikkeling in design Bijlage VI - Hiërarchische inlogstructuur Alle bijlagen van het verslag zijn ook te vinden in het bijbehorende mapje van de meegeleverde zip file.

4 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.

5 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.

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

7 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.

8 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.

9 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.

10 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:

11 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.

12 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

13 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:

14 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.

15

16 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.

17 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

18 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.

19 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.

20 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 Wim Antonissen Maarten@curiehom.nl w.antonissen@tangoas.nl

21 Bijlage II - Plan van aanpak Plan van aanpak bron: werkwijze.jpg Door: Bert Lobbezoo Frank Kaptein

22 Inhoudsopgave 1. Introductie Aanleiding Accordering en bijstelling Toelichting op de opbouw van het plan Projectopdracht Projectomgeving Doelstelling project Opdrachtformulering Op te leveren producten en diensten Eisen en beperkingen Cruciale succesfactoren Aanpak Het plan van aanpak Orientatiefase Ontwikkelingsfase Voorbereidingsfase... Fout! Bladwijzer niet gedefinieerd Ontwerpfase... Fout! Bladwijzer niet gedefinieerd Implementatiefase... Fout! Bladwijzer niet gedefinieerd Testfase... Fout! Bladwijzer niet gedefinieerd. 3.4 Afrondingsfase Projectinrichting en voorwaarden Plannen Planning Mijlpalenplan... 31

23 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.

24 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.

25 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.

26 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.

27 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.