Simulace.info - User contributions [en]

User:Hrus07

2025-06-15T19:52:17Z

Hrus07:

Technický dluh je dnes neodmyslitelnou součástí softwarového vývoje. Vzniká v důsledku různých důvodu (tlak na rychlost dodání, neoptimální řešení, používání zkratek a zanedbání architektury). Tento dluh se časem akumuluje a projevuje se v podobě nárůstu úsilí nutného k úpravám, údržbě ale ovlivňuje i další vývoj. Čím větší dluh, tím větší dopad na produktivitu týmu. Projekt se zpomaluje a dále zvyšuje celkové náklady.

=Definice problému=

Aplikace, o kterou se starám vznikla jako demovací nástroj. S průběhem času se vyvinula do plnohodnotného projektu a její rozšiřování naráží na technologický dluh. Začínáme tedy s již existencí defektů, ke kterému se přidává backlog nových funkcionalit. Stavu nepomáhá omezená velikost týmu, zdrojů a talk od vedení.

=Metoda=

Pro simulaci byla zvolena metoda systémové dynamiky, která je vhodná pro modelování zpětných vazeb a kumulativních efektů v časově proměnných systémech. Model byl vytvořen v nástroji Vensim.

=Model=

Model reprezentuje reálný případ z praxe. Kde dochází k interakci mezi backlogem, technickým dluhem, produktivitou a strategiemi řízení dluhu.

Míra využití zkratek se pohybuje kolem 4 z 10 případů. Backlog v tomto momentu má přes 80 hodin na jednotlivých požadavcích. A taky v tomto momentu už máme vedle backlogu kolem 30 hodin přirazených na refaktoring z důvodu neoptimálních řešení. Projekt je koncipován pro 2 aktivní developery s možností rozšíření na 6 lidí. Míra nově příchozích požadavcích je simulována normálovým rozdělením, tasky chodí pravidelně na týdenní bázi no pro jednoduchost jsme upravili logiku a denně se generuje v průměru 6 hodin práce. V tomto modelu jsme zanedbali svátků a jiných nepracovních dnů. Jelikož na projektu pracují převážně studenti, uvažujeme produktivitu 50 %.

'''Pro CLD jsme si identifikovali tři důležité kauzální slučky:'''

R1 – Růst dluhu: Tlak na rychlé dodání zvyšuje míru zkratek, což vede k rychlejší akumulaci technického dluhu, ten snižuje produktivitu, což vede k pomalejšímu dodání a opětovnému nárůstu tlaku.

R2 – Ztráta morálky: Nárůstem dluhu se zvyšuje frustrace a ztráta morálky týmu, což má negativní dopad na produktivitu a znovu zvyšuje backlog a dluh.

B1 – Refaktoring: Pokud dochází k refaktoringu, může dojít k redukci technického dluhu a obnovení části ztracené produktivity.

[[File:Hrus07_01.png]]

'''SFD model obsahuje následující:'''
Proměnné v modelu:

• Počáteční backlog (hodinově)

• Počáteční dluh

• Velikost týmu (počet developerů)

• Základní produktivita

• Míra zkratek (neboli nátlak vedení, protože alibisticky počítáme s poctivostí developera)

• Podíl času na refaktoring

• Efektivita refaktoringu

• Dopad dluhu na produktivitu

• Nové požadavky (generovány s malou stochastickou variabilitou)

[[File:Hrus07_02.png]]

=Výsledky=

Prvotní simulace se spoléhali na konstantní alokaci času na refaktoring kterou je zákazník ochoten zaplatit kolem 10 %. Tato míra pomáhá udržet duh pod kontrolou, ale dlohodobě nedokáže dluh zastavit. Reaktivní strategie (refaktoring, když duh dosáhne určité úrovně) se ukazuje jako efektivnější v rovnováze mezi krátkodobou produktivitou a dlouhodobou udržitelností vývoje. Proto dále uvažujme jen výsledky s dynamickou mírou alokovaného času pro refaktoring.

Simulace jednoho roku projektu z počátečního stavu by nebyla zvládnutelná a by bylo odpracováno méně než 8 hodin. 1 student by na konci roku efektivně zvládl odpracovat 2 hodiny na projektu a 1.5 hodiny na refaktoringu.

Optimalizací počtu developerů jsme zjistili, že 3 studenti jsou optimální počet pro udržení 8 hodin práce na projektu a 3 hodin na refaktoringu, přičemž dodání práce nekolísá a dluh se zmenšuje. Přičemž studenti můžou být pohodlně nahrazeni 2 zaměstnanci na plný úvazek.

Dle předpokladu, vyšší optimalizace získáme jen za předpokladu snížení tlaku a tedy míry zkratek které zaměstnanci použijí. Optimální řešení je 20 % využití zkratek s 2 zaměstnanci na plný úvazek. Při kterém získáme 12.4 hodin práce na projektu místo 8 s nulovou mírou využívání zkratek.

=Závěr=

Model potvrzuje, že řízení technického dluhu je klíčové pro udržitelný vývoj software. Projektoví manažeři a stakeholdeři mohou pomocí simulace pochopit důsledky různých rozhodnutí a lépe prioritizovat mezi rychlostí dodání a kvalitou kódu. Zkratky dokážou přinést bonus k produktivitě no musí být správně ošetřeny a zkratky nesmí překročit hranici, v našem konkrétním případu 20 %. Refaktoring není luxus, ale nezbytný nástroj k zabránění kolapsu produktivity.

= Data =
Po konzultaci s vedením jsem dosal povolení pro využití produkčních dat na méně důležitém projektu a kombinoval je s informacemi z odborní literatury.

* GUPTA, Kartik, 2025. Measuring the Impact of Technical Debt on Development Effort in Software Projects. arXiv [online]. [cit. 2025-05-12]. Dostupné z: https://arxiv.org/abs/2502.16277

* YLI-HUUMO, Jesse, Andrey MAGLYAS a Kari SMOLANDER, 2016. How do software development teams manage technical debt? – An empirical study. Dostupné z: doi:https://doi.org/10.1016/j.jss.2016.05.018

* TOM, Edith, Aybüke AURUM a Richard VIDGEN, 2013. An exploration of technical debt. Journal of Systems and Software. 86(6), 1498–1516. Dostupné z: doi:https://doi.org/10.1016/j.jss.2012.12.052

* HOLVITIE, Johannes, Sherlock A. LICORISH, Rodrigo O. SPÍNOLA, Sami HYRYNSALMI, Stephen G. MACDONELL, Thiago S. MENDES, Jim BUCHAN a Ville LEPPÄNEN, 2018. Technical debt and agile software development practices and processes: An industry practitioner survey. Information and Software Technology. 96, 141–160. Dostupné z: doi:https://doi.org/10.1016/j.infsof.2017.11.015

* Wierzchanowski G. and Jackiewicz M. Web Article: The complete guide to technical debt management: best practices for future proofing your new apps. Dostupné z: https://www.rst.software/blog/technical-debt-management

Jiné pomocné materiály
Feedback loops: System Dynamics: Exploring System Dynamics in Feedback Loops [https://www.fastercapital.com/content/Feedback-loops--System-Dynamics--Exploring-System-Dynamics-in-Feedback-Loops.html]

Technical debt quantification financial analysis: [https://fullscale.io/blog/technical-debt-quantification-financial-analysis/]

=Kód=

[[File:Hrus07.mdl]]

(01) Akumulace dluhu=Míra zkratek * Dodana prace
Units: Hour
(02) Backlog= INTEG (MAX(Nové požadavky - Dodana prace, 0), Počáteční backlog)
Units: Hour
(03) Čas na Refaktoring=Produktivita * Podil refaktoru
Units: Hour
(04) Developeři=1 + INTEGER ((Backlog + Dluh) / 160)
Units: Dmnl [1,20,1]
(05) Dluh= INTEG (Akumulace dluhu-Refaktoring, Počáteční dluh)
Units: Hour
(06) Dodana prace=Produktivita * ( 1 - Podil refaktoru)
Units: Hour
(07) Dopad Dluhu=1 / (1 + EXP((Dluh - 50) / 10))
Units: Dmnl
(08) Efektivita Refaktoringu=0.6
Units: Dmnl [0,1,0.01]
(09) FINAL TIME = 365
Units: Day
The final time for the simulation.
(10) INITIAL TIME = 0
Units: Day
The initial time for the simulation.
(11) Míra zkratek=0.4
Units: Dmnl [0,1,0.01]
(12) Nové požadavky=RANDOM NORMAL(4, 10, 6, 2, 12345)
Units: Hour
(13) Počáteční backlog=80
Units: Hour [0,500,8]
(14) Počáteční dluh=30
Units: Hour [0,500,8]
(15) Podil refaktoru=MIN(1, Dluh / 150 + 0.2 * (Backlog / 200))
Units: Hour
(16) Produktivita=Developeři * 8 * Základní produktivita * (1 + 0.35 * Míra zkratek) * Dopad Dluhu
Units: Hour
(17) Refaktoring=Čas na Refaktoring * Efektivita Refaktoringu
Units: Hour
(18) SAVEPER =
TIME STEP
Units: Day [0,?]
The frequency with which output is stored.
(19) TIME STEP = 1
Units: Day [0,?]
The time step for the simulation.
(20) Základní produktivita=0.5
Units: Dmnl [0,1,0.01]

SS 2024/2025/cs

2025-06-15T19:45:20Z

Hrus07:

{{DISPLAYTITLE:LS 2024/2029}}

Semestrální práce (simulace) z letního semestru 2024/2025. Sem přidejte odkaz na stránku s Vaší prací.
Nejprve je třeba nechat schválit [[Assignment SS 2024/2025/cs|zadání práce]].

=Vypracovaná témata LS 2024/2025=
* [https://www.simulace.info/index.php/User:Hlaj13 Strategie hráčů ve hře v kostky dle pravidel hry Farkle (NetLogo)] - Jan Hlavnička
* [https://www.simulace.info/index.php/User:Plaz03 Simulace tučňáků hledajících lásku na ledové kře (NetLogo)] - Zuzana Plachá
* [https://www.simulace.info/index.php/Útoky_medvědů Útoky medvědů (NetLogo)] Jan Vlček
* [https://www.simulace.info/index.php/User:Smrv03 Evakuace šelem v pražské ZOO v případě povodně (NetLogo)] - Veronika Smrčková
* [https://www.simulace.info/index.php/User:Bilk08 Bitva u Azincourtu (Netlogo) ] – Kateřina Bílková
* [https://www.simulace.info/index.php/User:Seka01 Simulace vojenské patroly a střetu s nepřítelem (Netlogo)] - Alexandr Sekera
* [https://www.simulace.info/index.php/User:Kubd06 Chování zákazníků v supermarketu/večerce (Netlogo)] – David Kubánek
* [https://www.simulace.info/index.php/User:Sanv05 Kontrola jízdenek v MHD (NetLogo)] - Vladislav Sanin
* [https://www.simulace.info/index.php/User:Jelp05 Autobusová linka v městské dopravě (NetLogo)] - Petr Jelínek
* [https://www.simulace.info/index.php/User:Kalp08 Přemnožení divokých prasat (NetLogo)] - Petr Kalina
* [https://www.simulace.info/index.php/User:Lans06 Pavlovovo podmiňování (Vensim)] - Louis Lang
* [https://www.simulace.info/index.php/User:Kala13 Šíření invazních druhů rostlin v krajině (Netlogo)] - Alena Smetanová
* [https://www.simulace.info/index.php/Optimální_nacenění_zálohy_na_kelímky Optimální nacenění zálohy na vratné kelímky na akcích (Monte Carlo)] - Phuong Bao Pham
* [https://www.simulace.info/index.php/User:Jana19 Bakterie na rukou (NetLogo)] – Alena Jansová
* [https://www.simulace.info/index.php/User:Hluv01 Vývoj hodnoty investičních portfolií v čase (Monte Carlo)] – Vilém Hluštík
* [https://www.simulace.info/index.php/User:Hrus07 Dynamika technického dluhu v softwarovém vývoji] – Šimon Hrúz

Dynamika technického dluhu v softwarovém vývoji

2025-06-15T19:40:07Z

Hrus07: Blanked the page

User:Hrus07

2025-06-15T19:39:06Z

Hrus07: Created page with "Technický dluh je dnes neodmyslitelnou součástí softwarového vývoje. Vzniká v důsledku různých důvodu (tlak na rychlost dodání, neoptimální řešení, použív..."

Technický dluh je dnes neodmyslitelnou součástí softwarového vývoje. Vzniká v důsledku různých důvodu (tlak na rychlost dodání, neoptimální řešení, používání zkratek a zanedbání architektury). Tento dluh se časem akumuluje a projevuje se v podobě nárůstu úsilí nutného k úpravám, údržbě ale ovlivňuje i další vývoj. Čím větší dluh, tím větší dopad na produktivitu týmu. Projekt se zpomaluje a dále zvyšuje celkové náklady.

=Definice problému=

Aplikace, o kterou se starám vznikla jako demovací nástroj. S průběhem času se vyvinula do plnohodnotného projektu a její rozšiřování naráží na technologický dluh. Začínáme tedy s již existencí defektů, ke kterému se přidává backlog nových funkcionalit. Stavu nepomáhá omezená velikost týmu, zdrojů a talk od vedení.

=Metoda=

Pro simulaci byla zvolena metoda systémové dynamiky, která je vhodná pro modelování zpětných vazeb a kumulativních efektů v časově proměnných systémech. Model byl vytvořen v nástroji Vensim.

=Model=

Model reprezentuje reálný případ z praxe. Kde dochází k interakci mezi backlogem, technickým dluhem, produktivitou a strategiemi řízení dluhu.

Míra využití zkratek se pohybuje kolem 4 z 10 případů. Backlog v tomto momentu má přes 80 hodin na jednotlivých požadavcích. A taky v tomto momentu už máme vedle backlogu kolem 30 hodin přirazených na refaktoring z důvodu neoptimálních řešení. Projekt je koncipován pro 2 aktivní developery s možností rozšíření na 6 lidí. Míra nově příchozích požadavcích je simulována normálovým rozdělením, tasky chodí pravidelně na týdenní bázi no pro jednoduchost jsme upravili logiku a denně se generuje v průměru 6 hodin práce. V tomto modelu jsme zanedbali svátků a jiných nepracovních dnů. Jelikož na projektu pracují převážně studenti, uvažujeme produktivitu 50 %.

'''Pro CLD jsme si identifikovali tři důležité kauzální slučky:'''

R1 – Růst dluhu: Tlak na rychlé dodání zvyšuje míru zkratek, což vede k rychlejší akumulaci technického dluhu, ten snižuje produktivitu, což vede k pomalejšímu dodání a opětovnému nárůstu tlaku.

R2 – Ztráta morálky: Nárůstem dluhu se zvyšuje frustrace a ztráta morálky týmu, což má negativní dopad na produktivitu a znovu zvyšuje backlog a dluh.

B1 – Refaktoring: Pokud dochází k refaktoringu, může dojít k redukci technického dluhu a obnovení části ztracené produktivity.

[[File:Hrus07_01.png]]

'''SFD model obsahuje následující:'''
Proměnné v modelu:
• Počáteční backlog (hodinově)
• Počáteční dłuh
• Velikost týmu (počet developerů)
• Základní produktivita
• Míra zkratek (neboli nátlak vedení, protože alibisticky počítáme s poctivostí developera)
• Podíl času na refaktoring
• Efektivita refaktoringu
• Dopad dluhu na produktivitu
• Nové požadavky (generovány s malou stochastickou variabilitou)

[[File:Hrus07_02.png]]

=Výsledky=

Prvotní simulace se spoléhali na konstantní alokaci času na refaktoring kterou je zákazník ochoten zaplatit kolem 10 %. Tato míra pomáhá udržet duh pod kontrolou, ale dlohodobě nedokáže dluh zastavit. Reaktivní strategie (refaktoring, když duh dosáhne určité úrovně) se ukazuje jako efektivnější v rovnováze mezi krátkodobou produktivitou a dlouhodobou udržitelností vývoje. Proto dále uvažujme jen výsledky s dynamickou mírou alokovaného času pro refaktoring.

Simulace jednoho roku projektu z počátečního stavu by nebyla zvládnutelná a by bylo odpracováno méně než 8 hodin. 1 student by na konci roku efektivně zvládl odpracovat 2 hodiny na projektu a 1.5 hodiny na refaktoringu.

Optimalizací počtu developerů jsme zjistili, že 3 studenti jsou optimální počet pro udržení 8 hodin práce na projektu a 3 hodin na refaktoringu, přičemž dodání práce nekolísá a dluh se zmenšuje. Přičemž studenti můžou být pohodlně nahrazeni 2 zaměstnanci na plný úvazek.

Dle předpokladu, vyšší optimalizace získáme jen za předpokladu snížení tlaku a tedy míry zkratek které zaměstnanci použijí. Optimální řešení je 20 % využití zkratek s 2 zaměstnanci na plný úvazek. Při kterém získáme 12.4 hodin práce na projektu místo 8 s nulovou mírou využívání zkratek.

=Závěr=

Model potvrzuje, že řízení technického dluhu je klíčové pro udržitelný vývoj software. Projektoví manažeři a stakeholdeři mohou pomocí simulace pochopit důsledky různých rozhodnutí a lépe prioritizovat mezi rychlostí dodání a kvalitou kódu. Zkratky dokážou přinést bonus k produktivitě no musí být správně ošetřeny a zkratky nesmí překročit hranici, v našem konkrétním případu 20 %. Refaktoring není luxus, ale nezbytný nástroj k zabránění kolapsu produktivity.

= Data =
Po konzultaci s vedením jsem dosal povolení pro využití produkčních dat na méně důležitém projektu a kombinoval je s informacemi z odborní literatury.

* GUPTA, Kartik, 2025. Measuring the Impact of Technical Debt on Development Effort in Software Projects. arXiv [online]. [cit. 2025-05-12]. Dostupné z: https://arxiv.org/abs/2502.16277

* YLI-HUUMO, Jesse, Andrey MAGLYAS a Kari SMOLANDER, 2016. How do software development teams manage technical debt? – An empirical study. Dostupné z: doi:https://doi.org/10.1016/j.jss.2016.05.018

* TOM, Edith, Aybüke AURUM a Richard VIDGEN, 2013. An exploration of technical debt. Journal of Systems and Software. 86(6), 1498–1516. Dostupné z: doi:https://doi.org/10.1016/j.jss.2012.12.052

* HOLVITIE, Johannes, Sherlock A. LICORISH, Rodrigo O. SPÍNOLA, Sami HYRYNSALMI, Stephen G. MACDONELL, Thiago S. MENDES, Jim BUCHAN a Ville LEPPÄNEN, 2018. Technical debt and agile software development practices and processes: An industry practitioner survey. Information and Software Technology. 96, 141–160. Dostupné z: doi:https://doi.org/10.1016/j.infsof.2017.11.015

* Wierzchanowski G. and Jackiewicz M. Web Article: The complete guide to technical debt management: best practices for future proofing your new apps. Dostupné z: https://www.rst.software/blog/technical-debt-management

Jiné pomocné materiály
Feedback loops: System Dynamics: Exploring System Dynamics in Feedback Loops [https://www.fastercapital.com/content/Feedback-loops--System-Dynamics--Exploring-System-Dynamics-in-Feedback-Loops.html]

Technical debt quantification financial analysis: [https://fullscale.io/blog/technical-debt-quantification-financial-analysis/]

=Kód=

[[File:Hrus07.mdl]]

(01) Akumulace dluhu=Míra zkratek * Dodana prace
Units: Hour
(02) Backlog= INTEG (MAX(Nové požadavky - Dodana prace, 0), Počáteční backlog)
Units: Hour
(03) Čas na Refaktoring=Produktivita * Podil refaktoru
Units: Hour
(04) Developeři=1 + INTEGER ((Backlog + Dluh) / 160)
Units: Dmnl [1,20,1]
(05) Dluh= INTEG (Akumulace dluhu-Refaktoring, Počáteční dluh)
Units: Hour
(06) Dodana prace=Produktivita * ( 1 - Podil refaktoru)
Units: Hour
(07) Dopad Dluhu=1 / (1 + EXP((Dluh - 50) / 10))
Units: Dmnl
(08) Efektivita Refaktoringu=0.6
Units: Dmnl [0,1,0.01]
(09) FINAL TIME = 365
Units: Day
The final time for the simulation.
(10) INITIAL TIME = 0
Units: Day
The initial time for the simulation.
(11) Míra zkratek=0.4
Units: Dmnl [0,1,0.01]
(12) Nové požadavky=RANDOM NORMAL(4, 10, 6, 2, 12345)
Units: Hour
(13) Počáteční backlog=80
Units: Hour [0,500,8]
(14) Počáteční dluh=30
Units: Hour [0,500,8]
(15) Podil refaktoru=MIN(1, Dluh / 150 + 0.2 * (Backlog / 200))
Units: Hour
(16) Produktivita=Developeři * 8 * Základní produktivita * (1 + 0.35 * Míra zkratek) * Dopad Dluhu
Units: Hour
(17) Refaktoring=Čas na Refaktoring * Efektivita Refaktoringu
Units: Hour
(18) SAVEPER =
TIME STEP
Units: Day [0,?]
The frequency with which output is stored.
(19) TIME STEP = 1
Units: Day [0,?]
The time step for the simulation.
(20) Základní produktivita=0.5
Units: Dmnl [0,1,0.01]

Dynamika technického dluhu v softwarovém vývoji

2025-06-15T19:36:16Z

Hrus07: Přidání témata simulace: Dynamika technického dluhu v softwarovém vývoji

Technický dluh je dnes neodmyslitelnou součástí softwarového vývoje. Vzniká v důsledku různých důvodu (tlak na rychlost dodání, neoptimální řešení, používání zkratek a zanedbání architektury). Tento dluh se časem akumuluje a projevuje se v podobě nárůstu úsilí nutného k úpravám, údržbě ale ovlivňuje i další vývoj. Čím větší dluh, tím větší dopad na produktivitu týmu. Projekt se zpomaluje a dále zvyšuje celkové náklady.

=Definice problému=

Aplikace, o kterou se starám vznikla jako demovací nástroj. S průběhem času se vyvinula do plnohodnotného projektu a její rozšiřování naráží na technologický dluh. Začínáme tedy s již existencí defektů, ke kterému se přidává backlog nových funkcionalit. Stavu nepomáhá omezená velikost týmu, zdrojů a talk od vedení.

=Metoda=

Pro simulaci byla zvolena metoda systémové dynamiky, která je vhodná pro modelování zpětných vazeb a kumulativních efektů v časově proměnných systémech. Model byl vytvořen v nástroji Vensim.

=Model=

Model reprezentuje reálný případ z praxe. Kde dochází k interakci mezi backlogem, technickým dluhem, produktivitou a strategiemi řízení dluhu.

Míra využití zkratek se pohybuje kolem 4 z 10 případů. Backlog v tomto momentu má přes 80 hodin na jednotlivých požadavcích. A taky v tomto momentu už máme vedle backlogu kolem 30 hodin přirazených na refaktoring z důvodu neoptimálních řešení. Projekt je koncipován pro 2 aktivní developery s možností rozšíření na 6 lidí. Míra nově příchozích požadavcích je simulována normálovým rozdělením, tasky chodí pravidelně na týdenní bázi no pro jednoduchost jsme upravili logiku a denně se generuje v průměru 6 hodin práce. V tomto modelu jsme zanedbali svátků a jiných nepracovních dnů. Jelikož na projektu pracují převážně studenti, uvažujeme produktivitu 50 %.

'''Pro CLD jsme si identifikovali tři důležité kauzální slučky:'''

R1 – Růst dluhu: Tlak na rychlé dodání zvyšuje míru zkratek, což vede k rychlejší akumulaci technického dluhu, ten snižuje produktivitu, což vede k pomalejšímu dodání a opětovnému nárůstu tlaku.

R2 – Ztráta morálky: Nárůstem dluhu se zvyšuje frustrace a ztráta morálky týmu, což má negativní dopad na produktivitu a znovu zvyšuje backlog a dluh.

B1 – Refaktoring: Pokud dochází k refaktoringu, může dojít k redukci technického dluhu a obnovení části ztracené produktivity.

[[File:Hrus07_01.png]]

'''SFD model obsahuje následující:'''
Proměnné v modelu:
• Počáteční backlog (hodinově)
• Počáteční dłuh
• Velikost týmu (počet developerů)
• Základní produktivita
• Míra zkratek (neboli nátlak vedení, protože alibisticky počítáme s poctivostí developera)
• Podíl času na refaktoring
• Efektivita refaktoringu
• Dopad dluhu na produktivitu
• Nové požadavky (generovány s malou stochastickou variabilitou)

[[File:Hrus07_02.png]]

=Výsledky=

Prvotní simulace se spoléhali na konstantní alokaci času na refaktoring kterou je zákazník ochoten zaplatit kolem 10 %. Tato míra pomáhá udržet duh pod kontrolou, ale dlohodobě nedokáže dluh zastavit. Reaktivní strategie (refaktoring, když duh dosáhne určité úrovně) se ukazuje jako efektivnější v rovnováze mezi krátkodobou produktivitou a dlouhodobou udržitelností vývoje. Proto dále uvažujme jen výsledky s dynamickou mírou alokovaného času pro refaktoring.

Simulace jednoho roku projektu z počátečního stavu by nebyla zvládnutelná a by bylo odpracováno méně než 8 hodin. 1 student by na konci roku efektivně zvládl odpracovat 2 hodiny na projektu a 1.5 hodiny na refaktoringu.

Optimalizací počtu developerů jsme zjistili, že 3 studenti jsou optimální počet pro udržení 8 hodin práce na projektu a 3 hodin na refaktoringu, přičemž dodání práce nekolísá a dluh se zmenšuje. Přičemž studenti můžou být pohodlně nahrazeni 2 zaměstnanci na plný úvazek.

Dle předpokladu, vyšší optimalizace získáme jen za předpokladu snížení tlaku a tedy míry zkratek které zaměstnanci použijí. Optimální řešení je 20 % využití zkratek s 2 zaměstnanci na plný úvazek. Při kterém získáme 12.4 hodin práce na projektu místo 8 s nulovou mírou využívání zkratek.

=Závěr=

Model potvrzuje, že řízení technického dluhu je klíčové pro udržitelný vývoj software. Projektoví manažeři a stakeholdeři mohou pomocí simulace pochopit důsledky různých rozhodnutí a lépe prioritizovat mezi rychlostí dodání a kvalitou kódu. Zkratky dokážou přinést bonus k produktivitě no musí být správně ošetřeny a zkratky nesmí překročit hranici, v našem konkrétním případu 20 %. Refaktoring není luxus, ale nezbytný nástroj k zabránění kolapsu produktivity.

= Data =
Po konzultaci s vedením jsem dosal povolení pro využití produkčních dat na méně důležitém projektu a kombinoval je s informacemi z odborní literatury.

* GUPTA, Kartik, 2025. Measuring the Impact of Technical Debt on Development Effort in Software Projects. arXiv [online]. [cit. 2025-05-12]. Dostupné z: https://arxiv.org/abs/2502.16277

* YLI-HUUMO, Jesse, Andrey MAGLYAS a Kari SMOLANDER, 2016. How do software development teams manage technical debt? – An empirical study. Dostupné z: doi:https://doi.org/10.1016/j.jss.2016.05.018

* TOM, Edith, Aybüke AURUM a Richard VIDGEN, 2013. An exploration of technical debt. Journal of Systems and Software. 86(6), 1498–1516. Dostupné z: doi:https://doi.org/10.1016/j.jss.2012.12.052

* HOLVITIE, Johannes, Sherlock A. LICORISH, Rodrigo O. SPÍNOLA, Sami HYRYNSALMI, Stephen G. MACDONELL, Thiago S. MENDES, Jim BUCHAN a Ville LEPPÄNEN, 2018. Technical debt and agile software development practices and processes: An industry practitioner survey. Information and Software Technology. 96, 141–160. Dostupné z: doi:https://doi.org/10.1016/j.infsof.2017.11.015

* Wierzchanowski G. and Jackiewicz M. Web Article: The complete guide to technical debt management: best practices for future proofing your new apps. Dostupné z: https://www.rst.software/blog/technical-debt-management

Jiné pomocné materiály
Feedback loops: System Dynamics: Exploring System Dynamics in Feedback Loops [https://www.fastercapital.com/content/Feedback-loops--System-Dynamics--Exploring-System-Dynamics-in-Feedback-Loops.html]

Technical debt quantification financial analysis: [https://fullscale.io/blog/technical-debt-quantification-financial-analysis/]

=Kód=

[[File:Hrus07.mdl]]

(01) Akumulace dluhu=Míra zkratek * Dodana prace
Units: Hour
(02) Backlog= INTEG (MAX(Nové požadavky - Dodana prace, 0), Počáteční backlog)
Units: Hour
(03) Čas na Refaktoring=Produktivita * Podil refaktoru
Units: Hour
(04) Developeři=1 + INTEGER ((Backlog + Dluh) / 160)
Units: Dmnl [1,20,1]
(05) Dluh= INTEG (Akumulace dluhu-Refaktoring, Počáteční dluh)
Units: Hour
(06) Dodana prace=Produktivita * ( 1 - Podil refaktoru)
Units: Hour
(07) Dopad Dluhu=1 / (1 + EXP((Dluh - 50) / 10))
Units: Dmnl
(08) Efektivita Refaktoringu=0.6
Units: Dmnl [0,1,0.01]
(09) FINAL TIME = 365
Units: Day
The final time for the simulation.
(10) INITIAL TIME = 0
Units: Day
The initial time for the simulation.
(11) Míra zkratek=0.4
Units: Dmnl [0,1,0.01]
(12) Nové požadavky=RANDOM NORMAL(4, 10, 6, 2, 12345)
Units: Hour
(13) Počáteční backlog=80
Units: Hour [0,500,8]
(14) Počáteční dluh=30
Units: Hour [0,500,8]
(15) Podil refaktoru=MIN(1, Dluh / 150 + 0.2 * (Backlog / 200))
Units: Hour
(16) Produktivita=Developeři * 8 * Základní produktivita * (1 + 0.35 * Míra zkratek) * Dopad Dluhu
Units: Hour
(17) Refaktoring=Čas na Refaktoring * Efektivita Refaktoringu
Units: Hour
(18) SAVEPER =
TIME STEP
Units: Day [0,?]
The frequency with which output is stored.
(19) TIME STEP = 1
Units: Day [0,?]
The time step for the simulation.
(20) Základní produktivita=0.5
Units: Dmnl [0,1,0.01]

File:Hrus07.mdl

2025-06-15T19:22:44Z

Hrus07:

File:Hrus07 02.png

2025-06-15T19:16:24Z

Hrus07:

File:Hrus07 01.png

2025-06-15T19:14:14Z

Hrus07:

Assignment SS 2024/2025/cs

2025-05-12T20:26:11Z

Hrus07: Edit témata : Dynamika technického dluhu v softwarovém vývoji

{{Ambox
| text = <div>
Please, put here your assignments. Do not forget to sign them. You can use <nowiki>~~~~</nowiki> (four tildas) for an automatic signature. Use Show preview in order to check the result before your final sumbition.
</div>
}}

{{Ambox
| text = <div>
Please, strive to formulate your assignment carefully. We expect an adequate effort to formulate the assignment as it is your semestral paper. Do not forget that your main goal is a research paper. It means your simulation model must generate the results that are specific, measurable and verifiable. Think twice how you will develop your model, which entities you will use, draw a model diagram, consider what you will measure. No sooner than when you have a good idea about the model, submit your assignment. And of course, read [[How to deal with the simulation assignment|How to deal with the simulation assignment]].
</div>
}}

{{Ambox
| text = <div>
Topics on gambling, cards, etc. are not welcome.
</div>
}}

{{Ambox
| type = content
| text = <div>
In order to avoid possible confusion, please, check if you have added '''approved''' in bold somewhere in our comment under your submission. If there is no '''approved''', it means the assignment was not approved yet.
</div>
}}

{{Ambox
| text = <div>
'''Criteria for evaluation of the simulation proposal'''

The proposal must contain:
*What you will simulate
*The goal of the simulation (what you analyze - i.e. not "to simulate balloon factory", but what problem should the simulation solve).
*Who would actually use such simulation (example of such user) and how would it help him
*What method and simulation environment you plan to use. Choose only from the development environments that we have used in the course.
*What variables will be incorporated
*What variables will be random
*What exact data you will base values of your variables on
*(In case of Monte Carlo) What exact data you will base your determination of probability distribution of your random variables on
*What exact data you will base your formulas in the simulation (simulation behavior) on

'''If any of the above points are missing from the simulation proposal, the proposal is considered incomplete. Unless the proposal contains all of the above points it will not be evaluated at all (and therefore cannot be approved).'''

# Is it clear from the proposed assignment how the simulation will work?
# Does the simulation make sense?
# Is the simulation model complex enough to simulate credibly the real-world phenomenon that the simulation tries to simulate?
# Is the data used real and relevant for the real-world phenomenon that the simulation tries to simulate?
# Is the simulation feasible? (in given time by the course)

'''If the answer to any of the above points is no, you need to improve your proposal. Don't wait for us to tell you so - you're wasting your time.'''

</div>
}}

== Simulace: Dynamika technického dluhu v softwarovém vývoji ==

=== Popis problému ===
Technický dluh v softwarovém vývoji vzniká, je a taky i bude. Jedním z důvodu vzniku je tlak na rychlost dodání, zvolení suboptimálního řešení nebo zkratky pro usnadnění práce. Tento dluh se hromadí v kódové bázi a systému a chová se podobně jako finanční dluh – s "úroky" v podobě zvýšeného úsilí na budoucí údržbu, opravy chyb ale i implementaci nových funkcí. Akumulovaný dluh tak postupně zpomaluje vývojový tým, snižuje agilitu projektu a zvyšuje celkové dlouhodobé náklady pro celou firmu.

=== Cíl simulace ===
Simulace si dává za úkol namodelovat dynamiku akumulace dluhu a jeho splácení v čase. Jaký ma vliv na produktivitu. Ale hlavně jaké různé strategie řízení dluhu jsou dlouhodobě nejefektivnejší (např. konstatní alokace času na refaktoring vs. reaktivní přístup).

=== Použití simulace ===
* Jako podpora při rozhodování projektových manažerů o prioritách (rychlost vs. kvalita).
* Může pomoci stakeholderům pochopit náklady a přínosy investic do kvality kódu (argumenty pro CIO).
* Pro strategické plánování v IT organizacích týkající se údržby a rozvoje systémů.

=== Použitá metoda a prostředí ===
* Simulace využívá metodu systémové dynamiky (System Dynamics).
* Bude použit program Vensim.

=== Proměnné ===
Definované předem:
* Počáteční úroveň technického dluhu.
* Počáteční rozsah backlogu (nesplněných požadavků).
* Velikost týmu.
* Základní produktivita týmu (bez vlivu dluhu).
* Míra alokace času na refaktoring (strategické rozhodnutí).

Náhodné:
* Tempo příchodu nových požadavků do backlogu.
* Efektivita refaktorovacích snah (malé fluktuace).
* Výskyt neočekávaných problémů vedoucích k tvorbě dluhu (např. kritické chyby).

Popřípadě další.

=== Data ===
* Produkční data budou ťežko získatelné, proto využijeme kombinaci odhadu expertů z praxe a odbornou literaturu.

* GUPTA, Kartik, 2025. Measuring the Impact of Technical Debt on Development Effort in Software Projects. arXiv [online]. [cit. 2025-05-12]. Dostupné z: https://arxiv.org/abs/2502.16277
* YLI-HUUMO, Jesse, Andrey MAGLYAS a Kari SMOLANDER, 2016. How do software development teams manage technical debt? – An empirical study. Dostupné z: doi:https://doi.org/10.1016/j.jss.2016.05.018
* TOM, Edith, Aybüke AURUM a Richard VIDGEN, 2013. An exploration of technical debt. Journal of Systems and Software. 86(6), 1498–1516. Dostupné z: doi:https://doi.org/10.1016/j.jss.2012.12.052
* HOLVITIE, Johannes, Sherlock A. LICORISH, Rodrigo O. SPÍNOLA, Sami HYRYNSALMI, Stephen G. MACDONELL, Thiago S. MENDES, Jim BUCHAN a Ville LEPPÄNEN, 2018. Technical debt and agile software development practices and processes: An industry practitioner survey. Information and Software Technology. 96, 141–160. Dostupné z: doi:https://doi.org/10.1016/j.infsof.2017.11.015

=== Simulant ===
[[User:Hrus07|Hrus07]] ([[User talk:Hrus07|talk]]) 22:19, 12 May 2025 (CET)

== Simulace: Útoky medvědů ==

=== Popis problému ===
Na Slovensku se vyskytuje velké množství medvědů, kteří ohrožují tamní obyvatele a turisty. Útoky jsou momentálně velmi časté a přibývají. Slovenská vláda schválila návrh na odstřel cca 350 jedinců. Zároveň se jedná o chráněný druh, tudíž počty by neměly být redukovány ve velké míře, ne-li vůbec.

=== Cíl simulace ===
Cílem bude simulovat ideální počet medvědů, aby se minimalizoval počet útoků medvěda a potřeba redukovat počet medvědů.

=== Použití simulace ===
* Např. pro plánování odstřelu medvědů, aby druh nebyl příliš ohrožen.
* Simulace chování medvědů v přírodě.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenti budou medvědi, turisti a lovci. V prostředí se populace medvědů bude přirozeně zvyšovat. Turisté mají šanci na útěk. Lovci budou reagovat na incidenty medvědů s turisty.

=== Proměnné ===
Definované předem:
* Medvědi – pohybují se po krajině, hledají potravu a případně útočí na turisty
* Lovci – redukují počty medvědů na základě útoků a ohrožení turistů.
* Turisti – objevují tamní krajinu a lesy. Reagují na přítomnost medvědů.

Náhodné:
* Rozmístění medvědů, lovců a turistů.
* Rozmístění vegetace, lesů.

=== Data ===
* Slovenská vláda schválila odstřel medvědů [https://www.irozhlas.cz/zpravy-svet/nemuzeme-zit-v-zemi-kde-se-lide-boji-chodit-do-lesa-slovenska-vlada-schvalila_2504021255_mst]
* Medvěd hnědý - biotop a teritorium [https://www.selmy.cz/medved/biotop-a-teritorium/]
* Medvěd na Slovensku [https://sita.sk/nasvidiek/kolko-medvedov-zije-na-slovensku-studia-ukazala-cisla-a-najviac-ich-je-na-polane/?utm_source=chatgpt.com]

=== Simulant ===
[[User:Vlcj07|Vlcj07]] ([[User talk:Vlcj07|talk]]) 19:43, 12 May 2025 (CET)

== Simulace: Přemnožení divokých prasat ==

=== Popis problému ===
Divoká prasata jsou v České republice přemnožená – na našem území jich je v současnoti 100krát více, než je únosné. Přemnožení je zapříčeněno několika faktory. Prvním je způsob rozmnožování divokých prasat. Bachyně mívají dva vrhy ročně, přičemž v každém vrhu se vyskytuje průměrně 4-12 selat. Při přebytku potravy tak populace divokých prasat prudce roste. Druhý faktor, který zapříčiňuje přemnožení prasat, je absence přirozených predátorů těchto zvířat na našem území. Kontrolu populace pak musejí provádět myslivci, nicméně odtřel je v současné době nedostatečný.

Přemnožená prasata mají negativní dopad na vegetaci svého okolí. Jedná se například o rostlinu bleduli letní, která se v České republice řadí mezi zvláště chráněné druhy rostlin.

=== Cíl simulace ===
Cílem simulace bude simulovat ideální míru odstřelu divokých prasat, aby nedošlo ke zničení vzácné vegetace (jako je například bledule letní). V simulaci bude zobrazena součinnost několika faktorů (růst prasečí populace v závislosti na přítomnosti potravy, množství střelců nutných pro udržení populace na uzdě apod.).

=== Použití simulace ===
Kdo může simulaci použít?
* Myslivci pro informovanější plánování odstřelu prasat.
* Lesní správa, farmářský a zahradnický průmysl apod. – všechna tato odvětví jsou negativně ovlivněná přemnoženou prasečí populací.
* Simulace může problematiku přiblížit i širší veřejnosti, která tak bude lépe schopná seznat její závažnost.

=== Použitá metoda a prostředí ===
Prostředím multiagentní simulace bude NetLogo. Agenti budou divoká prasata, myslivci a vzácná vegetace. Prasata se budou množit rychlostí závislou na množství vegetace. Model bude simulovat různé počty myslivců a různé strategie střelby. Množství vegetace bude závislé na velikosti prasečí populace.

=== Proměnné ===
Definované předem:
* Rychlost množení a „žravost“ divokých prasat.
* Rychlost obnovy vegetace.
* Počet myslivců a strategie a způsob jejich odstřelování prasat.

Náhodné:
* Počáteční populace prasat (v určitém rozmezí).
* Počáteční množství vegetace (opět v určitém rozmezí).
* Rozmístění prasat.
* Rozmístění myslivců.
* Rozmístění vegetace.

=== Data ===
* Prasata devastují vzácnou zeleň. [https://benesovsky.denik.cz/zpravy_region/premnozena-prasata-pustosi-benesovsko-mizi-bledule-i-orchideje-20250318.html]
* Způsob rozmnožování divokých prasat. [https://www.hubeni-skudcu.cz/blog/prase-divoke/]
* Policejní odstřel divokých prasat. [https://www.idnes.cz/liberec/zpravy/odstrel-divocaku-praseci-mor-liberec-jablonec-myslivci-policie.A241212_140610_liberec-zpravy_cink]
* Prase divoké – základní informace. [https://www.kdelovit.cz/cz/lovna-zver/srstnata/prase-divoke]
* Životní cyklus divokých prasat. [https://cit.vfu.cz/pohoda/zivotni_cyklus.pdf]
* Lov divokého prasete. [https://huntasticzech.cz/zvire/prase-divoke/]

=== Simulant ===
[[User:Kalp08|Petr Kalina (kalp08)]] ([[User talk:Kalp08|talk]]) 13:52, 12 May 2025 (CET)

== Simulace: Šíření dezinformací na sociálních sítích ==

=== Popis problému ===
Simulace modeluje šíření dezinformace mezi uživateli sociální sítě. V dnešním digitálním prostoru jsou informace často sdíleny bez jejich ověřování, což přispívá k rychlému rozšiřování nepravdivých nebo manipulativních zpráv. Sociální sítě jsou hlavním kanálem pro šíření jak pravdivých, tak nepravdivých informací. Model zkoumá, jak rychle a do jaké míry se dezinformace rozšíří napříč sítí uživatelů, kteří jsou mezi sebou propojeni pomocí přátelství nebo sledujících. Ovlivňujícími faktory jsou zejména míra ochoty sdílet, schopnost rozpoznat nepravdivý obsah, struktura sítě (např. počet spojení) a chování jednotlivců. Cílem je porozumět tomu, jaké strategie mohou šíření zpomalit či omezit a jak síťová struktura ovlivňuje zranitelnost vůči dezinformacím.

=== Cíl simulace ===
Cílem simulace je odpovědět na otázku: jak ovlivňuje struktura sociální sítě, chování jednotlivých uživatelů a míra kritického myšlení rychlost a rozsah šíření dezinformací? Simulace umožní identifikovat klíčové parametry, které mohou buď přispět k virálnímu šíření, nebo ho potlačit. Výsledkem může být doporučení k edukaci uživatelů nebo návrh algoritmických opatření pro omezení dosahu problematického obsahu.

=== Použití simulace ===
Simulace má možné využití:
* Jako didaktický nástroj pro výuku mediální a digitální gramotnosti nebo informační bezpečnost
* Pro využití v akademickém výzkumu zabývajícím se šířením obsahu v online prostředí, včetně fake news a konspiračních teorií.

Výsledky mohou posloužit i jako argument pro zavedení preventivních opatření na sociálních platformách.

=== Použitá metoda a prostředí ===
Simulace je vytvořena v prostředí NetLogo. Agenti představují uživatele sociální sítě a jsou propojeni do komunikační struktury (vztahy: „sleduje“, „přátelí se“). Dezinformace se šíří po těchto spojeních. V modelu existují pravidla pro šíření dezinformace a rozhodování agentů. To znamená, že každý agent má určitou pravděpodobnost sdílení, může si informaci ověřit a tím ji zablokovat, nebo ji předat dál.

=== Proměnné ===
'''Definované předem:'''
• počet uživatelů v síti
• typ sociální sítě/síťové struktury (náhodná síť, small-world, scale-free)
• průměrný počet spojení na agenta = síťová hustota
• počet původních šiřitelů dezinformace
• pravděpodobnost sdílení dezinformace (bez ověření)
• pravděpodobnost ověření zprávy a zamezení jejího šíření
'''Náhodné:'''
• rozložení spojení v síti
• výběr původních šiřitelů
• pořadí interakcí mezi agenty (směr šíření, kdo ovlivní koho)
• individuální rozhodnutí každého agenta (na základě pravděpodobností)
• výsledný rozsah šíření (liší se běh od běhu i při stejných nastaveních)

=== Data ===
* Výzkumy behaviorální ekonomie a mediální gramotnosti – např. [https://mediaeducation.ucoz.ru/_ld/0/83_Fedorov-A-2007-.pdf JIRÁK, Jan; WOOLÁK, Radim Woolák Radim. Mediální gramotnost. Praha: Radioservis, 2009.]
* Analýzy šíření fake news – např. Vosoughi, Roy, Aral (2018) – „The spread of true and false news online“, Science 359(6380), 1146–1151. [https://ide.mit.edu/wp-content/uploads/2018/12/2017-IDE-Research-Brief-False-News.pdf „The spread of true and false news online“]
* Odhady pravděpodobností a struktury sítě vycházejí z běžného chování uživatelů na sociálních sítích
* Výzkumné zprávy o algoritmech šíření obsahu na platformách jako Facebook, Instagram, nebo TikTok

=== Simulant ===
[[User:macn04|macn04]] ([[User talk:macn04|talk]]) 14:30, 12 May 2025 (CET)

== Simulace: Evakuace šelem v pražské ZOO v případě povodně ==

=== Popis problému ===
Pražská zoologická zahrada se nachází v záplavovém území a v minulosti byla při povodních (např. v roce 2002 a 2013) vážně zasažena. Evakuace zvířat, zejména velkých a nebezpečných šelem, představuje logisticky i bezpečnostně náročný úkol. Zvířata musí být přepravena v co nejkratším čase, bezpečně a s minimálním stresem, zároveň je nutné chránit zaměstnance a návštěvníky. Simulace se zaměřuje na proces evakuace pavilonu šelem při náhlém zvýšení hladiny Vltavy. Výsledky mohou pomoci vedení ZOO lépe se připravit na mimořádné události.

=== Cíl simulace ===
Simulace se bude věnovat otázce: Jak rychle a efektivně lze evakuovat šelmy z ohroženého pavilonu v případě povodně?
Výsledkem bude návrh optimální evakuační strategie v závislosti na různých faktorech (např. počet ošetřovatelů, kooperace zvířat, čas do zaplavení, atd.). Některá zvířata jsou více nebezpečná jiná jsou klidná.

=== Použití simulace ===
Simulace může sloužit:
*Zaměstnancům ZOO, kteří se chtějí připravit na krizové situace
*Studentům, kteří se učí o ochraně zvířat nebo krizovém řízení
*Veřejnosti, která si chce udělat představu, jak taková situace vypadá a proč je důležitá příprava

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo, kde agenti budou zvířata, zaměstnanci (ošetřovatelé) a povodeň. Zvířata mají různé chování, velikost, agresivitu. Ošetřovatelé jsou zkušení, ale i nováčci a je jich různý počet na směnách. Povodeň může mít různé rychlosti. Prostředím je pavilon šelem v pražské ZOO. V pavilonu jsou jednotlivé expozice podle druhu zvířete. V případě, kdy hrozí evakuace jsou všechna zvířata uvnitř pavilonu.

V případě evakuace přijdou chovatelé a evakuují zvířata. Některá musí uspat, jiná ne. Zvířata přesouvají do klecí nebo boxů a převážejí pryč cestou podle zatopení. U každého zvířete je dohledatelný

=== Proměnné ===
Definované předem:
* Počet zvířat v pavilonu, jejich velikost a druhy
* Počet evakuačních cest
* Rychlost záplav (kolik času je na evakuaci)
* Počet ošetřovatelů a jejich zkušenosti (můžou být zkušení nebo nováčci, nováčci jsou pomalejší a mají vyšší pravděpodobnost minout uspávací šipkou)

Náhodné:
* kooperace zvířete (může být klidné nebo agresivní)
* rozmístění ošetřovatelů
* minutí uspávací šipkou
* rozbitá klec

=== Data ===
* výroční zprávy ZOO Praha [https://www.zoopraha.cz/vse-o-zoo/vyrocni-zpravy]
* mapa ZOO Praha (obrázková) [https://www.zoopraha.cz/navsteva/30-mapa-zoo-praha]
* mapa ZOO Praha [https://g.co/kgs/aXs5ceF]
* přiklad info o zvířeti ZOO Praha [https://www.zoopraha.cz/aktualne/pohledem-reditele/14972-jak-se-v-zoo-praha-chystame-na-povodne]
* převoz tygrů [https://www.jamescargo.com/blog/tiger-transport.php?utm_source=chatgpt.com]
* CITES transport guidelines [https://cites.org/eng/resources/transport/advice.shtml?utm_source=chatgpt.com]

=== Simulant ===
Veronika Smrčková
[[User:smrv03|smrv03]] ([[User talk:smrv03|talk]]) 11:36, 12 May 2025 (CET)

== Simulace: Strategie hráčů ve hře v kostky dle pravidel hry Farkle ==

=== Popis problému ===
Cílem simulace je analyzovat a porovnat různé herní strategie ve hře Farkle (hazardní kostková hra). Dva hráči si během hry střídavě hází kostkami a snaží se získat co nejvíce bodů pomocí specifických kombinací (např. trojic, postupky, šest stejných hodnot apod.). Hráči však musí v každém tahu rozhodnout, zda pokračovat v házení (s rizikem ztráty aktuálního skóre) nebo se zastavit a body si uložit.

Každý hráč je reprezentován jako „persona“ s předdefinovanou strategií rozhodování – od konzervativního po extrémně rizikového přístupu. Tyto odlišné styly chování významně ovlivňují průběh hry, četnost výher i riziko prohry kvůli přehnané hamižnosti.

=== Cíl simulace ===
Cílem simulace je zjistit, jaké herní strategie (persony) jsou nejefektivnější v dosažení výhry ve hře Farkle. Zároveň zohledňuje spravedlnost (oba hráči mají stejný počet tahů) a umožňuje porovnávat strategie mezi sebou při opakovaném hraní stovek her. Výstupem je srovnání úspěšnosti jednotlivých přístupů a doporučení vhodné herní taktiky.

=== Použití simulace ===
Simulace může sloužit:
* jako model rozhodování v nejistém prostředí,
* jako prostředek pro výuku agentového modelování (např. střední školy, informatika, psychologie rozhodování),
* pro zábavné testování, která strategie by přinesla nejvíc výher v reálné hře Farkle,
* jako výchozí kostra pro složitější modely s učením, adaptivními hráči nebo evoluční optimalizací strategie,
* a v neposlední řadě, jako "engine" na testování person pro mou diplomovou práci.

=== Použitá metoda a prostředí ===
Simulace je implementována v prostředí NetLogo jako dvouagentní tahový model. Hráči se střídají v házení 6 kostek, získávají body za kombinace podle pravidel Farkle (např. trojice, čtveřice, pětice, šestice, postupky) a rozhodují se, zda budou pokračovat v tahu.

Model zahrnuje:
* různé herní strategie („persony“) – definované jako rozhodovací pravidla podle skóre, zbývajících kostek nebo náhodného faktoru,
* počítání statistik (výhry, tahy, FARKLE chyby),
* zajištění férovosti – druhý hráč má vždy možnost dokončit poslední tah, pokud první dosáhne vítězného skóre,
* export výsledků a vykreslení průběhu skóre do grafu (a jiné statistické ukazetele).

=== Proměnné ===
Definované předem:
* Cílové skóre pro výhru (např. 10 000)
* Počet simulovaných her (např. 100 až 1000)
* Herní strategie pro oba hráče:
* conservative – ukládá body při ≥400
* risky – ukládá body při ≥700
* greedy – ukládá body při ≥1000
* cautious – hraje opatrně (≥300 nebo málo kostek)
* random – rozhoduje se náhodně
* risk-averse – hraje opatrně jen pokud vede o >2000 bodů, jinak jako conservative
* point-maximizer – pokračuje, dokud nedostane HOT DICE
* combo-hunter – pokračuje po silných kombinacích (postupky, trojice a víc)

Náhodné:
* Hod šesti kostkami (1–6)
* Kombinace, které hráči získají (např. 3 stejné, postupka 1–6 atd.)
* Výsledek rozhodnutí pokračovat/zastavit u náhodné strategie

Možná rozšíření simulace:
* Evoluční vývoj nových strategií (např. pomocí genetického algoritmu)
* Paměť hráčů – učení na základě předchozích neúspěchů
* Reakce na strategii soupeře (adaptivní persona)

=== Data ===
* [https://farkle.games/official-rules/] - oficiální pravidla hry Farkle
* [http://incompleteideas.net/book/the-book-2nd.html] - popis chování osob v pod tlakem a při riskování (persony)
* [https://mud.co.uk/richard/hcds.htm] - rozdělení person a chování v různých karetních a jiných hrách
* [http://incompleteideas.net/book/the-book-2nd.html] - o strategiích rozhodování, výběru akcí, riziku a odměnách

=== Simulant ===
Jan Hlavnička
[[User:hlaj13|hlaj13]] ([[User talk:hlaj13|talk]]) 13:58, 8 May 2025 (CET)

== Simulace: Simulace tučňáků hledajících lásku na ledové kře 🐧❤️ ==

=== Popis problému ===
Cílem simulace je modelovat chování tučňáků během námluv na ledové kře. Tučňáci musí najít vhodného partnera pro hnízdění, přičemž čelí různým vnějším vlivům – nestabilnímu prostředí (praskající led), konkurenci ostatních tučňáků a hrozbě predátorů (např. lachtani).

Každý tučňák má specifické nastavení chování – někteří jsou spíše plachého typu, jiní jsou odvážní a aktivně oslovují potenciální partnery. Odlišný přístup k seznamování ovlivňuje jejich šanci na úspěšné spárování a přežití do hnízdní sezóny.

=== Cíl simulace ===
Simulace se zaměří na otázku: Jaký „balící styl“ (strategie chování) vede k nejvyšší šanci na nalezení partnera a založení hnízda, a jak tuto šanci ovlivňuje prostředí a přítomnost rizik? Výsledkem bude doporučení nejefektivnějších „láskových taktik“ v závislosti na kontextu (bezpečné vs. nebezpečné prostředí).

=== Použití simulace ===
Simulace může sloužit:
* jako model sociální interakce v zábavné formě,
* jako edukativní nástroj pro představení agentového modelování (např. na středních školách),
* nebo jako metaforické přiblížení seznamovacích strategií ve složitém prostředí.

=== Použitá metoda a prostředí ===
Simulace bude vytvořena v prostředí NetLogo jako multiagentní model, kde každý agent (tučňák) bude reprezentovat jiný typ chování. Prostředí bude ledová kra se zónami různé stability a výskytu predátorů.

Tučňáci budou interagovat podle jednoduchých pravidel: přiblíží se k partnerovi, pokusí se o námluvy (s pravděpodobností úspěchu ovlivněnou vlastnostmi obou), a pak spolu odcházejí hnízdit (zmizí ze scény). Mohou být také ohroženi prasknutím kry nebo útokem predátora.

=== Proměnné ===
Definované předem:
* Počet tučňáků (např. 50–100)
* Stabilita ledu (pravděpodobnost prasknutí při stání na místě)
* Výskyt predátorů (pravděpodobnost útoku při pohybu)
* Rychlost pohybu a reakce

Typ chování:
* Plachý – čeká, až ho někdo osloví
* Odvážný – aktivně balí ostatní
* Kombinovaný – střídá strategie

Náhodné:
* Rozmístění tučňáků
* Výběr preferovaného partnera (náhodně nebo podle vlastností)
* Výsledek námluv (pravděpodobnost úspěchu podle kompatibility + typu chování)
* Prasknutí ledové kry
* Útok predátora

Možná rozšíření simulace:
* Přidání „charakterových“ rysů (krása peří, zpěv, taneční dovednosti)
* Učení – tučňák se poučí z neúspěchu a změní taktiku
* Sezónnost – časový limit na nalezení partnera (jinak simulace končí smutným singl koncem)

=== Data ===
* [https://www.reuters.com/business/environment/emperor-penguins-suffered-mass-breeding-failures-2023-amid-record-low-sea-ice-2024-04-25/ Stabilita mořského ledu a úspěšnost hnízdění
* [https://www.birdsnz.org.nz/wp-content/uploads/2021/12/Rowe_67_etal_451_459.pdf Úspěšnost hnízdění u tučňáků malých
* [https://www.selwomarina.es/en/blog/por-que-pinguinos-regalan-piedras-hembra?utm_.com Selwo Marina Benalmadena] – Článek věnující se námluvám a párování, kde popisují darování kamínků jako součást námluv
* BBC Earth, National Geographic, Attenboroughovy dokumenty – často dobře vysvětlují typy chování, interakce a přežívání. Např. March of the Penguins

=== Simulant ===
Zuzana Plachá
[[User:plaz03|plaz03]] ([[User talk:plaz03|talk]]) 20:20, 7 May 2025 (CET)

== Simulace: Simulace vojenské patroly a střetu s nepřítelem ==

=== Popis problému ===
Simulace se zabývá chováním malé vojenské jednotky (patroly), která operuje v nepřátelském teritoriu. Cílem patroly je bezpečný průchod zadanou trasou. V oblasti se ovšem mohou nacházet nepřátelské síly, které mají za úkol patrolu odhalit a zlikvidovat. Průběh mise ovlivňuje několik proměnných – velikost jednotky, dosah vidění, typ terénu, schopnost včasné reakce a počet a rozmístění nepřátel. Výsledky simulace umožní analyzovat účinnost různých taktik a rozhodovacích pravidel, které jednotka může použít při plnění mise. Zároveň mohou sloužit jako podpůrný nástroj při plánování operací nebo jako tréninková pomůcka pro rozhodování armády v rizikových situacích.

=== Cíl simulace ===
Simulace se bude věnovat zodpovězení otázky: jak různé faktory (velikost jednotky, rozmístění nepřátel, strategie pohybu) ovlivňují úspěšnost vojenské patroly při průchodu nebezpečným územím? Cílem je nalézt parametry a strategie, které vedou k nejvyšší pravděpodobnosti úspěšného dokončení mise bez ztrát. Výsledkem bude doporučení efektivních taktických rozhodnutí pro minimalizaci rizika při podobných operacích.

=== Použití simulace ===
Simulaci by mohli využít velitelé malých jednotek nebo vojenská akademie pro testování taktik v simulovaných prostředích. Model by jim dokázal vyhodnotit, jak různé strategie a složení jednotky ovlivňují šanci na úspěšné dokončení mise bez ztrát.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenti v modelu budou reprezentovat členy vojenské patroly a nepřátelské jednotky. Prostředí bude představovat mapu oblasti s různými typy terénu - otevřený terén, les, kryt apod.

=== Proměnné ===
Definované předem:
* Počet vojáků v patrole
* Počet nepřátel
* Typ terénu (např. podíl lesů, volného prostoru)
* Trasa patroly (předem definovaná nebo generovaná)
* Dosah vidění vojáků i nepřátel
* Pravidla reakce na kontakt (útěk, útok, přivolání podpory)
Pravděpodobnosti střetu a úspěchu jsou založeny na odhadech inspirovaných vojenskými taktickými příručkami a popisech reálných situací v článcích A-Report.

Náhodné:
* Rozmístění nepřátel v terénu
* Zpozorování nepřítele (pravděpodobnost, že jednotka zahlédne protivníka)
* Výsledek střetu (založen na pravděpodobnosti úspěchu v boji)
* Chování nepřítele (např. zda se ukryje nebo přepadne)

=== Data ===
* [https://mocr.mo.gov.cz/assets/informacni-servis/povinne-informace/1-uredni-deska/zakon-106/odp/priloha-c--1-1_25.pdf Základní řád ozbrojených sil České republiky] – řád armády ČR
* [https://mocr.mo.gov.cz/assets/multimedia-a-knihovna/casopisy/a-report/ar9_2018.pdf Časopis A-Report Útoku se nedalo zabránit] – Úryvek ze článku věnovaný osudové chybě v boji na Balkáně
* [https://mocr.mo.gov.cz/assets/multimedia-a-knihovna/casopisy/a-report/ar10_2019.pdf Časopis A-Report Pod ostrou palbou] – Úryvek ze článku popisující možnost simulací ve vojenském prostředí
* Vlastní odhady založené na realistických parametrech (např. efektivní dostřel, rychlost pohybu v terénu)

=== Simulant ===
Alexandr Sekera
[[User:seka01|seka01]] ([[User talk:seka01|talk]]) 15:33, 7 May 2025 (CET)

== Simulace: Kontrola jízdenek v MHD ==
=== Popis problému ===
Simulace se zabývá procesem kontrol jízdenek ve veřejné dopravě (např. v systému MHD v Praze). Veřejná doprava je financována částečně z příjmů z jízdného. Cestování "načerno" představuje pro dopravní podnik zdroj ztrát. Proto revizoři od podniku provádějí kontroly platnosti jízdních dokladů. Z toho vyplývá otázka, jak často a jakým způsobem mají být dané kontroly prováděny, aby byly efektivní a ekonomicky dávaly smysl. Výsledky simulace umožní řízení MHD optimalizovat frekvenci kontrol, počet revizorů a tím zvýšit celkovou efektivitu inspekcí.

=== Cíl simulace ===
Simulace se bude věnovat zodpovězení otázky: jak ovlivňuje četnost kontrol objem vybraných pokut ve veřejné dopravě? Výsledkem bude doporučení efektivních inspekčních strategií pro maximalizaci vybraných pokut. Simulace také ukáže, kolik revizorů je potřeba pro dosažení požadované míry kontroly.

=== Použitá metoda a prostředí ===
Multiagentní simulace v Netlogo. Agenti v modelu budou reprezentovat pasažéry a revizory.

=== Proměnné ===
Definované předem:
* Počet cestujících (celkově)
* Počet revizorů
* Výše pokuty (standardní nebo menší za platbu okamžitě)
* Frekvence kontrol (počet provedených kontrol za minutu/hodinu)
* Kapacita vozidla (počet cestujících z celkového čísla, kteří jsou aktuálně v kontrolovaném prostoru)

Náhodné:
* Platnost jízdenky (zda jede pasažér "načerno")
* Zachycení černého pasažéra (zda je neplatnost jízdenky odhalena)
* Zaplacení pokuty (hned či později)

=== Data ===
[https://www.dpp.cz/jizdne/pokuty-revizori/vyse-prirazky DPP - pokuty a revizoři] - výše jednotlivých pokut

[https://www.dpp.cz/vozovy-park DPP - vozový park] - kapacity vozidel

[https://www.expats.cz/czech-news/article/prague-public-transport-inspectors-handed-out-250-000-fines-last-year Prague public transport inspectors handed out 250,000 fines last year] - počty kontrol, pasažérů a revizorů, celková výše pokut, zaplacení pokut

Míra cestování "načerno" pro Prahu není zveřejněna oficiálně. Pro odhad poměru černých pasažérů se lze inspirovat jinými státy ([https://theweek.com/transport/fare-dodging-londons-transport-blight UK], [https://www.trainsfare.eu/tackling-fare-evasion-in-bergamo-a-growing-challenge-for-atb-and-teb/ IT]).

=== Simulant ===
Vladislav Sanin
[[User:Sanv05|Sanv05]] ([[User talk:Sanv05|talk]]) 21:15, 6 May 2025 (CET)

== Simulace: Pavlovovo podmiňování v agentním modelu ==
=== Co budu simulovat ===
Simulace bude modelovat proces klasického (Pavlovova) podmiňování, kdy agent (představující psa) postupně spojuje neutrální podnět (zvonek) s přirozeným podnětem (jídlo). Výsledkem je, že agent začne reagovat podmíněnou reakcí (slinění) i v případě, že se později objeví pouze zvonek bez jídla.

=== Cíl simulace ===
Cílem simulace je analyzovat průběh učení podmíněné reakce a zjistit:
* kolik opakování je potřeba k vytvoření podmíněné reakce,
* jak stabilní tato reakce je v čase,
* jak rychle dochází k vyhasnutí reakce (extinkci) při absenci posílení,
* jak efektivní je opětovné učení (re-learning) po ztrátě reakce.

Obecně jde o pochopení mechanismů formování návyků a chování založeného na stimulaci a posilování.

=== Kdo by takovou simulaci mohl využít a jak by mu pomohla ===
Simulaci mohou využít například:
* psychologové zabývající se behaviorálním učením,
* učitelé při výuce základních principů behaviorismu,
* vývojáři agentních a AI modelů, kteří chtějí simulovat jednoduché učení nebo formování návyků.

Simulace jim umožní vizuálně a experimentálně sledovat proces klasického podmiňování a analyzovat vliv různých parametrů na průběh učení.

=== Použitá metoda a prostředí ===
* '''Metoda''': Agentní simulace využívající jednoduchý model chování se stavovým automatem. Agent mění svůj vnitřní stav v závislosti na podnětech a historii posilování.
* '''Prostředí''': NetLogo

=== Jaké proměnné budou v simulaci ===
* Počet pokusů o podmiňování
* Zpoždění mezi zvonkem a jídlem (časování podnětů)
* Frekvence posilování (např. 100 %, 75 %, 50 % případů s jídlem)
* Síla podmíněné reakce (vnitřní proměnná zvyšující se učením)
* Počet extinkčních pokusů (zvonek bez jídla)

=== Jaké proměnné budou náhodné ===
* Pravděpodobnost, zda po zvonku následuje jídlo (při částečném posilování)
* Malá náhodná odchylka v chování psa (např. reakční doba, úroveň slinění)

=== Na jakých datech budou proměnné založené ===
* Parametry vycházejí z publikovaných výsledků klasických experimentů Pavlova a dalších behaviorálních studií.
* Typické hodnoty časování a pravděpodobností pro různé typy posilování vychází z odborné literatury.
* Síla reakce bude modelována pomocí logistické funkce, která simuluje typickou křivku učení a vyhasínání reakce.
* [https://www.psychologywizard.net/uploads/2/6/6/4/26640833/pavlov_lecture_18.pdf Pavlov – Lecture 18 (Conditioned Reflexes, 1927)]
* [https://en.wikipedia.org/wiki/Classical_conditioning Wikipedia – Classical Conditioning]
* [https://www.simplypsychology.org/pavlov.html Simply Psychology – Pavlov’s Dogs]

=== Na jakých datech jsou založeny vzorce v simulaci (chování modelu) ===
Chování modelu bude založeno na Rescorla-Wagnerově modelu klasického podmiňování, který kvantifikuje změnu síly asociace mezi podmíněným podnětem a nepodmíněným podnětem během jednotlivých pokusů.
* [https://www.vcalc.com/wiki/rescorla-wagner-formula-alpha-and-beta-version vCalc – Rescorla-Wagner model (alpha and beta version)]
* [https://en.wikipedia.org/wiki/Rescorla%E2%80%93Wagner_model Wikipedia – Rescorla–Wagner model]

=== Simulant ===
[[User:Lans06|Lans06]] ([[User talk:Lans06|talk]]) 22:27, 6 May 2025 (CET)

== Simulace: Bitva u Azincourtu v roce 1415 (Anglie vs Francie během Stoleté války) ==

=== Popis problému ===
V roce 1415 stála Anglie v čele se svým králem Jindřichem V. proti silám Francie, které měly velmi drtivou převahu (Anglie cca 8500 a Francie cca 15 000). I přes tuto nevýhodu dokázala Anglie vyhrát s nepatrnými ztrátami. Dle historických pramenů to bylo především díky strategickému umístění anglického vojska v úzkém prostoru mezi stromy, kde nemohly francouzské jednotky přímo naběhnout a využít drtivou sílu svých počtů bojovníků - musely postavit více řad bojovníků za sebou a nemohly anglické jednotky obklopit.

=== Cíl simulace ===
Simulace se bude věnovat otázce: Měla by Francie šanci vyhrát bitvu, kdyby se bitva odehrávala na širokém prostranství narozdíl od úzkého prostoru? Nebo by stále Anglie dokázala vyhrát, kdyby přišla o výhodu okolí?

=== Použití simulace ===
Simulace může sloužit:
* historikům - náhled do historie, kdyby měla bitva jiný průběh
* Úvaha nad historickou událostí, která ovlivnila Stoletou válku

=== Cíl simulace ===
* dokázat, jak terén může ovlivnit průběh bitvy, pokud je stanovena správná strategie
* změní se průběh bitvy a dokáže Francie vyhrát?
* jak moc účinné je zbraň Long Bow (dlouhý luk) v otevřeném terénu?

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo, kde agenti budou jednotky Anglie (pěšáci, střelci s Long Bow) a Francie (pěšáci, kavalérie, střelci s Long Bow, střelci s kuší).

=== Proměnné v simulaci ===
Definované předem:
* počet a rozložení jednotek anglické armády
* počet a rozložení jednotek francouzské armády

Náhodné
* pohyb jednotek (každá jednotka má své reakce a možnosti pohybu)
* střelba z Long Bow - kolik zvládne vystřelit šípů za určitý čas

=== Data ===
* https://www.stoplusjednicka.cz/bitva-u-azincourtu-stret-ktery-rozhodl-nekonecnou-valku-mezi-anglii-francii
* https://zoom.iprima.cz/historie/bitva-u-azincourtu
* vlastní poznatky z rekonstrukcí bitev

=== Simulant ===
[[User:Bilk08|Bilk08]] ([[User talk:Bilk08|talk]]) 12:00, 12 May 2025 (CET)

== Simulace: Phishing na hybridním pracovišti ==

=== Popis problému ===
Práce bude zkoumat roli hybridního (onsite & remote) pracoviště na pravděpodobnsot úspěšného phishing útoku.
Remote zaměstnanci méně komunikují, než jejich onsite kolegové, což snižuje pravděpodobnost, že o podezřelém emailu někomu řeknou nebo u stolu jen prohlásí "to je divný" nebo "taky jsi dostal tenhle trenink do zitra?".
Simulace bude uvažovat, že ne každý zaměstnanec má přístup ke kritickým systémům, jen někteří mohou způsobit firmě vážné škody, ale pokud se tak stane, následky jsou velké.

=== Cíl simulace ===
Simulace má za cíl zjistit, jaké budou škody s různými konfiguracemi onsite vs. remote zaměstnanců.

=== Kdo by takovou simulaci mohl využít a jak by mu pomohla ===
Jakákoli korporát/firma s kombinací onsite a remote zaměstnanců (populární po pandemii)

=== Použitá metoda a prostředí ===
*Metoda: Multi-agentní simulace
*Prostředí: NetLogo

=== Jaké proměnné budou v simulaci ===
*Deterministické:
**Socializace (např. oběd)
**Délka sprintu (ke konci sprintu klesá pozornost, roste zbrklost)
**Počet zaměstnanců s kritickými přístupy
**Počet onsite zaměstnanců
**Počet remote zamšstnanců
**Intervaly mezi interními phishing testy IT oddělení

*Náhodné:
**Četnost phishing útoků
**Základní pravděpodobnost naletění na phishing
**Pravděpodobnost naletění po školení (efekt se bude s časem od školení snižovat)
**Pravděpodobnost naletění po úspěšném útoku
**Remote & onsite pravděpodobnost komunikace (při odhalení phishingu)
**Ztráta způsobená úspěšným phishingovým útokem bez kritických přístupů
**Ztráta způsobená úspěšným phishingovým útokem s kritickými přístupy

=== Data ===
*Vědecké články (např. psychologické studie na efekt o interních phishing testech, jak zvyšuje pracovní nápor pravděpodobnost naletění)
*Phishingové statistiky (např. četnost, úspěšnost, severita)

=== Simulant ===
[[User:Lebm05|Lebm05]] ([[User talk:Lebm05|talk]]) 12:59, 12 May 2025 (CET)

== Simulace: Obsazenost akutních lůžek v českých nemocnicích ==

=== Popis problému ===
České nemocnice disponují v průměru 4,6 akutními lůžky na 1 000 obyvatel. Při průměrné ošetřovací době, která teď činí 5,5 dne, dochází k fluktuacím mezi novými přijetími pacientů, obsazeným počtem lůžek a propouštěním pacientů. Při obsazenosti vyšší než 85 %, kvalita péče klesá, prodlužují se čekací doby a zvyšuje se riziko komplikací a nozokomiálních infekcí.

Simulace bude odhadovat vývoj obsazenosti akutních lůžek v čase a vyhodnotí dopad různých intervencí (zkrácení průměrné ošetřovací doby, navýšení kapacity, řízení fronty).

Výsledky simulace ukážou, která opatření nejvíce snižují riziko dlouhodobé obsazenosti nad 85 %, kdy už dochází k prodlužování čekacích dob a nárůstu infekcí; také mohou sloužit jako podpora rozhodování o investicích a rozdělení rozpočtu.

=== Cíl simulace ===
Cílem simulace je zodpovědět na otázku, do jaké míry a jak rychle udržení obsazenosti pod 85 % ovlivní faktory jako:
* Snížení průměrné ošetřovací doby o 10 %
* Navýšení kapacity o 10 %
* Řízená fronta (prioritizace)
Ve všech scénářích budu sledovat průměrnou denní obsazenost lůžek, maximální délku fronty, a čas, za který obsazenost překročí nebo zůstane pod hranicí 85 %.

=== Použití simulace ===
Kdo může simulaci použít?
Simulace umožní vedení zdravotnických zařízení a manažérům identifikovat dlouhodobé rizikové body v lůžkové kapacitě a následně je mohou využít k optimalizaci strategických investic tak, aby udrželi kontinuitu péče a finanční udržitelnost i při demografických změnách či neočekávaných vlnách poptávky. Díky simulaci mohou předem ověřit dopad různých politik (např. zkrácení průměrné ošetřovací doby, rozšíření kapacity, prioritizace příjmu) a na základě toho nastavit robustní krizové plány a alokaci zdrojů.

=== Použitá metoda a prostředí ===
Pro tvorbu simulace využit přístup Systémové dynamiky a nástroj Vensim PLE.

=== Proměnné ===
* Počet obyvatel
* Počet hospitalizovaných pacientů (akutní lůžka)
* Počet nově hospitalizovaných pacientů
* Počet propuštěných pacientů
* Průměrná délka hospitalizace
* Míra propuštění
* Průměrné denní množství nových žádostí o hospitalizaci
* Míra hospitalizace
* Celkový počet akutních lůžek
* Míra navýšení kapacity při obsazenosti větší než 85 %
* Počet volných lůžek
* Obsazenost lůžek

=== Data ===
* Počet obyvatel v ČR. [https://vdb.czso.cz/vdbvo2/faces/cs/index.jsf?page=vystup-objekt&pvo=DEM13&z=T&f=TABULKA&skupId=3829&katalog=33155&pvo=DEM13&evo=v141_!_IK-CR-K_1&c=v3~8__RP2021]
* Zdravotní péče České republiky. [https://csu.gov.cz/zdravotni-pece#:~:text=2016%202017%202018%202019%202020,548%209%20960%209%20996]
* Zdravotnická ročenka České republiky. [https://www.uzis.cz/index.php?pg=aktuality&aid=8560]
* Hospitalizace v nemocnicích ČR. [https://www.uzis.cz/index.php?pg=vystupy--vyznamna-temata--hospitalizace ]
* Pohyb obyvatelstva - rok 2021. [https://csu.gov.cz/rychle-informace/pohyb-obyvatelstva-rok-2021#:~:text=Podle%20výsledků%20sčítání%20lidu%2C%20domů,Štyglerová%2C%20vedoucí%20oddělení%20demografické%20statistiky]

=== Simulant ===
[[User:Kozo01|Olesia Kozlova (kozo01)]] ([[User talk:kozo01|talk]]) 16:07, 12 May 2025 (CET)

:: '''Schváleno'''[[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 20:45, 12 May 2025 (CET)

== Simulace: Eutrofizace vodní plochy ==

=== Popis problému ===
Eutrofizace vodních ploch je přírodní jev, který může být výrazně ovlivněn antropogenní činností. Jedná se zejména o jednotlivé chemické pochody, které způsobují nárůst biomasy na hladině vodní plochy. Díky tomuto růstu dochází k postupnému snižování světelných podmínek pod úrovní hladiny, což způsobuje úhyn biomasy a dochází k zvýšení rozkladných procesů, které zapříčiňují úbytek kyslíku v celé vodní nádrži. Následkem toho dochází i k úhynu vodních živočichů závislých na koncentraci kyslíku pod hladinou.

=== Cíl simulace ===
Cílem simulace je namodelovat celý proces eutrofizace, který bude ovlivněn antropogenní činností (např. splachy z polí). Zodpoví jednu z důležitých otázek: Jak antropogenní činnost urychluje eutrofizaci.

=== Použití simulace ===
* Simulace může být využita k akademickému studiu eutrofizace,
* jako podpora při legislativních rozhodnutí,
* může vylepšit strategické plánování ve vodohospodářských organizacích, nebo
* strategické plánování zemědělců.

=== Použitá metoda a prostředí ===
* Simulace využívá program Vensim, který byl vybrán na základě jeho schopnosti namodelovat toky a vazby mezi jednotlivými proměnnými ve sledovaném prostředí.

=== Proměnné ===
* Definované předem:
** úroveň eutrofizace,
** počáteční množství biomasy,
** počáteční množství živočichů,
** počáteční pH vody,
** počáteční obsah kyslíku.

* Náhodné:
** počasí,
** zalévání zemědělských ploch.

Popřípadě další.

=== Data ===
* YANG, Xiao-e, Xiang WU, Hu-lin HAO a Zhen-li HE, 2008. Mechanisms and assessment of water eutrophication. Journal of Zhejiang University. Science. B [online]. 9(3), 197–209. ISSN 1673-1581. Dostupné z: doi:[https://doi.org/10.1631/jzus.B0710626 10.1631/jzus.B0710626]

=== Simulant ===
[[User:bene08|Eliška Benešová (bene08)]] ([[User talk:bene08|talk]]) 16:07, 12 May 2025 (CET)

:: '''Schváleno''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 20:50, 12 May 2025 (CET)

== Simulace: Simulace průchodu cestujících pasovou kontrolou na letišti ==

=== Popis problému ===
Letiště v době dopravní špičky čelí problémům s kapacitou pasové kontroly. Nedostatečný počet otevřených přepážek vede k dlouhým frontám a nespokojenosti cestujících. Naopak příliš mnoho otevřených přepážek může znamenat neefektivní využití personálu. Proto je potřeba najít rovnováhu mezi těmito dvěma faktory.

=== Cíl simulace ===
Cílem simulace je analyzovat vliv počtu otevřených přepážek na délku fronty a maximální čekací dobu cestujících. Jedním z hlavních cílů je identifikovat maximální čekací dobu v případech, kdy nejsou otevřeny všechny dostupné přepážky, a navrhnout optimální počet přepážek pro různé scénáře zatížení.

=== Použití simulace ===
Simulaci může využít letištní management, konkrétně vedoucí směny nebo plánovači personálu, kteří rozhodují o počtu aktivních pracovníků v jednotlivých časových intervalech. Pomůže jim lépe plánovat směny a optimalizovat provoz pasové kontroly tak, aby se předešlo zbytečným zpožděním i plýtvání lidskými zdroji.

=== Použitá metoda a prostředí ===
Použiji agentní simulaci v jazyce Rust, s využitím open-source herního enginu Bevy (verze 0.13) jako vizuálního a simulačního prostředí. Každý cestující bude modelován jako agent, který dorazí, čeká ve frontě, a je odbaven u přepážky podle pravidel fronty (FIFO). Přepážky budou reprezentovány jako paralelní servery.

=== Proměnné ===

Deterministické proměnné:

*Počet otevřených přepážek
*Reálný rozvrh příletů letadel
*Počet cestujících vystupujících z každého příletu (interval 5 minut)

Náhodné proměnné:

*Interval mezi příchody cestujících (exponenciální rozdělení)
*Doba odbavení u přepážky (normální rozdělení)
*Rychlost přechodu cestujících od gate k pasové kontrole

Měřené výstupy:

*Průměrná čekací doba
*Maximální čekací doba
*Využití jednotlivých přepážek v %
*Délka fronty v čase

=== Data ===

Průměrná doba odbavení: Na základě interních dat z provozu pasové kontroly letiště.

Intenzita příchozích cestujících: Data získáná z každodenního leteckého provozu mimo sezónu a v sezóně (červen - září)

=== Simulant ===
[[User:Papd01|Papd01]] ([[User talk:Papd01|talk]]) 17:25, 12 May 2025 (CET)

== Simulace: Autobusová linka v městské dopravě ==

=== Popis problému ===
Simulace se zabývá provozem autobusové linky v městské dopravě. Veřejná doprava je klíčová pro fungování měst a efektivní provoz autobusových linek zajišťuje dostupnost a komfort pro cestující. V praxi dochází k problémům, jako je přetížení spojů během špičky, zpoždění, dlouhé čekací doby na zastávkách nebo nevyužité kapacity mimo špičku. Simulace umožní analyzovat, jak různé faktory (například počet autobusů, intervaly mezi spoji, kapacita vozidel nebo rozložení cestujících během dne) ovlivňují kvalitu přepravy a vytížení linky. Výsledky simulace mohou pomoci dopravcům optimalizovat jízdní řády a nasazení vozidel.

=== Cíl simulace ===
Cílem simulace je zjistit, jak různé parametry provozu autobusové linky ovlivňují:
* průměrnou dobu čekání cestujících na zastávce,
* naplněnost autobusů v různých částech trasy a v různých časech,
* identifikaci kritických zastávek s přetížením,
* doporučení pro optimalizaci jízdního řádu a kapacity linky.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenty v modelu budou reprezentovat autobusy, cestující a zastávky.

=== Proměnné ===
Definované předem:
* Počet autobusů na lince
* Kapacita jednoho autobusu
* Počet zastávek a jejich rozložení na trase
* Interval mezi odjezdy autobusů
* Délka trasy a čas potřebný k projetí celé linky

Náhodné:
* Počet cestujících přicházejících na jednotlivé zastávky v čase (modeluje špičku/mimo špičku)
* Cílová zastávka každého cestujícího (kde vystupuje)
* Doba nástupu a výstupu cestujících

=== Data ===
* [https://www.dpp.cz/vozovy-park DPP – vozový park] – kapacity autobusů, typy vozidel
* [https://pid.cz/jizdni-rady-podle-linek/ PID – jízdní řády autobusů] – intervaly a rozložení spojů
* [https://www.dpp.cz/spolecnost/o-spolecnosti/dpp-v-datech DPP – statistiky] – počty cestujících, vytížení linek

Pro modelování rozložení cestujících v čase lze vycházet z běžných statistik dopravních podniků nebo využít odhadů podle typu linky (městská, příměstská, školní apod.).

=== Simulant ===
[[User:jelp05|jelp05]] ([[User talk:jelp05|talk]]) 18:35, 12 May 2025 (CET)

== Simulace: Šíření invazních druhů rostlin v krajině ==

=== Popis problému ===
Invazní rostliny představují závažný ekologický problém, který ohrožuje biodiverzitu, mění dynamiku ekosystémů a může způsobovat výrazné ekonomické škody. Přestože existují různé metody jejich potlačení, jejich účinnost se liší podle situace a podmínek v dané oblasti. Vzhledem k tomu, že přímé testování zásahů v reálném prostředí je nákladné a obtížně opakovatelné, bude v této práci navržena simulace, která umožní predikci vývoje a porovnání efektivity různých zásahových strategií.

=== Cíl simulace ===
Simulace bude navržena s cílem modelovat a analyzovat dynamiku šíření vybraných invazních rostlinných druhů v různých typech krajiny. Bude zohledňovat klíčové faktory ovlivňující rozšiřování – jako jsou podmínky prostředí (vlhkost, teplota, typ půdy), biologické vlastnosti rostlin (rychlost růstu, produkce a klíčivost semen) a způsoby šíření (např. pomocí větru, vody nebo lidské činnosti). Součástí modelu bude také testování různých zásahových strategií, jako je mechanická likvidace, aplikace herbicidů nebo jejich kombinace

=== Použití simulace ===
Výsledky simulace poskytnou náhled na chování invazních druhů v čase a prostoru a umožní testovat zásahy bez přímého zásahu do reálného ekosystému. Simulace bude sloužit jako nástroj pro podporu rozhodování v oblasti ochrany přírody, krajinného plánování a managementu invazních druhů. Výstupy bude možné využít například ochranářskými organizacemi nebo správci chráněných území pro návrh efektivních a šetrných zásahových postupů.

=== Použitá metoda a prostředí ===
Prostředí: NetLogo (agentní modelování)

=== Proměnné ===
Deterministické proměnné:
* Biologické vlastnosti rostlin (rychlost růstu, počet a klíčivost semen, vegetační cyklus)
* Podmínky prostředí (vlhkost, teplota, typ půdy)
* Strategické zásahy (mechanické odstraňování, chemická likvidace, kombinace metod)
* Typ krajiny (pole, louka, les, urbanizované prostředí)

Náhodné proměnné:
* Směr a dosah šíření semen
* Počáteční rozmístění rostlin
* Vliv náhodných klimatických odchylek

=== Data ===
Data pro model budou získána z databáze Agentury ochrany přírody a krajiny ČR (https://invaznidruhy.nature.cz), která poskytuje podrobné informace o biologických a ekologických vlastnostech jednotlivých invazních druhů. Další poznatky budou čerpány z odborné literatury a metodických doporučení pro boj s invazními rostlinami.

=== Simulant ===
[[User:kala13|kala13]] ([[User talk:kala13|talk]]) 19:54, 12 May 2025 (CET)

Assignment SS 2024/2025/cs

2025-05-12T20:20:58Z

Hrus07: Přidání témata simulace: Dynamika technického dluhu v softwarovém vývoji

{{Ambox
| text = <div>
Please, put here your assignments. Do not forget to sign them. You can use <nowiki>~~~~</nowiki> (four tildas) for an automatic signature. Use Show preview in order to check the result before your final sumbition.
</div>
}}

{{Ambox
| text = <div>
Please, strive to formulate your assignment carefully. We expect an adequate effort to formulate the assignment as it is your semestral paper. Do not forget that your main goal is a research paper. It means your simulation model must generate the results that are specific, measurable and verifiable. Think twice how you will develop your model, which entities you will use, draw a model diagram, consider what you will measure. No sooner than when you have a good idea about the model, submit your assignment. And of course, read [[How to deal with the simulation assignment|How to deal with the simulation assignment]].
</div>
}}

{{Ambox
| text = <div>
Topics on gambling, cards, etc. are not welcome.
</div>
}}

{{Ambox
| type = content
| text = <div>
In order to avoid possible confusion, please, check if you have added '''approved''' in bold somewhere in our comment under your submission. If there is no '''approved''', it means the assignment was not approved yet.
</div>
}}

{{Ambox
| text = <div>
'''Criteria for evaluation of the simulation proposal'''

The proposal must contain:
*What you will simulate
*The goal of the simulation (what you analyze - i.e. not "to simulate balloon factory", but what problem should the simulation solve).
*Who would actually use such simulation (example of such user) and how would it help him
*What method and simulation environment you plan to use. Choose only from the development environments that we have used in the course.
*What variables will be incorporated
*What variables will be random
*What exact data you will base values of your variables on
*(In case of Monte Carlo) What exact data you will base your determination of probability distribution of your random variables on
*What exact data you will base your formulas in the simulation (simulation behavior) on

'''If any of the above points are missing from the simulation proposal, the proposal is considered incomplete. Unless the proposal contains all of the above points it will not be evaluated at all (and therefore cannot be approved).'''

# Is it clear from the proposed assignment how the simulation will work?
# Does the simulation make sense?
# Is the simulation model complex enough to simulate credibly the real-world phenomenon that the simulation tries to simulate?
# Is the data used real and relevant for the real-world phenomenon that the simulation tries to simulate?
# Is the simulation feasible? (in given time by the course)

'''If the answer to any of the above points is no, you need to improve your proposal. Don't wait for us to tell you so - you're wasting your time.'''

</div>
}}

== Simulace: Dynamika technického dluhu v softwarovém vývoji ==

=== Popis problému ===
Technický dluh v softwarovém vývoji vzniká, je a taky i bude. Jedním z důvodu vzniku je tlak na rychlost dodání, zvolení suboptimálního řešení nebo zkratky pro usnadnění práce. Tento dluh se hromadí v kódové bázi a systému a chová se podobně jako finanční dluh – s "úroky" v podobě zvýšeného úsilí na budoucí údržbu, opravy chyb ale i implementaci nových funkcí. Akumulovaný dluh tak postupně zpomaluje vývojový tým, snižuje agilitu projektu a zvyšuje celkové dlouhodobé náklady pro celou firmu.

=== Cíl simulace ===
Simulace si dává za úkol namodelovat dynamiku akumulace dluhu a jeho splácení v čase. Jaký ma vliv na produktivitu. Ale hlavně jaké různé strategie řízení dluhu jsou dlouhodobě nejefektivnejší.

=== Použití simulace ===
* Jako podpora při rozhodování projektových manažerů o prioritách (rychlost vs. kvalita).
* Může pomoci stakeholderům pochopit náklady a přínosy investic do kvality kódu (argumenty pro CIO).
* Pro strategické plánování v IT organizacích týkající se údržby a rozvoje systémů.

=== Použitá metoda a prostředí ===
* Simulace využívá metodu systémové dynamiky (System Dynamics).
* Bude použit program Vensim.

=== Proměnné ===
Definované předem:
* Počáteční úroveň technického dluhu.
* Počáteční rozsah backlogu (nesplněných požadavků).
* Velikost týmu.
* Základní produktivita týmu (bez vlivu dluhu).
* Míra alokace času na refaktoring (strategické rozhodnutí).

Náhodné:
* Tempo příchodu nových požadavků do backlogu.
* Efektivita refaktorovacích snah (malé fluktuace).
* Výskyt neočekávaných problémů vedoucích k tvorbě dluhu (např. kritické chyby).

Popřípadě další.

=== Data ===
* Produkční data budou ťežko získatelné, proto využijeme kombinaci odhadu expertů z praxe a odbornou literaturu.

* GUPTA, Kartik, 2025. Measuring the Impact of Technical Debt on Development Effort in Software Projects. arXiv [online]. [cit. 2025-05-12]. Dostupné z: https://arxiv.org/abs/2502.16277
* YLI-HUUMO, Jesse, Andrey MAGLYAS a Kari SMOLANDER, 2016. How do software development teams manage technical debt? – An empirical study. Dostupné z: doi:https://doi.org/10.1016/j.jss.2016.05.018
* TOM, Edith, Aybüke AURUM a Richard VIDGEN, 2013. An exploration of technical debt. Journal of Systems and Software. 86(6), 1498–1516. Dostupné z: doi:https://doi.org/10.1016/j.jss.2012.12.052
* HOLVITIE, Johannes, Sherlock A. LICORISH, Rodrigo O. SPÍNOLA, Sami HYRYNSALMI, Stephen G. MACDONELL, Thiago S. MENDES, Jim BUCHAN a Ville LEPPÄNEN, 2018. Technical debt and agile software development practices and processes: An industry practitioner survey. Information and Software Technology. 96, 141–160. Dostupné z: doi:https://doi.org/10.1016/j.infsof.2017.11.015

=== Simulant ===
[[User:Hrus07|Hrus07]] ([[User talk:Hrus07|talk]]) 22:19, 12 May 2025 (CET)

== Simulace: Útoky medvědů ==

=== Popis problému ===
Na Slovensku se vyskytuje velké množství medvědů, kteří ohrožují tamní obyvatele a turisty. Útoky jsou momentálně velmi časté a přibývají. Slovenská vláda schválila návrh na odstřel cca 350 jedinců. Zároveň se jedná o chráněný druh, tudíž počty by neměly být redukovány ve velké míře, ne-li vůbec.

=== Cíl simulace ===
Cílem bude simulovat ideální počet medvědů, aby se minimalizoval počet útoků medvěda a potřeba redukovat počet medvědů.

=== Použití simulace ===
* Např. pro plánování odstřelu medvědů, aby druh nebyl příliš ohrožen.
* Simulace chování medvědů v přírodě.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenti budou medvědi, turisti a lovci. V prostředí se populace medvědů bude přirozeně zvyšovat. Turisté mají šanci na útěk. Lovci budou reagovat na incidenty medvědů s turisty.

=== Proměnné ===
Definované předem:
* Medvědi – pohybují se po krajině, hledají potravu a případně útočí na turisty
* Lovci – redukují počty medvědů na základě útoků a ohrožení turistů.
* Turisti – objevují tamní krajinu a lesy. Reagují na přítomnost medvědů.

Náhodné:
* Rozmístění medvědů, lovců a turistů.
* Rozmístění vegetace, lesů.

=== Data ===
* Slovenská vláda schválila odstřel medvědů [https://www.irozhlas.cz/zpravy-svet/nemuzeme-zit-v-zemi-kde-se-lide-boji-chodit-do-lesa-slovenska-vlada-schvalila_2504021255_mst]
* Medvěd hnědý - biotop a teritorium [https://www.selmy.cz/medved/biotop-a-teritorium/]
* Medvěd na Slovensku [https://sita.sk/nasvidiek/kolko-medvedov-zije-na-slovensku-studia-ukazala-cisla-a-najviac-ich-je-na-polane/?utm_source=chatgpt.com]

=== Simulant ===
[[User:Vlcj07|Vlcj07]] ([[User talk:Vlcj07|talk]]) 19:43, 12 May 2025 (CET)

== Simulace: Přemnožení divokých prasat ==

=== Popis problému ===
Divoká prasata jsou v České republice přemnožená – na našem území jich je v současnoti 100krát více, než je únosné. Přemnožení je zapříčeněno několika faktory. Prvním je způsob rozmnožování divokých prasat. Bachyně mívají dva vrhy ročně, přičemž v každém vrhu se vyskytuje průměrně 4-12 selat. Při přebytku potravy tak populace divokých prasat prudce roste. Druhý faktor, který zapříčiňuje přemnožení prasat, je absence přirozených predátorů těchto zvířat na našem území. Kontrolu populace pak musejí provádět myslivci, nicméně odtřel je v současné době nedostatečný.

Přemnožená prasata mají negativní dopad na vegetaci svého okolí. Jedná se například o rostlinu bleduli letní, která se v České republice řadí mezi zvláště chráněné druhy rostlin.

=== Cíl simulace ===
Cílem simulace bude simulovat ideální míru odstřelu divokých prasat, aby nedošlo ke zničení vzácné vegetace (jako je například bledule letní). V simulaci bude zobrazena součinnost několika faktorů (růst prasečí populace v závislosti na přítomnosti potravy, množství střelců nutných pro udržení populace na uzdě apod.).

=== Použití simulace ===
Kdo může simulaci použít?
* Myslivci pro informovanější plánování odstřelu prasat.
* Lesní správa, farmářský a zahradnický průmysl apod. – všechna tato odvětví jsou negativně ovlivněná přemnoženou prasečí populací.
* Simulace může problematiku přiblížit i širší veřejnosti, která tak bude lépe schopná seznat její závažnost.

=== Použitá metoda a prostředí ===
Prostředím multiagentní simulace bude NetLogo. Agenti budou divoká prasata, myslivci a vzácná vegetace. Prasata se budou množit rychlostí závislou na množství vegetace. Model bude simulovat různé počty myslivců a různé strategie střelby. Množství vegetace bude závislé na velikosti prasečí populace.

=== Proměnné ===
Definované předem:
* Rychlost množení a „žravost“ divokých prasat.
* Rychlost obnovy vegetace.
* Počet myslivců a strategie a způsob jejich odstřelování prasat.

Náhodné:
* Počáteční populace prasat (v určitém rozmezí).
* Počáteční množství vegetace (opět v určitém rozmezí).
* Rozmístění prasat.
* Rozmístění myslivců.
* Rozmístění vegetace.

=== Data ===
* Prasata devastují vzácnou zeleň. [https://benesovsky.denik.cz/zpravy_region/premnozena-prasata-pustosi-benesovsko-mizi-bledule-i-orchideje-20250318.html]
* Způsob rozmnožování divokých prasat. [https://www.hubeni-skudcu.cz/blog/prase-divoke/]
* Policejní odstřel divokých prasat. [https://www.idnes.cz/liberec/zpravy/odstrel-divocaku-praseci-mor-liberec-jablonec-myslivci-policie.A241212_140610_liberec-zpravy_cink]
* Prase divoké – základní informace. [https://www.kdelovit.cz/cz/lovna-zver/srstnata/prase-divoke]
* Životní cyklus divokých prasat. [https://cit.vfu.cz/pohoda/zivotni_cyklus.pdf]
* Lov divokého prasete. [https://huntasticzech.cz/zvire/prase-divoke/]

=== Simulant ===
[[User:Kalp08|Petr Kalina (kalp08)]] ([[User talk:Kalp08|talk]]) 13:52, 12 May 2025 (CET)

== Simulace: Šíření dezinformací na sociálních sítích ==

=== Popis problému ===
Simulace modeluje šíření dezinformace mezi uživateli sociální sítě. V dnešním digitálním prostoru jsou informace často sdíleny bez jejich ověřování, což přispívá k rychlému rozšiřování nepravdivých nebo manipulativních zpráv. Sociální sítě jsou hlavním kanálem pro šíření jak pravdivých, tak nepravdivých informací. Model zkoumá, jak rychle a do jaké míry se dezinformace rozšíří napříč sítí uživatelů, kteří jsou mezi sebou propojeni pomocí přátelství nebo sledujících. Ovlivňujícími faktory jsou zejména míra ochoty sdílet, schopnost rozpoznat nepravdivý obsah, struktura sítě (např. počet spojení) a chování jednotlivců. Cílem je porozumět tomu, jaké strategie mohou šíření zpomalit či omezit a jak síťová struktura ovlivňuje zranitelnost vůči dezinformacím.

=== Cíl simulace ===
Cílem simulace je odpovědět na otázku: jak ovlivňuje struktura sociální sítě, chování jednotlivých uživatelů a míra kritického myšlení rychlost a rozsah šíření dezinformací? Simulace umožní identifikovat klíčové parametry, které mohou buď přispět k virálnímu šíření, nebo ho potlačit. Výsledkem může být doporučení k edukaci uživatelů nebo návrh algoritmických opatření pro omezení dosahu problematického obsahu.

=== Použití simulace ===
Simulace má možné využití:
* Jako didaktický nástroj pro výuku mediální a digitální gramotnosti nebo informační bezpečnost
* Pro využití v akademickém výzkumu zabývajícím se šířením obsahu v online prostředí, včetně fake news a konspiračních teorií.

Výsledky mohou posloužit i jako argument pro zavedení preventivních opatření na sociálních platformách.

=== Použitá metoda a prostředí ===
Simulace je vytvořena v prostředí NetLogo. Agenti představují uživatele sociální sítě a jsou propojeni do komunikační struktury (vztahy: „sleduje“, „přátelí se“). Dezinformace se šíří po těchto spojeních. V modelu existují pravidla pro šíření dezinformace a rozhodování agentů. To znamená, že každý agent má určitou pravděpodobnost sdílení, může si informaci ověřit a tím ji zablokovat, nebo ji předat dál.

=== Proměnné ===
'''Definované předem:'''
• počet uživatelů v síti
• typ sociální sítě/síťové struktury (náhodná síť, small-world, scale-free)
• průměrný počet spojení na agenta = síťová hustota
• počet původních šiřitelů dezinformace
• pravděpodobnost sdílení dezinformace (bez ověření)
• pravděpodobnost ověření zprávy a zamezení jejího šíření
'''Náhodné:'''
• rozložení spojení v síti
• výběr původních šiřitelů
• pořadí interakcí mezi agenty (směr šíření, kdo ovlivní koho)
• individuální rozhodnutí každého agenta (na základě pravděpodobností)
• výsledný rozsah šíření (liší se běh od běhu i při stejných nastaveních)

=== Data ===
* Výzkumy behaviorální ekonomie a mediální gramotnosti – např. [https://mediaeducation.ucoz.ru/_ld/0/83_Fedorov-A-2007-.pdf JIRÁK, Jan; WOOLÁK, Radim Woolák Radim. Mediální gramotnost. Praha: Radioservis, 2009.]
* Analýzy šíření fake news – např. Vosoughi, Roy, Aral (2018) – „The spread of true and false news online“, Science 359(6380), 1146–1151. [https://ide.mit.edu/wp-content/uploads/2018/12/2017-IDE-Research-Brief-False-News.pdf „The spread of true and false news online“]
* Odhady pravděpodobností a struktury sítě vycházejí z běžného chování uživatelů na sociálních sítích
* Výzkumné zprávy o algoritmech šíření obsahu na platformách jako Facebook, Instagram, nebo TikTok

=== Simulant ===
[[User:macn04|macn04]] ([[User talk:macn04|talk]]) 14:30, 12 May 2025 (CET)

== Simulace: Evakuace šelem v pražské ZOO v případě povodně ==

=== Popis problému ===
Pražská zoologická zahrada se nachází v záplavovém území a v minulosti byla při povodních (např. v roce 2002 a 2013) vážně zasažena. Evakuace zvířat, zejména velkých a nebezpečných šelem, představuje logisticky i bezpečnostně náročný úkol. Zvířata musí být přepravena v co nejkratším čase, bezpečně a s minimálním stresem, zároveň je nutné chránit zaměstnance a návštěvníky. Simulace se zaměřuje na proces evakuace pavilonu šelem při náhlém zvýšení hladiny Vltavy. Výsledky mohou pomoci vedení ZOO lépe se připravit na mimořádné události.

=== Cíl simulace ===
Simulace se bude věnovat otázce: Jak rychle a efektivně lze evakuovat šelmy z ohroženého pavilonu v případě povodně?
Výsledkem bude návrh optimální evakuační strategie v závislosti na různých faktorech (např. počet ošetřovatelů, kooperace zvířat, čas do zaplavení, atd.). Některá zvířata jsou více nebezpečná jiná jsou klidná.

=== Použití simulace ===
Simulace může sloužit:
*Zaměstnancům ZOO, kteří se chtějí připravit na krizové situace
*Studentům, kteří se učí o ochraně zvířat nebo krizovém řízení
*Veřejnosti, která si chce udělat představu, jak taková situace vypadá a proč je důležitá příprava

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo, kde agenti budou zvířata, zaměstnanci (ošetřovatelé) a povodeň. Zvířata mají různé chování, velikost, agresivitu. Ošetřovatelé jsou zkušení, ale i nováčci a je jich různý počet na směnách. Povodeň může mít různé rychlosti. Prostředím je pavilon šelem v pražské ZOO. V pavilonu jsou jednotlivé expozice podle druhu zvířete. V případě, kdy hrozí evakuace jsou všechna zvířata uvnitř pavilonu.

V případě evakuace přijdou chovatelé a evakuují zvířata. Některá musí uspat, jiná ne. Zvířata přesouvají do klecí nebo boxů a převážejí pryč cestou podle zatopení. U každého zvířete je dohledatelný

=== Proměnné ===
Definované předem:
* Počet zvířat v pavilonu, jejich velikost a druhy
* Počet evakuačních cest
* Rychlost záplav (kolik času je na evakuaci)
* Počet ošetřovatelů a jejich zkušenosti (můžou být zkušení nebo nováčci, nováčci jsou pomalejší a mají vyšší pravděpodobnost minout uspávací šipkou)

Náhodné:
* kooperace zvířete (může být klidné nebo agresivní)
* rozmístění ošetřovatelů
* minutí uspávací šipkou
* rozbitá klec

=== Data ===
* výroční zprávy ZOO Praha [https://www.zoopraha.cz/vse-o-zoo/vyrocni-zpravy]
* mapa ZOO Praha (obrázková) [https://www.zoopraha.cz/navsteva/30-mapa-zoo-praha]
* mapa ZOO Praha [https://g.co/kgs/aXs5ceF]
* přiklad info o zvířeti ZOO Praha [https://www.zoopraha.cz/aktualne/pohledem-reditele/14972-jak-se-v-zoo-praha-chystame-na-povodne]
* převoz tygrů [https://www.jamescargo.com/blog/tiger-transport.php?utm_source=chatgpt.com]
* CITES transport guidelines [https://cites.org/eng/resources/transport/advice.shtml?utm_source=chatgpt.com]

=== Simulant ===
Veronika Smrčková
[[User:smrv03|smrv03]] ([[User talk:smrv03|talk]]) 11:36, 12 May 2025 (CET)

== Simulace: Strategie hráčů ve hře v kostky dle pravidel hry Farkle ==

=== Popis problému ===
Cílem simulace je analyzovat a porovnat různé herní strategie ve hře Farkle (hazardní kostková hra). Dva hráči si během hry střídavě hází kostkami a snaží se získat co nejvíce bodů pomocí specifických kombinací (např. trojic, postupky, šest stejných hodnot apod.). Hráči však musí v každém tahu rozhodnout, zda pokračovat v házení (s rizikem ztráty aktuálního skóre) nebo se zastavit a body si uložit.

Každý hráč je reprezentován jako „persona“ s předdefinovanou strategií rozhodování – od konzervativního po extrémně rizikového přístupu. Tyto odlišné styly chování významně ovlivňují průběh hry, četnost výher i riziko prohry kvůli přehnané hamižnosti.

=== Cíl simulace ===
Cílem simulace je zjistit, jaké herní strategie (persony) jsou nejefektivnější v dosažení výhry ve hře Farkle. Zároveň zohledňuje spravedlnost (oba hráči mají stejný počet tahů) a umožňuje porovnávat strategie mezi sebou při opakovaném hraní stovek her. Výstupem je srovnání úspěšnosti jednotlivých přístupů a doporučení vhodné herní taktiky.

=== Použití simulace ===
Simulace může sloužit:
* jako model rozhodování v nejistém prostředí,
* jako prostředek pro výuku agentového modelování (např. střední školy, informatika, psychologie rozhodování),
* pro zábavné testování, která strategie by přinesla nejvíc výher v reálné hře Farkle,
* jako výchozí kostra pro složitější modely s učením, adaptivními hráči nebo evoluční optimalizací strategie,
* a v neposlední řadě, jako "engine" na testování person pro mou diplomovou práci.

=== Použitá metoda a prostředí ===
Simulace je implementována v prostředí NetLogo jako dvouagentní tahový model. Hráči se střídají v házení 6 kostek, získávají body za kombinace podle pravidel Farkle (např. trojice, čtveřice, pětice, šestice, postupky) a rozhodují se, zda budou pokračovat v tahu.

Model zahrnuje:
* různé herní strategie („persony“) – definované jako rozhodovací pravidla podle skóre, zbývajících kostek nebo náhodného faktoru,
* počítání statistik (výhry, tahy, FARKLE chyby),
* zajištění férovosti – druhý hráč má vždy možnost dokončit poslední tah, pokud první dosáhne vítězného skóre,
* export výsledků a vykreslení průběhu skóre do grafu (a jiné statistické ukazetele).

=== Proměnné ===
Definované předem:
* Cílové skóre pro výhru (např. 10 000)
* Počet simulovaných her (např. 100 až 1000)
* Herní strategie pro oba hráče:
* conservative – ukládá body při ≥400
* risky – ukládá body při ≥700
* greedy – ukládá body při ≥1000
* cautious – hraje opatrně (≥300 nebo málo kostek)
* random – rozhoduje se náhodně
* risk-averse – hraje opatrně jen pokud vede o >2000 bodů, jinak jako conservative
* point-maximizer – pokračuje, dokud nedostane HOT DICE
* combo-hunter – pokračuje po silných kombinacích (postupky, trojice a víc)

Náhodné:
* Hod šesti kostkami (1–6)
* Kombinace, které hráči získají (např. 3 stejné, postupka 1–6 atd.)
* Výsledek rozhodnutí pokračovat/zastavit u náhodné strategie

Možná rozšíření simulace:
* Evoluční vývoj nových strategií (např. pomocí genetického algoritmu)
* Paměť hráčů – učení na základě předchozích neúspěchů
* Reakce na strategii soupeře (adaptivní persona)

=== Data ===
* [https://farkle.games/official-rules/] - oficiální pravidla hry Farkle
* [http://incompleteideas.net/book/the-book-2nd.html] - popis chování osob v pod tlakem a při riskování (persony)
* [https://mud.co.uk/richard/hcds.htm] - rozdělení person a chování v různých karetních a jiných hrách
* [http://incompleteideas.net/book/the-book-2nd.html] - o strategiích rozhodování, výběru akcí, riziku a odměnách

=== Simulant ===
Jan Hlavnička
[[User:hlaj13|hlaj13]] ([[User talk:hlaj13|talk]]) 13:58, 8 May 2025 (CET)

== Simulace: Simulace tučňáků hledajících lásku na ledové kře 🐧❤️ ==

=== Popis problému ===
Cílem simulace je modelovat chování tučňáků během námluv na ledové kře. Tučňáci musí najít vhodného partnera pro hnízdění, přičemž čelí různým vnějším vlivům – nestabilnímu prostředí (praskající led), konkurenci ostatních tučňáků a hrozbě predátorů (např. lachtani).

Každý tučňák má specifické nastavení chování – někteří jsou spíše plachého typu, jiní jsou odvážní a aktivně oslovují potenciální partnery. Odlišný přístup k seznamování ovlivňuje jejich šanci na úspěšné spárování a přežití do hnízdní sezóny.

=== Cíl simulace ===
Simulace se zaměří na otázku: Jaký „balící styl“ (strategie chování) vede k nejvyšší šanci na nalezení partnera a založení hnízda, a jak tuto šanci ovlivňuje prostředí a přítomnost rizik? Výsledkem bude doporučení nejefektivnějších „láskových taktik“ v závislosti na kontextu (bezpečné vs. nebezpečné prostředí).

=== Použití simulace ===
Simulace může sloužit:
* jako model sociální interakce v zábavné formě,
* jako edukativní nástroj pro představení agentového modelování (např. na středních školách),
* nebo jako metaforické přiblížení seznamovacích strategií ve složitém prostředí.

=== Použitá metoda a prostředí ===
Simulace bude vytvořena v prostředí NetLogo jako multiagentní model, kde každý agent (tučňák) bude reprezentovat jiný typ chování. Prostředí bude ledová kra se zónami různé stability a výskytu predátorů.

Tučňáci budou interagovat podle jednoduchých pravidel: přiblíží se k partnerovi, pokusí se o námluvy (s pravděpodobností úspěchu ovlivněnou vlastnostmi obou), a pak spolu odcházejí hnízdit (zmizí ze scény). Mohou být také ohroženi prasknutím kry nebo útokem predátora.

=== Proměnné ===
Definované předem:
* Počet tučňáků (např. 50–100)
* Stabilita ledu (pravděpodobnost prasknutí při stání na místě)
* Výskyt predátorů (pravděpodobnost útoku při pohybu)
* Rychlost pohybu a reakce

Typ chování:
* Plachý – čeká, až ho někdo osloví
* Odvážný – aktivně balí ostatní
* Kombinovaný – střídá strategie

Náhodné:
* Rozmístění tučňáků
* Výběr preferovaného partnera (náhodně nebo podle vlastností)
* Výsledek námluv (pravděpodobnost úspěchu podle kompatibility + typu chování)
* Prasknutí ledové kry
* Útok predátora

Možná rozšíření simulace:
* Přidání „charakterových“ rysů (krása peří, zpěv, taneční dovednosti)
* Učení – tučňák se poučí z neúspěchu a změní taktiku
* Sezónnost – časový limit na nalezení partnera (jinak simulace končí smutným singl koncem)

=== Data ===
* [https://www.reuters.com/business/environment/emperor-penguins-suffered-mass-breeding-failures-2023-amid-record-low-sea-ice-2024-04-25/ Stabilita mořského ledu a úspěšnost hnízdění
* [https://www.birdsnz.org.nz/wp-content/uploads/2021/12/Rowe_67_etal_451_459.pdf Úspěšnost hnízdění u tučňáků malých
* [https://www.selwomarina.es/en/blog/por-que-pinguinos-regalan-piedras-hembra?utm_.com Selwo Marina Benalmadena] – Článek věnující se námluvám a párování, kde popisují darování kamínků jako součást námluv
* BBC Earth, National Geographic, Attenboroughovy dokumenty – často dobře vysvětlují typy chování, interakce a přežívání. Např. March of the Penguins

=== Simulant ===
Zuzana Plachá
[[User:plaz03|plaz03]] ([[User talk:plaz03|talk]]) 20:20, 7 May 2025 (CET)

== Simulace: Simulace vojenské patroly a střetu s nepřítelem ==

=== Popis problému ===
Simulace se zabývá chováním malé vojenské jednotky (patroly), která operuje v nepřátelském teritoriu. Cílem patroly je bezpečný průchod zadanou trasou. V oblasti se ovšem mohou nacházet nepřátelské síly, které mají za úkol patrolu odhalit a zlikvidovat. Průběh mise ovlivňuje několik proměnných – velikost jednotky, dosah vidění, typ terénu, schopnost včasné reakce a počet a rozmístění nepřátel. Výsledky simulace umožní analyzovat účinnost různých taktik a rozhodovacích pravidel, které jednotka může použít při plnění mise. Zároveň mohou sloužit jako podpůrný nástroj při plánování operací nebo jako tréninková pomůcka pro rozhodování armády v rizikových situacích.

=== Cíl simulace ===
Simulace se bude věnovat zodpovězení otázky: jak různé faktory (velikost jednotky, rozmístění nepřátel, strategie pohybu) ovlivňují úspěšnost vojenské patroly při průchodu nebezpečným územím? Cílem je nalézt parametry a strategie, které vedou k nejvyšší pravděpodobnosti úspěšného dokončení mise bez ztrát. Výsledkem bude doporučení efektivních taktických rozhodnutí pro minimalizaci rizika při podobných operacích.

=== Použití simulace ===
Simulaci by mohli využít velitelé malých jednotek nebo vojenská akademie pro testování taktik v simulovaných prostředích. Model by jim dokázal vyhodnotit, jak různé strategie a složení jednotky ovlivňují šanci na úspěšné dokončení mise bez ztrát.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenti v modelu budou reprezentovat členy vojenské patroly a nepřátelské jednotky. Prostředí bude představovat mapu oblasti s různými typy terénu - otevřený terén, les, kryt apod.

=== Proměnné ===
Definované předem:
* Počet vojáků v patrole
* Počet nepřátel
* Typ terénu (např. podíl lesů, volného prostoru)
* Trasa patroly (předem definovaná nebo generovaná)
* Dosah vidění vojáků i nepřátel
* Pravidla reakce na kontakt (útěk, útok, přivolání podpory)
Pravděpodobnosti střetu a úspěchu jsou založeny na odhadech inspirovaných vojenskými taktickými příručkami a popisech reálných situací v článcích A-Report.

Náhodné:
* Rozmístění nepřátel v terénu
* Zpozorování nepřítele (pravděpodobnost, že jednotka zahlédne protivníka)
* Výsledek střetu (založen na pravděpodobnosti úspěchu v boji)
* Chování nepřítele (např. zda se ukryje nebo přepadne)

=== Data ===
* [https://mocr.mo.gov.cz/assets/informacni-servis/povinne-informace/1-uredni-deska/zakon-106/odp/priloha-c--1-1_25.pdf Základní řád ozbrojených sil České republiky] – řád armády ČR
* [https://mocr.mo.gov.cz/assets/multimedia-a-knihovna/casopisy/a-report/ar9_2018.pdf Časopis A-Report Útoku se nedalo zabránit] – Úryvek ze článku věnovaný osudové chybě v boji na Balkáně
* [https://mocr.mo.gov.cz/assets/multimedia-a-knihovna/casopisy/a-report/ar10_2019.pdf Časopis A-Report Pod ostrou palbou] – Úryvek ze článku popisující možnost simulací ve vojenském prostředí
* Vlastní odhady založené na realistických parametrech (např. efektivní dostřel, rychlost pohybu v terénu)

=== Simulant ===
Alexandr Sekera
[[User:seka01|seka01]] ([[User talk:seka01|talk]]) 15:33, 7 May 2025 (CET)

== Simulace: Kontrola jízdenek v MHD ==
=== Popis problému ===
Simulace se zabývá procesem kontrol jízdenek ve veřejné dopravě (např. v systému MHD v Praze). Veřejná doprava je financována částečně z příjmů z jízdného. Cestování "načerno" představuje pro dopravní podnik zdroj ztrát. Proto revizoři od podniku provádějí kontroly platnosti jízdních dokladů. Z toho vyplývá otázka, jak často a jakým způsobem mají být dané kontroly prováděny, aby byly efektivní a ekonomicky dávaly smysl. Výsledky simulace umožní řízení MHD optimalizovat frekvenci kontrol, počet revizorů a tím zvýšit celkovou efektivitu inspekcí.

=== Cíl simulace ===
Simulace se bude věnovat zodpovězení otázky: jak ovlivňuje četnost kontrol objem vybraných pokut ve veřejné dopravě? Výsledkem bude doporučení efektivních inspekčních strategií pro maximalizaci vybraných pokut. Simulace také ukáže, kolik revizorů je potřeba pro dosažení požadované míry kontroly.

=== Použitá metoda a prostředí ===
Multiagentní simulace v Netlogo. Agenti v modelu budou reprezentovat pasažéry a revizory.

=== Proměnné ===
Definované předem:
* Počet cestujících (celkově)
* Počet revizorů
* Výše pokuty (standardní nebo menší za platbu okamžitě)
* Frekvence kontrol (počet provedených kontrol za minutu/hodinu)
* Kapacita vozidla (počet cestujících z celkového čísla, kteří jsou aktuálně v kontrolovaném prostoru)

Náhodné:
* Platnost jízdenky (zda jede pasažér "načerno")
* Zachycení černého pasažéra (zda je neplatnost jízdenky odhalena)
* Zaplacení pokuty (hned či později)

=== Data ===
[https://www.dpp.cz/jizdne/pokuty-revizori/vyse-prirazky DPP - pokuty a revizoři] - výše jednotlivých pokut

[https://www.dpp.cz/vozovy-park DPP - vozový park] - kapacity vozidel

[https://www.expats.cz/czech-news/article/prague-public-transport-inspectors-handed-out-250-000-fines-last-year Prague public transport inspectors handed out 250,000 fines last year] - počty kontrol, pasažérů a revizorů, celková výše pokut, zaplacení pokut

Míra cestování "načerno" pro Prahu není zveřejněna oficiálně. Pro odhad poměru černých pasažérů se lze inspirovat jinými státy ([https://theweek.com/transport/fare-dodging-londons-transport-blight UK], [https://www.trainsfare.eu/tackling-fare-evasion-in-bergamo-a-growing-challenge-for-atb-and-teb/ IT]).

=== Simulant ===
Vladislav Sanin
[[User:Sanv05|Sanv05]] ([[User talk:Sanv05|talk]]) 21:15, 6 May 2025 (CET)

== Simulace: Pavlovovo podmiňování v agentním modelu ==
=== Co budu simulovat ===
Simulace bude modelovat proces klasického (Pavlovova) podmiňování, kdy agent (představující psa) postupně spojuje neutrální podnět (zvonek) s přirozeným podnětem (jídlo). Výsledkem je, že agent začne reagovat podmíněnou reakcí (slinění) i v případě, že se později objeví pouze zvonek bez jídla.

=== Cíl simulace ===
Cílem simulace je analyzovat průběh učení podmíněné reakce a zjistit:
* kolik opakování je potřeba k vytvoření podmíněné reakce,
* jak stabilní tato reakce je v čase,
* jak rychle dochází k vyhasnutí reakce (extinkci) při absenci posílení,
* jak efektivní je opětovné učení (re-learning) po ztrátě reakce.

Obecně jde o pochopení mechanismů formování návyků a chování založeného na stimulaci a posilování.

=== Kdo by takovou simulaci mohl využít a jak by mu pomohla ===
Simulaci mohou využít například:
* psychologové zabývající se behaviorálním učením,
* učitelé při výuce základních principů behaviorismu,
* vývojáři agentních a AI modelů, kteří chtějí simulovat jednoduché učení nebo formování návyků.

Simulace jim umožní vizuálně a experimentálně sledovat proces klasického podmiňování a analyzovat vliv různých parametrů na průběh učení.

=== Použitá metoda a prostředí ===
* '''Metoda''': Agentní simulace využívající jednoduchý model chování se stavovým automatem. Agent mění svůj vnitřní stav v závislosti na podnětech a historii posilování.
* '''Prostředí''': NetLogo

=== Jaké proměnné budou v simulaci ===
* Počet pokusů o podmiňování
* Zpoždění mezi zvonkem a jídlem (časování podnětů)
* Frekvence posilování (např. 100 %, 75 %, 50 % případů s jídlem)
* Síla podmíněné reakce (vnitřní proměnná zvyšující se učením)
* Počet extinkčních pokusů (zvonek bez jídla)

=== Jaké proměnné budou náhodné ===
* Pravděpodobnost, zda po zvonku následuje jídlo (při částečném posilování)
* Malá náhodná odchylka v chování psa (např. reakční doba, úroveň slinění)

=== Na jakých datech budou proměnné založené ===
* Parametry vycházejí z publikovaných výsledků klasických experimentů Pavlova a dalších behaviorálních studií.
* Typické hodnoty časování a pravděpodobností pro různé typy posilování vychází z odborné literatury.
* Síla reakce bude modelována pomocí logistické funkce, která simuluje typickou křivku učení a vyhasínání reakce.
* [https://www.psychologywizard.net/uploads/2/6/6/4/26640833/pavlov_lecture_18.pdf Pavlov – Lecture 18 (Conditioned Reflexes, 1927)]
* [https://en.wikipedia.org/wiki/Classical_conditioning Wikipedia – Classical Conditioning]
* [https://www.simplypsychology.org/pavlov.html Simply Psychology – Pavlov’s Dogs]

=== Na jakých datech jsou založeny vzorce v simulaci (chování modelu) ===
Chování modelu bude založeno na Rescorla-Wagnerově modelu klasického podmiňování, který kvantifikuje změnu síly asociace mezi podmíněným podnětem a nepodmíněným podnětem během jednotlivých pokusů.
* [https://www.vcalc.com/wiki/rescorla-wagner-formula-alpha-and-beta-version vCalc – Rescorla-Wagner model (alpha and beta version)]
* [https://en.wikipedia.org/wiki/Rescorla%E2%80%93Wagner_model Wikipedia – Rescorla–Wagner model]

=== Simulant ===
[[User:Lans06|Lans06]] ([[User talk:Lans06|talk]]) 22:27, 6 May 2025 (CET)

== Simulace: Bitva u Azincourtu v roce 1415 (Anglie vs Francie během Stoleté války) ==

=== Popis problému ===
V roce 1415 stála Anglie v čele se svým králem Jindřichem V. proti silám Francie, které měly velmi drtivou převahu (Anglie cca 8500 a Francie cca 15 000). I přes tuto nevýhodu dokázala Anglie vyhrát s nepatrnými ztrátami. Dle historických pramenů to bylo především díky strategickému umístění anglického vojska v úzkém prostoru mezi stromy, kde nemohly francouzské jednotky přímo naběhnout a využít drtivou sílu svých počtů bojovníků - musely postavit více řad bojovníků za sebou a nemohly anglické jednotky obklopit.

=== Cíl simulace ===
Simulace se bude věnovat otázce: Měla by Francie šanci vyhrát bitvu, kdyby se bitva odehrávala na širokém prostranství narozdíl od úzkého prostoru? Nebo by stále Anglie dokázala vyhrát, kdyby přišla o výhodu okolí?

=== Použití simulace ===
Simulace může sloužit:
* historikům - náhled do historie, kdyby měla bitva jiný průběh
* Úvaha nad historickou událostí, která ovlivnila Stoletou válku

=== Cíl simulace ===
* dokázat, jak terén může ovlivnit průběh bitvy, pokud je stanovena správná strategie
* změní se průběh bitvy a dokáže Francie vyhrát?
* jak moc účinné je zbraň Long Bow (dlouhý luk) v otevřeném terénu?

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo, kde agenti budou jednotky Anglie (pěšáci, střelci s Long Bow) a Francie (pěšáci, kavalérie, střelci s Long Bow, střelci s kuší).

=== Proměnné v simulaci ===
Definované předem:
* počet a rozložení jednotek anglické armády
* počet a rozložení jednotek francouzské armády

Náhodné
* pohyb jednotek (každá jednotka má své reakce a možnosti pohybu)
* střelba z Long Bow - kolik zvládne vystřelit šípů za určitý čas

=== Data ===
* https://www.stoplusjednicka.cz/bitva-u-azincourtu-stret-ktery-rozhodl-nekonecnou-valku-mezi-anglii-francii
* https://zoom.iprima.cz/historie/bitva-u-azincourtu
* vlastní poznatky z rekonstrukcí bitev

=== Simulant ===
[[User:Bilk08|Bilk08]] ([[User talk:Bilk08|talk]]) 12:00, 12 May 2025 (CET)

== Simulace: Phishing na hybridním pracovišti ==

=== Popis problému ===
Práce bude zkoumat roli hybridního (onsite & remote) pracoviště na pravděpodobnsot úspěšného phishing útoku.
Remote zaměstnanci méně komunikují, než jejich onsite kolegové, což snižuje pravděpodobnost, že o podezřelém emailu někomu řeknou nebo u stolu jen prohlásí "to je divný" nebo "taky jsi dostal tenhle trenink do zitra?".
Simulace bude uvažovat, že ne každý zaměstnanec má přístup ke kritickým systémům, jen někteří mohou způsobit firmě vážné škody, ale pokud se tak stane, následky jsou velké.

=== Cíl simulace ===
Simulace má za cíl zjistit, jaké budou škody s různými konfiguracemi onsite vs. remote zaměstnanců.

=== Kdo by takovou simulaci mohl využít a jak by mu pomohla ===
Jakákoli korporát/firma s kombinací onsite a remote zaměstnanců (populární po pandemii)

=== Použitá metoda a prostředí ===
*Metoda: Multi-agentní simulace
*Prostředí: NetLogo

=== Jaké proměnné budou v simulaci ===
*Deterministické:
**Socializace (např. oběd)
**Délka sprintu (ke konci sprintu klesá pozornost, roste zbrklost)
**Počet zaměstnanců s kritickými přístupy
**Počet onsite zaměstnanců
**Počet remote zamšstnanců
**Intervaly mezi interními phishing testy IT oddělení

*Náhodné:
**Četnost phishing útoků
**Základní pravděpodobnost naletění na phishing
**Pravděpodobnost naletění po školení (efekt se bude s časem od školení snižovat)
**Pravděpodobnost naletění po úspěšném útoku
**Remote & onsite pravděpodobnost komunikace (při odhalení phishingu)
**Ztráta způsobená úspěšným phishingovým útokem bez kritických přístupů
**Ztráta způsobená úspěšným phishingovým útokem s kritickými přístupy

=== Data ===
*Vědecké články (např. psychologické studie na efekt o interních phishing testech, jak zvyšuje pracovní nápor pravděpodobnost naletění)
*Phishingové statistiky (např. četnost, úspěšnost, severita)

=== Simulant ===
[[User:Lebm05|Lebm05]] ([[User talk:Lebm05|talk]]) 12:59, 12 May 2025 (CET)

== Simulace: Obsazenost akutních lůžek v českých nemocnicích ==

=== Popis problému ===
České nemocnice disponují v průměru 4,6 akutními lůžky na 1 000 obyvatel. Při průměrné ošetřovací době, která teď činí 5,5 dne, dochází k fluktuacím mezi novými přijetími pacientů, obsazeným počtem lůžek a propouštěním pacientů. Při obsazenosti vyšší než 85 %, kvalita péče klesá, prodlužují se čekací doby a zvyšuje se riziko komplikací a nozokomiálních infekcí.

Simulace bude odhadovat vývoj obsazenosti akutních lůžek v čase a vyhodnotí dopad různých intervencí (zkrácení průměrné ošetřovací doby, navýšení kapacity, řízení fronty).

Výsledky simulace ukážou, která opatření nejvíce snižují riziko dlouhodobé obsazenosti nad 85 %, kdy už dochází k prodlužování čekacích dob a nárůstu infekcí; také mohou sloužit jako podpora rozhodování o investicích a rozdělení rozpočtu.

=== Cíl simulace ===
Cílem simulace je zodpovědět na otázku, do jaké míry a jak rychle udržení obsazenosti pod 85 % ovlivní faktory jako:
* Snížení průměrné ošetřovací doby o 10 %
* Navýšení kapacity o 10 %
* Řízená fronta (prioritizace)
Ve všech scénářích budu sledovat průměrnou denní obsazenost lůžek, maximální délku fronty, a čas, za který obsazenost překročí nebo zůstane pod hranicí 85 %.

=== Použití simulace ===
Kdo může simulaci použít?
Simulace umožní vedení zdravotnických zařízení a manažérům identifikovat dlouhodobé rizikové body v lůžkové kapacitě a následně je mohou využít k optimalizaci strategických investic tak, aby udrželi kontinuitu péče a finanční udržitelnost i při demografických změnách či neočekávaných vlnách poptávky. Díky simulaci mohou předem ověřit dopad různých politik (např. zkrácení průměrné ošetřovací doby, rozšíření kapacity, prioritizace příjmu) a na základě toho nastavit robustní krizové plány a alokaci zdrojů.

=== Použitá metoda a prostředí ===
Pro tvorbu simulace využit přístup Systémové dynamiky a nástroj Vensim PLE.

=== Proměnné ===
* Počet obyvatel
* Počet hospitalizovaných pacientů (akutní lůžka)
* Počet nově hospitalizovaných pacientů
* Počet propuštěných pacientů
* Průměrná délka hospitalizace
* Míra propuštění
* Průměrné denní množství nových žádostí o hospitalizaci
* Míra hospitalizace
* Celkový počet akutních lůžek
* Míra navýšení kapacity při obsazenosti větší než 85 %
* Počet volných lůžek
* Obsazenost lůžek

=== Data ===
* Počet obyvatel v ČR. [https://vdb.czso.cz/vdbvo2/faces/cs/index.jsf?page=vystup-objekt&pvo=DEM13&z=T&f=TABULKA&skupId=3829&katalog=33155&pvo=DEM13&evo=v141_!_IK-CR-K_1&c=v3~8__RP2021]
* Zdravotní péče České republiky. [https://csu.gov.cz/zdravotni-pece#:~:text=2016%202017%202018%202019%202020,548%209%20960%209%20996]
* Zdravotnická ročenka České republiky. [https://www.uzis.cz/index.php?pg=aktuality&aid=8560]
* Hospitalizace v nemocnicích ČR. [https://www.uzis.cz/index.php?pg=vystupy--vyznamna-temata--hospitalizace ]
* Pohyb obyvatelstva - rok 2021. [https://csu.gov.cz/rychle-informace/pohyb-obyvatelstva-rok-2021#:~:text=Podle%20výsledků%20sčítání%20lidu%2C%20domů,Štyglerová%2C%20vedoucí%20oddělení%20demografické%20statistiky]

=== Simulant ===
[[User:Kozo01|Olesia Kozlova (kozo01)]] ([[User talk:kozo01|talk]]) 16:07, 12 May 2025 (CET)

:: '''Schváleno'''[[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 20:45, 12 May 2025 (CET)

== Simulace: Eutrofizace vodní plochy ==

=== Popis problému ===
Eutrofizace vodních ploch je přírodní jev, který může být výrazně ovlivněn antropogenní činností. Jedná se zejména o jednotlivé chemické pochody, které způsobují nárůst biomasy na hladině vodní plochy. Díky tomuto růstu dochází k postupnému snižování světelných podmínek pod úrovní hladiny, což způsobuje úhyn biomasy a dochází k zvýšení rozkladných procesů, které zapříčiňují úbytek kyslíku v celé vodní nádrži. Následkem toho dochází i k úhynu vodních živočichů závislých na koncentraci kyslíku pod hladinou.

=== Cíl simulace ===
Cílem simulace je namodelovat celý proces eutrofizace, který bude ovlivněn antropogenní činností (např. splachy z polí). Zodpoví jednu z důležitých otázek: Jak antropogenní činnost urychluje eutrofizaci.

=== Použití simulace ===
* Simulace může být využita k akademickému studiu eutrofizace,
* jako podpora při legislativních rozhodnutí,
* může vylepšit strategické plánování ve vodohospodářských organizacích, nebo
* strategické plánování zemědělců.

=== Použitá metoda a prostředí ===
* Simulace využívá program Vensim, který byl vybrán na základě jeho schopnosti namodelovat toky a vazby mezi jednotlivými proměnnými ve sledovaném prostředí.

=== Proměnné ===
* Definované předem:
** úroveň eutrofizace,
** počáteční množství biomasy,
** počáteční množství živočichů,
** počáteční pH vody,
** počáteční obsah kyslíku.

* Náhodné:
** počasí,
** zalévání zemědělských ploch.

Popřípadě další.

=== Data ===
* YANG, Xiao-e, Xiang WU, Hu-lin HAO a Zhen-li HE, 2008. Mechanisms and assessment of water eutrophication. Journal of Zhejiang University. Science. B [online]. 9(3), 197–209. ISSN 1673-1581. Dostupné z: doi:[https://doi.org/10.1631/jzus.B0710626 10.1631/jzus.B0710626]

=== Simulant ===
[[User:bene08|Eliška Benešová (bene08)]] ([[User talk:bene08|talk]]) 16:07, 12 May 2025 (CET)

:: '''Schváleno''' [[User:Oleg.Svatos|Oleg.Svatos]] ([[User talk:Oleg.Svatos|talk]]) 20:50, 12 May 2025 (CET)

== Simulace: Simulace průchodu cestujících pasovou kontrolou na letišti ==

=== Popis problému ===
Letiště v době dopravní špičky čelí problémům s kapacitou pasové kontroly. Nedostatečný počet otevřených přepážek vede k dlouhým frontám a nespokojenosti cestujících. Naopak příliš mnoho otevřených přepážek může znamenat neefektivní využití personálu. Proto je potřeba najít rovnováhu mezi těmito dvěma faktory.

=== Cíl simulace ===
Cílem simulace je analyzovat vliv počtu otevřených přepážek na délku fronty a maximální čekací dobu cestujících. Jedním z hlavních cílů je identifikovat maximální čekací dobu v případech, kdy nejsou otevřeny všechny dostupné přepážky, a navrhnout optimální počet přepážek pro různé scénáře zatížení.

=== Použití simulace ===
Simulaci může využít letištní management, konkrétně vedoucí směny nebo plánovači personálu, kteří rozhodují o počtu aktivních pracovníků v jednotlivých časových intervalech. Pomůže jim lépe plánovat směny a optimalizovat provoz pasové kontroly tak, aby se předešlo zbytečným zpožděním i plýtvání lidskými zdroji.

=== Použitá metoda a prostředí ===
Použiji agentní simulaci v jazyce Rust, s využitím open-source herního enginu Bevy (verze 0.13) jako vizuálního a simulačního prostředí. Každý cestující bude modelován jako agent, který dorazí, čeká ve frontě, a je odbaven u přepážky podle pravidel fronty (FIFO). Přepážky budou reprezentovány jako paralelní servery.

=== Proměnné ===

Deterministické proměnné:

*Počet otevřených přepážek
*Reálný rozvrh příletů letadel
*Počet cestujících vystupujících z každého příletu (interval 5 minut)

Náhodné proměnné:

*Interval mezi příchody cestujících (exponenciální rozdělení)
*Doba odbavení u přepážky (normální rozdělení)
*Rychlost přechodu cestujících od gate k pasové kontrole

Měřené výstupy:

*Průměrná čekací doba
*Maximální čekací doba
*Využití jednotlivých přepážek v %
*Délka fronty v čase

=== Data ===

Průměrná doba odbavení: Na základě interních dat z provozu pasové kontroly letiště.

Intenzita příchozích cestujících: Data získáná z každodenního leteckého provozu mimo sezónu a v sezóně (červen - září)

=== Simulant ===
[[User:Papd01|Papd01]] ([[User talk:Papd01|talk]]) 17:25, 12 May 2025 (CET)

== Simulace: Autobusová linka v městské dopravě ==

=== Popis problému ===
Simulace se zabývá provozem autobusové linky v městské dopravě. Veřejná doprava je klíčová pro fungování měst a efektivní provoz autobusových linek zajišťuje dostupnost a komfort pro cestující. V praxi dochází k problémům, jako je přetížení spojů během špičky, zpoždění, dlouhé čekací doby na zastávkách nebo nevyužité kapacity mimo špičku. Simulace umožní analyzovat, jak různé faktory (například počet autobusů, intervaly mezi spoji, kapacita vozidel nebo rozložení cestujících během dne) ovlivňují kvalitu přepravy a vytížení linky. Výsledky simulace mohou pomoci dopravcům optimalizovat jízdní řády a nasazení vozidel.

=== Cíl simulace ===
Cílem simulace je zjistit, jak různé parametry provozu autobusové linky ovlivňují:
* průměrnou dobu čekání cestujících na zastávce,
* naplněnost autobusů v různých částech trasy a v různých časech,
* identifikaci kritických zastávek s přetížením,
* doporučení pro optimalizaci jízdního řádu a kapacity linky.

=== Použitá metoda a prostředí ===
Multiagentní simulace v NetLogo. Agenty v modelu budou reprezentovat autobusy, cestující a zastávky.

=== Proměnné ===
Definované předem:
* Počet autobusů na lince
* Kapacita jednoho autobusu
* Počet zastávek a jejich rozložení na trase
* Interval mezi odjezdy autobusů
* Délka trasy a čas potřebný k projetí celé linky

Náhodné:
* Počet cestujících přicházejících na jednotlivé zastávky v čase (modeluje špičku/mimo špičku)
* Cílová zastávka každého cestujícího (kde vystupuje)
* Doba nástupu a výstupu cestujících

=== Data ===
* [https://www.dpp.cz/vozovy-park DPP – vozový park] – kapacity autobusů, typy vozidel
* [https://pid.cz/jizdni-rady-podle-linek/ PID – jízdní řády autobusů] – intervaly a rozložení spojů
* [https://www.dpp.cz/spolecnost/o-spolecnosti/dpp-v-datech DPP – statistiky] – počty cestujících, vytížení linek

Pro modelování rozložení cestujících v čase lze vycházet z běžných statistik dopravních podniků nebo využít odhadů podle typu linky (městská, příměstská, školní apod.).

=== Simulant ===
[[User:jelp05|jelp05]] ([[User talk:jelp05|talk]]) 18:35, 12 May 2025 (CET)

== Simulace: Šíření invazních druhů rostlin v krajině ==

=== Popis problému ===
Invazní rostliny představují závažný ekologický problém, který ohrožuje biodiverzitu, mění dynamiku ekosystémů a může způsobovat výrazné ekonomické škody. Přestože existují různé metody jejich potlačení, jejich účinnost se liší podle situace a podmínek v dané oblasti. Vzhledem k tomu, že přímé testování zásahů v reálném prostředí je nákladné a obtížně opakovatelné, bude v této práci navržena simulace, která umožní predikci vývoje a porovnání efektivity různých zásahových strategií.

=== Cíl simulace ===
Simulace bude navržena s cílem modelovat a analyzovat dynamiku šíření vybraných invazních rostlinných druhů v různých typech krajiny. Bude zohledňovat klíčové faktory ovlivňující rozšiřování – jako jsou podmínky prostředí (vlhkost, teplota, typ půdy), biologické vlastnosti rostlin (rychlost růstu, produkce a klíčivost semen) a způsoby šíření (např. pomocí větru, vody nebo lidské činnosti). Součástí modelu bude také testování různých zásahových strategií, jako je mechanická likvidace, aplikace herbicidů nebo jejich kombinace

=== Použití simulace ===
Výsledky simulace poskytnou náhled na chování invazních druhů v čase a prostoru a umožní testovat zásahy bez přímého zásahu do reálného ekosystému. Simulace bude sloužit jako nástroj pro podporu rozhodování v oblasti ochrany přírody, krajinného plánování a managementu invazních druhů. Výstupy bude možné využít například ochranářskými organizacemi nebo správci chráněných území pro návrh efektivních a šetrných zásahových postupů.

=== Použitá metoda a prostředí ===
Prostředí: NetLogo (agentní modelování)

=== Proměnné ===
Deterministické proměnné:
* Biologické vlastnosti rostlin (rychlost růstu, počet a klíčivost semen, vegetační cyklus)
* Podmínky prostředí (vlhkost, teplota, typ půdy)
* Strategické zásahy (mechanické odstraňování, chemická likvidace, kombinace metod)
* Typ krajiny (pole, louka, les, urbanizované prostředí)

Náhodné proměnné:
* Směr a dosah šíření semen
* Počáteční rozmístění rostlin
* Vliv náhodných klimatických odchylek

=== Data ===
Data pro model budou získána z databáze Agentury ochrany přírody a krajiny ČR (https://invaznidruhy.nature.cz), která poskytuje podrobné informace o biologických a ekologických vlastnostech jednotlivých invazních druhů. Další poznatky budou čerpány z odborné literatury a metodických doporučení pro boj s invazními rostlinami.

=== Simulant ===
[[User:kala13|kala13]] ([[User talk:kala13|talk]]) 19:54, 12 May 2025 (CET)