•Planificarea implementarii

•Realizarea si testarea progamelor

•Instalarea sistemului
 Prezentare generală a implementarii

IMPLEMENTAREA SISTEMELOR este procesul de instalare a echipamentelor

şi softului în vederea finalizării sistemului şi dării lui în funcţiune.

Această etapă se derulează în cadrul firmei,

influenţează operaţiunile economice ale acesteia

Necesitatea unei planificări riguroase

 Prezentare generală a implementarii

Planificarea implementării

Pregătirea
Realizarea şi Selectarea şi
locurilor de muncă;
Activităţile testarea instalarea şi testarea
instruirea
personalului
programelor echipamentelor
etapei de
implementare

Finalizarea Testarea
documentaţiei sistemului

Conversia de la
vechiul la noul
sistem
 Planificarea implementarii

In planul de implementare se vor consemna :

• toate activitatile de efectuat

• timpul alocat
• responsabilitatile de executie
• costurile estimate ale fiecarei activitati
• momentul finalizarii implementarii

Planificarea şi controlarea activitatii de implementare sunt realizate prin:

• diagramele Gantt
• diagramele PERT
 Realizarea programelor

Categoriile de programatori

Nr. Număr programatori

crt. Tip programatori Scurtă caracterizare în 1994 în 2010

1 Programatori din Se constată trecerea atribuţiilor 2.000.000 300.000

compartimentele de dinspre compartimentele
informatică ale specializate în informatică spre
organizaţiilor cele ale utilizatorilor.
2 Programatori din Firmele pot fi specializate în 600.000 3.000.000
companii specializate de consultanţă soft sau în realizarea
software produselor-program.
3 Programatori de soft Soft încorporat în produse 3.000.000 10.000.000
încorporat în diverse comune (autoturisme,
produse echipamente de uz casnic ş.a.)
4 Programatorii de ocazie Persoanele ce îşi desfăşoară 20.000.000 100.000.000
activitatea ca specialişti în
diferite domenii (contabili,
manageri ş.a.).
 Testarea sistemelor
Verificare vs Validare

Obiectivul general al testării îl reprezintă identificarea numărului maxim de

erori cu efort minim
Testarea sistemelor face referire la două activităţi:
• Verificarea – The process of evaluating work-products (not the actual final
product) of a development phase to determine whether they meet the specified
requirements for that phase.
 The objective is to ensure that the product is being built according to the
requirements and design specifications. In other words, to ensure that work
products meet their specified requirements.
 Are we building the system right?
• Validarea – determină dacă au fost implementate toate cerinţele sistemului
 Are we building the right system?
 Testarea sistemelor
Verificare vs Validare

Testarea sistemelor face referire la două activităţi:

• Validation – The process of evaluating software during or at the end of the
development process to determine whether it satisfies specified business
requirements.
 The objective is to ensure that the product actually meets the user’s needs
and that the specifications were correct in the first place. In other words, to
demonstrate that the product fulfills its intended use when placed in its
intended environment.
 Are we building the right system?

sursa: http://softwaretestingfundamentals.com/verification-vs-validation/
 Testarea sistemelor
V&V techniques

•https://www.easterbrook.ca/steve/2010/11/the-difference-between-verification-and-validation/
 Testarea sistemelor
Activităţile etapei de testare

•subset al
•datelor de •Stabilirea
Stabilirea •rezultatele
•intrare •rezultatelor
rezultatelor •a•s•teptate

•PP •Strategia
Strategia Compararea •Rezultatele •Documentatia
•Compararea Documenta••tia
•testarii
testarii •rezultatelor
rezultatelor •testarii •testarii
testarii

•subset al •PP •rezultatele

•datelor de •ob••t inute
•intrare
 Testarea sistemelor
Principiile generale ale testării

1. Testele trebuie concepute astfel încât să urmărească respectarea cerinţelor

utilizatorilor

2. Testele trebuie planificate cu mult timp înainte de începerea activităţii de testare

3. Testarea trebuie să înceapă cu detaliile şi se finalizează la nivelul sistemului

4. Testarea exhaustivă nu este posibilă

5. Testarea trebuie să fie realizată de persoane care nu au fost implicate în fazele

anterioare de dezvoltare a sistemului

6. Testarea nu vizează numai produsul final, ci şi rezultatele fazelor intermediare

ale dezvoltării sistemului informatic
 Testarea sistemelor
Clasificarea tehnicilor de testare

1. După modul de efectuare a testării:

 Tehnici de testare automată – testarea sub controlul calculatorului
 Tehnici de testare manuală - testarea sub controlul omului

2. În funcţie de execuţia sau nu a programelor pe parcursul testării:

 Tehnici de testare statică – nu implică execuţia programelor
 Tehnici de testare dinamică – implică execuţia programelor

3. În funcţie de sursele de informaţii utilizate pentru generarea cazurilor de test:

 Testarea de tip “cutia neagră” – ia în considerare funcţiile componentei
testate
 Testarea de tip “cutia albă” – ia în considerare detaliile procedurale ale
componentei testate
 Testarea sistemelor
Testarea tip “cutia albă”

Avantaje:

 Identificarea erorilor ce pot rezulta în urma proiectării şi implementării

cazurilor de excepţie în tratarea unei funcţii a programului

 Identificarea şi localizarea mai uşoară a erorilor, motiv pentru care este

recomandată începerea testării cu aceste tehnici

Se urmăreşte generarea cazurilor de test astfel încât să fie garantată:

 execuţia fiecărei structuri de control alternative pe ambele ramuri;

 execuţia fiecărei structuri de control repetitive, atât la numărul minim, cât şi cel
maxim al iteraţiilor, dar şi al unuia intermediar;

 verificarea structurilor de date interne ale programelor

 Testarea sistemelor
Testarea tip “cutia neagră”

Răspunde la întrebările:

Cum poate fi testată validitatea funcţională a aplicaţiei?

Cum pot fi testate performanţele aplicaţiei?

Ce volum de date şi ce rată a intrărilor poate accepta sistemul?

Ce efect va avea asupra modului de funcţionare a sistemului o anumită

combinaţie a datelor de intrare?

Se bazează pe diagramele fluxurilor de date

 Tehnica testării căilor independente de execuţie
(Basic Path Testing)
Obiectivul urmărit: garantarea execuţiei cel puţin o dată a fiecărei linii de cod.

Calea urmată:

Determinarea Definirea setului de

complexitatii bază al căilor inde- Definirea cazurilor
logice pendente de execuţie de test

Etapele de lucru:
1. Construirea grafului fluxurilor logice de control din program,
2. Determinarea complexităţii logice a specificaţiilor procedurale,
3. Determinarea setului de bază al căilor liniare independente de execuţie,
4. Pregătirea cazurilor de test.
 Tehnica testării căilor independente de execuţie
Concepte utilizate
Un nod reprezentă un grup de instrucţiuni secvenţiale şi/sau o instrucţiune care
codifică o structură de control alternativă sau repetitivă

Reprezentări utilizate în construirea grafului fluxurilor logice de control din program:

Secvenţa If – then - else Do case Do-while

...

..
.

Nod predicativ – conţine o expresie logica simplă sau complexă

- pornesc două sau mai multe fluxuri de control (vezi nodurile de
culoare mai închisă)
 Tehnica testării căilor independente de execuţie
Concepte utilizate (continuare)

Complexitatea logică – defineşte numărul căilor independente de execuţie

- se calculează după formula:
CC = P + 1, unde P este numărul nodurilor predicative

Cale independentă de execuţie – orice cale prin program care implică cel puţin un
grup nou de instrucţiuni sau o condiţie nouă faţă de cele definite deja
 Tehnica testării căilor independente de execuţie
Exemplu
PROCEDURE EvaluareFIFO
* Acest modul realizeaza evaluarea stocurilor la iesire dupa metoda „First In – First
Out”
INTERFACE INPUT cMatCod, vCantitate
INTERFACE OUTPUT aConsum, bConsValid
vCantConsum = 0
SELECT DataIntrare,Stoc,Pret FROM Stoc INTO ARRAY aStocuri ;
1 WHERE MatCod = cMatCod and Stoc > 0 ORDER BY DataIntrare
n = ALEN(aStocuri,’ROW’)
DIMENSION aConsum(n,3) 2 1
i=1 3
DO WHILE i <= n AND vCantConsum < vCantitate
IF vCantitate – vCantConsum >= aStocuri(i,2)
4 INCREMENT vCantConsum BY aStocuri(i,2) 2
5 aConsum(i,1) = aStocuri(i,1)
aConsum(i,2) = aStocuri(i,2) 3
aConsum(i,3) = aStocuri(i,3)
ELSE 9
6 aConsum(i,1) = aStocuri(i,1)
aConsum(i,2) = vCantitate – vCantConsum 4
aConsum(i,3) = aStocuri(i,3) 10 11
7 vCantConsum = vCantitate
END IF 5 6
8 INCREMENT i BY 1 12
END DO 9
7
IF vCantConsum < vCantitate
10 bConsValid = FALSE
11 DISPLAY_MESSAGE(„Stocul este insuficient”)
ELSE 8
bConsValid = TRUE
12 ENDIF
END
 Tehnica testării căilor independente de execuţie
Exemplu (continuare)

Complexitatea ciclomatică este 5 (4 + 1)

1

2
Căile independente de execuţie sunt:
Calea 1:1-2-9-10-12
3
Calea 2:1-2-9-11-12
9
4 Calea 3:1-2-3-9-10-12
10 11
Calea 4:1-2-3-4-5-7-8-2-.....
5 6
12 Calea 5:1-2-3-4-6-7-8-2-.....
7

Datele de test pentru calea 4 sunt:

8
• valoarea lui cMatCod – “100001”
• valoarea pentru vCantitate – 100
• Pentru materialul “100001” în tabela Stocuri există
3 linii cu valorile 50,65 şi 40 pentru atributul Stoc.
 Testarea structurilor de control repetitive
Sunt luate în considerare trei tipuri de structuri repetitive:
Structuri repetitive Structuri repetitive imbricate
simple
Condiţii de testare Condiţii de testare
• se porneşte cu structura din interior
Se generează cazuri de şi configurarea celorlalte la numărul
test pentru 0, 1, 2, m, minim de iteraţii
n-1, n şi n+1 iteraţii • se continuă cu celelalte structuri în
aceeaşi manieră, doar că structurile
situate dedesubt sunt configurate la
valorile tipice
Structuri repetitive concatenate
Condiţii de testare
• ca în cazul structurilor
simple dacă structurile
concatenate sunt
independente
• ca în cazul structurilor
imbricate daca ele sunt
dependente
 Alte tehnici de testare - Examinările

 examinările presupun evaluarea programelor linie cu linie în vederea

depistării manuale a unor erori frecvent întâlnite, fără a se urmări efectul
fiecărei instrucţiuni
examinatorii interpretează liniile de program, iar pe baza comentariilor
şi întrebărilor formulate se vor descoperi eventualele greşeli

 se porneşte de la o listă de control cu erorile tipice întâlnite în

activităţile de proiectare şi programare
 Alte tehnici de testare – Examinările (continuare)

Exemple de erori:

 Utilizarea greşită a structurilor de date - referirea unor variabile neiniţializate

sau chiar nedeclarate

 Erori în expresiile de calcul - împărţirea la 0, utilizarea unor variabile de tipuri

diferite în aceeaşi expresie fără a se apela la funcţiile de conversie

 Erori legate de fluxul logic de control - structuri de control repetitive infinite,

blocuri de instrucţiuni ce nu vor putea fi executate niciodată

 Erori la nivelul interfeţelor - utilizarea unui număr incorect de parametri sau a

unor parametri al căror tip nu este corespunzător
 Alte tehnici de testare – Examinările (continuare)

O echipă de examinare este formată din patru membri:

 moderatorul este responsabil pentru organizarea şi conducerea şedinţelor de

lucru

 doi inspectori (examinatori) care vor interpreta programul sursă.

 programatorul, respectiv cel ce a scris codul, pentru a explica ce a

intenţionat să facă atunci când examinatorii consideră că ceva este greşit
 Alte tehnici de testare – Execuţia de probă

 presupune analiza programelor prin urmărirea efectului

fiecărei instrucţiuni pe baza unor date de test

 datele de test alese sunt simple, astfel încât să nu facă

dificilă urmărirea programului. Ele vor servi mai mult drept
punct de pornire a discuţiilor
 Strategia testării sistemelor informaţionale

 presupune definirea unui cadru de desfăşurare a fazei de testare, ca parte a

demersului dezvoltării sistemelor informatice

 Caracteristicile generale ale strategiei de testare

 Testarea începe de jos, de la nivelul modulelor, continuă cu testarea integrării

modulelor şi se încheie prin validarea sistemului informatic ca un tot

 Diferitele tehnici de testare trebuie aplicate în anumite momente ale testării.

Dacă la testarea modulelor se utilizează cu precădere tehnicile tip „cutia albă”,
în timpul testării integrării vor fi utilizate mai mult tehnicile tip „cutia neagră”

 Testarea este realizată de către o echipă independentă, în cazul proiectelor

mari sau de membrii echipei de dezvoltare a sistemului, în cazul proiectelor de
mai mică amploare
 Strategia testării sistemelor informaţionale
Testarea modulelor

Prin testarea modulelor se urmăreşte:

• testarea la nivelul interfeţelor modulului, pentru a se asigura că intrările şi

ieşirile în/din modul sunt corecte

• testarea structurilor de date locale, prin care se verifică integritatea datelor

memorate temporar de-a lungul ramurilor de execuţie din modulul respectiv.

• testarea căilor de execuţie urmăreşte depistarea erorilor legate de calcule

greşite, comparaţii greşite în expresiile logice, controlul logic necorespunzător al
execuţiei etc

• analiza valorilor limită pentru identificarea erorilor care apar la extremităţile

domeniului de valori pentru datele de intrare şi nu în mijlocul acestui domeniu
 Strategia testării sistemelor informaţionale
Testarea integrării modulelor
Erori ce pot apare la integrarea modulelor:
 pierderea unor date în cazul transmiterii lor de la un modul la altul
 execuţia unui modul poate avea efecte negative asupra altui modul
 utilizarea greşită a structurilor de date globale

Testarea integrării se poate realiza:

 de sus în jos (top-down) - începe cu modulul principal, după care se continuă,
prin parcurgerea în jos a structurii ierarhice a programului , în două modalităţi
posibile:
integrarea orientată pe verticală
integrarea orientată pe orizontală
 de jos în sus (bottom-up) - construirea şi testarea treptată a programului,
începând cu modulele de pe ultimele niveluri ierarhice
 Strategia testării sistemelor informaţionale
Testarea la nivelul sistemului

Testele concepute în această fază urmăresc:

 Testarea refacerii - se verifică dacă refacerea este realizată corespunzător
 Testarea securităţii - se verifică dacă mecanismele de protecţie ale sistemului
funcţionează corespunzător
 Testarea solicitării sistemului presupune confruntarea sistemului cu situaţii
anormale, testele anterioare vizând modul de funcţionare a programelor în
condiţii normale de lucru
 Testarea performanţelor sistemului este adesea combinată cu testarea solicitării
sistemului şi ia în considerare performanţele tehnice ale hardware-ului şi
software-ului.
 Strategia testării sistemelor informaţionale
Testarea de acceptare

Caracteristici:
reprezintă ultima ocazie de verificare a sistemului
se desfăşoară într-un mediu similar celui în care va fi pus în funcţiune şi de către
persoanele care îl vor utiliza
este realizată din perspectiva utilizatorului

Este efectuată în două etape:

Testarea alfa este realizată de client la sediul producătorului
Testarea beta se desfăşoară la sediul clientului, fără ca utilizatorii să fie
supravegheaţi de membrii echipei de dezvoltare a sistemului
 Documentarea sistemului
Componentele documentatiei utilizatorului :
1. Prezentarea generală a sistemului:
scopul sistemului;
•

prezentarea sumară, sub formă narativă şi grafică, a intrărilor, prelucrărilor

•

şi ieşirilor.
2. Procedurile generale
accesarea sistemului şi părăsirea lui;
•

instrucţiuni de operare (tastele funcţionale, combinaţiile de taste, utilizarea

•

mouse-ului, secvenţa comenzilor pentru executarea anumitei funcţii);

proceduri pentru încărcarea şi execuţia programelor;
•

lista controalelor şi descrierea lor;

•

explicaţii privind mesajele de eroare comune şi modul lor de corectare;

•

persoana de contact pentru eventualele probleme apărute în sistem.

•
 Documentarea sistemului
Componentele documentatiei utilizatorului:
(continuare)
3. Documentaţia procedurilor:
a) Prezentarea generală a fiecărei proceduri:
• descrierea sumară;
• diagrama fluxurilor de date.
b) Descrierea detaliată a fiecărei proceduri:
• descrierea narativă şi grafică a procedurii (de exemplu, paşii care ar
trebui urmaţi pentru introducerea datelor de pe o comandă primită de la
un client nou);
• descrierea fluxului de activităţi;
• modele de ecrane şi explicarea opţiunilor ce apar pe fiecare ecran (de
exemplu, adăugarea, ştergerea, modificarea unui document);
• descrierea sursei documentelor şi instrucţiunile de introducere a datelor
de intrare;
• descrierea ieşirilor şi prezentarea unui model al fiecărei ieşiri, cu
explicaţii şi instrucţiuni privind modul de obţinere şi distribuire a fiecărei
ieşiri.
 Documentarea sistemului
Componentele documentatiei utilizatorului:
(continuare)
c) Definirea datelor:
• descrierea datelor utilizate de fiecare procedură;
• proprietatea şi responsabilitatea asupra datelor;
• explicaţii privind securitatea accesului la date.
d) Interfeţele cu proceduri sau sisteme
• datele primite de alte proceduri sau grupuri de utilizatori
• informaţiile ce trebuie oferite altor proceduri sau grupuri de
utilizatori.
4. Glosarul de termeni
5. Indexul
 Conversia sistemului
Conversia - procesul de trecere de la vechiul la noul sistem

Tipuri de conversie:
 directă (arderea podului) - renunţarea, la un moment dat, la vechiul
sistem şi trecerea la cel nou
 paralelă - funcţionarea paralelă a celor două sisteme o perioadă de timp
 pe faze (graduală) - înlocuirea treptată a elementelor sistemului,
evitându-se schimbările drastice, instalându-se câte un subsistem pe rând
 modulară (pilot) - implementarea sistemului în unele componente din
unitate
 Conversia sistemului

Conversia fişierelor sau a bazelor de date constă în patru activităţi principale:

 pregătirea datelor pentru conversie;
 conversia datelor;
 verificarea corectitudinii noilor date;
 documentaţia şi efectuarea copiilor de siguranţă.