21-04-23 Litt: Larman kap. 2 og 8 1

Planlægning efter UP

UP som framework

UP på 1. semester

Planlægning efter UP

Input til UP

21-04-23 Litt: Larman kap. 2 og 8 2

Hvad er UP?• Unified Proces beskriver en software udviklingsproces. i

form af en række aktiviteter, der skal gennemføres for at kunne transformere brugerkrav til et edb system –

• ER OGSÅ: En fælles ramme/skabelon (framework) for udviklingsprocessen, som kan tilpasses de enkelte projekter (organisering, størrelse osv)

• Der findes mange bud på metode/værktøjer der kan anvendes indenfor rammen af UP, bl.a. UP’s forfattere og Larman

3 litt larman kap 2, 8 og 40

UP - kendetegn?• Forskellen fra andre metoder er de tre fundamenter,

metoden er baseret på:

– use case og risiko drevet

• vurdering af use cases i forhold til risici bestemmer rækkefølgen i udvikling!!!!

– arkitektur centreret

– iterativ og inkrementel

• UP sigter på udvikling af komponenter, som kommunikerer via veldefinerede interfaces. Derfor er arkitekturen i fokus.

• Bruger af UML (Unified Modelling Language)

21-04-23 Litt: Larman kap. 2 og 8 4

UP - use case drevet• Use cases er velegnet til såvel specificering af

krav som planlægning af aktiviteterne analyse, design …., dvs. at use cases kan bruges til at binde udviklingsprocessen sammen

• En use case er en serie af handlinger, som udføres af en eller flere aktører, og tilfører aktøren nytteværdi i udførelsen af arbejdet

• Begrebet use case drevet betyder, at use cases bruges til planlægning og kontrol af al fremdrift i udviklingsarbejdet – fra de indledende krav- overvejelser til koden

Meget vigtig!

• Det mest komplekse use cases laves i de første iterationer i UP (inception og elaboration), CDUD laves kun, hvis de er nødvendige for at udføre en kompleks use case fx ”find” funktioner.

• Ellers laves CRUD til sidst i construction fasen!!

21-04-23 Litt: Larman kap. 2 og 8 5

21-04-23 Litt: Larman kap. 2 og 8 6

UP - arkitektur centreret proces• Begrebet arkitektur har mange definitioner – Her: En

arkitektur er den fundamentale organisering af et system som en helhed, dvs. fundamentet som systemet skal hvile på ( nogle kalder det også for et overordnet design)

• Arkitekturer afspejler prioriteringer af mål og designkriterier:– er vedligeholdelsesvenlighed fx vigtigt og vil vi bruge ekstra

ressourcer på at udvikle systemet indenfor en 3 lags arkitektur?

• Arkitekturen er formen, use case er funktionaliteten.

21-04-23 Litt: Larman kap. 2 og 8 7

UP - Iterativ og inkrementel

SampleUP Disciplines

Business Modeling

Requirements

Design

Implementation

...

The relative effort in disciplines shifts across the phases.

This example is suggestive, not literal.

incep-tion

elaboration constructiontransi-

tion

...

21-04-23 Litt: Larman kap. 2 og 8 8

Milepæle

• Milepæle i et projekt er målepunkter, hvor projektets fremdrift kan vurderes

• Milepælene beskrives ved noget målbart – noget der skal være færdigt .. dokumenter, kode osv.

• For at fx kunne afslutte inception fasen i UP, skal der være verificeret at projektet er gennemførlig. Dvs kravene skal være defineret og systemet afgrænset i forhold til krav og økonomi (business case).

9 litt larman kap 2, 8 og 40

Fase- og iterations planer

inc. elaboration construction

Short; a few pages. Estimates phase and milestone end dates, and their objectives.

Detailed planning in an Iteration Plan is like a rolling wave that is only highly specific around the present and the near future (for example, the next iteration).

transition

Phase Plan

Iteration Plan

milestone

21-04-23

9

21-04-23 Litt: Larman kap. 2 og 8 10

Faseplan

• Overordnet udarbejdes en faseplan, hvor de enkelte UP faser og milestones beskrives

• I et studieprojekt nås typisk kun til et sted i construction

• Miletones fremgår af følgende figur:

Her fastlægges endelig budget og tidsplan

21-04-23 Litt: Larman kap. 2 og 8 11

UP faseplan på 1. semesterInception fasen

• Milestone: Inception. 1. december -5. december 2011

– Mål: At afgrænse systemet tilstrækkeligt til at kunne beslutte, om ”go” eller ”not go”

– Artefakter (dokumenter, diagrammer, kode):

• Første version af use case model (de fleste identificeret og beskrevet brief, de mest komplekse (10-20% beskrevet fully dressed)

• Første version af domænemodel

• Liste med kvalitetskrav

• Rangordning af use cases

• UI prototype

• …….

21-04-23 Litt: Larman kap. 2 og 8 12

Rangordning af use cases• Foretages efter:

• risici ved implementeringen (kritisk, signifikant eller ordinær)

• dækningsområde• vigtighed i forhold til forretningen

• Se Larman kap. 8.3• De højst prioriterede use cases detaljeres og implementeres

i de første iterationer– Fully dressed beskrivelse og mock up prototype i

inception– Analyse (SSD og kontrakter), design og

implementering i elaboration

Timebox

• Timebox betyder at iterationerme har en fast længde på fx en uge.

• Tager det fx 2 uger at udføre kritisk funktionalitet med den afsatte bemanding i elaboration, skal der være 2 iterationer

• Når man ikke det der skal laves i en iteration, overføres det manglende til den næste

• Forhåbentlig går alt op til sidst!!

21-04-23 Litt: Larman kap. 2 og 8 13

21-04-23 Litt: Larman kap. 2 og 8 14

UP faseplan på 1. semesterelaboration fasen (n iterationer)

• Milestone: Elaboration: 6 december – 15 december 2010– Mål: At fastlægge systemets arkitektur (lagdeling og principper for

tildeling af ansvar, GRASP)– Kritisk funktionalitet analyseres, designes , impl og testes gennem

følgende artefakter:• systemsekvensdiagram og operationskontrakter (kan evt.

medtages i inception) • arkitekturdokument• design af interaktionen (sekvens- eller kollaborationsdiagram)• designklassediagram• kode• testcases

21-04-23 Litt: Larman kap. 2 og 8 15

UP faseplan på første semesterconstruction (n iterationer)

• Milestone: Construction: 15 december 2010 – 3. marts 2011– Mål: Systemet er operationel dueligt– Resterende funktionalitet på kritiske use cases samt de mindre

kritiske use cases design, impl og testes gennem følgende artefakter:

• design af interaktionen (sekvens- eller kollaborationsdiagram)• designklassediagram• kode• testcases

16 litt larman kap 2, 8 og 40

Iterationsplan • Planlægning af næste iteration udføres efter hver fuldendt iteration

• I iterationsplanen defineres i detaljer hvilke aktiviteter, der skal udføres i iterationen og hvem der skal udføre de enkelte aktiviteter.

• Aktiviteterne bestemmes ud fra hvor man er i faseplanen, listen med rangordningen af use cases samt beslutning om en iterations længde (timebox):

– Af faseplanen fremgår hvilke artefakter der skal fremstilles

– Af rangordningen fremgår hvilke use case funktionalitet der skal laves (de højst prioriterede)

– Ud fra timeboxen beregnes hvor meget funktionalitet man kan nå at lave

Iterationsplan fortsat

• Iterationen i inception (der er ofte kun en) er lidt speciel, idet man i denne fase skal have overblik over kravene.

• I de næste faser består iterationerne typisk af design, impl, og test aktiviteter relateret til en eller flere use cases eller dele heraf (jf prioriteringslisten). I elaboration skal arkitekturen fastlægges

21-04-23 Litt: Larman kap. 2 og 8 17

Eksempel: Visuel udgave af iterationsplan (task board)

http://www.mountaingoatsoftware.com/pages/17-training-for-scrum-task-board-use

18

Eks: Elaboration, Iteration 1

Estimeret tid

19

Daily Stand Up Meeting

• Anvendes til opfølgning på iterationsplanen, hvad er lavet og hvad skal laves

• Et max 15 minutters møde hvor følgende spørgsmål stilles:– Hvad har du lavet siden sidste møde?– Er du løbet ind i problemer?– Hvad vil du gøre indtil næste møde?

• På mødet kan laves skitser og diagrammer, hvis der er behov for det fx til at afklare, hvad der er blevet lavet eller hvad der skal laves.

• Task board opdateres• Alle skitser og diagrammer er synlige i lokalet

20

Pair programming (fra eXtreme Programming)

• Alt kode (og unit tests) skrives i par ! – Koden skal være så “ren” som muligt.

• Par programmering er– to programmører, der begge

er engagerede, og hjælperhinanden mod et fælles mål

• Par programmering giver– bedre vidensdeling indenfor projektteamet– hurtigere oplæring af nye medarbejdere– forebygger fejl– nedsat produktivitetstab, når en medarbejder forlader teamet

21

Pair Programmering i praksis

• En udvikler har en opgave, der skal laves

– Han beder om hjælp hos en anden i teamet

– De sætter sig sammen ved en computer og går i gang med programmeringen:

• Rollerne i parret

– Den der har tastaturet arbejder på test/kode

– Den anden har fokus på:

• om det vil fungere i henhold til diagrammerne

• om der er testcases, der burde skrives

• Rollerne byttes flere gange og vilkårligt

21-04-23 Litt: Larman kap. 2 og 8 22

Input til UP

• Opsamling på forstudiet i en foranalyse:– Aktivitetsdiagrammer og beskrivelser af de

vigtigste forretningsaktiviteter– Interessenter og brugere– Forslag til hvordan vigtige forretningsscenarier

kan understøttes af IT i form af scenarier og mock up’s

– Overordnet afgrænsning i featureliste