Projekt

Obecné

Profil

Vize » Historie » Verze 16

Václav Hrabík, 2023-03-15 15:52

1 4 Petr Urban
h1. Popis a cíle frameworku SPADe
2 1 Petr Urban
3 4 Petr Urban
h2. Popis stávajícího SPADe frameworku
4 1 Petr Urban
5 4 Petr Urban
Během projektu vývoje softwaru se projektový manažer snaží vyhnout špatným praktikám a anti-vzorům, aby tak předešel případnému snížení pravděpodobnosti úspěšného dokončení projektu. Některé špatné praktiky však
6
na první pohled nemusí být zřejmé a k jejich odhalení může dojít až v případě, kdy už významně negativně ovlivnily průběh projektu. Tento problém
7
by mohla řešit automatická detekce špatných praktik a anti-vzorů už v jejich počáteční fázi. Díky tomu by měl projektový manažer prostor adekvátně
8
zareagovat. (Petr Štěpánek, 2022)
9 1 Petr Urban
10 4 Petr Urban
V současné době neexistuje komerční nástroj, který by v projektových
11
datech prováděl automatickou detekci špatných praktik nebo anti-vzorů nezávisle na použitém ALM nástroji. Tento problém je předmětem projektu
12
Katedry informatiky a výpočetní techniky (KIV) Fakulty aplikovaných věd
13
(FAV) Západočeské univerzity v Plzni (ZČU), kde je vyvíjen framework
14
Software Anti-pattern Detector (SPADe).
15
Hlavní funkčností frameworku SPADe je těžba dat ze softwarových projektů uložených v různých ALM nástrojích a jejich transformace do unifikované struktury v datovém skladu. Nad naplněným datovým skladem je
16
následně umožněno provádět datové analýzy zjišťující přítomnost událostí,
17
vzorců chování, konceptů a metod. Zvláštní pozornost je věnována zejména
18
přítomnosti špatných praktik a anti-vzorů.
19 1 Petr Urban
20 4 Petr Urban
h2. Cíle
21 1 Petr Urban
22 4 Petr Urban
!clipboard-202303071647-yhpvy.png!
23
[obr. 1]
24
25
Cílem je rozšířit framework SPADe, konkrétně: detektor, webové rozhraní a databázi, o několik dalších aplikací, přičemž každá by měla na starost konkrétní věc. Konkrétně detektor a webová aplikace jsou v současné době spojeni do jedné aplikace (monolit), který vznikl v rychlosti pod vedením Ondřeje V. My tento monolit chceme rozdělit do MVC architektury, tzn. využít Java Spring Boot jako RestAPI a ReactJS na vývoj samotné webové aplikace, která by s Javou komunikovali pomocí RestAPI.
26
27 6 Petr Urban
Nadále aplikace nemá žádnou autentizaci. Cílem je připravit takovou (nejspíše) službu, která bude mít abstraktní rozhraní (mj. bridge), který by sloužil jako připojení pro jiné autentizační služby. Zatím by autentizační služba byla vcelku primitivní a fungovala by s daným rozhraním. Komplexnější framework typu Keycloak, google OAuth apod. by se řešilo na úrovni diplomové práci mimo ASWI/TSP.+.
28 4 Petr Urban
29
Při migraci detektoru pouze na RestAPI je cílem i zavést tkz. kontraktové testy. Jsou to jednotkové testy využívající několik knihoven přímo od springu, které vytvářejí stuby z daných předpisů (swagger) a poté se spouštějí s cílem otestovat, zda neproběhla žádná změna v žádném z kontrolerů, která by ovlivnila výstup endpointu(ů).
30
31
32 16 Václav Hrabík
V průběhu implementace by byla vize i taková, že bychom zkusili změnit databázi z MySQL na MS SQL Server, a to kvůli mnoha výhodám, které má oproti MySQL. Nicméně je nutné vůbec zjistit, zda s touto DB bude jednoduchý nasazení potom v CI/CD apod.
33 1 Petr Urban
34 16 Václav Hrabík
35
h1. Specifikace požadavků
36
37
# Změna současné architektury na MVC
38
# Přidání správy uživatelů 
39
# Zavedení kotraktového testování
40
# Přidání možnosti jednoduchého nasazení produktu
41
# Kompletní a ucelená dokumentace produktu
42
43 4 Petr Urban
h1. Hrubý plán projektu
44
45 7 Petr Urban
46 11 Petr Urban
h2. Iterace
47 7 Petr Urban
48
*Iterace vycházejí z pravidel definovaných v [[Interní_konvence]]*
49
50 8 Petr Urban
> h3. 1. iterace:
51 1 Petr Urban
>> * Schůzka se zadavatelem a mentorem, dosazení LCO milníku, příprava nástrojů pro vedení projektu, domlouvání technologií, rozdělení prací a diskuze nad interními konvencemi při vedení projektu, *rozchození současného projektu* a sepisování veškerých návodů do wiki.
52 16 Václav Hrabík
>> * Začátek: 13. 02. 2023
53
>> * Konec:   27. 02. 2023
54 7 Petr Urban
55 8 Petr Urban
> h3. 2. iterace:
56 10 Petr Urban
>> * Upravit strukturu projektu na moduly. Každý modul bude představovat pod-aplikaci. 
57
>> * Vytvořit /v2/ strukturu aplikace tak, abychom mohli začít připravovat RestAPI pro front end aplikaci a došlo i k zachování původní funkcionality. Zároveň vytvořit strukturu aplikace, která se bude využívat poté dále provoláváním například z ReactJS aplikace (mít připravené alespoň nějaké základní endpointy)
58
>> * Připravit materiály (a důkladně je dokumentovat) na studium ReactJS aplikace. Pokusit se vytvořit pseudoprojekt, který by uměl komunikovat s připravenými endpointy. Alespoň je provolávat a získávat z toho pseudo-data
59
>> * Začít připravovat technickou dokumentaci. Nejlépe v AEP6 formátu.
60
>> * Ladit dokumenty, wiki, interní dokumenty a obecně všechny věci týkající se vedení projektu.
61
>> * Upravovat technické návrhy, vymýšlení návrhů na možné změny infrastruktury a architektury.
62 14 Petr Urban
>> * Dokončení vizí obecně (to znamená mít hotový seznam rizik, stakeholders apod.)
63 7 Petr Urban
64 8 Petr Urban
> h3. 3. iterace:
65 10 Petr Urban
>> * mít rozběhané všechny potřebné technologie, připravené prostředí a začít na vývoji.
66
>> * z technických návrhů začít připravovat službu na autentizaci. Připravit rozhraní (nejlépe bridge), alespoň template. Připravit DB strukturu pro uživatele, nejlépe i pro aktuální konfigurační .json soubory. 
67
>> * dosažení milníku LCA
68
>> * připravit kontraktové testy, strukturu na ně, a naučit se technologii spring-cloud-contracts. To znamená: začít dokumentovat endpointy do swagger.yaml souboru (předpis pro služby) a připravit všechny potřebné struktury k tomu, aby byly testy (alespoň jejich základní kostry) spustitelné.
69
>> * lazení technické dokumentace
70 7 Petr Urban
71 8 Petr Urban
> h3. 4. iterace:
72 10 Petr Urban
>> * lazení technické dokumentace
73
>> * refaktor původního kódu, odstraňování přebytečných věcí a snaha dostat logické věci do databáze místo z konfiguračních souborů.
74
>> * dotažení kontraktových testů
75 7 Petr Urban
>>> * Mít dodělané potřebné endpointy v controlleru, které se budou využívat ve webové aplikaci.
76 10 Petr Urban
>> * Rozmýšlení nad CI/CD, případně studium technologií
77 7 Petr Urban
78 8 Petr Urban
> h3. 5. iterace:
79 7 Petr Urban
>> * dotažení webového rozhraní
80 9 Petr Urban
>>> * Hotová stránka about, doplnit o metadata, povýšit verzi aplikace, hotová stránka main page a případně i další dle zvážení.
81 10 Petr Urban
>> * Funkční (spustitelné) kontraktové testy, které budou procházet. Obecně vytváření jednotkových testů na nový vývoj a klikací testy na webové rozhraní.
82
83
> h3. 6. iterace:
84 9 Petr Urban
>> * uživatelská příručka, 
85 15 Václav Hrabík
>> * funkční release,
86
>> * technická dokumentace alespoň z části hotová
87 1 Petr Urban
>> * dokončení administrativních záležitostí
88
>> * předání zákazníkovi.
89
90
h1. Stakeholders
91 16 Václav Hrabík
 * Petr Pícha (zákazník)
92
 * Petr Urban, Petr Štěpánek, Jiří Trefil a Václav Hrabík (vývojářský tým)
93
 * Adam Šmucr (bakalářská práce)
94
 * manažeři, výzkumníci v SW vývoji, sami vývojáři (potencionální uživatelé)
95 1 Petr Urban
96
h1. Seznam rizik
97
98
h2. Technická rizika
99 16 Václav Hrabík
 * Neznalost původní architektury
100
 * Neznalost používaných frameworků
101 15 Václav Hrabík
102
h3. Řešení technických riziky
103 16 Václav Hrabík
 * Řádné zaškolení a prostudování architektury
104
 * Řádné zaškolení a prostudování manuálů a vyzkoušení si principů na testovém projektu
105 15 Václav Hrabík
106
h2. Časová rizika
107 16 Václav Hrabík
 * Velká vytíženost vývojářského týmu v ostatních předmětech
108
 * Nemoci, lékařské zákroky
109
 * Velikonoce
110 15 Václav Hrabík
111
h3. Řešení časových rizik
112 16 Václav Hrabík
 * Pracovat postupně, průběžně a časově efektivně
113
 * Ihned po zjištění události oznámit týmu, aby se na to mohlo ihned reagovat
114
 * neslavit velikonoce :D