Universitatea Transilvania din Braov Facultatea de Matematic i Informatic Catedra de Informatic aplicat

Sisteme integrate de proiectare i programare

Elemente introductive n ingineria softului (Suport de curs pentru semestrul I)

Dorin Bocu

Motto-ul cursului Nevoia de a cunoate a dus la inventarea conceptelor. Nevoia de a explica cunoaterea a dus la inventarea meta-conceptelor. Nevoia de a ascunde o parte din cunoatere a dus la inventarea limbajelor de modelare. nainte de a fi un "stil de interpretare", arta de a modela este un mod de" a face compozi ie". Autorul

Cuvnt nainte Dei relativ nou, lumea informaticii impune respect prin problemele formulate, conceptele i teoriile dezvoltate pentru rezolvarea acestor probleme. Fundamentarea teoretic a universului informa ional aflat n zona de impact cu calculatorul este un exemplu de demers n spiral a crui dinamic i profunzime este greu de egalat n alte domenii. Permanenta schimbare a infrastructurilor informa ionale orientate pe calculator men ine la cote de alert maxim efortul de redefinire a paradigmelor teoreticoaplicative din lumea softului. Aproape toate tipurile de activitate uman pot fi organizate i desfurate cu totul altfel n prezen a calculatorului. Motivul acceptrii calculatorului n preajma omului sau n locul acestuia? Operativitate, precizie, obiectivitate. Despre consecin ele n plan estetic i moral ale rtcirii omului n sofisticata jungl a universului informa ional planetar (n curs de configurare) este, probabil, prematur s discutm i nici nu ne propunem aa ceva n aceast lucrare. Desprinderea omului de condi iile lui naturale de via a nceput de mult, n preistorie, odat cu descoperirea focului. n zilele noastre aceast desprindere continu cu o vitez (sau grab) care, uneori, ne pune pe gnduri. Din aceast uria epopee a desprinderii omului de natur ne propunem s analizm unele aspecte care se refer, n fond, la nevoia acestuia de a crea o realitate virtual care s-l ajute, s-l deconecteze i, dac se poate, s-l substitue. Acest joc n care s-au angajat energii uriae are toate ansele s dureze deoarece multe dintre abilit ile omului sunt greu de modelat i, spre deliciul cercettorilor, unele dintre ele aproape insurmontabile. Aceast lucrare ncearc un lucru destul de dificil ( innd cont de marea diversitate a abordrilor n literatura de specialitate) i anume identificarea bazelor ingineriei sistemelor soft. Adresndu-se tuturor celor interesa i de tiin a i, n egal msur, arta de a realiza sisteme soft, prezenta lucrare poate fi nceputul unui drum lung, uneori complicat i, de ce nu, interesant.

Capitolul 1 Probleme a cror rezolvare depinde esen ial de ingineria sistemelor soft
Sistemele care se adapteaz uor la condi iile de mediu sunt nzestrate cu subsisteme informa ionale performante i fiabile. De exemplu, conducerea unei afaceri astfel nct aceasta s func ioneze fr sprijin din afar, ba chiar s fie generatoare de resurse ale dezvoltrii, este o problem complex care pretinde persoanelor implicate cunotin e i abilit i remarcabile relativ la achizi ionarea datelor necesare pentru cunoaterea strii afacerii, interpretarea corect a datelor i a conexiunilor dintre acestea i, pe aceast baz, elaborarea de decizii. Cunoscnd modul de a gndi i ac iona al unor manageri, fcnd haz de necaz, deducem, i din cele spuse mai sus, c pentru a avea timp s doarm, unii manageri confund informarea sistematic cu arta de a supravie ui ct mai mult informndu-se fr metod.

1.1 Ce este ingineria sistemelor soft? Mai nti, s observm frecven a destul de mare cu care ntlnim sau vom ntlni sintagma ingineria softului. Pentru comoditate o voi nota, prescurtat i IS. Din dorin a de a nchega repede un dialog cu cititorul, anticipez c: Ingineria softului este o ramur a tiin ei calculatoarelor, n permanent evolu ie, care fundamenteaz teoretic o parte din activit ile specifice realizrii sistemelor soft. Spunem o parte deoarece realizarea unui sistem soft are, de regul, n spate, cunotin e din multe alte ramuri ale tiin ei calculatoarelor precum i din alte domenii (algoritmic, programarea calculatoarelor, limbaje formale, cercetri opera ionale, psihologie, teoria general a sistemelor, etc.). Tentant i interesant problema definirii riguroase a sintagmei tiin a calculatoarelor. Autorul acestei lucrri vede n spatele acestei sintagme domenii precum: algoritmica, teoria matematic a algoritmilor (calculabilitate i decidabilitate), bazele matematice ale sistemelor de calcul, bazele logice ale sistemelor de calcul, teoria formal a specificrii limbajelor de programare, problematica limbajelor de programare, bazele contructive ale sistemelor de calcul (un domeniu de mare complexitate i cu o dinamic remarcabil), inteligen a artificial (un domeniu n care cutrile sunt din ce n ce mai ramificate i mai profunde), ingineria softului, teoriile dezvoltate n jurul problematicii bazelor de date, teoriile dezvoltate n jurul arhitecturilor de tip re ea, etc. Este clar, sper i pentru cei care nc mai vd n informatic un exerci iu de utilizare inspirat a tastaturii, faptul c tiin a calculatoarelor este variat ca preocupri, solicit intens intelectul i, nc un amnunt important, viteza cu care afirma iile din informatic devin istorie este mult mai mare dect viteza cu care se ntmpl acelai lucri n fizic, sau matematic, de exemplu. Care sunt, totui, acele activit i specifice realizrii sistemelor soft care cad sub inciden a IS? Le putem rezuma astfel: 10 Abstractizarea solu iei unui sistem soft, prin care desemnm demersul conceptual n urma cruia specialistul n IS trece de la enun ul problemei la solu ia acesteia. 20 Organizarea procesului de abstractizare (modelare) a solu iei unui sistem soft. ndeosebi n cazul sistemelor soft de complexitate mare i medie modul de organizare a efortului de modelare poate influen a hotrtor calitatea unui sistem soft. 30 Reprezentarea solu iei unui sistem soft de-a lungul ntregului proces de modelare; documentarea complet a solu iei sistemului soft. Este vorba, n esen , de rezolvarea eficient a unor probleme de comunicare ntre participan ii la realizarea unui sistem soft, precum i de rezolvarea unor probleme de comunicare ntre realizatorii sistemului i diferitele categorii de beneficiari ai sistemului soft. 40 Optimizarea managementului procesului de realizare a unui sistem soft. Ca n orice alt tip de industrie i n industria softului conteaz enorm (pentru lansarea pe pia cu succes a unui sistem soft) calitatea actului de management. Sloganul cheie n IS ar trebui s fie: Cum se poate sistematiza ,eventual automatiza, procesul de realizare a unui sistem soft de calitate, ieftin i ob inut n timp util?.

IS ncearc (n diferite chipuri i de mai mult timp) s ne nve e cum poate deveni realitate acest slogan. Modalitatea prin care IS rezolv aceast problem este (simplificnd lucrurile) propunerea de metodologii de dezvoltare a softului (MDS). Istoria MDS este lung i destul de dificil de sintetizat fr a omite numeroase aspecte interesante. Firul cluzitor al acestei istorii ar putea fi, totui, definit astfel: 10 Fiecare metodologie dorete s instaureze o anumit rigoare n procesul de elaborare a solu iei unui sistem soft. 20 Fiecare metodologie se individualizeaz prin accentul pe care l pune pe un anumit element definitor (unul sau mai multe concepte de baz, unul sau mai multe principii de baz, formalizmul de reprezentre, etc.). 30 Fiecare metodologie dorete s ofere suport ct mai consistent pentru realizarea de sisteme soft de calitate. Dup unele aprecieri exist, nc, o diversitate prea mare de metodologii de dezvoltare a softului, fapt care nu stimuleaz neaprat productivitatea specialitilor n IS. n jurul marilor firme productoare de soft se cristalizeaz, progresiv, elemente i idei cu ajutorul crora se alimenteaz procesul de fundamentare a unor noi MDS. Aceste MDS primesc, de regul, girul mediilor academice, dup care se ntorc la utilizatori, care le consider adecvate pentru rezolvarea problemelor lor. Schematiznd, avem situa ia din Figura 1.1, adic un fel de circuit al apei n natur. Privind mai atent, ns, observm c este vorba de un proces cu conexiune invers pozitiv care, pe termen lung, are ca scop optimizarea suportului de care au nevoie specialitii n IS pentru a realiza sisteme soft. Astfel se prezint IS dac privim lucrurile din avion. n realitate situa ia este mult mai complex. Acest fapt va iei la iveal n cele ce urmeaz, cnd aplicnd descompunerea topdown n conjunc ie cu un permanent efort de abstractizare, vom n elege mai bine structura i specificul unui demers IS.
Firme/Persoane implicate n realizarea de sisteme soft

Idei, cerin e, solu ii par iale noi

Laboratoare de cercetare

MDS nou

Figura 1.1 Binomul cercetare-aplica ii n evolu ia MDS

1.2 Ce este un sistem soft? Destul de dificil un rspuns de tip defini ie la aceast ntrebare deoarece diversitatea crea iior care concureaz la calitatea de sistem soft este din ce n ce mai mare. Astfel, poate fi sistem soft un program executabil, ob inut cu ajutorul unui compilator C++. Tot sistem soft putem considera i un sistem de programe executabile care coopereaz pentru rezolvarea unei probleme date. De ce n-am socoti sistem soft un compilator, un SGBD sau chiar un sistem de operare? Tot un sistem soft poate fi considerat, cu deplin temei, un control ActiveX. De fapt, cnd vine vorba de tehnologiile soft de ultim or (ndeosebi cele promovate de Microsoft) no iunea de sistem soft face fa unor conota ii cu totul remarcabile (DLL-urile, controalele OLE, obiectele programabile, al i deriva i ai tehnologiilor COM i DCOM, etc.). Evident, se poate ncerca, pentru a face mai mult ordine n prezentare, o clasificare a aplica iilor recunoscute de platforma Microsoft/Win32. Aceste tipuri de aplica ii sunt: aplica ia de tip consol; este aplica ia care aduce n lumea Windows caracteristicile de baz ale unei aplica ii cu interfa orientat pe text. aplica ii Win32 tradi ionale; o astfel de aplica ie are toate elementele care sunt prezente ntr-o aplica ie Windows complet (fereastr de afiare, bar de meniuri, bar cu instrumente, bar de stare, etc.). O stfel de aplica ie, spre deosebire de aplica ia de tip consol are mari disponibilit i de cooperare cu sistemul de operare Windows. biblioteci cu legturi dinamice (DLL-Dynamic Link Library); o bibliotec DLL este, n esen , o colec ie de func ii care pot fi apelate din alte module executabile Windows. Nu discutm aici motivele care au generat specificarea acestei tehnologii de ctre specialitii de la Microsoft(dei acesta ar fi un foarte interesant studiu de caz ntr-o lucrare pe teme IS). Important este c, realizarea unei biblioteci DLL este un exerci iu deosebit att din punct de vedere al elaborrii solu iei tehnice ct i din punct de vedere al programrii. Aceasta deoarece, mai mult dect ntr-o aplica ie Windows ordinar, realizarea unei biblioteci DLL pune la ncercare abilit ile specialistului IS n ceea ce privete definirea de interfe e optimale pentru func ii, specificarea/scierea de cod generic, specificarea/scrierea de cod reentrant, cunoaterea particularit ilor programrii sub Windows, etc.. Controalele ActiveX; sunt un gen de mini-aplica ii care pot fi ncapsulate n orice obiect de tip container. Container poate fi fereastra cadru a unei aplica ii, sau un document HTML. Reprezentnd, de fapt, extinderea tehnologiei OLE la cerin ele universului INTERNET, ActiveX permite programatorilor s sporeasc gradul de func ionalitate al programelor fr prea mult efort. Prin utilizarea tehnologiei ActiveX, programatorul consimte s respecte o serie de reguli, s surmonteze o serie de obstacole, dar are i avantajul de a beneficia de efortul de modelare al altor specialiti n IS, n caz de convergen de interese cu acetia.

Am terminat, astfel, scurta trecere n revist a tipurilor de aplica ii suportate suportate de platforma Windows. Evident, am pus n discu ie elemente noi care ne-ar putea ajuta la definirea no iunii de sistem soft. Continund mica noastr investiga ie, ne putem ntreba dac un document HTML poate fi considerat sistem soft? ntrebri asemntoare ne putem pune relativ la crea ii precum: colec iile de fonturi utilizate de editoarele de texte, aa zisele fiiere cu resurse promovate de mediile vizuale de programare, colec iile de clase gen MFC (Microsoft Foundation Class), etc.

Este clar, sper, motivul pentru care, la nceputul acestui paragraf, am afirmat c este dificil de dat o defini ie viabil no iunii de sistem soft. Nu ar fi acesta singurul caz (Biblia opereaz cu no iunea de Dumnezeu fr s ne-o defineasc. Cu toate acestea exist oameni care consider biblia o capodoper att din punct de vedere al tipului de scriitur ct i din punct de vedere al modului de organizare a argumenta iei). Contnd, mai ales pe valoarea ei didactic, propun urmtoarea defini ie a no iunii de sistem soft. Se numete sistem soft orice produs al IS care poate fi utilizat pentru a fundamenta sau realiza protocoale efective i relativ autonome de prelucrare sau comunicare a datelor i informa iilor ntr-un context informa ional dat. Aadar, atributele esen iale ale unui sistem soft sunt: 10 Capacitatea de a fundamenta / realiza protocoale efective de prelucrare / comunicare a datelor / informa iilor. Exemple. -MFC poate fundamenta protocoale efective de prelucrare / comunicare date i informa ii; -Un sistem expert realizeaz un protocol efectiv de prelucrare / comunicare date / informa ii; -Un document HTML realizeaz un protocol efectiv de prelucrare / comunicare date / informa ii, etc. 20 Protocolul fundamentat sau realizat are o autonomie relativ. Ideea de baz a acestei autonomii relative const n faptul c protocolul este capabil, n anumite mprejurri, de ini iativa n rela ia cu mediul de interpretare sau de execu ie a protocolului. Ca un contraexemplu, o resurs Delphi, neintegrat ntr-un sistem complet de alte elemente ale unei aplica ii Delphi, nu poate fi considerat sistem soft. Integrat, ns, poate fi considerat parte a unui sistem soft. 30 Protocolul opereaz ntr-un context informa ional dat. Nu prea avem motive s acceptm ca sistem soft o crea ie IS care nu opereaz ntr-un context informa ional specific. Chiar dac nu este ntotdeauna evident, acest context informa ional exist. De exemplu, un mediu vizual de realizare a sistemelor soft este, el nsui, un sistem soft care opereaz cu un context informa ional specific, abstractizat de conceptele i principiile de utilizare a acestor concepte pentru a modela vizual solu ia unei probleme date. Cititorul, mai mult sau mai pu in avizat, ntrezrete, probabil, faptul c no iunea de sistem soft are un con inut discutabil. Mai presus de orice discu ie, ns, se afl faptul c n IS denumirea generic a produselor finite este sistem soft. Actualmente, omenirea triete un moment de cotitur din punct de vedere al modului de procesare a informa iilor care o intereseaz. Acest moment de cotitur ar putea fi numit revolu ie informa ional. Dup ce o mare parte din istoria omului a fost dedicat cuceririi redutelor substan iale i energetice, a sosit timpul unor modificri importante n ceea ce privete valorificarea dimensiunii informa ionale a tuturor activit ilor omului.

Diversificarea pe orizontal i pe vertical a produc iei de sisteme soft nseamn modificarea permanent a ofertei de tehnologii informa ionale (TI), tot mai mult cerute de societatea informa ional n curs de cristalizare. Circuitul produc ie TI - utilizare TI - redefinire cerin e fa de TI produc ie TI are o dinamic a crei trstur principal pare a fi efectul de autoaprindere. Tvlugul informatizrii societ ii omeneti pare a fi n faza n care rostogolirea lui nu mai poate fi oprit fr a prejudicia grav progresul metodelor de investigare i complexificare a realit ilor substan iale i energetice, fr s mai vorbim de cele informa ionale. Nu peste mult timp, o mare parte din locuitorii planetei vor fi nevoi i s nve e meteugul utilizrii i producerii TI. Dup cum se poate observa i n alte domenii de activitate i n industria softului exist tendin a de a: -extinde permanent capabilit ile interactive i de procesare ale sistemelor soft, innd cont de cerin ele concrete ale utilizatorilor dar i formnd la utilizatori obinuin a de a nv a tehnologii informa ionale noi, destinate modificrii comportamentului; -crete sistematic calitatea sistemelor soft; -diminua permanent costurile de produc ie. Manifestarea efectiv a acestor trei tendin e este posibil numai printr-un efort permanent de mbunt ire a elementelor suport n procesul de realizare a sistemelor soft. Studiul critic al elementelor suport n procesul de realizare a sistemelor soft este de competen a disciplinei prezentat n literatura anglo-saxon sub denumirea Software engineering, care n limba romn s-ar traduce convenabil prin Ingineria softului. Dup ce am ncercat o scurt incursiune n lumea preocuprilor IS, voi prezenta, n continuare, o serie de probleme care (de la nceputurile erei informaticii sau mai recent) men in treaz interesul specialitilor n IS pentru regndirea permanent a paradigmelor. 1.3 Probleme cu care se confrunt specialitii n IS Familiariza i oarecum cu ncrctura semantic de baz a no iunilor discutate n paragrafele 1.1 i 1.2, n acest paragraf vom analiza unele dintre problemele care au jucat i joac un rol important n evolu ia IS. De men ionat faptul c i acesta este un subiect n care abordrile abund deoarece universul problemelor IS poate fi analizat din mai multe puncte de vedere iar n interiorul unui punct de vedere utiliznd formalizme diferite. De exemplu, problema elaborrii solu iei unui sistem soft poate fi discutat, la un nivel de formalizm socotit convenabil, n scopul dezvoltrii abilit ilor unui specialist n IS sau n vederea informrii exacte a managerilor cu privire la particularit ile i utilitatea unui astfel de demers. Specialistul n IS vrea s nve e ct mai multe detalii despre arta de a realiza sisteme soft de calitate. Managerul care se instruiete pe probleme de IS este interesat de cunoaterea invariani ilor unui astfel de demers pentru a decide n cunotin de cauz modul n care, cu minimum de resurse se pot ob ine maximum de rezultate (att pe termen scurt ct i, eventual, pe termen mediu sau lung) prin automatizarea fluxurilor informa ionale ale afacerii n conducerea creia este implicat. Pentru a clarifica unele probleme de limbaj care ar putea s apar n continuare, s precizm faptul c n literatura de specialitate anglo-saxon se consider c trei categorii de indivizi sunt foarte importan i pentru succesul sau eecul unui proiect de realizare a unui sistem soft. Aceste categorii sunt:

-utilizatorii direc i (end-users) ai sistemelor soft; -utilizatorii indirec i (clients) ai sistemelor soft; -specialitii n IS. Probleme datorate perspectivei utilizator direct Opernd la extreme, utilizatorul direct al unui sistem soft este sau un individ avnd afinit i cu lumea IS sau un individ a crui cultur informatic este structurat, modest, n jurul abilit ilor necesare pentru utilizarea sistemului soft. n primul caz este vorba de un utilizator a crui prere despre calit ile sistemului soft poate fi deosebit de activ i pertinent. Al doilea tip de utilizator este, n general, sensibil la confortul oferit de utilizarea sistemului soft. Ambele categorii de utilizatori, ntr-o form sau alta, se pot considera la originea revendicrii pernanente: sporirea interactivit ii sistemului soft cu utilizatorul direct, promovnd mijloace de comunicare ct mai ergonomice. n mod evident, interactivitatea sistem soft-utilizator direct n sensul de mai sus presupune proiectarea i realizarea efectiv a unor interfe e ergonomice. ntr-o interfa ergonomic, utilizatorul direct gsete func ionalitatea dorit de o manier care nu pune la ncercare nici n elegerea, nici rbdarea i nici sntatea acestuia. Practica a demonstrat i demonstreaz faptul c este o art s proiectezi interfe e inteligibile, este o sarcin mult mai complicat s realizezi interfe e care rspund operativ i dau dovad de maxim ngduin fa de capriciile utilizatorului direct; n sfrit, destul de preten ioas este i misiunea de a realiza interfe e care nu numai c nu duneaz facult ilor psihice ale utilizatorului direct, ba chiar, ncearc reconfortarea lor. Mul i factori care determin calitatea unui sistem soft (problem asupra creia vom reveni, pe larg, n acest capitol) i gsesc o form de manifestare i n modul n care se exprim o interfa n rela ia cu utilizatorul. De exemplu, robuste ea unui sistem soft, considerat un factor extern de calitate, msoar abilitatea unui sistem soft de a rezista la ini iative din partea utilizatorului direct (transmise prin intermediul interfe ei) care depesc cerin ele specificate ale sistemului soft. Probleme datorate perspectivei utilizator-indirect Utilizatorul indirect (care poate fi ntruchipat de orice consumator inteligent de servicii furnizate de un anumit sistem soft) dac se manifest constructiv este un partener cu care specialistul n IS trebuie s coopereze strns deoarece solu ia multora dintre problemele care pot s apar pe timpul realizrii unui sistem soft depinde de acesta. Utilizatorul indirect decide nceperea/nenceperea finan rii proiectului de realizare a unui sistem soft; tot el este i cel care, n urma analizelor periodice cu privire la evolu ia proiectului, poate decide abandonarea/continuarea proiectului. Absolut trivial este faptul c ntr-o economie de pia fr finan are nu se poate materializa nici o idee de proiect, orict de generoas i ambi ioas ar fi aceasta. Acesta este motivul pentru care managementul proiectului de realizare a unui sistem soft trebuie s trateze cu maximum de profesionalism rela ia cu utilizatorii indirec i-variabile importante n ecua ia finan rii unui proiect. Utilizatorul indirect i asum, n mod normal i rolul de furnizor de date cu privire la structura proceselor informa ionale modelate i, ca o prelungire fireasc, rolul de

furnizor de elemente cu privire la cerin ele fa de sistemul soft n curs de realizare. Dac utilizatorul indirect nu i asum aceste dou roluri de pe o pozi ie corect, specialistul n IS este n fa a unei probleme al crei enun are geometrie variabil: Utilizatorul indirect nu este capabil s descrie corect procesele informa ionale modelate; cineva din echipa de proiectare trebuie s fac acest lucru i, evident, nota de plat a proiectului se ncarc; Utilizatorul indirect indic cerin ele fa de sistemul soft derivate din pozi ia pe care el (utilizatorul indirect) o are n ierarhia utilizatorilor indirec i. Apare, n acest fel, o problem nou i important pentru specialitii n IS, anume distilarea i asamblarea viziunilor unilaterale ale utilizatorilor indirec i pentru a ob ine o perspectiv sistemic asupra proceselor modelate. Utilizatorul indirect are, statistic vorbind, toate calit ile unui om obinuit: poate face omisiuni, poate emite judec i inconsistente, poate avea probleme n comunicarea datelor i informa iilor pe care le de ine, etc. Aceast posibilitate ar trebui s sporeasc semnificativ ncordarea cu care specialitii n IS culeg de la utilizatorii direc i date i informa ii necesare evolu iei pozitive a proiectului. Oricare ar fi situa ia, specialitii n IS trebuie s acorde o aten ie deosebit utilizatorilor indirec i; prerea lor fa de calit ile unui sistem soft poate determina nmormntarea acestuia nainte de a se nate, sau asigurarea condi iilor pentru ca sistemul soft s aib un ciclu de via pozitiv. No iunea de ciclu de via bate la u, dar de semantica aflat n spatele ei (destul de polimorf) vom discuta mai multe n Capitolele 2 i 3.. Deocamdat, ciclul de via al unui sistem soft, conform unei metodologii date, descrie etapele prin care trece un proiect de la faza de enun al problemei pn la solu ia executabil pe calculator .a.m.d dac se pune problema dezvoltrii, ntre inerii, etc.

Probleme generate sau descoperite de specialitii n IS Nu este dect o confirmare a regulii faptul c IS este un univers ale crui probleme sunt inventate, inventariate i rezolvate datorit dorin ei specialitilor n IS de a optimiza procesul de realizare a sistemelor soft. Simbolic vorbind, func ia obiectiv care st la baza optimizrii are multe variabile i o expresie necunoscut. De aceea nu se poate vorbi serios despre o optimizare n sens matematic ci despre efortul permanent de a imagina procedee de stpnire a complexit ii problemelor care apar n timpul realizrii unui sistem soft. Cele mai dificile probleme care pot apare n timpul realizrii unui sistem soft sunt, totui, problemele care i au originea n laboratoarele IS sau se reflect n activitatea acestor laboratoare. Vom prezenta, n continuare, enun ul problemelor fundamentale pe care trebuie s le aib n vedere orice specialist n IS. Pentru nenumrate motive (dintre care, unele le vom prezenta n continuare) procesul de realizare a unui sistem soft trebuie sistematizat. Aceast nevoie de sistematizare acoper mai multe dimensiuni:concep ie, ealonarea n timp, reprezentarea solu iei, documentarea, conducerea proiectului, etc. Sistematizarea nseamn, n esen , introducerea de reguli de urmat pentru a asigura, teoretic, succesul unui proiect. Nevoia de sistematizare intr n conflict cu tendin a multor

specialiti n IS de a se exprima ignornd protocoalele, normele, regulile adoptate de colectivele din care fac parte. Pentru a men ine n echilibru pozitiv nevoia de sistematizare i tendin a unor specialiti n IS de a ajunge la solu ie dnd cu tifla sistematizrii, este nevoie de mult abilitate din partea celor care specific paradigme de modelare a softului (dac cititorul mi ngduie aceast exprimare). Istoria a re inut de-a lungul erei informaticii exemple de paradigme n care normarea i formalizmul au descurajat pe mul i amatori de sistematizare, exemple de paradigme care au solu ionat satisfctor doar o parte din probleme, lsnd la latitudinea specialitilor n IS rezolvarea altora, exemple de paradigme care mbin elegant formalizmul cu puterea de sugestie n rezolvarea unui numr ct mai mare de probleme, etc. Din pcate (sau poate din fericire) universul IS, la capitolul probleme posibile, este deschis. Este din ce n ce mai greu de inut eviden a tipurilor de sisteme soft cunoscute, pentru a valorifica creator experien a acumulat prin realizarea lor, specificnd MDS infailibile i atotcuprinztoare. Dei la ora actual au fost edificate MDS care impresioneaz puternic prin obiectivele propuse i mijloacele de atingere a acestor obiective, omul rmne n continuare singurul n msur s nsufle easc aceste MDS sau s le adauge capabilit i noi n situa ii problematice deosebite (A se vedea, de exemplu, OM,T i UML, dou MDS relativ recente, cu aspira ii interesante pentru orice gnditor care n elege lumea orientat pe obiecte). Prin sistematizarea procesului de realizare a sistemelor soft se urmrete crearea unor condi ii avantajoase pentu gestiunea complexit ii problemelor specifice unui proiect. Oferirea de suport pentru gestiunea complexit ii este benefic pentru diviziunea muncii (dac se lucreaz n echip) i calitatea solu iei. Exist o mare varietate de abordri care propun i elemente suport explicite pentru gestiunea complexit ii. Dintre aceste abordri s enumerm i noi cteva care au ca numitor comun modularizarea. Putem modulariza orientat pe proceduri, putem modulariza orientat pe date, putem modulariza orientat pe obiecte. Rezultatul trebuie s fie de fiecare dat acelai: Solu ia=o colec ie de module care coopereaz pentru rezolvarea unei probleme date. Prin sistematizarea procesului de realizare a sistemelor soft se pun bazele reutilizrii efortului de modelare, n anumite circumstan e. Astfel, aa dup cum vom vedea, ndeosebi n Capitolele 2 i 4, solu ia unei probleme poate fi elaborat pe mai multe nivele de abstractizare, fiecare nivel fiind dedicat descrierii unor propriet i specifice ale solu iei. Regulile de baz n organizarea unei solu ii pe nivele de abstractizare pare simpl: nivelul de abstractizare al unei solu ii scade odat cu creterea infuziei de informa ie static i dinamic n solu ie. Creterea infuziei de informa ie static i dinamic nseamn trecerea solu iei de la o arhitectur cu o anumit stabilitate structural la o arhitectur cu stabilitate structural diminuat. Este o legitate care poate fi combtut constructiv doar prin utilizarea unei scheme de rafinare a solu iei care s limiteze diminuarea stabilit ii structurale a nivelului de abstractizare. Teoretic vorbind, cu ct avem mai multe nivele de abstractizare, cu att mai mic este efortul de regndire a unui anumit nivel de abstractizare. Practic, ns trebuie gsit un compromis eficient ntre numrul de nivele de abstractizare propuse i efortul depus de specialiti n IS pentru ob inerea solu iei n acest context. Astfel stnd lucrurile, o solu ie ob inut, s spunem, pe trei nivele de abstractizare (conceptual, logic, opera ional, a se vedea Figura 1.2) are cea mai mic stabilitate la nivel opera ional. Dac apar modificri care afecteaz acest nivel (i ele sunt cele mai plauzibile), atunci solu ia este regndit, refcnd, n principal, nivelul opera ional. Aceasta nseamn c solu ia are o rezisten structurat la modificri i c specialitii n IS fac reutilizare de efort de modelare n ob inerea unei solu ii.

Comentariu la Figura 1.2 Cele trei nivele de abstractizare au o semantic apropiat perspectivei pe care o ofer teoria managementului asupra actului de conducere, analizat pe vertical. Comentariu la Figura 1.3 Schema din Figura 1.3 ilustreaz componentele managementului, structurat pe nivele; dei nu sunt vizibile, ntre aceste componente exist rela ii foarte interesante pentru cineva care proiecteaz sistemul informa ional al unei afaceri.
Nivel conceptual (Ce face sistemul soft)

Solu ia conceptual Nivel logic (Cine, cnd i unde execut prelucrrile)

Solu ia logic Nivel opera ional (Cum se efectueaz prelucrrile) Sistem soft opera ional

Figura 1.2 Exemplu de ciclu de abstractizare a solu iei unui sistem soft

Figura 1.3 Piramida managementului din perspectiv sistemic. Managementul de TOP, dac este specificat corect trebuie s aib cea mai mare stabilitate structural. Managementul TACTIC formuleaz politicile necesare pentru ndeplinirea obiectivelor managementului de TOP. Dac este necesar, stabilitatea structural a acestor politici poate fi schimbat. n sfrit, managementul OPERATIV face tot ceea ce este necesar pentru a opera ionaliza politicile stabilite de managementul TACTIC. Nivelul operativ al managementului este supus, cu prioritate, schimbrilor atunci cnd se pune problema adaptrii sistemului condus la condi ii de performan noi.

Prin sistematizarea procesului de realizare a sistemelor soft se urmrete creterea permanent a calit ii acestora. Este momentul s facem o scurt incursiune n semantica deosebit de complex a sintagmei calitatea sistemelor soft. Punctul de vedere pe care l prezentm reprezint o sintez a expunerii fcut pe aceast tem n [10]. Att n teorie ct i n practic se accept faptul c softul de calitate este rezultatul lurii n considera ie a o serie de factori interni i externi procesului de configurare a solu iei finale a unui sistem soft. n limbaj comun se vorbete despre necesitatea de a realiza sisteme soft fiabile, uor de folosit, structurate, etc. Astfel de epitete asociate unui sistem soft caracterizeaz dou tipuri de propriet i ale sistemelor soft:propriet i externe i propriet i interne. Calitatea sistemelor soft i propriet ile externe Dintre propriet ile externe care decid calitatea unui sistem soft, le considerm ca fiind foarte importante pe urmtoatele: -corectitudinea; -robuste ea; -extensibilitatea; -reutilizabilitatea; -compatibilitatea; -eficien a; -portabilitatea; -uurin a n folosire. Corectitudinea Este abilitatea unui sistem soft de a executa toate sarcinile convenite cu utilizatorii i beneficiarii n faza de specificare Corectitudinea este o proprietate de maxim prioritate a sistemelor soft. Un sistem soft care face altceva dect s-a stabilit de comun acord cu beneficiarii i utilizatorii lui este obligatoriu s fie corectat (dac efortul necesar pentru a face acest lucru este asumat de cei care au greit) sau abandonat pentru a relua efortul de a gsi o solu ie care s aib, printre altele i atributul corectitudinii. Dei se poate vorbi uor i mult despre corectitudine, este o prob de rezisten i de ndemnare profesional specificarea corect a sistemelor soft. Pentru teoreticienii IS corectitudinea, dincolo de acceptarea rutinei, este sinonim cu rigoarea n specificare i proiectare, ceea ce nu este agreat de specialitii n IS adep i ai utilizrii unor limbaje cu suport natural n specificare i proiectare. Robuste ea Este abilitatea unui sistem soft de a reac iona adecvat n condi ii anormale de utilizarea. Este evident faptul c robuste ea completeaz corectitudinea. n timp ce corectitudinea se refer la comportamentul unui sistem relativ la o anumit specificare corect, robuste ea apreciaz ce se ntmpl cu sistemul soft n situa ii care, n chiar procesul de specificare ar trebui identificate ca excep ii. Realizarea de sisteme soft robuste este o sarcin care ncepe n faza de specificare i se ntinde pn n faza de programare. Pe acest traseu specialitii n IS trebuie s nfrunte dou clase mari de execp ii: Excep iile externe sistemului soft; Excep iile interne sistemului soft.

Frontiera dintre aceste dou clase de excep ii trebuie privit cu mult circumspec ie deoarece, n realitate este oricnd posibil ca, poten ial, o excep ie extern s induc o excep ie intern i invers. De asemenea, s mai observm c n timp ce excep iile externe pot fi nfruntate descurajnd ini iativele nespecificate ale utilizatorului, problematica excep iilor interne este mult mai complicat. n cazul sistemelor care gestioneaz rela ia cu utilizatorul prin intermediul unei interfe e cu o semantic deosebit de complex, excep iile externe, nainte de a fi inhibate trebuie identificate. Iat, deci, nc o problem de care specialitii n IS se lovesc dac doresc s scoat pe pia sisteme soft care rmn pe picioare la apari ia unor excep ii. Se poate formula i un fel de principiu relativ la odiseea tratrii excep iilor ntr-un sistem soft: n timp ce interfa a unui sistem soft i sporete receptivitatea fa de curiozitatea i comoditatea utilizatorilor, efortul de tratare complex i corect a posibilelor excep ii crete astfel nct poate deveni o problem care nu poate fi rezolvat dect prin metoda aproxima iilor succesive. Este cazul sistemelor de operare, de exemplu, a cror robuste e este, adeseori, rezultatul unui proces de ajustare pe banii i pe rbdarea diferitelor categorii de utilizatori. Extensibilitatea Este abilitatea unui sistem soft de a se adapta uor la modificri n faza de specificare Problema extensibilit ii este o problem de situare pe scala complexit ii: programele mici sunt uor de modificat; sistemele soft din ce n ce mai mari devin tot mai dificil de adaptat la modificri. Rmnnd n sfera afirma iilor valabile, dar generale, putem aduga c dou principii sunt utile n realizarea de sisteme soft extensibile. Acest principii sunt: Simplitatea proiectrii Ideea de baz este c o arhitectur simpl este ntotdeauna mai uor de modificat dect o arhitectur complex. Inevitabil, ns, vine ntrebarea: cnd spunem c un sistem soft are o arhitectur simpl? Un rspuns complet i precis la aceast ntrebare nu ncape n paginile acestei cr i. Simplitatea este un deziderat urmrit de orice creator care se respect. Faptul c exist destule crea ii ale omului care uimesc prin dificultatea cu care i transmit mesajul (inep ii literare, subproduse cinematografice, discursuri politice sterile, etc.) dovedete caracterul imprevizibil al modului n care un creator ajunge s opereze cu avantajele simplit ii n munca sa. Nu se poate algoritmiza ob inerea simplit ii pentru c, n forma ei cea mai nalt de exprimare, este sinonim cu crea ia. O crea ie plsmuit cu talent va provoca ntotdeauna exclama ii de genul:Ce simplu era!, Foarte uor de n eles!, Nici c se putea mai bine!, Cum de nu mi-a trecut prin cap?!, etc. O crea ie plsmuit doar pentru a umple fizic unul din multele goluri care exist n via a oamenilor provoac exclama ii de tipul:Doamne, ce mbcseal!, Nu n eleg mai nimic!, Mai bine lips!, Aa ceva puteam i eu s fac!, etc. Nu este pierdere de vreme s urmrim simplitatea i n IS. Doar c, i aici, ob inerea ei cere timp, pentru a lefui solu ia unei probleme, astfel nct s putem ob ine un sistem soft care este, cel pu in: -lizibil; -corect modularizat; -eficient n timpul execu iei.

Sunt nenumrate motive, ns, pentru care n IS se sacrific simplitatea, asigurndu-se, de exemplu, corectitudinea i robuste ea. Enumerm cteva dintre aceste motive: necesitatea scurtrii termenelor de execu ie, modificarea paradigmelor de modelare, modificarea limbajelor de programare, modificarea sistemelor de operare, creterea puterii de calcul a sistemelor hard (frecven de lucru foarte mare+ dimensiuni, de vis altdat, ale memoriei RAM). Descentralizarea Dac extensibilitatea este dorit cu orice pre i poate c nu exist suficient timp pentru a ob ine un sistem soft cu arhitectur simpl, atunci mai avem un punct de sprijin n descentralizare: cu ct autonomia modulelor care compun sistemul soft este mai mare cu att mai mare este probabilitatea ca o schimbare simpl s afecteze un numr redus de module. Reutilizabilitatea Este abilitatea componentelor unui sistem soft de a putea fi utilizate la dezvoltarea mai multor aplica ii diferite. Necesitatea reutilizrii unor componente soft se ntemeiaz pe observa ia c, adeseori, sisteme soft diferite pot fi construite pe baza unor solu ii-ablon similare. Promovarea sistematic a reutilizrii influen eaz al i factori de apreciere a calit ii sistemelor soft, precum corectitudinea i fiabilitatea. Reutilizarea este un factor cardinal n multe paradigme de programare i modelare. Astfel, programatorii Windows pot utiliza n procesul de realizare a propriilor aplica ii, poten ialul MFC (Microsoft Foundation Class). De asemenea, mediile vizuale de programare (Delphi, Visual Basic, Visual C++, CBuilder, etc.) ofer exemple consistente de reutilizare. Compatibilitatea Este o msur a uurin ei cu care componentele unui sistem soft se combin cu alte componente pentru a forma aplica ii noi. Firete, compatibilitatea este important deoarece, n general, sistemele soft nu pot fi dezvoltate n vid; ele vor interac iona cu alte sisteme soft. Secretul compatibilit ii se afl n omogenitatea proiectrii i n acceptarea unor standarde de comunicare ntre programe. Aadar, pentru a realiza sisteme soft compatibile, efortul de proiectare trebuie s ia n calcul i cele dou cerin e formulate mai sus. Comunitatea IS nu se poate mndri cu impunerea unor standarde i principii de detaliu n acest sens. Exist fani Windows care promoveaz tehnologiile, trebuie s recunoatem remarcabile, ale Microsft-ului. Exist, ns, i fani Linux care promoveaz propriile lor idei i tehnologii n ceea ce privete caracteristicile mediilor de dezvoltare a sistemelor soft. Am dat dou exemple de medii de dezvoltare a softului. Mai sunt nenumrate altele al cror istoric nu este momentul s l facem; ra iunea lor de a fi este urmtoarea: Lumea IS i datoreaz remarcabila dinamic unui permanent efort de inovare teoretic i n plan aplicativ; Lumea IS, n marea ei varietate, are nevoie de puncte de convergen pentru a face posibil interoperabilitatea crescnd ntre sistemele soft. Este destul de dificil de fcut o predic ie relativ la dezvoltarea prghiilor de compatibilizare a sistemelor soft n viitor. Actualmente, lumea aplica iilor Internet se prefigureaz ca un cmp de desfurare a unor btlii importante pentru noua fa a

universului IS. Este nevoie de timp, rbdare i efort sus inut pentru a gsi noi formule de specificare a propriet ilor fundamentale ale sistemelor soft, printre care se afl i compatibilitatea. Eficien a (Performan a) Este abilitatea unui sistem soft de a minimiza cererile de resurse hard (timp UC, memorie RAM, memorie extern, etc.). Comunitatea IS are dou atitudini tipice fa de eficien . Exist softiti care fac o pasiune din optimizarea permanent a sistemelor la care lucreaz. Din minile unor astfel de specialiti ies adevrate bijuterii din punct de vedere al performan elor. Pre ul pltit mpingnd performan a dincolo de un anumit prag logic este, n principal, diminuarea portabilit ii softului respectiv. ntr-o lume care viseaz la compatibilizarea sistemelor soft este greu de crezut c portabilitatea poate fi sacrificat. Exist i softiti care gndesc astfel: S facem sistemul soft corect nainte de a fi eficient cu orice pre . Un astfel de slogan merge n aplica iile n care absen a performan ei nu este critic pentru func ionarea softului, mizndu-se pe un fapt absolut real n ultima vreme: Eficien a poate fi ob inut pe seama progreselor n materie de tehnologii hard. Ca de obieci, adevrul trebuie s fie undeva la mijloc, ceea ce nseamn c specialistul IS trebuie s stpneasc arta de a ob ine performan a cerut cu minimum de cheltuieli de resurse. Portabilitatea Este o msur a uurin ei cu care un sistem soft poate fi transferat pe diferite platforme hard i medii de operare. Dat fiind marea diversitate de platforme hard i medii de operare, problema este real i dificil de rezolvat. Esen a acestei probleme const n faptul c orice sistem soft, ajuns n faza executabil, pe un calculator real, trebuie s se n eleag cu calculatorul respectiv. Aceasta nseamn c un cod execuatbil are o anumit structur i instruc iunile pe care le con ine sunt recunoscute de procesorul mainii gazd. Structura codului executabil este important pentru sistemul de operare, care supervizeaz ncrcarea codului executabil n memorie i execu ia acestuia, pas cu pas. Schema clasic n care apare problema portabilit ii este prezentat n Figura 1.4. Orice dificultate n portarea unui sistem soft de pe o platform pe alta este surmontabil dac : se fac modificrile necesare n codul surs(uneori aceste modificri pot fi dramatice); Exist compilatorul care tie s genereze cod executabil pentru platforma int (dac nu exist, trebuie cumprat, ceea ce nseamn c portabilitatea poate s coste). Orice dificultate n portarea unui sistem soft de pe o platform pe alta este surmontabil dac : se fac modificrile necesare n codul surs(uneori aceste modificri pot fi dramatice); Exist compilatorul care tie s genereze cod executabil pentru platforma int (dac nu exist, trebuie cumprat, ceea ce nseamn c portabilitatea poate s coste).

Cod surs/care poart amprenta mediului de execu ie i a mainii gazd scontate

Compilator/care poart amprenta mediului de execu ie int i a mainii gazd scontate

Cod executabil/dedicat perechii (mediu de execu ie, main gazd) recunoscut de compilator.

Figura 1.4 Dependen a de platform i efectele asupra portabilit ii n varianta clasic Evident, ar fi mult mai bine dac aceste dou probleme nu ar exista. Din pcate probelmele exist i specialitii n IS trebuie s ia n calcul la specificare i aspecte care afecteaz portabilitatea sistemului soft. O situa ie aproape diametral opus celei prezentate n Figura 1.5 o reprezint solu ia Java pentru asigurarea portabilit ii aplica iilor. De remarcat faptul c situa ia descris n Figura 1.5 este posibil n condi iile n care toat comunitatea recunote o anumit versiune de compilator Java. Trecerea de la o versiune la alta se face respectnd regulile de portare potrivit crora documentul n eles de o versiune oarecare a unui sistem soft este totdeauna n eles de o versiune mai nalt, nu i invers.
Interpreter Java (Pentium) Bytecode Java (Independent de platform)

Cod Java

Compilator Java

Interpreter Java (Power PC)

Interpreter Java (SPARC)

Figura 1.5 Solu ia Java la problema portabilit ilor sistemelor soft.

Aceasta este, pn la data scrierii acestei cr i singura modalitate de a dezvolta sisteme ct de ct portabile. Se pltete, ca de fiecare dat, tribut pentru acest ctig, la capitolul performan n timpul execu iei. Dar, ce mai conteaz, omenirea viseaz cu ochii deschii, ceea ce nseamn c ntr-o bun zi vom ajunge s dm alt sens i portabilit ii. Uurin a n folosire Se refer la modul n care oameni cu diferite nivele de instruire pot nv a s foloseasc sistemul soft pentru rezolvarea unor probleme reale. Se refer, de asemenea, la uurin a instalrii i operrii sistemului soft. nchei prezentarea propriet ilor externe ale sistemelor soft cu precizarea c problematica propriet ilor interne (structurare, modularizare, obiect orientare, etc.) reprezint un capitol la a crui scriere nc se lucreaz, neexistnd un consens deplin al specialitilor asupra modului de articulare a acestora ntr-o explica ie stabil structural. Despre unele dintre aceste subiecte vom avea un cuvnt de spus n Capitolul 4.

Capitolul 2 Ce este o metodologie de dezvoltare a softului?

De mult (nu putem spune exact cnd deoarece nu tim nici cnd a nceput povestea omului) s-a nscut ideea de paradigm . Poate, la nceput paradigma avea n elesul pe care ni-l dezvluie Dic ionarul explicativ al limbii romne. n zilele noastre, cnd natura de-abia se mai regsete printre crea iile omului, nu putem supravie ui dect inventnd, devornd i iar inventnd paradigme din ce n ce mai sofisticate. Cnd spun nu putem supravie ui m refer la to i cei care, realmente sau doar nchipuindu-i, cultiv o veche ndeletnicire chinezeasc (autoreflexia) pentru a descoperi mcar o parte din taina cunoaterii att de bine ascuns n proiectul Homo Sapiens.

2.1 De ce avem nevoie de MDS? n Capitolul 1 am prezentat o serie de considera ii, a zice cu preten ii de stabilitate structural, referitoare la universul IS. Este, ns, prea devreme pentru a-mi nchipui c ucenicii ntr-ale producerii softului sau creatorii de soft dup re ete proprii au devenit adep i convini ai promovrii re etelor IS. n acest paragraf vom inventaria o serie de probleme concrete de care, vrnd-nevrnd, specialistul n IS (afiliat sau nu la o metodologie) se lovete. Procednd astfel legitimm o stare de lucruri ntlnit i n alte domenii ale cunoaterii. Structura discursului n IS este determinat att de cerin e epistemologice specifice ct i de nevoia de organizare a diferitelor forme de manifestare a existentului n procesul de realizare a sistemelor soft. Evident, o parte din cerin ele epistemologice specifice le-am surprins n Capitolul 1. n acest paragraf vom ncerca s eviden iem o parte dintre formele de manifestare a existentului n procesul de realizare a sistemelor soft. Dei ne-ar place s semene cu o problem de matematic, este corect s spunem c nu este chiar aa. n matematic, o problem poate suna cam n genul: Dat triunghiul oarecare ABC, s se afle locul geometric al punctelor M, interioare triunghiului, pentru care SABM=SACM. Nu este cazul s intru prea adnc n considera ii metodice pe marginea rezolvrii acestei probleme. i totui, cineva care vrea s rezolve aceast problem are nevoie de trei puncte de sprijin: 10 Posibilitatea de a ncadra problema ntr-o clas tipologic. Dac aceast clas nu exist, gloria rezolvitorului sporete, specificnd clasa respectiv. n cazul nostru, fiind o problem de loc geometric, rigoarea ne cere s identificm locul geometric, dup care s facem verificarea c fiecare punct al locului geometric satisface proprietatea care a stat la baza identificrii locului. 20 Odat stabilit clasa tipologic, trebuie s avem control asupra semanticii no iunilor care intervim n enun ul problemei. n cazul nostru ne confruntm cu no iuni precum: loc geometric, interiorul unui triunghi, aria unui triunghi i, de ce nu, triunghi. 30 Pentru a gsi rezolvarea ne trebuie abilitatea de a valorifica avantajele prezentate la punctele 10 i 20 n vederea ob inerii solu iei problemei. n general, aceast abilitate o au persoanele care sunt capabile de inferen . Abilitatea de a comite inferen e autentice o au oamenii inteligen i. Evident, cine rezolv o problem faceun fel de descoperire, deci este un fel de creator. Folosesc sintagma un fel de deoarece face descoperire autentic cel care rezolv primul o problem sau propune i rezolv o problem nou. n cazul problemei noastre, pentru a ne face mai bine n elei ne-ar prinde bine reprezentarea din Figura 2.1.

Figura 2.1. Din enun ul problemei, avem, n mod evident: -ABC oarecare; -M interiorului ABC; SABM=SACM . Tot din enun ul problemei face parte i prelungirea lui AM care intersecteaz BC n O i ca urmare avem posibilitatea imediat de a proiecta B i C pe prelungirea lui AM n B', respectiv C'. Acum este momentul inferen ei specifice problemei: SAMB = SAMC =
AM BB 2 '

AM CC 2

'

SAMB=SAMC BB=CC BBOCCO BO=CO Mmedianei din A a ABC, etc. n IS situa ia este pu in modificat. Trecerea de la enun la solu ie, n cazul problemelor de complexitate mijlocie sau mare (n care, de regul, se cere modelarea comportamentului unui anumit proces informa ional) este mult modificat. Astfel, n forma ini ial, enun ul problemei poate sesiza nite caren e ntr-o activitate care pot fi eliminate prin utilizarea calculatoarelor sau poate intui nite avantaje ntr-o activitate dac se apeleaz la suportul calculatoarelor. n ambele cazuri, pentru a ob ine enun ul complet al problemei se trece la analiza informa ional a problemei. Scopul acestei activit i este ob inerea unui enun complet al problemei care cuprinde cerin ele fa de sistemul soft sub forma unei solu ii cu nivel nalt de abstractizare. Activitatea de analiz informa ional este dificil i este primejdios ca, din diferite motive, s nu incluzi printre cerin e un anumit aspect informa ional. Dac s-a pus punct analizei informa ionale, trebuie s se treac la elaborarea solu iei tehnice (un fel de documenta ie constructiv a sistemului soft). Dei elaborarea solu iei tehnice nseamn descrierea pn la detaliu a componentelor sistemului soft i a legturilor

dintre acestea, ceea ce nseamn infuzie treptat de elemente concrete n solu ie, n paralel se desfoar i activit i cu pronun at caracter de abstractizare (pentru a elimina redundan ele, pentru a optimiza prelucrrile, pentru a optimiza legturile dintre date, pentru a spori rezisten a sistemului la modificri, etc.). De foarte multe ori se poate spune c obiectul analizei informa ionale ca i obiectul activit ii de ob inere a solu iei tehnice au afinit i cu nisipurile mictoare. Ce-i de fcut? Trebuie mult rbdare i abilitate pentru a sesiza invarian ii procesului ceea ce ar permite nceperea efortului de modelare. n situa ia n care calvarul ob inerii solu iei tehnice a fost depit ncepe activitatea de transpunere a solu iei tehnice n acord cu exigen ele de sintaz, semantic i pragmatic specifice unui limbaj de programare. N-a zice c nu exist nisipuri mictoare i n aceast ncercare! n mod cert, numitorul comun al problemelor de matematic cu problemele de informatic este complexitatea. n cazul matematicii predomin complexitatea structural; n cazul informaticii, de cele mai multe ori predomin complexitatea spa ial. Dac la aceste elemente se adaug altele, precum: necesitatea reprezentrii solu iei pentru a fi n eleas de diferite categorii de utilizatori, necesitatea de a partaja anumite tipuri de resurse n procesul de elaborare a solu iei unui sistem soft, necesitatea de a armoniza efortul de dezvoltare n cazul n care se lucreaz n echip, etc. ne facem o imagine mai precis asupra amnuntelor care alctuiesc specificul unei probleme n IS. Pentru a nfrunta toate aceste probleme i multe altele, comunitatea specialitilor n IS a ncercat nc din epoca de nceput a erei informaticii s ngrdeasc liberul arbitru n procesul de dezvoltare a softului, lsnd, totui, loc de manifestare spiritului creator, prin ini iative de genul: -studiul teoretic al propriet ilor algoritmilor: formalizare a reprezentrilor; clasificarea algoritmilor; -studiul teoretic al unor metode generale de elaborare a algoritmilor (Backtracking, Greedy, Divide et Impera, Programarea dinamic); -elaborarea unor metode de programare (programarea structurat, programarea obiectorientat); -elaborarea unor metode de analiz a sistemelor informa ionale (procedee de investigare, mod de reprezenatare, concepte utilizate, etc.); -elaborarea unor metode de elaborare a solu iei tehnice (Top-down, HIPO, WarnierrOrr, etc.); -dezvoltarea unor elemente suport pentru specialitii n IS (sisteme de documentare, generatoare de programe, medii de dezvoltare a solu iei cu ajutorul calculatorului, etc.); -specificarea unor procedee de cuantificare a muncii depuse de specialitii IS pentru realizarea sistemelor soft; -elaborarea unor metode de planificare a efortului de dezvoltare a sistemelor soft.

Acumulrile n direc iile semnalate mai sus sunt impresionante; evolu ia abordrilor n IS, att teoretice ct i practice, seamn, metaforic vorbind, cu evolu ia popula iilor n sistemele genetice; clauzit de legit i, aparent stochastice, comunitatea specialitilor n IS produce genera ii succesive de elemente suport n dezvolatrea softului, le evalueaz, n practic, re ine ceea ce este valoros n ele i promoveaz ca parte component n genera iile urmtoare. De la o perspectiv fragmentat sau incomplet asupra procesului de dezvoltare a softului s-a ajuns n ultimii ani la elaborarea unor metodologii unitare de dezvoltare a softului, crea ii ale specialitilor n IS puse n slujba specialitilor n IS, cea mai mare parte din via a unui sistem soft. 2.2. ncercare de caracterizare a unei metodologii generice de dezvoltare a softului n Capitolul 1, paragraful 1.1 am prezentat o list de activit i specifice realizrii sistemelor soft. Aceste activit i sunt: -abstractizarea solu iei unui sistem soft (ASS); -desfurarea n timp a (=organizarea) procesului de abstractizare a solu iei unui sistem soft (OPA); -reprezentarea i documentarea evolu iei unui sistem soft (RDS); -optimizarea managementului procesului de realizare a unui sistem soft (OMP). Putem s definim o metodologie generic de dezvoltare a softului astfel: Un set finit de concepte, principii, norme, conven ii i reguli de opera ionalizare a acestora, pentru a da rspunsuri satisfctoare problemelor care apar n activit ile de tip AAS, OPA, RDS, OMP. S ncercm, n continuare, o serie de precizri relativ la semantica acestei defini ii. (Despre pragmatica acestei defini ii, nc nu putem spune mare lucru. Dac am fi vorbit despre o metodologie anume, alta era situa ia n ceea ce privete pragmatica.) Orice metodologie care urmrete priza la public trebuie s fac fa contradic iilor, inerente pentru semantica binomului MDS-specialist n IS. Una dintre contradic ii se refer la dorin a de a oferi un set relativ restrns de concepte, principii i reguli de utilizare a acestora n opozi ie cu aspira ia legitim a oricrui autor de MDS de a oferi sintax care s permit descrierea unei semantici, ct mai bogat posibil. Alt contradic ie se refer la nclina ia spre formalizm a spiritelor riguroase n opozi ie cu nclina ia spre intuitiv a altora. Nu n ultimul rnd (pentru c mai sunt i alte exemple) semnalez contradic ia dintre necesitatea de a standardiza mare parte a procesului de dezvoltare a sistemelor soft i nevoia de exprimare liber resim it de unii specialiti. n alt plan ne ntlnim cu contradic ia dintre nevoia de a crete productivitatea muncii i necesitatea de a realiza sisteme soft de calitate. Cei care specific MDS se strduiesc s men in echilibrul ntre aceste contradic ii prin diferite mijloace.

De exemplu, referitor la prima contradic ie, metodologia UML ofer o semantic foarte bogat cu ajutorul unui set bine ales de concepte i principii, oferind i cteva mecanisme de extensie cu ajutorul crora semantica metodologiei poate fi mbog it. n ceea ce privete capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip ASS, suntem datori cu o serie de precizri importante. Pentru o MDS recomandrile pe care aceasta le face pentru a transforma enun ul unei probleme de informatic n solu ie executabil pe un calculator real, practic definesc nsi substan a metodologiei. Aceste recomandri desemneaz, conform literaturii de specialitate, ciclul de abstractizare al unei MDS. Pentru un specialist n IS prima ntrebare pe care i-o pune n fa a unei probleme noi este destul de lung. Cum s derivez din datele problemei o solu ie, respectnd termenele de execu ie, fr s dezamgesc utilizatorul direct, ntmpinnd exigen ele curente i de perspectiv ale utilizatorului indirect i, chiar dac pare un pic utopie, fr s m stresez peste msur?. Fr ndoial, o astfel de ntrebare poate avea o serie de conota ii etice, filozofice, etc. dar nu acestea l preocup pe specialistul n IS. Eviden iind doar ingredientele esen iale ale unei probleme de IS, avem: -Date -Prelucrri -Interfe e Toate aceste ingrediente exist n domeniul problemei n format utilizator. n domeniul problemei, pentru descrierea solu iei se folosesc concepte pe care le n eleg, probabil, oricare dintre participan ii la un proiect, dar, n orice caz, ar trebui s le n eleag participan ii din sfera utilizatorilor i clien ilor.La cellalt capt al balan ei se afl domeniul solu iei n care se vehiculeaz concepte pe care le n elesc specialitii n IS. n format utilizator datele sunt organizate supralicitnd redundan a, prelucrrile, fiind aplicate unor date n care mustete redundan a, nu sunt automat cea mai fericit alegere. Tot att de delicat este i problema organizrii interfe elor deoarece n elaborarea acestora trebuie gestionat optim contradic ia dintre dorin a de a oferi utilizatorului confort i pornirea natural a specialistului n IS de a ra ionaliza interfa a cu utilizatorul. Acestea sunt o parte din motivele pentru care o MDS trebuie s ofere suport pentru elaborarea treptat (pe mai multe nivele de abstractizare) a solu iei pentru probleme de genul: -organizarea optim a datelor utilizate de un sistem soft; -organizarea optim a prelucrrilor specifice unui sistem soft; -organizarea pe principii ergonomice i de eficien a interfe elor unui sistem soft. Suportul oferit pentru rezolvarea problemelor semnalate mai sus depinde de metodologie. Rmnnd la ideea de metodologie generic, ar trebui s spunem c acest suport poate reprezenta un set de concepte, principii i reguli de opera ionalizare a acestora cu ajutorul crora se reprezint propriet ile de un anumit tip ale procesului n curs de modelare.

De exemplu, propriet ile informa ionale ale procesului modelat, odat ce au fost identificate, caracterizate i clasificate ne pot da o descriere a aspectelor statice ale procesului; n acest scop metodologiile ofer modele de organizare a datelor, eventual pe mai multe nivele de abstractizare. Propriet ile comportamentale ale procesului pot fi descrise utiliznd modele capabile s surprind diferite nuan e ale dinamicii unui sistem. Pare simplu, dar nu este aa. Pentru a ob ine o reprezentare ct mai exact a propriet ilor informa ionale i comportamentale ale unui proces, trebuie s elaborm: -modele care reprezint statica unui sistem; -modele care reprezint dinamica unui sistem; -modele care reprezint fluxurile informa ionale ntr-un sistem .a.m.d. Altfel spus, sistemul modelat este privit din mai multe perspective, fiecare perspectiv permi nd descrierea unui anumit tip de propriet i; laolalt, putem spune, fortnd pu in lucrurile, perspectivele ne ajut s ob inem o imagine holografic asupra sistemului modelat. Pn unde merge acurate ea acestei imagini?! Iat o ntrebare cu mai mult de dou tiuri pentru cei care dezvolt softuri dar mai ales pentru cei care specific noi MDS. n ceea ce privete capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip OPA. Oferta MDS privind rezolvarea problemelor de tip OPA este desemnat n literatura de specialitate prin sintagma ciclul de via al sistemelor soft. Ciclul de via al sistemelor soft este, alturi de ciclul de abstractizare, o caracteristic fundamental a MDS. Este evident faptul c, la detaliu, fiecare MDS are propria propunere de ciclu de via . Fcnd abstrac ie de metodologie, o prim perspectiv asupra semanticii no iunii de ciclu de via o ob inem n Figura 2.2. Diagrama din Figura 2.2. surprinde elementele esen iale pe baza crora ncepe s aib sens no iunea de ciclu de via . Adevrul este c, pentru sisteme soft de complexitate mare sau medie, ciclul de via al unei MDS trebuie s propun reguli de etapizare/organizare a efortului de realizare a unui sistem soft reunite sub denumirea Dezvoltare. Tot din ciclul de via face parte i utilzarea sistemului soft, de la care putem avea feed-back-uri care pot genera modificri. Pentru a ob ine date noi asupra semnifica iei no iunii de ciclu de via prezentm diagrama din Figura 2.3.
Analiza Proiectarea Implementarea Testarea

Etape de dezvoltare

Figura 2.3. Con inutul generic al etapei de dezvoltare a unui sistem soft

Problem

Dezvoltare

Utilizare

Modificare

Abandonare soft

Figura 2.2 Ciclul de via al unui sistem soft (dintr-o perspectiv rudimentar) Avnd ca pretext diagrama prezentat n Figura 2.3., pot prezenta comentariile de mai jos. Analiza Este etapa n care se constat c este necesar un sistem soft i se iau decizii n consecin . Fie c se constat existen a unei pie e pentru un produs de uz general, fie c o anumit organiza ie are nevoie de un soft specializat, n mare msur aceast prim etap presupune mai degrab luarea unor decizii de management i marketing dect abordarea unor probleme legate de studiul algoritmilor, de exemplu. Dup luarea deciziei de dezvoltare a sistemului soft ncepe analiza propriu-zis, al crei scop principal este identificarea necesit ilor utilizatorului poten ial al sistemului soft. De exemplu, n cazul unui produs de uz general, care urmeaz a fi vndut pe o pia concuren ial, trebuie stabilit un public int. Dac se construiete un sistem soft de gestiune a stocurilor ce urmeaz a fi folosit n departamentul de aprovizionare al unei firme constructoare de maini, atunci trebuiesc identificate necesit ile i ateptrile celor care lucreaz n cadrul acestui departament. Unul dintre rezultatele formale ale etapei de analiz l reprezint un set de cerin e pe care noul sistem soft ar trebui s le satisfac. Acestea trebuiesc formulate din punctul de vedere al utilizatorului (direct sau indirect), sau n limbajul de specialitate al IS. Dup ce au fost identificate cerin ele, acestea sunt transformate n specifica ii tehnice. Ca un exemplu, cerin a ca accesul la datele sistemului s fie permis doar persoanelor autorizate se poate transforma n specifica ia c sistemul nu trebuie s rspund dect dup introducerea unei parole de exact unsprezece caractere, confirmat de sistem. Firete, se pot pune ntrebrile:

Care sunt regulile care guverneaz procesul de identificare i reprezentare a cerin elor fa de sistemul soft? i Care sunt regulile care guverneaz domeniul de elaborare i reprezentare a specifica iilor tehnice?. Rspunsul este simplu: metodologia ofer suport de tip ASS i suport de tip RDS care se folosete n aceast etap a ciclului de via ct mai eficient cu putin . Proiectarea Este etapa n care solu ia sistemului soft este specificat n detaliu. n termeni generali vorbind, sistemul soft imaginat n etapa de analiz este descompus, progresiv, n componente mai uor de modelat, numite, generic, module. Implementarea sistemelor complexe devine posibil tocmai prin aceast descompunere modular. Astfel, mul imea detaliilor tehnice care trebuie luat n considerare ar fi imposibil de stpnit. Proiectarea modular creeaz, totodat condi ii pentru lucrul n echip i vine n ntmpinarea efortului de ntre inere, dac acesta este reclamat. Una dintre concluziile greu de combtut ale genera iilor de MDS poate fi formulat astfel: O structur modular, chibzuit proiectat este benefic att pentru implementarea sistemului ct i pentru modificarea sa ulterioar. Probabil, acesta este unul dintre principalele motive pentru care modelarea orientat spre obiecte ctig tot mai mult teren. n faza de proiectare, ca i n cea de analiz suportul de tip ASS i RDS este esen ial pentru a ob ine o solu ie tehnic de calitate. Implementarea Este etapa n care are loc scrierea efectiv a programelor, crearea fiierelor i, n consecin , dezvoltarea bazei de date a sistemului soft astfel ob inut. Testarea Este etapa strns legat de etapa anterioar deoarece, n mod normal, fiecare modul al sistemului este testat n timpul implementrii. ntr-un sistem bine proiectat (ceea ce ar face trimitere direct la o serie de posibili factori interni ai calit ii precum: decompozabilitatea modular, compozabilitatea modular, n elegerea modular, continuitatea modular i protec ia modular, conform i celor specificate n [3]) fiecare modul poate fi testat n mod independent, utiliznd versiuni simplificate ale celorlalte module pentru a simula interac iunea modulului int al testrii cu restul sistemului. Evident, pe msur ce diferite module sunt finalizate i combinate, testarea individual face loc treptat testrii generale a ntregului sistem. Practica dovedete c testarea i complementara acestei activit i, care este depanarea, sunt, ndeosebi n cazul sistemelor mari activit i greu de finalizat. Sistemele de mari dimensiuni pot con ine foarte multe erori chiar i dup efectuarea celor mai complexe teste. Multe erori pot rmne neobservate pe toat durata vie ii sistemului soft. Punerea la punct a unor strategii de eliminare a acestor erori este un obiectiv major al IS. Practica ne arat c n aceast direc ie mai sunt nc multe probleme de rezolvat.

Mult vreme MDS s-au bazat pe secven ialitatea propus n Figura 2.3., care sugereaz c trecerea dintr-o etap nou este posibil numai dup trimiterea lucrului n etapa precedent. A rezultat astfel un proces de dezvoltare cunoscut sub numele modelul cascad (waterfall model). Acest nume subliniaz faptul c procesul de dezvoltare poate decurge ntr-o singur direc ie. Studiile de specialitate arat c abordarea propus de modelul cascad este ntr-o contradic ie flagrant cu nevoia de a tatona profunzimile solu iei unei probleme (prin ncercri), resim it de spiritul creativ al rezolvitorului. n timp ce modelul cascad schi eaz un mediu de rezolvare a problemei riguros structurat, rezolvarea creativ se desfoar ntr-un mediu n care structurarea temporar poate fi abandonat n favoarea sugestiilor unor strfulgerri de intui ie. n ultimii ani, preocuprile IS ncearc s reflecte aceast contradic ie, beneficiind i de suportul oferit de instrumentele ingineriei soft asistate de calculator (Computer Aided Software Engineering CASE). Utilizarea acestor instrumente CASE faciliteaz parcurgerea etapelor de analiz, proiectare i implementare, ntr-o form sau alta prezente n orice MDS. n aceste condi ii este mai uor s se revin, n caz de eroare, sau chiar s se planifice o dezvoltare n spiral a solu iei sistemului soft (a se vedea paradigma RAD Rapid Application Development asupra creia vom reveni n Capitolul 3). n ceea ce privete capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip RDS, putem, de asemenea, s facem o serie de considera ii cu caracter general. Pe tot parcursul elaborrii solu iei unei probleme, aceasta trebuie documentat i reprezentat. Solu ia trebuie documentat deoarece exist mai multe categorii de persoane interesate n utilizarea acestei documenta ii (operatorii sistemului soft, cei care distribuie i instaleaz sistemul soft, programatorii care se ocup de ntre inerea sistemului soft, partenerii proiectului de realizare a sistemului soft, etc.). Documenta ia de utilizare poate fi realizat sub forma unor ghiduri de utilizare tiprite sau poate fi ncorporat n structura sistemului soft sub form de help interactiv. Spre binele autorilor sistemelor soft sau spre binele celor care ar trebui s modifice sistemul soft este bine ca nsui codul surs al sistemului soft s fie generos documentat. Deoarece, de calitatea documenta iei depinde n mare msur i priza sistemului soft la segmentul de pia cruia i se adreseaz, marile firme productoare de soft au transformat documentarea unui sistem soft ntr-o activitate supus n mare msur standardelor, automatizrii, legilor pie ei. Se cunosc exemplele remarcabile oferite n aceast privin de firme precum Microsoft sau Borland. Solu ia trebuie reprezentat n fiecare etap a ciclului de via deoarece: -permite schimbul de informa ii de natur tehnic ntre partenerii de proiect; -servete ca surs de documentare strict necesar celor care vor s aduc modificri sau dezvoltri acestei solu ii.

Att pentru documentarea ct i pentru reprezentarea solu iei se folosesc limbaje sau sisteme adecvate. Astfel, pentru documentare se folosete, n esen , limbajul natural, manifestndu-se o grij deosebit pentru rigoarea, claritatea, sugestivitatea i uurin a n utilizare a diferitelor tipuri sau sisteme de documentare. Programatorii, ndeosebi, sunt deja obinui i cu ncorporarea n mediile de programare sau n func ionalitatea diferitelor sisteme soft a unor help-uri interactive de mare complexitate sau a tutorialelor care asist nv area operrii sistemelor soft. Ultima gselni n materie de documentare a sistemelor soft o reprezint capabilit ile de tip wizards care scutesc utilizatorii de grija de a memora anumite protocoale de utilizare a sistemelor soft, lsndu-le ns ntotdeauna libertatea de a gndi care este cea mai bun alegere ntr-un anumit moment al utilizrii softului n cauz. n ceea ce privete reprezentarea solu iei, aducem la cunotin a cititorului faptul c lucrurile sunt mai pu in aezate dect n cazul documentrii. Limbajele alese pentru reprezentarea solu iei unui sistem soft pot fi: -tributare cerin ei de a fi intuitive, caz n care textul este combinat cu grafica conform unor reguli specificate riguros din punct de vedere sintactic (a se vedea nota ia utilizat n UML!); -tributare excesului de formalizm, indispensabil, spun teoreticienii pentru a asigura un spor de corectitudine n specificare, analiz, proiectare. Formalizmul excesiv este cerut i de, nc ipotetica, nzuin a IS de a implica sisteme soft specializate n generarea automat a codului executabil pornind de la solu ia tehnic (a se vedea Z, Z++, VDM, VDM++, sisteme formale de reprezentare a solu iei unui sistem soft care au reuit cteva strpungeri experimentale n lumea practic a IS i att deocamdat). Referitor la nota ie (cum se mai numete limbajul de reprezentare a solu iei) s precizm c aceasta n manualele de prezentare a MDS este strns dependent de semantica metodologiei, adic limbajul de reprezentare a solu iei respir acelai aer cu limbajul de abstractizare a solu iei. n ceea ce privete capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip OMP Din cele expuse pn n acest punct al lucrrii s-a n eles, presupun, faptul c lucrul n cadrul unui proiect de dezvoltare a unui sistem soft ridic probleme deosebite din punctul de vedere al managementului. Deja, practica lucrului n cadrul proiectelor de realizare a unor sisteme soft serioase a confirmat valabilitatea afirma iei potrivit creia: Un management slab poate compromite uor ansele de reuit ale unei echipe de proiectare redutabil profesional; un management bun poate gestiona eventualele probleme datorate nivelului profesional necorespunztor al unora dintre membrii echipei de proiectare. Lumea n care trim este, fr s exagerm deloc, opera diferitelor tipuri de management. Specialiti sau nu n probleme de management, este bine s tim c exist discipline care studiaz problemele fundamentale ale managementului, dar, complexitatea activit ilor imaginate de om depind de mult capabilit ile explicative i opera ionale ale unui tratat de bazele managementului, asistm la apari ia unor variet i noi de management cu obinuin a cu care la un anumit timp dup apusul soarelui ne vine din ce n ce mai greu s rezistm tenta iei de a ne culca. Printre aceste variet i de management se afl i managementul proiectelor de realizare a sistemelor soft (MPRSS). Multe dintre principiile fundamentale ale teoriei managementului opereaz i n cadrul MPRSS. Mai mult, putem afirma c, cel pu in n cazul

etapei de analiz din ciclul de via al unui sistem soft cunotin ele de management sunt de mare utilitate (dac sistemul soft este realizat la cererea conducerii unei organiza ii cu sau fr profit). Multe din ntrebrile care se pun n etapa de analiz (ce obiective are de ndeplinit sistemul soft?, care sunt mijloacele de ndeplinire a acestor obiective?, cum i mapeaz sistemul soft func iile pe domeniul activit ilor deservite?, etc.) primesc rspunsuri mult mai clare dac analistul are i cunotin e de management. Spernd c v-am convins, oarecum, de utilizarea unui management adecvat al procesului de dezvoltare a unui sistem soft, s anticipm c n aten ia MPRSS se afl trei tipuri fundamentale de activit i: -gestiunea resurselor angajate n realizarea sistemului soft; -asigurarea calit ii sistemului soft; -gestiunea riscurilor asociate procesului de realizare a sistemului soft. Toate aceste trei tipuri de activit i se desfoar dup o planificare riguroas care presupune, n esen stabilirea cadrului optim din punct de vedere organizatoric i logistic care permite valorificarea suportului oferit de MDS pentru rezolvarea problemelor de tip ASS, OPA, RDS. Nu ne va surprinde, aadar, s constatm c specialitii care depun eforturi pentru dezvoltarea suportului metodologic de tip OMP propun o serie de modele calitative i cantitative cu ajutorul crora se ncearc msurarea sau evaluarea rezultatelor activit ilor mai sus precizate. Date fiind particularit ile acestor activit i n cazul proiectelor de realizare a unor sisteme soft, este de ateptat ca multe direc ii de ac iune ale managementului s se supun unor legit i specifice. Orice patron de firm soft va scpa de multe probleme n ziua n care din laboratorul de cercetare va iei pe pia o metodologie care: articuleaz att de bine contradic iile, certitudinile i incertitudinile din munca unui specialist n IS, nct toate merg ca ntr-o linie de fabrica ie a unor echipamente necesare pentru dotarea unor capsule spa iale. Fericire sau ghinion, cert este c mai avem cale lung pn acolo. Nu cred c este cazul s v spun explicit de ce. Doar att mai adaug: de vin este complexitatea unora dintre activit ile specifice gndirii omeneti. Nu ne rmne dect s alegem dintre nenumratele rele pe care le avem n fa pe cea mai pu in costisitoare din toate punctele de vedere.

Capitolul 3 Ciclul de via al unui sistem soft

nclina ia omului spre rigoare si are izvorul n apetitul lui pentru improviza ie. Formele de manifestare a rigorii n IS au un defect la urma urmei pozitiv: rmn destul de repede n urma timpului. De aceea, "forfota" din laboratoarele de cercetare a IS se va men ine pentru mult vreme dac nu vom gsi ceva mult mai bun de pus n locul actualelor paradigme. Ce s punem n loc? Ceva mai simplu care s poat nmagazina mult mai mult complexitate. Iat, aadar, tema fundamental a cercettorilor IS n mileniul 3: Generarea complexit ii cu ajutorul unor sisteme cu structur simplificat. Subtilit ile temei sunt cunoscute din alte ncercri ale omului. Ceea ce trebuie descoperit este foarte aproape de cea mai mare necunoscut a omului: gndirea. Nu ne rmne dect s nv m s gndim ciclic i asimptotic la aceast mare necunoscut.

3.1 Ciclul de via al sistemelor soft. nc o introducere

S ne reamintim, la acest nceput de capitol, ideea de baz a capitolelor 1 i 2: nevoia de sistematizare a procesului de dezvoltare a sistemelor soft. Nimeni nu contest faptul c se pot ntlni abordri de genul celor reprezentate n Figura 3.1 i n Figura 3.2.

Specificarea cerin elor

Implementare

Figura 3.1 Un model primitiv de dezvoltare a softului

Specificarea cerin elor

Diagrama de structur

Implementare

Figura 3.2 Un model mbunt it de dezvoltare a softului Tot ceea ce se poate spune despre modelele de dezvoltare sugerate de figurile de mai sus este faptul c abstractizeaz frumos, dar ineficient procesul de dezvoltare a sistemelor soft de mare i medie complexitate. Conform Figurii 3.1, specialistul n IS trebuie s aib abilit i remarcabile care s-i permit s fac un salt uria de la cerin e la codul care descrie, practic, n detaliu, solu ia executabil a sistemului soft. Exist oameni care pot face acest lucru. Diferitele nivele de abstractizare i faze de dezvoltare a softului se nfirip n creierele acestora i capt contururi suficient de clare pentru a permite alimentarea cu materie prim de calitate a procesului de codificare. Chiar i n cazul unor astfel de oameni, saltul de la cerin e la cod este plin de riscuri. mbunt irea sugerat de Figura 3.2 este real dar insuficient. Ani la rnd, n laboratoarele de cercetare ale IS s-au fcut eforturi extrem de diverse i uneori foarte originale, pentru gsirea celei mai bune formule de desfurare n timp a procesului de abstractizare a solu iei unui sistem soft. Toate aceste formule se concretizeaz ntr-o list lung de propuneri de cicluri de via , din care vom analiza n continuare cteva exemple reprezentative. Dei ciclul de via propus de o MDS func ioneaz optim n conjunc ie cu o anumit strategie de abstractizare a solu iei, specific MDS, n analiza pe care o fac n paragraful 3.2 voi insista doar pe elementele care definesc particularit ile unei MDS din punct de vedere al ciclului de via . 3.2. Ciclul de via al sistemelor soft. Exemple. Schimbrile care s-au produs, n timp, n ceea ce privete tehnologiile informa ionale i MDS s-au reflectat i n ciclul de via al sistemelor soft, fie prin schimbarea etapelor acestuia, fie prin modificarea strategiei de parcurgere a acestor etape.

Un studiu comparativ al diferitelor exemple de MDS eviden iaz o serie de elemente interesante. Numrul fazelor ciclului de via specific unei MDS poate varia de la trei (analiz, proiectare, implementare) pn la douzeci sau mai multe. Este evident faptul c, i n acest domeniu, concuren a, be ia teoretic i ruperea contactului cu realitatea zmislesc, din cnd n cnd, adevra i montri metodologici. Pentru a trece cu brio examenul practicii, o MDS trebuie s manifeste o preocupare deosebit pentru dou dintre trsturile ciclului de via asociat: -numrul de faze s fie justificat att de o analiz punctual ct i de considera ii de ansamblu n ceea ce privete versatilitatea opera ionalizrii ciclului de via ; -fiecare faz a ciclului de via s fie acoperit satisfctor de elemente suport pentru rezolvarea problemelor de tip ASS, RDS, OMP. Avnd n vedere aceste dou exigen e, voi trece la descrierea unor modele ale ciclului de via al sistemelor soft reprezentative, urmnd s degajez o serie de concluzii generale dup prezentarea acestor modele. 3.2.1. Modelul cascad( MC) Numit i water-fall, este un exemplu de ciclu de via care a fcut istorie. El afost lansat la ap la nceputul deceniului 7 de ctre W. W. Royce i const ntr-o descompunere a ciclului de via al unui sistem soft n faze secven iale. Fazele sunt descompuse n activit i. Trecerea de la o faz la alta se realizeaz dup ce precedenta a fost parcurs integral. S mai re inem i faptul c MC se aplic la nivel de sistem. Alte informa ii cu privire la model n Figura 3.3.
Definirea cerin elor

Analiza

Proiectarea

Implementarea

Testarea

Utilizarea i instruirea

Figura 3.3. Modelul cascad

Avantaje recunoscute ale modelului cascad Ofer un control total asupra fazelor, n sensul c acestea fiind ordonate devin previzibile, eviden iindu-se clar ntinderea lor ca o colec ie de activit i i subactivit i specifice; Este uor de nsuit de ctre partenerii unui proiect, inclusiv de cei cu experien redus; Fiecare faz este acompaniat de o documenta ie destul de bine structurat. Dezavantaje ale modelului cascad Aplicndu-se la nivel de sistem, evident c nu ofer suport prea consistent pentru controlul complexit ii n cazul sistemelor mari; Dei, dup cum reiese i din Figura 3.3, nu este descurajat abordarea iterativ a unor faze sau componente ale lor, restric iile de timp impuse de programarea calendaristic a fazelor limiteaz ofertele benefice ale posibilit ii de revenire la o etap anterioar. Acest fapt nu este tocmai convenabil dac inem cont de faptul c, n practic, nu numai c sunt necesare reluri ale fazelor, mai mult se simte nevoia lucrului n paralel la o scar mai mare dect o permite modelul cascad; Evident, sistemul se pred doar dup parcurgerea etapelor anterioare, ceea ce nseamn o lung perioad de timp pn cnd utilizatorul vede sistemul la lucru, ceea ce nu este convenabil pentru nici una din faze (utilizatorul are destul timp s emit alte preten ii fa de sistemul soft); MC nu ofer suport adecvat pentru abordarea dinamic a proceselor de modelat; MC nu are protec ie explicit fa de modificrile care pot interveni pe parcursul dezvoltrii sistemului soft. Nu am considerat necesar s mai insist asupra con inutului fazelor prezentate n Figura 3.3. Paragraful 2.2 al acestei lucrri con ine suficiente informa ii lmuritoare n acest sens. Cu toate c are destui critici, modelul cascad a fost i este folosit, integral sau par ial, ori de cte ori se dorete un ciclu de via cu o structur echilibrat. 3.2.2 Modelul V (MV) Acest model preia ideile de baz ale modelului cascad, integrndu-le ntr-o concep ie ierarhic de controlare a modului n care sunt parcurse fazele de dezvoltare. (A se vedea Figura 3.4) Modelul, prezentat n Figura 3.4, descrie o strategie de organizare a procesului de abstractizare n care se propune o perspectiv mai clar asupra elementelor de feed-back ale procesului, o abordare mai modern a rela iei sistem-componente, o delimitare mai precis a interferen elor procesului cu utilizatorul sistemului soft rezultat. Adevrul este c marile muta ii produse n lumea tehnologiilor informa ionale orienteaz eforturile specialitilor n IS ctre posibilitatea abordrii unui sistem orientat pe componente, de o manier iterativ-incremental (ceea ce nseamn mai mult dect oferta modelului V) cu o aten ie deosebit fa de utilizator. n actuala etap de dezvoltare a IS utilizatorul a devenit un partener ale crui opinii trebuie luate n seam pentru ca sistemul soft s poat trece cu bine examenul pie ei.

Definirea cerin elor

Validare

Proiectare sistem

Testare sistem

Proiectare subsisteme (componente)

Testare subsisteme (componente)

Codificare/ asamblare componente

Figura 3.4. Modelul V A mai sublinia faptul c n cadrul MV se face o distin ie clar ntre verificare i validare, ca activit i specifice laturii din dreapta a V-ului modelului. Verificarea se refer la testarea sistemului, n diverse faze de dezvoltare, din punct de vedere al corectitudinii logice. n schimb, validarea permite verificarea corectitudinii specificrii cerin elor ini iale fa de sistemul soft. Figura 3.4 ne arat c validarea stabilete dac sistemul, n forma lui final, corespunde sau nu cerin elor. Faptul c validarea este posibil doar cnd sistemul ajunge n forma final este un punct slab al modelului, ndeosebi n situa ia n care procesul de modelat are afinit i structurale sau conjuncturale cu nisipurile mictoare. n acord cu [12], s men ionm faptul c MV, n forma consacrat apar ine lui Ould, care l-a adus n fa a comunit ii specialitilor n IS n 1990. 3.2.3 Modelul incremental (MI) Putem considera c este o alt form a MC. ncercnd s repare unele dintre neajunsurile criticate la MC i MV, MI se expune criticilor venind din alt direc ie. S vedem, mai nti oferta MI sub form grafic (Figura 3.5). Dup cum se observ n Figura 3.5, dup dou faze desfurate la nivel de sistem (definirea cerin elor i analiza) care permit ob inerea unei perspective arhitecturale asupra sistemului modelat, MI propune, pe aceast baz, descompunerea proiectului n subproiecte care genereaz o cascad de activit i paralele care permit ob inerea componentelor necesare sistemului final. Fa de MV, MI ofer posibilitatea atingerii scopului final n dou variante: sistem global livrat la sfrit sau componente livrate distinct. n categoria avantajelor MI considerm: MI se bazeaz pe posibilitatea de a aplica principiul Divide et impera; MI permite livrarea de componente realizate n intervale de timp scurte;

Proiectul sau sistemul final poate fi realizat de mai multe echipe sau persoane datorit modularizrii lui.
Definirea cerin elor Proiectare componenta_1 Implementare componenta_1 Instalare componenta_1 ntre inere componenta_1

Analiza

Arhitectura sistemului

Proiectare componenta_n Implementare componenta_n

Instalare componenta_n ntre inere componenta_n

Figura 3.5. Modelul incremental Dintre dezavantajele imediate considerm: Imposibilitatea aplicrii MI n toate cazurile; exist situa ii n care, pur i simplu nu exist elementele necesare aplicrii principiului Divide et impera n sensul pe care l presupune o modularizare de calitate; Componentele pot fi realizate numai dup ce ntregului sistem i se definete arhitectura, totul derulndu-se conform exigen elor principiului top-down de abstractizare; o cerin destul de dur care sugereaz cunoaterea i formularea cerin elor din faza ini ial de abordare a sistemului; Posibilitatea de a realiza sistemul soft dintr-o sum de componente, pune n fa a echipei (echipelor) care particip la realizarea sistemului soft probleme deosebite de integrare a componentelor pentru a ob ine sistemul executabil. Evident, calitatea demersului de abstractizare a solu iei poate salva sau compromite MI. 3.2.4 Modelul spiral (MS) A fost lansat de un specialist n IS cu preocupri ndelungate legate de ciclul de via al dezvoltrii sistemelor soft, B.W.Boehm. La baza MS stau dou convingeri: natura inerent iterativ a dezvoltrii i nevoia de planificare i evaluare a riscurilor fiecrei itera ii;

deficien a nregistrat la MV n care validarea se efectueaz prea trziu, l determin pe Boehm s propun realizarea acesteia ct mai devreme posibil, de ct mai multe ori, prin construirea de prototipuri, ca n Figura 3.6. n varianta Boehm, echipa de dezvoltare i utilizatorii se angajeaz treptat n proiect, diminund riscurile la nivel de prototip. Interesant este i posibilitatea valorificrii experien ei acumulate n planificarea activit ilor din prototipul urmtor. De precizat faptul c MC se regsete n fiecare itera ie. Ca elemente ce condi ioneaz utilizarea cu succes a modelului semnalez: -profesionalismul echipei de dezvoltare; -flexibilitatea n ac iune a echipei (=utilizarea resurselor, definirea activit ilor de ntreprins).

START

Evaluare prototip 1 Evaluare prototip 2

STOP

Evaluare prototip n

Figura 3.6. Modelul spiral 3.2.5 Modelul evolutiv (ME) Este cunoscut faptul c abordarea obiect orientat asigur un nalt grad de mapare a domeniului problemei peste domeniul solu iei ceea ce faciliteaz dezvoltarea incremental a sistemelor soft. ntr-o opozi ie net cu aspectul monolitic, aspectul evolutiv al ciclului de via se regsete n toate metodologiile obiect-orientate. Pornind de la aceast constatare putem spune c, n principiu, modelul evolutiv const n efectuarea unei investiga ii ini iale, elaborarea unei strategii pentru descompunerea proiectului n segmente (pr i), fiecare segment avnd o valoare deosebit pentru client. Segmentele sunt dezvoltate i livrate n mod iterativ, contribuind la sporirea gradual a performan elor sistemului. Fiecare segment trece prin toate fazele de dezvoltare a sistemelor: definirea cerin elor, analiz, proiectare, implementare, testare, utilizare.

STUDIUL INI IAL DESCOMPUNERE N SEGMENTE

SEGMENT_1 DEFINIRE CERIN E ANALIZA PROIECTARE IMPLEMENTARE TESTRI UTILIZARE

SEGMENT_n DEFINIRE CERIN E ANALIZA PROIECTARE IMPLEMENTARE TESTRI UTILIZARE

INTEGRARE SISTEM

Figura 3.7. Modelul evolutiv La terminarea unui segment, clientul intr n posesia unei forme cvasi-finite a sistemului. Puternica orientare a modelului evolutiv ctre lumea utilizatorilor are un impact deosebit asupra implicrii acestora n dezvoltarea segmentelor sistemului. Reuita utilizrii modelului evolutiv const n specificarea unei arhitecturi deschise, flexibile, prin implicarea tuturor pr ilor interesate, inclusiv a utilizatorilor, dar i a unor specialiti IS profesioniti. ME preia caracteristica esen ial a modelului circular, o form existent printre modelele tradi ionale. Concep ia modelului circular se baza pe ciclul unui sistem, realizat prin cercuri complete. La nchiderea unui ciclu se trece la o nou versiune a sistemului sau la un sistem nou. 3.2.6 Modelul tridimensional (MT) A fost lansat n Fran a i este sus inut de adep ii metodologiei MERISE. Modelul surprinde dezvoltarea sistemelor printr-o redare grafic bazat pe trei axe care descriu: ciclul de via al sistemului, ciclul de via al proiectului i ciclul de abstractizare (Figura 3.8).

Ciclul de via al sistemului soft surprinde timpul vie ii acestuia i perioadele principale dup care se efectueaz schimbri majore, precum: creterea semnificativ a volumului datelor i tranzac iilor de prelucrat i nregistrat, modificarea platformelor hard sau soft, etc. Toate acestea determin ac iunile de ntreprins n timpul realizrii sau ntre inerii sistemului. Ciclul de abstractizare trateaz nivelurile succesive ale specifica iilor, pornind de la elaborarea nivelului conceptual. ntrebarea de baz este: Ce face sistemul?. Rspunsul la aceast ntrebare este independent de aspectele tehnice i organizatorice. Urmeaz elaborarea nivelului logic (Cine execut prelucrrile? Cnd i unde?). Rspunsul la aceste ntrebri trebuie s fie independent doar de aspectele tehnice (platforma hard, sistemul de operare, limbajul de programare ales pentru implementare, etc.). n sfrit, ajungem la elaborarea nivelului fizic (Cum se execut prelucrrile?).
Ciclul de abstractizare

Nivelul conceptual

Nivelul logic

Sistem genera ia 1 Sistem genera ia 2

Nivelul fizic

Studiul preliminar Studiul detaliat Studiul tehnic Implementare ntre inere Ciclul de via al proiectului

Ciclul de via al sistemului

Figura 3.8. Modelul tridimensional Evident, cantitatea de informa ie acumulat la nivelul fizic este cea necesar pentru a avea ceea ce n alte metodologii numim solu ia tehnic a problemei.

Dup aceast solu ie tehnic se poate face implementarea cu minimum de efort dac limbajul ales este bine stpnit. De semnalat virtu ile explicite ale aezrii solu iei pe trei nivele de abstractizare. Cea mai mare ar fi introducerea unei ierarhii a rezisten ei solu iei la diferite tipuri de modificri. n aceast ierarhie, nivelul fizic preia ocurile datorate modificrilor cu dinamica cea mai nalt (platform soft, platform hard), nivelul logic preia ocurile datorate modificrilor organiza ionale (cu o frecven mai redus dect, s zicem, ocurile tehnice), nivelul conceptual preia ocurile cele mai grave care pot afecta un sistem n genere din punct de vedere structural. n tratarea rela iei dintre date i prelucrri lipsesc virtu ile abordrii obiect orientate. n sfrit, ciclul de via al proiectului ofer o perspectiv asupra efortului de dezvoltare a solu iei unei probleme, izomorf cu viziunea clasic asupra ciclului de via al sistemelor soft. Aadar, dup cum se spune i n [12], dezvoltarea unui sistem soft nseamn orientarea permanent i simultan pe cele trei axe. Recunoatem un smbure de adevr n afirma ia c luarea n considera ie a ciclului de via al sistemului permite o planificare riguroas a evolu iei sistemului i a schimbrilor de efectuat, n timp ce ciclul de abstractizare permite ob inerea unei solu ii care nu depinde de op iunile tehnice ceea ce uureaz extinderea sistemului n viitor. Nefiind un model cu priz la autorii consacra i ai domeniului, mul i specialiti pun sub semnul ntrebrii viabilitatea clamat, de altfel cu destul talent de ctre specialitii francezi n IS. 3.2.7 Modelul fntn artezian (MA) Acest model i are originea n modelul spiral i n altele care au adus mbunt iri ale acestuia. Deoarece modelul spiral i are originea n modelul cascad iar MA preia idei din variante mbunt ite ale modelului spiral, s-ar prea c MA este un model cruia ar trebui s-i acordm oarecare aten ie. n acest sens pledeaz i semantica Figurii 3.9. Analiza Figurii 3.9 ne arat c modelul este aplicabil n cazul dezvoltrii de sisteme obiect orientate, cum de altfel ne spun i prin ii modelului (Brian-Sellers Henderson i J.M. Edwards) n lucrrile dedicate prezentrii modelului. ntre timp, inten iile valoroase ale acestui model ca i inten iile valoroase ale altor modele prezentate deja au fost preluate de paradingma UML de modelare obiect orientat a sistemelor soft. 3.2.8 Modelul prototipizrii (MP) Multe modele de dezvoltare se bazeaz pe utilizarea, n anumite momente, a abordrilor iterative (de exemplu, analiza poate implica o serie de sarcini care sunt iterativ repetate pn cnd modelele analizei sunt considerate complete). Dei promite un cadru mai realist de dezvoltare a softului o astfel de abordare poate fi uor descumpnit de constatarea c, n zilele noastre utilizatorul final sau indirect tie s foloseasc sistemul odat ce acesta a fost livrat, ceea ce creeaz foarte repede mprejurrile necesare pentru ca acesta (utilizatorul) s observe eventualele neconcordan e ntre cerin ele lui fa de sistem i cele implementate efectiv. MP ofer o abordare care, poten ial, poate contribui la eliminarea omisiunilor i ambiguit ilor care pot exista n cerin e. n IS se numete prototip un sistem sau un sistem par ial finisat care este construit rapid pentru a explora anumite aspecte ale cerin elor fa de sistem i care nu este considerat sistem gata de livrarea final la utilizator.

Utilizare aplica ie ntre inere Testare sistem Evaluare

Testare componente

Codificare

Proiectare componente

Proiectare sistem Analiza Studiul cerin elor i al fezabilit ii FOND SOFTWARE

Figura 3.9. Modelul fntn artezian Un sistem soft aflat n faza de prototip se deosebete de un sistem soft gata de livrare prin o serie de omisiuni asumate sau strecurate involuntar n faza de codificare (implementare). Astfel c un prototip are, n mod obinuit, o func ionalitate incomplet (capacitate limitat de procesare a datelor, performan e reduse n timpul execu iei, siguran n func ionare problematic, etc.). Dezvoltarea prototipului este posibil efectiv doar utiliznd instrumente pentru dezvoltarea rapid a sistemelor soft (medii vizuale de proiectare, medii vizuale de programare, etc.). Cnd realizm un prototip putem avea diferite obiective n minte. Putem construi un prototip pentru a investiga cerin ele utilizator; n acest scop ne putem focaliza efortul de dezvoltare pe realizarea interfe ei cu utilizatorul pentru a stabili ce date ateapt utilizatorul de la sistem i ce date furnizeaz utilizatorul sistemului. Prototipul poate fi folosit pentru a determina cel mai adecvat gen de interfa . Putem construi un prototip pentru a stabili dac o platform de implementare anume poate suporta anumite cerin e de prelucrare. n sfrit, un prototip ar putea s urmreasc determinarea eficien ei unui limbaj particular, a unui SGBD sau a unei infrastructuri de comunica ie.

O perspectiv mai clar asupra propriet ilor modelului MP putem ob ine i din Figura 3.10.

Analiza ini ial

Definire obiective prototip

Specificare prototip

Evaluare prototip i stabilire schimbri

Construire protoip

Prototip complet

Figura 3.10. Dezvoltarea rapid a softului utiliznd prototipizarea Aadar, fazele principale necesare pentru a pregti un prototip sunt: Efectuarea unei analize ini iale; Definirea obiectivelor prototipului ; Specificarea prototipului; Construirea prototipului; Evaluarea prototipului i stabilirea schimbrilor de efectuat. Efectuarea unei analize ini iale ntreaga activitate de dezvoltare a softului folosete resurse valoroase. nceperea unui exerci iu de prototipizare fr o analiz ini ial este posibil s conduc la o activitate nestructurat i greit focalizat care va produce un soft proiectat nesatisfctor. Definirea obiectivelor prototipului Prototipizarea este de dorit s aib obiective clar stabilite. Un exerci iu de prototipizare poate implica multe itera ii, fiecare itera ie avnd drept rezultat o anumit mbunt ire a

prototipului. Pentru participan ii la un exerci iu de prototipizare, la un moment dat poate fi dificil de stabilit dac prototipizarea trebuie sau nu s continue. Pentru evitarea unei astfel de posibilit i definirea clar a obiectivelor de ndeplinit poate fi de mare folos. Specificarea prototipului Dei prototipul nu este realizat n perspectiva unor opera ii de extindere este, evident, important s aib un comportament scontat. De aceea, este absolut firesc s lum n calcul posibilitatea unor modificri care s apropie prototipul ct mai mult de comportamentul scontat. Aceste modificri sunt mult mai uor de fcut dac softul este realizat potrivit unor principii de proiectare profunde. Construirea prototipului Deoarece este important ca prototipul s fie realizat rapid este firesc ca n aceast faz s se apeleze la un mediu de dezvoltare rapid a plica iilor (Delphi, Visual Basic, Visual C, C-Builder, etc.). Evaluarea prototipului i stabilirea schimbrilor de efectuat Motivul principal pentru care realizm un prototip este testarea i explorarea anumitor aspecte ale sistemului soft de realizat. Prototipul trebuie evaluat n conformitate cu obiectivele identificate la nceperea exerci iului de prototipizare. Dac obiectivele nu au fost ndeplinite, evaluarea are drept consecin o serie de modificri care urmresc apropierea prototipului de obiectivele asumate. Dup cum se vede i din Figura 3.10, ultimele trei faze sunt parcurse ciclic, pn cnd toate obiectivele asumate de exerci iul de prototipizare sunt ndeplinite. n cele ce urmeaz putem prezenta avantajele acestui model dar i o serie de aspecte de care ar trebui s inem cont nainte de a ne aventura n prototipizare. Avantaje: Ilustrarea timpurie a func ionalit ii sistemului ajut la identificarea tuturor dezacordurilor dintre specialistul IS i client; Cerin ele client omise au anse s fie identificate; Dificult ile legate de proiectarea interfe ei pot fi contientizate i rezolvate; Realizabilitatea i utilitatea sistemului soft pot fi testate chiar dac, prin natura lui, prototipul este incomplet. Probleme: Clientul poate percepe prototipul ca parte a sistemului final dar nu poate n elege amploarea efortului cerut, uneori, de realizarea formei finale a sistemului, motiv pentru care are senza ia c acesta (sistemul final) trebuie livrat mai curnd dect este posibil n realitate; Prototipul poate distrage aten ia de la aspectele func ionale (uneori critice pentru sistem) ctre problemele de interfa (fetiizate oarecum de nevoia de a da permanent satisfac ie clientului/utilizatorului); Prototipizarea se bazeaz pe o implicare semnificativ a utilizatorului; Managementul care se bazeaz pe modelul MP are de luat decizii dificile de-a lungul ntregului ciclu de via .

3.2.9 Modelul OMT OMT (prescurtare de la Object Modeling Technique) este un model de dezvoltare al crui artizan este J. Rumbaugh. Urmrind s ofere suport pentru dezvoltarea obiect-orientat a sistemelor soft, modelul are urmtoarele faze: -Analiza; -Proiectarea sistemului; -Proiectarea claselor; -Implementarea. Noutatea modelului poate fi sintetizat astfel: dezvoltarea obiect-orientat a sistemelor soft este un proces conceptual independent de limbajul de programare pn la ultima faz. Vom sesiza aceast deplasare de accent i din scurta prezentare a con inutului fazelor n cele ce urmeaz. Analiza Pornind de la enun ul problemei, analiza are ca rezultat construirea unui model al lumii reale n care sunt eviden iate propriet ile importante ale acesteia. Activitatea n aceast faz debuteaz prin efortul de a n elege problema deoarece enun ul problemei este rareori complet sau corect. Modelul ob inut n faza de analiz este o abstractizare precis i concis a ceea ce trebuie s fac sistemul, nefiind relevant, deocamdat cum o va face. n acest model se opereaz cu obiecte din domeniul aplica iei, analistul nefiind preocupat de obiecte din domeniul implementrii precum: structur de date, procedur recursiv, etc. Un model bun poate fi n eles i criticat de specialiti n IS, care nu sunt neaprat programatori. Modelul analizei nu trebuie s con in nici o decizie de implementare. Ca un exemplu, o clas Window ntr-un sistem de monitorizare a ferestrelor aplica iilor la o sta ie de lucru ar putea fi descris n termeni de atribute i opera ii vizibile utilizatorului. Proiectarea sistemului Specialitul IS implicat n aceast faz trebuie s ia decizii de nivel nalt relativ la arhitectura de ansamblu a sistemului. Astfel, sistemul int poate fi organizat n subsisteme innd cont att de arhitectura propus ct i de analiza structural. Proiectantul trebuie s decid ce caracteristici de performan trebuie s optimizeze, s aleag o strategie de abordare a problemei i s fac o tratativ de alocare a resurselor. Proiectarea claselor n aceast faz este elaborat un model care se bazeaz pe modelul realizat n faza de analiz, cruia i se adaug detalii de implementare. Proiectantul adaug detalii n conformitate cu strategia stabilit pe timpul proiectrii sistemului. Obiectivul fazei l reprezint, n esen , specificarea structurilor de date i a algoritmilor necesari pentru implementarea fiecrei clase. Clasele de obiecte din faza de analiz sunt nc semnificative dar sunt completate cu algoritmi i structuri de date din domeniul solu iei alese astfel nct s se mbunt easc performan ele sistemului. Att obiectele din domeniul aplica iei ct i obiectele din domeniul solu iei sunt descrise de aceleai concepte i nota ii de esen obiect-orientat, dei ele exist n planuri conceptuale diferite.

Implementarea Clasele i rela iile dintre ele aa cum au rezultat n faza de proiectare a claselor sunt acum descrise n conformitate cu exigen ele unui limbaj de programare, innd cont de particularit ile de organizare a bazelor de date sau de anumite elemente hard specifice. Principial vorbind, activitatea de programare ar trebui s fie o parte relativ mic i mecanic a ciclului de dezvoltare a sistemului soft, deoarece se presupune c toate decizile dificile au fost deja luate n faza precedent. S mai adugm faptul c pentru descrierea solu iei unui sistem de-a lungul celor trei faze care premerg implementarea, se folosesc trei tipuri de modele: modelul obiectelor (care descrie obiectele din sistem i rela iile dintre ele), modelul dinamic (care descrie interac iunile dintre obiectele sistemului) i modelul func ional (care descrie transformrile pe care le suport datele din sistem). Sus inute de o nota ie consistent, aceste modele au fcut din OMT un element hotrtor n specificarea uneia dintre cele mai importante paradigme de modelare: UML. 3.2.10 Modelul Ra ional (RUP) RUP (Rational Unified Process) este ciclul de via considerat cel mai adecvat pentru paradigma de modelare UML, asupra creia vom face o serie de considera ii n capitolul 4. Scopul RUP, redus la esen e, ar putea fi formulat astfel: asigurarea cadrului pentru realizarea unor sisteme soft de calitate deosebit, care corespund n cel mai nalt grad cerin elor utilizatorilor, dispunnd de buget i grafic de execu ie predictibile. RUP reunete o parte dintre cele mai bune idei ale MDS curente ntr-o form care este potrivit pentru o mare varietate de proiecte de dezvoltare a softului sau chiar proiecte de modelare organiza ional. n ceea ce privete elementele de management, RUP furnizeaz, poten ial vorbind, o abordare disciplinat a problemelor legate de gestiunea sarcinilor i responsabilit ilor n interiorul unei firme care dezvolt soft. Caracteristici ale RUP RUP descrie un proces iterativ. n cazul sistemelor simple, pare absolut rezonabil un scenariu de rezolvare secven ial unidirec ional a problemei. Exist ns, n practica IS, nenumrate probleme a cror rezolvare nseamn dezvoltarea unor sisteme de mare complexitate sau de-a dreptul sofisticate. Pentru astfel de sisteme, abordarea secven unidirec ional este total nerealist. Alternativa o reprezint abordarea iterativ care sprijin n elegerea progresiv a problemei prin rafinri succesive i creterea incremental a solu iei efective pe baza unor cicluri multiple. Abordarea iterativ ofer flexibilitate n acomodarea la cerin e noi sau modificri tactice la nivelul obiectivelor sistemului modelat. De asemenea, abordarea iterativ permite participan ilor la proiect s identifice i s rezolve riscurile nainte ca acestea s devin o povar n procesul de dezvoltare a proiectului. Activit ile RUP pun accent pe realizarea i ntre inerea unor modele spre deosebire de alte metodologii care fetiizeaz rolul documentelor care nso esc reprezentarea solu iei. Modelele, ndeosebi cele realizate cu ajutorul UML permit reprezentri cu semantic bogat ale sistemelor soft n curs de dezvoltare. Aceste modele pot fi vizualizate n diferite moduri iar informa ia asociat lor poate fi manevrat electronic n regim on-line. Deplasarea

accentului spre modele urmrete minimizarea cheltuielilor necesare pentru generarea i ntre inerea documentelor i, totodat, maximizarea informa iilor cu con inut relevant. Dezvoltarea sistemelor soft conform RUP este centrat pe arhitectur. RUP este un model care con ine suport pentru dezvoltarea i fundamentarea timpurie a arhitecturii sistemului soft. Identificarea unei arhitecturi robuste faciliteaz lucrul n paralel la proiect, minimizeaz efortul de reproiectare i mrete probabilitatea de a reutiliza unele componente ale sistemului. De asemenea, o arhitectur robust este de dorit i din punct de vedere al managementului dezvoltrii sistemului soft. FAZE Fluxuri de lucru n interiorul fazelor Modelare afacere Specificare cerin e Analiz i proiectare Implementar e Testare Configurare hard Fluxuri suport Management ul schimbrilor Management ul proiectului Asigurarea mediului de lucru Itera ii prelimin are Itera ie #1 #2 Itera ie #n+ #n 1 Itera ie #m+1 #m Figura 3.11. Ciclul de via RUP Ini iere Elaborare Consturc ie Tranzi ie

Activit ile de dezvoltare sub RUP sunt dirijate de contextele de utilizare (use casedriven). RUP pune mare accent pe construirea sistemelor lund n considera ie modul n care sistemul, odat livrat, va fi utilizat.

RUP suport tehnicile obiect-orientate. Fiecare model n cadrul RUP este obiect-orientat, realizat conform nota iei furnizate de UML, de preferat. RUP este un proces configurabil. Cu toate c nici un proces nu este potrivit pentru toate firmele de dezvoltare a softului, RUP este configurabil, astfel nct s corespund cerin elor unor organiza ii mergnd pe scara complexit ii de la echipe de dezvoltare mici pn la firmele mari i foarte mari. RUP ncurajeaz preocuprile pentru controlul calit ii i managementului riscului. Evaluarea calit ii este realizat pe tot parcursul dezvoltrii solu iei, cu implicarea progresiv a tuturor participan ilor, utiliznd metrici i criterii obiective. Managementul riscului este, de asemenea, o constant a unui proces RUP, ceea ce permite identificarea n fa a riscurilor care ar putea duna succesului unui proiect. Faze i itera ii n RUP O faz, n IS, este intervalul de timp cuprins ntre dou repere majore ale procesului, n care sunt ndeplinite un set precis de obiective, se realizeaz o serie de piese ale sistemului soft (artifacts, n literatura american) i se decide trecerea sau nu n faza urmtoare, dac este cazul. RUP const n urmtoarele patru faze: Ini iere (Inception); Elaborare (Elaboration); Construire (Construction); Tranzi ie (Transition). Se poate vedea viziunea Rational asupra procesului de dezvoltare a unui sistem soft, din perspectiv sistematic urmrind ideile prezentate n Figura 3.11. Cititorul atent poate s observe marele poten ial ncapsulat n modelul RUP. Dac adugm i precizarea c acest model este sus inut integral de instrumentele CASE elaborate de firma Rational Software, cititorul trebuie s fie de acord cu faptul c toat vlva care se face n jurul UML i RUP are explica ii care au depit deja faza confruntrilor teoretice. Pentru edificare, n continuare voi oferi cteva explica ii pe marginea con inutului celor patru faze. Ini iere Este faza n care se face ceea ce n limba romn s-ar numi studiul de oportunitate care trebuie s precizeze: -domeniul proiectului; -criteriile pentru aprecierea reuitei; -evaluarea riscurilor;

-estimarea resurselor necesare; -un grafic de execu ie preliminar raportat la cele patru faze principale Cu tehnologiile de dezvoltare existente este ct se poate de uzual s se realizeze un prototip executabil care ajut la ntrirea celor precizate mai sus. Elaborare n aceast faz este analizat domeniul problemei, se stabilete un fundament arhitectural robust, se realizeaz planul proiectului i se elimin factorii de risc nalt ai proiectului. Deciziile arhitecturale trebuie luate avnd o viziune bine conturat asupra ntregului sistem. Aceasta nseamn c cea mai mare parte a cerin elor fa de sistem trebuie specificate corect. Pentru validarea arhitecturii propuse se poate implementa un sistem orientat pe contextele de utilizare (use case) semnificative). Construc ie n aceast faz, procednd iterativ i incremental se elaboreaz un produs complet, capabil s porneasc spre comunitatea utilizatorilor lui. Aceasta implic descrierea cerin elor omise n faza de elaborare, proiectarea pn la detaliu a sistemului i completarea implementrii i testrii acestuia. Tranzi ie n timpul acestei faze softul este livrat utilizatorilor. Odat ajuns la utilizatori este posibil s apar cerin e de dezvoltare adi ional, este posibil, de asemenea, s fie scoase la iveal bug-uri scpate sau plantate cu iscusin . n practic, aceast faz debuteaz cu o versiune beta a sistemului care este nlocuit, treptat de versiunea consolidat a acestuia. Teoretic, la terminarea acestei faze se decide dac obiectivele ciclului de via au fost ndeplinite i se evalueaz posibilitatea de a ncepe un nou ciclu de dezvoltare. Cititorul deduce din Figura 3.11 faptul c fiecare faz a modelului RUP poate fi obiectul mai multor itera ii, o itera ie fiind un ciclu de dezvoltare complet n cadrul unei versiuni a sistemului soft executabil, avnd ca rezultat un subset al produsului final, care se va mbog i func ional de la itera ie la itera ie pn cnd ajunge s ndeplineasc condi iile de livrare la utilizatori.

3.3 Concluzii Dei din motive didactice am ncercat s focalizez aten ia cititorului pe no iunea de ciclu de via , acesta va n elege, probabil, legtura indisolubil dintre ciclul de via i celelalte componente ale unei MDS. ndeosebi binomul ciclu de via ciclu de abstractizare trebuie n eles profund de ctre practican ii IS care vor s valorifice la maximum poten ialul unei MDS. Exemplele prezentate arat, pe de o parte, dificult ile ntmpinate de-a lungul timpului de specialiti IS n ncercarea lor de a spori randamentul metodologiilor de dezvoltare a softului, pe de alt parte tendin a permanent a MDS de a oferi o perspectiv ct mai realist asupra procesului de dezvoltare a sistemelor soft. Aa cum se vede i din exemplele prezentate nu lipsesc nici exagerrile, multe din modelele specificate de-a lungul timpului func ionnd frumos doar n nchipuirea creatorilor lor. Ca o concluzie de bun sim , am putea spune c un model de dezvoltare este bun dac este agreat de un numr mare de specialiti.

Acest lucru se poate ntmpla dac: modelul este uor de nv at i opera ionalizat; modelul este bine ancorat n realitatea procesului de dezvoltare; modelul ofer suport consistent de-a lungul ntregului proces de dezvoltare a sistemelor soft. Cititorul ncepe, probabil, s fie de acord cu mine atunci cnd spun c n IS "nisipurile sunt mictoare", multe probleme nerezolvate stau la vedere, deci cei care se simt cu muchii tari pot s ias la "interval". Expedi ia noastr continu pentru c mai avem i alte necunoscute de scos la iveal n capitolele care urmeaz.

Capitolul 4 Abstractizarea solu iei unui sistem soft

Avem nevoie de modele pentru a explica, cu un interes anume, dinamica unui sistem bnuit de noi c ar exista sau care exist sub ochii notri, n toat complexitatea lui. Elabornd modele, mbog im lumea sistemelor, care, privind lucrurile cu obiectivitate tiin ific, par a deschide una dintre marile por i ctre tainele alctuirii universului. O ntrebare, veche de cnd lumea, ar fi : Cum elaborm modelele? De cnd a nceput s se nfiripe, tiin a n genere nu face altceva dect s ne nve e cum putem dibui modele n cele mai neateptate col uri de univers.

4.1. Modelarea. Limbaje de modelare Dup Capitolul 3, n care libertatea de micare a gndirii a fost oarecum ngrdit de exigen ele subiectului abordat, iat-ne din nou pe un teritoriu vast, complex i n continu prefacere: universul modelrii. Activitatea de elaborare a modelelor se bazeaz, prin defini ie, pe un mare consum de energie intelectual. Cu att mai mare este efortul de modelare cu ct orizontul epistemologic al celui implicat n efort este nestructurat sau structurat neconcludent. Ori de cte ori este vorba despre activit i care se bazeaz pe muchii gndirii, trebuie s ne asumm deopotriv riscurile, frumuse ea i noutatea pe care o presupune rezolvarea unei probleme. Chiar i atunci cnd drumul este, pe alocuri, bttorit pentru a reui avem nevoie de dou tipuri de abilit i: abilit i de elaborare sistematic a realit ii, metod de modelare n domeniul de care apar ine problema. Pentru a fi meseriai adevra i ne mai trebuie doar atta ndoial n ceea ce tim la un moment dat ct s ne fie permanent treaz dorin a de a ti mai multe n fiecare clip. Ce este un model? Un model este reprezentarea ntr-un anumit mediu a unui obiect, proces sau fenomen din acelai mediu sau dintr-un mediu diferit. Vom numi sistem real (SR) obiectul, procesul sau fenomenul supus procesului de modelare. Modelul surprinde aspectele considerate importante ale unui SR, dintr-un anumit punct de vedere, simplificnd sau omi nd celelalte aspecte ale SR. Ingineria, arhitectura, astronomia, fizica i, de ce nu, IS folosesc intens modele. Odat realizate, modelele pot fi fizice (n construc ii, n muzeologie, etc.) sau pot lua forma unor reprezentri adecvate pe un suport de memorie extern (hrtie, floppy-disk, harddisk, etc.). n IS propriet ile modelelor sunt reprezentate cu ajutorul limbajelor. Fcnd abstrac ie de cele fizice, modelele se impun aten iei celor care le studiaz prin semantica i nota ia lor. Mai pe n elesul unui specialist IS, n elegerea unui model este o problem de sintax, semantic i, pentru a fi toate bune, trebuie s fie i o problem de pragmatic. Dac singurul merit al unui model s-ar rezuma la faptul c genereaz problemele mai sus men ionate, probabil c, ndeosebi n zilele noastre, ne-am lepda de ele. Realitatea este c avem nenumrate motive pentru care acest lucru nu se ntmpl. Modelarea poate fi utilizat pentru reprezentarea unor sisteme de cunotin e n vederea simplificrii n elegerii acestora de ctre persoanele interesate. n lumea IS se folosesc frecvent astfel de modele pentru a capacita utilizatorii n procesul de specificare a cerin elor fa de un sistem soft, de exemplu.

Elaborarea de modele pare a stimula creativitatea celor care proiecteaz un anumit sistem. nainte de a fi ceea ce este n forma final, un sistem este descris dintr-o serie de perspective care prilejuiesc realizarea a o serie de modele preliminare. Sistemul final este aproximarea unui SR, ob inut prin agregarea sintaxei i semanticii tuturor modelelor preliminare asociate. Dac ar fi s dm un exemplu din lumea IS, atunci sintaxa i semantica unui sistem soft ar putea fi rezultatul agregrii a trei tipuri fundamentale de modele: -modele care descriu aspectele statice ale SR modelat; -modele care descriu aspectele dinamice ale SR modelat; -modele care descriu aspectele func ionale ale SR modelat. Un model poate fundamenta realizarea unui sistem de organizare, clasificare, vizualizare i editare a informa ilor despre sistemele mari. Altfel spus, nu ne putem imagina procedee de simplificare a efortului de modelare ntr-un anumit domeniu dac nu rezolvm problema paradigmei-cadru de modelare. Sistemele dinamice pot fi modelate utiliznd, s zicem, paradigma UML. Cu ajutorul modelelor putem simplifica procesul de alegere a unei solu ii alternative. Numeroase sunt situa iile n care factorii care condi ioneaz la un moment dat procesul de realizare a unui sistem soft complic peste msur decizia de continuare a procesului. O modalitate de a iei din impas ntr-o astfel de situa ie o reprezint elaborarea de modele alternative i alegerea celui mai bun pe baza evalurii avantajelor i riscurilor asociate acestora. Modelele au fost dintotdeauna i elemente suport pentru stpnirea sistemelor complexe. Este, probabil, una dintre virtu ile cel mai mult ncercat n IS. Sistemele soft mari (large software system) pot fi abstractizate pe diferite nivele cu ajutorul modelelor, ceea ce simplific procesul de n elegere a SR modelat (evident, este vorba de un exemplu de sistem informa ional), eviden iaz mai uor structura sistemului sau permite anticiparea impactului pe care eventuale schimbri le pot produce asupra SR. Oprim aici o analiz care ar putea fi continuat la alt nivel de abstractizare pentru a spune mai multe n favoarea utilit ii modelelor. Convingerea mea, probat i de practic, este c merit s nve i s modelezi orict de dificil pare, la nceput, universul paradigmei folosite. Ce este un limbaj de modelare? Cititorul bnuiete, probabil, c nu ajunge s vorbim frumos despre modele. Trebuie s spunem cte ceva i despre climatul n care sunt elaborate aceste modele. Prima afirma ie pe care am mai fcut-o undeva i n Capitolul 1, este c putem elabora modelel folosind un

arsenalpropriu de elemente-suport. Teoretic, ns, avem de nfruntat, cel pu in trei probleme: vom avea, precis, dificult i n a ne face modelele n elese de al i specialiti; probabilitatea de a eua n ceea ce privete calitatea modelului poate fi destul de mare; este extrem de redus ansa de a beneficia de toate avantajele pe care le ofer un mediu de dezvoltare. Dac limbajul de modelare propriu este extrem de valoros, mai avem o ans n recunoaterea lui de o comunitate ct mai larg de specialiti. i, astfel, se face trecerea la al doilea tip de climat propriu elaborrii modelelor: cel n care se folosesc limbaje de modelare, recunoscute ca atare de comunitatea utilizatorilor, purtnd, eventual, girul mediilor academice, beneficiind, n cel mai fericit caz i de recunoaterea ca standard. ntr-o lume a IS un limbaj de modelare care nu este un standard este condamnat la supliciul anonimatului ceea ce echivaleaz cu moartea clinic a ideilor lansate de acel limbaj. Din fericire, chiar i aflat n moarte clinic, un limbaj de modelare propus la un moment dat poate dinui, prin ideile lui valoroase, dac acestea au fost fixate convingtor ntr-o lucrare de specialitate care a ajuns ntr-o bibliotec adevrat. Abandonnd aceste considera ii care risc s provoace un veritabil derapaj tematic, voi ncerca s explic cititorului ce este un limbaj de modelare n general i ce este un limbaj de modelare n IS. n general vorbind, un limbaj de modelare poate fi definit ca o ierarhie de concepte, principii i procedee de opera ionalizare a acestora n vederea abstractizrii solu iilor problemelor care fac parte dintr-o anumit clas tipologic. Aceast defini ie poate fi considerat satisfctoare pentru utilizatorii limbajelor de modelare. n fond, acetia trebuie s fie buni mnuitori ai conceptelor, principiilor i procedeelor de opera ionalizare a acestora pentru a realiza modele crora li se poate aplica sintagma profesionale. Pentru cei care specific limbaje de modelare sau pentru cei care realizeaz sisteme soft suport n procesul de modelare orientate pe un anumit limbaj de modelare, defini ia de mai sus este insuficient. Utilizatorul unui limbaj de modelare este asemenea muncitorului care trebuie s tie s mnuiasc o trus de scule, ntr-un context anume. Persoana care specific un limbaj de modelare este asemenea inginerului care a proiectat trusa de scule, abstractiznd o familie de contexte n care poate fi utilizat trusa. Scoaterea pe pia a unui limbaj de modelare nseamn rezolvarea cu brio a dou probleme majore: - Specificarea universului conceptual al limbajului -Identificarea formalizmului de prezentare a universului conceptual Amndou problemele sunt dificil de rezolvat astfel nct beneficiarii poten iali ai limbajului de modelare s devin beneficiari efectivi n numr ct mai mare. Semnalez, n

continuare, cteva dintre dificult ile i antagonismele cu care se confrunt un specificator de limbaje de modelare (SLM). Primul obstacol pe care trebuie s-l depeasc un SLM este reprezentat de problema delimitrii tipologice a sistemelor care urmeaz a fi modelate cu ajutorul limbajului. Demersul pentru rezolvarea acestei probleme poate eua gra ios dac SLM implicat nu reuete s opreasc la timp elanul generalizrii sau dac, din contr, nu gsete suficiente resurse pentru a extinde rezonabil oferta de aplicabilitate a limbajului. A doua problem cu care se confrunt un SLM este, evident, specificarea universului conceptual. Este, se poate spune, cea mai dificil dintre numeroasele probleme cu care se confrunt un SLM. Aceasta deoarce, universul conceptual trebuie structurat astfel nct s poat fi utilizat, indiferent de complexitatea sistemului modelat. n cazul problemelor de complexitate mic, amploarea efortului de abstractizare este redus; relativ redus este, n general, i semantica pe care trebuie s o codificm cu ajutorul limbajului. Aa cum, probabil, cititorul a dedus deja, confruntat cu exigen ele unei probleme, adecvat tipologic, limbajul de modelare trebuie s fac fa la dou comandamente esen iale: -asigurarea de suport pentru cel care modeleaz n vederea rafinrii treptate a solu iei; -asigurarea de suport pentru cel care modeleaz n vederea captrii semanticii sistemului modelat. Amndou comandamentele apas greu pe umerii celor care vor s specifice limbaje de modelare. Pentru mai mult rigoare n exprimare, de fapt, trebuie s spun cititorului c problema rafinrii treptate a solu iei unei probleme arbitrare este greu de algoritmizat. Acest fapt ar putea fi motivat, oarecum, de includerea aptitudinii de a rafina solu ia unei probleme printre abilit ile de baz ale unei persoane inteligente. Astfel c, nu avem algoritmi de rafinare treptat a solu iei unei probleme, indiferent ce limbaj de modelare discutm; n schimb, orice limbaj de modelare ncearc s propun un "background" pentru alegerea celei mai bune variante de rafinare. Rutatea unei probleme de rafinare a solu iei unui enun dat este dubl: algoritmizarea schemei de rafinare agreat de un limbaj nu poate fi realizat dect n linii mari; pe aceast baz apare al doilea factor de rutate: gsirea schemei de rafinare este o problem de alegere dintr-o mul ime, uneori inepuizabil, de variante. Ca exemple de elemente suport pentru rafinarea treptat a solu iei unui sistem soft putem indica: Descompunerea sistemelor n subsisteme i agregarea subsistemelor n sisteme (dou procedee de abstractizare din teoria general a sistemelor care opereaz cu n elesul originar la nivele nalte de abstractizare). Utilizarea modularizrii pentru ob inerea solu iei unui sistem soft; este un procedeu care extinde utilitatea principiului descompunerii din teoria general a sistemelor la specificul problemelor de modelare din IS. La fel cum descompunerea sistemelor n subsisteme este

consecin a unui anumit mod de a n elege sistemul modelat, modularizarea se poate baza pe abordarea top-down sau bottom-up. Indiferent de alegere avem nevoie de criterii. Ca un exemplu, n cazul abordrii top-down putem avea descompunere bazat pe: -criterii func ionale; -criterii de organizare a datelor; -abstractizarea fluxurilor de date; -tipuri abstracte de date. Fiecare dintre cerin ele de mai sus propune, de fapt, o anumit manier de trecere de la domeniul problemei ctre domeniul solu iei. Comentnd, pe scurt, doar descompunerea func ional, putem semnala faptul c aceasta a aprut i s-a consolidat ca metod n perioada de glorie a programrii structurate. Dintre autorii remarcabili care au abordat descompunerea func ional, amintesc pe c iva mai reprezentativi: De Marco, Yourdon i Constantine, Jackson, Page-Jons, Warnierr-Orr. Descompunerea func ional este cea care premerge, n IS, analiza i proiectarea structurat. La limit, descompunerea func ional a fost introdus cu scopul de a permite controlul complexit ii problemelor opernd cu tehnici de tipul divide et impera. Aadar, fiecare func ie este descompus n subfunc ii .a.m.d pn cnd se ob in componente (unit i de prelucrare) uor de transpus n instruc iunile limbajului de programare ales. Descompunerea func ional (DF) poate fi n eleas, re innd esen ialul, ca o ecua ie de tipul: DF = FUNC II + SUBFUNC II + INTERFE E FUNC IONALE

Evident, n cadrul descompunerii func ionale, preocuparea de baz a specialistului n IS este s identifice prelucrrile necesare n sistem i interfe ele func ionale asociate. Avantaje ale utilizrii DF: -simplitate n utilizare ntruct, orice s-ar spune, este o cale natural de rezolvare a unei probleme. -ob inerea, cu destul lejeritate, a cerin elor utilizatorului. -generarea de solu ii pe diferite nivele de abstractizare (sistem, subsistem, func ie, subfunc ie), fapt benefic pentru controlul complexit ii problemelor n diferite ipostaze. Dezavantaje ale utilizrii DF: -concentrarea eforturilor asupra aspectelor func ionale conduce la acumularea natural a multor date redundante. -nu exist reguli precise pentru opera ionalizarea DF.

-interac iunile non-ierarhice dintr-o solu ie orientat pe func ii sunt dificil de eviden iat. Pentru eliminarea acestor dezavantaje au fost propuse o serie de principii suplimentare (n contextul modularizrii n genere) care urmresc un control sporit asupra coeziunii modulelor i cuplrii lor. Termenul coeziune se refer la gradul de nrudire a componentelor interne ale unui modul ceea ce, n termeni mai precii, msoar gradul de specializare al modulului. O apreciere corect a importan ei coeziunii este posibil dac privim evolu ia unui proiect de-a lungul ntregului ciclu de via . Dac, deci, n perspectiva apropiat sau mai ndeprtat sunt necesare modificri ale unui modul, acestea sunt mai uor de controlat i de localizat dac modulele sunt nalt coezive. Coeziunea poate avea mai multe forme de exprimare. Fundamentale n procesul de abstractizare a solu iei unui sistem soft sunt coeziunea logic i coeziunea func ional. Coeziunea logic a unui modul rezult ca urmare a faptului c elementele lui interne permit realizarea unor activit i de aceeai natur. De exemplu, putem presupune c am proiectat un modul care se ocup de comunicarea sistemului soft cu lumea exterioar. Ceea ce unete componentele unui astfel de modul este faptul c toate activit ile au legtur cu ideea de comunicare. Evident, ns, comunicarea se poate referi la multe lucruri diferite (preluarea datelor, afiarea datelor, raportarea unor erori, etc.). O form mai puternic de coeziune este coeziunea func ional care msoar gradul de integrare al componentelor unui modul n vederea realizrii unei singure activit i. Problema care apare aici este: Ce se n elege prin ideea de activitate?. Rspunsul depinde, n mare msur, de contextul n care se pune ntrebarea. Termenul cuplare este introdus n modularizare pentru a msura gradul de interconectare a modulelor. Interconectarea modulelor este obligatorie pentru ca acestea s formeze un sistem coerent. ns, ra iunile de dezvoltare i ntre inere ne pun din nou n fa a unei cerin e de tipul o modificare efectuat ntr-un modul nu trebuie s afecteze imprevizibil comportarea celorlaltor module. Simplu i firesc. Pentru ca s fie i adevrat este clar c un obiectiv constant al modularizrii trebuie s fie maximizarea independen ei modulelor, ceea ce se ob ine prin minimizarea cuplrii acestora. Cuplarea modulelor se poate realiza prin control i prin date. Cuplarea prin control apare atunci cnd unul dintre module cedeaz controlul ctre alt modul. Cuplarea prin date se refer la partajarea datelor de ctre modulele unui sistem soft. Indiferent de tipul cuplrii este important ca aceasta s fie ct se poate de vizibil deoarece cuplarea implicit (ascuns) este cauza multor erori, ndeosebi de programare. Prin incursiunea fcut sper c am reuit s atrag aten ia cititorului asupra complexit ii decizilor cu care se confrunt un limbaj de modelare i, n egal msur, un specialist IS n rela ia cu o problem de modelare. Singura certitudine n procesul de modelare a solu iei unui sistem soft ar putea fi rezumat astfel: orice decizie luat n procesul de modelare genereaz probleme noi. Datoria specialistului n IS este de a ine sub control influen ele nedorite ale acestor probleme.

De fapt, ntreaga evolu ie n materie de modelare merge pe ideea de nlocuire a unei paradigme vechi de modelare cu o paradigm nou, atenund sau eliminnd defec iunile vechii paradigme, introducnd probleme noi care, asumate corect de ctre specialistul n IS, nu pot afecta semnificativ calitatea sistemului soft. S mai facem o precizare necesar: apari ia unei paradigme noi de modelare nu nseamn negarea tuturor ideilor vechilor paradigme. Astfel, de la descompunerea func ional la modelarea obiect-orientat este, sincer vorbind, cale lung. Aceasta nu nseamn, ns, c elementele de abordare func ional au disprut cu totul. Ele sunt n continuare prezente dar la un anume nivel de abstractizare a solu iei. Relum o idee pe care am mai vehiculat-o n acest capitol: suportul oferit de o MDS pentru abstractizarea solu iei unui sistem soft trebuie s l ajute pe specialistul n IS s fac trecerera de la domeniul problemei ctre domeniul solu iei conservnd ct mai multe dintre avantajele pe care experien a n materie de modelare le-a certificat. Pentru efectuarea unei treceri, specialistul n IS trebuie s gseasc n limbajul de modelare universul conceptual adecvat. Deoarece sistemele reale, supuse modelrii suport adeseori modificri, uneori strructurale, ceea ce creaz premize pentru apari ia, n timp, a unor semnifica ii particulare la nivelul sistemului real este evident c limbajul de modelare trebuie s posede, att ct este posibil i mecanisme pentru extinderea controlat a semanticii limbajului de modelare (a se vedea exemplul oferit de UML n aceast privin ). nchei aici considera iile pe marginea celei de-a doua probleme cu care se confrunt un SLM. A treia problem n aten ia unui SLM se refer la nota ia prin intermediul creia se face transfer de semantic dinspre limbajul de modelare ctre utilizatorul limbajului de modelare. Este o problem care, rezolvat nesatisfctor, poate compromite inten iile conceptuale ale limbajului. De regul, o nota ie inspirat permite: -vizualizarea procesului de modelare; -specificarea solu iei unei probleme; -realizarea solu iei; -documentarea solu iei. Vizualizarea procesului de modelare Este o calitate care contribuie hotrtor la rezolvarea a dou probleme importante: - sporirea semnificativ a accesibilit ii limbajului de modelare; n opozi ie total cu limbajele de modelare vizuale se afl limbajele de modelare care se bazeaz pe o sintax exclusiv formal. - asigurarea unui cadru sistematic pentru realizarea de medii CASE pentru promovarea modelrii vizuale asistat de calculator. Impactul pe care l are caracterul vizual al modelrii asupra productivit ii muncii este uria, dac adugm precizarea c mediile de dezvoltare asistat iau asupra lor mare parte din sarcinile de rutin sau susceptibile de a fi automatizate.

Exist specialiti care pun n crca vizualizrii o anumit tendin de depreciere a specificrii solu iei unei probleme (datorit oportunit ii pe care o reprezint un mediu CASE pentru a prototipiza, de exemplu). Chestiunea este discutabil deoarece, dac se lucreaz sub presiunea timpului, un mediu de dezvoltare nu poate dect s ne ajute s scurtm termenele de execu ie realiznd componente cu nalt grad de standardizare. De asemenea, dac timpul nu preseaz, atunci ine oricum de liberul arbitru dac nainte de a ne repezi la tastatur am reflectat suficient la problemele etapei n care ne aflm. Specificarea solu iei unei probleme Orice limbaj de modelare trebuie s posede n cel mai nalt grad nsuirea de a permite specificarea corect i complet a solu iei unei probleme. Cititorul care s-a confruntat, ca specialist IS, cu efectele devastatoare (asupra existen ei unui sistem soft) ale unei specificri incorecte i/sau incomplete n elege pe deplin greutatea acestei cerin e. Raza de ac iune a calit ii procesului de specificare a soul iei unui sistem soft aduce atingere att factorilor interni ct i factorilor externi ai calit ii unui sistem soft. Privind aceast cerin i din perspectiva exigen elor unui poten ial mediu de dezvoltare, asociat limbajului, adugm o nou dimensiune n elegerii capabilit ilor unui limbaj de specificare a solu iei unui sistem soft. Atrag aten ia cititorului asupra utilit ii unei dezbateri mai ample pe teme de corectitudine i completitudine. Astfel, un specialist IS poate opera cu cel pu in dou sensuri ale conceptului de corectitudine: -corectitudinea de mapare -corectitudinea formal. Corectitudinea de mapare caracterizeaz modul n care cerin ele beneficiarului sunt specificate n solu ie. Orice diferen ntre mesajul corespunztor unei cerin e din domeniul problemei i mesajul aceleiai cerin e n domeniul solu iei trebuie interpretat ca un exemplu de specificare incorect. Corectitudinea formal rspunde de acurate ea formal a specificrii. Mesajul de baz al specificrii poate fi prezent, deci avem corectitudine de mapare, dar acurate ea specificrii din punct de vedere formal poate fi un obstacol n comunicare sau n generarea automat corect a unor piese ale sistemului soft de ctre mediul de dezvoltare. n materie de specificare corect este cunoscut duelul dintre sistemele formale de specificare (Z, Z++, VDM, VDM++) i sistemele intuitive de specificare. n timp ce sistemele formale de specificare sunt puternic matematizate, ceea ce restrnge serios numrul celor interesa i de aceast abordare, sistemele intuitive ncearc s cultive rigoarea utiliznd masiv semantici exprimate cu ajutorul limbajelor naturale. Valen ele semantice ale no iunii de completitudine a specificrii sunt, de asemenea, variate. Analog corectitudinii, putem vorbi de completitudine de mapare, prin care n elegem prezen a n sistemul de cerin e a tuturor elementelor vitale n momentul dezvoltrii softului, precum i a unor elemente-cadru care s permit redefinirea, la nevoie, a sistemului de cerin e. Putem vorbi, de asemenea, de o completitudine structural, prin care desemnm finalizarea corect a tuturor inten iilor de specificare ale proiectului. Evident, efortul de specificare corect i complet are determinri adnci n structura ciclului de via i a ciclului de abstractizare. Acest lucru va fi mai clar pentru cititor n

momentul n care va trece de la n elegerea pe buc i a unei MDS la o viziune sistemic asupra utilit ii ei. Realizarea softului O nota ie chibzuit aleas trebuie s aib calitatea de a permite relativ uor transpunerea solu iei tehnice n limbajul de programare ales. Ceea ce, probabil, pare simplu ca teorie este ns o sarcin dificil pentru SLM. Pentru ca nota ia unei MDS s faciliteze realizarea softului, la specificarea limbajului de modelare trebuie depuse eforturi de unificare, pe ct posibil, a lumii conceptelor din domeniul solu iei tehnice cu lumea conceptelor din domeniul programrii. Aceast unificare este extrem de dificil ct timp n lumea limbajelor de programare se men in nc deosebirile de abordri n ceea ce privete structura solu iei unei probleme. ntr-o oarecare msur este chiar scuzabil o astfel de stare de lucruri. S ne gndim c n programare exist nu doar varia iuni pe o anumit tem ci chiar teme diferite. Programatorii cu experien tiu c ntr-un fel este s programezi ntr-un limbaj procedural, alta este optica ntr-un limbaj de esen func ional, aproape cu totul alta este abordarea ntr-un limbaj suport pentru programarea logic. De asemenea, este o lume principial nou i programarea obiect-orientat; plin de surprize este i lumea limbajelor paralele. Deosebirile de natur conceptual dintre limbajele prezentate mai sus (care nu au epuizat lista tipurilor de limbaje existente!) sunt suficient de pregnante pentru a provoca derut, la primul contact, unui programator crescut ntr-o alt paradigm. De ce ne-am atepta s fie mai uoar soarta SLM n ceea ce privete ncercarea lor de unificare a semanticilor diferitelor limbaje de programare ntr-o nota ie ct mai robust. Pentru a da un exemplu concret de ncercare n aceast direc ie recomand aten iei cititorului nota ia UML care reuete un lucru demn de toat lauda: aducerea la numitor comun a numeroaselor MDS autoproclamate obiect-orientate prin propunerea unei nota ii n care i fac loc concepte fundamentale ale modelrii obiect-orientate (clas, obiect, asociere, agregare, generalizare, motenire, mesaj, metaclas, metod, signatur, pachet, ablon, stereotip, etc.), precum i o serie de concepte care in de reprezentarea diferitelor tipuri de arhitecturi ale unui sistem soft n genere, modelarea n mediile de calcul paralele, etc. Dei ambi ia oricrui SLM n IS este de a vedea modelele ob inute independente de limbajul n care va fi transcris modelul, nu nseamn neaparat c are i sus inere efectiv. Revenind la cazul UML-ului, autorii lui clameaz independen a fa de limbaje de programare, dar, n sinea lor tiu c maparea solu iei tehnice pe solu ia programat este perfect doar dac principiile fundamentale ale limbajelor de modelare i programare sunt n rezonan . Pentru ca lucrurile s progreseze mai sunt de nfptuit numeroase reforme n ceea ce privete: -impunerea de standarde tehnologice n domeniul sistemelor de operare; -definirea i implementarea unor standarde n ceea ce privete structura sistemelor soft. Mediile vizuale de programare (de genul DELPHI, VISUAL C++, C-Builder, etc.) sunt exemple gritoare de abordri compatibile cu o paradigm de modelare important cum este UML.

Documentarea solu iei Nota ia unui limbaj de modelare trebuie s dispun de resursele necesare pentru a permite: -reprezentarea i documentarea arhitecturii sistemului; -reprezentarea i documentarea cerin elor fa de sistemul soft; -reprezentarea i documentarea solu iei tehnice la diferite nivele de abstractizare; -reprezentarea i documentarea activit ilor specifice managementului dezvoltrii sistemelor soft. Sistemele soft adevrate (n sensul c au complexitate medie sau mare) trebuie s adauge lng codul surs (izomorf, practic, cu codul executabil al sistemului soft) o serie de alte produse tipice ingineriei softului care, laolalt, alctuiesc documenta ia constructiv i de prezentare a sistemului soft. Documantarea complet a unui sistem soft este o prob de profesionalism pe care firmele de soft mari au transformat-o ntr-un veritabil bussines pe seama cererii de documanta ie, n cretere, din partea utilizatorilor diverselor tehnologii informa ionale lansate pe pia . A patra problem n aten ia unui SLM se refer la stabilirea limbajului cu care este definit limbajul de modelare. Cr ile care popularizeaz limbajele de modelare apeleaz, de regul, la o combina ie ntre limbajul natural i elemente de descriere formal pentru a realiza compromisul optim ntre rigoare i accesibilitate. Documenta ia de referin a unui limbaj de modelare poate apela la un limbaj special pentru descrierea propriet ilor limbajului de modelare. Situa ia este similar cu cea ntlnit n domeniul limbajelor de programare, unde se cunosc formalizme de descriere a anumitor propriet i ale limbajelor de tipul: -diagrame de sintax -sintaxa BNF Evident, exist i excep ii interesante n ceea ce privete alegerea limbajului cu ajutorul cruia se specific un limbaj de modelare. Este vorba de sistemele formale de specificare a softului (Z, Z++, VDM, VDM++) care apeleaz, esen ial, la un formalizm matematic care poate veni dinspre teoria mul imilor, logic, calculul lambda, etc. Poate fi, de asemenea, vorba despre limbajele de modelare, gen UML, care con in n ele nsele resursele pentru specificarea semanticii lor. 4.2. Arhitectura unui limbaj de modelare Un limbaj de modelare care se respect i propune (cel pu in din cauza cerin elor formulate n paragraful 4.1.) s se prezinte n fa a utilizatorilor cu o concep ie arhitectural clar. n elegerea arhitecturii unui limbaj de modelare este benefic att pentru utilizatorii limbajului ct i pentru cei care i studiaz fundamentele. Efectul cunoaterii arhitecturii unui limbaj de modelare asupra unui utilizator al acestui limbaj este similar efectului pe care l are, n general vorbind, structurarea asupra unui demers de cunoatere a unui sistem. Arhitectura unui sistem este datoare s explice tuturor celor interesa i:

-care sunt subsistemele fundamentale ale sistemului; ce semantic ncapsuleaz aceste subsisteme? -care sunt dependen ele fundamentale ntre subsistemele eviden iate mai sus; care este semantica esen ial a acestor dependen e? -care este formalizmul utilizat pentru descrierea i reprezentarea elementelor prezentate mai sus? Este evident faptul c, prin clarificarea aspectelor arhitecturale ale unui limbaj de modelare, SLM definete orizontul strategic al posibilit iilor de operare cu capabilit ile de modelare ale limbajului. Este posibil ca, pentru mul i utilizatori, cunoaterea acestui orizont s nu fie deloc o prioritate. Aceasta deoarece al ii decid pentru ei ce limbaj de modelare trebuie s foloseasc iar utilizarea efectiv a limbajului nu trebuie s treac neaparat prin n elegerea subtilit ilor asociate perspectivei arhitecturale. Pentru a ne forma o idee asupra utilit ii cunoaterii arhitecturii unui limbaj de modelare ne putem inspira din obinuin a pe care i-au fcut-o unii productori de soft de a scoate pe pia manuale de utilizare i manuale de referin pentru sistemele soft pe care le produc. Manualele de referin manifest o aten ie sporit fa de elementele arhitecturale i fa de, s-i spunem, evolu ia universului conceptual al obiectului descris. Manualele de utilizare ncearc, mai degrab, s prezinte utilizatorului scenarii pe baza crora se poate utiliza semantica obiectului respectiv. O astfel de abordare este prezent i n politica firmei Rational Software Corporation de promovare a limbajului de modelare UML, de exemplu. Aa cum se ntmpl, n general, arhitectura unui limbaj de modelare este rezultatul unui efort special de clasificare i ierarhizare conceptual, efort pe care l-am putea numi metamodelare. La ora actual specialitii IS n materie de limbaje de modelare precum i organismele care se ocup de promovarea standardelor n domeniu agreeaz dezvoltarea de arhitecturi pentru limbaje de modelare cu patru nivele de abstractizare. Care sunt aceste nivele i ce func ii ndeplinesc ele se poate vedea n Figura 4.1. Specialitii n IS, interesa i de utilizarea intens a limbajelor de modelare prefer s nlocuiasc abordarea arhitectural cu o abordare pragmatic. Pentru un utilizator de limbaj de modelare scenariul cel mai plauzibil este urmtorul: 1. Dintr-un motiv anume, n aten ia specialistului IS, ajunge o anumit realitate informa ional, cu veleit i sistemice i structurale obiective. 2. Specialistul IS stabilete determinarea obiectiv i subiectiv a realit ii informa ionale respective. n determinarea obiectiv includem acele aspecte ale realit ii informa ionale care exist i se manifest independent de atitudinea specialistului IS. n determinarea subiectiv intr n joc exact atitudinea specialistului IS fa de aspectele obiective ale realit ii informa ionale. Din momentul n care atitudinea specialistului fa de realitatea informa ional ncepe s se structureze, practic, ncepe procesul de modelare a realit ii informa ionale. Acest proces presupune:

Nivel Meta-metamodel

Descriere nivel Reprezint infrastructu-ra necesar pentru meta-modelarea arhitecturii. Definete limbajul pentru specificarea metamodelelor. Este o instan a unui metametamodel. Definete limbajul pentru specificarea unui model. Este o instan a unui metamodel. Definete limbajul necesar pentru descrierea unui anumit domeniu informa ional. Un obiect utilizator este o instan a unui model. Un obiect utilizator specific un anumit domeniu informa ional.

Exemple de concepte Meta clase, Meta opera ii, meta atribute, etc.

Metamodel

Clas, atribut, Opera ie, etc.

Model

Matricol, Adresa, Medie-la-admitere, etc.

Obiecte utilizator (date utilizator)

111, Calea Victoriei 81 Bl 2, Sc A, Ap. 20, 10

Figura 4.1. Arhitectura standard pe patru nivele a unui limbaj de modelare permanente i obligatorii procese de abstractizare. Se face abstractizare atunci cnd schi m elementele arhitecturale ale modelului, ceea ce nseamn generalizare. Se face abstractizare atunci cnd optm pentru o solu ie alternativ n procesul de rafinare a modelului, ceea ce nseamn specializare. permanente i obligatorii eforturi de reprezentare a diferitelor nivele de abstractizare, scopurile urmrite fiind: -rezolvarea problemelor de comunicare; -ob inerea specifica iilor complete ale modelului. Foarte bine! Nu s-ar putea s m exprim i mai concret n legtur cu cele dou dimensiuni ale procesului de modelare semnalate mai sus?

Voi ncerca acest lucru n continuare. Aadar, dat o problem adevrat (= volum mare de informa ii, stabilitate structural n mod nativ perisabil), specialistul n IS execut sarcini de genul: Identificarea fluxurilor informa ionale esen iale; este tiut faptul c multe dintre crea iile omului, inclusiv limbajele naturale, apeleaz la redundan pentru a-i consolida virtu ile semantice. Excesul de semantic se justific dac exist beneficiari imedia i pentru acest exces. Dac beneficiarii nu exist, atunci excesul de semantic ntemeiat pe redundan trebuie eliminat. n aceast ncletare pentru identificarea fluxurilor informa ionale, specialistul IS trebuie s fie, n egal msur, un culegtor harnic de date despre fluxurile informa ionale dar i un abil mnuitor al procedeelor de clasificare, ierarhizare, codificare, abstractizare i documantare a acestor fluxuri informa ionale. Rezultatul acestui demers: un tablou ct se poate de complet al tipurilor de date considerate importante pentru rezolvarea problemei. Identificarea cerin elor fa de sistemul soft care solu ioneaz problema. Acest tip de demers este complementar celui semnalat mai sus. Odat enun ate aceste cerin e, specialistul IS trece la definirea lor. Din nou se pune mare accent pe abstractizare pentru a alege din mul imea alternativelor calea cea mai apropiat de cerin ele imediate dar i cea mai potrivit din punct de vedere al posibilit ilor de evolu ie. Rezultatul demersului: o perspectiv de nivel de abstractizare nalt asupra propriet ilor esen iale ale solu iei: -date -func ii -componente -resurse angajate. Proiectarea solu iei sistemului soft. Numeroasele obiective i restric ii asumate pn la nceperea proiectrii reprezint cadrul de valorificare a acumulrilor din activit ile specificate generic mai sus. Un bun proiectant n elege rolul nsemnat jucat de abilitatea de a-i impune i gestiona o sumedenie de factori de constrngere, ineren i n procesul de realizare a unui soft de calitate. Nenumrate sunt momentele de cumpn n realizarea unui sistem soft. i aceasta se ntmpl deoarece procesul de dezvoltare a unui sistem soft nu este liniar i are multe elemente de descoperire n structura lui. Consider c abilitatea de baz a unui specialist IS avnd competen e n analiz, proiectare sau implementare rmne capacitatea de a abstractiza metodic. Este o abilitate care se formeaz prin exerci iu autoimpus i autocenzurat. Dorin a de a ob ine bijuterii n IS, transformat n exerci iu de plcere, iat secretul evolu iei profesionale i n materie de paradigme n IS.

4.3. Complemente. Elemente de teoria general a sistemelor Am mai fcut referiri scurte la importan a, consider eu, major a teoriei generale a sistemelor (TGS) n cunoatere, n modelare, n economie, politic, etc. Greu de gsit un col n lume cruia s nu i se potriveasc ceva din abordarea TGS. n acest paragraf voi ncerca s explicitez o serie de idei care, sub presiunea necesit ii, se manifest i implicit. Pentru nceput s observm c, n general vorbind, no iunea de sistem, n jurul creia vom articula discursul acestui paragraf, are un dublu n eles. Cu mai mult sau mai pu in discernmnt, numim sistem: un obiect, fenomen sau proces cu existen material l vom numi sistem real (SR) supus la un moment dat aten iei unui observator oarecare; tot sistem numim i un model care aproximeaz comportamentul unui SR. Aadar, atragem aten ia vorbitorilor de TGS asupra acestei surse de ambiguitate pe care o pot activa cu mare uurin , dac nu i men in aten ia treaz. Prima ntrebare pe care ne-o punem n TGS este, evident, urmtoarea: Ce este un sistem?. 4.3.1. Defini ia i caracteristicile unui sistem n TGS se numete sistem o colec ie de componente interconectate astfel nct se poate spune c evolueaz n comun pentru ndeplinirea unui obiectiv predefinit. La scara universului se poate vorbi, despre omniprezen a unor variate tipuri de sisteme care respect defini ia de mai sus i care se integreaz n sisteme din ce n ce mai complexe deoarece, chiar i filozofic vorbind, interdependen ele sunt esen iale pentru a discrimina multe dintre propriet ile unui sistem. Dintre propriet ile sistemelor (reale sau teoretice) importante i pentru o corect utilizare a paradigmei TGS n IS voi prezenta, n continuare, pe cele mai importante. Orice sistem are un mediu n care exist. Este dincolo de n elegerea omeneasc posibilitatea existen ei unui sistem fr nici o alt conexiune cu alte sisteme. No iunea de sistem nchis este o utopie teoretic. Contientizarea mediului n care exist un sistem real, de exemplu, poate fi esen ial pentru calitatea modelrii acestuia, dac se urmrete acest lucru. Orice sistem este delimitat de mediul n care exist de un anumit tip de frontier. Frontiera unui sistem este o no iune cu o semantic discutabil. Nici ntr-un caz, frontiera unui sistem nu este utilizat pentru a realiza nchiderea acestuia. Frontiera este o no iune cu ajutorul creia se realizeaz o delimitare ntre dinamica intern a unui sistem i dinamica rela iilor sistemului cu mediul nconjurtor. Avem nevoie de o cunoatere exact a frontierelor pentru a face ra ionamente corecte relativ la propriet ile unui sistem. Interfa a sistemului cu mediul este dependent de structura frontierei sistemului. n teorie, nu se poate ncepe procesul de modelare a unui SR dac nu au fost convenite frontierele acestuia. Orice sistem are intrri i ieiri. Intrrile sunt semnale (mesaje) ale mediului ctre sistem. Ieirile sunt rspunsuri pe care sistemul le d mediului n care se afl. Orice sistem are interfa . Interfa a permite comunica ia ntre dou sau mai multe sisteme. n IS, n jurul conceptului de interfa s-au dezvoltat tehnologii soft importante pentru viitorul tehnologiilor informa ionale (COM, DCOM, CORBA, etc.).

Orice sistem poate avea, poten ial, subsisteme. Este o constatare care, sub lupa filozofilor este asociat cu posibilit ile de observare ale omului, inerent limitate att n perspectiv microscopic ct i n perspectiv macroscopic. Cert este c orice subsistem poate fi, la rndul lui, n eles ca sistem care, de asemenea, se poate descompune n subsisteme. Operatorul de descompunere a sistemelor n subsisteme este recursiv i se aplic cu maximum de discernmnt. Afirma ia de bun sim n ceea ce privete acest operator este c nu se descompune ceea ce din perspectiva intereselor imediate de modelare sau cunoatere este invizibil. Orice sistem care rezist n timp are un mecanism de control. Problema durabilit ii n timp a sistemelor are legtur nemijlocit cu problema stabilit ii structurale a sistemelor la care vom face referiri n 4.3.2. Mecanismele de control ale sistemelor pot fi de tip feedback sau, uneori, de tip feedforward. Controlul pe baz de feedback presupune dirijarea informa iilor despre ieirile sistemului ctre subsistemul de control. Controlul pe baz de feed-before presupune colectarea permanent de date despre intrri i transmiterea acestora ctre subsistemul de control. Dei nu am spus explicit acest lucru, cititorul n elege faptul c subsistemul de control poate modifica comportamentul sistemului (n condi iile men inerii unei anumite stabilit i structurale) pentru a asigura o rela ie scontat ntre intrri i ieiri. Sistemele pe baz de feedback reac ioneaz mai lent la semnalele mediului. Sistemele pe baz de feed-before sunt mai sensibile la schimbrile de mediu ceea ce le mrete capacitatea de adaptare. Problema principal o reprezint costurile proiectrii sistemelor de control de tipurile mai sus men ionate. Sistemele de control orientate feed-before sunt mai scumpe i mai dificil de implementat. Ultima remarc pe care o adugm no iunii de sistem este urmtoarea: un sistem are ntotdeauna propriet i care nu sunt deductibile direct din propriet ile pr ilor. Aceste propriet i le putem numi propriet i integratoare (emergent properties, n englez). Cu ct aceste propriet i integratoare se manifest mai pregnant cu att mai mare este gradul de organizare a sistemului. Iat, aadar, alt subiect de care specialitii n IS sunt ct se poate de interesa i: gradul de organizare a sistemelor. Dac am continua am ajunge la considera ii savante privind msurarea entropiei unui sistem din perspectiv probabilist-informa ional ceea ce nu ne propunem, de fapt, n aceast lucrare. Este momentul s atragem cititorului aten ia asupra puternicului impact pe care gndirea holist (sistemic-integratoare) l poate avea asupra calit ii modelelor elaborate n IS. Ca un rezumat al ideilor prezentate n paragraful 4.3.1. v invit s analiza i semantica Figurii 4.2. A ncheia acest paragraf atrgnd aten ia cititorului asupra faptului c elementele introductive pe care le-am prezentat sunt, n mod sigur, un nceput de drum pentru specialitii IS interesa i n surprinderea i modelarea propriet ilor numeroaselor tipuri de sisteme informa ionale care populeaz nv mntul, lumea afacerilor, sistemele nuclearo-energetice, etc. ... 4.3.2. Structura unui sistem n defini ia dat unui sistem se face trimitere la rela iile dintre componentele unui sistem. tiu c printre filozofi exist adevrate certuri n legtur cu problema clasificrii i individualizrii acestor rela ii. Pentru exigen ele muncii n IS este important s tim c

n elegerea unui sistem este, pe lng o problem de delimitare n spa iu i o problem de evolu ie n timp. n evolu ia n timp a unui sistem se pot deosebi dou tipuri fundamentale de rela ii ntre componentele unui sistem: rela ii stabile i rela ii accidentale (ntmpltoare). Ansamblul rela iilor stabile dintre elementele unui sistem formeaz structura sistemului.

Frontier sistem Intrri Ce face sistemul Ieiri

Fluxuri de control

Feed-before

Cum este controlat sistemul

Feed-back

Mediul nconjurtor al sistemului

Figura 4.2. Componentele fundamentale ale unui sistem i rela iile dintre ele Pentru un specialist n IS, mai important dect faptul c structura unui sistem poate fi abstractizat de un sistem de ecua ii de nu tiu care tip, este cunoaterea faptului c un proces de modelare a unui sistem real este posibil s aib succes doar dac acestui sistem real i se poate asocia o perspectiv din care s se ntrezreasc un anumit gen de stabilitate structural. Zic un anumit gen de stabilitate structural ca o recunoatere a faptului c modelarea sistemelor nseamn, de fapt, aproximarea comportamentului lor dintr-o perspectiv concordant cu obiectivele asociate sistemului modelat. Astfel c nu este deloc o ntmplare faptul c una dintre primele cerin e ale succesului n modelarea specific IS o reprezint specificarea corect a binomului obiective+diagnostic stabilitate structural relativ la dezvoltarea unui sistem soft. Cu ncredin area c cititorul care a ajuns n acest punct al cr ii a fost provocat la studierea mai atent a utilit ii TGS n abstractizarea solu iei sistemelor soft i nu numai, pun punct paragrafului 4.3. 4.4. Complemente. Principii ale modelrii cu impact deosebit n IS Dei unii dintre cititori vor fi de prere c afirma iile pe care le voi face n continuare le erau de mult cunoscute, acest fapt nu m mpiedic s le fac gndindu-m la cei care nu au avut nc for a necesar pentru a se ridica la nivelul acestor principii n deplin cunotin de cauz. Aadar, este vorba de patru principii care, coroborate cu abilit ile de gndire sistemic i cu abilit ile de modelare specifice IS, v pot ajuta s traversa i cu succes jungla de obstacole care se dezvolt, n mod natural, ntre enun ul problemei i solu ia acesteia.

Primul principiu Alegerea tipului de model pe care urmeaz s l crea i are o influen profund asupra modului n care aborda i problema i deci asupra caracteristicilor solu iei acesteia. Aa cum insinuam i n alt context al prezentului capitol, acest principiu atrage aten ia explicit asupra efectelor pe care le pot produce, asupra solu iei n ultim faz, diferitele op iuni fcute de specialistul IS pe parcursul abstractizrii solu iei. Pentru a convinge cititorul asupra greut ii acestui principiu n IS, trebuie s l informm c, pornind de la o aceeai problem ntr-un fel arat solu ia dac este tributar obinuin elor de abordare specifice unui dezvoltator de baze de date, altfel arat solu ia dac este tributar obinuin elor de abordare ale analizei structurate .a.m.d. Alegerea tipului de model poate influen a semnificativ calitatea sistemului soft, costurile i beneficiile datorate utilizrii acestuia. Al doilea principiu Fiecare model poate fi exprimat la diferite nivele de abstractizare (precizie). Mesajul exact al acestui principiu poate fi n eles dac privim lucrurile din interiorul exigen elor unui laborator de modelare. Ca un exemplu n acest sens s ne amintim faptul c n IS un sistem soft, nainte de a ajunge n stadiul final de dezvoltare, trece prin mai multe nivele de abstractizare. Fiecare nivel de abstractizare con ine informa iile ateptate de o anumit categorie de participan i la dezvoltarea softului i reprezint un element-suport pentru gestiunea complexit ii procesului de abstractizare. Al treilea principiu Cele mai bune modele sunt modelele conectate la realitate. Mesajul de baz al principiului este simplu dar de mare utilitate: modela i transfigurnd realitatea modelat ct mai pu in. Problema transfigurrii realit ii modelate este n eleas mai uor dac ne punem ntrebri asupra modului n care domeniul problemei se mapeaz peste domeniul solu iei. Ideal este ca tehnica de modelare pe care o folosim s permit chiar maparea dup mai multe perspective dac acest lucru este benefic pentru procesul de modelare. Din nou fac trimitere la UML care institu ionalizeaz, aproape, cerin a conjugrii obiect-orientate cu abordarea multi-perspectiv. Al patrulea principiu: Un singur model nu este suficient. Fiecare sistem netrivial este cel mai bine aproximat de un set limitat de modele relativ independente. Sistemele netriviale sunt sisteme a cror complexitate trebuie structurat pentru ca modelul rezultat s ncapsuleze toat semantica relevant a sistemului modelat. Structurarea complexit ii sistemului modelat poate s nsemne i necesitatea ca sistemul modelat s fie descris din mai multe perspective, ob inndu-se astfel descrieri cu relativ autonomie semantic, care suprapuse (combinate) permit ob inerea unei imagini holografice asupra sistemului modelat.

Pun punct Capitolului 4 cu speran a c cititorul a n eles care sunt problemele n domeniul abstractizrii solu iei unui sistem soft i, de ce nu, va pune chiar umrul la clarificarea, la alt nivel de abstractizare, a acestor probleme.

Capitolul 5 Managementul proiectelor n industria softului

Succesul unei ac iuni depinde, esen ial, de modul n care i sunt gestionate problemele. nc mai exist manageri care viseaz cu ochii deschii c subalternii lor (ruina i, automotiva i, din patriotism i pe mai nimic) sunt gata n orice clip s mearg pn la sacrificiul suprem pentru salvarea incompeten ei efilor. Iertat fie nedumerirea ngrmdit n acest preambul de capitol. Un om se poate schimba nv nd i luptnd mpotriva obinuin ei. O echip, ai crei membri nu sunt clone ale unui aceluai prototip uman (deosebit din punct de vedere al calit ilor), are nevoie de conductor pentru a ajunge s func ioneze, ct de ct, ca un tot. n industria softului este nevoie de conductori care tiu managementul unei afaceri n genere i nc ceva pe deasupra. Acel nc ceva pe deasupra ne va interesa, cu predilec ie, n Capitolul 5.

5.1. Scurt introducere Nu este n inten ia acestei cr i s dezvolte teme ale teoriei managementului, n genere. Mult lume, ns, este convins de faptul c managementul proiectelor soft (MPS) i asum, ntr-un context particular, aceleai probleme i aceleai principii de baz pentru rezolvarea lor. De aceea nu mi se pare deloc o glum introducerea n planurile de nv mnt ale institu iilor de nv mnt superior care pregtesc specialiti IS a unor cursuri de ini iere n teoria managementului. Exist cel pu in dou motive pentru care este nevoie de o astfel de abordare. Aceste cunotin e i ajut pe managerii din industria softului s aib succes n afacerile pe care le conduc; Cunoaterea principiilor dup care se structureaz i se opera ionalizeaz managementul n cazul unei afaceri oarecare, este de mare utilitate pentru cei care, n definitiv, produc tehnologii informa ionale pentru a ntmpina o cerin de baz al actului de management: optimizarea fluxurilor informa ionale (vitez, calitate, spectru problematic). Practica demonstreaz destul de convingtor faptul c un specialist IS care lucreaz la solu ia unei probleme formulat de managementul unei afaceri, trebuie s intre metodic n semantica specific acestui management. n lipsa unui orizont minimal, specialistul va trebui s nve e ct mai multe dac nu vrea s bjbie pn la ob inerea solu iei tehnice. Cei p i i, dar i nep i ii, contientizeaz faptul c este greu s modelezi temeinic bazndu-te doar pe inspira ia de moment. Concretiznd, n fa a problemei realizrii unui sistem soft, managementul se lovete, n mod natural, de ntrebri de tipul: Ct va costa sistemul?, Cnd va fi terminat?. Acestea sunt doar dou din ntrebrile la care un rspuns corect este destul de dificil. Foarte multe proiecte "i-au dat bugetul ini ial de mai multe ori peste cap" i au fost finalizate mult timp dup termenul estimat al predrii. De aceea, printre obiectivele de baz ale MPS vom regsi: Planificarea sarcinilor proiectului; Estimarea succesului sau a eecului proiectului, raportat la planul de dezvoltare adoptat; Estimarea timpului i a for ei de munc necesare pentru finalizarea proiectului, ca ntreg i pe etape. 5.2. Teme fundamentale n managementul softului 5.2.1. Introducere Poate, cu riscul de a schematiza prea tare, voi ncerca s introduc cititorul n universul preocuprilor fundamentale ale unei persoane implicate n MPS. Aadar, pe lista subiectelor MPS vom regsi, n mod necesar, considera ii referitoare la: -dezvoltarea sistemelor soft (procese, activit i, management); -managementul riscului; -tehnici de reprezentare a MPS; -estimarea mrimii proiectelor;

-managementul calit ii. Fiecare dintre aceste subiecte ncearc s abstractizeze o categorie deosebit de probleme, abilitatea managerului fiind cea care va rezolva problema convertirii cunotin elor despre aceste subiecte ntr-o strategie coerent de conducere a proiectelor soft. Cititorul informat intuiete, probabil, c n industria sofutlui, la fel ca n orice alt domeniu de activitate, managementul se structureaz att pe vertical (ca urmare vom avea mai multe nivele de management) ct i pe orizontal (ca urmare, este plauzibil s avem mai multe arii de management). Amploarea procesului de structurare a managementului n industria softului depinde de complexitatea activit ilor desfurate i de atitudinea managementului de top fa de delegarea structural a competen elor manageriale. Ca de obicei, n IS, nu exist re ete infailibile nici n MPS. Se poate vorbi ns, despre exemple concrete de structurare a MPS i despre o anumit perspectiv asupra procesului de structurare a MPS. Exemplele concrete de structurare a MPS (veritabile studii de caz) pot oferi date interesante despre rela ia dintre anumite tipuri de procese i managementul asociat acestora. Aceste date pot fi valorificate efectiv dac se opera ionalizeaz, de exemplu, perspectiva asupra procesului de structurare a MPS prezentat n Figura 5.1.

Activitate de dzvoltare a softului cu obiective ini iale limitate.

Management cu structur simplificat.

Diversificare/complexificare a activit ii de dezvoltare a softului.

Restructurare sistem de management DA

NU

Exist indicii c performan ele actualului sistem de management sunt criticabile?

Figura 5.1. Dezvoltarea iterativ i incremental a managementului n industria softului

5.2.2. Dezvoltarea sistemelor soft din perspectiv managerial 5.2.2.1. Produse. Procese. Resurse. MPS manifest un interes deosebit fa de o serie de aspecte ale dezvoltrii softului care devin obiect de activitate pe toat durata dezvoltrii unui sistem soft. Astfel, din perspectiv MPS, dezvoltarea softului nseamn: -Produsele realizate; -Procesele desfurate; -Factorul uman implicat. Produsele realizate n timpul dezvoltrii softului n ceea ce privete produsele realizate n timpul dezvoltrii unui sistem soft, managementul are o atitudine, evident pragmatic, fiind preocupat de: cerin ele pe care acestea trebuie s le ndeplineasc; structura pe care acestea se bazeaz n timpul func ionrii. n ceea ce privete cerin ele, acestea pot fi: -cerin e func ionale (ce trebuie s fac sistemul?) -cerin e de calitate (ct de bine va lucra sistemul?) -cerin e n ceea ce privete resursele (ct va costa sistemul, n ultim analiz). Primele dou cerin e sunt i n aten ia MPS dar i preocup ndeosebi pe cei care lucreaz n analiz, proiectare i/sau programare. Al treilea tip de cerin este de competen a managementului, folosind, evident, datele furnizate de specialitii care lucreaz n analiz, proiectare, programare. Tot din punct de vedere al managementului este util s se tie, cu precizie, care sunt tipurile de documente care nso esc realizarea unui sistem soft. Aadar, din punct de vedere managerial, putem spune c un sistem soft nu se rezum doar la codul executabil al acestuia; el const dintr-o serie de documente care, n mod uzual, pot fi: -un document care cuprinde cerin ele fa de sistemul soft, cerin e care sunt rezultatul unui consens al tuturor celor interesa i, ntr-o form sau alta, n dezvoltarea sistemului soft; -documentul care descrie specificarea cerin elor, structurate la nivel de sistem i, respectiv la nivel de componente; -documentul care descrie solu ia tehnic a sistemului soft, elaborat n faza de proiectare, de obicei. Schematiznd, un astfel de document va con ine informa ii structurate astfel: descrierea solu iei sistemului soft ca ntreg; descrierea colec iilor de date; descrierea interfe ei cu utilizatorul;

descrierea prelucrrilor asociate func iilor sistemului soft. -codul surs al sistemului soft; -datele de test ale sistemului soft, structurate pe module i la nivelul sistemului ca ntreg; -documenta ia utilizator care nso ete sistemul soft; n aceast categorie putem include: ghidul de instalare a sistemului soft; manualul de referin al sistemului soft; sistemul de help on-line; suporturile de curs pentru instruire n utilizarea sistemului soft, etc. Toate aceste tipuri de documente trebuie realizate la standarde de calitate deosebite dac se dorete men inerea sistemului soft pe o traiectorie ascendent n topul preferin elor clien ilor. Este momentul s spunem c, vorbind despre clien i, din punct de vedere managerial acetia pot fi: clien i pentru care dezvoltm un sistem soft dedicat; clien i pentru care dezvoltm un sistem soft de interes general. S mai adugm faptul c, dintre toate documentele care nso esc realizarea unui sistem soft unele sunt destinate a fi livrate clientului, altele sunt pentru uzul intern al firmei productoare de soft. Procesele desfurate n timpul dezvoltrii softului Dac dorete s se implice n gsirea unui rspuns ct mai bun la ntrebarea Cum este realizat sistemul soft?, MPS trebuie s exercite un control metodic asupra modului n care se desfoar activit ile pe baza crora sunt realizate documentele men ionate mai sus, n acest paragraf. Ideea de control metodic poate avea n elesuri diferite pentru manageri diferi i. A sugera cititorului s priveasc aceast idee din perspectiv pragmatic: cel care investete n dezvoltarea unui sistem soft este preocupat ca procesul de dezvoltare a softului s fie structurat pe principii de eficien i calitate. Eficien a micoreaz costurile de produc ie, calitatea micoreaz costurile cu ntre inerea sau dezvoltarea. Iat motive destul de puternice pentru ca un manager s fie preocupat de con inutul unui proces de dezvoltare a softului. Din punct de vedere al managerului, problemele care apar n dezvoltarea softului se vd astfel: 1.Deoarece producerea unui document este posibil ca urmare a unei activit i specifice, ntregul proces de dezvoltare a softului va fi ntotdeauna o sum de activit i care de fapt formeaz un sistem de activit i, dac lum n seam nenumratele interdependen e dintre acestea.

2.Activit ile de dezvoltare tipice pentru un sistem soft ar putea fi considerate: analiza cerin elor; specificarea formal a sistemului i a pr ilor acestuia; proiectarea arhitecturii sistemului i a componentelor acestuia; implementarea sistemului; testarea componentelor sistemului; integrarea componentelor n sistem i testarea sistemului; scrierea manualelor i a altor tipuri de documenta ii utilizator; instalare sistem; ntre inerea sistemului pe timpul exploatrii. Deducem c este sarcina MPS s defineasc procesele de dezvoltare pentru a indica: -care sunt documentele i produsele care urmeaz a fi realizate; -ce activit i vor fi desfurate; -cnd va primi clientul documentele i produsele pe care le ateapt; -cnd vor fi desfurate activit ile. De aceea este imperios necesar ca activit ile de dezvoltare s fie organizate, ceea ce implic desfurarea unor activit i adi ionale procesului de dezvoltare a softului. Aceste activit i adi ionale dau consisten unui proces paralel cu procesul de dezvoltare a softului: procesul de management al proiectului de realizare a unui sistem soft. Am vzut c activit ile de dezvoltare au ca rezultat o mare varietate de documente. Activit ile de management au ca rezultat esen ial planurile pe baza crora se desfoar activit ile de dezvoltare. Prevederile i implica iile acestor planuri sunt negociate cu clientul, deoarece con in multe elemente de interes pentru acesta (resurse, termene de execu ie, etc.). Factorul uman implicat n dezvoltarea sistemelor soft Proiectele soft de medie i mare complexitate presupun o participare semnificativ din punct de vedere al factorului uman. M refer, n primul rnd, la specialitii n IS care se implic n desfurarea activit ilor de dezvoltare. Atunci cnd se lucreaz n echip la rezolvarea unei probleme, gestiunea rela iilor dintre membrii echipei devine o problem important. Aa cum ne nva tratatele de management ntre membrii unei echipe de dezvoltare pot apare: rela ii profesionale (de colaborare sau de subordonare), rela ii de natur general-uman (simpatie, antipatie, indiferen , etc.), rela ii legate de partajarea unor resurse comune (ncperile n care se lucreaz, grupurile sanitare, biblioteca, etc.) .a.m.d. Este sarcina managerului s gseasc solu iile cele mai simple pentru optimizarea func ionrii acestui complex de rela ii. Evident, managementul este interesat, n primul rnd, de eficientizarea rela iilor profesionale. De aceea, managementul proiectelor soft va propune un model de organizare a

membrilor unei echipe de dezvoltare. Cu toate c mai exist i vistori care vd o echip de proiectare ca o sum natural de preocupri convergente, practica recunoate ca valabile modelele ierarhice de organizare. Astfel c este posibil un model de organizare a membrilor unei echipe de dezvoltare, pentru un proiect mare, ca n Figura 5.2. Un astfel de model ncapsuleaz, evident, o serie de elemente birocratice, indispensabile pentru bunul mers al activit ilor ntr-o echip de dezvoltare. Tot managementul este cel care trebuie s gseasc cea mai corect dimensionare a structurii birocratice a unui proiect, n func ie de mrimea proiectului i priorit ile acestuia. O astfel de structur birocratic este necesar pentru a asigura, i din punct de vedere managerial, abstractizarea efortului de dezvoltare a unui sistem soft. Pentru o mai bun n elegere a rolului managementului n dezvoltarea sistemelor soft, n paragraful 5.2.2.2 voi face o scurt trecere n revist a ideilor de baz ale teoriei generale a managementului din perspectiv informa ionial.
Manager de proiect

Colectiv de asigurare a calit ii

Colectiv de verificare i validare

Colectiv de modelare a solu iei

Colectiv de programare

Colectiv pentru asigurarea suportului hard

Integrare

Subsistem 1

.......

Subsistem n

Figura 5.2 Model ierarhic, ipotetic, de organizarea a membrilor unei echipe de proiectare 5.2.2.2. Informa ie i management Sistemele informa ionale pot mbunt i considerabil procesul de elaborare a deciziilor manageriale. Veritabila industrie de sisteme informa ionale bazate pe calculator a impus concepte precum: sisteme de management informa ional (SMI) i sisteme informa ionale executive (SIE). Semnifica ia precis a acestor concepte o voi prezenta n cele ce urmeaz. Informa ia i func iile managementului Managementul este, n general, descris ca un proces de conducere care implic urmtoarele func ii: planificarea, organizarea, coordonarea i controlul. Aceste func ii ale managementului au fost identificate i expuse pentru prima dat de ctre Henri Fayol, un pionier al teoriei managementului din Fran a. Planificarea Ca func ie a managementului, planificarea presupune estimarea evolu iei proceselor i fenomenelor viitoare, respectiv, a efectelor pozitive i negative pe care aceasta le poate genera asupra sistemului condus. Tot de previziune ine i capacitatea managementului de a pregti din timp strategii i scenarii de ac iune pentru minimizarea riscurilor i maximizarea gradului de realizare a obiectivelor urmrite.

Organizarea Ca func ie a procesului de management, organizarea definete ansamblul proceselor de conducere prin intermediul crora se divizeaz activitatea sistemului condus, stabilindu-se i delimitndu-se subactivit ile i sarcinile corespunztoare acestora. Altfel spus, organizarea nseamn gruparea dup criterii de func ionalitate i eficien a sarcinilor i delegarea responsabilit ii necesare ndeplinirii lor. Coordonarea Ca func ie a procesului de management, coordonarea const n ansamblul proceselor prin care se sincronizeaz deciziile i ac iunile personalului unui sistem organiza ional (n cadrul previziunilor i organizrii anterior stabilite), cu scopul asigurrii resurselor necesare, n timp util, de calitatea stabilit i n cantitatea dorit, pentru atingerea obiectivelor sistemului organiza ional. ndeplinirea acestei func ii a sistemului de management este posibil cu ajutorul unui sistem de comunicare adecvat la toate nivelele de management. Controlul Prin control desemnm ansamblul proceselor de urmrire a modului n care se desfoar diferite ac iuni sau ntreg procesul de management, ct i de reglare a activit ilor organiza iei prin gsirea unor metode eficiente de identificare i eliminare a efectelor perturba iilor aprute n func ionarea sistemului. Schematiznd i dezvoltnd pu in subiectul avem Figura 5.3. Cititorul are ocazia s-i formeze o imagine ceva mai cuprinztoare asupra dificult ilor meseriei de manager. Pe lng faptul c pretinde competen , uneori interdisciplinar, pentru a men ine n echilibru diferitele tendin e care se pot manifesta la nivelul sistemului condus i la diferite niveluri de management, meseria de manager este marcat de numeroase responsabilit i, att fa de indivizii sau grupurile profesionale conduse ct i fa de organiza ie n ansamblu. Poate c, n acest moment, cititorul i-a modificat oarecum atitudinea i fa de MPS. Pentru a nu eua, un proiect soft are nevoie de un management eficient, elastic, corect dimensionat. Toate aceste calit i ale actului de management(eficient, elastic, corect dimensionat) depind de virtu ile sistemelor informa ionale pe care se bazeaz managementul. Dintre componentele sistemelor informa ionale un rol esen ial l joac, dup cum am ami spus SMI, SAD, SIE. SMI (Sistemele de management informa ional) Numite n diferite lucrri i sisteme de raportare a informa iilor, aceste sisteme au fost primul tip de sistem informatic-suport pentru actul de management. SMI produc date i informa ii necesare pentru fundamentarea multora dintre deciziile zilnice ale managerilor. Beneficiari obinui i ai SMI: managerii de nivel tactic i opera ional. SAD (Sistem de asistare a deciziilor) Sunt sisteme de informare bazate pe calculator care furnizeaz suport informa ional interactiv managerilor n timpul procesului de elaborare a deciziilor. Astfel de sisteme pot folosi: modele analitice, baze de date specializate, sisteme expert, etc. Beneficiari obinui i ai SAD: managerii de nivel tactic i strategic.

Planificarea Stabilire obiective i dezvoltare strategii i tactici

Organizarea Delegarea responsabilitiilor la nivel de individ i de grup

Coordonarea Conducerea personalului prin motivare i comunicare

Controlul Evaluarea i ajustarea performan elor organiza ionale Figura 5.3.a Func iile managementului

Interpersonal
Leader profesional Legtur cu mediul Leader formal

Informa ional
Supervizor Difuzor Leader de opinie

Decizional
Antreprenor Gestiune conflict Alocare resurse Negociere

Figura 5.3.b Rolurile managementului

Management strategic

Planificare i control al ac iunilor de interes general; competen a managerului de top Planificare i control al ac iunilor la nivelul subunit ilor componente; competen a managerului mediu

Management tactic

Management operativ Date i informa ii

Planificare i control al opera iilor zilnice; competen a managerilor care au contact direct cu nivelul operativ

Figura 5.3.c Niveluri de management

SIE (Sisteme informa ionale executive) Sunt sisteme informa ionale care combin multe dintre nsuirile SIM i SAD. Atunci cnd au fost dezvoltate pentru prima dat, SIE au fost focalizate pe ideea de asigurare a managerilor de nivel top cu informa ii strategice. Astfel de sisteme trebuie s permit managerilor de top un acces rapid la informa ii despre factorii de succes critici din perspectiva ndeplinirii obiectivelor asumate de organiza ie. n lucrarea [11] subiectul de fa este amplu dezvoltat i, ceea ce este important, dintr-o perspectiv pregnant pragmatic, ceea ce l ajut pe cititor s n eleag mai bine rela ia dintre informa ie i management care, n alt plan este nimic altceva dect rela ia dintre informa ie i putere. nchei aici mica incursiune n lumea managementului, invitnd cititorul s-i completeze cultura i cu o serie de cunotin e care ar putea s fac lumin ntr-o zon n care, altfel, poate bntui improviza ia. Cu perspectiva asupra managementului modificat n acord cu cele spuse n 5.2.2.2, putem aborda probleme cheie ale MPS ca n paragraful 5.2.2.3. 5.2.2.3. Esen ial i la obiect despre MPS Aadar, MPS este un caz particular de management de proiect, care la rndul lui este un caz particular de management n genere. Prin urmare, putem defini MPS rspunznd la ntrebrile: 1. Ce activit i desfoar managerii n industria softului? 2. Ce rol joac managerii ca i componente ale MPS? Rspunsul la aceste ntrebri mi cere s precizez urmtoarele: Activit i desfurate/competen e ale managerilor: -Planificarea (=stabilire obiective i organizarea modului de ndeplinire a acestora); -Urmrirea evolu iei proiectului prin msurarea progreselor realizate n raport cu planul; -Efectuarea corec iilor necesare pentru ca evolu ia proiectului s aib o curb ascendent, n limitele planului stabilit; -Tratarea excep iilor, adic efectuarea unor corec ii majore la planul de execu ie pentru a evita un posibil eec al proiectului. Aceste tipuri de activit i sunt desfurate la diferite nivele de management: -la nivel strategic (privesc ntreaga firm de dezvoltare a softului, pe o perioad de cteva luni sau chiar mai mult); -la nivel de proiect (privesc derularea unui proiect, n acord cu termenele de execu ie asociate); -la nivel de echip de proiectare (privesc o faz n dezvoltarea unui sistem soft); -la nivel individual (privesc desfurarea activit ilor la nivel individual de pe o zi pe alta).

Aspectele fundamentale pe care se structureaz aceste activit i sunt: resursele; este vorba, n principal, de utilizarea celei mai importante resurse n IS, timpul de lucru al specialitilor IS; deci, clasica, de-acum, problem: cine, ce i unde face?. calitatea; este vorba de calitatea sistemului soft n curs de dezvoltare, adic, trebuie clarificat care sunt obiectivele urmrite din acest punct de vedere i care sunt modalit ile de ndeplinire a acestor obiective. riscurile; este vorba de apari ia unor situa ii care pot afecta evolu ia corect a proiectului; din punctul de vedere al managementului, problema este: -cum pot fi identificate aceste situa ii? i -cum pot fi prevenite aceste situa ii? Dezvoltarea sistemelor soft folosete intens capacit ile explicative i de reprezentare ale modelelor: -diferite modele pentru structura i propriet ile produselor realizate n timpul dezvoltrii sistemului soft; -diferite modele pentru structura i propriet ile proceselor specificate n diferite planuri de dezvoltare. La fel ca i n alte domenii, se face uz de dou tipuri fundamentale de modele: -modele calitative i -modele cantitative. Modelele calitative (indiferent dac este vorba de produse sau procese) sunt utilizate pentru descrierea structurii acestora n termeni de componente i rela ii ntre componente. Modelele calitative pot admite mai multe tipuri de reprezentri (de tip diagram cazul UML, matematizate grafuri sau arborescen e, formale codul surs ntr-un limbaj de programare). Sunt posibile, dac se pltete tributul necesar rigorii, transformri de la o reprezentare la alta, dac acest lucru este n beneficiul evolu iei spre succes a proiectului. Modelele cantitative i propun cuantificarea atributelor msurabile ale produselor sau proceselor, precum i a interac iunilor dintre acestea. Efectiv, aceste modele se reduc la diferite tipuri de ecua ii matematice. n managementul proiectelor, modelele calitative sunt folosite pentru a descrie: -cum este compus procesul de dezvoltare din activit i; -ce documente produce un proces i ce documente sunt necesare pentru a desfura un proces; -cum se constituie ntr-o faz activit ile care coopereaz pentru a produce un produs livrabil ctre un anume tip de client;

-cum se nln uie fazele pentru a forma un proces complet. De asemenea, se poate spune c, n managementul proiectelor modelele cantitative sunt folosite pentru a descrie: -atributele care msoar calitatea i resursele implicate n dezvoltarea unui sistem soft; -cum pot fi estimate valorile acestor atribute la nceputul proiectului; -cum pot fi actualizate valorile acestor atribute n timpul derulrii proiectului pentru a men ine un trend favorabil ndeplinirii obiectivelor proiectului. Putem aborda acum i subiectul numit n MPS Planificarea ini ial a unui proiect. Este o activitate deosebit de important a managementului care trebuie abordat cu maxim profesionalism. Multe dintre deciziile care determin succesul unui proiect depind de calitatea planificrii ini iale. Abordarea corect a acestui subiect presupune: 10 Stabilirea obiectivelor Obiectivul fundamental al unui proiect de dezvoltare a softului este realizarea unui sistem care corespunde cel pu in cerin elor clien ilor. Spun cel pu in clien ilor (care corespund, dup cum am vzut n Capitolul 1, factorilor externi ai calit ii unui sistem soft i nu numai) deoarece exist i cerin e fa de sistemele soft care in de exigen ele de natur intern, asumate de specialitii IS n procesul de modelare. n mod uzual, obiectivul fundamental descris mai sus are trei subobiective importante: obiective sistem ce servicii ateapt clientul de la sistem astfel nct s rezulte i nite beneficii; costurile asociate dezvoltrii i folosirii sistemului soft; efectele secundare ale utilizrii sistemului soft alte avantaje pe care clientul le poate avea dac utilizeaz sistemul soft. Problema derivat din ncercarea de stabilire a obiectivelor unui sistem soft este urmtoarea: de multe ori clientul nu poate defini exact propriile lui cerin e, ceea ce, mai devreme sau mai trziu, poate afecta proiectul. De asemenea, la stabilirea obiectivelor nu trebuie uitat faptul c este dreptul clientului s atepte beneficii din utilizarea sistemului soft care depesc costurile de dezvoltare i utilizare. 20 Planificarea ini ial n acord cu cele spuse relativ la stabilirea obiectivelor, planificarea ini ial va ncerca s determine ct mai exact: -ce produse trebuie livrate clientului pentru a garanta ndeplinirea obiectivelor asumate; -ca urmare, ce activit i sunt necesare; -n consecin , ce documente trebuie realizate n aceste activit i; -n sfrit, ce alte activit i sunt necesare pentru a produce aceste documente.

Oriunde exist dubii, acestea pot fi tratate n aceast etap prin categorisirea articolelor (documente, activit i, func ii, etc.) ca fiind: -imperative (aceste articole sunt neaparat necesare pentru ntmpinarea cerin elor clientului); -de dorit (aceste articole ar putea fi foarte folositoare, dar este posibil satisfacerea cerin elor clientului i fr producerea lor); -op ionale (aceste articole pot fi folositoare, dar, n mod sigur, este posibil satisfacerea cerin elor importante ale clientului fr ele. Rezultatul planului ini ial va fi o list care cuprinde: -activit ile posibile; -documentele care vor fi livrate clientului; -documentele interne; -clasificarea acestora dup importan a lor pentru proiect. 5.2.3. Managementul riscului 5.2.3.1. Dereglare i risc Din activitatea cotidian a unui angajat al unei firme este cunoscut faptul c treburile nu merg ntotdeauna cum i-ar dori acesta. Lipsa de organizare sau presiunea exercitat asupra activit ii de factori aleatori pot provoca dereglri (incidente, disfunc ii) ale acestei activit i. Voi numi dereglare orice situa ie care poate apare n desfurarea unei activit i i care dac nu este combtut de management poate aduce prejudicii desfurrii activit ii conform planului. Trivial, dar trebuie spus c orice dereglare are circumstan e care o produc (=cauze) i rezultate n caz de ignorare a dezvoltrii dereglrii (=efecte). Evident, este de competen a managerului s identifice cauzele dereglrii pentru a ac iona asupra lor. Este cunoscut prostul exemplu dat de unii manageri care se lupt cu efectele deoarece n elepciunea i competen a pe care o au nu i ajut s ob in o reprezentare ct mai precis asupra cauzelor dereglrii. Se numete risc n procesul de management orice dereglare care reprezint o amenin are la adresa ndeplinirii obiectivelor esen iale ale unui proiect. n IS, obiectivele esen iale ale unui proiect pot fi: cerin ele fa de sistem, costurile estimate ale ntregului ciclu de via , etc. n acest moment putem observa c, odat aprut un risc n procesul de management, atunci acesta implic: -o dereglare a unei activit i;

-probabilitatea ca dereglarea s apar (altfel spus, probabilitatea de manifestare a cauzelor apari iei dereglrii); -impactul pe care dereglarea l va avea asupra succesului proiectului, dac apare (cu alte cuvinte, msura efectelor dereglrii asupra activit ii). Din punct de vedere al tipului de impact putem vorbi despre: -riscuri binare (la care efectele sunt pe principiul totul sau nimic); -riscuri scalate (la care efectele dereglrilor asociate pot varia pe o scal valoric dat); deci sunt riscuri cu manifestare gradat dup circumstan ele n care apare i se dezvolt o anumit dereglare. Motivul pentru care managementul unui proiect este pndit de riscuri are o explica ie foarte simpl: lipsa informa iilor sau cunotin elor relativ la ceea ce urmeaz s se ntmple n evolu ia proiectului. Altfel spus, n timpul dezvoltrii unui proiect putem s ne confruntm cu evenimente, practic, nepredictibile dar i cu evenimente care pot fi puse pe seama lipsei de informare. Aadar, putem vorbi despre evenimente incerte sau despre estimarea incert a propriet ilor evenimentelor. Ca un exemplu, n IS este uzual ca specialitii s vorbeasc astfel: -S-ar putea ca cerin ele fa de sistemul soft s se schimbe; -S-ar putea ca unii membri ai echipei s fac grip la iarn; -S-ar putea s nu se gseasc pe pia un anume echipament, la pre ul scontat. Toate aceste posibilit i descriu nite evenimente incerte. Tot aa de bine, specialitii IS se pot exprima astfel: -Nu tim ct poate dura ini ierea utilizatorilor n folosirea sistemului soft; -Nu avem date despre performan ele echipamentului cutare. n ambele situa ii prezentate mai sus, datele exist pe undeva dar nu au ajuns singure la urechea celor interesa i. 5.3.2.2. Identificarea riscurilor n IS Att teoreticienii (care nainte de a ajunge teoreticieni au fost buni practicieni) ct i marea parte a practicienilor sunt contien i de numeroasele riscuri pe care le presupune dezvoltarea unui sistem soft. n IS, am mai spus-o i altundeva n carte, ne aflm pe un teren minat. Bucuria de a izbuti n fa a unei provocri a proiectului poate fi uor umbrit de o ncercare neateptat. Faptul c multe proiecte importante au euat datorit modului superficial n care au identificat i cuantificat riscurile arat importan a cunoaterii acestor riscuri. Cauze comune ale riscurilor n dezvoltarea sistemelor soft sunt: cerin ele fa de sistemul soft sunt neclare sau susceptibile de a fi modificate;

utilizarea unor tehnologii noi fr a avea cunotin ele i deprinderile necesare; dificult i n estimarea timpului de execu ie i a altor resurse necesare; dificult i n estimarea performan elor sistemului; ncrederea oarb n furnizorii de componente i n posibilitatea de a termina proiectul cu indivizi cu abilit i ndoielnice; lipsa standardelor i a unor reguli minimale de urmat n procesul de dezvoltare a softului. ncercnd o clasificare a acestor cauze, oarecum, dup originea lor, avem: Cauze care pot fi puse pe seama clientului -necunoaterea cerin elor proprii fa de sistemul soft; -neimplicarea corect i efectiv n efortul de dezvoltare a proiectului; -necunoaterea clar a beneficiilor i costurilor proiectului. Cauze care pot fi puse pe seama mediului n care va lucra sistemul soft -nivel de organizare deficitar; -probabilitate mare de producere a unor schimbri majore. Cauze care pot fi puse pe seama tehnologiei folosite -aceasta nu furnizeaz facilit ile cerute de dezvoltarea sistemului; -aceasta nu are suficient performan n raport cu obiectivele sistemului. Cauze care pot fi puse pe seama resurselor disponibile -nu exist timp suficient pentru proiect; -oamenii implica i n proiect sunt insuficien i; -echipamentele disponibile pentru proiect sunt insuficiente sau uzate moral. Cauze care pot fi puse pe seama echipei de dezvoltare -necunoaterea tehnologiilor; -necunoaterea metodologiei de dezvoltare; -incapacitatea de a rezolva probleme punctuale; -dependen a exagerat de anumi i membri ai echipei. Toate motivele de ngrijorare reprezentate de aceste cauze (i nc multe altele) este bine s fie luate n serios de managementul unui proiect de sistem soft care trebuie s procedeze metodic i n problema riscurilor asociate proiectului, adic: -identificnd riscurile i clasificndu-le; -descriind riscurile pn la un nivel la care cauzele care le produc devin clare; -cuantificnd riscurile (probabilitatea de apari ie i mrimea impactului n caz de apari ie).

5.2.3.3. Reducerea riscului n MPS Evident c n fa a amenin rilor de tot felul la adresa succesului unui proiect, managementul trebuie s ia msuri de reducere a riscului de manifestare a acestor amenin ri. Deoarece trebuie s fie foarte clar pentru managerii din IS, voi sublinia, nc odat, ideea c: Managementul unui proiect de dezvoltare a unui sistem soft trebuie s desfoare o activitate metodic pentru reducerea riscurilor care pot prejudicia succesul proiectului. Ce poate face managementul n acest scop? Cteva direc ii de ac iune ar putea s fie: Ob inerea de informa ii pentru a diminua impactul necunoscutului asupra anselor de reuit ale proiectului prin: -organizarea de experimente i efectuarea de msurtori; -efectuarea de cercetri i construirea de modele; -construirea i evaluarea unor prototipuri, etc. ncercarea de a preveni evolu ia riscurilor prin: -contientizarea oamenilor-cheie ai proiectului asupra amenin rilor la adresa proiectului; -proiectarea i implementarea unor procedee de monitorizare a activit ilor; -perfec ionarea profesional a membrilor echipei. Mandatarea ctre un grup specializat a problemei managementului riscurilor unui proiect. A aminti cititorului c exist metodologii de dezvoltare a softului care se autointituleaz risk-driven (deci pun n centrul aten iei preocuparea de a diminua riscurile la care poate fi expus un proiect). A aminti n acest sens modelul spiralei (Boehm i Papaccio). Ca un fel de concluzie a paragrafului 5.2.3 voi spune c planul de dezvoltare a unui sistem soft poate fi modificat semnificativ n bine dac managementul i exercit cu abilitate i func ia de gestiune a riscurilor care pot amenin a succesul unui proiect. Dac managementul unui proiect n elege rolul conducerii preventive printre amenin rile naturale la adresa proiectului, atunci costurile, termenele de livrare i calitatea sistemului soft pot fi salvate de la abateri nedorite. 5.2.4. Tehnici de reprezentare a MPS Managerul unui proiect, n general, managerul unui proiect de dezvoltare a unui sistem soft, n particular, dispun de numeroase tehnici pentru reprezentarea i descrierea planurilor de proiectare. Cititorul a n eles, probabil, faptul c unul dintre rezultatele importante ale activit ii managementului n IS este reprezentat de planurile de dezvoltare. Pentru reprezentarea acestor planuri se folosesc modele de tip re ea sau diagrame Gantt. Toate aceste tipuri de reprezentare urmresc, n esen , acelai lucru: identificarea aspectelor critice ale planurilor de dezvoltare cu scopul de a focaliza aten ia managementului asupra acestor aspecte.

nainte de a trece la descrierea succint a tehnicilor de analiz a drumurilor critice ale unui plan de dezvoltare trebuie s informez cititorul c exist sisteme soft dedicate asistrii managementului proiectelor n general (CA Super-Project, Rational Rose). 5.2.4.1. Analiza drumului critic Tehnica cunoscut sub denumirea CPA (prescurtare de la Critical Path Analysis) a fost dezvoltat la sfritul anilor 50 pentru a fi folosit n dezvoltarea unor proiecte mari ale marinei americane. La origine, cunoscut ca metoda PERT (Project Evaluation and Review Technique), mai este numit i analiza de tip re ea, fiind folosit intens n nenumrate proiecte. Istoricul CPA i PERT arat c PERT este mai elaborat dect CPA. n esen , ns, ambele abordri folosesc pentru reprezentarea proiectelor concepte precum activit ile i evenimentele. Terminarea unei activit i echivaleaz cu producerea unui eveniment n mersul proiectului. Un astfel de eveniment mai este desemnat i ca reper (milestone n englez) n dezvoltarea proiectului. Fiecare reper reprezint nceputul unor activit i care sunt direct dependente de terminarea activit ilor precedente. Deoarece pentru prezentarea ideilor de baz ale analizei de tip re ea m voi limita la semantica CPA, voi mai spune c CPA se bazeaz pe analiza dependen elor secven iale ntre activit i i folosete durata estimat pentru fiecare activitate cu scopul de a deduce o estimare a duratei proiectului. De asemenea, CPA permite identificarea dependen elor dintre activit i care sunt critice pentru evolu ia proiectului. Etapele care trebuie parcurse pentru a elabora o analiz CPA sunt prezentate mai jos. Etapa 1 Tabelarea tuturor activit ilor i reperelor proiectului Aceast etap presupune ntocmirea de tabele care con in informa ii similare celor prezentate n Figura 5.4. Activitate A B C D E F G H I Descriere Interviuri utilizator Pregtire contracte de utilizare Rafinare contexte de utilizare Schimabre ecrane interfa utilizator Rafinare proiectare ecrane utilizator Identificare clase Analiza rela iilor dintre clase Schi are diagram clase Rafinare diagram clase Reper 2 3 4 5 6 7 8 9 10 Durata Activit i precedente estimat 5 u.t. 2 u.t. A,B C D C F F G,H 2 u.t. 2 u.t. 2 u.t. 2 u.t. 4 u.t. 5 u.t. 4 u.t. Personal necesar 2 Cel de la A 3 2 2 3 3 3 4

Figura 5.4. Un exemplu de proiect de activit i n IS

Etapa 2 Determinarea dependen elor dintre activit i Anumite activit i nu pot ncepe pn cnd altele nu s-au terminat. Predecesorii activit ilor sunt reprezenta i n coloana patru a tabelului de tipul celui din Figura 5.4. Ca un exemplu, activitatea rafinare contexte de utilizare trebuie s fie terminat nainte de a trece la identificarea claselor. Etapa 3 Estimarea duratei fiecrei activit i Pentru rezolvarea acestei probleme exist mai multe abordri datorit elementelor incerte implicate n estimarea duratei activit ilor. Una dintre cele mai mult folosite formule este:
ED = MOT + (4 * MLT ) + MPT 6

unde: -ED este durata estimat a activit ii (Expected Duration); -MOT este aprecierea cea mai optimist asupra duratei activit ii (Most Optimistic Time); -MLT este aprecierea cea mai probabil asupra duratei activit ii (Most Likely Time); -MPT este aprecierea cea mai pesimist asupra duratei activit ii (Most Pessimistic Time). Odat calculat durata estimat a unei activit i, aceasta este trecut n coloana 5 a unui tabel asemntor celui din Figura 5.4. Etapa 4 Elaborarea diagramelor CPA Exist dou stiluri principale de nota ii utilizate n elaborarea diagramelor CPA, desemnate prin activit i n nod sau activit i pe muchii. Amndou tipurile de nota ii folosesc acelai tip de informa ii dei arat diferit. n cele ce urmeaz voi adopta solu ia activit i pe muchii. n aceast variant fiecare reper este reprezentat printr-un cerc cu trei compartimente. Un compartiment este etichetat cu numrul reperului iar celelalte dou vor indica termenul cel mai devreme de ncepere a activit ii (TDI), i, respectiv, termenul cel mai ntrziat de ncepere a activit ii (TII). Ilustrm cele spuse n Figura 5.5.
Numr reper Termenul cel mai devreme de ncepere pentru activitatea D Etichet activitate

11 15

D 7
Durat activitate

18 24

Termenul cel mai ntrziat de ncepere pentru activitatea D

Figura 5.5. Exemple de nota ie CPA

Diagrama CPA, par ial completat, relativ la datele indicate n Figura 5.4. este prezentat n Figura 5.6. Voi face cteva observa ii relativ la Figura 5.6. Mai nti, acolo unde apar sge i punctate spunem c avem activit i fictive, a cror durat este 0. Astfel de activit i fictive sunt dictate de ra iuni de tipul: Conform datelor din Figura 5.4. activit ile G i H depind de terminarea activit ii F (reperul 7); De asemenea, G i H sunt predecesori pentru I (reper 9, unde ncepe activitatea I). Deoarece nu este obligatoriu ca G i H s se termine n acelai timp, fiecare activitate are nevoie de reper separat.
2 B 2 1 0 A 3 5 5 C 4 2 7 2 D 2 F 7 2 9 G 4 8 13 activitate fictiv H 9 5 14 I 4 10 18 5 9 E 6 2 11

Figura 5.6. Diagrama CPA par ial completat pentru un exemplu din Figura 5.4. Practic, activitatea fictiv n discu ie face legtura necesar ntre reperele 8 i 9. Etapa 5 Completarea datelor de tip TDI i TII pentru fiecare reper Pentru completarea cu date de tip TDI a diagramei CPA se folosete procedeul mersului nainte prin diagram, de la reperul considerat de start pn la reperul final i completarea cu date astfel: 1)TDI pentru reperul de start, n mod conven ional este 0. 2)Pentru reperele care au un singur predecesor valoarea TDI se ob ine prin nsumarea la valoarea TDI a predecesorului, a duratei estimate a activit ii acestor repere; 3)Pentru reperele care au mai mul i predecesori valoarea TDI se ob ine prin nsumarea la valoarea TDI cea mai mare (din lista valorilor TDI ale predecesorilor) a duratei estimate a activit ii asociate alegerii respective. 4)Evident, nainte de a calcula valoarea TDI pentru un reper, valorile TDI pentru to i predecesorii trebuie s fie deja calculate. Urmnd o astfel de procedur s-au ob inut valorile TDI n diagrama CPA din Figura 5.6. Pentru completarea cu date de tip TII a diagramei CPA se folosete procedeul mersului napoi prin diagram, de la reperul considerat final pn la reperul de start i completarea cu date astfel: 1)TII pentru reperul final este considerat, conven ional, egal cu TDI al acestui reper;

2)Pentru toate reperele care au un singur succesor, valoarea TII se ob ine scznd din valoarea TII a succesorului (deja calculat) durata activit ii corespunztoare; 3)Pentru reperele care au mai mul i succesori se fac toate diferen ele dintre TII ale succesorilor i duratele activit ilor asociate, alegndu-se ca valoare pentru TII ale reperelor n cauz, diferen a cea mai mic; 4)Din nou se presupune c, ajungnd s calculm valoarea TII a unui reper, to i succesorii au fost deja examina i. Forma complet a diagramei CPA prezentat n Figura 5.6. o avem n Figura 5.7.
2 B 2 1 0 0 A 3 5 5 5 C 2 4 7 7 2 5 5 D 2 F 2 7 9 9 G 4 8 13 14 H 5 9 14 I 14 4 10 18 18 9 16 E 6 2 11 18

Figura 5.7. Diagrama CPA complet pentru exemplul prezentat n Figura 5.4. Etapa 6 Identificarea drumului critic Dup completarea cu valori a etichetelor TDI i TII ale reperelor se poate calcula timpul de ateptare al reperelor ca diferen dintre TDI i TII. Aceast diferen reprezint timpul cu care o activitate poate fi ntrziat fr a provoca probleme de ncadrare n grafic celorlaltelor activit i ale proiectului. O succesiune de repere pentru care diferen ele ntre TDI i TII sunt 0 se numete drum critic. n Figura 5.7. activit ile care apar in unui drum critic au muchiile marcate cu o bar vertical dubl. Drumurile critice re in, n mod deosebit aten ia managementului unui proiect, datorit faptului c orice ntrziere pe o traiectorie critic poate afecta evolu ia proiectului. 5.2.4.2. Diagrame Gantt Aceste diagrame (denumite astfel dup inventatorul lor Henry Gantt) reprezint o tehnic extrem de simpl i eficient de reprezentare a ealonrii n timp a activit ilor unui proiect. Tehnica folosete barele orizontale pentru a reprezenta activit ile proiectelor. ntr-o astfel de diagram axa orizontal reprezint timpul, fiind etichetat cu repere de tip unit i de timp (ore, zile, sptmni) fcnd mai uoar urmrirea evolu iei proiectului n timp. Activit ile sunt aezate pe vertical, imediat n stnga diagramei, de sus n jos. Lungimea barei asociate fiecrei activit i n diagram este propor ional cu durata activit ii. S mai adugm faptul c diagramele Gantt arat n mod foarte sugestiv care sunt timpii de ateptare asocia i activit iilor i pot, de asemenea, da informa ii cu privire la alocarea n timp a resursei personal. Prezentm exemplul din Figura 5.4. din perspectiva diagramelor Gantt, n Figura 5.8.

5.2.4.3. Alte precizri asupra problemei reprezentrii planurilor de dezvoltare a sistemelor soft MPS are nevoie de o logistic de calitate pentru a monitoriza evolu ia activit ilor unui proiect din mai multe considerente, dintre care voi enumera cteva n continuare: 1.Prin utilizarea tehnicilor de reprezentare de tip CPA sau diagrame Gantt (DG) func ia de control a managemenrului are o foarte solid fundamentare metodologic. Se elimin controlul dup ureche sau bazat pe intui ia genial a managerului de proiect. 2.Prin utilizarea tehnicilor CPA sau DG riscurile rezultate din planificare pot fi estimate i, ca atare, se pot lua din timp msuri de diminuare sau eliminare a acestora. 3.Prin utilizarea tehnicilor CPA sau DG se instituie un cadru sistematic pentru controlul diferitelor tipuri de resurse ale proiectelor (personalul uman i productivitatea acestuia). 4.O planificare riguroas dar echilibrat influen eaz hotrtor costurile unui proiect. 5.Utilitatea acestor tehnici depinde de acurate ea instrumentelor cu ajutorul crora se stabilesc duratele activit ilor i necesarul de personal pe activitate. Aceste elemente se ob in cu ajutorul altor tehnici (metrici), a cror importan o subliniez, dar informez cititorul c n aceast carte nu voi dezvolta acest subiect.
Activit i Numr angaja i A B C D E F G H I 3 3 2 2 3 3 3 4 ZILE Numr de angaja i

10 9 8 7 6 5 4 3 2 1

ZILE
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Figura 5.8. Diagram Gantt a activit ilor i pentru alocarea angaja ilor pe activit ile proiectului

Voi atrage, totui, aten ia cititorului c este vorba despre metode de estimare a mrimii proiectelor (gen COCOMO), nc controversate, deci nc insuficiente din punct de vedere al obiectivit ii tiin ifice. Cititorul trebuie s mai afle, n ncheiere, c subiectul managementului proiectelor soft i preocup insistent i pe dezvoltatorii de medii CASE care ncearc s integreze n acestea i elemente suport pentru MPS.

Capitolul 6 Aspecte metodologice n abordarea unor probleme de dezvoltare a unor sisteme soft
Fr aplica ii orice teorie moare repede. Fr exemple de aplicare orice paradigm rmne o vorb goal. Dei n aceast carte nu am prezentat pe larg o metodologie anume, voi folosi (acolo unde este cazul), pentru ilustrarea unora dintre ideile repetate insistent n celelalte capitole ale cr ii, o serie de elemente preluate dup Object Modelling Technique (OMT) n contextul unei probleme pretext. Complexitatea problemei puse n discu ie nu este devastatoare; adevrul este c nici nu caut aa ceva n aceast carte. Problema are, ns, destule elemente care necesit din partea celui care le abordeaz reflec ie , metod i spirit creator, nainte de a se repezi la tastatur, cum au obiceiul mul i dintre softitii zilelor noastre.

6.1 Inten iile acestui capitol Pentru specialistul n IS aflat n fa a unei probleme ntrebarea cea mai important rmne : "Cum se poate abstractiza enun ul respectivei probleme astfel nct solu ia ob inut s aib mcar o parte din nsuirile unui sistem soft de calitate?". Atrag aten ia cititorului c nu vreau s minimalizez cu nimic rolul celorlaltor prghii metodologice n dezvoltarea sistemelor soft. Exist, ns, un motiv simplu pentru care, n aceast carte, voi insista mai mult pe elementele de abstractizare: prezentarea limbajului pe care l propune o metodologie pentru modelarea (=abstractizarea) solu iei unui sistem soft este un exerci iu de maxim seriozitate care, eventual, poate face obiectul altei cr i. De aceea, solu ia problemei-pretext pe care o voi aborda n acest capitol va fi reprezentat folosind limbajul natural i, eventual, reprezentri grafice uor de n eles sau care fac parte din categoria conven iilor de reprezentare cunoscute de marea majoritate a specialitilor n IS. S mai precizm, n sfrit, c problema este interesant tipologic, fapt care, sper eu, va men ine treaz aten ia cititorului. 6.2 Problem pretext pentru modelarea orientat obiect Pledoaria acestui paragraf are dou motiva ii: 10 Din ce n ce mai mul i specialiti n IS ar vrea s adere la "religia OO" dar, mai nti, trebuie ca cineva s-i conving. Ctigarea de aderen i autentici (nu formali) ai "religiei OO" nseamn s faci din aceti aderen i practican i din convingere. tiu c nu este simplu, dar voi ncerca. 20 Modelarea OO este o ocazie de a abstractiza de o manier care poate sensibiliza i ncnta chiar i pe specialitii n IS recunoscu i pentru ndrjirea cu care i apr vechile principii. Problema pretext asupra creia m opresc are urmtorul enun preliminar: Modelarea orientat obiect a unei stive generice Odat cu mine, n elege i cititorul c, nainte de a trece la rezolvarea propriuzis a problemei, trebuie s desluim, mcar n parte, semantica sintagmei "modelare orientat obiect". 6.2.1 Ce este modelarea orientat obiect? Iat o ntrebare bun la care este greu de dat un rspuns care s mul umeasc pe toat lumea. n IS, de exemplu, se vorbete despre orientare obiect n modelarea informa iilor, analiza i proiectarea sistemelor i, evident, n programare. Prezentarea pe care o fac va pune accent pe "liniile de for " ale sintagmei OO, dac mi este ngduit exprimarea. Mai nti, i voi reaminti cititorului c, indiferent dac se afl n domeniul problemei(DP) sau n domeniul solu iei (DS), specialistul n IS se confrunt, n esen , cu dou tipuri de probleme: organizarea datelor; organizarea prelucrrilor.

Din perspectiv clasic, pentru rezolvarea acestor dou probleme exist modele i metode de abordare specifice. Aa se face c vor exista modele de organizare a datelor (rela ional, re ea, ierarhic, fiiere clasice) i metode de organizare a prelucrrilor (orientate pe func ii, dirijate de date, dirijate de evenimente, etc.). Rezultatul unui demers din perspectiv clasic, n mare, este cel prezentat n Figura 6.1.

Solu ia tehnic

Modelul datelor
Problema Determinare cerin e fa de sistemul soft

Modelul prelucrrilor

Figura 6.1 Maniera clasic de ob inere a solu iei tehnice a unei probleme Obiec ia fundamental adus paradigmei ilustrat de Figura 6.1 se refer la sensibilitatea deosebit a solu iei tehnice n fa a modificrilor de orice tip. Originea acestei sensibilit i se afl n autonomia relativ a celor dou modele, benefic pentru dezvoltarea separat, de calitate, a modelelor, avnd n vedere o serie de cerin e pe termen scurt fa de solu ie ca ntreg, dar generatoare, n mod natural, de dependen e ntre modele, care nu favorizeaz continuitatea modular, extensibilitatea, portabilitatea, reutilizabilitatea, aspecte ale calit ii unui sistem soft relevante pe termen lung. Foarte sintetic spus domeniul problemei se mapeaz slab pe domeniul solu iei. Att din interiorul laboratoarelor IS ct i din afara acestora s-a exercitat o presiune permanent pentru aezarea pe baze noi a rela ie dintre date i prelucrri. O variant, validat practic ca eficient, de reaezare a rela iei date-prelucrri o reprezint modelarea orientat obiect. Imperativul cheie al paradigmei OO pare a fi asigurarea unor condi ii naturale de mapare sporit a domeniului problemei pe domeniul solu iei. Pentru realizarea acestui deziderat era nevoie de o modificare radical de abordare, pe care voi ncerca s o prezint n continuare n ceea ce are ea esen ial. Aa cum rezult din Figura 6.2 modelarea OO a solu iei unei probleme se face pe trei nivele de abstractizare. Conceptele esen iale (i specifice) ale modelrii OO se regsesc la primul nivel de abstractizare, numit n majoritatea metodologiilor OO modelul claselor. S mai semnalez cititorului c suportul pentru maparea DP pe DS se regsete, n principal, la primele dou nivele de abstractizare.

Problema Determinare cerin e fa de sistemul soft

Abstractizarea solu iei ca o colec ie de clase, interconectate (asocieri, generalizri, agregri) Abstractizarea structurii de control a fiecrei clase

Abstractizarea transformrilor suportate de fluxurile de date

Figura 6.2 Maniera OO de ob inere a solu ie tehnice a unei probleme Concepte fundamentale n elaborarea modelului claselor Am afirmat n mai multe rnduri faptul c sistemele reale care suport un proces de modelare informa ional reprezint punctul de plecare n demersul de dezvoltare a unui sistem soft care deservete un anumit sistem real. Obiectele care populeaz sistemul real i sunt importante din punct de vedere al cerin elor formulate fa de sistemul soft pot fi caracterizate informa ional i comportamental. n limbaj IS se spune c un obiect din lumea real poate fi abstractizat de o list de atribute informa ionale i de o list de atribute comportamentale. Conceptul de clas Toate obiectele care sunt abstractizate de aceeai list de atribute informa ionale i de aceeai list de atribute comportamentale formeaz o clas. Punnd n valoare afirma ia de mai sus este evident c obiectele care populeaz sistemul real sunt parti ionate n func ie de raportarea lor la o anumit list de atribute informa ionale i comportamentale. Paradigma OO merge mai departe i afirm c a defini o clas n spirit OO nseamn: 10 A stabili lista de atribute informa ionale (necesare i suficiente att din punct de vedere al logicii interne a obiectelor abstractizate de aceast clas ct i din punct de vedere al cerin elor de reprezentare a rela iilor cu obiecte avnd alte clase definitoare). 20 A declara aceast list ca fiind privat(=ascuns) fa de clien ii clasei. 30 A stabili lista de atribute comportamentale (necesare i suficiente att din punct de vedere al logicii interne a obiectelor abstractizate de aceast clas ct i din punct de vedere al solicitrilor formulate de ctre obiecte avnd alte clase definitoare). 40 Declararea ca publice a acelor atribute comportamentale care abstractizeaz mul imea serviciilor adresate obiectelor avnd alte clase definitoare (mul imea acestor atribute se numete interfa ). Aplicarea consecvent a conceptului de clas astfel formulat nseamn, n paradigma OO, promovarea sistematic a principiului ncapsulrii.

Dup cum se poate deduce, ncapsularea are dou obiective precise: abstractizarea similarit ilor informa ionale i comportamentale ale unei colec ii de obiecte; abstractizarea serviciilor oferite clien ilor de ctre obiectele din colec ia men ionat mai sus. Conceptul de obiect n paradigma OO se numete obiect o instan a unei clase n modelare, ca i n programare, un obiect este caracterizat prin: identitate; o list de valori asociat listei de atribute informa ionale; mul imea atributelor comportamentale partajate mpreun cu alte obiecte avnd aceeai clas definitoare. Din punct de vedere al identit ii, un obiect are o identiate fizic, asigurat de sistemul care monitorizeaz procesul de declarare a obiectelor, ct i o identitate logic, datorat protocoalelor pe baza crora, pentru fiecare obiect cu identitate fizic, recunoscut, se atribuie nite valori atributelor informa ionale aferente. Conceptul de atribut informa ional n modelarea OO exist deja consens n ceea ce privete sintaxa de principiu i semantica unui atribut informa ional, n sensul c un atribut informa ional se specific prin: <nume_atribut_informa ional> : <tip>[=<Valoare_implicit>] Aadar, orice atribut informa ional are nume, tip i, eventual, valoare implicit. Semantica atributului informa ional depinde, evident, de contextul n care acesta este utilizat. Opera ii i metode Descrierea comportamentului obiectelor unei clase este realizat, la cel mai nalt nivel de abstractizare de opera ii. Exist un consens relativ i n ceea ce privete specificarea unei opera ii n modelarea OO. Sintaxa de specificare a unei opera ii este, n general: [<Tip_returnat>] <Nume_opera ie>([<Lista_de_parametri>]) Aadar, o opera ie poate s returneze o dat de un tip specificat sau nimic, are un nume i poate face schimb de date cu apelantul n toate modurile posibile prin intermediul listei de parametri. Cititorul este contient de faptul c, specificnd o opera ie (nu implementnd-o), descriem, practic, utilitatea acestei opera ii i modul de folosire a acesteia. n aceast faz a expunerii este cazul s pregtesc cititorul pentru noi dezvluiri n ceea ce privete poten ialul modelrii OO. Din nenumrate motive (nevoia de rafinare treptat a solu iei, nevoia de reutilizare a efortului de modelare, nevoia de specificare a unor contexte polimorfice) solu ia orientat obiect a unei probleme poate fi rezultatul unor eforturi de abstractizare care se desfoar pe trei direc ii:

pe orizontal, ob inndu-se clase avnd aproximativ acelai nivel de abstractizare i structuri informa ionale i comportamentale dizjuncte; pe vertical, ob inndu-se lan uri de derivare, prin intermediul crora se gestioneaz similarit ile partajate de clase; n adncime, ob inndu-se, dac este cazul, alternative (replici) la o solu ie dat. Dei, formulat ca idee i nc nefolosit, abstractizarea n adncime, cu un suport adecvat la nivelul limbajelor de programare ar putea constitui solu ia sistematic pentru o problem mai veche :problema polimorfismului de nivel sistemic. Revenind la ideea abstractizrii OO pe vertical (deoarece problema de care ne vom ocupa va fi abordat din aceast perspectiv), voi prezenta, cu inten ia de a comenta, situa ia din Figura 6.3. A
1

A B

A C

A B D

Figura 6.3 O ierarhie de clase Figura 6.3 ne sugereaz urmtoarele: 10 Clasa referit cu 1 abstractizeaz similarit ile provenind de la cele dou lan uri de derivare. Abstractizarea, dup cum spune i psihologia gndirii, este o opera ie tipic de generalizare. De aceea, n procesul de abstractizare pe vertical, o rela ie posibil ntre clase este rela ia de generalizare (privit de jos n sus) sau rela ia de derivare (spacializare) dac privim de sus n jos. Conform Figurii 6.3 clasa referit de 2 generalizeaz clasa referit de 4 i n acelai timp specializeaz clasa referit de 1, ntr-o anumit direc ie. Cititorul este invitat s dea dovad de mult rbdare din punct de vedere al apetitului pentru comunicarea ideilor n modelarea OO. Exist un exces de limbaj, n mare parte scuzat de dorin a celor care comunic, de a surprinde noi fa ete ale unui fenomen att de complex cum este modelarea OO. Ca un exemplu, ntr-un lan de derivare, o clas care generalizeaz se numete superclas, clas de baz sau clas printe iar o clas care specializeaz se numete clas derivat, clas motenitoare sau clas urma. Oarecum ngrijorat de amploarea pe care o ia aceast "scurt prezentare" a fenomenului OO, trebuie totui s mai adaug c specializarea se poate realiza n dou moduri: prin adugarea de noi atribute; prin redefinirea unor atribute comportamentale.

Atunci cnd este prezent fenomenul de redefinire a atributelor comportamentale, versiunea unui atribut comportamental la nivelul clasei rdcin se numete opera ie, versiunile situate n clasele derivate direct sau indirect din clasa rdcin se numesc metode. Paradigma OO abstractizeaz eforturile de gestiune a similarit ilor n rela iile dintre clase ridicnd la rang de principiu ideea de motenire. Pentru cititorul atent motenirea reprezint o poart larg deschis ctre utilizarea efortului de dezvoltare, dac principiul motenirii este judicios aplicat i n deplin respect fa de ncapsularea OO. Evident c, cititorul curios va dori s afle i ce alte tipuri de rela ii se mai pot concepe ntre clase. i voi spune c aceste rela ii mai pot fi: de asociere, de agregare, de asociere ca i clase, etc.). Tot cititorului curios i voi mai spune c modelarea OO mai sus ine fervent nc un principiu important, principiul polimorfismului, a crui n elegere este, par ial, condi ionat de n elegerea conceptului de mesaj. Conceptul de mesaj n modelarea OO se numete mesaj apelul unei metode a unui obiect, formulat de ctre un client al obiectului respectiv. Evidente sunt urmtoarele dou lucruri: orice mesaj trebuie s primeasc un rspuns; obiectele comunic ntre ele cu ajutorul mesajelor. Acum suntem n msur s spunem c, n condi ii tehnice dependente de limbajul de programare un mesaj avnd aceeai structur sintactic poate primi rspunsuri diferite, n func ie de contextul n care s-a creat obiectul care este destinatar al mesajului. O opera ie care se poate comporta astfel se numete opera ie polimorfic. Nu-i rmne cititorului dect dorin a de a alege o paradigm OO pentru a se familiariza cu toate exigen ele ei n ceea ce privete: nota ia utilizat, structura ciclului de via , structura procesului de management al softului, etc. 6.2.1 Elemente de modelarea pe marginea problemei propuse S ne reamintim c problema pretext a paragrafului 6.2 este: Modelarea orientat obiect a unei stive generice Un curs de structuri de date ne nva c stiva este o structur de date n care opera iile de inserare i extragere a elementelor sunt restric ionate n sensul c: 10 Opera ia de inserare (numit i PUSH n majoritatea implementrilor) se face ntotdeauna naintea ultimului element introdus, dac acest ultim element introdus exist. Ultimul element introdus este referit de o variabil special a stivei numit vrf sau top. Dac stiva este vid, atunci vrful stivei (care are o valoare special ) este actualizat astfel nct s refere elementul introdus. De remarcat c la inserarea unui element n stiv putem avea depire superioar, n situa ia n care capacitatea predefinit a stivei este saturat. 20 Opera ia de extragere (numit i POP n majoritatea implementrilor) se refer la elementul din vrful stivei, dac acesta exist. n urma unei opera ii de extragere, vrful stivei este actualizat. De remarcat, de asemenea, c n situa ia n care se for eaz o extragere de element dintr-o stiv vid, spunem c avem depire inferioar.

Exprimndu-ne n limbaj OO, opera iile obligatorii pentru o stiv sunt opera iile PUSH() i POP(). Evident, cnd modelm comportamentul unei stive, ne pot fi de folos i alte opera ii a cror natur depinde de contextul n care este folosit stiva. Exemple de astfel de alte opera ii voi prezenta n propunerea de solu ie la aceast problem. Stiva pe care vrem s-o modelm trebuie s fie generic Cititorul a n eles, probabil, c o structur de date este un tip de dat structurat, prin urmare este viabil n momentul n care cunoatem, printre altele, tipul elementelor care populeaz structura. Astfel c putem avea stive de ntregi, stive de numere reale, stive de iruri de caractere, etc. O structur de date devine generic dac este specificat n aa fel nct s permit aplicarea acelorai opera ii asupra unor tipuri diferite de date Dac la cerin a genericit ii adugm i cerin a de a putea avea drept suport pentru pstrarea stivei memoria RAM sau o specie adecvat de memorie extern, problema ncepe s-i contureze un enun consistent. Sunt n msur (poate cititorului o s i se par prea devreme, dar m va n elege dup ce va aborda singur o astfel de problem) s formulez urmtoarele cerin e fa de sistemul soft pe care vreau s-l dezvolt: 10 Codul rezultat trebuie gndit astfel nct s poat fi partajat de orice client (programator) interesat; 20 Fiecare client s poat opera cu un tip de dat propriu; 30 Fiecare client s poat opta pentru suportul adecvat pentru stiv (RAM sau memorie extern); 40 Protocolul de lucru cu stiva s fie ct mai simplu; 50 Se vor avea, pe ct posibil, n vedere, cerin e precum: structurarea, modularizarea, orientarea pe obiect, lizibilitatea, documentarea, etc. Ultimele dou cerin e se refer, evident, la cod. Inventarul faptic al enun ului problemei n cauz, mpreun cu cerin ele mai sus formulate ne ngduie s eviden iem, din perspectiv orientare-obiect, urmtoarele clase candidate (Figura 6.4).
Stiva_RAM Stiva_M_Extern

Figura 6.4 Clase candidate la solu ia OO a problemei Este clar c aceste clase prezint similarit i de comportament. Inten ia n acest moment este de a schi a solu ia problemei ca o ierarhie de clase, avnd aliura din Figura 6.5.

TAbsStiva

TRamStiva

TMVStiva

TVideoStiva

Figura 6.5 Ierarhia de clase asociat solu iei problemei Dup cum se vede, s-a introdus o clas abstract (TAbsStiva) a crei menire este de a colecta similarit ile venind pe cele dou ramuri: Ramura din stnga TRamStiva modeleaz stiva RAM se deriveaz din TAbsStiva TVideoStiva modeleaz stiva utiliznd ca surs de date pentru stiv memoria video n mode text; se deriveaz din TRamStiva Ramura din dreapta TMVStiva modeleaz stiva pstrat pe o memorie extern (virtual) se deriveaz din TAbsStiva deoarece n comportamentul clasei TMVStiva apar elemente care fac improprie derivarea din una dintre clasele TRamStiva sau TVideoStiva. Schema prezentat n Figura 6.5 poate fi considerat modelul claselor pentru problema noastr. n treact fie spus, clasele prezentate n ierarhia din Figura 6.5 nu exceleaz prin dinamism, deci sunt triviale din punct de vedere modelului dinamic (structura de control, n Figura 6.2). Pentru a spori semantica schemei din Figura 6.5 prezentm, n extenso, defini iile claselor (rezultate n urma unui proces de abstractizare-ncapsulare uor de intuit de cititorul curios). TabsStiva Lungime_Element : intreg pozitiv; Numar_curent_de_elemente : intreg pozitiv=0; Eroare_de_alocare_memorie: boolean=false atribute private *Init(LE:intreg pozitiv) *Done() boolean GetAllocateError; ;virtual;

Push( X: referin la element de inserat) boolean Pop(X: referin la elementul extras) Clear() RollUp() RollDn()

; virtual ; virtual ;virtual; ;virtual; ;virtual

Dup cum se vede din defini ia clasei TabsStiva, toate opera iile fac parte din interfa , nefiind declarate ca private. De asemenea, cititorilor care au ncercat gustul programrii OO n Pascal, C++ sai Java trebuie s le atrag aten ia asupra opera iilor speciale (marcate cu asterisc) , Init (constructor de clas) i Done (destructor de clas), opera ii care joac un rol important n alocarea dinamic a memoriei pentru obiecte, ini ializarea lor i a tabelelor cu metode virtuale n caz c este cazul. S mai adugm faptul c unele opera ii ale clasei sunt urmate de clauza virtual ceea ce atrage aten ia asupra inten iei redefinirii acestor opera ii n descenden i. Se observ c atributele informa ionale care au putut fi incluse n lista de atribute informa ionale a clasei TAbsStiva sunt: -Lungime_Element; un ntreg pozitiv care va pstra lungimea n octe i a elementului stivei; -Numar_curent_de_elemente; un ntreg pozitiv care pstreaz numrul de elemente din stiv; la crearea unei instan e valoarea este 0. -Eroare_de_alocare_memorie: camp boolean care ajut la monitorizarea erorilor de alocare. Invit cititorul la refelec ie pe tema implica iilor pe care le are genericitatea asupra procesului de modelare i, n final s urmreasc codul Pascal care implementeaz ideile prezentate mai sus. TramStiva (derivat din TAbsStiva) Top: referin la element stiv atribut privat *Init(LE:intreg pozitiv) *Done() boolean GetAllocateError; Push( X: referin la element de inserat) boolean Pop(X: referin la elementul extras) Clear() RollUp() RollDn() (autoreferire) ;virtual; ; virtual ; virtual ;virtual; ;virtual; ;virtual

TMVStiva (derivat din TAbsStiva) Buffer :referin la o zon de memorie tampon Mesaj_Eroare : ir de caractere Nume_extern_fiier_asociat stivei :ir de atribute private Hfiier :Handle de fiier *Init(LE:intreg pozitiv)

caractere

*Done() boolean GetAllocateError; Push( X: referin la element de inserat) boolean Pop(X: referin la elementul extras) Clear() RollUp() RollDn() TvideoStiva (derivat din TRamStiva)

;virtual; ; virtual ; virtual ;virtual; ;virtual; ;virtual

PushScreen() boolean PopScreen() nainte de a prezenta codul surs care "materializeaz" inten iile de proiectare prezentate mai sus voi mai aduga o serie de observa ii de interes pentru cititor. 10 Utilizatorul ierarhiei de clase poate beneficia de comportamentul polimorfic al ntregii ierarhii. Singura lui obliga ie este s fac jonc iunea cu codul aferent ierarhiei, n programul client. 20 Genericitatea impune ca n protocolul de utilizare a ierarhiei, la un moment dat s se "coboare" la nivel de octet. Acest efort, ns, este derizoriu n compara ie cu prelucrrile asumate n ierarhie. 30 Utilizatorul ierarhiei beneficiaz, totodat i de facilit ile oferite de ierarhie penru depistarea posibilelor erori. Evident, tratarea unei erori este de competen a clientului. 40 Alegerea limbajului este o sarcin relativ comod pentru problema noastr. Am ales limbajul Pascal pentru a m face mai uor n eles. n realitate aceast alegere nseamn c miam pus codul ob inut la dispozi ia comunit ii programatorilor de Pascal i, eventual, Delphi. Cunosctorii de C++ tiu, ns, c suportul oferit de C++ pentru programare OO i programarea n genere este mult mai interesant. n sfrit, despre semantica ierarhiei, cel mai mult ne vorbete codul Pascal, ncapsulat ntr-un unit, pe care l prezint n continuare. 6.2.3 Implementarea modelului Cititorul are la dispozi ie n acest paragraf unit-ul Pascal care ncapsuleaz toate specifica iile convenite n paragraful 6.2.2 precum i o mic aplica ie care folosete una dintre capabilit ile unit-ului. Artificiile Pascal folosite pentru a rezolva problema genericit ii pot fi uor n elese urmrind comentariile incluse n codul surs i avnd cunotin e elementare de lucru cu structurile dinamice n Pascal. Cititorul poate trage nv minte i din analiza atent a modului n care conceptele OO din modelare i gsesc suport n Pascal, limbaj care s-a nscut, ini ial cu alte scopuri dect promovarea principiilor OO. unit StivaGen; { ---------------------------------------------------Unit-ul ncapsuleaz solu ia orientat obiect pentru stiva avand ca suport: -Memoria RAM;

-Hard disc-ul; Autor: Dorin Bocu Ianuarie 2001 ---------------------------------------------------} { ---------------------------------------------------Interfa a unit-ului ---------------------------------------------------} interface const Screen_Bytes = 4000; var { ---------------------------------------------------Variabile necesare pentru recuperarea adresei memoriei video ---------------------------------------------------} VideoMode :byte absolute $0040:$0049; VideoAddress :word; VideoPtr :pointer; type { ---------------------------------------------------Declara ii de tipuri necesare pentru a specifica structura nodului listei suport pentru stiva RAM ---------------------------------------------------} GenStivaPtr = ^GenStivaRec; GenStivaRec = record DataPtr : Pointer; NextLink : GenStivaPtr end; { ---------------------------------------------------Clasa care modeleaz o stiv abstract ---------------------------------------------------} PTAbsStiva=^TAbsStiva; TAbsStiva=object constructor Init(ElementSize:word); destructor Done ;virtual; function GetAllocateError:boolean; procedure Push(X:pointer) ;virtual; function Pop(X:pointer):boolean;virtual;

procedure Clear procedure RollUp procedure RollDn private ElemSize, Height : word; AllocateError : boolean; end;

;virtual; ;virtual; ;virtual;

{ ---------------------------------------------------Clasa care modeleaz stiva cu suport memoria RAM ---------------------------------------------------} PTRamStiva=^TRamStiva; TRamStiva = object(TAbsStiva) constructor Init(ElementSize:word); destructor Done ;virtual; procedure Push(X :pointer ) ;virtual; function Pop(X:pointer):boolean;virtual; procedure Clear ;virtual; procedure RollUp ;virtual; procedure RollDn ;virtual; private Top : GenStivaPtr; end; { ---------------------------------------------------Clasa care modeleaz stiva cu suport memoria externa ---------------------------------------------------} PTMVStiva=^TMVStiva; TMVStiva = object(TAbsStiva) constructor Init(ElementSize : word; Filename: string); destructor Done ;virtual; function GetErrorMessage : string; procedure Push(X:pointer) ;virtual; function Pop(X:pointer):boolean ;virtual; procedure Clear ;virtual; procedure RollUp ;virtual; procedure RollDn ;virtual; private DataBuffer:pointer; {pointer la buffer -ul de date } ErrorMessage, {messaj eroare } VMfilename : string;{nume extern fisier} VMfile : file; {variabila fisier } end;

{ ---------------------------------------------------Clasa care modeleaz o stiv RAM care utilizeaz ca sursa de date memoria video ---------------------------------------------------} PTVideoStiva=^TVideoStiva; TVideoStiva= object(TRamStiva) procedure PushScreen; function PopScreen:boolean; end; implementation { --------------------------------------------------Implementare opera ii abstracte TAbsStiva --------------------------------------------------} constructor TAbsStiva.Init(ElementSize :word); begin end; destructor TAbsStiva.Done; begin Clear end; procedure TAbsStiva.Push(X:pointer); begin end; function TAbsStiva.GetAllocateError:boolean; begin GetAllocateError := AllocateError end; function TAbsStiva.Pop(X:pointer):boolean; begin end; procedure TAbsStiva.Clear; begin end; procedure TAbsStiva.RollUp; begin end; procedure TAbsStiva.RollDn;

begin end; { --------------------------------------------------Func ie utilizator care for eaz sistemul s returneze nil n caz de apel new sau getmem nesolu ionat. Solu ie Pascal!!!!! --------------------------------------------------} function HeapErrorHandler(Size : word):integer;far; begin HeapErrorHandler := 1 end; { --------------------------------------------------Implementare metode TRamStiva --------------------------------------------------} constructor TRamStiva.Init(ElementSize:word); begin ElemSize := ElementSize; if ElemSize = 0 then ElemSize := 1; Height := 0; AllocateError := false; Top := nil; end; destructor TRamStiva.Done; begin Clear end; procedure TRamStiva.Push(X:pointer); var p : GenStivaPtr; begin AllocateError := false; if Top <> nil then begin new(p); { alocare element nou in stiva} if p = nil then begin AllocateError := true; exit; end;

getmem(p^.DataPtr, ElemSize); if p^.DataPtr = nil then begin AllocateError := true; exit; end; move(X^, p^.DataPtr^, ElemSize); p^.NextLink := Top; Top := p end else begin new(Top); if Top = nil then begin AllocateError := true; exit; end; getmem(Top^.DataPtr, ElemSize); if Top^.DataPtr = nil then begin AllocateError := true; exit; end; move(X^, Top^.DataPtr^, ElemSize); Top^.NextLink := nil end; inc(Height) end; function TRamStiva.Pop(X:pointer):boolean; var p:GenStivaPtr; begin if Height > 0 then begin Move(Top^.DataPtr^, X^, ElemSize); FreeMem(Top^.DataPtr, ElemSize); { dealocare data } p :=Top; Top:=Top^.NextLink; dispose(p); { dealocare nod stiva } dec(Height); Pop:=true end else

Pop:=false end; procedure TRamStiva.Clear; var x:Pointer; begin GetMem(x, ElemSize); while Pop(x) do freemem(x, ElemSize); end; procedure TRamStiva.RollUp; var old_top, next_one: GenStivaPtr; begin if (Top = nil) or (Height < 2) then exit; old_top := Top; Top := Top^.NextLink; old_top^.NextLink := nil; next_one := Top^.NextLink; while next_one^.NextLink <> nil do next_one := next_one^.NextLink; next_one^.NextLink := old_top; end; procedure TRamStiva.RollDn; var last_one, next_one : GenStivaPtr; begin if (Top = nil) or (Height < 2) then Exit; last_one := nil; next_one := Top; while next_one^.NextLink <> nil do begin last_one := next_one; next_one := next_one^.NextLink; end; next_one^.NextLink := Top; Top := next_one; last_one^.NextLink := nil end; { --------------------------------------------------Implementare metode TMVStiva

--------------------------------------------------} constructor TMVStiva.Init(ElementSize:word; Filename :string); begin if ElementSize = 0 then ElementSize := 1; ElemSize := ElementSize; VMfilename := Filename; Height := 0; assign(VMfile, VMfilename); {$I-} rewrite(VMfile,ElemSize); {$I+} if IOresult <> 0 then begin ErrorMessage:='Nu se poate deschide fisierul ' +VMfilename; exit; end; GetMem(DataBuffer,ElemSize); if DataBuffer=nil then begin AllocateError :=true; ErrorMessage :='Eroare alocare dinamica' end else begin AllocateError :=false; ErrorMessage :='' end; end; destructor TMVStiva.Done; begin Clear; freemem(DataBuffer, ElemSize); end; function TMVStiva.GetErrorMessage:string; begin GetErrorMessage:=ErrorMessage end; procedure TMVStiva.Push(X:Pointer); begin inc(Height); seek(VMfile, Height-1);

blockwrite(VMfile, X^, 1); end; function TMVStiva.Pop(X:Pointer):boolean; begin if Height > 0 then begin dec(Height); seek(VMfile, Height); blockread(VMfile, X^, 1); Pop := true end else Pop := false; end; procedure TMVStiva.Clear; begin Height := 0; {$I-} close(VMfile); erase(VMfile); {$I+} end; procedure TMVStiva.RollUp; var I:word; begin seek(VMfile, Height-1); blockread(VMfile, DataBuffer^, 1); seek(VMfile, Height); blockwrite(VMfile, DataBuffer^, 1); for I := Height-1 downto 1 do begin seek(VMfile, I-1); blockread(VMfile, DataBuffer^, 1); seek(VMfile, I); blockwrite(VMfile, DataBuffer^, 1); end; seek(VMfile, Height); blockread(VMfile, DataBuffer^, 1); seek(VMfile, 0); blockwrite(VMfile, DataBuffer^, 1); end; procedure TMVStiva.RollDn; var I:word; begin

seek(VMfile, 0); blockread(VMfile, DataBuffer^, 1); seek(VMfile, Height); blockwrite(VMfile, DataBuffer^, 1); for I:=2 to Height do begin seek(VMfile, I-1); blockread(VMfile, DataBuffer^, 1); seek(VMfile, I-2); blockwrite(VMfile, DataBuffer^, 1); end; seek(VMfile, Height); blockread(VMfile, DataBuffer^, 1); seek(VMfile, Height-1); blockwrite(VMfile, DataBuffer^, 1); end; { --------------------------------------------------Implementare metode TVideoStiva --------------------------------------------------} procedure TVideoStiva.PushScreen; begin Push(VideoPtr) end;

function TVideoStiva.PopScreen:boolean; begin PopScreen:=Pop(VideoPtr); end; { --------------------------------------------------Secven a de initializare a unit-ului in care variabila unitului SYSTEM HeapError este for at la valoarea <adresa functiei HeapErrorHandler> care ar putea trata excep iile la alocarea dinamic a memorie. De asemenea se stabilete adresa memoriei video --------------------------------------------------} begin HeapError:=@HeapErrorHandler; if VideoMode=7 then VideoAddress:=$B000 else VideoAddress:=$B800; VideoPtr:=Ptr(VideoAddress,0); end.

program Apl_Stiva_cu_sursa_de_date_memoria_video; {$M 8192, 0, 655350} { --------------------------------------------------Autor: Dorin Bocu Ianuarie 2001 --------------------------------------------------} uses crt, StivaGen; var S : TVideoStiva; I, NumarEcran : byte; AKey : char; { --------------------------------------------------Procedura umple ecranul cu un caracter dependent de numrul de ecran primit ca parametru --------------------------------------------------} procedure FillScreen(var SN : byte); var row : byte; C : char; AString : STRING; begin inc(SN); clrscr; C := chr(64 + SN); FillChar(AString[1], 80, C); AString[0] := chr(80); writeln('Numar ecran ', SN); for row := 2 to 24 do write(AString); end; { --------------------------------------------------Programul principal --------------------------------------------------} begin clrscr; { --------------------------------------------------Apelare constructor motenit de la TRamStiva --------------------------------------------------} S.Init(Screen_Bytes); NumarEcran := 0;

{ --------------------------------------------------Pregtete trei ecrane cu informa ii i le salveaz n RAM --------------------------------------------------} for I:=1 to 3 do begin FillScreen(NumarEcran); S.PushScreen; delay(1000); end; clrscr; write('Asteptati va rog ...'); delay(1000); { --------------------------------------------------Refacere ecrane prin apel succesiv al metodei Pop --------------------------------------------------} while S.PopScreen do delay(1000); gotoxy(1,25); clreol; write('Apasati o tasta ... '); AKey := readkey; S.Done; end.

Capitolul 7 Asigurarea calit ii n cadrul unei firme productoare de soft

...Exist oameni sau na iuni pentru care teoria lucrului bine fcut poate fi un motiv de bclie individual sau, de ce nu, na ional. Defec iunea provine de la n elegerea greit a importan ei detaliilor (care nu necesit anvergur spiritual deosebit, ci comportament binevoitor) asupra chestiunilor paradigmatice (care sunt un prilej de etalare a profunzimii poten elor intelectuale). Problema ar suna cam aa: <Presupunnd c suntem inteligen i, cum putem dobndi n elepciunea necesar pentru a folosi decent aceast inteligen ?!> (Extras din monologul pronun at de autor, n surdin, cu prilejul unei cltorii, neateptate, ntr-un autoturism Mercedes)

7.1 Introducere Aa cum am mai spus i n Capitolul 1, este nevoie de soft de calitate, produs n timp util i la pre uri competitive, pentru a face fa rigorilor supravie uirii pe pia a concuren ial. Expresia n timp util nseamn respectarea termenelor convenite pentru livrarea produselor. Expresia la pre uri competitive nseamn ncadrarea proiectului n restric iile bugetare convenite. Este evident faptul c cele dou cerin e pot fi ndeplinite prin crearea tuturor condi iilor pentru creterea continu a productivit ii muncii.

Preocuparea sistematic pentru creterea productivit ii muncii poate, ns, intra n conflict cu cerin a de a men ine calitatea la standarde nalte, dac nu se studiaz cu aten ie impactul oricrei inova ii n procesul de dezvoltare, asupra calit ii. Metoda clasic pentru a face fa posibilelor conflicte dintre cele dou cerin e se bazeaz pe delegarea competen elor n materie de calitate, ctre persoane sau colective care se ocup, exclusiv, de toate problemele presupuse de monitorizarea abaterilor de la calitate. Altfel spus:

O component a managementului firmei

Monitorizeaz abaterile de la calitate ale ...

Operativului

Figura 7.1 Metoda clasic de asigurare a calit ii Mi se pare o abordare total depit n condi iile actuale. Calitatea trebuie s fie, n esen , crea ia operativului. Majoritatea mijloacelor de promovare efectiv a calit ii este concentrat n minile celor care lucreaz nemijlocit la dezvoltarea softului (analiti, proiectan i, programatori, etc). De aceea, alternativa corect la Figura 7.1 mi se pare a fi cea prezentat n Figura 7.2. Cteva considera ii pe marginea strategiei schi ate n Figura 7.2, n cele ce urmeaz. Activit ile n ingineria softului (IS) se deosebesc mult de activit ile din alte domenii de activitate. n locul muchilor se folosete mult gndirea. Rutina exist, dar nu n prim plan, cum se ntmpl n alte industrii. n prim plan se afl creativitatea specialistului n IS, care, n fiecare proiect este obligat s fac fa la cerin e noi, indiferent de faza n care se afl dezvoltarea unui sistem soft. Pentru a se manifesta, creativitatea are nevoie de libertate de ac iune. Pentru a nu produce sub nivelul standardelor, creativitatea trebuie s se raporteze contient la standarde.

Managementul firmei

Asigur un transfer sistematic de resurse i competen e, pentru asigurarea calit ii, ctre nivelul...

Operativ

Figura 7.2. Metoda propus pentru managementul calit ii ntr-o firm modern de soft Factorii care determin calitatea n IS sunt din ce n ce mai sofisticat distribui i i articula i n cmpul de ac iune al unui specialist IS. Multe probleme din IS pot fi rezolvate optim prin alegerea tehnologiei (tehnologiilor) adecvate exigen elor proiectului. Am vrut s subliniez, nc odat, faptul c asigurarea calit ii este o problem de strategie, dac discutm despre principii de promovare a standardelor de calitate i este o problem de competen a operativului, dac discutm despre mijloacele de opera ionalizare a acestor principii. Ideea care se degaj, cred c este clar.

Dac se dorete, neaprat, implicarea managementului n rezolvarea problemelor de calitate (ceea ce este imperativ pentru o firm care se respect), abordarea ideal este urmtoarea: Stabilirea principiilor fundamentale care trebuie respectate n procesul de dezvoltare a softului (la nivelul conducerii firmei); Convenirea mijloacelor de opera ionalizare a principiilor; aceste mijloace pot fi independente de proiect sau, dac este cazul, dependente de proiect. Din perspectiv obiect orientat, situa ia se reprezint ca n Figura 7.3. Fcnd analogie cu o abordare clasic din ingineria softului, competen ele n materie de asigurare a calit ii softului, n cadrul unei firme, pot fi structurate pe trei nivele de abstractizare: -Nivelul conceptual (Conducerea firmei); -Nicelul specificare (Coordonatorii de proiecte); -Nivelul implementare (Membrii colectivelor de dezvoltare, repartiza i pe proiecte)
(La nivelul conducerii firmei) Principii fundamentale n asigurarea calit ii

(La nivelul coordonatorilor de proiecte)

Mijloace de opera ionalizare a principiilor independente de proiect

(La nivelul colectivului de proiectare 1) Mijloace de opera ionalizare specifice Proiect_1

(La nivelul colectivului de proiectare k) Mijloace de opera ionalizare specifice Proiect_k

Figura 7.3. Propunere de abordare, la nivel sistemic, a problemei calit ii ntr-o firm de soft Managementul calit ii la nivelul conducerii firmei -Conceptualizarea factorilor generici care determin calitatea unui sistem soft; -Conceptualizarea factorilor de calitate identifica i de firm; -Modalit i de ac iune. Managementul calit ii la nivelul coordonatorilor de proiecte -Specificarea factorilor generici care determin calitatea unui sistem soft; -Specificarea factorilor de calitate identifica i de firm; -Modalit i de ac iune. Managementul calit ii la nivelul colectivelor de dezvoltare

-Implementarea factorilor generici care determin calitatea unui sistem soft; -Implementarea factorilor de calitate identifica i de firm; -Modalit i de ac iune. 7..2 Idei pentru programul de asigurare a calit ii n cadrul unei soft firme oarecare de

7.2.1 Nivelul conceptual (Conducerea firmei) Ori de cte ori este nevoie, la acest nivel trebuie reflectat asupra urmtoarelor trei tipuri de probleme: -factori socoti i, n genere, ca fiind importan i pentru calitatea softului, pe care firma vrea s i monitorizeze. Descrierea lor la nivel conceptual. -factori identifica i de conducerea firmei ca fiind importan i pentru calitatea unui proiect anume. Descrierea lor la nivel conceptual. -modalit i de ac iune la nivel conceptual. Observa ie Problema calit ii softului este condiderat n literatura de specialitate o problem dificil, deoarece enun ul ei se modific odat cu tehnologiile folosite pentru dezvoltarea softului. Marea diversitate a abordrilor din punct de vedere tehnologic m-a determinat s propun cele dou tipuri de factori ai calit ii, n vederea monitorizrii. FACTORII GENERICI AI CALIT II Literatura de specialitate distinge trei categorii de factori generici ai calit ii. -factori care se refer la comportarea unui sistem soft dup ce a fost dat n exploatare: -Corectitudinea; -Fiabilitatea; -Performan a; -Eficien a; -Securitatea. -factori care se refer la comportarea unui sistem soft n cazul n care apar modificri: -modularitatea; -stilul de codificare i documentare; -factori care se refer la comportarea unui sistem soft n cazul n care acesta migreaz spre alte platforme hard sau de operare: -portabilitatea -reutilizabilitatea n elesul dat la nivel conceptual acestor factori l prezentm, n reluare, pe scurt, n continuare.

Corectitudinea se refer la abilitatea unui sistem soft de a executa toate sarcinile convenite la specificarea cerin elor. Fiabilitatea se refer la capacitatea sistemului soft de a-i conserva calitatea n timpul exploatrii. n unele cr i, fiabilitatea sistemelor soft se mai numete i robuste e n exploatare. Performan a se refer la modul n care sistemul soft, n format executabil, satisface cerin ele de performan convenite (timpii de rspuns la interogri, n medie sau minimali i maximali, etc.). Eficien a se refer la abilitatea sistemului soft de a utiliza eficient posibilit ile mainii fizice pe care acesta este executat. Observa ie n condi iile n care resursele hard critice ale sistemelor de calcul i mbunt esc permanent indicii de performan , s-ar prea c performan a i eficien a nu mai sunt nite priorit i, potrivit opiniei unor specialiti. Opinia mea este c trebuie s monitorizm, n continuare, aceti factori deoarece, oricnd pot ajuta un proiect s ctige btlia cu alte proiecte similare. Securitatea se refer la abilitatea sistemului soft de a minimiza pierderile de date n timpul avariilor la alimentare sau n cazul unor ncercri de utilizare neautorizat. Modularitatea este un atribut de importan major al oricrui sistem soft de complexitate medie i mare. Modularitatea trebuie planificat i urmrit judicios deoarece de realizarea ei n condi ii optime depinde esen ial disponibilitatea unei solu ii de a se adapta la condi ii noi de execu ie i de a face fa la cerin e noi (reutilizabilitatea i exetnsibilitatea). Modularizarea corect este, practic, visul oricrui specialist n ingineria softului i mai ales al oricrui programator iscusit. Practic, a modulariza corect nseamn : arhitectur simpl a solu iei + descentralizarea optim a capabilit ilor acesteia. Stilul de codificare i documentare poate sus ine sau compromite evolu ia unui sistem soft, att n faza de proiect ct i n perioada de utilizare efetctiv. Stabilirea unui set minimal de reguli i elemente suport pentru activit ile de codificare i documentare trebuie s fie o prioritate pe agenda celor care urmresc calitatea softlui n cadrul firmei. Portabilitatea solu iei unui sistem soft msoar capacitatea sistemului soft de a face fa , cu eforturi minimale, la exerci ii de migrare pe alte platforme hard i de operare. n condi iile n care varietatea arhitecturilor hard existente pe pia este n cretere iar lumea mediilor de operare tinde s se dezvolte, nc n dispre fa de standardizarea tehnologiilor de baz, este firesc s se aib, permanent n aten ie i acest factor al calit ii. Reutilizabilitatea este un vis al oricrei firme de dezvoltare a softului. Ideea este urmtoarea: dac un proiect, prin generalitatea lui, are disponibilitate spre reutilizare, n ansamblu sau pe componentele, atunci reutilizabilitatea trebuie planificat sistematic. FACTORI DE CALITATE IDENTIFICA I DE FIRM

<De studiat problema cu ntregul echipaj al firmei> MODALIT I DE AC IUNE LA NIVEL CONCEPTUAL. S-ar putea sugera, de exemplu, urmtoarele direc ii de ac iune. 1. Pentru fiecare proiect se va alege procesul de dezvoltare cel mai adecvat. Putem, de exemplu adopta urmtoarea atitudine: Mrimea i caracteristicile proiectelor aflate n lucru ne-au condus la ideea c tipul de proces ideal, n cadrul firmei de soft XXXXX , este modelul RAD (Rapid Application development). 2. Alegerea limbajului de modelare i a tools-urilor care promoveaz conceptele acestuia. n aceast direc ie sugerm o anumit constan a op iunilor deoarece nv area unui limbaj de modelare este o problem de timp i de bani. Ultimele evolu ii n domeniu m determin s sugerez utilizarea UML-ului, n combina ie cu tools-uri carre l promoveaz, precum: Rational Rose, ObjectiF, etc.. 3. Evaluarea lunar a calit ii solu iei unui proiect, indiferent de nivelul de abstractizare la care s-a ajuns. 7.2.2 Nivelul specificare (Coordonatorii de proiecte) Specificarea corectitudinii Aten ia coordonatorilor de proiecte se va focaliza pe: -Completitudinea listei cerin elor; -Claritatea formulrii cerin elor; -Identificarea rela iilor dintre cerin e; -Identificarea conflictelor dintre cerin e si explorarea solu iilor de compromis. Specificarea performan ei Aten ia coordonatorilor de proiecte se va focaliza pe: -completitudinea listei indicatorilor de performan ; -Claritatea formulrii indicatorilor de performan ; -Identificarea rela iilor dintre indicatori -Identificarea conflictelor dintre indicatori i explorarea solu iilor de compromis. Specificarea eficien ei Aten ia coordonatorilor de proiecte se va focaliza pe: -Selectarea indicatorilor de performan ai solu iei, sensibili la indicatorii de performan ai resurselor hard critice; -Identificarea protocoalelor de mapare a indicatorilor selectati peste indicatorii de performanta ai resurselor hard critice Specificarea fiabilit ii Aten ia efilor de proiecte se va focaliza pe: -Identificarea componentelor (interne i externe sistemului soft) care pot afecta siguran a n func ionare a acestuia; -Stabilirea strategiei de asigurare a fiabilit ii pentru fiecare component n parte:

-elemente-suport conceptuale; -elemente-suport la nivelul limbajului de programare; -elemente-supot la nivelul mediului de dezvoltare. 7.2.3 Nivelul implementare (membrii colectivelor de dezvoltare, repartiza i pe proiecte) La acest nivel se impun msuri care s asigure un feed-back permanent pe traseul calitatea la nivel conceptual calitatea specificat calitatea la nivel de operativ calitatea la nivel conceptual. Msurile preconizate sunt de doua tipuri: -punctuale; -anticipative. Msurile punctuale Constituie un ansamblu de activit i, convenite de management, pentru a verifica modul n care se realizeaz transferul de competen e n domeniul calit ii de la nivel de management spre nivelul operativ. Pentru ca aceste activit i s se poat desfura corect este necesar s se accepte urmtoarele condi ii minimale: -un proces de dezvoltare, care va permite implementarea feed-back-ului n domeniul calit ii; -un limbaj de modelare i reprezentare adecvat, ceea ce va facilita procesul de urmrire a calit ii. Msurile anticipative Constituie ansamblul activit ilor de informare i formare sistematic a tuturor partenerilor unui proiect, n acord cu reponsabilit ile curente i de perspectiv. Msuri concrete pentru promovarea calit ii la nivel operativ -Elaborarea riguroas a documenta iei sistemelor soft -documenta ie tehnic; -documenta ie de utilizare -documenta ie de prezentare Persoana care rspunde de calitate va defini abloanele pe baza crora se vor elabora aceste tipuri de documenta ii. efii de proiecte vor furniza toate datele necesare pentru elaborarea documenta iilor. Tools-ul folosit va fi ObjectiF, de exemplu. -Planificarea riguroas a procedurilor de testare (de urmrit paragraful 7.3 pentru mai multe detalii relativ la rolul testrii n asigurarea calit ii softului) -ncadrarea efortului de dezvoltare ntr-un model de dezvoltare convenabil; -Utilizarea, pentru elaborarea i reprezentarea solu iei, a unui limbaj de modelare adecvat Pentru testare, practica recomand combinarea tehnicilor top-down i bottom-up. Ca model de dezvoltare, la mrimea i natura aplica iilor de la firma de soft XXXXX recomand prototipizarea. Ca limbaj de modelare propun UML-ul.

-Accentuarea preocuprilor pentru managementul proiectelor i pe alte coordonate care influen eaz calitatea (reutilizarea efortului de dezvoltare, nivelul de informare, planificarea calendaristic, identificarea i gestiunea riscurilor, climatul de lucru etc.) 7.3 Prin testare spre sisteme soft de calitate 7.3.1 Considera ii preliminare Activitatea de testare nu genereaz direct calitate, dar, planificat judicios, poate contribui la realizarea softului de calitate. Una dintre formulrile care au fcut carier n dezbaterile pe tema calit ii softului sun, sec, astfel: Testarea complet a componentelor unui sistem soft poate fi considerat strategia de baz pentru asigurarea calit ii softului. n aceast sec iune a cr ii nu voi relua discu ia pe marginea factorilor care determin calitatea unui sistem soft. Este esen ial, ns, s constatm c factori precum corectitudinea, robuste ea i performan a, evalua i cu superficialitate, pot compromite ansele de reuit ale unui proiect. De fapt, lucrurile sunt foarte simplu de formulat: Dac sistemul soft ajunge la utilizator cu bug-uri, costurile pe care le implic remedierea (fix-area) acestor bug-uri sunt, statistic vorbind, net superioare costurilor pe care le presupune prevenirea lor n timpul proiectrii. De aici, al doilea principiu care ar trebui s fie ncorporat obligatoriu n orice strategie de testare: Procesul de testare a solu iei unui sistem soft trebuie s nceap, dac se poate, nc din fazele timpurii ale proiectrii. Admi nd ca fiind, realmente posibil, implementarea acestui ultim principiu, se pune ntrebarea: Cum trebuie organizat procesul de testare a solu iei unui sistem soft de-a lungul diferitelor stadii de abstractizare prin care aceasta trece. ntrebarea este destul de complicat, fie c o abordm din perspectiv istoric, fie c ncercm s punem cap la cap ultimele idei relativ la topic. Se cuvine s adugm o remarc banal, de altfel: Testarea nu este o activitate paralel cu procesul de dezvoltare. Organizarea judicioas a testrii este o necesitate din punct de vedere al managementului i efectiv posibil doar cu aportul echipei de dezvoltare, s spunem, din prima linie. Aceasta deoarece cunostin ele absolut necesare pentru a organiza testarea solu iei unui sistem soft sunt cel mai coerent articulate n mintea echipei de dezvoltare din prima linie. Ca un exemplu, n UML, comportamentul diferitelor obiecte care contribuie la dinamica unei aplica ii este capturat cu ajutorul modelelor vizuale de la diferite nivele de abstractizare. n jurul acestor modele se pot dezvolta, ulterior, componente, a cror testare i integrare progresiv este absolut natural. Exist, ns, o condi ie esen ial pentru ca lucrurile s mearg pe acest fga: Solu ia trebuie dezvoltat orientat pe componente. Experien a arat c dezvoltarea orientat pe componente asigur numeroase avantaje dezvoltatorilor (reutilizabilitate, fiabilitate, manevrabilitate n timpul testrii) dar solicit o aten ie deosebit n timpul proiectrii interfe elor componentelor, n principal. Se impune din ce n ce mai pregnant ideea c dezvoltarea softului trebuie s devin o activitate n care improvizarea unei solu ii tinde s fie nlocuit, sistematic, cu un efort planificat de abstractizare i verificare a solu iei. n sprijinul unei astfel de atitudini poate veni accesul constant la nout ile n materie de metode de abstractizare i introducerea, pe

acest temei, a obinuin ei de a utiliza instrumentele CASE pentru a optimiza diferitele tipuri de activit i care contribuie la asigurarea calit ii solu iei unui sistem soft. Aadar, problemele de calitate n ingineria softului sunt de natur sistemic i, n consecin , necesit o abordare sistemic. Fiind o problem al crei enun are geometrie variabil, problema calit ii va avea rezolvri nuan ate, n func ie de: tipul proiectului, viziunea managementului asupra calit ii, tipul de proces utilizat n dezvoltare, metoda de abstractizare folosit,etc. . Simplificnd, n mod voluntar, lucrurile, calitatea solu iei unui sistem soft poate fi asigurat dac managementul proiectului a reuit s specifice clar modul n care, pe parcursul dezvoltrii se va verifica aderen a solu iei la factorii de calitate monitoriza i. Beneficiarul principal al unui soft de calitate este clientul. Din punctul lui de vedere calitatea nseamn regsirea cerin elor i implementarea optim a acestor cerin e. Beneficiarul unui soft de calitate poate fi i firma productoare de soft, pentru care calitatea nseamn tot ceea ce ateapt clientul plus cerin e precum: adaptarea flexibil la cerin e noi, localizarea ocurilor provocate de modificri ale solu iei, etc.. Dup acest scurt tur de orizont n problematica calit ii softului, este cazul s fixm nite idei concrete relativ la posibilitatea de a asigura efectiv calitatea ntr-un proces de dezvoltare. 7.3.2 Despre prototipizare, testare i asigurarea calit ii Modelarea obiect orientat a solu iei unui sistem soft permite integrarea unor metode variate de asigurare a calit ii. Aa cum am mai subliniat i cu alt prilej, prototipizarea este un model de dezvoltare adecvat pentru o gam larg de proiecte. Din acest motiv voi ncerca s eviden iez virtu ile prototipizrii n materie de asigurare a calit ii. Reordonnd ideile prezentate n Capitolul 3, se poate vorbi, pentru nceput, de prototipizare explorativ, pe timpul fazei de analiz, ca pretext pentru a defini clar domeniul problemei i alte cerin e fa de sistemul soft. Acest tip de prototipizare poate fi folosit i pentru a evalua(=testa) eventualele solu ii alternative. Odat cu trecerea n faza de proiectare putem vorbi despre prototipizare experimental, care poate fi un mod de a evalua(=testa), grosier vorbind, utilizabilitatea solu iei dezvoltate. Criteriile de calitate urmrite, n principal, sunt: performan a i ceea ce am putea numi, implementabilitatea n genere. Ambele tipuri de prototipizare se desfoar, n principiu, dup regulile evolu iei iterative i incrementale a seriilor de prototipuri ctre produsul complet. Este evident faptul c, nainte de elaborarea fiecrui prototip este necesar formularea explicit i documentarea att a aspectelor referitoare la modificri sau extinderi ct i a aspectelor referitoare la testarea prototipului. Testarea trebuie organizat (ce date se folosesc, cum se ob in aceste date, ce strategie de testare folosim, admi nd c solu ia este corect modularizat, care sunt criteriile convenite ntre dezvoltatori i utilizatori pentru aprecierea prototipului?). Ideea obsesiv este una singur: Indiferent de perspectiva din care este urmrit, asigurarea calit ii trebuie s devin o preocupare permanent, eventual sus inut de tools-uri specializate (Rational Quality Architect, de exemplu, dac se folosesc tools-uri de la Rational). Efortul de organizare a procesului de testare a solu iei unui proiect ar trebui s se structureze pe dou tipuri fundamentale de activit i: planificarea logic a testrii i planificarea calendaristic a testrii. Ca un exemplu, planificarea logic a testrii solu iei unui proiect oarecare ar putea cuprinde: Testarea modulului XXXX

-Testare func ionalitate; -verificarea corectitudinii specificrii i modelrii cerin elor; -verificarea eficien ei i a performan ei; -verificarea integrit ii bazei de date n situa ia n care baza de date este utilizat n mod concurent; -Testare robuste e (=verificarea comportrii modulului n situa ii anormale de utilizare); -Testare protocoale de securitate(dac este cazul); -Stress testing-ul (urmrirea implica iilor acestuia asupra corectitudinii i performan ei); Testarea modulului YYYY -Elaborare de aplica ii pentru evaluarea func iilor modulului YYYY; Testarea modului n care coopereaz tehnologiile folosite la n cadrul aplica iei XXXX. Realizarea feed-back-ului ntre echipa de dezvoltare i echipa de testare, respectiv, echipa de dezvoltare i utilizatori. n ceea ce privete planificarea calendaristic, aceasta va lua n calcul testarea care va fi efectuat de ctre programatori i testarea care va fi efectuat de ctre utilizatori.

Bibliografie
[1] Barden, R., Stepney, S., Cooper, D., Z in Practice, Prentice Hall, 1994, [2] Bennet, S., McRobb, S., Farmer, R., Object Oriented Systems Analysis and Design using UML, McGraw-Hill Publishing Company, 1999 [3] Bocu, D., Introducere n programarea calculatoarelor utiliznd limbajul Pascal, Editura Albastr, 1999 [4] Bocu, D., Ini iere n ingineria sistemelor soft, Editura Albastr, 2001 [5] Bocu, D., Ini iere n modelarea obiect orientat a sistemelor soft utilizand UML, Editura Albastr, 2002 [6] Booch, G., Rumbaugh, J., Jacobson, I., The Unified Modeling Language User Guide, Addison-Wesley, 1999 [7] Booch, G., Object Oriented Design with Applications, The Benjamin/ Cummings Publishing Company, Inc., 1991 [8] Brookshear, J., G., Introducere n informatic, Editura Teora, 1998 [9] Fowler, M., UML Distiled, Second Edition, Addison Wesley, 2000 [10] Hicks, J., O., Management Information Systems, West Publishing Company1993, [11] Lano, K., Formal Object-Oriented Development, Springer, 1995

[12] Meyer, B., Object Oriented Software Construction, Prentice-Hall, 1997 [13] OBrien, J., A., Management Information Systems, Mc Grow-Hill Companies, 1996 [14] Oprea, D. , Analiza i proiectarea sistemelor informa ionale economice, Editura Polirom,1999 [15] Priestley, M., Practical Object Oriented Design, McGraw-Hill, 1997 [16] Quatrany, T., Visual Modeling with Rationale Rose and UML, Addison-Wesley, 1998 [17] Roman, D., Ingineria programrii obiectuale, Editura Albastr, 1996 [18] Rumbaugh, J., Jacobson, I., Booch, G., The Unified Modeling Language Reference Manual, Addison-Wesley, 1999 [19] Wetherbe, J., C., Vitalari, N., P., Sistem Analysis and Design-Best Practices, Wesp Publishing Company, Fourth Edition, 1994 [20] Wu, S.,Y, Wu, M.,S., Sistem Analysis and Design, West Publishing Company, 1994 [21] Priestley, M., Practical Object Oriented Design, McGraw-Hill, 1997 [22] Roman, D., Ingineria programrii obiectuale, Editura Albastr, 1996

Precizri cu studen ilor

privire

la

evaluarea

pregtirii

La aceast disciplin evaluarea va consta n:

1. Verificarea cunotin elor teoretice acumulate, printr-o lucrare scris, pentru care se acord note de la 1 la 10. 2. Elaborarea unui proiect n cadrul activit ilor de laborator
Fiecare proiect va con ine obligatoriu urmtoarele sec iuni: 1. Enun ul problemei. 2. Specificarea cerin elor fa de sistemul soft elaborat n cadrul proiectului. 3. Elemente de proiectarea solu iei: a) Diagrama claselor b) Interfe e c) Func iile sistemului soft d) Considera ii relativ la implementarea func iilor 4. Ghid de utilizarea a sistemului soft 5. Ghid de instalare a sistemului soft 6. Considera ii relativ la stabilitatea / exetensibilitatea solu iei
Prof. univ. dr. Dorin Bocu