Managementul proiectelor - ace.catalinamancas.roace.catalinamancas.ro/ACE/SDP1.pdfCurs, anul II...

39
Managementul proiectelor Managementul proiectelor Procese de dezvoltare Curs, anul II Calculatoare Procese de dezvoltare software (1)

Transcript of Managementul proiectelor - ace.catalinamancas.roace.catalinamancas.ro/ACE/SDP1.pdfCurs, anul II...

Managementul proiectelorManagementul proiectelor

Procese de dezvoltare

Curs, anul II Calculatoare

Procese de dezvoltare software (1)

SumarDefiniţii, clasificări, perspectiveProcese de dezvoltare genericen Modelul in cascada / Proiectarea formalăn Integrarea componentelor reutilizabilen Dezvoltari evolutiven Dezvoltari iterative: wDezvoltarea incrementala / Dezvoltarea in spirala

Modele de SDP modernen Procesele Rationaln Metodologii agile si programare extreman Rolul cazurilor de utilizare si al instrumentelor CASE

Ce este un proces de dezvoltare software (SDP)?

Un set coerent si structurat de activităţi al căror scop este dezvoltarea si evoluţia software-uluiIdee : exista activităţi generice, asemănătoare, in toate procesele software:

Specificarea – ce trebuie sa facă sistemul si care n Specificarea – ce trebuie sa facă sistemul si care sunt constrângerile sale de dezvoltare

n Dezvoltarea – “producţia” sistemului softwaren Validarea – verificarea faptului ca software-ul

corespunde cu cerinţele clientuluin Evolutia – modificarea software-ului ca raspuns la

schimbarea cerintelor

Perspectiva tehnică(Producţia software)

Companiile de software au 2 obiective principale:n dezvoltarea, furnizarea şi întreţinerea programelorn satisfactia userilor prin prisma îndeplinirii cerinţelor lor

curente (precizate) cât şi viitoare (potenţiale)Procesul de producţie (proces de dezvoltare soft.)Procesul de producţie (proces de dezvoltare soft.)trebuie să permită: n transformarea cerinţelor utilizator în sistem softwaren evoluţia acestui sistem

Un SDP tb să fie si riguros, repetabil şi controlabilAdoptarea şi particularizarea proceselor software în cadrul companiilor impune structurarea dar şicoerenţa activităţilor de dezvoltare sau menţinere

Coerenta si structurarea activităţilor intr-un SDP enecesara dezvoltării sau evoluţiei unui softwaren SDP permite transformarea cerinţelor utilizatorilor intr-

un sistem software

Necesitatea existentei SDP

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 conduce la lipsa de predictibilitate si erori (repetate)!

(SDP)(SDP)Cerinţe Cerinţe utilizatorutilizator

Sistem Sistem SoftwareSoftware

Perspectiva metodologicăIn esenţă, un SDP este o metodologie de dezvoltareAdoptarea unei astfel de metodologii e un pas important în procesul de maturizare al unui producător software Avantaje ale folosirii unei metodologii (SDP) într-o firmă: n toată lumea va lucra la fel, practic se foloseşte o „reţetă”

comună în abordarea proiectuluicomună în abordarea proiectuluin se cristalizează mult mai repede o terminologie comună n se stabileşte tipul de formulare care se utilizează, când şi cine le

completează/ le aprobă, ce măsuri se întreprind şi în ce situaţii → Altfel spus, se va genera un sistem de lucru uniform,

consistent şi consolidat, ce va permite: n planificarea şi urmărirea proiectelor în mod unificatn completitudinea şi corectitudinea raportărilor (implicit evitarea

conflictelor de raportare)n luarea deciziilor în timp real n creşterea eficienţei şi productivităţii programatorilor

Perspective procesualeFolosirea unei metodologii de proiect este departede a garanta succesul său (exista mulţi alţi factori care pot interveni în proiect)Inexistenţa ei garantează cel mai adesea eşecul Perspectiva procesuala (model de proces) este o Perspectiva procesuala (model de proces) este o reprezentare abstractă, simplificată a unui procesreal, prezentat prin fluxuri şi relaţii specificeTipuri de perspective procesuale:n “Workflow” – secvenţe de activităţi

n “Dataflow” – flux de informaţii

n “Roluri/actiuni” – ori “who does what? in a wedding J”

Perspectiva “workflow”Scop: Sa administreze fluxurile de lucru astfel ca oriceactivitate sa fie efectuata la timp de catre aceapersoana desemnata pentru efectuarea eiSisteme workflow (WFMS):Sisteme workflow (WFMS):Pachete software ce ajuta la definirea, manage-mentul si executia proceselor de tip workflow processes.q Procesele de business sunt mai intai translatate

(reprezentate) in software, care permite apoiexecutia lor - cel putin pentru un set specificat

Perspectiva “dataflow”Scop: Sa ilustreze prin fluxuri de date intreentitati interactiunea proceselor realeEx.

Un SDP bine definit si urmărit face diferenţa intre succesul unui proiect si

eşecul lui

este simplu (orice lege e simpla),este simplu (orice lege e simpla),dar uneori greu de aplicat (respectarea

legii e dificila, pp. autodisciplina)

Tipuri majore de SDPqProcesele “plan-driven” se disting prin

Ø planificarea in avans a tuturor activitatilorØ masurarea sistematica a progresului in raport cu

aceasta planificare

qProcesele “agile” se caracterizeaza printr-o qProcesele “agile” se caracterizeaza printr-o planificare incrementalaq Este mai usor de schimbat procesul, pentru a reflecta

cerintele in schimbare ale clientului

qIn practica, cele mai multe procese includelemente ale ambelor tipologii

Modele de procese softwareNu putem limita numarul proceselor de dezvoltaresoftware, ele imbraca aspecte specifice pentru fiecareorganizatie si prezinta diferente mai mici sau mai mari

Putem insa sesiza asemanarile si construi categorii(generice)

Un model de proces software e reprezentarea simplificata a unui SDP, proiectata dintr-o perspectiva specifica

O companie care îşi organizează activitatea pe proiecte prin intermediul unei metodologii are două posibilităţi:n există metodologii comerciale pe care le poate

achiziţiona şi utiliza internn îşi poate crea propria metodologie pe baza unor

metodologii generice

Procese de dezvoltare genericeClasificarea are in vedere separaţia fazelor dezvoltării:n SDP in cascada (“waterfall”)n Transformări formale ale specificatiilor n Dezvoltare evolutiva (“evolutionary development”)n Integrare din componente (reutilizabile)n Dezvoltarea iterativa si incrementalan Dezvoltarea iterativa si incrementalaw rezolva unele constrângeri temporale w răspunde nevoilor de adaptare/schimbare in proiect

Alte modele de SDP orientate spre reducerea planificarii:n Metodologii uşoare (agile)n Programarea extrema (XP)w Dezvoltarea condusa de cazurile de utilizare (“use-case

driven”) asigura consistenţa cu cerinţele si rolurile utilizatorw Suportul instrumentelor CASE este important

Trăsături comuneLa nivel de rezultate:n Sisteme software construite din componente softwaren Componente interconectabile si reutilizabile (interfeţe

bine definite!)

La nivel de activităţi:La nivel de activităţi:n Indiferent de tip, un SDP conţine activităţi generice:

specificare, proiectare, implementare etc.n Modelele de proces generice descriu moduri de

organizare a proceselor softwaren Modelele de proces iterative descriu procesele software

ca cicluri de activităţi

I. Modelul in cascadă (WM)Primul SDP in cadrul ingineriei soft. “tradiţionale”Faze secvenţiale, distincten Specificarea si dezvoltarea sunt separaten Fazele sunt delimitate de activităţi de tip Test/ Verifyn Aprobate de către echipa de calitate (QA) si/sau client

Aplicarea WM este potrivită când complexitatea sistemului este mică iar cerinţele sunt staticeTeoria pe care se bazează WM este riguroasaPractica WM, sau “procesul convenţional” s-a dovedit mult mai puţin eficienta

Reprezentare

Ø Procesul „curge” de la etapă la etapă, ca apa într-o cascadă

Ø Varianta cu feedback a WM propune remedierea problemelor descoperite în pasul precedent

“Teoria” WM (Winston Royce, 1970)n Două etape esenţiale: analiza şi implementarean Suplimentate de alte activităţi:wDefinirea si analiza cerinţelorw Proiectarea softwarew Proiectarea softwarew Testarea, care poate fi:

n Pe module – in etapele timpurii ale implementăriin A întregului sistem software – in faza finala

w Utilizarea (operarea) softwarewMenţinerea

“Esenţializare” WM (software lifecycle)

Ø Analiza – se specifica exact care e problema si care sunt cerinţele unei soluţii acceptabile

Ø Proiectarea – se dezvolta o soluţie, pana la nivel de detaliu, a problemei

Ø Implementarea – soluţia se codifica intr-unprogram

Ø Testare/verificare – ne asiguram ca solutia implementata este consistenta & corecta

Ø Menţinerea – reparare/ extindere/ adaptare software

Tema: “Rafinare” WM

Evaluare Identificare Stabilirea proceselor

Identificaremodalitati

Stabilirea schemelor Identificare

Proces

Inseraţi sarcinile in cadrul fazelor de proces de mai jos:

Etapa de analiza Etapa de proiectare

Etapa de implementare Etapa de testare

Evaluare Identificare metrici proceselor

de reviziemodalitati(guidelines)

schemelor de raport

Identificareriscuri

Probleme ale WMPrincipalul neajuns al modelului de dezvoltare in cascada este dificultatea gestionarii schimbărilor după ce procesul a trecut de prima etapa:n Schimbările rezultate sunt prea distructiveSchimbările rezultate sunt prea distructiven Modificarea cerinţelor produce reluarea procesuluin Testarea are loc prea târziu in ciclul de dezvoltaren Modelul este adecvat doar când cerinţele sunt

foarte bine înţelese de la început

Alte dificultăţi in “practica” WMExtinderea integrării si nerespectarea ulterioara (târzie) a proiectăriiRezolvarea târzie a riscurilorDecompoziţia funcţionala condusa de cerinte Decompoziţia funcţionala condusa de cerinte (requirements-driven)Relaţii de adversitate beneficiar - producatorFocus pe documente si meeting-uri de review

Extinderea integrării si nerespectarea ulterioara (târzie) a proiectării

La început - succes prin proiectare riguroasa pe hârtie si întâlniri lungi, completeCodificarea începe târziu Integrarea produce coşmaruri (40% din cost)Integrarea produce coşmaruri (40% din cost)Presiuni puternice de buget si termenePuneri la punct non-optimale si târzii

⇒ software întârziat, fragil, greu de menţinut

Rezolvarea târzie a riscurilor

Cerinţele: riscuri mari si instabileProiectare-codificare: risc stabil dar mareIntegrare: risc redus (rezolvări focalizate)Testare: risc redus (controlat, administrat)Testare: risc redus (controlat, administrat)

Rezolvarea riscului se face cu preţul reducerii calităţii produselor software.

Decompoziţia funcţionala condusa de cerinţe

Sunt necesare cerinţe precise devreme in proces (de la început)Implicit toate cerinţele sunt presupuse la fel de importanteimportanteDependenta de cerinţe rămâne constanta pe parcursul vieţii produsuluiCerinţele sunt specificate funcţionalDecompoziţia funcţionala se transmite software-ului produs

Relaţii de adversitate intre “stakeholders”

Cauza: dificultatea specificarii cerintelorStakeholders: clienţi, utilizatori, analişti, proiectanţi, programatoriIn general se produc si circula artefacte In general se produc si circula artefacte pe hârtie, notaţii neriguroaseRezultat: sensibilitate, lipsa de încredere

Concentrare pe documente si meetinguriProgresul - documentat prin artefacte (pe hârtie)Insuficienta concentrare pe progresul incremental al produsuluiNivel de înţelegere inegal intre participanţiNivel de înţelegere inegal intre participanţiMeeting-uri lungi si neproductiveSe “produc” multe documente, dar cu puţine elemente esenţiale in rezolvarea cerinţelorNeajunsurile de proiectare sunt expuse târziu

Probleme practice (Boehm)1. Găsirea de bug-uri si remedierea unui produs

software după livrare costa de 100 ori mai mult decât devreme, in faza de proiectare

2. Planificările iniţiale pot fi comprimate cu max. 2. Planificările iniţiale pot fi comprimate cu max. 25% din valorile nominale

3. Pentru fiecare $1 cheltuit cu dezvoltarea, $2 se cheltuie cu mentenanţa

4. Dezvoltarea/menţinerea sunt funcţie de nr. de linii de cod sursa (absenţa reutilizării)

II. Proiectarea formalăSe bazează pe transformările unor specificaţii matematice, trecând prin diferite reprezentări, spre un program executabil Transformările păstrează corectitudinea (sunt Transformările păstrează corectitudinea (sunt însoţite de verificări)

⇒programul este conform cu specificaţia sa

Requirementsdefinition

Formalspecification

Formaltransformation

Integration andsystem testing

Cicluri transformare-verificare

R2Formal R3 Executable

T1 T2 T3 T4Formal transformations

R1 R2Formalspecification R3 Executable

program

P2 P3 P4

Proofs of transformation correctness

R1

P1

Avantaje ale proiectării formaleFormalismul şi rigoarea matematică asigură corectitudineaSpecificaţia iniţială exprimată în limbaj matematic e “transformată” în program, de matematic e “transformată” în program, de obicei printr-un proces incremental Oferă posibilitatea generării automate de codVerificarea consistenţei şi testarea prin metode similare demonstrării automate de teoreme

Probleme ale proiectării formaleNevoia însuşirii unor tehnici specializateTraining-ul este scump si îndelungatDificultatea specificării formale a unor aspecte sau componente ale sistemului (de ex. GUIs –sau componente ale sistemului (de ex. GUIs –interfeţele utilizator)

⇒Aplicabilitatea acestor dezvoltări este limitata la sistemele “critice” - cazurile de siguranţa si securitate trebuie demonstrate înainte ca sistemul sa fie operaţional sau chiar in teste

III. Integrarea componentelor reutilizabile

O componenta software e o implementareindependent livrabila a unei functionalitati, ce poate fi reutilizata in diverse aplicatiin Ceea ce ea asigura si necesita trebuie precizatn Ceea ce ea asigura si necesita trebuie precizat

clar astfel incat sa fie utilizata fara ambiguitati

“Component-Based Software Engineering”proces de dezvoltare bazat pe asamblareade componente software reutilizabile in (sub)sisteme software complexe

Etape de lucru

Analiza componentelor existente dar si a cerinţelor iniţialeModificarea (alterarea) cerinţelor iniţialeProiectarea sistemului cu reutilizareProiectarea sistemului cu reutilizareImplementarea componentelor adiţionale si integrareaRequirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

Procesul de integrare

Domain Engineering

Domain Analysis

Reusable Component

Development

Software Architecture Development

Domain Model

Structural Model

Repository Reusable Artifacts/

Components

Component-Based Development

Testing

Component Engineering

Architectural Design

Analysis

Component Qualification

Component Adaptation

Component Composition

Component Update

Application Software

IV. Dezvoltari evolutiveCaracteristica: specificarea si dezvoltarea sunt întrepătrunseDoua variante de baza:n Dezvoltare exploratoriew Obiectiv: lucrul strâns cu clienţii, in scopul evoluării unui w Obiectiv: lucrul strâns cu clienţii, in scopul evoluării unui

sistem software de la stadiul iniţial de specificaţie generalaw Trebuie sa înceapă prin înţelegerea foarte buna a cerinţelor

n Dezvoltare cu disponibilizarea prototipuluiw Obiectiv: înţelegerea cerinţelor sistemw Poate începe cu specificaţii mai puţin clare, de la care se

dezvolta diferite prototipuri, a căror demonstrare lămureşte specificaţiile

Activităţi în dezvoltarea evolutivă

Specification Initialversion

Concurrentactivities

Validation Finalversion

Development Intermediateversions

Outlinedescription

Avantaje ale dezvoltării evolutive

Utilizatorii pot schimba specificaţiile fără a fi afectată decisiv durata de dezvoltareÎntreţinerea este redusă, deoarece validarea se face pe parcursul dezvoltăriiEste facilitată instruirea utilizatorilor finali chiar înainte de terminarea produsuluiPot fi folosite două feluri de prototipuri:n Disposable (“throw-away”) – folosit doar la obţinerea

unei specificaţiin Evolutionary – serveşte la crearea unui schelet al

aplicaţiei

Probleme ale dezvoltării evolutiveLipsa de vizibilitate a procesuluiSistemele rezultate sunt deseori slab structurateSunt necesare abilitaţi speciale (de ex. de lucru in limbaje pentru prototipizare rapida)in limbaje pentru prototipizare rapida)

⇒ Aplicabilitatea este limitata:n Pentru sisteme software interactive mici si mediin Pentru parţi ale unor sisteme mari (e.g. GUIs)n Pentru sisteme cu durata scurta de viata

PrototipizareaPrototipul ajută clientul în a-şi defini mai bine cerinţele şi priorităţilePermite totodată dezvoltatorilor să elimine lipsa de claritate a specificaţiilor

Dar: Dar: Prototipul rulează într-un mediu artificial si poate ascunde erori ale produsului finalFiind produs mai repede, programarea sa poate fi neglijentă si ca stilClientul poate schimba prea des specificaţiile, Programatorul poate fi nemulţumit de renunţarea la o parte din munca depusa