Proces obecně je po částech uspořádaná množina kroků směřujících k dosažení cíle. Je-li cíl vytvoření softwaru pak mluvíme o softwarovém procesu. Disciplína zabývající se problémy softwarového procesu se nazývá softwarové inženýrství.

Specifikace a analýza požadavků je první fáze vývoje softwaru. Cílem je definovat požadavky na software a popsat jeho funkčnost. Výsledkem této fáze by měly být dokumenty, které se stanou součásti smlouvy mezi zadavatelem a vývojovým týmem.

Návrh implementace je druhá fáze vývoje softwaru. Jde o abstrakci zdrojového kódu, která bude sloužit jako hlavní dokument programátorům v další implementační fázi.

Deklarativní programování se zabývá tím co se počítá a neřeší jak se to počítá (Např. u logického programování definujeme v kódu výrazy a vztahy a pak se dotazujeme na další klauzule, které z toho vyplývají. Jak probíhá samotné vyhodnocení klauzulí se neřeší.). Program je chápan jako funkce, která na základě vstupů vrátí výstup. Stejná funkce se stejnými argumenty dává u deklarativního prog. vždy stejný výsledek (vyhýbají se používání globálních proměnných).

Opakem tohoto principu je imperativní programování popisující jednotlivé úkony pomocí algoritmů. Zjednodušeně to lze popsat tak, že imperativní programy obsahují algoritmy, kterými se dosáhne chtěný cíl, zatímco deklarativní jazyky specifikují cíl a algoritmizace je ponechána programu (interpretu) daného jazyka.

Překladač je program, který překládá programy z jednoho programovací jazyka do jiného. Překladač tedy přečte zdrojový program napsaný v zdrojovém jazyce přeloží ho do ekvivalentního programu (cílový program), který je však napsaný v jiném (cílovém) jazyce. 

Překladač provádí dvě základní činnosti - analyzuje zdrojový kód a následně jej přeložit do cílového programu. Součástí analýzy je lexikální, syntaktická a strukturální analýza.

Činnost překladače je následující: Zdrojový kód -> pre-procesor -> lexikální analyzátor -> syntaktický analyzátor -> tvorba mezikódu -> optimalizátor -> generování výsledného kód -> optimalizace závislá na zařízení

Součástí generování cílového programu je optimalizace kódu. 

Návrhové vzory jsou metodiky (šablony) pro řešení různých problému, se kterými vývojář může setkat. Objektově orientované návrhové vzory typicky ukazují vztahy a interakce mezi třídami a objekty, aniž by určovaly implementaci konkrétní třídy.

Návrhové vzory se dělí do těchto 3 základních skupin:

• Creational Patterns (vytvářející) - řeší problémy související s vytvářením objektů v systému. Snahou těchto návrhových vzorů je popsat postup výběru třídy nového objektu a zajištění správného počtu těchto objektů. Většinou se jedná o dynamická rozhodnutí učiněná za běhu programu.

• Structural Patterns (strukturální) - představují skupinu návrhových vzorů zaměřujících se na možnosti uspořádání jednotlivých tříd nebo komponent v systému. Snahou je zpřehlednit systém a využít možností strukturalizace kódu.

• Behavioral Patterns (chování) - zajímají se o chování systému. Mohou být založeny na třídách nebo objektech. U tříd využívají při návrhu řešení především principu dědičnosti. V druhém přístupu je řešena spolupráce mezi objekty a skupinami objektů, která zajišťuje dosažení požadovaného výsledku.

Každá z těchto skupin obsahuje mnoho návrhových vzorů, které si nyní rozvedeme:

Creational patterns (Vzory týkající se tvorby objektů)

• Abstract Factory (Abstraktní továrna) – Definuje rozhraní pro vytváření rodin objektů, které jsou na sobě závislé nebo spolu nějak souvisí bez určení konkrétní třídy. Klient je odstíněn od vytváření konkrétních instancí objektů.
• Factory Method (Tovární metoda) – Definuje rozhraní pro vytváření objektu, které nechává potomky rozhodnout o tom, jaký objekt bude fakticky vytvořen. *Tovární metoda nechává třídy přenést vytváření na potomky.
• Builder (Stavitel) – Odděluje tvorbu komplexu objektů od jejich reprezentace tak, aby stejný proces tvorby mohl být použit i pro jiné reprezentace.
• Singleton (Jedináček) – Potřebujete-li, aby měla třída maximálně jednu instanci.
• Prototype (Prototyp, Klon) – Specifikuje druh objektů, které se mají vytvořit použitím prototypového objektu. Nové objekty se vytváří kopírováním tohoto prototypového objektu.
• Lazy Initialization (Odložená inicializace) – Odkládá vytváření objektu, počítání hodnoty nebo provádění nějakého procesu, až do okamžiku, kdy je ho poprvé potřeba.
• Object pool (Fond, lidově bazén) – Umožňuje vyhnout se drahému vytváření a uvolňování zdrojů recyklováním objektů, které už se nepoužívají.
• Multiton

Structural Patterns (Vzory týkající se struktury programu)

• Adapter (Adaptér) – Potřebujete-li, aby spolu pracovaly dvě třídy, které nemají kompatibilní rozhraní. Adaptér převádí rozhraní jedné třídy na rozhraní druhé třídy.
• Bridge (Most) – Oddělí abstrakci od implementace, tak aby se tyto dvě mohly libovolně lišit.
• Composite (Strom, Složenina) – Komponuje objekty do stromové struktury a umožňuje klientovi pracovat s jednotlivými i se složenými objekty stejným způsobem.
• Decorator (Dekorátor) – Použijeme jej v případě, že máme nějaké objekty, kterým potřebujeme přidávat další funkce za běhu. Nový objekt si zachovává původní rozhraní.
• Facade (Fasáda) – Nabízí jednotné rozhraní k sadě rozhraní v podsystému. Definuje rozhraní vyšší úrovně, které zjednodušuje použití podsystému.
• Flyweight (Muší váha) – Je vhodná pro použití v případě, že máte příliš mnoho malých objektů, které jsou si velmi podobné.
• Proxy – Nabízí náhradu nebo zástupný objekt za nějaký jiný pro kontrolu přístupu k danému objektu.

Behavioral Patterns (Vzory týkající se chování)

• Observer (Pozorovatel) – V případě, kdy je na jednom objektu závislých mnoho dalších objektů, poskytne vám tento vzor způsob, jak všem dát vědět, když se něco změní.
• Command (Příkaz) – Zapouzdřete požadavek jako objekt a tím umožněte parametrizovat klienty s různými požadavky, frontami nebo požadavky na log a podporujte operace, které jdou vzít zpět.
• Interpreter (Interpret) - Vytváří jazyk, což znamená definování gramatických pravidel a určení způsobu, jak vzniklý jazyk interpretovat.
• State (Stav) – Umožňuje objektu měnit své chování, pokud se změní jeho vnitřní stav. Objekt se tváří, jako kdyby se stal instancí jiné třídy.
• Strategy (Strategie) – Zapouzdřuje nějaký druh algoritmů nebo objektů, které se mají měnit, tak aby byly pro klienta zaměnitelné.
• Chain of responsibility (Zřetězení zodpovědnosti) – Řeší jak zaslat požadavek bez přesného vymezení objektu, který jej zpracuje.
• Visitor (Návštěvník) – Reprezentuje operaci, která by měla být provedena na elementech objektové struktury. Visitor vám umožní definovat nové operace beze změny tříd elementů na kterých pracuje.
• Iterator (Iterátor) – Nabízí způsob, jak přistupovat k elementům skupinového objektu postupně bez toho, abyste vystavovali vnitřní reprezentaci tohoto objektu.
• Mediator (Prostředník) – Umožňuje zajistit komunikaci mezi dvěma komponentami programu, aniž by byly v přímé interakci a tím musely přesně znát poskytované metody.
• Memento (Memento) – Bez porušování zapouzdření zachyťte a uložte do externího objektu interní stav objektu tak, aby ten objekt mohl být do tohoto stavu kdykoliv později vrácen.
• Template method (Šablonová metoda) – Definuje kostru toho, jak nějaký algoritmus funguje, s tím, že některé kroky nechává na potomcích. Umožňuje tak potomkům upravit určité kroky algoritmu bez toho, aby mohli měnit strukturu algoritmu.

K mapování UML diagramů na kód dochází v první části implementační fáze vývoje. Jde o automatické vygenerování zdrojového kódu z UML diagramu.

Z diagramu tříd například vygeneruje jednotlivé rozhraní, třídy s proměnnými a prázdnými metodami. Velmi hezký tutoriál o tom jak se mapuje class diagram na kód najdete zde.

Z diagramů komponent pak vyčte a do generovaného kódu přidá požadované komponenty. Komponenta je už existující a vyměnitelná část systému s daným rozhraním skrze které jí systém používá. Jde o komponentu napsanou v zdrojovém kódu, nebo už zkompilovanou komponentu v binárním kódu, či další komponenty reprezentovanými databázovými tabulkami, dokumenty, apod.

Úkolem samotné implementace je pak dopsat těla metod, jejichž chování může být pospáno v diagramu aktivit.

Abstract factory neboli továrna je návrhový vzor který řeší univerzálnost kódu. Cílem továrny je odstínit klienta od vytváření  konkrétních objektů (to má na starost factory). Klient se nestará o to, které konkrétní objekty vyrábí která konkrétní továrna, protože používá jednotné rozhraní abstraktní továrny. Vzor tudíž odděluje detaily implementace skupiny objektů od jejich obecného používání. 

Příklad Abstract factory:

Jde o to, aby například programátor při změně nějakého grafického prvku, nemusel překopávat celý kód který s tímto prvkem pracuje. Chceme-li mít například univerzální GUI jak pro Windows tak pro Linux, ale v programu nechceme rozlišovat zda pracujeme s linuxovským či windovským tlačítkem. Tuhle univerzalitu zajistím tak, že vytvořím univerzální tlačítko UButton (rozhraní, abstraktní třída), které bude mít definované metody pro práci s tlačítkem. V programu tedy budeme pracovat tlačítkem typu UButton a o konkrétní instanci se postará třída Factory (odtud název návrhového vzoru). Factory na základě operačního systému vytvoří instanci konkrétního tlačítka, které je specializované už pro daný operační systém WinButton nebo LinuxButton. Vzhledem k tomu, že obě tyto třídy implementovaly rozhraní UButton

class WinButton implements UButton

class LinuxButton implements UButton

pracuje s nimi hlavní program jako s jedním typem tlačítka UButton a jestli je to vevnitř WinButton nebo LinuxButton ho nezajímá. 

Singleton (česky jedináček) je návrhový vzor, který využijeme při řešení problému, kdy je potřeba, aby v celém programu běžela pouze jedna instance třídy. Tento návrhový vzor zabezpečí, že třída bude mít pouze jedinou instanci a poskytne k ní globální přístupový bod. To můžeme potřebovat například pro různé třídy, které něco řídí a vznik více instancí takovýchto Manager tříd by způsoboval chaos (např. třída zajišťující přístup k databázi) nebo například pro různé messengery apod.

Realizace tohoto návrhového vzoru spočívá v implementaci public konstruktoru a metody getInstance(), která zkontroluje zda ještě nebyla instance vytvořena a podle toho vrátí již existující instanci, nebo vytvoří novou.

Návrhový vzor kompozit řeší hierarchii objektů tak že je skládá do stromové struktury. Hlavní pointou pak je, aby se s jedním objektem manipulovalo stejně jako s celým kompozitem (skupinou objektů). Realizace je taková, že rozhraní definující chování jednotlivých objektů implementuje i třída reprezentující skupiny objektů.

Na obrázku vidíte příklad kdy třída Platno obsahuje všechny objekty typu Grafic které se umí vykeslit. Sama implmentuje taky rozhranní  Grafic, takže kromě přímek a mnohouhelníků obsahovat i další podplátna.

Příklad implementace v Javě. V ukázce je stádo ve kterém jsou objekty psů a krav. Oba umí vytvořit nějaký zvuk. Pomocí tohoto návrhového vzoru můžeme udělat velké stádo které obsahuje více malých stád a nechat udělat daný zvuk všech zvířat které jsou ve velkém stádu.

import java.util.ArrayList;
import java.util.Iterator;
 
public class Main {
 
    public static void main(String[] args) {
        Dog dog1 = new Dog();
        Cow cow1 = new Cow();
        AnimalGang dogGang = new AnimalGang(); //vytvoření stáda psů
        dogGang.add(dog1);
        dogGang.add(dog1);
        dogGang.add(dog1);
        AnimalGang cowGang = new AnimalGang(); //vytvoření stáda krav
        cowGang.add(cow1);
        cowGang.add(cow1);
        AnimalGang allAnimalsGang = new AnimalGang(); //vytvoření stáda všech zvířat
        allAnimalsGang.add(dogGang); //přidání stáda psů do celkového stáda zvířat
        allAnimalsGang.add(cowGang); //přidání stáda krav do celkového stáda zvířat
 
        allAnimalsGang.makeSound(); //celkové stádo zvířat udělá nějaký zvuk
    }
}
/**
Společný interface pro zvířata, která umí udělat nějaký zvuk
 */
interface Animal {
    public void makeSound(); //abstraktní metoda makeSound() představuje že zvíře dokáže udělat nějaký zvuk např. pes štěká, kráva bučí, kočka mňouká atd..
}
class Dog implements Animal{
    /**
    konkrétní implementace abstraktní metody makeSound() u psa
    */
    public void makeSound() { 
        System.out.println("HAF HAF !!");
    }
}
class Cow implements Animal{
    /**
    konkrétní implementace abstraktní metody makeSound() u krávy
    */
    public void makeSound() {
        System.out.println("Búúúúúúú !!");
    }
}
 
/**
Třída pro komponování objektů typu Animal
*/
class AnimalGang implements Animal {
    // ArrayList pro uchování zvířat ve stádu
    private ArrayList<Animal> childAnimals = new ArrayList<Animal>();
 
    public void makeSound() {
        Iterator<Animal> it = childAnimals.iterator();
        while(it.hasNext()){
            Animal animal = it.next();
            animal.makeSound();
        }
    }
    public void add(Animal _animal){
        this.childAnimals.add(_animal);
    }
    public void remove(Animal _animal){
        this.childAnimals.remove(_animal);
    }
}

Observer je možné použít v situaci, kdy je definována závislost jednoho objektu na druhém. Závislost ve smyslu propagace změny nezávislého objektu závislým objektům (pozorovatelům). Nezávislý objekt musí informovat závislé objekty o událostech, které je mohou ovlivnit.

Možná vám to připomíná klasický mechanismus zpracování událostí (Event / Listener), není to však příliš daleko od skutečnosti. Životní cyklus události se skládá z následujících kroků...

1. Vznik události (typicky vzniká uživatelskou akcí nad komponentou GUI - např. stisknutí tlačítka).
2. Na komponentu, která je zdrojem události je "zavěšen" posluchač dané události
3. Zdroj události (tlačítko) projde seznam registrovaných posluchačů a každému z nich oznámí vznik události - zavolá dohodnutou metodu rozhraní posluchače, metodě předá informace o události 

Observer se nasazuje se v situacích, kdy objekt, který mění své chování (komponenta) a jeho pozorovatelé neudržují navzájem žádné vazby a jejich propojení musí být tudíž zprostředkováno pomocí jejich supertříd. Smysl této nepřímé invokace spočívá v tom, že o přidání nového pozorovatele není nutné informovat (a tím měnit i zdrojový kód) pozorovaný objekt, ale stačí pouze vytvořit novou třídu, která je specializací třídy Pozorovatel (Observer) a její instance přidat do množiny pozorujících objektů prostřednictvím operace připoj (attach).

Objektově-orientované programování (OOP) je metodika vývoje softwaru. Paradigma OOP popisuje způsob vývoje a zápisu programu a způsob uvažování o problému. 

Základní paradigma OOP

• Při řešení úlohy vytváříme model popisované reality - popisujeme entity a interakci mezi entitami
• Abstrahujeme od nepodstatných detailů - při popisu/modelování entity vynecháváme nepodstatné vlastnosti entit
• Postup řešení je v řadě případů efektivnější než při procedurálním přístupu (ne vždy), kdy se úlohy řeší jako posloupnost příkazů 

Cíle OOP

• Je vedeno snahou o znovupoužitelnost komponent.
• Rozkládá složitou úlohu na dílčí součásti, které jdou pokud možno řešit nezávisle.
• Přiblížení struktury řešení v počítači reálnému světu (komunikující objekty).
• Skrytí detailů implementace řešení před uživatelem.

OOP != třídy a objekty - představuje přístup, jak správně navrhnout strukturu programu

Model OOP

OOP definuje program jako soubor spolupracujících komponent (objektů) s přesně stanoveným chováním a stavem. Metody OOP napodobují vzhled a chování objektu z reálného světa s možností velké abstrakce. Model OOP se skládá z několika následujích konstrukcí:

Objekt 

Jednotlivé prvky modelované reality (jak data, tak související funkčnost) jsou v programu seskupeny do entit, nazývaných objekty. Objekty si pamatují svůj stav a navenek poskytují operace přístupné jako metody pro volání. Objekt je také instancí třídy.

Třída (Class)

Třída slouží jako šablona pro vytváření instancí tříd - objektů. Seskupuje objekty stejného typu a podchycuje jejich podstatu na obecné úrovni.  (Samotná třída tedy nepředstavuje vlastní informace, jedná se pouze o předlohu; data obsahují až objekty.) Třída definuje data a metody objektů.

Interface (rozhraní)

Interface předepisuje třídě, která od ní bude odvozena, jaké metody, případně properties musí implementovat. Odvozený objekt může implementovat i další metody. Interface nedefinuje žádné proměnné - pouze konstanty, ani neobsahuje naimplementované metody - obsahuje pouze abstraktní metody bez jejich implementace (jejich hlavičky). Třída může implementovat libovolný počet rozhraní (narozdíl od dědičnosti). Pokud vytvoříte rozhraní, které dědí od jiného rozhraní, automaticky tak přebírá všechny jeho metody a konstanty.

Abstraktní třída

Je to takový hybrid mezi rozhraním a klasickou třídou. Od klasické třídy má schopnost implementovat vlastnosti (proměnné) a metody, které se na všech odvozených třídách budou vykonávat stejně. Od rozhraní zase získala možnost obsahovat prázdné abstraktní metody, které si každá odvozená podtřída musí naimplementovat sama. S těmito výhodami má abstraktní třída i pár omezení, a to že jedna podtřída nemůže zdědit víc abstraktních tříd a od rozhraní přebírá omezení, že nemůže vytvořit samostatnou instanci (operátorem new).

Rysy OOP

• Abstrakce – programátor, potažmo program, který vytváří, může abstrahovat od některých detailů práce jednotlivých objektů. Každý objekt pracuje jako černá skříňka, která dokáže provádět určené činnosti a komunikovat s okolím, aniž by vyžadovala znalost způsobu, kterým vnitřně pracuje.

• Zapouzdření (Encapsulation)– zaručuje, že objekt nemůže přímo přistupovat k „vnitřnostem“ jiných objektů, což by mohlo vést k nekonzistenci. Každý objekt navenek zpřístupňuje rozhraní, pomocí kterého (a nijak jinak) se s objektem pracuje.

• Skládání – Objekt může obsahovat jiné objekty.

• Delegování – Objekt může využívat služeb jiných objektů tak, že je požádá o provedení operace.

• Dědičnost (Inheritance) – objekty jsou organizovány stromovým způsobem, kdy objekty nějakého druhu mohou dědit z jiného druhu objektů, čímž přebírají jejich schopnosti, ke kterým pouze přidávají svoje vlastní rozšíření. Tato myšlenka se obvykle implementuje pomocí rozdělení objektů do tříd, přičemž každý objekt je instancí nějaké třídy. Každá třída pak může dědit od jiné třídy (v některých programovacích jazycích i z několika jiných tříd).

• Polymorfismus – odkazovaný objekt se chová podle toho, jaké třídy je instancí. Pokud několik objektů poskytuje stejné rozhraní, pracuje se s nimi stejným způsobem, ale jejich konkrétní chování se liší podle implementace. U polymorfismu podmíněného dědičností to znamená, že na místo, kde je očekávána instance nějaké třídy, můžeme dosadit i instanci libovolné její podtřídy. U polymorfismu nepodmíněného dědičností je dostačující, jestliže se rozhraní (nebo jejich požadované části) u různých tříd shodují, pak jsou vzájemně polymorfní. Polymorfismus bývá často vysvětlován na obrázku se zvířaty, která mají všechna v rozhraní metodu Speak(), ale každé si ji vykonává po svém. 

• Genericita - je možnost programovaciho jazyka definovat místo typů jen „vzory typů“, kde typy proměnných, použité v definici (ADT typy) jsou vyvedeny vně definice jako parametry a jsou určeny později klientskou aplikací.

Příklad:

List<T>   ...kde T je libovolný typ. Když List alokujeme, použijeme

List<int> intList = new List<int>(), a tento list poté akceptuje jen čísla typu int.

Kouzlo genericity vynikne pak v kombinací s dědičností, kdy do seznamu mohou být vloženy nejen objekty typu T, ale i objekty všech možných dědiců třídy (typu) T). 

Správa paměti je v informatice soubor metod, které operační systém používá při přidělování operační paměti jednotlivým spuštěným procesům. 

V jazyce Java i C# je správa paměti plně automatizovaná. O uvolňování paměti se stará separátní vlákno, které běží s nízkou prioritou a zajišťuje kontinuální sledování nepoužitých bloků paměti. Přidělování paměti se provádí operátorem new.

Úrovně správy paměti

• Technické vybavení
• registry, cache
• Operační systém
• virtuální paměť
• segmentace, stránkování
• Aplikace
• Přidělování paměti
• Regenerace paměti
• Manuální – delete, dispose, free(), …
• Automatická – garbage collection

Garbage collector (GC) - je obvykle část běhového prostředí (programovacího) jazyka, nebo přídavná knihovna, podporovaná kompilátorem, hardware, operačním systémem, nebo jakoukoli kombinací těchto tří. Má za úkol automaticky určit, která část paměti programu je už nepoužívaná, a připravit ji pro další znovupoužití.

Specifikace a analýza požadavků je první fáze vývoje softwaru. Cílem je definovat požadavky na software a popsat jeho funkčnost. Výsledkem této fáze by měly být dokumenty, které se stanou součásti smlouvy mezi zadavatelem a vývojovým týmem. Je však velký problém zjistit všechny požadavky před započetím vývoje projektu. Požadavky se totiž mění během životního cyklu projektu a jejich pochopení a identifikace je kontinuální proces.

Cíle požadavků

• Chcete vytvořit a udržovat dohody se zákazníky a dalšími zainteresovanými stranami o tom, co by systém měl dělat a proč.
• Aby vývojáři lépe pochopili požadavky na systém
• Definování hranic systému
• Vytvořit základ pro plánování technického obsahu iterací
• Poskytnout základ pro odhad nákladů a času na vytvoření systému
• Definovat uživatelské rozhraní pro systém, se zaměřením na potřeby uživatelů

Aktivity spojené s analýzou požadavků

• Sběr požadavků -  komunikace se zákazníky a uživateli za účelem získání jejich požadavků na systém.
• Analýza požadavků - identifikování nejasných požadavků, nekompletních, nejasných, nebo protichůdných a následně řešení těchto nesrovnalostí.
• Zaznamenání požadavků - dokumentování požadavků v různých formách, jako běžný textový dokument, případy užití (use case), nebo specifikace procesů.

Požadavky je také nutno: organizovat, dokumentovat, priorizovat, filtrovat a sledovat.

Použitý model

Use case je technika pro zdokumentování případného požadavku na nový systém, nebo změny na stávající systém. Každý use case poskytuje jeden nebo více scénářů, které zaznamenávají, jak by systém měl spolupracovat s koncovým uživatelem nebo jiným systémem. 

Typy požadavků

• Funkční požadavky (chování) - se používají k vyjádření chování systému zadáním jak vstupních a výstupních podmínek.
• Doplňující požadavky (nefunkční) - vykazuje jakostní znaky:
• Usability - Použitelnost se zabývá lidskými faktory, jako je esteticka, snadné učení, snadné použití, a tak dále
• Reliability - Spolehlivost adresy četnost a závažnost selhání, obnovitelnost a přesnost.
• Performance - Výkon se zabývá množstvím transakcí, jako je rychlost, rychlost, doba odezvy, a tak dále.
• Supportability - řeší, jak těžké je udržet systém a další vlastnosti potřebné k udržení systému po jeho vydání.

Workflow 

(schéma provádění procesu)

• Analyze problem - vytvoření dohody zachycující vyjádření o adresovaných problémech. Stakeholders i hranice projektu jsou identifikovány.
• Understand stakeholders needs - shromažďování požadavků a pochopení potřeb uživatelů a stakeholderů = zúčastněná strana ovlivněná činností projektu
  
• Define the system - stanovují se požadavky stakeholderů. Vytváří se use case diagramy pro klíčové funkce systému a určují se role. 
• Manage the scope the system (Správa rozsahu systému) -  vize je hotová, sbírají se funkční a nefunkční požadavky, use case je prioritizován a systém lze dodat v očekávaném čase a rozpočtem. 
  
• Refine the system definition (Upřesnění vymezení systému) - Use cases jsou podrobně popsány, stejně jako požadavky na software.
• Manage Changing Requirements (Správa změn požadavků) -  centrální kontrolní orgán řídí změny požadavků, a udržuje dohodu se zákazníkem.

Role

• Systemový analytik  - vede a koordinuje požadavky elicitace a use-case modelování popisující funkčnost systému.
• Requirements Specifier (požadavkový specifikátor) - specifikuje podrobnosti o všech funkcionalitách systému. Cílem je koordinace s dalšími požadavky a specifikacemi. Systemový analytik a Requirement Specifier úzce spolupracují s projektantem uživatelského rozhraní (User Interface Designer).
• Softwarový architekt - zajišťuje integritu architektonicky významných use cases.
• Requirement Reviewer (verifikátor požadavků) - ověří, že požadavky jsou vnímány a interpretovány správně ve vývojovém týmu.

Klíčové artefakty

• Stakeholder požadavky - jsou vyvolány a přidány na “wish list”
• Vision Document - obsahuje klíčové potřeby a funkce systému - vize . Podporuje smlouvy mezi finančním oddělením a oddělením vývoje.
• Use-Cases Model je postaven, aby sloužil jako smlouva mezi zákazníkem, uživatelem a vývojáři systému
• Supplementary Specification (dopňující specifikace) je doplňkem k use-case model, protože společně zachytí veškeré softwarové funkční a nefunkční požadavky -kompletní softwarová Specifikace požadavků.
• Glossary -  Slovníček definuje společnou terminologii, která se používá v projektu.
• Storyboards (scénáře) - spojené s případy užití slouží jako základ pro prototypy uživatelského rozhraní.

Specifikace softwarového systému může být formální nebo neformální. Neformální specifikace používá přirozený jazyk, případně obrázky, tabulky a ostatní nástroje umožňující pochopit popisovaný systém. V okamžiku, kdy taková notace získává charakter precizní syntaxe i sémantiky, stává se formální specifikaci. Formální specifikace je technika umožňující jednoznačně specifikovat softwarový systém. Často hovoříme také o semiformálních metodách, které mají přesně danou syntaxi, ale netrváme na úplné a precizní sémantice - patří sem jazyk UML.

Cílem formálních metod není jen jednoznačně systém popsat, ale také ověřit jeho požadované vlastnosti. Obecně formální metody nedosáhly masivního nasazení kvůli časové náročnosti a zbytečně vysokému usilí. Hlavní doménou pro využití se staly systémy vyžadující bezchybný chod v kritických situacích (řízení leteckých systémů, lékařský software apod.). 

Formální specifikaci můžeme rozdělit na 2 typy:

1. Specifikace chování (funkční) 
2. Specifikaci vlastností systému (deskriptivní )

Specifikace chování

Jeden z nejznámějších přístupů k popisu chování systémů a tedy i nástrojů funkční specifikace jsou tzv. konečné automaty. Softwaroví inženýři dostávají k dispozici formální aparát umožňující jednoznačně definovat chování objektů a ověřovat tak jeho požadované dynamické vlastnosti.

Graficky lze vyjádřit konečný automat pomocí grafu, kde uzly grafu vyjadřují stavy systému a hrany označené vstupem definují přechody mezi těmito stavy. V jazyce UML je tato specifikace realizována pomocí stavových diagramů, kdy ověřujeme zda-li posloupnost zpráv přijatých objektem vede k dosažení jeho koncového stavu.

Příklad:

Specifikace vlastností systému

Nejčastěji používanou metodu specifikace vlastností systému je algebraická specifikace - používá k popisu 2 základní pojmy – druhy a operace. Druhy a operace jsou analogií k pojmům datové typy a procedury bežně používaných v programovacích jazycích. V případě algebraických specifikací operace odpovídá matematickému pojmu funkce, která zobrazuje n-tici hodnot na hodnotu. Druhy rozumíme neprázdné množiny hodnot reprezentující definiční obor
a obor hodnot funkcí (operací).

Strukura algebraické specifikace má následující formu:

Je tvořena 4 základními komponentami:
1. představení definuje druh (jméno typu) a deklaruje další používané algebraické specifikace,
2. popis neformálně popisuje operace a druh,
3. signatury definují syntaxi operací a jejich parametry,
4. axiomy (platná tvrzení) určují sémantiku operací cestou charakterizace jejich chování.

Příklad: Algebraická specifikace abstraktního datového typu Seznam. Seznam je tvořen elementy, které jsou přidávány na jeho konec a odebírány z jeho začátku.

  Zdroj skripta - Metody specifikace softwarových systémů (Prof.Ing. Ivo Vondrák CSc.)

Jazyk Object Constraint Language (OCL) poskytuje rámec pro specifikaci omezení kladených na model formálním způsobem. Je speciálním případem textových anotací, které mají v textové formě specifikovat to co nelze vizualizuovat pomocí UML.

Výrazové prostředky jazyku OCL jsou deklarativní bez vedlejších efektů, což znamená, že nedojde k žádným změnám stavu systému z důvodů vyhodnocení výrazů jazyka OCL.  Omezení, která chceme tímto jazykem specifikovat se týkají jak statické struktury tak dynamického chování systému.

Invarianty - jsou omezení kladená na statickou strukturu. Invariantou rozumíme podmínku, která musí být splněna instancemi daného typu v libovolném čase.

OCL je specifikační jazyk - je určen pro vyjádření invariantů. Zápisy v OCL je třeba chápat jako specifikaci pro programy, které budou odpovídající integritní omezení zajišťovat.

Zápis v jazyce OCL má vždy jednotný tvar:

context <jméno> [inv|pre|post]: <výraz>

Stereotypy inv, pre a post znamenají:

• inv = <<invariant>> (obecně platné tvrzení - omezení)
• pre = <<precondition>> (vstupní podmínky operace - předpoklad)
• post = <<postcondition>> (podmínka, která platí po příslušné akci).

OCL je silně typovaný jazyk, tj. každý výraz v jazyce OCL má definován typ. To umožňuje silnou statickou typovou kontrolu zapsaných omezení při jejich interpretaci. OCL má předdefinovánu sadu typů – jsou to jednak primitivní typy: Integer, Boolean, String, Real, UnlimitedInteger, ze kterých lze vytvářet složené typy jako rozmanité kolekce: množina (Set), multi-množina (Bag), obecná kolekce (Collection), posloupnost (Sequence), atd. 

Podrobnější vysvětlení s více příklady najdete zde. 

  Zdrojem jsou skripta - Metody specifikace softwarových systémů (Prof. Ing. Ivo Vondrák, CSc.)

Architektura UML se skládá ze čtyř vrstev, které se liší mírou obecnosti svých prvků. Jedná se o architekturu pro metamodelování. Slovo meta- znamená o jeden stupeň abstrakce výše,  tj. metadata jsou data popisující data, metamodel je model popisující model. 

V následující tabulce jsou rozepsány všechny 4 vrstvy od té nejkonkrétnější.

Tento pohled používají autoři UML a autoři CASE nástrojů - nedívají se na UML jako na diagramy, pro ně je základem UML metamodel (diagramy jsou pouze grafickou reprezentací metamodelu). Při tomto přístupu se často používá pojem model místo pojmu diagram, např. místo diagramu tříd se používá pojem model tříd. Metamodel se popisuje pomocí Meta-Object-Facility (MOF) - abstraktního jazyka pro specifikaci, vytváření a správu metamodelů (další standard OMG). Pro výměnu metamodelů se používá XMI - na XML založený standard (součást standardu UML).

Klasifikace požadavků

• Funkční požadavky - co bude systém dělat
• Nefunkční požadavky - různá omezení na systém (přesnost, bezpečnost, výkon)

• Primární požadavky - získány od stakeholderů
• Odvozené požadavky - odvozeny od primárních požadavků

• Uspořádání na základě rolí - uživatelské požadavky, požadavky zákazníka, systémové požadavky

Prioritizace požadavků

Výhody prioritizace:

• nalezení jádra systému
• identifikaci důležitosti jednotlivých částí systému
• naplánování optimálního seznamu požadavků pro jednotlivá verze (release)
• nejdůležitějších části systému jsou implementovány první - minimalizace rizika a předělávek systému, spokojenost zákazníka

 Metody pro prioritizaci:  

• Cost-value přístup  - pro každý požadavek se určuje číselná dvojice -  náklady na provádění (cost) a hodnota požadavku (value) - vypočte se z nich relativní hodnota, která se porovnává

Správa požadavků

Systematický přístup ke sběru, organizaci a dokumentaci požadavků, které by měly splňovat potřeby zákazníka. Správa požadavků podporuje řízení změn a usnadňuje jejich zavádění. Správa požadavků zahrnuje komunikaci mezi členy projektového týmu a stakeholdery, čímž je umožněno přizpůsobovat požadavky v celém průběhu projektu a zajistit jejich aktuálnost. Důležitým bodem je ale právě neustálá komunikace mezi členy vývojového týmu, aby se nestalo že si požadavky budou vzájemně přepisovat. 

Cílem správy požadavků je doručení kvalitního produktu v čas a s rozpočetem, na kterém se zákazník a tvůrce shodli.

Vysledovatelnost požadavků

Vysledovanost je docílena spojením informačních objektů, které mají nějakou souvislost:

• požadavky a související systémové komponenty splňují tyto požadavky
• systémové cíle a požadavky vycházejí z těch požadavků
• změna návrhu a požadavků
• testování případů a požadavků
• systémové komponenty a zdroje potřebné k implementaci těchto požadavků

Závislost požadavků:

1.       Strukturální závislosti

·         refined-to: požadavek vyššího stupně je zušlechtěn větším počtem specifických požadavků

·         changes to: jeden požadavek se změní na jiný, když je vyvinuta nová verze tohoto požadavku

·         similar-to: jeden stanovený požadavek je podobný, nebo se překrývající, s jedním nebo více dalšími požadavky

2.       Omezující závislosti

·         requires: splnění jednoho požadavku závisí na splnění jiného

·         conflicts with: požadavek je v konfliktu s jiným, pokud nemohou existovat současně

3.       Cenové / Hodnotové závislosti

·         zvýšení / snížení ceny: pokud je jeden požadavek vybrán k implementaci, tak se cena implementace dalšího požadavku zvýší nebo sníží

·         zvýšení / snížení hodnoty: pokud je jeden požadavek vybrán k implementaci, tak se hodnota dalšího požadavku pro zákazníka zvýší nebo sníží

Plán projektu je formální, schválený dokument, který se používá jako vodítko pro realizaci projektu a projektového řízení. Primárně se plán projektu používá na zdokumentování předpokladů a rozhodnutí, usnadnění komunikace mezi zúčastněnými stranami, a zdokumentování schváleného rozsahu, ceny a harmonogramu. Plán projektu může být pouze souhrnný nebo velmi podrobný. 

V plánování je nutné identifikovat potřebné zdroje,  defininovat rizika a předpokladané omezení s jejich dopady. Činnost procesu vrcholí v sestavení realistického časového rámce a rozpočtu projektu a přípravě detailních plánů na realizaci projektu.

Plán projektu by měl optimálně obsahovat 4 základní otázky důležité pro projekt a jeho řízení:

• Proč? Z jakých důvodů se projekt realizuje? Jaký problém nebo nedostatek má projekt vyřešit? Proč je třeba vynaložit prostředky a úsilí na jeho realizaci?
• Co?  Co je cílem a výstupem projektu? Jaké jsou hlavní produkty nebo výstupy projektu? 
• Kdo? Kdo se na realizaci projektu bude podílet? A co bude povinností jednotlivých zúčastněných v rámci projektu? Jak budou účastníci projektu organizováni?
• Kdy? Jaký je harmonogram projektu? Jaké jsou významné milníky v průběhu realizace projektu? Jaká je časová osa projektu a kdy nastanou zvláště významné body označované jako milníky, je kompletní?

Cíle plánování

- nejkratší možný čas trvání projektu (souvisí také s náklady)

- nejnižší náklady

- nejmenší riziko

- efektivní využití zdrojů

Strategické cíle plánování by měly být SMART (specific - konkrétní, Measurable - měřitelné, Attainable - dosažitelné, Relevant - relevantní, Time-bound - časově vymezené)

Součásti plánu projektu

• stanovení rozsahu
• rozpis činností spjatých s projektem - struktura a členění prací
• časový harmonogram-milníky
• odhad nákladů - plán rozpočtu
• organizační uspořádání týmu, plán personálního zabezpečení
• přiřazení úloh a odpovědností pracovníkům
• určení délky trvání jednotlivých prací
• plán komunikace
• klíčová rizika, omezení a předpoklady plánované odezvy na rizika
• pomocné plány řízení rozsahu, harmonogramu, nákladů, ...

Podpůrné techniky

Brainstorming - vytyčení nápadů na projekt

SWOT analýza - určení silných a slabých stránek projektu

Ganttův diagram - harmonogram projektu

SWOT analýza 

S - Strengths  - charakteristika silných stránek projektu

W - Weaknesses - charakteristika slabých stránek projektu, jaké jsou nevýhody oproti konkurečním řešením

O - Opportunities - příležitosti na trhu

T- Threats - hrozby

Jednotlivé položky SWOT analýzy je vhodné ohodnotit, aby byla určena jejich důležitost. Na základě důležitosti je možné stanovit význam jednotlivých částí a zohlednit je při tvorbě strategií.

Brainstorming

Brainstorming je skupinová technika zaměřená na generování co nejvíce nápadů na dané téma. Je založena na skupinovém výkonu. Nosnou myšlenkou je předpoklad, že lidé ve skupině, na základě podnětů ostatních, vymyslí více, než by vymysleli jednotlivě.

• Před započetím se problém zopakuje.
• Mluvit by měl v jednom okamžiku pouze jeden.
• Po fázi vymýšlení přijde na řadu výběr nejlepších nápadů ze všech zapsaných.
• Zveřejněné nápady by neměly být nikým komentovány ani hodnoceny.
• I ten zdánlivě nejhloupější může inspirovat ostatní.
• Podpora uvolněné atmosféry - U brainstormingu jde především o kvantitu nápadů. Pomáhá neformální prostředí, tým, který se navzájem zná, žádná kritika ostatních. Dobrá nálada podporuje divergentní (rozbíhavé) myšlení.
• Všechno zapisovat - Formální struktura brainstormingového týmu by měla obsahovat pouze zapisovatele, tedy člověka, který se nemusí nutně zúčastnit vymýšlení, ale zapíše všechny nápady, které byly řečeny. Čím více nápadů, tím pravděpodobnější je nalezení nejlepší varianty.

Harmonogram projektu - Ganttův diagram

Je označení pro časový plán projektu, který obsahuje posloupnost provedení jednotlivých činností, plánovaná data plnění těchto činností a klíčové milníky projektu. Harmonogram  projektu bývá v praxi většinou vyjádřen formou Ganttova diagramu, který vyjydřuje časové návaznosti činností. Jednotlivé činnosti a dílčí procesy mohou probíhat souběžně a jejich dokončení může být podmíněno kteroukoliv z dalších rozpracovaných částí.

Projektové řízení můžeme definovat jako plánování, organizování a řízení činností a jejich zdrojů v rámci uceleného projektu za respektování časových, zdrojových a nákladových omezení (obvykle s cílem dosažení maximálního ekonomického efektu).

Projektové řízení musí odpovědět na následující otázky:

• Jak dlouho bude trvat realizace projektu?
• Jaké jsou časové a finanční rezervy pro splnění plánu?
• Je dostatek zdrojů ke komplementaci projektu, jak je naplánován?
• Jaké jsou náklady na jednotlivé zdroje aplikované na projektu?

Nástroje řízení

• Metoda kritické cesty (Critical Path Method – CPM) – síťová analýza
• Technika hodnocení a kontroly programů (Program Evaluation and Review Technique – PERT) – síťový uzlově orientovaný graf
• Ganttův diagram – úsečkový, grafická prezentace na časové ose
• Exekutivní informační systémy (Executive Information Systems –EIS)
• Distribuované projektové řízení – aplikuje a integruje nástroje pro plánování a řízení inovací, nástroje pro podporu rozhodování, CAD,CAM,…

Metoda kritické cesty

Sestrojíme orientovaný, ohodnocený graf reprezentující projekt. Každá hrana v něm má svoji váhu a každý vrchol své označení + dvě prázdné proměnné (levá a pravá) pro zápis hodnot cest. Hrany, které budou ležet na cestách budeme označovat. Graf může obsahovat i více než jednu kritickou cestu.

Nejprve projdeme graf zleva ze vstupního vrcholu (hodnota jeho levé proměnné je na začátku 0). Do levé proměnné tohoto vrcholu pak zapíšeme hodnotu cesty (hodnota cesty z předchozího vrcholu + hodnota hrany). Hranu vybíráme tak, že při vstupu do nějakého vrcholu budeme vybírat vždy hranu, ze které dostaneme nejvyšší hodnotu cesty (např. do vrcholu D půjdeme po hraně z B, protože cesta má hodnotu 7, což je vyšší než z C, kde má cesta hodnotu 4).

Tímto postupem vyplníme levé proměnné všech vrcholů a dojdeme až do výstupního (koncového) vrcholu grafu. V jeho levé proměnné nyní máme minimální délku projektu.

Druhý průchod grafu začínáme v koncovém vrcholu, opíšeme hodnotu z jeho levé proměnné do pravé a jdeme proti směru orientovaných hran (vpravo). Nyní však vybíráme cestu s nejmenší možnou hodnotou a její hodnotu hran odečítáme, výsledek zapíšeme do pravé proměnné vrcholu (např. do D půjdeme přes G, protože dostaneme hodnotu 7, což je menší, než kdybychom tam šli přímo z H). Když dojdeme do počátečního bodu, měli bychom v něm mít vpravo 0. Vrcholy se stejnými hodnotami vlevo a vpravo leží na kritické cestě (na obrázku označené červeně).

Soft skills při vedení projektu

Co to znamená vést skupinu?

• Dosahovat se skupinou požadovaných výsledků
• Vytvářet postoje, které motivují skupinu k nejlepšímu výkonu
• Přinášet postoje skupiny uspokojení z práce na projektu a z jejich vlastních výsledků
• Využívat schopností vést skupinu, získaných dříve studiem i zkušenostmi

Rozdíl mezi řízením a vedením

• řízení = Autoritativní proces, kdy vedoucí řídí, rozkazuje a nařizuje
• vedení = Vedoucí je se svou skupinou, umožňuje skupině vidět výsledky a učit se z chyb

Ideální je, když vedoucí řídí úkoly a vede lidi.

Definice ideálního vedoucího

• je v denním kontaktu s členy skupiny - zajímá se o ně a motivuje je
• je k dispozici v případě potřeby
• soustředí se na hlavní cíle projektu a připomíná je ostatním
• rozpoznává včas překážky a odstraňuje je
• je důsledný, dodržuje sliby
• podílí se se skupinou o maximum informací
• informuje a naslouchá
• ví co lidé dělají a co by chtěli dělat
• pomáhá skupině dosáhnout cílů a aby lidé cítili úspěch
• rozhoduje se bez omluv, rozhodnutí lehce nemění
• vyjednává s dobrou vůli a otevřeně
• předpokládá že členové skupiny jsou zralí, mají snahu růst, jsou motivovaní a že pracují kvalitně
• nešetří uznáním a odměnami

Čerpáno ze skript Information Management (Ing. Přemysl Soldán)

Je potřeba vymezit si důsledně všechna možná rizika pro konkrétní projekt. Rizika vznikají ještě před zahájením samotného projektu a také v jeho průběhu. 

Věcným výstupem procesu analýzy rizik je dokument který obsahuje:

• popis IS
• stanovení úrovně hrozeb
• odhad ztrát
• stanovení protiopatření
• určení zbytkových rizik

Druhy rizik a jejich příklady

Rizika projektová

• špatná komunikace členů týmu - rozdílná interpretace toho co mělo být uděláno 
• opoždění v čase - špatné plánování, malá časová rezerva
• kompetence - pracovníci neodpovídají kvalifikaci
• neznámá kvalita produktu
• neschopnost pracovat jako tým - kulturní rozdíly
• ztráta klíčové osoby - nemocenská, mateřská
• selhání technických zdrojů
• nedodržení rozpočtu

Rizika finanční - daňové změny, inflace, změny úrokových sazeb

Rizika přírodní - povodně, zemětřesení

Rizika vyšší moci - války, katastrofy

Řízení rizik

Disciplína se zabývá tvorbou činností, navzájem provázaných, které se snaží zamezit nebo zmírnit výskyt rizik nebo nemilých překvapení. Rizika ohrožují dosažení našich cílů, mají potenciálně negativní dopad na naši činnost a s určitou pravděpodobností se u naší činnosti vyskytnou. Řízení rizik se snaží tyto negativní dopady co nejvíce eliminovat.

Řízení rizik se skládá ze 4 činností:

1.     Identifikace rizik a oblastí hrozeb - vyhotoví se jejich seznam 

2.     Hodnocení rizik - pro určení hodnoty rizika je nutné nejdříve určit následující hodnoty:

• dopad rizika - na projekt a jeho průběh
• pravděpodobnost - s jakou pravděpodobností riziko nastane

- následně se stanoví hodnota rizika podle tabulky, která určujeme míru akceptovatelnoti rizik (vlevo)

- můžeme mít i víc jak 3 sloupce a řádky, záleží jak podrobnou chceme mít stupnici

- všechny rizika mají přidělené dvě hodnoty od 1-3 s jejich dopadem (I) a s jejich pravděpodobností (P)

=> riziko odpovídá jednomu políčku v tabulce kde se protly jeho hodnoty - high/ medium/ low, kdy high jsou vysoké rizika které se musí neprodleně řešit 

3.     Strategie zvládnutí rizik

Po důkladném zhodnocení rizik je nutné vytvořit plán rizik, ve kterém bude uvedeno určení strategie zvládnutí, minimalizace nebo eliminace rizik. Faktory, které ovlivňují tvorbu strategie: fáze projektu, velikost, priorita, komplexnost, časová a finanční náročnost. Tvorba plánu rizik není nijak složitá, ale je prioritně důležité rozpoznat všechna závažná rizika, které mohou náš projekt ovlivnit a k těmto rizikům navrhnou účinná protiopatření.

V tabulce musí být uvedeno: riziko, váha rizika, jeho pravděpodobnost a jeho hodnota. Dále zde musí být stanoveno preventivní opatření, pokud riziko nastane, jaké kroky podniknout k jeho odstranění nebo minimalizaci. Důležité je také určit odpovědnou osobu spojenou s provedením preventivního opatření. Určení krizového scénáře je další důležitou součástí tabulky plánu rizik. Krizový scénář se stanovuje pro případ, že se nepodaří riziko odstranit nebo jej minimalizovat. 

4.     Monitoring vývoje rizikových stavů

Během jakéhokoli projektu se mohou objevit další rizikové události a proto musejí být rizika stále monitorována. Nikdy nemůžeme určit a rozpoznat všechna rizika a pravděpodobnost, se kterou mohou nastat, proto je důležité abychom stále identifikovali nová rizika a přehodnocovali rizika, která byla již dříve rozpoznána. To znamená, že Plán rizik a jejich řízení se bude stále měnit v čase.

Kvantitativní

Kvantitativní analýza je náročnější na zdroje a její provedení trvá mnohem déle než kvalitativní analýza rizik. Je tomu tak proto, že hodnotu aktiva (aktivum = cokoli v organizaci co má má nějakou cenu) je nutné vyjádřit v penězích stejně jako možnou škodu v případě realizace konkrétní hrozby. Vyjádření škody ve finančních jednotkách však umožňuje jednodušší rozhodování ve fázi zvládání rizik, kdy vybíráme vhodná opatření.

Výpočet: pravděpodobnost výskytu události * potenciální ztráta = odhad ztrát (očekávaná ztráta) - ALE/EAC

Problém: nespolehlivost výsledku daná nepřesností výchozích údajů

Výhoda: konkrétní výsledky které se dají porovnávat

Přístupy: 

• Analýza historických dat a statistik,
• Analýza závislostí,
• Síťové analýzy,
• Simulace a modelování,
• Marketingové průzkumy a analýzy trhu,

Postup:

1. Identifikace a kvantifikace aktiv 

• Jak se dané aktivum podílí na výnosech, resp. kolik zisku nám generuje?
• Kolik by stálo opětovné pořízení aktiva a zprovoznění?
• Jakou bychom zaplatili pokutu v případě porušení důvěrnosti, integrity a dostupnosti?

2. Identifikace a kvantifikace hrozeb

• Kvalitativní analýza by měla obsahovat skutečná fakta a dostupné údaje. Pozitiva tohoto přístupu jsou zejména ve schopnosti hodnotit dopady na organizaci nebo jedince, které nelze elementárně vyjádřit v peněžních jednotkách (jak je běžné ukvantitativních analýz). Hodnocení dopadů kvalitativním přístupem však v dnešních metodikách postrádá konzistentnost a schopnost pokrýt všechny aspekty, podle kterých je nutné dopady hodnotit. V praxi si každý rizikový analytik vytváří vlastní způsoby hodnocení dopadů a i dalších parametrů pro stanovení míry rizika.

3. Identifikace a kvantifikace zranitelnosti

• V této fázi bychom se měli u každé dvojice hrozba – aktivum zamyslet nad tím, jakou škodu by mohla hrozba způsobit. Tato ztráta se nejčastěji uvádí v procentech a označuje se zkratkou EF (Exposure Factor). Pro její určení si musíme položit podobné otázky jako v případě stanovení hodnoty aktiva, konkrétně:
• O kolik se sníží výnosy resp. zisk v případě narušení důvěrnosti, integrity a dostupnosti?
• Jaké jsou náklady na zotavení se z dané hrozby a obnovu normální funkčnosti?
• Jakou bychom zaplatili pokutu v případě porušení důvěrnosti, integrity a dostupnosti?

4. Stanovení výše škody

• V okamžiku, kdy jsme stanovili hodnotu aktiva (AV), pravděpodobnost hrozby (ARO) a hodnotu zranitelnosti (EF), můžeme přistoupit ke stanovení výše celkové škody tzv. ALE (Annualized Loss Expectancy), kterou získáme součinem těchto hodnot: ALE=AV*EF*ARO.

Kvalitativní

Používá slov k popisu rozsahu možných následků a pravděpodobností, že se tyto následky přihodí. Užité škály mohou být přizpůsobeny nebo upraveny tak, aby vyhovovaly okolnostem, a různá rizika mohou být popsána různým způsobem.

Kvalitativní analýza je méně náročná na zdroje a trvá kratší mnohem kratší dobu než kvantitativní analýza rizik. Především proto, že hodnotu aktiva není nutné vyjadřovat v penězích stejně jako možnou škodu v případě realizace konkrétní hrozby. To však vede k horší kontrole nákladů ve fázi zvládání rizik, kdy vybíráme vhodná opatření.

Kvalitativní analýza se používá:

• Jako úvodní přehled vedoucí k identifikaci rizik, která vyžadují podrobnější zkoumání;
• Tam, kde tento druh analýzy postačuje k rozhodování; nebo
• Tam, kde číselné údaje nebo zdroje nejsou dostatečné k provedení kvantitativní analýzy.

Princip: Kvalitativní analýza rizik je založena na expertním odhadu jednotlivých aktiv (aktivum = cokoli v organizaci co má má nějakou cenu), hrozeb a zranitelností a pro jejich vyjádření používá slovního nebo číselného hodnocení. Umožňuje tak poměrně snadno a rychle identifikovat ta největší rizika. ).

Nevýhody: Oproti kvantitativní analýze rizik, kde je způsob výpočtu víceméně daný a nikdo ho nezpochybňuje, tak v případě kvalitativní analýzy rizik neexistuje pouze jediná možnost, jak se dobrat výsledku. Možnost zvolit si v podstatě jakoukoliv stupnici pro stanovení hodnoty aktiv, hrozeb a zranitelností představuje sice na jednu stranu výhodu, ale na stranu druhou to komplikuje srovnávání výsledků AR provedených nejrůznějšími společnostmi.

Kvantitativní vs. kvalitativní

Analytici upřednostňující kvantitativní přístup oproti kvalitativnímu často argumentují tím, že kvalitativní hodnocení dopadů je prováděno s vysokou mírou subjektivity, kdy výsledná hodnota závisí z velké části na osobním názoru hodnotitele. Pro stanovení kvantitativní hodnot se využívají výše uvedené metodiky a nástroje (simulace, analýza historických dat a statistik, marketingové průzkumy a analýzy trhu atd.), které však mohou v sobě zahrnovat také jistou míru subjektivity. Odborníci na finance mají k dispozici celou řadu nástrojů na výpočty odhadovaných hodnot, nicméně žádná předpověď rizik i matematicky podložená, nemůže být stoprocentní. Kvantitativní přístupy využívající finanční škály jsou velmi vhodné, pokud je po provedené analýze nutné najít zdroje na pokrytí zjištěných rizik. 

Testovací plán je výchozím dokumentem testovací dokumentace. V něm jsou stanoveny základní podmínky, za kterých bude testování probíhat.

Obvykle obsahuje testovací plán tyto údaje.

• Cíl testování - definuje, čeho by mělo být testováním dosaženo. Cílem může být například ověření všech funkčností systému, nebo kontrola správné funkčnosti dodatečně přidaných component, stejně tak se může ověřovat správné fungování aplikace na zákazníkem dodané produkční platformě a podobně.
• Přehled plánovaných testů - ten vychází z testovacích požadavků. Ty vychází v převážné míře z dodaných příkladů užití (Use case), dále mohou vyvstat z komunikace se zákazníkem nebo z bussines případů. Jednoduše řečeno je snaha navrhnout takový seznam testů, který postihne všechny funkčnosti aplikace a to z důrazem na použití ze strany zákazníka.
• Stanovení priorit - pro jednotlivé testované prvky aplikace a tedy i pro jednotlivé testy. Nejvyšší prioritou jsou označené ty prvky, které jsou z hlediska funkce aplikace nejvýznamnější, nebo ty, u kterých v případě nefunkčnosti hrozí největší riziko nesplnění cílů testování. Všechny ostatní prvky jsou otestovány až v případě otestování prvků s nejvyšší prioritou.
• Testovací strategie - popisuje, jaké typy testů budou provedeny (např. zátěžové, funkční apod.) a s jakým cílem (obvykle s vazbou na konkrétní use case). Jednotlivé testy pak zařazuje do konkrétních fází testování (integrační testy, akceptační testy apod.) Dále se zde popisují techniky, kterými budou prováděny jednotlivé typy testů. Velice důležité je i stanovení způsobu, jakým se budou testy vyhodnocovat, a kritérií, podle kterých je test označen jako kompletní.
• Požadavky na zdroje - slouží k definování požadavků, které musí být splněny, aby bylo možné testy provést. Sem se řadí jednak požadavky technického rázu jako je příprava testovacího hardwaru, instalace softwaru, zpřístupnění serverů a podobně. A dále zdroje lidské. Zde je vyjmenováno požadované složení testovacího týmu včetně požadavku na spolupráci jiných pracovníků (např. při instalaci a správě testovacího prostředí)
• Definice rizik - slouží k vymezení situací, které mohou ohrozit úspěšné testování. Sem může spadat například nedodání aplikace ve stanoveném termínu, nedostupný testovací nástroj, nebo nedostatek proškolených pracovníků. U těchto rizik se stanoví míra jejich závažnosti a návrh protiopatření.

Účelem modelování je vytvoření takové abstrakce procesu, která umožňuje pochopení všech jeho aktivit, souvislostí mezi těmito aktivitami a rolemi zapojenými do tohoto procesu.

Při sestavování podnikového modelu je nejprve je nutné identifikovat, jaké funkce daná organizace či podnik má plnit a za jakým účelem. 

1. Hledáme co je vstupem a výstupem těchto funkcí a jak jsou tyto funkce strukturovány. Následuje 
2. Další krok popisující jak tyto funkce budou zajišťovat transformaci vstupů na výstupy pomocí k tomu určených aktivit a procesů.
3. Nakonec je nutné definovat, čím konkrétně jsou v předchozích krocích definované toky dané a kdo a co bude realizovat specifikované aktivity. 

V podstatě tedy existují tři základní přístupy, které se využívají k modelování procesů, a které vychází ze tří základních typů použité abstrakce: 

1. Funkční přístup zaměřený především na funkce, jejich strukturování, vstupy a výstupy. Příkladem metody je IDEF.
2. Přístup specifikací chování je zaměřen na řídící aspekt vykonávání procesu cestou stanovení událostí a podmínek, za kterých mohou být jednotlivé aktivity prováděny. Příkladem je metoda EPC, BPMN.
   
3. Strukturální přístup je zaměřen na statický aspekt procesu. Cílem je postihnout entity a zdroje vystupující v procesu včetně jejich atributů, činností (služeb) a vzájemných vazeb. Určuje se pomocí UML.

IDEF (Integration DEFinition)

Metoda IDEF, konkrétně IDEF0, poskytuje modelovací jazyk s danou syntaxí a sémantikou, umožňující vytvořit strukturovanou grafickou reprezentaci systému nebo organizace. Budeme se zabývat typem IDEF0 určeným pro účely sestavení funkčního modelu, který strukturovaným způsobem popisuje funkce modelované doménové oblasti (existuje i IDEF1- struktura systému a IDEF2- chování). 

Skládá se z následujících prvků: 

1. Funkce (Function) popisující činnost transformující vstup na požadovaný výstup. 

2. Vstupem (Input) jsou data nebo objekty, které budou funkcí transformovány na výstup. 

3. Výstupem (Output) rozumíme data nebo objekty produkované funkcí. 

4. Řízení (Control) je dáno pravidly potřebnými k vytvoření požadovaného výstupu. 

5. Mechanismus (Mechanism) definuje prostředky nutné k realizaci funkce. 

Každá funkce nese své číselné označení (ID) a případně také označení diagramu - aby bylo možné vytvářet hierarchii diagramů odpovídající dekompozici funkcí (rozložení na podfunkce). Je zde pravidlo že diagram by neměl mít méně než tři a více než šest funkcí. Platí zde také důležitá vlastnost těchto diagramů, kdy výstupy dané funkce mohou být vstupem, řízením či mechanismem jiných funkcí. Tímto způsobem jsou definovány vzájemné závislosti mezi funkcemi. 

 Příklad IDEF0 - realizace zakázky.

EPC (Event-driven Process Chains)

Určuje jaká bude posloupnost aktivit, případně, které z aktivit budou moci být realizovány souběžně (paralelismus). Spočívá v řetězení událostí a aktivit do posloupnosti realizující požadovaný cíl. Z obecného pohledu vykonávání procesu událost definuje vstupní podmínku (precondition) uskutečnění aktivity. Ukončení aktivity pak definuje další událost – výstupní podmínku (postcondition), na kterou mohou navazovat další aktivity. Z toho vyplývá, že každá aktivita je vymezena dvěmi událostmi a tak je i jednoznačně definován její začátek a konec. 

Byznys proces specifikovaný pomocí EPC diagramu využívá následujících elementů:

• Aktivity (Activities), které jsou základními stavebními bloky určují, co má být v rámci procesu vykonáno. 
• Události (Events) popisují situace před a/nebo po vykonání aktivity. Aktivity jsou vzájemně propojeny pomocí událostí. Jinak řečeno, nějaká událost může vyjadřovat výstupní podmínku jedné aktivity a současně vstupní podmínku jiné aktivity. 
• Logické spojky (Connectors) se používají ke spojování aktivit a událostí. Tímto způsobem je popsán řídící tok procesu. EPC používá tři typy spojek: ∧ (AND – a současně), ∨ (OR – nebo) a XOR (exclusive OR – vzájemně se vylučující nebo). 

- vždycky je střídání události s aktivitou a mezitím dáváme logické spojky. Je tu ale pravidlo, že nemůžeme jít z události do spojky OR nebo XOR (jedině z aktivity).

BPMN (Business Process Model and Notation)

Poskytuje grafické znázornění pro specifikaci podnikových procesů v procesním diagramu (BPD). Procesní diagram je založen na flowchart technologii, která je velmi podobná diagramu aktivit.

Pomocí BPMN vznikají jednoduché diagramy, které se skládají z omezeného počtu grafických prvků. Díky tomu je pro vlastníky procesů, vývojáře a analytiky snadné porozumět procesním tokům i samotným procesům. BPMN se rozděluje na čtyři základní kategorie, viz níže. Tyto čtyři kategorie usnadňují tvorbu jednoduchých diagramů podnikových procesů a také umožňují tvorbu nových druhů tokových objektů a artefaktů, které přispívají k lepší srozumitelnosti diagramů.

Flow objects - Tokové objekty

• Events - Události
• Activities - Aktivity / Činnosti
• Gateways - Brány

Connecting objects - Spojovací objekty

• Sequence flow - Sekvenční tok
• Message flow - Tok zpráv
• Association - Asociace

Swim lanes - Plavecké dráhy (Kontexty)

• Pool - Bazény (Kontext)
• Lane - Dráhy (Oddíly kontextu)

Artifacts - Artefakty

• Data object - Datové Objekty
• Group - Skupiny
• Annotation - Anotace

Co vše provádí operační systém

• Organizuje přístup a využívání zdrojů počítače (čas procesoru, přístup k datům na discích, přístup do paměti).
• Fyzicky zajišťuje vstup a výstup dat podle požadavků ostatních programů.
• Komunikuje s uživatelem a na základě jeho pokynů vykonává požadované akce.
• Reaguje na chybové stavy programů a mylné požadavky uživatelů tak, aby tyto chyby nezpůsobily zásadní destrukci systému nebo poškození dat.
• Spravuje komunikaci s periferiemi. Definuje nastavení klávesnice, citlivost myši a dalších zařízení.
• Eviduje využívání systémových zdrojů apod.

Struktura OS

Operační systém je zpravidla tvořen tzv. jádrem (kernel), ovladači V/V zařízení (driver), příkazovým procesorem (shell) a podpůrnými systémovými programy.

• Jádro - po zavedení do paměti řídí činnost počítače, poskytuje procesům služby a řeší správu prostředků a správu procesů.
• Ovladač - zvláštní (pod)program pro ovládání konkrétního zařízení standardním způsobem. Použití strategie s ovladači umožňuje snadnou konfigurovatelnost technického vybavení.
• Příkazový procesor - program, který umožňuje uživatelům zadávat příkazy ve speciálním, obvykle jednoduchém jazyce.
• Podpůrné programy - do této kategorie jsou mnohdy zahrnovány i překladače (jazyk C v OS UNIX) a sestavující programy. Stojí na stejném místě jako aplikační programy.

Jádro OS

Jádro se zpravidla dělí na dvě podstatné části:

1. Správa procesů - správa procesů (prakticky není u jednoduchých OS) řeší problematiku aktivování a deaktivování procesů podle jejich priority resp. požadavků na prostředky.
2. Správa prostředků - zajišťuje činnost V/V zařízení, přiděluje paměť, případně procesory. Velmi důležitou částí správy prostředků je: správa souborů - způsob ukládání souborů a přístupu k nim. Moderní OS zajišťují jednotný pohled na soubory a zařízení. Zařízení jsou považovány za soubory se speciálním jménem.

Generické komponenty OS

• Správa procesoru (procesorů)
• Správa procesů (proces – činnost řízená programem)
• Správa vnitřní (hlavní) paměti
• Správa souborů Správa I/O systému
• Správa vnější (sekundární) paměti Networking, distribuované systémy Systém ochran Interpret příkazů

Správa procesů

• Proces – činnost řízená programem, provedení programu, „process“ nebo „task“
• Proces potřebuje pro svou realizaci jisté zdroje (CPU, paměť, I/O zařízení, …)
• Z hlediska správy procesů je OS zodpovědný za:
• Vytváření a rušení procesů
• Potlačení a obnovení procesů
• Synchronizace procesů a jejich vzájemná komunikace
• Variantou procesu je tzv. Vlákno – jednotka plánování činností definovaná v programu. Vlákna používají zdroje přidělené procesu.

Správa procesoru

• OS vybírá procesy běžící na dostupných procesorech.
• Dále podle typu OS zde patří i plánování vláken.

Správa vnitřní paměti

• Vnitřní pamětí se myslí primární, operační paměť, neboli fyzický adresový prostor (pole samostatně adresovatelných slov nebo bytů), repositář pohotově (rychle) dostupných dat sdílený CPU a I/O zařízeními.
• Vnitřní paměť energeticky závislá, ztrácející se po výpadku energie.
• OS je z hlediska správy vnitřní paměti odpovědný za:
• Vedení přehledu, který proces v daném okamžiku využívá kterou část paměti
• Rozhodování, kterému procesu po uvolnění paměti tuto paměť poskytnout
• Přidělování a uvolňování paměti
• Programátor vidí logický adresový prostor – ten je vymezen formou adresy v instrukci. OS zavádí programy a data do tohoto prostoru podle potřeby. Transformaci logické adresy na fyzickou se zpravidla provádí až při provádění instrukce. Struktura logického adresového prostoru může být lineární (pole) nebo dvojdimensionální (kolekce samostatných lineárních segmentů proměnné délky).

Správa I/O systémů

Poskytuje repositář vyrovnávacích pamětí a univerzální rozhraní ovladačů (driverů) I/O zařízení, a pak také samotné ovladače (drivery).

Správa vnější paměti

Správa energeticky nezávislé, sekundární paměti s dostatečnou kapacitou. Jako sekundární paměť obvykle slouží disky. OS je zodpovědný za:

• Správu volné paměti
• Přidělování paměti souborům
• Plánování činnosti disku

Správa souborů

Soubor – identifikovatelná kolekce souvisejících dat definovaná svým tvůrcem. Obvykle reprezentuje i programy i data.

OS je z hlediska správy souborů zodpovědný za:

• Vytváření a rušení souborů
• Vytváření a rušení adresářů (katalogů)
• Podporu primitivních operací pro manipulaci se soubory a adresáři
• Zobrazování souborů do sekundární paměti
• Archivování souborů na energeticky nezávislá média
• Networking, distribuované systémy

Distribuovaný systém – kolekce procesorů nesdílejících ani fyzickou paměť, ani hodiny. Procesory distribuovaného systému jsou propojeny komunikační sítí. Komunikace je řízena protokoly.

Systém ochran

Mechanismus pro řízení přístupu k systémovým a uživatelským zdrojům. Tento systém je součástí všech vrstev OS.

Systém ochran musí:

• Rozlišovat mezi autorizovaným a neautorizovaným použitím
• Poskytnout prostředky pro své prosazení

Interpret příkazů

• Většina zadání je předávána operačnímu systému řídícími příkazy, které zadávají požadavky na:
• Správu a vytváření procesů
• Ovládání I/O zařízení
• Správu sekundární paměti
• Práci v síti

Program, který čte a interpretuje příkazy je označován v různých OS různými názvy – command line interpreter, shell, …

Struktura OS podle jádra

• Monolitická jádra (Monolithic kernel)
• Otevřené systémy (Open systems)
• Microkernel

Monolitický OS

OS je na jednom místě (pod „červenou čárou“). Aplikace používá dobře definované rozhraní systémových volání pro komunikaci s jádrem.

Příklady OS – Unix, Windows NT / XP, Linux, BSD, …

Monolitické jádro je specifické pro komerční systémy.

Výhody:

• Dobrý výkon
• Dobře pochopená koncepce
• Jednoduché pro vývojáře jádra
• Vysoká úroveň ochrany mezi aplikacemi

Nevýhody:

• Žádná ochrana mezi komponentami jádra
• Není jednoduše a bezpečně rozšiřitelné jádro
• Celková struktura je ve výsledku komplikovaná, neexistují hranice mezi moduly jádra 

Otevřené Systémy

Aplikace, knihovny i jádro jsou všechny v jednom adresovém prostoru.

Jestli se to zdá být jako šílená myšlenka, zde jsou příklady – MS-DOS, Mac OS 9 a starší, Windows ME, 98, 95, 3.1, Palm OS.

Tato koncepce bývala velmi běžná.

Výhody:

• Velmi dobrý výkon
• Velmi dobře rozšiřitelné
• Výhodné pro jednouživatelské OS

Nevýhody:

• Žádna ochrana mezi jádrem a aplikacemi
• Nepříliš stabilní
• Skládání rozšíření může vést k nepředvídatelnému chování

Microkernel OS

Filosofie návrhu – chráněné jádro obsahuje pouze minimální (malou, čistou, logickou) množinu abstrakcí:

• Procesy a vlákna
• Virtuální paměť
• Komunikace mezi procesy

Všechno ostatní jsou server-procesy běžící na uživatelské úrovni.

Příklady OS – Mach, Chorus, QNX, GNU Hurd

Zkušenosti s tímto návrhem jsou smíšené.

Výhody:

• Přidáním server-procesu se rozšíří funkcionalita OS
• Jádro nespecifikuje prostředí OS
• Servery na uživatelské úrovni se nemusí zabývat hardwarem
• Silná ochrana OS i sám proti sobě (části OS jsou oddělené servery)
• Jednoduché rozšíření na distribuovaný nebo multiprocesorový systém

Nevýhody

• Výkon (Systémová volání viz. dále)
• Špatná minulost

Systémová volání – příklad

Slouží k abstrahování tvorby složitých objektů. A to tak, aby stejné výrobní schéma mohlo být použito pro tvorbu různých objektů. Způsob konstrukce těchto objektů je tedy stejný, jednotlivé kroky se však liší. 

Použití Stavitele je vhodné u rozdílných tříd s podobným procesem konstrukce. Samotné třídy mohou být rozdílné a nezávislé. Tím se liší od Abstraktní továrny, která slouží k tvorbě podobných objektů. 

Konstrukci provádí konkrétní implementace rozhraní Builder, ale proces konstrukce řidí třída Director. 

Příklad:

Klient přijde do fastfoodu a chce hlavní menu. Hlavní menu se skládá z hamburgeru, přílohy a nápoje. Výrobní postup je vždy stejný, jen některé kroky mohou být vynechány nebo zaměněny - někdo si objedná cheeseburger jiný může chtít chickenburger bez nápoje. 

Pracovník na přepážce je directorem - vytváří objednávku a řídí pracovníky. O realizaci jednotlivých kroků se starají různé implementace třídy Builder -např. vytvářeč chickenburger menu, vytvářeč cheeseburger menu, apod. Jejich výsledkem je kompletní produkt - balíček se sestaveným jídlem. Menu je možné odebrat teprve poté, kdy jsou všechny kroky konstrukce dokončeny.

Zjednodušeně: Ke konstrukci jednoho objektu slouží právě jeden Builder, proces konstrukce řídí Direktor, objekt ke konstrukci vybírá klient předáním Builderu Direktoru, po ukončení konstrukce si z Builderu pouze vybere výsledek metodou getResult.

Stavitelů ke konstrukci jednoho objektu může být voláno i více. Například pokud je výsledný produkt Composite může být při jeho konstrukci voláno více stavitelů, případně stejný stavitel několikrát za sebou. Tak je zajištěno například vytváření složitých objektů grafického rozhraní operačního systému.

Návrhový vzor Facade představuje řešení, jestliže je nutné zjednodušit vstupní bod do systému.

Při vývoji systému se lehce může stát, že celková jeho struktura se stává velmi těžce zvládnutelnou. I použitím návrhových vzorů se mnohdy dostáváme k velmi komplexnímu systému tříd s mnoha vazbami. Navíc každý systém může obsahovat i několik subsystému, které ještě zvětšují obtížnost pochopení zákonitostí systému. Facade představuje „high-level“ rozhraní, které slouží k zjednodušení komunikace mezi klientem a systémem.

Klient komunikuje se systémem pomocí Facade, kterému zasílá požadavky. Facade tyto požadavky zasílá příslušným objektům. Jinak řečeno Facade překládá svoje rozhraní do jednotlivých rozhraní v systému. Říkáme, že Facade je rozhraním systému, ale ve skutečnosti není použito standardní Java rozhraní (deklarované jako interface), ale Facade je implementován jako třída.

Příklad

Představme si systém, jehož úkolem je realizovat vyřízení zakázky ovoce, které objednávají maloobchody. V takovémto systému by neměla chybět třída respektive modul, která zajišťuje skladové hospodářství (Sklad ovoce), prodej ovoce (Obchod) a evidenci platby pohledávek (Účetnictví). Jelikož takové struktura je pro maloobchod nepřehledná, byla vytvořena třída Zásobování, která umožňuje průhlednou komunikaci s těmito moduly. Maloobchod si může zjistit stav svých dluhů, dotázat se na množství ovoce na skladě, zjistit jeho cenu a objednat si určité množství. Zásobování pouze překládá jeho požadavky na příslušné metody tříd v systému.