d
Riadok 6: Riadok 6:
 
Kurz je určený pre študentov 3. ročníka aplikovanej informatiky. Jeho cieľom je podať úvod do formálnej tvorby informačných systémov a nástrojov, ktoré sa pri vývoji informačných systémov používajú. Účastníci predmetu navrhnú, špecifikujú a implementujú skupinový projekt podľa zadania.
 
Kurz je určený pre študentov 3. ročníka aplikovanej informatiky. Jeho cieľom je podať úvod do formálnej tvorby informačných systémov a nástrojov, ktoré sa pri vývoji informačných systémov používajú. Účastníci predmetu navrhnú, špecifikujú a implementujú skupinový projekt podľa zadania.
  
<span style="color:red">Oznam: v akademickom roku 2020/2021 predmet Tvorba informačných systémov prebieha dištančne. </span>
+
<span style="color:red">Oznam: v akademickom roku 2021/2022 predmet Tvorba informačných systémov prebieha (kým situácia umožní) prezenčne. </span>
  
 
== Kontakt ==
 
== Kontakt ==
Riadok 18: Riadok 18:
  
 
* [[Course:Information Systems Development - Projekty/sk|plán]]
 
* [[Course:Information Systems Development - Projekty/sk|plán]]
* [http://dai.fmph.uniba.sk/courses/tvorbaIS/skupiny/skupiny_tis_2020.txt skupiny]
+
* [http://dai.fmph.uniba.sk/courses/tvorbaIS/skupiny/skupiny_tis_2021.txt skupiny]
 
* [http://kempelen.ii.fmph.uniba.sk/vyber/public/projects projekty]
 
* [http://kempelen.ii.fmph.uniba.sk/vyber/public/projects projekty]
 
<!-- * [[Course:Information Systems Development - Priradení cvičiaci/sk|priradení cvičiaci]] -->
 
<!-- * [[Course:Information Systems Development - Priradení cvičiaci/sk|priradení cvičiaci]] -->
Riadok 25: Riadok 25:
 
== Očakávané výstupy (deliverables) ==
 
== Očakávané výstupy (deliverables) ==
  
'''1. Prihláška na projekty''', <span style="color:green">čím skôr po zverejnení projektov, najneskôr 28.9.</span>
+
'''1. Prihláška na projekty''', <span style="color:green">čím skôr po zverejnení projektov, najneskôr 27.9.</span>
  
Zaradíte sa do 4-členných tímov a každý tím vyplní on-line prihlášku s preferenciami výberu zadaných projektov a popisom skúseností členov tímu
+
Poradíte sa vo svojich 4-členných tímoch a každý tím vyplní on-line prihlášku s preferenciami výberu zadaných projektov a popisom skúseností členov tímu
  
'''2. Katalóg požiadaviek''', <span style="color:green">všetko hotovo najneskôr do 16. 10.</span>
+
'''2. Katalóg požiadaviek''', <span style="color:green">všetko hotovo najneskôr do 15. 10.</span>
  
 
postupne odovzdáte tri samostatné výstupy: <br>A. Podrobné poznámky zo stretnutia so zadávateľom - už potvrdené, resp. korigované zadávateľom<br>B. Neusporiadaný, nie nutne konzistentný, úplný a jednoznačný zoznam požiadaviek, ktoré tím vytvoril na základe poznámok<br>C. Výsledný katalóg požiadaviek, ktorý odsúhlasil zadávateľ. Kým mal zadávateľ pripomienky, treba ich najskôr zohľadniť a ponúknuť mu na odsúhlasenie aktualizovanú, vylepšenú verziu.
 
postupne odovzdáte tri samostatné výstupy: <br>A. Podrobné poznámky zo stretnutia so zadávateľom - už potvrdené, resp. korigované zadávateľom<br>B. Neusporiadaný, nie nutne konzistentný, úplný a jednoznačný zoznam požiadaviek, ktoré tím vytvoril na základe poznámok<br>C. Výsledný katalóg požiadaviek, ktorý odsúhlasil zadávateľ. Kým mal zadávateľ pripomienky, treba ich najskôr zohľadniť a ponúknuť mu na odsúhlasenie aktualizovanú, vylepšenú verziu.
  
'''3. Návrh''', <span style="color:green">všetko hotovo najneskôr do 13.11.</span>
+
'''3. Návrh''', <span style="color:green">všetko hotovo najneskôr do 12.11.</span>
  
 
návrh vytvoríte podľa dohody s cvičiacim podľa typu projektu, ktorý riešite. V každom prípade však musí obsahovať nasledujúce časti: <br>A. podrobná špecifikácia vonkajších interfejsov - ak aplikácia komunikuje s inými aplikáciami, súbormi, zariadeniami - tieto musia byť jasne a podrobne definované<br>B. podrobný dátový model perzistentných údajov, formátov súborov, komunikačných protokolov.<br>C.  návrh používateľského rozhrania (ak projekt má GUI) - nakreslené a popísané všetky dialógy, okná a stránky, ktorými aplikácia komunikuje s používateľom - túto časť treba konzultovať so zadávateľom<br>D. Zrozumiteľný a jednoznačný návrh implementácie, podľa ktorého sa dá aplikácia vyvinúť a ktorý bude obsahovať: UML component diagram, UML class diagram, a aspoň jeden z dvojice UML state a UML sequence diagram, zrozumiteľne vysvetlenú architektúru, rozdelenie na časti (moduly) a ich interfejsy, využité technológie, cieľové prostredie nasadenia do prevádzky.  
 
návrh vytvoríte podľa dohody s cvičiacim podľa typu projektu, ktorý riešite. V každom prípade však musí obsahovať nasledujúce časti: <br>A. podrobná špecifikácia vonkajších interfejsov - ak aplikácia komunikuje s inými aplikáciami, súbormi, zariadeniami - tieto musia byť jasne a podrobne definované<br>B. podrobný dátový model perzistentných údajov, formátov súborov, komunikačných protokolov.<br>C.  návrh používateľského rozhrania (ak projekt má GUI) - nakreslené a popísané všetky dialógy, okná a stránky, ktorými aplikácia komunikuje s používateľom - túto časť treba konzultovať so zadávateľom<br>D. Zrozumiteľný a jednoznačný návrh implementácie, podľa ktorého sa dá aplikácia vyvinúť a ktorý bude obsahovať: UML component diagram, UML class diagram, a aspoň jeden z dvojice UML state a UML sequence diagram, zrozumiteľne vysvetlenú architektúru, rozdelenie na časti (moduly) a ich interfejsy, využité technológie, cieľové prostredie nasadenia do prevádzky.  
  
'''4. Testovacie scenáre''',  <span style="color:green">27. 11.</span>
+
'''4. Testovacie scenáre''',  <span style="color:green">26. 11.</span>
  
 
Na Githube je dokument s testovacími scenármi - ktorý vznikne podľa Katalógu požiadaviek. Jeden scenár môže testovať aj viacero požiadaviek, ale každá požiadavka z katalógu musí byť kompletne pokrytá v nejakom testovacom scenári.  
 
Na Githube je dokument s testovacími scenármi - ktorý vznikne podľa Katalógu požiadaviek. Jeden scenár môže testovať aj viacero požiadaviek, ale každá požiadavka z katalógu musí byť kompletne pokrytá v nejakom testovacom scenári.  
  
'''5. Otestovaný hotový zdrojový kód''', <span style="color:green">23. 12. </span>
+
'''5. Otestovaný hotový zdrojový kód''', <span style="color:green">24. 12. </span>
  
 
Na Githube je prvá funkčná kompletná verzia, ktorá bola aspoň raz predvedená zadávateľovi s podrobným záznamom zo stretnutia so zadávateľom.
 
Na Githube je prvá funkčná kompletná verzia, ktorá bola aspoň raz predvedená zadávateľovi s podrobným záznamom zo stretnutia so zadávateľom.
Riadok 54: Riadok 54:
 
# Projekt:  50b
 
# Projekt:  50b
 
# Písomky: 35b  
 
# Písomky: 35b  
# [http://dai.fmph.uniba.sk/courses/tvorbaIS/midterm2019.pdf Midterm (UML diagramy)] 24. nov. 2020 11:00-13:00: 15b, <!-- ([http://dai.fmph.uniba.sk/courses/tvorbaIS/2019/midterm2019.png  výsledky]), -->pozri príklad [http://dai.fmph.uniba.sk/courses/tvorbaIS/tis/new.html#uml-priklad kap. 3.11. v materiáloch] a tiež [http://dai.fmph.uniba.sk/courses/tvorbaIS/midterm2018.pdf staršie zadanie], alebo [http://dai.fmph.uniba.sk/courses/tvorbaIS/diagramy/ vzorové riešenie z niektorého predchádzajúceho roka]. Najlepší spôsob prípravy na midterm je vyriešiť [[cvicne zadanie midtermu TIS|cvičné zadanie]] alebo [[ine cvicne zadanie midtermu TIS|iné cvičné zadanie]] a poslať mi riešenie vopred mailom, dám Vám k nemu ešte spätnú väzbu. <!-- [[Media:midterm_tis_2018.png|Výsledky 2018]]. --> <br>'''Jednotka intenzívnej starostlivosti''': ak študent nemá 10 bodov z bežného termínu midtermu, tak bude prijatý na JIS: môže riešiť opravný midterm v rovnakom termíne ako bude prebiehať čipovanie vakcináciou (pozri nižšie).
+
# [http://dai.fmph.uniba.sk/courses/tvorbaIS/midterm2019.pdf Midterm (UML diagramy)] 24. nov. 2020 11:00-13:00: 15b, <!-- ([http://dai.fmph.uniba.sk/courses/tvorbaIS/2019/midterm2019.png  výsledky]), -->pozri príklad [http://dai.fmph.uniba.sk/courses/tvorbaIS/tis/new.html#uml-priklad kap. 3.11. v materiáloch] a tiež [http://dai.fmph.uniba.sk/courses/tvorbaIS/midterm2018.pdf staršie zadanie], alebo [http://dai.fmph.uniba.sk/courses/tvorbaIS/diagramy/ vzorové riešenie z niektorého predchádzajúceho roka]. Najlepší spôsob prípravy na midterm je vyriešiť [[cvicne zadanie midtermu TIS|cvičné zadanie]] alebo [[ine cvicne zadanie midtermu TIS|iné cvičné zadanie]] a poslať mi riešenie vopred mailom, dám Vám k nemu ešte spätnú väzbu. <!-- [[Media:midterm_tis_2018.png|Výsledky 2018]]. --> <br>'''Možnosť opravy''': ak študent nemá 10 bodov z bežného termínu midtermu, tak môže riešiť opravný midterm v skúškovom období.
  
 
Na známku je potrebných aspoň 25b za projekt, 20b za písomky, 10b za midterm, potom: 90-100: A, 80-90: B, 70-80: C, 60-70: D, 55-60: E, < 55: Fx.
 
Na známku je potrebných aspoň 25b za projekt, 20b za písomky, 10b za midterm, potom: 90-100: A, 80-90: B, 70-80: C, 60-70: D, 55-60: E, < 55: Fx.
  
Kvôli besneniu koronavírusu sa 35 bodov za písomky realizuje takto:
+
35 bodov za písomky sa realizuje takto:
* počas semestra sa cez vitamínové dotácie buduje vitamínová imunita
+
* počas semestra študenti riešia na prednáške skoro každý týždeň hodnotené besiedky (ich body sa napokon preškálujú na 35 podľa celkového súčtu možných získaných bodov)
* dodatočná infúzia: každý študent môže v skúškovom období jeden deň pred niektorým termínom vakcinácie dostať 1 vybranú duplikovanú vitamínovú dotáciu, ktorá bola v priebehu semestra a jej výsledok nahradí jeho pôvodné vitamíny z tej dotácie
+
* ak študent na konci semestra nemá z besiedok 10 (už preškálovaných) bodov, musí v skúškovom období písať jednu veľkú skúškovú písomku z celého semestra s maximálnym počtom 15 (preškálovaných) bodov
* ak študent po dotáciách (a prípadnej infúzii) nemá ani 5 vitamínov, je v termíne vakcinácie prijatý na ''povinnú'' ventiláciu, lebo nemá ako získať požadovanú úroveň imunity 20 (lebo 5 + 30/2 = 20). Po kompletnej transfúzii krvi dostane na ventilácii všetky vitamíny z celého semestra naraz, ale jeho organizmus už dokáže vstrebať naraz najviac 15 vitamínov z potenciálneho maxima 35, príklad: počas ventilácie získa 20 z 35 vitamínov, ale v organizme sa udrží iba 15
+
* ak sa študent nemohol niektorej besiedky z objektívnych príčin zúčastniť, v skúškovom období si príslušnú besiedku (s inými otázkami) môže nahradiť
* každý študent trpiaci hypovitaminózou (nemá ani 15 vitamínov), ''môže'' ísť na okysličovanie s rovnakými podmienkami ako má ventilácia
+
* ak sa výučba prepne do virtuálneho sveta, aj besiedky sa budú konať on-line, ale on-line získané body bude treba potvrdiť na ústnej skúške on-line v skúškovom období (ak pôjde výučba prezenčne až do konca, takáto skúška nebude)
* všetci študenti: v skúškovom období sa v niektorom termíne zadanom v AISe zúčastnia čipovania vakcináciou, t.j. dovtedy nazbierané vitamíny podporia účinok očkovacej látky implantovanej na on-line ústnej skúške; je možné získať aj väčšiu imunitu ako si cez vitamíny študent vybudoval počas semestra, ale imunita nad rámec vitamínov má iba polovičnú silu, príklad: študent príde na čipovanie s 20 vitamínmi, a naočkuje si 30 čipov, jeho výsledná imunita bude 20 + 10 / 2 = 25. Iný príklad: študent príde na čipovanie s 25 vitamínmi a naočkuje si iba 5 čipov, jeho výsledná imunita bude 5 a ak bude chcieť známku, prihlási sa so svojimi 25 vitamínmi na druhé kolo čipovania.
+
* v prípade otázok, volajte 155
+
  
 
== Pravidlá ==
 
== Pravidlá ==
Riadok 93: Riadok 91:
 
== Prednášky ==
 
== Prednášky ==
  
* 22.09. Úvodná prednáška, plán na semester
+
* 21.09. Úvodná prednáška, plán na semester
* 29.09. Špecifikácia, z materiálov sme prebrali kap. 0 - 1.3 (vrátane) a 2. (treba sa to do budúcej prednášky naučiť)
+
* 06.10. Modely vývoja IS, materiály kap. 1.4 - 1.6.8, Use-case diagramy (3.1)
+
* 13.10. Úvod do návrhu: ciele návrhu, princípy OOP, ERD, DFD, architektonické pohľady, ONF, SDD, materiály: 4 - 4.4.2 (vrátane) plus 3.0 a 3.10
+
* 20.10. Úvod do UML (bude až na midterme)
+
* 27.10. Architektonické štýly
+
* 3.11. Architektonické štýly, XP, experiment s návrhovými vzormi
+
* 10.11. Návrhové vzory
+
* 17.11. sviatok
+
* 24.11. Integrácia aplikácií
+
* 1.11. Clean code
+
* 8.11. Agilné metódy a soft skills
+
* 15.11. pozvaná prednáška Softec: <b>Daniel Buchta: Súčasné trendy pri vývoji Informačných systémov</b><br><i>V súčasnosti sa nachádzame v prechode do tretej etapy informačno technologickej revolúcie.<br>Po etape zoznamovania sa a etape masového rozšírenia sa momentálne nachádzame na prahu automatizácie informačných systémov, ktorá vedie k ich osamostatneniu sa.<br>Nástup tejto etapy sa prejavuje javmi ako prevádzka infraštruktúry a dokonca celých riešení v cloude či delegovanie rozhodovacích procesov a logiky aplikácií na informačné systémy samotné prostredníctvom AI/ML.<br>Na tejto prednáške si predstavíme ako v tomto prostredí prebieha vývoj informačných systémov a aké požiadavky sú kladené na nás, ľudí.</i>
+
  
 
* [[Course:Information_Systems_Development_Lectures2017/sk|minulá sezóna]]
 
* [[Course:Information_Systems_Development_Lectures2017/sk|minulá sezóna]]
Riadok 112: Riadok 98:
 
== Cvičenia ==
 
== Cvičenia ==
  
* 25.09. [http://dai.fmph.uniba.sk/courses/tvorbaIS/ex/git/newer.html cvičenie github], tímy sa už zorganizovali do 4-členných skupín
+
* prvé cvičenie (github) je domáca úloha, ktorú riešite po skupinách
* potom: každý týždeň individuálne stretnutie s cvičiacim v termíne podľa dohody s cvičiacim, z týchto stretnutí píše zápisnicu cvičiaci
+
* každá skupina sa stretne každý týždeň samostatne, na stretnutí si píše zápisnicu (tieto stretnutia môžu byť on-line, ak to tak skupine vyhovuje)
 +
* každý týždeň sa každá skupina stretne s cvičiacim v termíne podľa dohody s cvičiacim, z týchto stretnutí píše zápisnicu cvičiaci, (tieto stretnutia môžu byť on-line, ak to tak skupine vyhovuje)
  
 
== Literatúra ==
 
== Literatúra ==

Verzia zo dňa a času 06:06, 21. september 2021

Tvorba informačných systémov 1-AIN-131

Kurz je určený pre študentov 3. ročníka aplikovanej informatiky. Jeho cieľom je podať úvod do formálnej tvorby informačných systémov a nástrojov, ktoré sa pri vývoji informačných systémov používajú. Účastníci predmetu navrhnú, špecifikujú a implementujú skupinový projekt podľa zadania.

Oznam: v akademickom roku 2021/2022 predmet Tvorba informačných systémov prebieha (kým situácia umožní) prezenčne.

Kontakt

Pavel Petrovič, pavel.petrovic@fmph.uniba.sk
Ivan Polášek, ipo@gratex.com


Projekty


Očakávané výstupy (deliverables)

1. Prihláška na projekty, čím skôr po zverejnení projektov, najneskôr 27.9.

Poradíte sa vo svojich 4-členných tímoch a každý tím vyplní on-line prihlášku s preferenciami výberu zadaných projektov a popisom skúseností členov tímu

2. Katalóg požiadaviek, všetko hotovo najneskôr do 15. 10.

postupne odovzdáte tri samostatné výstupy:
A. Podrobné poznámky zo stretnutia so zadávateľom - už potvrdené, resp. korigované zadávateľom
B. Neusporiadaný, nie nutne konzistentný, úplný a jednoznačný zoznam požiadaviek, ktoré tím vytvoril na základe poznámok
C. Výsledný katalóg požiadaviek, ktorý odsúhlasil zadávateľ. Kým mal zadávateľ pripomienky, treba ich najskôr zohľadniť a ponúknuť mu na odsúhlasenie aktualizovanú, vylepšenú verziu.

3. Návrh, všetko hotovo najneskôr do 12.11.

návrh vytvoríte podľa dohody s cvičiacim podľa typu projektu, ktorý riešite. V každom prípade však musí obsahovať nasledujúce časti:
A. podrobná špecifikácia vonkajších interfejsov - ak aplikácia komunikuje s inými aplikáciami, súbormi, zariadeniami - tieto musia byť jasne a podrobne definované
B. podrobný dátový model perzistentných údajov, formátov súborov, komunikačných protokolov.
C. návrh používateľského rozhrania (ak projekt má GUI) - nakreslené a popísané všetky dialógy, okná a stránky, ktorými aplikácia komunikuje s používateľom - túto časť treba konzultovať so zadávateľom
D. Zrozumiteľný a jednoznačný návrh implementácie, podľa ktorého sa dá aplikácia vyvinúť a ktorý bude obsahovať: UML component diagram, UML class diagram, a aspoň jeden z dvojice UML state a UML sequence diagram, zrozumiteľne vysvetlenú architektúru, rozdelenie na časti (moduly) a ich interfejsy, využité technológie, cieľové prostredie nasadenia do prevádzky.

4. Testovacie scenáre, 26. 11.

Na Githube je dokument s testovacími scenármi - ktorý vznikne podľa Katalógu požiadaviek. Jeden scenár môže testovať aj viacero požiadaviek, ale každá požiadavka z katalógu musí byť kompletne pokrytá v nejakom testovacom scenári.

5. Otestovaný hotový zdrojový kód, 24. 12.

Na Githube je prvá funkčná kompletná verzia, ktorá bola aspoň raz predvedená zadávateľovi s podrobným záznamom zo stretnutia so zadávateľom.

6. Technická dokumentácia a výsledný zdrojový kód, 31. 1.

Aplikácia bola odovzdaná zadávateľovi, ktorý s výsledkom súhlasil, potvrdil, že požiadavky uvedené v katalógu požiadaviek boli splnené a výsledná aplikácia je použiteľná. Zdrojový kód je na Githube vrátane jedného kompletného PDF súboru, ktorý obsahuje aj katalóg požiadaviek aj návrh, pričom je aktualizovaná tak, aby bola v súlade s odovzdaným kódom.


Hodnotenie

  1. Projekt: 50b
  2. Písomky: 35b
  3. Midterm (UML diagramy) 24. nov. 2020 11:00-13:00: 15b, pozri príklad kap. 3.11. v materiáloch a tiež staršie zadanie, alebo vzorové riešenie z niektorého predchádzajúceho roka. Najlepší spôsob prípravy na midterm je vyriešiť cvičné zadanie alebo iné cvičné zadanie a poslať mi riešenie vopred mailom, dám Vám k nemu ešte spätnú väzbu.
    Možnosť opravy: ak študent nemá 10 bodov z bežného termínu midtermu, tak môže riešiť opravný midterm v skúškovom období.

Na známku je potrebných aspoň 25b za projekt, 20b za písomky, 10b za midterm, potom: 90-100: A, 80-90: B, 70-80: C, 60-70: D, 55-60: E, < 55: Fx.

35 bodov za písomky sa realizuje takto:

  • počas semestra študenti riešia na prednáške skoro každý týždeň hodnotené besiedky (ich body sa napokon preškálujú na 35 podľa celkového súčtu možných získaných bodov)
  • ak študent na konci semestra nemá z besiedok 10 (už preškálovaných) bodov, musí v skúškovom období písať jednu veľkú skúškovú písomku z celého semestra s maximálnym počtom 15 (preškálovaných) bodov
  • ak sa študent nemohol niektorej besiedky z objektívnych príčin zúčastniť, v skúškovom období si príslušnú besiedku (s inými otázkami) môže nahradiť
  • ak sa výučba prepne do virtuálneho sveta, aj besiedky sa budú konať on-line, ale on-line získané body bude treba potvrdiť na ústnej skúške on-line v skúškovom období (ak pôjde výučba prezenčne až do konca, takáto skúška nebude)

Pravidlá

  • na riešení projektu sa rovnakou časťou podieľajú všetci členovia tímu; hoci majú rozdelené roly, každý prispieva rovnomerne aj do implementácie zdrojového kódu
  • každá skupina musí odovzdať všetky výstupy načas
  • ak odovzdaný dokument alebo program nespĺňa ani minimálne požiadavky, odovzdanie sa neuzná a tím má možnosť odovzdať novú verziu (avšak ďalšie oneskoré odovzdanie má za následok príslušné bodové ohodnotenie)
  • zdrojové kódy aj odovzdávaná dokumentácia (podadresár docs/) sú priebežne ukladané v tímovom repozitári na Githube (inak za projekt nebudú udelené žiadne body!), všetky projekty sú open-source
  • členovia každého tímu sa každý týždeň stretnú na svojom tímovom stretnutí, pričom vopred je v bodoch známa agenda nasledujúceho stretnutia, pričom:
    • prediskutujú všetky body agendy
    • prvým bodom agendy je zhodnotenie vykonanej práce a splnených úloh od predchádzajúceho stretnutia tímu
    • posledným bodom agendy je naplánovanie práce do ďalšieho stretnutia, pričom ku každej položke sa určí, ktorý člen (členovia) je zodpovedný
    • priamo na stretnutí si píšu zo svojho stretnutia zápisnicu, priamo na samostatnú wiki-stránku svojho tímového repozitára, zápisnica obsahuje: dátum, zoznam prítomných, plánovaná agenda stretnutia, potom podľa bodov agendy, všetky podstatné informácie a prijaté rozhodnutia, zápisnica slúži predovšetkým členom tímu na organizáciu ich práce!


Roly členov tímu

Všetci členovia tímu sa zdokumentovateľne podieľajú na všetkých činnostiach (implementácia, dokumentácia, testovanie, komunikácia, manažment), ale hlavná zodpovednosť je rozdelená do 4 rolí:

  • dokumentácia: tento človek zodpovedá za to, že dokumentácia bude, bude taká ako má byť a bude hotová načas, má rozhodujúce slovo pri plnení úloh týkajúcich sa dokumentácie
  • implementácia: zodpovedá za to, že implementácia bude, bude taká ako má byť a bude hotová načas, má rozhodujúce slovo pri plnení úloh týkajúcich sa implementácie
  • manažment práce: stará sa o to, aby práca napredovala, dobre sa plánovala a rozdeľovala medzi členov tímu, aby sa pracovalo podľa dohodnutého režimu, zodpovedá za neustále napredovanie celého projektu a jeho úspešné dokončenie včas, má rozhodujúce slovo pri plánovaní a pri riešení konfliktov v kompetenciách v tíme, píše zápisnice, alebo tým poveruje iného člena tímu
  • manažment komunikácie (internej aj externej): stará sa o plánovanie stretnutí, komunikáciu s cvičiacim, zadávateľom a hlavne medzi členmi tímu má rozhodujúce slovo a zodpovednosť za správnosť, primeranosť, plynulosť komunikácie

Vysvetlenie: napr. ak je niekto zodpovedný za dokumentáciu, neznamená to, že on bude robiť celú dokumentáciu, ale že rozdeľuje prácu na dokumentácii osatným členom podľa toho, ako manažer komunikácie a manažer práce nastavia komunikáciu a spôsob rozdeľovania práce. T.j. tento človek musí mať dôkladný prehľad o tom, aká dokumentácia už existuje a aká dokumentácia je ešte potrebná a musí mať predstavu, ako tá dokumentácia vznikne.


Prednášky

  • 21.09. Úvodná prednáška, plán na semester


Cvičenia

  • prvé cvičenie (github) je domáca úloha, ktorú riešite po skupinách
  • každá skupina sa stretne každý týždeň samostatne, na stretnutí si píše zápisnicu (tieto stretnutia môžu byť on-line, ak to tak skupine vyhovuje)
  • každý týždeň sa každá skupina stretne s cvičiacim v termíne podľa dohody s cvičiacim, z týchto stretnutí píše zápisnicu cvičiaci, (tieto stretnutia môžu byť on-line, ak to tak skupine vyhovuje)

Literatúra

  • Materiál na zopakovanie
  • Tvorba informačných systémov 2016/2017
  • E.J.Braude, M.E.Bernstein: Software Engineering: Modern Approaches, Wiley, 2011
  • E.Gamma, R.Helm, R.Johnson, J.Vlissides: Design Patterns, Elements of Reusable Object-Oriented Software, Addison Wesley, 1995
  • M.Cade, H.Shell: Sun Certified Enterprise Architect for Java EE Study Guide, 2nd Edition, Prentice Hall, 2010.
  • Ľ.Šešera: Aplikačné architektúry softvérových systémov, STU, 2010
  • Ľ.Šešera, P.Grec, P.Návrat: Architektúra softvérových systémov - Architektúra internetových systémov a architektúra orientovaná na služby, STU, 2011
  • E.J.Braude: Software Engineering, An Object-Oriented Perspective, Wiley, 2001