Vize » Historie » Revize 14
Revize 13 (Petr Urban, 2023-03-07 16:50) → Revize 14/35 (Petr Urban, 2023-03-07 16:52)
h1. Popis a cíle frameworku SPADe
h2. Popis stávajícího SPADe frameworku
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
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
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ě
zareagovat. (Petr Štěpánek, 2022)
V současné době neexistuje komerční nástroj, který by v projektových
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
Katedry informatiky a výpočetní techniky (KIV) Fakulty aplikovaných věd
(FAV) Západočeské univerzity v Plzni (ZČU), kde je vyvíjen framework
Software Anti-pattern Detector (SPADe).
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
následně umožněno provádět datové analýzy zjišťující přítomnost událostí,
vzorců chování, konceptů a metod. Zvláštní pozornost je věnována zejména
přítomnosti špatných praktik a anti-vzorů.
h2. Cíle
!clipboard-202303071647-yhpvy.png!
[obr. 1]
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.
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.+.
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(ů).
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ý deploy potom v CI/CD apod.
h1. Hrubý plán projektu
h2. Iterace
*Iterace vycházejí z pravidel definovaných v [[Interní_konvence]]*
> h3. 1. iterace:
>> * 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.
> h3. 2. iterace:
>> * Upravit strukturu projektu na moduly. Každý modul bude představovat pod-aplikaci.
>> * 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)
>> * 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
>> * Začít připravovat technickou dokumentaci. Nejlépe v AEP6 formátu.
>> * Ladit dokumenty, wiki, interní dokumenty a obecně všechny věci týkající se vedení projektu.
>> * Upravovat technické návrhy, vymýšlení návrhů na možné změny infrastruktury a architektury.
>> * Dokončení vizí obecně (to znamená mít hotový seznam rizik, stakeholders apod.)
> h3. 3. iterace:
>> * mít rozběhané všechny potřebné technologie, připravené prostředí a začít na vývoji.
>> * 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.
>> * dosažení milníku LCA
>> * 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é.
>> * lazení technické dokumentace
> h3. 4. iterace:
>> * lazení technické dokumentace
>> * 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ů.
>> * dotažení kontraktových testů
>>> * Mít dodělané potřebné endpointy v controlleru, které se budou využívat ve webové aplikaci.
>> * Rozmýšlení nad CI/CD, případně studium technologií
> h3. 5. iterace:
>> * dotažení webového rozhraní
>>> * Hotová stránka about, doplnit o metadata, povýšit verzi aplikace, hotová stránka main page a případně i další dle zvážení.
>> * 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í.
> h3. 6. iterace:
>> * uživatelská příručka,
>> * funkční release,
>> * technická dokumentace alespoň z části hotová
>> * dokončení administrativních záležitostí
>> * předání zákazníkovi.
h1. Stakeholders
h1. Seznam rizik