MODUL1 Flashcards
(37 cards)
Förklara Boehms kurva
kap 1
Boehms kurva, Barry W Boehm, felens kostnad ökar tiofalt med varje led/steg i arbetet. 10 kr i kravfasen, 100 kr i designfasen, 1000 kr i implementeringsfasen, 10 000 kr om felet hittas i produktion.
kurvan visar att de tester som görs i slutet(acceptanstest) är de dyraste testerna. Därför bör testerna börjas tidigt så som komponenttest
definition av
Krav
kap 1
Ett krav är en önskvärd egenskap eller funktion hos ett IT-system
10 vanliga anledningar att inte arbeta med krav:
kap 1
- Användarna vet inte vad de vill ha
- Vi vet redan vad användarna vill ha
- Vem bryr sig om vad användarna vill ha?
- Vi har inte tid att skriva krav.
- Det är för svårt att skriva krav.
- Problemet är för svårt för att beskriva i form av krav.
- Min chef rynkar pannan när jag skriver krav, hen tycker att jag ska arbeta med viktiga uppgifter i stället.
- Det är lättare att ändra systemet senare än att skriva krav.
- Vi har redan börjat skriva kod, vi vill inte sabotera arbetet.
- Vi behöver inga krav, vi arbetar “objektorienterat”.
Varför är det viktigt att arbeta med kravhantering?
kap 1
att ha en bra/rätta hantering av krav ger bättre krav som ger bättre kvalite på systemet.
behövs för att kunna leverera systemet i tid, med rätt kvalite och inom budget
kraven har sällan den kvalitet som behövs för avancerade system, därför behöver de hanteras
felkällor vid utveckling av it-system
enligt James Martin
kap 1
- Krav 56%
- Design 27 %
- Implementering av kod 7%
- Annat 10%
Felmultiplicering
kap 1
det blir flera fel av ett fel
kan hända om ett fel hittas för sent i utvecklingen av systemet
Faktorer som påverkar om kraven ska realiseras eller inte:
kap 1 s.24
- hur lång tid det tar att realisera kravet
- hur stor mängd krav som finns (kravmassa)
- vilka personer som finns tillgängliga
- projektets budget
- hur stor teknisk risk kravet är förknippat med (de som är förknippade med stora risker bör lösas tidigt annars kan man tvingas göra om det man redan skapat)
Förklara
Kravhanteringsprocessen Stjärnan
kap 1
- Samla in
Definiera syfte, mål, målgrupp, omfattning och avgränsning av insamling. Samla in krav för intressenter från olika delar av verksamheten för att få bra bredd på användare.
Det är övergripande krav som samlas in.
Kan samlas in med workshops, intervjuer och enkäter. - Strukturera
Det pågår kontinuerligt. Syftet är att skapa en struktur som är lätt att överblicka och förvalta. - Prioritera
Se vilka krav som ger mest värde för pengarna, vilka som har störst risker. Utifrån det bestämmer vilka av kraven som ska realiseras först. Prioriteringen görs av beställaren. Finns olika skalor/tekniker som låg/medel/hög eller måste/bör. - Dokumentera
Formellt kontrakt mellan beställare och leverantör.
risk att dokumentationen blir mindre välskriven när leverantören är intern. Annars skrivs ett avtal om vad som ska levereras mot vilken ersättning. Dokumentationen tas fram för flera parter som utvecklare, kunder, användare, beställare, testare. - Kvalitetssäkra
För att säkerställa att rätt krav är dokumenterade. Dokumentering Granskning.
En återkommande aktivitet. Täta leveranser för att kunna testa det och justera det i tid. - Förvalta
Hantera ändringar i kraven. Risken för fel ökar om kraven ändras dagligen, de bör därför vara frysta i en period. Vanligt att CCB tar beslut om ändringar, påverkningsanalys
förklara
Kvalitetssäkring
kap 1
= alla planerade och systematiska åtgärder nödvändiga för att ge tillräcklig tilltro till att en produkt kommer att uppfylla givna krav på kvalitet.
Nämn tre utvecklingsmetoder och beskriv hur kravhantering fungerar i dem.
kap 1
- Sekventiell
hela systemet utvecklas i en enda sekvens - Iterativ
bygger liten del av systemet och förfinar det i utvecklinsetapper också kallade iterationer - Agil
korta iterationer av hög kvalitet, tester görs ofta gärna med automatiserade testfall
Nämn alla steg, tester och dokument som ingår i
V-modellen
illustrerar hur kravhantering relaterar till test inom systemutveckling
kap 1
- Krav(kravspec & användningsfall) - Acceptanstest
- Övergripande design (funktionsspec) - Systemtest
- Detaljerad design (designspec) - Integrationsstest
- Kodning - Komponenttest
se dokument MODUL 1 för beskrivning av varje nivå
Vad menas med
Kvittering
(v-modellen)
kap 1
kvittering/handskakning är när leverantören bemöter varje krav från beställaren…??
Vad finns det för typer av krav enligt FURPS+?
kap 2
Functionality (funktionalitet)
Usability (användbarhet)
Reliability (tillförlitlighet)
Performance (prestanda)
Supportability (underhållbarhet)
+(designrestriktioner)
u, r, p, s är alla icke funktionella krav.
furps+ används tex i RUP
Beskriv
Funktionella krav
kap 2
beskriver vad systemet ska göra.
Många av dem kan beskrivas med indata och förväntat utdata
Beskriv
Icke-funktionella krav
kap 2
Beskriver hur systemet ska fungera.
Kompletterar de funktionella kraven.
Beskriv de fyra slags krav som Ickefunktionella krav kan delas upp i
enligt furps+
kap 2
Användbarhet
* Hur lätt det är att använda och lära sig systemet.
* Behöver beskrivas så de går att mäta och testa.
* Kraven på användbarhet beskrivs på en systemövergripande nivå
Tillförlitlighet
* Ska kunna lita på systemet efter lång tids användning.
* Ett mått på detta är fel frekvens, hur ofta fel får förekomma och av vilken allvarlighetsgrad.
* Ett krav för tillförlitlighet bör innehålla: specificerad tillförlitlighet och en tidsperiod.
Prestanda
* Kan uttryckas i svarstid, transaktionsfrekvens eller genomströmning.
* Testas ofta under systemtesterna
Underhållbarhet
* Systemet ska vara billigt och enkelt att underhålla och förvalta.
* testbarhetskrav
* ex på krav, det ska gå att uppgardera syetmet utan att störa andra system
* 10 kravkategorier inom förvaltningsbarhet:
1. dokumentation
2. arkitektur och design
3. källkod
4. tredjepartsprodukter
5. testfall
6. körande system
7. underhållsorganisation
8. process
9. systemövergripande
10. ägande
Beskriv + i FURPS+
kap 2
Designrestriktioner
Direktiv för utvecklingen som måste uppfyllas av leverantören eftersom de är beslutande av beställaren. ex, systemet ska vara programmerat i ett specifierat språk.
Beskriv
Normala krav
kap 2
- enklaste kraven att hantera
- om de uppfylls blir kunden nöjd, annars missnöjd
- samla in med ex, intervjuer och workshop
Beskriv
Förväntade krav
kap 2
- så självklara att kunden /beställaren inte tänker på att nämna dem
- kraven är lätt att missa och måste tolkas in
- räcker inte med intervjuer för att samla in dessa krav
- om de uppfylls är kunden neutral, annars missnöjd
Beskriv
Sensationella krav
kap 2
- kan vara något nyttigt som leverantören hittar som beställaren inte visste var tekniskt möjligt.
- om de uppfylls blir beställaren nöjd, annars neutral
- tex automatisering
- beställaren måste godkänna dessa krav innan utvecklingen går vidare.
Förklara vad en intressentanalys är och beskriv arbetssättet i den.
kap 3
Identifiera intressenter genom att jobba i grupp. Gruppen kan bestå av folk som gjort förstudie och representanter från beställare och leverantör
- namn på projektet i mitten av tavlan i en cirkel
- deltagare skriver upp tänkbara intressenter på gula lappar runt omkting cirkeln
- pilar ritas från cirkel till lappar
- deltagarna disskuterar vad intressenten får/kräver av projektet och tvärtom.
- detta skrivs också upp på tavlan
Vanliga problem med att samla in krav
kap 3
- svårt att veta vad man vill ha som beställare
- svårt att få tillgång de olika intressenterna
- användare saknar teknisk kompetens
- beställare/användare har svår att förklara sin verksamhetskompetens
- beställare/användare använder uttryck som utvecklarna inte förstår och tvärtom
- beställare/användare är negativa till förändring → kommunikationsproblem
- beställare är orutinerade och oengagerade
- personal byts ut
- beställare vill att leverantör ska tala om hur systemet ska se ut
Ange tekniker att samla in krav på
kap 3
- Workshop
- Ostrukturerad intervju
- Strukturerad intervju
- Enkät
- Observering
- Användningstest
- Prototyp
- Användsningsfallsmodellering
- Personas
- Kortsortering
- Laddering
- Kravdagbok
- Rotorsaksanalys
Beskriv insamlingstekniken:
Workshop
kap 3
Fördelar och nackdelar med workshop:
+Bra för att snabbt identifiera, strukturera och prioritera övergripande krav.
+Omedelbar förankring och samsyn för deltagare
-Kräver tränad workshopledare
-Omfattande krav på förberedelse.
Intressenter träffas med workshopledare för att spåna fram idéer. Deltagarna kan skriva ner sina idéer på post-it-lappar och sätta upp dem på en whiteboardtavla.
En workshop har tre olika faser:
1. planering inför
Fastställer syfte, mål, deltagare ochagenda.
Har samtal eller intervju med deltagare.
Använd workshopregler.
Agendan kan se ut såhär: inledning, idegenerering och strukturering, paus, prioritering, avslutning/sammanfattning
se checklista
2. genomförande
Isbrytare
Olika varianter av idegenerering
Ett antal ostrukturerade ideer.
Med gruppering struktureras dem. Då kan ideerna och formuleras om, läggas till, tas bort och grupperna namnges.
3. uppföljning efter
Ta bilder på alla lappar. Skriv en sammanställning. Skicka ut dokumentation till deltagarna så de känner sig delaktiga.
Skillnaderna mellan vanligt möte och workshop handlar om upplevd tid, ledarens verktygslåda och deltagarnas engagemang.
