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