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

  1. Analyzujte hlavní funkční požadavky a nefunkcionální požadavky na systém, stanovte požadavky a cíle kvality.
  2. 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í).
  3. Připravte prvotní návrhy řešení architektury systémů.
  4. Sestavte srovnávací tabulky pro porovnání návrhů.
  5. Určete priority (váhy) jednotlivých charakteristik, případně jejich hierarchii.
  6. Analyzujte výsledky sumarizované v tabulce s ohledem na priority z kroku 5.
  7. Zvolte výchozí architekturu mezi kandidáty na základě předchozí analýzy.
  8. 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:

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í:

  • 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.

  • 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?

Zdroje

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

statnice/oi_si_prumyslove_aspekty_is_iso9126_skalovatelnost.txt · Poslední úprava: 2019/01/10 18:36 (upraveno mimo DokuWiki)
Nahoru
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0