UDVIKLING AF SUPPORTSYSTEM

Størrelse: px
Starte visningen fra side:

Download "UDVIKLING AF SUPPORTSYSTEM"

Transkript

1 UDVIKLING AF SUPPORTSYSTEM Aalborg Universitet E2-214 INF2 2002

2 Gruppe E2-214 Side 2

3 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Department of Computer Science Aalborg Universitet Titel: Tema: Design og vurdering af et edb-system i samarbejde med brugere Projektperiode: Fra: 4. februar 2002 Til: 30. maj 2002 Gruppe: E2-214 INF2 Synopsis: Gruppemedlemmer: Casper Lykke Hansen Morten Sieker Andreasen René Møller Lauridsen Simon Ormholt Schrøder Rasmus Flyger Berg Andersen Henrik Villemann Nielsen Allan Sandal Hagelskjær Vejleder: Marianne Bangsø Oplag: 10 Sider: 115 Dette projekt omhandler udviklingen af et IT-system. Dette system skal effektivisere arbejdsgangene i supportafdelingen hos IT-virksomheden SAXoTECH. Samarbejdet med SAXoTECH har været omdrejningspunktet under udviklingen. Under udviklingen har vi gjort brug af en blanding af metoder. Vi har inddraget dele af Prototyping, OOA&D og Extreme Programming. Vi har anvendt de forskellige metoder i det omfang, vi har ment det var nødvendigt. Udfra metoderne har vi analyseret det eksisterende system og derudfra har vi lavet en prototype af det nye system efter udarbejdelsen af et design. Prototypen er testet for brugervenlighed hos brugerne ved SAXoTECH. Ud fra vores test kunne vi se, at brugerne helt klart mente, at det nye system var bedre end det eksisterende. Testen viste dog også at der var mange ting der skulle forbedres. Samarbejdet med SAXoTECH har været essentielt for udviklingen af prototypen. Vi har lavet en Prototype, som løser de grundlæggende problemer fremsat af SAXoTECH. Der mangler dog meget funktionalitet inden man kan sige, at programmet er klar til introduktion i firmaet. Vi har gennem samarbejdet med SAXoTECH fået erfaringer i, hvordan det er at arbejde for en kunde, hvilke vi kan drage stor nytte af i fremtiden. Alt i alt har dette semester været en meget positiv oplevelse. Side 3 af 115

4 Gruppe E2-214 Side 4

5 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 1 Forord Dette projekt er lavet over temaet Design og vurdering af et edb-system i samarbejde med brugere. Vi har valgt at lave et supportsystem som skal bruges i forbindelse med support hos firmaet SAXoTECH. Igennem projektet har vi haft forbindelse til supportafdelingen hos SAXoTECH. Vi vil i denne forbindelse gerne takke Torben Hoelgaard, Kim Skovgaard og resten af SAXoTECH s supportteam, for deres hjælp i at få dette projekt lavet. Hovedgruppen for denne rapport er primært den eksterne eksaminator, vores vejleder og supporterne hos SAXoTECH. Læsevejledning for denne rapport: Referencerne i denne rapport er skrevet i følgende format: [forfatter, sidetal, linie]. Mere specifikke oplysninger om referencen findes i litteraturlisten. Hvis andet ikke er angivet, betyder en kunde SAXoTECHs kunder, mens bruger betyder den endelige bruger af systemet, oftest supporterne. Der er vedlagt skærmbilleder af programmet (bilag 7), samt et implementationsafsnit (bilag 6). En CD er inkluderet med denne rapport og indeholder rapporten i følgende formater [*.pdf, *.doc, *.rtf]. Samtidig vil der være lydspor med vores test og selve programkoden (bilag 5). Aalborg Universitet, 30. maj Casper Lykke Hansen Morten Sieker Andreasen René Møller Lauridsen Simon Ormholt Schrøder Rasmus Flyger Berg Andersen Henrik Villemann Nielsen Allan Sandal Hagelskjær Side 5 af 115

6 Gruppe E2-214 Side 6

7 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Indholdsfortegnelse 1 FORORD INDLEDNING TEORI & METODE (GENERELT) PROTOTYPING OOA&D Analyse Design EXTREME PROGRAMMING Hvad er XP? Kunden i centrum Ledelse og planlægning Analyse Design Kodning Test Opsummering BRUGERVENLIGHED Den klassiske definition Katastrofer De fem gyldne regler Gestaltlove SYSTEMUDVIKLINGSFILOSOFI Hard Systems Thinking (HST) Soft Systems Thinking (SST) Dialectic System Thinking (DST) Sammenligning af HST og SST TEST Metodevalg Andre testformer Konstruktiv interaktion Observation TEORI & METODE (PRAKSIS) UDVIKLINGSMODEL Overordnet model Design Programmering Opsummering TEST Introduktion Formål Problemspecifikation Brugerprofil Metode Opgaveliste Testmiljø og udstyr Testlederens rolle Testkriterier BRUGERVENLIGHED I PRAKSIS Mål Udvikling Eksempel 1: Optimering af brugerfladen Eksempel 2: Brug af forbillede Eksempel 3: Brug af gestaltlove Side 7 af 115

8 Gruppe E Opsummering SYSTEMFILOSOFI PREANALYSE PROJEKTVALG VORES SAMARBEJDSPARTNER VORES FØRSTE MØDE MED SAXOTECH PROBLEMDEFINITION KRAVSPECIFIKATION SYSTEMDEFINITION ANALYSE BESKRIVELSE AF SUPPORT ARBEJDSRUTINER USE CASES FOR MODTAGELSE AF FEJLMEDDELELSE Telefonisk henvendelse Henvendelse via mail/osc DEN EKSISTERENDE BRUGERFLADE KLASSEDIAGRAM DELKONKLUSION DESIGN HÅNDTERINGEN AF OPKALD HÅNDTERINGEN AF MAILS HÅNDTERINGEN AF KUNDEOPLYSNINGER BRUGSSCENARIER Brugsscenarier for det nye system Vurdering KLASSEDIAGRAM FUNKTIONSLISTE SKITSE AF BRUGERFLADEN REVIDERET PROBLEMDEFINITION Revideret kravspecifikation Revideret systemdefinition EKSEMPLER PÅ NY BRUGERFLADE DET NYE DESIGN TESTRESULTATER VURDERING OG FORBEDRINGSFORSLAG UDFRA TESTRESULTATERNE Forbedringsforslag Vurdering udfra spørgeskemaerne DELKONKLUSION SAMARBEJDSDOKUMENT FILOSOFISK ANSKUELSE DELKONKLUSION VURDERING UDVIKLINGSMODEL TEST SAMARBEJDE KONKLUSION METODER PROGRAMMET ER KRAVENE OPFYLDT? TEST & RESULTATER Side 8

9 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 14.5 AFRUNDING LITTERATURLISTE BILAG & APPENDIKSOVERSIGT Side 9 af 115

10 Gruppe E2-214 Side 10

11 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 2 Indledning Vi har i dette projekt, udfra forskellige teorier og metoder om udvikling af software, beskrevet udviklingen af et stykke software til IT-virksomheden SAXoTECH. Det udviklede software har til formål at lette kommunikationen mellem supportere, interne udviklere og firmaets kunder. Dette er gjort gennem en proces, hvor Prototyping har været omdrejningspunktet. En ting der er kendetegnende for stort set alle former for software er, at der er mennesker der gennem deres arbejde eller på anden vis er afhængige af softwaren for at kunne udføre forskellige opgaver et program kan ikke kaldes en succes, om end det er programmeret efter den bedste praksis, hvis ikke brugerne er interesserede i at anvende det. Dette betyder, at man må inddrage fremtidige brugere i udviklingen af software, for at kunne målrette produktet mod de krav og ideer brugerne har. Men betyder dette, at man skal have alle de fremtidige brugere med under udviklingen for at kunne sikre at disse vil finde systemet tilfredsstillende? Dette ville hurtigt blive en uoverskuelig opgave, og det er her udviklingsmetoder kommer til deres ret. Disse forskellige metoder gør, at man i samarbejde med en gruppe af brugere, kan udvikle et stykke software, som i høj grad kan rettes mod samtlige brugere. Dette er en god grund til, at være interesseret i netop dette semesters temaramme som er: Projektenheden på INF2 har temaet Design og vurdering af et edbsystem i samarbejde med brugere. Semestrets formål er at udbygge og afrunde den studerendes grundlæggende kendskab til centrale datalogiske emnekredse med særlig fokus på interaktion med brugere i udviklingsarbejdet.[www.math.auc.dk/f-sn/infbach2001.html] 25/ Vi har gennem analyse og design af det eksisterende system kunnet lave, et system der i høj grad løser de kerneproblemer som blev fremsat af SAXoTECH. Dette er gjort i tæt samarbejde med ledelsen og brugerne i firmaet, hvilket har resulteret i en kørende prototype der med en samlet arbejdsproces kunne udvikles til et færdigt kørende system som kunne lette hverdagen for de ansatte hos SAXoTECH. Side 11 af 115

12 Gruppe E2-214 Side 12

13 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 3 Teori & metode (generelt) 3.1 Prototyping I det følgende afsnit vil vi gennemgå ideerne bag Prototyping. Bag langt de fleste af de kommercielle applikationer, der i dag findes på vore computere, ligger mange timers planlægning, afprøvning og diskussion. Helt præcist hvordan man har nået det færdige resultat, varierer i sagens natur i det uendelige. Dog har de næsten alle det til fælles, at de på et eller andet tidspunkt, har eksisteret som prototyper. Disse prototyper har repræsenteret forskellige elementer der, måske, måske ikke, er blevet implementeret i den færdige applikation. Softwarebranchen er benhård. Her kan man med rette bruge det darwinistiske udtryk "survival of the fittest." Det samme må ligeledes gøre sig gældende med udviklingen af prototyper. Vi kan vælge at betragte udviklingen fra prototype til applikation som et evolutionsforløb, hvor udviklerne, i skaberens rolle, afprøver forskellige løsninger. Her lever en prototype således i kraft af sine styrker indtil den må vige pladsen for en stærkere og mere succesfuld udgave. En, der er bedre egnet til overlevelse. Det er den stærkeste der overlever, når brugerne vender tommelen op eller ned. En prototype er et til dels udviklet produkt, som gør kunder og udviklere i stand til, at undersøge forskellige dele af et foreslået system og derigennem fastslå om det er egnet til det færdige produkt. [Pfleeger 2001] s. 51, l. 2. En prototype vil typisk starte på et planlægningsstadie, hvor den eksisterer udelukkende som tegninger på et papir, hvor hver tegning repræsenterer et skærmbillede. Herefter kan det være man arbejder hen imod en kombinationsløsning, der er baseret både på papir og computergrafik, inden man tager skridtet fuldt ud og sigter mod den elektroniske prototype, der i sidste ende gerne skulle resultere i en færdig applikation. Når man snakker om prototyper er der to måder, hvor på disse bliver udviklet og behandlet. Disse er; evolutionary og throw-away. En throw-away prototype er software der skal hjælpe udviklere til, at forstå forskellige problemer. Ligeledes bruges denne til, at få af- eller bekræftet om de forskellige løsningsforslag er berettigede i softwaren. En throw-away prototype er ikke udviklet eller beregnet til, at blive en del det endelige system. Dette vil med andre ord sige, at når prototypen har været brugt smides den væk og udviklerne tage de nye erfaringer og fører disse med over i et nyt system. Dette er dog ikke tilfældet ved den evolutionary prototype. Denne er ligeledes skabt til, at skabe forståelse for systemet, dog er forskellen at denne prototype skaber basis for det endelige system. [Pfleeger 2001] s. 169, l. 6. Det vil sige, at prototypen benyttes til at udvikle applikationen under hele udviklingsforløbet hen mod en færdig og fuldt funktionel applikation. Endvidere tillader den, at udvikleren løbende kan foretage ændringer på baggrund af tests og analyser. Alene det at diskutere begrebet "en færdig applikation" er vanskeligt, da det er de færreste applikationer, hvis udvikling nogensinde stopper. Selvfølgelig har de fleste applikationer en vis forventet levetid, som afhænger af flere faktorer, men gennem denne levetid foretages der næsten konstant mindre ændringer i applikationen, fra udviklernes side. Ideen i at konstruere en prototype er muligheden for at teste denne for fejl, og lære af dem. Man er så i stand til at implementere forbedringer i forhold til testen, i en ny forbedret prototype. Sådan fortsætter man indtil prototypen, af udviklerne, bliver bedømt som værende klar til at tage springet fra prototype til færdig applikation. Herefter vil den være underlagt et vedvarende vedligeholdelsesarbejde fra udviklernes side, i takt med at fejl og forslag til forbedringer tages til Side 13 af 115

14 Gruppe E2-214 efterretning. Man kan lave interne tests, hvor det er udviklerne selv, der tester applikationen. Endvidere kan man lade personer fra målgruppen deltage i forsøgene for at se om applikationen taler det "rigtige sprog." Der er både fordele og ulemper ved at bruge personer fra disse to grupper. De fleste vil jo nok mene, at udviklerne ikke har mulighed for at se objektivt på applikationen selv. Derimod kan udviklernes viden i forhold til applikationen også udnyttes til at gå dybere ned i analysen af applikationen. Når man gør brug af personer fra målgruppen er der åbenlyse fordele, idet man her har et antal personer, som er i den gruppe applikationen er henvendt til. Endvidere har personerne ikke umiddelbart nogen viden om applikationen på forhånd og ingen tilhørsforhold, hvilket betyder, at de har mulighed for at være helt objektive. En ulempe kunne være, at det kan være svært at få personer uden for projektet til at leve sig helt ind i brugssituationen. Desuden kan man forestille sig, at disse personers engagement i testen eller forståelse af denne, ikke lever op til udviklernes ønske. Alt i alt kan man sige, at en prototype er fornuftig måde til, at teste en applikation gennem hele udviklingsforløbet. Prototypen er under hele processen i konstant udvikling gennem en iterativ proces hvor der foretages tests og revurderinger af design og funktionalitet. 3.2 OOA&D Dette afsnit er skrevet ud fra bogen Objekt Orienteret Analyse & Design [Mathiassen et. al]. Objekt Orienteret Analyse & Design (OOA&D) er en meget anvendt metode indenfor systemudvikling. Den mest basale byggesten i metoden er objekter. Disse bruges som beskrivende elementer, hvorved man får en større forståelse af problemområdet. Endvidere bruges begrebet hændelser til, at beskrive interaktionen mellem de forskellige objekter. Da objekterne og hændelserne kan være meget omfattende samles de i klasser, hvorved man ikke længere kigger på det enkelte objekt, men i stedet abstraheres disse. Herved får man en beskrivelse af en samling objekter med samme struktur, adfærdsmønster og attributter. Fordelen med dette er, at man herefter kan lave en klassestruktur der giver et godt og fornuftigt overblik over problemområdet. Der er samtidig en tæt sammenhæng mellem objektorienteret analyse, design og programmering. OOA&D analysen er en kombination af følgende: Problemområdet: Den del af omgivelserne, der administreres, overvåges eller styres ved hjælp af et system. [Mathiassen et.al. 2001] s. 6 l. 27 Anvendelsesområde: En organisation, der administrerer, overvåger eller styrer et problemområde. [Mathiassen et.al.2001] s. 6 l. 29 Side 14

15 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Analyse I bogen, Objekt Orienteret Analyse og Design, beskrives disse tre punkter som værende formålet med et analyse og design dokument [Mathiassen et.al.2001] s.3, i tabel.. At aftale krav til et edb-system. At designe et edb-system uden væsentlige usikkerheder. At forstå et edb-system, dets omgivelser og vilkårene for dets realisering. Det er grundlæggende punkt 1 og 3 vi beskæftiger os med her i analysen. Nemlig det at lave en kravspecifikation i samarbejde med brugeren og analysere deres nuværende anvendelses og problem område, så vi får en bedre indsigt i, hvilke rammer vi skal bygge vores nye system op om. Systemdefinition Det første der gøres i OOA&D er at lave en systemdefinition, hvilket er en kortfattet og præcis beskrivelse af et system udtrykt i naturligt sprog. I systemdefinitionen vil der stå, hvad systemet skal indeholde informationer om, hvad det skal kunne og hvor det skal bruges, samt hvilke betingelser der gælder for udviklingen. Den systemdefinition der udarbejdes skal være med til bevare overblikket igennem resten af analyse- og designarbejdet. I forbindelse med systemdefinitionen i OOA&D, bliver der indført kriterium for dennes indhold. Disse bliver beskrevet i et såkaldt BATOFF-kriteriet, som står for Betingelserne, Anvendelsesområde, Teknologi, Objekter, Funktioner og Filosofi. Problemområde En af de første ting der skal analyseres i analysedelen er selve problemområdet, det vil sige den del af omgivelserne der administreres, overvåges eller styres ved hjælp af et edb-system. Opgaven er at se på problemområdet og brugernes forståelse af dette. Derfor nøjes man med, at observere det der sker. Målet med en analyse af problemområdet er, at kunne opstille en model for det der sker. Ud fra denne er det så være muligt, at designe og implementere et system der kan behandle, kommunikere og præsentere information fra problemområdet på en effektiv måde. Det er vigtigt, at analysen af problemområdet danner et overblik, i stedet for en masse beskrivende detaljer der kan være med til, at forvirre og ødelægge overblikket. Noget af det første man beskæftiger sig med i analysen af problemområdet er, at udvælge, hvilke objekter og hændelser der skal med i modellen. Som nævnt i den indledende del af dette afsnit bliver objekterne og hændelserne klassificeret i klasser, og de klasser systemet skal bevare informationer om bliver udvalgt. Endvidere skal disse klasser være med til, at definere og afgrænse problemområdet. En anden del i analysen af problemområdet er struktur aktiviteten, hvor der sættes fokus på sammenhænge mellem klasser og objekter. Dette gøres for at forstå de abstrakte, generelle sammenhængen mellem klasser og de konkrete sammenhænge mellem objekter. Opgaven i klasse aktiviteten er at udvælge klasser til modellen og karakterisere deres hændelser. I strukturaktiviteten skal denne beskrivelse udvides ved at tilføje strukturelle relationer mellem klasser og objekter. Side 15 af 115

16 Gruppe E2-214 Den sidste aktivitet under analysen af problemområdet er, at kigge på adfærdsaktiviteten. Her bliver beskrivelsen af klasserne i klassediagrammet udvidet ved, at der bliver tilføjet en beskrivelse af adfærdsmønstret og attributter for hver klasse. Desuden resulterer dette i et tilstandsdiagram for hver klasse. Anvendelsesområde Efter at have analyseret problemområdet, skal anvendelsesområdet analyseres, dette hænger tæt sammen med analysen af problemområdet. Formålet med analysen af anvendelsesområdet er at definere de krav, der er til systemets model og at formulere krav til funktioner og grænseflade. Det er i analysen af anvendelsesområdet at brugsmønstrene bliver lavet. Disse er med til at opnå et relevant fokus og abstraktionsniveau. I brugsmønstrene beskrives aktørerne, hvilke er personerne og andre IT-systemer, der anvender systemet. At opstille brugsmønstre er en svær aktivitet, da det kræver samarbejde mellem brugere og udviklere. Det er kunden der formulerer deres behov og bidrager derigennem med deres indsigt i anvendelsesområdet, mens det er udvikleren der formulerer brugsmønstre og bidrager med teknisk indsigt. I anvendelsesområdet bliver funktionerne som systemet skal indeholde også beskrevet. Der bliver i denne del af analysen opstillet en komplet liste af funktioner samt detaljerede specifikationer af de komplekse dele. Udfordringen ved funktionsaktiviteten er at vælge hvilke funktioner der skal være med i systemet. Det er også i anvendelsesområdet at grænsefladen bliver beskrevet, da det er denne der bruges af aktørerne (brugerne) til at interagere med systemet. Grænsefladen er delt op i to dele; brugergrænsefladen, hvilket er den del brugerne bruger, og systemgrænsefladen, hvilket er grænsefladen til andre systemer. Analysen af disse grænseflader skal føre til en komplet beskrivelse af både brugergrænseflade- og systemgrænsefladeelementer. Det er i denne del af analysen ikke nødvendigt at gå for meget i detalje omkring de forskellige grænsefladeelementer. Men i stedet skal dialogformen og præsentationsformen beskrives sammen med en liste af alle brugergrænsefladeelementer. Analysen af brugergrænsefladen hænger meget sammen med de andre dele af analysen fra både problemområdet og anvendelsesområdet. Side 16

17 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Design I OOA&D s designdel skal man designe den arkitektur som systemet skal bygges op efter. Ideen med denne arkitektur er, at systemet deles op i mindre dele som skal opfylde bestemte designkriterier. Designdelen i OOA&D lægger meget op til, at designet skal leve op til de krav, der formuleres i analysedelen. Noget af det første man derfor gør i designet, er at opstille en liste over de designkriterier for kvalitet, som systemet skal overholde for, at man kan kalde det for et godt design. Ved OOA&D sker denne prioritering af designkriterier ved at opstille en checkliste med dem, hvor man kan vælge hvilken prioritet et designkriterium har. Det er også i designdelen at den tekniske platform bliver defineret, da det har betydning for hvor mange resurser et program må bruge. Det er ligeledes her udvikleren tager stilling til, hvilket programmeringssprog systemet skal designes i. En af hovedopgaverne i designdelen er at opstille en komponentarkitektur, da denne gør det lettere at forstå systemet og organisere designarbejdet. Komponentarkitekturen reducerer samtidig det samlede design til en række mindre komplekse opgaver. Når komponentarkitekturen skal opstilles, beskrives dette i et klassediagram, hvor komponenterne beskrives som pakker, og forbindelsen mellem dem som afhængigheder. Det diagram, der kommer ud af denne komponentarkitektur, kan mange gange se meget enkelt og trivielt ud, men til gengæld tvinger designet af komponentarkitekturen udviklerne til at tænke over de enkelte komponenters ansvar. Ideen med at lave en komponentarkitektur er, at lave en sammenhæng mellem de krav der er fundet frem til i analysedelen og de tekniske muligheder. To af de væsentlige komponenter der bliver designet er model- og funktionskomponenterne. Modelkomponenten skal indeholde hvordan klasserne i systemet repræsenteres, mens der i funktionskomponenten står beskrevet hvordan funktionerne i systemet skal implementeres. Side 17 af 115

18 Gruppe E Extreme Programming En utraditionel, kontroversiel og forholdsvis ny metode til udvikling af software er Extreme Programming (XP). XP vender op og ned på de traditionelle udviklingsmetoder, og den har både modstandere og tilhængere. En af pionererne inden for XP er Kent Beck, og det er [Beck 2000] der er grundlag for dette kapitel. Metoden er specielt velegnet til små eller mellemstore udviklingsgrupper, der arbejder med skiftende systemkrav. XP er opstået i en erkendelse af traditionelle udviklingsmetoders begrænsninger. Selvom man i årevis har anvendt mere og mere udviklede varianter af dem, støder man igen og igen på de samme problemer:?? Tidsplanen holder ikke og afleveringsfrister udskydes?? Projekter aflyses inden de når produktionen?? Systemet bliver i tiltagende grad kaotisk?? Systemet indeholder for mange fejl?? Systemet svarer ikke til kundens behov?? Systemet indeholder mange irrelevante eller ubrugelige funktioner, der måske var sjove at programmere men ikke understøtter kundens forretningsbehov.?? Kravene ændres undervejs og det er ikke muligt at implementere dem Endvidere er de almindelige udviklingsmetoder ikke særlig motiverende for udviklerne. Beck hævder, at den traditionelle opbygning af et udviklingsforløb strider imod programmørens natur. Derfor forsøger man i XP at vende udviklingen på en måde, der er naturlig, spændende og produktiv for udviklerne, samtidig med at kundens behov er i centrum Hvad er XP? Ifølge [Beck 2000] s. xvii er XP en effektiv, letvægts, lav-risiko, fleksibel, forudsigelig, videnskabelig og sjov måde at udvikle software på. Dens væsentligste karaktertræk er:?? Hurtig, konkret løbende feedback fra små udviklings cyklusser?? En trinvis planlægningsprocess, hvor der hurtigt udvikles en plan for hele projektets levetid?? Evnen til fleksibelt at planlægge implementationen efter skiftende forretningsbehov?? Løbende tests skrevet af både udviklere og kunder er med til at fange fejl tidligt?? Vægt på mundtlig kommunikation og test, samt program kode der er selvforklarende med hensynt til funktion og program struktur?? En evolutionær design proces der varer lige så længe som systemet?? Vægt på tæt samarbejde mellem programmører?? Vægt på arbejdsprocedurer der både stemmer i overens med programmørernes instinkter og projektets langtidsinteresser. Side 18

19 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Kunden i centrum Som med alle andre udviklingsmodeller er det ultimative mål med XP, at kunden er tilfreds med den software, der bliver udviklet. Forskellen i forhold til traditionel software udvikling er, at kunden inddrages intensivt. Projektgruppen består således ikke blot af udviklere og en projektleder, men også af en repræsentant fra kunden, der har indblik i det pågældende system bliver et permanent medlem af holdet. Kundens opgave i projektgruppen er, at fremlægge de behov og krav, som systemet skal efterleve. Kontaktpersonen skal løbende besvare de spørgsmål, som udviklerne støder på. Det medfører, at man sjældent vil løbe ind i en blindgyde i systemudviklingen. Det er fuldt legalt for kunden, at ændre systemkravene midt i udviklingen, faktisk opfordres denne til det. Opgaverne i udviklingen fordeles ved hjælp af såkaldte CRC-kort. CRC står for class, responsibility and colalaborators, hvilket på dansk kan oversættes til: Klasse, ansvarlighed og samarbejde. Hvert kort indeholder en historie, der beskriver en konkret opgave, som systemet skal løse. Den kan både være formuleret af en udvikler eller en bruger af systemet. Ved gruppemøder, hvor både udviklere, kunden og brugere er tilstede, gennemgår man historierne og udvælger dem, der umiddelbart vil tilføre systemet den største merværdi. Merværdi er her defineret som de funktioner, der forretningsmæssigt vil betyde mest for det endelige produkt. Det er også ved denne brainstorm, at systemet deles op i klasser, objekter, og sammenhængen mellem dem bestemmes. Når man har prioriteret opgaverne fordeles de, og hver enkelt udvikler vurderer, hvor lang tid opgaven vil kræve. Dette er essentielt, da det i høj grad er med til at fremme realistiske tidsplaner, når den enkelte udvikler selv kommer med overslaget. I mere traditionelle softwareudviklings metoder anvender man kun CRC-kort, i den indledende fase af projektet. I XP anvendes de gennem hele projektet. Det medfører et fleksibelt forhold til nye systemkrav, og derudover er det også en god måde at dokumentere de beslutninger, der blev vedtaget ved mødet. Det er vigtigt at holde en vis disciplin ved møderne, så man anvender tiden effektivt. Jo flere personer der deltager i møderne, jo flere bliver inddraget i udviklingsprocessen Ledelse og planlægning Projektlederens rolle er at sørge for, at de langsigtede mål overholdes. Han skal ikke fordele opgaverne men påpege, hvad der skal laves. Endvidere skal han på alle måder hjælpe udviklerne med at levere et stykke kvalitetsarbejde. Den overordnede tidsplan er yderst begrænset. I stedet følger den detaljerede planlægning de forskellige releases af systemet, hvilket kunne være intervaller på 1-4 uger. Kunden vælger den release der har den største anvendelighed set i et forretningsperspektiv. Hvilket betyder, at kunden altid ved hvad han får. En vigtig del af organisationen er, at ingen personer ejer et stykke kode. Alle har ret til at ændre i al kode. Side 19 af 115

20 Gruppe E Analyse Analyse fasen er meget vigtig i XP, det er her kunden (som regel den fremtidig bruger af systemet) der beskriver, hvad systemet skal indeholde og kunne. En af de første ting der sker er, at kunden nedskriver et sæt af user stories. En user story kan sammenlignes med en use case i andre udviklingsmetoder. I user stories står der de refleksioner kunden har haft over, hvordan det fremtidige system skal fungere. Når user stories er udarbejdet kan der laves en projektplan. Dette starter med, at udviklerne laver en fælles vurdering over, hvor lang tid det vil tage, at implementere systemet. Denne tidsplanlægning bliver inddelt i mindre dele, alt efter behov. De planlagte tidsintervaller vil altid kunne ændres, hvis det er nødvendigt Design Design delen i XP er stærkt nedprioriteret i forhold til andre udviklingsmodeller. I hvert fald, hvis man opfatter design på den traditionelle måde. Der lægges ikke meget vægt på design, da man ønsker, at udvikle et brugbart system så hurtigt som muligt. Derfor udvikles og ændres designet løbende gennem projektet. Det er naturligvis fortsat nødvendigt at skabe et overblik over et endeligt system, men dette overblik skabes ikke ved hjælp af et stort design dokument. Det er i orden, at man på forhånd har en ide omkring, hvordan man vil implementere en bestemt del af systemet. Denne form for små-design opmuntres man rent faktisk til i XP. Målet er, at gøre hele projektet og systemet mere fleksibelt, så ændringer er mulige. Det centrale begreb når man arbejder med design i XP er simpelhed. Alle strukturer og koder tilstræbes at være så simple som overhovedet mulig, og det udvikles i en iterativ proces. Refactoring er en meget vigtig og stor del af XP metoden. Kort fortalt er det en måde, hvor man rydder op i kode ved at fjerne uoverflødige dele såsom ubrugte funktioner. Refactoring gør det muligt, at arbejde med voksende kode, uden en tilbundsgående beskrivelse af designet, som XP forsøger at undgå. Refactoring sørger ligeledes for, at programmører ikke holder sig til de forkerte ideer, da de bliver tvunget til at bruge simpel, ren og forståelig kode Kodning Kodeprocedurerne i XP adskiller sig fra de fleste andre udviklingsmetoder. Et af de mest kendte elementer i XP er parprogrammering. Mange sætter fejlagtigt lighedstegn mellem parprogrammering og XP. Dette er en grov forenkling. XP er som et korthus, hvor kortene er elementer som hyppig testning, brugerinddragelse og endda det fysiske arbejdsmiljø. Parprogrammering går ud på, at to udviklere arbejder sammen om udviklingen af et stykke kode. Den ene person skriver koden, mens den anden bevarer det kølige, overordnede overblik og fanger fejl i programmeringen. Dermed bliver kodens kvalitet angiveligt høj, og metoden styrker også udbredelse af kompetence udviklerne imellem. Hvis man anvender et rotationsprincip, er det også muligt, at alle medarbejdere bliver fortrolige med en meget stor andel af programmet. Tilhængere af XP påstår, at resultatet af par programmering er mindst det samme, som det to enkelte programmører kan nå at lave hvis ikke mere. Side 20

21 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Test Test er et af de vigtigste elementer i XP. Det er en forudsætning for det, onde tunger ville kalde kaotisk organisation. Det er testningen der muliggør programkode på et højt kvalitetsniveau. Man skelner inden for XP mellem to typer af tests, der dog er tæt relateret; unittest og acceptancetests. Almindelig unittestning udføres løbende og ofte. Dem der arbejder med et stykke programkode, tester det sideløbende med udviklingen. Ofte skrives testen faktisk før en eneste linie programkode er skrevet. Acceptance tests er derimod skrevet af kunden for at sikre, at deres behov dækkes. For at undgå at systemet bliver kaotisk og fyldt med fejl bliver der skabt og vedligeholdt en omfattende test suite, som køres efter alle ændringer i systemet. Hvis der opstår fejl, rettes de med det samme. Unit tests er en måde til at teste adfærden hos den enkelte klasse. Ved god XP praksis sætter en udvikler sig ned og overvejer, hvad formålet med den klasse, han er i færd med at skrive, er. Det er muligt at skrive unittests for enhver enkelt klasse i et system. Unit tests gør det meget nemt, at bygge god, funktionel og højkvalitets kode. Når en klasse ikke passer til en unit test ændres den. Et stykke kode vil aldrig blive integreret med det kørende system, før det er testet og virker fuldstændigt. I praksis skal kode dog integreres med systemet, så snart som det er muligt. Den anden form for tests i XP s udviklingsproces er acceptance tests. De er baseret på bruger fortællinger, der oversættes så de kan testes. Dette svarer på mange måder til black box tests. Det er irrelevant, hvordan systemet udfører opgaverne så længe resultatet er korrekt. Acceptancetests er et af målene med programmeringsindsatsen hos udviklerne. Den medfører ren og simpel kode, da unødvendige egenskaber viser sig i testen. Man ser fremad og kun ting der er nødvendige for den pågældende iteration bliver implementeret. Ved denne form for tests får kunden lige nøjagtigt, det de ønsker - hverken mere eller mindre. Når Refactoring er sket køres testene igen, og hvis det ikke fungerer et hundrede procent er der noget galt. En anden stor fordel er, at det kollektive ejerskab af kode gøres simplere. Med mange udviklere på det samme stykke kode er det rart, at have en nem måde til, at verificere den opdaterede kode. Ligeledes gøres den hyppige kode integration lettere af netop samme grund Opsummering Målet med XP er at opnå højere kvalitet og hastighed gennem en bedre forståelse af kundens behov. Det kræver en ny måde at tænke på. En del af procedurerne er dristige og vil kræve en del mod af både udviklere og ledelse at implementere. Andre vil blot kræve en mindre ændring. De central principper er tæt kundekontakt, hyppig test og simpelhed i implementeringen. Kontakten med kunden danner et startpunkt og et mål. Kunden er ikke bare den der skal betale for programmet og brugerne er ikke bare dem, der skal bruge det. Begge indgår aktivt og hyppigt i udviklingsprocessen. Et andet væsentligt princip er hyppig integration af kode. Integrationen skal ske sekventielt og ikke parallelt. På denne måde har systemet altid en problemfri og kørende version. Problemfri, fordi der ikke er nogle dele af softwaren der er integreret med andre. Således er det muligt at frigive en ny udgivelse, hver gang der er sket en integration med systemet. Side 21 af 115

22 Gruppe E2-214 Kollektivt ejet kode er et andet vigtigt princip. Herved forstås, at der ikke er nogen, der ejer en linie kode, men alle har mulighed for at ændre eller opdatere al kode. På denne måde opnår man på udviklingsholdet en kollektiv forståelse af arkitekturen, systemet og den underliggende teknologi. Idealistisk set burde programmørerne cirkulere rundt i teamet, således alle kommer til, at kode på alle dele af systemet. XP kræver dog også en vis disciplin. Eksempelvis kræver kodepraksis, at koden er selvdokumenterende. Dermed er yderligere dokumentation end selve koden principielt overflødig. Kodestandarder bør overholdes af alle involverede udviklere for, at opnå forståelig og ensformig kode. Side 22

23 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 3.4 Brugervenlighed Begrebet brugervenlighed anvendes ofte I forbindelse med udviklingen af IT-løsninger, men ofte defineres begrebet kun meget vagt. I dette afsnit ønsker vi at definere, hvad vi forstår ved begrebet brugervenlighed, når vi refererer til det i resten af projektet. Afsnittet er skrevet udfra [www.dialogdesign.dk] 23/05/02 samt [Molich 2000]. Hvorfor overhovedet beskæftige sig med brugervenlighed? Vi ønsker at udvikle et mere effektivt system end det, der anvendes i dag. Da brugervenlighed i høj grad er med til at forbedre samspillet mellem menneske og maskine, mener vi at det er en faktor, der ikke må undervurderes. Af yderligere fordele ved intuitivt opbyggede brugergrænseflader kan nævnes, at der kan spares tid på uddannelse, og flere brugere har umiddelbar mulighed for at benytte systemet. Der kan også afsættes færre ressourcer til support på systemet. Et brugervenligt design er med til at øge kundernes moral og motivation til at arbejde Den klassiske definition Rolf Molich definerer brugervenlighed på [www.dialogdesign] 25/05/02 til at være: Let at lære At noget er let at lære kan måles på indlæringstiden. Indlæringstiden: Den tid det tager brugere at lære at løse bestemte opgaver ved hjælp af systemet. Let at huske At noget er let at huske kan måles på genindlæringstiden. Genindlæringstid: Den tid det tager brugere, som har været væk fra systemet eller, som kun anvender det engang imellem, at løse bestemte opgaver. Effektivt at bruge Effektivitet: Den hastighed hvormed brugeren løser bestemte opgaver i forening med systemet. Effektiviteten afhænger bl.a. af svartid og fejlhyppighed og ikke mindst kvaliteten af fejlmeddelelser. Rart at bruge Subjektiv tilfredshed: Den tilfredshed som brugeren udtrykker i spørgeskemaer eller ved interviews. Ved udvikling af et brugervenligt IT-system må man afveje, hvilke af disse faktorer der er vigtigst i forhold til det pågældende projekt. Indlæring og genindlæring er eksempelvis meget vigtig i et system, som brugere kun anvender sjældent. Det kunne eksempelvis være et selvbetjeningssystem som en dankortautomat. Effektiviteten er derimod vigtigst i et system, som brugere anvender mange gange dagligt. Det kunne eksempelvis være et bogføringssystem. Side 23 af 115

24 Gruppe E Katastrofer Et andet mål for brugervenlighed i et system kan være antallet af "kritiske problemer" og "katastrofer". Der er tale om et kritisk problem i et system, hvis et eller flere af følgende kriterier er opfyldt: 1. Brugeren er ude af stand til at fortsætte sit arbejde uden at få hjælp fra en anden person 2. Brugeren føler, at systemets opførsel er stærkt irriterende eller irrationel. 3. Der er en kritisk forskel mellem det, som brugeren tror, at systemet gør, og det som systemet rent faktisk gør. Disse tre typer fejl kan findes under brugertests eller ved efterfølgende evaluering. En katastrofe optræder, når to brugere uafhængigt af hinanden støder på et kritisk problem. For at designe brugervenlige systemer, kan de fem "gyldne regler" også være en hjælp De fem gyldne regler 1. Kend brugerne Det er meget vigtigt at lære brugerne af systemet at kende. Nogle systemer har mange forskellige brugere, men her er det vigtigt at identificere de primære brugere af systemet. Ofte vil man som systemudvikler have en del kontakt med chefer og ledelsen, dem der skal betale for systemet, men det er ved kontakt med systemets brugere, at man får den nødvendige information og feedback. Af teknikker til dette kan nævnes interview, diskussion, eller man kan besøge brugerne på deres arbejdsplads og observere dem mens de arbejder. 2. Inddrag brugerne Tag typiske brugere med på råd lige fra projektets start. Typiske brugere har stor erfaring med hvad systemet skal kunne. Man skal ikke blot få brugere til at godkende et færdigt system, man skal få dem til at øse af deres erfaring under udviklingen af systemet. Hvis man arbejder sammen med de samme brugere gennem længere tid, risikerer man dog at de bliver eksperter, og ikke længere fungerer som realistiske brugere. En af de bedste metoder til inddragelse af brugerne er udvikling af prototyper med eksempler på realistiske skærmbilleder. Det er i høj grad med til at engagere brugerne, og det er lettere for dem at visualisere, hvordan systemet kommer til at fungere. Hvis brugerne kommer med kritik af en prototype, må man ikke være bange for at ændre på den eller helt kassere den 3. Afprøv og ret systemet Selv erfarne systemudviklere kan ikke forudsige hvor brugervenligt et system vil være. Afprøvning er derfor den eneste vej frem. Resultaterne af afprøvningen styrer det videre design. 4. Lær af andre Lad dig inspirere. Brugergrænseflader i fremmede systemer kan give en masse nyttig inspiration - om ikke andet så til at fastslå, hvordan man ikke vil gøre. Det vil ofte være en fordel at finde "forbilleder" - programmer der i funktion eller opbygning minder om ens eget. På denne måde kan man finde inspiration til mulige brugergrænseflader. Side 24

25 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere 5. Koordiner systemets dele Koordinering sikrer at du kan lave ændringer i de enkelte dele af brugergrænsefladen. Hvis afprøvningen af systemet medfører, at et ord i menuen må laves om, så sikrer koordineringen, at ordet også ændres i alle andre dele af systemet, f.eks. hjælp, dokumentation og fejlmeddelelser Gestaltlove Perceptionspsykologien beskæftiger sig med, hvordan vi opfatter helheder. Inden for denne gren af psykologien er man nået frem til en række såkaldte "gestaltlove 1, der beskriver hvordan man kan få oplysninger til at hænge sammen visuelt. Der er tre primære love. De betyder kort fortalt følgende:?? Loven om nærhed: Symboler anbragt nær hinanden opfattes som sammenhængende?? Loven om lukkethed: Symboler i samme "ramme" opfattes som sammenhængende?? Loven om lighed: Symboler der minder om hinanden opfattes som sammenhængende. Disse love kan anvendes til at designe brugergrænseflader, når man skal placere de forskellige elementer. Eksempelvis kan de anvendes ved placeringen af knapper, tekst og grafiske elementer. 3.5 Systemudviklingsfilosofi Dette afsnit omhandler en lille del af den filosofiske teori bag systemudvikling, som vi kan integrere med vores projekt. Systemudviklingsfilosofi er teoretisk meget omfattende, så vi har valgt at fremhæve de 3 grundlæggende tænkemåder; Hard, Soft og Dialectic systems thinking. Det er tre differentierede tænkemåder, som vi i et senere afsnit vil inddrage i forbindelse med beskrivelsen af projektudviklingen. Selvom disse tre tænkemåder er skrevet i metodeafsnittet, er de ikke deciderede metoder. De er nærmere ubevidste ideologiske regelsæt, der benyttes af udviklerne Hard Systems Thinking (HST) HST er en meget regelfast tænkemåde. At bruge HST betyder, at man ser alt som systemer, at alle systemer eksisterer, og at de kan analyseres og implementeres som et computerprogram. Det medfører, at man skal tænke meget abstrakt og se alle faktiske ting som systemer. Disse kan nedbrydes til mindre systemer, helt ned til de enkelte funktioner og elementer. Tesen er, at man først skal se hele det samlede system og retorisk spørge; hvad skal dette system kunne, når det er færdigt?. Svaret til dette skaber nye spørgsmål, som igen skal besvares og igen kan der opstå nye spørgsmål. Det kan fortsætte indtil man er på et niveau, hvor man kan besvare eller løse spørgsmålene med kendte programmérbare funktioner. Dette kaldes funktionel analyse og er effektivt, når der overvejes meget komplekse systemer. Efter analysen kan funktionerne sættes sammen til elementer eller mindre systemer og igen sættes sammen til et stort veldefineret, eksplicit og hierarkisk system. Denne metode gør det også nemt at vise data-flow mellem de enkelt elementer i systemet. 1 Gestalt = helhed Side 25 af 115

26 Gruppe E2-214 I bogen Computers in Context [Dahlbom et.al. 1993] sammenlignes dette med de matematiske og fysiske love og teorier, der gør det muligt at beskrive Jorden som et stort system, nedbrudt til og genopbygget fra de atomare partikler. Dette kan dog kun lade sig gøre, da HST ikke tager forbehold for eksempelvis æstetik, politik og kultur. Det vil sige mennesket, eller systemets bruger bliver meget passive med denne filosofi Soft Systems Thinking (SST) Med SST opstår der en ny systemopfattelse. Modsat HST er alle systemer ikke i forvejen fastlagte og eksplicitte. Systemet vil kun være et system inde i hovedet på den individuelle udvikler, og det er hans baggrund, oplevelser, interesser og uddannelse m.m. der spiller ind på vedkommendes opfattelse af systemet. Det vil sige, at hvis udviklerens opfattelse af verdenen omkring ham ændres, vil systemet også ændres. Systemets brugere spiller derfor en væsentlig rolle med SST. Det er vigtigt med SST, at alle individer i systemet har den samme opfattelse og fortolkning af et system. Når det er opfyldt, kan man begynde at lave en rationel analyse og efterfølgende udvikle et program. Programmet vil have brugerne i centrum, frem for HST der har programmet i centrum Dialectic System Thinking (DST) DST er baseret på ide om, at verden er i konstant forandring, og at man kun kan opfatte det ved at vide, hvad der forandres og hvorfor. På den måde kan man se modsætningerne og forskellene fra før og efter forandringen, samt forklare og forstå, hvorfor der er sket denne forandring. Det er netop her den nye viden og forståelse opstår. DST er let at bruge i et humanistisk, social og psykologisk system-sammenhæng, men bogen stiller selv spørgsmål til, om metoden overhovedet kan overføres til computersystemer: Since there are no actors or conflicts within a computer system, its only fair to question whether it makes sense to speak of contradictions within such a system [Dahlbom et.al. 1993] s Sammenligning af HST og SST Soft Systems Thinking Subjektivt System & sociologisk teori Fleksibel metode Fokus på organisatorisk problemløsning Analysen skal gøre systemet nemmere for brugeren. Organisatorisk produkt Systemet bliver kreativt og intuitivt Systemet kan komme med forskellige løsninger. Hard Systems Thinking Objektivt System og computervidenskabelig teori Fastlagt metode Fokus på teknisk problemløsning Analysen er videnskabelig og teknisk og systemet er domineret af analysen. Teknisk produkt. Systemet kommer med én korrekt løsning. Side 26

27 INF2-Projekt: Design & vurdering af et edb-system i samarbejde med brugere Med HST bliver organisationer og programmer opfattet som systemer med en overordnet funktion eller ide. Den meget tekniske analyse og problemløsning vil udmunde i et system, der er designet til optimal effektivitet og er præcis defineret på en måde, så systemet opfylder dets funktionalitet. Ulempen ved HST er, at brugerne ikke inddrages i analyse og udviklingsprocessen. SST vil derimod prøve at overføre fokus fra en generel, firkantet verdensopfattelse til en, der er mere individuel. SST henvender sig også til det humanistiske og sociologiske perspektiv i systemerne og prøver at inddrage disse. Hvilket vil resultere i et system, hvor brugerne har stor indflydelse på udviklingen og resultatet. Ulempen ved SST er, at produktet bliver et mindre effektivt system, samt at komplekse systemer og problemer bliver sværere at udvikle og designe. 3.6 Test Metodevalg Når man skal teste et system, er der mange forskellige faktorer, man skal overveje. Først og fremmest skal man overveje præcis, hvad det er man ønsker at teste. Man kan lave forskellige former for tests, der for eksempel er beregnet til at teste selve koden eller brugervenligheden. Man kunne også lave deciderede programtests for at teste selve koden. Vi har dog valgt ikke at gøre dette udfra den anskuelse, at dette semester i højere grad lægger vægt på interaktionen os og firmaet imellem. Hvis semestret i højere grad omhandlede kodning kunne man have lavet direkte kodetests. Derfor har vi valgt at koncentrere os om tests for brugervenlighed. Et tænke højt forsøg går ud på, at testpersonen udfører en række fastlagte opgaver alt imens han fortæller, hvilke overvejelser han gør sig. Det er meget vigtigt at registrere de ting, som testpersonen udtaler. Fordelen ved tænke højt forsøg i forhold til en række andre testmetoder er, at man får en række meget spontane overvejelser omkring det testede system. Når en testperson direkte fortæller sine tanker under testen, mener vi også, at der er mindre sandsynlighed for, at væsentlige informationer bliver glemt. For at lave en tænke højt undersøgelse, skal man udarbejde realistiske opgaver, som brugeren skal løse i det pågældende program. Man skal endvidere sørge for, at spørgsmålene dækker et så bredt aspekt af programmets funktioner som muligt. Det gælder altså om ikke kun at lave opgaver i funktioner, som man ved er programmets stærke sider. For at forhindre dette kunne man inspireret af XP skrive sine tests før man påbegynder programmeringen. Dette kunne gøres udfra usecases, som skal kunne udføres i det nye system. Man skal også opstille retningslinier for testens udførelse. Dette er især af betydning, når testen som i vores tilfælde udføres af de samme personer, som har udviklet det testede program. Eksempelvis kunne man forestille sig at en testleder, der selv har været med til at udvikle et system, vil have en tendens til at forsvare systemet. Derfor må man opstille nogle regler, som testlederen skal følge. Endvidere er faste retningslinier med til at give sammenlignelige resultater, og eventuelle resultatmæssige afvigelser må antages at skyldes programmet og ikke testen. Side 27 af 115

28 Gruppe E2-214 Når man kommer til udvælgelsen af deltagere i forsøget må man forsøge at få et repræsentativt udvalg af brugere. Her kan eksempelvis stilling og erfaring indgå i udvælgelsen. Man skal altså ikke udelukkende bruge erfarne eller uerfarne brugere men en blanding og gerne nogen på et mellemstadie. Det er vigtigt at testen ikke stilles op som en eksamenssituation, hvor testpersonerne føler, at det er dem der testes. Derfor bør man forsøge at etablere et afslappet testmiljø, der samtidig er så tæt som muligt på programmets realistiske anvendelsesområde. Testlederens opgave under selve forsøget er at sikre, at testpersonen ikke sidder fast i en bestemt opgave. Der kan kun gives hjælp, hvis det er yderst nødvendigt, og denne hjælp gives i form af ledetråde. Testlederen må altså ikke direkte hjælpe brugeren med at besvare spørgsmålet. Hvis brugeren stadig ikke kan løse opgaven, må testlederen vurdere, om det er nødvendigt at gå videre til næste spørgsmål. Vi har valgt at bruge disse retningslinier af flere grunde. På den ene side får vi mest ud af testen, når brugeren selv forsøger at løse opgaverne. Omvendt kan vi måske motivere testpersonen til at forsøge sig på en opgave lidt længere, hvis han får lidt hjælp. Dermed får vi sandsynligvis også en række interessante observationer omhandlende de problematiske dele af programmet. Man skal være opmærksom på, at lederen ikke ubevidst giver hjælp i situationer, hvor det ikke er nødvendigt, og at lederen ikke manipulerer testpersonen til at svare i en bestemt retning på nogle af spørgsmålene. Efter endt afprøvning er det vigtigt, at man bruger tid på at snakke med testpersonen for at få uddybet dennes opfattelse af systemet Andre testformer I det nedenstående afsnit vil vi gennemgå andre former for testmetoder. Vi vil lave en kort gennemgang af hver testform, hvor vi definerer formålet med testen samt fordele og ulemper ved testformen. Vi har udvalgt et par testformer, som vi mener kunne bruges i vores situation Konstruktiv interaktion Formålet med denne testform er, såvel som ved tænke højt test, at teste systemet for funktionalitet og hvorvidt det er intuitivt forståeligt. I sin grundform minder den konstruktive interaktion stort set om en normal tænke højt test. Der er det til forskel, at man ved konstruktiv interaktion i stedet for en testperson bruger to. Det er så meningen at de to testpersoner skal løse opgaverne i fællesskab. En af fordelene ved at benytte denne form for test er, at det i høj grad falder testpersonerne naturligt at tænke højt. Det betyder at hele testformen kan virke mere afslappet for testpersonerne da mange testpersoner tit vil føle, at det virker unaturligt at sidde og ytre deres tanker højt. En ulempe ved denne testform kan være, at de to brugere simpelthen ikke arbejder godt sammen og der opstår konflikter, som intet har med det system der testes at gøre. Man vil også kunne opleve, at testpersonerne ikke bryder sig om eventuelt at skulle vise over for kolleger at der er huller i deres viden. Endvidere er denne testform ikke nødvendigvis fordelagtig, hvis systemet ved almindelig brug skal bruges af enkeltpersoner. Side 28

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

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

Læs mere

Objektorienteret Analyse & Design

Objektorienteret Analyse & Design Objektorienteret Analyse & Design Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen og Jan Stage ISBN: 87-7751-153-0 Udgave: 3. udgave Udgivelsesår: 2001 Antal sider: 452 Pris: Kr. 410,00 På de

Læs mere

Brugervenlighed som en fast del af udviklingsprocessen

Brugervenlighed som en fast del af udviklingsprocessen Brugervenlighed som en fast del af udviklingsprocessen Ingrid Haug, 10. marts 2010 Hvorfor dette oplæg? Brugervenlige produkter opnås kun ved at arbejde målrettet med brugervenlighed Alt for sjældent er

Læs mere

Systemvalg. Oversigt og teknikker. Kapitel 2

Systemvalg. Oversigt og teknikker. Kapitel 2 Systemvalg Oversigt og teknikker Kapitel 2 1 Mathiassen, Munk-Madsen, Nielsen & Stage, 1997 Træd et skridt tilbage! Hvad skal der gøres? Hvad handler det om? Objektsystem Edb-system Bruger Problemområde

Læs mere

Introduktion til projekter

Introduktion til projekter Introduktion til projekter v. 1.0.3 Introduktion I dette materiale ser vi overordnet på, hvad projekter egentlig er, hvordan de er skruet sammen og hvilke begreber, som relaterer sig til projekter. Vi

Læs mere

Glasset er ikke halvt tomt, men halvt fyldt

Glasset er ikke halvt tomt, men halvt fyldt Glasset er ikke halvt tomt, men halvt fyldt Den anerkendende opfølgningsproces Pernille Lundtoft og Morten Bisgaard Ennova A/S Agenda 1 Introduktion (10:10 10:30) Lidt om anerkendende tilgang 2 ERFA og

Læs mere

kollegiekokkenet.tmpdesign.dk Side 1

kollegiekokkenet.tmpdesign.dk Side 1 kollegiekokkenet.tmpdesign.dk Side 1 Indholdsfortegnelse Forord 3 Problemformulering 4 Udviklingsmetode 5 Tidsplan 6 Målgruppe 7 Design brief 8 Logo 10 Typografi og farve 11 Navigationsdiagram 12 Usecase

Læs mere

Guide til din computer

Guide til din computer Guide til din computer Computerens anatomi forklaret på et nemt niveau Produkt fremstillet af Nicolas Corydon Petersen, & fra Roskilde Tekniske Gymnasium, kommunikation & IT, år 2014 klasse 1.2 12-03-2014.

Læs mere

Underbilag 14 C: Afprøvningsforskrifter til prøver og tests

Underbilag 14 C: Afprøvningsforskrifter til prøver og tests Underbilag 14 C: Afprøvningsforskrifter til prøver tests Udbud om levering, installation, implementering, support, drift vedligehold af Borgeradministrativt System (BAS) Indhold underbilag 14 C Afprøvningsforskrifter

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

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace har gennem de seneste 7 år arbejdet tæt sammen med mere end 250 af de mest lovende

Læs mere

BRUGERTESTEN Introduktion

BRUGERTESTEN Introduktion BRUGERTESTEN Introduktion BAGGRUND Når man udfører en eller flere brugertests gøres det ud fra en idé om brugerinddragelse. Brugerinddragelse handler om at forstå brugernes behov, motivation og adfærd.

Læs mere

persolog Personlig Mestringsrapport

persolog Personlig Mestringsrapport persolog Personlig Mestringsrapport Instruktioner til persolog Online Rapporter Personlig Mestring Oversigt over rapportelementer og bestillingsmuligheder: persolog online rapporter Personlig Mestring

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

Projektets karakteristika

Projektets karakteristika Projektets karakteristika Gruppeopgave Projektledelse DTU 1999 Projektets karakteristika Formål At give en karakteristik af projektets stærke og svage sider, som kan lægge til grund for den senere mere

Læs mere

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Programmering C Eksamensprojekt Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Indledning Analyse Læring er en svær størrelse. Der er hele tiden fokus fra politikerne på, hvordan de danske skoleelever kan

Læs mere

Læringsprogram. Talkonvertering. Benjamin Andreas Olander Christiansen Niclas Larsen Jens Werner Nielsen. Klasse 2.4. 1.

Læringsprogram. Talkonvertering. Benjamin Andreas Olander Christiansen Niclas Larsen Jens Werner Nielsen. Klasse 2.4. 1. Læringsprogram Talkonvertering Benjamin Andreas Olander Christiansen Niclas Larsen Jens Werner Nielsen Klasse 2.4 1. marts 2011 Fag: Vejleder: Skole: Informationsteknologi B Karl G. Bjarnason Roskilde

Læs mere

Systematisk arbejdsmiljøarbejde Drejebog til ArbejdsPladsVurdering - APV. De fire faser Drejebog til gennemførelse af APV i skovbranchen.

Systematisk arbejdsmiljøarbejde Drejebog til ArbejdsPladsVurdering - APV. De fire faser Drejebog til gennemførelse af APV i skovbranchen. Systematisk arbejdsmiljøarbejde Drejebog til ArbejdsPladsVurdering - APV De fire faser Drejebog til gennemførelse af APV i skovbranchen. Udarbejdet af: Inge Nørby 2007 Systematisk arbejdsmiljøarbejde Indholdsfortegnelse

Læs mere

Læs først casebeskrivelsen på næste side. Det kan være en god ide at skimme spørgsmålene, som I skal besvare, inden casen læses.

Læs først casebeskrivelsen på næste side. Det kan være en god ide at skimme spørgsmålene, som I skal besvare, inden casen læses. I en kort artikel på næste side beretter vi om Elin, der er borgerkonsulent i Visitationen i Aarhus Kommune. Tidligere var Elins titel visitator. Artiklen beskriver på baggrund af interviews hvad forandringen

Læs mere

Vejledning til tiltrædelse og udvikling Vejledning til tiltrædelsessamtalen og udviklingsdelen

Vejledning til tiltrædelse og udvikling Vejledning til tiltrædelsessamtalen og udviklingsdelen Vejledning til tiltrædelsessamtalen og udviklingsdelen Herunder kan du finde hjælp til tiltrædelsessamtalen og til udviklingssamtalen og udviklingskontrakten. 1 Vejledning til tiltrædelsessamtalen Denne

Læs mere

PS102: Den menneskelige faktor og patientsikkerhed

PS102: Den menneskelige faktor og patientsikkerhed IHI Open School www.ihi.org/patientsikkerhed PS102: Den menneskelige faktor og patientsikkerhed (1 time) Dette modul er en introduktion til emnet "menneskelige faktorer": Hvordan indarbejdes viden om menneskelig

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

From Human Factors to Human Actors - The Role of Psychology and Human-Computer Interaction Studies in System Design

From Human Factors to Human Actors - The Role of Psychology and Human-Computer Interaction Studies in System Design ? VAD From Human Factors to Human Actors - The Role of Psychology and Human-Computer Interaction Studies in System Design? VEM Skrevet af Liam J. Bannon Director of the IDC and Professor of Computer Science,

Læs mere

3D GeoInformation. Systemudvikling. 1. Introduktion til Systemudvikling og Projektmodeller. Systemudvikling L7 2007 Lars Bodum

3D GeoInformation. Systemudvikling. 1. Introduktion til Systemudvikling og Projektmodeller. Systemudvikling L7 2007 Lars Bodum Systemudvikling 1. Introduktion til Systemudvikling og Projektmodeller Systemudvikling L7 2007 Lars Bodum Program Hvad er et system? Universe of discourse Leavitt s model for forandring Projektmodeller

Læs mere

Forecasting - MED SIKKER GRUND UNDER FØDDERNE

Forecasting - MED SIKKER GRUND UNDER FØDDERNE Demand Planner 2 MICROSOFT BUSINESS SOLUTIONS MICROSOFT BUSINESS SOLUTIONS 3 Forecasting - MED SIKKER GRUND UNDER FØDDERNE Kan du forudsige kundernes efterspørgsel, får du bedre mulighed for at styre virksomheden

Læs mere

Det vigtigste først! Dette er måske den vigtigste bog der nogensinde er skrevet om agile vs. vandfald. Muligvis fordi det vel stadig er den eneste

Det vigtigste først! Dette er måske den vigtigste bog der nogensinde er skrevet om agile vs. vandfald. Muligvis fordi det vel stadig er den eneste WTF? Thomas Schou-Moldt, Miracle A/S (siden 2008) Arkitekt, udvikler, teknisk projektleder, mv. Indtil videre afsonet lidt over 20 år i branchen, ingen udsigt til prøveløsladelse tsm@miracleas.dk, 5374

Læs mere

BUDGET. i byggeriet. INTERVIEW med professor Jan Mouritsen, Center for ledelse i byggeriet / CBS

BUDGET. i byggeriet. INTERVIEW med professor Jan Mouritsen, Center for ledelse i byggeriet / CBS s. 12 _ MAGASIN BENSPÆND _ Perspektiver på byggeriets problematikker _ budget BUDGET i byggeriet INTERVIEW med professor Jan Mouritsen, Center for ledelse i byggeriet / CBS Der er en tendens til, at man

Læs mere

Specialister i softwareudvikling. Mobil apps Online løsninger IT-konsulenter Ændring af eksisterende løsninger

Specialister i softwareudvikling. Mobil apps Online løsninger IT-konsulenter Ændring af eksisterende løsninger Specialister i softwareudvikling Mobil apps Online løsninger IT-konsulenter Ændring af eksisterende løsninger Projekter med Centic 1) Udgangspunktet er jeres virksomhed Den it-løsning vi leverer til jeres

Læs mere

Figur 9.1 De otte forandringstrin.[28]

Figur 9.1 De otte forandringstrin.[28] 9. IMPLEMENTERING 9. IMPLEMENTERING Dette kapitel har til formål, at redegøre for hvordan Temagruppe 10 kan skabe rammerne for succesfuld Benchmarking. I foregående kapitel er der redegjort for hvorledes

Læs mere

Computeren repræsenterer en teknologi, som er tæt knyttet til den naturvidenskabelige tilgang.

Computeren repræsenterer en teknologi, som er tæt knyttet til den naturvidenskabelige tilgang. Den tekniske platform Af redaktionen Computeren repræsenterer en teknologi, som er tæt knyttet til den naturvidenskabelige tilgang. Teknologisk udvikling går således hånd i hånd med videnskabelig udvikling.

Læs mere

Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. ERP Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste videns- og udviklingsklub.

Læs mere

PS4 A/S. House of leadership. Hvad tærer og nærer på Danske medarbejderes motivation.

PS4 A/S. House of leadership. Hvad tærer og nærer på Danske medarbejderes motivation. PS4 A/S House of leadership Hvad tærer og nærer på Danske medarbejderes motivation. Hvad tærer og nærer på danske medarbejderes motivation? Resultater af motivationsundersøgelse maj 2011 Konsulenthuset

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

IT og økonomi. Organisering af IT. Strategi og planlægning. Systemudvikling 3 Systemudvikling og systemanskaffelse. Hovedopgaver

IT og økonomi. Organisering af IT. Strategi og planlægning. Systemudvikling 3 Systemudvikling og systemanskaffelse. Hovedopgaver IT og økonomi Systemudvikling 3 Systemudvikling og systemanskaffelse Organisering af IT Hovedopgaver Strategi og planlægning Udvikling og anskaffelse Drift Brugersupport Strategi og planlægning Topledelsen

Læs mere

Afrapportering om forebyggende selvmordsundervisning

Afrapportering om forebyggende selvmordsundervisning Afrapportering om forebyggende selvmordsundervisning Rapporten vil beskrive : 1) Tilrettelæggelse af undervisningen 2) Gennemførelsen af undervisningen 3) Undervisningsmateriale/Litteratur 4) Erfaringsopsamling,

Læs mere

Innovations- og forandringsledelse

Innovations- og forandringsledelse Innovations- og forandringsledelse Artikel trykt i Innovations- og forandringsledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger

Læs mere

Fælles Pædagogisk Grundlag

Fælles Pædagogisk Grundlag Fælles Pædagogisk Grundlag Information til forældre Dagtilbud 0-6 år Forord Det er med glæde, at Børne-, Unge- og Familieudvalget i oktober måned godkendte et fællespædagogisk grundlag for det samlede

Læs mere

8. ARBEJDSPROCESSEN FOR SKABELSEN AF ET INTERNATIONALT WWW-STED... 113

8. ARBEJDSPROCESSEN FOR SKABELSEN AF ET INTERNATIONALT WWW-STED... 113 8. ARBEJDSPROCESSEN FOR SKABELSEN AF ET INTERNATIONALT WWW-STED... 113 8.1 FORSTÅELSE AF VIRKSOMHEDENS PRODUKTER/SERVICEYDELSER OG RESSOURCER... 114 8.2 INFORMATIONSSØGNING I RELATION TIL LANDE-, KONKURRENT-

Læs mere

Spil Rapport. Spil lavet i GameMaker. Kevin, Mads og Thor 03-02-2011

Spil Rapport. Spil lavet i GameMaker. Kevin, Mads og Thor 03-02-2011 Spil Rapport Spil lavet i GameMaker Kevin, Mads og Thor 03-02-2011 Indholdsfortegnelse Indledning... 2 HCI... 2 Planlægning / Elementær systemudvikling... 2 Kravspecifikationer... 4 Spil beskrivelse...

Læs mere

Hvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik

Hvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik Hvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik En referencelinie er en koordineret og veldefineret tilstand i et projekt,

Læs mere

Æstetik på pilgrim.dk

Æstetik på pilgrim.dk Æstetik på pilgrim.dk Indhold 1. Hvorfor æstetik ift. Pilgrim? 2. Hvad består æstetiske oplevelser af, og hvordan er brugerne blevet inddraget i sådan en designproces? 3. Design for æstetiske oplevelser

Læs mere

DM09x Molich s.1 UJC. Kap 3. De 5 gyldne regler: Nøgle til brugervenlige systemer: Et godt samarbejde med typiske brugere

DM09x Molich s.1 UJC. Kap 3. De 5 gyldne regler: Nøgle til brugervenlige systemer: Et godt samarbejde med typiske brugere DM09x Molich s.1 Molich Kap 3. De 5 gyldne regler: Nøgle til brugervenlige systemer: Et godt samarbejde med typiske brugere Kend brugere Inddrag brugere Lær af andre Koordiner systemets dele Afprøv og

Læs mere

Make it work! En Quick-guide til integration af virtuel mobilitet i internationale praktikophold

Make it work! En Quick-guide til integration af virtuel mobilitet i internationale praktikophold Make it work! En Quick-guide til integration af virtuel mobilitet i internationale praktikophold Hvad? Internationale praktikophold får større og større betydning i forbindelse med internationaliseringen

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

Fra god til fantastisk. Skab hurtige og målbare resultater!

Fra god til fantastisk. Skab hurtige og målbare resultater! Fra god til fantastisk Skab hurtige og målbare resultater! Team med solid erfaring Step-up blev etableret i 2003 og har lige siden arbejdet med at udvikle mennesker. Vi er i dag mest kendt som dem, der,

Læs mere

Sælgeruddannelsen. Den bevidste sælger

Sælgeruddannelsen. Den bevidste sælger Sælgeruddannelsen Den bevidste sælger Vindere i salget har en plan tabere har en undskyldning I arbejdet med salg og forbedring af performance er det vigtigt, at man konstant træner og udfordrer sig selv

Læs mere

MULTIMEDIEDESIGNER 1. ÅRS PRØVE

MULTIMEDIEDESIGNER 1. ÅRS PRØVE MULTIMEDIEDESIGNER 1. ÅRS PRØVE Eksamensprojekt, 2. semester, forår 2010 TEMA: E-HANDEL Erhvervsakademiet København Nord Udleveret mandag d. 3. maj 2010 Afleveres i 4 eksemplarer senest d. 28. maj kl.

Læs mere

Lær jeres kunder - bedre - at kende

Lær jeres kunder - bedre - at kende Tryksag 541-643 Læs standarden for kundetilfredshedsundersøgelse: DS/ISO 10004:2012, Kvalitetsledelse Kundetilfredshed Overvågning og måling Vejledning I kan købe standarden her: webshop.ds.dk Hvis I vil

Læs mere

Første del: indsatsen

Første del: indsatsen Første del: indsatsen Beskriv den indsats I vil sætte i gang Hvilke konkrete aktiviteter består jeres indsats af, og hvem skal gøre hvad? Elever i 5.a skal arbejde med emnet design Et tværfagligt forløb

Læs mere

Vejledning til bedømmelsesdelen

Vejledning til bedømmelsesdelen Vejledning til bedømmelsesdelen Denne vejledning fungerer som et hjælpeværktøj til, hvordan du udfærdiger en bedømmelse og afholder en bedømmelsessamtale i FOKUS. Personelbedømmelsens formål FOKUS bedømmelsen

Læs mere

<> STUDIEORDNING FOR MASTERUDDANNELSEN I IT. Specialiseringen i <<...>> VED <> i IT-VEST SAMARBEJDET

<<Institutionens logo>> STUDIEORDNING FOR MASTERUDDANNELSEN I IT. Specialiseringen i <<...>> VED <<INSTITUTIONENS NAVN>> i IT-VEST SAMARBEJDET STUDIEORDNING FOR MASTERUDDANNELSEN I IT Specialiseringen i VED i IT-VEST SAMARBEJDET FÆLLES SKABELON 10. marts 2008 1 Generel del af studieordning

Læs mere

8:30-14:30 Sproglig udvikling Kort aktivitet Planlægning af undervisningsforløb Fremlæggelse af undervisningsforløb

8:30-14:30 Sproglig udvikling Kort aktivitet Planlægning af undervisningsforløb Fremlæggelse af undervisningsforløb 8:30-14:30 Sproglig udvikling Kort aktivitet Planlægning af undervisningsforløb Fremlæggelse af undervisningsforløb Kaffepause 10:00-10:15 Frokost 12:15-13:00 Kaffepause 13:45-14:00 SPROGLIG UDVIKLING

Læs mere

Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF

Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF Den afsluttende prøve i AT består af tre dele, synopsen, det mundtlige elevoplæg og dialogen med eksaminator og censor. De

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

Lederuddannelsen Den Bevidste Leder

Lederuddannelsen Den Bevidste Leder Lederuddannelsen Den Bevidste Leder FORMÅL Formål med uddannelsen Ledelse handler om at få resultater gennem mennesker. Bevidste ledere er en forudsætning for at skabe attraktive arbejdspladser, og bevidst

Læs mere

UDDANNELSESBESKRIVELSE 2012 INNOVATION OG NYTÆNKNING

UDDANNELSESBESKRIVELSE 2012 INNOVATION OG NYTÆNKNING UDDANNELSESBESKRIVELSE 2012 INNOVATION OG NYTÆNKNING Indhold Målgruppe for uddannelsen... 2 Dit udbytte som deltager... 2 Uddannelse på diplom niveau... 3 Uddannelses omfang... 3 Seminarer... 3 Læringsform...

Læs mere

Ressourcen: Projektstyring

Ressourcen: Projektstyring Ressourcen: Projektstyring Indhold Denne ressource giver konkrete redskaber til at lede et projekt, stort eller lille. Redskaber, der kan gøre planlægningsprocessen overskuelig og konstruktiv, og som hjælper

Læs mere

Infoblad. ISO/TS 16949 - Automotive

Infoblad. ISO/TS 16949 - Automotive Side 1 af 5 ISO/TS 16949 - Automotive Standarden ISO/TS 16949 indeholder særlige krav gældende for bilindustrien og for relevante reservedelsvirksomheder. Standardens struktur er opbygget som strukturen

Læs mere

Proces orientering af IT organisationer (ITIL - implementering)

Proces orientering af IT organisationer (ITIL - implementering) Proces orientering af IT organisationer (ITIL - implementering) Af Lars Zobbe Mortensen Indholdsfortegnelse 1 Indledning... 3 1.1 Hvorfor bedst practice processer (f.eks. ITIL)?... 3 2 Beslutning om forandring...

Læs mere

Job / Person sammenligning

Job / Person sammenligning Job / Person sammenligning Privat & fortroligt 04/08/2014 Sales Director/ Hr. Thomas Sample PPA Job D 7 5 2 5 I 4 3 1 8 S 8 6 2-9 C 4 8-4 -4 Jobbeskrivelse JOb KRAv ANALYSE Resultatet af den udarbejdede

Læs mere

Fokus på innovation med Walt Disneys. kreativitetsstrategi? Præsentationens Indhold: Indledning Hvad er Walt Disneys

Fokus på innovation med Walt Disneys. kreativitetsstrategi? Præsentationens Indhold: Indledning Hvad er Walt Disneys Fokus på innovation med Walt Disneys kreativitetsstrategi Præsentationens Indhold: Indledning Hvad er Walt Disneys kreativitetsstrategi? Fordele? Udbytte? Hvem kan have glæde af innovationsprojekter? Hvordan

Læs mere

Forandringsagenten. Efter denne lektion skal du:

Forandringsagenten. Efter denne lektion skal du: Forandringsagenten Forandringsagenten Rollemodel Krav til de enkelte roller Diffusionssystemer Forandringsplanlægning Slide no.: 1 Efter denne lektion skal du: Kende til forandringsagentens rolle og ansvar

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

FACILITERING Et værktøj

FACILITERING Et værktøj FACILITERING Et værktøj Af PS4 A/S Velkommen til PS4s værktøj til facilitering Facilitering af møder Ved møder sker det ofte, at den indholdsmæssige diskussion sluger al opmærksomheden fra deltagerne,

Læs mere

<> STUDIEORDNING FOR MASTERUDDANNELSEN I IT. Linjen i <<...>> VED <> i IT-VEST SAMARBEJDET

<<Institutionens logo>> STUDIEORDNING FOR MASTERUDDANNELSEN I IT. Linjen i <<...>> VED <<INSTITUTIONENS NAVN>> i IT-VEST SAMARBEJDET STUDIEORDNING FOR MASTERUDDANNELSEN I IT Linjen i VED i IT-VEST SAMARBEJDET FÆLLES SKABELON 1. april 2014 1 Generel del af studieordning for masteruddannelsen

Læs mere

Lektionsplan B (1 dag)

Lektionsplan B (1 dag) Lektionsplan B (1 dag) Formålet med en dags undervisning er at give deltagerne viden om og forståelse for hvordan forskellige former for adfærd påvirker kommunikationen. Desuden vil deltagerne afprøve

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

UDEN FOR EETIKKEN. Jeg har. over et flerårigt forløb været i kontakt med en psykologarbejdsplads,

UDEN FOR EETIKKEN. Jeg har. over et flerårigt forløb været i kontakt med en psykologarbejdsplads, Synspunkt Af Ebbe Lavendt UDEN FOR På en stor dansk psykologarbejdsplads sker der systematiske brud på de etiske principper. Skyldes det ressourcemangel eller befinder stedet sig bare uden for etikken?

Læs mere

OPG. 3: STRATEGI FOR BRUGERINVOLVERING TAXAQUIZZEN GRUPPE 8: SALLY//LARS//ERIK//LINE BRUUN PROGRAM: TAXAQUIZZEN

OPG. 3: STRATEGI FOR BRUGERINVOLVERING TAXAQUIZZEN GRUPPE 8: SALLY//LARS//ERIK//LINE BRUUN PROGRAM: TAXAQUIZZEN OPG. 3: STRATEGI FOR BRUGERINVOLVERING PROGRAM: Taxaquizzen er en dansk tv-serie på Tv2, produceret efter det internationale koncept Cash Cab, som første gang blev vist på britisk tv i 2005. I programmet

Læs mere

Det er MIT bibliotek!

Det er MIT bibliotek! Det er MIT bibliotek! Denne guide er skrevet til dig, som skal køre rollespillet Det er MIT bibliotek! Det er et rollespil, som giver unge i udskolingsklasserne en bedre forståelse for, hvorfor biblioteket

Læs mere

Guide til succes med målinger i kommuner

Guide til succes med målinger i kommuner Guide til succes med målinger i kommuner Af Kresten Bjerg, kommunikationsrådgiver, Bjerg K Kommunikation måles af forskellige grunde. Derfor skal kommunikation også måles på forskellige måder. Dit første

Læs mere

Projektevaluering. Caretech Innovation. Projekt Mobiladgang til logistik data (C-72)

Projektevaluering. Caretech Innovation. Projekt Mobiladgang til logistik data (C-72) 1 Projektevaluering Caretech Innovation Projekt Mobiladgang til logistik data (C-72) Deltagere/partnere: Systematic A/S Capgemini Regionshospitalet Randers Caretech Innovation Dato: 3. oktober 2012 Version:

Læs mere

Hold 1, 2014 LOGBOG. Denne logbog tilhører:

Hold 1, 2014 LOGBOG. Denne logbog tilhører: Ledelse af borger og patientforløb på tværs af sektorer Et lederudviklingsforløb for ledere i Sundhed og Omsorg i Aarhus Kommune og ved Aarhus Universitetshospital Hold 1, 2014 LOGBOG Denne logbog tilhører:

Læs mere

Elevforudsætninger I forløbet indgår aktiviteter, der forudsætter, at eleverne kan læse enkle ord og kan samarbejde i grupper om en fælles opgave.

Elevforudsætninger I forløbet indgår aktiviteter, der forudsætter, at eleverne kan læse enkle ord og kan samarbejde i grupper om en fælles opgave. Undersøgelse af de voksnes job Uddannelse og job; eksemplarisk forløb 0-3.klasse Faktaboks Kompetenceområde: Fra uddannelse til job Kompetencemål: Eleven kan beskrive forskellige uddannelser og job Færdigheds-

Læs mere

Projektarbejde. AFL Institutmøde den 6.10.2005 Pernille Kræmmergaard Forskningsgruppen i Informatik

Projektarbejde. AFL Institutmøde den 6.10.2005 Pernille Kræmmergaard Forskningsgruppen i Informatik Projektarbejde AFL Institutmøde den 6.10.2005 Pernille Kræmmergaard Forskningsgruppen i Informatik Ønske for dagen Jeg håber, at i får et indblik i: Hvad studieprojekter er for noget Hvordan projektarbejdet

Læs mere

FORANDRING FORANDRINGER FOREKOMMER ALLE STEDER TÆLL3R OGSÅ! Leder/arbejdsgiver

FORANDRING FORANDRINGER FOREKOMMER ALLE STEDER TÆLL3R OGSÅ! Leder/arbejdsgiver Om psykisk arbejdsmiljø i detailhandlen Læs mere på www.detdumærker.dk TÆLL3R OGSÅ! Leder/arbejdsgiver FORANDRING FORANDRINGER FOREKOMMER ALLE STEDER Helle og Trine er til personalemøde, hvor deres chef

Læs mere

Forbedringspolitik. Strategi

Forbedringspolitik. Strategi Forbedringspolitik Strategi 1 2 Indhold Forord... 3 Formål... 5 Vi vil forandre for at forbedre... 6 Forbedringer tager udgangspunkt i patientforløb og resultatet for patienten... 7 Medarbejder og brugerinvolvering...

Læs mere

InfoGalleri i detaljer

InfoGalleri i detaljer InfoGalleri i detaljer InfoGalleri er et digitalt formidlingsværktøj, der hjælper dig til at kommunikere bedre med dine brugere ved brug af storskærme. Ved hjælp af vores brugervenlige redaktionsværktøj,

Læs mere

Projekt faglig formidling

Projekt faglig formidling Projekt faglig formidling Fælles projekt mellem kommunikation/it og Matematik Hvad går projektet ud på? Vi er i Kom/IT og matematik startet på et nyt SO projekt, der hedder faglig formidling, hvor at vi

Læs mere

Forberedelse og planlægning af GMP Audit

Forberedelse og planlægning af GMP Audit Forberedelse og planlægning af GMP Audit Juli, 2014 Indledning I de kommende sider får du nogle hurtige tips og råd til din forberedelse og planlægning af en GMP audit. Dette er ikke en komplet og grundig

Læs mere

TEMA. Du og dit team kan vælge tema for forløbet ved at lade jer inspirere af aktuelle historier i medierne eller trends på nettet.

TEMA. Du og dit team kan vælge tema for forløbet ved at lade jer inspirere af aktuelle historier i medierne eller trends på nettet. TEMA Du og dit team kan vælge tema for forløbet ved at lade jer inspirere af aktuelle historier i medierne eller trends på nettet. Det er vigtigt, at temaet: Er bredt, så eleverne kan følge egne interesser

Læs mere

Bilag 18. It A hhx, juni 2010. 1. Identitet og formål

Bilag 18. It A hhx, juni 2010. 1. Identitet og formål Bilag 18 It A hhx, juni 2010 1. Identitet og formål 1.1. Identitet It er et samfundsvidenskabeligt fag med berøringsflader til teknologiske fagområder. Faget giver viden inden for databehandlingsteknologier

Læs mere

Har vi forskellig læringsstil? (testskema)

Har vi forskellig læringsstil? (testskema) Har vi forskellig læringsstil? (testskema) Dette spørgeskema er udformet for at finde frem til din foretrukne læringsstil. I årenes løb har du sikkert udviklet læringsvaner, som hjælper til at give en

Læs mere

Uge 5.3: (Search,) Select & implement and development methods

Uge 5.3: (Search,) Select & implement and development methods Innovationsprocesser Uge 5.3: (Search,) Select & implement and development methods A A R H U S U N I V E R S I T E T Department of Computer Science 1 Innovation & ICT development *** Innovation *** * ***

Læs mere

Varighed 1/2-1 time afhængig af den specifikke opgave ekskl. forberedelse og afrapportering.

Varighed 1/2-1 time afhængig af den specifikke opgave ekskl. forberedelse og afrapportering. Shadowing Designerne observerer real life situationer gennem et stykke tid for at få indsigt i brugeroplevelsen på biblioteket ( Discover ). Herunder forstå, hvordan brugerne reagerer i en given kontekst.

Læs mere

Skriftlige eksamener: I teori og praksis. Kristian J. Sund Lektor i strategi og organisation Erhvervsøkonomi. Agenda

Skriftlige eksamener: I teori og praksis. Kristian J. Sund Lektor i strategi og organisation Erhvervsøkonomi. Agenda Skriftlige eksamener: I teori og praksis Kristian J. Sund Lektor i strategi og organisation Erhvervsøkonomi Agenda 1. Hvad fortæller kursusbeskrivelsen os? Øvelse i at læse kursusbeskrivelse 2. Hvordan

Læs mere

Praktikpladsundersøgelse Computer Science Studerende Forår 2011

Praktikpladsundersøgelse Computer Science Studerende Forår 2011 [Skriv tekst] [Skriv tekst] [Skriv tekst] Praktikpladsundersøgelse Computer Science Studerende Forår 2011 Praktikpladsundersøgelse Computer Science Studerende Forår 2011 Københavns Erhvervsakademi Ryesgade

Læs mere

RELATIONEL KOORDINERING SAMMEN GØR VI JER ENDNU BEDRE

RELATIONEL KOORDINERING SAMMEN GØR VI JER ENDNU BEDRE RELATIONEL KOORDINERING SAMMEN GØR VI JER ENDNU BEDRE # VI OPLEVER, AT MANGE OFFENTLIGE ORGANISATIONER ER UNDER VOLDSOMT PRES. LAD OS HJÆLPE JER! 2 KOORDINERING AF KOMPLEKSE OG TVÆRGÅENDE ARBEJDSPROCESSER

Læs mere

Vurdering af kvalitet en note af Tove Zöga Larsen

Vurdering af kvalitet en note af Tove Zöga Larsen Vurdering af kvalitet en note af Tove Zöga Larsen Kvalitet... 2 Test... 2 Hvordan finder man testdata?... 2 Dokumentation af test... 3 Review... 3 Vurderingskriterier... 3 Gennemførelsen af et review...

Læs mere

SOCIAL PRAKSIS. i byggeriet

SOCIAL PRAKSIS. i byggeriet social praksis _ Perspektiver på byggeriets problematikker _ MAGASIN BENSPÆND _ s. 27 SOCIAL PRAKSIS i byggeriet INTERVIEW med forsker Erik Axel, Center for ledelse i byggeriet / RUC Selvfølgelig skal

Læs mere

IT og ressourcestyring på Byggepladsen. 1 af 25

IT og ressourcestyring på Byggepladsen. 1 af 25 IT og ressourcestyring på Byggepladsen Kjeld Svidt, Aalborg Universitet IT og ressourcestyring på byggepladsen Kjeld Svidt Aalborg Universitet it.civil.aau.dk 1 af 25 Projekt IT og ressourcestyring på

Læs mere

SÅDAN HAR DU EN STØTTENDE SAMTALE. Psykiatrifondens guide til samtaler med børn og unge. Psykiatrifondens guide til samtaler med børn og unge

SÅDAN HAR DU EN STØTTENDE SAMTALE. Psykiatrifondens guide til samtaler med børn og unge. Psykiatrifondens guide til samtaler med børn og unge Psykiatrifondens guide til samtaler med børn og unge SÅDAN HAR DU EN STØTTENDE SAMTALE Psykiatrifondens guide til samtaler med børn og unge PSYKIATRIFONDEN.DK 2 Psykiatrifonden 2014 DEN STØTTENDE SAMTALE

Læs mere

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor

Læs mere

Notat. Brug personas til at leve dig ind i brugernes liv

Notat. Brug personas til at leve dig ind i brugernes liv Notat SEGES P/S Koncern Digital Datadreven informationsformidling, personas og personalisering Ansvarlig JUPO Oprettet 17-03-2016 Projekt: 7464, Digitale relationer og datadreven informationsformidling

Læs mere

Accelerate Agil implementering fra EG NeoProcess

Accelerate Agil implementering fra EG NeoProcess Accelerate Prioritise Sprint Accelerate Agil implementering fra EG NeoProcess EG NeoProcess www.eg-neoprocess.dk Accelerate den agile implementering Verden og hverdagen er kompleks og i konstant forandring

Læs mere

Essentielt er problemet her en kulturkløft, samt dårlig kommunikation medarbejderne og IT folkene imellem der er problemet.

Essentielt er problemet her en kulturkløft, samt dårlig kommunikation medarbejderne og IT folkene imellem der er problemet. Metoden ETHICS Søren Riis Jensen & Morten Skyt Eriksen Samarbejdsorienteret udvikling generelt Problemer ved typiske ikke samarbejdsorienterede udviklingsmetoder, er at de fejler pga. menneskeproblemer,

Læs mere

Projektbeskrivelse Informations Teknologi

Projektbeskrivelse Informations Teknologi Projektbeskrivelse Informations Teknologi Upload og indeksering af elev og -projektopgaver i skolemiljøet Indledning: Som nystartet på et gymnasium kan omvæltningen fra elev til påbegyndende studerende

Læs mere

En kur mod sygefravær

En kur mod sygefravær En kur mod sygefravær - Er en kur mod usunde relationer på en arbejdsplads Pernille Steen Pedersen Institut for Ledelse, Politik og filosofi & PPclinic Lån & Spar & Alectia Det gode liv Indsatser: Sundhedstjek

Læs mere

Magt & Etik når målet kan hellige midlet Mette Kaas Holt Team 5

Magt & Etik når målet kan hellige midlet Mette Kaas Holt Team 5 Magt & Etik når målet kan hellige midlet Mette Kaas Holt Team 5 1 Indholdsfortegnelse Indholdsfortegnelse 2 Indledning 3 Problemformulering 3 Metodeafsnit 4 Definitionen af Det Gode Liv 4 Direkte, Indirekte

Læs mere

METODESAMLING TIL ELEVER

METODESAMLING TIL ELEVER METODESAMLING TIL ELEVER I dette materiale kan I finde forskellige metoder til at arbejde med kreativitet og innovation i forbindelse med den obligatoriske projektopgave. Metoderne kan hjælpe jer til:

Læs mere