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 |