Agil programutveckling

Storlek: px
Starta visningen från sidan:

Download "Agil programutveckling"

Transkript

1 Agil programutveckling Pontus Evertsson D00, Lunds Tekniska Högskola Anna Jennerheim D00, Lunds Tekniska Högskola

2 1. Inledning 3 2. Extreme Programming (XP) 3 3. Feature Driven Development (FDD) 5 4. Jämförelse mellan XP och FDD 6 5. Unified Process (UP) 8 6. Agile UP Jämförelse mellan XP och UP Sammanfattning 11 Referenslista 12 2

3 Abstract Vår djupstudie beskriver tre lättviktsmetoder, XP, Agile UP och FDD samt jämför de två sista med XP. 1. Inledning Agil är ett annat ord för lättvikt. Som studenter vid LTH har vi endast sett XP som lättviktsmetod vid programvaruutveckling i våra kurser. Därför är det intressant att se att det finns alternativ till XP som kanske i vissa situationer till och med kan passa bättre. Här tar vi upp två andra, Agile UP (Agile Unified Process) och FDD (Feature Driven Development). Vi beskriver vilka delar som ingår i dem och gör en jämförelse med XP. De som är tänkta att läsa vår djupstudie är andra studenter vid LTH som vill se att det finns andra sätt att utveckla mjukvara än med XP-metodiken. 2. Extreme Programming (XP) Extreme programming är en lättviktsmetodik som är optimerad för projekt med ca 2-10 projektmedlemmar. XP bygger på att man har många korta iterationer där varje iteration leder till ett fungerande program som sedan byggs ut i nästa iteration. Tack vare de korta iterationerna och den nära kundkontakten, on-site customer, som man utnyttjar i XP är, man inte rädd för förändringar av problembeskrivningen. XP Practices I XP finns ett antal practices att följa. Dessa är följande: Planning Game Small Releases Metaphor Simple Design Testing Refactoring Pair Programming Collective Ownership Continuous Integration 40-hour Work Week On-site Customer Nedan följer en kort beskrivning av dessa practices. Planning Game Planning game är det första som sker i varje iteration i ett XP-projekt. Det går ut på att så snabbt som möjligt komma upp med en grov plan över vad som skall göras under kommande iteration. Arbetsmetoden under Planning game går till så att kunden kommer med ett antal index cards där det står ett krav, i form av en story, på varje. Utvecklarna diskuterar sedan igenom dessa, tidsestimerar 3

4 dem samt tar på sig ansvaret för en story. Small Releases Small releases innebär att man har väldigt korta iterationscykler. Detta för att kunden hela tiden skall ha en aktuell upplaga av programmet så att man kan veta att utvecklingen drivs åt rätt håll, dvs att programmet blir som kunden vill ha det. Metaphor I XP har man en metafor som beskriver hela systemet. Alla utvecklare och kunder känner till och förstår denna metafor vilket gör att det blir lättare att kommunicera då kunder och utvecklarna garanterat förstår varandra om de använder sig av metaforen. Simple Design XP använder sig av Simple design vilket innebär att alla test ska fungera, det får inte finnas duplicerad kod, koden skall vara tydlig och lätt att förstå samt innehåller så få klasser och metoder som möjligt. Testing Då en ny enhet skall implementeras skrivs först testerna och sedan implementerar man enheten så att alla testerna går igenom. Detta sätt att jobba på kallas Test first. Refactoring I XP är man aldrig rädd för att ändra i koden och gör refaktoreringar så fort det finns ett behov av detta till exempel om man upptäcker duplicerad kod, onödigt invecklad kod eller liknande. Pair Programming All produktionskod utvecklas i par. Detta medför många fördelar. Exempelvis är det alltid minst två programmerare som känner den aktuella koden väl och kunskaperna om klasserna sprids i projektgruppen om man kontinuerligt byter par. Dessutom minskar risken för missar och slarvfel markant eftersom koden hela tiden granskas. Collective Ownership Collective ownership innebär att alla äger all kod gemensamt. Det gör att alla kan ändra överallt i koden och man behöver därför inte vänta på att någon annan ska få tid att göra ändringen åt en. Continous Integration Så fort en delenhet är testad och färdig integreras denna med hela projektet för att minska mergeproblem. 40-hour Work Week I XP jobbar man aldrig övertid förutom kortare perioder undantagsvis. Detta för att alla hela tiden skall vara utvilade och motiverade. Detta höjer kvaliteten på den kod som produceras. 4

5 On-site Customer I XP är kunden hela tiden närvarande vilket minskar chansen att utvecklingen går i fel riktning. Ingen behöver gissa på vad de tror är rätt utan det är bara att fråga kunden om det är några oklarheter. 3. Feature Driven Development (FDD) FDD, som står för Feature Driven Development, är en modelldriven process med korta iterationer. Processen bygger på att man först gör en grov modellering av hela problemet och detta efterföljs sedan av en serie med korta design by feature, build by feature-iterationer. FDD består av följande fem olika delprocesser: 1. Develop an Overall Model 2. Build a Features List 3. Plan by Feature 4. Design by Feature 5. Build by Feature Delprocess ett, två och tre utförs bara en gång i ett projekt, därpå följer iterationer innehållandes de sista två delprocesserna. 1. Develop an Overall Model I denna första fas av projektet arbetar utvecklingslaget under ledning av chefsarkitekten med att skapa ett grovt programskelett. Under det arbetet går man till väga på följande sätt: Först utvecklar designers en väldigt grov modell av hela problemet för att sedan presentera detta för resten av utvecklingslaget. Därefter producerar designers ett programskelett och presenterar återigen modellen för hela utvecklingslaget, fast denna gång lite mer djupgående. Nu när programskelettet finns delas utvecklingslaget in i mindre grupper för att sedan, lett av chefsarkitekten, arbeta parallellt med att designa mindre delar av modellen. Detta presenteras sedan och slås samman med den totala designen med stöd av chefsarkitekten. 2. Build a Feature List Denna del i utvecklingen går ut på att sätta samman en feature list, som är en lista med alla saker som kunden sagt att programmet skall kunna göra. Ett exempel, då programmet som skall utvecklas är en ordbehandlare, kan vara: Beräkna det totala antalet tecken i dokumentet. Om inte kunden har specificerat problemet med hjälp av användarfall och sådana här funktionella krav får utvecklarna själva försöka ta fram features under aktivitet 1. Under denna fas grupperas även features med närliggande funktionalitet ihop. 3. Plan by Feature I denna tredje fas görs en högnivåplanering över hela projektet. Grupperna av features sorteras i ordningsföljd och delas ut till chefsprogrammerare som blir ansvariga för en eller flera featuregrupper. Med hjälp av programskelettet som utvecklades i fas 1 delas även ägandet av de olika 5

6 klasserna ut till de olika utvecklarna. Alla utvecklarna äger sina egna klasser Design by Feature / Build by Feature Under fas fyra och fem görs själva programmet. En chefsprogrammerare väljer först ut ett par av sina features som är lämpliga att utveckla under de närmsta 1-2 veckorna. Därefter undersöker chefsprogrammeraren vilka klasser som troligen kommer att vara involverade då dessa features skall göras. Ägarna till dessa klasser tillsammans med den aktuella chefsprogrammeraren bildar ett feature team. Det är normalt att en chefsprogrammerare leder två till tre feature-team parallellt samt att en klassägare ingår i två till tre olika feature-team samtidigt. Design by Feature Feature-teamet börjar sedan med den detaljerade designen för att bygga sina features. Designen består av att laget först gör detaljerade sekvensdiagram över alla features som laget skall utveckla. Då detta är gjort gör respektive klassägare beskrivningar av vad de klasser och metoder, som kommer att implementeras, skall utföra. Innan teamet går in i Build By Feature-fasen genomgår designen en inspektion. Build by Feature I denna fas skriver respektive klassägare koden som skulle implementeras i deras klasser. Detta innefattar kod och enhetstestning samt att hålla i en kodinspektion då det är klart. När chefsprogrammeraren är helt nöjd med en feature adderas denna nya kod till den kod som senare skall bli den som levereras till kunden. 4. Jämförelse mellan XP och FDD XP och FDD skiljer sig mest i följande avseenden: Storlek på projektgrupperna XP är i huvudsak designat att lämpa sig för projekt med två till tio utvecklare. FDD var från början designat att fungera för en grupp av ca utvecklare varav fyra är chefsprogrammerare och 16 stycken är klassägare (programmerare). Det har dock visat sig att FDD fungerar bra även för betydligt större projekt. Den största begränsande faktorn är antalet tillgängliga chefsprogrammerare i projektet. Metafor och modell I XP börjar man med att skriva stories till exempel med hjälp av index cards. Därefter tidsestimeras dessa och kunden väljer ut vilka man vill ha med i nästa release. Dessa stories beskriver saker som programmet skall kunna utföra. För att förbättra helhetsbilden av programmet använder man sig av en metafor som beskriver hela programmet och som alla känner till och kan använda sig av. 6

7 I FDD har man istället features som kan jämföras med XPs stories eller tasks. Den största skillnaden mellan XP och FDD i det här avseendet är att man har en objektmodell, dvs klassdiagram och liknande dokumentation. Detta har man enligt förespråkare för FDD för att få en bättre överblick över systemet. Det ska också förhindra att utvecklarna skapar en egen, individuell design i huvudet och istället se till att alla har samma bild. Dessutom är objektmodellen till för att minska antalet refactorings, eftersom det är lättare att göra en bra design när man vet hur allt ska se ut. Kollektivt ägandeskap eller ägande av klasser I XP har man kollektivt ägande av klasserna. Fördelarna med detta är enligt XP-förespråkarna bland annat följande tre punkter: 1 Utvecklingen går snabbare än om man har en person som ägare till varje klass. Man slipper då vänta på att ägaren ska ha tid att införa ändringarna i koden man behöver, de kan man skriva dit själv. 2 Eftersom alla får ändra all kod måste den vara lätt att sätta sig in i. Av den anledningen strävar utvecklarna mot så okomplicerad kod som möjligt. 3 Kollektivt ägandeskap sprider kunskap om hela systemet i utvecklingslaget. I FDD utnyttjar man istället ägande av klasser. Alla utvecklarna äger sina egna klasser. Några av fördelarna med detta kan vara följande: 1 I FDD är alla som äger en klass med i samma feature-team. Detta innebär att all kod som behöver ändras för att implementera en feature ägs av teamet. Även detta gör att man inte behöver vänta så mycket på att andra ska ändra i koden. 2 All lågnivådesign görs inom feature-teamet vilket innebär att alla är överens om och använder samma design. Om det är någon i teamet som inte följer den överenskomna designen upptäcks detta vid kodinspektionen och det får korrigeras. Även onödigt komplex kod upptäcks vid kodgranskningen. 3 Klassägarna känner sin egen klass perfekt, men eftersom de ofta kommer att hamna i samma team som klasser med närliggande funktionalitet kommer de även att känna till dessa bra. Varje utvecklare känner till det den behöver veta. Kodgranskning och parprogrammering I XP tillämpar man parprogrammering vilket innebär att designen och koden hela tiden granskas av en person utöver programmeraren själv. Detta leder självklart till ökad kodkvalitet. I FDD har man mer formella kodgranskningar. Detta tar mer tid men samtidigt får hela teamet en chans att gå igenom all ny kod. Testning I XP testar man programmets korrekthet genom enhets- och acceptanstester. I FDD finns inte specificerat hur testningen skall genomföras utan det är upp till chefsprogrammeraren att bestämma vad som är lämpligt. 7

8 5. Unified Process (UP) Unified Process är en risk-driven, iterativ utvecklingsprocess. Iterationerna är korta och innehåller var för sig kravanalys, design, implementation och testning. Efter varje iteration har man ett fungerande system som växer efter varje iteration man lämnar bakom sig. UP:s practices UP har följande practices som beskrivs närmare en bit ner: Iterativ utveckling Högrisk- och prioritetskrav tidigt Tidigt fokus på kärnarkitekturen Tillämpa use cases Modellera programvara visuellt Kontinuerligt verifiera kvalitet Hantera krav omsorgsfullt Hantera, kontrollera förändringar Iterativ utveckling Att dela in hela processen i iterationer är det viktigaste med UP. Den rekommenderade längden på en iteration är två till sex veckor, men om teamet är riktigt stort kan en iteration vara, som mest, upp till sex månader. Högrisk- och prioritetskrav tidigt UP sägs vara riskdriven. Det innebär att man tar hand om krav som man bedömer har hög riskfaktor eller är viktiga för kunden i de tidiga iterationerna. Detta gör att projektet, som är dömda att misslyckas, kan få misslyckas så tidigt som möjligt. Tidigt fokus på kärnarkitekturen Att implementera kärnarkitekturen tidigt i projektet hänger samman med föregående practise eftersom det både är viktigt och riskfyllt att få arkitekturen på plats. Tillämpa use cases Use cases är skrivna historier om hur systemet används. De är till för att utforska och dokumentera funktionaliteten hos de givna kraven. Modellera programvara visuellt Detta görs exempelvis med UML-diagram. Kontinuerligt verifiera kvalitet Detta görs genom tester. Testningen ska börja tidigt, utföras ofta och vara realistisk så att man får feedback på det man har byggt. 8

9 Hantera krav omsorgsfullt Att hantera krav omsorgsfullt innebär att inte vara slarvig vid exempelvis prioriteringar och uppföljningar. Hantera, kontrollera förändringar När ett nytt krav tillkommer måste man ta reda på hur det kommer att påverka det som redan finns implementerat och hur mycket extra arbete som måste läggas ner. UP:s faser En utvecklingscykel, dvs hela processen från början till färdig produkt, består av fyra olika phases (faser). Dessa är: 1. Inception (början) - Inledningsfasen där man tittar på vad som ska göras, gör vaga estimeringar samt bygger preliminära modeller. 2. Elaboration (utveckling) - Den först utvecklingsfasen där kärnarkitekturen, och andra delar med hög risk, implementeras. Modellerna arbetas om. 3. Construction (konstruktion) Den andra utvecklingsfasen där implementation av resten av systemet utförs. I slutet av fasen förbereds leverans till kunden. 4. Transition (övergång) Den sista fasen där systemet beta-testas och levereras till kunden. UP:s discipliner UP har nio olika discipliner, listade nedan, som finns till viss del i samtliga faser. Dock är modellering koncentrerad till de två första och implementation till de två i mitten. Business modeling Requirements Design Implementation Test Deployment Configuration & change management Project management Environment Disciplinerna sägs bestå av ett antal artefakter. En artefakt är något man tillverkar under projektet. Som exempel utgörs disciplinen Design av artefakterna designmodell, arkitekturdokumentation och datamodell. 6. Agile UP UP är tänkt att användas som en lättviktsmodell, agile UP. Detta uppnås eftersom man endast väljer några av artefakterna till sitt projekt, givetvis de man tycker passar bäst. UP gör att man kan anpassa sig när förutsättningar och krav ändras eftersom man inte gör all design och planering i början utan använder sig av iterationer. 9

10 7. Jämförelse mellan XP och UP De största skillnaderna mellan XP och UP: Teamstorleken XP är byggt för mindre projekt medan ett projekt i UP kan ha upp till hundratals utvecklare samtidigt. Dock delas dessa in i mindre subteam som arbetar parallellt. Design och modeller I UP ritar och skriver man mer för att beskriva systemet, till exempel med UML-diagram. I XP kommer mycket av designen efter hand när man implementerar. Lättillgänglig kund I XP finns on-site customer för att man lätt ska kunna reda upp eventuella oklarheter. Detta saknas i UP. Samarbete UP har inte specificerat vilka konstellationer man ska ha inom teamet när man arbetar, i XP programmerar man alltid i par. De största likheterna mellan XP och UP: Iterationer Båda delar upp arbetet i iterationer och planerar en iteration, max två i taget. Testning I båda varianterna ska man testa tidigt, ofta och på vettiga saker för att få värdefull feedback. Dock saknar UP XP:s Test first. 8. Sammanfattning Det hade varit intressant att delta i projekt som använder sig av agile UP och FDD för att få testa dem ordentligt, då hade man även kunnat göra en mer utförlig jämförelse. Vad vi kommit fram till är att det finns olika sätt att genomföra programmeringsprojekt och de har sina respektive fördelar och nackdelar. Därför får man välja vilken metod som passar bäst i den givna situationen och vilken man tycker bäst om personligen. Det är viktigt att man kommer överens om vilken metod man ska använda så att alla är med på det, det vill säga att ingen motverkar resten av gruppen och drar ner disciplinen som behövs för att följa den valda metodens regler. 10

11 Referenslista Titel Författare Internetadress Feature-Driven Development Stephen Palmer and Extreme Programming FDD Overview Presentation Agile Software Development using Feature Driven Development (FDD) download/fddoverview.pdf Applying UML and patterns Craig Larman 11

12 principer of agile practice (rörlig)

12 principer of agile practice (rörlig) X-treme programming 12 principer of agile practice (rörlig) Ge nöjd kund genom tidig och kontinuerliga leveranser Den viktigaste punkten som betyder att min vill ha kontinuerlig feedback Välkomna sena

Läs mer

RUP - Rational Unified Process

RUP - Rational Unified Process IBM Software Group RUP - Rational Unified Process Eva Hådding eva.hadding@se.ibm.com 1 Projektkaos. Chaos-rapporten 28% av projekten avslutades i tid och enligt budget. 49% av projekten drog över de ursprungliga

Läs mer

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades! Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer

Läs mer

Användarcentrerad systemdesign

Användarcentrerad systemdesign Användarcentrerad systemdesign Föreläsning 11: Agile-processer och ACSD Stefan Blomkvist Avdelningen för MDI/IT, Uppsala Universitet, Stefan.Blomkvist@hci.uu.se www.it.uu.se/edu/course /homepage/acsd/

Läs mer

extreme Programming refactored - recension och analys av Kent Becks senaste definition av XP

extreme Programming refactored - recension och analys av Kent Becks senaste definition av XP extreme Programming refactored - recension och analys av Kent Becks senaste definition av XP Måns Gunnarsson d01mg@efd.lth.se Sammanfattning Denna djupstudie består av en recension av andra upplagan av

Läs mer

UML: Exempel. Ett modelleringsspråk. UML: Ansvar. UML: tre huvudanvändningar. Exempel: En klass position storlek. UML Unified Modelling Language

UML: Exempel. Ett modelleringsspråk. UML: Ansvar. UML: tre huvudanvändningar. Exempel: En klass position storlek. UML Unified Modelling Language Ett modelleringsspråk : Exempel Fönster Klassnamn Unified Modelling Language Av Booch, Jacobson, Rumbaugh Exempel: En klass position storlek Attribut (instansvariaböe) Resultatet av en sammanslagning av

Läs mer

Agile-metoder, XP och ACSD

Agile-metoder, XP och ACSD Användarcentrerad systemdesign. Föreläsning 12 Agile-metoder, XP och ACSD Stefan Blomkvist MDI / IT, stefan.blomkvist@it.uu.se & Profdoc AB www.profdoc.se www.it.uu.se/edu/course /homepage/acsd/s04 XP

Läs mer

Informationshantering vid systemutveckling styrd av CM

Informationshantering vid systemutveckling styrd av CM Informationshantering vid systemutveckling styrd av CM Håkan Edler Torbjörn Jungeby Tore Qvist Syfte och mål Syftet med arbetsgruppens aktuella arbete är, att möjliggöra ett samordnat informationsutbyte

Läs mer

Scrum + XP samt konsekvensanalys

Scrum + XP samt konsekvensanalys Scrum + XP samt konsekvensanalys Daniel Nimren dt05dn8 Douglas Frisk dt05df1 Dept. of Computer Science, Lunds Tekniska Högskola, Sweden {dt05dn8 dt05df1}@student.lth.se 1 mars 2010 Sammanfattning Denna

Läs mer

Användarcentrerad systemdesign

Användarcentrerad systemdesign Användarcentrerad systemdesign Föreläsning 9: Agile-metoder, XP och ACSD Stefan Blomkvist MDI / IT, Uppsala Universitet, stefan.blomkvist@it.uu.se XP www.it.uu.se/edu/course /homepage/acsd/s04 Dagens föreläsning

Läs mer

Scrum + XP = sant. Kristian Björk D06, Lunds Tekniska Högskola dt05kb1@student.lth.se. Frederik Blauenfeldt Jeppsson. dt06fb8@student.lth.

Scrum + XP = sant. Kristian Björk D06, Lunds Tekniska Högskola dt05kb1@student.lth.se. Frederik Blauenfeldt Jeppsson. dt06fb8@student.lth. Scrum + XP = sant Kristian Björk D06, Lunds Tekniska Högskola dt05kb1@student.lth.se Frederik Blauenfeldt Jeppsson D06, Lunds Tekniska Högskola dt06fb8@student.lth.se 2010-03-02 1 Abstract Scrum och XP

Läs mer

TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU

TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU TDDI02 Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU På denna föreläsning: Verifikation, Validering och Testning XP Extreme Programming Vad är ett fel? I engelskan

Läs mer

SCRUM vs. XP en jämförelse mellan två lättviktsmetodiker

SCRUM vs. XP en jämförelse mellan två lättviktsmetodiker SCRUM vs. XP en jämförelse mellan två lättviktsmetodiker Phut Tran D01, Lund Tekniska Högskola d01pt@efd.lth.se 21 februari 2006 Innehållsförteckning ABSTRACT... 3 1 INLEDNING... 4 2 VAD ÄR EN LÄTTVIKTSMETODIK?

Läs mer

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer

Läs mer

OOA Objektorienterad Analys. Exempel på informell kravspecifikation. DD2385 Programutvecklingsteknik Några bilder till föreläsning 11 13/5 2013

OOA Objektorienterad Analys. Exempel på informell kravspecifikation. DD2385 Programutvecklingsteknik Några bilder till föreläsning 11 13/5 2013 DD2385 Programutvecklingsteknik Några bilder till föreläsning 11 13/5 2013 Innehåll OOA (ObjektOrienterad Analys) Utvecklingsmetodik särskilt XP-liknande OOA Objektorienterad Analys Definiera VAD ett system

Läs mer

Agil projektmetodik Varför och vad är det?

Agil projektmetodik Varför och vad är det? Agil projektmetodik Varför och vad är det? Boris Magnusson Datavetenskap LTH 2016-02-08 Lite större projekt Sträcker sig över tid Involverar många deltagare som behöver arbeta parallellt Planeras - delas

Läs mer

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH F7 Agila metoder EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH 1 XP - Scrum - Kanban Agila metoder Vad innehåller SCRUM Hur skiljer sig XP och SCRUM KANBAN

Läs mer

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions Testdriven utveckling Magnus Jonsson Siemens Medical Solutions 2 Soarian Stort projekt, ca 400 personer i projektet Distribuerad utveckling i USA, Indien och Sverige Web baserat lösning med admin client

Läs mer

Deluppgift 2 Kravhantering a) (2p) När man diskuterar krav brukar man ange två olika typer av krav. Beskriv dessa och ge exempel.

Deluppgift 2 Kravhantering a) (2p) När man diskuterar krav brukar man ange två olika typer av krav. Beskriv dessa och ge exempel. Page 1 (5) Hemuppgift 1DV404 150115-150118 Deluppgift 1 Processmodeller a) (4p) Alla mjukvaruutvecklare följer någon form av utvecklingsprocess i sitt arbete. Diskutera vad organisationer brukar ange som

Läs mer

Note to programmers. Embrace Change! Extreme Programming? Fyra basaktiviteter. 12 Practices / sedvanor. Vad är Extreme Programming

Note to programmers. Embrace Change! Extreme Programming? Fyra basaktiviteter. 12 Practices / sedvanor. Vad är Extreme Programming Embrace Change! Note to programmers Extreme programming Even programmers can be whole people in the real world. Extreme Programming is an opportunity to test yourself, to be yourself, to realize that maybe

Läs mer

Informationssystem och databasteknik, 2I-1100

Informationssystem och databasteknik, 2I-1100 Informationssystem och databasteknik, 2I-1100 Introduktion till informationssystem - användning, teknik och utveckling Vad är ett informationssystem? Informationssystem: datoriserat system som stödjer

Läs mer

Presentation. Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban

Presentation. Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban Presentation Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban Om AddQ Mission Vi skapar affärsnytta för kunden genom specialisttjänster inom test, kvalitetssäkring och effektivisering Tjänsteområden

Läs mer

SCRUM och agil utveckling

SCRUM och agil utveckling SCRUM och agil utveckling Johan Åberg johan.aberg@liu.se Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Läs mer

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell.

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell. Vattenfallsmodellen SCRUM Analys Kallas också linjär sekventiell modell Introduktion Design Kod Test Rational Unified Process Agile DSDM Adaptive Software Development Crystal Feature-Driven Development

Läs mer

Lyckade projekt - finns det?

Lyckade projekt - finns det? Lyckade projekt - finns det? Maria Lindqvist Björkman Enea Business Software Enea Business Software 2002 Sida 1 Agenda Förväntningar kund & leverantör Statistik om projekt Framgångsfaktorer Exempel på

Läs mer

SCRUM. Marcus Bendtsen Institutionen för datavetenskap

SCRUM. Marcus Bendtsen Institutionen för datavetenskap SCRUM Marcus Bendtsen Institutionen för datavetenskap 2 Metodik Systematiskt tillvägagångssätt för att garantera utfallet Metodiken behöver passa kontexten och tillgängliga resurser Verifiering av metodiken

Läs mer

TDDD26 Individuell projektrapport

TDDD26 Individuell projektrapport TDDD26 Individuell projektrapport Kort beskrivning av projektet Vi hade som projekt att utveckla en digital media servicer som skulle hjälpa filmentusiasten att organisera sitt filmbibliotek. Programmet

Läs mer

BESKRIVNING AV PROCESSMETODEN SCRUM

BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM INNEHÅLLSFÖRTECKNING inledning... 3 SCRUM... 3 Bakgrund... 3 Faser... 3 Ramverket... 3 Nordscrum... 4 StudentProjekt...

Läs mer

Praktikum i programvaruproduktion

Praktikum i programvaruproduktion Praktikum i programvaruproduktion Introduktion Föreläsare/Ansvarig: Pontus Boström Email:pontus.bostrom@abo.fi Rum A5055 Assistent: Petter Sandvik Email: petter.sandvik@abo.fi Rum: A5048 Föreläsningar:

Läs mer

Lean programvaruutveckling

Lean programvaruutveckling Lean programvaruutveckling Av Ludvig Hagmar (d01lh@efd.lth.se eller l_hagmar@hotmail.com) Den 12:e Februari 2006 Abstract: Denna djupstudie behandlar den agila metoden Lean software development eller Lean

Läs mer

Cult of Code Quality

Cult of Code Quality Jakob Schyberg (d00jsc) 2005-02-13 Coaching av Programvaruteam Josef Granqvist (d00jgr) LTH Institutionen för Datavetenskap Cult of Code Quality Vad kan en coach göra? Denna djupstudie handlar om kodkvalitet.

Läs mer

Agil mjukvaruutveckling. 1DV404, Jesper Andersson

Agil mjukvaruutveckling. 1DV404, Jesper Andersson Agil mjukvaruutveckling 1DV404, Jesper Andersson Agilt? Innehållet i alla mjukvaruutvecklingsprocesser! Roller! Aktiviteter! Artefakter Processmodeller Många smaker Unified Process Kanban SCRUM normativ

Läs mer

Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg

Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg Automation Region Affärsdriven systemutveckling genom agila metoder Stefan Paulsson Thomas Öberg Frontit Frontit är ett svenskt konsultföretag i gränslandet mellan Management & IT, som stärker sina kunders

Läs mer

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08 Formpipe Platina och kvalité Rasmus Staberg, Teknisk direktör, 2014-04-08 04 08 1 Formpipe Presentation Bakgrund Platina släpptes som första release år 2000. Fick pris för Best in show från Bill Gates

Läs mer

Testdriven utveckling. Teorin bakom testdriven utveckling. Bakgrund. Januari 2009, KTH. Alexander Tarnowski

Testdriven utveckling. Teorin bakom testdriven utveckling. Bakgrund. Januari 2009, KTH. Alexander Tarnowski Testdriven utveckling Januari 2009, KTH Alexander Tarnowski Teorin bakom testdriven utveckling Bakgrund Testdriven utveckling började nämnas kring 1999-2000 av Kent Beck I praktiken implementationen av

Läs mer

Therese Hansson & Magnus Jonsson. Motivationsfaktorer - Test inom Agila utvecklingsprojekt

Therese Hansson & Magnus Jonsson. Motivationsfaktorer - Test inom Agila utvecklingsprojekt Motivationsfaktorer - Test inom Agila utvecklingsprojekt Magnus Jonsson & Therese Hansson Flerårig erfarenhet från ett globalt utvecklingsprojekt där vi införde Agile & Scrum metodik i hela organisationen

Läs mer

TDP023 Projekt: Agil systemutveckling

TDP023 Projekt: Agil systemutveckling TDP023 Projekt: Agil systemutveckling Johan Åberg johan.aberg@liu.se Tre moment Projekt 8hp Marknadsföring av produkt 2hp Kopplat till projektarbetet Individuell rapport 2hp Kopplat till projektarbetet

Läs mer

Användbarhet i sitt sammanhang

Användbarhet i sitt sammanhang Användbarhet i sitt sammanhang Världsanvändbarhetsdagen 2009-11-12 Anders Hedberg, Guide Konsult Stockholm Innehåll En helikoptertur över ett projekts olika faser med belysning på användbarhet i förhållande

Läs mer

Objektorientering. Grunderna i OO

Objektorientering. Grunderna i OO Objektorientering Grunderna i OO 1 Systemutveckling Tre systemnivåer: Verksamhet Informationssystem Datasystem Huvuduppgifterna i ett systemutvecklingsarbete: Verksamhetsanalys Informationsbehovsanalys

Läs mer

Steget efter CAD Data Management. Per Ekholm

Steget efter CAD Data Management. Per Ekholm Steget efter CAD Data Management Per Ekholm Agenda Vilka processer/discipliner stöds i PDMLink Dokument management Configuration Management Change Management Project Management Hur utvärderar jag behovet?

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

F9 del B Organisatoriskt. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson Datavetenskap, LTH

F9 del B Organisatoriskt. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson Datavetenskap, LTH F9 del B Organisatoriskt EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson Datavetenskap, LTH 1 Projektet - moment Projektstartsmöte 6 Iterationer (en per vecka) - 10-12 team - 12-14 personer

Läs mer

Roller i mjukvaruprojekt. Åke Liljenberg ake.liljenberg@volvo.com

Roller i mjukvaruprojekt. Åke Liljenberg ake.liljenberg@volvo.com Åke Liljenberg ake.liljenberg@volvo.com Innehåll 1. Kort om presentatören 2. Kort om / WirelessCar 3. Vad kan jag bli när jag blir stor? 2 15-02-04 Min yrkeshistoria 1981-1990 Egen firma, programmering

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 17 juni 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

Datavetenskap. Therese Sundström. Utveckling av ett affärssystem med. Unified Process. Examensarbete, D-nivå 30 ECTS 2005:05

Datavetenskap. Therese Sundström. Utveckling av ett affärssystem med. Unified Process. Examensarbete, D-nivå 30 ECTS 2005:05 Datavetenskap Therese Sundström Utveckling av ett affärssystem med Unified Process Examensarbete, D-nivå 30 ECTS 2005:05 Utveckling av ett affärssystem med Unified Process Therese Sundström 2005 Therese

Läs mer

Scrums användning i Extreme Programming projekt. Lunds Tekniska Högskola D07 Lars-Olof Rydgren EDA270 2011-03-01

Scrums användning i Extreme Programming projekt. Lunds Tekniska Högskola D07 Lars-Olof Rydgren EDA270 2011-03-01 Scrums användning i Extreme Programming projekt Lunds Tekniska Högskola D07 Lars-Olof Rydgren EDA270 2011-03-01 1 Sammanfattning I denna djupstudie givet av kursen Coaching i Programvaruutveckling på Lunds

Läs mer

Del av projektuppgiften. Systemarkitektprogrammet

Del av projektuppgiften. Systemarkitektprogrammet Objektorienterad mjukvaruutveckling Provmoment: Ladokkod: Duggan ges för: Namn: Personnummer: Del av projektuppgiften Systemarkitektprogrammet 7,5 högskolepoäng Duggadatum: 2014-10-24 Tid: 09:00 12:00

Läs mer

Extreme Programming En bra metod?

Extreme Programming En bra metod? Extreme Programming En bra metod? Marcus Olsson D01, Lunds Tekniska Högskola d01mol@efd.lth.se 2004-02-24 Abstract Den kritik som Extreme Programming möter i böcker och artiklar kommer främst från personer

Läs mer

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel Kursinformation Metodik för programvaruutveckling Föreläsning 3 Latex ok för litteraturstudierapport (prata med mig bara) Nästa föreläsning är av Björn Regnell (jag är med också) Presentationer imorgon

Läs mer

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar Skapa testfall Testing Köra testen Hitta fel Inspections and reviews Verifiera resultatet Formal methods Static analysis Completeness Verifiering Kvalitet Maintainability Validering Traceability Fault

Läs mer

Agil testning i SCRUM

Agil testning i SCRUM Agil testning i SCRUM Petter Salomonsson Petter.salomonsson@addq.se Tel: 0708-398435 Kort presentation AddQ Consulting AB tydlig fokus på test och kvalitetssäkringstjänster erbjuder mycket erfarna konsulter

Läs mer

Software Engineering. Agneta Nilsson, PhD MPA Software Engineering Master s Programme

Software Engineering. Agneta Nilsson, PhD MPA Software Engineering Master s Programme Software Engineering Agneta Nilsson, PhD MPA Software Engineering Master s Programme Abstrakt! Software Engineering eller mjukvaruutveckling - definieras som tillämpningen av en systematisk, disciplinerad

Läs mer

En studie om parprogrammering i praktiken

En studie om parprogrammering i praktiken En studie om parprogrammering i praktiken Mia Nyström Karin Wanhainen Johan Rix 29 maj 2002 Sammanfattning Parprogrammering är en av de mest omdiskuterade grundstenarna i Extreme Programming (XP). All

Läs mer

XP vs. Tillverkningsindustrin

XP vs. Tillverkningsindustrin Djupstudie i Coaching av programvaruteam Lunds Tekniska Högskola 2006-02-20 XP vs. Tillverkningsindustrin Hur behandlar man The FIVE dysfunctions of a TEAM? Emil Svärdh D02, Lunds Tekniska Högskola d02es@efd.lth.se

Läs mer

Studie av estimeringstekniker för Extreme Programming. F. Stål D08, Lunds Tekniska Högskola

Studie av estimeringstekniker för Extreme Programming. F. Stål D08, Lunds Tekniska Högskola Studie av estimeringstekniker för Extreme Programming F. Stål D08, Lunds Tekniska Högskola dt08fs5@student.lth.se 27 februari 2012 Sammanfattning Den här studien syftar på att analysera ett fåtal estimeringsteknikers

Läs mer

2014-2015 Alla rättigheter till materialet reserverade Easec

2014-2015 Alla rättigheter till materialet reserverade Easec 1 2 Innehåll Introduktion... 4 Standarder... 5 Översikt: Standarder... 6 1058.1-1987 IEEE Standard för Software Project Management Plans... 7 Ingående dokument... 8 Syfte och struktur... 9 ITIL... 10 ITIL

Läs mer

Hur hanterar vi risk? Vad är TKO? Skillnad på agil och trad? Agil/Lean: Defer Commitment, Build knowledge, Fail fast

Hur hanterar vi risk? Vad är TKO? Skillnad på agil och trad? Agil/Lean: Defer Commitment, Build knowledge, Fail fast Hur hanterar vi risk? Vad är TKO? Skillnad på agil och trad? Trad: Mycket up front - illusionerat försök till kontroll Agil/Lean: Defer Commitment, Build knowledge, Fail fast Den Röda Tråden DESIGN Vi

Läs mer

Kursöversikt Certifierad Mjukvarutestare

Kursöversikt Certifierad Mjukvarutestare Kursöversikt Certifierad Mjukvarutestare Kurs Poäng (5 yh poäng/vecka) Examensarbete 20 Grunderna inom test 20 Kommunikation i arbetslivet 15 Lärande i arbete 1 60 Lärande i arbete 2 60 Projektarbete 15

Läs mer

Design för användbarhet

Design för användbarhet Design för användbarhet» Användbarhetsdesign, användbarhetsn och utvecklingsprocessen. Bengt Göransson användbarhets Bengt.Goransson@guide.se även avdelningen för Människa-datorinteraktion, Uppsala universitet

Läs mer

TDP023 Projekt: Agil systemutveckling

TDP023 Projekt: Agil systemutveckling TDP023 Projekt: Agil systemutveckling Johan Åberg johan.aberg@liu.se Tre moment Projekt 8hp Marknadsföring av produkt 2hp Kopplat till projektarbetet Individuell rapport 2hp Kopplad till projektarbetet

Läs mer

Djupstudie Code smells / Refaktorisering. Martin Larsson dt08ml5 Stefan Johansson, dt08sj7

Djupstudie Code smells / Refaktorisering. Martin Larsson dt08ml5 Stefan Johansson, dt08sj7 Djupstudie Code smells / Refaktorisering Martin Larsson dt08ml5 Stefan Johansson, dt08sj7 27 februari 2012 Innehåll 1 Inledning 1 2 Bakgrund 1 2.1 extreme programming....................... 1 2.2 Programvaruutveckling

Läs mer

2203$ ) UHOlVQLQJ. Varför fungerar XP Några motiveringar till varje regel efter Beck. Innehåll. Planeringsspelet

2203$ ) UHOlVQLQJ. Varför fungerar XP Några motiveringar till varje regel efter Beck. Innehåll. Planeringsspelet XP: varför fungerar det? Något om tentan. Innehåll 2203$ ) UHOlVQLQJ Introduktion till extreme Programming (XP) Varför fungerar XP? Något om tentan Vad ska man läsa och hur ser den ut? Varför fungerar

Läs mer

2009-02-02. Verktyg för agil systemutveckling. Vad är ett verktyg? Olika typer av verktyg för mjukvaruutveckling. Vad kan ett bra verktyg tillföra?

2009-02-02. Verktyg för agil systemutveckling. Vad är ett verktyg? Olika typer av verktyg för mjukvaruutveckling. Vad kan ett bra verktyg tillföra? Vad är ett verktyg? Verktyg för agil systemutveckling Individuals and interactions over processes and tools - The Agile Manifesto Papper, penna, linjal CAD-program Skruvmejsel Skruvdragare Etc 1 2 Vad

Läs mer

AGILA METODER. (för oss som inte kodar) Nina Berlin

AGILA METODER. (för oss som inte kodar) Nina Berlin AGILA METODER (för oss som inte kodar) Nina Berlin Agila värderingar 1. Individer och interaktioner framför processer och verktyg 2. Fungerande programvara framför omfattande dokumentation 3. Kundsamarbete

Läs mer

Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström.

Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström. Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström. Författare Per Johansson, Henrik Wallinder Generellt Helhetsintrycket från genomläsning av uppsatsen

Läs mer

TDDI02. På denna föreläsning: Programmeringsprojekt, Föreläsning 1. Kursinformation Vad är Software Engineering? Hur går ett projekt till?

TDDI02. På denna föreläsning: Programmeringsprojekt, Föreläsning 1. Kursinformation Vad är Software Engineering? Hur går ett projekt till? TDDI02 Programmeringsprojekt, Föreläsning 1 Anton Sundblad Filip Strömbäck Med utgångspunkt i tidigare slides av Jonas Lindgren På denna föreläsning: Kursinformation Vad är Software Engineering? Hur går

Läs mer

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech Användningscentrering i agila utvecklingsprojekt johanna.sarna@valtech.com Valtech Vem är jag? Johanna Särnå Jobbar på Valtech sedan 3 år tillbaka Jobbar där med användbarhet och projektledning Certifierad

Läs mer

Inlämning 2 - Tentamensfrågor

Inlämning 2 - Tentamensfrågor Lunds Universitet, Lunds Tekniska Högskola, LTH Inlämning 2 - Tentamensfrågor Projektgrupp B Sofie Eliasson, ic08se8@student.lth.se Maja Håkansson, dt08mh9@student.lth.se Olle Klang, ic09ok5@student.lth.se

Läs mer

Planeringsspelets mysterier, del 1

Planeringsspelets mysterier, del 1 Peter Lindberg Computer Programmer, Oops AB mailto:peter@oops.se http://oops.se/ 28 februari 2002 Planeringsspelets mysterier, del 1 Om jag ska spela ett sällskapsspel för första gången så vill jag att

Läs mer

Att införa Extreme Programming genom processförbättring

Att införa Extreme Programming genom processförbättring Att införa Extreme Programming genom processförbättring Johan Thiborg-Ericson Vahagn Baghomian 14-02-28 Sammanfattning Syftet med denna studie är att studera hur agila metoder uppkommer som en naturlig

Läs mer

VAD ÄR AGILE MODELING? Ove H. Holmberg, Merga Communications AB Version 1.0

VAD ÄR AGILE MODELING? Ove H. Holmberg, Merga Communications AB Version 1.0 VAD ÄR AGILE MODELING? Ove H. Holmberg, Merga Communications AB Version 1.0 Ove H. Holmberg Vad är Agile Modeling 1(17) Revision 1.0 2002-09-23 Version översatt utan större modifieringar från Engelska

Läs mer

Kurs-PM fo r HI1028, Projektkurs inom programvaruutveckling, VT16

Kurs-PM fo r HI1028, Projektkurs inom programvaruutveckling, VT16 Kurs-PM fo r HI1028, Projektkurs inom programvaruutveckling, VT16 Mål Kursen skall ge studenten träning i att utveckla en större programvara. Arbetet utförs i projektform. Projektet skall ge grundläggande

Läs mer

Distribuerad mjukvaruutveckling med extreme Programming

Distribuerad mjukvaruutveckling med extreme Programming Distribuerad mjukvaruutveckling med extreme Programming Jörgen Nilsson, d00jni@efd.lth.se February 22, 2005 Sammanfattning Denna artikel är en djupstudie skriven under en kurs i coaching av XPteam, på

Läs mer

Programmeringsstil 18/3-2002

Programmeringsstil 18/3-2002 Programmeringsstil 18/3-2002 Praktiska detaljer Skarpa projekt Processer och processmetoder Rast: Läs utdelat exempel Genomgång av exemplet Joel Brynielsson, 2002-03-18 1 Praktiska detaljer FAQ på hemsidan

Läs mer

Uppräkningstyper enum. DD2385 Programutvecklingsteknik Några bilder till föreläsning 11 12/5 2014. Enum m.m. OOA (ObjektOrienterad Analys)

Uppräkningstyper enum. DD2385 Programutvecklingsteknik Några bilder till föreläsning 11 12/5 2014. Enum m.m. OOA (ObjektOrienterad Analys) DD2385 Programutvecklingsteknik Några bilder till föreläsning 11 12/5 2014 Innehåll Enum m.m. OOA (ObjektOrienterad Analys) Utvecklingsmetodik särskilt XP-liknande Uppräkningstyper enum Definiera egen

Läs mer

men borde vi inte också testa kraven?

men borde vi inte också testa kraven? men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST, 24 februari 2011 SQS Software Quality Systems Sweden AB Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av

Läs mer

OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram

OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram 2EMHNWRULHQWHUDG5HDOWLGVSURJUDPPHULQJ Föreläsning 7 OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram - Kravspecifikationer, användningsfall, systemarkitektur - Analysfas vad är analys?

Läs mer

Arkitektur. Den Röda Tråden

Arkitektur. Den Röda Tråden Arkitektur Done Den Röda Tråden Vad är arkitektur? Vad har vi arkitekturmodellen till? Hur redovisar vi en arkitektur? Hur tar vi fram en arkitektur? Uppgift arkitekturella krav Nu Redovisning/Diskussion

Läs mer

In-flight Information System utveckling med ett användningscentrerat synsätt

In-flight Information System utveckling med ett användningscentrerat synsätt Uppsala Universitet Institutionen för informationsteknologi Användarcentrerad Systemdesign, 5p In-flight Information System utveckling med ett användningscentrerat synsätt Erik Salomonsson erik@salomonsson.net

Läs mer

Martin Völcker, SLL & Suit

Martin Völcker, SLL & Suit 1 2009-02-03 DSDM Martin Völcker, SLL & Suit martin.volcker@suit.se Tel: 08-648 70 00 Mobil:0708-252424 Mentorskap - Projektledning - Utbildning- Workshops 2 2009-02-03 Oklara krav Oklara roller Försenade

Läs mer

Agile i ett större sammanhang. Thomas Nilsson CTO, Agile Developer, Coach & Mentor

Agile i ett större sammanhang. Thomas Nilsson CTO, Agile Developer, Coach & Mentor Agile i ett större sammanhang Thomas Nilsson CTO, Agile Developer, Coach & Mentor Continuous Integration XP Simple Design Pair Programming Refactoring Agile i ett större sammanhang DSDM Test Driven Development

Läs mer

D J U P S T U D I E I E D A S I M P L E C O D E A N D D E S I G N

D J U P S T U D I E I E D A S I M P L E C O D E A N D D E S I G N D J U P S T U D I E I E D A 2 7 0 S I M P L E C O D E A N D D E S I G N S. Marcus Jacobsson D03, Lunds Tekniska Högskola d03mj@efd.lth.se S. Magnus Weinberg D03, Lunds Tekniska Högskola d03mw@efd.lth.se

Läs mer

Agil utveckling ställer nya krav på upphandling. Roland Bäcklin, Jaybis Konsult AB roland.backlin@jaybis.se

Agil utveckling ställer nya krav på upphandling. Roland Bäcklin, Jaybis Konsult AB roland.backlin@jaybis.se Agil utveckling ställer nya krav på upphandling Roland Bäcklin, Jaybis Konsult AB roland.backlin@jaybis.se Roland Bäcklin Tidigare: Utvecklare, Systemarkitekt, Projektledare, CTO, CIO, Riksinstruktör,

Läs mer

Tobias Landén tobias.landen@chas.se 0733 20 48 70

Tobias Landén tobias.landen@chas.se 0733 20 48 70 Internet och klientbaserade tekniker + Internets utveckling och påverkan Block 2 Lektion 1 Tobias Landén tobias.landen@chas.se 0733 20 48 70 Förra blocket Hur gick det? Vad som ska vara klart efter förra

Läs mer

Prototypningsverktyg. A Human-Centered Design Process (ISO 9241-210, 2010) Mattias Arvola. @mattiasarvola Institutionen för datavetenskap

Prototypningsverktyg. A Human-Centered Design Process (ISO 9241-210, 2010) Mattias Arvola. @mattiasarvola Institutionen för datavetenskap A Human-Centered Design Process (ISO 9241-210, 2010) Prototypningsverktyg 1. Plan the humancentred process 2. Understand the context of use Mattias Arvola Meets the requirements 5. Evaluate against requirements

Läs mer

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...

Läs mer

Redogörelse för utvecklingsprocessen av spelet The Legend of Chalmers

Redogörelse för utvecklingsprocessen av spelet The Legend of Chalmers Redogörelse för utvecklingsprocessen av spelet The Legend of Chalmers Ett projekt i kursen TDA367 Objektorienterat programmeringsprojekt och LSP310 Kommunikation och ingenjörskompetens Maxim Goretskyy

Läs mer

SCRUM och mycket mer

SCRUM och mycket mer Typ av dokument Anvisning Skapad Senaste uppdatering 2008-01-27 2008-11-13 1 (5) Sida 1 Det minsta möjliga? SCRUM och mycket mer Om man nu vill vara agile och inte har allt tid i världen, vad skall man

Läs mer

Projektuppgift i Användarcentrerad Systemdesign, ht 04

Projektuppgift i Användarcentrerad Systemdesign, ht 04 Projektuppgift i Användarcentrerad Systemdesign, ht 04 E-Dagis enligt systemutvecklings metoden The Usability Engineering Lifecycle, Deborah J. Mayhew Grupp 3: Daniel Lundberg, dalu8987@student.uu.se Hanna

Läs mer

Föreläsning 4: Designprocessen

Föreläsning 4: Designprocessen Föreläsning 4: Designprocessen FSR: 2, 3, (6), 7 Att läsa: Kapitel 9 och 12 i Rogers et al.: Interaction design 4/e 150911 Designprocessen 2 Designprocessenöversikt Introduktion Att involvera användare

Läs mer

2015-04-27. Detta har hänt... Agenda. Kursinformation. Föreläsning 5: Processer och vidareutveckling

2015-04-27. Detta har hänt... Agenda. Kursinformation. Föreläsning 5: Processer och vidareutveckling Föreläsning 5: Processer och vidareutveckling ETSA01 Ingenjörsprocessen 1 - Metodik VT15 Markus Borg Detta har hänt... Pratat krav, plan, design, test På gång att frysa kravspecifikationen Övning 3+4:

Läs mer

ETSA01 Ingenjörsprocessen 1 - Metodik VT15 Markus Borg

ETSA01 Ingenjörsprocessen 1 - Metodik VT15 Markus Borg Föreläsning 5: Processer och vidareutveckling ETSA01 Ingenjörsprocessen 1 - Metodik VT15 Markus Borg 1 Detta har hänt... Pratat krav, plan, design, test På gång att frysa kravspecifikationen Övning 3+4:

Läs mer

Testning. 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer

Testning. 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer Testning 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer UP Faser Elaboration ü Syfte: Fastställa och validera en basarkitektur för systemet vilket ger en stabil grund för den största delen av utvecklingsarbetet

Läs mer

Effekter av införande av agila metoder. Daniel Sundmark Mälardalens högskola

Effekter av införande av agila metoder. Daniel Sundmark Mälardalens högskola Effekter av införande av agila metoder Daniel Sundmark Mälardalens högskola Agila metoder Agila metoder Values T. ex., working software over comprehensive documentation (Agile manifesto) Agila metoder

Läs mer

Djupstudie i parprogrammering

Djupstudie i parprogrammering Djupstudie i parprogrammering Abstrakt P. Abrahamsson D05, Lunds Tekniska Högskola dt05pa1@student.lth.se P. Norlander D07, Lunds Tekniska Högskola dt07pn3@student.lth.se 2011-02-25 Denna studie handlar

Läs mer

Djupstudie - Datorbaserade system för tracking

Djupstudie - Datorbaserade system för tracking Djupstudie - Datorbaserade system för tracking Torbjörn Lundberg, dt05tl3 Joakim Svensson, dt05js8 18 februari 2008 Sammanfattning Tracking är ett hjälpmedel inom projekt för att hålla reda på information

Läs mer

Skapa Värde. KTH - November 2009

Skapa Värde. KTH - November 2009 Skapa Värde KTH - November 2009 Varför detta är viktigt för tekniker - Fet bredsida från en Designer Nästan alla projekt misslyckas Alla i teamet är involverade Alla måste vara beredda att agera Nu börjar

Läs mer

I detta avsnitt beskrivs vart parprogrammering appliceras, hur det ska fungera och även i vilket projekt det introduceras i.

I detta avsnitt beskrivs vart parprogrammering appliceras, hur det ska fungera och även i vilket projekt det introduceras i. PARPROGRAMMERING Mikael Möller, dt07mm5@student.lth.se 2011-02-28 Abstrakt Parprogrammering är ett arbetssätt där två programmerare arbetar tillsammans vid en dator med en uppgift. Studien behandlar frågor

Läs mer

Agil Projektledning. En introduktion

Agil Projektledning. En introduktion Agil Projektledning En introduktion Agil Projektledning Förändringar sker alltid i projekt Agil projektledning handlar om att hantera dessa Kunden har dålig insyn i ett traditionellt projekt De ska vara

Läs mer