Modelarea logic a prelucrrilor. Modelul logic de prelucrare.

are ca scop definirea soluiei informatice pentru lucrrile de informatizat, precizate n cursul modelrii conceptuale urmrete s ajung la st ructuri care faciliteaz programarea i implementarea, prin descompunerea n ULP/PL/PL corespunztor posturilor de lucru din MCP, modelarea logic trebuie s asigure distribuirea prelucrrilor pe echipamentele aferente nu mai poate menine acelai grad de independen a datelor fa de prelucrri. Cum scopul urmrit const n definirea unei soluii informatice implementabile, n care interaciunea date-prelucrri este fundamental, conceperea prelucrrilor nu mai poate face, n aceeai msur ca pe nivelele precedente, abstracie de date.

1 2 3
3.1 3.2 3.3 3.4
3.4.1Unitile logice de prelucrare
Unitatea logic de prelucrare(ULP/PL/PL) este o subdiviziune a lucrrii informatizabile definit n cursul modelrii conceptuale i, n acest context, izoleaz o parte din funcionalitatea acesteia. Decuparea lucrrilor n ULP/PL prezint mai multe avantaje: reducerea complexitii i izolarea efectelor modificrilor sau coreciilor aduse ulterior; cuprinderea detaliilor cerute de implementare este mult mai uoar la nivelul fiecrei ULP/PL; erorile sesizate n timpul testrilor vor putea fi mult mai uor localizate i corectate; schimbrile n regulile de funcionare vor opera numai n spaiul unei (sau unor) ULP/PL, restul sistemului rmnnd neschimbat.

1.1.1Decuparea n ULP/PL
La decuparea ULP/PL particip simultan dou criterii: unul provenind din structura datelor i cel de al doilea din structura prelucrrilor. 1.Structura datelor intervine n dou planuri: sub aspectul conservrii "obiectelor utilizator" i sub acela al tratrii tranzacionale a actualizrilor.

Obiectul utilizator desemneaz structura sau conceptul cu care utilizatorul lucreaz n activitatea curent. Nevoia definirii sale provine din faptul c reprezentarea informatic coincide n puine cazuri cu aceast structur. Spre exemplu, o comand adresat unui furnizor este, pentru utilizator, un "obiect" unitar i coerent; reprezentarea sa informatic se face ns prin patru entiti i trei asocieri diferite (figura 4.11), respectiv cinci tabele n BD.

Figura 4.11 Obiectul utilizator comand

Consecina este aceea c ULP/PL trebuie s respecte i s conserve aceast structur, asigurnd consultarea i actualizarea sa n concordan cu imaginea cu care este familiarizat utilizatorul. Corespondenele i prelucrrile aferente modului real de reprezentare informatic sunt efectuate "n culise", ascunse de ceea ce utilizatorul percepe ca aciune a sistemului. Tratarea tranzacional vizeaz cerina meninerii strii de coeren a datelor la ncheierea oricrei actualizri. Spre exemplu, memorarea unei comenzi trebuie s includ att adugarea unei nregistrri n tabela COMENZI ct i a nregistrrilor (una, dou sau mai multe) aferente din BUNURI_COMANDATE. Dac dup inserarea nregistrrii din COMENZI se produce un incident care mpiedic adugarea, parial sau integral, a nregistrrii sau nregistrrilor corespunztoare n BUNURI_COMANDATE, trebuie anulat i nregistrarea deja memorat n COMENZI. n ali termeni, memorarea unei comenzi se poate considera ncheiat numai atunci cnd s-au adugat, corect, nregistrrile corespunztoare n ambele tabele. n consecin, toate prelucrrile necesare asigurrii consistenei unei tranzacii trebuie s fac parte din aceeai ULP/PL. 2.structura prelucrrilor: Din punct de vedere al prelucrrilor, ULP/PL este o subdiviziune a lucrrii, care asigur o finalitate sau o funcionalitate perceptibil ca atare pentru utilizator. Regul: MED din MCP devine OBIECT UTILIZATOR n MLP Criterii generale privind structurarea n ULP/PL: Frecvena de prelucrare a ULP/PL; Grupurile/categoriile de utilizatori ale ULP/PL Omogenitatea ;i similaritatea prelucrrilor cerine de securitate similare. Criterii specifice privind structurarea n ULP/PL: Finalitatea lucrrii informatizabile conservarea obiectelor utilizator respectarea caracterului tranzacional al prelucrrilor prin intermediul RIR(restric iilor de integritate referenial).

1.1.1Compoziia ULP/PL
Prin excelen, SIG se caracterizeaz prin exploatarea uneia sau mai multor baze de date. n consecin, prelucrrile ce compun lucrrile solicitate de ctre utilizatori trebuie traduse n aciuni de consultare i actualizare a unor seturi de nregistrri aflate n diverse tabele. "Semnificaia acestor seturi este cuprins n cerine; expresia lor informatic depinde de structura de tabele, cmpuri, chei primare i externe definite n cursul proiectrii logice a datelor. Regul: MED din MCP devine OBIECT UTILIZATOR n MLP 1.ULP/PL conine structuri responsabile cu prezentarea Marea majoritate a lucrrilor efectueaz un schimb de date cu exteriorul, fie prin preluarea de date noi, care nu sunt nc memorate (sau nu fac parte dintre cele pe care sistemul le memoreaz) fie prin furnizarea de rapoarte, afiate sau imprimate. Prelucrrile specifice acestei comunicaii compun o a treia structur, responsabil cu prezentarea fa de partenerul uman cu care are loc. Exist, n acest cadru, aspecte legate de forma prezentrii, desemnate prin termenul generic de interfa i comenzi, reguli i restricii legate de coninutul prezentrii, care dirijeaz comunicarea cu utilizatorul (sau logica dialogului). Modelul logic al prelucrrilor efectuate de fiecare ULP/PL se articuleaz, n consecin, pe aceste trei straturi: prezentarea, logica problemei i gestiunea datelor. Cum prima i a treia sunt n postura de a oferi serviciile necesare efecturii prelucrrilor ce compun finalitatea ULP/PL, este firesc s se nceap cu aceasta. 1.ULP/PL conine structuri responsabile cu gestiunea datelor memorate n BD PL trebuie s "tie" cum se exprim conceptele i termenii specifici cerinelor n raport cu tablele existente i s lanseze prelucrrile de consultare sau actualizare adugare, modificare, tergere aferente. 3.ULP/PL conine structuri responsabile cu logica problemei(specificul de business) Lucrarea, aa cum este formulat n cadrul cerinelor, are o anumit finalitate spre exemplu, emiterea unei comenzi de cumprare i preconizeaz, pentru atingerea acesteia, o suit de pai, "logici" pentru utilizator. Ordinea i regulile dup care se fac acetia depind de natura lucrrii sau sunt fixate de ctre utilizator. Apare, prin urmare, o a doua structur, responsabil cu logica de business a lucrrii sau, mai general, cu logica problemei. Aceste trei structuri se articuleaz ca nivele ale arhitecturii ULP/PL (Figura 4.12).

Figura 4.12 Arhitectura general a ULP/PL

Prezentarea cuprinde: schimbul de date cu utilizatorul, definit sub forma unor machete de ecran sau de rapoarte, n care figureaz setul de date introduse sau afiate i articularea structural a acestora; comenzile pentru utilizator, definite prin efectele pe care le au i prin regulile i restriciile de utilizare.

Logica problemei caracteristic fiecrei ULP/PL este definit informatic sub forma unor aciuni sau acte considerate valide i, n consecin, acceptate i executate - i a regulilor care definesc aceast validitate. Pe acest nivel se regsesc, de asemenea: regulile de gestiune restriciile de integritate relaiile de calcul cuprinse n cerinele sistemului Gestiunea datelor cuprinde schemele externe sau subschemele necesare ULP/PL pentru obinerea datelor necesare sau pentru efectuarea actualizrilor de care este responsabil. Acestea se pot defini grafic sau direct sub form de interogri SQL.

1.1.1Procedura logic
Procedura logic desemneaz nlnuirea de ULP/PL necesare pentru executarea unei lucrri informatizabile (vezi studiul de caz, pentru exemplificare).

1.1.2Confruntarea cu BD (validarea modelelor)

Dup definirea fiecrei ULP/PL, se confrunt schema/schemele sale externe cu BD pentru a identifica i corecta: absena din tabele a unor cmpuri necesare prelucrrii; imposibilitatea de a face asocierile necesare ntre datele aflate n table diferite. Dup ce au fost proiectate toate ULP/PL din sistem, se identific i se elimin eventualele cmpuri de date care nu sunt folosite n nici o prelucrare.

MLP EXEMPLUL 1: GESTIUNEA si DECONTAREA PRODUSELOR FINITE

Actori externi

Pbc
Banca EXC

Actori externi

Pf
Exemplu 2 GESTIUNEA CREDITELOR BANCARE( c o ntinuarea

MCP )

ex din cursul

3.2.MLP Restricii de Integritate Referenial: RIR1 CLI.cnp = CO.cnp RIR2 CO.nrco = CH.nrco RIR3 /RATE. nrco = CO.nrco RIR4 CH.nrchit = /RATE.nrchit

OBIECTUL UTILIZATOR 1(OB_1) este CLICO/RATE provenit din MED1 care va fi activat prin PL1 OBIECTUL UTILIZATOR 2(OB_2) este COCHITANTE/RATE provenit din MED2 care va fi activat prin PL2

Desfacere F

Actori externi

P PL2
Exemplu 3 GESTIUNEA BUNURILOR(autor

prof. Dr. D. Zaharie)

Modelarea logic a datelor

Transpunerea modelului conceptual al datelor n modelul logic relaional

Aplicarea regulilor de transpunere a modelului conceptual al datelor (entitate-asociere) n modelul logic relaional conduce la urmtoarele tabele, cmpuri, chei primare i chei externe: FURNIZORI (Cod fiscal, Cod reg com, Denumire fz, Adres fz, Banca fz, IBAN fz) BUNURI (Cod bun, Denumire bun, Caracteristici,UM bun, Pre prestabilit) ANGAJAI (Cod intern ang, Nume ang, Prenume ang, Funcie, Loc munc, Statut ang) GESTIUNI (Nr gestiune, Denumire gestiune, Amplasare)

Serv CON

COMENZI (Nr comand, Data emiterii, Adresa livrare, Cod fiscal furnizor, Cod angajat responsabil) FACTURI (Nr factur, Data facturii, Data intrrii, Statut acceptare, Cod fiscal emitent, Nr gestiune, Nr comanda) NRCD (Nr nrcd, Data nrcd, Cod fiscal furnizor, Nr factur, Nr gestiune primitoare) ORDINE-PLAT (Nr op, Data op, Suma, Cod intern ang autorizare, Cod fiscal furnizor, Nr factur achitat) BUNURI-COMANDATE (Cod bun, Nr comand, Cantitate comandat, UM comand, Termen livrare, Pre convenit) BUNURI-FACTURATE ( Cod bun, Cod fiscal furnizor, Nr factur, Cant facturat, UM facturare, Pre facturare) BUNURI-RECEPIONATE (Cod bun, Nr nrcd, Cantitate cf doc, Cantitate intrat, Pret achizitie, UM cf doc, Statut recepie) C OMENTARII Deoarece pentru factur a fost menionat n MCD o restricie structural (restricia 7), cheia primar a tabelei respective este compus din cmpul Numr factur i din cheia extern Cod fiscal emitent, care exprim rolul entitii FURNIZOR n asocierea Emitent. n consecin, toate cheile externe privitoare la factur sunt compuse din aceste dou cmpuri (spre exemplu, BUNURIFACTURATE are cheia primar compus din cmpurile Cod bun, cheie extern n raport cu tabela BUNURI mpreun cu Nr factur i Cod fiscal emitent, cheie extern n raport cu tabela FACTURI). Modelul conceptual al prelucrrilor aduce o serie de elemente suplimentare n modelul logic al datelor. Sincronizarea lucrrilor presupune punerea n ateptare a evenimentelor survenite, pn n momentul n care condiia de sincronizare este verificat. Din consultarea modelului se constat c evenimentele ce particip la sincronizri sunt NRCD, Facturi, Facturi nesosite, Facturi refuzate, Facturi acceptate integral sau parial. Pentru a marca faptul c sunt n ateptare, pentru primele dou s-a adugat, fa de MCD, cte un atribut care s precizeze statutul acestora. n cazul NRCD, atributul statut recepie este plasat n tabela BUNURI_RECEPIONATE, pentru a putea reprezenta, n mod independent, starea fiecruia dintre bunurile consemnate n document i poate primi urmtoarele valori: n (netratat), a (acceptat), c (custodie - intrat dar neacceptat). n cazul facturii, atributul statut acceptare se afl n tabela FACTURI i poate lua una dintre valorile: n (netratat), a (acceptat), r (refuzat). n ambele cazuri, valoarea n indic starea de ateptare un nrcd a fost introdus i memorat, dar prelucrarea poate continua numai dup apariia facturii i, simetric, factura a fost introdus i memorat, dar se ateapt i nrcd corespunztoare. Restul evenimentelor sincronizatoare sunt stri generate prin prelucrri efectuate n sistem iar reprezentarea lor se face n raport cu tabelele existente. Facturile acceptate, spre exemplu, sunt acelea pentru care atributul Statut acceptare are valoarea a. Modelarea logic este de asemenea momentul n care trebuie s se decid n privina reprezentrii atributelor derivate: prin memorare sau prin recalculare la fiecare consultare. n studiul de caz prezent s-a optat pentru recalculare, ceea ce face ca aceste atribute s nu mai apar n tabele dar s solicite, n compensaie, redactarea de interogri pentru obinerea lor. Valoarea acceptat, spre exemplu, se obine nsumnd valoarea bunurilor intrate (bazat deci pe cantitile intrate i acceptate) din toate nrcd (unul sau mai multe) corespunztoare facturii respective sau nsumnd valorile bunurilor calculate pe baza cantitilor facturate, atunci cnd nu s-a ntocmit nrcd (n termeni de structur a BD, factura are cmpul Nr gestiune completat i implicit, verificat prin RI 8, nu exist nici un nrcd care se refer la ea).

Transpunerea relaional
Numrul RI 1 2 3 4 5

restriciilor

de

integritate

modelul

logic

6 7 8 9 10 11 12

Tabele i cmpuri implicate BUNURI.UM bun BUNURI_FACTURATE.Pret facturare BUNURI_COMANDATE.Pret convenit BUNURI_COMANDATE.UM comanda BUNURI.UM bun BUNURI_FACTURATE.UM facturare COMENZI.Data emiterii BUNURI_COMANDATE.Termen livrare ORDINE_PLATA.Suma BUNURI_RECEPTIONATE.Cantitate intrata, BUNURI_RECEPTIONATE.Statut receptie BUNURI_FACTURATE.Pret facturare FACTURI.Statut acceptare ANGAJATI.Statut ang FACTURI.cheia primar FACTURI.Nr gestiune NRCD.Nr gestiune primitoare BUNURI_COMANDATE.Cantitate comandata BUNURI_FACTURATE.Cantitate facturata BUNURI_RECEPTIONATE. Cantitate intrata BUNURI. Pret prestabilit BUNURI_COMANDATE.Pret livrare BUNURI_FACTURATE.Pret facturare COMENZI. Data emiterii BUNURI_COMANDATE.Termen livrare FACTURI.Data facturii FACTURI.Data intrarii COMENZI.Data emiterii NRCD.Data nrcd

Tabelul 41Tabelele i cmpurile implicate n restriciile de integritate definite la modelarea conceptual a datelor

1.1.1Modelarea logic a prelucrrilor

Varianta de desfurarea a prelucrrilor folosind viitorul sistem informatic definit n cadrul modelrii conceptuale include urmtoarele 7 lucrri ce urmeaz a fi executate cu mijloace informatice: emitere comenzi, emitere nrcd, nregistrare intrri fr factur, acceptare factur, nregistrare intrare bunuri, nregistrare bunuri necomandate, plat facturi. Toate acestea fac obiectul modelrii logice a prelucrrilor. Pentru exemplificare, a fost aleas lucrarea Emitere nrcd.

Emiterea nrcd
Din perspectiva utilizatorului, lucrarea servete pentru generarea nrcd pe baza rezultatelor recepiei i imprimarea pe hrtie a documentului aferent. Aceste dou funcionaliti conduc la definirea a dou ULP/PL (ULP/PL), care compun, mpreun, procedura logic aferent emiterii nrcd (Figura 4.13). Pentru fiecare ULP/PL structurarea continu pe cele trei nivele de arhitectur: prezentare, logica problemei i gestiunea datelor, n care logica problemei are rolul determinant.

Figura 4.13 Procedura logic EMITERE NRCD

ULP/PL pentru generarea nrcd

a. Logica problemei
Generarea nrcd presupune: introducerea codului fiscal al furnizorului; introducerea numrului gestiunii primitoare; introducerea numrului facturii furnizorului (posibil compus dintr-o serie i un numr), dac acesta este cunoscut; atribuirea automat a numrului i datei documentului (implicit data curent); specificarea bunurilor recepionate, unul cte unul; memorarea n BD. Pentru fiecare bun recepionat, specificarea presupune: introducerea codului bunului; introducerea unitii de msur, cantitii i preului unitar (preul de achiziie) din documentul nsoitor; verificarea unitii de msur: dac aceasta nu coincide sau nu este un multiplu al unitii de referin din tabelul BUNURI, se emite un mesaj de avertisment; introducerea cantitii intrate n gestiunea respectiv (recepionate) i calcularea valorii intrrii.

Avnd n vedere c intrrile de bunuri se bazeaz pe comenzi prealabile, furnizorii i bunurile ar trebui s fie deja prezente n BD. Cum n practic nu sunt excluse anumite situaii particulare, este necesar s se prevad posibilitatea de a insera un furnizor nou (dac este prima cumprare de la acesta) i de a aduga bunuri noi, cu toate elementele corespunztoare: cod bun, denumire, caracteristici, um, pre prestabilit. Deoarece acestea conduc la adugarea de nregistrri n tabelele FURNIZORI i BUNURI, este necesar asigurarea accesului la ULP/PL aferente pe parcursul prelucrrilor pentru generarea nrcd.

a. Prezentarea
Nivelul de prezentare vizeaz setul de date afiate i amplasarea lor n ferestra de ecran prin care utilizatorul interacioneaz cu sistemul, setul de comenzi prin care utilizatorul poate interveni i dirija prelucarea de la tastatur sau mouse i logica dialogului, determinat, pe de o parte, de logica problemei i, pe de alt parte, de adaptarea strii comenzilor la starea curent a prelucrii. Schia ferestrei de ecran specifice acestei lucrri este prezentat n figura 4.14.

Figura 4.14 Schia ferestrei de ecran pentru introducerea nrcd

Comenzile disponibile pentru utilizator sunt urmtoarele: memoreaz nrcd, continu, nchide, anuleaz, furnizor nou, articol nou, imprim nrcd. Ultimele trei comenzi apeleaz ULP/PL aferente prelucrilor la care se refer, dup care se revine automat la prelucrarea n curs. n contextul ferestrei de ecran preconizate i a comenzilor menionate, logica dialogului este urmtoarea: 1. Ferestra de ecran se deschide pentru un nrcd nou. 2. Utilizatorul tasteaz sau selecteaz din list, furnizorul i gestiunea primitoare. Dac bunurile au venit nsoite de factur, se tasteaz numrul acesteia. 3. Pentru fiecare dintre bunurile primite: a. se tasteaz sau se selecteaz din list codul bunului i unitatea de msur menionat n documentul care a nsoit bunurile de la furnizor. Sistemul rspunde afind denumirea bunului corespunztor codului menionat i verificnd unitatea de msur. Dac aceasta nu este identic sau nu este un multiplu al unitii de msur memorate n sistem pentru bunul respectiv, se emite un mesaj de avertisment, dar prelucrarea poate continua

b. se tasteaz cantitatea i preul unitar din documentul nsoitor i cantitatea intrat, dup care sistemul calculeaz i afieaz valoarea intrrii. 4. Dup introducerea tuturor bunurilor, se cere memorarea nrcd. Sistemul emite un mesaj prin care confirm memorarea, blocheaz aceast comand pentru a evita acionarea repetat i face activabil comanda de imprimare. 5. Utilizatorul poate opta pentru comanda de continuare cu un nou nrcd sau pentru oprire. n orice moment, pn la lansarea imprimrii, utilizatorul poate abandona tratarea nrcd n curs prin comanda anuleaz, care terge toate datele introduse i revine la starea iniial. Dinamica activrii-dezactivrii comenzilor pe msura desfurrii prelucrrilor este sintetizat n tabelul urmtor. Stare prelucrare La iniierea unui nrcd La tastarea primului caracter Dup introducerea codului, um, cantitii i preului primului bun Dup acionarea comenzii de memorare Dup acionarea comenzii de imprimare Memor eaz Impri m Contin u Anulea z nchi de

Tabelul 42 Comenzi activabile n cursul generrii unui nrcd.

a. Gestiunea datelor
Tabelele al cror coninut este consultat sau actualizat pentru emiterea nrcd sunt urmtoarele (Figura 4.15): NRCD, n care se adaug o nregistrare pentru noul nrcd; BUNURI_RECEPIONATE, n care se adaug cte o nregistrare pentru fiecare bun intrat; FURNIZORI, GESTIUNI, BUNURI, din care sunt obinute, prin consultare, datele necesare i cu care sunt corelate, prin chei externe, nregistrrile nou introduse din NRCD i BUNURI_RECEPIONATE; Opional, tabelul FACTURI poate oferi referina privitoare la numrul facturii creia i corespunde recepia, n msura n care aceasta a fost deja memorat n sistem.

Figura 4.15 Subschema datelor pentru emiterea NRCD

ULP/PL pentru imprimarea NRCD

a. Logica problemei
NRCD este un document tipizat, care are un coninut minimal obligatoriu, din care se regsete doar o parte n setul de date memorate n sistem. Elementele care lipsesc, dar care trebuie s figureze n document, sunt urmtoarele: numele i prenumele membrilor comisiei

de recepie, numele i prenumele gestionarului care preia bunurile, tipul i numrul documentelor nsoitoare, mijlocul de transport i datele de identificare ale delegatului. n consecin, logica problemei, aici extrem de simpl, presupune introducerea acestor date (care nu se memoreaz, ci servesc doar pentru imprimare) urmat de imprimarea nrcd curent (tratat n ULP/PL anterioar). Imprimarea nu poate fi declanat dac nu s-au completat datele minimale obligatorii, respectiv membrii comisiei de recepie, numele gestionarului, documentul sau documentele nsoitoare, mijlocul de transport i delegatul.

Figura 4.16 Schia ferestrei de ecran pentru introducerea datelor suplimentare necesare imprimrii nrcd

b. Prezentarea
Prezentarea cuprinde dou ferestre de ecran: prima, prin intermediul creia se introduc datele adiionale menionate anterior i cea de a doua, care afieaz imaginea nrcd n forma imprimabil (modelul de document tipizat, cod 14-3-1A). Comenzile oferite utilizatorului sunt: imprim, pentru declanarea propriu-zis a imprimrii, vizualizeaz/completeaz, pentru comutarea ntre cele dou ferestre de ecran, anuleaz, continu, nchide, comune cu cele de la ULP/PL precedent. La demararea ULP/PL, este activ implicit fereastra de completare a datelor. Comenzile vizualizeaz i imprim sunt independente dar continuarea cu un nou nrcd sau nchiderea sunt posibile numai dup ce documentul curent a fost imprimat (Tabelul 43). Anuleaz suprim toate datele introduse i reface starea iniial a acestei ULP/PL; continu i nchide sunt, aa cum s-a menionat, identice ca aciune cu cele specificate la generarea nrcd. Stare prelucrare La tastarea primului caracter Dup ce comisia de recepie, gestionarul, mijlocul de transport i delegatul sunt completate sau modificate Dup acionarea comenzii de vizualizare Dup acionarea comenzii de imprimare Vizualize az Impri m Contin u Anulea z nchi de

Tabelul 43 Comenzi activabile la imprimarea nrcd.

c. Datele

Gestionarul i membrii comisiei de recepie sunt angajai ai organizaiei: n consecin, numele i prenumele acestora se obin din tabelul ANGAJAI. Toate celelalte date suplimentare sunt temporare: se stocheaz n variabile locale doar pn la acionarea comenzilor continu, nchide sau anuleaz, dup caz. Implicit, la toate acestea se adaug ntreaga subschem de date a ULP/PL de generare a nrcd.

1.1 Probleme propuse

a. Elaborai modelul logic al prelucrrilor pentru lucrarea care asigur actualizarea nomenclatorului de bunuri, prin adugarea de bunuri noi, modificarea unor date ale bunurilor existente sau suprimarea unora dintre acestea (lucrare solicitat n problemele propuse pentru modelarea conceptual): structurarea n ULP/PL , logica problemei, prezentarea i datele aferente fiecreia dintre ele. b. Asigurarea prelucrrilor de la punctul anterior folosind o unic fereastr de ecran pentru prezentare modific structura i numrul de ULP/PL ? c. Elaborai modelul logic al prelucrrilor pentru lucrarea nregistrare intrare bunuri. Ce schimbri constatai fa de lucrrile executate interactiv, unitar i imediat ? d. Redactai interogarea SQL care afieaz bunurile preluate n custodie. e. Redactai interogarea SQL care calculeaz diferenele, n plus sau n minus, dintre valoarea intrrilor de bunuri la preuri de facturare i la preuri prestabilite, ntr-un anumit interval de timp. f. Redactai interogarea SQL care afieaz diferenele la recepie (nu uitai c, n afara diferenelor cantitative, pot aprea i situaii n care anumite bunuri care figureaz n documente nu sunt primite deloc sau s fie primite bunuri care nu figureaz n documente). g. Definii structura procedurii logice aferente lucrrii acceptare factur. h. Redactai interogarea SQL care calculeaz suma acceptat aferent unei anumite facturi (nlocuind spaiile din interiorul numelor de cmpuri cu cratime). i. Elaborai modelul logic al prelucrrilor pentru lucrarea plat facturi.

1.1 Sinteza noiunilor studiate

Relaia este o submulime a produsului cartezian de N domenii, care se prezint sub form bidimensional (tabelar) pe linii i coloane, fiind numit i tabel; Tuplul reprezint o linie n cadrul tabelului, fiind numit i nregistrare (n englez record); Domeniul reprezint un set de valori pe care le poate lua o un atribut. Atributul reprezint o caracteristic care poate lua valori ntr-un domeniu, fiecrei caracteristici fiindu-i rezervat o coloan n cadrul relaiei. Cheia primar - reprezint un atribut sau un grup minimal de atribute ale crui realizri pot permite identificarea unic a unui tuplu ntr-o tabel. Cheia candidat - reprezint un atribut sau un grup de atribute care pot, prin realizrile lor, s identifice un tuplu. Cheia extern - este un atribut din schema unei tabele, care joac rol de cheie primar ntr-o alt tabel i respect cerinele de integritate referenial. Schema unei relaii reprezint lista atributelor aparinnd relaiei, cu domeniile lor. Gradul relaiei reprezint numrul de coloane (atribute) ale relaiei. Cardinalitatea relaiei reprezint numrul de rnduri ale acesteia. Unitatea logic de prelucrare (ULP/PL) este o subdiviziune a lucrrii informatizabile definit n cursul modelrii conceptuale i, n acest context, izoleaz o parte din funcionalitatea acesteia.

Logica problemei caracteristic fiecrei ULP/PL, este definit informatic sub forma unor aciuni sau acte considerate valide, precum i a regulilor care definesc aceast validitate. Prezentarea cuprinde schimbul de date cu utilizatorul, definit sub forma unor machete de ecran sau de rapoarte, n care figureaz setul de date introduse sau afiate i articularea structural a acestora. Gestiunea datelor cuprinde schemele externe sau subschemele necesare ULP/PL pentru obinerea datelor necesare sau pentru efectuarea actualizrilor de care este responsabil. Procedura logic desemneaz nlnuirea de ULP/PL necesare pentru executarea unei lucrri informatizabile.

1.2 Teste de autoevaluare

1. Se consider urmtorul fragment de model conceptual al datelor referitor la gestiunea comenzilor primite de o societate comercial:
CLIENT CodClient NumeClient AdresaClient TelefonClient
TRANSMITE

COMANDA 0,n NrComanda 1,1 DataComanda

1,n
CONTINE Cantitate Pret

GRUPA PRODUS CodGrupa DenumireGrupa 0,n

APARTINE

1,1
nlocuit

0,n PRODUS CodProdus DenumireProdus UMProdus

NLOCUIESTE
nlocuitor

0,n

0,n

Care dintre relaiile incluse n fragmentul de model logic corespunztor acestui MCD este eronat: a) CLIENT(CodClient, NumeClient, AdresaClient, TelefonClient) b) NLOCUIETE(CodProdusnlocuit, CodProdusnlocuitor) c) PRODUS(CodProdus, DenumireProdus, UMProdus, CodGrupa) d) COMANDA(NrComand, DataComand, CodClient, CodProdus) e) CONINE(CodProdus, NrComanda, Cantitate, Pre) 1. Se consider urmtorul fragment de model conceptual al datelor referitor la gestiunea resurselor umane:
ANGAJAT Marca Nume Prenume Adresa DataAngajarii 0,n
PONTEAZA NrOre SalariuOrar LUCREAZA

COMPARTIMENT 1,n CodCompartiment DenumireCompartiment

1,1
CONDUCE

0,1 0,n 0,n

PRIMESTE

1,1

PLATESTE

1,n FISA PONTAJ NrFisa DataFisa Luna Anul 0,n SPOR CodSpor DenumireSpor ValoareSpor 0,n RETINERE CodRetinere DenumireRetinere ValoareRetinere

Care dintre relaiile incluse n fragmentul de model logic corespunztor acestui MCD este eronat: a) ANGAJAT(Marca, Nume, Prenume, Adresa, DataAngajrii, CodCompartiment) b) COMPARTIMENT(CodCompartiment, DenumireCompartiment, Marca) c) FISAPONTAJ(NrFia, DataFia, Luna, Anul, Marca) d) PONTEAZ(Marca, NrFia, NrOre, SalariuOrar) e) SPOR(CodSpor, DenumireSpor, ValoareSpor) 1. Se consider urmtorul fragment de model conceptual al datelor referitor la gestiunea unei biblioteci:
TITLU CodISBN Denumire NrPagini TipCoperta 0,n
APARTINE

EDITURA 1,1
APARUT LA AnAparitie

CodEditura 0,n DenumireEditura AdresaEditura

1,n
SCRIE

1,1 EXEMPLAR NrInventar DataIntrare Disponibilitate

0,n AUTOR CodAutor NumeAutor DataNasterii Nationalitate

Care dintre relaiile incluse n fragmentul de model logic corespunztor acestui MCD este eronat: a) EDITURA(CodEditura, DenumireEditura, AdresaEditura) b) APARUTLA(CodISBN, CodEditura, AnAparitie) c) EXEMPLAR(NrInventar, DataIntrare, Disponibilitate, CodISBN) d) AUTOR(CodAutor, NumeAutor, DataNasterii, Naionalitate) e) TITLU(CodISBN, Denumire, Nrpagini, TipCoperta, CodEditura, NrInventar) 1. Se consider urmtorul fragment de model conceptual al datelor referitor la gestiunea conturilor bancare:
CONT 0,n NrCont DataDeschidere TipCont 0,n
CREDITEAZA SumaCreditoare DEBITEAZA SumaDebitoare

OPERATIE 1,n CodOperatie DataOperatie 1,n TipOperatie Explicatie 1,1 1,1

PE BAZA

1,1
DESCHIDE SOLICITA

1,n CLIENT CodClient NumeClient AdresaClient TelefonClient 0,n

1,n DOCUMENT CodDocument DataDocument TipDocument

Care dintre relaiile incluse n fragmentul de model logic corespunztor acestui MCD este eronat: a) OPERATIE(CodOperaie, DataOperaie, TipOperaie, Explicaie, CodDocument, Cod Client, NrContDebitor, NrContCreditor) b) CREDITEAZA(NrCont, CodOperaie, SumaCreditoare) c) CLIENT(CodClient, NumeClient, AdresaClient, TelefonClient) d) DEBITEAZA(NrCont, CodOperaie, SumaDebitoare)

e) DOCUMENT(CodDocument, DataDocument, TipDocument) 1. Se consider urmtorul fragment de model conceptual al datelor referitor la gestiunea unei case de schimb valutar:
CLIENT CodClient NumeClient NumarActDeIdentitate TipActDeIdentitate 1,n
SOLICITA

CURS CodCotatie DataCotatie CursVnzare CursCumparare 1,1

COTEAZA

1,1
BULETIN DE SCHIMB VALUTAR

VINDE SumaVnduta

0,n 0,n VALUTA SimbolValuta DenumireValuta TaraOrigine

NumarBSV DataBSV

1,1

1,1

CUMPARA SumaCumparata

0,n

Care dintre relaiile incluse n fragmentul de model logic corespunztor acestui MCD este eronat: a) CLIENT(CodClient, NumeClient, NumarActDeIdentitate, TipActdeIdentitate) b) CUMPARA(NumarBSV, SimbolValuta, SumaCumprat) c) BULETINDESCHIMBVALUTAR(NumarBSV, DataBSV, CodClient, SimbolValutaVndut, SimbolValutCumprat, SumaVndut, SumaCumprat) d) CURS(CodCotaie, DataCotaie, CursVnzare, CursCumprare) e) VINDE(NumarBSV, SimbolValut, SumaVndut)

1.1 Bibliografie
Rspunsuri grile: 1-d 2-c 3-e 4-a 5-d

Unitatea de nvare 5
MODELAREA FIZIC(CONSTRUIREA I TESTAREA SISTEMULUI)..........CURSURILE 11,12,13.

4. Construirea i testarea sistemului

Construirea sistemului are dou obiective: Adaptarea soluiei logice la specificul platformei pentru care va fi dezvoltat i pe care va funciona sistemul. Implementarea propriu-zis. n consecin, construirea are ntotdeauna asociat o platform, care, n cazul de fa, este Microsoft Access 2007.

1 2 3 4 5
5.1 Obiective
a) Aspecte generale privitoare la implementarea sistemului folosind Access 2007. b) Crearea BD: proprietile principale ale cmpurilor, crearea tabelelor, implementarea restriciilor de integritate pe domeniu, definirea cheilor primare i a indecilor, integritatea referenial i definirea cheilor externe. c) Aspecte generale privitoare la crearea aplicaiei. d) Crearea aplicaiei: formulare pentru dirijarea prelucrrilor, formulare pentru prelucrri, rapoarte i macrocomenzi. e) Testare aplicaiei: aspecte generale, costuri, modelul de proces pentru testarea sistemelor informatice, abordri privitoare la definirea scenariilor de test, abordri privitoare la execuia scenariilor de test.

1.1 Arhitectura general

1.1.1Separarea datelor de aplicaie
Dezvoltarea de sisteme informatice de gestiune folosind Access 2007 urmeaz un model axat pe o baz de date unic, exploatat concurent de ctre posturile de lucru. n consecin, stilul arhitectural optim const n separarea sistemului n dou pri: prima, n care se regsesc numai tablele cu date i cea de a doua, care cuprinde restul elementelor, respectiv interogrile, formularele, rapoartele, macro-urile i modulelele de cod. Fizic, fiecare dintre acestea apare pe disc sub forma unui fiier baz de date (fiier ACCDB). Se ajunge astfel la o baz de date i o baz de proceduri(aplicativ). Dac se are n vedere o funcionare multitulizator, baza aplicativ se instaleaz pe fiecare post de lucru. BD se va afla pe un calculator distinct, accesibil prin reea de la toate posturile de lucru.

1.1.2"Obiectele" sistemului
Construirea sistemului se realizeaz n Access folosind cele ase tipuri de "obiecte" oferite de ctre acesta: tabele, interogri, formulare, rapoarte, macro-uri i module de cod-program. Tablele1 Tables - se separ, conform recomandrii anterioare, de restul obiectelor. Fac excepie tablele temporare i tablele statice, a cror amplasare n spaiul aplicaiei permite reducerea traficului de date ntre cele dou structuri. Tablele temporare sunt tablele folosite din considerente locale ale lucrrilor, fr a face parte din modelul logic al sistemului
1 Table sau tabele

Formularele Forms - sunt obiecte prin care utilizatorul interacioneaz cu sistemul. Din punctul acestuia de vedere, formularele sunt cele care asigur introducerea de date de la tastatur, activarea comenzilor disponibile n sistem prin intermediul tastaturii i al mouse-ului i consultarea pe ecran a informaiilor provenite din BD sau a mesajelor emise n cursul funcionrii. Din punct de vedere al BD, formularele ar trebui s fie modalitatea unic de actualizare a tablelor, deoarece, pe lng elementele de grafic i ergonomie pe care le ofer, dau posibilitatea verificrii tuturor restriciilor de integritate (mai complet dect restriciile care pot declarate la nivelul tablelor) i permit actualizarea corelat a mai multor table (ntr-un mod transparent pentru utilizator). Din punct de vedere al aplicaiei, formularele sunt cele care activeaz i coordoneaz execuia diverselor prelucrri, fiind, din acest punct de vedere, obiecte pereche unitilor de prelucrare. Interogrile Queries sunt cereri (instruciuni) SQL de consultare i actualizare a BD folosite n funcionarea sistemului. n mod uzual, interogrile servesc drept surse de date pentru formulare, rapoarte sau componente ale acestora. Din perspectiva sistemului, pot fi memorate ca uniti distincte (stored query), primind aadar un nume sau pot fi ncorporate anonim n structurile care le folosesc (embedded query). Interogrile se obin fie prin interfaa QBE (Query By Example) fie prin redactare direct n limbajul SQL. Indiferent de modul de creare, execuia lor este oprimizat intern, ceea ce le recomand ca soluie prioritar n efectuarea oricrei consultri sau actualizri. Rapoartele Reports - constituie categoria de obiecte specializate n furnizarea de informaii n format imprimabil. Aceasta face ca, alturi de funcionalitile de grupare, structurare i calcul axate pe coninutul datelor prezentate, s existe i funcionaliti de gestionare a formei i de punere n pagin a rezultatului. Sursele de date ale rapoartelor sunt, ca i n cazul formularelor, tablele i interogrile, memorate sau ncorporate. ??????????????????P aici am citit pt cursul an III CIG Macrocomenzile, denumite pentru simplitate macro-uri Macros sunt structuri care permit, ntr-o manier simpl i transparent, automatizarea prelucrrilor aferente formularelor i rapoartelor. Un macro este un grup de aciuni memorate mpreun n scopul execuiei lor automate, ca un tot unitar. Aciunile corespund, cu cteva excepii, comenzilor i interveniilor pe care utilizatorul le poate declana sau ntreprinde prin intermediul tastaturii sau al mouse-ului. Pentru a rspunde ct mai complet funciei de automatizare, macro-urile includ mecanisme de execuie condiionat i iterativ i de apelare a altor tipuri de obiecte active, inclusiv alte macro-uri. Funcionalitile oferite sunt suficient de bogate pentru a permite practic realizarea unei pri nsemnate din prelucrrile necesare sistemului fr a recurge la programare. Ca i interogrile, macro-urile pot fi memorate distinct, cu nume proprii sau pot rmne anonime, ncorporate n formularele sau rapoartele n care sunt utilizate. Modulele Modules stocheaz unitile de program (proceduri, funcii, clase de obiecte) dezvoltate pentru realizarea sistemului. Programarea d acces la cea mai larg gam posibil de prelucrri i permite un control mai complet i mai nuanat comparativ cu macro-urile. Redactarea programelor se face n limbajul VBA (Visual Basic for Applications). Exist dou tipuri de module: clas i standard. Ca regul general, aplicaia se construiete n jurul formularelor. Acestea extrag i actualizeaz datele direct din table sau prin intermediul interogrilor. Tot formularele sunt cele care reacioneaz la evenimentele survenite n cursul lucrului, prin declanarea execuiei macro-urilor i a unitilor de program (subrutine i funcii) stocate n module. Rapoartele sunt o alt categorie de obiecte care reunesc table, interogri, macro-uri i uniti de program. Spre deosebire de formulare, acestea sunt pasive, n sensul c nu efectueaz dect consultri de date, ceea ce le face, n raport cu formularele, mai simple i mai limitate.

1.2 Crearea BD
Punctul de pornire n crearea BD este reprezentat de structura definit n cursul proiectrii logice. Pe nivelul fizic se fac adaptrile necesare la platforma folosit i se definesc toate detaliile necesare constituirii sale. Elementele implicate aici sunt tablele i legturile dintre ele iar n cadrul fiecrei table, cmpurile componente, cheile primare, restriciile de integritate i indexrile cerute de optimizare.

1.2.1Particulariti n definirea cmpurilor

n raport cu standardul SQL ANSI folosit n cursul proiectrii logice, particularitile vizeaz regulile de formare a numelor de cmpuri i tipurile acestora. n Access, sunt acceptate diacriticele i spaiile n componena numelor de elemente. n aceste condiii, numele trebuie delimitate prin ncadrarea ntre paranteze drepte. Gama tipurilor de date existente n Access este diferit dect cea specificat n standardul menionat iar pentru unele dintre tipurile similare, se folosesc denumiri (cuvinte cheie) diferite. Avnd n vedere aceste deosebiri, este fireasc revederea definirii cmpurilor din proiectarea logic. Tabelul urmtor prezint cteva dintre caracteristicile cmpurilor i a tipurilor de date specifice Access.

Proprietate Field Name

Rol denumirea cmpului tipul campului

Data Type

Explicaii - lungimea maxim 64 caractere alfanumerice, majuscule/minuscule - se poate utiliza caracterul underline (ex:NR_DOC) - nu poate conine caracterele .,!,[,] - ex: CIF, Nr contract, Data_factura -tipul Text este alfanumeric pe maxim 255 caractere, lungimea implict fiind de 50 caractere;ex: den_client,Text,50 -tipul Number permite declararea atribute lor de tip numeric, prediferite pe diferite inter vale admisibile de valori i zone de memorie de diferite lungimi; -poate asigura descrierea urmtoarelor subtipuri: integer, long integer, single, double, byte (acestea sunt prezente n proprietatea Field size) -Field Size asigur modificarea lungimii atributului pentru a respecta descrierea exact a acestuia n raport de semantica i valorile sale reale. -specifica]iile fundamentale sunt descrise n continuare: Subtip interval de valori numeric Integer [-2768,32767], pe lungime de 2 octei Long -2147483648, 2147483647] Integer Single [-1,401298*10-45, 3,402823*1038] pentru numere pozitive [-3,402823*1038,-1,401298*10-45] pentru numere negative Double [4,94065645841 247*10-324,-1,797 69313486231*10308] pentru numere pozitive i [-1,797 69313486231*10308,4,9406564584 1247*10-324] pen tru numere negative Decimal [-1028-1,1028-1] i permite precizia de 28 poziii prin activarea proprietii Precision; n memorie sunt utilizai 12 bytes Byte [0, 255 pe lungime de 1 byte;tipul este preluat din DA , -tipul AutoNumber poate fi utilizat pentru campurile ale cror valori sunt incrementabile; AutoNumber poate genera automat o valoare numeric corespunztor subtipului number-integer, incrementat cu valoarea 1 (Increment) sau prin intermediul unei generri automate (Random) -n tabelul urmtor sunt prezenta te specificaiile tipului AutoNumber : Subtip Interval de valori

AutoNumber -valorile atribuite pot fi secveniale, prin proprietatea New Values= Increment sau aleatoare prin proprietatea New Values=Random -atributul ocup 4 bytes, cu precizarea c atributele de tip AutoNumber sunt neactualizabi le

Number

Description

Field Size Format

Input Mask

-tipul este utilizat pentru campuri care iau valori de tip GUID, avnd o dimensiune de 16 octei -tipul Currency permite declararea campurilor de tip numeric, cu ablonul implicit de 9(15).9(4) avnd dimensiunea de 8 octei. Acest tip poate stoca o valoare numeric, ntr-un format fix cu maxim 4 zecimale, cu posibilitatea utilizrii erorilor de rotunjire. Valoarea va avea ataat simbolul valutar. -tipul Date/Time permite declararea cmpurilor lor de tip dat calendaristic. -tipul Yes/No permite declararea cmurilor de tip logic vnd urmtoarele posibile valori: adevrat(valoarea 1) sau fals(valoarea 0). o descriere a -aceast descriere a cmpului este opional i prezint importan rolului pe numai pentru proiectant i pentru verificri ulterioare. care l are campul respectiv dimensiunea -permite definirea dimensiunii maxime pentru tipurile de date Number, cmpului AutoNumber, Text; formatul de -permite definirea formatului de afiare a datelor specifice unui afiare atribut,separat pe tipuri de atribute, astfel: Cmpuri numerice: General Number, Currency, Fixed, Standard, Percent, Scientific Cmp tip dat calendaristic: General Date, Long Date, Medium Date, Short Date, Long Time, Medium Time, Short Time - pentru definirea abloanele InputMask pot fi utilizate formatul urmtoarele caractere: pentru Mod utilizare introducerea Caracter datelor A -litere i coninut incomplet & -orice caracter, spaiu, dar nu este permis un coninut incomplet C -orice caracter, spaiu, este permis un coninut incomplet 0 -cifre 0-9, fr semn, nu este per mis un coninut incom plet L -litere A-Z, nu este permis un con inut incom plet 9 -cifre 0-9, spaiu, este permis un coninut incom plet # -cifre 0-9, semn, spaiu, este per mis un coninut incom plet < -setul de caractere introduse este convertit n minuscule Replication ID

> . sau , : sau ; Default Value Validation Rule Validation Text Required

-setul de caractere introduse este convertit n majuscule -separator pentru mii sau zecimale -separator pentru date calendaris tice

-se poate utiliza atunci cnd sunt utilizabile valori predefinite Valoarea pentru cmpul curent implicit reguli de -proprietatea Validation Rule implementeaz restriciile relative la validare domeniul cmpurilor prin intermediul unor expresii Access

mesaj eroare

de - Access poate detecta situaiile n care regulile de validare nu sunt ndeplinite, moment n care afieaz mesajul de eroare definit la nivelul proprietii Validation Text obligativitate dac valorile ale unui cmp sunt obligatorii de introdus atunci de va definirii unei specifica opiunea Yes valori

1.2.2Crearea tabelelor Crearea fiecrui tabel presupune definirea cmpurilor i a cheii primare. Fiecare cmp posed o serie de proprieti, prin a cror setare se precizeaz caracteristicile dorite ale datelor memorate n spaiul acestuia. Unele dintre acestea proprieti sunt omniprezente, n timp ce altele depind de tipul datelor. Figura 5.1 prezint, pentru exemplificare, proprietile cmpului Data nrcd din tabelul NRCD.

Figura 5.1 Lista de proprieti a cmpului Data nrcd din tabelul NRCD

1.2.3Restriciile de integritate de domeniu

SGBD Access admite, n mod implicit, declararea de restricii de integritate doar n cadrul fiecrui tabel. n acest scop, se utilizeaz proprietatea Validation Rule, care este prezent la nivelul fiecrui cmp i la nivelul tabelului. n consecin, restriciile care vizeaz strict coninutul unui cmp se declar n lista sa de proprieti iar restriciile care introduc corelaii ntre cmpurile din tabel, n lista de proprieti a tabelului. Proprietile Required i Allow zero length pot fi utile de asemenea n declararea unor restricii de integritate. Dac se dorete

definirea restriciilor de integritate pe domeniu ntre tabele singura soluie este oferit de limbajul SQL prin intermediul clauzei CREATE/ALTER TABLE ... CHECK (restricie). Restriciile de integritate a cror aciune include coninutul mai multor tabele diferite, cu excepia restriciilor de integritate referenial, pot fi declarate numai prin module de cod sau macrocomenzi n formularele de introducere a datelor, ataate la proprietatea de tip eveniment Before Update a structurii vizate- zon de tip Text Box, Combo Box .a.m.d. (control) sau a nregistrrii (form). Tabelul 51 trece n revist toate restriciile de integritate cuprinse n modelul logic al datelor din studiul de caz care pot fi implementate n cadrul tabelelor. Pentru exemplificare, figura 5.2 prezint maniera de declarare a restriciei 12 din studiul de caz i a restriciei privitoare la cmpul Statut acceptare, adugat prin modelul logic. Numru l RI 1 6 7 9 Tabele i cmpuri implicate BUNURI.[UM bun] ANGAJATI.[Statut ang] FACTURI BUNURI_COMANDATE. [Cantitate comandata] BUNURI_FACTURATE. [Cantitate facturata] BUNURI_RECEPTIONATE. [Cantitate intrata] BUNURI.[Pret prestabilit] BUNURI_COMANDATE.[Pret livrare] BUNURI_FACTURATE.[Pret facturare] Soluia de implementare n tabele proprietatea Validation Rule a cmpului proprietatea Validation rule a cmpului Cheie primar compus din dou cmpuri: Cod fiscal emitent i Nr factura proprietatea Validation rule a cmpului proprietatea cmpului proprietatea cmpului proprietatea cmpului proprietatea cmpului Validation Validation Validation Validation rule rule rule rule a a a a

10 11

12

proprietatea Validation rule a cmpului FACTURI.[Data facturii]- proprietatea Validation rule a tablei FACTURI.[Data intrarii] FACTURI
Tabelul 51 Restriciile de integritate implementabile direct la nivelul tabelelor Access

Figura 5.2 Declararea restriciilor de integritate prin proprietile Validation Rule

1.2.4Chei primare i indeci

Identificarea nregistrrilor unei table se face pe baza cheii primare. Cum cutrile cele mai frecvente se bazeaz pe aceasta, este normal crearea unui index care, n conformitate cu cerinele modelului relaional, accept numai valori unice i nenule. Acest lucru se realizeaz n Access n mod automat. Varianta cea mai avantajoas este, din acest punct de vedere, utilizarea cheilor primare de tip AutoNumber. Indexarea constituie o modalitate de optimizare important i se poate aplica nu numai pentru cheile primare, ci i pentru alte cmpuri dup care se fac cutri frecvente. Prin difereniere de indexul cheii primare, acestea poart denumirea de chei de indexare, respectiv indeci secundari.

Figura 5.3 Relaiile dintre tablele ce compun BD, relaii prin care sunt definite restriciile de integritate referenial aferente cheilor externe

1.2.5Chei externe i restricii de integritate referenial

O cheie extern se definete n Access prin crearea unei legturi (Relationships) ctre cheia primar corespunztoare, legtur pentru care trebuie activat verificarea integritii refereniale. Tipul de compunere ales la definirea cheii externe ar trebui s fie cel bazat pe corespondena reciproc (INNER JOIN), pentru a asigura un maxim de coeren. Verificarea restriciei de integritate referenial este realizat automat de ctre sistem. De asemenea, sistemul poate efectua automat i actualizrile antrenate de modificrile survenite n valorile cheilor primare implicate, prin activarea opiunilor Cascade Update Related Fields, Cascade Delete Related Fields. Aciunea lor este urmtoarea: la schimbarea valorii cheii primare dintr-o nregistrare, este ajustat automat i coninutul cheilor externe din nregistrrile care erau legate de aceasta i, respectiv, la suprimarea unei nregistrri, sunt terse automat i nregistrrile din alte tabele, legate prin chei externe de cheia primar a nregistrrii disprute. Acest mecanism funcioneaz "n cascad", pe ntregul lan de tabele legate ntre ele doar dac sunt activate opiunile amintite anterior. Figura 5.3 prezint tabelele ce compun BD din studiul de caz i cheile externe dintre acestea. Se pot observa chei externe compuse din dou cmpuri, necesare pentru referinele la factur, a crei cheie primar este format din codul fiscal al emitentului i din numrul facturii emise.

1.3 Crearea aplicaiei

Partea aplicativ a sistemului cuprinde ansamblul prelucrrilor pe care utilizatorii le realizeaz prin intermediul su. Din perspectiva fiecrui utilizator, aceasta nseamn setul de lucrri executabile informatic. Din perspectiva intern a sistemului, toate acestea apar drept ULP/PL ce graviteaz n jurul BD actualizri, consultri, copieri de siguran i restaurri declanate de comenzile transmise de utilizator, de datele introduse de acesta, de structurile i configurrile rapoartelor furnizate i nu n ultimul rnd, de regulile de protecie i securitate. n termenii tipurilor de obiecte oferite de Access, aceasta nseamn formulare i rapoarte: primele pentru interaciunea cu utilizatorii i intervenia activ asupra BD, cele din urm,

pentru actele pasive de extragere i afiare, n structuri mai mult sau mai puin complexe, a coninutului memorat.

1.3.1Conectarea la BD
Amplasarea datelor i aplicaiilor n locuri diferite impune instituirea unui mod de funcionare prin care fiecare post de lucru s aib acces, prin intermediul reelei, la datele necesare, fie pentru consultare, fie pentru actualizare. Una dintre alternativele propuse n acest scop de ctre mediul Access este conectarea (linking) la sursa sau la sursele externe de date. Stabilind o asemenea legtur, coninutul tablelor respective poate fi folosit n interogri, formulare i rapoarte ca i cnd acestea ar fi prezente local. Conectarea se poate face prin intermediul interfeei grafice sau prin subrutine VBA. Figura 5.4 prezint rezultatul legrii, pentru aplicaia aferent primului tip de post de lucru din studiul de caz. Tablele legate sunt figurate n panoul de navigare nsoite de o mic sgeat. Deoarece nu particip la nici una dintre lucrrile/procedurile logice ce sunt executate de la acest tip de post de lucru, ORDINE_PLAT nu figureaz printre tabelele accesibile.

1.3.2Structurarea aplicaiei
Dezvoltarea prii aplicative a sistemului graviteaz n jurul formularelor. Din aceast perspectiv, se pot evidenia trei tipuri de formulare: de prezentare a aplicaiei, de dirijare i de prelucrare. Primul dintre cele menionate este opional, dar confer o not de elegan i profesionalism, care are importana sa. Formularele de dirijare au menirea de a permite utilizatorului s aleag, s declaneze i, eventual, s intervin n derularea prelucrrilor dorite. Ultimul dintre tipurile menionate asigur efectuarea lucrrilor sau ale unor pri ale acestora.

Figura 5.4 Panoul de navigare n care figureaz tabelele legate din baza unic de date

Una dintre modalitile de structurare a aplicaiei const n alocarea unui formular distinct pentru fiecare lucrare informatizat. Paii (ULP/PL) pe care-i presupune lucrarea n cauz apar ca structuri distincte n cadrul formularului respectiv (aa cum se va vedea n paragrafele urmtoare). Formularele se grupeaz pe posturi de lucru tip, n funcie de lucrrile asociate acestuia i sunt coordonate de un formular de dirijare specific. Acesta din urm identific utilizatorul din postul de lucru din care este apelat i-i permite selectarea i activarea lucrrii pe care dorete s-o efectueze, n limita drepturilor care i-au fost atribuite. Formularul de identificare a aplicaiei, dac exist, este afiat pe o durat de cteva secunde, la deschiderea fiecrei sesiuni de lucru. Gruparea pe tipuri de posturi de lucru corespunde structurii de instalare i exploatare a sistemului. Un asemenea grup formeaz o structur aplicativ distinct, care se instaleaz pe fiecare post de lucru individual aparinnd tipului respectiv. Sistemul este compus fizic, n aceste condiii, dintr-o baz de date i una sau mai multe baze aplicative. Figura 5.5 prezint, pentru exemplificare, structura sistemului aferent studiului de caz. BD comun este exploatat de posturile de lucru din departamentul de aprovizionare, pentru emiterea comenzilor, a nrcd i pentru verificarea i formularea acceptului de plat pentru facturi, din zona contabilitii, pentru nregistrarea cumprrilor, a bunurilor neacceptate, preluate n custodie i din zona financiar, pentru achitarea facturilor. Pentru fiecare dintre tipurile menionate, pot exista mai multe posturi de lucru fizice: mai muli angajai care urmresc comenzile i realizarea aprovizionrilor, eventual specializai pe grupe de bunuri, mai muli salariai din contabilitate, respectiv din financiar, intervenind n sistem. Pe calculatorul aflat pe biroul fiecruia, trebuie s fie instalate programele ce permit executarea lucrrilor respective.

Figura 5.5 Sistemul informatic structurat n BD i aplicaii

1.3.3Formulare de dirijare a prelucrrilor

Dirijarea prelucrrilor se poate realiza, n Access 2007, prin intermediul formularelor sau prin particularizarea benzilor (ribbons) de comand. Un formular de dirijare este un formular obinuit, care conine doar butoane de comand. Acestea corespund lucrrilor ce pot fi executate i la acionare deschid automat formularele corespunztoare, prin intermediul unei subrutine sau unui macro ataate proprietii (On Click).

1.3.4Formulare de prelucrare
Schema arhitectural avansat anterior prevede ca pentru fiecare lucrare (task) informatizat s se creeze cte un formular distinct. Acest formular asigur: a) preluarea de la tastatur a datelor specifice; b) efectuarea fiecruia dintre paii ce compun lucrarea respectiv; c) controlul derulrii lucrrii sub aspectul succesiunii i coerenei pailor executai. Pentru a rspunde cerinelor menionate la punctul a, formularul va include casete-text sau de alte tipuri, corespunztor datelor introduse, independente sau grupate, inclusiv n structuri de tip sub-formular dac este cazul. Funcionalitile menionate la punctul b pot fi asigurate structural n mai multe moduri: printr-un formular multi-pagin, prin sub-formulare sau prin formulare etichetate (tabbed). Pentru punctul c, soluia cea mai simpl const n introducerea unor butoane de comand, care devin active sau inactive n funcie de stadiul curent al prelucrrii. Un formular multi-pagin este un formular ale crui spaiu este mprit pe vertical n mai multe pagini virtuale prin inserarea de marcaje separatoare (Page break). Se evit astfel derulrile repetate prin barele de deplasare vertical iar imaginea prezentat utilizatorului poate fi structurat n grupuri logice de date. Un sub-formular este, n termeni foarte simpli, un formular obinuit, "gzduit" n spaiul unui alt formular. n aceast relaie, formularul primitor este numit principal. Gzduirea poate fi pur grafic, cnd coninutul celor dou formulare este independent sau funcional, cnd coninutul afiat de sub-formular este corelat (sau sincronizat) cu coninutul formularului principal, prin intermediul unei perechi de cmpuri sau de grupuri de cmpuri (Link Child Fields, Link Master Fields). Un formular principal poate conine mai multe sub-formulare diferite iar fiecare sub-formular poate include, la rndul su, alte sub-formulare. Sub-formularele reprezint soluia tip pentru a trata situaiile n care ntre nregistrrile prelucrate exist un raport 1 n. n acest context, unei nregistrri n formularul principal i se pot asocia mai multe nregistrri n sub-formular. Formularele etichetate (tabbed) sunt sub-formulare care partajeaz acelai spaiu de afiare pe ecran. n orice moment, doar unul singur dintre acestea este vizibil, celelalalte fiind ascunse. Trecerea de la un sub-formular la altul se face prin selectarea etichetelor respective. Este o modalitate foarte bun de afiare a structurilor complexe, fr a ncrca excesiv ecranul. Zonele n care se plaseaz sub-formularele sunt casete pagin (page controls) ale formularului principal. Alturi de cele prezentate, se poate recurge la soluia foarte simpl de a folosi mai multe formulare independente, deschise simultan, pentru diverii pai de efectuat, deoarece n Access acestea pot comunica date ntre ele. Pentru a evita incoerenele sau erorile, nchiderea acestor formulare trebuie controlat atent, prin program. Butoanele de comand sunt casete (controls) care au comportamentul grafic al unui buton uzual. Acionarea butonului este sesizat prin proprietatea On click, la care se poate ataa o subrutin sau o macro-comand care s execute prelucrrile aferente. Activarea sau dezactivarea butonului se obine prin setarea programat a proprietii Enabled, n funcie de starea curent a lucrrii.

1.1 Testarea sistemului

Testarea este etapa care realizeaz validarea implementrii sistemului proiectat i are un scop dublu: pe de o parte se valideaz cerinele sistemului informatic iar pe de alt parte permite descoperirea erorilor. Pentru a se realiza testarea, aceasta trebuie conceput n prealabil n strict corelaie cu modul n care s-a proiectat funcionarea sistemului, de la nivelul cel mai general pn la cel mai detaliat. Ordinea activitilor de testare este ns invers, parcurgnd urmtoarele trei nivele: Pe unitai, De integrare, De sistem. Testarea pe uniti verific funcionarea separat a fiecrei uniti logice de program.

Testele de integrare vizeaz funcionarea unitilor de program n interaciune, respectiv n cadrul fiecrei proceduri logice. Testele de sistem se concentreaz asupra funcionrii ansamblului, n calitatea de software aplicativ coerent i unitar. Identificarea sursei erorilor i disfuncionalitilor i nlturarea lor presupune revenirea la oricare dintre nivelele de proiectare, inclusiv la programele surs i implic un efort creator, care conduce la ajustarea, la amelioarea proiectului. Este important ca identificarea problemelor/erorilor s se realizeze ntr-o faz ct mai apropiat de etapa identificrii cerinelor sistemului informatic deoarece costurile legate de eliminarea respectivelor probleme/erori cresc cu fiecare nou faz parcurs din cadrul dezvoltrii sistemului informatic: Faza 1. Cerine 2. Proiectare 3. Programare 4. Testare pe integrare 5. Testare de sistem 6. Exploatare Cost relativ la faza 1 1 3-6 10 uniti/de 15-40 30-70 40-1000

Tabelul 52: Costuri aproximative cu eliminarea defectelor n funcie de faza dezvoltrii sistemului informatic (IBM, GTE, et. al)

Spre exemplu, dac o anumit problem este identificat n momentul exploatrii sistemului informatic atunci costurile privitoare la rezolvarea respectivei probleme pot fi de zeci de ori mai mari dect costul identificrii problemei n faza de stabilire a cerinelor sistemului. La modul general, indiferent de tipul procesului de testare utilizat de ctre echipa de dezvoltare, pentru testare este necesar un ansamblu de date ce permite realizarea diferitelor scenarii pentru sistemul informatic dezvoltat. n corelaie cu aceste date, se stabilesc urmtoarele elemente: definirea scenariului de test: obiectul testului, punctele critice, rezultatele de obinut; valorile de test: datele de intrare n procedurile de actualizare, datele memorate nainte i dup execuia procedurilor, datele de ieire. Ian Sommerville prezint urmtorul model al unui proces pentru testarea sistemelor informatice:

Figura 5.1: Model de proces pentru testarea sistemelor informatice; adaptare Sommerville (2007, 539)

Conform acestui model, un scenariu de test2 specific datele de intrare, funcionalitile supuse testului i datele care trebuiesc obinute. Datele de test reprezint datele de intrare utilizate pentru execuia scenariilor de test. La final datele rezultate ca urmare a execuiei scenariilor de test se compar cu rezultele specificate de ctre scenariul de test. Dac rezultatele sunt identice se consider c testul a fost realizat cu succes. Un posibil eec al unui scenariu de test poate indica prezena uneia sau a mai multor erori n cadrul modulelor sistemului informatic, module utilizate pentru respectivul scenariu de test. Testarea riguroas a sistemului informatic nu se poate realiz fr definirea/proiectarea n prealabil a scenariilor de test. Literatura de specialitate (Sommerville 2007) a identificat trei abordri utilizate pentru definirea scenariilor de test: abordarea orientat ctre cerine abordarea orientat ctre partiionare abordarea structural Abordarea orientat ctre cerine presupune utilizarea cerinelor sistemului informatic pentru definirea scenariilor de test i are dou scopuri principale: validarea cerinelor (din punct de vedere al corectitudinii, completitudinii i omogenitii acestora) plus definirea unui set complet de scenarii de test care acoper toate cerinele(Bender 2009). Abordarea orientat ctre partiionare presupune definirea scenariilor de test n funcie de datele de intrare. Datele de intrare sunt divizate n submulimi disjunctive, operaie care se numete partiionare, scopul fiind acela de a construi scenarii de test care s utilizeze date de intrare reprezentative pentru fiecare submulime (Weyuker and Jeng, 1991). Abordarea structural permite definirea scenariilor de test avnd n vedere aspectele privitoare la structura codului surs. n funcie de modul n care se execut scenariile de test putem identifica dou tipuri de testare: testare manual i testare automat. n ambele cazuri, execuia scenariilor pentru testarea sistemului informatic de gestiune implic utilizarea unei(unor) baze de date de test. Testarea manual presupune implicarea unor persoane specializate3 care pentru fiecare scenariu de test pe care l parcurge joac rolul utilizatorilor finali. n anumite situaii, rolul acesta poate fi preluat chiar de ctre utilizatorii finali. Testarea automat presupune utilizarea, n mod uzual, a unor sisteme informatice specializat pentru execuia scenariilor de test. Dac pentru testarea manual este suficient realizarea unei documentaii care prezint procedura de testare pentru fiecare scenariu de test, n cazul testrii automate scenariile de test sunt definite la rndul lor sub forma unor proceduri sau funcii fapt care implic efort de programare.

2 En. test case 3 Numit i tester

Figura 5.6: Testare automat pe uniti realizat folosind cadrul de lucru NUnit

Dup ce sistemul a fost construit, testat i corectat (pus la punct), se genereaz formatul executabil final, ce se livreaz alturi de documentaia de utilizare a sistemului. Dincolo de toate aspectele privitoare la testarea sistemelor informatice este important urmtorul fapt: testarea sistemului are drept scop identificarea erorilor dar nu poate garanta lipsa total a acestora.

1.1 Studiul de caz

1.1.1 Structurarea aplicaiei
Dezvoltarea aplicaiilor interactive graviteaz, n MS Access, n jurul formularelor. Din aceast perspectiv, pentru primul tip de post de lucru sunt necesare trei formulare de prelucrare i un formular de dirijare (Tabelul 53). Pe acest nivel, formularul de prelucrare este punctul de intrare n procedura logic aferent. n funcie de coninutul i particularitile acesteia, formularul poate avea o structur mai simpl sau mai complex i poate antrena activarea altor formularea, emiterea de rapoarte .a.m.d.

Lucrri Emitere comenzi Emitere nrcd Acceptare facturi Dirijare prelucrri ...

Formulare frmComenzi frmNrcd frmAcceptare frmAproviz1 ...

Tabelul 53 Formularele Access n jurul crora se structureaz aplicaia

1.1.2Emiterea nrcd
n corelaie cu precizrile din proiectarea logic a prelucrrilor, a fost reinut aici procedura logic pentru emiterea notelor de recepie i constatare de diferene. Formularul de prelucrare prin care se intr n aceast procedur este cel corespunztor primei ULP/PL, respectiv generarea nrcd. Din interiorul acestuia, va fi activat formularul prin care este implementat a doua ULP/PL care va comanda, la rndul su, imprimarea nrcd ; documentul imprimat este, din perspectiva tipurilor de obiecte Access, un raport (Figura 5.6).

Figura 5.6 Suita de formulare i raportul prin care se implementeaz procedura logic aferent lucrrii Emitere NRCD

1.1.2.1ULP/PL pentru generarea nrcd

Implementarea ULP/PL se poate face parcurgnd, n termeni generali, paii urmtori: se definete structura sursei de date i se creaz formularul, conform schiei din proiectarea logic a prelucrrilor se introduc facilitilor de culegere a datelor i de asistare a utilizatorului

se implementeaz restriciile de integritate nedefinite la nivelul tabelelor se introduc comenzile pentru utilizator se testeaz formularul i se efectueaz coreciile necesare.

Sursa de date
Subschema de date aferent acestei ULP/PL (similar celei definite la modelarea logic a prelucrrilor) este prezentat n figura 5.7. ntre cele dou tabele care asigur memorarea nrcd NRCD i BUNURI_RECEPIONATE- exist o relaie de 1 n, expresie a faptului c un nrcd conine unul sau mai multe bunuri. n toate situaiile n care apare o asemenea relaie, este recomandabil utilizarea unei structuri formular-subformular. n raport cu linia trasat n schem, parte din stnga formeaz astfel sursa de date (record source) a formularului (principal) iar partea din dreapta, sursa de date a subformularului.

Crearea formularului
n modul cel mai simplu de lucru, se creaz cte o interogare (query) care reunete tabelele respective i, pe baza fiecreia, se genereaz cte un formular cu structura i forma adecvate (figura 5.8). Cel de al doilea formular se plaseaz n spaiul celui dinti n postura de subformular i se stabilete legtura dintre coninutul afiat de ele prin perechea de proprieti Link Master Fields, Link Child Fields.

Figura 5.7 Subschemele datelor i paii n crearea formularelor aferente ULP/PL pentru generare nrcd : notaiile A i C indic tabelele actualizate prin adugare de nregistrri, respectiv consultate.

Faciliti la introducerea datelor i asistarea utilizatorului

Formularul cuprinde trei zone de control de tip Combo Box (list de valori modificabil): codul fiscal al emitentului, pentru selectarea furnizorilor, numrul gestiunii, pentru precizarea gestiunii primitoare i codul bunului, pentru selectarea bunului recepionat. Pentru toate aceste zone de control, sursa de valori afiate (Row Source) este tabelul corespunztor (FURNIZORI, GESTIUNI, BUNURI); este activat cutarea parial (Auto Expand) i nu se admit alte valori dect cele existente n tabelele respective (Limit To List). Figura 5.9 prezint, pentru ilustrare, lista de proprieti a zonei Cod fiscal emitent.

Figura 5.8 Distribuirea datelor ntre formularul principal frmNrcd i subformularul BUNURI_RECEPIONATE. Legtura secionat prin linia punctat este preluat de perechea de proprieti Link Master Fields, Link Child Fields.

n momentul specificrii valorii pentru fiecare dintre aceste zone de control, sistemul afieaz automat, prin structura interogrii surs de date, datele aferente furnizorului (denumire i adres), datele aferente gestiunii (denumire i amplasare) i, respectiv, datele aferente bunului (denumire i caracteristici). Suplimentar, interogarea surs reine unitatea de msur memorat n tabelul BUNURI, pe care nu-l afieaz dar l folosete pentru a verifica unitatea de msur tastat.

Figura 5.9 Grupul de proprieti Data a zonei de control Cod fiscal emitent: ilustreaz utilizarea proprietilor Row Source, Limit To List i Auto Expand.

Figura 5.10 Grupul de proprieti Data a zonei de control ValoareIntrat: ilustreaz modul de calcul al valorii i utilizarea proprietilor Enabled i Locked pentru inhibarea accesului utilizatorului la acesta.

Accesul n zonele de control care afieaz datele extrase din tabele denumirea i adresa furnizorului, denumirea i amplasarea gestiunii primitoare, denumirea i caracteristicile bunurilor, la numrul nrcd
(atribuit automat) i la valoarea intrat (calculat) este prohibit prin setarea adecvat a proprietilor Enabled i Locked (a se vedea, pentru ilustrare, figura 5.10). Selectarea documentului nsoitor este asistat de dou butoane de opiuni. Prin activarea acestora, se deblocheaz zonele de control n care se tasteaz numrul facturii furnizorului, numrul avizului de expediie sau ambele. S-a recurs la aceast soluie, n primul rnd, n sprijinul imprimrii nrcd. Inhibarea afirii barelor de deplasare i a selectorilor de nregistrri este util pentru a conferi mai mult naturalee i pentru evita anumite manevre ale utilizatorului, care ar putea periclita corectitudinea derulrii prelucrrilor. n acest scop, se seteaz adecvat proprietile aferente la nivelul formularului, respectiv Navigation Buttons i Record Selectors. Proprietatea Status Bar Text permite ataarea la fiecare zon de control a unui text de ghidare, text ce se afieaz automat n bara de stare n momentul n care devine activ. Este

posibil de asemenea, ataarea unei descrieri concise a semnificaiei zonei, afiate atunci cnd cursorul rmne cteva secunde deasupra zonei de control respective, prin proprietatea ControlTip Text.

Comenzile pentru utilizator

Forma n care s-au implementat comenzile memoreaz nrcd, continu, nchide, anuleaz, imprim nrcd este cea a butoanelor de comand. Comenzile sunt determinate s devin activabile sau inerte prin setarea adecvat a proprietii Enabled. Spre exemplu, la iniierea unui nrcd, toate comenzile, cu excepia celei care permite nchiderea ULP/PL, sunt inactive (conform tabelului din proiectarea logic a acestei ULP/PL). Macrocomanda care le dezactiveaz, prin setarea proprietii menionate la valoarea False, este prezentat mai jos. Execuia acestei macrocomenzi este declanat prin proprietatea eveniment OnCurrent a formularului frmNrcd.

Figura 5.11 Blocarea butoanelor de comand printr-o macrocomand: ilustreaz utilizarea evenimentului On Current a formularului pentru a reaciona la deplasarea de la o nregistrare la alta.

Comanda Anuleaz devine activabil dup prima tastare sau selecie n list n oricare dintre zonele de control accesibile utilizatorului n formularul NRCD. Producerea acestui fapt este sesizat de proprietatea eveniment On Dirty. Pentru a evita multiplicarea macrocomenzii n toate zonele de control vizate, aceasta n-a mai rmas anonim, ci a primit numele deblAnulare. n felul acesta, poate fi apelat din toate punctele n care este necesar.

Figura 5.12 Macrocomanda comun deblAnulare, invocat n proprietatea On Dirty a mai multor zone de control ( data nrcd, cod fiscal emitent, nr gestiune, factura, aviz nsoire): ilustreaz utilizarea macrocomenzilor identificabile prin nume.

n mod similar, comanda Memoreaz este activat printr-o macrocomand ataat proprietii eveniment After Update a formularului BUNURI_RECEPTIONATE. Evenimentul aferent este declanat dup fiecare nregistrare pe disc a unei nregistrri (dup ce s-a introdus, deci, cel puin un bun intrat). Efectul comenzilor se obine prin execuia macrocomenzilor ataate proprietii eveniment On Click. n figura urmtoare este prezentat, pentru ilustrare, coninutul macrocomenzii ataate butonului de comand Continu: prin aciunea GoToRecord, aceasta realizeaz deplasarea la o nregistrare nou (adugat) n sursa de date a formularului NRCD i poziioneaz apoi, prin aciunea GoToControl, cursorul la Data nrcd. Deplasarea la o nou nregistrare prin GoToRecord determin ns producerea evenimentului Current n formularul NRCD, ceea ce declaneaz macrocomanda ataat proprietii acestuia (Figura 5.11 Blocarea butoanelor de comand printr-o macrocomand: ilustreaz utilizarea evenimentului On Current a formularului pentru a reaciona la deplasarea de la o nregistrare la alta.). Execuia acestei macrocomenzi are loc, aadar, dup aciunea GoToRecord dar naintea aciunii GoToControl. Activarea unei alte ULP/PL, aa cum este cazul pentru imprimarea nrcd, pentru adugarea unui furnizor sau a unui produs nou, se realizeaz deschiznd, printr-o macrocomand adecvat, formularului corespunztor. Formularul curent, din care s-a cerut prelucrarea, rmne deschis iar la ncheiere, se revine automat n spaiul i sub controlul su. Pentru imprimarea nrcd, s-a prevzut un buton de comand, conform structurii definite n cursul modelrii logice, la a crei proprietate eveniment On Click s-a ataat o macrocomand ce efectueaz deschiderea formularului frmImprNrcd (vezi i figura 5.15) prin aciunea OpenForm. Pentru comenzile furnizor nou i articol nou n-au fost inserate butoane de comand distincte, activarea lor fcndu-se prin dublu click pe zonele Combo Box ce le sunt afectate. Singura diferen fa de cele prezentate anterior este aceea c macrocomenzile sunt ataate acum proprietii On Dbl Click a zonelor respective.

Figura 5.13 Macrocomanda ataat proprietii eveniment On Click a butonului de comand Continu: ilustreaz modul de declanare a prelucrrilor specifice unei comenzi pentru utilizator

1.1.1.1ULP/PL pentru imprimarea nrcd

Rolul acestei ULP/PL este acela de a prelua datele care trebuie s figureze n documentul imprimat (impuse prin reglementrile n vigoare privitoare la nrcd) dar nu sunt memorate n tabelele NRCD i BUNURI_RECEPTIONATE i s declaneze generarea raportului prin care se obine forma imprimabil a documentului.

Sursa de date

O parte dintre datele suplimentare necesare membrii comisiei de recepie i gestionarul primitor provin din tabelul ANGAJAI. Deoarece comisia de recepie poate varia din punct de vedere al componenei i numrului de persoane, s-a optat pentru o soluie foarte simpl: utilizarea unui tabel temporar (care nu mai este amplasat pe server-ul de date) care s conin numele i prenumele respective (Figura 5.14). Toate celelalte date documente nsoitoare, mijloc de transport, delegat etc. - sunt pur i simplu introduse i folosite pentru generarea documentului, fr a mai fi memorate pe disc. nregistrrile din tabelul temporar MembriComisie sunt terse la acionarea comenzii de imprimare din formularul frmNrcd (Figura 5.15).

Figura 5.14 Structura tabelului temporar MembriComisie

Figura 5.15 Macrocomanda declanat la acionarea butonului btnImprima din frmNRCD: ilustreaz execuia unei interogri SQL, al crui text face parte din macrocomand.

Crearea formularului
Structura formularului, n formatul Design, este prezentat n figura 5.16. Controlul NrNRCDImpr preia numrul documentului din frmNRCD, prin macrocomanda ataat proprietii On Current a formularului (Figura 5.17). Componena comisiei de recepie este introdus ntr-o structur de tip subformular, creat pe baza tabelului MembriComisie.

Figura 5.16 Structura formularului frmImprNRCD n formatul Design

Faciliti la introducerea datelor

Facilitile de introducere a datelor vizeaz gestionarul i membrii comisiei de recepie, preluai, prin selecie, din tabelul ANGAJAI. n cazul gestionarului, s-a folosit o zon de control de tip Combo Box, care are drept surs de valori (Row Source) rezultatul unei interogri (query) care asociaz, ntr-un cmp unic, numele i prenumele angajailor i le afieaz n ordine alfabetic (Figura 5.18).

Figura 5.17 Macrocomanda prin care se preia numrul nrcd din formularul frmNRCD

Figura 5.18 Proprietile zonei Combo Box Gestionar: ilustreaz utilizarea interogrilor SQL pentru generarea unei surse de valori (Row Source) diferite de coninutul tabelului sau tabelelor din care se extrag datele.

Soluia aplicat pentru formularul ComisieRecepie (utilizat ca subformular n frmImprNRCD) este puin diferit (Figura 5.19). Zona NumeMComisie, de tip Combo Box, are o surs de valori (Row Source) cu dou coloane, fapt specificat prin proprietatea Column Count. Sursa datelor afiate este, ca i n cazul anterior, o interogare SQL. Coninutul primei coloane este atribuit zonei respective (NumeMComisie) prin proprietatea Bound Column. Coninutul celei de a doua coloane este plasat automat n zona Prenume de tip Text Box, printr-o macrocomand activat la producerea evenimentului After Update (produs dup reinerea valorii selectate din list). Specificarea unei coloane din sursa de valori a Combo Box se face prin proprietatea Column(i), unde indicele i precizeaz poziia coloanei dorite. Cum indicele primei coloane este zero, referirea la coloana a doua, n care se afl prenumele, se face prin expresia NumeMComisie.Column(1). Datele introduse n acest mod n cele dou zone sunt implicit stocate n tabelul temporar MembriComisie (care este sursa de date - Record Source a formularului), pentru a fi disponibile la imprimarea nrcd.

Figura 5.19 Structura formularului ComisieReceptie: ilustreaz folosirea proprietilor Column Count i Bound Column a zonelor de tip Combo Box i a proprietii Column(i) n cadrul unei macrocomenzi.

Comenzile pentru utilizator

Butoanele de comand oferite utilizatorului sunt vizibile n figura 5.16 i corespund specificaiilor din modelarea logic a prelucrrilor. Din tablelul elaborat la modelarea conceptual a prelucrrilor rezult c la deschiderea formularului, toate comenzile sunt inactive. Deblocarea butonului de anulare se realizeaz n maniera prezentat la ULP/PL anterioar. Butoanele de comand pentru vizualizare i imprimare se deblocheaz dup completarea datelor minimale obligatorii din nrcd. n acest scop, s-a folosit o macrocomand comun, numit VerifComplDate, care este apelat din proprietatea After Update ale fiecruia dintre zonele Gestionar, MijlTransport i Delegat i din proprietatea On Exit a subformularului MembriComisie. Figura 5.20 prezint aceast macrocomand, n care se remarc expresia condiional prin care se verific dac zonele menionate au fost completate i dac exist cel puin doi membri pentru comisia de recepie.

Documentul imprimat
Figura 5.21 prezint un nrcd, n forma n care este vizualizat i imprimat. Structura i coninutul respect modelul de document tipizat, cod 14-3-1A. Obinerea acestui document s-a realizat cu generatorul de rapoarte din MS Access. Structura raportului, n format Design, este prezentat n figura 5.22.

Figura 5.20 Macrocomanda VerifComplDate care deblocheaz butoanele de comand btnVizualizare i btnImprimare: ilustreaz execuia condiionat a aciunilor din macrocomand.

Figura 5.21 Modelul nrcd la imprimare

Sursa de date (Record Source) a raportului este o interogare n care se face compunerea tabelelor NRCD, FURNIZORI i GESTIUNI pentru nrcd cu numrul menionat n frmImprNRCD (preluat la rndul su din frmNRCD, unde s-a generat documentul). Textul acestei interogri este urmtorul:
SELECT NRCD.[Nr nrcd], NRCD.[Data nrcd], FURNIZORI.[Denumire fz], FURNIZORI.[Adresa fz], GESTIUNI.[Denumire gestiune] FROM GESTIUNI INNER JOIN (FURNIZORI INNER JOIN NRCD ON FURNIZORI.[Cod fiscal] = NRCD.[Cod fiscal furnizor]) ON GESTIUNI.[Nr gestiune] = NRCD.[Nr gestiune primitoare] WHERE NRCD.[Nr nrcd]=forms![frmImprNRCD]![NrNRCDImpr];

Datele din zonele Text Box afiate n partea superioar a raportului nr nrcd, data, gestiunea mpreun cu denumirea i adresa furnizorului, provin din aceast interogare. Factura i avizul de nsoire sunt preluate direct din frmNRCD, care a rmas, ca i frmImprNRCD, deschis.

Figura 5.22 Structura raportului rptNRCD n formatul Design

Textul Subsemnaii, membrii comisiei de recepie ... este generat prin expresia Control Source a zonei respective, fiind obinut prin inserarea, ntre poriunile de text fix, a datelor specifice preluate din formularul frmImprNRCD i din interogarea menionat mai sus (Figura 5.23). Raportul conine dou subrapoarte: pentru afiarea bunurilor recepionate i pentru afiarea membrilor comisiei de recepie. Figura 5.24 prezint structura primului subraport. Sursa de date este o interogare care compune coninutul tabelelor BUNURI_RECEPTIONATE i BUNURI. Tot n aceast interogare se calculeaz i valoarea, aa cum se poate observa n textul su, prezentat mai jos:
SELECT BUNURI_RECEPTIONATE.[Cod bun], BUNURI.[Denumire bun], BUNURI_RECEPTIONATE.[UM cf doc], BUNURI_RECEPTIONATE.[Cantitate cf doc], BUNURI_RECEPTIONATE.[Cantitate intrata], BUNURI_RECEPTIONATE.[Pret achizitie], [Cantitate intrata]*[Pret achizitie] AS Valoare, BUNURI_RECEPTIONATE.[Nr nrcd] FROM BUNURI INNER JOIN BUNURI_RECEPTIONATE ON BUNURI.[Cod bun] = BUNURI_RECEPTIONATE.[Cod bun] WHERE (((BUNURI_RECEPTIONATE.[Nr nrcd])=[forms]![frmImprNRCD]![NrNRCDImpr]));

Figura 5.23 Proprietatea Control Source a zonei care afieaz textul aflat deasupra tabelului cu bunurile recepionate: ilustreaz modalitatea de compunere a unui text unitar, folosind date preluate din mai multe surse.

Figura 5.24 Structura (sub)raportului BUNURI_RECEPTIONATE n format Design.

Denumirile coloanelor, n formatul grafic n care se dorete afiarea lor, sunt plasate n antetul raportului (Report Header). Dac ar fi fost plasate n antetul de pagin, care este poziia lor uzual, n-ar fi fost vizibile atunci cnd documentul servete ca subraport. Numrul curent este generat n zona Text Box aferent plasnd, n proprietatea Control Source, expresia =1 i setnd proprietatea Running Sum la valoarea Over All (Figura 5.25). Totalul valoric al intrrilor este calculat n seciunea Report Footer prin expresia Sum([Cantitate
intrata]*[Pret achizitie]).

Figura 5.25 Proprietile zonei NrCrt: ilustreaz modalitatea de generare a numerotrii liniilor ntr-un raport.

Subraportul prin care se afieaz membrii comisiei de recepie are o structur extrem de simpl, singura prelucrare pe care o efectueaz fiind aceea de a combina numele i prenumele ntr-un cmp unic, cu eliminarea spaiilor excedentare.

1.2 Rezumat
Unitatea de nvarea 5 prezint aspectele generale privitoare la implementarea sistemului informatic de gestiune folosind Access 2007. Aspectul fundamental este acela al separrii datelor de aplicaie Se ajunge astfel la o baz de date i o baz aplicativ. n mod uzual, BD conine tabele iar baza aplicativ este constituit din formulare, interogri (QBE i SQL), rapoarte, macrocomenzi i module VBA. Ca regul general, aplicaia se construiete n jurul formularelor. Acestea extrag i actualizeaz datele direct din table sau prin intermediul interogrilor. Tot formularele sunt cele care reacioneaz la evenimentele survenite n cursul lucrului, prin declanarea execuiei macro-urilor i a unitilor de program (subrutine i funcii) stocate n module. Crearea BD presupune crearea tabelelor i a legturilor dintre tabele. Crearea unei tabele Access presupune definirea cmpurilor (proprietile Field Name, Data Type, Required, Default Value, Description, Field Size, Format, Imput Mask, Validation Rule i Validation Text). O atenie deosebit trebuie acordat definirii restriciilor de integritate astfel: chei primare, indeci, chei interne i integritatea referenial, reguli de validare la nivel de cmp sau tabel, restricii SQL (CHECK), macrocomenzi sau subrutine VBA asociate evenimentului Before Update. Baza aplicaiei, partea aplicativ a sistemului, cuprinde ansamblul prelucrrilor pe care utilizatorii le realizeaz prin intermediul su. Din punctul de vedere al tipurilor de obiecte oferite de cre Access, partea aplicativ nseamn formulare (de prezentare, pentru interaciunea cu utilizatorii i intervenia activ asupra BD), interogri, rapoarte (pentru aciuni pasive de afiare a datelor), macrocomenzi i structuri de program scrise n limbajul VBA. Testarea sistemului se poate realiza pe urmtoarele nivele: unitar, de integrare i de sistem. Testarea unitar verific funcionarea separat a fiecrei uniti logice de program. Testarea de integrare vizeaz funcionarea unitilor de program n interaciune, respectiv n cadrul fiecrei proceduri logice. Testarea de sistem se concentreaz asupra funcionrii ansamblului, n calitatea de software aplicativ coerent i unitar. Pentru testare este necesar un ansamblu de date ce permite realizarea diferitelor scenarii de test ale sistemului informatic dezvoltat. n corelaie cu aceste elemente, trebuiesc stabilite urmtoarele: definirea testului (obiectul testului, punctele critice, rezultatele de obinut) i valorile de test (datele de intrare n procedurile de actualizare, datele memorate nainte i dup execuia procedurilor, datele de ieire).

1.3 Probleme propuse

a. Cum poate fi implementat restricia de integritate (aferent RI 3) privitoare la corelaia dintre unitile de msur din tabelul BUNURI i cele nscrise, pe baza documentelor nsoitoare, n nrcd: amplasare, coninut macrocomand, eveniment declanator. b. Definii implementrile pentru butoanele de comand btnAnuleaz, btnMemoreaz i btnInchide, n toate formularele n care apar. c. Modificai expresia de generare a textului compus din forma imprimat a nrcd, astfel nct, n cazurile n care nu este specificat documentul nsoitor, poriunea fix de text aferent acestuia s nu mai apar. d. Documentul nrcd include, pe verso, o serie de detalii pentru situaiile n care se constat diferene la recepie. Consultai modelul de document tipizat i facei completrile necesare, att n frmIntrNrcd ct i n rptNRCD, pentru a obine la imprimant i partea verso a documentului. Actualizai corespunztor i modelul logic al prelucrrilor. e. Dezvoltai soluia de implementare pentru formularul de dirijare frmAproviz1.

f. Implementai procedura logic aferent lucrrii nregistrare intrare bunuri n conformitate cu soluia formulat pentru problema corespunztoare la modelarea logic a prelucrrilor. g. Implementai procedura logic aferent lucrrii acceptare factur, n conformitate cu soluia formulat pentru problema corespunztoare la modelarea logic a prelucrrilor. h. Implementai procedura logic aferent lucrrii plat facturi, n conformitate cu soluia formulat pentru problema corespunztoare la modelarea logic a prelucrrilor.

SISTEME INFORMATICE DE GESTIUNE

Unitatea de nvare 6

Introducerea n exploatare i

meninerea n funciune

4. Introducerea n exploatare i meninerea n funciune

Obiective
Obiectivul acesti uniti de nvare este acela de a prezenta procesele i activitile aferente introducerii n exploatare a sistemelor informatice de gestiune i interveniilor de ntreinere a acestora, operate n cursul exploatrii curente. Studiul unitii permite: cunoaterea etapelor i activitilor parcurse la introducerea n exploatare cunoaterea strategiilor de tranziie de la sistemul actual la noul sistem informatic de gestiune nelegerea tipologiei proceselor de meninere n funciune a sistemelor informatice de gestiune i a activitilor specfice acestora cunoaterea tehnicilor specifice meninerii n funciune

Cuprins
4.1. Introducerea n exploatare 4.2. Meninerea n funciune 4.2.1.1. Tipuri de meninere n funciune 4.2.1.2. Procesul de meninere n funciune 4.2.1.3. Tehnici specifice meninerii n funciune

1 2 3 4 5 6
6.1 Introducerea n exploatare
Introducerea n exploatare este procesul n cursul cruia se realizeaz instalarea noului sistem la organizaia utilizatoare i intrarea n funcionare curent. Efectuarea sa presupune: asigurarea echipamentelor informatice i a cilor de comunicaie necesare; instalarea pe echipamente a programelor aplicative dezvoltate i testate; crearea bazei/bazelor de date i ncrcarea lor cu datele din organizaie; instituirea structurilor i procedurilor organizaionale specifice funcionrii noului sistem. Unele dintre activitile implicate, cum sunt achiziia i amplasarea echipamentelor i a reelelor de comunicaie, instruirea utilizatorilor, elaborarea documentaiei de utilizare, se pot pregti sau realiza, parial sau total, simultan cu proiectarea, construirea i testarea sistemului.

Din punct de vedere al realizrii efective, introducerea n exploatare poate fi structurat n urmtoarele etape (Figura 6.1): planificarea procesului; asigurarea i pregtirea resurselor necesare; instruirea cu privire la funcionarea sistemului; realizarea tranziiei la noul sistem; evaluarea sistemului Planificarea introducerii n exploatare, ca efort de anticipare, ordonare i corelare a aciunilor, stadiilor, termenelor i resurselor, este indispensabil att datorit complexitii procesului i a consecinelor pe care le are asupra acceptrii i punerii n valoare a rezultatelor dezvoltrii sistemului ct i faptului c pot fi luate n considerare mai multe strategii de realizare efectiv. Resursele implicate n introducerea n exploatare sunt cele necesare utilizrii efective a sistemului, adic echipamentele informatice i de comunicaie, software-ul de baz i aplicativ, personalul de utilizare i de administrare, cadrul de funcionare amenajarea spaiilor, procedurile organizaionale etc. n privina echipamentelor i a software-ului, n funcie de contextul concret din organizaie, poate fi necesar achiziia de echipamente noi, extinderea, modernizarea sau reamplasarea celor existente. n mod asemntor, asigurarea personalului poate presupune noi angajri sau redistribuiri ale personalului existent. Stabilirea amplasrii fizice, efectuarea amenajrilor necesare i adoptarea msurilor organizatorice privitoare la procesele de business n contextul noului sistem, la posturile de lucru, sarcinile, lucrrile i responsabilitile acestora, sunt de asemenea indispensabile pentru asigurarea introducerii n funciune. Dei grupate ntr-o singur etap datorit finalitii aceea de a asigura i pregti resursele necesare activitile menionate pot fi decalate n timp, n paralel cu derularea activitilor de dezvoltare a sistemului, cu condiia, evident, de a fi finalizate n acest stadiu.

Figura 6.1 Etapele introducerii n exploatare a sistemului informatic

Instruirea vizeaz asimilarea cunotinelor i abilitilor necesare efecturii lucrrilor i proceselor de business n condiiile funcionrii noului sistem i are n vedere dou categorii de personal: utilizatorii i administratorii de sistem. Instruirea utilizatorilor este de mai multe tipuri, n funcie de caracteristicile sistemului i de nivelul de cunotine al acestora, i poate viza: utilizarea efectiv a sistemului; spre exemplu, cum se face emiterea comenzilor de aprovizionare, cum se introduc bunurile recepionate, cum se corecteaz o factur introdus greit .a.m.d.; conceptele de afaceri i organizaionale folosite sau introduse odat cu sistemul: spre exemplu, care sunt regulile de selecie a ofertelor furnizorilor, cum se trateaz intrrile de bunuri sosite fr documente etc; cunotine informatice generale: utilizarea calculatorului i a sistemului de operare, efectuarea anumitor operaiuni de uz comun, folosirea echipamentelor particulare etc. Utilizarea efectiv este prezentat n ghidul (sau manualul) de utilizare, care face parte din documentaia sistemului. Acesta poate avea mai multe forme: document structurat, imprimat pe hrtie sau pe un suport electronic, material de tip e-learning, asisten instantanee (help) inclus n software-ul aplicativ etc. Indiferent de forma folosit, este necesar organizarea uneia sau mai multor sesiuni de prezentare, nsoite de demonstraii, asigurate de membrii echipei de dezvoltare, care s ofere un prim contact cu viitorul sistem, ce pot fi urmate de aprofundri bazate pe studiul sau consultarea documeniei oferite.

Modul concret de instruire privitoare la utilizarea sistemului este puternic influenat de modelul folosit la dezvoltarea sistemului. n aceast privin, toate abordrile care presupun participarea sau implicarea nemijlocit a utilizatorilor nc din primele activiti ale procesului de dezvoltare asigur i cunotine privitoare la viitoarea funcionare a sistemului (fr ns ca aceasta s exclud necesitatea furnizrii unui manual complet de utilizare). Instruirea privitoare la conceptele de afaceri i organizaionale specifice noului sistem este asigurat de ctre specialitii organizaiei beneficiare i se efectueaz numai n msura n care pregtirea sau experiena personalului implicat o solicit sau atunci cnd se au n vedere schimbri semnificative, cum ar fi, spre exemplu, trecerea, odat cu introducerea sistemului, la evaluarea stocurilor de bunuri prin metoda FIFO. Instruirea utilizatorilor este completat de acordarea de asisten n cursul exploatrii efective. Asistarea poate mbrca, ca i instruirea, mai multe forme, de la dialogul direct cu unul dintre membrii echipei de dezvoltare sau cu un specialist din compartimentul de TI al organizaiei, pn la asistena prin centre de apel dedicate sau prin forum-uri on-line. Informaiile necesare administratorilor de sistem vizeaz: organizarea (structurarea) sistemului; instalarea sistemului; gestionarea grupurilor de utilizatori mecanismele i instrumentele de autentificare, prevenire a accesului neautorizat i confidenialitate a datelor; procedurile de conservare a sistemului i a datelor (copii de siguran, restaurri, reluri dup incidente etc); n mod uzual, aceste informaii sunt cuprinse n ghidul (sau manualul) de administrare, care face parte, la rndul su, din documentaia livrat odat cu software-ul aplicativ. Tranziia constituie procesul de trecere de nlocuire a sistemului informaional actual cu noul sistem. Utilizarea termenului de sistem informaional semnaleaz faptul c nu este vorba despre o simpl instalare a software-ului de aplicaie dezvoltat sau achiziionat, ci de ncadrarea tuturor elementelor implicate echipamente, personal, proceduri organizaionale (inclusiv informaionale) ntr-un nou ansamblu coerent i funcional, depind astfel conotaiile pur informatice. Amploarea, complexitatea i riscurile antrenate de o asemenea schimbare au fcut s se contureze mai multe strategii de tranziie, avnd fiecare propriile avantaje i limitri. Ca i n cazul modelelor de dezvoltare, trebuie cutat i aplicat strategia sau combinaia de strategii care corespunde sau se adaptateaz cel mai bine fiecrui caz concret n parte. Strategiile de tranziie la noul sistem folosite n practic sunt urmtoarele: nlocuirea direct nlocuirea cu funcionare paralel nlocuirea localizat nlocuirea progresiv nlocuirea direct const n abandonarea, la o anumit dat, a vechiului sistem i intrarea global n exploatare a celui nou. Un asemenea tip de tranziie antreneaz riscuri semnificative: orice eroare survenit n timpul funcionrii poate pune utilizatorii n imposibilitatea de a executa lucrrile i sarcinile curente, cu efecte, uneori destul de ample, asupra desfurrii activitilor de business la nivelul ntregii organizaii. Dac efectuarea coreciilor este dificil i de lung durat sau sistemul n asamblul su eueaz, este necesar revenirea (temporar) la sistemul anterior, ceea ce, de asemenea, antreneaz ntrzieri i eforturi suplimentare. n cazul n care este o reuit, nlocuirea direct i total reprezint cea mai puin costisitoare strategie de tranziie.

Sistem vechi

Sistem nou

Figura 6.2 Tranziia prin nlocuire direct

nlocuirea cu funcionare paralel const n meninerea n funciune, pentru o anumit perioad de timp, att a sistemului vechi ct i a celui nou. n aceast situaie, remedierea erorilor sau a deficienelor noului sistem nu mai afecteaz efectuarea lucrrilor curente din organizaie, deoarece acestea sunt, oricum, executate i de ctre sistemul vechi. Riscul i efectele negative sunt mult mai mici dar tranziia este mult mai costisitoare prin faptul c are loc o dubl funcionare. De asemenea, poate aprea un impact negativ la nivelul utilizatorilor, care trebuie s execute de cte dou ori fiecare lucrare, recurgnd la mijloace i metode diferite.

Sistem Sistem nou vechi

Figura 6.3 Tranziia prin funcionare paralel

nlocuirea localizat, denumit de asemenea pilot, const n efectuarea tranziiei la nivelul unui site limitat (o subunitate, o filial, un centru de producie etc) i nu al organizaiei n ansamblul su. n aceste condiii, eventualele erori i deficiene afecteaz numai site-ul respectiv. Dup eliminarea problemelor i constatarea bunei funcionri, se continu cu urmtoarele site-uri, succesiv sau n bloc, pn la cuprinderea ntregii organizaii. Experiena acumulat la nivelul site-ului pilot accelereaz i susine tranziia pentru cele care urmeaz i creaz un cadru foarte bun pentru instruirea tuturor utilizatorilor. Riscurile sunt, n acest variant, mai reduse, dar procesul rmne, n ansamblu, costisitor. De asemenea, aplicabilitatea acestei strategii este limitat la cazurile n care este posibil delimitarea de site-uri pretabile pentru tranziie distinct.

Sit Sistem vechi vechi Sistem Sistem nou nou Sistem e 2 1

Figura 6.4 Tranziia prin nlocuire localizat

nlocuirea progresiv const n introducerea treptat a noului sistem, funcionalitate cu funcionalitate, modul cu modul, cu nlocuirea corespunztoare a prilor aferente din sistemul vechi, care rmne ns n funciune, ntr-o proporie din ce n ce mai mic, pn la eliminarea sa total. Este, cu alte cuvinte, corespondentul modelului iterativ de dezvoltare la nivelul introducerii n exploatare. Riscurile sunt, i n acest caz, limitate i mai uor de controlat, dar acest tip de tranziie impune realizarea de programe suplimentare, care s asigure comunicarea i interaciunea ntre cele dou sisteme, ceea ce este de natur s creasc costurile. Ca i n demersul precedent, nlocuirea progresiv este aplicabil numai n anumite cazuri, care se preteaz la funcionarea mixt pe care o presupune. Din aceast perspectiv, adecvarea la dezvoltare iterativ nu este i o confirmare pentru tranziia progresiv.

Sistem vechi Sistem nou

Figura 6.5 Tranziia prin nlocuire progresiv

Conversia datelor Tranziia cuprinde i o alt dimensiune, specific mai ales sistemelor informatice de gestiune, privitoare la fondul de date memorate. nlocuirea vechiului sistem presupune nu numai schimbarea echipamentelor, programelor aplicative i a procedurilor i proceselor de afaceri, ci i asigurarea continuitii datelor sub aspectul prelurii lor n noul sistem i prelucrrii n continuare. Din aceast perspectiv, n multe cazuri este necesar un adevrat proces de conversie, care s asigure tranzitarea fondului de date memorate din sistemul precedent n noile structuri, noile cerine de calitate, noile condiii de coeren logic. n numeroase cazuri, la datele deja memorate n sistemul anterior, trebuie adugate date suplimentare, a cror corelare se poate dovedi mult mai delicat dect nsi efortul de culegere i preluare n sistem. Deoarece acest proces nu este ntotdeauna automatizabil (sau este parial automatizabil), realizarea sa poate solicita un efort important i exigent sub aspectul competenei, din partea personalului organizaiei. n oricare dintre variante, nlocuirea sistemului vechi presupune existena unui fond de date deja ncrcate n BD, fond care se poate limita la o parte dintre tabele i din nregistrri, dar a cror prezen condiioneaz demararea funcionrii noului sistem. Evaluarea se refer la sistemul introdus n exploatare i urmrete s stabileasc msura n care acesta rspunde complet i corect cerinelor funcionale i nefuncionale pe baza crora a fost realizat. Calitatea sistemului de a fi dezvoltat n conformitate cu cerinele este, n mod normal, avut n vedere i urmrit pe tot parcursul proiectrii, construirii i testrii i face, n mod expres, obiectul validrii. Evaluarea d o apreciere final, bazat pe constatrile rezultate din funcionarea ntregului sistem n condiiile reale din organizaie.

1.1 Meninerea n funciune

Meninerea n funciune desemneaz procesul de intervenie asupra software-ului aplicativ, efectuat dup introducerea sistemului n exploatare i care urmrete

eliminarea problemelor aprute n funcionarea sau adaptarea la solicitrile survenite ulterior dezvoltrii. Acoperind ntregul interval de timp n care sistemul este folosit de ctre organizaie, meninerea n funciune compune, mpreun cu exploatarea curent, etapa cea mai lung din ciclul su de via. Meninerea n funciune, denumit adesea i ntreinerea sistemului, tinde s capete o importan din ce n ce mai mare, odat cu acumularea de sisteme informatice n cadrul fiecrei organizaii. Mai multe studii efectuate evideniaz o cretere a ponderii costurilor de meninere n funciune, care au ajuns actualmente la 70-80% din bugetele alocate sistemelor informatice, fa de 40-60% ct reprezentau acestea n urm cu 20 de ani. De asemenea, accentul interveniilor efectuate se deplaseaz de la corectarea erorilor i eliminarea disfuncionalitilor, spre extinderea i adaptarea sistemului la noile cerine aprute ca urmare a schimbrilor survenite n mediul de afaceri, n abordrile i obiectivele de management i de nevoia de interaciune cu alte noi sisteme. Abilitatea sistemului de a facilita sau, dimpotriv, de a ngreuna ntreinerea este referit prin caracteristica de mentenabilitate. Dintre factorii care determin mentenabilitatea, se afl pe primele locuri numrul de defecte latente, numrul de utilizatori i calitatea documentaiei.

1.1.1Tipuri de meninere n funciune

ntreinerea sistemului este impus de mai multe cauze: eliminarea erorilor de funcionare constatate dup introducerea n exploatare; adaptarea programelor la echipamente, software sau faciliti noi ale TI; adugarea de noi funcionaliti sau modificarea unora dintre cele oferite, ca urmare a cererilor formulate de ctre utilizatori sau impuse de schimbri survenite n legislaie sau n mediul de afaceri ; extinderea comunicaiei cu alte sisteme; amelioarea proiectului sistemului etc. n aceste condiii, se pot distinge aciuni de corectare i aciuni de extindere a sistemului. Adugnd la acestea i sensul aciunii ntreprinse reactiv sau proactiv se ajunge la urmtoarele patru tipuri de meninere n funciune: corectiv adaptiv perfectiv preventiv ntreinerea corectiv are caracter reactiv i urmrete eliminarea deficienelor constatate dup intrarea sistemului n exploatare curent, determinate de erori de proiectare, de programare sau chiar de introducere n exploatare. Acest tip de intervenie are caracter de urgen i trebuie realizat astfel nct s afecteze ct mai puin desfurarea activitilor de business din organizaie. ntreinerea adaptiv are, de asemenea, caracter reactiv i urmrete adaptarea software-ului aplicativ la evoluia tehnologiilor informaionale folosite i la schimbrile survenite n cerinele de business sau n legislaie. ntreinerea perfectiv, cu caracter proactiv, urmrete mbuntirea performanelor sistemului, cum ar fi, spre exemplu, viteza de prelucrare, convivialitatea interfeelor cu utilizatorii, scalabilitatea, mentenabilitatea etc. ntreinerea preventiv, cu caracter proactiv, vizeaz diminuarea riscurilor de producere n viitor a unor deficiene n funcionare, prin identificarea i eliminarea lor n stare latent. Acest gen de intervenie se ntlnete mai ales n cazul sistemelor critice, care pot afecta integritatea fizic sau existena fiinelor umane.

1.1.1Procesul de meninere n funciune

Meninerea n funciune sau ntreinerea sistemului are ca efect modificarea programelor sau/i a structurilor de date memorate ca urmare a unor cereri de corecie sau de extindere formulate de ctre utilizatorii direci sau de ctre alte persoane implicate (angajai din departamentul de TI al organizaiei) sau interesate (manageri, acionari etc). Se parcurge aadar suita de activiti specifice dezvoltrii definirea cerinelor, proiectarea, contruirea, testarea. Spre deosebire de dezvoltarea iniial, procesul de meninere n funciune are o serie de particulariti: opereaz asupra unui sistem existent i aflat deja n exploatare curent pe care-l modific; testarea are menirea de-a verifica nu numai buna funcionare a coreciei sau extinderii operate ci i a integrrii acesteia n sistemul existent, din care cea mai mare parte rmne neschimbat; rezultatul obinut dup testare formeaz o nou versiune a sistemului, care trebuie s-o nlocuiasc pe cea aflat n exploatare, cu minime impedimente asupra desfurrii, n acest interval de timp, a activitilor de business curente;

Cereri de corectare/ modificare

Figura 6.6 Activitile procesului de meninere n funciune

membrii echipei de meninere n funciune pot fi total diferii de cei care au dezvoltat sistemul, n frecvente cazuri acetia din urm fiind indisponibili chiar pentru o simpl consultare; procesul se reia, n termenii menionai, pentru fiecare nou cerere de ntreinere, astfel nct pe durata de via a sistemului apar, de regul, mai multe cicluri de ntreinere, n contrast cu ciclul de dezvoltare, care este unic.

Schematic, un proces de meninere n funciune are configuraia prezentat n figura 6.6 (conform cu cea recomandat n standardul IEEE1219-98 Maintenance Process Activities). Avnd n vedere c fiecare ciclu de meninere n funciune este declanat de o cerere (sau un grup de cereri) de corecie sau evoluie, una dintre activitile specifice vizeaz controlul i acceptarea sau respingerea acestora. Acceptarea cu uurin a cererilor conduce la cicluri multiple i la costuri importante, dup cum respingerea nejustificat sau superficial poate pune sub semnul discuiei utilitatea sau funcionalitatea ntregului sistem. Aa cum s-a menionat anterior, o prim distincie apare ntre tratarea erorilor manifestate, care trebuie remediate ct mai rapid cu putin i solicitrile de adaptare sau extindere, pentru care se poate face o ealonare n timp. n consecin, cererile sunt evaluate, clasificate i ordonate n funcie de prioritatea pe care o prezint pentru organizaie. Cererile acceptate sunt analizate pentru a stabili modificrile pe care le presupun; aceste modificri sunt apoi proiectate, implementate n programele surs, testate i ncorporate ntro nou versiune a sistemului, care o va nlocui pe cea aflat n funciune. Dintre activitile suport, se difereniaz aici managementul configuraiei, avnd n vedere c fiecare ciclu de meninere n funciune d natere unei noi versiuni a sistemului i documentarea, vital pentru a furniza echipei de ntreinere informaiile privitoare la sistem i

la modificrile ce i-au fost aduse n cicluri precedente, la un nivel de detaliu i sistematizare, care s permit unor persoane care nu au participat la dezvoltarea iniial s identifice poriunile din programe i structurile de date care trebuie revizuite sau extinse. La nlocuirea versiunii anterioare cu cea rezultat din ciclul de meninere n funciune sunt necesare i unele dintre activitile specifice introducerii n exploatare tranziia i uneori instruirea, n special atunci cnd s-a vizat realizarea de extinderi.

1.1.1Tehnici specifice meninerii n funciune

Meninerea n funciune conduce, n ultim instan, la efectuarea de modificri n programe existente, n cele mai multe cazuri, redactate de ctre alte persoane. Deseori, pentru a se ajunge la aceste modificri, este necesar efectuarea de intervenii la nivelul proiectului conform cruia a fost realizat sistemul. Pentru a putea face modificri pertinente n programe, acestea trebuie asimilate (nelese), activitate ce ocup ntre 40% i 60% din efortul total de meninere n funciune. n consecin, se recurge la diverse tehnici i instrumente software specializate, care s faciliteze asimilarea i modificarea sistemelor informatice existente. n aceast categorie se includ: dezvoltarea asistat de calculator; retro-ingineria; reingineria software. Dezvoltarea asistat de calculator prin diferitele produse dedicate (CASE) permite mrirea nivelului de abstractizare, astfel nct, cel puin parial, interveniile s fie realizate numai la nivelul modelelor de proiectare, acestea fiind traduse automat n cod surs. De regul, instrumentele de acest tip recurg la un tip particular de catalog repository n care se stocheaz descrierea diverselor elemente ale sistemului, ntr-o form exploatabil de ctre instrumentul respectiv. Acesta permite manipularea, sub forma mult mai accesibil de scheme i diagrame, a elementelor sistemului i efectuarea de modificri la acelai nivel, care sunt apoi traduse automat (cu unele limitri) in programe surs. Att varianta iniial, ct i modificrile ulterioare, sunt memorate n condiii de coeren controlat automat n repository i pot fi regsite i folosite la ciclurile de ntreinere ulterioare. Retro-conceperea (reverse engineering) acioneaz n sens invers demersului de dezvoltare, urmrind s reconstituie, prin examinarea codului de program, o imagine mai abstract, mai accesibil uman, a sistemului, mergnd ct mai aproape de modelele de proiectare sau chiar de definire a cerinelor. Aceste efort este asistat de diverse produse (instrumente) software dedicate. Pentru situaiiile n care programele sunt disponibile doar n format executabil, se recurge la produse de tipul decompilatoarelor sau dezasambloarelor, care permit obinerea unui echivalent ntr-un limbaj surs. Pornind de la programele n limbaj surs, este posibil reprezentarea, sub form de diagrame generate automat, a prelucrrilor efectuate de ctre acestea, reconstituind astfel o parte din documentaia de proiectare. Retro-conceperea este frecvent aplicat i pentru reconstituirea MCD, prin analiza structurii fizice a tabelelor din bazele de date sau a fiierelor. Retro-conceperea are caracter pasiv, n sensul c nu intervine n coninutul programelor, ci se limiteaz la prezentarea acestora ntr-o form mai accesibil uman. Din acest motiv, se utilizeaz n situaiile n care nu exist documenie pentru sistem sau aceasta este incomplet: la meninerea n funciune a software-ului aplicativ, dezvoltat de alte echipe dect cea care efectueaz ntreinerea; la integrarea cu alte sisteme, a cror documentaie nu este disponibil; pentru migrarea sistemelor cheie vechi, dezvoltate cu tehnologii desuete i aflate n exploatare efectiv de mufli ani. Reconceperea (reengineering) const n analiza, prin instrumente software dedicate, a programelor surs i modificarea acestora astfel nct performanele sau funcionalittile sistemului s fie ameliorate. Aceste modificri pot fi fcute automat sau sub control uman.

Numeroase medii de dezvoltare comerciale includ funcionaliti de tipul retro-concepiei i reconcepiei software.

Rezumat
Introducerea n exploatare reunete activitile necesare instalrii i intrrii n funcionare curent a sistemului informatic n organizaia beneficiar. Principalele activiti necesare introducerii n exploatare includ: asigurarea resurselor materiale, umane i organizaionale necesare, instruirea personalului, tranziia la noul sistem i evaluarea sistemului. Datorit complexitii i riscurilor pe care le implic, introducerea n exploatare trebuie riguros planificat, chiar dac unele dintre activitile sale se execut n cursul dezvoltrii sistemului. Tranziia vizeaz nlocuirea sistemului actual cu cel nou i asigurarea conversiei datelor. Exist mai multe strategii de nlocuire, care pot fi aplicate distinct sau n combinaie, n funcie de specificul sistemului i de condiiile concrete din organizaie. Meninerea n funciune acoper, n timp, ntreaga perioad de exploatare curent a sistemului informatic de gestiune i const n efectuarea de intervenii asupra software-ului de aplicaie pentru corectarea sau eliminarea erorilor i pentru a face sistemul s se adapteze la cerinele suplimentare aprute pe parcurs i la evoluia tehnologiilor informaionale, prelungindu-i astfel durata de via. n funcie de finalitate i de sensul de aciune, se disting patru tipuri de meninere n funciune: corectiv, adaptiv, perfectiv i preventiv. Procesul de meninere n funciune este declanat de apariia de cereri de corectare sau modificare i conine urmtoarele activiti de baz: evaluarea i selectarea cererilor, analiza cererilor acceptate, proiectarea modificrilor corespunztoare cererilor, implementarea modificrilor n programe i testarea. Meninerea n funciune recurge la o serie de tehnici specifice, care se adaug celor folosite n procesul de dezvoltare iniial a sistemului. Aceste tehnici sunt impuse de nevoia de a facilita asimilarea sistemului i programelor ce-l compun, deoarece persoanele care efectueaz meninerea n funciune sunt adeseori diferite de cele care au conceput i realizat sistemul, documentaia sistemului poate fi incomplet sau absent, sistemele ntreinute pot fi relativ vechi, recurgnd la tehnologii desuete.

SISTEME INFORMATICE DE GESTIUNE

Unitatea de nvare 7

Elemente de administrare a realizrii i exploatrii sistemelor informatice de gestiune

1 2 3 4 5 6 7 c
7.1 Administrarea realizrii sistemelor informatice de gestiune

Gestionarea realizrii sistemelor informatice de gestiune vizeaz aspectele legate de managementul procesului respectiv, din perspectiva fiecruia dintre cei doi participani client (sau beneficiar) i furnizor - i a modalitii de obinere, respectiv furnizare - prin cumprarea sau utilizarea (spre exemplu, prin abonare) unui sistem deja existent ori prin dezvoltarea unui sistem nou, unicat (pe msur). Pentru fiecare dintre cele dou cazuri generice menionate, beneficiarul i furnizorul (sau dezvoltatorul) au probleme de gestionare diferite. Caracterul de unicat i nivelul de creativitate pe care-l impune realizarea sau schimbarea sistemelor informatice face ca gestionarea acestora s recurg la principii, metode i tehnici de management de proiect. Managementul este indispensabil pentru a organiza i coordona eforturile organizaiilor sau echipelor implicate i pentru a asigura ncadrarea n bugetul alocat i termenele stabilite. Ignorarea sau diminuarea rolului su este considerat a fi una dintre cauzele majore de eec; pe de alt parte, ns, un bun management nu este suficient pentru a asigura succesul proiectului. Managementul de proiect include urmtoarea arie problematic: gestiunea domeniului proiectului gestiunea integrrii proiectului gestiunea timpului alocat proiectului gestiunea costurilor alocate proiectului gestiunea calitii proiectului gestiunea resurselor umane alocate proiectului gestiunea comunicrii informaiilor privitoare la proiect gestiunea riscului proiectului gestiunea achiziiilor necesare realizrii proiectului Toate acestea se regsesc i n realizarea sistemelor informatice de gestiune, cu aplicabilitate i ponderi diferite, pentru fiecare dintre tipurile de participani implicai n cele dou circumstane menionate: dezvoltare sau cumprare/utilizare. Dincolo de diversitatea inerent, activitile derulate se pot grupa conform urmtoarei structuri: activiti de iniiere a proiectului; activiti de planificare a proiectului; activiti de monitorizare i control al proiectului. Amploarea i coninutul concret al fiecruia dintre aceste trei grupuri de activiti variaz semnificativ de la un caz la cellalt, dar ele sunt prezente i trebuie contientizate i executate cu rigoare i realism de fiecare dintre participani, pentru a avea anse de succes ct mai bune i a reduce la minimum riscurile (Figura 7.1).

1.1 Managementul dezvoltrii sistemelor informatice

Managementul proiectelor de dezvoltare a sistemelor informatice cunoate, n raport cu alte domenii de activitate, o serie de particulariti, care genereaz dificulti specifice. O prim dificultate vine din faptul c o estimare acceptabil a efortului i, n consecin, a resurselor i duratei de timp necesare presupun o bun cunoatere a ceea ce urmeaz a fi realizat. Aceasta vizeaz, la nivel minimal, cerinele, funcionale i nefuncionale pe care trebuie s le satisfac sistemul. Dar colectarea, analiza i modelarea cerinelor este una dintre activitile de baz ale procesului de dezvoltare: cu alte cuvinte, ele constituie o premis indispensabil pentru a putea face anticipri i estimri i, n aceali timp, fac obiectul planificrii i urmririi, alturi de toate celelalte. La aceast dificultate, s-au formulat dou tipuri generale de rspuns: a. s se introduc o suit de activiti de pre-dezvoltare, care s dea o definire a necesitilor la care ar trebui s rspund sistemul, s investigheze alternativele de abordare i s elaboreze un studiu de fezabilitate; rezultatele acestor activiti preliminare formeaz baza iniierii proiectului; b. iniierea proiectului s se fac dup un studiu complet al cerinelor, ceea ce face ca activitile legate de acestea s fie tratate n afara efortului de management al dezvoltrii.

Modificarea cerinelor, fapt curent n realizarea sistemelor informatice de gestiune, uneori chiar n cursul dezvoltrii, constituie o dificultate suplimentar i din aceast perspectiv.

Figura 7.1 Gestionarea realizrii sistemelor informatice de gestiune implic n mod specific att dezvoltatorul (respectiv furnizorul) ct i beneficiarul

O alt dificultate major vizeaz estimarea preliminar a costurilor, necesar nu numai pentru bugetarea i urmrirea proiectului, ci i pentru fixarea preului cerut beneficiarului. Pe lng dificultile menionate anterior, se adaug aici att faptul c fiecare sistem este, n marea majoritate a cazurilor, diferit de ceea ce s-a dezvoltat anterior i implic multiple elemente de creativitate, extrem de dificil de anticipat i comensurat, ct i lipsa unor metode sau tehnici adecvate de evaluare. Din acest motiv, cele mai frecvente abordri sunt cele bazate pe analogii cu dezvoltrile precedente de sisteme similare i cele n care suma pe care beneficiarul este dispus s-o plteasc pentru sistem determin i mrimea acceptat a costului. Produsul creat n cursul procesului de dezvoltare este invizibil (intangibil) i nesuspus restricionrilor de natur fizic, spre deosebire de ceea ce se ntmpl la alte genuri de proiecte (construcii civile, echipamente etc). Aceasta confer un plus de dificultate urmririi progresului lucrrilor, care se bazeaz, pn n momentul testrii programelor, aproape numai pe documentaie. Din acelai motiv, eventualele erori risc s fie descoperite doar n faza final, cnd corectarea lor devine deosebit de dificil i costisitoare. Toate acestea au impus constituirea unei componente distincte de management al riscurilor, care s previn, s depisteze i s remedieze ct mai rapid eventualele situaii care ar putea compromite ncadrarea n parametrii fixai. Aceeai intangibilitate a produsului face ca, la un eventual eec, cheltuielile deja fcute s nu mai poat fi recuperate nici mcar parial, devenind pierdere pur. n aceste condiii, sunt necesare analize la intervale scurte de timp, care s permit identificarea ct mai rapid a unor asemenea situaii i s decid, dac este cazul, stoparea proiectului, nainte ca pierderile s devin prea mari. Dificultile enumerate i amploarea consecinelor nefavorabile pe care le pot avea n practic au amplificat importana managementului n dezvoltarea de sisteme informatice. Mai mult dect att, s-a ajuns chiar la formularea unor modele de procese de dezvoltare care integreaz, n activitile de baz, elemente de planificare, de prevenire i rezolvare a riscurilor, de dezvoltare i livrare treptat, pe componente, astfel nct ceea ce se realizeza s poat fi verificat i validat ct mai devreme de ctre utilizatori. Premisele favorabile aduse de aceste modele trebuie valorificate printr-un management adecvat, care se abate uneori de la regulile acceptate n cadru general. Inclusiv alegerea tipului de model de dezvoltare devine nu numai o problem de proiectare i construcie, ci i o problem de management.

Figura 7.2 Activitile de management i de dezvoltare a SIG

Managerul de proiect are sarcina de a constitui echipa care va realiza sistemul, de a stabili modul de alocare a resurselor disponibile, de a planifica, la nivelul adecvat de detaliu, activitile necesare realizrii sistemului i de a urmri realizarea lor, efectund pe parcurs corecii i ajustri, astfel nct s se ncadreze n limitele de timp i sumele fixate i s livreze sistemul cerut, la un nivel calitativ corespunztor. Aa cum rezult din aceast enumerare, activitile de management al proiectului demareaz naintea activitilor de dezvoltare i le nsoesc pe tot parcursul efecturii lor (Figura 7.2).

1.1.1Iniierea proiectului
Iniierea proiectului demareaz cu definirea ciclului de via al procesului de dezvoltare (CVP). Acesta este cel care identific etapele i fazele concrete de urmat, aria de cuprindere a fiecreia, ordinea de execuie i relaiile de condiionare reciproc. Stabilirea CVP este influenat de mai muli factori: particularitile cerinelor i restriciilor formulate de ctre beneficiar, politicile i standardele aplicate de dezvoltator i nu n ultimul rnd, experiena acumulat la dezvoltrile anterioare. n raport cu toate acestea, se alege modelul de ciclu de dezvoltare (CD) considerat a fi cel mai adecvat (cascad, incremental, n spiral etc). n conformitate cu maniera de abordare al CD ales, se definesc, ntr-o structur ierarhic, etapele, fazele i lucrrile necesare pentru realizarea sistemului i ordinea de efectuare a acestora, lund n considerare att logica demersului adoptat ct i eventualele prioriti i restricii fixate de beneficiar. Tabelul urmtor prezint o gril orientativ de alegere a tipului de model de ciclu de dezvoltare. n raport cu particularitile sistemelor informatice de gestiune, cele mai adecvate sunt modelele incremental i de dezvoltare rapid.

Model de dezvoltare Cascad

Recomandabil Proiecte ample, complexe, cu cerine stabile, formulate complet i fr ambiguiti la demararea sistemului, cu obiective i soluii clare;

Nerecomandabil Sisteme de mari dimensiuni, pentru care cerinele nu sunt familiare echipei de proiect sau care pot suporta modificri pe parcurs; sisteme pentru care exist cerine de instalare rapid. Sisteme simple sau de mici dimensiuni Sisteme n care gradul de risc nu este ridicat, sisteme cu potenial de reutilizabilitate Sisteme de mare amploare, sisteme cu cerine nefuncionale importante sau care recurg la tehnologii noi

Incremental Spiral

Dezvoltare rapid

Sisteme mari, cu cerine care se definesc sau se modific pe parcurs; sisteme bazate pe tehnologii Web; Sisteme critice pentru viaa uman, sisteme cu grad ridicat de risc, sisteme pentru care este avantajoas combinarea mai multor modele de proces Sisteme de dimensiuni mici i medii, interactive, n care este asigurat participarea constant a utilizatorilor, sisteme de analiz economic i raportare, sisteme inovatoare

Tabelul 71 Modelele ciclului de dezvoltare raportate la caracteristicile sistemelor informatice

n dezvoltarea sistemelor informatice, personalul constituie resursa critic. Activitatea desfurat de membrii echipei de dezvoltare are caracter pronunat intelectual i solicit mult creativitate i rigoare. Alturi de nivelul de pregtire i de calitile personale, toate acestea accentueaz i importana experienei practice acumulate, cu efect mai amplu dect n alte genuri de activitate uman. Constituirea echipei de proiect reprezint astfel una dintre sarcinile majore i delicate, avnd n vedere c presupune, aproape fr excepii, un compromis ntre nevoia de personal calificat i experimentat i disponibilitile existente.

1.1.2Planificarea proiectului
Ciclul de via al procesului de dezvoltare al sistemului este o pies fundamental, pe care se bazeaz att alocarea resurselor, ct i planificarea, monitorizarea i controlul proiectului. Pentru fiecare dintre activitile identificate n CVP, se stabilete rezultatul concret pe care trebuie s-l produc i se estimeaz efortul necesar realizrii, n termeni de durat, termene, personal i costuri. Rezultatele fixate depind de natura activitii, putnd avea forma unor documente intermediare (cum ar fi, spre exemplu, diverse modele) sau a unor elemente livrabile beneficiarului (prototip, subsistem executabil, documentaie etc). Aceste rezultate formeaz punctele de pornire pentru lucrrile urmtoare i servesc drept repere (milestones) n urmrirea progresului proiectului. Urmeaz ealonarea proiectului, prin care se stabilete ordinea n care se execut activitile, termenele la care trebuie ncheiate i alocarea pe membri ai echipei. n funcie de condiionrile reciproce, unele activiti sunt strict secveniale, n timp ce altele pot fi executate n paralel. Pentru activitile secveniale, durata total se obine prin nsumarea duratelor individuale ale acestora. Activitile posibil paralele se grupeaz n funcie de activitatea de a crei realizare depinde demararea lor iar durata fiecrui asemenea grup este dat de cea mai lung dintre activitile componente. La estimarea duratelor de realizare a fiecrei activiti este recomandabil prevederea unei marje de timp suplimentare care s acopere eventualele ntrzieri n executarea activitilor precedente sau indisponibilitatea temporar a resurselor umane i materiale necesare. Ealonarea preliminar astfel obinut poate suferi modificri pentru ncadrarea n resursele disponibile. Spre exemplu, un grup de activiti realizabile n paralel trebuie executat n secven dac n echipa de proiect nu exist suficient personal. Pe baza tuturor acestor elemente, se definitiveaz alocarea resurselor personal, echipamente, faciliti - pe etape, faze i lucrri.

Lucrare L1 L2 L3 L4 L5 L6 L7 L8 L9 L10

Durata n zile 3 5 8 2 4 8 6 3 4 5

Dependen L1 L1 L2 L2 L4,L6 L4 L9

Tabelul 72 Lucrri, durate i dependene

Pentru ilustrare, tabelul Tabelul 72 72 prezint un set ipotetic de lucrri, pentru care sunt precizate duratele estimate i lucrarea sau lucrrile a cror ncheiere condiioneaz demararea lor.

L1 L2 L3 L4 L5 L6 L7 L8 L9

L10 Tot al 3 3 4 5 4 4 3 3 4 4 4 3 1 1 1 1 1 1 1
Figura 7.3 Ealonarea iniial a lucrrilor

O prim soluie de ealonare a lor este prezentat n figura urmtoare, care are forma unui grafic Gantt. Lucrrile L1, L4 i L7 demareaz simultan, deoarece nu depind de nici o alt lucrare anterioar. Lucrrile L2 i L3 demareaz, ambele, dup ncheierea lucrrii L1 .a.m.d. Durata total a execuiei este de 18 zile i este determinat de suita L1, L2, L6 i L8. n raport cu acestea, celelalte lucrri pot ntrzia cu un anumit numr de zile (marcaj haurat) fr ca durata total s fie afectat. Spre exemplu, L10 poate demara ntre ziua a 7-a i ziua a 14-a; L9, care o condiioneaz pe L10, poate demara ntre ziua a 3-a i ziua a 9-a etc. 7 / 6 L1 L2 L3 L4 L5 L6 L7 L8 L9 L10 Tot al 3 3 2 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 2 8 / 6 9 / 6 1 0 / 6 1 1 / 6 1 4 / 6 1 5 / 6 1 6 / 6 1 7 / 6 1 8 / 6 2 1 / 6 2 2 / 6 2 3 / 6 2 4 / 6 2 5 / 6 2 8 / 6 2 9 / 6 3 0 / 6 1 / 7

Pe ultima linie este calculat numrul total de lucrri de executat n fiecare zi. Exploatnd marjele de timp disponibile pentru lucrri, se poate obine un grad mult mai uniform de ncrcare pe zile, aa cum se observ n figura 7.4. Fixnd data de ncepere, se obine imediat calendarul de execuie a lucrrilor respective. Alturi de planul proiectului, care acoper procesul de dezoltare, respectiv definirea cerinelor, proeictarea, construirea i testarea, se elaboreaz i alte tipuri de planuri: planul de asigurare a calitii proceselor i al software-ului produs planul de gestionare a configuraiei planul de validare a software-ului planul de instalare a sistemului planul de instruire a utilizatorilor

Figura 7.4 Calendarul de execuia a lucrrilor

1.1.1Monitorizarea i controlul proiectului

Monitorizarea i controlul au loc pe parcursul executrii proiectului i cuprind urmtoarele activiti cheie: managementul riscurilor; execuia i monitorizarea progresului proiectului n raport cu planul elaborat; identificarea eventualelor schimbri necesare n CVP i gestionarea acestora;

consemnarea proiectului.

comunicarea

informaiilor

privitoare

la

starea

Managementul riscurilor este procesul sistematic de identificare, analiz i de reacionare, prin eliminare sau diminuare, la elementele de risc aprute. Riscul definete, n acest context, orice element neprevzut care poate afecta, n sens negativ, dezvoltarea sistemului. Caracterul imprevizibil face ca riscurile s nu fie incluse n planul proiectului, dar prin consecinele pe care le pot avea, impun instituirea unui sistem de management dedicat. Orice resurs sau proces implicat n executarea proiectului este o potenial surs de risc: membrii echipei de dezvoltare pot fi, din diverse motive, indisponibili o anumit perioad de timp sau pot prsi echipa; echipamentele sau programele folosite pot s fie obinute cu ntrziere sau pot avea deficiene n funcionare; cerinele funcionale i nefuncionale pot fi incomplet definite sau se pot schimba pe parcurs; unele lucrri sau resurse pot fi subestimate sau omise la organizarea i planificarea proiectului; tehnologiile informaionale pe care urmeaz a funciona sistemul pot fi depite pn la finalizarea acestuia etc. Execuia proiectului presupune, din perspectiva managementului, iniierea lucrrilor planificate, asigurarea resurselor necesare realizrii acestora, ncadrarea n termenele prevzute, asigurarea calitii rezultatelor furnizate. Monitorizarea vizeaz ncadrarea n ealonarea fcut i ajustarea, n funcie de necesiti, a datelor de ncepere i terminare i a disponibilitii resurselor. Spre deosebire de urmrirea execuiei, nivelul de detaliere este aici, mult mai mare. Necesitatea schimbrilor n CVP este semnalat fie de constatrile provenite din urmrirea execuiei i evaluarea sistemului, fie de msurile de diminuare sau eliminare a riscurilor. Consecinele lor asupra planificrii i derulrii proiectului sunt de amploare mai mare dect cele rezultate din urmrirea execuiei i monitorizare. Informaiile privitoare la starea proiectului sunt difuzate, perioadic, tuturor celor interesai i se refer la execuia proiectului n raport cu planificarea. Aa cum s-a menionat, caracterul de produs intangibil al software-ului dezvoltat face ca aceste informri s constituie principalul mod de control al avansului activitilor.

1.1 Administrarea exploatrii sistemelor informatice de gestiune

Exploatarea cuprinde perioada de utilizare a sistemului pentru efectuarea lucrrilor i activitilor curente de la beneficiar. Demareaz odat cu instalarea i acceptarea softwareului i se ncheie atunci cnd se decide retragerea sistemului din uz. Principalele activiti efectuate n aceast poriune a ciclului de via al sistemului sunt urmtoarele: operarea sistemului asigurarea asistenei tehnice urmrirea i rezolvarea anomaliilor aprute la utilizare Anomaliile raportate pot declana reluarea unor activiti de dezvoltare i, n consecin, i de management al proiectului, pentru constatarea sursei acestora i efectuarea remedierilor necesare. n acelai mod, sunt tratate i eventualele solicitri de extindere sau completare, formulate de ctre utilizatori, dup intrarea n exploatare.