B2Lithuania svetainės modernizavimo ir palaikymo paslaugos 1585
Išanalizuota
Viešoji įstaiga Inovacijų agentūra
Atviras konkursasCPV: 72243000 - Programavimo paslaugos
ID: 67156442026-03-02 05:21
Atidaryti CVP ISAprašymas
Perkamos B2Lithuania svetainės modernizavimo ir palaikymo paslaugos. Tai apima esamos platformos atnaujinimą, naujų funkcionalumų diegimą ir nuolatinę techninę priežiūrą, siekiant užtikrinti sklandų ir saugų veikimą, pritaikymą mobiliesiems įrenginiams bei neįgaliesiems. Paslaugos teikiamos 36 mėnesių laikotarpiui su 4 mėnesių modernizavimo etapu ir papildomomis valandomis nenumatytiems poreikiams.
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 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. Informacinės sistemos ar duomenų registro kūrimas ar svetainės apima naujos informacinės sistemos arba duomenų registro ar internetinės savitarnos sistemų sukūrimą arba esamos informacinės sistemos ar duomenų registro modernizavimą ar internetinės savitarnos sistemų vystymą ar plėtrą, kai reikia sukurti naujus informacinės sistemos ar duomenų registro ar internetinės savitarnos sistemų funkcionalumus, arba pakeisti įdiegtus informacijos apdorojimo procesus, išskyrus informacinės sistemos arba duomenų registro arba internetinės savitarnos sistemų priežiūrą ar palaikymą, kuris apima tik klaidų taisymą ir sutrikimų šalinimą. Turėti tarptautiniu mastu pripažįstamą projektų valdymo kvalifikaciją.
- 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 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 naudadamas Laravel (PHP 8.x) ir Vue.js karkasus (kiekviename projekte programuotojas turi būti programavęs naudodamas abu nurodytus karkasus). Informacinės sistemos ar duomenų registro kūrimas ar svetainės apima naujos informacinės sistemos arba duomenų registro ar internetinės savitarnos sistemų sukūrimą arba esamos informacinės sistemos ar duomenų registro modernizavimą ar internetinės savitarnos sistemų vystymą ar plėtrą, kai reikia sukurti naujus informacinės sistemos ar duomenų registro ar internetinės savitarnos sistemų funkcionalumus, arba pakeisti įdiegtus informacijos apdorojimo procesus, išskyrus informacinės sistemos arba duomenų registro arba internetinės savitarnos sistemų priežiūrą ar palaikymą, kuris apima tik klaidų taisymą ir sutrikimų šalinimą.
Techniniai reikalavimai
Garantijos
- 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.
- 3Platformos sutrikimai, siejami su garantine priežiūra, turi būti kategorizuojami ir taisomi techninės specifikacijos 9 skyriuje aptartomis sąlygomis.
Palaikymo paslaugos
- 1Nepertraukiamo platformos veikimo užtikrinimas. Jei pastebimi platformos sutrikimai, prieš juos taisant, paslaugų apimtis ir atlikimo terminai turi būti suderinama su PO.
- 2Pagalba PO sprendžiant iškilusias problemines situacijas, konsultacijos.
- 3Su PO suderinta tvarka neatidėliotiną informavimą apie įvykusius ir potencialius sutrikimus bei jų sprendimo būdus, sutrikimų priežasčių diagnostiką, rekomendacijas 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 kitų 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; naudotojai negali matyti arba tvarkyti daugiau duomenų, nei jiems leidžia jų teisės; pateikiamų ataskaitų, dokumentų ar duomenų rinkinių skaičius, turinys ir forma atitinka susitarimus su PO; duomenų įvedimo, apdorojimo ir tvarkymo seka atitinka su PO suderintus planus; yra galimybės naudotojams atlikti numatytas operacijas.
- 2Reikia įsitikinti, ar Platformoje esanti dokumentacija ir elektroninė kontekstinė pagalba atitinka realybę. Be to, reikia į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.
- 3Teikėjas turi pateikti PO patikrintus pakeitimus be kritinių klaidų. Funkcinio testavimo scenarijai turi būti rengiami atsižvelgiant į aktualias PO teikiamas paslaugas ir kitus veiklos procesus. Funkcinio testavimo prioritetai bus nustatomi suderinus su PO, laikantis pakeitimų svarbos prioriteto.
- 4Teikėjas ir PO testavimai turi apimti tiek korektiškų, tiek ir nekorektiškų duomenų įvedimą bei reakcijos į pateiktus duomenis tikrinimą.
- 5PO atliks arba organizuos platformos saugumo testavimą vieną kartą per metus. Pastebėtų spragų šalinimas turės būti atliekamas 9 skyriuje nustatyta tvarka.
Modernizavimo reikalavimai
- 1Testinės aplinkos sukūrimas, sukonfigūravimas ir parengimas veikimui PO infrastruktūroje.
- 2Atnaujintos interneto svetainės stacionarioji ir mobilioji versijos, remiantis interaktyviu funkciniu prototipu, parengtu naudojant Figma įrankį ir pasiekiamu adresu: https://www.figma.com/design/nh6911llpk1OzJEAh4GTpV/B2Lithuania?node-id=0-1&t=VbA1Kl4WQiz2pajE-1.
- 3Pritaikyti svetainės dizainą visiems svetainės tinklalapiams ir įgyvendinti trūkstamus funkcionalumus remiantis parengtu prototipu. Tuo atveju, kai reikalingi pakeitimai apimtų backend posistemės korekcijas, tokie darbai gali būti atliekami tik iš anksto suderinus su PO ir bus vykdomi iš papildomų valandų, kurios numatytos 3.2 punkte.
- 4Užtikrinti dizaino pritaikymą mobiliesiems įrenginiams bei atitikimą Valstybės ir savivaldybių institucijų Interneto svetainių pritaikymo neįgaliesiems vertinimo metodikai.
- 5Masinio įmonių užkėlimo funkcionalumo sukūrimas. Modulio administravimą atlikti galės tik specifinę teisę turintys naudotojai.
- 6Įmonės arba įvedamos po vieną (turi būti sukurta įmonės įvedimo forma) arba importuojamos iš „.xlsx“ formato failo.
- 7Failo struktūra masiniam įkėlimui: Įmonės kodas ir eksporto apyvarta procentais. Įkeliant failą turi matytis failo importavimo progresas procentais ir progreso juosta.
- 8Rankinio įvedimo 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.
- 9Importuojant failą taikomos tos pačios taisyklės, kaip rankiniam įvedimui, išskyrus įmonės kodo egzistavimo tikrinimą - kuriant įrašus įmonės su jau egzistuojančiais kodais turi būti papildomos arba atnaujinamas eksporto apyvartos procentas.
- 10Klaidos/sėkmės pranešimai importuojant duomenis: Validacijos pranešimai atvaizduojami visoms įmonėms iškart pateikiant tiek eilučių, tiek klaidų paaiškinimus kiekvienoje eilutėje. Jei klaidų nėra sukuriami įrašai sąraše su būsena „Laukiama duomenų papildymo". Naudotojui pateikiama informacija kiek įrašų buvo sukurta ir kiek įmonių importuojamame faile jau egzistavo, bei kur buvo papildyta arba atnaujinta eksporto apyvartos informacija.
- 11Įkeltų įmonių duomenų papildymas: Sistema 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 (galutinė duomenų apimtis derinama su PO analizės etape).
- 12Po duomenų užkrovimo sistema tikrina ar API grąžino visus duomenis ir kiekvienai įmonei priskiria statusą.
- 13Statusas „Nėra visų reikalingų duomenų registracijai": Trūksta el. pašto adreso. Naudotojas turintis teisę, gali pridėti el. paštą ir (ne)patvirtinti anketą.
- 14Statusas „Reikalingas patikrinimas": El. paštai neprasideda „info@...", įmonės turintis tam tikrą teisinį statusą arba įmonės apyvartos yra mažesnė arba didesnė už tam tikrą skaičių. Naudotojas turintis teisę, redaguoja informaciją ir (ne)patvirtinti anketą. Statusui „Reikalingas patikrinimas” priklausomai nuo API gautų duomenų sukuriamos tam tikros taisyklės, jos bus tikslinamos analizės etape.
- 15Sąrašas su visomis būsena „Reikalingas patikrinimas“ pateikiamas teisę turinčiam naudotojui peržiūrai. Jis gali ne tik peržiūrėti bet ir redaguoti įmonių duomenis. Jei rankiniu būdu įrašomas įmonės el. paštas būsena pasikeičia į „Sukurta įmonės anketa”, o jei el. paštas ištrinamas būsena keičiama į „Nėra visų reikalingų duomenų registracijai”.
- 16Masiniai 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ę. Eilė standartiniu principu išsiunčia kvietimus jungtis prie B2Lithuania platformos el. paštu, kuris yra gaunamas iš API arba įvedamas teisę turinčio naudotojo.
- 17Kvietimo laiško tekstas preliminariai: „Jūsų įmonė yra įkelta į B2Lithuania eksportuojančių įmonių platformą. Kad būtumėte matomi naujiems potencialiems užsienio klientams, prašome prisijungti ir atnaujinti savo duomenis.“ Laiške matomi mygtukai su pasirinkimais: „Sutinku, kad įmonė būtų B2Lithuania kataloge“ ir „Pildyti įmonės profilį”. Mygtukų pavadinimai derinami su PO analizės etape.
- 18Naudotojui pasirinkus „Sutinku, kad įmonė būtų B2Lithuania kataloge“, sukuriamas jo įmonės profilis B2Lithuania ir uždedamas bazinis logotipas (pateiks PO analizės etape). Tokioms įmonėms suteikiama būsena „Tik baziniai duomenys“. Po šio patvirtinimo naudotojas norintis pildyti visą anketą tai bet kada padaryti gali iš laiško pasirinkdamas mygtuką „Pildyti įmonės profilį”.
- 19Naudotojui pasirinkus „Pildyti įmonės profilį“, naudotojas nukreipiamas į įmonės duomenų redagavimo formą, kur turi užpildyti ne tik asmens, bet ir įmonės duomenis, t. y. visus registracijos formoje (https://b2lithuania.com/register/registration-step-1) esančius duomenis. Tokioms įmonėms suteikiama būsena „Užpildyti visi duomenys“.
- 20Jei įmonė laišką ignoruoja arba užpildo tik bazinius duomenis, siųsti priminimo laiškus po 14 dienų ir pakartotinai po 30 dienų. Laiškų tekstai ignoravimo ir bazinių duomenų užpildymo atvejui bus pateikti PO analizės etape.
- 21Jei 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.
- 22Įmonių tikrinimo funkcionalumas: jei įmonė įkeliama į modulį, bet dar iki laiško gavimo arba įmonei turint statusą „Nesutiko prisijungti prie B2L“ registruojasi į B2Lithuania registracijos formą (t.y. įveda jau egzistuojantį įmonės kodą), registracijos metu susieti profilį ir leisti jai užbaigti registraciją naudojant jau užkrautus duomenis.
- 23Atnaujinti 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.
Bendrieji platformos reikalavimai
- 1Modernizuojami / atnaujinami platformos moduliai, komponentai turi būti pritaikyti neįgaliesiems ir atitikti teisės aktus, reglamentuojančius interneto svetainių prieinamumo reikalavimus, aprašytus Valstybės skaitmeninių sprendimų agentūros internetinėje svetainėje.
- 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ų. Kodas 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ų.
- 4Platformos 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).
- 5Platformos portalas turi veikti stabiliose (angl. Stable version) interneto naršyklėse (Google Chrome, Mozilla Firefox, Microsoft Edge, Safari, Opera), taip pat būti prieinamas įvairiuose įrenginiuose ir ekrano dydžiuose.
- 6Platformos funkcionalumų reakcijos laikas turi būti iki 3s.
- 7Lankytojui 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. Mobili 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.
- 8Teikėjas turi užtikrinti sklandų bendradarbiavimą su kitais PO atrinktais dalyviais (tuo atveju, jei prie svetainės dirbtų kiti tiekėjai) ir esant poreikiui, suderinti API end-point sąrašą reikalingą kitoms PO sistemų veikimui. Šis poreikių sąrašas ir įgyvendinimo / diegimo planas derinamas su PO ir kitais suinteresuotais dalyviais (tuo atveju, jei prie svetainės dirbtų kiti tiekėjai).
Sutrikimų šalinimas ir valdymas
- 1Platformos veikimo sutrikimas – tai: visiškas arba dalinis Platformos darbo sutrikimas, kai Platformos nebeatlieka tų funkcijų, kurias atlikdavo iki sutrinkant darbui; klaida Platformos realizavimo priemonėse, dėl kurios visai arba iš dalies neįmanoma atlikti tam tikrų funkcijų arba šios funkcijos pateikiami rezultatai yra klaidingi.
- 2Esant 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.
- 3Įvykus situacijai, kuomet problemų priežasčių sprendimas nevyksta, ar vyksta pažeidžiant nustatytus terminus – PO turi teisę samdyti trečių šalių ekspertus problemų priežasčiai nustatyti. Teikėjas privalo šalinti tokias surastas priežastis savo kaštais arba atlyginti PO patirtus kaštus tokias priežastis šalinant PO pasamdytoms kitoms trečioms šalims bei padengti eksperto išlaidas, jei nustatoma, kad problema buvo dėl Teikėjo veiklos ar neveikimo priežasčių.
- 4Visos klaidos ir sutrikimai fiksuojami PO JIRA aplinkoje. Fiksuoti gali tiek PO, tiek Teikėjas, kai pastebi sutrikimą / klaidą.
- 5I prioriteto sutrikimų šalinimas (Platforma nustojo funkcionuoti; visi arba didžioji dauguma naudotojų negali tęsti darbo masiškai sutrikus Platformos funkcijai, kuri yra būtina reikiamam tolimesniam procesui) turi būti pradėtas ne vėliau kaip per 2 darbo valandas nuo sutrikimo užregistravimo ir turi būti visiškai baigtas ne vėliau kaip per 8 darbo valandas nuo sutrikimo užregistravimo.
- 6I prioriteto sutrikimų šalinimas (grėsmė ar nukentėję PO ar trečiųjų šalių duomenys) turi būti pradėtas ne vėliau kaip per 1 darbo valandą nuo sutrikimo Jira priemonėmis ir turi būti visiškai baigtas ne vėliau kaip per 4 darbo valandas nuo sutrikimo užregistravimo.
- 7II prioriteto sutrikimų šalinimas (neapibrėžtas funkcijos veikimas, kuris leidžia įvykdyti numatytą Platformos funkciją, tačiau naudotojui reikia atlikti papildomus, nenumatytus ar alternatyvius veiksmus) turi būti pradėtas ne vėliau kaip per 4 darbo valandas nuo sutrikimo užregistravimo JIRA priemonėmis ir turi būti visiškai baigtas ne vėliau kaip per 16 darbo valandų nuo sutrikimo užregistravimo.
- 8III prioriteto sutrikimų šalinimas (veiklos procesai ir Platformos funkcionalumas paveiktas nežymiai. Sutrikimas duomenims ir Platformos funkcionalumui grėsmės nekelia. Galutiniai vartotojai turi galimybę dirbti, nejaučiant didelių Platformos sutrikimų. Problemos sprendimas yra būtinas, bet ne kritinis) turi būti pradėtas ne vėliau kaip per 8 darbo valandas nuo sutrikimo užregistravimo JIRA priemonėmis ir turi būti visiškai baigtas ne vėliau kaip per 4 darbo dienas nuo sutrikimo užregistravimo.
- 9Sutrikimo tipą ir prioritetą nustato PO. Teikėjo siūlymu ir PO sutikimu sutrikimo tipas ir prioritetas gali būti tikslinami.
- 10Jeigu dėl objektyvių priežasčių, nepriklausančių nuo Teikėjo, sutrikimo šalinimui reikalingas ilgesnis laikas, negu numatyti reakcijos laikai, dėl ilgesnio laiko su PO susitariama atskirai.
Paslaugų užsakymas ir priėmimas
- 1Modernizavimo ir palaikymo paslaugos užsakomos PO ir turi būti suteiktos per su Tiekėju sutartą terminą, tačiau ne vėliau nei per 15 d. d. nuo PO užsakymo Tiekėjui pateikimo dienos.
- 2PO šioje techninėje specifikacijoje numatytas paslaugas gali užsakyti dalimis. PO nusprendžia dėl užduočių prioritetų.
- 3Teikėjas, gavęs PO rašytinį prašymą dėl avarinės situacijos likvidavimo, programinės įrangos sutrikimo likvidavimo, platformos funkcionalumo modifikavimo, modernizavimo turi įvertinti prašymui atlikti būtinas laiko sąnaudas. PO pritarus laiko sąnaudoms, Teikėjas suteikia paslaugas.
- 4Modernizavimo / palaikymo funkcionalumo neatitikimą Teikėjas privalo ištaisyti šiais terminais: reakcija - ne ilgiau kaip per 1 darbo dieną nuo PO kreipinio pateikimo; sprendimas - ne ilgiau kaip per 3 darbo dienas nuo PO kreipinio pateikimo.
- 5PO įvertinus siūlomą modernizavimo sprendimą ir pateikus jam pritarimą, Teikėjas suformuoja paketus diegimui į testinę platformos aplinką.
- 6PO atlikus sprendimo testavimą testinėje aplinkoje ir nenustačius trūkumų, Tiekėjas atlieka diegimą į gamybinę aplinką.
- 7Modernizavimo ir palaikymo rezultatų priėmimas atliekamas ne vėliau kaip 5 darbo dienos nuo diegimo į PO gamybinę aplinką.
- 8Visi sutartyje įgyti rezultatai ir su jais susijusios teisės, įskaitant intelektinės nuosavybės teises, išskyrus asmenines neturtines teises į intelektinės veiklos rezultatus, tampa PO nuosavybe nuo paslaugų perdavimo-priėmimo momento be jokių apribojimų. PO gali laisvai naudoti, publikuoti, perleisti ar perduoti šias teises tretiesiems asmenims be atskiro Teikėjo sutikimo.
- 9Teikė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ą.
- 10Aptikus sutrikimus PO testavimo metu, sutrikimai turi būti pašalinami modernizavimo / palaikymo / garantinės priežiūros užsakymo įgyvendinimo rėmuose Teikėjo sąskaita.
- 11Teikė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ą.
Dokumentacijos ir programinio kodo reikalavimai
- 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.
- 4Atnaujinti esamą Platformos techninę dokumentaciją. Platformos 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.
- 7Visi šioje techninėje specifikacijoje apibrėžti reikalavimai yra suprantami kaip minimalūs.
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. Platforma, kur taikoma, privalo naudoti šiuos įrankius ir protokolus saugiai komunikacijai, su kitais sistemos komponentais bei galutiniais Platformos naudotojais, užtikrinti.
- 2Platforma privalo užtikrinti duomenų saugą.
- 3Platforma turi palaikyti siunčiamų, gaunamų ir saugojamų duomenų užšifravimą ir iššifravimą.
- 4Platformos naudotojui turi būti leidžiama keisti tik tuos įrašus, kuriuos jis turi teisę keisti.
- 5Platformos duomenų bazėje saugomi bei sąsajų pagalba perduodami duomenys privalo būti apsaugoti nuo sąmoningo ar nesąmoningo jų iškraipymo.
- 6Konfidencialių duomenų mainai ir su jais atliekami veiksmai privalo išsaugoti duomenų privatumą.
- 7Platformoje 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ų.
Dokumentai15
tendis.lt · Sukurta recodin.lt