Menu

Příklady projektových a produktových rizik

V minulém díle seriálu jsme kategorizovali rizika na produktová a projektová a zmínili algoritmus pro výpočet „jak hodně nás dané riziko pálí“. V tomto díle zmíníme příklady rizik z obou kategorií, na které můžete narazit v praxi. Seznamy níže mohou posloužit na vašich jako kontrolní seznam (checklist) při identifikaci rizik.
Mezi častá projektová (plánovací) rizika patří:

  • nedostatečná komunikace uvnitř týmu, se zákazníkem, sponzorem či dalšími zainteresovanými osobami (stakeholdery),
  • současná práce členů projektového týmu na více projektech,
  • nezkušenost lidí zapojených do projektu,
  • ztráta motivace týmu,
  • nerealistické termíny,
  • špatně definované zadání projektu (nejasné či neúplné požadavky),
  • neustále se měnící požadavky,
  • nedefinovaná či špatně definovaná akceptační kritéria,
  • neexistující či špatně nastavený přístup k verzování výstupů (configuration management),
  • ztráta vytvořených artefaktů (selhání hardwaru, krádež),
  • špatně ošetřené závislosti mezi dodávkami jednotlivých komponent,
  • nedostatečné testování,
  • nedostatečné zaškolení budoucích uživatelů,
  • změny kurzovního lístku (zejména při projektech, kde jsou náklady a příjmy v různých měnách),
  • legislativní či politické změny.

Do kategorie produktových (kvalitativních) rizik spadají například:

  • zadání platebního příkazu skončí s chybou,
  • výpočet pojistného spočítá chybně splátky,
  • výpočet počítá chybně na hranicích intervalů vstupních hodnot,
  • chybové hlášení je nesrozumitelné,
  • formulář pracuje chybně při použití české diakritiky,
  • v rozbalovacím seznamu ve formuláři nejsou všechny položky, které by tam být měly,
  • aplikace nefunguje korektně ve všech prohlížečích, v nichž měla fungovat,
  • aplikace nefunguje korektně při výměně databázového engine,
  • aplikace je nesrozumitelná pro uživatele,
  • aplikace umožňuje přihlášenému uživateli realizovat funkce, které by mu neměly být dostupné,
  • do aplikace je možné se přihlásit, aniž by měl příslušný uživatelský účet,
  • v aplikaci je možné neoprávněně manipulovat daty v databázi (např. tzv. SQL injection útok),
  • aplikace reaguje pomalu na požadavky uživatele,
  • rychlost aplikace degraduje v čase od restartu,
  • aplikace není schopna obsloužit požadované množství současných uživatelů,
  • funkcionality, které měly zajistit korektní zálohování a obnovu, nedokáží uvést aplikaci do původního stavu,
  • aplikace konzumuje místo na disku nadměrným způsobem

V dalším díle seriálu se podíváme na základní proces řízení rizik.
Tento článek čerpá z knihy Efektivní testování software.

Comments

Dear user, this website uses cookies to ensure you get the best experience on our website. More about cookies
I give my consent to processing of my personal data. More info