IPE Curs12continuare

Informatizarea Proceselor
Energetice
Curs 12-continuare
Capitolul 8. Metodologii de realizare a sistemelor

informatice
Prof.dr.ing. Ioana FAGARASAN

Capitolul 8. Metodologii de realizare a sistemelor informatice
8.1. Concepte utilizate în realizarea sistemelor informatice
8.2. Definirea şi conţinutul metodologiilor
8.3. Clasificarea metodologiilor de realizare a sistemelor informatice:
• Metodologii structurate:
• SSADM (Structured System Analysis and Design Methodology),
• MERISE (Méthode d’Etude et de Realization, Informatique pour les Systèmes d’Entreprise)
• Metodologii orientate obiect
• OMT (Object Modeling Technique),
• Proces iterativ de dezvoltare a sistemelor informatice utilizând UML
• Metodologia unificată de realizare a sistemelor informatice (RUP - Rational Unified Process )
• Metodologii bazate pe dezvoltarea rapidă
• Metodologii bazate pe dezvoltarea agilă
8.4. Structured Analysis and Design Information Systems (STRADIS)
8.5. Jackson System Development (JSD)
8.6. Structured System Analysis and Design Methodology (SSADM)
8.7. Metodologia MERISE - Méthode d’Etude et de Realization, Informatique pour les Systèmes
d’Entreprise
8.8. Metodologia Object Modeling Technique (OMT)
2
8.9. Metodologii bazate pe dezvoltarea rapidă
RAD (Rapid Application Development)
• Se referă la o serie de principii care urmăresc ajustarea etapelor de realizare a

sistemelor informatice, astfel încât o parte a sistemului să fie dezvoltată și să
ajungă la utilizatori rapid.
• Astfel, utilizatorii pot înțelege mai bine sistemul și pot sugera revizuiri care aduc
sistemul mai aproape de cerinţele acestuia.
• Se recomandă ca analiștii să folosească tehnici speciale și instrumente informatice
pentru a accelera etapele de analiză, proiectare și implementare, cum ar fi:
 instrumente CASE (Computer-Aided Software Engineering) utilizate in
ingineria ciclurilor de dezvoltare si evolutie a aplicatiilor informatice
 sesiuni comune pentru stabilirea cerinţelor Join Requirement Planning (JRP)
 limbaje de programare vizuale
 generatoare de cod
 reutilizarea componentelor software
 Astăzi, aproape toate mediile de dezvoltare integrate au facilităţi specifice
RAD
3
8.9. Metodologii bazate pe dezvoltarea rapidă
RAD (Rapid Application Development)
 RAD comprimă paşii metodologiilor tradiţionale într-un proces iterativ.
 Se bazează pe prototipizare şi pe revizuiri ale utilizatorilor înainte de a trece la
parcurgerea unei noi iteraţii
Metodologii de realizare clasice

Elaborarea
tema de Concepere Proiectare Implementare Testare Utilizare
realizare
RAD
Documentarea
Proiectare
cerinţelor
Proces
stabilirea cerinţelor Iterativ Implementare
Revizuiri ale
utilizatorilor Testare 4
8.10. Metodologii bazate pe dezvoltarea agilă
 Aceste metodologii sunt orientate pe programare şi au puține reguli

bine definite
 Implică descoperirea cerințelor și dezvoltarea de soluții prin efortul
colaborativ al echipelor de auto-organizare și multi-funcționalitate
precum si implicarea activa a clienților/utilizatorilor finali.
 Propune o planificarea adaptativă, o dezvoltarea evolutivă, livrarea
timpurie si îmbunătățire continuă. Totodata încurajează actiuni
flexibile la schimbare
5
 Aceste metodologii sunt orientate pe programare şi au puține reguli bine

definite
 Sunt bazate pe un set de douăsprezece principii:
1. Este prioritară satisfacţia clientului prin livrarea rapidă şi continuă de software
calitativ.
2. Schimbarea cerinţelor este binevenită chiar şi într-o fază avansată a dezvoltării.
Procesele agile valorifică schimbarea în avantajul competitiv al clientului.
3. Livrarea de software funcţional se face frecvent, de preferinţă la intervale de timp
cât mai mici, de la câteva săptămâni la câteva luni.
4. Clientul/ utilizatorul şi dezvoltatorii trebuie să colaboreze zilnic pe parcursul
proiectului.
5. Proiecte se construiresc în jurul oamenilor și nevoilor acestora. Oferindu-le mediul
propice şi suportul necesar este foarte probabil că obiectivele vor fi atinse.
6
 Sunt bazate pe un set de douăsprezece principii:

6. Cea mai eficientă metodă de a transmite informaţii înspre şi în interiorul echipei
de dezvoltare este comunicarea faţă în faţă.
7. Software-ul funcţional este principala măsură a progresului proiectului
8. Procesele agile promovează dezvoltarea durabilă. Beneficiarii, dezvoltatorii şi
utilizatorii trebuie să poată menţine un ritm de lucru constant pe termen lung.
9. Atenţia continuă pentru excelenţă tehnică şi concepere si proiectare de calitate
îmbunătăţeşte agilitatea produsului final.
10. Simplitatea este esenţială.
11. Cele mai bune arhitecturi, cerinţe şi design sunt create de echipe care se auto-
organizează.
12. La intervale regulate, echipa analizează cum să devină mai eficientă, apoi se
adaptează şi ajustează comportamentul în consecinţă.
7
 Pe baza acestor principii, metodologiile agile se concentrează pe optimizarea procesului

de dezvoltare a sistemelor prin eliminarea unei părți semnificative din documentare și
modelare.
 Este susținută realizarea simplă, iterativă a sistemelor. Practic toate metodologiile agile
sunt folosite în combinație cu tehnologiile orientate-obiect.
 Toate metodologiile bazate pe dezvoltarea agilă urmează un ciclu de dezvoltare simplu
prin parcurgerea etapelor tradiționale ale procesului de dezvoltare a sistemelor.
 Două dintre cele mai populare exemple de metodologii de dezvoltare agile sunt Extreme
Programming (XP) și Scrum.
Planificare Planificare Planificare
Analiză Analiză Analiză
Proiectare Proiectare Proiectare
Implementare Implementare Implementare
Iteraţia 1 Iteraţia 2 Iteraţia 3...
Sistem
Sistem
Sistem
8
Avantaje Dezavantaje
Abordare realistă în realizarea sistemelor Nu sunt potrivite pentru a gestiona dependenţe

informatice. complexe.
Promovează lucrul în echipă şi învăţarea. Risc crescut de sustenabilitate, mentenabilitate
și extensibilitate.
Funcţionalităţile pot fi implementate rapid şi Fără o documentație suficientă, nici sistemul şi
verificate. nici procesul de dezvoltare al sistemelor nu pot
fi auditate.
Model potrivit pentru mediile care se schimbă în Depinde foarte mult de interacţiunea cu
mod continuu. beneficiarul.
Reguli minime, documentaţie uşor de realizat. Transferul de informaţii către membrii noi ai
echipei este îngreunat de lipsa documentaţiei.
Uşor de gestionat. Lipsa regulilor poate duce la apariţia unui mediu
de lucru haotic.
Oferă flexibilitate. Dependenţa de membrii echipei care cunosc
cerinţele sistemului.
9
Extreme Programming - XP
• Pune accentul pe implementare/cod (standarde, principii) - utilizează un set comun de nume,

descrieri și practici de codificare.
• Susţine ca programatorii să lucreze in echipe de câte doi (“pair programming”), cu
responsabilitate comună pentru fiecare componentă software elaborată.
• Numeroase sesiuni de discuţii pe parcursul dezvoltării.
• Feedback rapid al utilizatorilor finali în mod continuu.
• Dezvoltatorii trebuie să aibă o mentalitate orientată către calitate.
• Se bazează foarte mult pe refactoring, care este un mod disciplinat de restructurare a
codului pentru a-l păstra simplu.
• Sistemul este dezvoltat într-un mod evolutiv și incremental.
• Fiecare iteraţie (1-4 săptămâni) are un rezultat funcţional.
• Suport redus pentru modelare.
• Relaţie strânsă între clienţi şi dezvoltatori.
• Lipsa documentaţiei de realizare.
10
Extreme Programming - XP
Când se recomandă: Când NU se recomandă:
• Pentru proiectele mici cu echipe • În cazul proiectelor mari sau echipele care nu sunt unite,
extrem de motivate, unite, stabile, și un efort de dezvoltare XP este nerecomadat.
cu experiență, XP ar trebui să • Există dubii asupra beneficiilor introducerii unor
funcționeze foarte bine. contractori externi în cadrul unei echipe existente, când
• XP este recomandat numai pentru se lucrează conform XP.
grupuri mici de dezvoltatori, nu mai • XP necesită un grad ridicat de disciplină; în caz contrar
mult de zece persoane. proiectele vor deveni nefocalizate și haotice.
• Pentru cicluri scurte de dezvoltare • Nu se recomandă pentru aplicații mari. Din cauza lipsei
şi atunci când sunt facilitate de analiză și documentației de proiectare, există doar
discuţiile frecvente cu utilizatorii documentație cod asociat cu XP, deci mentenanta
finali. sistemelor de mari dimensiuni construite cu XP poate fi
imposibilă
11
SCRUM
 Numele metodologiei este preluat din jocul de rugby, şi desemnează o grămadă

ordonată folosită pentru a reporni un joc
 Creatorii metodei Scrum cred că indiferent cât bine este realizată planificarea
dezvoltării unui sistem, de îndată ce software-ul începe să fie dezvoltat va izbucni
haosul și planurile nu vor mai avea utilitate
Principii de organizare
 Echipele sunt auto-organizate și auto-dirijate.
 Spre deosebire de alte abordări, echipele Scrum nu au un lider de echipă desemnat.
 Echipele se organizeze într-o manieră simbiotică și își stabileasc propriile obiective

pentru fiecare sprint (iterație).
12
SCRUM
 Principii de funcţionare
• Odată ce o iteratie a început, echipele Scrum nu mai iau în considerare nici o
cerință suplimentară.
• Orice cerințe noi care sunt descoperite sunt plasate într-o listă de cerințe care
urmează să fie abordate.
• La începutul fiecărui zile de lucru, are loc o reuniune unde toți membrii echipei
pentru raportarea realizărilor zilei precedente, stabilesc planul de lucru zilnic și
descriu toate blocajele din ziua precedentă.
• Pentru a asigura un progres continuu, orice blocaj identificat este abordat cu
prioritate.
• La sfârșitul fiecărei iteratii, echipa prezintă software-ul clientului.
• Pe baza rezultatelor iterației încheiate, este început un nou plan pentru
următoarea iterație.
13
Energetice
Curs 13
Capitolul 9. Testarea, verificarea si validarea produselor

Capitolul 9. Testarea, verificarea si validarea produselor
 Efectuate pe tot parcursul ciclului de viata

 Scopul: de a reduce erorile la un nivel acceptabil
 Cauza/sursa erorilor:
Cele mai multe sunt cauzate de deficiente in specificatii
Urmeaza cele rezultate in urma erorilor de proiectare
Relativ putine (sub 15%) sunt erori directe de programere
 Efortul necesar: 30-90% din efortul total al proiectului, in functie de
complexitatea si gradul de risc al functionarii necorespunzatoare a
software-ului.
 Organizarea activitatilor de verificare si validare este inclusa in
activitatile de management ale proiectului software si specificate in
Planul de Verificare si Validare
15 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

Ce este testarea, validarea, verificarea
• Testarea este procesul prin care se executa un program cu intentia de a gasi
erori. Testarea nu poate demonstra absenta erorilor ci doar prezenta lor.
• Verificarea asigura ca produsul este realizat in concordanta cu cerintele,

specificatiile si standardele:
• Sunt indeplinite cerintele specificate?
• Produsul este construit corect?
• Validarea asigura ca produsul va fi utilizabil pe piata.

• Produsul acopera nevoile operationale ?
• Produsul poate fi utilizat in mediul intentionat?
• Se construieste produsul care trebuie ?
• Diferenta dintre verificare si validare e sesizata de specialisti; practicienii

folosesc validarea si verificarea referindu-se la toate activitatile care asigura ca
produsul va functiona conform cerintelor

Verificare si validare
Cele doua concepte similare intalnite in testarea produselor program (PP) sunt
utilizate frecvent de catre specialisti.
• Verificarea
Acest tip de activitate ne ajuta in evaluarea PP pentru a stabili daca un produs dintr-o
anumita faza de dezvoltare satisface cerintele stabilite inainte de inceperea acestei
faze. Activitatile care verifica corectitudinea pentru faza de dezvoltare sunt denumite
activitati de verificare.
• Validarea are drept scop sa confirme daca un produs indeplineste asteptarile

clientului. Activitatile de validare se concentreaza pe produsul final, care este
testat din punct de vedere al clientului; validarea stabileste daca produsul
indeplineste asteptarile utilizatorilor globali
• Intarzierea executarii activitatilor de validare sunt adesea riscante si duc la

costuri mai mari de dezvoltare a PP.

Ce e testarea?
• IEEE 610: Procesul de a opera un sistem sau componente in conditii specifice, observand si
inregistrand rezultatele, si facand o evaluare a unui aspect al sistemului sau a componentei.
• IEEE 829 (Standard for Software and System Test Documentation): Procesul de analiza a unui item software pentru
a detecta diferentele intre conditiile existente si cele necesare, si pentru evaluarea functionalitatii
unor componente software.
• BS 7925-1 (http://www.testingstandards.co.uk/ ): Procesul de a executare a unui produs software pentru a
verifica ca satisfice cerintele si a detecta erorile.
• ISTQB (International Software Testing Qualifications Board https://www.istqb.org/ ) : Procesul ce consta in toate
activitatile de ciclu de viata, atat statice cat si dinamice, care se ocupa de planificare, pregatire si
evaluare de produse software, pentru a afla daca respecta cerintele specificate, cu scopul de a
demonstra ca respecta scopul propus si de a detecta defecte.
TESTAREA e un PROCES.
Impactul procesului de dezvoltare a PP
asupra calitatii acestora
Analiza cerintelor cerinte corect erori in definirea
definite cerintelor
Proiectarea specificatie erori in elaborarea erori induse de

conceptuala corecta specificatiei definirea cerintelor
Proiectarea proiect erori in proiect erori induse de

detaliata corect definirea cerintelor si a specificatiilor
program erori in program erori induse de definirea cerintelor

Implementare
corect si a specificatiilor + erori de proiectare
Integrare functionare erori erori cunoscute erori necunoscute

si testare corecta corectate care nu pot fi corectate
Efectul acumularii erorilor in etapele ciclului de realizarea a PP


Obiectivele testarii
• Personal implicat: programatori, inginerii de testare, directorii de proiecte
si clientii
• Procesul de testare din diferite perspective:
• Ce functioneaza: programatorii testeaza unitatile si sistemul dupa integrare in
vederea demonstrarii functionalitatii acestuia
• Ce nu functioneaza: dupa testarea functionalitatii urmeaza mai multe teste pentru
evidentierea defectelor de unitate sau sistem
• Reducerea riscului de defectare: cu cat sistemele sunt mai complexe poate apare
notiunea de defectare din timp in timp, si deci de rata de defectare
• Reducerea costurilor testarii: costuri de proiectare si executie a cazurilor de testare;
costuri de analizare a rezultatelor testelor; costuri de realizare a documentatiei in
vederea testarii si de raportare a testelor;
• Cu cat numarul de teste este mai mare cu atat va creste si costul testarii -
necesitatea selectionarii si construirii corecte a testelor

Obiectivele testarii
• Testarea este activitatea de:
• Concepere a cazurilor de test
• Executie a testelor
• Evaluarea rezultatelor testelor
In diferite etape ale ciclului de viata al PP.
Un test = executia programului pentru un set de date de
intrare convenabil ales, pentru a verifica daca rezultatul
obtinut este cel estimat.
Un caz de test = un set de date de intrare impreuna cu
datele de iesire pe care programul ar trebui sa le
produca

Definitii ale cazului de test
o Standardul IEEE 610 – 1990: “Un set de intrari ale testului, conditii de executie si
rezultate asteptate, dezvoltat pentru un obiectiv anume, cum ar fi sa exercite o
anume cale a unui program sau sa verifice corespondenta cu o cerinta specifica.”
o Standardul IEEE 829-1983: “Intrari specificate de documentatie, rezultate
asteptate si un set de conditii de executie pentru un item al testului.”
o Ron Patton (2001): “Cazurile de testare sunt intrarile specifice pe care le veti
incerca si procedurile ce vor urma cand testati produsul software.”
o De fapt, un test este o intrebare pe care o punem aplicatiei. Scopul ei este de a
aduna informatii.
Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

Definitii ale cazului de test
o Nu vrem sa descoperim doar defecte prin rularea unui caz de test.
• Informatii legate de calitate.
• Ajuta la luarea deciziilor de livrare a produsului.
• Estimarea si controlul costurilor de mentenanta si de acordare de suport pentru
produs.
• Conformitatea produsului cu specificatiile tehnice.
• Minimizeaza riscul proceselor juridice legate de siguranta.

Fazele procesului de testare
o Planificare si control
o Analiza si design
o Implementare si executie
o Evaluarea criteriilor de iesire si raportare
o Testarea se incheie – activitati de inchidere.

Caz de test. Exemplu
Un caz de test = un set de date de intrare impreuna cu
datele de iesire pe care programul ar trebui sa le
produca
Exemplu = calculul radicalului unui numar pozitiv
T1 :  0, 0 ,
T2 :  9,3 ,
T3 :  20, 4.47213595 ,
T4 :  80.5,8.97217922 ,

Caz de test. Exemplu
Iesirea estimata (IE) a unui program = o entitate
complexa care poate include urmatoarele entitati:
• Valori produse de program (valori numerice, text, audio,
imagine)
• Modificari de stare: ale programului sau ale bazei de
date (adaugare, stergere, updatare)
Ideal IE a unui test trebuie estimata in timpul proiectarii
cazului de test

Structura testului
Pentru a testa un PP un inginer de testare trebuie sa realizeze o secventa de activitati de
testare:
1. Identificarea
obiectivelor
3.Calculul iesirii estimate
5. Executarea programului
2. Selectarea
intrarii Program Iesire obtinuta
6.Analiza
rezultatelor testului
Mediul extern
4.Pregatirea mediului de executie verdict asociat testului
Raportul de testare trebuie sa contina:

- descrierea testului: intrare/iesire, mediul de executie
- explicatii despre cum se poate reproduce o defectiune obtinuta
- analiza defectiunii, descriere
Rolul testarii
• Testarea joaca un rol important in mentinerea si imbunatatirea

calitatii produselor program
• Calitatea produselor se imbunatateste pe tot parcursul ciclul de
realizarea al produsului prin repetarea ciclului “test – detectare
defect-corectare”
• Asigurarea calitatii cuprinde toate masurile, care au drept scop
imbunatatirea calitatii unui produs program.


Tipuri de teste. Teste unitare
• O unitate este cea mai mica parte testabila a unei aplicatii:
• functie/procedura intr-un limbaj de programare
• Testarea este efectuata de programatorul care o
implementeaza, pe baza specificatiei
• In cursul testarii, unitatea este tratata ca o entitate
independenta, care nu necesita prezenta altor componente
ale programului
• Necesita implementarea de module “stub”(ciot) si a unui
modul “driver”

Tipuri de teste. Teste unitare
• Modulul “stub” este o secventa de cod care simuleaza comportamentul
unei componente neimplementate inca
• Modul “driver” este o secventa de cod care conduce integrarea astfel

incat unitatea testata poate primi datele de la componentele
neimplementate inca, sau pot fi preluate dintr-un fisier
Modul driver
Modul testat /
unitate testata
Modul stub Modul stub

Tipuri de teste. Teste de integrare
• Sunt dedicate verificarii interactiunilor dintre module, grupuri
de module, subsisteme, pana la nivel de sistem.
• Exista mai multe metode de realizare a testelor de
integrare.
• Este necesara implementarea de module “stub” si module
"driver".
• Numarul de module "driver" si de module “stub” necesare
in testele de integrare depinde de ordinea in care sunt
integrate modulele.
• Testele de integrare necesita, de asemenea, instrumente de
gestiune a versiunilor si a configuratiilor.

Tipuri de teste. Teste de integrare
• Metoda "big-bang"
• Sunt integrate intr-un program executabil toate modulele existente la un
moment dat.
• Modulele "driver " si “stub” necesare sunt de asemenea integrate.
• Metoda este periculoasa caci toate erorile apar in acelasi timp si localizarea
lor este dificila.
• Integrare progresiva
• In fiecare pas se adauga ansamblului de module integrate numai un singur
modul.
• Erorile care apar la un test provin din ultimul modul integrat.
• 2 metode:
• Integrare ascendenta
• Integrare descendenta

Tipuri de teste. Teste de sistem
• Sunt teste ale sistemului de programe si echipamente complet.
• Sistemul este instalat si apoi testat in mediul sau real de functionare.
• Sunt teste de conformitate cu specificatia cerintelor software :
• teste functionale, prin care se verifica satisfacerea cerintelor
functionale
• teste prin care se verifica satisfacerea cerintelor ne-functionale :
• de performanta,
• de fiabilitate,
• de securitate, etc.
• Adesea, testele de sistem ocupa cel mai mult timp din intreaga perioada
de testare.

Tipuri de teste. Teste de acceptare
• Sunt teste de conformitate cu produsul solicitat, conform contractului cu
clientul (->Specificatia cerintelor utilizatorilor).
• Aceste teste sunt uneori conduse de utilizator.

• Pentru unele produse software, testarea de acceptare are loc in doua
etape:
1.Testarea alfa: se efectueaza folosindu-se specificatia cerintelor
utilizator
2.Testarea beta: programul este distribuit unor utilizatori selectionati,
realizandu-se astfel testarea lui in conditii reale de utilizare.

Tipuri de teste. Teste regresive
• Teste executate dupa corectarea erorilor, pentru a se
verifica daca in cursul corectarii nu au fost introduse alte
erori.
• Aceste teste sunt efectuate de regula in timpul intretinerii.
• Pentru usurarea lor este necesar sa se arhiveze toate
testele efectuate in timpul dezvoltarii programului, ceea ce
permite, in plus, verificarea automata a rezultatelor testelor
regresive

Energetice
Curs 14
Capitolul 10. Asigurarea calitatii

Ce este calitatea?
o Este un concept complex, care depinde de context si semnifica lucruri diferite
pentru persoane diferite.
o Pentru utilizator, inseamna satisfacerea nevoilor si cerintelor sale.
o Pentru producator, inseamna conformarea cu specificatiile tehnice.
o Cu alte cuvinte, calitatea inseamna valoare adusa produsului pentru cineva.
o Testarea nu aduce automat calitate! Ea măsoară nivelul calității unui produs.
Totodata, testarea nu poate demonstra absenta defectelor din aplicatie.

Asigurarea calitatii
• Totusi testarea este o activitate de asigurare a calitatii a produselor
software.
• Procesul de asigurare a calitatii trebuie sa inceapa devreme in ciclul
de dezvoltare software si sa fie parte integrata din acesta.
• Are patru activitati:
o Definirea criteriilor de calitate
o Validare
o Verificare
o Raportare

Carcateristici ale produselor informatice
Utilitatea se concretizeaza prin ce realizeaza sistemul, iar

performanta prin modul in care utilitatea este indeplinita.
Utilitatea este un ansamblu de cerinte si restrictii impuse

functionarii sistemului de utilizator in scopul realizarii unor
rezultate bine determinate.
Performanta este un ansamblu de cerinte si restrictii impuse

de o functionare optima a sistemului, in conditiile satisfacerii
utilitatii.

Produsele informatice (PI) trebuie sa indeplineasca anumite
caracteristici, performante de baza:
Portabilitatea – caracteristica PI de a fi transferat de pe un suport
hardware pe altul;
Fiabilitatea – este capacitatea PI de a indeplini anumite functii sau cereri
fara erori;
Flexibilitatea definita prin capacitatea sistemului informatic de a se
adapta la orice modificare impusa de beneficiarul PI in sensul
exploatarii acestuia;
Timpul de raspuns este definit ca intervalul de timp real, din momentul
aparitiei unei excitatii exogene si momentul realizarii complete a
functiilor PI pentru setul respectiv de date; el poate fi echivalent, in
majoritatea situatiilor, cu durata regimului tranzitoriu;

Ce parametru care defineste performanta unui produs informatic (PI) se
poate transforma in utilitate in urmatoarele situatii ?
1. portabilitatea A. PI generalizate (cu aplicabilitate pentru o clasa larga de procese)

sunt realizate cu o gama larga de echipamente
2. fiabilitatea B. La PI cu destinatie speciala (din domeniul militar sau cosmic,
sisteme energetice nationale) se impune prevenirea avariilor ce
3. flexibilitatea conduc implicit la catastrofe
C. PI destinate conducerii proceselor industriale trebuie sa lucreze in
4. timp de timp real.
raspuns D. Procesele mari necesita PI mari deoarece acestea implica o gama
larga de prelucrari de date, datorita numarului mare de cerinte si
restrictii. In consecinta sunt antrenate resurse importante, deci
investitii mari. Dpdv economic aceste investitii trebuie sa fie
amortizate in timp (pe durata de viata a sistemului respectiv).

Alte caracteristici al calitatii :
 Testabilitatea - usurinta cu care un PP, sau o parte a sa poate fi testata
 Utilizabilitatea – efortul cerut pentru a invata, utiliza si intrerupe
functionarea unui PP
 Integritatea – masura in care PP si datele sunt imune la accesul neautorizat
al clientului
 Refolosibilitatea - usurinta cu care componente ale unui PP pot fi utilizate
(mutate) într-un alt PP;
 Interoperabilitatea - abilitatea PP de a fucntiona impreuna cu un alt PP

Caracteristicile principale si derivate ale calitatii produselor software
potrivit modelului calitatii definit de standardul ISO/ IEC 9126
Functionabilitate
Fiabilitate
Portabilitate
Eficienta
Mentenabilitate
Utilizabilitate

Caracteristici Caracteristici derivate si semnificatii

Functionabilitate Adecvanta: prezenta si adecvanta setului de
functiuni in raport cu specificatiile.
Acuratete: atributele PP legate de obtinerea
rezultatelor corecte sau convenite ( ex: gradul de
precizie necesar al valorilor).
Interoperabilitate: posibilitatea de interactiune a
PP cu alte produse specificate.
Conformitate: conformitatea cu standarde,
conventii, reglementari si alte prescriptii similare,
legate de domeniul de aplicatie.
Securitate: posibilitatea PP de a preveni accesul
neautorizat, accidental sau deliberat, la programe
sau date


Fiabilitate Maturitate: gradul de maturitate al PP, respectiv
frecventa defectiunilor din cauza erorilor PP.
Toleranta la defecte: capacitatea PP de a-si mentine un
anumit nivel specificat de performanta in caz de eroare.
Recuperabilitate: posibilitatea restabilirii nivelului de
performanta si refacerea datelor in cazul unei erori,
timpul si efortul necesar pentru aceasta.
Facilitate de intelegere: usurinta in intelegere, efortul
utilizatorului de a recunoaste conceptul logic si
aplicabilitatea lui.
Operabilitate: usurinta in operare, respectiv adecvarea
stilului de interactiune si a tipului de interfata.
Facilitate de a invata: usurinta in invatarea aplicarii
Utilizabilitate produsului.


Eficienta Comportare in timp: respectiv eficienta ca timp de raspuns
pe tipuri de prelucrari, rate de transfer sub conditii diferite
de incarcare si configuratii diferite.
Comportamentul resurselor: respectiv consumul de
memorie interna si externa in diferite conditii
Analizabilitate: rapiditatea si exactitatea cu care se poate
identifica o eroare in executie din mesajele PP si cauzele
acesteia.
Modificabilitate: efortul necesar pentru modificare,
remedierea erorii sau pentru schimbarea mediului.
Stabilitate: se refera la riscul unui efect neasteptat al
modificarilor.
Mentenabilitate Testabilitate: se refera la efortul necesar pentru validarea
PP modificat.


Portabilitate
Adaptabilitate: posibilitatea de adaptare la alte medii
specifice fara a apela alte facilitati decat cele proprii PP.
Usurinta de instalare: posibilitatea de instalare a produsului
intr-un mediu specificat.
Conformitate: gradul de aderare al PP la standardele si
reglementarile legate de portabilitate.
Interschimbabilitate: posibilitatea si efortul de utilizare in
locul altui PP specificat, in mediul acelui PP

Asigurarea calitatii este mentinuta prin analize statice si
dinamice si evaluata printr-o serie de masuratori
Analiza statica
• Este bazata pe examinarea documentatiei: specificatii de cerinte, modele
software, documente de proiectare si coduri sursa
• Traditional analiza statica include revizii de cod, inspectii, analize de
alogoritmi di dovezi de verificare a corectitudinii codului
• Nu include executarea codului aflat in dezvoltare, dar inspecteaza codul si
comportarile posibile ale acestuia in vederea optimizarii comportamentului
in urma compilarii.

Analiza dinamica
• Este bazata pe executarea programului pentru a se descoperii posibilele
defectiuni in functionarea acestuia
• Sunt observate atat caracteristicile comportamentale cat si de performanta
ale acestuia
• Programele sunt executate atat cu date tipice cat si special proiectate
• Este importanta determinarea setului finit de teste potrivit pentru
evaluarea corecta a performanteleor si comportarii sistemului
Prin utilizarea ambelor abordari se doreste identificarea maximului de erori posibile

astfel incat aceste sa fie rezolvate cat mai curand in ciclul de realizare al produsului
program.


IPE Curs12continuare

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IPE Curs12continuare

Încărcat de

Drepturi de autor:

Formate disponibile

Informatizarea Proceselor

Capitolul 8. Metodologii de realizare a sistemelor

Prof.dr.ing. Ioana FAGARASAN

• Se referă la o serie de principii care urmăresc ajustarea etapelor de realizare a

Metodologii de realizare clasice

 Aceste metodologii sunt orientate pe programare şi au puține reguli

 Aceste metodologii sunt orientate pe programare şi au puține reguli bine

 Sunt bazate pe un set de douăsprezece principii:

 Pe baza acestor principii, metodologiile agile se concentrează pe optimizarea procesului

Planificare Planificare Planificare

Analiză Analiză Analiză

Proiectare Proiectare Proiectare

Implementare Implementare Implementare

Iteraţia 1 Iteraţia 2 Iteraţia 3...

Abordare realistă în realizarea sistemelor Nu sunt potrivite pentru a gestiona dependenţe

• Pune accentul pe implementare/cod (standarde, principii) - utilizează un set comun de nume,

 Numele metodologiei este preluat din jocul de rugby, şi desemnează o grămadă

 Echipele sunt auto-organizate și auto-dirijate.

 Spre deosebire de alte abordări, echipele Scrum nu au un lider de echipă desemnat.

 Echipele se organizeze într-o manieră simbiotică și își stabileasc propriile obiective

Capitolul 9. Testarea, verificarea si validarea produselor

Prof.dr.ing. Ioana FAGARASAN

 Efectuate pe tot parcursul ciclului de viata

15 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

• Verificarea asigura ca produsul este realizat in concordanta cu cerintele,

• Validarea asigura ca produsul va fi utilizabil pe piata.

• Diferenta dintre verificare si validare e sesizata de specialisti; practicienii

16 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

• Validarea are drept scop sa confirme daca un produs indeplineste asteptarile

• Intarzierea executarii activitatilor de validare sunt adesea riscante si duc la

17 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

Proiectarea specificatie erori in elaborarea erori induse de

Proiectarea proiect erori in proiect erori induse de

program erori in program erori induse de definirea cerintelor

Integrare functionare erori erori cunoscute erori necunoscute

Efectul acumularii erorilor in etapele ciclului de realizarea a PP

19 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

20 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

21 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

22 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

26 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

27 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

4.Pregatirea mediului de executie verdict asociat testului

Raportul de testare trebuie sa contina:

• Testarea joaca un rol important in mentinerea si imbunatatirea

29 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

30 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

31 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

• Modul “driver” este o secventa de cod care conduce integrarea astfel

32 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

33 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

34 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

35 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

• Aceste teste sunt uneori conduse de utilizator.

2.Testarea beta: programul este distribuit unor utilizatori selectionati,

realizandu-se astfel testarea lui in conditii reale de utilizare.

36 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

37 Analiza si Proiectarea Sistemelor Informatice Industriale - curs 12

Capitolul 10. Asigurarea calitatii

Prof.dr.ing. Ioana FAGARASAN

Analiza si Proiectarea Sistemelor Informatice Industriale - curs 13