8.6 Noslēguma projekts: Projektējuma aizstāvēšana

Stundas uzdevums: Aizstāvēt savu "Krustiņi un nullītes" spēles arhitektūras projektu klases priekšā. Pamatot savas izvēles, parādīt shēmas un pārliecināt auditoriju, ka Tavs plānotais izstrādes ceļš ir efektīvs un izpildāms.

SR 2.4.6. Plāno un dokumentē izstrādes procesu SR 2.4.7. Lietotāja saskarne un lietojamība SR 2.4.1. Problēmas dekompozīcija SR 2.4.3. Programmatūras prototipēšana un testēšana

70 min plāns: Ievads un kritēriju pārruna (~10 min) · 1. uzdevums (~15 min) - savāc projektējuma mapi kopā · 2. uzdevums (~25 min) - sasaisti prasību ar tehnisku izvēli · 3. uzdevums (~20 min) - aizstāvi projektējumu un pieraksti piezīmes. Papildu uzdevumu sāc tikai tad, ja pārējie trīs ir gatavi.

Pirms sāc: šis ir 8. tēmas noslēgums. Jaunas funkcijas nav jāprogrammē - jāparāda, ka prasības, datu modelis, UI plūsma un grafiks saskan savā starpā.

Teorija: aizstāvēšana pierāda, ka plāns ir izpildāms

Projektējuma aizstāvēšanā nav jāprogrammē jaunas funkcijas. Tev jāparāda, ka prasības, datu modelis, UI plūsma un izstrādes ceļš saskan. Labs arguments sasaista konkrētu lietotāja vajadzību ar konkrētu tehnisku izvēli.

## User Story
Kā spēlētājs es vēlos redzēt uzvarētāju,
lai saprastu, kad partija ir beigusies.

## Akceptēšanas kritērijs
- Pēc trīs vienādām zīmēm rindā tiek parādīts uzvarētājs.

Šāds fragments sasaista prasību ar pārbaudāmu rezultātu.

Praktiskie uzdevumi

1. uzdevums -

Savāc projektējuma mapi kopā

Beigās viss tavs plāns būs vienuviet un atverams vienā klikšķī.

Izveido krātuvē mapi projektejums.
Pārvieto tajā PRASIBAS.md un ROADMAP.md.
Pievieno ER diagrammas un UI plūsmas attēlus.
Izveido failu README.md ar saitēm uz visiem dokumentiem.
Pārbaudi, vai katra saite tiešām atveras.
Veic commit un push.

Gatavs, kad: GitHub mapē projektejums ir visi četri dokumenti, un README saites strādā.

2. uzdevums -

Sasaisti prasību ar tehnisku izvēli

Beigās katrai tehniskai izvēlei būs iemesls, nevis gaume.

Izveido tabulu ar kolonnām: lietotāja stāsts, tehniskā izvēle, pamatojums.
Ieraksti tabulā vismaz trīs rindas.
Pieraksti katrai, kāpēc tieši šī datu struktūra vai fails, nevis cita.
Iekļauj vismaz vienu izvēli, kas balstīta 7. tēmas efektivitātes secinājumos.
Pārbaudi, vai neviens pamatojums nav tā bija vieglāk.
Pārraksti vājāko pamatojumu.
Pievieno tabulu README.md failam.

Gatavs, kad: tabulā katrai rindai ir pamatojums, kas atsaucas uz konkrētu prasību vai efektivitāti.

3. uzdevums -

Aizstāvi projektējumu un pieraksti piezīmes

Beigās tu būsi izstāstījis plānu un uzzinājis tā vājo vietu.

Izstāsti projektējumu klasesbiedram vai skolotājam 3 minūtēs.
Parādi secībā: problēma, prasības, datu modelis, grafiks.
Pieraksti katru uzdoto jautājumu.
Pieraksti, uz kuru jautājumu tev nebija atbildes.
Papildini dokumentus, lai šī atbilde tajos parādītos.
Veic commit ar ziņu Papildina projektejumu pec aizstavesanas.
Iesniedz krātuves saiti skolotājam.

Gatavs, kad: tavos dokumentos ir atbilde uz to jautājumu, uz kuru aizstāvēšanas laikā nevarēji atbildēt.

Papildu uzdevums - Novērtē klasesbiedra projektējumu

Ja pamatdarbs ir gatavs, pārbaudi kāda cita plānu pēc tiem pašiem kritērijiem.

Saņem klasesbiedra projektējuma saiti.
Pārbaudi, vai katram lietotāja stāstam ir akceptēšanas kritēriji.
Pārbaudi, vai ER diagramma sasaucas ar UI plūsmu.
Pieraksti vienu stiprāko pusi un vienu ieteikumu.
Nosūti savas piezīmes autoram.

Gatavs, kad: tavas piezīmes nosauc vienu konkrētu stiprumu un vienu konkrētu uzlabojumu.

Biežākās kļūdas (un kā tās labot)

Prezentācija apraksta tikai ekrānus: piesaisti katru ekrānu lietotāja stāstam vai datu modelim.
Roadmap ir pārāk optimistisks: sadali darbu mazākos starpmērķos, ko var pārbaudīt.
Diagrammas nav salasāmas: palielini tekstu un izņem liekas detaļas.
Jautājumos rodas apjukums: sagatavo 2-3 argumentus par galvenajām tehniskajām izvēlēm.

Snieguma līmeņa apraksts (SLA)

Kritēriji	4-6 (Turpina apgūt)	7-8 (Apguvis)	9-10 (Padziļināti)
Tehniskais projektējums	Diagrammas ir nepilnīgas; trūkst loģiskas saiknes starp datiem.	ER un UI diagrammas ir precīzas un atbilst prasībām.	Projektējums ir profesionāls, iekļaujot datu tipus un kļūdu apstrādes loģiku.
Prasību definēšana	Lietotāju stāsti ir virspusēji vai tehniski nepareizi.	Lietotāju stāsti ir skaidri un fokusēti uz vērtību.	Precīzi definēti akceptēšanas kritēriji un prioritizēts Backlog.
Plānošana un Prezentācija	Runa ir haotiska; Roadmap nav reālistisks.	Sniegts pārliecinošs Pitch; Roadmap ir pamatots ar laika aplēsēm.	Spēja argumentēti aizstāvēt arhitektūras izvēles un vadīt jautājumu sesiju.

Prezentācijas kontrolsaraksts

[ ] Vai es skaidri definēju problēmu, ko mans dzinējs risina?
[ ] Vai mana ER diagramma parāda visas nepieciešamās tabulas/vārdnīcas?
[ ] Vai User Stories ir rakstīti no lietotāja skatpunkta?
[ ] Vai mans Roadmap iekļauj vismaz 3 svarīgus starpmērķus?
[ ] Vai esmu gatavs paskaidrot, kāpēc izvēlējos tieši CSV/JSON formātus?

Koda paraugs: Pēdējā pārbaude pirms Pitch


# Pārbaudi, vai Tavs arhitektūras dokumentācijas fails ir kārtībā:
cat PRASIBAS.md
cat ROADMAP.md

# Atceries: Prezentācijā fokusējies uz "KĀPĒC", nevis tikai "KAS".
# "Kāpēc šī vārdnīca ir labāka par sarakstu?"
# "Kāpēc šis starpmērķis ir pirmais?"

Status: Gatavs aizstāvēšanai.
Atceries: Šajā darbā tu esi projekta vadītājs. Pārliecini mūs!