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 î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
•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
Ingineria software
• Sistemele informatice devin
foarte repede extrem de
complexe
• Esecuri foarte numeroase
• « Craparea » este un fenomen
des întâlnit 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
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 ?

 Întâlniri 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 sfârsit : 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
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)
 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;
- 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
 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, constrângeri 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 î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 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
 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
Modificarea
necesitatilor
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
Mini-concluzie

Clientul încearca « Ascultarea »

prototipul 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

Initiere Elaborare Constructie Tranzitie

Capacitate Produs
Obiective Arhitectura
operationala initiala fabricat
(Viziune)

timp
Elemente RUP

Workflow: cerinte Detaliu Workflow: Analiza problemei

Workers Artefactos
Activities
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. Constângeri 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.
 Pâna aum în majoritatea cazurilor studentii s-au confruntat cu
probleme simple a caror rezolvare se rezuma la maxim câteva
 Î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 . Gânditi-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
Etapa Functionalitati
 Stabilirea etapelor de
dezvoltare

 Stabilirea relatiilor dintre

diferitele etape de
dezvoltare

 Distribuirea sarcinilor
(adica ce sarcina are fiecare)
Microsoft Office Project: Editor si
utilitar pentru organizarea task-urilor
4.2.3 Gestiune
 Obiective si prioritati
 Ipoteze,dependente si constrângeri
 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 Constrângeri non-
functionale
 Timp de raspuns
 Garantare raspuns in timp real
 Utlizarea memoriei
 Utilizarea retelei
 Utilizarea scalabilitatii
Intrebari?

Va multumesc !