Managementul proiectelor - ace.catalinamancas.roace.catalinamancas.ro/ACE/SDP1.pdfCurs, anul II...
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