Princípy softvérového inžinierstva

ak. rok 2025/26

 
 

Projekt

 
 

V rámci predmetu Princípy softvérového inžinierstva sa oboznámite s podstatnými fázami realizácie projektu zameraného na tvorbu modelu softvérového systému vrátane jeho vykonateľnej podoby.

Projekt pozostáva z týchto časti ku ktorým sú asociované termíny odovzdávania:

  1. Zameranie projektu, do 02.03.2026 08:00 (5 b)
  2. Špecifikácia požiadaviek, prípady použitia, do 16.03.2026 08:00 (15 b)
  3. Iniciálny model správania v UML, do 07.04.2026 08:00 (10 b)
  4. Štruktúra systému, objekty, triedy a interakcia, do 27.04.2026 08:00 (15 b)
  5. Implementácia, kód, do 04.05.2026 08:00 (10 b)
  6. Finálna správa o riešení projektu, posledný deň výučby v letnom semestri do 15.05.2026 23:59

Hodnotenie projektu

Základné povinnosti študenta pri realizácii projektu definujú podmienky absolvovania. Termíny odovzdávania sú striktné. V zátvorkách je uvedené maximálne bodové hodnotenie každej časti projektu. Všetky časti projektu sa odovzdávajú do systému AIS, pre čo budú vytvorené zodpovedajúce miesta odovzdania. Všetky časti projektu sú povinné. Bez ich odovzdania na akceptovateľnej úrovni nie je možné absolvovať predmet.

Súčasťou hodnotenia projektu je aj kvalita práce na cvičeniach (pripravenosť, aktivita a úroveň prezentovania progresu, vedenie diskusie) a prednáškach, za ktorú vyučujúci na cvičeniach do záverečného hodnotenia pridelí maximálne 15 bodov. Celkovo za projekt tak možno získať 70 bodov. Body získané za aktivity na prednáškach môžu kompenzovať body v rámci hodnotenia aktivity avšak len do výšky hodnotenia aktivity a teda maximálne do 15 bodov.

Projekt končí odovzdaním Finálnej správy o riešení projektu. Jednotlivé časti projektu sú po ich odovzdaní, a so súhlasom vyučujúceho aj pred ich formálnym odovzdaním, prezentované vyučujúcemu a na základe rozhodnutia cvičiaceho aj ostatným účastníkom cvičenia. O forme/spôsobe prezentácie a diskusie rozhodne cvičiaci priamo na cvičení. Prezentácia a následná diskusia má jednoznačný vplyv na hodnotenie odovzdanej časti. Môže vplývať na zvýšenie alebo zníženie hodnotenia časti projektu do 100% (nie je možné prekročiť maximálne hodnotenie). Študenti majú poznať vlasntú prácu, majú byť v odovzdanom modeli zorientovaní a pripravení zodpovedať instatntné otázky a riešiť zadané úlohy vyučujúceho na cvičeniach. V rámci prezentácie a následnej obhajoby sa očakáva korektné zodpovedanie otázok vyučujúceho na cvičeniach a diskutujúcich. Istú časť projektu vypracujete v nástroji Enterprise Architect (EA). Všetky diagramy pritom dopĺňate do toho istého projektu v EA tak, aby tvorili konzistentný celok.

1. Zameranie projektu

Vypracujte zámer projektu ako spresnenie rámcovej témy tak, aby bolo jasné, aký softvérový systém budete modelovať. Projekt výstižne pomenujte. K zámeru projektu je každý člen tímu povinný vypracovať samostatný opis jedného prípadu použitia relevantného k navrhovanému riešeniu. Počet vypracovaných prípadov použitia musí zodpovedať počtu členov tímu; napríklad pri štvorčlennom tíme je požadované spracovanie štyroch prípadov použitia. Očakávaný rozsah textu zámeru projektu je približne 2 000 znakov, pričom do tohto rozsahu sa nezapočítavajú opisy prípadov použitia.

Dokument odovzdajte vo formáte PDF. Píšte s použitím diakritiky. Nezabudnite v dokumente uviesť mená členov tímu.

Zámer projektu podlieha schváleniu a prípadným úpravám zo strany vyučujúceho na cvičeniach. Využite preto cvičenia pred termínom odovzdaním na prekonzultovanie jeho predbežného znenia.

Odovzdáva sa: dokument so zámerom projektu (PDF)

Hodnotenie časti 1

Spôsob hodnotenia je nasledujúci:

  • prehľadný a jasný zámer – 5 b
  • prevažne prehľadný a jasný zámer, málo výstižný alebo chýbajúci názov projektu – 4 b
  • neprehľadný a nejasný zámer – 0–3 b

2. Špecifikácia požiadaviek, prípady použitia

Vytvorte model prípadov použitia, ktorý zodpovedá zámeru vášho projektu. Model prípadov použitia pozostáva z textového vyjadrenia prípadov použitia a tomu zodpovedajúcich diagramov prípadov použitia v UML.

Opis prípadov použitia dodajte v samostatnom súbore (PDF). Diagramy prípadov použitia vypracujte a dodajte ako model v EA. Opis prípadov použitia má byť konzistentný vo zvolenej notácii: Jacobsonovej, Cockburnovej alebo aj inej, prípadne aj s vlastnými prispôsobeniami (konzultujte s vyučujúcim na cvičeniach). V dokumente opíšte konvencie notácie, ktoré platia pre váš model.

Snažte sa o to, aby medzi prípadmi použitia bol aspoň jeden vzťah include, jeden vzťah extend a jeden vzťah generalizácie, a to medzi prípadmi použitia, ktoré sú opísané (uvedené sú kroky ich tokov).

Prípady použitia organizujte do diagramov podľa predmetu (subject). Samotné diagramy prípadov použitia (nie jednotlivé prípady použitia) opíšte priamo v EA ako keby ste opisovali príslušný predmet. Z tohto opisu by malo byť jasné prečo sú dané prípady použitia uvedené spolu.

Odovzdáva sa:

  • dokument s opisom prípadov použitia (PDF)
  • príslušné diagramy v modeli v EA
  • PDF súbor dokumentujúci realizáciu časti projektu

Hodnotenie:

Aby táto časť projektu mohla byť hodnotená nenulovým počtom bodov, musí zodpovedať zámeru projektu, rámcovému zadaniu a spĺňať nasledujúce podmienky:

  1. Diagramy prípadov použitia musia byť súčasťou modelu v EA.
  2. Musí byť opísaných aspoň 7 prípadov použitia s netriviálnymi tokmi. Ak sú prípady použitia typu CRUD pre danú entitu rozpísané do samostatných prípadov použitia, všetky tieto prípady použitia sa počítajú ako jeden. V prípadoch použitia sa musí vyskytovať aspoň jeden alternatívny tok mimo vzťahu extend.
  3. Model v EA musí byť dodaný vo verzii, licenciou ktorej disponuje fakulta.

Spôsob hodnotenia tejto časti projektu je nasledujúci:

  • základný model prípadov použitia:
    • správne identifikované a korektne napísané prípady použitia s uvedením a dodržaním zvolených konvencií, adekvátne organizované do diagramov podľa predmetu: 8–9 b
    • menšie nedostatky v modeli prípadov použitia, menej adekvátna organizácia do diagramov, s nejasnou identifikáciou konvencií alebo nedostatkami pri ich dodržiavaní: 5–7 b
    • väčšie nedostatky v modeli prípadov použitia, neadekvátna alebo chýbajúca organizácia do diagramov, bez explicitnej identifikácie konvencií alebo veľkými nedostatkami pri ich dodržiavaní: 0–4 b
  • vzťahy medzi prípadmi použitia:
    • aspoň jeden korektný include, jeden extend a jeden vzťah generalizácia-špecializácie medzi opísanými prípadmi použitia, konzistentný s týmto opisom: 6 b
    • menšie nedostatky vo vzťahoch a ich konzistencii s opisom prípadov použitia alebo bez generalizácie-špecializácie: 4–5 b
    • väčšie nedostatky vo vzťahoch a ich konzistencii s opisom prípadov použitia alebo ich absencia: 0–3 b

3. Iniciálny model správania v UML

Pre vybrané prípady použitia (ich toky) vypracujte diagramy sekvencií a pre tie isté prípady použitia aj diagramy aktivít (aby ste mohli konfrontovať tieto techniky). Použite pokročilé prvky diagramov sekvencií a diagramov aktivít.

K prípadom použitia, pre ktoré ste vypracovali diagramy sekvencií a diagramy aktivít, v príslušných diagramoch uveďte zodpovedajúce kolaborácie s rolami, ktoré vyplynuli z (opisov) prípadov použitia, a ktoré sa prejavujú v diagramoch sekvencií (typy línií života) alebo v diagramoch aktivít (typy prenášaných objektov).

Odovzdáva sa:

  • príslušné diagramy v modeli v EA
  • PDF súbor dokumentujúci realizáciu časti projektu

Hodnotenie:

Aby táto časť projektu mohla byť hodnotená nenulovým počtom bodov, musí zodpovedať zámeru projektu, rámcovému zadaniu a spĺňať nasledujúce podmienky:

  1. Pre zodpovedajúci počet (odvodený od počtu členov tímu) prípady použitia (ich toky) musia byť vypracované diagramy sekvencií a pre tie isté prípady použitia aj diagramy aktivít.
  2. Model v EA musí byť dodaný vo verzii, licenciou ktorej disponuje fakulta.
  3. Táto časť projektu musí byť odovzdaná do AIS-u a prezentovaná aspoň raz v pokročilom štádiu rozpracovania pred jej záverečným odovzdaním.

Spôsob hodnotenia tejto časti projektu je nasledujúci:

  • korektne koncipované diagramy sekvencií s primeraným využitím kombinovaných fragmentov konzistentné s opisom prípadov použitia, korešpondujúce diagramy aktivít s korektne použitými uzlami rozhodovania a spájania, korektne uvedené kolaborácie: 8–10 b
  • menšie nedostatky v diagramoch sekvencií a diagramoch aktivít alebo slabšie využitie kombinovaných fragmentov a uzlov rozhodovania a spájania, menšia nekonzistencia s opisom prípadov použitia, menšie nedostatky v kolaboráciách: 4–7 b
  • väčšie nedostatky v diagramoch sekvencií a diagramoch aktivít, vrátane nevyužitia kombinovaných fragmentov a uzlov rozhodovania a spájania, zásadná nekonzistencia s opisom prípadov použitia, chýbajúce alebo zásadne mylné kolaborácie: 0–3 b

4. Štruktúra systému, objekty, triedy a interakcia

Triedy a rozhrania, ktoré tvoria architektonický základ systému, a triedy a rozhrania identifikované prostredníctvom iniciálneho modelu správania, ktorý je výsledkom predchádzajúcej časti projektu, znázornite v diagramoch tried ako základnom modeli štruktúry systému. Dbajte na zrozumiteľnosť v zmysle adekvátneho pomenovania a rozloženia prvkov v diagramoch. Využite viaceré diagramy s primeraným počtom prvkov, ktorými zachytíte dôležité pohľady na systém (jeden prvok sa môže vyskytovať vo viacerých diagramoch). Výstižne pomenujte tieto pohľady, t. j. diagramy tried.

Identifikácií tried môže predchádzať identifikácia kľúčových objektov a súvislostí medzi nimi prostredníctvom tzv. diagramu objektov. Ten sa v UML pokladá iba za špeciálny prípad diagramu tried. Aj keď je jednoduchý, má výhodu znázornenia predstavy o fungujúcom systéme bez nutnosti zaoberania sa implementačnými mechanizmami. Identifikujte zaujímavú konfiguráciu objektov a znázornite ju diagramom objektov. Znázornite niekoľko variantov naplnenia tejto konfigurácie objektov ďalšími diagramami objektov, napríklad pred a po ich interakcií vyjadrenej diagramom sekvencií, čo vám môže pomôcť pri identifikácií stavov.

Triedy organizujte do balíkov. Medzi balíkmi identifikujte závislosti, ktoré znázornite v diagrame balíkov. Závislosti medzi balíkmi majú reflektovať závislosti medzi ich prvkami.

Použite diagramy sekvencií na špecifikáciu vybraných metód. Koncipujte ich korektne, vrátane modelovania vyvolania špecifikovanej metódy ako nájdenej správy (found message).

Uplatnite stavové diagramy na vyjadrenie stavového priestoru objektov vybraných tried, systému alebo časti systému. Dbajte o logický výber stavov, správne používanie pseudostavov a správne modelované udalosti.

Odovzdáva sa:

  • príslušné diagramy v modeli v EA
  • PDF súbor dokumentujúci realizáciu časti projektu

Hodnotenie

Aby táto časť projektu mohla byť hodnotená nenulovým počtom bodov, musí zodpovedať zámeru projektu, rámcovému zadaniu a spĺňať nasledujúce podmienky:

  1. Model v EA musí byť dodaný vo verzii, licenciou ktorej disponuje fakulta.
  2. Táto časť projektu musí byť odovzdaná do AIS-u a prezentovaná aspoň raz v pokročilom štádiu rozpracovania pred jej záverečným odovzdaním.

Spôsob hodnotenia tejto časti projektu je nasledujúci:

  • korektné uvedenie tried a rozhraní v modeli primeraného rozsahu (aspoň 12 prvkov); uvedenie atribútov a operácií; korektné uvedenie vzťahov medzi triedami a rozhraniami; korektne uvedený diagram objektov a jeho varianty, korektne určené balíky a vzťahy medzi nimi s uvedením príslušného diagramu; konzistentnosť závislostí medzi balíkmi so závislosťami medzi ich prvkami; korektne koncipované diagramy sekvencií aspoň dvoch vybraných operácií (found message) konzistentné s významom modelovaných operácií, netriviálnej zložitosti a s primeraným využitím kombinovaných fragmentov; aspoň dva korektné stavové diagramy; uvedenie adekvátneho opisu prvkov (priamo v modeli): 13–15 b
  • menšie nedostatky ako napr. opakovanie agregácie atribútmi, nepoužitie rozhraní apod.; chýbajúce varianty diagramu objektov, chyby v diagrame balíkov, vynechanie zaradenia tried a rozhraní do balíkov v modeli alebo jeho uvedenie len na úrovni diagramu alebo nekonzistentnosť medzi závislosťami medzi balíkmi a závislosťami medzi ich prvkami; nedostatky v diagramoch sekvencií, nekonzistentnosť s významom modelovaných operácií alebo príliš jednoduché diagramy sekvencií; nedostatky v logike výberu stavov alebo v uvedení udalostí: 6–12 b
  • väčšie nedostatky: 0–5 b

5. Implementácia, kód

K vybranej časti modelu uveďte zodpovedajúci kód vo vami zvolenom OO programovacom jazyku. Identifikujte a opíšte súvis kódu s architektúrou a prípadmi použitia.

Odovzdáva sa:

  • kód
  • PDF súbor dokumentujúci realizáciu časti projektu

Hodnotenie

Aby táto časť projektu mohla byť hodnotená nenulovým počtom bodov, musí zodpovedať zámeru projektu, rámcovému zadaniu a spĺňať nasledujúce podmienky:

  1. Kód sa dá spustiť v prostredí inštalovanom na fakultných počítačoch (IntelliJ IDEA 2025.3.2).
  2. Ku kódu je poskytnuté vysvetlenie.

Spôsob hodnotenia tejto časti projektu je nasledujúci:

  • adekvátny kód s jasným opisom vzťahu k architektúre a prípadom použitia: 9–10 b
  • menej adekvátny kód alebo menej jasný opis: 4–8 b
  • väčšie nedostatky: 0–3 b

6. Finálna správa o riešení projektu

Sumarizujte aktivity realizované počas práce na projekte. Dokumentujte podstatné časti jednotlivých súčastí projektu. Do dokumentácie integrujte najdôležitejšie informácie o zdieľanom repozitári (GitHub) a jednotlivých šprintoch (Jira). Syntetizujte výkony jednotlivých členov tímu v prehľadnej tabuľke.

Odovzdáva sa: dokument Finálna správa o riešení projektu (PDF)

Spôsob hodnotenia tejto časti projektu je nasledujúci:

  • Odovzdanie poslednej časti, ktorá len sumarizuje priebežné aktivity nie je hodnotené bodovo ale je neoodeliteľnou a povinnou súčasťou projektu.

^