TNPW2-2016-01
Download as PPTX, PDF0 likes497 views
Technologies for publication on the web II Department of Information Technologies University of Hradec Králové, Czech republic
TNPW2-2016-01
- 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
- 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