Eksperimentel Systemudvikling 2011 Materielstyring til HVF 127 MFP

Størrelse: px
Starte visningen fra side:

Download "Eksperimentel Systemudvikling 2011 Materielstyring til HVF 127 MFP"

Transkript

1 Eksperimentel Systemudvikling 2011 Materielstyring til HVF 127 MFP DAT2, Group 3: Søren Løbner, Morten Daugaard, Jens William L. Sørensen,

2 Abstract In this report we have described how we have used the contextual design method to develop a design for an interactive system. The system supports the handling of materials and timeslots in a national guard otilla in Randers. To help in the design process we have created an interactive prototype of two working android applications. In the rst chapter we will give a short introduction to the problem at hand. Second chapter describes the general theoretical methods that we have used in the process. Third chapter is a description of the organization. Fourth Chapter describes how we have utilized the methods from chapter one. In the fth chapter we will give a summary of possible directions for future work. In the sixth and last chapter we conclude that our design has the potential to develop into a valuable tool for the otilla. Additionally we comment on our experiences with involving users in the design process in general.

3 1 Indledning Problemformulering Relateret litteratur PACT People Activities Context Technology Contextual Design Contextual inquiry Work Modelling Flow models: Sequence models: Artefact models: The Cultural model: The physical model: The anity diagram Consolidation Developing a vision Storyboard UED Paper prototyping Prototype lo- prototype hi- prototype Beskrivelse af organisationen Kontakten til organisationen PACT Design processen Data indsamling IT-befalingsmanden: introduktion til problemer og ønske om IT Forsyningsbefalingsmanden: primær stakeholder Contextual Inqueries Data behandling Flow Models Reektioner Sequence Models Bestilling Behandling af bestilling

4 Udlevering af materiel Tilbagelevering af materiel Reektion Artefakt Modeller Bestillingsseddel Forsyningsblanket Transportdokument Reektion Cutural model Physical model Anity diagram Reeksioner Developing a vision Webinterface Bestillingsklient i otillens lokaler Android applikation Reeksioner Storyboards Bestilling Udlevering af materiel Aevering af udlånt materiel Reeksioner UED Reeksioner Prototyping Første prototype Evaluering af lo- prototype Anden prototype Evaluering af hi- prototype Scenarier Scenarie: Arranger udlevering, inden Scenarie: Arranger udlevering, efter Fremtidigt arbejde Det videre forløb Backend systemet Portering til andre platforme Sikkerhed på platformen Udskrift af dokumenter fra systemet konklusion Erfaring med brugersamarbejde A Afvikling af hi- prototypen 44 A.1 Anvendelse

5 Chapter 1 Indledning I denne rapport vil vi gengive en design proces af et system der skal hjælpe en hjemmeværns otille i Randers med deres materielbestillinger. Vi vil primært bruge den kontekstuelle designmetode der er beskrevet i [Benyon, 2010], til at udvikle designet. Vi har valgt at bruge kontekstuelt design da vi mener at det passer godt til denne opgave, Contextual Design is written as a method for the design of generic product across a particular customer sector [Benyon, 2010][s. 273]. Denne beskrivelse passer godt på vores projekt, der skal udvikles et generisk bestillingsværktøj til brug hos hjemmeværnsafdelinger i Danmark, Ligeledes nder vi at opbygningen af den kontekstuelle designmetode passer godt til udvikling i teams og den sikrer at der er stor kunde inddragning og da vi har en god kontakt til otillen ser vi dette som en klar fordel. Vores endelige produkt vil være en interaktiv prototype, samt denne rapport der beskriver processen vi har foretaget for at udvikle prototypen. 1.1 Problemformulering Efter første møde med den valgte organisation, denerede vi følgende problemformulering. Vi vil ved hjælp af den kontekstuelle designmetode udvikle et interaktivt system til støtte af materielbestilling og håndtering i HVF 127 MFP 1 i Randers. Vi ønsker at simplicere og begrænse overødigt papirarbejde. 1 Hjemmeværnsotille 127, Maritime Force Protection 3

6 Chapter 2 Relateret litteratur 2.1 PACT PACT 1 [Benyon, 2010][s. 26] er et skelet der kan bruges som værktøj til at få designet et interaktivt system. PACT bygger på ideen om at at systemer skal udvikle sig i forhold til den kontekst de bruges i og hvordan de bruges. Så hvis konteksten for et system ændrer sig skal man ændre systemet for at tilpasse de nye behov. Men denne afhængighed går begge veje, hvis systemet ændres vil måden man bruger det på også ændre sig. PACT er delt op i re dele. People, Activities, Context og Technology People De store forskelle der er på folk har stor eekt på hvordan man skal udvikle sin teknologi. Der tages hensyn til re forskellige kategorier [Benyon, 2010][s ] t Fysiske forskelle: De fysiske forskelle på folk kan have afgørende betydning for designet af et system. Folk kan være blinde, døve, handikappede eller lignende. I et godt system har man selvfølgeligt taget hensyn til disse ting. Psykologiske forskelle: Der er naturligvis også forskelle på det psykologiske plan, folk har blandt andet forskellige kapaciteter med hensyn til hukommelse og koncentration. Mentale modeller: En mental model er en repræsentation for vores forståelse og viden. Hvis man har en god mental model inden for et område, program eller lignede kan man hurtigt udfører en opgave. Mentale modeller bliver styrket når man anvender systemer. Sociale forskelle: Folk har forskellige grunde til at anvende et system, nogle brugere vil gerne have en god, spændende oplevelse mens andre blot ønsker at udføre en opgave. Eksperter og nybegyndere har ofte forskellige tilgange til et system. Der er stor forskelle på at udvikle til et homogent og et heterogent brugersegment Activities Activities er de handlinger der skal udføres, eventuelt med henblik på et nyt interaktivt system. En designer skal selvfølgelig have fokus på formålet med en aktivitet, men der skal også tages hensyn til følgende hovedpunkter [Benyon, 2010][s. 35]: 1 People,Activities,Contexts,Technologies 4

7 Temporal aspect Cooperation Complexity Safty-critical The nature of the content En designer skal tage hensyn til hvor ofte en handling skal udføreres. Handlinger der bliver udført ofte vil have et andet design end ting der sjældent bliver udført. Der skal også tages hensyn til i hvilke situationer systemet vil blive brugt. Er der stort tidspres eller kan handlingen udføres langsomt og i et normalt tempo. Responstid er også en faktor, hvis det er kritisk at få hurtig svar så skal designet efterkomme dette krav. Der er også forskel på om en opgave består af en enkelt udførsel, eller om den skal foregå som ere udførelser. Er opgaven en holdopgave eller er der kun en enkelt bruger. Hvis der er ere brugere vil et design skulle tage højde for dette Context Handlinger og opgaver sker altid i en bestemt kontekst der tages i PACT højde for tre emner [Benyon, 2010][s.36] Physical enviroment: udvikles. De fysiske rammer kan have stor indydelse på hvorledes et system skal Social context: De sociale omgivelser er kan også have indvirkning på designet. Kan man få hjælp til at bruge det, eller er der sociale begrænsninger. Organizational context: Hvordan er det organisatoriske opbygget, er det en lille en-mands-virksomhed eller er det en stor multinational virksomhed. Dette kan være vigtigt at tage højde for i et godt design Technology Der skal tages højde for hvilke technologier designeren har at arbejde med, der skal tages højde for forskellige mugligheder inden for re katagorier [Benyon, 2010][s.38-44]. Input: Der er mange former for inputredskaber, og det er vigtigt at de rigtige bliver valgt til projektet. Output: Output kan ske på mange forskellige måder, der er hovedsagligt fokus på tre sanser når vi snakker om output, Syn, høre- og følesansen. Der kan være mange forskellige måder at få implementeret en god output metode. Communication: Hvordan skal brugere og enheder i systemet kommunikere med hinanden. Her er det vigtigt at tage højde for båndbredde og lignende, samt at give god feedback til brugere. Content: Content omhandler data i systemmet, hvilken struktur og form den har, det er en fordel at have præcis og velstruktureret indhold for at kunne lave et godt design. 5

8 2.2 Contextual Design Kontekstuel design er lavet som en metode til at producere et design over et generisk produkt til en bestemt brugersegment [Benyon, 2010][s.273]. Metoden er et miks af følgende: [Benyon, 2010][s. 272]. Almindelige tekniker der er blevet modiceret Etablerede tekniker der er integreret i metoden. Modellerings tekniker. Team building og data udvekslings metoder Contextual inquiry Det første skridt i en kontekstuel design proces er Contextual inquiry [Benyon, 2010][s. 274] det er en kombination af et almindeligt interview og observation. der er re grundlægende principper i Contextual inquiry. Context: Man skal besøge brugeren og se hvordan opgaverne bliver udført i den virkelige verden, Arbejdspladsen, hjemmet eller lignende, og stille spørgsmål til de handlinger der udføres. Partnership: Designeren og kunden er eksperter på deres områder, designeren skal være god til at se mønstre og strukturer i arbejdet. Kunden har stor viden om hvordan opgaven bliver udført. Interpretation: Designeren skal kunne tolke på de observerede handlinger, og nde mulige grunde til at opgaven bliver udført på denne måde, dette skal så vendes med kunden. Focus: Når man besøger en kunde skal der være et fokus ved dette besøg. Man kan spilde meget tid på at kunden viser eller fortæller om dele af arbejdet der er irrelevante Work Modelling Behandlingen af den data vi har fået ved vores kontekstuel forespørgsel skal gennemgås og dokumenteres som modeller. Der er fem forskellige typer af work models der alle repræsenterer en del af opgaven [Benyon, 2010][s. 277] Flow models: Flow models [Benyon, 2010][s. 278] er en repræsentation af hvordan en opgave bliver koordineret over de forskellige aktører. Flow models er udviklet fra et specikt synspunkt, der kan derfor være ere forskellige ow models for samme område. Flow models har følgende komponenter: Individuals: De involverede personer. Responsibilities: De individuelle aktørers ansvarsområder. Groups: Grupper af folk med de samme ansvarsområder. Flow: Hvordan personerne kommunikerer for at udfører opgaven. 6

9 Artefacts: De genstande, objekter der bliver brugt til, eller i forbindelse med, opgaven. Communication topic or object: Emnet der bliver diskuteret brugt. Places: Steder der er relevante for udførslen af opgaven. Breakdowns: De steder hvor det går galt Sequence models: For at repræsentere en opgave bruger man Sequence models [Benyon, 2010][s. 282]. Disse viser opgaven som den sker over tid. Sequence models bliver, ligesom ow models, lavet set fra en bestemt synsvinkel og man kan derfor have ere sequence models til samme opgave. Der er følgende elementer i en sequence model: The intent: Målet der skal opnåes ved udførslen af sekvensen, der er altid en hovedintention og der kan være ere under mål. The trigger: Hændelsen der starter sekvensen. Steps: Der er en række trin der bliver udført i sekvensen for at opnå The intent. Breakdowns: De steder hvor det går galt, eller kan gå galt, markeres Artefact models: Artefact models [Benyon, 2010][s ] er artefakter. Artefakter er genstande, fysiske ting, som der bliver brugt eller skabt i forbindelse med at der udføres opgaver i det nuværende system. Disse genstande skal forstås og dokumenteres, så man ved hvordan de bruges og forstås, indsamlingen af disse artefakter som en del af et Contextual inquiry se The Cultural model: Virksomheder kan have forskellige kulturer, dette bliver i Contextual design afspejlet ved hjælp af en Cultural model [Benyon, 2010][s. 289]. En virksomheds kultur har stor indvirkning på hvordan ting foregår i en virksomhed. Følgende elementer ingår i en Cultural model. Inuencers: Folk der har indydelse på hvordan opgaver bliver gjort. Extent: Den grad af indydelse en Inuencer har på en bestemt opgave. Direction: Den retning indydelsen går. Breakdows: hinanden. Hvor der er ting der går galt, eller hvor forskellige kulturelle indydelse modvirker The physical model: The physical model [Benyon, 2010][s. 291] er en repræsentation af de fysiske rammer omkring opgaverne der bliver udført. Modellen er ikke tænkt som et specikt grundplan, men skal forsøge at vise de vigtige punkter der bliver brugt i forbindelse med opgaven. Den kan være med til at give overblik over hvorfor opgaver bliver udført på de måder de gør. Elementerne i en physical model er: 7

10 Physical structures: Den fysiske struktur af arbejdspladsen, dette er kun så længe det har relevans for opgaven der bliver udført. Movement: Hvordan folk normalt bevæger sig rundt i arbejdsområdet og hvordan genstande bliver yttet rundt. Communications: De midler der anvendes til kommunikation i miljøet. Key artefacts: De steder hvor relevante genstande opbevares. layout: Indretning af arbejdspladserne, Breakdows: De steder hvor der kan gå ting galt The anity diagram Et anity diagram [Benyon, 2010][s ] er med til at denere krav, ønsker og behov til et system. Anity diagrammet er en Card sorting technique [Benyon, 2010][s. 164], teknikken er at man skal skrive koncepter på små kort, post-its eller lignende og herefter sortere dem i relevante grupper Consolidation Næste skridt i den kontekstuelle design proces er Consolidation [Benyon, 2010][s. 301]. I denne fase skal man følge op på og analysere de modeller og diagrammer man har konstrueret. Der skal også brainstormes for ideer til nye måder at løse problemer på. De enkelte workmodels bruges på følgende måde [Benyon, 2010][s ]. Flow models: Flow models bliver brugt til at få styr på folks roller og hvordan arbejdsgangen omkring opgaverne. Sequence models: Sequence models bruges til at få nye desginideer. Måske kan noget eller hele opgaven automatiseres, det er dog vigtigt at man er helt sikker på at der ikke mistes nogle punkter der skulle være manuelt. Artefacts models: Artefacts er gode til at danne et overblik over hvor der i arbejdsgangen eller i redskabet selv kan være designfejl. Cultural models: Den kulturelle agenda på en arbejdsplads, siger ikke så meget om hvordan strukturen og arbejdsprocessen er, men det er vigtigt at tage hensyn til det. Virksomhedskulturen kan være med til at forhindre at det nye design kommer til at fungerer som det var tænkt. Physical models: Det fysiske layout kan have stor indvirkning på et nyt design. Det kan være hensigtsmæssigt at tage hensyn til hvor artefakter opbevares, hvor de forskellige folk opholder sig under opgaveløsningen og lignende Developing a vision Under dette punkt deneres hvad det nye design skal kunne. Dette foregår ved en gennemgang af de ideer der er kommet i Consolidation fasen (se 2.2.4). Tag højde for hvordan kunden vil have opbygget deres informations system. Få lavet en oversigt over hovedfunktionaliteten i systemet. I tilfælde af at der arbejdes som et designteam er det en god idé at involvere hele teamet. 8

11 2.2.6 Storyboard Storyboards [Benyon, 2010][s ] skal bruges til at få konkretiseret visionerne for systemet, de skal vise hvorledes en opgave vil blive udført, de er graske gennemgange af opgaverne. I Contextual design skal Storyboards give et mere bredt perspektiv end normalt og der skal vises både interaktionen med systemet og andre artefakter. Der skal laves storyboards for alle de vigtige opgaver UED For at få dannet et overblik over hvordan det endelige system skal fungerer, på en måde som er forståelig og anvendelig for både udviklere og kunder bruger Contextual design UED 2 [Benyon, 2010][s ]. UED er et høj niveau design af det system vi ønsker som vores endelige produkt. Det er mere detaljeret end et storyboard og vil give et fuldt overblik, hvor et storyboard vil have fokus på en enkelt opgave. Grundlægende består et UED af et antal fokus områder over de forskellige opgaver i systemet. Et fokus område indeholder de funktioner og opgaver der er relevant for det område. Fokus området gives et kort deskriptivt navn og vil være opbygget af følgende elementer. Purpose statement: Beskrivelse af hvilket formål der er med fokus området. Functions: De funktioner der skal være, disse bliver beskrevet med korte beskrivelser, der er tale om både funktioner der bliver brugt af brugerne og de der bliver kaldt automatisk af systemet. Objects: Dette er de objekter, folk, artefakter osv., der er relevante for fokus området. Links: Dette er henvisninger til andre relaterede fokus områder. Constraints: Betingelser til fokusområdet, f.eks hastighed. Issues: Omhandler ideer til systemets UI, der kan også skrives problemer o.lig. Hidden focus areas: De områder som brugeren skal kende til men ikke skal have en reel kontakt med. Roles: De personer der kommer til at skulle arbejde med denne del af systemet. De første re er hovedpunkterne i Fokus området, de sidste re skal kun medtages hvis der er brug for det Paper prototyping I Contextual design bruges der papir prototyper [Benyon, 2010][s ] som er en lo- prototype se 2.3.1, disse bliver lavet på papir, gerne i den rigtige størrelse. Hensigten med disse prototyper skal vises frem til brugerne ved at lade dem gennemgå opgaver, både de eksisterende og nye. Designeren vil løbende skifte skærm billeder. Der stilles spørgsmål til hvordan brugeren gør og føler løbende. Der bliver taget noter af reaktioner og foreslag. Tidligt i designet skal folk involveres i analysen af ansvarsområder og funktionaliteten i systemet. Senere skal der være fokus på eektivitet og et mere komplet design. 2 User environment design 9

12 Genfortælle prototype mødet til resten af design teamet. Selve brugssituationen med brugeren skal designes på samme måde som et Contextual inquiry se Prototype En prototype [Benyon, 2010] [s. 184] er et værktøj til at efterprøve designet under selve design processen. De kan bruges til at demonstrere et koncept eller til at få styr på detaljerne. Der er mange forskellige måder og materialer at lave prototyper ud af, blandt andet pap og papir. Man kan med sine prototyper fokuserer på et enkelt design valg og man vil dermed kunne få bedre og klarere feedback fra brugeren på netop disse punkter, man bruger prototyperne som et lter [Lim et al., 2008][s. 7] lo- prototype Lo- prototyper [Benyon, 2010][s. 187] er ofte papir prototyper, screenshots på papir bliver lagt frem når brugeren interagerer med den, i en gennemgang af prototypen. De kan bruges til at sætte fokus på brede design ideer, de er hurtige at lave og nemme at smide ud bagefter. De bliver oftest brugt i den tidlige designproces til at hjælpe med udviklingen af løsninger. I udviklingen af en papir prototype skal man tage højde for hvor meget man skal gå i detaljer med prototypen kontra hvor meget man skal føre brugeren gennem opgaven hi- prototype Med hi- prototype [Benyon, 2010][s. 185] er man kommet meget tæt på det endelige mål. Der er altså tale om en computergenereret model der på mange punkter ligner og opfører sig som det produkt kunden skal modtage. En hi- pototype er god til at få evalueret på de generelle design elementer. Der er ofte tale om den sidste udgave som kunden skal acceptere inden man går i gang med den rigtige implementation af systemmet. Hvis der bruges hi- prototyper er der en ere faldgruber, prototypen kan komme til at virke for rigtig, dette kan gøre kunden forvirret hvis data ikke også er troværdigt. Der er heller ikke nogen garanti for at den prototype man har lavet rent faktisk kan føres ud i livet. 10

13 Chapter 3 Beskrivelse af organisationen HVF 127 MFP(Hjemmeværnsottille 127, Maritime Force Protection) er en forholdsvis ny hjemmeværnsenhed under marinehjemmeværnet. Enheden udfører opgaver som fredstidsbevogtning af søværnets skibe og installationer, samt støtte til det øvrige lokalforsvar i forbindelse med større katastrofer og lignende situationer. Eksempelvis kan det nævnes, at otillen var indsat som sikring følgende eksplosionen i Seest. I modsætning til marinehjemmeværnets sejlende enheder, er otillen primært fokuseret på landopgaver, dog med opgaver der indbefatter anvendelse af gummibåd i havne eller kystnært miljø. Flotillens medlemmer er en meget heterogen gruppe, med hensyn til alder, uddannelse og social baggrund. I forbindelse med optagelse i hjemmeværnet stilles dog visse krav, man skal blandt andet være minimum 18 år gammel og ellers opfylde bestemmelserne i hjemmeværnsloven Ÿ7 1. En høj procentdel af medlemmerne har før deres tjeneste i hjemmeværnet, aftjent deres værnepligt i forsvaret, hvor de er blevet bekendt med den omgangstone der ndes i en militær organisation og måden hvorpå en sådan organisation fungerer. Flotillen ledes efter de principper der gælder for almindelige enheder i forsvaret, på trods af at være en fuldstændig frivillig organisation. Medlemmerne kommer primært fra Randers og nærliggende områder, dog med enkelte der kommer fra Århus og Silkeborg-egnen. Det daglige arbejde foregår i otillens lokaler i det sydlige Randers, her mødes medlemmerne før og efter øvelser og her gennemføres uddannelse af og for otillens grupper. På adressen forendes, foruden undervisningslokale, også stabs-kontor, befalingsmandskontor, garage og lagerfaciliteter til forbrugsgenstande og det materiel der opbevares centralt. Organisationen er opbygget med en stab, bestående af otillechefen(fh) og hans næstkommanderende(nk), og underliggende delinger(del), som igen har underliggende grupper(grp). Staben og delingsorganisationen har ofte mere administrative opgaver, hvorimod den praktiske opgaveløsning oftest foregår i GRP-ramme. Flotillens øvelsesaktiviteter kan inddeles i taktiske øvelser, der ofte foregår på ådestation Frederikshavn eller i civile havne, og skydeøvelser som enten foregår på almindelige skydebaner i nærområdet eller i et af forsvarets skydeterræner. Flotillen deltager i ere større øvelser årligt og deltager desuden i skydninger og skydelejre adskillige gange om året. Forberedelse til øvelsesaktivitet (planlægning, udlevering af materiel o.l.) foregår i otillens lokaler. I forbindelse med de opgaver og øvelser enheden deltager i, skal medlemmerne bruge forskelligt materiel, ofte materiel af høj værdi eller våben, som opbevares centralt når det ikke er i brug. Det er enhedens forsyningsbefalingsmand der har ansvaret for at udlevere bestilt materiel og modtage det igen efter brug. 1 (herunder egnetheds- og værdighedskriteriet. 11

14 3.1 Kontakten til organisationen Før projektets start kontaktede Morten fra projektgruppen otillens forsyningsbefalingsmand, Jacob Ølholm og otillens IT-befalingsmand Erik Holland. Mortens baggrund for at skabe denne kontakt er, at han til daglig fungerer som delingsfører i otillen og derfor har et indgående kendskab til otillens arbejdsgange. Dette kendskab k ham til at foreslå projektet for de to ovennævnte befalingsmænd, som begge var positive overfor ideen. Dette på trods af det fysiske udbytte af projektet for otillen, kun vil være en prototype der kan synliggøre de muligheder og udfordringer, et endeligt system ville kunne bringe. Selvom det har været en støtte, at have en med nært kendskab til organisationen i projektgruppen, har det også betydet, at vi hele tiden har måttet være på vagt overfor en hvis forudindtagethed. En sådan forudindtagethed eller bias, ville muligvis kunne afholde os fra at udforske specielle designvalg og idéer og på den måde hæmme vores projekt. 3.2 PACT For at danne os et overblik over strukturen af virksomheden og det system vi vil udvikle til dem, har vi lavet en PACT analyse, se sektion 2.1. People: Bruger Gruppefører, delingsfører osv. - dvs. dem der bestiller materiel hos Forsyningsbefalingsmand (FSBM) Aldersgruppe IT-færdigheder Almindelige brugere. Flere af brugerene har erfaringer med smartphones. Generelt har brugerne meget forskellige baggrunde. FSBM Forsyningsbefalingsmand, nder materiel frem som brugerne har bestilt, hvis der mangler skal der bestilles nye ting pr. mail. han skal ligeledes tage imod materiel der skal aeveres tilbage. Alder 29 IT-færdigheder Almindelig bruger. Har erfaring med smartphonen. Activities: Bestilling og udlevering af materiel, bestilling af materiel ved depot og modtagelse af materiel. foregår ca. en gang om ugen, en gang imellem oftere. Responstid - ikke kritisk. Complexitet, ikke vildt kompliceret, NEM udregning er meget vigtig og en smule kompliceret, den er lovpligtig. Det er meget vigtigt med kopier af udleveret materiel, skal have underskrift på udleveret materiel. NEM udregninger er også kritiske. Contexts: Bestilling af materiel fra brugeren kan ske med en bestillings liste, pr telefon, mail o.lig. udlevering foregår ved otillens lokaler. Bestilling af materiel ved depot foregår oftest pr. mail, og FSBM kører så til depot for at få materiel udleveret. Organizational context: foregår i et miljø, der pga. den militære baggrund, værdsætter punklighed og eektivitet. Er et hierarkisk opbygget miljø, der er ikke nogen der f.eks kan nde på at gå uden om FSBM, og hente materiel. Technologies: Input Browser eller mobil app, det skal kunne bruges af almindelige brugere, delen som brugeren skal have adgang til skal være simpelt og eektivt, det er meget vigtigt med afhentningstidspunkt. FSBM må gerne være mere avanceret, de mest brugte features må gerne være eektive og let tilgængelige. Output Brugeren skal have tydeligt feedback på bestilling. FSBM- skal have besked når der kommer 12

15 en bestilling, der skal også udskrives forsyningsblanketter(kvittering) ved afhentning. communication lille dataudveksling, over ip eller lignende, sikkerhed ikke så vigtigt, materiel bliver fysisk udleveret af FSBM. content Database over materiel på lager. Lister over aktivt udlån. Kø over ventende bestillinger. Alt sammen tekst data. 13

16 Chapter 4 Design processen 4.1 Data indsamling Indsamlingen af data vedrørende vores projekt følger i de kommende afsnit. Det drejer sig om specikke formål samt udbytter af møder og samtaler med vores kontakter i hjemmeværnet i Randers. Det omhandler også hvad vi ville undersøge, forventede, og hvad vi k ud af det IT-befalingsmanden: introduktion til problemer og ønske om IT I slutningen af marts fandt første møde sted, med en repræsentant for hjemmeværnet i Randers. Her drejede det sig om at vi skulle danne os et overblik over otillens IT-systemer, og analysere os frem til de elementer eller områder, som kunne drage fordel af et re-design. Mødet var med IT-befalingsmanden, som bl.a. kunne berette, at otillens nuværende anvendelse af IT var minimal. Der var adskillige områder som kunne drage fordel af IT-understøttelse. IT-befalingsmanden har erfaring med ERP systemer, men mente at disse systemer ville tilbyde for mange unødvendige features og at en ny løsning skulle fokusere på de specikke forsyningsopgaver i otillen. Mødet blev holdt i en forholdsvis teknologipræget atmosfære og sammen k vi udarbejdet, hvad der kunne være et forslag til den underliggende arkitektur i vores initielle design. Vi diskuterede fordele og ulemper, ved et nyt system(eventuelt på en mobil platform) fremfor den nuværende papir/mail-baserede tilgang og vi kom frem til følgende fordele og udfordringer: Fordele: Den almindelige bruger af systemet behøver ikke fysisk at have kontakt til forsyningsbefalingsmanden. Den almindelige bruger kan få en ide om hvor lang tid der går, før et stykke materiel kan udleveres. Forsyningsbefalingsmanden kan få automatiseret trivielle arbejdsopgaver. Forsyningsbefalingsmanden får et bedre overblik over lager og udlån. Udfordringer: Brugerne skal vænnes til et nyt system. Systemet skal ikke pålægge brugerne mere administration end det nuværende papir/mail system. 14

17 4.1.2 Forsyningsbefalingsmanden: primær stakeholder Da vi nu havde afklaret at vores løsning skulle fokusere på de specikke forsyningsopgaver, så var det næste møde med forsyningsbefalingsmanden (FSBM). I det følgende vil vi beskrive måden vi gennemgik Contextual Inqueries Et contextual inquery, er måden hvorpå vi interviewer personer, der skal have indydelse på designet. Som beskrevet i afsnit Under det følgende contextual inquery, k vi gennemgået en konkret brugssituation, hvor vi k indsigt i måden hvorpå FSBM bestiller materiel til, i dette tilfælde, en skydeøvelse. I processen indgik udfyldning af en række papirer, samt afsendelse af s og under ere af disse handlinger forekom der at være opgaver, som kunne optimeres. Situationen vi overværede, udspillede sig som følger: En bruger havde tidligere bestilt re materielemner ved at udfylde en bestillingsliste og aevere den til FSBM. Materielemner er i dette tilfælde, ting som kan skaes gennem hjemmeværnets materieltjeneste. Da materiellet efter aftale skal udleveres en bestemt dato, har FSBM sikret sig at de enkelte emner ndes på eget lager, så han skriver bestillingen over på en forsyningsblanket med gennemslagspapir. Derefter bevæger han sig ud på lageret og plukker de bestilte emner. Sidste skridt er at brugeren underskriver forsyningsblanketten og Herefter beholder den ene kopi og FSBM originalen. Denne process gennemgås minutiøst i afsnit 4.4.1, og i afsnit beskriver vi så, hvordan det udspiller sig, under anvendelse af vores applikation. FSBM forklarede, at i situationer hvor et eller ere emner ikke bender sig på eget lager, skal de bestilles. Dette gør FSBM ved at sende en mail indeholdende de elementer han ønsker til depotet i Aarhus. I dette tilfælde havde FSBM modtaget en bestillingsliste, men ofte foregår bestillinger pr. mail eller telefon, hvilket besværliggør FSBMs arbejde. Ofte vil udleveringen af en bestilling indeholdende ammunitionsemner efterfølges af udfyldelsen af et transportdokument(hvis for eksempel ammunitionen skal transporteres til skydebanen). FSBM forklarer at når udlån skal returneres, så foregår det ved at materiellet optælles og kvitteringen herefter udleveres til låneren. Breakdowns FSBM gjorde os opmærksom på, at bestillingssedlerne kunne være udfyldt fejlagtigt. Det kunne være hvis en bruger havde angivet en forkert type, i feltet 'Antal' - konkret set ved, en bestilling på 'LMG Bånd' har under 'Antal' angivet 'Bånd' i stedet for et heltal, som er det som forventes. Det var altså muligt at skrive andet end tal, i felterne under 'Antal' Et andet breakdown blev observeret ved at der, som tidligere nævnt, var redundant papirarbejde. Mange formularer skal udfyldes ere steder, og dette kompliceres yderligere, hvis der er tale om at de ønskede elementer, var ammunition. Der skal der udfyldes ekstra transport-sedler, med såkaldt NEM-vægt, Netto Eksplosiv Mængde, en vægt som angiver den samlede mængde sprængstof, i det transporterede materiel. Vi k under dette møde også en introduktion til otillens bygning, lokaler samt, vores fokus område, lageret. Materialet var opstillet i hyldeorden, med numre markeret på hylderne, til indeksering. Her kunne vi, under interviewet med FSBM også forstå på ham at han ville imødese en ordning hvor han ville kunne benytte en håndholdt enhed, som f.eks. hans Android smartphone, til at scanne en stregkode, i stedet for at skulle skrive numre ned, som han efterfølgende skulle indtaste på computeren på kontoret. De indsamlede artefakter fra dette møde består af: eksempler på forsyningsblanketter 15

18 eksempler på udfyldte bestillingslister elektroniske udgaver af: forsyningsblanketter bestillingslister eksempler på transportsedler Ud fra disse artefakter har vi efterfølgende haft mulighed for at revidere vores prototyper, og optimere måden hvorpå udfyldningen af felter bliver gennemført. Det vil sige, at vi har begrænset antallet af felter, for at kun at bruge de absolut nødvendige. 4.2 Data behandling Flow Models For at danne et overblik over hvordan opgaver bliver koordineret og udført mellem de forskellige aktører ved en materiel bestilling, har vi lavet en workmodel, (som beskrevet i ). Modelen tager fokus i FSBM, da vi har den bedste kontakt og også den eneste person der har kontakt til de andre. Som det kan ses ud 1 fra gur 4.1 er der kun linjer til FSBM. Figure 4.1: Flowmodel, fokus set fra FSBM Modellen indeholder følgende aktører: FSBM: CH: Forsynings befalings manden. Det er her vi har vores fokus. 2 Chefen FH, der er i den organisatoriske opbygning af otillen et hierarkisk system (se kapitel 3). 1 Forsynings befalings 2 otillechefen mand 16

19 Myndigheder: Der er visse krav til FSBM's omgang med våben ligeledes skal han lave transportdokumenter hvis der skal køres med sprængfarlig materiel eller ammunition. Brugere: Der er her tale om gruppeførere o.lig, det er disse som FSBM har mest kontakt med, de har deres daglige gang ved otillen lokaler. Depot: Der er her tale om et depot beliggende i Aarhus. Mellem brugeren og FSBM er der mange forskellige ows som udspiller sig i forbindelse med materiel behandling. Der foregår en bestilling, denne kan ske på mange forskellige måder, telefon, papir, mail eller SMS. Der skal ligeledes aftales et møde til udlevering og indlevering af materiel. Der er meget der kan gå galt i denne måde at ordne ud- og indlevering på, især i selve aftaleprocessen. Der skal aftales og udveksles meget data, og der kan ske fejl, især når bestillingen foregår gennem telefonsamtaler Reektioner Ved vores gennemgang af vores Flow model ser vi tydeligt at der er en klar opdeling af ansvarsområder mellem de forskellige personer involveret i systemet, vi ser også at det hovedsageligt er i kontakten mellem Bestilleren og FSBM at ting, bliver kompliceret og kan gå galt. Vi kan bruge disse oplysninger til at se hvor det bedst at vi kommer ind med en ny design ide. Modellen hjalp os også til at se hvilke arbejdsopgaver det var vigtigst at få lavet Sequence models på. Vi har ikke fået deneret de enkelte Individuals og deres responsibilities i modellen og det gør desværre at det har været lidt sværere for os at få analyseret modellen, man skal lige huske på hvilke ansvarsområder der er hvor. Heldigvis er den militære ordning i otillen, (se afsnit 3) med til at sørge for at der ikke er meget overlap på ansvarsområder Sequence Models I vores ow model, (se afsnit 4.2.1, k vi et overblik over hvor det ville være praktisk at vide mere om de enkelte opgavers udførsler. Dette kan være med til at sætte fokus på om der er ting der kan automatiseres eller gøres simplere og dermed mindre udsat for fejl. Vi bruger ere sequence models (se ) for at danne en god indsigt ind i det nuværende system Bestilling Bestilling af materiel er essentiel for processen, der er mange måder at gøre det på og der er mange steder der kan ske fejl, misforståelser o.lig. fokus kommer til at være hos brugere det er klart her der kommer til at foregå mest, og næsten den samme opgave vil blive gennemgået i afsnit Hensigten i modellen, se gur 4.2 er at der skal bestilles noget materiel. Triggeren er når der opstår et behov, som regel i forbindelse med en øvelse eller lignende. Det ses tydeligt i guren at der allerede tidligt er ere muligheder for hvordan man får bestilt materiel. Vi har valgt at tage telefon, mail og at personligt aeverer en bestillingsblanket (se afsnit ). Dette skaber en uigennemskuelig arbejdsgang og stor risiko for datatab. Der kan ligeledes opstå breakdows når der skal aftales tid til udlevering, dette kan give store problemer og det synes at det må være et vigtigt punkt at få rettet i en god løsning Behandling af bestilling Denne sequence model omhandler hvordan med fokus på FSBM foregår når der skal aftales møde tidspunkter. Dette er et af de kritiske punkter i systemmet, FSBM har gjort os opmærksomme på at det er vigtigt 17

20 Figure 4.2: Sequence model af en bestilling, fokus fra Bruger med møde tiderne. Hensigten med opgaven er at få et tidspunkt der kan udleveres, Triggeren er at der bliver modtaget en bestilling. Figure 4.3: Sequence model af en behandlingen af en modtagen bestilling, fokus fra FSBM Der er to punkter der kommer til syne ved en gennemgang af denne model. Den første er grenen der skal udføres hvis der mangler materiel, her kan man få stor fordel ved at få indført en generel lagerstyring, der er ikke noget system til at holde styr på lageret, FSBM har selv et Excel-ark med noget data, men der kan opnå store fordele ved at få lavet en ordentligt database. Man kan så også kunne få automatiseret en del af processen ved bestilling hos fjern depot. Den anden er ikke så tydelig i modelen, men den er meget vigtig. Opgaven ved at få aftalt et tidspunkt, der kan ved især sms, mail bestillinger være mange trin inden man får aftalt et tidspunkt. Dette problem viste sig også i foregående afsnit , og vi bliver klar over at hvis vi skal lave et godt re-design til 18

21 systemmet skal der være en enkelt og nem metode at aftale tid på Udlevering af materiel Udleveringen af materiel skal ske på det aftalte tidspunkt i Flotillens lokaler, denne sequence model har til hensigt at det bestilte materiel udlevers. Triggeren er at der er modtaget og accepteret en bestilling. Fokus er hos FSBM. Figure 4.4: Sequence model af en udlevering af materiel, fokus fra FSBM Der foregår meget fysisk ved denne opgave og det vil være svært at lave om på dette. Men trinet hvor der skal udfyldes forsyningsblanketter, (se afsnit ), giver en mulighed for at kunne automatisere udfyldningen, der ny foregår i hånden enten med kuglepen eller ved indtastning i et dokument på computeren Tilbagelevering af materiel 3 Når brugeren er færdig med at bruge det lånte materiel, skal det a everes tilbage, forbrugs matriel 4 der er i overskud skal også leveres tilbage. Dette foregår som oftest lige efter en øvelse. Vores sequence model har som intent at der skal modtages udlånt materiel. Triggeren er at der skal aftales tidspunkt for dette. I denne sequence model er det igen et problem med tidspunkt og aftale om dette, problemet er dog ikke så stort da denne a evering som regel foregår lige efter en øvelse. Denne opgave er også meget fysisk og der er ikke meget vi vil kunne gøre for at få e ektiviseret når der fysisk bliver sat materiel på plads. Gennemgangen af materiellet kan dog gøres noget ved, for eksempel ved at holde databaser over udlånt materiel og have en form for scanning af materiellet Re ektion Produktionen og gennemgangen af vores sequence models har hjulpet os meget med at skabe et overblik over opgaverne, og hvor det er relevant at forbedre systemet, der er især tale om følgende punkter. 3 Der 4 Her er her tale om ting der skal a everes tilbage efter brug. Våben, biler o.lig er tale om materiel der kun bruges en gang, skyld plastre o.lig 19

22 Figure 4.5: Sequence model af en tilbagelevering af materiel, fokus fra FSBM Tidsbestilling. En konsistent måde at bestille materiel og tid på. Database håndtering. Automatisering af bestillinger ved depot. Automatisering af blanket udfyldelse. Hurtige måder at gennemgå materiel på Vi kunne med fordel have været mere detaljeret når modellerne blev udviklet. Det noget simple udtryk kan være med til at der bliver overset ting. f.eks (i gur 4.3) det fremgår ikke tydeligt at planlægning af mødetidspunkter er besværligt og kan tage ere iterationer Artefakt Modeller For at give os indblik i FSBMs arbejde og redskaber, udførte vi en analyse af tre af de artefakter der har størst betydning for FSBM og som est mulige i organisationen kommer i berøring med Bestillingsseddel Bestillingssedlen er FSBMs vigtigste nuværende redskab i forbindelse med bestillinger af materiel. Bestillingssedlen er umiddelbart et nyere koncept, som FSBM har indført for at få ensrettet de bestillinger han modtager, der er således ikke tale om en standardblanket der også anvendes ere steder i systemet. Sedlen kan ses som videreudviklingen af en simpel håndskreven note. Bestillingssedlens formål er to-sidet, både som en hjælp til FSBM der skal behandle bestillingen, men også som en hjælp til bestilleren der får et overblik over hvad der kan bestilles. Efter indsamlingen og den derpå følgende gennemgang af bestillingssedlens brug, udformede vi modellen der ses på gur 4.6. Bestillingssedlen består overordnet af to dele, en meta-del der udfyldes med diverse 20

23 Figure 4.6: Artefaktmodel, bestillingsliste 21

24 informationer om bestilleren, tidspunkt for udlevering, tidspunkt for aevering og anledningen til bestillingen 5. samt en materiel-del med en oversigt med navnet på de ting der kan bestilles og plads til at angive ønsket antal. Efter gennemlæsning af ere gamle bestillingssedler identicerede vi enkelte breakdowns hvor bestillingssedlen er udfyldt forkert. Hver gang en seddel er udfyldt forkert betyder det at FSBM er nødt til at kontakte bestilleren for at få rettet bestillingen, dette gør sig også gældende hvis FSBM ikke kan udlevere eller modtage bestillingen på de tidspunkter brugeren har angivet. De fordele bestillingslisten giver FSBM, skal afvejes mod de begrænsninger der naturligt ligger i papirmediet, for eksempel skal bestiller og FSBM være fysisk samme sted for at bestillingen kan overdrages, pludseligt opståede ændringer til bestillingen skal formidles via telefon eller mail og planlægningen af udog indlevering er meget ueksibel. Desuden giver listen kun bestilleren en ide om hvilke materielemner der ndes i systemet, ikke hvorvidt om de rent faktisk er på lager. Disse ulemper mener vi kan afhjælpes helt eller delvist kan afhjælpes ved et system der implementerer en digital version af bestillingssedlen Forsyningsblanket Forsyningsblanketten er et standarddokument som FSBM anvender i både en digital udgave og en papirudgave med gennemslag, dokumentet anvendes i hele forsvaret. Blanketten kan anvendes til adskillige formål blandt andet levering, tilbagelevering, overførsel og udlån. I otillen anvendes blanketten primært til udlån af materiel og fungerer således: blanketten udfyldes med de relevante oplysninger om modtager og de materielemner der udleveres, herefter underskriver låneren og modtager enten gennemslagskopien eller en ekstra udskrevet kopi af FSBM. FSBM opbevarer originalen. Ved tilbagelevering optælles materiellet og låneren modtager den originale blanket. Blanketten fungerer som kvittering for både låner og FSBM, men især kan FSBM dokumentere tilstedeværelsen af det materiel han er ansvarlig for. Artefaktmodellen for forsyningsblanketten ses på gur 4.7. Strukturen i dokumentet minder til forveksling om den på bestillingssedlen; en del der indeholder oplysninger om afsender, modtager og anvendelsestype, samt en del der angiver de emner der udleveres. Formmæssigt kan dokumentet godt virke forvirrende, der er mange rubrikker og ere er ikke annoteret med deres anvendelse. Skriften er ofte lille og der anvendes mange forkortelser. Dokumentets mange anvendelsesmuligheder gør også, at ikke alle rubrikker er nødvendige for hver anvendelse, hvilket givetvis kan skabe forvirring. Efter at have gennemset de originale eksemplarer vi modtog under dataindsamlingen, har vi identiceret enkelte breakdowns. Grundet den store mængde rubrikker kan det være svært for FSBM at huske hvilke der faktisk skal udfyldes i forbindelse med udlån. For låneren er det et problem at visse materielemner angives i sæt, da det ikke giver låneren et reelt billede af hvad han egentlig modtager(for eksempel kan der lånes et geværsæt, som udover geværet indeholder adskillige andre dele). En ting vi ikke ser som et breakdown, men nærmere en alternativ anvendelse af blanketten er, at FSBM anvender reference-rubrikken til at påføre serienumrene for de materielemner hvor dette kræves. Vi ser muligheder for at lette FSBMs arbejde, ved at eliminere inputmuligheder der ikke har relevans for udlån. Selvom vores system naturligvis må generere en forsyningsblanket i det anvendte format, behøver vores system kun udfylde de relevante rubrikker. Vi har desuden bemærket, at alt den information der skal anvendes for at udfylde forsyningsblanketten allerede eksisterer på bestillingssedlen, hvilket burde give anledning til en form for automatisering Transportdokument Transportdokumentet er ikke som sådan et redskab for FSBM eller andre otillemedlemmer, men derimod et stykke papir der kræves af ovenliggende myndigheder i forbindelse med transport af ammunition og 5 FSBM gjorde under interviewet opmærksom på, at især tidspunkterne var vigtige for hans daglige arbejde. 22

25 Figure 4.7: Artifaktmodel, forsyningsblanket 23

26 eksplosiver. Ligesom forsyningsblanketten og i modsætning til bestillingssedlen, er transportdokumentet en standardformular der bruges overalt i forsvaret. Transportdokumentet udfyldes ofte af FSBM i forbindelse med udleveringen af en materielbestilling og ofte ndes de relevante oplysninger, der skal bruges til at udfylde dokumentet, på den bestillingsseddel FSBM har modtaget. FSBM kan udfylde dokumentet manuelt eller ved hjælp af et regneark. At udfylde dokumentet kræver indgående viden til de emner der transporteres. Formen på dokumentet er generelt meget forvirrende, der er mange rubrikker og ere af dem virker ikke logisk placeret. Dokumentet giver det indtryk at det sjældent har praktisk anvendelse og ofte autogenereres. Strukturen i dokumentet består, ligesom bestillingssedlen, af en del der indeholder praktiske oplysninger, såsom: udgangspunkt, destination, køretøj og fører, derudover en del der indeholder oplysninger om de emner der transporteres, herunder: Materielnummer, antal, vægt og netto eksplosiv mængde(nem). Det eneste mulige breakdown vi har identiceret i forbindelse med udfyldelsen af transport dokumentet er, at det kan være meget svært at udfylde korrekt uden brug af et regneark der kan autoudfylde visse værdier, for eksempel varierer NEM værdien naturligvis for hver enkelt ammunitionstype. Eftersom dokumentet er ocielt, ville det, ligesom forsyningsblanketten, skulle udfyldes af vores system, så det overholder det nuværende format. Vi ser muligheder for at optimere udfyldningen/genereringen af transportdokumentet ved hjælp af autofuldførelse i en digitalformular, samt eventuelt ved at lave en sammenkobling med bestillingssedlen der kan indeholde de nødvendige oplysninger Reektion En af de ting vi ønsker med projektet er at eektivisere FSBMs arbejdsgange. Efter analysen af de artefakter vi har indsamlet, er det tydeligt at den samme information ere steder indtastes op til tre gange. En simpel men mærkbar eektivisering ville være at implementere et system der undgår denne redundans. Anvendelsen af standard dokumenter stiller krav til at systemet kan outputte informationen i disse formater, hvilket dog er et simpelt teoretisk koncept, som kan vise sig sværere i praksis. Det er vigtigt at huske, at det kun er i det perfekte bestillingseksempel at FSBM faktisk modtager en bestillingsseddel, ofte mailes eller telefoneres bestillingen, og vores system skal både være bedre end processen der anvender bestillingsseddelen og den der anvender mail/telefon Cutural model Vi nåde desværre ikke at få lavet en kulturel model, se afsnit , dette ligger ellers lige til, med den meget hierarkiske opbygning der er i hjemmeværnet. Vi valgte dog at hoppe over dette for at holde vores tidsplan og vi vurderede at det var bedst at lave ow-, sequence- og artefakt-modeller. Den meget opdelte og militære kultur sammen med at vi har daglig adgang til en hjemmeværnsmand, Morten (se afsnit 3.1), har vi haft nemt ved at udrede evt. spørgsmål til organisations kulturelle værdier. Dette har været med til at styrke vores vurdering om at undlade en kulturel model Physical model Vi valgte ikke at bruge en fysisk model se afsnit Vi mente at det var bestillingsopgaven, sende og modtage bestillinger, og da disse kunne foregå mange forskellige steder, i hjemmet, på arbejdet o.lig, syntes vi at det arbejde vi skulle lægge i det ikke ville kunne komme til nogen særlig stor gavn. Men angående ind- og udlevering af materiel kunne der være observationer som vi ikke har fanget, fordi vi ikke har fået lavet en fysisk model over otillens lokaler, og vi ville, hvis der havde været tid, havde brugt tid på at få lavet en fysisk opmåling af lokalerne. Vores endelige design bygger på en ide om at systemet skal kunne anvendes alle vegne, og det passer nt ind i processerne ved ind- og udleveringer. Vores endelige 24

27 produkt har også sørget for at digitalisere forsyningsblanketterne og bestillingssedlerne, se afsnit og , og vi har derfor fået fjernet et evt. breakdown, nemlig at papirene ikke bliver væk da det hele er digitaliseret. I det store hele er det et godt sted vi har valgt at slække lidt på designet, og vi har sikkert fået mere ud af de modeller vi har lavet, end ved at lave en fysisk og en kulturel model Anity diagram Vi har i samarbejde med FSBM udarbejdet et Anity diagram (se afsnit 2.2.3). Udviklingen var god og selvom vi ikke er i nærheden af at kunne præsenterer ere hundrede sedler, så var FSBM glad for at kunne give noget input til opgaven. Figure 4.8: Anity diagram Vores Anity diagram, se gur 4.8, indholder tre overordnede grupper: Bestillings modul: Denne kategori dækker over de ønsker der er til bestillingsdelen af vores system. FSBM modul: Denne gruppe indeholder punkter til del der kan hjælpe FSBM i hans arbejde med bestillinger. Administration af database: Denne gruppe er ønsker til håndteringen af databasen Reeksioner Vores anity diagram har været med til at få en bedre ide om hvilke ønsker FSBM har til et nyt system. Det fremgår også at en tre-deling af systemet virker hensigtsmæssigt. Det ville sikkert havde været bedre hvis 25

28 der var brugt mere tid på udviklingen, og dermed også kommet ere sedler. Desværre kommer der et reelt design forslag ind i diagrammet, Android applikationen, denne design idé har vi fået alt for tidligt og den kan måske havde holdt deltagerne i brainstorm-mødet fast i på krav til denne idé, og dermed ikke kommet med alle de krav eller ønsker der muligvis var Developing a vision Vi skal nu i gang med udviklingen af selve designet på det nye system, eller retter forslag til design. På baggrund af vores indsamlede data, modeller og diagrammer, er vi kommet frem til at vi i et nyt system kan automatiserer mange af de trivielle opgaver, udfyldning af formularer o.lig. Det er også oplagt at der kunne være en bedre måde, end FSBM's eget Excel-ark, at holde styr på lager status. Fejludfyldninger i bestillingssedler skal vi prøve at få begrænset eller elimineret helt. Forslag til forbedringer i systemet: Database, det vil være til stor gavn hvis der bliver sat en database som datastruktur til lageret. Tidsplanlægning, en kalender til planlægning af mødetidspunkter; den ene part kan sende sit forslag til mødetidspunkter, den anden part kan så vælge det tidspunkt der passer. Input validering, det var et generelt problem at bestillingssedlen blev udfyldt forkert og det skal derfor være meget simpelt og der skal laves sikring for at indtastet data er korrekt. Automatisering, FSBM kan få meget hjælp ved at papirer kan udfyldes automatisk. her drejer det sig hovedsageligt om forsyningsblanketten og transportdokumenter. Scanning af materiel der skal udleveres, dette kan være med til at lette udfyldningen af blanketter yderligere. Automatiseret tidsplanlægning: Automatisering af tidsplanlægning, systemet tjekker brugernes kalender og vil derefter kunne vælge et tidspunkt hvor begge parter kan. Dette punkt er ikke noget vi ville bruge, det virker urealistisk at brugerne af systemet vil holde en kalender der er præcis nok til dette formål. Depotbestilling: Systemet skal selv kunne give besked når der er varer der skal bestilles hjem, dette skal ske på baggrund af lagerstatus, og ventende bestillinger. Autofuldførelse på søgefunktion: Der kan vælges materielemner hvor listen af materiel bliver reduceret efter det input brugeren giver. Tidsplanlægning: FSBM fastsætter tidspunkter som man så kan booke sig ind på Webinterface En hjemmeside der ligner en almindelig webshop. dette system vil komme til at bestå af 2 dele. Webshop: Brugeren vil her kunne lægge det ønskede materiel i en virtuel indkøbskurv og tjekke det ud. Der vil blive sendt en mail til FSBM som bekræftelse. Database: Databasen vil være blive en hjælp til FSBM med hans lager status, han vil få et bedre overblik over hans lager og hvornår der skal bestilles. Der er ikke nogen oplagt måde at ordne tidsbestilling på i dette design, det ville kræve automatiseret tidsplanlægning. Hvilket vi jo gik bort fra. 26

29 Bestillingsklient i otillens lokaler Der sættes en bestillingsklient op i otillens lokaler, der skal så være mulighed for at komme ned i lokalerne og udfører sin materiel bestilling. Dette system vil komme til at have 2 elementer. Klient: Brugeren kommer ned i otillens lokaler for at gennemføre bestillingen, der vil løbende være en opdatering af databasen og brugeren skal kunne booke sig ind på et afhentnings tidspunkt fra en pulje afsat af FSBM. Database: Der vil være lavet en databasedel til at sikre FSBM et overblik over lagerstatus. Der vil også være muglighed for automatiske bestillinger hos depotet når det er nødvendigt, afhentningstidspunkt vælges fra pulje afsat af FSBM. Der er i dette design en større sikkerhed. Da data overførsler ikke sker over internettet er det nemmere at sørge for, at der ikke er nogen der får adgang til følsom data Android applikation Dette forslag er går ud på at der skal laves et kombineret webinterface til browsere og en applikation til smartphones. Systemet vil bruge bestillingssedlen som metafor for data der sendes mellem parterne, vi håber at det vil holde designet simpelt og genkendeligt for brugerne. Systemet kommer til at bestå af 3 dele. Bestillings applikationen: Her skal en bruger kunne tage sin telefon eller computer åbne applikationen og bestille det materiel han gerne vil have, han skal kunne undersøge og ændre tidligere ordre. FSBM applikationen: FSBM skal kunne tilgå bestillinger, godkende dem ændre tid eller varer og lignende, dette kan han tilgå direkte fra sin smartphone eller fra en browser. Der skal ligeledes være funktionalitet til at kunne hjælpe FSBM med ind- og udlevering af materiel, tanken er at applikationen skal automatisere så meget som mulig af formudfyldning, til at hjælpe med denne automatisering vil FSBM have mulighed for at scanne materiel, der tænkes her på scanning af stregkoder o.lig. Der vil også være mulighed for at der løbende bliver holdt øje med lagerstatus, og at der semiautomatisk bliver bestilt varer hos depotet, FSBM skal indover for at fastsætte tidspunkt for afhentning. Databasen: Databasen skal understøtte de andre funktionaliteter, og sikre FSBM en bedre oversigt over hans lager. Tidsplanlægning kommer til at foregå ved at Brugeren vælger de tidspunkter der passer ham og FSBM tager den der passer ham bedst. Det virker urealistisk at parterne kan holde en kalender der er opdateret nok til at der kan vælges tidspunkter ud fra det Reeksioner Vi har valgt at lave en Android applikation (se afsnit ), vi føler at dette design bliver det bedste til vores kunde. Det er baseret på elektroniske kopier af bestillingssedlen og er derfor nemt at sætte sig ind i. Ligeledes er der ere i otillen der har Android telefoner, herunder FSBM. En web udgave af applikationen vil sikre at folk uden en Android telefon også vil kunne få glæde af det. Webshop ideen mangler en logisk måde at inkorporere tidsplanlægning og det er et stort minus. Derudover går den bort fra det princip, at der bliver udfyldt bestillingssedler, som er velkendt for kunden. 27

30 Den nuværende webklient er for utilgængelig, brugerene bestiller oftest materiel hjem hjemmefra efter aftensmad 6, det ville være meget upraktisk for dem at skulle tage hen i otillens lokaler. Tidsbestillings princippet er heller ikke særligt eksibelt, FSBM skal holde tiderne i puljen fri fra andre aktiviteter. Android applikationen har været tidligt inde i vores bevidsthed i udviklingen, og det var svært for os at nde på andre ideer pga. dette. Det ville havde været godt for os, at vi ikke havde fået denne idé før vi var kommet til udviklingen af en vision. Vores valg i de forskellige faser kan derfor sagtens bære præg af at der allerede var en idé til designet og vi kan derfor have overset nogle pointer, det var også eget svært at nde på andre design ideer der var ligeså gode som denne, det ville sikkert have været nemmere hvis der ikke havde været nogle ideer inden Storyboards Vi har udviklet tre storyboards til at vise hvordan vores valgte system kommer til at fungere i forhold til forskellige opgaver. Disse opgaver har vi valgt ud fra en vurdering om, at de er fundamentale i systemet, man kan også se, at det er de samme opgaver som vi har fokus på i vores sekvens modeller (se afsnit 4.2.2), og det er de opgaver som vi har haft mest fokus på igennem hele designforløbet. FSBM har også lagt vægt på at det er disse opgaver der vil hjælpe ham mest i sit arbejde Bestilling Det første storyboard omhandler en bestilling af materiel fra en bruger. Vi ser i dette storyboard, gur 4.9, at brugeren foretager en bestilling på sin smartphone. Den store forskel på det nye system og det gamle er at det hele kun kan foregå på en måde, vi har elimineret risiko for fejludfyldning af felter og der behøves ikke at være direkte kontakt med FSBM, denne sender en godkendelse når han får set det igennem. 6 FSBM prøvede at logge ind på hjemmeværnets interne hjemmeside under vores første forsøg, og det gik meget langsomt 28

31 Figure 4.9: Storyboard, Bestilling med det nye system Vi har ikke i dette storyboard medtaget en tidsplanlægning. Selvom vi var klar over at tidsplanlægning var en stor fordel at få lavet i systemet, havde vi valgt at ikke have så meget fokus på det, da vi var bange for at det ville blive meget tidskrævende at få lavet en hi- prototype med denne feature, men efter senere kontakt med FSBM valgte vi at inkorporere det i vores papirprototype (se afsnit 4.3.1) og vores hi- prototype (se afsnit 4.3.2) Udlevering af materiel Det andet storyboard omhandler det næste trin, der er nu aftalt tid og accepteret bestilling og brugeren er nu mødt op i otillens lokaler. Der er i dette scenarie en interaktion mellem FSBM og vores system eller brugeren. FSBM får hjælp af systemet til at liste materiel og scanne og skrive kvitteringer ud. 29

32 Figure 4.10: Storyboard, Udlevering af materiel med det nye system Den indscanning af materiel der er i storyboardet har vi ikke fået inkopereret i vores endelige prototype, se afsnit 4.3.2, vi har i stedet skiftet fokus til at få lavet et fornuftigt tids-planlægningssystem A evering af udlånt materiel Det sidste scenario der blev lavet er opgaven der opstår når materiel skal a everes tilbage, her er tale om både overskydende forbrugs materiel og udlånte varer. Det nye system bruges til at tjekke om alle tingene på listen er med. 30

33 Figure 4.11: Storyboard, A evering af lånt materiel med det nye system Der er ikke mange afvigelser fra dette storyboard og til vores endelige hi- prototype, se afsnit 4.3.2, opgaven er rimelig simpel og vi har prøvet at holde den simpel og e ektiv, der bliver oftest a everet alt tilbage umiddelbart efter øvelser og der kan derfor være mange udførsler lige efter hinanden Re eksioner Vi har haft god gavn af vores storyboards, vi har dog imod den normale måde at lave storyboards i kontekstuel design, vores UI meget med i billederne, det var ikke så relevant at se aktørerne stå og bruge sin mobil, dette gælder især i det første scenarie, (se afsnit ) hvor der kun er interaktion med vores system. Dette har vi kunne bruge til at diskutere den kommende brugergrænse ade i større detaljer. Storyboardene har alle været med til at give os en mere fælles forståelse af det kommende system, inden denne del af processen, har vi haft den samme generelle ide men der har været mange detaljer der ikke var de samme, dette problem var efter produktionen af storyboards og papir-prototypen, (se afsnit 4.3.1), næsten helt væk. 31

34 4.2.9 UED Næste skridt har været at vi skulle have lavet et UED, (se afsnit 2.2.7), UED skal hjælpe os med at give et fuldt overblik over vores design. 7 fokus områder, det er de samme operationer som der har været fokus på igennem Vi har valgt at have 3 det meste af vores design proces. Bestilling, modtagelse af bestilling og ud- a evering af materiel, se gur Bestillings-fokus omhandler bruger-siden af vores system, det er denne del som f.eks gruppeførere og delingsførere kan operere på. Funktionerne skal i dette fokus være: Udfyld bestilling, send bestilling, ret bestilling og slet bestilling, vi tilføjede senere se aktive udlån, da vi vurderede at det kunne være rart for brugeren at se hvad han skal a everer tilbage, så han ikke glemmer noget. Modtagelse af bestilling udgør sammen med ud- og indlevering FSBMs ade, her er der tale om behandling af de bestilling der bliver modtaget fra brugeren. Her er Funktioner som accepter bestilling, partiel accepter bestilling, afvis bestilling og se bestillinger. Ud- og indlevering af materiel er det sidste klart de nerede fokusområde, det fokuserer på at hjælpe med disse opgaver og automatisere noget af papirudfyldelsen. Funktioner under dette fokus er: Udlever materiel, modtag materiel, se udlånt materiel, se ønsket materiel og print forsyningsblanket. Se ønsket materiel omhandler at det skulle være tilgængeligt for FSBM at se hvor meget materiel der er ønsket i alt, både fra accepterede og ikke-accepterede bestillinger. Dertil kommer et fjerde fokus område, database, men vi valgte at vi ikke ville designe noget her da det er en meget stor opgave at begynde på. Databasen skal kunne styre mange ting og vil i et endeligt produkt være meget vigtigt for at få det hele til at fungere korrekt, den vil endvidere kunne hjælpe FSBM meget i hans normale lageradministration. Figure 4.12: UED Re eksioner Vi har ikke gjort meget brug af vores UED til noget særligt. Vi har ikke været helt tilfredse med vores udformning af UED'en, da vi har oprettet tre fokusområder, og i vores endelige produkt er der kun to 74 fokus områder med database fokus, som vi har valgt ikke at lave noget til 32

35 områder, Bestilling og administration af bestillinger. Dette ville i praktisk betyde at vi skulle have slået modtag bestilling og ud- aevering af materiel sammen til et fokusområde. Vi har haft for meget fokus på opdelingen i vores storyboards, (se afsnit 4.2.8) og sequence models, (se afsnit 4.2.2) og derfor overset at der for FSBM er tale om det samme fokus område. Når man ser på vores hi- prototype, (se afsnit 4.3.2), har vi fået oprettet de funktioner der er afspejlet i UED'en, og strukturen i vores system er den samme som UED, hvis vi laver et fælles fokusområde der dækker Modtagelse af bestillinger og ud- aevering af materiel. Så vores design er på trods af minimalt brug af UED'en kommet til at fungere. Hvis vi skulle bruge kontekstuelt design igen vil der skulle være mere fokus på at få lavet et godt UED, det er tydeligt at det er en god guideline til hvordan det endelige produkt kommer til at se ud, det er også en god rettesnor så man får alt det funktionalitet med som det er tænkt. Det er også et godt tjek op på om alle er på samme vej hvad designet angår. 4.3 Prototyping Første prototype Efter dataindsamling, workmodelling og arbejdet med at udvikle en vision for systemet, er det logiske næste skridt at udvikle en prototype. Før udviklingsarbejdet gik i gang på prototypen var vi i tvivl om hvilket medie vi ønskede at anvende. vi undersøgte ere systemer til prototyping/gui-programmering med den tanke, at det ville være lettere at bygge videre på en sådan prototype til vores hi- version. Vi fandt dog ikke noget system der kunne tilfredsstille vores krav, især ikke med hensyn til udviklingshastighed og derfor endte vi med at vælge en papirprototype. Selvom vi havde analyseret artefakter, owmodels, havde udviklet et anity diagram med FSBM og egentlig havde fulgt contextual design metoden efter bedste evne, så var visionen om det endelige system stadig noget uklar ved prototypeudviklingens begyndelse. Hvad der dog stod klart var, at vores system som minimum skulle bestå af to separate enheder, en bestillingsdel og en FSBM-del. Vores første skridt var at udvikle en skitse til prototypen og gennem denne skitse begyndte vi langsomt at få en klarere idé om hvordan vores design skulle se ud, hvilke funktioner der var nødvendige og hvorfra der skulle være adgang til disse. Til den endelige prototype printede vi et antal ark med et billede af en HTC smartphone af samme type som FSBMs. Ud fra skitsen renskrev vi herefter den endelige prototype på de printede ark og numrede hvert ark. Vi forberedte prototypen til test ved at annotere knapperne, med nummeret på arket med den tilhørende funktionalitet. Selve udviklingen af prototypen tog ikke mere end halvanden dag, men betød at vi bagefter havde en væsentligt klarere vision af systemet vi var igang med at udvikle Evaluering af lo- prototype For at evaluere vores lo- prototype, inviterede vi FSBM til et møde i vores lokaler i Aarhus. Vi havde på forhånd klargjort et setup bestående af vores prototype som beskrevet, et opgave ark med re specikke opgaver som FSBM skulle forsøge at udføre ved hjælp af prototypen, samt en afslappet stemning. Fra starten sikrede vi os at FSBM var klar over forløbet og gjorde ham opmærksom på at al kritik var meget velkommen. De re scenarier han skulle gennemgå var som følger. Iteration fra "brugers" synsvinkel Iteration fra "bruger" 8 Her agerer FSBM almindelig bruger og gennemfører via vores prototyper en bestilling af 3 stk. GV og 500 skarpe skud. Han pointerer bla. at knapperne i bunden af skærmbilledet skal være 8 33

36 større og mere intuitive, ved. f.eks. at indeholde tekst og anvisninger. Det er en observation, vi naturligvis har inkorporeret i vores hi- prototype. Iterationer fra FSBMs synsvinkel Modtage og godkende bestilling 9 Denne del af evalueringen er fra FSBMs synsvinkel, hvor der er indløbet en bestilling, som den ovenstående. Vi ser her hvordan han håndterer det at skulle besvare brugerens ønskede tidsbooking og materielbestilling. Udlevering af en godkendt bestilling 10 Afsendelse af løbende bestilling til depotet 11 Disse interviews blev optaget på video, for at vi derefter kunne opstille et forsøg på det som Benyon skriver at Mackay et al. i 2000 beskriver som "Video Prototyping" [Benyon, 2010][s. 188]. Denne fremgangsmåde består af, at vi observerer mens vores aktør, her FSBM, gennemgår vores lo- prototyper. Dette optages på video, hvorefter vi lægger en animation af vores hi- prototype oven på videoen og som det ses på gur 4.13 så stemmer de to overens. Figure 4.13: FSBM gennemgår lo-, mens hi- vises at have samme opførsel Evalueringen havde til formål at bedømme hvorvidt det generelle workow i applikationen var anvendeligt for FSBM. Efter evalueringen var vi godt tilfredse med udbyttet, vi havde fået bekræftet at vores ow og generelle idé til udformningen af systemet passede overens med kundens ønsker. Samtidig havde vi fået opklaret en del tvivlsspørgsmål og klarlagt ere detaljer omkring FSBMs arbejde. Vi havde desuden fundet ere praktiske detaljer omkring opbygningen af vores interface der skulle rettes i en opdateret prototype. En ting vi også havde observeret var, at vores lo- prototype havde den ønskede virkning på FSBM. Prototypen lignede tilpas meget en mobiltelefon, så FSBM havde ingen problemer med at relatere til papirprototypen som et rigtigt system og det var tydeligt, at når der blev trykket på en knap på prototype,

37 kunne der ligeså godt være trykket på en rigtig telefon. Samtidig virkede prototypen dog også ufærdig nok, til at være noget man ville være bekendt at kritisere. Et eksempel på en af siderne i prototypen kan ses på gur En anden fordel ved papirprototypen var at vi løbende kunne rette detaljer og forevise forskellige ideer for FSBM, blandt andet havde vi to udkast til forsiden af FSBM-appen og ved hjælp af prototypen testede vi begge ideer og endte med at vælge en modiceret udgave af det ene udkast. Det at vi løbende rettede i prototypen, hjalp igen til at give FSBM indtrykket at designet på ingen måde var fastlagt og at hans mening betød noget for projektets udvikling. Figure 4.14: Side fra lo- prototypen Anden prototype Efter at have opnået et tilfredsstillende resultat og samtidig fået en endnu bedre forståelse for det færdige system, var vi kommet til at skulle udvikle en hi- udgave af vores prototype. Det havde længe været et faktum, at systemet skulle have et Android-interface både fordi ere otillemedlemmer var indehaver af en Android telefon, men også fordi udviklingsværktøjer var frit tilgængelige. For ere medlemmer af designgruppen var Android-mediet dog forholdsvis uudforsket. Vores intuition 35

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

Forelæsning den 31. marts 2003

Forelæsning den 31. marts 2003 Forelæsning den 31. marts 2003 1. Spørgsmål & Svar: (a) Aflevering af Delopgave 1 for Det Gennemgående Udviklingsprojekt udskydes én uge til 14.04.03; (b) Ingen forelæsning den 07.04.03 (c) De to konsoliderede

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

www.morten-rask.dk oktober 2001

www.morten-rask.dk oktober 2001 Opbygning af e-handelssystemer Implementering er en transformationsproces Agenda! Case: Det er nemt med Jubii Butik! Turban giver overblikket! Pernille Kræmmergaards fokus på ERP! Mortens model (igen)!

Læs mere

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF)

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF) Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Framework (TOGAF) Otto Madsen Director of Enterprise Agenda TOGAF og informationsarkitektur på 30 min 1. Introduktion

Læs mere

Projektevaluering. Caretech Innovation. Projekt Mobiladgang for læger og andet sundhedspersonale (C-47)

Projektevaluering. Caretech Innovation. Projekt Mobiladgang for læger og andet sundhedspersonale (C-47) 1 Projektevaluering Caretech Innovation Projekt Mobiladgang for læger og andet sundhedspersonale (C-47) Deltagere/partnere: Systematic A/S Regionshospitalet Randers og Grenå Caretech Innovation Dato: 8.

Læs mere

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

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

Læs mere

INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK

INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK Marianne Graves Petersen Associate Professor Computer Science Dept, University of Aarhus Center for Interactive

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

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

IT og Kommunikation. Workshop om planlægning af prototype forløb. 24.10.13 Rikke Okholm

IT og Kommunikation. Workshop om planlægning af prototype forløb. 24.10.13 Rikke Okholm IT og Kommunikation Workshop om planlægning af prototype forløb 24.10.13 Rikke Okholm Program Introduktion Tilgange og eksempler på metoder Workshop: Planlægning af prototypetest Brainstorm over jeres

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

Ole Gregersen 26. november 2009 IT Universitetet

Ole Gregersen 26. november 2009 IT Universitetet Ole Gregersen 26. november 2009 IT Universitetet Hvorfor er det relevant at arbejde med? 5 minutter med sidemanden Kvalitetsegenskab Risikostyring Oplevelsesdesign En kontrolleret designproces Et brugercentreret

Læs mere

Det erhvervsrelaterede projekt 7. semester. Projekt plan

Det erhvervsrelaterede projekt 7. semester. Projekt plan Det erhvervsrelaterede projekt 7. semester Projekt plan Titel på projekt: TAKSONOM: PETER KRISTIANSENS ARKIV (SKRIVES MED BLOKBOGSTAVER) Projektsted: LARM AUDIO RESEARCH ARCHIVE (SKRIVES MED BLOKBOGSTAVER)

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

Sketching & Prototyping, forår 2011

Sketching & Prototyping, forår 2011 Sketching & Prototyping, forår 2011 Heidar Al-Zaidi 2011 Heidar Al-Zaidi (281189 haza) Gruppe 9 Antal tegn:14.455 Link til refleksionsrapport: http://bit.ly/spr-haza Link til visuelt materiale: http://bit.ly/spr-haza2

Læs mere

Information til virksomheden om praktik på datamatikeruddannelsen

Information til virksomheden om praktik på datamatikeruddannelsen Information til virksomheden om praktik på datamatikeruddannelsen Kære virksomhed, Tak fordi du sammen med Cphbusiness vil være med til at færdiguddanne vores datamatikere. Her har vi samlet information

Læs mere

Materialeadministration Sidst opdateret 31-08-2006/version 1.0/Steen Eske Christensen

Materialeadministration Sidst opdateret 31-08-2006/version 1.0/Steen Eske Christensen Materialeadministration Sidst opdateret 31-08-2006/version 1.0/Steen Eske Christensen Indhold Ændringer Centrale begreber Generelt Arbejdsgange Vejledningen består af 3 dele, som kan læses hver for sig.

Læs mere

Første MFP-flotille er nu operativ

Første MFP-flotille er nu operativ jemmeværnet - Første MFP-flotille er nu operativ af 5 21-08-2014 14:50 HJEMMEVÆRNET Marinehjemmeværnet HJK > Marinehjemmeværnet > Nyheder > Første MFP-flotille er nu operativ Første MFP-flotille er nu

Læs mere

DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API

DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API Release 4.0.0 DaTelTek ApS Birkevej 4 DK-4640 Faxe Denmark CVR: 31 06 05 59 +45 32 22 22 22 www.dateltek.dk info@dateltek.dk Indholdsfortegnelse Ændring

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

Delaflevering FUA.4 Betina Korsbro, Mi Louise Hansen, Jesper Led Lauridsen og Knud Back

Delaflevering FUA.4 Betina Korsbro, Mi Louise Hansen, Jesper Led Lauridsen og Knud Back Delaflevering FUA.4 Betina Korsbro, Mi Louise Hansen, Jesper Led Lauridsen og Knud Back 1 Indhold 1.1 Generelt i forhold til projektet 1.1.1 Problemformulering Kalundborg kommune har gennem de senere år

Læs mere

Teknologianvendelse. - En overset ledelsesopgave. Af Christine Secher, Villa Venire A/S Marts 2013

Teknologianvendelse. - En overset ledelsesopgave. Af Christine Secher, Villa Venire A/S Marts 2013 Teknologianvendelse - En overset ledelsesopgave Af Christine Secher, Villa Venire A/S Marts 2013 Udviklingen i retning af smarte, selvbetjente it-løsninger accelererer overalt i frontlinien, hvor borgere

Læs mere

Henkel Norden AB ("Henkel") er en del af Henkel Corporation, og i henhold til DPA, er Jörg Heine, den dataansvarlige: schwarzkopf.dk@henkel.

Henkel Norden AB (Henkel) er en del af Henkel Corporation, og i henhold til DPA, er Jörg Heine, den dataansvarlige: schwarzkopf.dk@henkel. HENKEL FORTROLIGHEDSPOLITIK Vi, hos Henkel, tager vores forpligtelser i henhold til dansk lov om databeskyttelse (persondataloven) alvorligt og er forpligtet til at beskytte dit privatliv. Denne fortrolighedserklæring

Læs mere

EUROPOL JOINT SUPERVISORY BODY

EUROPOL JOINT SUPERVISORY BODY EUROPOL JOINT SUPERVISORY BODY Udtalelse 12/05 fra den fælles kontrolinstans for Europol om Europols anmeldelse af behandling af personoplysninger: Arbejdstider/flekstid/overarbejde/rådighedstjeneste/skifteholdstjeneste

Læs mere

Snapshots - Metodeworkshop med fart over feltet. Randers Sundhedscenter -tirsdag d. 17. marts 2009

Snapshots - Metodeworkshop med fart over feltet. Randers Sundhedscenter -tirsdag d. 17. marts 2009 Snapshots - Metodeworkshop med fart over feltet Randers Sundhedscenter -tirsdag d. 17. marts 2009 Anne Bøgh Fangel, projektleder Introduktion Bød velkommen og introducerede dagens forløb og projektets

Læs mere

Kom godt i gang med DanaShop

Kom godt i gang med DanaShop Kom godt i gang med DanaShop Tillykke med jeres nye webshop I din webshop fra DanaWeb findes der utroligt mange muligheder for at tilpasse den til lige netop jeres behov. DanaWeb har opsat alle shoppens

Læs mere

Sådan er fremtidens virtuelle arbejdsplads idag! Copyright 2011 Microsoft Corporation

Sådan er fremtidens virtuelle arbejdsplads idag! Copyright 2011 Microsoft Corporation Sådan er fremtidens virtuelle arbejdsplads idag! 5 tendenser der ændrer arbejdspladsen i fremtiden med IT. Giv dine medarbejdere Consumerization adgang til de applikationer af medarbejdere de har brug

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Termin 2013-2015 Institution Rybners Tekniske Gymnasium Uddannelse Fag og niveau Lærer(e) HTX Informationsteknologi B Jeppe Moritz Led Hold 3.E, Årgang 2012 Oversigt over undervisningsforløb

Læs mere

XMO Det handler om IT, der skaber værdi helt enkelt

XMO Det handler om IT, der skaber værdi helt enkelt XMO Det handler om IT, der skaber værdi helt enkelt OPLEV XMO Har du set videoen? På xmo.dk kan du se en kort video om XMO. Hvis du vil se mere, kommer vi gerne og viser systemet i din klinik. Se den på

Læs mere

PRINCE2 Certificeringsforløb. PRINCE2 Foundation PRINCE2 Practitioner. Knowledge that sets you apart

PRINCE2 Certificeringsforløb. PRINCE2 Foundation PRINCE2 Practitioner. Knowledge that sets you apart PRINCE2 Certificeringsforløb PRINCE2 Foundation PRINCE2 Practitioner PRINCE2 Certificeringsprogrammer Indhold PRINCE2 (Projects In Controlled Environments) er en procesbaseret tilgang til projektledelse,

Læs mere

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

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

Læs mere

Dagsorden. 1.Sidste nyt fra uddannelsen. 3.Markedsføring og deltagelse på uddannelsesmesser. 4.Praktik i efterårssemesteret 2009

Dagsorden. 1.Sidste nyt fra uddannelsen. 3.Markedsføring og deltagelse på uddannelsesmesser. 4.Praktik i efterårssemesteret 2009 Dagsorden 1.Sidste nyt fra uddannelsen 2.Valg Vl af formand for udvalget 3.Markedsføring og deltagelse på uddannelsesmesser 4.Praktik i efterårssemesteret 2009 5.Valg af faglige repræsentanter til udvalget

Læs mere

It-sikkerhedstekst ST9

It-sikkerhedstekst ST9 It-sikkerhedstekst ST9 Single Sign-On og log-ud Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST9 Version 1 Juli 2015 Single Sign-On og log-ud Betegnelsen Single Sign-On (SSO)

Læs mere

PLAN OG UDVIKLING GIS-STRATEGI 2012-2016

PLAN OG UDVIKLING GIS-STRATEGI 2012-2016 PLAN OG UDVIKLING GIS-STRATEGI 2012-2016 Indhold 1 INDLEDNING 3 2 STRATEGIGRUNDLAGET OG HANDLINGSPLAN 5 3 VISION 6 4 PEJLEMÆRKER OG PRINCIPPER 8 4.1 TEKNOLOGI 8 4.1.1 Principper 8 4.2 KOMMUNIKATION 9 4.2.1

Læs mere

EffEKTIvISER hverdagen AMPAREX brugervenligt OG InTEGRERET SOfTWARE TIl OPTIKERE Kunde håndtering KASSe (POS) MArKedSføring

EffEKTIvISER hverdagen AMPAREX brugervenligt OG InTEGRERET SOfTWARE TIl OPTIKERE Kunde håndtering KASSe (POS) MArKedSføring Effektiviser hverdagen AMPAREX brugervenligt og integreret software til optikere dtering Kunde hån S) KASSE (PO øring Markedsf DU BEHØVER IKKE VÆRE PÅ KONTORET FOR AT SERVICERE DINE KUNDER AMPAREX s unikke

Læs mere

Arbejdsformer i datalogiske forundersøgelser

Arbejdsformer i datalogiske forundersøgelser Arbejdsformer i datalogiske forundersøgelser Keld Bødker, Finn Kensing og Jesper Simonsen, RUC/datalogi Projektet foregår i et samarbejde mellem Danmarks Radio, H:S Informatik, WMdata Consulting A/S og

Læs mere

TESTPLAN: SENIORLANDS WEBSHOP

TESTPLAN: SENIORLANDS WEBSHOP TESTPLAN: SENIORLANDS WEBSHOP Indledning Vi vil i vores brugervenlighedsundersøgelse teste Seniorlands webshop 1. Vi vil teste hvor at webshoppen fungerer set ud fra en bruger af Internet. Vi vil blandt

Læs mere

Lederens ressourceoptimering

Lederens ressourceoptimering Lederens ressourceoptimering 44568 5S Sortere Sætte i orden Skure Standardisere Selvdisciplin 1 Derfor skal der indføres 5S Eksempler på forventede resultater ved succesfuld 5S implementering: Reducerede

Læs mere

STRØMLINING HÅNDTERING AF PAPIRPROCESSER I EN DIGITAL VERDEN

STRØMLINING HÅNDTERING AF PAPIRPROCESSER I EN DIGITAL VERDEN STRØMLINING HÅNDTERING AF PAPIRPROCESSER I EN DIGITAL VERDEN NOGLE AF DE BEDSTE MULIGHEDER FOR AT OPTIMERE WORKFLOWS FINDES, HVOR PAPIR OG DIGITALT MØDES Alle ved, at... DIGITALE PROCESSER STRØMLINER INFORMATIONSFLOWET

Læs mere

2013 SP1. Konfiguration af koncernindblik. Configuration Guide

2013 SP1. Konfiguration af koncernindblik. Configuration Guide 2013 SP1 Konfiguration af koncernindblik Configuration Guide Intellectual Property Rights This document is the property of ScanJour. The data contained herein, in whole or in part, may not be duplicated,

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

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England.

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England. Cookievejledningens Tekniske Guide Den tekniske guide beskriver fem skridt til overholdelse af cookiereglerne: 1. Fastlæggelse af webejendom 2. Undersøgelse af om der sættes cookies på hjemmesiden 3. Afgivelse

Læs mere

BACK-END OG DATA: ADMINISTRATION HVAD ER DE NYE MULIGHEDER MED VERSION 7.1? STEFFEN BILLE RANNES, 4. FEBRUAR 2015

BACK-END OG DATA: ADMINISTRATION HVAD ER DE NYE MULIGHEDER MED VERSION 7.1? STEFFEN BILLE RANNES, 4. FEBRUAR 2015 BACK-END OG DATA: ADMINISTRATION HVAD ER DE NYE MULIGHEDER MED VERSION 7.1? STEFFEN BILLE RANNES, 4. FEBRUAR 2015 SAS VISUAL ANALYTICS 7.1 ADMINISTRATOR Mulighed for at udføre handlinger på flere servere

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

PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER

PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER 1 INTRODUKTION 1.1 Formålet med Practitioner-eksamen er at give eksaminanden mulighed for at demonstrere forståelse af PRINCE2. Samtidig skal eksaminanden

Læs mere

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO...

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO... INDHOLDSFORTEGNELSE INDLEDNING... 7 Kristian Langborg-Hansen KAPITEL ET... 9 I gang med App Inventor Installation af App Inventor... 10 Trådløs installation... 11 Installation af emulator (Windows)...

Læs mere

App-strategi for Randers Kommune December 2012. Bilag 2: Procesvejledning for app-udvikling i Randers Kommune

App-strategi for Randers Kommune December 2012. Bilag 2: Procesvejledning for app-udvikling i Randers Kommune Bilag 2: Procesvejledning for app-udvikling i Randers Kommune Procesvejledningen har til formål, at skabe overblik over app-udviklingsprocessen, og skal sikre kvalitet og genkendelighed blandt apps ene

Læs mere

DayCare. CIM Care Systemer. Mere tid til børn og omsorg

DayCare. CIM Care Systemer. Mere tid til børn og omsorg DayCare CIM Care Systemer Mere tid til børn og omsorg CIM Care Systemer PPB Kommunikationsmodel Pårørende Tryghed Kommunikation Information Involvering Indsigt Borger Tryghed Information Hjælp til selvhjælp

Læs mere

DEN KOMPLETTE VÆRDIKÆDE MOBILITET SKABER VÆRDI FOR MOBILE MEDARBEJDERE

DEN KOMPLETTE VÆRDIKÆDE MOBILITET SKABER VÆRDI FOR MOBILE MEDARBEJDERE DEN KOMPLETTE VÆRDIKÆDE MOBILITET SKABER VÆRDI FOR MOBILE MEDARBEJDERE Læs mere på www.locus.dk LOCUS VÆRDI FOR MOBILE MEDARBEJDERE Locus makes mobility easy! Det er vores vision og leveregel. Vi leverer

Læs mere

Roskilde Tekniske Gymnasium. Eksamensprojekt. Programmering C niveau

Roskilde Tekniske Gymnasium. Eksamensprojekt. Programmering C niveau Roskilde Tekniske Gymnasium Eksamensprojekt Programmering C niveau Andreas Sode 09-05-2014 Indhold Eksamensprojekt Programmering C niveau... 2 Forord... 2 Indledning... 2 Problemformulering... 2 Krav til

Læs mere

FREMTIDENS SKOLESYSTEM. Baldersbækvej 2 2635 Ishøj Denmark +45 82 30 74 00 info@skemaintra.dk skemaintra.dk

FREMTIDENS SKOLESYSTEM. Baldersbækvej 2 2635 Ishøj Denmark +45 82 30 74 00 info@skemaintra.dk skemaintra.dk 1 Introduktion Der vil være en lettere elektronisk styring for alle lærere, elever og forældre. Det vil være et glimrende værktøj for alle på skolen Skolen vil kunne trække statistikker ud af systemet,

Læs mere

IntDesign - Kap 7. Kap 1.6.1 s. 20 - Usability goals

IntDesign - Kap 7. Kap 1.6.1 s. 20 - Usability goals IntDesign - Kap 1 Kap 1.6.1 s. 20 - Usability goals Usability goals are viewed as being concerned with meeting specific usability criteria, e.g. efficiency, whereas user experience goals are largely concerned

Læs mere

Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen

Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen Nets Denmark A/S Lautrupbjerg 10 P.O. 500 DK 2750 Ballerup T +45 44 68 44 68 F +45 44 86 09 30 www.nets.eu Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen

Læs mere

IKT programmer for Facilities Management. Vejledning for førstegangskøbere: Præsentation & debat

IKT programmer for Facilities Management. Vejledning for førstegangskøbere: Præsentation & debat DFM Workshop 05.10.09 09 IKT programmer for Facilities Management Vejledning for førstegangskøbere: Præsentation & debat Vejledning til systemkøberen Hvorfor en vejledning? Opbygning, highlights og vigtige

Læs mere

XProtect-klienter Tilgå din overvågning

XProtect-klienter Tilgå din overvågning XProtect-klienter Tilgå din overvågning Tre måder at se videoovervågning på For at skabe nem adgang til videoovervågning tilbyder Milestone tre fleksible brugergrænseflader: XProtect Smart Client, XProtect

Læs mere

REDEGØRELSE FOR OVERVEJELSER OG F ORSLAG VEDRØRENDE UDLEVERING OG OPBEVARING AF VÅBEN OG AMMUNITION TIL HJEMMEVÆRNSMEDLEMMER.

REDEGØRELSE FOR OVERVEJELSER OG F ORSLAG VEDRØRENDE UDLEVERING OG OPBEVARING AF VÅBEN OG AMMUNITION TIL HJEMMEVÆRNSMEDLEMMER. Redegørelse for overvejelser og forslag vedr. udlevering og opbevaring af våben og ammunition til hjemmeværnsmedlemmer. HJEMMEVÆRNSKOMMANDOEN 4. februar 2002 REDEGØRELSE FOR OVERVEJELSER OG F ORSLAG VEDRØRENDE

Læs mere

BullGuard Premium Protection... 2. Installation af BullGuard Premium Protection... 2. Ny BullGuard-bruger... 2

BullGuard Premium Protection... 2. Installation af BullGuard Premium Protection... 2. Ny BullGuard-bruger... 2 Indhold BullGuard Premium Protection... 2 Installation af BullGuard Premium Protection... 2 Ny BullGuard-bruger... 2 Hvis du allerede har produktet Internet Security 2013 installeret... 3 Aktiver Premium-tjenester...

Læs mere

Formål + ønsket resultat : Dagen gennemgås, så deltagerne er klar til at gå i kødet på opgaverne.

Formål + ønsket resultat : Dagen gennemgås, så deltagerne er klar til at gå i kødet på opgaverne. Drejebog, dagsforløb Herunder finder du en drejebog til et dagsforløb i Mobil Lab 3. Det er en drejebog for hvordan et forløb kan se ud, med 6 klokketimer til rådighed. Du har måske lidt mere eller lidt

Læs mere

Når du har logget dig ind, ser du Randers Kommunes byvåben midt på siden. I venstre side er der en række mapper:

Når du har logget dig ind, ser du Randers Kommunes byvåben midt på siden. I venstre side er der en række mapper: DXP vejledning Generelt: DXP er et værktøj til at fremstille præsentationsmaterialer (foldere, brochurer, løbesedler mv.) DXP egner sig kun til mindre brochurer og lign., da den største skabelon kan rumme

Læs mere

Indholdsfortegnelse. 1calendar ApS Kompagnistræde 20B, 1 th, 1208 KBH K, Denmark

Indholdsfortegnelse. 1calendar ApS Kompagnistræde 20B, 1 th, 1208 KBH K, Denmark Gymnasie håndbogen Indholdsfortegnelse Velkommen til 1calendar 2 Hvad er 1calendar? 3 Gymnasie kalender 3 Mobile applikationer 3 Online to-do 4 Lectio i din Outlook 4 Hvordan kommer vi i gang? 4 Hvad med

Læs mere

srum Fritidsaktiviteter 04-12-2008: 1. Semester. Multimediedesigner Projektstart: 17/11-2008 Aflevering: 4/12-2008

srum Fritidsaktiviteter 04-12-2008: 1. Semester. Multimediedesigner Projektstart: 17/11-2008 Aflevering: 4/12-2008 Gruppe 9: Besir Redzepi, Jacob Pedersen, Garwun Jeffrey Lai og Sean Rørgren srum Fritidsaktiviteter 04-12-2008: 1. Semester. Multimediedesigner Projektstart: 17/11-2008 Aflevering: 4/12-2008 Indholdsfortegenelse

Læs mere

Projektlederens guide til tilfredsstillende geoinformationsprodukter

Projektlederens guide til tilfredsstillende geoinformationsprodukter Projektlederens guide til tilfredsstillende geoinformationsprodukter Projektlederens guide er udarbejdet på baggrund af projektet: MobilGIS til natur- og arealforvaltere en web-baseret prototype. Projektet

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Termin 2014-2015 Institution Rybners Tekniske Gymnasium Uddannelse Fag og niveau Lærer(e) HTX Informationsteknologi B Jeppe Moritz Led Hold 2.E, Årgang 2013 Oversigt over undervisningsforløb

Læs mere

3OMSTILLING. Manual til 3Omstilling Webklient for brugere V2.0

3OMSTILLING. Manual til 3Omstilling Webklient for brugere V2.0 3OMSTILLING Manual til 3Omstilling Webklient for brugere V2.0 Indholdsfortegnelse 1. INTRODUKTION... 3 2. MINIMUMSKRAV FOR WEBKLIENT... 3 3. LOG IND... 3 4. HURTIGT OVERBLIK... 3 5. ÆNDRING AF STATUS...

Læs mere

Bestil selv teletaxi online

Bestil selv teletaxi online Bestil selv teletaxi online Sådan opretter du dig og sådan bestiller du I selvbetjeningssystemet, kan du: Se de kørsler du allerede har bestilt Bestille nye kørsler, når du vil Afbestille kørsler Betale

Læs mere

BEMAFD Pixiebog til jobsøgende

BEMAFD Pixiebog til jobsøgende BEMAFD Pixiebog til jobsøgende Tips til jobsøgning Ikke klassificeret Bemandingsafdelingen 19-12-2014 Tips til jobsøgning Denne Pixiebog er inddelt i nedenstående afsnit som du kan springe direkte til.

Læs mere

Installation og ibrugtagning af Geomagic Alibre Vault

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

Læs mere

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1 IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 1 AGENDA Hvem snakker? De betydende faktorer Agil forretningsudvikling D60 leverancemodel - Bedrock Opsamling og? 2 Hvem snakker?

Læs mere

Sag 61828-mho Udkast 06.05.2015. Cookiepolitik. 1. Politik for brug af HC Containers onlinetjenester

Sag 61828-mho Udkast 06.05.2015. Cookiepolitik. 1. Politik for brug af HC Containers onlinetjenester Sag 61828-mho Udkast 06.05.2015 Cookiepolitik 1. Politik for brug af HC Containers onlinetjenester På denne side oplyses om de nærmere vilkår for brugen af www.hccontainer.dk og eventuelle andre hjemmesider,

Læs mere

Problemstilling: Ordrestørrelsen bliver mindre men der kommer flere ordrer, der skal tastes

Problemstilling: Ordrestørrelsen bliver mindre men der kommer flere ordrer, der skal tastes Problemstilling: Ordrestørrelsen bliver mindre men der kommer flere ordrer, der skal tastes Har du overvejet andre muligheder for at modtage virksomhedens ordrer? Det kunne f.eks. være vha. EDI, XML eller

Læs mere

Rapport generator til Microsoft C5

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

Læs mere

OFFENTLIGT KMD A/S EJ 0.0 NUMMERERET SLIDE 1 CCM USER GROUP 20.11.2013. KMD einvoicing. v/ Ole Sixhøi

OFFENTLIGT KMD A/S EJ 0.0 NUMMERERET SLIDE 1 CCM USER GROUP 20.11.2013. KMD einvoicing. v/ Ole Sixhøi OFFENTLIGT SLIDE 1 CCM USER GROUP 20.11.2013 KMD einvoicing v/ Ole Sixhøi AGENDA SLIDE 2 INTRODUKTION KMD einvoicing - Baggrunden - Ydelsen DESIGN OG FUNKTIONALITET LOGISK FLOW ARKITEKTUR KMD E-INVOICING

Læs mere

Det bedste værktøj. er det der bliver brugt. RISMAstrategy

Det bedste værktøj. er det der bliver brugt. RISMAstrategy Det bedste værktøj er det der bliver brugt RISMA Vi er dedikeret til din succes Pålidelig rettidig information spiller en nøglerolle for succes i dagens omskiftelige forretningsverden. Samtidigt har vi

Læs mere

Effektivt samarbejde og videndeling via Organisatorisk Implementering af SharePoint

Effektivt samarbejde og videndeling via Organisatorisk Implementering af SharePoint Effektivt samarbejde og videndeling via Organisatorisk Implementering af SharePoint Louise Harder Fischer Ekstern lektor, CBS og Research Manager, Futurecom Business 3 vigtige pointer ved videndeling Viden

Læs mere

Sager på tværs. MOX giver sammenhængende processer på tværs af it-systemer

Sager på tværs. MOX giver sammenhængende processer på tværs af it-systemer Sager på tværs MOX giver sammenhængende processer på tværs af it-systemer 2 Sager på tværs Vil I gerne gøre det nemmere at sende dokumenter på tværs af jeres kommune? Så er MOX noget for jer! En kommune

Læs mere

Spiller / Pårørende manual Til www.kampseddel.dk

Spiller / Pårørende manual Til www.kampseddel.dk Spiller / Pårørende manual Til www.kampseddel.dk Brugervejledning for Spiller/Pårørende Kort om kampseddel.dk Kampseddel.dk er udarbejdet som et webbaseret værktøj til den frivillige Træner/Leder i en

Læs mere

Hvordan udarbejdes en strategi

Hvordan udarbejdes en strategi LENNART SVENSTRUP Hvordan udarbejdes en strategi LENNART@KYOEVAENGET.DK 2011 Strategi Alle kan udarbejde en strategi! MEN: For at en strategi er noget værd i praksis, skal den tage udgangspunkt i virkeligheden,

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

Forår 2012 - Firewalls

Forår 2012 - Firewalls Syddansk Universitet DM830 - Netværkssikkerhed Imada - Institut for matematik og datalogi Forår 2012 - Firewalls Forfatter: Daniel Fentz Johansen Alexei Mihalchuk Underviser: Prof. Joan Boyar Indhold 1

Læs mere

Vejledning til Autodesk Subscription Center

Vejledning til Autodesk Subscription Center Vejledning til Autodesk Subscription Center Udarbejdet af NTI CADcenter A/S maj 2013 Gå ind på internetadressen: http://subscription.autodesk.com som ser således ud: - Tast dit brugernavn og adgangskode

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

MEDARBEJDERSAMTALER Planorama 01-06-2015

MEDARBEJDERSAMTALER Planorama 01-06-2015 MEDARBEJDERSAMTALER Planorama 01-06-2015 1 Struktur i tilgang til medarbejdersamtaler, giver i Planorama indsigt i organisationens fremdrift på fokusområder og individuelle handlingsplaner. Udfordring

Læs mere

IDENTIFON. Emil Hauberg, Jakob Christoffersen, Ninette Nielsen og Senia Lundberg

IDENTIFON. Emil Hauberg, Jakob Christoffersen, Ninette Nielsen og Senia Lundberg Emil Hauberg, Jakob Christoffersen, Ninette Nielsen og Senia Lundberg 1 Indholdsfortegnelse side nr. 1. Forside. 2. Indholdsfortegnelse og indledning. 3. Problemformulering og afgræsning. 4. Tidsplan projektplan

Læs mere

Hjemmeværnets Lovpligtige Uddannelse

Hjemmeværnets Lovpligtige Uddannelse Hjemmeværnets Lovpligtige Uddannelse HVS UNR-0004 MAR 2013 Vi bidrager til forsvaret og beskyttelsen af Danmark med en troværdig og fleksibel kapacitet ved at levere militære, frivillige styrker, der tilgodeser

Læs mere

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets.

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets. Dagens program Har alle fået? Har nogen betalt for meget? Hav jeres koder klar Domæner change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog Hvad er widgets Hvad er

Læs mere

Impact værktøj retningslinjer

Impact værktøj retningslinjer Impact værktøj retningslinjer Værktøj fra Daphne III projektet IMPACT: Evaluation of European Perpetrator Programmes (Programmet for evaluering af Europæiske udøvere af krænkende adfærd) Impact værktøj

Læs mere

Det Naturvidenskabelige Fakultet. Introduktion til Blackboard (Øvelser) Naturvidenskabeligt Projekt 2006 Prøv at forske

Det Naturvidenskabelige Fakultet. Introduktion til Blackboard (Øvelser) Naturvidenskabeligt Projekt 2006 Prøv at forske Det Naturvidenskabelige Fakultet Introduktion til Blackboard (Øvelser) Naturvidenskabeligt Projekt 2006 Prøv at forske Indholdsfortegnelse Introduktion til Blackboard Content System...3 Øvelse 01 individuel:

Læs mere

Guide til Online tidsbestilling - en del af eportalen Revideret 26-06-2012

Guide til Online tidsbestilling - en del af eportalen Revideret 26-06-2012 Guide til Online tidsbestilling - en del af eportalen Revideret 26-06-2012 Indledning Med online tidsbestillingsmoduelt i Xdont, åbnes der for CGM s e-portal - kaldet Nembehandling.dk. Dette sted vil være

Læs mere

mytnt Quick Guide Enkel guide for mytnt-brugere mytnt - enkelt og hurtigt

mytnt Quick Guide Enkel guide for mytnt-brugere mytnt - enkelt og hurtigt mytnt Quick Guide Enkel guide for mytnt-brugere mytnt - enkelt og hurtigt Sådan tager du mytnt i brug 1. Gå til TNTs hjemmeside www.tnt.dk 2. Klik på linket send - mytnt i menuen til venstre 3. Opret dig

Læs mere

1. SEMESTER SYNOPSIS. Erhvervsakademi Aarhus. Kristian Peter Lund Drewsen E-konceptudvikling EKU-12d (1ek12d1) 1. Semesters Mundtlig Eksamen

1. SEMESTER SYNOPSIS. Erhvervsakademi Aarhus. Kristian Peter Lund Drewsen E-konceptudvikling EKU-12d (1ek12d1) 1. Semesters Mundtlig Eksamen E-konceptudvikling EKU-12d (1ek12d1) 1. SEMESTER SYNOPSIS Den 19 12-2012 Erhvervsakademi Aarhus 1. Semesters Mundtlig Eksamen 1. Semester Synopsis De tre opgaver der er beskrevet i denne synopsis er blevet

Læs mere

KLAR TIL KLYNGE FACILITATOR TRÆNING 2.0 3.-5. SEPTEMBER 2012 & 1.-3. OKTOBER 2012. REG X - Det Danske Klyngeakademi www.regx.dk

KLAR TIL KLYNGE FACILITATOR TRÆNING 2.0 3.-5. SEPTEMBER 2012 & 1.-3. OKTOBER 2012. REG X - Det Danske Klyngeakademi www.regx.dk KLAR TIL KLYNGE FACILITATOR TRÆNING 2.0 3.-5. SEPTEMBER 2012 & 1.-3. OKTOBER 2012 REG X - Det Danske Klyngeakademi www.regx.dk OM PROGRAMMET I dag betragtes udvikling af klynger som en af de vigtigste

Læs mere

Effektiv søgning på web-steder

Effektiv søgning på web-steder Effektiv søgning på web-steder 7. maj 1998 Udarbejdet af DialogDesign ved Rolf Molich, Skovkrogen 3, 3660 Stenløse Indhold 1. Indledning 3 1.1. Model for søgning 3 2. Forskellige former for søgning 4 2.1.

Læs mere

RSA Kryptosystemet. Kryptologi ved Datalogisk Institut, Aarhus Universitet

RSA Kryptosystemet. Kryptologi ved Datalogisk Institut, Aarhus Universitet RSA Kryptosystemet Kryptologi ved Datalogisk Institut, Aarhus Universitet 1 Kryptering med RSA Her følger først en kort opridsning af RSA kryptosystemet, som vi senere skal bruge til at lave digitale signaturer.

Læs mere

SKAB IDÉER. Et spil om lokalt iværksætteri

SKAB IDÉER. Et spil om lokalt iværksætteri SKAB IDÉER Et spil om lokalt iværksætteri SPILMANUAL FOR DIG, DER SÆTTER SPILLET I GANG GENERELT Spillet består af en spilmanual, en spilleplade og 13 øvelseskort. Derudover har du denne spilmanual, som

Læs mere

Mobilitet har fået nyt navn: CrossPad. Comwell Kolding den 9. april 2013

Mobilitet har fået nyt navn: CrossPad. Comwell Kolding den 9. april 2013 Mobilitet har fået nyt navn: CrossPad Comwell Kolding den 9. april 2013 it s a mobile first world I går Find hen til computeren I dag Der er en App til det Lokation Er ikke relevant Tid Er på min side

Læs mere

Fra User experience -l Fødevarer?

Fra User experience -l Fødevarer? Fra User experience -l Fødevarer? SUMMIT - konferencen København 22 maj 2013 Lars Bo Larsen Lektor, ph.d. Ins-tut f. Elektroniske Systemer Aalborg Universitet Oversigt 1. Hvad er User experience (UX)?

Læs mere

Online Banking Sikkerhedsvejledning PC-baseret version

Online Banking Sikkerhedsvejledning PC-baseret version Sikkerhedsvejledning PC-baseret version Indhold Introduktion til Sikkerhedsvejledningen...3 Sikkerhedsvejledningen...3 Sikker brug af internettet...3 Sikkerhedsløsninger i...3 Hvad er sikkerhed i?...4

Læs mere

Introduktion til den almen medicinske portefølje

Introduktion til den almen medicinske portefølje Introduktion til den almen medicinske portefølje Kære kollega. Den nye almen medicinske speciallæge uddannelse er i lighed med alle andre nye speciallæge uddannelser er målstyret dvs. en række mål eller

Læs mere