Title: Cuprins

Introducere
Fazele de realizare a unui produs software
Metodologii de dezvoltare
Criterii de selectare a unei metodologii
Metodologia cascada
Metodologia V
Metodologia spirala
Metodologii agile
SCRUM
Extreme Programming (XP)
Metodologia Rational Unified Process
Concluzii

Slide: 3

Title: Introducere

Aplicatiile sunt livrate cu defecte

Rata de erori si defecte nu ar fi tolerata pentru sistemele hardware
ENIAC 1946
Tehnologii, teorii, practici dezvoltate > software de calitate

Slide: 4

Title: Introducere

Evolutia echipamentelor hardware si a tehnologiilor software

Performanta hardware > 10 000 milioane ori
Performanta software > 500 ori
Multe produse software caracterizate prin:
Costuri ridicate
Intarzieri in realizare
Fiabilitate scazuta
Lipsa de satisfactie a clientului
Cum a crescut productivitatea software

Slide: 5

Title: Introducere

Care sunt motivele pentru care aplicatiile software sunt livrate cu defecte?
Software-ul mai complex decat hardware-ul
Greu de desoperit toate defectele in faza de testare
Care este solutia?

Slide: 6

Title: Introducere

Ciclul de viata al unui produs software (eng: Software Product Life Cycle)
Ciclul de realizare a unui produs software (eng: Software Development Life Cycle)
Slide: 7

Title: Ciclul de realizarea a unui produs software

Analiza cerintelor
Realizarea specificatiilor
Proiectare
Dezvoltare
Testare
Instalare
Mentenanta

Slide: 8

Title: Începutul unui proiect

Un proiect poate începe:

cu o idee a clientului
cu o idee a unei echipe de dezvoltare
Aceasta idee poate fi:
clara, bine definita
vaga, prost definita
Pentru a continua cu succes, este nevoie de
ingineria cerintelor.

Slide: 9

Title: Caracteristicile specificatiilor

Spun ce trebuie facut, nu cum

Sunt clare (neambigue)
Sunt suficient de detaliate
Sunt complete

Slide: 10

Title: Detalii de implementare la analiza?

10

NU
Clientul nu este competent in detalii tehnice
Clientul nu poate fi de acord in cunostinta de cauza cu
stipularile tehnice din specificatii.
E necesar sa restrangem multimea posibilelor solutiile
tehnice?
DA
Este nevoie sa integram intr-un sistem existent
Timpul de dezvoltare depinde de implementare
Intretinerea (costul) depinde de implementare
Slide: 11

Title: Responsabilitatile Analistului

11

sa extraga si sa clarifice cerintele clientului

sa ajute la rezolvarea diferentelor de opinie intre clienti si utilizatori.
sa sfatuiasca clientul despre ce este tehnic posibil sau imposibil
sa documenteze cerintele
sa negocieze si sa obtina o intelegere cu clientul.

Slide: 12

Title: Activitatile Analistului

12

Ascultare: Inregistreaza cerintele clientului.

Reflectare: Traduce cerintele in limbaj tehnic. Verifica pertinenta.
Scriere: Se cade de acord asupra formularilor.
Repeta pana cand se ajunge la o intelegere cu clientul in ceea ce priveste cerintele.

Slide: 13

Title: Probleme Potentiale

13

Procesul iterativ poate fi lung si complicat

Negocieri
Diferenta culturala dintre client si analist
Diferente intre cerintele clientului si ale utilizatorilor
Filmele SF vazute de client
Filmele SF vazute de programatori

Slide: 14

Title: Rezultatul Analizei

14

Document de specificatii
Acest document este folosit ca referinta
Provocari
Nivelul de detaliu
? Mare: mai precis, obtinut mai greu, munca inutila
? Mic: prea vag, nu poate ghida eficient dezvoltarea
Audienta documentelor
? 2 versiuni: una pentru client, alta pentru dezvolatori?
Notatia folosita
? Informala, semiformala, formala

Slide: 15
Title: Tipuri de specificatii

15

Specificatii functionale
Ce trebuie sa faca sistemul
Specificatii non-functionale
Specificatii privind datele
? Formatul datelor la intrare/iesire
? Formatul datelor din interiorul sistemului
Constrangeri
? tehnologice
? performanta
Recomandari
? Ajuta la luarea deciziilor de proiectare cand sunt mai multe
optiuni

Slide: 16

Title: Exemple

16

Body: Specificatii functionale

Sistemul se va opri in maxim 5 secunde dupa ce temperatura
procesorului atinge 80 grade Celsius.
Sistemul va permite cautarea si afisarea titlurilor cartilor
scrise de un anumit autor.
Specificatii privind datele
Datele vor fi exportate in format XML
Datele din tampoanele de intrare si iesire vor fi criptate
Constrangeri

Implementarea se va realiza folosind un limbaj orientat obiect.

Metodologia de dezvoltare va fi Prototipizare
Recomandari
Se va folosi cat mai putina memorie

Slide: 17

Title: Proiectare

Siguranta, flexibilitate si fiabilitate

Selectarea tehnologiilor utilizate
Impuse de client
Restrictrii date de software (ex. OS sau hardware)
Criterii de performanta
Descompounerea problemei in subprobleme
Implementarea modulara
Functiile fiecarui modul
Relatiile dintre module
Utilizare limbaj UML pentru descriere
Daca utilizam OOP trebui sa aplicam sabloane de proiectare
(design patterns)
Nivelul de detaliu ?

Slide: 18

Title: Implementare (Realizare)

Implementarea efectiva a codului

Testarea este parte integranta a procesului de implementare
Fiecare funcite, clasa sunt testate
Principiu de urmat: scrie mai intai testele si apoi functiile si clasele (Junit)
Documentarea codului (javadocs)
Pot aparea modificari ca urmare a unor probleme neprevazute
Pot aparea cerinte noi

Slide: 19

Title: Testare

Teste de functionare
Teste de performanta
Teste de acceptanta

Testare automata
Testare manuala

Echipa de testare conlucreaza cu echipa de programatori

Slide: 20

Title: Instalare

Incepe dupa ce programul a trecut testele

Acest proces este simplu sau complicat in functie de tipul aplicatiei. Ex: aplicatie desktop, aplicatie
de tip servicii web, etc.

Slide: 21

Title: Mentenanta

Instruirea utilizatorilor
Suport
Rezolvarea probleme care apar
Adaugare de noi functionalitati

Echipa ce realizeaza mentenanta != echipa de implementare

Slide: 22

Metodologii de dezvoltare a produselor software

Metodologii de dezvoltare software = este o subdisciplina in cadrul ingineriei software care se

ocupa cu definirea, structurarea si controlul procesului de dezvoltare a aplicatiilor software.
Cum efectuam activitatile indicate de SDLC
Exemple de metodologii:
Build and Fix
Metodologia cascada (cu feedback)
Metodologia V
Modelul în spirala
RUP (Rational Unied Process)
XP (Extreme Programming)

Slide: 23

Title: Clasificare metodologii

Dezvoltarea incrementala
Dezvoltarea iterativa
Incurajeaza comunicarea cu clientul
Sistemul evolueaza prin adaugarea de nou functionalitati in
fiecare iteratie
In primele iteratii se poate pune accentul pe functionalitatile
critice

Slide: 24

Title: Criterii pentru selectarea unei metodologii

Buget
Joaca un rol cheie
Dimensiunea echipei
Metodologii agile = echipe mici
Tehnologiile utilizate
Unelte si tehnici
Natura proiectului
Procese existente in companie

Slide: 25

Title: Build and FIX

Cowboy coding
O metodologie? utilizata de multe firme.
Costuri foarte ridicate pentru proiecte complexe
Produsul nu este livrat la timp
Prodosul are o calitate slaba
Nu este generata documentatie
Mentenanta este foarte dificial datorita lipse de documente de design si arhitectura

Slide: 26

Title: Metodologia Cascada

Slide: 27

Title: Metodologia Cascada

 Analiza
cerinte

Realizare specificatii

Proiectare

Implementare

Testare

Instalare integrare

Slide: 28

Title: Metodologia Cascada (cont.)

Este o metodologie secventiala

Utilizata de multe companiii mari
Aplicabil pentru proiectele care sunt bine definiti de la inceput
Iesirile unei faze reprezinta intrarile pentru faza urmatoare
Avantaje
Este un model riguros
Pune accent pe documentare
Este simplu, usor de inteles si de urmarit
Usor de insusit de catre membrii echipei
Dezavantaje
Nepractic in multe tipuri de proiecte
Ce se intampla daca clientul isi modifica cerintele pe parcursul proiectului?
Ce se intampla daca in faza de implementare se descompera ca o anumita componenta este difcil de
implementat asa cum a fost proiectata initial
?
Pot aparea probleme noi pe parcursul dezvoltarii

Slide: 29

Title: Metodologia V

Slide: 30

Title: Metodologia V

Analiza cerinte

Realizare specificatii

Proiectare
arhitectura

Implementare

Testare sistem

Teste de
integrare
 Testare
Unitati

Proiectare
detaliata

Testare de acceptanta

Slide: 31

Title: Metodologia V

Extensie a modelului cascada

Parcurgerea fazelor nu este liniara
Sunt definite 3 tipuri de faze
Fazele de verificare
Fazele de codare
Fazele de validare

Slide: 32

Title: Metodologia V

A fost dezvoltata in paralel in SUA si Germania

Este un model rigid
Testarea este activitate cheie in cadrul ciclului de dezvoltare
Evita intoarcerile
Durata de dezvoltare este lunga
Produsul apare tarziu
Partea superioara a V-ului implica utilizatorul final

Slide: 33

Title: Metodologia spirala

Slide: 34

Title: Metodologia Spirala

Slide: 35

Title: Modelul Spirala (cont.)

Un model adoptat in multe proiecte IT

Este un model iterativ
Potrivit pentru proiecte mari, complexe
Fiecare faza incepe cu analiza cerintelor si se incheie cu analiza de catre client a progreselor
realizate in cadrul iteratiei
Armata SUA a adoptat acest model pentru dezvoltarea sistemului Future Combat System (FCS)

Slide: 36

Title: Modelul Spirala (cont.)

Slide: 37
Title: Modelul Spirala (cont.)

Cerintele pentru sistem sunt descrise in detaliu

Este realizata o arhitectura preliminara a sistemului
Este construit un prim prototip pe baza arhitecturii preliminare – in mod uzual un model la scara al
produsului final
Un nou prototip este realizat urmand procedurile:
Este evaluat primul prototip in termeni de calitati, defecte si riscuri
Sunt definite ceinrtele pentru noul prototip
Este planificat si construita arhitectura pentru noul prototip
Este construit si testat al doilea prototip

Slide: 38

Title: Metodologii agile

Slide: 39

Title: Dezavantajele metodelor clasice de management a

proiectelor

For?e uriase în timpul etapei de planificare;

Resurse enorme pentru modificarea cerintele tehnice într-un mediu ce se schimba rapid;
Tratarea personalului ca factor de productie;

Slide: 40

Title: Rezultatul metodelor clasice

Haos datorita schimbarii cerintelor - cerintele unui proiect pot sa se schimbe în faza de
design,
implementare si chiar lansare. În mai toate metodologiile de dezvoltare, analiza este facuta în
partea de început a proiectului, si nici o schimbare nu mai este permisa pîna spre final.
Estimari nerealiste de timp, cost si calitate a proiectelor - managerul de proiect si dezvoltatorii tind
sa subestimeze cît timp si resurse sunt necesare pentru un proiect, si cîte functionalitati pot fi
livrate. Acestea nu pot fi niciodata prevazute 100% în faza de început a ciclului de dezvoltare.

Slide: 41

Title: Solutia?

Agile Software Development

Este un grup de metodologii de dezvoltare a aplicatiilor software
Au la baza principiile iterative
Minimizarea riscuri prin prin dezvoltarea in perioade scurte (iteratii)
Durata unei iteratii de la 1 la 4 saptamani
Fiecare iteratie cuprinde toate sarcinile
Fiecare iteratie poate fi privita ca un miniproiect
Rezultatul fiecarei iteratii este o noua versiune a produsului
Se pune accent pe comunicarea in timp real
Colaborare intre programatori si client
In general sunt echipe mici de dezvoltare

Slide: 42
Title: Caracteristicile Agile

Este iterativ: o iteratie are între 1-4 saptamîni,în rezultat sunt livrate anumite functionalitati
ale proiectului.
Este bazat pe timp:durata iteratiei e fixa si nu poate fi modificata pe parcursul proiectului. În acest
fel exista întotdeauna un rezultat productiv la finalul iteratiei.
Deschis catre client:la finalul fiecarei iteratii exista un rezultat care poate fi prezentat clientului.
Bazat pe livrarea de versiuni intermediare ale produsului: fiecare iteratie va implementa complet
toate “task-urile” cuprinse în acea iteratie

Slide: 43

Title: Metodologii agile

XP
SCRUM
DSDM,
Crystal,
Feature Driven
Lean Development
etc.
Toate folosesc principii de baza ale filozofiei Agile, dar o
implementeaza în moduri diferite.

Slide: 44

Title: Metodologiile agile

Prioritatea este satisfacerea nevoilor clientului prin livrarea în timp a soft-ului;

Cererile de schimbare sunt binevenite, chiar si în stadiile avansate ale dezvoltarii;
Livram frecvent soft functional, cu o frecventa saptamînala spre lunara, cu preferinta pentru
termene mai scurte;

Slide: 45

Title: Principiul Agile:YAGNI

"You Aren't Going To Need It... unless the business says so!".

Prin acest principiu suntem încurajati sa

implementam doar acele elemente pe care le solicita clientul si nimic mai mult!

Slide: 46

Title: Metodologia Scrum

Slide: 47

Title: Principiul metodologiei SCRUM

dezvoltarea incrementala a aplicatiei software;

livrari frecvente - de regula au loc o data la 4 saptamâni;
clientul primeste de fiecare data o aplicatie ce contine un numar tot mai
mare de functionalitati si care se afla în perfecta stare de functionare.
Slide: 48

Title: Metodologia SCRUM

Slide: 49

Title: Reguli în Scrum

Aceasta metoda necesita patru tipuri de sedinte :

Sedintele zilnice: echipa se reuneste în fiecare zi si petrece circa 15 minute, în picioare, pentru a
raspunde la urmatoarele trei întrebari: ce am facut ieri? Ce voi face azi? Cu ce obstacole ma
confrunt azi?
Sedintele de planificare: întreaga echipa se aduna pentru a decide care sunt functionalitatile care
vor alcatui urmatorul sprint, si pentru a actualiza lista generala.
Sedintele de revizuire a activitatii: în timpul acestei sedinte, fiecare membru prezinta ceea ce a facut
pe durata sprintului. Se organizeaza o
demonstratie a noilor functionalitati si o prezentare a arhitecturii. Aceasta este o
sedinta informala, de doua ore, la care participa toata echipa.
Sedintele retrospective: la finalul fiecarui sprint, echipa analizeaza aspectele care au functionat bine,
precum si pe cele care au functionat mai putin bine. În timpul acestei sedinte de 15–30 de minute,
se organizeaza un vot de încredere pentru a decide ce îmbunatatiri trebuie implementate.

Slide: 50

Title: Avantaje

reducerea documentatiei la minimul cu scopul sporirii productivitatii;

evitarea „efectului de tunel", adica faptul de a obtine rezultatul abia la livrarea finala si de a nu
întrezari nimic concret pe durata întregii faze de dezvoltare;
compunerea secventiala a continutului sprint-urilor permite efectuarea unei modificari sau
adaugarea unei functionalitati care nu era prevazuta initial. Acesta este principalul aspect care face
ca aceasta metoda sa fie „agila“;
metoda participativa: fiecare membru al echipei este invitat sa îsi exprime parerea si poate contribui
la toate deciziile luate în cadrul proiectului, fiind astfel mai implicat si mai motivat;
facilitarea comunicarii: lucrînd în aceeasi sala de dezvoltare sau fiind conectata prin intermediul
diferitelor mijloace de comunicare, echipa poate comunica usor si poate schimba informatii despre
impedimentele întâlnite în scopul eliminarii cât mai rapide a acestora;
ameliorarea cooperarii: comunicarea zilnica dintre client si echipa face
posibila o colaborare mai strânsa între cele doua parti;
cresterea productivitatii: prin eliminarea anumitor „exigente" specifice metodelor clasice, precum
documentatia;
timpul de livrare a produsului final se reduce semnificativ.

Slide: 51

Title: Riscuri si solutii

Dimensiunea echipei: fiind limitata la 7 -10 persoane, dimensiunea echipei se poate

transforma într-un obstacol daca se depaseste numarul de membri recomandat. În acest caz,
organizarea de sedinte devine
imposibila. Solutia consta în realizarea unui „Scrum of Scrums“ -
împartirea proiectului în echipe de dimensiuni standard si adaugarea
unei instante superioare care sa grupeze ScrumMasterii fiecarui Scrum;
Cereri multiple: cererile pot proveni din mai multe surse în cadrul unui proiect si pot uneori sa fie
dificil de gestionat datorita aspectului lor contradictoriu. Pentru a remedia aceasta problema,
trebuie sa se utilizeze în mod obligatoriu o aplicatie de gestiune a cererilor;
Calitatea produsului realizat: cu cât numarul echipelor este mai
mare, cu atât calitatea este mai greu de controlat. Pentru aceasta, este
important sa existe o politica de calitate riguroasa si un plan de calitate
a proiectului. Verificarea frecventa a codului si introducerea unor indicatori pentru masurarea
performantei programatorilor permit reducerea la minimum a acestui risc.

Slide: 52

Title: Organizare Scrum

Metodologia SCRUM implica interventia a trei protagonisti :

Product owner: responsabilul de produs si coordonatorul echipei
clientului. El este cel care defineste si stabileste functionalitatile
prioritare si alege data si continutul fiecarui sprint pe baza volumelor
de lucru comunicate de echipa.
ScrumMaster: acesta faciliteaza buna desfasurare a proiectului, are grija ca fiecare membru sa
poata lucra la capacitate maxima eliminând impedimentele si protejând echipa de perturbarile
exterioare. De asemenea, acorda o atentie speciala respectarii diferitelor faze SCRUM.
Echipa: fiind de regula alcatuita din circa 4-10 persoane, echipa
aduna la un loc specialistii necesari în cadrul unui proiect, si anume:
arhitectul, designerul, programatorul, testerul etc. Echipa se organizeaza singura si ramâne
neschimbata pe toata durata sprintului.

Slide: 53

Scrum demo

DEMO

Slide: 54

Title: Metodologia XP

Slide: 55

Title: Metodologia XP

Extreme Programming(XP)
XP descrie 4 principale activitai
Codare – principala activitate
Testare – orice modul implementat trebuie testa
Ascultare(comunicare) – programatorul trebuie sa comunice cu
clientul pentru a intelege necesitatile acestuia
Proiectarea – realizarea unei arhitecturi corecte a sistemului va eficientiza sistemul si va reduce
dependentele care nu sunt necesare intre diferitele module ale sistemului
Se preteaza pentru proiecte cu cerinte dinamice sau cele care nu sunt bine definite de la inceput
Trebuie sa existe un parteneriat intre client si programatori
Nu genereaza foarte multa documentatie
Slide: 56

Title: Metodologia XP (cont)

Slide: 57

Title: Extreme Programming

57

Extreme Programing (XP) este o model modern, usor (lightweight), de dezvoltare, inspirat
din RUP.
Dezvoltarea programelor nu înseamna ierarhii, responsabilitati si termene limita, ci înseamna
colaborarea oamenilor din care este formata echipa
Membrii echipei sunt încurajati sa-si afirme
personalitatea, sa ofere si sa primeasca cunoastere si sa devina programatori straluciti
XP considera ca dezvoltarea de programe înseamna în
primul rând scrierea de programe

Slide: 58

Title: Idei importante in XP

58
Echipa de dezvoltare nu are o structura ierarhica. Fiecare
contribuie la proiect folosind maximul din cunostintele sale.
Scrierea de cod este activitatea cea mai importanta.
Proiectul este în mintea tuturor programatorilor din echipa, nu în documentatii, modele sau
rapoarte.
La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerintelor.
Codul se scrie cât mai simplu.
Se scrie cod de test întâi.
Daca apare necesitatea rescrierii sau aruncarii de cod, aceasta se
face fara mila.
Modificarile aduse codului sunt integrate continuu (de câteva ori
pe zi).
Se programeaza în echipa (programare în perechi). Echipele se
schimba la sfârsitul unei iteratii (1-2 saptamâni).
Se lucreaza 40 de ore pe saptamâna, fara lucru suplimentar.

Slide: 59

Title: Metodologia RUP

Slide: 60

Title: Metodologia RUP

Rational Unified Process

Metoda iterativa dezvoltata de catre Rational Software
Este o colectie de procese ce descriu ciclul de dezvoltare al produselor software
Pune acent pe descriere proceselor sub forma unor diagrame – in contrast cu celelate modele
Utilizeaza UML ca limbaj de descriere
IBM ofera unelte pentru automatizarea proceselor descrise de RUP
Slide: 61

Title: Metodologia RUP (cont)

RUP defineste 6 principii de urmat

Dezvolta software-ul in mod iterative
Gestioneaza cerintele
Utilizeaza arhitecturi bazate pe component
Modeleaza in mod visual aplicatiile
Verificia calitatea software-ului
Gestioneaza schimbarile in software

Slide: 62

Title: Metodologia RUP (cont)

Procesele definite de RUP

Dimensiune timp, dimensiune statica

Slide: 63

Title: Metodologia RUP (cont)

Ciclul de dezvoltare al aplicatiei este descompus in sub- cicluri, fiecare ciclu este cumpus din
faze
Fazele sunt:
Initializare
Elaborare
Constructie
Tranzitie

Slide: 64

Title: RUP - Initializarea

Un document de viziune
Un model Use-case initial (10-20% complet)
Un plan de proiect cuprinzand fazele si iteratiile
O analiza a riscurilor
Un model de bussines daca e necesar
Unul sau mai multe prototipuri

Slide: 65

Title: RUP - Elaborare

Cea mai critica faza a proiectului

Cele mai importante componente ale sistemului sunt dezvoltate acum
Un model use-case (80% complet)
Capturarea cerintelor suplimentare
Arhitectura generala a sistemului
Un prototip executabil
Modelul de bussinis si riscurile revizuite
Planul de realizare al proiectului
Un manual preliminar de utilizare (optional)

Slide: 66

Title: RUP - Constructie

Restul componentelor nerealizate in faza anterioara constuite si integrate in produs

Toate componentele sunt testate
Rezultatul trebuie sa fie un produs pregatit pentru a fi livrat utilizatorului
Este realizat manualul de utilizare

Slide: 67

Title: RUP - Tranzitie

Produsul este instalat\livrat utiliatorului

Utilizatorul testeaza produsul
Defectele sunt raportate si fixate
Aceasta faza poate fi foarte simpla sau foarte complexa depinzand de tipul produsului (ex. Aplicatie
desktop, aplicatie pe mai multe niveluri)

Slide: 68

Title: RUP - Iteratii

Fiecare faza din RUP poate fi descompusa in iteratii

Avanatajele metodelor iterative
Riscurile sun gestionate mai bine
Schimbarile sunt mai usor de controlat
Calitate mai buna

Slide: 69

Title: RUP - Unelte

Rational Requisite®Pro--Keeps the entire development team updated and on track

throughout the application
development process by making requirements easy to write, communicate and change.
Rational ClearQuest™--A Windows and Web-based change-request management product that
enables project teams to track and manage all change activities that occur throughout the
development lifecycle.
Rational Rose 98--The world's leading visual modeling tool for business process modeling,
requirements analysis, and component architecture design.
Rational SoDA--Automates the production of documentation for the entire software development
process,
dramatically reducing documentation time and costs.
Rational Purify®--A run-time error checking tool for application and component software developers
programming in C/C++; helps detect memory errors.
Rational Visual Quantify™--An advanced performance profiling tool for application and component
software
developers programming in C++, Visual Basic, and Java; helps eliminate performance bottlenecks.
Rational Visual PureCoverage™ --Automatically pinpoints areas of code not exercised in testing so
developers can thoroughly, efficiently and effectively test their applications.
Rational TeamTest--Creates, maintains and executes automated functional tests, allowing you to
thoroughly test your code and determine if your software meets requirements and performs as
expected.
Rational PerformanceStudio™--An easy-to-use, accurate and scalable tool that measures and
predicts the performance of client/server and Web systems.
Rational ClearCase®--Market-leading software configuration management tool, giving project
managers the power to track the evolution of every software development project.

Slide: 70

Title: Concluzii