Sims Caiet Sarcini V06 Consultare [612280]

1

SISTEM INFORMATIC DE
MANAGEMENT AL ȘCOLARITATII

– SIMS –

CAIET DE SARCINI (document în consultare )

2
Cuprins

1 Obiectivele proiectului ………………………….. ………………………….. ………………………….. ……………….. 4
1.1 Preambul ………………………….. ………………………….. ………………………….. ………………………….. . 4
1.2 Obiectivele SIMS ………………………….. ………………………….. ………………………….. ………………… 6
1.3 Opțiunea de implementare ………………………….. ………………………….. ………………………….. ….. 8
2 Cerințe privind soluția tehnică ………………………….. ………………………….. ………………………….. …….. 9
2.1 Beneficiarii și Scenariile de utilizare ale sistemului ………………………….. ………………………….. 9
2.2 Informații cantitative ………………………….. ………………………….. ………………………….. ………… 13
2.3 Centrele de date ………………………….. ………………………….. ………………………….. ………………. 13
2.4 Abordare la nivel de terminal de utilizare ………………………….. ………………………….. ………… 14
2.5 Principalele categorii de componente ale soluției ………………………….. ………………………….. 16
2.6 Principii generale ………………………….. ………………………….. ………………………….. ……………… 17
3 Descrierea tehnică a proiectului ………………………….. ………………………….. ………………………….. … 20
3.1 Componentele SIMS ………………………….. ………………………….. ………………………….. ………….. 20
3.2 Cerințel e funcționale ale sistemului ………………………….. ………………………….. ………………… 22
3.3 Infrastructură software aplicativă ………………………….. ………………………….. ……………………. 59
3.4 Infrastructură hardware și software de bază ………………………….. ………………………….. …….. 90
3.5 Echipamente IT locale ………………………….. ………………………….. ………………………….. ……… 135
4 Strategia de implementare ………………………….. ………………………….. ………………………….. ……… 139
4.1 Cadrul activităților ………………………….. ………………………….. ………………………….. …………… 139
4.2 Aria de cuprindere ………………………….. ………………………….. ………………………….. ………….. 141

3
4.3 Livrabilele proiectului ………………………….. ………………………….. ………………………….. ………. 142
4.4 Organizare și Metodologie ………………………….. ………………………….. ………………………….. .. 144
5 Garanție, mentenanță și suport ………………………….. ………………………….. ………………………….. .. 147
5.1 Completitudinea soluției ………………………….. ………………………….. ………………………….. ….. 147
5.2 Managementul serviciilor IT – ITSM (IT Service Management) ………………………….. ……….. 148
5.3 Criterii de performanță a serviciului (SLA) ………………………….. ………………………….. ………. 148
5.4 Serviciul de asistență a utilizatorilor ………………………….. ………………………….. ………………. 151
6 Prezentarea ofertei ………………………….. ………………………….. ………………………….. ………………… 152

4
1 Obiectivele proiectului

1.1 Preambul

Ipostaza sistemului educa țional ca fiind cel ce dezvolt ă economia unei țări ascunde substraturi și efecte pe termen lung pe care analizele punctuale nu reu șesc
să le surprind ă decât superficial. Un sistem educa țional lipsit de eficien ță reprezint ă nu doar un consumator de fonduri, ci furnizorul majorit ății punctelor
nevralgice ale viitoarei economii: valori crescute ale șomajului și nevoi de asisten ță social ă, infrac ționalitate, migra ția for țată a valorilor c ătre alte state,
perimarea valorilor morale și culturale, excluziune social ă și în final riscul i zolării economice ca stat.
Ținând cont de aceast ă ipostaz ă a nucleului unei economii func ționale și catalizator al plus -valorii viitoare, diminuarea punctelor sensibile în ceea ce prive ște
absenteismul, violen ța crescut ă în rândul elevilor, abandonul școlar și promovabilitatea scăzută la test ările na ționale nu este doar o oportunitate pentru
actualele politici și strategii, ci reprezint ă un punct de îmbun ătățire semnificativ ă pentru economia viitoare a țării. Sistemul educa țional trece prin modific ări,
preponderent rezultate din suprapunerea resurselor neadaptate la profilul tinerilor din prezent și a modului în care interac ționeaz ă aceștia și părinții/tutorii
legali cu unit ățile școlare la nivel de implicare, responsabilizare și con știentizare a efector produse de absenteism și abandon.
În acest context, i mplementarea unor mecanisme de tipul Catalogului Electronic în mediul educa țional preuniversitar reprezint ă un instrument ce dep ășește
acțiunea de corectare a punctelor sensibile, având capacitatea de a ajuta în toate aspectele propuse de reformele actuale educa ționale înspre un sistem de
învățământ performant, modern și conform standardelor europene.

5

Plecând de la aceast ă realitate și având ambi ția de a dep ăși cadrul îngust al unui Catalog Electronic, Sistemul Informatic de Management al Școlarit ății –
prescurtat SIMS – are în vedere dezvoltarea , implementarea și instrumentalizarea unei platforme na ționale, centralizate, pentru colectarea și gestionarea
informa țiilor referitoare la rezultatele școlare și activitatea școlar ă zilnic ă din sistemul preuniversitar, precum și la evalu ările na ționale, în vederea oferirii unor
elemente de decizie suport pentru gestionarea eficientă și de calitate a sistemului educa țional, în conformitate cu viziunea MEC prin Legea educa ției na ționale
nr. 1/2011, cu modific ările și complet ările ulterioare.

6
Obiectivul principal este reprezentat de cre șterea performan țelor înv ățământului obligatoriu prin diminuarea punctelor nevralgice: absenteism și violen ță,
abandon școlar timpuriu și lipsa promovabilit ății prin eficientizarea utiliz ării resurselor existente și responsabilizarea tuturor participan ților la procesul
educa țional. De asemenea, aplica ția urm ărește implicarea elevilor în procesul de înv ățare prin punerea la di spozi ție a unui mediu online adecvat a șteptărilor
lor.

1.2 Obiectivele SIMS

Solu ția urmărită vizeaz ă implementarea și utilizarea la nivel na țional a unui sistem informatic bazat pe principiile eficien ței, transparen ței și responsabiliz ării
părților implicate în dialog și consultare. Acest sistem informatic va avea func ții de colectare în timp real a datelor din cadrul unit ăților de înv ățământ
preuniversitar concomitent cu transmiterea lor automat ă, agregarea la nivelul unit ății și raportarea c ătre Inspectorat ele Școlare Jude țene și nivelurile centrale
strategice . Astfel, p ornind de la nucleul specific de Catalog Electronic, p latforma va realiza înregistrarea și gestionarea activit ății curente în școală, la nivel
local și național: note, frecven ță, situa ție școlar ă, agregarea și analiza acestor date în scopul prezent ării de indicatori și informa ții statistice care s ă sprijine
factorii de decizie din educa ție în monitorizarea situa ției școlare la nivel local și național, precum și prezentarea detaliat ă a activi tății școlare a elevilor c ătre
părinți. Toate informa țiile actualizate vor fi accesibile factorilor decizionali din cadrul inspectoratelor școlare și Ministerului Educației și Cercetării .
Pe de alt ă parte, s istemul se vrea a fi semnificativ mai mult decât un simplu Catalog în sensul clasic – fiind menit a sprijini activitatea strategic ă și decizional ă,
la nivel na țional, în sistemul de înv ățământ preuniversitar , el va furniza :
 conducerii MEC , prin informa țiile gestionate, respectiv rapoartele și analizele avansate oferite, suport pentru activitatea decizional ă și strategic ă la nivel
național în sistemul de înv ățământ preuniversitar ;
o pune la dispozi ție un set de instrumente necesare colect ării datelor rezultate din activitatea școlar ă;
o oferă suport comparativ pentru fundamentarea politicilor educa ționale prin raportare inclusiv la rezultatele ob ținute la examenele na ționale
(evaluarea online a lucr ărilor scrise la examenele na ționale);
 conducerii unit ăților de înv ățământ, un sistem de semnala re a abandonului școlar, de urm ărire a frecven ței la cursuri și a not ării ritmice, ca suport pentru
interven ție prompt ă;
 profesorilor, o component ă de colectare a datelor aferente catalogului școlar și un set de rapoarte comparative, relevante, care vor av ea la baz ă datele
sintetice din întregul sistem, grupate pe domeniile de interes ale acestuia (discipline înrudite , regiuni);
 elevilor, o component ă de informare on -line a supra progresului școlar propriu, aferent ă Carnetului de note, dar și de contextualiz are relativ ă în cadrul
mai larg, local și național , care va oferi acestora capabilit ăți de a -și urm ări progresul școlar printr -un set de clasamente și pozi ționări (locale, regionale,
naționale) realizate pe discipline, arii curriculare și pe medii semestriale/anuale ;

7
 actorilor principali – profesori/conducere și elevi/p ărinți – un set minimal de func ționalit ăți de comunicare și partajare de informa ții;
 părinților, un set de instrumente pentru monitorizarea activit ăților curente ale elevilor ; sistem ul informatic va furniza informa ții părinților și elevilor
asupra activit ății curente în școală; beneficiarii (p ărinți, elevi) vor avea acces la informa ții în mod securizat și vor fi notifica ți asupra situa țiilor excep ționale
– precum absen țe, devia ții de rezultate școlare, activit ăți speciale;
 o platform ă pentru facilitarea evalu ării lucr ărilor în diverse procesele de Evaluare Na țional ă;
 publicului – un set de rapoarte și analize pe date anonimizate, generice, pe diver și indicatori de interes public lega ți de activitatea din cadrul sistemului
de înv ățământ
 tuturor actorilor din sistem, un set de nomenclatoare centralizate – inclusiv un mecanism centralizat reutilizabil de c ătre ter ți pentru autentificarea
delegat ă a profesorilor, elevilor și dependen ților a cestora – care pot fi folosite pentru dezvoltarea de servicii noi, cu valoare ad ăugat ă.
Interac țiunea cu platforma se va putea face prin multiple canale de acces: Internet/web, acces mobil (smart -phone, tablet ă), e-mail. Astfel, sistemul informatic
va pute a asigura accesul la Catalog și Carnetul de note , în format electronic autentic, fiecărui cadru didactic, elev și părinte, prin intermediul dispozitivelor
mobile și al altor echipamente de calcul portabile sau fixe aflate în dotarea unit ății de înv ățământ sau personale – sistemul va putea suporta inclusiv
dispozitivele proprii ale utilizatorilor finali, implementând mecanisme adecvate de securizare a comunica ției, accesului și datelor stocate local .
Prin informa țiile gestionate și analizele realizate, proiectul va sprijini activitatea decizional ă strategic ă la nivel na țional în sistemul de înv ățământ
preuniversitar. Proiectul va crea un cadru de colaborare și comunicare permanent asupra activit ății și rezultatelor elevilor, la nivel de management educa țional
pe toate palierele (na țional, jude țean și la nivelul unit ăților de înv ățământ). Cooperarea tuturor celor implica ți – cadre didactice, comunitate local ă /
administra ție public ă, beneficiari ai sistemului de înv ățământ / elevi și părinți – va putea det ermina cre șterea productivit ății la nivelul institu ției.
Sistemul va oferi posibilitatea accesului la informa ții pentru analize de etap ă și istorice. Odat ă elaborat un set de indicatori specifici pentru analiza de sistem
a rezultatelor și activit ății elevilor, rela ționa ți cu al ți indicatori existen ți în sistem (indicatorii de activitate și rezultate zilnice corelat cu indicatorii de
promovabilitate la examenele na ționale și ratele de abandon școlar), ace știa vor putea fi implementa ți în cadrul SIMS pen tru monitorizare, reprezentare și
semnalare automat ă. SIMS va oferi toate mecanismele necesare pentru calculul și monitorizarea de indicatori de performan ță specifici, pe baza informa țiilor
din bazele de date complexe gestionate. Prin instrumente specifice de analiz ă avansat ă a datelor, vor fi implementate mecanisme pentru semnalarea și
monitorizarea situa țiilor excep ționale, precum unit ăți de înv ățământ, regiuni sau alte grupuri care necesit ă interven ție, dup ă diverse criterii.
Vor putea fi astfel detecta te, spre exemplu, situa ții excep ționale de absenteism, sau evaluate rezultatele diverselor m ăsuri, pe paliere variate ; de asemenea,
se va putea analiza corelarea activit ății curente în școală (inclusiv absenteism sau rezultate școlare) cu rezultatele elevi lor și unit ăților de înv ățământ la
examenele na ționale.
Sistemul informatic va permite accesul în timp real la date opera ționale la nivelul unit ății de înv ățământ, precum și procesare a unitar ă în timp util a tuturor
datelor statistice, p ăstrând trasabilitatea, siguran ța, flexibilitatea utiliz ării și accesarea din orice loca ție și de pe orice suport electronic. Practic, aplica ția va

8
putea fi accesat ă atât din țară cât și din str ăinătate, de pe calculator, mobil sau tablet ă. În plus, sistemul va de termina cre șterea accesului și particip ării la
educa ție prin dezvoltarea și implementarea unei platforme electronice na ționale pentru gestionarea informa țiilor referitoare la rezultatele școlare și
activitatea școlar ă zilnic ă curent ă din sistemul preuniver sitar.
Sistemul informatic va putea acționa atât individual cât și, pe baza capacit ății sale de interoperabilitate, conjugat cu alte sisteme , cum ar fi ASM, BDNE, SIIIR
sau alte soluții informatice de monitorizare și control, a celor de prevenire și raportare a cazurilor de violen ță sau a sistemelor informatice implementate de
administra țiile locale cu scop social, putând schimba date cu aceste a, acolo unde ele exist ă.
Sistemul Informatic rezultat va trebui s ă includ ă toate elementele aferente compone ntelor sale centrale pentru a putea fi utilizat la nivel na țional. În acela și
timp, proiectul de fa ță va include și resursele necesare dot ării în plan local cu echipamentele necesare sus ținerii proceselor aferente evalu ării na ționale .
Personalul va fi preg ătit pentru implementarea și utilizarea platformei printr -un program de formare dedicat , derulat în paralel cu procesul de înrolare a
școlilor în sistem . Mai departe, acesta va fi sprijinit în activitatea de zi cu zi p rintr-un centru de contact care va r ăspunde în mod operativ solicit ărilor diver șilor
actori, pe canale dedicate.

1.3 Opțiunea de implementare

Documentul de fa ță își propune s ă traseze direc țiile principale pe care trebuie s ă le urmeze un asemenea sistem . Din punct de vedere al arhitecturii general e
a sistemului se va realiza un sistem centralizat, cu interfa ță utilizator implementat ă dual: atât ca interfa ță web, online, cât și ca aplica ție nativă pe
dispozitivul mobil, în regim deconectat (offline ) cu sincronizare .
Deși o astfel de abordare aduce unele provoc ări legate de securizarea accesului la aplica ția local ă și a datelor stocate pe dispozitivul mobil sau sincronizarea
cu datele prelucrate offline, totul în condi țiile unor sisteme centrale care trebuie s ă fie destul de complexe pentru a asigura performan ța și disponibilitatea
serviciului, avantajele acesteia sunt clare:
 Nu necesit ă resurse IT locale
 Simplific ă problemele legate de integrare date, sincronizare și integrare cu ter ți.
 Poate fi utilizat de pe orice dispozitiv.
 SIMS este disponibil și în mod de lucru deconectat, profesorii putând lucra și fără conectivitate sau cu sistemul central c ăzut.
 Încărcarea cotidian ă sistemului central este diminuat ă prin lucru local, pe tablet ă.

9
2 Cerin țe privind solu ția tehnic ă

2.1 Benefic iarii și Scenariile de utilizare ale sistemului

Sistemul va putea avea cel puțin următoarele grupuri de Beneficiari:
A. Cadrele didactice
Asigur ă Operarea sistemului prin activitatea lor de zi cu zi:
 Introduc și valideaz ă datele legate de rezultatele școlare și frecven ța elevilor ;
 Planific ă diverse activit ăți școlare ;
 Particip ă în procese specifice de informare și colaborare cu elevii și părinții (inclusiv elemente legate de comunicarea cu elevii, punere la dispozi ția
acestora a unor resurse de înv ățământ în format electronic, primirea de lucr ări, lansarea de chestionare etc.) ;
 Beneficiaz ă de rapoarte predefinite pentru vizualizarea datelor;
 Finalizeaz ă și certific ă situa țiile școlare la sfâr șit de ciclu de înv ățământ ;
 Particip ă în activit ățile de evaluare a lucr ărilor legate de procesele de Evaluare Na țional ă
 Valideaz ă prin semnare digital ă tranzac țiile efectuate în SIMS .

B. Personalul administrativ din cadrul unit ăților de înv ățământ
Asigur ă Gestiunea sistemului prin activitatea lor organizatoric ă:
 Definesc și gestioneaz ă nomenclatoarele locale: elevi, profesori, p ărinți, structur ă de înv ățământ, orar etc. ;
 Înregistreaz ă în sistem restul actorilor: profesori i, elevii, p ărinții, management ul local ;
 Centralizeaz ă și valideaz ă situa țiile școlare la sfâr șit de ciclu de înv ățământ ;
 Beneficiaz ă de rapoarte predefinite pentru vizualizarea datelor;
 Prelucreaz ă foile matricole și diplomele școlare ;
 Gestioneaz ă activit ățile de colectare a lucr ărilor legate de procesele de Evaluare Na țional ă.

C. Conducerea unit ăților de înv ățământ

10
Asigur ă Management ul proceselor de înv ățământ la nivel de unitate :
 Au acces la rapoarte predefinite și la unelte mai avansate de vizualizare a datelor ;
 Particip ă în procese mai largi de informare și colaborare cu profesorii, elevii și părinții;
 Avizeaz ă situa țiile școlare la sfâr șit de ciclu de înv ățământ ;
 Supervizeaz ă activit ățile de colectare a lucr ărilor legate de procesele de Evaluare Na țional ă și Bacalaureat ;
 Beneficiaz ă de rapoarte predefinite și alte unelte mai avansate de vizualiz are a datelor;
 Evalueaz ă continuu rezultatele activit ății școlare în unitatea proprie, cu posibilitatea de a compara cu diverse situa ții statistice, istorice și/sau legate
de alte unit ăți, pentru a putea lua cele mai bune decizii la nivel tactic .

11

12

D. Personalul de conducere la nivel local și central (inspectorate, minister, UAT)
Asigur ă Managementul proceselor de înv ățământ la nivel local și central:
 Au acces la rapoarte predefinite și la unelte avansate de vizualizare a datelor ;
 Particip ă în procese mai largi de informare și colaborare cu profesorii, managementul, elevii
și părinții;
 Evalueaz ă situa țiile școlare la sfâr șit de ciclu de înv ățământ ;
 Supervizeaz ă activit ățile de colectare și evaluare a lucr ărilor legate de procesele de Evaluare
Național ă și Bacalaureat ;
 Beneficiaz ă de rapoarte predefinite și alte unelte mai avansate de vizualizare a datelor;
 Evalueaz ă continuu rezultatele activit ății școlare în aria proprie de responsabilitate, cu
posibilitatea de a compara cu diverse situa ții statistice, istorice și/sau legate de alte arii
conexe, pentru a putea lua cele mai bune decizii la nivel tactic și strategic .

E. Elevi și Părinți
Urmăresc activitatea școlar ă de zi cu zi:
 Beneficiaz ă de rapoarte p redefinite legate de rezultatele școlare, frecven ța elevilor și
activit ățile planificate – la zi și istoric ;
 Primesc notific ări automate legate de diverse evenimente ;
 Particip ă în procese specifice de informare și colaborare cu profesorii (inclusiv elemente legate
de scutiri și învoiri , solicitarea unor clarific ări sau predarea lucr ărilor în format electronic );
 Iau cuno ștință de situa țiile școlare la sfâr șit de ciclu de înv ățământ ;
 Iau cuno ștință de rezultatele legate de procesele de Evaluare Na țional ă și Bacalaureat ;
 Pot participa în ac țiuni specifice de sondare a opiniei publice și / sau de colectare de date, pe
bază de formulare online .

F. Public
Urmărește activitatea școlar ă la nivel na țional și local, din punct de vedere statistic:
 Beneficiaz ă de rapoarte predefinite pe date statistice legate de rezultatele școlare, frecven ța
elevilor și activit ățile derulate în sistemul de înv ățământ , având acces la un set de rapoarte
predefinite și unelte mai avansate de vizual izare a datelor ;
 Sunt informa ți cu date statistice privind situa țiile școlare la sfâr șitul ciclurilor de înv ățământ și
a proceselor de Evaluare Na țional ă sau Bacalaureat ;
 Poate participa în ac țiuni de sondare a opiniei publice generice, pe baz ă de formular e online .

G. Alte institu ții și organiza ții
Urmăresc activitatea școlar ă de zi cu zi și se pot integra la nivel de date cu serviciile oferite de SIMS:
 Vizualizeaz ă informa țiile specifice legate de rezultatele școlare, frecven ța elevilor și activit ățile
planificate – la zi și istoric ;
 Pot fi implica ți în procese colaborative de decizie ;
 Pot interfa ța sistemele proprii cu serviciile oferite de SIMS .

H. Aplica ții ter țe de Management Local al Școlarit ății (AMLS)

13
Asigur ă derularea proceselor locale în mediu l de lucru propriu:
 Pot și au obliga ția de a interfa ța sistemele proprii cu serviciile specifice oferite de SIMS, legate
de dic ționarele de date, autentificare centralizat ă și înregistrarea datelor legate de prezen ță
și notare
(nu se va oferi un API pentru celelalte func ționalități auxiliare, implementarea acestora
rămânând în responsabilitatea și la latitudinea fiec ărui produc ător în parte)

2.2 Informa ții cantitative

Sistemul dorit va gestiona în cadrul proiectului de fa ță exclusiv activitatea cicluril or de învățământ
primar, gimnazial și liceal . Sistemul trebuie astfel implementat pentru a putea gestiona și celelalte
cicluri (superior , profesional, etc.) prin simpla sa extensie la nivel de infrastructur ă pentru a putea
susține înc ărcarea generat ă de noile grupuri țintă, dar el va fi dimensionat în aceast ă fază pentru a
face fa ță următoarelor caracteristici legate de volumetria grupul ui țintă curent:
 6 250 institu ții de înv ățământ (școli și licee cu personalitate juridic ă)
 180 000 de profesori
 2 250 000 elevi
 2 500 000 conturi pentru apar ținători (accesul p ărinților în sistem va fi posibil numai dup ă
înregistrarea unui cont de informare public ă la secretariatul școlii)
 150 000 alte conturi publice (accesul public în sistem va fi posibil numai dup ă înregi strarea
unui cont de informare public ă la un nivel de inspectorat)
 2 conturi de tip secretariat și 2 conturi de tip management (director și director adjunct – din
cadrul profesorilor) per unitate de înv ățământ
 5000 de conturi manageriale la nivelul inspectoratelor (local) și al ministerului (central)
 Evalu ările na ționale se deruleaz ă în maxim 5000 de școli, cu centralizarea lucr ărilor în 1 00 de
centre de scanare distribuite la nivel na țional
 La fiecare sesiune de evaluare na țional ă particip ă apx. 200 000 elevi , cu o medie de 6 file pe
lucrare scris ă => un necesar de prelucrare a 6000 de file / 12000 pagini duplex pe zi per centr u
de scanare
 110 000 clase de elevi
 Un profesor pred ă în medie la 10 clase în fiecare semestru
 Un elev s tudiaz ă în medie 8 materii per semestru, cu o medie de apx. 5 note per materie
 Un elev poate avea în medie apx. 35 de absen țe pe semestru

2.3 Centrele de date

Solu ția aplicativ ă, ca și cea de infrastructur ă hardware și software care va fi livrat ă trebuie s ă poat ă
func ționa în dou ă centre de date distincte, situate în loca ții care s ă asigure func ționarea și în cazul
unor eveniment deosebite.
Având în vedere c ă nu exist ă amenaj ări satisf ăcătoare, toate echipamentele vor fi livrate în containe re
care s ă fie suficiente func ționării în orice condi ții. Beneficiarul va asigura exclusiv spa țiul fizic de
amplasare a acestor containere și sursa de alimentare cu energie electric ă (postul de transformare –

14
la maxim 50 de metri de loca ție). Va r ămâne în sarcina Furnizorului realizarea oric ărui alt fel de
amenajare pentru amplasarea containerelor , inclusiv eventual betonarea platfo rmei de amplasare și
alimentarea din unul sau dou ă posturi de transformare (al doilea post de transf ormare per loca ție va
fi disponibil mai târziu, pe perioada de derulare a proiectului – sistemul va fi dat în produc ție cu
alimentare doar din posturile de lucru efectiv disponibile, al doilea post fiind de conectat ulterior) .
Totu și, în momentul de fa ță Beneficiarul nu dispune fizi c de loca ție decât pentru primul centru de
date, ce a de a doua fiind în curs de preg ătire – de aceea, pentru început întreaga solu ție va fi amplasat ă
într-o loca ție unic ă. Dar, pentru c ă se dore ște ca solu ția să fie gata din start pentru lucrul în dou ă
centre de date fizice, și pentru a evita confuziile legate de proiectarea solu ției, documentul de fa ță va
discuta peste tot despre dou ă centre de date – Ofertan ții trebuie s ă ofere, s ă proiecteze și să livreze
toate componentele ca și cum ar fi vorba de loca ții diferite. Astfe l, în cadrul centrului de date ini țial se
vor organi za dou ă centre de date logice care trebuie s ă func ționeze fiecare în parte independent,
ignorând faptul c ă sunt temporar colocate, urmând ca pe parcursul perioadei de mentenan ță
Benefici arul s ă solicite Furnizorul ui relocarea unuia dintre acestea în centrul de date aflat în preg ătire
– aceste servicii de relocare trebuie incluse în ofert ă.
Containerele trebuie s ă aibă toate facilit ățile necesare pentru a asigura func ționarea echipamentelor
în regim de lucru normal și condi ții climaterice extreme. Astfel, se vor prevedea capabilit ăți suficiente
de climatizare, stingere, control acces, asigurare a continuit ății aliment ării cu energie electric ă (inclusiv
generator, exclus iv carburantul acestuia) etc. Echipamentele din interiorul containerului trebuie s ă
poată suporta mutarea fizic ă a containerului în alt ă locație fără incidente. Pe perioada contractual ă
Furnizorul este unic responsabil cu orice defec țiune datorat ă unor cau ze de acest tip și va fi obligat s ă
înlocuiasc ă echipamentele defectate și să restabileasc ă în SLA agreat func ționalitatea solu ției pe
costurile proprii.

2.4 Abordare la nivel de terminal de utilizare

Pentru a asigura posibilit atea de a utiliza aplica ția de pe orice fel de dispozitiv (având în vedere și
disponibilitatea preconizat ă de 100% a accesului internet / wi -fi în unit ățile din teritoriu), practic toate
func ționalit ățile acesteia vor fi livrate integral prin intermediul unui browser web.
Totodat ă, pentru a optimiza calitatea experien ței de utilizare a serviciului de pe dispozitive mobile de
tip tablet ă, aplica ția va furniza și un client dedicat pentru Android / iOS / Windows , care va permite
inclusiv executarea unui set de func ționalit ăți în mod d econectat (off -line). Acest client este capabil s ă
înlocuiasc ă Catalogul și Carnetul de Note în format fizic, a șa cum sunt ele utilizate în prezent.
Aplica ția mobil ă SIMS va putea rula pe dispozitive Windows, iOS și Android, inclusiv în mod
deconectat. Aceasta va afi șa utilizatorului doar acele func ționalit ăți care sunt accesibile prin prisma
profilului s ău. De asemenea, va putea vizualiza și modifica numai acele date care sunt accesibile
utilizatorului în cauz ă – spre exemplu, nu va putea înregistra tra nzac ții pe elevi care nu îi sunt aronda ți.
Anumite opera țiuni vor fi dezactivate dac ă nu exist ă conexiune la sistemele centrale, dar asta nu va
trebui s ă-l împiedice pe utilizator s ă-și desf ășoare activitatea – spre exemplu, acesta va putea
înregistra tran zacții SIMS în mod temporar, urmând s ă le certifice definitiv ulterior, odat ă ce se
restabile ște conectivitatea sau de la un terminal web. Este important ca SIMS s ă implementeze în mod
explicit mecanismele necesare rezolv ării tuturor conflictelor de sincro nizare ce pot ap ărea în cazul
lucrului deconectat – în caz de conflict între datele de pe dispozitivul mobil și cele din sistemul central,

15
decizia asupra p ăstrării unei versiuni sau a alteia va apar ține întotdeauna utilizatorului. Spre a asigura
un maxim d e coeren ță a datelor, unele func ționalit ăți pot fi accesibile numai prin clientul dedicat
(dezactivate în interfa ța web) pentru maximiza securitatea aplica ției (acces exclusiv prin client dedicat,
securizat suplimentar) și a elimina complet aceast ă sursă de posibile erori de sincronizare.
Prin prisma utiliz ării principale a terminalului utilizator tip tablet ă, corelat ă cu cerin ța ca unele dintre
func ționalit ăți sa fie disponibile și în mod deconectat, este preferat scenariul Centrat pe profesor – se
prevede utilizarea câte unui dispozitiv pentru fiecare profesor în parte, gestionat complet și
independent de acesta; cataloagele propriu zise rămân virtual e, fiecare profesor putând accesa
fereastra de date care î i este asociat ă.
Criteriu Comentariu
Infrastructura Num ărul de tablete necesar este egal cu num ărul de profesori.
NU este necesar alt tip de infrastructur ă.
Concurenta Fiecare profesor poate lucra simultan de oriunde
Disponibilitate La pierderea sau defectarea unei tablete se pierd tranza cțiile care nu au fost
sincronizate de la ultima conectare la nivelul unei profesor.
Se pot prevedea tablete spare la nivelul școlii sau inspectoratului.
Responsabilitatea Responsabilitate clar ă, la profesor
Securitatea Accesul la echipament poate fi restric ționat la maxim. Securizarea
echipamentului poate fi impus ă și ea, dac ă e cazul

 fiecare profesor va utiliza un dispozitiv propriu , gestionat complet și independent de acesta ;
 permite lucrul simultan, în paralel, al tuturor profesorilor, f ără nici un fel de îngr ădiri;
 cataloagele propriu -zise r ămân în spa țiul virtual din toate punctele de vedere, fiecare profesor
putând accesa fereastra de date care îi este asociat ă, conform drepturilor sale de acces ;
 responsabilitatea asupra dispozitivului este cla ră, fără echivoc; profesorul î și asum ă
răspunderea pentru dispozitivul propriu și în acest fel cre ște durata de via ță a echipamentelor;
 securizarea sistemului și a dispozitivului sunt facilitate de faptul c ă acesta nu este transmisibil ;
 se pot implementa mai facil mecanismele de înregistrare a dispozitivelor, asociere la un
utilizator și trasabilitate ;
 nu necesit ă nici un fel de infrastructur ă suplimentar ă la nivelul școlii;
 pierderea sau defectarea unei tablete afecteaz ă minimal sistemul , la nivelul tranzac țiilor
aferente unui singur profesor, de la ultima sincronizare pân ă în momentul evenimentului; se
pot prevedea tablete de schimb la nivelul școlii sau inspectoratului ;
 poate facilita și în alte privin țe activitatea profesional ă a profe sorului, dincolo de utilizarea
strict ă în cadrul SIMS.
Dispozit ivele vor fi înregistrate în sistem la secretariatul școlii de care apar ține profesorul , maxim
câte unul per profesor . Aplica ția care va fi instalat ă pe dispo zitiv va implementa toate mecanisme le
necesare autentific ării univoce în sisteme și securiz ării datelor p ăstrate local. Aplica ția trebuie s ă
permit ă și utilizarea în comun a unui dispozitiv de mai mul ți profesori – pentru acest caz ea va asigura
identificarea și autentificare profesorului, precum și confiden țialitatea datelor între ace știa. Datele
necesare lucrului deconectat (offline) vor fi p ăstrate pe dispozitiv exclusiv criptat , cu chei care vor
diferi de la un profesor la altul . Ofertantul va descrie în det aliu modalit ățile de securizare incluse în
soluție și care s ă răspund ă la cerin țele de mai sus.

16
2.5 Principalele categorii de componente ale soluției

SIMS implic ă articularea a trei categorii principale de componente:
 Soluții aplicative specifice (vezi cap. 3.1 și 3.2 );
o Servicii func ționale ;
 Nucleul aplicativ de Catalog electronic ;
 Servicii generice de Catalog Electronic ;
 Servicii de administrare local ă a Catalogului Electronic ;
 Management operativ și Urm ărirea activit ății curente ;
 Arhiva electronic ă, incluzând Platforma de suport pentru Evaluarea Na țional ă și
Bacalaureat ;
 Servicii colaborative integrate (mesagerie simpl ă, partajare de documente , fluxuri
operative etc. );
 Servicii avansate de analiz ă și vizualizare a datelor , dedicate nivelurilor super ioare
(inspectorate și minister) ;
o Elemente generice , orizontale, de suport a serviciilor func ționale ;
 Elemente de interfa ță cu utilizatorii ;
 Aplica ții native Windows, iOS și Android ;
 Pagini web ;
 Registre și nomenclatoare ;
 Gestiune utilizatori ;
 Interfe țe aplicative ;

 Infrastructur ă hardware și software ;
o Dotarea cu tehnic ă IT și licen țe software a dou ă centre de date lucrând în mod activ -activ,
cu balansarea înc ărcării între acestea ;
 Infrastructur ă software aplicativ ă (vezi cap. 3.3);
 Livrare de aplica ții (server web, server de aplica ții etc.) ;
 Gestiune de date (baze de date, analiz ă și vizualizare, integrare la nivele
de date etc.) ;
 Middleware (API Gateway, Gestiunea identit ății, Gestiune fluxuri și
arhivare electronic ă, etc.) ;
 Infrastructur ă hardware și software de baz ă (vezi cap. 3.4);
 Echipamente de calcul (servere) și de stocare date ;
 Echipamente de re țea și soluții de securitate ;
 Software de baz ă;
 Solu ții software de gestiune și monitorizare a infrastructurii ;
o Tehnic ă IT local ă (vezi cap. 3.5);
 Dispozit ive mobile (nu se livrează aici) ;
 Scannere și stații de lucru ;

 Servicii conexe
o Servicii de implementare a solu ției informatice integrate la nivel central ;
o Servicii de implementare a solu ției informatice integrate la nivel local ;
o Servicii de instruire ;
o Servicii legate de asigurarea func ționării sistemului , inclusiv call -center .

17

2.6 Principii generale

Serviciile func ționale se vor implementa ca solu ții software configurate, particularizate sau dezvoltate
specific pentru acest proiect. Furnizorul va fi responsabil cu organizarea unui proces de dezvoltare
software accelerat, bazat pe un set de produse existente, care s ă permit ă respectarea termenelor
ambi țioase impuse de c ătre proiect. Acesta va elabora toate documentele necesare procesului de
dezvoltare software și construire a solu ției tehnice extinse , incluzând minimal :
 Specificare a cerin țelor func ționale ;
 Specificare cerin țelor tehnice ;
 Proiecte tehnice ;
 Documenta ția de testare func țional ă;
 Documente de înso țire.
Beneficiarul va fi consultat asupra tuturor detaliilor legate de func ționalit ățile de implementat, va avea
ultimul cuvânt în leg ătură cu acestea și va valida și aproba toate documentele de analiz ă și proiectare
a solu ției informatice , de testare și de înso țire a acesteia .
Întregul cod surs ă legat de serviciile func ționale va deveni proprietatea Beneficiarului, cu excep ția
elementelor de infrastructur ă software men ționate explicit aici î n cap. 3.3 (dac ă Furnizorul utilizeaz ă
alte elemente de software aplicativ în afar ă de acestea, trebui e să transfere Beneficiarului dreptul de
utilizare a acestora inclusiv la nivelul de cod surs ă documentat corespunz ător).
Toate configur ările și particulariz ările produselor software din alte zone vor fi documentate
corespunz ător și vor deveni proprietatea Beneficiarului.
Toate procesele verbale de acceptan ță vor fi condi ționate de existen ța documenta ției tehnice
corespunz ătoare, relevante și aprobate de reprezentan ții tehnici ai Beneficiarului .
Specifica țiile func ționale ini țiale legate de serviciile func ționale se reg ăsesc î n cap. 3.2. Trebuie precizat
că, pentru a sigura securitatea, flexibilitatea și rezilien ța solu ției finale, acestea se vor implementa
obligatoriu pe baza infrastructurii software solicitate în cap. 3.3 – este explicit interzis ă livrarea de
form ă a acestor produse și apoi utilizarea practic ă a altor tehnologii inferioare pentru rularea
diverselor componente func ționale SIMS.
Sistemul trebuie s ă aibă interfa ță utilizator de tip "multi -language" (român ă, englez ă, german ă,
maghiar ă) și să corespund ă specifica țiilor WCAG.

Testarea de performan ță va fi executat ă atât la acceptan țe, cât și periodic (bi -anual), de c ătre un
auditor de ter ță parte. Furnizorul trebuie s ă ofere supor t pentru executarea acestor teste și va trebui
să corecteze toate abat erile care sunt constatate prin aceste teste.

Arhitectura logic ă a serviciilor func ționale și a principalelor elemente de infrastructur ă software
aplicativ ă este reprezentat ă în diagrama urm ătoare:

18

19
Având î n vedere importan ța acestui sistem, și mai ales num ărul foarte mare de utilizatori și scenariile
posibile de utilizare de o varietate foarte mare, aspectele legate de flexibilitatea și disponibilitatea
soluției trebuie stabilite din start, astfel încât ea s ă fie disponibil ă, fără sincope, unui num ăr cât mai
mare de utilizatori:
 acces de pe un num ăr mare de canale
o adecvarea la rezolu ții diverse, î n special adaptarea specific ă de la telefon la tablet ă,
respectiv la ecran de laptop/desktop
o compatibilitate cu browsere web variate (Edge, Chrome și Firefox) ;
o compatibilitate cu dispozitive mobile variate ;
 lucru primar implicit pe terminale mobile cu un anumit grad de securizare ;
 utilizare secundar ă de pe terminale ter țe (BYOD – telefoane, tablete și
desktop/notebook)
 în condi țiile existen ței unei proceduri clare de înrolare sigur ă a termina lelor în
sistem ;
 ergonomie
o interfa ță proiectat ă pentru a fi folosit ă în condi țiile specifice de lucru ale utilizatorilor,
precum în clasa de curs în timpul orelor ;
o adapt ări pentru utilizatorii cu unele dizabilit ăți, cel pu țin pe set ul esen țial de
func ționalit ăți;
 înalta disponibilitate și asigurarea continuit ății
o asigurarea func ționarii neîntrerupte pentru toate componentele de la nivelul central al
soluției;
o posibilitatea de lucru în mod deconectat (off -line) pe un set acoperitor de func ționalit ăți,
cu evitarea problemelor de re -sincronizare
o exploatarea optim ă a resurselor de calcul prin balansarea înc ărcării între ambele centre
de date:
 cel puțin componen tele aferente Nucleului aplicativ de Catalog electronic vor
func ționa simultan în regim de lucru o pera țional, activ -activ, în ambele centre de
date
 celelalte componente pot func ționa fiecare în parte activ -pasiv, dar cele active
trebuie distribuite între cele dou ă centre de date pentru a asigura o înc ărcare
optim ă a resurselor de calcul , inclusiv la nivelul bazei de date
o în caz de eveniment deosebit, oricare dintre cele dou ă centre de date va putea prelua și
încărcarea aferent ă celuilalt centru de date, cu o penalizare inerent ă în performan ță
o soluția va fi în a șa fel construit ă astfel încât, în limitele licen țelor solicitate, Beneficiarul va
putea decide s ă varieze amprenta unor componente în dauna altora, sau chiar s ă opreasc ă
anumite servicii ne -esen țiale pe durate de timp bine definite
 securitate
o non-repudierea tranzac țiilor – semnare digital ă a tuturor tranzac țiilor la surs ă
o autentificarea și autorizarea accesului la informa ții (CBAC – vizibilitate doar asupra datelor
din aria de responsabilitate proprie) și acțiuni (RBAC – se pot apela doar func ționalitățile
specifice rolulu i utilizatorului)
o securitatea datelor – criptare în tranzit (tot) și în repaus (anumite date foarte sensibile,
precum cele legate de autentificare)
o securizare perimetral ă și de sistem

20
3 Descrierea tehnic ă a proiectului

Peste tot acolo unde cerințele de mai departe vor menționa denumiri ale unor produse comerciale,
acestea trebuie luate ca indicație pentru definirea nivelului minimal și obligatoriu al caracteristicilor
funcționale / tehnice solicitate – în toate acestea c azuri se subînțelege mențiunea „sau echivalent” .
Ofertantul poate utiliza în cadrul soluției alte produse decât cele menționate, având obligația de a
demonstra în cadrul ofertei echivalența produsului ofertat cu cel indicat , pe toate atributele
semnificat ive ale acestuia, indiferent dacă acesta au fost sau nu menționate explicit în cadrul
cerințelor.

3.1 Componentele SIMS

Pentru a crea un mod unitar și sigur de colectare a datelor privind notele și absen țele, aceste activit ăți
se vor desf ășura la clas ă, de c ătre profesori, utilizând un dispozitiv mobil (DEV) .
SIMS trebuie proiectat de c ătre ofertant pentru a livra func ționalitatea dorit ă, așa cum este ea
specificat ă în capitolul urm ător. Acesta (ofertantul) este liber s ă aleag ă orice împ ărțire pe modu le /
sub-module pe care o consider ă optim ă, cu condi ția ca sistemul s ă aibă minimal urm ătoarele
componente:

a) Sistemul central de management al școlarității (SCMS)

21
Aceasta este componenta principal ă de gestiune a informa țiilor privind școlaritatea, gestion ând
următoarele date:
 Nomenclatoare
 Rețea școlar ă, forma țiuni de studiu
 Roluri, utilizatori (profesori, elevi)
 Programe școlare (inclusiv competen țele specifice asociate disciplinei)
 Note, absen țe
 Asocierea dispozitivelor mobile la forma țiunile de studiu
 Gestiunea fluxurilor de mesaje și de notific ări
 Comunicarea cu aplica țiile-client și cu celelalte componente ale sistemului
 Interoperabilitatea cu SIIIR (bidirec țional ă, prin API REST și/sau view -uri materializate și triggere,
pentru preluarea nomenclatoarelor oficiale, a registrelor și asocierilor elevilor la clas ă)

b) Interfața web a SCMS (SCMS -WEB)
Aceasta este componenta de interfa ță web care include acele func ționalit ăți care nu sunt disponibile
în aplica țiile cl ient.

c) Aplicația-client de catalog electronic (CATEL)
Aceasta este aplica ția mobil ă ce va fi instalat ă pe dispozitivele mobile de colectare a datelor (DEV).

d) Aplicația-client pentru p ărinți (PARENT -CE)
Este aplica ția mobil ă ce va putea fi instalat ă pe terminale mobile de c ătre p ărinți. Va fi dezvoltat ă
pentru sistemele de operare iOS, Android și Windows. Va dispune de urm ătoarele facilit ăți:
 Vizualizare carnet de note și absen țe
 Vizualizare notific ări
 Acces la statistici (anonime) privind pozi ția copilului/copiilor în ierarhii locale, jude țene și
naționale, pe discipline/competen țe specifice
 Sistem de mesagerie (leg ătură bidirec țional ă cu școala/dirigintele)

e) Componenta de analiz ă și vizualizare date (AVD)
Acesta este componenta care va g ăzdui func ționalit ățile avansate de analiz ă și vizualizare date, dincolo
de nevoile de raportare standard, opera țional ă, care se vor implementa direct în SCMS / SCMS -WEB.

f) Componenta -portal de prezentare a datelor (INFO -CE)
Aceasta este componenta de tip portal care va permite accesarea, de c ătre p ărinți, a acelora și
func ționalit ăți ca cele din aplica ția-client, de c ătre elevi a propriului carnet de note și a mesageriei, dar
și cea care va prezenta, în mod public, statistici și informa ții utile privind școlaritatea l a nivel na țional.

22
g) Componenta de informare și publicare a seturilor de date (PUB -CE)
Acesta este componenta care va preg ăti și expune seturile de date specifice, gestionate de SCMS,
pentru a putea fi preluate în instrumente de tip Business Intelligence, Open Data, calcul indicatori
statistici, precum și de SIIIR.
Func ționalit ățile descrise în capitolul urm ător se vor distribui pe aceste componente.
Componentele aplicative nu trebuie s ă aibă limit ări legate de num ărul de utilizatori, de amprenta /
puterea de calcul utilizat ă, de volumul de date sau num ărul de tranzac ții efectuate, altele decât cele
date de infrastructura software aplicativ ă (cap.3.3).

3.2 Cerin țele func ționale ale sistemului

Pentru implementarea tuturor func ționalit ăților descrise în acest capitol se vor dezvolta, în mod
coerent și integrat, un set de elemente generice, orizontale, de suport a serviciilor func ționale,
cuprinzând:
o Elemente de interfa ță cu utilizatorii ;
 Aplica ții native Windows, iOS / Android (CATEL, PARENT -CE etc.) ;
 Pagini web (SCMS -WEB, PUB -CE, INFO -CE);
o Registre și nomenclatoare ;
o Gestiune utilizatori ;
o Analiz ă și vizualizare date (AVD)
o Interfe țe aplicative
o Alte elemente corespunzând funcționalităților prezentate mai departe
Acestea se vor dezvolta unitar, în sensul c ă se va evita dublarea diverselor componente de
infrastructur ă. Se va minimiza pe cât posibil num ărul de aplica ții native și de grupu ri de pagini web și
interfe țe aplicative care se vor implementa.
În mod obligatoriu, va exista un singur set de registre și nomenclatoare master, care se vor replica în
toate componentele sistemului .
Aceste detalii se vor stabili împreun ă cu Beneficiarul în prima faz ă a proiectului. Toate caracteristicile
funcționale ale soluției , fluxurile și celelalte funcționalități avute în vedere se vor implementa conform
situației exsitente în momentul analizei . Modificările ulterioare survenite în urma unor schimbări
legate de regulamente interne, legislație sau alte din alte cauze vor fi execute conform Procedurii de
Schimbare ( Change Request ).
Codul surs ă al tuturor componentelor care sunt utilizate în cadrul solu ției pentru a livra
func ționalit ățile descri se mai departe va deveni proprietatea Beneficiarului (mai puțin acele
componente considerate de infrastructur ă software, care se încadreaz ă la cap. 3.3 sau 3.4).
Beneficiarul va avea dreptul de a utiliza și modifica acest cod f ără nici un fel de limit ări, inclusiv dreptul
de a -l distribui c ătre ter ți în variant ă open -source.
Se includ aici t oate elementele de tipul modific ări, configur ări, particulariz ări ale solu țiilor software
COTS, precum și orice alte module dezvoltate suplimentar fa ță de cap. 3.3 sau 3.4 pentru a livra
func ționalit ățile necesare sistemului devin și ele proprietatea Beneficiarului la nivel de cod surs ă,
împreun ă cu toat ă documenta ția aferent ă.

23

3.2.1 Nucleul aplicativ de Catalog electronic (SCMS)

La nivel func țional solu ția este compus ă din integrarea mai multor componente func ționale majore
aferente zonei aplicative, respectiv:
1. Componenta servicii generice de Catalog electronic , alcătuită dintr -o serie de module menite s ă
asigure operare propriu -zisă în aplica ție;
2. Componenta de servicii de a dministrare local ă, adresat ă secretariatelor și administratorilor care
lucreaz ă în special la gestionarea bazelor de date și la între ținerea nomenclatoarelor ;
3. Componenta de management operativ și urmărirea activit ății curente ce ofer ă cu preponderen ță
informa ții menite s ă ajute utilizatorii în activitatea de raportare date și analiz ă.

Generic vorbind, soluția îndepline ște un set de func țiile multiple:
 Funcție de management informa țional cu module multiple având grade diferite de securitate:
modul cadr u didactic (profesor, diriginte, educator, înv ățător), modul secretariat, modul
director, modul inspectorat și modul Minister;
o Aceast ă func ție include și posibilitatea de exportare și listare a catalogului școlar
electronic în format fizic și acționare ca arhiv ă cu grad crescut de securitate,
posibilitatea de listare a diplomelor, a foilor matricole, a portofoliul ui elevului sau al
profesorului;
 Funcție de colectare a datelor, agregare și prelucrare statistic ă la nivel global prin care se vor
colecta în mod actualizat date privind: num ăr elevi, reziden ță, sex, apartenen ță religioas ă,
cazuri sociale, vârst ă, ponderea elevilor afla ți în grija altor rude, absenteism, note și ponderea
elevilor în func ție de note, e volu ția rezultatelor, cazurile de violen ță, infrac ționalitate,
abandon, corelarea elevilor și gruparea în func ție de medicul de familie sau poli țistul de
proximitate ș.a.;
o Prelucrarea statistic ă se poate face cu flexibilitate, urmând serii cronologice, ana lize
comparative, analize pondera le de tip pie -chart, histograme;
 Funcție de baz ă informațională necesar ă factorilor decizionali în vederea previzion ării,
planific ării și realiz ării de ac țiuni și politici destinate mediului ed ucațional;
 Funcție de catalog școlar și sistem de informare prin care se pot transmite informa ții despre
situa ția școlar ă a elevilor: note, absen țe, medii, situa ții deosebite, mesaje și observa ții. Aici se
vor prelucra tranzac țiile specifice SIMS: în sensul SIMS, vom definii o tranzacție SIMS ca fiind
orice opera țiune de înregistrare sau schimbare a unei note, a unei absen țe (tranzacții simple)
sau a unui document de tip situa ție școlară (tranzacții complexe) ;
 Funcție de comunicare între to ți participan ții la sistemul educa țional: cadre didactice,
secretariat, conducerea unit ăților de înv ățământ, Inspectorate Școlare Jude țene și Ministerul
Educa ției și Cercetării .

Aceste func ționalit ăți vor fi implementate în cadrul SCMS, respectiv a interfe țelor acestuia (SCMS –
WEB, CATEL, PARENT -CE, INFO -CE).

24
Soluția aplicativă trebuie furnizată la nivel de cod sursă (inclusiv proprietatea intelectuală non –
exclusivă asupra acestuia și dreptul de transfer a acestuia către alte entități guvernamentale), cu
dreptul nelimitate de utilizare (fără nici un fel de limitări cum ar fi numărul de utilizatori, amprenta de
procesare, volumel de date sau tranzacții etc.).

Tranzac țiile SIMS vor fi tratate extrem de atent de c ătre sistem, la cel mai înalt nivel de securitate și
auditare. Fiind vorba despre acte cu u n anumit regim juridic, acestea nu vor face în SIMS obiectul
unora dintre cerin țele GDPR, cum ar fi cele de „uitare” sau „transfer”.
Pe de alt ă parte, din toate celelalte puncte de vedere, sistemul rezultat trebuie sa fie complet în
conformitate cu cerin țele GDPR . Furnizorul va fi ținut responsabil dac ă SIMS va avea probleme GDPR
care țin de modul în care este sistemul implementat.
Componente ce vor fi prezentate în detaliu în capitolele urm ătoare . Setul de func ționalit ăți prezentat
aici este unul minimal, în faza de analiz ă acesta va putea fi completat cu alte capabilit ăți care sunt
caracteristice sistemului de înv ățământ românesc și au sc ăpat în aceast ă prim ă fază exploratorie –
așteptarea Beneficiarului este ca Furnizorul s ă aibă toată experien ța necesar ă pentru a completa din
start lista de mai jos cu acele func ționalit ăți care nu sunt surprinse mai jos.

3.2.1.1 Servicii generice de Catalog Electronic (CATEL, SCMS -WEB)

Aceasta este componenta principal ă ce ofer ă utilizatorilor accesul la informa ția școlar ă structurat ă și
permite profesorilor s ă introduc ă note pentru evalu ări, test ări ini țiale și finale, teze, simul ări, examene
de specialitate; s ă introduc ă și să motiveze absen țe; să introduc ă avertismente. Modulele care
alcătuiesc aceast ă component ă sunt prezentate în continuare:

3.2.1.1.1 Înrolare, Autentificare și Recuperare date de acces

Accesul în aplica ție se face prin generarea de conturi de la structurile superioare c ătre structurile din
subordine. Mai jos sunt detaliate scenariile de înrolare și aute ntificare pentru fiecare tip de utilizator
în parte:
1. Administrator General – este persoana care are acces la toate func ționalit ățile de configurare și
gestionare a bunei func ționări a aplica ției.
Înrolare : Se va introduce Numele și Prenumele în aplica ție împreun ă cu o dat ă de contact
valid ă (num ăr de telefon sau email).
Una din cele dou ă date de contact ale persoanei (num ărul de telefon sau adresa de email) este
introdus și ca nume de utilizator. În paralel, persoana în cauz ă prime ște pe adresa de conta ct
un cod format din 6 cifre (în acest fel se valideaz ă dacă datele de contact sunt introduse
corect).
Administratorul folose ște numele de utilizator împreun ă cu cele 6 cifre pentru a finaliza
crearea contului. Pasul final pentru crearea contului presupune introducerea unei parole
personalizate.

25
Autentificare : Pentru a se autentifica în contul personal, Administratorul introduce numele de
utilizator și parola. În cazul în care acestea sunt introduse corect, utilizatorul va primi un cod
de 6 cifre cu termen de valabilitate (OTP) pe adresa de contact (num ăr de telefon sau email).
Pentru a accesa contul, ca pas final, aplica ția solicit ă introducerea codului din 6 cifre.

2. Reprezentan ți MEC – Administratorul general creeaz ă conturi pentru reprezentan ții MEC .
Înrolare : În baza unui act de identitate Administratorul introduce Numele și Prenumele
Reprezentantului MEC în sec țiunea de creare conturi, împreun ă cu o dat ă de contact valid ă
(num ăr de telefon sau email).
Num ărul de telefon al persoanei (sau adresa de e mail) este introdus și ca nume de utilizator.
În paralel, persoana în cauz ă prime ște pe adresa de contact un cod format din 6 cifre (în acest
fel se valideaz ă dacă datele de contact sunt introduse corect)
Reprezentantul MEC folose ște numele de utilizator î mpreun ă cu codul din cele 6 cifre pentru
a finaliza crearea contului. Pasul final pentru crearea contului presupune introducerea unei
parole personalizate. La primirea datelor de înregistrare, reprezentantul MEC semneaz ă un
proces verbal de predare primire .
Autentificare : Pentru a se autentifica în contul personal, reprezentantul MEC folose ște
numele de utilizator și parola (nou definit ă). În cazul în care acestea sunt introduse corect,
utilizatorul prime ște un cod de 6 cifre cu ter men de valabilitate (OTP) pe adresa de contact
(num ăr de telefon sau email). Pentru a accesa contul, ca ultim pas, aplica ția solicit ă
introducerea codului primit din 6 cifre.

3. Reprezentan ți Inspectorate – Reprezentantul MEC (sau administratorul general) cr eeaz ă conturile
de acces pentru reprezentan ții Inspectoratelor școlare.
Înrolare : În baza unui act de identitate Reprezentantul MEC introduce Numele și Prenumele
Inspectorului în sec țiunea de creare utilizatori, împreun ă cu o dat ă de contact valid ă (num ăr
de telefon sau email).
Num ărul de telefon al persoanei (sau adresa de email) este introdus și ca nume de utilizator.
În paralel, persoana în cauz ă prime ște pe adresa de contact un cod format din 6 cifre (în acest
fel se valideaz ă dacă datele de contact su nt introduse corect).
Inspectorul folose ște numele de utilizator împreun ă cu codul din cele 6 cifre pentru a finaliza
crearea contului. Pasul final pentru crearea contului presupune introducerea unei parole
personalizate. La primirea datelor de înregistrar e, Reprezentantul MEC semneaz ă un proces
verbal de predare primire.
Autentificare : Pentru a se autentifica în contul personal, Inspectorul folose ște numele de
utilizator și parola (nou definit ă). În cazul în care acestea sunt introduse corect, utilizatoru l
prime ște un cod de 6 cifre cu termen de valabilitate (OTP) pe adresa de contact (num ăr de
telefon sau email). Pentru a accesa contul, ca ultim pas, aplica ția solicit ă introducerea codului
primit din 6 cifre.

26
4. Secretari și Directori – Inspectorul creeaz ă conturi pentru Secretarii și Directorii școlii.
Înrolare : În baza unui act de identitate Inspectorul introduce Numele și Prenumele
secretarului (directorului) în sec țiunea de creare conturi, împreun ă cu o dat ă de contact valid ă
(num ăr de telefon sa u email).
Num ărul de telefon al persoanei (sau adresa de email) este introdus și ca nume de utilizator.
În paralel, persoana în cauz ă prime ște pe adresa de contact un cod format din 6 cifre (în acest
fel se valideaz ă dacă datele de contact sunt introduse corect)
Inspectorul folose ște numele de utilizator împreun ă cu codul din cele 6 cifre pentru a finaliza
crearea contului. Pasul final pentru crearea contului presupune introducerea unei parole
personalizate. La primirea Datelor de înregistrare, Secretarul și Directorul semneaz ă un proces
verbal de predare primire.
Autentificare : Pentru a se autentifica în contul personal, Inspectorul folose ște numele de
utilizator și parola (nou definit ă). În cazul în care acestea sunt introduse corect, utilizatorul
prime ște un cod de 6 cifre cu termen de valabilitate (OTP) pe adresa de contact (num ăr de
telefon sau email). Pentru a accesa contul, ca pas final, aplica ția solicit ă introducerea codului
primit din 6 cifre.

5. Cadre Didactice (Profesori, Dirigin ți, Înv ățători etc.) – Secretarul creeaz ă conturi pentru cadrele
didactice din școală în baza unui act de identitate.
Înrolare : Datele profesorilor se pot prelua din SIIIR; ca solu ție secundar ă, datele cadrelor
didactice pot fi importate sau introduse manual de secretari atul școlii. Se preiau datele
personale (nume, prenume). Fiecare cadru didactic poate înregistra un dispozitiv mobil
(tablet ă sau smartphone ). Secretarul va înregistra num ărul de serie și IMEI al dispozitivului
mobil într -o baz ă de date unde îl va asocia l a numele profesorului. Pe dispozitiv se va instala
aplica ția nativ ă prin care cadrul didactic va putea accesa contul personal. Se introduc și alte
date, cum ar fi n umărul de telefon al profesorului și adresa sa de email . Un alias unic este
introdus ca nume de utilizator. Pasul final pentru crearea contului presupune introducerea
unei parole personalizate. La primirea datelor de înregistrare, profesorul semneaz ă un proces
verbal de predare primire.
Fiecare persoan ă cu rol de cadru didactic poate înrola maxim câte un dispozitiv mobil pe care
să func ționeze versiunea mobil ă a aplica ției SIMS sub forma de Catalog electronic . Astfel,
fiecare profesor poate înrola un dispozitiv pe care s ă lucreze în mod deconectat cu apl icația.
Solu ția va permite lucrul mai multor profesori pe acela și dispozitiv (doar pentru cazurile în
care se va utiliza un dispozitiv central situat în cancelarie care va deservi mai mulți profesori ),
în condi ții de securitate avansat ă (autentificare inde pendent ă per profesor, date securizate
distinct etc.).
Similar, se va înrola în sistem dispozitivul care g ăzduie ște generatorul de parole și inițializa
generatorul cu un cod dat de aplica ția mobil ă de catalog (procesul de înrolarea va putea
necesita leg ătura de date cu sistemul central) . Se recomand ă ca dispozitivul care g ăzduie ște
generatorul de parole să fie diferit de cel pe care ruleaz ă aplica ția, dar este acceptabil s ă fie
acela și dacă un singur profesor este înregistrat pe dispozitiv pentru lucrul offline cu aplica ția.

27
Autentificare : Pentru a se autentifica în contul personal, profesorul folose ște numele de
utilizator un cod de minim 6 cifre (OTP) cu termen foarte scurt de valabilitate (1-2 minute)
gene rat pe dispozitivul mobil utilizat pentru OTP (prin intermediul aplica ției generator , după
autentificare cu nume utilizator și PIN ). Pentru a accesa contul, ca ultim pas, aplica ția solicit ă
introducerea codului primit din 6 cifre.
* În cazul în care dispozitivul mobil se deterioreaz ă, profesorul poate înregistra un nou
dispozitiv mobil (la secretariat).
Procesul de autentificare trebuie s ă poat ă func ționa și în mod deconectat ( când unul dintre
cele dou ă dispozitive, sau ambele, nu au conexiune de date – OTP trebuie s ă fie generat și apoi
validat func ție de timp , ID utilizator și caracteristicile dispozitivului , fără acces la sistemele
centrale ). Conturile se vor bloca, atât local cât și central (im ediat ce exist ă conexiune de date),
la un num ăr parametrizabil de utilizator (între limite minime și maxime p arametrizabile
central) de încerc ări eșuate de autentif icare. Deblocarea se va putea face numai de c ătre un
administrator .
Aplica ția local ă va putea avea op țiunea de a utiliza o pre -autentificare suplimentară cu un alt
PIN, pentr u a preveni blocarea contului în cazul în care este accesat ă accidental de un utilizator
care nu este con știent de urm ări (spre exemplu, dac ă este un dispozitiv propriu al profesorului,
la care au acces membrii de familie ai acestuia – contul nu se va bloca , oricâte încerc ări
nereu șite de pre -autentificare se fac). Fiecare profesor poate decide activarea sau
dezactivarea pre -autentific ării din cadrul aplica ției, la orice moment .
Toate detaliile legate de identificare, autentificare, modific ările datelor asociate și tentativele
de autentificare (eșuate sau nu) vor fi scrupulos jurnalizate – cât timp se lucreaz ă offline ,
înregistr ările aferente se vor p ăstra local până la proxima conectare.
Procesul de înrolare și mecanismele de securitate, identificare și autentificare trebuie descrise
pe larg în ofert ă, eviden țiind nivelul înalt de securitate și măsurile luate pentru a împiedica
accesul neautorizat la date și aplica ții.

6. Părinți și Elevi – Dirigintele clasei (sau Secretarul) creeaz ă conturi pentru p ărinți și elevi.
Înrolare : Dirigintele introduce Numele , Prenumele și CNP -ul persoanei în aplica ție, eventual
împreuna cu o dat ă de contact valid ă (num ăr de telefon sau email).
Num ărul de tele fon al persoanei (sau adresa de email) este introdus și ca nume de utilizator.
În paralel, persoana în cauz ă prime ște pe adresa de contact un cod format din 6 cifre (în acest
fel se valideaz ă dacă datele de contact sunt introduse corect).
Părintele ( și elevul) va utiliza numele de utilizator împreun ă cu codul din cele 6 cifre pentru a
finaliza crearea contului. Pasul final pentru crearea contului presupune introducerea unei
parole personalizate.
La primirea Datelor de înregistrare, P ărintele (elevul) va se mna un proces verbal de predare
primire. Se vor lua în considerare și procesele verbale semnate cu semnătură electronică.
Autentificare : Pentru a se autentifica în contul personal, Părintele (elevul) va utiliza numele
de utilizator și parola (nou definită) . În cazul în care acestea sunt introduse corect, utilizatorul
va primi un cod de 6 cifre cu termen de valabilitate (OTP) pe adresa de contact (număr de

28
telefon sau email). Pentru a accesa contul, ca ultim pas, aplicația solicită introducerea codului
primi t din 6 cifre.
Alternativ, elevii și părinții își vor putea activa conturile inițializate de către diriginte sau
secretariat prin autentificare pe baza unui certificat calificat (în baza CNP), dacă sunt în posesia
unui asemenea instrument (certificatele af erente elvilor/părinților nu sunt absolut necesare
și nu sunt în responsabilitatea acestui proiect).
Fiecare persoan ă cu rol de elev sau p ărinte poate înrola maxim câte un dispozitiv mobil pe
care s ă func ționeze versiunea mobil ă a aplica ției SIMS sub forma de Carnet de note .

7. Recuperare date de acces
Datele de acces pot fi recuperate din interfa ța web. În func ție de informa ția care se dore ște a
fi recuperat ă (numele de utilizator sau parola), utilizatorul va trece printr -un proces de
verificare a datelor pe care le cunoa ște (nume de utilizator/email/telefon) și dac ă volumul
acestora este suficient, utilizatorul ob ține acces la interfa ța care îi permite înlocuirea datelor
uitate cu informa ții noi.

Pentru acei utilizatori care folosesc a plica ția client cu utilizare offline se va parcurge inclusiv o etap ă
de înrolare a dispozitivului pe care se va instala aceast ă aplica ție. Componenta de API a Nucleului
aplicativ va fi în a șa fel proiectat ă și implementată ca să nu accepte apeluri API decâ t de pe dispozitive
astfel înrolate, f ăcându -se toate verific ările de rigoare. Nu se vor folosi identificatori statici pentru
autentificare dispozitivului: de exemplu, profilul dispozitivului va fi completat cu date legate de
utilizator, secven ța de apel și data+timpul apelului și criptate, pentru a împiedica interceptarea și
reutilizarea token -ului de autentificare. Pentru simplifica autentificare și elimina problemele de
sincronizare, leg ătura dispozitiv – utilizator va fi una bijectiv ă (1:1).
Odată ce un utilizator a fost înrolat în sistem cu un CNP, î n cazul existenței unei semnături electronice
calificate proprie utilizatorului ea va putea fi folosită pentru accesarea aplicațiilor, respectiv a
modulelor la care posesorul are drepturi de utilizare / vizu alizare , ca alternativă la sistemul propriu
SIMS bazat pe OTP .

3.2.1.1.2 Notarea elevilor. Frecven ța

1. Acordare note
 Profesorii pot acorda note și calificative elevilor reprezentând evalu ări, test ări ini țiale și finale,
teze, simul ări, examene de specialitate, co rigen țe respectând condi țiile impuse de lege;
 Introducerea notei la purtare este condi ționat ă de num ărul absen țelor nemotivate ale
elevului și nu permite acordarea unei note mai mari decât cea posibil ă conform legii.

29
2. Calcul medii
 Pentru clasele primare media semestrial ă pe disciplin ă o reprezint ă calificativul cu frecven ța
cea mai mare acordat în timpul semestrului;
 Pentru clasele gimnaziale și de liceu media semestrial ă pe disciplin ă o reprezint ă media
aritmetic ă a notelor introduse în timpul se mestrului. Media se calculeaz ă cu dou ă zecimale și
se rotunje ște la cel mai apropiat num ăr întreg (la o diferen ță de 50 de sutimi, rotunjirea se
face în favoarea elevului);
 Pentru clasele gimnaziale și de liceu media semestrial ă pe disciplin ă cu tez ă o rep rezint ă media
obținută astfel: media semestrial ă = (3M+T)/4”, unde „M” reprezint ă media la evaluarea
periodic ă, iar „T” reprezint ă nota ob ținută la lucrarea scris ă semestrial ă (teză), nota astfel
obținută se rotunje ște la cel mai apropiat num ăr întreg (la o diferen ță de 50 de sutimi,
rotunjirea se face în favoarea elevului);
 Media general ă semestrial ă reprezint ă mediilor semestriale ob ținute pe fiecare disciplin ă;
 Media general ă anual ă pe disciplin ă o reprezint ă media aritmetic ă, fără rotunjire, a mediilor
obținute pe cele dou ă semestre;
 Media general ă anual ă o reprezint ă media aritmetic ă, fără rotunjire, a mediilor anuale
obținute la toate disciplinele.

3. Acordare absen țe
 Aplica ția permite profesorilor s ă introduc ă doar absen țele elevilor din clasele asoc iate
contului;
 Absen țele pot fi motivate direct de c ătre profesor respectând condi țiile impuse de lege;
 Absen țele pot fi motivate de Diriginte prin introducerea scutirilor sau învoirilor. Toate
absen țele nemotivate din intervalul scutirii se motiveaz ă auto mat în moment ul în care aceasta
este introdus ă în sistem;
 Profesorii pot acorda absen țe mai multor elevi simultan, cu posibilitatea select ării celor viza ți;
 Profesorii pot solicita l ămuriri online p ărinților

4. Alte func ționalități de notare
 Solu ția permite profesorilor s ă adauge observa ții cu privire la cuno ștințele elevilor. De
asemenea , profesorul poate decide vizibilitatea acestora: private (vizibile doar de el) sau
vizibile de diriginte/director;
 Profesorii pot acorda plusuri și minusuri elevilor pentru activitatea la ore. De asemenea ,
profesorul poate configura un anumit num ăr de plusuri/minusuri pentru a fi notificat când
acesta este atins și a putea decide dac ă înlocuie ște plusurile/minusurile cu note;
 Profesorii pot vizualiza mediile generale calculate automat ale elevilor (semestriale și anuale);
 Aplica ția informeaz ă cadrul didactic prin marcarea numelui elevului în diverse culori dac ă
acesta este în situa ție de corigen ță, repeten ție sau dac ă este transferat;
 Cadrul didactic poate vizualiza el evii din clas ă care au cele mai puțin e note și cele mai multe
absen țe. Sistemul menționează data ultimei note;
 Se pot înregistra note pentru mai mul ți elevi simultan, cu posibilitatea select ării celor viza ți;
 Se poate trimite un mesaj tuturor sau anumitor elevi și/sau p ărinților acestora;

30
 Se pot afi șa statistici legate de clasa curent ă. Dirigintele poate vizualiza topul elevilor dup ă
medii și dup ă absen țe. De asemenea acesta este informat cu privire la mediile generale
înregistrate pe semestre și anual;
 Exist ă posibilitatea stabilirii de c ătre profesor a elevilor care trebuie s ă susțină testări ini țiale
și finale;
 Aplica ția permite alegerea elevilor care sus țin tez ă la obiectul curent sau examen specialitate;
 Aplica ția permite alegerea elevilor scuti ți la materia selectat ă (exemple: Educa ție fizic ă,
Religie);
 Se pot adaug ă în aplica ție, de c ătre diriginte, adeverin țe medicale în condi țiile prev ăzute de
lege;
 Aplica ția ofer ă posibilitatea motiv ării automat a abs ențelor în perioada adeverin ței medicale;
 Motiveaz ă absen țele prin introducerea scutirilor și adeverin țelor medicale;
 Motiveaz ă în mod direct absen țele elevilor;
 Dirigintele are posibilitatea de a trimite avertismente elevilor;
 Dirigintele acord ă nota la purtare elevilor s ăi;
 Transmite mesaje cu atașament tuturor colegilor s ăi și poat e răspunde mesajelor primite;
 Înregistreaz ă activit ățile realizate în decursul unui an școlar;
 Profesorii introduc note și absen țe;
 Profesorii transmit rapoarte c ătre conducerea unit ății;
 Profesorii introduc activit ăți școlare și extra școlare;
 Profesorii comunic ă cu p ărinții, elevii, colegii, conducerea și secretariatul școlii;
 Profesorii încarc ă și partajeaz ă fișiere cu elevii și alți profesori.

5. Reguli și Permisiu ni
 Cadrul didactic poate vizualiza în contul lui personal toate clasele la care pred ă;
 Cadrul didactic poate s ă selecteze clasa la care sus ține ora;
 Cadrul didactic poate vizualiza elevii aferen ți clasei în ordine alfabetic ă;
 Cadrul didactic poate acorda o absen ță cu data din ziua respectiv ă sau cu o dat ă precedent ă;
 Cadrul didactic poate vizualiza lista cu toate absen țele unui elev de la materia respectiv ă;
 Cadrul didactic poate motiva o absen ță acordat ă în condi țiile prev ăzute de lege;
 Cadrul didactic poa te să acorde o not ă cu data din ziua respectiv ă sau cu o alta precedent ă;
 Notele introduse pot fi șterse timp de 4 zile, f ără ca profesorul s ă fie nevoit s ă cear ă acordul
directorului. Dup ă aceast ă perioad ă, nota va putea fi ștears ă numai cu acordul direct orului.
Acordul sau dezacordul directorului va fi trimis automat prin mesagerie în contul profesorului
solicitant . Sistemul va procesa automat ștergerea la acord.

3.2.1.1.3 Activit ăți

Prin accesarea op țiunii „Activit ăți (Portofoliul Profesorului )” se pot introduce toate activit ățile
realizate în decursul unui an școlar. Cadrul didactic câ știgă astfel timp prin înc ărcarea acestor
informa ții în format electronic.
Lista de activit ăți ce pot fi introduse de c ătre profesor cuprinde:

31
o Cercuri pedagogice organizate în școală – reuniuni ale profesorilor care predau aceea și materie
sau materii corelate pentru schimburi de idei și practici în metodele didactice aplicate;
o Proiecte europene – parteneriatele strategice la nivel european pun la dispozi ție diverse
proiecte pentru schimbul de experien ță și bune practici;
o Parteneriate – colabor ările cu institu ții și companii din sectorul public sau privat pot fi
concretizat e în diverse proiecte în care pot fi implica ți profesorii cu beneficii de ambele p ărți;
o Voluntariat – implicarea în campanii de voluntariat în scop social, civic organizate prin
intermediul asocia țiilor și funda țiilor non -profit;
o Olimpiade jude țene desf ășurate în școală – modul de organizare al fazelor jude țene a
olimpiadelor școlare cu menționarea datelor important e legate de profesorii coordonatori,
chestiuni administrative, împ ărțirea sarcinilor etc.;
o Alte concursuri organizate și desf ășurate în școală – modul de organizare a diverselor
competi ții cu menționarea datelor importante legate de profesorii coordonatori , chestiuni
administrative, împ ărțirea sarcinilor etc.;
o Rezultate la olimpiade – afișarea punctajelor ob ținute de elevii participan ți la olimpiade,
calificarea la nivelul superior al competi ției;
o Rezultate la alte concursuri – afișarea punctajelor ob ținute de elevii participan ți la olimpiade,
calificarea la nivelul superior al competi ției;
o Activit ăți educative;
o Activit ăți de formare – personalul didactic are obliga ția de a participa la cursuri de formare
profesional ă continu ă cu scopul de a fi mereu la cure nt cu modific ările survenite ulterior
definitiv ării în profesie, pentru fiecare activitate de formare îi revine un punctaj acordat
existând un minimum de acumulat într -un interval de timp;
o Activit ăți metodice în școală – implicarea în diverse activit ăți cu spectru larg ce implic ă
reuniunea pentru discu ții pe teme propuse la nivel de catedre disciplinare, consilii profesorale
și metodice;
o Finan țare / Autofinan țare;
o Tutore practic ă pedagogic ă – notificarea desemn ării ca tutore de practic ă pedagogic ă primind
responsabilitatea de instruire prin mijloace specifice a practicantului;
o Activit ăți CEx – detalii despre organizarea și desf ășurarea activit ăților Centrului De Excelen ță
pe diverse materii implicând dat ă și loc desf ășurare, etape, condi ții înscriere etc.;
o Simpozioane / Sesiuni de comunicare / Conferin țe etc.;
o Membrii în comisii – notificarea desemn ării la apartenen ța în diverse comisii;
o Preg ătirea elevilor pentru concursuri și olimpiade;
o Preg ătirea elevilor pentru examene naționale;
o Activit ăți diverse.

Profesorul poate asocia elevi sau al ți colegi la aceste activit ăți și le poate utiliza ca baz ă pentru
colaborare, mesagerie și partajare documente .
După încărcarea informa țiilor de c ătre profesor, directorul și secretariatul școlii vor putea vizualiza
toate activit ățile extra școlare introduse.
De asemenea , atât profesorul cât și personalul administrativ al școlii pot exporta lista activit ăților în
format PDF sau Excel și o pot lista în cazul în care este necesar.

32

3.2.1.2 Servicii de administrare local ă Catalog Electronic

Atât între ținerea nomenclatoarelor cât și partea de administrare și actualizare a datelor se face local
de către secretariatul fiec ărei unit ăți de înv ățământ.

3.2.1.2.1 Setări generale pentru unitatea de înv ățământ

Secretariatul are acces la o interfa ță special creat ă de unde poate configura diverse func ționalit ăți
globale ce au efect asupra întregii unit ăți de înv ățământ.
În prim ă instan ță informa țiile sunt importate din nomenclatoarele centrale, îns ă secretariatul poate
aduce complet ări sau corect ări în cazul în care informa țiile importate sunt trunchiate.
Informa țiile importate din nomenclatoare pentru configurarea școlii sunt urm ătoarele:
 Informa ții generale : numele unit ății de înv ățământ, tip, clasificare, adres ă, conducere;
 Ani de studiu : define ște anii de studiu și metodele de notare pentru întreaga unitate de
învățământ;
 Catalog electronic : set ări note, absen țe, scutiri, medii, avertismente ș.a.;
 Notific ări: stabile ște orele când se vor trimite notific ări și felul în care vor fi n otifica ți părinții,
elevii, profesorii cu privire la diverse activit ăți în contul personal;
 Module complementare : aceasta component ă permite secretariatului și directorului s ă
configureze individual fiecare modul din cele prezentate mai jos.

3.2.1.2.2 Gestionare u tilizatori

1. Gestionare elevi
 Exist ă posibilitatea ad ăugării elevilor noi în baza de date împreun ă cu datele personale (nume,
prenume, CNP, telefon, dat ă naștere, nr. matricol etc);
 Importul se poate realiza manual sau automat prin înc ărcarea fi șierului Excel ce con ține baza
de date cu elevii școlii;
 Exist ă posibilitatea desc ărcării modelului de fi șier ce con ține câmpurile necesare institu ției
școlare pentru realizarea importului automat de date;
 Fiecare elev va putea fi c ăutat în baza de date dup ă criterii multiple;
 Pentru fiecare elev se va putea genera automat “Fi șa elevului” care con ține informa ții despre
situa ția școlar ă (note, absen țe, medii, scutiri, avertismente , rezultate concursuri și olimpiade),
note la test ările ini țiale, finale și teze, sumar al mediilor semestriale și anuale, sumar al
absen țelor, totalul absen țelor motivate și nemotivate;
 Informa țiile despre elevi pot fi exportate în format PDF sau listate;
 Secretarul poate vizualiza în timp real situa ția școlar ă curent ă a elevului sele ctat: raportul
semestrial și anual, absen țe motivate, nemotivate, mediile generale semestriale și anuale;
 Pentru fiecare elev se poate genera automat ”Foaia matricol ă” în format aprobat de M.E.C. ;

33
 Se pot introduce mediile pentru elevii pleca ți cu burs ă în străinătate. Mediile elevilor vor putea
fi editate la fiecare materie în parte;
 Pentru fiecare elev se pot ad ăuga persoane care au dreptul de a se interesa de situa ția
acestuia (p ărinte, tutore etc.) – datele legate de elevi și asocierea acestora cu profesori, unit ăți
de înv ățământ, tutori etc. vor fi disponibile în mod structurat prin API și prin modulul care
asigur ă login, autentificare și autorizare ter ți.

2. Gestionare cadre didactice
 Pot fi ad ăugate sau importate cadre didactice și personal auxi liar nou în directorul de
utilizatori ;
 Exist ă posibilitatea edit ării cadrelor didactice deja introduse;
 Se pot c ăuta cadrele didactice în baza de date;
 Exist ă posibilitatea desc ărcării modelului de fi șier necesar institu ției școlare pentru realizarea
impor tului automat de cadre didactice;
 Exist ă posibilitatea modific ării informa țiilor personale ale cadrului didactic selectat;
 Cadrele didactice pot fi șterse;
 Secretarul poate vizualiza toate activit ățile extra școlare introduse de un anumit cadru
didactic;
 Există posibilitatea vizualiz ării claselor asociate fiec ărui cadru didactic;
 Se poate realiza importul automat al fi șierului ce con ține baza de date cu cadrele didactice;
 Directorul poate vizualiza portofoliul unui anumit cadru didactic.
 Informa țiile sunt si ncronizate cu componenta de infrastructur ă software Identificare și
Autentificare utilizatori, pentru utilizare in Single Sign -On și servicii ter țe
 Aici este și punctul de ini țiere a înrol ării profesorilor în serviciile de semnare avansat ă și
calificat ă. La expirarea sau compromiterea certificatelor, se vor primi notific ări pentru re –
înrolare sau regenerare certificate

3. Gestionare materii
 Secretarul are posibilitatea de a vizualiza, ad ăuga și edita materiile școlare;
 Se pot marca materiile care sunt op ționale;
 Se pot marca elevii care sunt scuti ți la o anumit ă materie (exemple: Educa ție fizic ă, Religie
etc.).

4. Gestionare transferuri
 Se pot introduce informa țiile legate de transferul elevilor
o de la o școală la alta
o de la o clas ă la alta
o de la o mater ie la alta
o din anul școlar curent în anul școlar urm ător.

34

5. Gestionare clase
 Aceast ă secțiune ofer ă secretarului posibilitatea de a ad ăuga în baza de date clase, de a genera
fișele de elevi pentru to ți elevii clasei, de a exporta catalogul în format clasic ca PDF;
 Pentru fiecare clas ă în parte, se pot asocia materii și profesori și se vor putea edita informa ții
ca: an școlar, liter ă, specializare, an de studiu, tipul clasei;
 Solu ția permite secretarilor s ă ștearg ă clasele introduse din eroare.

3.2.1.2.3 Respon sabilit ăți de administrare date Director și Secretariat

 Opereaz ă informa țiile despre elevi, profesori și materii în nomenclatoare ;
 Realizeaz ă si gestioneaz ă încadr ările;
 Acceseaz ă informa ții școlare din cataloagele tuturor claselor;
 Comunic ă prin mesagerie cu p ărinții, elevii și profesorii;
 Acces la orarul fiec ărei clase și al fiec ăruia dintre profesori;
 Generarea și listarea fi șei matricole;
 Generarea și listarea rapoartelor c ătre Inspectorat și Ministerul Educației și Cercetării ;
 Atât secre tarul cât și directorul au acces la sec țiunea Extra școlare ce permite crearea de
grupuri private sau publice;
 Secretariatul realizeaz ă transferul elevilor între unit ățile de înv ățământ;
 Directorul aprob ă sau respinge modificarea informa țiilor școlare de c ătre profesori;
 Directorul aprob ă ștergerea notelor din sistem conform legii înv ățământului;
 Directorul vede cererile aprobate și respinse de anulare a notelor.

3.2.1.2.4 Nomenclatoare utilizate

Solu ția permite comunicarea bidirec țional ă cu alte sisteme (de exemplu SIIIR) prin intermediul unui
API REST pentru preluarea nomenclatoarelor oficiale, ca de exemplu:
 Materiile aferente fiec ărei unit ăți de înv ățământ;
 Cadrele didactice asignate școlii;
 Ani școlari;
 Semestre;
 Perioadele de vacan ță;
 Profilul unit ății de înv ățământ ș.a.
În general secretariatul opereaz ă următoarele seturi de date, dar f ără a se rezuma doar la acestea:
1. Elevi
Pot fi ad ăugați elevi în baza de date împreun ă cu informa țiile relevante. Informa țiile despre elevi sunt:
 Nume / Prenume / Ini țiala tat ălui;
 Cod Numeric Personal (sistemul asigur ă validitatea lui) ;
 Data na șterii;

35
 Sex;
 Locul na șterii;
 Adresa de re ședin ță și tipul acesteia (urban/rural) ;
 Adresa la care locuie ște;
 Telefon / Email ;
 Observa ții;
 Limba matern ă;
 Limbi moderne studiate ;
 Specializ ări anterioare ;
 Informa ții despre medicul de familie ;
 Informa ții despre agentul de proximitate ;
 Num ăr matricol ;
 Alte informa ții în scop statistic: dac ă locuie ște cu p ărinții sau nu, dac ă stă în gazd ă, situa ția
familial ă, venit p e membru de familie ;
 Pentru fiecare elev pot fi introdu și unul sau mai mul ți părinți cu urm ătoarele informa ții:
o Tip (mama, tata, tutore legal, ruda etc.) ;
o Nume / Prenume ;
o CNP ;
o Profesie / Func ție / Loc de munc ă;
o Domiciliul de re ședin ță;
o Domiciliul flotant ;
o Telefon / Email ;
 Pentru fiecare elev se poate genera “Fi șa elevului” ;
o fișa con ține toat ă situa ția școlar ă (note, absen țe, medii, scutiri, avertismente );
o conține rezultatele la diverse concursuri și olimpiade ;
o fișa poate fi exportat ă ca PDF sau listat ă;
 Pentru fiecare elev se poate genera “Foaia matricol ă”;
o foaia matricol ă este realizat ă în formatul aprobat de MEC ;
o foaia matricola poate fi exportat ă în PDF sau listat ă;
o Pentru fiecare elev se pot introduce materiile studiate și mediile ob ținute înainte de
transferul la o alt ă școală;
o Elevii pot fi șterși dar exist ă posibilitatea recuper ării lor în cazul unei ștergeri
accidentale .

2. Clase
Pot fi ad ăugate în baza de date clase împreun ă cu alte informa ții relevante, precum:
o An școlar ;
o An de studiu ;
o Litera ;
o Specializare ;
o Tip (cursuri de zi sau seral) ;
La fiecare clas ă exist ă posibilitatea export ării catalogului în format electronic ca PDF , asemenea celui
clasic.
La fiecare clas ă se poate configura orarul

36
La fiecare clas ă se pot asocia materii și profesorii ca re le predau :
 materie poate avea mai mul ți profesori ;
 Clasa poate fi împ ărțită pe grupe ce studiaz ă materii diferite sau cu profesori diferi ți;
 Se poate selecta dac ă o materie este luat ă în calcul la calcularea mediei generale ;

3. Materii
Pot fi ad ăugate materiile împreun ă cu alte informa ții relevante:
 se poate selecta dac ă materia este op țional ă sau nu ;
 se poate selecta dac ă elevii pot fi scuti ți la acea materie sau nu .

4. Cadre didactice și personal auxiliar
Pot fi ad ăugate cadrele didactice cât și pers onalul auxiliar împreun ă cu alte informa ții relevante:
o Nume / Prenume ;
o CNP ;
o Data na șterii;
o Email / Telefon ;
o Func ție.
Cadrele didactice pot introduce în sistem activit ățile extra școlare pe care le desf ășoară:
o Cercuri pedagogice organizate în școală;
o Proiect e europene ;
o Parteneriate ;
o Voluntariat ;
o Olimpiade jude țene desf ășurate în școală;
o Alte concursuri organizate și desf ășurate în școală;
o Rezultate la olimpiade ;
o Rezultate la alte concursuri ;
o Activit ăți educative ;
o Activit ăți de formare ;
o Activit ăți metodice în școală;
o Finan țare / Autofinan țare;
o Tutore practic ă pedagogic ă;
o Activit ăți CEx ;
o Simpozioane / Sesiuni de comunicare / Conferin țe etc. ;
o Membri în comisii ;
o Preg ătirea elevilor pentru concursuri și olimpiade ;
o Preg ătirea elevilor pentru examene naționale ;
o Activit ăți diverse .
Pot fi vizualizate clasele și materiile la care un profesor este asociat
Poate fi vizualizat ă lista de autentific ări pentru fiecare cadru didactic

37
5. Transfer elevi
Între școli: se pot introduce informa țiile legate de transferul elevilor de la o școală la alta
o Tip transfer (plecat/venit) ;
o Nume școală sursă;
o Nume școală destina ție;
o Num ăr cerere de transfer ;
o Dată transfer .
Între clase : elevii pot fi transfera ți de la o clas ă la alta în timpul unui an școlar
o Informa țiile la materiile comune din clasa surs ă se vor copia în clasa de destina ție;
o Informa țiile la materiile care nu se mai predau la clasa destina ție se vor șterge ;
o Media general ă la o materie predat ă exclusiv la clasa de destina ție va fi aceea și cu cea ob ținută
pe semestrul din timpul transferului ;
Între materii : elevii pot fi transfera ți de la o materie la alta în interiorul aceleia și clase
Între ani școlari : elevii pot fi transfera ți în anul școlar urm ător la o clas ă cu aceia și liter ă sau alta

3.2.1.2.5 Orar

 După introducerea cadrelor didactice, a claselor de curs, a intervalelor orare și a unor preferin țe
de generare modulul va genera o versiune de orar care va putea fi modificat ă și manual dup ă
diverse criterii, în func ție de nevoi.
 Orarul generat va fi afișat atât profesorilor cât și părinților și elevilor. Secretariatul sau persoana
desemnat ă va putea modifica orarul în orice moment .
 Fiecare reprezentant de școală responsabil cu setarea orarului poate seta intervalul orar în care
fiecare ciclu de studiu î și desf ășoară activitatea. În func ție de anii de studiu, intervalele orare pot
fi diferite.
 Orarul cuprinde urm ătoarele date de intrare:
o listă de profesori;
o listă de clase și elevii din clas ă;
o listă de săli de clas ă și asocierea cu o clas ă de elevi;
o listă de laboratoare asociate cu materii;
o listă de materii;
o intervale orare;
o asocierea dintre clas ă, materie și profesori;
 se pot preciza num ărul de ore s ăptămânale și numărul de ore efectuate în laboratoare;
 o asociere se poate face și pe o subgrup ă a elevilor dintr -o clas ă;
 mai mul ți profesori pot preda aceea și materie la o clas ă/grup ă;
 elevii pot avea mai multe materii predate de profesori diferi ți în aceea și oră dacă sunt împ ărțiți pe
grupe;
 elevii pot avea mai multe materii predate de profesori diferi ți în acela și interval orar al acelea și
zile dar diferit în func ție de tipul s ăptămânii exemplu: s ăptămân ă pară sau impar ă;
 asocierea claselor pe schimburi;
 se vor speci fica pref erințele de generare a orarului;

38
 în ceea ce prive ște regulile de generare a orarului, fiecare regul ă are o importan ță între 1 și 100
unde 100 înseamn ă că un orar care nu o respect ă este considerat invalid iar 1 reprezint ă o regul ă
foarte puțin important ă;
 Pentru regulile cu o importan ță mai mic ă de 100, aplica ția calculeaz ă procentul de respectare a
regulilor folosind o formul ă care s ă țină cont de importan ța acestora. Aplica ția prime ște ca dat ă
de intrare un procent minim de respectare a regulilor pentru ca un orar s ă fie considerat valid.
Arhitectura aplica ției permite ad ăugarea cu u șurință de noi reguli.
Exemple de reguli cu importan ță 100:
o nu se pot preda mai multe materii în aceea și sală de clasă în acela și timp;
o elevii nu pot avea ferestre;
o o clas ă nu poate avea mai mult de 7 ore de curs pe zi.
Exemple de reguli cu importan ță mai mic ă de 100:
o un profesor dore ște sa aib ă ore doar în anumite zile;
o num ărul maxim de ore pe zi la o anumit ă materie la o clas ă să nu fie mai mult de dou ă;
o anumite materii se doresc a fi predate în anumite zile.
 Aplica ția accept ă un orar par țial de la care s ă porneasc ă generarea, pe care nu îl va modifica.
Totodat ă, aplica ția genereaz ă o variant ă de orar care re spect ă optim regulile introduse. În cazul în
care una sau mai multe reguli nu au putut fi respectate aplica ția va afi șa motivele pentru fiecare
regul ă în parte (exemplu: nu sunt suficiente s ăli de clas ă, nu sunt suficiente laboratoare etc.)

3.2.1.2.6 Anuar

 Modulul oferă posibilitatea de a înc ărca propria imagine în anuarul școlii, atât profesorii cât și
elevii pot înc ărca o fotografie pentru anuarul clasei. Este permis ă generarea anuarului pentru clasa
proprie sau pent ru toat ă unitatea de înv ățământ;
 Atât profesori i cât și elevii pot vizualiza anuarul clasei lor și al tuturor claselor din școală existând
posibilitatea afi șării în func ție de anul școlar (în curs sau anteriori);
 Modulul ofer ă posibilitatea desc ărcării anuarului (pe clasa curent ă, pentru colegii din an sau
pentru toate clasele) în format PDF, putând alege formatul în care anuarul se dore ște a fi
desc ărcat: A3, A4, A5. De asemenea , se poate selecta șablonul dorit, împreun ă cu stilul acestuia.

3.2.1.2.7 Administratori aplica ție

 Administreaz ă lista inspectoratelor jude țene;
 Administreaz ă lista unit ăților școlare în platform ă;
 Define ște rolurile și drepturile de acces pentru personalul din administrarea central ă;
 Define ște rolurile și drepturile de acces pentru personalul din inspectoratele școlare jude țene;
 Define ște rolurile și drepturile de acces pentru personalul din unit ățile școlare;
 Monitorizeaz ă în timp real și statistic gradul de utilizare a platformei;
 Monitorizeaz ă în timp real, performan ța tehnic ă a platformei;

39
 Monitorizeaz ă diverse echipamente hardware necesare func ționării platformei prin vizualizarea
stării acestuia (func țional, nefunc țional) și gradul de înc ărcare (utilizare CPU, RAM, spa țiu de
stocare etc);
 Realizeaz ă, backup -uri complete cu termen de p ăstrare permanent ;
 Restaureaz ă din backup -uri datele în cazul evenimente lor neprev ăzute.

3.2.1.3 Management operativ și urmărirea activit ății curente

Aplica ția pune la dispozi ție o serie de func ționalit ăți ce permit urm ărirea activit ății curente. Acestea
presupun accesul la datel e proprii, a utilizatorilor implica ți dar și acces la date agregate pentru
entit ățile din structurile superioare (Director, Inspectorate, Minister, Prim ării etc).

3.2.1.3.1 Statistici și date agregate

Minister
 Vizualizeaz ă lista Inspectoratelor Școlare Jude țene aflate în subordine;
 Pentru fiecare inspectorat se pot vizualiza unit ățile de înv ățământ cu num ărul total de elevi
înscri și;
 Pentru fiecare unitate de înv ățământ se poate vizualiza media general ă calculat ă în timp real;
 Vizualizeaz ă statistici pe inspector ate, unit ăți de înv ățământ, clase, elevi.

Inspectorate
 Vizualizeaz ă lista gr ădinițelor, școlilor și liceelor aflate în subordine;
 Pentru fiecare unitate de înv ățământ vizualizeaz ă num ărul total de elevi înscri și și media
general ă calculat ă în timp real;
 Vizualizeaz ă statistici pe unit ăți de înv ățământ, clase, elevi, medii.

Pentru a maximiza performan ța globală și funcționalitatea oferit ă, vizualizarea datelor aferente
nivelurilor superioare școlii, respectiv Minister și Inspectorat , va fi implementată în afara Nucleului
aplicativ de Catalog electronic, respectiv utilizând componente din zona de Analiz ă avansată și
vizualizare de date, pe baza unui datawarehouse distinct de bazele de date de produc ție.

Director și Secretariat
 Vizualizeaz ă clasamentul general al elevilor;
 Vizualizeaz ă informa ții școlare din cataloagele tuturor claselor;
 Consult ă rapoartele de activitate ale cadrelor didactice;
 Acces la rapoarte statistice (generale, specifice și individuale);
 Acceseaz ă statistici privind elevi, bursieri, șefi de promo ție;
 Acces la orarul fiec ărei clase și al fiec ăruia dintre profesori;

40
 Generarea și listarea rapoartelor c ătre Inspectorat și Ministerul Educației și Cercetării ;
 Fiecare elev poate fi c ăutat în baza de date dup ă criterii multiple;
 Pentru fiecare elev se poate genera automat “Fi șa elevului” care con ține informa ții despre:
situa ția școlar ă (note, absen țe, medii, scutiri, avertismente , rezultate concursuri și olimpiade),
note la test ările ini țiale, finale și teze, sumar al mediilor semestrial e și anuale, sumar al
absen țelor, totalul absen țelor motivate și nemotivate;
 Informa țiile despre elevi pot fi exportate în format PDF sau listate;
 Directorul poate vizualiza în timp real situa ția școlar ă curent ă a elevului selectat: raportul
semestrial și anual, absen țe motivate, nemotivate, mediile generale semestriale și anuale;

Anulare note
 Directorul prime ște cererile de a aproba ștergerea notelor din sistem conform legii
învățământului;
 Directorul aprob ă sau nu cererile de ștergere a notelor din siste m respectând legisla ția în
vigoare;
 Directorul are acces la istoricul cererilor de anulare a notelor și statusul acestora aprobate sau
respinse.

Diriginte / Înv ățător
 Vizualizeaz ă încadrarea anului școlar în curs;
 Vizualizeaz ă elevii în ordine alfabetic ă;
 Vizualizeaz ă notele elevilor la toate materiile;
 Vizualizeaz ă absen țele elevilor la toate materiile;
 Vizualizeaz ă adeverin țele medicale înregistrare în sistem pentru propria clas ă;
 Vizualizeaz ă lista scutirilor înregistrate;
 Vizualizeaz ă media clasei;
 Vizualizeaz ă mediile elevilor calculate automat;
 Acceseaz ă istoricul pentru a vedea în ce dat ă și la ce or ă s-au acordat anumite note sau
absen țe. De asemenea , sistemul permite vizualizarea datei și orei când absen țele au fost
motivate, respectiv șterse.

Profesori
 Vizualizeaz ă încadrarea anului școlar în curs;
 Vizualizeaz ă notele/calificativele elevilor;
 Vizualizeaz ă absen țele elevilor;
 Țin eviden ța activit ăților școlare și extra școlare;
 Semnalizeaz ă elevi cu probleme de corigen ță, num ăr de note insuficient sau medii
neîncheiate;
 Genereaz ă statistici legate de performan ța clasei;
 Realizeaz ă clasamente în func ție de note, medii, num ăr de absen țe;

41
Elevi si părinți
Elevii și părinții au la dispozi ție dou ă componente ce le ofer ă acces la Carnetul ele ctronic de elev:
Componenta de portal web și componenta aplica ție mobil ă Carnet de Note . Ambele le ofer ă acces la
informa ții despre situa ția școlar ă, mai exact la urm ătoarele func ționalit ăți:
 Vizualizare note (oral, test, tez ă, simulare, proiect) ob ținute la fiecare materie;
 Vizualizare medie calculat ă în timp real;
 Vizualizare probabilitate de ascultare la o anumit ă materie;
 Vizualizare note pe ani școlari anteriori;
 Acces la situa ția absen țelor motivate și nemotivate;
 Acces la scutirile introduse de diriginte;
 Posibilitatea de a genera și lista fi șa cu situa ția școlar ă;
 Vizualizarea scutirilor, a învoirilor și a adeverin țelor medicale;
 Vizualizarea conduitei și a punctajului aferent.

Acțiuni clase
 Cadrul didactic poate vizualiza în contul lui person al toate clasele la care pred ă;
 Cadrul didactic poate selecta clasa la care sus ține ora;
 Cadrul didactic poate vizualiza elevii aferen ți clasei în ordine alfabetic ă;
 Cadrul didactic poate acorda o absen ță cu data din ziua respectiv ă sau cu o dat ă precedent ă;
 Cadrul didactic poate vizualiza lista cu toate absen țele unui elev de la materia respectiv ă;
 Cadrul didactic poate motiva o absen ță;
 Cadrul didactic poate s ă acorde o not ă cu data din ziua respectiv ă sau cu o alta precedent ă;
 Notele introduse pot fi șterse timp de 4 zile, f ără ca profesorul s ă fie nevoit s ă ceara acordul
directorului. Dup ă aceast ă perioad ă, nota poate fi ștears ă numai cu acordul directorului.
Acordul sau dezacordul directorului este trimis automat prin mesagerie în contul profesorului
solicitant;
 Cadrul didactic poate introduce notele ob ținute la tez ă, test ări ini țiale, test ări finale sau
examene de specialitate.

Acțiuni elevi
 Vizualizarea informa țiilor generale despre elevi: nume, prenume, num ăr matricol, adres ă, telefon
părinți etc.
 Acordare note :
o Profesorii pot acorda note și calificative elevilor în condi țiile impuse de lege;
o Mediile se calculeaz ă automat con form legii înv ățământului în vigoare;
o Pentru introducerea notei la purtare, aplica ția ține cont de num ărul absen țelor
nemotivate ale elevului și nu va permite acordarea unei note mai mari decât cea posibil ă
conform legii.
 Acordare absen țe:
o Profesorii pot introduce absen țele elevilor din clasa selectat ă;
o Absen țele pot fi motivate respectând condi țiile impuse de lege;

42
 Profesorii pot ad ăuga observa ții cu privire la cuno ștințele elevilor. De asemenea , pot decide
vizibilitatea acestora private sau vizibile de diriginte/director;
 Profesorii pot acorda plusuri și minusuri elevilor pentru activitatea la ore. Aplica ția notific ă
profesorul când un anumit num ăr de plusuri/minusuri este atins și permite profesorului s ă decid ă
dacă va înlocui plusurile/minusurile cu no te;
 Profesorii pot vizualiza mediile generale calculate automat ale elevilor (semestriale și anuale);
 Aplica ția informeaz ă cadrul didactic prin marcarea numelui elevului în diverse culori de aflarea
acestuia în stare de corigen ță, medie nerotunjit ă sau tra nsfer;
 Cadrul didactic vizualizeaz ă elevii din clas ă care au cele mai puțin e note și cele mai multe absen țe.
Sistemul Menționează data ultimei ascult ări;
 Se pot înregistra note pentru mai mul ți elevi simultan, cu posibilitatea select ării celor viza ți;
 Se p ot acorda absen țe mai multor elevi simultan, cu posibilitatea select ării celor viza ți;
 Se poate trimite un mesaj tuturor sau anumitor elevi și/sau p ărinților acestora;
 Se afi șează statistici legate de clasa curent ă. Dirigintele poate vizualiza topul elevil or dup ă medii
și dup ă absen țe. De asemenea acesta este informat cu privire la mediile generale înregistrate pe
semestre și anual;
 Exist ă posibilitatea stabilirii de c ătre profesor a elevilor care vor sus ține test ări ini țiale și finale;
 Aplica ția permite alegerea elevilor care vor sus ține teza la obiectul curent sau examen de
specialitate;
 Aplica ția permite alegerea elevilor scuti ți la materia selectat ă (exemplu: Educa ție fizic ă, Religie).

3.2.1.3.2 Accesul la informa ții prin componenta de aplica ție mobil ă (PARENT -CE)

 Aplica ția nativ ă pentru terminale (telefoane și tablete) ruleaz ă pe sistemele de operare iOS,
Android, Windows. Aplica ția poate fi instalat ă de elevi și părinți și con ține urm ătoarele
func ționalit ăți:
 Vizualizare situa ție școlar ă (note, absen țe, observa ții, scutiri, conduit ă, teme);
 Notific ări de tip push;
 Clasamente generale (anonime) privind pozi ția copilului în ierarhii pe institu ție de înv ățământ,
locale, jude țene și naționale sau pe discipline;
 Clasamente de distribu ție a elevilor dup ă intervalele în care se încadreaz ă mediile;
 Clasamente individuale dup ă num ărul de absen țe nemotivate;
 Sistem de mesagerie intern ă (legătură bidirec țional ă cu profesorii, elevii din școală, conducerea
școlii sau structurile superioare);
 Partajare fi șiere;
 Vizualizare Orar;
 Modul de Teme (primire din partea profesorului, efectuare și primire not ă/calificativ/plus sau
minus);
 Acces modul de activit ăți Extra școlare;
 Acces modul Teste și Chestionare;
 Vizualizare Anuar;
 Acces modul Anun țuri și Nout ăți.

43
3.2.1.4 Alte funcționalități

3.2.1.4.1 Preferin țe Utilizatori

Toți utilizatorii pot modifica din contul personal urm ătoarele date:
o Parola
o Adresa de email / Num ărul de telefon
o Preferin țe în privin ța notific ărilor pe email
o Poza de profil
o Felul în care primesc nout ăți în cont

3.2.1.4.2 Notific ări

Aplica ția trimite emailuri pentru a notifica utilizatorii cu privire la urm ătoarele evenimente :
o Modificarea situa ției școlare a elevului
o Absen țe
o Autentific ări nereu șite
o Schimb ări de parol ă.

3.2.1.4.3 Interfa ță Utilizator

Traducere
 Sistemul este conceput s ă suporte traducerea în mai multe limbi;
 Sistemul permite introducerea și modificarea traducerilor de c ătre personal non tehnic.
 Sistemul este gata configurat pentru limbile uzuale în sistemul de înv ățământ
Preferințe
 Posibilitatea de a completa pagina de profil ce cuprinde: nume utilizator, imagine personal ă, date
de contact (e -mail, num ăr de telefon), sex, data na șterii, localizare, semn ătură electronic ă
mesagerie;
 Posibilitate de a modifica felul în care utilizatorul prime ște notific ări (accept ul sau refuzul a primi
știri și nout ăți despre educa ție, informa ții despre concursuri, informa ții despre diverse activit ăți
extra școlare, mesaje publicitare);
 Posibilitatea de a schimba parola contului;
 Posibilitatea de a uni dou ă sau mai multe conturi de utilizator în cazul când o persoan ă este, de
exemplu, profesor și părinte.

44
3.2.1.4.4 Modul Rapoarte

Modulul Rapoarte este componenta care preg ătește și expune seturile de date specifice, pentru a
putea fi preluate în instrument ele de raportare. Modulul poate publica automat datele deschise în
portalul Open Data guvernamental și poate calcula indicatorii statistici.
Rapoartele standard sunt disponibile pentru utilizatorii de tip MEC , pentru utilizatorii de tip ISJ/ISMB,
pentru ut ilizatorii de tip director/secretar și pentru utilizatorii de tip elev/p ărinte.
Utilizatorii de tip MEC au la dispozi ție:
o Rapoarte de ierarhizare a unit ăților de înv ățământ dup ă anumi ți indicatori, pe
localit ăți/jude țe;
o Rapoarte privind gradul de utilizare , la nivel de utilizator/forma țiune de
studiu/localitate/jude ț;
o Rapoarte de avertizare timpurie privind gradul ridicat de absenteism, pe unit ăți/regiuni
SIRUTA Nivel 1, Nivel 2 și/sau Nivel 3 (ca posibile focare de epidemii) cu vizualizare
grafic ă/hart ă interactiv ă;
o Rapoarte comparative cu mediile la evalu ările 2/4/6 și Evaluare Na țional ă, Bacalaureat.

Utilizatorii de tip ISJ/ISMB au la dispozi ție:
o Rapoarte privind notarea ritmic ă;
o Rapoarte privind frecven ța la ore;
o Rapoarte de pondere a încheierii situ ației școlare;
o Rapoarte de ierarhizare a unit ăților de înv ățământ dup ă anumi ți indicatori;
o Rapoarte privind gradul de utilizare, la nivel de utilizator/forma țiune de studiu;
o Rapoarte de avertizare timpurie privind gradul ridicat de absenteism, pe unit ăți/regiuni
SIRUTA Nivel 2 și/sau 3.

Pentru a maximiza performan ța globală și funcționalitatea oferit ă, vizualizarea datelor aferente
nivelurilor superioare școlii, respectiv Minister și Inspectorat, va fi implementată în afara Nucleului
aplicativ de Catalog e lectronic, respectiv utilizând componente din zona de Analiz ă avansată și
vizualizare de date, pe baza unui datawarehouse distinct de bazele de date de produc ție.

Utilizatorii de tip director/secretar au la dispozi ție:
o Situa ția școlar ă a unui elev/a mai multor elevi;
o Rapoarte privind notarea ritmic ă;
o Rapoarte privind frecven ța la ore;
o Rapoarte privind progresul școlar în raport cu mediile la nivelul școlii, local, jude țean, na țional;
o Rapoarte de pondere a încheierii situa ției școlare;
o Rapoarte de frecven ță a sincroniz ării tabletelor cu SIMS ;
o Generare catalog în format PDF.

45
Utilizatorii de tip elev/p ărinte au la dispozi ție:
o Situarea elevului în clasamentul clasei/ școlii;
o Evolu ția mediei elevului în timp.
o Rapoarte comparative pe regiune și la nivel na țional

3.2.1.4.5 Mesagerie

 Utilizatorii platformei pot folosi mesageria intern ă pentru a trimite mesaje atât c ătre un singur
destinatar cât și către mai mul ți destinatari. Modulul de Mesagerie împarte mesajele utilizatorului
în func ție de trei criter ii:
o Primite
o Expediate
o Arhivate
 De asemenea , utilizatorii pot folosi câmpul de c ăutare pentru a g ăsi facil orice mesaj necesar.
 În cazul destinatarului singular, este suficient ca expeditorul s ă tasteze numele destinatarului în
câmpul dedicat iar aplica ția îi afi șează o list ă de nume sugerate din care poate alege.
 În cazul în care nu se cunoa ște numele destinatarului acesta poate fi c ăutat dup ă diverse criterii:
o tipul destinatarului: cadru didactic, personal administrativ, inspector, departamentul Rela ții
Clien ți etc.
o după materia predat ă (în cazul cadrelor didactice)
o după func ție (în cazul personalului administrativ și inspector)
 În cazul în care expeditorul dore ște să trimit ă mesajul c ătre un grup de persoane, poate selecta
destinatarii din sec țiunea Caut ă Destinatar.
 Prin selectarea categoriei vizate: Elevi, P ărinți, Cadre didactice, Administrativ, Institu ții exist ă
posibilitatea select ării globale sau individuale a destinatarului.
 Pentru categoria Elevi pot și selecta ți toți elevii unei clase sau anumi ți elevi din anumite clase.
 Pentru categoria P ărinți pot fi selecta ți toți părinții elevilor dintr -o clas ă sau anumi ți părinți ai unor
elevi din anumite clase.
 Pentru categoria Cadre Didactice filtrarea se poate face în func ție de anul de studiu sau mate ria
predat ă, astfel pot fi selecta ți toți profesorii sau anumi ți profesorii ce predau la o anumit ă clasă
sau to ți profesorii sau anumi ți profesori ce predau aceea și materie.
 În cazul Institu țiilor utilizatoare, mesajul poate fi trimis c ătre toate cadrele didactice din țară, din
anumite jude țe, către tot personalul administrativ etc.
 Modulul Mesagerie ofer ă posibilitatea vizualiz ării statusului mesajelor expediate. Astfel,
expeditorul poate vizualiza dac ă destinatarul a citit mesajul s ău, iar în cazul mesajelor c ătre un
grup, ce persoane au citit mesajul transmis.
 Mesajele pot avea unul sau mai multe atașament e, în limita a 50 Mb; se va impune o limit ă maxim ă
a căsuței po ștale aferent ă unui utilizator în func ție de profilul acestuia; utiliz atorii pot exporta
mesajele mai vechi în formate standard pentru arhivare de mesaje, precum .msg, .eml sau .pst.
 Anumite mesaje importante (în condi ții mai restrictive – tip text, max.100 caractere) pot fi
transmise individual sau în regim broadcas t către mai mul ți utilizatori si multan pe canal tip SMS –
soluția aplicativ ă va include func ționalit ățile necesare apel ării unui SMS Gateway pentru acest tip
de serviciu cu mesajele și datele necesare transmiterii acestora, r ămânând ca serviciul efectiv de
transmitere a SMS -urilor s ă fie pus la dispozi ție ulterior de c ătre Beneficiar

46

3.2.1.4.6 Partajare Fi șiere Și Colaborare

Acest modul vine în sprijinul activit ăților colaborative și ofer ă utilizatorilor posibilitatea de a stoca și
partaja fișiere în contul personal . Necesitatea sa este data de situa țiile în care utilizatorii folosesc medii
de stocare diverse care uneori dau erori de compatibilitate sau exist ă riscul de a fi r ătăcite. Prin
intermediul acestuia se pot transmite fi șiere și documente de mici dimensiuni ce urmeaz ă a fi
prezentate sau folosite într -un context strict educa țional.

Modulul este destinat cu preponderen ță:
o profesorilor – pentru transmiterea c ătre elevi sau colegi de resurse educa ționale specifice în
format electronic; de regul ă, fișierele se vor înc ărca în contextul strict al unei activit ăți școlare,
materii etc. și vor fi vizibile elevilor care au fost selecta ți în prealabil
o elevilor – pentru transmiterea de teme c ătre profesori, sau ca r ăspuns la alte solicit ări ale
acestora; de regul ă, elevii nu pot înc ărca fi șiere pentru al ți elevi , ele vor fi vizibile numai
profesorului care a solicitat fi șierul .

 Modulul de partajare fi șiere permite înc ărcarea oric ărui tip de document (Doc, PDF, PPT, Excel,
JPG etc.).
 Fișierele înc ărcate pot fi inserate în Directoare denumite corespunz ător pentru o mai bun ă
organizare. Ulterior, fi șierele pot fi mutate dintr -un dosar în altul.
 Utilizatorii au posibilitatea s ă pre-vizualizeze fi șierele direct din aplica ție (word, excel, ppt, imagini,
txt).
 În cazul în care nu se cunoa ște numele destinatarului acesta poate fi c ăutat dup ă diverse criterii:
o tipul destinatarului: cadru didactic, personal administrativ, inspector, departamentul Rela ții
Clien ți etc.;
o după materia predat ă (în cazul cadrelor didactice) ;
o după func ție (în cazul personalului administrativ și inspector).
 Pentru fiecare fi șier care se dore ște a fi distribuit, aplica ția permite generarea unui link portabil .

Securitate
 Având în vedere c ă acest depozit de documente este la dispozi ția unui num ăr foarte mare de
utilizatori, securitatea con ținutului expus c ătre utilizatori este de cea mai mare importan ță.
 Se pot înc ărca doar fi șiere de anumite tipuri (doc, docx, xls, xlsx, pdf, jpg, avi, mpg, mp3 etc.), iar
lista este definitivat ă în faza de anal iză și poate fi actualizat ă ulterior.
 Înainte de a stoca un fi șier (sau dac ă e acceptabil, în paralel – asincron) , sistemul face o verificare
de validitate, asigurându -se că fișierul corespunde din punct de vedere al con ținutului. Practic t ot
conținutul încărcat de c ătre profesori și alți reprezentan ți ai MEC ar trebui verificat extrem de
atent din punct de vedere al securit ății, inclusiv prin intermediul unei solu ții de tip sandbox.
Inclusiv toate atașament ele care se pot trimite prin modulul de mesager ie vor trebui stocate în aceast ă
zonă și vor beneficia de func ționalit ățile aferente (nu se vor putea ata șa documente din alte loca ții).

47
Pentru fiecare tip de utilizator se va defini în sistem o limit ă maxim ă de spa țiu disponibil ( quota ) pe
care acesta nu o va putea dep ăși.
Pe baza modulelor anterioare se configureaz ă următorul set de func ționalit ăți mai avansate:

3.2.1.4.6.1 Teme

 Definirea fiec ărei teme în parte poate fi f ăcută de c ătre profesori. Ace știa au acces la o sec țiune
dedicat ă prin intermediul c ăreia pot încărca tema setând titlul acesteia, data limit ă și ora pân ă la
care elevii pot trimite tema efectuat ă și cerin ța proiectului. Pentru fiecare tem ă se poate anexa
un document în limita a 50 Mb. Ulterior profesorul alege elevii care vor avea aceast ă temă bifând
toată clasa sau selectând elevii viza ți.
 Elevii aronda ți vor primi notific ări automate din partea sistemului cu cerin țele impuse de c ătre
profesor.
 Elevii pot înc ărca și reînc ărca (cu suprascriere) tema de câte ori doresc în intervalul de timp definit
– sistemul va valida condi țiile și va bloca înc ărcarea în cazul în care acestea nu se îndeplinesc.
Sistemul va marca temporal fiecare fi șier înc ărcat și va returna o recipis ă elevului. Dup ă încheierea
timpului de înc ărcare, profesorul poate desc ărca ultim a versiune înc ărcată de fiecare elev.
 Temele elevilor sunt disponibile pentru vizualizare și din contul de p ărinte.
 De asemenea , exist ă o zon ă de Q&A în care elevii pot pune întreb ări profesorului în intervalul de
timp în care este înc ă permis ă încărcarea temei. Profesorul poate r ăspunde fiec ărei întreb ări în
parte sau poate face observa ții generale și actualiz ări în sec țiunea cu cerin țele temei.
 Sistemul pune la dispozi ție profesorului o zon ă în care acesta poate:
o Nota fiecare tem ă individual
o Da feedback individual fiec ărui elev
o Da feedback global tuturor elevilor care au înc ărcat tema

3.2.1.4.6.2 Extra școlare

 Modulul de activit ăți extra școlare permite tuturor utilizatorilor s ă creeze astfel de activit ăți și să
invite al ți utilizatori ca membri în grupuri dedicate.
 Grupurile create pot fi de 2 tipuri:
o grupuri publice (vizibile tuturor elevii, p ărinților și profesorilor din școală)
o grupuri private (vizibile doar celor care primesc invita ție din parte celui care a creat
grupul).
 Modulul permite organizarea de activit ăți extra școlare ce au loc atât în cadrul școlii cât și în alte
locuri.
 Modulul ofer ă posibilitatea de a urm ări și de a marca prezen ța la eveniment .
 Pentru activit ățile extra școlare care se repet ă, utilizatorul poate alege din mai multe tipuri d e
recuren ță:
o Recuren ța săptămânal ă (aici fiind disponibile posibilitatea de selectare a zilei din
săptămân ă și a intervalului orar pentru activit ățile care se repet ă de mai multe ori în
aceea și zi)

48
o Recuren ța lunar ă (se aplic ă pentru situa țiile când activitatea se repet ă de mai multe
ori într -o singur ă lună sau are loc în luni diferite)
o Recuren ța într -o dat ă fixă (se aplic ă în cazurile când activitatea are loc semestrial sau
o singur ă dată în an).
 Persoana care creeaz ă activitatea extra școlar ă are po sibilitatea s ă defineasc ă un set de marcaje.
Acestea pot fi folosite de coordonatori pentru a selecta statusul unui elev la o întâlnire (de
exemplu: absent, prezent sau participant, observator etc).
 Pentru fiecare activitate extra școlar ă se creeaz ă automa t o pagina asem ănătoare unui panou
central unde:
o participan ții pot discuta la comun prin intermediul unei ferestre de tip chat;
o se pot vizualiza datele de recuren ță ale activit ății și când are loc urm ătoarea activitate;
o se pot vedea care sunt membrii și coordonatorii pentru activitatea respectiv ă;
o membrii aceluia și grup pot trimite mesaje private unul altuia;
o pe lista membrilor se pot aplica filtre pentru vizualizare în ordine alfabetic ă, dup ă tip
de utilizator sau dup ă clasa din care face parte.
 Utiliza torul care a organizat activitatea respectiv ă împreun ă cu coordonatorii grupului, pot vedea
statistici de participare precum:
o procent de participare pe fiecare întâlnire în parte;
o procent de participare pe fiecare membru în parte (la câte întâlniri a participat și din
ce dat ă);
o procent de acordare marcaje pe fiecare întâlnire în parte și alte rapoarte.

3.2.1.4.6.3 Management Conținut Didactic

Din cauza multitudinii de manuale, caiete de lucr u și auxiliare, lectura obligatorie și suplimentară ,
ghiozdanul unui elev ajunge s ă cânt ăreasc ă între 8 și 10 kg.
eLearning -ul și resursele online dedicate înv ățării se dovedesc a fi mult mai apreciate de elevii români
și nu numai. Elevii declar ă că sunt mult mai interesa ți de activitatea didactic ă dacă au posibilitatea s ă
înve țe folosind mijloace moderne, s ă vizualizeze interactiv lec țiile, s ă acceseze materialele școlare
online, s ă adauge noti țe și să foloseasc ă un mix de mijloace: text, imagini, grafice, sunet. Socializarea
și posibilitatea de a lucra împreun ă cu al ți colegi sau parteneri de proiect și compararea rezultatelor
sunt de asemenea aspecte apreciate de elevii contemporani.
Caracteristici
 Permite cre șterea considerabil ă a nivelului de accesibilitate și fiabilitate în utilizare a suporturilor
educa ționale prezente prin imersarea lor într -o interfa ță online, sigur ă și personalizat ă, dedicat ă
fiecărui tip de utilizator în parte.
 Solu ția ofer ă un sistem de Management de con ținut alc ătuit din articole educa ționale, c ărți,
reviste, video -uri educative și tutoriale, document are dintr -un spectru larg.
 Alături de stocul ini țial de documente disponibile, acest modul permite crearea de categorii
distincte în func ție de domenii le de interes și popularea cu materiale conexe domeniului : cărți
suplimenta re, articole, reviste sau studii, materiale video și document are.
 Materialele integrate permit sortarea lor dup ă domenii de interes, dup ă data acces ării sau
marcarea lor în func ție de calitatea con ținutului (tip scor și feedback) și relevan ță pentru subiect.

49
 În afara accesibilit ății individuale acestea vor putea fi partajate cu grupul de lucru, colegi, elevi și
recomandate altor membri ai grupurilor de lucru, totul în tr-un mediu online protejat.
 Fiecare utilizator are posibilitatea s ă încarce fi șiere cu extensia .txt, .pdf,.doc, .docx, mp4, .avi,
.epub, s ă editeze materialele înc ărcate sau s ă atașeze o imagine de copert ă cu o descriere unic ă.
 Func ția de Management a conținutului didactic are urm ătoarele caracteristici:
o Online și interconectat ă
o Suport ă o multitudine de formate
o Editabil ă și personalizat ă
o Platform ă integrat ă multi -user/conturi individuale și conturi tip unitate de înv ățământ.

Accesibilitate
 Materialele din cadrul sistemului de management de con ținut pot fi vizualizate direct din aplica ție
și sunt adaptate pentru diverse dispozitive mobile: telefon mobil, tablet ă, laptop.
 Accesul se poate realiza atât la nivel de conturi individuale cât și grupat la nivel de clase, cicluri de
studiu sau unit ăți de înv ățământ. Interconectarea al ături de interfa ța social ă permite utilizatorilor
să acceseze informa ții și statistici avansate ca: num ărul de desc ărcări/ vizualiz ări, categoria c ăreia
apar ține docum entul sau scorul pe care l -a primit un anumit document .
 Sistemul permite accesul la documente la orice or ă și din orice loca ție, dep ășind astfel limit ările
unei biblioteci clasice publice sau private.
 Manualele digitale aprobate MEC pot fi publicate și distribuite prin modulul de management de
conținut didactic asigurând disponibilitatea acestora imediat ă.

3.2.1.4.6.4 Rapoarte Și Chestionare

 Acest modul este destinat tuturor utilizatorilor și are ca scop realizarea de sondaje de opinie ce
urmăresc colectarea de informa ții din rândul utilizatorilor (p ărinți, elevi, profesori etc).
Răspunsurile se pot colecta atât individualizat cât și anonim.
 Modulul de teste și chestionare are dou ă opțiuni principale:
Chestionare
Acestea pot fi create de profesori, dirigin ți, secretari, directori și pot fi aplicate tu turor
tipurilor de utilizatori)
Chestionarele pot fi aplicate o singur ă dată și sunt recomandate pentru a face sondaje de
opinie.
Rapoarte recurente
Rapoartele recurente se recomand ă pentru a colecta informa ții cu recuren ță zilnic ă,
săptămânal ă, lunar ă sau anual ă.
 Pentru ambele tipuri se poate seta un termen limit ă de completare.
 Răspunsurile colectate în urma chestionarelor și a rapoartelor sunt afi șate atât în contul celui care
le creeaz ă cât și în contul celui care completeaz ă.
 Afișarea rezultatelor se face sub form ă de:
o răspunsuri individuale;

50
o răspunsuri agregate;
o sub form ă de grafice.
 Spre deosebire de Chestionare care pot fi aplicate și anonim, rapoartele sunt doar nominale și pot
fi aplicate unor grupuri de utilizatori precum:
o o clas ă întreag ă;
o un an școlar întreg;
o o anumit ă materie etc.
 Acest modul reprezint ă o componenta integrat ă a modulul global de extragere și analiz ă date.
Modulul de formulare electronice este utilizat pentru c ulegerea de date la sc ara mare și este
interconectat cu modulul de raportare.

3.2.1.4.6.5 Modul Anun țuri Și Nout ăți

 Modulul ofer ă posibilitatea vizualiz ării și transmiterii de anun țuri, știri sau alte nout ăți din
educa ție, către Inspectori, profesori, directori și secretari.
 La nivel de transmitere MEC are posibilitatea de a trimite anun țuri, știri, nout ăți către absolut to ți
utilizatorii sistemului, Inspectoratele Jude țene c ătre utilizatorii aferen ți jude țului de care apar țin
iar directorii și secretarii c ătre utilizatorii apar ținând școlii respective.
 Toți utilizatorii aplica ției au astfel posibilitatea s ă vizualizeze cele mai recente știri și nout ăți din
educa ție, dar și știrile personalizate înc ărcate de personalul administrativ al fiec ărei unit ăți școlare
în parte.
 Părinții și elevi i au astfel posibilitate s ă vizualizeze nout ăți despre evenimente școlare, burse și alte
informa ții utile postate de c ătre secretariatul școlii.

3.2.1.4.6.6 Fluxuri de lucru

În cadrul proiectului , eventual pe baza platformei de Management a documente lor specificate în
cap.3.3.9 , se vor implementa până la 20 fluxuri de lucru care vor implica profesori, conducerea local ă
și central ă, și, pentru unele dintre ele, și elevi sau chiar p ărinți
 Cele două zeci de fluxuri de lucru vor avea o complexitate medie sau mare, fiecare cu cel puțin câte
10 tranzi ții , 5 decizii și 8 interac țiuni complexe cu utilizatorii
 Se vor avea în vedere mai multe categorii de fluxuri de lucru, cum ar fi:
o Flux de lucru pentru ob ținerea unor aprob ări al nivel de institu ție școlar ă
o Flux de lucru pentru ob ținerea unor aprob ări la nivel de inspectorat
o Flux de lucru pentru ob ținerea de date din teritoriu și consolidarea succesiv ă a acestora l a
nivel de inspectorat și apoi la nivel central
o Flux colaborativ tip șablon pentru procese de înv ățare coopera tivă lansate de profesor
o Flux colaborativ tip șablon pentru efectuare de teme lansate de profesor
 Stabilirea fluxurilor care se vor implementa se va face de c ătre Beneficiar la începutul proiectului
 Analiza și implementa rea fluxurilor se va face de c ătre F urnizor, împreun ă cu pilotarea și reglarea
detaliilor acestora pentru o bun ă func ționare în practic ă
 Fluxurile vor fi ini țiate din cadrul Nucleului operativ

51
 Fluxurile de lucru nu trebuie s ă fie implementa te static, adic ă trebuie s ă poat ă fi modificate
ulterior relativ ușor
 Pe cât posibil, interac țiunea cu actorii (profesorii, func ționarii, elevii și părinții) se va face exclusiv
prin elemente expuse de Nucleul aplicativ (mesagerie, componentele de partajare fi șiere și
colaborare, chestion are)

3.2.2 Platforma suport pentru Evaluarea Na țional ă și Bacalaureat

Una dintre func țiile cele mai importante ale SIMS e aceea de platform ă suport pentru procesele de
Evaluare Na țional ă și Bacalaureat .
În mod concret, SIMS va implementa alături de func ționalit ățile de mai sus un set de procese și fluxuri
de lucru colaborative care vor constitui baza IT pentru activit ățile de colectare și digitizare a lucr ărilor
elevilor, respectiv de corectare a acestora de c ătre un colectiv de profesori localiza ți oriun de în țară.
Grupul de func ționalit ăți aferente Evalu ărilor Na ționale și Bacalaureat se vor grefa organic peste
Nucleul aplicativ descris mai sus, integrându -se natural în structura aplica ției de Catalog Electronic. Se
vor implementa astfel urm ătoarele func ționalit ăți:
Pregătire Evaluare:
 Înregistrarea popula ției de elevi care va sus ține Evaluarea. Se va putea utiliza orice combina ție
între:
o import de date din alte sisteme cu validare în nomenclatoarele SIMS
o selec ție direct ă pe nomenclatoarele din SIMS, apl icând diverse filtre
 Declararea și înregistrarea loca țiilor, s ălilor și a responsabililor de s ăli
 Generarea de etichete autoadezive pentru identificarea lucr ărilor scrise
 Declararea și înregistrarea loca țiilor și responsabililor de digitizare
 Declararea și înregistrarea profesorilor corectori și a disponibilit ății acestora
 Definirea baremului de corectare (list ă de criterii și punctaje asociate)
Înregistrarea și digitizarea lucr ărilor:
 Asocierea lucr ării scrise cu unul dintre elevi, pe baza etichetei lipit e pe lucrare ( prin scanare a
etichetei la începutul examen ului)
 Înregistrarea lucr ării scrise în sistem, pe baza etichetei lipite pe lucrare (prin scanare a etichetei la
predarea lucr ării) și alocarea acesteia unui Pachet de lucr ări, având asociat un cadru responsabil
 Declararea Pachetului de lucr ări în tranzit spre un centru local de digitizare
 Declararea prelu ării Pachetului intact la loca ția de digitizare de c ătre un responsabil
 Digitizarea propriu -zisă, utilizând scannere de capacitate mare, integrate c u sistemul
 Salvarea lucr ărilor în format electronic într -o arhivă dedicat ă
 Reten ție în cadrul Arhivei
Corectarea lucr ărilor:
 Distribu ția automat ă anonimizat ă a lucr ărilor c ătre un profesor corector , pe baza op țiunii și/sau a
încărcării acestora
 Corectarea propriu -zisă și notarea lucr ării, pe baza baremului standard implementa t electronic și
însoțită de observa țiile de rigoare

52
 Salvarea notelor în sistem și publicarea acestora c ătre cei interesa ți
 Implementa rea cazurilor excep ționale, și a contesta țiilor, pri n re-alocarea automat ă la corec ție
către un alt profesor corector decât cel ini țial (versiune simplificat ă a Revenirii de mai jos)
Finalizarea Evalu ării:
 Transferul notelor în SIMS și către alte sisteme interesate
 Publicarea de rapoarte statistice pe site -ul public
 Publicarea de rapoarte avansate c ătre cadrele de conducere
 Transferul lucr ărilor în arhiv ă
 Transferul datelor detaliate de corectare anonimizate, bazate pe baremuri, pentru analiz ă
avansat ă, în uneltele specializate de analiz ă a datelor, pentru a determina calitatea și relevan ța
Evalu ării
Revenire:
 Flux de ob ținere a aprob ării de interven ție excep țional ă
 Posibilitatea de a extrage, în mod excep țional și cu aprob ările de rigoare, o lucrare anume din
arhiv ă, spre a o re -trimite la corectare, împreun ă cu baremul în vigoare la data Evalu ării
 Selec ția unui grup de profesori corectori pentru re -evaluare, pe baza baremului în vigoare la data
Evalu ării
 Flux de acceptare / respingere a noului rezultat.

Aplica ția care gestioneaz ă local procesul de digitizare a lucr ărilor va trebui s ă poat ă lucra și în mod
deconectat, pentru a permite continuitatea procesului de scanare în caz de întrerupere temporar ă a
legăturii de date. Documente le scanate se vor înc ărca în sistemul central în mod inteligent, pe baza
unui algoritm care s ă evite suprapunerea în upload a prea multor centre de date și crearea unor vârfuri
de comunica ție la nivelul centrelor de date. Pentru aceste motive aplica ția va lucra cu un cache local .
Opera țiunile de scanare a et ichetelor se vor realiza prin aplica ția mobil ă nativ ă iOS și Android,
integrat ă în cadrul solu ției SIMS în ansamblu (la nivel de identificare și autentificare, fluxuri și depozite
de documente etc.).
Furnizorul va livra inclusiv etichetele autocolante pre -tipărite necesare pentru toat ă perioada
contractual ă.

3.2.3 Arhiv ă electronic ă

Pe baza platformei de Management a documente lor specificate în cap. 3.3.9 se vor implementa două
seturi de func ționalit ăți:
 Motorul intern de stocare, reg ăsire și accesare a documente lor generate și / sau manipulate de
către sistem – este important ca drepturile de acces asupra acestora s ă fie p ăstrate pe toat ă durata
lor de via ță
 Gestiunea ciclului de via ță a documente lor cu caracter oficial, pentru care trebuie impuse perioa de
de reten ție clar definite, inclusiv nelimitat
o Se va asigura transferul documente lor între diversele niveluri de stocare (online – storage
NAS, arhiv ă online – bkp2dsk , arhiv ă de termen lung – tape )

53
o Implementa rea Arhivei electronice trebuie s ă respecte t oate cerin țele legale aferente
acesteia.

3.2.4 Securitate

Întreaga solu ție informatic ă aferent ă SIMS se va proiecta având maximizarea securit ății ca obiectiv
primordial. Toate module care implementează func ționalit ățile aferente SIMS vor trata în mod unitar
următoarele aspecte:
Autentificare și Autorizare acces:
 Toate componentele vor folosi acela și nomenclator de utilizatori și acela și set de creden țiale dintr –
o surs ă comun ă de tip master
 Odat ă autentificat, utilizatorul va primi acces în toate modulele la care este autorizat
 Pentru a securiza accesul, sistemul va permite mai multe tipuri de login în func ție de tipul de
utilizator:
o Autentificare soft: pe baza de ID/Parola ;
o Autentificare avansată: autentificare în 2 factori cu OTP, cu trei alternative:
 Software token pe un dispozitiv mobil – necesit ă înregistrarea / înrolarea în sistem
a acestui dispozitiv ; OTP se va genera pe baza unui PIN, dup ă înregistrare
 Posibilitatea de a folosi tablet a înr olată în sistem a cadrul ui didactic ca al doilea
factor (poate g ăzdui generatorul de OTP – dar numai în cazul unui singur utilizator
per tablet ă);
 Va trebui s ă func ționeze inclusiv dac ă nu exist ă comunica ție de date între
dispozitiv / tablet ă și centrele de date (OTP va putea fi generat și validat offline!)
 În cazul în care tableta este utilizat ă în comun de mai mul ți profesori se va
interzice (sau invalida, dac ă era anterior instalat) utilizarea generatorului de OTP
de pe acela și dispozitiv
o Autentificare hard : autentificare pe baza de certificat digital calificat (mai ales pentru
terțe părți; în aceste cazuri costul aferent al certificatului va trebui prev ăzut de utilizatorul
final sau de ter ța parte) .

Semnarea tranzac țiilor:
 În sensul SIMS, vom definii o tranzacție SIMS ca fiind orice opera țiune de înregistrare sau
schimbare a unei note ori a unei absen țe (tranzac ție simplă) sau a unui document de tip situa ție
școlară (tranzacție complex ă).
 Pentru a asigura non -repudierea abso lută și valoarea legal ă a principalelor tranzac ții efectuate în
sistem, acestea trebuie semnate final de c ătre ini țiatorul acestora pe baza unui certificat digital
avansat sau calificat, asociat univoc cu persoana fizic ă respectiv ă.
 Tranzac țiile simple se vor pot putea efectua în doi pa și:
o Sincronizarea tranzac țiilor între dispozitivul mobil, cu validarea acestora de c ătre sistemul
informatic central
o Semnare ulterioar ă pe baz ă de certificat digital avansat (pentru tranzac țiile gestionate de
SIMS) sau calificat (pentru tranzac țiile gestionate de un ter ț)

54
 Tranzac țiile complexe au întotdeauna la baz ă un document autentificat prin semn ătură calificat ă
de c ătre un cadru didactic și/sau, dup ă caz, secretariatul și conducerea unit ății școlare,
contrasemnate semnat definitiv în sistem prin aplicarea unui sigiliu tempora l bazat pe o
semn ătură calificat ă (compatibil ă eIDAS) generat ă automat de sistem ul central (în cazul SIMS) , cu
autoriz ările de rigoare dup ă caz
 SIMS va putea genera tranzac ții simple doar în cazul prelucr ărilor proprii – tranzac țiile care provin
din sisteme ter țe trebuie semnate definitiv de c ătre acestea: SIMS nu va accepta la intrare
tranzac ții semnate temporar și va verifica la ingestie validitatea semn ăturilor definitive
 Tranzac țiile compl exe vor fi apoi contrasemnate de SIMS chiar și în cazul în care provin din sisteme
terțe
SIMS va include infrastructura necesar ă semn ării avansate și a aplic ării de sigilii temporale.
Beneficiarul nu va trebui s ă invest easc ă în infrastructura proprie calificată de tip PKI: certificatele
calificate suportate sunt toate cele valabile pe teritoriul na țional, împerecheate cu utilizatorii la nivelul
CNP. Serviciul de semnare calificat ă în cadrul SIMS pentru to ți actorii menționați (profesori, secretar
șef, Manag ement unitate școlar ă) va fi inclus integral în cadrul mentenanței sistemului.
Asigurarea semn ării avansate va fi f ăcută printr -o solu ție local ă (instalat ă în centrele de date),
independent ă de alte componente ale solu ției, care s ă garanteze:
 securitatea absolut ă a certificatelor digitale individuale utilizate în semnarea avansat ă, pe tot
ciclul de via ță al acestora
 securitatea deplin ă a utiliz ării certificatelor digitale și a procesului de semnare în sine
 validarea vizual ă nemijlocit ă de alte sisteme de c ătre cel care semneaz ă, a datelor /
informa țiilor care trebuie semnate, înainte și dup ă semnare, într -un format facil accesibil
oricărui operator uman
 posibilitatea semn ării de pe dispozitive mobile care nu asigur ă securizarea unui certificat
digital în re gim de stocare local ă.

Trasabilitatea și Auditul activității:
 Aplica ția va permite utilizatorilor s ă vizualizeze istoricul complet al activit ății pe fiecare cont cu
posibilitatea filtr ării tranzac țiilor dup ă anumite criterii:
o perioad ă de timp;
o tip de ac țiune;
o dispozitiv folosit;
o locație (dac ă este disponibil ă).
 Istoricul activit ăților, cu toate detaliile aferente, va fi p ăstrat pe termen lung într -o aplica ție
specializat ă de tip log management , specificat ă în cap. 3.4, pentru a permite analize corelate și
activit ăți de audit și investigare
 Se vor avea în vedere în mod special detaliile de audit pe opera țiunile de semnare, mai ales cea
calificat ă (unde și acestea trebuie s ă fie semnate calificat) .

OWASP:
 Furnizorul va înso ți fiecare modul de un raport de conformitate OWASP

55
 La recep ția artefactelor software, acestea vor fi testare în prealabil cu o unealt ă de testare
automat ă specializat ă în identificarea vulnerabilit ăților specifice OWASP , de c ătre un auditor de
terță parte
Elementele de securitate aplicat ivă descrise aici vor fi completate cu o implementa re comprehensiv ă
a solu țiilor de securitate specificate în cap. 3.4.2 .
Securitatea aplica țiilor va fi certificat ă prin testare de securitate specializat ă, precum și prin teste de
penetrare , de c ătre un aud itor de ter ță parte .
Furnizorul are obliga ția de a corecta toate abaterile importante care vor rezulta din aceste test ări de
terță parte, precum și o parte dintre acele abateri de nivel cosmetic care vor fi considerate necesare
de către Benefic iar.

Securizarea datelor locale:
 Aplica ția va cripta datele p ăstrate pe dispozitiv între sesiunile de lucru
 Datele trebuie sc criptate cu chei diferite de la un profesor la altul
 Datele nu trebuie s ă fie accesibile între profesori dac ă mai mul ți utilizeaz ă același dispozitiv
 În cazul utiliz ării de certificate digitale, acestea nu vor fi stocate local în modalit ăți ce pot fi
compromise, spre exemplu prin root -area dispozitivului – dacă se utilizeaz ă astfel de tehnici
bazate pe certificate locale, se va descrie în detaliu modalitatea în care este securizat ă cheia
stocat ă local împotriva oricărui tip de atac .

3.2.5 Analiz ă avansat ă și vizualizare date (AVD )

Pe lâng ă rapoartele operative descrise mai sus, SIMS va include o platforma specializat ă pentru
stocarea, analiza avansat ă și vizualizarea datelor, a șa cum este ea descris ă în cap. 3.3.12 .
 Pe baza acesteia se va implementa un data lake și o structur ă de tip data mart / data warehouse
 Se vor implementa procesele de alimentare a acestor structu ri din depozitele de date ale SIMS și
din sursele externe specificate
 Se vor construi un num ăr de:
o 5 analize / rapoarte avansate utile la nivel de profesor
o 5 analize / rapoarte avansate utile la nivel de clas ă
o 15 rapoarte avansate utile la nivel de unitate
 Se vor implementa minim 15 tablouri de bord (dashboards) complexe:
o La nivel de inspectorat, cu minim 10 indicatori
o La nivel central, cu minim 15 indicatori
 10 rapoarte statistice semi -statice pentru public

3.2.6 Integrare (PUB -CE)

Se vor construi cel puțin patru nivelu ri de interfa țare cu SIMS:

56
Autentificare delegat ă:
 Platforma poate oferi servicii de autentificare și Identity provider pentru alte aplica ții. Sistemul va
implementa o interfa ță standard de tipul OpenID Connect / OAuth 2.0 expus ă către ter țe părți,
pentru autentificare în aplica țiile acestora în baza identit ății definite și validate în SIMS
 Se poate configura și utiliza pe fiecare dintre niveluri (parol ă, OTP și PKI). Folosind aceast ă
interfa ță, alte aplica ții vor putea delega identificarea și autentificarea persoanelor care au un rol
activ în SIMS c ătre acesta
 SIMS va avea reguli stricte legate de aplica țiile care vor putea utiliza aceast ă interfa ța și va păstra
un istoric clar al acestor cereri de autentificare
Interfață funcțională:
 Platforma expune un API restfull în care sunt disponibile toate func ționalit ățile de baz ă ale
Nucleului aplicativ de Catalog (gestiune note și prezen ță) pentru a asigura integrarea cu u șurință
cu alte aplica ții third -party de management al școlarit ății.
 Componenta de back -end asigur ă procedurile și func țiile specifice de gestiune și prelucrare a
datelor și asigur ă comunicarea cu celelalte module ale sistemului
 SIMS va avea reguli extrem de stricte legate de aplica țiile care vor putea utiliza aceast ă interfa ță
și va păstra un istoric clar al interac țiunilor cu acestea
 Nivelul de func ționalitate va putea fi delegat mai mult sau mai puțin către aceste aplica ții, în
func ție de sofisticarea acestora (acestea vor putea fi oricât de complexe, de la o simpl ă interfa ță
peste SIMS API pân ă la implementări comp lete de sine st ătătoare . În orice caz, vor exista dou ă
bariere ce nu vor putea fi înc ălcate:
o Orice apel în SIMS va trebui f ăcut în numele unui utilizator final (profesor, func ționar, elev,
părinte etc.) pe baza Aute ntificării delegate descrise mai sus
o Toate tranzac țiile SIMS vor trebui securizate exclusiv în cadrul aplica țiilor ter țe, prin
mijloace proprii; SIMS va semna numai tranzac țiile SIMS simple derulate integral prin
acesta, respectiv va contrasemna tranzac țiile complexe semnate și primite de la ter ți
Standardul de interoperabilitate aferent celor dou ă interfe țe de mai sus va fi dezvoltat în cadrul
proiectului și va fi anex ă la Metodologia de acreditare a aplica țiilor de tip catalog electronic, elaborat ă
tot în cadrul proiectului și care va fi aprobat ă prin O MEC astfel încât s ă se asigure cadrul metodologic
necesar acredit ării aplica țiilor respective pentru a putea interac ționa cu SIMS.
Interfețe aplicative și Interfețe pentru schimb de date:
 În cadrul pr oiectului se vor implementa interfe țe cel puțin cu toate aplica țiile MEC și externe
menționate în acest document
 Ca regul ă, se va încerca ca SIMS s ă fie cât mai independent de alte sisteme, inclusiv SIIIR – nu se
vor face apeluri și interog ări tranzac ționale în sisteme externe, ci, peste tot unde este posibil, se
vor replica datele în SIMS: fie în baza de date opera țional ă (în mod excep țional), fie în depozite de
date secundare, pentru suport decizie (datawarehouse, data lake)
 În general se vor prefera interfe țe de schimb de date tip batch, dar în anumite cazuri nu vor putea
fi evitate interfa țările la nivel de API dedicat; în mod cu totul excep țional, unele aplica ții vor
necesita ambele tipuri de interfe țe
 Deciziile des pre tipul fiec ărei interfe țe în p arte și detaliile aferente se vor stabili î n cadrul
proiectului

57
Absolut toate interfe țele cu sisteme ter țe se vor implementa exclusiv prin intermediul produselor de
integrare / autentificare tip software aplicativ COTS solicitate la cap. 3.3.6 și 3.3.11.

3.2.7 Semnare tranzac ții

Una dintre cele mai importante probleme care se ridic ă în fa ța sistem ului de fa ță este cea de asigurare
a caracterului legal, respectiv a non -repudierii tranzac țiilor școlare gestionate de c ătre acesta.
Problema trebuie abordat ă pe trei niveluri:
 Un nivel generic, care implic ă implementa rea unui sistem avansat de control al accesului și
audit al opera țiunilor, care s ă asigure securitatea și trasabilitate tuturor tranzac țiilor.
 Un nivel de arhivare, care s ă asigure stocarea docum ente lor electronice formale asociate
tranzac țiilor școlare, pe termen lung dar nu numai, conform tuturor exigen țelor impuse de
legile în vigoare
 Un nivel de semnare electronic ă, care s ă garanteze caracterul non -repudiabil al fiec ărei
tranzac ții manipulate în sistem.
Primele dou ă elemente se trateaz ă clasic, prin implementa rea unor mecanisme generice bine
cunoscute , definite în cap.3.2.3 și 3.2.4 și specificate în detaliu în cap.3.3 .
Ultimul punct aduce îns ă provoc ări cu totul speciale, datorit ă num ărului mare de actori implica ți și de
tranzac ții care se realizeaz ă.
Din aceste motive, se alege varianta de optim ă de compromis prin asigurarea unui nivel de semn ătură
digital ă atât pentru documente le școlare oficiale – situa țiile școlare – cât și pentru celelal te tranzac ții
pe parcursul anului școlar:
 Sigilarea temporar ă a situa țiilor școlare la sfâr șit de ciclu școlar, în baza unor semn ături
calificate compatibile eIDAS la nivelul profesor ului, prin contrasemnare calificat ă online la
nivelul de secretariat / Management al unit ății școlare și de c ătre sistemul central; înso țită de
semnarea avansat ă a tranzac țiilor școlare pe parcursul întregului an școlar, la moment ul
sincroniz ării sesiunilor de lucru (în cazul lucrului offline) sau al închiderii acestora (în cazul
lucrului online).
 Tranzac țiile simple se vor valida și semna de c ătre profesori în baza unui document tip PDF,
generat zilnic de c ătre sistem. Semnare se va face pe baz ă de certificate și semn ături avansate,
gestionate de c ătre sistem printr -o solu ție dedicat ă independent ă de celelalte module , asupra
document ului care va lista cu toate detaliile necesare toate tranzac țiilor individuale
înregistrate de c ătre un profesor într -o zi calendaristic ă. Semn ătura se va aplica de c ătre
componenta de semnare dig itală doar cu acordul nemijlocit și explicit al profesorului, precedat
de vizualizarea document ului de semnat și succedat de vizualizarea document ului semnat.
 Semnare de c ătre profesori, pe baza de certificate calificate de uz restrâns, prin mecanisme
compatibile eIDAS, a situa țiilor școlare
 Contrasemnare eIDAS de către nivelul de secretariat / Management al unit ății școlare
 Sigilare temporal ă centralizat ă pe baz ă de certificat calificat a tuturor situa țiilor școlare de
către sistemul central.
Toate procesele de semnare vor fi gestionate și derulate ca fluxuri de lucru în cadrul platformei de
Management de documente . Nucleul aplicativ va fi sesizat de eventualele întârzieri pe aceste fluxu ri

58
(de exemplu un profesor întârzie mai mult de o s ăptămân ă cu semnarea tranzac țiilor zilnice), având
astfel posibilitatea, de exemplu, s ă suspende activitatea tranzac țional ă a profesorului în cauz ă până la
normalizarea situa ției.
Astfel, trasabilitatea, c ertificare și non -repudierea tuturor datelor este complet ă:
 Tranzac țiile simple sunt semnate avansat de c ătre profesor
 Situa țiile școlare sintetice care se semneaz ă digital cu certificat calificat de personal uman :
 Per profesor (semn ătură per materie), la nivelul fiec ărei clase, o dat ă pe semestru
 Per unitate școlar ă (o semn ătură secretar + una director pe toate materiile odat ă), la
nivelul fiec ărei clase, o dat ă pe semestru .
 Situa țiile școlare individuale vor fi semnate calificat doar de către sistemul central, pe baza
datelor din situa țiile școlare sintetice
 Motorul de semnare calificat ă , ca și cel de semnare avansat ă, trebuie s ă genereze situa ții de
tip audit -trail detaliate , semnate digital , care s ă reflecte toate opera țiunile efectuat e.
Diplomele de studiu se pot genera, gestiona și elibera atât în format fizic (semnat fizic de secretar și
director), cât și în format electronic (semnat calificat de c ătre sistemul central pe baza situa țiilor
școlare).
Volumetrie:
 192 500 t itulari de certificate digitale pentru semnare calificat ă a tranzac țiilor complexe –
profesori, Management de unitate școlar ă (se presupune ca sunt din cadrul profesorilor), secretar
șef + adjunct
 Până la 15% rat ă de împrosp ătare / înlocuire anual ă a personalului
 Până la 5 000 000 semn ături calificate pe situa ții școlare sintetice de semnat anual (incluzând aici
Evaluarea Na țional ă, Bacalaureatul și o rat ă de 7.5% de re -semnare din diverse motive)
 Până la 40 000 000 de documente cu tranzac ții simple anual – minim unul pe zi (apx. 18 5 de zile
de studiu pe an) per profesor
Ofertantul trebuie să demonstreze în cadrul ofertei că soluțiile de semnare propuse se bazează pe
certificate digitale și corespund normelor europene (EU 910/201 4) sau legilor naționale legate de
semnătura calificată. Furnizorul de semnătură electronică calificată și/sau certificate digitale claificate
trebuie să fie certificat ca furnizor de Servicii de încredere (Trust services) la nivel european sau paote
fi certificat local de MCSI.
În mod part icular, în cazul procesul ui de semnare avansată, ofertantul trebuie să demonstreze că
soluția propusă asigură toate caracterisiticile Menționate la art.26 pentru semnătura avansată :
 Face trimitere exclusiv la semnatar, fiind legate fără echivoc de acesta
 Permite identificarea clară și univocă a semnatarului
 Este creată utilizând date de creare a semn ăturilor electronice pe care semnatarul le poate
utiliza cu un nivel foarte ridicat de încredere și se află sub controlul său exclusiv
 Este legată direct de dat ele utilizate la semnare (inclusiv document ul propriu -zis care trebuie
semnat), în așa fel încât orice modificare ulterioară a acestora să poată fi detectată.

59
3.3 Infrastructur ă software aplicativ ă

Arhitectura software -ului aplicativ este prezentat ă în diagrama urm ătoare:

Component ă Cantitate minim ă
Server web (WS) 70 nuclee fizice
Servere de aplica ții (AS) 700 nuclee fizice
Formulare web Inclus în AS sau DM
Raportare operativ ă Inclus în AS
Baza de date operativ ă 384 nuclee fizice
API Gateway 128 nuclee fizice
Identitate și Autentificare utilizatori 128 nuclee fizice
Semnare digital ă 48 nuclee fizice / 500 semn ături pe secund ă
Management documente (DM) 128 nuclee fizice
Big data 2×6 noduri
ETL 16 nuclee fizice
Fluxuri de analiz ă date 8 nuclee fizice
Vizualizare avansat ă date 240 nuclee fizice

Ofertantul este unicul responsabil cu dimensionarea soluției, cantit ățile de aici fiind doar minimal
obligatorii – acestea trebuie suplimentate dacă este necesar pentru a îndeplini cerin țele volumetrice și
de performan ță ale solu ției. Dac ă se va determina pe perioada implementări i sau a exploat ării că acestea
au fost sub-dimensionate în raport cu cerin țele, Furnizorul le va suplimenta pe cheltuiala proprie.

60
În calculul necesarului de resurse trebuie ținut cont și de configurarea unui mediu de testare/dezvoltare
permanent func țional, chiar dacă mult redus fa ță de cel de produc ție.
Toate componentele solicitate aici trebuie livrate în versiuni care implic ă supo rt din partea
Produc ătorului și drept de upgrade la ultimele versiuni ale acestora (sau, în cazul în care produsul nu mai
este disponibil , la produsele înlocuitoare recomandate de produc ător) pe toat ă perioada de derulare a
Contractului. În principiu, pe p erioada contractului se va realiza cel puțin un upgrade de versiune pe
fiecare component ă software în parte.

3.3.1 Server web

Acesta este nivelul care asigur ă expunerea serviciilor web c ătre utilizatori, precum și balansarea
acestora c ătre nivelul imediat inferior, al serverelor de aplica ție.
Instalarea acestui nivel se va face în ma șini virtuale și nodurile se vor configura pentru a func ționa
activ -activ, cu balansare a înc ărcării.
Serverul web utilizat trebuie s ă fie nativ compatibil cu Serverul de aplic ații utilizat pentru nucleul
func țional al SIMS, menționat la cap. 3.3.2 – în sensul în care serviciile de suport de la produc ător
aferent serverului de aplica ții acoper ă inclusiv aceast ă component ă.

3.3.2 Server de aplica ții

Acesta este nivelul care va g ăzdui logica aplicativ ă a SIMS.
Instalarea acestui nivel se va face în ma șini virtuale și nodurile se vor configura pentru a func ționa
activ -activ, cu balansare a înc ărcării.
După o analiz ă a argumentelor pro și contra diverselor tehnologii, concluzia care se i mpune este c ă nu
trebuie impuse restric ții asupra limbajului / tehnologiei care va fi aleas ă de c ătre cel care va
implementa aplica ția, atât timp cât:
a) aceasta este una dintre cele mai des utilizate în domeniu – Java, .Net , PHP sau Python
b) serverul de aplica ții și serverul web utilizate nu sunt în variant ă open -source, ci sunt de nivel
Enterprise (așa cum sunt acestea definite oficial de c ătre produc ător), oferite împreun ă cu
serviciile profesionale aferente de la produc ătorul acestora
c) are capabilit ăți de Management și monitorizare avansate, inclusiv:
a. facilitarea ciclului de dezvoltare și deployment , cu suport complet pentru continuous
delivery, inclusiv integrare cu Chef, Docker, Jenkins, Bamboo
b. caching
c. audit avansat
d. gesti une fină a sarcinilor asincrone ( job-uri)
e. posibilitatea de analiz ă a sursei problemelor prin analiza cauza -efect a
comportamentului codului la rulare
f. analiza cererilor aplicative reale per URL
d) func ționeaz ă în configura ții de înalt ă disponibilitate cu balansarea înc ărcării (inclusiv sessi on
clustering)

61
e) include mediu integrat și unelte de debugging proprii, optimizate .
Componenta de monitorizare livrat ă va trebuie s ă dispun ă de un conector / plu ggin pentru serverul
de aplica ții, care s ă poat ă colecta diverse metrici ale acestuia și informaț ii legate de el, inclusiv
evenimente le serverului de aplica ții, starea cluster -ului, notific ări, alerte și evenimente de audit, etc.
Suportul oferit de produc ătorul serverului de aplica ții trebuie s ă includ ă tot peisajul tehnologic
software asociat, inclusiv serverul web și baza de date. Serverul de aplica ții trebuie s ă fie suportat pe
tehnologia de virtualizare propus ă.
Pentru a putea sus ține sute de mii de sesiuni simultane în condi ții decente de performan țe, licența
oferit ă trebuie s ă permit ă lucrul în condi ții de vârf pe minim 700 de nuclee fizice active distribuite
nevoilor SIMS dup ă necesitate , dinamic , între cele dou ă centre de date , fără limit ă de num ăr utilizatori .
Se vor num ăra aici nucleele alocate exclusiv serverului de aplica ții propriu -zis (fără a contoriza aici
serverele web , balansoarele software sau alte componente auxiliare).

3.3.3 Formulare web

Acest nivel va implementa formularele web utilizate în diverse procese de colectare date sau fluxuri
de lucru.

3.3.4 Raportare operativ ă

Acesta este nivelul tehnologic pe baza c ăruia se vor implementa rapoartele operative din cadrul
aplica ției.
În principiu, acesta va func ționa pe datele din baza de date operativ ă, pentru a oferi o imagine cât mai
exact ă. Totu și, unele dintre rapoarte mai complexe pot fi rulate peste data lake pentru a desc ărca baza
de date operativ ă.

3.3.5 Baza de date operativ ă

Aici se vor g ăzdui principalele depozite de date ale solu ției integrate ca baze de date rela ționale OLTP.
Instalare a acestui nivel se va face în fiecare site pe o ferm ă de minim patru ma șini fizice dedicate, f ără
virtualizare.
În mod normal, fiecare centru de date va deservi jum ătate din teritoriul na țional, drept pentru care se
vor implementa mecanismele de replicare între cele dou ă locații care s ă asigure preluarea activit ății
între ele în caz de necesitate, cu un RPO de maxim 15 minute, cu excep ția tranzac țiilor simple SIMS
unde RPO acceptat este de maxim 5 minute.
Baza de date va fi una rel ațional ă orientat ă obiect și trebuie oferit ă în versiune tip Enterprise (maximul
de func ționalitate disponibil ă), cu suport de la produc ător pe toat ă durata proiectului. Licen ța oferit ă
trebuie s ă fie de tip perpetuu, în sensul c ă produsul de baz ă de date va putea fi folosit în continuare
ca depozit de date pentru SIMS, cu toate caracteristicile sale tehnice ini țiale, și dup ă expirarea

62
perioadei de suport. În acest sens licen ța oferit ă trebuie s ă acopere minim 384 nuclee fizice cu acela și
produs / edi ție, perpetuu și fără limit ă de num ăr utilizatori .
Solu ția de baz ă de date în arhitectura ofertată trebuie s ă poat ă fi configurat ă în așa fel încât înc ărcarea
generat ă de aplica ții pe baza de date s ă fie cât mai judicios distribuit ă pe toate serverele de baz ă de
date, cu posibilitatea de a redistribui înc ărcarea între serverele de baz ă de date active pentru a
optimiza timpul de r ăspuns pe anumite servicii func ționale.
Infrastructura aferent ă bazei de date trebuie dimensionată astfel încât, chiar și în cazul de fectării câte
unui server fizic în fiecare centru de date , solu ția de baza de date trebuie s ă poat ă continua să lucreze
în continuare pe minim 384 de nuclee fizice. Toate serverele care opereaz ă baza de date trebuie s ă fie
identice pentru a facilita admini strarea și flexibilitatea solu ției.
Solu ția de baz ă de date oferit ă trebuie s ă fie integrat ă nativ cu solu ția de big data propus ă, astfel încât
să poat ă desc ărca datele mai vechi de 3-4 ani în clusterul de big data, de unde s ă poat ă fi accesate la
citire în mod transparent, ca și cum ar fi stocate local în baza de date rela țional ă.
Pentru a putea sprijini dezvoltarea și administrarea SIMS, baza de date oferit ă trebuie s ă ofere un
maxim de func ționalitate, la nivelul unei edi ții Enter prise (a șa cum este aceasta definit ă oficial de c ătre
produc ător) incluzând aici:
 Caracteristici și compatibilitate maxim ă SQL 2011
o DROP s ă poat ă func ționa cu CASCADE ; la fel și TRUNCATE , inclusiv în cadrul unei
tranzac ții (cu posibilitate de roll -back)
o Posibilitatea de a ini țializa valoril e DEFAULT atât prin elemente statice cât și prin
expresii și func ții multiple, variate
o Utilizare larg ă a verific ărilor uzuale de coeren ța a datelor (constraints), inclusiv
utilizarea direct ă și nemijlocit ă a condi ției CHECK direct pe tabela în cauz ă fără
modificarea declara țiilor și fără intermedierea altor opera țiuni suplimenta re de tip
trigger sau vedere care pot afecta negativ performan ța
o Capabilit ăți largi, inclusiv FULL OUTER JOIN, INTERSECT, EXCEPT ,
o Interogare ie rarhic ă, inclusiv CONNECT BY nativ
o CTE (common table expression)
o Tipuri de date avansate, inclusiv boolean , array , interval, enumer ări și valori com puse,
precum și posibilitate de a defini noi tipuri de date dup ă necesit ăți
 Implementa re intrinsec ă conform ă ACID, indiferent de motorul de stocare
 Caracteristici generoase XML, NoSQL și obiectuale ( abstract data type sau echivalent ,
moștenire de tabele – table inheritance)
 Replicare Master -Slave -Slave în cascad ă și replicare Multi -Master , cu posibilitatea rezol vării
conflictelor și filtrării și valid ării datelor , între toate bazele de date ale solu ției
 Capabilitate nativ ă de replicare a datelor din baze de date externe Oracle și SQL Server
 Indexare flexibil ă cât mai eficient ă, inclusiv indec și par țiali, b-tree, hash , text integral și pe
expresii, cu reorganizarea de index online
 Implementa re nativ ă de Interogare paralel ă (parallel querry support cu paralelizare pe indec și,
bitmap heap, merge joins, etc.)
 Parti ționare
 Vederi materializate
 Posibilitatea de a utiliza cel puțin două limbaje pentru proceduri stocate:
o cel puțin un limbaj propriu cu caracteristici foarte puternice legate de baza de date

63
o cel puțin un limbaj generic, de larg ă răspândire, cum ar fi Java sau Python, accesibil
unei ma se mari de dezvoltatori
 Toate f uncționalit ățile avansate de gestiune, monitorizare , reglare fin ă și optimizare a frazelor
SQL disponibile la produc ător
 Capabilit ăți native de salvare și restaurare, inclusiv incremental backup și definirea politicii de
retenție
 Unelte de Management cu profilarea interog ărilor, tablouri de bord navigabile (inclusiv analiz ă
pe perioade – zoom – sau detaliere în profunzime a datelor – drill-down) legate de statisticile
de utilizare a bazei de date, editor SQL propriu integrat c u exemplificarea planului de execu ție

Baza de date trebuie s ă se integreze cu solu ția de monitorizare livrat ă, ca și cu cea de backup .
Nucleul aplicativ SIMS, g ăzduit în principal pe componentele de mai sus, trebuie poat ă susține
procesarea a 6000 de tranzacții simple pe secund ă cu un timp de r ăspuns mai mic de 2 secunde
(incluzând aici doar interog ări și rapoarte opera ționale foarte simple) .

3.3.6 API Gateway / Integrare aplica ții

Acesta este nivelul care va g ăzdui logica de integrare aplicativ ă a SIMS și va securiza accesul unor ter țe
părți la interfe țele aplicative ale SIMS. La acest nivel se vor implementa toate interfe țele standard
expuse de SIM S. Tot la acest nivel se vor rezolva interfe țele cu alte sisteme externe.
Instalarea acestui nivel se va fac e în ma șini virtuale și nodurile se vor configura pentru a func ționa
activ -activ , cu balansare a înc ărcării, astfel încât s ă poat ă susține minim 10 000 de tranzac ții pe
secund ă în condi ții de vârf . Elementele propriu -zise de API Gateway trebuie s ă fie astfel licen țiate pe
minim 128 de nuclee fizice , pentru a putea scala în caz de nevoie, perpetuu și fără limit ă de num ăr
utilizatori.
Se va audita atent orice acces și se vor putea realiza analize diverse despre utilizarea API -urilor expuse,
Solu ție de Integrare aplica ții / API Gateway care se va implementa va trebui s ă aibă minim urm ătoarele
capabilit ăți:
 Expune procese, date și servicii c ătre exteriorul sistemului ca API, asigurând controlul, încrederea,
securitatea și reglementarea API-urilor
 Asigu ră crearea, publicarea, Management ul ciclului de via ță, versionarea, guvernan ța și
securitatea API -urilor
 Dispune de interfa ță Web pentru dezvoltatori pentru deployment -ul și monitorizarea API -urilor și
o interfa ță prietenoas ă pentru consumatori pentru abo narea, descoperirea și consumarea API –
urilor
 Include API Gateway pentru securizarea, protec ția, Management ul și scalarea apelurilor API –
urilor. Asigur ă interceptarea cererilor API, aplicarea politicilor de regularizare trafic și securitate și
în urma valid ării, trimite apelurile de servicii web c ătre back -end.
 Include capabilit ăți de monitorizare și analiz ă care asigur ă furnizarea de rapoarte, statistici și
grafice referitoare la API -uri și permite configurarea de alerte pentru monitorizarea API -urilo r și
detectarea comportamentului neobi șnuit.
 Include func ționalit ăți de baz ă de tip magistral ă de servicii (ESB) în leg ătură cu apelurile API.
 Asigur ă cel puțin următoarele stadii în cadrul ciclului de via ță al API -urilor:

64
o CREAT: Metadatele API -ului sunt a dăugate în API Store, dar nu este instalat în API
Gateway, nefiind astfel vizibil c ătre abona ți în API Store.
o PROTOTIP: API-ul este instalat și publicat în API Store ca și prototip. Un prototip de API
este de obicei f ăcut public c ătre public pentru testar e. Utilizatorii pot invoca API -ul fără a
fi abona ți.
o PUBLICAT: API -ul este vizibil în API Store și este disponibil pentru abonare.
o DEPRECIAT: Când API -ul este depreciat nu mai permite noi abona ți, dar este în continuare
disponibil în API Gateway pentru abona ții existen ți, care îl pot utiliza pân ă va fi retras.
o RETRAS: API -ul este retras din API Gateway și șters din API Store.
o BLOCAT: Accesul la API este blocat temporar. Apelurile c ătre API sunt blocate și API -ul nu
mai este prezentat în API Store.
 Permite limitarea num ărului de apeluri c ătre un API într -o anumit ă perioad ă de timp, pentru
situa ții speciale, incluzând aici:
o Protejarea API -urilor în cazul atacurilor de tip Denial of Service (DoS)
o Regularizarea traficului în func ție de infrastructura d isponibil ă
o Accesarea API -urilor la diferite niveluri de serviciu
 Permite ca orice document asociat cu un API s ă aibă aceea și vizibilitate ca și API -ul
 Asigur ă management ul API -urilor de tip REST, SOAP și WebSocket.
 Asigur ă expunerea backend -urilor de tip S OAP ca REST API.
 Asigur ă securizarea API -urilor publicate în API Gateway prin folosirea standardului OAuth2.0.
 Permite configurarea de multiple API Gateway ce public ă într-un singur API Store în cazul în care
este necesar ă balansarea înc ărcării
 Asigur ă utilizarea de func ții multiple pentru resursele unui API, incluzând aici HTTP GET, POST, PUT
și DELETE
 Asigur ă suport pentru o gam ă variat ă de endpoint -uri, permițând API Gateway s ă se conecteze cu
tipuri avansate de backend, cum ar fi: HTTP endpoints , URL endpoints , WSDL endpoints , Failover
endpoints , Load -balanced endpoints .
 Asigur ă func ționalit ăți de API Management tip multi -chiria ș (multi -tenant ) care permit asigurarea
vizibilit ății și a disponibilit ății pentru abonare, astfel:
o Permite utilizatorilor s ă controleze vizibilitatea API -urilor printr -una din urm ătoarele
opțiuni:
 Public
 Restric ționat în func ție de rol
 Vizibil în domeniu meu
o Asigur ă disponibilitatea abon ării printr -una din urm ătoarele op țiuni:
 Disponibil pentru tenant -ul curent
 Disponibil pentru to ți tenan ții
 Disponibil pentru anumi ți tenan ți
 Asigur ă func ționalitatea Forget -Me pentru eliminarea de c ătre administrator a identit ății un ui
utilizator extern la cererea acestuia conform cerin țelor GDPR

65
3.3.7 Identificare și Autentificare utilizatori

Acesta este nivelul care va g ăzdui directoarele de utilizatori și logica de autentificare a acestora pentru
toate componentele SIMS în regim de Single Sign -On.
Data fiind importan ța asigur ării unui grad ridicat de securitate a accesului la informa țiile vehiculate
prin intermediul sistemului informatic, este esen țială utilizarea unor solu ții avansate de control al
accesului, administrare unitar ă a conturilor de utilizator și stocare sigur ă a pofilelor.
La acest nivel se va implementa și serviciul de Autentificare delegat ă care va putea fi expus c ătre
sisteme externe. S erviciul expus extern se va izola de cel propriu Nucleului aplicativ de Catalog pentru
a nu se afecta reciproc în cazul unor probleme – master va fi Nucleul aplicativ de Catalog .
Serviciul va trebui s ă implementeze toate nivelurile de Autentificare descris e anterior (cap.3.2 .4) și va
audita atent orice acces.
Solu ția de identificare și autentificare va asigura îndeplinirea urm ătoarelor cerin țe:
 Să permit ă vizitatorilor s ă devin ă utilizatori prin completarea unui formular de înregistrare.
Înregistrarea efect ivă a utilizatorilor se va putea realiza doar cu autorizarea unui administrator al
aplica țiilor, dup ă îndeplinirea formalit ăților administrative (de exemplu accesul p ărinților la datele
elevilor se va putea acorda doar dup ă validarea calit ății părintelui de către secretariatul școlii).
 Să asigure autentificarea utilizatorilor prin urm ătoarele metode:
o prin username plus parola, OTP și certificat digital
o prin folosirea tehnologiilor de Firewall/VPN
o folosind interfa ța și mecanismele proprii sistemului.
 Administrarea informa țiilor despre utilizatori și datele de autentificare ale acestora va putea fi
realizat ă prin intermediul modulului de administrare inclus în solu ție, accesibil de c ătre
Administratori prin interfa ța Web a solu ției;
 Să permit ă utilizato rilor s ă acceseze anumite func ționalit ăți disponibile în cadrul sistemului în
func ție de matricea de drepturi ata șată profilului acestora. Drepturile se pot da atât individual, c ât
și la nivel de grup. Utilizatorii, pot apar ține mai multor grupuri, iar dre pturile lor constau în suma
dintre drepturile individuale și cele de grup. În func ție de drepturile utilizatorilor, fiecare dintre
aceștia va accesa o anumita configura ție de meniu , cea la care are dreptul, și va putea efectua
opera țiuni doar pentru opera țiunile la care are drept.
 Să asigure administrarea unitara a conturilor de utilizator:
o Înregistrarea utilizatorilor
o Administrarea p rofilelor de utilizatori prin interfa ță web
o Integrarea în solu ție fără a necesita agen ți sau mecanisme intrusive
 Să asigure s tocarea configura țiilor și a politicilor de acces la resursele web în baza de date a
sistemului, f ără a exista nevoia unui depozitar proprietar de date
 Toate politicile de control al accesului trebuie să poat ă fi definite utilizând interfa ța web a solu ției,
fără a necesita cuno ștințe de programare sau rularea de scripturi pe server
 Să ofere control al accesului bazat pe roluri, în combina ție cu al ți factori precum moment ul de
realizare a cererii de conectare, adresa de re țea de unde provine cererea, grupul din care face
parte utilizatorul și orice alt atribut din profilul acestuia (inclusiv atribute special definite, ne –
standard)

66
 Nivelul de auditare trebuie să fie configurabil (succes, nereu șită etc.)
 Să poat ă realiza criptarea informa ției transferat ă între componentele sistemului și clien ți (HTTPS)
 Solu ția de control acces să fie integrat ă cu solu ția de stocare a profilelor utilizatorilor și cu cea de
administrare unitar ă
 Solu ția de control acces să poat ă fi implementată printr -un server central de cont rol acces, care
prelucreaz ă cererile de autentificare, autorizare și auditare
 Să asigure integrarea cu serverele web de tip proxy pentru blocarea tentativelor de acces la
resursele protejate; poate proteja unele resurse web din interiorul sistemului de acc esul direct din
exterior, orice acces la acestea realizându -se prin intermediul serverelor web proxy .
Instalarea acestui nivel se va face în ma șini virtuale și nodurile se vor configura pentru a func ționa
activ -activ, cu balansare a înc ărcării, astfel încâ t să poat ă susține minim 10 000 de tranzac ții pe
secund ă în condi ții de vârf. Elementele propriu -zise de Server de Identitate / Autentificare trebuie s ă
fie astfel licen țiate pe minim 128 de nuclee fizice , pentru a putea scala în caz de nevoie, perpetuu și
fără limit ă de num ăr utilizatori.

3.3.8 Time stamping / PKI

Acesta este nivelul care va implementa Autoritatea de Certificare proprie, pentru semnarea avansat ă
și calificat ă / eIDAS aferente tranzac țiilor SIMS .
Va exista un nivel aplicativ și unul realizat î n echipamente hardware, pentru a asigura performan ța și
a putea gestiona certificatele calificate și cele de root / CA în condi țiile de securitate necesare.
În fiecare centru de date se vor livra cel pu țin câte dou ă echipamente de tip HSM (hardware securit y
module) de re țea, certificate FIPS 140 Level 3, care s ă îndeplineasc ă mai multe func ții:
 Să protejeze cheile private corespunz ătoare unor certificate digitale critice, cum ar fi
certificatele locale de tip root ale PKI pentru semnarea avansat ă
 Să găzduiasc ă în mediu certificat FI PS cheile private ale certificatel or calificate
corespunz ătoare sistemului central
 Să asigure suportul de procesare criptografic ă pentru aplic area sigiliu lui temporar asupra
tuturor documente lor semnate de persoane fizice
 Să asigure suportul de procesare criptografic ă pentru aplic area de semn ătura calificat ă acelor
documente care nu sunt semnate de indivizi
 Să gestioneze securizat cheile de criptare ale altor sub -sisteme SIMS, acolo unde este cazul .
Modulul acesta va realiza c âteva func ționalit ăți principale:
 Va func ționa ca Autoritate proprie de certificate pentru func ționari / profesori, putând emite
certificate avansate în condi ții de securitate înalt ă (cheile private corespunz ătoare
certificatelor locale de tip root ale PKI se vor putea implementa și în module dedicate de tip
HSM neconectate la re țea, care vor fi în acest caz livrate suplimenta r față de cele de re țea
solicitate în configura ția minim ă, obligatorie)
 Va putea aplica semn ătură avansat ă în numele titu larilor de certificate avansate, autentificând
autorizarea acestora online prin mecanisme de tip OTP – cu pre -vizualizarea document ului de
semnat și post -vizualizarea document ului semnat de c ătre persoana care semneaz ă

67
 Va func ționa complet independent de c elelalte componente SIMS, cu excep ția unei integr ări
la nivel de identitate pentru sincronizare de identitate – autentificarea trebuie s ă se fac ă cu
mecanisme two factor proprii modului de semnare, pentru a garanta caracterul de semn ătură
avansat ă
 Va trebui s ă ating ă performan ța necesar ă:
o minim 1000 de semn ături pe secund ă (RSA, cu cheie de 2048bit ) realizate în mediul
securizat HSM per echipament HSM
o minim 500 de semn ături avansate pe secund ă, având în vedere întreg procesul de
semnare (autentificarea semnatarului prin mecanisme proprii – afișare document –
autorizarea semn ării de c ătre semnatar prin OTP – semnare propriu -zisă în back -end
– afișare document semnat în aceea și sesiune – time stamping de c ătre sistemul
central – validare explicit ă de către semnatar – trimitere c ătre arhiv ă)
Oferta va trebui s ă argumenteze performan ța solu ției propuse – aceasta va avea o
amprent ă total ă de minim 48 cores calculat ă la nivelul componentel or efectiv active în
procesul de semnare, cu posibilitate de distribu ție dinamic ă între centrele de date .
 Va expune c ătre Arhiv ă un API necesar opera țiunilor de semnare în procesele aferente
 Va implementa efectiv apelurile necesare semn ării, ca un black -box pentru arhiv ă – rezultatul
API-ului trebuie s ă fie document ul semnat sau cod de eroare indicând motivul e șecului
 Se vor implementa inclusiv cazurile de semn ătură multipl ă (de exemplu profesori + secretar
șef + director) sau alternativ ă (de exemplu director sau director adjunct).

Chiar dac ă va trebui f ăcută o integrare la nivel de înrolare de identitate cu celelalte sisteme, solu ția de
semnare avansat ă trebuie s ă includ ă propria solu ție de autentificare a utilizatorului, cel puțin la nivelul
unui OTP propriu. Datele despre identitatea utilizatorului care tre buie s ă semneze un document nu se
vor transmite explicit, ci ele trebuie extrase implicit din interiorul document ului, prin analiza
conținutului acestuia și a meta -datelor asociate, pentru a asigura leg ătura între semnatar și document .
În cazul în care per soana autorizat ă să semneze calificat un document nu este disponibil ă, modulul de
Arhiv ă va prevedea posibilitatea de semnare temporar ă de către un înlocuitor cu semn ătură avansat ă,
fluxul a șteptând semnarea calificat ă la moment ul în care persoana devine d isponibil ă (exemplu tipic
– secretarul șef al unei școli, care poate fi suplinit temporar de un alt secretar). Înlocuitorii vor fi
gestiona ți în cadrul acestui modul, prin declarare la înrolare și posibilitate de schimbare ulterioar ă. Nu
va exista posibili tatea de înlocuire decât pentru sem ănarea calificat ă, nu și pentru cea avansat ă.

3.3.9 Management documente

Aceasta este platforma care va constitui baza tehnologic ă pentru func ționalit ățile aferente cap. 3.2.2
și 3.2.3, precum și pentru alte elemente legate de fluxuri de lucru.
Pentru a asigura fiabilitatea solu ției, platforma software de Management documente oferit ă trebuie
să fie un produs de tip comercial care s ă permit ă implementa rea func ționalit ăților dorite nu prin
dezvoltare software extensiv ă, ci prin configur ări / personaliz ări ale unor capabilit ăți pre -existente în
moment ul ofert ării.

68
Platforma software trebuie s ă dispun ă de o arhitectur ă multi -tenant ce permite parti ționarea virtual ă
a datelor și configura ției, astfel încât fiecare instan ță a aplica ției să lucreze ca o instan ță virtual ă, dac ă
este cazul.
Platforma software trebuie să fie licen țiată atât pentru mediul productiv cât și pentru mediul de test.
Platforma software trebuie să suporte testare automat ă fără impact pe mediul productiv .
În principiu platforma va fi utilizat ă prin intermediul API -urilor, ca serviciu de back -end de c ătre
Nucleul aplicativ. Totu și, anumite procese sau fluxuri de lucru, cu exemplul notabil al evalu ării
Naționale și Bacalaureat , vor putea necesita accesul utilizatorilor în num ăr mare direct în arhiv ă, ceea
ce poate genera o înc ărcare apreciabil ă. Astfel, i nstalarea acestui nivel se va face în ma șini virtuale și
nodurile se vor configura pentru a func ționa activ -activ, cu balansare a înc ărcării, astfel încât să poat ă
susține minim 5 000 de tranzac ții pe secund ă în condi ții de vârf. Toate c omponentele sale esen țiale
trebuie s ă fie astfel fiecare licen țiate pe minim 128 de nuclee fizice , pentru a putea scala în caz de
nevoie, perpetuu și fără limit ă de num ăr utilizatori. În principiu, platforma se va putea instala ca activ ă
într-un singur centr u de date, cu posibilitatea comut ării rapide pe cel ălalt centru de date – se va
asigura replicarea continu ă a datelor și documente lor aferente, cu RPO de maxim 5 minute pe ntru
documente le semnate calificat de persoane individuale; documente le semnate avansat sau de c ătre
sistem pot avea un RPO de pân ă la 6 ore. Platforma trebuie s ă fie proiectat ă în așa fel încât, la nevoie
serviciul de Arhiv ă să poat ă func ționa distinct de cel de Evaluare Na țional ă și Bacalaureat , în centre de
date diferite.
Caracteristic i minimale generale:
 Se va realizarea integrarea Single Sign -On cu celelalte componente ale solu ției SIMS, astfel încât
utilizatorii s ă nu fie nevoi ți să se re -autentifice
 Platforma software va permite aplicarea de marc ă temporar ă și semn ătură electronic ă direct în
cadrul sistemului
 Ca și client acces platforma software trebuie să fie de tip web și să func ționeze cel pu țin pe
browserele Mozilla, Chrome, Edge și pe sistemele de operare Android și iOS
 Platforma software trebuie s ă permit ă integrarea cu alte sisteme pentru upload/download fișiere ,
transmiterea și recep ționarea de informa ții prin API, Web Service și batch import fișiere și
metadate
 Va con ține o com ponent ă care va realiza o conversie automat ă a con ținutului înc ărcat în formate
web (HTML, PDF), pentru o vizualizare facil ă a acestora direct în browser;
 Va permite rularea pe distribu țiile majore de sisteme de operare prezente pe piață , cel puțin
Windows și Linux
 Va include o componenta de tip portal pentru accesarea documente lor / imaginilor / înregistr ărilor
 Platforma software de Management al documente lor va include cel puțin următoarele module,
dezvoltate de acela și produc ător sau proiectate și integrate nativ pentru func ționare a împreun ă
în cadrul acela și sistem:
a) Arhivare electronic ă
b) Captura documente
c) Fluxuri de lucru
d) Registratur ă electronic ă
e) Management arhiv ă fizică de documente

69
3.3.9.1 Modul arhivare electronic ă

Modulul de arhivare electronic ă a documente lor va îndeplini cerin țele detaliate în continuare:
 să ofere un model de date în care con ținutul unui document și metadatele asociate formeaz ă
un obiect de un anumit tip;
 să ofere mecanisme de securitate bazate pe grupuri, roluri, utilizatori, func ții din organigram ă.
Nu trebuie să existe limitare privind num ărul de grupuri ce poate fi definit la nivelul depozitului
de documente . Drepturile de securitate și permisiunile trebu ie să fie special proiectate astfel
încât să permit ă controlarea accesului utilizatorilor la documente și tipul drepturilor de acces;
 să permit ă sincronizarea automat ă între grupurile func ționale din arhiva electronic ă și
grupurile de utilizatori definite în sistem
 să ofere acces c ătre mai multe arhive individuale pentru acela și utilizator; s ă ofere
posibilitatea desemn ării rela ției pe care o are fiecare utilizator în raport cu celelalte arhive
gestionate, inclusiv rolul general pe care acel utilizator îl are pentru fiecare astfel de arhiv ă
(este administrator sau este utilizator normal);
 să ofere posibilitatea organiz ării utilizatorilor în grupuri; un utilizator poate face parte din unul
sau mai multe grupuri; permisiunile de securitate trebuie să se asoci eze cu grupurile de
utilizatori (aplicând -se tuturor utilizatorilor membri ai acelui grup la moment ul de timp al
controlului accesului);
 permisiunile de securitate să se desemneze prin “clase de permisiuni”; o cla să de permisiuni
să dispun ă de un nume și să poat ă fi asociat ă unui set de grupuri, roluri, tipuri de documente
gestionate, Meniu ri de acces la aplica ție, acces la registre de documente
 să permit ă stabilirea nivelului de autorizare pe care utilizatorul îl are alocat în cadrul arhivei,
cel pu țin: ci tire, scriere, complet, vizualizare doar fi șa document fără posibilitate de vizualizare
conținut, cu recursivitate sau nu.
 clasa de permisiuni trebuie să poat ă oferi unui grup de utilizatori unul din nivelurile principale
de acces c ătre un document :
o acces la vizualizarea fi șei de documente dar f ără acces la con ținutul efectiv al
document ului,
o acces la vizualizarea atât a fi șei de document cât și la con ținutul electronic al
document ului,
o acces la vizualizarea atât a fi șei de document cât și la con ținutul electronic al
document ului cu posibilitatea de modificare a datelor din fi șa de date a document ului,
o acces la vizualizarea atât a fi șei de document cât și la con ținutul electronic al
document ului cu posibilitatea de modificarea datelor din fi șa de date a document ului sau
ștergere document
 utilizatorii trebuie să poat ă avea acces la documente le din arhivele electronice în
conformitate cu rolul asociat acestora și cu drepturile de acces înregistrate de c ătre
administratorul arhivei. Func țiile utili zate de c ătre utilizatorii sistemului trebuie să fie cel
puțin :
o administrare: pentru monitorizarea proceselor și informa țiilor legate de
administrarea arhivei,
o căutarea și vizualizarea: pentru c ăutarea documente lor în arhiva electronic ă;

70
 să permit ă definirea de colec ții de documente ce con țin documente grupate din arhiv ă după
diverse criterii, cu scopul de a oferi acces temporar unui set de utilizatori ale și ad-hoc
 să permit ă arhivarea oric ăror tipuri de documente indiferent de tipul de fi șier în care este
stocat
 utilizatorii trebuie să fie defini ți de c ătre operatorii autoriza ți ai administratorului de arhiv ă,
operatori ce au la rândul lor rolul de utilizator administrator tehnic al arhivei
 să ofere func ții de realizare a conformit ății cu standardu l GDPR cum ar fi dar f ără a se limita
la: pseudomizare, anonimizare, scopul prelu ării, nivel de securitate, categorii de date din
punct de vedere GDP, audit la nivel de record
 nu trebuie să se impun ă limit ări asupra num ărului de documente și metadate stocate sau
asupra capacita ții de stocare pe care o poate gestiona;
 să dispun ă de interfe țe de c ăutare în arhiv ă și administrare arhiv ă accesibile din browser: cel
puțin Edge , Chrome și Mozilla Firefox ;
 să ofere posibilitatea de salvare și reutilizare a se turilor de criterii de c ăutare avansat ă în
arhiv ă;
 să permit ă opera țiuni de download bulk pe baza seturilor de c ăutare salvate
 Să pună la dispozi ția utilizatorilor toate func țiile platformei prin intermediul unui client web
de tip ”out -of-the box”.
 să perm ită procesarea și afișarea în aceea și structur ă de documente atât a documente lor
electronice clasice ( în format scanat) c ât și a fișierelor de tip Electronic Data Interchange (EDI)
 să permit ă adăugarea de documente electronice printr -un mecanism de tip ”drag -and-drop”
în clientul web.
 să permit ă organizarea documente lor într -o structura ierarhic ă intuitiv ă. Aceast ă organizare
ierarhic ă va fi prezentat ă într-o structur ă arborescent ă, similar ă sistemelor de fi șiere
comune/obi șnuite. Documente le trebuie s ă poat ă fi organizate în structuri care s ă simuleze
modalitatea real ă de organizare în dosare și fișete.
 să permit ă importul automat în arhiva electronic ă a fișierelor existente de pe suport de
stocare electronic, organ izat în foldere și subfoldere împreuna cu fi șiere excel asociate care să
conțină tipul documente lor și valorile metadatelor pentru fiecare fi șier
 să permit ă importul automat în arhiva electronic ă a fișierelor de tip EDI (Electronic Data
Interchange) cel puțin din formatele: XML, iDOC, CSV, XML/EDIFACT conform ISO TS 20625,
cu setarea de layouturi configurabile pentru fiecare tip de document EDI
 să ofere posibilitatea de organizare a documente lor pe dosare (foldere)
 să permit ă definirea de criterii de indexare suplimenta re a documente lor, chiar dac ă fizic sunt
stocate în foldere diferite.
 să permit ă definirea de “liste filtrate” de documente , vizibile pentru utilizator ca ni ște foldere,
prin specificarea parametrilor utiliza ți la filtrare (exemplu: documente de un anumit tip, cu o
anumita valoare într -un câmp de indexare sau create de un anumit utilizator) și a modului de
afișare a rezultatelor (grupate dup ă un an, sau dup ă orice alt câmp, de exemplu);
 “Listele filtrate” pot fi generale, accesibile pentru to ți utilizatorii sau specifice numai unui
anumit utilizator/ grup de utilizatori și pot fi numite sugestiv (ex. „foi matricole 2015”;
 să ofere posibilitatea stoc ării documente lor într -un spa țiu centralizat și organizat și
posibilitatea de a asocia metadate pentru fiecare document în parte

71
 să permit ă administratorilor definirea de volume de stocare a documente lor (loca ții fizice în
care vor fi salvate documente le în sistem, pe medii diferite), precum și posibilitatea de a se
conecta la unul sau mai multe „Depozite de stocare”, în func ție de drepturile pe care ace știa
le au.
 să permit ă administratorului configurarea atributelor (câmpuri de date) fiec ărui tip de
document prin utilizarea unei interfe țe prietenoase de tip web, fără a fi nevoie de interven ție
în codul aplica ției.
 să permit ă administratorului s ă defineasc ă un set general de atribute la nivelul organiza ției
din care se vor alege ce atribute s ă apar ă pe fiecare tip de document
 să permit ă opera ții multiple executat e asupra documente lor:
o versionarea automat ă a documente lor, permi țând p ăstrarea tuturor versiunilor prin
care trece un document / înregistrare;
o check -out/ check -in, pentru asigurarea modific ării coerent ă a documente lor (în lucrul
colaborativ); un document aflat în statusul de “check -out” (în editare), va r ămâne în
continuare vizibil pentru ceilal ți utilizatori, doar în mod vizualizare (read -only);
o etichetarea fiec ărei versiuni, pentru a permite utilizatorilor să identifice facil
versiunea c ăutată;
o “Roll back”, adic ă de revenire la o versiune anterioar ă;
o posibilitatea de anexare la document ul ini țial și a altor documente ;
o indexarea automat ă a documente lor;
 În ceea ce prive ște prelucrarea documente lor pe tipuri de documente și metadate specifice
aces tor tipuri, permite:
o arhivarea documente lor în func ție de termen ele de p ăstrare și tipurile de documente
o definirea tipurilor de documente permise pentru fiecare flux de lucru;
o să se poat ă predefini fluxuri de lucru pentru fiecare tip de document ;
o stocare a și indexarea automat ă a documente lor în foldere/dosare predefinite în
func ție de tipul documente lor;
o indexarea automat ă a documente lor în func ție de departament și tipul document ului;
 să acopere ciclul de via ță al unui document (crearea, modificarea, validarea, aprobarea,
publicarea, arhivarea). În func ție de starea unui document sunt disponibile spre utilizare
diferite ac țiuni asupra documente lor.
 să permit ă implementa rea nomenclator ului arhivistic conform legisla ției.
 să permi tă mutarea documente lor care nu mai sunt active într -un depozit special de arhiv ă,
atunci când utilizatorii definesc acele documente ca fiind bune de arhivat;
 să permit ă definirea de termen e de p ăstrare la salvarea documente lor în concordan ță cu
cerin țele legislative;
 să permit ă arhivarea documente lor în func ție de termen ele de p ăstrare și tipurile de
documente ;
 să poat ă stoca metadatele în cel puțin următoarele sisteme de baze de date rela ționale: Oracle
Database, Microsoft SQL Server, MySQL, DB2 sau echivalente.
 să permit ă urmărirea și trasabilitatea modific ărilor efectuate pe un document .
 modific ările asupra documente lor pot fi realizate numai atunci când un document este scos
(checked out). Un utilizator care a f ăcut check -out pe document va lucra c u acesta, iar dup ă
terminarea acestei activit ăți, prin ac țiunea de check -in, document ului i se va incrementa

72
num ărul versiunii în mod automat, opera ția de check -in putând fi completat ă de comentarii
asupra versiunii.
 să permit ă nativ versionarea documente lor prin func ționalit ăți de tip „Check In – Check Out”.
Formatul de stocare al documente lor electronice trebuie s ă fie cel nativ, astfel se exclude
păstrarea documente lor în formatul propriu sistemului, pentru a asigura recuperarea facil ă a
datelor în caz de defec țiune.
 să asigure salvarea criptata a con ținutului documente lor, folosind algoritmul de criptare AES –
256.
 să permit ă integrarea cu orice server de directory care implementează protocolul LDAP sau
AD, pentru sincronizarea utilizato rilor și autentificarea acestora în sistem;
 să permit ă dezactivarea utilizatorilor și reactivarea ulterioar ă dacă este cazul;
 utilizatorii să fie deconecta ți automat din sistem dup ă o perioad ă în care acesta nu mai e
utilizat;
 să permit ă utilizatorilor int roducerea în arhiv ă a documente lor în regim bulk (mai multe
documente deodat ă) împreun ă cu metadatele de caracterizare aferente;
 să aloce un num ăr unic de înregistrare pentru fiecare nou document intrat în arhiv ă;
 să poat ă aplica automat un set de reguli de securitate, la înc ărcarea documente lor în arhiv ă și
ulterior, în func ție de metadatele document ului;
 utilizatorii să poat ă naviga în cadrul arhivei și în func ție de perspective care să ghideze
utilizatorii dup ă diverse c riterii legate de informa țiile de arhivare: data, metadate specifice
document ului. Perspectivele să poat ă fi definite ad hoc de c ătre utilizatorul arhivei f ără a
dispune de cuno ștințe de programare. Trebuie să nu existe limit ări în ceea ce prive ște num ărul
de perspective și num ărul de niveluri de structurare a datelor în cadrul perspectivelor;
 să permit ă utilizatorilor modificarea metadatelor documente lor electronice din arhiva
opera țional ă direct din interfa ța de utilizare;
 să permit ă popularea arhivei opera ționale utilizând modulul de captur ă documente ;
 să asigure auditarea opera țiilor efectuate, opera țiile de configurare/administrare a auditului
și de consultare a acestuia să se realizeze de c ătre administratori. Informa țiile referi toare la
audit nu pot fi alterate nici m ăcar de administratori f ără a se marca cine a f ăcut acea opera ție.
Trebuie să ofere mecanisme proprii de protecție a informa țiilor de audit;
 utilizatorii să poat ă vizualiza, pentru fiecare document în parte, istoricul modific ărilor, cu
eviden țierea modific ărilor în fiecare nou context;
 să permit ă afișarea unui link de acces pentru fi șa fiec ărui document , link ce poate fi transmis
pe email sau prin alte mijloace de comunicare electronic ă;
 să permit ă transmitere a pe email a document ului direct din interfa ța de acces a arhivei;
 să permit ă selectarea anumitor documente cu care se lucreaz ă frecvent și gruparea lor într -o
zona de documente de tip favorite;
 să dispun ă de interfa ță de vizualizare a detaliilor și desc ărcare a con ținutului fi șierelor zip
(pentru fiecare din fi șierele arhivate într -o arhiv ă format zip);
 să permit ă afișarea direct în browser a documente lor de tip imagine, f ără a fi nevoie de
achizi ționarea de licen țe pentru programe software auxiliare care să fie instalate pe sta ția de
lucru.
 să suporte cel puțin următoarele formate de fi șiere utilizate de c ătre beneficiari: pdf, tiff, jpeg,
bmp, gif, doc, docx, rtf, txt, html.

73
 să permit ă vizualizarea documente lor pe diferite niveluri de zoom, de la ansambl u până la cele
mai mici detalii
 să dispun ă de posibilitatea de a utiliza clien ți de acces, pentru echipamente mobile
(telefoane/tablete), la arhivele gestionate;
 soluția va gestiona și permite accesul utilizatorilor la documente le ce vor fi arhivate de c ătre
beneficiari folosind modulul de captur ă documente
 să ofere posibilitatea de arhivare și expunere a con ținutului arhivat, c ătre orice alt sistem, prin
folosirea standardului CMIS (content Management interoperability services);
 În ceea ce prive ște căutarea, platforma trebuie să asigure:
o căutarea automat ă a documente lor inclusiv dup ă textul con ținut cel puțin pentru:
documente le scanate utilizând OCR, fi șiere de tip Office (Word, Excel), fi șiere PDF și
emailuri;
o salvarea c ăutărilor pentru utilizare ulterioar ă;
o rafinarea rezultatelor unei c ăutări prin filtr ări și ordon ări suplimenta re operate doar
asupra rezultatelor c ăutărilor;
o căutarea rapid ă după valorile din oricare câmp de indexare (metadata), dup ă titlul
document ului și dup ă conținutul acestuia (full text)
o căutări utilizând operatori logici boole eni (”and” și ”or”) și de compara ție ”egal”,
”con ține”, ”mai mic”, ”mai mare”, c ăutări de proximitate (de exemplu sunt c ăutați
doi termen i, condi ția fiind ca între ace știa să nu existe mai mult de 3 cuvinte), etc;
o căutări doar în ultima versiune a documente lor sau în toate versiunile acestora;
o să realizeze un “scoring” al rezultatelor ob ținute în urma opera ției de c ăutare și să
afișeze rezultatele ordonate conform acestui scor ing; Scoring -ul va tine cont de
relevan ța termen ilor de c ăutare dar și de data de creare și accesare a documente lor;
o un mecanism de subliniere a termen ilor dup ă care a fost efectuata c ăutarea, atât în
metadate cât și în interiorul document ului;
o exportarea listei de obiecte rezultat ă în urma opera ției de c ăutare, în formate
standard, cum ar fi csv sau excel;
o definirea de câmpuri care s ă fie văzute în lista de rezultate precum și ordinea acestora,
va permite ordonarea rapid ă a rezultatelor dup ă orice câmp pre cum și gruparea
rezultatelor “on -the-fly”;
o definirea de “liste filtrate” de documente , vizibile pentru utilizator ca ni ște foldere,
prin specificarea parametrilor utiliza ți la filtrare (exemplu: documente de un anumit
tip, cu o anumit ă valoare într -un câmp de indexare sau create de un anumit utilizator)
și a modului de afi șare a rezultatelor (grupate dup ă un an, sau dup ă orice alt câmp,
de exemplu);
o să permit ă exportul con ținutului listelor filtrate în xls sau csv;
 să ofere un cadru int egrat de colaborare pe documente prin scrierea de mesaje de colaborare
pe document adresate anumitor utilizatori și păstrarea istoricului.
 să permit ă integrarea cu alte sisteme informatice, astfel încât s ă schimbe informa ții cu acestea
sub form ă de documen te. Aceast ă func ționalitate prive ște (și) interogarea (la nevoie a)
arhivelor de c ătre organiza ții externe.
 Să dispun ă de integrare nativ ă cu aplica ții Microsoft Office ( în vederea asigur ării
compatibiliz ării cu sistemele utilizate în prezent de ben eficiar ), astfel încât s ă permit ă:
o editarea și/sau salvarea documente lor direct pe server, din repository.

74
o pre-vizualizare (preview) a documente lor direct în interfa ță, fără să fie nevoie s ă se
deschid ă documente le în aplica țiile native asociate, pentru toate tipurile uzuale (PDF,
imagine, Word, Excel, Powerpoint, etc)
o din aplica țiile Microsoft Word și Excel s ă fie posibile urm ătoarele opera ții:
 accesarea depozitului/ depozitelor de documente la care utilizatorii au acces;
 deschiderea documente lor din depozitel e de documente și salvarea
documente lor în depozitele de documente ;
 vizualizarea metadatelor documente lor;
 executarea opera țiunilor de check -in/ check -out;
 compararea versiunilor aceluia și document , prin utilizarea func ționalit ății
“compare” din Microsoft Word
 definirea șabloanelor direct în aplica ția Microsoft Word sau Excel. Astfel, orice
document existent în format Word sau Excel va putea fi transformat în șablon,
prin definirea zonelor în care vor fi pre -completate valorile din metadate.
 înregistrarea direct ă a documente lor și inserarea automat ă a numerelor de
înregistrare și a datei de înregistrare în con ținutul documente lor WORD și
EXCEL.
 Asigur ă o securitate ridicat ă în ceea ce prive ște accesul la documente , astfel:
o accesul la documente le gestionate este posibil exclusiv prin intermediul aplica ției
client și nu prin file -sharing;
o dispune de mecanisme de definire a permisiunilor la nivel de depozit de documente ,
de entitate sau de atribut al entit ății;
o permisiunile care se pot defini sunt: vizualizare date, editare date, ștergere și de
modificare a permisiunilor;
o permisiunile de acces la documente sunt calculate dinamic, în func ție de valorile
metadatelor asociate documente lor
o drepturile de acces se pot gestiona la nivel de container de documente și fișier,
precum și pe tipuri de documente sau pe fiecare atribut de pe tipurile de documente ,
utilizând utilizatori și grupuri de utilizatori.
 să ofere posibilitatea cre ării structurii de date, utilizând o inte rfață grafic ă, astfel:
o definirea de mai multe volume de stocare a documente lor (mai multe loca ții fizice în
care vor fi salvate documente le în sistem, pe medii diferite);
o configurarea facil ă, direct în aplica ție, la nivel de atribut pentru cel puțin următoarele
caracteristici: eticheta afi șată utilizatorilor, tipul de date permis (text, num ăr, data
calendaristic ă, logic = adev ărat sau fals), lungimea permis ă, valoare implicit ă
(exemplu: utilizator curent, data curent ă), lista de valori, formula de calcul f uncție de
alte metadate;
o definirea de c ătre administrator de noi ecrane ale aplica ției mapate pe tipuri de
documente , în care s ă gestioneze diferite formulare, liste, entit ăți organizatorice,
date, rela ții părinte -copil, rela ții cu subpagini mapate pe alte tipuri de documente , pe
care s ă le poat ă publica direct în Meniu l aplica ției pentru utilizatori;
o administrarea șabloanelor folosind categorii de documente , compartimente de
utilizat, dosare, categorii predefinite, metadate și valori pre -completate pentru
metadate;

75
 să permit ă aflarea num ărului de documente gestionat de platform ă precum și a dimensiuni i
acestora prin punerea la dispozi ție a unui set de rapoarte predefinite dintre care:
o situa ție ocupare storage atât per unitate cât și per utilizator,
o documente create sau modificate de c ătre utilizatori într -o anumit ă perioad ă;
 să ofere posibilitatea de a monitoriza și notifica evenimente le astfel:
o monitorizarea fluxurilor de lucru active;
o gene rarea de alerte și notific ări din fluxuri de lucru;
o monitorizarea și generarea de alerte pentru fluxurile de lucru care nu sunt executate
în num ărul de zile stabilit;
o notificare a utilizatorilor privind modific ările ce apar în sistem: a fost creat un nou
document , document ul a ajuns într -un nou stadiu, etc.
o notificarea pe e -mail despre o sarcin ă de efectuat sau neefectuat ă;
 să permit ă auditarea opera țiunilor de login, logout, acces pe foldere, acces pe fi șiere.
Informa țiile de audit vor con ține inclusiv IP -ul de acces, data, ora, utilizatorul și acțiunea
efectuat ă;
 să permit ă păstrarea istoricului activit ății prin intermediul configur ărilor aferente proceselor
precum introducerea documente lor, aprob ări, print ări, etc.
 să permit ă administratorului restaurarea documente lor șterse de c ătre utilizatori.
 să includ ă func ționalit ăți de gestiune a nomenclatoarelor arhivistice, dup ă cum urmeaz ă:
o să permit ă crearea, publicarea și gestionarea de nomenclatoare arhivistice;
o să permit ă modificarea și versionarea nomenclatoarelor existente;
o să permit ă publicarea nomenclatoarelor arhivistice;
o să permit ă exportul de nomenclatoare ;
o să permit ă introducerea de perioade de p ăstrare pentru documente , inclusiv perioada de
păstrare perman entă;
o să permit ă modific ări ale elemente lor componente (ex. entit ăți, tipuri de documente ,
perioade de p ăstrare), pentru versiunile publicate ale nomenclator ului, doar prin crearea
unor versiuni noi.

3.3.9.2 Modul captur ă

Modulul de captur ă a documente lor trebuie s ă dispun ă de urm ătoarele caracteristici:
 să permit ă scanarea documente lor pe hârtie și încărcarea acestora în sistem, utilizând scanarea
local ă sau la distan ță.
 integrare cu modulul de registratur ă permi țând înregistrarea și direc ționarea fi șierelor în timpul
procesului de scanare, c ătre compartimentul de destina ție.
 să permit ă scanarea documente lor format hârtie și obținerea de imagini scanate.
 să permit ă scanarea asincron ă și realizeaz ă legătura fi șierului scanat la informa țiile de
înregist rare în func ție de codul de bare aplicat pe document .
 aplica ția va dispune de capabilitatea de a imprima coduri de bare și numere de înregistrare cu
imprimante de coduri de bare speciale și aplicarea pe documente ;

76
 aplica ția va dispune de capabilitatea de scanare bulk a documente lor și separarea automat ă a
acestora în pdf -uri individuale care vor fi ata șate automat în func ție de codurile de bare aplicate,
la înregistr ările corespunz ătoare
 în timpul opera ției de clasificare, imaginile scanate pot fi combinate într -un document , iar la
sfârșit exportate în format .pdf, înc ărcându -se apoi în sistemul de Management al
documente lor.
 indexarea documente lor electronice va fi realizat ă atunci când imaginile scanate sunt convertite
în documente .pdf în care se pot efectua c ăutări
 să permit ă folosirea de metadescriptori (câmpuri) pentru paginile scanate și nu impune limit ări
cu privire la num ărul acestora.
 realizeaz ă opera țiuni automate de OCR pentru toate fi șierele de tip imagine și PDF. În plus, să
permit ă indexarea și căutarea automat ă a documente lor inclusiv dup ă textul con ținut cel puțin
pentru: documente le scanate utilizând OCR, fi șiere office (Word, Excel), fi șiere PDF și emailuri;
 validarea metadescriptorilor asocia ți la nivel de imagine scanat ă se va realiza automatizat, pe
baza unor reguli de validare, sau manual. În cadrul procesului de validare pot fi incluse referin țe
către sisteme externe.
 să permit ă înregistrarea și rutarea automat ă a documente lor pe flux în timpul proces ului de
scanare c ătre compartimentul de destina ție.
 Fluxuri de scanare multiple și rutarea documente lor pe fluxuri pot fi definite și între ținute vizual,
direct în aplica ție, fără necesitatea de a scrie cod.
 să permit ă pre-vizualizarea (preview) documente lor direct în interfa ță, fără să fie nevoie s ă se
deschid ă documente le în aplica țiile native asociate, pentru toate tipurile uzuale (PDF, imagine,
Word, Excel, Powerpoint, etc);
 să permit ă eliminarea manual ă a datelor de intrare de pân ă la 90% din documente le tip ărite
 să permit ă clasific ări de documente și identificare pe baza formulelor REGEX
 să permit ă validarea manual ă pentru documente le care nu au trecut de extragerea automat ă a
textului și validare a acestuia
 să permit ă extragerea datelor utilizând OCR full text sau OCR pe zone speciale ale
documente lor / zone de document
 să permit ă extragerea direct ă a datelor folosind PDF API
 să permit ă extragerea mixt ă a datelor combinat ă din extragerea de date cu PDF API și
expresia REGEX
 să permit ă indexarea documente lor pentru c ăutare rapid ă și recuperare prin metadate

Modelul de licen țiere oferit trebuie s ă asigure c ă orice utilizator din cadrul organiza ției beneficiarului
va putea beneficia de capabilit ăți de captur ă, astfel încât s ă poat ă fi implicat în activit ățile de Evaluare
Național ă sau similare.

3.3.9.3 Modul registratur ă

Modulul de registratur ă a documente lor trebuie s ă îndeplineasc ă cerin țele detaliate în continuare:
 modulul de registratur ă trebuie să fie integrat cu modulul de arhivare electronic ă;

77
 să permit ă înregistrarea și distribu ția de documente în format electronic;
 să permit ă definirea structurii organiza ționale în forma arborescent ă;
 să permit ă definirea de noi tipuri de entit ăți la nivelul structurii organiza ționale (divizie,
departament , birou, etc);
 să permit ă definirea de registre și registraturi;
 să se poat ă defini utilizatori cu rol de “registrator” din punctele de intrare / ie șire a
documente lor din organiza ție în vederea înregistr ării de documente , cu scopul de a le distribui
în interiorul sau în afara organiza ției;
 înregistrarea document ului va genera ac țiunea de a acorda unui document un num ăr unic de
identificare la nivelul organiza ției, putând fi astfel urm ărit în cadrul organiz ației și în rela ția cu
terții;
 să permit ă ca num ărul de înregistrare să fie acordat automat în moment ul cre ării unui
document în sistem, dac ă este cazul, oferind altfel și posibilitatea de a stoca documente fără
num ăr de înregistrare;
 să permit ă gestionarea centralizat ă și unicitatea numerelor de înregistrare, num ărul unic de
înregistrare se va acorda pe baza unui sistem de numerotare centralizat la nivelul întregii
organiza ții, care se va reseta la începutul fie cărui an calendaristic (dac ă este cazul) și odat ă
alocat un num ăr de înregistrare document ului, acesta să nu mai poate fi modificat de c ătre
nici un utilizator;
 să permit ă crearea și gestionarea de registre de numere, definite de c ătre administrator, care
pot fi de mai multe tipuri și vor deține serii de numere secven țiale care se vor asocia cu tipuri
de documente ;
 să permit ă ca un registru să poat ă fi asociat la mai multe tipuri de documente , iar în acela și
timp un tip de documente să poat ă fi asociat la mai multe registre;
 va gestiona documente de intrare, de ie șire sau informative, oricare dintre acestea put ând fi
trimise c ătre unul sau mai mul ți destinatari;
 să permit ă fiecărui destinatar, pentru documente le ce necesit ă rezolvare, crearea de
răspunsuri la document ul primit și transmite rea acestora c ătre alte unit ăți organiza ționale;
 să se poat ă afișa harta de proces a document ului, care va indica utilizatorii și data la care au
primit document ul pentru a furniza rezolu ții, precum și statusul la fiecare utilizator;
 să permit ă gestionarea de nomenclatoare pentru emiten ții și destinatarii externi;
 un document va fi trecut în starea „finalizat” numai dup ă ce to ți utilizatorii implicati în fluxul
de distribu ție al acelui document vor finaliza document ul;
 utilizatorii trebuie să poat ă regasi documente în cadrul modulului software registratur ă dupa
datele asociate. Numărul de înregistrare, emitent, destinatar, data emitere;
 să permit ă definirea drepturilor de acces la documente astfel încât utilizatorii asocia ți unei
registraturi vor avea acces numai la documente le pe care le -au ini țiat sau le -au fost trimise.
 să ofere posibilitatea de a înregistra automat și a remite expeditorului o recipis ă de confirmare
a recep ției cel puțin cu urm ătoarele elemente : num ărul de înregistrare, data înregistr ării,
conținutul pe scurt, pagina de înregistrare în format PDF care să conțină prima pagina a
documente lor anexate transmise spre înregistrare pe email pe care s -a aplicat în partea de sus
a paginii bonul de înregistrare în for mat electronic.
 să permit ă definirea oric âtor registre configurabile facil de administratorul aplica ției

78
 să permit ă configurarea coloanelor care să apar ă în fiecare registru în func ție de nevoile
specifice ale beneficiarului
 să permit ă copierea automat ă a valorilor de pe metadatel e documente lor înregistrate în
coloanele din registrul în care sunt înregistrate documente le
 să permit ă configurarea coloanelor care să apar ă în fiecare registru cel puțin pentru
următoarele elemente : eticheta multilimba, tip de dată, dimensiune , obligativitate, lista de
valori asociat ă, formula de calcul, valori implicite
 să permit ă configurarea taburilor în care să fie organizate informa țiile în fiecare registru, cel
puțin a urmatoarelor elemente : eticheta multilimb ă, pozi ție, vizibil sau nu
 să permit ă importul și exportul configur ărilor unui registru în format XML
 să permit ă clonarea configur ărilor unui registru

3.3.9.4 Modul fluxuri de lucru

Acesta este modulul care va asigura fluxurile de lucru configurabile din cadrul solu ției, în special cele
aferente cap.3.2 .1.4.6.6 și 3.2.7 .
Platforma de Management a documente lor trebuie s ă includ ă un motor de fluxuri de lucru care asigur ă
capabilitatea de gestiune a proceselor cu documente care s ă permit ă circula ția documente lor pe
trasee ierarhice sau definite de autorul document ului, cu posibilitatea aprob ării sau respingerii
acestora, standardizarea, distribuirea și circula ția informa țiilor și a documente lor interne în cadrul
structurii, precum și a celor generate în rela ția cu autori tăți externe.
Aplica ția include atât instrument ele pentru dezvoltare cât și mediul de rulare pentru proiectarea,
execu ția și monitorizarea fluxurilor de documente .
Modulul de fluxuri de lucru cu documente trebuie s ă asigure urm ătoarele func ționalit ăți:
 să permit ă autorilor de procese definirea și între ținerea vizual ă, direct în aplica ție, a fluxurilor
de lucru aplicabile documente lor înregistrate;
 să permit ă autorilor de procese proiectarea fluxurilor de lucru bazate pe organigrama
companiei;
 să permit ă autorilor de procese s ă defineasc ă termen e limit ă pentru fiecare etap ă a fluxului de
lucru;
 să permit ă autorilor de procese s ă proiecteze fluxuri de lucru cu sarcini singulare sau sarcini
paralele;
 să permit ă autorilor de procese s ă defineasc ă condi țiile de terminare pentru o activitate
paralel ă;
 să permit ă autorilor de procese s ă defineasc ă comenzi condi ționale în cadrul fluxurilor de lucru;
 să permit ă autorilor de procese definirea variabilelor pentru fluxurile de lucru;
 să permit ă autorilor de procese modificarea cu u șurință a fluxurilor de procese, regulilor și logicii
de rutare f ără interven ția utilizatorilor IT și fără activit ăți de tip IT ca instalarea de noi pachete
ale aplica ției sau modific ări în schema bazei de date.
 să permită autorilor de procese s ă aloce drepturi de executare pentru fiecare flux de lucru;

79
 să permit ă autorilor de procese s ă defineasc ă tipuri de documente permise pentru fiecare flux
de lucru;
 să permit ă autorilor de procese s ă defineasc ă fluxuri de lucru pe ntru fiecare tip de document ;
 să permit ă autorilor de procese s ă programeze declan șarea schimbului de date cu sistemele
externe prin API (Application Programming Interface) înainte și dup ă inițierea unui flux de lucru
și de asemenea , pentru orice pas al fluxului de lucru;
 să permit ă autorilor de procese s ă programeze un timp de expirare pentru flux de lucru;
 să permit ă autorilor de procese blocarea edit ării documente lor dup ă anumite etape a fluxului
de lucru;
 să permit ă autorilor de procese s ă utilizeze g rupuri și roluri pentru definirea fluxurilor de lucru;
 să permit ă autorilor de procese punerea în aplicare a oric ărui tip de ac țiune înainte sau dup ă
orice etap ă a fluxului de lucru;
 să permit ă autorilor de procese definirea și validarea metadatelor ca obl igatorii într -o etap ă din
fluxul de lucru;
 să permit ă autorilor de procese s ă programeze escaladarea automat ă a pa șilor dac ă nu exist ă
un răspuns într -un anumit num ăr de zile;
 să permit ă autorilor de procese exportul defini ției fluxurilor de lucru în format de tip imagine,
pentru a -l putea prezenta spre avizare;
 să permit ă autorilor de procese exportul și importul defini ției fluxurilor de lucru într -un format
standardizat, cum ar fi XML
 redirec ționarea automat ă a sarcinilor în cazul în care utilizatoru l și-a delegat sarcinile;
 informarea utilizatorilor prin e -mail despre o nou ă sarcin ă primit ă pe un flux de lucru;
 notificarea utilizatorilor pe e -mail despre o sarcin ă de efectuat sau neefectuat ă;
 deschiderea sarcinilor de c ătre utilizatori din notific ări primite pe e -mail;
 să permit ă utilizatorilor s ă scrie un comentariu la terminarea unei sarcini a unui flux de lucru
 să permit ă administratorului s ă genereze un tabel cu toate fluxurile de lucru și toate informa țiile
necesare;
 să permit ă utilizatorilor s ă creeze filtre de c ăutare care s ă se aplice fluxurilor de lucru;
 să permit ă administratorilor s ă opreasc ă un flux de lucru;
 administrarea de delega ții pentru utilizatorii în concediu medical sau de odihn ă;
 trimiterea documente lor pe fluxuri de lucru în mod automat în timpul procesului de scanare.
 trimiterea documente lor pe fluxuri de lucru de la ecranul de control/ecranul tactil al scanerului.
 notificarea utilizatorilor prin mesaje implicite pentru ini țializarea fluxului de lucru și pentru
acțiunile oric ărui pas;
 să permit ă editarea documente lor de c ătre utilizatorii din fluxul de lucru;
 mutarea automat ă a fișierului într -un dosar pre -selectat, dup ă o etap ă a fluxului de lucru;
 să permit ă utilizatorilor selectarea etapei fluxului de lucru în cazul în care document ul este
returnat prin respingere și întoarcerea la etapa anterioar ă sau în alt ă etap ă a fluxului de lucru
 să permit ă utilizatorilor selectarea persoanei din grupul de lucru, pentru ca documente le să nu
fie trimise întregului grup;
 să permit ă gene rarea unui istoric al fluxurilor de lucru pentru utilizatori individuali și întreaga
organiza ție;
 monitorizarea fluxurilor de lucru active;
 generarea de alerte și notific ări din fluxuri de lucru;

80
 monitorizarea și generarea de alerte pentru fluxurile de luc ru care nu sunt executate în num ărul
de zile stabilit;
 să permit ă termen e limit ă de execu ție at ât la nivel de flux c ât și la nivel de pas de flux de lucru
 să permit ă definirea de mesaje implicite la ini țierea unui flux de lucru și la ac țiuni pe fiecare pas
de lucru
 să permit ă editarea documente lor care circula pe un flux de lucru
 să permit ă configurarea mutarii automate sau nu a documente lor în anumite foldere la
transmiterea pe un anumit flux sau dup ă anumi ți pași pe flux
 să permit ă marcarea fi șierelor cu litere și culori diferite care să reflecte progresul acestora pe
fiecare pas de flux
 să permit ă marcarea cu ro șu a documente lor respinse de la aprobare
 să permit ă definirea de pasi de tip DECIZIE pe flux
 să permit ă definirea de pa și secven țiali și paraleli de execu ție a fluxului
 să permit ă trimiterea de informari pe email și SMS pe flux
 să permit ă mutarea automat ă în foldere speciale a documentelor respinse
 să permit ă semnarea electronic ă a documente lor (cu certificat calificat, avansat sau simplu) la
aprobarea pe flux de fiecare utilizator
 să permit ă aplicarea de semn ături și stampile scanate pe documente word și pdf la aprobarea
pe flux de fiecare utilizator
 să permit ă ilustrarea grafic ă diferen țiată a fișierelor care se afl ă pe un flux dar sunt încă necitite
de către destinatarii de pe flux, pe modelul Inbox Email Google sau similar.
 să permit ă apelarea de servicii web, cereri http, sau alte func ții de tip API dup ă anumi ți pași de
pe flux pentru integrarea cu alte sisteme existente în organiza ția beneficiarului
 în func ție de procesele și procedurile beneficiarului, fluxurile de aprobare vor putea include
automatiz ări specifice, de tipul:
o Inițiere automat ă a fluxului de aprobare – la salvarea document ului de un anumit tip
se ini țiază automat fluxul de aprobare, cu validare din partea ini țiatorului.
o Func ția Superior – aplica ția trimite automat notificarea de tip informare doar c ătre
Superiorul direct al Arhivatorului ini țiator, în baza rela ției predefinite de tip Superior
o Func ția Esca lare pas de informare – dacă un utilizator informat pe un pas de flux nu
confirm ă informarea într-un interval predefinit (~24ore) aplica ția finalizeaz ă
automat pasul și notific ă aprobatorii de pe pasul urm ător
o Mutare document în folder dedicat dup ă aprobar e – pe pasul de trecere a
document ului în stare Aprobat, acesta este mutat automat în subfolderul
corespunzator tipului de document
o Informare ini țiator aprobare document – inițiatorul prime ște notificare automat ă
privitor la aprobarea document ului. Notific area se trimite de pe pasul pe care s -a
facut aprobarea final ă
o Notificare ter ț neparticipant la flux – finalizarea unui flux poate fi notificat ă unui ter ț
care nu a participat la flux, dar este necesar să afle c ă document ul s-a aprobat.
o Pasul de respingere se poate selecta prin configurare – la respingere, document ul
este restituit in țiatorului sau unei persoane de pe un pas anterior
o Blocarea posibilit ății de modificare a unui document după trimiterea pe flux

81
3.3.9.5 Modul de Management arhiv ă fizică de documente

Modulul de management arhiv ă fizică de documente trebuie s ă asigure urm ătoarele func ționalit ăți:
 să permit ă crearea și gestionarea pentru mai multe fonduri de arhiv ă
 să permit ă definirea mai multor diagrame de organizare, unul pentru fiecare fond
 să permit ă gestionarea istoricului organigramelor
 să permit ă definirea și clasificarea multipl ă a documente lor / „ Nomenclatoare arhivistice” în
conformitate cu legisla ția
 să respecte le gisla ția și regulamentul privind „Arhivele Na ționale”
 să se poat ă gestiona recep ții de documente de la clien ți
 să permit ă înregistrare de noi „Unit ăți Arhivistice”
 să se poat ă defini registru Intr ări-Ieșiri
 să permit ă scanarea de documente
 Acces securizat online pentru clien ți la fondul de documente
 să se poat ă genera rapoarte de monitorizare și Management al fondului de documente
 să existe o fi șă de Eviden ță a fondului arhivistic
 să permit ă administrarea depozitului: cl ădiri, corpuri, rânduri, rafturi, polițe, alveole, cutii
 să permit ă printr -un sistem de tipul sistem informatic geografic (SIG) accesarea unei baze de
date cu punte de interes/loca ții, cu scopul de a oferi informa ții Beneficiarului, referitor la
documente le existente în acel punct de inter es/loca ție
 să permit ă crearea Registrului General al Fondurilor
 să permit ă crearea Fi șei Fondului Arhivistic
 să permit ă crearea Nomenclator ului Arhivistic
 să existe un modul pentru Inventarul arhivistic (pe structuri)
 să permit ă crearea Ghidului Topografic al fondurilor din depozit
 să permit ă crearea Registrului depozit intr ări – ieșiri
 să permit ă crearea Registrului inventarelor
 să genereze un Proces Verbal de selec ționare și generare a termen elor de p ăstrare
 să genereze un Proces Verbal pred ări documente (ieșiri)
 să genereze un Proces Verbal retur documente (retururi documente ieșite)

3.3.10 Big data

Aici se vor g ăzdui depozite de date secundare ale SIMS ca data lake / data warehouse.
Instalarea acestui nivel se va face minim pe câte un cluster de șase ma șini fizice dedicate în fiecare
dintre cele dou ă centre de date, cu o replicarea datelor între ele. Chiar dac ă unul singur va ingera date,
ambele clustere vor fi active. Solu ția va asigu ra replicare în centrul secundar cu un RPO de 6h.
Platforma de tip Big Dat a va fi bazat ă pe un sistem distribuit de fi șiere ale c ărui func ționalit ăți să fie la
un nivel cel pu țin similar proiectului Apache Hadoop, care să permit ă stocare a și procesarea unor
volume nelimitate de date cu ajutorul mai multor solu ții care ruleaz ă integrat.

82
Modelul de licen țiere trebuie s ă asigure posibilitate de transfer a solu ției pe alte servere decât cele pe
care se va instala aceasta ini țial sau înlocuire a unora dintre ele, dup ă necesit ăți.
Platforma de tip Big Data va trebui s ă ofere :
 Capac itate virtual nelimitat ă de stocare și procesare a datelor prin scalarea pe vertical ă și
orizontal ă
 Management unic pentru toate componentele platformei; acest Management va trebui să poat ă
fi făcut prin intermediul unei interfe țe grafice de tip web
 Pentr u a putea fi efectuate opera țiuni de provizionare și administrare în mod programatic, solu ția
va trebui să ofere API public pentru func țiile platformei de Management
 O baz ă de date structurate de tip Massive Parralel Processing care să ofere cel puțin următoarele:
o care să poat ă fi folosit ă atât pentru interog ări SQL în timp real c ât și pentru interog ări SQL
de tip batch
o să fie compatibil ă cu principalele tipuri de fi șiere Hadoop
o să fie compatibil ă cu un tip de fi șier care ofer ă stocare date în format colum nar .
 Componenta pentru stocarea și indexarea de con ținut nestructurat ( documente , email -uri,etc).
o Componenta va putea fi accesat ă din interfa ța web (via REST) și soft -uri client scrise în
diverse limbaje de programare de larga circula ție (Java, Python, etc)
o Indexarea documente lor va putea fi f ăcută în timp real sau în batch via algoritmi de tip
map -reduce
 Motor pentru procesare analitic ă de volume mari de date în memorie , ale c ărui func ționalit ăți să
fie la un nivel cel puțin similar proiectul ui Apache Spark , inclusiv:
o Acces la datele din cluster prin interogare de tip standard SQL
o Librarie de Machine Learning care s ă includ ă cel puțin :
 Algoritmi de clasificare, regresie, clustering și collaborative filtering
 Analiza și caracterizare seturilor de date (featurization): extragerea (feature
extraction), transformarea, selec ția și reducerea dimensiuni lor seturilor de date
 Capabilitati pentru construc ția și reglajul ML Pipelines
 Persistenta: salvare și încărcare algortimi, modele și Pipel ines
o Procesare date în limbaje multiple inclusiv Java, Scala și Python
o Procesare distribuit ă de date pe baz ă de cache în memoria fiec ărui nod
o Capabilit ăți de streaming
o Reprezentare date tip graf
 Baza de date structurate pentru procesarea în batch (via SQL) a volumelor mari de date.
 Un message broker pentru procesare date și fluxuri de evenimente în timp real, ale c ărui
func ționalit ăți să fie la un nivel cel pu țin similar proiectul ui Apache Kafka, inclusiv :
o Un model de mesagerie de tip publish -subscribe distribuit pe un num ăr mare de noduri
o Parti ționare cozi de mesaje
o Replicare
o Func ționare continu ă și în cazul în care oricare din nodurile clusterului se defecteaz ă
 Sistem de fi șiere de tip cluster. Acesta va trebui să ofere scalabilitate virtual nelimita tă prin
adăugarea de noi servere fizice cu capacitate local ă de stocare
 Solu ție integrat ă pentru Management ul tuturor resurselor solu ției de tip Big Data
 Sistem de stocare date structurate care să ofere posibilitatea efectu ării opera țiunilor de update
 Aute ntificare prin integrare cu servere LDAP
 Autentificare via protocol Kerberos
 O solu ție pentru controlul accesului la datele stocate

83
 Criptarea datelor stocate precum si solu ție pentru management ul cheilor de criptare, compatibil ă
cu echipamente le HSM propuse
 Solu ție pentru trasabilitatea datelor (Data Lineage), care s ă ofere capabilit ăți de audit, lineage,
descoperire automat ă și Management ul ciclului de via ță al datelor stocate pe platforma .
 Toate componentele platformei vor putea fi configurate în arhitecturi de tip înalt ă disponibilitate

3.3.11 Integrare de date

Acest nivel va asigura integrarea la nivel de date între diversele componente ale solu ției, precum și
alimentarea data lake, Tot aici se va rezolva și integrarea la nivel de date cu alte sistem e externe , atât
la nivel OLTP cât și data lake .
Solu ția are ca scop furnizarea c ătre utilizatorii specializa ți a unei interfe țe prietenoase care s ă
simplifice activitatea de extragere și de prelucrare de date și de raportare. Solu ția va oferi atât
posibilitatea de a extrage, manipula și salva date dintr -o baz ă de date surs ă – în principal baza de date
operativ ă descri să la cap .3.3.5., dar nu numai.
Solu ția trebuie s ă îndeplineasc ă următoarele cerin țe:
 să dispun ă de o interfa ță prietenoa să de tip ‘point -and-click’, f ără să necesite cuno ștințe avansate
de programare sau lucru cu baze de date;
 autentificare pe baz ă de utilizator și parol ă cu posibilitatea de a limita accesul la nivel de
utilizator/tabela/activitate/etc;
 Posibilitatea de conectare, extragere, stocare, scriere din baze de date rela ționale și sisteme big –
data, atât existente c ât și posibile în viitor (inclusiv Informix, Microsoft SQL Server, MySQL, Oracle,
PostgreSQL), c ât și din surse non -relaționale (fi șiere text, CSV n on-structurate);
 Un mediu de metadate comun între diferite tehnologii, care să permit ă un limbaj unic și consistent
în organiza ție în care se folosesc diferite tipuri de baze de date și tehnologii;
 Posibilitatea cre ării unui model de metadate, prin organizarea metadatelor rapoartelor, tabelelor,
bazelor de date, etc. pe categorii, în foldere, într-un mod inteligibil și fluent;
 Să dispun ă de o interfa ță unică prin care să se poat ă administra metadatele, grupurile de ac ces și
resursele sistemului;
 Opera ții cu metadate:
 Import, export și copiere de obiecte individuale (rapoarte, librarii, tabele, coloane, index
sau chei) sau seturi de obiecte și relațiile dintre acestea, mergând până la întreg depozitul
de metadate;
 Versi onare prin exportarea în pachete de metadate;
 Import și export de metadate din și către alte tehnologii
 Modificare Metadate (atunci c ând intervin modific ări ale datelor fizice, metadatele și
datele să poată fi sincronizate)
 Migrarea, sincronizarea, duplica rea datelor între diferite sisteme opera ționale și surse de date.
 Să asigure func ționalit ăți de transformare și func ții care să permit ă:
 îmbun ătățirea calit ății datelor – prin intermediul unor transform ări dedicate, calitatea
datelor să poat ă fi îmbun ătățita prin identificarea și eliminarea valorilor multiple dintr -o
coloan ă (de exemplu eliminarea tuturor dublurilor, mai puțin a uneia, dintr -o coloana de
chei), eliminarea valorilor nule, aplicarea de pattern -uri structurale pe diferite coloane,
etc;

84
 extrag erea, transformarea, încărcarea și alte opera țiuni de manipularea a datelor;
 modificare, reformatare, consolidarea informa țiilor;
 interogarea datelor și generarea de rapoarte sub diferite formate (Excel, CSV, Word,
HTML);
 trimiterea de rapoarte prin email, salvarea pe disk sau afișarea pe ecran;
 Existen ța transform ărilor predefinite care să reduc ă timpul de dezvoltare al fluxurilor de
procesare de date.
 Acces la date:
o Citire de tip bulk -loading, acolo unde baza de date permite
o Acces la soluții de tip message queue
o Citire date de tip CSV, XML, JSON
o Integrare cu servicii web
 Să permit ă analiza datelor în tranzit:
o Corela ții – să creeze o analiza care conține corela ții statistice între coloane;
o Distribu ții – să creeze o analiz ă de distribu ție a dat elor pe coloane;
o Previziuni – să permit ă rularea procedurii de forecasting;
o Frecven țe – să creeze o analiz ă care conține num ărul de apari ții pentru o valoare, într-
o coloana;
o Statistici descriptive – analiza privind timpii și resursele folosite de o transf ormare;
 Posibilitatea de a folosi tehnologii de tip Change Data Capture (CDC)
 Controlul fluxurilor prin transform ări de tip Loop, For sau While pentru a putea fi
paralelizate
 Posibilitatea de a publica rezultatelor rulării fluxurilor de încărcare î ntr-o arhiva
electronica, transmise pe email sau într-o coad ă.
 Posibilitatea de a rula func ții de tip SQL , inclusiv Create Table , Delete , Select , Insert Rows ,
Join, Merge , Set Operations , Update
 Posibilitatea de a vizualiza relațiile dintre tabelele existe nte mergând pana la câmpurile pe care
acestea le con țin.

Instalarea acestei componente se va face în ma șini virtuale și nodurile se vor configura pentru a
func ționa activ -pasiv într -unul dintre cele dou ă centre de date (cu replicare în cel ălalt pentru
evenimente deosebite). Elementele propriu -zise de integrare date trebuie s ă fie licen țiate pe minim
16 nuclee fizice , pentru a putea sus ține moment ele cu înc ărcare de vârf, perpetuu și fără limit ă de
num ăr utilizatori . Se vor acoperi minim bazele de date de la cap.3.3.5, cu amprenta specificată acolo.
Dacă furnizorul prevede în cadrul soluției și alte baze de date cu date utile, se vor acoperi și acestea.

3.3.12 Analiz ă și vizualizare date

Acesta este nivelul care va constitui baza tehnologic ă pentru func ționalit ățile aferente cap. 3.2.5. În
principiu, acesta va func ționa pe datele din data lake, pentru a nu afecta sistemul operativ.
În aceast ă zonă distinge m două componente principale .

85
3.3.12.1 Definirea și proiectarea fluxurilor de analiz ă a datelor

Modulul de analiz ă trebuie să îndeplineasc ă următoarele cerin țe:
 Să ofere o interfa ță vizual ă în care s ă se poat ă crea fluxuri de procesare a datelor
 Să permit ă conectarea și integrarea mai multor seturi de date prin conectarea nodurilor
 Să ofere blocuri specializate pentru append, merge, importul de fi șiere de tip Microsoft Excel, CSV
etc.
 Să ofere instrument e de analiz ă și explorare a datelor: histograme, line chart, box plot, scatter
plot, line plot, bar chart, pie chart, 3d charts, precum și prezentarea tabelar ă a datelo r pentru
înțelegere
 Să ofere blocuri specializate pentru transformarea variabilelor de intrare prin care s ă se acopere
inclusiv func ționalit ăți de tipul: logaritmare, analiza componentelor principale, precum și alte
func ții în scopul normaliz ării datelor pentru eficientizarea algoritmilor și rezultatelor ob ținute
 Să ofere posibilitatea de a defini în interfa ță reguli de tipul „if then else”
 Să ofere algoritmi pentru segmentare , path analysis, link analysis, Kohonen self -organizing maps,
pent ru zona de modelare nesupervizat ă
 Să ofere algoritmi de tipul arbori decizionali, re țele neuronale, regresii, random forrest,
combinarea modelelor precum și noduri specializate pentru compararea și selectarea celui mai
bun model, în zona de modelare superv izată
 Să ofere algoritmi de tipul serii de timp pentru proiec ții și forecast
 Să ofere o metodologie de creare și Management al modelelor, direct construit ă în interfa ța de
lucru
 Pentru fiecare model, solu ția tre buie să creeze automat grafice și analize sp ecifice modelului
creat , inclusiv : analiza segmentelor și distribu ția valorilor dintr -o variabil ă în cadrul segmentului ,
stabilitatea modelului , grafice de tip re țea pentru a înțelege legăturile descoperite între diverse
entit ăți. Aceste analize nu trebuie să implice efort de configurare/dezvoltare de către utilizator,
fiind complet automate.
 Rezultatele fluxului să poat ă fi exportate într-un singur pachet de scoring care s ă includ ă atât
partea de model c ât și partea de preg ătire a datelor, logica de scor putând fi aplicat ă apoi imediat
pe un set nou de date, ce conține acelea și câmpuri, fără a fi nevoie de dezvoltare sau configurare
 Să ofere posibilitatea de a exporta rezultate le modelelor în cod PMML, Java și C.
 Să ofere posibil itatea de a folosi algoritmi pentru volume mari de date: in -database processing, in –
memory processing, etc.
Instalarea acestui modul se va face în ma șini virtuale și nodurile se vor configura pentru a func ționa
activ -pasiv într -unul dintre cele dou ă centre de date (cu replicare în cel ălalt pentru evenimente
deosebite). Elementele propriu -zise de definire și proiectare a fluxurilor date trebuie s ă fie licen țiate
pe minim 8 nuclee fizice , pentru a putea sus ține mai mul ți utilizatori care lucreaz ă simul tan, perpetuu
și fără limit ă de num ăr utilizatori .

3.3.12.2 Vizualizarea datelor

Modulul de vizualizare trebuie să îndeplineasc ă următoarele cerin țe:
 Posibilit ăți de raportare din surse de date eterogene

86
 Posibilitati de raportare cu moduri multiple de vizualizari care să conțină cel puțin hărți, sparklines
și indicatori:
o Sparklines: Posibilitate de creare rapoarte folosind tabele și matrici pentru a afi șa date
agregate;
o Indicatori: Posibilitatea de vizualizarea a datelor într-un mod rapid folosind metode grafice
(icoane).
o Hărți: Posibilitatea de creare de rapoarte folosind un îndrum ător (Wizard) care permite
vizualizarea datelor sub forma unui model geografic care poate prelua datele dintr -o galerie
de h ărți pe baz ă de interog ări SQL sau dintr -un fi șier stocat în sisteme geospa țiale.
o Grafice: bar with multiple lines, pie, donut, line, scatter, heat map, bubble, animated bubble,
treemap, dot, needle, numeric series, sched ule chart, vector, etc.
 Posibilitatea de a crea infografice pe baza informa țiilor definite în solu ție
 Posibilitatea de a integra grafice și vizualiz ări din surse externe, open source sau customizate
 Posibilitatea de a genera scenarii de tip what -if pe datele existente.
 Instrument e de data mining: func ționalit ăți pentru construirea sau integrarea de modele analitice
complexe precum și integrarea acestor modele cu opera țiile de business, incluz ând modele de
tipul arbori decizionali, regresii liniare sau l ogistice, serii de timp precum și posibilitatea de a
compara și evalua modelele ob ținute f ără a fi nevoie de cuno știnte de programare
 Raportare “ad hoc”: utilizatorii să poat ă edita propriile rapoarte pe baza unui model (template),
fără să dețină cuno științe de baze de date sau despre structura acestora. Serviciile de raportare
să fie incluse în produs, f ără add-on-uri sau licen țiere suplimenta re;
 Raportarea “ad hoc” să ofere posibilitatea de generare automat ă a tipului de grafic, în func ție de
câmpurile s electate.
 Rapoartele “ad -hoc” să prezinte informa ția selectat ă printr -o serie diversificata de grafice: line
chart, bar chart, pie chart, scatter plot, waterfall, serii de timp, bubble plot, treemap, needle plot,
sankey diagram și diagrama de re țea, precum să ofere și un instrument vizual, web -based de
construire de grafice noi.
 Interogare și analiz ă ad-hoc și self -service a datelor: facilit ăți de interogare a datelor disparate în
moment ul solicit ării rapoartelor;
 Extragerea și editarea dinamic ă a rapoartelor utiliz ând instrument e familiare de tip productivitate
(cel puțin Microsoft Excel) și interfe țe noi intuitive și productive care includ grafice, h ărți,
sparklines și indicatori;
 Să permit ă exportarea rapoartelor în diverse formate, cel puțin Microsoft Excel, fi șiere CSV, o alt ă
bază de date (oferta va preciza cel puțin o baz ă de date), fi șiere XML;
 Să permit ă exportul în documente tip PDF, TIFF;
 Posibilit ăți de colaborare cu ajutorul instrument elor de analiz ă de tip pivot, accesibile via un
browser web, care să permit ă utilizatorilor să creeze solu ții self -service BI cu portalul web ofertat
pe seturi de date mari
 Posibilitatea abon ării la alerte în cazul unor evenimente din baza de date.
În cadrul solu ției de analiz ă și vizualizare date se vor implementa :
o Minim 15 tablouri de bord (dashboards) a c ăror specifica ții detaliate vor fi definite în
cadrul fazei de analiz ă și proiectare

87
o Minim 4 modele de analiz ă și predic ție avansat ă, definirea scopului acestor modele fiind
făcută în faza de analiz ă și proiectare
o Minim 10 rapoarte statistice semi -statice care se vor publica cu o anumit ă frecven ță în
portalul destinat publicului.
Instalarea acestei componente se va face în ma șini virtuale și nodurile se vor configura pentru a
func ționa activ -activ, cu balansare a înc ărcării, astfel încât s ă poat ă susține minim 350 de sesiuni
simultane pe tablourile de bord (dashboards) și rapoartele statistice semi -statice definite în cadrul
soluției, cu un timp mediu de r ăspuns de maxim 15 sec unde, pe site -ul intern ( pe tablourile de bord
pentru angaja ți). Solu ția propus ă să fie astfel licen țiată pe minim 240 de nuclee fizice , pentru a putea
scala în caz de nevoie, perpetuu și fără limit ă de num ăr utilizatori.
Solu ția livrat ă trebuie s ă poat ă proviziona în fiecare centru de date, atunci când condi țiile o cer, câte
minim 6 noduri cu câte 512GB RAM pe fiecare nod în parte.
Solu ția de vi zualizare se va instala distinct în fiecare centru de date. În regim de lucru normal un centru
de date va deservi angaja ții ministerului de pe site -ul intern (cu tablouri de bord – dashboards –
specializate pentru diverse roluri din cadrul institu ției și rapoarte mai complexe) pe cea mai mare parte
a resurselor licen țiate, în timp ce al doilea centru de date v a utiliza restul de resurse licen țiate pentru
site-ul public (cu rapoarte mai simple), protejate de un mecanism de limitare a num ărului de cereri
simultane (throttling) care s ă previn ă supra -încărcarea acestuia. În caz de nevoie resursele licen țiate
se vor putea realoca între cele dou ă centre de date pentru a optimiza timpul de r ăspuns la
circumstan țe.

3.3.13 Cerin țe generice de arhitectur ă software

Toate componentele se vor instala în configura ții de înalt ă disponibilitate, preferabil în regim activ –
activ.
El1ementele legate de activitatea curent ă a profesorilor (pe care le vom denumi Core ) se vor grupa
distinct, separat de celelalte componente (pe care le vom denumi Main ) ale Nucleului interactiv,
pentru a putea asigura atât nivelul de performan ță necesar derul ării activit ății, cât și integritatea
datelor aferente. Separarea trebuie f ăcută inclusiv la nivelul schemelor sau instan țelor de baz ă de
date, cu asigurarea replic ării de date între ele.
Nucleul aplicativ se va instala în mod activ în ambele centre de da te, pentru a putea eficientiza
utilizarea resurselor de infrastructur ă. Celelalte componente pot func ționa în mod activ la un moment
dat într -un singur centru de date, dar trebuie asigurat ă replicare continu ă astfel încât oricare centru
de date s ă poat ă prelua integral activitatea (cu deteriorarea de performan ță de rigoare) în cazul unui
eveniment deosebit. Bascularea serviciilor între centrele de d ate trebuie s ă se fac ă manual, î n baza
unor scripturi de automatizare a opera țiunilor. Replicarea datelor treb uie s ă se fac ă automat, în mod
continuu.
Bazele de date trebuie s ă fie astfel organizate încât s ă asigure o înc ărcare optim ă, cât mai uniform ă,
pe fiecare server de baz ă de date din cadrul solu ției, indiferent de centrul de date în care se afl ă.
Solu ția de bază de date trebuie s ă fie astfel proiectat ă încât s ă poat ă scala pe orizontal ă și verdical ă.
Dincolo de utilizarea în comun a resurselor de infrastructura hardware și software de baz ă,
componenta de semn ătură digital ă trebuie s ă fie complet separat ă de oricare alte componente ale

88
soluției. Nu se vor face apeluri din alte sisteme SIMS în aceasta decât strict pentru a declan șa procese
de semnare. Nu se vor face apeluri dintre aceasta și alte sisteme SIMS decât pentru a comunica
rezultatul procesului de semnare și a transfera înapoi documente le semnate. Componenta de
semnare digital ă nu va fi folosit ă explicit de alte sisteme SIMS în afara Arhivei, strict pe procesele de
semnare de documente .

89
Diagrama de mai jos exemplific ă modul în care trebuie aplica țiile configurate per centre de date:

Oferta va demonstra detaliat cum se vor îndeplini aceste cerin țe prin solu ția propus ă.

90
3.4 Infrastructur ă hardware și software de baz ă

Infrastructura IT avut ă în vedere este descris ă în diagrama urm ătoare:

91
Vom împ ărți componentele aferente acesteia în patru mari categorii:
 Tehnic ă de calcul și solu ții de stocare date
 Rețelistic ă și Securitate IT
 Sisteme de gestiune
 Alte componente auxiliare.
Dotarea celor dou ă centre de date va fi practic identic ă, cu excep ția notabil ă a arhiv ării: soluția
principal ă de arhivare pe band ă va fi g ăzduit ă într-unul dintre centre, cel ălalt fiind dotat cu una mult
redus ă, de utilizat doar pentru nevoi opera ționale sau în caz de necesitate.
În mod normal, fiecare centru de date va procesa jum ătate din teritoriul na țional. În caz de necesitate,
centrul supravie țuitor va prelua toat ă încărcarea, sacrificând performan ța și oprind , dup ă caz,
serviciile auxiliare.
Se vor realiza toate configura țiile necesare replic ării și balans ării geografice între cele dou ă centre de
date, inclusiv toate scripturile care vor face comutarea înc ărcării de pe un site pe cel ălalt – comutarea
propriu -zisă va trebuie executat ă automat, dar comanda de comuta re nu se va da decât manual.
Se vor realiza teste de comutare real ă a înc ărcării de cel pu țin de dou ă ori pe an, câte unul pe fiecare
sens , acoperind toate subsistemele . Acestea vor fi însoțite și de teste legate de datele de pe benzi,
realizate prin sonda j, inclusiv cu restaurare, pe un eșantion aleatoriu.
Dacă consider ă necesar, ofertantul este liber s ă suplimenteze cantit ățile de mai jos cu echipamente
care corespund sau sunt superioare cerin țelor, în func ție de destina ția acestora (de exemplu, dac ă se
va ad ăuga un server în ferma de baz ă de date, acesta trebuie s ă fie identic cu toate celelalte)
Nu se vor accepta produse second hand, refurbished, recondi ționate, de provenien ță necunoscut ă
(care nu poate fi verificat e cu produc ătorul acelui produs), f ără marc ă de origine, a c ăror durata de
viață a fost afectat ă prin utilizarea în campanii de prezentare și testare la clien ți sau din cauza
depozit ării îndelungate ori deteriorate din cauza manipul ării necorespunz ătoare.
Component ă Cantitate minim ă per centr u de date
Ferma virtual ă 4 șasiuri + 20 serverele lamelare ;
alte 4 servere lamelare pentru alte nevoie
Servere de baz ă de date 4 servere scalabile
Big data 6 servere
Stocare all -flash 1 sistem
Stocare NAS 1 sistem
Complet de backup 1 complet (inclusiv software de backup, libr ărie de band ă și
sistem backup2disk)
Firewall 2 buc ăți
Securitate servere 300 instan țe server
Analiză malware 1 echipament
Router WAN 2 buc ăți
Switch WAN 2 buc ăți
Switch core campus 1 complet redundant
Complet controlul aplica țiilor 1 complet redundant
Switch core DC 4 buc ăți
Switch Management 1 bucat ă
Sisteme de gestiune 1 solu ție complet licen țiată pe infrastructura din centrul de date
(incluzând Management infrastructur ă, ITSM, monitorizare etc.)

92
Dulapuri tip rack După necesar
Container Complet accesorizat, inclusiv UPS, HVAC, securitate fizc ă etc.

Ofertantul este unicul responsabil cu dimensionarea soluției, cantit ățile de aici fiind doar minimal
obligatorii – acestea trebuie suplimentate dacă este necesar pentru a în deplini cerin țele volumetrice și
de performan ță ale solu ției. Dac ă se va determina pe perioada implementări i sau a exploat ării că acestea
au fost sub-dimensionate în raport cu cerin țele, Furnizorul le va suplimenta pe cheltuiala pr oprie.
În calculul necesarului de resurse trebuie ținut cont și de configurarea unui mediu de testare/dezvoltare
permanent func țional, chi ar dac ă mult redus fa ță de cel de produc ție.
Toate caracteristicile enumerate mai departe se referă la echipamente le ce vor trebui incluse în ofertă și
sunt minimale și obligatorii.

3.4.1 Tehnic ă de calcul și solu ții de stocare date

Produc ătorii echipamente lor trebuie s ă fie certifica ți ISO14001 9001 si 18001.

3.4.1.1 Ferma virtual ă

În fiecare centru de date se vor livra minim 4 șasiuri de servere blade , suficiente pentru a g ăzdui toate
serverele lame lare solicitate aici plus o rezerv ă de cel puțin 25% pentru extensii ul terioare . Șasiurile
vor fi echipate redundant cu switch -uri Ethernet și FC, car e să conecteze toate porturile solicitate în
serverele lamelare .
În fiecare centru de date, f erma de servere lamelare se va conecta în exterior la switch -urile core prin
legături redundante care s ă ofere o l ărgime de band ă total ă de cel puțin 400 Gbps pentru comunica ția
Ethernet respectiv 256 Gbps pentru comunica ția Fibre Channel.
În fiecare centru de date se vor instala:
 Minim 20 servere lamelare pentru ferma virtual ă, fiecare cu:
o minim 36 nuclee fizice (minim 2 x minim Xeon Gold sau echivalent , frecvență nominală
de funcționare de minim 3GHz , minim 18 core -uri)
o minim 2 discuri x 480GB SSD configurate în RAID 1
o minim 2x20Gbs Eth, minim 2x16Gb s FC
o minim 192GB RAM ; minim 6 servere lamelare vor avea instalat 1152GB RAM
o Sistem de operare Linux Enterprise sau Windows Server , fără limit ă de num ăr de
mașini virtuale
o Hypervisor de virtualizare de nivel Enterprise
 Minim 4 servere lamelare pentru alte nevoi , fiecare având:
o minim 16 nuclee fizice (minim 2 x minim Xeon sau echivalent , frecvență nominală de
funcționare de minim 2GHz, minim 8 core -uri)
o minim 2 discuri x 1.2TB 10k HDD , configurate în RAID 1
o minim 2x20Gbs Eth, minim 2x16Gb s FC

93
o minim 48GB RAM
o Sistem de operare Linux Enterprise sau Windows Server
Aceste echipamente vor g ăzdui cvas i-totalitatea componentelor software ale SIMS într -un mediu
virtual complet controlat , asigurându -se îns ă și o rezerv ă de capacitate de procesare în mediu ne –
virtualizat pentru nevoi speciale.
Se va asigura gestiunea și monitorizarea atent ă a întregului mediu virtualizat , inclusiv me canismele de
replicare a configura țiilor între centrele de date.
Se vor include aici toate componentele software de baz ă aferente:
 Solu ția de virtualizare
 Solu ția de Management
 Solu ția de replicare între centrele de date
 Sistemele de operare aferente mașinimlor virtuale
Solu ția de virtualizare va fi aceea și pe toate cele 40 de ser vere din cadrul fermei virtuale și trebuie s ă
fie certificat ă (acolo unde exist ă certific ări) sau suportat ă de toate componentele pe care le
găzduie ște, fără a limita în nici un fel func ționalitatea acestora.
Cerin țe minimale pentru fiecare șasiu de servere lamelare:
 Suport pentru servere tip „blade” cu unu , dou ă și patru CPU, în maxim 10 unit ăți rack
 Toate componentele sistemului – servere lamelare, dispozitive de Management , KVM, surse
de alimentare , ventilatoare, echipamente de interconectare și comunica ție, vor fi de tip
modular integrate în șasiu
 Surse de alimentare de înalt ă eficien ță, interne în șasiu, hot -swap, care s ă asigure alimentarea
redundant ă în condi ții de înc ărcare maxim ă a șasiului; redundan ță de tip „N+1” și „N+N”, cu
capabilit ăți „load -balancing” și „failover”; fiecare șasiu va fi echipat cu num ărul maxim de
surse de alimentare electric ă
 Sistem de ventila ție de înalt ă eficien ță pentru r ăcirea incintei, tip m odular hot -swap,
redundant, instalat intern în șasiu. Solu ția livrat ă va fi dotat ă cu toate modulele de ventila ție,
prev ăzute de produc ătorul echipament ului, inclusiv ventila ția suplimentară de pe sursele de
alimentare , dispozitive de interconectare și comunica ție etc.
 Suport pentru instalarea a minim 4 module I/O interne cu posibilitate de intermixarea a
acestora : 10/20 Gbps Ethernet, 16 /32 Gbps Fibre Channel sau FCoE
 Echipare cu module I/O per șasiu:
o Minim dou ă module 16Gbps Fibre Channel (sau FCoE) în configura ție redundant ă,
fiecare modul va avea un num ăr minim de porturi, astfel:
 interne – acoperitor pentru num ărul maxim de servere din șasiu
 externe – suficient pentru a expune o l ărgime de band ă total ă cel puțin egală
cu suma porturilor interne
 Suport pentru Zonare
o Minim două module Ethernet în configura ție redundant ă, fiecare switch va avea un
num ăr minim de porturi, astfel:
 interne – porturi 20 Gbps Ethernet acoperitor pentru num ărul maxim de
servere din șasiu
 externe – suficient pentru a expun e o l ărgime de band ă total ă cel puțin egală
cu suma porturilor interne

94
 Suport pentru : VLAN Layer 2 si Layer 3, Jumbo Frames, routing, rețea
convergent ă iSCSI LAN si SAN de tip iSCSI
 Management șasiu:
o Componenta hardware de management :
 min. 2 x module de management centralizat per șasiu pentru controlul la
nivelul întregului șasiu, în configura ție redundant ă (1+1), hot -swap, integrate
în șasiul „blade”
 minim un port Gigabit Ethernet și un port serial sau USB pentru acces, pe
modul sau pe șasiu ;
 Modulele de management de pe șasiuri trebuie s ă permit ă interconectarea
astfel încât s ă se poat ă realiza un management unificat, centralizat și
redundant , pentru toate serverele lamelare. Ofertantul va prezenta diagrama
de interconectare a modulelor de management .
o Com ponenta software de management :
 interfa ță unic ă, sigur ă pentru identificarea resurselor hardware (inventar),
configurare, monitorizare, alertare pentru șasiu și toate componentele
instalate;
 func ții integrate de management de la distan ță (remote), redirectare interfa ță
grafic ă – inclusiv sistemul de operare, tastatur ă și mouse, posibilitate de
pornire/oprire de la distan ță pentru fiecare server blade, switch instalat,
suport pentru remote media (virtual CD, flash etc);
 suport pentru acces ul securizat prin interfe țe Web -based GUI (SSL) și în linie
de comand ă (Telnet / SSH);
 suport pentru niveluri multiple de roluri de utilizator și permisiuni, inclusiv
integrarea în AD (Active Directory) și servicii LDAP (Lightweight Directory
Access Protoc ol);
 sistemul de management trebuie s ă permit ă monitorizarea în timp real a
consumului de energie electric ă, a temperaturii și furnizarea unor grafice de
evolu ție pe diverse perioade de timp (minute, ore, zile).
 aplica ția de management va permite monitori zarea și management ul tuturor
componentelor din cadru sistemului blade (servere, switch -uri, etc).
 sistemul de management va fi complet licen țiat, instalat și activat, f ără să fie
necesar ă licen țiere suplimentară .
o Sistem de alertare, diagnosticare și afișaj luminos cu LCD sau LED -uri pentru
semnalarea func ționării normale și a eventualelor erori ale componentelor șasiului .

Cerin țe minimale pentru fiecare server lamelar:
 server tip „blade” compatibil 100% cu șasiul solicitat mai sus
 suport pentru memorie D DR4 2666MT/s RDIMM, LRDIMM;
 suport pentru minim 3TB memorie LRDIMM;
 funcționalit ăți RAS (Reliability, Availability, Serviceability) pentru memorie: memory demand
și patrol scrubbing, failed DIMM isolation, memory mirroring, memory sparing
 Storage suportate : SAS, SATA, SSD , NVMe
 Suport montare pentru minim două discuri hot-plug / hor -swap

95
 Echipare conform cu cerințele de capacitate prezentate mai sus cu dou ă discuri certificate de
produc ătorul serverului , configurate în RAID 1 prin controller RAID hardware dedicat cu 1GB
memorie cache și suport pt. RAID 0, 1, 5, 6.
 Minim 1 x USB 3.0
 Minim 1 x USB 2.0 frontal, pentru date și pentru port management USB
 Fiecare server trebuie să dispun ă de conectori redundan ți pentru alimentare electric ă,
semnale I/O, management .
 Certificat de produc ător cu suport pentru urm ătoarele sisteme de operare: Microsoft
Windows Server, Linux Enterprise (inclusiv versiunile livrate) și soluția de virtualizare livrat ă
 Securitate :
o TPM 1.2/2.0
o Firmware cu semn ătură criptografic ă
o Secure Boot
o Protecție la modificarea configura țiilor de sistem și update -uri firmware ( System
Lockdown )
o Resetarea sistemului la starea ini țială (setările din fabric ă), cu toate datele și
configura țiile eliminate din mediile de stocare interne ale serverulu i (System Erase )
 Placă de baz ă fabricat ă sub acela și brand cu sistemul de calcul (s ă existe în nomenclator ul de
produse al produc ătorului sistemului de calcul)

Oferta va include o s oluție de management licen țiată complet pe toată infrastructura livrată, cu
următoarele caracteristici :
 Management și monitorizare centralizat ă cu suport pentru mai multe ti puri de echipamente
inclusiv: șasiu servere blade , server e, echipamente le de stocare , switch -uri LAN si SAN,
biblioteci de benzi etc.
 Alert are pe e -mail
 Monitorizarea consumului de energie
 Sistem integrat de diagnosticare
 Instalare local ă a sistemului de operare pe servere
 Update -uri locale
 Stocare pachete de drivere
 Update remote
 Control al puterii de alimentare
 Criptare
 Captură ecrane de eroare
 Suport IPv6
 Interfa ță grafic ă Web
 CLI remote și local
 Redirectare serial ă
 Configurare de la distan ță
 Alerte SNMP
 Backup și restaurare configura ții
 Consol ă virtual ă cu suport pentru minim 4 utilizatori concurenți
 Parti ții flash virtuale, foldere virtuale
 Înregistrare și redare secven ța de boot
 Suport pentru integrare cu AD, LDAP

96
 Autentificare prin certificare
 Diagnostic boot image
 Stocare de configura ții personalizate pentru automatizarea instal ărilor, scripturi și imagin i de
sistem.
 REST API
 Consol ă de administrare mobil ă cu suport pentru Android și iOS
 Tipul licen ței software pentru aplica ția de management : permanent
 Integrare și plug -in pentru solu țiile de monitorizare și virtualizare utilizate

3.4.1.2 Cluster baz ă de date

În fiecare centru de date se va instala o ferm ă de baz ă de date cu minim patru servere, fiecare având:
 Server rackabil cu suport pentru 8 procesoare , expandabil la 16 procesoare
 Minim 96 nuclee fizice instalate, cu frecven ța de baz ă de minim 3.0 GHz (minim 8 procesoare
x minim Xeon sau Power9 sau echivalent x minim 12 nuclee fizice )
 Sistem de operare Linux Enterprise sau Windows Server sau UNIX , inclusiv cluster file sistem
 Minim 4 x minim 25Gb ps Ethernet , pe minim dou ă carduri redundante
 Minim 4 x minim 1 6Gbps FC, pe minim dou ă carduri redundante
 Minim 2TB RAM instala ți (32 x 64GB RDIMM, 2666MT/s, ECC), expandabil al 12TB
 Sloturi PCIe 3.0 : minim 20 x8, minim 8 x16
 Surse de alimentare în configura ție redundant ă hot-swap / hot-plug
 Ventilatoare hot-swap / hot-plug, redundante , viteza de rota ție variabil ă în func ție de
încărcare
 Modul integrat pentru management , hardware și software, oferit de produc ătorul server -ului
 Minim 2 x discuri 800GB SSD instalate
 Controller RAID hardware dedicat cu suport RAID 0, 1, 5, 6 și memorie cache de minim 1GB
 Placă de baz ă fabricat ă sub acela și brand cu sistemul de calcul (s ă existe în nomenclator ul de
produse al produc ătorului sistemului de calcul)

3.4.1.3 Cluster Big Data

Oferta va include pentru fiecare centru de date se câte o ferm ă Big data cu minim șase servere per
locație , fiecare având:
 minim 4 4 nuclee fizice (minim 2 x minim Xeon Gold sau echivalent , frecvență nominală de
funcționare de minim 2GHz, minim 8 core -uri, 22 nuclee fizice )
 minim 2 x minim 400GB SSD
 minim 12 x minim 10TB HDD 7200 rpm
 minim 4 x minim 10Gbps Ethernet , pe minim dou ă carduri redundante
 minim 512GB RAM (16 x 32GB RDIMM 2666MT/s Dual Rank );
 funcționalități RAS (Reliability, Availability, Serviceability) pentru memorie memorie: Memory
Demand , Patrol Scrubbing, Failed DIMM isolation, Memory mirroring, Memory sparing
 Suport pentru m inim 24 x module DDR4 DIMM (RDIMM /LRDIMM ) suport ă minim 3TB RAM

97
 Sistem de operare Linux Enterprise sau Windows Server
 Format rackabil, maxim 2U
 Sloturi PCIe 3.0 : minim 3 x8, minim 1 x16
 Minim dou ă surse de alimentare , configura ție redundant ă hot-swap / hot-plug – echiparea s ă
acopere înc ărcarea cu toate discurile
 Minim 6 ventilatoare hot-swap / hot-plug, redundante , viteza de rota ție variabil ă în fu ncție
de înc ărcare
 Porturi frontale: video, 1 x USB 2.0 / USB 3.0, port dedicat pentru management
 Porturi în spate : video, serial, 1 x USB 2.0, port RJ45 dedicat pentru management
 Securitate :
o Protecție frontal ă cu încuietoare cu cheie pentru restric ționarea accesului fizic la
nivelul discurilor.
o TPM 1.2/2.0, alertare la intruziune, secven ță de pornire (boot) în manier ă securizat ă
, secven ță de oprire în manier ă securizat ă
o Firmware cu semn ătură criptografic ă
o Protecție la modificarea configura țiilor de sistem și update -uri firmware (System
Lockdown)
o Resetarea sistemului la starea ini țială (setările din fabric ă), cu toate datele și
configura țiile eliminate din mediile de stocare interne ale serverului (Secure Erase)
o Parol ă unic ă pt fiecare sistem ofertat, generat ă de produc ătorul echipament ului ,
pentru modulul de management .
 Management
o Modul integrat pentru management , hardware și software , oferit de produc ătorul
echipament ului.
o Solu ția de management va func ționa în manier ă independent ă de sistemul de
operare, f ără agen ți instala ți pe sistemul de operare, și va administra centralizat toate
componentele sistemului.
o Controlerul va include minim un port 1 Gb ps Ethernet dedicat pentru administrare
o Include agregarea mai multor co ntrolere de management , management la nivel de
grup .
o Consol ă unic ă de administrare pentru toate componentele sistemului, accesibil ă web.
o Suport DHCP , SNMP traps , notificari e -mail , Telnet/SSH , comenzi CLI inclusiv pentru
system boot, reset, power -on și shutdown
o Include suport pentru configurare adrese WWN/MAC în mod flexibil/virtual.
o Solu ția va include cel puțin : monitorizarea consumului de energie, criptarea
configura țiilor, captur ă ecrane de eroare, redirectare serial ă , backup și restaurare
configura ții , consol ă virtual ă (suport pentru minim 4 utilizatori concurenți ), parti ții
flash virtuale, foldere virtuale, înregistrare și redare secven ță de boot .
o Software de Management centralizat pentru administrarea dintr -o consol ă unică a
tuturor ser verelor ofertate, inclusiv monitorizarea și automatizarea proceselor :
firmware update, instalare sisteme de operare, administrare remote , redirec ționare
console.
 Controller RAID hardware dedicat cu suport RAID 0, 1, 5, 10, 50 și memorie cache minim 1GB
 Placă de baz ă fabricat ă sub acela și brand cu sistemul de calcul (s ă existe în nomenclator ul de
produse al produc ătorului sistemului de calcul)

98
3.4.1.4 Sistem de stocare all -flash

Aceste echipamente vor g ăzdui datele aferente bazelor de date rela ționale și mediilor virtuale de
produc ție, eventual și alte date cu cerin țe ridicate de performan ță. Se va prevedea în ofertă câte un
echipament în fiecare loca ție.
Fiecare echipament va avea urm ătoarele caracteristici minimale:
 echipament de ultim ă genera ție, cu caracteristici de performan ță extrem de ridicate , situat în
categoria high -end Enterprise în gama de produse a produc ătorului acestuia
 poat e fi instalat în rack -urile standard solicitate aici și poate fi ulterior, dac ă va fi cazul, amplasat
în alt rack al Beneficiarului, dup ă dorin ța acestuia
 asigur ă o disponibilitate de 99,9999%
 capacitate util ă instalat ă: minim 90 TB în RAID 6 pe discuri de acela și tip
 echipament ul trebuie s ă aibă func ționalit ăți avansate de de -duplicare și compresie hardware ;
pentru eficien ță optim ă, echipament ul ofertat trebuie s ă conțină func ții integrate de compresie
de tipul “in -line” (în timp real)
 configura ția livrat ă suport ă dublarea capacit ății utile prin ad ăugarea de discuri de acela și tip la
cele existente f ără achizi ția de noi sertare de discuri (cele livrate trebuie s ă fie populate la maxim
jumătate din capacitatea acestora ca num ăr de discuri)
 capacitatea de stocare livrat ă va fi exclusiv de tip flash drive (minim 3TB per disc/modul flash) ,
atât cea solicitat ă inițial cât și cea prev ăzută suplimenta r de c ătre Ofertant / Furnizor în moment ul
livrării sau pe durata proiectului
 minim dou ă discuri spare deja instalate, cu func ționare tip hot -spare
 minim 4 controllere cu func ționare activ -activ simetric ă (prezentarea în mod act iv-activ a tuturor
LUN -urilor, în mod nepreferen țial către servere)
 minim 448 GB memorie cache de tip RAM per controller , cu protecție pentru c ădere de tensiune
pe termen lung
 conectivitate extern ă – minim 16 porturi FC 16Gb ps
 minim 4096 ini țiatori FC
 minim 4096 LUN -uri
 performan ță minim ă în configura ția ofertat ă: 200 000 IOPS și timp de r ăspuns de maxim 1 ms
măsurat e cu deduplicare și compresie activate
 toate componentele și subansamblele echipament ului (inclusiv surse de alimentare și ventila ție)
vor fi în configura ție redundant ă și vor putea fi înlocuite f ără a afecta buna func ționare a
echipament ului (hot -swap )
 suport oficial de la produc ător pentru sisteme le de operare Windows Server și Linux Enterprise,
precum și pentru solu ții de virtualizare; în mod expres va exista suport oficial pentru sistemele de
operare și solu ția/solu țiile de virtualizare prev ăzute în cadrul solu ției ofertate
 software -ul trebuie licen țiat pentru întreg echipament ul de stocare și func ționalit ățile minim e
obligatorii solicitate de entitate contractant ă, indiferent de capacitatea inițială și viitoarea a
acestuia
 Echipament ul de stocare va fi ofertat și livrat cu minim următoarele func ționalit ăți de baz ă incluse :
o Thin Provisioning, mecanism de alocare virtuala a capacit ății de stocare;
o Snapshot, pentru realizarea copiilor locale instantanee (minim 256 de sesiuni), manual și
mod programatic cu opțiune de reten ție și ștergere automat ă a acest ora atunci când
expira (S cheduled Snapshot);

99
o Clonare, pentru realizarea copiilor locale integrale, cu impact minimal asupra
performan țelor echipament ului de stocare;
o Echipament ul trebuie s ă includ ă func ționalit ăți care permit resincronizarea copiilor locale
integrale, de tip clon ă, fără rescrierea în totalitate a acestora da că exist ă date istorice,
chiar și după intervale lungi de timp sau chiar daca relația dintre volume a fost eliminat ă
la un moment dat;
o Crearea de volume virtuale ( VVOLs), compatibile cu solu ția/solu țiile de virtualizare
utilizate în cadrul solu ției integrate ofertate
 administrare prin consola tip WEB/GUI și CLI
 Management ul tuturor func ționalit ăților se va realiza prin intermediul unei interfe țe unice,
centralizat, cu suport pentru integrare LDAP.
 sistemul de administrare WEB/GUI, va permite cel puțin realizarea următoarelor activit ăți:
o Creare, ștergere , modificare grupuri diskuri fizice și/sau virtuale
o Creare, ștergere , modificare volume, LUN -uri
o Creare grupuri consistente de volume
o Definire, modifi care, ștergere servere (tip hosts sau targets) și grupuri de servere
o Definire, modificare, ștergere porturi FC per sistem și per server (host)
o Definire, modificare, ștergere politica copiere la distan ță, adăugare volume, creare
grupuri (tip storage replication)
o Creare, modificare, ștergere utilizatori și roluri de tip: citire, audit, editare, administrator,
service – sau similar.
o Crearea de rapoarte istorice sau diagrame de performan ță în timp real minim pentru:
 Grad încărcare discuri fizice, statistici performan ță (num ăr de IO, mărime date
transferate – ex. KBs/sec, timpi de răspuns în ms)
 Grad de utilizare porturi, viteza transfer, volum date transferate, statistici
performan ță (num ăr de IO, mărime date transfera te – ex. KBs/sec, timpi de
răspuns în ms)
 Date statistice cu privire la volume și grupuri/seturi de volume
 Grad de utilizare controllere, încărcare procesoare, performan ță și încărcare
memorie cache
 Statistici LUN, performan ță pe fiecare LUN ( num ăr de IO, mărime date transferate
– ex. KBs/sec, timpi de răspuns în ms)
 Vizualizare alerte, probleme discuri fizice, grupuri, volume, porturi FC și ethernet
etc.
 Monitorizarea performan ței sistemului și auditarea log -urilor în manier ă istoric ă
(generare și vizualizare rapoarte pentru 1 zi, 7 zile, 30 de zile etc)

Solu ția livrat ă va include și minim câte o pereche de switch -uri de tip FC cu porturi de minim 16Gb ps
în fiecare centru de date, care s ă asigure conectarea redundant ă a tuturor porturilor FC solici tate ale
tuturor echipamente lor livrate. Se vor livr a toate cablurile și SFP -urile necesare conect ării redundante
a tuturor porturilor FC solicitate pe toate echipamente le livrate

100
3.4.1.5 Sistem de stocare NAS

Aceste echipamente vor g ăzdui datele aferente arhivei și depozitelor de documente , mediilor virtuale
de test/dev, depozitul de log -uri și alte date cu cerin țe mai sc ăzute de performan ță.
Se va livra un echipament în fiecare centru de date, fiecare cu urm ătoarele caracteristici min imale:
 Echipament de stocare de tip NAS (Network Attached Storage) în arhitectura scalabila de tip
cluster simetric multi -controller/ multi -node, fără punct singular de defect (single point of failure) ,
având cel puțin 8 controller e active;
 Montare în rack standard, cu posibilitatea mut ării în alt rack dup ă dorin ță
 Echipament ul ofertat va avea instalat ă o capacitate de stocare util ă de cel puțin 1150 TB
(extensibil pân ă la minim 8PB brut, minim 1PB în acela și sistem de fi șiere), configurat ă astfel încât
sistemul de stocare să permit ă func ționarea , fără pierderea de date, fără întreruperea serviciilor,
în cazul defect ării a oricăror trei discuri instalate în sistem respectiv în cazul defect ării unui întreg
controller/node instalat în sistem;
 Extinderea spațiului de stocare trebuie să se poat ă realiza în timpul func ționarii sistemului, fără a
afecta activitatea deservit ă de acesta, fără întreruperea accesului la date.
 Pentru a avea o încărcare echilibrat ă, sistemul de stocare trebuie să realizeze în mod automat
relocarea și rebalansarea datelor pe toate nodurile din sistem atunci când sunt adăugate disk-uri/
node -uri noi, respectiv când sunt retrase disk -uri/ node -uri din sistem, fără întreruperea accesului
la date.
 Capacitatea totala a memoriei RA M instalate în sistemul de stocare trebuie s ă furnizeze cel puțin
192 GB memorie cache read&write partajat ă la nivel global.
 Adițional , sistemul de stocare ofertat va avea instalat cel puțin 9600 GB capacitate de stocare
brut ă realizata pe module SSD/flash , cu rol de cache read&write pentru date/metadate.
 Sistemul de stocare ofertat trebuie să permit ă modificarea în mod flexibil a nivelului de protecție
a datelor, la nivel de fișier, director, subdirector al sistemului de fișiere, fără întreruperea accesului
la date.
 Sistemul de stocare ofertat trebuie să realizeze reconstruirea în mod inteligent a datelor de pe
discurile defecte înlocuite , fără a fi necesar ă reconstruirea spa țiilor libere de pe discuri. De
asemenea , sistemul de stocare trebuie să permit ă definirea unui spațiu de stocare cu rol de
rezerv ă activ ă sau hot -spare.
 Înlocuirea discurilor defecte trebuie să se poat ă realiza cu sistemul de stocare în func țiune , fără
întreruperea accesului la date.
 Pentru conectarea host -urilor (front -end), s istemul de stocare trebuie să fie echipat cu cel puțin
16 porturi 10 G bps Ethernet cu module optice SFP+ incluse.
 Interconectarea redundant ă a node -urilor/controller -elor din sistemul de stocare (back -end) se va
face pe o solu ție de interconectare redundant ă distinct ă, dedicat ă exclusiv acestui sistem , alocând
fiecărui controller minim 20Gbps .
 Sistemul de stocare trebuie să includ ă suport (indiferent de capacitatea de stocare și num ărul de
utilizatori) pentru următoarele protocoale de acces date: NF S v3 și v4, SMB1 /2/3, FTP, HTTP.
 Orice director al sistemului de fișiere trebuie să poat ă fi configurat pentru acces de către clien ți
conecta ți prin protocol SMB și NFS , eventual simultan ;
 Sistemul de stocare trebuie să includ ă suport pentru conectarea, in diferent de num ăr, a clien ților
de tip Microsoft Windows, UNIX, Linux, MacOS .

101
 Sistemul de stocare trebuie să includ ă suport pentru balansarea, pe baz ă de politici definite de
către administrator, a conect ării clien ților între toate nodurile de stocare din sistem, suport pentru
failover dinamic, failback și rebalansarea automat ă a conexiunilor clien ților NFS.
 Sistemul trebuie s ă permit ă replicarea asincron ă automat ă a datelor între cele dou ă centre de
date
 Sistemul trebuie să permit ă integrarea cu serverul de antivirus pentru scanarea datelor pe baza
unor politici definite de utilizator, pe directoare, la intervale regulate respectiv la accesarea
fișierelor .
 Autentificarea utilizatorilor trebuie să se poat ă realiza prin Acti ve Directory, LDAP, NIS, local (prin
useri defini ți pe sistemul de stocare).
 Sistemul trebuie să includ ă suport pentru configurarea unor limite ale spațiului utilizat in sistem
(Quota Management ) la nivel de utilizator, grup de utilizatori, director.
 Sistemul trebuie să includ ă suport pentru configurarea unor limite ale benzii ocupate de un anumit
utilizator sau grup de utilizatori, precum și per export de fișiere.
 Sistemul trebuie să permit ă monitorizarea resurselor în timp real și să alerteze automat , inclusiv
prin e -mail, administratorul de sistem, clasificând evenimente le apărute după importan ța lor;
evenimente le semnalate vor cuprinde și starea discurilor, a acumulatoarelor interne, a
temperaturilor, starea surselor de alimentare , a ventilatoarelor .
 Sistemul de stocare ofertat trebuie să includ ă instrument e pentru a realiza cu ușurința rapoarte
personalizate pe orice interval de timp pentru a furniza informa ții cheie de performan ță, utilizare
a sistemului;
 Instrument ele de monitorizare și raportare grafic ă a performan țelor trebuie să includ ă cel puțin :
o traficul de date pe interfa ța de rețea, controller , client, protocol
o ratele de operare pe protocol și laten țele înregistrate pe protocol, client sau pe clasa de
operare
o nivelul de utilizare a procesoarelor pe fiecare nod/controller
o statistici despre throughput -ul pe discuri
 Sistemul de stocare trebuie să includ ă suport nativ pentru auditarea evenimente lor de
configurare, acces prin protocoale SMB, NFS și să permit ă integ rarea cu aplica ții de auditare de la
diver și produc ători – se va realiza inclusiv integrarea cu aplica ția de log management inclus ă în
soluția de fa ță.
 Configurarea și administrarea sistemului de stocare trebuie să se realizeze prin interfa ță
incorporata, web (https) și CLI.
 Sistemul trebuie să includ ă capabilit ăți de administrare bazat e pe roluri predefinite.

3.4.1.6 Sistem de backup

Aceste echipamente vor asigura con tinuitatea activit ății și vor g ăzdui arhiva fizic ă în format electronic.
Se vor avea în vedere cel puțin următoarele componente:
o Sistem de backup pe disc – minim 26 0TB util în fiecare centru de date
o Solu ție de backup/recovery pentru toate componentele SIMS, integrat ă nativ cu mediul virtual
și cu sistemul de backup pe disk
o Sistem de backup pe band ă principal (inclusiv pentru arhivarea legal ă) – în site -ul I (copii ale
benzilor vor fi disponibile și în site -ul II pentru orice eventualitate, dar depozitate offline)

102
o Minim 4 unit ăți de band ă LTO-8, conectare FC
o Minim 150 slot -uri pentru benzi
o Sistem de backup pe band ă secundar (operativ) – în site -ul II (în caz de necesitate se vor putea
accesa exemplarele copie ale benzilor arhivei legale depozitate aici)
o Minim 2 unit ăți de band ă LTO-8, conectare FC
o Minim 32 slot -uri pentru benzi
Toate slot -urile se vor popula cu benzi LTO -8, în ambele site -uri. Suplimenta r se vor livra benzi
pentru înc ă minim 2PB de documente PDF compresate, pentru amplasare în alte loca ții sigure.

Solu ția de backup va avea urm ătoarele caracteristici minimale:
 Trebuie să fie bazat ă pe module de aplica ții software ce vor asigura rularea unor procese automate
de salvare și restaurare a datelor, protec ția aplica țiilor, cât și monitorizarea acestor servicii și a
echipament ului de backup pentru deduplicarea și păstrarea datelor salvate.
 Licen țierea soluției software trebuie să acopere întreaga capacitate de calcul a sistemelor centrale
ale sistemului integrat .
 Asigur ă protec ția întregului mediu virtual (cu un num ăr nelimitat de ma șini virtuale) cu
posibilitatea de a extinde politicile de protecție pentru servere fizice și a aplica țiilor ce ruleaz ă în
această infrastructur ă.
 Poate integra pe viitor și protec ția stațiilor de lucru de tip MS Windows, Linux și MacOS.
 Susține deduplicarea datelor la sursa sau destina ție prin segmentare și ajustare variabil ă a
blocurilor de date, indiferent de tipul de rețea.
 Procesul de deduplicare trebuie să se desf ășoare continuu, “inline”, fără stocare temporar ă a
datelor, iar factorul de deduplicare să fie global indiferent de sursa acestor date.
 Agenții soluției comunic ă direct cu echipament ul de backup, indiferent de rețeaua de transport,
astfel încât fluxurile de date de la sursa către destina ție sa nu treac ă prin aplica ția de salvare și
restaurare a datelor.
 Proteje ază sisteme de calcul de tipul Microsoft Windows, Linux CentOS, Debian, Free BSD, Red
Hat, SuSE, Ubuntu, Oracle Linux, UNIX și Solaris.
 Protejeaz ă consistent bazele de date Oracle, MS SQL Server, PostgreSQL și DB2, inclusiv baza de
date ofertat ă
 Procesele de salvare transfer ă întotdeauna către echipament ul de backup doar segmentele de
date noi sau cele modificate fa ță de procesul anterior.
 Oferă posibilitat e de restaurare direct din seturi de backup de tip “full backup” indiferent de
politicile de salvare apli cate.
 Echipament ul destinat protecție i datelor va realiza întotdeauna aceste seturi de date actualizate
fără necesitatea de a transfera alte date prin rețea după desf ășurarea ultimei politici de backup.
 Permite monitorizarea tuturor componentelor de salvare și restaurare, deduplicare și stocare a
datelor, într-o singur ă aplica ție grafic ă dedicat ă oferit ă de produc ător.
 Serviciul de monitorizare și analiz ă trebuie să-și poat ă extinde func ționalit ățile asupra unor
aplica ții similare de protecție a datelor de la alți produc ători prin rapoarte detaliate și analiz ă
global ă.
 Permite utilizatorilor s ă caute informa ții după cuvinte cheie în datele salvate și indexate prin
intermediului unei interfe țe de tip web. Utilizatorul va putea căuta și recupera fișierele dorite după
conținut direct din interfa ța web.

103
 Include servicii de replicare a mașinilor virtuale, sincron și asincron, local sau la distan ță, cu
jurnalizarea și păstrarea tuturor IO -urilor pe o perioada de timp determinat ă.
 Fiecare echipament de backup trebuie să includ ă:
o capacitate util ă de minim 260TB și să poat ă dubla aceast ă capacitate prin adăugare de
sertare adiționale cu discuri SAS.
o minim 4 porturi de 16 Gbps FC și minim 4 porturi de 10 Gbps Ethernet cu conector SFP+
o două surse de alimentare
o protecție a discurilor SAS prin RAID 6 și disk hot -spare.
 Acest echipament trebuie să fie livrat sub form ă de appliance fizic ( echipament fizic integrat f ără
posibilitatea de a instala alte aplica ții sau sisteme de operare fa ță de func ționalit ățile incluse de
produc ători, pentru asigurarea rezilien ței și a securit ății).
 Echipament ul trebuie să utilizeze un factor global de deduplicare pentru toate datele salvate sau
arhivate, indiferent de surs ă, protocol, sau interfa ța de rețea prin care au fost transferate.
 Echipament ul trebuie să permit ă integrarea cu protocoale multiple ca NFS, CIFS, VTL, NDMP și
OST.
 Transferul datelor de la surs ă la destina ție trebuie să poat ă fi criptat, la fel și păstrarea criptat ă a
segmentelor de date unice, deduplicate, indiferent de politicile de reten ție.
 Segmentele de date unice deduplicate trebuie să poat ă fi protejate în echipament în cazul unor
eventuale acțiuni de ștergere prin interven ții neautorizate.
 Echipament ul trebuie să susțină mecanisme de protecție și corec ție a datelor salvate, a sistemului
de fișiere, prin care asigur ă verificarea continu ă a segmentelor de date deduplicate și
disponibilitatea de resaturarea granular ă sau complet ă a fiecărui proces de backup finalizat cu
succes.
 Echipament ul de backup trebuie să poat ă replica la distan ță doar segmentele unice de date
deduplicate î ntr-un sistem similar, fizic, virtual sau integrat într-un mediu de tip cloud.
 În cazul unor politici de protecție în caz de dezastru, software -ul de backup trebuie să permit ă
replicarea î n sediul distant, fără costuri suplimenta re, astfel încât o restaurare a datelor în locația
de distan ță să poat ă porni în regim de urgen ță cu catalogul actualizat al proceselor de backup.
 Atât componenta software c ât și cea hardware trebuie să permit ă integrarea cu alte aplica ții de
monitorizare și control prin integrare cu interfe țe software standard, de exemplu REST API.

Sistemul de backu p automatizat pe benzi magnetice va stoca o copie a tuturor documente lor arhivei
electronice, precum și toate tipurile de informa ții utile pentru restaurarea componentelor software și
a datelor. Cerin țe minimale pentru fiecare librărie de band ă:
 Tehnologie unități de citire și medii de stocare de tip LTO Ultrium 8
 Scalabilitate: Minim 3,000 TB
 Suport pentru minim 21 drive -uri
 Suport pentru minim 270 sloturi casete de band ă
 Suport pentru 5 sloturi import -export
 Minim dou ă surse de alimentare redundante pentru fiecare unitate controller sau unitate de
expansiune cu benzi
 Display LCD pentru operare și administrare cel puțin pentru: stare sistem, diagnostice hardware/
software, loguri de sistem , configur ări și setări , inventariere.
 Aplica ție pentru management cu acces de la distan ță , port dedicat 1GB Ethernet , conectare web.
Se vor putea gestion a minim urm ătoarele opera țiuni: stare sistem , diagnostice hardware/
software, loguri de sistem , configur ări și setări , inventariere , firmware up date.

104
 Suport pentru Linear Tape File System (LTFS)
 Suport pentru criptare admin istrat ă din aplica ții externe și din controller intern
 Failover automat pentru porturi și drive -uri de band ă
 LTO cleaning tape, minim 1 bucat ă pentru fiecare 40 sloturi band ă
 Format rackmount cu kit de de montare de 19” inclus

3.4.2 Rețelistic ă și Securitate IT

3.4.2.1 Arhitectura de re țea

Arhitectura general ă este formata din doua site -uri distincte sub forma unor centre de date. Centrele
de date vor putea deservi aplica ții într -o maniera Active/Active, pentru cele doua centre de date DC1
si DC2, cu o scalabilitate de 1:1 in ceea ce prive ște echipamente le active de re țea.
Fiecare Centru de date va deservi utilizatori externi afla ți in Internet prin intermediul unor elemente
de balan sare în Front -end c ătre serverele de aplica ții aflate in Back -end, respectiv aplica ții sau
utilizatorii externi care vor putea interoga prin intermediul REST API alte aplica ții aflate în zona de
Back -end.
Pentru a îndeplini cerin țele de înalt ă disponibilit ate de tip Active/Active, cele dou ă centre de date vor
fi construite respectând criteriile cele mai stricte de segmentare , prin folosirea de “zone de securitate”
protejate de echipamente de tip Next Generation Firewall (NGFW) si Web Application Firewall (WAF).

Zonele de securitate
Pentru segmentare a cat mai eficientă a centrelor de date acestea vor fi împ ărțite în mai multe zone
începând cu cea mai nesigur ă zonă și terminând cu cea mai s igură zonă din punct de vedere al
importan ței datelor de ținute, respectiv:
• Zona EXTERN Ă (WAN) – inclusiv echipamente de tip Switch Agregare WAN, Router WAN;
• Zona de SERVICII (Front -End) – inclusiv Echipamente de redistribu ție a accesului la serviciile
de aplica ție (Global Service Load Balancer, GSLB), Echipamente de protecție a serviciilor de aplica ție
(Application Delivery Controller, ADC, cu func ții integrate de tip bastion host și de protecție a
aplica țiilor, WAF), Switch Core Campus;
• Zona INTERN Ă (Back -End) – inclusiv Echipamente de redistribu ție local ă a sarcinii de procesare
a serviciilor de aplica ție (ADC, cu func ții de tip load balancing, LB), Switch Core DC, Switch Edge DC.
Delimitarea zonelor astfel definite, implementa rea mecanismelor de protecție și aplicarea politicilor
de acces între acestea, se realizeaz ă de c ătre echipamente de tip Next Generation Firewall (NGFW).
Zonarea re țelei se va putea astfel implementa fie prin implementa rea de subre țele protejate
(Screened Subnet), relativ la interfe țe NGFW respectiv alocate, și/sau ca zone de protecție (”DMZ”)
între parti ții ale echipamente lor NGFW.

105
Zona EXTERN Ă (WAN)
În zona de agregare WAN vor fi prezente, pentru fiecare centru de date în parte, câte o pereche de
echipamente de tip Switch Agregare WAN configurate în modul Stack. Aceste perechi de echipamente
vor avea rolul de a agrega liniile de 10G de Internet și a le prezenta într-un mod redundant c ătre
echipamente le de tip Router WAN.
Echipamente le tip Switch Agregare WAN
Pentru fiecare centru de date, vor exista c âte dou ă echipamente cu 16 porturi de acces de 10G care
să suporte 16 module de tipul SFP+ 10 Gigabit Ethernet. Aceste porturi vor fi suficiente pentru a agrega
liniile de Internet existente și a le trimite c ătre echipamente le de tip Router WAN. Echipament ul va
avea incluse (built -in), în configura ția de baz ă, modulele de stack și cablurile aferente pentru stacking
date.
Echipamente le de tip Router WAN
Aceste echipamente , câte dou ă per loca ție, vor agrega, ruta și oferi redundan ță din punct de vedere
IP pentru liniile de Internet prezentate în mod redundant de c ătre echipamente le Switch Agregare
WAN. Acest echipament trebuie să asigure func ționalit ăți de rutare, cu ajutorul protocoalelor BGP,
OSPF. Capacitatea de rutare va trebui să fie de minimum 20 Gigabit/sec iar aceasta licen ță va fi inclu să
odat ă cu echipament ul.
Echipament ul de tip Router WAN va avea interfe țe la nord în Zona EXTERN Ă (WAN) iar la sud în Zona
de SERVICII (Front -End).

Zona de SERVICII (Front -End)
În aceast ă zonă de re țea vor fi interconectate și configurate cel puțin echipamente le de tip GSLB și de
tip ADC/WAF. Aceasta zon ă se va învecina la sud cu Zona INTERN Ă (Back -End).
Cererile primite via Internet vor fi rutate de c ătre echipamente le de tip Router WAN și direc ționate în
aceasta Zon ă de SERVICII (Front -End), de unde, un echipament tip GSLB va verifica parametrii necesari
și va direc ționa cererea c ătre resursele din Centrul de Date 1 (DC1) sau Centrul de Date 2 (DC2) în
func ție de parametrii monitoriza ți.
Pentru cererea provenit ă din Internet, astfel redistribuit ă de nivelul GSLB, traficul va fi filtrat în mod
reverse -proxy prin func ționalit ățile de tip Web Application Firewall și Anti -DDoS ale echipamente lor
de tip ADC/WAF situate în aceea și Zon ă de SERV ICII (Front -End), pentru identificarea anomaliilor
și/sau a atacurilor la nivel de aplica ție iar, mai apoi, va fi trimis c ătre serverele de aplica ții aflate in
Back -End (direct, sau prin intermediul unui nivel suplimenta r de redistribu ție asigurat la nivel ADC/LB).
Echipamente le de tip Switch Core Campus
Pentru fiecare Centru de date, vor exista c âte dou ă echipamente switch modulare de tip Core
Multilayer Switching, cu capabilit ăți de virtualizare la nivel de re țea și capabilit ăți de conectare 10G și
40G.
Echipamente le de tip Switch Core Campus vor fi virtualizabile și vor avea și posibilitatea de operare,
automatizare și programabilitate de tip “Software Defined”.

106
Aceste echipamente vor avea rolul unui switch nivel Collapsed Core -Distribution, care va agrega la
nord echipamente le de rutare Router WAN, pe rela ția cu Zona EXTERN Ă (WAN), iar la sud
echipamente le de tip Switch Core Datacentre, pe rela ția cu Zona INTERN Ă (Back -End).
Clusterul de echipamente de tip GSLB, ADC/WAF și echipamente le tip NGFW se vor conecta redundant
la ambele șasiuri modulare, respectiv prin cel puțin două legături redundante de 10 Gigabit Ethernet
fiecare.
Echipamente le de redistribu ție a accesului la servicii (GSLB)
Aceste echipamente de balansare, c âte dou ă pentru fiecare centru de date, vor direc ționa cererile pe
baza “Fully Qualified Domain Name” c ătre Centrul de date (DC1) sau Centrul de Date (DC2) în func ție
de parametrii monitoriza ți.
Aceste echipamente vor func ționa în disponibilitate înalt ă pentru a evita devierea traficului dintr -un
Centru de Date în altul, în cazul unei mentenanțe sau disfunc ționalit ăți la una din unit ățile de tip GSLB,
dar în lipsa unei alte defec țiuni la nivelul sistemelor care sus țin serviciile protejate în centrul de date
de baz ă.
Aceste echipamente trebuie dimensionate , pe baza cerin țelor detaliate mai jos, pentru a putea sus ține
traficul de vârf posibil pe liniile de acces internet de 20Gb.
Echipamente de protecție a serviciilor de aplica ție (ADC/WAF)
Aceste echipamente de protecție a serviciilor de aplica ție, câte dou ă pentru fiecare centru de date,
vor filtra cererile HTTP/HTTPS venite din Internet și destinate (direct, sau prin intermediul unui nivel
suplimenta r de redistribu ție asigurat la nivel ADC/LB) serverelor de apl icații din Back -End. Ele vor oferi
protecție WAF și anti -DDoS.
Aceste echipamente vor func ționa în disponibilitate înalt ă pentru a evita devierea traficului dintr -un
Centru de Date în altul, în cazul unei mentenanțe sau disfunc ționalit ăți la una din unit ățile ADC/WAF
dar în lipsa unei alte defec țiuni la nivelul centrului de date de baz ă.
Echipamente le tip ADC/WAF se vor conecta redundant de Echipamente le de tip Core Switching Centru
de Date cu c âte o leg ătură de 10G Ethernet în fiecare dintre șasiuri.

Zona INTERNĂ (Back -End)
Cea mai sigur ă zonă va fi cea de Back -end sau zona de încredere maxim ă. În aceast ă zonă vor fi
găzduite containere logice separate prin VLAN -uri de date și terminate în Next Generation Firewall
Tier 2 pentru a controla atât traficul nord -sud din zonele de mai puțin ă încredere în Backend cât și
traficul est -vest între containerele logice din zona de încredere maxima Back -End.
Echipamente le de tip Switch Core DC
Aceste echipamente , dou ă la num ăr pentru fiecare Centru de Date, vor putea implementa func țiile
specifice rolului Spine într -o arhitectur ă de re țea de tip “Spine & Leaf” și vor avea o func ție de
virtualizare fiind interconectate prin conexiuni redundan te tip 40G, pentru a realiza eficient aceast ă
func ție (virtualizare la nivel de re țea).
Num ărul de porturi prezente pe switch va fi de 48 de porturi 10/25G și 6 porturi uplink de 40/100G.
Switch -ul va putea adresa și arhitectura FCoE fiberchannel.

107
Aceste echipamente se vor conecta la nord, de echipamente le de tip Campus Core Multilayer
Switching prin multiple leg ături de 10GigabitEthernet, vor conecta direct echipamente de tip Local
Load Balancer, echipamente de tip Next Generation Firewall Tier 2 care inc lude și controale de
securitate. De asemenea , aceste echipamente de tip Centru de Date switching vor conecta redundant
și o alt ă serie de echipamente de switching Centru de Date (Leaf), acestea din urm ă având func ția de
a interconecta o serie de alte echip amente .
Se vor conecta în aceste echipamente sau în leaf -uri toate porturile 10G solicitate pe toate
echipamente le.
Echipamente le de tip Switch Edge DC
Aceste echipamente , dou ă la num ăr pentru fiecare loca ție Centru de Date, vor putea implementa
func țiile specifice rolului Leaf într -o arhitectur ă de re țea de tip “Spine & Leaf”, conectate redundant
în nivelul Spine, vor avea o func ție de virtualizare, la fel ca și DC Core, și vor fi interconectate prin
conexiuni redundante tip 40G pentru a realiza eficient aceast ă func ție (virtualizare la nivel de re țea).
Aceste echipamente se vor interconecta o serie de echipamente de stocare și prelucrare de date.
Echipamente le de tip Switch de Management
Aceste echipamente , de tip switch de nivel 2 OSI, câte unul per ce ntru de date, vor avea rolul de a
agrega interfe țele de management ale tuturor echipamente lor fizice din re țea.
Echipamente le de redistribu ție local ă a sarcinii de procesare a serviciilor (ADC/LB)
Aceste echipamente de redistribu ție a sarcinii de procesare a aplica țiilor, c âte dou ă pentru fiecare
centru de date, vor direc ționa cererile în func ție de parametrii monitoriza ți.
Aceste echipamente vor func ționa în disponibilitate înalt ă pentru a evita dezechilibrarea proces ării
locale a sarcinii de serviciu, în cazul unei mentenanțe sau disfunc ționalit ăți la una din unit ățile ADC/LB
dar în lipsa unei alte defec țiuni la nivelul echipamente lor din Zona INTERN Ă (Back -End) deservit ă.
Echipamente le tip ADC/LB se vor conecta redundant de Echipamente le de tip Core Swi tching Centru
de Date cu c âte o leg ătură de 10G Ethernet în fiecare dintre șasiuri.
Echipament tip Next Generation Firewall (NGFW)
Pentru fiecare centru de date, vor exista câte o pereche de echipamente Next Generation Firewall
care vor segrega și controla traficul nord -sud și est-vest. Aceste echipamente vor putea aplica m ăsuri
de Prevenirea Intruziunii (IPS) între traficul est -vest între containerele de date.
Echipamente le Next Generation Firewall se vor putea conecta redundant la switch -urile de tip Cor e
Switching Centru de Date prin 2 -4 leg ături redundante de 10/40 Gigabit Ethernet cu fiecare dintre cele
zonele de re țea delimitate.
Echipamente le NGFW vor putea fiecare inspecta minim 30 Gigabit/sec de trafic cu inspec ție FW +
Detec ția Aplica țiilor, dar nu mai pu țin de 20Gb IPS + Antivirus/Antimalware + Detec ția Aplica țiilor,
pentru a putea sus ține prelucrarea traficului maxim posibil prin leg ătura Internet prev ăzută.
Echipament de Management NGFW
Solu ția de zonare și protec ție a re țelelor implementată de echipamente le de tip NGFW va oferi o
protecție sporit ă față de arhitecturi tradi ționale. Pentru a adresa nivelul suplimenta r de complexitate
al acesteia, se impune utilizat ă o solu ție de tip Network Security Policy Management (pentru

108
Management ul fluxu rilor de activit ăți administrative pentru multiple echipamente și, respectiv, parti ții
de echipamente de tip NGFW).
Solu ția de management a politicilor de Securitate pe multiple firewall -uri va menține un control
coerent al politicilor de Securitate peste multiple firewall -uri fizice sau virtuale, evitând astfel crearea
de bre șe de securitate în sistem.
Solu ția ofertat ă se va comporta atât pasiv, prin analiza situa ției concrete și identificarea poten țialelor
breșe de securitate din sistem, cât și activ, prin împingere de configura ții către echipamente le firewall.
Aceste func ționalit ăți vor fi asigurate prin instan țe dedicate de tip server în mediu virtual și va putea
face Management ul pentru echipamente le Next Generation Firewall (NGFW).

Mai departe se prezint ă caracteristicile principale (configura ție și func ționalit ăți minimale, obligatorii
în configura ția solicitat ă dacă nu este precizat explicit caracterul op țional al acestora) pentru
echipamente le menționate mai sus

3.4.2.2 Protec ția re țelelor

Solu ția de zonare a re țelelor și de protecție (la nivel de re țea) a comunica țiilor se va implementa în
fiecare centru de date în parte prin câte un cluster de tip NGFW (firewall next generation) compus din
câte dou ă dispozitive identice specializat e de securitate pentru rețele implementa te ca hardware
dedicat monobloc , fiecare echipament având surse de alimentare și ventilatoare redundante .
Clusterele trebuie s ă poat ă fi configurate atât activ -pasiv, cât și activ -activ, dup ă cum se va considera
optim în faza de analiz ă. Echipamente le trebuie s ă monitorizeze și să detecteze schimb ările în
starea lor din punct de vedere hardware și software, s ă poat ă monitoriza starea conexiunilor de re țea
la nivel hardware (li nk state) precum și disponibilitatea re țelei prin monitorizare activ ă (ping) astfel
încât s ă poat ă iniția automat comutarea sistemului de redundan ță.
Arhitectura intern ă a acestor dispozitive trebuie s ă asigure resurse de procesare dedicate pentru
management , separate complet de resursele utilizate pentru analiza și controlul fluxurilor de date.
Pentru a face fa ță vârfurilor de trafic previzionate, fiecare echipament trebuie s ă poat ă procesa minim
20 Gbit/s pentru trafic de date cu con ținut controla t dpdv securitate ( protecție activat ă simultan
pentru scanare de tip anti -virus, anti -spyware, IPS și filtrare web). Echipament ul va asigura protec ția
traficului pentru cel puțin 8.000.000 de conexiuni simultane și va permite crearea de minimum
200.000 ses iuni noi pe secund ă.
Fiecare echipament trebuie s ă aibă cel puțin următoarele posibilit ăți de interconectare:
o Porturi pentru trafic de date:
o 4 porturi Ethernet 100/1000/10000 Mbps.
o 12 sloturi SFP/SFP+ (1000Mbps sau 10000Mbps, in fun ctie de tipul de transceiver
instalat)
o 2 sloturi QSFP+/QSFP28 (40Gbps sau 100Gbps, in functie de tipul de transceiver
instalat)
o Porturi pentru Management :
o 1 port Ethernet 10/100/1000 Mbps
o 1 port serial RS232 cu conectica RJ45 (port consol ă)

109
o Port pentru configurare offline
o 1 port USB tip A

Echipamente le se vor interconecta în cadrul cluster -ului propriu pe 40Gb. Fiecare echipament se va
conecta la fiecare switch campus din loca ția proprie în parte pe minim 4x10Gb.
Echipament ul trebuie s ă permit ă integrarea cu ferma de virtu alizare din cadrul solu ției în a șa fel încât
firewall -ul să poat ă prelua automat informa ții privind starea și configurarea ma șinilor virtuale
(de exemplu numele, adresele IP alocate, re țelele virtuale conectate), și să poat ă folosi aceste
informa ții în definirea politicilor de securitate. Politicile construite astfel trebuie s ă clasifice în mod
eficient și să controleze traficul ma șinilor virtuale, orice modificare a acestor adrese IP utilizate de
mașinile virtuale nu trebuie s ă implice necesitatea de a schimba configura ția politicilor de securitate.

Echipament ul trebuie s ă poat ă func ționa în:
o mod router (Layer 3 al modelului OSI)
o mod switching (Layer 2 al modelului OSI)
o mod transparent (f ără adrese IP configurate pe interfe țele de control a traficului d e rețea și
fără segmentare în domenii de coliziune separate în ceea ce prive ște Ethernet / CSMA)
o mod de ascultare pasiv ă (sniffer).
Modul de operare trebuie să poat ă fi setat în configura ția interfe ței de rețea, iar sistemul trebuie s ă
fie capabil de a lu cra în aceea și timp în toate modurile de mai sus pentru interfe țe diferite în aceea și
instan ță logic ă unic ă a sistemului (un sistem virtual, domeniu virtual etc).
Echipament ul trebuie s ă ofere suport pentru protocolul Ethernet cu VLAN tagging conform
standardului IEEE 802.1Q și trebuie s ă permit ă crearea de sub -interfe țe VLAN pentru
interfe țele de rețea configurate în mod L2 (switching) și L3 (routing). Dispozitivul trebuie s ă permit ă
definirea unui num ăr de 4094 de tag -uri VLAN.
Trebuie s ă permit ă configurarea unui num ăr minim de 125 routere virtuale, fiecare având
tabel ă de rutare separat ă pentru a face posibil ă func ționarea cu multiple tabele de rutare într -o
singur ă instan ță a sistem ului de securitate. Dispozitivul trebuie s ă implementeze protocoale de rutare
dinamice, cu suport pentru BGP, OSPF și RIP.
Echipament ul trebuie să asigure controlul de securitate asupra traficului de rețea între zone de rețea
(zone de securitate) , la nivel de rețea, de transport și de aplica ție (L3, L4, L7).
Regulile de securitate ce definesc politica de securitate a firewall -ului trebuie s ă poat ă defini
zonele de securitate sursa și destina ția, adresele IP ale clien ților și serverelor, protocoalele controlate
și serviciile de rețea (porturi TCP/IP), aplica ții, categorii de URL, utilizatorii afecta ți, controale
specifice de securitate, mod de jurnalizare a evenimente lor (log -uri) și modalitatea de gestionare a
lățimii de bandă de rețea (prioritate minim ă, lățime de band ă garantat ă, lățime de band ă maxima
pentru sesiuni marcate prin Diffserv).
Echipament ul trebuie s ă acționeze în conformitate cu principiul „Minimal Privilege“, adic ă să blocheze
toate aplica țiile cu excep ția celor permise explicit și pentru care sunt indicate
normele de politic ă de securitate.

110
Trebuie s ă identifice în mod automat aplica ții indiferent de portul TCP/IP utilizat, de criptare și de
protocoale de tunelare (inclusiv P2P și IM). Identificarea de aplica ție trebuie s ă aibă loc cel puțin prin
semn ături specifice traficului de aplica ție și prin analiza euristic ă.
Echipament ul trebuie s ă identifice corect aplica țiile indiferent de adresele IP sau intervalul de porturi
TCP/IP accesate, chiar presupunân d că toate aplica țiile vor genera trafic pe toate cele 65535 porturi
posibile. Echipament ul trebuie s ă asigure identificarea aplica țiilor pentru tot traficul maxim de baza
suportat de minim 30Gbit/s
Echipament ul trebuie să permit ă configurarea regulilor de securitate astfel încât accesul la aplica ții să
fie permis doar pe porturile standard ale aplica ției sau pe porturi specificate explicit. Protec ția
aplica țiilor trebuie să se realizeze de c ătre echipament ul firewall f ără a necesi ta module specializate,
software sau echipamente adiționale.
Echipament ul trebuie să asigure detec ția a cel puțin 2000 aplica ții pe baza semn ăturilor definite de
produc ător.
Echipament ul trebuie s ă permit ă crearea manual ă de semn ături pentru aplica ții adi ționale, direct pe
dispozitiv în interfa ța de administrare, f ără a necesita instrument e externe sau implicarea
produc ătorului.
Echipament ul trebuie s ă permit ă definirea și alocarea de profiluri de protecție (Antivirus, IPS, Anti –
spyware, filtrare URL, blocare fi șiere) distincte pentru fiecare aplica ție diferit ă din cadrul aceleia și
reguli de securitate, inclusiv pentru aplica ții ce utilizeaz ă acela și port IP și inclusiv pentru aplica ții
definite manual de ad ministrator.
Echipament ul trebuie s ă permit ă analiza și blocarea transferului de fi șiere în aplica țiile identificate, cel
puțin pentru fi șiere de tip: BAT, CAB, DLL, DOC, DOC criptat, DOCX, PPT, PPT criptat, PPTX, XLS, XLS
criptat, XLSX, RAR, RAR criptat, ZIP, ZIP criptat, EXE, GZIP, HTA, MDB, MDI, OCX, PDF, PGP, PIF, REG,
SH, TAR, text/html, TIF. Identificarea tipului de fi șier trebuie s ă se realizeze pe baza informa țiilor din
antet (header) și nu pe baza extensiei de nume.
Echipament ul trebuie s ă permit ă analiza și blocarea transferului de fi șiere în mod distinct pentru
aplica ții diferite ce ruleaz ă pe acela și port TCP/UDP (de exemplu TCP 80) și trebuie să permit ă alocarea
de profiluri separate de analiz ă și blocare pentru fiecare aplica ție în parte.
Echipament ul trebuie să permit ă definirea de ac țiuni de tip blocare sau continuare pentru prevenirea
atacurilor de tip ”drive -by download” prin afi șarea unei pagini care informeaz ă utilizatorul și eventual
permite continuarea download -ului dup ă acceptul ut ilizatorului.
Echipament ul va permite inspectarea comunica țiilor criptate SSL pentru traficul de ie șire către servere
externe (de exemplu navigarea pe Internet) precum și pentru traficul de intrare c ătre serverele
interne. Echipament ul trebuie s ă realizeze inspec ția traficului decriptat pentru detecție Antivirus, Anti
spyware, transfer de fi șiere de date, filtrare URL.
Echipament ul trebuie s ă asigure inspec ția traficului criptat SSL inclusiv pentru comunica ții ce nu
folosesc protocol HTTP, și să realizeze inspec ția traficului decriptat pentru detecție Antivirus, Anti
spyware, fi șiere de date, filtrare URL.
Echipament ul trebuie s ă poat ă fi configurat cu un set de politici de decriptare și inspec ție specific ă a
traficului SSL separat de politicile de securitate a traficului decriptat.

111
Echipament ul trebuie s ă dispun ă de o list ă actualizat ă automat de c ătre produc ător ce con ține servere
și URL -uri pentru care nu este posibil ă decriptarea traficului SSL (de exemplu aplica ții care folosesc
autentificare cu certificat digital sau care implementează verificarea certificatului serverului). Aceast ă
listă trebuie s ă permit ă invalidarea oric ărei intr ări și să poat ă fi folosit ă pentru a excepta serverele
incluse de la procesul de decriptare a traficului
Echipament ul trebuie s ă permit ă inspec ția comunica țiilor criptate Secure Shell (SSH) pentru traficul
de date, s ă detecteze și să permit ă blocarea tunel ării de alte protocoale în interiorul traficului SSH.
Identificarea utilizatorilor
Echipament ul trebuie s ă ofere posibilitatea de a stabili în mod transparent identitatea utilizatorilor
rețelei (prin integrare cu Active Directory, MS Exchange, Citrix, servere LDAP și Terminal Services).
Politica de control al accesului (firewall) trebuie s ă defineasc ă în mod precis
drepturile de acces ale utilizatorilor la serviciile și rețelele specifice, drepturi care trebuie s ă fie
Menținute chiar și atunci când utilizatorul schimb ă locația și adresa IP. Pentru utilizatorii care lucreaz ă
în sesiuni de terminal server, având astfel o adres ă IP comun ă, stabilirea identit ății trebuie s ă fie ,
de asemenea , efectuat ă în mod transparent pentru utilizator.
Echipament ul trebuie s ă aibă capacitatea de a colecta și analiza informa ții syslog de la dispozitive și
sisteme de rețea, altele decât MS Windows ( de ex. Linux sau Unix), pentru a corela
numele de utilizator cu adresele IP ale echipamente lor client de pe care utilizatorii stabilesc
conexiunea. Func ția trebuie s ă permit ă detectarea acțiunilor de Log on cât și Log off.
Echipament ul trebuie s ă identifice adresele IP originale ale sta țiilor finale pentru trafic cu antet HTTP
"X-Forwared -For" și să detecteze pe baza interog ării în Windows Active Directory utilizatorul efectiv
pentru sesiunile al c ăror trafic este trecut prin server proxy care ascunde adresa IP original ă.
Echipament ul trebuie s ă permit ă eliminarea adresei IP originale din headerele HTTP "X -Forwarded –
For" înainte de a transmite mai departe pachetele de date din cadrul sesiunii.
Protecție IPS, anti-virus , anti-spyware, Filtrare URL
Echipament ul trebuie s ă asigure, f ără componente hardware sau software adi ționale, filtrarea
accesului Web în func ție de categorii de conținut pentru servere HTTP. Baza de date cu URL -uri și
categoriile de con ținut trebuie s ă fie actualizat ă regulat în mod automat (pe baz ă de subscrip ție la
serviciul de actualizare al produc ătorului echipament ului) și trebuie s ă includ ă cel
puțin 20 de milioane de intrări URL.
Categoriile de con ținut pentru URL trebuie s ă poat ă fi folosite în defi nirea regulilor de securitate ca
adrese de destina ție pentru sesiunile controlate, separat de controlul de tip filtrare de trafic HTTP.
Echipament ul trebuie s ă ofere posibilitatea de a crea manual propriile liste de categorii de con ținut
și să le utilizeze în politicile de securitate , fără utilizarea unor instrument e externe și fără a
necesita sprijin din partea produc ătorului.
Echipament ul trebuie s ă asigure protecție Antivirus pentru aplica țiile identificate configurabil pentru
fiecare tip de de codor de protocol implementa t. Decodoarele de protocol trebuie s ă includ ă cel puțin :
http, smtp, imap, pop3, ftp, smb.
Protec ția Antivirus trebuie s ă fie realizat ă la nivelul echipament ului, f ără a necesita module
specializate adi ționale hardware sau soft ware. Baza de date de semn ături antivirus trebuie s ă fie
stocat ă în echipament și să fie actualizat ă automat și regulat de c ătre produc ătorul echipament ului,
pe baz ă de subscrip ție.

112
Protec ția Antivirus trebuie s ă poat ă fi configurat ă specific pentru fiecare regul ă de securitate. Nu se
accept ă ca func ționalitatea de antivirus s ă fie configurat ă la nivelul echipament ului, a unui modul de
securitate sau la nivelul uneia sau mai multor interfe țe specializate de securitate.
Echipament ul tr ebuie s ă asigure detec ția intruziunilor la nivel OSI Layer 7 (IPS/IDS), f ără a necesita
componente suplimenta re specializate hardware sau software. Baza de date de semn ături IPS/IDS
trebuie s ă fie stocat ă pe echipament și actualizat ă automat și regulat de către produc ătorul
echipament ului, pe baza de subscrip ție.
Echipament ul trebuie s ă permit ă configurarea profilelor de identificare IPS/IDS în mod specific pentru
fiecare regul ă de securitate în parte. Nu se accept ă ca scanarea IPS/IDS s ă se realizeze doar la nivelul
întregului echipament sau doar pentru interfe țe specifice.
Echipament ul trebuie s ă permit ă crearea manual ă a semn ăturilor de tip IPS/IDS direct pe dispozitiv,
în interfa ța de administrare, f ără a necesita instrument e externe sau sprijin din partea produc ătorului.
Echipament ul trebuie să asigure detecție de tip anti -spyware f ără module suplimenta re, software sau
hardware. Baza de date cu semn ăturile specifice anti -spyware trebuie să fie stocat ă pe dispozitiv si
actualizat ă automat și regulat d e către produc ător, pe baz ă de subscrip ție.
Echipament ul trebuie s ă permit ă configurarea profilelor de identificare anti -spyware în mod specific
pentru fiecare regul ă de securitate în parte. Nu se accept ă ca scanarea anti -spyware s ă se realizeze
doar la nivelul întregului echipament sau doar pentru interfe țe specifice
Echipament ul trebuie s ă permit ă crearea manual ă a semn ăturilor de tip anti -spyware direct pe
dispozitiv, în interfa ța de administrare, f ără a necesita instrument e exter ne sau sprijin din partea
produc ătorului.
Echipament ul trebuie s ă asigure protecție pe baz ă de semn ături DNS pentru a detecta și bloca traficul
către domenii considerate maligne.
Echipament ul trebuie s ă fie capabil s ă substituie adresele IP în r ăspunsurile DNS pentru domenii le
identificate ca fiind r ău inten ționate pentru identificarea cu ușurință a sta țiilor și echipamente lor LAN
infectate cu software r ău inten ționat (func ționalitate DNS sinkhole).
Echipament ul trebuie permit ă desc ărcarea automat ă, prin HTTP și HTTPS, de la sisteme externe, de
liste de adrese IP, liste de numele calificate și de liste URL și să poat ă folosi aceste liste dinamice în
configurarea regulilor de securitate pentru a asigura o protecție automat ă a accesului la resursele
reprezentate de aceste liste.
Echipament ul trebuie s ă asigure monitorizarea automat ă a informa țiilor jurnalizate și să poat ă
identifica adresele surs ă și destina ție IP care particip ă la evenimente specifice definite în conformitate
cu atributele selectate. Pe baza informa țiilor colectate trebuie s ă fie capabil de a crea obiecte tip
adres ă care s ă poat ă fi folosite în configura ția politicilor de securitate a dispozitivului pentru a
asigura o protecție automat ă sau accesul la resursele reprezentate de aceste o biecte.
Echipament ul trebuie s ă permit ă definirea de reguli pentru scanare a traficului web pentru
identificarea schimbului de creden țiale (nume utilizator si parol ă) cu servere web și să poat ă bloca
transmiterea datelor de autentificare c ătre servere care nu prezint ă încredere.
Echipament ul trebuie s ă fie capabil de a capta și transfera la sisteme externe de tip „Sand Box“ diferite
tipuri de fi șiere (exe, dll, pdf, msofffice, Java, jpg, swf) care sunt inspectate cu func ționalitatea anti –
virus și nu sunt cl asificate în mod cert ca fiind maligne sau benigne, pentru a asigura protecție

113
împotriva amenințărilor zero -day. Sistemul extern, în urma finaliz ării analizei fi șierului captat, trebuie
să actualizeze automat baza de date anti -virus a echipament ului firewa ll și să înregistreze un raport
de analiz ă în jurnalele de sistem.
Integrarea echipament ului cu sisteme externe de tip „Sand Box“ trebuie s ă permit ă administratorilor
să configureze la nivelul fiec ărei reguli de securitate tratarea diferen țiată a fișierelor capturate,
configurând pentru fiecare tip de fi șier sistemul extern de analiz ă ce va fi utilizat: în cloud -ul
produc ătorului sau pe echipamente dedicate instalate local și aflate sub controlul exclusiv al
beneficiarului.
Administratorul trebuie s ă aibă posibilitatea de a configura tipul de fi șier (exe, dll, pdf, msoffice, java,
jpg, swf), aplica țiile inspectate și direc ția de tranzit a fi șierului (trimitere, primire, ambele) pentru
analiza în sisteme externe de tip „Sand Box“.
Cerințe networking: NA T, DoS, IPSec VPN, SSL VPN, QoS
Echipament ul trebuie s ă efectueze transla ție de adrese NAT, static și dinamic. Mecanismele NAT
trebuie s ă permit ă cel puțin acces la Internet pentru mu ltiple adrese private utilizând o singur ă adres ă
IP public ă și furnizarea de servicii către Internet de pe servere interne cu adrese private.
Echipament ul trebuie s ă dispun ă de un set separat de politici pentru definirea regulilor NAT separat
de politicile de securitate.
Echipament ul trebuie s ă aibă func ție de protecț ie împotriva atacurilor DoS, cu posibilitatea de a limita
num ărul de sesiuni simultane pe baza adreselor IP sur să sau destina ție.
Echipament ul trebuie s ă permit ă stabilirea de tunele VPN protejate criptografic, bazate pe standarde
IPSec și IKE, în mod cli ent-to-site sau site -to-site. Num ărul de conexiuni VPN nu trebuie limitat prin
modelul de licen țiere, at ât pentru conectarea site -to-site c ât și pentru client -to-site. Echipament ul
trebuie să permit ă conectarea a cel pu țin 30000 clienti VPN și interoperar ea cu cel puțin 4000
coresponden ți IKE. Echipament ul trebuie s ă poat ă procesa cel puțin 16 Gbps trafic IPsec criptat.
Echipament ul trebuie să poat ă inspecta traficul efectuat prin tunele GRE și tunele IPsec AH necriptate,
aplic ând politicile de securitate definite și aplicabile traficului din aceste tunele.
Echipament ul trebuie să permit ă configurarea de politici de securitate unitare pentru utilizatorii
rețelei indiferent dac ă aceștia se conecteaz ă din re țelele interne sau din l ocații fizice externe, prin
VPN. Modulul software client VPN trebuie să fie disponibil pentru Windows, Mac OS X, Linux, Androis,
iOS și să nu implice costuri sau licen țiere per utilizator sau per sta ție fix ă sau mobil ă. Clientul software
VPN trebuie să poată colecta datele de configurare ale sta ției, incluz ând nivelul de actualizare a
sistemului de operare, pachetele software instalate, starea modulelor de protecție de securitate a
stației client, și să transmit ă aceste date c ătre echipament ul firewall care le va putea considera în
evaluarea politicilor de securitate a traficului de date.
Echipament ul trebuie s ă permit ă accesul securizat SSL la aplica ții HTML prin intermediul unui browser
web (clientless SSL VPN)
Echipament ul trebuie s ă permi tă construirea de politici de autentificare ce definesc tipul și num ărul
de mecanisme de autentificare (MFA – multi -factor authentication) pentru permiterea traficului și
accesului la resurse selectate. Modul de definire a politicilor de autentificare treb uie s ă permit ă
utilizarea ca filtre de aplicare a zonelor și adreselor surs ă, utilizatorii țintă, zone și adrese destina ție,
numerele de port și categorii de URL. Mecanismele de autentificare utilizabile trebuie s ă includ ă cel
puțin : RADIUS, TACACS+, LDAP, Kerberos, SAML 2.0.

114
Echipament ul trebuie s ă asigure posibilitatea controlului l ățimii de band ă de rețea (QoS) precum și
stabilirea priorit ății pentru orice aplica ție, prin utilizarea DiffServ, prin definirea l ățimii de band ă
maxim ă și a lățimeii de band ă garantat ă. Sistemul trebuie s ă permit ă crearea de cel puțin 8 clase se
serviciu QoS pentru diferite tipuri de trafic de rețea.
Echipament ul trebuie s ă fie capabil s ă controleze prin QoS l ățimea de banda a traficului pentru fiecare
utilizator.
Echipament ul trebuie s ă fie capabil s ă controleze traficul prin QoS la nivel de sesiune (flow) prin
marcare DSCP. Trebuie s ă fie posibil s ă se aloce acelea și clase QoS pentru traficul de intrare și de ieșire.
Cerințe de Management și raportare
Administrarea și Management ul echipament ului trebuie s ă poat ă fi făcute din linia de comand ă (CLI)
și consol ă grafic ă web GUI accesibil ă prin intermediul unui browser web standard.
Echipament ul trebuie s ă implementeze un model de configura ție candidat care poate fi editat ă în mod
liber pe dispozitiv fără a aplica imediat fiecare modificare în configura ția de lucru efectiv a
dispozitivului, până când modific ările sunt aprobate, verificate și activate de c ătre
administratorul de sistem. Modelul de configura ție candidat treb uie s ă permit ă modificare
configura ției simultan de c ătre administratori multipli, identificând schimb ările efectuate de fiecare
administrator și fiind capabil s ă activeze în configura ția de lucru a echipament ului doar schimb ările
unuia, a l unui subset sau al întregului grup de administratori.
Modelul de configurare trebuie s ă permit ă administratorilor să blocheze al ți administratori în a face
schimb ări într -o arie de configurare sau de a activa modific ările, p ână când fiecare administrator a
terminat imple menta rea tuturor modific ările necesare pentru func ționarea corect ă.
Echipament ul trebuie s ă fie echipat cu interfa ța API XML ca o parte integrant ă a
sistemului de Management instalat pe echipament prin care se poate configura și monitoriza starea
dispoziti vului prin apeluri de la software extern f ără a utiliza consola de administrare
sau de linie de comand ă (CLI).
Accesul la interfe țele de administrare trebuie s ă fie protejate criptografic (printr -o comunicare
criptat ă). Sistemul de Management trebuie s ă permit ă definirea mai multor administratori, fiecare
administrator sau grup putând avea privilegii diferite. Sistemul de management trebuie s ă permit ă
definirea privilegiilor de acces a administratorilor pentru fiecare tip de ac țiune posibil ă în interfe țele
de management (role based access contril – RBAC)
Sistemul de management trebuie s ă permit ă autentificarea administratorilor folosind o baz ă de date
local ă, LDAP, RADIUS, TACACS+ sau Kerberos.
Sistemul de management trebuie s ă permit ă utilizarea unei se cven țe de autentificare pentru
administratori având cel puțin trei metode de autentificare ( de ex. Baz ă de date local ă, LDAP, și
RADIUS).
Echipament ul trebuie s ă dispun ă de un sistem de stocare de date intern de tip hard -disk cu protecție
a datelor prin RAID1 pentru a stoca jurnale și rapoarte, cu o capacitate brut ă de cel pu țin 1TB pentru
fiecare hard -disk.
Sistemul de management trebuie s ă permit ă ștergerea jurnalelor și a rapoartelor stocate pe dispozitiv
după o anumit ă perioad ă de tim p.

115
Toate instrument ele de monitorizare, jurnalizare de trafic sau de analiz ă de securitate, precum și
instrument ele de raportare trebuie s ă fie instalate și disponibile la nivel local pe
echipament . Echipament ul trebuie s ă poat ă fi administrat, monitorizat și trebuie s ă poat ă realiza atât
rapoarte standard cât și rapoarte extinse, definibile de administratori
Sistemul de Management trebuie s ă implementeze uneltele necesare pentru a verifica impactul
actualiz ării semn ăturilor nou desc ărcate, înainte ca acestea să fie activate pe dispozitiv, asupra
politicilor de securitate configurate anterior.
Sistemul de Management trebuie s ă permit ă configurarea retransmisiei jurnalelor de trafic si de
securitate la un server syslog extern, diferit pentru f iecare politica de securitate.
Sistemul de Management trebuie s ă permit ă configurarea retransmisiei jurnalelor de trafic și
securitate in mod selectiv, pe baza datelor continute de intr ările în jurnale.
Sistemul de Management trebuie s ă implementeze unelte pentru crearea mai multor tipuri de
rapoarte adaptate la cerin țele beneficiarului. Rapoartele definite vor putea fi generate manual sau
automat la intervale de timp specificate. Rezultatul rapoartelor trebuie s ă fie disponibil cel pu țin în
formatele PDF, CSV și XML.
Sistemul de Management trebuie s ă permit ă crearea de rapoarte privind activitatea unor utilizatori
selecta ți sau la nivel de grup de utilizatori extrasi din servere LDAP.
Redundan ță (High Availability)
Echipament ul trebuie s ă fie capabil s ă lucreze în configura ție redundant ă (High Availability) în mod
activ -pasiv sau activ -activ.

3.4.2.3 Securitatea serverelor

Solutia de protectie impotriva amenințărilor de securitate de pe servere trebuie sa dispuna de
urmatoarele tehnologii specifice, proprii a le producatorului solutiei, care sa ruleze in cadrul unui
singur agent functional:
– un motor antivirus de scanare pe baza sabloanelor si semnaturilor, dar si euristic, folosind
componentele antimalware si antispyware instalate local, fara a folosi semnaturi , motoare si
agenti stocati in cloud
– un mecanism protectie impotriva atacurilor cu rootkit la nivel de boot
– un mecanism de curatare a virusilor de retea si a resturi de worms (troieni, inregistrari de
registri si fisiere virale) si a altor resturi de fisiere similare
– un motor de scanare la nivel de memorie, in vederea detectarii amenințărilor malware fara
fisier, care ruleaza doar in memorie
– mecanisme de machine -learning, care sa actioneze atat in perioada de dinaintea executiei, cat
si in moment ul rul arii. Mecanismele de machine -learning trebuie sa dispuna de functionalitati
proprii de reducere a rezultatelor false -positive in procesul de detectie
– un motor de scanare reputationala a resurselor web accesate, inclusiv a resurselor HTTPS.
Motorul trebuie sa ajute la prevenirea atacurilor cu exploituri din browser si cu scripturi rau –
intentionate.

116
– un motor de analiza comportamentala , care sa identifice comportamentele rau-intentionate,
protectie impotriva scripturilor si rootkiturilor, protectie impotriva a tacurilor cu cod injectat,
protectie impotriva rularii exploiturilor in browser, sa protejeze fisiere, chei de registri si
servicii, inclusiv sa detecteze comportamentele anormale ale aplicatiilor care ar putea
determina o amenințare sau un atac.
– un motor de firewall care sa lucreze impreuna cu motorul de scanare antivirus in vederea
protejarii sistemelor de atacurile cu virusi de retea. Motorul firewall trebuie sa permita
configurarea politicilor pe niveluri de risc si cu exceptii
– un motor de detectie a in truziunilor, care sa identifice modelele din pachetele de retea, care
ar putea indica un atac la nivel de sistem, aplicatii sau procese.
Solu ția trebuie s ă fie compatibil ă cu sisteme de operare Windows Server (2008, 2012, 2016) și Linux
(CentOS 6/7 Debian 8/9, Oracle 6/7, Red Hat Enterprise Linux 6/7, SUSE Linux Enterprise Server 12) .
Sistemul livrat trebuie s ă fie licen țiat pentru protec ția a minim 300 de servere fizice sau virtuale.
Solutia de protectie a serverelor trebuie sa aiba un sistem de clasificar e pentru nivelurile de risc a
amenințărilor identificate pentru fiecare componenta de securitate in parte, tinand cont de criteriile
de clasificare ale producatorului, dar care sa poata fi configurate si in mod individual.
Solutia de protectie a serverelor trebuie sa aiba un sistem de clasificare a valorii de business a
sistemelor gestionate, care sa poata fi corobrat cu nivelurile de risc ale amenințărilor pentru a permite
o evaluare de risc corespunzatoare a amenințărilor identificate de componentele solu tiei.
Solutia trebuie sa aiba o consola web si centralizata de gestiune si administrare a sistemelor si
politicilor, usor de utilizat, care sa dispuna cel putin de urmatoarele functionalitati:
– construirea de tablouri de bord de securitate pentru prioritiza rea actiunilor operationale cu
privire la amenințări , utilizatori, dispozitive, etc
– un sistem de raportare centralizata
– un mecanism, integrat in interfata web, de parcurgere a evenimente lor de securitate pana la
informatia specifica urmarita.
– activarea si reactivarea de componente functionale, distributia de actualizari si hotfix -uri
pentru agenti, dar si de semnaturi de securitate
– utilizarea unei comunitati interne de distributie a informatiilor legate de amenințări le
descoperite, care sa fie partajate cu toate celelalte dispozitive din cadrul solutiei.
Solu ția trebuie s ă aibă module de protecție pentru malware, pentru exploit -uri de vulnerabilit ăți și
anti-ransomware, și trebuie s ă poat ă să diferen țieze ac țiunile și raportarea evenimente lor pentru
malware, exploit, ransomware.
Solu ția trebuie s ă asigure prevenirea atacurilor malware cunoscute, atât pe baza de semn ături tip anti –
virus cât și prin metode euristice, precum și detectarea și blocarea atacurilor necunoscute, prin analiz ă
local ă și sandbox .
Regulile si profilurile de securitate trebuie sa se poata configura fara a necesita repornirea sistemului
sau a componentelor protejate.

117
Agentii solutiei de protectie trebuie sa dispuna de metode de protectie impotriva opririi sau modificarii
proceselor critice ale acestora, precum si impotriva dezinstalarii neautorizate a agentilor.
Solu ția trebuie s ă asigure protec ția împotriva exploit -urilor de vulnerabilit ăți fără să foloseasc ă
semn ături specifice fiec ărei variante de exploit cunoscut și trebuie s ă asigure blocarea exploit -urilor
cunoscute cât și a celor necunoscute, prin identificarea și blocarea tehnicilor de exploatare a
vulnerabilit ăților.
Solu ția trebuie s ă combine mai multe module de prevenire a atacurilor de tip exploit , inclusiv protecție
împotriva coruperii memoriei, protecție logic flow și protecție pent ru execu ția codului în mod
răuvoitor.
Solu ția trebuie s ă asigure protecție persistent ă atât online cât și offline (să func ționeze și să asigure
protecție și în perioadele în care agentul nu este conectat la Internet sau la rețeaua local ă).
Solu ția trebuie s ă permit ă definirea de liste de fișiere, identificate prin semn ătură criptografic ă (hash),
atât pentru permitere implicit ă a execu ției (white list) cât și pentru blocare implicit ă a execu ției (black
list). Politicile de permitere sau excludere de la execu ție trebuie s ă poat ă fi definite la nivel de fi șier
(hash) și să fie aplicate unuia sau mai multor clien ți, inclusiv prin selec ția acestora din g rupuri .
Comunica ția între agen ți și servere de Management trebuie s ă fie protejat ă prin criptare SSL; solu ția
trebuie s ă permit ă folosirea de certificate digitale generate extern pentru protec ția canalelor de
comunicare
Sistemul trebuie s ă permit ă realocarea licen țelor pentru agen ți direct din interfa ța de Management ,
fără a limita sau diferen ția licen țele între tipuri diferite de agen ți (sistem de operare, arhitectura
server, etc)
Sistemul trebuie s ă permit ă tratarea facil ă a incidentelor de tip ”false positives” prin posibilitatea
creării automate a politicilor de schimbare a verdictului, la nivel de hash al fi șierului țintă, modulelor
de protecție implicate în stabilirea verdictului, politici ce pot fi aplicate ulterior pentru servere
individuale sau grupuri de servere.
Solutia de securita te pentru servere trebuie sa se poata adapta in timp real la versiunile noi de kernel
ale sistemului de operare sau prin actualizarea agentului corespunzator. Acest proces trebuie sa se
poata configura si in mod automat.
Componenta de securitate ofertata t rebuie sa permita integrarea cu sistemul de analizare a malware –
ului necunoscut ofertat pentru cap.3.4.2.4.

3.4.2.4 Analiz ă malware necunoscut

Având în vedere importan ța sistemului și gradul s ău de penetrare, solu ția de securitate trebuie
completat ă cu o compone ntă specializat ă în detec ția fișierelor care con țin malware tip sandbox, mai
ales pentru a evita pe cât posibil infectarea cu malware prin documente în format electronic puse la
dispozi ție de cadrele didactice pentru uzul elevilor.
Astfel, se va implementa o solu ție redundant ă (câte un set de echipamente / servere în fiecare centru
de date) care s ă inspecteze în limita capacit ății solicitate documente le publicate de c ătre profesori. În
măsura în care exist ă resurse disponibile, se vor putea inspecta și alte documente publicate prin
sistem.

118
Sistemul de tip sandbox trebuie sa fie compus din componente care sa ofere capacitatea de analiza
pentru artefacte primite atat de la solutia de protectie a serverelor cat si pentru cele primite de la
sistemul de tip next generation firewall. Acest lucru va permite blocarea unor atacuri de tip zero day
atat la nivel de server cat si la nivel de retea.
Fișierele vor fi trimise c ătre sandbox direct de modulul de partajare fi șiere. Analiza se poate face
sincron (publicare doar după ce document ul a fost validat) sau asincron (publicare imediat ă, urmat de
retragere în caz de invalidare). Echipamente le de analiz ă malware trebuie s ă asigure scanarea unui
num ăr de minim 7000 de fi șiere pe zi per centru de date.
În condi ții normale d e lucru, Nucleul operativ va utiliza serviciul din centrul de date propriu, cu
posibilitatea de a comuta pe utilizarea serviciul ui de sandbox din celălalt centru de date în cazul unei
defec țiuni a echipament ului.
Soluția de analiz ă malware trebuie s ă poat ă analiza fi șiere de tip EXE, DLL, SCR, MS Office, PDF, Flash,
Java JAR și CLASS, fi șiere comprimate ZIP și link -uri URL încorporate în mesaje email.
Soluția se va conecta în fiecare switch campus din centrul s ău de date prin câte minim 2 leg ături de
rețea 1000 Mbps
Soluția trebuie s ă permit ă conectarea ma șinilor virtuale de analiza la o re țea de comunica ții izolat ă
pentru a identifica și analiza comportamentul în re țea al fi șierelor analizate.
Având în vedere caracterul lor diferit, serviciul trebuie s ă poată fi configurat astfel încât s ă prioritizeze
analiza fișierelor executabile sau a fișierelor document .
Serviciul trebuie s ă asigure generarea de semn ături anti -virus, DNS și clasificare URL pentru software –
ul analizat și identificat ca fiind malware.
Serviciul trebuie s ă poat ă actualiza periodic, în mod automat și/sau manual, bazele de date de
semn ături, algoritmii de analiz ă și imaginile de referin ță pentru ma șinile virtuale de analiz ă, prin acces
securizat criptat la un sistem de update al produc ătorului.
Serviciul trebuie s ă pună la dispozi ție un API securizat pentru trimiterea automat ă la analiz ă a fișierelor
din aplica ții software customizate și pentru preluarea verdictelor și rapoartelor de analiz ă, pe baza
căruia se va face integrarea cu SIMS .

3.4.2.5 Sistemul centralizat de Management și raportare de securitate

Sistemul de Management trebuie s ă fie implementa t ca un sistem de mașini virtual e.
Sistemul trebuie s ă permit ă integrarea unitar ă a tuturor echipamente lor NGFW, integrarea acestora
cu echipament ul dedicat pentru analiz ă malware necunoscut (sandbox) și preluarea jurnalelor și
alertelor de la software -ul de protecție a securit ății serverelor.
Sistemul de management trebuie s ă fie licen țiat pentru toate componentele hardware și software ce
vor fi integrate, la nivelul maxim de func ționalitate (f ără a limita prin licen țiere num ărul de utilizatori,
num ărul de porturi, capacitatea de stocare utilizat ă, num ărul de rapoarte, cantitatea de date
analizate, num ărul de administratori, etc).
Sistemul de Management trebuie s ă ofere interfe țe de administrare în mod CLI, în mod grafic peste
protocoale web și ca API XML pentru integrare sisteme externe

119
Accesul la interfe țele de administrare trebuie s ă fie protejate criptografic (printr -o comunicare
criptat ă). Sistemul de Management trebuie s ă permit ă definirea mai multor administratori, fiecare
administrator sau grup putând avea privilegii diferite. Sistemul de Management trebuie s ă permit ă
definirea privilegiilor de acces a administratorilor pentru fiecare tip de ac țiune posibil ă în interfe țele
de Management (role based access control – RBAC)
Sistemul de Management trebuie s ă permit ă gestionarea, accesarea și utilizarea unei capacit ăți de
stocare de m inimum 24TB pentru fiecare instan ță a sistemului, în scopul stoc ării jurnalelor de trafic, a
jurnalelor de securitate, a jurnalelor opera țiunilor administrative și a alertelor
Sistemul de Management trebuie s ă asigure administrarea configura țiilor opera ționale a
echipamente lor pe baza unor șabloane (template -uri) de configura ție precum și posibilitatea de a
defini și utiliza șabloane modulare (compuse din mai multe șabloane)
Configurarea șabloanelor de configura ție trebuie s ă permit ă utilizarea de variabile de configurare, care
să permit ă utilizarea unui șablon pentru echipamente multiple și să asigure diferen țierea
configura țiilor individuale prin intermediul variabilelor. Astfel de variabile trebuie să referen țieze
adrese IP, grupuri de adrese IP, nume de host (FQDN), identificatori de interfe țe de comunica ție,
identificatori de grupuri de cluster High Availability.
Sistemul de management trebuie s ă permit ă gruparea echipamente lor firewall utilizate în grupuri și
sub-grupuri.
Configura țiile opera ționale ba zate pe șabloane trebuie s ă poat ă fi aplicate unui grup, sub -grup sau
unui echipament individual
Configurarea politicilor de securitate trebuie s ă poat ă fi făcută la nivelul fiec ărui grup, sub -grup, cluster
de HA sau echipament individual
Sistemul de manag ement trebuie să asigure monitorizarea utiliz ării resurselor și a st ării de func ționare
pentru echipamente le firewall administrate
Sistemul de management trebuie s ă permit ă configurarea retransmisiei jurnalelor de trafic și de
securitate la un server syslo g extern, diferit pentru fiecare politic ă de securitate.
Sistemul de management trebuie s ă permit ă configurarea retransmisiei jurnalelor de trafic și
securitate în mod selectiv, pe baza datelor con ținute de intr ările în jurnale.
Sistemul de management trebuie s ă implementeze unelte pentru crearea mai multor tipuri de
rapoarte adaptate la cerin țele beneficiarului. Rapoartele definite vor putea fi generate manual sau
automat la intervale de timp specificate. Rezultatul rapoartelor trebuie s ă fie disponib il cel pu țin în
formatele PDF, CSV și XML.
Sistemul de management centralizat trebuie s ă permit ă generarea de rapoarte din bazele de date
locale de jurnale, agregat pentru grupuri sau pentru toate echipamente le și sistemele administrate.
Accesul la interfe țele de administrare trebuie s ă fie protejate criptografic (printr -o comunicare
criptat ă). Sistemul de management trebuie s ă permit ă definirea mai multor administratori, fiecare
administrator sau grup putând avea privilegii diferite. Sistemul de managemen t trebuie s ă permit ă
definirea privilegiilor de acces a administratorilor pentru fiecare tip de ac țiune posibil ă în interfe țele
de management (role based access control – RBAC)
Sistemul de management trebuie s ă permit ă autentificarea administratorilor folo sind o baz ă de date
local ă, LDAP, RADIUS, TACACS+ sau SAML.

120
Sistemul de management trebuie s ă implementeze un model de configura ție candidat care poate fi
editat ă în mod liber pe dispozitiv fără a aplica imediat fiecare modificare în configura ția de lucru
efectiv a dispozitivului, până când modific ările sunt aprobate, verificate și activate de c ătre
administratorul de sistem. Modelul de configura ție candidat trebuie s ă permit ă modificare
configura ției simultan de c ătre administratori multipli, identificând schimb ările efectuate de fiecare
administrator și fiind capabil s ă activeze în configura ția de lucru a echipament ului doar schimb ările
unuia, a unui subset sau al întregului grup de administratori.
Modelul de configurare trebuie s ă permit ă administratorilo r să blocheze al ți administratori în a face
schimb ări într -o arie de configurare sau de a activa modific ările, pân ă când fiecare administrator a
terminat implementa rea tuturor modific ările necesare pentru func ționarea corect ă.
Sistemul de Management trebui e să asigure jurnalizarea configura țiilor în timp și să permit ă în mod
facil revenirea la o configura ție anterioar ă, pentru toate sau pentru grupuri arbitrare de echipamente
administrate
Sistemul de management trebuie să asigure validarea configura țiilor înainte ca acestea s ă fie
transmise și activate pe echipamente le administrate.
Sistemul de management centralizat trebuie s ă asigure integritatea comunica ției cu echipamente le
administrate prin metode criptografice SSL. Sistemul trebuie s ă poat ă utiliza pe ntru criptarea
comunica ției cu echipamente le administrate certificate digitale generate extern de c ătre beneficiar
Sistemul de management centralizat trebuie s ă permit ă salvarea automat ă periodic ă a configura ției,
incluzând configura țiile echipamente lor fi rewall administrate
Sistemul de management centralizat trebuie s ă ofere în interfa ța grafic ă posibilitatea c ăutării unui
obiect in configura ția globala și să indice în ce zone de configura ție este utilizat.
Sistemul trebuie să prezinte datele din jurnalele diverse atât în mod individual, pentru fiecare tip de
jurnal, cât și în mod unificat, realizând automat și în mod dinamic agregarea și sortarea temporal ă a
intrărilor din jurnale diferite
Sistemul de management trebuie s ă ofere administratorilor capabilitatea de a face filtr ări ad -hoc a
jurnalelor pe baza obiectelor și caracteristicilor jurnalizate, și să ofere meniu ri contextuale pentru
analize de tip ”drill -down”
La implementa re se va realiza o configurare ini țială confo rmă cu cele mai bune practici în domeniu .
După un interval între 6 luni și un an de la implementa rea ini țială, pentru a evalua modific ările aduse
între timp, se va realiza o analiz ă de conformitate cu cele mai bune practici în domeniu (Best Practices
Asess men t) pe aceste componente.

3.4.2.6 Router WAN

Aceste echipamente , câte dou ă per loca ție, vor agrega, ruta și oferi redundan ța din punct de vedere
IP pentru liniile de Internet prezentate în mod redundant de c ătre echipamente le Switch Agregare
WAN.
Acest echipament trebuie să asigure func ționalit ăți de rutare cu ajutorul protocoalelor BGP și OSPF ,
având fiecare o putere de procesare de minimum 100 Gbit/sec, cu o capabilitate maxim ă de minim 25
Gbit/sec trafic criptat

121
El va avea urm ătoarele caracteristici minimale individuale :
 minimum 16 GB RAM instalat ă în sistem
 redundan ță (în) software
 minimum 4 porturi de 1 G bps Ethernet
 minimum 4 porturi de 10 G bps Ethernet
 1 slot Ethernet Port Adapter
 un modul tip Network Interface
 1 GB memorie flash
 două surse redunda nte de alimentare
 temperatura de operare trebuie să fie între 5 și 40 de grade Celsius , cu flux aer din fa ță în
spate
 umiditatea de operare trebuie să fie intre 10% și 85% cu posibilitatea de a cre ște la 90% pe
termen scurt
Echipamente le trebuie să suporte QoS și ACL în hardware fără a avea un impact negativ asupra
traficului inspectat .
Echipament ul trebuie să dispun ă de o separare a data plane de control plane
Echipament ul trebuie să exporte statistici de trafic prin unul din protocoalele J -Flow/sF low/Netflow
sau echivalent .
Echipament ul trebuie să fie gata să suporte tehnologia Software Defined – Wide Area Network (SD –
WAN) dac ă acest lucru se va impune în viitor.
Echipament ul trebuie să suporte firewall de mare vitez ă bazat pe zone de securitate.
Va exista s uport pentru garantarea aplica țiilor cu prioritate înalt ă versus aplica țiile cu prioritate
scăzută pentru a îmbun ătăți experien ța utilizatorilor.

3.4.2.7 Switch Agregare WAN

Fiecare echipament (câte dou ă per loca ție) va avea minimal:
 16 porturi SFP+ 10Gbps Etherenet
 licen ță software cu func ționalit ăți de baza (layer 2 -3 OSI)
 suport pentru IGMP 1, 2 și 3, MLD
 suport pentru rutare bazat ă pe politici (PBR) și protocoale de rutare precum OSPF
 Suport pentru QOS avansat de tip Shaped Round Robin(SRR) și Weighted Tail Drop(WTD).
 Suport pentru rutare IPv6 și protocoale IPv6 precum OSPFv3.
 Suport pentru protocoale de rutare multicast precum PIM -SM, PIM -DM și SSM.
 Suport pentru protocoale de nivel 2 OSI precum PVRST+ , MSTP.2 sau echivalent
 Echipament ul trebuie să suporte monitorizare prin protocolul RSPAN

122
3.4.2.8 Controlul aplica țiilor

În fiecare site se vor prevedea solu ții hardware specializate redundante , în configura ții locale de înalt ă
disponibilitate, pentru următoarele roluri :
 Protec ția serviciilor aplicative – WAF , anti-DDoS, securizarea aplica țiilor și a accesului la
acestea
 Redistributie servicii DNS – balansare global ă, DNS, rutare avansat ă
 Redistribu ția sarcinii – balansare local ă
Se vor prevedea platforme fizic distincte pentru fiecare rol în parte. Fiecare echipament în parte va fi
dimensionat pentru a putea face fa ță în mod sus ținut la tot traficul generat de aplica ții posibil teoretic
în condi țiile leg ăturii internet de 20Gb per site, considerând toate serviciile activate dup ă specificul
echipament ului.
Toate echipamente le aferente acestui nivel vor îndeplini fiecare în parte urm ătoarele cerin țe
minimale:
 Suport ă implementa rea în oricare din următoarele scenarii: Active -Standby, Active -Active și
configuratii N+1;
 Permite sincronizarea configura țiilor, starea conexiunilor și persisten ța pentru asigurarea
disponibilit ății aplica țiilor în caz de failover;
 Permite configurarea și sus ținerea, prin func ționalit ăți interne native de tip hipervizor, a multiple
parti ții de sistem și sisteme virtuale independente, active concurent;
 Fiecare alocare de resurse sistem, ca parti ție sau ca sistem virtual, va putea fi definit ă și peste
resurse hardware alocate din dou ă sau mai multe module și/sau echipamente distincte, în acelasi
cluster;
 Suport ă mirroring pentru conexiunile non -SSL în configura ție Active -Standby;
 Permite backup și restore pentru fi șierul de configurare din interfa ța grafic ă;
 Permite failover între modulele sau echipamente le core spondente configurate, în functie de:
defec țiuni hardware, defec țiuni de sistem, nefunc ționarea acceleratorilor SSL, nefunc ționarea
rețelei, nefunctionarea gateway -ului;
 Suport ă implementa rea într-un mediu / topologie cu o singur ă sub-rețea (subnet);
 Supor tă implementa rea în mod bridge;
 Permite primirea de mesaje SOAP/XML de la instrument e externe pentru modificarea
configura ției controller -elor de aplica ții;
 Permite Management -ul prin interfa ța serial ă, CLI (cu SSH) și https GUI;
 Permite colectarea de informa ții statistice și istorice despre utilizarea memoriei, procesorului,
conexiuni și trafic și afișarea acestora în grafice disponibile în interfa ța grafic ă. Unit ățile de timp
minim disponibile vor fi: per ora, zi, s ăptămână sau lun ă;
 Permite generarea și afișarea unei h ărți a re țelei pentru adresele IP și pool -urile noduri de
procesarelor virtuale;
 Permite agregarea link -urilor (802.3ad) și LACP (Link Aggregation Control Protocol);
 Suport ă generarea unei tabele de rutare ierarhizat ă compu să din diferit e segmente (tip "parent"
"child") pentru spa țiile de IP -uri izolate sau suprapuse;
 Permite alocarea dinamic ă și controlabil ă a resurselor tip CPU și memorie RAM (ex. dedicat,
func ționare nominal ă, func ționare minim ă);
 Dispune de template -uri de configurare generice customizabile în func ție de nevoile specifice;
 Trimite alerte despre diverse erori prin SNMP, syslog, e -mail;
 Permite definirea de multiple domenii de administrare;
 Permite resetarea la configura țiile ini țiale ("din fabric ă");

123
 Dispune de minim 2 porturi capabile 10 Gbps, toate echipate cu conectori de tip SFP+;
 Alimentare redundant ă prin cel puțin două surse independente de alimentare . Sursele vor oferi
func ționalitate hot -swap pentru înlocuirea rapid ă, fără oprirea alimentării sistemului și fără
întreruperea serviciilor asigurate de platform ă;
 Toate elementele de asigurare a ventila ției sistemului vor fi de tip hot -swap pentru înlocuirea lor
rapid ă în caz de avarie, f ără întreruperea func ționalit ăților preconi zate de platform ă;
 Montabil ă în rack -uri standard de 19”;

3.4.2.8.1 Platforma de protecție a serviciilor de aplica ție

Platforma de protecție a serviciilor de aplica ție are rolul de a aronda inițial, respectiv a redistribui și
proteja conexiunile fizice și logice realizate de utilizatori către aplica țiile și serviciile din platformele de
procesare, astfel încât indiferent de nivelul de performan ță și disponibilitate necesar aplica țiilor ce
proceseaz ă seturile de date, conexiunile să fie securizate și distr ibuite egal între nodurile de procesare.
Cele 4 noduri de protecție , echipamente de tip ADC/WAF, vor î ndeplini fiecare următoarele cerin țe
func ționale specifice minimale :
Rol
 Platforma de protecție a serviciilor de aplica ție pentru accelerarea, balansarea/rebalansarea și
securizarea traficului între utilizatori și aplica țiile/serviciile din platformele de procesare;
Optimizare si balansare/rebalansare
 Platforma de redistribu ție a sarcinii va putea func ționa în mod full prox y, respectiv în mod reverse
proxy;
 Va procesa trafic TCP și UDP generat de diferite aplica ții;
 Multipli algoritmi sau metode de balansare a traficului: round -robin, ratio și priority (cu un num ăr
minim de membri activi);
 Multipli algoritmi sau metode dinam ice de balansare a traficului: fastest -response, least –
connections, combina ția fastest -response least -connections, precum și bazate pe resursele noduri
de procesarelor de aplica ții (ex: utilizare CPU, încărcarea memorie i, gradul de încărcare al re țelei
etc);
 Va trimite cereri gradual c ătre noduri de procesarele de aplica ții nou ad ăugate;
 Va redirecta traficul pentru diferite tipuri de (ex: http to https);
 Va procesa cereri bazat e pe IP sur să/destina ție, SSL, hash persistence;
 Va utiliza diferite metode p entru “cookie persistence”: pasiv, insert, rewrite;
 Va utiliza metode de persisten ță a sesiunilor în func ție de orice variabil ă din header -ul pachetelor
TCP/UDP sau din payload;
 NAT (network address translation) și NAPT (network address port translation) bazat pe IP sur să
și/sau IP destina ție;
 Va returna pachete bazat pe adresa MAC a ultimului hop (asigurarea rout ării asimetrice);
 Va decide directionarea traficului în func ție de URI, method, HTTP host,version, cookie, tipul
browser -ului folosit de client, etc;
 Va genera reguli noi pentru Management ul traficului în func ție de anumite evenimente , folosind
un limbaj de scripting;
 Va controla fluxul de trafic bazat pe con ținutul acestuia, în mod bi -direc țional;
 Va folosi o combina ție mixt ă de adrese virtuale și noduri IPv4 și IPv6;
 Va translata trafic IPv6 -IPv4 și IPv4 -IPv6;
 Va folosi protocoale de routare IPv6: BGP4+, RIPng și OSPFv3;
 Va insera XFF în header -e HTTP, cu IP -ul de origine al clientului;
 Redirectare URL c ătre mai multe noduri de procesare virtuale în func ție de HTTP response code
sau URL pattern;

124
 Va returna o pagine de eroare în cazul în care resursele/noduri de procesarele de aplica ții nu sunt
disponibile. Pagina de eroare și mesajul v or putea fi customizate și să poat ă conține grafic ă;
 Va folosi “chunked transfer encoding” pentru Menține rea persisten ței sesiunilor;
 Va agrega și refolosi multiple sesiuni client într-o singur ă sesiune server -side;
 Va transforma sesiuni HTTP 1.0 în sesiuni HTTP 1.1 pentru consolidare sesiunilor server -side;
 Va oferi metode de compresie HTTP pentru reducerea traficului;
 Va oferi metode pentru accelerare și caching HTTP;
 Va oferi metode pentru optimizare simetric ă de date, compresie, criptare și tunneling;
 Va oferi metode de criptare AES SSL;
 Va oferi metode d e caching multi -store pentru con ținut dinamic și static (RFC2616);
 Va oferi metode pentru optimizarea traficului LAN/WAN conform: RFC2582 (optimizare Reno
asimetric ă), RFC1323 (extensii TCP pentru re țele de mare vitez ă), RFC3042, RFC2018, RFC3168;
Procesar e SSL/TLS
 Platforma va suporta terminarea de trafic SSL/TLS;
 Platforma va dispune de acceleratori SSL pentru SSL offloading;
 Platforma va comunica prin SSL/TLS cu un server de aplica ții backend;
 Platforma va suporta ajustarea parametrilor SSL precum metoda de criptare utilizat ă, versiunea;
 Platforma va suporta SSLv3 și TLSv1;
 Platforma va suporta certificate wildcard;
Protecție a serviciilor de aplicatie Web
 Capabilitate de inspec ție a cererilor/r ăspunsurilor HTTP;
 Capabilitate de a bloca atacuri tip DoS prin connection proxy;
 Capabilitate de filtrare a pachetelor OSI L3 -L7;
 Capabilitate de a detecta și bloca anomaliile de protocol TCP/UDP, pentru protecție DoS;
 Capabilitate de protecție împotriva atacurilor bazate pe malformarea pachetelor de tip SYN, ACK ,
ICMP, UDP, TCP, DNS sau ARP;
 Capabilitate de protecție împotriva atacurilor volumetrice de tip DDoS: flood, sweep, teardrop,
smurf attacks pentru aplica ții de genul HTTP, DNS sau SIP;
 Solu ția trebuie să poat ă defini politici diferite de securitate pentru diverse aplica ții;
 Solutia va suporta următoarele metode / tehnici de detecție :
 Decodare URL;
 Null byte string termination;
 Combinații de litere mari și mici;
 Eliminarea comentarii lor (ex. transformarea DELETE/**/FROM în DELETE FROM);
 Suport pentru modelu l de securitate pozitiv ă – "permite tot traficul cunoscut" și
blocheaz ă tot traficul necunoscut;
 Motor integrat de detecție pentru tentativele de evitare a inspec ției;
 Detecție bazat ă pe semn ături;
 Solu ția trebuie să permit ă dezvoltarea politicii de securi tate f ără script -uri adi ționale;
 Solu ția trebuie să permit ă generarea automat ă a politicii de securitate;
 Solu ția trebuie să recunoasc ă host -urile/entitatile (IP -urile) de încredere (trusted). Cererile
acestora trebuiesc tratate corespunz ător;
 Solu ția trebuie să suporte detec ția parametrilor ascun și/dinamici;
 Va fi posibil ă construc ția politicii de securitate pe baz ă de instrument e third party de evaluare a
vulnerabilit ăților – spre exemplu prin import);
 Management ul configura ției:
 Platforma de prote cție a serviciilor de aplica ție va permite definirea de roluri pentru
utilizatori și va solicita autentificare;
 Platforma de protecție a serviciilor de aplica ție va permite actualizarea manual ă sau automat ă a
semn ăturilor ( Menținute și publicate de furnizo ri);

125
Dimensionare
 Rata de transfer a echipament ului de cel puțin 20 Gbps, pentru serviciu Layer 4, respectiv de cel
puțin 20 Gbps, pentru serviciu Layer 7;
 Rata de procesare a sarcinii specifice de cel puțin 1 milion de cereri pe secundă , la nivel de serviciu
Layer 7, respectiv de cel puțin 2 milioane de cereri Layer 4 HTTP pe secundă ;
 Capacitate de deschidere si procesare a cel puțin 400000 conexiuni Layer 4 pe secundă , precum si
a cel puțin 20000 tranzactii SSL (cu chei de 2048 biti) pe secundă ;
 Compresie hardware suportata de cel puțin 10 Gbps, precum si procesare criptografica de cel
puțin 15 Gbps;

3.4.2.8.2 Platforma de redistributie local ă a sarcin ii

Platforma de redistributie local ă a sarcinii are rolul de a aronda initial, respectiv a redistribui
conexiunile fizice si logice realizate de utilizatori catre aplicatiile si serviciile din platformele de
procesare, astfel incat indiferent de nivelul de performanta si disponibilitate neces ar aplicatiilor ce
proceseaza seturile de date, conexiunile să fie distribuite egal intre nodurile de procesare.
Cele 4 noduri de redistributie , echipamente de tip ADC/LB, vor îndeplini fiecare urm ătoarele cerin țe
func ționale specifice minimale:
Rol
 Platforma de redistributie de sarcina pentru accelerarea si balansarea/rebalansarea traficului intre
utilizatori si aplicatiile/serviciile din platformele de procesare;
Optimizare si balansare/rebalansare
 Platforma de redistributie a sarcinii va putea func tiona in mod full proxy, respectiv in mod reverse
proxy;
 Va procesa trafic TCP si UDP generat de diferite aplicatii;
 Multipli algoritmi sau metode de balansare a traficului: round -robin, ratio si priority (cu un numar
minim de membri activi);
 Multipli algo ritmi sau metode dinamice de balansare a traficului: fastest -response, least –
connections, combinatia fastest -response least -connections, precum si bazate pe resursele noduri
de procesarelor de aplicatii (ex: utilizare CPU, incarcarea memorie, gradul de inc arcare al retelei
etc);
 Va trimite cereri gradual catre noduri de procesarele de aplicatii nou adaugate;
 Va redirecta traficul pentru diferite tipuri de (ex: http to https);
 Va procesa cereri bazat pe IP sur să/destinatie, SSL, hash persistence;
 Va utiliza diferite metode pentru “cookie persistence”: pasiv, insert, rewrite;
 Va utiliza metode de persistenta a sesiunilor in functie de orice variabila din header -ul pachetelor
TCP/UDP sau din payload;
 NAT (network address translation) si NAPT (network address po rt translation) bazat pe IP sur să
și/sau IP destinatie;
 Va returna pachete bazata pe adresa MAC a ultimului hop (asigurarea routarii asimetrice);
 Va decide directionarea traficului in functie de URI, method, HTTP host,version, cookie, tipul
browser -ului f olosit de client, etc;
 Va genera reguli noi pentru Management ul traficului in functie de anumite evenimente , folosind
un limbaj de scripting;
 Va controla fluxul de trafic bazat pe continutul acestuia, in mod bi -directional;
 Va folosi o combinatie mixta de adrese virtuale si noduri IPv4 si IPv6;
 Va translata trafic IPv6 -IPv4 si IPv4 -IPv6;
 Va folosi protocoale de routare IPv6: BGP4+, RIPng si OSPFv3;

126
 Va insera XFF in header -e HTTP, cu IP -ul de origine al clientului;
 Redirectare URL catre mai multe noduri de p rocesare virtuale in functie de HTTP response code
sau URL pattern;
 Va returna o pagine de eroare in cazul in care resursele/noduri de procesarele de aplicatii nu sunt
disponibile. Pagina de eroare si mesajul va putea fi customizate si să poata contine gr afica;
 Va folosi “chunked transfer encoding” pentru menținerea persistentei sesiunilor;
 Va agrega si refolosi multiple sesiuni client intr -o singura sesiune server -side;
 Va transforma sesiuni HTTP 1.0 in sesiuni HTTP 1.1 pentru consolidare sesiunilor serve r-side;
 Va oferi metode de compresie HTTP pentru reducerea traficului;
 Va oferi metode pentru accelerare si caching HTTP;
 Va oferi metode pentru optimizare simetrica de date, compresie, criptare si tunneling;
 Va oferi metode de criptare AES SSL;
 Va oferi m etode de caching multi -store pentru continut dinamic si static (RFC2616);
 Va oferi metode pentru optimizarea traficului LAN/WAN conform: RFC2582 (optimizare Reno
asimetrica), RFC1323 (extensii TCP pentru retele de mare viteza), RFC3042, RFC2018, RFC3168;
Procesare SSL/TLS
 Platforma va suporta terminarea de trafic SSL/TLS;
 Platforma va dispune de acceleratori SSL pentru SSL offloading;
 Platforma va comunica prin SSL/TLS cu un server de aplicatii backend;
 Platforma va suporta ajustarea parametrilor SSL precum metoda de criptare utilizata, versiunea;
 Platforma va suporta SSLv3 si TLSv1;
 Platforma va suporta certificate wildcard;
Disponibilitate
 Solutia va permite configurarea si sustinerea, prin functionalitati interne native de tip hipervizor,
a multiple partitii de sistem si sisteme virtuale independente, active concurent;
 Fiecare alocare de resurse sistem, ca partitie sau ca sistem virtual, va putea fi definita si peste
resurse hardware alocate din doua sau mai multe module si/sau echipamente distincte, in acelasi
cluster;
 Solutia va suporta mirroring pentru conexiunile non -SSL in configuratie Active -Standby;
 Solutia va permite backup si restore pentru fisierul de configurare din interfata grafica;
 Solutia va permite failover intre modulele sau echipamen tele corespondente configurate, in
functie de: defectiuni hardware, defectiuni de sistem, nefunctionarea acceleratorilor SSL,
nefunctionarea retelei, nefunctionarea gateway -ului;
 Solutia va suporta implementa rea intr -un mediu / topologie cu o singura sub -retea (subnet);
Management
 Platforma va permite primirea de mesaje SOAP/XML de la instrument e externe pentru
modificarea configuratiei controller -elor de aplicatii;
 Solutia va permite management -ul prin interfata seriala, CLI (cu SSH) si https GUI;
 Platform a va permite colectarea de informatii statistice si istorice despre utilizarea memoriei,
procesorului, conexiuni si trafic si afi șarea acestora in grafice disponibile in interfata grafica.
Unitatile de timp minim disponibile vor fi: per ora, zi, săptamana sau luna;
 Solutia va permite generarea si afi șarea unei h ărți a re țelei pentru adresele IP și pool -urile noduri
de procesarelor virtuale;
 Solutia va permite agregarea link -urilor (802.3ad) si LACP (Link Aggregation Control Protocol);
 Solutia va suporta gen erarea unei tabele de rutare ierarhizata compus ă din diferite segmente (tip
"parent" "child") pentru spatiile de IP -uri izolate sau suprapuse;
 Platforma va permite alocarea dinamica si controlabila a resurselor tip CPU si memorie RAM (ex.
dedicat, functionare nominala, functionare minima);
 Solutia va dispune de template -uri de configurare generice customizabile in functie de nevoile
specifice;
 Solutia va trimite alerte despre diverse erori prin SNMP, syslog, e -mail;

127
 Solutia va permite definirea de multiple domenii de administrare;
 Solutia va permite resetarea la configuratiile initiale ("din fabrica");
Dimensionare
 Rata de transfer a echipament ului de cel puțin 10 Gbps, pentru serviciu Layer 4, respectiv de cel
puțin 10 Gbps, pentru serviciu Layer 7;
 Rata de procesare a sarcinii specifice de cel puțin 600000 de cereri pe secundă , la nivel de serviciu
Layer 7, respectiv de cel puțin 1 milion de cereri Layer 4 HTTP pe secundă ;
 Capacitate de deschidere si procesare a ce l puțin 200000 conexiuni Layer 4 pe secundă , precum si
a cel puțin 4000 tranzactii SSL (cu chei de 2048 biti) pe secundă ;
 Compresie hardware suportata de cel puțin 5 Gbps, precum si procesare criptografica de cel puțin
8 Gbps;

3.4.2.8.3 Platforma de redistributie a accesului la serviciile de aplica ție

Platforma de redistributie a accesului la serviciile de aplica ție are rolul de a aronda initial, respectiv a
redistribui traficul de tip DNS realizat intre utilizatori si aplicatiile si serviciile din platformele de
procesare și de a proteja serviciul de DNS care deserve ște aceast ă procesare .
Cele 4 noduri de redistribu tie, echipamente de tip GSLB, vor îndeplini fiecare urm ătoarele cerin țe
func ționale specifice minimale:
Rol
 Platforma de redistributie servicii DNS pentru redistributia traficului de tip DNS intre utilizatori si
aplicatiile/serviciile din platformele de pr ocesare;
Redistributie trafic DNS
 Platforma va oferi suport IPv4, IPv6, topologii NAT64, IP anycast;
 Platforma va furniza raspunsuri de autoritate DNS (server autoritar DNS/server secundar DNS)
indreptand traficul catre adresele IP corecte;
 Platforma va obtine informatiile despre starea obiectelor si metrica in mod automat din ADC;
 Platforma va oferi posibilitatea deservirii raspunsurilor pentru obiectele configurate din memoria
cache de mare viteza;
 Platforma va include functionalitatea de authoritative slave DNS server si va raspunde si la cereri
pentru hostname -uri nebalansate;
 Platforma va oferi posibilitatea validarii cererilor de la clienti pe baza de RFC;
 Platforma va suporta DNS SEC si pentru raspunsuri la hostname -uri balansate;
 Platforma va oferi suport de SSL offloading si DNSSEC in hardware;
 Platforma va include o baza de date de geolocatie in scopul directarii utilizatorilor catre cel mai
apropiat data center;
 Platforma va permite colectarea/constructia unei baze de date de geolocatie pentru ad rese IP
private;
 Platforma va permite balansarea pe baza urmatoarelor metrici:
 Round Trip Time;
 Hops;
 Topology;
 Completion Rate;
 Packet Rate;
 Virtual Server Capacity;
 Bits/second;
 Link Capacity;
 Platforma va permite extinderea functionalitatilor native pri n limbaj de scripting cu următoarele
caracteristici:
 Capabilitatea de a folosi declaratii conditionale (if/then) si bucle (for, while);

128
 Capabilitatea de a genera alerte si de a executa script -uri pe baza diferitelor tipuri de evenimente ;
 Capabilitatea de a lterare a cererii sau a raspunsului pe baza de: origine, tip, semnatura sau datele
continute in cerere/raspuns.
 Platforma va permite integrarea cu infrastructura de retea folosind cel puțin următoarele
protocoale de rutare dinamice: BGP, OSPF, ISIS, RIP;
 Platforma va oferi suport pentru rutarea dinamica atat pentru IPv4 cat si pentru IPv6;
Dimensionare
 Rata de transfer a echipament ului de cel puțin 10 Gbps, pentru serviciu Layer 4, respectiv de cel
puțin 10 Gbps, pentru serviciu Layer 7;
 Rata de procesare a sarcinii specifice de cel puțin 300000 de cereri pe secundă , la nivel de serviciu
Layer 7, respectiv de cel puțin 600000 de cereri Layer 4 HTTP pe secundă ;
 Capacitate de deschidere si procesare a cel puțin 120000 conexiuni Layer 4 pe secundă , precum si
a cel puțin 2000 tranzactii SSL (cu chei de 2048 biti) pe secundă ;
 Procesare criptografica de cel puțin 5 Gbps;

3.4.2.9 Switch Core DC

Se vor prevede a minim 2 echipamente per centru de date, configurate cu rol spine (in arhitectur ă
spine -leaf), cu posibilitate de operare software defined.
Fiecare echipament va avea minimal:
 32 de interfe țe configurabile dup ă nevoi în oricare din 1/10/25 Gbps Ethernet sau Fibre
Channel over Ethernet
 6 porturi de uplink de 40 sau 100 Gbps.
 Suport hardware pentr u operare line -rate, nivel 2 si nivel 3 OSI.
 Memorie sistem de minim 16 de GB.
 Memorie de 32GB suport SSD.
Solu ția va oferi urm ătoarele capabilit ăți:
 Suport pentru protocolul Virtual Extensible LAN (VXLAN).
 Suport pentru protocoale de rutare unicast si multicast precum BGP, OSPF, PIM.
 Suport programabilitate cu ajutorul platformelor de automatizare precum Ansible, Puppet
si/sau Chef.
 Posibilitate de configurare si provizionare a echipament ului cu ajutorul limbajului Python.

3.4.2.10 Switch Edge DC
Se vor preved ea cel puțin 2 echipamente per centru de date, configurate cu rol de leaf (in arhitectura
spine -leaf), cu posibilitate de operare software defined.
Fiecare echipament va avea minimal:
 48 de interfețe configurabile după nevoi în oricare din 1/10/25 Gbps Ethernet sau Fibre
Channel over Ethernet
 6 porturi de uplink de 40 sau 100 Gbps.
 Suport hardware pentru operare line -rate, nivel 2 si nivel 3 OSI.
 Memorie sistem de minim 16 GB.

129
 Memorie de 32GB suport SSD.
Solu ția va oferi urm ătoarele capabilit ăți:
 Suport pentru protocolul Virtual Extensible LAN (VXLAN).
 Suport pentru protocoale de rutare unicast si multicast precum BGP, OSPF, PIM.
 Suport programabilitate cu ajutorul platformelor de automatizare precum Ansible, Puppet si
Chef.
 Posibilitate de configurare si provizionare a echipament ului cu ajutorul limbajului Python.

3.4.2.11 Switch Core Campus

Echipamente le trebuie să aiba o configuratie modulara, cu pân ă la minim 6 module, din care 2 module
sunt func ționale pentru unit ățile de tip supervizor si celelalte minim 4 module pentru interfe țe de
transmisie date.
Supervizorul echipament ului va oferi solu ției urm ătoarele caracteristici minimale:
 Capacitate de transmisie de pana la 1.4 Tbps
 Numar de adese MAC : 512000
 Numar de rute IPv4 : 1M.
 Numar rute multicast : 32000.
 Suport de tip open API.
 Suport nivel 2 OSI pentru protocoale precum PVRST , MSTP.2 sau echivalent .
 Suport pentru protocoale de rutare precum, BGP, VRRP , IS-IS, BSR, MSDP, OSPF.
 Suport pentru protocoale de segmentare rețea precum VRF, VXLAN.
 Suport automati zare Netconf, Restconf, gRPC, YANG.
 Posibilitate de operare de tip Software Defined a echipament ului.
Echipament ul va fi echipat cu module de date care să ofere minim următoarele capacita ți:
 40 de interfe țe 1/10 Gbps , Base -T.
 40 de interfe țe 1/10 Gbps, cu suport de conectare fibra optica sau cupru (SFP+).
 8 porturi 40/100G format QSFP28 distribuite pe modulele din sasiu
Fiecare echipament va fi echipat cu surse de putere AC redundante, capabile să susțină consumul unui
șasiu complet echipat .

3.4.2.12 Switch de Management

În fiecare site se va prevedea câte un switch pentru management ul echipamente lor out-of-band.
Fiecare echipament va avea urm ătoarele caracteristici minimale:
 48 de porturi de 1 Gbps
 4 porturi de uplink 1 Gbps cu suport pentru interf ață tip SFP.
 Suport modul de stack cu viteza de 80 Gbps.
 Suport pentru 16000 de adrese MAC.

130
 Suport pentru 2000 de rute IPv4.
 Suport pentru protocoale de nivel 2 OSI precum PVRST+ , MSTP.2 sau echivalent .
 Suport nivel 2 OSI, multicast IGMP snooping.
 Suport p entru transmisie pana la 10 0 milioane de pachete pe secundă .

3.4.3 Sisteme de gestiune

Se v a avea în vedere includerea în ofertă a cel puțin următoarel or componente de implementa t în
cadrul solu ției:
o Platforma de Management integrat a infrastructurii
o Platforma ITIL/ITSM , inclusiv service -desk
o Platforma de monitorizare
o Componente de automatizare a comut ării serviciului între centrele de date

3.4.3.1 Monitorizare sisteme și servicii

Solu ția trebuie s ă realizeze monitorizarea serviciilor de business (prin gruparea unui set de servicii de
infrastructur ă și prin modelarea bazat ă pe componentele de infrastructur ă monitorizate de acesta),
iar informa țiile colectate s ă poat ă fi puse la dispozi ție într -un tab lou de bord unic.
Având în vedere c ă la baza monitoriz ării calit ății serviciilor și a parametrilor SLA stau capabilit ățile de
monitorizare atât la nivelul infrastructurii hardware, cât și cele la nivelul sistemelor de operare, baz ă
de date și aplica ții, es te necesar ca aceste componente de monitorizare s ă fie parte integrant ă a
soluției de monitorizare al serviciilor.
Solu ția trebuie s ă permit ă monitorizarea integrat ă a tuturor elemente lor de infrastructur ă legate de
rețea, servere, storage, sisteme de operare, virtualizare, tehnologii suport utilizate de serviciile
func ționale care fac obiectul contractului (diferitele sisteme de operare Windows, Linux și
dispozitivele de re țea provenind de la diferi ți produc ători), virtualizare, diferite tipuri de serv ere de
aplcia ții, middlware și baze de date utilizate în cadrul solu ției.
Solu ția trebuie s ă permit ă vizualizarea tuturor elemente lor din infrastructura IT, cât și a leg ăturilor
dintre aceste elemente și să permit ă modelarea de servicii de business.
Prini palele caracteristici / funcționalități minimale ale solu ției cerute sunt:
o Monitorizarea elementară a infrastructurii
o Monitorizarea tuturor elemente lor de infrastructur ă, cu sau f ără agen ți
o Afișarea st ării și informa țiilor legate de fiecare element de infrastructur ă
o Alertarea personalului responsabil în caz de eveniment
o Automatizarea unor interven ții de remediere, cum ar fi repornirea automat ă a unor
servicii / echipamente sau alte ac țiuni configurabile
o Planificare de capacitate
o Raportare bogat ă orientat ă SLA
o Monitorizarea de site -uri și aplica ții web, inclusiv la nivel de tranzac ții web
o Monitorizarea serverelor de aplica ții

131
o Monitorizarea bazelor de date
o Monitorizare de protocoale multiple
o Monitorizaera sistemelor de operare
o Monitorizare solu țiilor de virtualizare
o Monitorizarea aplica țiilor, serviciilor și proceselor aplicative
o Monitorizare alimentare și UPS
o Administrare avansat ă
o Cetralizarea informa țiilor prin Tablouri de bord curpinz ătoare și intuitive , ușor de
configurat
o Capabilit ăți grafice multi ple de afi șare a informa ției
o Autodescoperire, import și gestiunea de configura ții
o Capabilitatea de a administra simultan mai mult de un centru de date
o Autentificare și control acces
o Integrarea cu infomra țiile de Log / Audit
o Acces sigur prin HTTPS
o Analiza traficului din re țea
o Analiz ă aprofundat ă, granular ă, a traficului de re țea
o Informa ții despre lățimi de bandă , trafic, probleme de capacitate , în diverse puncte
esențiale ale soluției
o Detectarea anomaliilor de trafic
o Capacitatea de navigare pân ă la nivel de port, IP etc.
o Calcul de band ă utilizat ă
o Capacitatea de a genera alerte prin analiza traficului pân ă la nivel de pachet
o Log Server
o Ușor de utilizat și de integrat cu alte componente, pentru a putea p ăstra toate datele de
log / audir într -un singur loc
o Alertare pe baz ă de evenimente configurabile
o Vizualizare și analiz ă în timp real
o Capabilit ăți avnsate de c ăutare și interogare
o Vizualizare avansat ă, cu posilibtatea configur ării de tablouri de bord
o Control acces granular
Solu ția ofertat ă trebuie s ă monitorizeze întreaga infrastructur ă din ambele centre de date și să
furnizeze o imagine consolidat ă a tuturor serviciilor de business și componentelor tehnice aferente.
Solu ția trebuie s ă acomodeze toate tehnologiile principale ofertate.
Întreaga solu ție trebuie configurat ă în regim de înalt ă disponibilitate și protejat ă la căderea oric ărui
dintre centrele de date.

3.4.4 Alte componente auxiliare.

Se vor avea în vedere cel puțin următoarele componente:
o Câte un c ontainer cu d ulapuri și UPS în fiecare centru de date
o Legături de date centrale
o Internet – minim 20GB per centru de date
o Replicare între centrele de date – minim 2x1Gb

132
Specificații container:
Centru de date prefabricat proiectat în format de modul container care con ține toate echipa mente le
necesare func ționării: unit ăți de alimentare electric ă neîntreruptibil ă, unit ăți HVAC (încalzile,
ventila ție și climatizare), baterii, tablouri de distribu ție, control acces, împreun ă cu toate celelalte
sisteme și componente necesare func ționării normale a centrului de date.
Toate componentele și materialele sunt de cea mai bun ă calitate, oferind manipulare și exploatare
sigur ă, sigur ă și confortabil ă. Cablurile, firele și alte componente nemetalice sunt de tip auto -sting ător
și vor fi în conformit ate cu normele și standardele relevante. Echipamente le instalate satisfac cerin țele
privind siguran ța și compatibilitatea electromagnetic ă. Materialele utilizate trebuie s ă fie
necombustibile. Modulele trebuie s ă fie prefabricate, pre -instalate și cablate, comandate și testate în
fabric ă, înainte de transportul c ătre destina ție.
Se vor folosi materiale dup ă cum urmeaz ă, sau echivalent: containerul va fi realizat din o țel structural
S355J0 de înalt ă calitate conform EN 10025; placarea o țelului va fi realizat ă din o țel S235JR; pere ții
externi sunt realiza ți din plac ări exterioare din o țel, zincate, vopsite, nitate și cu șuruburi la structura
metalic ă de baz ă vertical ă și orizontal ă; interiorul este acoperit cu panouri sandwich, cu umplutur ă de
poliuretan sau vat ă mineral ă.
Secțiunea transversal ă a podelei de la interior la exterior:
– Strat de placaj rezistent la ap ă, grosime 18 mm, acoperit cu PVC rigid de 2 mm.
– Structura de o țel umplut ă cu izola ție din vat ă mineral ă.
– Plăci de o țel
Secțiunea transversal ă a acoperi șului modulului, de la interior la exterior:
– plăci de gips 2 straturi
– Structura de o țel umplut ă cu izola ție din vat ă mineral ă
– Plăci din o țel, galvanizate, vopsite, nituite la structura metalic ă de baz ă.

Ușa echipat ă cu sistem de închidere automat ă a ușii, încuietori mecanice standard și bar ă de panic ă,
de minim 900×2150 mm (LxH).

UPS-ul inclus va putea livra cel puțin 60kVA și va fi dimensionat astfel încât s ă poat ă susține toate
echipamente le din container pentru min. 15 min. UPS -ul trebuie s ă fie scalabil prin ad ăugare de
module adi ționale pân ă la cel pu țin 90kVA.
Atunci când sistemul de baterii este scos din uz pentru între ținere sau UPS -ul este utilizat ca
convertizor de frecven ță, UPS -ul va continua s ă func ționeze și să îndeplineasc ă toate criteriile de
performan ță stabilite la starea de echilibru, cu excep ția capacit ății de timp de rezerv ă pentru
întreruperea alimentării .
UPS-ul va fi controlat de un microprocesor și va afi șa starea blocului func țional, m ăsurătorile, alarmele
și alte informa ții utile prin intermediul unui afi șaj grafic LCD pentru verificare parametrii, starea UPS –
ului și a bateriei, jurnale de evenimente și alarme cu timbru de timp și date pentru referin ță,
diagnosticare și acțiuni atunci când e ste cazul.
Modulul container va fi echipat cu 6 rack -uri de dimensiuni : înălțime 2000 mm, l ățime 800 mm,
adâncime 1200 mm. Fiecare rack va fi echipat cu min. dou ă PDU -uri fiecare cu cel puțin 20 x C13 și 4
x C19.
Solu ția de r ăcire pentru echipamente le din container trebuie s ă fie în configura ție N+1.

133
Modulul Container va fi echipat cu un sistem de stingere incendiu cu NOVEC 1230 sau echivalent.
Concentra ția proiectat ă pentru gazele NOVEC ar trebui s ă fie de 5,6% (pericole mai mari clasa A în
conformitate cu EN15004 / ISO14520). Sistemul complet const ă din cilindri umplu ți cu gaz NOVEC sau
echivalent, dispozitiv de ac ționare automat ă și conducte și duze prin care gazul este eliberat în spa țiul
protejat. Centrul de date trebuie s ă dispun ă de detectoare de fum instalate și conectate la panoul de
control al alarmei de incendiu pentru container.
Generator energie electric ă
 Frecven ță curent – 50Hz
 Tensiune ie șire – 400/230V
 Putere – cel puțin 130KVa
 Factor putere (Cos Phi) – 0.8
 Capacitate rezervor – min. 180 l
 Panou de control incorporat
 Livrat cu ulei si agent r ăcire pentru -30°C
Dacă generatorul este a mplasa t exterior, acesta trebuie s ă poat ă func ționa fără probleme și în condi ții
de mediu extreme .

Furnizorul este responsabil ca generatoarele s ă fie livrate cu combustibil, dup ă care va trebui s ă
asigure trimestrial completarea acestuia. Furnizarea necesarului suplimenta r de combustibil (pentru
avarii prelungite care nu se datoreaz ă Furnizorului) r ămâne în sarcina Beneficiarului.

Soluția de virtu alizare:
Cerin țe minimale pentru solu ția de virtualizare instalat ă pe serverele lamelare:
 oferă o arhitectur ă independent ă de un sistem de operare de uz general cu o amprent ă pe
disc cât mai mic ă (max 300 MB) și care permite ca instalarea și boot -area hipe rvizorului s ă fie
făcută foarte rapid, direct de pe discurile din server, din re țea sau pe de pe un stick USB;
 oferă suport pentru o gam ă largă de sisteme de operare instalate la nivel de ma șină virtual ă –
Windows (Server: 2016, 2012 R2, 2008 R2, 2003 R2; Desktop: 10, 8.1, 7), Red Hat (4,5,6,7),
SuSE, Ubuntu, FreeBSD, Debian, CentOS, Solaris, Oracle Linux;
 asigur ă o densitate mare de ma șini virtuale, oferind suport pentru configura ții fizice
generoase la nivel de host, prin configurarea cu pân ă Ia 576 de CPU -uri logice și 12TB de
memorie RAM;
 permite rularea de aplica ții mari consumatoare de resurse, oferind support de configurare a
mașinilor virtuale cu pân ă la 128 procesoare virtuale și 6TB RAM;
 permite utilizarea disk -urilor rapide instalate pe server pentru configurarea ca read cache la
nivel de ma șină virtual ă sau de disk, oferind astfel performan țe deosebite pentru aplica țiile
Tier 1;
 asigur ă rate mari de consolidare a ma șinior virtuale pe host -uri pr in mecanisme de optimizare
și supra alocare a memoriei pentru reducerea costurilor asociate infrastructurii fizice (ex.
num ăr host -uri, num ăr porturi de re țea / switch -uri) și de licen țiere precum și pentru
asigurarea continuit ății în func ționare a aplica țiilor în cazul unor întreruperi par țiale
neplanificate;

134
 permite crearea de grupuri virtuale de resurse (memorie și procesor) pentru controlul și
asigurarea performan țelor ma șinilor virtuale care folosesc în comun respectivele grupuri de
resurse;
 asigur ă suport pentru Trusted Platform Module (TPM) 2.0 la nivel de hipervizor si pentru
virtual Trusted Platform Module (TPM) 2.0 pentru ma șinile virtuale, asigurând astfel o
protecție și integritate sporit ă atât pentru hipervizor cât și pentru sistemele de operare guest;
 asigur ă suport pentru tehnologiile VBS (virtualization -based security) integrate în noile
sisteme de operare Microsoft – Windows 10 si Windows Server 2016;
 oferă o securitate crescut ă prin înc ărcarea proceselor importante la nivel de hypervisor în
zonele de memorie reziliente, prin utilizarea ultimelor func ționalit ăți disponibile în noile
versiuni de procesoare;
 asigur ă posibilitatea de criptare a tuturor fi șierelor asociate unei ma șini virtuale, indiferent de
sistemul de operare din ma șina virtual ă sau de tipul de stocare folosit ă;
 asigur ă criptarea traficului necesar migr ării unei ma șini virtuale în func ționare de pe un host
pe altul, caracteristic ă ce poate fi setat ă la nivelul ma șinii virtuale;
 asigur ă identificarea automat ă a celei mai bune moda lități de stocare a unei ma șini virtuale,
în func ție de nivelul de servicii asociat acesteia și ofer ă informa ții în timp real privind
conformitatea cu nivelul de servicii asociat;
 permite gruparea mai multor volume de stocare cu performan țe similare în cl ustere pentru
simplificarea Management ului și plasarea inteligent ă respectiv balansarea înc ărcării (în
func ție spa țiul disponibil sau timpul de acces la sistemul de stocare) ma șinilor virtuale în mod
automat la nivel de cluster;
 permite balansarea automat ă a înc ărcării pe host -uriIe din cluster prin mutarea ma șinilor
virtuale în vederea asigur ării resurselor optime pentru func ționare;
 asigur ă func ționalitate de failover astfel încât, în cazul defect ării unui host, ma șinile virtuale
care rulau pe acel host să fie restartate automat pe celelalte host -uri din cluster;
 dispune de capacit ăți de failover astfel încât, în cazul defect ării par țiale a unui host, ma șinile
virtuale care rulau pe acel host s ă fie migrate automat pe celelalte host -uri din cluster iar ho st-
ul degradat s ă fie trecut automant în mentenanță după evacuarea ma șinilor virtuale;
 dispune de capacit ăți de failover astfel încât, în cazul bloc ării sistemului de operare instalat
într-o ma șină virtual ă, respectiva ma șina virtual ă să fie restartat ă automat pe acela și host
pentru deblocarea sistemului de operare, a serviciilor și aplica țiilor;
 dispune de capacitate de failover care s ă detecteze problemele de acces la datastore la nivel
de host și să restarteze automat ma șinile virtuale afectate pe un alt host din cluster;
 oferă posibilitatea de boot -are rapid ă în cazul aplic ării actualiz ărilor, prin eliminarea timpilor
mari necesari ini țializării hardware în timpul procesului de boot;
 asigur ă comutatoare de re țea virtuale (switch -uri) administrate centra lizat, Ia care s ă se
conecteze ma șiniIe virtuale și interfe țele de re țea fizice de pe fiecare host;
 permite crearea de profile pentru host -uri (servere fizice) astfel încât instalarea pe mai multe
host -uri s ă se fac ă foarte rapid, respectând o configura ție prestabilit ă, configurabil ă pentru
eliminarea erorilor umane de configurare;
 oferă interfa ță unic ă de management bazat ă pe interfa ța web HTML 5, accesibil ă de pe
majoritatea sistemelor de operare și browser -erelor existente precum Firefox (Windows, Mac

135
OSX), Google Chrome (Windows, Mac OSX) și Edge (Windows) pentru simplificarea
Management ului;
 soluția de Management centralizat este disponibil ă ca appliance virtual pentru simplificarea
instal ării, actualiz ării și administr ării precum și pentru reducerea costurilor asociate (ex.
licen ță sistem de operare, licen ță bază de date);
 soluția de Management centralizat permite nativ configurarea în înalt ă disponibilitate pentru
evitarea situa țiilor de downtime la nivelul de Management ;

Soluția de Management centr alizat a virtualizării va fi instalata in minim o instanta virtuala in fiecare
centru de date.

3.5 Echipamente IT locale

3.5.1 Echipamente tip scanner

Pentru a asigura un flux de lucru f ără întreruperi, în fiecare loca ție de colectare a lucr ărilor v or trebui
asigurat e cel puțin câte două echipamente de scanare de productivitate mare. Fiecare echipament va
avea urm ătoarele caracteristici minimale:
 Tip: A4 ADF Scanner
 Iluminare LED
 Duplex cu o singur ă trecere (2xCCD)
 Moduri scanare: Mono (1bit) , Greyscal e (8bit) , Color (24bit)
 ADF cu capacitate minim ă de 80 foi A4 la 80g/m2
 Ciclu recomandat de scanare: 4,000 pagini pe zi ;
 Viteza (JPG, 300 dpi ):
o Full color / greyscale: minim 60 pagini A4 pe minut, simplex mode
o Full color / greyscale: minim 120 imagini A4 pe minut, duplex mode
 Rezoluție optic ă: 600 dpi (rezolu ție de scanare reglabil ă de la 50 la 600 / 1200) ;
 Hârtie suporat ă: 30-400 g/m2
 Senzor ultrasonic de detectare a alimentării cu mai mult de o pagin ă
 Func ții procesare imagini:
o Auto -detec ția dimensiuni i document ului
o Auto -detecție de culoare
o Auto -detecție și eliminare pagini albe
o Auto -deskew
o OCR și Barcode (1 și 2 dimensiuni )
o Automatizarea fluxului de scanare cu profile editabile, complexe și flexibile de
scanare, care se pot apela printr -un singur click
o Editarea document ului rezultat – rotire, mutare și ștergere pagini
o Licen țe software de scanare incluse
 Drivere: TWAIN și ISIS; Windows 7, 8, 10, Windows Server 2012, 2016, Linux
 Formate : tiff, jpg, pdf , pdf/a, bmp, pdf cu OCR
 Interfa ță: USB 3.0

136

Furnizor ul va asigura câte dou ă echipamente identice de rezerv ă per loca ție în minim șase loca ții
distribuite uniform pe teritoriul na țional, astfel încât s ă poat ă asigura pe perioada campaniilor de
evaluare na țional ă înlocuirea unui echipament defect in maxim 2 -3 ore.

3.5.2 Echipamente tip stație de lucru pentru scanare

Fiecare loca ție de scanare va fi dotat ă cu o sta ție de lucru la care se vor conecta cele dou ă scanere de
mare capacitate. Aceast ă stație de lucru va avea urm ătoarele caracteristici minimale:
Unitate centrală
 Chipset – Intel H310 sau echivalent
 Procesor – Minim 4 cores/4 threads, de tip Intel core i 3, 6MB cache sau echivalent , min.3.6GHz
 Memorie RAM – 8 GB RAM DDR4 2666 MHz; Suport pentru 32GB RAM, dou ă sloturi DIMM
 Placa de baz ă – Fabricat sub aceea și marcă cu sistemul de calcul
 HDD/SSD
o SSD 256 GB PCIe NVMe SED
o HDD 500GB 7.2krpm SATA
 Placa video cu suport pentru 2 display -uri conectate simultan, DirectX® 12
 Placa re țea – Integrat ă 10/100/1000 Gigabit Ethernet, capabilit ăți WoL, PXE
 WLAN ac + Bluetooth 5
 Porturi
o 3 x USB 2.0, 2 x USB 3.1, 1 x USB Type -C; cel puțin un port USB trebuie s ă permit ă
alimentarea și încărcarea dispozitivelor externe chiar și când PC -ul este închis
o 1 x RJ45
o 1 x HDMI, 1 x DisplayPort
o 1 x headphone jack pe panoul frontal
o 2 x M.2 s lots pe placa de baza
 Sursa de alimentare – minim 85% eficien ță
 Caracteristici de securitate
o posibilitatea de a seta parole diferite pentru boot, BIOS și Hard -disk
o modul TPM 2.0
o controlul interfe țelor USB
o slot Kensington
o Creden țial Guard Ready , Device Guard Capable
 Sistem de operare – Windows 10 Professional OEM preinstalat (personalul MEC nu are
competențele necesare pentru exploatarea unui alt sistem de operare) .
 Standarde
o CE, RoHS , Microsoft HCL , Energy Star
o DMI , PXE, WMI , SMBIOS
o ISO 9001, ISO 14001
 Tastatura 104-key și Optical wheel mouse
Monitor
 Display 23.8 inch , antiglare, de tip 24×7

137
o Tehnologie IPS (In Plane Switching),
o Aspect 16:9, rama sub țire pe minim trei laturi
o Rezolutie 1920 x 1080 nativ ă
o Pixel pitch 0.275 mm
o Unghi de vizualizare 178ș / 178ș (vertical/orizontal) pentru un contrast de min 10:1
o Luminozitate Min 250 cd/m2
o Contrast tipic 1000:1
o Timp tipic de raspuns 5 ms
 Video input
o 1 x HDMI
o 1 x DisplayPort in
 Audio incorporat , minimum 2W, port audio
 5 x USB 3
 Ergonomie
o Ajustarea înalțimii – Minim 150 mm
o Posibilitate înclinare – 5° / + 20°
o Posibilitate pivotare – 90° cu func ție AutoPivot
o Posibilitate montare VESA
 Standarde – RoHS , ISO9241 -307, TCO Displays 7.0, ENERGY STAR® 7.0

3.5.3 Echipamente tip sta ție de lucru pentru administrare

Se vor livra zece sta ții de lucru pent ru administratori, cu caracteristic ă de mobilitate. Aceast ă stație de
lucru va avea urm ătoarele caracteristici minimale:
 Chipset – Intel QM370 sau echivalent
 Procesor – Intel i7, sau echivalent; 6 cores/12 threads, cache 9MB , minim 2.4Ghz, TDP maxim 45W
 Memorie – 32GB, suport pentru cel puțin 64 GB RAM, memorie ECC func țional ă
 Placa de baz ă – fabricat ă sub aceea și marcă cu sistemul de calcul
 Stocare
o 1 x SSD 5 21GB de tip Highend
o 2 x HDD 1TB, sensor pentru protejarea HDD -ului la șocuri, suport RAID 0,1
 Placă video dedicat ă, NVIDIA® Quadro® P 4200, 8GB GDDR5 sau echivalent
 Placă audio integrat ă; 2 boxe stereo integrate
 Placă rețea integrat ă 10/100/1000 Gigabit Ethernet, WoL
 Placă rețea wireless integrat ă WLAN 802.11 ac \b\g\n, WiFi Certified
 Modul LTE
 Bluetooth integrat, ver. 5
 Porturi
o 3 x USB 3.1, minim un pot cu alimentare
o 2 x USB Type C Thunderbolt 3
o 1 x DisplayPort sau HDMI
o 1 x LAN RJ -45
o 1 x Audio -in/out

138
o 1 x Kensington Lock
 Sloturi
o 1 x SmartCard Reader
o 1 x SDCard Reader
o 1 x Simcard slot
 Display 17.3 -inch IPS antiglare, Rezolu ție minim FHD
 Webcam HD integrat , microfo n
 Baterie Li-Ion, 6 celule, minim 95Whr
 Caracteristici de securitate
o Posibilitatea de a seta parole diferite pentru bo ot și BIOS
o Posibilitate de blocare a echipament ului printr -un cod propriu de securitate
o Dispozitiv de scanare biom etrică
o Modul TPM V2.0
o MIL-STD-810G
o BIOS compatibil Computrace
 Sistem de operare Microsoft Windows 10 OEM (personalul MEC nu are competențele necesare
pentru administrarea și exploatarea unui alt sistem de operare)
 Suport pentru Intel vPro sau echivalent
 Tastatur ă, mouse laser 2000 dpi cu 10 butoane programabile

139
4 Strategia de implementa re

Sistemele centrale vor fi impleme ntate și gata de a fi lansate în produc ție (adic ă vor avea toate
acceptan țele luate) în maxim 6 luni de la demararea contractului, incluzând aici toate func ționalit ățile
de baz ă ale solu ției. Se vor putea amâna anumite elemente cum sunt cele legate de cap.3.2.1.4.6.6
(fluxuri de lucru) și cap. 3.2.5 (analize și tablouri de bord) cu pân ă la 6 luni, în m ăsura în care
Beneficiarul întârzie cu definitivare cerin țelor aferente.
Înrolarea în sistem a tuturor unit ăților din teritoriu se va face în urm ătoarele 12 luni dup ă lansarea în
produc ție. Minim 10% dintre unit ăți acoperind 15% din popula ția de elevi trebuie înrolate în primele
12 săptămâni dup ă lansare.
Serviciul de asisten ță va trebui s ă fie complet func țional în moment ul lans ării, chiar dac ă acesta va fi
dimensionat propor țional cu num ărul de utilizatori înrola ți.

4.1 Cadrul activit ăților

Beneficiarul dore ște implementa rea și Menține rea în func țiune în condi ții optime a SIMS pentru
următorii 5 ani dup ă lansarea în produc ție, prin achizi ția unor servicii menite să creeze si s ă mențină
în func țiune o solu ție IT viabil ă, din punct de vedere aplicativ și al infrastructurii hardware și software,
în final preg ătită pentru a sus ține activit ățile Beneficiarului pe termen lung.
Componentele aplicative, descrise în cap.3.2, constituie nivelul prioritar ca importan ță din punctul de
vedere al Beneficiarului. De și indispensabil ă, infrastructura IT este considerat ă un serviciu secundar,
și, în condi țiile în care problemele ridicate de aceasta sunt totu și de o complexita te ridicat ă iar
organiza ția Beneficiarului nu are resursele necesare pentru a face fa ță acestora în mod optim,
Beneficiarul a decis s ă externalizeze serviciul de asigurare a func ționării acesteia.
Beneficiarul va p ăstra responsabilitatea oper ării componentelor aplicative, urmând ca Furnizorul s ă
preia toate activit ățile legate de infrastructur ă.
Contractul se va derula în trei faze distincte:
I. Construcție (6 luni de la demararea Contractului) – în prima faz ă Furnizorul va trebui :
a. să deruleze faza de analiz ă, cu asisten ța Beneficiarului
b. să implementeze soluția informatic ă aferent ă SIMS
c. să livreze toate echipamente le și produsele software necesare soluției centrale
d. să instaleze și să configureze solu ția, cu toate compon entele sale hard ware și
software, în cele dou ă centre de date puse la dispozi ție de Beneficiar
e. să preg ăteasc ă toată document ația necesar ă soluției
f. să efectueze toate testele necesare și să obțină acceptan țele centrale din partea
Beneficiarului
g. să instruiasc ă personalul Beneficiarului r ăspunz ător cu componentele centrale ale
soluției
h. să facă opera țional serviciul de mentenanță și suport
i. să facă opera țional serviciu de asisten ță a utilizatorilor
j. În aceast ă fază trebuie finalizate toate func ționalit ățile esen țiale ale Nucleului
aplicativ, împreun ă cu toat ă infrastructura aferent ă:
i. Notare, prezen ță, activitate didactic ă
ii. Site elevi și părinți

140
iii. Func ționalit ăți administrative
iv. Raportare opera țional ă
v. Elementele de securizare (API Gateway, Identitate etc.)
vi. Procesele de semnare avansat ă și calificat ă
vii. Arhivarea documente lor, fluxurile aferente
viii. Colectare date în data lake
ix. Toate elementele de infrastructura hardware și software
x. Toate elementele de securitate

II. Înrolare (12 luni de la finalizarea Construc ției) – în aceast ă fază Furnizorul va trebui :
a. să livreze în teritoriu echipamente le locale
b. să înroleze în sistem unit ățile din teritoriu, cu concursul responsabililor locali
c. să instruiasc ă personalul Beneficiarului din teritoriu
d. să obțină acceptan țele locale de la responsabilii locali
e. să asiste Beneficiarul în operarea sistemului central – la sfâr șitul acestei faze
Beneficiarul trebuie s ă poat ă opera singur SIMS din punct de vedere func țional
f. să asigure mentenanță , suportul și serviciul de asisten ță a utilizatorilor
g. anumite componente complexe pot continua a fi dezvoltate și în aceast ă fază, pân ă la
terminarea sa:
i. Componentele colaborative din cadrul Nucleului aplicativ
ii. Data warehouse
iii. Analizele și vizualiz ările avansate de date
iv. Tablourile de bord
v. Arhiva legal ă
vi. Evaluar ea na țional ă

III. Producție (5 ani de la finalizarea Construc ției) – în a treia faz ă Furnizorul va asigura :
a. Mentenanță și suportul sistemului central
b. Garan ția echipamente lor din teritoriu
c. Serviciul de asisten ță a utilizatorilor
Trebuie în țeles de c ătre Furnizor că principalul scop al acestui Contract este Crearea și Asigurarea
bunei func ționări a SIMS prin intermediul unor servicii de cea mai înalt ă calitate conforme cu cerin țele
Caietului de sarcini, incluzând și nivelul SLA cerut. Tehnologia IT propriu -zisă aferent ă SIMS este doar
un corolar al acestui scop principal și în consecin ță achizi ția propriu -zisă de tehnologie software și de
echipamente este secundar ă. Din acest motiv pl ățile nu vor fi legate direct de achizi țiile de hardware
și/sau software c a atare, ci numai de Acceptan țe / trecerea în produc ție a SIMS . Astfel, pl ățile aferen te
Contractului se vor face dup ă cum urmeaz ă:
 10% avans din valoarea total ă a contractului cu TVA în termen de maxim 30 de zile
 20% din valoarea total ă a contractului cu TVA în termen de maxim 30 de zile distribui ți uniform
pe Acceptantele Centrale (în perioada de Construc ție; Furnizorul va propune structur ă a
Acceptan țelor Centrale și o distribu ție pe acestea a celor 20% aferen ți – Beneficiarul va decid e
asupra acestui subiect în faza ini țială a proiectului );
 10% din valoarea total ă a contractului cu TVA în termen de maxim 30 de zile la Acceptan ța
parțială legat ă lansarea în produc ție (finalul perioadei de Construc ție);
 10% din valoarea total ă a contractului cu TVA în termen de maxim 30 de zile distribui ți uniform
pe Acceptantele Locale (în perioada de Înrolare);
 50% din valoarea total ă a contractului cu TVA în termen de maxim 30 de zile la Acceptan ța
complet ă (finalul perioadei de Înrolare );

141
Pe fiecare etap ă se vor depune de c ătre operatorul economic câ știgător urm ătoarele documente :
de la primirea urm ătoarelor documente obligatorii în original:
• Factura emis ă de contractant
• Garan ția pentru returnarea/ restituirea avansului, emis ă conform dispoz ițiilor legale,
eliberat ă de o societate bancar ă sau de o societate de asigur ări, sub form ă de garan ție
bancar ă sau poli ță de asigurare
Fiecare plată va fi justificat ă integral, prin produse livrate, respectiv servicii prestate, pân ă
la finalizarea execut ării contractului, înainte de facturarea final ă. În caz contrar, achizitorul
are dreptul de a executa garan ția pentru returnarea avansului, pentru întreaga valoare,
inclusiv de a aplica penalit ăți de întârziere
Pe perioada post -implementa re de 5 ani, se va depune o scrisoare de garan ție de bun ă execu ție a
contractului în cuantum de 20% din valoarea f ără TVA a contractului, în forma prev ăzută în
document ația de atribuire, în termen de maxim 5 zile lucr ătoare de la semnarea contractului .
Garan ția tehnic ă este distinct ă de garan ția de bun ă execu ție a contractului .
4.2 Aria de cuprindere

Furnizorul este responsabil de construc ția SIMS și înrolarea în sistem a unit ăților din teritoriu.
După lansarea SIMS în produc ție, Furnizorul va fi responsabil permanent (24/7) de toate aspectele
legate de infrastructura IT aferent ă SIMS, asigurând (în condi țiile de SLA cerute la cap.5 .3):
 Func ționarea infrastructurii necesare rul ării SIMS ;
 Operarea SIMS al ături de Beneficiar in perio ada Înrol ării (operarea SIMS revine Beneficiarului
după aceea)
 Mentenanță componentelor aplicative SIMS din punct de vedere tehnologic
 Replicarea SIMS între centrele de date , atât la nivel de configura ție cât și de date; asigurarea
continuit ății SIMS în cazul unui eveniment nedorit și a func ționării acestuia în parametrii
stabili ți;
 monitorizarea continu ă a întregii infrastructuri centrale gestionate, cu posibilitatea de a
evalua în fiecare clip ă nivelul SLA al fiec ărui serviciu func țional în parte pr ecum și a serviciilor
func ționale grupate pe categorii majore, cu toate detaliile necesare, în cadrul unui tablou de
bord pentru Management ;
 gestiunea evenimente lor generate de sisteme pentru a putea evalua cauza func ționării
inadecvate sau a defectelor at unci când acestea se produc;
 asigurarea proceselor ITIL de Gestiune a Incidentelor, Asigurare a Capacit ății, Performan ței și
a Disponibilit ății, precum și de Gestiune a Activelor IT și a Schimb ării, prin fluxuri operative și
tehnologie adecvat ă;
 asigurarea backup -ului pentru baze le de da te, conform politicilor de back up stabilite .

Scopul principal este func ționarea componentelor SI MS 24×7 în parametrii de performan ță și
disponibilitate solicita ți în prezentul Caiet de sarcini, în condi țiile în care se va asigura pe cât posibil un
timp de via ță optim respectivelor componente. Toate serviciile aferente vor fi organizate de c ătre
Furnizor conform normelor ITIL.
De asemenea , personalul Beneficiarului va putea fi implicat și în opera țiunile de rutin ă legate de
diverse interven ții, modific ări și reconfigur ări de rutin ă, sub atenta supraveghere și îndrumare a

142
Furnizorului, pe baza procedurilor detaliate de c ătre acesta în document ația sistemului – Furnizorul î și
va p ăstra responsabilitatea asupra tuturor opera țiunilor și rezultatelor lor, atât timp cât acestea au
fost f ăcute cu aprobarea sa și conform procedurilor agreate.
Furnizorul va asigura în toate detaliile, document at, și transferul de cuno ștințe necesare func ționării
și oper ării sistemului, component ă cu component ă, atât c ătre administratorii Beneficiarului (o dat ă în
faza de Construc ție și încă o dat ă în a doua parte a fazei de Produc ție) cât și (la finalizarea Contractului)
către personalul care va prelua și asigura mentenanță după încetarea Contractului.

4.3 Livrabilele proiectului

În cadrul proiectului se vor livra toate elemente Menționate în cap.3, conform și cu cerin țele celorlalte
capitole. Preciz ăm ca lista acestora nu este limitativ ă – Furnizorul este obligat s ă suplimenteze aceast ă
listă în mod expl icit cu toate elementele necesare func ționării SIMS a șa cum este specificat aici, f ără a
altera termen ii și condi țiile financiare agreate.
Solu ția informatic ă va fi înso țită de toat ă document ația necesar ă, con ținând cel pu țin urm ătoarele
elemente :
 Specificarea cerin țelor func ționale
o Actori și cazuri de utilizare
o Informa ții vehiculate, surse de date
o Procesare și fluxuri de date, reguli de validare și transformare
o Colectare și afișare a datelor
o Gestiunea utilizatorilor, roluri și profiluri
o Interfe țe utilizator
o Interfe țe aplicative
o Administrare operativ ă, monitorizarea activit ății actorilor
o Procese colaborative
o Arhivare legal ă
 Specificare cerin țelor tehnice
o Cerin țe de performan ță
o Cerin țe de securitate
o Cerin țe de disponibilitate
o Cerin țe de audit și tras abilitate
o Cerin țe legate de interfa țarea aplicativ ă și de schimbul de date
o Cerin țe legate de stocarea de date
o Cerin țe legate de autentificare și autorizare
o Administrare tehnic ă, monitorizarea func ționării sistemelor
o Non -repudierea tranzac țiilor școlare
o Cerin țe legate de stocarea documente lor pe termen lung
o Cerin țe GDPR
 Proiecte tehnice
o Arhitectura solu ției informatice
o Arhitectura de securitate
o Proiectarea bazelor de date (OLTP) și a altor depozite de informa ții asociate (OLAP,
big data / data lake, arhiv e etc.)
o Specifica ții software detaliate pentru serviciile func ționale

143
o Document ație tip Blue -print legat ă de configurarea produselor COTS, acolo unde este
cazul (de exemplu infrastructura software de tip API Gateway, Document
Management , Identificare și Aut entificare Utilizatori etc.)
o Low-Level Design (LLD) pentru infrastructura hardware și software
o Ciclul de via ță al informa țiilor și documente lor; GDPR
 Document ația de testare func țional ă
o Specifica ții de testare
o Planuri de testare
o Rapoarte de testare
 Documente de înso țire
o Document ație pentru codul software
o Document ație de instalare
o Conformitate GDPR
o Manuale de administrare
o Manuale de operare
o Manuale utilizator
Lista de mai sus nu este limitativ ă – Furnizorul va fi obligat s ă adauge orice document ație necesar
îndeplinirii cerin țelor proiectului sau orice document necesar Beneficiarului pentru a l ămuri mai bine
func ționarea sau utilizarea SIMS. Beneficiarul va aproba fiecare document în parte, având dreptul de
a solicita complet ări sau, acolo unde este j ustificat, noi documente .
Preciz ăm că, înainte de implementa re, document ația tehnic ă aferent ă arhitecturii și proiect ării de
detaliu a solu ției va fi auditat ă de c ătre un consultant de ter ță parte – eventualele observa ții făcute
de acesta vor fi negociate împreun ă cu Beneficiarul și, acolo unde este necesar, vor fi însu șite și
corectate de c ătre Furnizor înainte de implementa re.
În cadrul procesului de implementa re, lansare în produc ție și apoi mentenanță a SIMS se vor livra
minimal urm ătoarele servicii:
 Servicii de implementa re a solu ției informatice integrate la nivel central
o Analiz ă și design
o Construc ție, livrare, instalare și configurare a elemente lor componente
o Integrare cu sisteme ter țe
o Încărcare și / sau migrare date
o Testare
 Func țional ă
 De disponibilitate și continuitate
o Lansare în produc ție, produc ție asistat ă
 Servicii de implementa re a solu ției informatice integrate la nivel local
o Livrare, instalare și configurare a componentelor locale
o Înrolare în sistem a unit ăților din teritoriu , prin asisten ță nemijlocit ă livrat ă de la distan ță
(remote ) personalului local al b eneficiarului (acesta va fi fost instruit în prealabil)
 Servicii de instruire
o La nivel central, pentru administratorii tehnici
o La nivel local, pentru utilizatori
 Instruire direct ă pentru directori și secretariat (câte 2+2 per școală, organiza ți în
clase de minim 2 zile și maxim 18 cursan ți)

144
 Instruire indirect ă (tip train -the-trainers) pentru profesori (câte o clas ă de 15
cursan ți minim 2 zile per jude ț/sector)
o Materiale elec tronice tip eLearning
 Pentru profesori
 Pentru secretariatul școlar și directori
 Pentru elevi și părinți
 Servicii legate de asigurarea func ționării sistemului
o Mentenanță și suport tehnic la nivelul componentelor centrale
 Gestiunea tehnic ă și Menține rea în parametrii agrea ți a solu ției
 Operare ITIL (configura ție, capacitate și performan ță, disponibilitate și
continuitate, incidente și probleme, securitate, cereri de schimbare, opera țiuni)
 Monitorizarea continu ă a SLA și raportarea regulat ă către Beneficiar
o Garan ție și suport la nivelul componentelor locale
o Serviciu de tip centru de contact
 Canale de contact de tip telefonic, email și portal de sesiz ări pentru angaja ții MEC
 Canale de contact de tip email și portal de sesiz ări pentru elevi și profesori
o Servicii de comunica ții
 Comunica ții de date la nivelul celor dou ă centre de date
 Acces internet 2x10Gb per centru de date (conectare d irect în container),
cu protecție anti-DDoS la nivelul operatorului de comunica ții
 Sincronizare date între cele dou ă centre de date 2x1Gb
Pe lâng ă auditul tehnic al solu ției IT înainte de implementa re (to be) , auditorul de ter ță parte va face
un audit al solu ției și dup ă implementa re acesteia (as is). Și pentru acesta, eventualele observa ții
făcute de auditor vor fi neg ociate împreun ă cu Beneficiarul și, acolo unde este necesar, vor fi însu șite
și corectate de c ătre Furnizor.
De asemenea , auditorul va derula teste comprehensive de perfo rman ță și de securitate, ale c ăror
observa ții, odat ă însușite de Beneficiar, devin obl igatorii de remediat de c ătre Furnizor.
Furnizorul are obliga ția de a sprijini activitatea auditorului, de exemplu facilitându -i acestuia accesul
pe sistema sau furnizând toate detaliile tehnice necesare, cu aprobarea Beneficiarului.

4.4 Organizare și Metodologie

Furnizorul va face o descriere complet ă a modului în care acesta în țelege obiectivele proiectului și
sarcinile stabilite prin acesta, abordarea urmat ă în prestarea serviciilor și metodologia de realizare a
activit ăților în scopul ob ținerii rez ultatelor a șteptate. Trebuie avute în calcul și prevederile legale din
domeniu care pot influen ța derularea proiectului.
Furnizorul este obligat s ă identifice și să explice aspectele cheie privind îndeplinirea obiectivelor
Contractului, principalele aspect e al solu ției propuse, modul cum acestea r ăspund obiectivelor
proiectului și atingerii rezultatelor a șteptate.
Abordarea activit ăților propuse pentru realizarea obiectivelor, în raport cu cerin țele stabilite prin
document ație, trebuie descrise succint, cu referire la descrierea detaliat ă a solu ției, iar derularea lor
în timp și resursele umane și materiale alocate trebuie s ă se reg ăseasc ă în referin țele din planul de
lucru și reflectate în elementele financiare.

145
Furnizorul va descrie metodologia pe care o folose ște pentru realizarea proiectului și pentru
organizarea activit ății de Management al infrastructurii, inclusiv pa șii propu și pentru introducerea
unui Management al serviciilor care urmeaz ă bunele practici ITIL. Aceasta va trebui s ă propun ă inclusiv
o organizare adecvat ă a Beneficiarului pentru a putea prelua activitatea curent ă de la Furnizor.

4.4.1 Planul de lucru

Furnizorul va descrie modul în care î și va organiza activit ățile în timp, succesiunea și interdependen ța
dintre acestea.
Planul d e lucru trebuie s ă cuprind ă punctele de control ale Contractului, a șa cum și le propune acesta.
Trebuie respectat termen ele avansate mai sus.
Planul trebuie s ă fie coerent, s ă poat ă demonstra atingerea obiectivului general și al obiectivelor
specifice ale Contractului în timp.
Planul ini țial poate fi amendat în urma fazei de ini țiere a Contractului, cu aprobarea Beneficiarului, cât
și pe parcursul desf ășurării activit ăților în timp. Planul trebuie prezentat utilizând un software de
planificare a activit ăților.

4.4.2 Organizare

În ceea ce prive ște organizarea și conducerea Contractului, Furnizorul trebuie s ă foloseasc ă una dintre
metodologiile larg -cunoscute în practica interna țional ă (Prince2, PMBOK sau echivalente).
Furnizorul va prezenta modul de organizare al propriei echipe, inclusiv al echipei propuse pentru
Management ul Contractului.
Totodat ă, Furnizorul va face propuneri pentru organizarea Beneficiarului în vederea conducerii
proiectului conform metodologiei pr opuse.
Informa țiile și datele culese de c ătre Furnizor în acest Contract pot fi sensibile și trebuie subliniat ă
respectarea confiden țialității acestora. Toate informa țiile și datele culese prin intermediul acestui
Contract vor putea fi folosite în alte sc opuri sau publicate doar cu aprobarea scris ă a Beneficiarului.

Întâlniri de Management
Contractul fiind complex, presupunând decizii tehnice și organizatorice de luat pe parcurs, managerii
de Contract din partea Furnizorului și ai Beneficiarului trebuie să aibă întâlniri regulate la cel mult dou ă
săptămâni pentru discutarea problemelor curente și a avansului realizat.
În aceste întâlniri, scurte și axate pe rezolv ări la problemele zilnice, pot participa, pe lâng ă cei doi
manageri de Contract, și invita ți ai acestora, în func ție de subiectele discutate. Vor fi întocmite Minute
care vor fi p ăstrate în document ația Contractului.
În fazele de Construc ție și Înrolare se vor organiza întâlniri lunare între managerul de Contract al
Furnizorului și Directorul de Contract desemnat la nivelul Beneficiarului pentru urm ărirea avansului
proiectului în raport cu planul, m ăsuri propuse pentru remedierea unor întârzieri, modific ări de plan
etc, pentru care este necesar ă o aprobare formal ă. Hot ărârile luate în aceste întâlniri vor fi
consemnate în minute ale întâlnirilor.

146

Personalul utilizat în proiect
Furnizorul va mobiliza toate resursele pe care le consider ă necesare pentru buna execu ție a
Contractului.
Furnizorul nu va efectua modific ări ale personalului desemnat fără consultarea prealabil ă și aprobarea
Beneficiarului.
La rândul lui, Beneficiarul î și rezerv ă dreptul de a cere înlocuirea unui expert care nu se dovede ște
preg ătit conform a șteptărilor cu un altul, echivalent cu preg ătirea necesar ă poziției în proiec t.
Deoarece Furnizorul este liber s ă propun ă o solu ție alc ătuită din platforme hardware și software dup ă
cum consider ă că poate acoperi mai bine necesit ățile, singura condi ție de admitere în proiect a unui
expert va fi existen ța unor certific ări adecvate și/sau a experien ței extensiv ă în domeniu l pentru care
este propus ca expert de c ătre Furnizor – de exemplu pentru echipamente le propuse, pentru suite de
software aplicativ, ITIL, securitate etc.

Rapoarte periodice
În fiecare lun ă din timpul fazelor de Construc ție și Înrolare, Furnizorul va întocmi un Raport lunar în
care se eviden țiază activit ățile desf ășurate în perioada raportat ă, riscuri ap ărute, m ăsuri propuse
pentru limitarea/eliminarea efectelor acestora, dificult ăți în deru larea proiectului conform planului și
măsuri de corec ție.
Raportul lunar trebuie s ă fie scurt, informativ, și să cuprind ă cel puțin următoarele informa ții:
 Activit ățile realizate în perioada de raportare și rezultatele par țiale;
 Activit ăți previzionate a se realiza în perioada urm ătoare
 Problemele/dificult ățile întâmpinate ce necesit ă o decizie din partea Beneficiarului pentru a fi
rezolvate și propuneri de remediere a acestora
 Riscuri ap ărute și măsuri de minimizare/prevenire a acestora
 Rezultatele realiz ate în cursul perioadei de raportare, resursele utilizate etc
 Livrabile/ documente produse etc.
În faza de Produc ție se va face un Raport trimestrial cu aceea și structur ă, la care se vor ad ăuga
rapoartele de Mentenanță și de respectare a SLA – pe baza acestora se va face facturarea în aceast ă
perioad ă.

147
5 Garan ție, Mentenanță și suport

În cadrul activit ăților de Mentenanță și suport se vor avea în vedere:
 Suportul si garan ția echipamente lor hardware și a licen țelor software va fi oferit ă pentru
minim 5 ani de la livrare, cu dreptul utilizatorului de a putea desc ărca singur fi șiere de update
de pe site -ul produc ătorului si de a deschide nemijlocit cazuri de suport.
 Toate activit ățile preventive și corective (repara ție, instalare, (re)conf igurare și optimizare)
necesare pentru:
o Menține rea func ționării în cele mai bune condi ții a componentelor hardware sau
software asociate ale SIMS (în mod curent);
o readucerea componentei, în cel mai scurt timp posibil, înapoi în stare de func ționare
normal ă (în cazul unui defect).
 Toate opera țiunile de rutin ă care trebuie efectuate în activitatea de zi cu zi pentru
func ționarea adecvat ă a serviciilor func ționale în condi țiile cerute de Beneficiar, incluzând aici
diversele cerin țe de modificare și reconfigura re care vor ap ărea pe parcursul proiectului, și
care trebuie implementa te în cel mai scurt timp posibil
 Asigurarea serviciului de asisten ță a utilizatorilor (nivelul 1 de suport)
 Asigurarea nivelului 2 și 3 de suport aferente infrastructurii IT
 Asigurarea nivelului 3 de suport aferent componentelor aplicative (nivelul 2 este asigurat de
Beneficiar)
 Escaladarea problemelor grave la produc ători
 Asigurarea garan ției echipamente lor din teritoriu, la sediile Beneficiarului
 ITSM.

Pe durata perioadei de garan ție se vor asigura servicii permanente de rezolvare disfunc ționalit ăților și
defectelor de orice natura, f ără costuri suplimenta re pentru entitate contractanta. Astfel, Ofertantul
se obliga s ă asigure înlocuirea oric ărei componente hardware defecte cu componente noi și certificate
pentru utilizare in echipamente le livrate, sau chiar a echipamente lor cu totul (daca situa ția o impune),
prin deplasare la sediul entit ății contractante. Remedierea defec țiunilor software se va face prin
acțiuni de aplicare de corec ții software, de reconfigurare, de restaurare de date sau alte ac țiuni Menite
să restabileasc ă func ționalitatea soluției în cel mai scurt timp posibil.

5.1 Completitudinea soluției

Soluția, așa cum va fi ea furnizata de un integrator unic, trebuie s ă fie c ât mai acoperitoare pe lan țul
dintre aplica ții si utilizator (end -2-end), dincolo de elementele primare legate de solu ția aplicativ ă
propriu -zisă si componenta de infrastructura hardware si software afer enta. În acest sens, pentru a
evita diluarea responsabilit ății si disputele legate de originea diverselor probleme care pot ap ărea pe
lanțul de utilizare, solu ție este cât mai completa , incluzând componente precum:
 Comunica ția la nivelul centrelor de date (inclusiv protecție de tip anti -DDoS de nivel carrier ) –
pentru a asigura performanta globala a solu ției, f ără a se putea invoca motive legate de
disponibilitatea sau calitatea leg ăturilor de date, atât la nivelul leg ăturilor internet dar si a leg ăturii
intre cele doua centre de date
 Soluție complet ă de securitate – adecvata unei solu ții informatice de asemenea importanta si
volum de utilizare; inclusiv securizarea adecvata a terminalelor mobile incluse in proiect și SOC

148
 Terminale utilizator – măcar ca o fracție a acestora, pentru a asigura compatibilitatea cu aplica ția,
si mai ales pentru asigurarea funcționarii în scenariul deconectat
 Centru de contact pentru toata masa de utilizatori, dimensionat adecvat pentru a putea sprijini
adoptarea si func ționarea soluției la nivel na țional
 Nivel complet de guvernanta IT , pentru a asigura transparenta in func ționare, predictibilitatea,
relevanta si men tenabilitate solu ției (ITIL, administrare, monitorizare, securitate); definire f ără
echivoc a nivelului de servicii solicitat, cu penalit ăți financiare clare corelate cu dep ășirea SLA,
precum si stabilirea preci să a structurii si atribu țiilor NOS si SOC .

Integratorul fiind în pozi ția de a controla practic toate elementele serviciului IT asociat, i se va putea
impune un SLA exigent, înso țit de penaliz ările de rigoare , fără a exista riscul pas ării de responsabilitate .

5.2 Management ul serviciilor IT – ITSM (IT Service Management )

Furnizorul trebuie s ă prevad ă o solu ție integrat ă pentru Management ul opera țional al infrastructurii
și serviciilor de business.
Solu ția va trebui implementată ca un sistem integrat, permi țând ca Management ul IT să fie gestionat
într-o manier ă conform ă cu practicile ITIL v3, pentru procese cum ar fi Management ul evenimente lor,
incidentelor, configura ției și schimb ării.
Implementa rea solu ției ITIL trebuie gestionat ă de un Expert în ITIL. Expertul trebuie s ă fie capabil s ă
organizeze și să conduc ă activitatea de servicii IT, conform Caietului de sarcini, s ă aibă experien ță
releva ntă în acest sens și certific ări adecvate ITIL Expert. Furnizorul va demonstra calificarea
specialistului propus în cadrul ofertei.

5.3 Criterii de performan ță a serviciului (SLA)

Incidentele care pot ap ărea în decursul oper ării se definesc astfel:
 Critic – care are implica ții majore în activitatea Beneficiarului și afecteaz ă serios utilizatorii
 Grav – care are implica ții majore în activitatea Beneficiarului
 Mediu – care are implica ții considerabile în activitatea Beneficiarului și/sau afecteaz ă
utilizatorii
 Ușor – care are implica ții minore asupra Beneficiarului sau a utilizatorilor
 Cosmetic – care nu afecteaz ă activitatea, dar reprezint ă o neconcordan ță ce poate fi
remediat ă.
Serviciile func ționale livrate de SIMS vor fi și ele împ ărțite în patru categorii:
 Serviciu critic – esen țial derul ării activit ății, cum ar fi zona de tranzac ții SIMS sau arhiva
 Serviciu important – important în derularea activit ății, cum ar fi zona de administrare și
înrolare
 Serviciu mediu – poate fi întrerupt pe termen scurt f ără a afecta semnificativ activitatea, cum
ar fi portalul public sau analiza avansat ă și vizualizarea de date
 Serviciu auxiliar – serviciu de mic ă importan ță pentru sistem, cum ar fi Anuarul sau Anun țuri
și nout ăți.
Se vor analiza în comun și apoi Beneficiarul va decide asupra unui set de metrici asociate serviciilor
prestate de Furnizor, metrici care vor fi utilizate în evaluarea calit ății serviciilor prestate. Aceste metrici

149
vor fi complet definite în faza ini țială a perioadei de Transformare, în cadrul rafin ării detaliilor legate
de procesele ITIL ce vor fi implementa te și vor face parte din rapoartele care trebuie s ă fie generate
de aceste procese.
În mod esen țial acestea vor ține seama de un model de punctaj de penalizare în raport cu înc ălcarea
nivelului de s ervicii a șteptat (SLA), punctaj care se va executa din garan ția de bun ă execu ție sau se va
deduce din valoarea facturilor lunare/trimestriale de asigurare a func ționării SIMS .
Punctajul se va aplica începând cu data intr ării acestuia în produc ție (Acceptan ță parțială) –
penaliz ările acumulate se vor recupera din pl ățile ulterioare, incluzând aici prima plat ă. Punctajul va
ține seama de severitatea incidentelor și de frecven ța acestora, incluzând și posibilitatea ca Furnizorul
să recupereze problemele minore (prin puncte negative și pozitive) – acumularea unui punctaj pozitiv
nu va conduce la o plat ă crescut ă, iar punctajul pozitiv nu se va reporta pe urm ătoarea perioad ă (se
va începe de la zero fiecare semestru în parte). Un punct de penalizare va fi echival ent cu 0.05% din
valoarea contractului. În calculul penalit ăților se vor respecta urm ătoarele principii:
 Un defect individual va fi penalizat o singur ă dată, alegându -se consecin ța cu maxim de puncte
de penalizare (nu se va multiplica pe mai mute elemente de penalizare și nu se va num ăra pe
fiecare component ă func țional ă afectat ă în parte);
 suma penalit ăților la un moment dat se va limita la 10 % din valoarea garanției , din care
acestea vor putea fi revendicate semestrial de către Beneficiar ;
 num ărul de pu ncte de penalizare pe zi va fi plafonat la 10 (zece);
 un incident nerezolvat în cadrul SLA va fi penalizat din nou o singur ă dată în fiecare zi în care
acesta se Menține ;
 incidentele deschise de Beneficiar vor fi declarate rezolvate de c ătre acesta – ele p ot fi închise
de c ătre Furnizor, dar Beneficiarul poate redeschide incidentul: în aceste cazuri SLA va fi
considerat de la data ini țială și nu se va reseta timpul.
Furnizorul va fi principalul responsabil în analiza defectelor și a problemelor de performan ță ale
soluției, utilizând instrument ele de monitorizare și gestiune evenimente care fac parte din solu ție.
Tabelele de mai jos con țin principalele elemente care vor fi luate în considerare la definirea modelului
de punctaj:
Timpi maximi* (în ore):

* exclusiv timpul necesar restaur ării de date din backup , dac ă e cazul
** restaurarea serviciilor c ăzute trebuie f ăcută chiar f ără a fi ridicat ă o sesizare de c ătre Beneficiar,
prin autosesizare de c ătre Furnizor – acesta are obliga ția de a monitoriza în permanen ță starea
serviciilor func ționale.
Nivel al serviciului func țional Critic Important Mediu Auxiliar
Răspuns la sesizarea unui incident 0.5 1 1 4
Rezolvarea unui incident/sesiz ări: Critic 4 4 6 8
Grav 8 8 12 24
Mediu 12 24 24 48
Ușor 24 48 48 72
Cosmetic 96 96 – –
Restaurare** a unui serviciu afectat din cauze
neimputabile Furnizorului * 6 12 24 48

150
Puncte de penalizare:
Nivel al serviciului func țional Critic Impor –
tant Mediu Auxi –
liar
Depășire timp de r ăspuns la sesizarea unui incident 1 0.5 0.25 0.25
Depășire timp de rezolvare a unui incident/sesiz ări: 1 0.75 0.5 0.25
Depășire timp de restaurare a unui serviciu 1 0.75 0.5 0.25
Depășirea nivelului acc eptat de înalt ă disponibilitate Între 5 -10% 0.25 0.125 – –
Între 10 -25% 0.5 0.25 0.125 –
Peste 25% 1 0.75 0.5 0.25
Depășirea ni velului acceptat de performan ță Între 10 -25% 0.25 0.125 – –
Între 25 -50% 0.5 0.25 0.125 –
Peste 50% 1 0.75 0.5 0.25
Defecte repetate la aceea și categorie de echipament
central în dec ursul a 15 zile consecutive* 3 sau 4 defecte 0.5
mai mult de 4
defecte 2
Defectarea / nefunc ționarea unei componente datorit ă Mentenanței
neglijente (lipsa ac țiunilor pro -active asociate componentei) 0.5
Pierdere sau corupere de date din motive legate de infrastructur ă 2 2 1 1
Nerealizarea copiilor de siguran ță conform politicii de backup, sau
imposibilitatea utiliz ării acestora (restaur ării de date) din motive imputabile
serviciului 2
Nefunc ționarea mecanismului de comutare în celălalt centru de date în caz
de defect real 1 0.75 0.5 0.25
Furnizarea rapoartelor de monitorizare și ITSM cu întârziere mai mare de 2
zile lucr ătoare 0.5
Manipularea / alterarea datelor de monitorizare sau ITSM, ori furnizarea
rapoartelor de monitorizare și ITSM cu date esen țiale lips ă sau inco erente 2
Asigurarea nivelului de performan ță global timp de 15 zile succesive -0.75
Asigurarea nivelului de disponibilitate global timp de 30 de zile succesive -0.75

* Nu se va lucra cu perioade predefinite, ci cu intervale oarecare alese arbitrar astfel încât s ă cuprind ă
un maxim de defecte: Se va considera orice perioad ă de 15 zile calendaristice posibil ă, atât timp cât
defectele respective nu au fost deja incluse într -o alt ă penalizare (de exemplu, dac ă un defect apare p e
26 mai și altul pe 3 iunie, se va lua în considerare o perioad ă oarecare care acoper ă cele dou ă
evenimente , nu perioade artificial delimitate spre exemplu de început sau sfâr șit de lun ă). Prin defect
repetat se în țelege mai multe defecte, chiar dac ă de n atur ă divers ă, care au necesitat repara ții sau
înlocuiri de piese/subansamble/componente hardware .

5.3.1 Niveluri acceptate de disponibilitate

Perioadă maximă de întrerupere (în ore/lun ă) per centru de date :

151
* Exceptând perioadele de întrerupere planificat ă și, dac ă e cazul timpul necesar restaur ării bazelor de
date din arhive backup

5.3.2 Niveluri acceptate de performan ță

Barem de Testare formal ă de performan ță:
(se execut ă la acceptan ța solu ției și ulterior odat ă in fiecare an, pe ambele centre de date, cu solu ția
de replicare activ ă, de c ătre o ter ță parte )
Timp de r ăspuns maxim pentru un mix de opera țiuni SIMS normale efectuate prin browser web
(măsurat în vLAN -ul serverului web) la o înc ărcare sus ținută de 3000 de tranzac ții noi pe secund ă per
centru de date : 99% din tranzac ții se finalizeaz ă cu succes sub 2 sec.
Timp de r ăspuns maxim pentru un mix de opera țiuni SIMS normale efectuate prin API restfull (m ăsurat
în vLAN -ul API -ului) la o înc ărcare sus ținută de 3000 de tranzac ții noi pe secund ă per centru de date :
99% din tranzac ții se finalizeaz ă cu succes sub 2 sec.

Barem de Timp de r ăspuns la utilizator :
(se monitorizeaz ă continuu în produc ție)
Se va avea în vedere un timp de r ăspuns la utilizator sub 3 secunde pentru 95% din opera țiuni,
considerând un mix de opera țiuni SIMS normale efectuate prin browser web și API, in condi țiile reale
de produc ție, pentru o înc ărcare de sub 2000 de tranzac ții pe secund ă.
Baremul de Timp de r ăspuns la utilizator poate fi modificat de comun acord cu Beneficiarul, dac ă
condi țiile de lucru vor ar ăta că este indicat.
Solu ția software pentru m ăsurarea tipului de r ăspuns în produc ție va fi pus ă la dispozi ție de Fur nizor.

5.4 Serviciul de asisten ță a utilizatorilor

Nivelul 1 de suport si asisten ță pentru utilizatori trebuie asigurat de c ătre Furnizor, într -un cadru bine
definit.
Se va asigura asisten ță offline și online, inclusiv telefonic ă, pentru to ți profesorii și ceilal ți angaja ți ai
Beneficiarului care utilizeaz ă SIMS.
Se va asigura asisten ță offline (email, fax, self -service, mesagerie intern ă asincron ă) pentru ceilal ți
participan ți cu identitate definit ă în sistem (elevi, p ărinți etc.).
Nivel al serviciului func țional Critic Important Mediu Auxiliar
Maxim întrerupere (ore/lun ă) * 2 4 8 12

152
6 Prezentarea ofertei

Cerințele caietului de sarcini sunt minimale – ofertele trebuie s ă includ ă explicit toate componentele
evident necesare func ționării solu ției a șa cum se cere, chiar dac ă acestea nu sunt cerute în mod
explicit. Similar, parametrii și cantit ățile solicitate sunt și ele minimale, și trebuie explicit majorate dac ă
ele nu sunt suficiente func ționării în parametrii solicita ți.
Oferta trebuie s ă includ ă liste de livrabile clare și complete:
 Listă de livrabile software, cuprinzând toate produsele sof tware necesare solu ției, cu
denumirile de produse de la produc ătorul acestora (inclusiv suport etc.) , specificând în clar
cantit ățile ofertate și metrica asociat ă, conform politicii publi ce de licen țiere a produc ătorului
– se interzice în mod explicit ofer tarea de licen țiere tip „pachet” sau „bundle”, cu excep ția
prezent ării unei scrisori de la produc ător prin care acesta î și asum ă integral solu ția de
licen țiere pe acest proiect
 Listă de livrabile hardware, inclusiv cantit ăți de componente și subansamble. S e vor eviden ția
explicit op țiunile software și servicii de suport de la produc ător asociate. Se vor include
configura țiile echipamente lor, care s ă eviden țieze subansamblele relevante la nivel de part –
number de produc ător, cu cantit ățile aferente.
Oferta trebuie s ă includ ă diagrame detaliate per centru de date și global:
 Arhitectur ă software (nivelul aplicativ și func țional)
 Arhitectur ă a solu ției (nivelul logic și de integrare a componentelor)
 Arhitectur ă fizică detaliată la nivel de echipament (inclusiv de re țea)
 Arhitectur ă de deployment (inclusiv localizarea componentelor pe ma șini fizice și detaliile de
alocare resurse fizice – RAM & CPU – per comp onente)
 Alte detalii
o Lista tuturor ma șinilor virtuale care se vor crea (inclusiv specificare OS, SW specia lizat
instalat local și necesare de resurse vCPU și RAM).
o Calcul detaliat de spa țiu fizic ocupat, putere electric ă consumat ă și necesar de r ăcire
o Justificarea teoretic ă a performan ței sistemului rezultat pe diversele sale
componente
Oferta trebuie s ă inclu dă o matrice de conformitate în care s ă se reg ăseasc ă, pentru fiecare cerin ță
din caietul de sarcini, un r ăspuns la obiect, clar și relevant. Răspunsul trebuie s ă explice modul în care
cerin ța este efectiv implementată – nu se vor lua în considerare r ăspunsuri care se rezum ă la a copia
cerin ța, eventual cu o minim ă reformulare. Toate referin țele la document ația tehnic ă trebuie f ăcute
specificând anexa referit ă, capitolul, pagina și paragraful – ne se vor lua în considerare referin țele la
documente între gi sau pagini web (toat ă document ația relevant ă trebuie livrat ă ca anex ă la ofert ă, în
format electronic ; se acceptă referințe la document așie tehnică în limba engleză, dar în acest caz, pe
lângă referință, răspunsul din matricea de conformitate trebuie să includă un rezumat concis în limba
română ).