Analýza, posouzení a ošetření rizik technických systémů

Popis problému, stávající stav

Má seminární práce se bude zabývat problematikou tvorby softwarového systému pro malou firmu, a to od rozhodnutí jejího majitele až po finální předání produktu zákazníkovi. Z mého hlediska se jedná o běžný problém, který jsem nucen v rámci svých pracovních povinností řešit několikrát do roka. Software musí splňovat veškeré požadavky zákazníka a být dodaný včas. Také je nutno, aby celý SW prošel předem specifikovanou množinou akceptačních testů a byla k němu vhodně vypracovaná uživatelská dokumentace.

Pracovníci

Profese a počet pracovníků

V hlavním zájmu práce bude stát vývojář, který software navrhuje a následně se podílí na jeho implementaci. Vedlě něj pak v procesu vystupujke další řada pracovníků:

• CZ-ISCO 11203 ředitel malé organizace – ředitel a majitel společnosti
• CZ-ISCO 25120 Vývojáři softwaru – druhý vývojář podílející se na projektu
• CZ-ISCO 25190 Spacialista na testování SW - tester

Kvalifikace, certifikáty a osvědčení pracovníků

• ředitel a majitel společnosti (vlastní společnost)
• druhý vývojář podílející se na projektu (bakalářský nebo vyšší studijní program v oboru informatiky)
• tester (započatý studijní program v oboru informatiky)

Mechanizmy a pomocné prostředky

Při procesu bude kalkulováno s využitím následujících prostředků:

• Stolní PC (oba vývojáři, tester)
• Standardní systém pro správu verzí (oba vývojáři, tester)
• Notebook (hlavní vývojář)
• Kávovar (oba vývojáři, tester)
• Bílá tabule (oba vývojáři, tester)

Seznam použitých materiálů

Jako základní materiál bude v procesu vývoje poižito následující:

• Bílý papír (oba vývojáři, tester, majitel společnosti)
• Popisovače na tabuli (oba vývojáři, tester)
• Káva (oba vývojáři, tester)

Vývojový diagram procesu

Zde je znázorněn vývojový diagram tvorby softwarového řešení pro firmu

Získání zakázky

Tato fáze řeší proces od počátku hledání vhodného zákazníka až po přijetí zakázky

Hledání zákazníka

Dostatečný přísun zakázek je jednou z hlavních podmínek přežití softwarové firmy. Zároveň je však výhodné hledat zákazníky v takových oborech, se kterýma již má firma zkušenosti a celý vývoj je tudíž výrazně levnější.

Oslovení zákazníka

Ve chvíli, kdy se podařilo úspěšně lokalizovat zákazníka v dostatečně blízkém oboru, je třeba zájazníka oslovit a zjistit, zda by měl o nový systém zájem.

Pokud zákazník software nepotřebuje, proces se vrací k hledání zákazníka

Předběžné zadání

Zjištění rámcových potřeb a požadavků zákazníka na nový systém a následná analýza, zda je pro nás výhodné tuto zakázku plnit (předběžná analýza náročnosti versus ceně, kterou je zákazník ochotný platit).

V případě, že zakázku není výhodné brát, proces se vrací zpět k hledání zákazníka.

Získání více informací

Důkladná zpověď zákazníka ohledně jeho potřeb, v případě nejasností pozorování dění a procesů ve firmě po nějakou dobu. Poté je také potřeba získané znalosti a poznámky konzultovat s ředitelem oslovené firmy a podepsat specifikaci softwaru včetně specifikace akceptačních testů.

Analýza a návrh

V této sekci se budu zabývatčástí procesu, ve které dochází k vytvoření návrhu software a předvedení tohoto návrhu zákazníkovi

Analýza získaných informací

V této fázi projektu dochází k vytvoření všeobecných závazných pokynů, jak má vypadat návrh a implementace softwaru tak, aby splňoval požadavky zákazníka. Jedná se také o de-facto první krok v iterativním modelu vývoje.

Návrh uživatelského rozhraní

Jako první věc je třeba navrhnout vzhled uživatelského rozhraní a běžných ovládacích prvků, aby bylo možno návrh předvést zákazníkovi (uživatelské rozhraní je první věc, se kterou se zákazník setká a reaguje na něj nejintenzivněji)

Návrh zásadních částí

V tomto kroku dochází k návrhu zásadních funkčních částí softwaru

Vytvoření Mock-Up

Zde je třeba vytvořit jen částečně funkční verzi softwaru, aby si jej zákazník mohlů osahat a vznést připomínky v co nejdřívější části vývoje a bylo tedy možné dodatečně upravovat specifikaci bez výrazného navýšení ceny vývoje.

Prezenatce zákazníkovi

Mock-Up vytvořený v předchozím kroku je prezentován zákazníkovi, se kterým je následně probírána jeho vhodnost a jsou vzneseny připomínky jak ke vzhledu tak k funkčnosti (v rámci možností).

V případě, že zákazník není spokojen s kteroukoliv částí, vývoj se vrací opět k analýze s upravenými informacemi od zákazníka.

Implementace

Implementace chybějících částí

Dochází k dokončení implementace zákazníkových požadavků, které nebyly plně dokončeny v prototypu.

Interní testování

Hotový produkt je předán testovacímu specialistovi, který postupně projde veškeré možné scénáře použití každé vlastnosti programu a vypňuje hlášení o těchto chybách do interního bugtracking systému.

V případě, že se v této fázi najdou chyby, následuje jejich oprava. V případě, že se již žádné chyby nenaleznou, pokračuje se ke tvorbě dokumentace.

Oprava chyb

Chyby nalezené testovacím specialistou jsou vývojáři opraveny a je k těmto chybám napsaná testovací specifikace, aby se zabránilo jejich opětovnému znovuzavlečení opravou jiné chyby (vytváří se tzv. regresní testy).

Po opravě chyby je systém opět celý testován

Testování

Tvorba dokumentace

Vývojář píše uživatelskou dokumentaci k hotovému produktu

Akceptační testy

Testovací specialista za přítomnosti zákazníka (ředitel společnosti) provede sadu akceptačních testů, které zaručují, že software splňuje požadavky zákazníka.

Pokud by některý z kaceptačních testů neprošel, následuje fáze opravy této chyby. Do tohoto kroku se proces bude dostávat pouze velmi vyjímečně.

Oprava chyb

Dochází k opravě chyb nalezených při akceptačních testech. Po opravě chyby se přechází k opětovnému provedení akceptačních testů.

Předání produktu zákazníkovi

Produkt je celý předán zákazníkovi, je podepsán předávací protokol a vystavena faktura na výsledný produkt.

Kontroly a sledované znaky kvality, environmentu a bezpečnosti

Vstupní kontrola

Před začátkem procesu vývoje zakázkového software je třeba provést několik kontrol, zda je možno tento proces dokončit. Ta se týká především kontroly vhodnosti pracoviště a pracovních stanic jednotlivých zaměstnanců.

Vstupní kontrola bude zahrnovat následující:

Vstupní kontrola pracoviště

Celý proces probíhá na pracovišti umístěném v prostorách firmy. Tudíž je třeba zajistit vhodné rozložení stolů vzhledem k osvětlení kanceláří jednotlivých zaměstnanců. Dále je třeba zkontrolovat stav kancelářských židlí jednotlivých zaměstnanců a nevyhovující nahradit. Vhodné je také provést kontrolu funkčnosti klimatizace a/nebo vytápění.

Také je třeba provést kontrolu funkčnosti rozvodu elektrického proudu a jeho případného zálohování.

Vstupní kontrola materiálů

Je třeba zajistit, aby všichni účastníci měli dostatěčný přísun kávy a čaje. Dále je vhodné zajistit dostatečnou zásobu fixů pro črtání na tabuli a čistý přípravek pro její mazání.

Vstupní kontrola zařízení

Vedle výše uvedených kontrol je také třeba zajistit plnou funkčnost IT infrastruktury, která bude použita pro vývoj.

Je tedy třeba zajistit funkčnost serveru s verzovacím systémem, zálohovacího serveru a také dostupnost a volné místo na cloudové zálohovací službě (ta je potřeba kvůli existenci druhého, geograficky nezávislého zálohovacího úložiště).

Dále je třeba zajistit plnou funkčnost síťové infrastruktury a připojení k internetu. Je tedy potřeba zkontrolovat konfiguraci routeru, zvláště pak správného nastavení VPN, aby bylo možno efektivně komunikovat s vnitřní infrastrukturou při setkání se zákazníky.

Mezioperační kontrola

V rámci procesu vývoje software bude také probíhat mezioperační kontrola vždy v průběhu a po ukončení každé fáze naznačené ve vývojovém diagramu. Kontrola po závěrečné fází pak bude provedena v rámci výstupní kontroly, která je zároveň součástí fáze 4.

Mezioperační kontrola v průběhu 1. fáze

V průběhu 1. fáze – získání zakázky bude nejprve osloven zákazník, zda nemá zájem o nový software. V případě, že ano, proces může pokračovat dále. Pokud by zákazník zájem neměl, osloví se další zákazník.

Provede se analýza předběžného zadání zda jej jsme schopni splnit a v případě že ano, proces pokračuje.

Mezioperační kontrola po ukočení 1. fáze

Po dokončení první fáze procesu bude zjištěno, zda jsou bližší data od zákazníka relevantní pro vypracování analýzy. Pokud ano, proces pokračuje, jinak je třeba zjistit více relevantních informací.

Mezioperační kontrola v průběhu 2. fáze

V průběhu této fáze dochází převážně k ověřování relevance návrhu vzhledem k analýze získaných informací. Pokud návrh vyhovuje analýze, proces pokračuje, jinak je třeba jej upravit.

V této fázi je již také potřeba kontrolovat pečlivé dodržování termínů dohodnutých se zákazníkem. V případě, že termín není možno stihnout, je třeba o tom zákazníka uvědomit co nejdříve.

Mezioperační kontrola po ukončení 2. fáze

Po dokončení druhé fáze je nutno konzultovat výsledný mock-up se zákazníkem a v případě nespokojenosti je potřeba opět získat více doplňujících informací a zopakovat celý proces analýzy a návrhu.

Mezioperační kontrola v průběhu 3. fáze

V průběhu fáze implementace je potřeba, aby každá implementovaná část prošla sadou předem připravených interních testů (unit tests). V případě, že některý test skončí chybou, je třeba tuto chubu opravit a testy znovu spustit. V případě, že všechny testy proběhnou bez chyb, proces pokračuje.

Výstupní kontrola

Před předáním produktu zákazníkovi je třeba, aby proběhla kontrola akceptačním testováním. Zde je kontrolováno, zda software splňuje veškeré zákazníkovy požadavky. Nejprve je sada akceptačních testů spuštěna přímo ve firmě, aby bylo možno zjištěné chyby co nejrychleji opravit. V případě, že akceptační testy skončí bez chyb, proces pokračuje.

Dále je software nasazen u zákazníka a v prostředí zákaznické firmy je opět spuštěna sada akceptačních testů. Pokud testy proběhnou i zde bez chyby, je software finálně předán zákazníkovi. V opačném případě opět dochází k odstranění chyb a opakování celého procesu výstupní kontroly.

Analýza a zhodnocení rizik

Zhodnocení rizik bylo provedeno pomocí metody FMEA a nachází se v příloze 1.

V rámci tohoto procesu byly identifikovány tři rizika s RPN vyšším než 100, u kterých byla následně provedena nápravná opatření. U dvou rizik se tímto podařilo RPN snížit pod hranici 100.

Kvalitativní rizika

Následující kapitola se bude zabývat kvalititivními riziky, které mohou v procesu nastat.

Rizika a nebezpečí

V celém procesu vývoje software může nastat celá řada rizik, které následně mají negativní dopad na kvalitu celého procesu. Seznam všech rizik s jejich ohodnocením se nachází v příloze 1 a to včetně detailního popisu jejich následků a nástrojů jejich detekce a prevence.

Diagram příčin a následků

Následující diagram ilustruje tzv. nepříznivou situaci, která může v procesu tvorby softwaru nastat a která způsobí nedodržení termínů dohodnutých se zákazníkem. Tomuto předchází řada příčin, které jsou rozděleny dle původce děje a kategorie rizika (kvalitativní rizika jsou znázorněna modře).

Hodnocení rizik a nebezpečí

Hodnocení rizik a nebezpečí bylo provedeno metodou FMEA a je dostupné v příloze 1. U závažných rizik je pak také uvedena jejich prevence.

Paretův diagram

Seřazením rizik jednotlivých procesů od největšího počtu bodů k nejmenšímu můžeme vytvořit relativní a kumulativní četnost jevů. Na základě těchto údajů je pak možné sestavit Paretův diagram.

Enviromentální rizika

Rizika a nebezpečí

V celém procesu vývoje software může nastat celá řada rizik, které následně mají negativní dopad na kvalitu celého procesu. Seznam všech rizik s jejich ohodnocením se nachází v příloze 1 a to včetně detailního popisu jejich následků a nástrojů jejich detekce a prevence.

Diagram příčin a následků

Následující diagram ilustruje tzv. nepříznivou situaci, která může v procesu tvorby softwaru nastat a která způsobí nedodržení termínů dohodnutých se zákazníkem. Tomuto předchází řada příčin, které jsou rozděleny dle původce děje a kategorie rizika (enviromentální rizika jsou znázorněna modrozeleně).

Hodnocení rizik a nebezpečí

Hodnocení rizik a nebezpečí bylo provedeno metodou FMEA a je dostupné v příloze 1. U závažných rizik je pak také uvedena jejich prevence.

Paretův diagram

Seřazením rizik jednotlivých procesů od největšího počtu bodů k nejmenšímu můžeme vytvořit relativní a kumulativní četnost jevů. Na základě těchto údajů je pak možné sestavit Paretův diagram.

Rizika BOZP a PO

V procesu nebyla identifikována žádná rizika související s problematikou BOZP a PO.

Shrnutí, závěr, havarijní připravenost a reakce

Shrnutí problematiky a závěr

Celá práce se věnuje problematice tvorby softwarového systému pro malou firmu z pohledu vývojáře. Tomuto tématu se věnuje od získávání zakázky až po její finální předání zákazníkovi. Celý proces, kterým se tato studie zabývá jsem navrhl na základě vlastních zkušeností, jelikož jsem se podílel na tvorbě několika takovýchto systémů.

V první kapitole práce se věnuji definici problematiky, představení potřebných účastníků a jejich požadovaných kvalifikací a také definování mechanismů, které jsou k realizaci procesu nezbytné.

Druhá kapitola obsahuje vývojový diagram procesu a následný podrobný popis jednotlivých konkrétních podprocesů.

Třetí kapitola se věnuje vstupní, mezioperační a výstupní kontrole. Vstupní kontrola se věnuje kontrole pracoviště, kontrole potřebných materiálů a kontrole technického zařízení. Mezioperační kontrola vychází z jednotlivých kontrolních bodů popsaných ve vývojovém diagramu a obsahuje kontroly, nutné pro úspěšný průběh respektive zakončení jednotlivých fází procesu. Výstupní kontrola následně spočívá v provedení akceptačních testů přímo v zákazníkově firmě a následném podepsání testovacího protokolu.

Ve čtvrté kapitole se věnuji analýze a zhodnocení rizik. Pomocí metody FMEA jsem identifikoval čtyři velké rizika, z nichž se tři povedlo následně snížit na malou úroveň. Hodnocení jednotlivých rizik poté zobrazuji v podobě Parettova diagramu.

Havarijní připravenost a reakce

V průběhu procesu neočekávám žádné závažné havárie, které by jej mohly nepříznivě ovlivnit.

V případě výpadku elektrické energie jsou veškeré servery zálohovány UPS zdrojem a následně agregátem. Pro práci zaměstnanců je v takovémto případě možnost použít notebooků. Pro případ problémů s dodávkou vody či tepla je možno využít možnosti tzv. home office.

Pro případ poruchy serveru nebo osobního počítače je pak možno kontaktovat technickou podporu výrobce zařízení a uplatnit next bussiness day záruku. V případě serveru se pak navíc jeho úlohu přebírá záložní stroj.

Havarijní připravenost a reakce u tohoto procesu není upravována žádným předpisem, zákonem či normou. Z tohoto důvodu jsem přílohu č. 2 nezahrnul do tohoto dokumentu.

Použitá literatura a odkazy

Seznam norem a použité literatury

Vymazal, T., Mika, J., O., Učební texty k předmětu 2CRT dostupné z www.fce.vutbr.cz/szk

Seznam www odkazů

/online/ www.istp.cz

/online/www.fce.vutbr.cz/szk