UAV Ingineria Programarii - Serban Ovidiu

UNIVERSITATEA “AUREL VLAICU” DIN ARAD Student: Șerban Ovidiu Florin
FACULTATEA DE STIINŢE EXACTE

DOMENIUL INFORMATICĂ
Ingineria programării
Student: Șerban Ovidiu Florin

UNIVERSITATEA “AUREL VLAICU” DIN ARAD
FACULTATEA DE STIINTE EXACTE
DOMENIUL INFORMATICA AN: 3
Curs: Ingineria programării
Profesor: Dominic Bucerzan
1. Introducere în ingineria programării.

Ingineria programării reprezintă aplicarea unei abordări disciplinate,
sistematice şi cuantificabile pentru dezvoltarea, operarea şi întreţinerea
produselor software.
Sursa: Glosarul terminologiei ingineriei programării, IEEE, 1990 ( Institute of Electrical and Electronics Engineers )
o În anul 1946 Goldstine şi von Neumann apreciau că 1000 de instrucţiuni

reprezintă o limită superioară rezonabilă pentru complexitatea problemelor
ce pot fi concepute ca rezolvabile cu ajutorul calculatorului.
o Sistemul de rezervare a biletelor pentru compania aeriană KLM conţinea,

în anul 1992, două milioane de linii de cod în limbaj de asamblare.
o După ce a prevăzut în 1981 că nici un program pentru calculatoare

personale nu va necesita vreodată mai mult de 640 KB de memorie RAM,
Bill Gates admite în 1995 că lucrurile s-au schimbat în ultimele două
decenii.
o In anul 1949 o revistă de popularizare a ştiinţei afirma că în viitor ar putea

exista calculatoare mai uşoare de 1,5 tone.
2. Definitie.
o Prima definiție a ingineriei programării data de NATO in anul 1968:
Ingineria programării este stabilitatea si utilizarea de principi inginerești
solide pentru a obține in mod economic programe care sunt sigure si
funcționează eficient pe mașini de calcul concrete. (F. L. Bauer )
o In anul 1983 a fost introdusă o definiție mai recenta:

Ingineria programării reprezintă abordarea sistematică a dezvoltării,
funcționării, întreținerii, si retragerii din funcțiune a programelor. (IEEE Standard
Glossary of Software Engineering Tehnology, 1983)
o ro.wikipedia.ro spune: (http://ro.wikipedia.org/wiki/Inginerie_software)

Ingineria software (din engleză: software engineering) este un domeniu ce
implică proiectarea, crearea și întreținerea de software aplicând tehnologii și
practici din informatică (știința calculatoarelor), managementul proiectelor,
inginerie, proiectarea interfețelor și a altor domenii.
Statistici.
o Va fi considerat 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.
 Studii de succes: USA’82 - Gibson & Singer
18 proiecte
12% 19% Succes: 17%
25% Parţial în folosinţă: 28%
32% Satisfacătoare: 11%
12%
Eşec: 22%
Neevaluate: 11%
Motivele eşecurilor
◦ Probleme de organizare
◦ Noile metode de lucru şi politicile salariale
◦ Modificările neprevăzute în afacere
Statistici.
 Studii de succes: USA’82 - Gibson & Singer
Din peste 100 proiecte
25% 33%
Succes: 33%
Cu probleme: 42%
42%
Eşec: 25%
Motivele eşecurilor
◦ Slaba pregătire a inginerilor software
◦ Resurse insuficiente
◦ Probleme de management
3. Greșeli celebre
o Sistemul de operare IBM OS360 conținea la fiecare relansare 1.000 de
greșeli.
o Pierdere vehicul explorare Venus. Problema era intr-un “FOR”....
o Unele sisteme integrate din aparatele de radioterapie au administrat doze

letale de radiaţii pacienţilor.
o Sistem de avertizare anti-rachetă activat. Atacam sau nu?
o În anul 1979 s-a descoperit o eroare în programele pentru sistemele de

răcire în centralele nucleare din SUA. Nu a fost niciodată nevoie de
execuţia rutinelor ce conţineau erorile.
o Ariane 5 explodează in 1996. Costurile s-au ridicat la : 500.000.000 $

4. Costurile destinate programelor.

o Aproape toate costurile programelor domină deseori costurile sistemelor
computerizate.
o Întotdeauna costurile de software pe un PC sunt mai mari decât costurile
de hardware.
o Întreţinerea programelor costă mai mult decât dezvoltarea lor
o Pentru sisteme cu durată mare de funcţionare, costurile de întreţinere pot
fi de câteva ori mai mari decât costurile de dezvoltare.
o Este necesară dezvoltarea de programe cât mai eficientă din punct de
vedere financiar.
5. Nevoia de programe.
o In general economia tuturor statelor dezvoltate depinde de sisteme
informatice bine puse la punct.
o Tot mai multe mai multe sisteme de siguranța sunt controlate de
calculator.
o Este necesară identificarea de teorii, metode şi instrumente pentru
dezvoltarea profesionistă de programe.
6. Scopul ingineriei programării.

o Ingineria programării are ca scop proiectarea si producţia de software.
o Inginerii programatori trebuie să adopte o manieră de lucru sistematică şi

organizată, să utilizeze instrumente şi tehnici adecvate în funcţie de
problema care trebuie rezolvată şi să ţină seama de constrângerile de
dezvoltare şi de resursele disponibile.
7. Siguranța si securitatea programelor.

o Un program este sigur dacă funcţionează corect, fără operaţii nedorite si
inutile.
o Un program pentru tranzacțiile online trebuie sa efectueze tranzacţiile
corect, chiar dacă funcţionarea sa poate fi întreruptă din când în când.
o Securitatea se referă la faptul că un sistem nu trebuie să permită utilizarea
neautorizată şi că se poate proteja împotriva atacurilor.
o Capacitatea sistemului de a rezista atacurilor este o proprietate complexă
dificil de măsurat întrucât pot apărea atacuri care nu au fost anticipate de
proiectanţii sistemului.
8. Cerințele unui produs software

o Întreținere cu costuri scăzute.
Programele cu ciclul lung de viaţă sunt supuse deseori modificărilor, de aceea
trebuie foarte bine documentat.
o Eficienţa.
Produsul nu trebuie să folosească în pierdere resursele sistemului.
o Interfaţa trebuie sa fie ușor de utilizat.

Interfaţa trebuie să ţină seama de capacitatea şi cunoştinţele utilizatorilor.
o Instruire.
Acces rapid la documentația produsului cu un “help” cat mai eficient.
o Fiabilitatea.
Produsul trebuie să se comporte după cerinţele utilizatorului şi să nu „cadă”
mai mult decât e prevăzut în specificaţiile sale.
9. Fazele fundamentale ingineriei programării.

Cele patru faze fundamentale ale metodologiilor ingineriei programării sunt:
Analiza
Ce dorim sa construim
Proiectarea
Cum vom construi
Implementarea
Construirea propriu-zisă
Testarea
Asigurarea calităţii
Analiza
o Această fază defineşte cerinţele sistemului, independent de modul în care acestea vor fi îndeplinite
o Se defineşte problema pe care doreşte să o rezolve clientul
o Rezultatul este documentul cerinţelor, care trebuie să precizeze clar ce trebuie construit
Proiectarea
o Pe baza cerinţelor din faza de analiză, se stabileşte arhitectura sistemului:
 Componentele sunt elementele constructive ale produsului. Acestea pot fi create de la zero sau reutilizate dintr-o
bibliotecă de componente. Componentele rafinează şi capturează semnificaţia detaliilor din documentul cerinţelor
 Interfeţele ajută la îmbinarea componentelor. O interfaţă reprezintă graniţa dintre două componente, utilizată pentru
comunicarea dintre acestea. Prin intermediul interfeţei, componentele pot interacţiona
 Comportamentul, determinat de interfaţă, reprezintă răspunsul unei componente la stimulii acţiunilor altor componente
Implementarea
o În această fază este construit sistemul, ori plecând de la zero, ori prin asamblarea unor componente pre-existente
o Scopul este producerea sistemului propriu-zis
Testarea
o Asigură calitatea produsului software
o Scopul este realizarea unui produs competitiv
o Un produs performant creşte satisfacţia clienţilor, iar funcţionalitatea poate fi dezvoltată în versiuni ulterioare
10. Modele de dezvoltare software.

o Modelul î̂n cascadă + Împarte o sarcină complexă în pași mai mici.
Ingineria
+ Ușor de administrat și controlat.
cerințelor
+ Fiecare pas are ca rezultat un produs bine definit.
Proiectarea
arhitecturala - Erorile se propagă între pași.
Proiectarea - Nu există mecanisme de reparare a erorilor.

detaliata
Implementare
Testarea
unităților
Testarea
sistemului
Ingineria
cerințelor
o Modelul
în cascadă cu întoarcere. + Oferă cadrul pentru remedierea erorilor din pasul
precedent.
Ingineria
- Erorile la pasul i care sunt descoperile la pasul i + 2 nu
cerințelor
sunt remediate.
- Clientul vede produsul final abia la sfârșitul dezvoltării.
Proiectarea
arhitecturala
Proiectarea
detaliata
Implementare
Testarea
unităților
Testarea
sistemului
Ingineria
cerințelor
o Modelul ĉiclic. + După fiecare modificare a codului se va testa si implementa si se

va lua de la capăt.
Ingineria + Fiecare fază se consumă un timp mai scurt, după care urmează
cerințelor mai multe iteraţii prin toate fazele
+ În final, după câteva cicluri, sistemul este complet şi gata de
lansare
Proiectarea - Procesul poate însă continua pentru lansarea mai multor versiuni
arhitecturala ale produsului.
Proiectarea
detaliata
Implementare
Testarea
unităților
Testarea
sistemului
Ingineria
cerințelor
o Modelul
în spirală. Exemple de riscuri:
- O firma concurentă lansează un produs rival.
+ Păstrează avantajele modelului în cascadă. - Un programator părăsește echipa.
+ Ia ˆîn calcul noțiunea de risc. - Clientul schimbă cerințele.
- O echipă nu respectă termenele de livrare.
1. Pregătirea 2. Gestiunea riscului

take stock dealing with risk
4. Planificarea
3. Dezvoltarea
următorului stagiu development
planning
o Modelul
ecluză. (watersluice) + Preia natura iterativă a metodologiei spirală, la care adaugă progresul sigur
al metodologiei cascadă
+ Echipele nu sunt blocate într-o serie de cerinţe sau într-o arhitectură imobilă
care se pot dovedi mai târziu inadecvate sau chiar greşite
+ Pentru respectarea termenelor limită, impune date de îngheţare a unor faze
- Presupune asumarea unor responsabilităţi privind delimitarea etapelor şi
îngheţarea succesivă a fazelor de dezvoltare.
- Presupune crearea unui mediu de lucru în care acceptarea responsabilităţii
pentru o decizie care se dovedeşte mai târziu greşită să nu se repercuteze în
mod negativ asupra individului
Ingineria
cerințelor
Proiectarea
Proiectarea
arhitecturala
arhitecturala
Proiectarea
Proiectarea
detaliata Implementare
detaliata Testarea
Testarea unităților
Implementare
Implementare
unităților Testarea
Produs
Testarea Testarea Testarea sistemului
unităților unităților sistemului
Testarea Testarea
sistemului sistemului
Ingineria
cerințelor
o Modelul V̂. + Dezvoltat pentru reglementarea dezvoltării de software în administraţia

federală germană.
+ Evidenţiază testarea pe tot parcursul ciclului de dezvoltare.
+ Trecerea la faza următoare se face numai după ce toate produsele din
faza curentă au trecut testele de verificare şi validare
+ Procesul de verificare şi validare are scopul detectării cât mai multor
erori în ciclul de dezvoltare
.
Faze descendente Faze ascendente

Ingineria Ingineria
cerințelor cerințelor
Proiectarea Testarea
arhitecturala sistemului
Proiectarea Testarea
detaliata unităților
Implementare
o Modelul sursă la vedere (Ôpen Source).

 O abordare recentă, apărută ca urmare a dezvoltării mijloacelor de comunicaţie: FTP, e-mail, grupuri de discuţie
 Exemple clasice: sistemul de operare Linux, Amarok, aTunes, Firefox, Apache OFBiz etc.
 Codul sursă este transmis utilizatorului final într-o manieră non-proprietară (fără patent), pe baza unei licenţe open-
source (gen GNU)
Proiectarea
arhitecturala
Proiectarea
Ingineria Server OS detaliata
cerințelor
Implementare
Testarea
unităților
Testarea
sistemului
Ingineria
cerințelor
11) Prototipizare.
Tipuri de prototipuri
 De aruncat (throw-away)
Scop: clarificarea specificaţiilor
Se dezvoltă repede, orice altceva e secundar (quick-and-dirty)
Util în a rezolva “architecural/technology spikes”
Programul “adevărat” este scris apoi de la 0
 Evoluţionar
Scop: construire incrementală a produsului final
Se construieşte un nucleu funcţional la care se adaugă apoi noi funcţionalităţi
+ Se poate elimina lipsa de claritate a specificaţiilor

+ Clienţii pot schimba cerinţele (e ieftin de gestionat)
+ Întreţinere ieftină (verificare pe parcurs)
+ Se poate facilita instruirea utilizatorilor
- Mediu artificial, probleme ascunse
- Da' nu-i aproape gata?! De ce mai durează atât?
- Putem să schimbăm specificaţiile? Pai aş vrea şi...
- Adică munca mea este aruncată la gunoi?
12) Rational Unified Process (R̂UP).

 Model iterativ folosit de IBM din 2003
 Ingineria funcționalității. Sunt sintetizate necesităţile funcţionale.
Are la baza 4 etape:
◦ Inception: pentru validarea costurilor și bugetului, studiu de risc, înțelegerea cerințelor.
◦ Elaboration: analiza domeniului problemei, arhitectura proiectului este stabilită.
◦ Construction: construcția sistemului, se obţine prima versiune a sistemului.
◦ Transition: tranziţia la sistemul din producţie.
http://fedir.github.io/web/2014/05/19/rup/
Bibliografie:
• Ovidiu Gheorghieş:
http://www.infoiasi.ro/~ogh/files/ip/curs-01.pdf
• Adrian Iftene:
http://thor.info.uaic.ro/~adiftene/Scoala/2012/IP/
• Andy Kramek, New Software - Build or Buy?
A Personal View:
http://weblogs.foxite.com/andykramek/archive/2009/07/25/8674.aspx
Links:
• Internet
• Wikipedia
• Failure rate: http://www.it-cortex.com/Stat_Failure_Rate.htm
• RUP: http://fedir.github.io/web/2014/05/19/rup/

UAV Ingineria Programarii - Serban Ovidiu

Încărcat de

Informații document

Titlu original

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

UAV Ingineria Programarii - Serban Ovidiu

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA “AUREL VLAICU” DIN ARAD Student: Șerban Ovidiu Florin

FACULTATEA DE STIINŢE EXACTE

Student: Șerban Ovidiu Florin

1. Introducere în ingineria programării.

o În anul 1946 Goldstine şi von Neumann apreciau că 1000 de instrucţiuni

o Sistemul de rezervare a biletelor pentru compania aeriană KLM conţinea,

o După ce a prevăzut în 1981 că nici un program pentru calculatoare

o In anul 1949 o revistă de popularizare a ştiinţei afirma că în viitor ar putea

o In anul 1983 a fost introdusă o definiție mai recenta:

o ro.wikipedia.ro spune: (http://ro.wikipedia.org/wiki/Inginerie_software)

o Pierdere vehicul explorare Venus. Problema era intr-un “FOR”....

o Unele sisteme integrate din aparatele de radioterapie au administrat doze

o Sistem de avertizare anti-rachetă activat. Atacam sau nu?

o În anul 1979 s-a descoperit o eroare în programele pentru sistemele de

o Ariane 5 explodează in 1996. Costurile s-au ridicat la : 500.000.000 $

4. Costurile destinate programelor.

6. Scopul ingineriei programării.

o Inginerii programatori trebuie să adopte o manieră de lucru sistematică şi

7. Siguranța si securitatea programelor.

8. Cerințele unui produs software

o Interfaţa trebuie sa fie ușor de utilizat.

9. Fazele fundamentale ingineriei programării.

10. Modele de dezvoltare software.

Proiectarea - Nu există mecanisme de reparare a erorilor.

o Modelul ĉiclic. + După fiecare modificare a codului se va testa si implementa si se

1. Pregătirea 2. Gestiunea riscului

o Modelul V̂. + Dezvoltat pentru reglementarea dezvoltării de software în administraţia

Faze descendente Faze ascendente

o Modelul sursă la vedere (Ôpen Source).

+ Se poate elimina lipsa de claritate a specificaţiilor

12) Rational Unified Process (R̂UP).

S-ar putea să vă placă și