UNIUNEA EUROPEANĂ GUVERNUL ROMÂNIEI Fondul Social European Instrumente Structurale OIPOSDRU UNIVERSITATEA

MINISTERUL MUNCII, PSD DRU 2007 - 2013 2007 - 2013 TEHNICĂ DE

FAMILIEI ŞI CONSTRUCŢII DIN
PROTECTIEI SOCIALE BUCUREŞTI
AMPOSDRU

Investeşte în oameni !
Proiect cofinanţat din FONDUL SOCIAL EUROPEAN
prin Programul Operaţional Sectorial Dezvoltarea Resurselor Umane 2007 – 2013
Axa prioritară 1: „EDUCAŢIA ŞI FORMAREA PROFESIONALĂ ÎN SPRIJINUL CREŞTERII ECONOMICE ŞI DEZVOLTĂRII SOCIETĂŢII
BAZATE PE CUNOAŞTERE”
Domeniul major de intervenţie 1.2 „Calitate în învăţământul superior”
Cerere de propuneri de proiecte: nr. 86 „Universitate pentru viitor”
Titlul proiectului: Reţea naţională de centre pentru dezvoltarea programelor de studii cu rute flexibile şi a unor instrumente didactice la specializarea de
licenţă şi masterat, din domeniul Ingineria Sistemelor
Numărul de identificare al contractului: POSDRU/86/1.2/S/63806

Gabriela Varvara
Ingineria Programarii I

C
Curs 2 - Modelarea
M d l proceselor
l software
ft

Partener P4

MINISTERUL EDUCAŢIEI, UNIVERSITATEA UNIVERSITATEA TEHNICĂ UNIVERSITATEA TEHNICĂ UNIVERSITATEA SC ASTI AUTOMATION SRL
CERCETĂRII, TINERETULUI ”POLITEHNICA” DIN ”GHEORGHE ASACHI” ”POLITEHNICA”
ŞI SPORTULUI DIN CLUJ-NAPOCA DIN DIN
BUCUREŞTI IAŞI TIMIŞOARA

Obiective curs 2:
Obiectivul 1: scurta introducere in modelarea proceselor software.
Obiectivul 2: prezentarea a trei modelele generice utilizate pe scara larga: cascada,
evolutionar, bazat pe componente.
Obiectiv 3: prezentarea rolului iteratiilor in cadrul unui proces de dezvoltare
Obiectivul 4: prezentarea activitatilor specifice din ingineria cerintelor, dezvoltare,
testare si evolutie software
Obiectivul 4: detaliere si particularizare model iterativ complet – Rational Unified
Process
Obiectivul 5: utilitare suport pentru activitatile implicate in procesele de dezvoltare
software.

Subiecte tratate: modele ale proceselor software, iteratie in cadrul unui proces,
activitati, RUP, utilitare suport pentru ingineria programarii

2
 Procesul software
– Set structurat de activitati impus de dezvoltarea unui sistem software

– Acopera toate fazele de dezvoltare: specificare, proiectare, validare, evolutie

– Modelul unui proces software = reprezentarea abstracta a unui proces dintr-o

perspectiva particulara
Clasificare modele:
Generice – folosite pentru procese generice (tipizate, generalizate)
Ad-hoc – folosite pentru procese particulare, atipice

Modele ale proceselor software generice

¾ Modelul cascada (Waterfall) – presupune separarea fazelor de specificare,

proiectare, implementare si validare

¾ Dezvoltare evolutionara – fazele de specificare, proiectare, implementare si

validare se intrepatrund

¾ Ingineria software bazata pe componente – sistemul este asamblat din

componente existente

¾ Exista mai multe variante ale acestor modele,

modele ca de exemplu dezvoltarea
formala care are la baza un proces in cascada, in care specificatia are un aspect
formal, ce este rafinata intr-un numar de iteratii

4
5

Neajunsuri majore ale modelului Waterfall:

– Dificultatea de a introduce modificari pe parcursul procesului de dezvoltare
– Orice faza poate incepe doar dupa ce faza precedenta a fost complet
finalizata
– Putine sisteme business au cerinte stabile. Impartirea inflexibila in stadii
distincte face imposibila tratarea noilor cerinte ale utilizatorului venite pe
parcusul dezvoltarii

Aplicabilitate model in cascada:

– Sisteme pentru care cerintele sunt complet intelese si modificarile sunt
drastic limitate de-a lungul etapei de proiectare
– Proiecte de ingineria programarii mari,
mari dezvoltate in locatii diferite

6
 Varianta de model in cascada cu revenire

Dezvoltarea de tip evolutionar

Cuprinde 2 directii fundamentale:

1. Dezvoltarea bazata pe explorare – obiectivul principal il constituie lucrul cu

clientii, sistemul final fiind dezvoltat dintr-o schita a specificatiilor initiale

2. Dezvoltare bazata pe prototipuri bune de aruncat – obiectivul principal il

reprezinta buna si completa intelegere a cerintelor. Se porneste cu o
intelegere vaga a problemei, vor rezulta prototipuri ce nu se dovedesc a fi
viabile si, drept consecinta, vor fi inlaturate rand pe rand. Acest proces va
clarifica cerintele determinand obtinerea unui prototip final viabil.

8
 Versiune initiala
Specificare

Versiuni
Descriere sumara Dezvoltare intermediare

Validare Versiunea finala

Neajunsuri majore ale modelului:

– Pierderea pe parcursul dezvoltarii a vizibilitatii procesului
– Adesea rezulta o slaba structurare a sistemelor
– Suscita existenta unor facilitati speciale ( limbaje pentru crearea rapida de
prototipuri)

Aplicabilitate model dezvoltare evolutionar:

Sisteme interactive mici si medii
Parti din sistemele mari (cum ar fi interfata utilizator)
Sisteme cu durata de viata mica

10
Capitolul 1: Procese software – cursul 2

Modelul Ingineriei Software bazat pe componente

¾Recurge la reutilizare in mod sistematic prin integrare a componentelor existente

in noi sisteme ((Commercial-Off-The-Shelf - COTS))
¾Fazele procesului:
¾Analiza componenta Specificare Analiza Proiectare
Modificare
cerinte sistem cu
¾Modificare cerinte componenta
cerinte
refolosire
¾Proiectare sistem cu refolosire
¾Dezvoltare si integrare
Dezvoltare Validare
si integrare
g sistem

¾Aceasta metoda a inceput sa fie folosita pe scara larga odata cu aparitia

componentelor standardizate

11

Iteratia in cadrul unui proces de dezvoltare

Cerintele sistemelor mari intotdeauna evolueaza pe parcursul procesului de

dezvoltare,, astfel incat stadiile primare
p sunt reluate si reprocesate
p – se
impune introducerea unei divizari a procesului in cuante de timp care sa
masoare efortul de reluare a unor activitati
Iteratia ca forma de partajare in timp a proceselor de dezvoltare poate fi
folosita in oricare model generic de proces.
Exista doua directii distincte de proiectare a iteratiilor:
Livrarea incrementala
Dezvoltare in spirala

12
 Livrarea incrementala
¾Implica dezvoltare si livrare in incremente, unde fiecare increment rezolva o parte din
functionalitatea globala ceruta
¾Cerintele utilizatorului sunt clasificate, incrementele de inceput rezolvand cerintele de
prioritate
i it t maxima i
¾Odata inceputa dezvoltarea unui increment, cerintele vor fi inghetate pana la terminarea
incrementului; acest lucru nu impiedica evolutia cerintelor care va fi luata in considerare
in iteratiile urmatoare

Definire Atribuire cerinte Proiectare

cerinte la incremente arhitectura
sistem

Dezvoltare Validare Integrare Validare

increment increment increment sistem
sistem Sistem
final
Sistem incomplet

13

Avantajele dezvoltarii incrementale

¾La fiecare increment se livreaza produs cu valoare pentru client, fiind asigurata
functionalitatea inca din fazele incipiente
¾Incrementele timpurii actioneaza ca prototipuri, ajutand la extragerea cerintelor pentru
urmatoarele incremente
¾Risc scazut de esec al intregului proiect
¾Cele mai prioritare servicii ale sistemului vor beneficia de cea mai intensa testare

¾Programarea extrema – caz particular de dezvoltare incrementala

Metoda de dezvoltare ce are drept scop livrarea unor incremente foarte mici de
functionalitate
¾Se bazeaza pe imbunatatirea permanenta a codului cu implicarea utilizatorului in
activitatile echipei de dezvoltare

14
 Dezvoltarea in spirala
¾Procesul este reprezentat mai curand ca o spirala si nu ca o
secventa de activitati, cu posibilitatea de revenire inapoi

¾Fiecare ciclu al spiralei reprezinta o modalitate concreta de

rezolvare a unui risc

¾Nu exista faze precise, precum specificarea sau proiectarea –

ciclurile fiind alese in functie de ceea ce se cere

¾Riscurile sunt evaluate in mod explicit si adresate pe tot parcursul

dezvoltarii, incepand cu cele majore

15

16
17

Sectoarele modelului spirala

1. Planificarea obiectivelor – sunt identificate obiectivele specifice fazei

2. Evaluarea si reducerea riscurilor – in urma evaluarii si prioritizarii riscurilor, vor

fi activate acele activitati ce au drept scop reducerea riscurilor majore

3. Dezvoltare si validare – se alege un model de dezvoltare care poate fi oricare

din modelele generice

4. Planificarea – proiectul este revizuit si se planifica urmatoarea faza a spiralei

18
Capitolul 1: Procese software – cursul 2

Activitatile procesului de dezvoltare software

Specificarea software

Proiectare si implementare software

Validare software

Evolutie software

19

Capitolul 1: Procese software – cursul 2

1.Specificarea software
¾ Este procesul de stabilire a serviciilor cerute sistemului software precum si a
g
constrangerilor de dezvoltare si operare
p ale acestuia
¾ Procesul de inginerie a cerintelor
o Studii de fezabilitate
o Extragerea si analiza cerintelor
o Specificarea cerintelor
o Validarea cerintelor

20
 Studiu de Extragere
fezabilitate si analiza
cerinte

Specificare cerinte

Raport fezabilitate Validare

cerinte

Modele sistem

Cerinte utilizator
si sistem

Document
de cerinte

21

2. Proiectare si implementare software

– Reprezinta
R i t procesull de
d convertire
ti a sistemului
i t l i
– Proiectare software – proiectarea structurii software ce determina realizarea
specificatiilor
– Implementare – traducerea structurii in cod executabil

– Activitatile de proiectare si implementare sunt legate intim si pot fi

intercalate

22
 2.1 Activitatile procesului de proiectare

– Proiectarea arhitecturala
– Specificarea abstracta (software)
– Proiectarea interfetei cu utilizatorul
– Proiectarea componentelor
– Proiectarea structurii datelor
– Proiectarea algoritmilor

23

Diagrama sintetica a procesului de proiectare

Specificare
cerinte

Activitati proiectare

Design Proiectare Proiectare Proiectare

Specificare Proiectare
arhitectura componenta structura date algoritmi
abstracta interfata

Specificatie
Arhitectura Specificatie Specificatie Specificatie Specificatie
structura date
sistem software interfata componenta algoritmi

Rezultate proiectare

24
 Metode structurate folosite in proiectarea software

– Reprezinta cai de dezvoltare structurata de software

– Proiectul este, de regula, documentat sub forma unui set de modele grafice
– Posibile modele: model obiect, model de secventa, model al tranzitiei starilor,
model de structura, model al fluxului de date, etc.

25

2.2 Programarea si depanarea

– Traducerea proiectului in program si eliminarea erorilor din acel program

– Programarea este o activitate personala – nu exista procese generice de
programare
– Programatorii desfasoara unele activitati de testare in vederea descoperirii
greselilor de programare si inlaturarea acestora in procesul de depanare

26
 3.Validare software
¾ Verificarea si validarea (V&V) are drept scop de a demonstra in ce masura
sistemul dezvoltat se conformeaza propriilor specificatii si raspunde cerintelor
formulate de client
¾ Implica
I li procese de
d verificare
ifi sii revizuire
i i (review)
( i )
¾ Testarea software implica executia sistemului pe cazuri de testare derivate din
specificarea datelor reale ce vor fi procesate de catre sistem

Proiectare
Localizare eroare reparare Reparare
p Retestare
eroare eroare sistem

27

Fazele testarii
¾Testarea componentelor sau a unitatilor functionale:
Componentele individuale sunt testate independent
Componentele pot fi functii
functii, obiecte sau grupari coerente ale acestor entitati
¾Testarea sistemului – testarea proprietatilor emergente are o importanta particulara
¾Testarea de acceptare – verificarea daca, pe datele client, sistemul satisface nevoile
acestuia
conform figurii (Ian Sommerville, 2004):
Requir ements System S ystem Detailed
specification specification design design

System Sub-system Module and

Acceptance
integration integration unit code
test plan
test plan test plan and test

Acceptance S ystem Sub-system

Service
test integra tion test integra tion test

28
 4. Evolutia software
¾ Produsele software sunt, inerent, flexibile si sunt supuse modificarilor
¾ Pe masura ce cerintele se modifica ca urmare a modificarii circumstantelor de business
business,
produsul software trebuie adus la zi
¾ Demarcatia intre dezvoltare si evolutie (mentenanta) devine din ce in ce mai irelevanta in
contextul unui numar din ce in ce mai redus al sistemelor complet noi

Evaluare Propunere
Definire cerinte Modificare
sisteme modificari
sistem sistem
existente sistem

Sisteme
Sistem nou
existente

29

Procesul de dezvoltare unificat Rational (Rational Unified Process- RUP) (IBM)

time

content

30
 Procesul de dezvoltare unificat Rational (RUP)
¾Model modern de proces, derivat din lucrul cu UML (Unified Modelling Language) si procese asociate

Descris din trei perspective (conform IBM):

Op perspectiva
p dinamica ce p
prezinta succesiunea in timp
p a fazelor de dezvoltare

Faza de inceput – stabileste cazurile business pentru sistem

Faza de elaborare – dezvolta modul de intelegere a domeniului problemei si arhitectura sistemului
Faza de constructie – proiectare, programare si testare produs
Tranzitie – desfasurarea sistemului in mediul de operare real si intretinere produs
O perspectiva statica ce ilustreaza activitatile procesului
O perspectiva pragmatica ce sugereaza cele mai bune practici

31

Bunele practici implementate de RUP

¾Dezvoltare bazata pe iteratii

¾Gestiunea cerintelor
¾Folosirea arhitecturilor bazate pe componente
¾Modelare software de tip vizual
¾Verificarea permanenta a calitatii
¾Gestiunea modificarilor

32
 Procesul de dezvoltare unificat Rational (RUP) – definire discipline

Modelare business – modelare cu ajutorul use-case-urilor a contextului business al

produsului dezvoltat
Cerinte – sunt identificati actorii din sistem si se dezvolta modelul use-case al
cerintelor
Analiza si proiectare – se creaza si documenteaza modelul de proiectare folosind
modele arhitecturale, modele ale componentelor, modele obiectuale si modele
secventiale.
Implementare – sunt implementate componentele si structurate subsistemele de
implementare. Generarea automata de cod duce la accelerarea procesului
Testare – este un proces iterativ ce are loc in conjunctie cu implementarea. Testarea
globala a sistemului succede faza de implementare
Desfasurare – distribuirea si instalarea produsului in locatiile de lucru ale clientului
Configurare si managementul schimbarilor - constituit dintr-un flux suport pentru
gestiunea modificarilor ce apar pe parcursul ciclului de dezvoltare
Management de proiect - flux de activitati suport ce vizeaza gestiunea dezvoltarii
sistemului
Mediu – se ocupa cu gasirea utilitarelor de dezvoltare adecvate procesului

33

Computer-aided software engineering (CASE)

¾Soft suport pentru dezvoltare si evolutie proces software
¾Categorii:
Editoare grafice pentru dezvoltare de modele
Dictionare pentru managementul entitatilor de proiectare
Buildere pentru interfetele utilizator
Depanatoare pentru depistarea automata a erorilor
Translatoare automate pentru generarea noilor versiuni ale programului
¾Utilitarele CASE pot fi grupate dupa urmatoarele criterii:
In raport cu functia specifica
In raport cu activitatile de dezvoltare ce le suporta
In raport cu organizarea lor in unitati integrate

34
 Clasificarea functionala a utilitarelor
Tip utilitar Exemple
Planificare utilitare PERT, de estimare, de desfasurare
Editare editoare de text, de diagrame, procesoare de text
Managm. schimbarilor utilitare trasabilitate cerinte, sisteme de modificare a
controlului
Managm. Configurarii sisteme de management a versiunilor, de construire
sistem
Creare prototip limbaje de nivel foarte inalt, generatoare interfete
utilizator
Suport pentru metode editoare de proiect, dictionare date, generatoare cod
Procesare limbaj compilatoare, interpretoare
Analiza program generatoare de referinte incrucisate, analizoare
statice/dinamice
Testare generatoare date testare, comparatoare fisiere
Depanare sisteme de depanare interactive
Documentare programe pozitionare pagini, editoare imagine
Reinginerie sisteme referentiere incrucisata, sisteme
restructurare program

35

Clasificarea utilitarelor CASE bazata pe activitati

36
 Integrare utilitare CASE

¾Produsele CASE pot fi grupate pe urmatoarele unitati de integrare:

¾Utilitare – suporta sarcini de procesare singulare, cum ar fi verificarea

consistentei proiectarii, editare text, etc.
¾Workbench – suporta o faza a unui proces de dezvoltare si integreaza mai multe
utilitare
¾Medii de dezvoltare – suporta o buna parte a unui proces de dezvoltare sau chiar
un intreg proces; integreaza mai multe workbenches.

37

Integrare utilitare CASE

38
 Concluzii
1. Procesele software sunt activitati de producere si evolutie a sistemelor software
2. Modelele proceselor software sunt reprezentari abstracte ale acestora
3. Activitatile de dezvoltare: specificarea, proiectarea si implementarea, validarea si evolutia
4 M
4. Modelele
d l l proceselor
l generice
i descriu
d i organizarea
i proceselor
l software
ft (ex.
( model
d l cascada,
d
dezvoltare evolutionara, inginerie software bazata pe componente)
5. Modelele iterative descriu procesele software ca un ciclu de activitati
6. Ingineria cerintelor este procesul de dezvoltare a specificatiilor software
7. Procesele de proiectare si implementare transforma specificatiile in program executabil
8. Validarea implica verificarea adecvantei sistemului la specificatii si la nevoile clientului
9. Evolutia se ocupa de modificarea sistemului dupa ce acesta este lansat pe piata
10.RUP
10 RUP este un model de proces generic ce permite separarea disciplinelor de evolutia in timp
de la o faza la alta
11.Tehnologiile CASE ofera suport in dezvoltarile software prin utilitare, workbenches si medii
de dezvoltare

39