Ingineria Programarii

UNIVERSITATEA “AUREL VLAICU” DIN ARADFACULTATEA DE STIINŢE EXACTEDOMENIUL INFORMATICĂ

Student: Șerban Ovidiu Florin

Student: Șerban Ovidiu FlorinUNIVERSITATEA “AUREL VLAICU” DIN ARADFACULTATEA DE STIINTE EXACTEDOMENIUL INFORMATICA AN: 3Curs: Ingineria programăriiProfesor: Dominic Bucerzan


Ingineria programării



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 & Singer18 proiecte

Motivele eşecurilor◦ Probleme de organizare◦ Noile metode de lucru şi politicile salariale◦ Modificările neprevăzute în afacere

19%

31%12%

25%

12%Succes: 17%Parţial în folosinţă: 28%Satisfacătoare: 11%Eşec: 22%Neevaluate: 11%



33%

42%

25%

Succes: 33%Cu probleme: 42%Eşec: 25%

Statistici. Studii de succes: USA’82 - Gibson & SingerDin peste 100 proiecte

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 softwareo Î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:

AnalizaCe dorim sa construim

Proiectarea Cum vom construi

Implementarea Construirea propriu-zisă

TestareaAsigurarea calităţii



Analizao Această fază defineşte cerinţele sistemului, independent de modul în care acestea vor fi îndepliniteo 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

Proiectareao 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

Implementareao În această fază este construit sistemul, ori plecând de la zero, ori prin asamblarea unor componente pre-existenteo Scopul este producerea sistemului propriu-zis

Testareao Asigură calitatea produsului softwareo Scopul este realizarea unui produs competitivo 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ă�

Ingineriacerinţelor

Proiectareaarhitecturala

Proiectareadetaliata

Implementare

Testareaunităţilor

Testareasistemului


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

- Nu există mecanisme de reparare a erorilor.



o Modelul în cascadă cu întoarcere.�Ingineriacerinţelor



Implementare


Testareasistemului


+ Oferă cadrul pentru remedierea erorilor din pasul precedent.- Erorile la pasul i care sunt descoperile la pasul i + 2 nu sunt remediate.- Clientul vede produsul final abia la sfârșitul dezvoltării.



o Modelul �ciclic.




Implementare


Testareasistemului


+ După fiecare modificare a codului se va testa si implementa si se va lua de la capăt.+ Fiecare fază se consumă un timp mai scurt, după care urmează mai multe iteraţii prin toate fazele+ În final, după câteva cicluri, sistemul este complet şi gata de lansare- Procesul poate însă continua pentru lansarea mai multor versiuni ale produsului.



o Modelul în spirală.�

1. Pregătireatake stock

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.

4. Planificareaurmătorului stagiu

planning

3. Dezvoltareadevelopment

2. Gestiunea risculuidealing with risk

+ Păstrează avantajele modelului în cascadă.�+ Ia �în calcul noţiunea de risc.



o Modelul ecluză. � (watersluice)




Implementare


Testareasistemului


+ 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



Implementare


Testareasistemului


Testareasistemului

ImplementareTestareaunităţilor

Testareasistemului

Produs



o Modelul V.�




Implementare


Testareasistemului


+ 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



o Modelul sursă la vedere (Open Source� ).




Implementare


Testareasistemului


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)

Server OS



o 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?



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

http://fedir.github.io/web/2014/05/19/rup/



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/

http://www.infoiasi.ro/~ogh/files/ip/curs-01.pdf

http://www.infoiasi.ro/~ogh/files/ip/curs-01.pdf

http://thor.info.uaic.ro/~adiftene/Scoala/2012/IP/

http://thor.info.uaic.ro/~adiftene/Scoala/2012/IP/

http://weblogs.foxite.com/andykramek/archive/2009/07/25/8674.aspx

http://weblogs.foxite.com/andykramek/archive/2009/07/25/8674.aspx

http://www.it-cortex.com/Stat_Failure_Rate.htm

http://www.it-cortex.com/Stat_Failure_Rate.htm



Date post:	17-Jul-2016
Category:	Documents
Upload:	darius-moti
View:	77 times
Download:	0 times

Ingineria Programarii

Documents