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

Størrelse: px
Starte visningen fra side:

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

Transkript

1 Systemudviklings projekt Nikolaj Boel Jensen Rasmus Thorslund Jensen Bo Mortensen Daniel Munch Lasse Abelsen 8. Juni 2009

2 Forord Denne rapport er skrevet på 4. semester på datamatiker uddannelsen. Rapporten afslutter et halvt semester med systemudvikling, der tager udgangspunkt i en fiktiv virksomhed kaldet STT 1. Indholdet i rapporten er baseret på en række opgaver, som inkluderer en analyse af mangler i STT, med henblik på udviklingsmetoder. Der vil også være en inspirationshåndbog, som beskriver forskellige udviklingsmetoder og deres fordele og ulemper. Til sidst i rapporten vil der være en case, hvor der skal laves et eksempel på, hvordan en planlægningsproces bliver gennemarbejdet. Gennem denne rapport vil der blive anvendt forkortelser for f.eks. teknologier og udviklings metoder, derfor vil de blive beskrevet første gang de anvendes og derefter vil forkortelsen blive anvendt. Et eksempel ville være: UP 2 Formål Ideen med denne rapport er, udover at besvare de spørgsmål der er blevet stillet, at udarbejde en inspirationshåndbog, som kan anvendes i forbindelse med hovedopgaven, der skal skrives efter denne eksamen. Håndbogen indeholder beskrivelser af metoder, og udviklingsmodeller samt klassificering af disse, dette bliver en fordel i forbindelse med hovedopgaven på næste semester, da mange teorierne kan genanvendes. 1 System Til Tiden 2 UP står for Unified Process og er en komplet plandreven udviklingsmetode. i

3 INDHOLD 1 Inspirations håndbog Inspirations Håndbog extreme Programming Scrum Unified Process Hvordan indrages prototyping? Prototyping og XP Prototyping og SCRUM Analyseforslag af et projekt Projektets størrelse Medarbejder ressourcer Definition af krav Kundekontakt Analyse af STT s problemer Analyse af System til tiden Procesorienteret fremgangsmåde Agile metoder Implementering Særligt aspekt i STT Vurdering af STT s udviklingsmetode Konfigurationsstyring Konfigurationsstyringsplan Estimering Personressourcer ii

4 4 Tandlæge Tang Projektplanlægning Valg af udviklingsmetoder Fremgangsmetode Use Case Use Case Prioteringsskema Fully dressed use case User Story Planning Game Estimering Burn down Chart Kravfastlæggelse Domæne model Arkitektur Prototyping Perspektivering Konklusion 41 iii

5 FIGURER 1.1 Figuren viser, hvordan et sprint ser ud i Scrum, det øverste element fra product backlog bliver til sprint backlog Eksempel på workflowet i de forskellige faser i UP Eksempel på skema til hjælp af metodevalg Boehm s graf for valg af projekt styring, med STT som udgangspunkt Eksempel på burn down chart efter endt sprint Forslag til en domæne model Forslag til systemets opbygning Forslag til en komplet system arkitektur Mock-up af protype til behandlingsvindue hos Tandlæge Tang. 36 iv

6 KAPITEL 1 Inspirations håndbog Dette kapitel indeholder en inspirations håndbog, denne håndbog vil beskrive forskellige systemudviklings- og projektplanlægningsmetoder. Endvidere vil der være en beskrivelse af forskellige tilgange til prototyping. Efter dette er der en beskrivelse af hvordan en analyse af et projekt udføres, og hvordan der ud fra dette kan vælges en systemudviklings- og projektplanlægningsmetode. 1.1 Inspirations Håndbog Denne sektion indeholder en beskrivelse og klassificering af forskellige systemudviklingsog projektplanlægningsmetoder. Som systemudviklings- og projektplanlægningsmetoder er der valgt følgende: extreme Programming, Scrum og UP. Disse er valgt baggrund af analysen i kapitel 2. Dette afsnit er baseret på teori fra: Craig Larmann Agile & Iteative Development. 1.2 extreme Programming XP er en agil udviklingsmetode som danner grundlag om følgende praktikker: Planning game: Planning game er XP s metode for at komme frem til tidsestimater. Som en del af dette skal der udarbejdes nogle User stories. Disse er baseret på scenarier fra virksomhedens hverdag. Meningen er at de udarbejdedeuser stories, skal opsummere den funktionalitet systemet, der udvikles, skal indeholde. Når der er skrevet User stories indgår de i planlægningsspillet, som er opbygget af tre faser. Den første fase er Exploration phase hvor hver User story bliver tidsestimeret. Er dette ikke muligt, opdeles User story en, eller 1

7 bliver skrevet om til nye User stories. Den næste fase er Commitment phase hvor, de forskellige User stories bliver sorteret efter tre kriterier: værdi, ricisi og hvor hurtigt det kan laves. Ud fra disse kriterier vælges der et Scope for User story ens omfang. Den sidste fase er Steering phase, hvor der udvælges den User story der skal implementeres, hvorefter denne testes. Fejler dette, kan en udbedring forsøges, eller starte forfra med at re-estimerer User story en. Lykkes det derimod, at implementere User story en kører planning game videre til næste User story, og processen gentages. Små udgivelser: Gennem planning game, laves der en plan for udgivelser af funktionalitet. Denne plan er short term, så der bliver udgivet ny funktionalitet med korte mellemrum. Derved formuleres der hurtigt et simpelt fungerende system, som kan udgives indenfor et kort tidsrum, og efterfølgende udbygges. Metaforer: Elementerne i systemet bliver beskrevet med ord. Dette giver alle udviklerne overblik over det komplette system. Det bevirker også at kommunikationen imellem udviklerne bliver optimeret. Simpelt design: På hvert givet tidpunkt skal designet af systemet være så simpelt som overhovedet muligt. Test før kodning: Inden der produceres noget kode, laver udviklerne fortløbende unit tests. Disse unit tests skal køre uden, fejlfrit. Kunden laver så test til, at teste slutfunktionaliteter. Hvis der opstår en fejl i koden, laves nye unit tests. Accepttest bliver afviklet så ofte som muligt, og resultatet af denne offentliggøres. Omstrukturering: Skal kunne foretages uden, at ændre noget af funktionaliteten, der findes i systemet. Endvidere kan omstruktureringer, af kildekoden, være nødvendigt for, at fjerne duplikater, forbedre kommunikationen, simplicisere eller tilføje fleksibilitet. Dette skal alt sammen være for, at forbedre den kildekode som udgør programmet. Parprogrammering: Alt programmel bliver produceret af to systemudviklere på en computer. Kollektivt ejerskab: Alle har rettigheder til at ændre, fjerne eller tilføje i kildekoden. Det vil sige at, alle udviklere har adgang til alt kode, hvilket betyder at hver eneste af par programmørene kan producere kode i alle moduler af systemet. Vedvarende integration: Byg systemet hver gang, en delopgave af en User Story er blevet færdig. Det er også vigtigt, at virksomheden forsætter med at teste, og lave nye tests, således at koden ikke bliver ubruglig hvis kravene ændres. 2

8 40 timers uger: Arbejd aldrig mere end 40 timer om ugen, og der skal ikke være overtid i mere end 14 dage. Tilgængelig kunde: Det skal hele tiden være muligt for udviklerne, at få kontakt til en kunde, hvis der i løbet af udviklingsprocessen skulle opstå nogle spørgsmål, eller noget der skal klargøres for udviklerne. Kode Standard: Det er vigtigt at have en kodestandard for den kode, der bliver produceret i projektet, således at udviklerne ikke skal bruge tid på at refactor koden på et senere tidspunkt. Anvendelse XP er specielt anvendelig i situationer, hvor kunden er i tvivl om det endelige produkt. Så der kan forekomme løbende ændringer i kravene. Samtidigt involverer XP kunden i projektet, hvilket hjælp den udviklende virksomhed til at,levere det produkt som kunden ønsker. Endvidere sikrer XP igennem de 12 overstående praktikker, at system udvikling bliver overskuelige gjort, for både udvikleren og kunden. XP hjælper også STT med, at holde styr bugettet da XP foreskriver, at udviklerne ikke må arbejde mere end 40 timer om ugen. De små releases sikrer, at udviklede produkt stemmer overens med kundens ønsker. Den færdige kode, burde fungere uden, at der skal debugges meget, da der til alt kode er skrevet unit-test. Krav til XP Kræver programmeringsdygtige medarbejdere. I STT s tilfælde bliver projektlederne faset ud og indgår i udviklingsholdet i en ny rolle. Det vil sige, at det kæver grundlæggende ændringer i virksomhedens organisation. U- lemperne ved XP er, at der kræves en konstant tilgængelig kunde, hvilket betyder at det bliver dyrere at udvikle software for kunden. En anden ulempe er den manglende dokumentation, det vil sige, at mange aftaler bliver indgået verbalt, og derfor let kan misforståes eller misfortolkes. Endvidere foreligger der kun et minimalt design, og beskrivelser af dette. 1.3 Scrum Scrum er en anden agil måde at planlægge på, den bygger ligesom XP på udvikling efter kundes ønsker. Scrum er opbygget af sprints, et sprint er en periode på typisk 30 dage. Scrum metoden bruger roller til, at administrere de enkelte dele af projektet. Disse roller er som følger: Product owner 1 er ansvarlig for funktionaliteten af produktet. Resultatet af dette bliver en product backlog som er en to-do liste. Denne product backlog bliver brugt til, at prioritere opgaver efter hvilken opgave der er best business for virksomheden. 3

9 Scrum master fungerer som en team leder for Scrum teamet. Scrum masteren er den person, mennesker uden for projektet henvender sig til. Det vil sige, at ingen udenfor projektet, kan henvende sig direkte til Scrum teamet. Scrum masteren afholder det daglige Scrum møde, hvor hver enkelt medlem af Scrum teamet bliver hørt om de kan gå videre med deres opgaver. Endvidere er det også Scrum masterens opgave, at lave burn down charts. Udover dette er Scrum masteren en del af Scrum teamet. Scrum team er et hold af udviklere bestående af typisk 6-8 personer, hvor 7 regnes for at være optimalt. Scrum teamet er ansvarlig for, at udvikle kildekoden til systemet. Teamet er en selvstyrende gruppe, som organiserer sig selv. Rollerne sikrer Scrum teamet et optimeret arbejdsmiljø, hvilket medfører en øget produktivitet. Samtidigt gør rollefordelingen det muligt for alle i Scrum teamet, at få hurtig og præcis svar på eventuelle spørgsmål. Når Scrum teamet er samlet, og har user stories 2 er de klar til,at påbegynde et sprint. Et sprint består af: Product backlog er et samlet sæt af funktioner, som product owneren har lavet og prioriteret. Disse funktioner er blevet lavet om til en todo liste hvor hver del tager ca. et sprint. Product backloggen bliver revurderet inden hvert sprint, da der kan være ændringer i, hvad der er best business for kunden. Det kan f.eks. være, at der i et forgående sprint er blevet lavet noget kode, som kræver meget debugging, så kan det være, at det er best business at få det gjort inden Scrum teamet starter på en ny task. Sprint backlog er den del af funktionerne, der skal implementeres i dette sprint, og er altid de øverste task i product backlog. Når først sprintet er i gang, er det ikke muligt at ændre funktionalitet. Resultatet af hvert enkelt sprint afsluttes med en demonstration af det fungerende software, hvor bl.a. product owner, brugere og andre repræsentanter for kunden, deltager. Dette udgør basis for evalueringsmødet, som fungerer som starten til det næste sprint. Som figuren, se figur 1.1, viser så arbejder Scrum teamet på en given sprint backlog. Sprint backloggen kan indeholde flere task fra produck backloggen, og bliver tilpasset den fastsatte tid et sprint skal vare. Hvis det viser sig, at opgaverne i sprintet mod forventning, er for komplekse, og derfor tager længere tid end antaget, kan der tages nogle tasks fra sprintet og 2 er defineret på samme måde som planning game fra XP i afsnit 1.2 4

10 Figur 1.1: Figuren viser, hvordan et sprint ser ud i Scrum, det øverste element fra product backlog bliver til sprint backlog placeres tilbage i produck backloggen. Det er Scrum masterens opgave, at administere sprintets omfang i forhold til tasks. [Burn down chart indsættes måske her] Til at kontrollere om Scrum teamet overholder tidsplanen bruges der et burn down chart. En burn down chart er en graf, der viser, hvor mange timer det vil tage, at løse alle opgaver i et sprint. Grafen viser om Scrum teamet er foran eller bagefter tidsplanen for sprintet. Burn down chartet opdateres hver dag. For at sikre at alle i Scrum teamet har noget at lave, eller kan lave noget, afholdes der hver dag et Scrum meeting. Et scrum meeting er et kort møde hvor Scrum masteren stiller hvert eneste medlem af Scrum teamet tre spørgsmål: Hvad lavede du i går? Hvad laver du i dag? Er der noget, der forhindre dig i, at forsætte med dette? Samtidig får alle medlemmer af Scrum teamet mulighed for, at ytre sig om sprintet eller hele projektet. Et Scrum meeting må gerne have flere deltagere end Scrum teamet, dog er det kun Scrum teamet som må tale under mødet. Ulempen ved Scrum er, at det kun er en forretningsmodel, og ikke yder nogen bistand til andre discipliner inden for software udvikling. For eksempel 5

11 yder Scrum ingen hjælp til, hvordan software skal udvikles. Samtidigt kræver Scrum ændringer i organisationen af en virksomhed, og kan tage lang tid, at indføre i en virksomhed. 1.4 Unified Process UP er en iterativ arbejdsmetode hvor det iterative består i, at alle udviklere arbejder sammen som et hold, og skal itererer gennem fire faser. Det er målet at projektet skal deles op i milepæle, hvor en milepæl skal være afsluttet inden den næste kan påbegynde. Nogle af de pratikker der anvendes i UP er, som følger: Udvikling foregår i små tidsintevaller. Udvikle de mest komplekse og vanskelige elementer tidligt i forløbet, samt kerne delen af arkitekturen. Sikre at der bliver leveret kvalitet til kunden. Tilpasse skiftende krav tidligt i processen. Alle arbejder sammen som et hold. UP kan deles op fire hovedfaser. I disse faser bliver de forskellige praktikker opfyldt. De forskellige faser er: Inception er den første fase og er som regel altid kort, og det er sjældent, at der er nogen form for iteration i denne fase. Aktiviteterne i denne fase kan f.eks. være, at finde de første krav, en business case samt at identificere de største risici. Disse business cases bliver omsat til use cases, som bruges, til at definere kravene til systemet. Det er også i denne, fase at de første meget utydelige, tidsestimater bestemmes. Elaboration er den næste fase. I denne fase kodes kerne arkitekturen og den/de mest komplekse use cases i projektet. Dette foregår i små iterationer. Ved starten af en iteration bestemmes, hvad denne iteration skal indeholde. Indholdet kan være alt fra at kode til at lave små krav. I denne fase kan use casene også revurderes, hvis nogle af dem, er i konflikt med kerne arkitekturen. Construction fasen er den fase, hvor det resterende system bliver konstrueret. Systemet bliver bygget ovenpå den eksisterende arkitektur, som er lavet i elaboration fasen. Selve udviklingen foregår stadig i små iterationer. I denne fase bliver de første tests lavet, og dokumentationen til systemet bliver også skrevet. 6

12 Transition i denne fase bliver systemet udgivet, først som en release kandidat, denne version bliver så reviewet og der bliver givet feedback, og de eventuelle fejl rettes. Hvis det er tilfældet, at det udviklede system skal erstatte et gammelt, så er det også i denne fase at dette sker. UP bygger på milepæle, en milepæl for inception fasen kan f.eks. være, at identificere nogle af de risici, som findes i projektet. For elaboration kan det f.eks. være, at blive enige om, hvordan kerne arkitekturen udarbejdes. En milepæl for construction kan være, at systemet er klart til at blive leveret. Et eksempel for den sidste fase, trasition, kan være at brugerne er tilfredse,. Figuren, se figur 1.2 viser, hvad der skal foregå i hvilke faser. I toppen ses Figur 1.2: Eksempel på workflowet i de forskellige faser i UP de fire faser, og de stiplede linjer er skæringslinjer for, hvornår de forskellige faser slutter. Faserne bliver delt op i iterationer, og disse udgør en del af milepælene for fasen, og når alle milepæle er opfyldt er fasen afsluttet. Figur 1.2 viser i hvilken faser de forskellige aspekter af udviklingen er vægtet. Eksempelvis udgør Business modelling størstedelen af inception fasen, men er stadig en del af de følgende faser. UP benytter roller til, at styre udviklingsholdet. Der findes fire hovedkategorier indenfor rolle begreber i UP: Kunde som navnet antyder, er dette den egentlige kunde eller en kundeansvarlig. Det er denne eller de personer, som udviklerne henvender sig til, hvis der er spørgsmål. 7

13 Udviklere denne gruppe tæller de mange forskellige typer af roller, som bruges når der udvikles software. Dette er f.eks. database designer, brugergrænseflade designer, system analytiker, tester, software arkitekt og kode udvikler. Management udgør projektlederne og proces ingeniørerne. Det er denne gruppe af personer, der har ansvaret for at planlægge, hvad der skal ske i de enkelte iterationer. Det er også disse personer, som har ansvaret for, at udviklerne arbejder sammen, og får udviklet det som er planlagt i iterationerne. Andre de sidste personer i dette, kan være grafikere, som skal lave grafik til systemet grænseflade. En teknisk forfatter, som skal skrive brugervejledninger. Dette kan også være eksterne konsulenter. Roller hjælper udviklingsholdet med, at bevare overblikket, da alle medarbejdere ved hvilke personer der, er ansvarlig for de forskellige områder. Dette betyder, at det er let, at arbejde på tværs af forskellige arbejdsområder. Ulemperne ved UP er, at det kræver meget dokumentation, og at udviklingsholdet ikke har den samme forståelse for hvordan slutproduktet skal se ud. Endvidere kræver det, at kravene er veldefinerede, for er udviklingsholdet først nået til Construction fasen, og kravene ændres, så vil det kræve ændringer, det udarbejdet materiale fra de foregående faser (Inception- og Elaboration). Dette er dyrt i både tid og penge. UP kræver også erfaring, da det kan være svært at fastlægge længden af de forskellige iterationer. Hvis en iteration bliver for tidskrævende, kan der forekomme ubalance i arbejdsflowet, da der kan være nogle medarbejderer, der kun arbejder på en lille del af projektet og disse kan mangle arbejde. De medarbejdere kan så risikere, at blive overbebyrdet i næste iteration. 1.5 Hvordan indrages prototyping? Prototyping er et værktøj til, at hjælpe udviklere med at designe systemer, udfra hvad kunden ønsker. Udviklerne demonstrere dele af systemet for kunden, så kunden får et indtryk af systemet. Kunder giver feedback til udviklerne om hvordan de ønsker systemet skal fungere. Dette hjælper både udviklere og kunden, da kunden er med til at bestemme, hvad system skal kunne. Kunden er også med til at bestemme hvordan designet skal se ud. På baggrund af dette har udviklerne har nemmere ved, at fastlægge kravene til systemet. Overordnet kan prototyping deles op i to former: Kast-væk prototyper og Evolutionære prototyper. Kast-væk prototyper bygger på, at når prototypen har tjent sit formål, så kasseres den, hvorimod en Evolutionær prototype videreudvikles til det endelige produkt. 8

14 1.5.1 Prototyping og XP XP ligger op til, at der er mulighed for at vælge en evolutionær form for prototyping. Hvor systemet bliver bygget op omkring prototypen ved at den udbygges for hver planning game iteration. Dette kan dog diskuteres, da der i XP udvikles på produktet fra første linie kode, og derfor ikke betragter det som prototyping. Dette kan dog være en ulempe, da systemets brugergrænseflade kan risikerer at være underudviklet. Er udviklerne bevidst om denne faldgruppe, er det dog oplagt at bruge kast-væk prototyper i XP, da disse kan anvendes i spikes til evt. test, eller proof-of-concept. Grundet kundens store inddragelse i udviklingen ved brug af XP, er prototyping en generel god ide, da arbejdsgangen i XP allerede minder om evolutionær prototyping Prototyping og SCRUM SCRUM er mere en planlægnings metode, og kræver derfor at brugeren af Scrum følger en, eller dele af en eller flere, udviklingsmetoder. Et eksempel ville være at SCRUM blev brugt til, at styre et projekt, og supplerede de individuelle SCRUM sprints med f.eks. UP som udviklings metode. Med dette som grundlag, er Prototyping også et tilvalg til SCRUM, og en generelt god ide. Ligesom i XP vil det give mere kontakt med kunden, og vil resultere i feedback, der kan hjælpe med, at få designet systemet, og få specifiseret kravne. SCRUM bygger, som andre agile udviklingsmetoder på, at der sagtens kan ske ændringer undervejs i projektforløbet. Derfor vil det være optimalt at vælge en evolutionær prototype, som kan udbygges eller tilpasses som kravene ændres. 1.6 Analyseforslag af et projekt I software udvikling, er det vigtigt, at der allerede ved projektets opstart gøres nogle overvejelser omring metodevalg, eller evt. metodekombination. Dette er vigtigt for, at kunne håndtere projektet hensigstmæssigt ift. planlægning, arbejdsfordeling og optimering. Inden projektet opstartes, er der en række faktorer, som indgår i valget af metode. Disse faktorer udledes af en forudgående analysefase, som har til formål, at fastsætte en metode som passer til projektforløbet. En sådan analysefase tager bl.a. følgende faktorer op til overvejelse: Projektets størrelse Alt efter hvor omfattende projektet er, herunder f.eks. mængden af dokumentation, er det muligt at argumentere for forskellige valg af metode, eller en kombination af disse. Ved større projekter med meget dokumentation, 9

15 som bestræber sig på, at kortlægge hele udviklingsprocessen, kan det være en fordel, at anvende et traditionel metode så som UP. Ulempen ved at benytte ovenstående metode, bliver dog tydelig hvis projektet evt. tager en uventet drejning, f.eks. at krave på forhånd ikke er kendte, eller i væsentlig grad ændres undervejs. Metoden kræver desuden meget tid og planlægning, og det er derfor, som tidligere nævnt, i høj grad væsentligt hvor mange personer der er involveret i projektet. Alternativet til den forholdsvis dokumentations krævende UP model, er de dynamiske og agile metoder. Heriblandt findes bl.a. SCRUM og XP. Disse metoder er langt mere tilpasningsdygtige, og generelt mere modtagelige overfor ændringer i kravspecifikationen efter projektets start. Ligeledes er agile metoder menneske orienterede, frem for proces orienterede. Det betyder at de agile metoder i høj grad bestræber sig på at arbejde i synergi med mennesker, from for imod dem Medarbejder ressourcer Hvor UP kræver flere medarbejdere indvolveret i processen som helhed, forkuserer de agile metoder hovedsagligt på mindre teams. SCRUM arbejder f.eks. meget sjældent med teams over ni personer inkl. testere og designere. Dog viser det sig tit, at smertegrænsen ligger tættere på maks seks personer. Ved at arbejde i små teams, minimeres bl.a. faktorer som fejlkommunikation og afhængighed af sociale relationer, sidstnævnte gør sig især gældende ved outscourcing af projektet. Vores egen efaring har eksempelvis lært os, igennem vores virksomhedsbesøg hos Logimatic, at samarbejde over landegrænser kan være problematisk. I dette tilfælde var problemet primært mangel på engelsk kundskaber fra indernes side. Vores efaring har desuden også vist os, at det ikke altid er en fordel at tildele et projekt flere resscourcer i form af medarbejdere, hvis projektet er tidsmæssigt bagefter og derfor ude af stand til at overholde sin deadline. Yderligere kræves det, at virksomheden har tiltro til udviklernes ekspertise i forbindelse med overvejelser om, at anvende en agil udviklingsmetode. Det er vigtigt for projektet, at udviklerne besidder stor ekspertise og er i stand til, at arbejde effektivt eftersom ansvaret bliver øget ved brug af agile metoder. Det vil sige, hvis virksomheden har et team af udviklere af svingende kvalitet og kvalifikationer kan det være en fordel, at overveje brug af mere tunge metoder. Eksempel på dette kunne være UP, hvor der bruges meget tid på dokumentation for at udviklerne i sidste ende ikke har samme mængde ansvar som i agile metoder Definition af krav Tunge metoder, så som UP, forsøger så vidt muligt at undgå ændringer løbende i processen. Det betyder, at findes der et projekt, hvis krav ikke er præcist definerede fra begyndelsen, kommer det højst sansynligt til at koste tid og penge at tilpasse dokumentationen til de reviderede krav. Derfor 10

16 er det fordelagtigt at vælge et agil metode når der arbejdes under betingelser, hvor kravene på forhånd ikke er kendte. Ligeledes er agile metoder menneske orienterede, frem for proces orienterede, jvf. afsnit Kundekontakt Ved opstart af projekter og valg af tilhørende metode/metoder bør der overvejes, hvorvidt det kræves, at kunden eller en repræsentant for kunden har mulighed for, at være tilstede under forløbet. Eksempelvis kan en fase i UP strække sig over længere tid, eftersom der er meget planlægning og dokumentation, inden en prototype kan være klar til brugertests. I UP er det primært i inceptionfasen, at kunden bliver inddraget når en prototype skal præsenteres i form af en tænke-højt test. Senere bliver kunden også indvolveret i accept-testen. I forhold til UP kræves det f.eks. i SCRUM, som er en agil metode, en langt højere grad af tilstedeværelse af kunden, da der her er mere kommunikation mellem denne og SCRUM teamet. F.eks. afsluttes et sprint i SCRUM hovedsageligt med en demonstration samt evaluering af sprintets resultat, hvor kunden, teamet og repræsentanter fra virksomheden er tilstede. Disse er alle overvejelser der bør undersøges grundigt, inden en projektmodel fastlægges. Som nævnt er der fordele og ulemper ved stort set alle modellerne, målet er at finde frem til den model, som passer bedst ind i et givent projekt. Dette udelukker dog ikke, at der f.eks. kan kombinere f- lere af disse modeller. En mulighed kunne f.eks. være, at virksomhedem, vælger at de vil arbejde med SCRUM i sine projekter, dog er virksomheden ikke helt tilfreds med den måde at selve sprintet forgår på, og vælger derfor at arbejde iterativt i denne fase istedet. Dette ville tilbyde virksomheden fordelene ved SCRUMs agile arbejdsmetoder, mens den samtidigt ville kunne undgå den overflod af dokumentation som UP foreslår. Virksomheden har derved formået, at tilpasse en projektmodel til hvad, passer dem bedst. Som virksomhed kan de evt. vælge at sætte sine faktorer op i et skema som vist i figur 1.3. Det giver et hurtigt overblik over hvilken valg af metode, der vil være oplagt, at bruge i en given situation. Skemaet tager dog ikke højde for kombination af metoder. Figur 1.3 ligger i høj grad op til, at der arbejdes med en agil arbejdsmetode. Dog kan det blive problematisk, at kunden kun i mindre grad er til rådighed under udviklingsforløbet, men ikke mere end det er muligt at arbejde udenom. Kunden kunne f.eks. deltage i daily SCRUM møderne telefonisk. At projektets krav ikke er definerede fra starten, taler desuden yderligere for at arbejde med XP som metode. Generelt er XP s small releases kortere i varighed end SCRUM s sprints, ligesom at der i XP er mulighed for at ændre i releaset undervejs. Når der derimod arbejder med et sprint i SCRUM, som typisk har en varighed af 30 dage, arbejdes der efter en sprint backlog, 11

17 Analytist faktor Værdi Valg af metode Størrelse af Lille Agil arbejdsmetode projektet (Projekt) (XP - SCRUM) Antal medarbejde Få Agil arbejdsmetode til rådighed (6-8 personer) (XP - SCRUM) Er projektets krav Nej Agil arbejdsmetode defineret fra starten (Flere krav er usikre) (XP - SCRUM) Hvor meget er I mindre grad Disciplineret kunden til rådighed (Primært arbejdsmetode under projektforløbet telefonisk) (UP) Figur 1.3: Eksempel på skema til hjælp af metodevalg. som kan tilpasse. 12

18 KAPITEL 2 Analyse af STT s problemer 2.1 Analyse af System til tiden Denne del af rapporten vil analysere virksomheden System til tiden (STT), og give en række forslag til løsninger på deres problemer. Til at begynde med, bliver virksomhedens problemer identificeres. Ud fra opgavebeskrivelsen af virksomheden, er følgende problemer blevet udledt, som vil danne grundlag for de forskellige løsningsforslag: 1. Mange forskellige opgaver. 2. Rift om specialister. 3. Kan ikke fastholde dygtige folk. 4. Projekter forsinkes. 5. Udviklere arbejder på flere projekter, ergo: forsinkelse på et projekt kan gå ud over et andet. 6. Mange fejl i afleverede systemer. 7. Leverancer fra underleverandøre er forsinket og/eller fejlbehæftet. 8. Dårlig arbejdsdeling og kommunikation. 9. Rettede fejl i kildekode, kan give problemer med anden kildekode. 10. Ingen opbevaring af gammel kildekode. 11. Udviklere har svært ved, at levere et design, der er godt nok til de kunder, hvor design er afgørende. 13

19 Andre faktorer der er afgørende, eller har betydning for virksomheden: Kunderne inddrages i alle udviklingsfaserne. Tid og pris. Funktionalitet er ikke længere nok for kunden. Virksomhendes overordnede problem er, at de mangler struktur, og dette gør processforbedring aktuelt, da dette give virksomheden nogle retningslinjer, de kan bruge til, at optimerer deres arbejdsgang Procesorienteret fremgangsmåde STT s direktør viser interesse for, at få mere styr på virksomhedens processer, samt at få dokumenteret hvordan de skal arbejde, for at sikre at kunder får leveret systemer, der lever op til deres forventninger 1. STT kan med fordel vælge og benytte sig af en procesorienteret og plandreven fremgangsmåde så som UP. Ved at arbejde med de fire faser som indgår i UP, afhjælpes de strukturelle problemer STT har. De rammer som UP sætter op omkring plandreven udvikling betyder, at arbejdsgangen i virksomheden bliver struktureret og mere forudsigelig. Disse elementer indgår i kravene til CMMI niveau 2 og 3. For at opnå CMMI niveau 2, kræves der grundlæggende projektledelse, hvilket blandt andet opfyldes gennem følgende processer i UP: Projektplanlægning Måling og Analyse Proces- og produktkvalitetskontrol Projektplanlægning som er et af kravene til CMMI niveau 2, opfyldes i høj grad gennem milepæle, faseinddeling og Gant kort 2. Analyse kravet bliver ligeledes opfyldt med UP, gennem Inception fasen, som beskrives nærmere i 1.4. Produkt- og kvalitetskontrol sker bl.a. gennem acceptstests. CMMI niveau 3 kræver bl.a. beslutninger baseret på analyser. Use case prioriteringsskema betyder, at beslutninger der afgør hvilke dele af systemet der skal prioriteres højest og testes mest, bliver taget på et velbegrundet grundlag. Forslag til konkrete standardiserede processer der, kan afhjælpe STTs problemer med hensyn til systemudviling: Unittests 1 Side 3, afsnit 3 i case beskrivelsen 2 14

20 Automatiserede tests, som tester de vigtigste funktionaliteter/usecases CVS, Subversion, SourceSafe eller lignende til versionsstyring Disse tre simple tiltag vil afhjælpe punkterne: 6, 9, 10 i afsnit 2.1. Derudover vil det være muligt for nyansatte, at få større mulighed for selv at løse problemer, der tidligere er forekommet i virksomheden, i forbindelse med systemudvikling. Dette bliver muligt med dokumentation vedrørende fejlrettelse og refactoring. Med standardiserede processer sikres det f.eks. at ved ændring i kode, er en defineret proces, som skal udføres på én bestemt måde. Dette giver udviklerne en større effektivitet, samt bedre overblik over ændringer af systemet. Sammen med automatiserede tests på de vigtigste funktioner/use cases sikrer en test for, om ændring forårsager problemer andre steder i koden. Dokumentation af refactoring og fejlretning kan samtidig aflaste specialister, der er meget rift om. Efterhånden som problemer og løsninger bliver dokumenteret, kan mindre erfarne systemudviklere få hjælp til lignende problemer i stedet for, at skulle spørge specialisterne til råds. Samtidig øges mulighederne for at fastholde specialister, og gode medarbejdere. Bedre projektstyring og processtandardiseringer vil samtidig mindske frustration hos specialister, da der opnås størrer forudsigelighed og øget mulighed for, at gentage tidligere successer. Samtidig er det i mindre grad nødvendigt for specialisterne, at tage hånd om de mindre erfarene medarbejdere, som nævnt i punktet over. Processtadardiseringen igennem CMMI øger chancerne for bedre, at kunne kontrollere og forudse projekters fremgang. CMMI giver en bedre projektstyring, og muligheden for at kunne placere udviklere således, at de arbejder på de projekter, hvor udviklerne er mest effektive Agile metoder Scrum kan bruges til organisering og planlægning af projekter, og ligger især vægt på business value. Ved at implementere Scrum i STT kan følgende problemstillinger afhjælpes: Mange forskellige opgaver Projekter forsinkes Udviklere arbejder på flere projekter / forsinkelse på et projekt kan påvirke andre projekter. 15

21 Dårlig arbejdsdeling og kommunikation Implementeres Scrum i STT opnår de en systematisering af opgavetyper via product backlogs. STT er meget uorganiseret mht. projektstyring. Med de værktøjer Scrum tilbyder til dette aspekt af systemudvikling kan, STT med høj sansynlighed forbedre deres projektstyring ved, at benytte sig af f.eks. product backlogs, burn down charts, sprints og scrum masters. Mere specifikt vil product backlogs afhjælpe problemer med forskelligheden i opgaver, og eventuelt give mulighed for, at fordele de ressourcer, der er til rådighed i virksomheden. Eftersom STT også har problemer med forsinkelser, vil implementering af Scrum s burn down charts også give et større overblik over eventuelle forsinkelser. Dette betyder, at allerede tidligt i enkelte projekter ses det om projekterne kræver justering af arbejdskraft. Scrum Masteren, fungerer som en problemknuser, filter og dirigent afhjælper flere af de problemer STT har. For eksempel sørger Scrum Masteren for, at teamet ikke bliver unødigt forstyrret. Dette bevirker, at tidsplaner bliver lettere at overholde. Daglige Scrum meetings er med til at sikre, at alle på et givent projekt ved, hvor langt alle andre er med deres del af projektet. Overordnet kan de problemer som STT oplever mht. projektstyring, afhjælpes ved, at bruge de værktøjer, som Scrum tilbyder. Den høje kundekontakt som Scrum ligger op til, passer desuden også godt sammen med det arbejde STT allerede har udført i form af,at opbygge et nært tillidsforhold til kunderene ved, at inddrage dem i alle udviklingsfaserne. Virksomheden oplever desuden, at funktionalitet ikke længere er nok for kunden. Et problem som kan afhjælpes ved at benytte Scrum, da hyppig kommunikation i designfasen kan opfange ønsker om ændringer tidligt i forløbet. XP 3 er en udbredt agil udviklingsmetode. Den fokusere på samarbejde, hurtig og tidlig udvikling og solide udviklingsteorier. Den er grundlagt på fire værdier; kommunikation, simplicitet, feedback og mod 4. Ud af XP s tolv hovedpraktikker 5, afhjælper især fire af dem STT s problemer med afleverede systemer. Disse fire er: Test før kodning Parprogrammering Vedvarende integration Omstrukturering (refactoring) 3 Extreme Programming 4 values.jsp 5 De tolv hovedpraktrikker kan ses i afsnit

22 Der ligges meget vægt på testing, hvor der skriver tests allerede inden kodningen påbegyndes kodningen. Det vil sige at udviklerne til at arbejde i et meget testdrevent miljø, hvor refactoring, parprogrammering og kontinuerlig integrering bliver en naturlig del af arbejdsprocessen. Dette begrænser eller eliminere nogle af de problemer STT oplever, nemlig punkterne seks og ni. Den dårlige arbejdsdeling og kommunikation som virksomheden oplever, kan ligeledes afhjælpes af XP eller Scrum s standupmeetings. Da dette giver alle på teamet en bedre indsigt i hvor langt andre er med deres dele af et projekt, tilgodeses problemerne med dårlig kommunikation. Det større overblik giver ligeledes bedre muligheder for at tage arbejdsdelingsbeslutninger på et bredere grundlag, med mere viden om de forskellige dele af projektet. Samtidig med, at alle intrassanter får et større overblik over fremgangen ved de enkelte dele via burn down charts. De resterende problemstillinger som STT står overfor, kan afhjælpes ved en blanding af Scrum og XP. Disses metoder bevirker, at udviklerne bliver udsat for langt færre frustrationsfaktore såsom, blive flyttet frem og tilbage mellem forskellige projekter. STT nævner desuden, at de har haft problemer med gammelt kode, som er blevet tabt igennem tiden, fordi de ikke gemmer kopier af dette. Dette kan forholdsvis let afhjælpes, ved at benytte et versionsstyrings værktøj såsomcvs/svn, som nævnt i afsnit Alternativt kan virksomheden eventuelt selv udvikle et versionsstyringssystem, hvis det vurderes til at være profitabelt. Endeligt har STT problemer med underleverandører, eksempelvis leverancer er forsinkede og/eller fejlbehæftede. Dette har naturligvis bevirket at visse projekter lider under disse forhold. Vælger STT at benytte agile udviklingsmetoder, er det med til, at kontakten med kunden bliver et samarbejde, frem for en forhandling. Dette vil formindske risikoen for fejlbehæftede og/eller forsinkede leverancer fra underleverandøre, da der vil være en mere åben dialog mellem virksomhed og leverandør Implementering For at STT kan få succes med en agil udviklingsmetode kræver det, at virksomheden er opmærksom på de faldgrupper som kan forekomme i agile arbejdsmetoder. Eksempler på faldgrupper: Projektledere skal ikke længere lede udviklerne (teamet) Som tidligere projektleder kan der være en stor trang til, at fortælle teamet, hvordan de skal arbejde eller løse et konkret problem. Mange projektledere er vant til, at arbejde med ledelse og planlægning, hvorimod deres rolle nu er Scrum Master. Dette betyder at vedkommende at projektlederne skal fokusere på at fjerne forhindringer, tilbyde ressourcer og fungere 17

23 som filter mod resten af organisationen. Udover dette fra dette skal Scrum Masteren, indgå som en del af Scrum teamet. Yderligere arbejde tilføjes efter sprintets start Product owner kan have en tendens til, at ville tilføje ændringer efter et sprints start. Der vil altid være ændringer i ønsker, til programmet. Det er vigtigt, at der igennem et sprint fastholdes de opgaver, som ved sprintets start er aftalt. Derved opnåes kontrol og stabilitet over processen. Opdages det, at estimeringerne fejlvuderet, er det tilladt at ændre i sprint backloggen, ved enten at slette eller tilføje tasks. Product Owner ikke involveret i prioritering Det er vigtigt ved anvendelse af Scrum at der er en kontakt til kunden. Det er product ownerens ansvar, at bestemme hvordan productbackloggen prioriteres og derigennem vurdere, hvilke opgaver, der skal indgå i næste sprint. Det er procuct owneren, der ved hvad der er vigtigst for kunden. Mangel på evaluering Det er vigtigt ved anvendelse af Scrum, at der indgår feedback ved afslutningen i et sprint. Dette sikrer at den del af system, der er blevet udviklet i det foregående sprint, også stemmer overens med kundens forventninger. Resultatet skal stemme overens, med hvad kunde for mest business value uf af. Flere Scrum Masters STT har mange projektledere, og det ikke alle der nødvendigvis skal fungere som Scrum Masters. Det er vigtigt for Scrum Teamet, at der er nogle retningslinier for en iteration, samt en brun down char der viser Scrum Teamet s fremgang i projektet. Disse opgaver tager Srum masteren sig af. Det er vigigt for et Scrum Team at kun en person varetager dette. Ved at der kun er en Scrum Master gør det kommunikationen lettere for Scrum Teamet. Ingen dokumentation Scrum er ikke ensbetydende med ingen dokumentation. Det skal forståes på den måde, at dokumentation skal udarbejdes, hvis det tilføjer værdi til produktet, og ikke bare for at følge en bestemt proces definition. Det samme gælder design diagrammer eller lignende. Finder teamet det nyttigt skal det laves, ellers er det spildt arbejde. Teamet er ikke sat ind i Scrum 18

24 Det er vigtigt at hele teamet, det vil sige; Product owner, Scrum Master og Scrum team har en forståelse Scrum, og de værdier denne metode tilbyder. Et svagt led i kæden kan give problemer i det daglige arbejde. Da medarbejderen ikke vil være i stand til, at se projektet i større perspekstiv. Scrum Meeting Scrum meetings må ikke blive for lange eller ufokuserede. Det er meningen at de, så vidt muligt, skal overståes på under 20 minutter, og udelukkende fokusere på Scrum-relaterede spørgsmål. Hvert sprint skal afkaste en del af produktet Når en iteration er færdig er målet, at det udviklede software er blevet integreret, testet og tilpasset det øvrige system. Det er dog ikke nødvendigt at iterationen afsluttes med et færdigt produkt, da dette kan kræve flere iterationer. 19

25 KAPITEL 3 Særligt aspekt i STT 3.1 Vurdering af STT s udviklingsmetode Firmaet(STT) har i deres nuværende arbejdsmetode store, generelle problemer med brug og planlægning af ressourcer. Dette set i forhold til tid, medarbejdere med de nødvendige kvalifikationer samt, at administrer deres nuværende systemer, samt deres systemer under udvikling. Yderligere har de, grundet tidspres, problemer med, at systemer med fejl i, bliver leveret til kunderne, hvilket i sidste ende giver problemer med estimering af ressourcer i forhold til support. I forhold til disse problemstillinger kan STT med fordel overveje, at gøre brug af metoder til estimering af medarbejder ressourcer samt tidsestimering. Endvidere vil det være en fordel i forhold til deres produkt releases, at udvikle systemerne i form af mindre versioner med dertilhørende baselines, så STT derved i langt højere grad undgår fejl i færdigudviklede produkter Konfigurationsstyring Når en virksomhed skal til at udvikle store og meget komplekse systemer, vil de ofte opdage, at systemet som helhed kan bestå af mange forskellige delkomponenter. Disse delkomponenter vil i de fleste tilfælde være små softwaremoduler med bestemte versionsnumre. Der kan også være tale om eksempelvis brugervejledninger eller datafiler, som er tilknyttet eksisterende systemer. Den proces, at sammensætte disse komponenter/moduler, så de udgør et samlet softwaresystem kaldes for konfigurering og kan være en meget omfattende arbejdsopgave at udføre manuelt eftersom der kan være mange forskellige filer med bestemte versionsnumre samt håndtering af deres indbyrdes afhængigheder. Til dette formål er der udviklet forskellige 20

26 værktøjer til automatisering, eksempelvis Java programmet Ant 1. I forhold til STT vil det være oplagt, at arbejde med konfigurationsstyring eftersom de derved får et større overblik over deres udvikling af systemer samt får et overblik over, hvilke kunder, der har hvilke versioner af systemer Konfigurationsstyringsplan Inden virksomheden går i gang med, at anvende konfigurationsstyring er det vigtigt, at der bliver gjort overvejelser omkring faste rammer, som virksomheden kan arbejde inden for. Til at hjælpe med, at opstille disse kan virksomheden stille sig selv følgende spørgsmål: Hvad skal styres (kravsspecifikation, designdokumenter, programmer, testdata m.v.)? Hvordan skal de identificeres? Hvordan skal de opbevares? Hvem er ansvarlig? Politikker for ændringskontrol og versionsstyring. Processen omkring brug af værktøjer. Registrering i database m.v Estimering Et af de største problemer for STT er deres nuværende estimering af projekter, herunder medarbejder ressourcer og tid. For at kunne forbedre dette kan STT overveje, en ny tilgang til estimering. SCRUM ville være et godt alternativ til deres nuværende planlægning og arbejdsmetoder. SCRUM er ikke en decideret udviklingsmetode, da det hovedsageligt kun er projektplanlægningen som SCRUM tager udgangspunkt i, udviklingsmetoden er helt op til virksomheden. SCRUM ville være godt for STT på grund af estimerings værdierne i SCRUM, samt SCRUM s muligheder for, at håndtere løbende ændringer i projektforløbet. I SCRUM er det Product owner der står for estimeringen af opgaver i projektet, hvilket giver fastere rammer for dem, der er involveret i projektets udvikling. Produkt owner laver en Product backlog med samtlige opgaver der skal laves for at projektet kan siges at være færdigt. Ud fra denne liste, estimere og planlægger produkt owner de forskellige opgaver efter Business value, og ligger dem med højst ROI 2 i toppen af listen ROI står for Return of investment 21

27 Ud fra denne liste bestemmes der et antal opgaver fra toppen, som kan indgå i et Sprint som ofte er svarende 30 dage. Denne nye liste kaldes for Sprint backlog Personressourcer I STT er der problemer med, at medarbejdere bliver rykket frem og tilbage på forskellige projekter, samt at få medarbejdere med ekspert viden nok til at blive i virksomheden. Dette gør det svært for STT, at overholde tidsestimater på selv meget simple opgaver. STT s nuværende udviklingsmetode virker umiddelbart meget agil, da virksomheden fortager mange små ændringer løbende i systemerne, hvilket gør at medarbejdere med ekspert viden bliver flyttet fra opgave til opgave, og ikke kan fokuserer 100% på én opgave. Det er nødvendigt for STT at skabe fastere rammer for deres medarbejdere, hvilket også vil resultere i bedre arbejdsvilkår for dem, samt skabe bedre kommunikation i virksomheden. Dette er nødvendigt da STT har svært ved, at holde på deres medarbejde. Virksomheden mangler en vis struktur der gør at medarbejdere trives i det daglige arbejde, og ønsker at blive i virksomheden. Det er her de fastere rammer kommer ind i billedet, de tidligere nævnte punkter som konfigurationsstyring, generel planlægning og estimeringer er med til, at skabe orden i projekterne, og vil resulterere i at medarbejderne er mindre stressede. Konfigurationsstyrringen vil hjælpe til med at medarbejdere ikke bliver fjernet fra vigtige opgaver, og at løse små problemer ved individuelle kunder, eftersom ændringer kun bliver lavet efter der er godkendt en request change form som indgår i et systems næste release/version. 22

28 KAPITEL 4 Tandlæge Tang Dette kapitel vil arbejde mod et løsningsforslag til Tandlæge Tang s nye system. Kapitlet vil indeholde planlægning af projektet, samt dele af løsninger til, et design som kan implementeres. 4.1 Projektplanlægning Når der skal laves en planlægningen af et projekt, er den første opgave, at vurdere hvilken projektplanlægnings- og udviklingsmetode, der bør vælges til at gennemføre projektet. Dette har Barry Boehm 1 lavet en graf, som kan hjælpe med. Figur 4.1 viser denne graf, hvor den er blevet udfyldt med værdier, der er udledt fra virksomheden STT. STT er valgt som udgangspunkt da store dele af rapporten er skrevet med henblik på STT som virksomhed. dog er aspekter fra Tandlæge Tang projektet blevet overvejet, og taget med i vurderingen. Figur 4.1 læses på følgende måde: De fem akser repræsentere forskellige områder af et projekt Personale, Dynamik, Kultur, Størrelse og hvor kritisk projektet er. Hver akse er blevet vurderet ud fra det nye projekt, og STT som virksomhed. Personale: STT har, som beskrevet tidligere i afsnit 2.1, haft problemer med, at holde på de højtuddannet og kompetente medarbejdere. Derfor ligger Personale aksen helt i top, STT s mandskab består hovedsageligt af knapt så kompetente folk (level 1 folk). 1 Forsker ved University of Southern California, Los Angeles, CA

29 Personale ( % level 1) ( % level 2 & 3 ) Hvor kritisk ( Tab skyldt af defekter ) Dynamik ( % Krav-ændringer/måned ) Mange liv 0 Enkelt liv Essentielle fonde Fonde Komfort Agil Diciplineret Størrelse ( # medarbejder på projektet ) Kultur ( % Trives med kaos vs. orden ) Figur 4.1: Boehm s graf for valg af projekt styring, med STT som udgangspunkt Dynamik: Beskriver hvor mange ændringer per måned der sker i projektforløbet. Da projekt oplægget har en grundig liste af krav, er det blevet vurderet at det er nemt at fastligge en kravspecifikation, og at der derfor ikke sker mange ændringer i forløbet. Kultur: Kulturen måles på hvor mange medarbejdere der trives bedst med kaos frem for orden. Hos STT har der gennem deres sidste projekter været meget kaos, bla. med at medarbejdere bliver flyttet fra projekt til projekt, og at de på baggrund af dette har overskrevet en del deadlines. Udfra dette er det konkluderet at STT ikke trives med kaos. Kultur aksen er derfor også helt ude hvor medarbejderne trives bedst med orden. Størrelse: Beskriver antallet af medarbejdere der, kan knyttes til projektet. STT har på nuværende tidspunkt 89 medarbejdere ansat, det er derfor valgt at de har mange ansatte til rådighed til projektet, omkring 50 medarbejder. Størrelse aksen ligger derfor i midten. Hvor kritisk: beskriver nogle kritiske faktorer som er med til at bestemme hvor kritisk udviklingen af projektet er. På baggrund af dette er det blevet vurderet at systemet ikke er en kritisk implementation, da virksomheden sagtens kan anvende deres gamle system, eller endda anvende en booking bog. Hvor kritisk aksen er derfor helt i bund. Når de forskellige akser er blevet vurderet for et projekt, giver der en indikation af, hvilken udviklingsform, der bør vælges til projektet. I dette 24

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

Responsivt Design - DMAA0213. Afgangsprojekt DMAA0213

Responsivt Design - DMAA0213. Afgangsprojekt DMAA0213 Responsivt Design - DMAA0213 Afgangsprojekt DMAA0213 Jesper Bjørn Andersen 18-06-2015 5. semester, afgangsprojekt - Responsivt Design Vejleder: Gunhild Marie Andersen Afsluttet: 18 Juni 2015 Deltager:

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

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

Kvalitetssikring og agile udvikling

Kvalitetssikring og agile udvikling Kvalitetssikring og agile udvikling Gæsteforelæsning for dsoftark-e10 på Århus Universitet Dagsorden Hvem er jeg og hvad er min baggrund i test og agile? Hvad kan I forvente? Agile og scrum Kvalitetssikring

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

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

Agil softwareudvikling i praksis. v/ Thomas Schou-Moldt, Lead Architect, Miracle A/S

Agil softwareudvikling i praksis. v/ Thomas Schou-Moldt, Lead Architect, Miracle A/S Agil softwareudvikling i praksis v/ Thomas Schou-Moldt, Lead Architect, Miracle A/S Thomas Schou-Moldt, Lead Architect Ansat i Miracle A/S (siden 2008) Arbejder som arkitekt / tech lead / teknisk projektleder

Læs mere

Projektarbejde med scrum- metoden

Projektarbejde med scrum- metoden Projektarbejde med scrum- metoden Indhold Indhold... 1 1 Indledning... 2 2 Roller og terminologi i scrum... 3 Opgavestilleren... 3 Scrum Masteren... 3 Projektgruppen... 3 Sprint... 3 3 Møder... 3 Planlægningsmødet...

Læs mere

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

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

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

Læs mere

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

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

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

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

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

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

Styregruppeformænd i SKAT Kort & godt (plastkort)

Styregruppeformænd i SKAT Kort & godt (plastkort) Håndbogen for Styregruppeformænd i SKAT Kort & godt (plastkort) 80% af alle projekter, hvor der er uigennemskuelighed fejler Lange projekter er mere risikofyldte end korte Transparente projekter har oftere

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

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

Administrationssystem med Android applikation Driving Academy

Administrationssystem med Android applikation Driving Academy Dette er procesrapporten til Bacheloropgaven på University College Nordjylland, omhandlende udviklingen af et Administrationssystem til Driving Academy. Opgaven indeholder alt information og dokumentation

Læs mere

Projektledelse - og ledelse af mennesker

Projektledelse - og ledelse af mennesker Projektledelse - og ledelse af mennesker Udvikling/ Mennesker/ Resultater Projekter er en arbejdsform, der kan fremme innovation, udvikling, samarbejde og helhedsorienterede løsninger. Arbejdsformer og

Læs mere

fra udvikler til leder med Pomodoro-teknikken Troels Richter 2009

fra udvikler til leder med Pomodoro-teknikken Troels Richter 2009 fra udvikler til leder med Pomodoro-teknikken Troels Richter 2009 Baggrund Professionel software udvikler gennem 9 år Knap 2 års erfaring som SCRUM Master (projektleder) Leder for 4-7 mand gennem det seneste

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

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

Lederens ressourceoptimering

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

Læs mere

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

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

Gruppe: 2 Hold: MulB Årgang 2013 Lærere: Merete Geldermann Lützen & Jesper Hinchely

Gruppe: 2 Hold: MulB Årgang 2013 Lærere: Merete Geldermann Lützen & Jesper Hinchely Bannerpage: http://spicegirls.creativefolder.dk/bannerpage/ Landingpage: http://spicegirls.creativefolder.dk/ René Skovgaard Andersen cph-ra73@cphbusiness.dk Stig Hamborg Nielsen cph-sn9@cphbusiness.dk

Læs mere

Agil-model versus V-model set i lyset af en testers dilemmaer

Agil-model versus V-model set i lyset af en testers dilemmaer Agil-model versus V-model set i lyset af en testers dilemmaer 1 Præsentation Foredragsholder Ane Clausen: Cand.Scient i Datalogi Københavns Universitet, Danmark Gift, 3 børn 25 års erfaring med IT: 12

Læs mere

SYNOPSIS 1. SEMESTER 2013 E-CONCEPT DEVELOPMENT

SYNOPSIS 1. SEMESTER 2013 E-CONCEPT DEVELOPMENT SYNOPSIS E-CONCEPT DEVELOPMENT INDHOLD 1. JONAS KROGSLUND HVEM ER JEG?... Side 3 2. PRÆSENTATION & MOTIVATION... Side 3 3. FAGLIGE UDFORDRINGER & PROBLEMER... Side 4 3.1 SCRUM...... Side 4 3.2 KRAVSPECOFIKATION...

Læs mere

PRINCE2 med tusind ord. Andy Murray, PRINCE2 (2009) lead author og direktør for Outperform UK Ltd. AXELOS.com. The Stationery Office 2011

PRINCE2 med tusind ord. Andy Murray, PRINCE2 (2009) lead author og direktør for Outperform UK Ltd. AXELOS.com. The Stationery Office 2011 PRINCE2 med tusind ord Andy Murray, PRINCE2 (2009) lead author og direktør for Outperform UK Ltd AXELOS.com White Paper September 2011 Indhold 1 Hvad er PRINCE2? 3 2 Fordele ved PRINCE2 3 3 Principper

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2 UC Effektiviseringsprogrammet Projektgrundlag Business Intelligence version 1.2 9. september 2014 1 Stamdata Stamdata Projektnavn (forventet): Projektejer: Projekttype: Business Intelligence It-chef Hans-Henrik

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

Guide til IT projekter i den fællesoffentlige projektmodel

Guide til IT projekter i den fællesoffentlige projektmodel DEN FÆLLESOFFENTLIGE PROJEKTMODEL Guide til IT projekter i den fællesoffentlige projektmodel Dato: 22.06.2015 Version: 1.0 1 Projektledelse af it-projekter Denne guide tager udgangspunkt i særlige forhold

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

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

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

PRINCE2 - et strategisk valg

PRINCE2 - et strategisk valg PRINCE2 - et strategisk valg Per Palmkvist Knudsen, IT-direktør JP/Politikens Hus Per Palmkvist Knudsen fører dig gennem en rejse af faldgruber og succeser med PRINCE2, herunder: - Hvordan organiserer

Læs mere

Peter Grynderup Poulsen

Peter Grynderup Poulsen 6. marts 2014 Peter Grynderup Poulsen pgpoulsen@gmail.com 30 22 45 24 Allégade 4, 7600 Struer www.pgpoulsen.dk Min baggrund indenfor softwareudvikling spænder meget bredt. Jeg har arbejdet med hjemmesideudvikling

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

Tryg base- scoringskort for ledere

Tryg base- scoringskort for ledere INSTITUTIONENS NAVN OG ADRESSE: INSTITUTIONENS LEDER: INSTRUKTØRENS NAVN: STARTDATO Tryg base- scoringskort for ledere Et værktøj til at evaluere din organisation før og efter jeres udviklingsarbejde med

Læs mere

Værktøj 2: Kortlægning af arbejdspresset

Værktøj 2: Kortlægning af arbejdspresset 12 Værktøj 2 Værktøj 2: Kortlægning af arbejdspresset Ved hjælp af værktøj 2 kan du undersøge, om der er for stort arbejdspres blandt den gruppe af medarbejdere, du har personaleansvar for. For stort arbejdspres

Læs mere

Musik afspiller Michael Frøstrup Andersen

Musik afspiller Michael Frøstrup Andersen Musik afspiller Michael Frøstrup Andersen Professionshøjskolen University College Nordjylland Professionsbachelor i softwareudvikling University College Nordjylland 1 Teknologi og Business Professionsbachelor

Læs mere

Lean Construction-DK s. Guide til bedre planlægning med Last Planner System

Lean Construction-DK s. Guide til bedre planlægning med Last Planner System Lean Construction-DK s Guide til bedre planlægning med Last Planner System Introduktion Last Planner System er et værktøj i Lean Construction udviklet specielt til byggeriet og med hensyn til byggeriets

Læs mere

Vidensmedarbejdere i innovative processer

Vidensmedarbejdere i innovative processer Vidensmedarbejdere i innovative processer Vidensmedarbejdere i innovative processer af direktør og partner Jakob Rasmussen, jr@hovedkontoret.dk, HOVEDkontoret ApS 1. Indledning Fra hårdt til blødt samfund

Læs mere

Kvalitetssikring af IT udvikling hos TDC

Kvalitetssikring af IT udvikling hos TDC Kvalitetssikring af IT udvikling hos TDC Kvalitetsrevisor Henning Sams Har være ansat hos TDC siden 1976 og har arbejdet med kvalitet i ca. 10 år, primært som QAér og Proceskonsulent. Underviser bl.a på

Læs mere

ALLERØD - HØRSHOLM LÆRERFORENING TEAMSAMARBEJDE

ALLERØD - HØRSHOLM LÆRERFORENING TEAMSAMARBEJDE ALLERØD - HØRSHOLM LÆRERFORENING TEAMSAMARBEJDE August 2014 For at give inspiration og support til teamene på skolerne har Kreds 29 samlet en række oplysninger og gode ideer til det fortsatte teamsamarbejde.

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

7. Referencer til andre værktøjer. 8. Sammenhæng med internationale standarder. 9. Referencer til Projektledelse Teori og praksis. 10.

7. Referencer til andre værktøjer. 8. Sammenhæng med internationale standarder. 9. Referencer til Projektledelse Teori og praksis. 10. Projektlederens værktøj 7. Referencer til andre værktøjer Nr. Navn Sammenhæng med Kritisk sti (CPM) 4.3.3 Tidsplan Udarbejdelse af tidsplan er forudsætningen for at kritisk sti kan findes 4.4.2 Successiv

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

Projektlederuddannelsen

Projektlederuddannelsen Projektlederuddannelsen Intensiveret fokus på egen praksis Projektlederen skal kunne skabe og facilitere resultater og udvikling af organisation og mennesker. De traditionelle metoder og værktøjer skal

Læs mere

Bilag 15 Leverandørkoordinering

Bilag 15 Leverandørkoordinering Bilag 15 Leverandørkoordinering Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 3 LEVERANDØRENS ANSVAR... 4 4 LEVERANDØRENS KOORDINERINGS- OG SAMARBEJDSFORPLIGTELSE...

Læs mere

Sikre gevinstrealisering

Sikre gevinstrealisering White Paper v1.0-2013 PORTEFØLJELEDELSE OG EFFEKT Topledere, mellemledere og programledere har ansvar for virksomhedens samlede udviklingsplaner samt den indbyrdes prioritering heraf. Med udgangspunkt

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

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

Projektlederens roller og kompetencer. Cases til Projektlederens roller og kompetencer

Projektlederens roller og kompetencer. Cases til Projektlederens roller og kompetencer Cases til Projektlederens roller og kompetencer Palle Ragn 1/9 Bibliografiske oplysninger Kursus: Lokalitet: Afgangsprojekt, Diplom uddannelsen i ledelse JCVU, Århus, Danmark Forfatter: Palle Ragn, 160364

Læs mere

Agil test tilgang - erfaringer fra projekter

Agil test tilgang - erfaringer fra projekter Agil test tilgang - erfaringer fra projekter af Michael Roar Borlund November 2011 Image Area Agenda Introduktion Agil test Fremtidsvision Agil test tilgang Agil opbygning i QC Resumé og Spørgsmål 2 Introduktion

Læs mere

Værdibaseret styring og optimering af projektporteføljen

Værdibaseret styring og optimering af projektporteføljen 17. April 2007 Værdibaseret styring og optimering af projektporteføljen Programchef Thomas Steinmetz, G4S Teamleder Charlotte Blou Sand, Creuna Copyright Creuna Danmark A/S Om Creuna Skandinavisk IT-konsulenthus

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

Nordsjællands Landskabsservice

Nordsjællands Landskabsservice Nordsjællands Landskabsservice Bekræftelse på udvikling af Typo3 hjemmeside med Ekstranet Dato: 22. Januar 2009 Udarbejdet af Bo Nørgaard, Projektleder Scan Designs A/S Esromgade 15 2200 Kbh. N CVR-nr.:

Læs mere

Software test i Socialstyrelsen. af: Jan Kristensen. Nov 2013

Software test i Socialstyrelsen. af: Jan Kristensen. Nov 2013 Software test i Socialstyrelsen af: Jan Kristensen Nov 2013 Agenda Lidt om Socialstyrelsen IT i Socialstyrelsen Software test QA Udviklingsmetode Agurkemetoden Test cases Test automatisering Afslutning

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

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

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

Læs mere

Lean i Faaborg-Midtfyn kommune

Lean i Faaborg-Midtfyn kommune Lean i Faaborg-Midtfyn kommune Direktionen har vedtaget at igangsætte et pilotprojekt i Faaborg-Midtfyn kommune indenfor lean. Lean indføres for at sikre en ensartet værdiskabende og resultatskabende metode

Læs mere

Fredag d. 26. februar kl. 16.00

Fredag d. 26. februar kl. 16.00 25. januar 2010 / SHA Understøttelse af en bedre projektstyring i Konkurrencestyrelsen Konkurrencestyrelsen har i efteråret 2009 gennemført en proces omkring øget fokus på planlægning og prioritering af

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

procesdrevet implementering I produktionsvirksomheder

procesdrevet implementering I produktionsvirksomheder RAPIDVALUE til AX 2012 procesdrevet implementering I produktionsvirksomheder med udgangspunkt i best practice Bryd med de sidste 20 års tilgang til ERPimplementering Veldokumenterede Best Practice forretningsprocesser

Læs mere

Møder til glæde og gavn i Vesthimmerlands Kommune

Møder til glæde og gavn i Vesthimmerlands Kommune Møder til glæde og gavn i Vesthimmerlands Kommune Møder til glæde og gavn? Møder, møder, møder Du kan sikkert nikke genkendende til, at en betragtelig del af din arbejdstid bruges på forskellige møder.

Læs mere

Din partner i udvikling

Din partner i udvikling Din partner i udvikling Få overblik over dine opgaver Opnå konkurrence fordele Skab merværdi for dine kunder Spar tid gennem effektivisering Overblik gennem indsigt NOVAQ as er et udviklingshus, der bygger

Læs mere

Best Practice for it og automationsprojekter Huskeliste med råd og erfaringer

Best Practice for it og automationsprojekter Huskeliste med råd og erfaringer Best Practice for it og automationsprojekter Huskeliste med råd og erfaringer Allan P. Kjær, Ph.D. (E), senior specialist IT og automation, COWI A/S Der er mange måder at planlægge og gennemføre et industrielt

Læs mere

BANNERPROJEKT 1.SEMESTER. Tine Hechmann, Josephine Jacobi, Mai Lyngby & Mettemarie From

BANNERPROJEKT 1.SEMESTER. Tine Hechmann, Josephine Jacobi, Mai Lyngby & Mettemarie From BANNERPROJEKT 1.SEMESTER Tine Hechmann, Josephine Jacobi, Mai Lyngby & Mettemarie From INDHOLDSFORTEGNELSE: Indledning... 2 Problemformulering... 2 Formål... 3 Mål... 4 Processen... 4 Planlægning... 5

Læs mere

Harmoni. Med SAP PI. Når tingene går op i en højere enhed. Kort & Godt. January 2012

Harmoni. Med SAP PI. Når tingene går op i en højere enhed. Kort & Godt. January 2012 January 2012 3. årgang, nummer 1 Harmoni Med SAP PI Når tingene går op i en højere enhed Godt nytår! Vi er kommet ind i 2012 med fuld fart, og vi glæder os til et fortsat godt samarbejde med kunder og

Læs mere

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt Scope Management ITU 11-09-2013 @janhmadsen Dagsorden Oplægsholder Projektstyring Scope Management i en fælles kontekst Definitioner Scope Management - styring af omfang ved projektets start under projektets

Læs mere

4. SEMESTER XP PROJEKTOPGAVE

4. SEMESTER XP PROJEKTOPGAVE 4. SEMESTER XP PROJEKTOPGAVE Udarbejdet af: Klasse: Dato: Linje: Sted: Dan Buhr Larsen, Thomas Gilg, Nicolaj Roos og Casper Cederberg Tr07dat2 20. marts 2009 Datamatiker, 4. semester Erhvervsakademiet

Læs mere

CV Jakob Niemann. Resumé: Nøglekvalifikationer. Personlighed. Født: 24/02 1976

CV Jakob Niemann. Resumé: Nøglekvalifikationer. Personlighed. Født: 24/02 1976 Jakob Niemann IT Konsulent Født: 24/02 1976 Rosendalsgade 11, 2. TV. 2100 København Ø Tlf: +45 2859 9808 JakobNiemann@gmail.com Resumé: Test og Quality Manager med mere end 15 års IT erfaring. Har stor

Læs mere

SPIL med tidsplan. Formål: Kernestof: Vejledning til opgaven:

SPIL med tidsplan. Formål: Kernestof: Vejledning til opgaven: Side 1 SPIL med tidsplan Formål: arbejde selvstændigt og sammen med andre i større problembaserede projektforløb og anvende metode til at planlægge, gennemføre og evaluere projektforløbet dokumentere og

Læs mere

Præsentation af styregruppeaftale. Marts 2015

Præsentation af styregruppeaftale. Marts 2015 Præsentation af styregruppeaftale Marts 2015 Release v. 2.2 marts 2015 INDHOLDSFORTEGNELSE 1.Materiale til præsentation af styregruppeaftalen 1.1 Introduktion til styregruppeaftalen og rammer for styregruppens

Læs mere

Agile metoder og kontrakter

Agile metoder og kontrakter Agile metoder og kontrakter 24. september 2009 Myllerup Consult, Hasseltoften 11, 8361 Hasselager +45 2834 9084, info@myllerup.dk Images: Disney Dream Works Indhold Scrum introduktion Processens ritualer

Læs mere

Application Management Service

Application Management Service Application Management Service I dette Whitepaper vil vi beskrive nogle af vores erfaringer med Application Management. De fleste virksomheder har på et tidspunkt lavet, eller fået lavet, en mindre applikation,

Læs mere

BackEnd Programmering PHP

BackEnd Programmering PHP 17708 08/ 02/ 2013 BackEnd Programmering PHP Prototype (CMS system) 371615m02dka.sub.ots.dk/historyspot eller linket CMS system på: qrguide.mmd.eal.dk Login CMS Username: admin Password: 1234 Source kode

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

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

Inspirationskatalog. Introduktion

Inspirationskatalog. Introduktion Inspirationskatalog Introduktion Inspirations kataloget er udarbejdet på baggrund af de statsfinansierede praksisnære innovationsprojekter. Rammen for de praksisnære innovationsprojekter er sat op omkring,

Læs mere

Opskriften på vellykkede OPI er tre grundlæggende råd

Opskriften på vellykkede OPI er tre grundlæggende råd Opskriften på vellykkede OPI er tre grundlæggende råd 2015 SIDE 2 Opskriften på vellykkede OPI er tre grundlæggende råd Pjecen er udarbejdet af Rådet for Offentlig-Privat Samarbejde Carl Jacobsens Vej

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

Center for Sundhedsinnovation

Center for Sundhedsinnovation Center for Sundhedsinnovation Business case for Telemedicin Behandling over afstand Christian Graversen, DI ITEK 30. December 2011 Version 1.0 Business case for Telemedicin Behandling over afstand 1. Ledelsesresume

Læs mere

GPS stiller meget præcise krav til valg af målemetode

GPS stiller meget præcise krav til valg af målemetode GPS stiller meget præcise krav til valg af målemetode 1 Måleteknisk er vi på flere måder i en ny og ændret situation. Det er forhold, som påvirker betydningen af valget af målemetoder. - Der er en stadig

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

DAFA s. HACCP-guidelines. I henhold til DS 3027. DAFA Side 1 af 9

DAFA s. HACCP-guidelines. I henhold til DS 3027. DAFA Side 1 af 9 s HA-guidelines I henhold til DS 3027 Side 1 af 9 s HA guidelines for Operatører. Afsnit 1 1.1. Hvad er HA? Side 3 1.2. HA-processen Side 4 1.3. Flowdiagram for HA-systemet Side 5 1.4. Kontrol og rapportering

Læs mere

Kvartalsrapport vedr. fase 1 af SKATs systemmodernisering for 1. kvartal 2007

Kvartalsrapport vedr. fase 1 af SKATs systemmodernisering for 1. kvartal 2007 Skatteudvalget SAU alm. del - Bilag 156 Offentligt Notat Skatteministeren Hovedcentret Strategi og Udvikling Projektkontoret Dato 25. maj J. nr. 07-061430 Kvartalsrapport vedr. fase 1 af SKATs systemmodernisering

Læs mere

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Projektstyring

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Projektstyring Udgave 1 2. SEMESTERPROJEKT Gruppe 5 Secure O matic Projektstyring Benjamin Sørensen, 02284 Tomas Stæhr Hansen, 03539 Stefan Nielsen, 02829 Mubeen Ashraf, 9279 Hussein Kleit, 9281 SECURE O MATIC Projektstyring

Læs mere

ETC sæt strøm til projektstyringen

ETC sæt strøm til projektstyringen ETC sæt strøm til projektstyringen Sådan får du succes med projektestimering Få styr på projekter og deadlines Denne publikation indeholder en gennemgang af den nye ETC-funktion i TimeLog Project. Med

Læs mere

RAMMEAFTALEBILAG A - KRAVSPECIFIKATION

RAMMEAFTALEBILAG A - KRAVSPECIFIKATION RAMMEAFTALEBILAG A - KRAVSPECIFIKATION Niels Juels Gade 13 1022 København vd@vd.dk EAN 5798000893450 Postboks 9018 Telefon 7244 3333 vejdirektoratet.dk SE 60729018 2 af 6 KRAVSPECIFIKATION Mindstekrav

Læs mere

SAS Standardarbejde i Administration og Service

SAS Standardarbejde i Administration og Service DI-version 2014-12-17 SAS Standardarbejde i Administration og Service Alle rettigheder tilhører DI 2-5-4 - SAS - Ledelsens Vejledning - 2014-12-17 side 1 af 8 Instruktion til kaizenleder Rettigheder DI

Læs mere

INDHOLDSFORTEGNELSE. Forord... 9

INDHOLDSFORTEGNELSE. Forord... 9 INDHOLDSFORTEGNELSE Forord... 9 Kapitel 1 Projektkompetencer... 11 Hvorfor projektkompetencer?... 11 Projektformens udbredelse... 14 Projektorganiseringens arbejdsmiljø... 19 Projektfeltets teorier...

Læs mere

INDHOLDSFORTEGNELSE FORORD... 9

INDHOLDSFORTEGNELSE FORORD... 9 INDHOLDSFORTEGNELSE FORORD... 9 KAPITEL 1 PROJEKTKOMPETENCER.... 11 Hvorfor projektkompetencer?.... 11 Projektformens udbredelse... 14 Projektorganiseringens arbejdsmiljø... 19 Projektfeltets teorier...

Læs mere

Lokal APV-proces i UCL 2014

Lokal APV-proces i UCL 2014 VEJLEDNING TIL APV-GRUPPEN Lokal APV-proces i UCL 2014 Udarbejdet af HR og Kommunikation Indledning Arbejdsmiljøloven kræver, at der gennemføres en arbejdspladsvurdering (APV) af det fysiske og psykiske

Læs mere

Kompetenceprofil for civil leder på nederste ledelsesniveau HOVEDFUNKTIONSDATA HOVEDOPGAVER

Kompetenceprofil for civil leder på nederste ledelsesniveau HOVEDFUNKTIONSDATA HOVEDOPGAVER Kompetenceprofil for civil leder på nederste ledelsesniveau HOVEDFUNKTIONSDATA Funktionsbetegnelse Funktionsniveau Forudsætninger Hovedopgaver for funktionen Civil lederstilling på nederste 1 ledelsesniveau.

Læs mere

STAMDATA RESULTATER UNDERVEJS. (1-5) Hvad kunne du ønske dig mere af? Besvarelse. Projektnavn. Kunde. Leverandør. Udfyldt af (kunde/leverandør)

STAMDATA RESULTATER UNDERVEJS. (1-5) Hvad kunne du ønske dig mere af? Besvarelse. Projektnavn. Kunde. Leverandør. Udfyldt af (kunde/leverandør) STAMDATA Besvarelse Projektnavn Kunde Leverandør Udfyldt af (kunde/leverandør) Udfyldt af (navn + rolle) RESULTATER UNDERVEJS Punktets relevans I meget høj I høj Hverken eller I mindre Slet ikke (1-5)

Læs mere