1

Univ. Ioan Slavici

Facultatea de Inginerie Calculatoare și Tehnologia Informației

Specializare: Tehnologia Informației

Ingineria programării

“Note curs”
 2

Contents
Definiție Ing. Programării............................................................................................................................3
Modele de dezvoltare...............................................................................................................................12
Etapele dezvoltarii programelor............................................................................................................12
Prototipizarea........................................................................................................................................15
Analiza cerintelor.......................................................................................................................................15
Design patern............................................................................................................................................17
Principii si moduri arhitecturale................................................................................................................17
Coding Standards.......................................................................................................................................28
Testare.......................................................................................................................................................28
Teste de acceptanta..............................................................................................................................29
Ce anume ar trebui sa contina un test plan?.........................................................................................29
Software license........................................................................................................................................33
Forme de licente....................................................................................................................................33
Restrictii.................................................................................................................................................33
Acorduri suplimentare...........................................................................................................................34
Licente de tip MS FPP............................................................................................................................34
MS OEM software..................................................................................................................................34
Asigurarea calitatii.....................................................................................................................................34
Ce este calitatea?..................................................................................................................................34
Ce inseamna un produs de calitate ridicata?.........................................................................................35
Metrici de calitate software...................................................................................................................35
 3

Definiție Ing. Programării

 Prima definiție a ingineriei programarii (NATO,1968): Ingineria programarii este

stabilirea și utilizarea de principii inginerești solide pentru a obține în mod economic
programe care sunt sigure și funcționeaza eficient pe mașini de calcul concrete
 Ingineria programării este stabilirea și utilizarea de principii inginerești solide pentru
a obține în mod economic programe care sunt sigure și funcționează eficient pe
mașini de calcul concrete
 O definiție recentă (IEEE Standard Glossary of Software Engineering Tehnology,
1983): Ingineria programării reprezintă abordarea sistematică a dezvoltării,
funcționării, întreținerii, și retragerii din funcțiune a programelor.
 “Software Engineering” care descrie “building of software systems which are so
large or so complex that they are built by a team or teams of engineers“ -
Fundamentals of Software Engineering (Ghezzi, Jazayeri, and Mandrioli).
 FreeDictionary: “The process of manufacturing software systems. A software system
consists of executable computer code and the supporting documents needed to
manufacture, use, and maintain the code.”
 Wikipedia: “Software engineering is the application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of software,
and the study of these approaches”

1. Ce este un proiect software ?

 Este un set de activități legate de elaborarea unuia sau mai multor programe, părți de
programe sau sisteme de programe.
 Rezultatul unui proiect software este un produs software.

2. Motivație:

 Aplicații de dimensiuni mari (milioane de liniide cod) scrise pe durata a câteva luni, ani.
 Echipe de lucru: Project manageri, Analiști,Arhitecți, Programatori, Testeri, Ingineri de
suport (de ordinul 10, 100, 1.000 de persoane,…)
 Soluția acestor probleme este o soluție scrisa într-un limbaj de programare orientat-
obiect

Motivele eșecurilor:
 4

 Probleme de organizare
 Modificari neasteptate ale clientului
 Ingineri soft de slaba calitate
 Resurse insuficiente
 Probleme de managment
 Metode noi de lucru

Calitatea este limitată de bugetul proiectului,

termenele limită și caracteristici.

Motive:

 Trasabilitate
 Optimizare
 Refolosire
 Scaderea timpului
 Calitate mai buna
 Costuri mai mici

Pentru un proiect de succes trebuie sa tinem cont de:

 Managment (implicare, decizie, coordonare)

 Asteptariile prea mari
 Cerinte
 Cunostinte
 Infrastuructura
 Concurenta
 Marketing
 5

 Planificare
 Comunicare
 Plan – Do – Check
Obiectivele (beneficile) rezultatelor la care ne asteptam in urma optimizarii procesului:

 Produs conform
 Reutilizam
 Optimizat
 QTC (quality time cost)
 Profit
 Trasabilitate
 Marketing

3. Costurile produselor software

4. Software-ul construit (negru) vs cumpărat (roșu):

 6

În prezent costurile acestora sunt mai mari decât costurile rezervate componentelor
hardware. Costul întreținerii unui program este de regulă mai mare decât costul
realizării unui program.

Dupa inceperea productiei

5. Care sunt atributele unui program bun ?

 Să fie ușor de folosit.

 Să nu se irosească resurse hardware.
 Să ofere funcționalitățile cerute.
 7

 Să fie usor de schimbat, completat și modificat.

 Un program este bun daca poate fi reutilizabil, poate fi extins.
 Vom considera că un proiect software are succes, dacă este realizat într-un
timp rezonabil și cu un buget rezonabil.
 Un eșec al unui produs software are loc atunci când produsul nu este realizat
sau când nu poate fi folosit.

6. Informatica vs Ing. Programării

Ing. Programării se ocupă de aspectele practice ale dezvoltării software iar informatica se
ocupă de aspectele teoretice ale dezvoltării software.

Ingineria sistemelor se ocupa de toate aspectele dezvoltării sistemelor de calcul (ingineria

proceselor, hardware și software).

Ing. Programării este o parte din ingineria sistemelor și se ocupă de:

 Specificarea cerințelor
 Proiectarea arhitecturală
 Implementare
 Testare
 Integrare
 Implementare

 Etapele dezvoltării:
 8

 Erori pe etape:
 9

Dificultăți pe care le întâlnim în Ing. programării:

 Presiunea pentru a livra programul cât mai repede cu un cost mic și cu o calitate bună.
Sistemele vechi trebuie întreținute și actualizate.

Pentru dezvoltarea programului avem nevoie de:

 Înțelegere clară a ceea ce se cere.

 Planul de acțiune și un set de metode și instrumente de lucru.

7. Etapele de dezvoltare a unui produs:

 Analiza cerințelor (Requirements analisys)

 Proiectarea arhitecturală (Arhitectural design)
 Proiectarea detaliată (Detailed design)
 Scrierea codului (Implementation)
 Integrarea componentelor (Integration)
 Validare (Validation)
 Verificare (Verification)
 Întreținere (Maintenance)

8. Analiza cerințelor:

Se stabilește ce anume isi doreste clientul de la produsul sau.

Problemele care apar sunt:

 Comunicarea
 Negocierea
 Sfătuirea clientului.
 10

9. Proiectarea:

 Arhitecturală - Programele mari nu pot fi concepute și implementate ca o singură

bucată iar programele sunt împărțite în module sau componente mai simple, care pot fi
abordate individual.
 Detaliată: Orice modul al aplicației se proiectează în cele mai mici detalii.

 Primul pas în analiză este de a studia cu atenție cerințele de intrare și de ieșire pentru a
vă asigura că acestea sunt înțelese și au sens
 Use case: lista acțiunilor utilizatorilor și răspunsurile sistemului pentru o anumită sub-
problemă în ordinea în care este probabil să apară
 Diagrama secvențelor: arată toate obiectele implicate în acest caz de utilizare pe axa
orizontală, timpul este prezentat de-a lungul axei vertical
 Condiție preliminară: o declarație privind orice ipoteze sau constrângeri asupra datelor
metodei înainte de începerea execuției metodei
 Postcondition: o instrucțiune care descrie rezultatul executării unei metode
 Abstracția este un model al unei entități fizice sau al unei activități
 Abstracția ajută programatorii să trateze probleme complexe într-o manieră fragmentată
 Abstractarea procedurală: distinge ceea ce urmează să fie realizat printr-o procedură de
la punerea sa în aplicare
 Abstractizarea de date: specificarea obiectele de date pentru o problemă și operațiile
care trebuie efectuate asupra acestora fără reprezentarea lor în memorie
 Reprezentarea unui obiect de date este irelevantă pentru alte clase care accesează
numai prin metodele sale  Ascunderea informațiilor: ascunderea detaliilor unei
implementări de clasă pentru utilizatorii clasei
 11

 Pe măsură ce interdependențele cresc, caracteristici precum reutilizarea, flexibilitatea și

mentenabilitatea descresc
 Un sistem cu structură de dependență scăzută va prezenta de obicei aceste patru
trăsături negative:
o Este rigid
 Impactul unei schimbări nu poate fi prezis, ca urmare nu poate fi estimat
 Timpul și costul nu pot fi cuantificate
 Managerii devin reticenți în a autoriza schimbarea
o Este fragil
 O singură modificare necesită o serie de modificări ulterioare
 Noile erori apar în zone care nu par să fie legate de zonele modificate
 Calitatea este imprevizibilă.
 Echipa de dezvoltare pierde credibilitatea
o Nu este reutilizabil
o Are vâscozitate ridicată

10. Implementare:

 Implementarea cuprinde codificarea și testarea separată a modulelor definite în etapa

de proiectare de detaliu. Este cea mai bine stăpânită şi cea mai bine “utilată” dintre
toate activităţile ciclului de viaţă al unui program - în anumite cazuri este chiar
automatizată sau parţial automatizată.

11. Integrare:

 Unitățile (modulele) care au fost testate independent sunt integrate treptat in

subsisteme, până la nivel de sistem.
 Se verifică comunicarea si interactiunea între componentele integrate.
 Secvența în care componentele sunt codificate si integrate în subsisteme executabile
este definită într-un plan pregatit în etapa de proiectare de detaliu.

12. Validare:
 12

 Ne asigurăm că programul îndeplinește cerințele utilizatorului.

13. Verificare:

 Ne asigurăm că programul este stabil și că funcționează corect din punctul de vedere al

dezvoltatorilor.

14. Întreținere:

 Începe odată cu livrarea produsului software la beneficiar.

 Este efectuată de un grup special.
 Activitățile depind de tipul de software: corectarea defectelor, îmbunătățirea unor
caracteristici, adaptarea la cerințe noi.

Modele de dezvoltare

Pentru a dezvolta un program este nevoie de:

 O înțelegere clara a ceea ce se cere
 Un set de metode și instrumente de lucru
 Un plan de acțiune

Plan de acțiune = șablon = model de dezvoltare

Etapele dezvoltarii programelor

 Un plan de Analiza cerințelor (Requirements analisys)
 Proiectarea arhitecturala (Arhitectural design)
 Proiectarea detaliata (Detailed design)
 Scrierea codului (Implementation)
 Integrarea componentelor (Integration)

Modele de dezvoltare
 Ad-hoc: descurcă-te cum poți
 Modelul în cascadă (cu feedback)
 13

 Prototipizare
 Modelul în spirală
 RUP (Rational Unified Process)
 V-Model
 XP (Extreme Programming)
 Agile, Lean, Scrum
 MDD, AMDD, TDD Modelul V:

Este o variantă a modelului cascadă, care pune în evidență corelarea dintre activitățile de
specificare și cele de testare, înlanțuirea în timp a activităților fiind aceeași. Planificările se fac o
dată cu parcurgerea primei ramuri.

 Avantaje:

+ Simplu și ușor de utilizat, mai ales pentru proiecte mici.

+ Fiecare fază are lucruri specifice, controlabile, de livrat.

+ Mai bun decât modelul în cascadă deoarece planul de teste este făcut încă de la început.

 Dezavantaje:

- Nu produce prototipuri timpurii

- Rigid, greu de introdus modificări dacă apar.

 14

15. Modelul cascadă cu întoarcere:

Mai exista modelul liniar si modelul liniar cu revenire la etapa anterioara.

 Avantaje și dezavantaje:

+ Oferă cadrul pentru remedierea erorilor din pasul precedent.

- Clientul vede produsul final abia la sfârșitul dezvoltării.

- Erorile la pasul i care sunt descoperite la pasul i + 2 nu sunt remediate.
 15

Kanban

Prototipizarea

 Tipuri de prototipuri
 De aruncat (throw-away)
 Scop: clarificarea specificațiilor
 Se dezvolta repede, orice altceva e secundar
 (quick-and-dirty)
 Util în a rezolva “architecural/technology spikes”
 Programul “adevarat” este scris apoi de la 0
 Evoluționar
 Scop: construire incrementala a produsului final
 Se construiește un nucleu funcțional la care se adauga apoi noi funcționalitați

Analiza cerintelor
 16

Cerinte (requirements). O discutie intre client si req. Manager. In prima parte este
negocierea si clarificarea ( elicitation, requirements validation, requirements managment –
change managment este nevoie de versionare ).

Requirements pot fi :

 Functionale ( se pot testa si se se face review)

 Nefunctionale (standardele, procese, lagal staf, aspect, quality, time line,
metodologi interne)
Textele requirements trebuie sa fie:

 Aplicabile
 Atomice
 Unice
 Clare, explicite
 Standardizat ( cine ce face)
 Sa aibe ID
 17

 Sa poate sa fie testate

 Criterii de acceptanta (obiectiv, toleranta)
 Constrangeri
 mentenabilitate;
 verificabilitate;
 completitudinea;
 corectitudinea,
 consistență;
 claritate;
 trasabilitate;
 modificabilitate;
 lizibilitatea;
 usor de folosit.
 S.M.A.R.T. ( specific, masurabil, aplicabil, relevant, usor de urmarit)
o S pecific Measurable A trainable R ealisable Time bounded.

Scheme, tabele nu au ce cauta in requirements. Daca clientul ne da asa ceva le punem ca si info
sau aditionale.

Sunt fezabile cand nu mai avem dubii si daca avem o descriere corecta a problemei (cat mai
detaliata). Foarte important in acesta etapa este definirea obiectivului.

Design patern

 interface segregation principle ( nu trebuie sa facem „varza”)

 open close principle
 dependency inversion principle
Nu trebuie sa uitam de change managment (sa fie trasabila) de la o versiune la alta, asa va fi
usor de gestionat

Principii si moduri arhitecturale

 Pipeline I – O
 Obiectual ( blocuri )
o atribute
o actiuni
o UML
 Call – return model
 18

 Manager model – SO
 Shared repository
 Shared services / servers
 Abstract machines

Design editor
Cod generator

Design Project
translator Program editor
repository

Design analyser Report generator

Modelarea

- Class
- Object ( obiectul este o instanta a clasei )

Modelul

- Simplificarea realitatii
- Planul detaliat al unui system

De ce modelam ?

- Pentru a intelege mai bine ce avem de facut

- Pentru a ne concentra pe un aspect

Relatii intre clase

Cele mai uzuale relatii intre clase sunt :

 19

- Mostenire
- Agregare

Persoana

Mostenire

Fetita

Modelarea arhitecturii

- Use case – urile

- Designul

Decizie

Yes

No

Bucla
 20

Extinde clasa abstracta

Instructiune

- Proceselor
- Cu ajutorul Deployment- ului – punerea in practica ( concept client – server )

Principii

- Modelele influenteaza solutia finala

- Au correspondent
- Diferite niveluri de precizie
- Nu e sufficient un singur model

Limbaje de modelare

- Tipuri de limbaje – UML, AML , DSL , FSML , VRML

- Limbaje grafice
- Arbori comportamentali
- Modelarea proceselor de business
- EXPRESS ( modelarea datelor )
- Flowchart
- Petri.Nets
- Metoda Booch
- OMT ( object modeling technique )
- OOSE
- Diagrame UML

UML
 21

- Este succesorul celor mai bune 3 limbaje de programare

- A aparut in anul 1990
- Este in continua dezvoltare
- Exista 13 tipuri de diagrame folosite clasate in 3 categorii
 De structura
 De comportament
 De interactiune

Use case

Relatii

- Asociere :
- Generalizare :
- Dependenta : < - - - - - - - - - - - - -

Relatia intre use case-uri

- Agregare – caz particular al relatiilor de asociere

DRY – Don’t repeat yourself

KISS – Keep it simple and stupid ( Open ,close , principle )

In cazul programarii 80 % din bug – uri sunt datorita “ tehnicii “ copy paste !!!

Obiecte

- Instantierea unei clase

- Defineste atribute  actiuni si procese

Function

- Function
- Methods
- Modules
 22

parametrii
F O

return

Ca sa functioneze intrariile si iesirile trebuie sa fie de acelasi tip.

int sum ( int a, int b )

return a + b ;

- Reprezinta centrul programarii

- Defineste o actiune
- In OO reprezinta o problema mai mica ( incapsulare ) .
In OO functia poate sa fie :
o Public
o Private
o Protected

Functia este o actiune !

Interfata unei functii

- Mesaj : continut
- Stare mesaj : to , ok , alterat
- Output – uri : structurate
- Receptie ( mesaj , stare )

Functia are argumente in functie de nevoi . Nu exista un numar optim de argumente .

DRY – Don’t repeat yourself

 23

- Sa nu existe conflicte
- Timp de executie
- Risipa de spatiu

Principalele caracteristici ale unui design bine facut :

- De compozitie – modularitate
- Functia sa cuprinda un singur predicat
- Intrepatrunderea componentelor

Intrepatunderea intre module

- Scopul intrepatrunderii
- Rezultatul

Efectele secundare ale descompunerii aditionale

- Identificarea grea a problemei

Nivele

- Concept
- Specificatie
- Implementare

Instantiere / Instanta

In programarea orientata pe obiecte avem nevoie permanent de clase . Putem sa aplicam

toate principiile din programarea orientate pe obiecte si in programarea functionala .

Tipuri abstracte vs interfete

Polimorfismul

- O clasa care poate fi folosita in mai multe feluri ( template )

 24

- Abstractizare
- Ajuta in refolosire

Intrepatunderea

O clasa  o singura abstractizare  o singura functie

Multiplicitatea

- Contul bancar
- Agregare, compozitie
- Minim un client
- Relatie de compozitie

Agregarea este de preferat in detrimental mostenirii !

Intrepatunderea buna

- Normalizarea bazelor de date

- Eliminarea redundantei

Conexiunea intre clase / obiecte

Forme de cuplare

 De identitate
 De reprezentare
 Subclase / mostenire

1.

 ISP
 LSP
 OCP

2. Principii de programare
 25

 Interrface Segregation Principle

 In relatia de dependența a unei clase fata o de alta clasa, aceasta ar trebui să depindă de cea mai mică
interfață posibilă
 Clienții nu ar trebui să fie obligați să depindă de metodele pe care nu le utilizează

Example – Timed door

class Door
{
public :
virtual void Lock () = 0 ;
virtual void Unlock () = 0;
virtual bool IsOpenDoor ;
}

TimerClient

Door

TimedDoor
implementarea nu respecta principiul! Deoarece nu
toate usile au nevoie de un timer

TimerClient Door

Yes

TimedDoor Mostenirea multipla

 26

Door TimerClient

TimedDoor TimedDoorAdaptor

1 +

Separarea prin delegare

Dependency Inversion Principle

Ex : Separation of policy and mechanism

Autosar
 27

Interfete standartizate usor de inlocuit

Exemplu :

Copy

Readprinter WhiteKey

void copy ()

int c ;

while (( c = ReadKeyboard () ) ! = EOF )

}
 28

Copy

Reader Writer

KeyReader PrinterWriter

Liskov Substitution Principle

o Square

Open Closed Principle

Coding Standards
 Sfaturi si reguli de folosit
 “ Unde sunt 2 buguri, cel mai probabil va fi si al treilea “
 “ Don’t patch bad code – rewrite it “
 “ Don’t stop with your first draft “

De ce sa avem standard de codare?

 Mentananta
 Mai putine buguri
 Munca in echipa
 Cost
 29

Tipuri de standarde

 De companie
 Pentru limbaje de programare

Reguli

 Identare
 Comentarea codului
 Spatiere
 Nume variabile ( tipul, modulul , nume sugestive)

Testare

 Unit Testing
 Integration Testing
 Performance Testing
 End-to-End Testing
 User Acceptance Testing
 Regression Testing

Teste de acceptanta
 Testarea cerințelor funcționale
 Gestionarea condițiilor de eroare și testarea distructivă
 Testarea securității
 Testarea de recuperare
 Testarea controlului
 Testarea performanțelor in conditii de stres
 Testarea prin regresie

Ce anume ar trebui sa contina un test plan?

 Criterii go / no-go
 Criteriile ar trebui să fie specifice și măsurabile
 Include rezultatele testelor care ar trebuie îndeplinite
 obiectivele de testare realizate, cum ar fi:
o Numărul de scenarii de testare finalizate
o Categorisirea defectelor descoperite după nivelul de severitate
o Numărul de defecte a fost rezolvat după nivelul de gravitate și testat in regresie cu
succes
 30

o Numărul de defecte restante după nivelul de gravitate

Evitarea erorilor depinde de:

 Existenta unei specificați precise a sistemului (de preferință formală)
 Proiectare software bazată încapsularea informațiilor
 Examinări extensive de validare în timpul procesului de dezvoltare
 O filozofie a calității organizaționale de a conduce procesul software
 Planificarea testarii sistemului pentru a expune defectele și a evalua fiabilitatea

Verification:

> Are we building the product right? ( Construim produsul in mod correct?)

— Este conform cu procesul nostru?

Validation:

> Are we building the right product? (Construim produsul dorit?)

— Este conform cu cerintele clientului?

Client Acceptance
Needs Testing
 31

Requirements System
Testing

Design Integration
Testing

Code Unit
Testing

Testarea componentelor – Unit testing

Obiectiv – Depistarea existentei unor defecte la nivel de unitate functionala ( componenta )

Defecte tipice puse in evidenta

 Nu se tine cont de precedenta operatorilor

 Utilizarea gresita a parantezelor
 Nume gresite ale obiectelor programelor
 Compararea unor date de tipuri necompatibile
 Lipsa intializarii sau initializare gresita
 Utilizarea gresita a unor operatori

Pe parcursul testarii componentelor urmarim detectarea erorilor si defectelor tipice la nivel de

unitate functionala .

Testarea de integrare – Integration testing

Obiectiv – Testeaza interfata intre componente pentru a pune in evidenta defecte in transferul
de informatie intre componente

Abordari ale testarii de integrare

 32

 Integrarea incrementala
 Integrarea top – down
 Integrarea bottom – up
 Testarea de regresie
 Smoke testing

Testarea incrementala se face pas cu pas , integrand la primul pas doua componente , apoi ,
dupa ce toate testele au fost realizate si defectele eliminate se adauga alta componenta , se
refac toate testele anterioare , se adauga noi teste si asa mai departe pana cand in testele
considerate nu mai pote fi pus in evidenta nici un defect .

Testarea top – down este o varianta a integrarii incrementale in care se porneste de la

programul principal si se adauga mereu componente de pe nivelele imediat inferioare pana
cand tot programul este testat.

Pasii procesului :

 Programul principal joaca rolul de test driver si se introduce surrogate pentru fiecare din
componentele direct subordinate acesteia .
 33

 La fiecare etapa un surogat este inlocuit cu o componenta reala si surogatele aferente

acesteia.
 Pentru fiecare component nou integrata se realizeaza teste.
 Numai dupa efectuarea tuturor testelor , se trece la inlocuirea urmatorului surogat cu o
componenta reala .
 Se efectueaza teste de regresie pentru a pune in evidenta eventualele defecte datorate
ultimei componente integrate .

Testarea bottom – up este o varianta a integrarii incrementale in care se porneste de la

componentele situate pe cele mai de jos nivele in structura programelor .

Testarea de regresie este un proces de confirmare ca, odata ce se schimba codul din program,
nu afecteaza celelalte functii.

Astfel, este necesar sa testam cand:

 Cand se schimba cerintele programului si codul trebuie sa reflecte aceste schimbari

 O noua functie este introdusa
 Intampinam probleme de performanta
 34

Build Verification Testing altfel cunoscut ca si Smoke Testing testeaza functiile cele mai
importante al programului pentru a se asigura ca versiunea curenta este destul de stabila
pentru a se putea lucra in continuare pe ea.

Cu ajutorul testului scoatem la iveala probleme de integrare si alte erori mai devreme.

Testarea de system ( System testing ) - testeaza sistemul integrat in ansamblu pentru a

verifica daca intalneste cerintele documentului de software (SRS). Acest test este evaluat extern
de catre un utilizator cu ajutorul documentului, neavand nevoie de cunostiinte al designului
intern sau a structurii codului, scopul principal fiind depistarea erorilor sau al defectelor de
integrare.

Testarea de acceptanta ( Acceptance tesing ) – foloseste criterii pentru a evalua produsul

complet si garanteaza ca au fost indeplinite cerintele clientului .

Software license

Licența software este un acord specific, în care autorul autorizează utilizarea programelor sale și
în principiu utilizatorul este obligat să plătească o remunerație (taxă de licență) pentru acest
lucru.

Tipuri de licente software:

 proprietary software (closed source) : commercial software

 free software (open source) : GNU GPL
 semi-free software

Forme de licente
 Licență cu nume unic de identificare
 35

o acorduri generale încheiate prin consensul părților

o sau alte confirmări ale licenței (adică aparține unui contract-cadru etc.), care
conține numele utilizatorului
o în acest caz nu aveți nevoie de factura pentru certificarea utilizării legale (dar
aveți nevoie de ea pentru scopuri contabile!)
 Licențe nenominale
o cutii de cutii
o acordul se produce printr-o acțiune reală (deschiderea cutiei etc.)
o în acest caz, trebuie să dețineți și factura
Restrictii
 limitări teritoriale
 limitarea limbajului utilizabil
 limitarea ediției
 determinarea hardware-ului
 determinarea utilizatorului
 limitări privind transferul de licență (afiliați, succesiune juridică, externalizare)

Acorduri suplimentare
 Actualizare licența
o Actualizarea este diferită (fix, patch, service pack)
 Acord de întreținere
 Acord de sprijin

Licente de tip MS FPP

 kit de instalare, manual, licență (în unele cazuri numai electronic), formularul de
înregistrare este inclus
 De obicei, puteți utiliza o singură versiune a produsului software
 Termenii licenței sunt stabiliți în EULA
 Nu există un identificator de utilizator final în licență, deci trebuie să dețineți o factură
(ca document concludent)
 Este cel mai scump mod de achiziție de software

MS OEM software

 Software-ul poate fi achiziționat cu hardware:

o Sisteme de operare
o Office (de obicei o ediție specială)
o Windows Server, SBS
 este permisă doar utilizarea unei versiuni
 Licența este electronică, eticheta COA acordă originalitatea
 36

 Nu există un utilizator final în licență, deci trebuie să dețineți o factură

 Suportul produsului furnizat de furnizorul de hardware

Asigurarea calitatii

Ce este calitatea?
 Abilitatea de a face același lucru în același mod, mereu și repede
 Clientul care cumpără astăzi un produs este asigurat ca este același cu cel pe care l-a
cumpărat săptămâna trecută sau il va cumpăra săptămâna viitoare
 Produsul satisface așteptările clienților în proportie de 100% tot timpul

Ce inseamna un produs de calitate ridicata?

 Trebuie să fie util pentru client.

 Trebuie să fie portabil.
 Trebuie să fie usor de întreținut.
 Trebuie să fie fiabil.
 Trebuie să produca rezultate corecte, cu un grad ridicat de precizie.
 Trebuie să fie eficient
 Trebuie să asigure o coerență a funcționalitatii (ceea ce ar face utilizatorul, sau se
așteaptă în mod rezonabil să facă).
 Trebuie să fie accesibil (pentru utilizator).
 Trebuie să fie ușor de învățat și ușor de folosit

Metrici de calitate software

 este o măsură cantitativă a gradului în care un sistem, o componentă sau un proces

posedă un atribut dat
 corectitudine (defecte per KLOC)
 mentenabilitate
o timp mediu de schimbare (mean time to change (MTTC) )
o randament = (costul schimbarii / costul total al sistemului )
 integritate
o amenintare = probabilitatea unui atac ( ce va cauza un failure)
o security = probabilitatea ca atacul sa fie contracarat
o integritate =  [1 - amenintare * (1 - securitate)]
• utilizabilitate
o usor de invatat (timp)
 37

o usor de folosit (timp)

o productivitate crescuta (cantitate)
o user attitude (questionnaire score)
• eficienta cu care sunt inlaturate erorile
o DRE = E / (E + D).
o E = # of erori gasite inainte de livrare
o D = # of erori gasite dupa livrare