Lucka Žoltá

Kompozit

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);
    }
}

Formální metody

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

Observer

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

OCL (Object Constraint Language)

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

Objektově orientované paradigma.

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

Čtyřvrstvá architektura

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

Správa paměti

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

Klasifikace, prioritizace, správa, vysledovatelnost a závislost požadavků.

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

Disciplína sběr a analýza požadavků

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

Plánování projektu

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