minimodul 3: spu/uml modellen - aalborg...

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 IterativeEvolutionære

• ”Code and fix”• Design-til-Værktøj• Off-the-Shelf

• Spiral• Modificeret

vandfald• V-model • W-model• U-model• SPU-modellen

Progressive

• Vandfald• Arrangeretaflevering

• Design-til-plan

• Evolutionær prototypeudvikling

• Evolutionær aflevering

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

RequirementSpecification

DesignImplementation

VerificationMaintenance

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 – orientedProcess forEmbeddedSystems

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 ogkravspecifikation

OOAnalyse

Kra

vspe

cifik

atio

n

Use Case Model

Arki-tektur

Design

SW og HWimplementeringaf use case X

SystemIntegra-tionstest

Accepttest

Iteration

W-model – for leverancer

Leverancetid

E E E

L LX tid

E EY tid Z tid

E: Intern EvalueringL: (del) Leverance

tid

V-modellen - for test

Kravspecifikation Accepttest

Arkitekturdesign System inte-grationstest

SW & HWImplementering

SPU modellen

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

SPU modellenProgram 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 modellenProcesdesign: • 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 overholdermodulspecifikationen

• 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 modellenReviews

Med SPU går det så gnidningsfrit???

NEJ!!! Men sandsynligheden for detgår helt galt reduceres betydeligt





• Tidsplaner, synkronisering og planlægning• Review og reviewteknik

Et problem: Parallel udvikling af software og hardware

Spørgsmål:• Hvordan udvikler man SW der skal køre på HW, SAMTIDIGT???

Moduldesign

Detaljeretdesign Kodning Unit

testModul

Integrationstest

SW Implementering af use case X

HW Implementering af use case X

Diagramtegning

Komponentberegning…

Wrapning/Lodning Test Modul

Integrationstest

Synch-and-stabilize udvikling

Arbejde foregår typisk som en gruppe af individualister, i en separat funktionel afdeling

Produkt og proces design arbejder i små teams

Feedback opnås hovedsagligt ved slutning af projekt, til brug i næste projekter

Feedback fra kunden sker løbende

Sigtende på funktion- og produkt-perfektionering i hver projekt cycklus

”Fikserede” leveringstidspunkter og flere opdateringscyklusser

En sen og samlet integration og system testfase ved projektets slutning

Hyppig synkronisering (daglige opdateringer) og mellemliggende stabilisatorer (milesten)

Sigter på at lave systemet komplet fra start til slut

Funktioner er prioriteret og er lavet i løbet af 3-4 milesten og underprojekter

Komplet og ”frossen” specifikation med detaljer før produktet laves

Visionsdrevet og udviklende specifikation

Alting er udført sekventielt

Sekventiel udvikling

Produktudvikling og test er udført parallelt

Synch-and-stabilize udvikling

Realiteten er ofte en balancegang mellem de to

Sync

h-an

d-st

abili

zeud

vikl

ing

Sekventiel udvikling

Tidsplaner, projektstyring, resourceudnyttelse

Kravspecifikation

System specifikation

HW Modul 1

HW Modul 2

HW Modul 3

SW Modul 1

SW Modul 2

SW Modul 3

SW Modul 1

SW Modul 2

SW Modul 3

Aktiviteter

M1 M3.1tidStart M2 M3.3

M3.2M3

W-model – for leverancer

Spørgsmål:• Hvorledes bestemmer man hvor leverancerne skal ligge tidsmæssigt?

Leverancetid

E E E

L LX tid

E EY tid Z tid

• Andre gruppe (medlemmer) kan også være modtagere af (del)produkt!

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

projekter)• 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 reviewsMarts 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 kursusholderMarts 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

minimodul 3: spu/uml modellen - aalborg...

Documents