Projektēšana // un Plānošana
Kā pārvērst ideju par darbojoties programmu? Apgūsti user stories,
datu modeļus un unittest - profesionāla izstrādātāja darba
process no prasībām līdz prezentācijai.
Tēmas saturs - 6 stundas
No problēmas formulēšanas līdz projektējuma aizstāvēšanai - pilns izstrādes cikls.
Problēmas formulēšana un automatizācija
Kā formulēt problēmu un pārvērst manuālu procesu efektīvā programmā.
Prasību specifikācija (User Stories)
"Kā [loma], es gribu [darbība], lai [mērķis]" - prasību apraksts, ko saprot visi.
Datu modelis un UI plūsma
Klašu un attiecību diagramma + lietotāja saskarnes plūsmas skice README.md failā vai diagrammu rīkā.
Prezentācijas māksla (Pitch)
Kā prezentēt projektu - slide struktūra, koda demonstrācija un pārliecinošs pitch.
Sasniedzamie rezultāti un resursu plānošana
Projekta laika josla - uzdevumi, virstēmas un progresa procenti Gantt formātā.
Noslēguma projekts: Projektējuma aizstāvēšana
Prezentē skolēnu vērtēšanas sistēmu - kods, testi, pitch un atbildes uz jautājumiem.
8. tēmas špikeris - projektēšana un plānošana
Problēmas formulēšana, prasības, datu modelis, prezentācija un plāns. Šajā tēmā kodu neraksta - te top dokumenti.
8.1 Problēmas formulējums
## Vājš formulējums (tā raksta lielākā daļa)
Spēli ir grūti papildināt un tas aizņem daudz laika.
Kas nav labi:
- "grūti" un "daudz" nav skaitļi - to nevar pārbaudīt
- nav pateikts, KAS tieši ir grūti
- nav skaidrs, kad problēma būtu atrisināta
## Spēcīgs formulējums
Katras jaunas lokācijas pievienošana prasa labot 20 Python funkcijas un
aizņem ~40 minūtes. Nedēļā pievienoju 3 lokācijas, tātad 2 stundas nedēļā
aiziet kopēšanai, un 4 no 10 reizēm rodas kļūda nepareiza ID dēļ.
Kas ir labi:
- skaitļi: 20 funkcijas, 40 min, 2 h, 4 no 10
- konkrēta darbība: lokācijas pievienošana
- NAV minēts risinājums - tikai problēmaRisinājumu ("uztaisīšu CSV") šeit nerakstām. Vispirms problēma, tikai tad risinājums.
8.2 Lietotāju stāsti un akceptēšanas kritēriji
## User Story
Kā [lietotājs], es vēlos [darbība], lai [ieguvums].
Kā spēlētājs, es vēlos redzēt savu inventāru,
lai zinātu, kādus priekšmetus esmu savācis.
## Akceptēšanas kritēriji - PĀRBAUDĀMI
- [ ] Nospiežot "i", parādās saraksts ar visiem priekšmetiem
- [ ] Tukšs inventārs rāda "Inventārs ir tukšs", nevis kļūdu
- [ ] Katram priekšmetam redzams nosaukums un skaits
-> uz katru var atbildēt tikai JĀ vai NĒ
## NEPĀRBAUDĀMI - tā nevajag
- [ ] Inventārs izskatās labi <- kā izmērīt?
- [ ] Inventārs strādā ātri <- cik ātri?
## Prioritāte
M = obligāts , V = vēlams , apjoms 1-5
Sāc ar to, kas ir M un ar mazāko apjomu.Ja kritēriju nevar pārbaudīt ar jā/nē, tas noved pie strīda par to, vai darbs ir gatavs.
8.3 Datu modelis un UI plūsma
ER diagramma - kādi dati sistēmā vispār ir
┌───────────────┐ ┌──────────────┐
│ Spēlētājs │ atrodas │ Lokācija │
├───────────────┤───────────►├──────────────┤
│ id (atslēga) │ │ id (atslēga) │
│ vards │ │ teksts │
│ hp │ │ izvele_a │
└───────────────┘ └──────────────┘
UI plūsma - pa kādiem ekrāniem lietotājs staigā
[Sākums] --nospiež Sākt--> [Spēle] --uzvar--> [Rezultāts]
▲ │
└───────────── Spēlēt vēlreiz ─────────────────┘
Pārbaude:
- vai katram ER atribūtam ir ekrāns, kur to redz?
- vai no katra ekrāna var tikt PROM? (nav strupceļu)Zīmē abas diagrammas kopā - tikai tā pamanīsi datus, ko neviens ekrāns nerāda.
8.4 Pitch struktūra
Lifta runa - 45-60 sekundes, 4-5 teikumi:
1. Āķis - kas piesaista uzmanību
2. Problēma - no 8.1 formulējuma, ar skaitli
3. Risinājums- ko tu būvē
4. Ieguvums - kas mainīsies lietotājam
Slaidu plāns - 5 slaidi, katram VIENA doma:
1. Āķis 2. Problēma 3. Risinājums
4. Demo 5. Nākamie soļi
Likumi:
- ne vairāk par 20 vārdiem uz slaida
- visi 5 slaidi kopā < 100 vārdi
- iztestē ar taimeri UN ar klasesbiedru
- sagatavo atbildes uz 3 jautājumiem, tostarp par riskuJa klasesbiedrs pēc runas nesaprot, ko tu būvē, vaina ir runā, nevis klausītājā.
8.5-8.6 Plāns, resursi un aizstāvēšana
## Starprezultāti
1. Datu ielādes modulis - gatavs, kad CSV ielādējas bez kļūdām
2. Spēles navigācijas cikls - gatavs, kad var pāriet starp 3 lokācijām
3. Rezultātu saglabāšana - gatavs, kad rezultāts paliek pēc restarta
-> katram pabeigtību var pārbaudīt ar JĀ/NĒ
## Resursi
- Tehniskie: Python 3.12, csv, json, VS Code
- Informatīvie: dokumentācija, 6. tēmas koda paraugi
- Laiks: 3 h nedēļā
- * TRŪKST: piekļuve skolas serverim -> prasīšu skolotājam
## Riski
| Risks | Plāns B |
|---|---|
| CSV eksports sabojā garumzīmes | saglabāt UTF-8, pārbaudīt uzreiz |
| Nepaspēju 3. posmu | iesniedzu ar 2 posmiem, 3. kā papildu |
## Definition of Done
- [ ] Programma palaižas bez kļūdām
- [ ] README apraksta palaišanu
- [ ] Iztestēts ar tukšu un bojātu ievadiAizstāvēšanā katrai tehniskai izvēlei jābūt pamatojumam, kas atsaucas uz prasību - nevis "tā bija vieglāk".