Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- statnice:oi_si_prumyslove_aspekty_is_iso9126_skalovatelnost [2011/05/17 21:01]
vokabakov
+++ statnice:oi_si_prumyslove_aspekty_is_iso9126_skalovatelnost [2025/01/03 18:23] (aktuální)
@@ Řádek 1: / Řádek 1: @@
-Hotovo 10%
 ====== 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 =====
+====== 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.
@@ Řádek 11: / Řádek 9: @@
   * **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 ====
+===== 9126-1 Model jakosti =====
-  * **Funkčnost**
+  * **Funkčnost (Functionality)**
     * Funkční přiměřenost (Suitability)
     * Přesnost (Accuracy)
@@ Řádek 18: / Řádek 16: @@
     * Bezpečnost (Security)
     * Shoda ve funkčnosti (Functionality Compliance)
-  * **Bezporuchovost**
+  * **Bezporuchovost (Reliability)**
     * Zralost (Maturity)
     * Odolnost vůči vadám (Fault Tolerance)
@@ Řádek 46: / Řádek 44: @@
     * Shoda v přenositelnosti (Portability Compliance)
-===== ISO 9126 vs. ISO25000 =====
+====== 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 |
@@ Řádek 57: / Řádek 55: @@
 | 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

statnice/oi_si_prumyslove_aspekty_is_iso9126_skalovatelnost.1305658907.txt.gz · Poslední úprava: 2025/01/03 18:19 (upraveno mimo DokuWiki)

Nahoru