Grįžti į sąrašą

Studijų tvarkaraščių planavimo, valdymo ir publikavimo informacinė sistema

Išanalizuota

VšĮ Kauno kolegija (PV)

Rinkos konsultacijaCPV: 72212517 - IT programinės įrangos kūrimo paslaugos
ID: 78586142026-05-14 09:20
Atidaryti CVP IS

Aprašymas

Kauno kolegija perka Studijų tvarkaraščių planavimo, valdymo ir publikavimo informacinės sistemos sukūrimo, įdiegimo ir priežiūros paslaugas. Ši sistema padės centralizuoti tvarkaraščių sudarymą, sumažins rankinių klaidų tikimybę ir užtikrins efektyvią informacijos sklaidą studentams. Projekto metu bus modernizuoti tvarkaraščių procesai, įskaitant automatinį generavimą, konfliktų tikrinimą ir viešą tvarkaraščių publikavimą.

Kvalifikaciniai reikalavimai

  • 1Tiekėjo vidutinės metinės pajamos iš veiklos, su kuria susijęs atliekamas pirkimas, paskutiniais 3 finansiniais metais, o jeigu tiekėjas įregistruotas vėliau ar veiklą atitinkamoje srityje pradėjo vėliau – nuo tiekėjo įregistravimo ar veiklos su pirkimu susijusioje srityje pradžios yra ne mažesnės kaip 54000 (penkiasdešimt keturi tūkstančiai) Eur be PVM. Laikoma, kad su atliekamu pirkimu susijusi veikla yra: informacinių sistemų kūrimo ir / arba diegimo ir / arba tobulinimo paslaugų teikimas.
  • 2Tiekėjas per pastaruosius 3 metus turi būti tinkamai ir laiku įgyvendinęs bent vieną sutartį / projektą (ar užbaigtą jo etapą), susijusį su laiko valdymo informacinių sistemų kūrimu, diegimu ar tobulinimu (pvz.: rezervacijų ar tvarkaraščių valdymo informacinės sistemos kūrimu, diegimu ar tobulinimu ir kt.)
  • 3Tiekėjas turi būti įdiegęs ir taikyti informacijos saugos vadybos sistemą, atitinkančią ISO/IEC 27001 standarto arba jam lygiaverčio standarto reikalavimus, ir užtikrinančią informacijos saugumą kuriant, diegiant ir prižiūrint informacines sistemas.
  • 4Tiekėjo siūlomi specialistai turi gebėti gerai rašyti, kalbėti ir suprasti lietuvių kalba. Jei lietuvių kalba nėra gimtoji – ne žemesnis kaip C1 lygis pagal Europass kalbų pasą. Jei specialistas nemoka ar nekalba lietuvių kalba, reikalavimas gali būti tenkinamas, numatant vertimo žodžiu ir raštu paslaugas. Išlaidas vertimo paslaugoms prisiima tiekėjas.
  • 5Specialistas – Projekto vadovas: Per pastaruosius 5 metus turi ne trumpesnę nei 2 metų vadovavimo informacinių sistemų kūrimo projektams patirtį.
  • 6Specialistas – IS architektas: a) Per pastaruosius 5 metus vykdė informacinių sistemų architekto funkcijas kuriant informacinę sistemą (bent viename projekte), kuri atitinka šiuos reikalavimus: 1) sistema susijusi su laiko valdymo informacinių sistemų kūrimu, pvz.: rezervacijų ar tvarkaraščių valdymo informacinės sistemos kūrimu ar diegimu ir kt. 2) sistema yra integruota su ne mažiau nei viena informacine sistema ar registru.
  • 7Specialistas – IS testuotojas: a) Per pastaruosius 5 metus turi ne mažiau kaip 2 metų informacinių sistemų testavimo patirtį.
  • 8Specialistas – BackEnd programuotojas: a) per paskutinius 5 metus turi ne mažiau kaip 3 metų BackEnd dalies programavimo patirtį, kuriant informacines sistemas.
  • 9Specialistas – FrontEnd programuotojas: a) per paskutinius 5 metus turi ne mažiau kaip 3 metų FrontEnd dalies programavimo patirtį, kuriant informacines sistemas.

Techniniai reikalavimai

Saugumas

  • 1Sistemos administracinė dalis turi būti logiškai atskirta nuo viešosios prieigos, užtikrinant, kad administravimo funkcijos nebūtų pasiekiamos neautorizuotiems naudotojams.
  • 2Sistema turi užtikrinti prieigos kontrolę pagal naudotojų roles, leidžiant pasiekti tik tas funkcijas ir duomenis, kurie atitinka priskirtas teises.
  • 3Duomenų perdavimas tarp naudotojo ir Sistemos turi būti apsaugotas naudojant saugius ryšio protokolus (pvz., HTTPS/TLS).
  • 4Viešoji Sistemos dalis neturi atskleisti vidinės Sistemos informacijos, techninių detalių ar kitų naudotojų duomenų.
  • 5Sistema turi užtikrinti saugų naudotojų autentifikavimą ir slaptažodžių saugojimą.
  • 6Sistema turi registruoti naudotojų veiksmus (audit log), leidžiančius atsekti svarbius veiksmus ir pakeitimus Sistemoje.
  • 7Sistema turi užtikrinti apsaugą nuo dažniausiai pasitaikančių saugumo pažeidžiamumų (pvz., OWASP Top 10 tipo grėsmių).
  • 8Turi būti užtikrintas duomenų vientisumas ir apsauga nuo neteisėto pakeitimo ar praradimo.
  • 9Sistema turi turėti sesijų valdymo mechanizmus (pvz., automatinį atsijungimą po neaktyvumo laikotarpio).
  • 10Turi būti užtikrinta prieigos kontrolė prie administracinių funkcijų (pvz., per papildomus saugumo mechanizmus, jei taikoma).
  • 11Sistema turi užtikrinti, kad klaidų pranešimai naudotojams neatskleistų jautrios techninės informacijos.

Duomenų importas

  • 1Sistema turi sudaryti galimybę importuoti pradinius duomenis.
  • 2Importuojami duomenys turi atitikti iš anksto apibrėžtą struktūrą.
  • 3Importo metu sistema turi atlikti pagrindinį duomenų tikrinimą.
  • 4Importo klaidos atveju duomenys neturi būti iš dalies išsaugoti.

Konfliktų valdymas

  • 1Sistema turi automatiškai tikrinti tvarkaraščio konfliktus.
  • 2Apie aptiktus konfliktus turi būti informuojamas planuotojas.
  • 3Konflikto atvejis neturi automatiškai blokuoti įrašo išsaugojimo.

Naudotojų valdymas

  • 1Sistema turi palaikyti ne mažiau kaip dvi naudotojų roles. Galutinis rolių sąrašas ir jų teisės suderinami, tvirtinant projekto vykdymo planą.
  • 2Sistema turi suteikti administratoriui galimybę kurti, redaguoti ir deaktyvuoti naudotojų paskyras.
  • 3Sistema turi užtikrinti naudotojų autentifikaciją naudojant prisijungimo vardą ir slaptažodį.
  • 4Sistema turi užtikrinti, kad naudotojai negalėtų atlikti veiksmų, viršijančių jiems priskirtas teises.

Veikimas ir našumas

  • 1Sistema turi užtikrinti pagrindinių naudotojų operacijų (pvz., tvarkaraščio peržiūros, redagavimo, filtravimo) atsako laiką ne ilgesnį kaip 300 ms ne mažiau kaip 95 % atvejų esant normaliam apkrovimui.
  • 2Sistema turi veikti stabiliai esant numatytam naudotojų skaičiui ir apkrovai, užtikrinant nepertraukiamą veikimą be kritinių sutrikimų.
  • 3Duomenų importo operacijos turi būti vykdomos efektyviai – tipinio importo veiksmo trukmė neturi viršyti 10 sekundžių, priklausomai nuo duomenų apimties.
  • 4Tvarkaraščio konfliktų tikrinimas turi būti atliekamas realiu laiku, užtikrinant atsako laiką ne ilgesnį kaip 300 ms vienai tikrinimo operacijai.
  • 5Sistema turi palaikyti vienalaikį darbą su keliais naudotojais be pastebimo našumo degradavimo.
  • 6Sistema turi būti suprojektuota taip, kad esant apkrovos augimui būtų galima didinti našumą (pvz., horizontaliai plečiant resursus).
  • 7Sistemos pasiekiamumas turi būti ne mažesnis kaip 99 % per mėnesį, išskyrus planinius priežiūros darbus.
  • 8Sistema turi užtikrinti, kad duomenų užklausos (pvz., tvarkaraščio filtravimas ar paieška) būtų vykdomos per priimtiną laiką (iki 1 sekundės).

Semestro konfigūracija

  • 1Sistema turi palaikyti semestrų kūrimą ir valdymą.
  • 2Prieš sudarant tvarkaraštį turi būti nustatyta semestro konfigūracija (darbo dienos, laiko tarpsniai ir kt.).
  • 3Konfigūracija turi galioti visoms to semestro savaitėms.

Tvarkaraščio sudarymas

  • 1Sistema turi turėti automatinio tvarkaraščio generavimo funkciją.
  • 2Generavimo metu sistema turi atsižvelgti į dėstytojų prieinamumą.
  • 3Sistema turi tikrinti auditorijų tinkamumą pagal nustatytus kriterijus (pvz., grupės dydį).
  • 4Sugeneruotas tvarkaraštis turi būti išsaugomas kaip juodraštis ir nerodomas viešai iki atskiro patvirtinimo.
  • 5Planuotojas turi galėti rankiniu būdu kurti ir redaguoti tvarkaraščio įrašus.
  • 6Tvarkaraščio įrašai turi būti perkeliami vizualiai (pvz., vilkimo būdu).
  • 7Sistema turi suteikti galimybę kopijuoti tvarkaraštį tarp laikotarpių.
  • 8Sistema turi sekti, kiek semestro valandų pagal dalyką ir grupę jau suplanuota.

Plėtimasis ir palaikymas

  • 1Sistema turi būti suprojektuota taip, kad būtų galima plėsti jos naudojimą įtraukiant papildomus padalinius, fakultetus ar kitus organizacinius vienetus, nekeičiant esminės architektūros.
  • 2Sistemos architektūra turi būti modulinė, užtikrinant pagrindinių funkcinių dalių atskyrimą, kad jų pakeitimai ar plėtra galėtų būti vykdomi neperrašant visos sistemos.
  • 3Sistema turi sudaryti galimybę plėsti funkcionalumą diegiant naujus modulius ar funkcijas.
  • 4Sistema turi palaikyti konfigūravimo galimybes (pvz., nustatymų keitimą be programavimo), leidžiančias adaptuoti Sistemą prie besikeičiančių poreikių.
  • 5Sistema turi užtikrinti suderinamumą su galimomis ateities integracijomis su kitomis informacinėmis sistemomis.
  • 6Sistemos atnaujinimai turi būti diegiami taip, kad būtų minimaliai trikdomas Sistemos veikimas (pvz., be ilgo nepasiekiamumo).
  • 7Sistema turi užtikrinti galimybę atlikti reguliarius atnaujinimus ir pataisas (bug fixes) nepažeidžiant esamo funkcionalumo.
  • 8Turi būti užtikrintas Sistemos versijų valdymas ir galimybė, esant poreikiui, grįžti prie ankstesnės versijos (rollback).
  • 9Sistema turi būti parengta ilgalaikiam palaikymui, užtikrinant aiškią architektūrą, dokumentaciją ir standartizuotus sprendimus.

Tvarkaraščių peržiūra

  • 1Sistema turi rodyti tvarkaraštį kalendoriaus formato vaizde.
  • 2Planuotojas turi matyti juodraščio būsenos tvarkaraštį ir galėti jį redaguoti.
  • 3Turi būti galimybė filtruoti tvarkaraštį pagal skirtingus parametrus (pvz., grupę, dėstytoją, auditoriją).
  • 4Viešoji peržiūra turi būti prieinama be prisijungimo.
  • 5Viešojoje peržiūroje turi būti rodoma tik paskelbta tvarkaraščio versija.

Tvarkaraščių publikavimas

  • 1Tvarkaraščio pakeitimai neturi būti automatiškai matomi - reikalingas atskiras paskelbimo veiksmas.
  • 2Tvarkaraštis turėtų turėti galimybę paskelbti dalinai užpildytą semestrą.
  • 3Po paskelbimo turi išlikti galimybė toliau redaguoti tvarkaraštį kaip juodraštį.

Bendrieji sistemos reikalavimai

  • 1Sukurtos programinės įrangos šaltinio kodas turi priklausyti Užsakovui.
  • 2Sistemos programinis kodas turi būti saugomas Užsakovo valdomoje kodo saugykloje (pvz., GitHub ar analogiškoje platformoje).
  • 3Sistemos kūrimui ir eksploatavimui turi būti įrengtos ir palaikomos šios aplinkos: a. kūrimo aplinka – skirta Sistemos kūrimui ir konfigūravimui; b. testavimo aplinka – skirta Sistemos testavimui; c. produkcinė aplinka – skirta galutiniam Sistemos naudojimui.
  • 4Sistema turi būti dokumentuota – parengta techninė dokumentacija, aprašanti Sistemos veikimo principus, architektūrą ir integracijas.
  • 5Turi būti parengti naudotojų vadovai pagal naudotojų roles.
  • 6Turi būti organizuoti ir įvykdyti Sistemos naudotojų mokymai pagal naudotojų roles.
  • 7Sistemai turi būti taikoma garantinė priežiūra sutartyje nustatytą laikotarpį.
  • 8Sistema turi užtikrinti naudotojų veiksmų registravimą (audit log): bendrieji veiksmų žurnalai saugomi ne trumpiau kaip 90 dienų; kritinių veiksmų (pvz., administracinių operacijų) žurnalai saugomi ne trumpiau kaip 180 dienų.
  • 9Paslaugų teikėjas gali siūlyti alternatyvius techninius sprendimus ar įgyvendinimo būdus, jei jie užtikrina lygiavertį ar geresnį funkcionalumą ir neprieštarauja pirkimo tikslams bei teisės aktams. Tokie sprendimai turi būti suderinti su Užsakovu.
  • 10Siūlomi alternatyvūs architektūriniai ar technologiniai sprendimai turi užtikrinti Sistemos patikimumą, saugumą, našumą, plėtrą ir prieinamumą. Sprendimų tinkamumas vertinamas ir tvirtinamas Užsakovo.

Dokumentai4

  • Tiekėjų kvalifikacijos reikalavimai_2026_05_13.docx
  • Tvarkarasčių sistema Technine specifikacija.docx
  • 1235_7858614.pdf
  • Kvietimas-rinkos-konsultacijai_Tvarkaraščių sistema.docx