Laboratoriniai darbai

Laboratorinių darbų metu studentai:

• Susiskirstę komandomis po 3-4 žmones atlieka projektinius darbus, pristato bei aptaria jų atlikimo eigą ir galutinius darbo rezultatus.
• Individualiai atlieka mini-užduotis ir aptaria jų rezultatus.

Projektinių darbų atsiskaitymo terminai:

• 1 darbas - iki spalio 13;
• 2 darbas - iki lapkričio 10;
• 3 darbas - iki gruodžio 22.

Įvertinimas už projektinį darbą susideda iš 90% už grupės atliktą darbą (paruoštą dokumentą ar sistemos prototipą) ir 10% už darbo pristatymą. Už darbų rezultatų pristatymą kiekvienas studentas vertinamas individualiai. Kiekvieną pavėluotą savaitę projektinio darbo įvertinimas mažinamas 1 balu. Projektinis darbas vertinamas atsižvelgiant ne tik į galutinį rezultatą, bet ir į darbą semestro metu (darbų eigos pristatymus, iškilusių problemų ir priimtų sprendimų aptarimus laboratorinių darbų metu).

Projektinių darbų eigoje parengti dokumentai turi būti apipavidalinti pagal PS katedros metodinius reikalavimus kursiniams darbams (atsiskaitant pateikiama nuoroda į PFD dokumentą MIF GitLAB aplinkoje). Kiekvieną dokumentą turi sudaryti šios dalys:

• Titulinis lapas.
• Anotacija.
• Turinys.
• Įvadas.
• Dėstymas.
• Terminų žodynas.
• Literatūros sąrašas.
• Priedai.

Visos dalys turi būti logiškai susietos. Dėstymo dalis priklauso nuo regiamo dokumento. Kiekvienam projektiniam darbui rekomenduojama struktūra pateikiama žemiau.

1 projektinis darbas: projektavimas

Programų sisitemos architektūra apibrėžiama, aprašant sistemą keliais aspektais (pjūviais). Ruošiant PS sistemos architektūros dokumentą laboratorinių darbų metu, rekomenduojama naudoti 4+1 architektūros pjūvių modelį. Taikant šį modelį, PS architektūros dokumentas turi turėti sekančias dalis:

• Užduotys ir jų vykdymo scenarijai (angl. Use case view)

  Šis skyrius turi dvejopą paskirtį: sistemos naudojimo atvejų vykdymo scenarijai gali būti atspirties taškas architektūros apibrėžimui, o apibrėžus architektūrą - jos korektiškumo tikrinimui. Šiame architektūros pjūvyje dažniausiai naudojamos UML naudojimo atvejų ir sekų diagramos. Struktūrinio PS modelio validavimui rekomenduojama naudoti ir UML objektų diagramas.

• Struktūrinis programų sistemos modelis (angl. Logical view)

  Šiame skyriuje daugiausia koncentruojamasi į funkcinių reikalavimų įgyvendinimą. Sistema aprašoma, apibrėžiant ją įgyvendinančias klases ir ryšius tarp jų bei sąsajas. Klasės įprastai grupuojamos į paketus, atspindinčius programų sistemos loginę struktūrą. Apibrėžiant struktūrinį PS modelį dažniausiai naudojamos UML klasių, paketų, objektų, sekų ir bendradarbiavimo diagramos.

• Dinaminis programų sistemos modelis (angl. Process view)

  Šiame skyriuje daugiausiai koncentruojamasi į programų sistemos elgseną jos vykdymo metu, be funkcinių savybių nagrinėjamos ir nefunkcinės, tokios kaip patikimumas ir greitaveika. Aprašant dinamines sistemos savybes įprastai naudojamos UML veiklos, sekų, objektų ir būsenų diagramos.

• Programų sistemos komponentai (angl. Development view)

  Šiame skyriuje sistemą įgyvendinančios klasės suskirstomos į komponentus, apibrėžiami ryšiai tarp jų. Komponentai ir jų ryšiai apibrėžia programų sistemos loginę struktūrą - sluoksnius, posistemių hierarchiją bei fizinę struktūrą - programuotojų gaminamus artefaktus. Šiame architektūros pjūvyje nagrinėjami ir sistemos konfigūravimo klausimai. Apibrėžiant PS komponentus ir jų ryšius dažniausiai naudojama UML komponentų ir paketų diagramos.

• Komponentų išskirstymas tinkle (angl. Physical view)

  Šiame skyriuje apibrėžiama PS naudojama aparatinė įranga, komunikacija tarp tinklo mazgų bei PS komponentų išdėstymas juose. Apibrėžiant sistemos komponentų išskirstymą tinkle dažniausiai naudojamos UML diegimo ir komponentų diagramos.

Atliekant pirmą projektinį darbą turi būti parengtas ne tik sistemos projektas, bet ir įgyvendintas veikiantis sistemos prototipas. Prototipo įgyvendinimui techniniai ribojimai netaikomi (programavimo kalba, operacinė sistema ar pan.), tačiau sistema turi atitikti sistemos projektą. Jei kuriant prototipą paaiškėja, kad sistemos projektas nekorektiškas, projektas turi būti pataisomas.

2 projektinis darbas: reikalavimai

Antrasis projektinis darbas skirtas reikalavimų specifikavimui. Reikalavimų specifikacija turi būti paruošta laikantis aukščiau pateiktų bendrosios dokumento struktūros reikalavimų, o dėstymo dalyje pateikiama žemiau nurodyta informacija. Siekiant dokumento aiškumo, skyriai dokumente gali būti skirstomi į poskyrius. Dokumente pateikiami reikalavimai turi būti identifikuojami ir anotuoti.

• Funkciniai reikalavimai

  Šiame skyriuje pateikiami reikalavimai detaliai apibrėžiantys pagrindines ir pagalbines sistemos funkcijas.

• Nefunkciniai reikalavimai

  Vidinių interfeisų reikalavimai: OS naudojimo reikalavimai, sąveikos su DB reikalavimai, dokumentų mainų reikalavimai, darbo kompiuterių tinkluose reikalavimai, sąveikos su kitomis programomis reikalavimai, programavimo aplinkos reikalavimai. Veikimo reikalavimai: vaizdavimo ir skaičiavimų tikslumo reikalavimai, patikimumo reikalavimai, robastiškumo reikalavimai, našumo reikalavimai. Diegimo reikalavimai: ruošinio reikalavimai, instaliavimo reikalavimai, pradinio DB kaupimo reikalavimai, sistemos įsisavinamumo reikalavimai. Aptarnavimo ir priežiūros reikalavimai, tiražuojamumo reikalavimai, apsaugos reikalavimai, juridiniai reikalavimai.

• Vartotojo interfeiso reikalavimai

  Šiame skyriuje pateikiami metaforos reikalavimai, formuluojamos užduotys, užduočių formulavimo kalbos reilkalavimai, užduočių formulavimo protokolo reikalavimai, interfeiso darnos ir standartizavimo reikalavimai, pranešimų formulavimo reikalavimai ir interfeiso individualizavimo reikalavimai.

3 projektinis darbas: dalykinės srities analizė

Trečiasis projektinis darbas skirtas užsakovo poreikių ir dalykinės srities analizei. Projektinis darbas turi būti paruoštas laikantis aukščiau pateiktų bendrosios dokumento struktūros reikalavimų, o dėstymo dalyje pateikiama žemiau nurodyta informacija.

• Verslo proceso aprašas.

  Šiame skyriuje bendrai aprašomas nagrinėjamas verslas ar rinka, įvardinamos pagrindinės jo veiklos ir tikslai. Čia (ir skyriuose iki sistemos naudojimo scenarijaus) nagrinėjamas esamas verslo procesas.

• Išorinė proceso analizė.

  Išorinė verslo proceso analizė vykdoma, siekiant identifikuoti grėsmes ar neišnaudotas nagrinėjamo verslo galimybes. Šiame skyriuje pateikiami verslo sistemos įeigos, išeigos, reguliavimo ir įvaizdžio valdymo tikslai, jų matavimo būdai, kritinės reikšmės bei esami įverčiai. Atliekant išorinę verslo ar rinkos analizę, į ją žiūrima kaip į juodą dėžę, nenagrinėjant jos vidinės struktūros ir procesų.

• Vidinė proceso analizė.

  Vidinė verslo proceso analizė atliekama, siekiant nustatyti nagrinėjamo verslo stiprybes ar silpnybes, kylančias iš paties verslo proceso, o ne jo aplinkos. Vidinė proceso (dalykinės srities) analizė atliekama keliais aspektais.

  • Dalykinės srities statinė struktūra.

    Šiame skyriuje apibrėžiamos pagrindinės dalykinės srities esybės. Esybės turi būti formuluojamos dalykinės srities kalba, atsiribojant nuo techninių detalių. Dalykinės srities struktūra turi būti pateikiama UML klasių diagramomis bei jas aprašančiu tekstu. Be UML klasių diagramų rekomenduojama pateikti ir dalykinės srities žodyną, kuriame kiekviena diagramose paminėta esybė aprašoma detaliau. Tokio žodyno sudarymas sumažina klaidų tikimybę, kai projekto dalyviai tas pačias sąvokas supranta skirtingai. Šiame skyriuje apibrėžtos sąvokos (esybės) turi būti nuosekliai naudojamos ir kituose dokumento skyriuose.

  • Užduotys.

    Šiame skyriuje nagrinėjamos pagrindinės sistemoje atliekamos užduotys ir su jomis susiję agentai. Pagrindinės užduotys turi būti pateikiamos UML užduočių diagramomis bei tekstiniu jų aprašymu. Šiame skyriuje pateikiamos tik bendriausios užduotys, kurios atitinka tikslus, siekiamus išorinių, sistemos atveju, agentų. Tokios užduotys (ar agentų siekiami tikslai) dažnai sutampa su bendriausiais verslo procesais, kurie, savo ruožtu, aprašo žingsnius, kuriuos reikia atlikti, norint tų tikslų pasiekti. Tokie procesai gali būti aprašomi UML veiklos arba BPMN diagramomis.

  • Užduočių vykdymo scenarijai.

    Siekiant detalizuoti bendriausių užduočių vykdymo scenarijus, atliekama funkcinė dalykinės srities dekompozicija. Šiame skyriuje nagrinėjamos žemesnio abstrakcijos lygmens užduotys. Tokios užduotys atitinka tikslus, kurių agentai siekia nebe visos organizacijos, bet jos padalinių ar naudojamų sistemų mastu. Identifikuotos užduotys aprašomos užduočių diagramomis, bei aprašomos tekstu. Detalesniems užduočių vykdymo scenarijams aprašyti įprastai naudojamos sekų diagramos. Taip verslo funkcijos dekomponuojamos tol, kol pakankamai detaliai išnagrinėjamos su vykdomu projektu susijusios jo dalys.

  • Dalykinės srities dinaminė struktūra.

    Šiame skyriuje pateikiami pagrindinių dalykinės srities esybių gyvavimo ciklai. Esybių gyvavimo ciklus patogu pateikti UML būsenų diagramomis. Kiekviena būsenų diagrama aprašo vienos esybės būsenas ir įvykius, kurie tą būseną įtakoja. Diagramose pateiktos būsenos bei perėjimai tarp jų turi būti aprašyti ir tekstu, detaliau paaiškinant pagrindinius diagramų akcentus.

• Analizės rezultatai.

  Šiame skyriuje vidinė ir išorinė verslo proceso analizė apibendrinama pateikiant esmines įžvalgas SSGG (SWOT) lentelės pavidalu. Lentelėje struktūrizuotai pateikiamos verslo stiprybės, silpnybės, jam kylančios grėsmės ir atsiradusios neišnaudotos galimybės. Lentelėje pateikiama informacija turi būti pagrįsta vidinės ir išorinės analizės medžiaga.

• Verslo proceso tobulinimo strategija.

  Šiame skyriuje, remiantis analizės rezultatais, pateikiama verslo tobulinimo strategija. Strategija pateikiama bendru aprašu bei struktūrizuotai, įvardinant strateginius tikslus. Kiekvienam strateginiam tikslui (nusako, ką norime pasiekti) apibrėžiami operaciniai tikslai, nusakantys kaip bus siekiama strateginių tikslų (kokius darbus ar žingsnius reikia atlikti).

• Sistemos naudojimo scenarijus.

  Atliekant šį projektinį darbą, strateginiai tikslai turėtų būti suformuluoti taip, kad vienas ar keli operaciniai tikslai būtų susiję su informacinės sistemos kūrimu ar diegimu. Praktikoje strateginių tikslų negalima formuluoti siekiant jais pateisinti sistemos kūrimą ar vystymą, tačiau siekiant išlaikyti projektinių darbų vientisumą, su laboratorinius darbus vedančio dėstytojo patvirtinimu, tokia prielaida padaroma. Šiame skyriuje ir jo skyreliuose aprašomas siūlomos kurti sistemos naudojimo scenarijus. Scenarijus aprašomas nesigilinant į sistemos įgyvendinimo priemones, akcentuojant funkcines sistemos savybes ir agentų sąveiką su ja.

  • Scenarijus.

    Šiame skyriuje pateikiamas scenarijus, nurodantis, kaip sistema apsikeis pranešimais su dalykinės srities agentais. Scenarijus turi būti pateikiamas UML sekų diagrama su tekstiniu diagramos aprašu, kuriame akcentuojami ir detalizuojami pagrindiniai sąveikos aspektai.

  • Sistemos teikiama nauda.

    Šiame skyriuje pateikiama UML užduočių diagrama, kurioje pateikiamos kuriamos sistemos lygmens užduotys ir susiję agentai. Šiose diagramose agentai yra išoriniai kuriamos sistemos atžvilgiu, tačiau jie gali būti vidiniai arba išoriniai nagrinėjamos dalykinės srities atžvilgiu.

  • Esama būklė.

    Šiame skyriuje pateikiama esama įmonės infrastruktūra, akcentuojant priemones, kurių gali prireikti (ar kurių galima bus atsisakyti) diegiant ar įdiegus siūlomą programų sistemą.

  • Priemonės scenarijui įgyvendinti.

    Šiame skyriuje įvardinama, kokių priemonių reikės siūlomam scenarijui įgyvendinti. Priemonės apima reikiamus serverius, licencijas, perkamas paslaugas ir visą kitą, ko reikia, kad sistema būtų sėkmingai įdiegta ir eksploatuojama.

• Įgyvendinamumo ir naudos analizė.

  Šiame skyriuje įvairiais aspektais nagrinėjamos galimybės įgyvendinti siūlomą sistemą.

  • Operacinis įgyvendinamumas.

    Šiame skyriuje analizuojami sistemos diegimo inovaciniai slenksčiai ir pateikiamos priemonės, kaip tokių trukdžių išvengti, ar sušvelninti jų įtaką.

  • Techninis įgyvendinamumas.

    Šiame skyriuje analizuojama, ar sistema gali būti įgyvendinama techniškai. Čia turi būti parodoma, kad projekto komanda žino, kaip įgyvendinti kritinius sistemos komponentus.

  • Ekonominis įgyvendinamumas.

    Šiame skyriuje turi būti pagrindžiamas projekto atsiperkamumas. Tokiam pagrindimui reikia suskaičiuoti preliminarią projekto kainą ir verslui atnešamą naudą (pinigais).

  • Juridinis įgyvendinamumas.

    Šiame skyriuje analizuojami su sistemos įgyvendinimu ar eksploatavimu susiję teisės aktai. Parodoma, kad sistema nepažeis galiojančių įstatymų, pagrindžiama kodėl ir kaip.