Ingineria și fiabilitatea programelor software

(Engineering and Software Reliability)

(Full text in Romanian)

Titu-Marius I. BĂJENESCU1
1Prof., Doctor Honoris Causa of Military Technical Academy of Romania and of Technical University of Republic of Moldova (Chișinău); Romanian
Academy Prize „Tudor Tănăsescu” Laureate; La Conversion, Switzerland

Abstract
Software engineering comprehends several disciplines devoted to prevent and remedy malfunctions and to warrant adequate
behaviour. Testing is a widespread validation approach in industry, but it is still largely ad hoc, expensive, and unpredictably
effective. Indeed, software testing is a broad term encompassing a variety of activities along the development cycle and
beyond, aimed at different goals.
Keywords: software engineering, testing, malfunction, research, analysis techniques, roadmap.
Received: June, 08, 2016
To cite this article:
BĂJENESCU I. T.-M., „Ingineria și fiabilitatea programelor software” (Engineering and Software Reliability), in Electrotehnica,
Electronica, Automatica (EEA), 2016, vol. 64, no. 4, pp. 66-70, ISSN 1582-5175.

1. Introducere activitatea de testare ar putea fi desfășurată în

Ingineria software cuprinde mai multe discipline
pentru a preveni și remedia defecţiunile și pentru a
garanta un comportament adecvat. Testarea este o
abordare de validare pe scară largă în industrie, dar este
încă în mare măsură ad-hoc, costisitoare, cu eficacitate
impredictibilă. Testarea software-ului se bazează pe
teoria matematică, arta și practica de validare, precum și
metodologia de dezvoltare a software-ului. Pentru a
acoperi acest vast domeniu ar fi nevoie de un manual (sau
de mai multe articole).
Testarea software-ului este un termen general care
cuprinde o varietate de activităţi de-a lungul ciclului de
dezvoltare (și dincolo de el), care vizează obiective
diferite. De aceea, cercetarea privind testarea software-
ului se confruntă cu o colecţie de provocări. O foaie de
parcurs coerentă a celor mai relevante provocări a fost
propusă în [1]. Punctul ei de plecare îl constituie unele
realizări importante din trecut [2-25], iar scopul ei este
format din patru obiective finale identificate, către care
cercetarea tinde, dar care rămân de neatins, ca un vis
frumos. Căile de realizare a visului sunt pavate de
provocări deosebite ale cercetării.
2. Multiplele faţete ale testării software-ului
Testarea software-ului este un termen general care
cuprinde un spectru larg de activităţi diferite, de la
testarea unei părţi a unui mic cod (unitatea de testare) de
către dezvoltator, la validarea de către client a unui
sistem informatic de mari dimensiuni (acceptarea
testării), pentru monitorizarea în timpul funcţionării a
unei reţele centrate pe o aplicaţie orientată spre servicii.
În diferite etape, cazurile de testare ar putea fi concepute
cu scopul de a avea obiective diferite, cum ar fi expunerea
la abaterile de la cerinţele utilizatorului, sau evaluarea
conformării cu o specificaţie standard, sau de evaluare a
robusteţii în condiţii de stres de încărcare, sau de intrări
rău intenţionate, sau de măsurare a atributelor date - cum
ar fi performanţa sau gradul de utilizare, sau estimarea
fiabilităţii operaţionale, și așa mai departe. În plus,
conformitate cu o procedură formală controlată, care
necesită planificare și documentare riguroase, sau mai
degrabă informale și ad-hoc (teste exploratorii).
Ca o consecinţă a acestei varietăţi de obiective și a
domeniilor de aplicare, ia naștere o multitudine de
înţelesuri pentru cuvintele "testarea software-ului", care
au generat multe provocări cercetării. Pentru a organiza
testarea într-o viziune unificatoare, vom încerca o
clasificare a problemelor comune multor aspecte de
testare a software-ului. Primul concept ar fi acela de a
determina care este numitorul comun - în cazul în care
acesta există - între toate aspectele posibile de testări
diferite. Un astfel de numitor comun poate fi punctul de
vedere foarte abstract că, având în vedere o porţiune, o
bucată de software (în funcţie de tipologia, dimensiunea
și domeniul de testare) testarea constă întotdeauna în
observarea unui eșantion de execuţii și de a elabora un
verdict asupra lui.
Pornind de la acest punct de vedere foarte general,
putem concretiza instanţe diferite prin diferenţierea
aspectelor specifice care pot caracteriza eșantionul de
observaţii (vezi figura 1) [1]:
DE CE (Why): De ce facem observaţiile? Această
întrebare se referă la obiectivul de testare, de exemplu,
căutăm defecte? sau trebuie să decidem dacă produsul
poate fi autorizat? sau mai degrabă trebuie să evaluăm
gradul de utilizare a interfeţei utilizator?
CUM (How): C m observăm eșantionul și cum facem
alegerea lui? Aceasta este problema selecţiei de testare,
care poate să fie făcută ad-hoc, în mod aleatoriu, sau în
mod sistematic prin aplicarea unor tehnici algoritmice sau
statistice. A inspirat mult cercetarea, ceea ce este de
înţeles, nu numai deoarece este atractiv intelectual dar,
de asemenea, pentru că modul în care cazurile de test
sunt selectate – deci criteriul de testare - influenţează
foarte mult eficacitatea de testare.
CÂT DE MARE (How much): Cât de mare este o probă?
Cu dublă întrebare privind modul în care putem alege
eșantionul observaţiilor (selecţie de testare), și cât de
 ELECTROTEHNICA, ELECTRONICA, AUTOMATICA, 2016, vol. 64, no. 4
multe dintre ele să luăm (adecvarea testului sau regula de
stop). Analiza de acoperire sau fiabilitatea măsurării
constituie două abordări "clasice" pentru a răspunde la o
astfel de întrebare.
CE (What): Ce anume executăm? Având în vedere
sistemul supus testului (s-ar putea să avem un sistem
compozit), putem observa executarea lui fie luându-l ca
un întreg, sau concentrându-ne doar asupra unei părţi din
sistem, care poate fi mai mult sau mai puţin important
(test de unitate, test de componentă / subsistem, test de
integrare), mai mult sau mai puţin definit: acest aspect dă
naștere la diferite niveluri de testare, și a eșafodajului
necesar pentru a permite executarea testului, a unei părţi
dintr-un sistem mai mare.
UNDE (Where): Unde efectuăm observaţia? Strict legat
de ceea ce executăm, este întrebarea dacă acest lucru se
face în firmă, într-un mediu simulat sau în contextul final
Figura 1. Foaia de parcurs a ingineriei de test a software-ului [1]. Pe foaia de parcurs, patru benzi orizontale descriu traseele de cercetare
identificate spre vise, și anume: (1) Teoria de testare universală; (2) Modelarea bazată pe test; (3) Testare automată 100%; (4)
Inginerie de testare maximizată pe eficacitate
3. Fiabilitatea software-ului
Încercarea de fiabilitate. Dată fiind ubicuitatea
software-ului, fiabilitatea lui (adică probabilitatea de
funcţionare fără defecţiuni pe o perioadă de timp
specificată, într-un mediu specificat) influenţează astăzi
orice produs tehnologic. La testarea fiabilităţii niciodată
nu putem descoperi ultima defectare și, de aceea, prin
utilizarea profilului operaţional pentru a conduce
testarea, se încearcă eliminarea acelor eșecuri care s-ar
manifesta mai frecvent. Intuitiv, dispozitivul de testare
imită modul în care utilizatorii vor folosi sistemul.
Fiabilitatea software-ului este de obicei dedusă pe baza
modelelor de fiabilitate; diferite modele ar trebui
utilizate, în funcţie de eliminarea defectelor detectate,
caz în care fiabilitatea crește (sau nu), când fiabilitatea
este doar certificată.
67
al ţintei. Această întrebare presupune cea mai mare
relevanţă atunci când este vorba de testarea sistemelor
înglobate (embedded systems).
CÂND (When): În ciclul de viaţă al produsului pe care
îl studiem, când vom efectua observaţiile ? Argumentul
convenţional este că mai devreme este cel mai
convenabil, deoarece costul eliminării deranjamentului
crește pe măsură ce avansăm în ciclul de viaţă. Însă unele
observaţii, în special cele care depind de mediul ambiant,
nu pat fi întotdeauna anticipate în laborator, și nu putem
continua orice observaţie semnificativă până la
implementarea și darea în funcţiune a sistemului.
Aceste întrebări furnizează o caracterizare foarte
simplă și intuitivă a activităţii de testare a software-ului,
care ne sunt de ajutor în punerea la punct a foii de parcurs
pentru provocările viitoare de cercetare (fig. 1).
Cercetarea fiabilităţii software-ului a intersectat
cercetările în testarea software-ului în mai multe moduri
fructuoase. Modele pentru fiabilitatea software-ului au
fost studiate în mod activ între anii 1980 și 1990 [26].
Aceste modele sunt acum mature și pot fi folosite în
procesul de testare, oferind îndrumare cantitativă pentru
cum și cât de mult să testăm. De exemplu, aceasta a fost
realizată de către Musa în contribuţia sa intitulată
Software Reliability Engineered Testing (SRET) (capitolul
6 din [26]), și este, de asemenea, susţinută în Cleanroom
development process, care urmărește aplicarea testului
statistic pentru a obţine măsurări certificate de
fiabilitate [27].
Din păcate, practica testelor de fiabilitate n-a ţinut
pasul cu progresele teoretice ale fiabilităţii software-ului,
probabil pentru că este (percepută ca) un complex
costisitor de activitate și - de asemenea - pentru
dificultatea inerentă de a identifica profilul operaţional
68 ELECTROTEHNICA, ELECTRONICA, AUTOMATICA, 2016, vol. 64, no. 4
necesar [28]. !n plus, astăzi cererea pentru fiabilitate și
alte calităţi de dependenţă este în creștere și, de aceea,
apare necesitatea abordării practice pentru a testa în mod
coerent, funcţional și extra funcţional, comportarea
sistemelor moderne care utilizează intensiv software.
În Spinoasa problemă a fiabilităţii software-ului,
Littlewood [29] a enunţat câteva teze importante și
anume: măsurarea și prezicerea fiabilităţii software-ului
este astăzi unul din domeniile știinţifice cele mai demne
de respect, însă trebuie să ţinem seama de severe limitări
la nivelurile de fiabilitate pe care putem să le măsurăm
efectiv; aceasta fără să mai vorbim de faptul că s-au
construit sisteme cu o siguranţă critică în funcţionare,
care cer niveluri de fiabilitate ale software-ului cu câteva
ordine de mărime mai mari decât cele care pot fi efectiv
măsurate1.
Faţă de această situaţie, ne putem întreba, pe bună
dreptate: care sunt limitele nivelurilor de fiabilitate ale
software-ului pe care le putem măsura? Sunt aceste limite
intrinseci? Cum ne putem convinge că ţelurile pe care le-
am realizat efectiv cu software-ul din sistemul nostru sunt
acoperitoare atunci când erorile de soft, de concepţie sau
de proiectare joacă un rol critic? Înseamnă oare aceasta
că ar trebui să facem astfel încât să nu depindem de
software în aplicaţiile critice pentru siguranţa în
funcţionare? Sau – extrapolând – înseamnă oare că n-ar
trebui să utilizăm software în aplicaţiile critice din punctul
de vedere al siguranţei în funcţionare? Sau – și mai ascuţit
exprimat – înseamnă aceasta că sunt sisteme pe care n-ar
trebui să le construim?
Ce ar trebui să facem pentru a exprima cerinţele de
dependenţă în limbajul probabilităţii? Căci există o
nesiguranţă inerentă privind comportarea în cazul
defectării sistemului datorită naturii imprevizibile a
mediului înconjurător sau datorită cunoștinţelor
incomplete ale observatorului, privind posibilele
comportări ale sistemului. Toate acestea ne forţează să
adoptăm măsuri probabilistice pentru a putea ţine seama
de aceste nesiguranţe. Iar din punct de vedere informal,
avem nevoie să câștigăm destulă încredere că sistemul nu
va cădea în pană prea frecvent, sau se va defecta cu o
probabilitate suficient de mică de-a lungul unui timp de
funcţionare deosebit de lung, etc.
Cât privește câștigarea încrederii într-o fiabilitate
extrem de înaltă, se pare că există două tipuri de dovezi:
dovezi directe provenind din observaţiile comportării
actuale a sistemului însuși (de exemplu, evaluarea directă
a fiabilităţii din comportarea la defectare); și dovezi
indirecte furnizate de alte atribute ale sistemului (de
exemplu, natura și calitatea concepţiei, a proiectării, a
procesului de dezvoltare, a analizei statistice, etc.). Ce
încredere putem avea însă în aceste dovezi?
4. Dovezi directe
Modelarea creșterii fiabilităţii software-ului a
înregistrat succese în anii din urmă și astăzi este – în
general – posibil să măsurăm și să "prezicem" fiabilitatea
software-ului, cu acurateţă, pentru niveluri modeste ale
fiabilităţii.
1 2
Așa, de pildă, caietul de sarcini al unor avioane de pasageri bine
cunoscute (A320/30/40, B777, etc.) cere o probabilitate de eroare
de 10-9 pentru ora de zbor, iar pentru semnalizare și control pe căile
ferate franceze, societatea SACEM "impune" o probabilitate de
eroare de 10-12 pentru ora de funcţionare!
Pentru aplicaţii critice ale siguranţei în funcţionare
există încă serioase dificultăţi, datorită problemei
"reprezentativităţii" cazurilor care servesc drept "intrare",
dar și datorită legii micșorării retururilor – ca efect al
reclamaţiilor din ce în ce mai reduse ca număr. În mod
intuitiv, toate acestea pot fi caracterizate ca fiind
evidente, căci – după cum se știe – fiabilitatea software-
ului nu poate fi "tested in", însă mărimea veritabilă a
problemei rămâne mai puţin evidentă.
Pentru sistemele critice din punctul de vedere al
siguranţei în funcţionare, problema este și mai serioasă,
căci la nivelurile respective trebuie să ne chinuim pentru
a ști dacă valorile "fixe" sunt efective (așa cum presupun
modelele de creștere a fiabilităţii software-ului), întrucât
a) ultimul "fix" s-ar putea să fi făcut sistemul mai "rău"
decât era înainte de defectare; și b) pentru o aplicaţie
critică din punctul de vedere al siguranţei în funcţionare,
se pare că cel mai sigur este să ţinem seama de
funcţionarea fără defectare, de la data când programul a
fost schimbat ultima oară.
Câtă încredere să avem într-un sistem care n-a căzut
niciodată în pană? Dacă ţinem seama de presupuneri
destul de plauzibile, o cale de acces "bayesiană" ne
conduce la următoarea concluzie: dacă un sistem a
supravieţuit – fiind permanent în funcţiune – t0 unităţi de
timp, fără defectare, există o șansă de 50:50 ca alte t0
unităţi de timp de funcţionare să se scurgă până la
următoarea defectare2. (Analiza clasică și "bayesiană" ne
conduc - practic - la aceleași rezultate).
Calea "bayesiană" permite să utilizăm a priori o
anumită convingere; însă pentru a susţine că un soft are o
fiabilitate extrem de ridicată, plecând de la o modestă
zestre de date – drept unică justificare –, convingerea
dumneavoastră precedentă în fiabilitatea respectivă
trebuie să fi fost extrem de nerezonabil ridicată!
Există alte surse de informaţii – în afara testelor – care
ne pot permite să avem o mai mare încredere? (De
exemplu, care să ne permită – în mod justificat – să fim
"tari" în opiniile noastre, înainte de a fi convinși de
contrariu.)
5. Dovezi indirecte
Principalele candidate în această privinţă sunt:
Cunoștinţe ale eficacităţii procesului de dezvoltare,
pentru probleme similare, ceea ce presupune o "bună
practică" în domeniu. De pildă, la întrebarea: a fost un
"bun" produs de toate cele n ori când a fost utilizat în
trecut?; ce șansă va avea să fie bun și de această dată?
Răspunsul sună: Este un argument "bayesian" naiv, dar
rezonabil plauzibil, care ne dă probabilitatea (n + 1) / (n
+ 2). Din nou, s-ar putea să vi se pară un sofism, un joc de
cuvinte, însă argumentul este bun în privinţa ordinului de
mărime. Dimpotrivă, argumentul este slab, dacă valoarea
lui n este destul de mică. (Inginerii specializaţi în soft par
însă să privească valoarea n = 1 drept o evidenţă
extensivă!)
Metodele formale - bazate atât pe procesul de
dezvoltare (drept verificare – parţială – a procedeului), cât
De exemplu, pentru un software critic destinat aplicaţiilor de zbor,
am avea nevoie de 109 ore de funcţionare fără pană (vreo 114.155
ani!) pentru a putea ajunge la concluzia certă că a fost vorba de un
timp mediu până la defectare de 109 ore.
 ELECTROTEHNICA, ELECTRONICA, AUTOMATICA, 2016, vol. 64, no. 4
și pe analiza statică (de exemplu, MALPAS). Verificarea
poate complet proteja împotriva unei clase de greșeli de
implementare (de exemplu, specificarea penelor – în
particular, omisiuni); verificarea nu ne ferește însă de
efectele acestora. Argumentele bazate pe eficacitatea din
trecut – în experienţe sau în studii de caz – suferă de
aceeași slăbiciune ca și argumentele "procesului" de mai
sus.
Toleranţa la defectare, diversitatea design-ului. Nu
putem adopta naiva analogie cu hardware-ul și să
presupunem că versiunile vor cădea în pană independent
una de alta. Există o evidenţă empirică care ne spune că
vor fi defectări comune, precum și motive teoretice
pentru pene dependente, chiar dacă versiunile sunt
efectiv independente.
Este însă evident că diversitatea furnizează câteva
îmbunătăţiri în comparaţie cu versiunile unice; întrebarea
este însă câte? Am putea încerca să estimăm gradul de
dependenţă atins, însă aceasta se dovedește în practică a
fi la fel de greu de rezolvat ca și problema iniţială a
estimării "cutiei negre"! Am mai putea apela la succese din
trecut și la grade de dependenţă realizate în utilizarea
operaţională a aplicaţiilor precedente ale metodologiei;
aceasta este însă problema procesului pe care am
considerat-o mai înainte, și – după cum am văzut –
argumentul este slab.
Revenim astfel la următoarele întrebări, rămase –
deocamdată – fără răspuns, care sintetizează în același
timp și niște concluzii utile, de care va trebui să ţinem
seama în activitatea noastră de viitor:
− Cum ne convingem pe noi înșine că ţelurile de
fiabilitate au fost atinse, atunci când software-ul (sau
greșelile de proiectare) joacă un rol critic?
− Care sunt limitele nivelurilor de fiabilitate pe care le
putem măsura? (Răspuns: destul de modeste: 10-4).
− Sunt aceste limite intrinseci? (Răspuns: probabil;
problema se referă la relativa sărăcie de date care
pot fi obţinute în mod rezonabil, și nu are nimic de a
face cu modelele de probabilitate).
− Putem face mai bine? (Răspuns: probabil, dar puţin;
avem nevoie de date mai multe și mai bune, cât și de
mijloace pentru a putea combina dovezi disparate).
− Înseamnă toate acestea că ar trebui să ne străduim să
nu depindem de soft în aplicaţii critice din punctul de
vedere al siguranţei în funcţionare? (Răspuns: cel
puţin în acele cazuri în care cerinţele de fiabilitate
globală ale sistemului depind de o fiabilitate extrem
de ridicată a software-ului
− Trebuie trasă concluzia că n-ar trebui să utilizăm soft
în aplicaţii critice din punctul de vedere al siguranţei
în funcţionare? (Răspuns: nu, unele aplicaţii au
cerinţe modeste de fiabilitate pentru software.
Uneori putem satisface chiar cerinţele unui sistem cu
cerinţe ridicate, atâta vreme cât vom reţine
avantajele software-ului, de exemplu reutilizarea
unui soft pentru care o lungă experienţă în exploatare
ne-a dovedit lipsa penelor, pentru un important timp
cumulat de funcţionare).
− Cerinţele pentru sisteme critice, din punctul de
vedere al siguranţei în exploatare, trebuie să includă
pentru subsisteme cerinţe numerice bazate pe
probabilitate, incluzând și software-ul. Pentru fiecare
sistem critic trebuie demonstrat știinţific că nivelul
cerut a fost atins. Sistemele critice care nu pot fi
69
validate în acest fel n-ar trebui certificate pentru
utilizare.
6. Concluzie
Testarea software-ului este o disciplină de cercetare
plină de viaţă, bogat și dificil articulată; sperăm că
această lucrare a oferit o imagine de ansamblu utilă
privind provocările actuale și viitoare.
7. References
[1] A. Bertolino, “Software Testing Research: Achievements,
Challenges, Dreams,” IEEE Computer Society, Proc. Future of
Software Engineering 2007 (FOSE'07), pp. 85-103.
[2] L. Baresi and M. Young, Test oracles. Technical report, Dept. of
Comp. and Information Science, Univ. of Oregon, 2001.
http://www.cs.uoregon.edu/michal/pubs/oracles.html.
[3] L. Baresi and Mauro Pezzé, “An introduction to software testing,
Electronic Notes” in Theoretical Computer Science 148 (2006)
pp. 89–111.
[4] E. Bayse, A. R. Cavalli, M. Nuñez, and F. Zaïdi, “A passive testing
approach based on invariants: application to the wap”.
Computer Networks, 48(2):235–245, 2005.
[5] B. Beizer, Software Testing Techniques (2nd ed.). Van Nostrand
Reinhold Co., New York, NY, USA, 1990.
[6] Belinfante, L. Frantzen, and C. Schallhart. Tools for test case
generation. IEEE-CS Press, 2007.
[7] S. Berner, R. Weber, and R. Keller, “Observations and lessons
learned from automated testing”. In Proc. 27th Int. Conf. on Sw.
Eng., pp. 571–579. ACM, 2005.
[8] G. Bernot, M. C. Gaudel, and B. Marre, “Software testing based
on formal specifications: a theory and a tool”. Softw. Eng. J.,
6(6):387–405, 1991.
[9] A. Bertolino, “ISSTA 2002 Panel: is ISSTA research relevant to
industrial users?” In Proc. ACM/SIGSOFT Int. Symp. on Software
Testing and Analysis, pp. 201–202. ACM Press, 2002.
[10] A. Bertolino and E. Marchetti, “Software testing” (chapt.5). In P.
Bourque and R. Dupuis, editors, Guide to the Software
Engineering Body of Knowledge SWEBOK, 2004 Version, pp. 5–16.
IEEE Computer Society, 2004. http://www.swebok.org.
[11] A. Bertolino, E. Marchetti, and H. Muccini, “Introducing a
reasonably complete and coherent approach for modelbased
testing”. Electr. Notes Theor. Comput. Sci., 116:85–97, 2005.
[12] A. Bertolino and A. Polini, “The audition framework for testing
web services interoperability”. In Proc. EUROMICRO ’05, pp. 134–
142. IEEE, 2005.
[13] A. Bertolino, A. Polini, P. Inverardi, and H. Muccini, “Towards
anti-model-based testing”. In Proc. DSN 2004 (Ext. abstract), pp.
124–125, 2004.
[14] S. Biffl, A. Aurum, B. Boehm, H. Erdogmus, and P. Gruenbacher,
editors. Value-Based Software Engineering. Springer-Verlag,
Heidelberg, Germany, 2006.
[15] S. Biffl, R. Ramler, P. Gruenbacher, “Value-based management
of software testing”. In [12].
[16] R. V. Binder, Testing Object-Oriented Systems Models, Patterns,
and Tools. Addison Wesley Longman, Inc., Reading, MA, 2000.
Future of Software Engineering (FOSE'07) 0-7695-2829-5/07,
2007
[17] C. Blundell, D. Giannakopoulou, and C. S. Pasareanu, “Assume-
guarantee testing”. In Proc. SAVCBS ’05, pp. 7–14. ACM Press,
2005.
[18] G. V. Bochmann and A. Petrenko, “Protocol testing: review of
methods and relevance for software testing”. In Proc.
ACM/SIGSOFT Int. Symp. Software Testing and Analysis, pp. 109–
124, 1994.
[19] M. Boshernitsan, R. Doong, and A. Savoia. “From Daikon to
Agitator: lessons and challenges in building a commercial tool for
developer testing”. In Proc. ACM/SIGSOFT Int. Symp. Software
Testing and Analysis, pp. 169–180. ACM Press, 2006.
[20] L. Briand, Y. Labiche, and Y. Wang, “An investigation of graph-
based class integration test order strategies”. IEEE Trans. Softw.
Eng., 29(7):594–607, 2003.
[21] L. Briand and A. Wolf (editors), Future of Software Engineering.
IEEE-CS Press, 2007.
70 ELECTROTEHNICA, ELECTRONICA, AUTOMATICA, 2016, vol. 64, no. 4
[22] L. C. Briand, Y. Labiche, and M. M. Sowka. “Automated,
contract-based user testing of commercial-off-theshelf
components”. In Proc. 28th Int. Conf. on Sw. Eng., pp. 92–101.
ACM Press, 2006.
[23] M. Broy, B. Jonsson, J.-P. Katoen, M. Leucker, A. Pretschner,
editors. Model-Based Testing of Reactive Systems - Advanced
Lectures, LNCS 3472. Springer Verlag, 2005.
[24] G. Canfora and M. di Penta, “The forthcoming new frontiers of
reverse engineering”. In [19].
[25] G. Canfora and M. di Penta, “Testing services and servicecentric
systems: Challenges and opportunities”. IT Professional, 8(2):10–
17, March/April 2006.
[26] N. Delgado, A. Q. Gates, and S. Roach. “A taxonomy and catalog
of runtime software-fault monitoring tools”. IEEE Trans. Softw.
Eng., 30(12):859–872, 2004.
[27] E. Dijkstra, Notes on structured programming. Technical Report
70-WSK03, Technological Univ. Eindhoven, 1970.
http://www.cs. utexas.edu/users/EWD/ewd02xx/EWD249.PDF
[28] M. Lyu (ed.), Handbook of Software Reliability Engineering,
McGraw-Hill, New York, and IEEE CS Press, Los Alamitos, 1996.
[29] J. Poore, H. Mills, and D. Mutchler, “Planning and certifying
software system reliability”. IEEE Software, Jan. 1993, pp. 87-
99.
[30] D. Hamlet and R. Taylor. “Partition testing does not inspire
confidence. IEEE Trans”. Softw. Eng., 16(12), 1990, pp. 1402–
1411.
[31] B. Littlewood, “Evaluation of Software Reliability - Achievements
and Limitations”. International Symposium on Reliability
Engineering, ETH Zurich, Oct. 1996.
Biography
Titu-Marius I. BĂJENESCU was born in Câmpina
(Romania) on April 2, 1933.
He received his engineering training at the
Polytechnic Institute Bucharest.
He served for the first five years in the Romanian
Army Research Institute, including tours on radio
and telecommunications maintenance, and in the
reliability, safety and maintainability office of the Ministry of
Defence (main base ground facilities).
R&D Experience: design and manufacture of experimental
equipment for Romanian Army Research Institute and for air
defence system.
He joined Brown Boveri (today: ASEA Brown Boveri) Baden
(Switzerland) in 1969, as a research and development engineer.
R&D Experience: design and manufacture of new industrial
equipment for telecommunications.
In 1974, he joined Hasler Limited (today: ASCOM), Berne, as
Reliability Manager (recruitment by competitive examination).
Experience: Set up QRA and R&M teams. Developed policies,
procedures and training. Managed QRA and R&M programmes.
As QRA Manager monitoring and reporting on production quality
and in-service reliability.
As Switzerland official, contributed to development of new ITU
and IEC standards.
In 1981, he joined “Messtechnik und Optoelektronik” (Neuchâtel,
Switzerland, and Haar, West Germany), a subsidiary of
Messerschmitt-Bölkow-Blohm (MBB) Munich, as Quality and
Reliability Manager (recruitment by competitive examination).
Experience: Product Assurance Manager of “intelligent cables”.
Managed applied research on reliability (electronic components,
system analysis methods, test methods, etc.).
Since 1985, he has worked as an independent consultant and
international expert on engineering management, tele-
communications, reliability, quality and safety.
Mr. Băjenescu is the author of many technical books published in
English, French, German and Romanian.
He is university professor and has written many papers and articles
on modern telecommunications, and on quality and reliability
engineering and management. He lectures as an invited professor,
visiting lecturer or speaker at European universities and other
venues on these subjects.
Since 1991, he won many Awards and Distinctions, presented by
the Romanian Academy, Romanian Society for Quality, Romanian
Engineers Association, etc. for his contribution to reliability
science and technology.
Recently he received the honorific titles of Doctor Honoris Causa
of the Romanian Military Academy and from Technical University
of the Republic of Moldavia (Chișinău).
In 2013, he obtained, together with prof. Marius Bâzu (head of
reliability laboratory of Romanian Research Institute for Micro- and
Nanotechnologies IMT) − the "Tudor Tănăsescu" prize of the
Romanian Academy for the book Failure Analysis, published by
John Wiley & Sons.
e-mail: tmbajenesco@bluewin.ch