Sunteți pe pagina 1din 58

Ghid de achiziii

software pentru
instituiile publice
Versiune 1.0
Ghid de achiziii
software pentru
instituiile publice
Versiune 1.0

Versiunea actualizat a ghidului precum i alte instrumente i materiale relevante pot fi descrcate de la adresa:
www.anis.ro/programe/ghidachizitii

Ghid de achiziii software pentru instituiile publice | 3


Ghid de achiziii software pentru instituiile publice | 4
CONINUT 1. Introducere 7
2. Principii 9
Independen9
Autonomie i continuitate9
Definirea problemelor i obiectivelor9
Definirea cerinelor 10
Formulri clare i naturale10
Cerine juste - principiul necesitii10
Inclusiv vs. exclusiv10
Evaluare obiectiv i transparent10
Implicarea pe parcursul proiectului11
3. Caietul de sarcini12
Descrierea instituiei i a activitii 12
Problemele i nevoile curente 12
Scopul i obiectivele proiectului 13
Rolurile utilizatorilor 13
Cerine funcionale 14
Cerine nefuncionale 17
Cerine de comunicare i organizare 27
Livrabilele proiectului 30
Procesul de acceptan 35
Cerine post implementare38
Structura financiar 40
4. Criterii de atribuire42
Cadrul legislativ42
Metodologie de evaluare43
Stabilirea criteriilor de evaluare 47
Criteriile de pre i cost47
Punctarea ofertelor n funcie de cost sau pre49
Criterii tehnice50
5. Concluzii 55

Ghid de achiziii software pentru instituiile publice | 5


Ghid de achiziii software pentru instituiile publice | 6
1. INTRODUCERE
Scopul acestui ghid este s ndrume personalul implicat n procesul de achiziie a soluiilor
software, n redactarea documentaiei tehnice de atribuire. Ghidul este adresat n principal
instituiilor publice dar poate fi foarte bine utilizat i n cazul achiziiilor din domeniul privat.
Recomandrile din ghid sunt aplicabile att achiziiilor de soluii software personalizate
("soluii custom" sau "soluii la comand") ct i achiziiilor de produse software deja
existente.

Sarcina de a crea un caiet de sarcini pentru o achiziie software poate prea la nceput extrem
de complex i copleitoare, mai ales dac persoana nsrcinat nu are o pregtire tehnic de
specialitate sau se afl la primul astfel de demers.

Exist de asemenea ideea preconceput c un caiet de sarcini trebuie redactat ntr-un limbaj
savant sau "de specialitate". Prin acest ghid dorim s demontm aceast idee i s artm
c orice specialist ntr-un domeniu public, care cunoate problemele cu care se confrunt
organizaia sa, poate redacta un caiet de sarcini coerent, chiar i fr a avea o pregtire
tehnic n domeniul software. Tocmai din acest motiv, n redactarea ghidului am ncercat
s evitm un limbaj foarte tehnic i, de asemenea, s explicm ntr-un mod ct mai simplu
noiunile tehnice relevante. Din acelai motiv am evitat traducerea anumitor termeni tehnici n
limba romn acolo unde am considerat c termenul n englez este mai relevant.
Credem c un caiet de sarcini trebuie n principal s detalieze nevoile beneficiarului i
problemele care trebuie rezolvate cu ct mai multe detalii i ntr-un limbaj ct mai simplu i
clar. n aceste sens, ghidul propune o structur a caietului de sarcini i o serie de recomandri
privind realizarea acestuia.

Exemplele oferite n ghid au strict rolul de a explica mai bine anumite concepte i nu trebuie
preluate ad-litteram n documentaia de atribuire.

Soluie software
Termenul de soluie software folosit n acest ghid cuprinde toate componentele i serviciile
necesare implementrii unei soluii ce are la baz software. Aceste servicii i componente pot
cuprinde: licene pentru produse software de baz (sisteme de operare, sisteme de baze de
date), licene pentru produse software specializate (ERP, CRM, BPM, KB, HelpDesk), software
existent disponibil comercial pe scar larg tip COTS (Commercial of the Shelf) echipamente
hardware, servicii de analiz i arhitectur, servicii de consultan n domeniul software, servicii
de dezvoltare i testare, servicii de design grafic i multe altele, lista nefiind exhaustiv.

Ce nu i propune acest ghid


Ghidul se refer strict la achiziii software i nu i propune s acopere partea de achiziii
hardware, networking, servicii de infrastructur sau comunicaii.

Ghidul adreseaz n principal latura tehnic a achiziiilor de software i nu i propune s


adreseze aspectele legale ale achiziiilor precum condiii de eligibilitate, procedura achiziiilor
sau contractarea. Aceste aspecte vor fi eventual elaborate ntr-o versiune viitoare a ghidului.

De asemenea, ghidul nu i propune sa fac recomandri de tehnologie, arhitectur sau privind


procesul care ar trebui urmrit pe perioada unei implementri.

Nu n ultimul rnd, trebuie reiterat faptul c acest ghid nu este exhaustiv. Ghidul propune o
structur a documentaiei tehnice de atribuire i un set de recomandri de la care se poate
porni n elaborarea documentaiei. Documentaia de atribuire trebuie ns adaptat de la caz la
caz prin eliminarea unor cerine care poate nu sunt aplicabile sau prin adugarea de cerine noi,
specifice proiectului.

Despre ghid
Ghidul a fost realizat la iniiativa Guvernului Romniei de ctre Asociaia Patronal a Industriei
de Software i Servicii (ANIS). Grupul de lucru care a participat la elaborarea ghidului a fost
format din: Mihai Matei (Essensys Software), Alex Lpuan (Zitec), Dan Grlau (Oracle) cu

Ghid de achiziii software pentru instituiile publice | 7


suportul i coordonarea doamnei Valerica Dragomir (ANIS) i Alex Timis (ANIS).

Prezentul document reprezint prima versiune a acestui ghid. Ca n orice demers iniial exist,
cu siguran, aspecte care pot fi mbuntite, precum i posibile erori sau inadvertene care
pot fi ndreptate. Exist deschiderea i disponibilitatea autorilor de a mbunti coninutul n
versiunile viitoare pe baza sugestiilor primite de la utilizatorii ghidului.

ncurajm utilizatorii acestui ghid s trimit comentariile i sugestiile de mbuntire folosind


adresele de contact de mai jos. Este de asemenea foarte util s nelegem i alte probleme de
care v lovii n achiziia sau derularea proiectelor software n organizaiile dumneavoastr.
Identificarea acestor probleme poate genera noi iniiative pentru crearea unor instrumente de
suport n activitatea dumneavoastr.

Adresa de contact pentru sugestii i observaii: ghidachizitii@anis.ro

Ghid de achiziii software pentru instituiile publice | 8


2. PRINCIPII
n cele ce urmeaz enumerm cteva principii pe care le considerm vitale n derularea
achiziiilor publice, pe lng cele specificate de legislaia n vigoare: nediscriminarea furnizorilor,
tratamentul egal al furnizorilor, respectarea criteriului proporionalitii etc.

Suntem convini c urmrirea acestor principii de transparen i independen, va conduce la


achiziii eficiente i proiecte de succes.

2.1. Independen
Principiul de baz al acestui ghid este independena fa de influenele potenialilor furnizori.

n realizarea unui caiet de sarcini trebuie s v asigurai independena fa de orice influen


extern i s punei pe primul loc interesul instituiei pentru care lucrai. n mod evident, orice
ingerin extern poate deturna sau dirija procesul de achiziie n detrimentul intereselor
instituiei dumneavoastr.

Scopul acestui ghid este tocmai acela de a v oferi suportul practic necesar pentru a elabora
caiete de sarcini, eliminnd astfel orice dependen extern.

2.2. Autonomie i continuitate


Independena trebuie asigurat att n faza de pregtire a caietului de sarcini i a procedurii
de atribuire ct i ulterior ncheierii relaiilor contractuale cu furnizorul selectat. Este critic,
ca nc din faza de pregtire a documentaiei de atribuire, s asigurai autonomia instituiei
dumneavoastr, precum i continuitatea soluiei independent de furnizorul iniial, ulterior
ncheierii relaiilor contractuale cu acesta.

n acest sens, documentaia de atribuire trebuie s conin prevederi care s asigure


continuitatea soluiei i s permit instituiei dumneavoastr operarea de modificri, respectiv:

Transferul codului surs (n cazul soluiilor personalizate) cu posibilitatea modificrii


independent de furnizor;
Transferul tuturor livrabilelor realizate n cadrul proiectului n form prelucrabil/editabil;
Proprietatea datelor i/sau posibilitatea extragerii acestora n mod automat, fr a fi
necesar intervenia furnizorului (export date)

Opiunile pe care le avei la dispoziie n acest sens sunt descrise pe larg in capitolul 3.6 Cerine
nefuncionale Legal i liceniere.

2.3. Definirea problemelor i obiectivelor


Un factor foarte important n succesul oricrui proiect este comunicarea clar a problemelor
cu care v confruntai n prezent i a obiectivelor i rezultatelor pe care proiectul trebuie s
le rezolve. Din acest motiv, n cadrul caietului de sarcini trebuie s comunicai ct mai clar att
problemele curente, ct i obiectivele proiectului.

Identificarea clar a problemelor cu care v confruntai, precum i o list clar de obiective, v


va ghida n procesul de documentare a cerinelor proiectului.

Fr aceste informaii, un furnizor nu va putea nelege problemele pe care trebuie s le rezolve


i, n consecin, soluia pe care o va propune nu va fi una optim.

Ghid de achiziii software pentru instituiile publice | 9


2.4. Definirea cerinelor
Soluia software pe care o solicitai va trebui s respecte o serie de cerine. Numrul i
complexitatea acestor cerine influeneaz direct costul i durata de implementare a proiectului.

Din acest motiv, este foarte important ca n caietul de sarcini s identificai clar toate cerinele
pe care soluia trebuie s le respecte. Omiterea unor cerine va cauza subestimarea proiectului
de ctre furnizori i va cauza probleme ulterior.

Este de asemenea foarte important ca cerinele s fie exprimate ct mai clar i n detaliu,
astfel nct potenialii furnizori s poat estima ct mai corect complexitatea acestora. Toate
detaliile pe care le putei furniza vor ajuta furnizorii s propun soluii optime pentru problemele
dumneavoastr.

2.5. Formulri clare i naturale


Ideea c limbajul folosit ntr-un caiet de sarcini trebuie s fie unul savant sau de specialitate
este o idee preconceput care nu face dect s creeze o barier artificial de comunicare ntre
dumneavoastr i potenialii furnizori.

Recomandarea noastr este ca n elaborarea caietului de sarcini s folosii un limbaj ct mai


natural i uor de neles. De asemenea, recomandm s definii termenii de specialitate
specifici domeniului dumneavoastr acolo unde este cazul. Formularea criptic a cerinelor va
cauza ineficiene, nenelegeri i ntrebri de clarificare nenecesare.

2.6. Cerine juste - principiul necesitii


Pe lng enumerarea tuturor cerinelor i detalierea acestora, este la fel de important ca
cerinele pe care soluia trebuie s le respecte s fie juste, respectiv s serveasc strict scopului
proiectului i rezolvrii problemelor cu care v confruntai fr alte adugri nenecesare.

Din acest punct de vedere este recomandat s evitai n special cerinele artificiale sau ascunse
care ar putea crea constrngeri i limitri artificiale sau chiar ar putea elimina din competiie unii
furnizori.

Evitai de asemenea cerinele suplimentare sau conexe care nu sunt neaprat necesare
proiectului (fenomenul de placare cu aur / gold plating). Acestea vor crea costuri
suplimentare i vor ngreuna implementarea proiectului. n acest sens, este recomandat s
facei distincia ntre cerine necesare (must have) i cerine opionale (nice to have).

2.7. Inclusiv vs. exclusiv


n elaborarea caietului de sarcini, recomandm o abordare ct mai inclusiv n privina
furnizorilor. Cu siguran exist criterii juste de eligibilitate i tehnice care pot fi folosite pentru
a filtra furnizorii, ns recomandm ca aceste criterii s fie folosite cu msur pentru a nu
restriciona artificial participarea furnizorilor la competiie. Un numr mai mare de furnizori v
va oferi o plaj mai larg de opiuni, precum i o ans mai mare de a contracta soluia optim.

n acest sens, este important s evitai limitarea artificial a participrii prin introducerea de
criterii tehnice sau de eligibilitate care pot fi satisfcute de un singur furnizor. Orice criteriu
limitativ trebuie s aib o justificare n obiectivele proiectului.

2.8. Evaluare obiectiv i transparent


n mod evident, evaluarea obiectiv i transparent a ofertelor este vital pentru un proces
de achiziii eficient. n acest sens, recomandm ca metodologia de evaluare s fie clar definit

Ghid de achiziii software pentru instituiile publice | 10


n caietul de sarcini, asigurnd astfel transparena procesului de evaluare. De asemenea, este
recomandat s detaliai criteriile i subcriteriile de evaluare ce vor fi folosite pentru desemnarea
furnizorului ctigtor.

2.9. Implicarea pe parcursul proiectului


Credem c implicarea beneficiarului pe parcursul unui proiect, i nu doar n faza incipient i n
faza final de acceptan, este vital pentru succesul proiectului.

n acest sens, este important alocarea resurselor umane necesare pe parcursul proiectului.
Din acest punct de vedere, recomandm alocarea unui responsabil unic de proiect care s aib
autoritatea necesar pentru a lua decizii n cadrul proiectului.

Recomandm de asemenea un proces recurent de revizuire a progresului (spre exemplu, cu


recuren lunar). n cadrul acestui proces se poate urmri progresul proiectului, se pot evalua
rezultatele pariale i, cel mai important, se poate aciona din timp n cazul n care proiectul
deviaz de la traseu. n cazul n care beneficiarul este implicat doar n faza de acceptan final,
exist riscul ca eventualele probleme aprute pe parcurs s fie descoperite doar la finalul
proiectului cu consecine mult mai mari.

Ghid de achiziii software pentru instituiile publice | 11


3. CAIETUL DE SARCINI
n seciunile urmtoare descriem capitolele pe care le recomandm n cadrul unui caiet de
sarcini. Pentru fiecare capitol exist recomandri punctuale pentru elaborarea coninutului.
Aceast list de capitole reprezint o recomandare minim i nu este exhaustiv. Evident, lista
poate fi completat cu alte capitole n funcie de necesitile dumneavoastr.

3.1 Descrierea instituiei i a activitii


Care este activitatea instituiei?

Este foarte probabil ca furnizorii de software interesai de proiectul dumneavoastr s nu


cunoasc foarte multe detalii despre instituia dumneavoastr i activitile acesteia. Exist
deci o barier artificial de comunicare iniial care trebuie ns depit ct mai repede i
eficient, iar un prim pas n eliminarea acestei bariere este chiar caietul de sarcini.

O prim ntrebare pe care orice furnizor o are este: Care este activitatea beneficiarului?.
Astfel, o introducere practic i util n caietul de sarcini este descrierea succint a instituiei
dumneavoastr, a scopului acesteia i a activitilor principale pe care le desfurai. n aceast
seciune este indicat s detaliai activitile relevante n cadrul proiectului care vor fi afectate
de noua soluie software.

n cazul n care exist o pagin de prezentare a activitii instituiei sau documentaie relevant
n acest sens, este util ca aceasta s fie menionat sau chiar anexat caietului de sarcini.

Descrierea instituiei i a activitii este de asemenea un loc bun pentru introducerea


termenilor specifici instituiei dumneavoastr care ar putea s nu fie foarte familiari. n cazul n
care terminologia folosit este foarte complex, recomandm crearea unui capitol separat de
terminologie ns termenii importani pot fi explicai nc din introducere.

3.2 Problemele i nevoile curente


Care sunt problemele de care ne lovim n prezent?

Un capitol esenial n fia tehnic este descrierea problemelor cu care se confrunt instituia
dumneavoastr i care au condus la necesitatea implementrii unei soluii software.
Identificarea i descrierea acestor probleme i nevoi este foarte important pentru definirea
cerinelor care vor rezolva aceste probleme. De asemenea potenialii furnizori trebuie s
neleag problemele cu care v confruntai pentru a putea propune o soluie optim.

Pentru identificarea acestor probleme, o abordare foarte practic este implicarea colegilor
dumneavoastr n identificarea i detalierea acestora. Este foarte posibil ca majoritatea
problemelor pe care colegii dumneavoastr le sesizeaz s fie formulate n limbajul tehnic specific
al instituiei n care lucrai. Este important s filtrai, s punei n contextul descrierii activitii
(vezi capitolul anterior) i s traducei aceste probleme pe nelesul oricrei persoane care nu
cunoate detaliile activitii instituiei. Alte tehnici de identificare a problemelor sunt descrise
n capitolul Cerine funcionale.

Relum aici ideea importanei limbajului natural i clar, precum i explicitarea termenilor tehnici.
n cazul n care n activitatea dumneavoastr se folosesc foarte muli termeni tehnici, este util
definirea unui capitol de Terminologie sau Glosar n cadrul caietului de sarcini.

IMPORTANT: Identificarea problemelor cu care se confrunt instituia dumneavoastr v este


la ndemn. Avei toate cunotinele i instrumentele de care avei nevoie, dumneavoastr i
colegii dumneavoastr putei identifica aceste probleme mai bine dect orice furnizor.

IMPORTANT: Identificarea i detalierea problemelor cu care v confruntai este un pas esenial

Ghid de achiziii software pentru instituiile publice | 12


care nu trebuie omis din caietul de sarcini. De cele mai multe ori identificarea corect a unei
probleme conduce la identificarea rapid a unei soluii.

3.3 Scopul i obiectivele proiectului


Unde vrem s ajungem?

Pentru a determina obiectivele proiectului trebuie s v imaginai situaia n care v dorii s


ajungei dup implementarea proiectului. ntrebarea la care trebuie s rspundei este: Care
este situaia n care vrem s ajungem dup ce acest proiect este implementat?. Rspunsurile
la aceast ntrebare reprezint obiectivele proiectului.

Definirea unor obiective clare va ajuta foarte mult i va ghida de asemenea i n realizarea
cerinelor proiectului. Evident, un proiect poate avea mai multe obiective, care pentru a fi
relevante trebuie s respecte principiile SMART, respectiv:

S - Specific
Obiectivele trebuie s fie concrete/specifice.

M - Msurabil
Msurarea realizrii obiectivului trebuie s fie simpl i evident n urma unei observrii
obiective (vs subiectiv i interpretabil)

A - Realizabil / Achievable
Obiectivele trebuie s fie realizabile n mod realist i nu imposibil de atins.

R - Relevant
Obiectivul trebuie s fie relevant pentru beneficiar.

T- Temporal
Trebuie s fie indicat un termen clar pentru realizarea obiectivului. Spre exemplu: la finalul
proiectului, ntr-un an de la implementare etc.

Exemplu bun: "Ne propunem ca prin acest proiect, n 2 ani de la implementare, 60% din
populaia judeului Prahova s i consulte online situaia taxelor i impozitelor, reducnd
astfel prezena la ghiee cu 40%".

Contra-exemplu: Ne propunem ca prin acest proiect s mbuntim percepia i experiena


ceteanului n relaia cu instituiile statului.

3.4 Rolurile utilizatorilor


Cine va utiliza sistemul?

Pentru o bun nelegere a cerinelor, este important nelegerea utilizatorilor care vor
interaciona cu sistemul. Astfel caietul de sarcini trebuie s cuprind o seciune n care sunt
enumerate rolurile care vor accesa sistemul. De asemenea, pentru fiecare rol, trebuie descrise
responsabilitile n cadrul sistemului i n cadrul instituiei.

Pentru identificarea acestor roluri este recomandat s examinai procesele de lucru din cadrul
instituiei care sunt relevante pentru sistem.

Exemple tipice de roluri sunt: Secretariat, Funcionar cu publicul, Operator financiar, ef


departament X, Management, Administrator de sistem etc.

Pe lng rolurile de utilizatori care vor utiliza sistemul, este util s enumerai i s descriei
i alte roluri (actori) care nu vor utiliza direct sistemul dar sunt relevante pentru nelegerea

Ghid de achiziii software pentru instituiile publice | 13


soluiei. Un exemplu de astfel de rol ar putea fi Autoritate de reglementare X sau Auditor
extern, respectiv roluri care poate beneficiaz de rapoarte generate de sistem chiar dac nu
acceseaz direct sistemul. Aceste roluri trebuie tratate distinct i trebuie marcate ca nefiind
utilizatori direci ai sistemului.

3.5 Cerine funcionale


Ce trebuie s fac sistemul?

Cerinele funcionale reprezint facilitile sau funciile pe care sistemul trebuie s le realizeze.
Cu alte cuvinte, ceea ce trebuie s fac sistemul.

Formularea corect i complet a cerinelor este vital deoarece un procent important de


defecte i/sau de erori aprute ntr-un proiect software se datoreaz erorilor din analiza
iniial a nevoilor beneficiarului. Cu ct o eroare se propag mai adnc fr a fi remediat, cu
att remedierea ei va costa mai scump, astfel:

$1 n timpul definirii cerinelor;


$5 n faza de concepie a aplicaiei;
$10 n etapa de codare a aplicaiei;
$20 n timpul testelor modulelor software;
$200 dup livrarea sistemului.

Desigur, valorile de mai sus sunt orientative ns ordinul de mrime este relevant, astfel erorile
neremediate aprute n definirea problemelor i cerinelor iniiale au cel mai mare impact.
Examinarea problemelor identificate este un bun punct de plecare pentru determinarea
cerinelor funcionale. De cele mai multe ori, identificarea problemei conduce la identificarea
rapid a unei soluii optime de rezolvare, soluie care devine evident atunci cnd problema
este cunoscut. Astfel, cerinele funcionale constituie rspunsul la problemele identificate
anterior.

O alt modalitate recomandat de identificare a cerinelor este consultarea colegilor


dumneavoastr n privina funcionalitilor de care ar avea nevoie pentru a-i desfura
activitatea mai eficient. Ca i n cazul problemelor, aceste cerine trebuie filtrate i structurate.

Cteva tehnici pentru identificarea cerinelor sunt:

Examinarea problemelor identificate;


Grupuri de lucru (brainstorming);
Interviuri cu colegii dumneavoastr;
Examinarea elementelor i documentelor existente (fluxuri de lucru, formulare, rapoarte,
legislaie etc);
Examinarea sistemelor informatice existente sau similare;
Observarea activitii colegilor (shadowing);
Utilizarea de chestionare online;
Revizuirea cerinelor existente pentru a determina cerine indirecte.

n cele ce urmeaz enumerm cteva tipologii de cerine funcionale ce pot fi folosite ca punct
de plecare n enumerarea cerinelor dumneavoastr. Avnd n vedere diversitatea cerinelor
funcionale, nu avem pretenia c aceast list ar fi complet.

Clasificarea cerinelor n funcie de importan


Att cerinele funcionale ct i nefuncionale, pot fi clasificate n funcie de importan folosind
metodologia MoSCoW:

Cerine critice (MUST have) - sunt cerine fr de care sistemul nu i ndeplinete scopul;
Cerine importante (SHOULD have) - cerine importante dar care nu sunt strict necesare;

Ghid de achiziii software pentru instituiile publice | 14


Cerine posibile (COULD have) - cerine posibile sau opionale (Nice to have) care nu sunt
neaprat necesare i sunt mai puin importante;
Cerine eliminate (WONT have) - cerine fr relevan care vor fi eliminate din scopul
proiectului.

Clasificarea cerinelor v va ajuta n stabilirea cerinelor care sunt incluse n caietul de sarcini.
n mod evident toate cerinele critice (must) trebuie incluse n documentaia de atribuire.
De asemenea, n funcie de bugetul i timpul disponibil, putei include i o parte din cerinele
importante (should) sau posibile (could).

Cerinele importante (should) i posibile (could) ar putea fi introduse n documentaie ca cerine


opionale suplimentare. n cazul n care criteriile de evaluare implic i rezolvarea acestor cerine
pentru punctaj suplimentar, este foarte important s clarificai acest lucru n caietul de sarcini.

Includerea cerinelor eliminate (WONT have) n documentaia de atribuire poate fi o modalitate


foarte practic de a elimina anumite presupuneri ale furnizorilor, presupuneri care ar putea
genera costuri inutile. n cazul n care o parte din aceste cerine ar putea deveni cerine ntr-o
versiune ulterioar, este util menionarea lor, astfel nct furnizorii, pe ct posibil, s proiecteze
o arhitectur de soluie care s acomodeze aceste cerine mai uor.

Evidena general de informaii


O bun parte din cerinele funcionale pot fi ncadrate n categoria evidenei generale de
informaii, respectiv capacitatea sistemului de a stoca anumite tipuri de informaii. n astfel de
cazuri, cerina de baz este c utilizatorii trebuie s poat aduga, modifica i terge diferite
tipuri de nregistrri.

IMPORTANT: n astfel de cazuri este important detalierea atributelor nregistrrii (cmpurile).


De asemenea, este util identificarea relaiilor cu alte entiti (spre exemplu, un contribuabil
este asociat unei uniti teritoriale). Enumerarea acestor atribute i relaii poate conduce la
identificarea unor cerine ascunse. Spre exemplu, identificarea atributului Jude necesit, cel
mai probabil, definirea unui nomenclator de judee.

Alte funcionaliti comune ar putea fi:

Cutare dup diverse criterii cu specificarea acestora;


Ordonarea listelor dup unul sau mai multe cmpuri;
Validri speciale (ex: interogarea altor sisteme);
Exportul mai multor nregistrri;
Printarea unei nregistrri;
Posibilitatea de a importa una sau mai multe nregistrri;
Gruparea informaiilor dup diverse criterii;
Versionarea modificrilor (pstrarea versiunilor anterioare);
Auditarea modificrilor;
Arhivarea nregistrrilor;
Accesul securizat la nregistrri (permisiuni la nivel de nregistrare).

Un exemplu de astfel de cerin ar putea fi: Sistemul trebuie s permit evidena contribuabililor.
Utilizatorii trebuie s poat aduga, modifica i terge nregistrrile contribuabililor. tergerea
unei nregistrri presupune mutarea n arhiv de unde poate fi restaurat samd. Iat c n acest
caz, simpla formulare a unei cerine a condus la o cerin ascuns, respectiv aceea de arhivare.

Nomenclatoare
O categorie special de nregistrri sunt nregistrrile de tip nomenclator. Nomenclatoarele
sunt simple liste de nregistrri, cu o dinamic mult mai mic a modificrilor. Exemple de
nomenclatoare: judee, ri, orae, zile libere legal, uniti teritoriale etc.

Identificarea nomenclatoarelor n cadrul caietului de sarcini este foarte util chiar dac pe
parcursul proiectului este probabil i descoperirea altor nomenclatoare neidentificate iniial.

Ghid de achiziii software pentru instituiile publice | 15


Fluxuri de lucru
Documentarea fluxurilor de lucru sub form de diagrame de flux este o modalitate foarte
util de a descrie cerinele funcionale. n cazul n care alegei s includei astfel de diagrame
n caietul de sarcini, este important s marcai corespunztor pe diagram paii din flux care
trebuie realizai n cadrul sistemului i paii care se realizeaz n afara sistemului.

Integrri cu alte sisteme


O alt categorie de cerine este reprezentat de integrarea cu alte sisteme software, integrare
care poate lua foarte multe forme.

Integrarea la nivel de date poate presupune un transfer de date cu un alt sistem i poate fi
unidirecional sau bidirecional. Integrarea unidirecional presupune transferul de date
dinspre sistemul A ctre sistemul B sau viceversa, n timp ce integrarea bidirecional presupune
transferul de date n ambele direcii.

Integrare de API (interfa programatic, Application Programming Interface) presupune


utilizarea interfeelor programatice oferite de un alt sistem. Un exemplu ar fi utilizarea unui API
de transmitere de SMS-uri sau integrarea cu serviciile online oferite de Registrul Comerului
sau Ministerul Justiiei.

Exist, de asemenea, posibilitatea integrrii la nivel de componente sau chiar la nivel de interfa
utilizator. n astfel de cazuri un sistem A folosete componente sau chiar fragmente de interfa
utilizator puse la dispoziie de un sistem B. Un exemplu de integrare la nivel de interfa ar fi
integrarea unui formular de plat online oferit de un procesator de pli.

Activiti automate
O parte din funciile unui sistem reprezint activiti automate. Exemple de astfel de activiti
ar fi backup-ul automat al bazei de date sau procesri de date recurente (ex: nchideri de zi, lun
etc.).

Recomandarea noastr este s automatizai n cel mai mare grad posibil operaiunile, reducnd
astfel ncrcarea echipei ce va utiliza proiectul rezultat i reducnd posibilele erori de operare.
Anumite procese trebuie s fie automatizate n mod obligatoriu (de exemplu, efectuarea de
copii de siguran a datelor), deoarece n lipsa automatizrii acestora este foarte posibil ca
operaiunea s nu aib loc sau s aib loc cu o frecven aleatoare, anulnd scopul funcionalitii.

Notificarea utilizatorilor
n multe cazuri exist cerine funcionale privind notificarea utilizatorilor n privina
evenimentelor relevante. n cazul notificrilor este util enumerarea tipurilor de notificare i
specificarea canalelor pe care notificrile vor fi transmise (Ex: mail, sms, n aplicaie etc.).

Exemple de notificri ar putea fi: notificarea transmis pe mail la alocarea unei sarcini, finalizarea
generrii unui raport care dureaz mult, rezultatul backup-ului bazei de date transmis
administratorilor de sistem etc.

Raportare
Majoritatea sistemelor informatice pun la dispoziia utilizatorilor un set de rapoarte predefinite
care pot fi generate pe baza datelor stocate n sistem. Coninutul unui raport poate varia de la
o list simpl de nregistrri, pn la rapoarte complexe coninnd indicatori de performan i
elemente vizuale complexe (grafice, hri etc). Rapoartele pot fi de asemenea parametrizate.
Spre exemplu, un raport care genereaz lista contribuabililor cu datorii mai mari de X, avnd
domiciliul n oraul Y, este un raport cu parametrii X i Y care pot fi modificai de utilizator.

n cazul n care cerinele de raportare sunt numeroase, este recomandat alocarea unui
capitol dedicat n documentaia de atribuire. n cadrul acestui capitol enumerai rapoartele
dorite menionnd denumirea fiecrui raport, coninutul pe scurt i parametrii dorii. n cazul
n care cerinele de raportare nu pot fi stabilite, este necesar s menionai cel puin numrul
de rapoarte dorite i complexitatea acestora astfel nct furnizorii s poat estima n mod
corect bugetul (ex: 20 de rapoarte de complexitate mic, 10 rapoarte de complexitate medie i
5 rapoarte de complexitate mare).

Ghid de achiziii software pentru instituiile publice | 16


n cazul n care rapoarte similare sunt deja generate pe alte ci (exemplu: excel sau folosind alte
sisteme) este foarte util s anexai caietului de sarcini aceste exemple.

O cerin uzual pe care o putei solicita este capabilitatea de printare i export a rezultatelor n
diferite formate uzuale (pdf, html, word, excel etc.).

Pe lng rapoartele predefinite, unele sisteme ofer posibilitatea utilizatorilor de a-i crea
propriile rapoarte. n cazul n care solicitai aceast funcionalitate, nu uitai s o menionai n
cadrul cerinelor de raportare. Aceast facilitate poate necesita cunotine tehnice i ar putea
fi accesibil doar personalului tehnic sau poate fi accesibil i utilizatorilor obinuii.

n cazul proiectelor cu nevoi de raportare complexe i variabile n timp, realizarea acestora n


mod programatic ar putea presupune costuri considerabile. n astfel de situaii recomandm
analizarea posibilitii de a utiliza platforme dedicate de raportare i procesare a datelor,
incluznd n proiect doar activitile necesare integrrii cu o astfel de platforma i, eventual,
costurile de liceniere i instruire. ntr-un astfel de scenariu configurarea rapoartelor ar putea fi
realizat cu resurse interne.

3.6 Cerine nefuncionale


Cum trebuie s se comporte sistemul?, Ce alte caracteristici sunt
importante?

Spre deosebire de cerinele funcionale care exprim ceea ce trebuie s fac sistemul, cerinele
nefuncionale exprim cerine despre cum trebuie s funcioneze sistemul, respectiv cerine
care nu in neaprat de funcionalitate. Dac identificarea cerinelor funcionale este relativ
natural i intuitiv, cerinele nefuncionale sunt caracteristici ale sistemului care nu sunt la fel
de evidente. Din acest motiv considerm c este util o list a posibilelor cerine nefuncionale
ce pot influena un sistem informatic.

n cele ce urmeaz propunem o astfel de list cu cele mai comune cerine nefuncionale pe care
o putei adapta nevoilor dumneavoastr. Aceste cerine trebuie incluse i detaliate n caietul
de sarcini sau eliminate dac nu sunt aplicabile n cazul dumneavoastr. Lista propus nu este
exhaustiv, astfel putei aduga n caietul de sarcini i alte cerine care sunt relevante pentru
dumneavoastr.

IMPORTANT: ntotdeauna cerinele suplimentare presupun i costuri suplimentare. Acest lucru


este evident n cazul cerinelor funcionale deoarece sistemul va face mai multe deci este
evident ca va costa mai mult. n cazul anumitor cerine nefuncionale, costurile pot crete
exponenial chiar dac acest lucru nu este la fel de evident. Astfel, ca i n cazul cerinelor
funcionale, este recomandat s solicitai doar acele cerine nefuncionale strict necesare,
eliminnd cerinele opionale (nice to have).

Spre exemplu, o interfa utilizator care este disponibil doar n limba romn este mai puin
costisitoare dect o interfa disponibil n mai multe limbi. Pentru o interfa disponibil n
mai multe limbi sunt necesare urmtoarele intervenii: dezvoltarea de cod/logic pentru
localizare, traducerea interfeei n celelalte limbi, testarea fiecrei interfee, localizarea
manualelor de utilizare i, eventual, chiar instruirea n fiecare limb. Mai mult, n cazul n care i
coninutul bazei de date trebuie localizat, impactul este mult mai mare i va presupune un efort
considerabil de administrare inclusiv pentru beneficiar (ex: localizarea tirilor pentru un site).
Astfel, dac o interfa n limba romn este suficient, este mult mai eficient s nu solicitai o
interfa disponibil n mai multe limbi. Acelai lucru este valabil pentru majoritatea cerinelor
nefuncionale.

3.6.1 Accesibilitate

Accesibilitatea se refer la capacitatea unui sistem de a fi utilizat de persoane cu dizabiliti

Ghid de achiziii software pentru instituiile publice | 17


(ex: lipsa total sau parial a vederii, lipsa auzului etc.). n cazul n care sistemul trebuie s fie
accesibil persoanelor cu dizabiliti, este important s specificai aceste cerine n caietul de
sarcini.

NOT: Majoritatea sistemelor de operare ofer funcii predefinite pentru persoanele cu


dizabiliti (magnifier, text-to-speech etc.). n cazul n care, pe lng aceste funcii, sunt
necesare funcii speciale dedicate persoanelor cu dizabiliti, acestea trebuie specificate n
detaliu.

3.6.2 Audit

Cerinele de auditare se refer la capacitatea sistemului de a nregistra toate operaiile efectuate


de ctre utilizatori, de ctre alte sisteme sau operaii automate. n scopul trasabilitii, registrul
de audit (audit log) este disponibil ulterior pentru consultare, spre exemplu n cazul unui audit
extern.

n cazul n care sistemul dumneavoastr necesit astfel de capabiliti, este important s le


menionai n caietul de sarcini. Este de asemenea recomandat s menionai explicit operaiile
care necesit auditare i detaliile ce trebuie auditate. Evident, n cazul n care dorii auditarea
tuturor operaiilor, costurile de implementare i exploatare vor crete.

3.6.3 Backup

Procesul de backup este procesul prin care datele unui sistem sunt salvate (backup) pentru a fi
ulterior restaurate (restore) n caz de nevoie (pierderea datelor, dezastru etc.). Existena unei
proceduri de backup este obligatorie pentru orice sistem informatic. Cerinele de backup nu ar
trebui s lipseasc din nici un caiet de sarcini.

Cerinele de backup trebuie s cuprind frecvena cu care este necesar realizarea de


backup-uri, tipul backup-ului, mediul de backup (online, offline) samd.

Recomandm programarea i includerea n serviciile de mentenan a unor exerciii periodice


prin care s verificai c procedura de back-up i restore funcioneaz corect.

3.6.4 Capacitate i volum de date

O seciune care nu trebuie s lipseasc din caietele de sarcini este cea legat de capacitatea i
volumele de date pe care sistemul trebuie s le suporte n prezent i viitor. Aceste informaii pot
fi exprimate n valori curente i valori anuale aditive. Spre exemplu, numrul curent de utilizatori
este 5000 i ne ateptm la adugarea unui numr maxim de 200 de utilizatori anual. Creterile
anuale pot fi exprimate i procentual.

Acurateea acestor valori este important pentru proiectarea i dimensionarea corect a


soluiei. Este astfel recomandat s evitai exagerarea volumelor deoarece va conduce la
creterea nejustificat a costurilor.

Exemple uzuale de date volumetrice:

Numr total de utilizatori;


Numr de utilizatori activi simultan;
Numr de nregistrri preferabil de fiecare tip relevant (ex: nr facturi, nr de documente
etc.);
Numr de documente;
Dimensiune stocare documente.

Ghid de achiziii software pentru instituiile publice | 18


3.6.5 Conformitate i Certificri

Soluiile software utilizate n anumite domenii de activitate ar putea necesita certificri i


autorizaii speciale pe care soluia trebuie s le respecte. De asemenea, pentru anumite soluii
ar putea exista standarde sau legislaie care trebuie respectate. n cazul n care exist astfel de
cerine, acestea trebuie s fie detaliate i justificate n caietul de sarcini.

IMPORTANT: Includerea n caietul de sarcini a unor cerine nejustificate de certificare i


conformitate pot restrnge lista furnizorilor eligibili i pot genera costuri nejustificate.
Recomandm ca includerea unor astfel de cerine eliminatorii s se fac cu pruden i n
cazurile n care acestea sunt chiar necesare.

3.6.6 Compatibilitate i interoperabilitate

n cazul n care soluia furnizorului trebuie sa fie compatibil cu alte soluii sau tehnologii, aceste
cerine trebuie documentate i detaliate. Un aspect pe care este indicat s l luai n considerare
este structura parcului IT disponibil n cadrul instituiei (calculatoare desktop, monitoare etc.).
Aceast evaluare poate conduce la anumite cerine de compatibilitate (de ex: sisteme de
operare vechi, rezoluii ecran reduse).

Exemple:

Compatibilitatea cu anumite sisteme de operare i versiuni;


Anumite browsere internet;
Capaciti hardware (ex: rezoluii de ecran);
Sisteme de baze de date;
Standarde tehnologice;
Etc.

3.6.7 Disponibilitate (availability)

Cerinele de disponibilitate exprim perioada n care soluia trebuie s fie funcional i


accesibil utilizatorilor.

Spre exemplu, o aplicaie de registratur mai puin critic ar putea fi disponibil doar n timpul
sptmnii, n intervalul orar 8.00-18.00, interval n care sunt acceptate ntreruperi de maxim 1
or. O soluie de dispecerat pentru situaii de urgen trebuie, cel mai probabil, s fie disponibil
24 de ore din 24, 7 zile din 7 posibile cu ntreruperi de maxim 1 ora/luna pentru mentenana
tehnic n anumite intervale orare.

Cerinele de disponibilitate se pot exprima sub forma intervalului orar n care sistemul trebuie s
fie disponibil i a duratei acceptabile de indisponibilitate n intervalul de disponibilitate. Alternativ,
se poate exprima sub forma raportului ntre timpul de disponibilitate (uptime) mprit la suma
timpului de disponibilitate adunat cu timpul de indisponibilitate, respectiv timpul total.

Spre exemplu, o soluie disponibil permanent pe perioada a treizeci de zile cu o ntrerupere de


o or are o disponibilitate de 30 zile x 24 ore - 1 or / 720 = 719 / 720 = 99.86%, respectiv timp
funcionare / (timp funcionare + timp nefuncionare) sau mai simplu timp funcionare/timp
total.

IMPORTANT: Trebuie subliniat faptul c un grad foarte mare de disponibilitate presupune i


costuri considerabile (n general pentru infrastructura redundant dar i pentru o arhitectur
software care s suporte o nalt disponibilitate). Exagerarea nevoilor de disponibilitate,
a intervalelor orare critice precum i a disponibilitii echipei de suport tehnic din partea
furnizorului va duce la o cretere nejustificat a costurilor.

Ghid de achiziii software pentru instituiile publice | 19


3.6.8 Documentaie

Documentaia este o parte important a oricrei soluii software. n caietul de sarcini trebuie
definite documentele care trebuie livrate de ctre furnizor. O list posibil a acestor documente
este definit n seciunea Livrabilele proiectului.

3.6.9 Extensibilitate

Extensibilitatea unei soluii reprezint gradul i uurina cu care aceasta poate fi extins cu noi
funcionaliti.

n cazul n care exist extensii viitoare ale soluiei, este foarte util ca acestea s fie comunicate
astfel nct furnizorul s defineasc o arhitectur care s suporte extensia. De asemenea,
alte cerine i ateptri n privina extensibilitii trebuie solicitate explicit n caietul de sarcini.
Exemple: posibilitatea de a aduga noi rapoarte, posibilitatea de a aduga noi roluri de securitate
etc.

Pentru a asigura n practic extensibilitatea, este important s v asigurai contractual de


disponibilitatea echipei furnizorului precum i s ncercai s prevedei costurile pe care astfel
de extinderi le implic n viitor. Acest lucru se traduce prin solicitarea unor garanii de timp
de intervenie i de pstrarea condiiilor comerciale pentru o anumit perioad de timp (ex.
Costurile de manoper sau liceniere nu se vor modifica pentru o anumit perioad de timp).

3.6.10 Garanie

Garania unei soluii protejeaz beneficiarul de impactul eventualelor defecte care sunt
descoperite ulterior acceptanei soluiei, eventual n mediul de producie. Garania trebuie
s acopere att cerinele funcionale, ct i cerinele nefuncionale, iar defectele identificate
trebuie remediate pe cheltuiala furnizorului.

Spre exemplu, o soluie care se dovedete a funciona neperformant n condiiile de volum de


date i ncrcare stabilite n caietul de sarcini sau specificaiile tehnice, este o soluie defect
care trebuie remediat de furnizor pe cheltuial proprie. n cazul n care ncrcarea i volumul de
date sunt mai mari dect cele specificate, discutm despre o soluie care necesit modernizare,
costul urmnd s fie suportat de beneficiar.

Iat nc o dat de ce formularea clar a cerinelor este important. n derularea garaniei


este important definirea ct mai explicit a noiunii de defect, respectiv un comportament al
soluiei diferit de cel stabilit de caietul de sarcini sau specificaiile funcionale. Caietul de sarcini
i, ulterior, specificaiile tehnice sunt referin pentru determinarea defectelor.

n general, perioada de garanie ncepe s curg ncepnd cu data instalrii n producie. Cu


toate acestea, n cazul n care instalarea n producie a soluiei este amnat din cauze care nu
in de furnizor, garania trebuie s nceap s curg de la o alt dat limit (ex: cel trziu X zile
de la finalizarea cu succes a acceptanei). O cerin poate fi: Garania furnizorului va ncepe s
curg de la data instalrii n producie sau n cazul amnrii cu mai mult de o lun a instalrii din
cauze care nu in de furnizor, la un interval de o lun de la acceptarea soluiei.

Majoritatea defectelor sunt descoperite n primele cteva luni de funcionare ale unei soluii.
Recomandm astfel ca perioada de garanie minim solicitat s fie de 6 luni pentru soluii de
complexitate mic-medie i cel puin 12 luni pentru soluii de complexitate mai mare. Evident,
perioada solicitat poate fi mai mare i este chiar indicat dac specificul proiectului o cere.
Trebuie ns subliniat faptul c i aceast cerin poate presupune costuri suplimentare.

Cerinele privind garania trebuie solicitate i detaliate n documentaia de atribuire. Durata


garaniei, termenul de la care ncepe s curg perioada de garanie, condiiile de acoperire,
precum i serviciile pe care furnizorul trebuie s le ofere n perioada de garanie, sunt detalii
care trebuie ct mai clar solicitate n documentaia de atribuire i, ulterior, preluate n contractul

Ghid de achiziii software pentru instituiile publice | 20


cu furnizorul.

3.6.11 Instalare

Modul n care o soluie este instalat n mediul de producie poate fi un aspect extrem de
important n anumite medii. Spre exemplu, timpul de instalare sau upgrade ar putea fi foarte
constrns n cazul unui sistem de dispecerat pentru situaii de urgen.

n cazul n care exist cerine speciale privind instalarea, acestea trebuie bine documentate
n documentaia de atribuire. Exemple: timpul maxim de instalare n cazul n care exist
constrngeri de timp, ferestrele de timp disponibile (ex: noaptea, doar n weekend etc.), tipul
instalrii (automat, manual), resursele umane disponibile pentru instalare i nivelul tehnic al
acestora.

3.6.12 Interoperabilitate

Interoperabilitatea se refer la capacitatea unui sistem de a schimba informaii cu alt sistem.


Interoperabilitatea presupune capacitatea de a interpreta automat informaii furnizate de alt
sistem si, de asemenea, de a genera informaii care pot fi interpretate automat de alte sisteme.
n general, interoperabilitatea se referea la folosirea de standarde open universal recunoscute.
Exemple de standarde open sunt: HTML, PDF, XML etc.

n cazul n care exist cerine speciale de interoperabilitate pe care sistemul trebuie s le


respecte, acestea trebuie detaliate n caietul de sarcini.

3.6.13 Infrastructura hardware i software existent

O seciune foarte important a cerinelor nefuncionale este seciunea n care este descris
infrastructura hardware i software existent cu care noul sistem trebuie s se integreze.
Avnd n vedere importana descrierii, este recomandat ca aceasta s fie un capitol distinct al
caietului de sarcini.

Descrierea infrastructurii poate s cuprind urmtoarele aspecte:

Topologia logic a reelei locale i inter-locaie dac exist;


Identificarea soluiilor folosite n instituie, relevante pentru proiect (Active Directory, mail
server, soluii de colaborare etc.);
Conectivitate internet dac este relevant pentru proiect (caracteristici conexiuni);
Tehnologii de dezvoltare software utilizate (limbaje de programare, baze de date etc.);
Servere eventual disponibile pentru noul sistem (configuraie hardware i software);
Licene software disponibile dac sunt relevante (sistem de operare, baz de date);
Alte sisteme software relevante n cadrul proiectului;
Descrierea staiilor client (hardware minim, sistem de operare, browser, software etc.);
Numr de staii i servere;
Alte echipamente i software relevante n cadrul proiectului;
Orice alte informaii legate de hardware sau software ce ar putea fi relevante pentru
proiect.

n descrierea infrastructurii existente este foarte util utilizarea diagramelor.

3.6.14 Localizare i globalizare

Internaionalizarea presupune capacitatea aplicaiei de a funciona n alte culturi (ri). Cerinele


de internaionalizare trebuie documentate explicit n documentaia de atribuire.

Ghid de achiziii software pentru instituiile publice | 21


Exemple de astfel de cerine:

disponibilitatea interfeei n mai multe limbi;


disponibilitatea documentaiei n mai multe limbi;
suport multi valut;
posibilitatea de a schimba formatul folosit pentru numere i date calendaristice;
funcionarea corect n zone diferite de timp.

3.6.15 Legal i liceniere

De multe ori aspectele legale sunt ignorate din caietele de sarcini cu consecine nefaste pentru
beneficiar. Omiterea cerinelor n aceast privin poate cauza o relaie de captivitate fa de
furnizorul soluiei ceea ce este evident de evitat.

Pentru a preveni astfel de situaii este foarte important s specificai n caietul de sarcini
cerinele legate de liceniere i alte aspecte legale.

Codul surs i modificri ulterioare


n cazul soluiilor personalizate (la cheie), este foarte important s clarificai aspectele legate
de proprietatea intelectual i accesul la codul surs al soluiei.

IMPORTANT: Pentru a evita o relaie de dependen, trebuie s v asigurai c vei putea


modifica codul surs independent de furnizorul iniial, vei putea transfera codul surs ctre un
alt furnizor sau contracta un alt furnizor pentru modificri sau servicii de mentenan.

Acest lucru se poate realiza uzual prin urmtoarele mecanisme:

liceniere nelimitat a tuturor livrabilelor cu transfer al codului surs i a livrabilelor cu


posibilitatea modificrii ulterioare de ctre beneficiar fr restricii (recomandat);
transferul proprietii intelectuale asupra tuturor livrabilelor ctre instituia
dumneavoastr.

Din punct de vedere practic ambele opiuni v vor oferi posibilitatea modificrii ulterioare a
soluiei fr a depinde de furnizorul iniial.

Opiunea licenierii fr limitri a soluiei i transferul codului surs i a tuturor livrabilelor


n form prelucrabil/editabil, va permite instituiei dumneavoastr modificarea sub orice
form a soluiei fr a depinde de furnizor. De asemenea aceast opiune nu presupune
constrngeri suplimentare pentru furnizor. Acesta va putea reutiliza la rndul su rezultate din
proiect n alte proiecte (ex: componente reutilizabile).

Opiunea de transfer a proprietii intelectuale presupune constrngeri suplimentare pentru


furnizor i costuri posibil mai mari. n acest caz furnizorul nu va putea reutiliza componente
sau fragmente din proiecte anterioare (ex: componente proprii, framework, etc.) deoarece
nu va putea realiza integral transferul de proprietate intelectuala. De asemenea furnizorul nu
va putea refolosi rezultate din proiect n alte proiecte, acestea devenind integral proprietatea
dumneavoastr. Aceast opiune este mai puin flexibil dar poate fi necesar n anumite
proiecte (ex: siguran naional).

Liceniere
n cazul unei achiziii de produse software deja existente este foarte complicat ca un furnizor s
transfere proprietatea intelectual ctre beneficiar sau s fie de acord cu modificarea codului
surs. ns este esenial s clarificai tipul de liceniere dorit i politica de upgrade i suport. n
acest caz trebuie s clarificai dac licena pe care o dorii este una perpetu sau una temporar
(tip abonament). n cazul licenierii sub form de abonament trebuie s clarificai situaia n care
vei finaliza contractul cu furnizorul respectiv. n privina upgrade-urilor (versiuni noi) trebuie
s definii cerinele legate de perioada pentru care sunt solicitate upgrade-uri i dac acestea
trebuie oferite contra cost sau nu. De asemenea, perioada n care furnizorul va oferi suport
pentru produsul oferit este important (sub forma de suport tehnic sau update-uri), precum

Ghid de achiziii software pentru instituiile publice | 22


i condiiile n care suportul este oferit (perioad, costuri etc). n mod evident, unele cerine pot
genera costuri suplimentare pe care trebuie s le bugetai.

Proprietatea datelor
Indiferent de tipul soluiei, soluie personalizat sau produs software, aspectul proprietii
datelor stocate n sistem nu trebuie neglijat. n acest sens trebuie s v asigurai c datele
rmn proprietatea instituiei dumneavoastr n orice situaie. De asemenea, trebuie s v
asigurai c furnizorul ofer o modalitate tehnic prin care datele pot fi extrase n orice moment
din sistemul existent ntr-o form prelucrabil (export ntr-un format standard, acces la baza
de date etc.).

Componente dezvoltate de teri


Un alt aspect important este legat de utilizarea de componente software dezvoltate de teri.
Astfel de componente accelereaz procesul de dezvoltare i sunt uzual folosite de dezvoltatori.
Este important ca furnizorul s asigure licenierea corect a acestor componente.

ncetarea activiti furnizorului i transfer


Exist situaii n care furnizorul i nceteaz activitatea sau situaii n care relaia contractual
cu acesta nu poate continua. Este important s stabilii cerinele privind o astfel de situaie.
Contractual, furnizorului i se poate solicita s realizeze transferul tuturor livrabilelor proiectului
ctre beneficiar sau ctre un alt furnizor.

Legislaie aplicabil
n cazul n care activitatea instituiei dumneavoastr este guvernat de anumite legi care au
un impact asupra sistemului, este necesar menionarea legilor aplicabile n aceast seciune.

IMPORTANT: Aceste cerine legale trebuie reluate sub form de clauze contractuale i n
contractul dintre instituie i furnizor.

3.6.16 Migrare

Exist frecvent situaii n care o soluie software nou este conceput s nlocuiasc o soluie
anterioar. Cel mai probabil, n astfel de situaii, soluia existent a fost folosit de-a lungul
timpul pentru a colecta date i informaii. Nu uitai s solicitai n caietul de sarcini migrarea
datelor n cazul n care informaiile din sistemul anterior trebuie migrate n noul sistem, n multe
situaii aceast activitate nu este trivial.

ntr-un astfel de caz este important s anexai caietului de sarcini ct mai multe informaii despre
sistemul anterior i, n special, documentaia bazei de date dac exist sau, cel puin, structura
acesteia. Fr aceste informaii furnizorii nu pot face o evaluare corect a complexitii i
efortului necesar migrrii.

Majoritatea provocrilor n cazul unei migrrii provin din posibile inconsistene sau erori n
datele existente (ex: date lips sau invalide) precum i din dificultatea maprii datelor vechi pe
noua structur a bazei de date. Din acest motiv, dac situaia o permite, este recomandat s
transmitei furnizorilor o mostr de baze de date actual, eventual anonimizat, astfel nct
acetia s poat nelege complexitatea problemei pe care o au de rezolvat.

3.6.17 Monitorizare

Un aspect tehnic important al unei soluii software este capacitatea acesteia de a fi monitorizat
din punct de vedere tehnic. O cerin minim care nu ar trebui s lipseasc este nregistrarea
erorilor ntmpinate (error log). Registrul de erori poate fi ulterior folosit pentru investigarea i
rezolvarea erorilor folosite.

O alt cerin ar putea fi alertarea automat a administratorilor de sistem atunci cnd


sunt ntmpinate condiii anormale de funcionare. n cazul unor aplicaii critice astfel de
funcionaliti ar putea fi absolut necesare, n timp ce pentru aplicaii non-critice astfel de

Ghid de achiziii software pentru instituiile publice | 23


cerine pot fi omise.

Existena unor indicatori de performan ai sistemului i a rapoartelor de sistem ar putea fi de


asemenea cerine dac astfel de funcionaliti sunt necesare. Pe lng aceste sugestii putei
formula i alte cerine concrete privind monitorizarea sistemului.

3.6.18 Performan

Performana unui sistem este foarte important pentru funcionarea eficient a acestuia.
Funcionarea neperformant (lent) a unor funcii cheie poate conduce la blocarea sistemului
i la imposibilitatea utilizrii acestuia. Astfel formularea cerinelor de performan n caietul de
sarcini este foarte important.

Trebuie subliniat faptul c performana unui sistem este influenat de foarte muli factori,
printre care numrul de utilizatori activi, volumul de date, distribuia datelor, caracteristicile
hardware, conexiunea la reea (local sau internet), gradul de ncrcare al conexiunilor,
arhitectura sistemului, structura bazei de date i multe altele. O parte dintre aceti factori sunt
cu siguran cunoscui (volum de utilizatori) sau pot fi influenai de furnizor (ex: arhitectura),
ns ali factori nu pot fi controlai de furnizor sau chiar nu pot fi cunoscui la momentul realizrii
caietului de sarcini.

Din acest motiv este foarte important ca n formularea cerinelor de performan s se


stabileasc i condiiile n care cerinele respective trebuie ndeplinite. Cu alte cuvinte, trebuie
detaliate volumele de date preconizate, numr de utilizatori activi simultan, caracteristicile
hardware, detaliile de infrastructur samd.

Cerinele de performan pot fi formulate sub form de timp optim i timp maxim n care anumite
operaii trebuie s poate fi realizate. n acest sens, este util s identificai cerinele funcionale
cheie ale sistemului i s asociai acestora cerine de performan.

Un exemplu de cerin de performan ar putea fi: Regsirea unei nregistrri de contribuabil


folosind CNP-ul trebuie s dureze sub X secunde n mod uzual i maxim Y secunde n condiii de
ncrcare maxim a sistemului.

3.6.19 Recuperare n caz de dezastru (Disaster recovery)

Un dezastru este un eveniment care poate afecta funcionalitatea sistemului. Un dezastru


poate fi defectarea dispozitivelor de stocare (hard disk sau SSD), defectarea plcii de baz a
unui server dar i dezastre naturale cum ar fi incendii, cutremure, inundaii etc.

Indiferent de infrastructura de care dispune instituia dumneavoastr, este vital s avei la


dispoziie un plan de restaurare a sistemului n caz de dezastru. Acest plan are rolul de a repune
n funciune un sistem n cel mai scurt timp posibil n cazul apariiei unui dezastru. n panica
ulterioar apariiei unui dezastru un astfel de plan se va dovedi extrem de valoros.

Unul din parametrii cheie ai acestui plan care trebuie specificat este timpul maxim de restaurare.
Cu ct acest timp este mai mic, cu att investiia necesar este mai mare. Pentru a asigura
un timp de restaurare foarte scurt este posibil ca anumite echipamente redundante s fie
necesare (ex: servere).

Este de asemenea foarte important ca acest plan s fie actualizat i testat periodic pentru a
asigura validitatea i aplicabilitatea acestuia n caz de nevoie.

3.6.20 Scalabilitate

Scalabilitatea unui sistem reprezint capacitatea acestuia de a gestiona volume mai mari de
activitate i date prin mbuntirea caracteristicilor hardware (scalare vertical) sau prin

Ghid de achiziii software pentru instituiile publice | 24


adugarea de echipamente hardware adiionale (scalare orizontal).

n mod ideal, rspunsul unui sistem la scalare ar trebui s fie liniar. Cu alte cuvinte, dublarea
caracteristicilor hardware sau adugarea unui server nou ar trebui s permit unui sistem
acomodarea unui volum dublu de activitate. n mod evident, acest rspuns liniar este imposibil
de obinut n practic.

Scalabilitatea unui sistem este o caracteristic foarte important atunci cnd volumele
gestionate sunt mari (numr mare de utilizatori, volum mare de date etc). Pentru aceste situaii
trebuie s formulai cerine de scalabilitate.

n general, scalabilitatea vertical nu presupune neaprat intervenii din partea dezvoltatorilor.


Hardware-ul poate fi mbuntit i soluia, cel mai probabil, va funciona corect fr a fi
necesare modificri. Scalabilitatea orizontal are ns un impact important n arhitectura
sistemului. Astfel, este important s menionai aceast cerin n caietul de sarcini n cazul n
care sistemul trebuie s suporte scalabilitate orizontal.

3.6.21 Securitate i confidenialitate

Un alt set de cerine care nu ar trebui s lipseasc din niciun caiet de sarcini sunt cele legate
de securitate. Domeniul securitii este unul foarte vast i sensibil. n acest ghid am ncercat
s structurm cteva cerine minime legate de securitate fr a ncerca s acoperim toate
scenariile posibile.

Autentificarea reprezint procesul prin care un actor este identificat (de obicei actorul este un
utilizator dar poate fi vorba i de un alt sistem informatic). Cerinele de securitate trebuie s
clarifice mecanismul de autentificare dorit. Cteva tipuri uzuale de autentificare sunt:

Pe baz de utilizator i parol;


Integrat active directory;
Cu certificate electronice;
Cu dispozitive tip digipass;
Cu coduri transmise via SMS (2 factor authentication);
Folosind standard de tip OpenAuth sau OpenID.

Autorizarea este procesul prin care unui actor i este permis accesul la resursele sistemului
(funcionaliti, date, rapoarte etc.). n majoritatea sistemelor prin procesul de autorizare se
poate controla accesul la funciile sistemului. Spre exemplu: Doar rolul financiar are acces
la rapoartele contabile. n anumite situaii este necesar i controlarea accesului la date.
Spre exemplu: Utilizatorii dintr-o unitate teritorial vor putea accesa doar nregistrrile
contribuabililor din teritoriul respectiv, sau Un utilizator cu rolul de front-office va putea
accesa doar nregistrrile proprii.

Pentru a detalia cerinele de autorizare este util folosirea unei matrici unde funcionalitile
sunt aranjate pe linii, coloanele reprezint rolurile din aplicaie iar intersecia reprezint tipul
de acces permis/nepermis. O matrice similar poate fi folosit i pentru accesul la date/
nregistrri.

Recomandm ca cel puin autorizarea la nivelul funciilor aplicaiei s fie configurabil i s


permit modificri ulterioare, respectiv permisiunile rolurilor i utilizatorilor s fie configurabile.

Protocoale de comunicaii
Un aspect important legat de securitate unui sistem l reprezint protocoalele de comunicaii
folosite pentru comunicarea ntre diversele componente (client-server, server-server). Este
o bun practic ca orice comunicaie ntre diversele componente ale sistemului s fie criptat
(ex: SSL) dac exist riscul ca respectiva comunicaie s fie expus. Spre exemplu, n cazul
unui sistem disponibil online (inclusiv website de prezentare), este obligatorie o conexiune
securizat ntre browser i server (respectiv folosirea HTTPS).

Ghid de achiziii software pentru instituiile publice | 25


Procedura de actualizare a certificatelor SSL este un aspect care nu trebuie omis. Aceste
certificate au o durat de valabilitate i un cost aferent, de aceea este important s avei foarte
bine organizat acest proces de achiziie i prelungire, pentru a evita situaia n care sistemul s
nu fie operaional la expirarea lor.

Criptare i semnatur electronic


n situaia n care sistemul gestioneaz date sensibile i este necesar un grad ridicat de securitate
putei solicita criptarea informaiilor sensibile. Implementarea semnturii electronice poate fi de
asemenea necesar dac anumite aciuni ale utilizatorilor trebuie s fie opozabile legal. n cazul
n care sistemul necesit criptarea anumitor informaii sau semntur electronic menionai
aceste cerine explicit n caietul de sarcini.

Cerinele de securitate pot avea un impact considerabil asupra costurilor i arhitecturii


sistemului. Ca i n celelalte cazuri, cerinele de securitate trebuie s fie juste i adecvate
scopului proiectului.

3.6.22 Usurina n utilizare (Usability)

Uurina n utilizare (Usability) a unui sistem se refer la uurina cu care utilizatori pot utiliza i
nva respectivul sistem. Chiar dac uurina n utilizare, performana i calitatea unui sistem
ar trebui s fie caracteristici implicite ale oricrui sistem, este util s menionai aceste cerine
n caietul de sarcini n special dac exist cerine speciale.

Chiar dac poate prea lipsit de importan, uurina n utilizare se poate dovedi esenial
dac utilizatorii acestuia au un grad mai sczut de pregtire tehnic sau sunt copleii cu alte
activiti ale instituiei. n astfel de situaii un sistem greoi este nc un blocaj n activitatea de zi
cu zi care ntr-un final conduce la ineficiena instituiei.

O caracteristic a unui sistem utilizabil este intuitivitatea i familiaritatea interfeei utilizator.


Cu alte cuvinte un utilizator ar trebui s poat folosi un sistem informatic nou cu un minim de
instruire sau chiar fr instruire. Utilizarea unei interfee familiare i consistente contribuie
foarte mult la uurina n utilizare a sistemului.

Utilizabilitatea unui sistem este de asemenea caracterizat de uurina n utilizare i de


eficiena utilizrii. Uurina i eficiena pot fi msurate prin numrul de interaciuni (mouse
click, butoane apsate, cmpuri completate amd) pe care un utilizator trebuie s le fac pentru
a duce la ndeplinire o anumit operaie. n anumite cazuri minimizarea numrului de interaciuni
poate face diferena ntre un sistem de succes i unul care nu i atinge scopul.

n determinarea cerinelor de uurin n utilizare este util definirea i caracterizarea audienei


creia sistemul se adreseaz. Aceast caracterizare poate face parte din caietul de sarcini,
separat sau ca descriere a rolurilor, i va fi cu siguran util furnizorilor n proiectarea soluiei.

n special n sistemele cu volume mari de operaii sau unde viteza de lucru este important
(spre exemplu aplicaii de ghieu public) pot exista cerine speciale de eficien pe care le putei
solicita n caietul de sarcini. Spre exemplu operaia de completare a formularului X trebuie s
poat fi realizat de un utilizator n maximum 5 minute folosind doar tastatura, presupunnd c
datele necesare sunt disponibile i viteza acestuia de tastare este satisfctoare.

n cazul sistemelor online disponibile publicului, uurina n utilizare este de asemenea foarte
important. Dac pentru angajaii instituiei exist posibilitatea instruirii, este foarte puin
probabil ca utilizatorii externi (publicul) s aloce timp unei instruiri. n astfel de cazuri sistemul
trebuie s fie intuitiv i familiar pentru a fi eficient i a-i atinge scopul.

Pentru astfel de cazuri este util identificarea funcionalitilor cheie pentru care viteza i
eficiena sunt importante. Aceste cerine trebuie detaliate i solicitate explicit n caietul de
sarcini.

Ghid de achiziii software pentru instituiile publice | 26


3.6.23 Tehnologie

n situaia n care din diverse motive soluia solicitat trebuie s foloseasc anumite tehnologii
sau exist constrngeri n privina tehnologiilor ce pot fi folosite la implementare, este necesar
ca astfel de constrngeri s fie documentate n caietul de sarcini.

Ca o excepie, o limitare tehnic acceptabil ar fi s solicitai ca noua soluie s fie compatibil


cu soluiile software existente, sau chiar s foloseasc acelai limbaj de programare sau
un sistem de baz de date deja liceniat (dac gradul de uzur moral i tehnic a soluiilor
existente o permit). Acest lucru va garanta un cost redus de exploatare pentru toate aplicaiile
beneficiarului, prin reducerea nivelului de complexitate a ntregului portofoliu de aplicaii.

IMPORTANT: introducerea unor constrngeri tehnologice poate limita drastic concurena.


Dac astfel de constrngeri sunt necesare exist acestea trebuie justificate i susinute. Este
foarte posibil ca introducerea unor constrngeri tehnice s cauzeze contestarea caietului de
sarcini i posibil chiar anularea unei competiii.

3.7 Cerine de comunicare i organizare


Care este structura echipelor de proiect?, Care sunt responsabilitile?,
Cum vom comunica?

Succesul unui proiect software depinde n mare msur de resursele umane implicate n proiect
i de modul n care acestea reuesc s comunice eficient pentru a depi dificulti i blocaje
inerente n cadrul oricrui proiect.

Structura echipelor de proiect


n privina organizrii este recomandat definirea cerinelor minime privind structura echipelor
implicate n proiect att din partea furnizorului ct i din partea beneficiarului.

n calitate de beneficiar trebuie s v asigurai c alocai proiectului suficiente resurse umane


interne, cu competene adecvate scopului proiectului precum i un buget de timp/efort alocat
proiectului. Chiar dac structura echipei beneficiarului nu constituie o cerin propriu-zis a
caietului de sarcini, definirea structurii acesteia este necesar nc din prima etap a proiectului.

n mod similar trebuie s v asigurai c viitorul furnizor va aloca o echip de proiect adecvat
i competent. Structura acestei echipe poate constitui o cerin a caietului de sarcini la care
furnizorul trebuie s rspund prin oferta sa.

Structura fiecrei echipe (beneficiar/furnizor) se realizeaz prin definirea rolurilor existente n


cadrul echipei. Pentru fiecare rol este necesar cel puin definirea urmtoarelor atribute:

Denumirea rolului;
List de responsabiliti n cadrul proiectului;
List de competene pe care trebuie s le dein;
Cerine i constrngeri (experien, certificri, samd.)

IMPORTANT: modul n care sunt formulate cerinele privind echipa furnizorului poate limita
considerabil numrul de furnizori. Recomandarea noastr este s definii strict cerinele
necesare proiectului evitnd introducerea de cerine vag relevante sau exotice (spre exemplu
certificri tehnice rare).

n funcie de specificul proiectului, un rol poate fi ndeplinit de una sau mai multe persoane (ex:
dezvoltator sau tester). De asemenea, o persoan poate cumula unul sau mai multe roluri. n
cazul n care exist constrngeri n privina rolurilor, este necesar definirea acestora.

n cadrul fiecrei echipe, recomandm definirea rolului de coordonator unic de proiect care
trebuie asigurat de o singur persoan. Acest rol coordoneaz echipa proprie i are experiena,
capacitatea i autoritatea de a lua decizii n cadrul proiectului.

Ghid de achiziii software pentru instituiile publice | 27


n msura n care complexitatea proiectului o permite, aceast persoan poate fi i punctul de
contact unic din partea autoritii contractante sau a furnizorului.

n mod evident, nu putem recomanda configuraia echipei potrivita pentru orice proiect i nu
ne propunem acest lucru. Am ncercat ns n cele ce urmeaz s identificm cteva roluri des
ntlnite n cadrul proiectelor software.

Exemple de roluri posibile n echipa beneficiarului:

Coordonator proiect
Rolul este descris mai sus. n cazul proiectelor de dimensiune i complexitate mic, acesta
poate fi i unicul punct de contact n relaia cu furnizorul. n cazurile n care proiectul
permite, aceast abordare este foarte recomandat din raiuni de eficien.
Responsabil IT
n majoritatea cazurilor este necesar alocarea unui responsabil IT care cunoate detaliile
infrastructurii IT&C a beneficiarului. Aceast persoan poate clarifica detaliile tehnice i,
de asemenea, poate fi implicat n procesul de acceptan i implementare a sistemului.
Specialist domeniu / responsabil formulare cerine (ex: Specialist comunicare public)
n formularea cerinelor funcionale i ulterior n detalierea acestora, este necesar
implicarea specialitilor n domeniile respective de activitate. Acetia sunt persoane din
organizaia beneficiarului care cunosc n detaliu procesele de lucru, legislaia i problemele
cu care se confrunt organizaia. Iniial rolul acestora este de formulare a problemelor i
cerinelor funcionale. Ulterior, n cadrul proiectului, acetia vor fi implicai n detalierea
cerinelor funcionale, n validarea diverselor livrabile (specificaii, machet amd) precum
i n procesul de acceptan.
Project manager
n general acest rol va fi probabil ndeplinit de coordonatorul proiectului. n cadrul
proiectelor foarte complexe este util implicarea unuia sau mai multor specialiti n
project management din partea beneficiarului. Acest rol asigur planificarea activitilor n
echipa beneficiarului precum i coordonarea i validarea activitilor cu responsabilul din
partea furnizorului.
Utilizatori / viitori utilizatori
Implicarea utilizatorilor unui sistem existent sau a viitorilor utilizatori, reprezint o
modalitate foarte practic de a identifica problemele cu care acetia se confrunt, precum
i pentru a valida cerinele unui viitor sistem.
Dezvoltatori i alte roluri tehnice
n cazul n care beneficiarul dispune de echip proprie de dezvoltare, poate fi util
implicarea acestor specialiti n cadrul proiectului. Aceast implicare poate fi foarte
relevant n cazurile n care proiectul prevede integrri cu alte aplicaii utilizate de
beneficiar, precum i pentru preluarea sarcinilor tehnice ulterior ncheierii proiectului (ex:
extindere, mentenan etc.).

Echipa de roluri n echipa furnizorului

Coordonator proiect
Este recomandat ca Furnizorul s desemneze un responsabil unic de coordonarea
proiectului. Ca i n cazul beneficiarului, pentru proiecte de complexitate mic i eventual
medie, coordonatorul proiectului poate prelua i alte roluri n cadrul echipei i poate fi
unicul punct de contact pentru echipa beneficiarului. Este esenial ca aceast persoan
s aib putere de decizie n compania furnizorului, astfel nct s poat soluiona toate
situaiile aprute n derularea proiectului.
Project manager
Rol responsabil de planificarea activitilor furnizorului.
Coordonator echip tehnic
Coordoneaz echipa tehnic a furnizorului. n funcie de complexitatea proiectului poate
ndeplini i alte roluri tehnice n cadrul proiectului.
Arhitect soluii software
Responsabil de definirea arhitecturii software a soluiei livrate. Pentru proiecte de
complexitate foarte mare poate fi necesar un arhitect software dedicat.

Ghid de achiziii software pentru instituiile publice | 28


Arhitect baze de date
Responsabil de proiectarea bazelor de date.
Analist software
Responsabil de discuiile de analiz cu specialitii beneficiarului, de elaborarea
specificaiilor, realizarea machetelor funcionale, derularea testelor de acceptan etc.
Rolul analistului este unul cheie n derularea oricrui proiect software. Obiectivul principal
al analistului este s se asigure c problemele i cerinele beneficiarului sunt adresate
corespunztor n soluia software propus de furnizor. Analistul are, de asemenea, rolul
de a intermedia comunicarea dintre echipa tehnic a furnizorului i echipa de specialiti a
beneficiarului i de a clarifica eventualele inconsistene i blocaje.
Arhitect UI/UX
Rol responsabil de definirea principiilor i a arhitecturii interfeei utilizator (UI). Rolul de
arhitectului UI este de a asigura o experien utilizator (UX) ct mai intuitiv, consistent
i eficient. n cadrul proiectelor cu cerine deosebite n privina interfeei utilizator (ex:
aplicaii ghieu sau aplicaii online dedicate publicului) este important definirea acestui
rol.
Designer grafic UI / designer web
Responsabil de aspectul grafic al interfeei utilizator.
Dezvoltator software / Consultant implementare
Evident, din echipa furnizorului nu pot lipsi dezvoltatorii software n cazul soluiilor
personalizate sau consultanii de implementare n cazul implementrii de produse
software existente (ex: ERP, CRM, DM etc.). n funcie de cerinele proiectului,
specializrile dezvoltatorilor pot fi foarte diverse. Cteva posibile exemple de specializri
sunt: Web, Front-End, Baze de date, Full stack, BI, mobile, embedded. De asemenea,
dezvoltatorii pot fi specializaii n anumite tehnologii sau limbaje.
Tester / coordonator echip testare
Asigurarea de ctre furnizor a unei echipe de testare separat de echipa de dezvoltare
este o practic recomandat.
Administrator de sistem / infrastructur
Sistemele informatice utilizate, att n procesul de dezvoltare ct i dup punerea n
producie a soluiilor, necesita configurare, actualizri ale diverselor pachete de software
precum i intervenii n perioada de mentenan.

Echipa de conducere

Sponsori executivi
Att din partea beneficiarului cat si din partea furnizorului este recomandata identificarea
unui Sponsor executiv. Aceste persoane fac parte din echipele de conducere ale
beneficiarului si furnizorului si asigura o interfa permanent de comunicare la nivel nalt.

Not: n conformitate cu art 179, lit g) din legea 98/2016, n relaie cu aceast poziie, se pot
stabili criterii de calificare pentru personalul de conducere al instituiei, n msura n care astfel
de criterii sunt justificate si aceste persoane nu particip n echipa de implementare conform
Art. 32 alin (5) din HG 395/2016.

Comunicare
Asigurarea unei comunicri eficiente ntre echipa beneficiarului i a furnizorului este un aspect
cheie n succesul oricrui proiect software. De cele mai multe ori ntre cele dou echipe exist
iniial o barier de comunicare cauzat n principal de zonele de specialitate diferite. Eliminarea
acestei bariere trebuie s fie o prioritate pentru ambele echipe, iar primii pai n aceast direcie
constau exact n elaborarea unui caiet de sarcini pe ct de clar posibil.

Instrumente de comunicare structurat


Instrumentele de comunicare i colaborare folosite pot uura i structura comunicarea pe
parcursul proiectului. Utilizarea mijloacelor clasice de comunicare este evident implicit (telefon,
email, ntlniri). Pe lng acestea, recomandm ns i utilizarea unor instrumente de colaborare
moderne i structurate, spre exemplu portaluri de colaborare disponibile online, aplicaii cloud
pentru editare colaborativ (ex: Google Apps, Microsoft Office 365, suita Atlassian etc.), aplicaii
de comunicare online (soluii de tip forum sau de mesagerie) sau aplicaii de planificare a task-
urilor. Multe astfel de instrumente sunt gratuite sau presupun costuri rezonabile de utilizare i

Ghid de achiziii software pentru instituiile publice | 29


pot avea un impact foarte mare n buna desfurare a unui proiect.

Utilizarea unor astfel de instrumente poate asigura accesul imediat i transparent al echipelor
la toate detaliile legate de proiect (documente, detalii de contact, activiti, calendar, situaii
blocante samd). n caietul de sarcini putei prevedea cerina ca astfel de instrumente s fie
utilizate sau eventual chiar puse la dispoziie de ctre furnizor.

Identificarea i rezoluia blocajelor (Issue management)


Blocajele sunt inerente n cadrul oricrui proiect i pot fi cauzate de deficiente de comunicare,
de lipsa de resurse (inclusiv timp), de ntrzieri, de neclaritatea sau instabilitatea unor cerine i
multe alte cauze. Un prim pas n rezolvarea blocajelor este identificarea acestora.

Recomandm ca n orice proiect s fie definit un mecanism simplu i accesibil prin care orice
membru al celor dou echipe poate semnala apariia unui blocaj n proiect care are potenialul
de a afecta ntregul proiect. Acest mecanism poate presupune simpla comunicare a unui blocaj
ctre coordonatorii de proiect via email sau adugarea blocajului ntr-un sistem dedicat (ex: o
list dedicat ntr-un portal online sau un document tip spreadsheet).

Evidena centralizat a blocajelor active i adresarea acestora n cadrul ntlnirilor de proiect,


este o practic pe care o recomandm n orice proiect. Eliminarea ct mai rapid a acestor
blocaje este un obiectiv principal al coordonatorilor de proiect.

Raportarea progresului (Status reporting)


Pe parcursul proiectului este foarte recomandat s urmrii progresul nregistrat pentru a
evita eventualele surprize i ntrzieri la finalul proiectului. Prin urmare, indiferent de procesul
de dezvoltare folosit, este recomandat s prevedei nc din caietul de sarcini cerine minimale
privind raportarea progresului, ntlnirile de stadiu (status) i formatul acestora, precum i
eventualele documente pe care furnizorul trebuie s le pregteasc (rapoarte de stadiu/
status).

Recomandm ca frecvena ntlnirilor s fie ntre 2 i 4 sptmni, cu participarea obligatorie a


coordonatorilor de proiect, precum i a rolurilor cheie din fiecare echip.

Agenda acestor ntlniri trebuie s cuprind cel puin urmtoarele:

Msurarea progresului i identificarea eventualelor ntrzieri;


Eliminarea blocajelor aprute n cazul n care nu au fost adresate imediat;
Clarificarea eventualelor nelmuriri funcionale/tehnice;
Validarea livrabilelor intermediare i rezolvarea eventualelor inconsistene;
Demonstrarea funcionalitilor implementate (chiar i pariale) i rezolvarea eventualelor
diferene de ateptri.

3.8 Livrabilele proiectului


Care sunt rezultatele concrete ale proiectului?

Livrabilele proiectului reprezint toate elementele pe care furnizorul se angajeaz s le livreze


beneficiarului n cadrul contractului. Pe lng soluia software funcional care este evident
livrabilul principal, un proiect software cuprinde i alte elemente care sunt necesare n derularea
unui proiect i, ulterior, instalrii n mediul de producie. n cazul proiectelor de complexitate
medie i mare, urmrirea unui proces structurat de dezvoltare i elaborarea documentaiei de
proiect necesare poate face diferena ntre un proiect de succes i unul euat.

Caietul de sarcini trebuie s conin toate cerinele n privina livrabilelor pe care furnizorul
trebuie s le furnizeze n cadrul proiectului. Livrabilele intermediare sunt cel puin la fel de
importante ca soluia propriu-zis astfel nct solicitarea acestora nu trebuie lsat la voia
ntmplrii presupunnd c livrarea acestora este implicit.

Recomandm ca lista livrabilelor solicitate s fie descris ntr-un capitol separat al

Ghid de achiziii software pentru instituiile publice | 30


documentaiei de atribuire chiar dac livrabilele pot fi referine i n alte seciuni ale acesteia. De
asemenea, este de dorit ca pentru fiecare livrabil s fie detaliate cerinele minime de calitate pe
care trebuie s le respecte, precum i condiiile de acceptan. Recomandm, de asemenea, ca
i livrabilele intermediare s fac obiectul unor acceptane intermediare.

Lista propus mai jos conine o serie de livrabile comune ntlnite n cadrul proiectelor software.
Ca i n celelalte cazuri, trebuie privit ca un punct de plecare n elaborarea caietului de sarcini i
adaptat la cerinele dumneavoastr prin eliminarea sau adugare de noi elemente.

Cod surs
Codul surs poate fi transferat la finalul proiectului n cazul n care contractul prevede c
beneficiarul va deine proprietatea intelectual, precum i n cazul n care acordul de liceniere
prevede i posibilitatea modificrii codului surs de ctre beneficiar. Se pot prevedea, de
asemenea, i livrri intermediare.

IMPORTANT: Pentru a evita o relaie de dependen, trebuie s v asigurai c vei putea


modifica codul surs independent de furnizorul iniial, transfera codul surs ctre un alt furnizor
sau contracta un alt furnizor pentru modificri sau servicii de mentenan. Opiunile legale pe
care le avei la dispoziie sunt descrise n detaliu n capitolul 3.6 Cerine nefuncionale, seciunea
Legal i liceniere.

n astfel de cazuri putei specifica limba n care trebuie scris codul (adic limba folosit pentru
comentariile din cod, denumirea variabilelor, metodelor etc). De asemenea, putei solicita ca
codul surs s respecte anumite reguli i standarde de calitate.

Exemple de reguli de scriere a codului (coding guidelines):

Java - http://www.oracle.com/technetwork/java/index-135089.html
C# - https://msdn.microsoft.com/en-us/library/ff926074.aspx
PHP - http://www.php-fig.org/psr/psr-1/ / http://www.php-fig.org/psr/psr-2/

Kituri de instalare / executabile


Unul din livrabilele proiectului poate fi kitul de instalare al soluiei sau fiierele executabile
compilate. n cazul n care furnizorul va livra i un kit de instalare, acesta trebuie supus procesului
de acceptan. n cazul n care un kit de instalare nu este solicitat, este obligatoriu ns ca lista
de livrabile s includ un document ce descrie paii necesari pentru instalarea soluiei.

Documentaie de utilizare
Chiar dac sistemul software este intuitiv i uor de utilizat, este indicat ca orice sistem s
dispun de un manual de utilizare care s fie accesibil att n interiorul aplicaiei ct i online (web)
i offline (pdf, chm, etc.). Este important ca manualul de utilizare s acopere i funcionalitatea
complex a aplicaiei care poate nu este la fel de intuitiv.

Documentaie de administrare i operare


Documentaia de administrare i operare cuprinde instruciuni adresate administratorilor de
sistem care pot cuprinde:

Procedura de instalare a soluiei;


Monitorizarea parametrilor de funcionare a aplicaiei;
Administrarea utilizatorilor i a drepturilor;
Configurarea parametrilor tehnici;
Taskuri de mentenan recurente (ex: curaare loguri);
Raportarea i investigarea erorilor de funcionare;
Modaliti rapide de punere n funciune;
etc.

Orice modificare viitoare a soluiei trebuie s fie nsoit de actualizarea acestor documente.

Strategia de backup
Documentul descrie strategia de backup a sistemului i cuprinde:

Ghid de achiziii software pentru instituiile publice | 31


Elementele care trebuie salvate;
Frecvena salvrilor i tipul acestora;
Responsabilitile pentru backup;
Locaia unde sunt pstrate salvrile;
Perioada de pstrare a salvrilor anterioare;
Etc.

Procedura de recuperare n caz de dezastru


Procedura de recuperare n caz de dezastru conine paii exaci care trebuie urmrii pentru
restaurarea sistemului n cazul apariiei unui dezastru. Este important ca acest document s
fie testat i actualizat corespunztor pentru a fi imediat disponibil ntr-o situaie de urgen.
Recomandm ca procedura de recuperare s fie disponibil i ca document separat (chiar dac
poate face parte i din manualul de administrare).

Procedura de instalare
Procedura de instalare descrie toi paii necesari instalrii i configurrii sistemului. n mod
uzual, procedura de instalare trebuie s detalieze cerinele preliminare instalrii (prerequisites),
paii de instalare i configurare, precum i un set minimal de teste prin care se poate verifica
funcionarea corect a aplicaiei.

Viziune i scop (vision & scope)


Documentul de viziune i scop descrie scopul i obiectivele sistemului i este relevant ca prim
document ce trebuie parcurs de o persoan nou introdus n proiect. Documentul trebuie s
ofere o imagine de ansamblu asupra obiectivelor proiectului i a raiunilor acestuia. n mare,
acesta poate s conin descrierea instituiei, problemele actuale i obiectivele proiectului aa
cum au fost formulate n documentaia de atribuire.

Specificaie funcional i tehnic


Specificaia funcional i tehnic poate fi un document sau un set de documente n care
cerinele din caietul de sarcini sunt clarificate, detaliate i structurate sub forma de funcii sau
caracteristici tehnice.

Document de arhitectura i design


Documentul de arhitectura i design este n principal un document tehnic n care sunt
documentate deciziile tehnice majore luate n implementarea soluiei.

Documentul poate s cuprind urmtoarele:

Tehnologiile folosite;
Componentele logice;
Componentele fizice ale soluiei;
Modul n care componentele sunt conectate i comunic;
Protocoalele de comunicaie utilizate;
Componente tere folosite dac este cazul;
Eventuale paternuri utilizate;
etc.

Documentaia bazelor de date


n cazul n care soluia software presupune i utilizarea uneia sau a mai multor baze de date,
unul din livrabilele furnizate trebuie s fie documentaia bazei/bazelor de date. n cazul soluiilor
proprietare sau open-source, aceast documentaie nu este neaprat relevant, ns orice
extensie a soluiilor standard trebuie documentat inclusiv la nivelul bazelor de date.

Indiferent ns de tipul soluiei adoptate (proprietar, open-source sau personalizat) trebuie


s v asigurai c vei avea proprietatea datelor stocate i posibilitatea migrrii acestora n alt
soluie.

Documentaia solicitat poate s cuprind urmtoarele informaii:

Ghid de achiziii software pentru instituiile publice | 32


Diagrama bazei de date;
Descrierea tabelelor;
Semnificaia cmpurilor (cel puin a celor neintuitive);
Descrierea relaiilor dintre tabele;
Denormalizri n cazul n care exist;
Securitate (modul n care se realizeaz autentificarea i autorizarea la nivelul bazei dar i
alte detalii importante de securizare precum criptarea bazei de date, firewall pentru baza
de date sau parte de audit);
Strategia de indexare;
Constrngeri;
Elemente de programabilitate dac este cazul (proceduri stocate, funcii, view-uri etc.);
Etc.

Arhitectura Interfeei utilizator (UI)


Arhitectura interfeei utilizator detaliaz structura interfeei utilizator i regulile care
guverneaz interfaa i poate cuprinde urmtoarele:

Tipurile de ecrane si structura fiecruia;


Principiile de prezentare a informaiei;
Structura meniurilor;
Adaptabilitate la diverse dimensiuni de ecran dac este cazul;
Mecanismele de navigare ntre ecrane;
Modul de prezentare a erorilor de validare;
Modul de prezentare a mesajelor i alertelor;
Comportamentul controalelor de input;
Elemente reutilizabile de interfa;
Persistarea preferinelor de interfa dac este cazul;
etc.

Existena unui document de arhitectur UI asigur dezvoltarea unei interfee utilizator


consistente.

Macheta interfeei utilizator (UI)


Macheta interfeei utilizator (sau prototipul UI) este un livrabil cheie n cadrul unui proiect care
implic i o interfaa utilizator. Macheta poate fi un document sau chiar o aplicaie n care doar
interfaa utilizator este funcional fr ca logica aplicaiei s fie implementat. Scopul machetei
este s ilustreze vizual modul n care cerinele funcionale vor fi implementate practic.

Acest livrabil este foarte important pentru c este foarte uor de neles de ctre viitorii
beneficiari ai sistemului care pot vizualiza i interaciona cu viitoarea aplicaie. Astfel,
eventualele erori sau nenelegeri ale cerinelor pot fi corectate nc de la nceputul proiectului
cu costuri mult mai mici. Macheta poate fi folosit ca referin i de ctre dezvoltatori pe
parcursul implementrii.

Macheta este realizat n paralel cu specificaia funcional i trebuie livrat i acceptat la


nceputul proiectului nainte de a ncepe dezvoltarea efectiv. O machet corect realizat va
corespunde n foarte mare msur cu aplicaia final.

Pentru ca o machet s fie relevant n cadrul proiectului, aceasta trebuie s fie interactiv,
respectiv s permit viitorilor utilizatori s interacioneze prin navigare, completarea
formularelor etc. n cazul n care macheta este compus doar din ecrane statice beneficiile
aduse vor fi mai mici.

Machetele UI pot fi mprite n trei categorii:

Fidelitate sczut (low fidelity) - schie desenate de mn sau folosind programe de


desen;
Fidelitate medie - acestea pot fi realizate folosind aplicaii specializate pentru machetare
sau pot chiar s fie programate. Machetele de fidelitate medie ilustreaz structura
interfeei i toate detaliile de interfa fr ns a prinde i design-ul grafic final al soluiei;

Ghid de achiziii software pentru instituiile publice | 33


Fidelitate mare (Hi fi) - machetele de fidelitate mare cuprind i detaliile grafice i alte
efecte ale interefeei i evident presupun un efort mare de implementare.

Machetele de fidelitate medie ofer un compromis foarte bun ntre costurile relativ sczute de
realizare i beneficiile pe care le aduc i sunt astfel recomandate n majoritatea proiectelor.

Recomandm, de asemenea, ca machetele UI s fie realizate folosind instrumente dedicate


pentru machetare care ofer productivitate i permit iterarea rapid (Balsamiq, Axure,
Justinimd, Moqups etc.).

IMPORTANT: n cazul n care macheta UI este dezvoltat prin scriere de cod (de exemplu: o
aplicaie web sau desktop), acest cod nu trebuie folosit n cadrul proiectului efectiv. Motivul
este c n dezvoltarea machetei sunt acceptabile compromisuri privind calitatea codului pentru
a ctiga productivitate, compromisuri care ns nu pot fi acceptate pentru soluia final.

Design grafic interfa utilizator (UI)


Designul grafic ilustreaz modul n care interfaa utilizator va arta dup implementare i
cuprinde schema de culori folosit, fonturi, spaierea elementelor etc. n general, designul grafic
presupune livrarea unor propuneri grafice sub form de imagini statice (jpeg, pdf) cu ecrane
relevante din aplicaie.

n cazul n care instituia beneficiarului trebuie s respecte anumite criterii unitare de identitate
sau identitatea grafic a fost stabilit anterior, este important s comunicai toate aceste
cerine prin intermediul caietului de sarcini.

Plan de testare
Planul de testare documenteaz strategia de testare a aplicaiei i poate include:

Metodele de testare;
Mediul de testare;
Descrierea rolurilor n echipa de testare;
Responsabiliti n cadrul echipei de testare;
Lista de funcionaliti testate sau excluse de la testare;
Criteriile de succes i eec ale testelor;
Modul de clasificare al defectelor (severitate, frecven, prioritate etc.);
Calendarul testelor.

Se recomand ca planul de testare s aib anexat i lista testelor folosite (cazuri de test),
precum i detaliile acestora (pai de testare, rezultate ateptate etc.).

Plan de teste de acceptan


Planul de teste de acceptan cuprinde testele pe care sistemul trebuie s le treac pentru a fi
acceptat. De asemenea, planul de acceptan detaliaz criteriile care trebuie ndeplinite pentru
ca soluia s fie acceptat.

n general, planul de acceptan este elaborat de ctre furnizor la nceputul proiectului, ns


validarea coninutului este prerogativul beneficiarului.

Aplicaii conexe
Pe lng soluia software, exist situaii n care sunt dezvoltate i alte aplicaii conexe. Acestea
ar putea fi diverse instrumente/aplicaii de administrare sau configurare, aplicaii utilizate
pentru mentenan, scripturi de migrare a datelor sau alte scripturi utilitare. n cazul n care
astfel de aplicaii fac parte din scopul proiectului, este util solicitarea acestora n caietul de
sarcini.

Hardware
n mod evident, n cazul n care prin caietul de sarcini este solicitat i hardware, acesta trebuie
menionat n lista de livrabile.

Ghid de achiziii software pentru instituiile publice | 34


Cloud
n situaia n care necesarul hardware, de stocare sau de procesare variaz puternic n timpul
exploatrii aplicaiei sau dorii soluii cu un nalt grad de disponibilitate, este recomandat s luai
n calcul i soluiile oferite de furnizorii de cloud-computing. O astfel de soluie v poate oferi
flexibilitate n modificarea infrastructurii sau metode de a reduce costurile n momentele n care
aplicaia dumneavoastr nu este ncrcat (de exemplu: pe timpul nopii dac aplicaia are o
ncrcare mare doar n timpul zilei).

n cazul n care soluia presupune sau permite utilizarea platformelor de cloud-computing


(Microsoft Azure, Amazon AWS, IBM Cloud, Oracle Cloud, Digital Ocean, etc.), acest lucru
trebuie prevzut n caietul de sarcini. Costurile de utilizare ale acestor platforme variaz n
funcie de utilizare, astfel estimarea costurilor n faza de ofertare poate fi foarte dificil. Din
acest motiv recomandm s solicitai n mod explicit detalierea structurii acestor costuri pe
ntreaga durat a proiectului. n cazul n care aceste costuri vor fi suportate de beneficiar, este
indicat facturarea sau refacturarea transparent de ctre furnizor (respectiv justificarea
detaliat a consumului). n cazul n care aceste costuri vor fi suportate de furnizor, avnd n
vedere dificultatea estimrii acestora, este recomandat alocarea unui limite de buget (lunar/
anual) pn la care furnizorul va suporta aceste costuri, eventual cu reportarea surplusului
neconsumat.

Servicii conexe
Apar i situaii n care sunt solicitate furnizorului i alte servicii conexe care nu sunt neaprat
implicite. Astfel de exemple ar putea fi servicii de instalare i punere n funciune hardware,
servicii de configurare de infrastructur (hardware, comunicaii, software de baz), teste de
securitate, alte servicii de consultan etc. Toate aceste servicii trebuie solicitate explicit n
caietul de sarcini.

3.9 Procesul de acceptan


Cum vom verifica i valida rezultatele proiectului?

Procesul de acceptan este procesul prin care toate livrabilele proiectului sunt validate i
recepionate de ctre beneficiar ca fiind conforme cu cerinele formulate i cu obligaiile
asumate de furnizor. Astfel, procesul de acceptan nu se refer doar la acceptarea final a
soluiei software (acceptana final), ci i la acceptane intermediare, care sunt derulate pe
parcursul proiectului, pentru validarea livrabilelor intermediare sau conexe proiectului (ex:
specificaii, machet, hardware etc).

Caietul de sarcini este referina principal i fundaia oricrui proiect. Un caiet de sarcini cu
cerine clare i detaliate va facilita procesul de acceptan, n timp ce un caiet de sarcini vag sau
succint poate conduce chiar la imposibilitatea refuzrii unor livrabile de slab calitate. Din acest
motiv este important s specificai n caietul de sarcini criteriile de acceptare sau refuzare,
precum i criteriile de calitate i gradul de detaliere necesar pentru celelalte livrabilele ale
proiectului, altele dect soluia propriu-zis.

Cu excepia proiectelor care au nc din faza de licitaie pregtit o specificaie tehnic detaliat
anexat caietului de sarcini (care poate este rezultatul unui proiect de consultan separat), de
cele mai multe ori proiectele software ncep cu o faz de analiz detaliat a cerinelor. Scopul
analizei este clarificarea i detalierea cerinelor formulate n caietul de sarcini i are ca rezultat
principal specificaia tehnic i funcional, macheta funcional i, n funcie de proiect, i alte
livrabile (design grafic, arhitectur, design-ul bazelor de date etc.).

n cadrul fazei de analiz este foarte posibil ca anumite cerine formulate iniial n caietul de
sarcini s se transforme prin detaliere, alte cerine este posibil s fie eliminate i la fel de posibil
este ca noi cerine s fie identificate, care nu au fost observate iniial. ntr-o anumit msur,
astfel de modificri sunt normale i sunt rezultatul negocierii unui compromis constructiv
ntre beneficiar i furnizor. ntr-o astfel de negociere caietul de sarcini devine un document de
referin. i, n aceast situaie, un caiet de sarcini clar i detaliat va ajuta la rezolvarea rapid a
blocajelor, n timp ce un caiet de sarcini vag poate genera blocaje insurmontabile.

Ghid de achiziii software pentru instituiile publice | 35


Este recomandat ca specificaiile tehnice i funcionale, macheta funcional (dac exist),
precum i celelalte livrabile care presupun obligaii pe care furnizorul i le asum n privina
soluiei software, s fie supuse unui proces de acceptan intermediar i s devin partea a
contractului (prin anexarea sau prin menionarea efectelor acestor livrabile n contract). n acest
fel, specificaiile tehnice pot fi folosite ca referin n procesul de acceptan. De asemenea, n
cazul n care caietul de sarcini nu era suficient de clar, faza de analiz este o oportunitate pentru
a ndrepta situaia.

Acceptana final i teste de acceptan


n procesul de acceptan final, specificaiile tehnice devin documentul de referin pentru
validarea conformitii soluiei software. Cu alte cuvinte, soluia software final trebuie s
respecte cerinele tehnice i funcionale definite n specificaie.

Pentru derularea procesului de acceptan este recomandat utilizarea unui plan de acceptan.
Acest document este realizat i agreat n timpul sau imediat dup faza de analiz i cuprinde
testele pe care sistemul trebuie sa le treac cu succes pentru a fi considerat conform. Chiar
dac planul de teste de acceptan este realizat de furnizor, coninutul acestuia trebuie validat
i agreat de beneficiar. n aceast privin trebuie s v asigurai c, cel puin funcionalitile
cheie ale sistemului precum i cerinele nefuncionale, sunt acoperite de testele prevzute n
planul de acceptan.

Pe lng testarea funcionalitii (cerinele funcionale), este foarte recomandat s verificai


i ndeplinirea cerinelor tehnice/nefuncionale, n special dac aceste cerine sunt importante
pentru proiect (performan, securitate, disponibilitate, redundan etc.).

De asemenea procesul de acceptan trebuie s valideze i celelalte livrabile ale proiectului n


cazul n care acestea nu au fcut obiectul acceptanelor intermediare.

IMPORTANT: testarea anumitor cerine nefuncionale poate presupune derularea de teste


specializate care pot presupune un efort considerabil din partea furnizorului. n astfel de
situaii trebuie ca aceste cerine s fie cuprinse n caietul de sarcini. Exemple: ndeplinirea unor
cerine speciale de securitate poate presupune teste de penetrare sau un audit de securitate,
ndeplinirea cerinelor de performan poate presupune teste de performan dedicate (load
testing) etc.

n situaia n care un plan de teste de acceptan nu este definit, este indicat s acoperii prin
testele de acceptan toate cerinele soluiei.

IMPORTANT: Prin procesul de acceptan pe care l definii trebuie s v asigurai c acceptana


nu se rezum doar la testele incluse n planul de acceptan i c vei avea libertatea de a derula
i alte teste proprii care pot cauza inclusiv refuzul sau observaii ale procesului de acceptan.

Caietul de sarcini trebuie s detalieze modul n care se va desfura procesul de acceptan.


Printre detaliile care trebuie menionate se numr urmtoarele:

Durata alocat testelor de acceptan


Cu ct sistemul este mai complex, cu att durata rezervat pentru acceptan trebuie sa fie
mai mare.

Mediul/infrastructura de testare
Mediul tehnic (servere, instane cloud etc) pentru derularea testelor de acceptan poate fi
chiar cel pe care soluia urmeaz s funcioneze. Este ns mult mai indicat ca un mediu tehnic
dedicat, ct mai similar (preferabil identic), s fie utlizat pentru testele de acceptan i, ulterior,
pentru alte teste (denumit mediu staging, de test sau pre-producie).

Responsabilitatea testrii.
Testele de acceptan trebuie derulate de personalul beneficiarului cu eventuala participare a
furnizorului.

Ghid de achiziii software pentru instituiile publice | 36


Clasificarea defectelor
Pe parcursul testelor de acceptan vor fi descoperite defecte care nu au fost identificate
de furnizor n testele proprii. Clasificarea acestor defecte este important pentru stabilirea
criteriilor de acceptan. O clasificare uzual a defectelor este:

O clasificare uzual a defectelor este:

Defecte majore. Defecte care blocheaz parial sau integral o funcionalitate important a
aplicaiei fr a exista o cale de ocolire (workaround);
Defecte medii. Defecte care blocheaz parial o funcionalitate pentru care exist o cale
de ocolire (workaround) sau defecte care blocheaz o funcionalitate non-critica;
Defecte minore. Defecte care nu impiedic funcionarea sistemului dar pot genera un
efort suplimentar pentru utilizatori pentru ocolirea lor;
Defecte cosmetice. Defecte ale interfeei utilizator, greeli de ortografie, mici probleme de
compatibilitate etc.

Rezultatul procesului de acceptan


O practic ntlnit este ca rezultatul procesului de acceptan s se ncheie cu unul din
urmtoarele rezultate:

Acceptat;
Acceptat cu observaii minore;
Acceptat cu rezerve;
Refuzat.

Pentru fiecare caz trebuie stabilite criterii clare care se refer n general la numrul i tipul
defectelor obinute i, eventual, la timpul n care acestea pot fi rezolvate. Spre exemplu, pentru
acceptarea fr observaii, criteriul aplicabil ar putea fi derularea acceptanei fr identificarea
vreunui defect (situaie foarte puin probabil), n timp ce acceptat cu observaii minore ar
presupune identificare numai a unor defecte mici sau cosmetice care pot fi remediate ntr-un
termen scurt bine specificat (ex: 1-2 sptmni).

Consecinele rezultatelor acceptanei trebuie documentate n documentaia de atribuire. Spre


exemplu, acceptarea proiectului cu observaii sau rezerve ar putea presupune ca furnizorul s
remedieze defectele observate ntr-un termen prestabilit n documentaia de atribuire.

Refuzul este situaia ale crei consecine trebuie definite foarte bine n caietul de sarcini
deoarece poate presupune consecine legale i financiare importante. Refuzul poate presupune
rezilierea imediat a contractului i eventuale penaliti pentru furnizor. De asemenea, refuzul
poate presupune reluarea testelor de acceptan dup scurgerea unei perioade prestabilite
n care furnizorul poate remedia defectele soluiei. Este recomandat ca impactul legal i
financiar (ex: blocarea plilor, penalizri, reziliere) al rezultatelor acceptanei s fie detaliat n
documentaia de atribuire i reluat n contractul cu furnizorul.

Procesul verbal de acceptan


Procesul de acceptan are ca rezultat ncheierea unui proces verbal de acceptan formal.
Acest document trebuie s conin observaiile beneficiarului, defectele identificate i
eventualele observaii ale furnizorului. n cazul n care este necesar, documentul trebuie s
conin i soluiile necesare pentru defectele identificate dac aceste soluii nu sunt evidente.

Procesul verbal trebuie s conin i termenul agreat pn la care defectele vor fi remediate
sau de la care va fi reluat procesul de acceptan n cazul refuzului. De asemenea, n cazul n care
punerea n funciune a sistemului este amnat din cauze care in exclusiv de furnizor (cum ar
fi remedierea unor defecte identificate n procesul de acceptan), garania oferit de furnizor
trebuie prelungit corespunztor.

Ghid de achiziii software pentru instituiile publice | 37


3.10 Cerine post implementare
Ce alte activiti vor fi necesare pe durata de via a soluiei?

Serviciile post implementare sunt serviciile derulate ulterior instalrii n producie a soluiei
software sau ulterior a acceptanei finale.

Ciclul de via al unei soluii software nu se ncheie n momentul n care soluia este instalat
n producie. Din acest motiv este foarte important ca autoritatea contractant s prevad
activitile care vor fi necesare pe toat durata de via a soluiei. Aceste activiti pot fi
asigurate att de echipa intern a autoritii contractante, ct i de furnizorul soluiei i, n cele
mai multe cazuri, este recomandat o abordare mixt.

n cazul n care serviciile post implementare trebuie asigurate parial sau integral, de ctre
furnizor, acest aspect trebuie specificat clar n documentaia de atribuire. De asemenea
autoritatea contractant trebuie s prevad un buget pentru aceste servicii. Costurile pentru
aceste servicii pot lua forma unui abonament lunar sau anual.

3.10.1 Servicii de configurare i actualizare

Aceste servicii asigur funcionarea n parametri normali a soluiei software i pot s acopere
partea software (configurri i actualizri ale versiunilor unor componente utilizate) dar i
partea de infrastructur (arhitectura de reea, configurri i actualizri ale softwareului aferent
infrastructurii informatice, modernizri ale infrastructurii etc).

3.10.2 Suport tehnic

Suportul tehnic presupune servicii de asisten tehnic oferite utilizatorilor i beneficiarului


pentru ca soluia s poat fi folosit n condiii normale. Suportul tehnic rspunde la ntrebri
de baz ale utilizatorilor (ex: cum s fac ..), rezolv probleme tehnice mai avansate (ex:
configurri, parametrizri) i, n acelai timp identific eventuale defecte ale soluiei.

Serviciile de suport tehnic pot fi accesibile prin telefon, mail sau, cel mai indicat, prin soluii
online de tip help-desk integrate n aplicaie. Recomandm s solicitai ca acest serviciu s fie
disponibil n timpul orelor dumneavoastr uzuale de activitate i s specificai timpii maximi de
rspuns dorii.

Suportul tehnic poate fi ncadrat n 5 niveluri:

Nivel 0 suportul tehnic de care beneficiaz utilizatorii fr a contacta un serviciu dedicat.


Acesta poate fi sub form de manuale de utilizare, tutoriale, sisteme tip knowledgebase, forum-
uri, liste de probleme cunoscute i modaliti de ocolire etc. Chiar dac acest tip de suport nu
reprezint un serviciu propriu-zis, este foarte recomandat s introducei astfel de materiale
pentru a reduce considerabil costurile de suport tehnic.

Nivel 1 reprezint prima linie de suport adresata utilizatorilor finali ai soluiei. n general aici
sunt rezolvate problemele de baz de utilizare a soluiei. De asemenea, la acest nivel, sunt
identificate eventualele incidente care sunt escaladate la nivelurile superioare de suport (ex:
defecte).

n cazul n care instituia dumneavoastr poate asigura serviciile de suport de nivel 1 adresat
utilizatorilor finali, este o variant foarte recomandat care poate reduce semnificativ costurile
de suport.

Nivel 2 nivel la care sunt adresate probleme tehnice mai avansate (ex: probleme de
configurare i parametrizare a soluiei, confirmarea defectelor) care ns nu implic neaprat
intervenii la nivelul codului surs. Acest nivel de suport este asigurat n general de persoane
care cunosc bine soluia i, preferabil, dein un nivel bun de cunotine tehnice. i n acest

Ghid de achiziii software pentru instituiile publice | 38


caz, pentru reducerea costurilor, atunci cnd este posibil, nivelul 2 poate fi asigurat de ctre
personalul beneficiarului (ex: departamentul IT).

Nivel 3 reprezint cel mai avansat nivel de suport tehnic. n general aceste servicii sunt
asigurate de echipa tehnic de implementare a furnizorului. La acest nivel sunt reproduse i
rezolvate eventualele defecte identificate la nivelul 2.

Nivel 4 la ultimul nivel sunt serviciile de suport asigurate de furnizorii hardware i software
de baz. Acest nivel asigur rezolvarea unor defecte identificate n infrastructura hardware/
software care depesc capacitatea furnizorului de rezolvare (ex: defecte ale sistemelor de
baz de date, ale browserelor internet sau ale sistemelor de operare).

3.10.3 Garanie

Serviciile asigurate n perioada de garanie fac parte, de asemenea, dintre serviciile post
implementare. n perioada de garanie furnizorul va repara pe cheltuial proprie eventualele
defecte identificate de suportul tehnic (level 2-3).

3.10.4 Servicii de intervenie

Acestea sunt serviciile prin care furnizorul garanteaz timpi de intervenie pentru identificarea
i rezolvarea de probleme ce nu permit utilizarea n parametri normali a soluiei. Este important
ca aceste servicii s acopere perioadele de utilizare intens ale soluiei. Din raiuni financiare,
nu este recomandat achiziionarea de pachete de tip 24x7 daca soluia nu este utilizat
permanent.

3.10.5 Servicii de monitorizare i prevenie

Aceste servicii presupun monitorizarea recurent a funcionrii soluiei cu scopul evitrii


unor probleme de funcionare n viitor. Acestea pot include monitorizarea log-urilor soluiei,
monitorizarea parametrilor de funcionare (utilizare procesor, spaiu alocat, memorie utilizat
etc), optimizarea indecilor folosii de bazele de date, executarea periodic a diverselor
proceduri critice (ex: disaster recovery) sau monitorizarea performanei aplicaiei.

3.10.6 Instruire

Instruirea personalului beneficiarului se va face att la nceperea exploatrii soluiei software,


ct i periodic sau la apariia de personal nou n echipa beneficiarului. Nevoile de instruire difer
de la beneficiar la beneficiar, de la proiect la proiect, ns ignorarea lor va reduce dramatic ansele
de succes ale soluiei. Recomandm lectura unui studiu realizat n 2011 (Cushing Anderson, IDC,
Impact of Training on Project Success) ce a artat c proiectele ce au alocat peste 6% din
buget pentru instruire au avut o rat de succes mult mai mare fa de cele ce au alocat sub 3%.

3.10.7 Servicii de modificare/extensie

Autoritatea contractant poate s solicite furnizorului alocarea unui buget de efort lunar sau
anual care s acopere mici ajustri i modificri ale soluiei. Acestea pot fi de obicei incluse
sub form de abonament periodic (lunar sau anual), i asigur disponibilitatea specialitilor
furnizorului, n limita orelor incluse n abonament, pentru implementarea de mici ajustri sau
modificri ale soluiei, suficient de mici ct s nu justifice un proces nou de achiziie (ajustri
pentru adaptare la modificrile legislative, mici modificri n fluxurile instituiei etc). n lipsa
contractrii acestor servicii, furnizorul nu va fi obligat s rezolve astfel de cerine n timp util
pentru dumneavoastr.

Ghid de achiziii software pentru instituiile publice | 39


3.10.8 Parametrii de performan ai serviciilor (SLA Service Level Agreement)

n formularea cerinelor privind serviciile post implementare este important definirea


parametrilor de performan ai acestor servicii pe care furnizorul trebuie s i respecte. Civa
parametri relevani sunt enumerai n cele ce urmeaz.

Disponibilitate suport tehnic perioada n care serviciile de suport tehnic sunt disponibile
sau, mai exact, n care echipa de suport tehnic este disponibil (ex: 24 x 7 disponibilitate
permanent 24 de ore n 7 zile, 8x5 disponibilitate n timpul programului normal de lucru
sptmnal 8 ore/zi etc.).

Timp de rspuns timpul de rspuns la incidentele de suport tehnic sesizate. Acesta poat s
varieze n funcie de gravitatea incidentelor. Timpul de rspuns nu asigur neaprat i o soluie
a incidentului reclamat.

Timp de soluionare temporar (workaround) timpul n care furnizorul trebuie s asigure


o soluie temporar incidentului reclamat. i acest timp poate varia n funcie de gravitatea
incidentului sau defectului.

Timp de soluionare permanent timpul n care furnizorul trebuie s asigure o soluie


permanent/final incidentului reclamat.

Timp de prezena on-site timpul n care furnizorul trebuie s asigure prezena specialitilor
proprii on-site pentru incidente critice.

Numar de incidente on-site numrul de solicitri de prezen on-site la care furnizorul trebuie
s raspund lunar sau anual.

Timp de alocare timpul n care furnizorul trebuie s aloce specialiti pentru solicitrile de
modificare ale beneficiarului dac astfel de servicii au fost contractate.

Disponibilitate de efort garantat efortul pe care furnizorul trebuie s l asigure pentru


cerinele de modificare ale beneficiarului dac astfel de servicii au fost contractate.

3.11 Structura financiar


Ct va costa proiectul?, Cum vor fi ealonate plile?, Exist costuri
ascunse?

Structura financiar prevzut n caietul de sarcini trebuie s cuprind planul financiar al


proiectului. n principal acesta cuprinde structura plilor ce urmeaz s fie efectuate i
condiiile n care aceste pli vor fi fcute.

Recomandm ca planul de pli s fie corelat cu livrabilele importante ce urmeaz s fie livrate
de furnizor i s corespund efortului depus pentru realizarea acestora. Evident, livrabilele
respective vor fi supuse unui proces de acceptan intermediar iar plile vor fi condiionate de
succesul procesului de acceptan.

n structura financiar a proiectului trebuie s inei cont i de faptul c firmele active n industria
software au costuri mari de operare recurente, n special cu personalul (costuri salariale lunare),
care nu pot fi susinute pe termen lung fr finanare. Evident, un furnizor aflat n dificultate
financiar nu este o situaie de dorit. Astfel, n structurarea plilor, este recomandat s gsii
un echilibru corect ntre interesele instituiei dumneavoastr i presiunea financiar pe care o
va suporta furnizorul. Acest aspect este cu att mai important pentru proiectele care cuprind
hardware sau licene care pot avea costuri considerabile pe care furnizorul nu le poate finana
pe perioade lungi.

O recomandare ferm n privina structurii financiare este dificil de oferit ns, n funcie de

Ghid de achiziii software pentru instituiile publice | 40


complexitatea i durata proiectului, sugerm ca plile programate s nu fie mai frecvente
dect o plat lunar, i nu mai rare dect o plat la trei luni, excluznd eventualul avans sau plata
aferent livrrii finale. Un numr foarte mare de pli poate presupune i un efort suplimentar
considerabil pentru validarea livrabilelor, n timp ce un numr prea mic de pli poate presupune
riscuri privind progresul i rezultatul final al proiectului, precum i o posibil presiune financiar
pe furnizor.

n cazul n care un avans este prevzut contractual, acesta poate s acopere eventual parial
efortul iniial al furnizorului pn la prima plat programat, cu respectarea prevederilor legale
cu privire la efectuarea de pli n avans din fonduri publice. Dac proiectul presupune i achiziii
de hardware i licene software, avansul poate fi mai mare pentru a acoperi cel puin parial
costurile furnizorului.

Pentru plile ulterioare acceptanei finale este recomandat s rezervai un procent relevant
din valoarea proiectului. De asemenea, pentru garania de bun execuie, trebuie rezervat un
procent din valoarea proiectului. n multe cazuri garania de bun execuie este constituit de
furnizor la nceputul proiectului (ex: scrisoare de garanie, transfer) i restituit furnizorului la
finalul perioadei de garanie. n cazul n care garania este asigurat pe o perioad mare, exist
posibilitatea restituirii pariale pe parcurs.

Alte costuri

Orice soluie software presupune i costuri viitoare pentru mentenan, operare, dezvoltri
ulterioare, upgrade-uri. Pe ct posibil trebuie s v asigurai c aceste costuri pot fi inute sub
control i nu genereaz o situaie de captivitate pentru instituia dumneavoastr.

n cazul n care contractul presupune servicii pe care furnizorul trebuie s le ofere n viitor, care
eventual nu sunt prinse n contractul iniial (ex: dezvoltri ulterioare, mentenan) este indicat
s agreai costul acestor posibile servicii, sub forma de tarif orar/zilnic, precum i condiiile n
care acest pre poate varia (ex: indexare anual cu indexul inflaiei sau cu un procent maxim).

n cazul soluiilor software bazate pe produse existente, upgrade-urile de software (versiuni


minore, majore) pot presupune costuri suplimentare i servicii conexe (actualizare, testare,
adaptare configurri etc). Caietul de sarcini trebui s prevad dac aceste versiuni noi trebuie
asigurate gratuit de furnizor n preul iniial al contractului pentru o anumit perioad sau vor fi
furnizate contra cost. n cazul variantei contra cost, aceste costurile trebuie s fie predictibile,
n timp ce preul serviciilor conexe trebuie agreat n prealabil (tarif orar/zilnic pe tip de resurse).

Estimarea costului total

n cadrul procedurilor de achiziie n care criteriul de atribuire este cel mai bun raport calitate-
cost, propunerea financiar a furnizorului trebuie s includ i informaiile necesare evalurii
de cost sau chiar o evaluare de cost realizat de furnizor ce va trebui validat de autoritatea
contractant.

Ghid de achiziii software pentru instituiile publice | 41


4. CRITERII DE ATRIBUIRE
Legislaia n vigoare prevede ca i criterii aplicabile n cadrul achiziiilor publice urmtoarele:

Criterii de calificare i selecie;


Criterii de atribuire

n aceasta prim versiune, ghidul i propune sa abordeze strict problematica criteriilor de


atribuire, fr a acoperi criteriile de calificare i criteriile de selecie. Aceast tem ar putea fi
eventual abordat n cadrul unei versiuni ulterioare a ghidului.

4.1 Cadrul legislativ


n vederea stabilirii criteriilor de atribuire trebuie aplicate prevederile Legii nr. 98/2016 privind
contractele de achiziii publice precum i a normelor metodologice aprobate prin HG. 395/2016.

Chiar daca n acest ghid ncercam s rezumm cadrul legal, este necesar ca la stabilirea criteriilor
de atribuire s respectai urmtoarele prevederi legislative:

Capitolul IV, Seciunea a 7-a Criterii de atribuire, Art. 187-192din Legea nr.98/2016
Capitolul al II-lea, Seciunea a 4-a, Paragraful 3 Stabilirea criteriului de atribuire, Art. 32-
34 din HG nr. 395/2016

Legea nr. 98/2016 este disponibila pe site-ul ANAP la adresa:


http://anap.gov.ro/web/wp-content/uploads/2016/05/L98_2016.pdf

Hotrrea Guvernului nr 395/2016 este de asemenea disponibil pe site-ul ANAP la adresa:


http://anap.gov.ro/web/wp-content/uploads/2016/06/HG395_16.pdf

Conform art 187 alin (3) din lege, autoritatea contractant are dreptul de a aplica unul din
urmtoarele criterii de atribuire:

a. Preul cel mai sczut;


b. Costul cel mai sczut;
c. Cel mai bun raport calitate-pre;
d. Cel mai bun raport calitate-cost.

Conform art. 187 alin (8) autoritatea contractant nu va utiliza costul cel mai sczut/preul
cel mai sczut drept criteriu de atribuire n cazul anumitor categorii de contracte de achiziie
public/acorduri-cadru de lucrri sau de servicii care au ca obiect servicii intelectuale i care
presupun activiti cu nivel de complexitate ridicat.

Mai mult dect att, n conformitate cu normele metodologice HG nr. 395/2016 art. 32, alin.
(6), singurele criterii aplicabile n cazul proiectelor de complexitate ridicat sunt Cel mai bun
raport calitate-pre sau Cel mai bun raport calitate-cost

Avnd n vedere c implementarea unei soluii software presupune n mod evident activiti cu
nivel de complexitate ridicat, singurele criterii aplicabile legal i pe care le recomandm pentru
achiziia de soluii software sunt Cel mai bun raport calitate-pre sau Cel mai bun raport
calitate-cost.

Este important de subliniat c prevederile legale menionate mai sus se refer strict la servicii
intelectuale.

n cazul n care achiziia dumneavoastr presupune i achiziii de hardware sau produse software
comercializate de mai muli ageni economici (ex: sisteme de operare, sisteme de baze de date
sau alte produse software ce pot fi achiziionate separat), achiziia poate fi separat n loturi
cu criterii diferite de atribuire sau n achiziii distincte, iar n situaia n care achiziia privete

Ghid de achiziii software pentru instituiile publice | 42


produse cu un grad ridicat de standardizare, atunci se poate utiliza i criteriului de atribuire
preul cel mai sczut / costul cel mai sczut.

Practica separrii n loturi este reglementat de Art. 141 din Legea nr. 98/2016.

4.2 Metodologie de evaluare


n conformitate cu art 190 din Legea nr. 98/2016, autoritatea contractant stabilete factorii de
evaluare i ponderea acestora n evaluarea final. De asemenea, conform Art. 32 alin.(2) din HG
nr.395/2016, factorii de evaluare precum i algoritmul de punctare trebuie precizate n mod clar
i detaliat n cadrul documentaiei de atribuire.

n cazul n care stabilirea unor ponderi nu este posibil din motive obiective, autoritatea
contractant are opiunea de a indica factorii de evaluare n ordinea importanei (conform art
190 (3) din Legea nr 98/2016).

Pentru cazurile n care se pot stabili ponderi obiective, n funcie de numrul de criterii pe care
dorii s le folosii pentru atribuire, propunem dou metodologii de evaluare:

Evaluare cu un nivel de criterii, aplicabil pentru un numr limitat de criterii (sub 10);
Evaluare cu dou niveluri de criterii, aplicabil pentru achiziii complexe unde sunt folosite
multe criterii de evaluare.

Diferena dintre cele dou metode este strict organizatoric, din punct de vedere matematic
cele dou metode sunt perfect echivalente.

4.2.1 Evaluare cu un nivel de criterii

Metoda presupune alegerea unui set de criterii direct evaluabile i stabilirea unor ponderi
procentuale pentru fiecare. Suma ponderilor asociate criteriilor trebuie s fie 100%.

Grila de evaluare prevzut n caietul de sarcini ar putea fi structurat astfel (acesta este doar
un exemplu de calcul pentru a ilustra structura grilei i modul de evaluare):

Criteriu Pondere
Preul achiziiei 25%
Calitatea tehnic a arhitecturii propuse 10%
Calitatea si detalierea soluiei n privina cerinelor funcionale 30%
Calitatea si detalierea soluiei n privina cerinelor nefuncionale 30%
Experiena personalului alocat 5%

Ghid de achiziii software pentru instituiile publice | 43


Rezultatul evalurii folosind grila de mai sus ar fi structurat astfel:

Punctaj
Evaluare Punctaj Evaluare
Criteriu Pondere ponderat
Furnizor 1 ponderat Furnizor 2

Preul achiziiei 25% 7 1.75 10 2.5


Calitatea tehnic a arhitecturii propuse 10% 5 0.5 7 0.7
Calitatea si detalierea soluiei n privina 30% 8 2.4 10 3
cerinelor funcionale
Calitatea si detalierea soluiei n privina 30% 6 1.8 9 2.7
cerinelor nefuncionale
Experiena personalului alocat 5% 4 0.2 7 0.35
Punctaj total 6.65 9.25

Punctajul ponderat pentru fiecare criteriu este rezultatul nmulirii dintre punctajul evaluat
(spre exemplu pe o scara de la 1 la 10, dar se poate folosi foarte bine orice scar) i ponderea
stabilit prin gril. Punctajul total este suma punctajului ponderat.

4.2.2 Evaluare cu dou niveluri de criterii

n cazul soluiilor complexe n care vei folosi pentru atribuire un numr mare de criterii,
recomandam separarea acestora pe dou niveluri:

Categorii/criterii principale cu ponderi procentuale asociate care influeneaz punctajul


final;
Subcriterii asociate criteriilor principale cu ponderi asociate n cadrul categoriei care
afecteaz punctajul categoriei.

Suma ponderilor asociate categoriilor principale trebuie s fie 100%. De asemenea, pentru
fiecare criteriul principal, suma ponderilor subcriteriilor trebuie s fie 100%.

Avantajul acestei metode const n faptul c permite definirea unor categorii principale
asigurnd astfel o structur mai bun a grilei de evaluare. Evident, aceast structur poate fi
convertit la o structur cu un nivel sau invers, printr-o simpl conversie aritmetic, neafectnd
n vreun fel rezultatul final.

Ghid de achiziii software pentru instituiile publice | 44


Exemplu de structur a grilei cu dou niveluri.

Pondere
Pondere n cadrul
Criteriu general
categoriei

Cost/Pre 25%

Calitatea propunerii 35%

Gradul de detaliare 10%

Calitatea tehnic a arhitecturii 10%

Calitatea si detalierea soluiei n privina


40%
cerinelor funcionale
Calitatea si detalierea soluiei n privina
40%
cerinelor nefuncionale

Calitatea planului de proiect 10%

Gradul de detaliere 10%

Corelarea cerinelor i livrabilelor 70%

Realismul planului propus 20%

Procesul de dezvoltare 10%

Subcriteriu 100%

Personalul alocat 10%

Subcriteriu 100%

Servicii post implementare 10%

Subcriteriu 100%

Personalul alocat 10%

Subcriteriu 100%

Servicii post implementare 10%

Subcriteriu 100%

Ghid de achiziii software pentru instituiile publice | 45


Mecanismul de calcul este similar cu cel pentru evaluarea cu un singur nivel, cu diferena c are
doi pai:

Calcularea punctajului pentru fiecare criteriu principal folosind ponderile subcriteriilor;


Calculare punctajului total folosind ponderile asociate criteriilor principale.

Aplicnd grila de mai sus, un exemplu de evaluare ar fi urmatorul:

Pondere Pondere Evaluare Punctaj Punctaj


Criteriu general n cadrul ponderat ponderat
categoriei subcriterii criterii
principale

Cost/Pre 25% 6 6 1.50

Calitatea propunerii 35% 7.60 2.66

Gradul de detaliare 10% 5 0.50

Calitatea tehnic a arhitecturii 10% 7 0.70

Calitatea si detalierea soluiei n


40% 10 4.00
privina cerinelor funcionale
Calitatea si detalierea soluiei n
40% 6 2.40
privina cerinelor nefuncionale

Calitatea planului de proiect 10% 7.60 0.76

Gradul de detaliere 10% 10 1.00

Corelarea cerinelor i livrabilelor 70% 8 5.60

Realismul planului propus 20% 5 1.00

Procesul de dezvoltare 10% 6.00 0.6

Subcriteriu 100% 6 6.00

Personalul alocat 10% 10.00 1

Subcriteriu 100% 10 10.00

Servicii post implementare 10% 8.00 0.8

Subcriteriu 100% 8 8.00

PUNCTAJ TOTAL 7.32

Culorile sunt folosite n tabel pentru a arta grupurile de date corelate.

Ghid de achiziii software pentru instituiile publice | 46


4.3 Stabilirea criteriilor de evaluare
Criteriile de atribuire pe care le vei alege pentru evaluare in foarte mult de specificul i
complexitatea proiectului. n acest ghid nu ne propunem s stabilim o metodologie standard
de evaluare, ns propunem un set de criterii pe care le putei adapta cerinelor dumneavoastr
specifice eventual adugnd criteriile proprii specifice proiectului.

n stabilirea criteriilor de atribuire trebuie inut cont de prevederile legale, astfel criteriile
utilizate trebuie s respecte urmtoarele condiii:

S fie alese n legtur direct cu natura i obiectul contractului, fr adugarea unor


criterii artificiale (a se avea n vedere art.188 alin.(1) din Legea nr.98/2016 i Art. 32 alin.(6)
lit. a) din HG nr.395/2016);
S reflecte avantaje pe care autoritatea contractant le obine;
Se pot referi la procesul folosit pe perioada proiectului, ct i ulterior potrivit art 188 alin.
(2) din Legea nr.98/2016;
S fie ct mai obiective, astfel nct autoritatea contractant s nu aib o libertate de
apreciere nelimitat, potrivit art. 189 alin.(1) din Legea nr.98/2016;
S asigure o concuren real ntre ofertani, potrivit art. 189 alin.(2) din Legea nr.98/2016.

Pentru a asigura un grad de obiectivitate ct mai mare este important ca fiecare criteriu utilizat
s fie ct mai bine detaliat iar modul de evaluare/punctare al fiecrui criteriu s fie ct mai clar
explicitat n documentaia de atribuire.

n funcie de specificul i complexitatea obiectului contractului ce urmeaz a fi atribuit,


autoritatea contractant alege dintre factorii de evaluare enumerai mai jos pe aceia pe care
i consider relevani pentru maximizarea beneficiilor obinute n urma derulrii procedurii de
atribuire, raportat la necesitile sale. Pentru fiecare factor de evaluare ce urmeaz a fi utilizat,
autoritatea contractant precizeaz n documentaia de atribuire metoda de acordare a
punctajului i algoritmul de calcul necesar aplicrii criteriului de atribuire ales.

Factorii de evaluare menionai mai jos sunt:

fie de natur cantitativ, fapt ce presupune c punctajul se acord n urma aplicrii unei
formule aritmetice/matematice (de ex. n cazul n care se puncteaz o specificaie tehnic
cum ar fi viteza de rspuns a sistemului, sau viteza procesorului, soluia tehnic cea mai
rapid va primi punctaj maxim, iar celelalte soluii vor fi punctate proporional n puncie
de nivelul parametrului n cauz prezentat);
fie de natur calitativ, situaie n care punctajul se acord n funcie de aprecierea
obiectiv a comisiei de evaluare, n corelaie cu aspectele descrise n enumerarea de mai
sus, departajarea realizndu-se pe clase de punctaj n funcie claritatea/acurateea,
coerena, relevana i altele asemenea criterii aferente propunerilor tehnice prezentate
de ofertani.

4.4 Criteriile de pre i cost


Pentru diferenierea ofertelor n funcie de cheltuielile pe care le implic achiziia de soluii
software complexe, autoritile contractante au dreptul de a utiliza ca i criterii de atribuire, cel
mai bun raport calitate-pre, sau cel mai bun raport calitate-cost.

Criteriile preul cel mai sczut i costul cel mai sczut sunt aplicabile doar pentru achiziia
produselor cu un grad ridicat de standardizare (ex: echipamente hardware uzuale, software
standard tip COTS).

n situaia utilizrii criteriului de atribuire cel mai bun raport calitate-pre sau cel mai bun raport
calitate-cost, n alocarea ponderii pentru criteriul de pre/cost trebuie s inei cont de faptul
c, n cazul contractelor ce presupun dezvoltare/proiectare sisteme informatice complexe,
ponderea alocat factorului nu poate fi mai mare de 40% (art. 32 alin. (6) din HG nr.395/2016).

Ghid de achiziii software pentru instituiile publice | 47


n cazul criteriului preul cel mai sczut (care poate fi utilizat doar pentru achiziia produselor
cu grad ridicat de standardizare), sau n situaia criteriului de atribuire cel mai bun raport
calitate-pre, preul se refer strict la oferta financiar a furnizorului i este uor aplicabil.

n cazul criteriilor de atribuire costul cel mai sczut i cel mai bun raport calitate-cost, costul
presupune ns o evaluare mai complex, dar poate fi un criteriu mult mai relevant pe termen
lung. Costul pe durata de via a achiziiei presupune determinarea costurilor totale pe care
autoritatea le va suporta pe durata de operare/utilizare a soluiei, suplimentar fa de preul de
achiziiei (respectiv determinarea TCO - Total Cost of Ownership).

Pentru evaluarea costului trebuie definit, n primul rnd, durata de via dorit a soluiei.
Pentru o analiz relevant a costului recomandm ca aceast perioad s fie ntre 3 ani i 5 ani,
fiind desigur posibile i niveluri mai mari, n funcie de specificul proiectului.

Avnd n vedere dinamica tehnologic, o perioad medie de via de 5 ani pentru o soluie
software este rezonabil. Dup o astfel de perioad, presupunnd c nu sufer transformri
sau upgrade-uri, soluia intr ntr-o perioad de mbtrnire. Recomandm ca orice soluie
software mai veche de 5 ani s fie evaluat tehnologic pentru a identifica riscurile posibile
(ex: incompatibiliti cu sistemele actuale, tehnologie ieit din uz, lipsa suportului din partea
furnizorului etc.).

Pentru utilizarea criteriului de atribuire costul cel mai sczut trebuie s definii n mod clar n
documentaia de atribuire elementele de cost care trebuie avute n vedere de furnizor n
elaborarea soluiei. Astfel, conform art. 33 alin. (3) i alin. (4) din HG nr. 395/2016, autoritatea
contractant trebuie s includ n documentaia de atribuire cel puin urmtoarele informaii:

Condiiile, mediul i intensitatea de utilizare;


Durata de utilizare anticipat;
Durata de utilizare pentru calcularea costurilor;
Elementele de cost evaluate;
Rata de actualizare pentru calculul financiar;
Modalitatea efectiv de realizare a calculului costului pe durata de via;
Condiiile contractuale de monitorizare a respectrii elementelor de cost precum i
consecinele nerespectrii acestora.

Pentru evaluarea costului total, legea prevede determinarea costurilor anuale pentru fiecare an
de utilizare pentru fiecare element de cost, n conformitate cu prevederile art. 33 alin. (2) (4)
din HG nr. 395/2016.

n cazul utilizrii criteriului costul cel mai sczut, este recomandat includerea n documentaia
de atribuire a unui template (foaie de calcul / spreadsheet) pe care furnizorii s l poat utiliza
pentru estimarea costului total. Aceast foaie de calcul poate, eventual, s fie solicitat ca parte
a propunerii financiare i validat de autoritatea contractant n cadrul procesului de achiziie.

4.4.1 Elemente de cost pentru stabilirea costului total

Lista de mai jos este un punct de pornire pentru identificarea elementelor de cost pe care le
putei include n evaluarea costului total.

Actualizri software
n special n cazul soluiilor bazate pe produse software existente, costul actualizrilor este
foarte relevant.

Licene software necesare


Costul pentru achiziia licenelor software necesare funcionrii soluiei i, eventual, costurile
de actualizare sunt de asemenea importante. n aceast categorie intr sistemele de operare
comerciale, sistemele de baze de date, soluii software de birou (exemplu: Office, Acrobat) i
orice alte licene ar putea fi necesare funcionrii soluiei.

Ghid de achiziii software pentru instituiile publice | 48


Costuri de administrare i operare
Orice soluie software presupune un efort din partea beneficiarului pentru administrare
i operarea acesteia (administrare tehnic, monitorizare, suport tehnic de nivel 1, backup,
administrarea incidentelor). Aceste costuri pot varia n funcie de soluia propus.

Costuri de extensie i modificare


Majoritatea soluiilor sufer modificri ulterior implementrii primei versiuni. n cazul n care
aceste modificri vor fi realizate de acelai furnizor, este relevant costul estimat al acestora.
Avnd n vedere c estimarea viitoarelor modificri este practic imposibil pentru estimarea
acestor costuri, se poate utiliza un efort estimat de ore anual nmulit cu un tarif orar specificat
de furnizor.

Hardware servere
Cerinele hardware ale soluiei propuse ar putea presupune investiii noi n hardware n
momentul implementrii iniiale sau ulterior, pe durata de via a soluiei.

Hardware client
Echipamentele hardware tip client, respectiv sisteme desktop, laptop, tablete sau mobile
ar putea presupune de asemenea costuri n funcie de caracteristicile tehnice ale soluiilor
propuse.

Costuri de gazduire (cloud)


Costurile de gzduire sau de utilizare a serviciilor tip cloud n cazul soluiilor cu componente
cloud.

Costuri de networking i comunicaii


Costuri cu infrastructura de reea i comunicaii. Spre exemplul costul conexiunilor la internet,
costuri de telefonie, costuri de mesagerie (ex: notificri SMS) etc.

Instruire
Costurile de instruire suportate de instituie pe durata de via. Pot fi evaluate inclusiv costuri
de logistic (nchiriere spaii de instruire, transport etc) precum i costuri pentru pregtirea
materialelor de instruire.

Efort propriu
Costul aferent efortului depus de personalul autoritii contractante pentru implementarea
proiectului, n cazul n care acesta poate varia n funcie de soluia oferit de furnizor sau de
procesul de implementare propus.

Riscuri
Impactul financiar al materializrii unor riscuri ar putea fi cuantificat. n acest sens trebuie
identificate riscurile posibile pe durata de via a soluiei. Spre exemplu: riscuri legate de personal
(relevante n cazul utilizrii unor tehnologiilor exotice sau nvechite), riscuri tehnologice (ex:
finalizarea ciclului de via), riscuri legale (ex: falimentul furnizorului), riscuri de securitate (ex:
compromiterea datelor personale) etc. Disciplina de administrare a riscurilor (risk management)
este una foarte complex pe care nu avem pretenia c o putem acoperi n acest ghid.

4.5 Punctarea ofertelor n funcie de cost sau pre


Punctarea ofertelor n funcie de cost sau pre este evident relevant doar n situaia utilizrii
criteriilor cel mai bun raport calitate-pre i cel mai bun raport calitate-cost, pentru celelalte
criterii fiind suficient ordonarea ofertelor.

Pentru punctarea ofertanilor n funcie de pre sau cost se poate folosi o metod simpl de
transformare a preului n punctaj. Punctajul pentru factorul de evaluare "preul ofertei" sau
costul ofertei se acord astfel:

a. pentru cel mai sczut dintre preurile/costurile ofertelor se acord punctajul maxim
alocat factorului de evaluare respectiv (ex: 10 puncte)

Ghid de achiziii software pentru instituiile publice | 49


b. pentru celelalte oferte punctajul se acord astfel:

Punctaj = (pre minim/pre oferta) x punctaj maxim alocat.

Exemplu de calcul:

Presupune cazul n care punctarea ofertelor se va face ntr-un interval de punctaj de la 1 la 10


iar ofertele sunt n intervalul de la 1.000 lei (cea mai mica ofert) la 20.000 lei (cea mai mare
ofert).

Oferta minim de pre (cu valoarea de 1.000 lei) va avea punctajul maxim, respectiv 10 puncte.
Celelalte oferte vor fi punctate astfel:

Oferta de 2.000 lei va avea punctajul = 1.000/2.000 x 10 = 5 puncte


Oferta de 5.000 lei va avea punctajul = 1.000/5.000 x 10 = 2 puncte
Oferta de 10.000 lei va avea punctajul = 1.000/10.000 x 10 = 1 punct
Oferta de 20.000 lei va avea punctajul = 1.000/20.000 x 10 = 0,5 puncte
S.a.m.d.

4.6 Criterii tehnice


Criteriile tehnice pot fi avute n vedere doar n cazul utilizrii criteriilor de atribuire cel mai bun
raport calitate-pre sau cel mai bun raport calitate-cost.

n cele ce urmeaz propunem o serie de criterii pe care le putei adapta situaiei dumneavoastr
i care vor fi utilizate pe lng componenta/componentele de pre/cost. Acestea sunt grupate
n urmtoarele categorii:

Calitatea propunerii tehnice;


Personalul alocat;
Calitatea i relevana planului de proiect;
Procesul de dezvoltare;
Servicii post implementare.

4.6.1 Calitatea propunerii tehnice

Gradul de detaliere al propunerii


Propunerile tehnice ale furnizorilor trebuie s adreseze n detaliu modul de ndeplinire, n
procesul de implementare a viitorului contract, toate cerinele formulate n documentaia
de atribuire. O propunere tehnic detaliat arat interesul potenialului furnizor precum i
nelegerea cerinelor formulate.

Calitatea tehnic a soluiei propuse


Utiliznd acest criteriu, putei evalua relevana arhitectural a soluiei propuse, modularitatea
arhitecturii, tehnologiile folosite, adaptarea la infrastructura tehnic a beneficiarului,
corespondena cerinelor funcionale cu elementele soluiei (sistem, subsisteme, module),
gradul n care tehnologia propus rspunde cerinelor nefuncionale etc.

nelegerea i acoperirea cerinelor funcionale


Propunerile furnizorilor trebuie s rspund n detaliu tuturor cerinelor funcionale formulate.
Pe lng acoperirea integral a cerinelor, rspunsul furnizorilor trebuie s arate i nelegerea
cerinelor, a nivelului de complexitate i s ofere soluii valide i eficiente acestor cerine.

nelegerea i acoperirea cerinelor nefuncionale


Furnizorii trebuie de asemenea s rspund integral i detaliat cerinelor nefuncionale
formulate. Soluiile propuse pentru a adresa unele cerinele nefuncionale, pot avea uneori
un impact profund n arhitectura soluiei sau pot influena alte cerine (funcionale sau
nefuncionale). n astfel de cazuri trebuie validat c impactul a fost corect evaluat de furnizor.

Ghid de achiziii software pentru instituiile publice | 50


Eficientizri tehnice i de proces
Criteriul urmrete ncurajarea furnizorilor s propun soluii eficiente din punct de vedere
tehnic cum ar fi reducerea necesarului de hardware i software, arhitecturi extensibile, simple
i modulare. De asemenea furnizorii ar putea propune i eficientizri de proces cu beneficii
pentru autoritatea contractant.

Caracteristici estetice i usurina n utilizare (usability)


Aspectul grafic al soluiilor propuse poate fi un criteriu de evaluare, n special n cazul soluiilor
cu componente adresate publicului (ex: soluii online). uurina n utilizare este relevant
pentru orice interfa utilizator i astfel poate fi folosit n cadrul criteriilor de atribuire.

Angajamente i cerine suplimentare


Criteriul urmrete ncurajarea i punctarea suplimentar a furnizorilor care i asum
angajamente suplimentare fa de cerinele minime prevzute n caietul de sarcini. Conform
Art 32 alin (9) lit b): cuantumul valoric al avantajelor de natur financiar pe care ofertanii
le pot oferi prin asumarea unor angajamente suplimentare n raport cu cerinele minime
prevzute n caietul de sarcini sau documentul descriptiv, aceste angajamente suplimentare
trebuie evaluate valoric.

4.6.2 Personalul alocat

Este important de remarcat c gradul de pregtire a personalului alocat pentru


implementarea contractului (denumit i personal cheie) este un criteriu care poate fi folosit
doar n cadrul criteriilor de atribuire i nu poate fi folosit ca i criteriu de calificare i selecie
(Art. 32 alin (4) din HG nr. 395/2016).

Experiena relevant
Criteriu care vizeaz experiena personalului cheie n realizarea unor activiti de tipul i
natura celor ce urmeaz a fi ndeplinite n viitorul contract n cadrul unor proiecte similare.

Pregatire tehnic
Criteriu care vizeaz pregtirea personalului alocat n utilizarea tehnologiilor relevante n
proiect.

Structura echipei de proiect


Evaluarea structurii echipei de proiect propuse de furnizor, respectiv dimensiunea adecvat
a echipei, rolurile definite n cadrul echipei, definirea unor responsabiliti clare pentru fiecare
rol, acoperirea specializrilor necesare n proiect, corelarea cu planul de proiect i efortul/
costul propus.

Certificri tehnice
Certificrile tehnice deinute de o persoan pot fi un indicator al competenelor acesteia,
ns lipsa unor certificri nu presupune implicit lipsa competenelor. Astfel, utilizarea
certificrilor tehnice n cadrul criteriilor de atribuire trebuie fcut cu just msur i pruden.
Introducerea unor criterii de punctaj artificiale poate influena considerabil concurena ntre
furnizori, n special n cazul punctajului suplimentar acordat pentru certificri tehnice rare,
cumul de certificri sau certificri irelevante n proiect.

n cazul n care vei folosi ca i criteriu de atribuire certificrile tehnice, recomandm ca


punctajul acordat acestui criteriu s nu fie determinant n economia general a punctajului.

4.6.3 Calitatea planului de proiect

Gradul de detaliere al planului


Un plan bine realizat i realist este un prim pas necesar pentru orice proiect reuit. Astfel,
detalierea planului de realizare propus de furnizor este un criteriu de evaluare relevant.

Ghid de achiziii software pentru instituiile publice | 51


Corelarea cerinelor i a livrabilelor solicitate cu planul propus
Criteriul urmrete gradul de corelare dintre planul propus i cerinele i livrabilele solicitate n
proiect. Planul de proiect trebuie s clarifice termenele la care vor fi livrate diferitele livrabile
solicitate precum i fazele/activitile n care vor fi implementate cerinele funcionale.

Acoperirea tuturor activitilor relevante


Criteriul urmrete gradul n care planul de proiect acoper toate activitile necesare
pentru finalizarea proiectului precum i ponderea acestora n cadrul proiectului. Activitile
includ: analiz, testare, project management, dezvoltare, instruire, acceptan, elaborare
documentaii etc.

Corelarea planului cu preul proiectului


Msura n care planul de proiect este corelat cu bugetul proiectului. n msura n care planul de
proiect include i informaii despre efortul estimat (ceea ce este recomandat) acestea pot fi
folosite pentru a determina acurateea planului i a estimrii.

Realismul planului propus


Msura n care planul propus este realist. Criteriul ar putea urmri subestimarea sau
supraestimarea considerabil a anumitor activiti din proiect.

Durata proiectului sau termenul de livrare


Pentru criteriul durat se poate folosi un algoritm identic cu cel propus pentru punctarea
ofertelor n funcie de cost sau pre, ns n loc de bugetul proiectului se va folosi numrul de
zile de la startul proiectului pn la acceptan sau punerea n producie.

4.6.4 Procesul de dezvoltare

Procesul utilizat de furnizorul soluiei i adaptarea procesului la complexitatea proiectului i


cerinele beneficiarului sunt aspecte vitale pentru succesul proiectului.

Claritatea procesului
Criteriul vizeaz claritatea cu care furnizorul definete procesul de dezvoltare/implementare
urmrit, definirea fazelor proiectului, modul n care diversele livrabile sunt realizate i
transformate n cadrul procesului, responsabilitile rolurilor n fiecare faz, abloanele de
documentaie utilizate.

Relevana procesului
Criteriul urmrete relevana procesului propus n contextul proiectului i adaptarea
procesului propus la complexitatea proiectului i cerinele de proces ale autoritii
contractate. n cazul soluiilor de complexitate mic-medie, un proces mai curnd informal
poate fi mai eficient, n timp ce soluii de complexitate mare necesit un proces mai formal.

Instrumente de proces i colaborare


Criteriul evalueaz instrumentele folosite de furnizor pe parcursul proiectului. Acestea pot
include: soluii de colaborare online, instrumente de planificare (project management), aplicaii
de prototipare UI, soluii de organizare a cerinelor, aplicaii de diagramare, soluii de eviden
a defectelor i incidentelor, aplicaii de testare, aplicaii de testare a performanei, aplicaii
pentru elaborarea manualelor de utilizare etc.

Project management
Criteriul vizeaz modul n care furnizorul va asigura pe ntreaga perioad a proiectului
disciplina de project management, precum i identificarea clar a responsabilitilor i
activitilor pe care rolul sau echipa de project management urmeaz s le realizeze. Printre
aceste responsabiliti se numr: monitorizarea progresului, identificarea i comunicarea
eventualelor ntrzieri, adresarea eventualelor blocaje i neclariti precum i administrarea
riscurilor.

Raportarea progresului

Ghid de achiziii software pentru instituiile publice | 52


Monitorizarea i raportare progresului este o atribuie a rolului sau echipei de project
management ns, avnd n vedere importana acestei activiti, o putei lua n considerare
ca un criteriu de evaluare distinct. Acest criteriu urmrete frecvena rapoartelor de
stadiu, structura i coninutul acestora, demo-uri intermediare ale soluiei i comunicarea
ntrzierilor.

Administrarea situaiilor blocante (Issue Management)


O alt atribuie foarte important a rolului de project management este administrarea i
adresarea situaiilor blocante inerente n orice proiect. Un criteriu distinct n acest sens
trebuie s vizeze modul n care furnizorul va identifica, administra, adresa i eventual escalada
blocajele aprute n proiect.

Administrarea cerinelor de modificare (Change Management)


n mod natural pe parcursul oricrui proiect apar modificri ale cerinelor iniiale (eliminare,
adugare, modificare, simplificarea sau creterea n complexitate). Un potenial criteriu
de evaluare, relevant n special pentru proiecte de complexitate mare, este procesul prin
care furnizorul va identifica, administra, negocia i ncorpora sau exclude din scop astfel de
modificri.

Testare
Criteriul urmrete evaluarea procesului de testare, respectiv structura echipei de testare
i adecvarea acesteia la nevoile proiectului, tipurile de teste realizate (unitare, funcionale,
de regresie, automate, de utilizabilitate, de compatibilitate, de performan, de securitate,
distructive, de acceptan etc), planificarea testelor, structura i evidena scenariilor de
test, evidena defectelor, prioritizarea defectelor sau instrumentele folosite pentru evidena
defectelor, instrumente folosite pentru testare.

Dezvoltare
Criteriul urmrete evaluarea procesului de dezvoltare utilizat de furnizor, respectiv
utilizarea obligatorie de soluii de source control, politica de checkin-uri, reguli pentru scriere
a comentariilor, politica privind review-urile de cod, utilizarea de standarde de scriere a
codului, utilizarea de instrumente automate de analiz a codului, utilizarea de instrumente de
productivitate i eliminare a erorilor n scrierea codului (refactoring, code smell etc.), utilizarea
standardelor deschise, unde este posibil, sau utilizarea de instrumente pentru monitorizarea
performanei n timpul dezvoltrii.

4.6.5 Servicii post implementare

Instruire
Criteriul poate evalua tipurile de instruire oferite de furnizor (utilizatori finali, administrare i
operare, dezvoltare etc), resurse disponibile pentru instruire (manuale, cursuri, tutoriale text,
tutoriale video) precum i suportul logistic oferit de furnizor pentru instruire.

Garanie
Criteriul va evalua perioada de garanie oferit de furnizor, eventual suplimentar fa de
garania solicitat n documentaia de atribuire, defectele acoperite de garanie, limitele
garaniei sau responsabilitatea furnizorului n cazul defectelor.

Servicii de mentenan i suport


Criteriul urmrete evaluarea serviciilor de mentenan i suport tehnic oferite de furnizor,
programul de lucru i disponibilitatea serviciilor, disponibilitatea unei persoane sau echipe
dedicate pentru suport, instrumentele puse la dispoziie pentru evidena incidentelor sau
defectelor, nivelul de suport (nivel 1 - probleme de baz, nivel 2 - suport tehnic mai avansat,
nivel 3 - suport tehnic al echipei de dezvoltare, nivel 4 - escaladare la furnizorii de tehnologie),
disponibilitatea furnizorului pentru prezena on-site pentru anumite tipuri de incidente,
tehnologii de suport la distan, disponibilitatea geografic a furnizorului n cazul n care este
relevant, monitorizare regulat preventiv i frecvena monitorizrii, precum i evaluarea
parametrilor de performan ai serviciilor de mentenan i suport la care se angajeaz
furnizorul prin contract (SLA - Service Level Agreement).

Ghid de achiziii software pentru instituiile publice | 53


Actualizri
Acest criteriu este n special relevant n cazul soluiilor bazate pe produse software existente
eventual personalizate. n astfel de situaii actualizarea n timp a produsului de baz este
foarte important. Criteriul va evalua tipul de actualizri oferite gratuit de furnizor (versiuni
minore, majore, fix-uri) i perioada pe care acestea sunt oferite.

Ghid de achiziii software pentru instituiile publice | 54


5. CONCLUZII
Aceasta prim versiune a ghidului acoper, prin recomandri practice, dou componente ale
procesului de achiziie a soluiilor software:

Realizarea documentaiei tehnice de atribuire;


Procesul de evaluare folosind criteriile de atribuire cel mai bun raport calitate-pre i cel
mai bun raport calitate-cost.

Urmrind structura i recomandrile din capitolul 3. Caietul de sarcini vei putea elabora
documentaia tehnic structurnd cerinele proiectului n cerine funcionale i cerine
nefuncionale.

n capitolul 4. Criterii de atribuire este explicat cadrul legal aplicabil, sunt propuse dou
metodologii posibile pentru evaluare i este de asemenea propus un set posibil de criterii de
atribuire cu explicaiile aferente.

Avnd n vedere problematica foarte complex abordat, ghidul nu i-a propus s impun un
standard de realizare a documentaiei de atribuire sau un standard de evaluare, ns este un
foarte bun punct de plecare n aceste demersuri.

Din acest motiv trebuie s insistm pe necesitatea adaptrii recomandrilor din ghid la
cerinele instituiei dumneavoastr, fr a prelua ad-litteram anumite recomandri sau
exemple din ghid. Este foarte posibil ca anumite recomandri s nu fie necesare sau aplicabile
n cazul dumneavoastr, la fel cum este posibil ca anumite cerine pe care le avei s nu fie
acoperite de ghid.

n aceste concluzii vrem de asemenea s insistm asupra principiului necesitii n elaborarea


documentaiei de atribuire, respectiv n formularea de cerine ct mai clare care sunt necesare
proiectului, evitnd cerine vagi, artificiale sau cerine opionale. Recomandm n special o
atenie sporit n formularea cerinelor nefuncionale a cror supradimensionare fa de
necesitile reale poate conduce la costuri exponenial mai mari.

n sperana c acest ghid va fi util n activitatea dumneavoastr, v urm succes n realizarea


documentaiei i n derularea proiectelor dumneavoastr.

Sugestii de mbuntire

Acest ghid se afl la prima versiune i exist intenia clar de a fi dezvoltat n continuare. Ca n
orice demers iniial, aceast versiune poate s conin omisiuni, greeli sau inadvertene care
vor fi corectate n versiunile ulterioare.

n acest sens v ncurajm s transmitei sugestiile dumneavoastr folosind metodele de


comunicare indicate mai jos. Pe lng aceste sugestii suntem foarte interesai s nelegem
provocrile cu care v confruntai n elaborarea documentaiilor de atribuire precum i n
derularea achiziiilor ce privesc soluii software. nelegerea acestor provocri ne va ajuta n
dezvoltarea ulterioar a acestui ghid dar i n elaborarea de instrumente conexe ghidului care
s v ajute n procesul de achiziie.

Adresa de contact pentru sugestii i observaii: ghidachizitii@anis.ro.

Ghid de achiziii software pentru instituiile publice | 55


Ghid de achiziii software pentru instituiile publice | 56
Versiunea actualizat a ghidului precum i alte instrumente i materiale relevante pot fi descrcate de la adresa:
www.anis.ro/programe/ghidachizitii

Ghid de achiziii software pentru instituiile publice | 57


Ghid de achiziii software pentru instituiile publice | 58