Technická podpora

h1. Životní cyklus projektu

Po vyřešení základních otázek plánování, návrhu a řízení, nastává životní cyklus projektu, který je tvořen následujícími částmi.

# Předběžná analýza, neboli specifikace cílů.

# Analýza systému, neboli specifikace požadavků.

# Projektová studie, neboli návrh.

# Implementace.

# Testování.

# Zavádění systému.

# Zkušební provoz.

# Rutinní provoz a údržba.

# Reengineering.

h2. 1. Podrobný popis jednotlivých částí životního cyklu IS

h3. 1.1 Předběžná analýza, neboli specifikace cílů

Základem celkového návrhu, vývoje i jakékoli úpravy stávajícího systému jsou požadavky uživatelů a cíle organizace. V této části se musí dané požadavky shromáždit, v hrubých rysech rozebrat a odhadnout dobu realizace a náklady. Cílem je pouze sestavit základní rámec požadavků, cílů a funkcí, ne je podrobněji rozebírat, to je úkolem další etapy.

Celkový rámcový projekt by tedy měl obsahovat zhruba následující věci:

# Časový plán projektu.

# Zdroje nutné k řešení, čímž je míněno finance, personál, SW, HW a podobně.

# Odhad funkčnosti, rozsahu systému, ekonomické efektivnosti a návratnosti investice.

Nástroje pro vytvoření specifikačního projektu:

# Analýza současného stavu, cílem je zjistit současný stav, nedostatky a navrhnout změny.

# Získání požadavků uživatelů a zjištění požadovaných vstupních a výstupních informací.

# Seznam problémů, které jsou známy, popis jejich důsledků a nástin řešení.

Konečným dokumentem této části je dokument, který specifikuje účel systému, identifikuje jeho uživatele a jejich zásadní požadavky, definuje části systému a navrhuje jejich řešení, obsahuje seznamy událostí a odhady datové základy, technického a softwarového zajištění.

h3. 1.2 Analýza systému, neboli specifikace požadavků

Tato část cyklu je rozborem části předchozí. Její důležitost je klíčová, neboť veškeré chyby ve struktuře dat i systému, které se zde neodhalí, jsou později velice obtížně odstranitelné.

h3. 1.3 Projektová studie, neboli návrh

Tato část je výsledkem analýzy systému. Výsledkem je dokument, který je podkladem pro obsah smlouvy s externí firmou o návrhu a realizaci IS, časový harmonogram, cena vyvíjeného projektu, konkrétní  implementace systému (patří sem logický datový model a fyzický datový model), podmínky zavádění v organizaci, záruční servis a podmínky celkového předání IS.

Prvky studie, které musí obsahovat:

# Základní informace o tvůrcích systému, v případě externí firmy její specifikace, dále pokud jde o systém složený z několika podsystémů také informace o jejich dodavatelích.

# Základní informace o organizaci pro kterou je systém vyvíjen, včetně uvedení týmu zaměstnanců, kteří popřípadě budou spolupracovat s externí firmou.

# Popis současného stavu organizace.

# Globální návrh IS, neboli logický datový model, který je návrhem funkcí a dat systému bez ohledu na technologické prostředí.

# Detailní návrh IS, neboli fyzický datový model, který obsahuje funkční analýzu systému, datovou analýzu, popis veškerých datových toků v organizaci a popis funkcí řízených událostmi. Celkovým výstupem je návrh funkcí a dat budoucího systému, které jsou definovány na základě prostředí, ve kterém bude systém implementován.

# Detailní popis nasazení IS v praxi, SW a HW studie související s nasazením nového IS.

# Detailní popis testovacího provozu systému, včetně poskytování záručního servisu.

# Celkový harmonogram spolupráce, do něhož patří časový harmonogram dodávky, platby, celková cena, podmínky dodání, ceny pozáručního servisu a podobně.

Při tvorbě studie nesmíme zapomínat na to, že je nutné veškerá fakta uvést v dostatečně detailním provedení a v podobě, která bude pochopitelná všem členům vedení, kteří provádí závěrečná rozhodnutí (tím je míněn zejména logický datový model). Celá studie by měla být vytvářena s vědomím, že je to poslední dokument, se kterým se management setká před konečným rozhodnutím o realizaci systému. V případě dohody mezi firmou a tvůrci systému tato studie slouží jako podklad realizace systému a podklad pro podmínky předání a testování.

h3. 1.4 Implementace

Tato část životního cyklu IS je vlastním programováním, kterého se účastní vybraní experti v programování a analytik nesoucí zodpovědnost za správnost řešení. Jako podklady pro jejich práci slouží veškeré informace shromážděné předchozími etapami a fyzický návrh systému.

Postup práce je následující. Na základě získaných faktů z fyzického návrhu se definují vstupy a výstupy jednotlivých operací a určí způsob jejich modifikace. Naprogramují se veškeré funkce a doladí se jejich vzájemné propojení. Dále se jednotlivé realizované funkce ověří a připraví se testovací data, která musí obsahovat maximální procento konečných reálných dat.

h3. 1.5 Testování

V této etapě se provádí připravené testy na hotovém IS. Je nutné vyzkoušet veškeré možné reakce systému na zadávaná data a zjištěné nedostatky opravit. Testování se často provádí na systému, který ještě není v reálném prostředí, neboť případné selhání by mohlo mít rozsáhlé následky. Příkladem jsou systémy ve zdravotnictví, letectví, jaderném průmyslu a podobně.

h3. 1.6 Zavádění systému

Zaváděním systému je míněna především jeho instalace, zavedení do provozu organizace, transformace původní datové základny tak, aby byla přístupná novému systému, poskytnutí manuálů a školení uživatelům. Při školení je nejlepším postupem nejprve školit vedoucí pracovníky a pokračovat zaměstnanci v provozu.

Tato etapa se nesmí v žádném případě podcenit, neboť jejím zanedbáním by mohla u budoucích uživatelů vzniknout averze vůči novému systému a tím neúspěch celého projektu.

Zavedení systému může být provedeno jedním z následujících způsobů.

# Souběžná strategie – je založena na pokračujícím provozu původního systému + současný provoz nového systému. Provoz obou systémů trvá několik pracovních cyklů, dokud nový systém nepracuje spolehlivě a uživatelé s ním nejsou dostatečně seznámeni. Tato metoda je bezpečná, ale velice náročná pro zaměstnance, neboť musí provádět dvakrát totéž, což by mohlo vést k averzi vůči novému IS. Proto se na toto období najímají externí pracovníci.

# Pilotní strategie – je založena na zavedení nového systému jen ve vybrané části podniku a po jeho ověření se systém zavede do celé organizace. Jako pilotní část se vybere taková, která je poměrně náročná a je možné na ní ověřit co nejvíce problémových oblastí.

# Postupná strategie – využívá se zejména u velice složitých systémů, kde jsou složité vnitřní vazby. Nejprve se zavádějí primární části IS na kterých ostatní části závisí, po jejich ověření se podobným postupem zavádí ostatní části až po zavedení celého systému.

# Nárazová strategie – spočívá v odstranění původního systému a zavedení kompletního nového systému. Tato strategie je velice riskantní, ale ušetří se při ní čas i pracovní síly.

h3. 1.7 Zkušební provoz

Zkušební provoz je celková realizace projektu, ve které je poskytovatel povinen zajistit okamžitý servis, odstranit chyby zjištěné během provozu, nebo dořešit dodatečné požadavky uživatelů v rámci původního návrhu.

h3. 1.8 Rutinní provoz a údržba

Tato etapa je závěrečnou fází projektu, ve které je systém provozován a používán. Do této etapy také spadá údržba systému, tedy zajištění správného provozu, úprava parametrů aplikací nebo změny některých programů tak, aby splňovaly nové požadavky uživatelů. Mezi základní povinnosti zajištění provozu IS patří organizace prací na počítačích a v síti tak, aby byl zajištěn soulad s původním projektem a dokumentací, zajištění přístupových práv k jednotlivým aplikacím, sledování činnosti počítačů a síťových prostředků z hlediska výkonu a poruchovosti, zajištění optimálního provozu systému, zabezpečení systému a ochrana dat před neoprávněným přístupem, nebo minimalizace škod vzniklých výpadkem systému např. záložními systémy nebo archivací dat. V neposlední řadě do této etapy také patří i opětovné školení uživatelů.

h3. 1.9 Reengineering

Tato etapa je přehodnocením požadavků na systém a pokud je nelze již splnit pouhou úpravou, je krokem vedoucím na počátek životního cyklu.

h2. 2. Základní modely životního cyklu systému

h3. 2.1 Model vodopád – System Development Method (SDW)

Základní charakteristikou modelu vodopád je, že při návrhu IS se provádí postupně jednotlivé etapy životního cyklu, které na sebe navazují a vzájemně se neprotínají. Etapy se provádí podle přesného plánu realizace a zpětně se k nim nevrací, dokončená etapa je vstupem etapy následující.

Tento model patří mezi klasické modely životního cyklu používané již v 70.letech k výstavbě automatizovaných systémů řízení. Cílem jeho vzniku bylo zavést do vývoje systémů jednotný řád, umožnění řešení komplexnějších problémů díky hierarchické dekompozici a snížení množství chyb precizní kontrolou všech výstupů jednotlivých etap.

Následující schéma vyjadřuje návaznost jednotlivých fází modelu vodopád.

!model_sdw!

Výhody modelu vodopád:

* ·           Tento postup je poměrně rychlý i levný pokud se nevyskytnou problémy. Je vhodné tento postup uplatnit při návrhu systému, kde je přesně známý problém a způsob jeho řešení.

* ·           Zavedení pevné struktury a kontroly do návrhu IS a ušetření lidských i finančních zdrojů.

Nevýhody:

* ·           Reálné projekty lze málokdy řešit v krocích definovaných modelem vodopád.

* ·           Konečný výsledek zjistíme až po poslední fázi návrhu, tedy až po předání. Bohužel uživatel si často uvědomí své skutečné potřeby až v tuto chvíli. Z těchto faktů plyne, že pokud se objeví chyby až po předání, je jejich oprava poměrně drahá a cena opravy je tím větší, čím více uzavřených fází leží mezi místem výskytu chyby a místem objevení chyby.

* 

* První verze kompletních systémů jsou k dispozici až po delší době, vlastně až v konečných fázích řešení a zákazník musí být velice trpělivý, což se obvykle nestává.

Některé z nevýhod modelu vodopád řeší jiné metodiky jako například prototypový vývoj (založený na vývoji částečně funkčního modelu) nebo postupný vývoj, mezi který patří inkrementální vývoj (tedy vývoj  jednotlivých částí) a iterační vývoj (tedy vývoj celého projektu, ale pouze v základním malém objemu).

Model vodopád lze chápat jako univerzální model, který má své nevýhody, ale je podstatně lepší než náhodný, metodicky neřízený přístup k řešení systému.

h3. 1.2.2        Prototypový model

Základní charakteristikou prototypového modelu je předpoklad změn výchozích požadavků zákazníků a umožnění reakce na tyto změny, čímž se liší od modelu vodopád.

!model_prot!

Tento model se začal prosazovat v 80.letech. Jeho hlavním cílem je urychlení vývoje IS využitím prototypů a seznámení zákazníka s prvními verzemi systému v co nejkratší době. Prototyp můžeme chápat jako zjednodušenou implementaci celého systému nebo jako plnou implementaci části systému. Tato implementace je provedena v co nejkratším čase a v takové funkčnosti, která prezentuje veškerá vnější rozhranní a umožňuje zákazníkovi reagovat na výsledky. Na základě připomínek zákazníků jsou upřesňovány požadavky a modifikován prototyp do té doby, dokud zákazník není spokojen. Poté následuje samotný návrh a implementace celého systému.

Výhody prototypového modelu:

* Model umožňuje co nejpřesněji obsáhnout požadavky budoucích uživatelů a reagovat na jejich změny.

Nevýhody:

* Tato metoda je u rozsáhlých systémů poměrně náročná, proto se většinou předem určuje množství opakování prototypů a každé z nich musí být provedeno do stanoveného termínu.

h3. 1.2.3        Model spirála

Tento model vytvořil B.W.Boehm v roce 1988 a je kombinací prototypového přístupu a analýzy rizik. Základem celého modelu je neustálé opakování vývojových kroků tak, že v každém dalším kroku se na již ověřenou část systému přibalují části na vyšší úrovni. Postup vývoje v jednotlivých krocích je shodný s původním modelem vodopád a každý krok se skládá z následujících částí.

# Specifikace cílů a určení plánu řešení.

# Vyhodnocení alternativ řešení a analýza rizik s daným řešením souvisejících.

# Vývoj prototypu dané úrovně a jeho předvedení a vyhodnocení.

# Revize požadavků, neboli validace (testování zda prototyp pracuje tak jak má).

# Verifikace, neboli ověření zda celkový výstup daného kroku je v souladu se zjištěnými požadavky.

Náklady a čas nutný na realizaci jednotlivých částí projektu, či na řešení celého projektu jsou patrné z modelu, neboť úhlová dimenze udává časovou náročnost a radiální úroveň udává rostoucí náklady.

Následující schéma vyjadřuje návaznost jednotlivých fází modelu spirála.

!model_spir!

Výhody modelu spirála:

* ·           Model využívá ověřené kroky vývoje a analýzou rizik předchází chybám.

* ·           Umožňuje konzultovat požadavky zákazníků v jednotlivých krocích a modifikovat systém podle upřesněných požadavků.

* ·           První verze systému je možné sledovat a hodnotit při jejich postupném vzniku.

Nevýhody:

* ·           Řešení systému pomocí tohoto modelu vyžaduje neustálou spolupráci zákazníků, proto není vhodný zejména pro systémy vyvíjené na zakázku bez účasti budoucích uživatelů.

* ·           Neumožňuje přesné naplánování termínů, cen a jednotlivých výstupů a tím i jejich plnění.

* ·           Je nutné provést bezchybnou analýzu rizik a vybrat aspekty u nichž budeme rizika prověřovat, neboť na této analýze jsou založeny další fáze projektu. Pozdní zjištění komponent s vysokou mírou rizika může mít zásadní vliv na celý projekt.

* ·           Malá členitost modelu vyžaduje zkušené programátory, při nutnosti podrobnějšího členění je nutné zajistit precizní kontroly výstupů.

https://www.fi.muni.cz/~smid/mis-zivcyk.htm