1. SE APROBĂ,
Director UEFISCSU
Adrian CURAJ
Experți IT Expert Achiziții publice Juridic
Ilie TAMAȘ Anca MUSTAȚĂ Dodi DUMITRU
Marius NICOLĂESCU
Cristina MOISE
DOCUMENTAŢIE PENTRU ATRIBUIREA CONTRACTULUI
ACHIZIŢIA PUBLICĂ DE SERVICII DE DEZVOLTARE A UNUI
SISTEM INFORMATIC INTEGRAT (APLICAȚIE INFORMATICĂ)
PENTRU SISTEMUL NAŢIONAL DE GESTIUNE A
PARTICIPANŢILOR ÎN SISTEMUL DE ÎNVĂŢĂMÂNT
SUPERIOR
(denumit REGISTRUL MATRICOL UNIC – RMU)
Iulie 2009
Pag. 1/84
2. FIŞA DE DATE A ACHIZIŢIEI
I. a. AUTORITATEA CONTRACTANTĂ
Denumire: Unitatea Executivă pentru Finanţarea Învăţământului Superior şi a
Cercetării Ştiinţifice Universitare
Adresa: Str. Schitu Măgureanu, Nr.1, Et.3, Sector 5, Localitatea: Bucureşti, Cod
poştal: 050025, România
Localitate: Bucureşti Cod poştal: Ţara: România
050025
Persoana de contact: Anca Mustaţă Telefon: 021/307.19.41
E-mail: anca.mustata@uefiscsu.ro Fax: 021/307.19.29
Adresa Autorităţii contractante: http://www.uefiscsu.ro
I.b Principala activitate a Autorităţii contractante: educaţie
Autoritatea contractantă nu achiziţionează în numele altei autorităţi contractante.
Alte informaţii şi/sau clarificări pot fi obţinute de la :
Unitatea Executivă pentru Finanţarea Învăţământului Superior şi a Cercetării Ştiinţifice
Universitare, Str. Schitu Măgureanu, Nr.1, Et.3, Sector 5, Cod poştal 050025, Bucureşti,
tel.: 021/307.19.41, fax: 012/307.19.29.
Data limită de primire a solicitărilor de clarificări: 09.09.2009, ora 12.00.
Adresa: Unitatea Executivă pentru Finanţarea Învăţământului Superior şi a Cercetării
Ştiinţifice Universitare, Str. Schitu Măgureanu, Nr.1, Et.3, Sector 5, Cod poştal 050025,
Bucureşti, tel.: 021/307.19.41, fax: 012/307.19.29, email: anca.mustata@uefiscsu.ro.
Data limită de transmitere a răspunsului la clarificări : 10.09.2009, ora 12.00
Modul de utilizare a căilor de atac:
Organismul competent de rezolvare a contestaţiilor: Pentru soluţionarea contestaţiilor,
partea care se consideră vătămată se poate adresa Consiliului Naţional de
Soluţionare a Contestaţiilor care funcţionează pe lângă Autoritatea Naţională pentru
Reglementarea şi Monitorizarea Achiziţiilor Publice, localizat în str. Stavropoleos nr. 6,
sectorul 3, Cod Postal 030084, Bucureşti, România - Certificat de Înregistrare Fiscală
(CIF): 20329980 Tel.:(+4) 021 310.46.41 Fax: (+4) 021 - 310.46.42, E-mail:
office@cnsc.ro.
Modul de constituire a contestaţiei
Contestaţia se formulează în scris şi trebuie să conţină informaţiile precizate în art. 270
alin. (1) din OUG 34/2006. Contestatorul va ataşa la contestaţie şi copia actului atacat,
în cazul în care acesta a fost emis, precum şi copii ale înscrisurilor prevăzute la art. 270
alin. (1) din OUG 34/2006, dacă acestea sunt disponibile.
Termenul de depunere a contestaţiei
Contestaţia poate fi depusă în cel mult 10 zile de la data luării la cunoştinţă de către
contestatar despre un act al autorităţii contractante pe care acesta îl consideră nelegal.
Pag. 2/84
3. În cazul în care documentaţia de atribuire este publicată în SEAP în condiţiile prevăzute
la art. 75 alin. (5) din OUG 34/2006, data luării la cunoştinţă se consideră a fi data
publicării documentaţiei de atribuire.
După înaintarea contestaţiei către Consiliu, contestatarul va înainta de îndată autorităţii
contractante o copie a contestaţiei şi a înscrisurilor contestate, dacă acestea sunt
disponibile.
I.c. Sursa de finanţare:
Proiect finanţat de Uniunea Europeană prin Fondul Social European, Programul
Operaţional Sectorial pentru Dezvoltarea Resurselor Umane 2007 – 2013, Axa
prioritară 1 „Educaţia şi formarea profesională în sprijinul creşterii economice şi
dezvoltării societăţii bazate pe cunoaştere”, Domeniul Major de Intervenţie 1.2 „Calitate
în învăţământul superior”.
II OBIECTUL CONTRACTULUI
II.1) Descriere
II.1.1) Denumire contract: Dezvoltarea unui sistem informatic integrat
(aplicație informatică) pentru sistemul naţional de gestiune a
participanţilor în sistemul de învăţământ superior – Registrul Matricol
Unic (RMU)
II. 1.2) Denumire contract şi locul prestării:
- Contract de prestare de servicii.
- Sediul central şi sediile universităţilor din Sistemul de Învăţământ Superior din
România.
- Achiziţionarea se va realiza prin cumpărare.
- Cod CPV: 72230000-6 – servicii de dezvoltare software personalizat.
- Cod CPV: 48611000-4 – pachete software pentru baze de date.
II. 1.3) Procedura se finalizează prin: contract de achiziţie publică
II. 1.4) Durata contractului de achiziţie publică: 15 luni de la data atribuirii
(semnării contractului de către părţi), dar nu mai târziu de data de 15.12.2010.
II. 1.5) Nu se acceptă oferte alternative.
II. 1.6) Se vor depune oferte pentru întreaga cantitate de servicii solicitate. Nu
se acceptă oferte parţiale.
II.2) Cantitatea sau scopul contractului
II.2.1) Obiectul serviciilor îl reprezintă achiziţia publică de servicii de dezvoltare aplicație
software privind Dezvoltarea unui sistem informatic integrat pentru sistemul naţional de
gestiune a participanţilor în sistemul de învăţământ superior – Registrul Matricol Unic
(RMU).
Pag. 3/84
4. Scopul contractului este detaliat în caietul de sarcini inclus în prezenta documentație de
atribuire.
DENUMIRE COD CPV
Servicii de dezvoltare
72230000-6
software personalizat
Pachete software pentru baze
48611000-4
de date
II.2.2) Autoritatea contractantă, la momentul finalizării contractului de prestări servicii,
are dreptul de a opta pentru prelungirea contractului prin achiziţionarea de noi servicii
similare de la operatorul economic a cărui ofertă va fi declarată câştigătoare în cadrul
acestei proceduri.
Valoarea estimată a acestor servicii similare nu va putea depăşi 20% din valoarea
contractului, iar valoarea contractului acordat ca urmare a acestei proceduri este de
4 000 000 lei.
II.3) CONDIŢII SPECIFICE CONTRACTULUI
II.3.1) Alte condiţii particulare referitoare la contractele subsecvente acordului - cadru
(după caz): nu este cazul.
II.3.1.a) Contractele de prestări de servicii NU sunt rezervate.
II.3.1.b) Alte condiţii: NU
II.3.2) Garanţie de participare: DA
III PROCEDURA
III.1) Procedura selectată: licitaţie deschisă.
III.2) Etapa finală de licitaţie electronică: Nu.
III.3) Condiţii de licitaţie electronică: Nu este cazul
III.4.) Legislaţia aplicată
1. Ordonanţa de urgenţă a Guvernului nr. 34/2006 privind achiziţiile publice, publicată
în Monitorul Oficial al României, Partea I, nr. 418 din 15.05.2006, aprobată, cu
modificări şi completări ulterioare, prin Legea nr. 337/2006, publicată în Monitorul
Oficial al României, Partea I, nr. 625 din 20.07.2006, Legea nr. 128/2007, O.U.G. nr.
94/2007 publicată în MOF nr. 676 din 04/10/2007, Decizia Curţii Constituţionale nr.
569/2008 publicată în MOF nr. 537 din 16/07/2008, O.U.G. nr. 143/2008 publicată în
MOF nr. 805 din 02/12/2008, O.U.G. nr. 228/2008 publicată în MOF nr. 3 din
05/01/2009, O.U.G. nr. 19/2009 publicată în MOF nr. 156 din 12/03/2009, O.U.G. nr.
72/2009 publicată în MOF nr. 426 din 23/06/2009.
2. Hotărârea Guvernului nr. 925/2006 privind aprobarea normelor de aplicare a
Ordonanţei de urgenţă a Guvernului nr. 34/2006 privind achiziţiile publice, publicată
în Monitorul Oficial al României, Partea I, nr. 625 din 20.07.2006, cu modificările şi
completările ulterioare, prin Hotărârea nr. 1337/2006, publicată în Monitorul Oficial
al României, Partea I, nr. 817 din 04.10.2006.
IV. CRITERII DE CALIFICARE ŞI SELECŢIE
Pag. 4/84
5. IV.1) Situaţia personală a ofertantului
1. Declaraţie privind eligibilitatea Cerinţă obligatorie: completarea formularului 12A din
capitolul de Formulare.
2.Declaraţie privind neîncadrarea Cerinţă obligatorie: completarea formularului 12B din
în situaţiile prevăzute de articolul capitolul de Formulare.
181 din OUG 34/2006.
IV.2) Capacitatea de exercitare a activităţii profesionale (înregistrare)
Persoane juridice / fizice române Cerinţe obligatorii:
a) Certificat constatator emis de Oficiul Registrului
Comerţului, care să ateste faptul că nu este în stare
de faliment sau lichidare şi din care să reiasă
obiectul de activitate, valabil la data deschiderii
ofertelor (copie conform cu originalul);
b) Certificat de înregistrare emis de Oficiul
Registrului Comerţului (copie conform cu
originalul);
c) Pentru persoanele fizice române - autorizare de
funcţionare sau orice alte documente justificative din
care să rezulte că are capacitate de exercitare a
activităţii (original sau copie legalizată);
Persoane juridice / fizice străine Cerinţe obligatorii: Documente edificatoare care să
dovedească o formă de înregistrare ca persoană
juridică sau de înregistrare / atestare ori apartenenţă
din punct de vedere profesional, în conformitate cu
prevederile legale din ţara în care ofertantul este
rezident (traducere legalizată).
IV. 3.) Situaţia economico-financiară
1. Bilanţ contabil Cerinţă obligatorie: Prezentarea Bilanţurilor
Contabile pe ultimii trei ani (2006, 2007, 2008), vizate
şi înregistrate de organele competente (copie
ştampilată, semnată şi cu menţiunea „conform cu
originalul” pe fiecare pagină).
2.Informaţii privind cifra de Cerinţă obligatorie: Declaraţii prin care ofertantul va
afaceri demonstra realizarea unei cifre medii anuale de
afaceri globală, pe ultimii trei ani de 1.800.000
EURO. (Formularul 1 din capitolul de Formulare).
IV. 4.) Capacitatea tehnică
1.Experienţă similară Cerinţe minime:
Ofertantul (sau membrii asociaţiei, cumulaţi) trebuie
să fi dezvoltat în ultimii trei ani cel puţin două sisteme
informatice similare, cu peste 500 de utilizatori, cu
acoperire similară, pe tehnologie şi arhitectură
asemănătoare cu cele propuse;
Pag. 5/84
6. Ofertantul va depune, în sprijinul afirmaţiilor, copii ale
părţilor relevante din contract şi recomandări
semnate şi parafate de către beneficiar. Pentru a
asigura integritatea şi calitatea ofertelor, nu sunt
acceptate ca documente suport contracte nefinalizate
la data deschiderii ofertei.
2.Lista principalelor contracte de O listă a principalelor prestări de servicii similare în
prestare de servicii similare în ultimii 3 ani conţinând valori, perioade de prestare,
ultimii 3 ani beneficiari (indiferent dacă sunt autorităţi contractante
de stat sau clienţi privaţi) (Formularul 12D din
capitolul de Formulare).
3.Informaţii privind personalul Cerinţe privind personalul propriu:
tehnic de specialitate şi de Cerinţa minimală a autorităţii contractante este ca
asigurarea calităţii numărul de angajaţi ai ofertantului (individual sau în
asociere), alocaţi proiectului, să fie de cel puţin 25,
dintre care următorii experţi cu studii superioare
finalizate:
Project Manager:
Minim 10 ani experienţă în domeniul IT&C,
(design, implementare şi exploatare sisteme
informatice integrate);
Minim 3 ani experienţă coordonare echipe
consultanţi în proiecte de complexitate similară
Minim 3 proiecte conduse – de valoare cel
puţin egală cu cea a proiectului supus
prezentei proceduri de achiziţie;
Certificări relevante pe management de
proiecte; de exemplu, certificare de tip Project
Management Professional (PMP) emisă de
către PMI sau echivalent;
Competenţe relevante: minim o recomandare
emisă de către un client pentru un proiect
desfăşurat în cadrul unei autorităţi publice
precizând rezultatele practice obţinute.
Expert baze de date:
Minim 5 ani experienţă profesională pe
domeniul de expertiză;
Participare în cel puţin 3 proiecte similare;
Certificări relevante: DBA pentru tehnologie
propusă.
Pag. 6/84
7. Minim doi experţi dezvoltare software:
Minim 7 ani experienţă dezvoltare software;
Participare în cel puţin 3 proiecte similare.
Expert Tehnologia Comunicaţiilor
Minim 10 ani experienţă profesională pe
domeniul de expertiză;
Studii superioare de electronică şi
telecomunicaţii;
Participare la cel puţin 2 proiect de anvergură
similară care implică tehnologia de
comunicaţii.
Experţi Sisteme informaţionale, de management
şi de securitate (condiţiile pot fi îndeplinite
cumulativ de mai multe persoane)
Minim 10 ani experienţă în domeniul IT&C;
Minim 3 proiecte care au presupus elaborarea
de studii IT&C;
Minim 3 proiecte care au presupus evaluarea
infrastructurilor IT&C;
Competențe în managementul sistemelor de
securitate: Certificare CISM (Certified
Information Security Manager) emisă de către
ISACA (Information Systems Audit and Control
Association) sau echivalent;
Competenţe în managementul sistemelor
informatice la scară largă: certificare CGEIT
(Corporate Governance for Enterprise IT)
emisă de către ISACA sau echivalent;
Competențe în auditul sistemelor
informaţionale: certificare CISA (Certified
Information Systems Auditor) emisă de către
ISACA sau echivalent;
Competenţe relevante: minim o recomandare
emisă de către un client pentru un proiect
finalizat care a implicat evaluarea situaţiei
curente şi elaborarea unui studiu privind
soluţiile de îmbunătăţire.
Expert Securitate informatică aplicată
Minim 3 ani experienţă în domeniul IT&C;
Pag. 7/84
8. Competențe în managementul securităţii
informatice aplicate; de exemplu, certificare de
tip LPT (Licensed penetration tester) sau
echivalent;
Competenţe relevante: minim o recomandare
emisă de către un client pentru un proiect
finalizat care a presupus testarea securităţii
prin intermediul testelor de penetrare.
Auditor Sisteme Informaţionale
Minim 3 ani experienţă în domeniu;
Competente în auditul sistemelor
informaţionale;
Certificare CISA sau echivalent;
Prezentarea a minim 3 recomandări pentru
proiecte în domeniul auditului sistemelor
informatice.
În cazul depunerii unei oferte comune, aceşti experţi
pot să fie angajaţi ai oricărui membru al asocierii.
Pentru fiecare dintre experţii propuşi, ofertantul va
prezenta un CV conform Formularului 2E din capitolul
de Formulare, recomandări semnate şi parafate de
către beneficiari, copii după diplomele de certificare
profesională şi documente care să ateste calitatea de
angajat al ofertantului. Un expert poate fi propus
pentru o singură poziţie din cele obligatorii.
Ofertantul va completa Formularul 2D (original) din
capitolul de Formulare.
Pentru a face dovada alocării a cel puţin 25 de
persoane, inclusiv respectarea cerinţei minime,
ofertantul va da o declaraţie pe proprie răspundere
conform formularului 2D (original) din capitolul de
Formulare.
Ofertantul va asigura comunicare la toate nivelurile
(scris şi vorbit) în limba română, cu toate persoanele
implicate în implementarea proiectului.
4.Certificate Dovada certificării ISO 9001 sau ISO 9002 pentru
sistemul de management al asigurării calităţii sau
echivalent.
Dovada certificării ISO 27001 pentru sistemul de
management al securității informaționale sau
echivalent.
5. Informaţii privind • Declaraţiile privind partea/părţile din contract care
Pag. 8/84
9. subcontractanţii sunt îndeplinite de subcontractanţi şi modul în care
specializarea acestora acoperă partea
subcontractată.
Formularul 2B (original) din capitolul de
Formulare, completat de către contractant și de toți
subcontractanții care participă la îndeplinirea
contractului.
•Lista cuprinzând subcontractanții, conform
Formularului 12G din capitolul de Formulare - original
•Declaratie privind calitatea de participant la
pocedura conform Formularului 12C din capitolul de
Formulare - original
•Descrierea modului în care contractantul principal va
monitoriza și conduce subcontractanții pentru a
asigura realizarea în timpul stabilit a activităților
subcontractate.
•Declarație privind neîncadrarea în situațiile
prevăzute la art. 181 din Ordonanța de urgență a
Guvernului nr.34/2006, conform Formularului 12B din
capitolul de Formulare – original pentru fiecare
subcontractant
•Declarație pe propria răspundere. Completată în
conformitate cu Formularul 12A din capitolul de
Formulare – original pentru fiecare subcontractant.
V. ELABORAREA OFERTEI
V. 1) Limba de redactare a ofertei: limba română. De asemenea, orice
corespondenţă şi documente legate de procedura de atribuire transmise între ofertant şi
Autoritatea Contractantă trebuie să fie în limba română. Documentele emise în altă
limbă vor fi însoţite de traducerea autorizată şi legalizată în limba română.
V. 2) Perioada de valabilitate a ofertei: 120 zile
V. 3) Cuantumul garanţiei de participare: 40 000 lei .
V. 4) Perioada de valabilitate a garanţiei pentru participare: 120 zile
V. 5) Modul de constituire a garanţiei de participare
Scrisoare de garanţie bancară în original în favoarea autorităţii contractante – Unitatea
Executivă pentru Finanţarea Învăţământului Superior şi a Cercetării Ştiinţifice
Universitare. Se va utiliza obligatoriu modelul indicat în Formularul 11 din anexa 1.
Scrisorile de garanţie bancară vor fi eliberate de o bancă din România, care nu se află
în stare de faliment sau reorganizare sau o banca din strainatate cu corespondent in
Romania, care indeplineste conditiile precizate.
V.6) Modul de prezentare a propunerii tehnice
Oferta tehnică va conţine:
a) Descrierea serviciilor ofertate.
Pag. 9/84
10. b) Activităţile şi sarcinile concrete care vor fi încredinţate personalului implicat în
îndeplinirea contractului.
Ofertantul are obligaţia de a prezenta propunerea tehnică astfel încât să se asigure
posibilitatea verificării corespondenţei acesteia cu cu cele prevăzute în Caietul de
sarcini; astfel, Propunerea tehnică va conţine comentarii, articol cu articol, al
specificaţiilor tehnice conţinute în Caietul de sarcini, prin care să se demonstreze
această corespondenţă.
Ofertanţii care participă la procedura de atribuire înteleg să ofere numai servicii care să
îndeplinească condiţiile tehnice minime specificate în caietul de sarcini.
Toate solicitările precizate anterior vor fi prezentate conform detaliilor incluse în caietul
de sarcini constituie subiect al evaluării conform grilei prezentate în capitolul VI al fişei
de date a achiziţiei.
V.7) Modul de prezentare a propunerii financiare
Propunerea financiară se întocmeşte conform Formularului 10A şi a sumarului ofertei
financiare, anexă la Formularul 10A, din capitolul de Formulare, în original. Preţul
ofertat se va exprima în LEI.
Nu este acceptată ofertă alternativă.
V.8.) Data pentru care se determină echivalenţa leu/euro
Curs de referinţă comunicat de BNR în ziua 04.09.2009, ora 16.00.
V.9) Prezentarea ofertei
a) Adresa la care se depune oferta:
Unitatea Executivă pentru Finanţarea Învăţământului Superior şi a Cercetării Ştiinţifice
Universitare, Str. Schitu Măgureanu, Nr.1, Et.3, Secretariat, Sector 5, Cod poştal
050025, Bucureşti, tel.: 021/307.19.23, fax: 012/307.19.29.
b) Data limită pentru depunerea ofertei: 16.09.2009, orele 11.00.
c) Numărul de exemplare în copie: trei
d) Mod de prezentare
Scrisoarea de garanţie bancară de participare în favoarea autorităţii contractante,
în original, se va depune în plic închis separat, odată cu celelalte documente ale
ofertei.
Fiecare pagină a ofertei trebuie să fie numerotată şi semnată, de către ofertant,
care are obligaţia de a anexa şi un opis al documentelor prezentate.
Documentele originale, care nu pot fi depuse în oferta “ORIGINAL”, vor fi
prezentate în copie, semnate şi ştampilate în original de către conducătorul
societăţii ofertante. Originalele acestor documente vor fi prezentate, pentru
confruntare, în timpul şedinţei de deschidere.
Documentele originale care alcătuiesc Propunerea tehnică şi Propunerea
financiară, marcate corespunzător, se vor introduce într-un plic interior plicului
marcat „ORIGINAL”, marcat „PROPUNERE TEHNICĂ ŞI FINANCIARĂ”.
Celelalte documente care însoţesc oferta, în original, se vor introduce într-un plic
marcat “DOCUMENTE DE CALIFICARE”, interior plicului marcat „ORIGINAL”.
Pag. 10/84
11. Ofertantul trebuie să sigileze originalul şi copiile în plicuri separate, marcând
corespunzător plicurile cu „ORIGINAL” şi, respectiv, „COPIE”;
Pe plicul marcat “ORIGINAL” şi pe plicurile marcate „COPIE” se va scrie
denumirea şi adresa ofertantului, pentru a permite returnarea ofertei, fără a fi
deschisă, în cazul în care oferta respectivă este declarată întârziată.
Plicurile interioare se vor introduce într-un PLIC EXTERIOR care va fi închis
corespunzător şi netransparent. Plicul exterior trebuie să fie marcat cu adresa
Autorităţii contractante şi cu inscripţia “A NU SE DESCHIDE ÎNAINTE DE DATA :
16.09.2009; orele 12.00.
PLIC “ORIGINAL” PLIC “COPIE” (3 buc)
Propunerea tehnică Propunerea tehnică
Propunerea financiară Propunerea financiară
Celelalte documente care
Celelalte documente care însoţesc oferta
însoţesc oferta
marcat cu numele şi adresa marcat cu numele şi adresa
ofertantului ofertantului
PLIC EXTERIOR – marcat cu adresa autorităţii contractante şi cu menţiunea:
“A NU SE DESCHIDE ÎNAINTE DE DATA :” 16.09.2009; orele 12.00”
e) Modificarea si retragerea ofertei
O ofertă poate fi retrasă şi modificată numai până la data şi ora limită de depunere a
ofertelor.
f) Oferte întârziate
Ofertele depuse la o altă adresă decât adresa anunţată sau depuse după data/ora limită
înscrisă la pct. V.9. sunt considerate oferte întârziate.
V.10) Deschiderea ofertelor
Se deschid numai ofertele pentru care s-a depus garanţia de participare.
Deschiderea ofertelor se va face de către comisia de evaluare, la data de 16.09.2009;
orele 12.00, la Unitatea Executivă pentru Finanţarea Învăţământului Superior şi a
Cercetării Ştiinţifice Universitare, Str. Schitu Măgureanu, Nr.1, Et.3, Sala de Consiliu
(camera 12), Sector 5, Cod poştal 050025, Bucureşti, tel.: 021/307.19.23, fax:
012/307.19.29.
Pag. 11/84
12. Persoanele autorizate să asiste la deschiderea ofertelor sunt: reprezentanţii autorizaţi ai
ofertanţilor, care vor prezenta documente de identificare şi împuternicire semnată de
persoana autorizată să semneze oferta.
VI. CRITERII DE ATRIBUIRE
VI.1. Criteriul aplicat pentru atribuirea contractului de achiziţie publică: oferta cea
mai avantajoasă din punct de vedere economic.
Punctajul acordat pentru fiecare ofertă se calculează pe baza formulei:
Ptotal = Pfinanciar x 30% + Ptehnic x 70%
1. Punctajul financiar, Pfinanciar, se acordă astfel :
a) Pentru cel mai scăzut dintre preţurile ofertate se acordă 100 de puncte;
b) Pentru alt preţ decât cel prevăzut la litera a) se acordă punctaj astfel:
Pfinanciar = (Pmin / Pev) x 100
unde Pmin şi Pev reprezintă:
Pmin = cel mai mic preţ din ofertele prezentate;
Pev = preţul ofertei pentru care se face evaluarea
Preţurile care se compară în scopul întocmirii clasamentului sunt cele ofertate pentru
prestarea integrală a serviciilor, exclusiv TVA. Se va lua în calcul valoarea ofertată
pentru întreaga cantitate de servicii solicitate.
2. Punctajul tehnic, Ptehnic, se acordă de către comisia de evaluare pe baza
aprecierii obiective efectuate de către membrii acesteia, apreciere care se raportează în
totalitate la prevederile caietului de sarcini. Pentru fiecare dintre factorii de evaluare
enumeraţi în tabelul care urmează, punctajul maxim care poate fi acordat este cel trecut
în coloana „Punctaj maxim”. Acesta se va acorda pentru oferta (ofertele) care răspunde
(raspund) cel mai bine la factorul de evaluare respectiv. Pentru celelalte oferte, se va
acorda un număr de puncte între 0 şi punctajul maxim evidențiat în tabelul de punctaj,
în funcţie de aprecierea obiectivă a nivelului satisfacerii cerinţelor de către oferta, în
raport cu oferta cea mai bună.
Ptehnic al fiecărei oferte va fi constituit din suma punctajelor obţinute de acea ofertă
pentru fiecare dintre factorii de evaluare specificaţi în tabel.
Punctaje tehnice
Factor de evaluare Punctajul maxim
1. Metodologie de management de proiect – gradul de definire şi
detaliere a metodologiei, inclusiv gradul de aplicare la specificul 10
proiectului
Pag. 12/84
13. Factor de evaluare Punctajul maxim
1. Descrierea implementarii unei metodologii de Management de
4
proiect.
2. Identificarea, descrierea şi planificarea reducerii riscurilor
3
specifice proiectului.
3. Descrierea planificării proiectului în detaliu, structura pe pachete
3
de lucru (WBS), încărcare resurse, milestone-uri etc.
2. Metodologie de asigurare şi control a calităţii pentru toate
componentele proiectului – gradul de definire şi detaliere a 10
metodologiei, inclusiv gradul de aplicare la specificul proiectului
1. Planul de asigurare a calităţii. 5
2. Descrierea interacţiunii cu echipele de proiect 5
3. Metodologie de implementare - gradul de definire şi detaliere a
10
metodologiei, inclusiv gradul de aplicare la specificul proiectului
1. Descrierea rolurilor în detaliu, a alocării experților pe categorii de
4
lucrări / servicii, în cadrul echipelor de proiect.
2. Descrierea Planului de comunicare; 3
3. Descrierea Procedurilor / Instrumentelor de lucru. 3
4. Metodologie de suport tehnic - gradul de definire și detaliere a 10
metodologiei, inclusiv gradul de aplicare la specificul proiectului
1. Descrierea în detaliu a nivelului de disponibilitate a suportului
6
tehnic, natura şi diversitatea acestuia
2. Metodologia folosită pentru susţinerea serviciilor de suport tehnic 4
5. Metodologie de dezvoltare software - gradul de definire şi
detaliere a metodologiei, inclusiv gradul de aplicare la specificul 10
proiectului
1. Definirea metodologiei şi caracteristicilor generale ale produselor
5
software
2. Definirea modulelor software, functionalităţi, interfețe etc. 5
6. Metoda de export a datelor - gradul de definire şi detaliere a
10
metodologiei de export de date
1. Definirea metodologiei aplicate în cazul exportului de date: etape,
3
acţiuni, riscuri.
2. Definirea unui exemplu de plan de export de date (activităţi,
2
responsabili, mediu de lucru, control).
3. Tratarea întreruperilor / excepţiilor în exportul de date 2
4. Planul de reluare a exportului de date (roll-back) 3
7. Planul de proiect (realizare / execuţie) 20
1. Prezentarea planului de proiect în format Gantt, pe minim 3
8
niveluri.
2. Exemplu de plan de proiect complet, orientat pe specificul
12
proiectului.
8. Descrierea conceptului (prototip) de sistem informatic propus 20
1. Detalierea obiectivelor / etapelor necesare bunei implementări 5
2. Detalierea proceselor de inițiere, comunicare, execuție, calitate și
5
control, modificare și încheiere.
3. Detalierea infrastructurii hardware necesare 3
Pag. 13/84
14. Factor de evaluare Punctajul maxim
4. Detalierea infrastructurii software necesare 3
5. Detalierea proceselor și serviciilor de implementare. 4
TOTAL GENERAL 100
VI.4. Oferta câştigătoare va fi cea mai avantajoasă din punct de vedere economic (cea
care a obţinut cea mai mare valoare a lui PTotal).
VII. ATRIBUIREA CONTRACTULUI DE ACHIZIŢIE PUBLICĂ
Atribuirea contractului se va face în corelaţie cu pct. II 1.3 ; II 1.4; II 1.5; II 1.6 din Fişa
de date a Achiziţiei.
VIII. CONDIŢII FINANCIARE IMPUSE DE CONTRACT
VIII.1. Ajustarea preţurilor (tarifelor) contractului: Preţul este ferm în LEI; nu se
acceptă ajustarea preţului.
VIII.2. Garanţia de bună execuţie a contractului :
1. În termen de maxim 3 zile de la semnarea contractului furnizorul va prezenta o
scrisoare de garanţie de bună execuţie în valoarea de 10% din valoarea contractului de
furnizare, fără TVA.
2. Modul de constituire a garanţiei de bună execuţie a contractului de prestare de
servicii este scrisoarea de garanţie bancară de bună execuţie şi constituie anexă la
contract (Formularul 5 din capitolul de Formulare, în original). Scrisoarea de garanţie
bancară va fi eliberată de o bancă din România, care nu se află în stare de faliment sau
reorganizare sau o bancă din străinatate cu corespondent în România, care
îndeplineşte condiţiile precizate.
3. Returnarea garanţiei de bună execuţie se va efectua conform H.G. 925/2006 privind
normele de aplicare a O.U.G. 34/2006.
IX. CONTRACTUL. CLAUZE CONTRACTUALE OBLIGATORII
În termen de 11 zile de la data comunicării rezultatului aplicării procedurii,
furnizorul declarat câştigător se va prezenta la sediul autorităţii contractante pentru
încheierea contractului. În caz contrar, se va executa garanţia de participare.
Clauzele contractuale sunt prezentate în modelul de contract ataşat (în capitolul de
Formulare din documentaţia de atribuire).
Neacceptarea clauzelor contractuale are drept urmare descalificarea ofertantului.
Toată documentația de atribuire în tot cuprinsul său este obligatorie, conform
prevederilor legale.
Şef Compartiment Achiziţii Publice Oficiul juridic Întocmit
Pag. 14/84
15. CAIET DE SARCINI
1. OBIECTUL LICITAŢIEI
Achiziţionarea serviciului de dezvoltare a unui sistem informatic integrat pentru sistemul naţional
de gestiune a participanţilor din Sistemul de Învăţământ Superior (SIS) – Registrul Matricol Unic
(RMU).
2. CONTRACTORUL (BENEFICIARUL)
Unitatea Executivă a Finanţării Învăţământului Superior şi a Cercetării Ştiinţifice Universitare
(UEFISCSU).
3. OFERTANTUL ŞI FURNIZORUL
Ofertantul este societatea comercială care se înscrie la prezenta licitaţie. Furnizorul este
societatea comercială care câştigă prezenta licitaţie.
4. SCOPUL SERVICIULUI LICITAT
Crearea unui sistem integrat unic la nivel naţional, privind participanţii din SIS, care va furniza în
timp real informaţii şi rezultate obiective şi credibile factorilor de decizie şi altor persoane fizice
sau instituţii interesate, în funcţie de nivelul de acces atribuit acestora. Sistemul va include şi o
componentă publică web, de tip portal, pentru furnizarea de informaţii, specifice RMU, publicului
larg şi pentru a facilita comunicarea şi colaborarea între utilizatorii sistemului.
Sistemul va cuprinde o bază de date integrată pentru gestionarea informaţiilor referitoare la
participanţii SIS.
RMU va răspunde următoarelor nevoi identificate la momentul actual:
necesitatea unui sistem unic la nivel naţional care să asigure integrarea informaţiilor
privind capitalul uman implicat în SIS şi vizibilitatea acestor informaţii, până la nivel de
date primare;
facilitarea procesului de gestiune şi de raportare în timp real a informaţiilor de la nivelul
universităţilor şi asigurarea transparenţei acestor informaţii, corelat cu utilizarea
fondurilor publice alocate;
diseminarea informaţiilor publice specifice RMU printr-o interfaţă web accesibilă oricărui
utilizator autorizat şi facilitarea comunicării între utilizatorii sistemului;
asigurarea unei imagini reale a dezvoltării capitalului uman prin învăţământ superior
(numărul de participanţi şi absolvenţi, respectiv nivelul, performanța şi domeniul de
dezvoltare).
Pag. 15/84
16. 5. DESCRIEREA GENERALĂ A SISTEMULUI RMU
RMU trebuie să fie un sistem uşor de utilizat şi sigur. El va fi un sistem software integrat, care
va permite:
colectarea datelor complete cu privire la universităţile din România şi a studenţilor
acestora;
gestionarea datelor colectate;
extragerea datelor sub formă de rapoarte şi scenarii de analiză pentru toate nivelurile
beneficiare ale sistemului;
furnizarea de informaţii publice pe web prin intermediul unei componente de tip portal;
interogarea de către instituţiile beneficiare ale sistemului şi de către sistemele
electronice naţionale de e-guvernare a serviciilor web expuse de sistem.
RMU trebuie să acopere complet nevoile de raportare şi să fie extensibil pentru adăugarea de
noi seturi de date colectate şi de noi tipuri de rapoarte.
RMU trebuie să fie securizat şi să respecte standarde înalte de securitate, accesul la sistem să
fie controlat prin solicitarea de informaţii de identificare a utilizatorilor (login). Componentele de
tip portal şi aplicaţia specifică de colectare a datelor trebuie să utilizeze acelaşi subsistem de
gestiune a utilizatorilor, astfel încât va exista un singur cont utilizator pentru accesarea ambelor
componente.
Sistemul RMU va trebui să permită înregistrarea tuturor operaţiilor executate de utilizatori şi
revenirea la datele de la un moment dat (rollback) pentru prevenirea erorilor de colectare a
datelor sau a modificărilor rău intenţionate.
Principial, sistemul trebuie să se conecteze la sistemele universităţilor, principalele furnizoare
de informații primare, să le valideze, să le stocheze, să le prelucreze şi să editeze rapoarte, cu
asigurarea deplină a securităţii şi confidenţialităţii.
Principala entitate a bazei de date a RMU o va
reprezenta PERSOANA care a intrat la un moment dat
în SIS şi a obţinut calitatea de STUDENT, cu
evidenţierea traiectoriei sale de pregătire
universitară.
Statutul PERSOANEI poate fi:
Student, la un program de licenţă, masterat sau doctorat (L,M,D), caz în care i se
asociază (activează) tot istoricul de pregătire universitară.
Absolvent.
Ieşit prematur din programul de pregătire (retras sau exmatriculat).
O PERSOANĂ poate trece, în timp, dintr-un statut în altul, sistemul RMU având capabilitatea de
a controla corectitudinea schimbării statutului.
Pag. 16/84
17. Sistemul RMU are caracter de arhivă. El memorează date cu caracter permanent despre o
persoană care a intrat la un moment dat în SIS.
În România există peste 100 de universităţi acreditate sau autorizate să funcţioneze provizoriu,
de stat sau particulare, distribuite geografic în toate judeţele ţării, având peste 800.000 studenţi.
Modul în care universităţile gestionează informaţiile despre studenţi este eterogen. Unele
universităţi au sistem informatic unic, altele au sisteme informatice diferite, la nivelul tuturor
facultăţilor care le compun, altele au sisteme informatice diferite la unele facultăţi iar la altele
evidenţa este în format clasic, altele au doar evidenţă în format clasic. De aceea, proiectantul
RMU trebuie să asigure configuraţiile de tipul celor din Figura1.
Culegere Baza de
de date Încărcare RMU
date standard
a) Structuri fără sistem informatic de evidenţă a studenţilor
Baza de Baza de
date INTERFAŢA date Încărcare RMU
standard
b) Structuri cu sistem informatic de evidenţă a studenţilor
Figura 1. - Schema de principiu a încărcării datelor în RMU
Pentru universităţile (sau facultăţile) ce deţin un sistem informatic, sistemul va facilita preluarea
acestor informaţii din sistemul local în mod automat prin intermediul unor interfeţe.
În acest moment sunt identificate peste 30 de tipuri de sisteme diferite de evidenţă a studenţilor
la universităţi.
Pentru fiecare persoană, sistemul trebuie să gestioneze
datele specificate în ANEXA 1 (secțiunea I).
Furnizorul va analiza sistemele informaţionale/informatice existente în cadrul universităţilor şi a
datelor colectate prin intermediul acestora. Rezultatul acestei analize va fi un model de date ce
va conţine toate informaţiile necesare evidenţei studenţilor în RMU. Realizarea unui document
de analiză va fi parte a sarcinilor Furnizorului şi va fi livrat către Beneficiar. În documentul de
analiză vor fi indicate modificările necesare în sistemele utilizate de către universităţi.
Pag. 17/84
18. Categoriile de utilizatori şi beneficiari ai RMU sunt:
decidenţi şi personal implicat în elaborarea politicilor în învăţământul superior,
personalul cu funcţii de conducere, monitorizare, evaluare şi control în învăţământul
superior;
personal cu funcţii de conducere din universităţi şi facultăţi;
personal administrativ din universităţi, responsabile cu gestionarea informaţiilor despre
studenţi (secretariate);
personal implicat în procesul de formare de formatori, pentru utilizarea sistemului;
studenţi ai universităţilor;
alte categorii de utilizatori, în conformitate cu drepturile de acces pe care le vor obţine de
la Beneficiar.
6. SARCINILE FURNIZORULUI
Furnizorul este responsabil de executarea la timp şi de calitate a tuturor activităţilor şi de
obţinerea rezultatelor stabilite în Caietul de Sarcini.
Furnizorul va îndeplini toate cerinţele acestui proiect, în conformitate cu şi prin implementarea
bunelor practici din domeniu.
Furnizorului i se solicită:
identificarea situaţiei actuale din SIS românesc în vederea propunerii unei modalităţi
optime pentru realizarea interfețelor de interconectare;
proiectarea de detaliu (proiectarea tehnică) a RMU, inclusiv definirea specificaţiilor de
administrare şi de utilizare;
dezvoltarea RMU şi punerea acestuia în funcţiune;
extinderea funcţionalităţilor şi accesului la RMU spre beneficiul altor instituţii private şi
publice şi a sistemelor electronice naţionale integrate;
formarea practică, informarea şi instruirea utilizatorilor RMU;
întreţinerea şi îmbunătăţirea continuă a RMU în perioada de garanţie şi postgaranţie.
Furnizorul va livra:
Sistemul complet RMU de colectare, arhivare, prelucrare şi de raportare a datelor.
Licenţele software necesare funcţionării complete a RMU, inclusiv pentru SGBD și
software-ului de bază pentru operare, comunicare și prelucrare.
Documentaţia de proiectare, administrare şi utilizare;
Proiectul complet de arhitectură hardware a echipamentelor care vor suporta
funcţionarea arhitecturii software a sistemului RMU;
Drepturile de proprietate intelectuală asupra RMU, inclusiv codurile sursă și structurile
bazelor de date.
Acţiunile suport:
cursuri pentru administratori şi utilizatori;
managementul proiectului;
asigurarea calităţii.
Pag. 18/84
19. Pentru realizarea RMU, furnizorul va asigura, în principal:
Analiza situaţiei actuale din SIS şi a cerinţelor de proiectare ale Beneficiarului.
Furnizorul va analiza structurile de date, sistemele de operare, sistemele de baze de date din
universităţi şi va propune specificaţiile preliminare de proiectare şi soluţiile de interfeţe cu
structurile standard. El va stabili, împreună cu Beneficiarul, structura bazei de date a RMU,
cerinţele de validare, protecţie, interogare, prelucrare şi stocare a datelor.
Dezvoltarea şi Implementarea RMU.
Furnizorul va asigura dezvoltarea, implementarea şi întreţinerea unui sistem cu toate funcţiile şi
componentele necesare, acesta urmând a fi utilizat ca o componentă naţională a SIS şi care va
acoperi în totalitate cerinţele exprimate în prezentul document. Întregul ciclu de viaţă a RMU,
inclusiv lansarea aplicaţiei în execuţie şi serviciile de garanţie, post-garanţie, mentenanţă şi
suport, trebuiesc realizate de către Furnizor. RMU va fi construit pe baza unei arhitecturi
modulare, pentru a putea permite modificări şi dezvoltări ulterioare. Furnizorul va livra module
software pentru toate nivelurile administrative ale RMU.
Interfaţarea cu sistemele existente.
Sistemul trebuie să interfaţeze cu sistemele existente în universităţi. În cazul în care o parte din
informaţii nu sunt disponibile în sistemele existente, Furnizorul trebuie să pună la dispoziţie
aplicaţii prin care se vor completa şi achiziţiona informaţiile necesare RMU. De asemenea vor fi
realizate interfețe cu sisteme terțe.
Implementarea unei componente web de tip portal.
Furnizorul va implementa o componentă de tip portal, accesibilă pe web, care va fi parte a
RMU.
Portalul web va avea opţiunea de vizualizare şi în limbile engleză, franceză, germană, italiană.
Implementarea unui sistem de autentificare securizată și de autentificare.
Aplicația trebuie să permită autentificarea securizată prin dispozitive electronice (de ex. Etoken),
precum și autentificări standard prin utilizator și parolă. Furnizorul trebuie să ofere propuneri de
politici de securitate a parolelor, modul de schimbare a acestora, tipul de caractere necesare în
crearea unei parole precum și modul de criptare în baza de date.
Se solicită implementarea de semnături digitale pentru autentificare și certificare date – RMU
trebuie să conțină soluție de semnătură electronică, integrată în cadrul aplicației pentru
semnarea formularelor electronice, a exportului de date, a formularelor afișate pe portalul web,
a documentelor și deciziilor publicate, etc.
Furnizarea proiectului de arhitectură hardware a RMU.
Furnizorul va trebui să propună arhitectura completă hardware necesară RMU. În definirea
specificaţiilor echipamentelor, Furnizorul va respecta prevederile Legii achiziţiilor publice din
România.
În urma finalizării proiectului, baza de date a RMU va reprezenta o sursă unică de date
complete şi corecte privind SIS din România.
RMU trebuie să ofere o sursă unică pentru nomenclatoarele care pot fi utilizate de către aplicaţii
şi sisteme terţe. RMU trebuie să fie bazat pe standarde deschise, care sa permită comunicarea
cu alte sisteme.
Pag. 19/84
20. Sistemul trebuie să ofere garanţia introducerii unice a aceluiaşi set de date, evitând colectarea
multiplă a datelor.
7. SPECIFICAŢII FUNCŢIONALE
RMU trebuie să conţină interfeţe pentru managementul datelor şi rapoartelor. Ele vor putea fi
utilizate şi de către operatorii universităţilor. Principalele caracteristici ale ei vor fi:
Interfaţa cu utilizatorul trebuie să fie accesibilă web, securizat, cu acces diferenţiat
pentru rolurile diferite de utilizator.
Interfaţa cu utilizatorul trebuie să conţină funcţionalităţi care să uşureze munca
operatorilor şi să mărească productivitatea acestora.
Interfaţa cu utilizatorul trebuie să fie clară şi consistentă, pentru a permite un acces uşor
la informaţiile solicitate.
Datele conţinute în cadrul RMU trebuie să fie uşor de vizualizat şi de localizat. În acest
scop, toate modulele sistemului ce lucrează cu colecţii de date de tip nomenclator
trebuie să afişeze aceste colecţii de date prin intermediul unei liste de selecţie.
Sistemul trebuie să conţină module cel puţin pentru: raportare; analiză; tablou de bord
sau alte tehnici de management universitar.
Rapoartele trebuie să conţină şi elemente de tip: charts, maps, crosstabs, 3D bar, pie,
line, gauge, funnel, scatter, dot density.
Trebuie să permită un management multidimensional, oferind informaţiile atât pentru
raportare cât şi pentru analiză.
Rapoartele trebuie să poată fi afişate utilizatorilor sub diverse forme, inclusiv tablou de
bord. Componenta de raportare trebuie să permită salvarea rapoartelor în diferite
formate cum ar fi PDF, Word, Excel, Html etc.
Interfaţa trebuie să fie prietenoasă pentru navigare, să ofere facilităţi de tip drill-down şi
alte funcţionalităţi ce pot uşura utilizarea sistemului.
Raportarea consolidată şi managementul depozitelor de date trebuie să asigure
funcţionalităţi native de extragere a datelor din diferite surse de date (SQL Server,
Oracle, Excel, Web services), realizarea de filtrări, agregări şi diferite alte transformări
asupra datelor necesare integrării cu diversele sisteme informatice ale instituţiilor de
învăţământ - ETL (Extract, Transformation, Lload).
7.1. CATEGORII DE RAPOARTE
Editarea rapoartelor are la bază proceduri de căutare, sortare, filtrare, corelare, clasificare uni şi
multicriterială, analiză statistică etc. Se vor proiecta generatoare de rapoarte, care pot
reconfigura diverse seturi de date corelate. Rapoartele vor reflecta situaţia persoanelor la un
moment dat (static), dar şi în dinamică, prin analiza comparată cu unul sau mai multe momente
anterioare (dinamic).
Exemple de rapoarte:
a) Rapoarte referitoare la student: statutul şcolar al studentului; urmărirea traseului
universitar parcurs în timp de o persoană; pagina personală a studentului etc.
Pag. 20/84
21. b) Rapoarte de semnalare a încălcării legislaţiei: persoană înscrisă într-un program la
un anumit nivel (L,M,D), fără să dovedească parcurgerea nivelului anterior; persoană înscrisă
într-un an de studiu, fără să dovedească parcurgerea anilor anteriori; situaţia studenţilor care
urmează al doilea program la acelaşi nivel (L,M,D) pe locuri finanţate de la buget; situaţia
studenţilor care urmează al doilea program la zi în centre universitare diferite etc.
c) Rapoarte centralizatoare de analiză care vizează situaţia studenţilor pe:
universităţi; cicluri de studii; forme de învăţământ; specializări; forme de finanţare;
centre universitare; zone geografice de apartenenţă a universităţilor; ani de studii;
domenii fundamentale de ştiinţă; domenii de L, M, D; grupe de vârstă; mediu de
provenienţă (urban, rural); pe sexe etc. precum şi după mai multe astfel de criterii, static
şi dinamic. De asemenea, pot fi solicitate rapoarte privind numărul absolvenţilor cu şi
fără diplomă (L,M,D), situaţia studenţilor bursieri, a celor cazaţi, situaţia studenţilor care
urmează a doua facultate, situaţia studenţilor exmatriculaţi, situaţia studenţilor
transferaţi inter-universităţi, situaţia studenţilor admişi prin concurs, situaţia studenţilor
admişi ca olimpici, situaţia studenţilor admişi prin proceduri speciale de către MECI etc,
în diverse grupări: pe ani, pe univesităţi, pe specialităţi etc., static şi dinamic.
d) Rapoarte de evidenţă a documentelor de studii şi de absolvire: corelarea între
numărul absolvenților şi numărul diplomelor eliberate; confruntarea seriilor documentelor
eliberate cu cele livrate de MECI etc.
e) Rapoarte privind analize de excepţie: universitatea cu cel mai mare / mai mic număr
de studenţi; specializările de licenţă cu cel mai mare / cel mai mic număr de studenţi;
universităţile cu cel mai mic număr de studenţi promovaţi integral etc.
f) Fişiere cu o structură particularizată, cu format standardizat, pentru a se putea
exporta date către instituţiile conexe: INS, ARACIS, Ministerul Muncii, Familiei şi Protecţiei
Sociale, Ministerul Sănătăţii, Ministerul Finanţelor Publice etc.
RMU trebuie să ofere posibilitatea construirii de noi rapoarte, la
cererea beneficiarului.
Editarea Rapoartelor, afişarea datelor şi a informaţiilor obţinute din procesul de prelucrare vor
avea în vedere toate cerinţele de prezentare profesională a lor, privind identificarea, datarea,
sortarea, filtrarea, paginarea, aranjarea etc.
7.2. GESTIONAREA NOMENCLATOARELOR
RMU trebuie să gestioneze o serie de nomenclatoare. Elementele nomenclatoarelor
conţinute în RMU trebuie să fie aliniate cu legile şi reglementările și codificările naționale
utilizate în SIS. RMU trebuie să permită înregistrarea valabilităţii elementelor din nomenclatoare
şi să ţină cont de aceasta.
Exemple de nomenclatoare:
Universităţi
Pag. 21/84
22. Facultăţi
Domenii fundamentale de artă, ştiinţă şi cultură
Domenii de studii universitare: licenţă, masterat, doctorat
Specializări / Programe de studii: licenţă, masterat, doctorat
Domenii pentru finanţarea universităţilor de stat
Judeţe din România
Localităţi din România
Regiuni geografice din România
Naţionalităţi
Ţări
Cetăţenie
Ani universitari
Forma de învăţământ – zi, distanţă, frecvenţă redusă, seral
Formă de proprietate – public, privat
Limbă de studiu
Alte nomenclatoare ce vor fi identificate în perioada de analiză detaliată trebuie implementate şi
utilizate acolo unde sunt necesare.
7.3. GESTIONAREA INFORMAȚIILOR
INFORMAȚII PRIVIND STUDENȚII ÎNMATRICULAȚI ÎN CADRUL UNIVERSITĂȚILOR
RMU trebuie să colecteze informaţii privind studenţii înmatriculaţi în cadrul universităţilor.
Informaţiile colectate vor fi folosite ca suport pentru prelucrări după diverse criterii în vederea
realizării raportărilor solicitate de utilizatorii sistemului.
Mulţimea orientativă a informaţiilor referitoare la studenţi este prezentată în Anexa 1.
Un student poate fi înscris simultan în cadrul mai multor universităţi sau poate fi înscris în cadrul
mai multor facultăţi ale aceleiaşi universităţi.
O persoană care are calitatea de student la un moment dat, poate fi absolvent al unui program
la un moment anterior sau să fi ieșit prematur dintr-un program desfăşurat anterior.
Sistemul va permite asocierea studentului la structura organizaţională a universităţilor:
departamentul / facultatea, domeniul de licenţă, specializarea / programul de studii, anul de
studii etc.
Datele privind situaţia şcolară a studentului vor fi asociate la nivel de specializare / program de
studiu.
Sistemul trebuie să înregistreze informaţii cu privire la documentele de studii (diplomele de
bacalaureat, licenţă, masterat, doctorat etc.).
RMU trebuie să fie capabil să identifice:
a) Starea completă actuală a studentului (toate programele de studii pe care le
urmează simultan, formele de învăţământ, formele de finanţare etc.).
b) Toate studiile universitare anterioare ale studentului (toate programele de studii pe
care le-a absolvit, formele de învăţământ, formele de finanţare etc., precum și
programele de studii pe care le-a părăsit prematur) şi documentele care atestă
aceste studii.
Pag. 22/84
23. c) Studiile liceale finalizate şi documentele care atestă aceste studii.
INFORMAȚII PRIVIND STRUCTURA ADMINISTRATIVĂ A UNIVERSITĂŢILOR
Sistemul trebuie să colecteze informaţii privind „Structura administrativă a universităţilor”, vezi
Anexa 1 - Secţiunea II.1 „Structură administrativă”:
universitatea;
facultatea / departamentul;
ciclul de studii ( L,M,D);
domeniul de studii (pe cicluri de studii);
programul de studii / specializarea şi numărul de puncte de credit asociate;
acreditat / autorizat provizoriu;
forma de învăţământ (zi, seral, frecvenţă redusă, învăţământ la distanţă).
Sistemul trebuie să efectueze colectarea informaţiilor despre structura organizaţională a
universităţilor într-o manieră flexibilă, permiţând reprezentarea corectă a structurilor
organizaţionale reale, prezente în cadrul universităţilor.
Structura organizaţională ierarhică, definită pentru o universitate trebuie să fie utilizată în cadrul
modulului de securitate a sistemului, pentru a restricţiona accesul utilizatorilor conform nivelului
ierarhic corespunzător.
INFORMAȚII PRIVIND CIFRELE DE ȘCOLARIZARE
Sistemul trebuie să colecteze informaţii privind cifrele de şcolarizare, vezi Anexa 1, Secţiunea
II.2 „Date privind cifrele de şcolarizare”:
anul de studiu;
cifra de şcolarizare aprobată pentru fiecare ciclu de studiu (L,M,D), programul de studiu
pe componentele buget / taxă;
numărul de locuri pe cicluri de studiu (L,M,D), pentru cetăţenii din Republica Moldova;
numărul de locuri pe cicluri de studiu (L,M,D), pentru cetăţenii de etnie română din alte
ţări;
studenţii de etnie romă şcolarizaţi pe locuri speciale;
ordinul D.G.I.A.E.R. pentru bursierii statului român;
studenţi pe cont propriu valutar.
7.4. VALIDAREA DATELOR
Având în vedere că Furnizorul trebuie să asigure încărcarea datelor în RMU în două modalităţi
diferite (vezi figura 1), sistemul trebuie să asigure: a) validarea datelor culese primar şi b) a
celor exportate din bazele de date ale universităţilor. Cele două modalităţi vor fi tratate diferit.
Pentru prima, erorile vor fi notificate utilizatorului şi se vor oferi informaţii în vederea realizării
corecţiilor. Pentru a doua categorie, vor fi editate rapoarte care necesită decizii la nivel naţional
sau la nivel de universitate, pentru remediere.
Validările pot viza situaţia de la un moment dat (static) sau pot viza corelaţii între seturi de date
de la momente diferite (dinamic).
Pag. 23/84
24. 8. COMPONENTA WEB DE TIP PORTAL
Componenta web a sistemului va trebui să fie alcătuită din cele două secţiuni: publică,
accesibilă oricărui vizitator; privată, accesibilă exclusiv utilizatorilor înregistraţi.
Funcţionalităţile minime ale componentei web sunt:
Fiecare potenţial utilizator al sistemului va trebui să aibă posibilitatea de a se
înregistra în interfaţa web a aplicaţiei şi de a-şi crea un cont de utilizator, având
iniţial un set standard de drepturi de acces. Drepturile de acces vor trebui să poată fi
ulterior modificate pentru a permite un acces diferenţiat în secţiunile de acces la date
şi proceduri.
Sistemul trebuie să alerteze utilizatorul după login dacă perioada de valabilitate a
contului se apropie de sfârşit şi să îi permită acestuia să-şi revalideze datele, să
schimbe parola, sau să schimbe adresa de e-mail, mărind astfel perioada de
valabilitate a contului cu acelaşi interval standard definit în sistem.
Sistemul va pune la dispoziţia utilizatorului prin interfaţa web posibilitatea de a trimite
sesizări sau sugestii cu privire la diverse probleme ce pot apărea la accesarea
datelor, sau la funcţionarea interfeţei web; toate acestea vor fi confirmate prin
trimiterea unui e-mail către adresa utilizatorului cu datele subscrise şi cu un număr
de identificare unic ce va permite urmărirea facilă a acestor informaţii.
Sistemul va colecta toate datele introduse de utilizator, relative la comunicări şi
sesizări, şi va oferi acestuia posibilitatea de a accesa toate aceste date introduse:
spre exemplu, în interfaţa web, utilizatorul îşi va vedea toate sugestiile şi reclamaţiile
introduse în sistemul centralizat; va putea să efectueze modificări, să şteargă sau să
creeze şi să raporteze situaţii noi.
Pentru localizarea documentelor accesibile nivelului de acces al utilizatorului, acesta
va putea căuta după tipuri de documente (nomenclatoare etc.), după tipul de fişiere
căutate (fişiere, *.doc, *.pdf, imagini etc.), după zona geografică a instituţiei, după
numele instituţiei, după perioada de valabilitate a documentului, după perioada în
care documentul a fost introdus în sistemul centralizat.
Datele găsite după aplicarea criteriilor de filtrare vor fi afişate în pagină într-o formă
lizibilă, aplicaţia permiţând salvarea acestora într-un format standard ales de
utilizator: csv, txt, HTML, XML, pdf, doc, xls – toate acestea putând fi trimise şi pe
adresa de e-mail a utilizatorului, dacă dimensiunea tuturor fişierelor ataşate nu
depăşeşte o valoare stabilită ulterior. Mesajele astfel trimise trebuie să menţioneze
că datele pot suferi modificări.
Interfaţa web a aplicaţiei va permite utilizatorului să definească filtre după criteriile de
căutare folosite cel mai des de către utilizator şi va oferi posibilitatea refolosirii prin
salvarea acestora.
Sistemul va permite definirea de grupuri de utilizatori şi executarea unor operaţii
orientate pe grup, cum ar fi trimiterea de mesaje de e-mail tuturor membrilor
grupului.
Interfaţa web va implementa şi conceptul de „Inbox” prin intermediul căruia sistemul
va pune la dispoziţia utilizatorilor informaţii noi de interes pentru aceştia. Existenţa
Pag. 24/84
25. mesajelor noi va fi semnalată utilizatorilor înregistraţi la momentul autentificării în
sistem.
Toate formularele utilizate în componenta web de tip portal vor fi însoţite de un
mecanism de protecţie împotriva trimiterii multiple, prin folosirea de texte de tip
„Captcha”.
Toate validările de date ce se vor face în interfaţa utilizator vor indica cu exactitate
mesajele de eroare în cazul în care acestea apar, iar în anumite cazuri vor sugera
metode de evitare a acestora sau vor oferi sugestii de completare a câmpurilor.
Căutarea documentelor sau a oricăror tipuri de date se va putea face folosind criterii
precum: căutare după dată, căutare în interval calendaristic selectat, după numele
fişierului sau al articolului, după data de creare a documentului, după autorul
documentului (persoană sau instituţie), după conţinutul documentului („full-text
search”), acolo unde este cazul.
9. INTEROPERABILITATE / INTEGRARE CU SISTEME EXISTENTE ȘI VIITOARE
Interoperabilitatea reprezintă un factor cheie în proiectarea şi dezvoltarea acestui sistem,
asigurând conlucrarea cu sisteme interne sau terţe, prezente sau viitoare.
Se va asigura un grad ridicat de interoperabilitate, prin utilizarea de standarde recunoscute,
care să permită dezvoltarea viitoare de noi funcţionalităţi sau chiar de sisteme informatice
complexe ce vor consuma serviciile oferite de RMU.
Pentru a asigura continuitate în interoperare şi pentru a asigura funcţionarea viitoare a
sistemului, formatele şi tehnologiile utilizate în interoperabilitatea sintactică trebuie să fie definite
ca standard sau să fie bazate pe standarde deschise şi susţinute intern sau internaţional.
Se solicită Ofertantului descrierea nivelului şi modelelor de interoperabilitate propuse pentru
acest sistem.
9.1. INTEROPERABILITATEA CU SISTEMELE INFORMATICE EXISTENTE ÎN UNIVERSITĂȚI
RMU va reprezenta o implementare la nivel naţional, interconectându-se cu toate universităţile
de stat şi particulare acreditate din România, după modelul de principiu prezentat în figura 1.
Furnizorul va livra programe de culegere a datelor în format standard (fig. 1.a), respectiv
interfeţe cu sistemele informatice existente (fig. 1.b). Se va furniza, de asemenea, o procedură
de export în RMU din formatul standard creat la nivelul aplicaţiilor locale.
Modulul de administrare a procesului de încărcare a datelor în baza de date RMU trebuie să
furnizeze statistici cu privire la încărcarea datelor şi gradul de completitudine al acestora.
Furnizorul va asista universităţile pentru a-şi asigura interconectarea cu RMU.
9.2. INTEROPERABILITATEA CU SISTEMELE INSTITUȚIILOR CONEXE
RMU trebuie să poată exporta, în format standardizat, date către sistemele informatice ale
instituţiilor conexe, cum ar fi:
Ministerul Muncii, Familiei şi Protecţiei Sociale
Ministerul Finanţelor Publice
ARACIS
Pag. 25/84
26. Ministerul Sănătăţii
Institutul Naţional de Statistică etc.
În acest sens se va furniza şi un set complet de documentaţii tehnice privind formatul propus şi
formatele de export.
10. SISTEMUL DE SECURITATE
Luând în considerare natura personală şi confidenţială a datelor ce vor fi colectate, RMU trebuie
să conţină un sistem de securitate performant, ce suportă funcţionalităţi de integrare şi
autentificare, care să respecte obligatoriu cel puţin cerinţele minime de securitate prezentate în
ORDINUL nr. 52 din 18 aprilie 2002 privind aprobarea Cerinţelor minime de securitate a
prelucrărilor de date cu caracter personal.
Sistemul de securitate trebuie să permită şi autentificarea automată, pentru a permite
conectarea sistemelor informatice ce vor comunica prin intermediul serviciilor expuse de
registru, utilizând un sistem de criptare asimetric.
Accesul utilizatorilor la interfaţa de colectare a datelor la nivelul sistemului central se va efectua
securizat, prin utilizarea certificatelor digitale.
Canalele de comunicaţii utilizate pentru transfer vor fi securizate.
SISTEMUL IERARHIC DE AUTENTIFICARE ȘI AUTORIZARE
Se solicită un sistem de autorizare ierarhic, în care drepturile de securitate pot fi asociate
diferitelor niveluri din modelul informaţional real. Astfel, un utilizator primeşte drepturi de
securitate numai la nivelul ierarhic la care are acces în realitate (vezi figura 2). Sistemul de
autorizare se răsfrânge asupra tuturor funcţionalităţilor prezente în sistemul central, inclusiv
asupra sistemului de raportare.
Exemple de drepturi de securitate sunt:
studentul poate vizualiza informaţiile colectate despre el, dar numai despre el;
personalul autorizat din cadrul unei facultăţi poate vizualiza şi prelucra datele studenţilor
înscrişi numai în cadrul respectivei facultăţi;
personalul autorizat de la nivelul universităţii are dreptul de a vizualiza şi prelucra
datele tuturor studenţilor universităţii;
personalul autorizat de la nivelul central RMU are dreptul de a vizualiza şi prelucra
datele tuturor studenţilor din SIS;
alte categorii de utilizatori vor avea acces numai pentru vizualizarea, cu sau fără drept
de copiere, a unor informaţii publice.
Pag. 26/84
27. Acces naţional securizat
RMU
Administratori RMU
Nivel Naţional
Operatori validare
Back office, raportare,
Operatori raportare
servicii
Sisteme informatice conexe
Acces instituţie securizat
Administrator instituţie
Operatori introducere date şi validare
Back Office RMU Servicii RMU Operatori raportare
Nivel Instituţie Nivel Instituţie Sisteme informatice locale
Acces componentă securizat
Administrator componentă
Back Office RMU Back Office RMU Servicii RMU Operatori introducere date
Nivel componentă Nivel componentă Nivel componentă Operatori raportare
instituţie instituţie instituţie Sisteme informatice locale
Figura 2. - Structură ierarhică - drepturi de securitate
Structura ierarhică completă de drepturi de securitate va fi definitivată în faza de analiză
detaliată.
Aplicația trebuie să permită autentificarea securizată prin dispozitive electronice (de ex. Etoken),
precum și autentificări standard prin utilizator și parolă. Furnizorul trebuie să ofere propuneri de
politici de securitate a parolelor, modul de schimbare a acestora, tipul de caractere necesare în
crearea unei parole precum și modul de criptare în baza de date.
Se solicită implementarea de semnături digitale pentru autentificare și certificare date – RMU
trebuie să conțină soluție de semnătură electronică, integrată în cadrul aplicației pentru
semnarea formularelor electronice, a exportului de date, a formularelor afișate pe portalul web,
a documentelor și deciziilor publicate, etc.
11. CERINȚE PRIVIND ARHITECTURA TEHNICĂ
11.1 SUPORTUL DE LIMBĂ
Toate interfeţele utilizator trebuie să asigure suport pentru limba română.
11.2 PERFORMANȚĂ
Sistemele hardware şi software recomandate pentru susţinerea RMU trebuie să asigure accesul
simultan pentru minim 2500 de utilizatori şi nelimitat pentru vizitatorii secţiunii publice a
sistemului. Componentele de sistem suplimentare, precum trimiterea de mesaje electronice,
accesul la fişierele din server etc., trebuie să fie calibrate pentru a accepta cel puţin 50 de
conexiuni simultane.
Se solicită din partea Ofertantului menţionarea ordinului de mărime a serverelor (număr,
capacitate procesor, memorie, harddisk) astfel încât timpul de răspuns al aplicaţiei să nu
depăşească 10 (zece) secunde pentru 95% dintre tranzacţiile de tip introducere date şi 5 (cinci)
Pag. 27/84
28. secunde pentru alte tipuri de tranzacţii referitoare la aplicaţie, cu excepţia operaţiunilor de
generare a rapoartelor şi accesarea funcţiilor de administrare a sistemului.
11.3 SUBSISTEMUL DE ADMINISTRARE
Soluţia oferită va include o componentă pentru operaţiunile zilnice de mentenanţă şi auditare în
vederea unei exploatări sigure a RMU, pentru un areal de utilizatori pe întreg teritoriul ţării.
SOFTWARE BACKUP
Ofertantul va propune o soluţie cuprinzătoare şi eficientă de backup, care va fi compatibilă cu
toate sistemele de operare, bazele de date şi alte registre de date folosite la implementarea
RMU. Soluția de back-up va permite transferul automat și manual la intervale de timp definite de
administrator.
JURNALIZARE / AUDITARE
Ofertantul va furniza în cadrul soluţiei posibilitatea stocării în jurnale şi a vizualizării acestora de
către utilizatori cu roluri predefinite, a tuturor acţiunilor cu impact în sistem, de la introducerea
de date şi până la consultarea acestora, putând identifica unitatea administrativă din care
utilizatorul a intervenit în sistem, numele acestuia şi oricare alte date relevante legate de
informaţia accesată.
Fişierele de jurnalizare vor fi protejate astfel încât doar personalul sau utilizatorii autorizaţi să
poată avea acces la ele şi toate activităţile de accesare a acestor fişiere vor fi de asemenea
jurnalizate într-un registru separat.
11.4 CERINȚE DE DEZVOLTARE
Componentele interfeţei utilizator trebuie să se bazeze pe INTERNET, fie sub forma unei
interfeţe pentru browser de INTERNET, fie sub forma aplicaţiilor desktop.
Sistemul software trebuie să fie încorporat în conceptul Arhitectură Orientată pe Servicii
(Service Oriented Architecture - SOA).
Sistemul trebuie să fie modular ca structură, permiţând separarea componentelor codului pentru
interfaţa utilizator de codul logicii de business, permiţându-se, astfel, dezvoltarea viitoare
independentă a componentelor şi posibilitatea adăugării de componente noi, fără să afecteze
stabilitatea sistemului. Structura trebuie să permită modulelor software să fie adăugate sau
actualizate, fără să afecteze întreaga aplicaţie.
RMU trebuie să încorporeze tehnologii pentru integrarea şi schimbul de date în format Unicode.
Sistemul trebuie să se integreze în cadrul arhitecturilor de servicii de tip enterprise, care susţin
organizaţiile încrucişate, interoperabilitatea încrucişată a aplicaţiilor, colaborarea şi integrarea în
medii complexe.
Autentificarea utilizatorilor trebuie să fie integrată cu subsistemul de securitate şi să permită, de
asemenea, extinderea prin LDAP v3 (Lightweight Directory Access Protocol) pentru a fi folosită
de sisteme externe RMU.
RMU trebuie să permită integrarea cu aplicaţiile din suita Microsoft Office (Excel, PowerPoint,
Word, Outlook).
Pag. 28/84
29. RMU va fi dotat cu un sistem de asistenţă sensibil la context (context sensitive) accesibil tuturor
utilizatorilor care sunt autentificaţi. Limba sistemului de asistenţă trebuie să fie româna.
Interfaţa utilizator trebuie să utilizeze un limbaj corespunzător în toate modulele, cu cuvinte,
expresii şi concepte familiare utilizatorilor, prin aceasta favorizându-se un acces facil şi intuitiv,
limitându-se utilizarea termenilor orientaţi către sistem. Este responsabilitatea furnizorului să se
familiarizeze cu terminologia specifică utilizată în cadrul comunicărilor din SIS.
Pictogramele, elementele din meniu sau comenzile ce indică acţiuni şi opţiuni trebuie să fie clar
diferenţiate şi trebuie să corespundă standardelor de bună practică, general acceptate. Aceleaşi
pictograme / comenzi trebuie să îndeplinească aceleaşi funcţii în întreaga interfaţă utilizator.
Modulele interfeţei utilizator trebuie să fie structurate astfel încât, la orice moment, utilizatorii să
poată identifica ce funcţie folosesc în respectivul moment şi cum pot reveni atât la pasul
anterior cât şi la principala interfaţă software (meniul principal).
Toate funcţionalităţile componentei client a RMU trebuie să fie accesibile de la orice PC
(calculator personal) care foloseşte rezoluţii de monitor de minim 1024x768.
Pentru a menţine independenţa platformei, nu se vor utiliza controale sau tehnologii specifice
unui anumit tip de browser în componenta client (cum ar fi ActiveX, XUL etc.).
RMU trebuie să asigure o Interfaţă de Programare a Aplicaţiei - API (Interfaţă deschisă) bine
documentată. Prin aceasta, aplicaţiile suplimentar dezvoltate / implementate într-o etapă
ulterioară sau care rulează în cadrul instituţiilor beneficiare şi furnizează date pentru sistem, să
se poată conecta la elementele centrale ale RMU, să poată interacţiona cu subsistemul său de
securitate şi făcând uz de funcţionalităţile puse la dispoziţie de către sistem şi interfeţele expuse
să poată asigura alimentarea cu date a bazelor de date ale sistemului, dar numai după ce în
cadrul acestui flux s-au parcurs toate etapele de validare prevăzute.
Notificările către utilizatori trebuie să se efectueze preferabil prin e-mail. Pentru universităţile
care nu au o soluţie proprie de e-mail, furnizorul va propune o soluţie de comunicare și
colaborare pe propriul domeniu ales al universităţii şi de creare a conturilor pentru studenţii
acesteia. Pentru ceilalţi utilizatori se vor propune soluţii de comunicare şi colaborare
corespunzătoare.
Contul de e-mail personalizat creat pentru fiecare student trebuie să îndeplinească următoarele
cerinţe:
spaţiu de stocare de până la 10GB şi să permită ataşamente (dimensiunea
ataşamentelor de minim 10 MB),
serviciul trebuie să fie securizat şi să asigure scanarea antivirus a mesajelor,
facilitaţi pentru crearea de liste de distribuţie e-mail la nivel de grup.
În funcţie de diverse evenimente, aplicaţia trebuie să fie capabilă să genereze şi să trimită
notificări/alerte, preferabil prin e-mail.
Controlul accesului utilizatorilor trebuie să fie bazat pe setările de permisiuni, configurabile
conform poziţiei lor în SIS.
Va fi proiectată procedura exportului datelor de către universităţi precum şi procedura de
corecţie a datelor, după validare, prin export corector, fără suprascriere.
Sistemul trebuie să prevadă posibilitatea reluării ultimului export şi să ofere proceduri
corespunzătoare de aprobare a acestuia.
Arhitectura sistemului trebuie să fie de tip NOSPOF (No Single Point of Failure), asigurând un
înalt nivel de disponibilitate a serviciilor.
Pag. 29/84
30. Soluţia trebuie să asigure un nivel de protecţie de tip firewall, respectând cerinţa de înaltă
disponibilitate a întregii soluţii.
Furnizorul va pune la dispoziţia Beneficiarului sursele programelor,
licenţelor instrumentelor care permit proiectarea şi dezvoltarea
aplicaţiilor livrate şi sistemul de dezvoltare colaborativ.
11.5 PROTECŢIA DE TIP ANTIVIRUS
Soluţia va trebui să ofere protecţie antivirus pentru servere de tip front-end. Soluţia
antivirus trebuie să aibă următoarele caracteristici minimale :
suport pentru scanare antivirus în timp real a traficului de date la download sau upload
spre serverele de front end,
suport pentru scanare antivirus, la cerere, a conţinutului portalului,
suport automatizat de update-uri de semnături înainte de scanare,
posibilitate de ştergere automatizată a fişierelor corupte, comprimate sau criptate,
posibilitate de trimitere notificări la recipienţi,
suport pentru raportare și statistici de securitate,
suport pentru update-uri pentru fişierele de semnături la 15 minute,
posibilitate de setare a unui loc secundar pentru downloadarea fişierelor de semnături,
protecţia în timp real antivirus şi antispyware să fie asigurată şi în perioada de timp în
care motoarele antivirus se actualizează,
suport pentru multiple motoare antivirus – soluţia trebuie să aibă mai multe motoare de
scanare antivirus de la producători certificaţi VB 100% sau ICSA Labs,
posibilitate de setare a comportamentului produsului pentru folosirea separată a unuia
sau mai multor motoare de scanare,
posibilitatea de setare a unor dimensiuni maxime pentru scanarea fişierelor transmise,
posibilitatea de creare a unor modele (template-uri) pentru scanările de securitate,
suport pentru scanarea unor formate diferite de fişiere arhivate (cel putin: PKZip (.zip),
GNU Zip (.gzip), Arhive .zip self-extracting (.exe), Arhive Zip (.zip), Arhive Java (.jar),
formatul TNEF (Winmail.dat), Structured storage (.doc, .xls, .ppt), Open XML (docx,
.xlsx, or .pptx), MIME (.eml), SMIME (.eml), UUEncode (.uue), Arhive UNIX (.tar),
Arhive RAR (.rar), MACBinary (.bin)),
posibilitatea de scanare separată la cerere antivirus și/sau scanare de conţinut după
extensii și/sau scanare după lista de cuvinte cheie,
suport pentru filtrare de conţinut după cuvinte cheie şi posibilitatea de creare a listelor de
cuvinte cheie,
suport pentru filtrare de conţinut după tipul, extensia, numele sau dimensiunea fişierelor.
11.6 CERINȚE DE ASIGURARE A CALITĂȚII
Ofertantul trebuie să prezinte descrierea serviciilor de asigurare a calităţii. Obiectivele principale
ale serviciilor de asigurare a calităţii proiectului trebuie să fie:
Pag. 30/84
31. stabilirea unui standard de calitate bine documentat pentru toate activităţile şi
elementele care trebuie livrate în cadrul proiectului;
stabilirea unui cadru privind calitatea, care va fi utilizat pentru evaluarea conformităţii
produselor şi a procedurilor de implementare RMU;
stabilirea măsurilor preventive şi/sau corective în cazurile în care produsele sau
procedurile proiectului sunt livrate sau efectuate într-un mod care nu este conform cu
standardul de calitate.
Ofertantul trebuie să livreze Planul de asigurare a calităţii şi Metodologia de asigurare şi
control a calităţii (certificare ISO 9001:2000 sau echivalent).
Standardele de asigurare a calităţii trebuie să acopere toate componentele proiectului şi
sistemului dezvoltat.
11. BAZA DE DATE
Soluția de bază de date trebuie să țină seama de gestiunea unui volum mare de date referitoare
la situația prezentă a studenților și a tuturor situațiilor de pregătire anterioară lor.
Tehnologia de bază de date utilizată pentru depozitul de date central trebuie să suporte
următoarele caracteristici:
scalabilitate ridicată;
optimizator ajustabil, multinivel, pentru interogări;
procesare paralelă a interogărilor (procesează simultan mai multe partiţii de tabel);
recuperare la un moment dat (recuperare la un moment specificat în timp);
suport de backup online şi offline;
să poată rula pe diferite sisteme de operare (Linux, Unix, Windows);
să ruleze pe servere de tip cluster cu diferite tipuri de CPU;
să schimbe date cu alte RDBMS folosind conexiuni directe;
să permită suspendarea temporară a task-urilor care folosesc multe resurse;
să permită administrarea din browser web;
să permită utilizarea, actualizarea şi administrarea bazelor de date foarte mari (mai mult
de 2TB şi în concordanţă cu volumul datelor care vor fi gestionate);
să permită accesul utilizatorilor la informaţii în acelaşi timp;
să permită definirea de utilizatori şi grupuri de utilizatori cu diferite drepturi de acces;
să permită rularea în mod cluster;
să permită balansarea între servere, astfel încât să se obţină o performanţă mai mare;
să permită crearea de copii logice şi fizice ale bazelor de date, pentru citire şi
actualizare;
RDBMS trebuie să aibă propriul software de cluster pentru a rula pe diferite sisteme de
operare fără să se achiziţioneze alte licenţe suplimentare pentru sistemul de operare;
să permită definirea de indexuri la nivel local şi global;
să permită definirea mai multor categorii de indexuri;
să permită diferite tipuri de partiţionare;
să monitorizeze toate tipurile de interogări;
Pag. 31/84
32. să conţină unelte pentru administrarea bazelor de date si procesărilor uzuale care se
execută asupra bazelor de date;
să ofere performanţe ridicate ale sistemului de baze de date, referitoare la: criptarea
transparentă a datelor, a fişierelor de date şi jurnal; autentificarea operaţiilor; colectarea
datelor de performanţă; monitorizarea evenimentelor; comprimarea backup-urilor;
să permită implementarea structurilor de date complexe, inclusiv a datelor binare mari.
Furnizorul trebuie să ofere toate licenţele necesare atât pentru
universităţi, cât şi pentru RMU. Toate sistemele de baze de date
folosite trebuie să fie licenţiate.
12. ARHIVAREA DATELOR
RMU trebuie să permită arhivarea datelor pe termen nelimitat. Arhivele se referă la:
a) Datele aferente fiecărui export de la universităţi către RMU, de la momentul punerii în
funcţiune a sistemului. Într-un an universitar vor fi cel puţin două astfel de exporturi.
b) Absolvenţii diverselor cicluri de pregătire (L,M,D), care nu sunt “activi” în SIS (nu sunt
studenţi la momentul curent).
c) Persoanele ieşite prematur din SIS;
d) Nomenclatoarele asociate fiecărui moment de arhivare.
Înregistrările arhivate trebuie să fie disponibile pentru a putea fi interogate ulterior.
Sistemul va trebui să permită şi interogări mixte, de date curente şi arhivate, pentru rapoarte şi
situaţii de evoluţie şi comparare în timp.
Sistemul trebuie să prevadă reîmprospătarea informaţiilor arhivate, astfel încât ele să fie
disponibile la orice moment. Pentru aceasta se vor asigura sisteme de protecţie asociate
arhivelor electronice.
RMU trebuie să fie un sistem activ pentru prezent și trecut.
14. MANAGEMENTUL PROIECTULUI
14.1. METODOLOGIA DE MANAGEMENT AL PROIECTULUI
Se vor oferi servicii de management al proiectului (PM) pe întreaga durată de viaţă a proiectului,
pentru a asigura îndeplinirea la timp a tuturor obiectivelor şi încadrarea în buget.
Ofertantul va include în Propunerea tehnică o descriere completă a metodologiei de PM.
Serviciile PM vor fi oferite de personalul specializat în PM al Furnizorului. Ofertantul va include
în prezentarea echipei de proiect personalul PM propus, cel puţin un Manager de Proiect şi un
Responsabil cu Asigurarea Calităţii.
Pag. 32/84
33. 14.2. METODOLOGIA DE IMPLEMENTARE
Ofertantul trebuie să prezinte în Propunerea tehnică Metodologia de implementare. Ea trebuie
să conţină graficul de implementare, din care să rezulte calendarul de desfăşurare a activităţilor
pentru finalizarea proiectului.
Se impun următoarele termene maximale de referinţă:
1. Dezvoltarea aplicației informatice privind sistemul național de gestiune a studenților:
instalarea și configurarea serviciilor de infrastructură;
crearea structurilor de baze de date;
programare aplicație;
realizare interfețe web și module de autentificare;
implementare de semnături digitale pentru autentificare și certificare date
Rezultat: Aplicația informatică privind RMU, documentația și licențele aferente
Termen de finalizare: 31.01.2010
2. Realizarea raportărilor de bază ale sistemului, cu participarea unor universități pilot:
definirea subsetului de date pentru raportările de bază;
programarea și crearea șabloanelor pentru raportări și interogări;
introducerea de date privind studenții;
generarea și validarea corectitudinii rapoartelor
Rezultat: Raportări de bază ale sistemului, documentația și licențele aferente
Termen de finalizare: 30.04.2010
3. Implementarea facilităților complete ale sistemului și conectarea universităților participante:
extindere raportări de bază;
configurare acces în sistem;
introducere date privind studenții;
generare rapoarte complete;
creare raportului final privind implementarea sistemului
Rezultat: Rapoarte complete ale sistemului, documentația și licențele aferente
Termen de finalizare: 31.05.2010
4. a. Extinderea funcționalităților sistemului:
definirea tipurilor de beneficiari;
definire și programare raportări specifice;
traducere interfață web în limbi oficiale UE (eng, fr, ger, it)
b. Crearea interfețelor de conectare:
programare interfețe web care să permită autentificare prin mecanisme
electronice specifice;
programare sistem de chei publice și semnătură electronică
Rezultate:
a. Modulele extinse ale aplicației, documentația și licențele aferente
Pag. 33/84
34. b. Facilitățile extinse ale interfețelor, documentația și licențele aferente
Termen de finalizare: 30.09.2010
5. Întreținerea și îmbunătățirea sistemului.
6. Formare operatori și administratori sistem:
redactarea și tipărirea manualelor de administrare a sistemului;
organizarea unor ateliere de formare pentru un grup de formatori (aprox. 15-20
persoane)
Termen de finalizare: 30.09.2010
7. Formarea utilizatorilor sistemului:
crearea și distribuirea documentației de utilizare;
organizarea unor ateliere de formare pentru un grup de formatori (aprox. 15-20
persoane);
organizarea unor ateliere de formare (aprox. 8 -10) în centre universitare ale
regiunilor naționale de dezvoltare;
Termen de finalizare: 31.10.2010
8. Testarea finală și recepția a sistemului cu toate componentele și facilitățile
Termen de finalizare: 10.12.2010
9. Garanția RMU
Pentru o perioadă de 3 ani de la recepția finală a sistemului.
Ofertantul trebuie să includă în secţiunea Management de Proiect din Oferta Tehnică un plan
de proiect, detaliat pentru fiecare dintre activităţi.
Sarcinile enumerate în fiecare dintre activităţi trebuie să fie considerate ca nivel minim de
detaliere. Planul inclus în ofertă trebuie să cuprindă toate etapele necesare, să fie în format
GANTT şi să respecte termenele impuse de Beneficiar.
Autoritatea contractantă are opțiunea de a solicita suplimentarea următoarelor servicii:
posibilitatea extinderii sistemului către alți participanți la învățământul superior
formarea utilizatorilor noi ai sistemului
asigurarea de servicii de întreținere și îmbunătățire a sistemului
asigurarea suportului tehnic pentru 1 an.
14.3. LIVRABILE ÎN CADRUL PROIECTULUI
Elementele principale livrate şi conţinutul minim care trebuie acoperit de Furnizorul de servicii
sunt enumerate în următorul tabel.
Sarcină Elemente care trebuie livrate
Implementarea aplicaţiei RMU, cu toate componentele
Definirea Elementele care se livrează în urma acestei sarcini trebuie să fie diagramele
detaliată a de proces aprobate de toate instituţiile interesate (MECI, Universităţi etc.)
proceselor
Pag. 34/84
