Print Email Download

Prezentarea generala a firmei

Introducere

În cadrul acestei lucrări va fi prezentat sistemul informatic utilizat în mod curent de compania Software Development & Consulting pentru a-şi putea desfăşura activitatea de consultanţă IT în mod eficient. În activitatea de consultanţă IT se lucrează în principal pe bază de proiecte în cadrul cărora se desfăşoară activităţile aferente acestora.

În momentul de faţă, există pe piaţă o gamă foarte variată de produse software de managementul proiectelor care îndeplinesc o multitudine de cerinţe precum colaborativitate, urmărirea activităţilor, managementul portofoliului de proiecte, managementul resurselor precum şi cel al documentelor. Dezavantajele acestor produse software constă în faptul că pot fi foarte costisitoare, cost justificat de complexitatea lor, pot fi în mod semnificativ inflexibile datorită tehnologiilor cu care au fost create şi tot din acest motiv pot fi personalizate şi extinse mai greu sau într-un timp mai îndelungat.

Dacă pentru unele domenii de activitate, Internetul nu oferă soluţia optimă, pentru marea majoritate acesta reprezintă opţiunea ideală. Astfel, pentru a valorifica avantajele oferite de aplicaţiile web sistemul informatic prezentat a fost creat utilizând produsul Oracle Application Express. Acest produs software permite crearea de aplicaţii web în mod rapid şi organizat oferind astfel posibilitatea creării unui sistem informatic atât flexibil cât şi complex deoarece orice nouă cerinţă de personalizare poate fi rezolvată fără eforturi foarte mari.

Această lucrare este concepută în trei capitole, cu numeroase subcapitole şi se finalizează cu o serie de concluzii şi propuneri cu privire la posibilităţile de dezvoltare a sistemului realizat.

Capitolul I pe lângă faptul că realizează o descrierea a problemei economice de rezolvat mai face şi un studiu preliminar care urmăreşte cunoaşterea în ansamblu a sistemului ce trebuie informatizat. Capitolul II este un capitol pur teoretic ce prezintă instrumentele şi tehnologiile folosite pentru realizarea aplicaţiei informatice.

Capitolul III face o prezentare detaliată, atât teoretică cât şi practică a modului de analiză şi proiectare a aplicaţiei precum şi a sistemului în sine.

Partea de Concluzii prezintă anumite concluzii şi sugestii conturate în timpul procesului de realizare al aplicaţiei.
CAPITOLUL 1. Prezentarea activităţii firmei Software Development & Consulting S.R.L.

În acest capitol va fi prezentată problema economică ce urmează să fie rezolvată prin realizarea unui sistem informatic dedicat.

1.1. Prezentarea generală a firmei

Software Development & Consulting S.R.L. este o companie lider în dezvoltarea şi implementarea de proiecte software şi de consultanţă în domeniul informatic, fiind primul IBM Premier Software Business Partner din România, un important partener Microsoft în domeniul Document Management şi nu în ultimul rând partener certificat Oracle.

Principala arie de interes o reprezintă proiectele de integrare de aplicaţii, integrare de date, consolidare de date, Document Management, Content Management, Internet Banking, arhivare de informaţii şi documente şi nu în ultimul rând ERP. Pentru toate aceste arii de interes firma oferă servicii de consultanţă IT [MANU01].

Software Development & Consulting (SDC) este o companie cunoscută ca fiind unul dintre cei mai importanţi integratori de tehnologie de pe piaţa IT din România. SDC are experienţă profesională în dezvoltarea şi implementarea de soluţii software, în asigurarea de servicii de consultanţă, training de specialitate, training de management al costurilor, training pentru gestionarea informaţiei şi resurselor [MANU01].

Fondată în 1996, SDC este o societate privată, având 100% capital românesc. În anul 2006 SDC a fost preluată de compania Omnilogic. În urma acestei schimbări, compania s-a transformat din dezvoltator de software în integrator orientându-se astfel către soluţii de software complexe care să permită dezvoltarea unor noi parteneriate, implementarea unor soluţii avansate şi consolidarea poziţiei companiei în zona de consultanţă IT [MANU01].

Software Development & Consulting S.R.L. este organizată în patru părţi operative [ROF001], respectiv:

Ø O parte comercială - departamentele vânzări, marketing şi relaţii cu publicul;

Ø O parte financiară - departamentul financiar-contabil;

Ø O parte de logistică - departamentul de resurse umane, serviciul juridic şi serviciul administrativ;

Ø O parte de dezvoltare software organizată în practici în funcţie de domeniul tehnic abordat.

1.2. Compartimentele firmei

În acest subcapitol se face o prezentare mai detaliată a departamentelor din organigrama companiei Software Development & Consulting S.R.L. aşa cum apare în “Regulamentul de organizare şi funcţionare” al firmei [ROF001]:

a) Directorul General asigură conducerea curentă a activităţii societăţii comerciale prin directorii executivi şi compartimentele funcţionale subordonate nemijlocit acestuia, conform structurii organizatorice aprobate. De asemenea, Directorul General reprezintă societatea în relaţiile cu terţi.

b) Directorul Economic este subordonat Directorului General şi are în subordine departamentul Financiar - Contabil. Directorul economic este responsabil de organizarea şi îndrumarea acţiunii de întocmire a rapoartelor statistice în domeniul financiar-contabil, a bilanţului contabil, a balanţei de verificare şi a altor situaţii informaţionale specifice.

Departamentul Financiar-Contabil: elaborează şi fundamentează indicatorii financiari ai societăţii reflectaţi de bugetul de venituri şi cheltuieli, asigură organizarea şi funcţionarea normală a contabilităţii patrimoniale, asigură respectarea integrităţii patrimoniului societăţii şi ia măsuri pentru întregirea lui, întocmeşte documentele de salarizare a personalului (fluturaşii de salarii) şi întocmeşte jurnalele conturilor.

c) Directorul Comercial este subordonat Directorului General şi are în subordine următoarele departamente: Vânzări, Marketing şi Relaţii cu publicul. Directorul Comercial asigură fundamentarea şi elaborarea strategiei şi politicii comerciale a societăţii, asigură şi întreţine legăturile contractuale cu furnizorii şi clienţii, aprobă strategiile de marketing şi PR şi de asemenea participă la târguri naţionale/internaţionale de profil făcând propuneri de colaborare şi implementare de noi produse în oferta firmei.

Departamentul de Vânzări: se ocupă cu participarea la diverse licitaţii din domeniul IT, elaborarea ofertelor de servicii, elaborarea contractelor câştigate fie în domeniul privat fie în domeniul public prin intermediul licitaţiilor precum şi de promovarea acţiunilor de publicitate menite să sporească cifra vânzărilor, toate acestea făcându-se conform hotărârilor adoptate în acest sens de conducerea societăţii.

Departamentul de Relaţii cu Publicul: se ocupă cu promovarea imaginii firmei, informarea atât a clienţilor din portofoliul firmei cât şi a potenţialilor clienţi despre activităţile companiei, fie în mod direct sau prin intermediul mass-mediei prin comunicate informative şi interviuri, analiza ofertelor de publicitate şi selectarea celor mai avantajoase metode de promovare (atât din perspectiva impactului asupra pieţei, cât şi din perspectiva preţurilor).

Departamentul de Marketing: se ocupă cu efectuarea de studii de piaţă precum studiul concurenţei, analiza preţurilor practicate pe piaţă pentru domeniul de activitate curent şi realizarea de propuneri fundamentale de modificare a preţurilor practicate de companie, întocmirea de rapoarte şi prognoze referitoare la evoluţiile importante de la nivel macroeconomic şi implicaţiile acestora asupra politicii organizaţionale a firmei şi de asemenea gestionează modul de realizare şi utilizare a bazei de date (de marketing) a firmei.

d) Directorul Logistic este subordonat Directorului General şi are în subordine următoarele departamente: Resurse Umane, Serviciul juridic, Serviciul administrativ. Directorul Logistic urmăreşte îndeaproape evidenţa personalului, respectarea normelor în vigoare cu privire la protecţia muncii, participă la fundamentarea cheltuielilor administrativ-gospodareşti, asigură respectarea strictă a legislaţiei şi soluţionează litigiile patrimoniale cu alte societăţi comerciale, conform prevederilor legale.

Departamentul Resurse Umane: întocmeşte toate operaţiunile referitoare la dinamica personalului (angajare, concediere, schimbarea locului de muncă, promovarea, pensionarea) şi con-lucrează cu departamentul financiar-contabil asigurând calculul drepturilor băneşti ale salariaţilor şi acordarea acestora la termenele prevăzute.

Serviciul Juridic: urmăreşte modul în care sunt respectate dispoziţiile legale şi prevederile statutului cu privire la apărarea şi gospodărirea patrimoniului societăţii, actualizează actele normative existente în societate, primeşte, difuzează şi prelucrează actele normative noi şi, de asemenea, acordă asistenţă juridică subdiviziunilor organizatorice interesate.

Serviciul Administrativ: se ocupă cu paza şi protocolul societăţii şi cu partea de secretariat.

e) Directorul Tehnic este subordonat Directorului General şi are în subordine departamentul de dezvoltare software care este organizat în următoarele practici: Business Solutions, Project Management, Java, Document Management, Oracle şi System Administration. Aceste practici sunt coordonate fiecare de câte un Practice Manager care în mod normal este un consultant senior din cadrul practicii respective. Directorul Tehnic este responsabil cu coordonarea activităţilor acestor practici astfel încât desfăşurarea proiectelor de consultanţă IT să se facă în mod cursiv, fără probleme.

Practica de Business Solutions: primeşte caietele de sarcini ale licitaţiilor comerciale la care participă firma şi alcătuieşte soluţiile software care răspund cel mai bine cerinţelor exprimate în aceste caiete selectând produsele software propuse spre implementare.

Practica de Project Management: se ocupă (în colaborare cu celelalte practici) cu realizarea planurilor de proiecte conform soluţiilor software specificate de practica de Business Solutions. În timpul desfăşurării proiectelor asigură bunul mers al acestora prin verificarea existenţei contextului necesar rezolvării fiecărei activităţi în parte din cadrul proiectelor.

Practica de Java: se ocupă de activităţile din cadrul proiectelor care necesită utilizarea framework-ului Java.

Practica de Document Management: dezvoltă extensii pentru produsul propriu eDoc şi se ocupă de proiectele care au ca scop implementarea acestui produs ca şi soluţie pentru activitatea de management de documente.

Practica de Oracle: se ocupă de implementări ale produselor Oracle - Database, Business Intelligence, ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) şi Portal şi de integrări ale acestora cu alte produse software existente deja în portofoliul clienţilor.

Practica de System Administration: se ocupă de activităţile din cadrul proiectelor care necesită instalări de componente hardware, instalări de sisteme de operare şi reţelistică.

Organizarea structurată pe niveluri a relaţiilor ierarhice existente între departamentele descrise anterior este evidenţiată în organigrama societăţii [ROF001] (figura 1-1).

1.3. Activităţile firmei

Compania Software Development & Consulting (SDC) are ca şi domeniu de activitate furnizarea de servicii de consultanţă IT [ROF001]. Această activitate începe în cadrul departamentului comercial o dată cu participarea reprezentanţilor de vânzări la diverse licitaţii de proiecte din domeniul IT. Anterior acestor licitaţii, posibilii clienţi contractează diverse firme de profil şi transmit către firmele interesate un anumit caiet de sarcini care reprezintă practic cerinţele preliminare ale soluţiilor software ce se cer implementate.

Acest caiet de sarcini este transmis departamentului de dezvoltare software, respectiv practicii ce elaborează soluţiile de afaceri, care urmează să ofere răspunsuri clare tuturor cerinţelor din respectivul caiet. Elaborarea răspunsurilor detaliate (cum se execută o anumită funcţionalitate, detalii legate de funcţionalităţi personalizate) se face în colaborare cu fiecare practică care va implementa ulterior respectiva soluţie. Finalitatea acestei activităţi este elaborarea unui document amplu ce va conţine prezentarea detaliată a soluţiei tehnice oferite de firma SDC [PROC01].

O dată elaborat acest document, departamentul comercial va estima costul implementării soluţiei furnizate (componente hardware, licenţe pentru produse software, costuri servicii, etc) şi va ataşa documentul rezultat ofertei finale care este trimisă către potenţialul client.

În cazul câştigării licitaţiei se demarează o serie de activităţi care au ca scop implementarea cu succes a soluţiei tehnice propuse anterior în termenii comerciali existenţi în contractul încheiat în urma licitaţiei. Conform procedurilor de lucru din cadrul departamentului de dezvoltare software [PROC01], aceste activităţi sunt:

Ø Directorul tehnic desemnează un manager de proiect din cadrul practicii de Project Management.

Ø Directorul tehnic împreună cu managerul de proiect aleg un şef al echipei tehnice care va executa implementarea proiectului. Alegerea şefului tehnic al echipei se face în funcţie de natura proiectului şi de anvergura sa şi nu trebuie să fie neapărat un Practice Manager, astfel, pentru un proiect ce implementează o soluţie tehnică de consolidare de date la nivel de baze de date Oracle, şeful echipei tehnice poate fi un consultant din cadrul practicii Oracle care are minim trei ani experienţă în această activitate.

Ø O dată ales şeful echipei tehnice se trece la realizarea planului de proiect în care sunt trecute activităţile necesare pentru implementarea proiectului, resursele alocate (umane, tehnice, fizice) pentru rezolvarea activităţilor precum şi interdependenţele dintre acestea. După cum se poate observa, prin alocarea resurselor umane la planul de proiect se stabileşte chiar echipa tehnică care urmează să implementeze soluţia tehnică.

Ø După implementarea efectivă a soluţiei tehnice proiectul este finalizat de obicei cu o etapă de instruire a utilizatorilor în folosirea sistemului implementat.

După finalizarea cu succes a implementării soluţiei tehnice, clientul contractează în mod uzual şi un an de suport care constă de fapt în asistarea clientului, contra cost, în folosirea sistemului implementat şi rezolvarea eventualelor probleme care pot apărea. Există însă şi situaţii când în urma utilizării sistemului apar cerinţe pentru dezvoltarea unor noi funcţionalităţi. Aceste cerinţe sunt tratate ca activităţi individuale în cadrul planului de proiect şi în funcţie de complexitatea lor pot avea un cost propriu separat de cel aferent contractului de suport.

1.4. Prezentarea activităţii care va fi informatizată

În activitatea de consultanţă IT, după cum sa prezentat anterior, se lucrează în principal pe bază de proiecte în cadrul cărora se desfăşoară activităţile necesare pentru implementarea cu succes a soluţiilor tehnice oferite.

Deoarece activitatea consultanţilor IT presupune şi deplasări la locaţia clientului (care poate avea multiple sucursale în ţară sau chiar în afara ţării) este greu de ţinut o evidenţă la zi a fiecărei activităţi în parte, fapt care poate duce la multiple probleme.

Printre cele mai grave probleme care pot să apară menţionăm:

Ø probleme de comunicare între membrii echipelor de proiecte, între echipă şi şeful tehnic al acesteia şi chiar între şefii de echipe şi directorul tehnic;

Ø întârzieri nejustificate din punct de vedere tehnic ale activităţilor;

Ø imposibilitatea ţinerii unei evidenţe a întârzierilor cauzate de client;

Ø lipsa de coordonare sau coordonarea întârziată între membrii echipelor de proiecte;

Ø alocarea ineficientă a consultanţilor atât în sensul subalocării cât şi al supraalocării acestora;

Ø propagarea în cascadă a întârzierilor cauzate de supraalocarea consultanţilor;

Ø lipsa unei imagini de ansamblu asupra stării desfăşurării proiectelor.

În lipsa apariţiei unor probleme, modul normal de desfăşurare a activităţilor din cadrul departamentului de dezvoltare software cuprinde următoarele operaţii principale [PROC01]:

Ø Directorul tehnic care se află la nivel managerial decide începerea unui nou proiect în urma informaţiilor primite de la departamentul comercial (în principiu, această decizie este declanşată de directorul comercial care anunţă câştigarea unei licitaţii de proiect).

Ø Directorul tehnic alege un manager de proiect din practica de Project Management şi împreună cu acesta se alege şi un şef tehnic al echipei ce urmează să implementeze soluţia tehnică oferită.

Ø Managerul de proiect împreună cu şeful de echipă elaborează planul de proiect şi în acelaşi timp aleg şi specialiştii care vor face parte din echipa de proiect în funcţie de activităţile ce trebuiesc desfăşurate.

Ø În procesul de alegere al echipei se ţine cont de faptul că un consultant nu trebuie neapărat să facă parte din echipă pe toată perioadă desfăşurării proiectului ci trebuie să fie disponibil în perioada când trebuie să rezolve respectiva activitate căruia i-a fost asignat ca resursă umană în cadrul planului de proiect.

Ø Pentru fiecare activitate se stabileşte ce consultant o poate desfăşura (specialist IT), o dată de început şi o dată ţintă de rezolvare (deadline-ul activităţii) precum şi o prioritate ataşată acesteia. În stabilirea deadline-urilor activităţilor trebuie să se ţină seama şi de priorităţile acestora deoarece activităţile cu prioritate înaltă, din punct de vedere contractual, sunt posibile cauze de reziliere de contract (dacă nu sunt îndeplinite complet) sau aplicare de sancţiuni financiare (dacă nu sunt îndeplinite în perioada alocată, adică au întârzieri).

Ø O dată stabilite toate acestea, proiectul poate fi demarat şi fiecare consultant trece la executarea activităţilor proprii raportând periodic starea de desfăşurare a acestora şefului echipei tehnice a proiectului aferent, pentru a preîntâmpina apariţia unor întârzieri sau pentru a anunţa din timp posibilitate apariţiei acestora.

Ø O dată rezolvată, o activitate este considerată ca fiind închisă. Dacă toate activităţile unui proiect sunt închise atunci managerul de proiect poate considera proiectul închis.

În desfăşurarea activităţilor de zi cu zi managerii de proiecte şi şefii de echipe din cadrul companiei se pot confrunta cu proiecte ce se desfăşoară în paralel sau chiar activităţi din cadrul aceluiaşi proiect care au perioade de rezolvare care se suprapun. În aceste situaţii (indiferent de locaţia desfăşurării proiectelor) este nevoie de o imagine de ansamblu care să permită asignarea optimă a consultanţilor la activităţile ce trebuiesc desfăşurate.

În acest context decizia de alocare a unui consultant la o anumită activitate devine deja o operaţie delicată şi trebuie să ia în calcul o multitudine de factori precum:

Ø cunoştiinţele tehnice ale consultanţilor (de exemplu, dacă un angajat are competenţe pe produse Oracle şi nu pe partea de reţea);

Ø disponibilitatea consultanţilor (dacă un consultant potrivit pentru respectiva activitate este şi liber să o desfăşoare sau dacă este alocat deja la o altă activitate cu prioritate mai mare);

Ø pentru o activitate cu prioritate înaltă se verifică dacă respectivul consultant are întârzieri dese (deoarece la activităţile cu prioritate înaltă nu se admit decât întârzierile cauzate de client, în caz contrar compania poate suferi pierderi financiare conform specificaţiilor contractuale);

Ø deoarece consultanţii primesc comisioane când sunt implicaţi în proiecte se încearcă o echilibrare a acestora pentru a menţine un nivel ridicat al satisfacţiei angajatului.

CAPITOLUL 2. Limbaje şi tehnologii informatice utilizate

În acest capitol vor fi prezentate metodele şi tehnologiile folosite pentru realizarea aplicaţiei.

2.1. UML (Unified Modeling Language)

În anii '90 au apărut o multitudine de metode destinate formalizării procesului de dezvoltare a sistemelor informatice, fiecare dintre acestea utilizând un set de notaţii proprii [LUSA03].

Printre cele mai populare metode se numărau:

Ø OMT (Object Modeling Technique) - James Rumbaugh

Ø OOD (Object Oriented Design) - Greedy Booch

Ø OOSE (Object-Oriented Software Engineering) - Ivar Jacobson

Fiecare dintre metodele menţionate anterior trata cu precădere o anumită etapă din ciclul de viaţă al unui produs software. Astfel, metoda OMT era considerată potrivită pentru etapa de analiză, metoda OOD era considerată cea mai adecvată pentru etapa de proiectare iar metoda OOSE se axa mai ales pe etapa de analiză comportamentală.

În acest context, aşa cum se prezintă în lucrarea [SUCI09], “limbajul UML s-a născut din dorinţa de a unifica cele mai importante concepte introduse de fiecare dintre aceste metode precum şi pentru a găsi o notaţie standard de modelare a acestor concepte”. Astfel, în septembrie 1997 competiţia acerbă existentă între susţinătorii metodelor menţionate anterior ia sfârşit prin adoptarea de către consorţiul internaţional OMG (Object Management Group) a limbajului UML ca şi limbaj standard de modelare a aplicaţiilor.

UML reprezintă un standard de notaţie care introduce un set de nouă diagrame cu ajutorul cărora se poate descrie un sistem informatic. Cu toate acestea “UML nu propune şi un proces de utilizare a acestor diagrame” în construcţia unei aplicaţii [SUCI09].

Diagramele propuse de limbajul UML sunt următoarele: diagrame de cazuri de utilizare, diagrame de clase, diagrame de secvenţă, diagrame de stări, diagrame de colaborare, diagrame de activităţi, diagrame de componente, diagrame de exploatare şi diagrame de pachete.

În lucrarea [LUSA03] aceste diagrame sunt grupate în următoarele categorii:

Ø Diagrame pentru modelarea proceselor de afaceri - acestea oferă o imagine de ansamblu a funcţionalităţilor pe care trebuie să le ofere sistemul informatic (diagramele de cazuri de utilizare);

Ø Diagrame pentru modelarea structurii statice - acestea descriu atât structura sistemului informatic cât şi responsabilităţile acestuia (diagramele de clase şi de obiecte);

Ø Diagrame pentru modelarea structurii dinamice - descriu comportamentul sistemului informatic şi multiplele interacţiunile care au loc între entităţile din cadrul acestuia (diagrame de secvenţă, de colaborare, de stări şi de activităţi);

Ø Diagrame arhitecturale - descriu componentele executabile din cadrul sistemului şi determină plasarea acestora în mod grupat pe echipamentele hardware ce alcătuiesc configuraţia fizică a acestuia (diagramele de componente, de exploatare şi de pachete).

Deşi individual fiecare diagramă ilustrează soluţia problemei dintr-un punct distinct de vedere, în final aceste puncte de vedere se intercoreleaza. Astfel, modul de interacţiune dintre diagrame se poate reprezenta ca în figura următoare (vezi figura x).

În cadrul lucrării [LUSA03] diagramele UML sunt prezentate astfel:

Diagrame de cazuri de utilizare - au rolul de a stabili aria de cuprindere a sistemului reprezentând într-o formă grafică funcţionalităţile pe care acesta trebuie să le îndeplinească. Din acest motiv modelul reprezentat de diagramele de cazuri de utilizare împreună cu descrierea succintă a fiecărui caz identificat se numeşte modelul cerinţelor.

Diagrame de clase - descriu structura statică internă a sistemului atât prin intermediul claselor şi atributelor cât şi prin operaţiile aferente acestora şi prin descrierea relaţiilor dintre ele. Construcţia acestor diagrame se face în etapa de elaborare a sistemului informatic acestea fiind cele mai importante diagrame din această etapă.

Diagrame de secvenţă - prezintă în mod grafic diversele interacţiunile care au loc între obiectele sistemului informatic, observate în ordine cronologică. Prin intermediul acestor diagrame se identifică obiectele şi clasele aferente unui scenariu şi mesajele prin care acestea comunică. Ca şi diagramele de colaborare, diagramele de secvenţă descriu un caz de utilizare.

Diagrame de colaborare - prezintă în mod grafic multiplele interacţiunile existente între obiectele sistemului organizate relativ şi legăturile dintre acestea.

Diagrame de stări (de tranziţie a stărilor) - sunt utilizate în descrierea comportamentului obiectelor aparţinând unui clase.

Diagrame de activităţi - sunt variante ale diagramelor de stări organizate în raport cu acţiunile şi destinate în primul rând reprezentării comportamentului intern al unei metode (implementarea unei operaţii) sau a unui caz de utilizare.

Diagrame de componente - prezintă dependenţele statice sau dinamice existente între componentele software ce alcătuiesc un sistem informatic atât la nivel de cod sursă (înainte de compilare) cât şi la nivel de cod binar (înainte de link-editare) sau executabil.

Diagrame de exploatare sau de desfăşurare - modelează atât configuraţia elementelor de procesare la momentul execuţiei cât şi modul de distribuire al componentelor software, proceselor şi obiectelor pe care aceste elemente le conţin. Un sistem informatic poate avea o singură astfel de diagramă asociată. Acest tip de diagramă surprinde doar componentele de la momentul execuţiei, nu şi pe cele utilizate în etapele de compilare sau link-editare.

Diagrame de pachete sau module - oferă mijloace de grupare în pachete pentru elementele ce se regăsesc în cadrul diagramelor. Aceste grupări sunt foarte utile în cazul sistemelor informatice complexe. De menţionat este faptul că deşi un pachet sau modul poate grupa atât elemente din cadrul altor tipuri de diagrame cât şi alte pachete, cu toate acestea pachetul nu descrie comportamentul elementelor sale. Criteriile de grupare nu sunt predefinite ci sunt alese în funcţie de caracteristicile sistemului descris.
2.2. Sistemul de gestiune de baze de date Oracle

“Oracle este un sistem de gestiune a bazelor de date (SGBD) complet relaţional, extins, cu facilităţi din tehnologia orientată obiect” [LUNG05]. Sistemul Oracle este proprietar firmei Oracle Corporation care în momentul de faţă este unul dintre cei mai importanţi furnizori de software de gestiune a datelor aflându-se pe primul loc în topul principalilor furnizori de astfel de sisteme cu 47% din segmentul de piaţă, urmat de IBM cu 21% şi Microsoft cu 17% [Web003].

Prima versiune a sistemului Oracle a apărut la sfârşitul anilor 70 respectând în totalitate teoria relaţională în sensul că a implementat modelul de date relaţional pentru baza de date precum şi un limbaj de programare relaţional SQL, respectiv SQL*Plus, care reprezintă o dezvoltare a limbajului standard [VELU09].

În anul 1997 s-a lansat SGBD Oracle 8.0, care reprezenta apariţia unei noi generaţii de baze de date Oracle întrucât marchează trecerea de la arhitectura iniţială de tip client/server a sistemului la arhitectura Network Computing [LUNG05].

În anul 2001 a fost lansată versiunea Oracle 9i care a iniţiat trecerea la o nouă generaţie de servicii orientate spre mediul internet. Această versiune a sistemului devine “mai mult decât un suport pentru baze de date deoarece oferă o infrastructură completă de software pentru afaceri electronice şi rulează pe o varietate de sisteme de calcul şi de operare: SUN - SOLARIS, HP - UX, IBM - AIX, WINDOWS şi LINUX” [LUNG05].

În anul 2003 a apărut pe piaţă versiunea 10g a sistemului Oracle care vine cu noi facilităţi faţă de sistemul Oracle 9i şi marchează trecerea la generaţia Grid Computing care este o tehnologie informatică ce oferă suport complet pentru utilizarea coordonată a mai multor servere mici care acţionează împreună în mod unitar formând astfel un sistem foarte puternic [VELU09].

Sistemul Oracle, ajuns acum la versiunea 11g, a devenit prin dezvoltări şi îmbunătăţiri succesive mai mult decât un SGBD relaţional. Astfel, sistemul Oracle reprezintă deja o infrastructură pentru bazele de date pe internet în arhitectură Grid Computing [VELU09].

Arhitectura sistemului Oracle, aşa cum este prezentată în lucrarea [VELU09], grupează componentele acestuia pe trei niveluri: nucleul Oracle reprezentat de baza de date Oracle, interfeţele de dezvoltare şi instrumentele de întreţinere.

Nucleul Oracle are ca şi componente limbajele de programare (SQL, PL/SQL, Java şi precompilatoare), sistemul bazei de date şi instanţa bazei de date. În varianta distribuită a bazei de date Oracle regăsim Real Application Clusters care este o tehnologie ce permite adăugarea transparentă a unei noi instanţe a bazei de date prin adaptarea automată a resurselor pentru încorporarea noii instanţe în mod insesizabil pentru utilizator.

Interfeţele pentru dezvoltarea aplicaţiilor ce utilizează baze de date Oracle sunt multiple şi oferă un mediu complet de dezvoltare pentru aplicaţii web.

Instrumentele utilizate în procesul de întreţinere a bazei de date sunt destinate în principal administratorilor bazei de date şi mai puţin dezvoltatorilor de aplicaţii. Principalul instrument utilizat în acest proces este Oracle Enterprise Manager (OEM) care are o interfaţă web-based prin intermediul căreia se poate monitoriza activitatea întregului sistem al bazei de date, se pot identifica problemele în mod facil şi se pot cere chiar sfaturi pentru rezolvarea lor. Tot cu ajutorul acestui instrument se poate automatiza o politică de salvare de copii (backup) a bazei de date.

Interacţiunea directă cu baza de date se face prin intermediul celor două limbaje de programare aflate în nucleul Oracle: SQL (Structured Query Language) şi respectiv PL/SQL (Procedural Language/SQL) [VELU03].

SQL este un limbaj relaţional de regăsire, standardizat internaţional ANSI SQL-86 (American National Standard Institute, anul 1986). Oracle conţine o extensie a acestui limbaj, respectiv SQL*Plus care permite descrierea şi manipularea datelor într-o bază de date relaţională într-un mod neprocedural.

PL/SQL este un limbaj procedural propriu bazei de date Oracle suportând şi un set de comenzi SQL pentru accesul la date.

Ambele limbaje de programare utilizează o serie de concepte Oracle dintre care cele mai importante prezentate în lucrările [LUNG05] şi [VELU03] sunt:

Ø Tabela sau relaţia reprezintă un ansamblu format din n coloane (atribute) şi m rânduri (tupluri sau linii) care nu conţine date la nivel agregat şi liniile sunt distincte unele faţă de altele.

Ø Cheia primară este reprezentată de o coloană sau de un set de coloane dintr-o tabelă care identifică un tuplu în mod unic.

Ø Viziunea sau vederea reprezintă o selecţie de date dintr-una sau mai multe tabele.

Ø Un cluster reprezintă o modalitate de grupare a rândurilor uneia sau a mai multor tabele cu scopul de a mări viteza de execuţie a unor operaţii consumatoare de timp.

Ø Comanda este o instrucţiune de tip SQL care este trimisă spre execuţie unei baze de date Oracle.

Ø Cursorul este un identificator spre o zonă de memorie dinamic alocată pentru executarea unor comenzi.

Ø Blocul reprezintă o grupare a mai multor instrucţiuni SQL şi PL/SQL care se execută împreună.

Ø Cererea reprezintă o comandă SELECT din cadrul limbajului SQL de regăsire a datelor din baza de date.

Ø Declanşatorul este un subprogram executat automat în urma unui eveniment particular.

Ø Tranzacţia este un ansamblu omogen de operaţii care are rolul de a asigura coerenţa datelor prin modul său de execuţie - fie complet sau deloc.

2.3. Oracle Application Express

Oracle Application Express (Oracle APEX), cunoscută anterior sub denumirea de HTMLDB, reprezintă un instrument pentru dezvoltarea rapidă a aplicaţiilor web de tip “introducere de date şi raportare” care utilizează baze de date Oracle. Folosind doar un browser web şi fără o experienţă deosebită în programare, se pot dezvolta şi implementa aplicaţii profesionale care sunt atât rapide cât şi sigure [Web001].

Pentru a dezvolta, implementa sau rula aplicaţii utilizând Oracle Application Express nu este necesară instalarea niciunui soft client deoarece APEX oferă trei servicii care susţin toate etapele necesare acestor activităţi:

Ø Application Builder - pentru a dezvolta aplicaţiile web;

Ø SQL Workshop - pentru lucrul cu obiectele din baza de date şi pentru a executa comenzi SQL;

Ø Utilitare - permite încărcarea şi descărcarea datelor atât în fişiere simple cât şi în foi de calcul.

Application Express este un instrument de dezvoltare facilă a aplicaţiilor web fiind utilizat în mod frecvent la nivelul întreprinderilor mici şi mijlocii dar şi la nivel departamental în cadrul companiilor mari. Uşurinţa în dezvoltare este asigurată de modul de abordare al procesului de dezvoltarea care utilizează aproape în mod exclusiv interfeţe de tipwizard [Web002].

În Oracle Application Express, redactare codului este declarativă, adică nu se generează cod, nu se compilează cod ci pur şi simplu se interacţionează cu interfeţele de tip wizard (pentru a crea diverse obiecte precum videoformate, rapoarte, grafice) şi cu paginile de proprietăţi (pentru a modifica obiectele existente). În definirea rapoartelor şi a graficelor este utilizat limbajul SQL şi de aceea cunoaşterea unor comenzi de bază (SELECT) este totuşi necesară. Pentru dezvoltatorii avansaţi care doresc funcţionalităţi mai complexe, aceştia pot utiliza şi fragmente de cod PL/SQL sau JavaScript [Web001].

Oracle Application Express generează aplicaţiile în timp real pornind de la date stocate în tabelele existente în baza de date. Când se crează o aplicaţie nouă sau se extinde una existentă, mediul APEX pur şi simplu creează sau modifică metadate stocate în tabelele sale în baza de date deoarece platforma de dezvoltare rezidă efectiv în baza de date Oracle, componentele APEX fiind reprezentate efectiv de aproximativ 215 tabele şi 200 de obiecte PL/SQL [Web001].

Arhitectura platformei APEX este dependentă de versiunea bazei de date utilizată [Web002], astfel:

Ø Versiunile mai vechi de 10.2.0.3 necesită Oracle HTTP Server (Apache) împreună cu plug-in-ul mod_plsql. În această variantă plug-in-ul intermediază comunicaţiile între serverul web şi obiectele APEX din baza de date, intermediere care transmite cererile provenite din browser-ul web către apeluri de proceduri stocate în baza de date (vezi figura x).

Ø Începând de la Oracle Database 10.2.0.3 (inclusiv Oracle Database 10g Express Edition), serverul HTTP şi mod_plsql pot fi înlocuite cu Embedded PL/SQL Gateway (EPG). În această variantă rutinele EPG rulează direct în serverul XML DB HTTP din baza de date Oracle şi include funcţionalităţile de bază ale mod_plsql dar nu mai necesită existenţa unui Oracle HTTP Server (vezi figura x).

Rapoarte: se realizează utilizând o interfaţă de tip wizard care permite selectarea controalelor de afişat şi paginaţia. Ulterior se poate configura şi modul de sortare al coloanelor afişate, tipul de export (CSV, XML), setările de printare, navigare de tip “Drill-Down” către alte rapoarte, grafice sau videoformate şi aplicarea schemelor de autorizare. Pentru elaborarea de template-uri speciale de afişare (RTF) se poate realiza o integrare cu produsul BI Publisher care permite printarea şi în format PDF, Word, Excel sau HTML.

Videoformate utilizate pentru introducerea datelor: există o gamă variată de videoformate predefinite precum videoformate tabelare, de tip Master-Detail, bazate pe servicii Web, pe proceduri stocate sau direct pe tabele din baza de date. Pe lângă validarea câmpurilor conform anumitor formate şi detectarea actualizărilor eşuate (raportate prin mesaje în interfaţă) videoformatele beneficiază şi de controale speciale predefinite de genul listelor de valori (LOVs), pop-up-uri de tip calendar, controale de tip shuttle şi de selectare de fişiere din sistemul de operare.

Grafice: de tip SVG (Scalable Vector Graphics), HTML sau Flash care pot fi configurate să se reîmprospăteze la anumite intervale de timp pentru a afişa mereu informaţii curente.

Navigarea între pagini: se face prin taburi (standard, părinte), liste, breadcrumbs, prin link-uri puse pe imagini şi text, utilizând ierarhii (tree) şi prin butoane.

Design: APEX oferă un set de 20 de teme predefinite de afişare a obiectelor aplicaţiei bazate pe un set de template-uri preexistente, astfel, la trecerea de la o temă la alta aplicarea modificărilor de design se face în mod consecvent în toate paginile aplicaţiei. Aceste template-uri pot fi modificate la nivel de CSS şi HTML.

Securitate: APEX oferă scheme predefinite de autentificare precum LDAP, Single Sign-On, metode particulare (utilizator/parola dintr-o tabelă), utilizatori Oracle Application Express, utilizatori ai bazei de date, fără autentificare (folosind Database Access Descriptor) şi reguli de autorizare definite central pentru toată aplicaţia dar care pot fi utilizate de la nivelul unei pagini web până la nivel de obiect de tip buton sau chiar link pentru afişarea condiţionată a acestora.

CAPITOLUL 3. Realizarea aplicaţiei informatice privind activitatea de consultanţă IT

În capitolul de faţă se va face descrierea detaliată a procesului de realizare a aplicaţiei informatice pornind de la analiza cerinţelor şi realizarea diagramelor UML până la prezentarea efectivă a sistemului informatic implementat.

3.1. Analiza activităţii de alocare a consultanţilor IT în cadrul echipelor de proiecte

Aplicaţia ce urmează să fie realizată îşi propune să rezolve problema managementului eficient la nivelul activităţii de consultanţă IT care, după cum s-a prezentat anterior, se bazează în principal pe proiecte în cadrul cărora se desfăşoară activităţile necesare pentru implementarea cu succes a soluţiilor tehnice oferite.

Deoarece activitatea consultanţilor IT presupune şi deplasări la locaţia clientului (care poate avea multiple sucursale în ţară sau chiar în afara ţării) aplicaţia realizată va fi de tip web pentru a putea fi accesată via Internet şi va oferi un set de funcţionalităţi care să răspundă următoarelor cerinţe:

Ø Aplicaţia trebuie să ofere o evidenţă clară a tuturor proiectelor implementate;

Ø Introducerea şi modificarea datelor referitoare la un proiect se poate face în mod restricţionat doar la nivel managerial;

Ø Aplicaţia trebuie să ofere o evidenţă clară a tuturor specialiştilor IT existenţi în departamentul de dezvoltare software pornind de la directorul tehnic până la toţi membrii practicilor existente;

Ø Introducerea şi modificarea datelor referitoare la specialiştii IT se poate face în mod restricţionat doar la nivel managerial;

Ø Desemnarea şefului de echipă a unui proiect este de asemenea restricţionată tot la nivel managerial;

Ø Asignarea specialiştilor IT ca şi membrii ai echipelor se poate face de către directorul tehnic, managerul de proiect sau şeful de echipă;

Ø Orice activitate nouă apărută după demararea proiectului poate fi auto-asignata de către un consultant o dată ce acesta este disponibil şi deţine cunoştinţele necesare să o rezolve;

Ø O dată asignată o activitate unui consultant aceasta este considerată a fi în lucru şi ca atare nu poate fi modificată decât de consultantul care trebuie să o rezolve sau de către şeful echipei tehnice a proiectului în cauză;

Ø În asignarea iniţială a consultanţilor la activităţile proiectului trebuie să se ţină seama de clauzele contractuale care desemnează activităţile de tip “Show Stopper”, care sunt posibile cauze de reziliere de contract (dacă nu sunt îndeplinite complet) sau aplicare de sancţiuni financiare (dacă nu sunt îndeplinite în perioada alocată, adică au întârzieri).

Ø Aplicaţia trebuie să ofere un set de rapoarte care să furnizeze o imagine de ansamblu atât asupra procesului de desfăşurare a proiectelor cât şi asupra aspectelor financiare implicate (venituri, comisioane);

Ø Aplicaţia trebuie să furnizeze informaţiile necesare managerilor şi şefilor de echipă în procesul de decidere a modului de asignare a acestora în diferite proiecte;

Ø Pentru a reduce din volumul de muncă al administratorilor de aplicaţie este nevoie şi de o modalitate de modificare a parolei proprii de către fiecare utilizator în parte;

Pentru a aprofunda analiza cerinţelor menţionate anterior se va utiliza setul de diagrame furnizat de limbajul de modelare UML.

3.1.1. Diagrama cazurilor de utilizare

Diagrama cazurilor de utilizare are scopul de a reprezenta grafic funcţionalităţile îndeplinite de sistemul informatic în faza sa finală.

Principalele cazuri de utilizare identificate sunt următoarele, după cum se poate observa în figura 3-1:

Ø Definire consultant - acest caz de utilizare se declanşează la angajarea unui nou consultant IT şi doar persoane de la nivelul managerial pot îndeplini această activitate.

Ø Deschidere proiect - are loc în momentul când este câştigată o licitaţie comercială şi doar persoane de la nivelul managerial pot îndeplini această activitate.

Ø Identificare activităţi - este echivalentă cu definirea unei activităţi noi aferente unui proiect existent; această activitate poate fi îndeplinită de manageri, şeful de echipă al respectivului proiect şi de oricare dintre membrii echipei proiectului.

Ø Asignare activităţi - acest caz de utilizare este declanşat de definirea unei noi activităţi pentru care nu a fost desemnat consultantul responsabil să o rezolve şi poate fi îndeplinit de şeful echipei proiectului în cauză sau de oricare dintre membrii acesteia.

Ø Desfăşurare activităţi - acest caz de utilizare reprezintă actualizarea unei activităţi existente cu informaţii referitoare la starea şi evoluţia rezolvării sale; această activitate poate fi înfăptuită doar de către consultantul asignat respectivei activităţi şi de către şeful de echipă al proiectului în cauză.

Ø Rezolvare activităţi - este cel mai frecvent mod de finalizare al unei activităţi însă nu este mereu obligatoriu deoarece se poate constata că activitatea în cauză nu poate fi finalizată din diverse motive şi ca atare activitatea este închisă fără a fi rezolvată.

Ø Închidere activitate - dacă o activitate se consideră a fi finalizată (are completată o dată de finalizare) aceasta este închisă în mod automat.

Ø Închidere proiect - acest caz de utilizare este declanşat doar dacă toate activităţile aferente proiectului în cauză sunt închise; doar persoane de la nivelul managerial pot îndeplini această activitate.

3.1.2. Diagrama de clase

Diagrama de clase descrie structura statică internă a sistemului atât prin intermediul claselor şi atributelor cât şi prin operaţiile aferente acestora şi prin descrierea relaţiilor dintre ele.

Precum se observă în figura 3-2 au fost identificate următoarele clase: People, Projects, Activities, Status şi Priorities împreună cu atributele şi operaţiile acestora.

Relaţiile dintre clase se descriu astfel:

Ø o persoana poate fi asignată unui proiect în sensul că face parte din echipa de specialişti a respectivului proiect;

Ø o persoana poate fi asignată unei activităţi sau mai multor activităţi din cadrul proiectului din echipa căruia face parte;

Ø o persoana identifică şi deschide o activitate sau mai multe în cadrul proiectului din echipa căruia face parte;

Ø o activitate sau mai multe se desfăşoară în cadrul unui proiect;

Ø o activitate poate avea un status;

Ø o activitate poate avea o prioritate anume.

3.1.3. Diagrama de activităţi

Diagramele de activităţi reprezintă stările de execuţie a unor mecanisme sub forma unor succesiuni de etape regrupate secvenţial în ramificaţii paralele de fire de execuţie. După cum se poate observa în figura x, operaţia de alocare a consultanţilor IT în cadrul echipelor de proiecte se poate modela cu ajutorul diagramei de activităţi astfel:

3.1.4. Diagrame de secvenţă şi de colaborare

Diagramele de secvenţă prezintă în mod grafic diversele interacţiunile care au loc între obiectele sistemului informatic, observate în ordine cronologică. Diagramele de colaborare prezintă în mod grafic aceleaşi interacţiuni însă organizate relativ, evidenţiind mai mult legăturile dintre acestea.

După cum se poate observa ambele tipuri de diagrame evidenţiază interacţiunile din sistem însă diagrama de secvenţă prezintă o viziune temporală pe când diagrama de colaborare prezintă o viziune spaţiala a acestora.

În cazul sistemului curent aceste interacţiuni se desfăşoară astfel:

Ø Diagramele de secvenţă şi de colaborare aferente cazului de utilizare Definire consultant pot fi observate în figurile x şi respectiv x. În aceste diagrame se evidenţiază faptul că un manager trebuie sa fie autentificat în aplicaţie pentru a putea înregistra un consultant nou în sistem

Ø Diagramele de secvenţă şi de colaborare asociate cazului de utilizare Definire proiect (figurile x şi respectiv x) evidenţiază faptul că un manager trebuie sa fie autentificat în aplicaţie pentru a putea defini un nou proiect.

Ø Diagramele de colaborare şi de secvenţă asociate cazului de utilizare Asignare activităţi pot fi observate în figurile x şi respectiv x. În aceste diagrame se evidenţiază următoarele interacţiuni:

o un şef de echipă trebuie să fie autentificat în aplicaţie pentru a putea aloca consultanţii IT echipelor de proiecte şi activităţilor din cadrul acestora;

o după accesarea interfeţei sistemului, şeful de echipă execută în mod repetat următorii paşi pentru fiecare viitor membru al echipei de proiect:

§ asignare proiect - consultantul IT este astfel înscris în echipa de proiect;

§ asignare rol - se stabileşte o ierarhie în cadrul echipei;

o De asemenea, tot în mod repetat execută următorii paşi dar pentru fiecare activitate din cadrul proiectului:

§ deschidere activitate - se defineşte activitatea curentă;

§ asignare activitate - astfel se alocă consultantul responsabil să o rezolve.

Ø Diagramele de secvenţă şi de colaborare asociate cazului de utilizare Definire proiect (figurile x şi respectiv x) evidenţiază faptul că un manager trebuie sa fie autentificat în aplicaţie pentru a putea defini un nou proiect.

3.1.5. Diagrama de stare

Diagramele de stări denumite şi diagrame de tranziţie a stărilor descriu comportamentul obiectelor aparţinând unei clase, în cazul de faţă este vorba despre clasa Activitate (ACTIVITIES) care are trei stări: deschisă, în lucru şi închisa, după cum se poate observa şi în figura x.

3.2. Proiectarea sistemului
3.2.1. Proiectarea componentelor sistemului

Diagrama de componente prezintă dependenţele statice sau dinamice existente între componentele software ce alcătuiesc sistemul informatic.

Sistemul conceput are ca principale componente:

• Schema bazei de date;

• Procedurile şi funcţiile responsabile de validări, de algorimii ce asigură eliminarea suprarezervării, eliminarea unor erori de actualizare;

• Interfaţa cu utilizatorul ce comunică cu celelalte două componente, formând aplicaţia de gestiune.

3.2.2. Schema conceptuală a bazei de date rezultată din diagrama claselor

Pentru a soluţiona problema managementului eficient la nivelul activităţii de consultanţă IT se foloseşte o bază de date Oracle 11g Enterprise Edition.

Acestă bază de date conţine sase tabele ce au rolul de a înregistra toate datele necesare referitoare atât la utilizatori, proiecte, specialisti IT, activitati, prioritati si statusuri.

Tabelele menţionate mai sus sunt următoarele:

Ø STATUS - reprezinta nomenclatorul de stari în care se poate regasi o activitate, respectiv deschisa, în lucru sau inchisa daca activitatea s-a terminat deja.

Ø PRIORITIES - reprezinta nomenclatorul de prioritati care pot fi asignate unei activitati la momentul crearii sale, respectiv scazuta, medie sau inalta. În cadrul proiectelor prioritatea inalta este asignata unei activitati de tip “show-stopper” sau critica. De exemplu, etapa de aplicare a politicilor de siguranta la un sistem de email care depaseste cuanta de timp admisa poate expune sistemul unor vulnerabilitati ce pot compromite confidentialitatea informatiilor. Aceste activitati trebuiesc terminate în anumite conditii de timp, altfel activitatea clientului poate fi prejudiciata şi ca atare depasirea datei tinta aduce cu sine o sanctiune financiara.

Ø PROJECTS - reprezinta nomenclatorul de proiecte contractate de companie ce ofera informatii despre data de inceput a unui proiect, data de finalizare planificata şi data de finalizare reala a proiectului.

Ø PEOPLE - reprezinta nomenclatorul de angajati ai companiei şi contine numele angajatilor, adresele de email ale acestora, functia pe care o ocupa, proiectul la care sunt asignati în momentul de fata precum şi comisionul procentual pe care l-au negociat la angajare.

Ø ACTIVITIES - reprezinta nomenclatorul de activitati desfasurate de angajatii companiei. Aceasta este tabela centrala de informatii ce contine activitatile proiectelor, proiectele din care acestea fac parte, specialistul care a sesizat activitatea (de obicei sefii de echipa sau managerii la momentul deciderii planului de proiect), consultantul care trebuie sa finalizeze activitatea, data de sesizare, data de rezolvare tinta cât şi cea reala, statusul şi prioritatea activitatii cât şi venitul pe care activitatea il aduce companiei(in mod normal se masoara în dolari/zi).

Ø APP_USERS - este utilizata pentru a se putea folosi o metoda de autentificare in aplicatie utilizand o combinatie utilizator/parola. Aceste credentiale nu au fost trecute in tabela PEOPLE pentru a se putea schimba rapid in aplicatie schema de autentificare daca acest lucru se doreste.

Modul în care se leagă tabelele prezentate anterior, este reprezentat în figura următoare:

3.3. Implementarea sistemului
3.3.1. Crearea obiectelor de la nivelul bazei de date

----------CREATING TABLES----------
--- Creating table PROJECTS
create table PROJECTS
(
PROJECT_ID INTEGER not null,
PROJECT_NAME VARCHAR2(100) not null,
START_DATE DATE not null,
TARGET_END_DATE DATE not null,
ACTUAL_END_DATE DATE
);
alter table PROJECTS add constraint PROJECTS_PK primary key (PROJECT_ID);
alter table PROJECTS add constraint PROJECTS_UK unique (PROJECT_NAME);

--- Creating table PEOPLE
create table PEOPLE
(
PERSON_ID INTEGER not null,
PERSON_NAME VARCHAR2(100) not null,
PERSON_EMAIL VARCHAR2(100) not null,
PERSON_ROLE VARCHAR2(20) not null,
ASSIGNED_PROJECT INTEGER,
COMISSION INTEGER
);
alter table PEOPLE add constraint PEOPLE_PK primary key (PERSON_ID);
alter table PEOPLE add constraint PEOPLE_UK unique (PERSON_NAME);
alter table PEOPLE add constraint
PEOPLE_PROJECT_FK foreign key (ASSIGNED_PROJECT)
references PROJECTS (PROJECT_ID);
alter table PEOPLE add constraint PEOPLE_ASSIGNMENT_CC
check ((person_role in ('Sef echipa','Membru echipa') and assigned_project is not null)
or (person_role in ('CEO','Manager') and assigned_project is null));
alter table PEOPLE add constraint PEOPLE_ROLE_CC
check (person_role in ('CEO','Manager','Sef echipa','Membru echipa'));

--- Creating table APP_USERS
create table APP_USERS
(
ID NUMBER not null,
USERNAME VARCHAR2(30) not null,
PASSWORD VARCHAR2(16) not null,
ACCESSLEVEL NUMBER not null,
PERSON_ID NUMBER
);
comment on column APP_USERS.ACCESSLEVEL is '1=ADMIN; 2=MANAGER; 3=USER';
alter table APP_USERS add constraint APP_USERS_PK primary key (ID);
alter table APP_USERS add constraint APP_USERS_UK unique (USERNAME);
alter table APP_USERS add constraint APP_USERS_PEOPLE_FK foreign key (PERSON_ID)
references PEOPLE (PERSON_ID);

--- Creating table PRIORITIES
create table PRIORITIES
(
PRIORITY_ID NUMBER not null,
PRIORITY VARCHAR2(200) not null
);
alter table PRIORITIES add constraint PRIORITIES_PK primary key (PRIORITY_ID);

--- Creating table STATUS
create table STATUS
(
STATUS_ID NUMBER not null,
STATUS VARCHAR2(100) not null
);
alter table STATUS add constraint STATUS_PK primary key (STATUS_ID);

--- Creating table ACTIVITIES
create table ACTIVITIES
(
ISSUE_ID INTEGER not null,
ISSUE_SUMMARY VARCHAR2(200) not null,
ISSUE_DESCRIPTION VARCHAR2(2000),
IDENTIFIED_BY INTEGER not null,
IDENTIFIED_DATE DATE not null,
RELATED_PROJECT INTEGER not null,
ASSIGNED_TO INTEGER,
TARGET_RESOLUTION_DATE DATE,
PROGRESS VARCHAR2(2000),
ACTUAL_RESOLUTION_DATE DATE,
RESOLUTION_SUMMARY VARCHAR2(2000),
CREATED_DATE DATE not null,
CREATED_BY VARCHAR2(60) not null,
LAST_MODIFIED_DATE DATE,
LAST_MODIFIED_BY VARCHAR2(60),
STATUS_ID INTEGER,
PRIORITY_ID INTEGER,
COST INTEGER
);
alter table ACTIVITIES add constraint ACTIVITIES_PK primary key (ISSUE_ID);
alter table ACTIVITIES
add constraint ACTIVITIES_ASSIGNED_TO_FK foreign key (ASSIGNED_TO)
references PEOPLE (PERSON_ID);
alter table ACTIVITIES
add constraint ACTIVITIES_IDENTIFIED_BY_FK foreign key (IDENTIFIED_BY)
references PEOPLE (PERSON_ID);
alter table ACTIVITIES
add constraint ACTIVITIES_PRIORITY_FK foreign key (PRIORITY_ID)
references PRIORITIES (PRIORITY_ID);
alter table ACTIVITIES
add constraint ACTIVITIES_PROJECT_FK foreign key (RELATED_PROJECT)
references PROJECTS (PROJECT_ID);
alter table ACTIVITIES
add constraint ACTIVITIES_STATUS_FK foreign key (STATUS_ID)
references STATUS (STATUS_ID);

----------CREATING SEAQUENCES----------
--- Creating sequence APP_USERS_SEQ
create sequence APP_USERS_SEQ
minvalue 1 maxvalue 9999999999999999999999999999
start with 1 increment by 1 nocache order;

--- Creating sequence ACTIVITIES_SEQ
create sequence ACTIVITIES_SEQ
minvalue 1 maxvalue 9999999999999999999999999999
start with 1 increment by 1 nocache order;

--- Creating sequence PEOPLE_SEQ
create sequence PEOPLE_SEQ
minvalue 1 maxvalue 9999999999999999999999999999
start with 1 increment by 1 nocache order;

--- Creating sequence PRIORITIES_SEQ
create sequence PRIORITIES_SEQ
minvalue 1 maxvalue 9999999999999999999999999999
start with 1 increment by 1 nocache order;

--- Creating sequence PROJECTS_SEQ
create sequence PROJECTS_SEQ
minvalue 1 maxvalue 9999999999999999999999999999
start with 1 increment by 1 nocache order;

--- Creating sequence STATUS_SEQ
create sequence STATUS_SEQ
minvalue 1 maxvalue 9999999999999999999999999999
start with 1 increment by 1 nocache order;

----------Creating package APP_USER_SECURITY for APEX authentication schema----------
CREATE OR REPLACE PACKAGE APP_USER_SECURITY AS

 

PROCEDURE LOGIN(P_UNAME IN VARCHAR2,
P_PASSWORD IN VARCHAR2,
P_SESSION_ID IN VARCHAR2,
P_FLOW_PAGE IN VARCHAR2);

FUNCTION VALID_USER(P_USERNAME IN VARCHAR2, P_PASSWORD IN VARCHAR2)
RETURN BOOLEAN;

PROCEDURE CHANGE_PASSWORD(P_USERNAME IN VARCHAR2,
P_OLD_PASSWORD IN VARCHAR2,
P_NEW_PASSWORD IN VARCHAR2);

FUNCTION GET_HASH(P_USERNAME IN VARCHAR2, P_PASSWORD IN VARCHAR2)
RETURN VARCHAR2;

END;
/

--- Creating package body APP_USER_SECURITY
CREATE OR REPLACE PACKAGE BODY APP_USER_SECURITY AS

FUNCTION GET_HASH(P_USERNAME IN VARCHAR2, P_PASSWORD IN VARCHAR2)
RETURN VARCHAR2 AS
BEGIN
RETURN DBMS_OBFUSCATION_TOOLKIT.MD5(INPUT_STRING => UPPER(TRIM(P_USERNAME)) || '/' || P_PASSWORD);
END;

PROCEDURE LOGIN(P_UNAME IN VARCHAR2,
P_PASSWORD IN VARCHAR2,
P_SESSION_ID IN VARCHAR2,
P_FLOW_PAGE IN VARCHAR2) IS
BEGIN
WWV_FLOW_CUSTOM_AUTH_STD.LOGIN(P_UNAME => UPPER(TRIM(P_UNAME)),
P_PASSWORD => P_PASSWORD,
P_SESSION_ID => P_SESSION_ID,
P_FLOW_PAGE => P_FLOW_PAGE || ':' || 1);
EXCEPTION
WHEN OTHERS THEN
RAISE;
END;

PROCEDURE CHANGE_PASSWORD(P_USERNAME IN VARCHAR2,
P_OLD_PASSWORD IN VARCHAR2,
P_NEW_PASSWORD IN VARCHAR2) AS
V_ROWID ROWID;
BEGIN
SELECT ROWID
INTO V_ROWID
FROM APP_USERS
WHERE USERNAME = UPPER(TRIM(P_USERNAME))
AND PASSWORD = GET_HASH(P_USERNAME, P_OLD_PASSWORD)
FOR UPDATE;

UPDATE APP_USERS SET PASSWORD = P_NEW_PASSWORD WHERE ROWID = V_ROWID;
COMMIT;

EXCEPTION
WHEN NO_DATA_FOUND THEN
RAISE_APPLICATION_ERROR(-20000, 'Utilizator inexistent.');
END;

FUNCTION VALID_USER(P_USERNAME IN VARCHAR2, P_PASSWORD IN VARCHAR2)
RETURN BOOLEAN AS
--INTOARCE FALSE DACA NU E USER VALID
--INTOARCE TRUE DACA E USER DIN TABELA
V_REZULTAT BOOLEAN;
V_TEMP NUMBER;
BEGIN
V_REZULTAT := FALSE;
V_TEMP := 0;
SELECT 1
INTO V_TEMP
FROM APP_USERS
WHERE USERNAME = UPPER(TRIM(P_USERNAME))
AND PASSWORD = GET_HASH(P_USERNAME, P_PASSWORD);
IF (V_TEMP = 0) THEN
V_REZULTAT := FALSE;
ELSE
V_REZULTAT := TRUE;
END IF;
RETURN V_REZULTAT;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RETURN FALSE;
END;

END;
/

----------CREATING TRIGGERS----------
--- Creating trigger APP_USERS_BI
create or replace trigger app_users_bi
before insert on app_users
for each row
begin
if (:new.id is null) then
for c1 in (select app_users_seq.nextval nv from dual) loop
:new.id := c1.nv;
end loop;
end if;
:new.password := app_user_security.get_hash(upper(trim(:new.username)), :new.password);
:new.username := upper(trim(:new.username));
end;

--- Creating trigger APP_USERS_BU
create or replace trigger app_users_bu
before update on app_users
for each row
begin
:new.password := app_user_security.get_hash(upper(trim(:new.username)), :new.password);
end;

--- Creating trigger BI_ACTIVITIES
create or replace trigger bi_activities
before insert on activities
for each row
begin
if (:new.issue_id is null) then
select activities_seq.nextval into :new.issue_id from dual;
end if;
if (:new.status_id is null) then
select t.status_id
into :new.status_id
from status t
where t.status = 'Deschis';
end if;
:new.created_date := sysdate;
:new.created_by := nvl(wwv_flow.g_user, user);
end;

--- Creating trigger BI_PEOPLE
create or replace trigger bi_people
before insert on people
for each row
begin
if (:new.person_id is null)
then select people_seq.nextval
into :new.person_id
from dual;
end if;
end;

--- Creating trigger AI_PEOPLE

create or replace trigger ai_people
after insert on people
for each row
begin
--Pentru fiecare angajat nou introducem si un user in tabela APP_USERS
insert into app_users
(username, password, accesslevel, person_id)
(select upper(replace(:new.person_name, ' ', '.')) username,
upper(replace(:new.person_name, ' ', '.')) password,
(case
when :new.person_role in ('CEO', 'Manager') then
2
else
3
end) accesslevel,
:new.person_id
from dual);
end;

--- Creating trigger BI_PRIORITIES
create or replace trigger bi_priorities
before insert on priorities
for each row
begin
if (:new.priority_id is null)
then select priorities_seq.nextval
into :new.priority_id
from dual;
end if;
end;

--- Creating trigger BI_PROJECTS
create or replace trigger bi_projects
before insert on projects
for each row
begin
if (:new.project_id is null)
then select projects_seq.nextval
into :new.project_id
from dual;
end if;
end;

--- Creating trigger BI_STATUS
create or replace trigger bi_status
before insert on status
for each row
begin
if (:new.status_id is null)
then select status_seq.nextval
into :new.status_id
from dual;
end if;
end;

--- Creating trigger BU_ACTIVITIES
create or replace trigger bu_activities
before update on activities
for each row
begin
if (:new.actual_resolution_date is not null) then
select t.status_id
into :new.status_id
from status t
where t.status = 'Inchis';
end if;
:new.last_modified_date := sysdate;
:new.last_modified_by := nvl(wwv_flow.g_user, user);
end;

3.3.2. Prezentarea rezultatului procesului de implementare

In abordarea practica sistemul informatic este compus dintr-o baza de date Oracle 11g Enterprise Edition in care sunt stocate toate datele inregistrate in aplicatie si o aplicatie web dezvoltata cu Oracle Application Express v3.2.

Ca şi organizare functionala aplicatia este organizata în doua parti: o parte tranzactionala prin intermediul careia se pot introduce şi actualiza datele în baza de date şi o parte de raportare prin intermediul careia se pot analiza aceste date (starea proiectelor, a activitatilor şi angajatilor) conform mai multor criterii.

Din punctul de vedere al “publicului tinta” aplicatia este organizata în trei module principale:

Ø un modul de operatii zilnice prin care sunt inregistrate proiectele, activitatile acestora şi evolutia finalizarii lor - destinat atat managerilor cât şi angajatilor;

Ø un modul de raportare orientat catre management care sa ofere în orice moment o imagine de ansamblu a desfasurarii proiectelor - destinat managerilor;

Ø un modul de raportare orientat catre angajat care ofera acestuia o imagine punctuala asupra propriei sale activitati - destinat fiecarui angajat în parte.

Pentru un acces mai usor la facilitatile aplicatiei organizarea paginilor web din cadrul acesteia s-a facut sub forma de tab-uri pe doua nivele. Astfel exista trei tab-uri parinte Operatiuni, Manager şi Angajat fiecare dintre acestea continand propriul subset de tab-uri.

Pentru a analiza functionalitatile aplicatiei se porneşte de la un caz real (o activitate ce trebuie asignata unui consultant) urmarind fluxul logic pe care un sef de echipa sau manager l-ar urma în vederea desemnarii unui specialist IT pentru rezolvarea respectivei activitati.

3.3.3. Modulul operational

Autentificarea în aplicatie se face în mod clasic cu nume_utilizator şi parola. O data accesata, aplicatia afiseaza pagina Home indiferent daca utilizatorul este manager sau sef de echipa sau doar membru de echipa. Aceasta pagina este o sinteza a celor mai utilizate rapoarte şi după cum se poate observa în imaginea urmatoare, în zona de “Activitati neasignate” apare o activitate cu deadline pe data de 25 Ianuarie care este sesizata la nivelul proiectului de “Implementare sistem nou de salarizare” chiar de catre sefa de echipa a proiectului Iulia Sandu.

După cum se poate observa şi în partea inferioara a paginii Home, toate activitatile reprezinta legaturi catre pagina de “Creare/Editare Activitate”.

Daca se acceseaza pagina de “Creare/Editare Activitate” se observa o multitudine de campuri ce pot fi completate sau modificate:

Ø Sumar: reprezinta zona textuala unde persoana care a sesizat activitatea scrie pe scurt o descriere succinta a problemei (camp obligatoriu);

Ø Descriere: se completeaza cu explicatii aditionale daca este necesar (camp optional);

Ø Identificata de: identifica seful de echipa sau managerul care a sesizat problema (camp obligatoriu);

Ø Data identificarii problemei (camp obligatoriu);

Ø Proiect: proiectul caruia ii este atasata activitatea curenta (camp obligatoriu);

Ø Asignata catre: consultantul insarcinat cu rezolvarea problemei(camp optional);

Ø Status: Deschis, Inchis sau În lucru (camp obligatoriu);

Ø Prioritate: Scazuta, Medie sau Inalta (camp optional);

Ø Data tinta rezolvare: cand s-a estimat ca se termina de rezolvat activitatea (camp optional);

Ø Evolutie: explicatii diverse legate de starea activitatii în ultimul moment al consemnarii acesteia;

Ø Data reala rezolvare: cand s-a terminat de rezolvat activitatea;

Ø Sumar rezolvare: explicatii diverse referitoare la metoda sau pasii de rezolvare.

Referitor la problema decizionala a asignarii noii activitati observata anterior, se verifica ce specialisti fac parte din echipa de lucru pentru a sti ce persoane pot fi teoretic insarcinate cu solutionarea respectivei activitati.

Consultand subtab-ul “Specialisti” din tabul “Operatiuni” se observa ca echipa proiectului “Implementare sistem nou de salarizare” este alcatuita din seful de echipa (Iulia Sandu) şi un membru de echipa (Monica Dinita).

După cum se observa în figura 6 ambele persoane sunt asignate unor activitati în lucru sau abia deschise la nivelul proiectului. Astfel, Monica Dinita are asignata o activitate cu prioritate medie ce trebuia finalizata pana pe data de 11 a lunii trecute iar Iulia Sandu are asignata o activitate abia deschisa cu prioritate inalta.

Deoarece noua activitate are o prioritate inalta, a carei solutionare intarziata poate aduce prejudicii financiare companiei de consultanta cât şi clientilor, se verifica daca specialista vizata are o viteza buna de lucru şi apoi istoricul de intarzieri. Acest lucru se poate face accesand tabul “Manager” şi apoi subtab-ul “Numar mediu zile activitati” sau direct din pagina Home din meniul de link-uri rapide din partea stanga a ecranului.

După cum se poate observa din figura urmatoare, Monica Dinita are o viteza medie de lucru.

Se trece la verificarea situatiei intarzierilor utilizand tab-ul “Manager” şi apoi subtab-ul “Situatie intarzieri”. După cum se observa consultantul vizat nu are un istoric de intarzieri, fapt care duce la concluzia ca în momentul de fata Monica Dinita este cea mai buna optiune pentru rezolvarea activitatii nou aparute.

Pentru a-i asigna noua activitate Monicai Dinita revenim la tab-ul “Operatiuni” şi apoi subtab-ul “Calendar” pentru a putea consulta imaginea de ansamblu a deadline-urilor lunii curente. După cum se poate observa din figura urmatoare activitatile neasignate sunt evidentiate cu rosu.

Se da click pe activitatea din data de 25 Ianuarie şi astfel se acceseaza în mod direct pagina “Asignare activitati” ce permite asignarea efectiva a activitatii. Pentru a salva schimbarile efectuate în aceasta pagina se da click pe butonul “Modificare”.

Pe langa paginile prezentate anterior, în cadrul modulului operational, mai exista inca doua pagini esentiale pentru desfasurarea activitatilor în cadrul companiei:

Ø pagina “Creare/Editare Specialisti” ce permite inregistrarea în baza de date a detaliilor specialistilor IT si,

Ø pagina “Proiecte” ce permite inregistrarea în baza de date a detaliilor legate de proiecte.

De mentionat este faptul ca aceste doua pagini au accesul restrictionat în functie de rolul utilizatorului sau angajatului care acceseaza aplicatia. Astfel, editarea datelor referitoare la proiecte o poate face doar un manager desi lista proiectelor este publica şi poate fi vizualizata de orice utilizator.

Spre diferenta de aceasta restrictie, editarea datelor unui angajat poate fi facuta doar de un alt angajat cu o functie minim pe acelasi nivel ierarhic sau superior. Acest lucru este posibil deoarece pot exista proiecte mixte intre echipe. De exemplu, un proiect de implementare a unui nou site în cadrul unei firme poate fuziona cu proiectul de integrare a sistemului de email în cadrul aceleasi firme desi, initial erau tratate ca doua proiecte diferite.

După cum se poate observa în figura urmatoare, utilizatorul GEORGE.BALAN care detine rolul de sef de echipa nu are drept de editare la nivel de proiect butonul “Edit” nefiind vizibil.

3.3.4. Modulul de raportare orientat catre management

Acest modul cuprinde un set de rapoarte menite sa poata furniza nivelului de management atat informatii în timp real cât şi informatii istorice cu privire la proiecte, activitati şi angajati, oferind astfel o imagine de ansamblu cuantificata din mai multe puncte de vedere.

Rapoartele din cadrul modulului reprezinta fiecare în parte un subtab din cadrul tab-ului parinte “Manager”:

Ø “Raport Activitati”: reprezinta un raport parametrizat care are ca scop furnizarea unor situatii sintetice precum data primei activitati deschise în cadrul proiectului selectat, data ultimei activitati finalizate din cadrul proiectului, contorizarea activitatilor pe status-uri şi prioritati precum şi o evidenta a asignarii activitatilor pe consultanti:

Ø “Situatie intarzieri”: prezentat şi în modulul anterior, acest raport ofera o imagine clara asupra intarzierilor aparute la anumite proiecte şi apoi grupate pe angajati. După cum se poate observa în imaginea urmatoare proiectul “Implementare modul operational site public” inregistreaza intarzieri medii:

Ø “Situatie venituri”: acest raport ofera o imagine de ansamblu asupra veniturilor ce urmeaza a fi incasate de catre companie la finalizarea proiectelor. Situatia este prezentata atat ca grupare pe angajat cât şi pe proiect:

3.3.5. Modulul de raportare orientat catre angajat

Spre diferenta de modulul de raportare orientat spre management care era axat pe situatii grupate pe angajat sau proiect, modulul de raportare destinat angajatului ofera informatii utile consultantilor adica la nivel de proiect sau activitate.

Cele doua puncte de interes ale unui angajat au fost identificate ca fiind comisioanele şi intarzierile. Rapoartele din cadrul modulului reprezinta fiecare în parte un subtab din cadrul tab-ului parinte “Angajat”:

Ø “Situatie comisioane”: acest raport ofera o imagine clara asupra comisioanelor angajatului care a accesat aplicatia. Comisioanele sunt fie grupate pe proiecte fie direct listate pe activitati:

Ø “Situatie intarzieri”: acest raport ofera o imagine clara asupra intarzierilor angajatului care a accesat aplicatia. Intarzierile sunt fie grupate ca durata în zile pe proiecte fie direct listate pe activitati:

Concluzii

Utilizarea aplicatiei web în desfasurarea activitatii de planificare a resurselor umane eficientizeaza procesul de adoptare al deciziilor oferind un suport informational în mod structurat.

Astfel, alocarea unui consultant IT la o activitate în cadrul unui proiect poate fi facuta în mod optim, printr-o decizie corecta ce tine cont de eficienta de lucru şi experienta specialistului IT, asa cum bine evidentiaza aplicatia web ce sta la baza desfasurarii intregii activitati de consultanta a companiei.

Aceasta aplicatie, prin multitudinea informatiilor raportate, ofera posibilitatea de a identifica pe termen lung şi alti factori de risc necuantificati în prezent precum factorul uman sau specificul unui proiect.

Cu toate acestea doar o cunoastere indeaproape a competentelor consultantilor şi a specificului fiecarui proiect poate duce la o decizie echilibrata în formarea echipelor de proiecte.

--TODO: work in progress…

Bibliografie

[LUNG05] I. Lungu, Baze De Date Oracle Limbajul Sql, Ed. ASE, 2005.

[LUSA03] I. Lungu, Gh. Sabău, M. Velicanu ş.a., Sisteme informatice: analiză, proiectare şi implementare, Ed. Economică, 2003.

[MANU01] ***, Manualul noului angajat - documentaţia interna a firmei Software Development & Consulting.

[PROC01] ***, Proceduri de lucru din cadrul departamentului de dezvoltare software a firmei Software Development & Consulting.

[ROF001] ***, Regulamentul de organizare si functionare al firmei Software Development & Consulting.

[SUCI09] D. Suciu, Analiza şi gestiunea sistemelor informatice complexe, 2009:

http://cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/

[VELU03] M. Velicanu, I. Lungu, M. Munteanu ş.a., Sisteme de baze de date: teorie şi practică, Ed. Petrion, 2003.

[VELU09] M. Velicanu, I. Lungu, I. Botha ş.a., Sisteme de baze de date evoluate, Ed. ASE, 2009.

[Web001] ***, Oracle APEX - prezentare generală:

http://www.oracle.com/technology/products/database/application_express/index.html

[Web002] ***, Application Express Developer's Guide - Part Number E13367-02:

http://download.oracle.com/docs/cd/E14373_01/appdev.32/e13367/intro_app.htm#BCEDHHHG

[Web003] ***, Gartner Says Worldwide Relational Database Market Increased:

http://www.gartner.com/it/page.jsp?id=507466


More from UK Essays

Paid Writing Services

Free Content

About UK Essays

Order Now

Instant Price