Tentamensproblem 1: Projektmodeller
Fråga 1A
Du har tröttnat på ett visst ordbehandlingsprogram och tycker att det
borde gå att ta fram något bättre. Eftersom du alltid drömt om att bli
rik tänker du göra något du kan sälja till den stora massan
Vilket sorts projekt är det och vilken projektmodell verkar
vara lämplig? Motivera varför den valda modellen är lämplig. (4p)
Fråga 1B
Det finns tre olika Projektmodeller, den traditionella
(krav på produktnivå), den snabba modellen (krav på domännivå) och
tvåstegsmodellen (Både domännivåkrav och designnivåkrav). De olika
modellerna passar olika bra i olika projekt. Nämn en projekttyp som
inte passar bra för varje projekttyp och motivera varför
projekttypen inte passar projektmodellen. (6p) (Konstruktörens
kommentar: Inte vidare värst pedagogisk fråga, men hade lite brist på
tid och fantasi...).
Lösningsförslag
1A
Exempel på svar:
Det är ett produktuvecklingsprojekt (1p).
Framförallt tycker Laursen att man bör använda två-stegsmodellen,
domännivå + designnivå, vid produktutveckling (1p). Metoden är dels
inriktad på att beskriva olika användaruppgifter (tasks), men att man
även tar med designnivåkrav för att beskriva komplexa delar av
gränssnittet. (2p om man får med båda. Hälften ger 1p). Totalt 4p
Man skulle även kunna tänka sig att använda
den traditionella modellen, produktkrav. Man inriktar sig här på att
ta fram funktionskrav. Eftersom man främst inriktar sig på
programmets funktioner och inte på vad användaren egentligen ska
utföra riskerar man att missa viktig funktionalitet. Väljer man det
här svarsalternativet kan man max få 3 poäng.
Man får skriva en väldigt bra motivering om man ska få poäng för Fast approach...
1B
Two-step: I den "vanliga" typen av COTS-projekt (affärs eller
färdiga verktyg) passar inte tvåstegsmodellen så bra (1p) eftersom
gränssnitten i dessa projekt redan är färdigutvecklade (1p) och det är
ganska meningslöst att försöka ta fram nya gränssnitt. Totalt
2p
Man kan även nämna underhåll av befintlig produkt (1p), eftersom
såväl gränssnitt som affärsmål och större delen av domänkraven redan
ska vara färdiga och kartlagda(1p). Totalt 2p
Traditional: Här finns det ganska många frågetecken i fig
1.7B, s.33 i Laursen. Så länge man inte nämner COTS verktyg,
underleverantörskontrakt eller underhåll av befintligt system får man
0.5 poäng för projekttypen. Sedan bör man nämna två av nackdelarna
nedan i sin motivering för full poäng (2p). Nackdelarna är:
Det är tidskrävande.
Eftersom det främst är funktionella krav kan det vara svårt att
försäkra sig om att man uppfyller affärsmålen eller att man stöder
alla uppgifter systemet ska klara av.
Funktionella krav kan vara svårlästa för kunden. Om nu kunden
skulle kunna läsa kraven finns det trots detta risk att det inte går
att avgöra om det är riktiga och rimliga krav.
Om man låter Intressenterna att lämna in krav brukar de komma med
långa önskelistor där det sedan kan vara svårt att prioritera rätt
krav.
Får man bara med en av nackdelarna ger svaret endast 1
poäng. Totalt 2p
Fast-approach: Produktutvecklingsprojekt (1p)är inte så lämpliga,
eftersom man bör designa och utvärdera användargränssnittet. (1p) Det görs
inte enligt den här modellen eftersom man inte tar med några
funktionella krav.
Underleverantörskontrakt (1p) för delar av tekniska system passar inte
så bra eftersom alla domännivåkrav redan bör vara framtagna (1p)
Underhåll av befintliga system (1p) med motivering som
ovan(1p).
COTS-projekt där man vill införskaffa utvecklingsverktyg eller
tekniska komponenter (COTS tools... 1p) är inte heller lämpligt med
samma motivering som för de två ovanstående projekttyperna (1p).
Totalt 2p