Planlægningssystem til autoværksted.

Størrelse: px
Starte visningen fra side:

Download "Planlægningssystem til autoværksted."

Transkript

1 Side 1 af 49 Planlægningssystem til autoværksted. udført af Henning Svensson Kim Damgaard Indholdsfortegnelse Planlægningssystem til autoværksted... 1 Indholdsfortegnelse... 1 Beskrivelse af autoværkstedet... 2 Problemformulering... 2 Autoværkstedets vision... 2 Inception-fasen... 3 Krav til systemet... 3 Definition af system grænse... 3 Primære aktører... 3 Primære aktørers mål... 4 Definer Use Cases... 5 Supplerende specifikation... 7 Planlægning af næste iteration... 8 Udviklingsplan... 9 Forfinet vision Ordliste Go - No go? Elaboration-fasen Aktivitetsdiagram UC1 "Basic Flow": Testovervejelser System Sekvens Diagram Domain Model Kontrakter Detaljeret design Sekvensdiagrammer Systemarkitektur Det videre forløb Bilag Bilag 1: Beskrivelser af Use Cases i "Brief Format" Bilag 2: SystemTester.java: Bilag 3: Output ved kørsel af klassen SystemTester Bilag 4: Kildetekst til selve programmet... 37

2 Side 2 af 49 Beskrivelse af autoværkstedet Autoværkstedet beskæftiger 1 værkfører, 15 mekanikere, 3 lærlinge samt en kontorassistent. Det er primært kontorassistenten og værkføreren, der i dag tager sig af henvendelserne fra kunderne. Kundehenvendelserne sker enten telefonisk eller ved personlig henvendelse og drejer sig typisk om reservation af tid til reparation eller service. Ud fra de løbende reservationer udarbejdes planer for den enkelte mekanikers arbejdsdag. Disse udføres manuelt i dag, primært af værkføreren samt kontorassistenten. Mekanikerne har forskellige arbejdstider, men med samme ugentlige timetal. Der sker løbende ændringer i de ressourcer der er til rådighed på værkstedet, fordi de ansatte, som kan have specielle kompetencer, bytter arbejdstid, bliver syge osv. Ferie planlægges op til 1 år frem i tiden. Autoværkstedet har omkring 1500 stamkunder, der er registeret med diverse person-oplysninger samt oplysninger om deres biler (registreringsnr., mærke, årgang etc.). Til autoværkstedet er der tilknyttet en brugtvognshandel, således at mekanikerne kan arbejde på klargøring af biler til salg, når de ikke udfører reparationer eller service for kunder. Problemformulering Autoværkstedet ønsker at frigøre noget af den tid, der benyttes på kundehenvendelser og den manuelle planlægning. Værkføreren vil hermed, i højere grad, kunne bidrage med sine meget stærke kompetencer på værkstedet. Kontorassistenten vil kunne øge sin indsats på en række administrative opgaver. Endvidere opleves det i dag tit, at kunden ikke kan få ordentlig besked vedr. reservation, da værkføreren og kontorassistenten mangler overblik som følge af den manuelle planlægning. Det manglende overblik gør det også mere besværligt, at efterkomme kundernes ønsker om akutte reparationer. Den manuelle planlægning medfører i visse situationer, at mekanikerne ikke arbejder optimalt. Enten arbejder de på forkerte opgaver set i relation til deres færdigheder eller set i relation til at få bilerne klar til den lovede tid. Indtastning i økonomi-systemet af mekanikernes Job-registreringer forgår manuelt, og tager unødig tid for kontorassistenten. Afholdelse af ferie kolliderer nogle gange med ordremængden, hvilket måske kunne undgås, hvis autoværkstedet blev bedre til at forudsige fremtidige behov for ressourcer. Autoværkstedets vision Autoværkstedet ønsker et system, som kan reducere tidsforbruget til behandling af kundehenvendelser og planlægning. De har en ide om at kunne tilbyde kunderne en form for "Self service" således, at kunderne selv kan varetage nogle af de funktioner som værkføreren og

3 Side 3 af 49 kontorassistenten i dag varetager. Endvidere skal arbejdsplanerne udarbejdes/opdateres automatisk. Der ønskes en integration til autoværkstedets økonomi-system, således at mekanikernes tidsforbrug samt fravær (ferie, sygdom osv.) automatisk kan overføres fra det nye system. Systemet skal kunne opsamle forbrugte ressourcer således, at historiske data periodisk set kan anvendes i den fremtidige planlægning. Afgrænsninger Det skal bemærkes, at vi har nedtonet, og nogle steder helt undladt, beskrivelser vedr. tilgang til systemet via Internettet for at begrænse denne opgaves omfang. Derudover har vi udeladt alt omkring reservedele/reservedelslager. Inception-fasen I denne fase undersøges det om, der skal investeres i en mere dybdegående analyse af problemdomænet. Med andre ord: Skal vi efter denne fase starte på Elaboration-fasen? Endvidere er det vigtigt at få afklaret om projektets interessenter er enige om visionen for projektet. Inception-fasens varighed bør som hovedregel være kort, hvilket typisk vil sige 1-2 uger. Krav til systemet Man kan med fordel kategorisere kravene efter FURPS+ modellen, for bl.a. at minimere risikoen for at glemme krav til systemet. For at finde samt dokumentere de funktionelle krav (F'et i FURPS+) benyttes Use-Case modellen, hvor ideen er at fokusere på hvorledes brugeren/aktøren, ved at bruge systemet, kan få sine mål opfyldt. Fremgangsmåden er at vælge system-grænse, identificere primære aktører; identificere primære aktørers mål og slutteligt definere Use Cases, der opfylder aktørernes mål. Definition af system grænse Systemet består af selve applikationen samt hardwaren og kan tilgås vha. et lokalt brugerinterface eller via Internettet. Uden for system grænsen er aktører samt autoværkstedets økonomi-system. Primære aktører Vi har fundet frem til følgende primære aktører: Kontorassistent Værkfører Mekaniker Lærling Kunde IT drift (pt. kontorassistenten/ Værkfører med en anden kasket på ). Overvågningsproces Tiden Det er indlysende, at kontorassistenten og værkføreren er primære aktører til systemet. De resterende aktører er afdækket gennem samtaler med nogle af de ansatte i autoværkstedet. Under samtalerne har vi stillet dem en række spørgsmål eksemplificeret ved følgende liste:

4 Side 4 af 49 Hvem vedligeholder kundeoplysninger? Hvem vedligeholder oplysninger om de ansatte? Hvem skal kunne reservere tider i værkstedet? Hvem skal starte og stoppe systemet? Hvordan planlægges den enkelte ansattes arbejdstid? Hvad skal der ske hvis systemet fejler eller går ned? Skal der ske af handlinger på givne tidspunkter, eller med givne tidsintervaller? Primære aktørers mål Aktør Kontorassistent Værkfører Mekaniker Lærling Kunde IT drift Overvågningsproces Tiden Mål Reservere tid til service/reparation på værkstedet for kunder. Ændre reservation for kunder. Afbestille reservation for kunder. Minimere tidsforbrug til registrering af mekanikernes tidsforbrug samt fravær. Reservere tid til service/reparation på værkstedet for kunder. Ændre reservation for kunder. Afbestille reservation for kunder. Minimere tidsforbrug til registrering af mekanikernes fravær. Udarbejde arbejdsplaner for mekanikere. Se arbejdsplan. Registrere tidsforbrug. Registrere fravær. Se arbejdsplan. Registrere tidsforbrug. Registrere fravær. Reservere tid til service/reparation på værkstedet. Ændre reservation. Afbestille reservation. Oprette/vedligeholde egne kundeoplysninger. Blive orienteret om gode tilbud osv. Start systemet. Luk systemet ned. Genstarte system-processer, der er gået ned. Meddele IT drift vedr. system-fejl. Kopiere personale-oplysninger fra økonomisystem. Kopiere kunde-oplysninger fra økonomi-system. Udskrive liste over nye/ændrede kundeoplysninger. Udsende nyhedsbreve, tilbud osv. Indkalde til service.

5 Side 5 af 49 Definer Use Cases En Use Case ifbm. kravanalyse for en software applikation bør, som en tommelfingerregel, omhandle forretningsprocesser på et niveau defineret som følger: En handling (som respons på en forretningsbegivenhed) udført af én person på ét sted på én gang, der tilfører målbar værdi til virksomheden og efterlader data på et konsistent stade. Ved at gennemgå listen over de primære aktørers mål og med ovenstående definition in mente, har vi på nuværende tidspunkt identificeret følgende Use Cases: UC1: UC2: UC3: UC4: UC5: UC6: UC7: UC8: UC9: UC10: UC11: UC12: UC13: UC14: UC15: UC16: UC17: Reserver tid til service/reparation. Ændre reservation. Afbestille reservation. Vis job-kø. Vis arbejdsplan for en given periode. Registrer tidsforbrug (start- og sluttidspunkt). Registrer fravær (sygdom, ferie etc.). Kopier personale-oplysninger fra økonomi-system. Kopier kunde-oplysninger fra økonomi-system. Opret/vedligehold kunde-oplysninger samt biler ejet af kunde. Udskrive liste over nye/ændrede kunde-oplysninger. Overfør tidsforbrug samt fravær til økonomi-system. Udsende nyhedsbreve, tilbud osv. Indkalde til service. Start systemet. Genstarte system-processer, der er gået ned. Meddele IT drift vedr. system-fejl. Se bilag 1 for beskrivelser i "Brief Format" for disse Use Cases. Det er vigtigt at notere sig, at ovenstående liste, i nuværende fase, ikke er udtømmende. Endvidere vil de funktionelle krav, som vores Use Cases skal være med til at afdække, næsten med sikkerhed, blive udsat for ændringer. Ændringer undervejs i projektforløbet skal ikke opfattes som et problem, men nærmere som en drivkraft i den igangværende proces, der officielt benævnes Unified Process (UP). UP kombinerer "best practices", iterativ- og risikodreven udvikling. For at give et overblik over systemet bringes her et Use Case Context diagram:

6 Side 6 af 49 Figur 1 - Use Case Context diagram.

7 Side 7 af 49 Det skal bemærkes at der ikke er medtaget kommunikationslinier fra kunden til systemet pga. den tidligere omtalte nedtoning af beskrivelser vedr. tilgang til systemet via Internettet. Endvidere skal det nævnes at, aktørerne Kontorassistent, Værkfører, Mekaniker og Lærling, for overskuelighedens skyld, er samlet i en aktør kaldet Ansat. Supplerende specifikation Ved fortsat at benytte FURPS+ modellen, skal vi nu have fundet frem til de ikke-funktionelle krav. FURPS+ er en forkortelse og er forklaret herunder: Functional (funktionelle krav) Usability (menneskelige faktorer, hjælp, dokumentation så som bruger-, installations- og administrator-vejledninger) Reliability (fejltolerance, muligheder for recovery osv.) Performance (svartider, datamængder, oppe-tid, driftsressourcer osv.) Supportability (tilpasningsevne, vedligeholdelse, internationalisering, konfigurerbart) Plusset i FURPS+ står for de krav, der kan relateres til følgende faktorer: Implementering (ressource begrænsninger, sprog og værktøjer, hardware osv.) Interface (bindinger ifbm. brugerinterface samt interface til eksterne systemer) Drift Pakning Juridiske forhold (licenser etc.) Vores analyse afdækkede følgende ikke-funktionelle krav: A. Systemet skal være et hurtigt værktøj ifbm. søgning af ledig tid til reservation af service/reparation (P). B. Det skal være et flerbruger system. Der skal være samtidig adgang til systemet fra kontoret (kontorassistent), værkførerkontoret (værkfører/mekaniker), samt fra værkstedet (værkfører/mekaniker/lærling) (U). C. Ifbm. at en mekaniker anvender systemet til job-registrering i værkstedet, kan tastatur ikke anvendes pga. mekanikernes snavsede oliefingre! (+) D. Kommunikationen med systemet skal foregå på Dansk (S). E. Der forventes en oppe-tid på 99% indenfor normal arbejdstid. (R). F. Ved nedbrud skal alle accepterede reservationer kunne gendannes (R) G. Systemet skal have interface til værkstedets økonomisystem.(+) H. Funktioner, der skal anvendes af mekanikere, skal være meget intuitive og nemme at bruge. (U)

8 Side 8 af 49 Planlægning af næste iteration For at kunne planlægge en eventuelt kommende iteration er kravene "ranket" i nedenstående skema: Krav Type Arkitektur / teknik Risiko / kompleksitet Kritisk for Sum løsningen UC1 F UC2 F UC3 F UC4 F UC5 F UC6 F UC7 F UC8 F UC9,10,11 F UC12 F UC13 F UC14 F UC15 F UC16 F UC17 F A P B U C D S E R F R G H U De enkelte krav er vurderet efter skalaen: 1 = Lav, 2= Middel, 3 = Høj. Inden for kategorierne: Arkitektur / teknik = Hvor stor indflydelse har kravet på det tekniske design af systemet. Risiko / Kompleksitet = Hvor kompleks er kravet. Kritisk for løsningen = Hvor stor forretningsværdi har kravet. En af de risici vi kan se er, at værkstedspersonalet ikke gider at anvende systemet, hvis det ikke bliver meget nemt at anvende. Dette skal derfor have en meget stor bevågenhed under udviklingen. Rent teknisk er dette dog ikke så risikofyldt, da personerne i projektgruppen er stærke inden for dette felt. Af andre "risktyper" kan nævnes problemet med at få projektet besat med ressourcer med de rette kvalifikationer. Heller ikke på dette punkt er der ikke problemer i relation til dette projekt. Et fokus område bliver projektets behov for tidsforbrug hos projekt personer (ansatte i autoværkstedet), som stadig skal varetage deres daglige arbejdsopgaver. Med ovenstående betragtninger in mente og med baggrund i den foretagne "rankning" vælger vi i den eventuelt kommende iteration at arbejde med "Basic Flow" scenariet i UC1 (Reserver tid til service/reparation).

9 Side 9 af 49 Udviklingsplan På baggrund af ovenstående "rankning" samt en vurdering af den logiske rækkefølge, har vi udarbejdet en foreløbig udviklingsplan. Det er vigtigt at understrege, at planen kun er foreløbig og at den efter hver iteration, vha. nye "rankninger", revideres. Efter en iteration er man jo som regel blevet klogere og "rankningen" vil som konsekvens heraf med stor sandsynlighed ændre sig. Processen vi følger (UP) består af følgende faser: Inception: Elaboration: Overordnet vision, identifikation af Uses Cases ca. 10% beskrevet i detaljer. Arkitektur beslutninger, afdækning af high risk elementer (også kode mæssigt), de fleste Use Cases beskrevet i detaljer. Construction: Kodning af tilbageværende low risk elementer, samt øvrige elementer. Transition: Beta test, systemet går live. De sidste 3 faser indeholder typisk flere iterationer. Det er vigtigt, at forstå at hver iteration selvom det er i Elaboration fasen ender op med færdige program elementer (kode). For mindre projekter vil store dele af systemet blive kodet i Elaboration fasen. Første udkast til udviklingsplanen: Fase Iteration Indhold nr. Elaboration 1 UC1: Reserver tid (NormalReservation) Basic flow. Elaboration 2 UC1: Reserver tid (SpecialReservation) + GUI Søg reservations tidspunkter Basic flow UC7: Registrer fravær UC15: Start system Elaboration 3 UC1: Reserver tid (NormalReservation) Alternativ flow. UC2: Ændre reservation Construction 1 UC3: Afbestille reservation UC1: Reserver tid (SpecialReservation) Alternativ flow UC10: Opret/vedligehold/søg kunde-oplysninger samt biler ejet af kunde. Construction 2 UC4: Vis job-kø UC6: Registrer tidsforbrug. UC11: Udskriv liste over nye/ændrede kunde oplysninger. Non-functional: C, H Construction 3 UC5: Vis arbejdsplan for en given periode. Construction 4 UC8: Kopier personale-oplysninger fra økonomi-system. UC9: Kopier kunde-oplysninger fra økonomi-system. UC12: Overfør tidsforbrug samt fravær til økonomi-system. Non-functional: F, G Construction 5 UC13: Udsende nyhedsbreve, tilbud osv. UC14: Indkalde til service. Transition 1 Første pilotversion installeres. Transition 2

10 Side 10 af 49 Non-functional krav: Til krav A, B, D og E forventes der ikke selvstændige aktivteter. De forventes at blive indarbejdet i de øvrige aktiviteter, som en del af udviklingsaktiviteterne. Forfinet vision På baggrund af den forudgående analyse har vi opstillet nedenstående vision, der har fået "commitment" fra projektets interessenter: Autoværkstedet ønsker et system, som kan reducere tidsforbruget til behandling af kundehenvendelser og planlægning. Kunderne skal, på sigt, på alle tider af døgnet kunne henvende sig til autoværkstedet for at reservere tid til reparation eller service. De skal ligeledes have adgang til, successivt rette, de oplysninger som autoværkstedet har registreret om dem. Nye kunder skal kunne oprette sig selv i systemet. Men som udgangspunkt udvikles og installeres systemet i første omgang til in-house brug. Oplysningerne om kunderne ønskes på sigt anvendt til en mere aktiv kundepleje, nyhedsbreve, indkaldelse til service, rabatter, konkurrencer, kampagner, tilbud osv. Arbejdsplaner skal opdateres automatisk når mekanikere pludselig skal bruge tid på akutte reparationer. Mekanikerne skal hele tiden være informeret om hvilken opgave, de skal arbejde på og de skal kunne se hvilke opgaver, der venter. Dette kunne eventuelt implementeres vha. en job-kø, der ydermere har den fordel, at den enkelte mekaniker kan vælge opgaver, der passer til vedkommendes kompetencer. Autoværkstedet opnår altså en decentralisering af planlægningen, som medvirker til en optimal udnyttelse af personale samt produktionsapperat. Der ønskes en integration til autoværkstedets økonomi-system, således at mekanikernes tidsforbrug samt fravær (ferie, sygdom osv.) automatisk kan overføres fra det nye system. Mht. personale- og kundeoplysninger betragtes økonomi-systemet som master. Systemet skal kunne opsamle forbrugte ressourcer således, at historiske data kan anvendes i den fremtidige planlægning. Decentraliseringen af planlægningen påtænkes ligeledes at omfatte ferie. Mekanikerne skal selv kunne booke ferie og med det samme se om det harmonerer med behovet for ressourcer. Ordliste Term Definition og information Aliaser Aktør Noget der kan påvirke systemet, så som en person (identificeret vha. en rolle), et computer system eller en organisation. Primær aktør Får mål opfyldt ved at benytte systemet. Use Case Beskrivelse af systemets brug.

11 Side 11 af 49 Term Definition og information Aliaser Service Kontrol/eftersyn af bilen efter et bestemt antal kilomenter. eks , Mindre reparationer som olieskift etc. foretages ifm. servicen. Arbejdsbeskrivelser Beskrivelse af opgaver der kan udføres på en bestemt biltype. Eks km service. Speciel reservation Normal reservation Kunde Mekaniker, Svend Ansat Lærling Fravær Autoværksted Reservation af et tidspunkt til en opgave på bilen, som kræver udlært personale. Reservation af et tidspunkt til en opgave på bilen, som ikke kræver udlært personale. Typisk service eftersyn. Ejeren af en bil, som er blevet repareret/serviceret på værkstedet. Udlært værkstedspersonale. Mekaniker, lærling, værkfører og kontorassistent. Person som er under uddannelse til mekaniker. Tidsperiode hvor en ansat ikke er på arbejde pga. ferie, sygdom etc. Det fysiske sted, der ønsker det nye system installeret og hvor biler bliver serviceret / repareret. Go - No go? Det vurderes at projektet kan gennemføres samt at tilbagebetalingstiden vil blive ca. 1 år. Autoværkstedets ledelse vurderer endvidere, at systemet har stor strategisk betydning. Det besluttes at gå videre til elaboration-fasen. Elaboration-fasen I 1. iteration, som vi skal i gang med nu, bestemte vi vha. "rankning", at arbejde med "Basic Flow" scenariet i UC1 (Reserver tid til service/reparation). UC1 beskrives derfor nu i "Fully Dressed" format. Tallene i parentes refererer til efterfølgende skærmbillede layouts.

12 Side 12 af 49 UC 1: Reserver tid til service/reparation Primary Actor: Kontorassistent. (kan også være værkføren, men med samme beføjelser som kontorassistenten). Stakeholders and Interests: Kontorassistent: Ønsker at kunne give kunden et hurtigt svar, på hvornår kundens bil kan Kunde: bliver behandlet. Ønsker at få behandlet sin bil hurtigst muligt, eller alternativt på en bestemt dag. Autoværkstedets ledelse: Ønsker tilfredse kunder, samt korrekt styring af tidsressource forbruget. Preconditions: Kontorassistenten er logget på systemet. Success Guarantee (Postconditions): Reservationen er registeret i systemet. Trigger: En kunde henvender sig for at foretage en reservation til service/reparation. Basic Flow: 1. Kunden henvender sig til autoværkstedet med ønske, om at få foretaget service/reparation. 2. Kontorassistenten beder om kundens tlf.nr. 3. Kontorassistenten indtaster tlf.nr. 4. Systemet fremfinder og præsenterer de registrerede kunde- samt bil-data i skærmbilledet "Søg reservations tidspunkter" (se udkast til layout efter denne Use Case). 5. Bil vælges (kunden kan have flere biler). 6. Systemet præsenterer en liste over mulige arbejdsbeskrivelser for den valgte bil (biltype). 7. Kontorassistenten vælger arbejdsbeskrivelser p.b.a. af kundens ønske. 8. Kontorassistenten igangsætter søgning efter ledig tid for reservation uden at ændre default værdierne i felterne (se skærmbillede-layout efter denne Use Case) Ønsket dato (1) og Arbejdsvarighed (2). 9. Systemet afgør p.b.a valgte arbejdsbeskrivelser om reservationen kræver udlært personale (Speciel reservation), eller ej (Normal reservation). 10. Systemet søger efter åbningstider, i en periode fra den ønskede dato (1) og 14 dage frem. 11. Indenfor de fundne åbningstider søger systemet herefter efter værkstedspersonel, der ikke er fraværende og ikke er optaget af opgaver. 12. Systemet præsenterer en liste over ledige tidspunkter i skærmbilledet "Vis ledige tidspunkter" (se udkast til layout efter denne Use Case). 13. Kontorassistenten forelægger kunden de ledige tidspunkter. 14. Kunden accepterer et tidspunkt. 15. Kontorassistenten registrerer reservationen. 16. Systemet gemmer reservationen som en opgave.

13 Side 13 af 49 Alternative Flows: 4a. Kunden er ikke registeret. 1. Kontorassistenten opretter kunden i systemet. 2. Kontorassistenten opretter kundens bil(er) i systemet. 4b. Bilen som kunden ønsker serviceret er ikke oprettet under kunden. 1. Kontorassistenten opretter kundens bil i systemet. 1b. Bilen er registreret under en anden kunde (tidligere ejer). 2. Ejer forholdet på Bilen ændres. 8a. Kunden har et specifikt ønske til tidspunkt for service. 1. Kontorassistenten forespørger systemet om ledig tid, ved at indtaste ønskede dato. 8b. Den ønskede reparation er af en anden varighed end den angivet i arbejdsbeskrivelserne. 1. Kontorassistenten kontakter en mekaniker for, at få et groft estimat på den ønskede opgave. 2. Kontorassistenten ændrer Arbejdsvarighed (2) og igangsætter søgning. 8c. Den ønskede reparation er ikke registeret under de fremsøgte arbejdsbeskrivelser. 1. Kontorassistenten kontakter en mekaniker for, at få et groft estimat på den ønskede opgave. 2. Kontorassistenten indtaster arbejdsbeskrivelsen som fritekst. 3. Kontorassistenten ændrer Arbejdsvarighed (2) og igangsætter søgning. 13a. Ingen af de fremfundne tidspunkter passer kunden. 1. Kontorassistenten foretager ny søgning ved at indtaste en anden dato.

14 Side 14 af 49 Skærmbillede layout: "Søg reservations tidspunkter" TimeFinder V0.01 Tlf.nr Screen Navn: layout: Adresse: Jens Vejmand Juelsmindevej 12 A 2650 Hvidovre Reg.nr: VB23123 BilType: Alfa Romeo 156 Sidste Service: CJ76122 VW Golf Arbejdsbeskrivelser for valgt bil (reg.nr. CJ76122) af typen VW Golf 2.0: km service. Varighed er 4 timer. Der kræves ikke udlært personale km service. Varighed er 4 timer. Der kræves ikke udlært personale km service. Varighed er 4 timer. Der kræves ikke udlært personale km service. Varighed er 3 timer. Der kræves udlært personale. Stor reparation. Varighed er 8 timer. Der kræves udlært personale. Middel reparation. Varighed er 4 timer. Der kræves ikke udlært personale. Lille reparation. Varighed er 2 timer. Der kræves ikke udlært personale. (1) Ønsket Dato: (2) Arbejdsvarighed: 8 Søg Tidspunkt Feltet Ønsket dato (1) er default udfyldt med dagsdato + 1 dag. Feltet Arbejdsvarighed (2) er default udfyldt med forventet varighed i timer bestemt ud fra biltype samt ønskede arbejdsbeskrivelser. Begge default værdier kan overskrives. Værkføren kan eksempelvis give et mere præcis estimat på arbejdsvarighed for store reparationer.

15 Side 15 af 49 Skærmbillede layout: "Vis ledige tidspunkter" TimeFinder V0.01 Ledige Tidspunkter: 1 Åbningstid: Varighed er 8 timer. Ledig tid på værksted (ressourcer-fravær-opgaver): =4 Varighed af arbejde: 8 Kunden KAN IKKE vælge denne dag. 2 Åbningstid: Varighed er 8 timer. Ledig tid på værksted (ressourcer-fravær-opgaver): =8 Varighed af arbejde: 8 Kunden KAN vælge denne dag. Accepter Tidspunkt Ny Søgning Aktivitetsdiagram UC1 "Basic Flow": Aktivitetsdiagrammet er OOAD s flowcharts, som viser aktiviteternes hændelsesforløb. I dette tilfælde bruger vi aktivitetsdiagrammet til, at billedeliggøre vores Use Case.

16 Side 16 af 49 Figur 2 - Aktivitetsdiagram til UC1 "Basic Flow"

17 Side 17 af 49 Det ovenstående aktivitetsdiagram viser Reservation af tid til service/reparation. Den centrale del af aktiviteterne (dialogen med systemet) står kontorassistenten for. Da kunden enten henvender sig personligt eller telefonisk vil der samtidigt med aktivitets flowet forekomme kommunikation mellem kontorassistenten og kunden. Dette er ikke medtaget, da formålet er at vise det principielle i aktivitets flowet. Testovervejelser Efter udarbejdelsen af UC1 (Reserver tid til service/reparation) i "Fully Dressed" format er det på sin plads, at overveje hvorledes testen skal foretages. Testens formål er bl.a. at skabe tiltro til, at systemet gør det som det skal gøre. Derfor er det vigtigt, at man gør sig klart hvad resultatet af testen skal blive. Sagt med andre ord bør man ifm. udarbejdelsen af en Use Case, samtidigt udarbejde tilhørende testcase. Vi har ladet os inspirere testmetoden "test-first programming", der anvendes i Extreme Programming (XP). Og da hver iteration i UP i princippet indeholder en "mini V-model", har de gode gamle test-dyder fra V-modellen, der jo også indgyder til at teste fra starten, selvfølgelig også været en kilde til inspiration. Fremgangsmåden ved testmetoden "test-first programming" er først at skrive lidt testkode, dernæst lidt kode der skal testes. Når koden er succesfuldt testet gentages forløbet. I UC1 fremsøges en kunde vha. tlf.nr. som argument. Vi skal altså først lave testkode, som kan teste oprettelse af en kunde samt fremsøgning af denne. Herefter laves kode der rent faktisk kan oprette kunden samt fremsøge denne. Når koden er succesfuldt testet vil vi på tilsvarende vis fortsætte med at arbejde os igennem UC1, indtil vi føler os overbeviste om at koden tilfredsstiller den beskrevne funktionalitet. Ovenstående er gennemført vha. klassen SystemTester.java som kan ses i Bilag 2 hvor også outputtet af testen kan ses (Bilag 3).

18 Side 18 af 49 System Sekvens Diagram Før det egentlige designarbejde i iteration 1 påbegyndes, er det formålstjenstligt at få afklaret input og output system events relateret til "Basic Flow" scenariet i UC1. Det letter overgangen fra analysearbejdet til designarbejdet. Hertil anvendes et System Sekvens diagram som er en Craig Larman opfindelse: R e se rv e r tid til s e rv ic e /re p a ra tio n U C 1 B a s ic F lo w s c e n a rie g e tk u n d e (p T lfn r) K u n d e g e tb ile re je ta fk u n d e (K u n d e Id ) B il[] g e ta rb e jd s B e s k riv e ls e r(b ilt y p e Id ) A rb e jd s B e s k riv e lse [] lis tf re e T im e (o e n s k e td a to, v a rig h e d, U d la e rtp e rs o n a le K ra e v e t) L e d ig e T id e r[] a c c e p tt im e (b ilr e g N r,d a to,v a rig h e d,v a lg te A rb e jd s B e s k r) Figur 3 System sekvens diagram. Som det ses betragtes systemet som et hele; som en "black box". Og vi har nu, i højere grad, fået konkretiseret operationerne, der relaterer sig til Basic Flow scenariet i UC1. Senere i designforløbet vil vi lave "rigtige" sekvensdiagrammer, hvor det vil fremgå hvilke objekter i systemet, der får ansvaret for at udføre operationerne. Til afklaringen heraf benytter vi Craig Larman's GRASP Patterns.

19 Side 19 af 49 Domain Model Designarbejdet påbegyndes ved at udarbejde en Domain Model. Da vi jo arbejder i henhold til UP er det vigtigt ikke at kaste sig ud i og lave en komplet model på nuværende stadie. I efterfølgende iterationer udbygges modellen til også at afspejle disse. Af hensyn til eventuelt nye udviklere på projektet er det vigtigt at Domain Modellen vedligholdes. Den er nemlig et godt værktøj til hurtigt at bibringe et godt indblik i problem domænet. Domain modellen repræsenterer konceptuelle klasser (ting, begreber fra den virkelige verden) og ikke software klasser. Et eksempel på en software klasse kan f.eks. være en interface klasse til en database. For at finde de konceptuelle klasser i problem-domænet anvendes en "Conceptual Class Category List": Conceptual Class Category Physical or tangible objects Specifications, designs or descriptions of things. Places Transactions Transaction line items Roles of people Containers of other things Things in a container Other computer or electromechanical systems external to the system Abstract noun concepts Organizations Events Processes (often not represented as a concept but may be) Rules and policies Catalogs Records of finance, work, contracts, legal matters Finacial instruments and services Manuals, documents, reference papers, books Candidates Bil Biltype, Arbejdsbeskrivelse Autoværksted Reservation Job-registrering Kontorassistent, Værkfører, Mekaniker, Lærling, Kunde Åbningstider Datoer, Tidspunkter. Økonomi-system Service, Reparation, Opgave, Fravær, Åbningstid Kundehenvendelse Bilmanual Reparationsvejledninger Servicevejledninger Endvidere er UC1 gennemgået for navneord (Arbejdsvarighed, Arbejdsbeskrivelse, Autoværksted, Bil, Biltype, Dato, Kontorassistent, Kunde, Opgave, Periode, Reparation, Reservation, Service, Tid, Tidspunkt, Tlf.nr., Åbningstid).

20 Side 20 af 49 Arbejdsvarighed, Dato, Tid, Tidspunkt samt Tlf.nr. er ikke konceptuelle klasser, men nærmere attributter, da disse kan repræsenteres vha. simple datatyper som f.eks. int. Dog repræsenteres eksempelvis Dato og Tlf.nr. vha. lidt mere komplekse datatyper nemlig Date og String, men betragtes stadig som attributter. Endvidere kan man sige at Arbejdsvarighed består af et antal samt en enhed, men for nu forudsætter vi bare at der er tale om et antal timer. Flg. liste repræsenterer de konceptuelle klasser, der relaterer sig til nuværende iteration: Autoværksted Bil Åbningstid Opgave Ansat Biltype Reservation Kunde Arbejdsbeskrivelse Fravær Herefter skal vi, uden at anvende ret meget tid, identificere associationer mellem de konceptuelle klasser. Hertil anvendes en "Common Associations List": Category A is physical part of B* A is logical part of B* A is physically contained in/on B* A is logically contained in B* A is a description for B A is a line item of a transaction or report B A is known/logged/recorded/reported/captured in B* A is a member of B A is an organizational subunit of B A uses or manages B A communicates with B A is related to a transaction B A is a transaction related to another transaction B A is next to B A is owned by B A is an event related to B Candidates Åbningstid - Autoværksted Ansat - Autoværksted Opgave - Autoværksted Biltype - Bil Arbejdsbeskrivelse - Biltype Arbejdsbeskrivelse - Opgave Reservation - Autoværksted Ansat - Autoværksted Kunde - Autoværksted Kunde - Bil Bil - Kunde Fravær - Ansat Reservation - Opgave Opgave - Bil Kategorier markeret med * er af speciel vigtighed i Domain Model henseende.

21 Side 21 af 49 Slutteligt har vi identificeret attributter for de enkelte klasser i Domain modellen, der herefter, på nuværende tidspunkt, ser således ud: Figur 4 Domain Model. Som det ses indeholder klasserne Opgave, Åbningstid og Fravær en dato og en varighed. Vi kan forudse, at dette problem-domæne måske kommer til at indeholde flere klasser med netop disse attributter. Endvidere er varighed, som tidligere omtalt, ikke en simpel datatype. Disse ting til sammen gør det nærliggende at lave en ny klasse der hedder Tidsperiode og så lave associationer fra denne til Opgave, Åbningstid og Fravær. Man kunne også overveje om klasserne Opgave, Åbningstid og Fravær skulle nedarve fra Tidsperiode, hvilket ville være ok i relation til "100%- reglen", men ikke i relation til "is a - reglen". Kontrakter Kontrakter anvendes normalt ifbm. store, tunge Use Cases, hvor en yderligere beskrivelse af systemet kan være værdifuld for det videre designarbejde. De beskriver resultaterne (ændringerne i objekternes tilstand) af system operationer fra System Sekvens Diagrammet og kunne godt beskrives i selve Use Casen, men det medfører som regel en meget stor detaljeringsgrad og

22 Side 22 af 49 mindsker måske hermed værdien af selve Use Casen. Vi har valgt at lave kontrakter for operationerne listfreetime og accepttime, der kort er beskrevet i punkt 9, 10, 11 og 16 i UC1: Contract CO1: Operation: listfreetime listfreetime(date oensketdato, int varighed, boolean udlaertpersonalekraevet) Cross References: Use Case: UC1 - Reserver tid til service/reparation. Preconditions: Postconditions: Åbningstider og Ansatte er oprettet i systemet. Endvidere er eventuelt fravær samt eventuelle opgaver ligeledes oprettet i systemet. Kunden er fremsøgt. Kundens bil(er) er fremsøgt en af disse er valgt til service/reparation. Mulige arbejdsbeskrivelser for valgt biltype er fremsøgt og de ønskede arbejdsbeskrivelser er valgt. Ud fra valgte arbejdsbeskrivelser er arbejdsvarighed bestemt. Ligeledes ud fra disse er det afgjort om udlært personale er krævet. Felterne Ønsket dato (1) og Arbejdsvarighed (2) er udfyldt. Objekterne i Domain modellen er ikke ændret. Objekt-instanser oprettet under fremsøgning er nedlagt. Liste over ledige tidspunkter præsenteres. Contract CO2: Operation: accepttime accepttime(string bilregnr, Date dato, int varighed, Vector ValgteArbBeskr) Cross References: Use Case: UC1 - Reserver tid til service/reparation. Preconditions: Postconditions: En bil er valgt (i CO1), de ønskede arbejdsbeskrivelser er markerede (CO1) og Arbejdsvarighed er bestemt. listfreetime (se CO1) er gennemført. Kundens valg blandt de ledige tidspunkter er valgt. Eventuelle kommentarer er anført. En Opgave instans er oprettet og gjort persistent. Detaljeret design Efter alle de forudgående undersøgelser føler vi os nu godt rustet til det mere detaljerede designarbejde. Vi kaster os over udarbejdelse af klassediagram og sekvensdiagrammer. Grundet de tidligere omtalte betragtninger vedr. tidsperioder i klasserne Opgave, Åbningstid og Fravær har vi set i relation til Domain Modellen lavet en ny klasse der hedder Tidsperiode. Dette fremgår at klassediagrammet som ses herunder:

23 Side 23 af 49 Figur 5 Klasse diagram

24 Side 24 af 49 I Figur 5 ses klasse diagrammet i sin nuværende form Klasse diagrammet har været, og vil i kommende iterationer være i konstant udvikling. Som Controller klasse for system events har vi pt. valgt klassen AutoVaerksted. Det er på nuværende stade i projektet ok, da der endnu ikke er så mange system operationer. High Cohesion er bevaret. State Pattern er valgt til Reservation. State Pattern anvendes i de tilfælde hvor et objekts opførsel afhænger af dets tilstand, og dets tilstand kan ændre sig på runtime tidspunktet. State Pattern giver den fordel, at der senere kan tilføjes yderligere specilaliseringer af reservations typer, uden ændringer af ireservation (som er et interface) eller de øvrige klasser. I øjeblikket kan Reservation være i 2 states enten en NormalReservation hvor der ikke kræves udlært personale alternativt i state SpecialReservation hvor der kræves udlært personale. På sigt kunne man forstille sig en tredje state, som eksempelvis specielle færdigheder kræves for, at løse en bestemt opgave. Denne nye reservationstype skulle derved blot arve fra ireservation (altså tilføjes side om side med NormalReservation og SpecialReservation). På kørsels-tidspunktet afgøres v.h.a polymofi hvilken objekttype (State) der er tale om, og derved hvilken listfreetime funktion der skal kaldes. Med på diagrammet er også en spæd start på servicelaget, der tager sig af persistens ved at kommunikere typisk med en database eller eksempelvis XML-filer. Pt. er servicelaget repræsenteret af en enkelt klasse der er navngivet TestDB_Singleton. Klassen, der er en Facade Controller, er medtaget for at kunne teste systemet og persistens vha. af SystemTester klassen (beskrevet herunder). TestDB_Singleton er implemteret, som en Singleton. En singleton garanterer, at der kun findes en instans af klassen. Tidsperiode er i princippet pt. kun attributter, som er udskilt fra Opgave, Fravaerd og Aabningstid. Vi har undervejs haft et lidt andet design på banen, som bør genovervejes i en senere iteration I dette alternative design var Opgave, Fravaerd og Aabningstider en specialisering af tidsperiode (Opgave, Fravaerd og Aabningstider arver fra tidsperiode). Const klassen indeholder en række konstanter, der kan benyttes i hele systemet denne klasse er også en Singleton. SystemTester-klassen er tidligere beskrevet i afsnittet Testovervejelser. For klassen Ansatte og deres beskæftigelse er modelleret vha. det GoF Pattern, der hedder Bridge. Brige anvendes i de tilfælde, hvor der ikke ønskes permanent binding mellem en abstraction (Ansat) og dets implemtering (Roller: Laerling, Mekaniker). Det giver den fordel, at implementeringen af en abstaction kan skiftes på runtime tidspunktet. Altså at en Laerling eksempelvis kan blive udlært, og skifte rolle til Mekaniker. Yderligere roller forventes tilføjet under implemteringen af SpecielReservation, samt hvis specielle færdigheder pr. ansat implementeres.

25 Side 25 af 49 Sekvensdiagrammer * [ i : = 1.. a n t W o r k i n g D a y s ] Figur 6 Sekvens diagram UC1 Basic Flow

26 Side 26 af 49 * [ i : = 1.. a n t W o r k i n g D a y s ] Figur 7 Sekvens diagram (Første udkast UC1 alternativt flow 4a)

27 Side 27 af 49 I figur 6 og 7 vises sekvensdiagram for Use Case Reserver tid til service/reparation (UC1). Sekvensdiagrammet i figur 7 er første udkast til alternativ flow(4a) i Use Casen. Sekvensdiagrammet figur 6 - Use Case Reserver tid til service/reparation (UC1) basic flow. Når kontorassistenten påbegynder en reservation af service/reparation, sendes ifm. fremsøgningen af kunden, en meddelelse getkunde til klassen AutoVaerksted. AutoVaerksted agerer set med GRASP briller i dette tilfælde Information Expert. Søgefunktioner som eksempelvis getansatte, getworkingdays, og getopgavevarighed er generelt set placeret i Autovaerksted, hvilket giver high cohesion AutoVaerksted får i sin nuværende version også rollen, som Controller (svarer til GoF Facade Pattern) mod databasen. Når kunden er fremfundet, sendes en meddelelse getbilerejetafkunde til kunde, som er Information Expert, overfor hvilke biler den enkelte kunde ejer. Arbejdsbeskrivelser hentes med en meddelelse getarbejdsbeskrivelser til Biltype ( Information Expert ). Fremsøgningen af ledige tidspunkter sendes, som meddelelse til Reservation, som spørger Information Expert en AutoVarksted. Reservation bruger i sit underliggende design Polymorphism ifm. afgørelsen af hvilke søge funktioner, der skal kaldes. Når et tidspunkt er accepteret sendes en meddelelse til Reservation, som har ansvar for opgaven bliver gemt på databasen. I de viste sekvensdiagrammer og i denne iteration, har vi ikke taget stilling til hvem, der skal være Creator af de enkelte klasser. I en senere iteration hvor GUI-delen udvikles skal dette ske. Den nuværende model tyder på, at der skal tilføjes en Controller (Facade) klasse mellem GUI-laget og forretningslaget Denne nye controller skal derved dele ansvaret med Autovaerksted for at få opgaven løst. Af hensyn til High Cohesion bør eksempelvis opretkunde og opretbil i en senere iteration flyttes fra AutoVaerksted, så denne kun indeholder søgefunktion. Systemarkitektur Planlægningssystemet udvikles i Java med udgangspunkt i 3-lags arkitekturmodellen: 1. lag: GUI laget Indeholder skærmbilleder til at varetage dialogen med brugeren. Kommunikerer med forretningslaget via en Controller (GoF Facade Pattern). 2. lag: Forretningslaget Den forretningsspecifikke funktionalitet. Kommunikerer med datalaget via en Controller (GoF Facade Pattern). 3. lag: Servicelaget Søger for persistens. Vil typisk være kommunikation med en database eller f.eks. XML-filer. GUI laget implementeres som en klient del. D.v.s en Java Applet, som køres via en Internet Browser. Af hensyn til værkstedets størrelse, og den ønskede IT investering - baseres systemet i første omgang på en enkelt server (PC). Der etableres klient adgang fra kontorassistentens og værkførerens eksisterende PC ere. Til visning af job-køen samt til registrering af bl.a. start- og sluttidspunkter opsættes en "terminal" (+krav vedr. oliefingre) i værkstedet. Dette er illustreret ved nedenstående Deployment Diagram:

28 Side 28 af 49 Figur 8 Deployment diagram. Det videre forløb I dette skoleprojekt stopper vi nu. I den virkelige verden ville vi nu, som tidligere nævnt, revidere udviklingsplanen og herefter starte på 2. iteration. Når alle iterationer er gennemført skulle vi så gerne stå med et færdigt system, der som et resultat af de mange feedbacks fra kunden, til fulde lever op til kundens forventninger.

29 Side 29 af 49 Bilag Bilag 1: Beskrivelser af Use Cases i "Brief Format" UC1: Reserver tid til service/reparation. En kunde henvender sig til autoværkstedet for at reservere tid til service/reparation af sin bil. Kundens oplysninger søges frem i systemet og disse verificeres. Ud fra den valgte bils biltype listes en række arbejdsbeskrivelser, der beskriver forskellige servicetyper samt reparationer. Arbejdsbeskrivelser vælges efter kundens ønsker, og med ønsket dato samt varighed som parametre fremsøges ledige tider til en reservation på værkstedet. Disse tider præsenteres for kunden, og det af kunden accepterede tidspunkt reserveres i systemet. UC2: Ændre reservation. En kunde henvender sig til autoværkstedet for at ændre tidspunktet for en reservation. Kundens oplysninger søges frem i systemet og disse verificeres. Herefter fremsøges reservation samt nye ledige tider på værkstedet. Disse nye tider præsenteres for kunden og det af kunden accepterede tidspunkt reserveres i systemet. UC3: Afbestille reservation. En kunde henvender sig til autoværkstedet for afbestille en reservation. Kundens oplysninger søges frem i systemet og disse verificeres. Herefter fremsøges reservation og denne annulleres. UC4: Vis job-kø. Når en mekaniker er klar til nye opgaver, går han hen til systemet og får vist den aktuelle job-kø, der generes dynamisk ud fra de foretagne reservationer. Mekanikeren vælger en opgave, der passer til vedkommendes kompetencer og i øvrigt passer ind i den decentrale planlægning på værkstedet. Specielle opgaver skal muligvis på sigt pointes til en bestemt ansat, som besidder specielle kvalifikationer. Bemærkning efter 1 iteration: Publish-Subscribe Pattern bør overvejes. UC5: Vis arbejdsplan for en given periode. Når værkføreren ønsker at skabe sig et overblik over behovet for ressourcer på værkstedet aktiveres UC5. Start- og slut-tidspunkt angives og herefter vises på grafisk form et overblik over ressourcer til rådighed, ressourcebehov til registrerede reservationer og endeligt forbrugte ressourcer i tilsvarende periode sidste år. Specielle opgaver skal muligvis på sigt pointes til en bestemt ansat, som besidder specielle kvalifikationer. Arbejdsplanerne danner også grundlag for planlægningen, af de enkelte mekanikers/lærlings arbejdstider i den kommende periode. UC6: Registrer tidsforbrug (start- og sluttidspunkt). Når en mekaniker er klar til nye opgaver, går han hen til systemet og får vist den aktuelle job-kø, der generes dynamisk ud fra de foretagne reservationer. Mekanikeren vælger en opgave, der passer til vedkommendes kompetencer og i øvrigt passer ind i den decentrale planlægning på værkstedet eller som er tildelt den enkelte ansatte p.g.a specielle kvalifikationer. Det sker ved at knytte mekanikerens initialer til opgaven. Samtidig med dette registres det egentlige starttidspunkt for opgaven til brug for job-registrering/fakturering. Når mekanikeren ikke længere arbejder på opgaven registreres sluttidspunkt og er opgaven helt udført markeres dette i et særskilt felt.

30 Side 30 af 49 UC7: Registrer fravær (sygdom, ferie etc.). Ved registrering af fravær indtastes årsag (sygdom, ferie etc.), starttidspunkt og sluttidspunkt. Herefter vises arbejdsplanen for den givne periode (UC5), således at man med det samme kan se indvirkningen på behovet for ressourcer. En mekaniker kan således med det samme se om f.eks. ønsket ferie kan lade sig gøre. Er det tilfældet gemmes registreringen af ferien. Er der tale om at en mekaniker sygemelder sig, kan værkføreren se om der skal indkaldes ekstra ressourcer eller om opgaver skal flyttes. UC8: Kopier personale-oplysninger fra økonomi-system. Personale-oplysningerne vedligeholdes kun i autoværkstedets økonomi-system. Disse kopieres en gang om måneden til det nye system. Kontorassistenten kan dog manuelt aktivere proceduren. UC9: Kopier kunde-oplysninger fra økonomi-system. Kontorassistenten vedligeholder kunde-oplysningerne (navn, adresse, tlf., biltype, årgang, forventet antal kilometer pr. år etc.) i autoværkstedets økonomi-system. Når nye kunder henvender sig oprettes de og når eksisterende kunder meddeler ændringer registreres disse. Kundeoplysningerne kopieres en gang i døgnet til det nye system. Kontorassistenten kan dog manuelt aktivere proceduren. Før kopiering af oplysningerne for en eksisterende kunde, kontrolleres det om kunden selv har rettet oplysningerne i det nye system. Er det tilfældet foretages kopiering ikke og UC11 aktiveres. UC10: Opret/vedligehold kunde-oplysninger samt biler ejet af kunde. I de tilfælde hvor kunden ikke er registeret i værkstedsystemet, eller oplysningerne i systemet er forkerte er der behov for, at kunne oprette/vedligeholde systemet med korrekte oplysninger. Dette gør sig også gældende for oplysninger om de biler ejet af kunden. Det skal være muligt, at flytte ejerskabet af en bil fra en kunde til en anden. UC11: Udskrive liste over nye/ændrede kunde-oplysninger. Når proceduren i UC9 køres udskrives eventuelt nye kunde-oplysninger, som kontorassistenten har oprettet/rettet i værkstedssystemet. Kontorassistenten benytter herefter udskriften til at opdatere autoværkstedets økonomi-system. På sigt overvejes en mere automatisk ajourførings funktionalitet. UC12: Overfør tidsforbrug samt fravær til økonomi-system. En gang i døgnet kopieres oplysninger om værkstedspersonalets tidsforbrug på diverse opgaver til autoværkstedets økonomi-system. Ligeledes kopieres oplysninger om fravær (fri, ferie etc.) til økonomi-systemet. UC13: Udsende nyhedsbreve, tilbud osv. På baggrund af kunde-oplysningerne kan værkføreren/kontorassistenten udsende nyhedsbreve, tilbud osv. Når materialet, der skal udsendes er klart, angives forsendelsesmåde (brev eller ) hvorefter kunder, der skal sendes til, fremsøges. Søgeargumenter kan f.eks. være en given biltype, da værkføreren måske har fået fat i nogle ekstraordinært billige reservedele til netop denne biltype. Når søgeresultatet er tilfredsstillende trykkes "Send" hvorefter kundedata flettes sammen med materialet. Er forsendelsesmåde afsendes med det samme. Er forsendelses måden brev printes materiale. UC14: Indkalde til service. Hvis kunden giver tilsagn herom kan systemet på baggrund af den registrerede biltype, årgang samt forventet antal kilometer pr. år, via , indkalde kundens bil til service.

31 Side 31 af 49 UC15: Start systemet. Systemet skal ideelt set kun startes en gang, da systemet, i hvert fald på sigt, påtænkes at skulle være til rådighed 24 timer i døgnet. Dog vil der blive tale om at skulle genstarte systemet i tilfælde af en uoprettelig fejl (UC16 fejler). Server startes, database samt database-listener startes og endeligt startes selve applikationen. UC16: Genstarte system-processer, der er gået ned. På systemet kører en række skygge-processer, der har det formål at starte de primære processer, såfremt de går ned. Skygge-processerne spørger med 3 minutters interval på om de primære processer kører. Er det tilfældet foretages intet. Er det ikke tilfældet forsøges de genstartet. Kan det ikke lade sig gøre aktiveres UC17. UC17: Meddele IT drift vedr. system-fejl. Hvis UC16 fejler logges fejlen i loggen, på sigt (når direkte online service til kunde aktiveres) skal der sendes en meddelelse til personen med ansvar for IT-driften. Bilag 2: SystemTester.java: import java.util.date; import java.util.enumeration; import java.util.vector; import java.text.dateformat; /* Generated by Together */ public class SystemTester public static void main(string[] argv) System.out.println("Instantier testdatabasen."); TestDB_Singleton db = TestDB_Singleton.getInstance(); System.out.println("/* ******** Opret testdata og gem dem i testdatabasen ******** */"); System.out.println("Opret selve AutoVærkstedet"); AutoVaerksted autovaerksted = new AutoVaerksted(); System.out.println("Opret ansatte i testdatabasen."); Rolle laerling = new Laerling(); Rolle mekaniker = new Mekaniker(); Ansat ansat1 = new Ansat("KD", "Kim", "Damgaard von papand", mekaniker, autovaerksted); db.addobject(ansat1); Ansat ansat2 = new Ansat("HS", "Henning", "Svensson Højben", laerling, autovaerksted); db.addobject(ansat2); System.out.println("Opret lidt fravær i testdatabasen. Fravaer(Tidsperiode newtid, String newaarsag, Ansat newansat)"); Fravaer fravaer1 = new Fravaer(new Tidsperiode(new Date(103,0,15,12,00), 4), Const.AARSAG_FRI, ansat1); db.addobject(fravaer1); Fravaer fravaer2 = new Fravaer(new Tidsperiode(new Date(103,0,16,8,00), 8), Const.AARSAG_SYG, ansat2); db.addobject(fravaer2); System.out.println("Opret åbningstider."); db.addobject(new Aabningstid(new Tidsperiode(new Date(103,0,15,8,00), 8), autovaerksted)); db.addobject(new Aabningstid(new Tidsperiode(new Date(103,0,16,8,00), 8), autovaerksted)); System.out.println("Opret kunder i testdatabasen."); Kunde kunde1 = new Kunde(1," ","Jens","Vejmand","Juelsmindevej", "12 A","2650","Hvidovre",autoVaerksted); db.addobject(kunde1); Kunde kunde2 = new Kunde(2," ","Jens Peter","Hansen","Dryadevej", "41","2650","Hvidovre",autoVaerksted); db.addobject(kunde2);

Assignment #5 Toolbox Contract

Assignment #5 Toolbox Contract Assignment #5 Toolbox Contract Created by: René Kragh Trine Randløv E mail address cph rk70@cphbusiness.dk 23 11 2014 1 Introduktion Dette dokument indeholder en vertikal kontrakt for et system som skal

Læs mere

Indholdsfortegnelse for kapitel 2

Indholdsfortegnelse for kapitel 2 Indholdsfortegnelse for kapitel 2 Kapitel 2. Analyse.......................................................... 2 Analyse af 2.1...................................................... 2 Analysen af Database.................................................

Læs mere

Software Design (SWD) Spørgsmål 1

Software Design (SWD) Spørgsmål 1 Spørgsmål 1 Unified Process Du skal give en beskrivelse af Unified Process. Beskrivelsen skal indeholde forklaring på følgende begreber: Phase Iteration Discipline Activity Milestone Artifact Spørgsmål

Læs mere

Projekt 2, 3. semester WEBPROJEKT

Projekt 2, 3. semester WEBPROJEKT Projekt 2, 3. semester WEBPROJEKT Aflevering d. 11/10-2013 CPH Business URL: www.thorleifbæk.dk/projekt2/index.php Gruppe 2 Shiko, Thorleif, Pernille og Annemette MUL 3A Indholdsfortegnelse s. 3 Factsheet

Læs mere

Løsningsforslag til Camp Let. Case Beskrivelse: Camp Let

Løsningsforslag til Camp Let. Case Beskrivelse: Camp Let Løsningsforslag til Camp Let Case Beskrivelse: Camp Let Firmaet Camp Let har til formål at udleje forskellige typer transportable ferieboliger. Det drejer sig i øjeblikket om campingbusser, campingvogne,

Læs mere

Software Design (SWD) Spørgsmål 1

Software Design (SWD) Spørgsmål 1 Spørgsmål 1 Unified Process Du skal give en beskrivelse af Unified Process. Beskrivelsen skal indeholde forklaring på følgende begreber: Phase Iteration Discipline Activity Milestone Artifact Spørgsmål

Læs mere

Indholdsfortegnelse. EasyIQ IDM 5.4 Brugermanual

Indholdsfortegnelse. EasyIQ IDM 5.4 Brugermanual Indholdsfortegnelse Indledning... 2 Forsiden... 2 Dine genveje... 3 Nyheder... 3 EasyIQ og EasyIQ Quick Funktioner... 3 Administration... 8 Licens... 8 Nyheder... 9 Eksterne links... 11 Log... 12 Password...

Læs mere

Velkommen til e-services

Velkommen til e-services Velkommen til e-services E-services giver patienterne mulighed for at kommunikere med sin læge via internettet - en mulighed som mange læger og patienter er glade for. Det giver en dejlig fleksibilitet

Læs mere

Region Midtjylland Proces for Change Management

Region Midtjylland Proces for Change Management Region Midtjylland Proces for Change Management Version 1.1 Forord Dette dokument beskriver RMIT s Change Management proces. Processen beskriver minimumskravene (need to have) for at få processen til at

Læs mere

Opgradering til version 4 af Netaflæsningsmodulet

Opgradering til version 4 af Netaflæsningsmodulet Opgradering til version 4 af Netaflæsningsmodulet Den nye version af netaflæsningsmodulet adskiller sig væsentligt fra den gamle version, ved at forbrugeren slår direkte op i værkets data, i stedet for

Læs mere

Quickguide til PM5. De enkelte punkter er beskrevet løst kig i manualen hvis du har brug for en dybere forklaring.

Quickguide til PM5. De enkelte punkter er beskrevet løst kig i manualen hvis du har brug for en dybere forklaring. Her er en hurtig guide til hvordan du kommer godt i gang med PM5. Der er visse ting der skal gøres i den rigtige rækkefølge, for at du får det bedste ud af systemet fra starten af. De enkelte punkter er

Læs mere

Software Design (SWD) Spørgsmål 1

Software Design (SWD) Spørgsmål 1 Spørgsmål 1 Unified Process Du skal give en beskrivelse af Unified Process. Beskrivelsen skal indeholde forklaring på følgende begreber: Phase Iteration Discipline Artifact Milestone Du skal relaterer

Læs mere

ITO... 5. Problemformulering... 5. Indledning... 5. Organisation og Ledelse... 5. Generel beskrivelse af logistik og produktionssystemer...

ITO... 5. Problemformulering... 5. Indledning... 5. Organisation og Ledelse... 5. Generel beskrivelse af logistik og produktionssystemer... ITO... 5 Problemformulering... 5 Indledning... 5 OrganisationogLedelse... 5 Generelbeskrivelseaflogistikogproduktionssystemer... 7 Produktionslayout... 7 Funktionslayout... 7 Gruppelayout... 8 Produktstyring...

Læs mere

Indholdsfortegnelse for kapitel 1

Indholdsfortegnelse for kapitel 1 Indholdsfortegnelse for kapitel 1 Forord.................................................................... 2 Kapitel 1.................................................................. 3 Formål............................................................

Læs mere

Bruger v1.5 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk

Bruger v1.5 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk Bruger v1.5 QUICK GUIDE Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk INTRODUKTION TIL REKVI-SKOLE Ideen med Rekvi-skole systemet udsprang fra et behov

Læs mere

Indhold. Indholdsfortegnelse

Indhold. Indholdsfortegnelse Indholdsfortegnelse Indhold Indledning... 2 Forsiden... 2 Dine genveje... 3 Nyheder... 3 EasyIQ og EasyIQ Quick Funktioner... 3 Administration... 6 Licens... 7 Nyheder... 8 Log... 9 Password... 9 System...

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

FORCE Inspect Online Manual v. 1.02. FORCE Inspect Online Manual. 1 af 18

FORCE Inspect Online Manual v. 1.02. FORCE Inspect Online Manual. 1 af 18 FORCE Inspect Online Manual 1 af 18 Indholdsfortegnelse Indholdsfortegnelse... 2 FORCE Inspect Online Manual... 3 Generelt... 3 Login... 3 Main... 4 Intro sektion... 4 Links sektion... 4 News sektion...

Læs mere

ViKoSys. Virksomheds Kontakt System

ViKoSys. Virksomheds Kontakt System ViKoSys Virksomheds Kontakt System 1 Hvad er det? Virksomheds Kontakt System er udviklet som et hjælpeværkstøj til iværksættere og andre virksomheder som gerne vil have et værktøj hvor de kan finde og

Læs mere

Lavet af Danni jensen og David Olsen

Lavet af Danni jensen og David Olsen Projekt Delfin Lavet af Danni jensen og David Olsen 19/5-2008 Indholdsfortegnelse. Side 1: Indholdsfortegnelse og forord. Side 2: Kravsliste. Side 3: Use Case Model. Side 4: Formandens aktørbeskrivelse

Læs mere

ITWIN1. Afsluttende projekt. PhotoDays. Benjamin Sørensen (02284) Tomas Stæhr Berg (03539)

ITWIN1. Afsluttende projekt. PhotoDays. Benjamin Sørensen (02284) Tomas Stæhr Berg (03539) ITWIN1 Afsluttende projekt PhotoDays Benjamin Sørensen (02284) Tomas Stæhr Berg (03539) ITWIN1 - AFSLUTTENDE PROJEKT PhotoDays Benjamin Sørensen & Tomas Stæhr Berg 02284 & 03539 1 1 Underskrifter Rapporten

Læs mere

InfoPro 2i. Profil Softwarefirmaet MaCom A/S blev etableret i 1992. Vi udvikler og markedsfører dokumenthåndteringssystemet InfoPro.

InfoPro 2i. Profil Softwarefirmaet MaCom A/S blev etableret i 1992. Vi udvikler og markedsfører dokumenthåndteringssystemet InfoPro. InfoPro 2i Profil Softwarefirmaet MaCom A/S blev etableret i 1992. Vi udvikler og markedsfører dokumenthåndteringssystemet InfoPro. Mission MaCom's mission er at sikre og skabe struktur i vores kunders

Læs mere

Vejledning til Teknisk opsætning

Vejledning til Teknisk opsætning Vejledning til Teknisk opsætning v. 1.0 Adm4you, 2010. Indhold Kort om denne vejledning... 3 Generelt om easyourtime... 3 Installation af databasen... 3 Sikkerhed og rettigheder... 4 SQL Login... 4 Rettigheder

Læs mere

Advanced Word Template Brugermanual

Advanced Word Template Brugermanual Advanced Word Template Brugermanual Forord: Advanced Word Template er et værktøj, der anvendes sammen med Microsoft Word til at opbygge ensartet beskrivelser på en mere intelligent måde end Copy and Paste

Læs mere

IDAP manual Emission

IDAP manual Emission IDAP manual Emission Dato: 08-06-2005 16:32:35 Indhold INDHOLD... 1 1 EMISSION... 2 1.1 KURVER... 2 1.2 RAPPORTER... 5 1.3 DATA REDIGERING... 6 1.3.1 Masse redigering... 7 1.3.2 Enkelt redigering... 10

Læs mere

Bias Reducing Operating System - BROS -

Bias Reducing Operating System - BROS - Bias Reducing Operating System - BROS - Accepttestspecifikation Projektgruppe 3: Rasmus Lund Jensen (11111) Nicolai Glud(11102) Jacob Roesen(10095) Mick Holmark(11065) Johnny Kristensen(10734) 1 Versionshistorik

Læs mere

Indledning...3. OnTime Kalenderen...3. Daglig brug af OnTime...4. Oversigter / Views...5. Funktioner...7. Brug af ikoner...12

Indledning...3. OnTime Kalenderen...3. Daglig brug af OnTime...4. Oversigter / Views...5. Funktioner...7. Brug af ikoner...12 Indholdsfortegnelse: Indledning...3 OnTime Kalenderen...3 Daglig brug af OnTime...4 Oversigter / Views...5 Funktioner...7 Brug af ikoner...12 Grafisk visning af tid...13 Side 2 Indledning I større organisationer

Læs mere

User Management System

User Management System User Management System www.inlogic.dk Indholdsfortegnelse UMS Web brugervejledning... 3 Skift dit password... 5 Mobil nummer... 6 IT Regel... 7 Dine oplysninger... 8 Skema... 9 SMS Abonnement... 10 Karakter...

Læs mere

Web-baseret metadata redigeringsmodul

Web-baseret metadata redigeringsmodul Kravspecifikation Geodata Danmark Geodatacentret I/S Energivej 3 4180 Sorø Tlf. 5786 0400 Fax. 5786 0414 GIS Danmark A/S Birkemosevej 7 6000 Kolding Tlf. 7399 1100 Fax. 7399 11199 Web www.geodata.dk Web-baseret

Læs mere

Daglig brug af JitBesked 2.0

Daglig brug af JitBesked 2.0 Daglig brug af JitBesked 2.0 Indholdsfortegnelse Oprettelse af personer (modtagere)...3 Afsendelse af besked...4 Valg af flere modtagere...5 Valg af flere personer der ligger i rækkefølge...5 Valg af flere

Læs mere

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Version 1.10 Versionshistorik Version Dato Opsummerende beskrivelse af ændringer 1.00 2010-10-5

Læs mere

Mobile Arbejdssedler. Mobile TID. Mobile Observationer

Mobile Arbejdssedler. Mobile TID. Mobile Observationer Næsgaard MOBILE Generelt Flere vejledninger Næsgaard MOBILE kan anvendes til markregistrering og/eller til tidsregistrering. Har du adgang till både Mark og TID i PC program kan du som administrator bestemme

Læs mere

Indholdsfortegnelse for kapitel 3

Indholdsfortegnelse for kapitel 3 Indholdsfortegnelse for kapitel 3 Kapitel 3 Design............................................................ 2 Database........................................................... 3 ER-diagram.................................................

Læs mere

ADK 1.0 KRAVSPECIFIKATION

ADK 1.0 KRAVSPECIFIKATION ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 23-06-2014 MST Oprettelse af integrationskrav 0.2 25-06-2014 HAH Review for forståelighed og stringens.

Læs mere

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Accepttest-specifikation

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Accepttest-specifikation Udgave 2 2. SEMESTERPROJEKT Gruppe 5 Secure O matic Accepttest-specifikation Benjamin Sørensen, 02284 Tomas Stæhr Hansen, 03539 Stefan Nielsen, 02829 Mubeen Ashraf, 9279 Hussein Kleit, 9281 SECURE O MATIC

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

PID2000 Archive Service

PID2000 Archive Service PROLON CONTROL SYSTEMS Herstedvesterstræde 56 DK-2620 Albertslund Danmark Tlf.: (+45) 43620625 Fax: (+45) 43623125 PID2000 Archive Service Bruger vejledning Juni 2002 Denne manual beskriver brugen af softwaren

Læs mere

Elaboration fase 2. semester projekt 2008-04-11. Gruppe 4

Elaboration fase 2. semester projekt 2008-04-11. Gruppe 4 Indholdsfortegnelse Analysemodeller... 4 Domænemodel... 4 ER-model... 5 Designmodeller... 7 Designklassediagram... 7 Sekvensdiagram... 9 Relationel model... 10 Diskussion af datastrukturer, algoritmer

Læs mere

Indhold. Side 2 af 26

Indhold. Side 2 af 26 Tema Design Design, Programmering og test af Adressebog Fra d. 17 april til 20 april 2012 Vejledere: Gunhild Marie Andersen Kis Boisen Hansen Gruppe B Deltagere Side 1 af 26 Indhold Indledning.... 3 Kodestandard...

Læs mere

Kontoplan Plus. Felter i Plus+ kontoplanen... 3. Eksternkonto... 3. Effekt... 3. Primo... 3. MomsABC... 3. Årskode... 3. Prv... 3. KontoNavn2...

Kontoplan Plus. Felter i Plus+ kontoplanen... 3. Eksternkonto... 3. Effekt... 3. Primo... 3. MomsABC... 3. Årskode... 3. Prv... 3. KontoNavn2... Kontoplan plus... 2 Felter i Plus+ kontoplanen... 3 Eksternkonto... 3 Effekt... 3 Primo... 3 MomsABC... 3 Årskode... 3 Prv... 3 KontoNavn2... 4 Funktioner i kontoplan plus... 4 Konteringsvejledning...

Læs mere

Automatisk Vandingssystem

Automatisk Vandingssystem Automatisk Vandingssystem Projektdokumentation Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård Hansen - 201205713 - IKT Kasper Sejer Kristensen

Læs mere

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 -

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 - - 1 - Indholdsfortegnelse Hvorfor skal jeg tage backup af min blog? Side 3 Tag backup med UpDraft Side 4 Tag manuelt backup Side 8-2 - Hvorfor skal jeg tage backup af min blog? Lige meget om du har opbygget

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

Læs mere

HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE

HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE 1 Tekniske Krav 1.1 Hardware krav: En skærm gerne med touch Hvis skærmen ikke har touch, skal du bruge et tastatur og en mus Webcam Gerne i HD En ekstern lydenhed

Læs mere

NYT Panda Antivirus 2007 Kom godt i gang Vigtigt! Læs venligst grundigt afsnittet i denne guide om online registrering. Her findes nødvendige oplysninger for maksimal beskyttelse af din PC. Afinstaller

Læs mere

UML til kravspecificering

UML til kravspecificering UML til kravspecificering UML mini-kompendium - til brug i forbindelse med modellering af kravspecifikationer. Copyright 2006 Teknologisk Institut, IT-Udvikling Aktivitetsdiagram 2/9 Aktion Aktionsnavn

Læs mere

Administrator v1.0 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk

Administrator v1.0 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk Administrator v1.0 QUICK GUIDE Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk INTRODUKTION TIL REKVI-KONTOR Ideen med Rekvi-Kontor systemet udsprang

Læs mere

Vejledning i brug af system til online indberetning af mønstringsdata

Vejledning i brug af system til online indberetning af mønstringsdata Vejledning i brug af system til online indberetning af mønstringsdata Søfartsstyrelsen kan tilbyde samtlige rederier mulighed for at kunne indberette mønstringsdata elektronisk. Den elektroniske indberetning

Læs mere

Pakkepriser i Eftermarkedsportalen. Brugervejledning

Pakkepriser i Eftermarkedsportalen. Brugervejledning Pakkepriser i Eftermarkedsportalen Brugervejledning 1 Indhold Brugervejledning - Pakkepriser... 3 Forhandlerindstillinger... 3 Egne reservedele... 3 Oversigt over væsketyper, der skal opdateres med reservedelsnumre

Læs mere

Videregående Programmering Obligatorisk opgave - 3. semester, efterår 2004

Videregående Programmering Obligatorisk opgave - 3. semester, efterår 2004 Overvågningssystem Beskrivelse Bagagesorteringssystemet består af et antal skranker (check-in) til modtagelse og registrering af bagage, et automatiseret sorteringsanlæg samt et antal terminaler (gates),

Læs mere

Tlf. +45 7027 1699 Fax + 45 7027 1899

Tlf. +45 7027 1699 Fax + 45 7027 1899 Firmaordninger I firmaoversigten kan du holde styr på dit kundekartotek samt disses bookinger. Der kan desuden oprettes andre firmaer end dit eget. Herved kan der udbydes særlige ydelser på med egne arbejdstider.

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

Sektornet VPN Installationsvejledning Windows Vista/7

Sektornet VPN Installationsvejledning Windows Vista/7 Sektornet VPN Installationsvejledning Windows Vista/7 Version 5.0 Af Jesper Skou Jensen og Mads Udengaard Sørensen 1 Start installationen 1 1 Indledning Denne vejledning gennemgår opsætning af Sektornet

Læs mere

Erfaringer med Information Management. Charlottehaven Jens Nørgaard, NNIT A/S jnqr@nnit.com

Erfaringer med Information Management. Charlottehaven Jens Nørgaard, NNIT A/S jnqr@nnit.com Erfaringer med Information Management Charlottehaven Jens Nørgaard, NNIT A/S jnqr@nnit.com Agenda Hvor ligger virksomhedens information gemt og hvor opstår kravet til at finde denne information. Find Find

Læs mere

Denne vejledning dækker opsætning og brug af påmindelsesprofiler og påmindelser om manglende registrering af fravær på AMU kurser.

Denne vejledning dækker opsætning og brug af påmindelsesprofiler og påmindelser om manglende registrering af fravær på AMU kurser. Påmindelsesprofiler Sidst opdateret 28-09-2011/version 2/UNI C/Frederik Andersen Indhold Ændringer og tilføjelser Centrale begreber Generelt Arbejdsgange Denne vejledning dækker opsætning og brug af påmindelsesprofiler

Læs mere

Version 8.0. BullGuard. Backup

Version 8.0. BullGuard. Backup Version 8.0 BullGuard Backup 0GB 1 2 INSTALLATIONSVEJLEDNING WINDOWS VISTA, XP & 2000 (BULLGUARD 8.0) 1 Luk alle åbne programmer, bortset fra Windows. 2 3 Følg instrukserne på skærmen for at installere

Læs mere

Skriftlig eksamen i Datalogi

Skriftlig eksamen i Datalogi Roskilde Universitetscenter Skriftlig eksamen i Datalogi Modul 1 Sommer 1999 Opgavesættet består af 5 opgaver, der ved bedømmelsen tillægges følgende vægte: Opgave 1 15% Opgave 2 15% Opgave 3 8% Opgave

Læs mere

Nyt i SkoleIntra 5.9. Sidst ændret den 25 05 2015. Adgang til at redigere elevplaner for elever med sekundær klassetilknytning

Nyt i SkoleIntra 5.9. Sidst ændret den 25 05 2015. Adgang til at redigere elevplaner for elever med sekundær klassetilknytning Nyt i SkoleIntra 5.9 Sidst ændret den 25 05 2015 Adgang til at redigere elevplaner for elever med sekundær klassetilknytning I SkoleIntra kan man tilknytte en elev til en anden klasse end normalklassen.

Læs mere

Ved at klikke på ADMIN i øverste menu linje går man ind i butiks administrations delen.

Ved at klikke på ADMIN i øverste menu linje går man ind i butiks administrations delen. Vejledning i www.tempobooking.dk s butiksadministration. Efter butiks LOGIN vises dagsoversigten: Ved at klikke på ADMIN i øverste menu linje går man ind i butiks administrations delen. Butiksadministrationen

Læs mere

Hosted CRM Outlook client connector setup guide. Date: Version: 1. Author: anb. Target Level: Customer. Target Audience: End User

Hosted CRM Outlook client connector setup guide. Date: Version: 1. Author: anb. Target Level: Customer. Target Audience: End User Hosted CRM 2011 Outlook client connector setup guide Date: 2011-09-08 Version: 1 Author: anb Target Level: Customer Target Audience: End User Language: da-dk Page 1 of 19 LEGAL INFORMATION Copyright 2011

Læs mere

HHBR. Design. Kvalitets vurdering. Opgaven. Målgruppe og Budskab. De Grafiske valg

HHBR. Design. Kvalitets vurdering. Opgaven. Målgruppe og Budskab. De Grafiske valg Opgaven Der skal designes en hjemmeside til en pensioneret revisor, som ønsker at starte en fritids beskæftigelse op, som privat revisor. Han Ønsker en hjemmeside der skal kort fortælle om hans forretning.

Læs mere

Smart-ebizz Manual til Bookinsystem Indholdsfortegnelse Kom hurtigt i gang med dit booking system:... 3 Overblikket over dit bookingsystem... 4 Hovedside... 4 Kunder... 4 Opret ny Kunde... 4 Vagtplaner...

Læs mere

IT projekt. sæt et mål og nå det med omtanke!

IT projekt. sæt et mål og nå det med omtanke! IT projekt sæt et mål og nå det med omtanke! Det overordnede FORMÅL med dias-showet er at fortælle hvordan vi gennemfører IT projekter med succes ved hjælp af Microsoft Solutions Framework MSF modeller:

Læs mere

Elektronisk spørgeskema 2009. Vejledning

Elektronisk spørgeskema 2009. Vejledning Elektronisk spørgeskema 2009 Vejledning Indberetning på Elektronisk spørgeskema for 2009 Introduktion Elektronisk spørgeskema 2009 (ESP 2009) giver Dem mulighed for at lette arbejdet i forbindelse med

Læs mere

Obligatorisk opgave i objektorienteret analyse og design

Obligatorisk opgave i objektorienteret analyse og design Obligatorisk SD-opgave s. Obligatorisk opgave i objektorienteret analyse og design Løs følgende, som en indviduel opgave. I må gerne samarbejde i grupper, men alle har ansvar for at udfærdige sin egen

Læs mere

Opgaveplanlægger. Opgaveplanlægger

Opgaveplanlægger. Opgaveplanlægger Opgaveplanlægger Ved hjælp af opgaveplanlæggeren har du mulighed for at få afviklet periodiske aktiviteter automatisk på et valgt klokkeslæt og med ønsket gentagelseshyppighed. Dvs. der er mulighed for

Læs mere

Delaflevering. Webdesign og webkommunikation, (hold 2), IT Universitetet, f2011. Kim Yde, kyd@itu.dk. Kenneth Hansen, kenhan@itu.

Delaflevering. Webdesign og webkommunikation, (hold 2), IT Universitetet, f2011. Kim Yde, kyd@itu.dk. Kenneth Hansen, kenhan@itu. Delaflevering Webdesign og webkommunikation, (hold 2), IT Universitetet, f2011. Kim Yde, kyd@itu.dk Kenneth Hansen, kenhan@itu.dk 1 Indholdsfortegnelse Problemfelt - Problemformulering... 3 Målgruppe...

Læs mere

DKAL Snitflader REST Register

DKAL Snitflader REST Register DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4

Læs mere

Programmering C RTG - 3.3 09-02-2015

Programmering C RTG - 3.3 09-02-2015 Indholdsfortegnelse Formål... 2 Opgave formulering... 2 Krav til dokumentation af programmer... 3 ASCII tabel... 4 Værktøjer... 5 Versioner af ASCII tabel... 6 v1.9... 6 Problemer og mangler... 6 v2.1...

Læs mere

Regnskabsprogram til kontrol af brændstofforbrug til køretøjer.

Regnskabsprogram til kontrol af brændstofforbrug til køretøjer. Regnskabsprogram til kontrol af brændstofforbrug til køretøjer. Manual for BenzinTjek-xp Side. C. Lindstrøm 2005-2006 Sidst revideret 14. januar 2006 Side 2. Manual for BenzinTjek-xp Indholdsfortegnelse

Læs mere

Oktober 2013 HLG/XIGA. Opstartsvejledning ATS Engros 1/12

Oktober 2013 HLG/XIGA. Opstartsvejledning ATS Engros 1/12 Oktober 2013 HLG/XIGA Opstartsvejledning ATS Engros 1/12 1. ATS Engros vejledning for aktører Formålet med dette dokument er at beskrive, hvordan du kommer i gang med at anvende ATS til test af certifikat

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Maj 2015 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

Web Admin 5.5. Brugsvejledning for Domain admin. Copyright 2003 Gullestrup.net

Web Admin 5.5. Brugsvejledning for Domain admin. Copyright 2003 Gullestrup.net Web Admin 5.5 Copyright 2003 Gullestrup.net Log ind på systemet Start med at gå ind på http://mailadmin.gullestrup.net i din browser. Indtast din Email Adresse samt Password, som du tidligere har modtaget

Læs mere

Vejledning i brug af Interbook (Frederiksberg) til brugere med adgangskode

Vejledning i brug af Interbook (Frederiksberg) til brugere med adgangskode Vejledning i brug af Interbook (Frederiksberg) til brugere med adgangskode Udarbejdet af Kultur & Fritid, februar 2010. - 1 - Hvad er Interbook?...- 3 - Brugernavn og kodeord...- 3 - Startsiden...- 3 -

Læs mere

Opsætning af MobilePBX med Kalenderdatabase

Opsætning af MobilePBX med Kalenderdatabase Opsætning af MobilePBX med Kalenderdatabase Dette dokument beskriver hvorledes der installeres Symprex Exchange Connector og SQL Server Express for at MobilePBX kan benytte kalenderadadgang via database

Læs mere

Hosted CRM Outlook client connector setup guide. Date: Version: 1. Author: anb. Target Level: Customer. Target Audience: End User

Hosted CRM Outlook client connector setup guide. Date: Version: 1. Author: anb. Target Level: Customer. Target Audience: End User Hosted CRM 2011 Outlook client connector setup guide Date: 2011-06-29 Version: 1 Author: anb Target Level: Customer Target Audience: End User Language: da-dk Page 1 of 16 LEGAL INFORMATION Copyright 2011

Læs mere

Eksamensbeviser og karakterer til Eksamensdatabasen Sidst opdateret 01-02-2007/version 1.1/Steen Eske Christensen

Eksamensbeviser og karakterer til Eksamensdatabasen Sidst opdateret 01-02-2007/version 1.1/Steen Eske Christensen Eksamensbeviser og karakterer til Eksamensdatabasen Sidst opdateret 01-02-2007/version 1.1/Steen Eske Christensen Indhold Ændringer Centrale begreber Generelt Arbejdsgange Vejledningen består af 3 dele,

Læs mere

MobileCTI Dialer Installations og konfigurations vejledning

MobileCTI Dialer Installations og konfigurations vejledning MobileCTI Dialer Installations og konfigurations vejledning Vejledning i Installation og konfiguration af MobileCTI Outlook Dialer / MobileCTI TAPI Dialer Version 2.10 December 2005 www.blueposition.com

Læs mere

Bilag 3A.7 Brugergrænseflader

Bilag 3A.7 Brugergrænseflader Bilag 3A.7 Brugergrænseflader Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 3 USER EXPERIENCE GUIDELINES (UX-GUIDELINES)... 5 3.1 GENERELLE UX-GUIDELINES... 5 3.1.1

Læs mere

Database. Pr jekt. Hold CLmul-a14e Gruppe 3 3. semester 2015. Vejledere: Tue Becher Ivan R. Frederiksen

Database. Pr jekt. Hold CLmul-a14e Gruppe 3 3. semester 2015. Vejledere: Tue Becher Ivan R. Frederiksen Database Pr jekt Hold CLmul-a14e Gruppe 3 3. semester 2015 Vejledere: Tue Becher Ivan R. Frederiksen Indholdsfortegnelse 1. Problemformulering 2. ER-diagram 3. Attribut-tabel 4. Use Case-model 5. Use Case

Læs mere

Bilag 2: Kravspecifikation - Side 1

Bilag 2: Kravspecifikation - Side 1 Bilag 2: Kravspecifikation - Side 1 Use-Cases Syddjurs Kommune betragter den tværgående sundhedsplatform som en del af en større infrastruktur, hvor data flyder mellem forskellige elementer. Dette dokument

Læs mere

Quick Guide for Mobil Reception (Omhandler mobil reception også kaldet isymphony)

Quick Guide for Mobil Reception (Omhandler mobil reception også kaldet isymphony) Quick Guide for Mobil Reception (Omhandler mobil reception også kaldet isymphony) Generelt Mobil Reception er et værktøj som bruges til at overvåge medarbejdere, kø er og meget andet samt styre dit omstillingsanlæg

Læs mere

Rapport generator til Microsoft C5

Rapport generator til Microsoft C5 Generelt Rapportgeneratoren til C5 kan benyttes sammen med alle versioner af C5 og kræver INGEN tillægsmoduler eller tilkøb af C5. Den kører på: C5 version 1.5x, 1.6x, 2.x, 3.x, 4.x, 2008, 2010 og 2012.

Læs mere

Panda Antivirus + Firewall 2007 NYT Titanium Kom godt i gang Vigtigt! Læs venligst grundigt afsnittet i denne guide om online registrering. Her findes nødvendige oplysninger for maksimal beskyttelse af

Læs mere

Konference om Cloud Computing 18. maj 2011. Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD

Konference om Cloud Computing 18. maj 2011. Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD Konference om Cloud Computing 18. maj 2011 Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD POC, hvad er det? En søgning på internettet viser, at de fleste sites

Læs mere

WORKCYCLUS Kortlægninger

WORKCYCLUS Kortlægninger WORKCYCLUS Kortlægninger Vers 4.0 Juni 2013 Workcompany A/S Amagertorvet 33, 4.sal DK-1160 København K www.workcompany.dk Workcyclus Professionel Brugerguide Kortlægninger - Version 4.0 (Juni 2013) 1.

Læs mere

Dokument- og Sagsstyringssystem

Dokument- og Sagsstyringssystem Dokument- og Sagsstyringssystem Mads Nissen Kongens Lyngby 2010 IMM-B.Eng-2009-36 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone

Læs mere

Modtag købte materialer. Maj 2012

Modtag købte materialer. Maj 2012 Modtag købte materialer Maj 2012 Indhold Modtag købte materialer... 1 Indhold... 2 Modtag købte materialer... 3 Start af Modtag købte materialer... 3 Skanning af stregkoder... 4 Registrering af modtaget

Læs mere

Vejledning til Kilometer Registrering

Vejledning til Kilometer Registrering Vejledning til Kilometer Registrering iphone Appen som holder styr på dit firma og privat kørsel. Udviklet af Trisect Development 2011. www.trisect.dk For iphone version 4.2 og nyere. Med Kilometer Registrering

Læs mere

It-sikkerhedstekst ST8

It-sikkerhedstekst ST8 It-sikkerhedstekst ST8 Logning til brug ved efterforskning af autoriserede brugeres anvendelser af data Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST8 Version 1 Maj 2015 Logning

Læs mere

Vejledning i brug af Interbook (Frederiksberg)

Vejledning i brug af Interbook (Frederiksberg) Vejledning i brug af Interbook (Frederiksberg) Opdateret af Kultur & Fritid, september 2010. - 1 - Hvad er Interbook?...- 3 - Brugernavn og kodeord...- 3 - Startsiden...- 3 - Nyheder...- 4 - Søg ledige

Læs mere

TK/TBL / 25.08.2014 v.0.1. DigiMatch. Elektronisk Kamprapport

TK/TBL / 25.08.2014 v.0.1. DigiMatch. Elektronisk Kamprapport TK/TBL / 25.08.2014 v.0.1 DigiMatch Elektronisk Kamprapport 1 Procedure før kampstart... 3 DigiMatch download... 3 Registerniveau... 7 Indstillinger... 9 Login... 9 Tilpas knapperne... 10 Kampregistrering...

Læs mere

Audit. Kaizenlederens vejledning. DI-version 2015-04-14

Audit. Kaizenlederens vejledning. DI-version 2015-04-14 DI-version 2015-04-14 Audit Alle rettigheder tilhører DI 3-2-1 - Audit - Kaizenlederens Vejledning - 2015-04-14 side 1 af 11 Instruktion til kaizenleder Rettigheder DI ejer alle rettigheder til denne instruktion.

Læs mere

Installation og ibrugtagning af Geomagic Alibre Vault

Installation og ibrugtagning af Geomagic Alibre Vault Karl Lausten Bright Ideas Tlf.:+45 98 62 28 37 Mejsevej 8 Email: klausten@bright-ideas.dk DK-9600 Aars www.bright-ideas.dk CVR 26 85 59 69 12.02.2014 Installation og ibrugtagning af Geomagic Alibre Vault

Læs mere

Bilag 3A.7 Brugergrænseflader

Bilag 3A.7 Brugergrænseflader Version 0.8 19-12-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 4 2 INDLEDNING... 5 3 USER EXPERIENCE GUIDELINES (UX-GUIDELINES)... 6 3.1 GENERELLE UX-GUIDELINES... 6 3.1.1 MODTAGERORIENTERET SPROG...

Læs mere

Vejledning. Opsætning af Trio Web Vers 2.0 feb. 2010

Vejledning. Opsætning af Trio Web Vers 2.0 feb. 2010 Opsætning af Trio Web Vers 2.0 feb. 2010 Indholdsfortegnelse Opsætning af Trio Web... 3 Generel opsætning af Trio Web... 3 Databaseopsætning... 3 DB... 3 Aar... 4 Login... 4 Internet... 4 Port... 4 Registreringsnøgle...

Læs mere

Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen

Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen Indhold Ændringer Centrale begreber Generelt Arbejdsgange Vejledningen består af 3 dele, som kan læses hver for sig. Du kan derfor

Læs mere

Klon en ipad. - en vejledning til klon af ipad

Klon en ipad. - en vejledning til klon af ipad Klon en ipad - en vejledning til klon af ipad Indholdsfortegnelse 1. Hvorfor klone en ipad 2. Installer itunes 3. Klargør en Master ipad 4. Husk at begrænse 5. Backup af Master ipad 6. Husk at... 7. Opdater

Læs mere

Anvendelse af dobbelthistorik i GD2

Anvendelse af dobbelthistorik i GD2 Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version:

Læs mere

DMX styring med USB-interface

DMX styring med USB-interface DMX styring med USB-interface Introduktion...2 DMX bibliotek...3 Programmering af kanaler...7 Sådan skabes et show/en lyssekvens...11 Introduktion DMX LightPlayer er en avanceret men meget brugervenlig

Læs mere