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

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

extreme Programming Kunders og udvikleres menneskerettigheder

extreme Programming Kunders og udvikleres menneskerettigheder extreme Programming Software Engineering 13 1 Kunders og udvikleres menneskerettigheder Kunder: At sætte mål og få projektet til at følge dem At kende varighed og pris At bestemme softwarefunktionalitet

Læs mere

DANMARKS NATIONALBANK LEVER AGIL UDVIKLING STADIG I DET VILDE VESTEN

DANMARKS NATIONALBANK LEVER AGIL UDVIKLING STADIG I DET VILDE VESTEN DANMARKS NATIONALBANK LEVER AGIL UDVIKLING STADIG I DET VILDE VESTEN Sikkerhed og Revision 2013 Martin Falk-Hansen & Svend M Er sikkerhed og revision et problem i agil udvikling? Og i givet fald hvorfor?

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

sådan kører vi processen

sådan kører vi processen VERTICA sådan kører vi processen Når du som ny kunde skal have udviklet en ny e-handelsløsning eller app til din virksomhed, kan det være svært at overskue den proces, der følger. Hos Vertica har vi været

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

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 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

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

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

[A20] Kick off document and process description. 1 of 5

[A20] Kick off document and process description. 1 of 5 [A20] Kick off document and process description 1 of 5 kick off document Huge Lawn Projekt Kick-Off Alle projekter og ideer er forskellige. For at vi kan give et reelt bud på dit/jeres projekt eller idé

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

Vejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3)

Vejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3) Vejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3) Version 2.10 / 04-01-2018 / PHM Indholdsfortegnelse Indledning... 3 Baggrund... 3 Iterativ udvikling med ASE-modellen... 4 Udviklingsprocessen

Læs mere

Bilag 16. Den Iterative Model. Til Kontrakt. Den Nationale Henvisningsformidling

Bilag 16. Den Iterative Model. Til Kontrakt. Den Nationale Henvisningsformidling Bilag 16 Den terative Model Til Kontrakt OM Den Nationale Henvisningsformidling Bilag 16 Den terative Model Side 1/9 NSTRUKTON TL TLBUDSGVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil

Læs mere

Pain Treatment Survey

Pain Treatment Survey Pain Treatment Survey Projektoplæg Projektoplæg til fælles udviklingsprojekt, i samarbejde mellem KLONK og smerteeksperter fra Sverige, Danmark og Norge www.klonk.dk Indholdsfortegnelse Baggrund... 2 Idé...

Læs mere

(Bilaget ligger på i pdfformat og word-format.)

(Bilaget ligger på  i pdfformat og word-format.) BILAG 7 DEN AGILE METODE OG SAMARBEJDSORGANISATION (Bilaget ligger på http://silkeborgkommune.dk/erhverv/udbud/varer-og-tjenesteydelser i pdfformat og word-format.) Skemaer udfyldes af Tilbudsgiver. Besvarelsen

Læs mere

klassetrin Vejledning til elev-nøglen.

klassetrin Vejledning til elev-nøglen. 6.- 10. klassetrin Vejledning til elev-nøglen. I denne vejledning vil du til nøglen Kollaboration finde følgende: Elev-nøgler forklaret i elevsprog. En uddybende forklaring og en vejledning til hvordan

Læs mere

Noter fra workshop med OS2

Noter fra workshop med OS2 Noter fra workshop med OS2 Exported on 12/10/2017 Noter fra workshop med OS2 1 Table of Contents 1 Table of Contents... 2 2 Overordnede noter:... 3 3 Beslutninger og noter til de enkelte kandidater:...

Læs mere

ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT

ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT Executive summary 1. ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT Regeringen har et mål om, at den offentlige sektor skal være blandt de mest effektive og mindst bureaukratiske i verden, og for at

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

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

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

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

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

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

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

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

Læs mere

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

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

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

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

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

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

Erfaringer med gennemførelse af store IT-projekter. Fagdirektør Thomas Monefeldt, Udvikling og Forenklingsstyrelsen Skatteministeriet

Erfaringer med gennemførelse af store IT-projekter. Fagdirektør Thomas Monefeldt, Udvikling og Forenklingsstyrelsen Skatteministeriet Erfaringer med gennemførelse af store IT-projekter Fagdirektør Thomas Monefeldt, Udvikling og Forenklingsstyrelsen Skatteministeriet 1 Indhold Introduktion til ImplementeringsCenter for Inddrivelse (ICI)

Læs mere

Hvad kræver en opgradering af dit ERP-system?

Hvad kræver en opgradering af dit ERP-system? Hvad kræver en opgradering af dit ERP-system? At opgradere dit ERP-system kan være meget omfangsrigt. Vi har redegjort for, hvilke elementer du skal være opmærksom og forberedt på inden du skifter. Hvad

Læs mere

Procedure for systemtest

Procedure for systemtest LANDBRUGS- OG FISKERISTYRELSEN Procedure for systemtest Retningslinjer for hvordan test udføres i LFST Kontrakt om Testressourcer Underbilag 1c 23. oktober 2017 Version 1.0 En beskrivelse af hvordan test

Læs mere

Procedurer for styring af softwarearkitektur og koordinering af udvikling

Procedurer for styring af softwarearkitektur og koordinering af udvikling LEVERANCE 2.3 Procedurer for styring af softwarearkitektur og koordinering af udvikling Procedurerne vil omfatte: Planlægning af udfasning af gamle versioner af OpenTele Planlægning af modning af kode

Læs mere

IT Service Management (ITIL) i en agil verden. Lars Zobbe Mortensen

IT Service Management (ITIL) i en agil verden. Lars Zobbe Mortensen IT Service Management (ITIL) i en agil verden Lars Zobbe Mortensen Om Lars It service management konsulent ITIL ekspert og underviser Projekt leder PRINCE2 agile og underviser Tidligere leder for udviklings

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

Kunsten at få succes med CRM

Kunsten at få succes med CRM Kunsten at få succes med CRM Kunden i centrum Den succesfulde CRM-implementering 30 20 Den største fejl, virksomheder kan gøre, når de skal vælge CRMsystem, er at bruge al tiden på at evaluere leverandører

Læs mere

Studieordning for Multimediedesigner National del August 2018

Studieordning for Multimediedesigner National del August 2018 Studieordning for Multimediedesigner National del August 2018 Indholdsfortegnelse Indholdsfortegnelse... 0 1. Uddannelsens mål for læringsudbytte... 1 2. Uddannelsen indeholder fire nationale fagelementer...

Læs mere

Kom godt i gang med BPM Indholdsfortegnelse

Kom godt i gang med BPM Indholdsfortegnelse Kom godt i gang med BPM Indholdsfortegnelse Kom godt i gang med BPM... 2 Vælg det rigtige BPM-software... 2 6 forslag til at komme i gang med BPM og procesautomatisering... 2 1. Brug ikke for megen tid

Læs mere

Projekt - Valgfrit Tema

Projekt - Valgfrit Tema Projekt - Valgfrit Tema Søren Witek & Christoffer Thor Paulsen 2012 Projektet Valgfrit Tema var et projekt hvor vi nærmest fik frie tøjler til at arbejde med hvad vi ville. Så vi satte os for at arbejde

Læs mere

STUDIEORDNING for Multimediedesigneruddannelsen. Revideret

STUDIEORDNING for Multimediedesigneruddannelsen. Revideret STUDIEORDNING for Multimediedesigneruddannelsen Revideret 01.08.2018 Indhold 1. Uddannelsens mål for læringsudbytte... 3 2. Uddannelsen indeholder fire nationale fagelementer... 3 2.1. Design og programmering

Læs mere

Ventetider i projekter

Ventetider i projekter Ventetider i projekter - en undersøgelse af 25 projekter og deres udfordringer Del I: Hvad venter vi på? Del II: Hvad er en ventetid? Del III: Hovsa! Hvorfor stopper vi her? Del IV: Spild ikke ventetiden!

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

KOLLABORATION. Vejledning til elevnøgle, klasse

KOLLABORATION. Vejledning til elevnøgle, klasse Vejledning til elevnøgle, 6.-10. klasse I denne vejledning vil du finde følgende: Elevnøgler forklaret i elevsprog. Vejledning og uddybende forklaring til, hvordan man sammen med eleverne kan tale om,

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

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

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

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

Kontrakt om Drift, Videreudvikling, Support af tilskuds- og kontroladministrative

Kontrakt om Drift, Videreudvikling, Support af tilskuds- og kontroladministrative Kontrakt om Drift, Videreudvikling, Vedligeholdelse og Support af tilskuds- og kontroladministrative systemer m.fl. Bilag 12 Change Management 16. marts 2018 Version 1.0 Side 1/16 [Vejledning til tilbudsgiver:

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

Årets Projektdag 2016 Troels Andersen-Lind SEGES AGILE IT - STRICTLY BUSINESS

Årets Projektdag 2016 Troels Andersen-Lind SEGES AGILE IT - STRICTLY BUSINESS Årets Projektdag 2016 Troels Andersen-Lind SEGES AGILE IT - STRICTLY BUSINESS AGENDA Hvem-Hvad-Hvor SEGES Kvæg - strictly business Hvad er agile Hvorfor fungerer KvægIT agile 2... HVEM ER SEGES SEGES er

Læs mere

Succesfuld implementering af automatiseret test

Succesfuld implementering af automatiseret test Succesfuld implementering af automatiseret test Forudsætningerne og faldgruberne John Fodeh john.fodeh@hp.com 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject

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

Agile holdninger, ved Jesper Nielsen

Agile holdninger, ved Jesper Nielsen Agile holdninger, ved Jesper Nielsen AAU april 2007 Historien om Henrik der gik til styregruppemøder Færdig med fase 1, brugt for mange timer. Grundig omkring X Færdig med fase 2, også brugt for mange

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

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

10. gode råd til forandringer i virksomheder

10. gode råd til forandringer i virksomheder Sådan får du SUCCESFULDE FORANDRINGSPROJEKTER 10. gode råd til forandringer i virksomheder 10 gode råd til forandringsledelse Medarbejdere og ledere kan næsten få sved på panden, når ordet forandring bliver

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

Product Ownerens værktøjskasse

Product Ownerens værktøjskasse Product Ownerens værktøjskasse 26. marts 2014 Jesper Thaning, agil praktiker & partner i BestBrains Agenda Vurdering af behov (værdi og risiko) Nedbrydning Det visuelle Afklaring af User Stories PO i større

Læs mere

Mangelfuldt dokumenterede it-systemer. Hvordan løses udfordringen?

Mangelfuldt dokumenterede it-systemer. Hvordan løses udfordringen? Mangelfuldt dokumenterede it-systemer Hvordan løses udfordringen? Indholdsfortegnelse 1. Resume... 3 2. Introduktion... 3 3. Fordelene ved at løse udfordringen... 3 4. Løsningen... 4 4.1 Hvordan?... 4

Læs mere

BILAG 5.D DOKUMENTATION

BILAG 5.D DOKUMENTATION BILAG 5.D DOKUMENTATION INDHOLDSFORTEGNELSE 1. Indledning...4 2. Kundens krav til Leverancedokumentation...4 Side 2 of 10 Instruktion til besvarelse af bilaget: Teksten i denne instruktion er ikke en del

Læs mere

En fleksibel og ligetil. løsning for alle. Få værdifuld indsigt med intelligent software

En fleksibel og ligetil. løsning for alle. Få værdifuld indsigt med intelligent software En fleksibel og ligetil løsning for alle Få værdifuld indsigt med intelligent software En fleksibel og ligetil løsning for alle Dialog Data har udviklet VIS - en samlet standard Business Intelligence-

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

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

Komunikation/It C Helena, Katrine og Rikke

Komunikation/It C Helena, Katrine og Rikke HTX Afsluttende projekt E-learning Komunikation/It C Helena, Katrine og Rikke 1.1 01-05-2013 Systemudvikling Indledende aktiviteter Kommunikationsplanlægning for projektet, Laswells fem spørgsmål. o Hvem

Læs mere

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125 Tietgenskolen - Nørrehus Data warehouse Database for udviklere Thor Harloff Lynggaard DM08125 Juni 2010 Indhold Beskrivelse... 3 Data warehouse... 3 Generelt... 3 Sammenligning... 3 Gode sider ved DW...

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

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

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Bilag 8 Test 12.05.2016 Version 1.0 [Vejledning til tilbudsgiver: Bilaget er i sin helhed at betragte som et mindstekrav (MK).

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

Målbillede for kontraktstyring. Juni 2018

Målbillede for kontraktstyring. Juni 2018 Målbillede for kontraktstyring Juni 2018 1 Introduktion Opstilling af målbillede Målbilledet for kontraktstyringen i Signalprogrammet (SP) definerer de overordnede strategiske mål for kontraktstyring,

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

Vurdering af kvalitet en note af Tove Zöga Larsen

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

Læs mere

10 gode råd. Vælg den rette model. af konsulent Morten Korsaa, DELTA

10 gode råd. Vælg den rette model. af konsulent Morten Korsaa, DELTA 10 gode råd af konsulent Morten Korsaa, DELTA Vælg den rette model SKI rammekontrakten giver mulighed for at bruge to udviklingsmodeller den klassiske og den nye. Dit valg er afgørende for succes. Den

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

Effektivitet og kvalitet i projekteksekvering

Effektivitet og kvalitet i projekteksekvering Webinarrække om projektledelse Intro til Projektmodel Light Effektivitet og kvalitet i projekteksekvering 22.11.2017 Annika Lindberg Hvad er projektmodel light Udviklet af Syddansk Sundhedsinnovation i

Læs mere

Nexus Guide. Den definitive guide til Nexus: Et ydre skelet for skaleret Scrum udvikling. Udarbejdet og vedligeholdt af Ken Schwaber og Scrum.

Nexus Guide. Den definitive guide til Nexus: Et ydre skelet for skaleret Scrum udvikling. Udarbejdet og vedligeholdt af Ken Schwaber og Scrum. Nexus Guide Den definitive guide til Nexus: Et ydre skelet for skaleret Scrum udvikling Udarbejdet og vedligeholdt af Ken Schwaber og Scrum.org August 2015 Indholdsfortegnelse Nexus overblik... 2 Formålet

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

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

DSDM Agil projektledelse

DSDM Agil projektledelse DSDM Agil projektledelse Divisionsdirektør Jakob Seedorff 5. december 1 Fiftytwo A/S Et af 12 selskaber i Bording Group Retail 52RETAIL Omnichannel Point of Sale Mobile Point of Sale Selvscanning Leasing

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

Brand By Hand Brand By Hand: Handelsbetingelser - august 2014

Brand By Hand Brand By Hand: Handelsbetingelser - august 2014 Brand By Hand CVR: 34845808 Møllevangsallé 142, 8200 Aarhus N 1 Indledning Vi yder altid vores bedste for at opfylde dine behov og indfri dine forventninger. Vi har i det følgende formuleret vores handelsbetingelser,

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

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Stamoplysninger til brug ved prøver til gymnasiale uddannelser Termin Jan-juni 2016 Institution UCH/ Handelsskolen Uddannelse Fag og niveau Lærer(e) Hold EUX Business IT B Lars

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

UD OVER RAMPEN! KURSUSFORLØB FOR ILDSJÆLE HADERSLEV ERHVERVSRÅD 2. DECEMBER 2014

UD OVER RAMPEN! KURSUSFORLØB FOR ILDSJÆLE HADERSLEV ERHVERVSRÅD 2. DECEMBER 2014 UD OVER RAMPEN! KURSUSFORLØB FOR ILDSJÆLE HADERSLEV ERHVERVSRÅD 2. DECEMBER 2014 PROGRAM Velkomst og dagens program Elevatorpitch præsentation Fra idé til realisering, del 1 - oplæg Projektskabelon, del

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

Studieordning Professionsbachelor i softwareudvikling National del

Studieordning Professionsbachelor i softwareudvikling National del Studieordning Professionsbachelor i softwareudvikling National del 1. Indholdsfortegnelse 1. Indholdsfortegnelse... 0 2. Uddannelsens mål for læringsudbytte... 1 3. Uddannelsen indeholder fire nationale

Læs mere

Informationsforvaltning i det offentlige

Informationsforvaltning i det offentlige Informationsforvaltning i det offentlige 1 Baggrund Den omfattende digitalisering af den offentlige sektor i Danmark er årsag til, at det offentlige i dag skal håndtere større og større mængder digital

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

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet. Bilag 12 - Ændringshåndtering

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet. Bilag 12 - Ændringshåndtering Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Bilag 12 - Ændringshåndtering 12.05.2016 Version 1.0 [Vejledning til tilbudsgiver: Bilaget er i sin helhed at betragte som et mindstekrav

Læs mere

STUDIEORDNING. professionsbachelor i softwareudvikling

STUDIEORDNING. professionsbachelor i softwareudvikling STUDIEORDNING for professionsbachelor i softwareudvikling Revideret 9. juni 2017 Indhold 1. Uddannelsens mål for læringsudbytte... 2 2. Uddannelsen indeholder fire nationale fagelementer... 3 2.1. Udvikling

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

Branchens perspektiv på den gode indkøbs organisation. En måling er bedre end 100 mavefornemmelser. Per Hartlev

Branchens perspektiv på den gode indkøbs organisation. En måling er bedre end 100 mavefornemmelser. Per Hartlev KL s Dialogforum for it-leverandører og konsulenthuse 7. november 2016 Branchens perspektiv på den gode indkøbs organisation En måling er bedre end 100 mavefornemmelser Per Hartlev ph@whitebox.dk 7/11-2016

Læs mere

Hack and Crack en Kina case-aften

Hack and Crack en Kina case-aften Hack and Crack en Kina case-aften Overordnet tema: 1. Supply Chain Management 2. Designbeskyttelse (kopiering) 3. Kontraktforståelse og CSR (Corporate Social Responsibility) 1 Introduktion: Denne case-aften

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