Rizika » Historie » Revize 4
Revize 3 (Klára Beránková, 2017-04-13 16:52) → Revize 4/5 (Klára Beránková, 2017-04-13 16:53)
h1. Rizika * Frontend komunikuje s backendem pomocí REST API. Může nastat situace, kdy je potřeba zásadně změnit API a pak tak 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.