Struktureret system udvikling Minimodul 3: SPU/UML modellen

Struktureret system udvikling Minimodul 3: SPU/UML modellen Rasmus L. Olsen, 11 Marts 2009

Kursusoversigt og tidsplan Mm1: Introduktion til kursus, UML og use cases (11 Februar, 2008) Mm2: Kravspecifikation og accepttest (18/2) Mm3: SPU/UML modellen (11/3) Mm4: Design af system (18/3) Mm5: Test design og planlægning (27/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 Opsummering og planlægning af review

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

Grundlæggende modeller Basal Livscyklus/Proces model Ad hoc udvikling Progressive 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å: http://www.business-esolutions.com/islm.htm

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

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

Vandfaldsmodel fordele og ulemper Fordele: God basis for gennemført og konsistent design Vedligeholdelsesvenligt resultat Mindre og/eller overskuelige/veldefinerede projekter Ulemper: Virkelighedens projekter følger sjældent et 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?

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

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 )

SPU-UML konceptet

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

Spiralmodel Fordele: Minimere risiko Dele af projektet der er forbundet med størst usikkerhed/risiko udvikles tidligt Synliggøre udviklingsforløb Fordi hver ny iteration er baseret på en kørende model Korte lærecykler (vigtig ved ny teknologi) God til håndtering af problemer af forskellig kompleksitetsgrader Gradvis nedbrydning af komplekse problemer Skalerbart i forhold til antal personer involveret i processen Egnet for enkelt personer, men også for grupper

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

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

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

SPU modellen

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

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!

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

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

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

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.

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

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å??).

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

Resultaterne af SPU modellen Reviews

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

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

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???

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

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

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

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?

Bestemmelse af leveringstider/synkroniseringspunkter God planlægning kræver erfaring! Estimering af tid til opgaver der inddrager forskellige, svært vurder bare 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!!!!

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

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

Planlægning af reviewmøde Fastlæggelse af tidspunkt for review http://www.doodle.ch/ 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

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

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

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!!

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

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!

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

Efterbehandling

SPU-UML konceptet - opsummeret

Foreslået tidsplan for reviews Marts 15 Analysedokument sendes til reviewgruppen og kursusholder. Marts 18 Review, 1. runde (opgaveregning) Marts 23 Review-rapport sendes til gruppen og kursusholdere Analysedokument til 2. runde sendes til reviewgruppen og kursusholder Marts 27 Opfølgning af reviews fra 1. runde Review, 2. runde (opgaveregning) Marts 30 Review rapport fra 2. runde sendes til gruppe og kursusholder * Opfølgning af reviews fra 2. runde skal desværre ske på eget initiativ, da kurset ikke er længere end 5 mm Se plan på http://kom.aau.dk/~rlo/lectures/ssd_09/review-plan-analysedok.html 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å http://cpk.auc.dk/education/ssu- 2007/mm6/review-plan-analysedok.html