Managementul si

dezvoltarea produselor
software
Cuprins

• Istoric
• Ciclul de viata al unui produs software
• Modele de dezvoltare software
1. Istoric

 Programarea modulara Pascal

 Programarea orientata obiect C++/Java
 Programarea cu ajutorul componentelor
Entreprise Java Beans
 Criza dezvoltarii software
Erori grave
• Sonde spatiale pierdute (Venus ’60,
Marte 99)
• Criza rachetelor – Cuba 1979
• Rachetele Patriot 1991
• Primul zbor Ariane 5 1996 artificii de 5
miliarde $
• Aeroportul Denver 1994-1996
• Anul 2000
• Incidente în fiecare luna
- bursa din Tokyo …
- accidente de circulatie
Proiectarea software
•Livrarea în întârziere a tuturor
proiectelor
•Cost mult ridicat fata de cel
prevazut
•Livrarea unui produs de proasta
calitate
•Esuarea în majoritatea cazurilor
•Studiu american din 1995 : 81
miliarde $ / an datorat esecului
software
 Constructia podurilor si dezvoltarea
software
Ingineria civila Ingineria software
• Sistemele informatice devin foarte
•Esecuri mai putine repede extrem de complexe
•Surparea unui pod este foarte • Esecuri foarte numeroase
perculoasa pentru oameni • « Craparea » este un fenomen des
întâlnit si obisnuit
•O experienta de mai multe milenii • Pierderi minore în general
•Un pod stricat în general nu se • Cu exceptia sistemelor critice
repara ci se reconstruieste putem spune ca un produs software
nu poate anticipa orice situatie
•Podul rezista la 99% din conditii • Adaugarea sau schimbarea
functionalitatilor, de platforme
•Daca un pod este inutilizabil
atunci schimbam traseele
drumurilor
2.1 Cum se desfasoara în general un proiect ?

• Entuziasm general la început

• Un punct de criza în care se constientizeaza ca proiectul nu poate fi
predat la timp
• Spre sfârsit : un volum de munca impresionabil (24h/24h), resurse
umane suplimentare, tensiune si relatii încordate

Acest ciclu se repeta si în marile companii de soft la primele

proiecte realizate de catre o companie.
Principala cauza este incapacitatea de planificare si gestionare a
resurselor (timp, oameni, documentatie, utilitare, cunostinte, etc) .
2.2 Asa da, asa nu
Termen de
Punct de predare
criza

Efort

10

Pas 1 Pas 2 Pas 3

2.3 Ciclul de viata optim pentru derularea unui proiect

• Ciclu de viata = ansamblul etapelor parcurse în

dezvoltarea unui produs software.
• Etapele ciclului de viata :
1. Culegerea de specificatii
2. Analiza
3. Proiectarea
4. Implementarea si Testarea
5. Validare si Integrare
6. Calificare
7. Punerea în functiune
8. Mentinerea
9. Retragerea sau înlocuirea
2.3.1 Culegerea de informatii

• Definirea problemei, adica a ceea ce se da în problema, a resurselor

de care dispunem (alte sisteme informatice sau BD pe care le putem
utiliza, tehnici utilizabile, persoane care ar putea lucra,etc)
• Specificarea detaliata a functionalitatilor ce trebuiesc suportate de
catre sistemul informatic (adica realizarea diagramei de cazuri de
utilizare)
• Realizata prin caietul de sarcini
• Analiza functionala
2.3.1.1.Stabilirea obiectivelor

• Se face de catre managerul de proiect;

• Fiecarea idee buna trebuie promovata indiferent de
cel care a contribuit la ea;
D1 Clientul este cel care doreste acel produs.
D2 Utilizatorul este cel care doreste sa utilizeze acel
produs software.
D3 Dezvoltatorii sunt aceia care intentioneaza sa
« fabrice » acel produs.
2.3.1.2 Definirea necesitatilor

• Un caiet de sarcini este stabilit de catre client în

colaborare cu utilizatorul si dezvoltatorul :
- descrierea functionalitatilor asteptate de la
aplicatie;
- constrângeri non-functionale (timp de raspuns,
utlizarea memoriei, etc );
- posibilitatea utilizarii Diagramei de Cazuri de
utilizare;

Rezultatul acestei etape : Caietul de sarcini

2.3.2 Analiza

• Cautarea solutiilor corecte posibile

A gasi solutiile corecte posibile înseamna
- a alege tehnica de programare ( orientat obiect, procedural, componente);
- a gasi algoritmii potriviti si adaptarile lor la necesitatile problemei;
- determinarea modelului obiectual necesar dezvoltarii proiectului;
- a alege solutia software necesara dezvoltarii;(MySQL sau Oracle,Java sau C#,
JavaBuilder sau Eclipse,etc ).
- a gasi criteriile de dezvoltare (ergonomie, accesibilitate, rapiditate, etc )

• Identificarea caracteristicilor acestor solutii

Pentru solutiile gasite se va încerca o acomodare pe cazuri simple si studierea
caracteristicilor (comportamente,raspunsuri, timp de executie,etc ) în aceste
situatii de cercetare.
2.3.2.1 Analiza necesitatilor

• Este de fapt definitia produsului de realizat

- specificatiile precise ale produsului de realizat;
- constrângeri ce trebuiesc satisfacute;

Rezultatul acestei etape

- dosarul de analiza (specificatii functionale si non-
functionale)
- schita manualului utilizatorului ;
 2.3.2.2 Planificare
• Defalcarea proiectului în sarcini care se înlantuiesc în mod continu si logic.
• Afectarea fiecarui membru al echipei pentru o anumita durata si scop.
• Definitia normelor de calitate ce trebuiesc satisfacute .
• Alegerea metodelor de concepere si testare.
• Stabilirea dependentelor externe (umane, materiale, preturi, calitate a
serviciilor)
Rezultatul acestei etape
- Plan de calitate al produsului, Planul proiectului
- Estimarea costurilor reale
- Deviz destinat clientului (pret, întârzieri, livrabile)
 2.3.3 Proiectarea si faza de concepere
• Definirea arhitecturii software.
• Interfete dintre diferite module.
• Rolul acestei etape este de a concepe arhitectura de asa natura
astfel încât componentele produsului sa fie independente pentru a
facilita dezvoltarea.
Rezultatul acestei etape
- Dosarul de conceptie;
- Planul de integrare;
- Planul de testare;
- Actualizarea planning-ului ;
2.3.4 Implementarea

• Alegerea limbajului potrivit de dezvoltare

• Alegerea tehnologiei potrivite de dezvoltare (alegerea
serverului de baze de date, alegerea tehnologiei de stocare
a datelor, alegerea metodei de transmitere a datelor –
protocoale de comunicatii, sincronizare etc )
• Scrierea codului sursa / scripturi ,etc.
Rezultatele acestei etape
- Module codate
- Documentarea fiecarui modul
- Actualizarea planning-ului
2.3.4.1 Testarea

• Se verifica echivalenta dintre implementare si modelul

proiectat.
• Validarea implementarii în raport cu criteriile de
corectitudine identificate în etapa de analiza.
• Implementarea si testarea se face pentru fiecare modul în
parte.
• Testarea întregii aplicatii este o alta etapa din ciclul de viata
si trebuie facuta aceasta distinctie.
Rezultate
Module testate
Rezultatele testarilor unitare
2.3.5 Integrarea si validarea aplicatiei

• Fiecare modul este integrat cu celelalte conform planului de

integrare.
• Ansamblul este testat conform cu planurile de testare.
Rezultate
- Produs software testat
- Manual de instalare
- Versiunea finala a manualului de utilizare.
2.3.6 Calificarea produsului soft

• Teste de amploare realizate în conditii normale de utilizare.

• Teste non-functionale
- Teste de încarcare
- Teste de toleranta
Rezultate
Raportul de anomalii
2.3.7 Punerea în functiune

• Livrarea produsului final

• Instalarea produsului la client
• Sfârsit sau nu ?!

….
2.3.8 Mentinerea aplicatiei

• Raporturi de incidente sau anomalii

• Cerere de modificari corective
• Cereri de evolutie a aplicatiei
• Cod si documentatie modificata
• O noua serie de teste
- Unitare
- De integrare
- Non – regresive
3. Modele ale ciclului de viata

• Modelul în cascada
• Modelul în V
• RAD
• RUP
• 2TUP
• XP
 3.1 Modelul în cascada
Analiza
necesitatilor Modificarea
necesitatilor
Specificatii
functionale

Planificare

Concepere

Implementare

Integrare

Calificare

Exploatare

Retragere
Problemele modelului în cascada

• Proiectele adevarate rar urmeaza o dezvoltare secventiala

• Este dificil a stabili toate necesitatile proiectului la începutul sau
• Produsele soft dezvoltate urmând un model în cascada apar de cele
mai multe ori cu întârziere
• Acest model este aplicabil pentru proiectele care sunt bine întelese
 3.2 Modelul în V
Specificatii functionale
Calificare
si planificare

Conceptie globala Integrare

Conceptie detaliata Teste unitare

Programare
Comparatie

• Modelul în V permite
- O buna anticipare în dezvoltare
- Evita întoarcerea
• Dar
- Cadrul de dezvoltare este foarte rigid
- Durata este adesea foarte lunga
- Produsul soft apare adesea foarte târziu
3.3 RAD
Rapid Aplication Develoment

• Discutii si interactiuni cu utilizatorul

• Verificarea eficacitatii reale a unui algoritm
• Verficarea specificatiei interfetei cu utilizatorul (GUI)
• Metoda utilizata adesea pentru stabilirea si identificarea necesitatilor
• Utilizata adesea de catre generatoarele de coduri
3.4 RUP
Rational Unified Process