Favorite IP

||||| 1. (0.5p) Avantajele si dezavantajele modelului “iterativ si incremental” in

comparatie cu modelul “in cascada”.
Produsul software este dezvoltat in mai multe iteratii, fiecare iteratie
incluzand un “ciclu de dezvoltare de cascada". Fiecare iteratie se incheie cu un
produs executabil.
Avantaje ale modelului de dezvoltare "iterativ si incremental" fata de
modelul de dezvoltare "in cascada":
- in fiecare iteratie este livrat un produs executabil, care satisface o parte din
cerintele utilizator, spre deosebire de modelul "in cascada", unde produsul
executabil este disponibil tarziu, ceea ce creste riscurile de neacceptare;
- este flexibil la schimbarea cerintelor, spre deosebire de modelul "in
cascada", care nu este recomandat pentru proiectele in care cerintele sunt neclare
sau se pot schimba pe parcurs;
- depanarea si testarea sunt usor de efectuat, prin faptul ca se urmareste
testarea functionalitatilor adaugate in iteratia curenta, in comparatie cu modelul "in
cascada", in care multe dintre erori sunt descoperite tarziu;
- riscurile sunt reduse, in comparatie cu modelul "in cascada", unde toate
riscurile sunt incluse intr-un singur ciclu de dezvoltare.

Dezavantaje ale modelului de dezvoltare "iterativ si incremental" fata de

modelul de dezvoltare "in cascada":
- documentatia este construita treptat, in timpul fiecarei iteratii, spre
deosebire de modelul "in cascada", in care sistemul este bine documentat inca de la
inceput;
- se poate transforma usor intr-o abordare "build and fix", ce va afecta
calitatea produsului final, precum si durata de dezvoltare, in comparatie cu modelul
"in cascada", care permite un bun management al proiectului, prin planificarea
resurselor umane pe etape si estimarea exacta a costurilor.
2. (0.5p) Adaptabilitatea este (specificati raspunsurile corecte):
a. cerinta functionala
b. constrangere de implementare a cerintelor utilizatorilor
c. calitate a produsului software
d. usurinta de modificare pentru mutarea pe alta platforma
e. usurinta de eliminare a erorilor
f. usurinta de modificare la schimbarea cerintelor

3. (0.5p) Modelul conceptual al unui sistem (specificati raspunsurile corecte):

a) Este construit in etapa de definire a cerintelor utilizator;
b) Este construit in etapa de definire a cerintelor software;
c) Este construit in etapa de proiectare arhitecturala;
d) Descrie modul de implementare a cerintelor software;
e) Este independent de implementare.

5. (0.25p) Care sunt calitatile unei arhitecturi software , principii de modularizare.

Care este masura care exprima cuplarea intre clase?
- adaptabilitatea (robustetea la schimbari): usurinta de modificare si intretinere
- eficienta: utilizarea eficienta (la minimum) a resursele disponibile
- usurinta intelegerii
Principii de modularizare:
- Modulele trebuie sa fie simple si cat mai independente unul de altul
- O modificare a unui modul are influenta minima asupra altor componente
- O schimbare mica a cerintelor nu conduce la modificari majore ale
arhitecturii
- Efectul unei conditii de eroare este izolat in modulul care a generat-o
 - Un modul poate fi inteles ca o entitate de sine-statatoare
- Modulele trebuie sa “ascunda” modul de implementare a interfetei lor
(information hiding)
O clasa este cuplata cu o alta clasa (nu prin mostenire) daca ea refera metodele
sau variabilele instanta ale celeilalte.
Dezavantaje:
- Cuplarea excesiva este defavorabila proiectarii modulare si limiteaza
reutilizarea. Cu cat o clasa este mai independenta cu atat este mai usor de
reutilizat intr-o alta aplicatie.
- Cu cat numarul de clase cuplate este mai mare, cu atat mai mare este
sensibilitatea la schimbari ale clasei, in alte parti ale programului.
Intretinerea este mai dificila.
- Cu cat cuplarea este mai stransa, cu atat mai greu de inteles

6. (0.25p) Diagramele de stari se folosesc pentru (specificati raspunsurile corecte):

a. Modelarea sistemelor reactive
b. Modelarea comportamentului in timp al obiectelor unei clase
c. Reprezentarea actiunilor paralele
d. Modelarea interactiunilor dintre obiecte

|| 7. (1p) Diagrama de clasa pt o firma care pune la dispozitia angajatilor sai mai
multe masini. Masinile sunt dotate cu motoare noi si sisteme de transmisie noi.
Un motor este alcatuit din 8 cilindri si un carburator. Odata asamblate intr-un
motor, cei 8 cilindri si carburatorul nu mai pot fi dezasamblate pentru a fi folosite
in alt motor. La o masina se poate schimba motorul si sistemul de transmisie
independent.
Fiecare angajat utilizeaza o singura masina. Fiecare masina poate fi utilizata de mai
multi angajati.
Se doreste evaluarea performantelor noilor motoare si sisteme de transmisie din
fiecare masina. Pentru aceasta, fiecare angajat evalueaza masina pe care a folosit-o
si face o apreciere in care specifica: intervalul de timp in care a folosit masina, o
nota de la 1 la 5 pentru motor si o nota de la 1 la 5 pentru sistemul de transmisie.
Un angajat se identifica prin numele sau, o masina prin numarul sau, un motor prin
seria sa, iar un sistem de transmisie printr-un identificator.
TODO

|||||| 8. (1.25p) Prezentati tipurile de teste efectuate pe parcursul dezvoltarii unui

produs software. Se va preciza pentru fiecare tip de teste:
a) Ce fel de verificari se urmaresc prin acel tip de teste;
b) Cum se efectueaza si cine participa la executia lor.
1.Teste unitare:
-se efectueaza la nivelul unei unitati de program: functie, procedura, functie
membru a unei clase
-sunt realizate de programator
-unitatea testata este tratata ca o entitate independenta
-unitatile cu care interactioneaza unitatea testata sunt simulate prin module ciot si
modul driver
-rezultatele fiecarui apel al modulului testat sunt afisate/scrise intr-un fisier
-se poate utiliza un tabel intrari - rezultate asteptate.
Exemplu: testarea unei functii

2.Testarea de integrare
-scop: integrarea modulelor dezvoltate independent intr-un sistem functional
-dedicate verificarii interactiunilor dintre module, grupuri de module, subsisteme
etc
-presupun realizarea de module ciot si driver (nr lor depinde de ordinea in care sunt
testate modulele)
-necesita instrumente de gestiune a versiunilor si configuratiilor
-metoda: big-bang: sunt integrate intr-un program .exe toate modulele existente la
un moment dat (inclusiv ciot si driver); metoda este periculoasa caci toate erorile
apar in acelasi timp si localizarea lor este dificila
-integrare: progresiva, ascendenta, descendenta, hibrida, sandwich
3.Testarea de sistem
-obiectiv: se verifica daca sistemul software satisface cerintele specificate
-sunt teste ale sistemului de programe si echipamente complet. sistemul este
instalat si apoi testat in mediul sau real de functionare sau simulat.
-adesea ocupa cel mai mult timp din perioada de testare
-toate testele sunt de tip cutie neagra
-tipuri teste: functionale, performanta, comunicare, utilizare resurse, fiabilitate,
securitate, portabilitate, siguranta in functionare, stres.

4.Testarea de acceptare
-scop: verificarea conformitatii cu produsul solicitat, conform contractului cu
clientul
-participa si clientul, uneori testele fiind conduse de el
-pt unele produse are loc in 2 etape: alfa( folosindu-se specificatia cerintei
utilizator pana se cade de acord ca programul este o reprezentare satisfacatoare a
cerintelor) + beta(este distribuit unor utilizatori selectionati, realizandu-se testarea
in conditii reale de utilizare)
-conditie acceptare: sa aiba calitatile acceptate de client si utilizatorii tinta
-tipuri de teste: functionalitatea,acuratetea,integritatea datelor,recuperarea datelor,
usurinta de utilizare instalare configurare, performanta,fiabilitatea,intretinerea etc

5.Teste regresive
-sunt executate dupa corectarea unor erori pentru a verifica daca in cursul
corectarii nu au fost introduse alte erori
-sunt efectuate, de regula, in timpul perioadei de operare a sistemului
-pt usurarea muncii este necesar sa se arhiveze toate testele efectuate in timpul
dezvoltarii programului, permitand verificarea automata a rezultatelor testelor
regresive

Testari functionale
Este o testare de tip “black-box”(Black Box Testing).
Cazurile de test se bazeaza pe specificatia functionala a componentei testate.
Diferite metode de alegere a cazurilor de test
Testare “ad hoc”: programul este executat (in mod repetat) pentru intrari alese in
mod arbitrar din domeniul de intrare al programului sau din afara acestuia,
observandu-se comportarea sa – este principala metoda de reparare a problemelor
raportate de clienti!
Se construiesc cazuri de test prin care se verifica functiile programului dar si cazuri
cu valori speciale ale variabilelor de intrare si de iesire, care pot conduce la
descoperirea de defecte.
Pentru reducerea numarului de cazuri de test se folosesc diferite metode si
euristici: “pairwise testing”, partitionarea in clase de echivalenta, teste statistice.
Testare bazata pe modele formale derivate din cerintele de sistem sau specificatiile
functionale

Testari structurale
Graful de control este principalul instrument de testare structurala.
Avantaje: Pot fi generate automat:
– Graful de control, pornind de la codul sursa
– Predicatele de cale, pe baza grafului program
– Datele de test, alese aleator din domeniul datelor de intrare a.i. sa fie satisfacute
predicatele de cale.
Dezavantaje
Cazurile de test depind de structura programului, trebuie recalculate la orice
modificare nu pot fi reutilizate
Cazurile de test acopera functionalitatile implementate, nu le descopera pe cele
absente!

CONCLUZIE:
Testele structurale trebuie sa fie completate cu cele functionale.
Testele structurale pot evidentia unele erori care nu sunt descoperite prin testele
functionale, care folosesc esantioane ale datelor de intrare.
Se incepe cu testul functional si se continua cu cel structural.

|||| 9. (0.75p) Definiti 3 caracteristici de calitate ale produselor software dintre cele
definite in standardul ISO – 9126, si subcaracteristicile lor.
Standardul ISO – 9126 este un model de calitate software, organizat ierarhic in 6
caracteristici de nivel inalt, fiecare cu un set propriu de sub-caracteristici:
1) functionalitatea - existenta unui set de functii si proprietatile lor specificate;
subcaracteristici:
- oportunitatea – functiile oferite de produs sunt adecvate scopului
definit;
- precizia - furnizarea unor rezultate si efecte corecte sau agreate de
utilizatori;
- interoperabilitatea - capacitatea produsului de a interactiona cu
sisteme specificate;
- securitatea – capacitatea de a preveni accesul neautorizat la
programe sau date;
- conformitatea.
2) fiabilitatea - capacitatea produsului de a-si mentine nivelul de performanta,
pentru o perioada de timp definita; subcaracteristici:
- maturitatea – atribut bazat pe frecventa caderilor datorate
defectelor;
- toleranta la defecte – capacitatea de a-si mentine starea de
functionare in cazul unei caderi;
- usurinta de restabilire a starii de functionare normale dupa o
cadere;
- conformitatea.
3) usurinta de utilizare - efortul necesar pentru utilizarea produsului de catre un
set de utilizatori; subcaracteristici:
- usurinta de intelegere;
- usurinta de invatare;
- usurinta de operare;
- puterea de atractie;
- conformitatea.
4) eficienta - relatia dintre nivelul de performanta al produsului si cantitatea de
resurse utilizate; subcaracteristici:
- comportarea in timp - timpul de raspuns, rata tranzactiilor;
- utilizarea resurselor - CPU, memorie interna, spatiu pe disc;
- conformitatea.
5) usurinta de intretinere - usurinta de a efectua modificari; subcaracteristici:
- usurinta de analiza – usurinta de identificare a cauzei primare a
unei caderi;
- usurinta de modificare – efortul necesar pentru efectuarea unei
modificari;
- stabilitatea – sensibilitatea la schimbari;
 - usurinta de testare – efortul necesar pentru a testa o schimbare a
sistemului;
- conformitatea.
6) portabilitatea - capacitatea produsului de a putea fi transferat dintr-un mediu in
altul; subcaracteristici:
- adaptabilitatea;
- usurinta de instalare;
- usurinta de inlocuire;
- conformitatea.
10. (0.25) Prin ce tip de diagrame uml se poate reprezenta un scenariu?
 Diagrame de secventa care contin:
o Obiectele si actorii care participa la o interactiune intr-un scenariu /
caz de utilizare
o Secventa de mesaje schimbate intre obiecte / intre obiecte si actori
 Diagrame de activitate

|| 11. (0.5) Diagramele de activitate pot fi folosite pentru a reda:

a) Starile unui obiect pe parcursul vietii sale
b) Pasii unui proces de calcul
c) Interactiunea dintre obiecte
d) Fluxul controlului intr-o operatiune
e) Executia secventiala sau paralela a unui actiuni

||||| 12. (0.5p) Ce este un sablon de proiectare si prin ce este descris?

Scop:
-reutilizarea solutiilor de proiectare, pt rezolvarea unor pb similare cu unele deja
intalnite si rezolvate anterior
-creearea unui limbaj comun, pt comunicarea experientei in rezolvarea unor
probleme si solutiile lor de proiectare
Un sablon de proiectare descrie o problema care se intalneste in mode
repetat in proiectarea programelor si solutia generala pentru problema respectiva
astfel incat sa poata fi utilizata oricand dar nu in aceeasi mod de fiecare data.
Solutia este exprimata folosind clase si obiecte.
Atat descrierea problemei cat si solutia sunt abstracte astfel incat sa poata fi
folosite in multe situatii diferite

Un sablon are 4 elemente esentiale:

1.Un nume prin care poate fi referit -> se creeaza un vocabular de proiectare
2.Descrierea problemei. Se explica problema si contextul in care apare, cand
trebuie aplicat sablonul.
3.Descrierea solutiei: elementele care compun proiectul, relatiile dintre ele,
responsabilitatile si colaborarile
4.Consecintele aplicarii sablonului: permit evaluarea alternativelor de proiectare,
intelegerea costurilor si a beneficiilor aplicarii unui sablon.
Descrierea completa a unui sablon de proiectare:
1.Numele sablonului si clasificarea
2.Intentia: Ce realizeaza sablonul, care este scopul sau, ce probleme de proiectare
adreseaza
3.Alt nume prin care este cunoscut
4.Motivatia. Este descris un scenariu care ilustreaza o problema de proiectare si
cum este rezolvata problema. Scenariul ajuta la intelegerea descrierii mai abstracte
care urmeaza
5.Aplicabilitatea: situatiile in care poate fi aplicat si cum pot fi recunoscute aceste
situatii
6.Structura: reprezentata grafic prin diagrame de clase si de interactiune
7.Participanti: clasele si obiectele care fac parte din sablonul de proiectare si
responsabilitatile lor
8.Colaborari: cum colaboreaza participantii pt a-si indeplini responsabilitatile
9.Consecintele: care sunt compromisurile si rezultatele utilizarii sablonului
10.Implementare : daca trebuie avute in vedere anumite tehnici de implementare,
aspecte dependente de limbajul de programare
11.Exemplu de cod (C++ sau Smalltalk)
12.Utilizari cunoscute
13.Sabloane corelate

13. (0.75) Testele unitare si testele de integrare; scopul, cum se efectueaza, cine le
efectueaza?
Vezi ex. 8.

|| 14. (0.5) Explicati criteriul acoperirii setului de cai de baza in testarea structurala.
Cum se poate calcula numarul de cai din setul de baza?
Criteriul acoperirii setului de cai de baza: fiecare ramificatie a unui nod de
decizie trebuie testata pe o cale liniar independenta.
Setul cailor de baza se construieste iterativ, adaugand de fiecare data o cale care
contine cel putin un arc care nu este inclus in nici o alta cale din set.
Daca o cale introduce un nod nou (care nu este inclus in nici o alta cale liniar
independenta) atunci calea este liniar independenta, deoarece introduce automat si
un arc nou.
Complexitatea ciclomatica indica numarul de cai liniar independente prin codul
sursa = numarul de cazuri de test pe baza criteriului acoperirii setului de cai de
baza.
Complexitatea ciclomatica a unui program (McCabe, 1982):
v=e-n+2
- e este numarul de arce (edges),
 - n este numarul de noduri (nodes) ale grafului de control

||| 15. (0.25) Cum este definita fiabilitatea unui produs software in modelul de
calitate ... si care sunt subcaracteristicile sale?
18. Calitatile unui produs software conform standardului ISO-9126
Pentru ambele vezi ex. 9.

|| 17. (1p?) Diagrama de clase pt editor text

TODO
19. Descrieti pe scurt principalele tipuri de cerinte specificate in Documentul
cerintelor software. Care sunt tipurile de modele UML adecvate specificarii
cerintelor software?
|| 21. (1p) SRD - ce contine, cum se specifica, ce diagrame se folosesc,
etc.
Raspunsul pentru ambele:
SRD: Software requirements document: Reflecta punctul de vedere al
dezvoltatorului cu privire la produsul de dezvoltat.
Tipuri de cerinte software
a) Functionale
- Descriu functiile pe care trebuie sa le realizeze sistemul, intr-un mod
independent de implementare.
- Sunt derivate din cerintele operationale ale sistemului (Doc. Cerinte
Utilizator/Sistem)
- Specifica transformarile care trebuie efectuate asupra intrarilor si iesirile
care trebuie sa se obtina pentru fiecare tip de intrari, comportarea sistemului
pentru diferite tipuri de intrari.
Exemple:
 – masoara temperatura si o afiseaza in grade Celsius
– cere codul PIN, il verifica si afiseaza un mesaj de acceptare sau rejectare
b) Ne-functionale (suplimentare)
• Sunt atasate cerintelor functionale
• Majoritatea rezulta din constrangerile incluse in specificatia Cerintelor
Utilizator/Sistem
• Cerinte de: performanta, interfata, de operare, de verificare, de
portabilitate, de intretinere, de fiabilitate, s.a.

1)Cerinte de performanta
-Valori numerice atasate unor parametri masurabili cum ar fi: viteza, capacitatea,
precizia, frecventa. Exemplu: sistemul masoara temperatura cu o precizie de 1 grad
Celsius.
2)Cerinte de interfata
• Componente hardware/software cu care interactioneaza produsul
• Interfete interne / externe ale produsului software
3)Cerinte de operare
-Modul de comunicare cu operatorii umani, aspecte fizice si ergonomice ale
interfetei utilizator:
– Descrierea dialogului
– Aspectul ecranului in timpul dialogului
– Stilul limbajului de comenzi
4)Cerinte impuse resurselor fizice
– Puterea de prelucrare
– Memoria necesara
– Spatiul pe disc
5)Cerinte de verificare
-Efectuarea unor simulari (atunci cand sistemul nu poate fi testat in mediul
operational inainte de testarea de acceptare).
6)Cerinte impuse mediului de testare.
• Posibilitati de diagnosticare.
• Cerinte pentru testarea de acceptare.
7)Cerinte de portabilitate
– "Sa poata rula pe calculatorul X fara modificarea codului sau modificand cel
mult 2% din codul sursa”.
– "Nici o parte a software-ului nu trebuie scrisa in assembler."
8)Cerinte de intretinere
-Usurinta de reparare a erorilor, de imbunatatire sau adaptare la schimbarea
cerintelor. Exemplu: "Timpul de reparare a unei erori nu va depasi niciodata o
saptamana“.
9)Cerinte de fiabilitate
-Frecventa acceptata a caderilor software, in functie de categoria caderii:
–Severa, avertizare, informare.
10)Cerinte de securitate
-Cum sa fie securizat sistemul impotriva pericolelor:
– Erori utilizator (distrugerea accidentala a software-ului sau datelor)
– Hazarduri fizice (foc)
– Access ne-autorizat
– Virusi, securitatea comunicarii in retea
11)Cerinte de siguranta
-Protectia impotriva distrugerilor cauzate de caderile software. De exemplu, ce
trebuie sa se intample in cazul producerii unei caderi software:
– Degradare treptata
– Continuare dintr-un anumit punct

Tipurile de modele UML adecvate specificarii cerintelor software sunt:

- diagrame de clase si diagrame de obiecte (fac parte din modelul obiect)
- diagrame de interactiune si diagrame de stari (fac parte din modelul
dinamic)
Diagramele de interactiune (de secventa si de colaborare) reprezinta
interactiunile dintre un set de obiecte in timpul unui singur caz de
utilizare(scenariu).
Diagramele de stari reprezinta comportarea in timp a unui obiect dintr-o clasa de
obiecte.

20. Care sunt riscurile unui proiect software? Care sunt riscurile cele mai mari in
cazul utilizarii modelului cascada?
Riscurile unui proiect software:
- factori de experienta:
– a managerului
– a echipei
– a organizatiei
- factori de planificare:
– estimarea resurselor umane
– a perioadelor de timp pentru diferite activitati
– definirea responsabilitatilor
- factori tehnologici:
 – noutatea tehnologica (tehnologii inca nevalidate in practica)
– metodele de dezvoltare
– instrumentele de dezvoltare
- factori externi: (riscurile cele mai mari in cazul utilizarii modelului
cascada)
– calitatea specificatiei cerintelor
– stabilitata cerintelor
– stabilitatea si disponibilitatea altor factori de care depinde proiectul
Modelul cascada nu se recomanda pentru:
• Proiectele in care cerintele sunt vagi, neclare
• Proiectele in care cerintele se pot schimba pe parcursul dezvoltarii
• Proiectele de lunga durata
Este insa adecvat pentru proiectele in care cerintele sunt bine intelese de la inceput
si nu se modifica pe parcursul procesului de dezvoltare

22. (0.25p) Modelul de dezvoltare iterativ si incremental:

a. conduce la un timp de dezvoltare mai lung decat modelul cascada.
b. contine 2 activitati diferite fata de cel cascada(specificati ce activitati)
c. este mai adaptiv decat modelul cascada
d. poate fi aplicat numai pentru proiecte mici sau medii
e. este mai putin expus riscurilor de esec al proiectului, decat modelul cascada.
Cele doua activitati diferite sunt:
- analiza de nivel inalt: are rolul de a defini cerintele de nivel inalt ale
sistemului si de a planifica iteratiile si de a aloca cerintele pe iteratii
- analiza fiecarei iteratii: are rolul de a defini scopurile iteratiei urmatoare

23. Verificare si validare. Ce inseamna fiecare, ce documente se folosesc si ce teste

se folosesc pt fiecare.
Sunt efectuate pe tot parcursul perioadei de specificare a cerintelor
Validarea: activitati de asigurare a calitatii prin care se verifica existenta calitatilor
asteptate de clienti si utilizatori:
- Este produsul in conformitate cu cerintele utilizatorilor/clientului?
- Sunt verificate proprietatile externe ale produsului
- Este implicat clientul
Verificarea: activitati de asigurare a calitatii prin care se verifica proprietatile
specificate ale unui produs software
- Este implementarea produsului in conformitate cu specificatia sa?
- Sunt verificate atat proprietatile interne cat si cele externe ale produsului
- Sunt efectuate de participantii la procesul de dezvoltare
- Toate artefactele procesului de dezvoltare sunt (pot fi) supuse activitatilor de
verificare
24. (1.25) O problema la care iti da un graf de control si trebuie sa ii gasesti setul
de cai de test si date de test pentru fiecare cale. Si mai aveai un subpunct la care iti
cere criteriile de acoperire ale unui graf de control.

Vezi Testarea structurala.pdf din cursul 8.

26. Ce este un design pattern si cum se descrie?

Vezi ex. 12. Sablon de proiectare = design pattern

||| 27. (0.75) Diagrama pentru evidenta persoanelor dintr-o colectivitate..

TODO

||| 28.(0.25) Diagramele de interactiune se folosesc pentru (mai multe raspunsuri

corecte):
a. Reprezentarea interfetei utilizator
b. Modelarea comunicarii dintre obiecte
c. Reprezentarea scenariilor
d. Reprezentarea comunicarii intre componente software

28. (0.5p) Cum este definita densitatea(rata) defectelor, ce reprezinta si pt ce se

foloseste?
Rata/densitatea defectelor reprezinta numarul (estimat) de defecte din produs,
raportat la dimensiunea sa, pentru o perioada de timp.
Este o metrica dinamica de calitate software, deoarece este bazata pe date colectate
in timpul testelor executate pe parcursul tuturor fazelor de testare.
Este utilizata in special pentru sistemele de uz comercial:
• nu exista un profil de utilizare tipic
• companile dezvoltatoare utilizeaza densitatea defectelor pentru estimarea
costurilor si a resurselor necesare mentenantei produsului software
• MTTF poate sa nu fie reprezentativ pentru toti clientii

30. Complexitatea ciclomatica a unei unitati program: definitie, ce indicatii da cu

privire la testarea unui program?
Complexitatea ciclomatica indica numarul de cai liniar independente prin codul
sursa = numarul de cazuri de test pe baza criteriului acoperirii setului de cai de
baza.
Complexitatea ciclomatica a unui program (McCabe, 1982):
v=e-n+2
- e este numarul de arce (edges),
- n este numarul de noduri (nodes) ale grafului de control
Pentru testarea structurata:
- Complexitatea ciclomatica a unui modul program sa fie limitata la 10.
- In timpul proiectarii de detaliu, complexitatea sa fie limitata la 7, deoarece
creste in timpul codificarii.
Este proiectata ca masura a:
- dificultatii de testare,
- usurintei de intelegere si intretinere,
- fiabilitatii unui modul program.