+ All Categories
Home > Documents > inginerie hatz

inginerie hatz

Date post: 13-Apr-2016
Category:
Upload: demiii
View: 71 times
Download: 2 times
Share this document with a friend
Description:
hatz
75
Mentenanța produselor software
Transcript
Page 1: inginerie hatz

Mentenanța produselor software

Page 2: inginerie hatz

Introducere

Fu da e tele e te a ței Costurile e te a ței și esti area

acestora

Măsuri folosite î procesele de e te a ță soft are

Acti ități și teh ici folosite î procesul de e te a ță

2

Page 3: inginerie hatz

Introducere

Faza de e te a ţă î epe odată u pu erea în aplicare a produsului.

Parte i tegra tă a i lului de viaţă.

Nu a avut parte de ate ţia orespu zătoare de la început.

Mod de re uperare a i vestiţiei.

3

Page 4: inginerie hatz

. Fundamentele mentenanţei

E defi ită de sta dardul IEEE şi ISO/IEC.

S op vast u ulte de ur ărit şi o trolat.

Persoa a are se o upă u e te a ţa –

maintainer.

Nevoia de ola orare di tre ai tai er şi dezvoltatori.

Ne esitatea e te a ţei derivă di e esităţile utilizatorilor.

4

Page 5: inginerie hatz

. Costurile mentenanţei şi evoluţia software

Ne esită resurse î se ate;

Redu erea osturilor pri o u i are şi î ţelegerea fa torilor are i flue ţează mentenabilitatea;

de iziile privi d e te a ţa su t ajutate de î ţelegerea a eea e se î tâ plă siste elor î timp;

5

Page 6: inginerie hatz

. Categoriile mentenanţei

4 categorii

Preve tivă: detectare/corectare erori latente;

Perfe tivă: î u ătăţirea perfor a ţei; Adaptivă: adaptarea la un mediu nou/schimbat;

Core tivă: corectarea erorilor;

6

Page 7: inginerie hatz

. Probleme cheie în mentenanţa software

Probleme tehnice

Î ţelegere li itată, testare, a aliza i pa tului, mentenabilitate

Probleme de management

Alinierea cu o ie tivele orga izaţiei, angajarea de personal, pro ese, aspe te orga izaţio ale

Estimarea costurilor

Măsuri

7

Page 8: inginerie hatz

2. Estimarea costurilor de mentenanță

fa tori teh i i și o -tehnici

a ordări utilizate:

modelele parametrice;

Experie ța;

ea ai u ă a ordare:

date e pirice + experie ța

8

Page 9: inginerie hatz

2.1 Măsuri folosite în procesele de mentenanță software

Institutul de Inginerie Software – 4 ăsuri: ări ea, efortul, orarul şi alitatea

IEEE1219:

capacitatea de a fi analizat;

capacitatea de a fi modificat;

stabilitatea;

capacitatea de a fi testat;

9

Page 10: inginerie hatz

. Activitățile procesului de mentenanță

des ris pri i ter ediul sta dardelor de e te a ță software IEEE 1219 și ISO/IEC 14764

a tivități de e te a ță

tra ziția

acceptarea/ respingerea cererii de modificare

help desk

analiza impactului

suport software

a ordurile privi d ivelul servi iilor SLAs și o tra tele de e te a ță de spe ialitate spe ifi e u ui a u it

domeniu)

10

Page 11: inginerie hatz

4. Tehnici utilizate în procesul de

mentenanţă

î țelegerea progra ului reengineering -> înlocuirea unui software vechi cu

unul nou

reverse engineering

redocumentarea

refacearea design-ului

refactoring

11

Page 12: inginerie hatz

Concluzia vã aparŁine astãzi ! Care este ?

Page 13: inginerie hatz

Testare software

Page 14: inginerie hatz

Testarea presupune:

evaluarea calităţii produselor;

îmbunătăţirea produselor;

identificarea problemelor şi a bugg-

urilor;

Page 15: inginerie hatz

Aspecte cheie

Principalele aspecte :

criteriile de selectie;

testarea eficientei;

obiectivele testarii;

identificarea defectelor;

relatii ale testarii, cu alte activitati;

Page 16: inginerie hatz

Introducere

1. Bazele testării

2. Nivele de testare

3. Tehnici de testare

6. Măsuri de testare

7. Procesul de testare

Concluzii

Page 17: inginerie hatz

1 . Bazele testarii software

Terminologia de testare si aspecte cheie:

dinamic -testarea implica intodeauna executarea

programului;

finit –proiectele finite pot dura chiar si cativa ani;

selectat –diferentele dintre teste se regasesc, in

general, in fuctie de modul de selectie,

asteptat – posibil.

Page 18: inginerie hatz

2. Nivelele testarii

Din acest punct de vedere, se pot distinge 3 mari etape

de testare la nivel conceptual, si anume:

Scopul testarii;

Testarea unit-urilor;

Testarea integrarii;

Testarea sistemului

6

Page 19: inginerie hatz

Obiectivele testarii

Testarea calificarii;

Testarea instalarii;

Testarea alfa si beta;

Testarea conformitatii;

Siguranta evaluarii;

Testarea regresiei;

Testarea stresului;

Testarea spate in spate;

Testarea recuperarilor;

Testarea configurarii;

Testarea aplicabilitatii

7

Page 20: inginerie hatz

3.Tehnicile de testare

Tehnici bazate pe intuitia si experienta

inginerului software

• Testarea ad-hoc - utila pentru identificarea testelor

speciale, acelea care nu sunt usor de capturat prin

tehnicile formalizate.

• Testarea experimentala - diverse surse:

comportamentul produsului observat in timpul testarii,

familiarizarea cu aplicatia, platforma, buggurile

procesului, etc.

8

Page 21: inginerie hatz

Tehnicile bazate pe specificatii

Limita de separare;

Tabela decizionala;

Automate;

Testarea specificatiilor;

Testarea aleatorie;

9

Page 22: inginerie hatz

Tehnici bazate pe cod

Criterii bazate pe flux-control;

Criterii bazate pe fluxul de date;

Modele de referinta pt testarea code-based;

Tehnici bazate pe bugg-uri

Bugg-uri dibuite;

Testarea bugg-urilor.

10

Page 23: inginerie hatz

Tehnici de utilizare

Profilul operational;

Software Reliability Engineered Testing (SRET):

metodă de testare ce cuprinde intregul proces de

dezvoltare, prin care testarea este proiectata şi ghidată

de obiectivele de fiabilitate.

Tehnici bazate pe natura aplicatiei;

11

Page 24: inginerie hatz

Tehnici de selectie si combinare

Tehnici functionale si Structurale;

Determinibilitate in comparatie cu aleator

testarile pot fi selectate într-un mod determinist,

în conformitate cu una dintre diferitele tehnici

enumerate, sau luate la întâmplare din unele

intrari distribuite, cum se face de obicei în testele

de fiabilitate

12

Page 25: inginerie hatz

4. Masuri de testare

Evaluarea programului in timpul testarii

Masuri de programare si adaugare a planurilor de testare;

Tipuri de bugg-uri, clasificari si statistici;

Denistatea erorilor;

Testarea si evaluarea fiabilitatii;

Imbunatatirea modelelor de testare a fiabilitatii;

13

Page 26: inginerie hatz

Evaluarea si testarea performantelor

Masuri de acoperire;

Bugg-uri asemanatoare;

Rezultatul dintre bugg-uri eliminate si cele ramase;

Compararea eficacitatii diferentelor;

14

Page 27: inginerie hatz

5. Procesarea testarii

Testarea conceptelor, strategiilor, tehnicilor, şi măsurile lor, trebuie integrate într-un proces definit si

controlat, care este rulat de factorul uman.

Consideratii practice

Atitudini de programare;

Caietul de sarcini;

Documentatii;

Testarea interna si indepenta a echipei

Costurile estimative, precum si alte masuri

15

Page 28: inginerie hatz

Activitatile de testare

Planificare;

Generarea de cazuri de testare;

Mediul de dezvoltare a testelor;

Executarea;

Evaluarea rezultatelor testarii;

Raportarea problemelor;

Urmarirea bugg-urilor;

16

Page 29: inginerie hatz

Concluzii

Dupa cat este de complex procesul de testare, pe atat

este de important a fi realizat;

Prin testare, bugg-urile si erorile aparute in programe ,

vor fi detectate si se va incerca rezolvarea problemelor

Testarea este o etapa la fel de importanta ca si cea de

programare, etc.

17

Page 30: inginerie hatz

CONSTRUC IA SOFTWARE

Page 31: inginerie hatz

1.Introducere

2.Bazele construc iei software

3.Gestionarea construc iei 4.Considerente practice

5.Concluzii

Page 32: inginerie hatz

1. INTRODUCERE

Co stru ţie soft are = rearea detaliată a u ui soft are fu ţio al, se ifi ati , pri o i aţia de odifi are, verificare, testare pe componente, testare de integrare

şi depa are. KA a o stru ţiei soft are este legată de cea a design-

ului şi a testării: (output- design, input – testare).

Produce cel mai mare număr de elemente de

configurare care trebuie gestionate într-un proces soft.

Se bazează foarte mult pe instrumente şi metode

Produsul final al unui proiect software este codul.

Cel mai apropiat domeniu de informatică datorită

utilizării algoritmilor şi tehnicilor de codare.

Page 33: inginerie hatz

Aria de cunoştinţe a Construcţiei Software este legată de următoarele KA:

◦ KA a Design-ului Software

◦ KA a Testării Software

◦ KA a Managementului Configurării Software

◦ KA a Instrumentelor şi Metodelor din Ingineria Software

◦ KA a Calităţii Software

Page 34: inginerie hatz

2.BAZELE CONSTRUC IEI SOFTWARE

Minimizarea complexităţii ◦ Necesitatea reducerii complexităţii se aplică tuturor

aspectelor construcţiei software

◦ Reducerea complexităţii = accentuarea creerii de cod simplu şi uşor de citit în defavoarea celui inteligent

Anticiparea schimbărilor e susţinută de multe tehnici:

◦ Metode de comunicare - standarde pentru formatul şi conţinutul documentelor; ◦ Limbaje de programare – standarde precum Java, C++

etc.

◦ Platforme – standarde pentru programatorii interfaţelor pentru apelurile la sistemul de operare.

◦ Instrumente – standarde pentru notaţiile diagramelor UML etc

Page 35: inginerie hatz

Construcţie pentru verificare

◦ dezvoltarea de software în asemenea mod încât depistarea erorilor să se efectueze rapid de către inginerii care scriu software-ul, dar şi în timpul testării independente şi activităţii operaţionale;

◦ Tehnicile amintite urmăresc standardele pentru a permite analiza codului, testarea pe componente, organizare a codului pentru a permite testarea automată şi utilizarea restrictivă a structurilor de limbaj complexe şi greu de înţeles.

Standarde în construcţie

◦ Utilizarea standardelor externe – de ex., specificaţii in interfaţă hard şi soft precum IEEE sau ISO.

◦ Utilizarea standardelor interne - pot fi create pe bază organizaţională la nivel corporativ sau pentru utilizarea în proiecte specifice.

Page 36: inginerie hatz

3.GESTIONAREA CONSTRUC IEI Modele de construcţie

◦ Modele liniare: modelul cascadă, livrarea pe componente

◦ Modele iterative: prototipizarea evoluţionară, Extreme Programming şi Scrum

Planificarea construcţiei ◦ Alegerea metodei afectează ordinea în care componentele

sunt create şi integrate şi gradul de complexitate estimat.

◦ Abilitatea proiectului de a reduce complexitatea şi de a anticipa schimbările.

◦ Atribuirea de sarcini specifice inginerilor software

Măsurarea construcţiei ◦ Anumite activităţi pot fi măsurate: codul elaborat, codul

reutilizat, codul distrus, complexitatea codului, efortul if planificarea.

Page 37: inginerie hatz

4.CONSIDERENTE PRACTICE Proiectarea construcţiei ◦ Proiectarea detaliată are loc la nivelul construcţiei ◦ Este dictată de constrângerile stricte impuse de problemele reale care

sunt abordată de către software ◦ Realizarea modificărilor pentru a aprofunda detaliile de proiectare

software din timpul construcţiei. Limbaje de construcţie

◦ Include toate formele de comunicare prin care se pot specifica calculatorului soluţiile problemelor.

◦ Limbajul de configurare – ing. aleg dintr-un set limitat de opţiuni predefinite, pentru a crea noi soft-uri (ex., fiş. de configurare bazate pe text utilizate în S.O. Windows şi Unix).

◦ Limbajele bazate pe seturi de instrumente (toolkit languages) pt. a construi aplicaţii din toolkit-uri (ex., script-urile)

◦ Limbajele de programare – cele mai flexibile lb. de construcţie; conţin trei tipuri de notaţii: Lingvistic – utiliz. Cuvintelor ca şiruri de caractere text; Formal – stau la baza celor mai multe forme de programare

Vizual - interpretarea vizuală directă şi plasarea entităţilor vizuale

Page 38: inginerie hatz

Implementarea

◦ Tehnici pentru crearea de cod sursă inteligibil; ◦ Utilizarea de clase, tipuri enumerate, variabile,

constante denumite şi alte entităţi similare;

◦ Utilizarea structurilor de control;

◦ Tratarea erorilor (a celor planificate şi a excepţiilor); ◦ Prevenirea încălcării securităţii la nivel de cod (depăşirii

de buffer, overflow de indici de matrice);)

◦ Organizarea codului sursă;

◦ Documentaţia codului; ◦ Îmbunătăţirea codului;

Testarea - în faza de construcţie reduce decalajul dintre momentul comiterii greşelii şi momentul detectării ei;

◦ Testarea pe componente

◦ Testarea de integrare

Page 39: inginerie hatz

Reutilizarea ◦ Selecţia unităţilor reutilizabile, bazelor de date, procedurilor

de testare sau datelor de testare; ◦ Evaluarea codului sau testarea reutilizabilităţii; ◦ Raportarea informaţiilor privind noul cod refolosibil, a

procedurilor de testare sau a datelor de testare; Calitatea construcţiilor – presupune tehnici de asigurarea

calităţii codului în faza de construcţie: ◦ Testarea pe componente şi testarea de integrare; ◦ Dezvoltare test-first (în faza de Testare); ◦ Cod preliminar; ◦ Utilizarea afirmaţiilor; ◦ Depanare (debugging); ◦ Comentarii tehnice; ◦ Analiza statică;

Integrarea ◦ Planificarea succesiunii în care componentele vor fi integrate; ◦ Crearea de cadre pentru a suporta versiuni intermediare ale

software-ului;

Page 40: inginerie hatz

5.CONCLUZII

Construcţia software este un proces important în activitatea

de dezvoltare a sistemelor software, fiind în strânsă legatură cu toate celelalte Arii de Cunoştinţe ale ingineriei sistemelor software.

Page 41: inginerie hatz

Introducere

1. Fundamentele design-ului de soft

2. Elemente cheie în design-ul u ei aplicaţii 3. Structura şi arhitectura aplicaţiei 4. Evaluarea şi a aliza calitativă a desig -ului soft

5. Notaţiile desig -ului aplicaţiei

6. Strategii şi etode de soft desig

Concluzii

1

Page 42: inginerie hatz

Design-ul [IEEE610.12-90] - „procesul de definire a arhitecturii,

componentelor, interfeţelor şi a altor caracteristici ale unui sistem bazat pe componente”, cât şi „rezultatul acestui proces”.

Design-ul programului joacă un rol important în dezvoltarea ulterioară a softului: permite inginerilor de soft să producă diferite modele care alcatuiesc un plan al soluţiilor posibile .

Conform standardelor, [IEEE12207.0-96], privind procesele din

ciclul de viaţă al unei aplicaţii, design-ul este un proces constând din două activităţi:

× Design-ul arhitectural al aplicaţiei - are rolul de a descrie structura şi organizarea de nivel superior, şi in acelasi timp identifică diferitele componente.

× Design-ul detaliat al aplicaţiei - are rolul de a descrie fiecare componentă suficient de detaliat pentru a permite construcţia ei.

În terminologia lui Tom DeMarco, managementul design-ului aplicaţiei, se ocupă mai ales de analiza design-ului, şi de părţile componente care alcătuiesc aplicaţia. 2

Page 43: inginerie hatz

Procesul design-ului soft

Design-ul soft este considerat ca fiind un proces realizat

în 2 paşi: 1. Design-ul arhitectural - descrie modul în care un

program este descompus şi organizat în

componente (arhitectura programului).

2. Design-ul detaliat - descrie comportamentul

specific al acestor componente. Rezultatul

acestui proces constă într-un set de modele care

înglobează deciziile majore care trebuie luate în

privinţa design-ului unui program.

3

Page 44: inginerie hatz

Tehnici de activare

Principiile design-ului de soft, numite şi tehnici de activare, reprezintă noţiuni cheie, considerate ca fiind fundamentale pentru multe concepte şi abordări ale design-ului de soft. Tehnicile de activare sunt următoarele:

× Abstractizarea - „procesul de omitere a informaţiilor, astfel încât lucrurile care sunt diferite să poată fi tratate ca şi cum ar fi asemănătoare.” În contextul design-ului de programe, sunt 2 mecanisme de abstractizare: parametrizarea şi specificarea.

× Asocierea şi coeziunea : asocierea - legătura relaţiilor dintre module; coeziunea - definită de modul în care relaţionează elementele care alcătuiesc un modul.

× Descompunerea şi modularizarea - împart aplicaţia în module mai mici, independente, de obicei având scopul de a plasa funcţionalităţi diferite sau responsabilităţi în module diferite.

× Încapsularea / ascunderea informaţiilor - gruparea elementelor şi a detaliilor interne ale unei abstractizări astfel încât aceste detalii să fie aparent inaccesibile.

× Separarea interfeţei şi a implementării - presupune definirea unei componente cu o interfaţă publică, accesibilă clienţilor, şi separată de detaliile referitoare la modul de realizare a componentei.

× Suficienţă, întregire şi primitivitate - asigurarea faptului că o componentă a aplicaţiei poate cuprinde toate caracteristicile importante ale unei abstractizări.

4

Page 45: inginerie hatz

Atunci când proiectăm o aplicaţie, trebuie să tratăm o serie de elemente cheie, cum ar fi: calitatea, performanţa, modul de descompunere, organizarea şi asamblarea componentelor aplicaţiei.

În contrast, alte elemente, tratează aspecte ale comportamentului aplicatiei. Aceste elemente au fost denumite „aspecte” şi tind să nu fie unităţi funcţionale de descompunere a aplicaţiei, ci proprietăţi care influenţează performanţele sau semantica componentelor într-un mod sistemic. Printre cele mai importante elemente de acest fel putem aminti: × Concurenţa - modul de descompunere al aplicaţiei în procese, sarcini, fire de

execuţie; tratează probleme legate de eficienţă, atomicitate, sincronizare şi organizare. × Controlul şi tratarea evenimentelor - modul de organizare al datelor, de control al

fluxului, de tratare a evenimentelor reactive şi temporale prin diverse mecanisme. × Distribuţia componentelor - modul de distribuire a soft-ului peste hardware, modul în

care componentele comunică între ele, modul în care poate fi folosit soft-ul şi hard-ul pentru a trata aplicaţiile heterogene. × Toleranţa şi tratarea erorilor şi excepţiilor - modul de prevenire şi toleranţă al erorilor;

se ocupă de situaţiile excepţionale. × Interacţiunea şi prezentarea - pune în evidenţă modul de structurare şi organizare al

interacţiunii cu utilizatorul şi de prezentare a informaţiilor. × Persistenţa datelor - modul în care datele vor fi manipulate pe durata lor de viaţă.

5

Page 46: inginerie hatz

In sens strict, o arhitectură software reprezintă o descriere a subsistemelor şi componentelor unei aplicaţii şi a relaţiilor dintre ele.

Arhitectura încearcă să definească structura internă (construirea si organizarea) a software-ului rezultat.

× Structuri arhitecturale O vedere (view) reprezintă un aspect parţial al arhitecturii software care ne arată

proprietăţile specifice ale unui sistem soft”. Aceste vederi distincte se referă la diferite aspecte asociate design-ului soft – de exemplu vederea logică (îndeplinirea cerinţelor funcţionale) vs. vederea proces (probleme de concurenţă) vs. vederea fizică (probleme de distribuţie) vs. vederea de dezvoltare ( modul în care design-ul este împăţit în unităţi de implementare).

Un stil arhitectural este „un set de constrângeri asupra unei arhitecturi care defineşte un

set sau o familie de arhitecturi”, un meta-model de organizarea soft-ului la nivel inalt. Diferiţi autori au identificat diferite stiluri arhitecturale: * structuri generale (de exemplu: straturile, filtrele, etc) * sisteme distribuite ( de exemplu: client-server, pe mai multe nivele, broker) * sisteme interactive (de exemplu: Prezentare-Abstractizare-Control) * sisteme adaptabile( de exemplu: micro-kernel) * altele (de exemplu: interpretatoarele, controloarele de procese, cele bazate pe reguli).

6

Page 47: inginerie hatz

× Şabloane de design

Un şablon „ este o soluţie comună la o problemă comună într-un anumit context”.

- stilurile arhitecturale : sabloane descriind organizarea de nivel inalt a unei aplicatii

- şabloane de design: folosite pentru a descrie detalii la un nivel mai local.

* şabloanele creaţionale (de exemplu: singleton, constructor, prototip, etc)

* şabloanele structurale (de exemplu: adaptor, legatura, compozit, proxy)

* şabloanele comportamentale (de exemplu: comanda, interpretor, iterator, mediator, observator, de stare, template, etc)

× Familiile de Programe şi Cadre

O posibilă abordare care ar putea permite refolosirea design-urilor şi componentelor soft, este încercarea de a proiecta familii software (produse soft de linie). Acest lucru se poate realiza identificând aspectele comune în

cadrul unei familii soft şi utilizând componente refolosibile şi customizabile pentru a răspunde necesităţilor varietăţii din cadrul familiei soft.

7

Page 48: inginerie hatz

a. Atribute ale calităţii

- sunt importante pentru obţinerea unui design soft de calitate;

- exemple: mentenanţa, portabilitatea, testarea, trasarea, corectitudinea, robusteţea şi îndeplinirea scopurilor pentru care este proiectat;

O distincţie interesantă între atributele de calitate :

- cele luate în considerare în momentul rulării , de ex. performanţa, securitatea, disponibilitatea, funcţionalitatea ;

• – cele care nu sunt luate în considerare în momentul rulării , de ex. portabilitatea, reutilizarea, integrabilitatea;

• – cele legate de calităţile intrinseci ale arhitecturii, de ex. integritatea conceptuală, corectitudinea, integralitatea.

b. Analiza calitativă şi tehnici de evaluare

Revizuirea design-ului soft: tehnici care să verifice şi să asigure calitatea design-ului.

Analiza statică: poate fi folosită pentru a evalua design-ul.

Simularea şi prototipurile: tehnici dinamice de evaluare a design-ului.

8

Page 49: inginerie hatz

c. Măsurători - folosite pentru a evalua sau a estima cantitativ diferite aspecte ale dimensiunii design-ului soft, ale structurii sau ale calităţii.

- depind, in general de abordarea folosită pentru construirea design-ului.

Aceste măsurători sunt clasificate în 2 mari categorii:

Orientate pe funcţii (structurate): structura design-ului, obţinută în mare parte prin descompunere funcţională este reprezentată in general ca o organigramă de structură pe care pot fi facute diferite măsurători.

Orientate pe obiect: structura de ansamblu a design-ului este adesea reprezentată cu ajutorul unei diagrame de clase, pe care pot fi obtinute diferite măsurători.

9

Page 50: inginerie hatz

Notaţiile - folosite pentru a descrie organizarea structurală a design-ului / pentru a reprezenta comportamentul soft-ului;

- folosite în timpul design-ului arhitectural / în timpul design-ului detaliat;

- folosite în cadrul unor metode specifice (descrierea structurală, descrierea comportamentală).

Descrierea structurală: a notaţiilor ce descriu principalele componentele şi modul de interconectare:

× Limbajele de descriere a arhitecturii (LDA): folosite pentru a descrie arhitectura unei aplicaţii în termeni de componente şi conectori;

× Diagramele de clase şi obiecte: folosite pentru a reprezenta seturi de clase (şi obiecte) şi relaţionarea lor.

× Diagramele de componente: folosite pentru a reprezenta un set de componente şi interelaţionarea lor.

× Class Responsibility Collaborator card (CRCs): folosite pentru a indica numele componentelor, responsabilităţile acestora şi numele componentelor cu care interacţionează.

× Diagramele de desfăşurare: folosite pentru a modela aspectele fizice ale unui sistem.

× Diagramele entitate-relaţie: folosite pentru a reprezenta modele conceptuale ale datelor stocate în sisteme informaţionale

× Limbaje de descriere a interfeţei: folosite pentru a defini interfeţele componentelor soft-ului.

× Diagrame de structură Jackson: folosite pentru a descrie structuri de date în termeni de secvenţă, selecţie şi iteraţie.

× Grafice de structură: folosite pentru a descrie structura de apelare a programelor.

10

Page 51: inginerie hatz

Descrierea comportamentală: folosite pentru a descrie comportamentul dinamic al componentelor soft-ului.

× Diagrame de activitate: folosite pentru a ilustra controlul fluxului de la activitate la activitate.

× Diagrame de colaborare: folosite pentru a arăta interacţiunile care apar în cadrul unui grup de obiecte, unde accentul este pe obiecte, pe legăturile dintre ele şi pe mesajele pe care le schimbă prin aceste legături.

× Diagrame de flux de date: folosite pentru a arăta fluxul de date în cadrul unui set de procese.

× Tabele de decizie şi diagrame: folosite pentru a reprezenta combinaţii complexe ale condiţiilor şi acţiunilor.

× Grafice de flux şi grafice structurate: folosite pentru a reprezenta fluxul de control şi acţiunile asociate ce vor fi efectuate.

× Diagramele de secvenţă: folosite pentru a arăta interacţiunile din cadrul unui grup de obiecte, cu accent pe ordonarea mesajelor în funcţie de timp.

× Tranziţiile de stare şi diagramele graficelor de stare: folosite pentru a arăta controlul fluxului de la stare la stare, în cadrul unei maşini cu mai multe stări.

× Limbaje formale de specificare: folosesc noţiuni de bază din matematică pentru a defini riguros şi abstract interfeţele şi comportamentul componentelor soft

× Pseudocodul şi limbaje de design ale programelor: programarea structurată, asemeni limbajelor folosite pentru a descrie, în general în etapa de design general, comportamentul unei proceduri sau metode.

11

Page 52: inginerie hatz

- strategiile ajută procesul de design;

- metodele sunt mult mai specifice - sugerează şi furnizează un set de notaţii şi un set de orientari pentru folosirea metodei;

× Strategii generale : strategiile top-down vs bottom up, abstractizarea datelor şi ascunderea informaţiilor, folosirea euristicii, folosirea şabloanelor, folosirea abordării iterative şi incrementale.

× Design-ul structurat:

- metodă clasică de design soft;

- folosit după analiza structurală, produce diagrame de flux de date şi descrieri de procese asociate.

× Design-ul orientat obiect:

- moştenirea şi polimorfismul joacă un rol crucial in sfera design-ului bazat pe componente, şi unde meta-informaţiile pot fi definite şi accesate;

× Design-ul centrat pe structuri de date: - porneşte de la structurile de date pe care le manipulează un program şi nu de la funcţiile pe care le îndeplineşte

× Design-ul bazat pe componente: - se adresează problemelor legate de furnizarea, dezvoltarea şi integrarea unor componente pentru a îmbunatăţi gradul de refolosire al lor.

× Alte metode: - metodele formale şi riguroase, metodele transformaţionale.

12

Page 53: inginerie hatz

Design-ul software

este un proces de proiectare a cerintelor unui program, pentru a intocmi o descriere a structurii interne a acestuia, in vederea

realizarii obiectivelor stabilite.

13

Page 54: inginerie hatz

Cerinte software

Notiunea de cerinte software

1.Fundamentele cerintelor software

2.Procesarea cerintelor

3.Obtinerea cerintelor

4.Analiza si specificarea cerintelor

5.Validarea cerintelor si

Considerente practice

Page 55: inginerie hatz

Notiunea de cerinte software

-Domeniul cerintelor software se ocupa cu:

extragerea, analiza, specificarea si validarea

cerintelor unui proces.

-Exprima nevoile si constrangerile unui

produs software ce contribuie la rezolvarea

unei probleme reale.

Page 56: inginerie hatz

1.Fundamentele cerintelor software

1. Definirea unei cerinte software

2. Cerinte de produs; cerinte de proces

3. Cerinte functionale si non-functionale

4. Proprietati emergente

5. Cerinte cuantificabile / ne-cuantificabile

6. Cerinte de sistem / cerinte software

Page 57: inginerie hatz

2.Procesarea cerintelor

Modele de proces

Actori de proces

Administrarea si suportul procesului

Imbunatatirea si calitatea procesului

Page 58: inginerie hatz

3.Obtinerea cerintelor

Sursele cerintelor

Tehnici de obtinere:

Interviuri

Scenarii

Prototipizare Sedinte de grup

Observatiile

Page 59: inginerie hatz

4.Analiza si specificarea cerintelor

→ Clasificare cerintelor

→Modelarea conceptuala

→Design arhitectural si alocarea cerintelor

→Negocierea cerintelor

→Specificarea cerintelor →Document despre definirea sistemului

Page 60: inginerie hatz

5.Validarea cerintelor si

Considerente practice

→ Revizuirea cerintelor

→Prototipizarea

→Validarea modelului

→Teste de acceptare

Page 61: inginerie hatz

INGINERIA SISTEMELOR SOFT Introducere

Page 62: inginerie hatz

Cuprins

Definitie

Obiective

Ariile de cunostiinte

Domeniile conexe

Page 63: inginerie hatz

Defintia conceptului ISI

Aplicarea unei abordări cuantificabile în mod sistematic şi disciplinat pentru dezvoltarea , exploatarea şi întreţinerea sistemului soft

Page 64: inginerie hatz

Obiective

Promovarea unei viziuni coerentă pentru ISI

Statabilirea locului si setarea limitele ISI

Caracterizarea conţinutul ISI ca şi disciplină

Oferirea unui acces la topica ISI cu privire la

Baza de Cunoştiinte

Oferirea unei baze pentru dezvoltare si

certificare

Page 65: inginerie hatz

Ariile de cunostiinte (KA)

Cerinţele sistemelor soft Proiectarea sistemelor soft

Construcţia sistemelor soft Testarea sistemelor soft(software)-testing

Întreţinerea sistemelor soft(software)-maintenance

Managementul de configurare a sistemelor soft

Managementul ingineriei sistemelor soft

Procesul de inginerie a sistemelor soft

Instrumente de ingineria sistemelor soft şi metode

Calitatea sistemelor soft (software)

Page 66: inginerie hatz

Domeniile conexe

Ingineria calculatoarelor

Managementul proiectelor

Informatică

Managementul calităţii Management

Ergonomia software

Matematică

Sisteme de inginerie

Page 67: inginerie hatz

PROIECTAREA SISTEMELOR SOFT

PROIECTAREA – procesul de definire al arhitecturii, componentelor, interfeţelor şi a altor caracteristici ale unui sistem sau a unei componente.

KA – impartită in 6 subzone:

1. Bazele de Design ale Sistemelor Soft 2. Problemele cheie întâlnite în Proiectarea Sistemelor Soft 3. Structura şi Arhitectura Software

4. Analiza şi evaluarea calităţii Proiectării Sistemelor Soft 5. Notaţiile de proiectare a Sistemelor 6. Strategiile şi Metodele de Proiectarea a Sistemelor Soft

Page 68: inginerie hatz

CONSTRUC IA SISTEMELOR SOFT

Construc ia sistemelor soft - se referă la crearea detaliată a muncii unui software semnificativ, printr-o combinaţie între:

Cod;

Verificare;

Unitate de testare;

Testarea de integrare;

Depanare(debugging).

KA - include trei sub-zone:

1. Bazele de construcţie a programului 2. Gestionarea construcţiei software-ului 3. Considerentele practice

Page 69: inginerie hatz

TESTAREA APLICA IILOR SOFT

Testare Software constă în verificarea dinamică a comportamentului unui program pe un set finit de cazuri de testare, selectate corespunzător dintr-un număr infinit de domenii de execuţie, faţă de comportamentul aşteptat.

Testarea unei aplicaţii soft are 5 paşi: 1. Descrierea Bazelor Testării aplicaţiei soft 2. Nivelurile de testare 3. Tehnici de testare 4. Măsuri legate de testare 5. Procesul de testare care include consideraţiile practice, precum

şi activităţile de testare.

Page 70: inginerie hatz

MENTENAN A APLICA IEI SOFT

Faza de între inere a ciclului de via a - începe la livrare, dar

activităţile de întreţinere au loc mult mai devreme.

Software-ul de întreţinere KA este împărţit în patru sub-zone:

1. Bazele Mentenanţei Aplicaţiei Soft 2. Problemele Cheie în Întreţinerea Aplicaţiei Soft 3. Procesul de mentenanţă

4. Tehnicile de întreţinere

Page 71: inginerie hatz

MANAGEMENTUL CONFIGURARII SISTEMELOR SOFT

Software Configuration Management (CSM) - disciplina care ne ajută să identificăm configuraţia soft-ului la diferite momente în timp, cu scopul de a controla în mod sistematic eventualele schimbări de configuraţie şi de a menţine integritatea şi trasabilitatea configuraţiei pe tot parcursul ciclului de viaţa al sistemului.

Această KA include şase sub-zone. 1. Procesul de administrare al SCM 2. Identificarea configuraţiei Software

3. Controlul configuraţiei software

4. Contabiliatea configuraţiei software 5. Auditarea configuraţiei software 6. Livrarea şi Managementul lansării software-ului

Page 72: inginerie hatz

MANAGEMENTUL INGINERIEI SISTEMELOR SOFT

Software Engineering Management – are în vedere gestionarea şi măsurarea ingineriei software.

Există şase subzone de gestionare a ingineriei software: 1. Iniţierea şi definirea domeniului de aplicare 2. Planificarea Proiectului de Soft

3. Punerea în aplicare a proiectului de soft

4. Examinarea şi evaluarea 5. Încheierea 6. Ingineria software(Software Engineering)

Page 73: inginerie hatz

PROCESUL DE INGINERIE AL SISTEMELOR SOFT

Procesul de Inginerie Soft - este preocupat de definirea,

implementarea, evaluarea, măsurarea, managementul, schimbarea, precum şi de îmbunătăţirea procesului de inginerie soft în sine.

Acesta este împărţit în patru sub-zone:

1. Modificarea şi implementarea procesului 2. Definirea procesului

3. Evaluarea procesului

4. Măsurători referitoare la produs şi proces

Page 74: inginerie hatz

INSTRUMENTELE ŞI METODELE INGINERIEI SOFT

Subzona de instrumente Software Engineering - abordeaza diverse probleme de instrumente, cum ar fi tehnicile de integrare a instrumentelor, care sunt potenţial aplicabile tuturor claselor de instrumente.

Subzona Metodelor Ingineriei Soft este împărţită în sub-sectiuni:

1. metode euristice care se ocupă cu abordările informale 2. metode formale care se ocupă cu abordările matematice

3. prototipuri de metode care se ocupă cu dezvoltarea de software.

Page 75: inginerie hatz

CALITATEA SOFTWARE

Software-ul de calitate al ariei de cunoştin e - se ocupă cu considerentele de calitate ale software-ului ce depăşesc procesele de ciclu de viaţa ale software-ului.

Descrierea acestei KA acoperă trei sub-zone:

1. Fundamentele de calitate ale Software-ului

2. Procesele de Management al Calităţii Software

3. Considerentele practice legate de Calitatea Software-ului


Recommended