17. Jaké metody modelování informačních systémů znáte?

Modelování – tvorba modelu, kdy se během jeho tvorby soustředíme jen na

nejnutnější detaily a ostatní zanedbáváme. V průběhu tvorby softwaru je potřeba

vytvořit řadu různých modelů, které odpovídají jednotlivým pohledům na řešený úkol.

 

Datový model - popisuje entity, atributy, vztahy a integritní omezení. Podmínky datového modelu: Musí existovat entita pro každý objekt, Vyloučit nadbytečné entity, Zanést všechny vztahy, Vyloučit odvoditelné vztahy, Udržet model v normální formě, Zanést všechny integritní omezení. Entity (student, učitel, předmět), vztahy (relace), atributy, integritní omezení... ER diagramy, relační modely, UML Classe diagramy....

 

Funkční model - popisuje služby, které systém poskytuje pro záznam, údržbu a využití dat

Podmínky funkčního modelu: Úplnost datového modelu, Vyloučit nadbytečné funkce a metody. Slouží k detailní identifikaci a specifikaci procesů, jejich struktury, vlastníků, vstupů, výstupů, omezení apod.

 

Dynamický model - popisuje možné stavy dat a jejich změny. Podmínky dynamického modelu: Úplnost dynamického modelu (model pro každou entitu, i včetně různých vztahů), Existence modelu pro každý řídící proces, Existence popisu životního cyklu systému

Datový model

• popisuje entity, atributy, vztahy a integritní omezení

Podmínky datového modelu:

• Musí existovat entita pro každý objekt

• Vyloučit nadbytečné entity

• Zanést všechny vztahy

• Vyloučit odvoditelné vztahy

• Udržet model v normální formě

• Zanést všechny integritní omezení

Vyvážení datového modelu:

• Datový model vs. datový slovník

• Datový model vs. funkční dekompozice

• Datový model vs. minispecifikace

Funkční model

• popisuje služby, které systém poskytuje pro záznam, údržbu a využití dat

Podmínky funkčního modelu:

• Úplnost datového modelu (metoda pro každou událost, každá funkce/metoda musí být popsána)

• Vyloučit nadbytečné funkce a metody

Vyvážení funkčního modelu:

• Funkční model vs. datový slovník

• Funkční model vs. datový model

• Funkční model vs. dynamický model

Dynamický model

• popisuje možné stavy dat a jejich změny

Podmínky dynamického modelu:

• Úplnost dynamického modelu (model pro každou entitu, i včetně různých vztahů)

• Existence modelu pro každý řídící proces

• Existence popisu životního cyklu systému

18. Jaké metody se používají pro řízení kvality vývoje informačních systémů?

COBIT, ITIL apod. jsou zaměřeny na procesy v informatice (COBIT) či řízení ICT (ITIL), podle zadání otázky jde jen o kvalitu vývoje (SW).

 

Definice jakosti softwaru říká: Je to shoda s explicitně stanovenými požadavky na funkci a chování, explicitně dokumentovanými vývojovými standardy a implicitními charakteristikami, které se očekávají od každého profesionálně vyvinutého softwaru. Jedná se o to, že kvalitní produkt musí být vytvořen kvalitním procesem. To platí, jak si ukážeme dále, pro software dvojnásob. Bez kvalitního vývoje si nemůžeme být jisti kvalitou výsledku. Kvalitu nemůžeme kontrolovat až potom, co byl vytvořen programový kód. Kvalitou se musíme zabývat během celého vývoje softwaru.

 

Terminologie a přístup k managementu jakosti se u různých autorů může lišit. Držme se normy ISO/DIS 9000:2000, která říká, že management jakosti jsou koordinované činnosti pro nasměrování a řízení organizace s ohledem na jakost.

Obvykle zahrnuje

1) stanovení politiky jakosti a cílů jakosti

2) plánování jakosti

3) řízení jakosti

4) zabezpečování jakosti

5) zlepšování jakosti.

 

Z hlediska řízení projektu se managementu jakosti týkají hlavně body 2)-4), které najdeme popsané i v americké normě pro projektové řízení [PMBOK].

Plánování jakosti spočívá ve stanovení cílů jakosti a specifikování procesů pro splnění těchto cílů. Výsledkem této činnosti je plán řízení jakosti.

Řízení jakosti je zaměřené na splnění požadavků na jakost. Spočívá ve sledování konkrétních výsledků projektu a posuzování, zda odpovídají standardům a stanoveným požadavkům. Pokud neodpovídají, navrhují se způsoby odstraňování příčin nevyhovujícího plnění.

Zabezpečování jakosti je zaměřené na poskytování důvěry, že jsou splněny požadavky na jakost. Je tedy zaměřeno na to, aby zákazník, vedení prováděcí organizace, případně další strany nabyly důvěry v kvalitu procesu a produktu (je to vlastně ujištění zákazníka nebo třetí strany o kvalitě). Činnosti pro zabezpečování jakosti mohou být prováděny i externě, třeba formou externího auditu.

 

Zabezpečení jakosti kvality

Ve starším pojetí byl proces zabezpečení jakosti nadřazen a zahrnoval i činnosti plánování a řízení jakosti. S tímto přístupen se setkáme v řadě softwarových knih. Podle [Pressman], jednou ze zastřešujících aktivit procesu vývoje softwaru je zabezpečování jakosti softwaru (SQA – Software Quality Assurance), která zahrnuje

• cíle managementu jakosti

• efektivní technologie (metody a nástroje)

• formální revize, přezkoumání

• strategii testování

• řízení softwarové dokumentace a jejích změn

• zajištění shody se standardy

• měření a vykazování

 

Příprava plánu řízení jakosti pro projekt.

Plán je vytvořen během plánování jakosti. Aktivity SQA jsou pak vedeny podle tohoto plánu.

Plán stanoví:

• prováděná vyhodnocování

• prováděné audity a přezkoumání

• standardy, které se mají použít v projektu

• procedury pro evidenci a sledování chyb

• dokumenty, které budou vytvářeny skupinou SQA

• zpětnou vazbu poskytovanou projektovému týmu.

 

Účast při vývoji popisu procesu softwarového projektu. Skupina SQA přezkoumá popis procesu vzhledem ke shodě s politikou organizace a externími normami (např. ISO) a ostatními částmi plánu projektu.

Přezkoumání analýzy a návrhu softwaru a verifikace vzhledem k definovanému softwarovému procesu. Skupina SQA identifikuje, dokumentuje a sleduje odchylky a verifikuje prováděné opravy.

Audity stanovených softwarových produktů, verifikace vzhledem k specifikacím. Skupina SQA identifikuje, dokumentuje a sleduje odchylky a verifikuje prováděné opravy, periodicky podává zprávy vedení projektu.

Zajištění, aby odchylky v softwarové práci a produktech byly dokumentovány a ošetřeny podle dokumentovaných procedur.

Zaznamenání všech neshod a vykazování managementu.

Navíc má skupina SQA koordinovat řízení změn a pomáhat při sběru a analýze softwarových metrik.

 

Techniky řízení jakosti softwaru

Přezkoumání, revize, testování, oponentura, inspekce, audit jsou různé typy kontroly. Jejich výklad se u různých autorů mnohdy liší, a to také v závislosti na rozdílném překladu z angličtiny.

Přezkoumání (nebo také revize, v angličtině review) je podle definice normy ISO činnost

prováděná k zajištění vhodnosti, přiměřenosti, efektivnosti a účinnosti předmětu s cílem

dosáhnout stanovených cílů. [Humphrey]rozlišuje tři základní metody přezkoumání:

• inspekci

• procházení (walk-throughs)

• osobní přezkoumání

 

Inspekce je formální metoda týmového přezkoumání podle přísných pravidel.

[Fagan] popsal inspekci softwaru s pevnou strukturou a pravidly.

Skládá se ze tří fází:

1. příprava

2. vlastní inspekce

3. zpráva

Příprava začíná krátkou schůzkou, kde se jsou účastníci inspekce seznámeni s problematikou tak, aby byl všem jasný produkt a jejich role během inspekce. Potom následuje individuální studium podkladů a odkrývání problémů a otázek. Vlastní inspekce je setkání inspekčního týmu s realizátory, kde se probírají nalezené problémy a vyjasňují případné otázky. V poslední fázi se specifikují nalezené defekty a píše se zpráva z inspekce.

Procházení (walk-through) podle Humphreye je méně formální metoda, která může spočívat v prezentaci pro spolupracovníky, případně pro uživatele. Realizátor prochází programem (nebo jeho návrhem) a vysvětluje posluchačům, jak program řeší jednotlivé situace. Cílem je objevit případná nedorozumění a nedostatky.

Osobní přezkoumání je aktivita, kterou provádí sám tvůrce. Autor by si měl projít analytický model, návrh softwaru nebo napsaný program předtím, než bude implementován, přeložen nebo testován. Měl by se snažit objevit, co nejvíc chyb dřív, než bude předložen k inspekci. Spoléhat na testování hotového programu se nevyplácí. Ideálnem je napsat program, který nebude mít žádnou chybu. Tím, že budeme jednotlivé vývojové fáze procházet a upravovat, aby byly průhledné a srozumitelné, vyhneme se celé řadě logických chyb. Pokud bude náš produkt srozumitelný a bude mít jasnou strukturu, usnadníme práci sobě i inspekčnímu týmu. Můžeme to srovnat s literární činností. Jen málo z knih, které se zdají být napsány lehce, byly takto napsány hned napoprvé. Obvykle se výsledný tvar rodí pomalu po mnohém přepisování. Domnění, že přezkoumáváním programového kódu ztrácíme čas, je mylné. Ušetříme si často mnohem delší dobu, kterou bychom strávili laděním špatně napsaného programu. Vyplatí se, když i do osobního přezkoumání vneseme řád. Tím může být předem připravený

postup třeba ve formě kontrolního seznamu, který nás povede. Pressman používá pro inspekci termín formální technická revize (FTR – Formal Technical Review). Jejím cílem je

• odkrýt chyby ve funkci, v logice, v implementaci

• ověřit, že software vyhovuje požadavkům

• ujistit se, že software je reprezentován podle definovaných standardů

• zajistit, aby software byl vyvinut jednotným způsobem

• docílit, aby projekt byl lépe řiditelný.

FTR má být prováděna v týmu o třech až pěti pracovnících. Vlastní revizní jednání by neměla být delší než dvě hodiny, pak přestává mít požadovaný efekt. Pokud jde o rozsáhlý produkt, je třeba jej rozdělit podle jeho struktury na menší části, které budou přezkoumávány samostatně. FTR může probíhat i v několika fázích. Každou FTR musí někdo vést a každé jednání musí někdo zapisovat. Mělo by se postupovat podle předem známého programu.

 

Opravdu účinné techniky jsou takové, které postupují podle předem daných pravidel. Avšak i méně formální techniky mají své místo. Mohou to být i pravidelná „posezení u kávy“ s kolegy, na kterých si vzájemně vyjasňujeme problémy.

Testování je prověřování funkčnosti produktu. U programu to znamená jeho spuštění za účelem nalezení chyb. Pokud testování chyby neobjeví, neznamená to, že v programu žádné chyby nejsou. Znamená to jenom, že jsme neprovedli správný test.

Simulace jsou ruční nebo poloautomatické procházení částí programu se symbolickým prováděním výpočtu.

Formální důkaz správnosti je metoda, která má formou matematického důkazu ověřit, že je program správný.

Evaluace je celkové zhodnocení rozsáhlých materiálů, provádí se technikou přezkoumání nebo inspekce. Může jít například o oponenturu požadavků (studie proveditelnosti, anglicky feasibility study). Zjištění, zda jsou požadavky úplné, bezesporné, ve shodě s cíly projektu.

Verifikace je ověření, zda výstupy etapy splňují požadavky vstupních dokumentů (shoda cíle a specifikací, návrhu a specifikací, kódu a návrhu a specifikací). Provádí se technikou přezkoumání, inspekce, procházení nebo čtení kódu. Dále se sleduje dodržování termínů, rozpočtu, know-how, norem a standardů.

Validace je předvedení a praktické ověření správné činnosti technikou testování.

Audit je prověření dodržování a stavu plnění úkolů nezávislou skupinou. Některou specifickou oblast (jako např. účetní audit, audit kvality podle normy ISO 9000) může prověřovat jen akreditovaná organizace.

 

Cena za jakost

Každá inspekce a každý test něco stojí. Každý další test může odkrýt další chyby a přispět tak ke zvýšení kvality produktu. Kdy to skončit? Kdy budeme s dosaženou kvalitou spokojeni? Jak vysokou cenu za kvalitu máme investovat? Pochopitelně se budeme snažit za minimální náklady dosáhnout maximální kvality.

Náklady na kvalitu můžeme dělit na náklady vynaložené na prevenci, na prověření a na odstranění chyb.

Do prevence patří plánování jakosti, školení týmu a také třeba pořízení nástrojů na testování. Náklady na prověřování zahrnují cenu za přezkoumání, inspekce a testování. Náklady na odstranění chyby se liší, byla-li chyba objevena před dodáním zákazníkovi (vnitřní chyba) nebo po dodání (vnější chyba).

Ukazuje se, že náklady dramaticky rostou od prevence defektů k jejich detekci, od odstraňování vnitřních chyb k odstraňování chyb vnějších.

 

Je pochopitelné, že cena za opravu defektu u zákazníka je tím větší, čím víc zákazníků produkt používá. Taková cena zahrnuje náklady za vyřízení reklamace, za vrácení produktu, jeho opravy a poskytnutí náhrady. Ztráta důvěry ve firmu následkem takové reklamace je cena, kterou lze jen těžko vyčíslit. V IBM je používán model zesilování defektů k ilustraci generování a detekci chyb během vývoje softwaru. Budeme si tento model ilustrovat v následující tabulce na hypotetickém příkladu. Myšlenka, na které je postaven tento model, říká, že v každém kroku vývoje softwaru můžeme a obvykle uděláme nějaké chyby. Jestliže je neobjevíme, přenáší se do dalšího kroku, kde buďto přetrvávají beze změny, nebo v častějším případě jsou zdrojem následných chyb – zesilují se.

 

Testování SW by mělo tvořit 70procent procesu řízení kvality, 30procent ověřování kvality dokumentace, analýzy, návrhu, zdrojových kodů, atd.

 

U softwaru vysoké kvality, který má stoprocentně splňovat požadavky klienta, je ověřování kvality celého vývojového procesu a současně každé jednotlivé části projektu nezbytné. Po celou dobu vývoje stačí vycházet z jednoduchého předpokladu: cena chyby s časem narůstá (čím později je chyba odstraněna, tím je odstranění dražší). Cílem tedy je zajistit takovou kvalitu vývoje aplikací, aby byly případné chyby nalezeny co nejdříve. Pro tyto účely je užitečné definovat kvalitu jako objektivní míru, jejíž stav lze zhodnotit testováním příslušné části systému nebo příslušných výstupů procesu vývoje softwaru.

 

Řízení kvality lze rozdělit na dvě roviny, na formální quality assurance (QA) a na věcné quality assurance. Předmětem formální části QA je kontrola výstupů dle zvoleného metodického rámce (Rational Unified Process, Prince 2 apod.), dále plánování a rozvržení jednotlivých aktivit, ověřování kvality a stanovení kritérií kvality výsledného produktu i dílčích výstupů. V praxi projektu se tedy jedná převážně o kontrolu formálních náležitostí jednotlivých procesů a výstupů při vývoji softwaru.

 

QA centrum je jednotka kompetentní za ověřování kvality, vedená QA managerem. Provádí formální i věcné řízení kvality v určených „měřících“ bodech procesu softwarového vývoje. Není náhodou, že tyto měřící body odpovídají typickým vývojovým disciplínám, tj. správě požadavků, analýze a designu atd. V každém měřícím bodu se aplikují obě roviny procesu ověřování kvality - jak formální QA, tak věcné QA.

 

Statistické přístupy k jakosti softwaru

Tak jako jinde i zde platí, že pokud se chceme zlepšovat, musíme své procesy měřit, naměřené hodnoty uchovávat, abychom měli porovnání a věděli, jestli se zlepšujeme nebo zhoršujeme, a abychom se z minulých chyb uměli poučit. Statistický přístup k jakosti softwaru se sestává z následujících kroků:

1. Sběr a kategorizace informací o softwarových defektech

2. Nalezení příčiny pro každý defekt (např. neshoda specifikací, chyba návrhu, porušení standardů, špatná komunikace se zákazníkem)

3. Identifikace závažných příčin. Paretův princip říká, že velkou část následků způsobuje jen malé procento příčin (Uvádí se typický poměr 80:20, který znamená, že zdrojem 80% všech chyb je jen 20% možných příčin).

4. Ošetření problémů, které způsobují závažné příčiny.

 

Diagram příčin a následků

Klasickým prostředkem pro vizualizaci a analýzu příčin a následků je Ishikawův diagram. Je nazván je podle japonského odborníka na zabezpečování jakosti prof. Kaoru Ishikawa. Jiný název je fishbone (rybí kost) diagram. Tak jak se vyhledávají příčinné jevy, které brání hladkému průběhu procesu, zakreslují se do diagramu. Přitom je možné znázornit jejich strukturální rozklad.