1 / 22

Planlægning efter UP

Planlægning efter UP. UP som framework UP på 1. semester Planlægning efter UP Input til UP. 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 –

darryl
Download Presentation

Planlægning efter UP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Planlægning efter UP UP som framework UP på 1. semester Planlægning efter UP Input til UP 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 Litt: Larman kap. 2 og 8

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

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

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

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

  9. Fase- og iterations planer 9 litt larman kap 2, 8 og 40

  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 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 • ……. 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 Litt: Larman kap. 2 og 8

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

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

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

  18. Eksempel: Visuel udgave af iterationsplan (taskboard)http://www.mountaingoatsoftware.com/pages/17-training-for-scrum-task-board-use 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. • Taskboard opdateres • Alle skitser og diagrammer er synlige i lokalet

  20. Pair programming (fraeXtreme Programming) • Alt kode (og unit tests) skrivesi par ! • Kodenskalværeså “ren” sommuligt. • Par programmeringer • to programmører, derbeggeerengagerede, oghjælperhinanden mod etfællesmål • Par programmering giver • bedrevidensdelingindenforprojektteamet • hurtigereoplæringafnyemedarbejdere • forebyggerfejl • nedsatproduktivitetstab, når en medarbejderforladerteamet

  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

  22. Input til UP • Opsamling på forstudiet i en foranalyse: • Aktivitetsdiagrammer ogbeskrivelser 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 Litt: Larman kap. 2 og 8

More Related