d
d
 
(130 intermediate revisions by the same user not shown)
Riadok 4: Riadok 4:
 
}}
 
}}
  
 +
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.
+
Okrem toho sa študenti na samostatných prednáškach zaoberajú etickými a spoločenskými aspektami informatiky (1) a získavajú informácie o základoch podnikania a vytváraní startupov (2). V časti (1) odovzdávajú vypracovaný referát - informácie poskytuje vyučujúci Michal Winczer, v časti (2) je účasť na prednáškach povinná, v opačnom prípade študent vypracuje referát.
  
 +
* '''utorok, 8:10, miestnosť A'''
 +
* '''streda, 8:10, miestnost B - tieto budú iba vtedy, ak to bude vopred avizované!!'''
  
 
== Kontakt ==
 
== Kontakt ==
  
 
Pavel Petrovič, pavel.petrovic[[Image:zavinac.gif|@]]fmph.uniba.sk<br>
 
Pavel Petrovič, pavel.petrovic[[Image:zavinac.gif|@]]fmph.uniba.sk<br>
Andrej Jursa, andrej.jursa[[Image:zavinac.gif|@]]fmph.uniba.sk<br>
+
Ivan Polášek, ipo[[Image:zavinac.gif|@]]gratex.com<br>
e-mail: tis-team[[Image:zavinac.gif|@]]lists.dai.fmph.uniba.sk  
+
Michal Winczer, winczer[[Image:zavinac.gif|@]]fmph.uniba.sk<br>
 
+
<!-- e-mail: tis-team[[Image:zavinac.gif|@]]lists.dai.fmph.uniba.sk -->
  
 
== Projekty ==
 
== Projekty ==
  
 
* [[Course:Information Systems Development - Projekty/sk|plán]]
 
* [[Course:Information Systems Development - Projekty/sk|plán]]
* [http://kempelen.ii.fmph.uniba.sk/vyber/public/projects Projekty a skupiny]
+
* [http://dai.fmph.uniba.sk/courses/tvorbaIS/skupiny_tis_2023.txt skupiny]
* [[Course:Information Systems Development - Priradení cvičiaci/sk|priradení cvičiaci]]
+
* [https://dai.fmph.uniba.sk/courses/tvorbaIS/projekty2023.pdf projekty]
 
+
<!-- * [[Course:Information Systems Development - Priradení cvičiaci/sk|priradení cvičiaci]] -->
  
 
== 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 2.10.</span>
+
'''1. Prihláška na projekty''', <span style="color:green">čím skôr po zverejnení projektov, najneskôr 22.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 17. 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. Pred tým, ako sa posiela návrh katalógu požiadaviek zadávateľovi, ho musí schváliť cvičiaci.  
  
'''3. Návrh''', <span style="color:green">všetko hotovo najneskôr do 14.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ť aspoň jeden relevantný UML diagram, podľa dohody s cvičiacim, zrozumiteľne vysvetlenú architektúru, rozdelenie na časti, 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 (nie nutne v tomto poradí a tejto štruktúre!): <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 (napr. [https://www.youtube.com/watch?v=2pxVCzRFGeg pgadmin]), 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. <br>E. Plán implementácie - v akom poradí sa budú implementovať, testovať a navzájom spájať jednotlivé komponenty.
  
'''4. Testovacie scenáre''',  <span style="color:green">28. 11. 2017</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. Dokument využijete na to, aby ste skontrolovali, že všetko, čo má byť hotové je implementované a funguje. Neslúži na podrobné testovanie všetkých prípadov - na to je vhodné vytvárať jednotkové testy, ktoré sa dajú zbehnúť. Typický príklad: jeden scenár pozostáva z 12 krokov, ktoré definujú čo má používateľ urobiť a s akými dátami to má urobiť (napr. ak vkladá nové údaje cez nejaký formulár), v každom kroku je 1) akcia - čo má používateľ spraviť a 2) výsledok - ako na to reaguje systém, čo sa má udiať. Takýto scenár pokryje napr. 25% funkcionality požadovanej v KP. Ďalší takýto scenár pokryje najekých 30% požiadaviek s tým, že má s prvým scenárom prekryv 7%, atď, až kým všetky scenáre dokopy nepokryjú celú funkcionalitu. Scenáre by mali byť písané tak, aby ich dokázal vykonať vývojový tím, nie nejaký externý prizvaný tester.
  
'''5. Otestovaný hotový zdrojový kód''', <span style="color:green">23. 12. 2017</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.
  
'''6. Technická dokumentácia a výsledný zdrojový kód''', <span style="color:green">31. 1. 2018</span>
+
'''6. Technická dokumentácia a výsledný zdrojový kód''', <span style="color:green">17. 1.</span>
  
 
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.  
 
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.  
  
 +
'''7. Prezentácia vytvoreného diela''' - 3-5 minutové video, v ktorom predvediete, čo aplikácia robí a ako bola navrhnutá a implementovaná. Video je určené na zdieľanie výsledkov práce s ostatnými skupinami v tomto predmete, <span style="color:green">do konca skúškového obdobia</span>. Na vytvorenie videa prosím použite [https://obsproject.com/ OBS Studio], pred nahrávaním si urobte pár poznámok, čo idete povedať/ukázať a popripravujte si jednotlivé stránky/dialógy/diagramy/atď, ktoré poukazujete.
  
 
== Hodnotenie ==
 
== Hodnotenie ==
  
 
# Projekt:  50b
 
# Projekt:  50b
# Písomky: 35b [http://dai.fmph.uniba.sk/courses/tvorbaIS/prvy_test.png prvá], [http://dai.fmph.uniba.sk/courses/tvorbaIS/druhy_test.png druhá], [http://dai.fmph.uniba.sk/courses/tvorbaIS/sien_slavy_po_druhej.png po druhej], [http://dai.fmph.uniba.sk/courses/tvorbaIS/midterm.png midterm], [http://dai.fmph.uniba.sk/courses/tvorbaIS/treti_test.png tretia], [http://dai.fmph.uniba.sk/courses/tvorbaIS/sien_po_tretej.png po tretej], [http://dai.fmph.uniba.sk/courses/tvorbaIS/stvrty_test.png štvrtá], [http://dai.fmph.uniba.sk/courses/tvorbaIS/sien_po_stvrtej.png po štvrtej], [http://dai.fmph.uniba.sk/courses/tvorbaIS/piaty_test.png piata], [http://dai.fmph.uniba.sk/courses/tvorbaIS/sien_po_piatej.png po piatej], [http://dai.fmph.uniba.sk/courses/tvorbaIS/siesty_test.png šiesty], [http://dai.fmph.uniba.sk/courses/tvorbaIS/sien_po_siestej.png sieň slávy]
+
# Besiedky: 35b <!--, sieň slávy: [[Media:sien_tis2020_01.png|requirements engineering]], [[Media:sien_tis2021_02.png|models of IS development]], [[Media:sien_tis2021_03.png|introduction to design]]  -->
# Midterm (UML diagramy) 13.11. miestnosť B, 14:00-16:30: 15b, 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/diagramy/ vzorové riešenie z predchádzajúceho roka]. Najlepší spôsob prípravy na midterm je vyriešiť [[cvicne zadanie midtermu TIS|cvičné zadanie]] a poslať mi riešenie do nedele 18:00, dám Vám k nemu ešte spätnú väzbu.
+
# <!-- 23. nov. 2021 11:00-13:00 --> Midterm (UML diagramy): 15b, <!-- výsledky: [[Media:midterm_tis_2021.png|graf]]<br> --> [http://dai.fmph.uniba.sk/courses/tvorbaIS/midterm2019.pdf príklad], <!-- ([http://dai.fmph.uniba.sk/courses/tvorbaIS/2019/midterm2019.png výsledky]), -->pozri iný 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]] - ďalšie tri nájdete v LISTe 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 besiedky, 10b za midterm, potom: 90-100: A, 83-90: B, 74-82: C, 65-73: D, 55-64: E, < 55: Fx.
  
 +
35 bodov za besiedky 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 20 (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 25 (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, besiedky sa budú konať nejakou inou formou, ktorú v tom prípade upresníme.
  
 
== Pravidlá ==
 
== 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
+
* 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 aj do dokumentácie
 
* každá skupina musí odovzdať všetky výstupy načas  
 
* 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)
 
* 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)
Riadok 68: Riadok 77:
 
** prvým bodom agendy je zhodnotenie vykonanej práce a splnených úloh od predchádzajúceho stretnutia tímu
 
** 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ý
 
** 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, agenda slúži predovšetkým členom tímu na organizáciu ich práce!
+
** '''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 ==
 
== Roly členov tímu ==
Riadok 81: Riadok 89:
  
 
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.  
 
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 ==
 
== Prednášky ==
  
* 26.09. Úvodná prednáška, plán na semester
+
* 19.09. Úvodná prednáška, plán na semester
* 03.10. [http://dai.fmph.uniba.sk/courses/tvorbaIS/sl/tis2new.pdf Špecifikácia], z [http://dai.fmph.uniba.sk/courses/tvorbaIS/tis/new.html materiálov] sme prebrali kap. 0 - 1.4; 2. (treba sa to do budúcej prednášky naučiť)
+
* 26.09. Requirements Engineering, z materiálov 1.1. - 1.3 a všetky 2.*
* 10.10. [https://tis.easyproject.cz Gantt] ([http://dai.fmph.uniba.sk/courses/tvorbaIS/sl/gantt_example.pdf príklad]), [http://dai.fmph.uniba.sk/courses/tvorbaIS/sl/tis3new.pdf Modely vývoja sw], [http://dai.fmph.uniba.sk/courses/tvorbaIS/sl/use_cases.pdf Use Case Diagramy]
+
* 03.10. Fázy a modely vývoja IS, z materiálov všetky zvyšné 1.*
* 17.10. [http://dai.fmph.uniba.sk/courses/tvorbaIS/sl/tis4new.pdf Návrh a UML], nabudúce treba vedieť nakresliť Ganttov diagram, poznať základné modely vývoja sw, ich výhody a nevýhody, ciele pri návrhu IS, vedieť nakresliť ERD opisujúci doménu IS, vysvetliť základné princípy OOP a objektovú normalizáciu. Z [http://dai.fmph.uniba.sk/courses/tvorbaIS/tis/new.html materiálov] sú to state 1.5. - 1.6.8., 3.0, 4 - 4.4.2.
+
* 10.10. Use-case diagram a úvod do návrhu, z materiálov  3.0, 3.1, 3.10. 4., (4.1. nie), 4.2, 4.3, 4.4.1
* 24.10. pozvaná prednáška: Tomáš Kulich: [http://dai.fmph.uniba.sk/courses/tvorbaIS/sl/Architecture.pdf Ako robiť architektonické rozhodnutia], Vacuum Labs, určite prídite!
+
* 17.10. Dokončenie návrhu a architektonické štýly  4.1., 4.4.2, 4.5.
* 7.11. UML na príklade
+
* 24.10. UML
* 13.11. miestnost B, 14:00-16:30, midterm, 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/diagramy/ vzorové riešenie z predchádzajúceho roka]. Najlepší spôsob prípravy na midterm je vyriešiť [[cvicne zadanie midtermu TIS|cvičné zadanie]] a poslať mi riešenie do nedele 18:00, dám Vám k nemu ešte spätnú väzbu.
+
* 31.10. Návrhové vzory - creational, structural (kvíz až 14.11.), z materiálov 5.1, 5.2 (odporúčam knihu Design Patterns)
* 14.11. [http://dai.fmph.uniba.sk/courses/tvorbaIS/sl/tis5new.pdf Architektúra a návrhové vzory], na najbližšej prednáške treba  ovládať state 4.5., 5., 5.1. a 5.2. z [http://dai.fmph.uniba.sk/courses/tvorbaIS/tis/new.html#arch materiálov]. Behavioral patterns doberieme 21.11. Vypočujte si kvalitnú prednášku Jonasa Bonera: [https://event.on24.com/wcc/r/1531494/30341ECC392F9574909EB139EC0FF1CB?partnerref=LC Reactive Microsystems - The Evolution of Microservices at Scale]
+
* 7.11. Midterm (UML)
* 21.11. Behavioral patterns a [http://dai.fmph.uniba.sk/courses/tvorbaIS/sl/tis6.pdf Integrácia aplikácií]. Na prednáške 5.12. treba ovládať state 5.3. a 6. z [http://dai.fmph.uniba.sk/courses/tvorbaIS/tis/new.html#behavioral materiálov] od 6.1. budeme pokračovať  až 5.12.
+
* 14.11. Návrhové vzory - behavioral, z materiálov 5.3
* 28.11. Daniel Buchta: Data experience, pozvaná prednáška v podaní popredných expertov spoločnosti Softec, určite prídite!<br>Program: Čo je BIG DATA, História, technológie a trendy, BIG DATA vs. SQL, Architektúra, Technológie. (''Bude to Big Data prednáška v ktorej budú trendy moderných frontendov a napojednie týchto trendov moderných frontendov s Big Data'')
+
* 21.11. Čistý kód (úvod) - kvíz nie, iba domáce zadanie
* 5.12. Rôzne spôsoby klasifikácie integrácie aplikácií, Agilné metódy vývoja softvéru, state [http://dai.fmph.uniba.sk/courses/tvorbaIS/tis/new.html#klas 6.1. - 6.3. a 9. z materiálov]. Pozrite si [https://www.youtube.com/watch?v=ffkIQrq-m34 zaujímavú prednášku prof. Meyera], v ktorej hodnotí myšlienky agilných metód.
+
* 28.11. Integrácia aplikácií a čistý kód (jadro) - kvíz až 12.12. (Integrácia + Agilné metódy, podľa materiálov 6.* a 9.*)
* 12.12. [http://dai.fmph.uniba.sk/courses/tvorbaIS/sl/tis9.pdf Čistý kód]. Treba vedieť uvedené princípy aplikovať v praxi.
+
* 29.11. Skúsenosti zakladateľov softvérovej firmy: Photoneo, Skelletex (Martin Madaras, Michal Malý)
 +
* 5.12. Pozvaná prednáška: Ján Ružarovský - SAP Labs Slovakia: Agilné metódy vývoja SW
 +
* 6.12. Skúsenosti zakladateľov softvérovej firmy: UI42 (Martin Krupa, Robert Mráz)
 +
* [[Course:Information_Systems_Development_Lectures2017/sk|minulá sezóna]]
  
 
== Cvičenia ==
 
== Cvičenia ==
  
* 29.09. [http://dai.fmph.uniba.sk/courses/tvorbaIS/ex/git/new.html cvičenie github] na H6, 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: [https://dai.fmph.uniba.sk/courses/tvorbaIS/ex/git/newer.html zadanie]
* 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 ==
  
* [http://dai.fmph.uniba.sk/courses/tvorbaIS Tvorba informačných systémov 2016/2017]
+
* [http://dai.fmph.uniba.sk/courses/tvorbaIS/tis/new.html Materiál na zopakovanie]
 
* E.J.Braude, M.E.Bernstein: Software Engineering: Modern Approaches, Wiley, 2011
 
* 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
 
* E.Gamma, R.Helm, R.Johnson, J.Vlissides: Design Patterns, Elements of Reusable Object-Oriented Software, Addison Wesley, 1995
Riadok 112: Riadok 124:
 
* Ľ.Š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š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
 
* E.J.Braude: Software Engineering, An Object-Oriented Perspective, Wiley, 2001
 +
* Čistý kód / Robert C. Martin ; překlad Jiří Berka. Brno : Computer Press, 2009
 +
* Jacobsen et al: The Essentials of Modern Software Engineering, Association for Computer Machinery and Morgan & Claypool Publishers, 2019.
 +
 +
=== Spätná väzba ===
 +
 +
* je vítaná
 +
* kedykoľvek na MS Teams - osobne alebo v skupine
 +
* aj počas semestra môžete použiť aj tento formulár: [https://dai.fmph.uniba.sk/courses/tvorbaIS/feedback.html?predmet=tis feedback]
 +
* anketu vzhľadom na to, že je anonymná a zároveň verejná (buď jedno alebo druhé - naraz to nefunguje) a preto obshuje nepravdivé, manipulatívne ba až škodlivé príspevky odtrhnuté z reťaze a od reality, navyše v čase keď už pre Vás nič nemôže zmeniť, nečítam a odporúčam to isté aj Vám.
  
 
__NOTOC__
 
__NOTOC__

Aktuálna revízia z 22:39, 16. február 2024

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.

Okrem toho sa študenti na samostatných prednáškach zaoberajú etickými a spoločenskými aspektami informatiky (1) a získavajú informácie o základoch podnikania a vytváraní startupov (2). V časti (1) odovzdávajú vypracovaný referát - informácie poskytuje vyučujúci Michal Winczer, v časti (2) je účasť na prednáškach povinná, v opačnom prípade študent vypracuje referát.

  • utorok, 8:10, miestnosť A
  • streda, 8:10, miestnost B - tieto budú iba vtedy, ak to bude vopred avizované!!

Kontakt

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

Projekty

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

1. Prihláška na projekty, čím skôr po zverejnení projektov, najneskôr 22.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. Pred tým, ako sa posiela návrh katalógu požiadaviek zadávateľovi, ho musí schváliť cvičiaci.

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 (nie nutne v tomto poradí a tejto štruktúre!):
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 (napr. pgadmin), 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.
E. Plán implementácie - v akom poradí sa budú implementovať, testovať a navzájom spájať jednotlivé komponenty.

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. Dokument využijete na to, aby ste skontrolovali, že všetko, čo má byť hotové je implementované a funguje. Neslúži na podrobné testovanie všetkých prípadov - na to je vhodné vytvárať jednotkové testy, ktoré sa dajú zbehnúť. Typický príklad: jeden scenár pozostáva z 12 krokov, ktoré definujú čo má používateľ urobiť a s akými dátami to má urobiť (napr. ak vkladá nové údaje cez nejaký formulár), v každom kroku je 1) akcia - čo má používateľ spraviť a 2) výsledok - ako na to reaguje systém, čo sa má udiať. Takýto scenár pokryje napr. 25% funkcionality požadovanej v KP. Ďalší takýto scenár pokryje najekých 30% požiadaviek s tým, že má s prvým scenárom prekryv 7%, atď, až kým všetky scenáre dokopy nepokryjú celú funkcionalitu. Scenáre by mali byť písané tak, aby ich dokázal vykonať vývojový tím, nie nejaký externý prizvaný tester.

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, 17. 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.

7. Prezentácia vytvoreného diela - 3-5 minutové video, v ktorom predvediete, čo aplikácia robí a ako bola navrhnutá a implementovaná. Video je určené na zdieľanie výsledkov práce s ostatnými skupinami v tomto predmete, do konca skúškového obdobia. Na vytvorenie videa prosím použite OBS Studio, pred nahrávaním si urobte pár poznámok, čo idete povedať/ukázať a popripravujte si jednotlivé stránky/dialógy/diagramy/atď, ktoré poukazujete.

Hodnotenie

  1. Projekt: 50b
  2. Besiedky: 35b
  3. Midterm (UML diagramy): 15b, príklad, pozri iný 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 - ďalšie tri nájdete v LISTe 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 besiedky, 10b za midterm, potom: 90-100: A, 83-90: B, 74-82: C, 65-73: D, 55-64: E, < 55: Fx.

35 bodov za besiedky 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 20 (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 25 (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, besiedky sa budú konať nejakou inou formou, ktorú v tom prípade upresníme.

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 aj do dokumentácie
  • 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

  • 19.09. Úvodná prednáška, plán na semester
  • 26.09. Requirements Engineering, z materiálov 1.1. - 1.3 a všetky 2.*
  • 03.10. Fázy a modely vývoja IS, z materiálov všetky zvyšné 1.*
  • 10.10. Use-case diagram a úvod do návrhu, z materiálov 3.0, 3.1, 3.10. 4., (4.1. nie), 4.2, 4.3, 4.4.1
  • 17.10. Dokončenie návrhu a architektonické štýly 4.1., 4.4.2, 4.5.
  • 24.10. UML
  • 31.10. Návrhové vzory - creational, structural (kvíz až 14.11.), z materiálov 5.1, 5.2 (odporúčam knihu Design Patterns)
  • 7.11. Midterm (UML)
  • 14.11. Návrhové vzory - behavioral, z materiálov 5.3
  • 21.11. Čistý kód (úvod) - kvíz nie, iba domáce zadanie
  • 28.11. Integrácia aplikácií a čistý kód (jadro) - kvíz až 12.12. (Integrácia + Agilné metódy, podľa materiálov 6.* a 9.*)
  • 29.11. Skúsenosti zakladateľov softvérovej firmy: Photoneo, Skelletex (Martin Madaras, Michal Malý)
  • 5.12. Pozvaná prednáška: Ján Ružarovský - SAP Labs Slovakia: Agilné metódy vývoja SW
  • 6.12. Skúsenosti zakladateľov softvérovej firmy: UI42 (Martin Krupa, Robert Mráz)
  • minulá sezóna

Cvičenia

  • prvé cvičenie (github) je domáca úloha, ktorú riešite po skupinách: zadanie
  • 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
  • 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
  • Čistý kód / Robert C. Martin ; překlad Jiří Berka. Brno : Computer Press, 2009
  • Jacobsen et al: The Essentials of Modern Software Engineering, Association for Computer Machinery and Morgan & Claypool Publishers, 2019.

Spätná väzba

  • je vítaná
  • kedykoľvek na MS Teams - osobne alebo v skupine
  • aj počas semestra môžete použiť aj tento formulár: feedback
  • anketu vzhľadom na to, že je anonymná a zároveň verejná (buď jedno alebo druhé - naraz to nefunguje) a preto obshuje nepravdivé, manipulatívne ba až škodlivé príspevky odtrhnuté z reťaze a od reality, navyše v čase keď už pre Vás nič nemôže zmeniť, nečítam a odporúčam to isté aj Vám.