Tvorba informačných systémov - o projektoch 2016/2017

1. špecifikácia (ČO bude program robiť)
   • kontaktovať zadávateľa a dohodnúť si s ním interview
   • na tomto interview zistiť, čo presne tento človek potrebuje a zapísať si o tom poznámky
   • na základe týchto poznámok vypracovať špecifikáciu projektu (tzv. Katalóg požiadaviek), ktorý svojmu zadávateľovi predložíte na schválenie, on sa k nemu vyjadrí a prípadné zmeny ešte pred jeho schválením zapracujete do špecifikácie (aj opakovane, kým projekt nie je schválený); katalóg požiadaviek pred zadávateľom musí odobriť aj váš cvičiaci.
   • špecifikácia je "technology-neutral", je písaná jazykom zrozumiteľným aj zadávateľovi a teda neobsahuje nič, čo patrí do návrhu
   • hlavný výstup: dokument Katalóg požiadaviek (uložený na githube spolu s kópiou potvrdenia od zadávateľa, že ho akceptuje)
   
   
2. návrh (AKO sa program naprogramuje)
   • na základe Katalógu požiadaviek vypracujete pomocou entitno-relačných diagramov, use-case diagramov, stavových diagramov a prípadne sekvenčných diagramov analýzu systému a na základe toho navrhnete používateľské rozhranie
   • analyzujete technológie, ktoré prichádzajú v projekte do úvahy - to znamená odskúšate či technologicky zvládate všetko, čo bude počas implementácie potrebné využiť a čo si program bude vyžadovať
   • vytvoríte dátový model - ak projekt bude využívať databázu, tak podrobný návrh databázy (ideálne diagram vyexportovaný priamo z databázy), okrem toho všetky ostatné dátové entity, s ktorými program bude pracovať a spôsoby ich reprezentácie
   • formou komponentného diagramu navrhnete dekompozíciu projektu na moduly (z hľadiska funkcionality), pomocou domain-level class diagramu balíčky (z hľadiska implementácie) a pomocou data-flow diagramu z hľadiska procesov a výmeny údajov medzi nimii, tok dát môžete vizualizovať aj pomocou sekvenčných diagramov.
   • vytvoríte triedny diagram, ktorý bude obsahovať všetky podstatné triedy aplikácie (v prípade webu všetky modely, viewy a kontrollery)
   • vypracujete testovacie scenáre, podľa ktorých neskôr otestujete funkcionalitu celej aplikácie, keď bude hotová
   • hlavný výstup: dokument Návrh (uložený na githube a schválený cvičiacim)
   
   
3. implementácia
   • postupne pridávaním samostatne otestovateľných čŕt softvéru naimplementujete potrebnú funkcionalitu
   • každú pridávanú časť si jej autor po sebe najskôr otestuje (podľa možnosti unit testami), predtým, ako ju pridá do celého projektu
   • zdrojové kódy budú obsahovať dokumentačné komentáre - pre všetky public metódy a premenné
   • každá nová funkcionalita sa pridáva na github, hneď keď je vyvinutá
   • pri písaní kódu sa usilujte dodržiavať zásady čistého kódu
   • hlavný výstup: skompilovateľný kompletný zdrojový kód, prešiel jednotkovými a základnými testami
   
   
4. nasadenie do prevádzky
   • realizovanie testov navrhnutých v testovacích scenároch, nainštalovanie na cieľové prostredie, ak k tomu ešte nedošlo a celkové dôkladné otestovanie aplikácie
   • a vykonanie úprav, ktoré si testy vyžiadajú
   • predvedenie prvej "finálnej" verzie cvičiacemu a potom zadávateľovi
   • zapracovanie pripomienok a požiadaviek od zadávateľa
   • odovzdanie hotovej verzie zadávateľovi
   • vypracovanie finálneho dokumentu "Technická dokumentácia" pozostávajúceho z aktualizovanej špecifikácie a návrhu
   • zhodnotenie celej tímovej práce na projekte
   • výstupy: technická dokumentácia a hotová aplikácia v prevádzke so zdrojákmi na Githube

• Tímy si vytvoríte samostatne, v každom tíme by mali byť 4 členovia. 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í:
  1. 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
  2. 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
  3. 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
  4. 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 nastaví 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.
• Každý tím sa každý týždeň stretáva na svojom tímovom stretnutí, prítomní sú všetci členovia tímu a na stretnutí hneď píše zápisnicu. Zápisnica je v taktomto formáte:
  1. dátum stretnuia
  2. zoznam prítomných
  3. agenda - zoznam bodov, ktoré treba prediskutovať/riešiť:
     • zhodnotenie predchádzajúceho obdobia - ako boli splnené naplánované úlohy, prečo splnené neboli, aké akcie sa preto dohodli vykonať
     • ...jednotlivé body agendy... (čo sa zistilo, našlo, dohodlo, naplánovalo, urobilo)
     • naplánovanie úloh na nasledujúce obdobie: čo sa urobí a kto bude za to zodpovedný
  Zápisnicu píše člen tímu zodpovedný za dokumentáciu (alebo iný člen tímu, ktorého poverí) priamo na stretnutí, je primárne určená pre vás, zapisujte si do nej všetky potrebné informácie, linky na informácie a dokumenty, formáty dát, všetko, čo ste dohodli na stretnutí a nie je uložené v nejakom dokumente. To, čo nie je zapísané v zápisnici, nie je záväzné. Zápisnicu nahrajte na Github hneď na konci stretnutia. Hoci je určená pre vás, zápisnicu čita aj váš cvičiaci, jednak aby sa stíhal orientovať vo vašom projekte a jednak, aby videl, ako práca na projekte napreduje.
• Okrem toho, každý tím sa každý týždeň stretáva na stretnutí so svojim cvičiacim (aspoň na 30 min). Stretnutie s cvičiacim prebieha takto:
  1. "stand up meeting" - každý člen tímu povie, čo on urobil od posledného stretnutia s cvičiacim, aké mal úlohy a ako to dopadlo, čo mu stojí v ceste, čo ho čaká ďalej, ktoré úlohy má pridelené do ďalšieho týždňa
  2. správa o celkovom pokračovaní projektu pre cvičiaceho
  3. spätná väzba od cvičiaceho o odovzdanej dokumentácii a pokračovaní projektu
  4. diskusia
  Cvičiaci na stretnutí skontroluje, že máte v poriadku zápisnice a robí si zo stretnutia záznamy, aby vedel, ako tím pokračuje a vedel referovat vyučujúcemu a tiež tím aj jednotlivcov zhodnotiť. Tím si z tohto stretnutia tiež robí zápisnicu, ktorú vyvesí na konci stretnutia na Github.
• Vývoj prebieha na verejnom konte na Githube v repozitári tímu, ktorý je súčasťou organizácie TIS2016. Do repozitára sa do priečinku "minutes" nahrávajú všetky zápisnice, do priečinku "documentation" všetky dokumenty, ktoré sú pripravené na odovzdanie a do priečinku "src" sa nahrávajú zdrojové súbory, ktoré sú skompilovateľné - nielen výsledné hotové programy, ale každá nová verzia akéhokoľvek súboru, ktorý niekto v tíme dokončí. S Gitom, Githubom a Zenhubom sa všetci naučia pracovať na prvom cvičení, ktoré je povinné. Na úložisko vyvíjanej verzie softvéru tím nepoužíva nič iné ako svoj tímový Github repozitár.

• Špecifikácia 20.9. - 11.10.
  • do 24.9. vytvorenie skupiny na portáli pre výber projektov a zadanie výberu tém
  • 26.9. priradenie projektov k skupinám
  • do 4.10. plán projektu vo forme Ganttovho diagramu
  • do 11.10. katalóg požiadaviek
  
  
• Návrh 12.10. - 8.11.
  • do 18.10. entitno relačný diagram, use-case diagramy, stavové diagramy sekvenčné diagramy
  • do 25.10. zadávateľom odsúhlasené používateľské rozhranie, analýza technológií, dátový model, dekompozícia
  • do 01.11. triedny diagram
  • do 08.11. testovacie scenáre a skompletizovaný návrh
  
  
• Implementácia 9.11. - 9.12.
  • 15.11. Na Githube sú naimplementované prvé features, ktoré fungujú a niečo robia
  • 22.11. Na Githube sú naimplementované skoro všetky features, ktoré sa testujú
  • 29.11. Celý projekt sa dá "skompilovať", spustiť a testuje sa
  • 6.12. Základná funkcionalita podľa Katalógu požiadaviek je pripravená na finálne testovanie a odovzdávanie
  
  
• Nasadenie do prevádzky 10.12. - 15.1.
  • do Vianoc: zadávateľ videl prvú hotovú verziu aplikácie
  • do 10.1. Zapracovaná spätná väzba od zadávateľa
  • do 15.1. Aktualizovaná finálna technická dokumentácia a výsledný zdrojový kód