Transcript curs2_r

Procesele software
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 1
Obiective





Modele pentru procesele software
Trei modele generice de procese şi când pot fi
utilizate
Schiţarea modelelor proceselor pentru ingineria
cerinţelor, dezvoltarea software-lui, testare şi
evoluţie
Explicarea modelului RUP (Rational Unified
Process)
Tehnologia CASE în sprijinirea activităţilor
procesului software
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 2
Subiecte acoperite





Modele pentru procesul software
Iterarea procesului
Activităţile procesului
RUP (Rational Unified Process)
CASE (Computer-aided software engineering)
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 3
Procesul software
Def. Proces software = set structurat de activităţi
necesare pentru dezvoltarea unui sistem software
•
•
•
•
specificare;
proiectare;
validare;
evoluţie.
Def. Model pentru proces software = reprezentare
abstractă a unui proces. Prezintă o descriere a
unui proces dintr-o perspectivă particulară.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 4
Modele generice pentru procesul
software

Modelul cascadă (waterfall)
•

Dezvoltare evolutivă
•

Etape separate şi disticte de specificare şi de dezvoltare.
Specificarea, dezvoltarea şi validarea sunt intercalate.
CBSE (Component-based software engineering)
•
Sistemul este asamblat din componente existente.
Există variante multiple ale acestor modele. De exemplu,
dezvoltarea formală unde se utilizează un proces de tip
cascadă dar specificarea este o specificare formală care
este rafinată de-a lungul mai multor stadii pentru a deveni
un proiect implementabil.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 5
Modelul cascadă
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 6
Etapele modelului cascadă





Analiza şi definirea cerinţelor
Proiectarea sistemului şi a software-lui
Implementarea şi testarea unităţilor
Integrarea şi testarea sistemului
Operarea şi întreţinerea
Principalul dezavantaj al modelului cascadă constă în
dificultatea adaptării modificărilor după ce procesul demarat.
Înainte de a se trece la o nouă etapă este necesară
încheierea celei precedente.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 7
Problematica modelului cascadă




Partiţionarea inflexibilă a proiectului în stadii distincte face
dificil răspunsul la modificarea cerinţelor clientului.
Modelul este potrivit doar în cazurile în care cerinţele sunt
bine înţelese şi modificările vor fi în limite acceptabile în
timpul procesului de dezvoltare.
Puţine sisteme business au cerinţe stabile.
Modelul cascadă este folosit în special pentru proiecte de
ingineria sistemelor mari, unde un sistem este dezvoltat pe
mai multe sit-uri.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 8
Dezvoltare evolutivă

Dezvoltare exploratorie
•

Obiectivul este acela de a lucra cu clienţii şi de a
dezvolta un sistem final dintr-o specificare schiţată
iniţial. Trebuie să se înceapă cu cerinţe bine
înţelese şi să se adauge caracteristici noi pe baza
propunerilor clientului.
Prototipare (Throw-away prototyping)
•
Obiectivul este acela de a înţelege cerinţele
sistemului. Trebuie să se înceapă cu cerinţele
puţin înţelese şi să se clarifice ceea ce este
necesar cu adevărat.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 9
Dezvoltare evolutivă
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 10
Dezvoltare evolutivă

Probleme
•
•
•

Lipsa vizibilităţii procesului;
Sistemele sunt deseori slab structurate;
Pot fi necesare calificări speciale (e.g. în limbaje pentru
prototipare rapidă).
Aplicabilitate
•
•
•
Pentru sisteme interactive de dimesiuni mici sau
mijlocii;
Pentru părţi din sisteme mari (e.g. interfaţa utilizator);
Pentru sisteme cu durate mici de viaţă.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 11
CBSE (Component-based software
engineering)


Bazată pe reutilizare sistematică, unde sistemele
sunt integrate din componente existente sau
sisteme COTS (Commercial-off-the-shelf).
Etapele procesului
•
•
•
•

Analiză componente;
Modificare cerinţe;
Proiectare sistem cu reutilizare;
Deyvoltare şi integrare.
Această abordare este din ce în ce mai mult
utilizată odată cu apariţia standardelor de
componente.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 12
Dezvoltare orientată pe reutilzare
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 13
Iterare proces



Cerinţele sistemului se dezvoltă ÎNTOTDEAUNA
în cursul unui proiect astfel încât reiterarea, în
care primele etape sunt reluate, este întotdeauna
parte a procesului pentru sisteme mari.
Iterarea se poate aplica oricărui model generic de
proces software.
Două abordări (corelate)
•
•
Furnizare incrementală;
Dezvoltare în spirală.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 14
Furnizare incrementală



În loc de a livra sistemul deodată, dezvoltarea şi
livrarea sunt divizate în incremente cu fiecare
increment livrând o parte a funcţionalităţii cerute.
Cerinţele utilizatorului sunt prioritizate şi cerinţele
cu cele mai mari priorităţi sunt incluse în primele
incremente.
Odată ce a fost pornită dezvoltarea unui
increment, cerinţele sunt îngheţate deşi cerinţele
pentru următoarele incremente pot continua să
evolueze.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 15
Dezvoltare incrementală
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 16
Avantajele dezvoltării incrementale




Se poate furniza valoare la client cu fiecare
increment, astfel încât funcţionalitatea sistemului
este disponibilă mai devreme.
Primele incremente acţionează ca un prototip care
ajută la obţinerea cerinţelor pentru incrementele
următoare.
Risc mai scăzut de eşuare a întregului proiect.
Serviciile sistemului cu priorităţi mari tind să fie
testate mai mult.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 17
Programare extremă


Abordare a dezvoltării bazată pe dezvoltarea şi
furnizarea de incremente de funcţionalitate foarte
mici.
Se bazează pe:
• îmbunătăţirea constantă a codului,
•
•
implicarea utilizatorului în echipa de
dezvoltare,
programare în mod pereche (pairwise).
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 18
Dezvoltare în spirală




Procesul este reprezentat sub formă de spirală
(în loc de secvenţă de activităţi cu reluare).
Fiecare buclă din spirală reprezintă o etapă în
proces.
Nu există faze fixe ca specificare sau
proiectare – buclele din spirală sunt alese
funcţie de ceea ce este necesar.
Risurile sunt evaluate explicit şi rezolvate de-a
lungul procesului.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 19
Modelul spirală al procesului software
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 20
Sectoarele modelului spirală

Stabilire obiective
•

Evaluare şi reducere risc
•

Riscurile sunt evaluate şi se realizează activităţi pentru
reducerea riscurilor cheie.
Dezvoltare şi validare
•

Sunt identificate obiectivele specifice etapei.
Se alege un model de dezvoltare pentru sistem, care
poate fi oricare din modelele generice.
Planificare
•
Proiectul este revăzut şi se planifică următoarea etapă
a spiralei.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 21
Activităţile procesului




Specificarea software-lui
Proiectarea şi implementarea software-lui
Validarea software-lui
Evoluţia software-lui
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 22
Specificarea software-lui
Def. Procesul de stabilire a serviciilor cerute şi a
constrângerilor asupra operării şi dezvoltării
sistemului.

Procesul pentru ingineria cerinţelor
•
•
•
•
Studiu de fezabilitate;
Obţinere şi analiză cerinţe;
Specificare cerinţe;
Validare cerinţe.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 23
Procesul pentru ingineria cerinţelor
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 24
Proiectarea şi implementarea softwarelui
Def. Procesul de convertire a specificaţiilor
sistemului într-un sistem executabil.

Proiectare software
•

Implementatare
•

Proiectarea unei structuri software care realizează
specificaţiile;
Translatarea acestei structuri într-un program
executabil;
Activităţile de proiectare şi implementare sunt
strâns corelate şi pot fi intercalate.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 25
Activităţile procesului de proiectare
a software-lui






Proiectare arhitecturală
Specificare abstractă
Proiectare interfaţă
Proiectare componente
Proiectare structură de date
Proiectare algoritm
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 26
Procesul de proiectare a softwarelui
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 27
Metode structurate
Def. Abordări sistematice ale proiectării softwarelui.

Proiectul este documentat (în mod uzual) sub
formă de set de modele grafice.

Modele posibile
•
•
•
•
•
Model obiecte;
Model secvenţe;
Model tranziţii de stare;
Model structural;
Model al fluxului de date.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 28
Programare şi depanare
Def. Traducerea proiectului într-un program şi
eliminarea erorilor din acel program.

Programarea este o activitate personală – nu
există un proces generic pentru această
activitate.

Programatorii realizează o testare iniţială a
programului în cursul operaţiei de depanare
(debugging) pentru a descoperi şi corecta erori
ale programului.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 29
Procesul de depanare
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 30
Validarea software-lui



Verificarea şi validarea (V & V) are scopul de a
arăta că sistemul se conformează
specificaţiilor sale şi îndeplineşte cerinţele
clientului sistemului.
Implică procese de verificare/control şi
revizuire şi testarea sistemului.
Testarea sistemului implică executarea
sistemului cu cazuri de testare care sunt
derivate din specificarea de date reale ce
trebuie procesate de sistem.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 31
Procesul de testare
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 32
Stadiile testării

Testare componente sau unităţi
•
•

Testare sistem
•

Componentele individuale sunt testate independent;
Componentele pot fi funcţii sau obiecte sau grupuri
coerente de astfel de entităţi.
Testarea sistemului în ansamblu. Testarea proprietăţilor
emergente are o importanţă specială.
Teste de acceptare
•
Testare cu datele clientului pentru a verifica dacă
sistemul îndeplineşte cerinţele acestuia.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 33
Etapele testării
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 34
Evoluţia software-lui



Software-ul este în mod inerent flexibil şi se
poate modifica.
Pe măsură ce cerinţele se modifică odată cu
modificarea circumstanţelor business,
software-ul suport pentru business trebuie, de
asemenea, să evolueze şi să se schimbe.
Deşi s-a făcut demarcarea între dezvoltare şi
evoluţie (întreţinere), aceasta devine din ce în
ce mai nerelevantă pe măsură ce din ce în ce
mai puţine sisteme sunt complet noi.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 35
Evoluţia sistemului
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 36
RUP (Rational Unified Process)


Model modern pentru procesul software
derivat din UML şi procesele asociate
elaborării acestuia.
Descris din 3 perspective
•
•
•
Perspectivă dinamică – arată repartizarea etapelor
în timp;
Perspectivă statică – arată activităţile procesului;
Perspectivă practică - sugerează practici bune.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 37
Modelul etapelor RUP
P has e i terati on
Incepti on
©Ian Sommerville 2004
Elaborati on
Cons tructi on
Software Engineering, 7th edition. Chapter 4
Transi tion
Slide 38
Etapele RUP

Concepţie
•

Elaborare
•

Dezvoltarea unei înţelegeri a domeniului
problemei şi a athitecturii sistemului.
Construire
•

Stabilirea cazului business pentru sistem.
Proiectarea sistemului, programarea şi testarea.
Tranziţie
•
Repartizarea (deploy) sistemului în contextul său
de operare.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 39
Practici bune RUP






Dezvoltare iterativă a software-lui
Managementul cerinţelor
Utilizare de arhitecturi bazate pe componente
Modelare vizuală a software-lui
Verificarea calităţii software-lui
Controlul modificărilor în software
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 40
Fluxuri statice de activităţi
Flux de activităţi (workflow)
Descriere
Modelare business
Procesele business sunt modelate utilizând cazuri de utilizare business.
Cerinţe
Se identifică actorii care interacţionează cu sistemul şi sunt elaborate
cazuri de utilizare pentru a modela cerinţele sistemului.
Analiză şi proiectare
Se crează şi de documentează un model de proiectare utilizând modelel
arhitecturale, modele de componente, modele de obiecte şi modele de
secvenţe.
Implementare
Componentele sistemului sunt implementate şi structurate în subsisteme
de implementat. Generarea automată a codului din modelul de proiectare
permite accelerarea acestui proces.
Testare
Testarea este un proces iterativ desfăşurat în conjuncţie cu
implementarea. Testarea sistemului are loc după finalizarea
implementării.
Repartizarea (deployment)
Se crează un release al produsului, se distribuie utilizatorilor şi este
instalat în spaţiul lor de lucru.
Managementul configuraţiilor
şi al modificărilor
Flux de activităţi suportativ care gestionează modificările la sistem.
Managementul proiectului
Flux de activităţi suportativ care gestionează dezvoltarea sistemului.
Context
Flux de activităţi care se ocupă cu punerea la dispoziţie de instrumente
software pentru echipa de dezvoltare a software-lui.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 41
CASE (Computer-aided software
engineering)


CASE (Computer-aided software engineering) este software
folosit ca suport pentru procesele de dezvoltare de software
şi de evoluţie a software-lui.
Automatizare activităţi
•
•
•
•
•
Editoare grafice pentru dezvoltarea modelului sistemului;
Dicţionare de date pentru gestionarea entităţilor proiectării;
Constructor GUI pentru construirea interfeţei utilizator;
Debugger-e pentru a sprijini găsirea erorilor în program;
Traducătoare (translator) automate pentru generare de noi
versiuni de program.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 42
Tehnologia CASE

Tehnologia CASE a condus la îmbunătăţiri
semnificative ale procesului software. Totuşi nu
atât de mult cât s-a prezis.
•
•
Ingineria software cere gândire creativă – aceasta
nu este uşor de automatizat;
Ingineria software este o activitate de echipă şi,
pentru proiectele mari, se cheltuieşte mult timp cu
interacţiunile în cadrul echipei. Tehnologia CASE
nu oferă suport pentru acestea.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 43
Clasificare pentru CASE


Clasificarea ajută la înţelegerea diferitelor tipuri de
instrumente CASE şi suportul oferit de ele pentru activităţile
procesului (care proces?).
Perspectiva funcţională
•

Perspectiva proces
•

Instrumentele sunt clasificate conform funcţiei lor specifice.
Instrumentele sunt clasificate conform activităţilor procesului
pentru care oferă suport.
Perspectiva integrării
•
Instrumentele sunt clasificate conform organizării lor în
unităţi integrate.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 44
Clasificarea funcţională a
instrumentelor
Tip de instrument
Exemple
Pentru planificare
Instrumente PERT, instrumente pentru estimare, spreadsheets
Pentru editare
Editoare text, editoare diagrame, procesoare text
Pentru managementul
modificărilor
Instrumente pentru urmărirea cerinţelor, sisteme pentru controlul modificărilor
Pentru managementul
configuraţiilor
Sisteme pentru management versiuni, instrumente pentru construire sistem
Pentru prototipare
Limbaje de nivel f. înalt, generatoare de interfaţă utilizator
Suport al metodei
Editoare pentru proiectare, dicţionare de date, generatoare de cod
Pentru procesare limbaj
Compilatoare, interpretoare
Pentru analiză program
Generatoare de referinţe încrucişate, analizoare statice, analizoare dinamic
Pentru testare
Generatoare date de test, comparatoare fişiere
Pentru depanare
Sisteme pentru depanare interactivă
Pentru elaborare
documentaţie
Programe de aranjare în pagină, editoare de imagini
Pentru re-inginerie
Sisteme pentru referinţe încrucişate, sisteme pentru restructurare programprogram
re-structuring systems
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 45
Clasificare instrumente bazată pe
activităţi
Re-eng in eerin g to ols
Tes tin g to ols
Deb ug g in g too ls
Prog ram an aly sis to ols
Lang u ag e-p ro ces sin g
to ols
Meth o d s up po r t too ls
Prototy p ing to ols
Con fig uration
man ag emen t to ols
Chang e man ag emen t too ls
Documen tatio n too ls
Editing too ls
Plan ning to o ls
Specificatio n
©Ian Sommerville 2004
Design
Implemen tatio n
Verification
an d
Validatio n
Software Engineering, 7th edition. Chapter 4
Slide 46
Integrare CASE

Instrumente
• Suport pentru activităţi individuale ale
procesului, cum ar fi verificarea consistenţei proiectării,
editare text, etc.

Workbench-uri
• Suport pentru o etapă a procesului cum ar fi
specificare sau proiectare; în mod normal includ mai multe
instrumente integrate.

Medii
• Suport pentru toate sau pentru o parte
substanţială a întregului proces software. În
mod normal includ mai multe workbench-uri integrate.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 47
Instrumente, workbench-uri, medii
CASE
tech no lo g y
Wo rk ben ch es
To ols
Editors
Compilers
File
co mpar ato rs
Analy sis an d
d esign
Multi-metho d
wo rk ben ch es
©Ian Sommerville 2004
In teg rated
en v iro nmen ts
Pro grammin g
Sing le-meth od
wo rk ben ch es
Env iro nmen ts
Pro ces s-cen tr ed
en v iro nmen ts
Tes tin g
Gen er al-pu rp os e
wo rk ben ch es
Software Engineering, 7th edition. Chapter 4
Lang u ag e-s pecific
wo rk ben ch es
Slide 48
Puncte cheie





Procesele software sunt activităţile implicate în producerea
şi evoluţia unui sistem software.
Modelele proceselor software sunt reprezentări abstracte
ale acestor procese.
Activităţile generale sunt specificarea, proiectarea şi
implementarea, validarea şi evoluţia.
Modelele generice ale proceselor descriu organizarea
proceselor software. Exemplele includ modelul cascadă,
modelul dezvoltării evolutive şi ingineria software bazată pe
componente.
Modelele iterative ale procesului descriu procesul software
process sub formă de ciclu de activităţi.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 49
Puncte cheie






Ingineria cerinţelor este procesul de dezvoltare a
specificaţiilor software-lui.
Procesele de proiectare şi implementare transformă
specificaţiile în program executabil.
Validarea implică controlarea faptului că sistemele îşi
îndeplinesc specificaţiile şi necesităţile utilizatorului.
Evoluţia se referă la modificarea sistemului după ce a fost
dat în exploatare.
RUP (Rational Unified Process) este un model generic de
proces care separă activităţile de etape.
Tehnologia CASE oferă suport pentru activităţile procesului
software.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 50