Göm menyn

TDDD80 Projekt: Mobila och sociala applikationer

Projekt-examination


Förutom muntlig redovisning, sker betygsättning enligt ett antal grundkrav, samt ett poängbaserat system för graderade betyg. Tanken är att ni ska kunna planera för ett visst betyg redan från början genom att välja att implementera poänggivande funktioner i er app. Har ni egna förslag på möjliga poänggivande funktioner eller tekniska finesser, är ni välkomna att kontakta kursledningen.

Muntlig slutredovisning

Mot slutet av kursen ska systemet redovisas, dvs. demas muntligt. Var och en av er ska vara beredd att:

  • Berätta om systemets syfte och målgrupp. Vilket problem löser systemet och på vilket sätt?
  • Demonstrera hur appen fungerar genom att visa typiska användningsfall, med fokus på de poänggivande krav som ni anser er ha uppfyllt.
  • Demonstrera koden samt redovisa coverage för enhetstestning.
  • Svara på frågor kring design, genomförande, och detaljer kring implementationen av appen.

Grundkrav

  • Allmänt: Appen ska ha en specifik målgrupp och lösa ett äkta problem på ett professionellt sätt. Detta innebär bl.a. att appen ska ha en viss komplexitet, både vad gäller utformning (GUI) och teknik (kod).
    • GUI komplexitet: Appen ska ha minst fyra skärmar, login- och kontoregistrerings-skärmar inte medräknade, där användaren kan interagera med appen (en skärm som visar en textsnutt eller en bild är alltså inte medräknade här).
    • Kodkvalitet: Koden ska vara välstrukturerad, välkommenterad och allmänt lättläst. Vid inlämning ska en .readme fil medfölja, med tydliga anvisningar för hur systemet ska byggas. Alla nödvändiga libraries etc ska inkluderas i inlämningen.
  • Socialt: Minst 3p sociala funktioner (se poängsystemet nedan). Systemets sociala funktioner ska implementeras från grunden. (För övriga funktioner såsom inloggning etc. kan valda API:er användas.)
  • Testning: Coverage för enhetstestning ska vara minst 40%. Du väljer själv om du gör det för server-koden eller för klient-koden (mobila-delen); du behöver inte göra det för bägge kodbaserna. (Generellt är det lättare att testa och mäta coverage på server-sidan.)
  • Användbarhet: Appen (i slutgiltigt skick) ska användbarhetstestas med 5 användare som är representativa för målgruppen. De användbarhetsmått som ska användas är uppgiftsframgång, användbarhetsproblem, samt SUS. Deltagarna ska utföra minst 4 icke-triviala uppgifter. Testets utförande och resultat ska redovisas i en välskriven rapport om max 4 A4-sidor som lämnas in till din labbassistent i PDF-format via e-post. All information som behövs för att genomföra uppgiften presenteras på föreläsningen om utvärderingsmetoder.

Betygsnivåer

Betyg 3: minst 6p (inkl. 3p sociala funktioner)

Betyg 4: minst 8p (inkl. 3p sociala funktioner)

Betyg 5: minst 10p (inkl. 3p sociala funktioner)

Poängsystem

  • Arbetsplanering
    1. Server-labbar inlämnade i tid. (1p)
    2. Flutter-labbar inlämnade i tid. (1p)
  • Sociala funktioner
    1. Gilla informationsobjekt (inklusive undo). (1p)
    2. Kommentera informationsobjekt. (1p)
    3. Följa andra användares aktivitet, t.ex. att man ser sina vänners inlägg. (1p)
    4. Hantera vänner (etablering och terminering av en vänskapsrelation, samt visning av vänners status). (1p)
    5. Övriga sociala funktioner (ska godkännas av labbassistent/kursledare). (1p)
  • Användning av sensorer (på ett för systemets syfte och målgrupp naturligt sätt)
    1. Kamera. (1p)
    2. GPS. (1p)
    3. Annan sensor (ska godkännas av labbassistent/kursledare). (1p)
  • Tekniska lösningar
    1. Navigering genom hela appen mha go_router biblioteket (notera att även navbars kan implementeras mha routes). (1 p)
    2. Hantering av rotation, genom att anpassa layout (t.ex. antal komponenter som visas på skärmen, eller deras placering på skärmen). (1 p)
    3. Användning av provider fullt ut i hela appen för att hantera uppdatering av innehåll som visas i appen. (1 p)
      • Optimering av hur innehåll uppdateras i widget-trädet, genom att injicera innehåll på rätt nivå i widget-trädet. (1 p)
    4. Modulär kod enligt Repository designmönstret för att hantera data och nätverksanrop. (2 p)
    5. Tredjeparts-inloggning, t.ex. Google Sign-in (1 p)
    6. Geofencing (1 p)
    7. Språkanpassning till minst ett annat språk än appens default. (1 p)
    8. Light vs. dark mode, som t.ex. anpassas efter systeminställningar. (1 p)
    9. Anpassning till äldre användare, genomgående i appen, genom t.ex. ökad fontstorlek (1 p), eller ökad kontrast (1 p).
    10. Widget-testning av minst två skärmar. (1 p)
    11. Flutter unit-testning med minst 40% coverage. (1 p)
  • Användbarhet
    1. Rapporten om användbarhetstestet utökas med en tabell som innehåller en uppdelning av de identifierade användbarhetsproblemen enligt allvarlighetsgrad. Tabellen ska ha fyra kolumner. En kolumn för allvarlighetsgraden (låg, medel, hög), en kolumn för beskrivningen av problemet, en kolumn som beskriver problemets påverkan på användbarupplevelsen, en kolumn som beskriver antalet användare som upplevt problemet. (1p)
    2. Rapporten om användbarhetstestet utökas med 1 A4-sidas beskrivning och motivering av åtgärdsförslag för de allvarligaste användbarhetsproblemen som identifierats. OBS: kräver nivå 1 (dvs. att föregående punkt är genomförd). (1p)

Sidansvarig: Rita Kovordanyi
Senast uppdaterad: 2025-04-08