Managementul proiectelorManagementul proiectelor

Definirea unui proces de dezvoltare

Curs, anul II Calculatoare

Definirea unui proces de dezvoltare software in cadrul unei organizaţii

SumarMetodologii generice si procese propriiMetodologia HEI RUPn Iniţiere n Elaborare n Elaborare n Construcţien TranziţieEvoluţia proceselor software Ghid simplificat de rafinare a unui proces software

Modele de procese genericeSDP în cascada (“waterfall”)Transformări formale ale specificaţiilor Dezvoltare evolutiva (“evolutionary developm.”)Integrare din componente (reutilizabile)Dezvoltarea iterativa şi incrementalaDezvoltarea iterativa şi incrementalan rezolva unele constrângeri temporale n răspunde nevoilor de adaptare/schimbare în

proiectDezvoltarea condusa de cazurile de utilizare(“use-case driven development”) n asigura consistenta cu cerinţele şi rolurile

utilizator

O companie ce îşi organizează activitatea pe proiecte după o metodologie are 2 posibilităţi: n există metodologii comerciale pe care le poate

achiziţiona şi utiliza intern

Metodologii (procese) proprii

n îşi poate crea propria metodologie, prin adaptareaunuia dintre modelele de SDP generice

Există o bază generală pentru crearea uneimetodologii? DA, nu doar una ci mai multe!n Project Management Body of Knowledge

n Specifică (Rational Unified Processes)

Practic, singurul standard ANSI pentru managementul de proiect (IEEE Std 1490™-2003) care identifică şi descrie cunoştinţele general acceptate, ce servesc ca bază de lucru pentru managerii de proiecte General acceptate înseamnă aici că:

Standardul PMBoK (3rd ed., 2004)

General acceptate înseamnă aici că:n aceste cunoştinţe/ practici de lucru descrise se aplică

majorităţii proiectelor pe tot ciclul lor de viaţă n există un consens larg asupra valorii şi utilităţii lor

Nu înseamnă însă că aceste cunoştinţe şi practici de lucru trebuie aplicate uniform tuturor proiectelor, fără o considerare atentă a cazurilor în care ele sunt adecvate!

Pornind de la standarde, firme ca IBM, Microsoft, SAP, Oracle etc. au creat metodologii comerciale ce aduc:n procese bine definite pentru fiecare fază a unui proiect

şi pentru fiecare zonă de cunoştinţe din PMBoKn alte facilităţi, de exemplu formulare gata concepute şi

care trebuie doar completate în proiecte

Metodologii comerciale

care trebuie doar completate în proiecteInstrumentele software pentru management : n respectă anumite standarde comunen urmăresc tendinţele pieţei

Principalii furnizori de software includ în platformele specifice şi module dedicate urmăririi proiectelor pe baza metodologiilor propriiDeşi specifice firmelor care le-au creat, aceste procese şi metodologii nu rămân închise, ci sunt publicate şi pot fi achiziţionate de alte firme

Metodologiile standard permit puţine abateri de la reguli: astfel se evită o serie de conflicte specifice Arată cum trebuie făcut pornind de la cele mai bune practici în domeniu, însă se şi adaptează la nivelul de complexitate al proiectelor din firmăInclud experienţa altor firme specializate în

Avantaje

Includ experienţa altor firme specializate în metodologii de proiect, ce au contact în viaţa reală cu diverşi clienţi, diverse situaţii în proiecte, diverse moduri de lucru: n beneficiarul are la dispoziţie numeroase exemple

complexe pentru a învăţa din experienţa altoraCrearea unei pieţe paralele a metodologiilor de realizare a produselor, pe lângă cea propriu-zisă a produselor software, face ca aceste metodologii să concureze şi să evolueze - maturizându-se !

Cele legate de preţ – ridicat!Familiarizarea mai lentă cu instrumentele folositen mai ales când acestea sunt relativ complexen în special în cazul unui training sumar

Felul în care se adaptează la procesele deja stabilite

Dezavantaje

Felul în care se adaptează la procesele deja stabilite în cadrul companiei beneficiareDiferenţele între metodologii ţin nu doar de preţul lor, ci şi de multe alte aspecte, ca:n instrumentele software care pot fi utilizate în funcţie

de parteneri n necesităţile pe care le presupune raportarea şi accesul

la training

Simplificând puţin, formularea se face astfel:Toţi cei implicaţi în proiecte se adună şi stabilesc o serie de aspecte esenţiale ce ţin de modul de lucru în proiecte prezente sau viitoare n un flux de documente, formularele respective

proceduri de rezolvare în caz de conflicte

Metodologii formulate intern

n proceduri de rezolvare în caz de conflicte n cine aprobă proiecte noin cine aprobă fiecare tip de acţiune etc.

Acest mod de lucru este apoi documentat temeinic şi cu proceduri certificate (eventual ISO) De la o anumită dată înainte toţi directorii, managerii de proiect, personalul tehnic etc. vor lucra numai după procedurile documentate intern

Costul redus Procedurile rezultate se pot mula perfect pe procesele existente în firma respectivă În general, se alege această cale dacă o firmă:

are experienţă în lucrul pe proiecte

Avantaje

n are experienţă în lucrul pe proiecte n a gestionat anterior cu succes multe situaţii,

unele neprevăzute n are o vedere de ansamblu care să-i permită

să documenteze proceduri de lucru pentru fiecare situaţie care poate apărea

În cazul unei experienţe insuficiente de lucru, abordarea nu este viabilă n Din nimic nu se poate inventa un mod de lucru

adecvatn Daca se adopta, acesta nu se va regăsi în realitatea

Dezavantaje

n Daca se adopta, acesta nu se va regăsi în realitatea proiectelor din companie!

Este necesar timp şi implicarea tuturor celor care vor lucra pe aceste proceduri Fiecare poate aduce un punct de vedere şi o experienţă individuală diferită, dar utilă

Vom încerca sa definim un SDP propriu!Metodologia HEI RUPMetodologia HEI RUP(Higher Efficiency Integrated Rational Unified Processes)

Punct de pornire 1: cadrulprocesual RUP

Rational Unified Process

specializare

Proces de dezvoltare propriu

Proiectul meu

punere in actiune

Punct de pornire 2: Caracteristici ale procesului intern

Munca în echipă, ce se concretizează in:n Participare la proiectarea colaborativăn Asumarea diferitelor roluri în echipa unui proiectn Crearea si urmărirea unui plan de proiectare si testare

Crearea documentelor asociate cu un produs softwaren Crearea documentelor asociate cu un produs software

Posibilitatea de a avea intr-un semestru 2 iteratiiper proiect, fiecare de ~ 6 saptamani (midterm):n 1 sapt. planificare, analiza & designn 3-4 sapt. proiectare de detaliu si implementaren 1-2 sapt. testare/ finalizare (midterm/ final presentation)

Etc.

Rational Unified ProcessesCei 3 “amigos” (Booch, Rumbaugh si Jacobson), având fiecare deja definit propriul proces, au creat RUP ca un proces generic/ cadru procesual (framework)n Ce permite dezvoltarea software OOn Independent de UML, deşi cele 2 sunt considerate n Independent de UML, deşi cele 2 sunt considerate

uneori împreunaMetodologia RUP este in mod esenţial un proces genericiterativ, incrementalProiectele RUP parcurg următoarele 4 faze:

1. iniţiere 3. construcţie2. elaborare 4. tranziţie

O privire mai atentă asupra RUPO metoda de mngm a dezvoltarii software OOUn cadru procesual de dezvoltare extensibilInformatia de proces este in acces online (in Repository) si descrisa in format HTMLRepository) si descrisa in format HTMLExista sabloane pentru toate livrabilele majore:n Sabloane RequisitePro pentru urmarirea cerintelorn Sabloane Word pentru cazurile de utilizaren Sabloane de proiect pentru mngm de proiect

Exista manuale de proces ce descriu proceselecheie

Arhitectura RUPTimp si faze din ciclul de

viaţăDiscipline de proces saufluxuri de lucru

Cele 3+1 cuvinte cheie

Centrat pe arhitectura

Condus de cazuri de utilizare Provindin USDP

Provindin USDP

Iterativ si incremental

Confruntandu-se cu risculUSDP (Unified Software Development Process) este

framework –ul de SDP din care provine RUP, ca siOpenUP

Iniţiere: Analiza cerinţelor/ specificaţiilor

Concept cheie: separarea cerinţelor aplicaţiei de cerinţele procesuluiSe tine cont, pe langa cerinţele funcţionale, de:n Aspectele non-funcţionale ale sistemului software:

timpul de execuţie pe un anumit procesor, timpii de timpul de execuţie pe un anumit procesor, timpii de regăsire si salvare ai fişierelor, vitezele de actualizare ale frame-urilor etc.

n Aspecte ale procesului software: cerinţele de date ale procesului – ce impun determinarea fişierelor sau bazelor de date necesare, a mărimii lor estimative si a modului cum sunt utilizate

Paşi in analiza cerinţelor

Metodologia de analiza a cerinţelor acoperă un ciclu mai lung

Fazele extreme sunt: n colectarea cerinţelor iniţiale colectarea cerinţelor iniţiale n separarea cerinţelor

Paşi:n Colectarea cerinţelor bruten Rafinarea cerinţelorn Documentarea cerinţelor

Colectarea cerinţelor “brute”

Începe prin dialog cu experţii in domeniul sistem sau aplicaţie Un model minimal (prototip) poate furniza un context util acestui dialogcontext util acestui dialogInstrumente software specializate, precum EasyRM Requirement Management Suite ori AnalystPro, pot fi utilizate inca din aceasta faza, mai ales pentru documentare

Rafinarea cerinţelor

La finele pasului 1, este probabil ca echipa de dezvoltare sa se confrunte cu prea multe cerinţe, nu la fel de prioritareObiectivul acestui pas este de a procesa mai departe cerinţele; se obţine o lista prioritizată departe cerinţele; se obţine o lista prioritizată Se examinează pentru fiecare cerinţa in parte:

1. Incluziunea in domeniul (scopurile) proiectului. Cerinţele din afara vor fi eliminate

2. Redundanta fata de alte cerinţe. Redundantele trebuie rezolvate.

3. Prioritatea: pe termen scurt, mediu sau lung.

Documentarea cerinţelor

La acest pas, informaţiile colectate vor fi strânsein documentaţia cerinţelor

Aceasta reprezintă o documentaţie de referinţa,construita in maniera bottom-up, conţinând:

O descriere scurta (un overview al conţinutului altorn O descriere scurta (un overview al conţinutului altordocumente)

n Un pointer la documentul de lucru (ce poate fi o calein sistemul de fişiere, ori un URL), conţinând el însuşireferinţe spre alte documente

n Pe măsura ce numărul de documente creste, esteesenţiala clasificarea lor intr-o maniera ierarhica, deex. in foldere separate pentru arii tematice separate

Standard software (UML): “Use-Case Driven Development”

Colectarea, rafinarea si documentarea cerinţelor se pot face folosind cazuri de utilizareCazurile de utilizare specifica cerinţele sistemului si conduc procesele de:

proiectaren proiectaren implementare întreaga dezvoltare a sistemuluin testare

Cazurile de utilizare reprezintă sursa pentru construcţia cazurilor de testare

Cazurile de utilizare in analiza cerinţelor1. Cazurile de utilizare permit captura initiala si

descrierea/ analiza completa a cerinţelor

2. Cazurile de utilizare nu sunt selectate izolat

3. Cazurile de utilizare conduc dezvoltarile 3. Cazurile de utilizare conduc dezvoltarile arhitecturale/arhitecturile afecteaza selectia cazurilor de utilizare

Elaborare : Cazurile de utilizare inproiectarea arhitecturala1. Cazurile de utilizare conduc dezvoltarile

arhitecturale/arhitecturile afecteaza selectia cazurilor de utilizare

2. Cazurile de utilizare asigura informatii de intrare 2. Cazurile de utilizare asigura informatii de intrare semnificative pentru: n specificarea subsistemelor, claselor si interfetelorn specificarea cazurilor de testaren planificarea iteratiilor de dezvoltare

ð Use case-urile si arhitecturile sunt dezvoltate impreuna in timpul dezvoltarii sistemului

Standard software: Dezvoltarea iterativa/ incrementalaMotivatii:n Cerintele nu pot fi complet cunoscute inainten Iteratii succesive expliciteaza si detaliaza ceea ce

necesita si vor utilizatoriiSchimbarea inevitabila a cerintelor necesita oricum n Schimbarea inevitabila a cerintelor necesita oricum adaptare

Beneficii:n Creste ritmul (tempo-ul) dezvoltarii n Creste eficienta muncii de dezvoltaren Tinte restranse, focalizate intr-o planificare mai scurtan Validare timpurie pe modele de implementare minimale

Modelul de proiectareDescrie structura statica a sistemului prin subsisteme, clase, interfeteEvidentiaza colaborarea intre obiectele definite in structura statica, ce modeleaza cazurile de utilizareEste ierarhic dar poate contine si relatii non-ierarhice (asociatii, dependente etc.)(asociatii, dependente etc.)Un model de implementare minimal poate fi asigurat inca din aceasta faza, cu componente care sa demonstreze ca arhitectura descrisa este executabilan Daca design-ul este asemanator cu “scheletul” (fara

“muschi” sau “piele” - adaugate in faza urmatoare) n Se pot adauga totusi cativa “muschi” care sa

demonstreze miscarile de baza

InfluenteArhitectura pe care se va implementa sistemulSistemul de operare Sistemul de gestiune a bazelor de date ale proiectului, protocoalele de reteaCadre, componente si consideratii de dezvoltareCadre, componente si consideratii de dezvoltareInteractiunea cu sistemele legale, standarde, politiciCerinte nonfunctionale (performante, robustete) Necesitati de distribuire (client/server, web-based etc)

Proiectarea top-down(in cadrul abordarilor structurate pana la cele OO)

Subliniaza concentrarea asupra proiectarii de nivel inalt (overall design), ignorand in prima parte detaliile

Focalizarea are loc asupra scopurilor importante:Focalizarea are loc asupra scopurilor importante:w Explicitare (cineva trebuie sa faca implementarea!)

w Robustete la viitoarele schimbari

w Reutilizare (o parte din componentele proiectului pot fi adaptate si pentru alte proiecte)

Proiectarea orientata pe obiecte: Problema calităţiiTehnica dezvoltarii orientate pe obiecte cere:

Definirea obiectelor specifice:n Componente cheie ale sistemuluin Responsabilitati ale fiecareia

Interactiuni (cai de comunicare cheie intre n Interactiuni (cai de comunicare cheie intre componente)

n O lista a serviciilor asigurateRafinarea cerinţelor si definitiilor

→Calitatea unui proiect OO se reflecta in proiectele viitoare pe care le suporta in mod natural!

“Repositories”Un ‘repository’ este o locatie (sau set de locatii) unde analistii/ proiectantii/ testerii tin documentatia sau codul asociat cu unul sau mai multe sisteme sau proiecteRepository-uri tipice:n Un director de retea continand corespondenta unui proiect, n Un director de retea continand corespondenta unui proiect,

rapoarte, date (artifacte ale dezvoltarii)n Un dictionar de instrumente CASEn Manuale/ help-uri sistem n Documentatie tiparita (dosare si biblioteci ce descriu un

sistem)n O interfata web (un intranet ) la componentele de mai susn Cod sursa cu componente ce pot fi compilate si executate

Modele si documenteSa cream documente doar cand sunt necesare?Sa actualizam documentele doar in situatii de criza?

actualizareactualizare actualizareactualizare

IdeeIdee ModelModeltemporartemporar

ModelModelpermanentpermanent

pastrarepastraremodelmodel

versiuneversiune

RenuntareRenuntare

Documentatia tehnica de proiectare

Difera de documentatia pentru end-userInclude:n Comentarii asupra coduluin Comentarii asupra claselor (structurilor de

date si cod)date si cod)nDefinirea algoritmilornDefinirea structurii proiectului (prin diagrame)n Comentarii la modelele obiectual, functional si

dinamic n Posibil, o harta si instrumente de navigare in

structura proiectului

Constructie : Modelul de implementareStabileste:

Cum sunt elementele din modelul de proiectare (clase) implementate pe componente (de ex. fisiere sursa)Cum sunt componentele organizate in Cum sunt componentele organizate in concordanta cu mecanismele de structurare/ modularizare disponibile in mediul de implementare si limbajele de programareScopul este obtinerea unui sistem functional in raport cu componentele: cod sursa, scripturi, binare, executabile, impreuna cu documentatia

Componente de implementareO componenta este parte a unui subsistem (ce include si componentele de interfata):n reprezintă biunivoc un element din proiect (clasa de

proiectare)dar poate implementa si mai multe clase de proiectaren dar poate implementa si mai multe clase de proiectare

n sau reprezintă operatii definite de interfatan dependentele de compilare sunt posibile

Subsistemelen sunt definite ca ierarhii de componente n pot fi recursive (imbricate)

PrototipizareaUn proces iterativ care necesita si incurajeaza:n Relatii stranse intre proiectant si utilizatorin Participarea activa a utilizatorilor finaliw (“end-users know what they want when they see it!”)

Este astfel un model si un proces activ de Este astfel un model si un proces activ de dezvoltare care ofera utilizatorilor finali o experienta preliminara cu sistemul viitor (“ a sort of touch-and-feel experience”)Si creativitatea este incurajata – prin feedback rapid din partea utilizatorului se ajunge la solutii mai buneErorile pot fi detectate mai devreme!

“Repositories” de cod sursa/ Controlul versiunilor

Coordonarea unei echipe necesita, pentru fisiere partajate, asigurarea ca, la un moment dat, doar un membru poate modifica un fisierDezvoltarea “cross-platform” necesita urmarirea problemelor de portabilitate la mentinerea unui cod unic pe toate platformelepe toate platformeleReutilizabilitatea/ orientarea pe obiecte a codului sursa necesita urmarirea modulelor utilizate de programe Versiuni vechi ale codului sursa si alte fisiere, pot fi necesare si trebuie regasite pentru urmarirea defectelor, deci trebuie control

Ä Un proiect (partajat) trebuie sa ofere suport pentru combinarea fisierelor, istoric, si control al versiunilor

Ä Impartirea proiectelor mari in subproiecte poate usura managementul proiectului!

CASE Tool: Visual SourceSafeBaza de date VSS -> asigura copii “master” pentru fisierele unui proiectFiecare user <- poate detine “copii de lucru” din baza VSSUn protocol simplu de check-out previne conflictele intre utilizatori multipli ce lucreaza pe aceleasi fisiereutilizatori multipli ce lucreaza pe aceleasi fisiereTehnologia VSS “reverse delta” asigura:n Disponibilitatea tuturor versionilorn Utilizarea eficienta (minimala) a spatiului pe disc –

datorita pastrarii incrementale a modificarilorn Cei mai buni timpi de acces – de baza este versiunea

curenta

Standarde de codificareSunt seturi de reguli ce descriu:n Cum trebuie sa arate codul implementatn Ce caracteristici ale limbajului de programare trebuie

folositen Ce tools-uri trebuie folosite pentru codificare, si cumn Ce tools-uri trebuie folosite pentru codificare, si cum

Sunt utile in majoritatea proiectelor, o necesitate in unele tipuri de proiecte (ex. “open source”)Pot fi mai mult sau mai putin specifice, dar:n mai ales cand cei ce colaboreaza la un proiect sunt

numerosi, diferentele in stilul de codificare pot conduce la neintelegeri

Documentarea coduluiCream documentatie doar cand se cere?Actualizam documentatia doar cand apar probleme?Cata incredere putem avea in documentatie?Problema fundamentala este comunicatia, nu documentatia!documentatia!Documentatia trebuie sa fie atat cat trebuie de buna (completa)Documentatia e parte a sistemului, ca si codul sursaScopul primar al unei echipe e dezvoltarea software, scopul secundar este facilitarea dezvoltarilor viitoareBeneficiul de a avea documentatia trebuie sa fie mai mare decat costul crearii si mentinerii ei

Sistemul de documentare DoxygenSe poate aplica fisierelor sursa C/C++, Java, IDL, documentate, fiind prin aceasta un instrument universal (comp. JavaDoc)Poate genera folosind comentarii de documentare:

Un browser de documentare HTML on-line, iesire HTML n Un browser de documentare HTML on-line, iesire HTML comprimata

n Un manual de referinta off-line (in LaTeX)n Iesire in RTF, PostScript, hyperlinked PDF, pagini de

manual Unix

Poate extrage structura codului din surse nedocumentate

Facilitati Doxygen

Blocuri speciale de documentare Permite descrieri sumare si de detaliu in codPermite plasarea documentatiei nu in headere ci in fisierele sursa (aceasta tine headerele in fisierele sursa (aceasta tine headerele compacte si permite accesul direct)Tine documentatia consistenta cu codul sursa Relatiile intre elemente pot fi vizualizate prin grafuri de dependenta, diagrame de colaborare, mostenire etc.

Utilizarea DoxygenPasul 1: Documentarea surselor, folosind:

Blocuri speciale de documentare (Qt/C/C++ style)/*! ... text ... */ //! ... one line of text ...

O descriere sumara si una detaliata, inaintea unei declaratii sau O descriere sumara si una detaliata, inaintea unei declaratii sau definitiiComenzi structurale – ceea ce permite plasarea blocurilor de documentare oriundeDocumentarea membrilor compusi (file, struct, union, class, ori enum) poate fi facuta atat in afara cat si inauntrul structurii

Utilizarea Doxygen (cont.)

Pasul 2: Crearea unui fisier de configurare:Doxywizard – este un “GUI front-end” pentru crearea, citirea si scrierea fisierelor de configurare, si pentru setarea optiunilor de configurareDoxygen poate crea un fisier de configurare template pentru Doxygen poate crea un fisier de configurare template pentru proiect

Pasul 3: Lansarea Doxygen:Optiunile configurate, precum EXTRACT_ALL, controleaza“cata” documentatie sa fie extrasa din fisierele sursa

Doxywizard

TestareaTestele trebuie planificate ca:n Teste de integrare – necesare pentru fiecare

constructie in cadrul unei iteratiin Teste sistem – necesare doar la sfarsitul unei iteratii

Testarea completa a fiecarei constructii a codului Testarea completa a fiecarei constructii a codului verifica implementareaExecutia testelor trebuie facuta impreuna cu inregistrarea sistematica a rezultatelor testelor

Proiectarea si implementarea testelor

Se face prin crearea:n cazurilor de testare ce specifica ce se testeaza, cu ce

intrari, si sub ce conditiin procedurilor de testare ce specifica cum se executa

testeletestelen componentelor de testare executabile, pentru

automatizarea testelorDefectele sunt simptome ale erorilor software sau ale unor probleme de proiectare descoperite in urma revizuirilor Ele trebuie inregistrate si urmarite astfel incat sa fie rezolvate

Cazurile de testarePot sa difere doar prin 1! valoare de intrare/ rezultatSunt specificate intr-o matrice de testaren Fiecare caz de test este un rand n Fiecare domeniu de intrari/ rezultate este o coloana

O matrice de test asigura o buna examinare a n O matrice de test asigura o buna examinare a cazurilor de testare similare si pentru crearea ulterioara a procedurilor si componentelor de testare

O procedura de testare poate fi reutilizata pentru cazuri de testare multiple, si invers, un caz de testare poate fi subiect al unor proceduri de test multiple

Modelul de testareEste o colectie de cazuri, proceduri si componente de testn Cazurile de test deriva din cazuri de utilizaren In general testele pot fi refolositen In general testele pot fi refolositen Un model de testare prea extins poate fi

descompus in “pachete” Trebuie mentinut pe întreaga durata a ciclului de viata software

Dinamica modelului de testareModelul de testare evolueaza in timpul ciclului de viata al software-ului, prin:

n Indepartarea cazurilor de testare ce nu mai sunt actuale (si a procedurilor/ componentelor de testare asociate) de testare asociate)

n Crearea de noi cazuri de testare pentru fiecare constructie

n Rafinarea cazurilor de testare in teste de regresie

“Debug Testing”Este testarea in timpul fazelor de tranzitie ale constructiei

softwareTipuri de testare:n Progresiva (implica fie teste de integrare fie teste

sistem globale)Regresiva (in cazul unei noi versiuni, se reiau teste n Regresiva (in cazul unei noi versiuni, se reiau teste anterioare)

Folosita atat in timpul proiectarii cat si implementariin In proiectare: linia de baza arhitecturala este testata

folosind un model de implementare minimaln In implementare: fiecare constructie a codului (rezultat

al implementarii) trece prin teste de integrare si fiecare iteratie trece prin testare de sistem

Specificul testarii constructiveDezvoltarea iterativa transforma cazurile de test

in teste regresive pentru constructiile ulterioare ale codului

Numarul cazurilor de testare creste cu fiecare iteratie: iteratiile finale au un numar mare de teste iteratie: iteratiile finale au un numar mare de teste regresive

Focus: Testare regresiva + Repararea defectelor aparute initial

“Release Testing”Are loc in faza finala (fiind de aceea si o testare de

ansamblu – “overall testing”). Consta in:Teste de instalare:n Poate fi sistemul instalat pe platformele tinta? n Se comporta el corect dupa instalare?

Teste de configurare:n Lucreaza sistemul corect in diferite configuratii (de

ex., de retea)? n Anumite cerinte suplimentare in configuratii diferite

pot esua

“Release Testing” (cont.)Teste negative (“cazuri de abuz" )n Incercari de a face sistemul sa esueze pentru a

evidentia slabiciunile sale n Identificarea cazurilor de testare pe care sistemul nu

a fost proiectat sa le suportea fost proiectat sa le suportew Configuratii de retea incorectew Incarcari “imposibile"

Teste de stressn Identificarea problemelor cand sistemul sufera

datorita resurselor insuficiente

Tranziţie : mentenanţă+evoluţieTransition completes product release...Este faza in care software-ul atinge complet capabilitatile operationale initiale (nu perfect, dar poate opera in mediul utilizator)Include:Include:n Livrarea software-ului (deployment)n Crearea si executia testelor de integraren Urmarirea (indeplinirii) cerinţelorn Mentenanţa programului (produsului)n Evoluţie a produsului si procesului

Activitati de menţinere

Mentinerea software-ului:Procesul de modificare a unui software operational,

existent, pastrand insa functiunile primare intacte

Tipuri de mentenanţă:Tipuri de mentenanţă:1. Corectiva (“repair/debug”, cca. 20% ca pondere)2. Adaptiva (adaptarea la mediu, adaugarea de noi

cerinte)3. Perfectiva (imbunatatirea performantei, ex.

optimizarea timpului de executie)4. Preventiva (schimbari ce faciliteaza mentenanta

viitoare)

Evoluţia software-uluiProblemele raportate de testeri externi sunt corectate Orice noi facilitati pot fi adaugate daca schimbarile sunt atat de mici incat nu au impact asupra planului proiectuluiimpact asupra planului proiectuluin Ideal, acestea sunt adaugate acum doar la o

lista de noi facilitati (functii) n Implementarea lor are loc doar in urmatorul

ciclu de dezvoltare (cu urmatoarea versiune)

Evoluţia proceselor software

Principii:

1. Dezvoltarea unui proces software trebuie inteleasa ca un proces evolutiv.

2. Un proces software trebuie inteles inainte de a 2. Un proces software trebuie inteles inainte de a fi definit.

3. Dezvoltarea proceselor software, ca proces in sine, trebuie nu doar definita, ci si masurata si gestionata corespunzator.

Imbunatatirea proceselorPentru a evolua si imbunatati un proces:n Acesta trebuie definitn Trebuie sa reprezinte o aproximatie rezonabila a ceea

ce se face efectiv in cadrul organizatiei

Motivul principal pentru care procesele software Motivul principal pentru care procesele software sunt deficitare este acela ca nu se face ceea ce se stie ca trebuie facutSimpla definire a unui proces face greselile si omisiunile mai evidente si contribuie astfel la imbunatatirea proceselor efective

Ghid simplificat de rafinare a unui proces software

Se porneste de la o definitie de proces generic, identificata ca fiind apropiata de cel real Se include o faza de planificarePe baza inregistrarilor din organizatie, se estimeaza timpul de dezvoltare pentru fiecare estimeaza timpul de dezvoltare pentru fiecare faza majora si categorie de produs softwareSe definesc metrici (de ex. de productivitate)Se mentine o evidenta a fiecarei dezvoltari de procesSe produc raportari pentru fiecare dezvoltare de proces