ETS672 Requirements Engineering L6: Agile Prioritisation Validering av krav! Att säkerställa att vi har eliciterat och dokumenterat rätt krav Kommer vi att bygga rätt system med dessa krav?! Christin Lindholm Anpassa kravarbetet till projektet Syfte Metoder Granskningar Tester Modellbaserad simulering Härledning med matematiska modeller Agile utveckling Grundtanke Utkast av system som testas snabbt Syfte Alla i projekt måste ha förståelse för: Projektet omfattning Krav och bakomliggande behov Göra kunden nöjd leverera fungerande programvara under hela processen Krav på kundens engagemang Agile Manifesto http://agilemanifesto.org
Underliggande antagande Antagande om! Förändring av krav Krav utvecklas över tid beroende av förändringar i teknologi, kundbehov och verksamhet -> krav uppkommer under utvecklingsprocessen, vilket innebär att lite tid läggs på initial kravelicitering! Dokumentation Omfattande dokumentation och modeller är kontraproduktivt -> ingen detaljerad kravdokumentation i förväg Underliggande antagande forts Antagande om! Interaktion med kund Kunden är frekvent tillgänglig för utvecklarna " Agile utveckling vilar på denna tillgänglighet för elicitering och validering av krav! Förändringskostnader Kostnaden för att göra förändringar ökar inte med tiden -> krav som utvecklas över tid ökar inte kostanden. Kravhantering utförs iterativt och inkrementellt Scrum Daily Time Box Stories Tasks
Krav vs User stories Traditionellt krav 1. Systemet ska tillhandahålla ett konfigurerbart gränssnitt för alla användarfunktioner 2. Användargränssnittet ska vara konfigurerbart på följande områden: a) Font b) Bakgrundsfärg User story Som systemanvändare vill jag kunna konfigurera användargränssnittets font, bakgrundsfärg. Så att jag kan använda systemet på effektivaste sätt User-Story 6.2.3: (Avklarad) Prioritet: H Som spelare vill jag, med så få knapptryck som möjligt, kunna bekräfta mina inställningar och börja spela. Acceptanskriterier: a. På alternativskärmen skall det finnas en bekräfta-knapp. b. När spelaren trycker på knappen skall följande ske: 1. Inställningarna som gjorts skall sparas i appens interna databas. 2. Spelplanen skall visas. Förslag på implementation: Alla alternativ skall sparas i den lokala databasen vid ett knapptryck på bekräfta-knappen. Kommentarer: Face-to-face Iterativ kravhantering Upplevda fördelar Upplevda utmaningar Upplevda fördelar Upplevda utmaningar! Kunden kan styra i oväntade riktningar! Eliminerar behovet av tidskonsumerande dokumentation och processer för godkännande! Risk för felaktiga eller otillräckliga krav om intensiv interaktion med kund inte finns! Få kund att vara onsite! Att få koncensus vid mer än en kundgrupp! Få förståelse eller tillit från kund som är van vid traditionella utvecklingsprocesser! Skapar mer tillfredställande relation med kunden! Omedelbara tillgången till kunden ger klarare och mer förståeliga krav! Svårt att skapa kostnads och tidsestimeringar för hela projektet! Om kommunikationen upphör så skapar bristen på dokumentation problem! Negligerar kvalitetskrav
Extrem prioritering Upplevda fördelar Upplevda utmaningar Konstant planering Upplevda fördelar Upplevda utmaningar! Kunden kan ge affärsmässiga skäl för krav -> lättare att förstå kundens prioriteringar och hjälper utvecklarna at bättre möta kundens behov! Ger många tillfällen till omprioriteringar! Att använda affärsvärde (time-tomarket) som enda prioriteringskriterie kan orsaka stora problem på längre sikt! Ständiga omprioriteringar kan leda till instabilitet! Tidig och konstant validering -> minimerar till stor del behovet av stora förändringar! Kostanden vid ändring minska dramatiskt jämfört med traditionell utveckling! Kravförändringar gör att tidig arkitektur blir inadekvat och redesign av arkitektur ökar kostnaderna betydligt! Behovet för refactoring är inte alltid uppenbart och förmågan beror på erfarenhet hos utvecklarna. Löser inte alltid problemet med otillräcklig arkitektur. Prototyping Upplevda fördelar Upplevda utmaningar Test-driven utveckling Upplevda fördelar Upplevda utmaningar! Bra för att validera krav! Kan vara svårt att underhålla och utveckla prototyper Problem med skalbarhet, säkerhet och robusthet! Kan skapa orealistiska förväntningar från kunder! Tester kan användas för att skapa spårbarhet. Denna spårbarhet gör det lättare att infoga förändringar! Stor utmaning att utvecklare inte är vana vid att skriva tester innan kodning! Kräver förståelse av kraven och omfattande samarbete mellan utvecklare och kund eftersom det involverar förfining av låg-nivå specifikationer iterativt
Granskningar (Reviews) och Acceptanstester Upplevda fördelar! Granskningsmöten möjliggör: Förvissning att projektet är på rätt väg Ökar kundens tillit och förtroende identifierar problem tidigt! Granskningsmöten hjälper ofta till att erhålla ledningsstöd (projekt status och progress till projekt sponsorer) Upplevda utmaningar! Har ingen formell modellering av detaljerade krav -> formell verifiering! Consistency checks (konsistens kontroll) eller formella inspektioner har man sällan! Brist på tillgång till kund kan skapa problem vid acceptanstest då kunden ska utveckla testerna. Ofta används QA-personal för att hjälpa kunden utveckla dessa tester. Diskussion Prioritering! Diskutera följande frågor: Varför behövs prioritering? När ska man göra prioriteringar? Vem (vilka roller) är lämpliga att göra prioriteringar? Viktiga frågor kring prioritering! Varför prioritera?! När ska man prioritera?! Hur ska man prioritera?! Vem ska prioritera?! Vad ska prioriteras? Definition! Prioritisation = to list or rate in order of priority! Priority = 1 a (1) : the quality or state of being prior (2) : precedence in date or position of publication b (1) : superiority in rank, position, or privilege (2) : legal precedence in exercise of rights over the same subject matter 2 : a preferential rating; especially : one that allocates rights to goods and services usually in limited supply that project has top priority 3 : something given or meriting attention before competing alternatives
Varför prioritera? Vi måste höja! systemets prestanda! Vi måste uppfylla! nya krav! Vi har inte nog! med pengar! Tiden rinner iväg! Nyttan med att prioritera! Fokusera på det viktigaste! Hitta hög- & låg-prioriterade krav! Implementation av rätt krav i rätt ordning! Spara tid och pengar Vi måste fixa! alla felrapporter! Vi är ont om folk! Hur ofta används olika funktioner egentligen? Exempel på hur det kan vara: Ibland,! ofta eller! alltid! 36% Sällan! 19% Aldrig! 45% 80-20-regeln! Pareto-principen (vital few, trivial many) 20% av kraven står för 80% av värdet 20% av kraven står för 80% av kostnaden 20% av kraven står för 80% av risken! Några krav har Högt värde och låg kostnad, andra har Lågt värde och hög kostnad [Butler Group]
Exempel från industriprojekt 13 The requirements! value for customer 1 2 4 5 6 3 7 8 9 10 14 11 12 The requirements! cost of implementation Utmaningar med prioritering! Abstraktionsnivå på prioriteringsobjekt! Kombinatorisk explosion! Beroenden! Inte lätt att prediktera framtiden Vad behöver göras?! Välja vad som ska värderas:! prioriteringskriterier! Välja vad som ska prioriteras:! prioriteringsobjekt! Strukturera och gruppera: på lagom nivå och rimligt antal! Gör själva prioriteringen: prioriteter för varje objekt och kriterium! Visualisera, diskutera, iterera,
Objekt & kriterier! Objekten är ofta produktegenskaper eller högnivåkrav som står för sig själv! Kriterierna kan vara t.ex. Kundvärde Utvecklingskostnad Utvecklingstid Teknisk risk Passar säljtidpunkten Passar varumärket! Maximera / Minimera På vilken nivå ska vi prioritera? När prioritera? På vilken skala ska vi ange prioriteter?! Inför beslutspunkter, t.ex. Projektstart Konstruktionsstart Releaseplanering Inkrementplanering! Vid stora förändringar! Upprepade gånger med lagom intervall Kategorisering ex: måste-krav, tvetydiga, ändringsbenägna Ordinal skala ex: dyrare, större risk, högre värde Ratioskala ex: $, h, % (relativ) Dela in i grupper utan inbördes ordning Rankad lista A>B Numeriska relationer A=2*B
Olika principer för prioritering! Kategorisering Exempel: Stabila, Ändringsbenägna, Oumbärliga, Uteslutna Ger olika högar med krav! Sortering på ordinal-skala Parvis jämförelse < mer eller mindre Ger rangordnad lista! Estimering på ratio-skala Parvis jämförelse på graderad skala Ger estimat för varje krav som ger relationer " # Antal timmar " $ Pengar " % Relativt Olika tekniker för prioritering! Analytical Hierarchy Process (AHP) Ratio-skala, parvisa jämförelser, kräver verktygsstöd, ger mått på graden av konsekvens (consistency)! Ranking (sortering) Ordinal skala, parvisa jämförelser, enkel! Numeriska betyg Ordinal skala; snabb och enkel; risk att allt blir lika viktigt då kraven inte ställs mot varandra; risk att folk tolkar som ratio-skala (även om betyget 4 inte nödvändigtvis är dubbelt så mycket som betyget 2 )! Top-ten Ordinal skala, snabb och enkel, ger grov uppskattning av en begränsad del av kraven Vanlig industriell praxis! Kraven kategoriseras på skala 1-4 [Lau:7.4]! Problem: Kraven ställs aldrig mot varandra Vilket ska bort när viktigt krav tillkommer? Allt tenderar bli viktigast; ger beslutskramp Hur sker prioriteringen?! Arbetsgrupper eller individuellt? Gruppdynamik kan påverka Viktigt skapa konsensus?! Distribuerat i tid och rum?
Parvisa jämförelser: värde Which requirement has the higher value for customer? Parvisa jämförelser: kostnad Which requirement has the higher cost of implementation? Normal papers Very much more More Equal More Very much more Image enhancement Normal papers Very much more More Equal More Very much more Image enhancement Image enhancement Memory buffer Image enhancement Memory buffer Voice control Address book Voice control Address book Hur lång tid tar det?! Kategorisering snabbast men ger minst Jämförelserna går snabbare med tiden! Parvisa jämförelser: Minst en jämförelse per krav Om fler görs kan man upptäcka inkonsekvenser Maximal redundant: n*(n-1)/2
Visualisering - värde Visualisering - kostnad Kostnad-värde-diagram Inkrementell prioritering! När nya krav tillkommer: Infoga i strukturen Jämför med befintliga krav Visualisera, diskutera, revidera
Ändringshantering Analytical Hierarchy Process! Utvecklad av Thomas L. Saaty på 80-talet Allmän teknik inom beslutsteori! Parvisjämförelse av alla möjliga par på ratioskalan: 1 Of equal value 3 Small difference 5 Essential or strong value 7 Very large difference 9 Extreme difference 2, 4, 6, 8 Intermediate values Matrisberäkningar ger prioriteter och mått på graden av inkonsekventa jämförelser Consistency Releaseplanering Konsekvent! Att välja ut en mängd krav som skall implementeras i nästa utgåva. Inkonsekvent AHP föreslår 0.1 som övre gräns för hanterbar inkonsekvensgrad, men det är för restriktivt i kravsammanhang då osäkerheterna ofta är stora
Releaseplanering! Att välja ut en mängd krav som skall implementeras i nästa utgåva. Mest risk först? Det som konkurrenterna inte har först? Få arkitekturen på plats? Nödvändigaste funktionerna först? Funktion före tillförlitlighet? Release-tema? Krav som är beroende?
Summering Nytta av prioritering! Fokusera på det viktigaste! Hitta hög- & låg-prioriterade krav! Implementation av rätt krav i rätt ordning! Spara tid och pengar! Prioritera i era projekt! Inlärningsmål: Kunskap och förståelse! För godkänd kurs skall studenten kunna: definiera grundläggande begrepp och principer inom kravhantering redogöra för ett flertal olika typer av krav redogöra för och värdera ett flertal olika metoder och tekniker för kravhantering beskriva och relatera olika delprocesser inom kravhantering beskriva kravhanteringsprocessens relation till övriga processer i produktlivscykeln 54 Inlärningsmål: Färdighet och förmåga För godkänd kurs skall studenten kunna: välja lämplig kravhanteringsteknik för sammanhanget använda flera olika tekniker för att identifiera krav använda flera olika tekniker för att specificera krav använda flera olika tekniker för att validera krav använda flera olika tekniker för att prioritera krav Inlärningsmål: Värderingsförmåga och förhållningssätt För godkänd kurs skall studenten kunna medvetet kunna välja arbetssätt efter hur kravbilden ser ut på ett adekvat sätt kunna involvera användare i kravprocessen visa ett prov på ett systematiskt och långsiktikt arbetssätt medvetet kunna problematisera över kravkvalitetens påverkan på slutproduktens kvalitet 55 56
Vad händer nu?! Sista övningen 2/10! Labb torsdag 15/10 Glöm inte förberedelse uppgiften!! ANONYMA TENTOR GLÖM INTE ANMÄLA ER! Tenta lördagen den 24 oktober kl. 8-13 Tips skriv mycket på den sista delen! En tenta oktober