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).
4. Testarea programelor.
5. Sabloane de proiectare OOP (Design Patterns).
Bibliografie
1. Ian Sommerville SOFTWARE ENGINEERING
2. Cursuri (cs.pub.ro, info.uaic.ro, etc).
3. Tutoriale Internet.
Evaluare
1.Tema de casa (2p)
- documentatie software engineering pentru proiectul de diploma
2. Tema intermediara (1p)
3. Activitatea la laborator (4p)
4. Examinare scrisa (3p)

Software Engineering??
Anii 1970 Criza software

Metodele de dezvoltare existente inadecvate dezv. de programe mari.

Efortul creste mai mult decat liniar in comparatie cu dimensiunea programului.

Componentele hardware nu mai reprezinta factorul cel mai important.

Un program nu este o entitate statica, ci el evolueaza in timp datorita

schimbarii cerintelor si a mediului de utilizare.

Trebuie sa poata fi usor de inteles si de adaptat de persoane diferite de cele

care l-au dezvoltat.

Dezvoltarea de software devine o industrie de sine statatoare

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

software: Software Engineering
Scopul: definirea de tehnici de fabricatie justificate de teorie sau de practica.
Software-ul se deosebeste de alte produse fabricate:
- nu este un produs fizic
- este dezvoltat, nu fabricat; nu exista un proces de fabricatie software
- programele nu pot fi asamblate din componente
- nu imbatraneste

Software =
cod sursa, cod executabil, biblioteci
+
documentatii (de realizare, de instalare, de utilizare)

Standardul IEEE 1993: Software Engineering este: Aplicarea unei

abordari sistematice, disciplinate si masurabile in dezvoltarea, operarea
si intretinerea software-ului, adica aplicarea ingineriei pentru software.
De asemenea, studiul unor asemenea abordari.

Principalele activitati ale unui proiect software

Activitati tehnice:
Definirea Cerintelor Utilizator
Definirea Cerintelor Software
Proiectarea arhitecturala
Proiectarea detaliata
Implementarea unitatilor program ( modulelor)
Integrarea
Testarea de sistem
Testarea de acceptare
Intretinerea si operarea

Activitati de asigurare a calitatii

Activitati de management al proiectului

Principalele activitati ale unui proiect software

Activitati tehnice:

Definirea Cerintelor (Software Requirements)

Definirea Cerintelor Utilizator

Definirea Cerintelor Software

Proiectarea (Software Design)

Proiectarea arhitecturala

Proiectarea detaliata

Implementarea (Software Implementation)

Implementarea unitatilor program ( modulelor)

Integrarea

Testarea (Software Testing)

Testarea de sistem

Testarea de acceptare

Intretinerea si operarea (Software Maintenance)

Activitati de asigurare a calitatii

Activitati de management al proiectului

Definirea cerintelor utilizator

Aceste cerinte descriu punctul de vedere al utilizatorului: CE doreste viitorul utilizator de la

viitorul produs.

Sunt cerinte privind functionare a sistemului, de performanta, de securitate, de interfata utilizator,

de interfata, etc.

Cerintele sunt definite cat mai clar intr-un document: Documentul Cerintelor Utilizator (URD User Requirements Document) sau Documentul Cerintelor de Sistem

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

Exemplu:

Sistemul trebuie s asigure procesarea fiierelor externe create de alte programe (detalii aici).

Definirea cerintelor software

Analiza cerintelor utilizator si definirea unui set de cerinte pe care viitorul produs software trebuie
sa le indeplineasca astfel incat sa fie satisfacute cerintele utilizatorilor.

Cerintele sunt descrise in cadrul unui document numit Documentul de Cerinte Software (SRD
Software Requirements Document) sau Specificatia de sistem.

Specificatia cerintelor software este independenta de implementare

SRD sta la baza contractului dintre client si producator/ echipa de dezvoltare

Furnizeaza o baza pentru estimarea costurilor si a planificarii

Exemplu (vezi cerinta anterioara de utilizator):

Trebuie prevzut de definire a tipurilor de fiiere externe

Fiecare tip de fiier extern trebuie s aib asociat o aplicaie care s fie apelat pentru fiierul
respectiv

Fiecare tip de fiier extern trebuie s fie reprezentat n fereastra utilizatorului printr-o icoan
specific

La selectarea icoanei se va apela aplicaia asociat tipului respectiv de fiier extern

Definirea cerintelor software (cont.)

Realizata (de regula !) de un analist de sistem (inginer de cerinte)

Partea cea mai importanta (destul de complicata): relatia intre client si echipa de dezvoltare

Obiectivul: stabilirea unor cerinte precise !

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

Definirea cerintelor software (cont.)

Cerinta software: ce si cum trebuie sa faca programul

Cerinte functionale:

Ce functionalitati trebuie sa aiba sistemul

Ce va contine, cum va raspunde la anumite intrari, etc.

Interactiuni intre sistem si mediul in care evolueaza sistemul

Independente de tehnologii, metodologii, (etc.) de dezvoltare

Cerinte non-functionale

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

Consideratii privind platformele de dezvoltare, tehnologii, metodologii, standarde, etc.

Cerinte specifice domeniului aplicatiei

Caracteristici: corectitudinea, consistenta, completitudinea, realism, verificabilitatea, sa

descrie exact ce vrea clientul, etc.

Definirea cerintelor software (cont.)

Asa nu:
Exemplu de cerinta vaga: sistemul trebuie sa fie prietenos
Exemplu de cerinta contradictorie: sistemul poate fi utilizat de maxim zece utilizatori
la un moment dar, dar n anumite situaii pot exista douzeci de utilizatori conectai
Exemplu de cerinta nerealista: toate datele se scriu pe disc iar timpul de rspuns
trebuie s fie mai mic de o secund

Definirea cerintelor software (cont.)

Factori de risc:
1. cerine incomplete (13.1%)
2. lipsa implicrii utilizatorilor (12.4%)
3. lipsa resurselor (10.6%)
4. ateptri nerealiste (9.9%)
5. lipsa suportului executivului (9.3%)
6. schimbarea cerinelor i a specificaiilor (8.7%)
7. lipsa planificrii (8.1%)
8. sistemele nu au mai fost cerute n ntregime
(7.5%)

Definirea cerintelor software (cont.)

Exist mai multe posibiliti de scriere a unui document de specificare a cerinelor.
O structura posibil (conf. stand. IEEE Std. 830-1993) este prezentat mai jos:

Proiectarea arhitecturala

Se stabileste arhitectura sistemului software care va implementa Cerintele formulate in

documentul de Cerinte Software

Se alege solutia de proiectare optima dintre alternativele posibile.

Toate Cerintele Software trebuie sa fie acoperite de sistemul descris in Documentul de

Proiectare Arhitecturala (ADD Architectural Design Document).

Activitatea de proiectare arhitecturala poate include si specificarea testelor de integrare

Proiectarea de detaliu

Subsistemele sunt descompuse succesiv pana se ajunge la nivel de componente direct

implementabile prin unitati de program (care nu mai sunt descompuse).

Se specifica functia/ functiile pe care trebuie sa le realizeze fiecare componenta, in Documentul

de Proiectare de Detaliu (DDD Detalied Design Document).

De asemenea, se pot defini testele unitare

Implementarea modulelor

Implementarea cuprinde codificarea si testarea separata a modulelor definite in etapa

de proiectare de detaliu.

Cea mai bine stapanita si cea mai bine utilata dintre toate activitatile ciclului de
viata.

Reprezinta circa 15-20% din efortul total de dezvoltare a unui program.

Specificarea si proiectarea reprezinta in jur de 40% (Requirements + Design)

Testarea circa 40% din efortul total de dezvoltare (Testing)

Integrarea

Modulele care au fost testate independent sunt integrate treptat in subsisteme, pana la

nivel de sistem.
Se verifica comunicarea si interactiunea intre componentele integrate (Integration
testing)

Testarea de sistem

Se verifica daca sistemul satisface cerintele specificate in documentul Cerintelor

Software

Testarea de acceptare

Se verifica daca sistemul satisface cerintele specificate in documentul Cerintelor

Utilizator

Se efectueaza de o echipa de testare independenta care include si clientul/utilizatori

Testare alfa/beta

Intretinerea si operarea

Este efectuata de (alta) echipa de dezvoltare / client

Activitatile depind de tipul de software

corectarea defectelor,

imbunatatirea unor caracteristici,

adaptarea la cerinte noi

Asigurarea calitatii
Scop: asigurarea cerintelor tehnice si a standardelor de calitate in procesul de dezvoltare
si de catre produsul final

Alegerea metodelor si a standardelor de specificare, proiectare si implementare

Revizii, pe tot parcursul procesului de dezvoltare

Definirea strategiilor de testare

Definirea metodelor de documentare

Definirea metricilor de evaluare a produselor si a instrumentelor de masurare

Activitati de management

Scrierea propunerii pentru obtinerea proiectului

Etapizarea si planificarea in timp a activitatilor

Revizii

Selectia si evaluarea personalului

Scrierea si prezentarea de rapoarte

Riscurile unui proiect software

Sunt patru grupe de riscuri pentru un proiect software:

factori de experienta:

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 pentru
livrarea produsului
definirea responsabilitatilor

factori tehnologici:

experienta si calificarea managerului de proiect

experienta si calificarea echipei
maturitatea organizatiei care realizeaza proiectul: dezvoltarea de sisteme similare, utilizarea de
standarde de Softw Eng., certificat de calitate ISO 9000

noutatea tehnologica
alegerea metodelor de dezvoltare (noi, nepotrivite)
alegerea instrumentelor de dezvoltare (noi pentru echipa, ineficiente)

factori externi:

calitatea specificarii si stabilitatea cerintelor utilizator

calitatea definirii si stabilitatea interfetelor externe
calitatea si disponibilitatea sistemelor externe

Ciclul de viata al unui program (Software life cycle)

O secventa de etape in existenta produsului software

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

Fiecare etapa din ciclul de viata este caracterizata prin activitati specifice si produsele rezultate din
activitatile respective.

Obs: include si intretinerea reluare activitati de dezvoltare

Modele ale ciclului de viata software => metodologii de dezvoltare software

(Software development life cycle models / process models):
Modelul cascada (Waterfall model)
Modelul in V ( Vmodel)
Modelul ESA ( European Space Agency)
Modelul incremental
Dezvoltarea agila(Agile development)
Dezvoltarea pe baza de prototip (Prototyping )
Modelul in spirala (Spiral model)

MODELUL IN CASCADA (WATERFALL)

Avantaje:

Sistemul este bine documentat

Permite un bun management al proiectului:

planificarea resurselor umane pe etape

estimari de cost mai exacte

Dezavantaje:

Un produs executabil, care sa demonstreze functionarea sistemului este disponibil destul de tarziu,
dupa integrare.

Pana atunci s-au produs numai documente !!

Deoarece modelul este secvential, exista numai uhn feedback local, la tranzitiile intre faze.

Multe erori sunt descoperite tarziu cost crescut

Toate riscurile sunt incluse intr-un singur ciclu de dezvoltare

Adecvat pentru proiectele in care cerintele sunt bine intelese de la inceput si nu se modifica pe
parcursul procesului de dezvoltare.

Experienta ultimelor decenii a demonstrat ca modelul este valoros.

Este utilizat in prezent de multe organizatii mari.

MODELUL IN CASCADA (WATERFALL)

Limitarile modelului

Detectarea erorilor se face destul de tarziu:

Ar fi potrivit in cazul in care:

cerintele sunt bine intelese

solutia usor de proiectat

exista putin necunoscut

In realitate:

in sau dupa faza de integrare = > la testarea concreta a programului

neintelegerea cerintelor de cttre client sau analist;

instabilitatea cerintelor;
legeri tehnologice eronate;
schimbri de personal.

Necesita reveniri la etapele anterioare => reflectarea realitatii

Daca sunt ocazionale => modelul este pertinent

Altfel => modelul nu corespunde realitatii

Modelul INCREMENTAL

Modelul INCREMENTAL

Modelul INCREMENTAL

Modelul ciclului de via INCREMENTAL" este opus modelului IN CASCADA.

Se bazeaz pe o idee foarte simpl:
dac un sistem este prea complex pentru a fi neles, conceput sau realizat
intr-o singura iteratie este mai bine sa fie realizat n mai multe iteratii, prin
evoluie.
Obs: un produs tipic consta din 10-50 iteratii

MODELUL INCREMENTAL

Avantaje:

In fiecare etapa este livrat un produs executabil (satisface o parte din cerintele utilizator). Opus
modelului cascada in care se elaboreaza documente

Prototipurile sunt livrate clientului/utilizatorilor

Feedback-ul utilizatorului este distribuit pe tot parcursul dezvoltarii => isi poate defini mai bine
cerintele;

In cazul aparitiei unor schimbari in cerinte acestea pot fi incoporate in urmatorul prototip

Utilizatorul devine partener al proiectului

Dezavantaje:

Erorile de proiectare sunt mai greu de eliminat

Efectul unei modificari locale se poate propaga in ansamblul aplicatiei.

Fiecare nou increment poate necesita reorganizarea structurii interne, degradand arhitectura initiala a
programului, facandu-l greu de verificat si de intretinut

Clientul poate poate cere mai mult !

Abordarea incrementala se poate transforma usor intr-una codifica si repara (build and fix)

MODELUL Agile

[wikipedia]

MODELUL Agile

Cadru general (conceptual) pentru dezvoltarea software

defineste mai multe metode: SCRUM, XP, etc.

Model bazat pe modelul iterativ

Fiecare iteratie este un proiect in miniatura => un nou produs

Se lucreaza pe sloturi mici de timp (timebox -uri) => managementul riscului

Comunicare directa intre participanti

dezvoltatori, testeri, proiectanti, manageri => fara documentatie

Principala masura a progresului => software functional

Dezavantajul: putina documentatie !

Tema: citeste despre SCRUM si XP