Analýza rizik » Historie » Revize 3

« Předchozí | Revize 3/5 (rozdíl) | Další »
Štěpán Faragula, 2025-03-19 18:33

Analýza rizik¶

Vzhledem k časovému tlaku, zejména během zkouškového období, nemusí mít tým dostatek času 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.

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

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

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.

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

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

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 prběžně předvádět funkcionalitu projektu na schůzkách se zadavatelem.

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

Soubory (0)

Aktualizováno uživatelem Štěpán Faragula před asi 1 měsíc · 3 revizí