Bendrabučių apgyvendinimo informacinė sistemos sukūrimas
Išanalizuota
Vilniaus universitetas (PV)
Rinkos konsultacijaCPV: 72200000 - Programinės įrangos programavimo ir konsultacinės paslaugos
ID: 78897952026-05-15 11:26
Atidaryti CVP ISAprašymas
Vilniaus universitetas ieško sprendimo studentų apgyvendinimo paslaugoms valdyti. Siekiama sukurti centralizuotą, žiniatinklio pagrindu veikiančią informacinę sistemą, kuri automatizuotų rezervavimą, sutarčių sudarymą, sąskaitų išrašymą ir problemas, gerintų veiklos efektyvumą, skaidrumą ir teiktų savitarnos galimybes nuomininkams.
Kvalifikaciniai reikalavimai
Kvalifikacinių reikalavimų nerasta
Techniniai reikalavimai
Sutarčių valdymas
- 1Sistema turi leisti sukurti sutartį naujam arba esamam nuomininkui, taikant kainodaros taisykles, nustatant sutarties trukmę ir inicijuojant finansinius įrašus.
- 2Turi būti pakopinė kainodara pagal kambario tipą, taikant nuolaidas.
- 3Sutarties terminų logika turi apimti trumpalaikę (<60 dienų) ir ilgalaikę (>=60 dienų) sutartis.
- 4Finansinių procesų inicijavimas: sugeneruoti pirmąją sąskaitą faktūrą, sukurti mokėjimų grafiką, užregistruoti depozitą ir perduoti sutarties duomenis į sąskaitų faktūrų generavimo modulį mokėjimų ir sąskaitų valdymui.
- 5Administratorius turi galėti kurti, atnaujinti, nutraukti ir archyvuoti sutartis, susietas su kambarių paskirstymu ir sąskaitų išrašymu.
- 6Sutartys turi turėti būsenas: juodraštis, aktyvi, nutraukta, archyvuota.
- 7Sutartys ir jų atnaujinimai turi būti dinamiškai generuojami iš konkrečioms kalboms (lietuvių, anglų) skirtų šablonų, naudojant nuomininkų ir įstaigų metaduomenis.
- 8Sutarties patvirtinimo taisyklės turi užtikrinti logiškas datas, galiojantį kambarių paskyrimą ir aktyvius nuomininkus.
- 9Įrenginių valdytojai turi galėti atnaujinti kelias sutartis vienu metu naudodami atrankos įrankius.
Nuomininkų valdymas
- 1Sistema turi registruoti nuomininko profilį, įskaitant asmens ir kontaktinius duomenis, bei atlikti tapatybės patikrinimą per integracijas arba rankinę peržiūrą.
- 2Sistemoje turi būti laukai: vardas, pavardė, kontaktinė informacija, gimimo data / asmens kodas, adresas, globėjas (jei nepilnametis).
- 3Turi būti patvirtinimai dėl duomenų formato, unikalumo ir išdavusios institucijos patikrinimo.
- 4Turi būti saugi vartotojo registracija ir el. pašto patvirtinimas.
- 5Palaikomas slaptažodžio šifravimas ir pasirenkamas daugiafaktorinis autentifikavimas.
- 6Nuomininkai turi galėti atnaujinti asmeninę informaciją, įkelti asmens tapatybės dokumentus ir pridėti kontaktus nelaimės atveju.
- 7Visi profilio pakeitimai turi būti registruojami su laiko žymomis.
- 8Administratoriai turi galėti ieškoti nuomininkų pagal vardą, statusą, tautybę arba sukūrimo datą.
- 9Išplėstiniai filtrai turi palaikyti sutarčių susiejimą ir likučių stebėjimą.
- 10Visi naudotojo veiksmai (pvz., prisijungimas, profilio pakeitimai) turi būti įrašomi audito sekoje atitikties reikalavimams užtikrinimui.
Ataskaitos ir analizė
- 1Sistema privalo palaikyti duomenų eksportą standartiniais formatais (CSV, Excel, JSON, XML) tolesnei analizei.
- 2Ataskaitų suvestinėse vizualizuojami kambarių panaudojimo rodikliai, rodomi šilumos žemėlapiai ir užimtumo laiko juosta pagal patalpas, aukštus ir kambarių tipus.
- 3Duomenys gaunami iš kambarių valdymo modulio ir atnaujinami beveik realiuoju laiku.
- 4Pateikiama bendrų pajamų, neapmokėtų likučių, neapmokėtų sąskaitų ir skolų išieškojimo efektyvumo rodikliai.
- 5Filtrai leidžia segmentuoti finansinius duomenis pagal datų intervalą, mokėtojo tipą (nuomininkas ar organizacija) ir atsiskaitymo būseną.
- 6Vizualizacijos apima juostines diagramas, skritulines diagramas ir laiko eilučių grafikus.
- 7Stebimas paslaugos ir problemų užklausų gyvavimo ciklas, įskaitant reagavimo laiką, sprendimo laiką ir eskalavimo dažnumą.
- 8Prietaisų skydelyje pažymimos neatitinkančios užklausos ir apskaičiuojami SLA laikymosi rodikliai pagal komandą arba paslaugos tipą.
- 9Vartotojai, turintys ataskaitų teikimo teises (administratorius, buhalteris), gali generuoti pasirinktines ataskaitas naudodami filtruojamus parametrus (pvz., sutarties trukmę, studento pilietybę, įstaigą).
- 10Ataskaitų išvesties formatai: CSV, PDF ir XLSX.
- 11Galima suplanuoti automatinį ataskaitų generavimą ir pristatymą.
- 12Laiko eilučių ataskaitos padeda strateginiam planavimui analizuojant metinius rodiklius, pvz., su registracija susijusią paklausą ar finansinius rezultatus.
- 13Ataskaitų suvestinės palaiko išsamias analizės galimybes, kad būtų galima ištirti konkrečius rodiklius (pvz., spustelėjus skolos diagramos segmentą, atidaromi susiję nuomininkų įrašai).
- 14Prieigą prie ataskaitų tipų ir ataskaitų suvestinių reglamentuoja RBAC politikos, užtikrinančios, kad neskelbtini duomenys būtų matomi tik įgaliotiems vaidmenims.
- 15Duomenų vizualizavimo sistema, sukurta naudojant modernias JS bibliotekas (pvz., D3.js arba Chart.js), turi užtikrinti reaguojantį ir prieinamą rodymą visuose įrenginiuose.
- 16Pateikiamas visoje sistemoje saugomų svarbių veiksmų (sutarčių pakeitimų, mokėjimų, administratoriaus prisijungimų) žurnalas su laiko žymomis, IP adresais ir naudotojų ID, kad būtų galima stebėti atitiktį reikalavimams.
Nefunkciniai reikalavimai
- 1Sistema turi palaikyti vidutinį puslapio įkėlimo laiką, mažesnį nei 2 sekundes, ir maksimalų vienu metu veikiančių vartotojų skaičių bent 500.
- 2Serverio pusės operacijos, tokios kaip sutarčių sudarymas ar sąskaitų faktūrų generavimas, 95 % atvejų turi būti atliktos per mažiau nei 3 sekundes.
- 3Programa turi užtikrinti SSL/TLS taikymą visiems perduodamiems duomenims, šifruoti slaptažodžius ir neskelbtinus duomenis naudodama pramonės standartų algoritmus (pvz., „bcrypt“, AES-256) ir laikytis Bendrojo duomenų apsaugos reglamento (BDAR).
- 4Turi būti įdiegta vaidmenimis pagrįsta prieigos kontrolė (RBAC), kad būtų galima apriboti prieigą prie duomenų pagal naudotojų vaidmenis.
- 5Turi būti saugomas audito žurnalas, kuriame būtų užfiksuoti visi svarbiausi sistemos veiksmai (pvz., sutarčių pakeitimai, finansinės operacijos).
- 6Platforma turi būti modulinė, leidžianti nepriklausomai plėsti ir keisti sistemos komponentus, leidžiančią paslaugoms (pvz., sąskaitų išrašymui, vartotojų valdymui) keisti mastelį nepriklausomai.
- 7Sistema turi palaikyti horizontalų mastelio keitimą naudojant konteinerinius diegimus (pvz., „Docker“, „Kubernetes“).
- 8Sistema turi būti suprojektuota taip, kad būtų užtikrintas duomenų prieinamumas, patikimumas ir galimybė plėsti didėjant apkrovai, siekiant palaikyti duomenų augimą.
- 9Sistema turi užtikrinti 99,5 % veikimo laiką, neįskaitant planinės priežiūros.
- 10Siekiant užtikrinti aukštą prieinamumą, turi būti įdiegti automatiniai gedimų prevencijos ir apkrovos balansavimo mechanizmai.
- 11Turi būti įdiegta atsarginių kopijų kūrimo ir atkūrimo po avarijų strategija, įskaitant kasdienes atsargines kopijas ir saugojimą ne vietoje.
- 12Programos sąsaja turi atitikti reaguojančio dizaino principus ir būti prieinama iš visų šiuolaikinių naršyklių.
- 13Privaloma laikytis WCAG 2.1 AA gairių, užtikrinant patogumą asmenims su negalia.
- 14Sąsaja turi palaikyti naršymą tiek klaviatūra, tiek ekrano skaitytuvu.
- 15Integracijai su universiteto ERP sistemomis, studentų informacinėmis sistemomis ir finansiniais įrankiais turi būti pateiktos RESTful API, naudojant JSON formatą.
- 16API turi palaikyti CRUD operacijas su nuomininkais, sutartimis, sąskaitomis faktūromis ir mokėjimais, ir būti dokumentuotos naudojant OpenAPI (Swagger įrankis) specifikacijas.
- 17Sistema turi palaikyti vienkartinį prisijungimą (SSO) ir integraciją su išorinėmis tapatybės valdymo sistemomis, naudojant standartinius protokolus (pvz., OAuth2, OpenID Connect, SAML ar LDAP), kad būtų užtikrintas sklandus autentifikavimas įvairiose įstaigos paslaugose.
- 18Žetonų galiojimo pabaigos, atnaujinimo ir seanso skirtojo laiko valdikliai turi būti konfigūruojami.
- 19Sistema turi palaikyti daugiakalbį turinį, įskaitant anglų ir lietuvių kalbas, su išplėtimo galimybe papildomoms kalboms.
- 20Visi statiniai ir dinaminiai vartotojo sąsajos elementai turi įkelti tekstą iš lokalizuotų išteklių failų.
- 21Platforma turi palaikyti standartinių failų formatų, įskaitant PDF, DOCX, JPEG, PNG, įkėlimą ir peržiūrą.
- 22Dokumentai turi būti nuskaityti dėl kenkėjiškų programų ir patikrinti, ar jie įskaitomi.
- 23Sistemos stebėjimas realiuoju laiku ir centralizuotas registravimas turėtų būti įdiegti naudojant centralizuotus stebėjimo ir registravimo sprendimus (pvz., „Prometheus“, ELK ar lygiaverčius įrankius).
- 24Įspėjimai turi būti suaktyvinami pagal konfigūruojamas ribas (pvz., procesoriaus naudojimas, klaidų dažnis).
- 25Visi įvesties duomenys turi būti patvirtinti tiek kliento, tiek serverio pusėje dėl formato, logikos ir tipo.
- 26Verslo taisyklės (pvz., nepersidengiančios sutartys, galiojantys kambarių dydžiai) turi būti įgyvendinamos naudojant vidinę patvirtinimo logiką.
- 27Visi programos duomenys turi būti saugomi naudojant UTF-8 kodavimą ir palaikyti specialiuosius simbolius.
- 28Duomenų bazė turi užtikrinti duomenų vientisumą, palaikyti ACID operacijas ir ryšių tarp duomenų kontrolę (pvz., naudojant referencinius apribojimus arba lygiavertę logiką).
- 29Sistema turi pateikti kontekstinius patarimus ir laukų aprašymus, kad būtų lengviau naudotis naudotoju.
- 30Turi būti paieškos pagalbos skyrius ir atsisiunčiamas naudotojo vadovas (PDF formatu).
Paraiškų ir eilių valdymas
- 1Pareiškėjai turi pateikti apgyvendinimo prašymus, o sistema turi validuoti duomenis, priskirti eilės numerį ir nustatyti prioritetą pagal nustatytas taisykles (pvz., programą, registracijos datą, statusą).
Atvykimo ir išvykimo valdymas
- 1Sistema turi automatizuoti įsikraustymo ir išsikraustymo procesus, įskaitant patalpų būklės patikrinimą, dokumentavimą ir susijusių finansinių procesų inicijavimą.
- 2Turi būti kontroliniai sąrašai, apimantys būklės patikros formą, nuotraukų įkėlimą (su laiko žyma) ir skaitmeninį patvirtinimą (sign-off).
- 3Sistemoje turi būti skaitmeninio patvirtinimo galimybė, kur nuomininkas ir (arba) administratorius patvirtina, kad pateikta patalpų būklės informacija yra teisinga ir įkelti duomenys atitinka faktinę situaciją.
- 4Skaitmeninio patvirtinimo metu sistema privalo saugoti naudotojo identifikatorių, datą ir laiką, susieto įrašo identifikatorių (apžiūros / checklist) bei IP adresą arba įrenginio informaciją (jei taikoma).
- 5Įvykiai turi apimti užstato grąžinimo inicijavimą, papildomų mokesčių (pvz., žalos) sukūrimą ir sutarties uždarymo inicijavimą.
Kambarių ir patalpų valdymas
- 1Turi būti CRUD funkcionalumas bendrabučiams, aukštams ir kambariams, kur kiekvienas kambarys susietas su tipu (pvz., dvivietis, trivietis) ir užimtumo būsena.
- 2Turi būti automatinis kambarių priskyrimo mechanizmas pagal eilės vietą, nuomininko prioritetus ir kambarių prieinamumą, palaikantis pakeitimus.
- 3Turi būti realaus laiko prieinamumo stebėjimas su įspėjimais apie perteklinį rezervavimą arba kambarių konfliktus.
- 4Sistema turi apimti apžiūros istoriją, problemų žymas, nuomininkų duomenis ir pranešimų galimybes.
Sistemos priežiūra ir palaikymas
- 1Sprendimas turi apimti integruotus 24/7 veikiančius realaus laiko stebėjimo įrankius, kurie atlieka pagrindinių komponentų (pvz., duomenų bazės, API galinių taškų, autentifikavimo paslaugos) būklės patikras.
- 2Anomalijos (klaidų padidėjimas, lėtas reagavimo laikas, paslaugų gedimai) turi suaktyvinti įspėjimus el. paštu, SMS žinutėmis arba integruojant su tokiomis platformomis kaip „PagerDuty“.
- 3Kritinės problemos (visiškas sistemos sutrikimas, duomenų sugadinimas): atsakymas per 4 valandas, sprendimas per 8 valandas.
- 4Didelės problemos (funkcinis modulis nepasiekiamas): atsakymas per 8 valandas, sprendimas per 12 valandų.
- 5Nedidelės problemos (vartotojo sąsajos klaida, kosmetinis defektas): atsakymas per 24 valandas, sprendimas per 72 valandas.
- 6Po saugumo testavimo turi būti įdiegti reguliarūs pagrindinių programų modulių ir trečiųjų šalių bibliotekų atnaujinimai.
- 7Avarinių pažeidimų korekcijos turi būti įdiegtos per 24 valandas nuo kritinio pažeidžiamumo nustatymo.
- 8Kasdienės automatinės atsarginės kopijos turi būti sukonfigūruotos, saugiai saugomos ne vietoje ir saugomos mažiausiai 30 dienų.
- 9Atkūrimo procedūros turi būti dokumentuojamos ir testuojamos kas ketvirtį.
- 10Visi funkciniai patobulinimai ar infrastruktūros pakeitimai turi atitikti oficialų pakeitimų prašymą ir patvirtinimo darbo eigą, apimant versijų kontrolę, poveikio analizę ir atšaukimo planavimą.
- 11Kasmet turėtų būti teikiama bent 50 valandų ekspertų lygio palaikymo sistemos derinimui, užklausų optimizavimui ir apkrovos testavimui, atsižvelgiant į naudojimo tendencijas.
- 12Tiekėjas turi suteikti prieigą prie paieškos pagrindu veikiančios žinių bazės, techninės dokumentacijos ir pagalbos tarnybos bilietų pardavimo sistemos su patogia vartotojo sąsaja.
- 13Pagalbos agentai turi būti apmokyti tiek techninių trikčių šalinimo, tiek naudotojų pagalbos srityse.
- 14Po diegimo suteikiamas mažiausiai 12 mėnesių garantinis laikotarpis, apimantis programinės įrangos klaidas, duomenų vientisumo problemas ir našumo regresiją, atsiradusią dėl sistemos atnaujinimų.
- 15Palaikymas turi apimti infrastruktūros priklausomybių atnaujinimus (pvz., OS pataisymus, duomenų bazės modulio atnaujinimus, TLS versijų atnaujinimus), užtikrinant nuolatinę platformos atitiktį reikalavimams ir saugumą.
Sąskaitų išrašymas ir finansai
- 1Sistema turi valdyti visą finansinį ciklą – nuo sąskaitų generavimo iki mokėjimų, skolų ir grąžinimų administravimo.
- 2Turi būti automatinis sąskaitų generavimas pagal sutartis.
- 3Turi būti realaus laiko mokėjimų registravimas ir suderinimas.
- 4Turi būti daugiakanaliai (el. paštas / SMS) priminimai.
- 5Turi būti skolų taisyklės su eskalavimu po nustatyto laikotarpio.
- 6Turi būti užstato ir permokų grąžinimo procesai su patvirtinimo etapais.
- 7Sąskaitų faktūrų generavimo modulis turi automatiškai išrašyti sąskaitas faktūras pagal sutarties trukmę, sutarties sąlygas ir kainodaros taisykles, automatiškai pridedant kambario tipą ir kainodaros taisykles.
- 8Turi būti galimybė integruotis su mokėjimų inicijavimo platformomis ir mokėjimo paslaugų teikėjais per API (pvz., bankiniai mokėjimai, kortelės, open banking sprendimai), įskaitant mokėjimo inicijavimą ir mokėjimo būsenos gavimą.
- 9Sandorių stebėjimas turi rodyti istorinius ir realiuoju laiku atliktus mokėjimus pagal nuomininką bei palaikyti eksportavimą standartiniais formatais (CSV, XLSX, JSON, XML).
- 10Mokėjimo būsenos turi apimti: inicijuotas, apmokėtas, atmestas, pavėluotas, palaikant dalinius mokėjimus.
- 11Skolų valdymo modulis turi stebėti pradelstus mokėjimus, taikyti delspinigius pagal nustatytas verslo taisykles ir generuoti ataskaitas.
- 12Sistema turi siųsti automatinius el. pašto priminimus apie neapmokėtas sąskaitas faktūras, nepavykusius mokėjimus ir būsimus atnaujinimus pagal įvykius (pvz., artėjantis terminas, pradelsta sąskaita).
- 13Užstato grąžinimo eiga turi tvarkyti grąžinimo užklausas, patvirtinimo eigą ir didžiosios knygos koregavimus.
- 14Turi būti įmokų valdymas: registruoti pradines įmokas, jų susiejimą su sutartimi, stebėti grąžinimo tinkamumą ir suderinti išsiregistravimą.
- 15Visi finansiniai įrašai (sąskaitos, mokėjimai, depozitai) turi būti susieti su konkrečia sutartimi ir nuomininku.
- 16Visi finansiniai veiksmai turi būti registruojami audito žurnale.
Aptarnavimas ir problemų sprendimas
- 1Nuomininkai turi galėti pateikti paslaugų užklausas arba registruoti problemas, o sistema turi užtikrinti jų paskyrimą, sekimą ir sprendimą pagal SLA.
- 2Užklausose turi būti nurodyta kategorija, aprašymas, prioritetas ir pasirenkami priedai.
- 3SLA turi nurodyti atsakymo ir sprendimo laikus pagal kategoriją.
- 4Turi būti automatinis užklausų priskyrimas atsakingiems darbuotojams.
- 5Turi būti automatinis užklausų perdavimas (eskalavimas), jei SLA pažeidžiamas.
- 6Nuomininkai turi galėti teikti struktūrizuotas paslaugų ar problemų užklausas, kuriose nurodoma kategorija, aprašymas, prioritetas ir pasirenkami priedai.
- 7Darbo eigos modulis turi priskirti užklausą darbuotojams ir sekti būsenos pakeitimus pagal sutartą SLA.
- 8Turi būti eskalavimo taisyklės, perduodančios užklausą vadovams, jei ji neišsprendžiama per nustatytą laiką.
- 9Ataskaitų teikimas ir analizė turi apimti sprendimo laiką, darbuotojų darbo krūvio ir pasikartojančių problemų analizę, pateikiant juos kaip ataskaitų suvestines.
tendis.lt · Sukurta recodin.lt