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 EC101, EG405
Craciunul
Sesiunea criza de timp, 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 impresionant (24h/24h),
resurse umane suplimentare (colegul de camera de anul 2),
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
Definitii
Initiere : este faza n care se :
- Stabileste domeniul proiectului;
- Stabilesc criteriile pentru validarea reusitei;
- Evalueaza riscurile;
- 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 : softul 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
Detaliu Workflow: Analiza problemei Workflow: cerinte
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 recomandabila
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 veti 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 utilitare 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
Timp de raspuns
Garantare raspuns in timp real
Utlizarea memoriei
Utilizarea retelei
Utilizarea scalabilitatii
Intrebari?



Va multumesc !