Charakterizujte možné varianty řešení IS/IT podniku z hlediska zodpovědnosti za tvorbu, integraci a provoz IS/IT. Analyzujte přínosy a rizika těchto variant.
Promítání změn do projektu, dlouhodobá údržba projektu, důvody změn, odpovědnost za údržbu, předpoklady údržby projektů, životnost projektu, přípravy inovace projektu, autorský dozor
1.1. Životnost projektu
Každý automatizační projekt prochází 3 obdobími:
1) období tvorby projektu a jeho ověřování
2) období relativní spolehlivost projektu (rutinní využívání)
3) období morálního znehodnocení projektu
· V prvním období se odstraňují nedostatky, ověřují se programy..
· Druhé období znamená průběžnou údržbu projektu, promítání změn, které nenarušují základní filosofii systému.
· Třetí období je podle rozboru jednotlivých stadií projektování nejdůležitější. Každý projekt se mění a vyvíjí v čase - často dochází k prudkému znehodnocení projektu. Je to způsobeno nespolehlivostí stárnoucího počítače, zastarávání dokumentace, potřebou řešit nové požadavky uživatelů, v dnešní době způsobují asi nejvíce znehodnocení projektů změny právních předpisů a hospodaření vůbec.
1.2. Dlouhodobá údržba
q stadium rozvoje a údržby systému nabylo veliké důležitosti
q v některých podnicích existuje už dnes v analyticko programátorských úsecích převaha prací zaměřených na údržbu a doplňování již realizovaných projektů
q např. 80 % všech kapacit firmy slouží údržbě a vývoji dříve vytvářených objektů
q je nutné zabývat se otázkami:
§ jaké jsou příčiny změn
§ jak tvořit projekty snadno udržovatelné
§ kdo má realizovat zásahy do projektů
§ jak slouží dokumentace k podpoře údržby projektů
1.3. Důvody změn
charakter změn
q změny snadno realizovatelné(nové výstupní sestavy, změny algoritmů bez změny DZ, ..)
q změny závažného charakteru (změna DZ, změna filosofie zpracování úlohy, ..)
promítání změn do projektu je závislé na celkovém návrhu projektu
pokud se v návrhu počítá s budoucím vývojem, pak se změny v projektu snadno realizují
1) Změny od uživatelů
vnitřní vývoj systému řízení v podniku
q každý projekt je odrazem určitého stavu systému řízení a slouží k podpoře tohoto systému
q důležité je, aby změny v systému řízení byly před jejich utvářením konfrontovány s projektanty a případně byly modifikovány, aby nezasáhly rušivě do stávajících projektů
q při dobré spolupráci je možné provádět řadu změn se stávajícími daty
vnější vlivy na podnik
q trh, legislativa
q tyto vnější vlivy jsou uživateli projektu interpretovány jako nezbytně nutné zásahy do řízení a zprostředkovaně do projektů = jsou nutné pro přežití podniku
q tyto změny přinášejí velké ztráty způsobené přepracováním projektů
q je třeba zvážit, zda je lépe projekty změnit, či vytvořit nové
zjištění chyb a nedostatků v uživatelských projektech
q týká se to hlavně velkých projektů, kde je často pomocí zkušebních souborů dat ověřena pouze část variant, hlavně z důvodů časových nákladů na zkušební provoz
2) Změny z pozice řešitelů
změny výpočetního systému
q nový HW, SW,OS, SŘBD
q lze jej rozdělit na inovaci celého systému či dílčích částí
optimalizace některých funkcí projektu
q zlepšení spolehlivosti, komunikace, bezpečnosti, efektivnosti, objektivizace DZ
q optimalizaci projektu je třeba provádět uváženě, neboť velké zásahy do projektu mohou znamenat narušení stability a omezení dalšího vývoje projektu
nejčastěji jsou požadované změny vyvolány uživatelskou sférou
její schválení nesmí být soukromou věcí či dohodou mezi programátory a uživateli
většinou je stanoven kolektiv vedoucích pracovníků, kteří hodnotí požadované změny do projektu
Kdo změny realizuje:
q zbytky původního řešitelského týmu
q provozní programátoři
q kdokoliv z analytiků a programátorů
Dohled nad provozem mají provozní programátoři a při dobré dokumentaci jsou schopni realizovat malé změny do projektu.
1.4. Předpoklady údržby
q mít metodu projektování
q strukturovaný přístup
q perfektní dokumentace (automatizovaná)
q určení odpovědnosti za údržbu
q předpokládat, že se systém bude udržovat
q nové metody CASE - zlepšuje dokumentaci, přehlednost, strukturovanost, transparentnost, ..
1.5. Příprava inovace projektu
q prostudovat si dostupnou dokumentaci
q specifikovat charakter změny a akceptační kritéria - projednat to s uživatelem
q návrh realizace změn
q změny v projektu (zachování původního kódování, ..)
q vytvoření plánu testů, ověření funkcí po změnách
q implementace opraveného systému - uvedení do provozu a zaznamenávání všech změn do dokumentace
1.6. Další souvislosti
q kde jsou hranice únosných změn systému
q odhad budoucího vývoje systému (vyhodnocování dotazů, reklamací, automatizovaných statistik provozu
q sledování nákladů o změnách
q seznámení uživatelů se změnami
q sledování vytíženosti HW
q shoda stavu systému se stavem globální a informační strategie
Žádné komentáře:
Okomentovat