Rizika¶

• Frontend komunikuje s backendem pomocí REST API. Může nastat situace, kdy je potřeba zásadně změnit API a pak by klient nevěděl na čem je. Proto jednotlivé verze API budou viditelně očíslovány, verze API bude zakomponována do RESTových endpointů.

• REST API má být bezstavové, my zároveň potřebujeme ověřovat uživatele při některých akcí.
1. Buď je třeba posílat ověřovací údaje při každém takovém požadavku a tím pádem nastavit HTTPS protokol
2. nebo lze využít lepší varianty, jako je třeba OAuth, což by ale mohlo být dost náročné na nastavení.

• Závislost vývoje frontendu na backendu. Pro omezení či vyloučení závislosti (pro snažší a hladší vývoj převážně frontendu) je vhodné vytvořit mock server.

• Riziko výpadku služby. Pro produkční nasazení je důležité, aby backend běžel ve více kontejnerech v různých data centrech, aby se předešlo nedostupnosti služby z důvodu nasazování nové verze/výpadku-serveru/výpadku-datacentra.

• Riziko výpadku databáze. Toto riziko jsme přesunuli na poskytovatele služby, jelikož nakupujeme databázi jako službu.

• Přijetí od uživatelů. Je zde riziko, že uživatelé nebudou využívat nový systém. Tomu předejdeme tím, že je projekt postaven přímo dle potřeb zákazníka, kterému dodáme i jasnou dokumentaci(uživatelskou příručku), která do systému uvede nové uživatele.

• Za externí riziko považujeme zrušení nebo dlouhodobý výpadek poskytovatele cloudu. Nicméně vzhledem k zaměření projektu a renomé poskytovatele toto riziko považujeme za malé.

• Vzájemné porozumění se zákazníkem podporujeme pravidelnými meetingy a se zadavatelem také komunikujeme real-time prostřednictvím moderních nástrojů pro kolaboraci. Předcházíme tím riziku nedorozumění v požadavcích.

• Nedodržení termínů/nedodání funkcionality. Jelikož se jedná o školní projekt, nemáme jako tým dostatečné zázemí ani právní status, nemůžeme se tedy závazně zavázat prakticky k ničemu.