m
m
Line 5: Line 5:
 
V projekte si vyskúšate ako vyzerá vývoj softvéru v tíme. Bude vám (s prihliadnutím na váš výber) pridelený projekt vývoja softvéru, ktorý niekto potrebuje naprogramovať. Ten človek sa volá '''zadávateľ'''. Ak tomu požiadavky zadávateľa nebudú brániť, projekt bude open-source. Okrem toho vám bude pridelený cvičiaci, ktorý bude sledovať váš pokrok na projekte každý týždeň. Vývoj bude prebiehať v týchto fázach:
 
V projekte si vyskúšate ako vyzerá vývoj softvéru v tíme. Bude vám (s prihliadnutím na váš výber) pridelený projekt vývoja softvéru, ktorý niekto potrebuje naprogramovať. Ten človek sa volá '''zadávateľ'''. Ak tomu požiadavky zadávateľa nebudú brániť, projekt bude open-source. Okrem toho vám bude pridelený cvičiaci, ktorý bude sledovať váš pokrok na projekte každý týždeň. Vývoj bude prebiehať v týchto fázach:
  
=== Špecifikácia ('''ČO''' bude aplikácia robiť) ===
+
=== Špecifikácia (<span style="color:blue">ČO</span> bude aplikácia robiť) ===
 
* kontaktovať zadávateľa a dohodnúť si s ním interview
 
* 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 tomto interview zistiť, čo presne tento človek potrebuje a zapísať si o tom poznámky
Line 12: Line 12:
 
* hlavný výstup: dokument Katalóg požiadaviek (uložený na githube spolu s kópiou potvrdenia od zadávateľa, že ho akceptuje)
 
* hlavný výstup: dokument Katalóg požiadaviek (uložený na githube spolu s kópiou potvrdenia od zadávateľa, že ho akceptuje)
  
=== Návrh ('''AKO''' sa aplikácia naprogramuje) ===
+
=== Návrh (<span style="color:blue">AKO</span> sa aplikácia naprogramuje) ===
 
* na základe Katalógu požiadaviek vypracujete návrh podľa ktorého sa bude dať aplikácia naprogramovať. Nemusí byť úplne potrebný, ale mal byť jasný a kompletný. Pri analýze systému si môžete pomôcť entitno-relačnými diagramami, use-case diagramami, stavovými diagramami, sekvenčnými diagramami - podľa dohody s cvičiacim aspoň jeden UML diagram zahrniete a na základe toho navrhnete používateľské rozhranie, ktoré skonzultujete so zadávateľom
 
* na základe Katalógu požiadaviek vypracujete návrh podľa ktorého sa bude dať aplikácia naprogramovať. Nemusí byť úplne potrebný, ale mal byť jasný a kompletný. Pri analýze systému si môžete pomôcť entitno-relačnými diagramami, use-case diagramami, stavovými diagramami, sekvenčnými diagramami - podľa dohody s cvičiacim aspoň jeden UML diagram zahrniete a na základe toho navrhnete používateľské rozhranie, ktoré skonzultujete so zadávateľom
 
* 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ť
 
* 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ť

Revision as of 09:08, 26 September 2017

Tvorba informačných systémov - projekt

naspäť na stránku predmetu


V projekte si vyskúšate ako vyzerá vývoj softvéru v tíme. Bude vám (s prihliadnutím na váš výber) pridelený projekt vývoja softvéru, ktorý niekto potrebuje naprogramovať. Ten človek sa volá zadávateľ. Ak tomu požiadavky zadávateľa nebudú brániť, projekt bude open-source. Okrem toho vám bude pridelený cvičiaci, ktorý bude sledovať váš pokrok na projekte každý týždeň. Vývoj bude prebiehať v týchto fázach:

Špecifikácia (ČO bude aplikácia 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)

Návrh (AKO sa aplikácia naprogramuje)

  • na základe Katalógu požiadaviek vypracujete návrh podľa ktorého sa bude dať aplikácia naprogramovať. Nemusí byť úplne potrebný, ale mal byť jasný a kompletný. Pri analýze systému si môžete pomôcť entitno-relačnými diagramami, use-case diagramami, stavovými diagramami, sekvenčnými diagramami - podľa dohody s cvičiacim aspoň jeden UML diagram zahrniete a na základe toho navrhnete používateľské rozhranie, ktoré skonzultujete so zadávateľom
  • 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
  • ideálne 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 nimi, tok dát môžete vizualizovať aj pomocou sekvenčných diagramov.
  • môžete vytvoriť triedny diagram, ktorý bude obsahovať všetky podstatné triedy aplikácie (v prípade webu všetky modely, viewy a kontrolery)
  • 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)

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á (inak projekt nebude uznaný!)
  • 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

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