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