Tentafrågor 1. Grupp. B

Transkript

1 Tentafrågor 1 Grupp. B Sebastian Buks (ic05sb3@student.lth.se) Andreas Edmundsson (ic05ae6@student.lth.se) Birger Hedberg-Olsson (ic05bh3@student.lth.se) Omar Khan (ic05ok5@student.lth.se) Victor Lindell (ic05vl7@student.lth.se) David Sandberg (c04ds@student.lth.se) 11 februari

2 Fråga 1. Projekttyper I utveckling baserad på löpande räkning bestäms kraven tidigt i projektet för att sedan inte ändras under utvecklingstiden. För att skapa sig en tydlig kravbild i projektet och på så sätt gynna den resterande utvecklingsprocessen bestäms kraven tidig i projektet. Det ger utvecklarna en tydligare förståelse för vad man arbetar med och gör att kostnaderna inte skenar iväg. E. (Både påståendet och anledningen är felaktiga uttalanden.) I utveckling baserad på löpande räkning är kraven till en början rent informella (och ofta helt odokumenterade). Istället skapas dessa under utvecklingens gång. Det är dessutom aldrig en bra idé att skriva kraven i sten för att sedan inte tillåta förändring under projektets livtid; förutsättningar kommer att ändras och krav kan t om visa sig vara orealistiska eller helt saknas. Lau:1 sid

3 Fråga 2. Kravtyper Produkten ska ha ett startfönster i enlighet med den bild som visas i appendix A. Detta är ett typiskt krav på design-nivå. Generellt specificerar design-krav detaljer noggrant och visar hur detta ska implementeras i produkten. C. (Påståendet är korrekt, men anledningen är ett felaktigt uttalande.) Det är riktigt att design-krav specificerar detaljer angående ex. ett visst interface noggrant men det är ett felaktigt påstående att samma krav specificerar hur detta skulle implementeras i produkten. Det senare skulle snarare begränsa utvecklarna av att göra ett så optimalt system som möjligt. Lau:1 sid 26. 3, 5 3

4 Fråga 3. Kravnivåer Ett krav på domän-nivå kan vara både funktionellt och icke-funktionellt. Ett exempel på ett icke-funktionellt domän-krav är den totala tid det tar för en användare att utföra en särskild handling i ett visst system. Med tid avses då både den manuella tid användaren behöver samt den processtid systemet har. A (Både påståendet och anledningen är korrekta uttalanden OCH anledningen förklarar påståendet på ett korrekt sätt.) Det stämmer att ett domän-krav både både kan vara funktionellt och icke-funktionellt. Domänen avser dels produkten men också omgivningen runt produkten och ett icke-funktionellt (kvalitetskrav) krav kan mycket väl behandla en tidsprestation. Lau:1 sid 15 &

5 Fråga 4. Projekttyper Med projekttypen Product Development kan det vara svårt att utveckla för en specifik marknad med specifika kunder. Kunden i sammanhanget är ofta marknadsavdelningen i ett företag medans leverantören är utvecklingsavdelningen. A (Både påståendet och anledningen är korrekta uttalanden OCH anledningen förklarar påståendet på ett korrekt sätt.) Ett stort problem i denna typ av projekt är att utvecklarna sällan eller aldrig ser den verkliga kunden (som ska köpa produkten) utan måste förlita sig på marknadsavdelningens egna tolkning av marknaden och dess krav. Lau:1 sid

6 Fråga 5. Fokusgrupp Fokusgrupper är ett bra sätt att en bit in i projektet lufta problem mellan olika intressenter. Fokusgrupper är som en strukturerad brainstorming. Eftersom att alla inblandade parter är samlade är det ett lämpligt tillfälle att ta upp problem, idéer och framtiden. A (Både påståendet och anledningen är korrekta uttalanden OCH anledningen förklarar påståendet på ett korrekt sätt.) En bra sammanfogad fokusgrupp är ett utmärkt tillfälle att lufta problem mellan projektets alla intressenter. Lau:8 sid

7 Fråga 6. Observation Observation är en bra metod för att få reda på kundens huvudsakliga mål. Eftersom kunden ofta inte vet vad de vill ha men vill hjälpa till, ger de därför logiska men ibland felaktiga svar. D (Påståendet är felaktigt, men anledningen är ett korrekt uttalande) Intervju eller intressentanalys är en bättre metoder för att få reda på kundens mål. Observation är inte så bra eftersom det är svårt att se vilka mål kunden har. Observation är istället en bra metod för att se hur kunden arbetar. Anledningen stämmer men är inte anledningen till varför påståendet stämmer. Lau:8 sid 340,

8 Fråga 7. Eliciteringsmetoder Att bestämma eliciteringsmetod är viktig och är något som kan vara tidskrävande. Att välja fel metod kan få hela projektet på fall. E (Både påståendet och anledningen är felaktiga uttalanden.) Lausen säger att man hellre ska testa en metod istället för att lägga tid på att diskutera om den kanske fungerar. Att välja fel är inte ödestiget då man lätt kan göra flera eliciteringsmetoder. Lau:8 sid

9 Fråga 8. Datamodell En datamodell presenterar produktens data väl oavsett vilket utvecklingsskede produkten befinner sig i. En E/R-modell som beskriver information på domännivå kommer att likna den färdiga produktens E/R-modell. A (Både påståendet och anledningen är korrekta uttalanden och anledningen förklarar påståendet på ett korrekt sätt) Påståendet är rätt då datamodeller är okänsliga av vilken implementationsnivå produkten befinner sig i. Anledningen är också sann eftersom en tidig analys av information på domännivå kommer att skapa en modell som kommer beskriva informationen även vid implementationen. Lau:2 sid 54. 6, 7. 9

10 Fråga 9. Data ordlista Att upprätta en data ordlista är en tidskrävande process. Då en data ordlista skapas är det lätt att veta när den är klar. C (Påståendet är korrekt, men anledningen är ett felaktigt uttalande) Påståendet är rätt, då det är lätt att göra en data ordlista för detaljrik och därmed kan processen bli väldigt tidskrävande. Dock är anledningen felaktig då det är svårt att avgöra när ordlistan är fullständig. Lau:2 sid 59. 1, 3. 10

11 Fråga 10. Virtuella fönster Med virtuella fönster kan produktens gränssnitt användbarhetstestas i ett tidigt utvecklingsskede. Genom att specificera snygga menyer och knappar kan kunden lätt förstå och få en övergripande bild av produktens användargränssnitt. C (Påståendet är korrekt, men anledningen är ett felaktigt uttalande) Påståendet är korrekt då brister kan upptäckas tidigare än traditionella användbarhetstester. Däremot är anledningen inte korrekt då snygga menyer och knappar ej skall vara specificerade i virtuella fönster. Lau:2 sid 69. 1, 5. 11

12 Fråga 11. Funktionskrav Funktionskrav är ofta komplicerade att implementera även om leverantören förstår dem. Leverantören måste hela tiden tänka på att funktionskraven möjliggör för kunden att uppfylla sina affärsmål. E (Både påståendet och anledningen är felaktiga uttalanden) Påståendet är falskt eftersom det ofta är lätt för leverantören att direkt översätta funktionskrav till funktioner till exempel i program. Anledningen är sann eftersom leverantören ofta inte alls behöver beakta kundens affärsmål. Lau:3 sid 86. 1, 3, 4, 6, 10,

13 Fråga 12. Funktionskrav Överlag gillar inte kunder funktionskrav. Även fast kunden verkligen förstår funktionerna, har kunden svårt att se om funktionerna kommer uppfylla affärsmålen. D (Påståendet är felaktigt, men anledningen är ett korrekt uttalande) Påståendet är falskt eftersom överlag älskar kunderna funktionskrav, det är lätt för kunden att kontrollera att alla funktioner är med i slutprodukten. Anledningen är korrekt eftersom det ofta är svårt att koppla ihop funktioner med om affärsmålen blir uppfyllda. Lau:3 sid 87. 1, 3, 6, 10, 16 13

14 Fråga 13. Händelselista Händelselista för användargränssnitt bör endast användas om design-nivå krav behövs. Händelselista för användargränssnitt är i huvudsak ett design problem. A (Både påståendet och anledningen är korrekt uttalande OCH anledningen förklarar påståendet på ett korrekt sätt) Påståendet och Anledningen är korrekta, händelselist är ett design problem och bör endast användas då design-nivå krav skall tas fram. Lau:3 sid 83. 1, 3, 5 14

15 Fråga 14. Relationer och gruppering mellan krav Relationer och beroende mellan krav används ofta för att gruppera kraven i grupper som skall implementeras tillsammans. Grupperingen av kraven görs för att effektivisera implementation. A (Både påståendet och anledningen är korrekta uttalanden OCH anledningen förklarar påståendet på ett korrekt sätt.) Krav som hänvisar eller relaterar till samma delar av systemet skall utvecklas av samma personer. MDRE1 sid 595. stycke 4.6 7, 9 15

16 Fråga 15. Förändring i kravarbetet Att skapa acceptans för ny praxis i kravhanteringsarbetet är mycket utmanande. Det är svårt att ändra folks invanda beteende och att få alla att arbeta efter samma nya metod. A (Både påståendet och anledningen är korrekta uttalanden OCH anledningen förklarar påståendet på ett korrekt sätt.) Artikeln visar att företagen har många nya bra idéer, verktyg och metoder. Men att det är mycket jobbigt att börja använda dem. MDRE1 sid 595, 596 stycke , 9 16

17 Fråga 16. Marknadsdriven utveckling Intressenterna underlättar kravprocessen i en marknadsdriven utveckling. Den breda gruppen intressenter, i en marknadsdriven utveckling, genererar ett oavbrutet flöde med nya krav. D (Påståendet är felaktigt, men anledningen är ett korrekt uttalande.) Hanteringen av det oavbrutna flödet med krav är en av de svåraste utmaningarna i kravhanteringen hos den marknadsdrivna utvecklingen. MDRE1 sid 597, 589 stycke , 2 17

18 Fråga 17. Distribuerad prioritering Distribuerad prioritering kan användas när marknaden är uppdelad i segment. Distribuerad prioritering är endast bra i teorin men fungerar inte i praktiken. C (Påståendet är korrekt, men anledningen är ett felaktigt uttalande.) Enligt artikeln är distribuerad prioritering användbar och resultatet är användbart. PRIO1 sid , 14, 15 18

19 Fråga 18. Distribuerad prioritering Alla de olika intressenternas (som representerar olika marknadsandelar) prioritering spelar lika stor roll när beslut om produktens framtid tas. När sammanslagningen av all de olika intressenternas prioritering är gjord går resultatet inte att ändra på. E (Både påståendet och anledningen är felaktiga uttalanden.) Påståendet är falskt eftersom de olika intressenternas prioritering inte spelar lika stor roll. Hur mycket influens en intressent har baseras på ett eller flera kriterier som till exempel vinst under tidigare utgåvor eller storlek på marknadsandelen. Anledningen är också falsk, när sammanslagningen skett skickas den ut till alla intressenter och om det sedan är nödvändigt sker en iteration av prioritering till. PRIO1 sid 53. 2, 13, 14 19

20 Fråga 19. Relationer mellan krav AND-relationen mellan två krav är samma sak som två stycken REQUIRES-relationer i båda riktningar. AND-relationen har i detta fall prioritet över REQUIRES-relationerna. A (Både påståendet och anledningen är korrekta uttalanden OCH anledningen förklarar påståendet på ett korrekt sätt.) Tittar man på definitionerna av relationerna ser man att AND är samma sak som REQUIRES i båda riktningarna. Det är meningslöst att har två stycken REQUIRES, AND prioriteras därför. INTERDEP avsnitt 2. 3, 13 20

21 Fråga 20. Relationer mellan krav Relationer mellan krav är oftast jämt fördelade över alla kraven. Under planeringen av ett produktsläpp är förutom kravens prioritet, relationerna mellan kraven en viktig faktor att tänka på. D (Påståendet är felaktigt, men anledningen är ett korrekt uttalande.) Påståendet är falskt eftersom enligt artikeln visade undersökningarna på att ca 10% av kraven stod för 50% av relationerna, alltså är relationerna inte jämnt fördelade. Att kraven har relationer mellan varandra gör det omöjligt att endast gå efter prioritet vid produktplanering, alltså är anledningen sann. INTERDEP abstract samt avsnitt 1. 13, 16 21