Cursul 11 29 Aprilie

adiftene@infoiasi.ro
Din Cursurile trecute
Manual Testing
Test Automation
Software Bug
Testing cycle
Calitatea programelor
Metrici
Copyright
Examen






2
How, Who, When, Where, Results

3
Test Automation: How, Who, When, Results

4
Software Bug: Prevention, Life Cycle

5

6
Testing Cycle: Persons involved, Tasks

7
Realizai scenarii de test pentru nregistrarea
utilizatorilor
UserID, Password, ConfirmPassword







Test, Regression, Acceptance
Testare automat


8
Cum msurm calitatea unui lucru?
Calitatea construciei (ct de bine este lucrat, dac
exist defecte n materialul din care este fabricat ...)
Calitatea designului (elegan, confort ...)
O combinaie ntre calitile construciei i ale
designului (rezistena...)

n general putem spune c un scaun A este mai
bun dect un scaun B sub un anumit aspect al
calitii, dar de obicei este greu de precizat cu
ct este mai bun.

9
Nu se examineaz calitatea construciei (=>
unicitate ntre toate disciplinele inginereti)

Toate atributele calitii se refer la design.

Dac ne referim la valori estetice:
Programele sunt n mare parte invizibile, iar valorile
estetice conteaz doar pentru prile vizibile
n afar de interfa, singurele aspecte observabile la
un program sunt:
Notaiile folosite pentru design i scrierea codului
Comportamentul programului atunci cnd
interacioneaz cu alte entiti.

10
Atunci cnd vorbim despre calitatea unui
program trebuie:
S definim atribute ale calitii care ne intereseaz;
S cutm modaliti de msurare a lor;
S putem da o reprezentare a designului;
S scriem specificaii care s ghideze programatorii
(calitile designului s fie respectate i de
implementare).

11
Codul care implementeaz un design este o
reprezentare a acelui design.
Asigurarea calitii fcut dup scrierea codului
este un proces costisitor i e posibil s fie inutil.
De regul doar se ine cont de modul n care e
scris codul (coding style, design patterns,
adaptability, maintenance, reuse (cuplaj,
coeziune), security)

12
Msoar ct de bine se potriveste un program
mediului su.

Ia n calcul aspecte de tipul:
Programul funcioneaz;
Programul face ceea ce trebuie s fac;
Programul este sigur;
Programul poate fi adaptat pe msur ce nevoile se
schimb.

Toate msurile referitoare la calitate sunt
relative!!!
13
Siguran (safety)

Eficien (efficiency)

ntreinere (maintenance)

Uzabilitate (usability)

14
Este programul complet, consistent i robust?
completitudine trateaz toate intrrile
posibile;

consisten se comport ntotdeauna aa
cum este ateptat;

robustee se comport bine n situaii
anormale (ex. lipsa resurselor, lipsa
conexiunii, etc.)

15
Programul utilizeaz ntr-un mod eficient resursele?
(procesor, memorie, reea...)
Eficiena este ntotdeauna mai puin important dect
sigurana: Este mai uor s facem un program sigur s
fie eficient dect un program eficient s fie sigur

16
Ct de uor poate fi modificat design-ul
ulterior?

Tipuri de ntreinere:
Corectiv: eliminarea erorilor;
Perfectiv: adugarea de funcionaliti care
ar fi trebuit s fie oferite;
Adaptiv: actualizarea programului cnd se
schimb cerinele.
17
Ct de usor este programul de nvat i de
folosit?

18
Simplitate



Modularitate

19
Este msura invers a complexitii.

Aspecte ale complexitii:
Complexitatea fluxului de control: numr
cile posibile de execuie ale unui program
Complexitatea fluxului de informaii: numr
datele care sunt transmise n program
Complexitatea nelegerii: numr
identificatorii i operatorii folosii

20
Poate fi msurat uitndu-ne la:
Coeziune: ct de bine lucreaz mpreun
componentele unui modul.
Cuplaj: gradul de interaciune ntre module.

21
Efectum msurtori pentru
a nelege
a controla
a prevedea

Cnd poi s msori lucrul despre care vorbesti
i s exprimi aceasta n numere, atunci tii ceva
despre acel lucru. Dar cnd nu poi s l msori,
cnd nu poi s l exprimi n numere,
cunostinele tale sunt slabe i nesatisfctoare;
ele pot fi nceputul cunoasterii, dar mai nimic nu
este nc fcut pentru a ajunge la stadiul de
tiin. (Lord Kelvin)

22
Dimensiunea unui program
Complexitatea unui program
Fiabilitatea unui program
Timpul necesar dezvoltrii unui program
Alocarea resurselor necesare dezvoltrii
unui program
Productivitatea muncii
Costurile de dezvoltare

23
KLOC: Kilo Lines Of Code (mii linii de cod)

Effort, PM: Person Month (Om lun).

24
COnstructive COst MOdel (Boehm 1981)
Folosit pentru evaluarea costurilor
Trei nivele de rafinare a prediciilor:
COCOMO de baz
COCOMO intermediar
COCOMO detaliat

25
Formula pentru efortul necesar dezvoltrii n
funcie de numrul de linii de cod

Effort Applied = a
b
(KLOC)
bb
[ man-months ]
Development Time = c
b
(Effort Applied)
db

[months]
People required = Effort Applied / Development
Time [count]

a
b
, b
b
, c
b
, d
b
- constante ce depind de tipul
proiectului
26
Propus de Boehm n 1995

Ia n calcul tehnicile moderne de dezvoltare
aprute
Prototipizare
Dezvoltarea pe componente
4GL (fourth generation language)

Ofer posibilitatea de a face estimri nc din
primele faze ale dezvoltrii

27
Surprinde efortul necesar realizrii unui prototip
al aplicaiei
Se bazeaz pe numrul de puncte obiect (NOP)
Formula de calcul a efortului:



28
Se inventariaz ecranele ce trebuie afiate
Simple: 1
Complexe: 2
Foarte complexe: 3
Se inventariaz rapoartele ce trebuie generate
Simple: 2
Complexe: 5
Foarte complexe: 8
Fiecare modul n limbaj de nivel mai jos (ex.
3GL): 10
Suma punctelor obinute reprezint numrul
total de puncte obiect ale programului.

29
Se estimeaz numrul total de linii de cod
(ESLOC)
Factori luai n calcul
Volatilitatea cerinelor
Gradul posibilitii de reutilizare a codului

30
Atributele produsului
Sigurana produsului; Complexitatea modulelor
sistemului; Dimensiunea documentaiei cerute;
Dimensiunile bazei de date utilizate; Procentajul
cerut de componente reutilizabile

Atributele sistemului de calcul
Constrngeri privind timpul de execuie; Volatilitatea
platformei pe care se face dezvoltarea; Constrngeri
de memorie
31
Atributele personalului
Capacitatea analitilor; Capacitatea programatorilor;
Continuitatea personalului; Experiena analistului n
domeniul problemei; Experiena programatorilor n
domeniul problemei; Experiena n limbajele i
instrumentele folosite

Atributele proiectului
Utilizarea intrumentelor; Gradul de lucru n echipe
aflate la distan i calitatea comunicrii ntre echipe;
Comprimarea planului de dezvoltare

32
20 om-lun. E corect calculul de mai jos???
20 oameni muncesc 1 luna
4 oameni muncesc 5 luni
1 om muncete 20 luni
Productivitatea individual scade atunci cnd
echipa de dezvoltare crete
Comunicare suplimentar
La adugarea de noi membri, productivitatea iniial
scade
Creterea numeric a forei de munc la un
proiect rmas n urm are ca efect rmnerea i
mai n urm a proiectului. (Legea lui Brooks)

33
Pentru o echip cu P persoane putem avea ntre
P-1 i P(P-1)/2 canale de comunicaie

Fiecare canal induce o pierdere de eficien






34
Avem 12 luni s terminm treaba, deci treaba va
dura 12 luni. Legea lui Parkinson: munca se
ntinde pe timpul avut la dispoziie.

tim c competitorul a cerut $1.000.000. Noi
cerem $900.000.

tim c bugetul clientului pentru produs este de
$500.000. Att ne cost i pe noi dezvoltarea.

Programul va dura 1 an, dar voi spune c va
dura 10 luni. Ce-o s mai conteze 2 luni peste
planificare...
35
Lipsa de acuratee
Rezistena din partea angajailor
Folosirea lor n alte scopuri dect au fost create
Disensiuni n cadrul echipei de dezvoltare

36
Drepturile de autor reprezint ansamblul
prerogativelor de care se bucur autorii cu
referire la operele create; instituia dreptului de
autor este instrumentul de protecie a
creatorilor i operelor lor
Copyright gives the creator of an original work
exclusive right for a certain time period in
relation to that work, including its publication,
distribution and adaptation; after which time the
work is said to enter the public domain.
37
Several exclusive rights typically attach to the
holder of a copyright:
to produce copies or reproductions of the work and to
sell those copies (mechanical rights; including,
sometimes, electronic copies: distribution rights)
to create derivative works (works that adapt the
original work)
to perform or display the work publicly (performance
rights)
to sell or assign these rights to others
to transmit or display by radio or video (broadcasting
rights)

38
eful de grupa prezint ce a lucrat fiecare
membru al grupei (clase i module implementate,
resurse, documentaie, etc.). Evaluare proiect
integrat:
- 70-80 de puncte sub-modul funcional testat i
mbuntit
- 60-70 de puncte sub-modul aproape funcional
- 50-60 de puncte nite rezultate
- 0 puncte fr integrare
Cei care nu implementeaz nimic i ncurc
celelalte subgrupe n realizarea proiectului,
primesc punctaj negativ
39
Tematici: IP, logic, cunotine generale, etc.

20 - 30 de subiecte 30 de minute

Rspunsurile scurte la obiect, cuvinte cheie

Atenie! Vor fi subiecte a cror nerezolvare va
duce la acumularea unui punctaj negativ! Aceste
subiecte vor fi marcate pe tez cu punctajul sub
forma [-10, 10] (lucrurile de baz)

Data: 20 (21) Mai
40
O scurt prezentare a elementelor de TAIP

Prezentri de proiecte grupele mai avansate
4-5 slide-uri: nume proiect, descriere proiect,
diagrame UML, design patterns (4-5 minute)
Demo proiect (10-15 minute cu tot cu Q&A)
Prezentatorii (pentru prezentare) i audiena (pentru
ntrebri) vor primi bonusuri

41
Bug Life Cycle: http://www.buzzle.com/editorials/4-
6-2005-68177.asp,
http://qastation.wordpress.com/2008/06/13/process
-for-bug-life-cycle/
COCOMO: http://en.wikipedia.org/wiki/COCOMO
Curs 12, Ovidiu si Adriana Gheorghies:
http://www.infoiasi.ro/~ogh/files/ip/curs-12.pdf








42