NUME ȘI PRENUME: CARABADACHE (NEICU) RAMONA GEORGIANA

DISCIPLINA: INGINERIE SOFTWERE

DATA ÎNSCRIERII: OCTOMBRIE 2019 - 4 SEMESTRE

INGINERIE SOFTWERE

Ingineria sistemelor de programare sau ingineria software, sub alta denumire, este o
disciplina care se ocupa de toate aspectele productiei software cum ar fi dezvoltare, exploatare
si intretinere.
Economiile tuturor tarilor dezvoltate depind de software, tot mai multe sisteme fiind
controlate de programe.
Ingineria software se ocupa cu teorii, metode si instrumente pentru dezvoltarea
software profesionala, cheltuieleile legate de software reprezentand un procent semnificativ in
toate tarile dezvoltate. Costurile software depasesc de cele mai multe ori costurile legate de
hardware iar costurile de intretinere ale unui program sunt mai mari decat de cele de
dezvoltare depasind uneori de cateva ori costurile de dezvoltare.
Produsele software pot fi dezvoltate pentru a satisface o piata generala – Generice -
pentru a fi vandute unei game largi de utilizatori (Excel, Word) sau pot fi Dedicate -
dezvoltate pentru un singur client in conformitate cu cerintele clientului.
Pentru ca un software sa fie considerat de calitate el trebuie sa ofere functionalitatea si
performanta ceruta de client si sa fie mentenabil (sa evolueze pentru a fi in pas cu
schimbarile), fiabil si acceptat de acesta (sa fie usor de inteles, utilizabil si compatibil cu alte
sisteme).
Termenul de inginerie software a apărut pentru prima dată în 1968 la Conferinta de
Inginerie Software a NATO ( NATO Software Engineering Conference ). De atunci, a
continuat ca o profesie şi domeniu de studiu dedicat la crearea de software de o calitate mai
mare, mai accesibila de întreţinut, şi mai rapid de construit. Având în vedere că domeniul este
încă relativ mic, există încă multe dezbateri în jurul ingineriei software, dacă aceasta este
conformă cu definiţia clasică a ingineriei sau daca aceasta este doar programare.
Cand primul calculator modern a aparut in 1940, instructiunile pentru a-l face operabil
erau cablate in interiorul masinii, dezvoltatorii au realizat rapid ca acesta nu este un sistem
flexibil si au implementat arhitectura stocarii programelor sau arhitectura von Neumann.
Limbajele de programare au început să apară în anii 1950 şi acest lucru a fost, de asemenea,
un alt pas major. Limbaje majore, cum ar fi Fortran, Algol, precum şi Cobol au fost lansate la
sfârşitul anilor 1950 pentru a face faţă problemelor ştiinţifice, algoritmice precum şi
problemelor de afaceri iar in 1969 a fost introdus un sistem software de gestionare a
hardware-ul numit sistem de operare Unix.
Aceste progrese în domeniul software s-au întâlnit cu mai multe progrese în hardware-
ul computerului. La mijlocul anilor 1970, a fost introdus pe piata microcalculatorul, accesibil
ca pret pentru pasionaţi si usor de scris software-ul pentru acesta. Aceasta la rândul său duce
la aparitia celebrului computer personal sau PC-ul şi sistemului de operare Microsoft
Windows. La sfârşitul anilor 1970 şi începutul anilor 1980 apar noi limbajele de programare:
C + +, Smalltalk, Obiectiv C.
Software open-source au început să apară la începutul anilor 90, sub formă de Linux şi alte
programe iar Internetul şi World Wide Web au lovit în mijlocul anilor 90 schimband ingineria
programarii din nou.
În timp ce unele zone cum ar fi Alberta, Ontario si Quebec, Canada, licentiaza inginerii de
software, cele mai multe locuri din lume nu au nici o lege în ceea ce priveşte profesia de
ingineri software. Cu toate acestea, există unele ghiduri de la IEEE Computer Society şi
ACM, principalele două organizaţii profesionale de inginerie software.: Ghidul IEEE "Guide
to the Software Engineering Body of Knowledge" versiunea 2004 sau SWEBOK definesc
domeniul şi oferă o acoperire de cunoştinţe practice pe care inginerii de software ar trebui să
le aibă.
Cei mai multi ingineri software lucreaza ca angajaţi sau contractori cu intreprinderi,
agenţii guvernamentale (civile sau militare), precum şi cu organizaţii non-profit iar unii
ingineri software lucreaza pentru ei înşişi ca liber-profesionişti. Unele organizaţii au
specialişti pentru a efectua fiecare din sarcinile din procesul de dezvoltare software, alte
organizaţii au nevoie de ingineri software pentru a face mai multe sau toate dintre ele. În
proiectele mari, oamenii pot fi specializati într-un singur rol, in proiectele mici oamenii pot
umple mai multe sau toate rolurile în acelaşi timp, specializarile incluzand: analişti, arhitecţi,
dezvoltatori, testeri, tehnicieni, manageri ( industrie ) şi cadre didactice, cercetători ( mediul
academic ).
Nu există dezbateri considerabile asupra perspectivelor viitoare de angajare pentru
ingineri software şi a altor profesionişti IT. ACM a avut un program de certificare
profesionala la începutul anilor 1980 care a fost întrerupt din cauza lipsei de interes. ACM a
examinat posibilitatea de certificare profesionala de ingineri software la sfârşitul anilor 1990,
dar în cele din urmă a decis că această certificare a fost inadecvata pentru practica
profesională industrială a software-ului de inginerie. Cele mai multe programe de certificare
din industria IT sunt orientate spre tehnologii specifice şi care sunt gestionate de către
vânzătorii acestor tehnologii. Aceste programe de certificare sunt adaptate pentru instituţii
care ar angaja oameni care folosesc aceste tehnologii.
Dezvoltarea software-ului orientat obiect include cinci activităţi: cerinţele elicitation
analiza, design-ul sistemului, design-ul obiectului şi implementarea. În timpul acestor cerinţe
şi analize inginerii software formulează problema clientului şi creează modelul domeniului de
aplicare. Cerinţele elicitation şi analiza corespund paşilor 1 şi 2 din metoda ingineriei.
Pe parcursul design-ului sistemului inginerii software analizează problema, o
descompun şi selectează strategii pentru design-ul sistemului. Pe parcursul design-ului
obiectului, ei selectează soluţiile pentru fiecare piesă şi decide asupra soluţiei potrivite.
Design-ul sistemului şi obictului rezultă în modelul domeniului soluţiilor. Design-ul
obiectului şi sistemului corespunde paşilor 3 şi 4 ale metodei ingineriei. Pe parcursul
implemetării inginerii software realizează sistemul prin transformarea modelului domeniului
soluţiilor într-o reprezentare executabilă. Implementarea corespunde pasului 5 al metodei.
Ceea ce deosebeşte ingineria software de alte ştiinţe în ceea ce priveşte problem solving este
că schimbarea are loc în aplicaţii şi în domeniul soluţiilor timp în care problema este
rezolvată.
 Dezvoltarea software include activităţi a căror scop este de a evalua potrivirea
modelelor respective. În timpul revizualizării analizei modelul domeniului de aplicaţie este
comparat cu realitatea clientului care poate fi schimbată ca un rezultat al modelării. În timpul
revizualizării design-ului modelul domeniului soluţiilor este evaluat faşă de scopurilor
proiectului.
În timpul testării sistemul este validat faţă de modelullui domeniului soluţiilor care poate fi
schimbat prin introducerea unor noi tehnologii. În timpul conducerii proiectului, managerii îşi
compară modelele proceselor de dezvoltare cu realitatea.
O greşeală comună pe care inginerii software şi managerii o fac este de a presupune că
dobândirea cunoştinţelor necesare dezvoltarii sistemelor este constantă. Această greşeală nu
este făcută doar de managerii software; poate găsită şi în alte domenii.
În secolul al XVII-lea a fost publicată o carte utilizată pentru predare, care ajuta
studenţii să înveţe poemele germane, în şase ore “băgându-le cu pâlnia”. Idea utilizării pâlniei
pentru învăţare este bazată pe o presupunere răspândită, şi anume că mintea noastră este o
“găleată”, care iniţial este goală, dar care poate fi umplută constant. În mintea noastră intră
informaţii prin simţuri, sunt accumulate şi sunt digerate. Popper numeşte acest model de
dobândire constantă a cunoştinţei : “Teoria găleţii minţii”. Printre multe alte lucruri care sunt
greşite în această teorie este presupunerea că şi cunoştinţa este concepută ca o sumă de
lucruri care pot umple o găleată.
Knowledge acquisition este un proces variabil. Adăugare unor noi piese de
informaţii pot invalida toate cunoştinţele pe care le-am dobândit pentru înţelegerea sistemului.
Chiar dacă am argumentat această înţelegere în documente şi cod, trebuie să fim pregătiţi
mental să începem de la notiţe. Aceasta are implicaţii importante asupra setului de activităţi şi
interacţiunile lor pe care le definim în dezvoltarea sistemului software. Echivalentul “Teoriei
găleţii minţii ” este modelul secvenţial de tip cascadă pentru dezvoltarea software în care toţi
paşii metodei ingineriiei sunt îndepliniţi secvenţial.
Există câteva procese software care se confruntă cu această problemă prin evitarea
dependenţelor secvenţiale inerente în modelul cascadă. Dezvoltarea bazată pe risc încearcă să
anticipeze surprizele târzii din proiect prin identificarea componentelor de mare risc.
Dezvoltarea bazată pe problemă încearcă să înlăture liniaritatea în întregime. Orice activitate
de dezvoltare-analiză,design-ul sistemului, obiectului, implementare testare sau livrare- pot
influenţa orice altă activitate. În dezvoltarea bazată pe problemă toate aceste activităţi sunt
executate în parallel. Dificultatea modelelor dezvoltate nesecvenţial este că sunt greu de
condus.
Dezvoltarea unui soft cere colaborarea mai multor persoane cu diferite bagaje de
cunostinţe şi cu interese diferite. Clientul cere şi plăteşte pentru sistem. Programatorii
realizează sistemul. Managerul de proiect planifică bugetele de proiect şi coordonează
programatorii. Ne referim la toate persoanele implicate în proiect ca şi participanţi. Ne referim
la un set de responsabilităţi în cadrul proiectului sau sitemului ca şi un rol. Un rol este asociat
cu un set de operaţiuni şi este atribuit unui participant. Acelaşi partiicipant poate avea mai
multe roluri.
Pe parcursul proiectări sistemului dezvoltatorii definesc scopurile designului pentru
proiectul respectiv şi descompun sistemul în subsisteme mai mici care pot fi realizate pe
echipe. Dezvoltatorii selectează şi strategiile de construire a sistemului, cum ar fi hardware-ul
şi platforma pe care urmează să ruleze sistemul, strategiile de management al datelor,
controlul fluxului global, politicile de control al accesului şi limitele condiţilor. Rezultatul
designului sistemului este o descriere clară a fiecărei din aceste strategii, o descompunere în
subsisteme şi o diagramă de desfăşurare reprezentând maparea hardware/software a
sistemului. In timp ce atât analiza cât şi designul sistemului realizează modele ale sistemului
aflat în construcţie, doar analiza foloseşte entităţi ce pot fi înţelese de client. Designul
sistemului foloseşte modele mult mai rafinate care includ entităţi care sunt dincolo de limita
de înţelegere(şi interes) a clientului.
Pe parcursul proiectării obiectelor, dezvoltatorii definesc obiectele domeniului soluţiei
pentru a acoperii golul dintre modelul analizei şi platforma hardware/software definită in
timpul proiectării sistemului. Aceasta include descrierea exactă a obiectelor şi a interfeţelor
subsistemelor, restructurarea modelului obiectual pentru a atinge unele scopuri ale proiectării,
cum ar fi extensibilitatea şi înţelegerea facilă şi optimizarea modelului obiectual pentru
performanţă. Rezultatul activităţii de proiectare a obiectelor este un model detaliat al
obiectelor adnotat cu constrângeri şi descrieri precise ale fiecărui element.
Pe parcursul implementării dezvoltatorii transpun modelul domeniului soluţiei în cod
sursă. Aceasta cuprinde implementarea atributelor şi a metodelor pentru fiecare obiect şi
integrarea tuturor obiectelor astfel încât acestea să funcţioneze ca un sistem unitar. Activitatea
de implementare acoperă golul dintre(span de gap) modelul obiectual detaliat şi setul complet
de cod sursă ce poate fi compilat. Se presupune că cititorul este deja familiarizat cu
conceptele de programare şi ştie cum să creeze structuri de date şi algoritmi folosind un
limbaj orientat obiect cum ar fi Java sau C++.
Pe parcursul testării dezvoltatorii găsesc diferenţe între sistem şi modelul său prin
utilizarea sistemului folosind date de intrare de probă. In timpul testării dezvoltatorii compară
designul modelului obiectelor cu fiecare obiect şi subsistem. In timpul testării integrate,
combinaţii de subsisteme sunt comparate cu designul modelului sistemului. Pe parcursul
testării sistemului, situaţii tipice şi excepţionale sunt rulate prin sistem iar rezultatele sunt
comparate cu modelul ceriţelor. Scopul testării este de a găsii cât mai multe erori pentru a
putea fi reparate înainte de a livra produsul. Planificarea fazelor de testare are loc în paralel cu
alte activităţi de dezvoltare: testarea sistemului se planifică pe parcursul obţinerii cerinţelor şi
a analizei, testarea integrată se planifică atunci când se crează designul sistemului, iar testarea
unităţilor se planifică în timpul designului obiectelor
Inginerii se confruntă cu greutăţi în activitatea de modelare, ei trebuind să fie atenţi la
orice moment doar pe detaliile relevante şi ignorând toate celalalte. Pe parcursul procesului de
dezvoltare, inginerii programatori construiesc diverse modele ale sistemului şi ale domeniului
de aplicare
SE este o activitate de rezolvare a unor probleme. Modelele sunt utilizate pentru a căuta
soluţii acceptabile. Inginerii nu au resurse infinite şi sunt constrânşi de buget şi de termenele
limită. Datorită slabelor cunoştinţe, ei de multe ori trebuie să se bazeze pe metode empirice
pentru a evalua avantejele diferitelor metode.
SE este o activitate de acumulare a cunoştinţelor.În modelarea aplicaţiilor şi a soluţiilor
domeniului, inginerii colectează date, le organizează în informaţii şi le dau forma de
cunoştinţe.
SE este o activitate de conduită raţională. Când adună cunoştinţe şi iau decizii despre sistem
sau domeniile lui de aplicare, inginerii trebuie de asemena să se încadreze în contextul în care
aceştia iau deciziile. Informaţiile raţionale, reprezentate ca un set de modele, le permit
inginerilor să înţeleagă implicaţiile unei presupuse schimbări când se revizuieşte o problemă.
Activităţile de management se concentrează pe planificarea proiectului, monitorizarea
şituaţiei, urmarirea schimbărilor, şi coordonarea resurselor în aşa fel încât un produs de înaltă
calitate să fie livrat la timp şi în limitele bugetului. Activităţile de management nu implică
doar existenţa managerilor, ci şi marea majoritate a participanţilor la proiect. Activităţiile de
management includ:
 comunicare
 management relaţional
 management de configurare software
 management de proiect
 ciclul de viaţă al software-ului
Mentenanţa software, care nu este tratată în aceasta carte, include activităţile de
dezvoltare care apar dupa livrarea sistemului la client. În mod tradiţional, mentenanţa
software-ului a fost diferentiata de alte activităţi de dezvoltare întrucat este foarte deschisă
spre schimbări şi este realizată de o altă echipă diferită de echipa care l-a dezvoltat iniţial.
Deoarece proiectele moderne de inginerie software devin din ce în ce mai deschise spre
schimbări, distingerea activităţilor de construcţie de cele de întreţinere devin tot mai neclare.
Multe din activităţile descrise în aceasta carte pot trece la mentenanţă, inclusiv designul de
obiecte, implementarea, testarea, management raţional, şi managementul de configurare
software.
1 Comunicarea
Comunicarea este cea mai critică activitate şi care consuma cel mai mult timp în
ingineria software. Neînţelegerile şi omisile duc deseori la greşeli şi întârzieri a căror
corectare costă mult în procesul de dezvoltare ulterior. Comunicarea include schimbul de
modele şi documente despre sistem şi domeniul de aplicare a acestuia, raportarea situaţiei al
produsului în lucru, oferirea de feedback în legatură cu calitatea produsului aflat în lucru,
enunţarea şi rezolvarea problemelor, şi comunicarea deciziilor. Comunicarea este greoaie
datorită diversitatii situatiilor participanţilor, distribuirea geografică şi volumul, complexitatea
şi evoluţia informaţiei schimbate.
Pentru a trata problemele legate de comunicare, participanţii la proiect au multe unelte
la dispoziţie. Cea mai bună este convenţia: când participanţii se pun de acord cu anumite
notaţii pentru a reprezenta informaţii, cu uneltele folosite la manipularea informaţiei, şi
procedurile de ridicare şi rezolvare a problemelor, elimină o mare parte din sursele cauzatoare
de neînţelegeri. Exemplele de notaţii includ diagramele UML, template-uri pentru scrierea
documentelor şi a discursurilor, şi identificarea schemelor pentru numirea componentelor
software. Exemplele de unelte includ Computer Aided Software Engineering (CASE), unelte
pentru mentenanţa modelelor, procesoare de cuvinte pentru generarea documentelor, şi
transformarea formatelor pentru publicarea informaţiei. Exemplele de proceduri includ
întâlnirea procedurilor de organizare, conducere, şi salvarea unei întâlniri, proceduri de
revizuire pentru revizuirea documentelor şi oferirea de feedback, şi inspectarea procedurilor
pentru detectarea defectelor în modele sau în codul sursă. Convenţiile alese nu trebuie să fie
cele mai bune; trebuie doar să fie impărţite şi acceptate de toţi.
2 Managementul Rational
Raţionarea este justificarea deciziilor. Raţiunea unei decizii luate include problema
careia i se adreseaza, alternativele care develop-erii le-au luat în considerare, criteriul folosit
de develop-eri pentru evaluarea deciziilor, dezbaterea realizată de develop-eri pentru
obţinerea consensului, şi a deciziilor. Rationarea este cea mai importantă informaţie de care
au nevoie developerii cand schimbă sistemul. Dacă un criteriu se schimbă, developerii pot
reevalua toate deciziile care depind de acest criteriu. Daca apare o nouă alternativă, poate fi
comparată cu toate celelălte alternative care au fost deja evaluate. Daca decizia nu este clară,
pot apela la raţiune pentru a o justifica.
Din păcate, raţiunea este de asemenea cea mai complexă informaţie cu care au de-a
face developerii în procesul de dezvoltare, şi deci, este cel mai greu de înnoit şi întreţinut.
Pentru a face faţă acestei provocări, developerii prind raţiunea în timpul întîlniriilor şi a
discuţiilor on-line, prezintă raţiunea cu modele problematice, şi accesează raţiunea în timpul
schimbărilor.
3. Managementul de configurare software
Managementul de configurare software este procesul care monitorizeaza şi controlează
schimbăriile din produsele aflate în lucru. Shimbările îngreunează dezvoltarea programelor.
Cerinţele se schimbă în momentul în care clientul cere noi elemente când pe masură ce
developerii înteleg mai bine domeniul de aplicare. Platforma hardware/software pe care
sistemul este construit se schimbă îndată ce apar noi tehnologii. Schimbările de sistem ca şi
greşeli, sunt descoperite la testare şi sunt reparate. Managementul de configurare software era
plasat în partea de mentenanţă, cand îmbunătăţirile erau incremental introduse in sistem. În
procesul modern de dezvoltare, schimbările apar mai devreme decat mentenanţa. Totuşi
schimbările din dezvoltare pot fi făcute în orice etapă. Managementul de configurare permite
developerilor sa ţină evidenţa schimbărilor. Sistemul este reprezentat ca fiind un numar de
elemente de configurare care sunt revizuite individual. Pentru fiecare element de configurare,
evolutia lui este urmarită ca o serie de versiuni. Selectarea unei versiuni permite developerilor
să se întoarcă la o situatie bine definită a sistemului cand o schimbare cedează.
Managementul de configurare de asemenea permite developerilor să controleze
schimbările. Dupa ce a fost definită o linie de bază orice schimbare trebuie verificată şi
aprobata înainte să fie implementată. Acest lucru permite managementului sa asigure o
evolutie a sistemului în concordanţă cu scopul proiectului şi că numărul de probleme
introduse în sistem sunt limitate.
Administrarea proiectului
Se ocupă de supraveghera activităţilor ca acestea sa rămână în limitele timpului şi de buget.
Aceasta include planificarea şi împărţirea bugetului pe proiect pe masura negocierilor cu
clientul, angajarea de programatori şi organizarea acestora în echipe, monitorizarea stadiilor
proiectului şi intervenirea cand proiectul deraiază de la calea impusă