ASIGURAREA CALITII NTR-O FIRM DE SOFT

Dorin Bocu
Transilvania University, Department of Computer Science
e-mail d.bocu@unitbv.ro

Abstract
The cost of fixing faults in a system increases as the system progresses through
the systems development life cycle. If an error occurs in the analysis of a system, it
is cheaper to fix it during the analysis phase than it is later, when that error may
have propagated through numerous aspects of the design and implementation.
This paper presents some considerations about the impact of a good management
regarding software quality.

1. Introducere
Este nevoie de soft de calitate, produs n timp util i la preuri competitive pentru a face
fa rigorilor supravieuirii pe piaa concurenial. Expresia n timp util nseamn respectarea
termenelor convenite pentru livrarea produselor. Expresia la preuri competitive nseamn
ncadrarea proiectului n restriciile bugetare convenite.
Este evident faptul c cele dou cerine pot fi ndeplinite prin crearea tuturor condiiilor
pentru creterea continu a productivitii muncii. Preocuparea sistematic pentru creterea
productivitii muncii poate, ns, intra n conflict cu cerina de a menine calitatea la
standarde nalte, dac nu se studiaz cu atenie impactul oricrei inovaii n procesul de
dezvoltare, asupra calitii.
Metoda clasic pentru a face fa posibilelor conflicte dintre cele dou cerine se bazeaz
pe delegarea competenelor n materie de calitate, ctre persoane sau colective care se
ocup exclusiv de toate problemele presupuse de monitorizarea abaterilor de la calitate.
Altfel spus:

O component a
managementului
firmei

Monitorizeaz abaterile
de la calitate ale ...

Operativului

Figura 1. Metoda clasic de asigurare a calitii

Mi se pare o abordare total depit n condiiile actuale. Calitatea trebuie s fie, n esen,
creaia operativului. Majoritatea mijloacelor de promovare efectiv a calitii este
concentrat n minile celor care lucreaz, nemijlocit, la dezvoltarea softului (analiti,
proiectani, programatori, etc). De aceea, alternativa corect la Figura 1 mi se pare a fi cea
prezentat n Figura 2.

Managementul
firmei

Asigur un transfer sistematic

de resurse i competene,
pentru asigurarea calitii,
ctre nivelul...

Operativ

Figura 2. Metoda propus pentru managementul calitii ntr-o firm modern

Cteva consideraii pe marginea strategiei schiate n Figura 2, n continuare.

Activitile n ingineria softului (IS) se deosebesc mult de activitile din alte domenii
de activitate. n locul muchilor se folosete mult gndirea. Rutina exist, dar nu n
prim plan, cum se ntmpl n alte industrii. n prim plan se afl creativitatea
specialistului n IS, care, n fiecare proiect, este obligat s fac fa la cerine noi,
indiferent de faza n care se afl dezvoltarea unui sistem soft. Pentru a se
manifesta, creativitatea are nevoie de libertate de aciune. Pentru a nu produce sub
nivelul standardelor, creativitatea trebuie s se raporteze contient la standarde.
Factorii care determin calitatea n IS sunt din ce n ce mai sofisticat distribuii i
articulai n cmpul de aciune al unui specialist IS. Multe probleme din IS pot fi
rezolvate optim prin alegerea tehnologiei (tehnologiilor) adecvate exigenelor
proiectului. Am vrut s subliniez, nc odat, faptul c asigurarea calitii este o
problem de strategie, dac discutm despre principii de promovare a
standardelor de calitate i este o problem de competena operativului, dac
discutm despre mijloacele de operaionalizare a acestor principii. Ideea care se
degaj, bnuiesc c este clar.
Dac se dorete, neaprat, implicarea managementului n rezolvarea problemelor de
calitate, abordarea ideal este urmtoarea:
Stabilirea principiilor fundamentale, care trebuie respectate n procesul de
dezvoltare a softului (la nivelul conducerii firmei);
Convenirea mijloacelor de operaionalizare a principiilor; aceste mijloace pot fi
independente de proiect sau, dac este cazul, dependente de proiect.
Din perspectiv obiect orientat, situaia se reprezint ca n Figura 3.
La nivelul conducerii firmei
Principii fundamentale n asigurarea
calitii

La nivelul coordonatorilor de proiecte

Mijloace de operaionalizare a principiilor
independente de proiect

La nivelul colectivului de
proiectare 1
Mijloace de operaionalizare
specifice Proiect_1

La nivelul colectivului de
proiectare k
Mijloace de operaionalizare
specifice Proiect_k

Figura 3. Propunere de abordare a problemei calitii ntr-o firm de soft

Fcnd o analogie cu o abordare clasic din ingineria softului, competenele n materie de

asigurare a calitii softului n cadrul unei firme pot fi structurate pe trei nivele de
abstractizare:
-Nivelul conceptual (Conducerea firmei);
-Nicelul specificare (Coordonatorii de proiecte);
-Nivelul implementare (Membrii colectivelor de dezvoltare, repartizai pe proiecte)

Managementul calitii la nivelul conducerii firmei

-Conceptualizarea factorilor generici care determin calitatea unui sistem soft;
-Conceptualizarea factorilor de calitate identificai de firm;
-Modaliti de aciune.

Managementul calitii la nivelul coordonatorilor de proiecte

-Specificarea factorilor generici care determin calitatea unui sistem soft;
-Specificarea factorilor de calitate identificai de firm;
-Modaliti de aciune.

Managementul calitii la nivelul colectivelor de dezvoltare

-Implementarea factorilor generici care determin calitatea unui sistem soft;
-Implementarea factorilor de calitate identificai de firm;
-Modaliti de aciune.;

2 O schi de program pentru asigurarea calitii n cadrul unei firme de

soft
2.1 Nivelul conceptual (Conducerea firmei)
Ori de cte ori este nevoie, la acest nivel trebuie reflectat asupra urmtoarelor trei tipuri de
probleme:
-factori socotii, n genere, ca fiind importani pentru calitatea softului, pe care firma
vrea s i monitorizeze. Descrierea lor la nivel conceptual.
-factori identificai de conducerea firmei ca fiind importani pentru calitatea unui
proiect anume. Descrierea lor la nivel conceptual.
-modaliti de aciune la nivel conceptual.
Observaie
Problema calitii softului este considerat, n literatura de specialitate, o problem
dificil, deoarece enunul ei se modific odat cu tehnologiile folosite pentru dezvoltarea
softului.
Marea diversitate a abordrilor din punct de vedere tehnologic m-a determinat s propun
cele dou tipuri de factori ai calitii, n vederea monitorizrii.

2.1.1 Factorii generici ai calitii

Literatura de specialitate distinge trei categorii de factori generici ai calitii.
-factori care se refer la comportarea unui sistem soft dup ce a fost dat n
exploatare:
-Corectitudinea;
-Fiabilitatea;
3

-Performana;
-Eficiena;
-Securitatea;
-Ergonomia interfeei.
-factori care se refer la comportarea unui sistem soft n cazul n care apar
modificri:
-modularitatea;
-stilul de codificare i documentare;
-factori care se refer la comportarea unui sistem soft n cazul n care acesta
migreaz spre alte platforme hard sau de operare:
-portabilitatea
-reutilizabilitatea
nelesul dat la nivel conceptual acestor factori l prezentm, pe scurt, n continuare.
Corectitudinea
Se refer la abilitatea unui sistem soft de a executa toate sarcinile convenite la specificarea
cerinelor.
Fiabilitatea
Se refer la capacitatea sistemului soft de a-i conserva calitatea n timpul exploatrii. n
unele cri, fiabilitatea sistemelor soft se mai numete i robustee n exploatare.
Performana
Se refer la modul n care sistemul soft, n format executabil, satisface cerinele de
performan convenite (timpii de rspuns la interogri, n medie sau minimali i maximali,
etc.).
Eficiena
Se refer la abilitatea sistemului soft de a utiliza eficient posibilitile mainii fizice pe
care acesta este executat.
Observaie
n condiiile n care resursele hard critice ale sistemelor de calcul i mbuntesc
permanent indicii de performan, s-ar prea c performana i eficiena nu mai sunt
nite prioriti, potrivit opiniei unor specialiti.
Opinia mea este c trebuie s monitorizm, n continuare, aceti factori deoarece,
oricnd pot ajuta un proiect s ctige btlia cu alte proiecte similare.
Securitatea
Se refer la abilitatea sistemului soft de a minimiza pierderile de date n timpul avariilor la
alimentare sau n cazul unor ncercri de utilizare neautorizat.
Ergonomia interfeei
Se refer, practic, la confortul asigurat clientului n timpul utilizrii diferitelor funcii ale
unui sistem soft.
Modularitatea

Modularitatea trebuie planificat i urmrit judicios deoarece de realizarea ei n condiii

optime depinde esenial disponibilitatea unei soluii de a se adapta la condiii noi de
execuie i de a face fa la cerine noi (reutilizabilitatea i exetnsibilitatea). Modularizarea
corect este, practic, visul oricrui specialist n ingineria softului i mai ales al oricrui
programator iscusit. Practic, a modulariza corect nseamn:
arhitectur simpl a soluiei + descentralizare optim a capabilitilor acesteia.
Stilul de codificare i documentare
Poate susine sau compromite evoluia unui sistem soft, att n faza de proiect ct i n
perioada de utilizare efetctiv. Stabilirea unui set minimal de reguli i elemente suport
pentru activitile de codificare i documentare trebuie s fie o prioritate pe agenda celor
care urmresc calitatea softlui n cadrul firmei.
Portabilitatea
Acest factor msoar capacitatea sistemului soft de a face fa, cu eforturi minimale,
la exerciii de migrare pe alte platforme hard i de operare. n condiiile n care varietatea
arhitecturilor hard existente pe pia este n cretere iar lumea mediilor de operare tinde s
se dezvolte, nc n dispre fa de standardizarea tehnologiilor de baz, este firesc s se
aib, permanent n atenie i acest factor al calitii.
Reutilizabilitatea
Este un vis vechi al oricrei firme de dezvoltare a softului. Ideea este urmtoarea: dac un
proiect, prin generalitatea lui, are disponibilitate spre reutilizare, n ansamblu sau pe
componentele, atunci reutilizabilitatea trebuie planificat sistematic.

2.1.2 Factori de calitate identificai de firm

Problema identificrii acestor factori trebuie s figureze pe agenda managementului
firmei, dac aceasta s-a hotrt s investeasc n calitate. Investiiile fcute n calitate nu se
recupereaz imediat, dar sunt foarte profitabile pe termen lung i mediu. De aceea, pentru
supravieuire, managementul unei firme de soft trebuie s organizeze dezbateri cu personalul
de specialitate pentru a identifica i defini acei factori ai calitii considerai specifici firmei
n cauz.

2.1.3 Modaliti de aciune la nivel conceptual.

Pentru exemplificare, sugerez urmtoarele direcii de aciune.
1.

Pentru fiecare proiect se va alege procesul de dezvoltare cel mai adecvat. Mrimea i
caracteristicile proiectelor aflate n lucru m-au condus la ideea c tipul de proces ideal, n cadrul
firmei XXXXXX, este modelul RAD (Rapid Application Development), ale crui caracteristici
reies din Figura 4.
Definire obiective
prototip

Analiza iniial

Specificare prototip
Evaluare prototip i
stabilire schimbri

Construire protoip

Prototip complet

Figura 4 Dezvoltarea rapid a softului utiliznd prototipizarea

Aadar, fazele principale necesare pentru a pregti un prototip sunt:

Efectuarea unei analize iniiale;
Definirea obiectivelor prototipului ;
Specificarea prototipului;
Construirea prototipului;
Evaluarea prototipului i stabilirea schimbrilor de efectuat.
Efectuarea unei analize iniiale
ntreaga activitate de dezvoltare a softului folosete resurse valoroase. nceperea unui
exerciiu de prototipizare fr o analiz iniial este posibil s conduc la o activitate
nestructurat i greit focalizat care va produce un soft proiectat nesatisfctor.
Definirea obiectivelor prototipului
Prototipizarea este de dorit s aib obiective clar stabilite. Un exerciiu de prototipizare
poate implica multe iteraii, fiecare iteraie avnd drept rezultat o anumit mbuntire a
prototipului. Pentru participanii la un exerciiu de prototipizare, la un moment dat poate fi
dificil de stabilit dac prototipizarea trebuie sau nu s continue. Pentru evitarea unei astfel de
posibiliti definirea clar a obiectivelor de ndeplinit poate fi de mare folos.
Specificarea prototipului
Dei prototipul nu este realizat n perspectiva unor operaii de extindere este, evident,
important s aib un comportament scontat. De aceea, este absolut firesc s lum n calcul
posibilitatea unor modificri care s apropie prototipul ct mai mult de comportamentul
scontat.
Aceste modificri sunt mult mai uor de fcut dac softul este realizat potrivit unor principii
de proiectare profunde.
Construirea prototipului
Deoarece este important ca prototipul s fie realizat rapid este firesc ca n aceast faz s
se apeleze la un mediu de dezvoltare rapid a plicaiilor (Delphi, Visual Basic, Visual C, CBuilder, etc.) sau la un tools care asist proiectarea, precum ObectiF sau Rationale Rose.
Alegerea potrivit pentru firma XXXXXX, la acest stadiu al investigaiilor diferitelor toolsuri pare a fi ObjectiF, promotor al UML, ca limbaj de modelare i avnd un proces de
dezvoltare specific (ActiF).
Evaluarea prototipului i stabilirea schimbrilor de efectuat
Motivul principal pentru care realizm un prototip este testarea i explorarea anumitor
aspecte ale sistemului soft de realizat. Prototipul trebuie evaluat n conformitate cu obiectivele
identificate la nceperea exerciiului de prototipizare. Dac obiectivele nu au fost ndeplinite,
evaluarea are drept consecin o serie de modificri care urmresc apropierea prototipului de
obiectivele asumate. Dup cum se vede i din Figura 4 ultimele trei faze sunt parcurse ciclic,
pn cnd toate obiectivele asumate de exerciiul de prototipizare sunt ndeplinite.
n cele ce urmeaz putem prezenta avantajele acestui model dar i o serie de aspecte de
care ar trebui s inem cont nainte de a ne aventura n prototipizare.
Avantaje

Ilustrarea timpurie a funcionalitii sistemului ajut la identificarea tuturor

dezacordurilor dintre specialistul IS i client;

Cerinele client omise au anse s fie identificate;

Dificultile legate de proiectarea interfeei pot fi contientizate i rezolvate;

Realizabilitatea i utilitatea sistemului soft pot fi testate chiar dac, prin natura lui,
prototipul este incomplet.

Probleme:
Clientul poate percepe prototipul ca parte a sistemului final, dar nu poate nelege
amploarea efortului cerut, uneori, de realizarea formei finale a sistemului, motiv
pentru care are senzaia c acesta (sistemul final) trebuie livrat mai curnd dect este
posibil n realitate;

Prototipul poate distrage atenia de la aspectele funcionale (uneori critice pentru

sistem) ctre problemele de interfa (fetiizate oarecum de nevoia de a da permanent
satisfacie clientului/utilizatorului);

Prototipizarea se bazeaz pe o implicare semnificativ a utilizatorului;

Managementul care se bazeaz pe modelul RAD are de luat decizii dificile de-a lungul
ntregului ciclu de via.

2.

Alegerea limbajului de modelare i a tools-urilor care promoveaz conceptele acestuia. n aceast

direcie sugerez o anumit constan a opiunilor, deoarece nvarea unui limbaj de modelare
este o problem de timp i de bani. Sugerez UML n combinaie cu ObjectiF.

3.

Evaluarea lunar a calitii soluiei unui proiect, indiferent de nivelul de abstractizare la care s-a
ajuns.

2.2 Modaliti de aciune la nivelul specificare (Cooordonatorii de

proiecte)
Specificarea corectitudinii
Atenia coordonatorilor de proiecte se va focaliza pe:
-Completitudinea listei cerinelor;
-Claritatea formulrii cerinelor;
-Identificarea relaiilor dintre cerine;
-Identificarea conflictelor dintre cerine si explorarea soluiilor de compromis.
Specificarea performanei
Atenia coordonatorilor de proiecte se va focaliza pe:
-completitudinea listei indicatorilor de performan;
-Claritatea formulrii indicatorilor de performan;
-Identificarea relaiilor dintre indicatori
-Identificarea conflictelor dintre indicatori i explorarea soluiilor de compromis.
Specificarea eficienei
Atenia coordonatorilor de proiecte se va focaliza pe:
-Selectarea indicatorilor de performan ai soluiei, sensibili la indicatorii de
7

performan ai resurselor hard critice;

-Identificarea protocoalelor de mapare a indicatorilor selectati peste indicatorii de
performanta ai resurselor hard critice
Specificarea fiabilitii
Atenia efilor de proiecte se va focaliza pe:
-Identificarea componentelor (interne i externe sistemului soft) care pot afecta
sigurana n funcionare a acestuia;
-Stabilirea strategiei de asigurare a fiabilitii pentru fiecare component n parte:
-elemente-suport conceptuale;
-elemente-suport la nivelul limbajului de programare;
-elemente-supot la nivelul mediului de dezvoltare.

2.3 Modaliti de aciune la nivelul implementare

La acest nivel se impun msuri care s asigure un feed-back permanent pe traseul:
calitatea la nivel conceptualcalitatea specificatcalitatea la nivel de
operativcalitatea la nivel conceptual.
Msurile preconizate sunt de doua tipuri:
-punctuale;
-anticipative.
Msurile punctuale
Constituie un ansamblu de activiti, convenite de management, pentru a verifica modul n
care se realizeaz transferul de competene n domeniul calitii de la nivel de management
spre nivelul operativ. Pentru ca aceste activiti s se poat desfura corect este necesar s se
accepte urmtoarele condiii minimale:
-un proces de dezvoltare, care va permite implementarea feed-back-ului n domeniul
calitii;
-un limbaj de modelare i reprezentare adecvat, ceea ce va facilita procesul de
urmrire a calitii.
Msurile anticipative
Constituie ansamblul activitilor de informare i formare sistematic a tuturor
partenerilor unui proiect, n acord cu reponsabilitile curente i de perspectiv.

3 Concluzii
n loc de alte concluzii, prezentm, n continuare, cteva msuri concrete pentru
promovarea calitii la nivel operativ. Aceste msuri sunt:
-Elaborarea unui stil de codificare;
-Elaborarea riguroas a documentaiei sistemelor soft (tipuri de documentaie
i template-uri asociate):
-Planificarea riguroas a procedurilor de testare
Activitatea de testare este de importan crucial pentru asigurarea
calitii sistemelor soft dezvoltate de o firm.
8

-ncadrarea efortului de dezvoltare ntr-un model convenabil

-Utilizarea pentru elaborarea i reprezentarea soluiei, a unui limbaj de
modelare adecvat
-Accentuarea preocuprilor pentru managementul proiectelor i pe
coordonate care influeneaz calitatea precum: reutilizarea efortului de dezvoltare,
nivelul de informare, planificarea calendaristic a dezvoltrii, identificarea i gestiunea
riscurilor, climatul de lucru.

Bibliografie
[1] Bocu, D., Iniiere n ingineria softului, Editura Albastr, ediia a II-a, 2002
[2] Bennet, S., Mc Robb, S., Farmer, R., Object Oriented Systems Analysis and Design using
UML, McGraw-Hill Publishing Company, 1999