Logistiek Management Systeem. Het ontwerpen, ontwikkelen en implementeren van een logistiek management systeem

-1-

Logistiek Management Systeem. Het ontwerpen, ontwikkelen en implementeren van een logistiek management systeem.

Gert-Jan Stolk 0753877

8 februari 2005

Gemaakt bij de opleiding Informatica, Hogeschool Rotterdam, begeleid door docent C. Stolk, uitgevoerd bij bedrijf Care2Move van Breugel.

-2-

1 Samenvatting Dit verslag gaat erop in hoe ik de problemen binnen de logistieke afdeling van het bedrijf 'Care2Move' van Breugel gepland hebt aan te pakken met behulp van de invoering van een nieuw informatie systeem. Het uiteindelijke verloop van het ontwikkelen van het informatiesysteem blijkt uiteindelijk op een aantal essentiële punten af te wijken van het ontwerp van het systeem.

-3-

2 Inhoudsopgave 1. 2. 3. 4.

5.

6.

7.

8. 9.

Samenvatting.................................................................................................................. 3 Inhoudsopgave............................................................................................................... 4 Inleiding.......................................................................................................................... 5 BedrijfsOriëntatie............................................................................................................ 6 Het bedrijf .................................................................................................................... 6 De geschiedenis........................................................................................................... 6 De core-business......................................................................................................... 6 De bedrijfsstructuur...................................................................................................... 6 De bedrijfscultuur......................................................................................................... 7 De positie in de omgeving............................................................................................ 7 Eigen positie................................................................................................................. 7 De voorbereiding............................................................................................................ 8 Huidige situatie............................................................................................................. 8 Gewenste situatie......................................................................................................... 8 Overwegingen.............................................................................................................. 9 Alternatieven en Aanbevolen keuze............................................................................. 9 Aanpak......................................................................................................................... 9 Globale Opzet............................................................................................................ 10 Verdere uitwerking..................................................................................................... 10 De systeemontwikkeling............................................................................................... 11 Het ontwikkelproces................................................................................................... 11 Het implementatie proces........................................................................................... 12 Post-implementatie..................................................................................................... 12 Reflectie........................................................................................................................ 14 Leerdoelen................................................................................................................. 14 Reflectie op afzonderlijke leerdoelen......................................................................... 14 Leer punten................................................................................................................ 15 Conclusie...................................................................................................................... 17 Bijlagen......................................................................................................................... 18 Leerdoelen................................................................................................................. 19 Eisenlijst..................................................................................................................... 21 Voorbereidend UML ontwerp..................................................................................... 26 Definitieve UML Ontwerp........................................................................................... 46 Database ERD........................................................................................................... 50 Product Screenshots.................................................................................................. 52 Logboek..................................................................................................................... 56 Urenverantwoording................................................................................................... 66

-4-

3 Inleiding Na twee jaar informatica op het rivio werd het tijd voor een stage. Na bij een aantal bedrijven gesolliciteerd te hebben lag de stage dichterbij dan verwacht. Het bedrijf van Breugel 'Care2Move', waar ik al twee jaar als logistiek medewerker werk, bood me onverwachts een stage opdracht aan. Namelijk het opzetten van een informatiesysteem voor de logistieke afdeling. De opdracht had nog wel wat haken en ogen omdat alle aan informatica gerelateerde processen binnen het bedrijf uitbesteed zijn, dat wil zeggen dat er geen deskundige begeleiding zou zijn. Maar omdat ik zelf goed op de hoogte was van de processen in en om het magazijn en de problematiek daarbij, nam ik de opdracht graag aan om een bijdrage te leveren in een oplossing. Bovendien geeft deze stage opdracht in deze situatie goede mogelijkheden om het hele software ontwerpproces door te lopen en vanwege de afwezigheid van deskundige begeleiding eens flink de fout in te gaan. Kortom een goede leerervaring. Dit stageverslag gaat in op de problematiek die binnen de logistieke afdeling van 'Care2Move' van Breugel, de oplossingen voor deze knelpunten, en hoe de software die hulp moet bieden bij het oplossen van de problemen tot stand is gekomen. Uiteindelijk volgt er nog een beschrijving wat deze ervaring voor mij en mijn leerdoelen betekend heeft. Het is handig om wat basiskennis te hebben over het ontwerpen van een informatiesysteem voor het lezen van dit verslag, maar het is niet noodzakelijk.

-5-

4 BedrijfsOriëntatie Het bedrijf Op het industrieterrein Hordijk – West aan de Hekendorpstraat in de buurt van de plaatsen Rotterdam – IJsselmonde – Ridderkerk – Barendrecht, is het bedrijf van Breugel ‘Care2Move’ gevestigd. Van Breugel 'Care2Move' opereert in de branche voor mobiliteitshulpmiddelen en zorgproducten, het is aangesloten bij een overkoepelende organisatie met de naam `Care2Move’. Bij deze organisatie zijn ook vele andere bedrijven aangesloten zoals Breva (Dordrecht), Jeremiasse (Middelharnis, Goes en Vlissingen), Arcof (Rotterdam) en Ligtvoet (Hengelo, Nijmegen, Uden, Venlo, Heerlen en Waalre). Alle bedrijven opereren; én onder hun eigen naam én onder de naam van de groep. Alle bedrijven zijn herkenbaar aan dezelfde huisstijl. De geschiedenis Het bedrijf is in 1967 begonnen als Teunissen rolstoel techniek, later is dit bedrijf overgenomen door Gerrit van Breugel. Onder leiding van van Breugel heeft het bedrijf een flinke groei doorgemaakt. Het bedrijf is gegroeid van 3 naar 30 werknemers. Ook de activiteiten in de zorg hulpmiddelen branche zijn gegroeid. Vroeger bestond het assortiment alleen uit rolstoelen, tegenwoordig levert van Breugel alles op het gebied van zorg hulpmiddelen, van rolstoelen tot po-stoelen tot Hoog-Laag bedden tot til liften. Ook voor ADL (Algemene Dagelijkse Levensverrichtingen) hulpmiddelen is van Breugel een goed adres. De core-business Van Breugel ‘Care2Move’ is een leverancier van allerlei soorten producten die te maken hebben met mobiliteit, zorg, verpleging en ADL (Algemene Dagelijkse Verrichtingen) hulpmiddelen. De bedrijfsstructuur Van Breugel ‘Care2Move’ is grofweg opgedeeld 4 groepen, dat zijn financieel secretarieel, verkoop, logistiek en technische dienst.

Directie

Financieel Secretarieel

Verkoop

Verkoop

Logistiek

Technische Dienst

Adaptatie

De bedrijfscultuur Van Breugel staat bekend als een bedrijf met een goede werksfeer en veel persoonlijke aandacht voor de klant. De doelstelling klant tevredenheid staat daarom samen met het maken van winst op nummer één. De directie probeert ook een ontspannen sfeer te -6-

houden in het bedrijf. De vormen van communicatie binnen het bedrijf zijn over het algemeen informeel wat de sfeer ten goede komt, afgezien van een lichte rivaliteit tussen afdelingen. De positie in de omgeving De deelname aan de ‘Care2Move’ groep vermindert de bewegingsvrijheid van het bedrijf. Ieder lid van de ‘Care2Move’ groep heeft zo zijn eigen verzorgingshuizen, ziekenhuizen en recent ook zorg verzekeraars als klant. Een stil zwijgende afspraak is; dat de leden niet onderling gaan concurreren, omdat één van de doelen van de ‘Care2Move’ groep is gezamenlijk; te concurreren tegen andere grote bedrijven zoals Welzorg, Harting Bank, RSR, Beenhakker en Revacore. Eigen positie Nu rest natuurlijk nog de vraag wat een student informatica in een hierboven beschreven bedrijf zoekt. Ik werkte oorspronkelijk al twee jaar bij dit bedrijf als logistiek medewerker. Dat hielt voor mij in dat ik voornamelijk werkzaam was op zowel de logistieke als de technische afdeling. Toen men erachter kwam dat ik nog op zoek was naar een stage werd mij een stage opdracht aangeboden, namelijk het maken van een management systeem voor de logistieke afdeling. Op het moment is er geen goed informatiesysteem beschikbaar voor de logistieke afdeling, wat inhoud dat er nergens wordt bijgehouden welke artikelen waar in het magazijn aanwezig zijn. Dit levert problemen op met betrekking tot het bijhouden van de voorraad. Er moet dus een goed informatie systeem komen met belangrijkste doel de magazijn voorraad bij te houden. Dit kan voor mij een bijdrage leveren in zaken als het leren omgaan met wensen van klanten, het zelfstandig ontwikkelen van een informatie systeem die aan de verwachtingen van de klant voldoet en het zelfstandig onderzoek doen naar (voor mij) nieuwe technieken zoals het gebruik van barcodes.

-7-

5 De voorbereiding In dit hoofdstuk wordt besproken wat de motieven zijn voor het ontwerpen en implementeren van een nieuw informatiesysteem en welke stappen er als voorbereiding voor genomen zijn. Huidige situatie Op dit moment is de opslag van de logistieke afdeling grofweg opgedeeld in twee delen, te weten: het depot en het magazijn. Het depot bestaat uit voornamelijk volledige middelen van een aantal zorgverzekeraars, WVG Rotterdam (wet voorzieningen gehandicapten) en een aantal eigen middelen voor bijvoorbeeld particuliere verkoop. Het magazijn bestaat uit een aantal schappen met de meest uiteenlopende onderdelen voor al de middelen die onder andere ook in het depot aanwezig zijn. Momenteel is het depot gedeelte nog goed te overzien. Alle middelen worden door de eigenaar of door de logistieke afdeling bijgehouden (met behulp van excel bestanden). Alle stellingen en losse middelen zijn genummerd. Eigenlijk weet alleen de werknemers van de logistieke afdeling precies hoe het systeem werkt. Dit klinkt misschien in eerste instantie nadelig, maar niets is minder waar als de situatie zo meteen van het magazijn bekeken wordt. Het depot systeem werkt namelijk -vrijwel- foutloos, maar kan wel tijdrovend zijn. Het beheer van het magazijn geeft eigenlijk één probleem wat zich op laat delen in meerdere oorzaken en gevolgen. Het probleem is dat er geen overzicht van de actuele voorraden zijn van het magazijn. Dit heeft als gevolg dat het magazijn niet aangevuld wordt wat vertraging teweeg brengt in de processen van de technische afdeling, die de grootste afnemer is van het magazijn. Ook resulteert dit in veel tijdverspilling doordat er veel tijd besteed moet worden aan het zoeken van een bepaald onderdeel (immers de plaatsing van een artikel wordt niet bijgehouden). Deze problematiek wordt onder andere veroorzaakt doordat het magazijn er bepaald niet netjes bij ligt. Dit komt omdat iedereen het magazijn maar in- en uitloopt (ook personeel van de technische afdeling) en zijn sporen nalaat van zijn zoektocht naar een bepaald artikel. Daar komt nog eens bij dat er een enorme verscheidenheid aan artikelen in het magazijn aanwezig is. Het enige waar men nog informatie kan krijgen van de inhoud van het magazijn zijn gegevens van de jaarlijkse telling. Dit is echter onnauwkeurig of gewoon onvolledig mede omdat het niet bepaald motiverend is om artikelen in een dergelijk rommelig magazijn te gaan tellen. Al met al werkt het wel, maar het zou vele malen sneller en preciezer kunnen en een veelheid aan fouten zouden voorkomen kunnen worden. Ook moet er vermeld worden dat er al wel een informatie systeem aanwezig is (MICOS; www.gmt.nl). Dit is echter voornamelijk voor de documenten stroom binnen en buiten het bedrijf bedoeld, er ontbreken een heel aantal belangrijke functies voor voorraad beheer. Gewenste situatie Men heeft al veel nagedacht over plannen om de situatie te verbeteren. Dit brengt termen als 'gesloten magazijn' en 'barcode registratie' naar voren. Inderdaad zou een gesloten magazijn al een hele verbetering zijn van de huidige situatie. Onder een gesloten magazijn verstaat men dat alleen logistieke medewerkers toegang hebben tot het magazijn. Dit beperkt dus het aantal personen die verantwoordelijk zijn voor hoe het magazijn erbij ligt. Hierdoor kan ook deze persoon de voorraad bijhouden. Dit alles heeft echter ondersteuning nodig van een goed informatiesysteem vanwege de grote variëteit aan artikelen. Het gebruik van barcodes is daarom in het geheel zo vreemd niet. Dit garandeert een stukje precisie en zekerheid doordat je geen foute artikelnummers kan overnemen. -8-

De situatie zou zo moeten worden dat de technische dienst een aanvraag doet naar een bepaald artikel, en dat vervolgens een logistiek medewerker het artikel uit de voorraad neemt en afboekt. Een dergelijk informatie systeem geeft meteen ook mogelijkheden om de voorraad op pijl te houden door bij ieder artikel een minimale voorraad aan te geven. Verder geeft dit de mogelijkheid om iedere afdeling een inzicht te geven in de aanwezige artikelen en kan men beter de in- en uitstroom van artikelen bijhouden wat ook boekhoudkundig interessant is. Dit geeft ook meteen te opening om dit systeem ook toe te passen op de depot middelen. Dit is voornamelijk bedoeld om het geheel eenduidig te houden, en efficiënter te maken (dmv het gebruik van barcodes). Overwegingen Het klinkt allemaal heel mooi, maar er zijn nog wel een aantal problemen te onderscheiden aan een dergelijk nieuw systeem. Het vergt namelijk een hoge mate van discipline om het systeem (virtuele voorraad) consistent te houden met de fysieke voorraad. Daarom zit er een bepaald risico aan verbonden om het magazijn geheel gesloten te houden voor iedereen behalve logistieke medewerkers. Door toedoen van ziekte of omdat men gewoon geen tijd heeft (het beheren van de voorraad is bepaald niet de enige taak van de logistieke afdeling) kan niet alleen leiden tot irritaties maar ook tot het niet bijhouden van het systeem wat met één actie het hele informatie systeem waardeloos maakt. De werking van het systeem vergt dus een stukje instelling en medewerking om staande te blijven. Verder kunnen de artikelen zelf niet van barcodes worden voorzien, de schappen worden daarom voorzien van barcodes, wat als gevolg kan hebben dat het verkeerde artikel aan de verkeerde code gekoppeld kunnen worden. Dit vereist dus oplettendheid van de gebruiker. Ook is het lastig om het hele magazijn in het systeem door te voeren omdat er sprake is van oude artikelen, halve (gedemonteerde) artikelen en bakken met gemengde artikelen. Dit zal een blijvend probleem vormen waarvoor geen direct sluitende oplossing gevonden kan worden. Op het moment accepteert men het gewoon dat deze artikelen gewoon niet of op een algemene manier worden ingevoerd omdat ze toch bepaald weinig gebruikt worden. Samengevat staat of valt het systeem met het gebruik ervan. Alternatieven en Aanbevolen keuze Eigenlijk zijn er niet direct alternatieven beschikbaar behalve op dezelfde voet doorgaan als dat er nu gedaan wordt. Een alternatief had bijvoorbeeld wel kunnen zijn om een bestaand systeem aan te schaffen. Het probleem is echter dat daar geen financiële middelen beschikbaar voor zijn als er geen zekerheid is van de werking ervan. Daarom is dit een soort goede gok waar weinig (financiële) risico's in zitten omdat het eigenlijk gewoon vrijwel gratis ontwikkeld wordt. Bovendien is men verzekerd van support omdat ik sowieso al bij van Breugel werk. Daarom is er voor gekozen om management software te schrijven met een centrale database zodat de voorraad op elke computer binnen (en later eventueel ook buiten) het bedrijf te raadplegen is. Alle artikelen en middelen van bepaalde depots moeten van barcodes worden voorzien voor de vlugge verwerking van de gegevens. Deze barcodes moeten ingelezen kunnen worden met een draadloze datacollector, zodat je niet afhankelijk bent van een bepaald fysiek bereik. Aanpak Er wordt in principe zonder vaste planning gewerkt, dit omdat er toch weinig speling is. Er kan geen extra manuren op het project gezet worden omdat ik als enige beschikbaar ben die de vaardigheden bezit om een hierboven geschetst systeem op poten te zetten. Daarom is er eerst een eisenlijst gemaakt waarin de prioriteiten van ieder onderdeel van het systeem aangegeven is, en in de volgorde van prioriteit zal het systeem dan ook ontwikkeld worden (bijlage 2). Al het overige wat niet afkomt kan eventueel later na de stage nog toegevoegd worden. -9-

Na het eisenpakket wordt er een UML ontwerp gemaakt. Dit ontwerp is in het begin voornamelijk een globale opzet, wat met latere inzichten verder uitgebreid wordt. Doordat ik alleen aan het systeem werk is het erg lastig om alle situaties en processen volledig te analyseren. Hierna kan begonnen worden aan het ontwikkelen van het systeem in volgorde van prioriteit. Uiteindelijk moet het systeem geïmplementeerd worden. Het implementeren wordt halverwege het ontwikkelproces gedaan vanwege de interne tijdpad van het bedrijf. Het is dus noodzakelijk om de functionaliteiten die voor het implementeren nodig zijn voortijdig af te hebben. De voorraadbeheer onderdelen moeten dus op tijd afgerond en getest zijn. Uiteindelijk moet er (eventueel buiten de stage) support geleverd worden voor het systeem. Globale Opzet Het te maken product wat de naam LMS (Logistiek Management Systeem) gaat dragen, moet grofweg de volgende functies omvatten. Voorraadbeheer: Dit omvat alle beheers functies voor de voorraad, wat dingen inhoud als het toevoegen en wijzigen van producten, groepen en leveranciers en het bijhouden van de kwantiteit van de voorraad. Verder moeten de artikelen die onder het minimale aantal komen duidelijk weergegeven kunnen worden om zo duidelijk te maken wat bijbesteld moet worden. Barcode systeem: Het systeem moet de mogelijkheid hebben om: barcodes te associëren met artikelen, vooraf gespecificeerde barcode scanners uit te lezen, barcodes af te drukken en barcodes te genereren. Import systeem: De bestaande artikel gegevens moeten overgebracht kunnen worden naar LMS om zo makkelijk artikel gegevens door te kunnen voeren en bestaande artikelen op te kunnen zoeken. Deze gegevens worden dus niet direct gebruikt, maar zijn meer een ondersteuning voor de artikel database van LMS. Export systeem: Dit heeft een minder hoge prioriteit, het gaat hier voornamelijk om het genereren van een excel bestand formaat die geïnterpreteerd kan worden door MICOS. Balans gegevens: Er moet een simpele vorm van een balans weergegeven kunnen worden voor de artikelen in het magazijn. Ook dit heeft een minder hoge prioriteit. Print functionaliteiten: Er moeten diverse pagina's uitgeprint kunnen worden, lage prioriteit. Voor een volledig overzicht zie bijlage 2 voor het eisenpakket. Verdere uitwerking Het systeem is verder uitgewerkt met behulp van UML modellen die bestaan uit Use-Case Diagrammen, een Class Diagram en Sequence Diagrammen. Al deze onderdelen zijn terug te vinden in bijlage 3. Het systeem zal verder gebouwd worden om een centrale (postgres) database, die op de server van het bedrijf zijn werk moet gaan doen (ERD, bijlage 5).

-10-

6 De systeemontwikkeling In dit hoofdstuk wordt besproken hoe het uiteindelijke informatiesysteem er inhoudelijk uitziet in vergelijking met het ontwerp en hoe het ontwikkeling- en implementatie proces ervan verlopen is. Er wordt voornamelijk aandacht besteed aan de volgorde van ontwikkeling- stappen, om een betere indicatie van tijd te krijgen kan het logboek geraadpleegd worden, zie bijlage 7. Het ontwikkelproces Het ontwikkelproces begon bij het maken van een eisenlijst en UML ontwerp. Dit is niet iets wat ik graag doe dus het was relatief snel afgerond (binnen een week, zie bijlage 3). Hierna ben ik direct overgegaan tot het ontwikkelen van het systeem, wat in principe voor een aantal weken voorspoedig verliep. Mijn ervaring met interfaces programmeren met java was niet echt groot, ik heb nooit echt meer ondernomen dan de standaard opdrachten van de programmeer modules op de HRO en wat andere kleine programma's. Hierdoor moest ik voortdurend java documentatie en voorbeelden doornemen voor het ontwikkelen van het systeem. Dit had verder weinig effect op de snelheid van ontwikkeling maar meer op latere toepassingen van bepaalde onderdelen. Bovendien veroorzaakt dit ook diverse afwijkingen op het vooraf gemaakte UML model, wat niet een groot probleem was omdat het uml model sowieso al vrij globaal opgezet was. De eerste grote verandering in het ontwerp trad op toen het idee voor het scannen van barcodes iets gewijzigd werd. Aanvankelijk was het idee om een draadloze scanner te gebruiken die direct zijn data door zou geven aan het systeem. Dit werd echter gewijzigd na een aantal gesprekken met de opdrachtgever. Deze wees erop dat een systeem waar direct extra gegevens bij de barcode ingevoerd konden worden (bijvoorbeeld het aantal artikelen die uit de voorraad wordt genomen) meer gewenst was. Dit veranderde het hele concept van een gewone barcode scanner naar een datacollector. Dit is een apparaat die de ingevoerde data (ingevoerd door beide een barcode scanner en toetsenbordje) eerst in zijn eigen geheugen opslaat en later in het systeem inleest. Dit was in principe niet zo een groot probleem, behalve dat een aantal grafische user interface onderdelen waardeloos werden. De keuze voor een scanner is uiteindelijk gevallen op een CipherLab 8001 (http://www.cipherlab.co.uk/products/pdt/8000.htm). Dit is een relatief goedkope datacollector die via een basis station (cradle) met een usb interface is aangesloten op de computer. Een volgend obstakel kwam aan het licht toen door de opdrachtgever geïnstrueerd werd dat er nog een aantal datavelden toegevoegd moesten worden voor depot middelen. Dit was een groter probleem dan verwacht wat toen veroorzaakt bleek te worden door een ontwerpfout. Het programma was totaal gefocust op de huidige datavelden en het zou erg veel werk kosten om er een aantal velden aan toe te voegen. Hierdoor ontstond het idee om de data die het systeem eerst direct uit de database haalde door middel van queries, om te zetten in een aparte database laag. Het idee was om in principe alleen de database laag aan te spreken vanuit de GUI, en dat alleen de database laag een verbinding met de daadwerkelijke database zou hebben. Zo kon in de database laag ook goed aangegeven worden welke datavelden de database tabellen zouden moeten bevatten, wat het systeem erg flexibel maakt. Dit was een grote afwijking van het originele UML ontwerp. Verdere vertragingen werden opgelopen doordat een deel van het ontwerp in het ontwikkelproces werd gedaan. Een voorbeeld daarvan is ook de kwestie met de barcodescanner/datacollector. Maar later trad een vergelijkbaar probleem op met betrekking tot -11-

het afdrukken van de barcode labels. Ik had van tevoren nog niet bedacht met wat voor apparatuur dit zou gebeuren. Het gevolg was dat het hele labelprint systeem halverwege het ontwikkelingsproces is ontworpen. Dit is op zich een erg prettige manier van werken echter niet zo efficiënt Op een moment waren de belangrijkste functies zo goed als af (maar nauwelijks getest). Er ontbraken echter nog een aantal essentiële onderdelen om het systeem te gaan implementeren. Toch was de implementatie van het systeem gewenst omdat het ondertussen tegen het einde van 2005 liep en de jaarlijkse magazijn telling voor de deur stond. Dit was direct een goed moment om het systeem te implementeren door alle artikelen toe te voegen. Ik was hier zelf niet echt gelukkig mee omdat het systeem niet echt voldoende getest was dus ik heb de laatste dagen voor de telling besteedt aan het stabiliseren en testen van het systeem. Het implementatie proces Voor het implementeren was het systeem wel redelijk voorbereid. De enige functie die eigenlijk nog ontbrak was dat de datacollector nog niet uitgelezen kon worden. Dit onderdeel heb ik nog tijdens het implementeren ontwikkeld. Alle mutaties in aantallen werden daarvoor met de hand op papier bijgehouden, zodat deze achteraf doorgevoerd konden worden. Dit was niet ideaal maar er was even niets anders voor handen en zou in theorie moeten werken. In de praktijk raakten de lijsten met wijzigingen kwijt en hadden we dus een probleem. Het implementeren ging volgens een andere methode dan ik zelf in gedachte had. Het originele plan was om alle stellingen systematisch af te lopen en alle artikelen in te voeren zodat er direct een goede basis was en alle artikelen van een barcode voorzien zouden kunnen worden. Dit bleek echter niet mogelijk met betrekking tot de beperkte tijd en mankracht. Er waren slechts 3 dagen vrij gemaakt voor het tellen en het tellen moest door het huidige personeel gedaan worden naast hun normale werkzaamheden. Daarom zijn de originele tellijst lijsten van de vorige jaren aangehouden en doorgevoerd in het systeem met de juiste aantallen en plaatsingen. Vervolgens is het de bedoeling dat ieder artikel dat nog niet in het systeem zit, ingevoerd zal wordt wanneer er een handeling mee wordt verricht (ie voorraad aanvullen of uit de voorraad nemen). Op deze manier zou de geregistreerde voorraad steeds meer overeen moeten komen met het fysieke voorraad. Op deze manier is het systeem minder nauwkeurig maar het is 'werkbaar'. Uiteindelijk zijn van alle ingevoerde artikelen barcodes uitgedraaid en is het magazijn van barcode labels voorzien. Het systeem draait nu volledig en het bestelsysteem is in gebruik. Post-implementatie Nadat het systeem een tijdje draaide zijn er nog een aantal complicaties opgetreden. Het eerste probleem dat zich voordeed was dat de mazijnbeheerder de eerste paar keer vergat de waardes door te voeren na ze ingelezen te hebben met de datacollector. Het programma geeft namelijk eerst een lijst weer met hetgeen uitgelezen is van de datacollector. Deze kan eventueel nog gewijzigd worden, en uiteindelijk moet het geaccordeerd worden door op een knop te drukken. Dit accorderen werd vergeten. Verder zaten er nog een paar kleine fouten in het systeem, waarvan er een vrij kritiek was. Deze fout bestond er uit dat de wijziging van een groep op een verkeerde groep doorgevoerd werd. Het gevolg was dat alle artikelen opeens tot een verkeerde groep behoorde. Door de structuur van de database was de schade redelijk makkelijk te herstellen, en de fout was vlug gerepareerd. Ik ben na het implementeren verder gaan werken aan nieuwe functionaliteiten van het programma. Ook hier ging het op een moment fout. Bij het introduceren van een nieuwe versie met een aantal kleine verbeteringen en een stel nieuwe functies was het mechanisme defect geraakt waarmee er nieuwe artikelen aangemaakt kunnen worden. De introductie van deze nieuwe versie was nogal last-minute werk waardoor er blijkbaar dus -12-

niet intensief genoeg getest was. Door goed versie beheer kon het probleem simpel opgelost worden door een rollback te doen naar een oudere versie. Het programma wordt vanaf een netwerk schijf geladen dus updates hoeven maar op een plaats doorgevoerd te worden. Na het repareren van deze fout is uiteindelijk deze nieuwe versie alsnog doorgevoerd. Het is nu de bedoeling dat ik ook na deze stage door blijf werken aan het programma. De meest noodzakelijke functies zijn voltooid. Maar er zijn toch nog een heel aantal functies die nog toegevoegd kunnen worden, wat in de toekomst dus ook gaat gebeuren.

-13-

7 Reflectie Dit hoofdstuk vormt een reflectie op de gedane werkzaamheden. In hoeverre de vooraf gestelde leerdoelen voldaan zijn en wat beter zou kunnen. Leerdoelen De vooraf gestelde leerdoelen bestonden grofweg uit de volgende punten (zie bijlage 1 voor de volledige SMART omschrijvingen): 1. Kunnen communiceren op het niveau van een klant. 2. Eisenlijsten op kunnen stellen. 3. Een UML ontwerp kunnen maken. 4. Een programma schrijven in java. 5. Nieuwe technieken kunnen toepassen in mijn programmatuur. 6. Een informatie systeem kunnen implementeren. 7. Gebruikers van een nieuw systeem instrueren tot goed gebruik ervan. Reflectie op afzonderlijke leerdoelen Kunnen communiceren op het niveau van een klant: Dit leerdoel is ruimschoots aan bod gekomen doordat ik de enige IT'er binnen het bedrijf was. Dus iedere communicatie met medewerkers van het bedrijf over het systeem was dus een training voor dit leerdoel. Dit ging naar mijn idee na verloop van tijd steeds beter. Het kan echter ook tegen je werken, zo gebeurde het dat ik een uitleg voor een leek gaf over onder andere ook het financiële informatiesysteem van 'Care2Move' van Breugel aan een tweetal heren die naar mijn systeem kwamen kijken. Dezen bleken achteraf de financieel manager en technisch adviseur van het bedrijf te zijn dat het financiële informatie systeem gemaakt heeft. Eisenlijsten op kunnen stellen: Dit is iets wat ik al meerdere keren heb moeten doen voor verscheidene project op de HRO. Het verschil is alleen dat ik het nu alleen heb moeten doen. In principe is dit erg goed gegaan, alleen het uiteindelijke product voldoet niet geheel aan deze specificaties. Alleen de functies met de hoogste prioriteit zijn uiteindelijk afgekomen. Dit is niet zo een groot probleem omdat het systeem uiteindelijk functioneel is en het systeem later uitgebreid gaat worden met de laatste specificaties, wat de vooraf gestelde opzet al was. Een UML ontwerp kunnen maken: Dit was voor mij niet iets nieuws aangezien ik al een heel aantal ontwerpen heb moeten maken voor HRO projecten. Dit was echter wel de eerste keer dat ik dit op mezelf heb moeten doen. Dit maakt het ontwerp vatbaarder voor onvolledigheid. Mijn ervaring is dat de volledigheid enorm toeneemt naar mate er meer mensen aan meewerken. Het gevolg is dat het eerste UML ontwerp erg globaal is en mede door de latere toevoeging van de database laag vele malen minder complex is dan het uiteindelijke ontwerp. Het verschil valt goed te zien in bijlage 3 en bijlage 4. Het oorspronkelijke ontwerp is uiteindelijk niet veel meer dan een goede basis geweest voor het opzetten van het systeem, en zo eigenlijk onmisbaar. De use-cases en daarmee sequence diagrammen zijn hier en daar inhoudelijk nogal gewijzigd door de toevoeging van de database laag, maar ook hier blijft de basis hetzelfde. Ik denk niet dat het veel beter gedaan had kunnen worden met mijn ervaring en inzicht op het te maken systeem ten tijde van het eerste ontwerp. Een programma schrijven in java: Het bewijs hiervan is het programma wat nu gebruikt wordt in het magazijn van 'Care2Move' van Breugel. Het schrijven hiervan was een erg leerzame ervaring. Als ik nu terugblik op hoe het huidige programma in elkaar zit, dan zou ik het waarschijnlijk heel anders (lees beter) hebben geschreven. Het huidige programma is niet direct instabiel maar wel moeilijk te onderhouden. Dit is veroorzaakt door structurele wijzigingen door te voeren halverwege het ontwikkelproces. Het documenteren zou beter kunnen, iemand die nieuw is met de door mij geschreven -14-

code zal waarschijnlijk veel moeite hebben om het volledig te doorgronden. Nieuwe technieken kunnen toepassen in mijn programmatuur: Het overgrote deel van het programma wat ik geschreven waren nieuwe toepassingen voor mij. Door dit veel te doen kan je snel zelfstandig oplossingen opzoeken of verzinnen. Een lijstje van onderdelen waarvan ik van tevoren geen idee had hoe het vorm te gaan geven waren onder andere: barcodescan systeem, print systeem en een excel import systeem. Al deze onderdelen heb ik uiteindelijk zonder veel problemen kunnen schrijven mede door goede documentatie en artikelen op het internet. Een informatie systeem kunnen implementeren: Ik had jammer genoeg weinig invloed in de methodes die gebruikt werden bij het implementeren van het systeem. Ik moest eerder de implementatie aanpassen aan de draaiende bedrijfsprocessen. Dus ik heb er maar het beste van gemaakt. Uiteindelijk is iets werkbaars uitgekomen, maar het is zo verlopen als ik gehoopt had. Gebruikers van een nieuw systeem instrueren tot goed gebruik ervan: Ik heb hier niet echt de tijd voor genomen, omdat ik te druk was met het zorgen dat het systeem de functionaliteiten had die het moest hebben. Dus ik heb het bij het invoeren even kort geïntroduceerd en heb daarna voornamelijk on demand laten zien hoe bepaalde onderdelen werken, en niet meer gedaan dan hier en daar wat bijsturen. Uiteindelijk lijkt het erop dat iedereen wel aardig zijn weg weet te vinden in het programma. Leer punten Uiteraard zijn er een stel punten die beter hadden gekund. Zo zijn er een aantal stappen in het ontwerp proces waar ik meer aandacht aan zou hebben kunnen besteden. Zo had ik wel beter na kunnen denken over de koppeling tussen de user interface en de data. Het verzaken hiervan heeft direct en indirect voor aardig wat tijdverspilling geleid. Ik had misschien beter de opdrachtgever moeten ondervragen over de gewenste functionaliteiten en hoe hij deze voor zich zag, al valt natuurlijk te betwijfelen of hij deze indrukken al had. Het is in ieder geval niet handig om grote structuur veranderingen later in je programma door te moeten voeren. Al zou het eigenlijk niet een al te groot probleem moeten vormen bij een goed geschreven programma. Bij het ontwerp zou ook beter rekening gehouden kunnen worden gehouden met hoe gui onderdelen werken in java. Doordat de werking van een aantal van deze onderdelen nog niet bij mij bekend waren bleek het later niet aan te sluiten op mijn ontwerp. Een oplossing zou kunnen zijn om tijdens het ontwerpen al de documentatie over deze GUI objecten te bestuderen. Hetzelfde geld ook voor bijvoorbeeld de te gebruiken randapparatuur zoals de barcode scanner en printer. De programma onderdelen die hierbij passen zijn halverwege het ontwikkelproces ontworpen omdat de details over de te gebruiken apparatuur nog niet bekend was. Deze zouden ook van tevoren bepaald kunnen worden. Een ander belangrijk punt tijdens het ontwikkelen is documenteren. Ik heb dit eigenlijk tijdens het hele ontwikkelingsproces niet gedaan of er gewoon geen tijd voor genomen. Het gevolg is dat de code moeilijk te begrijpen is als je er niet bekend mee bent, en dat ik alle documentatie achteraf zal moeten schrijven om een duidelijke java documentatie te kunnen genereren. Het implementeren had ook beter gekund door bijvoorbeeld een implementatie plan te schrijven en deze voor te leggen. Of op zijn minst een plan voor het implementeren mondeling eerder te overleggen. Dit is er bij ingeschoten door tijdgebrek. Het was moeilijk tijdens het ontwikkelproces om een indicatie te geven van hoe lang het ging duren tot iets af was. Ik ging er voor bij het voorbereiden van het ontwikkeltraject vanuit dat ik geen planning hoefde te maken omdat ik toch alleen aan het project zou werken, en ik toch geen invloed zou kunnen uitoefenen op de tijd. Dan is het dus zinnig om wel een planning te maken al is het puur om een inschatting te maken van de tijd die -15-

nodig zou moeten zijn voor het introduceren van een bepaalde functie in de software. En als laatste zou het ook een verbetering zijn om de gebruikers van het systeem beter te instrueren om zo een zelfstandiger gebruik van het systeem te bewerkstelligen. Nu moet ik zelf nog bijvoorbeeld de excel import functie besturen. Dit kan overigens ook te maken hebben met de complexiteit van de user interface daarvoor. De interface is redelijk complex maar wel erg flexibel, wat al meerdere keren zijn nut heeft gehad.

-16-

8 Conclusie Deze stage is voor mij uiteindelijk een erg leerzame ervaring geweest. Ik heb ervaring op kunnen doen met een heel ontwikkelingstraject van een nieuw informatiesysteem. Het enige probleem was dat ik zelf het hele traject heb aan moeten sturen. Wat dat betreft heb ik alles zelf moeten verzinnen en dus niet echt iets van anderen kunnen leren. Mijn kennis van java is enorm toegenomen in de laatste maanden. Ik heb nu het gevoel dat ik eigenlijk wel alles wat binnen java mogelijk is zou kunnen maken met de ervaring die ik heb opgedaan tijdens deze stage. Uiteindelijk is mijn systeem nu in gebruik bij 'Care2Move' van Breugel en krijg ik goede feedback over de werking ervan. Ook twee afgevaardigden van GMT (het bedrijf dat het informatiesysteem voor van Breugel maakt) bleken positief tegenover mijn werk te staan, en er werd gedacht over een koppeling tussen mijn systeem en het hunne. Al met al kan ik deze stage daarom wel een succes noemen.

-17-

9 Bijlagen 1.Leerdoelen...................................................................................................................... 19 2.Eisenlijst.......................................................................................................................... 21 3.Voorbereidend UML ontwerp........................................................................................... 26 4.Definitieve UML Ontwerp................................................................................................. 46 5.Database ERD................................................................................................................. 50 6.Product Screenshots....................................................................................................... 52 7.Logboek........................................................................................................................... 56 8.Urenverantwoording........................................................................................................ 66

-18-

1.Leerdoelen

-19-

Leerdoelen Gert-Jan Stolk 0753877 - Ik wil aan het einde van de stageperiode op een gelijk niveau met een klant, zondere enige ICT kennis, kunnen communiceren over het implementeren van een ICT-informatie systeem. (feedback stagebegeleider) - Ik wil aan het einde van de stageperiode zelfstandig een lijst met eisen op kunnen stellen voor een ICT-systeem die overeenkomt met de wensen van een klant. (feedback stagebegeleider) - Ik wil aan het einde van de stageperiode zelfstandig een uml ontwerp bestaande uit usecase, klasse en sequence diagrammen op kunnen stellen aan de hand van een eisenlijst en de wensen van een klant. (op te leveren document en feedback stagebegeleider) - Ik wil aan het einde van de stageperiode op basis van een uml ontwerp een programma kunnen schrijven in java. (op te leveren programma) - Ik wil aan het einde van de stageperiode in staat zijn tot het implementeren van (voor mij nog) nieuwe technieken binnen een informatie systeem. (op te leveren programma met werkende functionaleiten voor het printen en uitlezen van barcodes en het importeren en exporteren van algemene data naar het excel bestandstype) - Ik wil aan het einde van de stageperiode een informatie systeem succesvol in kunnen voeren in het bedrijfsproces waarvoor het informatie systeem is gemaakt. (feedback van gebruikers van het door mij op te leveren programma) - Ik wil aan het einde van de stageperiode gebruikers van een nieuw informatie systeem succesvol op kunnen leiden voor het gebruik van het systeem. (feedback van gebruikers)

-20-

2.Eisenlijst

-21-

Algemene eisen # Requirement 100 Het systeem moet kunnen werken op een windows 2000 systeem. 101 Het systeem moet ondersteuning bieden voor acces, mysql en postgresql databases. 102 Het systeem moet beveiligd worden met een wachtwoord. 103 Het systeem moet een gebruikers systeem hebben waar iedere gebruiker verschillende lees/schrijf rechten heeft. 104 Het systeem moet met barcodescanners overweg kunnen. 105 106 107 108 109 110 111 112 113 114 115 116 117

Driver(s) Dit is het systeem wat binnen het bedrijf gebruikt wordt Zodat het systeem zowel met een centrale als decentrale database kan werken. Niet iedereen heeft toegang tot het systeem. Zodat iedereen zijn eigen verantwoordelijkheid binnen het systeem heeft.

Het werk in het magazijn moet vlot kunnen verlopen, barcodes kunnen hier hun aandeel in hebben. Het systeem moet barcodes kunnen Het systeem beheerd het systeem genereren voor een bepaald artikel. van barcodes. Het systeem moet barcodes uit Ook op nieuwe artikelen moet een kunnen printen. barcode komen. Alle data van een artikel moet in het Om fouten of aanpassingen door systeem aan te passen zijn (zie te voeren eisen 200-213). Er moeten nieuwe artikelen Er worden regelmatig nieuwe toegevoegd kunnen worden aan het artikelen aan het assortiment systeem. toegevoegd. Het systeem moet een indeling Omdat maar bepaalde groepen kunnen maken in groepen waartoe artikelen voor de gebruiker op een de artikelen behoren. bepaald moment relevant zijn. In het systeem moeten artikelen op Deze zoekfunctie is voornamelijk verschillende gegevens opgezocht belangrijk wanneer barcodes kunnen worden. ontbreken. Het systeem moet kunnen filteren Zodat er makkelijk bekeken kan op groep, leverancier, type, worden wat er in het magazijn onderdeel, en plaatsing. aanwezig is. In het systeem moet opgezocht Op deze manier kan iedereen het kunnen worden waar een artikel fysieke artikel ook daadwerkelijk geplaatst is. terug vinden. Het systeem moet aan het Dan hoeft dit niet los ingevuld te artikelnummer kunnen zien wie de worden. leverancier is. Het systeem moet aangeven Zodat er dan van dat artikel een wanneer er een tekort is aan een bestelling gemaakt kan worden bepaald artikel. Het systeem moet bepaalde vaste Dit werkt het makkelijkst in gegevens kunnen importeren uit combinatie met een huidig globaal een excel bestand. management systeem. Het systeem moet zijn gegevens Als aansluiting op andere kunnen exporteren naar een excel systemen. bestand. Het systeem moet een mogelijkheid Externe klanten moeten zicht -22-

MoSCoW Must Should Must Would

Must

Must Must Must Must Must Must Must Should Could Would Must Could Should

bieden om via een browser zijn gegevens te tonen. 118 Het systeem moet de financiële balans op kunnen maken. 119 Een gerechtigde gebruiker moet de database connectie settings aan kunnen passen. 120 Een gerechtigde gebruiker moet de barcode settings aan kunnen passen 121 De gerechtigde gebruiker moet de rechten van andere gebruikers kunnen wijzigen.

kunnen hebben in hun voorraad. Een vast bedrijfproces wat ondersteund moet worden. Op deze manier kan er makkelijk overgestapt worden naar een ander database systeem. De instellingen van type barcode en barcodelabel print settings moeten aangepast kunnen worden. De rechten moeten aangepast kunnen worden bijvoorbeeld wanneer een user een andere functie krijgt of meer/minder rechten blijkt nodig te hebben.

-23-

Should Should Should

Should

Data # Requirement 200 Het systeem moet bijhouden welke barcodes bij welk artikel horen. 201 Het systeem moet bijhouden welk artikelnummer bij een artikel hoort. 202 Het systeem moet bij kunnen houden welk serienummer er bij een artikel hoort als deze aanwezig is. 203 Het systeem moet bijhouden waar een artikel fysiek geplaatst is. 204 Het systeem moet bij kunnen houden welk lotnummer er bij een artikel hoort als deze aanwezig is. 205 Het systeem moet het aantal aanwezige gelijke artikelen bij kunnen houden. 206 Het systeem moet bij kunnen houden van welke leverancier een artikel afkomstig is. 207 Het systeem moet bij kunnen houden van welk type middel het artikel afkomstig is of welk type middel het is. 208 Het systeem moet bij kunnen houden welk onderdeel van een middel het artikel omvat. 209 Het systeem moet een beschrijving van een artikel op kunnen slaan. 210 Het systeem moet de inkoop prijs van een artikel bij kunnen houden. 211 Het systeem moet de verkoop prijs van een artikel bij kunnen houden. 212 Het systeem moet een korting bij de verkoop en inkoop prijs bij kunnen houden. 213 In het systeem moet aangegeven worden wat de minimale- en maximale voorraad van een bepaald artikel mag zijn. 214 In het systeem moet aangegeven kunnen worden wanneer het artikel is toegevoegd. 215 In het systeem moet aangegeven worden welke user het artikel toegevoegd heeft. 216 In het systeem moet aangegeven kunnen worden wanneer de gegevens van het artikel voor het laatst gewijzigd zijn. 217 In het systeem moet aangegeven worden welke user de gegevens

Driver(s) Dataopslag

MoSCoW Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

Dataopslag

Must

-24-

van het artikel voor het laatst gewijzigd heeft. 218 In het systeem moet aangegeven Dataopslag worden wanneer de een artikel voor de laatste keer aangevuld zijn.

-25-

Must

3.Voorbereidend UML ontwerp

-26-

Class Diagram

-27-

UseCase Diagram

-28-

Use Cases & Sequence Diagrammen

Naam Samenvatting Actoren Aannamen Beschrijving Uitzonderingen Resultaat

Opstarten De gebruiker start het programma op. Logistiek medewerker, Manager logistiek De gebruiker bevindt zich in een opgestart operating system. (1) De gebruiker start het programma (2) Het programma geeft een inlogscherm weer [database connectie problemen] Er wordt een bericht weergegeven dat het programma geen connectie met de database kan maken. Het programma wordt afgesloten. Het programma bevindt zich bij het inlogscherm

-29-

Naam Samenvatting Actoren Aannamen Beschrijving Uitzonderinge n Resultaat

Inloggen Er wordt op het systeem ingelogd. Logistiek medewerker, Manager logistiek Het programma geeft het inlogscherm weer. (1) De gebruiker vult zijn inlog gegevens in. (2) De gebruiker bevestigd dat hij de gegevens heeft ingevuld. [foutieve inlog gegevens] Er wordt een bericht weergegeven dat het programma de inlog gegevens niet herkent en geeft opnieuw het inlog formulier weer. Een gebruiker is ingelogd.

-30-

Naam Samenvatting Actoren Aannamen Beschrijving

Uitzonderinge n Resultaat

Nieuw artikel invoegen Er wordt een nieuw artikel toegevoegd aan het assortiment. Logistiek medewerker, Manager logistiek Er is ingelogd en de gebruiker heeft de rechten om een nieuw artikel in te voeren. (1) De gebruiker klikt op het menu ‘data>artikel toevoegen’ of klikt op de knop ‘artikel toevoegen’ in de werkbalk. (2) De gebruiker voert de nodige gegevens in bij het nieuwe artikel. (3) De gebruiker klikt op de knop ‘ok’ in het invoer scherm. (4) Er wordt een opsomming van de ingevoerde gegevens weergegeven. [dubbele data] Er wordt aangegeven dat het toe te voegen artikel al bestaat, en dit artikel wordt weergegeven. Een nieuw artikel is toegevoegd aan de database, en de invoer datum wordt ingevoerd.

-31-



Voorraad aanvullen Er wordt een of meerdere gelijke artikelen toegevoegd aan de voorraad. Logistiek medewerker Er is ingelogd en de gebruiker heeft de rechten om het aantal artikelen aan te passen. (1) De gebruiker geeft aan welk artikel aan te willen vullen door deze op te zoeken of met de barcode scanner in te lezen. (2) De gebruiker voert het aantal in waarmee het artikel wordt aangevuld. (3) De gebruiker bevestigd de invoer door op de ‘ok’ knop te drukken. (4) Het artikel wordt in de voorraadlijst geselecteerd met het nieuwe aantal. geen Een nieuwe kwantiteit van artikelen wordt in de database doorgevoerd, en de laatste aanvul datum wordt geupdate.

-32-



Artikel uit de voorraad halen Er wordt een of meerdere gelijke artikelen uit de voorraad gehaald. Logistiek medewerker Er is ingelogd en de gebruiker heeft de rechten om het aantal artikelen aan te passen. (1) De gebruiker geeft aan welk artikel uit de voorraad te willen halen door deze op te zoeken of met de barcode scanner in te lezen. (2) De gebruiker voert het aantal in waarmee het artikel wordt verminderd. (3) De gebruiker bevestigd de invoer door op de ‘ok’ knop te drukken. (4) Het artikel wordt in de voorraadlijst geselecteerd met het nieuwe aantal. geen Een nieuwe kwantiteit van artikelen wordt in de database doorgevoerd.

-33-



Artikel wijzigen De gegevens van een artikel worden gewijzigd. Logistiek medewerker, Manager logistiek Er is ingelogd en de gebruiker heeft de rechten om gegevens van artikelen aan te passen. (1) De gebruiker geeft aan welk artikel te willen wijzigen door deze op te zoeken of met de barcode scanner in te lezen. (2) De gebruiker voert de wijzigingen voor het artikel door. (3) De gebruiker bevestigd de invoer door op de ‘ok’ knop te drukken. (4) Het artikel wordt in de voorraadlijst geselecteerd met de nieuwe gegevens. [verkeerd datatype] Het systeem geeft aan dat er verkeerde data is ingevoerd en gaat terug naar stap 2. De gegevens van een artikel zijn gewijzigd, en de laatste wijziging datum en gebruiker wordt geupdate.

-34-


Barcode afdrukken Er wordt een barcode voor een bepaald artikel afgedrukt Logistiek medewerker Er is ingelogd en de gebruiker heeft de rechten om artikelen te bekijken. En het juiste artikel is opgezocht (zie artikel zoeken). (1) De gebruiker klikt op de ‘barcode afdrukken’ knop (2) De barcode wordt volgens de barcode instellingen afgedrukt [Probleem met de printer] Er wordt een bericht weergegeven dat er iets mis is met de printer. Er wordt een barcode label uitgeprint.

-35-


Voorraad bekijken Een gebruiker bekijkt een deel van de voorraad Logistiek medewerker, Manager logistiek Er is ingelogd en de gebruiker heeft de rechten om artikelen te bekijken. (1) De gebruiker klikt op het menu ‘weergave>voorraad’ of klikt op de knop ‘voorraad weergave’ in de werkbalk. (2) De gebruiker voert de gewenste filters door. Geen De gebruiker ziet een naar zijn instellingen gefilterde lijst artikelen.

-36-



Artikel zoeken Een gebruiker zoekt een artikel Logistiek medewerker, Manager logistiek Er is ingelogd en de gebruiker heeft de rechten om artikelen te bekijken. (1) De gebruiker klikt op het menu ‘weergave>voorraad’ of klikt op de knop ‘voorraad weergave’ in de werkbalk. (2) De gebruiker voert eventueel gewenste filters door. (3) De gebruiker voert een zoekterm in. (4) Er wordt een lijst met zoekresultaten weergegeven. Geen De gebruiker ziet een lijst artikelen die aan zijn filters en zoekterm voldoen.

-37-



Nieuwe artikelgroep aanmaken Er wordt een nieuwe artikelgroep aangemaakt Logistiek medewerker, Manager logistiek Er is ingelogd en de gebruiker heeft de rechten om nieuw artikel groepen aan te maken. (1) De gebruiker klikt op het menu ‘data>artikelgroep’. (2) De gebruiker voert de nodige gegevens in bij de nieuwe artikelgroep. (3) De gebruiker klikt op de knop ‘ok’ in het invoer scherm. (4) Er wordt een bericht weergegeven dat de artikelgroep succesvol is toegevoegd met een opsomming van de ingevoerde gegevens. [dubbele data] Er wordt aangegeven dat de toe te voegen artikelgroep al bestaat, en de eigenschappen van deze artikelgroep wordt weergegeven. Een nieuwe artikelgroep is toegevoegd aan de database.

-38-



Bestellijst bekijken De gebruiker bekijkt de lijst van artikelen die besteld zouden moeten worden. Manager logistiek Er is ingelogd en de gebruiker heeft de rechten om te bestellen artikelen te bekijken. (1) De gebruiker klikt op het menu ‘weergave>besteladvies’ of klikt op de knop ‘besteladvies weergave’ in de werkbalk. (2) De gebruiker voert eventueel gewenste filters door. (3) Er wordt een lijst met artikelen weergegeven die de minimum voorraad overschreden hebben. Geen De gebruiker ziet een lijst artikelen die aan de filters voldoet en die de minimum voorraad overschreden hebben.

-39-



Importeren van een bestand Er wordt een extern bestand geïmporteerd naar de database. Logistiek medewerker, Manager logistiek Er is ingelogd en de gebruiker heeft de rechten om artikelen te wijzigen en/of toevoegen. (1) De gebruiker klikt op het menu ‘bestand>importeren’. (2) De gebruiker selecteert een bestand om te importeren in de filebrowser. (3) De gebruiker geeft aan wat er met de geïmporteerde data gebeuren moet. (4) De gebruiker accordeerd eventueel of er data overschreven moet worden. [incorrecte data] De data in het te importeren bestand incorrect of van een verkeerd datatype. De database is geupdate vanuit een extern bestand.

-40-



Exporteren naar een bestand Bepaalde gegevens uit de database worden geëxporteerd naar een extern bestand. Logistiek medewerker, Manager logistiek Er is ingelogd en de gebruiker heeft de rechten om artikelen te bekijken. (1) De gebruiker selecteert in de voorraad weergave de reeks te exporteren records (zie ‘Voorraad bekijken’). Of bekijkt een financieel rapport. (2) De gebruiker klikt op het menu ‘bestand>exporteren’. (3) De gebruiker kiest een locatie waar het te exporteren bestand terecht moet komen in de filebrowser. (4) De gebruiker geeft aan welke velden er in het exporteerde bestand moeten komen. (5) De gebruiker geeft aan van welk filetype het geëxporteerde bestand moet komen. (6) De gebruiker bevestigt zijn keuze door op de ‘export’ knop te klikken. [geen ruimte] Het systeem geeft aan dat er geen ruimte op de schijf is voor een dergelijk bestand. [geen rechten] Het systeem geeft aan dat het bestand op deze locatie niet opgeslagen mag worden. Er is een extern bestand aangemaakt met een door de gebruiker aangegeven reeks data.

-41-


Balans rapport opvragen Een gebruiker vraagt een financieel rapport op. Manager logistiek Er is ingelogd en de gebruiker heeft de rechten om de financiële functies te gebruiken. (1) De gebruiker klikt op het menu ‘view>balans’. (2) De gebruiker geeft aan wat voor template hij wil gebruiken voor het balans rapport. Geen Er wordt een balans rapport getoond.

-42-



Database instellingen wijzigen Een gebruiker wijzigt de database instellingen. Systeembeheerder Er is ingelogd en de gebruiker heeft de rechten om database instellingen te wijzigen (1) De gebruiker klikt op het menu ‘bestand>instellingen’. (2) De gebruiker klikt op ‘Database’ in het weergegeven menu. (3) De gebruiker voert zijn gewenste wijzigingen door. (4) De gebruiker bevestigt zijn wijzigingen door op de knop ‘Toepassen’ te klikken. [foutieve data ingevoerd] Er wordt weergegeven dat er iets op een verkeerde manier is ingevoerd en wat dat precies is. De database instellingen zijn gewijzigd.

-43-



Barcode instellingen wijzigen Een gebruiker wijzigt de barcode instellingen. Logistiek medewerker, Manager logistiek Er is ingelogd en de gebruiker heeft de rechten om barcode instellingen te wijzigen. (1) De gebruiker klikt op het menu ‘bestand>instellingen’. (2) De gebruiker klikt op ‘Barcode’ in het weergegeven menu. (3) De gebruiker voert zijn gewenste wijzigingen door. (4) De gebruiker bevestigt zijn wijzigingen door op de knop ‘Toepassen’ te klikken. [foutieve data ingevoerd] Er wordt weergegeven dat er iets op een verkeerde manier is ingevoerd en wat dat precies is. De barcode instellingen zijn gewijzigd.

-44-



Gebruiker instellingen wijzigen Een gebruiker wijzigt de gebruikers instellingen. Manager logistiek Er is ingelogd en de gebruiker heeft de rechten om gebruikers instellingen te wijzigen. (1) De gebruiker klikt op het menu ‘bestand>instellingen’. (2) De gebruiker klikt op ‘Gebruikers’ in het weergegeven menu. (3) De gebruiker voert zijn gewenste wijzigingen door. (4) De gebruiker bevestigt zijn wijzigingen door op de knop ‘Toepassen’ te klikken. [foutieve data ingevoerd] Er wordt weergegeven dat er iets op een verkeerde manier is ingevoerd en wat dat precies is. De gebruikers instellingen zijn gewijzigd.

-45-

4.Definitieve UML Ontwerp

-46-

Volledige Class Diagram

-47-

Core Class Diagram

-48-

GUI Class Diagram

-49-

5.Database ERD

-50-

-51-

6.Product Screenshots

-52-

laadscherm

Voorraad weergave

-53-

Cluster editor

Artikel Bibliotheek

-54-

Import weergave

Barcode print weergave

-55-

7.Logboek

-56-

Week 1 Maandag 12 September 2005 – Gesprek over de functionaliteiten van het te maken programma (zie bijlage 1 notulen – Eisenpakket alpha en beta gemaakt. (Eisenpakket Alpha.doc Eisenpakket Beta.doc) – Use-cases gedefinieerd (zie bijlage 2) – Use-cases alpha uitgewerkt (Use-Cases Alpha.doc) – Goedkeuring stage verder geregeld (E-Mail) Bijlage 1 – beveiliging van het programma met passwords moet wel maar heeft geen prioriteit. – Barcodes is een must. – Er moet een systeem komen om voornamelijk financiele gegevens uit het huidige micos systeem te halen, dit dmv van een excel import/export functie. – Er moeten middelen van externe klanten geregistreerd worden (DSW, AWBZ) – Er moet waarschijnlijk toch een gedecentralieerde database komen, maar er moet eerst met een centrale getest worden, beide functies moeten dus aanwezig zijn. – Er moet een waarschuwings systeem komen als een bepaalde voorraad producten onder het minimale aantal komt, zodat het dan bijbesteld kan worden. – Er moet gezocht worden naar een goede barcode scanner. – De volgende datafields zijn van belang bij artikelen: [ID, barcode, artikelnummer, serienummer, groep, plaatsing, lotnummer, aantal, leverancier, type, onderdeel, omschrijving, inkoopprijs, verkoopprijs, korting, minimale voorraad, maximale voorraad] Bijlage 2 – opstarten – inloggen – nieuw artikel invoeren – invoeren van een artikel – verwijderen van een artikel – barcode uitprinten – voorraad bekijken – specefiek artikel opzoeken – nieuwe artikelgroep aanmaken – bestellijst bekijken – importeren van een bestand – exporteren van een bestand – financieel rapport opvragen – inloggen externe klant (moet verder uitgebreid worden als dit onderdeel uitgevoerd wordt) – gebruik webinterface (moet verder uitgebreid worden als dit onderdeel uitgevoerd wordt) Dinsdag 13 September 2005 – Use-cases beta uitgewerkt (Use-Cases Beta.doc). – Use-case diagram alpha gemaakt. (Ontwerp alpha.jude) – Goedkeuring stage verder geregeld, op de stagesite aangemeld. – Interface ontwerpen gemaakt. -57-

–

Eerste versie klasse diagram gemaakt (Ontwerp alpha.jude)

Woensdag 14 September 2005 – Alpha versies sequence diagrammen gemaakt (Ontwerp alpha.jude) Donderdag 15 September 2005 - klasse diagram aangevuld (Ontwerp Alpha.jude) - Ontwerp in Beta gezet (Ontwerp Beta.jude) - Begonnen met het ontwikkelen van de GUI

Week 2 Maandag 19 September 2005 – bedrijfsoriëntatie. Dinsdag 20 September 2005 – Onderzoek naar java interface technieken – Installeren van nodige software op nieuwe werkplek – Kleine verbeteringen gemaakt aan de GUI. Woendag 21 September 2005 – GUI verder ontwikkeld (menu en werkbalk afgerond). Donderdag 22 September 2005 – Verschillende GUI scherm indelingen gemaakt. – GUI – instelling opties gemaakt.

Week 3 Maandag 26 September 2005 – Database ideeen verzameld en een alpha-test versie van de database gemaakt met mysql. – Implementeren van de database in java. Dinsdag 27 September 2005 – Database gegevens in een Jtable gezet. – Ontwerp voor een AbstractTableModel geimplementeerd voor de Jtable. Woensdag 28 September 2005 – De filter onderdelen gemaakt voor de GUI. Donderdag 29 September 2005 – Artikel gegevens venster gemaakt voor de GUI.

Week 4 Maandag 3 Oktober 2005 – Verder gewerkt aan artikel gegevens venster. Dinsdag 4 Oktober 2005 – Versie 3 gemaakt van het artikel gegevens venster. -58-

Woendag 5 Oktober 2005 – Versie 3 artikel gegevens venster afgerond. – Interactie tussen het artikel gegevens venster en database gemaakt. Donderdag 6 Oktober 2005 – Weergave methoden voor het artikel gegevens venster geschreven. – Pending issues opgelost.

Week 5 Maandag 10 Oktober 2005 – Artikel Lijst venster filters werkend gemaakt. – Link tussen Artikel lijst en artikel gegevens gemaakt. – Bugs in artikel gegevens opgelost. Dinsdag 10 Oktober 2005 – Bugs in de artikel lijst opgelost. – artikel gegevens herschreven. Woensdag 11 Oktober 2005 – artikel lijst en artikel edit lijst gekoppeld – Onderzoek gedaan naar barcode scanners en datacollectoren. De uiteindelijke keuze is gevallen op het volgende product http://www.cipherlab.co.uk/products/pdt/8000.htm – Een demoprogramma geschreven en geemuleerd voor de bovenstaande scanner. Donderdag 12 Oktober 2005 – De eerste functies gemaakt voor het opslaan van wijzigingen in artikelen. – Status bespreking gehad, de barcode scanner is goedgekeurd en er moeten nog wat kleine toevoegingen gedaan worden aan de database om het systeem compitabel te maken met volledige middelen die niet tot het magazijn behoren.

Week 6 Maandag 17 Oktober 2005 – De eerste functies voor het toevoegen en oplaan van nieuwe artikelen en het wijzigen van artikelen afgerond en gedebugged. – Een start gemaakt met het optimaliseren en documenteren van alle huidige code. Dinsdag 18 Oktober 2005 – De database verbeterd en omgezet in postgresql – Begonnen met het programmeren van een laag tussen de database en het programma. Woensdag 19 Oktober 2005 – database laag gedebugged en werkend gekregen Donderdag 20 Oktober 2005 – laatste bugs uit de database laag verholpen. – Begonnen met implementeren van de nieuw databaselaag in de bestaande code. -59-

Week 7 Maandag 24 Oktober 2005 – Artikellijst volledig compitabel gemaakt met de nieuwe databaselaag. – Artikellijst gedebugged. – Artikelgegevens volledig compatible gemaakt met de nieuwe databaselaag. Dinsdag 25 Oktober 2005 – Artikelgegevens gedebugged – Artikel lijst en artikel edit lijst gekoppeld Woensdag 26 Oktober 2005 vrij Donderdag 27 Oktober 2005 – Sorteer algoritme aan de gui gekoppeld. – Nieuw artikel toevoeg functie opgezet.

Week 8 Maandag 31 Oktober 2005 – Nieuw artikel/artikel opslaan functionaliteiten uitgewerkt, gedebugged, in de gui verder doorgevoerd en afgerond. – Status gesprek, deadline richtlijnen vastgesteld. – Gui onderdelen geoptimaliseerd. Dinsdag 1 Novemeber 2005 – GUI onderdelen voor de groep en leverancier management gemaakt. Woensdag 2 November 2005 – Databaselaag abstracter gemaakt en geoptimaliseerd. Donderdag 3 November 2005 – Bugs verhelpen als gevolg van de wijzigingen in de databaselaag.

Week 9 Maandag 7 November 2005 – Bugs verholpen als gevolg van de wijzigingen in de databaselaag. – Begonnen met verifieren van gegevens bij het invoeren van een textveld. Dinsdag 8 November 2005 – Basis opgezet voor form verifiatie – Groep en leverancier management geupdate, en schrijf functionaliteiten toegevoegd. Woensdag 9 November 2005 – Structuur verandering gemaakt in kleuren defenitie. – Het invoeren van groepen/leveranciers afgerond. Donderdag 10 November 2005 – Geexperimenteerd met ander gui look and feels. -60-

– –

Updaten van groep en leverancier gegevens afgerond. Het gehele cluster (groepen en leveranciers zijn clusters) management gedebugged en afgerond.

Week 10 Maandag 14 November 2005 – Cut, Copy, Paste functionaliteiten ingebouwd. – Custom ingegeven filters werken nu zoals behoord. – Opzet gemaakt voor micos inport uit excel. Dinsdag 15 November 2005 – Micos (interne informatiesysteem) import verder ontwikkeld. Woensdag 16 November 2005 – Micos import verder ontwikkeld. Donderdag 17 November 2005 – Micos import verder ontwikkeld. – Met de barcode scanner geexperimenteerd.

Week 11 Maandag 21 November 2005 – Opzet gemaakt voor en onderzoek gedaan naar het tussenverslag. Dinsdag 22 November 2005 – Uitgezocht hoe het beste het basisstation van de barcode scanner gebruikt kon worden met de scanner. Woensdag 23 November 2005 – Verder getest aan het basistations van de barcode scanner. – Verder gewerkt aan de micos importer. Donderdag 24 November 2005 – Alle GUI onderdelen van de micos import afgerond.

Week 12 Maandag 28 November 2005 – Aan het stage tussenverslag gewerkt. – Onderzoek gedaan naar pl/pgsql en java.awt.print Dinsdag 29 November 2005 – Benodigde pl/pgsql triggers en functies geschreven. – Micos Import afgerond. Woensdag 30 November 2005 – Artikellijst GUI en internals abstracter gemaakt zodat ook de micostabel ermee weergegeven kon worden. – Verdere implementatie van de micosgegevens in het programma. -61-

Donderdag 1 December 2005 – Stage tussenverslag afgerond. – Knoppen voor de barcode en micos functies toegevoegd. – Een bug in Knippen, Kopieren en Plakken verholpen. – Verder de micosfunctie doorgevoerd.

Week 13 Maandag 5 December 2005 – Koppeling tussen micostabel en het systeem. Dinsdag 6 December 2005 – Communicatie tussen artikellijst en artikelgegevens verbeterd. Woensdag 7 December 2005 – Koppeling tussen micostabel en het artikelsysteem afgerond. – Bug verholpen bij het aanmaken en direct editen van een cluster. Donderdag 8 December 2005 – Frame voor de barcode print functie opgezet. – Geexperimenteerd met java.awt.print.

Week 14 Maandag 12 December 2005 – Onderzoek naar de printfuncties van java afgerond. – Een universele printclass geschreven. – Gewerkt aan de layout van de etiketten in java. Dinsdag 13 December 2005 – Etiket teken classe geschreven en de layouts ervoor doorgevoerd. – Printfuncties voor de teken classe getest. Woensdag 14 December 2005 – Verder gewerkt aan de barcode print GUI. Donderdag 15 December 2005 – Verder gewerkt aan de barcode print GUI en functionaliteiten.

Week 15 Maandag 19 December 2005 – Verder gewerkt en gedebugged aan de barcode print GUI en functionaliteiten. Dinsdag 20 December 2005 – Verder gewerkt en gedebugged aan de barcode print GUI en functionaliteiten. Woensdag 21 December 2005 – Barcode print GUI en functionaliteiten afgerondt. -62-

Donderdag 22 December 2005 – Nieuwe programmas gemaakt voor de datacollector. – Onderzocht hoe de datacollector het beste uitgelezen kan worden. – Triggers geschreven voor de database.

Week 16 Dinsdag 27 December 2005 – De database uitgebreid met triggers voor het aanmaken van nieuwe users en het maken van een log tabel. Woensdag 28 December 2005 – Bug fixes uitgevoerd. Donderdag 29 December 2005 – Het systeem klaar gemaakt voor de eerste beta uitgave. – Bug fixes. Vrijdag 30 December 2005 – Tests uitgevoerd. – bug fixes.

Week 17 Maandag 2 Januari 2006 – Testen. – Bug fixes. Dinsdag 3 Januari 2006 – Testen/Implementeren. – Bug fixes. Woensdag 4 Januari 2006 – Implementeren. – Barcode scan systeem ontwikkelen. Donderdag 5 Januari 2006 – Barcode scan systeem verder ontwikkeld. Vrijdag 6 Januari 2006 – Barcode scan systeem functioneel gemaakt.

Week 18 Maandag 9 Januari 2006 – Barcode scan systeem getest. – Bugs gefixes. Dinsdag 10 Januari 2006 – Implementeren. – Kleine toevoegingen in functionaliteiten gedaan. -63-

Woensdag 11 Januari 2006 – Begonnen met het maken van een nieuwe beta uitgave. – Artikeldetail en geschiedenis venster ontwikkeld. Donderdag 12 Januari 2006 – Artikeldetail en geschiedenis venster ontwikkeld.

Week 19 Maandag 16 Januari 2006 – Artikeldetail en geschiedenis venster ontwikkeld. – Support geleverd. Dinsdag 17 Januari 2006 – AtikelGegevens omgebouwd om goed synchroom te lopen met het artikeldetail veld. Woensdag 18 Januari 2006 – Alle functies aangepast aan de nieuw functionaliteiten. Donderdag 19 Januari 2006 – Een nieuwe versie afgerond.

Week 20 Maandag 23 Januari 2006 – Grote bug ontdekt, reparatie geanaliseerd. Dinsdag 24 Januari 2006 – Structurele veranderingen gemaakt in het programma. Woensdag 25 Januari 2006 – Verder gewerkt aan de reparatie van de fout. – Beter foutvermelding toegevoegd. Donderdag 26 Januari 2006 – Nieuw versie klaar gemaakt voor gebruik.

Week 21 Maandag 30 Januari 2006 – Documenteren van code. – Een product tour gegeven van mijn product aan twee afgevaardigden van GMT (http://ww.gmt.nl) de leverancier van het informatiesysteem bij 'Care2Move' van Breugel. Dinsdag 31 Januari 2006 – Documenteren. – Kleine bug fixes. Woensdag 1 Februari 2006 -64-

– –

UML ontwerp gereverse engineerd. Documenteren.

Donderdag 2 Februari 2006 – Code opgeschoont naar aanleiding van gerverse engineerde class diagram. – Orginele UML ontwerp gexporteerd en samengevoegd.

Week 22 Maandag 6 Februari 2006 – Gewerkt aan het stageverslag.

-65-

8.Urenverantwoording

-66-

Week dag 1 Maandag Dinsdag Woensdag Donderdag 2 Maandag Dinsdag Woensdag Donderdag 3 Maandag Dinsdag Woensdag Donderdag 4 Maandag Dinsdag Woensdag Donderdag 5 Maandag Dinsdag Woensdag Donderdag 6 Maandag Dinsdag Woensdag Donderdag 7 Maandag Dinsdag Woensdag Donderdag 8 Maandag Dinsdag Woensdag Donderdag 9 Maandag Dinsdag Woensdag Donderdag 10 Maandag Dinsdag Woensdag Donderdag 11 Maandag Dinsdag Woensdag Donderdag

datum 09/12/05 09/13/05 09/14/05 09/15/05 09/19/05 09/20/05 09/21/05 09/22/05 09/26/05 09/27/05 09/28/05 09/29/05 10/03/05 10/04/05 10/05/05 10/06/05 10/10/05 10/11/05 10/12/05 10/13/05 10/17/05 10/18/05 10/19/05 10/20/05 10/24/05 10/25/05 10/26/05 10/27/05 10/31/05 11/01/05 11/02/05 11/02/05 11/07/05 11/08/05 11/09/05 11/10/05 11/14/05 11/15/05 11/16/05 11/17/05 11/21/05 11/22/05 11/23/05 11/24/05

tijd 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 0 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8

Omschr. Ontwerpen Ontwerpen Ontwerpen Ontwerpen SLB SLB Dev-GUI Dev-GUI Dev-DB Dev-GUI Dev-GUI Dev-GUI Dev-GUI Dev-GUI Dev-DB Dev-DB Dev-Func Dev-Func Dev-Func Dev-Func Dev-Doc Dev-DB Dev-JDB Dev-Func Dev-GUI Dev-Func Dev-Func Dev-Func Dev-Func Dev-JDB Dev-JDB Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Bar Dev-Bar Dev-Func

12 Maandag Dinsdag Woensdag Donderdag 13 Maandag Dinsdag Woensdag Donderdag 14 Maandag Dinsdag Woensdag Donderdag 15 Maandag Dinsdag Woensdag Donderdag 16 Dinsdag Woensdag Donderdag Vrijdag 17 Maandag Dinsdag Woensdag Donderdag Vrijdag 18 Maandag Dinsdag Woensdag Donderdag 19 Maandag Dinsdag Woensdag Donderdag 20 Maandag Dinsdag Woensdag Donderdag 21 Maandag Dinsdag Woensdag Donderdag 22 Maandag Dinsdag Woensdag Donderdag Totaal

-67-

11/28/05 11/29/05 11/30/05 12/01/05 12/05/05 12/06/05 12/07/05 12/08/05 12/12/05 12/13/05 12/14/05 12/15/05 12/19/05 12/20/05 12/21/05 12/22/05 12/27/05 12/28/05 12/29/05 12/30/05 01/02/06 01/03/06 01/04/06 01/05/06 01/06/06 01/09/06 01/10/06 01/11/06 01/12/06 01/16/06 01/17/06 01/18/06 01/19/06 01/23/06 01/24/06 01/25/06 01/26/06 01/30/06 01/31/06 02/01/06 02/01/06 01/23/06 01/24/06 01/25/06 01/26/06

8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 6 8 8 8 8 6 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 700

Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-DB Dev-Func Dev-Test Dev-Test Dev-Test Dev-Test Dev-Test Dev-Func Dev-Func Dev-Test Dev-Test Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Func Dev-Bugs Dev-Bugs Dev-Bugs Dev-Bugs Documenteren Documenteren Documenteren Documenteren Verslag Verslag Verslag Verslag

Logistiek Management Systeem. Het ontwerpen, ontwikkelen en implementeren van een logistiek management systeem

Recommend Documents