Presentation laddar. Vänta.

Presentation laddar. Vänta.

Kravhantering PV7170 Föreläsning 4a Validering. Verifiering och Validering Verifiering är processen som avgör om ett system eller modul motsvarar dess.

Liknande presentationer


En presentation över ämnet: "Kravhantering PV7170 Föreläsning 4a Validering. Verifiering och Validering Verifiering är processen som avgör om ett system eller modul motsvarar dess."— Presentationens avskrift:

1 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 Typer –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 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 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 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 Kontrollera önskemålets giltighet Hitta andra beroenden Hitta påverkade krav Rådfråga kund om kostnaden Bedöm ändrings- kostnaderna Föreslå krav- ändring Ändringsförslag Kravlista Kravändringslista Kundinformation Kravändring Kostnads- information

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

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 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 Krav- specifikation Projekt- ledaren Marknads- föringsavd. Dokumentali ster Utbildare Kunder Test- gruppen Utvecklings- gruppen Underhålls- gruppen Produkt Testspec. Projekt- plan Utbild- mtrl Produkt dokumentation

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 –Modularitet Portabilitet –Hårdvaruabstraktioner –Modularitet Användbarhet –Särskilj användargränssnittet –Följ standarder och ”look-and-feel”


Ladda ner ppt "Kravhantering PV7170 Föreläsning 4a Validering. Verifiering och Validering Verifiering är processen som avgör om ett system eller modul motsvarar dess."

Liknande presentationer


Google-annonser