UP som framework UP på 1. semester Planlægning efter UP Input til UP 03-04-2017 Litt: Larman kap. 2 og 8

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 03-04-2017 Litt: Larman kap. 2 og 8

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) litt larman kap 2, 8 og 40

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 03-04-2017 Litt: Larman kap. 2 og 8

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!! 03-04-2017 Litt: Larman kap. 2 og 8

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. 03-04-2017 Litt: Larman kap. 2 og 8

UP - Iterativ og inkrementel 03-04-2017 Litt: Larman kap. 2 og 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). 03-04-2017 Litt: Larman kap. 2 og 8

Fase- og iterations planer 9 03-04-2017 litt larman kap 2, 8 og 40

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 03-04-2017 Litt: Larman kap. 2 og 8

UP faseplan på 1. semester Inception 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 ……. 03-04-2017 Litt: Larman kap. 2 og 8

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 03-04-2017 Litt: Larman kap. 2 og 8

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!! 03-04-2017 Litt: Larman kap. 2 og 8

UP faseplan på 1. semester elaboration 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 03-04-2017 Litt: Larman kap. 2 og 8

UP faseplan på første semester construction (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 03-04-2017 Litt: Larman kap. 2 og 8

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 litt larman kap 2, 8 og 40

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 03-04-2017 Litt: Larman kap. 2 og 8

Eksempel: Visuel udgave af iterationsplan (task board) http://www Eks: Elaboration, Iteration 1 Estimeret tid

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

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ælper hinanden 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

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

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 03-04-2017 Litt: Larman kap. 2 og 8