Nedan finns studenternas egna förlag på tentauppgifter som lämnats in under kursens gång, tillsammans med kursansvariges kommentarer.
OBS! Dessa tentaproblem är av
varierande kvalitet och bedömningsmallarna kan i många fall diskuteras och innehåller
ibland sakfel, så när ni använder dessa problem för att tentaplugga så får ni
själv bilda er en uppfattning om deras värde som
kunskapsutvärderingsinstrument.
Detta är en
omfattande fråga med relevanta begrepp och utförlig bedömningsmall, men tyvärr
är det i grund och botten är en upprabblingsfråga. Jag får väl erkänna att jag själv
gjort sådana här tentafrågor i min tidiga lärargärning :-), men jag vill försöka
rikta in mig mer på djupförståelse snarare än minneskunskaper. Man kan väl ha
någon enstaka sådanhär fråga på en tenta om det är riktigt grundläggande och
centrala begrepp, men en tenta får inte bara ha denna typ av frågor.
Bra frågor som kräver förståelse. Bedömningsmallen nästa klockren; en liten defekt på en 1-poängare är den felaktiga förklaringen på COTS Purchase - det är inte marknadsavdelningen som gör kravspecen för inköpandet, det är faktiskt uppköparen (även om marknadsavdelningen ju ofta ger produktkrav till utvecklingsorganisationen, men det är inte COTS Purchase utan Product Development eller mer specifik COTS Development (COTS är en slags Product, nämligen en renodlad programvaruprodukt)). Man ska väl också vara vaksam på om S:et i COTS (Commercial Off-theShelf Software) anger "Shelf" eller "Software"; man kan ju mycket väl prata om andra COTS-produkter som nödvändigtvis har programvara, t.ex. kameror. Här kan man läsa en artikel om definitionen på COTS i programvarusammanhang för den intresserade: Maurizio Morisio, Marco Torchiano, "Definition and classification of COTS: a proposal", ICCBSS, Orlando 2002.
Frågorna är
jättebra men bedömningsmallen är tyvärr ofullständig då den inte innehåller
exempellösning. Dessutom ett sakfel: COTS betyder renodlade
programvaruprodukter så de innehåller inte hårdvara och är alltså inte inbyggda
system.
Kanonbra fråga, men
saknar exempel i exempellösningen. Det är exemplen som gör att det inte bara
blir en upprabblingsfråga som kan klaras med fotografiskt minne av boktexten.
Jag vill att ni löser era egna uppgifter i bedömningsmallen och inte bara anger
hur de ska bedömas. (Min erfarenhet som lärare är att om man gör tentauppgifter
utan att lösa dem själv helt och hållet så missar man ofta flera problem med
tentauppiften - tentauppgifter behöver också "debuggas"...)
Bra fråga med
exempel i bedömningsmallen (hade varit ännu bättre om frågan var formulerad så
att exempel inte bara blev de som redan står i boken). Bra med syfte - kopplar
till inlärningsmål och underlättar för examinatorn som ska göra bedömningen.
Dessa båda frågor
är tveksamma. Q1 avslöjar en felaktig tolkning av "tacit". Med
"tacit requirements" menas underförstådda eller dolda krav och ett
"demand" (dvs bakomliggande behov) kan vara både "tacit"
och "explicit". Dessutom stödjer vad jag kan se frågan ej ngt av
kursens inlärningsmål. Q2 är innovativ i sin form med påståendevärdering men
tyvärr är de två första påståendena tvetydiga. De framgår inte om det är
"system validation" resp "system verification" eller
"requirements validation" resp "requirements verification"
som avses. Vilken av dessa tolkningar man väljer avgör om påståendena är sanna
eller falska vilket inte är en trevlig sits för en tentamakare...
Bra fråga
(dessutom den första som är på annat ur litteraturlistan än Lauesens bok för er
som behöver tentaplugghjälp på ngt annat än boken). Testar förståelse och
kräver att man kan värdera fördelar och svårigheter. Bra bedömningsmall.
Jättebra fråga
som hade gett klockren bonus om inte bedömningsmallen hade varit ofullständig.
Ni har egentligen inte löst er egen tentauppgift, och jag bedömer att det blir
svårt att använda mallen för att ge poäng på ett konsekvent sätt. Bra dock att
ni på några ställen ger exempel.
Frågan är ganska bra då upprabblingsgrågan kombineras med en
värderingsfråga kring för och nackdelar. Det stora problemet är att ni själv ej
har angett dessa för/nackdelar i bedömningsmallen. Dessutom är det ju inte så
att vissa för/nackdelar alltid gäller eftersom det är kontexberoende: i vissa
sammanhang är en viss sak en fördel i andra sammanhang en svårighet. Jag hade
velat att ni hade ret ut detta i bedömningsmallen och att ni kanske fått med
detta sammanhangsberoende i redan i frågeställningen. Det finns alltså en
möjlighet här att göra en riktigt bra fråga+bedömningsmall...
Ok fråga och ok
bedömningsmall och bra lösningsförslag. Tråkigt dock att frågan kan klaras med
minneskunskaper, och kräver egentligen ej särskilt mycket djupkunskap.
Bra frågor och
bra svar. (Dock behöver en tender (upphandling) inte vara offentlig.) Några
tveksamheter i mallen: Det vanliga är inte att det blir produkt development
utan snarare contract development (Hur ska den som svarar på ett specifikt
anbud sedan utveckla produkten så att den passar för en öppen marknad utan att
kompromissa med det kundspecifika?). I sambandet borde framgå att det kan
övergå i UPPKÖP av generisk programvara.
Bra fråga + bra
bedömningsmall nu med exempellösning.
I stort bra
frågor och bra svar. Bonusen är "på håret" då a)(ii) är konstig.
Projekttypen i sig föreskriver inget speciellt sätt att "hitta en
leverantör". COTS är ju egentligen namnet på en produkttyp, så
projekttypen borde bli tex "upphandling av COTS" (till skillnad från
"utveckling av COTS", som är ett specialfall av produktutveckling).
Bra fråga + bra
mall och svar. Nu med bra utredning av för och nackdelar.
Bra som kräver
att man tillämpar sina kunskaper genom att välja stilar och sedan använda dem.
Bra bedömningsmall även om det inte är helt solklart hur man ska ge poäng. Ett
litet minus är att ni inte skilt på händelser och funktioner som ju är olika
saker. Kontextdiagrammet är inte gjort som det är tänkt. Det är inte tydligt
vilket som är systemet som ska utvecklas (brukar vara en box med tjockare
linjer) och det saknas nog en hel del aktörer. Den ovala ringen antar jag ska
ange gränsen mellan yttre och inre domän, men det är ju konstigt att den enda
aktörer bara finns i den yttre domänen. Ni som ska tentaplugga får i stället
kolla på kontextdiagram i boken för att se hur de bör se ut.
Bra fråga - dock
finns det väl fler än tre råd att ge när man gör tasksdescriptions så jag
gillar inte formuleringen "finns tre saker". "Don't
program"-exemplet är lite vagt. system.exit? Ej förklarat varför detta är
designnivå. Skillnaden mellan händelse(förlopp) och feature kan redas ut lite
mer, men bra fråga.
Bra fråga. (Hade
velat ha svenska termer i hela frågan.) Hyfsad bedömningsmall. In/utdata är
lämpade att specificera med dataflödesdiagram men själva formatet (datatyp,
antal tecken, etc) passar nog data dictionary bättre till. Jag ställer mig också
tveksam till lekmäns förmåga att validera dataflödesdiagram. Kul med
80-20-regel-frågan! Dock är det inte tillräckligt tydligt att det egentligen
inte är en "regel" efter som det mycket väl kan vara 19-81 eller
varför inte 30-70... Det viktiga är att det nog sällan är precis 50-50 ...
Bra fråga som
testar förmåga att värdera för/nackdelar. I mallen: en bra utredning av
skillnaden mellan olika nivåer på händelser och även hur händelser relaterar till
uppgifter och användningsfall på olika nivå.
Bra fråga som
testar förmågan att avgöra i vilka sammanhang olika stilar passar. Bra mall.
(Dock inte helt uppenbart hur man ska dela ut poäng)
Bra fråga. Dock borde
en nivå till vara med: Designnivå; Screens and Prototypes hamnar där snarare än
på produktnivå.
Bra frågor och
bra mallar. Fråga 1 kräver nog en liten domänbeskrivning för att fungera på en
tentamen (jag tror också att denna fråga kan vara väldigt svår både att lösa
och att bedöma för de som inte är insatta - jag tror att man lött hamnar i
läget att alla eller ingen klarar denna frågan beroende på hur hård man är när
man sätter poäng). Fråga två är på funktionella detaljer och det är enda frågan
som lämnats in på detta hittills och ska man ställa någon fråga på funktionella
detaljer så verkar denna vara lämplig (detta kan ju faktiskt komma på tentan
:-)
Kul med fråga på
labben. 1a "(avancerade)" är lite kryptiskt. Jag förstår att ni vill
undvika att folk svarar word/excell/access, men det är kanske inte verktygens
avancerade nivå som kännetecknar dem, utan snarare att de är specialgjorda för
att stödja (stora delar) av kravhanteringen, ofta med fokus på kravförvaltning
genom livscykeln. Fråga 1b är en tråkig minnesfråga. 1c lite konstigt att ange
"fördel" med COTS - de har väl uppkommit för att någon har trott sig
se en marknad för dem. Fråga 1d är den fråga som är riktigt bra - här får man
verkligen tänka efter och värdera kravhanteringsverktyg utifrån ett praktiskt
perspektiv + bra mall - dock tror jag att den är ganska svår för de flesta som
inte jobbat praktiskt med kravverktyg.
Kul uppgift
med domänbeskrivning. Bra att man får visa vad man kan genom att skriva krav.
Dock har bedömningsmallen en stor svaghet i det att den inte är kopplad
explicit till de olika stilarna i Lauesen för resp kvalitetskrav. Det som också
inte är bra är att de exempel ni ger inte uttryckta på de sätt som Lauesen
rekommenderar, då de tex inte mätbara.
I grunden en
upprabblingsfråga som kan klaras med minneskunskaper.
En bra fråga
som inte är en direkt upprabblingsfråga utan kräver att man kan jämföra två
olika tekniker. Dessutom tar den upp svåra avvägningar mellan kvalitetskrav.
Först en
upprabblingsdel, men sedan kommer bra saker: värdering av varför de är
viktiga och krav på exempel. De exempel ni angett i bedömningsmallen är bra
och uttryckta på ett mätbart sätt i linje ed vad Lauesen rekommenderar.
Bra fråga som
tar ett helhetsgrepp och kräver att man sätter in en teknik i sitt sammanhang.
Bra svar och rimlig bedömningsmall.
Bra att frågan
kräver förklaring och exempel snarare än upprabbling. Dock hade den varit ännu
intressantare om de två olika uppsättningarna faktorer hade jämförts på något
sätt – de är ju uppenbarligen relaterade. Mallen och svaren bra.
Bra fråga! Kräver
förståelse och att man kan förklara, motivera och ge exempel. Den är dock
ganska svår för 10 poäng, och jag tror att sista delen av fråga b) kan vara
svår för tentanden att lista ut vad frågeställaren är ute efter.
I grunden en
upprabblingsfråga. QFD är väl inte det mest centrala i kursen och de problem
som finns med QFD inom kravhantering för programvara är bara delvis belysta.
Bra fråga som
kräver att man värderar för och nackdelar. Poängsättningen är dock inte
helt entydig. Jag tror dock att den är ganska svår att både besvara och att
bedöma. Man kan också undra om företaget ni beskriver verkligen ska satsa på
pilotexperiment före något annat – pilotexperiment ger ju inte information
om kraven förrän man har en i stort sett färdig produkt.
Bra fråga! Kräver
att man förstår syftet med eliciteringsteknikerna och kan koppla till
problemen de försöker lösa. Bedömningsmallen är bra – dock är
exempelsvaren på fråga a) svårbedömda och de exempel som ges i svaret är
ganska abstrakta.
Upprabblingsfråga
som iofs är relevant och bra kunskap att ha men jag vill att en tenta frågar
är på en lite mer avancerad nivå.
Upprabblingsfråga.
Saknar litteraturhänvisning. Själva frågan är märkligt formluerad – vadå
”… ny krav till.”? Har missat att reda ut skillnaden mellan krav och
defekt.
Bra fråga som
kräver att man kan ange fördelar. I ert svar dock så svarar ni på mer än
vad som frågats efter. Varför inte fråga efter nackdelar också?
Mycket bra fråga.
Kräver att man jämför och att man har koll på för och nackdelar, dessutom
kräver exempel på ett rimligt sätt. Mycket bra svar och bra bedömningsmall.
Bra fråga som
kräver insikt i olika prioriteringsteknikers för och nackdelar. Eliciteringsfrågan
är ganska svår men relevant och kräver värderingsförmåga. Orginellt att fråga
efter tekniker som passar dåligt i ett visst sammanhang. Dock kan den nog bli
lite svårbedömd.
Bra fråga
eftersom det finns en koppling mellan tekniker, projektets faser och
eliciteringsbarriärer somkräver att man har satt samman olika delar av teorin.
Mallen är bra även om det blir ganska svårt att bedöma svaren, men så är
det ju med öppna frågor.
En intressant
fråga som gäller labb 2. Kräver insikt och resonemangsförmåga. Dock är det
en hel del subjektiva bedömningar inblandade så den blir ju ganska svårbedömd.
I grunden en
upprabblingsfråga, tyvärr. Dock efterfrågas exempel vilket är bra. Man hade
kunnat göra mycket roligare frågor kring detta som hade krävt att man kunnat
värdera och jämföra tekniker, samt använda CRUD-matrisen istf att
bara rabbla upp vad C R U D står för. Dessutom finns det många fler än 5
tekniker för validering…
I huvudsak en
upprabblingsfråga. Riskfrågan är dock bra då svaren ju är på exempelnivå.
Kvalitetsattributen är viktiga att kunna. (Konstighet med fråga a): Ett par sätt
= 2 st – hur ska man då kunna beskriva tre.)
Fråga som ber
om upprabbling av kvalitetsattribut och vad man kan göra för att verifiera
dessa. Dock har ni inte svarat på hur de kan verifieras utan svarat hur man kan
undvika problem (vilket iofs är viktigt). Ni har ej heller svarat fullständigt
på er fråga eftersom svaret bara innehåller två exempel.
Mycket bra fråga
som kräver att man kan jämföra risker för kund och risker för leverantör
samt genom exempel ange vad man kan göra för att miska risker. Bra svar och
entydig mall.
Bra fråga
genom att man får med exempel visa att man förstått varför kvalitetsattribut
kan vara dåligt uppfyllda. (Ett litet minus är att frågan ej ger 10p vilket
var ett tydligt och mätbart krav på tentaproblemet)
En avancerad
och omfattande fråga som kräver förståelse för för- och nackdelar samt förmåga
att ge exempel och sätta in tekniker i sitt sammanhang. Ni har dock missat att
ordet ”simulering” har flera betydelser (jmf föreläsning
6). Förvirrande med två d)-delfrågor, samt att ett svar är ”insprängt”
i andra frågor. I svaret har ni missat en viktig poäng med pilot-test: att de
bör göras när införandekostnaden vida överstiger implementationskostnaden
och man kan tänka sig att bygga om systemet baserat på det man upptäcker i
pilottesterna, så länge man inte riskerar höga kostnader i införandet av ett
system som ej är tillräckligt bra.
Fråga som
mest är baserad på att kunna rapa upp minneskunskaper. Frågorna kring vilket
stadium kravspecifikationen måste befinna sig i och vem som kan utföra
valideringen är lite mer intressanta. NI har dock ej själva svarat fullständigt
på er egen fråga, vilket är ett krav.