Možnosť stiahnutia dokumentácie.

Kliknutie na tlačidlo DownLoad umôžuje stiahnuť zbalenú dokumentáciu (*.ZIP) napísanú v MS Word verzia 8.0 .



Užívateľská príručka


Možnosť stiahnutia kompletnej dokumentácie za zimný a letný semester.

Kliknutie na tlačidlo DownLoad umôžuje stiahnuť zbalenú dokumentáciu (*.ZIP) napísanú v MS Word verzia 8.0 (dokumentácia obsahuje viacero súborov zbalených do jedného *.ZIP).


 

Slovenská technická univerzita

Katedra informatiky a výpočtovej techniky, Fakulta elektrotechniky a informatiky

lkovičova 3, 812 19 Bratislava

 

 

 

 

Vysokoškolský rozvrh

 

 

Dokumentácia

 

Podrobná špecifikácia požiadaviek a hrubý návrh

 

 

 

 

Tím 4

 

Andrej Haršáni

Alexander Ješenko

Martin Mišák

Rastislav Samák

Juraj Schindler

 

 

 

 

 

  • Obsah

    •  

    0. Obsah *

    1. Úvod *

    2. Plán projektu *

    3. Analýza požiadaviek *

    3.1 Analýza systému č.2 *

    3.1.1 Recenzia etapy - analýza systému č.2 *

    3.1.1.1 Kontext systému (DFD) *

    3.1.1.2 Špecifické funkcie systému (definícia požiadaviek) *

    3.1.1.3 Špecifikácia údajov v systéme *

    3.1.1.4 Špecifikácia správania sa systému *

    3.1.1.5 Opis a príručka ku prototypu *

    3.1.2 Recenzia etapy - návrh systému č.2 *

    3.1.2.1 Architektúra systému *

    3.1.2.2 Návrh systému (DFD) *

    3.1.2.3 Spôsob implementácie a jej ohraničenia *

    3.1.2.4 Fyzický návrh databázy *

    3.1.2.5 Príručka štýlu programovania *

    3.1.3 Recenzia etapy - implementácia systému č.2 *

    3.2 Analýza systému č.1 *

    3.2.1 Recenzia etapy – analýza systému č.1 *

    3.2.2 Recenzia etapy - návrh systému č.1 *

    3.2.3 Recenzia etapy – implementácia systému č.1 *

    3.2.3.1 Databázový prostriedok *

    3.2.3.2 Programovací prostriedok *

    3.3 Analýza súčasného stavu *

    3.3.1 Výber predmetov a tvorba semestrového rozvrhu *

    3.3.2 Tvorba rozvrhu skúšok *

    3.4 Analýza požadovaných rozšírení *

    3.4.1 Prebrané požiadavky *

    3.4.2 Požadované rozšírenia *

    4. Koncept systému *

    4.1 Kontextový diagram tokov údajov *

    4.2 Opis externých entít: *

    4.3 Opis údajových tokov: *

    5. Špecifikácia funkcií systému *

    5.1 Špecifikácia funkcionálnych požiadaviek *

    5.1.1 Požiadavky na spracovanie rozvrhu skúšok *

    5.1.2 Požiadavky na priame spracovanie rozvrhu *

    5.1.3 Požiadavky na zapisovanie predmetov študentmi *

    5.1.4 Požiadavky na prihlasovanie predmetov učiteľmi *

    5.1.5 Požiadavky na prepojenie systému so vstupmi z existujúceho informačného systému *

    5.1.6 Požiadavky na výstupy systému *

    5.2 Špecifikácia funkcií *

    5.2.1 Funkcie na manipuláciu so všeobecnými údajmi *

    5.2.2 Funkcie na podporu vytvárania rozvrhu skúšok *

    5.2.3 Funkcie na podporu vytvárania semestrového rozvrhu *

    5.2.4 Funkcie systému na manipuláciu so študijnými plánmi *

    6. Špecifikácia údajov v systéme *

    6.1 Logický model údajov. *

    6.2 Opis údajových entít *

    7. Špecifikácia správania systému *

    7.1 Editovanie požiadaviek na predmet *

    7.2 Editovanie rozvrhu *

    7.3 Editovanie rozvrhu skúšok *

    7.4 Kontrola kolízií v rozvrhu skúšok *

    7.5 Porovnávanie rozvrhu s požiadavkami na predmety *

    7.6 Editovanie a výber študijného plánu *

    7.7 Kontrola vyplneného študijného plánu *

    7.8 Záverečná kontrola vyplnených študijných plánov *

    7.9 Prezeranie nevyplneného študijného plánu *

    7.10 Automatická kontrola kolízií v rozvrhu *

    7.11 Import údajov *

    7.12 Editovanie údajov *

    7.13 Výstup na WWW *

    7.14 Export údajov *

    8. Ďalšie požiadavky a ohraničenia *

    8.1 Požiadavky *

    8.1.1 Generovanie rozvrhu *

    8.1.2 Hromadné spracovanie údajov *

    8.1.3 Požiadavky na prevádzku systému *

    8.2 Ohraničenia *

     

     

     

     

     

    1. Úvod

      2.  

       

      Vytváraný systém - Vysokoškolský rozvrh, má slúžiť ako podpora pre tvorbu rozvrhu na katedrovej i fakultnej úrovni. Snahou je odstrániť alebo aspoň zredukovať množstvo papierovej práce, ktorá je v súčasnosti s tvorbou rozvrhu spojená, automaticky vykonávať kontrolu možných kolízií...

      Systém nadväzuje na už existujúci produkt – ”Katedrový informačný systém: Spracovanie katedrového rozvrhu”, ktorý bol vytváraný v roku 1998/1999 ako tímový projekt a ktorý v sebe zahŕňal správu učiteľov, študentov, miestností, predmetov. Umožňoval vytvárať rozvrh, avšak s ohraničením, že rozvrh sa vytvoril iba pre jeden týždeň a ten bol potom rovnaký pre všetky týždne semestra.

      Cieľom nového systému je podporiť tvorbu rozvrhu aj s možnosťou zmien v jednotlivých týždňoch semestra, poskytnúť nástroje pre tvorbu rozvrhu skúšok. Systém bude navyše umožňovať vytváranie študijných plánov pre jednotlivé formy štúdia a následné prihlasovanie študentov na predmety.

      Keďže systém nadväzuje na predchádzajúci projekt a má prebrať i jeho vlastnosti, je platformovo nezávislý, čo je zabezpečené technológiou WWW. Je snaha zachovať i jednoduché ovládanie, keďže ho budú používať viaceré skupiny používateľov (napr. prváci sa budú musieť prihlásiť na predmety => dôraz na jednoduchosť).

       

      Riešiteľský kolektív:

       

      Bc. Andrej Haršáni

      Bc. Alexander Ješenko

      Bc. Martin Mišák

      Bc. Rastislav Samák

      Bc. Juraj Schindler

       

       

       

    2. Plán projektu

     

     

    Týž

    Stret

    Činnosť, Úlohy

    Osoby

    1.

    		  

    Ponuka (vytvorenie a nahlásenie tímov, zverejnenie tém a požiadaviek na vypracovanie ponuky)

    všetci

    2.

     

    Účasť na prezentáciách jednotlivých tém

    Spracovanie ponuky

    všetci

    Mišák, Samák

    3.

    		  

    Účasť na prezentáciách ponúk

    Odovzdanie a prezentácia ponuky

    všetci

    Mišák

    4.

    		  

    Účasť na vyhodnotení ponúk, dohodnutie času stretnutí s pedagogickým vedúcim

    všetci

    5.

    1.

    Rozdelenie funkcií v tíme.

    Vytvorenie tímovej WWW stránky

    Štúdium existujúcich systémov s danou problematikou:

    • projekt vytvorený tímom č.1.

     

    • projekt vytvorený tímom č.2

     

    všetci

    Samák

     

    Mišák, Schindler

     

    Ješenko, Haršáni, Samák

    6.

    2.

    Vytvorenie dokumentácie analýzy existujúcich systémov:

    • projekt vytvorený tímom č.1 - analýza, návrh
    • - implementácia
    • projekt vytvorený tímom č.2 - analýza
    • - návrh
    • - implementácia

    Naštudovanie požadovaných rozšírení systému a vytvorenie predbežného hrubého návrhu:

    • zadávanie požiadaviek na predmet, evidencia rozdielneho rozvrhu pre rôzne týždne semestra
    • tvorba a vyplňovanie študijného plánu
    • tvorba rozvrhu skúšok

     

    Schindler

    Mišák

    Haršáni

    Ješenko

    Samák

     

     

    Mišák, Samák

     

    Ješenko, Schindler

    Haršáni

    7.

    3.

    Kompletná rekonštrukcia tímovej WWW stránky.

    Vytvorenie dokumentácie k odovzdaniu na posudok:

    • Úvod, Ďalšie požiadavky a ohraničenia
    • Plán projektu (dopracovanie), Analýza súčasného stavu
    • Analýza požiadaviek rozšírení
    • Kontextový diagram
    • Špecifikácia funkcií, údajov, správania systému

    Samák

     

    Schindler

    Mišák

    Haršáni

    Ješenko

    všetci (každý svoju pridelenú časť)

    8.

    4.

    Sumarizovanie dokumentácie a príprava na odovzdanie.

    Odovzdanie dokumentácie na posúdenie inému tímu.

    Prebratie práce iného tímu na posúdenie.

    Rozdelenie práce iného tímu na časti k posúdeniu jednotlivými členmi tímu:

    všetci

    Mišák

    Mišák

     

    9.

    5.

    Odovzdanie posudku špecifikácie a hrubého návrhu iného tímu

    		  

    10.

    6.

    Dopracovanie zistených nedostatkov a návrh prototypu vybraných častí

    		  

    11.

    7.

    Implementácia prototypu vybraných častí

    		  

    12.

    8.

    Odovzdanie prototypu vybraných častí systému spolu s dokumentáciou a používateľská prezentácia prototypu

    		  

     

     

     

     

    1. Analýza požiadaviek

     

    Pri riešení nášho projektu budeme vychádzať z riešení dvoch projektov, ktoré boli vypracované minulý rok a zo súčasného stavu realizácie rozvrhu. Našou úlohou je na základe analýzy týchto systémov

     

      1. Analýza systému č.2

        2.  

        Systém č.2 je produkt s názvom Katedrový informačný systém – Spracovanie katedrového rozvrhu, ktorý bol vypracovaný v školskom roku 1998/1999 tímom v zložení:

        Bc. Martin Kužela

        Bc. Marek Trabalka

        Bc. Jozef Végh

        Bc. Peter Veres

        Bc. Milan Vojvoda

        Kompletná dokumentácia k produktu a projektu bude prílohou tejto dokumentácie.

        1. Recenzia etapy - analýza systému č.2

          2. Dokument analýzy bol rozdelený do týchto častí:

           

          Kontext systému (DFD)

          Špecifické funkcie systému (definícia požiadaviek)

          Špecifikácia údajov v systéme

          Špecifikácia správania sa systému (špecifikácia požiadaviek)

          Opis a príručka ku prototypu

          1. Kontext systému (DFD)

     

    Kontextový diagram a tiež diagram nultej úrovne je navrhnutý prehľadne a zrozumiteľne. Popis externých entít, procesov a úložísk údajov je jasný. Chýba popis dátových tokov.

     

    Z diagramu nultej úrovne vyplýva, že užitočnosť tohoto systému je obmedzená na:

    pričom údaje potrebné na túto činnosť sa získavajú čiastočne pomocou importovania z existujúcich systémov alebo pracným editovaním, ktoré v systéme vykonáva externá entita Sekretárka katedry. Týmto pracným editovaním mám na mysli zapisovanie predmetov študentov, ktoré úzko súvisí z tvorbou rozvrhu.

    Zhodnotenie:

    Navrhnúť proces Zapisovanie predmetov. Dáta, ktoré vyjadrujú zapísané predmety študenta sa budú získavať tým, že entita Študent ich naplní.

     

          1. Špecifické funkcie systému (definícia požiadaviek)

     

    V časti definícia požiadaviek sú uvedené len funkcionálne požiadavky v hierarchickej úrovni. Chýbajú požiadavky na prevádzku systému.

    Zadefinované funkcionálne požiadavky sú obmedzené na minimálnu funkčnosť:

     

    Zhodnotenie:

    Funkcionálne požiadavky na systém sa preberú aby bola zachovaná minimálna funkčnosť a vhodne rozšíria v dokumente definícia požiadaviek

     

    V časti analýza súčasného stavu je opísaný postup vytvárania rozvrhu, ktorý sa ešte stále používa. Je uvedený aj formulár o predmete a jeho popis. Časť analýza súčasného stavu je nevhodne zaradená do dokumentu. Mala by byť v časti analýza požiadaviek a nie v časti špecifické funkcie systému.

     

    Nie je jasné:

     

    Zhodnotenie:

    Treba získať doplňujúce informácie o súčasnom postupe vytvárania rozvrhu a na základe toho určiť nové požiadavky na systém. Jednou z možností je vkladanie formulárov o predmete priamo do databázy systému externou entitou Učiteľ.

     

    V časti špecifikácia funkcionálnych požiadaviek sú požadované funkcie rozdelené do dvoch častí:

     

    funkcie na manipuláciu so všeobecnými údajmi systému

    - špecifikáciu funkcií je nutné rozšíriť o niektoré položky ako napr. e-mailovú adresu

    Do systému bude vstupovať formulár, v ktorom budú zadané všetky informácie o danom predmete. Tento formulár bude pred začiatkom semestra zadávať pre každý predmet daný prednášajúci. V prípade viacerých formulárov pre jeden predmet sa automaticky vytvorí zoznam prednášajúcich pre predmet.

    - funkcie sú špecifikované dobre a je vhodné ich prebrať

    - funkcia je nedostatočne špecifikovaná, pretože nezohľadňuje špecifické študijné plány, kde sa okrem povinných a voliteľných predmetov nachádzajú aj skupiny voliteľných predmetov, na ktoré sú určité kreditové požiadavky. Funkcia evidencia študijných plánov nie je triviálna a je nutné špecifikovať ju podrobnejšie.

    - špecifikácia funkcie sa zmení na základe predchádzajúcej funkcie, evidenciu voliteľných predmetov bude vykonávať externá entita študent, v predpísanom časovom období

    - špecifikáciu funkcie je vhodné zaradiť do skupiny funkcie na podporu vytvorenia rozvrhu

    - funkcie sú v dokumente nedostatočne špecifikované

     

    funkcie na podporu vytvorenia rozvrhu

    - špecifikáciu funkcií je vhodné zmeniť tak, že pri zadaní ročníka sa zobrazia príslušné predmety a prednáška alebo cvičenie sa vloží do rozvrhu zobrazeného pre miestnosť. ďalej je nutné zohľadniť vytváranie rozvrhu jedinečného pre každý týždeň semestra. Preto sa nasledovné funkcie musia podrobnejšie špecifikovať a definovať nové požiadavky s tým súvisiace.

    - funkcie sú špecifikované dostatočne

    - v dokumente sú predchádzajúce funkcie nejasne a nedostatočne špecifikované a treba ich podrobnejšie opísať

     

    Zhodnotenie:

    Funkčné požiadavky špecifikované v recenzovanom dokumente sa preberú do novovytváraného systému s tým, že sa niektoré upravia, prípadne podrobnejšie rozdelia na viac funkčných požiadaviek. Po analyzovaní špecifikovaných požiadaviek by sa mali dodefinovať nasledovné funkčné požiadavky:

    Tieto funkčné požiadavky budú podrobne definované a špecifikované v dokumente definícia a špecifikácia požiadaviek v nasledujúcej kapitole.

     

          1. Špecifikácia údajov v systéme

    Údaje sú špecifikované formou diagramu logického modelu údajov. Logický model je neúplný pre špecifikované požiadavky.(chýbajú tabuľky na uloženie študijného programu)

     

    Zhodnotenie:

    Pri špecifikovaní údajov v systéme je možné vychádzať z daného logického modelu údajov, ale je nutné tento model doplniť o všetky potrebné údaje na základe špecifikácie nových požiadaviek, prípadne iných dokumentov.

     

          1. Špecifikácia správania sa systému

    Zhodnotenie:

    Táto časť dokumentu je vypracovaná veľmi podrobne a jasne a predstavuje podrobný opis pre vývoj systému. Po zohľadnení nových špecifikovaných požiadaviek bude tento dokument vytvorený v podobnej forme.

     

          1. Opis a príručka ku prototypu

    Opis prototypu sa nenachádza v dokumente. Príručka k prototypu je vypracovaná kvalitne. Je napísaná jasne a jednotlivé kapitoly sú prehľadne číslované. Obrázky vhodne prispievajú k názornému vysvetleniu ovládania a funkčnosti prototypu.

     

     

        1. Recenzia etapy - návrh systému č.2

          2.  

          Keďže práca nášho tímu nadväzuje na výsledky tímu č.2 z minulého školského roku, je potrebné si osvojiť vytvorený produkt. Treba poukázať na dobré myšlienky, ktoré by bolo možné prevziať bez menších úprav a vypichnúť slabé stránky, potrebné prepracovať.

           

          1. Architektúra systému

            2.  

            Zvolená architektúra systému, teda MS IIS a MS SQL Server, zaručuje vlastnosti potrebné pre náročnosť databázového systému akým je vysokoškolský rozvrh vzhľadom na objem údajov. Táto voľba by nemala byť zmenená.

            Zo zobrazenia architektúry typu klient - server vidno, že klienti sú rozdelené na dve skupiny, na používateľa a rozvrhára, kde posledne menovaný má pevne stanovený web prehliadač. Tento spôsob bol zvolený kvôli rozsiahlosti práce rozvrhára, teda samotnej tvorbe rozvrhu. Ak by však mal byť systém stavaný na fakultnú úroveň, bolo by vhodné, aby podporoval čo najväčšie množstvo dostupných grafických prehliadačov.

             

            Klient - server architektúra

             

            Objasnenie architektúry klient – server všeobecne vystihuje podstatu štruktúry a funkčnosti systému tohto typu. Prezentované je rozdelenie na stranu servera a stranu klienta.

            Prvá zo strán je založená na web a databázovom serveri. Konkrétnejšie na tabuľkách v databáze a serverových skriptoch pre IIS. Túto kombináciu zvolených produktov netreba meniť. Implementácia tejto strany je na základe firmy Microsoft, kde ako web server je použitý Internet Information Server, ako databázový server je zvolený SQL Server. Dobrý výber typu skriptov určuje voľbu ASP oproti CGI, pre možnosť kombinovania HTML jazyka so skriptovacími jazykmi ako Visual Basic Script alebo JavaScript v jednom súbore.

            ďalšia strana je klientská, obsahujúca web prehliadač. V prípade obyčajného používateľa nie sú robené špeciálne zásahy, stačí použiť štandartné HTML. Naopak pre rozvrhára bola identifikovaná potreba interaktívneho prostredia, na ktoré bolo využité DHTML. Toto riešenie považujem ako správne z hľadiska, presunutia záťaže na stranu klienta, ale nevýhodou je nekompatibilita medzi prehliadačmi Internet Explorer a Netscape Navigator v podpore tejto technológie (možnosť implementácie častí pre obidva prehliadače).

            Nakoniec tejto časti sú spomenuté väzby modulov na databázu, kde kvôli časovému limitu nebolo uznané za vhodné implementovať export a import údajov pre SQL Server.

             

          2. Návrh systému (DFD)

            3.  

            Diagramy dátových tokov

             

            Kontextový diagram obsahuje entity, ktoré nie je potrebné meniť ani dopĺňať, ale pre identifikované rozšírenia na systém bude treba doplniť toky údajov k učiteľom a študentom aj o opačný smer (smerom do systému). Za dobré považujem zahrnutie okolia tohto systému, na tejto úrovni, ostatných modulov KIS do jednej externej entity. Zaujímavá je externá entita Fakultný rozvrh zabezpečujúca výstup do FIS, pri ktorej spätnú väzbu na KIS zabezpečuje rozvrhár, pričom aj táto funkcia by mohla byť riešená cez web. Na 0. a 1. úrovni dekompozície procesov nie sú popísané dátové toky, čo sprehľadňuje diagram, na účet menšej výpovednej hodnoty. V podstate celú štruktúru funkčného modelu by bolo možné prebrať a doplniť o určené rozšírenia (prípadne mierne upraviť podľa nových požiadaviek)

            Opis procesov

             

            Ad 1. Import a Export údajov. Pri opise importu a exportu údajov je opäť špecifikovaný dôvod neimplementovania vlastných modulov na import a export údajov, avšak tentoraz je príčina v už poskytovanom importe a exporte pomocou SQL servera

            Ad 2.3 Evidencia skupín. Znova by som vyzdvihol myšlienku vytvorenia skupín ľudí majúcich spoločné vlastnosti (týkajúce sa rozvrhu). Nie je tu spomenutá evidencia skupín učiteľov.

            Ad 3.3 Získanie záznamov zo servera. Z hľadiska záťaže komunikačného spojenia považujem za dobre navrhnuté obnovovanie údajov až pri explicitnom vyžiadaní, ktorú predstavil daný tím (týka sa aj zápisu zmien v rozvrhu na server).

            Ad 4.5 Výber filtrovaných nekonzistencií. Pri kontrole obmedzení je dobre riešené zadávanie filtrov, predstavené ako iterácia k vytvoreniu správneho filtra pomocou opätovného dodefinovania.

            Ad 5. Výber zobrazenia. ďalej možno prevziať funkciu pre určenie spôsobu zobrazenia výstupu, pretože každý používateľ preferuje rozdielne produkty na spracovanie údajov a všetky nemusia podporovať spoločný štandard.

             

            Opis úložísk údajov

             

            Opis úložísk údajov popisuje logický model údajov, ku ktorému sa v tomto viac nevyjadrujem, pretože pre náš tím je dôležitejší, z hľadiska nadväznosti, fyzický model údajov predchádzajúceho tímu.

             

            Opis externých entít

             

            Zaujala ma “multientita” používateľ, ktorá agreguje na vyjadrenie spoločných čŕt viacero osôb a teda sprehľadňuje hlavne kontextovú úroveň DFD.

            Implementácia požiadaviek vo fyzickom dátovom modeli a v procesoch modelu dátových tokov

             

            I keď v nadpise tejto časti je použité slovo implementácia, nemá s ním táto časť nič spoločné. Jedná sa o upriamenie sa predovšetkým na podstatné fakty zo špecifikácie požiadaviek. Vymenované sú časti systému, v ktorých by mali byť dané požiadavky implementované, prípadne aj s vymenovaním relácií do databáz, potrebných na zostavenie požadovanej informácie.

            Včlenenie tejto kapitoly považujem ako vhodné vzhľadom na zaostrenie sa na požadovaný problém a neskoršie lepšie rozdelenie si tímových úloh.

            Pri požiadavkách systému na výstup je poskytovaný aj špeciálny výstup pre zamestnancov katedry za účelom plánovania katedrových schôdzok, ktorý je zabezpečený spojením študentov aj učiteľov do jednej tabuľky, vytvorením skupiny učiteľov a úpravou rozvrhu pre túto skupinu.

            Nie je dostatočne riešení výstup do existujúceho KIS.

             

          3. Spôsob implementácie a jej ohraničenia

            4.  

            Zavedené ohraničenia predchádzajúceho tímu sú vo väčšej miere ekvivalentné s nami identifikovanými potrebnými rozšíreniami.

            Zoznam ohraničení:

            • pravidelný týždenný rozvrh
            • nadväznosť predmetov
            • automatizovaný import/export údajov z/do existujúceho KIS
            • opäť spomenutý import/export údajov v súvislosti s produktom MS Excel (väčšina dokumentov v KIS je v tomto tvare), poskytuje MS SQL Server
            • nepriama kontrola konzistencie údajov (možno presunúť časť do priamych kontrol editovacích funkcií)

     

          1. Fyzický návrh databázy

            2. Štruktúra databázových tabuliek

             

            Diagram popisujúci štruktúru databázových tabuliek je neprehľadný, i keď zobrazuje naraz všetky údajové entity s atribútmi a vzťahmi. Pre náš tím bude potrebné túto štruktúru zmeniť podľa špecifikovaných rozšírení.

             

            Opis modelu údajov

             

            Pri tabuľke schedule, ktorá spája osobu s dvojicou predmet a miestnosť, je na určenie relácie preferované použitie osoby pred použitím skupiny. Tento krok však nie je dostatočne vysvetlený (“tento prístup sa nám zdal byť univerzálnejší), pričom zostavovanie rozvrhu je tvorené cez skupiny.

            Ako dobré považujem uvažovanie možnosti zrušenia predmetu v súčinnosti s potrebou uchovať históriu predmetu, ktorá sa zachová ak idsubject v tabuľke absolvedsubjects nie je vedený ako cudzí kľúč.

            Možnosť budúceho rozšírenia je uľahčená aj uvažovaním tabuľky subjectrelation, ktorá umožňuje sledovanie nadväznosti predmetov.

             

          2. Príručka štýlu programovania

            3.  

            Považujem za potrebné pokračovať v dodržiavaní zásad spísaných predchádzajúcim tímom, nielen z titulu prevzatia ich zdrojových textov.

     

        1. Recenzia etapy - implementácia systému č.2

     

    Samotná implementácia produktu je prehľadne členená do samostatných adresárov. Zdrojové texty sú prehľadne členené a v hlavičke každého súboru sú uvedené údaje na lepšie pochopenie významu súboru. Autori používajú Java a Visual Basic skripty. Samotná práca s užívateľom je riešená Visual Basic scriptami. Jednotlivé skripty sú prehľadne štruktúrované.

    V dokumentácii sú prehľadne zachytené implementačné podrobnosti. Nebolo by zlé uviesť nielen funkciu jednotlivých súborov a nad akými údajmi pracujú, ale zakresliť (prípadne popísať) celkovú dynamiku systému, ako sú jednotlivé súbory prepojené a aké údaje si navzájom odovzdávajú. Autori tieto implementačné podrobnosti prehľadne zachytávajú v hlavičkách jednotlivých súborov. Nebolo by zlé urobiť súhrn týchto údajov a zachytiť ich aj v dokumentácii.

    Pri testovaní produktu v prostredí Internet Explorer sa vyskytli drobné chyby. Prvou chybou, ktorá by sa dala vytknúť autorom produktu je autentifikácia. Pri nesprávnej autentifikácii užívateľa nie je nijakým spôsobom oboznámený z nekorektným prístupom do programu. Patrilo by sa informovať užívateľa o výsledku autentifikácie (aspoň v prípade nekorektného prístupu). Jediný spôsob, ktorý informuje užívateľa o výsledku autentifikácie je zmena pozadia zo sivého na biele. Pre osobu, ktorá nepozná spôsob obsluhy daného produktu sa nič nedeje a tým sa bude opätovne pokúšať odoslať svoje meno a heslo serveru na autentifikáciu. V dokumentácii v užívateľskej príručke je spomenuté, že v prípade nesprávneho autentifikovania sa opätovne zobrazí stránka požadujúca zadanie mena a hesla užívateľa. Keď sa už teda autori rozhodli nevypisovať žiadne hlásenie o úspešnosti autentifikácie, tak by sa nemalo meniť ani pozadie formuláru.

     

    Čo ma veľmi milo prekvapilo, bolo komfortné riešenie práce s jednotlivými databázami. Editovanie , prezeranie a modifikovanie databáz bolo prehľadne riešené a jednotlivé tlačidlá jasne naznačovali na čo slúžia. Ako veľký prínos som ocenil zabudovanie filtrov pri prezeraní databáz a globálny náhľad na dáta pomocou tabuliek. Je to drobnosť, ale pri veľkom množstve informácií výrazne urýchľuje užívateľovi orientáciu v dátach. Pri testovaní práce s dátami sa vyskytol drobný problém. Pri všetkých možnostiach, ktoré daný produkt umožňuje, v prípade, že chce oprávnený užívateľ vytvoriť nového užívateľa (user) v databáze a zadá semester iný ako 0-1 pre daného užívateľa, tak po stlačení tlačidla na uloženie formuláru do databázy sa vypíše chybové okno a následne sú všetky položky v databáze (lokálnej – na strane užívateľa) prepísané posledne zadávaným formulárom. Jediný spôsob ako získať opätovne platné dáta z databázy vedie k uzatvoreniu prehliadača (v prípade, že bol volaný z inej stránky, tak treba zatvoriť aj pôvodný prehliadač) a opätovnému spusteniu prehliadača a následnému spusteniu produktu. Pri rozsahu práce, ktorú vykonali autori je zrejmé, že nemohli vychytať všetky možné chyby, pretože poznajú danú problematiku a pracujú s produktom korektne. Na testovanie je preto vhodné používať osoby neoboznámené s danou problematikou, ktoré rýchlejšie odhalia slabiny produktu. Preto by som doporučoval vzniknutú chybu odstrániť a do formuláru (nielen do konkrétneho) pridať rozsahy platných hodnôt, ktoré napomôžu pri zadávaní položiek vo formulári.

     

    Pri editovaní databáz, pri práci so skupinami a študijnými plánmi by nebolo zlé vypisovať údaje v abecednom poradí. Sprehľadnilo by sa tým vyhľadávanie konkrétnej položky v zozname.

     

    Najväčšie problémy vznikli pri vytváraní rozvrhu. Užívateľ, ktorý si neprečíta podrobne užívateľskú príručku z veľkými problémami odhalí spôsob zadávania predmetov do rozvrhu. Až po preštudovaní zistí, že zadávanie je metódou Drag & Drop, ale aby vytvoril predmet v rozvrhu s kompetným obsahom bunky rozvrhu musí postupne natiahnuť na príslušné miesto predmet, miestnosť a skupinu. Toto postupné vkladanie údajov nieje až tak efektívne a v nesprávnom poradí sa zobrazí v rozvrhu prázdna hodina bez názvu, ale s definovanou dĺžkou trvania. Pri vytváraní rozvrhu mohli autori dovoliť dodefinovanie zvyšných parametrov priamo vo formulári, prípadne mohli pridať na stránku tlačidlo, ktoré by konkrétnu trojicu vložilo na určené miesto v rozvrhu. Vkladanie by bolo interaktívne, ale nemuselo by sa postupne zadávať predmet, miestnosť, skupina a zakaždým potvrdiť vykonanú úpravu.

    Produkt tiež umožňuje kliknutím na konkrétnu hodinu v rozvrhu zadať predmet bez mena, miestnosti a skupiny. Takáto položka predstavuje obsadenie rozvrhu prázdnym predmetom, ktorý ak chce následne užívateľ zmazať, tak zistí, že operácia viedla k havárii prehliadača. Následne treba zatvoriť prehliadač a opätovne spustiť prehliadač a v ňom produkt. Bolo by preto dobré testovať pri zadávaní čí je vyplnená aspoň jedna z troch základných položiek (predmet, miestnosť, skupina).

    Taktiež by nebolo zlé pri použití metódy Drag & Drop po vložení predmetu na príslušné miesto zobrazovať v okne popisujúcom predmet prednastavenú hodnotu nie 0 ale 1, aby sa nevytvárala hodina s nulovou dĺžkou.

    ďalší problém vzniká pri ukladaní vytvoreného rozvrhu na server. Po úspešnom vytvorení rozvrhu a následnom stlačení tlačidla “Uložiť” vypíše sa chybové hlásenie do pracovného okna a rozvrh je premazaný. Strava rozvrhu je spôsobená prekreslením aktívneho okna (tzv. refreš). Je to spomenuté aj v dokumentácii, ale v súvislosti s modifikáciu rozvrhu.

    Posledný problém, ktorý je spojený s tvorbou rozvrhu vzniká pri modifikovaní rozvrhu. Prechodom kurzoru myši po predmetoch sa zobrazujú jednotlivé predmety s podrobnosťami pod rozvrhom. Toto funguje perfektne v prípade vytváranie rozvrhu. Pri modifikácii rozvrhu sa tieto informácie zobrazujú iba pre prvé predmety v danom dni.

     

    Kontrola konzistencie databázy umožňuje veľké množstvo testov. Je prehľadne zobrazovaná po jednotlivých testoch pre užívateľa na obrazovku. Pri výpisoch kolízií sa niekedy vypisujú dva zhodné riadky ako kolízie. V týchto prípadoch by bolo dobré uvádzať kritérium, podľa ktorého sa určilo, že sa jedná o kolíziu. Nie je to vidieť zo zobrazenej tabuľky.

     

    Celkové hodnotenie:

    Produkt je pre užívateľa prehľadne členený na jednotlivé podcelky. Ku každému celku je vytvorené podrobná užívateľská príručka. Jednotlivé formuláre sú prehľadne rozmiestnené na obrazovke. Vzhľad stránok nerozptyľuje používateľa pri práci a poskytuje mu čo najväčšie množstvo informácií v prijateľnej forme. Práca s uchovanými údajmi v databáze je vzhľadom na možnosti prehliadačov (hlavne grafických) komfortná a jednoduchá.

    Spomenuté chyby nemajú za cieľ spochybniť kvalitu vytvoreného produktu. Poukázaním na tieto chyby sa dá zlepšiť celkový produkt a vystríhať sa pred podobnými chybami.

     

    Čo by bolo vhodné prevziať od predchádzajúceho týmu je editácia databáz, ktorú prepracovali autori veľmi podrobne. Samozrejme ju bude treba prispôsobiť na nový dátový model. Autentifikácia je taktiež dobre navrhnutá. Jej funkčnosť bude treba rozšíriť o nové možné prístupy a prispôsobiť našim potrebám. Vytváranie rozvrhu bude treba prepracovať z dôvodu iného prístupu k vytváraniu rozvrhu. Kontrola chýb je z hľadiska výstupných údajov pre rozvrhára prijateľná, bude treba odstrániť spomenuté problémy. Čo sa týka funkčnosti kontroly kolízií je treba vytvoriť nový spôsob detekcie kolízií.

     

     

      1. Analýza systému č.1

        2. Systém č.1 je produkt s názvom Katedrový informačný systém – Katedrový rozvrh, ktorý bol vypracovaný v školskom roku 1998/1999 tímom v zložení:

        Ing. Kováč Artúr

        Ing. Rajčan Štefan

        Bc. Chorvatovič Michal

        Bc. Kečkéš Ladislav

        Bc. Tamajka Dušan

        Kompletná dokumentácia k projektu bude prílohou tejto dokumentácie.

         

        1. Recenzia etapy – analýza systému č.1

     

    V prvej časti analýzy je rozoberaná celková tvorba rozvrhu. Rozdelili ju do troch fáz:

     

     

    Keďže projekt je zameraný na podporu katedrového informačného systému, riešitelia sa zamerali na uľahčenie tvorby rozvrhu v I. a III. fáze a na podporu prezerania rozvrhu.

    Pre každú fázu sú analyzované potrebné vstupy a výstupy podľa špecifikácie, ktorá bola zadaná, ale i podľa požiadaviek, konzultovaných s p.Husárovou a p. Bielekovou. Analýza pokrýva požiadavky na systém.

     

        1. Recenzia etapy - návrh systému č.1

     

    Pre systém bol zvolený hybridný model architektúry, ktorý je zložený z vrstvového, distribuovaného, interaktívneho a interpretačného modelu.

    Má trojvrsvovú databázovú architektúru.

     

    Myslím, že architektúra systému bola vhodne navrhnutá. Keďže sa k báze údajov nepristupuje priamo , ale prostredníctvom klientov, je zabezpečená aj ochrana pred neoprávneným prístupom k údajom.

     

    V systéme sú definované nasledovné prístupové práva:

     

     

     

     

    Nebolo však spomenuté, či používateľ tiež musí mať konto, teda oprávnenie na prezeranie rozvrhu. Myslím, že by bolo vhodné, keby si mohli rozvrh prezerať aj osoby, ktoré nie sú z fakulty (napr. niekto zo Stavebnej fakulty si chce pozrieť rozvrh svojho kamaráta...).

     

     

    DFD diagramy sú dobre navrhnuté. Zaujímavý je proces editovanie rozvrhu a tabuliek, ktorý komunikuje s databázou nasledovne. Pri editácii rozvrhu zadávateľom sa najprv všetky údaje skopírujú do lokálnej databázy. V nej sa vykonávajú všetky potrebné zmeny. Až na povel zadávateľa rozvrhu sa všetky zmeny aj fyzicky prenesú do databázy. V etape návrhu však nebolo spomenuté, či zadávatelia rozvrhu môžu byť aj viacerí a ak áno, tak čo by sa stalo, keby naraz editovali rozvrh nad lokálnou databázou a potom zapísali, každý svoje údaje do ostrej databázy. Teda ako sa rieši vznik nekoherencie údajov, problém, ktorý pri tomto riešení určite môže nastať.

    Funkcie procesov boli však celkove dosť slabo vysvetlené a popísané.

     

    Dátový model údajov nebol úplný, keďže chýbali popisy hrán, teda vzťahov medzi údajmi. Myslím, že by bolo prehľadnejšie priamo do modelu dať aj atribúty jednotlivých entít. Teraz si treba zakaždým nájsť údajový slovník, keď je potrebné vidieť aj atribúty jednotlivých entít modelu.

    Fyzický model je robený pomocou diagramu tabuliek. Pri vysvetlení tejto techniky je pekne vidieť hrany, teda vzťahy medzi jednotlivými tabuľkami, avšak pri konkrétnom zobrazení tieto prepojenia nie sú zobrazené. Nie je teda vôbec vidieť vzájomné väzby.

     

    Pri navrhovaní rozvrhu sa sledujú tieto kolízie:

     

        1. Recenzia etapy – implementácia systému č.1

          2.  

          Implementáciu daného projektu je možné rozdeliť do dvoch základných častí. Sú to:

          - voľba a spôsob použitia databázovej platformy

          - voľba a spôsob použitia programovacieho prostriedku, ktorý s danými dátami manipuluje a vytvára užívateľské rozhranie

           

          1. Databázový prostriedok

            2.  

            Ako databázový prostriedok bol použitý produkt firmy Microsoft – Microsoft Access. Táto voľba bola urobená vzhľadom na relatívne prístupnú cenu a splnenie všetkých nevyhnutných kritérií uvedeným prostriedkom. Nevýhodou však je malá rýchlosť prístupu, nakoľko je nutné k databáze pristupovať cez rozhranie ODBC. Preto sa zdá byť použitie klasického SQL servra z hľadiska výkonnosti ako výhodnejšie.

             

          2. Programovací prostriedok

     

    Na implementáciu bolo možné použiť rôzne prostriedky prípadne kombinácie týchto prostriedkov. V predmetnom projekte bolo vybrané na implementáciu prostredie JBuilder od firmy Borland (t.j. programovací jazyk Java). V tomto jazyku je implementovaný prototyp, ktorý však preukázal, že výber uvedeného prostriedku je maximálne nevhodný pre daný projekt. Dôvodom je problém s prenositeľnosťou programu medzi počítačmi. Tento problém by sa však za predpokladu dostatočného ladenia na školských počítačoch dal pravdepodobne odstrániť. Hlavným problémom však bola rýchlosť odozvy systému, ktorá je závislá na prístupných hardvérových prostriedkoch. Keďže používané počítače nemajú dostatočné parametre a riešiť tento problém nie je v silách programátorov, tak sa javil ako neprekonateľný. Preto bolo nutné pristúpiť k zmene implementačného prostredia.

    Ako nové prostredie bola zvolená kombinácia statických HTML stránok, PHP3 a Java scriptov. Výhodou je menšia náročnosť na hardvér pri o mnoho rýchlejších odozvách systému. Uvedené prostriedky predstavujú vhodnú kombináciu, pretože umožňujú efektívne pokryť všetky požiadavky na implementáciu:

     

    Uvedené oblasti použitia jednotlivých prostriedkov sú použité v celom projekte s výnimkou jedného prípadu.

    Pri editovaní rozvrhu je celá databáza skopírovaná v upravenej forme do súboru, ktorého obsah je potom poslaný ako hodnota premennej na lokálny počítač. Všetky zmeny rozvrhu sa potom vykonávajú iba nad uvedenou premennou. Na konci editácie je nutné celý obsah poslať späť na server čím sa zaktualizuje obsah databázy. Toto riešenie sa javí ako veľmi nevýhodné vzhľadom na to, že prináša relatívne veľa obmedzení a rizík. Hlavným je riziko nedostatku voľnej pamäte lokálneho počítača. V prípade vyskytnutia sa tohto problému systém môže jednoducho zhavarovať a všetky zmeny vykonané počas tejto editácie budú nenávratne stratené. Keďže počas editácie neprebieha žiadne automatické ukladanie medzivýsledkov, riziko ich straty je veľké aj pri iných okolnostiach ako sú výpadok elektrického napätia ap. ďalším obmedzením je fakt, že v jednom okamihu môže byť rozvrh editovaný iba jedným užívateľom. Výhodou je rýchlejšia odozva systému, keďže všetky dáta sú na lokálnom počítač a nemusí prebiehať komunikácia po sieti. Vzhľadom na uvedené negatíva však bolo pravdepodobne vhodnejšie zvýšiť bezpečnosť a robustnosť systému aj za cenu jeho spomalenia.

     

     

     

      1. Analýza súčasného stavu

        2.  

        Vypracovávaný tímový projekt má podľa zadania riešiť problematiku výberu predmetov študentmi, zadávanie požiadaviek na predmety vyučujúcimi, tvorbu rozvrhu so zohľadnením rôzneho vyučovania v jednotlivých týždňoch semestra ako aj tvorbu rozvrhu skúšok, ktoré sú na konci každého semestra. Preto sa analýza súčasného stavu bude zaoberať celou postupnosťou uvedených úkonov.

        1. Výber predmetov a tvorba semestrového rozvrhu

          2.  

          Pred koncom každého školského roka schvaľuje pedagogická rada v spolupráci so senátom zoznam predmetov, ktoré je možné otvoriť v nasledujúcom školskom roku. Tento zoznam je zhrnutý do Študijného programu fakulty. Na základe tohto zoznamu sú pre jednotlivé ročníky a odbory (resp. špecializácie) vytlačené formuláre s názvom Študijný plán. Tieto plány obsahujú zoznam vyberateľných predmetov pre danú kategóriu študentov. Tieto sú rozdelené do skupín podľa určených kritérií (napr. povinné, povinne voliteľné, odporúčané, ekonomické predmety, matematické predmety, ...). Elektronická forma uvedených formulárov je klasický dokument pre Word alebo Excel. Príklad tohto dokumentu je v prílohe B-1. Opisované formuláre sú tlačené vo výpočtovom laboratóriu prípadne u tajomníka každej katedry - podľa príslušnej metódy distribúcie. Distribúcia týchto formulárov študentom, ich spracovanie ako aj tvorba rozvrhu prebieha odlišne pre rôzne ročníky.

          Pre 1. a 2. ročník bakalárskeho štúdia je distribúcia zabezpečovaná príslušnou študijnou referentkou pedagogického oddelenia, ktorá ich aj zozbiera späť a zoznam študentov s ich vybranými predmetmi zaeviduje. Ona vykoná kontrolu správnosti vybraných predmetov. Príslušné údaje posiela priamo fakultnému rozvrhárovi (keďže študenti ešte nepatria pod žiadnu katedru), ktorý vytvorí príslušný rozvrh hodín. Tento rozvrh je pripomienkovaný každou zainteresovanou katedrou.

          Pre zvyšné ročníky bakalárskeho štúdia a inžinierske štúdium zabezpečujú distribúciu katedry (na KIVT je to tajomník – v súčasnosti Ing Bieleková) a to pre študentov študujúcich odbor patriaci pod danú katedru. Po spätnom zozbieraní týchto tlačív je vykonaná kontrola správnosti študentmi vybraných predmetov. Kritériami sú napríklad celkový počet kreditov, minimálny počet kreditov za vybrané predmety z konkrétnych skupín, prípadne to, či boli vybrané všetky povinné predmety pre danú kategóriu študentov. Kontrola sa uskutočňuje manuálne, čo je veľmi náročný a zdĺhavý proces. Zároveň tajomník katedry vytvorí zoznam študentov a ich predmetov, ktorý je udržiavaný vo forme tabuľky pre Excel. Na základe informácií z tejto tabuľky sa musia určiť predmety, ktoré nebudú otvorené kvôli nedostatočnému záujmu študentov, pričom študenti ovplyvnení touto zmenou si musia určiť náhradné predmety (táto zmena sa väčšinou deje až na začiatku aktuálneho školského roka).

          Zároveň s týmto procesom tajomník rozdá formuláre s názvom Požiadavky na predmet ľuďom, zodpovedným za výučbu jednotlivých predmetov (väčšinou sú to prednášajúci ale pri špeciálnych predmetoch ako napr. tímový projekt sú to osoby vedúce tento predmet). Daný formulár je uvedený v prílohe B-2. Po vyplnení a zozbieraní tohto tlačiva je na základe uvedených informácií povereným pracovníkom (v súčasnosti je ňou prom. mat. Husárová) vytvorený zoznam krúžkov (pre bakalárske štúdium) a skupín študentov (pre inžinierske štúdium). Skupiny sú tvorené manuálne na papieroch a za pomoci Excelu. Pre tieto skupiny študentov je vytvorený katedrový rozvrh hodín t.j. rozvrh hodín, ktoré budú vyučované pracovníkmi katedry a v katedrových miestnostiach. Uvedený rozvrh je vytváraný manuálne a zadaný do fakultného rozvrhového systému. V nasledujúcej fáze je rozvrh tvorený fakultným rozvrhárom (v súčasnosti RNDr. Galan) a to na základe katedrových rozvrhov a požiadaviek na pridelenie miestností v správe fakulty. Kolízie medzi jednotlivými požiadavkami rieši fakultný rozvrhár konzultáciami s jednotlivými katedrovými rozvrhármi, ktorí ak je to nevyhnutné musia zmeniť svoje požiadavky aj za cenu čiastočnej úpravy predbežného katedrového rozvrhu. Tento proces sa opakuje až po dosiahnutie rozvrhu vhodného pre celú fakultu.

          Po definitívnom určení rozvrhu tajomník katedry pridelí pedagógov jednotlivým cvičeniam v rozvrhu a to za pomoci špeciálneho programu, určenom iba na tento účel.

          Grafická forma opísaného procesu pre vyššie bakalárske a inžinierske ročníky je uvedená na obrázku.

           

          Proces výberu predmetov a tvorby rozvrhu hodín:

           

           

           

           

           

          Popis presúvaných dokumentov:

          1.a, 1.b - študijný program

          2., 3. - študijný plán nevyplnený

          4. - študijný plán vyplnený

          5. - zoznam študentov s vybranými predmetmi

          6. - požiadavky na predmet nevyplnené

          7. - požiadavky na predmet vyplnené

          8. - predbežný katedrový rozvrh s požiadavkami na fakultné priestory

          9. - kolízie s inými katedrami; definitívny fakultný rozvrh

          10. - definitívny katedrový rozvrh

          11. - definitívny katedrový rozvrh s pridelenými pedagógmi na cvičenia

           

          Poznámka: je možné, že formulár Požiadavky na predmet zbiera od vedúcich predmetu tajomník, ale v ďalšom ho aj tak používa katedrový rozvrhár, takže zobrazenie toku Vedúci – Tajomník – Rozvrhár by bol zbytočnou komplikáciou diagramu.

           

          Zaujímavou časťou opisovaného procesu je zahrnutie možnosti vytvárať rozdielny rozvrh pre rôzne týždne semestra. Súčasný rozvrhový systém umožňuje iba rozlišovanie "typu" týždňa na A a B. Toto delenie v praxi zodpovedá párnemu a nepárnemu týždňu. Špeciálne typy predmetov, ktoré požadujú osobitý režim cvičení (resp. spoločných stretnutí) ako je napríklad stretnutia iba v konkrétnych týždňoch semestra (t.j. nepravidelne), nie sú súčasným systémom podporované. Tento problém je v praxi riešený každým vedúcim takéhoto predmetu samostatne.

        2. Tvorba rozvrhu skúšok

     

    Rozvrh skúšok je vytváraný priebežne počas semestra. Na jeho tvorbu dosiaľ neexistujú žiadne pevné pravidlá, prípadne tlačivá s požiadavkami na prideľovanie termínu a priestorov pre skúšku a preto je zostavovaný prevažne manuálne bez nejakého významného využitia výpočtovej techniky. Jeho tvorba je centrálna pre celú fakultu a predbežný návrh je posielaný na pripomienkovanie jednotlivým katedrám. Osobou zodpovednou za uvedený proces je v súčasnosti doc. Jasenek.

    Kritériá pre tento tvorivý proces sú napríklad:

     

     

     

      1. Analýza požadovaných rozšírení

        2.  

        Na základe analýzy dvoch vytvorených systémov a analýzy súčasného stavu sme časť požiadaviek na funkčnosť systému prebrali zo systému č.2 a požiadavky sme ďalej rozšírili.

         

        1. Prebrané požiadavky

     

        1. Požadované rozšírenia

     

    Požiadavky prebrané zo systému č.2, špecifikujú len minimálnu funkčnosť zameranú na podporu vytvorenia rozvrhu. Preto požiadavky na novovytváraný systém sú rozšírené o:

     

     

     

     

     

     

     

     

    1. Koncept systému

     

     

      1. Kontextový diagram tokov údajov

        2.  

         

         

         

      2. Opis externých entít:

        3.  

        EE1 – Tajomník katedry

        Obhospodaruje evidencie učiteľov, študentov a predmetov. Vykonáva niektoré činnosti ohľadom správy katedry.

         

        EE2 – Externý inf. Systém

        Predstavuje všetky systémy v interakcii s popisovaným systémom z hľadiska výmeny dát.

         

        EE3 – Študent

        Poslucháč štúdia na fakulte, katedre.

         

        EE4 – Rozvrhár skúšok

        Má na starosti zostavenie plánu konania skúšok.

         

        EE5 – Učiteľ

        Predstavuje pedagóga (napr. prednášajúci, cvičiaci) podieľajúceho sa na procese výučby.

         

        EE6 – Používateľ

        Osoba získavajúca informácie o rozvrhu semestra, skúšok a nevyplnených študijných plánoch.

         

        EE7 – Rozvrhár semestra

        Osoba vytvárajúca katedrový alebo fakultný rozvrh na určitý semester.

         

      3. Opis údajových tokov:

     

     

    Evidovaný údaj – informácia, ktorá zahŕňa všetky údaje uchovávané v systéme

     

    Študijný plán – nevyplnená alebo vyplnená časť študijného programu, upozornenie na nesprávny výber predmetu v študijnom pláne, výsledky celkovej kontroly študijného plánu

     

    Rozvrh skúšok – požiadavka na rozvrh skúšok, týkajúca najmä jeho tvorby, informácia o rozdelení konania skúšok na jednotlivé dni

     

    Rozvrh semestra – požiadavka na semestrový rozvrh, týkajúca najmä jeho tvorby, popis rozvrhu na semester

    Chyba v rozvrhu – upozornenie na kolízie v rozvrhu

     

    Exportovaný údaj – údaj určený pre využitie v spolupracujúcich systémoch.

     

    Importovaný údaj – informácia použiteľná v popisovanom systéme

     

    Požiadavka na predmet – údaj bližšie popisujúci potrebné veci na zabezpečenie výučby daného predmetu

     

     

     
    1. Špecifikácia funkcií systému

     

     

    5.1 Špecifikácia funkcionálnych požiadaviek

     

    Funkcionálne požiadavky sú rozdelené do nasledujúcich skupín:

     

     

     

        1. Požiadavky na spracovanie rozvrhu skúšok

     

     

        1. Požiadavky na priame spracovanie rozvrhu

     

     

     

        1. Požiadavky na zapisovanie predmetov študentmi

     

     
        1. Požiadavky na prihlasovanie predmetov učiteľmi

     

     

     

        1. Požiadavky na prepojenie systému so vstupmi z existujúceho informačného systému

     

     

        1. Požiadavky na výstupy systému

     

     

     

    5.2 Špecifikácia funkcií

     

    Priority jednotlivých funkcií sú označené rímskymi číslicami za každou funkciou. Ich význam:
    1. – najvyššia priorita
    2. – stredná priorita
    3. – najnižšia priorita

     

     

     

        1. Funkcie na manipuláciu so všeobecnými údajmi

     

     

     

    Evidencia študentov (I)

     

    Pri zadávaní študentov sa budú zadávať nasledujúce údaje: meno, priezvisko, číslo študenta, titul, rodné číslo študenta, prihlasovacie meno, heslo, e-mailová adresa.

    Systém bude zabezpečovať aj import externých údajov.

     

    Evidencia učiteľov (I)

     

    Pri zadávaní učiteľov sa budú zadávať nasledujúce údaje: meno, priezvisko, titul, katedra, rodné číslo, prihlasovacie meno, heslo, e-mailová adresa.

    Systém bude zabezpečovať aj import externých údajov.

     

    Evidencia predmetov (I)

     

    Pri zadávaní predmetov sa budú zadávať nasledujúce údaje: názov predmetu, skratka predmetu, katedra, kredity, html stránka predmetu.

    Systém bude zabezpečovať aj import externých údajov.

     

    Evidencia prednášajúcich pre predmet (I)

     

    Zadávať sa budú údaje: zoznam špecializácií, ročníkov a typ pre ktorý je predmet otvorený, počet hodín cvičení a prednášok, max. počet skupín súčasne, celkový počet skupín na voliteľný predmet, miestnosť na prednášky a cvičenia, typ výuky, zoznam počtu hodín pre jednotlivé týždne.

     

    Evidencia katedier (I)

     

    Pri zadávaní katedier sa budú zadávať nasledujúce údaje: skratka, názov, umiestnenie, vedúci . Systém bude zabezpečovať aj import externých údajov.

     

    Evidencia študijných odborov (I)

     

    Pri zadávaní študijných odborov sa budú zadávať nasledujúce údaje: ročník, zameranie, špecializácia, číslo špecializácie, skratka.

    Systém bude zabezpečovať aj import externých údajov.

     

     

    Evidencia študijných plánov (I)

     

    Tento modul bude zabezpečovať zadávanie všetkých študijných plánov pre každý ročník a každú špecializáciu. Bude umožňovať vytváranie skupín predmetov na ktoré sú špeciálne požiadavky pri zapisovaní. Pre každý ročník a špecializáciu bude obsahovať: zoznam povinných predmetov, zoznam voliteľných predmetov, prípadne zoznam skupín voliteľných predmetov na ktoré sú špeciálne požiadavky, semester.

     

    Evidencia zapísaných predmetov študentov (II)

     

    Tento modul bude zabezpečovať zadávanie voliteľných predmetov pre konkrétnych študentov. Pri požiadavke na výpis zapísaných predmetov pre študenta sa povinné predmety budú automaticky brať zo študijného plánu a voliteľné predmety sa budú brať zo zoznamu voliteľných predmetov.

    Systém bude vykonávať kontrolu správnosti zapísania predmetov s ohľadom na počet kreditov.

     

    Vytváranie skupín zo študentov (II)

    Skupina je zovšeobecnenie krúžku. Vo vyšších ročníkoch môže študent patriť do viacerých skupín na základe zapísaných voliteľných predmetov.

     

    Vytváranie skupín z učiteľov (II)

     

    Učitelia budú zadávaný do skupín na základe príslušnosti ku katedre a skupiny budú vytvorené aj pre učiteľov ktorý cvičia rovnaký predmet.

     

    Evidencia požiadaviek na predmet (I)

     

    Evidované budú požiadavky pre všetky predmety otvárané v danom semestri. Požiadavky, ktoré ostanú nezmenené z predchádzajúceho školského roku bude možné iba aktualizovať (resp. prípadne vykonať malé zmeny) a tieto sa stanú platné pre aktuálny semester bez nutnosti opätovného zadávania.

     

     

    Tlač jednotlivých dokumentov (III)

     

    Všetky evidované údaje bude možné vytlačiť používateľmi, ktorí majú na príslušné údaje práva čítať.

     

     

        1. Funkcie na podporu vytvárania rozvrhu skúšok

     

     

     

     

     

    Zadávanie skúšok pre každý predmet (I)

     

    Po zadaní ročníka a špecializácie sa zobrazia predmety a prednášajúci, ktoré sa študujú v ročníku podľa študijného plánu. Po vybraní dvojice predmet a prednášajúci je možné vložiť skúšku do zobrazeného rozvrhu pre konkrétny týždeň na príslušnú hodinu a deň. Štandartne sa dĺžka skúšky nastaví na 3 hodiny. Túto hodnotu je možné zmeniť. Začiatok skúšky môže byť aj v časoch kedy sa nezačína štandartná vyučovacia hodina. Kontroluje sa kolízia – v jednej miestnosti súčasne viac skúšok.

     

    Konfigurácia zobrazenia rozvrhu (III)

     

    Zobrazenie rozvrhu pre skúšky je možné nakonfigurovať ako rozvrh pre jednu alebo viac miestností súčasne. Miestnosti, pre ktoré sa bude zobrazovať rozvrh sa vyberú zo zoznamu miestností vhodných na skúšku.

     

    Priradenie študentov do miestností (I)

     

    Po vytvorení a všetkých kontrolách rozvrhu skúšok sa vygeneruje priradenie študentov do miestností. Študenti sa priradia do miestností rovnomerne podľa abecedy.

     

    Ponúknutie alternatív rozmiestnenia skúšky do miestností (III)

     

    Pri vytváraní rozvrhu pre skúšku pre daný predmet systém ponúkne na základe počtu študentov, ktorý majú predmet zapísaný alternatívy rozloženia do miestností.(napr.: pre predmet so 73 študentmi systém ponúkne alternatívy: a) 1x miestnosť s max. kapacitou 300, 1x miestnosť s max. kapacitou 150

    b) 3x miestnosť s max. kapacitou 150 )

     

     

    Prezeranie rozvrhu (I)

     

    Typy výstupov, ktoré táto funkcia poskytuje: rozvrh pre nastavenú konfiguráciu miestností, rozvrh pre učiteľa, rozvrh pre skupinu študentov, rozvrh pre konkrétneho študenta.

     

     

    Kontrola rozvrhu (I)

     

    Globálna kontrola celého rozvrhu. Zavedenie nasledujúcich typov chýb:

     

     

    Vypnutie kontroly pri zadávaní (II)

     

    Spôsob na vyriešenie výnimiek.

     

    Manipulácia so záznamami cvičení a prednášok (I)

     

    Táto funkcia zahŕňa možnosť interaktívnej zmeny miestnosti, času, dňa, týždňa pre skúšku pre daný predmet.

     

     

     

        1. Funkcie na podporu vytvárania semestrového rozvrhu

     

     

    Prednastavenie rozvrhu podľa požiadaviek na predmet (II)

     

    Výstup tejto funkcie bude slúžiť ako poradná informácia pri vytváraní prednášok a cvičení pre daný predmet. Ak budú evidované požiadavky na predmet dostatočne detailné, vytvorí šablónu, podľa ktorej bude možné zadávať rozvrh tak, aby vyhovoval zadaným podmienkam.

     

    Zadávanie prednášok (I)

     

    Po zadaní ročníka sa zobrazia predmety, ktoré sa študujú v ročníku podľa študijného plánu. V každom predmete sa určí typ týždňa, deň, hodina, miestnosť a prednášajúci. Výmer hodín prednášky sa získa tiež zo študijného plánu. Kontroluje sa, aby v jednom momente v jednej miestnosti bola iba jedna prednáška, a aby jeden učiteľ neučil naraz vo viac ako jednej miestnosti.

     

    Zadávanie cvičení (I)

     

    Po zadaní ročníka sa zobrazia predmety, ktoré sa študujú v ročníku podľa študijného plánu a majú už určenú dobu prednášky. Po výbere predmetu sa zobrazí rozvrh už aj so zadanou prednáškou. Je možné zadávať cvičenia - určiť typ týždňa, deň, miestnosti, čas cvičenia, krúžok alebo skupinu. Kontroluje sa, aby jeden krúžok/skupina v jednom čase nebol(a) na dvoch miestach a aby v miestnosti nebolo viac študentov ako je kapacita miestnosti. V jednej miestnosti v jednom čase nemôžu byť dve rôzne cvičenia.

     

    Priradenie učiteľov k cvičeniam (I)

     

    Ku každému cvičeniu sa zadeľujú učitelia. Po výbere rozvrhu pre konkrétny predmet sa zobrazí zoznam učiteľov z katedry ku ktorej daný predmet patrí. Ku každému predmetu sa určí učiteľ. Učiteľ nemôže učiť naraz dva rôzne predmety. Učiteľ by nemal učiť naraz ani v dvoch rôznych miestnostiach avšak tieto kontroly bude možné vypnúť.

     

    Prezeranie rozvrhu (I)

     

    Prezerať rozvrh bude možné podľa rôznych kritérií. Typy vstupných podmienok budú: miestnosť, učiteľ, predmet, krúžok/skupina študentov, konkrétny študent. Každý z týchto rozvrhov bude možné odfiltrovať podľa typu týždňa (párny, nepárny, konkrétny týždeň semestra).

     

    Porovnanie rozvrhu s požiadavkami na predmet (II)

     

    Porovnanie existujúceho rozvrhu daného predmetu s požiadavkami na tento predmet.

     

    Kontrola rozvrhu (II)

     

    Globálna kontrola celého rozvrhu. Zavedenie dvoch typov chýb: záväzných a informatívnych. Záväzné chyby sa musia odstrániť, sú neprijateľné. Informatívne chyby sa dajú ignorovať ak to bolo zámerom (napr. jeden učiteľ učí naraz v dvoch miestnostiach).

     

    Vypnutie kontroly pri zadávaní (II)

     

    Takýmto spôsobom sa budú riešiť výnimky pri zadávaní rozvrhu. Vypnuté chyby sa nebudú zobrazovať formou hlásení a budú ignorované.

     

    Manipulácia so záznamami cvičení a prednášok (I)

     

    Táto funkcia zahŕňa možnosť zmeny parametrov (typu týždňa, dňa, času, miestnosti, učiteľa) už existujúceho časového poľa, prípadne jeho vymazanie z databázy.

     

    Určenie času kedy majú všetci učitelia alebo vybraná skupina učiteľov voľno (III)

     

    Táto funkcia bude pomôckou na určenie termínu katedrových schôdzí.

     

    Vytvorenie zoznamov voľných hodín študenta/študentov/krúžku/skupiny

    (III)

    Táto funkcia bude pomáhať pri určení termínov spoločných stretnutí študentov.

     

        1. Funkcie systému na manipuláciu so študijnými plánmi

     

     

     

    Editovanie študijného plánu (I)

     

    Činnosť vykonávaná študentom určitého ročníka, prípadne odboru, výberového bloku, za účelom zapísania predmetov na ďalší školský rok podľa stanovených kritérií. Predmety sa vyberajú z nevyplneného študijného plánu, v ktorom je tento výber povolený. Povinné a opakované predmety sa zvolia automaticky. ďalej je výber prenechaný na študenta. Prístup k funkcii pre každého študenta je chránený heslom.

     

    Kontrola vyplneného študijného plánu (I)

     

    Kontrolujú sa podmienky správnosti výberu (splnený minimálny požadovaný počet kreditov na semester/rok, splnený minimálny počet kreditov pre skupiny predmetov – ak je splnený maximálny celkový počet kreditov na semester/rok, viacnásobne zvolený predmet, môže obsahovať aj ďalšie kontroly).

     

    Záverečná kontrola vyplnených študijných plánov (I)

     

    Kontrola vykonávaná na komplexné overenie správnosti výberu určenej množiny študijných plánov. Umožňuje vykonávať kontroly na: splnenie minimálneho požadovaného počtu kreditov na semester/rok, splnenie minimálneho počtu kreditov pre skupiny predmetov – ak je splnený maximálny celkový počet kreditov na semester/rok, viacnásobne zvolený predmet, nadväznosť predmetov, zapísané opakované predmety, splnenie minimálneho počtu študentov na predmet. Možnosť zadať filter na sledované chyby, prípadne upozornenia. Funkcia je prístupná iba privilegovanej osobe.

     

    Prezeranie nevyplneného študijného plánu (II)

     

    Funkcia zabezpečuje zobrazenie požadovaného nevyplneného študijného plánu, v ktorom nie je možné modifikovať. Prístup k funkcii nie je chránený heslom. Využitie iba za úmyslom pozretia ponúkaných nevyplnených študijných plánov (netreba posielať heslo na overenie, ak si chce študent iba pozrieť študijný plán a výber predmetov uskutočniť neskôr).

     

     

     

    1. Špecifikácia údajov v systéme

     

      1. Logický model údajov.
























        2.  

         

         

         

         

      2. Opis údajových entít

     

    Predmety

     

    Skupiny predmetov

     

    Požadované predmety

     

    Študenti

     

    Učitelia

     

    Skupiny užívateľov

     

    Štúdium

     

    Výuka

     

    Miestnosti

     

    Rozvrhy

     

    Opis postupu tvorby logického modelu údajov

     

    Pri tvorbe dátového modelu sme vychádzali z dátového modelu, uvedeného v analyzovanej práci č.2. Avšak vzhľadom na požadované rozšírenia bolo nutné pridať nové dátové entity a čiastočne upraviť význam existujúcich entít.

    Úplne novými entitami sú Výuka, Štúdium a Skupiny predmetov, ktoré slúžia na ukladanie informácií o štúdijných plánoch a požiadavkách na predmet. Entita Rozvrhy má, vzhľadom na požiadavku uchovávania rôznych rozvrhov pre rozličné týždne a taktiež nutnosť ukladať rozvrh skúšok, zmenenú štruktúru. Časť údajov, ktoré boli uchovávané v entite Predmety sú presunuté do entity Výuka.

     

     

     

    1. Špecifikácia správania systému

     

      1. Editovanie požiadaviek na predmet

     

     

    Postup pri editácii požiadaviek na predmet:

    1. Zvoliť položku sprístupňujúcu túto časť aplikácie

    2. Prihlásiť sa ako užívateľ oprávnený vykonávať túto editáciu

    3. Zadať číslo predmetu a prednášajúceho (resp. zodpovedného za predmet), pričom prednastavená hodnota bude prihlasovacie meno užívateľa

    4. Systém zistí, či dané požiadavky sú už evidované:

      1. Ak áno – umožní opravovať existujúce dáta

      2. Ak nie – umožní pridať nové požiadavky do systému

    5. Ukončenie editácie:

      1. Uložiť zadané dáta/zmeny do databázy

      2. Neuložiť dáta/zmeny do databázy

      3. Vymazať existujúce dáta z databázy (iba ak boli už pred tým zadané)

    6. Odhlásiť sa zo systému

      1. Editovanie rozvrhu

    Uvedené kritéria bude užívateľ vyberať formou voliteľných položiek zo zoznamov.
      1. Editovanie rozvrhu skúšok

    Uvedené kritéria bude užívateľ vyberať formou voliteľných položiek zo zoznamov.

     

    Postup pri editovaní skúšky pre vybraný predmet

    1. Vyber predmetu zo zoznamu predmetov pre konkrétne zameranie

    2. Informovanie o alternatívach rozdelenia do miestnosti

    / napr. 1 x miestnosť 300 alebo 2 x miestnosť 150 /

    3. Technikou drag-and-drop alebo editovaním vyplniť časové políčko/políčka v rozvrhu

    3.1 Dĺžka trvania skúšky je prednastavená na štandardnú hodnotu 3 hodiny

    4. Spustenie kontroly

    AK je dostatočná kapacita miestností pre skúšku pre vybraný predmet

    TAK

    Všetci študenti, ktorí majú zapísaný vybraný predmet, sa podľa abecedy priradia rovnomerne do vybraných miestností

    INAK

    Znovu bod 2.

      1. Kontrola kolízií v rozvrhu skúšok

     

     

      1. Porovnávanie rozvrhu s požiadavkami na predmety

     

      1. pri editovaní rozvrhu pre predmet
      2. pri prezeraní rozvrhu pre predmet (iba oprávnenému užívateľovi)

     

    Postup pri porovnávaní rozvrhu s požiadavkami na predmet:

    1. Vojsť do jednej z uvedených častí aplikácie (a, b)
    2. Stlačiť príslušné tlačítko (uvedené informácie sa zobrazia na obrazovku)
      1. Editovanie a výber študijného plánu

     

     

    Popis správania:

    AK dnes je skôr ako dátum ukončenia výberov TAK

    Zadanie prístupového mena a hesla študenta

    AK správne prístupové meno a heslo TAK

    AK je študent 2. ročníka TAK

    Zvolenie odboru

    Zobrazenie odboru a výberového bloku

    PRE daný výberový blok

    Zobrazenie povinných, povinne voliteľných, voliteľných, opakovaných predmetov

    Zobrazenie odkazu na odporúčané predmety

    V tomto zobrazení možno spôsobom priameho označenia predmetu určiť zapísanie predmetu do ďalšieho školského roku

    OPAKUJ pre každú zmenu výberu v študijnom pláne

    Zobrazenie:

    Zobrazenie celkovej sumy zapísaných kreditov

    AK požiadavka na zapísanie študijného plánu TAK

    AK je splnený maximálny požadovaný počet kreditov na semester/rok TAK

    PRE každú skupinu

    AK počet kreditov zo skupiny je menší ako požadovaný TAK

    Upozornenie na nedostatočný počet kreditov

    AK je vo všetkých skupinách predmetov splnená požiadavka minimálneho počtu kreditov TAK

    Zapísanie študijného plánu a ukončenie

    AK je splnený minimálny požadovaný počet kreditov na semester/rok TAK

    Upozornenie na rozloženie štúdia

    AK výber študijného plánu potvrdený TAK

    Zapísanie študijného plánu a ukončenie

    INAK

    Už nemožno vyberať

      1. Kontrola vyplneného študijného plánu

     

    Kontrolované parametre:

     

    Popis správania:

    PRE všetky zvolené predmety

    Vykonanie kontroly nad študijnými plánmi

    Zobrazenie výsledkov kontroly

      1. Záverečná kontrola vyplnených študijných plánov

     

    Kontrolovať treba:

     

    Popis správania:

    Zvolenie filtra kontrol (štúdium, ročník, odbor, výberový blok, atď.)

    PRE všetky študijné plány

    Vykonanie kontroly nad študijnými plánmi

    Zobrazenie výsledkov kontroly

      1. Prezeranie nevyplneného študijného plánu

     

     

    Popis správania:

    Zvolenie ročníka

    AK ročník obsahuje odbory TAK

    Zvolenie odboru

    Zobrazenie odboru

    AK v odbore sú výberové bloky TAK

    Zvolenie výberového bloku

    Zobrazenie výberového bloku

    Zobrazenie nevyplneného študijného plánu pre daný výberový blok

    INAK

    Zobrazenie šablóny študijného plánu pre daný odbor

    INAK

    Zobrazenie šablóny študijného plánu pre daný ročník

     

      1. Automatická kontrola kolízií v rozvrhu

     

      1. Import údajov

     

     

     

      1. Editovanie údajov

     

     

      1. Výstup na WWW

     

      1. Export údajov

     

     

    8. Ďalšie požiadavky a ohraničenia

     

      1. Požiadavky

        2.  

        1. Generovanie rozvrhu

          2.  

          Generovanie rozvrhu je problém, ktorý by vyžadoval samostatnú dôkladnú analýzu, vyšpecifikovanie všetkých kolízií, ktoré treba riešiť. Kvôli jeho zložitosti a nedostatku času túto časť vynechávame.

           

           

        2. Hromadné spracovanie údajov

     

     

        1. Požiadavky na prevádzku systému

     

     

      1. Ohraničenia

     

    Prezeranie údajov bude možné bez identifikácie užívateľa. Ostatné činnosti budú sprístupňované podľa pridelených práv, pričom definícia týchto práv spolu s prihlasovacími menami a heslami bude uložená priamo na servri.