# 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.