Popis rizik » Historie » Revize 2
« Předchozí |
Revize 2/3
(rozdíl)
| Další »
Jan Kebrle, 2017-03-31 22:55
Popis rizik a strategie jejich odstranění¶
Nízká produktivita h2.
Popis: Každý z členů týmu má nějaké mezery (často výrazné) ve znalostech použitých technologií (Spring, Hibernate, Angular.js), doba nutná k zaučení a nevyhnutelné začátečnické chyby mohou způsobit výrazné překročení časové dotace úkolů.¶
Řešení: Rozdělení práce tak, aby každý člen co nejlépe využil již existující znalosti. Včasné zaškolení či doučení potřebných znalostí.
Absence kritických znalostí
Popis: Některé ze znalostí, které budou v průběhu projektu nezbytně potřeba, aktuálně nemá žádný z členů týmu. Získávání těchto znalostí až ve chvíli kdy budou potřeba, by mohlo vést k nepřesnému plánování časové náročnosti a nepředvídatelným komplikacím.¶
Řešení: Včasné doučení potřebných znalostí a jejich vyzkoušení při řešení podobného či zjednodušeného problému.
Časová vytíženost členů týmu
Popis: vzhledem k charakteru vývoje projektu a extrémnímu časovému vytížení členů týmu (studují a zároveň pracují), mohou nastat neočekávaná zpoždění při plnění úkolů. Tím by také mohlo dojít ke zpoždění případných návazných úkolů.¶
Řešení: Včasná identifikace úkolů kritických pro hladký průběh dalšího vývoje. Přesné odhadování časových možností členů týmu.
Nevhodně navržená architektura
Popis: Nevhodný návrh architektury by v průběhu projektu mohl zpomalit vývoj (např. obtížným testováním či složitou integrací komponent).¶
Řešení: Návrh architektury s ohledem na jednoduchost testování a modularitu.
Nedostatečná flexibilita architektury
Popis: Architektura nebude navržena dostatečně obecně a zapracování změnových požadavků zákazníka bude nákladné či si vyžádá změny architektury.¶
Řešení: Promyšlení potenciálních rozšíření aplikace, důraz na univerzálnost a maximální abstrakci navrhovaných API.
Nezkušenost týmu s návrhem softwarové architektury
Popis: Hrozí reálné riziko, že i při nejlepší snaze bude nutné architekturu kvůli nedostatkům v návrhu během projektu změnit, což bude nákladné.¶
Řešení: Štědrá časová dotace a zapojení všech členů týmu (případně zákazníka), by mohlo pomoci identifikovat slabiny v návrhu. Anticipace tohoto problému by se měla projevit v návrhu architektury, která bude v přiměřené míře umožňovat dodatečné změny či úpravy.
Nekompatibilita operačních systémů
Popis: Přestože všechny použité technologie budou multiplatformní, mohou se vyskytnout neočekávané problémy s kompatibilitou, protože aplikace bude vyvíjena na OS Windows, avšak výsledný produkt nasazen na OS Linux.¶
Řešení: Periodické testování aplikace na obou prostředích by mělo včas odhalit většinu problémů s nekompatibilitou a umožnit jejich lokalizaci.
Zřízení a správa produkčního prostředí
Popis: Dosud není jasné, kde poběží produkční prostředí. Univerzitou poskytnutý aplikační server však bude každopádně mimo kontrolu týmu. Pokud se vyskytne problém se serverem, bude k jeho nápravě nutné kontaktovat pověřenou osobu. Nikdo z týmu nemá zkušenosti se správou a konfigurací linuxového aplikačního serveru.¶
Řešení: Vyjednat aplikační server a produkční prostředí co nejdříve. V případě nutnosti zřídit vlastní aplikační server pro potřeby testování a získání potřebných zkušeností.
Aktualizováno uživatelem Jan Kebrle před asi 8 roky(ů) · 2 revizí