====== Prumyslové aspekty IS, nefunkcionální požadavky na systémy podle ISO 9126, kapacitní plánování systémů, zajištění odezvy a škálovatelnosti systému.(A0M33PIS) ======

====== ISO 9126 ======
Normy řady ISO 9126 stanovují obecné požadavky na jakost softwarového produktu. V současnosti jsou postupně nahrazovány novou (velmi podobnou) řadou norem ISO 25000, vyvíjených v rámci mezinárodního normalizačního projektu SQuaRE.  

  * **9126-1 Model jakosti** - přináší model kvality a specifikuje 6 charakteristik jakosti, kde každá charakteristika má několik podcharakteristik
  * **9126-2 Vnější metriky** - externí metriky pro měření
  * **9126-3 Vnitřní metriky ** - interní metriky pro měření
  * **9126-4 Metriky pro jakost použití**  - zabývá se problematikou jakosti při použití softwarového produktu (Quality in Use).

===== 9126-1 Model jakosti =====
  * **Funkčnost (Functionality)**
    * Funkční přiměřenost (Suitability)
    * Přesnost (Accuracy)
    * Schopnost spolupráce (Interoperability)
    * Bezpečnost (Security)
    * Shoda ve funkčnosti (Functionality Compliance)
  * **Bezporuchovost (Reliability)**
    * Zralost (Maturity)
    * Odolnost vůči vadám (Fault Tolerance)
    * Schopnost zotavení (Recoverability)
    * Shoda v bezporuchovosti (Reliability Compliance)
  * **Použitelnost (Usability)**
    * Srozumitelnost (Understandability)
    * Naučitelnost (Learnability)
    * Provozovatelnost (Operability)
    * Atraktivnost (Attractivness)
    * Shoda v použitelnosti (Usability Compliance)
  * **Účinnost (Efficiency)**
    * Časové chování (Time Behaviour)
    * Využití zdrojů (Resource Utilisation)
    * Shoda v účinnosti (Efficiency Compliance)
  * **Udržovatelnost (Maintainability)**
    * Analyzovatelnost (Analysability)
    * Měnitelnost (Changeability)
    * Stabilnost (Stability)
    * Testovatelnost (Testability)
    * Shoda v udržovatelnosti (Maintainability Compliance)
  * **Přenositelnost (Portability)**
    * Přizpůsobitelnost (Adaptability)
    * Instalovatelnost (Installability)
    * Slučitelnost (Co-existence)
    * Nahraditelnost (Replaceability)
    * Shoda v přenositelnosti (Portability Compliance)

====== ISO 9126 vs. ISO25000 ======
^ ISO 9126      ^ ISO 25000 (SQuaRE)      ^ 
| Metrik je navrženo příliš mnoho (přes 200), není jasné, které kdy vybrat | Vytváří jednotnou architekturu řady norem a zastřešující příručku |
| Není jasné, jak formulovat potřeby a převést je do měřitelných požadavku | Vytvořit příručku pro to, jak užívat metriky |
| Není jasné, kterou „jakost“ zkoumat (vnitřní, vnější, produktu)| Definuje primitiva pro měření, např. prvky měřené přímo (čas, počet, kategorie) |
| 9126-1 Model jakosti | Zavádí metriky pro objektivizaci požadavků na jakost |
| 9126-2 Vnější metriky | 25010 Model jakosti |
| 9126-3 Vnitřní metriky | 25020 Metriky |
| 9126-4 Metriky pro jakost použití | 25030 Požadavky na jakost |
| 9126-5 Základní softwarové metriky | 25040 Vyhodnocování jakosti |

====== Volba architektury IS – doporučené kroky ======
  - Analyzujte hlavní funkční požadavky a nefunkcionální požadavky na systém, stanovte požadavky a cíle kvality.
  - Použijte přizpůsobený standard ISO 9126, resp. ISO 25000 jako rámec pro hodnocení (obvykle vyžaduje dodefinovat specifické metriky a ukazatele podle konkrétních systémových požadavků, např. na specifické komponenty nebo rozhraní).
  - Připravte prvotní návrhy řešení architektury systémů.
  - Sestavte srovnávací tabulky pro porovnání návrhů.
  - Určete priority (váhy) jednotlivých charakteristik, případně jejich hierarchii.
  - Analyzujte výsledky sumarizované v tabulce s ohledem na priority z kroku 5.
  - Zvolte výchozí architekturu mezi kandidáty na základě předchozí analýzy.
  - Je-li vyžadována podrobnější analýza, soustřeďte se na charakteristiky relevantní problémové doméně, s ohledem na priority, získané v kroku 5.

====== Škálovatelnost (rozšiřitelnost) ======
**vlastnost systému, indikující jeho schopnost přizpůsobit se rostoucím požadavkům na kapacitu, výkon, odezvu, dostupnost systému a atd., popřípadě být připraven na rozšíření.**

Škálovatelnost je často omezena
návrhem/implementací systému

**Dimenze škálovatelnosti**
  * **Load scalability**: Schopnost distribuovaných systémů rozšířit/zúžit využitelné zdroje v závislosti na zátěži. Alternativně, schopnost snadné modifikace systému nebo komponenty podle zátěže.
  * **Geographic scalability**: Schopnost udržet výkonnost, použitelnost atd. v podmínkách geografického rozšiřování.
  * **Functional scalability**: Schopnost rozšiřování systému o nové funkcionality s minimalizací úsilí.

**Kompromisy k řešení při návrhu systému:**
  * výkon vs. škálovatelnost
  * cena vs. škálovatelnost (contribution margin = revenue – variable costs)
  * operabilita vs. škalovatelnost – škálovatelnost rozsáhlých a komplexních systémů omezuje možnosti „manuální“ správy systému
  * funkcionalita vs. škálovatelnost 
  * konsistence replikace dat vs. škálovatelnost

**Kategorie škálovatelnosti:**
  * **Vertikální škálovatelnost (scale up)**
    * přidávání zdrojů jednomu uzlu systému (typicky přidání procesoru, rozšíření paměti), včetně rekonfigurace pro využití nových zdrojů (např. zvětšení počtu démonů Apache web serveru)
  * **Horizontální škálovatelnost (scale out)**
    * přidávání nových uzlů do systému (typicky u distrib.aplikací), např. rozšíření z jednoho webserveru na tři, rozšíření gridu, zvýšení počtu procesoru

===== HW škálovatelnost =====
Často se doporučuje soustředit se na hardwarovou rozšiřitelnost před kapacitní. Je levnější přidat procesor, než ladit výkon.

Příklad: Část programu lze zrychlit o 70%, je li spouštěna paralelně na čtyřech CPU. Je-li 1-P sekvenční část výpočtu a P je část, kterou lze paralelizovat, maximální zrychlení s využitím N procesorů udává Amdahlův zákon:

{{:statnice:amdahl_corrected.png|}}

Pozn.: Mám za to, že ve jmenovateli má být znaménko +, tj. (1-P)+P/N, nikoli (1-P)-P/N, viz http://en.wikipedia.org/wiki/Amdahl%27s_law 

Čím více snížím paralelizovatelnou složku P/N, tím menší bude její příspěvek ve jmenovatel a tím i vyšší hodnota zlomku = zrychlení
(founemi2)

====== Zajištění odezvy systému - Real Time systémy ======
  * systém reálného času - informační systém, který zpracovává asynchronní vstupy a produkuje odpovědi v pevně stanoveném čase.
    * Doba, kterou má systém k dispozici pro provedení úlohy, je známa předem.
    * Na počtu vstupů a jimi vyvolané pracovní zátěži systému přitom nezáleží.
  * systém reálného času - informační systém, který zpracovává asynchronní vstupy a produkuje odpovědi.
    * potřebný čas může být odvozen ze zátěže systému 
    * tento čas musí být ohraničený->nejdelší možná doba odezvy.
  * **hard RT** - systém vždy musí splnit daný časový termín (např. řízení létajícího prostředku, jaderného reaktoru aj.)
  * **soft RT** - konkrétní časové okamžiky mohou být zmeškány. (např. optimalizace spotřeby paliva v motoru).
  * požadavky pro RTOS definuje standard Posix 1003.1b, Real-time extensions

==== Zajištění odezvy systému – řízení přístupu ke zdrojům (workload manager) ====
  * **servisní třídy** (service classes) a jejich důležitost - klasifikační mechanismus jednotlivých úloh
  * **cíle** (goals) a **úrovně priorit** (importance levels) servisních tříd – určují očekávaný pracovní výkon a mohou být definovány pomocí:
    * **doby odezvy** (response times goals) – aplikace musí komunikovat s WLM
    * **relativní rychlosti** (velocity goals) – založeno na relativní rychlosti zpracování stanovované podle měření systémových stavů (system states)
    * **volné** (discretionary goals) - pokud neexistují žádné jiné požadavky.
  * Doba odezvy udává trvání pracovního požadavku (work request) mezi zadáním do systému a okamžikem, kdy je operace je hotova.
    * WLM se poté snaží zajistit, aby průměrná doba odezvy skupiny pracovních požadavků byl dle očekávání, nebo aby část pracovních požadavků splnila očekávání uživatelů.
  * Systémové stavy popisují, kdy pracovní požadavky používaly systémové zdroje a kdy na ně musely čekat - stavy zpoždění. Definujeme rychlost zpracování:
  {{:statnice:screen_shot_2011-05-17_at_9.43.13_pm_2_.png|}}
  * Stanovení rychlosti zpracování nevyžaduje komunikaci aplikace s WLM, avšak není tak přesné jako doba odezvy.

  * Servisní třídy a definice cílů jsou organizovány v politice služeb spolu s ostatními komponentami pro reporting a další řízení. Vše je uloženo jako definice služeb (service definition), podle které se určuje přednostní přístup servisních tříd k systémovým zdrojům (při příliš vysoké zátěži systému).
  * WLM shromažďuje data o činnosti a systémových zdrojích a porovnává v předem definovaných časových intervalech s uživatelskými definicemi z definic služeb a upravuje přístup k systémovým zdrojům, pokud nebylo dosaženo požadavků uživatelů. K porovnání nashromážděných dat s definicemi cílů se vypočítává index výkonu (performance index, PI).
  * **Index výkonu** je číslo, které udává, zda definice cílů pro danou servisní třídu byly splněny, nesplněny nebo překonány.
{{:statnice:screen_shot_2011-05-17_at_9.44.48_pm_2_.png|}}
  * WLM kontroluje přístup k procesorům systému, I/O jednotkám, systémovému úložišti a spouští a ukončuje procesy. Disponuje mechanismy k umístění pracovních požadavků na nejvhodnější systém u paralelního zpracování.

====== Kapacitní plánování systému ======
===== Základní otázky pro kapacitní plánování IS=====
  * Jaké výkonostní metriky (data) mají být sledovány?
  * Jak často mají být data sbírána?
  * Co jsou relevantní prahové úrovně nebo akceptovatelné provozní úrovně?
  * Co se má provést, jsou-li určité prahové nebo provozní úrovně překročeny?
  * Jak je sbírána statistika pro charakterizaci zatížení, jeho predikce, modelování výkonnosti, kapacitní plánování a konfiguraci?
  * Kdo jsou účastnící těchto procesů? 
  * Jaké jsou jejich role?

{{:statnice:screen_shot_2011-05-18_at_9.00.46_am.png|}}

{{:statnice:screen_shot_2011-05-17_at_9.51.14_pm_2_.png|}}

{{:statnice:screen_shot_2011-05-17_at_9.52.30_pm_2_.png|}}


====== Zdroje ======
Přednášky předmětu A0M33PIS