Synopsis: Tema: Design og vurdering af et edbsystem i samarbejde med brugere

Størrelse: px
Starte visningen fra side:

Download "Synopsis: Tema: Design og vurdering af et edbsystem i samarbejde med brugere"

Transkript

1 15pt0pt

2

3 Department of Computer Science Informatik Fredrik Bajers Vej 7E DK-9220 Aalborg Øst Titel: Workout & Fitnesss Tema: Design og vurdering af et edbsystem i samarbejde med brugere Projektperiode: INF2, Forårssemester 2006 Projektgruppe: i202a Deltagere: Mikkel Bundgaard Lars Holm Christiansen Brit Susan Jensen Kasper Wittrup Højris Jensen Mads Kristian Wallin Pedersen Alex Ranch Vejleder: Janne Jul Jensen Oplagstal: 8 Sidetal: 92 Afsluttet den 30. Maj 2006 Synopsis: Denne rapport behandler udvikling af software i samarbejde med brugere. Der anvendes extreme Programming(XP) som udviklingsmodel for processen. Samarbejdspartneren i dette projekt er en mindre virksomhed, der sælger samt udlejer diverse tness produkter til private samt rmaer. Virksomheden har ønske om at optimere deres arbejdsrutiner, ved hjælp af implementering af ny software løsninger, da de eksisterende systemer ikke længere opfylder virksomhedens krav. Gennem denne proces vil XP bliver evalueret som udviklingsmetode, hvorved vi vil specicere kritikpunkter og styrker. Programmet er udviklet i et Java udviklingsmiljø og efterfølgende er der udført en brugbarhedstest på programmet for at afdække og klassicere eventuelle brugbarhedsproblemer.

4

5 Forord. Vi ønsker at takke Thomas Storm fra Workout & Fitness, uden hans hjælp ville det ikke have været muligt at gennemføre dette projekt. Thomas formåede at tage tid ud af hans travle kalender gentagende dage, for at kunne arbejde sammen med os. Møderne har været yderst produktive og vi er sikre på, at vi alle har lært meget af disse. Læsevejledning Til rapporten er tilknyttet en CD indeholdende udarbejdet materiale i form af kildekode og færdigt prototype-program. Kildehenvisninger er angivet som (forfatter, årstal) og en kildeliste ndes i kildeliste - se indholdsfortegnelse. I rapporten igennem anvendes udtrykket vi, og er udtryk for gruppen som har udarbejdet denne rapport. Forkortelser vil forekomme, angives som følgende eksempel: ExtremeProgramming(herefter XP). Appendiks indeholder udarbejdet materiale fra gruppen og er materiale som er udarbejdet af gruppen, men som ikke er relevant i rapporten. Mikkel Bundgaard Lars H. Christiansen Mads Wallin Brit Susan Jensen Kasper Wittrup Alex Ranch

6

7 Indhold. 1 Indledning Problembeskrivelse Problemformulering Indledende virksomhedsbesøg Mål Overvejelser Resultat af mødet Virksomhedsbeskrivelse Lageret Bogføring Ønsker til et nyt system XP Metoder Introduktion til XP Case værktøjer til XP X-planner Test Driven Development og J-unit Fælles udvikling Design Udviklingsmetode Planning game Hyppige udgivelser Metaforer Enkelt design Test Refaktorering Fælles ejerskab timers arbejdsuge Kundetilstedeværelse

8 3.4 Programmering Kunden er tæt på Kode standarder Test Driven Development Par programmering Integrer ofte Alle skal være med til at kode Opsummering Iterationer Første iteration Brug af brugerhistorier Kravliste Release Kommunikation Brugermøde Feedback Forbedringer til kommunikation Konklusion Anden iteration Kravliste Release Kommunikation Feedback Konklusion Opsummering af processen Metode kritik af XP Krav ændres løbende Brugsmønster vs. Brugerhistorier Anvendelse af XP Refaktoring Test driven development Mangel på ansvarsdeling Jo simplere, jo bedre Koden er designet Koden er selv-dokumenterende Caseværktøjer Positive erfaringer med XP Universitetsprojekter Opsummering

9 6 Estimering og usikkerheder Estimering Opsummering Tanker vedrørende software udvikling Gidseltagning i Extreme Programming Orden i kaos Konsekvenser Acceptance test 55 9 Test Testformål Teori Opstilling af test Fremgangsmåde Resultater Test overvejelser Konklusion Diskussion Samme projekt, to fremgangsmåder Samme fremgangsmåde andet projekt Konklusion Fremtidig arbejde Fremtiden for vores program A Mødeprogram 75 B Brugerhistorier 77 B.1 Interview guide C Introduktion til test 81 C.1 Testspørgsmål C.2 Samtykkeerklæring C.3 Demogrask data af testpersoner D Essays fra Software loso 85 D.1 Gidseltagning i Extreme Programming? D.2 Orden i kaos

10 D.3 Konsekvenser

11 Figurer. 3.1 Screenshoot af X-planner Forskrifterne supplerer hinanden Forløb i udvikling af software gennem TDD Et system til at udføre løbende test Screenshoot fra første iteration Screenshoot fra anden iteration Godkendelseskriterier for test Skema til katagorisering af fundne problemer Opstilling i Usabilitylab Fundne og klassicerede problemer fra brugbarhedstesten C.1 Samtykkeerklæring C.2 Demogrask data

12 FIGURER FIGURER 10

13 . KAPITEL 1 Indledning Dette projekt er udarbejdet i forbindelse med semestret INF2 ved Aalborg Universitet med det overordnede tema: Design og vurdering af et edb-system i samarbejde med brugere Formålet med dette projekt er at opnå erfaring i metoder og teknikker til samarbejde med brugere i udviklingsarbejde baseret på design, realisering og evaluering af prototyper. Vi vil i denne rapport dokumentere processen og erfaringerne fra udviklingen af et stykke software til rmaet Workout & Fitness. Projektet vil forløbe efter udviklingsmetoden Extreme Programming (XP). Det er vores mål at softwaren til Workout & Fitness kan anvendes i almindelige arbejdsrutiner, hvorved virksomhedens arbejdsopgaver eektiviseres. 1.1 Problembeskrivelse I det daglige arbejde hos Workout & Fitness bruges forskellige applikationer til både administration, håndtering af salg samt lagerstatus. Således er den nuværende forretningsgang, at et salg registreres ved at rmaets webløsning sender en til salgsafdelingen, der efterfølgende ringer op til køberen, for at aftale betalingsform samt levering med mere. Sælgeren skriver derefter kundens personlige oplysninger ind i et dokument, der benyttes som faktura. Dernæst skrives oplysninger vedrørende handlen, manuelt ind i virksomhedens økonomisystem. Til sidst sendes der besked til lageret om, at den bestilte vare skal afsendes. Ligeledes når der opgøres status på lageret, foregår dette ved at optællingen foretages, hvorefter resultatet sendes via , for derefter at blive indført i et regneark. Systemerne der bruges til at udføre dette arbejde har altså ingen, eller ringe indbyrdes sammenhæng, hvilket betyder at de ansatte ofte skal skifte mellem ere applikationer, for at løse deres arbejdsopgave. Dette medfører at tidsforbruget ved gennem-

14 1.2 Problemformulering 1 Indledning førelse af en bestilling synes at være for stort samt at muligheden for fejl indtastninger øges, hvilket vi vil søge at eektivisere. 1.2 Problemformulering Vi ønsker vha. XP at udvikle en applikation der muliggør en forbindelse mellem disse forskellige applikationer i den centrale styring, med særlig fokus på optimering af arbejdsgangen omkring lagerarbejdet i Flensborg. I udviklingen af denne applikation ønskes brugerinddragelse jf. XP forskrifterne, for derigennem at sikre succesfuld kravbeskrivelse samt implementering. Ovenstående leder os frem til følgende problemformulering: Hvorledes udvikles der med brug af XP, en applikation der kan sammenkoble de forskellige systemer virksomheden benytter nu, og hvilke erfaringer kan vi danne ud fra denne proces? 12

15 . KAPITEL 2 Indledende virksomhedsbesøg Inden selve udviklingen begyndte havde vi et initierende møde med virksomheden Workout & Fitness for at danne os et indtryk virksomheden, som vi ønskede at skrive projekt med, og for at vi kunne mødes med den repræsentative gruppe fra virksomheden. Vores mål var her at beskrive vores projekt og hvorledes det skulle forløbe. Det er dette vi beskriver i dette kapitel. 2.1 Mål Som første led i vores samarbejde med virksomheden Workout & Fitness, besluttede vi at hele gruppen skulle deltage i det første møde med virksomheden. Formålet med vores indledende besøg var til dels ment som en introduktion til virksomheden, og vore fremtidige samarbejdspartner. En del af mødet skulle samtidig foregå som et kvalitativt interview, i form af det Kvale (Kvale, 1994) kalder et delvist struktureret, kvalitativt eksplorerende interview (Se bilag B.1 på side 80). På mødet præsenterede vi vore mål med projektet, samt undersøgte hvad virksomheden kunne opnå gennem dette samarbejde. Herefter gav vi en generel kort introduktion til software-udviklingsmodeller, dernæst specikt om brugen af XP, samt hvad udvikling efter XP betyder for virksomheden. Herunder et tæt samarbejde og gentagende møder med repræsentanter for virksomheden. 2.2 Overvejelser En del af vore overvejelser inden mødet omhandlede hvorledes vi kunne sikre et højt udbytte af mødet. Dette søgte vi at opnå gennem det delvist struktureret eksplorerende interview. Spørgeformen var åben og fulgte et naturligt ow. Interviewet og de indledende spørgsmål var stillet med henblik på, at få

16 2.3 Resultat af mødet 2 Indledende virksomhedsbesøg et overblik over organisationen som helhed, samt at få et detaljeret indblik i de daglige arbejdsopgaver. 2.3 Resultat af mødet Igennem mødet k vi klarlagt forretningsgangen i virksomheden, samt et detaljeret indblik i arbejdsgangen i form af daglige opgaver. Samtidig gav mødet også virksomheden en introduktion til vores forventninger og hvilke fremgangsmetoder de kunne forvente vi ville anvende. Dette har været med til at danne videre grundlag for samarbejdet med Workout & Fitness. 2.4 Virksomhedsbeskrivelse Samarbejdspartneren Workout & Fitness er et lille rma med under ti medarbejdere, oprettet i 1997, fordelt på 2 geograske lokationer henholdsvis; Århus, virksomhedens hovedsæde, samt Flensborg. Flensborg afdelingen fungerer som lager samt butik, og er placeret i Tyskland af konkurrencemæssige årsager. Produkterne består af diverse typer af tness udstyr, alt fra mindre vægtsæt til større motionsmaskiner, så som motionscykler, træningsbænke etc. Virksomheden sælger primært produkter til private personer, dog køber rmaer også større tness løsninger hos Workout & Fitness. Virksomhedens nuværende hjemmeside kan ndes på Kundesegmentet er typisk personer i alderen år hvilket virksomhedens web løsning afspejler, idet betalingen foregår ved almindelig bankoverførsel således kunden har en fast kontaktperson på kontoret i Århus. Ved modtaget betaling sendes varen direkte fra lageret i Flensborg til kunden. Det er endnu ikke muligt at betale via hjemmesiden, hvilket der dog arbejdes på Lageret Lageret har ikke nogen elektronisk lagerstyringsfunktion, hvilket medfører at resultater af vareoptællinger manuelt skal indføres i et regneark. Vareforsendelsen sker ved salgskontoret kontakter lageret og beder dem sende de bestilte varer. Elektronisk lagerstyring er derfor også et ønske, således salgsafdelingen er i stand til at se lagerstatus samt at sammenholde denne, med hjemmesiden. Levering af varer sker så vidt muligt, som dag til dag levering. Dog afhænger dette af valgte fragtmand. 14

17 2 Indledende virksomhedsbesøg 2.4 Virksomhedsbeskrivelse Bogføring Bogføring i virksomheden foretages i C5 Light, som er en ældre version med DOS brugerade. Der er et udpræget ønske om bogføring stadig skal foretages i et C5 miljø, men at bogføringssystemet bliver opdateret til C5, samt at det integreres med lagerstyring, bestilling og faktureringen fra hjemmesiden Ønsker til et nyt system De nuværende systemer er ikke i tilstrækkelig grad integreret med hinanden, hvorfor der foretages en del manuel gentagende arbejde. Eksempelvis indføres bestillinger fra hjemmesiden manuelt i bogføringssystemet, ligesom der manuelt skal sendes besked til lageret om at afsende produkter. Det er bl.a. disse arbejdsgange der ønskes optimeret og integreret i et samlet system, således en del af det administrative merarbejde minimeres betydeligt, jf. nedenstående punkter. Integration mellem web og bogførings systemer Elektronisk lagerstyring Betalingsgateway på hjemmeside Mindsket gentagende administrations overhead, som følge af gentaget arbejde 15

18 2.4 Virksomhedsbeskrivelse 2 Indledende virksomhedsbesøg 16

19 . KAPITEL 3 XP Metoder I dette afsnit vil vi beskrive grundelementerne i XP samt hvordan udviklingen bør foregå efter XP. Ydermere vil vi behandle de caseværktøjer der anbefales til udviklingen, samt hvordan udviklingsprocessen bør forløbe ifølge XP. 3.1 Introduktion til XP Extreme Programming (XP) is actually a deliberate and disciplined approach to software development (Wells, 1999). XP adskiller sig fra det traditionelle udvikling paradigme, som f.eks. vandfaldsmodellen, ved i langt større grad, at sætte kunden i fokus i sammenlignet med det traditionelle paradigme. Dette fokus på kunden gennem hele udviklingsprocessen er vigtigt i XP idet kunden derved får et bedre indblik idet software der er under udvikling. Dette sætter kunden bedre i stand til at træe rationelle beslutninger om mulige ændringer i softwaren, selv sent i udviklingsprocessen. I XP lægges der stor vægt på de re kerneværdier som er; kommunikation, enkelthed, feedback og mod. Samlet set er dette med til at sikre en agil udviklingsproces. Eksempelvis igennem praksisen omkring parprogramming, sætter XP stor fokus på kommunikation. Yderligere er XP opbygget efter en ad struktur hvor alle har et fælles ansvar, idet der ofte skiftes rundt blandt udviklerne. Således står en enkelt udvikler ikke til ansvar for en komplet del af systemet, men mange delelementer. Ved at lade udviklerne rotere inden for projektet, muliggøres det også at give feedback på program-stumper, hvilket er medvirkende til at skabe ensartet kode. Igennem hele processen holdes en tæt kundekontakt og udgivelser til kunden sker hurtigt i projekt forløbet.

20 3.2 Case værktøjer til XP 3 XP Metoder 3.2 Case værktøjer til XP Der ndes en række udviklingsværktøjer til brug i XP der understøtter projekteringen og udviklingen af softwaren. Nogle af disse værktøjer vi vil beskrive i de følgende afsnit X-planner X-planner er et tidsestimeringsværktøj til at understøtte udviklingen, ved at holde rede på brugerhistorier i udviklingsiterationerne. Efter nogen tids brug, kan udviklerne bruge X-planner til at hjælpe med at estimere tidskrævende iterationer, baseret på data indsamlet under tidligere iterationer. Yderligere hjælper værktøjet med at holde styr på hvilke udviklere der er tilknyttet hvilke brugerhistorier, samt hvor langt udviklingen af opgaverne er kommet. For illustration af X-planner se gur 3.1 Figur 3.1: Screenshoot af X-planner Test Driven Development og J-unit Teorien bag brugen af Test Driven Development(TDD) foreskriver at der på forhånd skrives unit tests til den kode der skal skrives. Dette gøres for at sikre at den kode der skrives, ikke indeholder unødvendige funktioner idet der kun skal skrives nok kode til at unit testen kan gennemføres uden fejl. 18

21 3 XP Metoder 3.3 Design Således fungerer unit testene som succeskriterier for udviklingen, og disse er med til at validere at softwaren er færdig udviklet. Til at skrive unit test, bliver frameworket J-unit anvendt, som kan integreres direkte med de este Java udviklingsmiljøer, hvilket i vores tilfælde er Borland JBuilder Fælles udvikling Til at styre kildekode lerne anvendes Subversion, hvilket er en forbedring af det ældre CVS, som versionsstyringsprogram. Til dette anvendes TortoiseSVN for at holde rede på opdateringer og nye tilføjelser fra gruppen. TortoiseSVN er en grask overbygning til SVN således det undgås at anvende en konsol. 3.3 Design Udviklingsmetode XP består af en række regler, hvor enten alle, eller ingen af disse regler skal anvendes. Disse regler understøtter ifølge XP hinanden i en symbiotisk eekt, som vist på gur 3.2. Pilene mellem reglerne (punkterne) indikerer hvordan de balancerer og forstærker hinanden. Figur 3.2: Forskrifterne supplerer hinanden Planning game For at få det meste ud af udviklingsperioden forskriver XP, at udviklerne fra starten planlægger forløbet i samarbejde med kunden. Dette sker både 19

22 3.3 Design 3 XP Metoder for lade kunden føle at teamet har tingene under kontrol, men samtidig også en mulighed for at se hvad teamet gennemgår på forskellige tidspunkter i forløbet. Da kunden er i stand til se hvornår teamet udvikler på bestemte arbejdsområder, vil det være nemmere at komme med spørgsmål og ideer på det rigtige tidspunkt. Det er således kunden der er i den bedste position til at vurdere hvilke dele af systemet der har den højeste prioritet. Derimod er det udviklerne der kan vurdere hvilke opgaver der har den største kompleksitet og hvilke opgaver der således bør påbegyndes først. Ved hjælp af gruppens erfaringer fra tidligere projekter skulle udviklerne således være i stand til at fastsætte et reelt udviklingsforløb for at sikre projektets succes Hyppige udgivelser Efter en nøje planlægning ligger XP op til der udgives udgivelser med mindre tidsintervaller, så kunden vha. Planning game samt de forskellige udgivelser vil være i stand til at komme med indskydninger i form af ideer, for på den måde få de mest nyttige funktioner udviklet på mindst tid. Således vil udviklerne selv fra starten af forløbet være i stand til at starte på selve udviklingen af softwaren, og vha. af hyppige aeveringer være i stand til at minimere omkostningerne ved ændringer. Minimeringen af omkostningerne sker i kraft af at kunden gennem de hyppige udgivelser kan nde fejl, og derved kan der korrigeres for disse, således der ikke videreudvikles på fejl. De hyppige udgivelser hjælper således kunden med at ændre retningen af udviklingen for derigennem at sikre enighed mellem kundens ønsker og det som udvikles Metaforer Metaforer benyttes til at hjælpe kunden for at give forståelse for udviklingen vha. noget genkendeligt for kunden, eksempelvis at omtale et databasesystem som et adressekatalog eller telefonbog. Metaforer kan ligeledes benyttes internt i udviklingsteamet, således at hvis en delgruppe ikke mestrer et delemne, kan en anden delgruppe forklare sammenhængen vha. en metafor Enkelt design XP foreskriver, at softwaren ikke må indeholde redundant kode og skal således kun være i stand til at fuldføre alle testcases. Dette kan minde om en øvelse (Tufte, 1992) beskriver for graske designere: Design en gur, fuldstændig som man vil. Fjern derefter elementer uden at fjerne noget information. Når der ikke er mere der kan slettes, står man tilbage med det rigtige design. 20

23 3 XP Metoder 3.3 Design Altså bør det undgås at implementere unødige og overkomplicerede metoder i bestræbelserne på at opnå et enkelt design Test I XP skrives testcasene først og efterfølgende skrives koden. Årsagen til dette er, at man derved anskueliggør de krav og formål, den efterfølgende kode skal kunne opfylde. Udviklerne opnår derved simplere kode og det overordnede mål fastholdes. Dette giver samtidig en mere stabil og funktionel kode, se: (Beck, 2002), da hver enkelt del bliver gennemtestet før den bliver tilføjet til den eksisterende kode. Består den nye kode ikke testen fejlfrit, refaktoreres denne indtil dette er tilfældet. Dette skaber mere tillid til koden, både for udviklerne og kunden. Se også afsnit på side Refaktorering Når et udviklingspar tilføjer ny kode til den samlede systemkode, er det vigtigt at de overvejer om der kan laves ændringer til den eksisterende kode, der kunne gøre deres implementering lettere. Hvis implementeringen lykkes og den gennemløber samtlige tests fejlfrit, kan udviklerne overveje om de kan se nye måder at forbedre koden på. Det er denne gennemgang og søgen efter forbedring af systemkoden der kaldes refaktorering. Måden udviklerne nder frem til, at det er nødvendigt med refaktorering, kan f.eks. være hvis der er redundant kode. Eksempelvis hvis metoder har næsten samme funktion, kan disse laves til en enkelt metode der opfylder begge krav, hvilket resulterer i en simplere og mere overskuelig kode Fælles ejerskab For at opnå det bedst mulige udbytte af de forskellige udvikleres erfaringer, opfordres disse til løbende at tilføje ændringer og opdatere kode igennem hele systemet. Udviklingen foregår ved at der programmeres i par og at der hyppigt roteres rundt, så alle programmører har haft del i alt kode i større eller mindre grad. Derved undgås at enkelte udviklere får ejerskab over en bestemt del af koden. Hvis et udviklingspar nder muligheder for at opdatere systemkoden, eller det er nødvendigt at ændre koden for, at implementere nye dele, så bør de foretage disse ændringer. Udviklernes kendskab til det samlede system afhjælper også de mulige fejl og problemer disse løbende opdateringer ville kunne skabe. 21

24 3.3 Design 3 XP Metoder timers arbejdsuge I XP udviklingsmetoden er kreative og oplagte udviklere et vigtigt element. Arbejdsopgaver i udviklingen bør være fastsat således udvikleren ikke overbelastes med arbejde, således de ikke kan møde udhvilet og oplagte op næste arbejdsdag. Et eksempel på dette kan være en 40 timers arbejdsuge. Dette betyder dog ikke, at der ikke er plads til overarbejde hvis uventede problemer opstår, dog vil der ikke komme noget godt ud af gentaget overarbejde. I sådanne tilfælde står projektgruppen overfor et dybereliggende problem, der ikke kan løses ved overarbejde Kundetilstedeværelse Kundetilstedeværelse er et vigtigt element i XP udviklingsmetoden, fordi den hjælper med at sikre udviklingens og systemets succes. Kunden er en repræsentant for virksomheden der udvikles til, der har forståelse for hvad der kræves af systemet, samt hvordan det skal anvendes. XP foreskriver at der gøres nytte af en onsite costumer, hvilket betyder at kunden ikke bare skal være et element man forhandler med og udvikler til. Men derimod ønskes det at kunden er en aktiv del af udviklingsholdet, så det derved er muligt at diskutere eventuelle tvivlsspørgsmål i selve udviklingsprocesen. Formålet med kundetilstedeværelsen er, at søge at sikre et bedre slutprodukt, ved at lade kunden besvare udviklernes spørgsmål samt træe beslutninger vedrørende udviklingen. Brugerhistorier Brugerhistorier minder lidt om brugsmønstre, dog er brugsmønstre mere proces orienterede samt skrevet af udvikleren. Brugerhistorier er små historier skrevet af brugerne af systemet. Disse historier skal kort fortælle hvad delelementer af systemet skal kunne. Eksempelvis kunne en brugerhistorie beskrive, hvorledes et salg forgår fra start til slut, hvorimod et brugsmønster for samme scenario ville beskrive den specikke proces. Brugerhistorier erstatter samtidig kravspecikationen. Idet en kravspecikation er et endegyldigt dokument, bruges en sådan specikation ikke ifølge XP idet et af kerne elementerne i XP er at kunden skal kunne ændre kravene til systemet løbende gennem projektet. Brugerhistorier er dog ikke endegyldige krav til delelementet, men lige så meget en indikator af sværhedsgraden af det ønskede element. Udvikleren kan således bruge disse brugerhistorier i planlægningsfasen, til estimering af hvor lang tid det vil tage at udvikle den specikke del af systemet. Under udfærdigelsen af brugerhistorierne er kundens opgave at forklare udvikleren 22

25 3 XP Metoder 3.4 Programmering problemstillingen, med henblik på at udvikleren skal få indsigt i problemstillingen samt have mulighed for at stille uddybende spørgsmål. Udgivelser Når brugerhistorierne er lavet, afholdes et udgivelsesmøde, hvori det bestemmes hvornår de forskellige udgivelser skal nde sted. Rækkefølgen af udgivelserne bestemmes i samarbejde med kunden. Møder XP foreskriver standup meetings som en måde at komme hurtigt i gang med dagens opgaver, samtidig med at hele holdet bliver sat ind i ændringer. Grunden til at møderne afholdes stående er for at sikre at de ikke trækker ud. Dette er ligeledes med til at holde diskussionerne små, samtidigt med at hele holdet bidrager til mødet. 3.4 Programmering Kunden er tæt på Et af kerne-elementerne i XP er, at have kunden tæt på under hele processen hvilket også gælder i programmeringsfasen. Hvis muligt tilrådes det ydermere, at kunden aktivt hjælper med til selve udviklingen af programmet. Kundens primære funktion er, at fungere som et værktøj til at sikre produktet lever op til egne forventninger og krav. Dette sikres ved at kunden, med hjælp fra udviklerne, skriver brugerhistorier og er med til at fastsætte deadlines for udgivelser, samt prioritering af de forskellige udgivelser. Kunden tilrådes også at være med til at teste de forskellige udgivelser, da disse test ligger til grund for vericering af udgivelsens modenhed Kode standarder Udviklerne skal indbyrdes aftale, hvordan koden opstilles og hvilken navngivningsstandard der benyttes. Dette gøres for at opnå ensartet kodelayout, hvorved alle udviklere bedre er i stand til at læse og forstå hinandens kode. Ifølge XP er ens kodelayout noget man stræber efter, dog er det opnå svært at opnå fuldstændig ensartethed. 23

26 3.4 Programmering 3 XP Metoder Test Driven Development Inden selve programmeringen påbegyndes, overvejes det hvilke test der skal udføres for koden er tilstrækkelig udviklet. Sideløbende med udviklingen skrives yderligere test. Først når koden består testcasene, er udviklingen færdig. Det er derfor vigtigt at tilføje alle tænkelige testcases. Test Driven Dvelopment,TDD, er også en fordel ved refaktorering af kode, da det bliver lettere at refaktorere kode, idet det hurtigt kan afgøres om den refaktorerende kode, lever op til kravene fastsat i testcasene. Inden en testcase skrives, overvejes det først hvad der er nødvendigt at teste. Derefter skrives testen, og testen udføres for at sikre at den fejler. Herefter skrives den kode som denne testcase har til formål at validere. Dette er illustreret i gur 3.3. Eksempler på testkode kan ses på den medfølgende CD. Figur 3.3: Forløb i udvikling af software gennem TDD Alle testcases bør så vidt muligt automatiseres, således det ikke kræver menneskelig fortolkning af testresultaterne. Hvis testene tager længere tid, kan der i stedet anvendes smoking tests (Larman, 2005), som betyder at de længerevarende test cases kun afvikles 4 gange om dagen. For at kunne udføre løbende test, kræves det at store dele af udviklingen automatiseres. Denne automatisering er illustreret på gur 3.4 på næste side. En server henter løbende opdateringer til kildekoden fra versionstyringsprogrammet(subversion/cvs). Herefter afvikles alle testcases, og når testcasene 24

27 3 XP Metoder 3.4 Programmering validerer korrekt, overføres de til webserveren. Figuren illustrere hvordan det kunne foregå ved et webudviklingsprogram. Figur 3.4: Et system til at udføre løbende test Par programmering Parprogrammeing er en programmeringsform hvor to programmører deles om en computer. Ideen med parprogrammeing er at trods tiden det tager at producere et stykke kode øges, bliver kvaliteten af koden samtidig højere, ifølge (Cockburn and Williams, 2001). Derved ender man med at spare tid og omkostninger senere i processen, da der ikke er nær så mange fejl og der skal rettes i programmet. Parprogramming besidder samtidig den fordel, at det er med til at uddanne udviklerne og give ensartet kode. XP foreskriver at der til et par af programmører hører ét tastatur, en mus, samt at de to udviklere bytter plads med jævne intervaller for at sikre kvaliteten. 25

28 3.5 Opsummering 3 XP Metoder Integrer ofte Udviklerne skal stræbe efter at udgive kode så ofte som muligt. Det er især vigtigt at et udviklingsteam ikke holder på et stykke kode i mere end en dag af gangen. Løbende udgivelse af kode medvirker til at undgå en afvigende og fragmenteret udvikling, idet alle har adgang til den sidste nye kode. Dermed kan udviklerne til stadighed holde sig opdaterede med både funktionalitet af kode, samt have overblik over processen som helhed. Ydermere er det vigtigt at integrationerne fra de forskellige programmerings grupper koordineres så der ikke forekommer konikter eller programmeres videre i forældet kode Alle skal være med til at kode XP tilråder at alle medvirker til at kode og dermed er med til at nde nye ideer i alle aspekter af projektet. Dette medfører at der ikke er enkelte udviklinghold der ejer et stykke kode, hvorved alle udviklere vil kunne ændre og optimere alle dele af systemet. Denne tankegang medfører også at der ikke er en chef arkitekt på hele systemet. Alle i projektgruppen vil derfor være lige ansvarlige for det samlede system. 3.5 Opsummering Vi har i dette kapitel gennemgået og beskrevet hvorledes XP-metoden er opbygget af en række forskrifter der, ifølge (Beck, 2002), understøtter og forstærker hinanden. Disse forskrifter bygger på XP-metodens ånd om teamwork, kommunikation, enkelthed og feedback. Teamwork gennemføres vha. parprogramming, omrokering af udviklerne, møder samt fælles ejerskab. Alt dette er med til at sikre at alle udviklere har kendskab til alle aspekter af udviklingen, samt friheden til at gennemføre ændringer i hele kildekoden. Kommunikation gennemføres via den tætte kundekontakt, understøttet af brugerhistorier samt metaforer. Enkeltheden bliver understøttet af de fælles kodestandarder, hyppige aeveringer og refaktorering. Feedback kommer i udviklingen igennem de hyppige iterationer, kundekontakten, test og integrationerne. Alle forskrifterne understøtter hinanden indbyrdes og er med til at sikre en produktiv udvikling, der ikke er underlagt de traditionelle udviklingsparadigmers stringente opdeling af analyse og design. Dermed giver det udviklerne og kunden mulighed for, at indgå et tæt samarbejde hvor der hurtigt kan implementeres nye ændringer og stadig sikre et resultat af høj kvalitet. 26

29 . KAPITEL 4 Iterationer I kraft af at udviklingen gennemgår ere iterationer, bliver udviklerne i samarbejde med kunden, mere og mere opmærksomme på dennes ønsker. Således opnås der med tiden et system, der er lever op til kundens ønsker. 4.1 Første iteration Efter udarbejdelse af brugerhistorier i samarbejde med kunden gik vi igang med at designe GUI'en. Efter første iteration resulterede det i følgende; se gur 4.1 på den følgende side. Vores udgangspunkt var at designe en brugerade med store knapper med ikoner som medarbejderne intuitivt kunne associere til deres dagligdag. Årsagen til at udvikle GUI'en allerede i første iteration var, at give kunden et bedre indtryk af et fungerende program tidligt i processen. På denne måde ønskede vi at gøre kunden mere tryg ved programmet, for således at minimere eventuelle problemer forbundet med ibrugtagningen af systemet. Samtidig fungerede GUI'en som en overordnet arkitektur for funktionaliteter der skulle laves i kommende iterationer. Endvidere valgte vi i slutningen af iterationen at begynde udviklingen af enkelte funktionaliteter i metodelaget af programmet. Dette betød at vi skabte kontakt imellem vores program og den SQL-database server der indeholder lagerstatus, varenumre, priser osv. Dette var for at opnå bedre indblik i hvordan programmet i fremtiden skulle håndtere dette data Brug af brugerhistorier Ud fra de brugerhistorier vi k fra kunden, se appendiks B på side 77, kunne vi fastlægge nogle specikke krav til systemet. F.eks. kunne historien om lageroptælling omsættes til kravet om mere automatisering. Dette er i overensstemmelse med kundens ønske om at systemet selv skal løse gentagende og trivielle opgaver. Ud fra disse informationer besluttede vi at designe systemet således, at når lagerstatusen på et givent produkt ændres, skrives dette

30 4.1 Første iteration 4 Iterationer Figur 4.1: Screenshoot fra første iteration automatisk til den database som hjemmesiden bruger til at vise lagerstatus for kunderne. Denne funktion gør hele den nuværende procedure fuldautomatisk, hvilket derfor sparer tid hos både lagermedarbejderne, ledelsen og kunden Kravliste Der er fra kundens side stillet forskellige krav til systemet; bl.a. skal det automatisere en del af det gentage arbejde, der på nuværende tidspunkt forekommer i virksomheden. Ydermere skal der automatisk sendes en ordrebekræftelse, når en kunde har foretaget et køb via hjemmesiden. Når der bliver lavet optælling, indkøb, salg etc. skal systemet og hjemmesiden automatisk opdateres, således lagerstatus altid stemmer overens. Systemet skal desuden have funktioner der kan lave produktbestillinger, således brug af ere forskellige applikationer overødiggøres. Ydermere skal systemet kunne holde rede på hvem der har lejet et givent produkt, samt hvor lang tid det har været udlejet. Nedskrivningen af dette produkt skal ligeledes beregnes af systemet. Disse krav er at nde i de brugerhistorier der er blev udarbejdet i samarbejde med kunden. Brugerhistorierne 28

31 4 Iterationer 4.1 Første iteration kan ndes i appendiks B på side Release Efter ca. 14 dages udvikling sendte vi første iteration til kunden som i løbet af et par dage skulle gennemgå første iteration og komme med kommentarer ved brugermødet. Formålet med dette var at få respons på hvordan udviklingen af programmet forløb i forhold til de krav og brugerhistorier som blev udarbejdet fra starten. Således ville der allerede kunne tages hånd om uforudsete problemer og krav, således disse føres videre til næste iteration Kommunikation Gennem første iteration har vi benyttet forskellige kommunikationsformer, i vores kontakt med kunden.vi har primært, grundet den fysiske afstand, benyttet os af telefonisk kommunikation, samt korrespondance. Ved større beslutninger og designvalg valgte vi at tage til Århus for at holde personlige møder med kunden. Ved det første møde med kunden, var formålet at igangsætte projektet, derfor var hele gruppe med til mødet i Aarhus. Dette gentog vi da der skulle udarbejdes brugerhistorier. Som substitut for kunden der, i kraft af virksomhedens begrænsede størrelse, til tider havde de nødvendige ressourcer at afsætte til projektet, rettede vi i stedet denne kommunikation mod et gruppemedlem. Dette gjorde vi da vedkommende har indsigt i virksomhedens arbejdsmåder i kraft af sit fritidsarbejde i virksomheden. Dette gruppemedlem kom derfor ofte til at fungere som både en del af udviklingsholdet samt som kunde, hvilket var en stor fordel da gruppemedlemmet havde stort kendskab til de tekniske sider af det eksisterende system. Dette havde en vital rolle i udviklingen, idet mange af de tekniske spørgsmål kunne besvares omgående af vedkommende, i kraft af dennes overblik over det eksisterende system Brugermøde Slutningen på første iteration skulle have været et brugermøde med kunden for at igangsætte anden iteration. Dog blev vores kontakt med kunden begrænset i forhold til hvad vi havde håbet på. Det var i denne del af første iteration, vi valgte at benytte os af gruppemedlemmet der havde tilknytning til kunden. Gruppemedlemmets erfaring inden for virksomheden, samt kontakt med kunden via MSN Messenger og , gjorde at vi k den nødvendige respons og kritik til at kunne afslutte første iteration og fortsætte til anden iteration. 29

32 4.1 Første iteration 4 Iterationer Feedback Da det primært var GUI'en der var udviklet, gav kunden ikke så meget feedback, da kundens fokus mere lå på funktionaliteten af programmet. Dog blev der noteret, at kunden ønskede bedre navigation i programmet, gerne ved hjælp af en tilbageknap, således det altid vil være muligt at komme tilbage til hovedmenuen. GUI'en gjorde det således muligt for kunden at se hvordan de forskellige funktioner var planlagt til at se ud i programmet, hvilket denne fandt tilfredsstillende Forbedringer til kommunikation Grundet de, til tider, lange svar tider på s valgte vi, som tidligere nævnt, i slutningen af første iteration at benytte MSN Messenger. Idet kommunikation i Messenger automatisk bliver gemt på computeren blev det således muligt for hele gruppen på et senere tidspunkt at gennemse denne kommunikationen med kunden, for vericering af vores implementeringsforslag. Ved denne opdatering af vores kommunikationsform håbede vi, at få en mere eektiv arbejdsgang samt forøge hastigheden i fremtidige iterationer. Det var ydermere et forsøg på i større grad at følge XP forskrifterne i forhold til hvad vi havde gjort i den første iteration. Grundet, vore samt kundens, begrænsede ressourcer kunne vi ikke leve op til det element i XP der foreskriver kunden skal være tæt på udviklerne. Vi håbede dog på MSN Messenger løsningen ville simulere en tættere kontakt med kunden igennem de næste iterationer Konklusion Gennem første iteration, har vi lært at projektplanlægningen skal fastholdes, idet det er nødvendigt følge op på opgavernes varighed og længde, for derigennem at søge at undgå spildtid og samtidig tracke retningen af udviklingen. Samtidig har vi gjort nogle erfaringer med brugerhistorier, samt opgaven med at udlede arbejdsopgaver fra brugerhistorier. Denne erfaring vil vi naturligvis bruge i anden iteration, samtidig vil vi forsøge at gøre mere ud af at anvende de roller som XP opstiller, samt og synliggøre disse. Disse tiltag skal være med til at forbedre udviklingen i anden iteration. Vores kommunikation i sidste del af første iteration har primært været MSN Messenger, kombineret med s. Mindre spørgsmål kunne stilles pr telefon hvis det ikke var muligt, at komme i kontakt med kunden via MSN Messenger. Vi vil i anden iteration forsætte med at anvende MSN Messenger 30

33 4 Iterationer 4.2 Anden iteration som et supplement til den eksisterende kommunikationen med kunden. 4.2 Anden iteration Efter gennemarbejdning af første iteration, samt dertilhørende feedback fra kunden, påbegyndte vi implementeringen af yderligere funktionalitet i programmet. Anden iteration indebar samtidig nogle udfordringer, idet virksomheden besluttede at omstrukturere deres database, hvilket resulterede i omfattende refaktorering, af alt der kommunikerede med databasen. Dette forsinkede vores udviklingsproces en del, idet dette viste sig at være mere kompliceret end først antaget. Årsagen til dette problem var til dels, at XP foreskriver at man altid skal kode til nu'et, og det derfor ikke er nødvendigt at fremtidssikre sit program, da man i tilfælde af ændringer bør refaktorerer. Derfor var store dele af koden opbygget omkring de antagelser vi i starten af første iteration havde gjort os. Da disse antagelser ikke længere var gyldige, resulterede dette som sagt i omfattende ændringer i koden, lignedende det (Rosenberg and Scott, 2000) kalder et kode Rip op Kravliste De generelle krav til programmet er stadig relevante for denne iteration, dog blev der fra kundes side fremsagt et ønske om en tilbage-funktion på brugeraden, der skulle muliggøre, at det altid var muligt for brugeren at komme tilbage til forsiden af programmet, vha. et museklik Release Efter cirka en uges udvikling på metodelaget, færdiggjorde vi anden iteration. Dette indebar en omfattende refaktorering af al koden der kommunikerer med SQL-databases, hvilket var nødvendigt for at kompensere for de ændringer der skete i opbygningen af det eksisterende system. Idet databasekontakten var etableret og vareoplysninger kunne hentes fra databasen samt behandles i programmet, forventede vi i dette release, respons fra kunden om hvordan disse levede op til dennes krav. Samtidig forventede vi også respons på implementeringen af præference-menuen i programmet, som indebar nye funktionaliteter kunden skulle tage stilling til. Dette var dog ikke muligt, så kommunikationen igennem denne iteration blev støttet op af antagelser om hvad kunden ønskede, baseret på inputs fra gruppemedlemmet der er ansat i virksomheden. Anden iteration resulterede således bl.a. i gur 4.2 på næste side der viser panelet Complete Order, hvilket 31

34 4.2 Anden iteration 4 Iterationer er et af de paneler der k tilføjet funktionalitet i anden iteration. Figur 4.2: Screenshoot fra anden iteration Kommunikation Vi har gennem anden iteration benyttet kommunikation via MSN Messenger, og telefon. De este af samtalerne er foregået over MSN messenger, da det umiddelbart var den nemmeste måde, hvorpå kunden kunne nde nogle tomme huller i sin tidsplan. Denne kommunikationsform er ikke ideel til brugermøder, men omstændighederne taget i betragtning, var det den mest eektive måde, hvorpå vi kunne få og opretholde kontakt med kunden. 32

Objektorienterede metoder

Objektorienterede metoder Objektorienterede metoder Gang 12. Kvalitet i større systemer Evt.: Ekstremprogrammering (XP) Dette materiale er under Åben Dokumentlicens, se http://www.sslug.dk/linuxbog/licens.html projektopgaven i

Læs mere

Indholdsfortegnelse for kapitel 1

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

Læs mere

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

DD110 - Detaljeret projektplan

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

Læs mere

- Erfaringer med implementering af MES løsninger. SESAM RAMBØLL, d 31. marts. 2011 DC Produktions IT Projekt Afdelingen Arne Boye-Møller

- Erfaringer med implementering af MES løsninger. SESAM RAMBØLL, d 31. marts. 2011 DC Produktions IT Projekt Afdelingen Arne Boye-Møller - Erfaringer med implementering af MES løsninger SESAM RAMBØLL, d 31. marts. 2011 DC Produktions IT Projekt Afdelingen Arne Boye-Møller DC Projektorganisation Arne J. Boye-Møller, Produktions IT, Projektafdelingen

Læs mere

Af produktivitetschef Bjarne Palstrøm, Dansk Industri

Af produktivitetschef Bjarne Palstrøm, Dansk Industri Faldgruber i Lean Af produktivitetschef Bjarne Palstrøm, Dansk Industri Erfaringerne med indførelse af Lean-tankegangen viser, at virksomhederne fra tid til anden ikke får det forventede udbytte. Denne

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

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

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

Læs mere

Tidsregistreringssystem til Løgstør Kommunale Hjemmepleje

Tidsregistreringssystem til Løgstør Kommunale Hjemmepleje Tidsregistreringssystem til Løgstør Kommunale Hjemmepleje 30. Maj 2003 Informatik Gruppe E4-101: Aalborg Universitet Eva Lund Andersen Jens Møller Lauridsen Joan Marianne Nielsen Lasse Bech Eiler Louise

Læs mere

Iterativ og Agil udvikling

Iterativ og Agil udvikling Iterativ og Agil udvikling 1 2 Udfordringer i hverdagen En liste over de udfordringer man står overfor ved implementering af iterativ og agil udvikling. 3 Udfordringer med Iterationer 4 Iterationer, I

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

Triolab lægger vægt på et tæt samarbejde med kunden, sådan at de tilbudte løsninger fungerer optimalt og tilpasses kundens behov.

Triolab lægger vægt på et tæt samarbejde med kunden, sådan at de tilbudte løsninger fungerer optimalt og tilpasses kundens behov. Side 1 af 8 Indledning Triolab er et firma, der forhandler kvalitetsløsninger til laboratorier i flere segmenter. Triolab er et firma, der forestår totalløsninger. Der tilbydes support på højt fagligt

Læs mere

Evaluering og kvalitetsudvikling i aftenskolen

Evaluering og kvalitetsudvikling i aftenskolen Evaluering og kvalitetsudvikling i aftenskolen Projektrapport Peter Holbaum-Hansen, LOF og Marlene Berth Nielsen, NETOP Juli 2009 [Skriv et resume af dokumentet her. Resumeet er normalt en kort beskrivelse

Læs mere

JUNI 2014 KØBENHAVN DK HOSTMASTER BRUGERUNDERSØGELSE 2014 AF DK HOSTMASTER. DK HOSTMASTER A/S Kalvebod Brygge 45, 3. sal. DK-1560 København V

JUNI 2014 KØBENHAVN DK HOSTMASTER BRUGERUNDERSØGELSE 2014 AF DK HOSTMASTER. DK HOSTMASTER A/S Kalvebod Brygge 45, 3. sal. DK-1560 København V JUNI 2014 KØBENHAVN DK HOSTMASTER BRUGERUNDERSØGELSE 2014 AF DK HOSTMASTER DK HOSTMASTER A/S Kalvebod Brygge 45, 3. sal. DK-1560 København V Juni 2014 Analyse af brugerundersøgelse af DK Hostmaster DK

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

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

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

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

Læs mere

Poster design. Meningen med en poster

Poster design. Meningen med en poster Poster design At præsentere et naturvidenskabelig emne er ikke altid lige nemt. Derfor bruges ofte plakater, såkaldte posters, til at fremvise forskning på fx messer eller konferencer. Her kan du finde

Læs mere

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

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

Læs mere

Softwaretest. - også af "ikke testbar" software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.

Softwaretest. - også af ikke testbar software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco. Softwaretest - også af "ikke testbar" software DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.dk Hvorfor softwaretest? Software er sjældent fejlfri Test sikrer at softwaren

Læs mere

JUNI 2015 KØBENHAVN DK HOSTMASTER BRUGERUNDERSØGELSE 2015 AF DK HOSTMASTER. DK HOSTMASTER A/S Kalvebod Brygge 45, 3. sal. DK-1560 København V

JUNI 2015 KØBENHAVN DK HOSTMASTER BRUGERUNDERSØGELSE 2015 AF DK HOSTMASTER. DK HOSTMASTER A/S Kalvebod Brygge 45, 3. sal. DK-1560 København V JUNI 2015 KØBENHAVN DK HOSTMASTER BRUGERUNDERSØGELSE 2015 AF DK HOSTMASTER DK HOSTMASTER A/S Kalvebod Brygge 45, 3. sal. DK-1560 København V Juni 2015 Analyse af brugerundersøgelse af DK Hostmaster DK

Læs mere

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

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

Læs mere

Samrådsspørgsmål. Akt 186

Samrådsspørgsmål. Akt 186 Samrådsspørgsmål Akt 186 Der ønskes en uddybende redegørelse for og en drøftelse af årsagerne til og konsekvenserne af den forventede meget betydelige fordyrelse og forsinkelse af projektet. Svar: Indledning

Læs mere

Bilag 2. Studieforløbsbeskrivelsen: Det faglige indhold I projektet

Bilag 2. Studieforløbsbeskrivelsen: Det faglige indhold I projektet Bilag 2 Studieforløbsbeskrivelsen: Det faglige indhold I projektet I de følgende spørgsmål skal I som gruppe reflektere over, hvad I har gjort for at indfri de faglige krav til projektet. Hvordan har husets

Læs mere

Lavet af Danni jensen og David Olsen

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

Læs mere

It-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

It-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. It-håndbogen Uddrag af artikel trykt i It-håndbogen. 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

Læs mere

Region Midtjylland Proces for Change Management

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

Læs mere

eksamensprojekt 2. sem

eksamensprojekt 2. sem Multimediedesigner Klima 2009 Virksomheder i en klimakontekst eksamensprojekt 2. sem maj - juni 2009 www.cphnorth.dk Trongårdsvej 44 DK 2800 Kgs. Lyngby 1. Opgaven Indledning: I december 2009 skal Danmark

Læs mere

EDI til Microsoft Dynamics

EDI til Microsoft Dynamics EDI til Microsoft Dynamics EDI til Microsoft Dynamics Anvend EDI og udnyt potentialet fuldt ud i økonomisystemer fra Microsoft Dynamics herved opnår din virksomhed et mindre ressourceforbrug og færre fejl.

Læs mere

Cloud i brug. Migrering af Digitalisér.dk til cloud computing infrastruktur

Cloud i brug. Migrering af Digitalisér.dk til cloud computing infrastruktur Cloud i brug Migrering af Digitalisér.dk til cloud computing infrastruktur 02 Indhold > Executive Summary............................................................... 03 Digitaliser.dk.....................................................................

Læs mere

Når økonomioutsourcing er den rigtige løsning

Når økonomioutsourcing er den rigtige løsning Når økonomioutsourcing er den rigtige løsning Overvejer I at oursource hele eller dele af jeres økonomifunktion? Dette whitepaper er udarbejdet, så I har et bedre beslutningsgrundlag at handle ud fra.

Læs mere

Effektivisering og automatisering af lagerressourcer med Optilog

Effektivisering og automatisering af lagerressourcer med Optilog Effektivisering og automatisering af lagerressourcer Optilog er det ideelle styringsværktøj til lager- og logistikafdelinger i produktions- og handelsvirksomheder. Optilog er først og fremmest beregnet

Læs mere

Studieordning del 4-2014

Studieordning del 4-2014 Studieordning del 4-2014 Fagbeskrivelser Datamatiker AP Graduate in Computer Science Version 1.1 Revideret august 2014 Side 0 af 8 Indhold del 4 Fagbeskrivelser 1. Faget Programmering (PRO)...2 2. Faget

Læs mere

OFTE STILLEDE SPØRGSMÅL

OFTE STILLEDE SPØRGSMÅL Copyright 2015 EG A/S FAQ OFTE STILLEDE SPØRGSMÅL EG Clinea Dette dokument giver svar på de oftest stillede spørgsmål i forbindelse med opgradering fra MedWin til EG Clinea Copyright 2015 EG A/S FAQ Side

Læs mere

Virksomhedens salgspipeline. Business Danmark november 2009 BD272

Virksomhedens salgspipeline. Business Danmark november 2009 BD272 Virksomhedens salgspipeline Business Danmark november 2009 BD272 Indholdsfortegnelse Indledning... 2 Rapportens opbygning... 2 Hovedkonklusioner... 3 Metode og validitet... 3 Salgs- og marketingafdelingernes

Læs mere

Ledelsesevaluering. Formål med afsæt i ledelsespolitik og ledelsesværdier. Inspiration til forberedelse og gennemførelse

Ledelsesevaluering. Formål med afsæt i ledelsespolitik og ledelsesværdier. Inspiration til forberedelse og gennemførelse Ledelsesevaluering Inspiration til forberedelse og gennemførelse At gennemføre en ledelsesevaluering kræver grundig forberedelse for at give et godt resultat. Her finder I inspiration og gode råd til at

Læs mere

Postregistrering Eksamensprojekt i Programmering C Lavet af: Frantz Furrer Svendborg Erhvervsskole HTX Vejleder: Claus Borre

Postregistrering Eksamensprojekt i Programmering C Lavet af: Frantz Furrer Svendborg Erhvervsskole HTX Vejleder: Claus Borre Postregistrering Eksamensprojekt i Lavet af: Frantz Furrer Vejleder: Claus Borre Side af 4 Titelblad: Skolens navn: Svendborg Tekniske Gymnasium - Rapport: Rapportens titel: Postregistrering Side antal:

Læs mere

Hvilke forandringer vil brugerportalsinitiativet betyde for skoler og dagtilbud. Programchef Kit Roesen, KL

Hvilke forandringer vil brugerportalsinitiativet betyde for skoler og dagtilbud. Programchef Kit Roesen, KL Hvilke forandringer vil brugerportalsinitiativet betyde for skoler og dagtilbud Programchef Kit Roesen, KL Agenda Trivsel og læring digitaliseringsstrategi Hvor bliver ejerskabet af, når vi køber ind for

Læs mere

InsuBiz. Business case over Horsens Kommune: Return On Investment (ROI) for en dansk kommune der er skiftet fra EASY-systemet til InsuBiz EASY modul

InsuBiz. Business case over Horsens Kommune: Return On Investment (ROI) for en dansk kommune der er skiftet fra EASY-systemet til InsuBiz EASY modul InsuBiz Business case over Horsens Kommune: Return On Investment (ROI) for en dansk kommune der er skiftet fra EASY-systemet til InsuBiz EASY modul Om Horsens Kommune Horsens Kommune Horsens Kommune har

Læs mere

Magic Stats. - Samarbejde med brugere

Magic Stats. - Samarbejde med brugere Magic Stats - Samarbejde med brugere Institut for datalogi Aalborg Universitet INF 2 TITEL: Magic Stats - samarbejde med brugere. PROJEKTPERIODE: INF2, 3. februar - 30.maj, 2008 PROJEKT GRUPPE: i201ba

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

Nye testteknikker fra ISTQB - direkte fra hylderne. Ole Chr. Hansen

Nye testteknikker fra ISTQB - direkte fra hylderne. Ole Chr. Hansen Nye testteknikker fra ISTQB - direkte fra hylderne Ole Chr. Hansen TestExpo 29. Januar 2015 Præsentation Ole Chr. Hansen Managing Consultant Fellow SogetiLabs Global Innovation Team Blog - http://ochansen.blogspot.com

Læs mere

Medlemstilfredshed Teknisk Landsforbund 2010

Medlemstilfredshed Teknisk Landsforbund 2010 Medlemstilfredshed Teknisk Landsforbund 1 Indhold Indhold Introduktion Information om undersøgelsen og resultatforklaring 3 Tilfredshed og Loyalitet Vurderinger og sammenligninger 5 Hvordan skaber du større

Læs mere

Kommunikationsstrategi for Brugerklubben SBSYS WWW.SBSYS.DK SBSYS@RM.DK

Kommunikationsstrategi for Brugerklubben SBSYS WWW.SBSYS.DK SBSYS@RM.DK Kommunikationsstrategi for Brugerklubben SBSYS WWW.SBSYS.DK SBSYS@RM.DK Indholdsfortegnelse Ekstern Kommunikation... 3 Eksempler på kommunikation med eksterne interessenter... 4 Intern Kommunikation...

Læs mere

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

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

Læs mere

Optimering af fraværsregistrering

Optimering af fraværsregistrering Journal Optimering af fraværsregistrering Eksamensprojekt i Programmering C, klasse 3.4, 2011 AFLEVERET 09-05-2014 Indhold Abstract... Fejl! Bogmærke er ikke defineret. Problemformulering... 2 Produktet...

Læs mere

DEN GODE SAMTALE HÅNDBOG FOR LEDERE

DEN GODE SAMTALE HÅNDBOG FOR LEDERE DEN GODE SAMTALE HÅNDBOG FOR LEDERE 1 INTRO DE FØRSTE SKRIDT er en ny måde at drive a-kasse på. Fra at være a-kassen, der bestemmer, hvor, hvordan og hvornår den ledige skal være i kontakt med a-kassen,

Læs mere

Systemudviklings projekt. Nikolaj Boel Jensen Rasmus Thorslund Jensen Bo Mortensen Daniel Munch Lasse Abelsen

Systemudviklings projekt. Nikolaj Boel Jensen Rasmus Thorslund Jensen Bo Mortensen Daniel Munch Lasse Abelsen Systemudviklings projekt Nikolaj Boel Jensen Rasmus Thorslund Jensen Bo Mortensen Daniel Munch Lasse Abelsen 8. Juni 2009 Forord Denne rapport er skrevet på 4. semester på datamatiker uddannelsen. Rapporten

Læs mere

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

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

Læs mere

Supermarkedsmodellen for design af brugergrænseflade

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

Læs mere

Mailhosting op til 2 GB op til 4 brugere, pr. måned. Herefter pr. påbegyndte 10 GB, pr. måned

Mailhosting op til 2 GB op til 4 brugere, pr. måned. Herefter pr. påbegyndte 10 GB, pr. måned 14-06-2011 prisliste v. 1.0.1 Priser er vejl. DKK og ekskl. moms. Der tages forbehold for trykfejl og prisændringer. Der henvises til Generelle Bestemmelser og betingelser Gældende 30 dage fra dato Mainpoint

Læs mere

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

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

Læs mere

FORRETNINGSSTRATEGI SUNDHED.DK

FORRETNINGSSTRATEGI SUNDHED.DK FORRETNINGSSTRATEGI SUNDHED.DK INDHOLD 01 Om dokumentet 3 02 Sundhed.dk s forretning 4 02.1 Mission og vision 4 02.2 Sundhed.dk s position og marked 4 02.3 Sundhed.dk s fundament og leverancer 5 02.4 Målgrupper

Læs mere

Tirsdag: PROJEKTLEDELSE OG -ARBEJDE

Tirsdag: PROJEKTLEDELSE OG -ARBEJDE Tirsdag: PROJEKTLEDELSE OG -ARBEJDE Hvad Er det en god har idé? vi lært? (CBA/BC) Hvad har vi lavet? (projektevaluering) Hvornår har vi et projekt? (projektgeografi) Hvad skal vi levere? (produktmål) Interessentanalyse

Læs mere

Mindfulness hos familierådgivningen i Ikast Brande kommune - 20 socialrådgivere og 5 HK - Hanne Nørskov er leder af Familierådgivningen. Indhold.

Mindfulness hos familierådgivningen i Ikast Brande kommune - 20 socialrådgivere og 5 HK - Hanne Nørskov er leder af Familierådgivningen. Indhold. Mindfulness hos familierådgivningen i Ikast Brande kommune - 20 socialrådgivere og 5 HK - Hanne Nørskov er leder af Familierådgivningen Indhold. 1. Indledning v. Hanne Nørskov 2. Målinger opsummeret 3.

Læs mere

Kommunernes Ydelsessystem: Vejledning til business caseredskab

Kommunernes Ydelsessystem: Vejledning til business caseredskab Kommunernes Ydelsessystem: Vejledning til business caseredskab Version 1.0, maj 2014 Denne vejledning til en lokal business case suppleres af følgende dokumenter: Instruktion til udfyldelse af business

Læs mere

Hjælp til at opstille kompetencelæringsmål

Hjælp til at opstille kompetencelæringsmål 1 Hjælp til at opstille kompetencelæringsmål Dette skal hjælpe til at udstationeringer kan blive så målrettede som muligt. Vi definerer først begreberne kompetence og kompetenceudvikling. Derefter præsenterer

Læs mere

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

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

Læs mere

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

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

Punkt 9 - bilag 3. Vejledning vedr. brug af Cisco Jabber

Punkt 9 - bilag 3. Vejledning vedr. brug af Cisco Jabber Punkt 9 - bilag 3 vedr. brug af Cisco Jabber Region Sjælland 2014 INDHOLD 1. Organisation & Ansvar 2. Juridiske aspekter 3. Generel brug af Cisco Jabber Tilgængelighed Chat Skærmdeling Videosamtale Virtuelle

Læs mere

Hvordan udarbejdes en strategi

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

Læs mere

Ud af krisen. Software på tværs, 15. juni 2009

Ud af krisen. Software på tværs, 15. juni 2009 Ud af krisen Software på tværs, 15. juni 2009 Om Ative Agile udvikling og rådgivning Klassisk udviklingsmodel Krav Design Ændrer sig Implementering Tager for lang tid Springes over Mareridt Test Deployment

Læs mere

Cindie Mortensen, Merete Koudahl, Pernille Tramp Webdesign, gruppeprojekt exercise 7. Menu A/S

Cindie Mortensen, Merete Koudahl, Pernille Tramp Webdesign, gruppeprojekt exercise 7. Menu A/S Menu A/S Problemfelt MENU A/S (MENU) er en dansk design virksomhed og producent. MENU har specialiseret sig indenfor skandinavisk design samt deres evige stræben efter at lave noget originalt. De repræsenterer

Læs mere

Bilag 1 Tidsplan Version 0.9 05-05-2014 0

Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 ETAPER I UDVIKLINGSPROJEKTET... 3 2.1.1 ETAPE I - AFKLARING... 3 2.1.2 ETAPE II ANALYSE, DESIGN,

Læs mere

Lean gammel vin på nye flasker SCKK Excellence om Lean og arbejdsgange

Lean gammel vin på nye flasker SCKK Excellence om Lean og arbejdsgange Lean gammel vin på nye flasker SCKK Excellence om Lean og arbejdsgange 3. april 2006 Jørgen Kjærgaard Lean i historisk perspektiv en del af kvalitetstraditionen med TQM og Excellence 2 Toyota Production

Læs mere

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

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

Læs mere

2. Metode. 2.1 Interessentanalyse Interessenterne i projektet er vist i nedenstående figur: Aftalekalenderprojektet. Indledning

2. Metode. 2.1 Interessentanalyse Interessenterne i projektet er vist i nedenstående figur: Aftalekalenderprojektet. Indledning 2. Metode Indledning Projektet er udført med flg. faser: Foranalyse (uden iterationer) Analyse (udarbejdelse af kravspecifikation afsnit 9.1, herunder use case beskrivelser afsnit 9.2) Design af skærmbilleder

Læs mere

Modul 2 - "Usability at work" Usability i organisationer. Vær tålmodig. Ledelsens opbakning. Synliggørelse. Effektive arbejdsrutiner

Modul 2 - Usability at work Usability i organisationer. Vær tålmodig. Ledelsens opbakning. Synliggørelse. Effektive arbejdsrutiner World Usability Day 2006 14. november, Århus Modul 2 - "Usability at work" Af Kristian Krämer I dette modul var overskriften Usability at work og det dækkede bl.a. over usability-folkets arbejdsvilkår

Læs mere

Jobrotationsprojekt PIXI 2014/2015 Dagplejere og pædagogmedhjælpere Børn og unge, Norddjurs kommune Dynamisk projektbeskrivelse

Jobrotationsprojekt PIXI 2014/2015 Dagplejere og pædagogmedhjælpere Børn og unge, Norddjurs kommune Dynamisk projektbeskrivelse Jobrotationsprojekt PIXI 2014/2015 Dagplejere og pædagogmedhjælpere Børn og unge, Norddjurs kommune Dynamisk projektbeskrivelse Projektleder: Pia Christensen 06-06-2014 Indholdsfortegnelse FORORD... 2

Læs mere

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

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

Læs mere

Digital Identitet. Projektudvikling af www.virtualdating.dk

Digital Identitet. Projektudvikling af www.virtualdating.dk Synopsis Digital Identitet. Projektudvikling af www.virtualdating.dk Gruppe 14 Kasper Spaabæk, Allan Jonas, Trine Uldall, Jonna Bolette Degn Titel Digital Identitet. Formål Vi laver et datingsite (www.virtualdating.dk),

Læs mere

GUIDE TIL EN STRESSHÅNDTERINGSOG TRIVSELSPOLITIK

GUIDE TIL EN STRESSHÅNDTERINGSOG TRIVSELSPOLITIK GUIDE TIL EN STRESSHÅNDTERINGSOG TRIVSELSPOLITIK Guide til udarbejdelse og implementering af en stresshåndterings- og trivselspolitik Ejerskab Når en virksomhed skal udarbejde en stresshåndterings- og

Læs mere

Innovationens Syv Cirkler

Innovationens Syv Cirkler Innovationens Syv Cirkler Med denne gennemgang får du en kort introduktion af Innovationens Syv Cirkler, en model for innovationsledelse. Dette er en beskrivelse af hvilke elementer der er betydende for

Læs mere

Nøgletal og karakterbøger i byggeriet

Nøgletal og karakterbøger i byggeriet Nøgletal og karakterbøger i byggeriet Regler for evaluering af entreprenører, håndværkere, rådgivende ingeniører, arkitekter og bygherrer 9 Nøgletal og karakterbog Danske bygherrer bruger i stigende grad

Læs mere

Dynamisk hverdag Dynamiske processer

Dynamisk hverdag Dynamiske processer Dynamisk hverdag Dynamiske processer Verden og hverdagen er kompleks og i konstant forandring - og derfor skal den måde vi arbejder med projekter og implementering være enkel og forandringsparat. Agil

Læs mere

Vejledningen til proces for design af fremtidsmodellen

Vejledningen til proces for design af fremtidsmodellen Vejledningen til proces for design af fremtidsmodellen Januar 2014 Indhold 1. FORMÅL... 3 FORMÅLET MED DENNE PROCESVEJLEDNING... 3 2. FREMTIDSMODELLENS OMRÅDER... 3 2.1. AKTIVITETER... 4 DEFINER OVERORDNEDE

Læs mere

Lederen. Den udsatte medarbejder. Fastholdelse. Kollegagruppen SR/TR

Lederen. Den udsatte medarbejder. Fastholdelse. Kollegagruppen SR/TR Faktorer ved Lederen Den udsatte medarbejder Fastholdelse Kollegagruppen F a k t o r e r v e d S u c c e s f u l d e f a s t h o l d e l s e s f o r l ø b Med udgangspunkt i interviews med ledere, udsatte

Læs mere

Parforhold anno 2010. Undersøgelse udarbejdet af Institut for Krisehåndtering. Institut for Krisehåndtering november 2010 Side 1 af 13

Parforhold anno 2010. Undersøgelse udarbejdet af Institut for Krisehåndtering. Institut for Krisehåndtering november 2010 Side 1 af 13 Parforhold anno 2010 Undersøgelse udarbejdet af Institut for Krisehåndtering Side 1 af 13 Indholdsfortegnelse: Forord:... 3 Formål med undersøgelsen:... 3 Analysens fakta:... 3 Hvor meget tid bruger par

Læs mere

Selvevaluering. dine erfaringer med ledelse

Selvevaluering. dine erfaringer med ledelse Selvevaluering dine erfaringer med ledelse Velkommen Velkommen til din selvevaluering, som skal understøtte dine overvejelser omkring lederrollen. Selvevalueringen har to formål: Dels at give dig en introduktion

Læs mere

Indhold. Side 2 af 26

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

Læs mere

Situationsbestemt coaching

Situationsbestemt coaching Bag om coaching Ovenfor har vi fokuseret på selve coachingsamtalen med hovedvægten på den strukturerede samtale. Nu er det tid til at gå lidt bag om modellen Ved-Kan- Vil-Gør, så du kan få en dybere forståelse

Læs mere

Håndbog til projektledelse

Håndbog til projektledelse Mere info kontakt Julie Kirstine Olsen Udviklingskonsulent juols@ikast-brande.dk Tlf.: 9960 4153 Mads Ballegaard Konsulent mabal@ikast-brande.dk Tlf.: 9960 4021 Produceret af Håndbog til projektledelse

Læs mere

Business case. for. implementering af InCare på plejecenter med 40 beboere

Business case. for. implementering af InCare på plejecenter med 40 beboere Dato: 2012 J.nr.: xx Business case for implementering af InCare på plejecenter med 40 beboere Version: 3.2 2/11 Indholdsfortegnelse 1. Ledelsesresume... 3 2. Løsningsbeskrivelse... 4 Projektets navn eller

Læs mere

PRODUKTIONSSTYRING OG -PLANLÆGNING

PRODUKTIONSSTYRING OG -PLANLÆGNING PRODUKTIONSSTYRING OG -PLANLÆGNING Introduktion Er det egentlig præcist at tale om produktion når temaet er spiludvikling? For produktion dufter jo af faste procedurer, kendte milepæle, og definerede krav

Læs mere

Lærervejledning til Produktudvikling, produktion og service

Lærervejledning til Produktudvikling, produktion og service Lærervejledning til Produktudvikling, produktion og service Lærervejledningen er forfatternes bud på, hvordan bogen Produktudvikling, produktion og service kan bruges i den daglige undervisning. Vejledningen

Læs mere

Notat vedrørende erfaringer med den eksperimenterende metode blandt deltagere i Uddannelseslaboratoriets uddannelseseksperimenter

Notat vedrørende erfaringer med den eksperimenterende metode blandt deltagere i Uddannelseslaboratoriets uddannelseseksperimenter Notat vedrørende erfaringer med den eksperimenterende metode blandt deltagere i Uddannelseslaboratoriets uddannelseseksperimenter Udarbejdet af Merete Hende og Mette Foss Andersen, 2014 1 Formål Dette

Læs mere

Indkøbspolitik For EUC Sjælland.

Indkøbspolitik For EUC Sjælland. Indkøbspolitik For EUC Sjælland. Revideret juli 2011. 1 Indholdsfortegnelse: EUC Sjælland i tal...3 EUC Sjællands indkøbspolitik...4 Indkøbspolitikkens formål og mål...5 Indkøbspolitikkens omfang og afgrænsning...5

Læs mere

Mobile løsninger til salg, service og flådestyring. Jens Davidsen CEO WPA Mobile ApS.

Mobile løsninger til salg, service og flådestyring. Jens Davidsen CEO WPA Mobile ApS. Mobile løsninger til salg, service og flådestyring Jens Davidsen CEO WPA Mobile ApS. Indhold Historien Teknik Fordele Produkt Erfaringer Prisen Introduktion Historien Microsoft Lande / sprog Kunder DONG

Læs mere

MTU 2011 Medarbejdertilfredshedsundersøgelse

MTU 2011 Medarbejdertilfredshedsundersøgelse MTU 11 Medarbejdertilfredshedsundersøgelse Svarprocent: 91% ( besvarelser ud af 22 mulige) Enhedsrapport Indhold Indhold Introduktion til undersøgelsen 3 Hovedresultater: Arbejdsglæde og Loyalitet 5 Hvordan

Læs mere

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

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

Læs mere

PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER

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

Læs mere

Introducering af Flip MinoHD: http://celikshadow.dk/flip/

Introducering af Flip MinoHD: http://celikshadow.dk/flip/ Introducering af Flip MinoHD: http://celikshadow.dk/flip/ Ahmad Hahmoud Besir Redzepi Jeffrey Lai 04/05-2009 2.semester 3. projekt Indholdsfortegnelse: 1.0 Forord 3 2.0 Kommunikationsplan 4 3.0 Navigationsdiagram

Læs mere

Udbud med forhandling hvordan, med hvem og om hvad (direktiv 2014/24/EU) Advokat Torkil Høg 11. november 2014

Udbud med forhandling hvordan, med hvem og om hvad (direktiv 2014/24/EU) Advokat Torkil Høg 11. november 2014 Udbud med forhandling hvordan, med hvem og om hvad (direktiv 2014/24/EU) Advokat Torkil Høg 11. november 2014 1 Agenda 1. Introduktion 2. Udbud med forhandling udvalgte problemstillinger 2 1. Introduktion

Læs mere

SÅDAN FÅR MINDRE VIRKSOMHEDER SUCCES MED KOMPETENCEUDVIKLING

SÅDAN FÅR MINDRE VIRKSOMHEDER SUCCES MED KOMPETENCEUDVIKLING SÅDAN FÅR MINDRE VIRKSOMHEDER SUCCES MED KOMPETENCEUDVIKLING ER VIRKSOMHEDENS MEDARBEJDERE KLÆDT PÅ TIL FREMTIDEN? SÅDAN FÅR MINDRE VIRKSOMHEDER SUCCES MED KOMPETENCEUDVIKLING KOMPETENCEUDVIKLING = NY

Læs mere

Internet Information Services (IIS)

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

Læs mere

Leverings- og vedligeholdelsesvilkår for Moderniseringsstyrelsen lokale datavarehus LDV

Leverings- og vedligeholdelsesvilkår for Moderniseringsstyrelsen lokale datavarehus LDV Leverings- og vedligeholdelsesvilkår for Moderniseringsstyrelsen lokale datavarehus LDV Indhold 1. DEFINITIONER... 2 2. BAGGRUND OG FORMÅL... 2 3. MODERNISERINGSSTYRELSENS YDELSER... 3 4. INSTITUTIONENS

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

1. Baggrund og problemstilling

1. Baggrund og problemstilling 1. Baggrund og problemstilling 1.1 Baggrund Opgavestiller og fremtidig bruger af systemet er klinikken Tandlæge Annelise Bom 1. Opgaven udspringer af et ønske om at forbedre aftalestyringen. Nøgleordene

Læs mere

få en ny og bedre hjemmeside på få minutter Quick guide Del denne quick guide med alle som har glæde af en ny og bedre hjemmeside

få en ny og bedre hjemmeside på få minutter Quick guide Del denne quick guide med alle som har glæde af en ny og bedre hjemmeside få en ny og bedre hjemmeside på få minutter Quick guide Del denne quick guide med alle som har glæde af en ny og bedre hjemmeside 1 Alle har ret og råd til en professionel hjemmeside på få minutter GoMinisite

Læs mere