mangagment Flashcards
Vad är målet med mangement activity?
identifiera ändringar (utifrån kontexter ) och uppskatta hur dessa förändringar kommer att påverka
Vilka olika ändringar finns det som kan behövas göras utifrån olika kontexter
- Stakeholders utvecklar sina goals
- Lagar och regleringar
- Ny teknik eller konkurenter dyker upp
- Ändringar i hur man ska använda system
- Regler och policyes på jobbet
Vad är målet med requirment change mangement?
Att hantera ändringar i kraven för att se till att det blir rätt beslutat
Vilka tar detta beslut om en request of change?
Change control board
Hur kan man göra en change of request? (NRREC)
- Det kan finnas en presentation på nya krav
- Ta bort ett krav som finns
- Förlänga ett krav som finns
- Change exisiting requirment
- reduction exisitng requirment (TO BIG)
Change of request dokumenteras med några detaljer, nämn vilka parametrar
- Description, typ av ändring, 2. status (hög/låg)
- effort (1 vecka, 2 dagar osv) ,
- orginator (author)
Process of change the request
vad gör första steget med kraven?
- Classification of request, vilken typ av ändring ska göras?
- Hot fix = ändringen måste göras nu
- Corrective = erorr i systemet som beror på kravet
- Adaptive = systemet måste ändras för att det finns ny teknik
Process of change the request #2
Impact of analys = hur mycket effort krävs för att ändra kravet och hur påverkar det de andra kraven
- Evaultion of changed request
lägg fram tid och kostnad för styrelse.
- Prioritece change of request
om ndring accepteras av styrelse så måste kraven som kommer in prioriteras
moniotoring change of request
Hur integrerar kravet med andra krav och systemet
Requriment versioning handlar om
Hur numrerar man versioning?
Att ha tillgång till kraven som ändras genom en livcykel när det gäller om kraven extend, change, reduce or what ever.
- Man numrerar versionerna men när man gör större ändringar så sätter man en etta framför.
ex v0.1, v0.2 och sen v1.1 vid större förändring
Agil processen för change mangment handlar om
att vara flexibel och välkomna ändringar i utvecklingen för bättre system
nämn 3 områden som reqest of change in requirment kan grunda sig i?
user experice - ändra uppelvesen för använder när det gäller Ux
Technical = man kanske inte ser dom men dom kan ändras för att spara in tid och pengar
Scope - när vissa funktioner inte behövs eller kan framflyttas till nästa realse.
How does requirment mangement support traceability?
Traceability handlar om att spåra kraven från början till slut i en livscykel i ett system
3 olika typer av traceability =
Vad handlar dependency om mellan user stories?
Att om krav 2 behöver krav 1 är det ett dependency
kan man ta bort alla dependency mellan user stories?
Nej, men man ska försöka ta bort dom man hittar
exempel på dependency med reklam
vi kan inte ta bort reklam förrän vi skapat det.
Nackdelar som gör att man inte kan prioritera
pengar, begränsat med resurser, tid, männiksor
Hur proriterar man krav?
Enligt criterier för framtida utveckling
när eller var proriterar man user stories
Man proriterar dom när dom skapas eller när dom läggs i backlog
Criterier för att prioritera krav
- Importance, cost, duration, risk, damge (om den ej utvecklades), volatility ( sannolikhet att det ändras över tid)
Nämn 2 metoder man kan implemtera criterierna i för att prioritera kraven
- Stack rankning method - Går igenom kraven i backlog och placerar dom i order efter critera
- MOSCOW method - Must have = Måste finnas i system
should have = man måste ej ha dom men dom svider om dom inte är med men dom påverkar lite bara om de ej är med i första realse tänk att man kan göra pappersarbete medans det ej finns i system
could have = finns det budget och tid över. Se det som att det är extra om det är med, exempelvis att man kan ha panorama fönster istället för vanliga, vi kan välja att logga in med mobil och dator
wont have = out of budget, men kan komma senare, ex effekter eller extra saker. ex ljudeffekter när man får en swhish, när man byter sida, serveras changpage på flygplan osv
tekniker för prioritering av krav
- Cost of delay - compare highest cost of delay and cheapest to do first.
kano method = handlar om kundernas satiscfaction. man proriterar kraven utifrån 3 områden:
Dissatisfaction = must be, kunden bryr sig inte för det förväntar sig detta. ex bild med hjul, ratt, broms osv.
Satsification = more is better, from existing requirments. kund efterfrågar detta för att bli glad, ex få påminnelse när något är i lager,. det måste inte finnas i systemet men kund vill ha det.
delighter = något som kund ej förväntar sig men som gör dom glada, det kan vara spela in film på tv box, få bonus när de fyller osv.
kano classification evolution handlar om
Det som förut ansåg som kanske en delighter är idag kanske en disssatisfier
