2. års projekt, bachelor i softwareudvikling, IT-Universitetet. Hotel system

Størrelse: px
Starte visningen fra side:

Download "2. års projekt, bachelor i softwareudvikling, IT-Universitetet. Hotel system"

Transkript

1 2. års projekt, bachelor i softwareudvikling, IT-Universitetet Hotel system Morten Esbensen Nikolas Bang Manscher Casper Hjermitslev Jensen Casper Nielsen Voigt Marco Pock Steen Fraile Joachim Sejr Vejleder: Niels Hallenberg

2 INDHOLD INDHOLD Indhold Indhold i 1 Indledning 1 2 Microsoft Team Model Ansvarsfordeling Konklusion Kravspecifikation B. Overordnede behov B1. Forretningsmæssige mål B2. Tidligt bevis for gennemførlighed (proof of concept) Konklusion C. Arbejdsopgaver C1. Check-in C2. Check-ud C3. Booking C4. Ændre booking C5. Bestil service C6. Ændre ophold(stay) C7. Ændre gæst-information(guest) C8. Ændre værelse(room) C9. Ændre service C10. Tilføj ekstra gæst (Guest) C11. Erstat gæst/betaler (Guest) C12. Foretag vedligeholdelse af værelse(room Maintenance) D. Data systemet skal anvende Hotel Landmark Room RoomState RoomType PricingStrategy Stay Guest i

3 INDHOLD INDHOLD Service ServiceType E. Andre funktionelle krav E1. Komplekse beregninger og regler E2. Udskrifter og rapporter F. Integration af externe systemer F1. Eksternt Bookingsystem F5. Integration med nye eksterne systemer G. Teknisk IT-arkitektur G1. Brug af eksisterende hardware og software G2. Nyt hardware og software L. Drift, support og vedligeholdelse L1. Svartider: L2. Tilgængelighed: L3. Datalagring: L4. Support: Vurdering af SL Datamodel Udvikling Kendte bugs Interface Design Analyse Serveren Søgeagent Receptionistklienten Sikkerhed Konklusion Klient Design Overordnet systemarkitektur GRASP Adapter Factory Singleton Strategy Model View Controller Forbedringer ii

4 INDHOLD INDHOLD 6.9 F# kode Implementering Konklusion Server Design Design Patterns Klasse Diagram Package Diagram Kode udvidelser Design af brugergrænseflade 38 9 Test Indledning: Usability test Formål Arbejdsopgaver Resultater UnitTests: Funktionalitetstest Refleksion Forløbet Refleksion Kommunikation: Deadlines: SMU: Endeligt produkt: Konklusion: Konklusion 50 iii

5 1 INDLEDNING 1 Indledning Denne rapport er udarbejdet i marts-maj 2009 som en del af vores 2. års projekt på IT- Universitetet (ITU) i kurset BAAAP - "Projektklynge: Andetårsprojekt". Niels Hallenberg fungerer som vejleder sammen med Kathrine Dalgaard Skovdal. Under en fase af projektet har vi et aktivt samarbejde med tre studerende fra Singapore Management University (SMU). Formålet med projektet er bl.a. at lære at samarbejde i et større hold (6 personer) med et andet virtuelt team over stor fysisk afstand og kulturelle forskelle; i dette tilfælde 3 studerende fra Singapore. Dette betyder at vi må kommunikere effektivt med de studerende fra Singapore ved hjælp af forskellige kommunikationsformer og sørge for overholde deadlines da deres del af projektet er afhængig af vores. Derudover er det for vores vedkommende en del af formålet at lære at implementere webservices i kodesproget C# og en klient (med dele af koden i F#), der skal bruges af receptionisten på hotellet. Overordnet er det formålet med projektet at fremme vores færdigheder med koordinering af projekter. Mange af vores evner til at koordinere og udføre projekter får vi fra et andet kursus på dette semester: BSUP - "Systemudvikling og Projektorganisering". Vores webservice repræsenterer et hotel, der vil give hotelsøgemaskiner adgang til (antal) ledige værelser, mulighed for at booke værelse(r) på hotellet mm. Vores egen klient skal også benytte vores webservice til at se, oprette og ændre bookinger på hotellet, hvor klienten benyttes. Til disse opgaver er det nødvendigt med en SQL database, der indeholder information om gæster, værelser osv. Udover selve koden er det også en del af vores opgave at dokumentere vores projekt (bl.a. ved hjælp af kravspecifikation, data modeller og dokumentation af kommunikation) og teste koden ved hjælp af de teknikker vi har lært i tidligere kurser. 1

6 2 MICROSOFT TEAM MODEL 2 Microsoft Team Model 2.1 Ansvarsfordeling I det følgende afsnit vil vi forklare om vores brug af Microsofts model for succesfuldt projektarbejde. Vi har i gruppen valgt at fordele ansvar ud fra principperne i "Microsoft Team Model"(MTM), der er en tilgang Microsoft har udformet der skal guide et projekthold mod succes på alle områder. Modellen definerer roller, funktionsområder og ansvar for mindre projekthold hvor alle deltagere deler ansvaret for projektets succes, men med forskellige fokusområder. Dette betyder altså at ansvaret bliver delt mellem alle deltagere, men der alligevel er enkeltpersoner, der har hovedansvar for de forskellige områder. Modellen er udviklet af Microsoft på baggrund af flere år erfaring med udviklingsprojekter og generel "best practice"på området. I vores projekt valgte vi at benytte MTM da vi blev introduceret for det under kurset, og tænkte det ville være interessant at forsøge at fordele rollerne på denne måde. Vi tænkte det ville være en let måde hurtigt at fordele ansvar ved nye opgaver, eller opgaver der bare skal klares. Vi fordelte roller ud fra hvad folk er bedst til og interesserer sig mest for da vi mente det ville sørge for at medlemmerne er mest produktive og glade for projektforløbet. Og da alle kunne få en rolle de var glade for var det ikke noget problem. Vi har fordelt rollerne på følgende måde: Architecture: Marco Arkitektens ansvar er at designe hvordan programmet løser opgaven, som er blevet stillet ved projektets start. Communication management and Test: Nikolas & Joachim Communication Managements har ansvar for at aftaler med Singapore bliver overholdt af gruppen, samt at den generelle kommunikation er af ordentlig kvalitet. Testernes ansvar er at finde så mange bugs i softwaret, som de kan. De skal også udpege steder hvor koden eventuelt kunne optimeres, men behøver ikke at kunne optimere den. User Experience: Nikolas & Joachim Dem med "User Experience-rollen har ansvaret for at optimere og effektivicere den grafiske brugergrænseflade og øge programmets performance. Program management: Casper J. Program Managerens opgave er at aflevere et stykke færdigt program til tiden, der er af ordentlig kvalitetog indenfor projektets scope. Development and release: Morten & Casper V. 2

7 2.2 Konklusion 2 MICROSOFT TEAM MODEL Udviklerne har til ansvar at realisere arkitektens vision. Udgiverne har til ansvar at gøre programmet klart til aflevering. 2.2 Konklusion Under projektforløbet forsøgte vi at holde os til de tildelte roller, men fandt det svært at holde os til rollerne. Det var f.eks. svært kun at lade kommunikationen foregå via de kommunikationsansvarlige under møder med de studerende fra Singapore, da det var mest hensigtsfuldt at lade alle fra holdet deltage i møderne og det dermed er de programmeringsansvarlige, der havde bedst styr på hvad de skal bruge fra det andet hold. Så på den måde har vi ikke holdt os til rollerne som det var hensigten. Det er selvfølgelig heller ikke meningen at MTM skal tvinges ned over en gruppe, men snarere fungere som en vejledende guide. Men alt i alt har det været interessant at prøve modellen, og det har på ingen måde svækket vores projektforløb selvom det var eksperimenterende. 3

8 3 KRAVSPECIFIKATION 3 Kravspecifikation Kravspecikationen er de skrvne regler for hvad det færdige produkt skal opfylde når projektforløbet er slut. Det skal være muligt at ændre, tilføje og fjerne krav i løbet af processen, da projektet følger en iterativ udviklingsstruktur. Først vil de overordnede krav samt tasks produktet skal kunne understøtte beskrives, og derefter følger en redegørelse for datastrukturen, andre funktionelle krav og hvordan systemet skal kunne integreres med eksterne systemer. Til sidst følger en teknisk beskrivelse af arkitekturen og reglerne for systemets drift, support og vedligeholdelse. 3.1 B. Overordnede behov Dette kapitel forklarer hvordan kravene tænkes at tilgodese kundens forretningsmæssige mål og hvordan risikable krav ønskes afklaret tidligt B1. Forretningsmæssige mål Kunden (i dette tilfælde en fiktiv interessent eller Niels) ønsker ved erhvervelse af systemet at opfylde nogle forretningsmæssige mål. De følgende mål er anført som forventninger fra kundens side; altså ikke direkte krav, da kunden også selv har delansvar for om hvorvidt målene bliver opnået. De følgende mål er lige vigtige for kunden og skal derfor nås så hurtigt som muligt, men som sagt har kunden også indflydelse. Dog har nogle mål også en tidsfrist som vist i tabellen. Formål med det nye receptionist system 1. Færre fejlindtastninger. 2. Effektiv støtte til alle arbejdsopgaver. 3. Løbende forbedring af arbejdsgange. 4. Lavere driftsomkostninger. 5. Opfylde krav fra kunden(niels) Overordnede løsninger Relaterede krav Evt. tidsfrist Systemet kontrollerer om indtastningerne er realistiske. Alt nødvendigt data er til rådighed ved arbejdet. Mulighed for at ændre data om nødvendigt. Det er let at udvide systemet med nye funktioner hvis der skulle komme nye krav til arbejdsgange. Mindske antallet af arbejdstimer pr. gæst ved at effektivisere nødvendige processer der vedrører gæsten. Hvis der var flere systemer før erstattes de med ét enkelt system. Støtte til alle opgaver i kapitel C. Understøtter alle opgaver fra tidligere systemer. Eller fra eventuelt manuelt arbejde. 20/

9 3.2 C. Arbejdsopgaver 3 KRAVSPECIFIKATION B2. Tidligt bevis for gennemførlighed (proof of concept) For at undgå at komme til at stå i en situation hvor man bliver nødt til at afbryde udviklingen af et system, fordi en essentiel del af systemet simpelthen ikke kan laves ønsker kunden "Proof of concept"på at de risikable dele af udviklingen kan gennemføres. Risikable krav hvor tidligt bevis kræves: 1. Effektiv støtte til de mest essentielle arbejdsopgaver (Task C1-3). 2. Brugervenlighed 3. Svartider med det planlagte antal brugere. Eksempel på bevis: En prototype af de nødvendige skærmbilleder (gerne på papir) vurderes af ekspertbrugere. Kan ske efter få arbejdsdage når programmet tages i brug. En prototype (gerne på papir) usabilitytestes med de kommende brugere af systemet. Kan ske efter få arbejdsdage når programmet tages i brug. Et testsystem sættes op med simulation af det forventede antal brugere. Svartiderne måles. Kan ske efter få arbejdsdage når programmet tages i brug Konklusion Vi har altså defineret nogle mål for programmet, der sørger for at vi kan arbejde målrettet mod at udvikle et program kunden kan være tilfreds med. 3.2 C. Arbejdsopgaver Denne sektion omhandler en detaljeret beskrivelse af de arbejdsopgaver, som systemet skal kunne understøtte brugeren i. Arbejdssområde: Hotel Management Brugerprofil: Receptionist. De er ikke nødvendigvis bekendte med IT-systemer. Miljø: Reception C1. Check-in Start: En gæst ankommer. Slut: Gæsten har fået nøgle og værelse. Regnskabsførelse startet. Frekvens: Total: Omkring 0,5 check-ins pr. værelse pr. nat. Vanskelighed: En bus med 50 gæster ankommer. 1. Receptionist finder værelse. Gæst har booket i forvejen. 5

10 3.2 C. Arbejdsopgaver 3 KRAVSPECIFIKATION Ingen passende værelser. Gæst vil have naboværelser. Gæsten prutter om prisen. 2. Registrerer gæstens information. Gæst registreret ved booking. Regulær guest. 3. Registrerer gæsten, der er checket ind. 4. Nøgle udleveres Gæst glemmer at aflevere nøglen tilbage. Gæst vil have to nøgler C2. Check-ud Start: En gæst er ved at forlade hotellet. Slut: En gæst har forladt hotellet. Frekvens: Total: Omkring 0,5 checker ud pr. værelse pr. nat. Vanskelighed: En masse gæster checker ud på samme tid(f.eks. ved sæsonændringer). 1. Gæst afleverer nøgle. Gæst har tabt nøglen. 2. Receptionisten finder prisen for opholdet. 3. Gæst betaler for opholdet. Gæst har betalt i forvejen. 4. Gæst får en regning C3. Booking Start: Gæst kontakter reception. Slut: Gæst har lavet en booking. Frekvens: Ofte. Vanskelighed: Mange bookingønsker på én gang. 1. Gæst kontakter reception. 2. Gæst opgiver bookinginformation. 6

11 3.2 C. Arbejdsopgaver 3 KRAVSPECIFIKATION 3. Receptionist checker ledige værelser. Ingen ledige værelser i det ønskede tidsrum. 4. Receptionist laver booking C4. Ændre booking Start: Gæst kontakter reception. Slut: Receptionist laver de ønskede ændringer i bookingen. Frekvens: Ofte. Vanskelighed: Mange ønsker om bookingændringer på én gang. 1. Gæst kontakter reception. 2. Gæst opgiver nødvendig booking identifikation og ønskede ændringer i bookingen. 3. Receptionisten checker om de nye bookingændringer er mulige. Det er ikke muligt at lave de ønskede ændringer. 4. Receptionisten ændrer bookingen C5. Bestil service Start: Gæst kontakter reception. Slut: Receptionisten registerer service. Frekvens: Mindst én pr. booking. Vanskelighed: En masse gæster ønsker services på samme tid. 1. Gæst kontakter reception. 2. Gæst ønsker services. Service ikke tilgængelig. 3. Receptionist registrerer service C6. Ændre ophold(stay) Start: Gæst kontakter reception. Slut: Receptionist har ændret opholdet. Frekvens: Ofte. Vanskelighed: Mange ophold skal ændres på samme tid. 7

12 3.2 C. Arbejdsopgaver 3 KRAVSPECIFIKATION 1. Gæst kontakter reception. 2. Gæst vil have nyt værelse eller ændre i opholdsdatoerne. Ændringsønske kan ikke opfyldes. 3. Receptionist laver de ønskede ændringer C7. Ændre gæst-information(guest) Start: Gæsten vender tilbage til receptionen for at få skrevet id ind. Slut: Gæsten har fået rettet information. Frekvens: En gang om ugen pr. værelse. Vanskelighed: En stor gruppe skal have tastet id ind. 1. Gæst kontaker reception. 2. Gæst har stadig ikke fået indtastet id i systemet. Gæst har ikke noget id eller id er ugyldigt. 3. Receptionist laver de nødvendige ændringer C8. Ændre værelse(room) Start: Gæsten har fået gæster og får brug for flere værelser. Slut: Gæsten har fået nøgle og værelse. Regnskabsførelse startet. Frekvens: En gang om ugen. Vanskelighed: Mange gæster ønsker flere værelser samtidig. 1. Gæst kontakter reception. 2. Gæst ønsker et eller flere værelser. Der er ikke flere værelser. 3. Værelse findes og bookes. 4. Nøgle udleveres til gæst. 8

13 3.2 C. Arbejdsopgaver 3 KRAVSPECIFIKATION C9. Ændre service Start: Gæsten har fundet en fejl i regningen. Slut: Fejlen er rettet og ny regning er udskrevet eller fejlen er forklaret. Frekvens: 1 ud af 100 gæster. Vanskelighed: Uenighed om fejlen. 1. Gæst modtager regning. 2. Gæst eller receptionist finder en fejl. Gæst og receptionist er uenige om fejlen. Bestyrer tilkaldes. 3. Fejl rettes. 4. Ny regning udskrives C10. Tilføj ekstra gæst (Guest) Start: Gæsten får ven på besøg. Slut: Ekstra gæst er registreret i systemet. Frekvens: Ofte. Vanskelighed: Stor gruppe ankommer til hotellet. 1. Gæst skal have ekstra gæster på værelset. Der er ikke mere plads på den betalende gæsts værelse(r). 2. Receptionist har indtastet den ekstra gæsts information C11. Erstat gæst/betaler (Guest) Start: Gæsten vil ændre betaler på ophold(stay). Slut: Ændring foretaget. Frekvens: En gang pr. tiende gæst. Vanskelighed: Problemer med ny betaler(økonomisk). 1. Gæst kontakter receptionen. 2. Gæst vil ændre betaler på opholdet. Ny betaler er ikke med gæsten for at foretage ændringen. 3. Receptionist redigerer betaler på opholdet. 9

14 3.2 C. Arbejdsopgaver 3 KRAVSPECIFIKATION C12. Foretag vedligeholdelse af værelse(room Maintenance) Start: Personale skal udføre vedligeholdelse af værelse. Slut: Arbejde udført og værelse sat til ledig igen. Frekvens: En gang pr. ophold Vanskelighed: Mange værelser tilknyttet det samme ophold. 1. Gæst checker ud fra et ophold. 2. Receptionist ændrer værelsets ledighed. 3. Værelse(r) rengøres/repareres. 4. Receptionist ændrer værelsets ledighed. 10

15 3.3 D. Data systemet skal anvende 3 KRAVSPECIFIKATION 3.3 D. Data systemet skal anvende Systemet skal kunne understøtte den data som er beskrevet i denne sektion. Data skal forstås som den konceptuelle forgænger for de C# objekter senere beskrevet under datamodelafnittet. I denne sektion følger den konceptuelle E/R model over hvordan dataen webservicen og klientsystemet skal anvende den, hvilke restriktioner der skal opfyldes og en kort beskrivelse af felternes betydning. Det skal være muligt at skabe, ændre, slette og for det meste sende dataen mellem klienten og webservicen. Figuren herunder viser en Entity/Relationship- model over dataens indbyrdes sammenhæng. Herefter vil der forekomme en formel beskrivelse af dataen. Entity/Relationship model v1.1 Name, Address, Stars, Phonenumber, Name, Location, Information, Url Hotel Landmark Availability, Startdate, Enddate, Type, Capacity Offseasonprice, Onseasonprice RoomState Room RoomType PricingStrategy Name, Address, Address2,Address3, Identification, Phonenumber, Date, Quantity Name, Price Guest Stay Service ServiceType Startdate, Enddate, State, Numberofpersons Figur 1: Entity/Relationship diagram dataen programmet skulle kunne anvende Hotel En liste over alle hoteller. Det er meningen webservicen skal kunne rumme information om mange hoteller, hver knyttet til deres unikke rum, ophold og gæster. Dataens omfang: Omkring 10 hoteller om året. Kommer an på webservicens understøttelse af forskellige hoteller. 1. Name: Hotellets navn. 11

16 3.3 D. Data systemet skal anvende 3 KRAVSPECIFIKATION 2. Address: Addressen hotellet. 3. Stars: Gennemsnitlig antal stjerner hotellet har fået i reviews. Antallet varierer mellem Phonenumber: Telefon nummeret på hotellets reception til hotellets kontakt person Landmark En liste af alle seværdigheder hotellerne finder relevant for deres kunder. Landmarks repræsenterer bestemte beliggenheder eller turist-attraktioner, som er knyttet til hotellet. Det kan bruges til at lokke påvirke potentielle kunder til netop at vælge hoteller, der ligger tættest seværdigheder de finder interessante. Dataens omfang: Ét hotel 1. Name: Navnet på seværdigheden. 2. Location: Seværdighedens adresse. 3. Url: Et link til en hjemmeside, som beskriver seværdigheden. 4. Informaiton: Ekstra information, fx hvis hotellet giver rabat på seværdigheden Room En liste over alle rum på alle hoteller. Rummene skal betales for at bo på over en periode af gæsterne. Dataens omfang: 23 rum RoomState En liste over alle forskellige status som alle rum kan være knyttet til. Et RoomState beskriver en periode, hvor rummet ikke er ledigt til brug af kunder. Dette ændres af personalet alt efter behov. Dataens omfang: Ca tilføjelser og sletninger (200 tilføjelser og sletninger per rum om året) 1. Availability: Rummet ledighed angivet som 0 eller Startdate: Dato for hvornår rummet starter med at være under reparation. 3. Enddate: Dato for hvornår rummet slutter med at være under reparation 12

17 3.3 D. Data systemet skal anvende 3 KRAVSPECIFIKATION RoomType En liste over alle typer rum. Et RoomType beskriver rummets kapacitet og type. Det er ikke designet til at ændres, kun af personalet tilfælde af et nyt type rum introduceres på ét eller flere af hotellerne. Dataens omfang: 4 måske med 1 tilføjelse meget sjældent. 1. Type: Rum typer: Single, Double, Triple eller Suite. 2. Capacity: Antal personer der er plads til i rummet PricingStrategy En liste over alle varianter af priser, der kan knyttes til RoomTypes. Det er ment til at gøre det muligt at introducere varierende priser baseret på rum-type. Dataens omfang: 1 per RoomType. 1. Offseasonprice: Pris når det er lavsæson. 2. Onseasonprice: Pris når det er højsæson Stay En liste af alle ophold (inklusivt optagede rum) der forekommer på hotellerne. De er knyttet til en betalende gæst og eventuelt et ubestemt ekstra antal gæster. Et opholds pris bliver udregnet på baggrund af rummets potentielt varierende pris, plus de eventuelle services gæsten har modtaget. Dataens omfang: Højst (1 per rum ganget med 365 dage om året per hotel.) 1. Startdate: Opholdets startsdato. 2. Enddate: Opholdets slutdato. 3. State: Opholdets status: Booked, Checked In, Checked Out, Canceled. 4. Numberofpersons: Antal personer knyttet til opholdet Guest En liste over alle gæster på alle hoteller. Gæsterne kan være betalere eller bare ekstra gæster som er booket ind sammen med en betaler. Dataens omfang: (En betaler per ophold plus i gennemsnit 2,3 personer.) 1. Name: Navnet på gæsten. 2. Address1: Gæstens første addresse 13

18 3.3 D. Data systemet skal anvende 3 KRAVSPECIFIKATION 3. Address2: Gæstens anden addresse 4. Address3: Gæstens tredje addresse 5. Identification: Gæstens Identfication. 6. Phonenumber: Gæstens telefon nummer Gæstens Service En liste over alle services, der er blevet købt hotellerne. Dataens omfang: (Antal stay multipliceret med gennemsnitligt 3,5 services per ophold.) 1. Date: Datoen servicen købt. 2. Quantity: Antal services ServiceType En liste over alle service typer der findes på alle hoteller. Kombineret med listen med fysiske services skal det være muligt at udregne prisen på den samlede ydelse. Dataens omfang: 7 plus 2 tilføjelser om året, afgjort af hotellets personale. 1. Name: Navnet på servicen. 2. Price: Prisen på servicen. 14

19 3.4 E. Andre funktionelle krav 3 KRAVSPECIFIKATION 3.4 E. Andre funktionelle krav Hvis man ser bort fra de opgaver i kapitel C og D, som programmet skal kunne udføre, er der stadig nogle funktionaliteter programmet skal kunne, som ikke direkte står skrevet, men som bruges indirekte til at løse de nedskrevne arbejdsopgaver. De beskrives her E1. Komplekse beregninger og regler Her er en tabel over de systemfunktioner der står for udregning og overholdelse af regler som programmet håndterer. Funktion: Rabatten udregnes som en administrator har besluttet. Eksempel på løsning: Rabatten bliver udregnet automatisk, efter nogle regler der er fastsat i programmet. Så kan rabatreglerne ikke blive omgået. Koden kan ses nedenunder. Kode for udregning af rabat: let staydiscount = if(staylength()>5, 0.85, 1.0) guestdiscount = if(guests()>2, GUESTS(), 1.0) totalprice = STAYLENGTH() ROOMRATE() totaldiscount = staydiscount guestdiscount service = SERVICEPRICE() in totalprice totaldiscount + service end"; E2. Udskrifter og rapporter. Her beskrives de forskellige steder i programmet, hvor der laves egentlige udskrifter af information, eller bare bliver vist noget information. Udskriftskrav: Eksempel på løsning: Receptionisten skal kunne udprinte en regning for et ophold, når der checkes ud. Der implementeres en printfunktion. Programmet skal vise en grafisk oversigt Et canvas viser oversigten. over hotellets værelser og deres status. Programmet skal vise en oversigt over de Datatabeller i UI en henter den nødvendige dele af databasen, der skal bruges til at understøtte information fra databasen og viser den. arbejdsopgaverne. 15

20 3.5 F. Integration af externe systemer. 3 KRAVSPECIFIKATION 3.5 F. Integration af externe systemer. Systemet skal integreres med det eksterne online bookingsystem som er vist på Figur 2. Hotel Receptionist F1. Eksternt Booking System Hotel System F5. Nye eksterne systemer Figur 2: Konstekst Diagram F1. Eksternt Bookingsystem. Det eksterne bookingsystem indeholder hotellets data, såsom værelsestilgængelighed og bookingregisteringer. Da al data er gemt på dette eksterne system, er det vitalt for alle arbejdsopgaverne. Frekvens: Hele tiden. Integrationsbehov: Ved åbning af hotelmanagersystemet, skal et login kræves før man kan få adgang til det eksterne system. Managersystemet må møde grænsefladekravene for det eksterne system. Eksempler på løsning: Systemet vil bede brugeren om login. Managersystemet implementerer grænsefladen for det eksterne system F5. Integration med nye eksterne systemer Kunden forventer at kunne koble nye eksterne webservices til systemet om nødvendigt. Dette kan f.eks. være et andet softwarehus. Det kan også være nødvendigt at skifte platform for webservicen. 16

21 3.6 G. Teknisk IT-arkitektur 3 KRAVSPECIFIKATION Systemets grænseflader i klientrollen: Receptionist-systemet kan på brugerens initiativ overføre data for en booking, gæst eller lignende fra det nye system. Receptionist-systemet kan bruge det nye systems database således at data altid er identisk i de to systemer. Dokumentation og rettigheder: Den tekniske grænseflade til Receptionistsystemet skal dokumenteres. Dokumentationen skal kunne forstås af et typisk tredjeparts softwarehus og findes egnet til integrationsformålet. Svartiderne for de forskellige funktioner på grænsefladen skal specificeres. Eksempler på løsning: Eksempler på løsning: Hvis nødvendigt kan et mindre kursus gennemføres for at tredjepart kan forstå dokumentation. Må ikke være en større udgift da dokumentationen bør være udførlig. 3.6 G. Teknisk IT-arkitektur G1. Brug af eksisterende hardware og software. Det antages at brugeren ikke har det nødvendige IT-udstyr til at kunne operere det nye system G2. Nyt hardware og software. For at kunne operere systemet, må brugeren anskaffe det følgende hardware og software: Krav til kundens hardware og software:: Kunden skal anskaffe pc er til brug af systemet. Kunden skal have internetadgang til pc erne for at kunne kommunikere med det eksterne bookingsystem. Eksempel på løsning: Kunden skal anskaffe mindst 2 pc er med Windows XP eller senere. Kunden må anskaffe ADSL eller bedre. 17

22 3.7 L. Drift, support og vedligeholdelse. 3 KRAVSPECIFIKATION 3.7 L. Drift, support og vedligeholdelse. Her beskrives krav til ydelser der først kan testes når systemet er blevet udleveret L1. Svartider: Svartider er nødvendige for kunden, for at kunne teste om systemet kan klare den belasting som systemet vil blive udsat for. Krav til svartider : Eksempel på løsning: Programmet skal ikke bruge for lang tid på at åbne op. Man kan se data og taste inden to minutter. Skifter man felt, skal det ikke kunne Man kan taste inden 0,2 forstyrre brugerens tastehastighed. s.(dette er tiden for det Går man fra et vindue til et andet, skal det ikke kunne forstyrre brugerens tastehastighed. Data skal kunne overføres fra serveren inden at det ødelægger brugerens koncentrationen. Datatabeller skal ikke kunne forstyrre brugeren så meget at det ødelægger koncentrationen. mentale skift mellem felter) Man kan taste inden 1,3 s.(dette er tiden for det mentale skift mellem delaktiviteter) Man kan se opdateret data inden 20 s.(dette er tiden der går før man mister tålmodigheden og begynder at lave noget andet) Man kan se opdateret data inden 4 s L2. Tilgængelighed: Der kan være forskellig årsager til at driften bliver stoppet og her er beskrevet nogle af dem: 1. Problemer hos kunden. 2. Eksterne problemer. 3. Problemer pga. leverandøren(dette er den eneste som leverandøren har noget med at gøre). 4. For dårlig hardware. 18

23 3.7 L. Drift, support og vedligeholdelse. 3 KRAVSPECIFIKATION Krav til driftstid : Tilgængeligheden registreres af brugeren, hvis han oplever driftsproblemer Mellem kl 8 og kl 21 skal systemet have høj tilgængelighed På andre tidspunkter behøver tilgængeligheden ikke at være lige så høj Eksempel på løsning: En gang om måneden gøres den generelle tilgængelighed op I dette tidsrum skal systemet have en tilgængelighed på 98 procent I dette tidsrum skal systemet have en tilgængelighed på 90 procent L3. Datalagring: Da dataene for systemet fylder meget lidt, er der ikke de store krav til hvor mange datamængder systemet skal kunne kræve. Krav til datalagring : Systemet skal kunne tilgå data fra de sidste 20 år uden krav til hvor meget plads system skal kunne bruge Eksempel på løsning: L4. Support: Supporten er krav til hjælpeydelser, fx en hotline, overvågning af drift eller konfigurationsændringer. Krav til support : Eksempel på løsning: Leverandøren skal hjælpe brugeren med udstyr og den udleverede software I perioden mellem kl 8 og kl 21, skal I denne periode skal kunden kunne få telefonisk brugerne kunne ringe til leverandøren og få hjælp kontakt inden 30 minutter. Brugeren skal kunne få kontakt pr. mail med leverandøren og få hjælp Brugeren skal kunne få kontakt inden 12 timer. 19

24 3.8 Vurdering af SL07 3 KRAVSPECIFIKATION 3.8 Vurdering af SL07 I dette projekt bruger vi SL07 som skabelon til at definere vores kravspecifikation. Hvis man sammenligner SL07 med RUP-Requirement artifakten, som er den fremgangsmåde vores projekt sidste semester brugte, bruges SL07 kravspecifikationen som et kommunikationsmiddel mellem leverandør og kunde, hvor RUP fokuserer på en iterativ fremgangsmetode. RUP er specialdesignet til at understøtte agile udviklingsmodeller, mens SL07 er lavet til en vandfaldsmodel,hvor leverandør og kunde bliver enige om alt hvad progammet skal kunne, før de bliver enige om ordren. SL07 består af kravdele, defineret fra A til I: Kravdel: Indhold: B: Overordnede behov: C: Arbejdsopgaver systemet skal understøtte: D: Data systemet skal anvende: E: Andre funktionelle krav: F: Systemets integration med eksterne systemer: G: Tekniskt it-arkitektur: L: Drift, support og vedligehold: RUP-Requirement Artifacts består af disse kravdele: Kravdel: Indhold: 1: Use-Case Model: 2: Supplementary Specification: 3: Glossary: 4: Vision: 5: Business Rules: Overordnede behov i SL07 omhandler de samme ting som vision i RUP. Begge kravspecifikationer har et punkt der omhandler forskellige scenarier for brugere af systemet. Det er Use-Case Model i RUP og Arbejdsopgaver i SL07. Del D, der omhandler data som systemet skal anvende, er ikke repræsenteret i RUP. Senere under udvikling af softwaret i RUP skabes en domænemodel og deraf en E/R-model, men de hører ikke til i kravspecifikationsfasen. SL07 fastlåser sig til E/R-modellen allerede før udviklingen er gået igang, hvilket er en typisk fremgangsmåde for vandfaldsmodeller og meget dårligt understøtter iterative fremgangsmetoder. Del E, G og L, de ikke-funktionelle krav, omhandler det samme som Supplementary Specification i RUP. Del F, Systemets integration med eksterne systemer, svarer ingen dele til i RUP. I RUP kommer det først senere i udviklingen, da at fastlåse sig så tidligt i processe ikke vil passe godt i en iterativ udviklingsmodel. SL07 egner sig til at blive brugt, når en kunde og en leverandør skal forhandle sig til en kravspecifikation over en periode. Men til en iterativ udvikling med mange ændringer på relativt kort tid, passer den ikke godt, da den fastlåser sig på nogle vigtige og afgørende krav, som senere vil ændre sig. 20

25 4 DATAMODEL 4 Datamodel Denne sektion vil beskrive hvordan datamodellen opstår på baggrund af ER-modellen beskrevet i kravspecifikationen. Datamodellen tager udgangspunkt i implementationen af ER-modellen fra en konceptuel model til en specifik model, og beskriver i dette tilfælde helt konkret hvordan ER modellen transformeres til de C# objekter vores program vil gøre brug af. Datamodellen beskriver både primærnøglerne og attributernes typer. For forklaring på de specifikke attributter refereres til kravspecifikations punkt D omhandlende data programmet skal kunne anvende. Se datamodellen på næste side (figur 3). 4.1 Udvikling Som konsekvens af at være baseret på kravspecifikationen, har datamodellen været udsat for mange ændringer undervejs i projektet dvs. at den på ingen måde har været statisk. Der har været mange dynamiske ændringer, der ellers ville tage lang tid at ændre pga. den mængde testdata, der allerede har været tilstede i databasen fra starten. Det første udkast til datamodellen blev udarbejdet internt af gruppen i starten af semesteret. Webservicen blev senere udviklet på baggrund af denne. Under samarbejdet med Singapore, blev webservicens interface forhandlet og ekstra database tabeller tilføjet på baggrund af ønsker fra holdet i Singapore. I de sidste uger under udvikling af klientsoftwaren blev der yderligere introduceret nye database tabeller med henblik på, at tilføje ekstra funktionalitet i form af f.eks. flere gæster til et stay, lister over service typer samt roomstates. Det, der har ændret sig mest i projekt forløbet for datamodellen, er de tabeller, som optræder som bindeled mellem andre tabeller, f.eks. Additional Room. De eksisterer som løsninger til problemet, at kunne ændre relationers kardinalitet fra en-til-en til en-til-mange. 4.2 Kendte bugs Som konsekvens af udviklingen har databasen et par bugs, der ikke er blevet rettet. Den første stammer fra konceptet at et stay ikke kan oprettes uden en gæst og et rum. Vi tog ikke højde for programmets håndtering af et tomt stay og dets repræsentation i databasen. Det har påvirket flowet i programmet, så Stay vinduet ikke kan kaldes med et tomt stay. Den anden konsekvens er repræsentationen for opholdets dato ikke burde ligge i Stay som attribut, men burde udregnes som den samling af datoer opholdets værelser til sammen giver. 21

26 4.2 Kendte bugs 4 DATAMODEL Datamodel v String Address : String Id : Integer Name: String Location: String Name : String Landmark Stars : Integer 1 Hotel Phonenumber : String Information: String Id: Integer Url: String Room 1 Id : Integer Type : String Availability : Integer Id : Integer OnSeasonPrice : Integer RoomType Capacity : Integer RoomState AdditionalRoom OffSeasonPrice : Integer 1 PricingStrategy StartDate : Datetime StartDate : Datetime Id : Integer EndDate : Datetime Id : Integer Id : Integer EndDate : Datetime Address3 : String Address2 : String Address1 : String Additioal Guests 1 Id : Integer 1! Stay 1 Id : Integer NumberOfPersons : Integer State : Integer Phonenumber : String Guest 1 Date : Datetime Quantity : Integer Services Name : String 1 Name : String Id : Integer Identification : String Id : Integer ServiceType String Price : Integer Figur 3: Entity/Relationship diagram over dataen programmet skulle kunne anvende. 22

27 5 INTERFACE DESIGN ANALYSE 5 Interface Design Analyse I dette afsnit vil vi reflektere over design af vores interfaces. Vores program består af tre komponenter; en serverdel, en receptionistklient og en søgeagent (udviklet af studerende på SMU). Receptionistklinten samt søgeagenten forbinder begge til serverens interface. 5.1 Serveren Serveren består af en database og en webservice. Al information og data om hotellet, gæster, værelser med mere findes i databasen, og al tilgang til denne skal ske gennem vores webservice. Webservicen udstiller en række metoder til at hente, ændre eller lægge informationer i databasen. En del af metoderne er aftalt i samarbejde med SMU således at søgeagenten kan tilgå de relevante informationer som den skal bruge. Resten af metoderne er tilføjet til at understøtte de ekstra funktioner som receptionistsoftwaret tilbyder. 5.2 Søgeagent Planen var, at vores samarbejdsgruppe fra SMU skulle udvikle en søgeagent, der brugte vores webserviceinterface. Gennem Skype-konferencer og mail udveksling aftalte vi hvordan webserviceinterfacet skulle se ud, og vi baserede beslutningerne på kravene fra projektbeskrivelsen samt nogle ekstra funktionaliteter vi, eller SMU ønskede. Dette resulterede i følgende operationer: Funktion Beskrivelse CreateGuest Opretter en gæst i databasen BookRoom Booker et valgt værelse CancelBooking Annullerer en booking, men sletter den ikke fra databasen RoomSearch Søger på værelser der opfylder de indtastede søgekriterier RetrieveBooking Henter informationer om en booking HotelInformation Henter informationer om hotellet Landmark- Information Henter informationer om seværdigheder tæt på hotellet Desværre havde vores samarbejdsgruppe fra SMU ikke tid til at implementere deres søgeagent, så vi havde ikke mulighed for at teste hvorvidt dette interface var tilfredsstillende for en fungerende søgeagent. Dog har nogle af de andre grupper brugt vores webservice, idet vores WSDL ligger på wikien, så vi kan se, at nogle af metoderne virker. 23

28 5.3 Receptionistklienten 5 INTERFACE DESIGN ANALYSE 5.3 Receptionistklienten Receptionistklienten som vi har udviklet i 2. del af projektet bruger det samme webserviceinterface som søgeagenten. Udover de metoder implementeret til søgeagenten fik vi brug for at tilføje nogle ekstra metoder. Dette resulterede i, at webservicen nu har betydeligt flere metoder end da vi afsluttede samarbejdet med SMU. Figur 4 illustrerer hvordan de forskellige systemer hænger sammen. Interface oversigt Søgeagent brugere Søgeagenter Receptionistklient Webservice interface ITU server Figur 4: Interface overview 5.4 Sikkerhed Vi har ikke implementeret nogen sikkerhed på vores webservice. Dette betyder at alle og enhver i princippet kan benytte metoderne som vores webservice udstiller. Dette er ikke en god løsning da der findes personfølsomme oplysninger i databasen. Ligeledes ændrer flere af vores metoder på data. 5.5 Konklusion Vi har som ønsket implementeret en webservice med et interface, der fungerer med søgeagenter og en receptionistklient. Dette fungerer fint, men der er stadig nogle ting, vi gerne ville 24

29 5.5 Konklusion 5 INTERFACE DESIGN ANALYSE forbedre: Vores webservice har en masse metoder, hvor nogle af dem bruges af søgeagenter og klient, og andre kun bruges af klienten. Vi kunne godt tænke os at webservicen var delt op således, at der var en WSDL til søgeagenterne og en til klienten. Dette vil forhindre, at søgeagenterne kan bruge metoder der er beregnet til klienten. Vi ville ligeledes gerne implementere noget sikkerhed på vores webservice for at undgå eventuel misbrug. 25

30 6 KLIENT DESIGN 6 Klient Design 6.1 Overordnet systemarkitektur Hotelreceptionistsystemet er et meget databasecentreret system forstå et på den må de, at størstedelen af koden enten har til formå l at hente data ud fra databasen eller organisere og vise dataen i brugergrænsefladen. Det betyder, at domænelagets betydning bliver nedsat, da der ikke er behov for komplekse datastrukturer eller logiske udregninger. Da vi allerede har defineret typiske domæneklasser så som Guest, Room og Service i webservicen, kan vi genbruge disse, og domænelaget bliver dermed reduceret til få klasser, som bestå r af lister af "midlertidig"data, som venter på at blive sendt afsted til webservicen.pakke diagrammet på figur 5 nedenfor viser den overordnede systemarkitektur. Klienten består af to projekter, "ClientApp", som er vores hovedprojekt, og "ClientControls", der er lavet for at kunne bruge selvlavede user controls til "RoomView"i ClientApp. ClientApp består af 6 underpakker, Controller, Domain, Technical Services, View, Resources og Service References. Controllerklasserne står for interaktionen mellem view og domain, se afsnit 6.7. IStorage-interfacet bliver tilgået af flere klasser, da den sørger for kommunikationen til vores webservices. 26

31 6.1 Overordnet systemarkitektur 6 KLIENT DESIGN! "# $ % "!$ '" "(# " & () ( (+! & & "! & Figur 5: Pakkediagram for receptionistklient 27

32 6.2 GRASP 6 KLIENT DESIGN 6.2 GRASP I det følgende afsnit vil vi beskrive arkitekturen i vores klient, samt overvejelser til hvordan designet vil kunne forbedres. Vi har designet klasserne udfra de 9 GRASP principper: Information expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection og Protected Variations. Principperne går ud på, at hver enkelt k- lasse skal designes således at den får et klart defineret og afgrænset ansvarsområde. Samtidigt skal der være så lav kobling klasserne imellem at en ændring i en klasse ikke medfører at andre ikke længere virker. Vi har opnå et dette i vores program ved brug af flere design patterns: 6.3 Adapter For at gøre størstedelen af klasserne uafhængige af forbindelse til webservicen, har vi brugt et Adapter design pattern. Vi har lavet et adapter pattern ved at definere et interface IStorage som definerer alle mulige kald til webservicen. Klassen WebserviceAdapter implementerer IStorage og sørger for at sende kaldene videre til SoapAdapter som den har en instans af. Det smarte ved dette design er, at resten af systemet kun kender til IStorage interfacet og ikke til den konkrete implementation. På den må de kan man nemt udskifte hvordan vi kommunikerer med servicen, og evt. benytte andre former for datalagring (fx lokal database) uden at ændre i resten af systemet. Se figur 6 for illustration af vores adapter. <<interface>> IStorage +CreateGuest() +ModifyGuest() +SearchGuest() +GetGuest() +SearchRooms() +BookRoom() +CancelBooking() +GetBooking() +ModifyBooking() +CreateService() +ModifyService() +GetService() WebserviceAdapter - adaptee : SoapAdapter 1 SoapAdapter Figur 6: UML diagram af vores implementation af adapter pattern. Diverse metoder, metode-argumenter og nedarvede metodesignaturer er udeladt. 28

33 6.4 Factory 6 KLIENT DESIGN 6.4 Factory For at fordele ansvaret bedst muligt, har vi lavet ladet en StorageFactory stå for at returnere IStorage adapteren. Brugen af en factoryklasse har flere fordele: Man opretholder høj koherens ved at adskille evt. kompleks logik for oprettelsen af objekter, og samtidigt skjuler man den for klassen som skal bruge det skabte objekt. StorageFactory indeholder metoden GetStorageAdapter, som returnerer et objekt af typen IStorage, hvilken slags adapter det er, er så ledes op til StorageFactory at bestemme. 6.5 Singleton StorageFactory og de fleste af klasserne i vores domænelag er lavet til Singletons. Dette har vi gjort af 2 grunde: Mange af klasserne i domænelaget indeholder lister med data som skal tilgås fra forskellige forms, en singleton sørger for at vi kun instatierer klasserne een gang og dermed undgår inkonsistent data. Vi ønsker desuden også at kunne få fat på en instans af klasserne fra flere steder i systemet. Vi har implementeret singletons med lazy initialization. Vi definerer en statisk metode getinstance() i vores singleton klasse, som tjekker om der allerede findes en instans og returnerer den, ellers opretter den en ny. 6.6 Strategy Strategy giver mulighed for at vælge forskellige strategier til en given opgave. I vores program bruger vi strategy til at sortere i vores lister. Vi har lavet en række comparators der hver især implementerer ICompararer interfacet. Hver comparator står for at sortere objekter efter en bestemt parameter. Hvilket strategi der skal sorteres efter (altså hvilken comparator der skal bruges til sorteringen) bestemmes efter hvilken kolonne man trykker på i listen og idet alle comparators er af typen IComparer, kan de behandles ens. 6.7 Model View Controller MVC design pattern bruges til skabe lav kobling imellem domæne laget og vores Windows Forms. Det opnås ved at indsætte et led imellem GUI og domæne-laget i form af controller klasser. En controller er den første klasse som modtager og "kontrollerer"systemoperationer kaldt fra brugergrænsefladen. Den har så ansvaret for at bearbejde data, og delegere opgaven videre til domæne- og det tekniske lag. 29

34 6.8 Forbedringer 6 KLIENT DESIGN Form2 Events RoomWindowController RoomList Figur 7: Eksempel på brug af MVC design pattern i vores klientsystem Figur 7 viser et eksempel på flowet i udførelsen af en operation. Fra RoomView (GUI) bliver der kaldt ned i RoomWindowController, som delegerer operationenen videre til RoomList. Når operationen er udført, vil der blive affyret et event som RoomView har subscribet på, og RoomView vil derefter blive opdateret. I et MVC pattern kalder man kun metoder et lag ned ad gangen, men GUI komponenter kan subscribe på events i hvilket som helst lag. På den må de skabes der lav kobling ved, at gøre det nemt at udskifte GUI komponenter uden at det påvirker de underliggende lag. 6.8 Forbedringer Ved brug af foregående af design patterns har vi altså overholdt GRASP principperne, hvilket giver den fordel at man i fremtiden nemmere vil kunne udvide og forbedre koden. Ved at bruge adapter pattern til kommunikation med webservicen, giver det os fx. mulighed for en dag nemt at udskifte webservicen med en lokal database, uden det vil påvirke resten af system. Ved brug af MVC kan vi i fremtiden tilføje og ændrer Windows Forms uden at skulle ændre koden i domænelaget. Der er dog stadig mangler i koden, og plads til forbedringer. Listen af forbedringer som vi har diskuteret er som følger: Exception handling: En god må de at forbedre vores system på, ville være bedre hå ndtering af exceptions. En smart må de at forbedre sin kode på er, at definere sine egne exceptionklasser. Exceptions kastet af programmet kan konverteres til egne exception klasser og kastes videre, hvorefter det besluttes om brugeren skal gøres opmærksom på fejlen. Dette kan gøres ud fra NameTheProblemNotTheThrower princippet, hvor man navngiver exceptions udfra hvorfor de opstod. På den må de er det nemt at se hvad der forårsagede fejlen, hvis en funktion ikke virker ordenligt, hvilket er utroligt nyttigt til debugging. Command Pattern til kald af webservice: Som tidligere beskrevet har vi brugt MVC til adskillelse af brugergrænsefladen og resten af programmet. Istedet for MVC kunne vi implementere et Command Pattern. Command pattern fungerer således, at hver kommando fra brugergrænsefladen beskrives i en command klasse. Denne klasse indeholder alle informationer om funktioner, der skal køres, når en given kommando skal 30

35 6.9 F# kode 6 KLIENT DESIGN køres, f.eks. et museklik. Fordelen ved commandpattern er, at kommandoer bliver instantieres som objekter og således kan man udføre funktioner på dem som med alle andre objekter. F.eks. kan man tilføje dem til en liste og afvikle dem løbende. Dette kunne også gøres ved connection errors, hvor en gemt command kunne afvikles senere, hvis forbindelsen er nede. 6.9 F# kode F#-delen er den der udregner en eventuel rabat til prisen for et ophold på hotellet. Det er meningen at hotelbestyreren, eller en anden form for administrator, skal kunne sætte rabatten. Så kan programmet som receptionisten bruger, udregne rabatten automatisk, uden at receptionisten behøver at tænke over det. Man kan lave en klient til rabat-administratoren så han kan ændre i rabatten efter behov, eller lægge nogle forskellige rabatter op på en server, og lade receptionisten vælge den rabat der skulle bruges (eller en kombination af de to), eller man kan vælge at fastsætte rabatten ind i selve programmet Implementering Til selve rabatudregner-koden fik vi udleveret et skelet som vi skulle lave færdig og som vi bagefter kunne bygge videre på, hvis vi havde lyst. Vores rabatudregner-kode skal kunne samarbejde med hovedprogrammet der er skrevet i C#, da nogle af rabatudregner-funktionerne skal kunne hente noget information der kun er tilgængeligt i hovedprogrammet, men det er ikke helt ligetil. Til at starte med kalder hovedprogrammet ind i rabatudregneren, som er fra den udleverede kode. Men rabatudregneren kan ikke umiddelbart kalde tilbage til hovedprogrammet. Det kan gøres gennem en webservice, en callbackmetode eller man kan bruge tid på at finde en helt tredje metode. Vi valgte at nedpriotere muligheden for at en administrator skal kunne gå ind på en rabatklient og sætte en rabat eller at en receptionist skulle kunne vælge imellem flere rabatter der lå på en server. Så vi valgte at bruge ét sæt med rabatter skrevet i rabatudregnerkode og fastsat ind i vores program. Vi har ikke fundet det nødvendig at lave F#-koden i rabatudregneren meget anderledes end som det har været tænkt i den udleverede skeletkode. Dog har vi tilføjet et par ekstra funktioner, som der bliver kommet ind på. For ikke at spilde tid på "rabatudregner til hovedprogram-kommunikationen har vi ikke eksperimenteret med at bruge en webservice og har istedet valgt at implementere den udleverede løsning istedet. I vores rabatudregner-kode har vi lavet to ekstra funktioner, GUESTS() og SERVICEPRICE(). Vores rabatudregner-kode sørger for at udregne den totale pris og har derfor brug for prisen for alle de købte services, hvilket man får ved at kalde SERVICEPRICE(). En af de fastsatte rabatter afhænger af antallet af gæster, som man får ved at kalde GUESTS(). "Rabatudregner til hovedprogram-kommunikationen laves som i den udleverede løsning, hvor man i hovedprogrammet kalder ned i rabatudregneren med en reference til en callbackmetode der ligger i hovedprogrammet, så denne metode bliver kørt igennem når rabatudregner-koden bliver kørt. Denne callbackmetode tager desuden et objekt med informationer om værdierne fra rabatudregneren og den aktuelle funktion der bliver kørt i rabatudregneren. Det der sker er så at callbackmetoden i hovedprogrammet registrerer om den kender den aktuelle funktion, 31

36 6.9 F# kode 6 KLIENT DESIGN som så udføres Konklusion Vi har nu en rabatudregner skrevet i F#, der kan kommunikere frem og tilbage med hovedprogrammet. Det betyder at rabatudregneren kan få den information den skal bruge fra hovedprogrammet og outputte en totalpris tilbage til hovedprogrammet med en indregnet rabat. Så behøver en receptionist der bruger vores program, ikke at tænke over rabatter. Det ene sæt af rabatter vi bruger, er fastsat ind i programmet. Det er blevet gjort, da vi ikke har prioriteret en mere avanceret løsning særlig højt. 32

37 7 SERVER DESIGN 7 Server Design I dette afsnit vil vi se på design af vores webservice på serveren. Vi vil se på logisk design, såsom pakke og klasse diagram og diskutere mulige kode udvidelser. Vores serverdel skal understøtte en masse forskellige webservices og skal kunne benyttes af flere brugere ad gangen. Da al information som vores service skal returnere findes i databasen, skal vi bruge en nem metode til at hente og ændre information. Vi startede oprindeligt med at skrive SQL statements i strings men så blev vi opmærksomme på LINQ (Language Integrated Query). LINQ er en.net feature, som gør det muligt at håndtere database queries med eksempelvis C# kode. Udover nemt og hurtigt at kunne skrive queries i C# i stedet for SQL, har vi også mulighed for at indlæse hele vores database i.net miljøet ved at bruge en "LINQ to SQL Classes". På denne måde kan vi bare "drag & drop"tabeller fra vores database og over i denne klasse. Vi får så automatisk genereret klasser, der svarer til rækker i de forskellige tabeller. Da vi nu kan bruge C# kode til at håndtere eksempelvis collections fra rækker i databasen er det meget nemt, at manipulere dem og returnere hvad vi vil. Der er dog et problem ved de klasser som er oprettet automatisk og det er cirkulære referencer, således at hvis nu en booking har en gæst og et værelse, vil den returnere det hele i et objekt. Disse objekter der i princippet kan være næsten uendeligt store kan vi ikke sende over SOAP, så derfor har vi lavet vores egne klasser der repræsenterer disse, dog kun med de variable der er relevante. Vi overvejede at benytte tråde, men indså, at det ville skabe problemer mht. consistency i databasen. Så vi valgte bare at lade det hele køre som en tråd, da systemet er tilegnet at skulle bruges af et mindre antal brugere. Performance har været ganske fin trods flere samtidige webservice kald fra forskellige computere. Fejlhåndtering af webservices på serveren er lidt besværligt, da den jo primært bruges af klienten. Det er er ikke sådan lige at parse exceptions med disse webservice kald, så derfor valgte vi at gemme alle fejl i en log og returnere resultater, som ville kunne indikere at en fejl var opstået til klienten. Vi har desuden valgt at logge alle kald webservice kald med et timestamp når de er udført. 7.1 Design Patterns Pga. den måde vores webservice er opbygget på har vi ikke kunnet finde nogle relevante design patterns, som kunne implementeres på server siden. Da alle services returnerer vidt forskellige objekter kan vi ikke lavet noget samlet interface og da vores logning bare er en klasse, mener vi ikke det kan betale sig at bruge hverken factory eller singleton. Vi har dog nogle overvejelser over muligheder i afsnittet "kode udvidelser"længere nede. 7.2 Klasse Diagram Vores klasse diagram består af rigtig mange klasser, så for at bevare overskueligheden har vi udeladt metoder for Service klassen og variable i vores queries. Alle query klasser er re- 33

38 7.2 Klasse Diagram 7 SERVER DESIGN lateret til vores Service klasse, som udbyder alle webservices. Vores logning er også relateret til alle query klasser. De forskellige klasser som repræsenterer værelser, bookninger osv. er relateret til de services, hvor de benyttes. 34

39 7.2 Klasse Diagram 7 SERVER DESIGN FullBookingClass ModifyBookingDateQuery CreateBookingQuery CancelBookingQuery +Modify() : bool +Create() : int +Cancel() : bool ModifyBookingGuestQuery ModifyBookingStateQuery +Modify() : bool +Modify() : bool RetrieveBookingListQuery RetrieveStayQuery +Retrieve() : List<FullBookingClass> +Retrieve() : FullBookingClass QueryLogger Service DeleteGuestQuery +Delete() : bool ModifyGuestQuery AddAdditionalGuestQuery +Add() : bool DeleteAdditionalGuestQuery +Modify() : bool +Delete() : bool RetrieveAdditionalGuestQuery CreateGuestQuery +Retrieve() : List<GuestClass> +Create() : int RetrieveGuestQuery SearchGuestQuery +Retrieve() : GuestClass +Retrieve() : List<GuestClass> LandmarkQuery +Retrieve() : List<LandmarkClass> GuestClass LandmarkClass AddRoomToStayQuery CreateRoomStateQuery DeleteRoomFromStayQuery +Add() : bool +Delete() : bool +Create() : bool GetAllRoomsQuery GetRoomQuery +Retrieve() : List<RoomClass> +Retrieve() : RoomClass ModifyRoomStateQuery GetRoomStatesQuery RoomStateClass +Modify() : bool +Retrieve() : List<RoomStateClass> RetrieveRoomsFromStayQuery +Retrieve() : List<RoomClass> SearchRoomsQuery +Retrieve() : List<RoomClass> RoomClass CreateServiceQuery RetrieveServiceTypeQuery +Create() : bool +Retrieve() : List<ServiceTypeClass> ModifyServiceQuery RetrieveServiceQuery +Modify() : bool +Retrieve() : List<ServiceClass> DeleteServiceQuery HotelQuery +Delete() : bool +Retrieve() : HotelClass ServiceClass ServiceTypeClass HotelClass Figur 8: UML diagram af vores klasse opdeling på server siden. 35

40 7.3 Package Diagram 7 SERVER DESIGN 7.3 Package Diagram Pga. de mange forskellige webservices har vi valgt, at dele dem op efter typer. Vi har således samlet alle services der vedrører gæster i en "Guests"pakke og alle der har noget at gøre med bookninger i en "Booking"pakke. På denne måde har vi et godt overblik over de forskellige metoder og kan hurtigt lokalisere den service vi leder efter. De klasser vi har lavet til retur data fra webservicen er samlet i en pakke også, denne kunne også deles op efter forskellige typer, men da vi kun opererer med 8 forskellige fandt vi ikke dette nødvendigt. Som det kan ses på diagrammet benytter vores "Technical services"model pakken til at lave de objekter, der skal sendes tilbage gennem vores webservice. Vores webservice interface benytter "Technical service"laget til at udføre webservice kaldene. Service Webservice Interface Domain Model Database Technical services Guests Booking Service Rooms Misc Figur 9: UML diagram af vores pakkeopdeling på server siden. 36

41 7.4 Kode udvidelser 7 SERVER DESIGN 7.4 Kode udvidelser En oplagt kodeudvidelse er sikkerhed på webservicen, så det kun er dem som skal bruge den som har adgang. Som det er nu kan alle med en tilpasset klient få adgang til webservicen og benytte alle de forskellige services. Måden at gøre dette på er simpel, da vi benytter SOAP envelopes. Det er muligt at lave en såkaldt "security header", som bliver en del af den forespørgsel, der sendes til webservicen. Denne vil så indeholde et brugernavn samt password, som tjekkes op mod en brugerdatabase på serveren. På denne måde vil det også være muligt at identificere hvilke brugere, der benytter de forskellige services. Det ville være smart for at finde ud af hvem der eventuelt har lavet en fejl, da vi så ville kunne logge brugeren når en webservice bliver brugt. En anden udvidelse ville være at organisere vores services lidt mere. Dette kunne vi opnå ved at have forskellige "pure fabrication"klasser, som stod for de forskellige typer services. F.eks. kunne vi have en som håndterede alle gæste services og en der håndterede alle bookings. Disse kunne så være singletons, som var nemme og få fat på. Det ville gøre det meget nemmere at holde overblikket i forhold til nu. En tredje mulighed er at udvide vores logning, som lige nu kun understøtter logning til en tekst fil. Vi kunne benytte et adapter pattern, som udover tekst logning kunne supportere logning til database eller xml. En fjerde udvidelse ville være at tjekke op på alle parametre til vores webservicekald, således at der tjekkes for gyldig data. Det gør vi i et mindre omfang, men der er nogle services, der forventer gyldig inddata fra klienten. En sidste mulighed til at gøre webservicen mere overskuelig ville være i selve Service k- lassen, da denne fylder over 500 linjers kode, så den er meget svær at overskue. Vi er ikke helt sikre på hvordan man ville kunne delegere metoderne ud, men vi kunne forestille os, at man måske lavede nogle partielle klasser og delte services op efter type. Der er altså mange ting som der ville kunne forbedres på vores webservice i fremtiden. 37

42 8 DESIGN AF BRUGERGRÆNSEFLADE 8 Design af brugergrænseflade Receptionistsystemets GUI er den brugergrænseflade som receptionisten skal bruge hver dag til at køre hotellet. Det er derfor vigtigt for receptionistens daglige arbejde, at systemet nemt og effektivt understøtter de opgaver som opstår i løbet af arbejdsdagen. Brugergrænsefladen skal derfor være intuitiv at bruge, i form af oversigter over ledige værelser og gæster som bor på hotellet. Med det i tanke, har vi designet vores brugergrænseflade ved at kigge på vores arbejdsopgaver fra kravspecifikationen (se afsnit 3), og diskuteret hvad der skulle med i hvert vindue for at opgaven kunne løses. Vi endte med at udarbejde prototyper til 3 hovedvinduer, som vi har implementeret i vores system. Vi har valgt at dele systemet op i tre hovedvinduer med hver sit arbejdsområde: gæstevindue, reservationsvindue og værelsesvindue. Ideen bag dette er at reducere mængden af redundant data i vinduerne ved udførelse af forskellige arbejdsopgaver. Det er f.eks. ikke nødvendigt at vise alle informationer om en gæsts reservation, hvis blot man ønsker at ændre hans personlige data. Dette hjælper til at fokusere arbejdsopgaven, og mindske forvirring hos receptionisten. 38

43 8 DESIGN AF BRUGERGRÆNSEFLADE Figur 10: Gæstevindue Gæstevinduet på (Figur 10) er det vindue som receptionisten ser når systemet starter. Herfra kan man søge på en gæst udfra reservations nr., navn, tlf. nr. osv. Hvis gæsten har booket på forhånd, kan man gå ind på reservation ved at trykke Show, ellers kan man oprette en ny på Create new. Vælger man Show vil reservationsvinduet dukke op. Al data er stillet overskueligt op i lister. 39

44 8 DESIGN AF BRUGERGRÆNSEFLADE Figur 11: Vindue hvorfra man reservere værelser I reservationsvinduet er alle informationerne om en reservation ligeledes vist overskueligt i lister. Herfra kan man se og tilføje gæster, services og værelser til hver reservation. I reservationsvinduet kan man udføre check-in, check-out og annulering af en gæsts reservation. Det var vigtigt for os, at give brugeren af systemet det bedst mulige overblik til at foretage reservationer. I vores bookingvindue har vi lavet en gitteroversigt som spænder over datoer på tværs og værelser nedad (se figur 11). Systemet er sat til at vise 14 dage frem som standard, start datoen kan sættes i søgefeltet. Gitteret viser en oversigt over ledige værelser, farvet i grønt, og optagede værelser i rødt. Man kan reservere et værelse på to må der; enten ved at markere værelser i oversigten med musen, eller udfylde felterne i booking feltet. Man tilføjer et værelse til reservationen ved at trykke Book. Vi har også valgt at lave en grafisk oversigt over værelserne. En grafisk oversigt over værelserne giver et anderledes overblik, og gør f.eks. en receptionistvikar i stand til at imødekomme ønsker såsom at værelserne skal ligge på samme etage, eller ved siden af hinanden. Denne oversigt viser ligeledes ledige værelser i grønt for de søgte datoer (se figur 12 ). For at gemme reservationen trykkes Save, hvis gæsten endnu ikke er oprettet i systemet vil man blive bedt om at udfylde informationer om gæsten. Figur 12: Værelsesoversigt En test af brugervenligheden af vores receptionistsystem kan ses i afsnit

45 9 TEST 9 Test 9.1 Indledning: Testning af software er en meget vigtig del af softwareudvikling, og vi har derfor fokuseret meget på dette. På vores wiki side findes omfattende test-information om de services vi brugte i SMU samarbejdet. Vi lavede bl.a. et testprogram til at verificere resultaterne, samt unittesting af de vigtige klasser. I vores klient del har vi lagt vægt på brugervenlighedstests samt performance tests. Vi har også benyttet black box testning for alle vores arbejdsopgaver defineret i krav specifikationen. På server siden har vi udvidet vores unittestning for de vigtigste services. Vi har benyttet testdata, som er baseret på virkelige lignende gæster. 9.2 Usability test Formål Den mest effektive måde at finde problemer med brugervenligheden på er ved at udføre en usability test. Ved at få en testperson, som ikke kender systemet, til at udføre en række receptionistopgaver kan man observere om brugegrænsefladen er intuitiv og nem at bruge. Vores testperson, Christian Højgaard, har erfaring med IT og andre receptionistsystemer, hvilket ikke er en bruger i vores målgruppe Arbejdsopgaver Opgaverne som testpersonen skal udføre er typiske arbejdsopgaver for en receptionist. Opgaverne er derfor også udformet som virkeligshedstro situationer, og med så lidt skjult hjælp som muligt. Arbejdsopgave 1: John Simpson ringer og spørger om der er 2 ledige dobbeltværelser fra d. 20/5-09 til og med den 29/5-09. Hvis det er tilfældet, ønsker John at reservere værelserne, de er 2 personer i hver. Arbejdsopgave 2: John Simpson ringer og vil afbestille den reservation han har foretaget sig dagen før til næste uge. Arbejdsopgave 3: John Simpson ankommer til hotellet og ønsker at checke ind. De er 4 i alt, som alle skal registreres i systemet. Arbejdsopgave 4: John Simpson ringer til receptionen fra værelset og vil bestille morgenmad til hans og vennernes værelse. Arbejdsopgave 5: John Simpson ønsker at forlænge sit ophold med 3 dage Resultater De observerede problemer under testen, opdeles efterfølgende 6 kategorier: 41

46 9.2 Usability test 9 TEST Missing functionality Opgaven er ikke mulig at udføre pga. manglende implementation. Task failure Brugeren kan ikke selv udføre opgaven, eller tror fejlagtigt at opgaven er blevet udført. Annoying Brugeren synes systemet er ulogisk eller besværligt at bruge, eller bruger ikke systemet korrekt. Medium problem Brugeren løser opgaven efter at have forsøgt i lang tid. Minor problem Bruger løser opgaven efter et par forsøg. Set-up error Problemer med opsætning af testen. Arbejdsopgaver blev udført som en think-aloud test af en sen, fuldt funktionel version af systemet. Følgende problemer blev observeret og rapporteret under testen: P1: (Minor) I search: Create new for at få et overblik over ledige værelser er ikke intuitivt. Blev valgt efter Show. P2: (Task failure) Ved booking: Man kan markere flere rækker (værelser) med markøren, det er ikke tydeligt for brugeren at kun det øverste værelse registreres. P3: (Task failure) Ved booking: Tvivl om hvor mange gange der skal trykkes Book for at booke begge værelser. P4: (Annoying) Ved booking: Tvivl om der er valgt rigtige datoer for værelser, da det ikke fremgår af listen over værelser der skal bookes. P5: (Minor) Create new guest: Tvivl om hvorvidt Identification skal udfyldes hvis fx reservation udføres over telefon. P6: (Medium) Af oversigten over reservation fremgår det at samme værelse blev reserveret 2 gange til samme datoer. P7: (Annoying) I reservation: Tvivl om hvilke datoer hvilke værelser er reserveret til. P8: (Minor) I reservation: Uklart om dette vindue skal lukkes ned efter endt reservation. P9: (Minor) I search: Forvirring omkring 2 forskellige former for ID i de forskellige lister (den ene er gæstens ID, den anden er reservationens). P10: (Minor) I reservation: Ikke tydeligt om Cancel annullerer reservationer, bliver dog bekræftet hvis man trykker. P11: (Task failure) I reservation: Det er ikke muligt at forlænge en reservation, selvom brugergrænsefladen umiddelbart tillader brugeren at gøre det. Forlængelsen som brugeren tror han udfører, bliver ikke registreret i databasen korrekt. 42

47 9.3 UnitTests: 9 TEST Problemer markeret som task failure er de mest kritiske, da brugeren fejlagtigt tror at opgaven er udført. P2, P3 og P11 er alle problemer som vil påvirke hotelgæsten direkte, og givetvis besværligøre receptionistens daglige arbejde når en gæst dukker op med en reservation som er registreret forkert i databasen. Disse problemer skal derfor have højest proritet når der skal rettes fejl. Andre mindre kritiske fejl som fx. P1 og P5, vil typisk kunne rettes ved en mindre omarrangerering af brugergrænsefladen, og bør derfor også tages i betragtning til næste revision af systemet. 9.3 UnitTests: Da vi har 33 webservices har vi valgt ikke at unitteste dem alle. Vi har hovedsageligt u- nittestet gæste og booking services, da de er de vigtigste i programmet: CreateGuest DeleteGuest ModifyGuest RetrieveGuest SearchGuests CreateBooking CancelBooking ModifyBookingGuest RetrieveBooking SearchRooms Unittests er lokaliseret som projektet UnitTesting i solutionen Hotel1, som også indeholder hele vores webservice. Figur 13: Screenshot af unittests Alle vores tests er fuldført med succes. 43

Skriftlig opgave. Designtanker i database-nære systemer

Skriftlig opgave. Designtanker i database-nære systemer Skriftlig opgave til eksamen for faget»databaser«designtanker i database-nære systemer Martin Ancher Holm Juni 2010 1 Intro Denne skriftlige opgave indeholder kort de daglige tanker jeg har omkring design

Læs mere

Dygtig.NET / C# udvikler med stor erfaring fra både offentlige organisationer og private virksomheder.

Dygtig.NET / C# udvikler med stor erfaring fra både offentlige organisationer og private virksomheder. .NET UDVIKLER NATIONALITET: DANSK PROFIL Dygtig.NET / C# udvikler med stor erfaring fra både offentlige organisationer og private virksomheder. Stor erfaring omkring databasedesign, datahåndtering og MS

Læs mere

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014 2014 Tidsregistrering Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4 Informationsteknologi B Roskilde Tekniske Gymnasium 25-11-2014 Indholdsfortegnelse 1 Indledning... 3 2 User stories... 3 3

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

Database for udviklere. Jan Lund Madsen PBS10107

Database for udviklere. Jan Lund Madsen PBS10107 Database for udviklere Jan Lund Madsen PBS10107 Indhold LINQ... 3 LINQ to SQL og Arkitektur... 3 O/R designere... 5 LINQ Den store introduktion med.net 3.5 er uden tvivl LINQ(udtales link): Language-INtegrated

Læs mere

Accepttest Specifikation For. Gruppen

Accepttest Specifikation For. Gruppen Accepttest Specifikation For Gruppen Indholdsfortegnelse 1. INDLEDNING...3 1.1 FORMÅL...3 1.2 REFERENCER...3 1.3 TESTENS OMFANG OG BEGRÆNSNINGER...3 2. TESTEMNER...3 2.1 CENTRAL ENHEDEN...3 2.2 ADGANGS

Læs mere

DOtAB. Teknisk rapport

DOtAB. Teknisk rapport DOtAB Teknisk rapport Indholdsfortegnelse Introduktion... 1 Systemarkitektur... 1 Teknologier... 1 Platforme for mobile enheder... 1 Kommunikations interfacet... 2 Udviklingsmiljø... 2 IDOtAB (service

Læs mere

Software Projekt NoSQL vs RMDB

Software Projekt NoSQL vs RMDB Software Projekt NoSQL vs RMDB Skrevet af Carsten Sørensen, Hans Jørgen Frandsen, Peter Haislund Department of Computer Science, University of Aarhus Aabogade 34, 8200 Arhus N, Denmark 201200089, 19960442,

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

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

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN 1/20 Indledning Dette projekt er den afsluttende del af webudvikling-studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med

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

Indholdsfortegnelse for kapitel 1

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

Læs mere

Installation af Oracle 10g Release 2 database

Installation af Oracle 10g Release 2 database Installation af Oracle 10g Release 2 database Oracle 10g database indeholder databasesoftware, enterprise manager, SQL*Plus m.m., HTML DB (i dag kendt som Application Express) og tilhørende HTTP Server

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

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

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Rollebaseret. Side 1 Copyright: Naddon version 201009

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Rollebaseret. Side 1 Copyright: Naddon version 201009 Markedsinfo Microsoft Dynamics NAV 2009 SP1 Rollebaseret Side 1 Microsoft Dynamics NAV 2009 SP1 Rollebaseret Indholdet i dette dokument må på ingen måde gengives helt eller delvist hverken på tryk eller

Læs mere

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4 Maskine Udlejning 15. oktober 2010 Jacob Weng, Jeppe Boese og Mads Anthony Roskilde Tekniske Gymnasium Udlejningsvirksomhed 3.4 Indholdsfortegnelse Problemformulering:... 2 Planlægning:... 2 Analyse af

Læs mere

Svendeprøve Projekt Tyveri alarm

Svendeprøve Projekt Tyveri alarm Svendeprøve Projekt Tyveri alarm Påbegyndt.: 8/2-1999 Afleveret.: 4/3-1999 Projektet er lavet af.: Kasper Kirkeby Brian Andersen Thomas Bojer Nielsen Søren Vang Jørgensen Indholds fortegnelse 1. INDLEDNING...3

Læs mere

3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015

3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015 PROJECT DATABASE 3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015 Ved at underskrive dette dokument bekræfter vi, at det indsendte materiale alt sammen er vores eget materiale og arbejde. Andreas

Læs mere

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1 Copyright: Naddon version 201009

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1 Copyright: Naddon version 201009 Markedsinfo Microsoft Dynamics NAV 2009 SP1 Klassisk Side 1 Microsoft Dynamics NAV 2009 SP1 Rollebaseret Indholdet i dette dokument må på ingen måde gengives helt eller delvist hverken på tryk eller i

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

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Introduktion. Pacsoft Online 11-11-2013

Introduktion. Pacsoft Online 11-11-2013 Introduktion Pacsoft Online 11-11-2013 2 Indhold 1 Introduktion til Pacsoft Online... 3 1.1 Grundlæggende navigering... 3 1.2 Søgning af information... 3 1.3 Indtastning af faste oplysninger... 4 1.4 Din

Læs mere

Profilhåndtering. Unifaun Online 2014-05-07

Profilhåndtering. Unifaun Online 2014-05-07 Profilhåndtering Unifaun Online 2014-05-07 2 Indhold 1 Profilhåndtering... 3 2 Centrale begreber i Profilhåndtering... 4 3 Administratoren... 6 4 Et eksempel - Blomster A/S... 7 5 Sådan opsættes profilhåndtering

Læs mere

Eksamen, DSDS, efterår 2008

Eksamen, DSDS, efterår 2008 Eksamen, DSDS, efterår 2008 Introduktion til Scripting, Databaser og Systemarkitektur Jonas Holbech IT Universitetet i København 6. januar 2009 Alle hjælpemidler er tilladte, dog ikke computer og kommunikationsmidler.

Læs mere

! Kia Dahlen. Kamilla Klein, Pia Jensen og Maria Korshøj Andersen.

! Kia Dahlen. Kamilla Klein, Pia Jensen og Maria Korshøj Andersen. Copenhagen Business Academy Multimediedesigner 3. semester - 1. projekt, september 2014 Gruppe 1 - MulA Kia Dahlen. Kamilla Klein, Pia Jensen og Maria Korshøj Andersen. Study: Multimedia Design Project:

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

Booking+ Brugervejledning

Booking+ Brugervejledning Booking+ Brugervejledning Booking+ er et webbaseret, brugervenligt lokaleadministrations- og mødebookingsystem, der kan håndtere lokalereservationer fra forskellige lejere og brugere af fælles mødelokaler,

Læs mere

Kom godt igang med Inventar registrering

Kom godt igang med Inventar registrering Kom godt igang med Inventar registrering (InventoryDB) (Med stregkodesupport) programmet fra PetriSoft Introduktion... 1 Inventar registrering... 2 Værktøjsudleje... 3 Service database til reperationer

Læs mere

Casper Fabricius http://casperfabricius.com. ActiveRecord. O/RM i Ruby on Rails

Casper Fabricius http://casperfabricius.com. ActiveRecord. O/RM i Ruby on Rails Casper Fabricius http://casperfabricius.com ActiveRecord O/RM i Ruby on Rails Casper Fabricius Freelance webudvikler - casperfabricius.com 9 års erfaring med webudvikling 6 år med ASP/ASP.NET/C# 3 år med

Læs mere

BAAN IVc. Brugervejledning til BAAN Data Navigator

BAAN IVc. Brugervejledning til BAAN Data Navigator BAAN IVc Brugervejledning til BAAN Data Navigator En udgivelse af: Baan Development B.V. P.O.Box 143 3770 AC Barneveld Holland Trykt i Holland Baan Development B.V. 1997. Alle rettigheder forbeholdes.

Læs mere

Data lagring. 2. iteration (implement backend)

Data lagring. 2. iteration (implement backend) Data lagring 2. iteration (implement backend) Emner Grundlæggende database begreber. Data definitionskommandoer ER-diagrammer og cardinalitet/relationer mellem tabeller Redundant data og Normalisering

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

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

EVALUERING I SURVEYXACT TRIN FOR TRIN

EVALUERING I SURVEYXACT TRIN FOR TRIN EVALUERING I SURVEYXACT TRIN FOR TRIN LÆR AT TACKLE 2015 KOMITEEN FOR SUNDHEDSOPLYSNING 1 INDLEDNING Komiteen for Sundhedsoplysning stiller SurveyXact et internetbaseret redskab til kvalitetssikring til

Læs mere

DD110 - Detaljeret projektplan

DD110 - Detaljeret projektplan Version: 1.3 Status: Godkendt Godkender: Dokumenthistorik Version Dato Navn Status Bemærkninger 1.0 9-11-2007 Endelig Initiel version 1.1 22-11-2007 Godkendt 1.2 28-11-2007

Læs mere

Databaseadgang fra Java

Databaseadgang fra Java Databaseadgang fra Java Grundlæggende Programmering med Projekt Peter Sestoft Fredag 2007-11-23 Relationsdatabasesystemer Der er mange databaseservere Microsoft Access del af Microsoft Office MySQL god,

Læs mere

PHP 3 UGERS FORLØB PHP, MYSQL & SQL

PHP 3 UGERS FORLØB PHP, MYSQL & SQL PHP 3 UGERS FORLØB PHP, MYSQL & SQL Uge 1 & 2 Det basale: Det primære mål efter uge 1 og 2, er at få forståelse for hvordan AMP miljøet fungerer i praksis, og hvordan man bruger PHP kodesproget til at

Læs mere

Bookingsystem til hoteller. JTA-Data Jylland JTA. Vinkelvej 108a 8800 Viborg Tlf. 86672024 www.jta-data.dk DATA. Jylland

Bookingsystem til hoteller. JTA-Data Jylland JTA. Vinkelvej 108a 8800 Viborg Tlf. 86672024 www.jta-data.dk DATA. Jylland Bookingsystem til hoteller -Data: C5 bookingsystem til hoteller Indhold 1. Daglig brug af bookingsystemet. 2. Ny booking et værelse 3. Ny booking flere værelser 4. Ankomst 5. Rengøring 6. Afrejse 7. Værelsesoversigt

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

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

Bilag 1. Kravspecifikation Annoncering af e-rekruttering som servicebureauløsning

Bilag 1. Kravspecifikation Annoncering af e-rekruttering som servicebureauløsning Click here to enter text. Koncernløsning udbud - Udbudsbetingelser «edocaddresscivilcode» Bilag 1. Kravspecifikation Annoncering af e-rekruttering som servicebureauløsning Aalborg Kommune rekrutterer til

Læs mere

Object-Relational Mapping

Object-Relational Mapping Databaser for udviklere () Datamatiker TietgenSkolen Underviser: Allan Helboe 06-06-2010 Problemformulering Denne opgave er et forsøg på at beskrive problemerne der opstår ved anvendelsen af en relationel

Læs mere

Kravspecification IdP løsning

Kravspecification IdP løsning Kravspecification IdP løsning Resume IT-Forsyningen, som varetager IT-drift for Ballerup, Egedal og Furesø Kommuner, ønsker at anskaffe en IdP/Føderationsserverløsning, der kan understøtte en række forretningsmæssige

Læs mere

Database "opbygning"

Database opbygning Database "opbygning" Dette områder falder mest under en DBA's ansvarsområde. Det kan sagtens tænkes at en database udvikler i nogle situationer vil blive nød til at oprette produktions og test) databaser,

Læs mere

Sporbarhed og Rapportering i Quality Center. Kim Stenbo Nielsen NNIT Application Management Services

Sporbarhed og Rapportering i Quality Center. Kim Stenbo Nielsen NNIT Application Management Services Sporbarhed og Rapportering i Quality Center Kim Stenbo Nielsen NNIT Application Management Services Indhold INTRODUKTION Hvem er jeg Hvad vil jeg fortælle om QC std. rapporteringsfaciliteter EXCEL RAPPORTER

Læs mere

Én IT løsning, mange fordele AX TRAVEL. - fremtidens rejsebureauløsning

Én IT løsning, mange fordele AX TRAVEL. - fremtidens rejsebureauløsning Én IT løsning, mange fordele - fremtidens rejsebureauløsning Privatejet virksomhed Etableret i 1987 100 % danskejet Hovedkontor i Allerød og kontor i Århus +80 medarbejdere Solid og positiv økonomi gennem

Læs mere

Umbraco installationsvejledning

Umbraco installationsvejledning på et ScanNet ASP Webhotel Indledning Beskrivelse Denne vejledning vil indeholde installation af CMS systemet Umbraco på et ASP Webhotel. Det dansk grundlagt Content Management System (CMS) Umbraco er

Læs mere

SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW 1. - SUPERBRUGERE OG MEDLEMMER AF RETTIGHEDSGRUPPER -

SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW 1. - SUPERBRUGERE OG MEDLEMMER AF RETTIGHEDSGRUPPER - SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW 1. - SUPERBRUGERE OG MEDLEMMER AF RETTIGHEDSGRUPPER - INTRODUKTION TIL SKOLERNES DIGITALE BLANKET FLOW Vi er glade for at kunne byde velkommen til opdateret

Læs mere

WWW. Forslag til integreret digitalt værk ved Det Informationsvidenskabelige Akademi på KUA3 Udarbejdet af Jacob Nielsen 2013

WWW. Forslag til integreret digitalt værk ved Det Informationsvidenskabelige Akademi på KUA3 Udarbejdet af Jacob Nielsen 2013 WWW Forslag til integreret digitalt værk ved Det Informationsvidenskabelige Akademi på KUA3 Udarbejdet af Jacob Nielsen 2013 Arbejdstitel: "Internet på hovedet" Projektet tager udgangspunkt i det formelt

Læs mere

FKO Quick Guide. Kom godt igang med FKO Temperaturmåling

FKO Quick Guide. Kom godt igang med FKO Temperaturmåling FKO Quick Guide Kom godt igang med FKO Temperaturmåling FKO GUIDE Temperaturmåling Publikationen er udgivet af Socialstyrelsen Edisonsvej 18, 1. 5000 Odense C Tlf: 72 42 37 00 www.socialstyrelsen.dk Udgivet

Læs mere

Automatisk Vandingssystem. Rettelser. 1 af 11

Automatisk Vandingssystem. Rettelser. 1 af 11 Automatisk Vandingssystem Rettelser 1 af 11 Automatisk Vandingssystem Projektrapporten Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård Hansen

Læs mere

XML webservice for pensionsordninger. Version 1.0 Draft A

XML webservice for pensionsordninger. Version 1.0 Draft A XML webservice for pensionsordninger Version 1.0 Draft A Dokumentoplysninger Titel: Projekt: Webservice for pensionsordninger EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til

Læs mere

Forbedringer i NS 5.3 08.03.2012

Forbedringer i NS 5.3 08.03.2012 Introduktion og formål med dette dokument Moderniseringsstyrelsen har pr. 10. januar 2012 frigivet obligatorisk servicepack, Navision Stat 5.3 med tilhørende systeminfo og vejledninger. Dette skriv er

Læs mere

Bilag 1A. Kravspecifikation: Intranet til Danmarks Domstole. Indledning. Struktur

Bilag 1A. Kravspecifikation: Intranet til Danmarks Domstole. Indledning. Struktur Bilag 1A Kravspecifikation: Intranet til Danmarks Domstole Indledning Det bemærkes indledningsvis, at tilbudsgiveren skal tilbyde at opfylde samtlige af de nævnte krav, der er angivet at være mindstekrav,

Læs mere

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning Rollebeskrivelser i den fællesstatslige programmodel - Vejledning August 2013 Indhold 1. LÆSEVEJLEDNING... 1 2. FORMAND FOR PROGRAMBESTYRELSEN (PROGRAMEJER)... 2 3. PROGRAMLEDER... 3 4. FORANDRINGSEJER...

Læs mere

EasyIQ ConnectAnywhere Release note

EasyIQ ConnectAnywhere Release note EasyIQ ConnectAnywhere Release note Version 2.4 Der er over det sidste år lavet en lang række forbedringer, tiltag og fejlrettelser. Ændringer til forudsætningerne: o Klienten skal ved førstegangs login

Læs mere

Kontraktbilag 4 Kundens IT-miljø

Kontraktbilag 4 Kundens IT-miljø Kontraktbilag 4 Kundens IT-miljø [Vejledning til Leverandøren i forbindelse med afgivelse af tilbud Dette bilag indeholder Kundens krav til at systemet skal kunne afvikles i nedenstående IT-miljø. Leverandøren

Læs mere

Pronestor Room. Modul 4. At bruge Pronestor Room Side 4.0 4.8. Booker / Sekretær Mine indstillinger Side 4.4

Pronestor Room. Modul 4. At bruge Pronestor Room Side 4.0 4.8. Booker / Sekretær Mine indstillinger Side 4.4 Modul 4 At bruge Pronestor Room Side 4.0 4.8 Facility manager / Administrator Bookings (Facility manager) Side 4.1 o Opret møder og bookinger o Redigér møder o Lås møder o Ordresøgning og historik o Rapporter

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

Kort om CoinDB (Mønt- og seddelsamling):

Kort om CoinDB (Mønt- og seddelsamling): Kom godt i gang med CoinDB programmet fra PetriSoft (Holder styr på din Mønt- seddel- eller frimærkesamling) Kort om CoinDB (Mønt- og seddelsamling): CoinDB er et Windows program, der anvendes af mønt-

Læs mere

APEX i Praksis Martin B. Nielsen. Navn. MBNDATA Emne

APEX i Praksis Martin B. Nielsen. Navn. MBNDATA Emne APEX i Praksis Martin B. Nielsen Navn MBNDATA Emne Foredragsholderen Oracle/APEX Arkitekt/udvikler/DBA Siden Oracle v.5 (1988) APEX Siden 2007, men før (Database provider, HTMLDB) MBNDATA siden 1996 MBNDATA

Læs mere

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5 Databaser og SQL Introduktion til SQL Kap 1-5 1 Dagens gang Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang 2 Databasebegreber A database is a:

Læs mere

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING 2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING Baggrund Udgangspunktet er projekt 2, dvs. en blog om cupcakes, hvor målgruppe, afsender og modtager allerede er defineret. Du bliver nu bedt om at udvikle et

Læs mere

Pronestor Room & Catering

Pronestor Room & Catering Pronestor Room & Catering Modul 2 Installation af tilkøbsmoduler Side 2.0 2.9 Bruger Import (AD integration) Side 2.1 2.4 o Service Accounts (hosted og on-premises) o Active Directory struktur o Installation

Læs mere

Trimble Access Service (Sync)

Trimble Access Service (Sync) Vejledning i opsætning af Trimble AccessSync Trimble har ved Dimensions November 2012 ændret deres forretningsmodel med hensyn til deres AccessSync funktionalitet. Tidligere har det krævet et særskilt

Læs mere

DATABASE Projekt 1-3. semester

DATABASE Projekt 1-3. semester DATABASE Projekt 1-3. semester Gruppe 2- CLmul-a12e Projekt URL http://www.lucasperch.dk/projekter/database.pdf Gruppe 2 Lucas Perch-Nielsen cph-lp14@cphbusiness.dk http://lucasperch.dk/skole.php Niclas

Læs mere

Indstillinger. 1. Built-in viewer 2. Built-in viewer embedded 3. Ekstern viewer

Indstillinger. 1. Built-in viewer 2. Built-in viewer embedded 3. Ekstern viewer TeXMaker guide TeXMaker er den editor, som vi anbefaler til at skrive LaTeX i. Det er en såkaldt cross-platform editor og kan benyttes til både Windows, Mac og Linux. TeXMaker er en ret almindelig editor

Læs mere

Digital skriftlig aflevering med Lectio Censormodul Stedprøver installationsvejledning

Digital skriftlig aflevering med Lectio Censormodul Stedprøver installationsvejledning Digital skriftlig aflevering med Lectio Censormodul Stedprøver installationsvejledning 1. Lokalt installeret afleveringsprogram til stedprøver... 2 2. Systemkrav... 3 3. Netværksopsætning... 4 4. Installation

Læs mere

Object-Relational Mapping

Object-Relational Mapping Object-Relational Mapping Skriftligt arbejde i forbindelse med eksamen i Databaser for udviklere Studerende: Henrik Rossen Jakobsen Vejleder: Allan Helboe 07-06-2010 Indhold Indledning... 2 Problemformulering...

Læs mere

Internet Information Services (IIS)

Internet Information Services (IIS) Internet Information Services (IIS) Casper Simonsen & Yulia Sadovskaya H1we080113 06-11-2013 Indholdsfortegnelse Problemformulering... 2 Hvorfor:... 2 Hvad:... 2 Hvordan:... 2 Problembehandling... 3 Introduktion...

Læs mere

Systemudvikling og projektorganisering, Bachelor i softwareudvikling, IT-Universitetet Hotel system

Systemudvikling og projektorganisering, Bachelor i softwareudvikling, IT-Universitetet Hotel system Systemudvikling og projektorganisering, Bachelor i softwareudvikling, IT-Universitetet Hotel system Morten Esbensen - 08-04-1984 - [mortenq@itu.dk] Nikolas Bang Manscher - 02-06-1987 - [nmanscher@itu.dk]

Læs mere

FairSSL Fair priser fair support

FairSSL Fair priser fair support Microsoft IIS 6 Certifikat administration Følgende vejledning beskriver hvordan man installere et certifikat på en IIS 6 For support og hjælp til anvendelsen af denne vejledning kan du kontakte FairSSL

Læs mere

Nets - Medarbejder Signatur

Nets - Medarbejder Signatur Nets - Medarbejder Signatur Nets Direkte Kommunikation Nøgle Bestilling Version: 2.1, Oktober 2013 Continia Software a/s Hjulmagervej 55 DK-9000 Aalborg Denmark Tel. +45 82 30 50 00 Support mail: cm@continia.dk

Læs mere

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling Java og JEE 1 2 Udfordringer og problemstillinger En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling 3 Generelt om Java og JEE 4 Generelt, I Man undervurderer hvor mange

Læs mere

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning Rollebeskrivelser i den fællesstatslige programmodel - Vejledning Januar 2014 Indhold 1. LÆSEVEJLEDNING... 1 2. FORMAND FOR PROGRAMBESTYRELSEN (PROGRAMEJER)... 2 3. PROGRAMLEDER... 3 4. FORANDRINGSEJER...

Læs mere

Indhold Opstartsprocedure... 3 Dankort... 3 Korrekt åbningsprocedure af dankortterminalen... 4 Korrekt lukkeprocedure af dankortterminalen...

Indhold Opstartsprocedure... 3 Dankort... 3 Korrekt åbningsprocedure af dankortterminalen... 4 Korrekt lukkeprocedure af dankortterminalen... Quickguide Indhold Opstartsprocedure... 3 Dankort... 3 Korrekt åbningsprocedure af dankortterminalen... 4 Korrekt lukkeprocedure af dankortterminalen... 4 Logon på Dynamics NAV... 4 Overblik over Dynamics

Læs mere

MapInfo Professional v11.0 & v11.0.3 Februar 2012

MapInfo Professional v11.0 & v11.0.3 Februar 2012 MapInfo Professional v11.0 & v11.0.3 Februar 2012 Peter Horsbøll Møller, Systems Engineer Pitney Bowes Software MapInfo for Windows MapInfo Professional Start på Microsoft.NET integration Investeringer

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

SYSTEM DESIGN. 18. december 2012 [Mink Farm Rapport] Dette projekt bruger UP model, som er et krav for dette semesters projekt.

SYSTEM DESIGN. 18. december 2012 [Mink Farm Rapport] Dette projekt bruger UP model, som er et krav for dette semesters projekt. SYSTEM DESIGN Dette projekt bruger UP model, som er et krav for dette semesters projekt. Unified Process (UP) er en iterativ og gradvis softwareudvikling proces ramme, der bruges til at modellere hvad,

Læs mere

The Complete Property Management System

The Complete Property Management System The Complete Property Management System Med fokus på jeres virksomhed HotSoft 8 er et komplet bookingsystem, som egner sig til alle typer virksomheder fra vandrerhjem til store hotelkæder. Eftersom HotSoft

Læs mere

Arkitektur principper og design mønstre til realisering af enterprise applikationer baseret på rige domænemodeller (og.net)

Arkitektur principper og design mønstre til realisering af enterprise applikationer baseret på rige domænemodeller (og.net) Arkitektur principper og design mønstre til realisering af enterprise applikationer baseret på rige domænemodeller (og.net) Kim Harding Christensen EOS A/S Margrethepladsen 3 8000 Århus TLF: 8732 8787

Læs mere

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav.

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav. Miniprojekt2011 Projektbeskrivelse Der skal fremstilles en lille java application på PC, hvor brugeren kan foretage interaktioner med en simpel database på disken via et grafisk brugerinterface. Formålet

Læs mere

EasyIQ Opdatering 5.2.3 -> 5.4.0

EasyIQ Opdatering 5.2.3 -> 5.4.0 EasyIQ Opdatering 5.2.3 -> 5.4.0 Kunde: Forfatter: Thomas W. Yde Systemtech A/S Side: 1 af 17 1 Indholdsfortegnelse 2 GENERELT OMKRING FORUDSÆTNINGEN OG OPDATERINGS FORLØBET... 3 2.1 FORUDSÆTNINGER...

Læs mere

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...

Læs mere

Bibliotek.dk som lokal grænseflade notat

Bibliotek.dk som lokal grænseflade notat Bibliotek.dk som lokal grænseflade notat Dette notat skal beskrive løsningsmodeller for bibliotek.dk som lokal grænseflade som opfølgning på det notat som blev lavet i 2007 1 og på den workshop som blev

Læs mere

EDI. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1. Copyright: Naddon version 201010

EDI. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1. Copyright: Naddon version 201010 EDI Microsoft Dynamics NAV 2009 SP1 Klassisk Side 1 Indholdet i dette dokument må på ingen måde gengives helt eller delvist hverken på tryk eller i anden form - uden forudgående skriftlig tilladelse fra

Læs mere

My booking. Generelt. Forsiden. Version 9.0

My booking. Generelt. Forsiden. Version 9.0 My booking Version 9.0 System til at lave online bookinger, med mulighed for opdeling i grupper, forskellige booking typer, ændre layout indstillinger, status styring, sprogvalg samt en del mere, detaljer

Læs mere

Vejledning i brugen af økonomiportalen 2011 Indhold

Vejledning i brugen af økonomiportalen 2011 Indhold Vejledning i brugen af økonomiportalen 2011 Indhold Køreplan for indberetning af regnskab og budget til provstiet.... 2 Hvordan indberettes regnskab 2011?... 2 Hvor kan jeg få hjælp.... 3 Kontrol af data

Læs mere

Indhold. 1 Indledning... 3. 1.1 Kompatible browsere... 3. 2 Log ind i Umbraco... 3. 3 Content-delen... 4. 3.1 Indholdstræet... 4

Indhold. 1 Indledning... 3. 1.1 Kompatible browsere... 3. 2 Log ind i Umbraco... 3. 3 Content-delen... 4. 3.1 Indholdstræet... 4 Indhold 1 Indledning... 3 1.1 Kompatible browsere... 3 2 Log ind i Umbraco... 3 3 Content-delen... 4 3.1 Indholdstræet... 4 3.2 Ændring af indhold... 5 3.3 Tilføjelse af en side/sektion... 6 3.4. At arbejde

Læs mere

Rollebeskrivelser. Programroller ift. den fællesstatslige programmodel

Rollebeskrivelser. Programroller ift. den fællesstatslige programmodel Rollebeskrivelser Programroller ift. den fællesstatslige programmodel Indholdsfortegnelse Rollebeskrivelser... 1 1. Programprofiler... 3 1.1. Formand for programbestyrelse/programejer... 3 1.2. Programleder...

Læs mere

Testservice med anvendelse af Microsoft software.

Testservice med anvendelse af Microsoft software. Testservice med anvendelse af Microsoft software. Få offentlig nøgle fra installeret signeringscertifikat 1. Klik Start Kør på den pc eller server hvor signeringscertifikatet er installeret. 2. Skriv MMC

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

Dokumentering af umbraco artikeleksport:

Dokumentering af umbraco artikeleksport: Dokumentering af umbraco artikeleksport: Lav en artikel side 2-3. Installationsguide side 3-5. Opsættelse af databasen og web.config side 5-8. Umbraco: templates side 8. Umbraco: borger.dk tab side 8.

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

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret Håndbog Til CPR services Bilag 8 GCTP-standard m.m. CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk Side 2 af 14 Indholdsfortegnelse

Læs mere

PROfessiOnel RisikOstyRing med RamRisk

PROfessiOnel RisikOstyRing med RamRisk 4 Professionel risikostyring med ramrisk www.ramrisk.dk Risikostyring med RamRisk Rettidig håndtering af risici og muligheder er afgørende for enhver organisation og for succesfuld gennemførelse af ethvert

Læs mere

Shop Floor Control. Registrering. Med Shop Floor Control i Microsoft Navision. Axapta kan du indsamle og analysere

Shop Floor Control. Registrering. Med Shop Floor Control i Microsoft Navision. Axapta kan du indsamle og analysere Med Shop Floor Control i Microsoft Navision Axapta kan du indsamle og analysere produktionsrelaterede oplysninger, f.eks. arbejdstimer og produktionsaktiviteter, for at forbedre omkostningsstyringen samt

Læs mere

Supermarkedsmodellen for design af brugergrænseflade

Supermarkedsmodellen for design af brugergrænseflade Supermarkedsmodellen for design af brugergrænseflade Denne note er skrevet frit efter Peter Huber, som på et kursus i Efteruddannelsescenteret fortalte om supermarkedsmodellen til design af brugergrænseflader.

Læs mere