IV. Metodiky a metody návrhu, vývoje a provozu IS/ICT. ... Flashcards
Metodika - obecně
Metodika představuje v obecném smyslu souhrn metod a postupů pro realizaci určitého úkolu KDO?KDY?CO?JAK?PROČ?
- Metodiky zabývající se údržbou a vývojem IS bývají označovány jako metodiky vývoje IS/ICT.
- Kromě vývoje je rovněž důležité také nasazení hotového řešení, rozšíření řešení a integrace stávajících řešení, jsou tyto metodiky označovány jako metodiky budování IS/ICT.
- Metodiky budování IS/ICT = metodiky vývoje IS/ICT + metodiky provozu IS/ICT
Vývoj a provoz informačního systému je obtížné oddělit, neboť některé části IS (subsystémy, moduly, komponenty, služby aj.) jsou v daném okamžiku v provozu, některé jsou rozvíjeny, některé jsou vytvářeny nově a všechny musí být dohromady integrovány. Proto metodiky budování IS/ICT pokrývají jak oblast vývoje, tak oblast provozu IS/ICT.
Problematikou provozu IS/ICT se však nezabývají v celé šíři, neboť je tato oblast řešena v rámci metodik pro řízení informatiky (například COBIT, ITIL).
Termín metodika budování IS/ICT je vymezen následovně: Metodika budování IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení. Určuje kdo, kdy, co, jak a proč dělat během vývoje a provozu IS.
Metodika napomáhá
Metodika napomáhá
- k tomu, aby IS byl přínosem pro uživatele (organizaci, zákazníka, …)
- k tomu, aby byly provedeny všechny potřebné činnosti tvorby IS, a to ve správné časové posloupnosti
- k tomu, aby IS byl srozumitelně dokumentován
- k dobré organizaci práce na projektu
- k optimalizaci spotřeby zdrojů při tvorbě a provozu IS.
Základní požadavky efektivní využitelnosti metodik:
Základní požadavky efektivní využitelnosti metodik:
- musí jasně deklarovat soubor hodnot, na kterých je založena,
- musí určovat postup řešení, aby bylo možné celý proces vývoje IS/ICT plánovat,
- musí se zabývat všemi faktory (dimenzemi), které tvorbu a provoz IS ovlivňují
- musí určovat priority řešení (co a kdy je důležité),
- měla by doporučovat metody, techniky a nástroje, které je vhodné využít v jednotlivých fázích řešení.
Rigorózní metodiky
Rigorózní metodiky
V současnosti můžeme sledovat dva hlavní proudy v metodických přístupech, které jsou označovány jako rigorózní metodiky a agilní metodiky (popsány v otázce č. 9). Hlavním kritériem, které tyto dva proudy odlišuje, je „Váha metodiky“, ale liší se i dalšími hledisky.
V této kapitole jsou charakterizovány rigorózní metodiky, které vycházejí z přesvědčení, že procesy při budování IS/ICT lze popsat, plánovat, řídit a měřit. Snaží se podrobně a přesně definovat procesy, činnosti a vytvářené produkty, a proto bývají často velmi objemné. Rigorózní metodiky jsou zpravidla založeny na sériovém (vodopádovém) vývoji. Existují ale také rigorózní metodiky založené na iterativním a inkrementálním vývoji.
Příkladem těchto metodik jsou OPEN, Rational Unified Process (RUP), Enterprise Unified Process (EUP). V rámci rigorózních metodik tvoří samostatnou kategorii metodiky pro hodnocení softwarových procesů (Software Process Assesment). Metodiky hodnocení softwarových procesů jsou založeny na přesvědčení, že kvalita procesu určuje kvalitu produktu, a proto popisují postupy, které umožňují hodnotit úroveň zralosti procesů při vývoji software. Nejznámější z těchto metodik je Model zralosti (Capability Maturity Model for Software).
Charakteristika rigorózních metodik
Charakteristika rigorózních metodik
- těžké metodiky – podrobné, hodně formalit, direktivní řízení
- předpokládají opakovatelnost procesů, možnost definovat všechny požadavky na řešení předem
- příklady – OPEN, RUP, EUP, OOSP
- metodiky pro hodnocení SW procesů (Software Process Assesment) – Capability Maturity Model (CMM)
Metodika OPEN = Object–oriented Process, Environment and Notation
Metodika OPEN = Object–oriented Process, Environment and Notation
OPEN je veřejně přístupná metodika podporující celý životní cyklus vývoje IS/ICT. Je zaměřena zejména na vývoj objektově orientovaných a komponentových aplikací. Metodika OPEN definuje procesní rámec, známý pod názvem OPEN Process Framework (OPF). Jde o procesní metamodel, ze kterého mohou být generovány instance specifické pro organizaci.
OPEN je flexibilní, může se přizpůsobit jak doméně, tak konkrétnímu projektu, a zohlednit dovednosti členů týmu, kulturu organizace, požadavky specifické pro každou doménu. OPEN může být použit pro malé projekty, stejně jako pro velké, klíčové projekty.
Metodika RUP = Rational Unified Process
Metodika RUP = Rational Unified Process
Metodika Rational Unified Process je založena na tzv. nejlepších praktikách softwarového vývoje:
- iterativní vývoj
- řízení požadavků
- použití komponentové architektury
- vizuální modelování (UML, CASE nástroje…)
- kontrola kvality software
- řízení změn
Životní cyklus SW
Životní cyklus software je rozdělen na cykly. Předmětem každého cyklu je nová verze produktu. Jeden vývojový cyklus je v RUP rozdělen do 4 po sobě jdoucích fází:
- Počáteční fáze (Inception)
- Elaborační fáze (Elaboration)
- Konstrukční fáze (Construction)
- fáze Nasazení (Transition)
1. Počáteční fáze = Definice cílů projektu, požadavků, sestavení harmonogramu projektu (plán iterací), odhad nákladů projektu a definice rizik.
2. Elaborační fáze = Má za cíl definovat architekturu systému. V této fázi by měl být vytvořen prototyp.
3. Konstrukční fáze = Návrh a realizace systému včetně testování.
4. Fáze nasazení = Zajišťuje, aby uživatelé mohli systém používat. Součástí této fáze je školení uživatelů, předání dokumentace, vytvoření help-desk atd. Každá fáze je uzavřena milníkem – časovým okamžikem, ve kterém musí být splněny cíle fáze a dochází k rozhodování. Podstatným nedostatkem metodiky RUP je: zaměřuje pouze na vývoj řešení, ne na jeho provoz a údržbu.
Model zralosti SW – Capability Maturity Model for Software (SW–CMM)
Model zralosti SW – Capability Maturity Model for Software (SW–CMM)
Nejznámějším příkladem hodnocení softwarových procesů je Model zralosti SW (Capability Maturity Model for Software). Zralost softwarového procesu (Software Process Maturity) je dosažena, pokud je určitý proces explicitně definován, řízen, měřen, kontrolován a je efektivní. Zralost softwarových procesů vede ke zvýšení produktivity a kvality a zvyšuje se výkon procesu.
- označovaný zkratkou SW-CMM.
- vyvinut v Institutu pro softwarové inženýrství (Software Engineering Institute – SEI) za
- účelem hodnocení dodavatelů softwarových řešení pro ministerstvo obrany USA – v r. 1995
- Integrační model zralosti (Capability Maturity Model Integration, CMMI) od r. 2000
(1) Počáteční úroveň (initial)
- softwarové procesy jsou náhodné a chaotické
- organizace nemají stabilní prostředí pro vývoj a údržbu software, reagují pouze na vzniklé problémy.
(2) Opakovatelná úroveň (repeatable)
- organizace mají definovány a zavedeny postupy řízení projektu.
- softwarový proces je disciplinovaný
(3) Definovaná úroveň (defined)
- organizace má definovány, dokumentovány a standardizovány procesy pro řízení i softwarově inženýrské činnosti, které jsou navzájem integrovány v rámci celé organizace
- softwarový proces je standardní a konzistentní
(4) Řízená úroveň (managed)
- organizace má stanoveny detailní metriky softwarových procesů i kvality produktu
- softwarový proces je predikovatelný
(5) Optimalizovaná úroveň (optimizing)
- organizace má vytvořeny podmínky pro kontinuální zlepšování procesů.
Agilní metodiky
Agilní metodiky
- Důraz na častou komunikaci se zákazníkem, čímž je možné přesunout zodpovědnost za požadavky na zákazníka – zákazník určuje a mění priority funkcí
- Důraz na přidanou hodnotu pro zákazníka
- Založeno na důvěře a individualitě
- Pozitivní přístup ke změnám
Metodiky provozu IS/ICT
ITIL (Knihovna infrastruktury IT)
Soubor best practices pro řízení IT služeb – mezinárodně akceptovaný standard pro řízení IT služeb. Jsou to postupy popisující, co se má udělat. Jakým způsobem to podnik udělá, to už je na něm. Vedle těchto návodů poskytuje širokou škálu dalších produktů v oblasti školení, profesionální kvalifikace, konzultací, softwarových prostředků či výměny zkušeností.
COBIT
COBIT
COBIT je komplexní systém cílů a metrik podnikové informatiky. Tato metodika je oproti ITIL mnohem strukturovanější. Je to všeobecně přijímaný rámec pro zavádění a provoz IT Governance nad IT ve firmě. Významně pomáhá strategii firmy. Dále zavádí postupy měření a vyhodnocuje výkon IT. PIS je v tomto ohledu rozdělena do funkčních domén (plánování, implementace, provoz, monitoring), které obsahují konkrétní procesy. Ty jsou poměřovány 7 kritérii (efektivnost, výkonnost, důvěra, integrita, dostupnost, soulad, spolehlivost). Výsledná zjištění pak přisuzuje 5 zdrojům (personál, aplikace, technologie, vybavenost, data). Obsahuje také systém měkkých metrik, díky kterým je možné měřit úroveň zralosti IS – maturity model.
Agilní metodiky
Agilní metodiky
Agilní metodiky začaly vznikat v druhé polovině 90. let jako reakce na nedostatky tradičních rigorózních metodik. Umožňují vytvořit řešení velmi rychle a pružně jej přizpůsobovat měnícím se požadavkům. Tyto „lehké“ metodiky vývoje SW vychází z myšlenky, že jedinou cestou, jak otestovat software, je co nejrychleji ho vyvinout (nebo jeho část), předložit zákazníkovi a na základě zpětné vazby jej upravit. Jednotlivé agilní metodiky používají rozdílné techniky, ale jsou založeny na společných principech a hodnotách. V únoru 2001 byl podepsán „Manifest agilního vývoje softwaru“ a byla vytvořena „Aliance pro agilní vývoj softwaru“.
Agilní metodiky
Agilní metodiky:
- lehké metodiky, nepopisují procesy, ale praktiky, málo dokumentace, dávají přednost osobní komunikaci
- zaměřeny na ty činnosti, které vytvářejí hodnotu, eliminují činnosti, které hodnotu nepřinášejí
- inovace a kreativita se rozvíjejí v chaosu, proto málo procesů, spíše praktiky
- přesun zodpovědnosti za požadavky na zákazníka - zákazník určuje a mění priority funkcí
- spolupráce zákazníků a vývojářů
- využívají individualit a silných stránek lidí
Největší použitelnost se předpokládá u:
- výzkumných projektů
- time-to-market
- menších týmů
Principy agilních metodik
Principy agilních metodik
Výše zmíněný „Manifest agilního vývoje softwaru“ deklaruje čtyři hodnoty, přičemž tučně vyznačené prvky mají větší relativní význam než prvky vedle nich. „Odhalili jsme lepší způsob vývoje softwaru, sami jej používáme a chceme pomoci i ostatním, aby jej používali.
Manifest agilního vývoje dává přednost (2001):
- individualitám a komunikaci před procesy a nástroji
- provozuschopnému software před obsažnou dokumentací
- spolupráci se zákazníkem před sjednáváním kontrakt
- reakci na změnu před plněním plánu
Na základě tohoto manifestu bylo definováno 10 hlavních principů agilních metodik:
- včasná a kontinuální dodávka softwaru s hodnotou pro zákazníka
- změna požadavků i v průběhu vývoje
- každodenní spolupráce uživatelů a vývojářů
- podpora motivovaných jedinců
- osobní komunikace
- fungující software
- „zdravý vývoj“
- perfektní technické řešení i návrh
- jednoduchost řešení, maximalizace množství neudělané práce
- samoorganizující se týmy
Rozdíl mezi metodikami
Rigorózní metodiky:
- požadavky, procesy je třeba specifikovat předem a změnám se snažíme zabránit
- SW procesy lze popsat
- hodně formalit, dokumentace, direktivní řízení
- standardní projekty, velké projekty
- příklady: OPEN, RUP, EUP
Agilní metodiky:
- individualita, pozitivní přístup ke změnám
- důležitější než dokumentace je provozuschopný software
- klade důraz na přidanou hodnotu pro zákazníka
- spolupráce se zákazníkem – častá komunikace
