Struktureret system udvikling Minimodul 3: SPU/UML modellen

Transkript

1 Struktureret system udvikling Minimodul 3: SPU/UML modellen Rasmus L. Olsen, 12 Marts 2008

2 Kursusoversigt og tidsplan Mm1: Introduktion til kursus, UML og use cases (13/2, 2008) Mm2: Kravspecifikation og accepttest (27/2) Mm3: SPU og UML (12/3) Mm4: Design af system (26/3) Mm5: Test design og planlægning (9/4)

3 Dagens program Projektudviklingsmodeller Ad hoc Tidslineære Iterative Evolutionære Iterative modeller Spiral model U model W model V model SPU modellen Detaljeret gennemgang af de enkelte faser Tidsplaner, synkronisering og planlægning Review og reviewteknik

4 Projekt livscyklus / Proces model Anvendt til at guide Analyse Design Udvikling Vedligeholdelse Husk: Modeller er kun repræsentanter for virkelighedens verden!

5 Grundlæggende modeller Basal Livscyklus/Proces model Ad hoc udvikling Tidslineære Evolutionære Iterative Code and fix Design-til-Værktøj Off-the-Shelf Vandfald Arrangeret aflevering Design-tilplan Evolutionær prototype udvikling Evolutionær aflevering Spiral Modificeret vandfald V-model W-model U-model SPU-modellen Se også:

6 Ad hoc udvikling ( Code-and-fix ) Karakteriseret ved: Ingen eksplicit udviklingsmodel Afhængighed af de enkelte projektdeltagers evner og erfaringer Kaotisk/tilfældig Upræcise tidsplaner Usikre budgetter Uklar funktionalitet Inkonsistent produktkvalitet Dårlig basis for forbedringer af produktivitet og kvalitet Kan dog også lede til exceptionelle resultater

7 Tidslineære - Vandfaldsmodel Første strukturerede metode til system udvikling Storhedstid i 70 erne og 80 erne, men benyttes stadig (endda med succes)! Fryser kravspecifikationer Requirement Specification Design Implementation Verification Maintenance Feedback and error control

8 Vandfaldsmodel fordele og ulemper Fordele: God basis for gennemført og konsistent design Vedligeholdelsesvenligt resultat Mindre og/eller overskuelige/veldefinerede projekter Ulemper: Virklighedens projekter følger sjældentet strengt sekventielt forløb Ingen garanti for at brugeren får det ønskede! Dårlig tilpasning til ændrede omstændigheder Stor usikkerhed i starten af projektet (lyder det bekendt?) Intet kørende system før til slut i projektforløbet?

9 Evolutionær udvikling Bygger videre på hvad man tidligere har lavet; krav såvel som produkt Produkt i konstant udvikling Ikke egentlig egnet til produktudvikling, da slutproduktet oftest ikke er kendt Anvendelsesområde er relateret til f.eks. Forskning der bygger på tidligere opnåede resultater

10 Iterative modeller Iterativ = inkrementel Hver iteration= mini-vandfaldsmodel Fordele: Hurtigere demonstrerbare resultater Mindre krav til specifikation af krav Større fleksibilitet Ulemper: Slutbrugerne skal være aktivt involverede => tager tid fra udviklingen Kommunikation og koordination er essentielt Stigende krav, mer-vil-have-mer (eng. scope-crepe )

11 Dagens program Projektudviklingsmodeller Ad hoc Tidslineære Iterative Evolutionære Iterative modeller Spiral model U model W model V model SPU modellen Detaljeret gennemgang af de enkelte faser Tidsplaner, synkronisering og planlægning Review og reviewteknik

12 Spiral modellen -For styring ROPES: Rapid Object oriented Process for Embedded Systems

13 Spiralmodel Fordele: Minimere risiko (dele forbundet med størst usikkerhed/risiko udvikles tidligt) Synliggøre udviklingsforløb Korte lærecykler (vigtig ved ny teknologi)

14 U-model for udviklingsaktiviteter Analyse og kravspecifikation Kravspecifikation OO Analyse Arkitektur Design SW og HW implementering af use case X Use Case Model System Integrationstest Accepttest Iteration

15 W-model for leverancer X tid E E L Leverancetid L Y tid Z tid E E E tid E: Intern Evaluering L: (del) Leverance

16 V-modellen - for test Kravspecifikation Accepttest Arkitekturdesign System integrationstest SW & HW Implementering

17 SPU-UML konceptet

18 Dagens program Projektudviklingsmodeller Ad hoc Tidslineære Iterative Evolutionære Iterative modeller Spiral model U model W model V model SPU modellen Detaljeret gennemgang af de enkelte faser Tidsplaner, synkronisering og planlægning Review og reviewteknik

19 SPU modellen

20 SPU modellen

21 SPU modellen Kravspecifikation: Analyse og use case specificering Kravspecifikation Accepttest specifikation Foreløbelig brugervejledning Evt. en simpel prototype/demo Review af kravspecifikation

22 SPU modellen Program design: Opdeling af system i parallelle processer Eksterne grænseflader Interne grænseflader Synkronisering af processer Procesintegration-specifikation Hvordan integreres processerne? Hvad integreres hvornår? Kritiske komponenter først! Vigtigt at alle i gruppen er aktive og enige!

23 SPU modellen Procesdesign: Opdeling af proces i moduler Sekventielt program Fællesmoduler Modul specifikation (krav, funktioner, grænseflader) Modulintegrations-specifikation Identifikation af test programmer/stubbe Integration og test

24 SPU modellen Moduldesign: Specialiseret design af modul Hvordan Algoritme/flow chart/diagram udlægning Specifikation af datastrukturer Modul test specifikation Black-boks test White-boks test

25 SPU modellen Modulimplementering Omsætning af design til kode/hardware Følg standarder, f.eks. Kodestandarder såsom ANSI-C Ledningefarver, f.eks. sort: stel, rød: +5V Stikforbindelser Kodegranskning Forbedrer kode kvalitet Opdagelse af logiske fejl Læring af andres succeser/fejl Nedbrudt ejerskab

26 SPU modellen Modultest: Verificering at modulet overholder modulspecifikationen Skrivning af test moduler/stubbe Brug af test apparater Udfyldning af test rapport Dokumentation over hvad der er, og ikke er blevet testet for! Dokumentation over hvilke problemer der eventuelt er fundet.

27 SPU modellen Modulintegration: Samling af moduler Test af proces - integrationsrapport Dokumentation over hvad der er, og ikke er blevet testet for! Dokumentation over hvilke problemer der eventuelt er fundet. Vær forsigtig/realistisk Koble kun et modul sammen ad gangen Vær beredt på at skulle gå tilbage til start

28 SPU modellen Processintegration: Samling af parallelle processer Sikring at proces kommunikation virker Udarbejdelse af procesintegrationsrapport Det står i SPU bogen det kan være svært, men hvorfor? Manglende funktionaliteter (ups, det mangler vi) Dobbeltarbejde (det er jo det jeg har lavet ) Misforståelser under projektforløbet Forkerte interfaces (jeg troede du mente ) Forkerte datatyper (skulle det være en Float??) Forkert opfattelse af funktionaliteter (skulle den have beregnet kvadratroden også??).

29 SPU modellen Accepttest: Skal svare på det helt store spørgsmål: Er produktet som køberen forventer?

30 Med SPU går det så gnidningsfrit??? NEJ!!! Men sandsynligheden for det går helt galt reduceres betydeligt

31 Resultaterne af SPU modellen Reviews

32 Dagens program Projektudviklingsmodeller Ad hoc Tidslineære Iterative Evolutionære Iterative modeller Spiral model U model W model V model SPU modellen Detaljeret gennemgang af de enkelte faser Tidsplaner, synkronisering og planlægning Review og reviewteknik

33 Synch-and-stabilize udvikling Synch-and-stabilize udvikling Produktudvikling og test er udført parallelt Visionsdrevet og udviklende specifikation Funktioner er prioriteret og er lavet i løbet af 3-4 milesten og underprojekter Hyppig synkronisering (daglige opdateringer) og mellemliggende stabilisatorer (milesten) Sekventiel udvikling Alting er udført sekventielt Komplet og frossen specifikation med detaljer før produktet laves Sigter på at lave systemet komplet fra start til slut En sen og samlet integration og system testfase ved projektets slutning Fikserede leveringstidspunkter og flere opdateringscyklusser Feedback fra kunden sker løbende Produkt og proces design arbejder i små teams Sigtende på funktion- og produktperfektionering i hver projekt cycklus Feedback opnås hovedsagligt ved slutning af projekt, til brug i næste projekter Arbejde foregår typisk som en gruppe af individualister, i en separat funktionel afdeling

34 Sekventiel udvikling Realiteten er ofte en balancegang mellem de to Synch-and-stabilize udvikling

35 Et problem: Parallel udvikling af software og hardware SW Implementering af use case X Modul design Detaljeret design Kodning Unit test Modul Integrationstest Diagram tegning Komponent beregning Wrapning/ Lodning Test Modul Integrationstest HW Implementering af use case X Spørgsmål: Hvordan udvikler man SW der skal køre på HW, SAMTIDIGT???

36 Tidsplaner, projektstyring, resourceudnyttelse Aktiviteter SW Modul 1 SW Modul 3 SW Modul 2 SW Modul 2 SW Modul 3 SW Modul 1 HW Modul 2 HW Modul 1 HW Modul 3 System specifikation Kravspecifikation Start M1 M2 M3.1 M3.3 M3.2 M3 tid

37 W-model for leverancer X tid E E L Leverancetid L Y tid Z tid E E E Andre gruppe (medlemmer) kan også være modtagere af (del)produkt! Spørgsmål: Hvorledes bestemmer man hvor leverancerne skal ligge tidsmæssigt?

38 Bestemmelse af leveringstider/synkroniseringspunkter God planlægning kræver erfaring! Estimering af tid til opgaver der inddrager forskellige, svært vurderbare parametre Analogi: Hvor lang tid tog en lignende opgave sidst? Faktor vurdering: Hvor erfaren er vedkommende/gruppen man sætter på at lave modul X eller Y? Nyskabelse: Er der noget nyt involveret i aktiviteten? Forudsigelse: Kan der forudses problemer? Nedbrydning af problem til delproblemer (moduler) hjælper Løbende feedback og justeringer ved hjælp af status møder og opfølgning er nødvendigt Det er en del af jeres læringsproces!! Brug nu jeres vejleder til estimering af tid til opgaver Kommunikation mellem involverede er ALTAFGØRENDE!!!!

39 SPU-UML konceptet - opsummeret

40 At indføre SPU succesfuldt, kræver samarbejde.

41 Dagens program Projektudviklingsmodeller Ad hoc Tidslineære Iterative Evolutionære Iterative modeller Spiral model U model W model V model SPU modellen Detaljeret gennemgang af de enkelte faser Tidsplaner, synkronisering og planlægning Review og reviewteknik

42 Review teknik Review er en teknik benyttet til at korrigere og justere projektforløb/ projektdokumentation Review benyttes især ved milesten Formålet er at finde fejl og mangler Reviews kræver forberedelse! Processen deles op i flg. Elementer Planlægning Formøde Forberedelse Reviewmøde Opfølgning

43 Planlægning af reviewmøde Fastlæggelse af tidspunkt for review Udvælgelse af deltagere Typer af deltagere Reviewleder Reviewer Referent Tilhører Kriterier til reviewer Skal være tekniske kompetente indenfor området Have diplomatisk sans Kunne være i stue sammen Ikke være en del af ledelsen (generelt ikke vigtigt for studenterprojekter) Normalt med to-tre reviewers

44 Planlægning af reviewmøde Klargøring af dokumenter Det er forfatteren der bestemmer hvornår et dokument er klar til review Fremfinding af materiale Generelt; al den nødvendige baggrundsmateriale der er behov for at forstå det der skal reviewes Indkaldelse til møde Husk at sende dokumenter med ved indkaldelsen Husk at sende mødetidspunkt og sted Husk at invitere alle relevante personer

45 Formøde - Hvorfor et formøde? Klarlæggelse af hvad der forventes af reviewerne Hvad skal reviewes Reviewets formål Deltagernes roller Diskussion af reviewets teknik/forløb Dagsorden for reviewmødet Udlevering af spørgsmål til reviewerne Overordnet gennemgang af produktet (en fra projektgruppen) Overordnet gennemgang af dokumentet (en af forfatterne) Formål, funktioner, grænseflader, datastrukturer, logisk struktur Gennemgang af det udleverede baggrundsmateriale Gennemgang af spørgsmål til reviewerne

46 Forberedelse til reviewmødet Læsning og vurdering af dokumentation under review Review kan f.eks. Adressere Trykfejl, stavefejl og andre korrekturfejl Afvigelser fra standarder Logiske fejl og mangler, f.eks. Uopfyldelige krav Mulighed for deadlocks i programdesign Husk også at rose/fremhæve gode ting Husk også at lære af andres fejl/fortræffeligheder og inddrag erfaringer i jeres eget projekt!!

47 Reviewmøde Der er mange måder at strukturere et reviewmøde på Generelt handler det om at forklare baggrunde for de kommentarer man har Korrekturfejl (kræver ikke nødvendigvis en gennemgang) Kommentarer til dokumentets udformning Generelle kommentarer til dokumentet Detaljeret gennemgang af specifikke kommentarer Konklusion og bestemmelse af opfølgningsprocedure

48 Gode råd til kommentering under reviewmødet Vær forberedt (som reviewer) Vær solidarisk og ikke bedrevidende Tal pænt Dårligt eksempel: Det er da for dumt at.. Bedre: Jeg tror nok der er et problem. Giv også positiv kritik Undgå at diskutere stil Der findes mange forskellige måde at udarbejde et dokument på Spørgsmålet er ikke om hvorvidt du kan lide forfatteren stil, men om det giver mening og er korrekt! Hold jer til tekniske emner Undgå at diskutere de betingelser hvorunder dokumenterne er frembragt. Det er irrelevant!

49 Efterbehandling Udarbejdelse af referat Opfølgning af kritik punkter Ellers giver reviewet jo ingen mening! Registrering af tidsforbrug Til brug for projektplanlægning af fremtidige projekter

50 Foreslået tidsplan for reviews Marts 19 Analysedokument sendes til reviewgruppen og kursusholdere. Marts 26 Review, 1. runde Marts 28 Review-rapport sendes til gruppen og kursusholdere + hjælpelærer April 9 April 9 Review, 2. runde (for grupper der ikke nåede 1. runde) Opfølgning af reviews fra 1. runde Opfølgning af reviews fra 2. runde skal desværre ske på eget initiativ, da kurset ikke er længere end 5 mmfg/rg Se plan på Spørgsmål: Hvorvidt i har lyst/lov til jeres dokument lægges ud på websiden til andres behjælpelighed Eksempler fra sidste års kursus kan ses på /mm6/review-plan-analysedok.html

51 Efterbehandling