Analýza rizik¶

Plánovací¶

• Vzhledem k časovému ná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.
• Rozdělení projektu na dvě části (TSP1 a TSP2) může vést k problémům při přechodu mezi předměty, zejména u plánované funkcionality v TSP1, na kterou nezbyl čas.

• Řešení
• Během letního zkouškového období by se měl tým věnovat klíčovým úlohám, které jsou nezbytné pro dokončení TSP1, a zbylé odložit 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.

Předměty na škole¶

• Jako studenti 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.

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ů.

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.

Bezpečnostní¶

• 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í.

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 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í.

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 co největší.
• 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.

Š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.

Náhlá 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ísto okamžitého souhlasu nebo odmítnutí požadavku bychom se měli pobavit se zadavatelem o možných dopadech na projekt (co bude nutné implementovat, zda to stihneme, jestli to ovlivní ostatní části projektu).

---

Autor: Štěpán Faragula
Datum: 19.03.2025
Stav: hotový