KLU Materiel Nord A/S

Transkript

1 KLU Materiel Nord A/S Nordjyllands Erhvervsakademi Datamatiker uddannelsen

2

3 Nordjyllands Erhvervsakademi Datamatiker uddannelsen Titel: KLU Materiel Nord A/S Projekt Periode: 25 April - 4 Juni 2008 Fag: 2. semester projekt Gruppe: 4 Forfattere: Jesper Liver Nallaik-Kumaran Shanmuganathan Mathias Steen Andersen Heine Dueholm Vejleder: Gunhild Marie Andersen Hjælpelærere: Finn Ebertsen Nordbjerg Poul Andersen Antal eksemplarer: 4 Sider: 79

4 Forord Denne rapport er udarbejdet af fire 2. semester studerende ved Nordjyllands Erhvervsakademi i perioden 25 April - 4 Juni I rapporten agerer de studerende konsulenter som er hyret af KLU Materiel Nord A/S, hvor de skal udvikle et udlejningssystem. Vi vil gerne sige tak til KLU Materiel Nord A/S, for deres store samarbejdsvilje og imødekommenhed i forbindelse med dette projekt. Jesper Liver Nallaik-Kumaran Shanmuganathan Mathias Steen Andersen Heine Dueholm i

5 Indhold 1 Indledning Problemformulering Afgrænsning af projektet Spørgsmål Foranalyse Virksomhedskarakteristik Organisation Problemanalyse SWOT Strategi analyse Regnskabsanalyse Cost Benefit Direkte målelige omkostninger Direkte målelige indtægter/omkostningsbesparelser Indirekte/vanskeligt målelige omkostninger Indirekte/vanskeligt målelige indtægter Konkurrenceforhold Hjemmeside Priser for udlejning Udvalg af material til udlejning ii

6 2.7 IT-strategi Formål Applikationer og Information Teknologi Handlingsplan Videre udvikling Delkonklusion Iteration 1: Kravspecifikation Systemdefinition Forretningsaktiviteter Prototype Domænemodel Use Case Oversigt Delkonklusion Iteration 2: Analyse Aktørbeskrivelse Use Case System Sekvens Diagram Operationskontrakt Delkonklusion Iteration 3: Design og implementering Arkitekturovervejelse Kodestandard Patterns Interaktionsdiagram Designklassediagram Klasser Overvejelser under implementering Database generelt iii

7 5.5.2 Client-Server model Store O notation Database design Oversigt over database tabeller Normalisering Implementering Generelt omkring oprettelse GUI vinduer Dato styring Beregning af antal arbejdsdage Individuelle værdier Test Cases junit Brugervenlighedstest System Accept Delkonklusion Planlægning Tidsplan Ugeplaner Konklusion 64 I Appendix 66.1 Hvem har skrevet hvad? Visualisering af Fully Dressed Use Case Use Case Diagram Brugermanual til materialeudlejning Udlejning Materiel Kunde Status iv

8 .4.5 Statistik Billeder til brugermanual Logbog v

9 Kapitel 1 Indledning Dette projekt er udarbejdet efter henvendelse til KLU Materiel Nord A/S, som har indvilliget i at være udgangspunkt for vores 2. semester projekt. KLU Materiel Nord A/S har fremsat et ønske om at få udviklet et udlejnings system til firmaets entreprenørmateriel. KLU Materiel Nord A/S har ikke udleveret en kravspecifikation eller designdokumentation. Softwaren er udviklet i Java ved hjælp af NetBeans IDE 6 sammen med MySQL og Navicat 8.0 Lite. UML er lavet i Rational Rose 7. Vi har brugt SVN til versionstyring. Rapporten er skrevet i LATEX Rapportens opbygning er lavet ud fra Nordjyllands Erhvervsakademis vejledning i rapport skrivning til datamatiker projekter. 1.1 Problemformulering I samarbejde med KLU Materiel Nord A/S, vil vi udarbejde en rapport og et udlejningssystem til firmaets entreprenørmateriel. Rapporten vil indeholde en virksomhedsanalyse, samt dokumentation for design og udvikling. Vi vil i projektet bruge viden, som vi har tillært os i de respektive fag: 1

10 CAOS, ITIO, SoftwareKonstruktion og SoftwareDesign Afgrænsning af projektet Systemet vil blive en prototype, og ikke et færdig udviklet system. Vi vil fokusere på at få opbygget et system som kan kommunikere sammen med en database, og håndtering af de basale funktioner, såsom datostyring, kalender, kundehåndtering, status over materiel, priser/rabatter Spørgsmål Hvordan udvikler vi et enkelt, brugervenligt og effektivt udlejningssystem? - Hvilke yderligere funktioner kan implementeres til systemet? - Kan systemet samkøres med rammesystemet C5 - Er der muligheder for at udbygge systemet med en internet del? - Kan systemet give et bedre strategisk redskab for ledelsen til at vurdere og optimere deres udlejningsmateriel? - Hvordan designer vi et system mest hensigtsmæssigt? - Hvordan løses problemer i forhold til samtidighed? Når der er flere brugere logget på ad gangen. - Hvordan skal systemet laves og implementeres? 2

11 Kapitel 2 Foranalyse I dette afsnit vil vi analysere KLU Materiel Nord A/S. Vi vil beskrive virksomheden som vi ser den lige nu. Vi vil benytte relevant teori fra faget ITIO for at lave redegørelsen, herunder en karakteristik, en SWOT analyse, en cost benefit vurdering, virksomhedens konkurrenter og virksomhedens strategi for IT. 2.1 Virksomhedskarakteristik Virksomheden KLU Materiel Nord A/S blev startet ultimo 2004, med fokus på salg og service. I 2006 blev virksomheden omdannet fra et enkeltmandsvirksomhed til A/S da de begyndte på udlejning af entreprenør materiel. KLU Materiel Nord A/S er bosiddende i Aalborg. KLU Materiel Nord A/S har i alt syv medarbejdere. Virksomhedens nuværende bruttoomsætning lyder på 25 millioner kr. om året. Ud fra KLU Materiel Nord A/S organisations diagram kan man aflæse flere ting om virksomheden. Hvis man kigger fra top til bund, kan man se hvordan den vertikale arbejdsdeling er. Det bliver uddybet grundigere nedenfor. 3

12 Direktør Kennith Lohmann Freelance bogholder Afdelingsleder Ulrik Knudsen Souschef Michael Pedersen Sælger Montør Montør Pladsmand Jan Olsen Chauffør Figur 2.1: Organisations diagram for KLU Materiel Nord A/S Organisation KLU Materiel Nord A/S er en flad organisation. I toppen er Kennith Lohmann som er direktør for KLU Materiel Nord A/S. Men da han bor på Sjælland tager han kun der over en gang om måneden. Den daglige ledelse lader han Ulrik Knudsen og Michael Pedersen om at klare som henholdsvis er afdelingsleder og souschef. Efter dem kommer Jan Olsen som er pladsmand i virksomheden. Han sørger for at alle maskinerne er klar til at blive lejet ud. Eller hvis der nogle af maskinerne der er gået i stykker, sørger han for de bliver lavet. Hvis der er brug for det, kan han også godt tage lastbilen og køre en maskine hen til en kunde. Hernæst har vi sælgeren som er virksomhedens ansigt udadtil. Han kører rundt til forskellige virksomheder for at opsøge potentielle kunder. Til sidst er der så de to montører som køre rundt til de forskellige kunder, hvis de skal havde hjælp til styring af maskiner eller hjælp til at stille dem op. Hierarkiet i KLU Materiel Nord A/S er en blanding af linie- og det funktionelle princip. Hver medarbejder ved normalt, hvem der er deres overordnede. Ulrik Knudsen og Michael Pedersen har begge to lige meget ansvar, så det kan skabe misforståelser eller konflikter, hvis lederne ikke får snakket ordentligt sammen. Eller at en af lederen har en højere status, og derved være den, som personalet hovedsagligt retter sig efter. Hvad angår opgaveløsninger giver alle en hånd med, hvis der er brug for det. Så selv Michael, som er souschef kan nogle gange skulle køre en maskine hen 4

13 til en kunde, selvom dette ligger uden for hans arbejdsområde. Dette er en nødvendighed da KLU Materiel Nord A/S er en lille virksomhed med få ansatte, så selvom der er stress på nogle gange, så bliver de nødt til at klare sig med de syv nuværende medarbejdere. Ved at ansætte ekstra arbejdskraft vil det give en større omkostningsbyrde for virksomheden. Ved at kigge på kontrolspændet for KLU Materiel Nord A/S, altså hvor mange underafdelinger eller personer som Kennith Lohmann har beslutnings og koordineringsansvar for. Kennith Lohmann har altså et kontrolspænd på to, da det kun er Ulrik Knudsen og Michael Pedersen, der er hans direkte underordnede. Da han kun er der ca. én gang om måneden er det mere rigtigt, at tjekke hvor stort kontrolspændet er på Ulrik Knudsen og Michael Pedersen, som jo står for den daglige ledelse af KLU Materiel Nord A/S. De har hver et kontrolspænde på fem medarbejdere. Dette gør at de har et meget større overblik og meget lettere, kan træffe beslutninger. KLU Materiel Nord A/S er en lille virksomhed med få ansatte, som hver især har forskellige arbejdsområder. Da de er så småt bemandet er det vigtigt, at de alle sammen skal være meget funktionelle og hurtigt kan omstille sig til en anden arbejdsopgave end de er vant til, hvis en skulle gå hen og blive syg eller forhindret på anden vis. Selvom at de nogle gange kan få rigtig travlt på grund af deres antal, er det ikke kun en ulempe af de ikke er så mange medarbejdere. De kommer nemlig til at få et meget bedre forhold indbyrdes. Dette er en stor fordel i dagligdagen, fordi der bliver kommunikeret meget bedre og derved sker der ikke så mange fejl ved at man misforstår hinanden. 5

14 2.2 Problemanalyse PROBLEMER HYPOTESER LØSNINGSMULIGHEDER Dobbelt arbejde i forhold arbejdsgange ved udfyldning af udlejningssedler Der findes ikke et IT-system til håndtering af lejeangivelser. Reservationer bliver udfyldt manuelt og derefter videregivet til Michael eller Ulrik, som taster data ind på computer og derefter udarbejder de en køresedler og fakturaer. IT til direkte at notere reservationer af materiel. Herefter generes data direkte videre så der hurtigt og effektivt kan udskrives køresedler, udlejningssedler og faktura. Registreringen foregår direkte og kun en gang. Derved minimeres risiko for fejl og misforståelser, når oplysninger skal videreformidles imellem flere personer. Lille arbejdsstyrke Mangel på overordnet it-strategi og eventuelt fremtidsvisioner. Det virker til at, det kører godt som det kører nu. Reklame sker fra mund til mund og via sælger. Og Herefter er virksomhedens mål, at opfylde kundernes ønsker så snart de opstår. Men er det nok. Kan der ske ændringer i fremtiden. Konkurrenceforhold Der er et begrænset antal medarbejdere ansat: 1 pladsmand, 1 chauffør, 2 montører, 1 sælger og de 2 overordnede( Ulrik og Michael). Sårbar overfor sygdom eller mange kundeanmodninger Virksomheden kan have svært ved at være forberedt til fremtidige krav og ønsker. Et marked med vækst giver også øget konkurrence. Allerede nu findes flere store konkurrenter. Der kan komme flere til. Hertz, som er kendt for biludlejning, er sidste nye konkurrent. Overvejelser over antallet af ansatte i forhold til arbejdsmængde og økonomi. Et altid velkendt problem for virksomheder, når ressourcer og behov skal gå op i en højere enhed. Nødplaner for alternative løsninger. Brug af udefrakommende arbejdskraft. Eksempelvis chauffører. Udarbejde en overordnet strategi, visioner og mål for virksomheden. Især inden for IT, da det er et marked der bliver større og større. Forventningen til at virksomheder i dag har IT-systemer, er noget som kunder forventer i takt med den almindelig samfundsudvikling. Konkurrenterne har det. Overvejelser over marketing og især det at være mere synlig, er noget som KLU Nord også skal overveje. Kan man bruge erfaringer eller samarbejde med samarbejdspartneren LOHKE Materieludlejning A/S. Klar definition af strategi, mål og ambitionsniveau i forhold til markedsandel, fremtidig vækst, marketing mm. Webhandel er det en mulighed? Konkurrenterne har det. Vi har taget udgangspunkt i de opstillede problemstillinger, og har herefter analyseret dem i ovenstående skema. Udfra beskrivelse af hypoteserne, har vi forslået en løsning til de problemer, som et nyt it-system vil give. Det nye IT-system skal være et samlet system, hvor man registrerer og samler alle data, og derved løser problemerne i forhold til KLU Materiel Nord A/S nuværende situation. Herefter udarbejdes en SWOT-analyse, hvor virksomhedens interne og eksterne situation analyseres. 6

15 2.3 SWOT INTERNE SITUATION STÆRKE SIDER Økonomisk velfunderet Godt arbejdsklima Fleksibel arbejdsrokering Hurtig responstid i forhold til levering og kundeservice God service Et marked med stor vækst Øget efterspørgsel i forhold til leje kontra købe EKSTERNE SITUATION MULIGHEDER Ekspanderende marked Forenkling af arbejdsgange ved hjælp af IT Satse mere på web-baseret udlejning og profilering SVAGE SIDER Konkurrence situation; Lille firma kontra store konkurrenter Begrænset udvalg på specialmateriel Lille arbejdsstyrke; Sårbar ved sygdom eller mange bestillinger Mangel på IT-strategi TRUSLER Øget konkurrence Begrænset varesortiment Kommentarer til skemaet: Ekspanderende marked: I Danmark er behovet for udlejning kontra køb af eget materiel, først lige begyndt. Der er et stort potentiale. Der er stadig en udpræget holdning, at man som entreprenør eller lignende skal eje sit eget materiel. I eksempelvis resten af EU, er forholdet imellem udlejning kontra køb af materiel helt anderledes: I EU er 70% af matriellet udlejet i forhold til DK, hvor det kun er 46% 7

16 Behovet for udlejning, vil være støt stigende, da virksomheder i kraft af omkostningsstyring, fravælger køb af dyrt materiel, og i stedet satser på udlejning, hvor man samtidig opnår en ekstra fordel, ved at materieludvalget bliver kraftig udvidet. En trussel for KLU Materiel Nord A/S er en øget konkurrence: I kraft af, at behovet for leje af materiel, er støt stigende vil konkurrence situationen højst sansynligt også ændres. Der vil altid være interesserede forretningsfolk, som er interesseret i at investere i en ekspanderende branche. Allerede nu, kan man se, at Hertz (som også er kendt for udlejning af biler) er gået ind på markedet. De har overtaget firmaet Dansk Lift A/S, og banker for alvor på, som en stor og kendt konkurrent. Udfra ovenstående SWOT analyse, og ved at vurdere KLU Materiel Nord A/S stærke og svage sider og muligheder og trusler, giver det en status over virksomheden lige nu. Ud fra denne analyse, kan KLU Materiel Nord A/S tilrettelægge sin fremtidige strategi. Det vil sige, at formulere en overordnet plan, udarbejde politikker og mål for virksomhedens fremtidige drift. Umiddelbart har KLU Materiel Nord A/S en overvejende posetiv SWOT-analyse. Der er fine muligheder for at fortsat at drive en sund og rentabel forretning, samt at kunne ekspandere i takt med nye muligheder, både i forhold til den øgede efterspørgsel efter lejet materiel, og en øget satsning på IT. Samtidig skal virksomheden have øget fokus på konkurrence situationen, som også hænger sammen med øget krav til IT-løsninger. Der mangler en overordnet IT-strategi, som vi bl.a. vil give et vurdering på Strategi analyse Ud fra SWOT kan udledes følgende mulige strategier. Maxi-Maxi: Fokus på at maksimere styrker og muligheder KLU Materiel Nord A/S er en virksomhed med service i højsædet, samt et helt specielt positivt arbejdsmiljø. Der er godt og fast kundegrundlag. Denne viden skal bibeholdes kombineret med at udnytte et kraftig ekspanderende marked på leje af materiel, samt øget opmærksomhed på ITløsninger og webhandel. Mini-Maxi: Fokus på at minimere svagheder og maksimere muligheder 8

17 Øget fokus på konkurrenter, samt overordnede strategier, for udviklingen af virksomheden i fremtiden. Især inden for IT, men også organisatorisk. Ændringer i medarbejderstyrken. Der kan blive et behov for ansættelse af IT-faglig, ekstra mandskab hvis virksomheden skal følge med den øgede efterspørgsel på lejet materiel. Mini-Mini: Fokus på at minimere svagheder og trusler Forbedre virksomhedens synlighed. KLU Materiel Nord A/S hjemmeside er svær at finde. Virksomheden lever af kendskabet fra mund til mund, samt opsøgning af kunder ved besøg af virksomhedens sælger. Er det nok - også i fremtiden? Forventes det, at KLU Materiel Nord A/S også kan tilbyde en webløsning? Dette skal vurderes og medtages i overordnet strategi. Maxi-Mini: Fokus på at maksimere styrker og muligheder samt minimere trusler Fortsætte udviklingen på grundlag af det eksisterende kundegrundlag samt viden, som KLU Materiel Nord A/S allerede har opbygget, samt at kunne levere godt materiel til konkurrencedygtige priser. Konklusion strategi analyse Udfra interview samt analyse af KLU Materiel Nord A/S, vil vi råde virksomheden til følgende: Hvis KLU Materiel Nord A/S ikke har en overordnet idé, strategi eller sat nogle operationelle mål, vil vi anbefale at man i samråd med direktøren udarbejder en sådan, gerne med udgangspunkt i vores anbefalinger. Udefra ser vi en økonomisk velfungerende virksomhed, som lever af deres eksisterende kunder, sælgerbesøg samt på anbefalinger som især virker fra mund-til-mund. På baggrund af SWOT-analysen kan man man med udgangspunkt i Ansoff s vækstmatrix, vælge i mellem tre strategier: Markedspenetrering: Her kan KLU Materiel Nord A/S især satse på prisen, people (de ansatte), processen. Prisdiffentiering, hvor man vægter prisen lidt lavere end konkurrenterne. People (ansatte): Kundekontakt og service, hvor man som lille virksomhed og med den helt specielle arbejdskultur og sammenhold, kan give en bedre og mere personlig behandling til sine kunder. 9

18 Proces: Effektivitet i forhold til logistik. Overholdelse af leveringsaftaler og hurtig responstid med mere. Markedsudvikling: Ud fra de nuværende produkter skal KLU Materiel Nord A/S satse på nye markeder. En nærliggende løsning vil være en bedre synlighed på nettet. Det skal være nemmere at finde firmaets hjemmeside, samtidig med at hjemmesidens design og opbygning skal forbedres. Vi vil anbefale, at man via sin nuværende leverandør eller ved valg en ny, kan forbedre hjemmesiden, så den bliver nemmere og hurtigere at bruge. Eksempelvis: Der skal være et godt blikfang. Overskuelige menuer, med enkle og hurtige links til det man søger. Der må godt være flere billeder, til understøttelse af fremvisninger. Der skal være søgefunktioner på kategorier, materiel mm. Derudover vil man kunne udbygge hjemmesiden til en større eller mindre e-business site. I første omgang kan man vælge, at tilbud eller/og ordrer kan ske via hjemmesiden. I sidste ende, kan så vælge den helt færdige e-commerce løsning. Dette kræver, at KLU Materiel Nord A/S, tager deres organisation op til revurdering. Det kræver andre krav til IT-udstyr, personale, og IT-eksperter. Produktudvikling: Som den sidste strategi, vil vi fokusere på valg af nye produkter til det nuværende marked. Kan der opstå nye behov i fremtiden. Hvilket materiel, vil der være efterspørgsel efter, materiellets stand og alder, nye regler og love kan påvirke efterspørgslen efter nyt materiel, eller ændrede krav til specifikationerne for materiellet. Her vil bl.a. det nye IT-system s muligheder for at køre statistik på materiellets rentabilitet, være et godt planlægningsværktøj. 10

19 2.4 Regnskabsanalyse Resultatopgørelse i 1000 kr Netto omsætning Vareforbrug Dækningsbidrag Kontante kapacitetsomk: -Salgsfremmende omk Lokaleomkostninger 477 -Personaleomkostninger Øvrige omkostninger Kontante kapacitetsomk. i alt Indtjeningsbidrag Afskrivninger 0 Resultat før renter Financielle omkostninger Nettoresultat før skat Nøgletal 2007 Overskudsgrad 23% Dækningsgrad 55.7% Det har ikke været muligt at få fat i balancen med aktiver og passiver, hvilket er hvorfor der ikke er flere nøgletal. Overskudsgrad(OG) viser hvor meget virksomheden tjener når de primære udgifter så som KKO og afskrivninger er fratrukket. I 2007 var OG 23%, hvilket betyder for hver krone de omsætter, har de omkring 23 øre i overskud. Dækningsgrad (DG) viser hvor meget virksomheden tjener på deres produkter, når vareforbruget(indkøbsprisen) og andre variable omkostninger er fratrukket. Det er med andre ord et nøgletal som viser hvordan den rå indkøbspris ligger i forhold til salgsprisen. Jo højere dækningsgraden er, destro lettere bliver det at betale andre omkostninger, og samtidigt få positive tal på bundlinien. I 2007 var DG 55,7%, hvilket vi betragter som positivt. 11

20 På baggrund af den manglende balance og tal fra kun ét år, er det svært at komme med en fuldstændig analyse. 2.5 Cost Benefit Direkte målelige omkostninger Anskaffelse af nye computere Hvis KLU Materiel Nord A/S skal investere i dette IT-system til brug af håndtering af udlejning, skal virksomheden ud at investere i et begrænset omfang af nyt hardware. Jf. kapitel omkring teknologi i foranalysen. Udgifter ved udvikling af systemet. Under udviklingen af systemet skal der afsættes penge til lønning af programudvikleren. Der skal yderligere betales for at få systemet implementeret i firmaets netværk. Programmet er ikke så omfattende og kan nemt implementeres med virksomhedens edb-system. Oplæring af medarbejdere Medarbejderne i virksomheden skal gennem en kortere oplæring for at lære det nye system at k- ende, før de kan gå i gang med at bruge det. Den største udfordring til brug af en IT-registrering vil være datadisciplin. Før blev alt skrevet manuelt på et stykke papir. Nu skal medarbejderen logge sig på systemet først og derefter foretage registreringer. Desuden skal der rettes opmærksomhed på reparationer. Disse skal også noteres i systemet. Når de tages ud til reparation og omvendt. Udgifter til IT support Umiddelbart skal der ikke ansættes en IT ansvarlig i firmaet, da systemet er så enkelt at gå til. Der kan laves en aftale eller kontrakt med programudvikleren, vedr. support Direkte målelige indtægter/omkostningsbesparelser Sparede lønomkostninger Indførslen af det nye system vil medfører en større effektivitet i lagerstyring og udlejning af materiel, hvilket betyder at en medarbejder kan udfører flere handlinger på kortere tid, og det betyder at 12

21 firmaet kan spare penge på løn. Den daglige arbedsgang bliver mere smidig og effektiv, og dobbelt arbejde undgås. Bedre lagerkontrol og større sikkerhed for at en vare er på lager Systemets lagerkontrol vil sikre et mere effektivt lager, hvor man altid ved hvilket materiel man har, hvor materiellet befinder sig, når de er udlejet samt hvilke er under reparation. Dette betyder at man har lettere ved at tilpasse sin lagerbeholdning, og binding af likviditet. Rentabilitetsanalyser på lager Ved hjælp af en statistik funktion, vil man hurtig kunne danne sig et overblik over, hvilket materiel der er rentable, hvor tit de udlejes mm. Herved vil man nemt og hurtigt, tilpasse sig en indkøbsstrategi i forhold til hvilke slags materiel, virksomheden skal tilbyde Indirekte/vanskeligt målelige omkostninger Negative sociale konsekvenser Med det nye system, skal der indføres en datadisciplin, som vil ændre den normale arbejdsrutine. Det som man altid har gjort, og som hidtil har virket, skal ændres. Det kan kræve en del tilvænning. Riskoen for fejl, kan opstå, hvis man ikke opretholder kvaliteten i sine registreringer. Bliver materiel noteret til reparation? Så de ikke fysik optræder på lageret. Man skal undgå, at man rent fysisk skal ud at tjekke lageret. En anden ting, som nok er af mindre betydning, er medarbejdernes forhold til edb. Er de vant til at bruge edb. Dog kan man forvente, at tilgangen og brugen af IT er blevet så almindeligt i dagens Danmark, at det vil være et naturligt krav, at medarbejderen selv kan bruge sytemet, med et en form for introduktions kursus til selve systemet Indirekte/vanskeligt målelige indtægter Forbedret kundeservice Med det nye system bliver salgsprocessen forbedret hvilket giver mulighed for en bedre og hurtigere kundeservice. Man vil hurtigere give tilbagemeldinger på lagerstatus, tidspunkt for hvornår udlejet udstyr forventes tilbage, samt kunderegistreringer og ændringer. Øget konkurrenceevne, da der kommer flere og flere konkurrenter på markedet. Flere af dem har allerede et velfungerende 13

22 IT-system og tilmed et website, hvor varerne kan bestilles direkte. Forbedret management muligheder Systemet tilbyder bedre muligheder for ledelsen, for at analysere statistik på udlejninger og kunder. Rentabilitet på de enkelte materiel, Antal udlejninger, antal reparationer, hvor ofte lejer kunden materiel og overblik over store og små kunder osv. Medarbejder tilfredsstillelse. Medarbejderne kan også få indsigt i lagerstatus og håndtering af udskrifter mm. Virksomheden bliver heller ikke så sårbar, hvis Michael eller anden leder ikke er til stede for at kunne indtaste data. Systemet tilbyder nye funktioner som gør medarbejderens arbejde lettere og mere overskueligt, og man undgår dobbeltarbejde. Før blev udlejningen fortaget manuelt og derefter videregivet til en overordnet, som så indtastede det i edb-systemet for at kunne udskrive en faktura. De økonomiske udgifter vil være forholdsvis begrænsede. Den største udgift vil være omkostninger til programudvikleren, men det vil stort set være et engangsbeløb. Udgifter til hardware vil være begrænsede, da krav til hardwaren ikke er særligt store og derfor billige at anskaffe. IT-systemet vil også gavne firmaet indirekte, da det vil øge kvaliteten af kundeservicen i forbindelse med en udlejning, samt på opfølgning og forspørgsler. Der vil ikke længere være tvivl om en given vares placering på lageret eller hos en kunde. Man vil hurtigt kunne give et svar over telefonen. Systemet vil også øge firmaets konkurrenceevne, da det giver mulighed for at udvide firmaet med en e-business afdeling i fremtiden, hvilket betyder at de kan nå ud til endnu flere kunder. Samlet set, vil implementeringen af udlejningssystemet medvirke til en given engangs udgift, men firmaet vil rimelig hurtigt kunne forrente denne investering i kraft af effektivisering af arbejdsrutiner, forbedret kundeservice, en øget konkurrenceevne og et bedre analyseredskab. Afslutningsvis vil det være en god ide for KLU Materiel Nord A/S at formulere en udvidet ITstrategi. Hvor er virksomheden på vej hen. Skal systemet udvides med en website på sigt. Hvilke krav stiller kunderne for fremtiden. Forventes der en øget tilgang via nettet, udover den personlige kontakt? Dette giver vi et bud på i afsnit 2.7 IT-strategi. 14

23 2.6 Konkurrenceforhold Vi har kigget på tre emner : Hjemmeside, Priser for udlejning og Udvalg af materiel til udlejning, for at afprøve konkurrenceforholdene mellem KLU Materiel Nord A/S og firmaer der tilbyder samme service Hjemmeside KLU Materiel Nord A/S er meget usynlige på Internettet. Deres site på nettet er meget minimalistisk og ser mindre seriøs ud end deres nærmeste konkurrenter. Deres største konkurrent er Hertz Materiel A/S, som har en mere informativ hjemmeside (Se figur 2.2). Hertz Materiel A/S er meget synlig på nettet og dukker blandt andet op som det første ved en søgning på "materieludlejning, Aalborg"på Krak ( som er en vejviser/telefonbog på Internettet. Også Nordjysk Lift A/S har en stærk profil på Internettet med mulighed for søge i deres varekatalog og tilbyder tilmed en konkurrence hvor både private og firmaer kan deltage og vinde gavekort til en værdi af kr Også andre konkurrenter har en bedre position på Internettet. Vi har kigget på følgende firmaer : Firma URL Kommentar Hertz Materiel A/S God repræsentation på Internettet Nordjysk Lift A/S Online konkurrencer, vind gavekort DNE Materieludlejning A/S DO-MA A/S http// Jydsk Materiel Udlejning Online udlejnings- og kalkulationssystem Lohke Materieludlejning A/S Samarbejdsparter på sjælland 15

24 Figur 2.2: Hertz Materiel A/S (April 2008) og KLU Materiel Nord A/S (2007) Priser for udlejning En samligning af priser viser at KLU har den fordel at de er billigere, med cirka 100 kr. i forhold til konkurrenterne på leje af maskiner. Priserner er indsamlet på det respektive hjemmesider i april måned Priserne er for leje per dag, ekskl. moms og afgifter og forsikring m.m. Eksempler: Manitou 160 ATJ, 16 m Bomlift KLU Materiel Nord A/S: kr Hertz Materiel A/S: kr Bobcat 553 minilæsser KLU Materiel Nord A/S: kr Nordjysk Lift A/S: kr Manitou MT 732 Teleskoplæsser KLU Materiel Nord A/S: kr DNE Materieludlejning A/S: kr Manitou ATJ Bomlift DO-MA A/S: kr KLU Materiel Nord A/S: kr

25 Hertz Materiel A/S: kr Lohke Materieludlejning A/S: kr DNE Materieludlejning A/S: kr Udvalg af material til udlejning Hertz Materiel A/S tilbyder leje af lifte med og uden fører. Her er KLU Materiel Nord A/S udvalg begrænset og mere tilpasset virksomheder med mindre enterprenør mæssige krav. 2.7 IT-strategi Umiddelbart virker det ikke som at KLU Materiel Nord A/S har en strategi for deres IT, derfor vil vi give nogle bud på, hvad de kan gøre. Ved at indføre mere IT i virksomheden, vil man kunne minimere det dobbelt arbejde som Michael sidder med. Som det er nu, i forbindelse med udlejninger, foregår det på papir. Dette betyder at alle i virksomheden kan foretage udlejninger, hvilket er positivt. Problemet er dog, at Michael skal sidde og taste disse informationer ind, fra papiret, til rammesystemet C5. Vi mener derfor, at det er aktuelt at benytte et system som kan erstatte denne process. For at virkningen kan måles, er det nødvendigt, at alle i virksomheden benytter det nye system. Det kræver en høj data diciplin hos medarbejderne, for at have pålidelige data. Der skal opstilles en computer på værkstedet, hvor montørerne har mulighed for at opdatere det materiel, de nu arbejder på. Det vil også højne effektiviteten og sikkerheden i virksomheden, fordi der ikke er noget papir, som kan blive væk, kragetæer som ikke kan tydes eller glemte aftaler. I og med at faktura-, følge- og ordresedler automatisk bliver udskrevet, gør det også arbejdsgangen lettere Formål Formålet med at lave et system er primært, for at skabe overblik, minimere fejl og undgå dobbelt arbejde. 17

26 2.7.2 Applikationer og Information På kort sigt: Mulighed for at give et overblik over hvad som er på lager. På lang sigt: Mulighed for at udskrive fakturaer direkte via Navision C5 samt vise statistik for maskiner Teknologi Det er nødvendigt med en database, for at kunne holde styr på materiel, tilbud, ordrer, kunder og så frem dels. Virksomheden har allerede en lokal central server, hvor det er muligt at installere databasen på. Selve programmet er ikke særligt krævende, de maskiner som står på kontoret kan sagtens køre programmet. Den maskine som skal anskaffes til værkstedet, så montørerne kan opdatere status, kunne f.eks. indeholde følgende hardware/software MHz 256 MB RAM Microsoft Windows XP Seneste JRE (Java Runtime Environment) fra For at opsummere nødvendigt materiel: 1 Computer, gerne af ældre dato 1 SQL server, f.eks. MySQL med InnoDB som er gratis Diverse kabler (netkabel, strøm, m.fl.) Handlingsplan Udviklingen af systemet foregår ved hjælp af en repræsentationsstrategi, hvilket betyder at virksomheden stiller involverede brugere til rådighed, som derfor er med i udviklingsforløbet af systemet. Dette sikrer at systemet i højere grad, bliver tilpasset brugernes krav og behov i virksomheden. En anden mulighed kunne have været en ekspertstrategi, som ville gøre udviklingen af systemet 18

27 lettere, da alle beslutninger kunne tages af udviklerne. Ulempen er medarbejderne i virksomheden, som skal bruge systemet, ikke har et tilhørsforhold da de ikke har været med under udviklingsforløbet. En anden ting som kunne tale for at benytte denne strategi er omfanget af systemet, da systemet er relativt lille og ikke særligt omfattende. Men vi har som sagt valgt at benytte repræsentationsstrategien. Implementeringen af det nye system vil komme til at forløbe på følgende måde: 1. Databasen bliver konfigureret. 2. En computer installeres på værkstedet og kobles på serveren. 3. Computerne på kontoret sættes op. 4. Systemet prøves af Videre udvikling Systemet er i princippet klar til at kunne videre udvikles med et website, som kører som en frontend til programmet. Alle de funktionaliteter som programmet har, vil også kunne laves på websitet. Derfor ville det være relevant at vurdere om tiden er til at lave en bestillingsside på websitet, ligesom mange af virksomhedens konkurrenter har. 2.8 Delkonklusion Igennem vores analyse af KLU Materiel Nord A/S kan vi konkludere at den IT-løsning vi vil udvikle helt klart vil kunne hjælpe og lette deres daglige arbejdsgang og effektivisere håndteringen af oprettelse og udlejning af materiel. IT-systemet ville også kunne integreres med deres eksisterende C5 løsning, således at udskrivning af faktura-, følge- og ordreseddel sker automatisk. Virksomheden bør investere i et bedre website med et professionelt look, hvor man kan søge i deres produkter. Derudover bør virksomheden overveje at gøre brug af Google Ad-Words på websitet så de er mere synlige på Internettet når potentielle kunder søger efter materiale udlejning. 19

28 Kapitel 3 Iteration 1: Kravspecifikation 3.1 Systemdefinition Systemet er et IT-system, som skal bruges af KLU Materiel Nord A/S. Systemet skal bruges i den daglige drift til registrering af udlejninger. Systemet skal være pålideligt og hurtigt da det skal erstatte et eksisterende papir system. Systemet baseres på computere som er koblet sammen i et netværk med en database. Systemet vil være et flerbrugersystem, da det både skal bruges på kontoret og på værkstedet. Selve udviklingsforløbet skal foregå i tæt samarbejde med brugeren. Betingelser Systemet kræver at brugeren har en let forståelse for brugen af IT. Systemet skal udvikles i samråd med brugeren. Anvendelsområde Er rettet specifikt mod KLU Materiel Nord A/S, men kan i princippet bruges af lignende virksomheder med samme virksomhedsgrundlag, nemlig udlejning. Systemet skal erstatte et gammeldags papir system virksomheden benytter nu. Teknologi Systemet kræver en database, som skal holde styr på varenumre, priser, datoer og så frem dels. Ydermere er det nødvendigt at opstille en terminal, med forbindelse til netværket, på værkstedet 20

29 hvor montørerne kan opdatere status på materiel. Objektsystem Udlejningsforløbet er det mest komplekse. Funktionalitet Systemet skal kunne håndtere udlejning af materiel, med alt hvad det nu indebærer. Det vil sige, antal, leveringsdatoer, afleveringsdatoer, priser, status på materiel, ordrebehandling, fakturaer, lagerstatus osv. Filosofi Hensigten med systemet, er at lette arbejdet for KLU Materiel Nord A/S i forbindelse med udlejningsforløbet. Dette gøres i høj grad ved at give et større overblik, da virksomheden er vokset betragteligt siden start og deres nuværende system har ikke denne mulighed. 21

30 3.2 Forretningsaktiviteter Login Salg Opret kunde Service Opret materiel Udlejning Ajourfør konto Modtag materiel Reserver materiel Udfyld udlejningsliste Ved overskredet betalingsfrist Ajourfør lager Hvis materiel er udlejet eller til reparation Udskriv udlejningsliste Udsend faktura Rykker Betaling Diagrammet viser hvad der sker, når man skal oprette en udlejning i klu. For at starte en udlejning starter en medarbejder med at logge på systemet. Herfra har medarbejderen flere muligheder. Han kan oprette et nyt stykke materiel til systemet, hvis de skulle få en ny maskine. Herefter kan han så oprettet en ny kunde eller hente en eksisterede i databasen. Nu kan han så oprette en udlejning, hvor han tilføjer en kunde og det materiel, som han ønsker at leje. Hvis det materiel, kunden ønsker at 22

31 leje ikke er på lager reserveres den. Når materiellet så er hjemme, bliver den tilføjet til udlejningen og lageret ajourføres. Så udskrives udlejningsliste og faktura udsendes. Hvis betalingsfristen bliver overskredet udsendes en rykker. Til sidst bliver betalingen udført. Salg og service har vi ikke beskrevet nærmere, da vores program først og fremmest er udviklet til at håndtere udlejning. 23

32 3.3 Prototype Første prototype, som vi viser eksempel på herunder, blev brugt i forbindelse med besøg hos KLU Materiel Nord A/S. Her gennemførte vi en pluralistic walkthrough (tænke-højt-test), for at se om de ideer, vi havde til vores GUI, levede op til virksomhedens ønsker. Der blev herefter noteret ændringer, som er tilrettet til den eksisterende version. Noterne er ikke vedlagt, da håndskriften og opstillingen ikke giver et præsentabelt dokument. Figur 3.1: Materiel fane 24

33 Figur 3.2: Kunde faneblad Figur 3.3: Udlejnings faneblad 25

34 Figur 3.4: Udlejnings faneblad Figur 3.5: Opdater ordre faneblad 26

35 3.4 Domænemodel Vores domænemodel af KLU Materiel Nord A/S er en hjælp til at få et overblik over hvilke klasser vi skal have i vores program. Da det er udlejning, vi skal lave til KLU Materiel Nord A/S har vi en Rental klasse. Rental har en aggregering til RentalItem da Rental skal være oprettet for at RentalItem kan blive lavet. Customer og Employee klassen er associeret sammen med Rental. RentalItem er associeret med Equipment. Domænemodel for KLU Materiel Nord A/S. Udlejning af materiel til såvel private som erhvervskunder Employee RentalItem 1 0..* Rental 1 1..* 1..* Customer 1 0..* 1..* Equipment 27

36 3.5 Use Case Oversigt Vi har udfra vores use case diagram som kan findes i appendix.3 lavet følgende oversigt, hvor vi laver en beskrivelse og prioritering. Højeste prioritet er 1 og laveste 10. USE CASE BRIEF BESKRIVELSE BRUGER SYSTEM RANG createcustomer Kunde henvender sig til medarbejder for at Høj Mellem 5 blive oprettet som kunde searchcustomer Medarbejder indtaster kundeoplysninger, Mellem Lav 6 kundenr eller navn i søgefelt for kunde searchequipment Medarbejder indtaster vareoplysninger i søgefelt Mellem Lav 6 for vare addequipment Når varen er fundet, tilføjes varen til liste Mellem Lav 6 reserveequipment Hvis varen er udlejet eller til reparation, kan Høj Høj 2 kunden bede medarbejderen om at reservere vare med angivelse af start og slutdato, ligesom en normal udlejning removeequipment Medarbejder kan fjerne vare fra liste, hvis Mellem Lav 6 kunde fortryder at leje den pågældende vare startdate, enddate expectedenddate Medarbejder angiver hhv. start- og slutdato, samt forventet slutdato på liste, efter forespørgsel til kunde Lav Lav 7 28

37 USE CASE BRIEF BESKRIVELSE BRUGER SYSTEM RANG createrental En kunde henvender sig til en medarbejder, Høj Høj 1 for at leje et stykke materiel. DiscountRate, InsuranceRate confirmrental createequipment statisticsequipment statisticsorder / Customer Medarbejder angiver rabat, forsikring, mm som led i udlejningsoprettelse Lav Lav 7 Medarbejder bekræfter de indtastede lejeoplysninger, Mellem Lav 6 for at systemet herefter er klar til at udskrive følgeseddel/ ordrebekræftelse. Lageret bliver samtidigt reguleret En ny vare bliver oprettet med angivelse af Mellem Lav 6 varens attributter. Medarbejder kan via systemets statistikopfølgning, Mellem Høj 3 tjekke op på varens historik. Købspris, antal udlejninger, indtjening mm. Kan bruges som redskab til at vurdere varens rentabilitet. Hvilke typer varer skal man især satse på mm. Medarbejder kan via systemets statistikopfølgning, tjekke op på kundens samlede ordrer. Herved kan medarbejderen danne sig et overblik over hvor ofte kunden lejer, Den samlede lejeindtægt, hvilket materiel kunden benytter mm. Mellem Høj 4 Som det kan ses ud fra tabellen er den højeste prioritet createrental. Derfor har vi naturligvis også valgt at arbejde videre med denne use case. 29

38 3.6 Delkonklusion I den første iteration har vi gjort det klart hvilke krav, der er til det nye system. Dette har vi gjort ved at lave en systemdefinition, med en beskrivelse af et IT-system til styring af udlejning, bygget op på en database. Dette skal forenkle virksomhedens arbejdsmetoder, samt kunne give et værktøj til at foretage statistik på materiel og kunder. Vi har udarbejdet et diagram med KLU Materiel Nord A/S forretningsaktiviteter. Prototypen er de første mock-ups, som vi fremviste virksomheden i forbindelse med en brugertest. (Tænke højt test). I domænemodellen har vi udvalgt vores klasser og deres forbindelser, angivet med multiplicitet. Følgende klasser er valgt: Customer, Employee, Rental, RentalItem, Equipment. En oversigt over use cases er udarbejdet, hvor vi har listet og vægtet de forskellige use cases. Vi har valgt at arbejde videre med den mest komplekse use case: createrental. Denne use case kan ses i et aktivitetsdiagram. (se bilag I.1 i appendix). Ud fra kravsspecifikationen er vi nu klar til at foretage en dybere analyse. 30

39 Kapitel 4 Iteration 2: Analyse 4.1 Aktørbeskrivelse IT-systemet har følgende brugere. Montører/Pladsmand: Deres primære opgave er at opdatere systemet i henhold til statusen på materiellet. Muligheden for at gøre det direkte sikrer den nødvendige datadiciplin. Ydermere har de også mulighed for at lave en udlejning. Kontor: Deres primære opgave er at styre udlejningsdelen. Det vil sige oprettelse af varer, redigering af varer, sletning af varer. De har også mulighed for at se statistik på materiel. 4.2 Use Case Fully dressed beskrivelse af use casen: createrental: Aktør: Medarbejder Pre-betingelse: Medarbejder er logget ind og materiellet er på lager. Post betingelse: Kunden er registreret, materiellet er udlejet, lageret er nedskrevet, ordre er oprettet og bekræftelse er udskrevet. 31

40 Main Succes Scenario: 1. En kunde henvender sig til medarbejder for at oprette en udlejning 2. Medarbejder åbner fanebladet "udlejning " 3. Medarbejder indtaster kontonr. 4. Systemet returnerer kundeoplysninger 5. Medarbejder forespørger kunde om udlejningsønsker 6. Kunde angiver materieloplysninger 7. Medarbejder indtaster materielnr./materielnavn 8. Systemet returner materieloplysninger samt lagerstatus 9. Medarbejder tilføjer materiel til ordreliste 10. Systemet tilføjer automatisk fordefinerede værdier. Eks. lejepris 11. Medarbejder beder kunde om start- og slutdato sat forventet slutdato 12. Kunde angiver periode 13. Medarbejder indtaster periodeoplysninger i udlejningsliste 14. Medarbejder forespørger kunde om leveringsoplysninger 15. Kunde angiver leveringsoplysninger 16. Medarbejder indtaster firmanavn, adresse, postnr., by, tlf., samt evt. bemærkninger Punkt 5 til 18 gentages ved yderligere udlejningsønsker 17. Medarbejder bekræfter ordren 28. Systemet returnerer en ordrebekræftelse og ajourfører lager 19. Medarbejder beder systemet om at printe bekræftelse som bruges både som køreseddel og ordrebekræftelse til kunden 20. Medarbejderen afslutter samtalen med kunden og afslutter udlejningen på systemet. Alternative scenarier: Kunden er ikke registreret 1. Kunden er ikke registreret hos virksomheden 2. Medarbejder beder om oplysninger til registrering af kunde 3. Kunde angiver kundeoplysninger 4. Medarbejder indtaster oplysningerne i kundefane 5. Medarbejder bekræfter oplysninger og trykker udfør Materiellet er udlejet 1. Kunden anmoder om materiel 32

41 2. Medarbejder indtaster materielnr eller materielnavn 3. Systemet returnerer materieloplysninger samt lagerstatus 4. Medarbejder må meddele kunde, at materiel er udlejet, og forventes tilbage til en angivet slutdato 5. Kunde angiver, om dato for udlejning harmonerer med materiellets hjemkomst til virksomheden 6. Hvis ikke, vil medarbejderen finde en alternativ metode, ved at finde et tilsvarende materiel andet steds, som kan udlejes på samme betingelser for kunden. Materiel er til reparation 1. Kunden anmoder om materiel 2. Medarbejder indtaster materielnr eller materielnavn 3. Systemet returnerer materieloplysninger samt lagerstatus 4. Medarbejder må meddele kunde, at materiellet er til reparation og forventes tilbage til en anslået dato. 5. Kunde angiver, om dato for udlejning, harmonerer med dato for at materiellet bliver klarmeldt. 6. Hvis ikke, vil medarbejderen finde alternative metoder, for at tilfredsstille kundens behov. Rabat/ forsikring forhandles til en anden sats (tilføjelse efter punkt 13 i main succes scenario) 14. Kunde og medarbejder forhandler ny rabatprocent i forbindelse med udlejning. 15. Medarbejder indtaster og ændrer procentsatsen i udlejningslisten. (De forud aftalte satser, der følger den enkelte kunde, kan overskrives hvis nødvendigt) 16. Derefter punkt 14 til 20 i main succes scenario) Systemet melder fejl ved indtasting 1. Kunde anmoder om et materiel 2. Medarbejder indtaster materielnr eller materielnavn 3. Systemet returnerer materieloplysninger samt lagerstatus 4. Ved indtastning af lejeoplysninger, sker det helt utænkelige, at systemet melder fejl. 5. Medarbejder prøver at finde årsagen til fejl 6. Medarbejder prøver at genstarte udlejningsdelen og oprette udlejning forfra 7. Hvis system stadig melder fejl, afslutter medarbejder indtastning på computer 8. Medarbejder foretager nødprocedure. 9. Medarbejder noterer udlejning manuelt på virksomhedens blanketter, som blev brugt før det nye IT-system. 10. Herefter foregår registrering, som i "gamle dage" 11. Medarbejder afslutter samtalen med kunden 33

42 12. Medarbejder henvender sig til systemudvikler, som vil løse problemet. 13. Når systemet er oppe at køre igen, indtastes den manuelt noterede ordre i systemet. 34

43 4.3 System Sekvens Diagram Bruger System 1: createrental(idrental) LOOP 2: FetchCustomer(phone) 3: addrentalitem() 4: add(startdate, enddate,...) 5: addrentalbytransactions(r) 6: updaterentalitemobj() 7: finish() Vi har udeladt returpilene fra systemet til bruger, for at diagrammet ikke skulle blive for pladskrævende. Returpilenes tekst giver også sig selv, i forhold til metodekaldene til systemet. Vi er klar over vi allerede har foretaget et design valg i beskrivelsen af system sekvens diagrammet med hensyn til tilføjelse af dato og levering. 4.4 Operationskontrakt I forlængelse af use casen: createrental beskriver vi hermed den med en operationskontrakt. Vi har valgt kun at demonstrere brugen af en operationskontrakt. Der kunne godt udarbejdes flere operationskontrakter, men vi har ikke fundet det nødvendigt, da princippet i opbygningen er den samme. Operation: createrental() Use Case: createrental 35

44 Pre betingelse: Materiel findes på lager, Kunde er registreret med faste oplysninger for rabat og forsikring Post betingelse: Et rentalobjekt blev oprettet Et rentalitemobjekt blev oprettet. Et Customerobjekt er associeret til rental. Et Equipmentobjekt er associeret til rentalitem, søgt ved hjælp af equipmentid RentalItem er tilskrevet startdate, enddate, expectedenddate, deliveryaddress og transport DBRental og DBRentalItem er tilskrevet attributværdier. 4.5 Delkonklusion I anden iteration har vi kigget nærmere på analysefasen, hvor vi har arbejdet videre på de krav vi har beskrevet i iteration 1. Vi har to aktører til systemet: Montører/pladsmand og kontorpersonalet. Derefter er den mest komplekse use case createrental blevet beskrevet i en fuld version med alternative scenarier. Vi har udarbejdet et system sekvens diagram, med brugerens kommandoer til systemet, beskrevet som en black-box. Herefter har vi beskrevet Operationskontrakterne for createrental, hvor kontrakten fungerer som et slags interface til systemet. Dette bliver herefter afprøvet i design og implementeringen i iteration 3. 36

45 Kapitel 5 Iteration 3: Design og implementering 5.1 Arkitekturovervejelse En arkitektur er en overordnet strukturform i et system. Til udviklingen af dette system benytter vi en lagdelt arkitektur, som består af tre lag. Disse tre lag er opdelt i et Modellag, Controllerlag og GUIlag. Den tre delte arkitektur kan udvides, og eftersom vi har behov for at tilgå en database udvider vi det nederste lag med et DBlag. Kommunikationen mellem lagene er nedadgående, så GUIlaget kommunikerer med Controllerlaget og Controllerlaget kommunikerer med Modellaget og DBlaget. I vores DBlag benytter vi en Singleton, som betyder at vi kun opretter én instans af database forbindelsen. Meningen med at bruge en lagdelt arkitektur, er at skabe en forståelig og fleksibel struktur af systemet. Dette medfører, at systemet bliver lettere at udføre vedligeholdelse på. Det at bruge den lagdelte arkitektur skaber i første omgang mere kode arbejde, men alternativet er, at man undlader at bruge lag og får skrevet koden hurtigere, men så betaler prisen senere i form af besværet vedligehold. Princippet i en lagdelt arkitektur er, at man deler de forskellige niveauer, i vores tilfælde tre, op i 37

46 pakker eller lag. Hver pakke får så hvert sit ansvar for en del af systemets funktioner, og man ønsker her at skabe lav kobling og høj binding. Lav kobling fordi, man ikke ønsker at klasser skal være afhængige af andre klassers implementation, hvilken vil kunne besværliggøre vedligeholdsarbejde på systemet betydeligt. Binding er et mål for hvor tæt relateret de forskellige ansvars områder er i en klasse. Hvis metoderne der tilhører en klasse har stor lighed, siges klassen at have høj binding. Det hjælper med at holde koden læsbar og forhøjer muligheden for at kode bliver genbrugt Kodestandard Vi har valgt at designe vores klasser og dermed også feltvariabler, metodehoveder og funktionskald på engelsk da det primært hænger bedre sammen med vores udviklingsmiljø. Desuden synes vi at et metodehovede skrevet på engelsk er mere sigende end et tilsvarende på dansk. printminstock() Udover at programmere på engelsk bruger vi også kamelnotation, hvilket betyder at når ens metodehovede er bygget op af flere ord, skal første bogstav starte med stort. Det er især anvendeligt hvis man har et langt metodehovede connectmatchidwithbrackettype() 38

47 5.2 Patterns I dette kapitel vil vi analyse og dokumentere vores brug af patterns (mønstre). Grundliggende har vi 9 GRASP mønstre/ principper: Creator Information Expert Low Coupling High Cohesion Controller Polymorhis Pure Fabrication Indirection Protected Variations Low Coupling-pattern Dette mønster bruger vi sammen med den tredelte lagdeling. Lav kobling fordi klasserne skal være uafhængige. Dette mønster hænger sammen med High Cohesion pattern. High Cohesion-pattern Dette mønster bruger vi sammen med den tredelte lagdeling. Høj binding fordi det gør koden mere overskuelig og lettere at vedligeholde, samt at det kode kan genbruges. Dette mønster hænger sammen med Low Coupling pattern. Controller-pattern Dette mønster bruger vi som et led i den tredelte arkitektur. Dette gør vi da det giver højere fleksibilitet, såfremt UI en skal udskiftes. Controlleren er altså det første lag bag GUI laget som koordinerer efterfølgende operationer.vi har en "Controller"for hver af vores aktører - projektleder, projektchef, sælger og medarbejder; dvs. GRASP controller. Creator-pattern Vores liste følger også princippet "Creator"i GRASP-pattern. Dvs. at vores eks. B klasse har ansvaret for oprettelse af en instans af A hvis B aggregerer A objekter. Rental indeholder en liste af Rental- Items. Dette mønster bruger vi i forbindelse med vores GUI lag. Vi har valgt at give GUI laget adgang 39

48 til Model laget, da det har mange fordele fremfor at få Controller laget til at sende trivielle objekter frem og tilbage. Ydermere ville det kræve meget kode på Controller laget, så som get-metoder. Dette fremmer ikke low coupling and high cohesion, men det gør det nemmere at programmere. Vi har valgt denne løsning, selvom det kræver lidt opmærksomhed, hvis man vil udskifte GUI-laget. CustomerGUI CustomerCtr c : Customer CustomerDB 1: create(idcustomer, idcity,..) 2: cctr.addcustomer(c) 3: addcustomer(customer c) 4: return rc 5: return rc 40

49 Singleton-pattern Ved et singleton-pattern forstås, at det er kun en klasse, der er ansvarlig for at oprette et objekt. Klassens attributter indkapsles ved at gøre dem private, og kan kun tilgås udefra igennem et statisk metodekald. Dette mønster bruger vi i sammenhæng med database forbindelsen. Ved at bruge dette mønster sikrer vi at der kun bliver oprettet en instans når systemet starter, som efterfølgende bliver brugt så længe systemet kører. 1 //Constructor 2 private DBConnection() { 3 String url = driver + databasename; 4 try { 5 Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); 6 } 7 catch(exception e) { 8 System.out.println("Can not find the driver"); 9 System.out.println(e.getMessage()); 10 } 11 [ Rest of function omitted..] Listing 5.1: DBConnection.java 41

50 5.3 Interaktionsdiagram GUIRental RentalCtr CustomerCtr RentalItemCtr EquipmentCtr r:rental ri:rentalitem DBRental DBRental DBRentalItem DBCustomer DBCustomer c:customer DBEquipmentC DBEquipmentC ategory 1: create(idrental) 2: create() 3: create() 4: ri 5: return(r, ri) 6: r, ri 7: FetchCustomer(Phone) 8: FetchCustomer(Phone) 9: CreateCustomer(idCustomer,idCity,ContactPerson...) 10: Customer(c) 11: Customer(c) 12: Customer(c) 13: addrentalitem() 14: fetchequipmentbyid(int i) 15: Equipment(eq) 16: Equipment(eq) 17: addrentalusingtransaction(r) 18: addrentalusingtransaction(r) 19: updaterentalitemobj() 20: Finish() DBEquipment 42

51 Dette er et interaktionsdiagram over createrental. Et interraktionsdiagram er et diagram der viser alle de metodekald som sker ned i gennem klasserne i programmet. I dette diagram starter metokladet ude fra RentalGUI med at createrental() som så sender metode videre til Controllerlaget. Herefter bliver den så sendt videre ned i Modellaget til Rental klassen der så opretter et nyt Rental objekt. Herefter bliver Rental objektet så sendt tilbage til RentalGUI en. Nu skal der så tilføjes en kunde til Rental objektet. Der startes ikke med at blive oprette en ny kunde i databasen da i henhold til use casen i prebetingelsen allerede skal være oprettet en kunde. Nu skal kunden bare hentes i databasen, så metodekaldet starter fra RentalGUI en ned til CustomerCtr med fetchcustomer(phone). CustomerCtr sender så metodekladet fetchcustomer(phone) ned til DBCustomer som henter Customer i databasen. DBCustomer sener så metodekladet createcustomer(idcustomer,idcity,contactperson...) ned til Customer klassen som opretter et nyt Customer objekt, som bliver sendt tilbage til CustomerCtr og så hen til RentalGUI. Efter Customer er tilføjet sender RentalGUI metodekladet addrentalitem() ned til EquipmentCtr som sender fetchequipmentby Id(int i) ned til DBEquipment som henter EquipmentObj ned til E- quipmentctr og så hen til RentalGUI en. RentalGUI sender så addrentalusingtransaction ned til rentalctr som sender metode kaldet videre ned til DBRental, hvor rentalobj bliver gemt i databasen. RentalGUI en sender så medtoden addrentalusingtransaction(r) ned til RentalCtr som sender den ned til DBrental som gemmer den ned i databasen. RentalGUI sender så updaterentalitemobj() som går ned til DBRentalItem som tilskriver til databasen. Så er Rental oprettet. 43

52 5.4 Designklassediagram Employee (from Logical View) String Username String Pwd int ID String tostring() Customer (from Logical View) int idcustomer int idcity String ContactPerson String String Company String Street int Phone 1 int Mobile int Fax Double DiscountRate Double InsuranceRate String Comments 1 0..* 0..* RentalItem (from Logical View) int idrentalitems int idequipment String idrental boolean iscollection boolean isoverweight String StartDate String EndDate String ExpectedEndDate Double RentalCost Double DiscountRate Double InsuranceRate int idcity String DeliveryStreet String DeliveryComments 1..* 1 Rental (from Logical View) String idrental int idcustomer String RentalDate ArrayList<RentalItem> ri ArrayList<RentalItem> getlist() 1..* get/set metoder er ikke vist. 1..* Equipment (from Logical View) int idequipment int EquipmentCategory String Equipmentnumber String Title String Description String TechnicalData Double DimmLength Double DimmWidth Double DimmHeight Double DimmWeight Double RentalCost String ServiceStatus String tostring() Klasser I det følgende er en beskrivelse af modellens klasser Employee Registrering af ansatte i KLU Materiel Nord A/S, som har adgang til systemet. Klassen er associeret til Rental, hvor én (1) ansat er associeret nul-til-mange (0..*) udlejninger. Customer Registrering af både private og erhvervskunder. Customer er associeret til Rental, hvor én (1) kunde er associeret nul-til-mange (0..*) udlejninger. 44 File: C:\Documents and Settings\Administrator\My Documents\Skole\Datamatiker\2. semester\projekt\klunord\documents\klu Nord.mdl 15:40: maj 2008 Class Diagram: Use Case View / DesignKlasseDiagram Page 1

53 Equipment Registrering af maskiner og andet materiel hos KLU Materiel Nord A/S. EquipmentObjekt er tilknyttet en-til-mange (1..*) RentalItemObjekter. Rental Registrering af de forskellige udlejninger. Rental er den centrale klasse, og er aggregeret klasse til "RentalItems"således at ét (1) RentalObjekt er tilknyttet en-til-mange (1..*) RentalItemObjekter. Desuden er Rental er associeret til Employee og Customer RentalItems Registrering af maskiner og andet tilhørende en udlejning (Rental), hvor hver materiel er en "Rental- Item". Klassen er aggregeret til Rental og associeret en-til-mange (1..*) EquipementObjekter. Attributter på RentalItems StartDate og EndDate er faste værdier, der som regel ikke vil være behov for at ændre efter oprettelsen. ExpectedEndDate er hvad lejeren anslår eller udlejer angiver, og kan derfor ændres flere gange inden enheden kommer retur. RentalCost er de samlede omkostninger for leje dette materiel. Beløbet skal blandt andet bruges til at holde rede på de samlede udlejningsudgifter, på baggrund af DiscountRate og InsuranceRate der angiver henholdsvis den rabatsats og forsikringsats for materielet, samt iscollection og isoverweight, der angiver om materielet bliver afhentet eller leveret og om denne er over 7 tons. Alle det nævnte værdier er individuelle for hver objekt og kan sættes om ønsket ved oprettelse af udlejning. idcity og DeliveryStreet angiver den individuelle leveringsadresse, standard er kundens adresse. DeliveryComments er en kort beskrivelse henvendt til fragtmanden omkring levering. 45

54 5.5 Overvejelser under implementering Database generelt Da vi har valgt at benytte en gratis RDBMS i form af MySQL er der et par problematikker som er værd at nævne. For det første har MySQL mange forskellige storage-engines som kan bruges på tabeller, hvor de to mest kendte er MyISAM og InnoDB Der er fordele og ulemper ved begge, men det som er værd at bide mærke i at MyISAM ikke understøtter transaktioner hvor InnoDB gør. I vores system har vi et behov for transaktioner, så derfor bruger vi selvfølgelig InnoDB. Dette betyder også vi har mulighed for at bruge savepoints og rollback i koden. 46

55 1 try { 2 // Sæt AutoCommit til false, så der ikke comittes efter executeupdate() 3 con.setautocommit(false); 4 // Opret et Statement objekt og lås databasen 5 Statement stmt = con.createstatement(); 6 stmt.setquerytimeout(5); 7 // n-mange sql queries 8 stmt.executeupdate(qry1); 9 stmt.executeupdate(qry2); 10 stmt.executeupdate(qryn); 11 // Eftersom AutoCommit er sat til false skal vi explicit gøre det 12 con.commit(); 13 // Nedlæg objektet nu 14 stmt.close(); 15 } 16 //Såfremt vores sql-queries ikke gik godt, ender vi hernede 17 catch(sqlexception ex) { 18 try { 19 // Rul databasen tilbage til sidste gyldige commit 20 // Dvs, selvom 1 qry gik godt, og resten failede, bliver den gode også fjernet. 21 con.rollback(); 22 System.out.println("Rolling back!"); 23 } catch(exception ex1) { 24 System.out.println("Error rolling back"+ ex1); 25 } 26 } Listing 5.2: Eksempel for commit/rollback Client-Server model Næste release af systemet vil formentligt blive tråd baseret, hvilket betyder at kritiske metoder i systemet skal beskyttes med synchronized og wait() / notifyall(). En hel anden løsning på flerbruger problemet kunne være at benytte en Client-Server model. Idéen med en Client-Server løsning er at klienterne kun snakker sammen med applikations serveren. Applikations serveren står så for håndteringen af alt som har med SQL serveren at gøre. Dette sikrer i teorien samtidighedsproblemet. Denne løsning har vi dog ikke valgt at implementere grundet omfanget deraf. 47

56 SQL Server Store O notation I forbindelse med vores Login, hvor vi checker om username og password fra inputfelterne stemmer overens med det som står i databasen, henter vi alle Employees ned fra databasen, gemmer data som objekter og tilføjer dem til en ArrayList. Dette betyder også at vi er tvunget til i worstcase at løbe alle objekter i listen igennem. Dette betyder at gennemløbstiden er O(n). I vores tilfælde hvor der formentlig ikke vil blive mere end fem Employees, er det ikke et kæmpe problem, men hvis man forestillede sig at vi kunne have Employees var implementeringen overhovedet ikke smart. Den måde vi burde have implementeret checket på, er ved at lade databasen stå for det. SELECT Username, Pwd FROM Employee WHERE Username = test AND Pwd = test ; Databasen er væsentligt hurtigere til at søge rækker igennem, når Username og Pwd er kendt udfra index. Gennemløbstiden er nemlig kun O(log(n)) kontra O(n). n = O(n) O(log(n), 2) 20 Dette betyder at i worstcase ville hastigheden være ved O(n) mens hastigheden ville være 20 ved O(log(n)). 48

57 5.6 Database design Oversigt over database tabeller Figur 5.1: Diagram over tabel-relationer i systemet. Som det ses i designklassediagrammet (5.4), udgør "Rental"den centrale klasse, denne transformeres til tabellen Rental. Ligeledes er de resterende klasser transformeret til deres respektive tabeller i databasen. Desuden er der en tabel EquipmentCategory, som muliggører sorting af materiel under diverse kategorier og en tabel City, til håndtering af postnummer -> bynavn Normalisering Grunden til tabellen RentalItems indeholder attributter, der kan ses som redundans af data, skyldes et eksplicit ønske fra KLU Materiel Nord A/S, om at disse værdier skal kunne sættes individuelt for hvert materiel, ved hver udlejning. Derfor vil disse attributter kun indeholde værdier, når det er nød- 49

58 vendigt, ellers kalkuleres disse ude fra de centrale værdier i tabellerne Customer (attributterne: DiscountRate og InsuranceRate) og Equipment (attribut: RentalCost). Samme gælder for attributterne idcity der sammen med DeliveryStreet og DeliveryComments, kun udfyldes hvis der nødvendigt. 2. Normalform Alle vores attributter er fuld funktionel afhængige af hele primærnøglen og dermed på anden normalform og derfor også på første normalform.. 3. Normalform Et eksempel på 3. normalform er at bynavn er bestemt af dets postnummer, så derfor har vi oprettet tabellen City, med attributterne idcity for postnummer og City for bynavn, derved er bynavn ikke indirekte/ikke transitivt afhængig af primærnøglen idcustomer i tabellen Customer eller af idrentalitems i tabellen RentalItems. 5.7 Implementering Gennemgang af væsentlig kode og metoder for GUIRental der bygger på vores mest komplekse use case : createrental Generelt omkring oprettelse GUI vinduer For at der kun kan instantieres kun ét (1) GUI vindue, sættes det respektive objekter til static final. Alle på nær GUIStatus er private, da det er nødvendigt at kunne tilgå metoden initcontentformodel() i klassen GUIStatus, fra klassen GUIRental, for at kunne opdatere listen over udlejninger "live", hver gang der oprettes en udlejning. 1 private static final GUICustomer gcustomer = new GUICustomer(); 2 private static final GUIRental grental = new GUIRental(); 3 private static final GUIEquipment gequipment = new GUIEquipment(); 4 public static final GUIStatus gstatus = new GUIStatus(); Listing 5.3: Objekt af en klasse kan kun instantieres én gang 50

59 5.7.2 Dato styring Figur 5.2: Valg af periode for udlejning. Dato styring (se figur 5.2) er implementeret ved hjælp af "SwingX - JXDatePicker- plugin Beregning af antal arbejdsdage Til at beregne antal arbejdesdage i perioden (StartDate til EndDate) har vi implementeret metoderne wdnum() og diff(). Disse metoder er tilkommet via forum på internettet, DeveloperFusion 2 Metoden wdnum() returner antallet af arbejdsdage, ved at kalkulere antal dage siden den 1. jan- 1 SwingLabs Swing Component Extensions: 2 DeveloperFusion: 51

60 uar 1970, (gettime() divideret med antal millisekunder der i en dag), adder derefter 3 til resultatet og returner antal arbejdsdage i alle uger i måneden og eventuelt også antallet af de arbejdsdage, i en partiel uge, hvis måneden indeholder det. Metoden diff() udregner ved hjælp af wdnum() antallet af arbejdsdage I periode EndDate og S- tartdate. Desværre virker metoden kun hvis man vælger en hel uge (mandag til mandag/søndag til søndag), ved kortere perioder fejler metoden, så denne værdi kan kun bruges som vejledende. 1 public long diff(date d1, Date d2) { 2 return wdnum(d2) - wdnum(d1); 3 } 4 private long wdnum(date date) { 5 long l = date.gettime() / 1000 / 60 / 60 / ; 6 return 5 * (l / 7) + Math.min(l % 7, 5); 7 } Listing 5.4: Beregning af antal arbejdsdage Individuelle værdier For at kunne sætte individuelle værdier, så som rabatsats, forsikringssats og leveringsadresse samt evt. meddelelse vedrørende levering, for hver enkelt materiel i en udlejning, er det nødvendig at have en metode updaterentalitemobj(), der opdaterer det enkelte RentalItem objekt med de individuelle oplysninger. Først kaldes en metode enablerentalitemdetails() som aktiver panelet (figur 5.4) hvor der kan indtastes individuelle oplysninger. 52

61 Figur 5.3: Som standard er panelet disabled. Den bliver aktiv når der vælges en materiel på listen og deaktiveres igen efter opdatering af de individuelle værdier. Figur 5.4: Der kan sættes individuelle værdier for hvert materiel ved hver udlejning. 53

62 1 2 /* 3 * Da der flere steder er brug for vide hvilken række der er aktiv/valgt, oprettes metoden getselectedrow() 4 * Returner den valgte række i tabellen 5 */ 6 private int getselectedrow() { 7 int rowcount = jtable.getselectedrow(); 8 return rowcount; 9 } 10 private void updaterentalitemobj() 11 { 12 // Hvilken række er valgt I tabellen 13 int rowcount = getselectedrow(); 14 // Hent Objektet af typen RentalItem på plads rowcount fra ArrayList<RentalItem> i Objektet Rental 15 RentalItem ritemobj = rentalobj.getlist().get(rowcount); // Sæt det individuelle værdier for den valgt materiel 18 ritemobj.setdiscountrate(double.parsedouble(newdiscountrate.gettext())); 19 ritemobj.setinsurancerate(double.parsedouble(newinsurancerate.gettext())); 20 ritemobj.setiscollection((iscollectionselection.isselected())); 21 if (isoverweightselection7tons.isselected()) { 22 ritemobj.setisoverweight(true); 23 } 24 ritemobj.setdeliverystreet(deliverystreet.gettext()); 25 int tmpidcity = Integer.parseInt(CityZIP.getItemAt(CityZIP.getSelectedIndex()). tostring()); 26 ritemobj.setidcity(tmpidcity); 27 ritemobj.setdeliverycomments(deliverycomments.gettext()); // Fjern eksisterende Objekt RentalItem på pladsen rowcount 30 rentalobj.getlist().remove(rowcount); // Tilføj ny Objekt RentalItem med de nye værdier på pladsen rowcount i ArrayList< RentalItems> i Objektet Rental 33 rentalobj.getlist().add(rowcount, ritemobj); /* 36 * For at det kun skal være muligt at rette værdier for den valgte materiel på listen, kaldes metoden 37 * disablerentalitemdetails(), som deaktiver panelt der tillader indstilling af 38 */ individuelle værdier. 39 disablerentalitemdetails(); } Listing 5.5: updaterentalitemobj() 54

63 5.8 Test Cases junit I forbindelse med implementeringen er det muligt at lave test cases i Netbeans. Disse test cases kan man lave efter hver klasse er skrevet. Test cases kan modificeres således at de kan teste alt - konstruktør, get/set funktioner, abstrakte funktioner og så frem dels. Det smarte ved test cases er hvis man foretager ændringer i strukturen af klasserne. Hvis der bliver tilføjet en ekstra variabel, en ekstra funktion, en ændret returtype eller andet. Hvis man i en klasse har en metode der afhænger af en andens klasses konstruktør, og der bliver lavet ændringer til konstruktør, vil det jo med stor sandsynlighed betyde at metoden fejler. Dette er muligt at se hvor fejler ligger hvis man har lavet test cases da det virkede. Test cases er især gode hvis man ikke sidder og udvikler på det samme projekt hele tiden, og måske har svært ved lige at huske hvilke ting som afhænger af hinanden. I dette projekt har vi også benyttet et par test cases, men måske ikke i samme omfang som vi burde. Vi har derimod lavet vores egne interaktive tests med systemet, hvor vi har testet ydergrænser af(negative tests) og almindelige positive tests Brugervenlighedstest Da vi lavede vores brugergrænseflade til vores udlejningssystem tog vi udgangspunkt i Jacob Nielsens regler. Det første punkt er let at lære. Vi har delt vores GUI med et Login. Efter man har logget ind, har vi delt GUI en op i fem kategorier; udlejning, materiel, kunde, status og statistik. Så man får let et overblik og kan hurtigt og enkelt vælge de grænseflader, man skal bruge. Vi har skrevet hele brugerænsefladen på dansk så brugeren ikke skal til at sætte sig ind i et andet sprog. Det andet punkt er, at det er let at huske. Vi har lavet udlejnings GUI en sådan, at man kun skal have ét vindue åbent, for at kunne oprette en udlejning. Udlejnings GUI en er bygget op, så man starter fra toppen med at tilføje kunde og materiel. Herefter vælger man perioden for udlejningen og specifikke ting til leveringen. Til sidst trykker man på: Opret Udlejning. Vi har opbygget vores GUI er logisk, så det er let at huske, hvilke oplysninger man skal bruge, når man for eksempel skal oprette en ny 55

64 kunde. Jacob Nielsens tredje punkt handler om, at brugergrænsefladen skal være pålidelig at bruge. Eksempelvis, når man opretter et nyt materiel. Man må ikke overskrive materiel, der allerede ligger i databasen. Eller hvis man skal logge på og man bruger et ugyldigt tegn, så hele systemet ikke går ned, men viser en fejlmeddelelse. Det næstsidste punkt er, at brugergrænsefladen er effektiv at bruge. Her skal de to første punkter være opfyldt, for at dette kan være gældende. Der skal også tages højde for fejl, der kan opstå. Hvis der opstår fejl, skal der være fejlmeddelelser, som kan hjælpe brugeren videre. Dette har vi gjort med udlejning-, kunde- og materiel GUI en, hvor den skriver, at alle felterne skal være udfyldt for man kan oprette eksempelvis en kunde. Det sidste punkt er, at grænsefladen skal være tilfredsstillende at bruge. Den skal for første opfylde alle de overståede punkter. Hernæst skal man kunne lave alle de ønskede oprationer fra grænsefladen som brugeren ønsker. 56

65 5.8.3 System I forbindelse med testning af systemet, har vi afprøvet diverse scenarier. Først og fremmest normalscenariet, men derefter har vi også afprøver grænsetilfælde. Både for at se, om de indlagte fejlmeddelelser kommer frem, eller hvordan data bliver påvirket. (Vi har løbende foretaget test under implementeringen.) Eksempelvis: Når man skal oprette en udlejning skal man først finde en kunde som er i databasen ud fra kundes telefonnummer. Hvis telefonnummeret er ugyldigt eller ikke findes i databasen kommer den op med en fejlmeddelelse om at man skal indtaste et gyldigt kunde nr. Når man går ned, for at tilføje materiel, skal man først havde tilføjet en kunde, da den ellers kommer med en fejmeddelelse, om at der ikke er valgt en kunde. Når kunde er fundet, kan man vælge materiel ud fra kategori, og herefter tilføjes det specifikke eksemplar. Man kan ikke vælge et marteriel, 57

66 som er udlejet i forvejen eller hvis den er til reparation. Derefter vælges periode med en startdato, slutdato og en forventet slutdato. Der sker nogle gange fejl i optællingen af udlejningsdage. Hvis man kommer til at tilføje det samme eksemplar, kommer en fejlmeddelelse, at det materielnr allerede er tilføjet Man kan trykke på det tilføjede eksemplar og redigere i det valgte materiel s oplysninger. Herefter vil udlejningen blive oprettet og gemt. Hvis man kommer til at tilføje den forkerte kunde, skal man nulstille hele vinduet, fordi man kun kan tilføje en kunde. Hvis man vil oprette en ny kunde, kan man ikke skrive et telefonnummer, som allerede eksisterer i databasen. Når man vil oprette et nyt materiel, kan der ske en fejl da man for eksempel, kan havde flere gravemaskiner af samme mærke, med samme materielnummer Accept Accepttesten er planlagt til mandag d. 10. juli, hvor vi vil fremvise programmet til KLU Materiel Nord A/S. 5.9 Delkonklusion Arkitekturen er blevet en tredelt lagarkitektur, med et GUI-, Controller- og et Modellag, som er tilknyttet et databaselag. Det giver et system, som er nemmere at vedligeholde i fremtiden. Den fastsatte kodestandard er overholdt. I forbindelse med implementeringen af koden, har vi haft fokus på forskellige mønstre Jf. GRASP-mønstre har vi beskrevet Low Coupling, High Cohesion, Creator og Controller, som har været vigtige elementer i forhold til implementeringen. Indenfor design-mønstrene har vi især brugt et Singleton-mønster. interaktionsdiagrammet viser bevis på brug af mønstre, samt beskriver vores metodekald i den mest komplekse use case: createrental, og hvordan systemet kommunkerer inden for vores black box. Designklassediagrammet, som er udbygget fra domænemodellen med atrributter og lister. Implemetationen af den mest komplekse kodedel. 58

67 Implementeringen af koden er der foretaget flere overvejelser: Oprettelsen af GUI klasserne kunne med fordel, være implementeret ved brug af Singleton design patterns. En del af metoderne kunne evt. flyttes i selvstændige klasser, således de ikke er indkodet i GUI-klasserne. Metoden for udregning af arbejdsdage indenfor en given periode skal opdateres til en version der virker 100%, måske kan dette implementers ved brug af SQL script der udregner dette, når der køres et kald på datoerne i tabellen RentalItems. Afledningsvis har gennemført forskellige testscenarier: JUnittest. Testcases i Netbeans. Brugervenlighedstest. Krav til vores interface Systemtest. Testning af programmet, som det fungerer lige nu. Accepttest er aftalt til at gennemføres mandag d. 9. juni 2008 hos KLU Materiel Nord A/S. 59

68 Kapitel 6 Planlægning En af de første dage i projektforløbet startede vi med at lave et udkast til en iterations opdelt tidsplan. På denne tidsplan lavede vi alle de punkter som vi på det tidspunkt havde en fornemmelse af vi skulle rundt omkring. Tidsplanen har gennem hele projektet været en støtte, hvor vi har kunne danne os et overblik over hvor langt vi var. Selvom vores iterationer er ændret lidt i forhold til tidsplanen, har vi alligevel valgt at vise den, da punkterne er ens, omend de står andre steder her i rapporten. Hver uge holdt vi møde med vores vejleder, for at få respons på de ting som vi arbejdede med. Vi brugte også de forskellige lærere undervejs, som vi har haft til de respektive fag. Vi brugte whiteboards, som vi havde i vores grupperum. På dem skrev vi en ugeplan op, hvor noget af tidsplanen var på, men også hvad der ellers måtte være, f.eks. møder. Disse ugeplaner har vi taget billeder af. Vi har kun medtaget ugeplanerne, hvor der er sket ændringer i forhold til ugen forinden, og sat dem ind længere nede i dette kapitel. Udover det førte vi også en logbog, hvor vi skrev hvad der overordnet blev arbejdet med hver dag. Den kan findes i appendix.5 En af de ting som tog meget af vores tid var at parse KLU Materiel Nord A/S varekatalog igennem og indsætte informationen i databasen. Vi havde fået et udtræk fra virksomhedens eget katalog, i en ren tekst fil, men den var ikke opdelt efter kategorier. Så det krævede lidt ekstra arbejde for at få dette opdateret i databasen. Vi brugte også lang tid på at finde en måde hvorpå vi kunne håndtere datoer. Her fandt vi et plugin i form af SwingX som kunne dette, men ikke i det datoformat vi havde brug for. Så dette skulle vi 60

69 også finde ud af at konvertere. Vi har arbejdet sammen som én gruppe, og med én mener vi at gruppen ikke har været opdelt i flere undergrupper hvor nogen arbejdede på det samme hele tiden, mens andre arbejdede på noget andet. Nej alle i gruppen har rørt ved de forskellige processer som vi har arbejdet med undervejs. Når det så er sagt, er det også naturligt nok at hvert gruppemedlem har en niché, en styrke, noget som de er gode til, og dette har de selvfølgelig fået lov til at arbejde videre med, ligeså vel som de ting som haltede er blevet trænet i det omfang det har været muligt. 61

70 6.1 Tidsplan ID Task Name Duration Start Finish 28 Apr '08 05 May '08 12 May '08 19 May '08 26 May '08 02 Jun '08 M T M T W M T W M T W M T W M T T F S S W T F S S T F S S T F S S T F S S T F S S W T 1 Analyse 3 days? Fri Tue Virksomhedskarakteristik 3 days? Fri Tue SWOT 3 days? Fri Tue Costbenefit 3 days? Fri Tue Konkurrenceforhold 3 days? Fri Tue IT-strategi 3 days? Fri Tue Delkonklusion 3 days? Fri Tue Iteration 1 8 days? Wed Fri Kravspecifikation 8 days? Wed Fri Aktivitetsdiagram 8 days? Wed Fri Domænemodel 8 days? Wed Fri Use Case oversigt 8 days? Wed Fri Delkonklusion 8 days? Wed Fri Iteration 2 6 days? Mon Mon Arkitekturovervejelser 6 days? Mon Mon Aktørbeskrivelser 6 days? Mon Mon Use Case 6 days? Mon Mon Operationskontrakt 6 days? Mon Mon System Sekvens Diagram 6 days? Mon Mon Delkonklusion 6 days? Mon Mon Iteration 3 6 days? Wed Wed GRASP 6 days? Wed Wed UML 6 days? Wed Wed Implementering 6 days? Wed Wed Test 6 days? Wed Wed Delkonklusion 6 days? Wed Wed Konklusion 2 days? Thu Fri Kontrol af rapport 2 days? Mon Tue Aflevering 1 day? Wed Wed Project: Tidsplan.mpp Date: Fri Task Split Progress Milestone Summary Project Summary External Tasks External Milestone Deadline Page 1 62

71 6.2 Ugeplaner Figur 6.1: Uge 18 Figur 6.2: Uge 19 Figur 6.3: Uge 20 Figur 6.4: Uge 23 63

72 Kapitel 7 Konklusion Denne rapport er udarbejdet i samarbejde med KLU Materiel Nord A/S. Virksomheden har et ønske om at få implementeret et udlejningssystem til deres materiel, som på sigt kan implementeres med deres administrative rammesystem. Virksomheden har ikke fremsat nogen kravsspecifikation eller designdokumentation. Disse er blevet til i dialog, bl.a. ved virksomhedsbesøg og . KLU Materiel Nord A/S er en økonomisk velfungerende virksomhed, med et godt arbejdsmiljø. I kraft af at være en lille mandskabsstyrke, har virksomheden opnået en dynamisk arbejdsdeling, hvor alle hjælper alle. Det giver en mere harmonisk organisation, trods stillingsbetegnelse. Risikoen er, at man er meget sårbar overfor sygdom, perioder med ekstraordinært travlhed mm. Virksomheden vil kunne få stor gavn af et nyt udlejningssystem, som vil forenkle arbejdsgangene og give KLU Materiel Nord A/S, både et bedre strategisk redskab samt på sigt gøre dem mere nutidige og konkurrencedygtige. Især hvis de forstærker synligheden og brugervenligheden på deres website, som med tiden kan udvides til e-handel. Vi vil foreslå, at KLU Materiel Nord A/S inddrager vores konklusioner i deres IT-strategi, som del af en overordnet strategi, for virksomhedens udvikling i fremtiden. Vi har udviklet et program, der kan håndtere kunder, materiel, materieludlejning og ordrestatus. Statistikdelen er ikke blevet færdigudviklet, men hensigten var at kunne følge op på materiel og 64

73 kunder. I forhold til håndtering af samtidighed, havde vi nogle overvejelser om, hvordan vi kunne styre dette. Vi har tilføjet en transaktion ved oprettelse af et rentalitem. Data bliver tilbageført ved systemfejl, til tidspunktet før indtastning. En anden udfordring var, at konvertere virksomhedens databaseoplysninger til vores database. Dette projekt på 2. semester, har været en meget lærerig proces, hvor vi har tilegnet os ny viden indenfor de relevante fagområder. Vi har arbejdet som en velfungerende gruppe, hvor der altid har været et højt humør, men også en vilje til at arbejde med rapporten og udlejningssystemet. 65

74 Del I Appendix 66

75 .1 Hvem har skrevet hvad? 1 Indledning (Heine) 1.1 Problemformulering (Fælles) Afgrænsning af projektet Spørgsmål 2 Foranalyse 2.1 Virksomhedskarakteristik (Mathias) Organisation (Mathias) 2.2 Problemanalyse (Jesper) 2.3 SWOT (Jesper) Strategi analyse (Jesper) 2.4 Regnskabsanalyse (Heine) 2.5 Cost Benefit (Jesper) Direkte målelige omkostninger Direkte målelige indtægter/omkostningsbesparelser Indirekte/vanskeligt målelige omkostninger Indirekte/vanskeligt målelige indtægter 2.6 Konkurrenceforhold (Nallaik-Kumaran) Hjemmeside Priser for udlejning Udvalg af material til udlejning 2.7 IT-strategi (Heine) Formål Applikationer og Information Teknologi Handlingsplan Videre udvikling 2.8 Delkonklusion (Mathias & Nallaik-Kumaran) 3 Iteration 1: Kravspecifikation 3.1 Systemdefinition (Heine) 3.2 Forretningsaktiviteter (Jesper & Mathias) 3.3 Prototype (Fælles) 3.4 Domænemodel (Fælles) 3.5 Use Case Oversigt (Jesper & Heine) 67

76 3.6 Delkonklusion (Jesper) 4 Iteration 2: Analyse 4.1 Aktørbeskrivelse (Heine) 4.2 Use Cases (Jesper) 4.3 System Sekvens Diagram (Fælles) 4.4 Operationskontrakt (Jesper) 4.5 Delkonklusion (Jesper) 5 Iteration 3: Design og implementering 5.1 Arkitekturovervejelse (Heine) Kodestandard 5.2 GRASP Patterns (Jesper & Heine) 5.3 Interaktionsdiagram (Fælles) 5.4 Designklassediagram (Heine) Klasser (Nallaik-Kumaran) 5.5 Overvejelser under implementering Database generelt (Heine) Client-Server model (Heine) Store O notation (Heine) 5.6 Database design (Nallaik-Kumaran) Oversigt over database tabeller Normalisering 5.7 Implementering (Nallaik-Kumaran) Generelt omkring oprettelse GUI vinduer Dato styring Beregning af antal arbejdsdage Individuelle værdier 5.8 Test Cases junit (Heine) Brugervenlighedstest (Mathias) System Accept 5.9 Delkonklusion (Jesper & Nallaik-Kumaran) 6 Planlægning (Heine) 6.1 Tidsplan 6.2 Ugeplaner 7 Konklusion (Fælles) 68

77 .2 Visualisering af Fully Dressed Use Case add CustomerId create Customer Hvis vare er udlejet eller til reparation add EquipmentId remove Equipment Reserve Equipment add Equipment update equipment storage add startdate, completion date, Expeted complet... Angiv Rabat, Forsikring mm Bekræft Ordre Systemet ajourfører automatisk lageret Udskriv Ordrebekræftelse, Følgeseddel Afslut ordre 69

78 .3 Use Case Diagram find Customer find equipment add equipment create customer remove equipment Leder Medarbejder reserve equipment show statistic on equipment show statistic on customer set rentalstartdate, rentalendda... create rental set discount, insurrance a.m. 70

79 .4 Brugermanual til materialeudlejning Programmet er beregnet til at foretage udlejning af materiel, samt håndtering af materiel, kunder og statistik. Programmet kan tilpasses, så det kan køre sammen med rammesystemet C5. Inden programmet startes kan man installere 1 stk. SQL-server, f.eks. MySQL med InnoDB som er gratis. Der er tilknyttet en SQL-server til programmet. 1. Programmet åbnes ved at dobbeltklikke på filen : KLUNord.jar 2. Login menu popper op Se figur: 1 og felterne brugernavn og password udfyldes begge med ordet: test og tryk herefter "OK". 3. Et menuoversigt med følgende 5 muligheder dukker op: Se figur: Udlejning Se figur: 3 4. Udlejning vælges, når der skal foretages en materieludlejning. Det forudsættes, at kunden allerede er oprettet. 5. Udlejningsvinduet åbner sig. Øverst i venstre hjørne indtastes kundenr. Hvilket er kundens telefonnr. I eksemplet bruges følgende nr: og tryk "Søg". 6. Herefter vil man få listet kundeoplysninger op til højre i skærmbilledet. Derudover vil forudindtastede værdier for rabat, forsikring blive vist i "standardværdier for kunde", samt leveringsadresse vil være forudangivet med kundens egen adresse i "leveringsadresse". Disse værdier kan ændres. Dette kan ses i punkt: Ved hjælp af de 2 dropdown boxe, vælger man kategori og dertilhørende materiel. 8. Startdato angives eller vælges fra dropdown panel, og herved forevises status for det enkelte materiel i "Status for materiel". Der er følgende statusværdier: "Klar", "Udlejet", "Udgået"og "Reparation". 9. Slutdato og forventet slutdato angives eller vælges fra dropdown box. (Forventet slutdato er en dato for, en formodet forlængelse af udlejningskontrakten for det enkelte materiel.) Herefter vil antal dage blive listet umiddelbart under datoangivelsen. Disse dage er det som prisen for udlejningen beregnes ud fra. 10. Efter angivelse af datoer, vælges "Tilføj"umiddelbart under datoindtastningen. 11. Herefter vil man kunne se det valgte materiel blive listet i feltet lige under med angivelse af 71

80 Materielnr., Navn, start-, slut- og forventet slutdato. 12. Der er nu mulighed for at søge et nyt stykke materiel, som angivet foroven. 13. Rækken for det enkelte materiel kan markeres, og herved har man mulighed for at fjerne det valgte materiel eller man kan tilføje rettelser til de forud angivne værdier i feltet "Oplysninger til det valgte materiel". 14. Ny leveringsadresse kan angives med evt. bemærkninger. 15. Afkrydsning for afhentning eller at materiellet skal leveres. Der er 2 takster for levering, hvor man kan vælge mellem en takst under eller over 7 tons. 16. Nye værdier for rabat og forsikring kan indtastes, hvis forudangivne oplysninger skal ændres. 17. Herefter "opdateres"oplysningerne. 18. Efter færdig indtastning foretages "opret udlejning"og udlejningen gemmes i status. 19. Derefter kan udlejning nulstilles, og ny kunderegistrering kan foretages..4.2 Materiel Se figur: 5 1. Vælg Materiel i menu oversigten. 2. Materielvinduet åbner og her kan man både søge, opdatere eller tilføje materiel. 3. Ved nyoprettelse vælges kategori eller indtastes. 4. Data indtastes i "Materiel", "Materielnr", "Navn", "Beskrivelse", "Lejepris", "Teknisk info", "Dimensioner"og "Status" 5. Tryk "Gem som ny". 6. Ved opdatering, søges et stykke materiel. 7. Kategori og materiel vælges ud fra dropdown bjælken. 8. Dataværdier angives i de respektive felter. 9. Ændringer af dataværdier indtastes. 10. Tryk "opdater"og materiellet ajourføres..4.3 Kunde Se figur: 6 1. Vælg Kunde i menuoversigten. 2. Kundevinduet åbner, hvor man kan søge, opdatere eller tilføje kunde. 72

81 3. Ved nyoprettelse indtastes data i "Firma", "Kontaktperson", "Adresse", "Postnr", "Telefon", "Mobil", "Fax", " ", "Bemærkninger", "Rabatsats"og "Forsikringssats". 4. Tryk "Gem". 5. Ved opdatering, indtastes telefonnummer på kunde i søgefeltet "Find Kunde". 6. Tryk "Søg". 7. Data for den pågældende kunde listes i de forskellige felter. 8. Ved ajourføring af data, rettes det pågældende felt med nye data. 9. Tryk "Gem"og kundedata opdateres..4.4 Status Se figur: 4 1. Vælg Status i menuoversigten. 2. Statusvinduet åbner, hvor man kan se status på afgivne udlejninger. 3. Firma, ordreid og ordredato angives for den enkelte udlejningsaftale. 4. Ved valg af række med et angivent firma, fremkommer beskrivelse af materiel, startdato, slutdato, forventet slutdato, samt pris. 5. Nederst i højre hjørne opgøres den samlede pris, beregning af moms samt den endelige pris inklusiv moms. Ved flere rækker af lejet materiel, beregnes den samlede pris for hele ordren..4.5 Statistik Statistikdelen er ikke blevet implementeret. Vi arbejder på sagen, men ideen er, at man kan bruge statistikken til at undersøge eksempelvis, hvor rentabel et stykke materiel er. Anskaffelsespris, reparationer, antal udlejninger med angiven indtjening indtastes, og herved kan man følge op på økonomien og bruge erfaringen, til fremtidige investeringer. Det samme kan gøres, ved at føre statistik på virksomhedens kunder. Dette vil være et godt strategisk redskab for virksomhedens ledelse. 73

82 .4.6 Billeder til brugermanual Figur 1: Login Figur 2: Oversigt Figur 3: Udlejning Figur 4: Status over udlejning 74

83 Figur 5: Materiel Figur 6: Kunde Administration.5 Logbog Torsdag 21. Februar 2008 Første møde med KLU Materiel Nord A/S Rundvisning Aflevering af problem formulering Fredag 22. Februar 2008 Udarbejdelse af Prototype Onsdag 27. Februar 2008 Udarbejdelse af Prototype Fredag 11. April 2008 Udarbejdelse af Prototype Onsdag 23. April 2008 Fremvisning af Prototype ved Michael Meningen med mødet var at få respons på prototypen. Vi havde lavet prototypen i netbeans, og kunne derfor fremvise den. Michael havde ikke set andre udkast før denne. Michael havde flere gode ideer, hvor forløbet kunne optimeres, mest i henhold til opsætningen af udlejning. 75