Technologies for publication on the web II Department of Information Technologies University of Hradec Králové, Czech republic

1. Úvodní informace k předmětu
Mgr. Lukáš Vacek
lukas.vacek@uhk.cz
TNPW2 2015/2016

2. 2
„I am still learning“ – Michelangelo (as 87 yo)

3. Agenda
• Obsah předmětu
• Vstupní předpoklady
• Podmínky pro zápočet
• Požadavky na projekt
• Osnova dokumentace
• Aktuální informace k předmětu na webu
• Rady, co se mi nikam nevešly…
3

4. • (Skoro) každý ví, co je to Internet! Dokonce i Věra Pohlová 
• Význam Internetu ve společnosti neustále roste
• Důležité médium (tisk, rozhlas, televize…)
• Vysoká míra interakce s koncovým uživatelem
• Komunikační prostředek (informace) a platforma pro poskytování služeb
• Flexibilní prostředí (ekosystém) s velmi dynamickým vývojem
(několik let zpátky = internetový středověk)
• Více možností přístupů, různá zařízení, vyšší rychlost (konektivita), 24/7 – odkudkoliv,
kdykoliv!
Infografika: The Evolution of the Web… http://evolutionofweb.appspot.com/
• Exponenciálně roste počet uživatelů a množství dat, která Sítí protečou
Internet? 4

5. 5
Zdroj Intel

6. • Co jsou to webové aplikace?
• Základní přehled používaných technologií, podrobněji
• JavaScript
• PHP (na cvičeních)
• ASP.NET (na cvičeních)
• Bezpečnost webových aplikací
• Aktuální trendy
• Cloud computing
• Mobilní aplikace
• XML (když bude čas)
• Cílem je navázat tam, kde skončil předmět TNPW1
Témata přednášek 6

7. • Absolvování předmětu TNPW1 (zápočet, zkouška)
• Praktická znalost (X)HTML
• Schopnost používat CSS při definování vizuálních vlastností WWW stránek
• Problematika webových aplikací vás zajímá jako technologie/business
Vstupní předpoklady 7

8. • Perspektiva ICT – jeden z nejlukrativnějších oborů, rychle se rozvíjí
• V kurzu je Internet, mobilní app, systémová integrace, DWH, BD, IoT, Java, .NET
• Vaše cena na trhu práce bude vyšší, když budete mít potřebné know-how
• Chápejte čas a úsilí věnované svému vzdělávání jako INVESTICI!
• Vzdělávání absolventů je dnes pro firmy drahé a riskantní
• Nikdo si z Vás nesedne na zadek!
• V reálném životě to je vždy trochu jinak, než jak si to ve škole představujeme
• Není nic špatného na tom, když něco nevíte nebo neumíte…
špatné je, když s tím nic neděláte!
• Nesvádějte svoji lenost nebo blbost na druhé!
K čemu je to dobré? 8

9. • Účast na mých cvičeních není povinná! Ostatní cvičící to mohou mít jinak!
• Pro získání zápočtu je třeba odevzdat závěrečný projekt.
• Projekt lze osobně prezentovat v termínech vypsaných v ISITu nebo na cvičeních
kdykoliv v průběhu semestru.
• Součástí projektu bude stručná dokumentace (stačí heslovitě na 1x A4).
Podmínky pro zápočet 9

10. • Projektem je webová aplikace, vytvořená ve Vámi zvolené technologii
• Součástí projektu bude vhodně zvolená integrace sociálních sítí
• Připravíte si powerpointovou prezentaci a ukážete funkční projekt, který má smysl provozovat
a používat!
• Projekt představíte jako šéfové vývojového týmu:
• O co jde?
• Komu je určen? (cílový uživatel)
• Proč by jej měl uživatel používat? (výhody)
• Porovnáte se s konkurencí (v čem je lepší/horší)
• Kolik MD stála implementace, za kolik je prodáváte?
• Výhled do budoucna (rozvoj, nové funkce, sociální sítě apod.)
• Pokud nejste programátor, někoho si na implementaci sežeňte. Ale budete tomu rozumět a
dokážete odpovědět na moje technické dotazy!
Obecné požadavky na projekt 10

11. • Skriptovací jazyky (PHP a spol.) používejte na projektech povinně v kombinaci s aplikačním
frameworkem (např. Nette, Zend...)!
• Výsledný zdrojový kód stránek bude validní HTML5!
• Aplikace bude fungovat i v mobilním prohlížeči (responsive web design)
• Struktura aplikace, navigace a vzhled stránek budou respektovat aspoň základní pravidla
pro přístupnost a použitelnost (znáte to z TNPW1!)
• Veškerá vizuální nastavení (layout, fonty, barvy apod.) budou definována v CSS (včetně
formátování pro tisk)
• Aplikační data budou uložena v databázi na serveru
• Všechny datové vstupy od uživatelů budou odpovídajícím způsobem ošetřeny (na straně klienta
je to vhodné, na straně serveru povinné), včetně zabezpečení proti opakovanému zápisu dat přes
obnovení stránky apod.
• V projektu bude vhodně využita technologie XML (např. RSS kanál s novinkami, export/import
dat apod.), pokud to má smysl
• Výjimky jsou přípustné, pokud je dokážete obhájit!
Technologické požadavky na projekt 11

12. • Cíl projektu
• Jméno autora!
• URL adresa projektu
• Popis řešení
• Popis použitých technologií
• Popis zabezpečení
• Odhadovaná pracnost a cena projektu
• K prezentaci si přineste aspoň jeden výtisk! Neposílejte mi osnovu mailem!
Osnova dokumentace 12

13. Na serveru http://tnpw2.webnode.cz najdete
• Informace k předmětu TNPW2
• Přednášky ke stažení (ve formátu PDF)
• Zdrojové kódy ukázkových příkladů
• Seznam doporučené literatury
• Odkazy na Internetu
Aktuální informace k předmětu na webu 13

14. Rady, co se mi nikam nevešly…

15. • Jednoduchá odpověď… ten kdo to platí! Obvykle business 
• Zákazník není váš soupeř, ale spoluhráč!
• Při rozhodování používejte ověřitelné argumenty (výpočet, porovnání)
• Cílem je úspěšná implementace projektu (s ohledem na podmínky)
• Potřeby zákazníka
• Harmonogram
• Peníze
• Kapacity (know-how)
• Hledejte nejjednodušší řešení požadavků!
• Nehledáme dokonalost, čistotu… „Done is better than perfect.“
• Udržitelnost v. neudržitelnost!
Projekt… KDO je tady ŠÉF? 15

16. • Komunikace je králem!
• Efektivní komunikace je klíčem k úspěšnému projektu
• Musíte být schopni vysvětlit své návrhy/nápady pokud možno stručně –
stostránkový dokument (skoro) nikdo nečte! Hlavně ne zákazník 
• Nebojte se používat názorné obrázky, buďte srozumitelní
• Vždy musíte vědět, kdo je vaše publikum… komu prezentujete/vysvětlujete
• Prezentujte realitu (funkce, stav projektu), nestavte vzdušné zámky (= zklamání)
• Co zákazník potřebuje (očekává)? Konkretizujte (pro různé role!)
• Pozor! Ne vždy je splnění všech zadaných požadavků možné
• Odporující si požadavky, termíny, cena, technologie, další omezení…
• Neodkládejte problémy (o kterých víte) na později!
Komunikace na projektu – I. 16

17. • Když vám něco (cokoliv) není jasné, zeptejte se!
• Průběžná zpětná vazba od zadavatele!
• Rozhodování o cílech probíhá na strategické, taktické a operační úrovni!
• Důležité je jednoznačné rozdělení zodpovědnosti na projektu (kdo-co?)
• Nenechte se vydírat!
• Žádný zákazník není důležitější než dobrý produkt (opakované řešení)
• Přínos pro jednoho zákazníka může být komplikací pro ostatní >> problém
• Pozor na statistiku (ankety… vědí lidé, o čem hlasují?)
• Naučte se říkat NE. Žádné „možná“ nebo „později“, prostě řekněte NE!
• Nebojte se! Nezapomeňte na to, že úplně KAŽDÝ MÁ SVÉHO ŠÉFA 
Komunikace na projektu – II. 17

18. • Motto: „Když něco nemůžete změřit, nemůžete to ani řídit“ – Peter Drucker
• Požadavky na informační systém určuje business!
• Zohlednit potřeby zákazníka, jejich pokrytí funkcionalitou systému
• Měřit přínos jednotlivých požadavků (ROI, TCO) – vyplatí se to, za jakých podmínek?
• Návrh architektury musí být v rovnováze – business/technologie – z krátkodobého
i dlouhodobého hlediska!
• Náklady ovlivňují zvolené technologické řešení
• Důležitá je zpětná vazba od businessu v průběhu všech etap řešení
• Kvalita výstupu je přímo úměrná kvalitě vstupních informací
• Implementace řešení, odhady pracnosti, náklady, termíny, pokrytí požadavků
• Kvantifikujte požadavky
• Obecné pojmy (např. rychle, flexibilně, rozšířitelně) nemají jednoznačný výklad
• Upřesněte, co konkrétní požadavek znamená? (např. Průměrná doba odezvy je… )
Projektové požadavky 18

19. • Koncový uživatel – intuitivní a správné chováním, výkon, spolehlivost,
použitelnost, dostupnost a bezpečnost
• Administrátor – přehlednost chování, jednoduchost správy, nástroje pro
monitorování provozu
• Pracovník businessu – konkurenceschopné funkce, co nejkratší dobu pro
uvedení do provozu, porovnání s konkurenčními produkty/službami a cenou
• Zákazník – zajímá ho cena, stabilita a termín dodání
• Vývojář – očekává jasně specifikované požadavky, a jednoduchý, konzistentní
přístup k dobře zdokumentovanému návrhu, snadné provádění změn
• Projektový manažer – vyžaduje předvídatelnost při sledování projektu, termínů,
rozpočtů a možnost produktivního využití zdrojů
• Zdroj: Monson-Haefel, Richard – 97 klíčových znalostí softwarového architekta
Příklady obvyklých požadavků a potřeb uživatelů 19

20. • Nepodceňovat!
• Často vychází z metodiky nebo z požadavků zákazníka
• Místo pro důležité informace o projektu… požadavky, design, protokoly,
provozní příručky apod.
• Nespoléhejte na lidskou paměť, dokumentace je spolehlivější
• Dokumentaci ukládat na jedno místo… do projektové knihovny!
• Pečlivě vše dokumentujte (požadavky i návrh architektury)
• Co, kdo, kdy, proč, jaká omezení?
• Všechny požadavky jednoznačně identifikujte (číslování!)
• Jedině s dokumentací lze rozhodnout, je-li dodávané řešení v souladu
s požadavky
• Kvalitní dokumentace zjednodušuje provoz a případný další rozvoj systému
Projektová dokumentace 20

21. • Různé možnosti, asi žádná není úplně 100% univerzální
• Kritéria pro výběr: znalost, zkušenost, flexibilita, norma/zákon
• Požadovaná metodika je často v zadávací dokumentaci
• Pokud si nějakou vyberete pro projekt, držte se ji
• Každá metodika se přizpůsobuje projektu (FTFP?) a lidem! Chce to čas!
• Některé jsou velmi robustní, jiné jsou jednoduché
• Podporují snahu MNG mít správné lidi ve správnou chvíli na správném místě
• Přehled metodik… Wiki
Projektové metodiky 21

22. • Jsou hodně trendy (konstatování)
• Extrémní programování (XP)
• Scrum
• Vývoj řízený vlastnostmi (FDD – Feature Driven Development)
• Lean software development
• Vývoj řízený testy (TDD – Test Driven Development)
• Crystal metodiky (Alistair Cockburn)
• Sprint method (Jiří Knesl)
Agilní metodiky 22

23. • http://www.zdrojak.cz/clanky/agilni-vyvoj-scrum/
• Product owner (pigs)
• Zastupuje zákazníka (business, který projekt platí)
• Určuje priority jednotlivých požadavků, implementační detaily, co bude ve kterém sprintu...
• Team member (pigs)
• Implementuje produkt/projekt, různé role (analýza, programování, testování apod.)
• Zodpovídá za chyby nebo úspěch svých úkolů
• Sám si organizuje práci na přidělených úkolech
• Scrum master (pigs)
• Odstiňuje vývojáře od problémů okolního světa (zajišťuje funkční HW, SW licence…)
• Učí, implementuje scrum metodiky
• Kontroluje, že jsou realizovány správně
• Zajišťuje potřebnou dokumentaci (Backlog, harmonogram, plán iterací, alokace kapacit...)
Agilní metodiky – SCRUM (Role I.) 23

24. • Stakeholders (chickens)
• Lidé od zákazníka, testeři, připomínky zvenčí
• Managers (chickens)
• Lidé ovlivňující prostředí projektu, nejsou pigs
• Nezapomeňte na ně, i když stojí jakoby mimo implementaci
Agilní metodiky – SCRUM (Role II.) 24

25. • Projekt je rozdělen do jednotlivých etap/iterací (sprintů)
• Plán sprintu… Co se bude dělat? A jak se to bude dělat?
• Jeden sprint cca 2-4 týdny (může být i kratší)
• Důležitá pravidla!
• V průběhu sprintu nejsou akceptovány žádné změny!
• Každý sprint musí být naplánován před svým zahájením!
• Často probíhá tzv. nultá iterace – řešení nějakého jednoduchého nebo naopak
důležitého úkolu v rámci týmu, resp. školení, příprava prostředí apod.
Agilní metodiky – SCRUM (Sprint) 25

26. • Seznam všech známých požadavků (tasks, tickets...) na projekt/produkt
• Každý požadavek má stanovenou prioritu (určuje ji Product owner a SCRUM
master)
• Všichni členové týmu mají přístup!
• V rámci sprintu má požadavek svého vlastníka (zodpovídá za implementaci,
výsledek)
• Pokud člen týmu stihne přidělené úkoly v rámci sprintu rychleji, může dostat
z backlogu další (po dohodě se SCRUM masterem!)
Agilní metodiky – SCRUM (Product backlog) 26

27. • Daily SCRUM (povinně!)
• Každý den ráno schůzka všech členů týmu, cca 15 minut
• Co jste udělali od poslední schůzky?
• Co máte naplánováno do další schůzky?
• Jsou nějaké problémy, na které jste narazili? Kdo je může pomoct vyřešit?
• Organizuje a řádně dokumentuje SCRUM master!
• SCRUM review meeting (povinně!)
• Probíhá na konci každé iterace (sprintu)
• Ukázka toho, co už je hotové
• Zpětná vazba
• Retrospektivní SCRUM meeting (doporučeno)
• Obvykle jen členové týmu a SCRUM master
• Získané zkušenosti, problémy, co a jak zlepšit?
Agilní metodiky – SCRUM (Scrum meeting) 27

28. • Používejte zdravý rozum!
• Implementace SCRUM metodiky potřebuje čas!
• Není to univerzální kráječ (řešení každého problému)!
• Je to přístup k vývoji software
• Je rychlý a flexibilní
• Je orientován na závazky (osobní zodpovědnost)
• Je založen na srozumitelnosti, kontrole a přizpůsobení
• Pozor na FTFP projekty!
Agilní metodiky – SCRUM (Doporučení) 28

29. • Čistota návrhu nikdy nesmí být na úkor použitelnosti nebo výkonu!
• Používejte vhodné návrhové vzory a doporučení (SOLID, GRASP …)
• Udělejte řešení co nejjednodušší (KISS)
• Příliš mnoho uživatelských konfigurací vede ke složitosti (a k problémům)
• Neopakujte se (DRY)
• Implementujte jen ty funkce, které jsou skutečně potřeba (YAGNI)
• Rozsah práce (bude to rychle) není důvodem pro implementaci funkce!
• I malá (nepromyšlená) změna může mít velký dopad
• Spousta špatných nápadů má rychlou/levnou implementaci 
Design aplikace (Co je dobré vědět?) 29

30. • Ukládat na jednom místě v repository (Git, TFS…)
• Definovat programátorské konvence
• Verzovat kód, používat tzv. labels
• Používat komentáře (lepší pochopení geniality autora kódu )
• Vždy dodržovat pravidlo GET – BUILD – RUN!
Zdrojové kódy 30

31. • Testujte všechno, co jde (funkční, zátěžové, integrační, unit…)
• Pokud se vám vyplatí testy automatizovat, udělejte to (hodně iterací, rozsáhlé
systémy, hodně dodavatelů, refaktorizace…)
• Lidský faktor selhává, automatický test proběhne vždy stejně
• Automatické testy lze dobře propojit s ukládáním změn do repository
• S automatickými testy souvisí přístup Continuous integration
• K tématu… Robert Dresler: Snižování rizikovosti softwarových projektů
Testování 31