Registrul Matricol Unic Documentatia De Atribuire

6,534 views

Published on

Published in: Business, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
6,534
On SlideShare
0
From Embeds
0
Number of Embeds
73
Actions
Shares
0
Downloads
49
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Registrul Matricol Unic Documentatia De Atribuire

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×