PV7170 Föreläsning 4a Validering

En presentation över ämnet: "PV7170 Föreläsning 4a Validering"— Presentationens avskrift:

1 PV7170 Föreläsning 4a Validering
Kravhantering PV7170 Föreläsning 4a Validering

2 Verifiering och Validering
Verifiering är processen som avgör om ett system eller modul motsvarar dess specifikation Validering är processen som avgör om ett system är lämpligt för sitt syfte Kravvalidering är det första steget för att se till att ett system är lämpligt för sitt syfte

3 Validering av krav Syfte
För att kontrollera att vi har insamlat och dokumenterat de rätta kraven ”Bygger vi rätt system?” Metoder Inspektioner Checklistor Kravklassificeringar Prototyper Simulationer

4 Inspektioner Utvecklad av M.E. Fagan, IBM, 1970-talet
En formell utvärderingsteknik där kraven manuellt undersöks i detalj av en grupp annan än utvecklaren för att hitta defekter Generella mål Hitta defekter Överföra kunskap Lärande från defekter

5 ”N-fold” inspection Replikerar inspektionsaktiviteter med N oberoende lag Kravdokumentet ges till alla N lagen En moderator / ordförande leder alla lagen Varje lag genomför inspektioner med hjälp av en checklista Flera lag kan hitta samma defekter

6 ”N-fold” inspection

7 Checklista Kravdokumentet Innehåller kravdokumentet följande:
Sammanfattning Innehållsförteckning Funktionella krav Kvalitets krav Index Finns all refererad information tillgänglig?

8 Checklista Krav Innehåller kravet förtidig design eller implementationsinformation? Beskriver kravet ett enda krav eller kan det delas upp i flera olika krav? Är samma tjänst beskriven i andra krav? Kan olika krav grupperas tillsammans? Använder olika krav samma uttryck men på olika sätt?

9 Checklista Är kravet testbart?
Finns tilltänkta (syften) ord utelämnade för att göra kravet testbart? Ex: Det tilltänkta är att en användare skall hitta information snabbt. För att göra den vaga beskrivningen testbar så tar man bort ”snabb”. Syftet är borttaget men kravet är testbart. Kan kravet realiseras men tillgänglig teknologi? Är kraven unikt identifierbara? Är specialtermerna definierade? Är dokumentet självständigt eller krävs det att man har tillgång till andra dokument för att förstå det?

10 Checklista Ord och grammatik
Har varje ”den/det” och ”dess” en explicit och omisskännelig referens? Är komparativa former såsom ”tidigast”, ”senast” precisa och förståeliga Har alla ord samma innebörd för kunder, användare eller utvecklare? Kolla efter: Komplett, avsluta, nåbar, simultan, normal, önskad, osv.

11 Checklista Innehåller kravet ord som gör det icke-kvantifierbart? Ex.:
Flexibel Modulär Effektiv Adekvat Möjlig Snabb Lite Ofta, vanligtvis

12 Kravklassificering Dela upp kraven i kategorier eller grupper
För att se vad som är angränsande De hör möjligtvis ihop Och kanske skall ändras tillsammans För att se om det saknas några krav Tomma kategorier och grupper

13 Validering med prototyper
Snabba prototyper (Throw-away prototyping) Utvecklande prototyper (Evolutionary prototyping) Arbetsgång Välj prototypmiljö Välj ut prototyptestare Utveckla testfall Genomför testfallen Dokumentera problem

14 PV7170 Föreläsning 4b Prioritering
Kravhantering PV7170 Föreläsning 4b Prioritering

15 Behovet av prioritering
”Vad vi vill ha överstiger alltid det vi har råd med” ”Vi måste förbättra prestandan” ”Vi har inte tillräckligt med pengar” ”Vi måste möta de nya kundernas krav” ”Vi har inte tillräckligt med tid” ”Vi måste fixa problemen i programvaran” ”Vi har inte tillräckligt med personal”

16 Behovet av priortering
Källa: Butler Group.

17 Behovet av prioritering 80-20-regeln
Paretoprincipen (fåtal vitala, många enkla) 20% av kraven motsvarar 80% av värdet 20% av kraven motsvarar 80% av kostnaden 20% av kraven står för 80% av riskerna Vissa krav: Har högt värde men kostar lite, andra Har lågt värde men kostar mycket

18 Fördelar med prioritering
Möjliggör identifiering av hög- och lågprioritering av krav Fokusera resurser på vad som är viktigt Implementation av de viktiga kraven först Skära ner på kostnader och utvecklingstid Genom att välja viktiga funktioner Genom att minimera konflikter med mindre viktiga krav Genom att tidigarelägga testning av de viktigaste funktionerna Möjliggör ”inkrement” för systemet

19 Prioriteringstekniker
Klassificera på skala Högt, mellan eller lågt värde Väsentlig, förhandlingsbar eller önskvärd [IEEE830] 3, 2, 1 Tilldela värden 1-10 1-100 Fördela poäng Dela ut 100 poäng mellan kraven – ju mer poäng desto viktigare Multipla kriterium QFD Focal Point AB utvecklar ett verktyg för prioritering

20 Hantering av prioritetsförändring
När ett nytt krav är identifierat Lägg till den till strukturen Jämför kravet med en del andra krav Kan man utifrån givna krav bestämma dess prioritet? Diskutera och besluta om det nya kravet skall inkluderas i planen eller inte

21 Omprioritering När nya krav kommer fram
När det är dags för en ny version Med jämna intervaller I projektets olika faser När andra ändringar sker

22 PV7170 Föreläsning 4c Kravstyrning, (Management)
Kravhantering PV7170 Föreläsning 4c Kravstyrning, (Management)

23 Omfattning Hanterar ändringar i krav Förändringspolicy Hanterar krav
Enskilda krav Relationer mellan krav Versioner av krav Hanterar kravdokumentet Dokument Beroenden av andra dokument Hanterar spårbarhet

24 Procedurer Verktyg och tekniker för versionshantering
Procedurer för nya och ändrade krav Hur de föreslås Hur de processas Hur de förhandlas Hur de kommuniceras ut till berörda

25 Procedurer (forts.) Hur utformas kraven? Styrning av kravens status
Vem får lov att ändra? Status kontroll och rapporteringsförfarande Påverkansanalyser för ändrade krav Hur kravförändringar påverkar projektplaner och åtaganden

26 Kravdatabas Version- och ändringskontroll
Relationer mellan krav (motsv. kravmatris) Ansluten till Projektplaneringsverktyg Testverktyg Exempel, RequsitePro

27 Flyktiga krav (Volatile requirements)
Föränderliga Krav som förändras med systemmiljön T.ex. skattesystem ändras pga ändrade lagar Framträdande Krav som ändras efterhand som systemet klarare framträder T.ex. hur information skall presenteras Påföljande Krav som baseras på antagande som inte stämmer Användare anpassar sig till systemet och ”uppfinner” nya sätt att använda det →krav på ändringar Jämförbarhet Krav som är beroende på annan utrustning eller process, när dessa ändras medför det att kraven ändras En instrumentpanel behövs ändras om en ny display införs

28 Ändringsprocessen Hitta påverkade krav Hitta andra beroenden
Kravlista Ändringsförslag Hitta andra beroenden Kontrollera önskemålets giltighet Kravändringslista Kundinformation Föreslå krav-ändring Rådfråga kund om kostnaden Kravändring Bedöm ändrings-kostnaderna Kostnads-information Kostnads-information Kundinformation

29 Initialt krav / intressent / affärsmål
Spårbarhet Initialt krav / intressent / affärsmål ”Framåt-mot”-spårbarhet Krav-specifikation ”Framåt-från”-spårbarhet ”Bakåt-från”-spårbarhet ”Bakåt-mot”-spårbarhet Design / Produkt

30 Varför spårbarhet? För att Hitta källan till ett krav
Hitta andra krav från samma källa Hitta var i designen kravet är implementerat Hitta vilka krav som påverkar en viss del i designen Hitta beroenden mellan krav Hitta beroenden mellan versioner av krav

31 Varför spårbarhet? Säkerställande!
Har alla krav blivit implementerade? Påverkan? Vilka krav och delar av system påverkas av ändringar? Underhåll Var implementerar jag en ändring? Projektkontroll Vilken status har projektet? Återanvändning Vilka andra krav är gränsar till detta? Testning Var testar vi det här kravet?

32 PV7170 Föreläsning 4d Kravspecifikation, Arkitekturer
Kravhantering PV7170 Föreläsning 4d Kravspecifikation, Arkitekturer

33 Kravspecifikationen Den viktigaste leverabeln ifrån kravprocessen
Kan variera i form Text Grafiska modeller Formella specifikationer

34 Vem använder kravspecifikationen?
Kunder och marknadsföringsavdelningen Projektledare Utvecklingsgrupper Testgrupper Underhållsgruppen / underhållsprojekt Dokumentalister Utbildare

35 Kravspecifikationens användare
Produkt dokumentation Utbild- mtrl Utbildare Dokumentalister Underhålls- gruppen Produkt Kunder Krav- specifikation Utvecklings- gruppen Marknads- föringsavd. Projekt- ledaren Test- gruppen Projekt- plan Testspec.

36 Kravens relation till Projektplanen Bedömning av produktens storlek
Problemanalys Bedömning av produktens komplexitet Design och kod Övergripande arkitektur Moduler Tester Use Cases Scenarios

37 Kvalitetsattribut Beakta kvalitetsattributen (kvalitativa krav) för att finna den lämpligaste arkitekturen Vad göra? Kvantifiera kvalitetsattributen Gör dem mätbara Prioritera kvalitetsattributen Välj lämplig arkitektur

38 Lämplig arkitektur Prestanda Strömlinjeformning Få indirekta nivåer
Genvägar? Modifierbar / flexibel Fler indirekta nivåer Modularitet Underhåll Inga genvägar Portabilitet Hårdvaruabstraktioner Modularitet Användbarhet Särskilj användargränssnittet Följ standarder och ”look-and-feel”