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

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