Caiet de sarcini
Caiet de sarcini
privind achiziționarea serviciilor de dezvoltare a website-ului BNR
Cuprins
A.3. Obiectivele proiectului 5
B.1. Structura sistemului informatic 7
Arhitectura sistemului actual 7
Clase de informații, tipuri de clase, metainformații 9
Structuri de date ale modulelor funcționale 10
Designul site-ului public (front-end) 12
Interfața de administrare (back-end) 13
Funcționalități destinate administratorilor 14
Funcționalități destinate utilizatorilor publici 15
Interfața de administrare (Content Management System - CMS) 19
Administrarea utilizatorilor 20
Administrarea claselor și a grupurilor de informații 21
Administrarea șabloanelor (template-urilor) 21
B.7. Monitorizare. Logare activități 23
D. Desfășurarea proiectului 30
D.2. Metoda de implementare 31
F. Efectuarea plăților în cadrul Contractului 35
A. Obiectul contractului
A.1. Rolul site-ului BNR
(1) Banca Națională a României, în calitatea sa de bancă centrală a statului român, elaborează și aplică politica monetară și de curs de schimb, răspunde de autorizarea, reglementarea și supravegherea prudențială a instituțiilor de credit, de promovarea și monitorizarea bunei funcționări a sistemelor de plăti, contribuind la asigurarea stabilității financiare. De asemenea BNR asigură administrarea rezervelor internaționale ale României. BNR sprijină politica economică generală a statului, fără prejudicierea îndeplinirii obiectivului său fundamental privind asigurarea și menținerea stabilității prețurilor.
(2) BNR este conectată la importante fluxuri de date, fiind la rândul său furnizor de date pentru o gamă largă de instituții și autorități (interne și internaționale), agenți economici, unități de învățământ și cercetători, agenții de presă, mass-media și diferite alte categorii de public.
(3) Website-ul BNR reprezintă principalul mijloc de comunicare cu publicul, fiind accesat zilnic de peste 30 de mii de utilizatori unici, iar numărul de accesări depășește deseori 2 milioane/zi. BNR utilizează de asemenea și alte canale de comunicare digitală: prin transmiterea de informații și notificări e-mail, prin conturile BNR pe Twitter, LinkedIn, YouTube și prin aplicația mobilă LeulRomânesc. Website-ul propriu-zis constituie totodată un repository pentru o gamă largă de informații care decurg din obligații legale de informare și responsabilități specifice băncii centrale, toate informațiile de natură publică fiind vehiculate prin infrastructura acestuia.
A.2. Obiectul contractului
(4) Obiectul prezentului contract îl constituie achiziționarea serviciilor de dezvoltare web necesare realizării următoarei versiuni a website-ului BNR (a 3-a versiune majoră), denumit în continuare WEBSITE-v3.
(5) Prin acest proiect se urmărește înlocuirea website-ului actual, conceput acum 10 ani, cu un produs nou, realizat conform celor mai noi standarde și tehnologii din domeniu și menit să asigure îmbunătățirea proceselor de comunicare cu publicul, pentru a putea deveni în mediul online o referință de informare-educare și dialog profesionist. Pe lângă aspectele tehnice, noua soluție va pune accent și pe experiența utilizatorilor site-ului (UX), printr-o abordare atentă a elementelor de accesibilitate și navigabilitate. De asemenea, proiectul va acoperi translatarea
(selectivă) și rescrierea creativă a conținutului selectat în noul website, astfel încât să se ofere informații ușor de înțeles pentru cât mai multe categorii de audiență.
(6) Pe baza conceptului creativ acceptat, soluția tehnică trebuie să fie una integrată, să conțină toate elementele necesare funcționării complete, unitare, ca soluție la cheie. Eventualele module-program provenite de la terți vor fi integrate în ofertă numai cu licență, asigurându-se pentru BNR toate drepturile de utilizare.
(7) Obiectivele proiectului sunt sintetizate în capitolul următor (A.3. Obiectivele proiectului). În capitolele din secțiunea B. Specificații tehnice sunt sistematizate principalele cerințe ale proiectului, rezultate din experiența acumulată în perioada de exploatare a website-ului actual, precum și din bunele practici existente la nivelul altor bănci centrale cu care BNR colaborează.
(8) Specificațiile de detaliu vor fi stabilite în faza de analiză a fiecărei etape de implementare, conform unei metodologii iterative de tip Agile (v. cap. D.2. Metoda de implementare).
(9) Proiectul implică de asemenea realizarea unei aplicații webmobile pentru distribuirea celor mai solicitate informații (dobânzi, curs de schimb și știri BNR) pe dispozitive mobile, precum și prin construirea unui API de tip REST, pentru a înlesni interoperatibilitatea cu alte sisteme, prin internet.
(10) Infrastructura hardware și de comunicații, precum și licențele pentru software-ul de bază (sisteme de operare, baze de date) nu fac obiectul acestui contract, intrând în obligațiile BNR.
A.3. Obiectivele proiectului
(11) Website-ul BNR are statut de aplicație critică pentru banca centrală, orice întrerupere a funcționării sale sau disfuncționalitate a acestuia putând avea un impact negativ asupra îndeplinirii obligațiilor legale ale instituției, a imaginii BNR sau chiar asupra piețelor financiare.
(12) Prin realizarea proiectului WEBSITE-v3 se urmăresc următoarele obiective:
A. Realiniere la standardele cele mai avansate ale domeniului. Se va asigura accesibilitate pe toate categoriile de device-uri (Responsive Design, Adaptive Design – mobile first), ameliorarea UX (User eXperience) – readability, navigability, interactivitate crescută (JS, AJAX) și orientare accentuată spre conținut vizual.
B. Publicare de informații în condiții de siguranță și ergonomie.
C. Management unitar al proceselor de comunicare pe website și pe conturile social media. Administrarea eficientă, centralizată, a tuturor aspectelor legate de informațiile
publice, pe tot parcursul fluxului de publicare: generare – validare – publicare – diseminare.
D. Creșterea transparenței și consolidarea prestigiului instituției. Publicarea în condiții de predictibilitate (urmărind un calendar reanunțat), sincron pe toate canalele (website și conturi social-media) și diseminarea promptă, activă a informațiilor (prin e-mail și push- notifications).
E. Îmbunătățirea serviciilor oferite utilizatorilor. Optimizarea regăsirii informației, căutare avansată (după domeniu, tip de conținut, cronologie etc), abonare on-line la diferite categorii de știri, formulare on-line pentru diverse solicitări. Posibilitatea realizării de sondaje sau interogări complexe ale publicului, pe bază de chestionar.
F. Întărirea rolului de conștientizare/educare financiară a publicului larg. Conținut ușor de înțeles, design atractiv, structură intuitivă și interactivitate mărită, simultan cu optimizarea căutării prin utilizarea tag-urilor.
G. Respectarea protocoalelor de schimburi de informații cu categoriile speciale de beneficiari: agenții de presă, instituții și autorități naționale, organisme internaționale, prin publicarea/diseminarea informațiilor specifice și a notificărilor către acestea, conform calendarelor prestabilite și monitorizarea strictă a stării fiecărei raportări.
H. Valorificarea informațiilor existente în website-ul actual, prin preluarea selectivă în WEBSITE-v3 de către prestator, conform necesităților exprimate de beneficiar în etapa de analiză.
I. Monitorizarea unor parametri de performanță, precum și a încercărilor de acces neautorizat. Extragerea de informații relevante pentru fine-tuning. Urmărirea fazelor de execuție a taskurilor de publicare/ diseminare și a erorilor.
J. Monitorizarea nivelului de interes pe secțiuni și obiecte, statistici de accesare.
K. Limitarea dinamică a accesului abuziv (atacuri de tip DoS) și blocarea posibilităților de SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF) etc.
B. Specificații tehnice
(13) Cerințele exprimate în acest capitol vor fi interpretate drept minimale, implementarea lor fiind obligatorie. În faza de analiză a proiectului, beneficiarul și ofertantul vor stabili de comun acord specificațiile detaliate (v. cap. D. Desfășurarea proiectului).
(14) Nerespectarea de către ofertant a oricăreia dintre cerințele specificate în acest capitol conduce automat la descalificarea ofertantului respectiv.
B.1. Structura sistemului informatic
Arhitectura sistemului actual
S4
C1
S1
S3
C2
INTERNET
S2
DMZ
S5
INTRANET
C1 - Utilizatori publici C2 – Administratori web
S1 (Web Server) - Hosting Site BNR, Windows, legătura Gigabit cu S2
S2 (Database Server) - Hosting al bazei de date proprii site-ului
S3 (Import Server) - Hosting al serviciului destinat procesării documentelor excel și importul datelor din acestea în baza de date S2 precum și apelarea procedurilor stocate din S4 la anumite intervale de timp setate din CMS
S4 (Database Server) – Hosting al bazei de date-sursă, pentru importul de date în S2 prin obiecte stocate, apelate de S3
S5 (File Server) - Fișiere Excel-sursă, legătura Gigabit cu S3
Cerințe
(15) Evoluția așteptată la realizarea WEBSITE-v3 este asigurarea unei separări efective a front- end-ului de back-end. Cel din urmă va fi accesibil doar din intranet, în timp ce front-end-ul va expune utilizatorilor din internet strict funcțiunile rezervate acestora.
(16) WEBSITE-v3 va fi aliniat sub aspect tehnologic la standardele și practicile actuale în materie.
(17) Oferta va preciza configurația hardware-software pe componente. Pentru echipamente hardware se va preciza configurația minimă și cea recomandată pentru fiecare server, iar pentru software se vor prezenta eventualele recomandări referitoare la modul de licențiere.
(18) Sistemul se va instala și configura pe infrastructura virtuală BNR conform specificațiilor furnizorului. Fiecare mediu (producție și test) va permite instalarea prin replicare și reconfigurare.
(19) Modulele componente ale sistemului WEBSITE-v3 vor fi implementate ca sisteme de tip centralizat, într-o arhitectură pe 3 nivele: nivel prezentare, nivel logică de business, bază de date pentru stocarea modelelor de date.
(20) WEBSITE-v3 trebuie să fie capabil să inițieze mai multe procese simultan și să asigure accesul concurent la informații, cu evitarea blocărilor reciproce.
(21) WEBSITE-v3 trebuie să fie modular și deschis. Soluția trebuie să fie robustă, să permită procesarea unor volume mari de date (dublarea volumului actual de date și de trafic), scalabilă, să tolereze sporirea numărului de utilizatori și să asigure portabilitate pe diverse platforme hardware posibil necesare în dezvoltarea ulterioară a băncii.
(22) Sistemul WEBSITE-v3 trebuie să suporte migrarea pe sisteme de tip cluster, fără a necesita adaptări ulterioare ale codului.
(23) Sistemul informatic WEBSITE-v3 va suporta mecanisme de load-balancing, reverse proxy și va include o componentă de monitorizare a utilizării resurselor hardware (accesibilă și din back- end).
(24) WEBSITE-v3 trebuie să funcționeze ca un proces continuu, în timp real, fără a fi necesară intervenția administratorilor tehnici în timpul funcționarii normale.
B.2. Structuri de date
Clase de informații, tipuri de clase, metainformații
(25) Conținutul informațional al site-ului este organizat în clase de informații, care reprezintă seturi de informații care pot fi tratate unitar având aceeași natură, tematică și sursă, precum și un regim de publicare/actualizare specific. Câteva exemple tipice sunt următoarele:
o Cursul zilnic al pieței valutare (serii statistice ale valutelor cotate de BNR);
o Buletinul lunar;
o Reglementări BNR;
o Monede numismatice;
(26) Clasele de informații se încadrează în anumite tipuri, în funcție de natura lor, spre exemplu:
o Serii statistice – serii de înregistrări care urmăresc evoluția unor indicatori în timp (ex: Cursurile pieței valutare – serii zilnice);
o Publicații – fișiere PDF, HTML, EPUB, XLS;
o Pagini (HTML) cu un regim de publicare periodic sau ocazional (ex: Comunicate de presă privind rezervele internaționale (lunare), Posturi vacante, Emisiuni numismatice) ;
o Conținut multimedia;
o Entități înregistrate în Registrele BNR (bănci, IFN) etc.
(27) Fiecărui tip de informații îi este asociat un set de metainformații (atribute specifice). Cu titlu de exemplu, clasa de informații “Buletine lunare - pdf” este de tip ”Publicații” și are asociate în baza de date următoarele metainformații: Titlu, Autor, Data înregistrării, An și Lună publicare, Număr de ordine, Sumar, Limbă, Cuvinte cheie, Drepturi (Copyright). Publicațiile de specialitate pot conține câmpuri suplimentare precum coduri JEL, ISBN/ ISSN.
(28) Metainformațiile sunt utilizate pentru prezentarea diferitelor tipuri de informații în website, fiind utilizate în cadrul template-urilor asociate claselor respective de informații. Ele permit de asemenea clasificări, filtrări, sortări, căutare avansată etc.
(29) Pentru evaluarea corectă a volumului de informații existent în prezent, care va trebui translatat (selectiv) în structura WEBSITE-v3, se prezintă mai jos statistica celor mai importante categorii:
o Clase statistice: 100 de clase distincte care grupează cca 4500 de indicatori;
o Comunicate de presă: cca. 2.500 (de pagini HTML), grupate în 12 clase distincte;
o Reglementări BNR: cca. 2.400 de înregistrări, într-o singură clasă;
o Publicații (incl. prezentări PDF): peste 8.000 de fișiere, grupate în 46 clase distincte;
o Emisiuni numismatice: cca. 750, o singura clasă;
o Alte pagini HTML : cca. 1800;
o Glosar: 324 de înregistrări, grupate în 9 clase distincte;
o Alte clase de informații, de ex. Evenimente, Grafice, Organigramă, Declarații de avere etc.: câteva sute de înregistrări, grupate în 20-30 de clase distincte.
(30) Pentru WEBSITE-v3 se solicită unificarea unor aspecte de administrare (cum ar fi definirea template-urilor de prezentare), redefinirea unor clase existente (ex: Organigrama, Declarații de avere), precum și definirea unor noi clase (ex: Registrul instituțiilor de credit).
(31) Configurarea drepturilor de acces se va efectua la nivelul claselor de informație și al funcționalităților (pentru administrare).
(32) O descriere detaliată a claselor de informații, a grupării acestora pe tipuri, precum și a metainformațiilor asociate, va fi pusă la dispoziția prestatorului în etapa de analiză.
Structuri de date ale modulelor funcționale
(33) Baza de date a site-ului actual conține, de asemenea, structurile de date necesare diferitelor module funcționale cum ar fi: modulul de import al datelor statistice din diferite baze de date interne, modulul de transmitere a notificărilor pe e-mail, date colectate cu ajutorul formularelor din site și informațiile administrative (superuseri, abonați etc.)
(34) WEBSITE-v3 va asigura o separație totală între front-end și back-end prin localizarea informațiilor administrative doar în mediul intern (excluderea acestora din baza de date a site- ului public).
(35) Se solicită și completarea structurilor de date administrative cu noi informații, cum ar fi datele de contact ale persoanelor care au calitatea de surse-autorizate, calendarul de diseminare al unor clase de informații, atribute care să semnaleze opțiunea distribuirii știrilor asociate acestora pe fiecare rețea de socializare etc. Structurile de date corespunzătoare acestor module vor fi stabilite de comun acord de către prestator și beneficiar, în funcție de soluțiile de implementare propuse.
(36) Anumite secțiuni ale website-ului, considerate de interes pentru utilizatori, vor fi mapate opțional pe subdomenii: de ex. Xxxxxx.XXX.xx, Xxxxxxxxxx.XXX.xx, Xxxxxxxxxx.XXX.xx, Xxxx.XXX.xx etc.
B.3. Conținut
Cerințe generale
(37) Pe baza analizei website-ului actual, prestatorul va furniza un concept creativ și linii strategice pentru abordarea și redactarea conținutului informațional în WEBSITE-v3, care să asigure o experiență îmbunătățită utilizatorilor.
(38) Conceptul creativ și planul strategic vor susține nemijlocit nevoile de informare și educare ale utilizatorilor website-ului, vor facilita înțelegerea de către aceștia a subiectelor prezentate. Forma finală a acestora va fi stabilită de comun acord cu beneficiarul în etapa de analiză detaliată a proiectului.
(39) Pe baza conceptului creativ acceptat, prestatorul va adapta conținutul editorial existent, pe noua structură a WEBSITE-v3.
(40) Se solicită rescrierea conținutul website-ului într-un mod creativ și simplificat, astfel încât să ofere informații ușor de înțeles pentru publicul larg.
(41) Pentru conținutul informațional al site-ului se solicită ca acesta să fie clar, concis și accesibil pentru cât mai multe categorii de audiență.
(42) Vor fi luate măsuri dedicate îmbunătățirii experienței utilizatorilor, prin abordarea atentă a elementelor de accesibilitate, navigabilitate și lizibilitate (UX).
(43) Textele vor fi susținute prin intermediul componentei vizuale pentru a spori nivelul de atractivitate și de interactivitate a informației: prestatorul va propune imagini sau animații, iar beneficiarul va asigura infografice și materiale video pentru a exemplifica anumite funcții și atribuții ale băncii.
(44) Vor fi oferite căi alternative de regăsire a informației astfel încât utilizatorii să găsească ușor informațiile care îi interesează (prin crearea automată de link-uri către termenii din Glosar, către acte legislative sau alte pagini speciale, introducerea unor componente de tip Întrebări și răspunsuri și prin optimizarea funcției de căutare avansată – după secțiune, tip de conținut, cronologie etc.).
(45) În anumite zone ale site-ului, conținutul va fi elaborat ținând cont de nevoia de educare financiară a publicului și de tipul de audiență urmărit (de exemplu, prin crearea unor secțiuni de Explainers/Resurse educaționale/Întrebări și răspunsuri – aici se pot prezenta activitățile principale ale băncii, fenomene ca inflația și deflația, modalitățile prin care banca centrală
încearcă să mențină stabilitatea prețurilor, noțiuni de putere de cumpărare, credite, depozite, economisire, investire etc.). O descriere detaliată a claselor de informații care vor intra în acest proces va fi pusă la dispoziția prestatorului în etapa de analiză.
B.4. Design
Cerințe generale
(46) Designul trebuie să fie sobru, elegant și aerisit și să respecte identitatea vizuală a BNR.
(47) Interfețele grafice vor oferi utilizatorilor experiențe de navigare coerente, vor fi intuitive și ușor de folosit.
(48) Sugestie de structurare a fișierelor CSS:
• style.css – stiluri comune, aplicate atât în site-ul public cât și în administrare – asigură posibilitatea editării WYSIWYG în CMS;
• public.css – aplicat doar site-ului public;
• admin.css – aplicat doar site-ului de administrare;
• mobile.css – aplicat doar pentru dispozitivele mobile;
• print.css – aplicat versiunii pentru tipărire;
• CSS-uri specifice pentru principalele tipuri sau categorii de informații – se aplică doar în cazurile respective (ex: gallery.css, publicații, tree-view etc);
(49) Prestatorul va prezenta propriile variante de design pentru homepage și pentru paginile de conținut (după perioada de analiză), machetele fiind apoi ajustate iterativ pentru a răspunde necesităților proiectului.
Designul site-ului public (front-end)
(50) Soluție de tip one-site, responsive/ adaptive web design (mobile first), urmărind redarea corectă a conținutului pentru utilizatorii diferitelor tipuri de terminale:
a. Mobile (tablete și smartphone), orientate portrait sau landscape;
b. Terminale de tip desktop și laptop;
c. Toată gama de browsere utilizate la nivel mondial, acoperind minimum 90% din numărul total de utilizatori;
d. Formatul paginilor va ține seama de necesitatea redării conținutului util (html) cu ajutorul cititoarelor vocale și Braille, pentru persoane cu handicap vizual/auditiv.
(51) Paginile de prezentare vor oferi o experiență de navigare unitară și coerentă, fiind compuse de regulă din elemente constitutive comune:
a. Logo;
b. Search;
c. Selector Limbă;
d. Modificare font;
e. Share;
f. Meniu navigare;
g. Coloană laterală (stânga/dreapta);
h. Footer;
i. Conținut propriu-zis, compus la rândul său din blocuri structurale.
(52) Adaptat tipurilor de conținut, se vor defini de comun acord cu beneficiarul stiluri unitare de prezentare a paginilor și formate-standard inspirate după website-urile altor bănci centrale.
(53) Elementele de animație (slider, carusel etc), nu vor induce o dinamică prea amplă în pagină, pentru a nu deturna atenția utilizatorilor de la conținutul informațional propriu-zis.
(54) Dimensiunea fonturilor va fi scalabilă (cu un mecanism de mărire/ micșorare) adecvat. Se va avea în vedere implementarea web fonts, găzduite local.
(55) Tooltip-ul standard va fi înlocuit cu o versiune stilizată (CSS+JS), cu fallback pentru browserele care nu suportă JS.
(56) În cazul tabelelor HTML de dimensiuni mari, se acceptă deschiderea tabelului într-o pagină dedicată, cu un design simplificat, având atașate facilități specifice (scroll dinamic cu păstrarea header-ului și a coloanei din dreapta).
(57) Galeria foto care deschide conținutul într-un lightbox trebuie să fie responsive și să aibă funcționalități de navigare, slideshow, zoom, share.
Interfața de administrare (back-end)
(58) Administratorii site-ului utilizează calculatoare desktop/laptop, având browsere comune actualizate la zi: Chrome/Mozilla/IE.
(59) CMS va permite editarea în regim WYSIWYG, precum și ”în cod”, cu acceptarea standardelor HTML5, SVG, CSS3/4, xml1.0 și JS. (preferabil cu syntax highlighting).
(60) Paginile vor fi asamblate pe baza unui set de blocuri structurale (building-blocks), optimizate din punctul de vedere al designului pentru prezentarea unor categorii specifice de informații. Se solicita implementarea minimum a următoarelor blocuri structurale:
a. bloc de cod HTML static;
b. bloc de cod HTML dinamic (include conținut adus din BD prin select-uri SQL);
c. Calendar;
d. Formular/Sondaj;
e. Galerie imagini + lightbox;
f. Bază de date interactivă;
g. Publicații;
h. Listă de știri (cu posibilitatea de filtrare/ selecție);
i. Grafic;
j. Hartă;
k. Conținut multimedia (video, audio, Iframe);
l. Card (structură dreptunghiulară cu o imagine de impact, titlu, descriere scurtă și link “read more”);
m. Lista colapsabilă (acordeon/ dropdown);
n. Butoane;
o. Tab-uri;
p. Coloane pe dimensiuni prestabilite (1/4, 1/3, 2/3, 1/2 etc.);
q. Note de subsol;
r. Banner mesaje/ imagini;
s. Tabele;
t. Articol (gen blog);
u. Monedă numismatică;
v. Slider/ Carusel;
w. Time-line
x. Componente definite administrativ (custom).
(61) Interfața de administrare va fi optimizată din punct de vedere al ergonomiei și funcționalității, și va include pagini de tipul dashboard de monitorizare a principalelor procese.
(62) Nu este admisă includerea de reclame, link-uri, banner-e sau alte informații comerciale, nici în interfața front-end, nici în interfața back-end.
B.5. Funcționalități
Funcționalități destinate administratorilor
(63) Interfața de administrare va integra următoarele funcțiuni, detaliate în capitolele următoare:
a. Administrarea conținutului, printr-o interfață specializată de tip Content Management System (CMS)
b. Modulul de publicare
c. Administrarea șabloanelor (secvențe de cod HTML preformatate, cu posibilitatea includerii unor informații extrase din baza de date, cu diverse utilizări)
d. Modulul de import
e. Modulul de notificare prin e-mail
f.Sondaje și formulare tipizate
g. Management log-uri de accesare
h. Monitorizare parametri de performanță
i. Versionare pagini - permite administratorilor revenirea la o versiune anterioară, dintr-un număr de 5 (versiuni salvate anterior)
j. Redirectare la o altă pagină (oricărei pagini i se poate asocia o comandă de redirectare)
k. Administrare utilizatori cu roluri administrative (administratori, editori, validatori)
l. Administrarea abonaților (utilizatori publici)
m. Administrarea homepage-ului
n. Setarea parametrilor de lucru ai sistemului. Nu se vor utiliza hard-codări pentru: parametri, path-uri, adrese, hostname-uri etc, toate setările administrative de acest tip fiind customizabile printr-o pagină dedicată acestora.
o. Administrarea serviciului de cache pentru paginile publice.
p. Funcționalitățile dinamice client-side vor fi implementate cu JavaScript, structurate astfel încât să poată fi testate în faza de previzualizare a paginii. Se va asigura vizibilitatea conținutului paginilor chiar și pentru browsere care au JavaScript dezactivat.
Funcționalități destinate utilizatorilor publici
a. Noutăți
(64) Listă care va expune un index al noilor informații publicate în site (generare automată, perisabilitate). Se vor prezenta data, rezumatul și legătura către textul complet al acestora sau secțiunea-gazdă.
b. Căutare. Căutare avansată
(65) Motor intern de indexare a informațiilor. Se vor indexa atât conținutul paginilor, cât și conținutul documentelor publicate (Word, Excel, PDF etc.), precum și metainformațiile asociate imaginilor.
(66) Rezultatele căutării se vor afișa în ordinea relevanței, paginate dinamic. Fiecare rezultat va consta din: breadcrumb - care va exprima poziția paginii în arborele site-ului, un link și un extras relevant în care vor fi evidențiați termenii căutării.
(67) Căutarea va fi indiferentă la diacritice.
(68) Căutarea avansată va permite efectuarea de căutări pe categorii de informații: indicatori statistici, documente, imagini, în Registrele BNR, în secțiuni specifice, pagini HTML, termeni în Glosar etc.
(69) Prestatorul va realiza optimizări pentru search engine (SEO) și pentru social networks (tag- urile specifice).
(70) Implementarea funcțiilor de căutare cu ajutorul unor motoare de căutare externe se poate realiza doar dacă prestatorul asigură respectarea tuturor condițiilor legale corespunzătoare acestei soluții (incluzând reglementările legate de prelucrarea datelor cu caracter personal).
(71) Pentru asigurarea unei compatibilități cu website-ul actual, va fi prevăzută o posibilitate de redirectare a URL-urilor actuale către noile adrese.
c. Facilități pentru preluarea automată a datelor
(72) Pentru utilizatori care accesează date în mod regulat și aplicații informatice care utilizează site-ul BNR ca sursă de date se vor asigura următoarele facilități:
i. posibilitatea parsării paginilor HTML ale site-ului (url-uri persistente în timp);
ii. accesarea unor categorii de informații printr-un serviciu REST;
iii. anumite categorii de date vor fi expuse și în fișiere xml. Se va asigura continuitatea serviciilor oferite de website-ul actual.
d. Abonare on-line
(73) Utilizatorii vor avea posibilitatea abonării la noutăți pentru diferite secțiuni și categorii de informații (stabilite administrativ). Procedura de validare a abonării se va baza pe verificarea adresei de e-mail și va include acceptarea unor Termeni și condiții, printr-o bifă.
(74) Printr-un link inclus în corpul e-mailului transmis, abonații vor avea posibilitatea dezabonării sau a modificării categoriilor de informații la care s-au abonat.
(75) Lista abonaților va fi administrabilă printr-o pagină dedicată care să permită căutarea adreselor, validarea, abonarea și dezabonarea administrativă și filtrarea înregistrărilor multiple.
e. Selector de limbă (română – engleză)
(76) Website-ul prezintă de regulă conținut bilingv: română-engleză. Selectorul de limbă permite utilizatorului să modifice limba în care este afișată pagina din fereastra curentă. În cazul paginilor fără corespondent în limba engleză, se va efectua o redirectare în pagina corespunzătoare celui mai apropiat părinte care dispune de versiunea în limba engleză.
f. Statistică interactivă
(77) Sistemul va permite stocarea datelor într-o structură multidimensională (o anumită serie de date va putea fi asociată cu diferite atribute (dimensiuni) care permit filtrarea categoriilor de interes pentru utilizator, ex: Xxxxxx în care este exprimată valoarea (RON/EUR/USD), Valori medii sau sfârșit de perioadă, Ajustate sezonier/neajustate etc. Seriile statistice vor fi prezentate utilizatorilor sub formă unei vizualizări de tip arbore (Tree view), cu posibilitatea selecției datelor de interes, prin bifarea clasei de indicatori statistici, a atributelor de filtrare (dacă există) și apoi a seriilor statistice de interes.
(78) Datele statistice vor fi prezentate tabelar (HTML) și vor putea fi exportate în XLS, XML și CSV). Exemple relevante se regăsesc pe site-urile altor bănci centrale (Banca Centrală Europeană, Banca Federală a Germaniei, Banca Portugaliei etc.) sau al EUROSTAT.
(79) Utilizatorii vor avea posibilitatea de a-și salva URL-ul raportului obținut ca bookmark, pentru referențiere ulterioară la același set de indicatori.
(80) Datele din statistica interactivă vor putea fi accesate de către terți și prin intermediul unui API bazat pe REST sau servicii similare, care va permite extragerea datelor de interes pentru utilizatori.
g. Vizualizări pentru date statistice (dezvoltare nouă)
(81) WEBSITE-v3 va include grafice standard (Line, Column/ Bar, Pie), teritoriale (județe, țări UE), cu interactivitate minimum la nivelul axelor.
h. Tipărire și salvare ca PDF
(82) Versiunea generată pentru imprimare va include doar conținutul principal, având o formatare adecvată tipăririi și cu includerea unor elemente de identitate vizuală specifice BNR, în antet.
i. Formulare
(83) Vor fi implementate formularele existente în website-ul actual (solicitare acces la Arhivă, Muzeu, Bibliotecă și Petiții on-line). Administrativ se vor putea defini noi formulare, sondaje, chestionare, incluzând funcționalități care permit încărcarea unor fișiere.
j. Hartă site
(84) Va prezenta structura acestuia și va fi generată dinamic, la cerere sau în urma unei modificări administrative care are ca rezultat o schimbare în structura site-ului. Varianta publică a hărții va fi generată în urma filtrării parametrizate a elementelor irelevante.
k. Glosar
(85) La activarea acestei funcționalități, pe pagina curentă vor fi identificate și marcate distinct cuvintele și expresiile care se regăsesc în Glosar. La mouseover, definiția termenului va fi afișată într-un tooltip.
l. URL shortener realizat ca serviciu propriu al WEBSITE-v3
(86) Nu este permisă integrarea cu servicii publice de URL shortener.
m. Modificare dimensiune font.
n. Webcasting și arhivă video
(87) Site-ul va permite transmiterea în timp real a fluxurilor video (prezentat într-un bloc constructiv dedicat, care include un iframe și care ar putea fi plasat și pe un subdomeniu – ex: xxxx.xxx.xx), precum și posibilitatea de a furniza, on-demand, conținut extras dintr-o arhivă video. Player-ul video trebuie să fie compatibil HTML 5, cu fallback în Flash și va avea opțiune de download.
o. Legislație – secțiune adaptată pentru conținut cu specific legislativ
(88) Introducerea unor posibilități de filtrare avansată a indexului legislativ (în funcție de tematică, tip act, titlu, perioadă, tag-uri etc.).
p. Last updated
(89) Fiecare pagină va conține un atribut (afișabil) referitor la momentul ultimei actualizări.
(90) Site-ul va fi optimizat pentru încărcare rapidă prin utilizarea de sprite-uri, încărcarea progresivă a imaginilor, comasarea și minificarea (on-the-fly) a fișierelor CSS și JS, mecanisme dedicate de caching, gzip etc. (conform unor parametri de sistem).
(91) În cazul în care sistemul informatic nu poate funcționa pentru o perioadă de timp se va afișa temporar o pagină de eroare statică.
q. Tur virtual
(92) Preluarea funcționalității existente se va realiza cu migrarea din Flash în HTML5/ JS.
r. Aplicația mobilă
(93) Principalele informații solicitate vor fi puse la dispoziția utilizatorilor și prin intermediul unei aplicații mobile:
i. Curs (incl. convertor) valutar
ii. Dobânzi BNR
iii. Noutăți (lista de știri)
iv. Info financiar (o selecție de indicatori)
(94) Aplicația va putea fi descărcată gratuit de pe principalele depozite de aplicații online: App Store (Apple - iOS), Google Play (Android).
(95) Modulul Curs și convertor valutar va fi livrat și ca widget independent.
(96) Aplicația va avea opțiune de notificări push pentru diferite seturi de date, precum și refresh la cerere. Datele vor fi descărcate local, pentru uzul off-line, cu semnalarea depășirii pragurilor de perisabilitate prestabilite.
(97) Aplicația va fi disponibilă în limbile română și engleză.
(98) Aplicația va fi publicată în depozitele de aplicații online App Store (Apple - iOS) și Google Play (Android) în numele BNR, folosind conturile BNR; publicarea de componente ale acesteia în numele altor entități este interzisă.
B.6. Administrare
Generalități
(99) Paginile site-ului sunt servite utilizatorilor (public și administratori) de către Webserver-ul S1 (vezi cap. B1), conținutul informațional fiind stocat în baza de date a site-ului (pe serverul S2), iar documentele și imaginile sunt stocate într-o structură de foldere administrabilă, pe S1. Sistemul beneficiază de asemenea de un serviciu de cache customizabil.
(100) Prin proiectul curent se urmărește separarea Back-end-ului de Front-end. Componenta de administrare va fi separată (URL, port distinct) față de componenta vizibilă public și de componenta API (v. cap. B.8. Securitate).
(101) Funcționalitățile destinate administratorilor, enumerate în cap. B.5. vor fi implementate ținând cont de cerințele detaliate în continuare.
Interfața de administrare (Content Management System - CMS)
(102) CMS-ul permite utilizatorilor autentificați ca Administratori, Content editori sau Validatori să adauge/ modifice sau să șteargă elemente din conținutul și structura site-ului, precum și să configureze/ întrețină diversele servicii și funcționalități oferite de website.
(103) CMS dispune de o componentă ce asigură posibilitatea editării WYSIWYG, respectiv permite introducerea informațiilor și formatarea lor fără a necesita o pregătire specială. Componenta de editare va permite de asemenea și editarea directă a codului generat.
Workflow de publicare
DOCUMENT D2
DOCUMENT D1
TEMPLATE T1
Template designer Content Editor Content Validator BNR Site
(104) Pentru publicarea unei categorii de informații noi se parcurg de regulă următorii pași:
1. Crearea șablonului de pagină în care vor fi prezentate informațiile clasei respective, de către un Administrator („Template Designer”).
2. Generarea unei noi înregistrări în clasa respectivă publicarea unei informații aparținând clasei respective un Content Editor va introduce informațiile în site prin interfața de administrare. Aplicația va prezenta o pagina de tip Preview unui Validator, autorizat să activeze publicarea acesteia.
3. Pentru clase de informații cu publicare repetitivă, un serviciu de import automat asigură preluarea informațiilor, în mod programatic.
(105) Utilizatorul cu rol de „Content Editor” poate introduce, șterge sau actualiza datele existente, fără a fi nevoit să aibă cunoștințe extinse de HTML, având la dispoziție și o interfață duală, WYSIWYG + HtmlEditor. Interfața va permite și inserarea de imagini, documente (pdf, doc, xls, zip etc) și conținut video. Aceste resurse sunt încărcate pe server dintr-o interfață web specializată care permite generarea de metainformații (între care un set Dublin Core simplificat).
(106) Pentru publicarea de informații cu caracter de unicat sau ocazional administratorii realizează pagini individuale, respectând designul general al site-ului.
Administrarea utilizatorilor
(107) Utilizatorii website-ului se împart în trei categorii:
(1) utilizatori publici
(2) utilizatori cu drepturi speciale (superuseri): administratori, webeditori și validatori
(3) surse autorizate (persoanele responsabile cu furnizarea de date, corespunzătoare fiecărei clase de informații) – pot face (opțional) obiectul unor notificări email.
(108) Sursele autorizate pot avea și rol de editori sau validatori.
(109) Controlul drepturilor se face la nivel de grupuri de utilizatori și roluri, pe fiecare categorie de informații sau funcționalitate.
(110) Administratorii pot modifica componența grupurilor de utilizatori, aceasta afectând imediat drepturile de acces subsecvente.
(111) Administrarea utilizatorilor include înregistrarea informațiilor de contact despre fiecare persoană (telefon, direcție, e-mail etc.).
(112) Toate operațiunile efectuate de superuseri vor fi logate în scopuri de audit.
Administrarea claselor și a grupurilor de informații
(113) Administrarea informațiilor publicate se face la nivelul claselor de informații sau al grupurilor de clase. Clase de informații (definite cf. cap. B2) care au anumite trăsături comune pot fi tratate la nivel de grup (ex: grupul comunicatelor de presă, grupul publicațiilor BNR etc.).
(114) Grupurile și clasele sunt definite de către administrator. Crearea unei pagini în site necesită specificarea mapării pe o clasă sau un grup. La un grup se pot adăuga în timp noi clase sau șterge clase existente. O clasă poate fi dezactivată pentru a deveni invizibilă în site.
(115) Cele mai multe clase sunt generate în momentul creării de noi pagini și reflectă structura sitului. Clasele pot fi modificate oricând de către un administrator.
(116) La nivelul claselor de informații se configurează drepturile de acces, politicile de publicare și de diseminare, inclusiv alerte adresate surselor autorizate.
Administrarea șabloanelor (template-urilor)
(117) Șabloanele HTML includ zone de cod fixe precum și zone care se completează dinamic din atribute ale unui membru al clasei la care este asociat sau din valori tabelare, extrase din baza de date a site-ului.
(118) Elementele dinamice sunt exprimate prin marcatori de forma [##inflatie##] (pentru valori simple) sau prin marcatori de tipul [##SURSA_DATE##] ... șablon ... [##/SURSA_DATE##] – pentru a genera tabele conform unui șablon precizat.
(119) Tipuri de template-uri utilizate în website-ul actual:
▪ pagini de website specifice pentru anumite secțiuni/clase de informații (ex: Rata dobânzii de politică monetară, Index legislativ, Achiziții BNR etc.) - acestea se populează dinamic, la fiecare accesare a paginii;
▪ template-uri cu modele de prezentare, adresate webeditorilor (ex: în cazul comunicatelor de presă, webeditorii dispun de formate prestabilite în care încarcă informațiile utile, rezultatul fiind stocat ca un cod HTML de sine stătător, fără a se păstra referința la template-ul utilizat;
▪ template-uri de e-mail - pentru transmiterea de notificări către abonații la diferite categorii de noutăți sau alte categorii de beneficiari;
▪ template-uri de notificări - pentru diseminarea de informații către liste de e-mail-uri.
(120) Pentru a asigura compatibilitatea cu setul de șabloane existent, în faza de analiză prestatorul va primi informațiile detaliate despre șabloanele și marcatorii existenți, în vederea translatării acestora în noul website.
(121) Pentru WEBSITE-v3 se solicită unificarea șabloanelor actuale (implementate în prezent ca module separate, cu grade diferite de complexitate), precum și includerea unor șabloane pentru generarea știrilor pe homepage (care pot include și o imagine), precum și destinate publicării pe rețelele de socializare.
Modulul de publicare
(122) Scenariul de publicare cuprinde o serie de acțiuni a căror succesiune va fi stabilită administrativ: editare, previzualizare, validare, setare oră publicare, setare canale de distribuție, publicare conținut principal (HTML, document etc.), publicare știre, publicare banner/ știre pe homepage, distribuire către abonați, publicare pe rețelele de socializare, unde se publică de regulă serii de articole, atât înainte (pre-anunțuri), cât și după publicarea principală (mesaje- cheie).
(123) Modulul va permite controlul administrativ al tuturor parametrilor de publicare/ diseminare, permițând aplicarea unor „politici de diseminare” prestabilite, care prevăd, în raport cu momentul publicării paginii pe website, momentul transmiterii de pre-notificări e-mail, pre-
anunțuri pe homepage, regimul de diseminare al informațiilor (pe homepage, e-mailuri abonați și către liste de diseminare, push notifications (mobil), diseminare pe platformele de socializare (Twitter, YouTube, LinkedIn și, în perspectivă, Instagram și Facebook)).
Modulul de notificări
(124) Va asigura generarea de mesaje adecvate pentru o gamă largă de beneficiari: abonați ai diferitelor categorii de știri, liste de distribuție, surse autorizate și alți utilizatori interni.
(125) Conținutul mesajelor este generat dinamic, conform unor șabloane administrabile. Momentul transmiterii este de asemenea stabilit prin intermediul unui trigger programabil (SQL). Funcționarea modulului va putea fi întreruptă administrativ, iar task-urile de diseminare vor putea fi administrate individual. Modulul va transmite mesajele prin intermediul serverelor de poștă electronică existente.
Modulul de import
(126) Asigură preluarea automată de date din surse externe site-ului:
a. view-uri Oracle special concepute în acest scop, dintr-o schemă Oracle accesibilă prin rețeaua internă;
b. fișiere XLS cu un format standard, amplasate într-un director partajat din rețeaua internă;
c. pagini HTML cu un format fix, publicate de alte instituții, pe site-urile proprii.
(127) Tipurile de date importate sunt: dată, numerice, alfanumerice.
(128) Datele încărcate vor putea fi previzualizate înainte de publicare, fără ca acestea să fie accesibile publicului.
(129) Serviciul de import de date va permite stabilirea coordonatelor de conectare la schema Oracle-sursă, la file-serverul unde sunt localizate fișierele XLS-sursă, precum și la sursele de date din internet.
(130) Tipul de date, regimul de import condițiile de validare a datelor, precum și ceilalți parametri implicați, vor fi administrabili.
(131) Momentul importului va putea fi stabilit pentru fiecare clasă de informații ca valoare absolută, ca șir de date calendaristice (calendar de actualizare) sau dinamic, în funcție de alte evenimente/actualizări din baza de date.
(132) Modulul va fi prevăzut cu posibilitatea declanșării manuale a încărcării, precum și cu posibilitatea încărcării manuale a datelor, printr-o interfață adaptată, în cazul apariției unei disfuncționalități.
Administrare Homepage
(133) Toate zonele homepage-ului (inclusiv Zona Logo) vor permite modificarea administrativă a conținutului.
(134) Sistemul va permite stabilirea unor reguli complexe de selecție a elementelor publicate (spre exemplu pentru generarea listei cu cele mai importante noutăți), precum și posibilitatea introducerii de elemente noi, anunțuri urgente etc.
Modulul formulare-sondaje
(135) Pentru colectare de informații, website-ul va conține o soluție pentru realizarea de formulare care să includă câmpuri de tip text, numerice, flag binar, radio-buttons, drop-down list. Se va asigura un nivel intermediar de validare internă a conținutului, precum și protecția împotriva injecției de cod/conținut malițios.
(136) În prezent formularele sunt utilizate pentru solicitare acces la Arhivă, Muzeu și Biblioteca BNR, precum și pentru Petiții on-line.
(137) WEBSITE-v3 va permite utilizatorului public încărcarea de fișiere (pdf, xls, doc, imagini și video), precum și colectarea de comentarii la articolele publicate.
B.7. Monitorizare. Logare activități
(138) Acțiunile de monitorizare vor avea un impact minimal asupra performanțelor site-ului.
Monitorizare accesări
(139) Pentru a nu impacta performanța serverului WEB, logurile de accesare vor fi salvate în pachete de înregistrări, într-o bază de date separată, optimizată pentru astfel de operațiuni.
(140) Având în vedere faptul că zilnic se înregistrează peste 2 milioane de accesări, tot zilnic la o anumită oră (cu trafic minim), se va executa o procesare automată pentru extragerea informațiilor relevante, iar înregistrările mai vechi se vor șterge din baza de date. Perioada de retenție a înregistrărilor va fi setată conform unor parametri de administrare.
(141) Din setul de informații consolidate la nivel zilnic vor face parte minimum:
α. Statistică vizitatori site (IP-uri distincte);
β. Statistică accesări pagini – Top 200 (după numărul de accesări);
χ. Statistică accesare pe secțiuni (ale arborelui site-ului);
δ. Statistică privind durata medie petrecută pe pagini;
ε. Repartiția geografică a utilizatorilor;
ϕ. Dispozitive utilizate (desktop, tabletă, smartphone etc.), browser-ul utilizat;
γ. Top 100 Referrers;
η. Top 1000 cuvinte cheie/expresii căutate.
(142) În faza de analiză vor putea fi propuse/ agreate de comun acord și alte statistici relevante.
Monitorizare website
(143) Acțiunile efectuate automat de către serviciile site-ului (import, publicare, transmitere de e- mailuri și mesaje destinate rețelelor de socializare etc) vor fi logate, cu posibilitatea setării unor filtre/ excepții parametrizabile.
(144) Acțiunile aflate în diferite stadii de derulare vor fi prezentate într-o interfață dashboard dedicată.
(145) Modulul de administrare va include și o secțiune de monitorizare a parametrilor de funcționare a serverelor Web și a bazelor de date.
(146) Viteza de servire a conținutului, erorile înregistrate în loguri, ratarea unor deadline-uri de publicare (în raport cu calendarele sau momentele prestabilite) vor fi înregistrate, cu posibilitatea setării unor filtre și a transmiterii de alerte e-mail, precum și cu semnalizarea grafică pe pagina dashboard.
(147) Cazurilor de eroare și excepțiile vor fi procesate de un sistem de tratare adecvat.
Monitorizare superuseri
(148) Toate acțiunile administrative vor fi logate în scopuri de audit: modificările de conținut, modificările de securitate, precum și acțiunile de modificare a funcționalităților sau parametrilor generali.
(149) Interfața de administrare nu va permite ștergerea informațiilor logate.
B.8. Securitate
(150) Website-ul public va fi separat de website-ul de administrare, care va fi accesibil exclusiv din intranet (URL distinct).
(151) Autentificarea utilizatorilor site-ului public se va face prin adresă de e-mail și parolă, pentru a permite abonarea la diverse categorii de știri. Opțional interfața de abonare poate include un cod CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart)
(152) Website-ul de administrare va permite autentificarea următoarelor categorii de superuseri:
a. Administratori;
b. Web-editori;
c. Validatori.
(153) Accesul superuserilor va respecta următoarele cerințe:
a. Autentificarea se efectuează pe bază de nume utilizator și parolă;
b. Modelul de implementare a drepturilor de acces va fi pe grupuri și roluri;
c. Interfața de administrare va permite controlul drepturilor de administrare de conținut, a drepturilor de administrare a securității etc., cu o granularitate adecvată;
d. Accesul la diferitele componente ale interfețelor de administrare se va face numai în limita drepturilor stabilite pentru grupurile și rolurile corespunzătoare;
e. Accesul la interfața de administrare va putea fi restricționat la nivel de adrese IP, cu posibilitatea definirii whitelist/ blacklist;
f. Se va aplica regimul de configurare și actualizare al parolelor stabilit prin politica de securitate a BNR, care va fi comunicată dezvoltatorului în faza de analiză;
g. Criptarea datelor de autentificare în baza de date, astfel încât să se asigure confidențialitatea datelor.
(154) Soluția va include mijloace de prevenire a atacurilor de tip DoS, SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF) etc.
(155) Preluarea automată de date din surse externe trebuie prevăzută cu un mecanism de verificare și validare a acestora din punct de vedere al securității, iar interacțiunea cu celelalte baze de date se va realiza securizat (configurare network encryption + certificate). Ofertantul va asigura identificarea și implementarea soluțiilor, cu consultarea prealabilă a beneficiarului.
(156) Oferta va evidenția riscurile și punctele de vulnerabilitate ale sistemului. Se vor propune eventuale măsuri adiționale de optimizare a nivelului de securitate și metode proactive în vederea prevenirii și identificării rapide a atacurilor.
(157) Metodologia de implementare va include o etapă de verificare a codului prin utilizarea unor unelte automate în vederea identificării erorilor/vulnerabilităților. Rezultatele revizuirii vor fi
transmise beneficiarului în etapa premergătoare solicitării acceptanței pentru faza/modulul respectiv.
(158) WEBSITE-v3 va beneficia la toate nivelele de mecanisme de securitate standard moderne (ex: HTTPS, VPN etc.).
(159) Pentru configurare, instalare sau setare a modulelor se vor folosi, de preferință, script-uri care vor fi documentate corespunzător.
(160) Sistemul va permite efectuarea facilă a operațiunilor de back-up/ restore, manual sau programat, atât pentru bazele de date, cât și pentru fișierele core. Back-up-urile trebuie să fie compacte și să poată fi preluate ușor de către sistemele de back-up ale BNR.
(161) WEBSITE-v3 trebuie să respecte legislația din România în toate domeniile aplicabile, inclusiv în cel al protecției datelor cu caracter personal.
C. Resurse necesare
(162) Prin transmiterea ofertei sale, agentul economic ofertant se angajează să asigure, în cazul selecției sale ca furnizor agreat pentru realizarea proiectului, toate resursele necesare finalizării acestuia în parametrii și în termenul stabilit, respectiv:
C.1. Resurse tehnice
(163) Furnizorul va dispune de toate resursele tehnice necesare dezvoltării proiectului, precum și al efectuării testărilor necesare (ex: simularea traficului web – pentru testarea performanței de răspuns în diferite condiții de încărcare).
C.2. Resurse umane
Managerul de proiect
(164) Furnizorul va desemna în calitate de Manager de proiect o persoană având competența și experiența adecvate nivelului de complexitate și importanță al proiectului curent. Condițiile impuse pentru această poziție sunt precizate în cadrul Condițiilor minime de calificare.
Experții-cheie
(165) Ofertantul va asigura resursele umane necesare și alocarea dinamică a acestora în funcție de necesitățile fiecărei etape, în vederea realizării în bune condiții a proiectului curent.
(166) Xxx echipa prestatorului sunt considerați a fi de o importanță deosebită următorii experți- cheie, pentru care se vor prezenta detaliile specificate, în vederea evaluării:
1. Expert dezvoltare software
- Competențe certificate privind tehnologiile utilizate în soluția propusă;
- Portofoliu de proiecte, cu descrierea elementelor relevante în raport cu solicitările Caietului de sarcini.
2. Expert baze de date
- Competențe certificate privind tehnologiile utilizate în soluția propusă;
- Portofoliu de proiecte, cu descrierea elementelor relevante în raport cu solicitările Caietului de sarcini.
3. Designer web
- Portofoliu de proiecte, cu descrierea elementelor relevante în raport cu solicitările Caietului de sarcini
4. Expert user experience/user interface (UX/UI)
- Portofoliu de proiecte, cu descrierea elementelor relevante în raport cu solicitările Caietului de sarcini
5. Programator aplicații mobile
- Portofoliu de proiecte, cu descrierea elementelor relevante în raport cu solicitările Caietului de sarcini
6. Expert Content writer
- Portofoliu de proiecte, cu descrierea elementelor relevante în raport cu solicitările Caietului de sarcini
(167) Având în vedere faptul că evaluarea echipei de proiect se va efectua pe baza portofoliilor de proiecte prezentate, este necesar ca acestea să reflecte cât mai bine capacitatea experților- cheie de a răspunde la un înalt nivel calitativ cerințelor specificate în Caietul de sarcini. Vor fi luate în considerare numai realizările/exemplele corelate cu domeniile de expertiză asumate în cadrul proiectului curent, respectiv:
a. Pentru poziția de Specialist dezvoltare software
Ofertantul trebuie să facă dovada capacității de realizarea de funcționalități destinate utilizatorilor publici, precum și a funcționalităților destinate administratorilor, de tipul celor descrise în capitolele: B.5. Funcționalități și B.6. Administrare.
b. Pentru poziția de Expert baze de date
Ofertantul trebuie să facă dovada capacității de proiectare a structurilor/bazelor de date și a diagramelor de conexiuni, de realizare practică a unor baze de date cu un grad de complexitate similar proiectului curent și utilizând tehnologia propusă în cadrul ofertei depuse.
c. Pentru poziția de Designer web
Ofertantul trebuie să facă dovada capacității de a genera un concept creativ general care să reflecte contextul și obiectivele unui website, să facă dovada capacității de a realiza un design al paginilor care să contribuie la consolidarea imaginii BNR, fiind comparabil din punct de vedere al nivelului estetic dar și al tehnologiilor adoptate cu design-ul altor bănci centrale. Vor fi oferite exemple care sunt relevante în raport cu
cerințele referitoare la designul site-ului public (front-end), incluse în Caietul de sarcini la capitolele B3. Conținut și B.4. Design.
d. Pentru poziția de și Specialist UX/UI
Ofertantul trebuie să facă dovada capacității de a realiza o soluție responsive/adaptive web design, care să plaseze site-ul BNR la un nivel comparabil din punct de vedere estetic și al tehnologiilor adoptate cu site-urile celorlalte bănci centrale europene. Vor fi prezentate exemple de integrare de elemente interactive (galerie, slider, carusel etc), precum și soluțiile de îmbunătățire a experienței utilizatorului (accesibilitate, navigabilitate, usability) implementate, similare celor solicitate în cadrul proiectului curent (v. cap. B3. Conținut, B.4. Design și B5.Funcționalități).
e. Pentru poziția de Programator aplicații mobile
Ofertantul trebuie să facă dovada capacității de a implementa cerințele proiectului în privința realizării unei aplicații mobile, interconectată cu website-ul propriu-zis. Se vor oferi exemple referitoare la proiecte anterioare, cu specificarea atribuțiilor avute (ex: realizarea arhitecturii aplicației, stabilirea fluxurilor de navigare/ operare/ procesare, comunicație cu sisteme exterioare etc), atât pentru Android cât și pentru iOS, care sunt similare/comparabile cu aplicația mobilă solicitată prin proiectul curent (v. cap. B5. Funcționalități destinate utilizatorilor publici, lit.r. Aplicația mobilă).
f. Pentru poziția de Content writer
Ofertantul trebuie să facă dovada capacității de a satisface cerințele proiectului curent (cf. cap. B.3. Conținut), prezentând exemple în cadrul cărora expertul a desfășurat activități similare celor necesare pentru implementarea proiectului ofertat, respectiv:
• redactare și revizuire conținut web (content rewriting), extragerea ideilor esențiale, a cuvintelor-cheie, structurarea informației
• promovare conținut, știri, mesaje, social media.
• realizare plan de content strategy bazat pe obiective, audiențe țintă și tipuri de conținut, stabilirea topicilor și a cuvintelor cheie specifice.
(168) Obs: În procedura de evaluare vor fi luate în considerare toate informațiile furnizate de ofertant. În cazul în care ofertantul omite transmiterea de informații relevante care să permită notarea unuia dintre factorii de evaluare, acesta va fi cotat cu zero puncte.
D. Desfășurarea proiectului
D.1. Planul de proiect
(169) Managementul proiectului, precum și funcțiile cheie în desfășurarea proiectului vor fi asigurate de către specialiști ai ofertantului.
(170) Oferta va include o propunere inițială pentru Planul de proiect și o diagramă Gantt orientativă cu principalele faze ale proiectului, concepute ținând seama de metodologia de implementare Agile (iterativă).
(171) Planul de proiect va include, fără a se limita la acestea, următoarele etape:
α. Definirea caracteristicilor metodologiei de proiect;
β. Analiza sistemelor actuale și stabilirea specificațiilor detaliate aferente fiecărei funcționalități/ secțiuni a sistemului, a intervalelor de realizare și a livrabilelor pentru fiecare dintre acestea;
χ. Realizarea designului;
δ. Dezvoltarea modulelor funcționale;
ε. Translatarea conținutului informațional în noul format
ϕ. Testarea modulelor funcționale pe mediul de test, la BNR și obținerea acceptanței în urma testării sub diferite aspecte: funcționale, interfață, conversie, performanța, securitate;
γ. Pregătirea/ planificarea tranziției;
η. Instalarea pe mediul de producție;
ι. Realizarea conversiei datelor/ fișierelor istorice pe mediul de producție;
φ. Sesiune de parallel run;
κ. Lansarea în producție (go live).
(172) Obs: Pentru scurtarea termenelor, etapele se vor desfășura pe fluxuri multiple, în paralel.
(173) Durata proiectului nu va depăși 12 luni din momentul începerii proiectului, moment consemnat prin Minuta ședinței de kick-off semnată de ofertant și de BNR, și până la recepția finală sau lansarea în producție a sistemului, în funcție de evenimentul care se produce primul.
(174) În cadrul primei etape a Planului de proiect, ofertantul și beneficiarul vor stabili de comun acord termenii Planului de proiect și ai diagramei Gantt, documente care vor fi supuse aprobării beneficiarului.
(175) Ofertantul va oferi servicii de instalare și configurare pentru produsele care vor face parte din soluția propusă. Se vor instala două medii: Mediul de dezvoltare (incl. testare și instruire) și mediul de producție.
(176) Specialiștii implicați din partea prestatorului vor semna Angajamente de confidențialitate, înainte de a le fi prezentate structurile de date și modulele-program ale actualei versiuni a site- ului BNR.
D.2. Metoda de implementare
(177) După alegerea prestatorului și stabilirea echipei de implementare, activitățile proiectului se vor desfășura în conformitate cu o metodologie tip Agile, în condiții agreate de ambele părți, care să asigure controlul fazelor, al activităților, planificarea în timp, alocarea resurselor, verificarea rezultatelor, confirmarea performanțelor așteptate și realizarea documentației specifice modulelor/fazelor respective.
(178) Testarea și înlăturarea erorilor/ completarea și corectarea funcționalităților se vor realiza prin procese iterative specifice metodologiei Agile, care se vor încheia cu semnarea unei Acceptanțe de fază.
(179) Transferul versiunilor succesive de la furnizor la BNR în vederea testării și acceptării se va efectua prin intermediul sistemului de versionare existent la BNR.
(180) Pentru trasarea bug-urilor va fi utilizat de asemenea sistemul BNR (Bugzilla).
D.3. Instruire utilizatori
(181) În scopul exploatării sistemului în condiții optime de performanță se va face transfer de cunoștințe către personalul de specialitate din BNR atât în regim neformalizat, pe tot parcursul proiectului, precum și în sesiuni speciale de training.
(182) Instruirea administratorilor va începe din faza de testare a modulelor funcționale, în cadrul fiecărei etape de implementare.
(183) Sesiunile de instruire se vor desfășura pe bază de prezentări, demonstrații și exemple practice.
(184) Ofertantul va propune durata necesară de instruire astfel încât să fie posibilă aprofundarea tuturor aspectelor relevante.
(185) Instruirile se vor desfășura la sediul BNR, după un program stabilit de comun acord de către ofertant și reprezentanții BNR.
(186) Instruirea va fi organizată în limba română.
D.4. Lansare în producție
(187) După predarea de către ofertant a tuturor modulelor funcționale către beneficiar, se vor desfășura teste de integrare (atât între sistemele proprii, cât și cu celelalte sisteme informatice ale BNR) pe o perioadă de minimum 6 săptămâni.
(188) Testarea finală va consta într-o perioadă de parallel run care va dura minimum 2 săptămâni.
(189) Până la finalizarea sesiunii de parallel run, ofertantul va revizui și va preda BNR documentația tehnică completă, care va include: modelul de procese, modelul de date, diagrama relațiilor între entități, fișierele sursă, fișele de instalare, diagramele UML, instrucțiuni de utilizare pentru modulele dezvoltate și manualul de instalare detaliat.
(190) Finalizarea procesului de lansare în producție va fi marcată prin semnarea Procesului verbal de acceptanță finală.
D.5. Garanție
(191) Ofertantul va asigura garanția pentru sistemul implementat pentru o perioadă de 12 luni de la data Procesului verbal de acceptanță finală.
(192) Ofertantul va preciza în oferta sa termenii SLA (Service Level Agreement): timpii de răspuns, timpii de rezolvare etc., procedura de notificare, precum și informații despre resursele umane alocate pentru susținerea serviciului de garanție.
(193) Cerințele minime pentru SLA:
Clasa de eroare/ urgență | Subiectul sesizării | Timp de răspuns (max.) | Timp de rezolvare (valori maxime) |
Clasa A | Site-ul sau module componente ale acestuia nu funcționează deloc | 1 oră | 2 ore |
Clasa B | Site-ul și module componente ale acestuia funcționează, dar sunt necesare intervenții pentru funcționare la un standard calitativ acceptat de beneficiar | 4 ore | 8 ore |
Clasa C | Site-ul sau modulele componente funcționează, | 1 zi | 5 zile lucrătoare |
Clasa de eroare/ urgență | Subiectul sesizării | Timp de răspuns (max.) | Timp de rezolvare (valori maxime) |
dar necesită intervenție în vederea evitării unei deteriorări a funcționării | lucrătoare | ||
Clasa D | Site-ul sau modulele componente funcționează corespunzător, dar beneficiarul solicită ajustări ce nu necesită funcționalități suplimentare | 2 zile lucrătoare | 5 zile lucrătoare |
(194) În perioada de garanție se vor asigura, de la sediul prestatorului sau on-site, la sediul central al BNR, după caz:
a. Menținerea/ repunerea în stare de bună funcționare a sistemului furnizat, la parametrii agreați (performanță, disponibilitate, integritatea datelor etc.);
b. Monitorizare periodică și preventivă a sistemului;
c. Îmbunătățirea performanțelor tehnice ale sistemului (tuning);
d. Rezolvarea bug-urilor;
e. Adaptarea modulelor și funcționalităților existente la eventuale spețe care nu au fost corect sau complet identificate în timpul analizei și implementării inițiale;
f. Adaptarea aplicației informatice ca urmare a unor eventuale modificări de natură neprevăzută (legislație, noi versiuni software etc).
(195) Ofertantul va preciza condițiile în care poate acorda servicii de asistență tehnică și funcțională post-garanție.
E. Copyright
(196) Ofertantul va pune la dispoziția beneficiarului codul sursă și va face cunoscute standardele și instrumentele de dezvoltare utilizate, astfel încât să permită extinderea sistemului, inclusiv extinderea schimbului de date cu sisteme exterioare, precum și aplicarea upgrade-urilor software.
(197) BNR va reține dreptul de proprietate intelectuală exclusivă asupra tuturor componentelor proiectului WEBSITE-v3 și va deține toate drepturile de proprietate industrială și intelectuală, titlurile și interesele asupra ideilor, conceptelor, know-how-ului, codului sursă, documentației sau tehnicilor create în baza proiectului WEBSITE-v3.
F. Efectuarea plăților în cadrul Contractului
(198) Plata se va face în tranșe, pe parcursul derulării contractului, pe baza documentelor de acceptanță de etapă/ acceptanță finală semnate de furnizor și de către un responsabil de contract sau de înlocuitorul acestuia, desemnați de către BNR, după cum urmează:
Nr. crt . | Fază | Procent din total ofertă |
1. | Analiză și proiectare | Maximum 10 % |
• Definirea caracteristicilor metodologiei de proiect; • Analiza sistemelor actuale și stabilirea specificațiilor detaliate aferente fiecărei funcționalități/ secțiuni a sistemului, a intervalelor de realizare și a livrabilelor pentru fiecare dintre acestea; • Realizarea designului | ||
2 | Dezvoltare | Maximum 30 % |
• Dezvoltarea modulelor funcționale • Translatarea conținutului informațional în noul format | ||
3 | Testare | Maximum 20 % |
• Testarea modulelor funcționale pe mediul de test, la BNR și obținerea acceptanței în urma testării sub diferite aspecte: funcționale, interfață, conversie, performanța, securitate | ||
4 | Tranziție | Maximum 10 % |
• Pregătirea/ planificarea tranziției • Instalarea pe mediul de producție • Realizarea conversiei datelor/ fișierelor istorice pe mediul de producție | ||
5 | Lansare în producție | Minimum 30 % |
• Sesiune de parallel run • Lansarea în producție (go live) |
(199) Nu se vor efectua plați în avans.