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

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

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.

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

Č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)

• 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

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

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

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