Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Návrh a implementace webové aplikace pro podporu produktového řízení
BAKALÁŘSKÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Aplikovaná informatika
Autor: Jan Zabloudil
Vedoucí bakalářské práce: Ing. Vojtěch Růžička Praha, květen 2021
Prohlášení
Prohlašuji, že jsem bakalářskou práci Návrh a implementace webové aplikace pro podporu produktového řízení vypracoval samostatně za použití v práci uvedených pramenů a literatury.
V Praze 2. května 2020 ...
Jan Zabloudil
Poděkování
Děkuji vedoucímu práce Ing. Vojtěchovi Růžičkovi za trpělivost, odborné vedení, cenné rady a připomínky při vedení této práce.
Abstrakt
Práce se věnuje návrhu a implementaci webové aplikace pro podporu produktového řízení v organizacích. Cílem práce je vytvoření minimální verze webové aplikace, která bude šířena jako otevřený software. Práci můžeme rozdělit na dvě části. První část popisuje oblast produktového řízení a analýzu existujících aplikací v této oblasti. Na základě provedené analýzy je zpracován seznam funkčních požadavků a vytvořen návrh aplikace včetně uživatelského rozhraní. Dle návrhu webové aplikace se druhá část práce zaměřuje na její implementaci. Pro vývoj back-endové části aplikace se používá PHP a framework Symfony, front-endovou část aplikace tvoří HTML, CSS a nástroje platformy Bootstrap. Druhá část práce se dále zabývá ověřením funkčnosti aplikace. Závěrem práce představuje vizi budoucího rozvoje aplikace.
Klíčová slova
webová aplikace, produktové řízení, PHP, Symfony, otevřený zdrojový kód
Abstract
The theme of the thesis is the design and implementation of an open-source web application that should serve as a tool for product managers. The aim of this work is to create a minimum viable product in the form of a web application. The thesis begins with a description of the product management field and with an analysis of existing product management software tools. Based on the performed analysis, a list of features requirements is described and an application design is created.The second part of the thesis is focused on the app implementation according to the created app design. PHP and Symfony framework are used for the development of the application’s backend. A combination of HTML, CSS and Bootstrap framework is used for implementation of the app’s frontend. The second part of the thesis also describes the app testing. At the end of the work the vision for further development of the app is presented.
Keywords
web application, product management, PHP, Symfony, open-source
Obsah
Úvod... 14
1 Oblast produktového řízení... 15
1.1 Co je produktové řízení? ... 15
1.2 Detailní pochopení problému... 15
1.3 Software pro podporu produktového řízení ... 16
2 Úloha aplikace ... 17
2.1 Klíčové povinnosti produktového manažera ... 17
2.2 Analýza úlohy aplikace ... 18
3 Analýza existujících řešení... 20
3.1 Analýza aplikací pro podporu produktového řízení ... 20
3.2 Definice cílové uživatelské skupiny ... 25
4 Funkční požadavky ... 26
4.1 Způsob distribuce aplikace ... 26
4.2 Minimální verze aplikace ... 26
4.3 Prioritizace ... 26
4.4 Výběr platformy ...31
4.5 Popis jednotlivých funkcí aplikace ...31
4.5.1 UC1 Vytvoření uživatelského účtu ... 33
4.5.2 UC2 Přihlášení do uživatelského účtu ... 33
4.5.3 UC3 Úprava uživatelského účtu ... 33
4.5.4 UC4 Změna hesla ... 33
4.5.5 UC5 Smazání uživatelského účtu ... 33
4.5.6 UC6 Obnovení hesla ... 33
4.5.7 UC7 Správa Zpětné vazby ... 33
4.5.8 UC8 Správa Vlastností produktu ... 34
4.5.9 UC9 Správa Štítků ... 36
4.5.10 UC10 Upravení Portálu ... 36
4.5.11 UC11 Přidání Zpětné vazby přes Portál ... 36
4.5.12 UC12 Odhlášení z uživatelského účtu ... 37
4.6 Návrh uživatelského rozhraní aplikace ... 37
4.7 Databázový návrh ... 37
5 Implementace aplikace ... 40
5.1 Použité technologie... 40
5.2 Vývojové prostředí ... 40
5.3 Architektura aplikace ... 41
5.4 Způsob vykreslování stránek aplikace ... 41
5.5 Struktura zdrojového kódu aplikace ... 42
5.6 Popis implementace ... 43
5.6.1 Řadiče ... 44
5.6.2 Autentizace a autorizace ... 47
5.6.3 Databáze ... 50
5.6.4 Formuláře ... 53
5.6.5 Události ... 54
5.6.6 Vkládání závislostí ... 55
5.6.7 Posílání e-mailů ... 55
5.6.8 Šablonovací systém Twig ... 57
5.6.9 Bootstrap ... 58
5.6.10 Nevyužité Symfony komponenty ... 59
5.6.11 Zhodnocení vývoje aplikace ... 59
6 Testování aplikace ... 61
6.1 Nasazení aplikace do produkčního prostředí ... 61
6.2 Funkční testování... 61
6.3 Akceptační testování ... 62
6.4 Využití automatických testů... 63
6.5 Nástroje pro statickou analýzu kódu ... 64
7 Rozšíření aplikace ... 66
7.1 Vývoj nové funkcionality ... 66
7.2 Administrační přístup ... 66
7.3 Client-side rendering ... 66
7.4 Tailwind ... 68
7.5 Automatické testy... 68
8 Závěr ... 69
Použitá literatura ... 70 Přílohy ... I Příloha A: Popis zvažované funkcionality aplikace... I Příloha B: Specifikace případů užití ... IV Příloha C: Návrh uživatelského rozhraní aplikace... XXI Příloha D: Zdrojový kód aplikace ... XXIII
Příloha E: Ukázka aplikace ... XXIV
Seznam obrázků
Obrázek 1: Proces Objevování produktu (zdroj: https://www.productboard.com/blog/step-
by-step-framework-for-better-product-discovery/) ... 17
Obrázek 2: Value vs. Complexity Quadrant (zdroj: https://www.izenda.com/product- roadmap-prioritization-methods/) ... 27
Obrázek 3: Výsledek provedené metody Value vs. Complexity Quadrant (zdroj: autor).... 29
Obrázek 4: Případy užití (zdroj: autor) ... 32
Obrázek 5: UC7 Správa Zpětné vazby (zdroj: autor) ... 34
Obrázek 6: UC8 Správa Vlastností produktu (zdroj: autor)... 35
Obrázek 7: UC9 Správa Štítků (zdroj: autor) ... 36
Obrázek 8: UC11 Přidání Zpětné vazby přes Portál (zdroj: autor) ... 37
Obrázek 9: Fyzický model databáze (zdroj: autor) ... 39
Obrázek 10: Prerendering (zdroj: https://www.toptal.com/front-end/client-side-vs-server- side-pre-rendering) ... 67
Seznam tabulek
Tabulka 1: Zpracování metody Jobs-to-be-Done (zdroj: autor) ... 18
Tabulka 2: Popis pojmů metody The product strategy grid (zdroj: autor) ... 20
Tabulka 3: Provedení metody The product strategy grid (část 1) (zdroj: autor) ...21
Tabulka 4: Provedení metody The product strategy grid (část 2) (zdroj: autor) ... 22
Tabulka 5: Provedení metody The product strategy grid (část 3) (zdroj: autor) ... 23
Tabulka 6: Provedení metody The product strategy grid (část 4) (zdroj: autor) ... 24
Tabulka 7: Výsledek metody The product strategy grid (zdroj: autor) ... 25
Tabulka 8: Popis kvadrantů metody Value vs. Complexity Quadrant (zdroj: autor) ... 27
Tabulka 9: Provedení metody Value vs. Complexity Quadrant (zdroj: autor) ... 28
Tabulka 10: Provedení metody ICE (zdroj: autor) ... 29
Tabulka 11: České alternativy anglických názvů funkcionality aplikace (zdroj: autor) ...31
Tabulka 12: Popis entit (zdroj: autor)... 38
Tabulka 13: Popis struktury zdrojového kódu aplikace (zdroj: autor) ... 43
Tabulka 14: Nevyužité Symfony komponenty (zdroj: autor) ... 59
Tabulka 15: Scénáře funkčního testování (zdroj: autor) ... 61
Tabulka 16: Výsledek akceptačního testování (zdroj: autor) ... 63
Seznam výpisů programového kódu
Výpis 1: Ukázka řadiče (zdroj: autor) ... 44
Výpis 2: Ukázka použití Konvertoru (zdroj: autor) ... 44
Výpis 3: Použití Ovladače v řadiči (zdroj: autor) ... 45
Výpis 4: Ukázka Třídy pohledu (zdroj: autor) ... 46
Výpis 5: Příklad autentizace v aplikaci (zdroj: autor) ... 48
Výpis 6: Příklad třídy řídící autorizaci (zdroj: autor) ... 48
Výpis 7: Autorizace uvnitř řadiče (zdroj: autor) ... 49
Výpis 8: Příklad třídy entity (zdroj: autor) ... 50
Výpis 9: Uložení objektu do databáze (zdroj: autor) ... 51
Výpis 10: Ukázka použití DQL API (zdroj: autor) ... 52
Výpis 11: Ukázka třídy formuláře (zdroj: autor) ... 53
Výpis 12: Vložení závislosti v konstruktoru třídy (zdroj: autor)... 55
Výpis 13: Sestavení e-mailu (zdroj: autor) ... 56
Výpis 14: Odeslání připraveného e-mailu (zdroj: autor) ... 56
Výpis 15: Příklad Twig šablony (zdroj: autor) ... 57
Výpis 16: Ukázka funkčního testu (zdroj: autor) ... 64
Terminologický slovník
Pojem Definice
Autentizace „Jako autentizace se označuje proces ověření identity uživatele. Uživatel tedy prokazuje, že je tím, za koho se vydává.” (Štráfelda, 2015)
Autorizace „Autorizace je proces, kdy si aplikace ověřuje, že daná osoba má oprávnění provést nějakou činnost.”
(Štráfelda, 2015) Cross-Site Request Forgery
(CSRF)
Jedná se o útok na webové aplikace. „Útok může být snadno veden proti aplikacím, které pro uchování informace o přihlášení uživatele používají cookie nebo hlavičku Authorization. Podstata útoku spočívá v tom, že uživatele přimějeme navštívit stránku napadané aplikace, která provádí nějakou akci, aniž by o tom uživatel věděl. Útok tím pádem může být snadno veden proti aplikacím, do kterých se útočník může sám přihlásit a tím zjistit jejich strukturu nebo které mají přístupný zdrojový kód. “ (Vrána, 2006) Cross-Site Scripting (XSS) Jedná se o zranitelnost webové aplikace, při které
aplikace uchovává škodlivá data od uživatele. Obvykle se jedná o data v podobě hypertextového odkazu, který odkazuje na škodlivý obsah. Útočníci nejčastěji
vkládají škodlivý obsah pomocí JavaScript kódu a oklamou uživatele, aby klikl na odkaz, pomocí kterého útočníci například ukradnou data uživatele
(Cgisecurity.com, 2002).
Data Mapper Jedná se o návrhový vzor, který popisuje vrstvu softwaru oddělující objekty v paměti od záznamů v databázi. Odpovědností vzoru je přenášet data mezi vrstvou objektů a databázovou vrstvou a zároveň obě vrstvy udržovat oddělené (Fowler, 2005).
Framework „Framework je softwarová struktura, která slouží jako podpora při programování, vývoji a organizaci jiných softwarových projektů. Může obsahovat podpůrné programy, knihovnu API, návrhové vzory nebo doporučené postupy při vývoji.“ (Škrášek, 2008)
Hash „Digitální otisk textu, který je výsledkem hashovací funkce. Má podobu jedinečného shluku čísel a písmen.
Používá se všude tam, kde nechceme, aby třetí strana
Pojem Definice
odhalila námi napsanou zprávu.“ (Digitální pevnost, 2018)
Návrhový vzor Pozorovatel „Návrhový vzor Observer (Pozorovatel) se používá v situacích, kdy chceme, aby nějaké objekty dostávaly informaci o změně stavu jiného objektu a zároveň měly možnost za běhu ovlivňovat, které objekty to budou.” (Hordějčuk, 2008)
Návrhový vzor Prostředník „Prostředník je návrhový vzor pro návrh struktury objektů, které mezi sebou komunikují. Zjednodušeně řečeno: místo toho, aby spolu objekty komunikovaly přímo, využijí k tomu prostředníka.“ (Hordějčuk, 2008)
Refactoring Refactoring je proces provádění změn ve zdrojovém kódu softwarového programu. Cílem je vylepšení vnitřní struktury zdrojového kódu bez změny chování programu (Fowler, 2000).
Search engine optimalization (SEO)
„Proces ovlivňování viditelnosti webu nebo stránky v neplacené části výsledků internetového vyhledávače.
Obecně řečeno, čím výše a čím častěji se web objevuje ve výsledcích vyhledávače, tím více návštěvníků web může z internetového vyhledávače získat. SEO může cílit na různé typy hledání včetně obrázků, lokálního hledání, videí, akademických informací, novinek nebo užšího hledání v specifických oborech.“ (Ungr, 2014) SQL injection SQL injection je technika s cílem narušit databázi.
Škodlivý kód je umístěn přímo do SQL dotazu prostřednictvím vstupu na webové stránce (W3Schools, 2010).
Sůl (kryptografie) „Při hashování hesla se na vstup navíc ještě přidává nějaký další řetězec, takzvaná sůl. Sůl je pokaždé jiná, výsledný hash je tak i pro stejná hesla pokaždé jiný.” (Štráfelda, 2015)
User experience (UX) Obor, který se zabývá všemi aspekty interakce koncového uživatele s firmou, jejími službami a produkty. Cílem správného UX je naplnit co
nejefektivněji potřeby uživatele (Norman a Nielsen, 2020).
Úvod
Proč riskovat vytváření špatného produktu, když mohou firmy nejdříve ověřit, jestli výrobek řeší reálné potřeby zákazníků? V posledních letech zejména s rozvojem informačních technologií si firmy začínají uvědomovat, že nestačí optimalizovat vytváření produktů, marketing a prodejní aktivity a doufat v úspěch. Uvedení produktu na trh předchází výzkum a analýza s cílem pochopit potřeby potenciálních zákazníků a navrhnout řešení, které tyto potřeby dokáže naplnit. Návrhem a rozvojem produktů, které splňují výše uvedené parametry, se zabývá obor produktového řízení (anglicky Product management). Čas a zdroje investované do aktiv spojených s návrhem správného produktu jsou zanedbatelné v porovnání se zdroji, které musí firma vynaložit při samotném vývoji a prodeji výrobku, tak proč riskovat? Není divu, že produktové řízení je v posledních letech na vzestupu, firmám totiž pomáhá řešit zásadní věc – vytvářet produkty, které uživatelé skutečně chtějí. Stejně jako jiné obory v dnešní době i produktové řízení využívá při výkonu své práce podpory informačních technologií. Se zvýšením poptávky po oboru se začaly rozvíjet i softwarové nástroje specializované na produktové řízení. Rozvoj nástrojů ještě umocnilo to, že obor je vysoce poptávaný zejména v oblasti informačních technologií, jejichž úloha ve společnosti neustále roste. Na rozdíl od ostatních oblastí zakořeněných v oboru informačních technologií nejsou pro produktové řízení hojně rozšířené softwarové nástroje s otevřeným zdrojovým kódem, které lze využívat zdarma a dále je rozvíjet.
Cílem bakalářské práce je implementovat minimální verzi webové aplikace s otevřeným zdrojovým kódem pro podporu produktového řízení v organizacích pomocí PHP frameworku Symfony. Aplikace je vytvořena s motivací přispět k dalšímu rozvoji oboru a zpřístupnit software pro organizace, které nemají prostředky pro využívání placených nástrojů. V práci je představen obor produktového řízení, analýza, návrh a implementace aplikace s využitím PHP frameworku Symfony. Pro pochopení části práce popisující vývoj aplikace je u čtenáře předpokládána znalost principů tvorby webových stránek a objektově- orientovaného programování. Na závěr práce je popsáno testování aplikace a její další rozvoj v budoucnu.
1 Oblast produktového řízení
V této kapitole je představena oblast produktového řízení a jeho hlavní úkoly v rámci organizace.
1.1 Co je produktové řízení?
Produkty existují, aby řešily problémy reálného světa, se kterými se lidé potýkají. Cagan definuje produktové řízení jako činnost, jejímž cílem je vytvořit produkt, který je hodnotný, použitelný a realizovatelný. Hodnotný ve smyslu toho, že řeší problémy lidí v jejich osobním i profesním životě. Musí být natolik použitelný, aby lidé poznali přínos produktu a nebyli odrazeni během procesu osvojování používání výrobku. A organizace musí být schopna produkt vytvořit se zdroji, které má k dispozici (Cagan, 2017). Hlavním úkolem produktového řízení v organizaci je rozhodnout jak nakládat s produkty, které organizace přináší na trh. Mají být produkty dále rozvíjeny, upravovány nebo zrušeny? Má organizace případně rozšířit portfolio o nový produkt (Productboard, 2014)? Podle Cagana je odpovědností produktového manažera vyhodnocovat a rozhodovat, co by mělo být doručeno zákazníkovi. Každý podnik závisí na zákaznících, kteří kupují či používají podnikem poskytovaný výrobek. Produkt je výsledkem toho, co vytvoří produktový tým podniku. A odpovědností produktového manažera je rozhodnout, co má produktový tým vytvořit (Cagan, 2017). Role produktového manažera spočívá v rozhodování, co a kdy postavit a jak přimět uživatele neboli zákazníky, aby daný produkt používali (Intercom, 2017).
1.2 Detailní pochopení problému
Pro vytvoření produktů, které jsou hodnotné, použitelné a realizovatelné, je podle Cagana nutné, aby produktoví manažeři dokonale znali své uživatele, jejich potřeby a problémy (Cagan, 2017). Cíl produktového řízení lze definovat i jako snahu o co nejkomplexnější pochopení problémů uživatelů a nalézání nejlepších řešení (Productboard, 2014).
Produktoví manažeři využívají tzv. Product discovery process (dále Proces objevování produktu). Tento proces jim pomáhá detailně pochopit, co uživatelé řeší za problémy. Díky pochopení problému dokáží navrhnout jeho nejlepší možné řešení. Proces objevování produktu je cyklus aktivního zaznamenávání, zkoumání a prioritizování potřeb uživatelů a následné validování možných řešení těchto problémů (Productboard, 2019). Podle Cagana má Proces objevování produktu následující cíle: zjistit, jestli budou zákazníci připravovaný produkt používat, případně jestli za něj budou ochotni zaplatit. Dále proces ověřuje, zda zákazníci dokáží produkt používat, jinými slovy jestli je pro ně dost srozumitelný. Třetím cílem je ověření, zda dokáže daná organizace navržený produkt vytvořit (Cagan, 2017).
1.3 Software pro podporu produktového řízení
Softwarové nástroje pomáhají produktovým manažerům s produktovým řízením. Nástroje jsou využívány při provádění Procesu objevování produktu, usnadňují prioritizaci a pomáhají sdílet produktovou vizi a strategii napříč celou organizací. První nástroj tohoto druhu byl představen v roce 2012 (Productboard, 2019). V posledních 10 letech získává produktové řízení v organizacích dle studie1 Neila Lyere na důležitosti. Zvyšující se úloha tohoto oboru se projevila i v počtu nástrojů, které byly na trh uvedeny (Iyer, 2019). Ve všech případech se jedná o monetizované aplikace, které nabízí komplexní řešení pro podporu produktového řízení. Dle autorem provedené analýzy v kapitole 3 není na trhu rozšířena aplikace s otevřeným zdrojovým kódem, která by byla k dispozici pro organizace zdarma, byla volně šiřitelná a modifikovatelná. Autor si klade jako cíl této bakalářské práce vytvořit minimální verzi aplikace pro podporu produktového řízení. V následujících kapitolách je představena úloha aplikace, provedena analýza stávajících řešení a následně představen návrh autorovy aplikace.
1 https://medium.com/agileinsider/incredible-growth-in-demand-for-product-managers-in-the- us-but-not-necessarily-in-the-places-youd-936fec5c1932
2 Úloha aplikace
V kapitole 2 je blíže představena úloha implementované aplikace. Byla provedena analýza s cílem identifikovat konkrétní cíle, kterých chce uživatel používáním aplikace dosáhnout.
Aplikace má primárně pomáhat produktovým manažerům s prováděním metody Objevování produktu a s dalšími klíčovými odpovědnostmi.
2.1 Klíčové povinnosti produktového manažera
Dle Cagana je jednou z klíčových schopností produktového manažera dokonalá znalost uživatelů. První krokem v rámci metody Objevování produktu je sbírání zpětné vazby a pochopení problémů, potřeb a úhlu pohledu uživatele. Pro identifikaci potřeb uživatelů je důležité vytvořit proces pro sběr a analýzu uživatelské zpětné vazby (Cagan, 2017). V dalším kroku metody Objevování produktu je na základě potřeb uživatelů vytvořen návrh řešení.
Tento návrh je představen uživatelům a je ověřeno, zda skutečně plní jejich potřeby, jinými slovy je zjištěno, zda se jedná o správné řešení. Ve chvíli, kdy jsou připraveny návrhy řešení, je třeba rozhodnout, jaké návrhy implementovat jako první. K rozhodnutí se využívají různé metody prioritizace. Pro ilustraci autor práce uvádí metodu RICE, která umožňuje hodnotit jednotlivé návrhy na základě čtyř parametrů: dosah, hodnota, důvěra v hodnotu a komplexita (Productboard, 2020).
Obrázek 1: Proces Objevování produktu (zdroj: https://www.productboard.com/blog/step-by-step- framework-for-better-product-discovery/)
Další úlohou produktového manažera je sdílení produktové strategie a vize napříč organizací (Productboard, 2015). V následujících odstavcích je představeno, jakou úlohu bude hrát aplikace při výkonu jednotlivých povinností produktového manažera.
2.2 Analýza úlohy aplikace
Na základě klíčových povinností produktového manažera bylo analyzováno, jakých konkrétních cílů se bude uživatel při používáním aplikace snažit dosáhnout. Pro analýzu byla použita metoda Jobs-to-be-Done (dále jen JTBD). Metoda slouží pro určení konkrétních cílů, kterých se snaží uživatel používáním produktu dosáhnout (Intercom, 2017). Cílem JTBD je upravit vztah mezi uživatelem a jeho potřebou. Potřeba je formulována jako úloha, kterou chce uživatel vykonat. A uživatel používá produkt, aby mu pomohl danou úlohu vykonat (Productboard, 2020). Prvním krokem při provedení analýzy je určit úlohy, které bude uživatel v aplikaci provádět. Na základě klíčových povinností produktového manažera byly vybrány následující úlohy:
• správa zpětné vazby od uživatelů,
• validace plánovaných produktových úprav,
• plánování a prioritizace produktových úprav.
Následně je každá úloha popsána ve struktuře „sloveso úlohy – předmět úlohy – upřesnění úlohy“. Při provedení analýzy autor využil také své vlastní znalosti nabyté tříletým působením na pozici produktového manažera. Průběh a výsledky metody zobrazuje následující tabulka (Tabulka 1).
Tabulka 1: Zpracování metody Jobs-to-be-Done (zdroj: autor)
Sloveso úlohy Předmět úlohy Upřesnění úlohy
spravovat zpětnou vazbu od uživatelů na jednom místě, online
validovat návrhy produktových úprav online, s využitím co největšího počtu uživatelů
plánovat a prioritizovat
chystané produktové úpravy online, na základě zpětné vazby
Jako první byla analyzována úloha správy uživatelské zpětné vazby. Dle autora je pro produktové manažery klíčové, aby mohli spravovat veškerou zpětnou vazbu na jednom místě. Důležitým aspektem je také dostupnost dat online. Druhou úlohou je validace návrhů produktových úprav. Zde je klíčovým aspektem jednoduchá komunikace s co největším počtem uživatelů. Poslední analyzovanou úlohou bylo plánování a prioritizace chystaných produktových úprav. Opět je dle autora důležité, aby bylo možné plánování provádět online a bylo prováděno na základě získané zpětné vazby.
Výsledky analýzy byly použity při návrhu konkrétní funkcionality aplikace spolu s výsledky analýzy existujících řešení, která je zpracována v následující kapitole. Návrh funkcionality je představen v kapitole 4.
3 Analýza existujících řešení
V kapitole 3 je představena analýza existujících aplikací pro podporu produktového řízení.
Následně jsou definovány klíčové vlastnosti autorem implementované aplikace a je popsána cílová uživatelská skupina aplikace.
3.1 Analýza aplikací pro podporu produktového řízení
Byla provedena analýza šestnácti existujících aplikací pro podporu produktového řízení.
Cílem analýzy bylo prozkoumat klíčové funkce a vlastnosti, které jednotlivé aplikace vzájemně odlišují a pomáhají jim být úspěšný na trhu. Aplikace byla analyzována pomocí metody The product strategy grid představenou Danem Olsenem (Productboard, 2018). Metoda rozděluje vlastnosti produktů do třech kategorií, které jsou zpracovány v následující tabulce (Tabulka 2).
Tabulka 2: Popis pojmů metody The product strategy grid (zdroj: autor)
Kategorie Popis
Must-haves (dále jen Klíčové funkce/vlastnosti)
Klíčová funkcionalita, bez které není produkt na trhu
konkurenceschopný. Jedná se zároveň o funkcionalitu, bez které uživatelům přestává dávat smysl produkt používat.
Performance benefits (dále jen Funkce/vlastnosti zlepšující použitelnost)
Funkce a vlastnosti produktu, které zlepšují zážitek z jeho používání. Při analýze jsou přiřazovány hodnoty vysoký, střední, nízký. Vysoký značí vysokou míru přispění ke zlepšení
použitelnosti, naopak nízký značí malou míru přispění ke zlepšení použitelnosti.
Delighters (dále jen Neočekávané funkce/vlastnosti)
Vlastnosti a funkce, které přinášejí uživatelům neočekávanou hodnotu a odlišují produkt od konkurence.
Provedenou analýzu zobrazují následující tabulky (Tabulka 3-6).
Tabulka 3: Provedení metody The product strategy grid (část 1) (zdroj: autor)
Funkce/vlastnosti Productboard2 Pendo3 ProductPlan4 Uservoice5 Klíčové
Správa zpětné vazby Ano Ano Ne Ano
Validace návrhů produktových
úprav Ano Ano Ano Ano
Prioritizace Ano Ne Ano Ano
Produktová mapa Ano Ano Ano Ano
Zlepšující použitelnost
Pohodlné ovládání Vysoký Vysoký Vysoký Střední
Jednoduchost Střední Nízký Vysoký Střední
Neočekávané
Integrace Ano Ano Ano Ano
Použití zdarma Ne Ne Ne Ne
Analytika Ne Ano Ne Ne
Průzkumy Ne Ano Ne Ano
Integrace do aplikace Ne Ano Ne Ano
Průvodce/zprávy uživatelům Ne Ano Ne Ne
Nastavení vize, strategie, cíle
firmy Ne Ne Ne Ne
Plánování zdrojů Ne Ne Ne Ne
Pořízení záznamů obrazovky
uživateli Ne Ne Ne Ne
Modifikovatelnost Ne Ne Ne Ne
2 https://www.productboard.com/
3 https://www.pendo.io/
4 https://www.productplan.com/
5 https://uservoice.com/
Tabulka 4: Provedení metody The product strategy grid (část 2) (zdroj: autor)
Funkce/vlastnosti UserBack6 Gainsight7 harvestr8 prodpad9 Klíčové
Správa zpětné vazby Ano Ano Ano Ano
Validace návrhů produktových úprav Ne Ne Ne Ano
Prioritizace Ne Ne Ano Ano
Produktová mapa Ne Ne Ano Ano
Zlepšující použitelnost
Pohodlné ovládání Vysoký Střední Střední Vysoký
Jednoduchost Střední Nízký Nízký Vysoký
Neočekávané
Integrace Ano Ano Ano Ano
Použití zdarma Ne Ne Ne Ne
Analytika Ne Ano Ne Ne
Průzkumy Ano Ne Ne Ne
Integrace do aplikace Ano Ano Ne Ano
Průvodce/zprávy uživatelům Ne Ano Ne Ne
Nastavení vize, strategie, cíle firmy Ne Ne Ne Ne
Plánování zdrojů Ne Ne Ne Ne
Pořízení záznamů obrazovky uživateli Ano Ne Ne Ne
Modifikovatelnost Ne Ne Ne Ne
6 https://www.userback.io/
7 https://www.gainsight.com/
8 https://harvestr.io/
9 https://www.prodpad.com/
Tabulka 5: Provedení metody The product strategy grid (část 3) (zdroj: autor)
Funkce/vlastnosti Craft io10 roadmunk11 airfocus12 productstash13 Klíčové
Správa zpětné vazby Ano Ano Ne Ano
Validace návrhů produktových
úprav Ano Ne Ne Ano
Prioritizace Ano Ano Ano Ne
Produktová mapa Ano Ano Ano Ano
Zlepšující použitelnost
Pohodlné ovládání Střední Vysoký Vysoký Vysoký
Jednoduchost Střední Střední Vysoký Střední
Neočekávané
Integrace Ano Ano Ano Ne
Použití zdarma Ne Ne Ne Ano
Analytika Ne Ne Ne Ne
Průzkumy Ne Ne Ne Ne
Integrace do aplikace Ne Ne Ne Ano
Průvodce/zprávy uživatelům Ne Ne Ne Ano
Nastavení vize, strategie, cíle
firmy Ano Ne Ne Ne
Plánování zdrojů Ano Ne Ne Ne
Pořízení záznamů obrazovky
uživateli Ne Ne Ne Ne
Modifikovatelnost Ne Ne Ne Ne
10 https://craft.io/
11 https://roadmunk.com/
12 https://airfocus.com/
13 https://www.productstash.io/
Tabulka 6: Provedení metody The product strategy grid (část 4) (zdroj: autor)
Funkce/vlastnosti canny io14 glidr15 aha io16 usersnap17 Klíčové
Správa zpětné vazby Ano Ano Ano Ano
Validace návrhů produktových
úprav Ano Ano Ano Ano
Prioritizace Ne Ano Ano Ne
Produktová mapa Ano Ano Ano Ne
Zlepšující použitelnost
Pohodlné ovládání Vysoký Vysoký Střední Střední
Jednoduchost Vysoký Střední Nízký Střední
Neočekávané
Integrace Ano Ano Ano Ano
Použití zdarma Ne Ne Ne Ne
Analytika Ne Ne Ne Ne
Průzkumy Ne Ne Ne Ano
Integrace do aplikace Ne Ne Ne Ano
Průvodce/zprávy uživatelům Ne Ne Ne Ano
Nastavení vize, strategie, cíle firmy Ne Ne Ne Ne
Plánování zdrojů Ne Ne Ne Ne
Pořízení záznamů obrazovky
uživateli Ne Ne Ne Ano
Modifikovatelnost Ne Ne Ne Ne
Na základě výsledků analýzy byly definovány vlastnosti plánované aplikace, jsou uvedeny v následující tabulce (Tabulka 7).
14 https://canny.io/
15 https://www.glidr.io/
16 https://www.aha.io/
17 https://usersnap.com/
Tabulka 7: Výsledek metody The product strategy grid (zdroj: autor)
Klíčové funkce/vlastnosti
Správa zpětné vazby Aplikace musí umožňovat sbírat a uchovávat zpětnou vazbu od uživatelů.
Validace návrhů produktových úprav Možnost plánovat a sdílet návrhy produktových úprav s uživateli a získávat na ně zpětnou vazbu.
Prioritizace Prioritizace navrhovaných produktových úprav na základě zpětné vazby.
Produktová mapa Možnost zobrazení a plánování úprav v produktové mapě.
Funkce/vlastnosti zlepšující použitelnost
Pohodlné ovládání Intuitivní a jednoduché ovládání.
Jednoduchost Aplikace musí být snadno pochopitelná i pro osoby, které zatím žádný podobný software nepoužívaly.
Neočekávané funkce/vlastnosti
Použití zdarma Aplikaci lze používat zdarma bez omezení.
Modifikovatelnost Aplikaci lze upravovat či rozšiřovat díky tomu, že je šířena s otevřeným zdrojovým kódem.
3.2 Definice cílové uživatelské skupiny
Na základě poznatků nabytých provedením analýzy pomocí metody Jobs-to-be-Done byla definována primární uživatelská skupina aplikace. Trh již nabízí komplexní aplikace pro podporu produktového řízení. Naopak ale nenabízí jednoduchá řešení pro organizace, které dosud neměly zdroje či znalosti pro implementaci procesů produktového řízení, zároveň však potřebují získávat a zpracovávat zpětnou vazbu od uživatelů a nechtějí investovat prostředky do placených produktů. Trh nabízí mnoho aplikací, které se zaměřují zejména na produktové řízení digitálních produktů. Vzhledem k tomu, že je aplikace vyvíjena s otevřeným kódem, může být jednoduše upravena i pro další odvětví, pro něž zatím nejsou nástroje přizpůsobeny. Poznatky zpracované v kapitolách 2 a 3 byly využity pro definici funkčních požadavků aplikace, kterým se věnuje následující kapitola.
4 Funkční požadavky
V úvodu této kapitoly je představen způsob distribuce aplikace a popis záměru implementace minimální verze aplikace. Následně je definován seznam funkčních požadavků a pomocí metod prioritizace jsou vybrány funkční požadavky, které mají být implementovány v rámci minimální verze aplikace. Vybrané požadavky jsou blíže popsány včetně diagramů případů užití a je představen návrh grafického rozhraní aplikace.
4.1 Způsob distribuce aplikace
Autor se rozhodl vyvinout aplikaci s otevřeným zdrojovým kódem, aby mohlo být řešení volně využíváno, vylepšováno a přispělo k rozšíření principů produktového řízení. Aplikace může být používána či upravována v mezích stanovených licencí MIT. Zdrojový kód aplikace je součástí přílohy D.
4.2 Minimální verze aplikace
Cílem této práce byla implementace tzv. minimální verze produktu. Eric Ries ve své knize The Lean Startup definuje minimální verzi produktu (anglicky Minimum viable product) jako verzi, díky které lze získat maximum zpětné vazby za využití minima prostředků (Ries, 2011). Je to verze produktu, která s minimem prostředků umožňuje ověřit, zda bude produkt na trhu opravdu úspěšný (Productboard, 2019). Funkčnost aplikace byla po implementaci ověřena v produktovém týmu softwarové firmy StartupJobs.com s.r.o.
Testování je podrobněji zpracováno v kapitole 6. Zároveň byla aplikace nabídnuta veřejně k využití a dalšímu rozšiřování.
4.3 Prioritizace
Funkční požadavky aplikace byly definovány pomocí výsledků analýz popsaných v kapitole 2 a 3. Autor práce vybral pomocí dvou metod prioritizace funkcionalitu, která byla implementována v rámci minimální verze aplikace. První metodou vybranou pro prioritizaci je Value vs. Complexity Quadrant. Metoda je doporučována při prioritizaci funkcionality minimální verze aplikace (Productboard, 2020). U každé funkce je určena její hodnota pro uživatele a náročnost implementace na stupnici od 1 do 10. Následně je vytvořena matice. Na osu X je nanesena hodnota, na osu Y náročnost. Metoda rozděluje matici na čtyři kvadranty (viz Obrázek 2).
Obrázek 2: Value vs. Complexity Quadrant (zdroj: https://www.izenda.com/product-roadmap- prioritization-methods/)
Následující tabulka (Tabulka 8) vysvětluje jednotlivé kvadranty.
Tabulka 8: Popis kvadrantů metody Value vs. Complexity Quadrant (zdroj: autor)
Kvadrant Název Popis
Levý horní Quick Wins (dále Snadno
implementovatelná funkcionalita)
Implementačně nenáročná funkcionalita, která přináší vysokou hodnotu uživateli.
Pravý horní Potential Features (dále Potenciální funkcionalita)
Implementačně náročná funkcionalita, která přináší vysokou hodnotu uživateli.
Levý spodní
Time Sink Features
(dále Implementačně náročná funkcionalita)
Implementačně náročná funkcionalita, která nepřináší vysokou hodnotu uživateli.
Pravý spodní
Fill-Ins or Maybes
(dále Nedůležitá funkcionalita)
Implementačně nenáročná funkcionalita, která nepřináší vysokou hodnotu uživateli.
Snadno implementovatelná funkcionalita a Potenciální funkcionalita přinášejí největší hodnotu uživateli v poměru k vynaloženým nákladům, proto by dle metody měly být implementovány primárně. Naopak Implementačně náročná funkcionalita by měla být zavržena. Nedůležitá funkcionalita by měla být podrobena bližší analýze, protože není jasné, zda přinese dostatečně vysokou hodnotu, která se vyrovná implementačním nákladům.
Následující tabulka (Tabulka 9) ukazuje postup aplikování metody Value vs. Complexity Quadrant a její výsledek pro navrhovanou funkcionalitu aplikace. Navrhovaná funkcionalita je blíže popsána v Příloze A. V Tabulce 9 je zároveň zeleně vyznačena funkcionalita, která byla vybrána pro implementaci minimální verze aplikace. Autor vybral funkcionalitu spadající do kvadrantu Potenciální funkcionalita, žádná funkcionalita nespadala do kvadrantu Snadno implementovatelná funkcionalita.
Tabulka 9: Provedení metody Value vs. Complexity Quadrant (zdroj: autor)
Sekce aplikace Funkcionalita Hodnota Náročnost Uživatelský účet Přístup k uživatelskému účtu (přihlášení,
registrace) 10 6
Uživatelský účet Změna hesla 6 7
Uživatelský účet Zapomenuté heslo 6 7
Uživatelský účet Více přístupů k uživatelskému účtu 2 10
Zpětná vazba Přidat/zobrazit/upravit/smazat 10 7
Zpětná vazba Filtrování 7 7
Zpětná vazba Důležitost Zpětné vazby 8 9
Zpětná vazba Řazení dle kritérií 3 5
Zpětná vazba Štítky 4 6
Zpětná vazba Přidání obrázku 4 7
Vlastnost produktu Přidat/zobrazit/upravit/smazat 10 8
Vlastnost produktu Filtrování 7 9
Vlastnost produktu Produktová mapa 8 6
Vlastnost produktu Řazení dle kritérií 5 5
Vlastnost produktu Definice cílů 5 6
Vlastnost produktu Přidání obrázku 5 7
Vlastnost produktu Komentáře 3 4
Vlastnost produktu Přesunutí Vlastnosti produktu na Produktové
mapě pomocí drag&drop 5 10
Vlastnost produktu Stromová struktura 5 10
Vlastnost produktu Štítky 8 6
Portál Přidat/zobrazit/upravit/smazat 10 8
Portál Možnost prezentovat Vlastnosti produktu s
obrázky 8 9
Portál Vložení přes iframe 5 7
Portál Upravitelné sekce 4 8
Portál Přidání Zpětné vazby 10 6
Sekce vzdělávání Přidat/zobrazit/upravit/smazat 5 5
Ostatní Aplikace ve více jazycích 2 8
Následující obrázek (Obrázek 3) ukazuje funkce zasazené do matice na základě hodnoty a náročnosti implementace. Jak již bylo zmíněno výše, pro implementaci byla vybrána jen Potenciální funkcionalita (pravý horní kvadrant).
Obrázek 3: Výsledek provedené metody Value vs. Complexity Quadrant (zdroj: autor)
Pro zajištění objektivity byla provedena prioritizace také pomocí metody ICE, která se doporučuje ve chvíli zavádění nového produktu, kdy ještě není známa zpětná vazba od uživatelů (Productboard, 2020). Metoda ICE oproti předchozí metodě přidává jeden hodnotící parametr. Metoda hodnotí jednotlivé funkce navíc podle míry důvěry produktového manažera ve schopnost dané funkce naplnit stanovené hypotézy. Jinými slovy, jestli daná funkcionalita přinese uživatelům a organizaci hodnotu, která je od ní očekávána.
Výsledek zachycuje následující tabulka.
Tabulka 10: Provedení metody ICE (zdroj: autor)
Sekce
aplikace Funkcionalita Hodnota Náročnost Důvěra Skóre Vlastnost
produktu Přidat/zobrazit/upravit/smazat 10 8 10 9,33
Portál Přidat/zobrazit/upravit/smazat 10 8 10 9,33
Zpětná vazba Přidat/zobrazit/upravit/smazat 10 7 10 9,00 Uživatelský
účet
Přístup k uživatelskému účtu
(přihlášení, registrace) 10 6 10 8,67
Zpětná vazba Důležitost Zpětné vazby 8 9 9 8,67
Portál Přidání Zpětné vazby 10 6 10 8,67
Portál Možnost prezentovat Vlastnosti
produktu s obrázky 8 9 8 8,33
Sekce
aplikace Funkcionalita Hodnota Náročnost Důvěra Skóre Uživatelský
účet Změna hesla 6 7 10 7,67
Uživatelský
účet Zapomenuté heslo 6 7 10 7,67
Vlastnost
produktu Filtrování 7 9 7 7,67
Vlastnost
produktu Produktová mapa 8 6 7 7,00
Vlastnost
produktu Štítky 8 6 7 7,00
Zpětná vazba Filtrování 7 7 7 7,00
Vlastnost
produktu Stromová struktura 5 10 4 6,33
Vlastnost produktu
Přesunutí Vlastnosti produktu na Produktové mapě pomocí drag&drop
5 10 3 6,00
Vlastnost
produktu Přidání obrázku 5 7 4 5,33
Uživatelský účet
Více přístupů k uživatelskému
účtu 2 10 3 5,00
Portál Vložení přes iframe 5 7 3 5,00
Portál Upravitelné sekce 4 8 3 5,00
Vlastnost
produktu Řazení dle kritérií 5 5 4 4,67
Vlastnost
produktu Definice cílů 5 6 3 4,67
Ostatní Aplikace ve více jazycích 2 8 4 4,67
Zpětná vazba Štítky 4 6 3 4,33
Zpětná vazba Přidání obrázku 4 7 2 4,33
Sekce
vzdělávání Přidat/zobrazit/upravit/smazat 5 5 3 4,33
Zpětná vazba Řazení dle kritérií 3 5 2 3,33
Vlastnost
produktu Komentáře 3 4 3 3,33
Pomocí obou metod se podařilo vybrat stejnou funkcionalitu, která je popsána dále v této kapitole.
4.4 Výběr platformy
Autor práce se rozhodl implementovat webovou aplikaci, protože nejlépe splňuje stanovené požadavky: aplikace musí být snadno dostupná co největšímu počtu uživatelů, musí být možné jednoduše sdílet data mezi jednotlivými uživateli a implementace musí být co nejrychlejší. V případě vývoje mobilní či desktopové aplikace je nutné aplikaci přizpůsobovat rozdílným operačním systémům, což prodlužuje dobu implementace.
4.5 Popis jednotlivých funkcí aplikace
V této sekci jsou popsány jednotlivé funkční celky aplikace. Grafické rozhraní aplikace obsahuje texty v anglickém jazyce. Pro názvy jednotlivých funkcionalit v této práci jsou zvoleny české ekvivalenty, které dle autora ne vždy dobře vystihují význam dané funkcionality, proto jsou v následující tabulce (Tabulka 11) vysvětleny anglické pojmy a jejich české ekvivalenty.
Tabulka 11: České alternativy anglických názvů funkcionality aplikace (zdroj: autor)
Anglický název Český ekvivalent Popis
Feedback Zpětná vazba Zpětná vazba poskytnutá uživatelem daného produktu. V textu práce je používán pojem „zpětná vazba“ s malým i velkým počátečním písmenem.
Pokud autor používá malé počáteční písmeno, odkazuje se na obecný význam pojmu. Pokud je použito velké počáteční písmeno, jedná se o odkaz na funkcionalitu aplikace.
Feature Vlastnost produktu Funkcionalita nebo vlastnost produktu. Pojem je zpravidla používán zejména v souvislosti se softwarem, kdy daná funkcionalita/vlastnost umožňuje uživatelům vykonávat určitou činnost (Shewan, 2020).
Portal Portál Stránka na internetu, která umožňuje lidem najít užitečné informace na určité téma a směřuje uživatele na další webové stránky (Cambridge English Dictionary, 2017).
Roadmap Produktová mapa Strategický plán, který definuje cíl a požadovaný výsledek a popisuje jednotlivé kroky k dosažení cíle (ProductPlan, 2021).
Tag Štítek Štítek je textový řetězec, který může být přiřazen dané entitě. Například Vlastnost produktu může mít přiřazené Štítky, které ji blíže specifikují.
Pro přesnější popis funkcí aplikace byly vytvořeny diagramy případů užití, které zachycují chování systému z pohledu uživatele. Účelem diagramu je popsat funkcionalitu systému (Čápka, 2018). Následující diagram (Obrázek 4) zobrazuje případy užití aplikace.
Obrázek 4: Případy užití (zdroj: autor)
V této části kapitoly jsou představeny jednotlivé případy užití (viz Obrázek 4). Podrobný popis jednotlivých případů užití je součástí Přílohy B této práce.
4.5.1 UC1 Vytvoření uživatelského účtu
Základ aplikace tvoří uživatelský účet. Pro vytvoření uživatelského účtu je nutné zadat e- mailovou adresu, heslo a název firmy, pro kterou je uživatelský účet vytvářen.
4.5.2 UC2 Přihlášení do uživatelského účtu
Pro přihlášení do uživatelského účtu musí uživatel zadat e-mail a heslo.
4.5.3 UC3 Úprava uživatelského účtu
Uživatelský účet lze editovat. Konkrétně lze změnit e-mail a název firmy. Lze zadat pouze takový e-mail, který ještě není využíván jiným účtem. Funkcionalita je dostupná pouze po přihlášení do uživatelského účtu.
4.5.4 UC4 Změna hesla
Heslo uživatelského účtu lze změnit. Při změně hesla na nové je vyžadováno zadání současného hesla. Funkcionalita je dostupná pouze po přihlášení do uživatelského účtu.
4.5.5 UC5 Smazání uživatelského účtu
Uživatelský účet je možné smazat. Při smazání je vyžádáno zadání hesla k uživatelskému účtu. Funkcionalita je dostupná pouze po přihlášení do uživatelského účtu.
4.5.6 UC6 Obnovení hesla
V případě zapomenutí hesla lze heslo obnovit. Po zadání e-mailu spjatého s uživatelským účtem je na danou e-mailovou adresu odeslána zpráva, které obsahuje unikátní odkaz na stránku, na které lze nastavit nové heslo. Odkaz je platný po dobu jedné hodiny od požádání o obnovení hesla.
4.5.7 UC7 Správa Zpětné vazby
Aplikace umožňuje v rámci uživatelského účtu spravovat získanou zpětnou vazbu. Lze uložit samotné znění zpětné vazby a kontakt na osobu, která zpětnou vazbu poskytla. Zpětná vazba se může nacházet ve dvou stavech – nový nebo zpracovaný. Stav slouží k tomu, aby firma věděla, zda už zpětná vazba byla zpracována nebo ještě ne. Zpětnou vazbu lze fulltextově vyhledávat a lze také filtrovat na základě stavu. Zpětnou vazbu lze propojit s Vlastnostmi produktu, tato funkcionalita je popsána níže.
Modelová situace: Firma provozující aplikaci pro rozvoz potravin obdrží zpětnou vazbu od potenciálních zákazníků bydlících v Berouně, že kdyby k nim firma potraviny dovážela, budou jejich služby využívat. Firma si může uložit zpětnou vazbu v aplikaci.
Jednotlivé případy užití při správně Zpětné vazby zobrazuje Obrázek 5.
Obrázek 5: UC7 Správa Zpětné vazby (zdroj: autor)
4.5.8 UC8 Správa Vlastností produktu
V aplikaci lze v rámci uživatelského účtu spravovat plánované Vlastnosti produktu. Pro Vlastnost produktu lze uložit její název, popis a stav. Stav přibližuje situaci, ve které se Vlastnost produktu nachází v rámci procesu implementace. K jednotlivým vlastnostem lze také připojovat Štítky, pomocí kterých lze jednotlivé vlastnosti třídit do kategorií. Vlastnosti produktu lze zobrazit v seznamu či Produktové mapě. Mezi vlastnostmi lze fulltextově vyhledávat nebo filtrovat dle stavů a Štítků.
Modelová situace: Firma provozující aplikaci pro rozvoz potravin uvažuje nad rozšířením dosahu rozvozu o novou oblast. Do aplikace přidá novou Vlastnost produktu „Začít dovážet do oblasti Beroun”, přidá podrobnější popis a vlastnost označí Štítky „Nová dovozová oblast” a „Akvizice nových zákazníků”.
Vlastnosti produktu lze propojit s jednotlivými Zpětnými vazbami a určit důležitost dané vazby. Na základě těchto propojení se Vlastnosti produktu automaticky počítá prioritizační
skóre, které indikuje hodnotu dané vlastnosti pro zákazníky. Vlastnosti produktu může firma také sdílet na Portálu, tato funkcionalita je popsána níže.
Modelová situace: Firma provozující aplikaci pro rozvoz potravin má v aplikaci uloženou Vlastnost produktu, ve které plánuje rozšíření dovozu i o oblast Beroun. Firma může propojit Vlastnost produktu se Zpětnou vazbou od lidí, kteří by rádi z Berouna jejich služby využívali a u jednotlivých propojení uvést důležitost. Například zpětná vazba poskytnutá od potenciálního zákazníka, který říká, že by občas nakoupil, když je na chatě u Berouna, má nižší důležitost než od zákazníka, který píše, že by nakupoval každý týden. Na základě propojených Zpětných vazeb se vypočítá prioritizační skóre Vlastnosti produktu. Další výhodou je, že firma při plánování Vlastností produktu může prohlédnout všechny připojené Zpětné vazby.
Jednotlivé případy užití při správě Vlastností produktu zobrazuje Obrázek 6.
Obrázek 6: UC8 Správa Vlastností produktu (zdroj: autor)
4.5.9 UC9 Správa Štítků
Výše již byly zmíněny Štítky, které lze přiřazovat k jednotlivým Vlastnostem produktu. V rámci uživatelského účtu lze přidávat, upravovat a mazat Štítky. Jednotlivé případy užití zobrazuje Obrázek 7.
Obrázek 7: UC9 Správa Štítků (zdroj: autor)
4.5.10 UC10 Upravení Portálu
Portál umožňuje sdílet libovolné Vlastnosti produktu s uživateli. Vlastnost produktu je na Portálu prezentována jménem, popisem a připojeným obrázkem. Firma na Portálu zařadí Vlastnost produktu do jedné ze tří kategorií: nápady, v procesu nebo hotové. Firma tak může s uživateli sdílet nápady, chystané úpravy i již provedené produktové změny. Případy užití UC8-3 a UC8-4 spojené s prezentováním Vlastnosti produktu na Portále jsou zobrazeny výše na Obrázku 6. Firma může Portál zobrazit, případně skrýt a upravovat jeho jméno.
Dále budou rozebrány případy užití pro přidání Zpětné vazby přes Portál.
4.5.11 UC11 Přidání Zpětné vazby přes Portál
Portál je dostupný bez přihlášení do uživatelského účtu a uživatelé si mohou na Portálu prohlížet firmou prezentované Vlastnosti produktu. Uživatelé mohou přes Portál přidat zpětnou vazbu k jednotlivým Vlastnostem produktu. Firmě se automaticky tato zpětná vazba uloží do systému a propojí se s danou Vlastností produktu. Uživatelé mohou přes Portál poslat i zpětnou vazbu, která se nevztahuje k žádné konkrétní Vlastnosti produktu.
Modelová situace: Firma provozující aplikaci pro rozvoz potravin prezentuje na Portálu Vlastnosti produktu, které zvažuje implementovat. Jednou ze zvažovaných úprav je i začátek rozvážení potravin v Berouně. Potenciální zákazník z Berouna přijde na Portál a může firmě zanechat zpětnou vazbu, že by ocenil, kdyby do Berouna dováželi potraviny. Pravidelný zákazník z Prahy přijde na Portál, prohlíží si chystané úpravy a napadne ho, že by ocenil, kdyby mohl objednávku rozšířit o pár položek i poté, co už objednávku odešle. Na Portálu může zákazník firmě poslat svou zpětnou vazbu, i když firma zatím danou Vlastnost produkt
sama na Portálu neukazuje. Díky Zpětné vazbě v aplikaci firma vidí, jak uživatelé na chystané Vlastnosti produktu reagují, a získává cenné informace ještě předtím, než vlastnosti implementuje.
Jednotlivé případy užití při přidávání zpětné vazby přes Portál zobrazuje Obrázek 8.
Obrázek 8: UC11 Přidání Zpětné vazby přes Portál (zdroj: autor)
4.5.12 UC12 Odhlášení z uživatelského účtu Přihlášený uživatel se může odhlásit.
4.6 Návrh uživatelského rozhraní aplikace
Na základě funkčních požadavků byly navrženy skici webu (v angličtině se používá pojem wireframe), které zobrazují návrh jednotlivých stránek aplikace při zobrazení na počítači a mobilním telefonu. Skici slouží k návrhu rozmístění funkčních a obsahových prvků jednotlivých stránek. V této bakalářské práci byly skici použity jako podklad pro implementaci aplikace. Skici byly vytvořeny pomocí nástroje Balsamiq18 a tvoří Přílohu C této práce.
4.7 Databázový návrh
Aplikace vyžaduje úložiště dat, kde mohou být uchovávány informace, které uživatelé zadávají v aplikaci. Způsob implementace uložiště je blíže popsán v kapitole 5. V této podkapitole jsou popsány entity reprezentující jednotlivé funkcionality na úrovni databáze.
Popis entit (Tabulka 12) je součástí návrhu aplikace a byl využit při její implementaci.
18 https://balsamiq.com/
Tabulka 12: Popis entit (zdroj: autor)
Entita Co entita reprezentuje
Company Uživatelský účet, který uchovává přihlašovací údaje a informace o firmě.
Portal Portál, na kterém může firma sdílet s uživateli zvažované a chystané produktové úpravy a získávat od uživatelů zpětnou vazbu.
Feedback Zpětná vazba ukládaná v aplikaci.
Feature Vlastnosti produktu ukládané v aplikaci.
FeatureTag Štítky, které mohou být přiřazeny k Vlastnosti produktu.
Implementační poznámka:
Mezi entitou Feature a FeatureTag je relační vztah M:N. Na úrovni relační databáze je vygenerována samostatná databázová tabulka, kde jsou uloženy relace mezi entitou Feature a FeatureTag.
FeatureState Jednotlivé stavy Vlastnosti produktu.
PortalFeature Reprezentuje Vlastnost produktu na Portále.
PortalFeatureState Jednotlivé stavy, ve kterých se mohou Vlastnosti produktu na Portále nacházet.
File Informace o souborech, které byly uživateli nahrány na server. Uživatelé mohou nahrávat obrázky pro prezentaci Vlastností produktu na Portálu.
Insight Propojení Zpětné vazby a Vlastnosti produktu a důležitost tohoto propojení.
Implementační poznámka:
Na úrovni relační databáze se jedná o M:N vztah mezi entitou Feedback a Feature. Entita Insight kromě této relace obsahuje ještě atribut určující důležitost propojení (v podobě relace 1:N s entitou InsightWeight), proto se musí i na úrovni PHP jednat o samostatnou entitu.
InsightWeight Stupně důležitosti propojení Zpětné vazby a Vlastnosti produktu.
Součástí návrhu aplikace je i fyzický databázový model pro databázový systém MySQL19 (Obrázek 9). Model popisuje atributy entit a relace mezi jednotlivými entitami. Systém MySQL byl použit ve vývojovém i produkčním prostředí. Blíže se autor tématu databází věnuje v kapitole 5.
19 https://www.mysql.com/
Obrázek 9: Fyzický model databáze (zdroj: autor)
5 Implementace aplikace
Kapitola 5 se věnuje technologiím použitým při vývoji minimální verze aplikace. Je představena architektura aplikace a dále jsou popsány jednotlivé komponenty PHP frameworku Symfony a jejich využití při implementaci aplikace. Jsou nastíněny funkce Symfony frameworku, které nebyly dosud použity, ale s jejich implementací se počítá při budoucím rozvoji aplikace. Na závěr kapitoly je zhodnocen vývoj aplikace a naplnění cíle bakalářské práce.
5.1 Použité technologie
Vývoj webové aplikace se neobejde bez využití jazyků HTML a CSS, které slouží pro tvorbu webových stránek a pro definování jejich vzhledu. Dále autor využil knihovnu jQuery20 pro jazyk JavaScript a knihovnu Bootstrap21, jejíž využití je podrobněji rozvedeno níže. Hlavní technologií použitou pro tvorbu aplikace je skriptovací jazyk PHP. Autor se rozhodl implementovat aplikaci ve skriptovacím jazyce PHP s využitím frameworku. Framework přináší řadu výhod, jako hlavní výhody autor vnímá rychlejší a efektivnější vývoj, lepší zabezpečení a výkonnost výsledné aplikace. Byl zvolen jeden z nejpopulárnějších PHP frameworků současnosti – Symfony. Autor vybral tuto technologii, protože s ní má největší zkušenosti a má jistotu, že nabízí veškerou potřebnou funkcionalitu pro vývoj navržené aplikace. Podrobněji je využití frameworku popsáno níže.
5.2 Vývojové prostředí
Aplikace byla vyvíjena v lokálním prostředí s využitím Symfony Local Web Server. Server je přizpůsoben pro použití při vývoji PHP aplikací a je alternativou k webovým serverům jako je Apache22 či nginx23. Symfony Local Web Server lze využít pouze při vývoji aplikací, nelze s ním pracovat v produkčním prostředí. Jako úložiště dat sloužil databázový systém MySQL.
20 https://jquery.com/
21 https://getbootstrap.com/
22 https://httpd.apache.org/
23 https://www.nginx.com/
Pro ukládání a správu zdrojového kódu byl využit verzovací systém Git. Webový Git repozitář byl umístěn na serveru Gitlab24.
V úvodu kapitoly byly představeny použité technologie i podoba vývojového prostředí. V následující části kapitoly bude blíže představena implementace aplikace.
5.3 Architektura aplikace
Webové aplikace implementované pomocí Symfony frameworku využívají tzv. Model-View- Controller vzor, zkráceně MVC vzor (dále jen MVC). Cílem MVC je zabránit míchání kódu zodpovědného za logiku aplikace s kódem zodpovědným za grafické rozhraní aplikace.
Logika aplikace je psaná v jazyce PHP, kdežto grafické rozhraní webové aplikace tvoří zejména značkovací jazyk HTML. Kód kombinující oba jazyky dohromady je nepřehledný a těžko upravitelný (Čápka, 2016). MVC zajišťuje úplné oddělení těchto dvou vrstev.
Výsledkem je přehledný a snadno upravitelný kód. Při vývoji aplikace podle MVC je zdrojový kód aplikace rozdělen do tří částí: controller neboli řadič (dále jen řadič), model a view neboli pohled (dále jen pohled). Model reprezentuje data a akce s daty, které aplikace vykonává. Pohled zajišťuje interakci s uživateli a vykresluje data z modelu. Řadič reaguje na akce provedené uživatelem a podle potřeby vyvolává změny v pohledu či modelu (Symfony, 2005).
5.4 Způsob vykreslování stránek aplikace
Existují dva způsoby vykreslování (neboli rendering) webových stránek. Při využití tzv.
server-side-rendering (dále jen vykreslování na serveru) je HTML stránka včetně dat kompletně sestavena skriptem či programem na serveru. Následně je HTML stránka odeslána do webového prohlížeče neboli klienta, který ji zobrazí. Druhým způsobem je tzv.
client-side rendering (dále jen vykreslování na straně klienta), při kterém je programem či skriptem odeslána ze serveru do prohlížeče HTML stránka bez dat a data jsou ze serveru získána asynchronně pomocí jazyku Javascript, který je následně vykreslí (CSS tricks, 2021).
Při vývoji aplikace byl využit jazyk PHP a framework Symfony. Tyto technologie umožňují rychlou a efektivní implementaci vykreslování na serveru. Vykreslování na straně klienta vyžaduje navíc komplexní použití jazyka Javascript. Cílem minimální verze aplikace bylo získat co nejrychleji zpětnou vazbu od uživatelů s využitím minima prostředků. Autor se proto rozhodl pro vykreslování na serveru, jelikož nebylo třeba osvojení a použití další
24 https://gitlab.com/
technologie. Nicméně při dalším rozvoji projektu je dle autora žádoucí vykreslovat stránky na straně klienta, důvody tohoto rozhodnutí jsou rozebrány v kapitole 7.
5.5 Struktura zdrojového kódu aplikace
Při implementaci aplikace byla dodržena Symfony frameworkem doporučená struktura zdrojového kódu. Struktura je zobrazena na následujícím obrázku (Obrázek 8).
Obrázek 8: Struktura zdrojového kódu aplikace (zdroj: autor)
V tabulce (Tabulka 13) jsou popsány jednotlivé části struktury zdrojového kódu aplikace. Některým částem se autor věnuje podrobně níže v této kapitole.
Tabulka 13: Popis struktury zdrojového kódu aplikace (zdroj: autor)
Složka projektu Obsah složky
app/bin Tzv. console skript umožňující spouštění console příkazů (Symfony, 2019).
app/config Konfigurační soubory aplikace využívající formátu YAML.25
app/migrations Databázové migrace, které autor podrobněji rozebírá níže v této kapitole.
app/public Složka slouží jako tzv. web root. To znamená, že se zde nacházejí soubory volně přístupné z webu:
• index.php,
• Javascript soubory,
• CSS soubory,
• obrázky,
• soubory nahrané uživateli.
Soubor index.php plní úlohu nesoucí název Front-controller. Jedná se o návrhový vzor, ve kterém všechny HTTP požadavky zpracovává jeden řadič a následně je deleguje dále (Symfony, 2019).
app/src PHP zdrojový kód aplikační logiky, který autor podrobněji rozebírá níže v této kapitole.
app/templates HTML šablony, kterým se autor podrobněji věnuje níže v této kapitole.
app/tests Unit a funkční testy, kterým se podrobněji věnuje kapitola 7.
app/translations Překlady textových řetězců.
app/var Soubory mezipaměti a žurnály.
app/vendor Zdrojový kód aplikací třetích stran, které projekt využívá. Závislosti jsou spravovány pomocí nástroje Composer26.
5.6 Popis implementace
V této sekci kapitoly jsou podrobněji představeny komponenty a koncepty Symfony frameworku a dalších technologií, které autor použil a aplikoval při vývoji aplikace.
25 https://yaml.org/
26 https://getcomposer.org/
5.6.1 Řadiče
Jak již bylo zmíněno v úvodu kapitoly, řadiče reagují na akce provedené uživatelem a podle potřeby vyvolávají změny v pohledu či modelu. V aplikaci je využit přístup, kdy je pro každou entitu tvořící funkční celek aplikace implementován samostatný řadič (v podobě PHP třídy).
Entity autor rozebírání níže v kapitole. Úkolem řadiče je reagovat na akce provedené uživatelem. Akce jsou webovým prohlížečem na server posílány v podobě HTTP dotazu.
Server posílá zpět odpověď například v podobě souboru ve formátu HTML, JSON či XML nebo v podobě přesměrování na jinou webovou stránku. Jednotlivé metody třídy řadiče reagují na různé akce provedené uživatelem.
Při implementaci řadičů byly využity funkce Symfony frameworku, které usnadňují a zrychlují implementaci. Autor se jimi zabývá na následujících řádcích kapitoly. První z využitých komponent nese název Router a umožňuje nastavení tzv. směrování (v angličtině se využívá pojem Routing). Mechanismus směrování umožňuje definovat, jaká část kódu má zpracovat HTTP dotaz. Jak již bylo řečeno, zpracování HTTP dotazu je úkolem řadiče. Komponenta Router tedy umožňuje definovat, jaká metoda řadiče se má pro daný HTTP dotaz vykonat. Jako příklad je uvedena ukázka kódu aplikace (Výpis 1), kdy je po zadání URL adresy https://domena-projektu.xx/ vrácena HTML stránka.
Výpis 1: Ukázka řadiče (zdroj: autor)
/**
* @Route("/", name="fo_home")
*/
public function index(): Response {
return $this->render('front_office/home.html.twig');
}
Díky komponentě Router je možné vytvářet URL adresy se sémantickými názvy, které uživatelům naznačují funkcionalitu dané stránky. Zároveň jsou sémantické URL adresy důležité pro optimalizaci stránek pro vyhledávače (SEO).
V souvislosti se směrováním je uvedena další funkcionalita, která je v řadičích aplikace využita. Nese název ParamConverter anotace (dále jen Konvertor). Úkolem Konvertoru je převod parametrů HTTP dotazu na objekty PHP tříd. Parametry lze převádět na instance entit nebo na instance třídy DateTime (Symfony, 2019). Autor uvádí příklad kódu, který zpracovává navštívení stránky https://domena-projektu.xx/apple/settings/info. Konvertor se pokouší v databázi najít záznam, který odpovídá instanci entity Company. Atribut s názvem slug dané instance musí odpovídat textovému řetězci „apple“. Pokud není záznam nalezen, vrátí řadič HTTP stavový kód 404. Použití Konvertoru ukazuje Výpis 2.
Výpis 2: Ukázka použití Konvertoru (zdroj: autor) /**
* @Route("/admin/{slug}/settings/info", name="bo_settings_info")
