mangagment

Question 1

Vad är målet med mangement activity?

Answer 1

identifiera ändringar (utifrån kontexter ) och uppskatta hur dessa förändringar kommer att påverka

Question 2

Vilka olika ändringar finns det som kan behövas göras utifrån olika kontexter

Answer 2

• 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

Question 3

Vad är målet med requirment change mangement?

Answer 3

Att hantera ändringar i kraven för att se till att det blir rätt beslutat

Question 4

Vilka tar detta beslut om en request of change?

Answer 4

Change control board

Question 5

Hur kan man göra en change of request? (NRREC)

Answer 5

1. Det kan finnas en presentation på nya krav
2. Ta bort ett krav som finns
3. Förlänga ett krav som finns
4. Change exisiting requirment
5. reduction exisitng requirment (TO BIG)

Question 6

Change of request dokumenteras med några detaljer, nämn vilka parametrar

Answer 6

1. Description, typ av ändring, 2. status (hög/låg)
2. effort (1 vecka, 2 dagar osv) ,
3. orginator (author)

Question 7

Process of change the request

vad gör första steget med kraven?

Answer 7

1. Classification of request, vilken typ av ändring ska göras?
2. Hot fix = ändringen måste göras nu
3. Corrective = erorr i systemet som beror på kravet
4. Adaptive = systemet måste ändras för att det finns ny teknik

Question 8

Process of change the request #2

Answer 8

Impact of analys = hur mycket effort krävs för att ändra kravet och hur påverkar det de andra kraven

Question 9

3. Evaultion of changed request

Answer 9

lägg fram tid och kostnad för styrelse.

Question 10

4. Prioritece change of request

Answer 10

om ndring accepteras av styrelse så måste kraven som kommer in prioriteras

Question 11

moniotoring change of request

Answer 11

Hur integrerar kravet med andra krav och systemet

Question 12

Requriment versioning handlar om

Hur numrerar man versioning?

Answer 12

Att ha tillgång till kraven som ändras genom en livcykel när det gäller om kraven extend, change, reduce or what ever.

2. 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

Question 13

Agil processen för change mangment handlar om

Answer 13

att vara flexibel och välkomna ändringar i utvecklingen för bättre system

Question 14

nämn 3 områden som reqest of change in requirment kan grunda sig i?

Answer 14

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.

Question 15

How does requirment mangement support traceability?

Answer 15

Traceability handlar om att spåra kraven från början till slut i en livscykel i ett system

Question 16

3 olika typer av traceability =

Question 17

Vad handlar dependency om mellan user stories?

Answer 17

Att om krav 2 behöver krav 1 är det ett dependency

Question 18

kan man ta bort alla dependency mellan user stories?

Answer 18

Nej, men man ska försöka ta bort dom man hittar

Question 19

exempel på dependency med reklam

Answer 19

vi kan inte ta bort reklam förrän vi skapat det.

Question 20

Nackdelar som gör att man inte kan prioritera

Answer 20

pengar, begränsat med resurser, tid, männiksor

Question 21

Hur proriterar man krav?

Answer 21

Enligt criterier för framtida utveckling

Question 22

när eller var proriterar man user stories

Answer 22

Man proriterar dom när dom skapas eller när dom läggs i backlog

Question 23

Criterier för att prioritera krav

Answer 23

1. Importance, cost, duration, risk, damge (om den ej utvecklades), volatility ( sannolikhet att det ändras över tid)

Question 24

Nämn 2 metoder man kan implemtera criterierna i för att prioritera kraven

Answer 24

1. Stack rankning method - Går igenom kraven i backlog och placerar dom i order efter critera
2. 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

Question 25

tekniker för prioritering av krav

Answer 25

1. 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.

Question 26

kano classification evolution handlar om

Answer 26

Det som förut ansåg som kanske en delighter är idag kanske en disssatisfier