CURS 2 Managementul proiectului coninut de cunotere Institutul de management de proiect (PMI) a ncercat s determine care sunt cunotinele minime

e de care are nevoie managerul de proiect pentru a fi eficient. PMI a identificat 9 arii de cunoatere care sunt : - Managementul integrrii proiectului, - Managementul scopului, - Managementul timpului, - Managementul costului, - Managementul calitii, - Managementul resurselor umane, - Managementul comunicaiilor, - Managementul riscului, - Managementul investiiilor (achiziiilor). 1. Managementul integrrii proiectului d asigurare c proiectul este corect planificat, executat i controlat. Aceasta include exercitarea controlului i asupra schimbrilor din proiectul formal. 2. Managementul scopului implic autorizarea jobului, dezvoltarea specificaiilor scopului care definesc limitele proiectului, mprirea muncii n componente monitorizabile i cu livrabile, verificarea c scopul planificat poate fi atins i implementarea procedurilor de control la schimbarea scopului. 3. Managementul timpului presupune dezvoltarea unei planificri care poate fi atins i controlul c munca se desfoar. 4. Managementul costului invoc estimarea costurilor resurselor incluznd oameni, echipamente, materiale, cheltuieli de deplasare sau orice ce alt suport. Dup ce acest lucru este fcut toate costurile trebuie bugetate i urmrite pentru a menine proiectul n interiorul bugetului aprobat. 5. Managementul calitii. S-a ntmplat nu o dat ca una dintre cauzele eecului unui proiect s fi fost sacrificarea calitii pentru a se putea respecta termenul de livrare. Managementul calitii include att asigurarea calitii (planificarea atingerii cerinelor de calitate) ct i controlul calitii (paii care trebuie urmai pentru a controla rezultatele i a vedea dac sunt n concordan cu cerinele). 6. Managementul resurselor umane nseamn identificarea nevoilor de personal pentru proiect, definirea rolurilor, responsabilitilor i a relaiilor dintre membrii echipei unui proiect, aducerea de noi membrii i conducerea tuturor ct timp se execut proiectul. 7. Managementul comunicaiilor care implic planificarea, execuia i controlul achiziiei i diseminrii tuturor informaiilor relevante ctre nevoile tuturor responsabililor din proiect. Informarea include stadiul proiectului, ndeplinirea lui i orice altceva ce afecteaz responsabilii.

8. Managementul riscului este procesul sistema- tic de identificare analizare i rspundere a riscului proiectului. nseamn maximizarea probabilitii i consecinelor evenimentelor pozitive pentru proiect i minimizarea probabilitilor evenimentelor i consecinelor negative. 9. Managementul investiiilor (achiziiilor) nseamn procurarea necesarului de materiale i servicii pentru proiect care reprezint aspectul logistic, dar pe lng aceasta implic: - deciziile care trebuie luate asupra a ce se procur, - licitaii, - cotaii, - furnizori, - administrarea contractelor i ncheierea lor la terminarea jobului. Managementul aplicaiilor software Nu putem vorbi de managementul unui proiect software fr s vorbim de ingineria software i de ciclul de via al unui produs software. Creterea n dimensiune i complexitate a aplicailor software a depit cu mult progresele fcute n domeniul tehnicilor de programare. De aceea, o paralel ntre ingineria software i ingineria construciilor ar fi atractiv. tim c inginerii constructori ntocmesc planuri, construiesc machete, studiaz proprietile materialelor folosite i fac rapoarte privind progresul operaiunilor. Construcii de o complexitate foarte mare au fost realizate n acest fel ntr-un mod raional i economic. Constructorii de aplicaii software trebuie s procedeze la fel pentru ca dezvoltarea programelor s nu mai fie un proces impredictibil. Ingineria software are ca scop obinerea de sisteme funcionale chiar i atunci cnd teoriile i instrumentele disponibile nu ofer rspuns la toate provocrile ce apar. Inginerii fac ca lucrurile s mearg, innd seama de restriciile organizaiei n care lucreaz i de constrngerile financiare. Problema fundamental a ingineriei software este satisfacerea cerinelor utilizatorului. Aceasta trebuie realizat nu punctual, nu imediat, ci ntr-un mod flexibil i pe termen lung. Ingineria software Dezvoltarea sistemelor informatice Ingineria software se ocup de toate etapele dezvoltrii programelor, de la achiziia cerinelor de la client pn la ntreinerea i retragerea din folosin a produsului livrat. Pe lng cerinele funcionale, clientul dorete (de obicei) ca produsul final s fie realizat cu costuri de producie ct mai mici. De asemenea, este de dorit ca aceasta s aib performane ct mai bune (uneori direct evaluabile), un cost de ntreinere ct mai mic, s fie livrat la timp, i s fie sigur. Rezumnd, atributele cheie ale unui produs software se refer la: - Mentenabilitate, posibilitatea de a putea fi ntreinut: un produs cu un ciclu de via lung este supus deseori modificrilor, de aceea el trebuie foarte bine documentat; - Fiabilitate: produsul trebuie s se comporte dup cerinele utilizatorului i s nu cad mai mult dect e prevzut n specificaiile sale; - Eficien: produsul nu trebuie s foloseasc n pierdere resursele sistemului ca memoria sau timpul de procesare; - Interf. potrivit pt utilizator: interf. tr. s in seama de capacitatea i cunotinele utilizatorului. Optimizarea tuturor acestor atribute e dificil deoarece unele se exclud pe altele (de exemplu, o mai bun interfa pentru utilizator poate micora eficiena produsului). n cazurile n

care eficiena este critic, acest lucru trebuie specificat explicit nc din faza de preluare a cerinelor utilizatorului, precum i compromisurile pe care ea le implic privind ceilali factori. Trebuie spus c ingineria software nu rezolv toate problemele care apar atunci cnd se scriu programe dar, n momentul de fa, ea ne poate spune sigur ce s nu facem. Ciclu de via al produsului software. Ciclul de via al unui sistem informatic mparte dezvoltarea unui produs software n pai independeni, aflai ntr-o anumit succesiune. Paii succesivi sunt: - stabilirea cerinelor - specificarea - proiectarea - implementarea - testarea - operarea i ntreinerea Faza de analiz. Aceast faz definete cerinele sistemului, independent de modul n care acestea vor fi ndeplinite. Acum se definete problema pe care clientul dorete s o rezolve. Rezultatul acestei faze este documentul care conine specificarea cerinelor i care trebuie s precizeze clar ce trebuie construit. Documentul de specificare : Documentul ncearc s redea cerinele din perspectiva clientului: - definind scopurile i interaciunile la un nivel descriptiv nalt, independent de detaliile de implementare, cum ar fi, de exemplu: formularea problemei, - ateptrile clientului sau criteriile pe care trebuie s le ndeplineasc produsul. Faza de analiz poate fi vzut ca o rafinare a detaliilor. Distincia dintre detaliile de nivel nalt i cele de nivel sczut sunt puse mai bine n eviden de abordrile top-down (unde se merge ctre detaliile de nivel sczut) i bottom-up (care tind ctre detaliile de nivel nalt). Documentul cerinelor, numit specificarea cerinelor poate fi realizat ntr-o manier formal, bazat pe logic matematic, sau poate fi exprimat n limbaj natural. Documentul cerinelor-Specificarea: n mod tradiional, el descrie obiectele din sistem i aciunile care pot fi realizate cu ajutorul obiectelor. Aici noiunea de obiect nu trebuie confundat cu obiectul din programarea orientat obiect. Descrierea obiectelor i aciunilor trebuie s fie general si s nu depind de o anumit tehnologie. n general, documentul cerinelor descrie ontologia proiectului, adic vocabularul de cuvinte cheie (n special construcii substantivale i verbale) care va fi utilizat pentru definirea protocolului specific aplicaiei. Descrierile acestea nu implic proiectarea arhitecturii aplicaiei, ci enumerarea prilor componente i a modului n care acestea se comport. Mai trziu, n faza de proiectare, acestea vor fi transformate n primitive informatice, precum liste, stive, arbori, grafuri, algoritmi i structuri de date. Mai concret, documentul trebuie s conin descrieri pentru urmtoarele categorii: - Obiecte: Documentul trebuie s defineasc mai nti ontologia sistemului, care este bazat n mare parte pe construcii substantivale pentru identificarea pieselor, prilor componente, constantelor, numelor i a relaiilor dintre acestea;

- Aciuni: Documentul trebuie s defineasc de asemenea aciunile pe care trebuie s le ndeplineasc sistemul i care sunt sugerate n general de construcii verbale. Exemple de aciuni sunt: metodele, funciile sau procedurile; - Stri: Sunt definite ca mulimi de setri i valori care disting sistemul ntre dou ipostaze spaio- temporale. Fiecare sistem trece printr-o serie de schimbri de stare. Exemple de stri sunt: starea iniial, cea final sau strile de eroare. Cele mai multe stri depind de domeniul problemei. Strile sunt asociate cu obiectele sistemului. Un eveniment declaneaz o tranziie de stare care poate conduce la ndeplinirea unei aciuni de ctre sistem; - Scenarii tipice: Un scenariu este o secven de pai urmai pentru ndeplinirea unui scop. Cnd sistemul este terminat i aplicaia este disponibil, clientul trebuie s poat utiliza, ntr-o manier ct mai facil si clar specificat, toate scenariile tipice ale aplicaiei. Scenariile tipice trebuie s reprezinte majoritatea scenariilor de utilizare ale aplicaiei. Ponderea acestora variaz de la un sistem la altul, dar 90% se consider o proporie acceptabil. Bineneles c un sistem cu un singur scenariu de utilizare este relativ simplu de obinut, pe cnd unul cu mii de scenarii posibile va fi mult mai dificil de analizat. Deseori este invocat regula 80/20: 80% din funcionalitatea sistemului se realizeaz cu 20% din efortul de munc. Executarea restului minoritar de funcionalitate necesit marea majoritate a timpului de lucru; Scenarii atipice: Un scenariu atipic trebuie s fie ndeplinit de sistem numai n cazuri speciale. Clientul poate s spere, de exemplu, c o eroare neprevzut este un eveniment atipic. Totui, sistemul trebuie s gestioneze un numr ct mai mare de categorii de erori, prin tehnici stabilite, precum tratarea excepiilor, monitorizarea proceselor etc.; Faza de proiectare. Pe baza cerinelor din faza de analiz, acum se stabilete arhitectura sistemului: componentele sistemului, interfeele i modul lor de comportare: - Componentele sunt elementele constructive ale produsului. Acestea pot fi create de la zero sau reutilizate dintr-o bibliotec de componente. Componentele rafineaz si captureaz semnificaia detaliilor din documentul cerinelor; - Interfeele ajut la mbinarea componentelor. O interfa reprezint grania dintre dou componente, utilizat pentru comunicarea dintre acestea. Prin intermediul interfeei, componentele pot interaciona; - Comportamentul, determinat de interfa, reprezint rspunsul unei componente la stimulii aciunilor altor componente. Documentul de proiectare descrie planul de implementare a cerinelor. Se identific detaliile privind limbajele de programare, mediile de dezvoltare, dimensiunea memoriei, platforma, algoritmii, structurile de date, definiiile globale de tip, interfeele etc. n aceast faz trebuie indicate i prioritile critice pentru implementare. Acestea sugereaz sarcinile care, dac nu sunt executate corect, conduc la eecul sistemului. Totui, chiar dac prioritile critice sunt ndeplinite, acest fapt nu duce automat la succesul sistemului, ns crete nivelul de ncredere c produsul va fi o reuit. Faza de implementare. n aceast faz, sistemul este construit, ori plecnd de la zero, ori prin asamblarea unor componente pre-existente. Pe baza documentelor din fazele anterioare, echipa de dezvoltare ar trebui s tie exact ce trebuie s construiasc, chiar dac rmne loc pentru inovaii i flexibilitate.

De ex., o component poate fi proiectat mai restrns, special pt un anumit sistem, sau mai general, pentru a satisface o direcie de reutilizare. Echipa trebuie s gestioneze problemele legate de calitate, performan, biblioteci i depanare. Scopul este producerea sistemului propriu-zis. O problem important este ndeprtarea erorilor critice. ntr-un sistem exist trei tipuri de erori: - Erori critice: mpiedic sistemul s satisfac n mod complet scenariile de utilizare.Aceste erori trebuie corectate nainte ca sistemul s fie predat clientului i chiar nainte ca procesul de dezvoltare ulterioar a produsului s poat continua; - Erori necritice: Sunt cunoscute, dar prezena lor nu afecteaz n mod semnificativ calitatea observat a sistemului. De obicei aceste erori sunt listate n notele de lansare i au modaliti de ocolire bine cunoscute; - Erori necunoscute: Exist ntotdeauna o probabilitate mare ca sistemul s conin un numr de erori nedescoperite nc. Efectele acestor erori sunt necunoscute. Unele se pot dovedi critice, altele pot fi rezolvate cu patch-uri sau eliminate n versiuni ulterioare. Planul de implementare. Stabilete programul dup care se va realiza implementarea i resursele necesare (mediul de dezvoltare, editoarele, compilatoarele etc.). Faza de testare. Calitatea produsului software este foarte important. Multe companii nu au nvat ns acest lucru i produc sisteme cu funcionalitate extins, dar cu o calitate sczut. n multe metodologii ale ingineriei software, faza de testare este o faz separat, realizat de o echip diferit dup ce implementarea s-a terminat. Motivul este faptul c un programator nu-i poate descoperi foarte uor propriile greeli. O persoan nou care privete codul poate descoperi greeli evidente care scap celui care citete i recitete materialul de multe ori. Din pcate, aceast practic poate determina o atitudine indiferent fa de calitate n echipa de implementare. Tehnicile de testare sunt abordate preponderent din perspectiva productorului sistemului. n mod ideal, i clientul trebuie s joace un rol important n aceast faz. Testele de regresiune (engl. regression test) sunt colecii de programe care testeaz una sau mai multe trsturi ale sistemului. Rezultatele testelor sunt adunate i dac exist erori, eroarea este corectat. Un test de regresiune valid genereaz rezultate verificate, numite standardul de aur. Validitatea rezultatului unui test ar trebui s fie determinat de documentul cerinelor. n practic, echipa de implementare este responsabil de interpretarea validitii. Testele sunt colectate, mpreun cu rezultatele standardelor de aur, ntr-un pachet de test de regresiune. Pe msur ce dezvoltarea continu, sunt adugate mai multe teste noi, iar testele vechi pot rmne valide sau nu. Dac un test vechi nu mai este valid, rezultatele sale sunt modificate n standardul de aur, pentru a se potrivi ateptrilor curente. Pachetul de test este rulat din nou i genereaz noi rezultate. Acestea sunt comparate cu rezultatele standardelor de aur. Dac sunt diferite, nseamn c n sist a aprut o eroare. Eroarea e corectat si dezvoltarea continu. Acest mecanism detecteaz situaiile cnd starea curent de dezvoltare a produsului invalideaz o stare existent. Astfel, se previne regresiunea sistemului ntr-o stare de eroare anterioar. Exist patru puncte de interes n testele de regresiune pentru asigurarea calitii. Testarea intern trateaz implementarea de nivel sczut. Fiecare funcie sau component este testat de ctre echipa de implementare. Aceste teste se mai numesc teste clear-box sau whitebox, deoarece toate detaliile sunt vizibile pentru test.

Testarea unitilor testeaz o unitate ca un ntreg. Aici se testeaz interaciunea mai multor funcii, dar numai n cadrul unei singure uniti. Testarea este determinat de arhitectur. De multe ori sunt necesare aa-numitele schele, adic programe special construite pentru stabilirea mediului de test. Numai cnd mediul este realizat se poate executa o evaluare corect. Programul schel stabilete stri i valori pentru structurile de date i asigur funcii externe fictive. De obicei, programul schel nu are aceeai calitate ca produsul software testat i adesea este destul de fragil. O schimbare mic n test poate determina schimbri importante n programul schel. Aceste teste se mai numesc teste black-box deoarece numai detaliile interfeei sunt vizibile pentru test. Testarea aplicaiei testeaz aplicaia ca ntreg i este determinat de scenariile echipei de analiz. Aplicaia trebuie s execute cu succes toate scenariile pentru a putea fi pus la dispoziia clientului. Spre deosebire de testarea intern i a unitilor, care se face prin program, testarea aplicaiei se face de obicei cu scripturi care ruleaz sistemul cu o serie de parametri i colecteaz rezultatele. n trecut, aceste scripturi erau create manual. n prezent, exist instrumente care automatizeaz si acest proces. Majoritatea aplicaiilor din zilele noastre au interfee grafice (GUI). Testarea interfeei grafice pentru asigurarea calitii poate pune anumite probleme. Cele mai multe interfee, dac nu chiar toate, au bucle de evenimente, care conin cozi de mesaje de la mouse, tastatur, ferestre etc.i care asociate cu fiecare eveniment sunt coordonatele ecran. Testarea interfeei presupune deci memora- rea tuturor acestor informaii i elaborarea unei modaliti prin care mesajele s fie trimise din nou aplicaiei, la un moment ulterior. Testarea la stres determin calitatea aplica- iei n mediul su de execuie. Ideea este crearea unui mediu mai solicitant dect cel n care aplicaia va rula n mod obinuit. Aceasta este cea mai dificil si complex categorie de teste. Sistemul este supus unor cerine din ce n ce mai numeroase, pn cnd acesta cade. Apoi produsul este reparat i testul de stres se repet pn cnd se atinge un nivel de stres mai ridicat dect nivelul ateptat de pe staia clientului. Deseori apar aici conflicte ntre teste. Fiecare test funcioneaz corect atunci cnd este fcut separat. Cnd dou teste sunt rulate n paralel, unul sau ambele teste pot eua. Cauza este de obicei managementul incorect al accesului la resurse critice. Mai apar i probleme de memorie, cnd un test i aloc memorie i apoi nu o mai elibereaz. Testul pare s funcioneze corect, ns dup ce este rulat de mai multe ori, memoria disponibil se reduce iar sistemul cade. Concluzii Problematica domeniului ingineriei software este divers i se amplific pe msura creterii continue a complexitii sistemelor software. Toate eforturile au fost i sunt direcionate ctre satisfacerea ct mai complet a cerinelor utilizatorilor, a creterii calitii sistemelor i a scderii costurilor de producere.