PV7170 Föreläsning 1a Introduktion

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

1 PV7170 Föreläsning 1a Introduktion
Kravhantering PV7170 Föreläsning 1a Introduktion

2 Lite statistik

3 Varför? ”The hardest single part of building a software system is deciding what to build” ”No other part of the work so cripples the resulting system if done wrong” ”No other part is more difficult to rectify later” [Brooks 1987, ”No silver Bullet: Essence and Accidents of Software Engineering”]

4 ”Lagar” ”Requirements engineering is more difficult now, because all systems that were easy to specify have been built some time ago.” Tom DeMarco, Bonn 2001 ”Requirements deficiences are the prime source of project failures.” R.L. Glass, Software Runaways. Lessons Learned from Massive Software Failures, 1998 ”Errors are most frequent during the requirements and design activities and are the more expensive the later they are removed” B.W. Boehm, IEEE Transaction 1975

5 Standish Group (rapport 1994)
31% av alla projekt avbryts innan de är avslutade 52.7% av projekten kostar 189% av de ursprungliga kalkylerna Tre av de vanligaste faktorerna som anges som fällor i projekten var: Avsaknad av användarinput: 13% av alla projekt Ofullständiga krav och specifikationer: 12 % aap Ändrade krav och specifikationer: 12 % aap (Summa 37%...)

6 Standish Group (rapport 1994)
9% av projekten i stora företag levererades i tid och inom budget 16% av projekten i mindre företag levererades i tid och inom budget Tre av de vanligaste faktorerna som anges som fällor i projekten var: Involvering av användare: 16% av alla lyckade projekt (aalp) Ledningsstöd: 14% aalp Klara kravdefinitioner: 12% aalp

7 % Relativt storleken på problemet

8 Capers Jones undersökning…
Defektursprung Defektpotential Effektiv borttagning Krav 1,00 77% Design 1,25 85% Implementation 1,75 95% Dokumentation 0,60 80% Felaktig kodrättning 0,40 70% Totalt 5,00

9 Kostnad för borttagande av fel

10 Vad göra? Formalisera och kontrollera Insamlingen av krav
Specificeringen av krav Analys och förhandling av krav Testning med avseende på krav Hantering av krav

11 Vad är då ett krav? Definition (enligt IEEE):
Ett tillstånd eller förmåga önskad av en användare för att lösa ett problem eller uppnå ett mål 2) Ett tillstånd eller förmåga som måste uppnås eller innehas av ett system eller system komponent för att uppfylla ett kontrakt, standard, specifikation eller något annat formellt dokument 3) En dokumenterad representation av ett tillstånd eller förmåga enligt 1) eller 2)

12 Definition av krav Enligt Sommerville and Sawyer
(ISBN: , sid 4, Requirements Engineering – A good practice guide) ”Requirements are … a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system”

13 Hur? Krav skall beskriva problem Inte lösa dem! Eftersom
Det är svårt att lösa problem Om man löser dem så löser man dem ofta på ett icke-optimerat sätt Om man bara beskriver problemet så underlättar vi en optimerad lösning eftersom mängden möjliga lösningar är större

14 Varför är det så svårt? Krav är abstraktioner av verkligheten
Ibland i flera led Krav innehåller ofta dold kunskap eller förutsätter viss grundinformation Jämför med: Försök att beskriva hur man cyklar Försök att beskriva hur man knyter skosnöre

15 Kravhantering Består av: Utveckling av krav genom en iterativ process
Dokumentation av problem och krav Verifiering av förståelsen för kraven Och innehåller följande aktiviteter Identifikation och dokumentation av kund- och användarkrav Skapande och underhåll av ett dokument som sammanställer beteenden, behov och begränsningar Analys, verifiering och validering av kraven med avseende på konsekvens, fullständighet och realiserbarhet Iterativt och inkrementellt arbete

16 Kravhantering – huvudsaklig arbetsgång
Identifiera intressenter Samla in krav Analysera och förhandla kraven med kunden Dokumentera kraven Verifiera och validera kraven Paketera på ett användbart sätt för utvecklingsfasen Möjliggör spårbarhet av krav Hantera och återanvänd krav Kontrollera att kraven uppfylls

17 Risker med svag kravhantering
Otillräcklig inblandning av slutanvändare Flytande krav Tvetydiga krav Onödiga eller oönskade krav Minimalistiskt kravdokument Utelämnade / bortglömda användargrupper Otillräcklig information för planeringen av utvecklingen av systemet

18 Kravhantering och andra aktiviteter
Planering Kontroll Konstruktion Kravhantering Dokumentation CM V & V