Sectiunea II caietul de sarcini

3Cerintele Proiectului

3.1Cerinte Generale

3.1.1Cerinte privind structura sistemului:

• 
  Sistemul va fi astfel conceput incat sa permita structurarea pe nivele ierarhice pentru a indeplini functionalitatile necesare la nivel central, la nivel regional si la nivel local.
  
• 
  Standarde utilizate: se vor utiliza standarde deschise, neproprietare pentru a permite interconectarea facila cu alte sisteme si pentru a permite adaugarea ulterioara de noi facilitati.
  
• 
  Sistemul trebuie sa fie organizat pe module si trebuie sa permita adaugarea facila de noi module functionale. Modulele trebuie sa fie capabile sa functioneze independent, si trebuie sa poata fi administrate independent.
  
• 
  Sistemul va fi constituit pe 3 straturi (tiers) – Baza de date, server de aplicatii, interfata utilizator.
  

3.1.2Cerinte privind flexibilitatea sistemului

Solutia ofertata trebuie sa permita adaugarea ulterioara de noi module fara a fi nevoie de reproiectarea in totalitate a platformei software. De asemenea solutia trebuie sa permita integrarea ulterioara facila cu sisteme si tehnologii utilizate la nivelul institutiilor publice care vor beneficia de aceasta platforma.

3.1.3Cerinte de platforma tehnologica

Platforma tehnologica trebuie sa asigure disponibilitate pentru aplicatiile critice prin implementarea unei structuri de tip cluster, care sa asigure continuarea functionarii aplicatiei in cazul nefericit al unui incident. Aceasta arhitectura asigura si posibilitatea de crestere a puterii de calcul pe masura ce datele din sistem se inmultesc si sistemul isi extinde functionalitatile. Prin folosirea acestei arhitecturi, cresterea se poate face prin adaugarea de noi servere, fara a fi necesara oprirea aplicatiei sau reconfigurarea acesteia.

Functionarea aplicatiei pe mai multe servere trebuie sa fie transparenta pentru utilizatorii care trebuie sa fie deserveti in continare in cazul unui incident, mutarea conexiunii de pe un server pe celalat fiind realizata in mod automat, fara deconectarea utilizatorului.
Platforma tehnologica trebuie sa fie compatibila cu configuratiile hardware uzuale, fara a fi legata de un anumit vendor hardware sau un anumit sistem de operare.

Este recomandat ca arhitectura solutiei software sa fie o arhitectura pe 3 nivele:

• 
  Client;
  
• 
  Serverul de aplicatii;
  
• 
  Baza de date.
  

Functionarea unei aplicatii pe trei nivele presupune existenta unei baze de date, care stocheaza informatiile, a unui server de aplicatii, pe care utilizatorii ruleaza modulele de aplicatie ale sistemului integrat, si clientul, o aplicatie de tip browser, care necesita operatii administrative minime.

3.1.4Cerinte de integrare si interfatare

Sistemul trebuie sa indeplineasca minim urmatoarele cerinte de integrare si interfatare:

• 
  Sistemul trebuie sa se integreze cu solutiile de securitate (gestiunea indentitatii utilizatorilor si a accesului).
  
• 
  Sistemul trebuie sa dispuna de mecanisme tip web-based sau servicii web pentru integrare/interfatare cu diverse sisteme ale Beneficiarului, ale caror specificatii tehnice vor fi puse la dipozitia Ofertantilor in perioada de analiza a proiectului ;
  
• 
  Sistemul trebuie sa permita integrarea facila cu cel putin un sistem de raportare tip “Business Inteligence”, independent de platforma tehnologica si bazate pe standard deschise;
  
• 
  Sistemul trebuie sa permita integrarea nativa cu componente de tip “Service Registry”;
  
• 
  Sistemul trebuie sa permita integrarea nativa cu platforma tehnologica de tip “Cluster”, pentru scalabilitate facila ;
  
• 
  Sistemul trebuie sa se poata integra facil cu componente enterprise de Design si Development pentru o dezvoltare facila ;
  
• 
  Sistemul trebuie sa se poata integra nativ cu o platforma de tip tip “Message Queue” pentru imbunatatirea scalabilitatii, integrabilitatii si a securitatii;
  

3.1.5Cerinte de securitate

Sistemul e-Romania trebuie sa asigure atat cetatenilor, cat si beneficiarilor – institutii publice un mediu sigur conform standardelor in domeniu. Avand in vedere faptul ca portalul e-Romania va oferi servicii cum ar fi efectuarea de plati on-line, gestionarea datelor cu caracter confidential, Ofertantii vor proiecta si vor implementa solutia acordand o importanta deosebita securitatii si confidentialitatii datelor.
In acest sens, ofertantul trebuie sa acorde consultanta in vederea conformitatii sistemului oferit cu sistemului de management al securitatii informatiei (SMSI) conform ISO 27001:2005.
Ofertantul va trebui sa detina urmatoarele certificari:

• 
  minim 2 specialisti certificati ca lead auditor ISO 27001, certificat acreditat IRCA
  
• 
  minim 2 specialisti certificati CISM – certificat emis de ISACA
  
• 
  minim 2 specialisti certificati CEH
  

3.2Cerinte Software Detaliate

3.2.1Timpi de raspuns ai sistemului

• 
  Returnarea raspunsului pentru interogarile interactive din sistem nu trebuie sa dureze mai mult de 5 secunde pentru aplicatiile care ruleaza pe serverele din Data Center.
  
• 
  Executarea rapoartelor on-line nu trebuie sa dureze mai mult de 3 minute. Pentru rapoarte care dureaza mai mult de 3 minute trebuie sa se implementeze un mecanism de rulare in paralel si notificarea utilizatorului cand executarea rapoartelor s-a terminat. Acesta va urma sa fie transmis utilizatorului prin e-mail sau link in cadrul aplicatiei.
  
• 
  Timpii de raspuns se masoara de la initierea operatiei de pe calculatorul utilizatorului si pana la terminarea incarcarii paginii sau a datelor pe calculatorul acestuia.
  
• 
  Sistemele centralizate trebuie sa raspunda in timpii stabiliti in conditii de incarcare de 500 de utilizatori simultan pe fiecare subsistem Portal. Ofertantul trebuie sa prezinte un plan de testare a timpilor de raspuns ai aplicatiilor simuland cele mai utilizate functiuni ale aplicatiilor.
  

3.2.2Istoricul activitatii

• 
  Sistemul trebuie sa dispuna de un mecanism de inregistrare a activitatilor efectuate de utilizatori, in cadrul subsistemelor si pe diverse niveluri de detaliere.
  
• 
  Se vor memora, pe anumite niveluri de agregare si detaliere, toate interactiunile intre subsisteme.
  
• 
  Administratorii subsistemelor trebuie sa poata identifica daca o anumite operatiuni s-a efecutat cu succes sau nu si sa poata avertiza prim mail sau in cadrul subsistemelor Portal pe utilizatorii implicate.
  
• 
  Logul operational va fi mentinut pe cel putin 3 luni in urma.
  

3.2.3Identificarea utilizatorilor

• 
  Sistemul trebuie sa ofere componenta de administrare a accesului utilizatorilor, cu urmatoarele facilitati :
  
  • 
    Administrare utilizatori si servicii acces;
    
  • 
    Autentificare si servicii tip Single-Sign On;
    
  • 
    Administrarea politicilor;
    
  • 
    Servicii de istorizare (logging);
    
  • 
    Consola de administrare;
    
  • 
    Facilitati de depanare (debugging);
    
  • 
    Interfata de administrare web based.
    
• 
  Sistemul trebuie sa ofere componenta de repository de profile utilizatori tip tip « Directory », cu urmatoarele caracteristici :
  
  • 
    Sa fie compatibila cu standardul LDAP ;
    
  • 
    Sa poata fi implementata pe o schema tip “open”, extensibila.
    
• 
  Parolele utilizatorilor vor fi stocate in componenta de « Directory », si doar in cazuri exceptionale, in fisiere bine securizate;
  
• 
  Aplicatiile integrate in cadrul subsistemelor Portal (care se vor detalia in faza de analiza a proiectului) vor asigura identificarea utilizatorilor pe baza numelui de utilizator si a parolei acestora;
  
• 
  Sistemul va permite definirea de reguli prin care utilizatorii sunt obligati sa isi schimbe parola la un anumit interval de timp.
  
• 
  Aplicatiile din cadrul subsistemelor Portal vor permite schimbarea drepturilor utilizatorului fara a fi nevoie de repornirea acestora pentru aplicarea noilor drepturi.
  

3.2.4Administrarea accesului

• 
  Sistemul va fi capabil sa limiteze accesul pentru anumite grupuri de utilizatori doar la modulele de aplicatii pentru care acestia au dreptul
  
• 
  Sistemul va fi capabil sa sustina definirea de reguli de acces la date (citire, scriere, stergere si creare) pentru diverse grupuri de utilizatori
  
• 
  Sistemul va putea interzice accesul la orice din cadrul acestuia.
  

3.2.5Cerinte de raportare

Cerintele de raportare se vor indeplini de catre sistem sau cu ajutorul unei solutii third-party cu care sistemul se va integra.

• 
  Sa se permita definirea de rapoarte, in cadrul lui sau prin intermediul unei solutii third-party, personalizate pe grupuri de utilizatori si pa categorii de continut;
  
• 
  Sa se ofere facilitate de raportare tip “Business Inteligence”;
  
• 
  Sa se ofere facilitate de generare rapoarte dinamice, rich-content pentru ecran sau imprimanta in format PDF, HTML, XLS, CSV, XML;
  
• 
  Solutia de raportare sa poata fi integrate facil in aplicatii web si s a respecte tehnologia JEE;
  
• 
  Sa permita crearea de template-uri de rapoarte cu zone flexibile ce permit ajustarea automata la adaugarea de noi elemente sau obiecte;
  
• 
  Sa permita crearea facila prin utilizarea de rapoarte predefinite de tipul: liste, cross-taburi, harti, control prin prompturi, imagini, obiecte HTML si o gama larga de grafice usor de customizat si adaptat nevoilor utilizatorilor
  
• 
  Sa ofera access la surse relationale de date de la diversii vendori precum si accesibilitatea surselor prin intermediul ODBC, JDBC si surse dimensionale.