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.
Allmänt:
+Koppling till inlärningsmål, tydliga bedömningsmallar, ambitiöst
- Saknar motivering till varför ett visst svar är rätt på de få ställen där det är tveksamt
- Slagsida mot inlärningsmål 3
1. Tekniker för funktionella krav
Bra sätt att kolla förståelse för när en viss teknik passar bra. "Identifiera funktioner" kan vara vilseledande och föra tankarna till eliciteringstekniker. Visst borde 7:an kunna användas för att beskriva in- och utdata till funktioner – feature requirements är flexibelt användbara textuella beskrivningar.
2. Eliciteringstekniker
Känns lite krystad och tveksam. Exempel på tveksamhet: Det ni beskriver liknar "dold kunskap" och enl ACRE så passar observation, protokoll, etnografi bäst för detta men det stämmer inte med era "rätta" svar. Skriv ut RAD – tråkigt om man glömt vad det betyder.
3. Tekniker för funktionella krav
Bra att testa projekttyp vs stil. Att kräva att skilja mellan datakrav resp funktionella krav är olyckligt då man ofta menar att datakrav är en sorts funktionella krav. I b) så är väl påstående 2 snarare FEL eftersom virtuella fönster INTE är tänkta för att specificera användargränssnitt. I c) är F och E är omkastade – källa till misstag som kan förvirra tentanden.
4. Teknik för funktionella krav
Känns lite väl enkel – spänn bågen högre. Mycket plats för 0,5 p
8. Projekttyper
Viktigt område. Men lurigt att en delfråga ska ha två svar och en ska ha noll. Detta måste förklaras annars stupar tentanden på denna formsak.
9. Abstraktionsnivåer
Bra.
Allmänt:
+ Bra frågetyper. Ibland bra motiveringar till varför rätt eller fel.
- Koppling till inlärningsmål ibland tveksam. Ibland tonvikt på detaljer snarare än viktiga principer.
1. Teknik för datakrav
Känns inte superviktig, speciellt med tanke på att det finns många varianter på kardinalitetsnotation. Tveksam koppling till inlärningsmål; detta är väl snarare specificering an elicitering.
2. Teknik för datakrav
Bra frågetyp. Några småsaker: "data modellen" -> datamodellen, "sända omkring objekt" ??? konstigt uttryck, krystat svarsalternativ
3. Teknik för datakrav
Bra. "I" -> i
4. Tekniker för funktionella krav
"Skärm bilder" -> Skärmbilder. Är D en förhoppning eller varför är det fel? Varför är E rätt? Frågan verkar inte testa mål 3 utan snarare mål 12.
5. Tekniker för funktionella krav
Tveksamt om man kan vara säker på att ordningen är exakt såhär. Varför är B svårare än D? Gäller snarare mål 13.
6. Tekniker för datakrav, klassdiagram
Kardinalitet igen !? Känns inte superviktigt. Dessutom fokus på funktionella detaljer som inte är det mest centra i kursen.
7. Tekniker för datakrav, klassdiagram
Känns inte superviktigt. Dessutom fokus på funktionella detaljer som inte är det mest centra i kursen.
8. Eliciteringstekniker
Bra. Bra motiveringar. 8.4 "Prioritering" -> Prioriteter, ´"Kontnad" –> kostnad
9. Eliciteringstekniker
9.1 är bra men 9.2 kan ev. diskuteras. Är utbildningsbehov alltid lättare att sätta pris på än IT-flexibilitet?
Allmänt
+ Bra frågetyper. Bra motiveringar kring varför rätt/fel.
- Några frågor är inte helt relevanta.
1. Focal Point
Är tveksam till att rätt ordning är avgörande för poängen när det handlar om iterering mellan aktiviteter. Dessutom känns det inte helt schysst att testa om man beskriver Focal Point på "rätt" sätt. Metoden har utvecklats över tiden och innehåller idag fler moment. Känns som en inte jätteviktig minneskontrollfråga.
2. Produktledning
En del bra frågor. Språkslarvigheter här och där. Är inte även icke marknadsdriven kravhantering problematisk? Hur kan lönsamhet förklara hjälpsamhet?
3. Eliciteringstekniker
Mycket bra men svår fråga. Spelar ordningen roll för poängen? Är inte prototyper bra för att föreställa sig nya sätt att utföra uppgifter?
4. Tekniker för funktionella krav
Bra frågetyp för att testa
fördelar med tekniker. Den andra delfrågan känns ngt krystad i formuleringen.
Varför passar E på sista? "Lätt att ta till sig"??
Påstående "inte håller"??? obegripligt
Allmänt
+En del bra frågetyper och frågor.
-Motivering och sakfel.
1. Tekniker för datakrav
Koppling till fel inlärningsmål. Mål 9 handlar om labb 2. Borde snarare vara mål 12, 15, 16. Lite lurigt att säga ngt som är sant men lägga till en grej som är falskt. Då blir det ju delvis sant… 1:6 är FEL; VW handlar inte om att validera design!!
2. Funktionella detaljer
Oklart vad "utvecklingsorienterad" betyder. Ngt krystade svarsalternativ. Ni har valt en teknik ur kapitlet funktionella detaljer, vilket minskar chansen att denna kommer med på tentan… Bra ide till frågetyp dock.
3. Kravklassificering
a) "applikation" ->
appendix?? "komma-separeradfiler" -> "komma-separerad
fil"
Olyckligt att ni har oklara klassificeringsalternativ, tex "specifikt
syfte" som är ganska vagt. Känns inte viktigt att kunna klassificera krav
som "extern rapport"?
4. Kvalitetskrav
Bra frågetyp. Hur poängsätts denna uppgift? (B är egentligen ingen kvalitetsfaktor utan en nivåindelning av kvalitetsfaktorer med fokus på huvudsaklig typ av användning, men det är väl ok för det passar ju bäst som alternativ till 5.)
5. Eliciteringstekniker
Bra frågetyp och bra fråga. "Syften" är lite missvisande. Det handlar mer om till vad teknikerna är lämpliga. Varför har ni bara valt en ihopparning? Det är ju kanske flera möjligheter som är rätt?
6. Tekniker och deras nackdelar
Bra frågetyp och bra fråga! Testar värdering av tekniker!
Allmänt
+I grunden bra idéer till frågor.
-Lite väl låg ambitionsnivå vad gäller omfattningen. Lite dålig täckning av stoffet. Har ej följt riktlinjerna om att det ska vara lätträttat och inte efterfråga fritextsvar.
1. Kravklassificering
Bra fråga. Dock är b) ganska svår eftersom det finns så många alternativa klassificeringar. Vore bättre om alternativen var förutbestämda eller om ni hade en mer utförlig bedömningsmall som även tog med t.ex. efficiency.
2. Kravkvalitet
Kraver fritextsvar. Dock bra fråga. Vore kanske intressant att även ta upp fördelar med kraven jämfört med att de helt saknades jmf tex R1 som ju kanske indikerar en prioritering bland kvalitetsattribut?
3. Kravkvalitet
Innovativ fråga. Kanske är inte alternativen klockrena men bra frågetyp och första gången jag ser en fråga som behandlar denna viktiga sak på detta sätt.
4. Omskrivning av krav.
Ej lätträttad.
Allmänt:
+Bra och innovativa frågetyper.
-Tveksamheter och sakfel i svaren
1.Projekttyper vs livscykeln
Bra att koppla ihop dessa saker. Men kunden brukar väl vara med på acceptanstester? Om jag inkluderar 5) i svaret så får jag dessutom 0 poäng för ett enda "fel" som egentligen är rätt. AARGH
1 (igen). Marknadsstrategier
OK. Minnestestkaraktär men iofs på en viktig sak så denna skulle kunna passa bra på en tenta.
2. Projekttyper
Svaren till a) och c) känns tveksamma. Skulle inte ett företag som är inblandad i kontraktsdriven utveckling kunna ha konkurrenter? Jo! Jämför inte kunderna på en marknad flera erbjudanden? Jo! Jämförs inte flera erbjudanden i en upphandlingssituation? Jo! Det är ngt som är grundläggande problematiskt med formuleringen av frågan. Samma företag kan ju ha många olika typer av projekt…
4. Validering
Hyfsad fråga, men är det viktiga att man vet om t.ex. förklaringskoll är struktur eller innehåll? Det viktiga är väl att veta vad man borde kolla och det testas inte riktigt av denna fråga…
5. Begrepp
Kul och nyskapande med korsord!! Men hör detta hemma på en tenta? Vilken urskiljning har vi lyckas med om tentanden inte klurat ut ett visst ord? Testar vi språkfärdigheter och knep-o-knåp-vana snarare än kravhanteringskunskaper?
Allmänt:
+Bra frågor på viktiga saker.
-Enstaka tveksamheter.
1.Kravkvalitet
Tveksamt med såhär "fyrkantig" syn på kravkvalitet och inte så genomtänkt. "Komplett" är egentligen omöjligt att uppnå i praktiken. Då är det kanske viktigare att satsa på realismen i kraven (uppnåbarhet). "Tillgänglighet" kan väl visst vara bra om man nu med det menar att intressenterna får tillgång till kraven eller kravförslagen. "Kvantitativ" är väl visst bra om man med det menar att kvalitetskraven är kvantifierade på ett sätt som underlättar verifierbarhet…
2. Validering
Frågan testar bara om man kommer ihåg vad CRUD betyder. Minns man inte det är det kört… Minnesregler är ju bra att ha men kanske hade frågan kunna at fokusera på vad man ska kolla snarare än vad CRUD betyder…
3. Validering
Bra fråga! Men varför är det fel att använda task&support? Borde inte detta kunna hjälpa till att minska riskerna om det förtydligar vad som förväntas av kunden?
4. Kvalitetskrav
Bra!
5. Kvalitetskrav
Minnesfråga men på viktiga begrepp som man bör kunna. (Vore dock bra om även svenska termen fanns med.)
6. Spårning, validering
Bra! "konsekvens koll"-> konsekvenskoll, eller ännu hellre "kontroll av (intern) överensstämmelse". "Review" borde översättas till granskning.
7. Verktyg
Bra. Man borde dock förtydliga att det gäller befintliga verktyg
8. Kvalitetskrav
Bra. Kanske vore bra om man även testade koppling till vilken typ av kvalitetskrav det gällde.
Allmänt:
+Bra frågor och mycket att tänka på.
-Enstaka missar och lite slarvigt språk här och där.
1. Kravkvalitet
Testar viktig koppling mellan kravkvalitet och tekniker! Ett problem med frågan är att B faktiskt är rätt på alla om man tänker att om man inte hade gjort teknik x så hade man hittat färre krav… Jag tror rent allmänt att många tekniker täcker många kravkvalitetsaspekter så det kanske inte är så intressant ändå att testa detta såhär. Vore nog bättre med frågetypen påstående-anldening här för att kolla att man förstått anledningarna som ni har i rättningsmallen…
2. Diverse
Oftast mkt bra andemeningar! Dock vissa formuleringsproblem. Många viktiga eftertankar krävs. Ibland svårt att hävda att andra varianter inte är korrekta. Exempel: Vad utvecklarna anser (ofta/sällan)) kan väl vara sant/falskt oberoende av huruvida kraven är korrekta eller inte? Språkproblem som gör det svårare att läsa. Exempel: "Huvud anledning" -> huvudanledning. "tidigra"? "anbuds förfarande" -> anbudsförfarande
3. Kvalitetskrav
Ok, minnestest men viktiga begrepp att kunna. Jag vill även se svenska termer!
4. Kvalitetskrav
Bra. Detaljerad fråga på användbarhet. Innovativ! Kopplar ihop flera delar i teorin! Dock svår, men en tenta ska ju ha några svåra frågor också för att skilja ut de högsta betygen… Lite lurigt att riskbilderna bara ska kopplas till vissa krav – varför är det så? (Kalle har föresten precis förstått hur man bäst fixar tentan – undrar om han är bra på att konstruera tentor också… :-)
Allmänt:
+Viktiga områden.
-Lite väl tunt och ngt låg ambitionsnivå. Dessutom vissa tveksamheter. Sammantaget med D1 täcks inte inlärningsmålen brett.
1. Validering
Viktigt område. Men är kanske inte det viktigaste att testa om man exakt minns hur Lauesens checklista är organiserad. Kanske viktigare att testa vad man bör kolla.
2. Projekttyper
Bra frågetyp och viktigt område (som vi dock har MÅNGA frågor på redan). Vissa problem med facit. Exempel: Om man utvecklar en produkt finns väl kunden oftast utanför företaget på en marknad?
Allmänt:
+ Bra fråga på datakrav.
-Om man lägger samman inlämning E1 är det totalt sett är det allt för tunt vad gäller täckningen av inlärningsmålen. Lite för låg ambitionsnivå för högre bonus.
1. Funktionella krav
Bra försök men tveksam rättningsmall. Även ett användningsfall bör vara sammanhållet och måluppfyllande och 2:an känns mer som en händelse i ett anvädnningsfall (som utförs av systemet) än ett sammanhållet måluppfyllande användningsfall. Svårt att testa sådant här med alternativ ryckta ur sitt tönkta sammanhang.
2. Datakrav
Bra. (Småsak: Hade velat ha svenska termer för teknikerna.)