Managementul si

dezvoltarea proiectelor
software
UNIT 1. Managementul proiectelor
Obiective
Ingineria software ?!
Ciclul de viata al unui produs software
Modele de dezvoltare software
Caietul de sarcini
1.Ingineria software ?!
De ce inginerie software?
Definitia ingineriei software

1.1 De ce inginerie software ?
Pentru a se trece
de la dezvoltarea ad-hoc si imprevizibila

la

o dezvoltare strucurata, constructiva si
sistematica
Istorie
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 ntrziere 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 software
Sistemele informatice devin
foarte repede extrem de
complexe
Esecuri foarte numeroase
Craparea este un fenomen
des ntlnit si obisnuit
Pierderi minore n general
Cu exceptia sistemelor critice
putem spune ca un produs
software nu poate anticipa orice
situatie
Adaugarea sau schimbarea
functionalitatilor, de platforme
Ingineria civila
Esecuri mai putine
Surparea unui pod este foarte
perculoasa pentru oameni
O experienta de mai multe milenii
Un pod stricat n general nu se
repara ci se reconstruieste
Podul rezista la 99% din conditii
Daca un pod este inutilizabil
atunci schimbam traseele
drumurilor
1.2 Definitia Ingineriei Software
Disciplina ( = metode,tehnici, utilitare )
bazata pe cunostinte (teorie)
pe cunostinta de a face,produce ceva (pragmatica)
si de a face sa se stie (comunicare)
pentru a produce (dezvoltare)
n mod industrial (marime)
aplicatii software (produse)
de cea mai buna calitate

2.Ciclul de viata al unui produs
software


Cum se va desfasura proiectul de la
Inginerie Software ?

ntlniri la 3F, C15, Zambara
Craciunul , deci nu facem nimic
Sesiunea . Oau , mi se nvrte totul n cap
Iadul studentesc .
2.1Cum 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 sfrsit : un volum de munca impresionabil (24h/24h),
resurse umane suplimentare (colegul de camera de anul 4),
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
10
Punct de
criza
Termen de
predare
Efort
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)
Este de fapt realizata prin caietul de
sarcini
Analiza functionala (vezi Curs 2 UML)
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;
- constrngeri 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;
- constrngeri 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, ntrzieri, livrabile)

2.3.3 Proiectarea
La modelele rezultate n urma etapei de analiza
se adauga noi elemente pentru a defini o solutie
particulara ce transpune problema n cauza.
Proiectarea trebuie sa aibe n vedere
optimizarea unor criterii de dezvoltare.
Proiectarea este de fapt o rafinare a modelului
obiectual ( o diagrama de clasa aproape
perfecta, constrngeri pentru atribute si metode,
coerenta modelului )
Faza de concepere
Definirea arhitecturii software.
Interfete dintre diferite module.
Rolul acestei etape este de a concepe arhitectura de asa
natura astfel nct 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 si testarea
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

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.De fapt testarea se mparte n doua : este vorba
de testarea pentru fiecare modul al aplicatiei dar si
testarea ntregii aplicatii.Testarea ntregii aplicatii este de
fapt 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 la pana
Rezultate
Raportul de anomalii
2.3.7 Punerea n functiune
Livrarea produsului final
Instalarea produsului la client
Sfrsit 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
Specificatii
functionale
Planificare
Concepere
Implementare
Integrare
Calificare
Exploatare
Retragere
Modificarea
necesitatilor
Problemele modelului n cascada
Proiectele adevarate rar urmeaza o
dezvoltare secventiala
Este dificil a stabili toate necesitatile
proiectului la nceputul sau
Produsele soft dezvoltate urmnd un
model n cascada apar de cele mai multe
ori cu ntrziere
Acest model este aplicabil pentru
proiectele care sunt bine ntelese
3.2 Modelul n V
Specificatii functionale
si planificare
Conceptie globala
Conceptie detaliata
Programare
Teste unitare
Integrare
Calificare
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 trziu
Mini-concluzie
Clientul ncearca
prototipul
Ascultarea
clientului
Construirea sau
ameliorarea prototipului
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
Workflow= disciplina
Definitii
Initiere : este faza n care se :
- Stabileste domeniul proiectului;
- Stabilesc criteriile pentru stabilirea reusitei;
- Evalueaza riscurilor;
- Estimeaza resurselor necesare;
- Un grafic de executie preliminar,raportat la cele patru
faze principale.
Elaborare :stabilirea unei arhitecturi robuste,adica se
realizeaza planul proiectului si se elimina factorii de risc
majori.
Constructie : n mod iterativ si incremental se va
implementa un produs complet.
Tranzitie : sosftul este livrat utilizatorilor pentru testarea (
versiune beta a sistemului )
Faze de dezvoltare
timp
Obiective
(Viziune)

Arhitectura

Capacitate
operationala initiala

Initiere Elaborare Constructie Tranzitie
Produs
fabricat
Elemente RUP
Workflow Detail:Analyse the Problem Workflow: Requirements
Activities
Workers
Artefactos
3.5 2TUP : Two Track Unified Process
Se concentreaza n jurul
arhitecturii sistemului de
proiectat
Propune un ciclu de
dezvoltare n Y
Se poate adapta pentru
proiecte de orice marime
3.6. XP EXtreming Programming
Este recomndabila pentru
echipele de maxim 10
persoane
4 valori :
-Comunicare
-Simplitate
-Feedback
-Curaj
4.Caietul de sarcini
Ce este un caiet de sarcini ?
Structura
1. Introducere
2.Organizarea proiectului
3.Gestiune
4.Tehnici
5.Calendar si Buget
6.Functiile produsului
7.Constngeri non-functionale
4.1 Ce este un caiet de sarcini ?
Caietul de sarcini constituie fundamentul pentru orice proiect.
El ne furnizeaza de fapt un ghid despre ce avem de facut n cadrul
proiectul la care vom avea de lucru.
Pna aum n majoritatea cazurilor studentii s-au confruntat cu probleme
simple a caror rezolvare se rezuma la maxim cteva
n cazul problemelor de matematica un mic caiet de sarcini era
reprezentat de ceea ce se scrie nainte de a rezolva problema,adica
ipoteza si concluzia.
Daca nsa problema pe care o avem de efectuat este una mai complicata
atunci trebuie efectuat un adevarat caiet de sarcini.
De exemplu daca trebuie organizata o excursie atunci este necesara
realizarea unui caiet de sarcini.
n viata de zi cu zi,conceptul de caiet de sarcini este utilizat frecvent .
Daca guvernul doreste sa construiasca autostrada Timisoara-
Budapesta, atunci va face un concurs la care firmele care vor dori sa
construiasca aceasta autostrada vor participa prin caietul de
sarcini.Practic vom avea de-a face cu un concurs al caietelor de sarcini.
4.2.1 Introducere
Rezumatul contine o descriere detaliata a aplicatiei, asupra
scopului aplicatiei respective, a directiilor de cercetare pentru
atingerea obiectivelor aplicatiei si alte amanunte considerate
esentiale n ntelegerea aplicatiei .
Materiale ce trebuiesc livrate clientului, adica
produsul soft, bibliotecile asociate, documentatie tehnica, manualul
utilizatorului,etc.
Definitii si acronime . Gnditi-va ca un client poate nu va
pricepe tot ceea ve-ti scrie n acest caiet,mai ales termenii
specifici.n aceasta rubrica aveti sansa sa faceti cunoscut limbajul
utilizat.
4.2.2 Organizarea proiectului
Stabilirea etapelor de
dezvoltare

Stabilirea relatiilor dintre
diferitele etape de
dezvoltare



Distribuirea sarcinilor
(adica ce sarcina are fiecare)
Etapa Functionalitati
Microsoft Office Project
Editor si utilitar pentru organizarea task-
urilor

4.2.3 Gestiune
Obiective si prioritati
Ipoteze,dependente si constrngeri
Gestiunea riscului
Mijloace de control

4.2.4 Tehnici
Metode si utilitare utilizate
- Metode si utilitare utilizate n proiectare
- Metode si utilitare utilizate n dezvoltare
- Metode si utilitarea utilizate n crearea documentatiei
- Metode si utilitare utilizate n testare
- Metode si utilitare utilizate n integrarea modulelor
- Utilitar pentru asigurarea gestiunii proiectului

Documentatie
- Documentatia utilizata pentru folosirea metodelor si utilitarele de
mai sus
- Documentatia proiectului (JavaDoc sau Doxygen)
http://www.stack.nl/%7Edimitri/doxygen/index.html Doxygen
http://java.sun.com/j2se/javadoc/ JavaDoc

4.2.5 Calendar si buget
Calendarul desfasurarii proiectului, adica
perioada n care trebuie efectuata o anumita sarcina,cine trebuie sa
o efectueze si care va fi rezultatul muncii din acea etapa, cum vom
evalua rezultatul acelei etape.
Bugetul alocat
Resurse, adica de ce avem nevoie pentru a realiza acest
proiect : resurse umane, calculatoare, soft-uri, resurse de
documentare,etc.

4.2.6 Functiile produsului
Este de fapt o transpunere a diagramei
cazurilor de utilizare.
Pentru fiecare actor vom determina
functiile pe care acesta ar intentiona sa le
utilizeze.
4.2.7 Constrngeri non-functionale




Va multumesc !