Kapitola 6: Model jako zjednodušení reality (oprava chyb)
Testování modelu - porovnání s realitou
1. Úvod: Když mapa neladí se skutečností
V minulé kapitole jsme se naučili, že modely jsou jako zjednodušené mapy, které nám pomáhají se zorientovat. Ale co když je v mapě chyba? Co když na mapě chybí most, který ve skutečnosti existuje? Pak se můžeme snadno ztratit nebo jet špatně. V této kapitole se naučíme, jak poznat, že je v modelu chyba, a jak ji opravit.
2. Co je to model? (Opakování)
Pamatuj, že model je zjednodušená verze reality. Ukazuje nám jen to důležité. Ale i v tom zjednodušení musí být model správný, jinak nám nepomůže.
Definice: Model
Model je zjednodušená verze reality, která nám pomáhá lépe pochopit, jak něco funguje, nebo jak vyřešit nějaký problém.
3. Jak poznat chybu v modelu?
Chybu v modelu poznáme tak, že model neodpovídá skutečnosti, nebo nám nepomáhá vyřešit problém tak, jak bychom chtěli.
3.1. Model neodpovídá skutečnosti
To je jako když máš mapu, na které je ulice, která ve skutečnosti neexistuje, nebo naopak chybí.
Příklad: Model rozvrhu hodin
Představ si, že máš nakreslený rozvrh hodin (to je model). Ale v úterý máš podle rozvrhu tělocvik, a ve skutečnosti máš mít matematiku. To je chyba v modelu! Model (rozvrh) neodpovídá realitě (skutečnému průběhu hodin).
3.2. Model nefunguje tak, jak má
Někdy model sice vypadá správně, ale když ho použijeme, nevede k cíli.
Příklad: Model cesty do školy
Nakreslil sis diagram, jak se dostaneš do školy (model). Ale když ho použiješ, zjistíš, že ti trvá cesta 20 minut, i když jsi si myslel, že to bude jen 10 minut. Model ti tedy neukázal správný čas.
4. Jak opravit chybu v modelu?
Když najdeme chybu, musíme ji opravit. Je to jako když si uvědomíš, že v mapě chybí most, a tak si ho tam dokreslíš.
4.1. Porovnání se skutečností
Nejlepší způsob, jak najít chybu, je porovnat model se skutečností.
Příklad: Oprava rozvrhu hodin
Zjistil jsi, že máš v úterý matematiku místo tělocviku. Tak si vezmeš tužku a v rozvrhu (modelu) si tělocvik přepíšeš na matematiku. Tím jsi opravil chybu v modelu.
4.2. Změna modelu, aby lépe fungoval
Někdy model není úplně špatný, ale dá se vylepšit, aby nám lépe sloužil.
Cyklus vylepšování - návrh, tvorba, test, oprava
Příklad: Vylepšení diagramu cesty do školy
Zjistil jsi, že cesta do školy trvá déle. Můžeš si do diagramu přidat nový krok: "Zastavit se pro svačinu". Tím se model stane přesnějším a bude lépe odpovídat tvé realitě.
5. Proč je důležité umět opravovat modely?
Svět se neustále mění. Co platilo včera, nemusí platit dnes. Proto je důležité umět naše modely (plány, rozvrhy, mapy) přizpůsobovat novým informacím.
Přesnost: Opravený model je přesnější a lépe nám pomáhá.
Spolehlivost: Když víme, že náš model je správný, můžeme se na něj spolehnout.
Učení se: Opravováním chyb se učíme a lépe rozumíme světu kolem sebe.
Člověk a digitální svět
V digitálním světě se neustále setkáváme s modely – od map v mobilu po plány budov. Je důležité si uvědomit, že tyto modely jsou vždy zjednodušením reality a mohou obsahovat chyby nebo být neúplné. Schopnost kriticky zhodnotit model, najít v něm nedostatky a navrhnout vylepšení je klíčová pro efektivní práci s digitálními nástroji a pro řešení problémů v reálném světě.
Otázky k zamyšlení
Může být model někdy "dokonalý" a bez chyb? Proč ano, nebo proč ne?
Proč je důležité umět najít chybu v mapě, když cestuješ?
Jak ti pomůže, když si opravíš chybu v plánu, který jsi si udělal?
Úkoly pro praxi
Hledání chyby v rozvrhu: Vezmi si svůj rozvrh hodin (nebo si ho nakresli jako model). Zkus najít alespoň jednu věc, která se v rozvrhu liší od skutečnosti (např. jiná učebna, jiný učitel, jiný předmět). Oprav ji v modelu.
Vylepšení plánu pokoje: Vrať se k plánu svého pokoje z minulé kapitoly. Zkus najít něco, co jsi zapomněl nakreslit, nebo co bys mohl vylepšit, aby byl plán přesnější a užitečnější. Dokresli to.
Model mého dne: Nakresli si jednoduchý diagram (model) svého dne od rána do večera. Zkus ho dodržet. Na konci dne se zamysli, jestli se něco lišilo od tvého plánu. Pokud ano, oprav model tak, aby lépe odpovídal tvému skutečnému dni.
* Rozšíření pro pokročilé
Validace a verifikace modelů
V profesionální praxi rozlišujeme dva důležité pojmy:
Validace: "Stavíme správný produkt?" – Ověření, že model odpovídá požadavkům a realitě.
Verifikace: "Stavíme produkt správně?" – Ověření, že model je interně konzistentní a bez technických chyb.
Iterativní proces vývoje
Modely se obvykle nevytváří najednou, ale iterativně – v opakujících se cyklech:
Plánuj: Rozmysli si, co model má obsahovat.
Vytvoř: Nakresli/napiš první verzi.
Testuj: Porovnej model s realitou, najdi chyby.
Vylepši: Oprav chyby a přidej chybějící části.
Opakuj: Vrať se na krok 2 s lepší verzí.
Techniky hledání chyb
Review (revize): Někdo jiný zkontroluje tvůj model.
Testování: Zkusíš model použít na reálných datech.
Simulace: Model "pustíš" a sleduješ, jak se chová.
Porovnání: Srovnáš svůj model s existujícím řešením.
Životní cyklus vývoje software
* Úkoly pro pokročilé
Word – Dokumentace revize: Vytvoř dokument "Revize modelu". Vlož do něj obrázek svého modelu (např. screenshot diagramu). Pod něj napiš tabulku: sloupec "Nalezená chyba", sloupec "Návrh opravy", sloupec "Stav (opraveno/čeká)".
Excel – Sledování verzí: Vytvoř tabulku pro sledování verzí modelu: Verze (1.0, 1.1, 2.0...), Datum, Popis změn, Autor. Vyplň pro fiktivní projekt.
Peer review: Vyměň si svůj model (diagram, plán) se spolužákem. Najdi 3 věci, které by šly vylepšit v jeho modelu. Napiš mu konstruktivní zpětnou vazbu.
Scratch – Model se zpětnou vazbou: Vytvoř ve Scratchi jednoduchý "model" – např. postavu, která chodí podle tvých instrukcí. Přidej tlačítko "CHYBA", které zastaví postavu a zobrazí zprávu "Model neodpovídá realitě – oprav mě!".
** Rozšíření pro maturitní obory
Podrobně: Metodiky vývoje software
Revize modelů je součástí širších metodik vývoje:
Vodopádový model (Waterfall)
Fáze jdou sekvenčně: Analýza → Návrh → Implementace → Testování → Nasazení.
Každá fáze musí být dokončena před další.
Nevhodný pro projekty s měnícími se požadavky.
Agilní metodiky
Scrum: Práce v "sprintech" (2-4 týdny), denní stand-up meetingy.
Kanban: Vizuální tabule s úkoly (To Do → In Progress → Done).
Důraz na flexibilitu, rychlou zpětnou vazbu, iterace.
Validace: "Stavíme správný produkt?" – odpovídá model požadavkům?
Verifikace: "Stavíme produkt správně?" – je model bez chyb?
Testovací případy: Konkrétní scénáře pro ověření funkčnosti.
Větvení verzí v systému Git
** Úkoly pro maturitní obory
PowerPoint – Metodiky vývoje: Vytvoř prezentaci "Waterfall vs Agile" (10-12 snímků). Porovnej: fáze, flexibilita, dokumentace, typické projekty. Uveď příklady.
Excel – Kanban tabule: Vytvoř v Excelu Kanban tabuli pro školní projekt. Sloupce: Backlog, To Do, In Progress, Testing, Done. Přidej úkoly s barvami podle priority.
Word – Testovací plán: Napiš testovací plán pro jednoduchou aplikaci (kalkulačka). Zahrň: co se testuje, testovací případy (vstup, očekávaný výstup), výsledek testu.
Canva – Plakát Scrum: Vytvoř v Canvě plakát vysvětlující Scrum pro učebnu. Zobraz: role (Product Owner, Scrum Master, Team), artefakty (Backlog, Sprint), ceremonie (Planning, Daily, Review, Retro).
GitHub úvod: Vytvoř si účet na GitHub. Vytvoř nový repozitář "muj-prvni-projekt". Nahraj tam jeden soubor (např. README.md). Napiš shrnutí, co jsi udělal/a.
*** Rozšíření pro IT obory
Jako budoucí IT specialista musíš rozumět životnímu cyklu software a verzování na teoretické úrovni. Tato kapitola rozšiřuje základy bez programování.
Životní cyklus software (SDLC)
SDLC (Software Development Life Cycle) popisuje fáze vývoje software:
Fáze
Aktivity
Výstupy
1. Plánování
Definice cílů, rozpočet, harmonogram
Projektový plán
2. Analýza
Sběr požadavků, studium proveditelnosti
SRS dokument
3. Návrh
Architektura, datový model, UI návrh
Technická dokumentace
4. Implementace
Psaní kódu, unit testy
Zdrojový kód
5. Testování
Funkční, integrační, systémové testy
Test reporty
6. Nasazení
Instalace, konfigurace, školení
Produkční systém
7. Údržba
Opravy chyb, aktualizace, rozšíření
Nové verze
Typy testování
Typ testu
Co testuje
Kdo provádí
Unit test
Jednotlivé funkce/metody
Vývojář
Integrační test
Spolupráce modulů
Vývojář/Tester
Systémový test
Celý systém
QA tým
Akceptační test (UAT)
Splnění požadavků
Zákazník
Regresní test
Že změny nerozbily stávající funkce
Automatizace/Tester
Verzování – teorie
Sémantické verzování (SemVer) je standard pro číslování verzí:
Formát: MAJOR.MINOR.PATCH
Příklad: 2.4.1
• MAJOR (2): Velké změny, nekompatibilní s předchozí verzí
• MINOR (4): Nové funkce, zpětně kompatibilní
• PATCH (1): Opravy chyb, zpětně kompatibilní
Příklady verzí:
1.0.0 → První stabilní verze
1.0.0 → 1.0.1 = Oprava chyby
1.0.1 → 1.1.0 = Nová funkce
1.1.0 → 2.0.0 = Velká změna (breaking change)
Větve (Branches) v Git
Větve umožňují paralelní vývoj:
main/master: Hlavní větev, stabilní produkční kód.
develop: Vývojová větev, integrace nových funkcí.
feature/xxx: Větev pro vývoj konkrétní funkce.
hotfix/xxx: Větev pro rychlou opravu kritické chyby.
release/x.x: Příprava nové verze.
Typický workflow (Git Flow):
1. Vytvoř feature větev z develop
2. Implementuj funkci, commituj změny
3. Vytvoř Pull Request (PR)
4. Code review od kolegy
5. Merge do develop
6. Po testování merge do main a vytvoř tag s verzí
Code Review
Code review je proces kontroly kódu kolegou před jeho začleněním:
