36SI - HAVESHOP

Rámcový plán projektu	Detailní plán analýzy	Oponentura projektu CRM

Plán řízení jakosti	Plán testů a akceptací	Zpráva průběžné kontroly řešení

Rámcový plán projektu:

Stanovení rozsahu projektu:

funkce : Systém HaveShop bude vytvořen jak informační systém pro dochod s výpočetní technikou, který má jeden obchod a jeden sklad.Systém bude umožňovat evidenci zboží na skladě, rezervace zboží

chování : Celý systém bude založen na databázové aplikaci evidující zboží na skladě a spravující konta jednotlivých zákazníků. Bude umožňovat víceuživatelský přístup.

rozhraní : Systém bude vytvořen formou webového rozhraní využívajícího standardního protokolu HTTP.

spolehlivost : Vzhledem k tomu, že tento systém je určen pro jednu firmu a k ceně systému nebude kladen zvýšený důraz na bezpečnost ani spolehlivost.

Odhad LOC:

	optimální	pravděpodobný	pesimistycký	EV
UICF - modul řízení a komunikace s uživatelem	1000	1100	1300	1117
DBM - řízení databáze	1500	1600	2000	1650
PC - řízení periferií	930	1100	1150	1080
DAM - modul analýzy návrhu	3500	4000	6200	4283
LOC				8130

Předpokládáme průmšrnou produktivitu 620 LOC/mm.

Z toho plyne pracnost 13,11 mm.

Počítáme-li náklady 25 000Kč na mm, pak dostaneme cenu produktu 327 750Kč.

Odhad FP:

	optimální	pravděpodobný	pesimistycký	EV	váha	FP
počet vstupů	5	6	7	6	4	24
počet výstupů	3	4	7	4,33	5	21,66
počet dotazů	3	6	7	5,66	4	22,66
počet souborů	1	1	3	1,33	10	13,3
počet externích souborů	0	0	1	0,16	7	1,16
součet						82,78

Předpokládáme náročnost 6,5 FP/mm.

Z toho plyne pracnost 12,73 mm.

Počítáme-li náklady 25 000Kč na mm, pak dostaneme cenu produktu 318 250Kč.

Procesní odhad: (v mm)

	Aktivita
Úkol	komunikace s uživatelem	Plánování	analýza rizik	Analýza	Návrh	Kódování	Testování	součet
UICF				0,5	1,5	0,2	2	4,2
DBM				0,5	2	1	0,75	4,25
PC				0,25	1	0,25	0,75	2,25
DAM				0,5	1	0,25	1	2,75
součet	0,1	0,1	0,1	1,75	5,5	1,7	4,5	13,75
pracnost [%]	1	1	1	13	40	12	32	100

Počítáme-li náklady 25 000Kč na mm, pak dostaneme cenu produktu 343 750Kč.

COCOMO:

E = a(KLOC)^b*EAF

D = c(E)^d

Kde EAF je opravný faktor, který se spočítá jako součin faktorů uvedených v následující tabulce:

Jméno	Hodnota	Popis
Faktory systému
RELY	0,98	spolehlivost
DATA	1	rozsah dat
CPLX	0,85	složitost systému
Faktory počítače
TIME	1	časové omezení (rychlost systému)
STOR	1	paměťové omezení
VIRT	1	stabilita počítače
TURN	1	rychlost odezvy počítače při vývoji
Faktory řešitelů
ACAP	0,86	znalosti a zkušenosti analytika
AEXP	0,91	znalost aplikace
PCAP	0,86	zkušenosti a schopnosti programátorů
VEXP	0,9	znalosti virtuálního počítače
LEXP	0,95	znalost programovacího jazyka
Faktory projektu
MODP	1	moderní programovací metody
TOOL	0,91	použití programových nástrojů
SCED	1	časový plán

Počet řádek zdrojového kódu odhadneme na 8000.

Zvolíme organický mód. Tomu odpovídají hodnoty parametrů a = 3,2, b = 1,05.

Pak nám vyjde pracnost E = 12,39 mm

Počítáme-li náklady 25 000Kč na mm, pak dostaneme cenu produktu 309 750Kč.

Porovnání odhadů pracnosti:

LOC 13,11mm

FP 12,73 mm

PO 13,75 mm

COCOMO 12,39 mm

Průměrný odhad 13 mm. Největší odchylka je 5,8%.

Průměrné náklady budou 325 000Kč.

Plán zdrojů:

Pracovník	Role	Odborné zkušenosti
Luboš Vondra	vedoucí týmu	zkušenosti s vedením týmu, znalosti databázové problematiky, analytické znalosti
Zdeněk Vondra	manažer jakosti	zkušenosti s testováním softwareových produktů, znalosti databázové problematiky, analytické znalosti
Stanisla Duben	grafik	znalost internetových aplikací, zkušenosti s návrhem grafických rozhraní
Ondřej Mackovič	ideolog	zkušenosti s vymezením teoretického návrhu a implementace, schnopnost navrhovat nová řešení
Radek Lochman	ekonom	ekonomické znalosti, schopnost analyzovat výhodnou ekonomickou situaci
Michal Semler	analytik	analytické znalosti, schopnost analyzovat problém a vybrat nejvhodnější řešení

Globální harmonogram:

Tabulka rizik:

Rizika	Kategorie	Pravděpodobnost	Dopad	Možné řešení	Kdo bude řešit problém
fluktuace členů týmu	projektový tým	50%	kritický	náhradní pracovníci, dostatečné ohodnocení	vedoucí týmu
nízký odhad velikosti	velikost produktu	50%	kritický	rezerva při plánování, dohoda se zákazníkem	vedoucí týmu, ekonom
penále při pozdním odevzdání	odchodní	30%	kritický	časová rezerva, dohoda se zákazníkem, přijetí dalších pracovníků	vedoucí týmu, ekonom
jsou formální revize dokumentovány včetně nalezených chyb?	procesní	30%	marginální	průběžná konrola	manažer kvality
zákazník změní požadavky	procesní	10%	kritický	úprava produktu podle nových požadavků	celý tým

Detailní plán analýzy:

Struktura členění prací:

Detailní harmonogram:

Sloupcové diagramy zdrojů:

Matice zodpovědnosti:

	Pracovník
Činnost	Luboš Vondra	Zdeněk Vondra	Stanislav Duben	Radek Lochman	Ondřej Mackovič	Michal Semler
Komunikace v týmu a vedení týmu SI1
Rozdělování úkolů
Internetové stránky projektu
Rámcový plán projektu
Detailní plán analýzy
Plán řízení jakosti
Plán testů a akceptací
Zpráva průběžné kontroly řešení
Deklarace záměru
Odborný článek
Kontextový diagram
Model jednání
Návrh rozpočtu
Návrh software a hardware
Harmonogram
Datový slovník
Datový model
Data Flow Diagramy
Minispecifikace
Návrh grafického rozhraní

Plán řízení jakosti:

Plán řízení jakosti je prostředek určený pro dohled nad vyvíjeným softwarem a pro kontrolu předem daných kritérií, které musí produkt splňovat. Mezi hlediska pro posouzení kvality softwaru patří bezpečností politika, neboli ochrana proti hackerským, nebo podobným, napadnutím jak z internetu, tak v rámci společnosti, ve které bude software provozován, dále pak kvalita databázového systému, jenž bude využíván a kvalita návrhu databázového schématu pro uložení dat a v neposlední řadě je to způsob a kvalita pravidelného zálohování důležitých dat.

Harmonogram

Harmonogram plánu řízení jakosti slouží mimo jiné i k přesnému stanovení pravidel pro vývoj systému, která by měla při důsledném dodržování dopomoci k tomu, aby bylo směřováno k předem stanovenému cíli, tj. kvalitnímu informačnímu systému. Dále může z harmonogramu, při jeho správném zpracování a navržení a ve spolupráci s celým týmem, kde je velmi důležitá komunikaci mezi členy týmu, včetně vedoucího, vedoucí týmu vyčíst v jaké fázi se nachází jednotlivé části projektu, tzn. jestli již jsou hotovy, jestli jsou právě vyvíjeny, nebo jestli budou z důvodu závislosti na jiných částech systému vyvíjeny až v pozdější době. Již výše zmíněná komunikaci mezi členy týmu včetně vedoucího je velmi podstatná, protože vedoucí by měl být k dispozici pro konzultaci nějakého problému týkajícího se vývoje informačního systému pro zajištění prevence jeho kvality. Během vývoje budou testerovi předávány vypracované dílčí úkoly a tester v rámci zajištění kvality prověří, zda dílčí úkol splňuje předem daná kriteria. Pro provedení testů je svolána porada, kde jsou probrány případné nalezené nedostatky a bude vyvíjena snaha o nalezení řešení vzniklých nedostatků. V případě nalezení řešení bude toto řešení předáno pracovníkovi, který dílčí úkol plnil a ten opraví svou práci dle navrženého řešení. Pokud nebude řešení okamžitě nalezeno, bude svolána další porada o něco později, kde se bude v hledání řešení pokračovat. Zde je nutné upozornit na to, že u dílčích úkolů, které jsou kritické protože na nich závisí další dílčí úkoly je třeba nalézt řešení co nejrychleji, aby se celý projekt velmi neprotáhl. Harmonogram řízení jakosti je přizpůsoben harmonogramu celého projektu, kde na testování a případnou opravu je vymezen dostatečný časový úsek.

Legenda:

A2:

B2:

C2:

D2,D4,D6,D8:

E1:

F1:

F2:

G1:

G2:

G3:

H2:

Testy, zda postupy uvedené v dokumentaci skutečně vedou k očekávaným výsledkům.

Dokumentace

Dokumentace je nedílnou součástí každého projektu i každé jeho dílčí části, proto i my budeme dokumentaci vytvářet kvalitně tak aby sloužila svému účelu. Dokumentace bude mimo jiné sloužit i ke kontrolování jakosti a správnosti funkce jednotlivých dílčích úkolů. Vytváření dokumentace je součástí pracovní náplně jednotlivých pracovníku pracujících na daném projektu, kde každý vytváří dokumentaci k tomu, co vytvořil. Případné nalezené nedostatky, či neshody v dokumentaci budou sděleny pracovníku, který ji vytvářel a ten také tyto nedostatky a neshody odstraní. Celá dokumentace bude uvedena na intranetových stránkách a za její úplnost a správnost bude odpovídat správce intranetové dokumentace, který vždy při změně této dokumentace bude informovat o změně celý tým.

Požadovaná dokumentace:

Odborný článek
Kontextový diagram
Datový slovník
Analýza a plán řízení rizik
Rozsah projektu - struktura členění prací
Globální harmonogram
Návrh řešení a rozpočet
Plán řízení jakosti
Datový, procesní a dynamický model

Úvodní studie

Úvodní studie důležitou součástí dokumentace, kde je definováno, co celý tým bude řešit. Studie bude obsahovat:

Deklaraci záměru
Odborný článek
Kontextový diagram
Model jednání
Scénáře událostí
Datový slovník

Projektová dokumentace

Projektová dokumentace vychází z úvodní studie. Z hlediska kvality se bude kontrolovat reálnost odhadu nákladů (HW,SW a vývoj) a také reálnost časového harmonogramu. Projektová dokumentace bude obsahovat:

Složení týmu
Návrh řešení
Odhad celkových nákladů, čili rozpočet
Globální harmonogram

Analytická dokumentace

Analytická dokumentace je podrobnějším zkoumáním daného problému. Po dokončení této fáze, již bude následovat samotná implementace. Tato část musí obsahovat:

Datový model
Dynamický model
Stavový diagram
Návrh uživatelského rozhraní

Testy

Dokumentace bude obsahovat harmonogram testů jednotlivých bodů předchozí dokumentace a také způsob testování, očekávané a dosažené výsledky.

Uživatelská dokumentace

Uživatelská dokumentace bude vypracována na základě analytické dokumentace a zejména samotné implementace. Bude obsahovat Průvodce instalací, Učebnici používání produktu a referenční příručku. Kontrolována bude jednotnost pojmů v jednotlivých dokumentech, správnost, věcnost a srozumitelnost.

Plán testů a akceptací:

Účelem testů je ověřit předpokládanou činnost programu a s co největší pravděpodobností objevit skryté chyby.

Testovaný software

V první fázi testování bude systém podroben testům na vyhledání chyb v jednotlivých modulech informačního systému. Dále budou následovat testy odhalující chyby a problémy při integraci jednotlivých modulů a testy zkoumající vlastnosti systému jako jsou: reakce na chyby, zátěž a použitelnost v konfrontaci s uživatelem.

Strategie testování

a) Jednotkový test

Testování zaměřené na verifikaci jednotlivých modulů. Podle popisu návrhu procedur jsou testovány důležité cesty uvnitř modulu. Testování jednotek je prováděno metodami white-box testing, paralelně pro více modulů, tzn. že pro každý modul otestujeme všechny cesty, kterými algoritmus může procházet.

b) Integrační testování

Integrace shora-dolů , začíná se hlavním řídicím modulem a postupuje se směrem dolů: buď strategií do hloubky nebo do šířky.

Hlavní modul je "driver", "stubs" nahrazují všechny podřízené moduly.
Postupně (buď podle přístupu do hloubky nebo do šířky) jsou nahrazovány "stubs" skutečnými moduly.
Po každém přidání modulu je systém otestován.
Regresní testování má zajistit, že nebyly zavlečeny nové chyby.

Regresní testování . Testuje se, zda nenastal vedlejší efekt přidáním nového modulu (zavlečené chyby) - opakováním předchozích testů.

c) Validační testování

Provádí se po integraci a slouží k ověření, že software splňuje očekávání zákazníka, která jsou definovaná ve specifikacích softwarových požadavků ("validační kritéria"). Provádí se metodami black-box testing, tzn. že je testováná funkčnost systému z pohledu jeho uživatele.
Alfa testování provádí zákazník v řízeném prostředí dodavatele ("programátor se mu dívá přes rameno").
Beta testování se provádí u zákazníka. Vývojový tým není přítomen. Zákazník zapisuje všechny problémy (skutečné i imaginární) a určitých intervalech je posílá dodavateli.

d) Systémové testování

Je to série testů, která prověřuje celý počítačový systém (HW, SW prostředí, databáze, uživatele systému…).
Recovery testing (testování obnovy). Systémové testování ověřující, že poruchy byly řádně ošetřeny v předepsaném čase. Pro automatické ošetření se vyhodnocuje re-inicalizace, mechanismus checkpointů, obnova dat, restart.
Security testing (bezpečnostní testování). Testování odolnosti proti útokům hackerů. Tester supluje roli hackera a snaží se proniknout do systému. Má-li dost času a zdrojů, tak se mu to podaří. Úlohou našeho systémového návrhu je, aby cena proniknutí do systému byla co největší.
Stress testing. Cílem je prověřit program v abnormální situací (kvantita, frekvence nebo obsah) - neboli jak dlouho mohu systém namáhat, než padne?

Výsledky testů

Výsledkem testů budou zprávy o provedených testech s výsledky. Uvedeno vždy bude, zda kvalita odpovídá požadavkům, a pokud ne, jak dalece se jim vzdaluje. Budou zaznamenány činnosti vedoucí k nápravě takto zjištěných rozporů a po jejich provedení budou testy zopakovány. V případě, že budou nalezeny chyby závažnějšího charakteru, bude připravena nová série testů, aby se zamezilo "cíleným" opravám chyb pro konkrétní případy.
Výsledky jednotlivých testů budou zaznamenávány. Na rozdíl od jiných dokumentů však při opakování testů nebude předchozí zpráva nahrazena novou verzí, ale obě budou uchovány paralelně. Nedílnou součástí dokumentace testování bude "Záznam o testech", ke kterému bude po každém provedeném testu připojen krátký záznam obsahující datum, charakteristiku daného testu a stručný přehled získaných výsledků. Tento dokument bude používán pro přehled o chronologické posloupnosti provádění testů.
Absolutní většina testů je rozhodovacích (testovaná jednotka má/nemá požadovanou kvalitu). Jedná se o všechny testy jednotkové a integrační a dále o testy zotavení z chyb. Výsledkem testů bezpečnosti bude zpráva o bezpečnostních slabinách systému, která se stane podkladem pro finální opravy autorizačních schémat.Výsledkem zátěžových testů bude opět informace o tom, zda se systém chová korektně i při nadměrné zátěži. Naopak u testů výkonových budeme hledat vztah mezi zatížením systému (frekvencí dotazů) a zatížením systému (počet dotazů čekajících na vyhodnocení, rychlost odezvy, dosažitelnost služby).

Zpráva průběžné kontroly:

Úvodní studie

Deklarace záměru

Deklarace záměru se je zpracována odpovídajícím způsobem.

Odborný článek

V odborném článku bylo zjištěno, několik drobných nedostatků, které byly okamžitě po projednání týmem odstraněny. Podstatnější nedostatek odborného článku byl v tom, že původně nezahrnoval možnost přeskakování rezervací obyčejných zákazníku zákazníky VIP, na což byl vedoucí týmu upozorněn zadavatelem. Vedoucí týmu o tom informoval autora odborného článku, který o tento požadavek odborný článek doplnil.

Kontextový diagram

Kontextový diagram je zpracován odpovídajícím způsobem. Všechny vztahy jsou přehledně a podrobně popsány.

Model jednání

Model jednání byl zpracován odpovídajícím způsobem.

Scénáře událostí

Scénáře možných událostí jsou zpracovány odpovídajícím způsobem a obsahují identifikaci zda bude událost počítačově podporována.

Datový slovník

Datový slovník je zpracován odpovídajícím způsobem. Jednotlivé atributy jsou zde podrobně popsány.

Projektová dokumentace

Rozpočet

Rozpočet získaný pomocí metody COCOMO odpovídá představám jak zadavatele tak týmů tvůrců systému.

Harmonogram

Etapy v harmonogramu jsou zpracovány správně. Není v něm však podchyceno důležité období na jednotlivé iterace testování. To řeší harmonogram řízení jakosti, který je samostatnou částí dokumentu.

Řešitelský tým

Seznam členů týmu je v pořádku uveden na intranetových stránkách projektu.

Analytická dokumentace

Datový model

Datový model byl v první fázi zpracován zcela chybně, protože obsahoval velmi matoucí názvy pro jednotlivé entity, ale hlavně se v něm nacházela podstatnější chyba a to duplicita entit při výdeji zboží se skladu, který navíc nebyl ani navázán na odběratele. Dále datový model vůbec neobsahoval entity pro příjem zboží na sklad. Po opravení těchto chyb byl datový model, po konzultaci se zadavatelem, rozšířen o entitu dodavatelů.

Dynamický model

Dynamický model v první fázi obsahoval podstatný nedostatek v tom, že obsahoval rozhodovací bloky, které se v dynamickém modelu vůbec nevyskytují. Po konzultaci s celým týmem byly tyto bloky odstraněny a dynamický model byl přepracován tak, aby odpovídal skutečnosti.

Minispecifikace

Minispecifikace je přehledná a je zpracována odpovídajícím způsobem.

Stavový diagram

Stavový diagram je zpracován odpovídajícím způsobem.

Návrh uživatelského rozhraní

Uživatelské rozhraní je vytvořeno velmi vkusně a je uživatelsky příjemné, přehledné. K tomuto rozhraní nemám výhrady.

Oponentura projektu CRM

Deklarace záměru

Deklarace záměru je převzata přímo od zadavatele projektu, čili její hodnocení vzhledem k tomuto projektu by bylo neadekvátní.

Odborný článek

Odborný článek obsahuje nedostatek v tom, že projektovaný systém nemá vyřizovat objednávky zákazníků, pouze jim zasílá nabídky, jak je správně uvedeno v bodě „Přehled o objednávkách zákazníka“, ale v dalších několika bodech je uvedeno, že objednávky i vyřizuje, nebo to aspoň z textu vyplývá.

Kontextový diagram

V kontextovém diagramu zcela chybí terminátor Zásilkové oddělení, který by měl zajišťovat akci číslo 2. Dále akce číslo 1 a 3 by měly mít obrácenou šipku, čili od Prodejního systému k systému CRM a tato šipka by mela být doplněna akcí získání informací o nakoupeném zboží daným zákazníkem. Akce číslo 4 je zcela chybná, protože žánrový profil je vnitřní informace systému CRM a osobní údaje jsou již v akci číslo 1. Akce číslo 5 by měla jít od systému CRM k systému prodejnímu a naopak jak je to v kontextovém diagramu uvedeno.

Model jednání

V modelu jednání je v horní části chybně pojmenovaný terminátor Zákazník, mělo by to být prodejní systém a dále by v této části neměly být funkce stav objednávky, objednání výrobku a zrušení objednávky, tyto funkce jsou součástí prodejního systému a ne systému CRM, a v neposlední řadě zde chybí funkce pro získání potřebných informací jako jsou seznam nakoupených, či objednaných výrobků daným zákazníkem, a informace o platební morálce zákazníka (mohla by to být funkce Prodej, ale v tom případě je chybně pojmenována). Tyto informace jsou získávány z prodejního systému. Dále jsou zde zcela navíc funkce zaslání výrobku a potvrzení objednávky. Toto je opět součást prodejního systému a ne systému CRM.

Scénáře událostí

Scénáře událostí ve většině případů popisují události nastávající při interakci prodejního systému a zákazníka a ne zákazníka a systému CRM, případně prodejního systému a systému CRM, což je cílem vytvářeného projektu. Akce odpovídající projektovanému systému CRM jsou pouze akce číslo 5, 7, 10.

Rozpočet

Rozpočet je zpracován korektním způsobem, až na to, že do výsledné ceny nejsou započteny náklady na software a hardware, které by ještě zvýšily výslednou cenu projektu, která je již tak dosti vysoká. Drobnou výhradu mám k použití programovacího jazyka JAVA, protože aplikace vytvořené v tomto programovacím jazyce jsou znatelně pomalejší a jejich nezávislost na operačním systému a verzi JRE není také až tak stoprocentní, viz E-R Modelář spuštěn na verzi JRE 1.4.1 nefunguje a při použití verze 1.3.1 funguje bez problému.

Návrh hardware a software

Hardware a software je navrhnut zcela dostačujícím způsobem pro projektovaný systém.

Harmonogram

Harmonogram je zpracován dostačujícím způsobem. Ale jeho prezentace je zcela nevhodná. Není možno si obrázek zvětšit a tak jak je uveden je zcela nečitelný a má nulovou vypovídající hodnotu.

Datový slovník

Datový slovník je zpracován odpovídajícím způsobem a nemám k němu výhrady.

Datový model

V datovém modelu postrádám uchovávání informace o novinkách a všech titulech dodávaných dodavatelskou firmou, dále entita Zboží by zde měla být asi pojmenována jako Dárek, protože systém žádné zboží nedodává, pouze může zásilkové oddělení informovat o tom, že má odeslat zákazníkovi dárek, nebo reklamu. A vztahy Zboží(Dárek) – Zásilka a Reklama – Zásilka by měly být vztahy výlučné, v malém množství případů budeme v jedné zásilce posílat dárek a zároveň reklamu, případně informace o nových titulech. V neposlední řadě by zde mohl být číselník určující, kdy má kdo svátek, protože jinak by bylo nutno tyto informace dohledávat jinde, což by bylo nepraktické a pomalejší.

Data Flow Diagram

Data flow diagram BONTON by měl mít data store DB data store pojmenován pravděpodobně DB zásilky. Data flow diagram KALENDÁŘ je v pořádku. U data flow diagramů PRODEJNÍ SYSTÉM a SPRÁVCE by měl být opět jinak pojmenován data store DB data store.

Minispecifikace

Akce nová objednávka je zcela zbytečná, protože tato akce není součástí systému CRM, ale prodejního systému. Systém CRM pouze přebírá informace o objednávkách a prodaném zboží z prodejního systému. Jinak nemám k minispecifikaci žádné další výhrady .

Stavový diagram

Stavový diagram je zpracován odpovídajícím způsobem a nemám k němu žádné výhrady.

Návrh GUI

GUI je navrženo zcela dostačujícím způsobem ve stylu „v jednoduchosti je síla“, což znamená, že neobsahuje žádné zbytečné „parádičky“, ale naopak obsahuje vše co je třeba.

Detailní plán analýzy

Detailní plán analýzy obsahuje pouze matici zodpovědnosti, které je zpracována dostačujícím způsobem a nemám k ní výhrady. Bohužel detailní plán analýzy neobsahuje strukturu členění prací, detailní harmonogram a diagramy zdrojů.

Rámcový plán projektu

Rámcový plán analýzy obsahuje pouze analýzu rizik, která je zpracována velmi dobře, bohužel opět neobsahuje některé další podstatné informace jako jsou stanovení rozsahu projektu, výpočet rozpočtů různými metodami, plán zdrojů a globální harmonogram.

Plán řízení jakosti

Dokumentace neobsahuje plán řízení jakosti.

Plán testů a akceptací

Plán testů a akceptací je zpracován odpovídajícím způsobem, jediné co v něm postrádám je informace o testování funkčnosti vytvořené aplikace samotným zadavatelem projektu.

Zpráva průběžné kontroly

Dokumentace neobsahuje zprávu průběžné kontroly.