# 2. Softvérové inžinierstvo Životní cyklus SW, proces vývoje a řízení softwarového vývoje. Metodika (Rational) Unified Process (UP, RUP), agilní metodiky a principy agilního vývoje SW. Nasazení a provoz softwarových systémů. Údržba softwarových systémů, znovupoužitelnost. Příklady z praxe pro vše výše uvedené. (PA017) --- **Softvérové inžinierstvo** je samostatný inžinersky odbor, ktorý rieši systematický prístup k vývoju, prevádzke, údržbe a náhrade softvéru. Chýba nejaká ucelená teória, zakladná terminológia nie je jednotná a prakticky sa používajú kolekcie osvedčených techník. **Softvér** je artefaktom vývojového procesu, ktorý vzniká inžinierskou prácou. Skladá sa z programov, procedúr, pravidiel, dokumentácie a dát, ktoré sú potrebné k prevádzke systému. Softvérový produkt je výrobok určený k predaniu používateľovi. Softvér sa dá rozdeliť na **generický** a **zakázkový**. Počas života softvéru sa komunikuje s jeho používateľom (návrh, údržba). ## Životný cyklus SW, proces vývoja a riadenia softvérového vývoja **Procesom vývoja** rozumieme proces, ktorý postupne transformuje **požiadavky** zákazníka (používateľa) do softvérového **riešenia**. V rámci tohto procesu sa **hovorené požiadavky** formálne **spíšu** do funkčných a nefunkčných požiadaviek, ktoré sa následne **dizajnujú** do celkovej SW architektúry a návrhových diagramov. Tieto výstupy slúžia programátorom na **vytvorenie kódu** podľa návrhov, ktoré budú spĺňať dané požiadavky. Na záver sa výsledný kód **testuje**, **dokumentuje** a **certifikuje**, aby bol oprávnený na použitie užívateľmi. **Životné cykly SW** vychádzajú z konkrétnych ustanovených vývojových procesov. Životné cykly vznikli, aby sme zabránili vzniku problémov pri vývoji, ako napríklad: - Nepresné pochopenie požiadavkov - Neschopnosť reagovať na požiadavky - Zložitá údržba alebo rozšírenie systému - Neskoré objavenie závad - Nízka kvalita a výkon softvéru - Nekoordinovaná práca v tíme Takýto proces sa zvyčajne skladá z fáz: - Analýza - Návrh - Implementácia - Testovanie - Nasadenie / údržba systému Rozlišujeme množstvo ustálených životných cyklov: - **Vodopád (waterfall)** - Postupujeme prísne sekvenčne v poradí jednotlivých fáz. - Ak máme všetky špecifikácie, prejdeme k návrhu, ak máme kompletný návrh, prejdeme k implementácii, ak máme naimplementované, prejdeme k systémovému testovaniu. Ak máme otestované, nasadzujeme a presúvame sa do fáze údržby. - Zvyčajne sa zároveň s implementáciou tvoria aj unit testy. - Je vhodný na jednoduché / malé projekty, ktoré majú jasne stanovené požiadavky. - Nevýhody - Čím neskôr sa nájdu problémy v špecifikácii, tým viac to spôsobí rozdiely na cene - Môže dojsť k nedodržaniu poradia - Zákazník nedostatočne zadá špecifikáciu - Zákazník musí byť trpezlivý, lebo až do konca nemá vlastne nič v rukách - Nemôže na tom robiť hocijaký tím ľudí, musia byť kvalifikovaní, až talentovaní - Výhody - Je jednoduchý, má nízky management overhead (menežeri ho majú radi) - Dizajn systému býva elegantný, pretože je všetko premyslené vopred - **Inkrementálny (incremental)** - SW sa vyvíja vo verziách (inkrementoch), ktoré postupne nabaľujú na funkcionalite. - Každý inkrement je samostatný vodopád. - Je vhodný na veľké projekty s pomerne jasnými požiadavkami. - Nevýhody - Na začiatku sa začne s nejakými požiadavkami, ale môžu veľmi prerásť - Administratívny overhead, drahší ako vodopád - Zákazník dostane inkrement a ihneď ho začne používať (používa starú dokumentáciu, nie všetko musí fungovať, vzniká frustrácia) - Výhody - Rýchlejšie nasadenie, viditeľnosť, lepšie vie reagovať na zmeny - Na dokumentácii sa pracuje v menších celkoch a periodicky - **Prototyp (prototype)** - Odlišný od vodopádu a inkrementu, slúži na preskúmanie možností, ako by finálny produkt mohol vyzerať. - Spočíva v opakovanom vytváraní prototypov, ktoré majú iba zlomkovú funkcionalitu. Následne sa prototyp zahodí a začne sa odznova ak je zlý, alebo sa prejde na iný vývojový cyklus. - Fázy: identifikácia požiadaviek, návrh prototypu, implementácia, testovanie a hodnotenie. - Zákazník rád kritizuje, zvyčajne sa odporúča max. 2 prototypy. - Je vhodný na menšie projekty, ktoré majú nejasné požiadavky. - **Výskumník (researcher)** - Jedná sa o vývojový cyklus na základe princípu trial and error (vyskúšaj a uvidíš). - Nemáme jasne stanovené požiadavky, očakávame iba nejaký business goal. - Príklad: Navrhni auto, ktorá vyhrá F1. - Nevýhody - Neexistuje dokumentácia - Veľmi špecifický tím ľudí, nedajú sa nahradiť - Ťažko sa menežuje - Experimentuje sa s nejasným výsledkom - Nepoužiteľné v komerčnej sfére - Výhody - Potenciálne vznik prelomového riešenia - **Špirála (spiral)** - Jedná sa o iteratívny, inkrementálny proces - Základom špirály je cyklus, ktorý sa skladá z: - Plánovanie - requirements plan, lifecycle plan, development plan, integration and test plan - Analýza - zber požiadaviek - Evaluácia alternatív, analýza a riešenie rizík (risk management), tvorba prototypu - Vývoj - koncept, požiadavky, product design, detailed design - Môžeme mať niekoľko cyklov podľa potreby - Výhody - ??? - Nevýhody - ??? Samotný vývoj v rámci zvoleného cyklu sa zvyčajne musí **riadiť** pomocou nejakých menežmentových procesov. Rozlišujeme **prediktívny** a **agilný** prístup. - **Prediktívny** (tradičný) prístup - Rigidný (nemenný) - Je založený na riadení a dodržiavaní procesov - Rozsah práce a požiadavky sú jasne dané - Je nutné množstvo plánovania napred - Príklad: **Unified Process** (UP) - Príklad použitia: jadrová elektráreň - Funkcionalita je daná, mení sa čas a dostupné zdroje (peniaze) - **Agilný** prístup - Flexibilný (meniteľný) - Je založený na riadení ľudských zdrojov - Požiadavky sa dynamicky menia - Minimálne plánovanie napred - Príklad: **SCRUM** - Príklad použitia: e-shop, podnikové IS - Čas a zdroje sú dané, mení sa funkcionalita ## Metodika RUP, UP, agilné metodiky, principy agilného vývoja SW Metodika **Unified Process** je framework softvérového vývojového procesu založený na **prediktívnom** prístupe. K práci pristupuje **iteratívne a inkrementálne**. Proces vyžaduje, aby sa projektový tím v rámci prvej iterácie identifikoval **riziká** (risk management). Ustanovuje, že volba a vybudovanie dobrej architektúry systému je hlavným cielom projektového tímu. V rámci UP sa používajú **UML diagramy**, ktoré nám ukazujú statickú (class diagram, use case diagram) a dynamickú (activity diagram, communication diagram, state diagram) štruktúru architektúry. Projekt sa skladá zo **4 fáz**: - **Inception** (výsledkom sú ciele) - Rozhodnutie, či je systém možné vytvoriť (feasibility study) - Ustanovenie business case cielu - Zapísanie počiatočných požiadaviek - Identifikácia rizík - **Elaboration** (výsledkom je architektúra) - Vytvorenie architektonického základu - Zapísanie všetkých požiadaviek - Vytvorenie statických a dynamických UML modelov - Vytvorenie use case diagramov - **Construction** (výsledkom je nejaký funkčný celok) - Dokončenie dizajnu a analýzy systému - Programovanie - Testovanie - **Transition** (výsledkom je produkt) - Oprava chýb - Vytvorenie manuálov a dokumentácie - Poskytnutie školení, handover - Vydanie produktu Každá fáza sa môže skladať z 1 a viac iterácií. Na konci každej iterácie vzniká inkrement. Každá iterácia sa skladá zo **6 procesov**: - **Business modeling** - Vytvorenie diagramov zrozumiteľných pre stakeholderov - Modelovanie ceny, zárobku, straty, exit plan - Používa **activity diagram** - **Requirements** - Modelovanie užívateľských očakávaní - Definuje kontrakt medzi developerom a klientom - Používa **use case diagram** - **Analysis and Design** - Návrh diagramov, ktoré pomôžu programátorom pri tvorení kódu - Používa **class diagram, sequence diagram, collaboration diagram** - **Implementation** - Zameriava sa na OOP jazyky - Používa **class diagram, object diagram, component diagram** - **Test** - Používa **use case diagram** na blackbox testing interakcií medzi aktérmi - Používa **class diagram** na nájdenie nežiadaných interakcií medzi triedami - Používa **activity diagram** na nájdenie alternatívnych procesných tokov - **Deployment** (internal or external) - Pripravuje SW na použitie - Definuje požiadavky na HW a SW - Používa **deployment diagram**, ktorý obsahuje väzby na fyzické subsystémy a ich závislosti **Inkrementom** sa rozumie **rozdiel** medzi dvoma iteráciami. Každá iterácia je **mini-projekt**, ktorý by nemal trvať dlhšie ako 3 mesiace. V rámci jednej fázy môže prebehnúť niekoľko iterácií podľa veľkosti projektu. **Kedy** použiť UP: - Ak máme väčšinu požiadaviek definovaných už na začiatku projektu - Ak potrebujeme úplnú kontrolu nad procesom a tímom - Ak developeri potrebujú hĺbkovú dokumentáciu (UML diagramy) - Zvyčajne máme Fixed Time, Fixed Price - Zákazník dostane to, čo je definované v kontrakte - Zákazník nepotrebuje dohliadať nad projektom - Kontrakt musí obsahovať veľa špecifík - Projekt potrebuje veľa času na plánovanie - Change requests sú náročné - Striktné dodržiavanie deadlinov a budgetu **Rational Unified Process (RUP)** je špecifickou implementáciou UP frameworku od spoločnosti Rational Software (neskôr odkúpené IBM). RUP ide viac do hĺbky, presne definuje kto, čo, kedy a ako. Jedná sa o komerčný produkt. Rozširuje UP o ďalšie procesy, ako napr. Configuration and change management, Environment a Project management. RUP bol neskôr evolvovaný do agilných metodík (OpenUP). Na rozdiel od tradičných metodík, **agilné metodiky** majú rýchlo reagovať na požadované zmeny (change management). Sú primárne cielené na iteratívny a inkrementálny vývoj softvéru. Kladie sa veľký dôraz na komunikáciu so zákazníkom. Dokumentácia nie je až tak dôležitá ako dokončený projekt - dokumentácia stojí peniaze a čas. Medzi agilné metodiky patrí: - Extreme programming (XP) - Používa bežné princípy a postupy ale doťahuje ich do extrému - Neustále revidovanie, párové programovanie - Neustále testovanie, automatizované testy - Neustály refaktoring - Hodí sa na menšie projekty a menšie tímy, a ak je nepresné zadanie alebo sa rýchlo mení - Najvyššia hodnota je vytvoriť čo najkvalitnejší kód, ktorý je zároveň zdrojom dokumentácie - Feature driven development (FDD) - Najmenej agilná metodika - Vývoj prebieha po malých kúskoch, zvyčajne z 5 fáz - 3 sekvenčné, 2 iteratívne - Vytvorenie celkového modelu - Vytvorenie zoznamu požiadaviek - Plánovanie podľa požiadaviek - Iterácie o veľkosti 2 týždňov - Návrh - Implementácia - Na začiatku projektu sa spraví obrysová špecifikácia a zákaník si vyberá čo sa implementuje - Test driven development (TDD) - Je založený na princípe Red-Green-Refactor - Napíšem najprv test, na ktorý napíšem minimálnu implementáciu aby to prešlo - Potom sa k tomu vrátim a refaktorujem - Nezaoberá sa formálnou špecifikáciou, plánovaním a dokumentáciou - K testom sa pristupuje ako k hlavnej fázi vývojového cyklu - **SCRUM** - V dnešnej dobe najviac používaná agilná metodika - Ľahká na pochopenie, ťažká na dokonalé aplikovanie - Teória sa zakladá na "The SCRUM guide" - 19 stran, kde sa definujú krátke ale striktné pravidlá - Očakáva sa využitie ďalších metodík a techník na ucelenie vývojového procesu - SCRUM sa skladá z nasledovnej štruktúry: - 5 udalostí - Sprint - max. 1 mesiac - Sprint Planning - 8h meeting pred šprintom - Daily SCRUM - denný meeting o progrese - Sprint Review - 4h meeting, kontrola inkrementu, úprava Product Backlogu, rekalkulovanie ceny a času dokončenia - Sprint Retrospective - 3h meeting, hodnotenie šprintu, čo zlepšiť a čo nechať tak - 3 role - Product Owner - zastáva sa stakeholderov, nastavuje Product Backlog - SCRUM Master - menežuje proces - Team of Developers - udržuje a implementuje Sprint Backlog - 3 artefakty (výstupy) - Product Backlog - Skladá sa z user stories, ohodnotené story pointami - Sprint Backlog - podmnožina z Product Backlogu, ktorá sa má v rámci šprintu implementovať - Product Increment - výstup zo šprintu - User stories sa zvyčajne hodnotia pomocou Story pointov na základe **Planning pokeru** - V rámci tímu sa definuje jednotka, napr. 1-100 v závislosti na veľkosti - Na sprint planningu sa rozdajú kartičky, každá kartička je čislom Fibonacciho postupnosti - Členova tímu zvolia hodnotu k user story a potom sa o tom diskutuje - V rámci SCRUMu neustále bojujeme s vyvážením vzťahu **Time-Functionality-Price** ## Nasadenie a beh SW Po dokončení vývojového procesu sa dostávame do fáze **nasadzovania** a **odozvdania** projektu (**handover**). Softvér sa nasadzuje na rôzne **prostredia**: - Development - lokálne testovanie developermi - Test - používa oddelenú databázu, zvyčajne slúži na testovanie funkcionality zákazníkom - Staging - používa živú databázu ale môže byť iná verzia za účelom testovania, neskôr sa preklopí na Production - Production - používa živú databázu a priamo dostupné zákazníkovi Nasadzovanie sa robí **manuálne** (Bash, SSH, Remote desktop) alebo **automaticky** pomocou **CI/CD** (Continuous integration, delivery) procesov. CI slúži na **automatizované testovanie** a statickú analýzu kódu, CD na **automatické nasadenie** na servery. Príklad: GitHub CI, GitLab CI, Azure DevOps, Jenkins. Môžeme použiť aj technológie ako Docker, RedHat OpenShift (Kubernetes), Ansible. Po nasadení sa softvér dostáva do **stavu behu a údržby**. - Robíme monitoring služieb (heartbeat) - Logging - Change management - Školenie zamestnancov a užívateľov - Support ## Údržba SW, znovupoužiteľnosť **Údržbou SW** rozumieme modifikáciu nasadeného SW po predaní zákazníkovi za účelom opravy chýb, zvýšenia výkonnosti a prispôsobeniu zmenám. - Údržbu môže robiť iný tím ako ten, čo ho vyvíjal - Zvyčajne má support inú cenu a samostatnú zmluvu ako vývoj V určitých prípadoch vieme **artefakty** z projektu použiť v iných projektoch. Poznáme úrovne **znovupoužiteľnosti**: - Abstrakcie - analytické prvky (UML diagramy, špecifikácie, manuály...) - Objekty - triedy - Komponenty - kolekcie tried, services - Systém - kompletný systém Dôležité je sa zamyslieť nad nejakým **overheadom**: - Čas strávený hľadaním vhodnej komponenty - Cena za použitie - Úprava a doprogramovanie komponenty - Integrácia (cena, čas, úsilie) Príklad: Informačný systém MUNI Špecificky existuje aj **Reuse-oriented vývojový proces**, kde sa zameriavame na využitie čo najviac "off the shelf" modulov a doprogramujeme si zvyšok, napr. UI, samostatne.