Managementul proiectelorManagementul proiectelor
Procese de dezvoltare
Curs, anul II Calculatoare
Procese de dezvoltare software (2)
E un set coerent si structurat de activităţi ce sunt necesare în dezvoltarea sau evoluţia unui produs softwaren SDP permite transformarea cerinţelor utilizatorilor intr-
un sistem software
Procesul de dezvoltare software (SDP)
un sistem software
n Funcţionalitatea adiţionala derivata din noi cerinţe poate fi adăugata unui software tot in urma unui SDP
Lipsa unui proces de dezvoltare software duce la lipsa de predictibilitate si erori (repetate)!
(SDP)(SDP)Cerinţe Cerinţe utilizatorutilizatorSistem Sistem
SoftwareSoftware
SumarDefiniţii, clasificări, perspectiveProcese de dezvoltare genericen Modelul in cascada si Proiectarea formalăn Dezvoltarea evolutivan Integrarea componentelor reutilizabilen Dezvoltari iterative: wDezvoltarea incrementala/ dezvoltarea in spirala
Modele de SDP modernen Procesele unificate (Rational)n Metodologii agile (SCRUM s.a.) si programare extreman Rolul cazurilor de utilizare si al instrumentelor CASE
- Procese software iterative -Cerinţele unui sistem evoluează întotdeauna pe parcursul unui proiectCel puţin stadiile iniţiale ale unui proces software pot fi considerate iterativeIteraţia poate fi aplicata oricăruia dintre modelele de procese generice anterioareDoua abordări principale (înrudite)n Dezvoltarea incrementalan Dezvoltarea in spirala
V. Dezvoltarea incrementalaDezvoltarea si livrarea unui produs software pot fi împartite in incrementeUn increment livrează o parte a funcţionalităţiiCerinţele utilizator se pun in ordinea priorităţii iar cerinţele cu cea mai înalta prioritate se includ in cerinţele cu cea mai înalta prioritate se includ in incrementele livrate devremeOdată ce demarează dezvoltarea unui increment, cerinţele pentru acesta sunt îngheţateCerinţele pentru celelalte incremente pot continua sa evolueze
Suprapunerea temporala a incrementelor
Incrementare = Adaugare
Dualitatea abordarilor incrementale
“Incremental means adding, iterative means reworking” (Alistair Cockburn)Strategia iterativa: dezvoltarea repetata a unor parti din sistem in scopulrevizuirii si imbunatatiriiStrategia incrementala: etapizare si planificare pt. ca partile diferite ale unui sistem sa fie dezvoltate la momente si cu viteze diferite si integrate pemasura ce sunt finalizate
Increment Iterate
fundamentally means “add onto”.
fundamentally means “change”.
repeating the process on a new section of work.
repeating the process on the same section of work
repeat the process (design, implement, evaluate)
repeat the process (design, implement, evaluate)
Iterativ
\
Prima iteratie livreaza o parte din functionalitate (Feature1) pentrua o evalua (corect/ tb. revizuit)Dupa a doua iteratie, desirevizuite, unele parti inca au nevoie de imbunatatiriA treia iteratie livreaza o parte din functionalitatea (Feature1) finala si stabila
Incremental
Primul increment livreaza o parte a functionalitatii intreguluisistemAl doilea increment livreaza o alta parte a functionalitatiiintregului sistemAl treilea increment livreazarestul functionalitatii intreguluisistem
Avantajele dezvoltării incrementale
Valida teincrement
Develop systemincrement
Design systemarchitecture
Integrateincrement
Valida tesystem
Define outline requirements
Assign requirements to increments
Final
System incomplete
Finalsystem
O parte a funcţionalităţii este livrata mai devreme Primele incremente acţionează ca prototipuri si ajuta la demonstrarea cerinţelor pentru următoarele incrementeSe reduce riscul eşecului global al proiectuluiServiciile sistem prioritare sunt cele mai testateAvantajele dezv. incrementale sunt evidente si printr-o evolutie moderna a sa - eXtreme Programming (XP)
VI. Dezvoltarea in spiralaPropusa de Barry Boehm (1988)Reluarea proceselor se reprezintă ca o spirala, iar fiecare fază printr-o bucla in spirală; de ex. n fezabilitatea sistem pe bucla interioara,
definirea cerintelor pe bucla urmatoare, n definirea cerintelor pe bucla urmatoare, n proiectarea sistem pe a treia etc.
Nu exista faze fixe, precum analiza sau testarea – buclele spiralei sunt alese in funcţie de ceea ce este necesar la un moment datCaracteristica principala a sa este recunoastereaexplicita a riscului: Riscurile sunt in mod explicit evaluate/ rezolvate pe parcursul procesului
Cele 4 sectoare ale modelului spiral
Alegerea obiectivelorn Sunt identificate obiectivele specifice ale fazei, constrângerile
asupra procesului şi produsului, riscurilen Se face planificarea detaliata, inclusiv alternativele
Evaluarea şi Reducerea risculuin Activităţile se desfăşoară a.î. să se reducă riscurile cheie; de ex. n Activităţile se desfăşoară a.î. să se reducă riscurile cheie; de ex.
riscul unor cerinţe necorespunzătoare→ elaborarea unui prototipDezvoltarea şi Validarean Se alege un model de dezvoltare pentru sistem (poate fi oricare
model generic), in funcţie de riscurile majore identificatew Ex. (risc dominant) (model de dezvoltare)
GUIs corecte dezvoltarea evolutivasiguranţa sistem transformări formaleintegrarea subsistemelor dezvoltare in cascada
Revizia si Planificarean Se face revizia proiectului şi se planifică următoarea fază a spiralei
Model spiral al unui proces software(Sommerville, 2000)
Riskanalys is
Riskanalys is
Riskanalysis
Prototype 2Prototype 3
Opera-tionalprotoype
Evaluate alternativesiden tify, resolve risk s
Determine ob jectivesalternatives and
cons traints
Riskanalysis Proto-
type 1
Prototype 2 protoype
Concept o fOperation
Simulations, models, b enchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Prod uctdesign Detailed
design
CodeUnit tes t
Integr ationtestAccep tance
testServ ice Develop, v erifynext-level p rod uct
Plan next p hase
Integrationand test p lan
Developmentplan
Requirements planLife-cycle plan
REVIEW
Derularea unei activităţi in modelul spiral: analiza cerinţelor
Analiza cerinţelor acoperă un ciclu lungFazele extreme sunt:
n colectarea cerinţelor iniţiale n separarea cerinţelor
Paşi:n Colectarea cerinţelor bruten Rafinarea cerinţelor
Rafinarea cerinţelorLa finalul pasului 1, echipa de
dezvoltare va fi probabil confruntată cu prea multe cerinţe, nu toate prioritare
Obiectivul acestui pas este de a procesa mai departe cerinţele; se obţine o listă prioritizată
Se examinează pentru fiecare cerinţă în parte:n Rafinarea cerinţelor
n Documentarea cerinţelor
Colectarea cerinţelor bruteÎncepe prin dialog cu experţii în domeniu Un model minimal (prototip) poate furniza un
context util acestui dialogPot fi utilizate instrumente software
specializate, ca EasyRM Requirement Management Suite, AnalystPro
în parte:1. Incluziunea în domeniul (scopurile) proiectului; cerinţele în afară vor fi eliminate2. Redundanţa fată de alte cerinţe. Redundanţele trebuie rezolvate.3. Prioritatea: pe termen scurt, mediu sau lung
Documentarea cerinţelorDocumentaţia cerinţelor reprezintă o
documentaţie de referinţa
Modele de SDP moderneProcesele unificate (Rational)Procesele unificate (Rational)Metodologii uşoare (agile)Programarea extremă (XP)
nUtilizarea instrumentelor CASE
Modelul USDPSe bazeaza pe modelul iteratiilor controlate(Controlled-Iteration Model)In esenta, fiecare iteratie majora suporta patrufaze:n Initiere: Negociere si definire produs pentru iteratian Initiere: Negociere si definire produs pentru iteratia
curentan Elaborare: Design produsn Constructie: Creare produs complet functionaln Tranzitie: Livrare produs in cadrul fazei conform cu
cele asumateCaracteristic este si faptul ca faza urmatoare este pornitainaintea sfarsitului fazei precedente (aprox. dupa 80% din derularea celei precedente)
Rational Unified Process(principala varianta USDP)
Business Modeling
Analysis & Design
PhasesProcess Workflows
Requirements
Elaboration TransitionInception Construction
ManagementEnvironment
ImplementationTest
Preliminary Iteration(s)
Iter.#1
Iterations within phases
Supporting Workflows
Iter.#2
Iter.#n
Iter.#n+1
Iter.#n+2
Iter.#m
Iter.#m+1
Deployment
Configuration Mgmt
RUP este “Arhitecture Centric”
Logical View
Implementation View
Programmers Analysts/
End-user
Process View
Deployment View
Programmers Software management
PerformanceScalabilityThroughput
System IntegratorsSystem topologyDelivery, installationcommunication
System Engineering
Use-Case View
StructureDesigners End-user
Functionality
Condus de cazurile de utilizare
Ciclul de dezvoltare si de viata al software-ului
Captura iniţiala a cerinţelor sistemului
Dezvoltarea condusa de cazurile de utilizare
Un caz de utilizare este o parte a funcţionalităţii unui sistem, ce oferă un rezultat/valoare semnificativaCazurile de utilizare specifica cerinţele sistemului si conduc procesele de:n proiectaren proiectaren implementare întreaga dezvoltare sistemn testare
Cazurile de utilizare reprezintă sursa in construcţia cazurilor de testareCazurile de utilizare si arhitecturile sunt dezvoltate împreuna in timpul dezvoltării sistemului
Un cadru procesual iterativ...Recunoaste realitatea schimbarii cerintelorGestioneaza timpuriu riscurile, prin impartirea dezvoltariisistemului si tratarea intai a partilor ce implica risc marePermite “un pic de planificare, un pic de design si un picde scriere de cod”de scriere de cod”Incurajeaza implicarea timpurie a tuturor participantilor, incl. testeri, integratori, documentaristi (technical writers)Permite auto-acordarea procesului cu fiecare iteratie, decicorectia erorilor aparute si punerea in practica a “lectiilorinvatate” cu fiecare iteratieSe focalizeaza pe arhitectura componentelor, nu pelivrarea finala a sistemului complet
Un cadru procesual incremental…Permite evolutia software-ului in mod natural, nefiindnecesara producerea sa intr-un effort majorPermite imbunatatirea software-ului, dandu-se suficienttimp procesului evolutivForteaza accentul pe stabilitate, fiindca doar o bazaForteaza accentul pe stabilitate, fiindca doar o bazastabila poate suporta multiple adaugariPermite unui nucleu de sistem sa ruleze efectiv mult maidevreme autonomPermite progresului interimar sa continue prin adaugareade functionalitatiGestioneaza mult mai bine riscurile prin expunerea maidevreme a problemelor in procesul de dezvoltare
Infruntarea riscurilor
InceptionArchitectural prototype
Draft specifications & models
ElaborationInitial executable system
Refined specifications & models
Focus pe cei 20% ce conteaza:• Cazuri de utilizare primare• Componente arhitecturale• Scenarii
Inception
Iteration 3... Construction
Final system
Intermediate system
Transition
Risk
Risk
Fluxuri de lucru in RUP
Core Process
Workflows
Core Process
WorkflowsWorkflowsWorkflows
Support Process
Workflows
Support Process
Workflows
Faze si iteratii
Initiere Intelegem CE construimSe defineste domeniul proiectului; se dezvoltacazurile de business si cele de utilizare critice
Inception Elaboration Construction Transition
timetimetimetime
cazurile de business si cele de utilizare critice
Elaborare Intelegem CUM construimPlanificare proiect, specificare caracteristici sifunctii, arhitectura de baza
Constructie Construim produsulProducere produs beta
Tranzitie Tranzitia produsului catre useriProducere produs final
Iteratia ca Waterfall
Intr-o iteratie, se parcurgtoate fluxuriletoate fluxurilede lucru
Metodologii agile. Principii:Implicarea utilizatoruluin Rolul său este de a prioritiza noile cerinţe şi de a
evalua iteraţiile sistemuluin Trebuie avută in vedere pe tot parcursul procesului de
dezvoltaredezvoltare
Oamenii sunt importanţi, nu procesuln Abilităţile echipei de dezvoltare trebuie recunoscute şi
exploataten Echipa trebuie lăsată să-şi contureze propriile
modalităţi de lucru, fără a i se da reţete
Principiile metodelor agile (cont.)
Livrarea incrementalăn Programul este dezvoltat incremental, utilizatorul doar
indica cerinţele care trebuie incluse la fiecare iteraţie
Acceptarea schimbăriiAcceptarea schimbăriin Echipa trebuie să se aştepte că cerinţele se schimbăn Proiectarea sistemului trebuie făcută astfel încât să se
adapteze uşor la aceste schimbăriMenţinerea simplităţiin Concentrare pe simplitate atât în programele
dezvoltate cât şi în procesul de dezvoltaren Oricând e posibil, complexitatea din sistem se elimină
Abordari agile vs. clasice
Specificatii cunoscute sau vagi
Problemele metodelor agileEste dificilă menţinerea interesului clienţilor implicaţi în procesMembrii echipei pot fi incapabili să se adapteze la implicarea intensă caracteristică metodelor agileagileCând există mai mulţi factori de decizie, este dificilă prioritizarea schimbărilorMenţinerea simplităţii necesită lucru suplimentarContractele pot fi o problemă în cazul dezvoltării iterative
Cerinta “Time-Box” (limitarea dezvoltarii temporale)
Se aplica in special pentru:n Analiza cerintelorn Design initial
Sub forma:Sub forma:while( not done )
{Develop a version within a bounded timeDeliver to customerGet feedbackPlan next version
}
Modelul SCRUM
Start
Cadru modern agil, aplicabil cand un proiect nu se poate imparti in faze clare, ca in modelul spiral
Un mic grup (pachet) de jucatori esteresponsabil de recuperarea mingii in gramada (scrum) si avansul echipei
Goal
Principii ale Scrum
Intotdeauna sa ai un produs pe care sa-l poti livra, c.p teoretic: sa poti declara oricand “gata”
Build-uri timpurii si dese
Teste continue de produs sincrone cu build-urileTeste continue de produs sincrone cu build-urile
Asumarea posibilitatii schimbarii cerintelor: de aici necesitatea de adaptarea la schimbarea cerintelorde piata in cursul dezvoltarii
Micile echipe lucreaza in paralel pentru a maximizacomunicatia si a minimiza overhead-ul
Concepte folosite in Scrum(http://www.controlchaos.com/ap.htm)
Sprint – cadente de lucru succinte (1-3 saptamani) ce implica si evaluarea produsuluiBacklog – “wish list” cu toate cerintele la care produsul complettrebuie sa raspunda. Backlog item-urile sunt prioritizate
Obiecte/Componente – module reutilizabile auto-continute
Pachet - grup de obiecte in cadrul caruia backlog item-urile sunt implementate
Echipa - grup de cel mult 6 persoane ce lucreaza la un pachet
Issue – chestiune ce tb, rezolvata inainte de a asigna un backlog item unui pachet/ probleme ce se rezolva prin schimbarea unui pachet
Solutie – rezolvarea unei chestiuni sau a unei probleme
Schimbari – activitati ce tb. efectuate pentru a rezolva o problema
Riscuri - sunt asociate unei probleme, issue ori backlog item
http://www.controlchaos.com/ap.htm
Alte modele agile
RAD (Rapid Application Development):time-boxed, prototipizare iterativa
JAD (Joint Application Development): JAD (Joint Application Development): Focus pe modele in curs de dezvoltarepartajate intre utilizatori si dezvoltatori
Programarea extremaEste o noua abordare, in care se dezvolta si se livreaza foarte mici incremente ale funcţionalităţiiEste considerata o metodologie “lightweight” şi o metodă de programare „agilă”, adecvată RAD (dezvoltării rapide a aplicaţiilor)XP consideră că dezvoltarea programelor nu înseamnă XP consideră că dezvoltarea programelor nu înseamnă ierarhii, responsabilităţi şi termene limită, ci colaborarea oamenilor din care este formată echipaAceştia sunt încurajaţi să îşi afirme personalitatea, să ofere şi să primească cunoştinţeXP consideră că dezvoltarea de programe înseamnă în primul rând scrierea de programe, nu documente, şedinţe şi rapoarte
Particularităţi ale XP (Beck)
XP se bazează pe: n îmbunătăţirea constanta a coduluin implicarea utilizatorilor, chiar includerea lor in
echipele de dezvoltareechipele de dezvoltaren programarea “pereche” - 2 programatori la un
ecrann scrierea testelor înaintea programelorn menţinerea testelorn obţinerea rapida a unui sistem minimal si
evoluţia sa in direcţia cea mai urgenta
“Carta drepturilor” (1)Ca dezvoltator, ai dreptul:n Să ştii ceea ce se cere, prin cerinţe clare, cu declaraţii
clare de prioritaten Să spui cât îţi va lua să implementezi fiecare cerinţă,
şi să îţi revizuieşti estimările în funcţie de experienţăşi să îţi revizuieşti estimările în funcţie de experienţăn Să îţi accepţi responsabilităţile, în loc ca acestea să-ţi
fie atribuiten Să faci treabă de calitate în orice momentn La linişte, distracţie şi muncă productivă şi plăcută
“Carta drepturilor” (2)Ca utilizator, ai dreptul: n La un plan general, să ştii ce poate fi făcut, când, şi la
ce preţn Să vezi progresul într-un sistem care rulează şi care se
dovedeşte că funcţionează trecând teste repetabile pe care le specifici tucare le specifici tu
n Să te răzgândeşti, să înlocuieşti funcţionalităţi şi să schimbi priorităţile
n Să fii informat de schimbările în estimări, destul de devreme pentru a putea reduce cerinţele astfel ca munca să se termine la data stabilită
n Poţi chiar să te opreşti la un moment dat şi să rămâi cu un sistem folositor care să reflecte investiţia până la acea dată
Caracteristici XPEchipa de dezvoltare nu are o structură ierarhică; fiecare contribuie la proiect folosind maximul din cunoştinţele saleProiectul este în mintea tuturor programatorilor din echipă, nu în documentaţii, modele sau rapoarteechipă, nu în documentaţii, modele sau rapoarteCerinţele clientului sunt exprimate ca scenarii sau povestiri (“user stories”)Acestea sunt scrise “pe bileţele”, echipa le împarte în sarcini de implementare (care stau la baza planificării orarului de lucru şi estimărilor costurilor)La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerinţelor
Scrierea de cod este activitatea cea mai importantăLa fiecare pas se face numai ce este absolut necesar în momentul următorCodul se scrie cât mai simplu şi se optimizează de câte ori e posibil (refactorizare)Se scrie mai întâi cod de test
Alte caracteristici XP
Se scrie mai întâi cod de testPoate apare necesitatea rescrierii sau eliminării coduluiModificările aduse codului sunt integrate continuu (de câteva ori pe zi)Se programează în echipă (programare în perechi); echipele se schimbă la sfârşitul unei iteraţii (1-2 săpt.)Se lucrează maxim 40 de ore pe săptămână
Suport automat de proces (CASE)Termenul generic CASE (Computer-aided software engineering) unifică acel tip de software destinat sa suporte dezvoltarea/evoluţia proceselor softTipuri de activităţi automatizate prin CASEn Editoare grafice pentru dezvoltarea modelului sistemn Editoare grafice pentru dezvoltarea modelului sistemn Dicţionare de date pentru managementul entităţilorn Constructoare pentru GUIs n Depanatoare pentru găsirea erorilor de programaren Translatoare automate pentru generarea versiunilor
noi ale unui sistem software
Tehnologia CASESuportă toate activităţile proceselor softwareA adus îmbunătăţiri semnificative in SDPLimitarea suportului CASE pentru procesele software are următoarele cauze:
Ingineria software necesita in mare măsura gândire n Ingineria software necesita in mare măsura gândire creativa – care nu este uşor de “automatizat”
n Ingineria software are in centru activităţi in echipa; pentru proiectele mari o mare parte din timp se consuma in interacţiuni:w in cadrul echipeiw intre echipe
Clasificarea instrumentelor CASEPermite înţelegerea potenţialului lor de suport
pentru activităţile proceselor softwarePerspectiva funcţionalan Instrumentele CASE se clasifica conform cu funcţia
lor specificalor specificaPerspectiva procesualan Instrumentele CASE diferă după activităţile de proces
suportatePerspectiva integrativan Instrumentele CASE se clasifica conform cu
organizarea lor in unităţi integrate
Clasificarea instrumentelor CASEDomeniu tool ExemplePlanificare Diagrame Gantt si PERT, instrumente de
estimare, spreadsheet-uri
Editare Editoare si procesoare de texte, editoare dediagrame
Managementul schimbarii Tool-uri pentru urmarirea (indeplinirii)cerintelor, sisteme de control al schimbarii
Managementul configuratiei Managementul versiunilor, constructiasistemelor
Prototipizare Limbaje de nivel foarte inalt, generatoare deinterfete utilizatorinterfete utilizator
Suportul metodelor (paradigmelor) Editoare pentru proiectare, dictionare dedate, generatoare de cod
Procesoare de limbaj Compilatoare, interpretere
Analiza de program Generatoare de referinte incrucisate,analizoare statice si dinamice
Testare Generatoare de date de test, comparatoarede fisiere
Depanare Sisteme interactive de depanare
Documentare Programe de asezare in pagina, editoare deimagini
Re-engineering Sisteme pentru (generare de) referinteincrucisate, sisteme de re-structurare aprogramului
O clasificare bazata pe activităţiReengineering tools
Testing tools
Debugging tools
Program analysis tools
Language-processingtools
Method support tools
Prototyping toolsPrototyping tools
Configurationmanagement tools
Change management tools
Documentation tools
Editing tools
Planning tools
Specification Design Implementation Verificationand
Validation
Integrarea instrumentelor CASEExistă:
Instrumente de tip “tool” (unealta singulara)n Pentru suportul task-urilor de proces individuale (de
ex. verificarea consistentei proiectării, editarea)Instrumente de tip “workbench”Instrumente de tip “workbench”n Pentru suportul etapelor (fazelor) de proces (de ex.
specificarea sau proiectarea)n In mod normal includ un număr de tool-uri, integrate
Mediin Pentru suportul integral sau major al SDPn In mod normal includ cateva workbench-uri integrate
Integratedenvironments
Process-centredenvironments
FilecomparatorsCompilersEditors
EnvironmentsWorkbenchesTools
CASEtechnology
Instrumente CASE
Single-methodworkbenches
General-purposeworkbenches
Multi-methodworkbenches
Language-specificworkbenches
Programming TestingAnalysis anddesign
Integratedenvironments
Process-centredenvironments
FilecomparatorsCompilersEditors
Top Related