Grįžti į sąrašą

B2Lithuania svetainės modernizavimo ir palaikymo paslaugos

Išanalizuota

Viešoji įstaiga Inovacijų agentūra

Atviras konkursasCPV: 72243000 - Programavimo paslaugos
ID: 74589192026-04-21 05:01
Atidaryti CVP IS

Aprašymas

Perkamos B2Lithuania svetainės modernizavimo ir palaikymo paslaugos. Šis pirkimas apima esamų platformos modulių atnaujinimą, naujų funkcionalumų kūrimą, tokių kaip masinis įmonių užkėlimas, bei nuolatinę techninę priežiūrą ir sutrikimų šalinimą. Paslaugos turi užtikrinti platformos prieinamumą, saugumą ir sklandų veikimą, laikantis nustatytų kokybės standartų ir terminų.

Kvalifikaciniai reikalavimai

  • 1Tiekėjas pirkimo sutarties vykdymui turi paskirti ne mažiau kaip 1 (vieną) specialistą, kuris turi atitikti šiuos reikalavimus: Projekto vadovą, kuris: per pastaruosius 3 (tris) metus iki pasiūlymų pateikimo termino pabaigos turi būti vadovavęs ne mažiau kaip 2 (dviems) informacinės sistemos ar duomenų registro ar internetinės savitarnos sistemų projektams.
  • 2Tiekėjas pirkimo sutarties vykdymui turi paskirti ne mažiau kaip 1 (vieną) specialistą, kuris turi atitikti šiuos reikalavimus: Full-stack programuotoją, kuris per pastaruosius 3 (tris) metus iki pasiūlymų pateikimo termino pabaigos yra vykdęs ne mažiau kaip 2 (du) informacinės sistemos ar duomenų registro ar internetinės savitarnos sistemų kūrimo projektus, kurių metu programavo naudodadamas Laravel (PHP 8.x) ir Vue.js karkasus. (kiekviename projekte programuotojas turi būti programavęs naudodamas abu nurodytus karkasus).

Techniniai reikalavimai

Garantija

  • 1Įdiegtiems papildomiems Platformos funkciniams ir nefunkciniams reikalavimams turi būti taikoma 12 mėn. garantija nuo įdiegto funkcionalumo į gamybinę aplinką, kuri fiksuojama JIRA, jei JIRA fiksuoti nėra galimybių, tai nuo priėmimo–perdavimo akto pasirašymo dienos.
  • 2Garantinio laikotarpio pradžia kiekvienam naujai sukurtam Platformos modulio, komponento funkcionalumui – suteikiamas garantinis laikotarpis nuo kiekvieno tokio funkcionalumo sukūrimo ir perdavimo datos.

Palaikymo paslaugos

  • 1Nepertraukiamo platformos veikimo užtikrinimas; paslaugų apimtis ir atlikimo terminai turi būti suderinama su PO prieš taisant sutrikimus.
  • 2Pagalba PO sprendžiant iškilusias problemines situacijas, konsultacijos.
  • 3Su PO suderinta tvarka neatidėliotinas informavimas apie įvykusius ir potencialius sutrikimus bei jų sprendimo būdus, sutrikimų priežasčių diagnostika, rekomendacijos kaip išvengti galimų sutrikimų.
  • 4Institucijų, su kuriomis pasirašytos bei ruošiamos pasirašyti duomenų teikimo sutartys, naudojamų ir planuojamų naudoti duomenų struktūrų atnaujinimas, priežiūra, prisijungimo adresų ir prisijungimo duomenų keitimas pagal poreikius, techninių specifikacijų derinimas ar ruošimas ir konsultavimas.
  • 5Specifinių duomenų pagal tam pateiktus kriterijus ištraukimas iš platformos duomenų bazės ir pateikimas PO pageidaujamu formatu ir struktūra; duomenų taisymas.
  • 6Smulkūs naudotojo sąsajos patobulinimai ir esamų Platformos funkcijų pagerinimai naudotojui (pvz. mygtukų ar kt. tekstų pavadinimų pakeitimai, neaktualių mygtukų paslėpimai, aiškinamųjų tekstų įdėjimai, piktogramų atnaujinimai, duomenų laukų privalomumų keitimai (kai pakeitimai nedaro įtakos sisteminių procesų), smulkūs Platformos formuojamos ar atvaizduojamos naudotojo sąsajoje informacijos iš įvestų duomenų pakeitimai.).
  • 7Teikėjas nedelsdamas (ne vėliau kaip per 1 val. nuo Teikėjo identifikuotos problemos užfiksavimo momento) informuoja PO atsakingą asmenį ir valstybės debesijos paslaugų teikėjo atsakingą asmenį (jeigu yra rizika, kad problema susijusi su infrastruktūra) apie pastebėtas Platformos veikimo problemas telefonu, elektroniniu paštu, sukonfigūravus savo veikimo stebėjimo platformos ir siunčiant automatinius pranešimus ar kitaip (problemų ir trikdžių registravimo sistemoje).
  • 8Visos (tiek Teikėjo identifikuotos, tiek PO pastebėtos) Platformos veikimo problemos nedelsiant registruojamos PO JIRA paskyroje. PO atsakingi asmenys turi turėti galimybę matyti užregistruotų problemų sprendimo eigą, tikslinti problemų informaciją, matyti įregistruotų problemų/klaidų ištaisymo būseną ir kitą aktualią informaciją.

Testavimo reikalavimai

  • 1Testavimo proceso metu Teikėjas turi įsitikinti, kad įvairių grupių naudotojai gali atlikti jiems skirtas operacijas pagal suteiktas teises, įskaitant navigacijos ir vartotojo sąsajos testus.
  • 2Naudotojai negali matyti arba tvarkyti daugiau duomenų, nei jiems leidžia jų teisės.
  • 3Pateikiamų ataskaitų, dokumentų ar duomenų rinkinių skaičius, turinys ir forma atitinka susitarimus su PO.
  • 4Duomenų įvedimo, apdorojimo ir tvarkymo seka atitinka su PO suderintus planus.
  • 5Yra galimybės naudotojams atlikti numatytas operacijas.
  • 6Reikia įsitikinti, ar Platformoje esanti dokumentacija ir elektroninė kontekstinė pagalba atitinka realybę.
  • 7Reikia įvertinti, ar ankstesnės Platformos funkcijos, kurios nebuvo modifikuojamos arba kurios buvo naujai sukurtos, veikia taip pat, kaip ir anksčiau, ir ar nepasirodo anksčiau ištaisytos klaidos.
  • 8Teikėjas turi pateikti PO patikrintus pakeitimus be kritinių klaidų.
  • 9Funkcinio testavimo scenarijai turi būti rengiami atsižvelgiant į aktualias PO teikiamas paslaugas ir kitus veiklos procesus.
  • 10Teikėjas ir PO testavimai turi apimti tiek korektiškų, tiek ir nekorektiškų duomenų įvedimą bei reakcijos į pateiktus duomenis tikrinimą.
  • 11PO atliks arba organizuos platformos saugumo testavimą vieną kartą per metus. Pastebėtų spragų šalinimas turės būti atliekamas 9 skyriuje nustatyta tvarka.

Technologijos ir aplinka

  • 1Sistemos išpildymui pasirinktas atvirojo kodo technologijų rinkinys: Ubuntu 20.08, Nginx, GIT, PHP 8.3 (Laravel 11), AOuth2, MySql 8, Redis, Node.js, PM2, Javascript (Vue.js), HTML5, CSS3, Material Design.
  • 2Testinė aplinka turi būti sukurta, sukonfigūruota ir parengta veikimui PO infrastruktūroje.

Modernizavimo reikalavimai

  • 1Interneto svetainės stacionariosios ir mobiliosios versijos atnaujinimas, remiantis interaktyviu funkciniu prototipu, parengtu naudojant Figma įrankį (https://www.figma.com/design/nh6911llpk1OzJEAh4GTpV/B2Lithuania?node-id=0-1&t=VbA1Kl4WQiz2pajE-1).
  • 2Svetainės dizaino pritaikymas visiems svetainės tinklalapiams ir trūkstamų funkcionalumų įgyvendinimas remiantis parengtu prototipu.
  • 3Dizaino pritaikymas mobiliesiems įrenginiams bei atitikimas Valstybės ir savivaldybių institucijų Interneto svetainių pritaikymo neįgaliesiems vertinimo metodikai.
  • 4Masinio įmonių užkėlimo funkcionalumo sukūrimas, kurio administravimą atlikti galės tik specifinę teisę turintys naudotojai.
  • 5Įmonės turi būti įvedamos po vieną per įmonės įvedimo formą arba importuojamos iš „.xlsx“ formato failo.
  • 6Rankinio įvedimo metu turi būti taikomos duomenų validacijos taisyklės: Įmonės kodas - privalomas, 9 skaitmenų, neegzistuojantis esamame įmonių sąraše bei nesikartojantis kviečiamų įmonių sąraše; Eksporto apyvarta procentais tarp 0 ir 100.
  • 7Įkeliant failą turi matytis failo importavimo progresas procentais ir progreso juosta.
  • 8Importuojant failą, kuriant įrašus, įmonės su jau egzistuojančiais kodais turi būti papildomos arba atnaujinamas eksporto apyvartos procentas.
  • 9Klaidos/sėkmės pranešimai: jei duomenys importuojami, validacijos pranešimai atvaizduojami visoms įmonėms iškart pateikiant tiek eilučių, tiek klaidų paaiškinimus kiekvienoje eilutėje.
  • 10Jei klaidų nėra, sukuriami įrašai sąraše su būsena „Laukiama duomenų papildymo".
  • 11Naudotojui pateikiama informacija, kiek įrašų buvo sukurta ir kiek įmonių importuojamame faile jau egzistavo, bei kur buvo papildyta arba atnaujinta eksporto apyvartos informacija.
  • 12Sistema periodinių užduočių (angl. cronjobs) pagalba atrenka įrašus su būsena „Laukiama duomenų papildymo" ir pagal įmonės kodą užkrauna papildomus duomenis iš sistemos (API): Adresas, El. pašto adresas, Svetainė, Darbuotojų skaičius, Apyvarta, Įmonės įkūrimo data.
  • 13Po duomenų užkrovimo, sistema tikrina ar API gražino visus duomenis ir kiekvienai įmonei priskiria statusą.
  • 14Statusas „Nėra visų reikalingų duomenų registracijai" (trūksta el. pašto adreso) leidžia naudotojui turinčiam teisę, pridėti el. paštą ir (ne)patvirtinti anketą.
  • 15Statusas „Reikalingas patikrinimas" (el. paštai neprasideda „info@...“, įmonės turi tam tikrą teisinį statusą arba apyvartos yra mažesnė arba didesnė už tam tikrą skaičių) leidžia naudotojui turinčiam teisę, redaguoti informaciją ir (ne)patvirtinti anketą.
  • 16Statusas „Sukurta įmonės anketa" (duomenų pakanka) siunčia laiškus dėl profilių patvirtinimo.
  • 17Masiniai veiksmai gali būti atliekami tik po to kai teisę turintis naudotojas patvirtina visą sąrašą, tam turi būti sukurtas atskiras mygtukas „Siųsti kvietimus".
  • 18Sąrašo filtrai: Įmonės pavadinimas, Įmonės kodas, Būsena, Paskutinio prisijungimo data.
  • 19Masiniai veiksmai: išsiųsti kvietimus visoms įmonėms su būsena „Sukurta įmonės anketa“, kurioms kvietimai nebuvo išsiųsti ir kurias patvirtino administratorius; kvietimo modulis sukuria laiškus ir patalpina juos į laiškių eilę.
  • 20Kvietimo laiške matomi mygtukai su pasirinkimais: „Sutinku, kad įmonė būtų B2Lithuania kataloge“ ir „Pildyti įmonės profilį”.
  • 21Naudotojui pasirinkus variantą „Sutinku, kad įmonė būtų B2Lithuania kataloge“, sukuriamas jo įmonės profilis B2Lithuania ir uždedamas bazinis logotipas. Tokioms įmonėms suteikiama būsena „Tik baziniai duomenys“.
  • 22Naudotojui pasirinkus variantą „Pildyti įmonės profilį“, naudotojas nukreipiamas į įmonės duomenų redagavimo formą, kur turi užpildyti ne tik asmens, bet ir įmonės duomenis (visus registracijos formoje https://b2lithuania.com/register/registration-step-1 esančius duomenis). Tokioms įmonėms suteikiama būsena „Užpildyti visi duomenys“.
  • 23Jei įmonė laišką ignoruoja arba užpildo tik bazinius duomenis, siųsti priminimo laiškus po 14 dienų ir pakartotinai po 30 dienų.
  • 24Jei ir po priminimo laiškų klientas neatliks jokių veiksmų, praėjus 90 dienų nuo paskutinio laiško išsiuntimo, įmonės būsena automatiškai keičiama į „Nesutiko prisijungti prie B2L“. Teisę turintis naudotojas gali šią būseną bet kada pakeisti į „Laukiama duomenų papildymo" ir pradėti procesą iš naujo.
  • 25Įmonių tikrinimo funkcionalumas: jei įmonė įkeliama į modulį, bet dar iki laiško gavimo arba įmonei turint statusą „Nesutiko prisijunti prie B2L“ registruojasi į B2Lithuania registracijos formą (t.y. įveda jau egzistuojantį įmonės kodą), registracijos metu susieti profilį ir leisti jam užbaigti registraciją naudojant jau užkrautus duomenis.
  • 26Atnaujinti platformą, kad ji neturėtų Web Application Security Project (OWASP) Top 10 periodiškai skelbiamame aktualiame dokumente ir ankstesnėse šio dokumento versijose nurodytų pažeidžiamumų: laiko atakų prevencija, slaptažodžių žurnalizavimas.
  • 27Dokumentacijos atnaujinimas pagal techninės specifikacijos 12.3. p. reikalavimus.

Paslaugų apimtis ir trukmė

  • 1Platformos modernizavimo paslaugos turi būti suteiktos ne vėliau kaip per 4 mėnesius nuo sutarties įsigaliojimo dienos.
  • 2500 val. nenumatytiems modernizavimo ir palaikymo poreikiams teikiamos 36 mėnesius nuo sutarties įsigaliojimo, pagal atskirai PO ir Teikėjo suderintą užsakymą ir valandinį įkainį.
  • 3Perkančioji organizacija neįsipareigoja užsakyti visų numatytų paslaugų, teiktinų pagal nenumatytus poreikius.

Bendrieji reikalavimai platformai

  • 1Modernizuojami / atnaujinami platformos moduliai, komponentai turi būti pritaikyti neįgaliesiems ir atitikti teisės aktus, reglamentuojančius interneto svetainių prieinamumo reikalavimus (Valstybės skaitmeninių sprendimų agentūros internetinėje svetainėje aprašyti reikalavimai).
  • 2Programavimo kodas turi būti optimizuotas pagal W3C standartus.
  • 3Paslaugos turi būti teikiamos laikantis pripažintų programavimo gerųjų praktikų (pvz., Clean Code principų); galutinis programinis kodas turi būti struktūrizuotas, lengvai skaitomas, nuosekliai dokumentuotas ir komentuotas pagal sutartą stilių.
  • 4Kodas turi atitikti saugumo nuo įsiskverbimo reikalavimus, o jo kokybė turi būti patvirtinta atliekant statinę ir dinaminę saugumo analizę (SAST ir DAST), neturint kritinių ar didelio pavojingumo pažeidžiamumų.
  • 5Platformos komponentų informacija ir duomenys turi būti atvaizduojami laikantis vieningos dizaino sistemos, užtikrinant nuoseklų struktūravimą, suprantamas žymas, logišką informacijos išdėstymą ir prieinamumo reikalavimus (WCAG 2.1 AA).
  • 6Platformos portalas turi veikti stabiliose interneto naršyklėse (Google Chrome, Mozilla Firefox, Microsoft Edge, Safari, Opera), taip pat būti prieinamas įvairiuose įrenginiuose ir ekrano dydžiuose.
  • 7Platformos funkcionalumų reakcijos laikas turi būti iki 3s.
  • 8Lankytojui užėjus į Platformą su mobiliuoju įrenginiu (planšetiniu kompiuteriu ar išmaniuoju telefonu ir pan.), Platforma turi jam automatiškai pateikti versiją, skirtą mobiliesiems įrenginiams.
  • 9Mobili versija turi būti optimizuota ir korektiškai atvaizduojama mobiliojo įrenginio ekrane neprarandant jokių standartinės versijos funkcijų, t. y. lankytojai turi galėti patogiai ir intuityviai naršyti, vykdyti paieškas.
  • 10Teikėjas turi užtikrinti sklandų bendradarbiavimą su kitais IA atrinktais dalyviais ir esant poreikiui, suderinti API end-point sąrašą reikalingą kitoms PO sistemų veikimui.

Sutrikimų šalinimas ir valdymas

  • 1Naudojant Platforma ir esant nuolat pasikartojantiems sutrikimams ir klaidoms – tai laikoma problemomis, kurias Teikėjas turi spręsti iš esmės, randant bei išsprendžiant priežastį, bet ne tik pasekmes. Problemų sprendimas turi būti vykdomas pagal gerąsias praktikas, pvz., ITIL Problemų valdymo procesą (angl. Problem management), naudojant JIRA aplinkoje sukauptą informaciją apie kreipinius.
  • 2Visos klaidos ir sutrikimai fiksuojami PO JIRA aplinkoje. Fiksuoti gali tiek PO, tiek Teikėjas, kai pastebi sutrikimą / klaidą.
  • 3I prioriteto sutrikimo šalinimas (Platforma nustojo funkcionuoti, masiniai naudotojų darbo sutrikimai) turi būti pradėtas ne vėliau kaip per 2 darbo valandas nuo užregistravimo ir baigtas ne vėliau kaip per 8 darbo valandas.
  • 4I prioriteto sutrikimo šalinimas (grėsmė duomenims) turi būti pradėtas ne vėliau kaip per 1 darbo valandą nuo užregistravimo ir baigtas ne vėliau kaip per 4 darbo valandas.
  • 5II prioriteto sutrikimo šalinimas (neapibrėžtas funkcijos veikimas, reikalingi papildomi veiksmai) turi būti pradėtas ne vėliau kaip per 4 darbo valandas nuo užregistravimo ir baigtas ne vėliau kaip per 16 darbo valandų.
  • 6III prioriteto sutrikimo šalinimas (nežymiai paveiktas funkcionalumas, nekritinis) turi būti pradėtas ne vėliau kaip per 8 darbo valandas nuo užregistravimo ir baigtas ne vėliau kaip per 4 darbo dienas.
  • 7Sutrikimo tipą ir prioritetą nustato PO; Teikėjo siūlymu ir PO sutikimu sutrikimo tipas ir prioritetas gali būti tikslinami.
  • 8Sutrikimo pašalinimo ir (ar) užsakymo įvykdymo pabaigos laiku laikomas tas momentas, kuomet Teikėjas perduoda informaciją apie sutrikimo pašalinimą ar užsakymo įvykdymą PO ar jo įgaliotiems atstovams. Sutrikimas laikomas galutinai pašalinta kai PO atsakingi asmenys tai patvirtino.

Dokumentacija ir programinis kodas

  • 1Visa dokumentacija turi būti parengta lietuvių kalba ir laikantis bendrinės lietuvių kalbos taisyklių.
  • 2Dokumentų galutinės versijos turi būti pateiktos elektroniniu formatu (DOCX arba lygiaverčiu redaguojamu ir PDF arba lygiaverčiu skaitymui skirtu formatu) ir pasirašytos elektroniniu parašu, jei su PO nesutariama kitaip.
  • 3Paslaugų teikimo metu Teikėjas turės parengti ir (ar) atnaujinti ir su PO suderinti: Analizės ir projektavimo dokumentus; Atnaujinti esamą Platformos techninę dokumentaciją.
  • 4Platformos techninė dokumentacijos atitinkamos dalys / punktai privalo būti atnaujinti atsižvelgiant į Teikėjo suprogramuotus platformos funkcionalumų pakeitimus, suprogramavus naujus funkcionalumus privalo būti parengta naujų funkcionalumų dokumentacija / papildyta esama techninė dokumentacija.
  • 5Atnaujinta techninė dokumentacija ar jos dalys privalo būti pateiktos PO derinti (peržiūrėti) kartu su pateikiamu testuoti atitinkamu platformos funkcionalumo pakeitimu.
  • 6Pakeitimo diegimas bus priimamas diegti tik kai su PO bus suderinta atnaujinta platformos techninė dokumentacija ar jos dalis.
  • 7Teikėjas užtikrina, kad sukurti funkcionalumai ir programinis kodas būtų talpinami IA GitHub suteiktoje repozitorijoje tokiu būdu, kad užtikrintų sklandų Platformos modernizavimą / palaikymą / garantinę priežiūrą.
  • 8Teikėjas užtikrina, kad svetainės dizainui sukurti panaudotas turinys: tekstai, nuotraukos, grafika ir šriftai - yra legalūs ir perduos PO licencijas, liudijančias jų įsigijimą arba pateiks įrodymus, liudijančius legalaus naudojimo faktą.

Duomenų saugos ir konfidencialumo reikalavimai

  • 1Platformos saugumas paremtas dažniausiai praktikoje naudojamais įrankiais bei protokolais, tokiais kaip PGP, SSH ir SSL/TLS, S/MIME, IPSEC ir kitais.
  • 2Platforma, kur taikoma, privalo naudoti šiuos įrankius ir protokolus saugiai komunikacijai su kitais sistemos komponentais bei galutiniais Platformos naudotojais, užtikrinti.
  • 3Platforma privalo užtikrinti duomenų saugą.
  • 4Platforma turi palaikyti siunčiamų, gaunamų ir saugomų duomenų užšifravimą ir iššifravimą.
  • 5Platformos naudotojui turi būti leidžiama keisti tik tuos įrašus, kuriuos jis turi teisę keisti.
  • 6Platformos duomenų bazėje saugomi bei sąsajų pagalba perduodami duomenys privalo būti apsaugoti nuo sąmoningo ar nesąmoningo jų iškraipymo.
  • 7Konfidencialių duomenų mainai ir su jais atliekami veiksmai privalo išsaugoti duomenų privatumą.
  • 8Platformoje negali turėti Open Web Application Security Project (OWASP) Top 10 periodiškai skelbiamame aktualiame dokumente ir ankstesnėse šio dokumento versijose nurodytų pažeidžiamumų.

Dokumentai8

  • 1_Bendrosios sąlygos.docx
  • 2_Specialiosios sąlygos.docx
  • 3_Pirkimo sąlygų 2 priedas. Techninė specifikacija.docx
  • 4_Pirkimo sąlygų 5 priedas „EBVPD“.xml
  • 5_Pirkimo sąlygų 8 priedas. Sutarties projektas.docx
  • 6_c4t_7458919_1.xml
  • 7458919_Contract notice - general directive, standard regime_0.pdf
  • 1679_7458919.pdf