\chapter{Design aplikace}
\section{Základní řízení procesu vývoje softwaru}\label{section:SDLC}
Řízení procesu vývoje softwaru se na první pohled může zdát jako velice jednoduchá záležitost. Dostaneme specifika programu od zákazníka, vytvoříme plán a začneme tvořit. Jako spousta věcí v životě ale ani toto není tak jednoduché. Zákazník bohužel nemůže přijít do obchodu a koupit si program, který má ty nejlepší parametry. Vůbec definovat kvalitu programu je velice obtížné. Měly by se parametry zaměřovat na počet řádků kódu, nebo na rychlost programu? Nejspíš ne. Více řádků kódu nemusí znamenat neefektivitu, může to být naopak známka promyšleného designu, který se v celém programu používá jednotně. Chybovost tak bude menší a bude jednodušší rozšiřovat kompatibilitu a funkčnost celého programu. Naopak i ta nejrychlejší aplikace nemusí byt dostatečně rychlá pro obsluhu milionu zákazníků současně. Není tedy jasné, jak specifikovat a monitorovat kvalitu softwarového vývoje.

Protože vývoj zahrnuje spoustu různých aktivit od tradiční programátorské práce, která tvoří základ každého vývoje, přes design uživatelského rozhraní, které umožní zákazníkům se jednoduše orientovat v digitálním světě, až po marketingový tým, jenž nejen vytváří propagační kampaň pro vyvíjený produkt, ale dostává i zpětnou vazbu jak od budoucích uživatelů, tak od zákazníků, kteří si daný produkt objednali. Proto je je velmi náročné sladit tyto týmy tak, aby vše proběhlo bez komplikací a aby nikdo na nikoho nečekal. V opačném případě vznikají zpoždění a kvalita celého projektu klesá.

Pro vývoj softwaru tedy musíme použít jiné inženýrské postupy než u tradičnějších způsobů výroby. Jinak bychom nevyužili všechny výhody vycházející z toho, že software je taková nehmatatelná substance, jež pohání náš svět. \cite{kacvinsky2012agilni} 

Výběr vhodného procesu pro vývoj BillSaveru nám zajistí jednoduchý a kvalitní vývoj. Více o tom jaký řídící proces jsme vybrali a proč si probereme v kapitole \ref{subsection:Hamronogrma} a \ref{section:TechnickeAspekty}. Zde si vytvoříme pouze informovaný základ.

Celý vývoj by se dal rozdělit do několika etap: plánování, analýza, návrh, implementace a údržba. Tomuto rozdělení se říká SDLC (system development life cycle). V této studii se zaměříme na plánování, analýzu a převážně návrh.

\begin{itemize}
\item V plánovací fázi se zaměřujeme nejvíce na studii proveditelnosti. Vytvoříme a zkonsolidujeme vývojový tým. Vytvoříme strategii vývoje a vymezíme si vztyčné cíle. Identifikujeme možné budoucí problémy, vybereme vhodné technologie a ohraničíme podnikatelský rozsah celého projektu.

\item V analýze bychom měli klasifikovat problémy, které se mohou vyskytnout při implementaci, a navrhnout jejich řešení. Vytvoříme rešerši podobných projektů a s týmem se dohodneme na tom, jaká implementace nejlépe odpovídá našemu případu použití. Zanalyzujeme systém s pomocí již vytvořené rešerše a nakonec poukážeme na nezbytné části a potřeby systému, které budeme podrobně navrhovat v další části.

\item Při návrhu musíme zanalyzovat data, která se budou uchovávat, a k nim  vytvořit vhodný databázový model. Dále je třeba analyzovat interakci jednotlivých objektů mezi sebou, vytvořit jejich výhodná rozhraní a nakonec navrhnout uživatelské rozhraní.

\item Implementovat se bude již vyhotovená analýza, což znamená vytvoření databázového schématu podle databázového modelu a vytvoření aplikace z vyhotoveného návrhu. Po dokončení implementace se otestuje všechna funkcionalita a nakonec se opraví objevené chyby.

\item Závěrečným krokem je údržba vytvořeného systému. Tato práce je prováděna administrátorem systému, jenž se stará o monitorování a údržbu celého systému. \cite{ComperativeAnalysisOfSDLC}
\end{itemize}


SDLC je však pouze teoretický základ pravidel, a proto vzniklo několik hlavních implementací. Tyto postupy se dělí na vodopádový model, metodologii ve tvaru V a agilní model. \cite{balaji2012waterfall} \cite{ComperativeAnalysisOfSDLC}  Každá z těchto implementací má své výhody a nevýhody, jež si nyní porovnáme:

\subsection{Waterfall}
Waterfall model neboli vodopádový model je specifická implementace SDLC, která byla prvně popsaná v roce 1970 hlavním vedoucím Lockhed Software Technology Center Dr. Winstonem W. Roycem. \cite{rerych2007wasserfallmodell} Je to tedy jedna z nejstarších implementací SDLC.

\begin{figure}[h]
    \centering 
    \includegraphics[width=10cm]{images/Waterfall_model.png}
    \caption{Waterfall model \cite{waterfallModel}} 
    \label{fig:waterfallModel}
\end{figure}

Jedná se o sekvenční model, kde každá sekce musí být kompletně hotová, aby se mohlo pokračovat dál. Dokumentace a testování se píše vždy na konci každé sekce. Potom se sekce uzavře a už se nesmí měnit. Požadavky by měly být specifikovány jasně a zřetelně již na začátku každé sekce, jinak by vznikal chaos v organizaci projektu.

Hlavní výhody tohoto modelu jsou jeho zřetelné požadavky na začátku každé sekce. Protože se jedná o lineární model, je celý proces velice jednoduchý na pochopení a implementaci. Udržení kvality dokumentace je také velice jednoduché při držení se daného modelu.

Hlavní nevýhody vyplývají z jeho výhod. Kvůli jeho linearitě mohou vznikat prostoje, které prodlužují vývojový čas a tím zapříčiňují zvyšující se  finanční náročnost celého projektu. Dále je také u většiny projektů problém zjistit všechny informace již na začátku sekce, kvůli tomu se mohou nedostatky nabalovat v dalších fázích projektu. Bez možnosti upravování předchozích fází se z promyšleného projektu může velice rychle stát projekt, kterému nikdo nerozumí. \cite{balaji2012waterfall}

\subsection{V-model}
V model neboli Validation \& Verification model je specifikace, která navazuje na vodopádový model a doplňuje ho. Místo testování, které probíhá pouze v jednom bloku, se testy připravují postupně již od začátku vývoje. Testeři jsou tak zapojeni do celého projektu již od začátku.

\begin{figure}[h]
    \centering 
    \includegraphics[width=10cm]{images/V-model.png}
    \caption{V-model \cite{V-Model} }
    \label{fig:vModel}
\end{figure}

Výhody jsou podobné jako u vodopádového modelu, tzn. jednoduchá implementace, přesně definované pořadí kroků a relativně přímočará dokumentace projektu. Protože jsou však testy vytvářeny již na začátku, je šance na úspěch celého projektu daleko vyšší.

Nevýhody stejně jako u předchozího modelu představují jeho in-flexibilita k případným změnám, vysoká šance prodlevy, vyšší finanční náročnost a nutnost mít veškeré informace již na začátku projektu. I když jsou však testy vytvářeny již od začátku, nedávají jasné postupy řešení případných chyb. \cite{balaji2012waterfall} \cite{ComperativeAnalysisOfSDLC}

\subsection{Agilní model} \label{subsection:AgilniVyvoj}
Agilní přístup je nový způsob vývoje, který se snaží nahradit in-flexibilitu lineárních přístupů, vytvářet malé propojené týmy, zvýšit spolupráci, dávat důraz na jednotlivce místo institucionalizovaných procesů a zvýšit týmového ducha. Agilní přístup se řídí několika zásadami, které jsou napsané v agilním manifestu:

\begin{itemize}
\item Jednotlivci a interakce před procesy a nástroji

\item Fungující software před vyčerpávající dokumentací

\item Spolupráce se zákazníkem před vyjednáváním o smlouvě

\item Reagování na změny před dodržováním plánu

\item Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více. \cite{beck2001agile}
\end{itemize}        



Dále také obsahuje principy, jimiž by se měl každý agilní tým řídit:

\begin{itemize}

\item Naší nejvyšší prioritou je vyhovět zákazníkovi časnýma průběžným dodáváním hodnotného softwaru.

\item Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka.

\item Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody.

\item Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu.

\item Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme jim, že odvedou dobrou práci.

\item Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace.

\item Hlavním měřítkem pokroku je fungující software.

\item Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale.

\item Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu.

\item Jednoduchost -- umění maximalizovat množství nevykonané práce -- je klíčová.

\item Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.

\item Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti. \cite{beck2001agile}
\end{itemize}       



Z tohoto přístupu vzešlo několik hlavních vývojových postupů, z nichž nejznámější a nejpoužívanější je SCRUM, který zahrnuje
3 základní fáze: předehru, hru a post hru. 

\begin{figure}[h]
    \centering 
    \includegraphics[width=10cm]{images/SCRUM_process_detailed.png}
    \caption{SCRUM model \cite{abrahamsson2017agile} }
    \label{fig:scrumModel}
\end{figure}

V předehře se sepíší všechny požadavky, které jsou prozatím známy. Odhadne se jejich pracnost a přidají se do takzvaného backlogu, který se nakonec seřadí podle priority. Požadavky mohou přicházet od zákazníka, programátora, testera či jiných osob zapojených do vývoje. Do backlogu se mohou konstantně přidávat další požadavky, mohou se ale upravovat a zpřesňovat již vytvořené požadavky. V předehře se také vytvoří architektura programu v závislosti na stávajícím backlogu. V případě nutné změny se identifikují dopady a případné problémy na celý projekt. Tyto změny se pak prodiskutují a z výsledků této diskuze se zavedou případné změny. \cite{abrahamsson2017agile}

Hra se skládá z takzvaných sprintů, což jsou cykly trvající v rozmezí od jednoho do čtyř týdnů a opakující se přes celý vývojový proces. Každý sprint se skládá ze standardních SDLC fází. Existují však důležité milníky ve sprintu, a sice:

\begin{itemize}
    \item Sprint planning, ve kterém se vyberou úkoly pro celý sprint a rozhodí se mezi programátory.
    
    \item Stand-UP, který se opakuje v pravidelných intervalech 1-3 dny, ve kterém všichni členové vývojového týmu řeknou, na čem zrovna pracují a jestli nepotřebují nějak pomoct.
    
    \item Na konci sprintu proběhne retrospektiva, kdy celý tým zanalyzuje a zhodnotí daný sprint a nakonec navrhne případné změny pro další sprint.
\end{itemize}
\cite{abrahamsson2017agile}

Poslední fáze SCRUMu je post hra. Do této fáze se celý tým dostane až tehdy, když nebyly identifikovány žádné další úkoly a celý backlog je prázdný. Celý systém je tak připraven na systémové testování, integraci a vytvoření dokumentace.

Výhody tohoto postupu jsou: krátká doba pro vytvoření výsledku; přímá komunikace mezi zákazníkem a vývojářským týmem; flexibilita pro případné změny v zadání; kontinuální zpětná vazba od zákazníka, která umožňuje zdokonalit celý projekt. Odhad pracnosti je vcelku přesný kvůli krátkému časovému úseku. Díky všem těmto výhodám má celý projekt větší šanci na úspěch. \cite{mahalakshmi2013traditional}

Hlavní nevýhody tohoto procesu jsou: komplikovaná struktura; nutnost týmové spolupráce, bez které se úspěch projektu neobejde; velká pravděpodobnost nedostačující dokumentace; integrační testy probíhají až na konci, kvůli tomu může dojít k nečekaným problémům. Ale především se tým může zaměřit na jeden aspekt programu a tím nemusí zbýt čas na jiné části projektu. \cite{abrahamsson2017agile}