1 MINISTERUL AFACERILOR INTERNE DIRECŢIA GENERALĂ ANTICORUPŢIE APROB DIRECTOR GENERAL Comisar -şef de poliţie IONIŢĂ ALEXANDRU CĂTĂLIN DE ACORD DIRECTOR GENERAL ADJUNCT Comisar -şef de poliţie MELINTESCU OCTAVIAN SPECIFICAȚIE TEHNICĂ PRIVIND ACHIZI ȚIA SERVICIILORDE MENTENANȚĂ PENTRU SOLUȚIA SOFTWARE „MARC”
84
Embed
APROB DIRECTOR GENERAL - mai-dga.ro file1 ministerul afacerilor interne direcŢia generalĂ anticorupŢie aprob director general comisar -şef de poliţie ioniŢĂ alexandru cĂtĂlin
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
MINISTERUL AFACERILOR INTERNE
DIRECŢIA GENERALĂ ANTICORUPŢIE
APROB
DIRECTOR GENERAL
Comisar -şef de poliţie
IONIŢĂ ALEXANDRU CĂTĂLIN
DE ACORD
DIRECTOR GENERAL ADJUNCT
Comisar -şef de poliţie
MELINTESCU OCTAVIAN
SPECIFICAȚIE TEHNICĂ PRIVIND ACHIZIȚIA SERVICIILORDE MENTENANȚĂ
PENTRU SOLUȚIA SOFTWARE „MARC”
2
Cuprins
1. INFORMAȚII GENERALE ...................................................................................................................... 3
2.3. Descrierea serviciilor de mentenanță care se vor achiziționa .................................................................. 17
2.3.1. Servicii de mentenanţă evolutivă ..................................................................................................... 18
2.3.2. Servicii de mentenanţă corectivă ..................................................................................................... 19
2.4. Management de proiect ............................................................................................................................ 20
2.4.1. Cerinţe privind implementarea proiectuluide asigurare a mentenanţei evolutive şi corective a
soluţiei software MARC .................................................................................................................................. 22
2.4.2. Planul de implementare a soluțiilor de mentenanță evolutivă și corectivă ale aplicaţiei MARC .... 22
2.5. Cerinţe privind transferul de cunoștințe ................................................................................................... 24
2.6. Cerințe privind resursele umane .............................................................................................................. 24
2.6.1. Manager de proiect .......................................................................................................................... 24
2.6.3. Arhitect de sistem ............................................................................................................................ 25
2.7. Cerinţe privind garanţia şi testarea ........................................................................................................... 26
2.7.2. Cerinţe de testare .............................................................................................................................. 27
2.8. Cerinţe de recepţie cantitativă şi calitativă ............................................................................................... 28
3. ALTE MENȚIUNI ................................................................................................................................... 28
3
1. INFORMAȚII GENERALE
1.1. Introducere
Direcţia Generală Anticorupţie (DGA) a realizat şi implementat la nivelul Ministerului
Afacerilor InterneMetodologia de management al riscurilor de corupţie, aprobată prin Ordinul MAI
nr. 86/2013 privind organizarea şi desfăşurarea activităţilor de prevenire a corupţiei în cadrul
MAI,denumită în cuprinsul prezentelor specificații tehnice Metodologie. Implementarea acestui
document a presupus, în esenţă, un efort sistematic de identificare, evaluare şi ierarhizare a
riscurilor de corupţie specifice domeniilor de activitate ale instituţiei, scopul fiind reprezentat de
elaborarea şi aplicarea unor măsuri de prevenire/control adecvate vulnerabilităţii mecanismelor
existente (încorporate în structura, procedurile, regulile şi reglementările instituţiei), respectiv
monitorizarea efectelor acestora asupra posibilităţii de materializare şi a impactului riscurilor de
corupţie.
În baza Metodologiei, la nivelul fiecărui domeniu de activitate din cadrul ministerului, a fost
întocmit câte un Registru al riscurilor de corupţie, care a avut rolul de a evalua capacitatea
instituţiilor componente de a face faţă factorilor actuali sau potenţiali ce pot favoriza apariţia unor
acte de corupţie, fiind identificate şi stabilite mecanisme de monitorizarea acţiunilor întreprinse.
Având la bază Metodologia, DGA a dezvoltat în cadrul proiectului
HOME/ISEC/AG/FINEC/4000002185 – „Îmbunătăţirea capacităţii MAI de a identifica şi diminua
riscurile şi vulnerabilităţile la corupţie prin utilizarea soluţiilor IT”aplicaţia informatică MARC
(Managementul Asistat al Riscurilor de Corupţie) ce permite implementarea în sistem informatic a
produselor rezultate din aplicarea Metodologiei la nivelul MAI. Scopul dezvoltării aplicației a fost
de a asigura sustenabilitatea rezultatelor activităţilor desfăşurate la nivelul tuturor
instituţiilor/structurilor MAI în domeniul managementului riscurilor de corupţie, prin simplificarea,
standardizarea şi îmbunătăţirea calităţii datelor obţinute ori gestionate în acest cadru.
Aplicația MARC permite standardizarea modalităţilor de întocmire şi utilizare a diverselor
tipuri de documente aferente managementului riscurilor de corupție și oferă modalităţi mult mai
eficiente de analiză, dar și de monitorizare a implementării măsurilor stabilite în registrele riscurilor
de corupție ale structurilor MAI. În contextul informaţiilor disponibile pentru fiecare dintre riscurile
şi vulnerabilităţile la corupţie stocate în cadrul aplicaţiei, aplicația permite funcţionalităţi standard
pentru bazele de date (de genul: adăugare, ştergere, sortare, interogări ş.a.) și funcţionalităţi
specializate (prelucrări cantitative ori calitative, analiză statistică, includere în categorii, ierarhizare
ş.a.).
În perioada de utilizare, soluția informatică MARC s-a dovedit a fi un instrument practic de
lucru, care a facilitat activitatea de management al riscurilor de corupție, a maximizat capacitățile
de raportare, sintetizare și analiză, cu rezultate ce conduc la scăderea timpului de reacție și
rezolvarea problemelor curente privind monitorizarea riscurilor de corupţie.
În contextul asigurării sustenabilităţii investiţiei finanţate în cadrul proiectului sus-menţionat -
HOME/ISEC/AG/FINEC/4000002185, în cursul anului 2016, DGA a obţinut finanţare europeană,
în cadrul contractului de finanţare nerambursabilă nr. 9/FSIP/2016, prin Fondul pentru Securitate
Internă, pentru proiectul „Mecanisme eficiente de prevenire şi combatere a corupţiei în
administraţia publică”, Cod ROFSIP20160S5A08P01. Unul din rezultatele proiectului asumate de
DGA prevede„Optimizarea infrastructurii de utilizare a aplicaţiei MARC prin mentenanţa soluţiei
4
software …”, fapt pentru care este necesară achiziţia de servicii mentenanță(în valoare de 79.965 lei
fără TVA) pentru sistemul informatic „MARC”, în vederea asigurării funcţionalităţiicompleteşi la
parametrii tehnici optimi.
În cadrul proiectului va fi asigurată mentenanţa aplicaţiei MARC existente, implementându-
sedezvoltările software necesare pentru optimizarea şi buna funcţionare a acesteia.
Mentenanţapropusă este de tip evolutiv şi corectiv. Astfel, prin cele două tipuri de mentenanţă vor
fiasigurate atât up-date-ul pentru nevoile de optimizare, precum şi corectarea eventualelor erorisau
bug-uri ce ar putea apărea pe parcursul utilizării soluţiei informatice.
În acest fel se intenţionează atât optimizarea aplicaţiei, în funcţie de nevoile rezultate din
procesul de utilizare cât şi orice modificări ori corecţii ale soluţiei software, care îi asigură buna
funcţionare, precum: îndreptarea erorilor apărute din exploatarea acesteia, implementarea
modificărilor legislative din domeniu, modificările structurale intervenite la nivelul MAI etc.
1.2. Arhitectura funcțională a aplicației informatice MARC
Soluţia informatică este dezvoltată pe o platformă de tip portal web, astfel încât, prin
intermediul reţelei de INTRANET a MAI, este asigurat accesul la baza de date gestionată de către
DGA pentru toate stațiile de lucru conectate la rețeaua de voce-date a MAI. Utilizatorii structurilor
MAI se conectează la sistemul informatic, prin intermediul unui browser web, fără a fi nevoie de
instalarea altor programe sau module client, aplicația fiind bazată pe tehnologii web, care constituie
interfaţa utilizatorului cu un server software de baze de date de tip SQL.
Principalele caracteristici ale aplicaţiei MARC:
• Este un sistem web-based, care respectă arhitectura 3-tier, astfel:
include un server de gestiune a bazelor de date relaţionale;
include un server de aplicaţii;
este accesibilă utilizatorilor prin intermediul unui browser web (Microsoft
Internet Explorer versiunea minim 8, MozillaFirefox, Google Chrome);
• Componentele software ale sistemului sunt instalate (si rulează) într-un mediu
virtualizat;
• Oferă suport pentru lucrul a 2500 de utilizatori, dintre care 100 concurenţi;
• Rulează în cadrul unei reţele LAN şi poate fi accesată via WAN/web;
• Funcționează pe modelul unei baze de date centralizate, găzduită de serverul pentru
procesare şi baze de date;
• Oferă o interfaţă unică pentru utilizatori, customizată nevoilor și drepturilor de acces
ale fiecărei categorii de utilizatori ai Sistemului;
• Oferă mecanisme şi facilităţi de analiză şi raportare agregată a datelor;
• Include instrumente indispensabile de infrastructură software precum:
sistem de salvare şi recuperare a datelor;
platformă de virtualizarea a resurselor de procesare;
platformă de dezvoltare (software).
5
• Oferă o interfaţă centralizată (customizată) de lucru pentru administratorii
funcţionali (de business) ai Sistemului care le oferă suportul necesar configurării mediului de lucru
pentru utilizatorii finali.
• Oferă instrumente de suport al lucrului colaborativ precum:
zone de lucru comune;
instrumente tip „forum de discuţii” şi „chat room” (la nivel de facilităţi);
calendar comun de activităţi;
capabilităţi de lucru cu form-uri;
capabilităţi de lucru cu documente;
capabilităţi de flux de lucru.
• Include opţiuni/mecanisme/interfeţe de procesare (preluare din multiple
surse/prelucrare/export în diverse formate);
• Oferă suport pentru integrarea cu soluţii de semnătură electronică.
6
1.2.1. Arhitectura Software
Arhitectură software MARC – reprezentare grafică
marc.db
PortalDocument Repository
MySQL
Zmanda Enterprise
Virtualmin
PHP MyAdmin
marc.td
Liferay Portal on Apache
Virtualmin
Java
Apache HTTP Server
Eclipse IDE
Selenium HQ IDE, JUnit,
Java On Rails
MySQL
Zmanda Enterprise
PortalDocument Repository
JasperReports
MySQL Monitor Tool
Geo Server
GeoNetwork
PHP MyAdmin
marc.app.01
Apache HTTP Server
Liferay Portal on Apache
Tomcat Node 1
Virtualmin
Java
KeyTool
JasperSoft BI CE
CAS
marc.app.02
Liferay Portal on
Apache Tomcat Node 2
Virtualmin
Java
GeoServer GeoNetwork
7
Arhitectură SoftwareMARC – detaliere componente
Componente Descriere
marc.app.01
Mediu: ProductieDenumire logica: Nod 1 Server de Aplicatie
Virtualmin Unealta web de gestionare server
Apache HTTP
Server
LoadBalancer in clusterul de portal
Liferay Portal 6.2 Nodul 1 de Portal
CAS Central authentication service
Apache Tomcat Containerul web pe care ruleazaLiferay Portal
Java 1.7 Masina virtuala de Java in care ruleaza Apache Tomcat
JasperSoft BI
CommunityEdition
JasperSoft BI CommunityEdition este unul dintre cele mai raspandite
instrumente de raportare agregata in comunitatea Java si indragit de
dezvoltatori.
Keytool Componentă de stocare și manipulare a certificatelor digitale X.509.
marc.app.02
Mediu: ProductieDenumire logica: Nod 2 Server de Aplicatie
Virtualmin Unealta web pentru gestionarea serverului
Liferay Portal 6.2
(Include CAS)
Nodul 2 de Portal
Apache Tomcat Containerul web pe care ruleazaLiferay Portal
Java 1.7 Masina virtuala de Java in care ruleaza Apache Tomcat
GeoServer Server tip GIS (de procesare a datelor spatiale).
Quantum GIS Aplicația Desktop GIS.
GeoNetwork Aplicatia catalog de management a resurselor spatiale.
OpenLayers Aplicatie de vizualizare a datelor cartografice si de integrare de harti online –
dezvoltata pe baza tehnologiei.
GeoExt Librărie de instrumente java pentru dezvoltarea aplicațiilor web-GIS.
Sencha Ext JS Librărie de instrumente java pentru dezvoltarea aplicațiilor web.
8
Arhitectură Software MARC – detaliere componente
Componente Descriere
marc.db
Mediu: ProductieDenumire logica: Server baze de date
Virtualmin Unealta web pentru gestionarea serverului
MySQL Serverul de baze de date
ZmandaAmandaRecovery Soluție tip COTS (”Commercialof-the-shelf”) inteligentă, robustă și
performantă de salvare și restaurare a datelor.
MySQL Monitor Tool MySQL Monitor Tool este o componenta de monitorizare pentru
sistemul MySQL.
PhpMyAdmin Interfata web pentru administrarea bazei de date MySQL
marc.td
Mediu: Testare/dezvoltare Denumire logica: Server de testare/dezvoltare
Virtualmin Unealta web pentru gestionarea serverului
Apache HTTP Server Server web
Liferay Portal 6.2 Portal
CAS Central authentication service
Apache Tomcat Container web
Java 1.7 Masina virtuala Java
MySQL Serverul de baze de date
ZmandaAmandaRecovery Soluție tip COTS (”Commercialof-the-shelf”) inteligentă, robustă și
performantă de salvare și restaurare a datelor.
phpMyAdmin Interfata web pentru administrarea bazei de date MySQL
Eclipse Eclipse este un mediu de dezvoltare tip IDE complet si foarte
performant in comunitatea Java.
Subclipse Subclipse permite gestiunea eficienta a versiunilor de cod.
Selenium HQ IDE
9
Arhitectură Software MARC – detaliere componente
Componente Descriere
JUnit
Redmine Redmine permite raportarea bug-urilor intr-o maniera foarte eficienta.
Junit JUnitfaciliteaza testarea (codului sursa) de catre dezvoltatori intr-o maniera
facila.
Java on Rails Java on Rails este un framework de dezvoltare foarte raspandit in comunitatea
Java si indragit de dezvoltatori.
JasperSoft BI
CommunityEdition
JasperSoft BI CommunityEdition este unul dintre cele mai raspandite
instrumente de raportare agregata in comunitatea Java si indragit de
dezvoltatori.
GeoServer Server tip GIS (de procesare a datelor spatiale).
Quantum GIS Aplicația Desktop GIS.
GeoNetwork Aplicatia catalog de management a resurselor spatiale.
OpenLayers Aplicatie de vizualizare a datelor cartografice si de integrare de harti online –
dezvoltata pe baza tehnologiei.
GeoExt Librărie de instrumente java pentru dezvoltarea aplicațiilor web-GIS.
SenchaExt JS Librărie de instrumente java pentru dezvoltarea aplicațiilor web.
Keytool Componentă de stocare și manipulare a certificatelor digitale X.509.
10
1.2.2. Arhitectura Hardware
11
Arhitectura Hardware
COMPONENTA
DESCRIERE
Virtual Machine 1 Hostname: marc.app.01
IP DEV: Adresă IP
IP PROD: Adresă IP
RAM: 8 GB
Proc: 2 cores
HDD SO (rootvg alocat pe storage rapid): 50 GB
STORAGE DOCUMENTE MARC mapat la /storage (storagevg alocat pe
storage lent): 500GB
SO: CentOS 6.4 Final
Virtual Machine 2 Hostname: marc.app.02
IP DEV: Adresă IP
IP PROD: Adresă IP
RAM: 6 GB
Proc: 2 cores
HDD SO (rootvg alocat pe storage rapid): 50GB
STORAGE DOCUMENTE MARC mapat la /storage (storagevg alocat pe
storage lent): 500GB
SO: CentOS 6.4 Final
Virtual Machine 3 Hostname: marc.db
IP DEV: Adresă IP
IP PROD: Adresă IP
RAM: 6 GB
Proc: 2 cores
HDD SO (rootvg alocat pe storage rapid): 50 GB
STORAGE BAZA DE DATE MARC mapat la /db (storagevg alocat pe
storage lent): 200GB
SO: CentOS 6.4 Final
Virtual Machine 4 Hostname: marc.td
IP DEV: Adresă IP
IP PROD: Adresă IP
RAM: 6 GB
Proc: 2 cores
HDD SO (rootvg alocat pe storage rapid): 50 GB
SO: CentOS 6.4 Final
12
1.3. Descrierea principalelor module/funcţionalităţi ale aplicației MARC:
Aplicația este organizată în două secțiuni:
Secțiunea publică, ce poate fi accesată fără ca utilizatorul să fie autentificat. Această secțiune
poate fi accesată de către orice angajat al MAI care beneficiază de o stație de lucru conectată la
rețeaua de INTRANET a MAI.
Aplicaţia informatică MARC poate fi accesată, prin tastarea în browser-ul de internet a
adresei a adresei IP, acţiunea fiind urmată de apăsarea tastei ENTER.
De regulă, în această secțiune, apar informații publice: articole, informări, calendar activ de
evenimente etc.; aplicația permite, de asemenea, utilizarea secțiunii publice pentru configurarea
unuia sau a mai multor chestionare active ce pot fi utilizate pentru realizarea mult mai facilă a unor
sondaje de opinie (pentru a estima, de exemplu, percepția nivelului de corupție).
Secțiunea privată - această secțiune poate fi accesată doar dacă utilizatorul s-a autentificat; în
această secțiune se desfășoară întregul proces de management al riscurilor de corupție.
Pentru a se autentifica în aplicația MARC, utilizatorii structurilor MAI beneficiază de o
interfaţă de acces, prin intermediul unui browserweb, fără a fi nevoie de instalarea altor programe
sau module client. Astfel, după accesarea aplicației MARC (tastarea în browser-ul de internet a
adresei IP), un utilizator se poate autentifica, prin accesarea butoanelor ori
(pasul 1), urmate de introducerea numelui de utilizator (pasul 2) şi a parolei (pasul 3),
respectiv de apăsarea acțiunii (pasul 4).
Figura 1 – accesul în aplicaţia MARC
13
1.3.1. Categorii de utilizatori ai aplicației
Aplicația are definite trei categorii de utilizatori, în funcție de rolurile și responsabilitățile
fiecăruia:
a) Administratorii Centrali (AC): sunt utilizatori cu rolul de administrare a aplicaţiei MARC,
desfăşurându-şi activitatea în structura specializată a DGA (Serviciul Studii și Proiecții
Anticorupție).
Utilizatorii cu acest rol au acces la toate funcționalitățile de administrare a aplicației, având
drepturi de a gestiona structurile organizatorice în aplicație și utilizatorii de la nivelul
întregului MAI. Administratorii Centrali (AC) pot aproba şi defini diferite înregistrări în
sistem (Activități Vulnerabile, Sarcini, Documente, Riscuri și Cauze din domeniul
reglementărilor) și sunt notificați cu privire la activitățile majore în aplicaţie.
b) Administratorii Teritoriali (AT): sunt ofițerii de prevenire din cadrul structurilor
teritoriale ale DGA. Utilizatorul cu acest rol poate administra structurile organizatorice și
utilizatorii definiţi în toate organizaţiile din județul său. De asemenea, poate vizualiza
documentele asociate incidentelor de integritate la nivel național şi asocia riscuri
incidentelor definite în cadrul structurilor organizatorice pe care le administrează. AT
primește, totodată, notificări cu privire la întreaga activitate realizată de utilizatorii din
județul respectiv.
c) Membrii Grupurilor de lucru pentru prevenirea corupției: în secțiunea privată, aplicația
MARC este concepută pentru a fi folosită de către fiecare responsabil din Grupul de lucru
pentru prevenirea corupţiei, prin intermediul unui cont de acces şi al unei1 parole
individuale.
1.3.2. Module/funcţionalităţi (de bază) ale aplicației MARC:
Soluţia informatică (Sistemul/Aplicaţia) se constituie din următoarele module (funcţionale):
1.3.2.1. Modulul ”Management al Riscurilor de Corupţie”
Accesarea acestui modul se realizează doar de către utilizatorii stabiliți la nivelul Grupurilor
de lucru pentru prevenirea corupției (Șef al Grupului/Consilier sau Membru al Grupului de Lucru).
În cadrul acestui modul, se regăsesc principalele funcționalități ale aplicației, prin care se
alimentează întreaga bază de date privind riscurile de corupție. Etapele ce se parcurg în cadrul
acestui modul sunt următoarele:
Pregătirea activităţilor de management al riscurilor de corupţie (modulul ANEXA 1);
Identificarea şi descrierea riscurilor de corupţie (modulele ANEXA 2, ANEXA 3, ANEXA
4 şi ANEXA 5);
Evaluarea riscurilor de corupţie (se completează în modulul ANEXA 4, utilizând machetele
de evaluare);
Determinarea şi implementarea măsurilor de prevenire/control al riscurilor de corupţie
(ANEXA 4 și ANEXA 10);
Monitorizarea şi revizuirea riscurilor de corupţie (ANEXA 4).
1 Aplicația permite, totuși, ca informația să fie implementată de către un singur utilizator la nivelul structurii, căruia îi pot fi stabilite responsabilități cu privire la toate domeniile gestionate la nivelul unei structuri
14
Mai jos, este descris schematic fluxul de lucru în aplicație, marcat prin anexele pe care membrii
grupului de lucru trebuie sa le realizeze, iar în Anexa 3 a prezenteispecificaţii tehnice sunt
descrise modulele și funcționalitățile aferente fiecărei etape. De asemenea, în Anexa 2, sunt
prezentate cazurile de utilizare a aplicaţiei informatice MARC.
1.3.2.2. Modulul ”Chestionare”
Aplicaţia include un modul de tip ”Chestionare”, care permite interogarea utilizatorilor pe diverse
teme. Acest modul oferă următoarele capabilităţi:
Modulul poate prezenta mai multe chestionare active la un moment dat în interfaţa
vizitatorului.
Modulul permite definirea chestionarelor doar de către administratorii centrali.
Chestionarele pot conţine întrebări de mai multe tipuri cum sunt: cu o singură variantă de
răspuns, cu variante multiple de răspuns, cu răspuns obligatoriu sau opţional.
Chestionarele pot prezenta sau nu vizitatorului o statistică cu răspunsurile date până în acel
moment de alţi vizitatori.
Modulul permite exportul statisticilor de răspuns provenite de la unul sau mai multe
chestionare.
Chestionarele pot fi activate ori dezactivate sau pot fi programate să aibă o perioadă
specificată de valabilitate.
Chestionarele pot fi programate să apară în interfaţă la o dată anume din viitor.
15
1.3.2.3. Modulul ”Newsletter”
Aplicaţia include un modul de tip ”Newsletter” care permite abonarea/dezabonarea la/de la
ştirile trimise de Sistem şi crearea şi distribuirea de newsletter-e. Acest modul oferă următoarele
capabilităţi:
Abonaţii pot să îşi gestioneze singuri opţiunea de a primi sau nu newsletter de la Sistem.
Modulul oferă un editor avansat de tip MS Word pentru creare a newsletter-elor.
Atunci când se trimite un newsletter din modul, tot abonaţii activi primesc newsletter-ul, administratorul neavând posibilitatea să selecteze un set restrâns de destinatari.
Modulul nu permite adăugarea sau eliminarea manuală a abonaţilor de către un administrator.
1.3.2.4. Modulul ”Administrare”
Aplicaţia include un modul de”Administrare” care permite utilizatorilor Sistemului MARC
cu profil de administrator central accesarea unei interfeţe dedicate pentru realizarea (în principal a)
operaţiilor de căutare şi listare, adăugare, modificare, ştergere pe obiectul/obiectele selectate,
precum şi gestionarea operaţiilor de backup automate/manuale a bazei de date. Acest modul
cuprinde:
administrarea utilizatorilor şi a drepturilor asignate (pentru administratorii teritoriali şi
centrali);
gestionarea bazei de cunoştinţe (Help) de către administratorii centrali;
administrarea nomenclatoarelor aplicaţiei de către administratorii centrali;
gestionarea jurnalelor aplicaţiei de către administratorii centrali;
administrarea job-urilor de backup de către administratorii centrali;
raportarea periodică a detaliilor privitoare la accesul în sistem al utilizatorilor prin
intermediul unui sub-modul de ”Audit”;
realizarea de rapoarte cu privire la informațiile din baza de date.
1.3.2.5. Modulele “Rapoarte” și ”Indicatori performanţă”
Utilizând modulul de rapoarte al aplicației, pot fi realizate sinteze ale măsurilor aplicate ori
ale celor suplimentare propuse pentru unitățile de muncă ale structurilor MAI, toți membrii
grupurilor de lucru putând fi informați de activitatea desfășurată în domeniul lor de activitate, la
nivelul întregii țări.
De asemenea, soluţia software permite obţinerea de rapoarte de monitorizare cu privire la
îndeplinirea responsabilităţilor de către membrii Grupurilor de lucru pentru prevenirea corupției și
responsabilii de risc, comparând activităţile planificate cu cele ce au fost realizate, pentru un orizont
temporal prestabilit şi la nivelul fiecărei structuri cărora le-au fost alocaţi utilizatori.
Aplicația păstrează, de asemenea, un istoric al oricăror modificări din baza de date (de
exemplu valorile alocate evaluărilor riscurilor de corupție), măsuri cu termenul depășit, incidente de
integritate produse într-un anumit orizont temporal etc., informația fiind utilizată pentru producerea
de rapoarte definite, rapoarte de audit etc.
16
2. SERVICII SOLICITATE
2.1. Scop
Scopul contractului îl constituie achiziția serviciilor de mentenanță evolutivă și corectivă ale
componentelor software ale aplicației informatice MARC, pentru a creşte uşurinţa în exploatare și
performanţele sistemului MARC, ca urmare a cerințelor de extindere solicitate la nivelul proceselor
operaționale specifice.
Autoritatea contractantă doreşte ca serviciile de mentenanță evolutivă și corectivă furnizate să
fie însoţite de servicii de implementare şi de management de proiect de calitate, care să garanteze
atingerea cu succes a obiectivelor de dezvoltare a soluţiei software.
Ofertantul va avea o abordare metodologică asupra întregului proces de implementare şi va
descrie în cadrul ofertei sale modul în care intenţionează să urmărească derularea proiectuluide
asigurare a mentenanţei soluţiei software, prezentând un grafic de implementare (a se vedea cap.
2.4.- Management de proiect).
2.2. Premize
Ofertanţii vor ţine cont la întocmirea ofertelor de următoarele premize:
Ofertanțiivor avea responsabilitatea implementării complete a soluțiilor de mentenanță a
aplicaţiei software MARC, care să respecte toate cerinţele exprimate în prezentul document
şi să includă toate licenţele software şi modulele funcţionale necesare rulării acestora;
Ofertanțiivor îndeplini toate cerinţele exprimate în prezentul document, în conformitate cu
şi prin implementarea bunelor practici din domeniu, urmărind pe cât posibil promovarea
celor mai noi tehnologii din domeniile informatice vizate de sistem;
Ofertanţii vor avea în vedere caracteristicile componentelor software detaliate în prezentul
document, fiind necesară dezvoltarea şi detalierea lor în cadrul ofertei. Ofertanţii vor dovedi
indeplinirea cerinţele tehnico-funcţionale menţionate în acest document,prezentând
documentele electronice oficiale de tehnologie/produs ale producătorilor tuturor
componentelor software incluse/descrise în ofertă sau făcând referinţe (link-uri web) către
site-urile oficiale ale producătorilor componentelor în secţiunea unde sunt prezentate aceste
tehnologii/produse; Autoritatea Contractantă îşi rezerva dreptul de a verifica legitimitatea
documentelor electronice oficiale de tehnologie/produs incluse sau referite de Ofertanţi în
oferte;
Datorită faptului că există o multitudine de soluţii software pentru asigurarea mentenanței
evolutive și corective ale aplicației MARC, fiecare având dependinţe şi caracteristici
specifice, prezentul document defineşte specificaţiile minime, de bază, ale acestor
servicii.Caracteristicile detaliate ale modificărilor funcționale ale aplicației vor fi stabilite, de
comun acord, în cadrul şedinţelor de analiză şi proiectare,prevăzute după încheierea
contractului de prestări servicii(a se vedea cap. 2.4. Management de proiect);
17
Ofertantul este direct răspunzător de funcţionarea la cheie a aplicaţiei MARC, după
implementarea soluțiilor de mentenanță software pe care le oferă. Astfel, în cazul în care,
pentru îndeplinirea cerinţelor din prezentaSpecificaţie tehnică, este nevoie de suplimentarea
anumitor componente software/licenţe/module, Ofertantul le va include în oferta tehnică şi
financiară. Orice completări de licenţe sau module funcţionale software care se vor dovedi
necesare în perioada de implementare (datorate detaliilor tehnice finale stabilite de comun
acord la şedinţele de lucru) se vor face de către Contractant, fără costuri suplimentare pentru
Beneficiar.
Toate componentele software trebuie ofertate în ultima versiune existentă la producător.
Ofertanţii vor prezenta detaliat şi vor argumenta în ofertă:
Modul de licenţiere al tuturor componentelor software ofertate, pentru a se evidenţia felul în
care schema de licenţiere propusă acoperă cerinţele prezentului proiect;
Numărul licenţelor software grupate pe tipuri de licenţe.
Locaţia de livrare este sediul Autorităţii Contractante, Bucureşti, şos. Olteniţei nr. 390A,
sector 4. Componentele soluţiei software prin care se asigură menenanţa aplicaţiei MARC vor fi
livrate, instalate şi configurate la aceasta locaţie de către personalul Contractantului. Eventualele
cheltuieli de logistică aferente etapei de livrare şi instalare a produselor software vor fi suportate de
Contractant.
Sediul operaţional pentru acest proiect este cel alAutorităţii Contractante, Bucureşti, şos.
Olteniţei nr. 390A, sector 4.
2.3. Descrierea serviciilor de mentenanță care se vor achiziționa
Mentenanţa software reprezintă una dintre fazele procesului de dezvoltare software, ce urmează
realizării şi lansării în exploatare a unui sistem software. În cadrul acestei faze, se operează
modificări asupra sistemului software pentru a corecta defecte, pentru a extinde setul de
funcţionalităţi oferite de acesta sau pentru a implementa optimizări de natură să îmbunătăţească
peformanţa sistemului şi calitatea serviciilor oferite utilizatorilor săi.
Contractantul va presta următoarele tipuri de servicii:
Mentenanţă evolutivă (adaptivă) - reprezintă procesul prin care se aduc modificări asupra
sistemului software pentru îmbunătăţirea funcţionării sistemului, pentru a răspunde unor noi
cerinţe din partea beneficiarilor sistemului, ce ar putea reprezenta
extinderi/adaptări/modificări ale unor funcţionalităţi existente ori implementarea unor noi
funcţionalităţi în sistem.
Mentenanţă corectivă - reprezintă procesul prin care se aduc modificări asupra sistemului
software pentru a corecta probleme de funcţionare - defecte – descoperite în timpul
exploatării;
Servicii de instalare și configurare
Servicii de testare a soluției în contextul mentenanței corective și evolutive
Servicii de garanție
Pe timpul derulării activităților de mentenanță, contractantul are obligaţia să presteze
următoarele intervenţii:
Asistență și suport pentru menținerea în stare corectă de funcționare a tuturor modulelor
componente ale aplicației software MARC;
18
Asistență pentru utilizarea corectă a aplicației;
Soluționarea/eliminarea bug-urilor/erorilor identificate în timpul utilizării aplicației;
Actualizarea documentației tehnice (manuale de administrare, utilizare, documentații de
instalare, configurare) în urma modificărilor/corecțiilor operate la nivelul aplicației;
Monitorizarea și verificarea periodică a aplicației;
Instalarea de noi versiuni ale aplicațiilor în urma efectuării de corecții, modificării unor
funcționalități sau implementarea de noi funcționalități;
Aplicarea unei politici adecvate de securitate, prevenirea accesului neautorizat la date;
Verificarea (la solicitarea beneficiarului) a valorilor normale ale parametrilor de functionare
(consistenta bazelor de date, viteza de raspuns, diverse optimizari in functie de necesităţi);
Asistență și suport în arhivarea electronică a documentelor aferente soluției software
MARC;
Asistență și suport în definirea și implementarea de noi fluxuri de lucru;
Actualizări ale fluxurilor de lucru şi ale parametrilor tehnici ai aplicaţiei informatice
MARC;
Actualizarea, împreună cu beneficiarul, a politicilor/procedurilor de backup a bazei/bazelor
de date și a aplicațiilor componenete;
Mentenanță rapoarte existente la nivelul aplicației, asistența în dezvoltarea și publicarea de
noi rapoarte;
Configurarea setărilor de securitate pentru a asigura protecția și buna funcționare a
sistemului;
Testarea sistemului ca urmare a corecțiilor, modificărilor/extinderilor efectuate asupra
functionalitatilor component;
Informarea si instruirea utilizatorilor cheie cu privire la actualizările aplicaţiei, respectiv
furnizarea de explicații ad-hoc pe zone neasimilate în totalitate de către reprezentanții
Autorităţii Contractante.
Identificarea eventualelor probleme apărute în funcționarea produselor software comerciale
(COTS), respectivreinstalarea/reconfigurarea/readucerea în stare de funcționare a produselor
software COTS, în scopul asigurării bunei funcționări a aplicației MARC;
Instalarea și configurarea de programe de corecție (patch, fix-packetc) publicate de către
producător aferente produselor software din arhitectura MARC, atunci când situația o
impune.
2.3.1. Servicii de mentenanţă evolutivă
Serviciile de mentenanță evolutivă sunt activități de dezvoltare a unor noi funcționalități ale
sistemului informatic, în vederea satisfacerii solicitărilor beneficiarului, cu reguli de business noi
sau modificate, precum și alte adaptări datorate modificării cadrului legislativ, administrativ etc.
Mentenanţa evolutivă va permite Autorităţii Contractante să dezvolte noi funcţionalităţi sau
adaptarea/extinderea funcţionalităţilor existente, astfel încât sistemul să răspundă mult mai bine
aşteptărilor utilizatorilor săi.
19
În Anexa 1 a prezentului documenteste este prezentată lista funcţionalităţilor ce se doreşte a fi
adăugate/modificate de către Autoritatea Contractantă, în cadrul aplicației informatice MARC,
aceasta urmând a fi detaliată, după semnarea contractului, de comun acord cu câştigătorul achiziţiei
serviciilor de mentenanţă. Contractantul va identifica soluțiile de dezvoltare a aplicației MARC și le
va transmite în vederea analizei către echipa de management a beneficiarului, înainte de faza de
dezvoltare, testare şi implementare a funcţionalităţilor noi.
Lista prezentată în Anexa 1 nu este exhaustivă, detalierea tehnico-funcţională a dezvoltărilor
software necesare și a funcţionalităţilor ce vor face obiectul mentenanței evolutive urmând a se
finaliza în cadrul etapei de analiză şi proiectare a serviciilor de mentenanță ale aplicaţiei
informatice MARC, în conformitate cu prevederile pct. 2.2. - Premise, respectiv ale cap. 2.4.
Management de proiect.
Fiecare activitate aferentă acestui tip de mentenanță se va consemna în ”Raportul lunar de
mentenanță” și se vor preciza cel puțin: modificarea/modificările solicitate, rezultatele analizei
cerințelor, modul și timpul de dezvoltare a noilor funcționalități sau a celor existente, precum și
Se vor include în oferte servicii de garanţie pentru dezvoltările software realizate în perioada
contractuală cu privire la aplicaţia informatică MARC după cum urmează:
Toate componentele şi subcomponentele proiectului de tip COTS (”Commercialoff-the-
shelf”) vor avea o perioadă de suport (actualizări) de la producător de 24 luni de la data de
acceptanţă a serviciilor de mentenanță.
Perioada de garanţie pentru toate configurările şi dezvoltările software din cadrul
componentelor şi sub-componentelor software va fi de 24 luni de la data de acceptanţă a
aplicaţiei.
Serviciile de garanţie oferite vor include minim următoarele:
Diagnosticarea, izolarea şi remedierea defectelor software semnalate de către Autoritatea
Contractantă;
Asistenţa cu instalarea de actualizări şi noi versiuni de programe puse la dispoziţie de către
producătorii de software tip COTS inclus în cadrul ofertei de mentenanță a sistemului MARC,
care vor putea fi aplicate, fără sa afecteze funcţionarea sistemului sau să necesite noi dezvoltări
ale componentelor sistemului;
Asistenţa acordată Autorităţii Contractante pentru aplicarea corecţiilor ca urmare a
remedierii defectelor semnalate.
Serviciile de garanţie software din cadrul proiectului de asigurare a mentenanţei evolutive şi
corective a soluţiei software MARC vor fi disponibile în toate zilele lucrătoare (8x5) prin
intermediul unui sistem de helpdesk şi trebuie să garanteze remedierea defectelor software
semnalate de Autoritatea Contractantă, conform următorului tabel de gravitate (SLA):
Nivel de
gravitate Descriere
Reacţie iniţială
a
Contractantului
(ore)
Timp total de
soluţionare a
defectului
software
(zile lucrătoare)
1 Defect major, sistemul nu este funcţional 2 1
2 Defect mediu, unele funcţii sau
componente ale sistemului nu sunt
funcţionale
4 2
3 Defect minor, unele funcţii sau
componente ale sistemului sunt afectate
dar funcţionale
8 4
Ofertanţii vor descrie în oferte planul detaliat privind garanţia software asigurată în cadrul
proiectului de asigurare a mentenanţei evolutive şi corective a soluţiei software MARC.
27
2.7.2. Cerinţe de testare
Testarea Sistemului presupune verificarea faptului că soluţia informatică ce se va implementa este
funcţională în întregime şi toate componentele funcţionează, conform specificaţiilor de
implementare.
Scenariile de testare vor fi întocmite împreună cu echipa desemnatăla nivelul Autorităţii
Contractante. Testele standard de punere în funcţiune se vor efectua în prezenţa reprezentanţilor
Autorităţii Contractante şi constau în identificarea şi verificarea cantitativă şi calitativă a
componentelor.
Contractantul trebuie să prezinte scenariile/procedurile de testare per componentă şi sistem
integrat (inclusiv cele de securitate) şi procedura de acceptanţă pe care o propune spre folosire în
cadrul derulării contractului. Autoritatea Contractantă poate să propună și alte scenarii de testare a
soluției software.
Teste preliminare:
Autoritatea Contractantă va realiza împreună cu reprezentanţi ai Contractantului teste asupra
tuturor componentelor software, în conformitate cu instrucţiunile de instalare şi folosire.
Criteriul de succes îl reprezintă trecerea tuturor testelor şi verificărilor recomandate de
producătorul componentelor software.
Teste operaţionale:
Contractantul va realiza şi parcurge testele pe întregul Sistem şi pe componentele acestuia,
în conformitate cu Planul de Teste,întocmit de către acesta și agreat de Autoritatea
Contractantă.
Autoritatea Contractantă (asistată de către reprezentanţi ai Contractantului) va parcurge
ulterior testele pe întregul Sistem şi pe componentele acestuia, în conformitate cu Planul de
Teste realizat de către acesta şi agreat de Autoritatea Contractantă, până ce rezultatele
testelor vor dovedi funcționarea tuturor componentelor Sistemului.
Planul de testare va cuprinde cel puţin următoarele tipuri de teste:
- Testare unitară – se verifică în întregime logica individuală a fiecărei componente, se
verifică respectarea cerinţelor funcţionale evidenţiate în documentele de Analiza şi
Proiectare. Criteriu de succes – componenta trece toate testele funcţionale.
- Testarea sistemului integrat – se verifică faptul că fiecare interfaţă între componente
funcţionează corect din punct de vedere al consistentei datelor, al constrângerilor de timp,
al validărilor de date şi al gestiunii erorilor. Criteriul de succes – Toate grupurile de
componente testate trec toate testele de interfaţare.
- Testarea de stres – se verifică faptul că toate componentele sistemului şi sistemul ca un
întreg sunt capabile să gestioneze cantităţile cerute de date şi să răspundă numărului cerut
de utilizatori. Se vor defini limitele din punct de vedere al volumului de date, al numărului
de utilizatori şi al numărului de evenimente după care nivelul de răspuns se deteriorează.
Criteriul de succes: sistemul ca întreg este capabil să servească numărul cerut de utilizatori
28
şi să răspundă la cantitatea cerută de date. În situaţiile în care sistemul se blochează, nu
trebuie să se piardă date critice, unde este cazul operaţiile sunt efectuate tranzacţional.
- Testarea de securitate - împreună cu beneficiarul se vor defini testele de securitate.
Testele se vor face inclusiv pe întregul sistem funcţional.
Planul detaliat de testare, însoţit de scenariile de testare, va fi realizat de către Contractant şi
aprobat de Autoritatea Contractantă după etapa de analiză şi proiectare din implementarea
proiectului de asigurare a mentenanţei evolutive şi corective a soluţiei software MARC.
2.8. Cerinţe de recepţie cantitativă şi calitativă
Recepţia cantitativă şi calitativă a serviciilor de mentenanță a soluţiei informatice MARC va fi
efectuată la Autoritatea Contractantă, de către specialiştii Beneficiarului (comisia de recepție),
împreună cu reprezentanţii Contractantului. Rezultatele se vor consemna în procesul–verbal de
recepţie cantitativ - calitativă.
Recepţia cantitativă şi calitativă se va constitui în acceptanţa serviciilor de mentenanță şi va
cuprinde toate procedurile de testare (propuse de Contractant şi aprobate de Beneficiar, cât şi cele
propuse de Beneficiar) cu privire la fiabilitatea dezvoltărilor software aduse aplicaţiei MARC, cât
şi verificarea codului sursă în vederea respectării recomandărilor privind Cod curat (Clean code).
Acceptanța finală va fi acordată numai după ce Beneficiarul a verificat toate condițiile de
funcționare ale componentelor software care au făcut obiectul serviciilor de mentenanță prestate și
toate fluxurile operaționale/cazurile de utilizare cuprinse în scenariile de test sunt funcționale, iar
cerințele de performanță sunt îndeplinite.
3. ALTE MENȚIUNI
Achiziția de componente hardware sau echipamente nu face obiectul acestei specificații tehnice.
Pentru îndeplinirea cerinţelor acesteispecificaţii tehnice, Autoritatea Contractantă va pune la
dispoziţia Contractantului întreaga documentaţie tehnică a sistemului MARC, precum și accesul la
codul sursă și bazele de date ale aplicației MARC.
Contractantul trebuie să utilizeze documentaţia oferită de Autoritatea Contractantă numai în
scopul contractului, pentru îndeplinirea cerinţelor prezentei specificații tehnice.
La expirarea/terminarea contractului, contractantul trebuie să restituie Beneficiarului toate
resursele pe care le-a primit de la acesta, în condiţiile în care au fost predate (documentaţii tehnice,
alte documente etc.).
Toate drepturile patrimoniale de autor,drepturile de proprietate intelectuală şi de utilizare asupra
codului sursă şi a tuturor operelor (produselor) create de către Contractant sau membrii asocierii, pe
parcursul prestării serviciilor achiziționate prin această Specificaţie tehnică se transferă către
Autoritatea Contractantă şi vor rămâne în proprietatea exclusivă a beneficiarului.
Contractantul este responsabil pentru toate vătămările persoanelor sau proprietăţii care survin ca
rezultat al neglijenţei sale şi trebuie să ia măsuri preventive corespunzătoare privind securitatea şi
sănătatea in munca conform prevederilor legale, a personalului propriu şi a proprietăţii terţilor. În
29
plus, Contractantul este responsabil de toate documentațiile livrate şi serviciile prestate până la
finalizarea, recepţia şi acceptarea întregii activităţi de prestare a serviciilor.
Contractantul trebuie să se conformeze tuturor revizuirilor, completărilor şi modificărilor
oricăror legi şi reglementări la nivel european, naţional și normelor interne MAI aplicabile care sunt
în vigoare la data contractului şi care afectează prestarea serviciilor.
Serviciile de mentenanţăevolutivă şicorectivă prestate deContractant fac obiectul recepţiei de
către reprezentanţii autorizaţi ai Autorităţii Contractante.
Transportul la şi de la locurile unde sunt instalate componentele sistemului MARC a
personalului Contractantului sunt în responsabilitatea exclusivă a Contractantului şi se vor realiza
cu mijloace de transport ale acestuia.
Reprezentantul (reprezentanţii) Contractantuluitrebuie să participe la toate întâlnirile solicitate
de către Beneficiar pentru efectuarea de inspecţii, discuţii, coordonarea şi evaluarea stadiului şi
modului de prestare a serviciilor prevăzute în specificaţia tehnică. Aceste întâlniri vor fi ţinute cu
frecvenţa apreciată ca fiind necesară de către Beneficiar.
Contractantul este responsabil pentru asigurarea tuturor materialelor/consumabilelor necesare
pentru realizarea serviciilor de mentenanţă.
30
Anexa 1 Lista de modificări funcționale ale aplicației informatice MARC
Funcționalități generale
G01 Optimizarea aspectului general al aplicaţiei Optimizarea grafică a culorilor taburilor, dimensiunilor butoanelor, caracterelor folosite în toate modulele
aplicaţiei.
G02 Motor de căutare avansată şi filtre de ordonare Dezvoltarea tuturor motoarelor de căutare avansată prin introducerea de criterii de selecţie multiplă pe informaţiile disponibile în baza de date (de ex.: judeţ, structură, domeniu de activitate etc.). Posibilitatea de a filtra/ordona informaţiile (de ex.: A-Z sau Z-A, crescător-descrescător etc.) din orice câmp.
G03 My sites În ecranul principal al membrilor grupurilor de lucru (MGL) să fie eliminat butonul “My Sites” cu cele două opţiuni. Afişarea celor două opţiuni să fie reprezentantă separat sub titulatura: Secțiune publică şi Secțiune privată.
G04 Mod afișare structuri organizatorice pentru Administratorul Teritorial Modul organizare a listei de structuri afișate utilizatorului AT să fie similar celui pentru utilizatorul cu rol de AC. Prima dată se vor afișa structurile de nivel 3 (Structurile subordonate), spre exemplu “Instituţia prefectului”, care va trebui să includă structurile subordonate, spre exemplu “Serviciile publice comunitare”, “Regim permise de conducere şi înmatriculare a vehiculelor” şi “Serviciile publice”, “Serviciile comunitare”, “Paşapoarte” etc. Cu alte cuvinte, afișarea listei structurilor să fie restrânsă la nivelul 3, iar la click pe o structură, să fie afișate structurile ei copil de la nivelul 4 ș.a.m.d..
G05 Categorisire Să se modifice aplicația astfel încât să se poată selecta și un Sub-Sub-Domeniu de Activitate. Acum este posibil doar Domeniu de Activitate și Sub-Domeniu de activitate. Optimizarea modului de afişare a domeniilor şi subdomeniilor de activitate, evidenţiate pe coduri de culori. Permiterea ştergerii/inactivării unui domeniu sau subdomeniu de activitate. Blocarea la asociere pe un domeniu de activitate dacă există subdomeniu.
G06 Auditarea Căutarea după evenimente şi auditare să se facă și după organizație. Mai jos o captură de ecran cu felul în
care este acum implementat modulul de audit.
31
Modulul audit trebuie să conţină şi date legate de accesările pe care le face un utilizator. Informaţiile conţinute de acest modul vor fi arhivate lunar (în ultima zi a lunii), pentru aceeaşi lună a anului precedent. Informaţiile ce vor fi păstrate pentru afişare în acest modul nu vor fi mai vechi de un an.
G07 Adăugare de noi roluri pentru utilizatori Se dorește adăugarea de noi roluri:
A. “Responsabil Risc”, care să poată face următoarele acțiuni:
- completare Anexa 2;
- primire Notificări Incidente și Sarcini din Anexa 10;
- Completare Raport anual de evaluare a masurilor din registru.
B. „Consilier central”, care să poată face următoarele acțiuni:
- vizualizarea documentelor întocmite de GL din structurile copil;
- primire Notificări pentru acţiunile realizate de MGL din structurile copil;
- Raport anual de evaluare a masurilor din registrele întocmite de GL din structurile copil;
- Anexa 10 care să includă toate anexele 10 întocmite de GL din structurile copil.
G08 Utilizatori Este dublat „Detalii” la utilizator. Trebuie eliminat unul dintre câmpurile „detalii”. Trebuie adăugată funcţionalitatea de adăugare multiplă pe un utilizator a mai multor judeţe sau structuri. Introducerea unei funcţionalităţi care să permită preluarea informaţiilor introduse/anexelor create de un utilizator de către un utilizator nou.
G09 Newsletter Analizarea oportunităţii de a activa/configura newsletter-ul.
G10 Amendare conţinut Aplicaţia trebuie să permită oricărui utilizator de a amenda conţinutul anumitor înregistrări din baza de
date prin butoane dedicate acestei funcţionalităţi (de exemplu descrierea ameninţării/riscului de corupţie).
G11 Verificare adăugare conţinut Orice adăugare în baza de date să fie însoţită de o verificare automată a informaţiilor deja existente, pentru
evitarea adăugării unor duplicate, însoţite de mesaje de eroare.
32
Documente PDF
P01 Adăugare footer şi header în toate documentele PDF generate de aplicație În orice document pe care aplicația îl generează trebuie introdus în header o serie de câmpuri dinamice (de ex.: structura părinte, structura copil etc.) sau fixe (de ex.: "nr._________ din __.__._____ " etc.). De asemenea, în header mai trebuie introdus şi câmpul APROB, iar la sfârşitul documentului va fi afişat numele celui care a întocmit documentul sau lista membrilor grupului de lucru, după caz. În footer trebuie introdusă, în mod automat, dată creare document, dată modificare document, dată imprimare document, nume utilizator care a imprimat documentul.
Chestionare
CH01 Chestionar inteligent Se dorește îmbunătăţirea/extinderea modulului actual de chestionare ori instalarea unui modul de
chestionare care să permită culegerea de date pe eșantioane distincte (de ex.: rol, unitate de muncă etc.),
astfel încât să ofere următoarele funcționalități:
- moștenire întrebări de la un chestionar la altul (ne referim la definiții, răspunsuri, permisiuni de
afișare, etc.);
- opțiunea de a adăuga întrebări deschise într-un chestionar;
- posibilitatea de filtrare a afișări unui chestionar astfel încât doar anumite categorii de utilizatori să
poată vedea chestionarul. Categoriile se definesc prin filtrare pe: SO (doar utilizatori ce fac parte
din acea Strucutra Organizatorică), UM (doar utilizatorii ce au asociat în cadrul unei Anexa 1 acel
Domeniu/Domenii de activitatea), utilizator explicit (se selectează doar anumiți utilizatori).
Notificări
N01 Notificări depășire termen Notificările de depășire sau de avertizarea depășirii termenelor să fie scrise cu roșu BOLD.
N02 Alertarea automata repetitivă Notificările de depășire sau de avertizare a depășirii termenelor să se genereze începând cu 3 zile înainte de termen și până la rezolvarea acesteia, în mod repetat, o data pe zi. Nu se generează o noua alertă dacă cea veche nu s-a vizualizat.
N03 Link activ Notificările generate de aplicaţie trebuie să fie însoţite de link-uri către conţinutul notificării.
MODULUL Anexa 1
A101 Optimizarea modului de afişare Afişarea unui singur formular în care vor fi cuprinse informaţiile necesare parcurgerii Anexei 1. După parcurgerea cu succes a unor secţiuni din formular să fie evidenţiate prin culori, iar a celor care nu au fost parcurse sau sunt completate eronat să fie evidenţiate în alte culori. Aplicaţia să permită Salvarea provizorie a informaţiilor introduse în formular.
A102 Eliminarea unui membru inactiv din PDF Eliminarea din adăugarea în *.pdf a membrilor ce au devenit inactivi pe parcursul procesului de MRC.
A103 Introducere fluxuri de lucru Consilier si MGL Atunci când, în aplicație, se realizează componenta grupului de lucru în cadrul Anexe 1, pentru fiecare utilizator având rolul de Consilier, trebuie să fie specificat şi fluxul de lucru pe care îl atribuie utilizatorului:
- Flux de lucru de Consilier; - Flux de lucru de MGL.
Pentru a specifica această opțiune, va exista o bifă. Dacă e bifat, atunci utilizatorul în cauză va parcurge şi fluxul de lucru de MGL, iar dacă nu e bifată, va parcurge doar fluxul de lucru de Consilier, respectiv parcurgerea DOAR a Anexei 1 şi Anexei 10.
33
MODULUL Anexa 2
A201 Completarea opţională Completarea chestionarului din Anexa 2 să fie opţională, nu obligatorie cum este în prezent. Consilierul sau
şeful GL să poată stabili în Anexa 1 dacă un MGL trebuie să parcurgă Anexa 2.
A202 Folosirea de template *.xls Aplicaţia trebuie să permită încărcarea din interfaţă a unor chestionare completate în *.xls, preluarea
răspunsurilor din modulul de chestionar să fie făcută în mod automat, astfel încât să se constituite o bază
de date.
MODULUL Anexa 3
A301 Optimizarea modului de afişare Afişarea unui singur formular în care vor fi cuprinse informaţiile necesare parcurgerii Anexei 3. Parcurgerea cu succes a unor secţiuni din formular să fie evidenţiată prin culori, iar a celor care nu au fost parcurse sau sunt completate eronat să fie evidenţiate în alte culori. Aplicaţia să permită Salvarea provizorie a informaţiilor introduse în formular.
A302 Adăugarea şi asocierea de documente unei activităţi sau sarcini Aplicaţia trebuie să permită introducerea de documente într-un mod mai facil şi asocierea acestora pe
activităţi sau sarcini. Va fi adăugată o coloană în formular în care să poată fi înscris un text string, vezi
exemplul din imaginea de mai jos.
A303 Adăugarea unor butoane Aplicaţia trebuie să permită adăugarea de sarcini sau documente din formular prin accesarea unor butoane
dedicate acestei operaţiuni. De asemenea, aplicaţia trebuie să permită, prin accesarea unui buton dedicat,
adăugarea de documente ce vor fi asociate pe activităţi vulnerabile sau pe domenii de activitate.
A304 Adăugarea unor criterii de ordonare/filtrare Aplicaţia trebuie să permită ordonarea/filtrarea informaţiilor (de ex.: Domeniu de Activitate la modulul
Activităţi Vulnerabile, Sarcini, Documente).
34
A304 Eliminat mesajul "Nu puteţi crea o nouă Anexa 3, editaţi Anexa 3 deja
existentă!" Eliminat mesajul "Nu puteţi crea o nouă Anexa 3, editaţi Anexa 3 deja existentă!".
MODULUL Anexa 4
A401 Optimizarea modului de afişare Afişarea unui singur formular în care vor fi cuprinse informaţiile necesare parcurgerii Anexei 4. După parcurgerea cu succes a unor secţiuni din formular să fie evidenţiate prin culori, iar a celor care nu au fost parcurse sau sunt completate eronat să fie evidenţiate în alte culori. Aplicaţia să permită Salvarea provizorie a informaţiilor introduse în formular.
A402 Un Risc sa fie analizat în cadrul unei singure Anexe 4 în contextul aceleiaşi
Anexe 1 La crearea Anexei 4, să NU apară riscurile care au deja Anexe 4 în contextul aceleiași Anexe 1. Pentru a
evita cazurile în care doi utilizatori vor lucra simultan pe același Risc, ceea ce, în final, ar duce la situația în
care unul din cei doi va trebui să refacă Anexa 4 şi toate datele introduse, pentru că ar încălca regula ca “Un
Risc să fie analizat în cadrul unei singure Anexe 4, în contextul aceleiaşi Anexe 1”. Atunci când utilizatorul
selectează un Risc, dacă acel risc este DOAR selectat de alt utilizator în același timp, vom afișa în dreptul
riscului respectiv o notificare vizuală, menţionând şi numele utilizatorului. Astfel, cei doi (sau mai mulți)
utilizatori vor putea negocia în afara aplicației, pentru a se decide cine/ce risc va analiza.
A403 Avertiza AV din Anexa 3 fără Risc Să existe în listingul cu Anexe 4 un avertisment, în cazul în care utilizatorul are AV-uri din Anexa 3 pe care
nu a adăugat risc.
A404 Avertizare încălcare regula “Un Risc să fie analizat în cadrul unei singure
Anexe 4 în contextul aceleiași Anexe 1” La finalizarea Anexei 4, dacă există deja o Anexa 4 finalizată sau cel puțin salvată ca draft, care a tratat
același Risc în cadrul aceleiași Anexe 1, utilizatorul primește eroare ca nu poate salva această Anexa 4.
Utilizatorul va trebui să aleagă alt Risc şi să completeze din nou Anexa 4 şi restul meta-datelor. Aceasta
funcționalitate vine ca o măsura de constrângere în plus faţă de cea de la A402.
A405 Afișare Anexe 4 create de alți MGL Utilizatorul va vedea în lista sa Anexele 4 create de alţi MGL, în cadrul aceleiași Anexe 1 şi acelorași DA-uri
pe care le are şi el. Utilizatorul va putea accesa orice Anexa 4 (inclusiv pe cele create de alți MGL), şi le va
putea modifica cu aceleași drepturi ca şi creatorul.
A406 Nomenclatoare măsuri Aplicaţia trebuie să permită afişarea şi adăugarea de măsuri existente sau suplimentare din formularul
Anexa 4, şi constituirea de nomenclator de măsuri.
A407 Adăugare butoane Aplicaţia trebuie să pună la dispoziţia utilizatorului comenzi rapide pentru adăugarea / modificarea /
amendarea unui conţinut (de ex.: risc, activitate, sarcină, document etc.) direct din formularul Anexa 4 din
pop-up.
MODULUL Anexa 5
A501 Adăugare Anexa 5 din pop-up Anexa 4 Aplicaţia trebuie să se poată permite adăugarea unei Anexa 5 (Cauze din Domeniul Reglementarilor) în pop-up din Anexa 4. Desigur că dacă în pop-up se adaugă o Cauza din Domeniul Reglementarilor, ar trebui să apară şi în listingul de cauze din Anexa 4.
35
A502 Ştergere/inactivare înregistrare Aplicaţia trebuie să permită ştergerea/inactivarea unei înregistrări din baza de date prin apăsarea unui
buton. După inactivare aceasta nu va mai apărea în lista cauzelor din domeniul reglementării, însă rămâne
în baza de date pentru a păstra legăturile cu alte înregistrări generate anterior.
A503 Adăugare buton Anexa 5 Să existe un buton separat în meniul principal care să trimită direct în secțiunea Anexa 5-Raport cauze din
domeniul reglementărilor.
MODULUL Anexa 10
A1001 Registru de riscuri pe toate structurile Aplicaţia trebuie să permită consilierului central să genereze Anexa 10, în care vor fi incluse toate Anexele
10 ale GL din structurile copil.
A1002 Adăugare modul rapoarte evaluare Aplicaţia trebuie să permită descărcarea unui raport de evaluare standard generat cu informaţiile cuprinse
în Anexa 10 (în format *.xls) şi încărcarea din interfaţă a acestora, iar preluarea răspunsurilor din modelul
de raport să fie făcută în mod automat, constituindu-se o bază de date cu rapoarte de evaluare pe Anexa
10.
Aplicaţia trebuie să permită consilierului central să genereze Raport de evaluare, în care vor fi incluse toate
datele din rapoartele Grupurilor de Lucru din structurile copil.
A1003 Adăugare modul rapoarte monitorizare Aplicaţia trebuie să permită descărcarea unui raport de monitorizare standard generat cu informaţiile
cuprinse în Anexa 10 (în format *.xls) şi încărcarea din interfaţă a acestora, iar preluarea răspunsurilor din
modelul de raport să fie făcută în mod automat, constituindu-se o bază de date cu rapoarte de evaluare pe
Anexa 10.
Aplicaţia trebuie să permită consilierului central să genereze Raport de monitorizare, în care vor fi incluse
toate datele din rapoartele Grupurilor de Lucru din structurile copil.
MODULUL Riscuri
R01 Un nou modul dedicat managementului Riscurilor Revizuirea riscurilor se va face la producerea unui Incident de către un membru care este asociat pe
Domeniul de Activitate.
MODULUL Incidente
I01 Optimizarea modului de afişare Afişarea unui singur formular în care vor fi cuprinse informaţiile necesare parcurgerii modulului. După parcurgerea cu succes a unor secţiuni din formular să fie evidenţiate prin culori, iar a celor care nu au fost parcurse sau sunt completate eronat să fie evidenţiate în alte culori. Aplicaţia să permită Salvarea provizorie a informaţiilor introduse în formular.
MODULUL Rapoarte
RA01 Accesul la rapoarte Se dorește oferirea accesului la rapoarte şi utilizatorilor cu rol de Consilier/membru grup de lucru aparat
central.
RA02 Îmbunătăţirea criteriilor de selecţie Aplicaţia trebuie să permită unui administrator să extragă rapoarte pe selecţii multiple, nu doar pe unul (de
ex.: raport pe n domenii de activitate şi nu doar pe unul singur).
36
Librăria de documente
DOC01 Accesul la documente Se dorește oferirea accesului la documente şi utilizatorilor cu rol de Consilier/membru grup de lucru central
la documentele întocmite de GL din structuri copil.
37
Anexa 2 - Cazuri de utilizare a aplicației informatice MARC Cazurile de utilizare implementate în aplicaţie sunt listate în tabelul de mai jos.
COD NUME CAZ UTILIZARE ACTOR/ROL
UCG 1
Acces site web sistem Vizitator Intranet
UCG 2
Acces sistem MARC Orice rol ce deţine credenţiale de acces
în sistem
UCG 3
Ieşire sistem MARC Orice rol ce deţine credenţiale de acces
în sistem
UCA 1
Administrare Structuri Organizaţionale Administrator Central
UCA 2
Alocare manuală a UM pe SO Administrator Central
UCA 3
Definire GL la nivel de Structuri Centrale Administrator Central
UCA 4
Definire şi asociere MGL la GL la nivel de
Structuri Centrale Administrator Central
UCA 5
Definire GL la nivel de Structuri Teritoriale Administrator Teritorial
(+Administrator Central)
UCA 6
Definire şi asociere MGL la GL la nivel de
Structuri Teritoriale
Administrator Teritorial
(+Administrator Central)
UCA 7
Administrare Nomenclator Domenii de
Activitate Administrator Central
UCA 8
Administrare Nomenclator Activitati
Vulnerabile Administrator Central
UCA 9 Adaugare/Editare Activităţi Vulnerabile AC+AT+Şef/Consilier GL+MGL
UCA 10 Căutare Activitate Vulnerabilă AC+AT+Şef/Consilier GL+MGL
UCA
11 Notificare Adaugare AV AC
UCA 12 Aprobare/Stergere Activităţi Vulnerabile AC
UCA
13
u
c
a
Notificare MGL aprobare/dezaprobare AV Şef/Consilier GL+MGL
38
UCA
14 Asociere AV la UM AC
UCA1
5 Adaugare/Editare Sarcini/Asociere sarcini AV AC+AT+Şef/Consilier GL+MGL
Este de precizat că implementarea în baza de date a unor incidente de integritate, produse la nivelul
altor structuri2, MAI, dar asociate riscului de corupție care face obiectul evaluării, determină inactivarea
scorurilor de la 1 la 2, din Scala de evaluare. Dacă incidentele de integritate s-au întâmplat în structura MAI
unde se face evaluarea, atunci aplicaţia blochează (nu mai poate fi selectat) și scorul ce corespunde
factorului Posibil, membrul grupului putând selecta doar o valoare mai mare de 3.
2 De exemplu, în domeniul ordine publică, la Direcţia Generală de Poliţie a Municipiului Bucureşti, s-a întâmplat un incident de integritate, iar evaluarea se realizează pentru acelaşi domeniu, dar la Inspectoratul de Poliţie al Judeţului Vrancea
67
Exemplu – scală de evaluare cu incident în alte structuri decât cea unde se face evaluarea
b) Stabilirea impactului global
Estimarea impactului global al unui risc de corupţie constituie activitatea de cuantificare a efectelor
posibile ale acestuia asupra următoarelor componente / dimensiuni:
1. nivelul de performanţă a activităţilor şi obţinerea rezultatelor aşteptate;
2. calendarul activităţilor ori întârzieri posibile în termenul de realizare a obiectivelor activităţii;
3. consecinţele exprimate în termeni de buget;
4. consecinţele în planul imaginii instituţiei.
Pentru determinarea impactului fiecărui risc identificat, membrii grupului stabilesc dimensiunile
posibile ale impactului global încă din etapa de descriere a riscului. În aplicaţie aceste
efecte/consecinţe/componente/dimensiuni au fost selectat în cadrul anexei 4, aşa cum am precizat în
subcapitolul 2.2 – Creare anexă 4.
Pentru fiecare dimensiune a impactului se va estima importanţa relativă a acesteia şi se va stabili
scorul impactului global în cazul materializării, utilizând indicatorii descriptivi prevăzuţi în Scala de
estimare a impactului global al riscului – Anexa7 din metodologie .
Valoarea impactului global se calculează automat în aplicaţie, ca sumă a valorilor obţinute din
înmulţirea importanţei relative cu scorul impactului pentru fiecare dimensiune identificată. Astfel, după
alegerea probabilităţii se completează importanţa relativă (prin estimare procentuală – (%), din prima
coloană aferentă componentei/dimensiunii).
68
După determinarea importanţei relative, se selectează nivelul de impact ( scor de la 1 la 5, din
coloana a doua), acţionând căsuţa corespunzătoare „Impact”. Această acţiune deschide o fereastră (pop-up)
cu Scala de estimare a impactului (anexa 7 din Metodologie), din care, similar ca la probabilitate, se
selectează scorul aferent fiecărei componente a riscului, așa cum a fost identificat în activitatea anterioară a
Grupului de lucru pentru prevenirea corupției.
c) Expunerea riscului și prioritatea de intervenție
Prin înmulțirea probabilităţii şi a impactului global mai sus descrise se obţine expunerea la risc, pe
baza căreia se stabileşte prioritatea de intervenţie. În cadrul aplicaţiei MARC, acest calcul se realizează
automat de către sistem, imediat după completarea probabilităţii şi a impactului.
Nivelul riscului
Pe baza datelor introduse mai sus, aplicația stabileşte prioritatea de intervenţie, clasificând și
ordonând riscurile de corupţie în riscuri minore, riscuri moderate şi riscuri înalte. Regula de clasificare
69
poate fi vizualizată în aplicaţie, într-o un fereastră tip pop-up, unde sunt explicați termenul de intervenţie şi
prioritatea aferentă acestuia, corespunzător definițiilor din anexa nr. 9 a Metodologiei.
2.2.3.4. Evaluarea măsurilor de prevenire/control existente şi determinarea măsurilor
suplimentare (modulul Anexa 4)
În baza priorităţii de intervenţie stabilite, membrii grupului propun măsuri pentru
prevenirea/controlul riscului evaluat. Pentru completarea măsurilor de prevenire/control identificate la
nivelul unităţii de muncă analizate utilizatorul selectează, din ecranul principal al modulului Anexa 4,
butonul „Acțiuni”, comanda „măsuri de prevenire/control existente şi suplimentare”.
Utilizatorul apasă pe „Adaugă o nouă măsura” pentru a insera o noua măsura existentă la nivelul
structurii, iar, după completarea măsurii, se alege câmpul „Evaluare eficienţă măsură” şi se deschide un
pop-up (fereastră), corespunzătoare anexei 8 din Metodologie, în vederea analizării eficienţei măsurii
respective. Măsura existentă se evaluează dacă se adresează în mod efectiv riscului identificat, dacă este bine
documentată, comunicată celor interesaţi / implicaţi şi dacă este operaţională, aplicată în mod consecvent. În
funcţie de răspunsurile date aplicaţia calculează automat scorul aferent eficienţei, conform scalei din anexa 8
mai sus precizată.
70
Măsurile suplimentare au în vedere reducerea probabilităţii de materializare sau a impactului
vizează riscurile înalte şi cele moderate, cu prioritate 1 şi 2. Apăsarea pe butonul „Adaugă o nouă măsură”
se face pentru implementarea unei noi măsuri suplimentare, aferentă riscului analizat, precum și a
responsabilului de implementarea măsurii.
2.2.3.5. Definirea indicatorilor de evaluare a măsurilor de prevenire/control existente și
a celor suplimentare
Pentru implementarea şi monitorizarea aplicării măsurilor existente şi/sau suplimentare, asumate la
nivelul structurii organizatorice analizate, se vor stabili indicatori de evaluare aferenţi fiecărei măsuri. În
aplicaţie, pentru a stabili indicatorii de evaluare a măsurilor, utilizatorul selectează din Modulul Anexa 4
coloana „Acțiuni”, butonul „Stabilire indicatori de evaluare”.
După ce se vor completa indicatorii de evaluare, pentru ca informaţiile să se păstreze în sistem se
apasă butonul „Salvează”.
2.3. Registrul riscurilor de corupție – Modulul ANEXA 10
Modulul ANEXA 10 permite generarea Registrului Riscurilor de corupție, pentru toate Anexele 1
active din aplicație, semnificând finalizarea procesului de identificare și evaluare a riscurilor de corupție,
respectiv de determinare a măsurilor de prevenire/control. Această funcționalitate este accesibilă doar
utilizatorilor care au rolul de Șef al grupului de lucru și Consilier pentru integritate, și acest lucru se face
prin apăsarea butonului Anexa 10.
71
Pentru a genera Registrul Riscurilor de Corupție, se va alege din lista Anexelor 1 care au fost create
pentru derularea procesului de management al riscurilor de corupție, Anexa 1 (ACTIVĂ) în contextul
căreia au fost parcurse toate etapele.
Aplicația va deschide o nouă fereastră în care va fi autogenerat REGISTRUL RISCURILOR DE
CORUPȚIE, care cuprinde informațiile din toate Anexele 4 ce au fost Finalizate în contextul Anexei 1
ACTIVE. În cazul în care în Registrul generat nu conține toate domeniile de activitate, persoana care
a fost alocată pe domeniul respectiv nu a finalizat nicio Anexă 4.
Interfața generată este dinamică, în acest modul, fiind stabilite termenele de implementarea a
măsurilor incluse în Anexa 4, precum și periodicitatea acestora, în cazul în care sunt înscrise măsuri care
presupun un anumit grad de repetabilitate (zilnic, săptămânal, lunar, trimestrial etc.). După completarea
formularului, pentru ca aplicația să rețină datele selectate, trebuie apăsat butonul Salvează, și în mod
automat se generează un document cu extensia *.pdf și vor fi Notificați toți utilizatorii cu privire la acest
lucru. Lista documentelor create vor fi afișate de la cel mai recent la cel mai vechi.
După stabilirea termenelor și periodicității cu care se va implementa respectiva măsură, fiecare
utilizator va avea activă acțiunea de evaluare a fiecărei măsuri conform indicatorilor de evaluare stabiliți
anterior.
2.4. Monitorizarea și revizuirea riscului
Evaluarea măsurilor de prevenire/control pentru riscurile de corupție din sistem se poate face abia
după ce au fost stabilite termenele de implementare în cadrul modulului Anexa 10 – Registrul Riscurilor.
După implementarea efectivă a măsurilor, în vederea evaluării acestora, membrii grupului se
autentifică și accesează modulul anexa 4.
Pentru a marca Finalizarea acelor Măsuri de prevenire / control existente şi suplimentare, din
butonul Acţiuni al Anexei 4 în care a fost identificat riscul, se va alege Măsuri de prevenire / control
existente şi suplimentare.
72
Pentru a marca o măsură ca fiind implementată se acționează butonul „Finalizat” pentru acelea care
au fost realizate. Aplicaţia va afişa un mesaj de confirmare a acţiunii pe care doriţi să o faceţi. Ulterior
confirmării, nu vor mai putea fi făcute modificări asupra respectivei măsuri, respectiv reactivarea ei pentru
implementare. După ce au fost confirmate ca fiind implementate, în locul butonului va fi afişată, în mod
automat, data la care a fost acţionată comanda, se va apăsa butonul Salvează, astfel încât aplicaţia să reţină
modificările pe care le-aţi făcut.
După această etapă, utilizatorul trebuie să introducă valorile în funcţie de indicatorii de evaluare ce
au fost stabiliţi anterior, în etapa de descriere şi evaluare a riscului. Pentru acest lucru, din butonul Acţiuni
se va alege Stabilire indicatori de evaluare.
73
În câmpurile puse la dispoziţie de aplicaţie, vor fi înscrise din tastatură valorile pentru fiecare
măsură implementată, conform indicatorilor de evaluare stabiliţi anterior. Pentru măsurile ce au ca indicatori
de evaluare schimbarea ori realizarea unei proceduri, dezvoltarea unei aplicaţii, implementarea unui sistem,
etc. în căsuţa respectivă va fi înscrisă valoare 1 pentru cele care au fost realizate sau valoarea 0 dacă aceasta
nu a fost implementată.
În cazul în care o măsură suplimentară a fost implementată şi se doreşte păstrarea acesteia, pentru
perioada următoare în cadrul registrului de riscuri, ca măsură existentă, va fi bifată căsuţa din dreptul măsurii
suplimentare, iar după apăsarea butonului Salvează aceasta va deveni măsură existentă.
După implementarea măsurilor existente sau suplimentare, este posibil să se modifice valorile
probabilităţii sau impactului global, iar pentru a evalua expunerea la risc se va proceda ca în faza evaluării
iniţiale, din butonul Nivelul riscului/componentelor/dimensiuni de impact.
74
În cazul în care au fost parcurse toate etapele, se apasă butonul Finalizează şi notifică Şef/Consilier
grup de lucru, iar sistemul va trimite în mod automat notificări cu privire la finalizarea aplicării acelei
măsuri, realizată în termen. Dacă nu se respectă termenul menţionat în Anexa 10, pentru fiecare măsură din
registru, aplicaţia va transmite o notificare cu trei zile înainte de expirarea acestuia, în vederea atenţionării
membrilor grupului.
75
3. GESTIONAREA (CĂUTARE/ADĂUGARE) NOMENCLATOARELOR DIN APLICAȚIE