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í. Buď je třeba posílát ověřovací údaje při každém takovém požadavku a tím pádem nastavit HTTPS protokol a nebo jsou ještě lepší varianty jako je třeba OAuth, což by 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 cetnrech, aby se předešlo nedostupnosti služby z důvodu nasazování nové verze/výpadku server/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řijení 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 na potřeba zákazníka, kterému dodáme i jasnou dokumentaci, která do systému uvede nové uživatele.

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

• Vzájemené 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 k prakticky k ničemu.