Projekt

Obecné

Profil

Vize » Historie » Verze 33

Václav Hrabík, 2023-04-10 08:34

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 25 Petr Štěpánek
!clipboard-202303181252-ieyt2.png!
21 27 Petr Štěpánek
[obr. 1]
22 23 Petr Štěpánek
23 4 Petr Urban
h2. Cíle
24 1 Petr Urban
25 4 Petr Urban
26
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.
27
28 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.+.
29 4 Petr Urban
30
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(ů).
31
32
33 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.
34
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 32 Václav Hrabík
# Kompletní a ucelená dokumentace produktu (malá priorita)
42 16 Václav Hrabík
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 31 Václav Hrabík
*Viz [Roadmap]*
50 1 Petr Urban
51
h1. Stakeholders
52 18 Václav Hrabík
53 16 Václav Hrabík
 * Petr Pícha (zákazník)
54
 * Petr Urban, Petr Štěpánek, Jiří Trefil a Václav Hrabík (vývojářský tým)
55
 * Adam Šmucr (bakalářská práce)
56
 * manažeři, výzkumníci v SW vývoji, sami vývojáři (potencionální uživatelé)
57 1 Petr Urban
58
h1. Seznam rizik
59
60
h2. Technická rizika
61 18 Václav Hrabík
62 16 Václav Hrabík
 * Neznalost původní architektury
63
 * Neznalost používaných frameworků
64 15 Václav Hrabík
65
h3. Řešení technických riziky
66 18 Václav Hrabík
67 16 Václav Hrabík
 * Řádné zaškolení a prostudování architektury
68
 * Řádné zaškolení a prostudování manuálů a vyzkoušení si principů na testovém projektu
69 15 Václav Hrabík
70
h2. Časová rizika
71 18 Václav Hrabík
72 16 Václav Hrabík
 * Velká vytíženost vývojářského týmu v ostatních předmětech
73
 * Nemoci, lékařské zákroky
74
 * Velikonoce
75 15 Václav Hrabík
76
h3. Řešení časových rizik
77 18 Václav Hrabík
78 16 Václav Hrabík
 * Pracovat postupně, průběžně a časově efektivně
79
 * Ihned po zjištění události oznámit týmu, aby se na to mohlo ihned reagovat
80
 * neslavit velikonoce :D