Biologie | Chimie | Didactica | Fizica | Geografie | Informatica | |
Istorie | Literatura | Matematica | Psihologie |
Aplicatiile de mediu vor fi centralizate si implementate la nivel national, fiind accesate prin intermediul clientilor remote (technologii web in general sau „rich client” numai in cazuri speciale). Toate aplicatiile din acest proiect vor fi instalate la sediul central al ANPM deoarece aici trebuie centralizate si analizate datele introduse din centrele locale.
Trebuie facuta diferenta intre instalare fizica si accesibilitate. Toate aplicatiile care vor fi dezvoltate in cadrul proiectului trebuie sa poata fi accesate din orice locatie din reteaua SIM si eventual alte locatii interesate. Portalul public va putea fi accesat din Internet fara restrictii.
Modul de constructie a tuturor aplicatiilor de mediu si fiecareia in parte trebuie sa se bazeze pe configurarea / customizarea unor aplicatii standard.
Principalele functionalitati ale solutiilor, care trebuie implementate in contextul functionalitatii specific, a securizarii aplicatiei si a unui control strict asupra autentificarii si autorizarii utilizatorilor, vor fi:
Enrollment-ul si gestiunea actorilor externi (toate persoanele care interactioneaza cu sistemul, intern sau extern ANPM)
Gestiunea fluxurilor datelor specifice (colectare, validare, prelucrare) cu interfete adecvate fiecarui rol posibil
Gestiunea fluxurilor de autorizare (cu puncte de interactiune cu actorii externi)
Monitorizarea fluxurilor in derulare, respectiv analiza celor inchise
Generarea de rapoarte detaliate pentru analiza interna, inclusiv cu suport GIS
Generarea si publicare unor rapoarte de interes public, inclusiv cu suport GIS.
Pentru sporirea eficientei si diminuarea riscurilor, dincolo de aspectele specifice, aceste functionalitati vor fi toate implementate folosind un framework comun tuturor aplicatiilor de mediu, maximizind componenta de configurare a produselor standard utilizate in infrastructura si recurgind la customizari numai acolo unde este absolut necesar.
Fiecare aplicatie in parte va avea o arhitectura centralizata, cu o baza de date centrala. Utilizatorii vor accesa aplicatia prin intermediul unei interfete web. In figura urmatoare este reprezentata arhitectura centralizata generic a unei aplicatii:
Aceasta lista prezinta principalele componente ale solutiei:
Aplicatii standard (ECM, BPM, BI si GIS) – aceste componente trebuie sa furnizeze un nivel de functionalitate cit mai mare out-of-the-box pentru a minimiza efortul de customizare si a maximiza potentialul lor pentru viitoarele proiecte
Baza de date – trebuie avute in vedere performanta si flexibilitatea platformei, posibilitatile de extindere viitoare prin introducerea unor clustere, independenta de sitemul de operare etc.
Componente custom pe Web/Application Server – site-ul si aplicatiile sale trebuie sa beneficie de o platforma sigura si stabila, conforma cu standarde, care sa asigure cresterea aplicatiei si independenta de sistemul de operare
Configurari pe aplicatiile standard (pentru realizarea functionalitatilor specific – aici trebuie concentrat maximul de efort prin evitarea customizarilor pe cit posibil)
Business Intelligence – construirea tuturor rapoartelor necesare, prezentarea acestora, integrarea cu diverse date etc.
Enterprise Content Management – gestiunea tuturor documentelor specific aplicatiei si a datelor conexe acestora (trebuie eliminate sau minimizate datele externe documentelor; datelel se structureaza prin indexarea docuemntelor specifice
Business Process Management – furnizeaza unica platform pentru implementarea regulilor si algoritmilor aplicatiei: in afara acestuia nu se vor implementa decit interfete utilizator pure, fara interacctiuni intre ele, ele fiind orchestrate de aici
Geographical Information System – support specific in toate modulele.
La nivel logic fiecare aplicatie de mediu se va baza asadar pe un ansamblu de componente software integrate asa cum sunt figurate in diagrama urmatoare:
Solutia finala care va implementa sistemul informatic trebuie sa indeplineasca anumite caracteristici tehnice care privesc aspectele de performanta, utilizabilitate, continuitate, securitate, extensibilitate si interoperabilitate.
Sistemul trebuie sa suporte traficul public pe web-site, cit si cei 3000 de utilizatori interni ANPM; in perioadele de virf (sfirsit de perioade de raportari etc.) vor intra simultan mult mai multi utilizatori, astfel incit sistemul trebuie sa suporte minim 3000 de useri simultan logati, cu minim 300 de tranzactii simultane (200 OLTP si 100 rapoarte standard)
Arhitectura sistemului informatic se bazeaza pe accesarea sistemului in tehnologie web - fie Intranet, fie Internet.
Avand in vedere tehnologia de acces la aplicatii prin intermediul browserelor web, este important ca interfata cu utilizatorul a sistemului informatic sa respecte principiile standardadizate de utilizabilitate. Acest concept se referea la capacitatea interfetei utilizator de a fi:
Usor de folosit de catre toate categoriile de utilizatori
Intuitiva – functionalitatile oferite de catre sistem trebuie sa fie usor identificabile si accesibile
„Prietenoasa” cu browserele Internet
Sa asigure suport pentru persoanele cu dizabilitati
Sa nu existe limitari functionale in functie de browserul utilizat
Sa previna erorile de introducere date prin reguli de validare
Sa asigure asimilarea usoara a aplicatiilor prin oferirea unei interfete cit mai uniforme intre diversele componente.
Specificul activitatilor economice desfasurate de catre SIM impune asigurarea unei disponibilitati maxime sistemului (prin disponibilitate vom intelege capacitatea sistemului informatic de a fi accesibil utilizatorilor acestuia fara intreruperi).
In sistemul informatic vor fi impementate solutii care sa asigure continuitatea acestuia in situatii de:
Intreruperi neplanificate de natura hardware
Intreruperi neplanificate datorate erorilor de date
Intreruperi neplanificate datorate factorilor umani
Intreruperi neplanificate datorate erorilor de functionare a sistemului
Intreruperi planificate
Conceptul de business continuity adreseaza cerintele care trebuie indeplinite in cadrul companiei pentru a asigura continuitatea activitatilor in cazul defectelor, aparitiei unor bug-uri in aplicatie precum si in situatii de forta majora. O parte importanta a acestei arii o reprezinta componentele legate de zona de IT.
In acest sens, politica de „business continuity” a companiei va adresa si componentele de High availability, Backup and Recovery si Disaster Recovery din zona IT.
Prin “availability” vom intelege masura in care sistemul informatic in ansamblu este disponibil si accesibil utilizatorilor in conditii de performanta adecvate – astfel, sistemul informatic SIM va asigura:
Recuperarea datelor in caz de incident
Detectarea erorilor in functionarea sistemului
Operarea continua, cu minimizarea intervalelor de intrerupere a functionarii sistemului
Pentru a indeplini aceste obiective, sistemul informatic va trebui sa:
Asigure continuarea functionarii in situatia celor mai multe incidente
Sa contina functionalitati de prevenire a intreruperilor
Sa contina functionalitati de monitorizare si detectie rapida a incidentelor
Sa prezinte facilitati de recuperare rapida a datelor si starii sistemului
In acest scop, va fi implementata o arhitectura de tip “high-availability”, bazata pe configuratii software si hardware redundante.
Complementar trebuie avut in vedere solicitarea si obtinerea unui SLA adecvat din partea furnizorilor care sa asigure down-time-ul minim in caz de defecte ale aplicatiei.
Pentru protectia in caz de defecte hardware sau caderi inopinate ale aplicatiilor trebuie avuta in vedere furnizarea neintrerupta a serviciilor IT printr cerinte adecvate de redundanta la nivelul echipamentelor si prin utilizarea unei arhitecturi care sa asigure functionarea aplicatiilor si in cazul caderii unor servere.
La nivelul bazei de date se va implementa o solutie de tip cluster ce permite functionarea simultana a mai multor noduri in regim activ-activ (balansarea incarcarii pe noduri).
De asemenea, Application Server-ele si componentele tip Portal vor fi instalate in arhitecturi cluster tip activ-activ cu load-balancing astfel incit sa permita un nivel de redundanta optim in conditii de eficientizare a dimensiunii infrastructurii necesare.
In general, toate componentele importante ale sistemului vor fi instalate in clustere activ-activ (de preferat) sau fail-over (numai acolo unde este specificat in acest caiet ca acceptabil).
Implementarea unei solutii de Disaster Recovery poate avea o importanta deosebita pentru oraganizatie datorita impactului deosebit pe care il au activitatile desfasurate de aceasta.
Solutia de Disaster Recovery (DR) are obiectivul de a preveni pierderea datelor si a capabilitatilor operationale in caz de dezastru. La limita, solutia de DR poate fi utilizata si ca un nivel de HA prin comutarea utilizatorilor pe centru de DR in cazul indisponibilitatii temporare totale a centrului principal.
Mecanismul preferat pentru sincronizare datelor intre centru si DR este cel de replicare la nivel fizic (intre unitatile de stocare centralizare existente intre cele doua centre). In acest context trebuie avute in vedere urmatoarele valori pentru RTO (recovery time objective) si RPO (recovery point objective):
RTO – maxim 1 ora
RPO – maxim 10 minute.
Centrul DR va fi complet functional (inclusiv la nivelulul redundantei sistemelor) dar cu un nivel de echipare de compromis (asigurind performante ceva mai slabe decit cel principal)
Centrul DR va fi complet implementat in cadrul acestui proiect, intr-o faza finala a sa. Pe parcursul proiectului beneficiarul va comunica in timp util furnizorului locatia acestuia. Amenajarea locatiei de disaster recovery (mai putin echipamentele solicitate in acest caiet de sarcini) si asigurarea comunicatiei intre site-ul principal si cel de DR cad in responsabilitatea beneficiarului.
Copyright © 2024 - Toate drepturile rezervate