ASWI - Pokročilé softwarové inženýrství » ASWI 2025 » Dolování dat z ALM nástrojů do SPADe databáze (Pícha) - SKIBIDI OHIO RIZZLERS

h1. Analýza rizik

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

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

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á

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

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

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 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ý