REFERAT

INGINERIA PROGRAMĂRII
INTRODUCERE ÎN INGINERIA PROGRAMĂRII .

Student: Șerban Ovidiu Florin

UNIVERSITATEA “AUREL VLAICU” DIN ARAD
FACULTATEA DE STIINŢE EXACTE
DOMENIUL INFORMATICĂ
AN: 3
Profesor: Dominic Bucerzan

Cuprins.
1) Introducere în ingineria programării. ............................................................................................................ 2
2) Definiție ............................................................................................................................................................. 2
- Statistici 18 proiecte ....................................................................................................................................... 2
- Statistici, peste 100 proiecte .......................................................................................................................... 3
3) Greșeli celebre ................................................................................................................................................ 3
4) Costurile destinate programelor ................................................................................................................... 3
5) Nevoia de programe ....................................................................................................................................... 4
6) Scopul ingineriei programării......................................................................................................................... 4
7) Siguranța si securitatea programelor ........................................................................................................... 4
8) Cerințele unui produs software ..................................................................................................................... 4
9) Fazele fundamentale ingineriei programării. .............................................................................................. 5
- Analiza ........................................................................................................................................................ 5
- Proiectarea ................................................................................................................................................. 5
- Implementarea ........................................................................................................................................... 5
- Testarea ...................................................................................................................................................... 5
10) Modele de dezvoltare software. ................................................................................................................. 6
Modelul în cascadă ........................................................................................................................................... 6
Modelul în spirală............................................................................................................................................. 7
Modelul ecluză. (watersluice) ......................................................................................................................... 8
Modelul V .......................................................................................................................................................... 8
Modelul sursă la vedere (Open Source) ......................................................................................................... 9
11) Prototipizare. ................................................................................................................................................. 9
12) Rational Unified Process (RUP). .............................................................................................................. 10
13) Bibliografie. .................................................................................................................................................. 10
UNIVERSITATEA “AUREL VLAICU” DIN ARAD
FACULTATEA DE STIINŢE EXACTE
DOMENIUL INFORMATICĂ

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 )

Î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.
Sistemul de rezervare a biletelor pentru compania aeriană KLM conţinea, în anul 1992, două milioane de linii
de cod în limbaj de asamblare.
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.
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) Definiție
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 )

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)

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 18 proiecte
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% Succes: 17%

19%
25%
Parţial în
32%
12% folosinţă: 28%
Satisfacătoare:
11%
Motivele eşecurilor
◦ Probleme de organizare
◦ Noile metode de lucru şi politicile salariale
◦ Modificările neprevăzute în afacere

Page 2
UNIVERSITATEA “AUREL VLAICU” DIN ARAD
FACULTATEA DE STIINŢE EXACTE
DOMENIUL INFORMATICĂ

- Statistici, peste 100 proiecte

Studii de succes: USA’82 - Gibson & Singer - Din peste 100 proiecte

Motivele eşecurilor
◦ Slaba pregătire a inginerilor software
◦ Resurse insuficiente
◦ Probleme de management

3) Greșeli celebre
Sistemul de operare IBM OS360 conținea la fiecare relansare 1.000 de greșeli.

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

Unele sisteme integrate din aparatele de radioterapie au administrat doze letale de radiaţii pacienţilor.

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

Î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.

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

4) Costurile destinate programelor

Aproape toate costurile programelor domină deseori costurile sistemelor computerizate.

Întotdeauna costurile de software pe un PC sunt mai mari decât costurile de hardware.

Întreţinerea programelor costă mai mult decât dezvoltarea lor.

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.

Este necesară dezvoltarea de programe cât mai eficientă din punct de vedere financiar.

Page 3
UNIVERSITATEA “AUREL VLAICU” DIN ARAD
FACULTATEA DE STIINŢE EXACTE
DOMENIUL INFORMATICĂ

5) Nevoia de programe
In general economia tuturor statelor dezvoltate depinde de sisteme informatice bine puse la punct.
Tot mai multe mai multe sisteme de siguranța sunt controlate de calculator.
Este necesară identificarea de teorii, metode şi instrumente pentru dezvoltarea profesionistă de programe.

6) Scopul ingineriei programării

Ingineria programării are ca scop proiectarea si producţia de software.

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

Un program este sigur dacă funcţionează corect, fără operaţii nedorite si inutile.
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.
Securitatea se referă la faptul că un sistem nu trebuie să permită utilizarea neautorizată şi că se poate proteja
împotriva atacurilor.
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

Întreținere cu costuri scăzute.
Programele cu ciclul lung de viaţă sunt supuse deseori modificărilor, de aceea trebuie foarte bine documentat.

Eficienţa.
Produsul nu trebuie să folosească în pierdere resursele sistemului.

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

Interfaţa trebuie să ţină seama de capacitatea şi cunoştinţele utilizatorilor.

Instruire.
Acces rapid la documentația produsului cu un “help” cat mai eficient.

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.

Page 4
UNIVERSITATEA “AUREL VLAICU” DIN ARAD
FACULTATEA DE STIINŢE EXACTE
DOMENIUL INFORMATICĂ

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
Această fază defineşte cerinţele sistemului, independent de modul în care acestea vor fi îndeplinite
Se defineşte problema pe care doreşte să o rezolve clientul.
Rezultatul este documentul cerinţelor, care trebuie să precizeze clar ce trebuie construit.

- Proiectarea
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
În această fază este construit sistemul, ori plecând de la zero, ori prin asamblarea unor componente pre-
existente.
Scopul este producerea sistemului propriu-zis.

- Testarea
Asigură calitatea produsului software.
Scopul este realizarea unui produs competitiv.
Un produs performant creşte satisfacţia clienţilor, iar funcţionalitatea poate fi dezvoltată în versiuni ulterioare.
Page 5
UNIVERSITATEA “AUREL VLAICU” DIN ARAD
FACULTATEA DE STIINŢE EXACTE
DOMENIUL INFORMATICĂ

10) Modele de dezvoltare software.

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

Proiectarea
arhitecturala

Proiectarea
detaliata

Implementare

Testarea
unităților
Testarea
sistemului

Page 6
UNIVERSITATEA “AUREL VLAICU” DIN ARAD
FACULTATEA DE STIINŢE EXACTE
DOMENIUL INFORMATICĂ

Modelul în spirală.

+ Păstrează avantajele modelului ˆîn cascadă.
+ Ia ˆîn calcul noțiunea de risc.
Exemple de riscuri:
- O firma concurentă lansează un produs rival.
- Un programator părăsește echipa.
- 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

Page 7
UNIVERSITATEA “AUREL VLAICU” DIN ARAD
FACULTATEA DE STIINŢE EXACTE
DOMENIUL INFORMATICĂ

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

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

Page 8
UNIVERSITATEA “AUREL VLAICU” DIN ARAD
FACULTATEA DE STIINŢE EXACTE
DOMENIUL INFORMATICĂ

Modelul sursă la vedere (Open 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)

11) Prototipizare.
Tipuri de prototipuri
De aruncat (throw-away)

ce altceva e secundar (quick-and-dirty)

Evoluţionar

augă 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?

Page 9
UNIVERSITATEA “AUREL VLAICU” DIN ARAD
FACULTATEA DE STIINŢE EXACTE
DOMENIUL INFORMATICĂ

12) Rational Unified Process (RUP).

 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.

13) Bibliografie.
Biografie:
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/

Page 10