Minimodul 2: Kravspecifikation og accepttest -...
Transcript of Minimodul 2: Kravspecifikation og accepttest -...
Struktureret system udvikling
Minimodul 2: Kravspecifikation og accepttest
Rasmus L. Olsen, 27 februar 2008
Kursusoversigt og tidsplan
Mm1: Introduktion til kursus, UML og use cases (13/2, 2008)Mm2: Kravspecifikation og accepttest (27/2)Mm3: SPU og UML (5/3)Mm4: Design af system (12/3)Mm5: Test design og planlægning (26/3)
SPU V model
Kravspec.
Programdesign
Procesdesign
Moduldesign
Implementation
Procesintegration
Accept-test
Modultest
Modulintegration
Eksempel – MP3 afspiller
“Lytteren”
MP3 afspiller
Afspil mp3 fil
Vis ID-tag info
Upload af mp3 filer
PC
Forstærkeranlæg
“Uploader”
Målet er at ….
• Målet er :• IKKE en god kravspecifikation i sig selv• MEN et godt produkt
• Hvorfor så ikke “spare” kravspecifikationen ?• Svarer til ønsket om blive millionær
• satse på at vinde i lotteriet• eller arbejde hårdt/smart !
Hvorfor kravspecifikation? #1/2
Aftale mellem ”kunde” og ”leverandør” om hvad der skal udvikles (afstemme mål og forventninger)
Enig?!?
Hvorfor kravspecifikation? #2/2
• Basis for projektplanlægning • Basis for at estimere udviklingsomkostninger• Reducere samlede udviklingsomkostninger
• Grundlag for accepttestspecifikation• Grundlag for fremtidige ændringer
• Forbedret portabilitet (til andre afdelinger/ platforme / etc.)
IEEE standarder/anbefalinger
m.fl.
• Paradoks• Masser af information/vejledninger om udarbejdelse af
kravspecifikation er tilgængelig• MEN de bruges IKKE (altid) !!!!
Hvad er en GOD kravspecifikation?
IEEE std 830-1998 anbefaler følgende
• Korrekthed• Utvetydig• Komplet• Konsistent• Organiseret efter prioritet/vigtighed• Verificerbar• Modificerbar• Sporbar
Korrekthed
• En kravspecifikation er korrekt, hvis og kun hvis ethvert krav ispecifikationen er noget produktet skal overholde• Mangler der nogen krav?• Er der unødvendige krav i specifikationen?• Er det reelt de krav, som kunden egentlig ønsker skal opfyldes?
On November 7, 1940, at approximately 11:00 AM, the first Tacoma Narrows suspension bridge collapsed due to wind-induced vibrations. Situated on the Tacoma Narrows in Puget Sound, near the city of Tacoma, Washington, the bridge had only been open for traffic a few months.(from http://www.enm.bris.ac.uk/research/nonlinear/tacoma/tacoma.html)
Glemte krav vdr. resonans
Utvetydig
• En kravspecifikation er utvetydig, hvis og kun hvis hvert krav har en mening• Undgå udefinerede ord:
Eksempel: genstartstid på motoren skal være min. 10 min.• Hvad er genstartstid?
Inkluderer det motoren først stopper, eller er det fra når motoren starter igen?
• Undgå ord som: tilstræbe, hurtigt, rimelig, så vidt muligt, eventuelt,…• Problemer kan være/opstå pga.
• Sprogbarrierer• Eks
• Forskellige opfattelser af krav pga. folks forskellig baggrund• Eks
• Krav repræsentationer/formuleringer• Eks
Komplet
• En kravspecifikation er komplet hvis og kun hvis den inkluderer flg. elementer• Indeholder alle betydende krav, hvad enten de hentyder til
funktionalitet, ydelse, design begrænsninger, eller eksterne grænseflader.
• Specifikation af både gyldig og ugyldig input og output• Referencer og figurtekst til samtlige figur, tabeller og diagrammer samt
definitioner af samtlige termer og måleenheder• TBD: To Be Determined
• Er ok så længe der itereres i udviklingsfasen• Det er en god ide at beskrive hvorfor et krav er TBD
og hvad der skal til for at ændre TBD til noget konkret• Er IKKE ok når produktet afleveres
Konsistent
• En kravspecifikation er konsistent, hvis og kun hvis ingen underliggende krav er i konflikt med hinanden eller overordnede krav
• To type inkonsistens• Forskellige navne (stophane vs. Lukkeventil)• Direkte konflikt (blinkende rød lampe vs. konstant lysende rød lampe)
• Brug præcist og ikke varierende sprog
Den skal kunne en masse, være af
god kvalitet og være billig
Hmmmm…..
Organiseret efter prioritet/vigtighed
• En kravspecifikation er prioriteret hvis hvert krav har et nummer tilknyttet, der indikerer vigtigheden af kravet• Kræver enighed mellem kunde og leverandør
• Kunden skal nøjere overveje sine enkelte krav• Udviklere skal identificere tidskrav til enkelte opgaver
Det er vigtigthjulene og styringkan klare terræn
kørselDet er vigtigt
at bussen er gul
Verificerbar
• En kravspecifikation er verificerbar hvis og kun hvis hvert krav opstillet kan verificeres
• Eksempler• Ikke målbar:
• Resultatet af målingen skal være klar uden nævneværdig forsinkelse• Programmet må ikke ”crashe” !• Intuitiv brugergrænseflade
• Målbar• Resultatet skal i 70% af tilfældene foreligge inden 3 sek. og i 100%
af tilfældene efter 7 sek.• Programmet skal køre som forventet (overholde funktions
bestemte krav) i mindst 99% af anvendelsesperioden• Højst 5% af en given test gruppe må finde brugerfladen
uoverskuelig
Modificerbar
• En kravspecifikation er modificerbar, hvis og kun hvis, dens struktur og stil er lavet således at ændringer, tilføjelser og fjernelse af krav ikke leder til inkonsistens eller redundans.
• Der VIL ske ændringer i krav under projektforløbet!• Anvend struktur såsom
• Indholdsfortegnelse/indeks og logisk numerering• Undgå redundans eller afhængige krav• Separer krav i stedet for at
blande krav sammen
Sporbar
• Et krav er sporbar hvis det er muligt at spore tilbage hvorfra kravet stammer
• Baglæns sporbarhed:• Hvis krav kan henføres til tidligere specifikationer
• Forlæns• Mulighed for at referere til krav fra fremtidige dokument (entydig
identifikation af krav)
Bemærkninger
• Kravspecifikation skal beskrive hvad systemet skal gøre, og ikke hvordan det skal implementeres. Derfor, undgå• Designkrav• Projektkrav
• Det er OK at vende tilbage til krav og justere• Man bliver klogere under projektforløbet
• Nogle krav giver pludselig ingen mening• Nogle krav viser sig at være urealistiske• …
Indholdsfortegnelse af krav specifikation
Indholdsfortegnelse er kun vejledende- Skal tilpasses de enkelte tilfælde (jeres projekter)
• Indledning• Generel beskrivelse• Specifikke krav• Ekstern grænseflade• Krav til ydelse• Kvalitetskrav• Design krav• Andre krav• Del-levering
Se SPU-UML note eller IEEE Std. 830-1998
Indhold af kravspecifikation - Indledning
• Produktets navn• Målet for udvikling• Identifikation af leverandør og kunde• Regler for indføring af ændringer• Liste med reference dokumenter• Læsevejledning
IndledningGenerel beskrivelseSpecifikke kravEksterne grænsefladeKrav til ydelseKvalitetskravDesign kravAndre kravDel-levering
IndledningGenerel beskrivelseSpecifikke kravEksterne grænsefladeKrav til ydelseKvalitetskravDesign kravAndre kravDel-levering
Indhold af kravspecifikation – Generel beskrivelse
• Beskrivelse af det totale system• Hovedfunktioner vha. Use Cases• Begrænsninger• Fremtid• Brugerprofiler• Krav til udviklingsforløb• Kundeleverance• Forudsætninger (HW, SW, kunderepræsentant)
IndledningGenerel beskrivelseSpecifikke kravEksterne grænsefladeKrav til ydelseKvalitetskravDesign kravAndre kravDel-levering
Indhold af kravspecifikation – Specifikke krav
• Definitioner• Detailkrav
• identificerbar• reference/begrundelse• prioritering• levetid
IndledningGenerel beskrivelseSpecifikke kravEksterne grænsefladeKrav til ydelseKvalitetskravDesign kravAndre kravDel-levering
Indhold af kravspecifikation – Eksterne grænseflader
• Bruger-grænseflade• Hardware-grænseflade• Kommunikations-grænseflade• Software-grænseflade
IndledningGenerel beskrivelseSpecifikke kravEksterne grænsefladeKrav til ydelseKvalitetskravDesign kravAndre kravDel-levering
Indhold af kravspecifikation – Krav til ydelse
• Tidskrav• Programstørrelse
IndledningGenerel beskrivelseSpecifikke kravEksterne grænsefladeKrav til ydelseKvalitetskravDesign kravAndre kravDel-levering
Indhold af kravspecifikation – Kvalitetskrav
• Pålidelighed• Vedligeholdelses-venlighed• Udvidelsesvenlighed• Brugervenlighed• Genbrugbarhed• Integritet• Effektivitet
IndledningGenerel beskrivelseSpecifikke kravEksterne grænsefladeKrav til ydelseKvalitetskravDesign kravAndre kravDel-levering
Indhold af kravspecifikation – Design krav
Hver kvalitetsfaktors vigtighed vurderes• f.eks. skala 1 .. 5
• 1: ukritisk, • 2: ikke særlig vigtig, • 3: vigtig, • 4: meget vigtig, • 5: særdeles vigtig
• eller “MoSCoW” skala:• Must• Should• Could• Won’t
IndledningGenerel beskrivelseSpecifikke kravEksterne grænsefladeKrav til ydelseKvalitetskravDesign kravAndre kravDel-levering
Indhold af kravspecifikation – Design krav
• Hvad der ikke falder under de andre kategorier
IndledningGenerel beskrivelseSpecifikke kravEksterne grænsefladeKrav til ydelseKvalitetskravDesign kravAndre kravDel-levering
Indhold af kravspecifikation – Design krav
Hvis projektet er opsplittet i del-leveringer• definition af de enkelte leverancer• hvilke specifikke krav der skal
være opfyldt af den enkelte leverance
Accepttest
• Formål : • Demonstrere overfor kunden, at produktet er som specificeret i
kravspecifikationen.• Udførelse :
• Planlægges, specificeres, designes og udføres af en “uafhængig tester”eller eventuelt af kunden selv.
• Generelt: des mere automatiserede en test er, jo bedre test gennemførelse
• Godkendelse :• Godkendt accepttest er ofte betingelse for betaling af de sidste rater.
Indholdsfortegnelse af accepttest
• Accepttestspecifikationen består af:• Indledning• Formål• Referencer• Testens omfang og begrænsninger• Godkendelse
• Testemner• Testdesign/test metode
Eksempler på forskellige typer test
• Stress-test• Volumen-test • Bruger-test• Sikkerhedstest• Test på ydeevne• Lagertest• Konfigurationstest• Kompatibilitetstest• Pålidelighedstest• Fejlbehandlingstest
Mere om test og design af test i mm5
Men husk: planlæg jeres test ordentligt!Chernobyl, 26. April, 1986 :- En beslutning var taget om at teste
værkets evne til at producere elektricitet nok til at drive værkets sikkerhedssystem i det tilfælde den eksterne el forsyning forsvandt.
- En lang række af omstændigheder ikke taget i betragtning under testen, ledte til nedsmeltningen af reaktor 4 på kraftværket
- Konsekvenserne ses stadig i dag og er meget virkelige på mange mennesker. En del er også døde som direkte og indirekte følgevirkning
Opsummering
• En god kravspecifikation har følgende karakteristika• Korrekthed• Utvetydig• Komplet• Konsistent• Organiseret efter prioritet/vigtighed• Verificerbar• Modificerbar• Sporbar
• Kravspecifikation leder op til accepttest• Det er IKKE let at lave en god kravspecifikation, og kræver iterationer
Et ord om review process og andre informationer
• Foreslået delegering af review:• Gruppe 410 og 411 reviewer Gruppe 412• Gruppe 411 og 412 reviewer Gruppe 413• Gruppe 412 og 413 reviewer Gruppe 414• Gruppe 413 og 414 reviewer Gruppe 415• Gruppe 414 og 415 reviewer Gruppe 410• Gruppe 415 og 410 reviewer Gruppe 411
• Sørg for at være konstruktive og ikke destruktive i jeres kritik• Det er meningen i skal hjælpe hinanden!
• Reviews vil indgå som en del af ”opgaveregning”• Skabelon til udfyldning af review vil blive tilgængelig på kursets hjemmeside
snart• PDP: Vi skal holde en individual eksamen for jer, men jeg anbefaler at i
deltager i ”opgaveregningen” trods alt