sifonier plat

7/25/2019 Sifonier Plat

http://slidepdf.com/reader/full/sifonier-plat 1/37

Elemente principalele in cadrul cursului

1. Introducere: activitati in procesul de dezvoltare software.

2. Modele ale procesului de dezvoltare software.

3. Modelarea sistemelor informatice: U(nified) M(odeling) L(anguage).

. !estarea programelor.

". #a$loane de proiectare %%& ('esign &atterns).

Bibliografie1. Ian Sommerville “SOFTWARE ENGINEERING ”

2. ursuri (cs.pu$.ro info.uaic.ro etc).

3. !utoriale Internet.

Evaluare

1.!ema de casa (2p)

* documentatie software engineering pentru proiectul de diploma

2. !ema intermediara (1p)

3. Activitatea la laborator (4p)

. +,aminare scrisa (3p)



Softare Engineering!!

-nii 1/0 "ri#a softare

4 Metodele de dezvoltare e,istente inadecvate dezv. de programe mari.

4 +fortul creste mai mult decat liniar in comparatie cu dimensiunea programului.

4 omponentele 5ardware nu mai reprezinta factorul cel mai important.

4 Un program nu este o entitate statica ci el evolueaza in timp datoritasc5im$arii cerintelor si a mediului de utilizare.

4 !re$uie sa poata fi usor de inteles si de adaptat de persoane diferite de cele

care l*au dezvoltat.

4 'ezvoltarea de software devine o industrie de sine statatoare



- devenit necesara o disciplina care sa furnizeze cadrul pentru construirea de

software: Softare Engineering

Scopul$ definirea de te5nici de fa$ricatie 6ustificate de teorie sau de practica.

#oftware*ul se deose$este de alte produse fa$ricate:

* nu este un produs fizic

* este dezvoltat nu fa$ricat7 nu e,ista un proces de fa$ricatie software

* programele nu pot fi asam$late din componente

* nu im$atraneste



4 Softare %

cod sursa cod e,ecuta$il $i$lioteci 8

documentatii (de realizare de instalare de utilizare)

4 #tandardul I+++ 13: Softare Engineering este: “Aplicarea unei

abordari sistematice& disciplinate si masurabile in de#voltarea& operarea

si intretinerea softare'ului& adica aplicarea ingineriei pentru softare.

e asemenea& studiul unor asemenea abordari.”



rincipalele activitati ale unui proiect softare

4 Activitati te*nice$

'efinirea erintelor Utilizator

'efinirea erintelor #oftware

&roiectarea ar5itecturala

&roiectarea detaliata

Implementarea unitatilor program ( modulelor)

Integrarea

!estarea de sistem

!estarea de acceptare

Intretinerea si operarea4 Activitati de asigurare a calitatii

4 Activitati de management al proiectului



rincipalele activitati ale unui proiect softare

Activitati te*nice$

4 'efinirea erintelor (#oftware 9euirements)

'efinirea erintelor +tili#ator 'efinirea erintelor Softare

4 &roiectarea (#oftware 'esign)

&roiectarea ar5itecturala

&roiectarea detaliata

4 Implementarea (#oftware Implementation) Implementarea unitatilor program ( modulelor)

Integrarea

4 !estarea (#oftware !esting)

!estarea de sistem

!estarea de acceptare

4 Intretinerea si operarea (#oftware Maintenance)

Activitati de asigurare a calitatii

Activitati de management al proiectului



Definirea cerintelor utilizator

-ceste cerinte descriu punctul de vedere al utilizatorului: + doreste viitorul utilizator de la

viitorul produs.

#unt cerinte privind functionare a sistemului de performanta de securitate de interfata utilizator

de interfata etc.

erintele sunt definite cat mai clar intr*un document: 'ocumentul erintelor Utilizator (U9' *

User Requirements Document ) sau 'ocumentul erintelor de #istem

-ctivitatea de definire a cerintelor utilizator poate include si specificarea testelor de acceptare.

E,emplu:

#istemul tre$uie s; asigure procesarea fi<ierelor e,terne create de alte programe (detalii aici).



Definirea cerintelor software

-naliza cerintelor utilizator si definirea unui set de cerinte pe care viitorul produs software tre$uie

sa le indeplineasca astfel incat sa fie satisfacute cerintele utilizatorilor.

erintele sunt descrise in cadrul unui document numit Documentul de Cerinte Software (#9'

Software Requirements Document ) sau #pecificatia de sistem.

#pecificatia cerintelor software este independenta de implementare

#9' sta la $aza contractului dintre client si producator= ec5ipa de dezvoltare

>urnizeaza o $aza pentru estimarea costurilor si a planificarii

E,emplu (vezi cerinta anterioara de utilizator):

!re$uie prev;zut; de definire a tipurilor de fi<iere e,terne

>iecare tip de fi<ier e,tern tre$uie s; ai$; asociat o aplica?ie care s; fie apelat; pentru fi<ierul

respectiv

>iecare tip de fi<ier e,tern tre$uie s; fie reprezentat @n fereastra utilizatorului printr*o icoan;specific;

La selectarea icoanei se va apela aplica?ia asociat; tipului respectiv de fi<ier e,tern



Definirea cerintelor software (cont!

9ealizata (de regula A) de un analist de sistem (inginer de cerinte)

&artea cea mai importanta (destul de complicata): relatia intre client si ec5ipa de dezvoltare

%$iectivul: sta$ilirea unor cerinte precise -

Multe programe nu se potrivesc cu ce vrea clientul din cauza unor cerinte gresite=insuficiente




4 erinta software: ce si cum trebuie sa faca programul

4 erinte functionale:

e functionalitati tre$uie sa ai$a sistemul e va contine cum va raspunde la anumite intrari etc.

Interactiuni intre sistem si mediul in care evolueaza sistemul

Independente de te5nologii metodologii (etc.) de dezvoltare

4 erinte non*functionale

Impun diverse constrangeri (limitarea variantelor de constructie): e,: constrangeri de timp etc.

onsideratii privind platformele de dezvoltare te5nologii metodologii standarde etc.

4 erinte specifice domeniului aplicatiei

4 aracteristici: corectitudinea consistenta completitudinea realism verifica$ilitatea sa

descrie e,act ce vrea clientul etc.




4 -sa nu:

+,emplu de cerinta vaga: sistemul trebuie sa fie prietenos

+,emplu de cerinta contradictorie: sistemul poate fi utilizat de maxim zece utilizatori

la un moment dar, dar în anumite situaţii pot exista douăzeci de utilizatori conectaţi

+,emplu de cerinta nerealista: toate datele se scriu pe disc iar timpul de răspuns

trebuie să fie mai mic de o secundă




>actori de risc:

1. cerinţe incomplete (13.1%)

2. lipsa implicării utilizatorilor (12.4%)

3. lipsa resurselor (10.6%)

4. aşteptări nerealiste (9.9%)

5. lipsa suportului executiului (9.3%)6. sc!im"area cerinţelor şi a speci#caţiilor ($.%)

. lipsa plani#cării ($.1%)

$. sistemele nu au mai &ost cerute 'n 'ntreime

(.5%)




+,ist; mai multe posi$ilit;?i de scriere a unui document de specificare a cerin?elor.

% structura posi$il; (conf. stand. I+++ #td. B30*13) este prezentat; mai 6os:



"roiectarea ar#itecturala 4 #e sta$ileste ar5itectura sistemului software care va implementa erintele formulate in

documentul de erinte #oftware

4 #e alege solutia de proiectare optima dintre alternativele posi$ile.4 !oate erintele #oftware tre$uie sa fie acoperite de sistemul descris in Documentul de

"roiectare Ar#itecturala (-'' Architectural Desin Document ).

4 -ctivitatea de proiectare ar5itecturala poate include si specificarea testelor de integrare



"roiectarea de detaliu

4 #u$sistemele sunt descompuse succesiv pana se a6unge la nivel de componente direct

implementa$ile prin unitati de program (care nu mai sunt descompuse).

4 #e specifica functia= functiile pe care tre$uie sa le realizeze fiecare componenta in Documentul

de "roiectare de Detaliu (''' Detalied Desin Document ).

4 'e asemenea se pot defini testele unitare



Im$lementarea modulelor

4 Implementarea cuprinde codificarea si testarea separata a modulelor definite in etapa

de proiectare de detaliu.4 ea mai $ine stapanita si cea mai $ine utilata dintre toate activitatile ciclului de

viata.

4 9eprezinta circa 1"*20C din efortul total de dezvoltare a unui program.

4 #pecificarea si proiectarea reprezinta in 6ur de 0C (9euirements 8 'esign)

4 !estarea circa 0C din efortul total de dezvoltare (!esting)



Inte%rarea

4 Modulele care au fost testate independent sunt integrate treptat in su$sisteme pana la

nivel de sistem.

4 #e verifica comunicarea si interactiunea intre componentele integrate (Integrationtesting)

Testarea de sistem

4 #e verifica daca sistemul satisface cerintele specificate in documentul erintelor

#oftware

Testarea de acce$tare

4 #e verifica daca sistemul satisface cerintele specificate in documentul erintelor

Utilizator

4 #e efectueaza de o ec5ipa de testare independenta care include si clientul=utilizatori

4 !estare alfa=$eta



Intretinerea si o$erarea

4 +ste efectuata de (alta) ec5ipa de dezvoltare = client

4 -ctivitatile depind de tipul de software

corectarea defectelor

im$unatatirea unor caracteristici

adaptarea la cerinte noi



Asi%urarea calitatii

#cop: asigurarea cerintelor te5nice si a standardelor de calitate in procesul de dezvoltare

si de catre produsul final

4 -legerea metodelor si a standardelor de specificare proiectare si implementare

4 9evizii pe tot parcursul procesului de dezvoltare

4 'efinirea strategiilor de testare

4 'efinirea metodelor de documentare

4 'efinirea metricilor de evaluare a produselor si a instrumentelor de masurare

Acti&itati de mana%ement

4 #crierea propunerii pentru o$tinerea proiectului

4 +tapizarea si planificarea in timp a activitatilor

4 9evizii4 #electia si evaluarea personalului

4 #crierea si prezentarea de rapoarte



iscurile unui proiect softare

#unt patru grupe de riscuri pentru un proiect software:

4 factori de e,perienta$ e,perienta si calificarea managerului de proiect

e,perienta si calificarea ec5ipei

maturitatea organizatiei care realizeaza proiectul: dezvoltarea de sisteme similare utili#area destandarde de Soft Eng. certificat de calitate I#% 000

4 factori de planificare$ estimarea incorecta a resurselor umane necesare in fiecare etapa a proiectului

estimarea incorecta a perioadelor de timp necesare pentru diferite activitati inclusiv pentrulivrarea produsului

definirea responsa$ilitatilor

4 factori te*nologici$ noutatea te5nologica

alegerea metodelor de dezvoltare (noi nepotrivite) alegerea instrumentelor de dezvoltare (noi pentru ec5ipa ineficiente)

4 factori e,terni$ calitatea specificarii si sta$ilitatea cerintelor utilizator

calitatea definirii si sta$ilitatea interfetelor e,terne

calitatea si disponi$ilitatea sistemelor e,terne



Ciclul de &iata al unui $ro%ram (Software life c'cle!

4 % secventa de etape in e,istenta produsului software

include toate activitatile necesare pentru dezvoltarea produsului si relatiile temporale dintre ele.

4 >iecare etapa din ciclul de viata este caracterizata prin activitati specifice si produsele rezultate din

activitatile respective.

4 %$s: include si intretinerea reluare activitati de dezvoltare

odele ale ciclului de &iata software )* metodolo%ii de dez&oltare software

(Software de&elo$ment life c'cle models + $rocess models!,

4 /odelul cascada (Daterfall model)

4 Modelul in E ( Emodel)

4 Modelul +#- ( +uropean #pace -gencF)

4 /odelul incremental

4 'ezvoltarea agila(-gile development)

4 'ezvoltarea pe $aza de prototip (&rototFping )

4 Modelul in spirala (#piral model)



/0E1+1 “I2 "AS"AA” (AE5A11)

Avanta6e$

4 #istemul este $ine documentat

4 &ermite un $un management al proiectului: planificarea resurselor umane pe etape

estimari de cost mai e,acte

e#avanta6e$

4 Un produs e,ecuta$il care sa demonstreze functionarea sistemului este disponi$il destul de tarziu

dupa integrare.

4 &ana atunci s*au produs numai documente AA

4 'eoarece modelul este secvential e,ista numai u5n feed$acG local la tranzitiile intre faze.

4 Multe erori sunt descoperite tarziu cost crescut

4 !oate riscurile sunt incluse intr*un singur ciclu de dezvoltare

4 Adecvat pentru proiectele in care cerintele sunt $ine intelese de la inceput si nu se modifica pe

parcursul procesului de dezvoltare.

4 +,perienta ultimelor decenii a demonstrat ca modelul este valoros.

4 +ste utilizat in prezent de multe organizatii mari.

0 “ " S" ( )



/0E1+1 “I2 "AS"AA” (AE5A11)

1imitarile modelului

4 'etectarea erorilor se face destul de tarziu:

in sau dupa faza de integrare H la testarea concreta a programului

4 -r fi potrivit in cazul in care:

cerintele sunt $ine intelese

solutia usor de proiectat

e,ista putin necunoscut

4 In realitate: neintelegerea cerintelor de cttre client sau analist7 insta$ilitatea cerintelor7 legeri te5nologice eronate7 sc5im$ri de personal.

4 Jecesita reveniri la etapele anterioare H reflectarea realitatii

'aca sunt ocazionale H modelul este pertinent -ltfel H modelul nu corespunde realitatii



/ d l l “I2"E/E2A1”



/odelul “I2"E/E2A1”

/ d l l “I2"E/E2A1”




/ d l l “I2"E/E2A1”




4Modelul ciclului de via?; IJ9+M+J!-LK este opus modelului IJ -#-'-.

4#e $azeaz; pe o idee foarte simpl;:dac; un sistem este prea comple, pentru a fi @n?eles conceput sau realizatintr*o singura iteratie este mai $ine sa fie realizat @n mai multe iteratii prinevolu?ie.

%$s: un produs tipic consta din 10*"0 iteratii

/0E1+1 “I2"E/E2A1”



/0E1+1 “I2"E/E2A1”

Avanta6e$4 In fiecare etapa este livrat un produs e,ecuta$il (satisface o parte din cerintele utilizator). %pus

modelului cascada in care se ela$oreaza documente

4 &rototipurile sunt livrate clientului=utilizatorilor

4 >eed$acG*ul utilizatorului este distri$uit pe tot parcursul dezvoltarii H isi poate defini mai $inecerintele7

4 In cazul aparitiei unor sc5im$ari in cerinte acestea pot fi incoporate in urmatorul prototip

4 Utilizatorul devine partener al proiectului

e#avanta6e$

+rorile de proiectare sunt mai greu de eliminat

+fectul unei modificari locale se poate propaga in ansam$lul aplicatiei.

>iecare nou increment poate necesita reorganizarea structurii interne degradand ar5itectura initiala a

programului facandu*l greu de verificat si de intretinut

lientul poate poate cere mai mult A

-$ordarea incrementala se poate transforma usor intr*una codifica si repara ($uild and fi,)

ODE-.- /A%ile0



%

wiGipedia



/0E1+1 “ A%ile”

4 adru general (conceptual) pentru dezvoltarea software

defineste mai multe metode: S!RU" #$ etc.

4 Model $azat pe modelul iterativ

>iecare iteratie este un proiect in miniatura H un nou produs

4 #e lucreaza pe sloturi mici de timp (time$o, *uri) H managementul riscului

4 omunicare directa intre participanti

dezvoltatori testeri proiectanti manageri H fara documentatie

4 &rincipala masura a progresului H software functional

4 'ezavanta6ul: putina documentatie A

4 ema$ citeste despre SCR. si 1"

sifonier plat

Documents