Managementul P roiectelor Software

1. Managementul Proiectelor Software Universitatea “Politehnica” Bucuresti Facultatea de Automatica si Calculatoare Catedra Calculatoare Conf. Dr. Ing. Costin-Anton Boiangiu Costin.Boiangiu@cs.pub.ro

2. ManagementulProiectelor Software Capitolul 5. Managementul dezvoltarii

3. Ciclulde viaţăal unuiprodus software Ciclu de viaţă • naştere • apareideea (necesitatea) realizăriiprogramuluişi se aprobădezvoltarealui • creştere • dezvoltarea • maturitate • instalarea • exploatareacurentă • întreţinerea • bătrâneţe (vârsta a III-a) • exploatare cu probleme • moarte • scoaterea din exploatare

4. Ciclul de viaţă al unuiprodus software Fazeleciclului de viaţă • definiţia • începecândesteformulatăproblema de rezolvat • puneaccentulpe CE face programul • CE informaţie se prelucrează • CE funcţiisauperformanţetrebuiesăaibăsistemul • CE interfeţe cu altesisteme • CE restricţii de proiectareexistă • CE criterii de validaresuntnecesare • dezvoltarea • puneaccentulpe CUM trebuiefăcutprogramul • se definesc • structurile de date • arhitecturaprogramului • se stabilescdetaliile de implementare ale procedurilorşidatelor • se realizeazătestarea. • exploatarea • instalare • exploatare • întreţinere

5. Ciclul de viaţă al unuiprodus software Faza de definitie • analiza de sistem (ingineria de sistem) • stabileşterolulpe care-l joacăprogramulînansamblulsistemuluiinformaţional al organizaţiei. • planificareaproiectului • analizariscurilor, estimareacosturilorşialocarearesurselornecesarepentrudezvoltare, definireasarcinilor de lucruşi a orarului de derulare al proiectului. • analizacerinţelor • definireadetaliată a informaţiei care se prelucrează, specificareaclară a funcţiilorpe care trebuiesă le execute programulşiprecizarearestricţiilorimpuseasupraacestuia.

6. Ciclul de viaţă al unuiprodus software Faza de dezvoltare • proiectarea • traduce cerinţeleasuprasoftuluiîntr-un set de reprezentări (grafice, tabelare, bazatepelimbaje de descriere) numitespecificaţii de proiectare. • specificaţiile de proiectare se referă la structurile de date, arhitecturaprogramului, algoritmiipentruprelucrărişicaracteristicileinterfeţei cu utilizatorul • codificarea • traduce specificaţiile de proiectareîn cod sursă (limbaj de programare) • testareaunitară • testarea • testare de integrare • testare de acceptare

7. Ingineriaprogramării - Istoric Dezvoltareaartizanală a programelor • cerinţe nerespectate • lipsă de fiabilitate • cu erori sesizate dar neînlăturate • întârzieri ale termenelor de livrare • întreţinere dificilă. 1968, NATO, Bavaria, Prima Conferinţă de SE(Software Engineering) • criza software • nevoiauneiabordărisistematiceşidisciplinate a dezvoltăriisoftului Jaloane • C. Bohm, and G. Jacopini, Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules, CACM, 9(1966), No. 5, 366-371. • E.W.Dijkstra, GOTO Statement Considered Harmful, CACM, 11(1968), No. 3, 148. • W. Stevens, G. Myers, L. Constantine, Structured Design, IBM Systems Journal, 13(1974), No. 2, 115-139. • T. DeMarco, Structured Analysis and System Design, Prentice Hall, 1979.

8. Ingineriaprogramării Configuraţia soft - include toatecomponentelesistemului soft (documentaţiaproiectuluişiprodusului, codulsursă, datele, programulexecutabil, etc) http://satc.gsfc.nasa.gov/GuideBooks/cmpub.html

9. Ingineriaprogramării - definitii Definiţia1 (Fritz Bauer) • stabilireaşipunereaînpractică a unorprincipiiinginereştisolide care săproducăaplicaţii soft fiabileşi care săfuncţionezeeficientpemaşinireale Definiţia2 (IEEE87) • o abordaresistematică a realizării, exploatării, întreţineriişiscoaterii din exploatare a programelor Definiţia 3 (Roger Pressman) • o mulţime de paşisauactivităţi care înglobeazămetodele, instrumenteleşiprocedeeledescrise anterior. Existămaimultemodalităţi de combinare a acestorpaşi, care caracterizeazăceeacenumimparadigmeleinginerieiprogramării

10. Ingineriaprogramării – componente (1) • metode • oferăinformaţiedesprecum se construieştesoftul. • metodepentru: • planificareaşiestimareaproiectului • analiza de sistemşianalizacerinţelor • proiectareastructurilor de date, arhitecturiiprogramuluişi a algoritmilor • codificare, testareşiîntreţinere • instrumente • oferăsprijin automat şisemiautomatpentrumetode • existăinstrumente • specificepentrufiecareclasă de metode • instrumente integrate (CASE)

11. Ingineriaprogramării – componente (2) • procedee • liantulceuneştemetodeleşiinstrumentele • definesc • secvenţaîn care se aplicămetodele • documentele (documentaţii, rapoarte, formulare) necesare • verificărilepentruasigurareacalităţii • punctele de verificare (bornele) pentruevaluareaprogreselorrealizate

12. Ingineriaprogramării: prezentşiviitor Steve McConnell, 10 Best Influences on Software Engineering, IEEE Software, ian-feb 2000 • Revizuirile şi inspecţiile • Principiul ascunderii informaţiei • Dezvoltarea incrementală • Implicarea utilizatorilor în procesul de dezvoltare • Controlul automat al revizuirilor • Evoluţia limbajelor de programare • Modelul randament-maturitate al softului • Programarea orientată pe obiecte • Dezvoltarea bazată pe componente • Metricile şi măsurarea efortului de programare

13. Proiectareasoftului Definiţia 1 http://www.magicnet.net/~jbryson/ WATERFAL.HTML • Transformareacerinţelorîntr-o reprezentare a softului care poatefievaluată din punctul de vedere al calităţiiînainte de începereacodificării. Existădouăetape ale proiectării: • (1) proiectareapreliminară, de ansamblu (transformareacerinţelorîntr-o arhitectură) şi • (2) proiectarea de detaliu (rafinarearezultatuluiproiectăriipreliminareînreprezentări de structuri de date şialgoritmi) Definiţia 2 (Carnegie-Mellon University/Software Engineering Institute SEI TR-004-99) • Transformareaspecificăriicerinţelorîntr-o descriere a moduluiîn care se vorimplementaacestecerinţe. Ea cuprindeactivităţiprecumproiectareaarhitecturii, specificareaabstractăşiproiectareainterfeţelor, proiectareacomponenteloraplicaţiei, proiectareastructurilor de date şi a algoritmilor. Proiectareafoloseşte o varietate de tehnicişiforme de reprezentare, fiecaredintreelefiinddestinatăcapturăriiuneivederi a sistemului din punctul de vedere al activităţiirespective

14. Fundamenteleproiectării

15. Fundamenteleproiectării Scopulproiectăriiesteproducereaspecificaţiilor de proiectare, formate din • (i) proiectul de arhitectură a sistemuluice se varealiza, descrisprindiagrame de structură care definescrelaţiiledintrecomponentelestructurale ale aplicaţiei • (ii) modelelelogiceşifizice de date, care sunttransformări ale modelului conceptual înstructuri de date necesarepentruimplementare • (iii) specificaţiile de proiectare a procedurilor, care conţindescriereaalgoritmică a prelucrărilor • (iv) proiectulinterfeţelor, datprindescrierişimachete

16. Procesul de proiectare a softului Clasificări/accepţiuniale termenuluiproiectare • dupănivelul de abstractizare • proiectareconceptualăsauanalizacerinţelor • proiectarelogică • proiectarefizică • dupănivelul structural • proiectare de ansamblu/preliminară/generală • proiectare de detaliu • dupăobiectulactivităţilortehnice • proiectareaarhitecturii • proiectareadatelor • proiectareaprocedurilor/proceselor • proiectareainterfeţelor

17. Procesul de proiectare a softului Caracteristicileunuiproiect bun (i)săaibă o organizareierarhică, care săpermităfolosireainteligentă a controluluiîntrecomponentelesoftului (ii) să fie modular, adicădescompus logic încomponente care executăfuncţiişisubfuncţiispecifice (iii) săconţinăreprezentăridistincteşiseparabile ale datelorşiprocedurilor (iv) săproducăsubprograme cu caracteristicifuncţionaleindependente (v) săproducăinterfeţe care reduccomplexitateaconexiunilorîntre module şi cu mediul extern (vi) să fie obţinutfolosind o metodăiterativă care să fie dirijată de informaţiaobţinutăînanalizacerinţelor Întimpulproiectăriicalitateaproiectului se verificăprin • reviziitehniceformale • inspecţii ale proiectului(“design walkthroughs”).

18. Evoluţiametodelor de proiectare • suntstrâns legate de • paradigma de dezvoltare care se aplică • metodele de analiză a cerinţelor • influenţesemnificativeasupraproiectării • (a) dezvoltareamodulară a programelor (Parnas, 1972; Dennis, 1973) • (b) metodelepentrurafinareaarhitecturii soft înmanieră top-down (Wirth, 1971) • (c) programareastructurată (Dahl, Dijkstra, Hoare, 1972; Mills, 1972). • clase de metode de proiectare - se suprapunpesteclasele de metode de analiză a cerinţelor, trecuteînrevistăîncapitolul 4 • (a) metode de proiectarestructurată (metodebazatepetranslatareafluxului de date într-o definiţie de proiect - Stevens, Myers, Constantine, 1974; Yourdon, Constantine, 1979) • (b) metodebazatepetranslatareastructurilor de date (Jackson, 1975; Warnier, 1974) • (c) metodebazateşi orientate peobiecte (Booch, 1983; Meyer, 1988; Coad, Yourdon, 199x; Rumbaugh, HOOD, UML). • caracteristicicomune • (i) mecanismepentrutranslatareareprezentăriidomeniuluiinformaţieiîntr-o reprezentare de proiectare • (ii) folosireaunornotaţiipentrureprezentareacomponentelorfuncţionaleşi a interfeţeloracestora • (iii) o tehnicăeuristicăpentrurafinareşipartiţionare • (iv) existenţaunorcriterii de evaluare a calităţii

19. Proiectareabazatăpeprototipizare • metodăalternativăşiindependentă de proiectare • prototipfuncţional: echivalentuluneispecificaţiipehârtie • avantaje • productivitatecrescută • o maibunăsurprindere a cerinţelorclientului • dezavantaje • ciclu de viaţădezordonat (codifică - implementează - repară) • nu acoperătoateaspecteleproiectării • poateaduce la acceptarearapidă a unuiproiect, scurtcircuitândachiziţiaşiselecţia • sistemulpoatescăpa de sub control • reduce creativitatea • performanţemaislabe • strategii de prototipizare • prototipizarearapidă • medii RAD - ciclul • construirea de ecrane, formulareşirapoarte • evaluareaşifolosireainterfeţelor de cătreutilizatoru • prototipizareasistemelor • instrumente 4GL, generatoare de aplicaţii • construireaunei BD prototip + încărcareaacesteia cu date de test • proiectareainterfeţelor (rapoarte + formulare de introducere a datelor) • integrareapaşiloranterioriîntr-un nucleu user-friendly

20. Paşiiproiectării Selecţia Achiziţia Proiectareapropriu-zisăşiintegrarea

21. Selecţia Obiective • (a) căutareaşiidentificareasoluţiilor alternative (manualeşiinformatice) pentrusistemulstudiat (ţintă) • (b) evaluareafezabilităţiifiecăreisoluţii alternative • (c) recomandareaceleimaibunedintreele Activităţi • identificareasoluţiilorposibile • consultareautilizatorilor, managerilor, personaluluitehnic • start: specificareacerinţelor • diferăprin • gradul de automatizare a prelucrărilor • instrumentele soft folosite • arhitecturile hard-soft

22. Selecţia Activităţi(cont) • analizafezabilităţiifiecăreivariante (soluţii) • tipuri de fezabilitate - ponderi • tehnică • operaţională • economică • de derulare • indicator de fezabilitate: sumăpunctaj * pondere • scală de notare 0 - 100 (punctaj) pentrufiecaretip de fezabilitate • pondereasociatătipului de fezabilitate • stabilireasoluţieialese • propunerea de sistem(“system proposal”) • planulproiectului • estimări de dimensiune • soluţiiidentificate • analizafezabilităţii • conducereaiadecizia • cumpără ŞI/SAU • dezvoltă

23. Achiziţia • se referă la componentelesoluţieirecomandate care se vorcumpăra • categorii de componentesupuseachiziţiei: hard, soft şiservicii (consultanţă, instruire, asistenţătehnică, etc) • obiectiveleachiziţiei: • (a) căutareaşiidentificareaproduselorspecifice care pot ajutasoluţiarecomandatăpentrusistemulţintă • (b) solicitarea, evaluareaşiclasificareapropunerilor (ofertelor) furnizorilor • (c) selectareaşirecomandareaceleimaibuneoferte • (d) stabilireacerinţelorpentruintegrareaproduselorce se vorachiziţionaînsoluţie • activităţileachiziţiei: • (i) stabilireacriteriilortehnice • (ii) solicitarea de oferte • (iii) validareaofertelor • (iv) evaluareaofertelor • (v) stabilireaoferteicâştigătoare • (vi) stabilireacerinţelor de integrare a produselorachiziţionateînsoluţiapropusă

24. Proiectareapropriu-zisă Grupuride activităţi: • proiectaregenerală (de ansamblu) • proiectare de detaliu Proiectareagenerală • aceleactivităţi care servesc la realizareauneischiţe a proiectului general pentrusistemulţintă, schiţănumităproiect de ansamblu, proiectpreliminarsaugeneral • activităţi • (1) Proiectareaarhitecturiiprogramului • (2) Analizaşidistribuireadatelor (proiectarealogică a datelor) • (3) Proiectarealogică a prelucrărilor Proiectarea de detaliu • niveluluiproiectăriifizice • activităţi • (4) Proiectareafizică a datelor (fişiereşi/sau BD) • (5) Proiectareaintrărilorşiieşirilor • (6) Proiectareainterfeţelor on-line Fiecaresubpas se încheie cu reviziişiinspecţii

25. Principiileproiectării FALS: programul bun esteacela care funcţionează. Deosebiriîntre un program care funcţioneazăşi un program bun • factori de calitate • program bun • (1) programulfuncţionează, dar nu oricum, ciînconformitate cu documentul de specificare a cerinţelor • (2) evoluţiaprogramului (întreţinereaacestuia) se poategestionafărăgreutăţimajore • (3) programul nu este format numai din cod sursă, cişidintr-o mulţime de altedocumente care suntdestinatetocmairealizăriiprimelordouăcerinţe Concepteşiprincipii de proiectare • (1) abstractizarea • (2) ascundereainformaţiei • (3) descompunerea • (4) modularizarea Concepteleşiprincipiileaplicateînsituaţii concrete devintehnici

26. Principiileproiectării Abstractizarea • neglijareadetaliilorpentru a surprindeesenţa • procesul de dezvoltareeste o succesiune de abstractizări • nivelul conceptual: modeleconceptuale, generale • nivelul logic: modelelogice • nivelulfizic: modelefizice • mecanisme de abstractizare • abstractizareafuncţională (procedurală) • abstractizareadatelor • abstractizareacontrolului • abstractizareaprocedurală • prelucrărileefectuate de o procedură se concentreazăînnumeleacesteia • se realizeazăprin • specificare: nume, parametri, pre- şipostcondiţii • parametrizare: clase de probleme • reprezintă un contractîntrecel care implementeazăproceduraşicel care o foloseşte

27. Principiileproiectării Abstractizarea(cont) • abstractizareadatelor • neglijeazădetaliile de reprezentare a unui tip de date punândaccentulpecomportamentul (operaţiile) acestuia • caracteristicileabstractizăriidatelor • încapsularea: reprezentareaşioperaţiilesuntpuseîmpreună • ascundereainformaţiei: accesul la reprezentare se face numaiprinintermediuloperaţiilor • specificareaTDA conţine • elementeleceformeazăreprezentareaTDA • structura - relaţiiledintreelemente • domeniul - mulţimeavalorilorvalide • invariantulTDA • specificareaoperaţiilor • clase de operaţii • constructori • accesori • modificatori • reprezintă un contractîntrecel care implementeazăTDA şicel care foloseşteinstanţeleacestuia

28. Principiileproiectării Abstractizarea(cont) • abstractizareacontrolului • manifestări ale controlului • evenimente • interacţiunea cu utilizatorul • aplicaţia • alteaplicaţii • sistemul de operare • excepţii - erori de execuţie • declanşare • propagare • capturare • prelucrare • mijloace de exprimare • structurilefundamentale ale programăriistructurate • secvenţa • decizia • repetiţia • evenimente: TOE (task, object, event) • excepţii: throw, try, catch

29. Principiileproiectării Ascundereainformaţiei David L. Parnas, On the Criteria to be Used in Decomposing Systems into Modules, CACM, 14(1972), No. 4, 220-225. Principiulascunderiiinformaţiei • (a) fiecarecomponentăîşiascundedetaliile interne • (b) componentelecomunicăîntreeleprininterfeţebine definite Sarcini • proiectantulspecifică • programatorulimplementează • programatorul de aplicaţiefoloseşte (apelează) Nivele de structurare a programelorşiascundereainformaţiei • procedura: • public: specificarea • ascuns: date locale şialgoritm • modulul • public: interfaţa • ascuns: implementareaoperaţiilor din interfaţă, codul de iniţializare • TDA • public: specificarea (operaţiipublice) • ascuns: implementarea (clase): reprezentare, implementareoperaţii • deciziile de proiectare • public: aceledecizii care se pot fundamenta • ascuns:aceledeciziipentru care nu există o fundamentaresolidă • detaliile de implementare • blocuri de control (programe shell), coduri de caractere, collating sequence

30. Principiileproiectării Descompunerea • un sistem mare estedescompusînsubsistememaimici, maiuşor de înţelesşi de gestionat • permiteexprimareastructuriisistemuluiprin • arhitectura soft • ierarhiacontrolului • instrumentefolosite • diagrameierarhice • reţele de procese (DFD – “Data Flow Diagram” numai cu proceseşifluxuri de date) • avantaje • gestionareacomplexităţii • implementareşitestareseparată a subsistemelor • activităţiparalele, muncăînechipă

31. Principiileproiectării Modularizarea Definiţii (IEEE87) • modul: o parte a unui program, separată logic de celelaltepărţi ale acestuia • program: colecţie de abstractizări (module), fiecaregestionând un aspect particular al problemei de rezolvat Modularizarea - concept generic cepermiteproiectantuluisă • (i) descompună un sistemînunităţifuncţionale • (ii) impună o ordineierarhică a folosiriiacestora • (iii) implementezeabstractizareadatelor • (iv) dezvoltesubsistemeindependente Sistem modular • colecţie de abstractizări, fiecarereprezentând un subsistembinedefinit • fiecareabstractizare se descompuneînfuncţii Caracteristicileunuimodul • sintactic • conţinedeclaraţii de subprograme, variabile, tipuri de date, constante • compilareseparată • implementeazăabstractizăriproceduralesauTDA • semantic • interfaţă • implementare • nivel logic • stare (privată) • operaţii (publice) • client - server • nivelfizic • variabile locale • procedurişifuncţiipublice

32. Principiileproiectării Cerinţelemodularizării B. Meyer, Object-Oriented Software Construction, Prentice-Hall, 1988 (1) descompunereamodulară: o problemă P se poatedescompuneînsubprobleme (module) (2) compunereamodulară: elementele (modulele) dejaexistente se pot combinapentru a contribui la rezolvareaproblemei P (3) protecţiamodulară: arhitecturile de module realizaterestrângpropagareaunorcondiţiianormale, efectulacestoralimitându-se la modululîn care eleaparsau, încelmairăucaz, la modulele client ale acestuia (4) înţelegereuşoară: are un înţeles de sine stătător, pecâtposibilfără a finecesarăconsultareaaltor module (5) independenţaclienţilorfaţă de modificărilefăcuteînmodul: modificărilemiciîntr-un modulsă nu afectezecelelalte module (continuitatemodulară) Gradul de independenţă a unuimodul

33. Principiileproiectării Cerinţelemodularizării (cont) Gradul de independenţă a unuimodul • cuplarea (măsoarăinterdependenţarelativă) • coeziunea (măsoarăputereafuncţională) Cuplarea • tăriacuplăriiestecaracterizată de • complexitateainterfeţelor • tipul de conectare • tipul de comunicareîntre module • cuplareslabă - module bineproiectate • module independente • cuplareprin date - parametri transmişi la apelul subprogramelor • cuplare de nivelmediu • cuplareacontrolului: • indicator (flag) în client • rutinădispecerîn client - apeluriînfuncţie de flag • cuplarestrânsă - de nivelînalt • cuplareexternă - depinde de platformagazdă • apeluri de serviciisistem, formate de conversie, protocoale de comunicaţie • cuplarefolosind zone comune de memorie • două module care folosescaceeaşizonă de memorie • fiecarepoatemodificavalorile din zonacomunăfără ca săştiecelălalt • cuplare de conţinut - cod spaghetti • un modulpoatemodificadatele, controlulsauchiarinstrucţiunileceluilalt

34. Principiileproiectării Cerinţelemodularizării (cont) Coeziunea • înaltă - modulbineproiectat • informaţională - modululimplementează un TDA • toateserviciilemodululuifolosescaceleaşi date, de obiceiascunseînimplementareasa • funcţională • modululimplementeazătoateoperaţiilenecesareuneifuncţiimajore a aplicaţiei • secvenţială • parametrii de ieşireaiunuiserviciusuntparametri de intrareîn alt serviciu • funcţionalitateamodulului se obţineapelândîntr-o anumităordineserviciile • medie • de comunicare • toateserviciile au aceiaşiparametri de intrareşi de ieşire • procedurală • toateserviciiletrebuieexecutateîntr-o anumităordine • joasă - modul slab proiectat • temporală • unelecomponentetrebuieexecutateîntr-un moment binedefinit al execuţiei • codul de iniţializare • asocierelogică • gruparedupăfuncţionalitate • generare de rapoarte • intrări-ieşiri • funcţiimatematice • incidentală • serviciiindependente

35. Principiileproiectării Cerinţelemodularizării (cont) Principiide proiectare a modulelor (1) principiulinterfeţelorpuţine • număr minim de legături cu alte module (2) principiulinterfeţelormici • debit minim de informaţieschimbată cu alte module (3)principiulinterfeţelorpublice • serviciile din interfaţaunuimodulsuntdisponibileoricărui client, fărădiscriminare (4) principiulascunderiiinformaţiei • datele locale ale modululuisuntaccesibilenumaiprinintermediulserviciiloracestuia • toatedetaliile de implementare a serviciilorsuntascunsemodulului client

36. Proiectareaarhitecturii Proiectareaarhitecturii • descompunereasistemuluiînsubsisteme • fiecaresubsistemconţine o mulţimedisjunctă de servicii • subsistemele se descompunînmodule Definiţii (Sommerville, 1996) • subsistem • sistemînadevăratulînţeles al cuvântului • este independent - exploatareasa nu depinde de serviciileoferite de altesubsisteme • este format din module • comunică cu altesubsistemeprininterfeţebine definite • modul • componentă a unuisistem care • furnizeazăserviciialtor module • foloseşteserviciileoferite de alte module • nu esteconsideratsistemindependent

37. Proiectareaarhitecturii Etapeleproiectăriiarhitecturii • (1) structurareasistemului • (2) modelareacontrolului • (3) descompunereaîn module • (4) optimizareaproiectului • (5) revizuireaproiectului (1) Structurareasistemului • activităţi • descompunereasistemuluiînsubsisteme • identificareainterfeţelordintresubsisteme - fluxuri de date • rezultate • diagrama de blocuri de arhitectură • nu conţineinformaţie de control • modelefolosite • depozitcomun de date • subsistemelefolosesc date comune • un subsistem produce date folosite de alt subsistem • client-server • subsistemefolosescserviciioferite de altesubsisteme • serviciile se proiectează independent de posibiliiclienţi • maşinăabstractă • aplicaţiiorganizatepenivele • niveluliexpuneserviciipentruniveluli-1 - primitivelemaşiniivirtualepentruimplementareaniveluluii-1

38. Proiectareaarhitecturii Etapeleproiectăriiarhitecturii (cont) (2) Modelareacontrolului • scopuri: • identificarearelaţiilor de control întresubsistemeleidentificate • folosireaacestora la planificareaordinii de dezvoltare a subsistemelor • modelele de control: • (a) control centralizat - arhitecturăcentralizată • (b) sistemedirijate de evenimente • arhitecturacentralizată • aplicaţiiîn care există un subsistem central (program principal), care asigurăcontrolulexecuţieituturorcelorlaltesubsisteme • temporar, controlulexecuţieipoatefidelegatunorsubsisteme, însăprimulnivel de control aparţinesubsistemului central • modele de apel • execuţiesecvenţială - modelulapel-revenire • execuţieparalelă - modelulmanager • sistemeledirijate de evenimente • subsistemelerăspund la evenimente generate înexteriorullor • mediulsistemului: utilizatori, alteaplicaţii • altesubsisteme ale sistemului • sistemul de operare • model de apel • apelul se execută la producereaunuieveniment • sistemulesteîntr-o stare stabilă • programul principal - buclă de evenimente (mesaje) • preluare din coada de evenimente • prelucrare, traducere • dispecerarespresubsistemul care trebuiesă-l execute

39. Proiectareaarhitecturii Etapeleproiectăriiarhitecturii (cont) (3) Descompunereaîn module • scopuri: identificarea • tipurilor de module • interconexiunilorîntre module • descompunerea se face la nivelulfiecăruisubsistem • se folosesc • diagramele de blocuri de arhitectură (conţinsubsistemeleşifluxurile de date) • modelele de control • criteriile de modularizare pot fipropriifiecăruisubsistem • depind de metodele de proiectarefolosite (7.1.3): • bazatepe flux de date • bazatepestructuri de date • orientate peobiecte • fiecaredintremetode are avantajeşidezavantaje • absolutizareauneiaîndefavoareacelorlaltedenotă o slabăcunoaştere a esenţeiinginerieiprogramării • NU EXISTĂ REŢETE UNIVERSALE: profesionalismulinformaticianului se manifestătocmaiînalegereametodeiceleimaipotrivitepentruproiectareauneiaplicaţii date

40. Proiectareaarhitecturii Finalizareaproiectului de ansamblu Etapele (1) - (3) producproiectul de arhitecturăiniţial Etapele (4) - (5) producproiectul de arhitectură (4) Optimizareaproiectuluiiniţial de arhitectură • acoperă nu numaiproiectarea, cişiimplementareaşitestarea • evaluareacomunicăriiîntre module nu se poate face completdecâtdupăimplementare • strategie de optimizare • (1) la proiectareaarhitecturii - se descompunesistemulîn module şi se specificăfiecaremodul • (2) la proiectarea de detaliu - se elaboreazăspecificaţiile de programarepentrufiecaremodul • (3) la implementare - se implementează (codificare + testare) moduleleproiectate • (4) la testarea de sistem - se măsoarăperformanţelesistemuluişi se detecteazălocurileînguste (serviciişi module critice) • serviciicritice: execuţiadureazămult • module critice: module cu interacţiune client-server puternică: timpul de comunicareîntre module afecteazăperformanţelesistemului • (5) se reconfigureazăşi se recombinămodulelecriticeşi se reia de la (3), pânăcând se obţinrezultateleaşteptate • reproiectareaalgoritmilorpentruserviciilecritice • combinareamodulelorcriticeîntr-unulsingur

41. Proiectareaarhitecturii Finalizareaproiectului de ansamblu (cont) (5) Revizuireaproiectuluiiniţial de arhitectură • documentaţiaproiectului de arhitecturăconţine • DFD • modelele de date • diagrama de blocuri de arhitectură • descompunereasubsistemelorîn module (structura de interconectare a modulelor) • legăturadintre module şimodelul logic de date • restricţiile de timp • excepţiile • pentrufiecaremodul se precizeazănumele, descriereafuncţională a acestuiaşispecificareainterfeţei (serviciilorfurnizate) • scopulrevizuirii - dupăetapa (1) • sădemonstrezecăstructuraarhitecturiisistemuluişicaracteristicileacestuiace se pot observa din exterior satisfaccerinţeleprecizateîndocumentul de specificare a acestora • obiectulrevizuirii • (a) caracteristicilefuncţionale • (b) atributele de performanţă • (c) interfeţele cu mediul extern • (d) dialogurile cu utilizatorul • (e) formatulrapoartelor • (f) condiţiilecegenereazăexcepţiişigestiuneaacestora La terminarearevizuirii se recomandăîncheiereaunui document de acceptare, semnat de managerul de proiect

42. Programareaextrema (XP - eXtreme Programming) • Programareaextrema: • Parte a miscariidenumite “Agile Development” (DezvoltareAgila) • Este o metoda de dezvoltarefoarteiterativasiincrementala • Motto: “Imbratiseazaschimbarea” • Referinte: • http://www.extremeprogramming.org/ • Wiki Wiki. The Portland Pattern repository http://c2.com/cgi/wiki?UserStory • http://xprogramming.com/

43. eXtremeProgramming (continuare) • Echipa mica de dezvoltatorii • Membriiechipeitrebuiesa fie foartebuni • Se lucreaza in echipe de catedoidezvoltatori • Se incearcasa se minimizezeeforturilenecesaredezvoltariiproiectului • Cerinteleproiectuluisuntexprimate sub forma unorpovesti ale clientului

44. eXtreme Programming - Vedere de ansamblu

45. eXtreme Programming - Vedere de ansamblu a uneiiteratii

46. eXtreme Programming - Vedere de ansambluasupradezvoltarii

47. eXtreme Programming - Vedere de ansambluasupraactivitatii de programare

48. CesuntUser Stories? • Un user story este o scurtadescriere a ceeacevreaclientul de la produsul software; estescrisa de catre client, intr-un limbaj familiar acestuia, fara a folositermenitehnici • De obicei o asemeneapoveste nu continemaimult de 3-5 propozitii

49. Scopulunoruser stories • User Stories suntfolositepentru a creaestimarile de timp • Pot inlocuidocumentelemari care prezintacerinteleutilizatorilor • Suntfolosite de asemeneapentrucazurile de test la testele de acceptare

50. SpecificareaCerintelorUtilizatorilorVS User Stories • Nivel de detaliu • User stories suntscurtesi la obiect • User stories artrebuisacontinadoaraceledetalii care pot genera o estimare minima a riscurilorsiperioadanecesaraimplementariicazurilor de utilizare respective • Atentiesporita la nevoileclientului • Artrebuievitatedetaliilespecificeuneianumitetehnologii, formatulbazei de date saualgoritmiifolositi; accentultrebuiesa fie pus penevoilesibeneficiileclientului, si nu pe forma interfeteigraficespreexemplu