Analýza rizik » Historie » Revize 3
Revize 2 (Štěpán Faragula, 2025-03-18 21:46) → Revize 3/5 (Štěpán Faragula, 2025-03-19 18:33)
h1. Analýza rizik h3. Časové * Vzhledem k časovému tlaku, zejména během zkouškového období, nemusí mít tým dostatek času Jiné předměty na dokončení projektu. * Rozdělení projektu na dvě části (TSP1 a TSP2) může vést k problémům s koordinací a zajištěním plynulého přechodu mezi nimi. * *Řešení* * Během letního zkouškového období by měl tým soustředit všechny dostupné síly na úkoly, které jsou nejnutnější pro dokončení projektu v TSP1, a zbytek nechat na později. * U projektu je nutné definovat konkrétní cíle, které je třeba dosáhnout v TSP1 a TSP2. h3. Předměty na škole * Jako stutendi máme povinnosti i v jiných předmětech, které vyžadují strávený čas na semestrálních pracích a učení se na zápočty/zkoušky. *KIV/DB2* ** *KIV/DB2* *** 6/6 členů *** ** 3 semestrální práce 23.3.2025 + 13.4.2025 + 11.5.2025 * *KIV/IR* ** *KIV/IR* *** 6/6 členů *** ** domácí úlohy každý týden *** ** zápočtový test 8.4.2025 *** ** semestrální práce 28.5.2025 * *KPM/PMN* ** *KPM/PMN* *** 6/6 členů *** ** průběžná kontrola 19.3.2025 *** ** 1 semestrální práce 30.4.2025 / 7.5.2025 * *KFY/SMFT* ** *KFY/SMFT* *** 6/6 členů *** ** sepsání zprávy na dané téma *** ** povinná docházka 1x týdně * *KIV/CICD* ** *KIV/CICD* *** 5/6 členů *** ** semestrální práce 6.5.2025 * *KPM/APP* ** *KPM/APP* *** 3/6 členů *** ** 2 semestrální práce 18.3.2025 + 22.4.2025 *** ** zápočtový test ** * *UJP/AEP6* *** ** 2/6 členů *** ** esej 20.4.2025 *** ** abstrakt 14.4.2025 - 18.4.2025 *** ** prezentace 21.4.2025 - 25.4.2025 *** ** zápočtový test 28.4.2025 - 2.5.2025 *** ** povinná docházka 2x týdně * *Řešení* * Sledovat termíny a pravidelně komunikovat s ostatními členy týmu, aby se předešlo zpoždění projektu následkem práce na "nečekané" práci jinde. * Na schůzkách si rozdělit jednotlivé úkoly podle aktuálních školních povinností. Tímto způsobem nebude žádný člen týmu přetížen, a práce na projektu nebude mít zpoždění. * Většina deadlines jsou ke konci výuky v semestru, toho lze využít a nejvíc práce na projektu by se mohla plánovat na začátek semestru. h3. Zaměstnání * 2/6 členů jsou zaměstnaní, přičemž chodí do práce alespoň zaměstnaní * pravidelná docházka 2x týdně. týdně * Tato skutečnost může způsobit stres a ztížit koordinaci týmu, zejména pokud dojde k náhlým změnám v realizaci plánů. * *Řešení* ** Určit pravidelná setkání pro kontrolu pokroku a domluvit se možnost práce na minimálních požadavcích pro každý týden, aby bylo možné minimalizovat stres z práce. ** Pokud zaměstnaný člen bude mít problémy s časovým harmonogramem, ostatní členové mohou převzít část jeho úkolů. dálku (závažný důvod) h3. Technologické * Nedostatečná znalost používaných neznalost využitých technologií ** zvolené technologie (Java, Maven, SpringBoot, MySQL, Docker) vedoucí k neefektivnímu vývoji a chybám SpringBoot) ** tvorba GUI v implementaci. * Přechod mezi různými verzemi zvolených technologií (čeká nás přechod z Java 23 na Java 24) Javě * Problém s pochopením zadání. * *Řešení* ** databáze (MySQL) * Využití zdrojů a materiálů ze školy pro rychlé osvojení nezbytných technologií. ** kontejnerizace (Docker) * Před nasazením nových verzí provádět testy, aby se zajistilo, že nové verze nezpůsobí problémy s existujícím kódem. * Umožnit jednotlivým členům týmu vyzkoušet si nové technologie na malých projektech nebo prototypových úkolech, než se pustí do hlavní části projektu. nepochopení zadání h3. Technické * Problémy problémy s vývojovým prostředím prostředí (IntelliJ IDEA, Visual Studio Code). Code) * Výpadky výpadek systémů Redmine a GitLab mohou narušit správu projektu a verzování, nebo uplně zamrazit práci (Redmine wiki). * *Řešení* * Dostatečně dobře nastavené vývojové prostředí. * Při výpadku systémů udržovat pracovní verze projektu offline a komunikovat o změnách pomocí e-mailu nebo jiných komunikačních nástrojů, dokud se systém neobnoví. h3. Komunikační Komunikace * Časová vytíženost zadavatele a mentora, kteří nemusí být vždy k dispozici, ani na online prostoru. * *Řešení* *zadavatel* * Na ** pracovník KIV/ZČU, časově vytížený ** do odvolání možné schůzky si předem připravit seznam otázek a témat pro diskuzi, aby byla každá schůzka co nejefektivnější. * Po každé schůzce zaznamenat její průběh, což sníží potřebu častého opakování informací. * Při nejasnostech se ozvat co nejrychleji. pouze přes MS Teams h3. Změna požadavků * Během vývoje může zadavatel změnit některé požadavky nebo přidat nové funkce, což může vést k nutnosti upravovat již hotovou část projektu. * *Řešení* *mentor* * Mít jasně definované požadavky na začátku projektu a prběžně předvádět funkcionalitu projektu na schůzkách se zadavatelem. ** vedoucí katedry KIV/ZČU, časově vytížený ---- Autor: Štěpán Faragula Datum: 18.03.2025 Stav: hotový