Post on 22-Jan-2016
description
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