Analýza rizik » Historie » Revize 4
Revize 3 (Štěpán Faragula, 2025-03-19 18:33) → Revize 4/5 (Štěpán Faragula, 2025-03-19 20:09)
h1. Analýza rizik h3. Plánovací Časové * Vzhledem k časovému nátlaku, tlaku, zejména během zkouškového období, nemusí mít tým dostatek času na dokončení všech naplánovaných storek během iterace. projektu. * Rozdělení projektu na dvě části (TSP1 a TSP2) může vést k problémům při s koordinací a zajištěním plynulého přechodu mezi předměty, zejména u plánované funkcionality v TSP1, na kterou nezbyl čas. nimi. * *Řešení* * Během letního zkouškového období by se měl tým věnovat klíčovým úlohám, soustředit všechny dostupné síly na úkoly, které jsou nezbytné nejnutnější pro dokončení projektu v TSP1, a zbylé odložit zbytek nechat na později. * V rámci TSP1 je důležité soustředit se na dosažení základních funkcionalit, které budou sloužit jako základ pro TSP2. * U projektu je nutné definovat konkrétní cíle, které je třeba dosáhnout v TSP1 a TSP2. * Je nutné vytvořit hrubý časový plán pro obě části, včetně milníků a rezervy na nečekané problémy. h3. Předměty na škole * Jako studenti 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* *** 6/6 členů *** 3 semestrální práce 23.3.2025 + 13.4.2025 + 11.5.2025 ** *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* *** 6/6 členů *** průběžná kontrola 19.3.2025 *** 1 semestrální práce 30.4.2025 / 7.5.2025 ** *KFY/SMFT* *** 6/6 členů *** sepsání zprávy na dané téma *** povinná docházka 1x týdně ** *KIV/CICD* *** 5/6 členů *** semestrální práce 6.5.2025 ** *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ň 2x 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 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ů. h3. Technologická Technologické * Nedostatečná znalost používaných technologií (Java, Maven, SpringBoot, MySQL, Docker) vedoucí k neefektivnímu vývoji a chybám v implementaci. * Přechod mezi různými verzemi zvolených technologií (čeká nás přechod z Java 23 na Java 24) * Problém s pochopením zadání. * *Řešení* * Využití zdrojů a materiálů ze školy pro rychlé osvojení nezbytných technologií. * 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. h3. Bezpečnostní Technické * Datové pumpy budou pracovat s několika různými API klíči a přihlašovacími údaji uživatele, které nesmí být vyzrazeny. * Během vývoje může dojít k neúmyslnému vyzrazení těchto údajů na veřejnost (např. přenos mezi členy týmu, chyba v kódu). * *Řešení* * API klíče a přihlašovací údaje by měly být uloženy v šifrované podobě. * Je nutné najít způsob, jak si během vývoje bezpečně předávat citlivé údaje bez jejich vyzrazení. h3. Technická * Problémy s vývojovým prostředím (IntelliJ IDEA, Visual Studio Code). * Výpadky systémů Redmine a GitLab mohou narušit správu projektu a verzování, nebo úplně zastavit postup práce (např. Redmine 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í * Časová vytíženost zadavatele a mentora, kteří nemusí být vždy k dispozici, ani na online prostoru. * *Řešení* * Na schůzky si předem připravit seznam otázek a témat pro diskuzi, aby výnos schůzky byl byla každá schůzka co největší. 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. h3. Škálovatelnost * Návrh architektury systému nebude možné efektivně rozšířit, což může být problém zejména při implementaci konkrétních datových pump. * *Řešení* * Věnovat dostatečný čas a pozornost generickému návrhu pump, s ohledem na budoucí rozšíření o nové ALM nástroje. h3. Náhlá změna 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í* * Mít jasně definované požadavky na začátku projektu a průběžně prběžně předvádět funkcionalitu projektu na schůzkách se zadavatelem. ---- Autor: Štěpán Faragula Datum: 19.03.2025 18.03.2025 Stav: hotový