Universitatea de Stat din Moldova Facultatea de Matematic i Informatic Catedra Tehnologii de Programare

Tez de Master
Sistem informatic pentru gestionarea managementul proiectelor

A efectuat masterandul anului II, specialitatea Informatic Ciobanu Igor

Conductorul, doctor confereniar Catedra Tehnologii de Programare Cpn Gheorghe

Chiinu 2012

INTRODUCERE
Orice ntreprindere, companie, organizaie i are organizat structura sa proprie de funcionare, n raport cu genul de activitate pe care l duce si nu n ultimul rnd cu legislaia n vigoare. Aceast structur este multidimensional i poate fi mprit n mai multe substructuri interdependente, care pot fi privite ca structuri distincte: structura de servicii i de personal, structura de management, marketing, financiar, economic, structura de informaii. Toate acestea sunt n strns colaborare i creeaz o structur organizatoric unic, caracteristic fiecrei ntreprinderi n parte. Cu toate acestea fiecare din aceste ntreprinderi, n dependen de structura sa organizatoric i de activitatea lor, folosesc sau dac nc nu folosesc atunci cu siguran vor folosi n timpul apropiat un sistem informatic sau un produs software specific, elaborat n scopul creterii productivitii i automatizrii unor procese care ar simplifica i mbunti mult munca personalului i ar spori venitul financiar al ntreprinderii, ceia ce este unul din cele mai importante scopuri a fiecrei ntreprinderi. Astzi, aflndu-ne ntr-o epoc n care mainile de calcul i tehnologiile informaionale ajungnd la un nivel nalt de dezvoltare, ne permit elaborarea acestor sisteme, mai complexe i mai performante, care sunt nite utiliti de nenlocuit n majoritatea ntreprinderilor, deoarce existena unui sistem automat, unui produs software, simplific foarte mult procesul de gestionare a ntreprinderii. n scopul realizrii prezentei lucrri au fost studiate cum decurce procesul de lucru n firmele IT. Rezultatele acestor studii au constituit punctul de plecare

pentru elaborarea sistemului informatic i sunt reflectate n cadrul tezei care const din Introducere, trei capitole principale i concluzii. //to do Cel de-al teilea capitol ntitulat Sisteme informatice i metode de dezvoltare ale acestora, prezint descrierea teoriei elaborrii sistemelor informatice i expunerea etapelor de dezvoltare a acestora. Tot aici sunt descrise tehnologiile i mijloacele instrumentale utilizate n dezvoltarea sistemului elaborat n lucrarea dat. Al treilea capitol Proiectarea i dezvoltararea sistemului pentru gestionarea managementul proiectelor nsumeaz rezultatele cercetrilor expuse n primele dou capitole i descrie etapele de proiectare i dezvoltare a Sistemului Informatic Managerial, destinat evidenei si monitorizrii proiectelor, automatiznd i simplificnd interaciunea dintre angajai si clieni, care va fi utilizat nemijlocit n activitatea de zi cu zi de lucrtori ct i de clieni, unde clienii vor putea vedea cum decurge dezvoltarea proiectului, iar lucrtorii task-urile care le are zi de zi i comunicarea dintre developeri, testeri, project manageri i ali lucratori ai firmelor.

CAPITOLUL I. CONCEPTUL DE MANAGEMENT

1.1. APARIIA CONCEPTULUI DE MANAGEMENT Dezvoltarea i cristalizarea n timp a ceea ce numim astzi management i are rdcinile n secolele XV-XVI, dar marea majoritate a specialitilor din domeniu situeaz individualizarea managementului n jurul anului 1900. Astfel, la nceputul secolului XX, dou personaliti de seam, una de origine francez Henry Fayol i cealalt de origine american Frederick Taylor, recunoscut ca printele managementului tiinific, au pus bazele managementului, prin iniierea unor studii de amploare n ntreprinderile industriale, cei doi criticnd simultan metodele tradiionale de organizare a produciei industriale i propunnd noi metode/principii de organizare i administrare a unei afaceri. Pentru prima dat n 1911, odat cu publicarea The Principles of Scientific Management a lui Taylor i Administration Industrielle et Generale a lui Fayol n 1915 apare acea explozie a interesului pentru managementul ca practic, ca activitate, aceast dat fiind considerat punctul de nceput n recunoaterea managementului ca domeniu de informare i instruire scolastic. Iniierea managementului tiinific la nceputul secolului XX a constituit un eveniment revoluionar care a contribuit la raionalizarea muncii i reducerea pierderilor. Considerat de marea majoritate a specialitilor drept printele managementului tiinific, Frederick Taylor i -a bazat ntreaga concepie pe ideea c munca oamenilor se poate raionaliza. Aceast concepie a maximei prosperiti este privit, mai ales, din punctul de vedere al ntreprinztorului i este ridicat de Taylor la rangul de principal obiectiv al managementului.

Taylorismul apare astfel ca o concepie organizaional-tehnicist, n care locul principal este ocupat de o serie de idei, cum ar fi: imaginea clar despre fiecare element, crearea unui fundament tiinific care s nlocuiasc metodele vechi de munc, studierea tiinific a fiecrui element, alegerea celor mai potrivii muncitori pentru fiecare operaie, dezvoltarea colaborrii ntre administraie i muncitori, folosirea specialitilor etc, n vreme ce elementul uman este plasat pe un loc secundar. Un pas nainte n dezvoltarea i fundamentarea managementului tiinific l-a fcut Henri Fayol realiznd saltul de la nivelul locului de munc la nivelul ntreprinderii n ansamblul ei, reuind astfel s lrgeasc coninutul i sfera conceptului de management. Abordarea i definirea funciilor ntreprinderii i a managementului ei, precum i considerarea ntreprinderii ca organism de sine stttor, dar aflat n legtur cu alte organisme asemntoare, i confer concepiei lui Fayol un fundament tiinific i meritul cel mai mare. Taylor i Fayol au jalonat trsturile de baz ale conceptului de management tiinific, acordnd o atenie mai mare elementului tehnic i organizatoric, n vreme ce factorul om este complet neglijat. De multe ori, managementul clasic a fost criticat pentru tratarea simplist i unilateral a fiinei umane angajat n organizaii. Unii specialiti consider c soluiile date managementului de ctre Taylor i Fayol au fost valabile pentru condiiile de la nceputul secolului i n-ar mai corespunde organizaiilor de astzi. Ali specialiti sunt convini c opera lui Taylor este insuficient neleas i criticat pe nedrept, el cutnd s uureze munca oamenilor, mbuntind condiiile de munc, reducnd oboseala, reproiectnd mainile spre a le adapta mai bine la om. Att managementul tiinific, iniiat de Taylor, ct i teoria clasic a organizrii de ansamblu a firmelor, creat de Fayol, au avut succesori. Astfel, managementul tiinific s-a bucurat de contribuiile remarcabile ale soilor Frank Gilbreth (1868-1924) i Lillian Gilbreth (1878-1972) i a lui Henry L. Gantt (18611919). Soii Gilbreth, inspirai de analizele tayloriene asupra normelor de timp ale

operaiilor tehnologice practicate n atelierele de prelucrri, dornici s contribuie la amplificarea potenialului uman, au transformat aceste analize n aplicaii tiinifice exacte, de msurare a aciunilor elementare din procesul muncii. Henry L. Gantt a fost un inginer ca i Taylor, colabornd cu acesta din urm, care i-a propus s mbunteasc eficiena muncii prin cercetare tiinific. A dezvoltat sistemul de salarizare n acord, propus de Taylor, printr-un sistem mai stimulativ care combina aa-numitul salariu zilnic garantat (un salariu zilnic minim) cu bonificaii pentru depirile de norm. Spre a putea efectua msurtori asupra gradului ndeplinirii sarcinilor, a iniiat introducerea n practica de atelier a graficelor liniare de activitate, prin care se pot reda att sarcina programat conform normelor, ct i gradul de realizare efectiv (graficele Gantt). Max Weber, un teoretician german, a introdus conceptul de organizaie birocratic, propunnd un sistem de conducere impersonal, bazat pe autoritate raional, cu compartimente i birouri care s constituie o structur formal capabil de continuitate, indiferent dac managerii individuali triesc sau mor, lucreaz n cadrul firmei sau pleac. n schimb, Henry Mintzberg a avut preocupri majore legate de domeniile care vizeaz strategia produciei, a utilizrii timpului de munc a managerilor i a determinrii de ctre firm a propriilor nevoi. Avntul nentrerupt al tehnicii i tehnologiei, precum i aplicarea frecvent n producie a cuceririlor tiinei au impulsionat dezvoltarea managementului prin apariia unor noi concepte. n acest sens, un element important de care se leag transformarea amintit l constituie nceperea studierii i lurii n considerare a factorului uman, a relaiilor i comportamentului uman n producie fapt ce a dus la schimbarea concepiilor tradiionale referitoare la management (Cornescu et al., 2003). Cercetrile ntreprinse de grupul lui Mayo au nsemnat un pas nainte n evoluia conceptului de management marcnd nceputul utilizrii unor concepte i metode sociologice i psihologice, cum ar fi: sistemul de valori, comportamentul individual i organizaional, aptitudini, leadership,

motivaie etc. Att Mayo, ct i precursorii lui, H.J. Leavit, A. Maslow, F. Herzberg, Douglas Mc. Gregor, Wiliam Ouchi i alii acord o atenie mare individului, grupelor de munc i relaiilor care se stabilesc ntre indivizi i grupele de munc din care fac parte. Ei au pus n viden faptul c, pe lng organizaia formal, n cadrul ntreprinderilor se constituie i exist i organizaii informale care au un rol deosebit n formarea climatului de munc. Noutatea const n faptul c se realizeaz unitatea dintre factorii tehnici i cei umani i se mbogete paleta de metode i tehnici utilizate de management pentru realizarea obiectivelor propuse cu maximum de eficien. n ceea ce privete managementul modern, acesta implic un mare numr de abiliti i orientri, dintre care multe presupun abiliti legate de statistic, utilizarea tehnologiei informaiei, contabilitate i matematic. De asemenea, managementul pune accent pe rezolvarea raional a problemelor i pe gndirea logic, pe folosirea unor metode matematice moderne n procesul de conducere, pe utilizarea unor instrumente ce au revoluionat munca managerilor i orientarea companiilor n afaceri, cum ar fi computerul, internetul, inteligena artificial etc. Toate acestea mbogesc managementul tiinific i l menin n pas cu schimbrile care se produc n viaa ntreprinderilor, innd cont i de sarcinile pe care le impune progresul social si economic. Concluzionnd, tiina i practica managementului au cunoscut i cunosc, n secolul XX i la nceputul secolului XXI, o evoluie spectaculoas cu un impact deosebit n viaa tuturor tipurilor de organizaii. Diversitatea abordrilor teoretice i pragmatice pun n eviden micarea de idei n acest domeniu, precum i struina specialitilor de a concepe sisteme de onducere care s fie accesibile i eficiente 1.2. DEFINIII I ACCEPIUNI ALE TERMENULUI DE MANAGEMENT Definirea i explicarea termenului de management a preocupat o multitudine de specialiti, astfel nct literatura de specialitate a ncercat s-i

clarifice coninutul. Conceptul de management are semnificaii multiple i se folosete mult n teorie i n practic. Esenialul n analiza i tratarea acestui concept l constituie determinarea coninutului, a elementelor i direciilor care-i stabilesc trsturile. Dat fiind caracterul complex al managementului, au aprut numeroase i variate definiii ale acestui concept. O prim definiie consider c managementul este un proces de proiectare i meninere a unui climat n care indivizii, muncind mpreun n colectiv, realizeaz eficient scopurile stabilite" (Koontz et al., 1984). Din aceast definiie se desprind o serie de idei cum ar fi: -managementul se aplic la toate tipurile de organizaii i la toate nivelurile ierarhice; - ca manageri, cei stabilii cu astfel de atribuii, ndeplinesc funcii de conducere; - scopul principal al managementului este de a crea condiiile necesare realizrii de ctre mai muli indivizi a obiectivelor propuse, a unor eluri, ale unei structuri, ceea ce nseamn eficien; - managementul are un pronunat caracter pragmatic, faptic, real, impunnd aciunile de succes i justificnd nemplinirile n plan social. O definiie clar i sintetic a managementului o ofer M. Dumitrescu, artnd c acesta reprezint tiina prin care se asigur conducerea tuturor proceselor i unitilor economice i din celelalte sectoare de activitate, n toate funciunile acestora, avnd n prim plan omul, participarea motivat a acestuia i care presupune rezolvarea problemelor sub raport previzional, organizatoric, de conducere, de luare a deciziilor i control, cu concretizarea acestora n creterea eficienei economice (Niculescu&Dumitrescu, 2001). Dintre definiiile clasice, formulate de specialitii din domeniul managementului, le vom avea n vedere pe urmtoarele:

- Frederick W. Taylor definea managementul, n cartea sa Shop Management, publicat n 1903, astfel: a ti exact ce doresc s fac oamenii i a-i supraveghea ca ei s realizeze aceasta pe calea cea mai bun i mai ieftin; - Henri Fayol, n lucrarea sa Administration industrielle et gnrale, publicat n 1915, meniona c a administra nseamn a prevedea, a organiza, a comanda, a coordona i a controla; - Potrivit opiniei lui A. Mackensie, exprimat n noiembrie 1969 n Harvard Business Review, managementul este procesul n care managerul operez cu trei elemente fundamantale idei, lucruri i oameni realiznd prin alii obiectivele propuse; Dintre multiplele accepiuni i definiii date de ctre diveri specialiti romni termenului de management, vom prezenta n cele ce urmeaz doar cteva: - Managementul poate fi definit ca un proces de orientare a activitii oamenilor n scopul realizrii unor obiective (Lazr, 2004). - Conform lui Constantin Opran managementul este tiina i arta organizrii i conducerii unei activiti sau organizaii (Opran et al., 2002). - n accepiunea lui Ovidiu Nicolescu i a lui Ion Verboncu managementul firmelor rezid n studierea proceselor i relaiilor de management din cadrul lor, n vederea descoperirii legitilor i principiilor care le guverneaz i a conceperii de noi sisteme, metode, tehnici i modaliti de conducere, de natur s asigure obinerea i creterea competitivitii (Nicolescu&Verboncu, 1999). n concluzie, managementul reprezint ansamblul activitilor, disciplinelor, metodelor, tehnicilor care nglobeaz sarcinile conducerii, gestiunii, administrrii i organizrii companiei/organizaiei/instituiei i vizeaz ca, prin adoptarea deciziilor optime n proiectarea i reglarea proceselor microeconomice s antreneze ntregul personal pentru a ntreprinde i a lucra ct mai profitabil, pentru a organiza

schimbri capabile s asigure unitii un viitor trainic i eficace pe plan economic i social. Dei au fost date i, probabil, se vor mai da multe definiii managementului, n ceea ce ne privete considerm c managementul poate fi definit ca procesul de atingere a obiectivelor unei colectiviti umane organizate (ntreprinderi economice, instituii publice, organizaii non-profit) n condiiile utilizrii optime i eficiente a resurselor materiale, umane i financiare.

CAPITOLUL II.
CONCEPTUL DE PROIECT

Cuvntul proiect provine din latinescul projectum al verbului proicere (a arunca ceva nainte) format din prefixul pro-(care indic ceva ce precede aciunea urmtoare a cuvntului n timp) i rdcina iacere (a arunca). Rdcina latin sugereaz micarea, o traiectorie, o anume relaie cu spaiul i timpul. Procesul implicat presupune un punct de plecare folosit ca o baz, de unde cineva se arunc nainte, ctre un scop. Istoric vorbind, cuvntul i conceptul au fost folosite prima dat de arhiteci. n secolul al XV-lea, Filippo Brunelleschi a primit sarcina desvririi catedralei din Florena prin adugarea unui dom. nainte s nceap, el a elaborat o schi (progetto sau plan) a domului, folosind diverse perspective pentru a oferi o reprezentare geometric a viitoarei structuri.

2.1. CARACTERISTICILE PROIECTELOR Din definiiile proiectelor menionate mai sus, reies o serie de caracteristici care sedefinesc i se adapteaz progresiv pe parcursul desfurrii proiectului. Aceste caracteristici se regsesc, ntr-o msur mai mare sau mai mic, n fiecare dintre proiecte, indiferent de mrimea lor i se concretizeaz n urmtoarele elemente fundamentale: - Unicitatea rezultatului - n primul rnd, caracterul de noutate al rezultatului produs implic un anumit grad de necunoscut, caracteristic pentru orice lucru care nu s-a mai fcut nainte; - Durata finit - deoarece proiectele au date clare de nceput i de sfrit, anumite elemente organizatorice capt un caracter temporar, fiind croite special pentru a ndeplini obiectivele specifice ale proiectului. De exemplu, echipa de lucru este constituit doar pe durata proiectului, iar bugetul de resurse i responsabilitile manageriale sunt angajate strict n raport cu obiectivele proiectului; -Mrimea proiectului reprezint msura costurilor unui proiect. Aceasta este un indicator pe baza cruia se poate aprecia utilitatea folosirii managementului proiectului. Aceast caracteristic mai are n vedere i componenta temporal, n sensul necesarului de resurse financiare sau umane pe toat perioada de derulare a proiectului; - Gradul de inovare i complexitatea proiectelor depind de o serie de criterii, cum ar fi: caracterul de noutate al proiectului, mrimea proiectului, implicaiile sociale, riscul n atingerea obiectivului proiectului etc. Un proiect rmne complex chiar dac unul sau mai multe criterii au valoare sczut, atta timp ct altele au valoare ridicat. Cu ct complexitatea proiectului este mai mare, cu att trebuie investit mai mult n activitatea de management al proiectului, ridicnd astfel costurile acestuia.

O cunoatere a acestor caracteristici este deosebit de important, deoarece permite o abordare difereniat a proiectelor, conducnd astfel la un mod de organizare diferit, la o stabilire judicioas a obiectivelor, la alegerea optim a resurselor materiale i umane din cadrul proiectului n funcie de specificitatea sa.

2.2. TIPURI DE PROIECTE Unii spun c orice munc este un proiect. Exist dou tipuri de munc: munca de rutin i munca de proiect. Munca de rutin const din lucrurile pe care le efectuezi ca parte continu a muncii tale. Pe de alt parte proiectele nu constituie o rutin. Diferena cea mai mare o constituie faptul ca proiectele, prin definiie, au un punct de nceput i de sfrit bine determinate. Exist un moment n timp cnd proiectul nu a existat (nainte de proiect), cnd exist (proiectul), i cnd nu mai exist (dup proiect). Acetia sunt factorii pe baza crora se determin dac o munc este sau nu una de proiect. Exist o foarte mare varietate de proiecte. Orice ncercare de epuizare a subiectului va avea ntotdeauna dezavantajul limitrii. O prim clasificare a proiectelor ia n considerare o serie de caracteristici ale lor cum ar fi amploarea, domeniul de activitate i mrimea lor (Scarlat&Galoiu, 2002): 1. Dup amploarea lor: - organizaionale; - locale (localitate, jude, grup de judee); - naionale; - regionale (proiectul este de interes pentru mai multe judee din regiunea geografic respectiv); - internaional. 2. Dup domeniul obiectivului i activitilor proiectului: - proiecte industriale; - proiecte sociale;

- proiecte comerciale; - proiecte culturale; - proiecte de protecie a mediului; - proiecte tiinifice (de cercetare); - proiecte educaionale; - proiecte de management. 3. Dup mrimea lor: - proiecte mici: acest tip de proiecte au termene de maxim un an, au valori reduse, permit angajrile parttime, au cerine tehnologice modeste i permit o urmrire direct zilnic; - proiecte medii: au termene cuprinse ntre doi i trei ani, cu valori medii, n care sunt permise att angajrile part-time, ct i full-time, au cerine tehnologice medii, iar urmrirea lor se realizeaz prin raportri periodice; - proiecte mari: au termene lungi, mai mult de trei-cinci ani, au o valoare ridicat i permit numai angajri full-time, au cerine tehnologice performante, apeleaz la instrumente i programe specifice, iar urmrirea lor se realizeaz prin raportri de control; O alt tipologie a proiectelor poate fi conceput pornind de la dou elemente: tipul de produs (tangibil, entitate fizic, i intangibil, cu valoare abstract, intelectual) i tipul de activitate (fizic sau intelectual). Prin combinarea acestor criterii se pot obine patru tipuri de proiecte (Wideman, 1998): 1. Produs tangibil i munc fizic (exemplul standard fiind dat de proiectele de construcii). Astfel de proiecte prezint urmtoarele caracteristici: - activitile presupuse de proiect sunt n mare aceleai, eforturile sunt repetate;

- sursele de variaie sunt reduse; - resursele sunt previzibile; - costurile implicate sunt relativ mari; 2. Produs intangibil i munc fizic (exemplu standard: revizuirea unor politici sau proceduri). Caracteristicile de baz ale acestui tip de proiect sunt: - se bazeaz pe un model anterior; - modelului anterior i se aduc doar modificri, corecii sau mbuntiri; - resursele sunt previzibile; - costurile sunt relativ mici, necesare doar pentru a opera aceste modificri i pentru a multiplica noul produs; 3. Produs tangibil i munc intelectual (exemplu standard: proiecte de dezvoltare a unor noi produse, proiecte de investiii). Ca i caracteristici pot fi menionate: - nu se bazeaz pe un model sau pe un lucru deja existent; - eforturile nu se repet, abordrile sunt multiple; - resursele nu sunt att de previzibile, nu pot fi anticipate n mod riguros; - costurile variaz; 4. Produs intangibil i munc intelectual (exemplu standard: proiecte de cercetare i dezvoltare). Aceste proiecte: - presupun munc de creaie i inovaie; - eforturile nu sunt standardizate de la o etap la alta a proiectului, ci difer considerabil; - presupun munc de explorare; - nu se bazeaz pe ceva existent; - resursele utilizate sunt imprevizibile;

- costurile sunt imprevizibile i, de obicei, mari; S-a pus accentul pe prezentarea acestei tipologii pentru a se evidenia n primul rnd faptul c, de la proiectele de tip unu i pn la cele de tip patru riscurile cunosc o cretere considerabil, dar la fel crete i numrul posibilitilor, al oportunitilor care pot fi exploatate pentru a obine rezultate ct mai performante. De altfel, ncadrarea proiectului ntr-una din aceste categorii uureaz munca de planificare i cea de execuie. Odat stabilit ncadrarea, se pot realiza urmtoarele lucruri n funcie de caracteristicile dominante ale proiectului: - o planificare adecvat a activitilor; - o alocare a resurselor ct mai judicioas (n cazul unui proiect de tip patru analiza i managementul riscului comport o cu totul alt proeminen dect n cazul unui proiect de revizuire a unor politici, prin urmare resursele de timp, de bani i umane alocate n aceast direcie difer); Gradul de complexitate a unui proiect este dat de numrul sarcinilor presupuse a fi ndeplinite, de numrul i intensitatea constrngerilor care apar pe parcursul desfurrii sale. Teoreticianul Dennis Lock clasific proiectele n patru mari categorii (Lock, 2000): - proiecte de construcii, petrochimice, miniere, extractive acest tip de proiecte sunt dintre cele cunoscute, cu un grad mare de vizibilitate. Ele implic riscuri i probleme speciale de organizare i comunicare, necesit adesea investiii masive de capital i un management riguros al activitilor, resurselor i al calitii. - proiecte industriale au ca scop producerea de echipamente i utilaje specializate, produsul finit fiind construit special pentru un anumit client. De regul acest tip de proiecte se desfoar ntr-una din fabricile companiei

ceea ce permite exercitarea activitii de management direct la faa locului i crearea unui mediu propice de lucru. - proiecte de management aceste proiecte au n vedere managementul i coordonarea activitilor necesare pentru realizarea unui produs finit care difer n principiu de produsele industriale sau de construcii. - proiecte de cercetare presupun cel mai mare grad de risc, obiectivele lor finale sunt, de obicei, dificil sau imposibil de definit i pot s nu se preteze la metodele de management de proiect aplicabile n cazul proiectelor industriale sau de management. O alt clasificare a proiectelor are n vedere mprirea lor n trei mari grupe (Mocanu&Schuster, 2004): - proiecte de investiii (construcia unei cldiri noi, restaurarea unui monument istoric, retehnologizarea unei bnci), - proiecte de cercetare i dezvoltare (dezvoltarea unui produs nou, a unei noi tehnologii, elaborarea unui nou software), - proiecte de organizare (introducerea unui nou concept de marketing, introducerea managementului proiectelor ca form alternativ de conducere, lrgirea segmentului de pia). n literatura de specialitate exist o multitudine de abordri cu privire la tipologia proiectelor, unele dintre ele pun accentul pe amploarea i domeniul de activitate al proiectului, altele au n vedere tipul de produs care rezult n urma muncii de proiect i gradul de complexitate, n vreme ce o serie de proiecte in cont de domeniul n care se deruleaz, de durata finanrii i de sursa de provenien a banilor. Toate proiectele, indiferent de tiparul n care sunt ncadrate, depind de o multitudine de factori (durata definirii proiectului i costurile aferente, volumul informaiilor i gradul lor de detaliere, timpul necesar pentru documentare, gradul de implicare i specializare a echipei i a managerului de proiect) care, pn la urm, conduc la reuita unui proiect

2.3 PROIECT VS. PROGRAM Din punct de vedere teoretic, exist o distincie ntre noiunile de proiect i program (Chase et al., 2000), dei de cele mai multe ori acestea se folosesc cu nelesuri echivalente. n managementul proiectelor un program include mai multe proiecte, iar un proiect se poate descompune mai departe n subproiecte, grupuri de activiti i aciuni pentru a putea fi mai uor administrate. Subproiectele sunt, de multe ori, subcontractate ctre teri, fie c este vorba despre o entitate exterioar instituiei/organizaiei sau despre un departament al instituiei/organizaiei respective care iniial nu era planificat s participe la proiect. Programele, ca i proiectele, au o conducere clar definit. Exist mai nti un director/manager de program/proiect (Project Director, Project Manager, Project Coordinator, Team Leader), care coordoneaz o echip, complexitatea proiectului impunnd participarea a mai mult de o singur persoan. Pe de alt parte, din multe puncte de vedere diferenele dintre programe i proiecte sunt notabile. Potrivit lui Stanley E. Portny programul reprezint un efort de atingere a unui obiectiv strategic de anvergur, cu raz lung de aciune (Portny, 2001). Spre deosebire de proiect, programul nu i atinge niciodat n ntregime obiec tivele, iar pentru atingerea unui obiectiv complex al unui program pot fi derulate mai multe proiecte, fiecare producnd un rezultat de sine stttor. O alt definiie a programului are n vedere faptul c acesta reprezint un ciclu sau un set de activiti care sunt planificate i controlate, n general fr un termen de ncheiere precis delimitat, cu un aspect dinamic, care constituie o abordare integrat pentru ndeplinirea misiunii i obiectivelor unei instituii/organizaii (Project Management Manual, 1998). Pe de alt parte, programul mai este privit ca un grup de proiecte interdependente administrate n mod coordonat/concertat pentru a obine rezultate

care nu ar fi posibile prin derularea de sine stttoare a fiecrui proiect n parte. Spre deosebire de proiect, un program: - vizeaz mai multe schimbri concomitente sau succesive; - nu este n mod obligatoriu delimitat precis n timp; - are o durat n general mai mare; - un program poate include unul sau mai multe proiecte. Trebuie avut n vedere i faptul c programul reprezint un efort de atingere a unui obiectiv strategic de anvergur, cu raz lung de aciune. Organizaiile pot avea programe n cadrul crora, aa cum am vzut mai sus, deruleaz mai multe proiecte. Modalitatea n care sunt gestionate programele fiind, de fapt, cea a proiectelor fiecare proiect va avea un manager de proiect, o echip, resurse limitate etc., cu alte cuvinte absolut toate caracteristicile unui proiect, diferena fiind c un program cuprinde mai multe proiecte. n ceea ce ne privete, putem defini programul ca fiind un grup de proiecte conduse coordonat, pentru a obine beneficii ce nu ar rezulta dac ele ar fi conduse separat, avnd un cadru instituional care sprijin proiectele ce converg spre un obiectiv general. 2.4 ORGANIZAIA CENTRAT PE PROIECTE Extinderea managementului proiectelor ca mijloc de a susine competiia, de a rspunde mediului organizaional din ce n ce mai solicitant, a dus la apariia unui nou tip de organizaie, aa-numita organizaie centrat pe proiecte. O astfel de organizaie are ca i caracteristic principal faptul c performana ei se msoar n funcie de capacitatea de a se adapta la diferite proiecte i multitudinea proiectelor derulate i nu n funcie de soliditatea organigramei sau numrul de angajai. Competena profesional nu mai este nici ea o valoare n sine, ci ceea ce conteaz mai mult este viteza cu care angajaii i unesc abilitile i cunotinele pentru a gsi o soluie la o problem comun, precum i viteza cu care, odat rezolvat

problema (odat ncheiat proiectul), angajaii formeaz alte combinaii pentru a rezolva o nou problem. Organizaia centrat pe proiecte nu mai este compus din departamente care lucreaz fiecare pe diferite segmente ale unui proiect, de aceast dat proiectul este cel care impune structurarea pe departamente. Exist o serie de avantaje create ca urmare a structurrii activitii organizaiilor centrate pe proiecte i anume: - unitatea abordrilor i a metodologiilor aplicate; - derularea proiectelor conform unor proceduri standardizate; - extinderea standardizrii i la nivelul metodelor de raportare, de monitorizare a evoluiei proiectelor, de diseminare a rezultatelor intermediare i finale; - derularea proiectelor capt o nalt not de profesionalism; - proiectele derulate ctig vizibilitate n ansamblul organizaiei; - utilizarea instrumentelor specifice pentru managementul proiectelor devine previzibil i, prin urmare, mai eficient. Datorit noii modaliti de structurare a departamentelor, organizaiile centrate pe proiecte se pot confrunta cu fenomenul de inutilitate a activitilor n cadrul diferitelor proiecte, iar pe de alt parte exist pericolul unei birocratizri excesive a activitii. De multe ori, proiectele sunt conduse de specialiti ntr-un anumit domeniu, deci de persoane care au competen tehnic pentru a se ocupa de domeniul respectiv i nu de manageri de proiect cu pregtire specific, totodat existnd multiple i diferite grupuri de interes care au o miz n proiect, dar cu toate acestea, organizaiile sunt dispuse s accepte eventualele neajunsuri, care sunt ponderate de eficien i calitate maxim pe un proiect anume.

CAPITOLUL III
MANAGEMENTUL PROIECTELOR Utilizarea managementului proiectelor reprezint un pas important n dezvoltarea organizaiilor, indiferent de domeniul n care acestea i desfoar activitatea, i a condus la cristalizarea i dezvoltarea conceptului ca fiind o disciplin de sine stttoare, diferit de managementul general. Managementul proiectelor este un domeniu destul de recent aprut, iar importana sa a cunoscut o cretere major datorit faptului c, la scar internaional, tot mai multe aciuni se desfoar n cadrul unor proiecte. De aceea, resursele utilizate de aceste proiecte (mai ales cele financiare) au un rol din ce n ce mai mare n dezvoltarea economic, aria lor de aplicabilitate crescnd continuu.

3.1. PRINCIPIILE FUNDAMENTALE ALE MANAGEMENTULUI PROIECTELOR Extinderea i renumele pe care le cunoate managementul proiectelor au ncurajat eforturile de a determina o serie de principii fundamentale, care au rolul de a ghida activitatea propriu-zis i de a o standardiza n vederea performanei. Principiile managementului proiectelor sunt simple, dar uneori proiectul presupune cteva zeci sau chiar sute de activiti, iar aceste activiti sunt dependente unele de altele unele se desfoar n paralel, altele sunt interdependente, se intercondiioneaz, n sensul c nceputul lor depinde de ncheierea (cu succes) a altora, atunci cnd resursele, de o varietate deosebit, trebuie alocate n momente de timp diferite, n cantiti diferite, cnd finanarea provine din mai multe surse, cnd banii de la o anumit surs vin n trane, cnd exist mai muli parteneri cu

diverse grade de implicare n proiect, cnd echipa de proiect este asamblat din diferite departamente ale organizaiei, cnd o parte din activiti este subcontractat ctre teri, managementul proiectelor ncepe s devin o activitate ct se poate de complex i de riguroas, n nici un caz uoar sau care poate fi abordat superficial. Astfel c, preocuparea de a concepe o serie de principii fundamentale, care s fie agreate de ctre ntreaga comunitate a specialitilor n managementul proiectelor pornete de la o serie de premise: - persoanele implicate n activitile specifice proiectului urmresc aceleai obiective; - obiectivele proiectului sunt cele declarate, nu exist obiective ascunse sau care nu au fost declarate n mod explicit; - persoanele implicate n activitile specifice proiectului sunt oneste unele fa de altele; - toi membrii echipei au un bagaj minim de cunotine i de expertiz n managementul proiectelor, precum i cunotine legate de domeniul propriuzis al proiectului; - exist o motivaie puternic a membrilor echipei cu privire la ncheierea cu succes a proiectului; - toi membrii echipei cunosc foarte bine cine este finanatorul i care sunt obiectivele acestuia, ct i cui se adreseaz proiectul (cine este clientul/grupul int/grupul de beneficiari). Pornind de la aceste premise, se pot proiecta apte principii fundamentale ale managementului proiectelor (Wideman, 1999).

3.1.1. Principiul angajamentului Acest prim principiu subliniaz faptul c, ntre finanator (sponsor, furnizor de resurse, agenie de finanare) i instituia/organizaia care i propune s deruleze un proiect trebuie s existe un tip de angajament echitabil nainte de nceperea oricrei activiti. Acest angajament nseamn c ambele pri implicate cunosc foarte bine ce efort trebuie depus pentru a se realiza proiectul, cunosc, cel puin n mare, procesele i riscurile asociate proiectului, sunt dispuse s i mpart i s i asume responsabilitile, riscurile i un eventual eec.

3.1.2. Principiul succesului predefinit Al doilea principiu are n vedere faptul c normele pe baza crora proiectul este considerat un succes, att n ceea ce privete derularea, ct i produsul final, trebuie s fie definite de la bun nceput, nainte de declanarea oricrei activiti. Astfel, criteriile de succes convenite pot s constituie baza procesului de luare a deciziei i a evalurii finale. n acest sens, exist dou tipuri de criterii de succes, cele referitoare la derularea proiectului, care au n vedere respectarea limitelor de timp, a bugetului, exploatarea eficient a tuturor celorlalte resurse (oameni, echipamente, sedii) i o percepie creat n jurul proiectului i cele referitoare la produsul final, care au n vedere calitatea, standardele tehnice, relevana proiectului, eficiena sa, domeniul de aciune, precum i percepia creat n jurul produsului/rezultatului final. 3.1.3. Principiul eficienei/consistenei interne/interdependenei Cel de-al treilea principiu se refer la relaia de interdependen care exist ntre aria de cuprindere a proiectului, timpul alocat, bugetul stabilit i calitatea proiectat a produsului final. Cele patru elemente sunt interrelaionate, trebuie s fie realizabile i s se reflecte unul pe cellalt. Cu alte cuvinte, bugetul, spre

exemplu, trebuie s fie n concordan cu toate celelalte elemente nu se poate solicita o sum foarte mare de bani pentru rezolvarea unei probleme minore, cu o arie de cuprindere foarte ngust. Orice modificare a unuia dintre aceste elemente antreneaz modificri ale celorlalte. Modificarea ariei de cuprindere a proiectului antreneaz modificri n ceea ce privete calitatea, timpul i resursele necesare proiectului.

3.1.4. Principiul strategiei n accepiunea acestui principiu orice proiect trebuie s aib la baz o strategie. n cazul domeniului pe care l avem n vedere managementul proiectelor planificarea precede ntotdeauna execuia. n termeni simpli, acest principiu stabilete ce trebuie fcut i cnd trebuie fcut.

3.1.5. Principiul controlului Conform acestui principiu toate proiectele trebuie s beneficieze de politici i proceduri riguroase i eficiente de control i monitorizare. Spre deosebire de principiul anterior, acest principiu stabilete cum trebuie fcut un anumit lucru i de ctre cine.

3.1.6. Principiul canalului unic de comunicare Potrivit acestui principiu, ntre finanator i managerul de proiect trebuie s existe un singur canal prin care sunt comunicate deciziile de importan vital pentru proiect Totodat acest principiu nu l exclude pe cel al transparenei sau pe cel al accesului nengrdit la informaie. Important este ca, n procesul de luare a deciziilor i de comunicare a acestora n cadrul unui proiect, att finanatorul, ct i promotorul proiectului s comunice prin intermediul unui singur reprezentant.

Altfel, deciziile ajung la unitatea de execuie n mod eronat, devin contradictorii, afectnd substanial bunul mers al proiectului.

3.1.7. Principiul mediului de lucru stimulativ n sfrit, ultimul principiu se refer la datoria pe care o are managerul de proiect de a crea, pentru membrii echipei, un mediu de lucru stimulativ, care s exploateze ntreg potenialul acestora. Crearea acestui mediu ncurajator se realizeaz att prin adoptarea unui stil managerial adecvat tipului de proiect, ct i prin administrarea inteligent a relaiei cu organizaia n ansamblu. Managerul de proiect trebuie s fie preocupat ca echipa pe care o conduce s nu fie izolat n ansamblul organizaiei, ca proiectul de care este responsabil s fie cunoscut, acceptat i apreciat la nivelul organizaiei. Principiile managementului proiectelor au valoare universal pentru majoritatea proiectelor, indiferent de dimensiunea sau complexitatea lor. Gestionarea riguroas a proiectelor presupune aplicarea unor mecanisme i proceduri formale importante i utilizarea unor resurse organizaionale nsemnate. 3.2. ORGANIZAREA STRUCTURAL A MANAGEMENTULUI PROIECTELOR n funcie de msura competenelor repartizate, exist trei tipuri organizatorice de baz, distincte, n structura organizatoric a proiectelor: coordonarea proiectului, organizarea matriceal a managementului proiectelor i structura organizatoric independent a managementului proiectelor

3.2.1. Coordonarea proiectelor n cazul coordonrii proiectelor este vorba de o form redus a managementului proiectelor n care coordonarea proiectului se face de ctre anagerul/coordonatorul de proiect, de cele mai multe ori, direct subordonat conductorului instituiei, datorit importanei strategice a proiectelor. Toate procesele de decizie importante cad ns n sarcina organizaiei funcionale primare. Managementul proiectelor n forma organizatoric de coordonare a proiectelor are cteva avantaje: - membrii echipei de proiect provin direct din structura organizatoric primar, linear, posed deci cunotinele i experiena nemijlocit; - dispunerea de personal este relativ simpl, flexibil, deoarece, n funcie de necesiti, angajaii pot fi dislocai din structura organizatoric primar. Dup ncheierea proiectului, acetia revin direct pe posturile lor iniiale, evitndu-se astfel problema reintegrrii membrilor echipei; - costurile sunt reduse. - coordonatorul de proiect poate s ia decizii obiective, neavnd interese nemijlocite n proiect dect acelea orientate spre ndeplinirea obiectivelor de proiect. Exist totui i o serie de dezavantaje ale acestei forme de organizare care sunt evidente: - fiecare decizie trebuie discutat amnunit cu factorii de decizie din structura organizatoric primar; - n cazul intereselor divergente, sarcinile structurii organizatorice primare sunt prioritare; - lupta pentru resurse, att materiale ct i de personal, poate s devin acerb i s blocheze bunul mers al proiectelor.

Modelul de coordonare a proiectelor se justific numai atunci cnd se deruleaz proiecte de dimensiuni reduse, cu folosirea resurselor umane ntr-un timp clar stabilit. Ea este adecvat pentru organizaii mici i mijlocii, care nu pot susine un management al proiectelor costisitor, pe termen lung. 3.2.2. Organizarea matriceal a managementului proiectelor Este o combinaie ntre coordonarea de proiect i structura organizatoric independent a managementului proiectelor. n funcie de aspectele abordate n proiect, competenele sunt exercitate att de conductorul de proiect, ct i de ctre conducerea din structura organizatoric primar. Organizarea matriceal a proiectelor prezint cteva avantaje: - att conductorul de proiect ct i echipa de proiect sunt responsabili pentru rezultatele proiectului, dar competenele de decizie i responsabilitatea pentru proiect se afl n minile managerului de proiect; - personalul din echipa de proiect poate fi folosit n mod flexibil, reintegrarea n unitatea organizatoric iniial a membrilor echipei de proiect fiind simpl; - coordonarea n funcie de obiectivele urmrite a intereselor legate de proiect i a intereselor unitii organizatorice primare este simpl. Dezavantajele organizrii matriceale a managementului proiectelor sunt i ele clare: - deseori apar conflicte de competene i de resurse ntre managerul de proiect i conductorii departamentelor din organizaia primar, mai ales atunci cnd se suprapun mai multe proiecte; - fenomenul dublei subordonri a membrilor echipei de proiect, duce la dezorientare.

Din punct de vedere psihologic este forma de organizare cea mai dificil datorit conflictelor care apar ntre organizaia primar ierarhic i organizaia secundar de proiect, bazat pe experiena muncii n echip, deci conflicte ntre dou culturi diametral opuse. Organizarea matriceal a proiectelor este forma cea mai rspndit i cea mai avantajoas, dac aspectele privind rezolvarea conflictelor de competen sunt gestionate profesional printr-un management al conflictelor.

3.2.3. Organizarea independent a managementului proiectelor Managementul proiectelor ca structur organizatoric independent implic o structur organizatoric secundar, independent, att conductorul de proiect ct i membrii echipei de proiect fcnd parte dintr-o organizaie secundar. Organizaia primar nu intervine dect la cerere pentru rezolvarea unor aspecte de strict specialitate. Toate competenele i rspunderile sunt localizate la nivelul organizaiei secundare deci la nivelul managementului independent al proiectelor. Practic, aceast form de organizare este folosit la derularea unor proiecte mari, precum i n cadrul unor organizaii mari (concerne), n domeniul departamentelor de consulting intern. Avantajele unei uniti organizatorice independente privind managementul proiectelor sunt evidente: - conductorul de proiect are competene depline; - este o form eficient de organizare pentru proiectele de anvergur; - permite reacii rapide la schimbri i perturbaii; - se realizeaz o identificare a membrilor echipelor de proiect cu proiectele n sine i cu obiectivele propuse; - nu apar conflicte de competen;

- durata derulrii proiectelor este mai scurt. Exist i dezavantaje care nu trebuie ns neglijate: - costurile de implementare ale unui management al proiectelor independent sunt mari; - noua structur trebuie mai nti s se rodeze nainte de a deveni eficient; - flexibilitatea echipei de proiect este redus; - specialitii folosii temporar trebuie recrutai din organizaia primar; - recrutarea echipei de proiect i reintegrarea lor ulterioar poate deveni dificil datorit perspectivelor de carier reduse. Managementul proiectelor ca unitate organizatoric independent este o form de organizare adecvat pentru proiecte mari, cu un grad de unicitate ridicat, proiecte care nu au tangen foarte mare cu organizaia primar. 3.2.4. Managementul proiectelor ca structur multi-proiect Acest tip de structur este o variant a organizrii proiectelor matriceale i este necesar atunci cnd se deruleaz simultan mai multe proiecte. Ea necesit implicarea total a departamentelor din organizaia primar, precum i implicarea unor teri (firme de consultan, organizaii naionale i internaionale, parteneri externi etc). Structurarea managementului proiectelor sub forma multi-proiectului se aplic, n general, n proiectele strategice, de reorientare a unei organizaii, n proiectele de colaborare cu alte organizaii, fie ele interne sau externe, de reorientare informaional etc. Avantajele acestui tip de structur sunt similare cu cele ale structurii matriceale, dar pentru o mai bun derulare a proceselor complexe i pentru stabilirea clar a responsabilitilor este necesar stabilirea unui manager de proiect din cadrul, interiorul, organizaiei. Exist ns i o serie de dezavantaje ale acestei structuri care reies din nsi complexitatea ei, cum ar fi: resursele limitate i modul de alocare al acestora poate

duce la discuii, este necesar o stabilire clar a prioritilor n derularea proiectelor i n alocarea resurselor, este nevoie de o planificare a proiectelor, actualizat periodic, la nivelul ntregii organizaii i o estimare periodic a resurselor alocate de ctre ficare departament n parte. Managementul proiectelor ca structur multiproiect este o form organizatoric complex de derulare a mai multor proiecte concomitent, precum i derularea unor proiecte n colaborare cu parteneri externi. n concluzie, conceptele manageriale tradiionale, care se bazau pe structuri ierarhice i pe reglementri birocratice nu se mai adapteaz noilor condiii economice, sociale, politice, regionale dac se dorete implementarea cu succes a unui management modern, eficient, adaptat la cerinele secolului XXI.

CAPITOLUL III

SISTEME INFORMATICE I METODE DE DEZVOLTARE ALE ACESTORA Odat cu dezvoltarea ntreprinderilor se dezvolt i crete i genul lor de activitate, odat cu aceasta se schimb i procesele ce au loc n cadrul ntreprinderii, unele apar, altele se schimb, unele n genere pot s dispar. Cu timpul aceast evoluie duce la dificultatea monitorizarii si dirijrii activitilor unei ntreprinderi, deoarece odat cu creterea numrului de procese monitorizarea si dirijarea fiecrui proces n parte devine destul de dificil i implic multe cheltuieli de resurse umane ct i financiare. Din aceast cauz ntreprinderea trebuie s recurg la ntrebuinarea unui produs soft de automatizare a acestor procese. Odat cu apariia calculatoarelor i dezvoltarea noilor tehnologii de programare, crearea unui sistem informatic (SI) de automatizare a proceselor de lucru din cadrul unei ntreprinderi, a ncetat s mai fie o problem att de complicat ca naintea apariiei primelor calculatoare personale (PC). De-a lungul anilor au fost elaborate o mulime de sisteme informatice de automatizare a diferitor procese, au fost elaborate o serie de sisteme care pot fi ntrebuinate nu doar de o singur companie. Dar deoarece ntreprinderile difer de la una la alta,

nu sunt de acelai nivel de dezvoltare, nu toate au acelai gen de activitate, majoritatea dintre ele i creeaz propriul su SI, care le permite automatizarea proceselor dorite existente i a celor care se presupune c vor aprea pe viitor.Crearea softului dat contribuie la mbuntirea lucrului personalului i a ntregii companii. 3.1. Noiunea de sistem Ludvig Bertalanffy, printele teoriei sistemelor a definit sistemul ca un ansamblu de elemente aflate in interaciune. Ali autori, ns, l consider ca: o mulime de obiecte ntre care exist anumite relaii de cauzalitate sau ca o mulime ordonat de elemente; acea mulime de elemente n cadrul creia se desfoar procesul de conducere; o mulime de perechi de intrare-ieire. Toate aceste abstractizri au generat sursa elaborrii teoriei matematice a sistemelor. Pentru a putea da natere unui sistem elementele lui trebuie s aib o anumit afinitate, s se atrag, s depind, i s se influeneze unele pe altele. Sistemele la rndul lor sunt organizate pe mai multe niveluri, pentru ca elementele lor sunt i ele formate din alte elemente, fiind de fapt nite subsisteme. Orice subsistem de ordin superior este compus dintr-o mulime de subsisteme de ordin inferior. n pofida numeroaselor caracteristici generale, sistemele nu sunt identice ntre ele. Dei sunt formate dintr-o mulime de elemente aflate n interaciune, dei toate se comport unitar i integral n relaiile lor cu mediul, diferitele sisteme se deosebesc foarte mult ntre ele. Teoria sistemelor recunoate c, n funcie de mulimea elementelor, de relaiile cu mediul, de factorul timp, de coeficientul de complexitate i de natura

relaiilor dintre mrimile de intrare i cele de ieire, sistemele pot fi finite sau infinite, nchise sau deschise, statice sau dinamice, simple sau complexe, determinate sau probabilistice, liniare sau neliniare etc. (Grunberg, 1977).

Figura 2.1: Tipuri de sisteme. Proprieti ale Sistemelor, conform Teoriei generale a sistemelor: 1. Orice sistem are un mediu n care exist un sistem nu poate exista fr nici o alta conexiune cu alte sisteme. Nu exist noiunea de sistem nchis. Contientizarea mediului n care exist un sistem real poate fi esenial pentru calitatea modelarii acestuia. 2. Orice sistem este delimitat de mediul in care exist de un anumit tip de frontier nici ntr-un caz frontiera nu trebuie folosit pentru a realiza

nchiderea acestuia. Frontiera este o noiune cu ajutorul creia se realizeaz o delimitare intre dinamica intern a unui sistem si dinamica relaiilor sistemului cu mediul nconjurtor. Teoretic nu poate fi fcut modelarea unui sistem real daca nu sunt cunoscute frontierele acestuia. 3. Orice sistem are intrri i ieiri intrrile sunt semnale (mesaje) ale mediului ctre sistem, iar ieirile sunt rspunsuri pe care sistemul le da mediului n care se afl. 4. Orice sistem are interfa interfaa permite comunicarea ntre dou sau mai multe sisteme. 5. Orice sistem poate avea, potenial, subsisteme orice subsistem poate fi la rndul lui, neles ca sistem care de asemenea se poate descompune n subsisteme (nu se descompune ceea ce n perspectiva intereselor imediate de modelare sau cunoatere este indivizibil). 3.2. Sistem Informaional i Sistem Informatic n viaa noastr de zi cu zi, calculatoarele sunt ceva obinuit, ba chiar indispensabil n unele cazuri. Se poate spune, pe drept cuvnt c trim ntr -o societate informatizat. n zilele noastre, ntlnim calculatoare peste tot, de la magazinul din col, care-i ine evidenele sale cu ajutorul unui PC i pn la pota la care pltim telefonul. Peste tot sunt calculatoare, legate eventual ntre ele i formnd astfel reele de calculatoare. Toate acestea se datoreaz faptului c ne dm seama din ce n ce mai mult ca PC-ul ne uureaz munca. Dar trebuie de subliniat faptul c un calculator este de fapt o mainrie care prelucreaz o serie de informaii pe care i le dm. Informaia, este elementul esenial din acest ntreg lan. De fapt, n practic ntlnim, printre altele, dou concepte legate de aceasta i anume sistemul informaional i sistemul informatic.

Sistemul

informaional

este

un

ansamblu

de

elemente

(resurse

organizaionale, umane, materiale, tehnice i financiare) implicate n procesul de colectare, furnizare, prelucrare i transmitere a informaiilor. Sau altfel spus, reprezint un ansamblu de fluxuri de informaii n baza crora se desfoar activitatea din orice domeniu, asigurnd legtura dintre sistemul decizional i cel de execuie. Rolul sistemului informaional este de a transmite informaia ntre diferite elemente. De exemplu, n cadrul unei uniti economice, rolul sistemului informaional este de a asigura persoanele din conducere cu informaii necesare pentru luarea diferitor decizii economice sau de alt natur. n cadrul sistemului informaional se regsesc: informaia vehiculat, documentele purttoare de informaii, personalul, mijloace de comunicare, sisteme de prelucrare a informaiei, etc. Printre posibilele activiti desfurate n cadrul acestui sistem, pot fi enumerate: achiziionarea de informaii din sistemul de baz, completarea documentelor i transferul acestora ntre diferite compartimente, centralizarea datelor, etc. Sistemul informatic este un ansamblu structurat i corelat de proceduri i echipamente electronice de calcul care permit prelucrarea automat a datelor i obinerea de informaii. Cu alte cuvinte sistemul informatic va include n sine sistemul de prelucrare a datelor, adic unul sau mai multe calculatoare, echipamente periferice i software ul necesar prelucrrii datelor. Un rol important n cadrul componentelor sistemului informatic l ocup echipamentele electronice de calcul, materializate prin dispozitive periferice pentru introducerea datelor (tastatura, scannerul), extragerea informaiilor (printer, monitor), suporturi de memorie extern (floppy, hard disc, CD), unitatea central -

microprocesorul. Acestea i sunt elementele care deosebesc sistemul informatic de cel informaional. Datele de intrare sau, cu alte cuvinte, intrrile n sistem reprezint datele introduse n sistem sau n una din prile sale cu scopul de a fi memorizate sau prelucrate. Ieirile din sistem sunt, pe de alt parte, datele pe care un sistem sau orice parte a sa le transfer n afara acelui sistem sau a prii. Sistemele informatice acoper cele mai diverse domenii, clasificndu-se n funcie de specializare n: a) Sisteme specializate, sunt sisteme elaborate pentru soluionarea problemelor din anumite domenii. b) Sisteme de uz general, cu ajutorul crora se rezolv o gam mai larg de probleme din mai multe domenii; c) Sisteme locale, n cadrul crora programele i datele care se prelucreaz se afl pe un singur calculator; d) Sistemele de reea funcioneaz ntr-o reea de calculatoare, iar datele i programele pot fi distribuite pe mai multe staii de reea. n funcie de localizarea datelor i de locul n care se efectueaz prelucrrile datele, sistemele informatice pot fi: Cu date centralizate (datele se afla pe un singur sistem de calcul); Cu date distribuite (datele se afla distribuite pe mai multe calculatoare n reea); Cu prelucrri centralizate (prelucrarea datelor se face pe o singura staie de lucru, indiferent de numrul staiilor pe care sunt informaiile de prelucrat);

 Cu prelucrri distribuite (mai multe calculatoare prelucreaz datele provenite de la unul sau mai multe calculatoare din reea). Dup domeniul n care funcioneaz, sistemele pot fi clasificate : De baze de date, specializate n gestiunea unor cantiti mari de date; Pentru prelucrri tiinifice, specializate pe anumite domenii tiinifice; Pentru conducerea proceselor tehnologice, pentru conducerea unor maini, scule, unelte computerizate; Dup nivelul ierarhic ocupat de sistemele informatice n structura organizaional a societii, pot fi : Sisteme informatice pentru conducerea activitilor la nivelul unitilor economice; Sisteme la nivelul organizaiilor cu structur de grup; Sisteme informatice teritoriale; Sisteme informatice la nivel de ramur i subramur i la nivel economic naional; Sisteme de uz general. Dup activitatea ce o automatizeaz, sistemele pot fi: Pentru conducerea produciei; Pentru activitatea comercial; Pentru evidena contabil; Pentru evidena materialelor si mrfurilor; Pentru evidena personalului i salarizare; Pentru evidena mijloacelor fixe.

3.3. Ciclul dezvoltrii sistemului informatic Dezvoltarea unui sistem informatic este un proces ciclic. Modelul grafic al pailor principali care trebuie urmai n dezvoltarea sistemelor este prezentat n figura urmtoare.
Analiza, documentarea sistemului existent Dezvoltarea, testarea, validarea sistemului Implementarea sistemului Evaluarea i ntreinerea sistemului

Figura 2.2. Privire de ansamblu asupra ciclului de via al dezvoltrii sistemelor Este clar c primele trei etape n dezvoltarea sistemelor pun accent pe lucrurile potrivite problemele manageriale. Paii ulteriori ai dezvoltrii sistemelor se concentreaz asupra asigurrii c lucrurile sunt bine fcute. Paii din ciclu nu sunt discrei n totalitate, prelucrai o singur dat. Mai degrab, ciclul de dezvoltare a sistemelor este iterativ i evolutiv. El definete un flux secvenial principal din punctul de origine pentru a identifica noi probleme i oportuniti. Fiecare pas reprezint un punct principal i are transmiteri identificabile ce simbolizeaz ntregul. La orice pas din ciclu pot fi descoperite problemele i/sau oportunitile neidentificate anterior. n astfel de cazuri este important asigurarea integrrii corecte n sistem a soluiei la noua problem i/sau noua oportunitate. Efectuarea chiar a unei schimbri minore la un sistem fr a lua n considerare ceea ce s-a stabilit anterior poate cauza efecte neanticipate i de nedorit. Aceste efecte pot duna grav exploatrii sistemului. Prin urmare, aa cum se arat n Figura 2.2., toi paii ciclului de dezvoltare a sistemelor permit ntoarcerea la punctul de origine n orice moment. Aceast caracteristic face ca ciclul de via s

prezinte, mai degrab, o caracteristic n spiral sau n vrtej dect una pur secvenial sau o caracteristic n cascad. Modelul n cascad modelul tradiional al ciclului de via a ajuns s fie foarte criticat pentru c este prea inflexibil pentru a rspunde la climatul de afaceri schimbtor din ziua de astzi. Cu deplasarea sa natural n jos implic faptul c ntoarcerea n sus la paii anteriori este nenatural, de nedorit i de evitat. Ritmul rapid al schimbrii afacerilor sugereaz oarecum un model care faciliteaz, dac nu ncurajeaz, revizuirea pailor anteriori pentru a asigura viabilitatea sistemului i pentru a reduce schimbrile ulterioare din aval. Modelul ilustrat n Figura 2.3. susine acest punct de vedere. Timpul necesar completrii ciclului pentru o problem sau oportunitate dat poate varia de la cteva ore la mai muli ani, depinznd de complexitatea cerinei. n continuare se va face o scurt trecere n revist a celor apte pai ai ciclului de via al dezvoltrii sistemului.

Figura 2.3. Modelul ciclului de via al dezvoltrii sistemului Modelul n Cascad

Etapa 1: Identificarea problemelor i a oportunitilor Aa cum este ilustrat n figura 2.3., impulsul pentru iniierea unui ciclu de dezvoltare a sistemului este de a identifica noi probleme i oportuniti. Pentru a nelege clar natura exact a problemei, este necesar o analiz n detaliu pentru cunoaterea sistemului existent. Etapa 2: Analiza i documentarea sistemului existent Sistemul existent inclusiv sistemele informaionale manuale, bazate pe documente trebuie s fie bine analizat i documentat nainte de proiectarea, dezvoltarea i implementarea schimbrilor (sau a unui sistem nou n totalitate). - revizuirea sistemului de producie; - preluarea deciziilor innd seama de fluxul de producie; - revizuirea informaiilor curente disponibile pentru asistarea lurii deciziilor (de exemplu, tranzaciile i rapoartele); - identificarea deficienelor din sistemul informaional existent. De ndat ce a fost analizat, sistemul informaional existent este documentat pentru activitile ulterioare i pentru cerine de comunicare. Etapa 3: Determinarea cerinelor informaionale Dup ce au fost depistate deficienele din sistemul informaional i sistemul existent a fost bine analizat i documentat, pot fi determinate cerinele informaionale. Deoarece sistemul informaional trebuie s conin informaiile necesare lurii deciziilor, soluiile la problemele informaionale pot fi obinute prin restructurarea informaiilor existente sau luarea n considerare a altora noi. Etapa 4: Proiectarea funcie de tehnologie, cerinele de personal Colectarea informaiilor i analiza cerinelor stabilesc criteriile pentru identificarea mijloacelor alternative de soluionare a problemelor. De aceea, n

timp ce pasul anterior definete ce este de dorit, acest pas definete cum se va face. Personalul necesar i tehnologiile viabile identificate sunt incluse n sistem, putnd fi structurate pentru a susine soluia definit n pasul anterior. n general, sunt disponibile mai multe variante, care difer prin gradul de realizare a sarcinii prestabilite. Etapa 5: Dezvoltarea, testarea i validarea sistemului Pn la acest punct au fost identificate soluiile dorite i mijloacele de realizare a lor. Acum este posibil dezvoltarea i testarea sistemului. Acest pas conine instalarea hardware-ului sau software-ului necesar, precum i generarea i testarea programelor de calculator. Software-ul poate fi achiziionat ca un sistem complet necesitnd unele modelri sau poate fi dezvoltat de ctre organizaie. P rodusul final al acestui pas este un sistem operabil i de ncredere care satisface obiectivele iniiale de proiectare pentru rezolvarea unei probleme sau pentru a profita de o oportunitate. Etapa 6: Implementarea sistemului Dup ce noul sistem a fost dezvoltat i testat, se poate realiza conversia de la vechiul la noul sistem. Un element cheie al procesului de implementare l reprezint rezolvarea problemelor organizaionale i de comportament care apar adesea. Implementarea de noi sisteme informaionale schimb de obicei uneori dramatic locurile de munc, responsabilitile, cerinele oamenilor i relaiile de comunicare. Pentru a face fa factorului uman i pentru a minimiza rezistena la schimbare, acestea trebuie previzionate. Corect implementate, sistemele pot fi foarte motivatoare i pot ajunge la participanii din organizaie. Etapa 7: Evaluarea i ntreinerea sistemului Dup implementarea noului sistem, este important de apreciat c t de eficiente sunt soluiile oferite la diverse probleme. Evaluarea, prin urmare, nseamn

aprecierea gradului de variaie dintre performanele planificate i cele actuale ale sistemului. Dac noul sistem a euat n atingerea obiectivelor din proiectare sau prezint noi probleme sau oportuniti, s-ar putea s trebuiasc iniiat un nou ciclu de via al dezvoltrii sistemului. Dac noul sistem opereaz satisfctor, atunci sistemul poate fi meninut la nivelul curent de exploatare pn cnd apar noi probleme sau oportuniti. naintea analizrii, o problem trebuie clar identificat i definit. Prin urmare, importan capital are explorarea conceptelor legate de identificarea problemelor i a oportunitilor.

3.4. Analiza i proiectarea sistemului informatic Analiza SI este descompunerea unui ntreg n elemente componente pentru a le putea studia separat. Proiectarea SI este un proces de concepere, de gndire a unei soluii posibile pentru o problem propus bazat pe mai multe procedee. Proiectarea este un proces iterativ cu ajutorul cruia cerinele ctre SI sunt translate n prezentri inginereti a SI. La nceput aceste reprezentri redau numai informaia conceptual la un nivel nalt de abstractizare, iar urmtoarele concretizri duc la alctuirea textelor n limbaj de programare. Proiectarea se descompune n 2 subactiviti: - proiectarea preventiv sau de ansamblu; - proiectarea de detaliu;

Proiectarea preventiv formeaz abstracia nivelului arhitectural i identific structura general a SI. Pornind de la structura problemei i scopul pentru ce se creeaz SI. n acest fel sunt identificate componentele sistemului, relaiile dintre ele, algoritmii care vor fi utilizai i datele comune ale componentelor. Proiectarea de detaliu concretizeaz aceste abstracii i presupune detalierea componentelor, definete precis algoritmii, structurile de date, interfeele dintre componente i modul de implementare a lor.
cerine Proiectarea preventiv Arhitectura programelor Proiectarea i datelor de detaliu Structura datelor i algoritmii programelor

Proiectarea interfeei

Figura 2.4.: Legturile informatice a procesului de proiectare Proiectarea preventiv asigur : - identificarea subsistemelor; - determinarea principiilor de baz de dirijare a subsistemelor i a interaciunilor lor; Proiectarea preventiv include 3 etape de activitate: Structurarea sistemului sistemul se structureaz n cteva subsisteme, unde subsistemul se subnelege o component program independent; Modelarea dirijrii aici se determin modelul de legtur de dirijare ntre sisteme particulare; Decompoziia subsistemelor n module aici fiecare subsistem se descompune n module, se determin tipurile de module i legturile dintre ele;

3.5. Tehnologii utilizate la dezvoltarea sistemului informatic Analiznd problemele depistate n activitatea ntreprinderilor sa hotrt crearea unui sistem client-server, fiind accesibil n orice moment de timp de utilizatorii definii n acest sistem de ctre administratorul sistemului. Reeind din aceasta pentru dezvoltarea sistemului se va utiliza / aplica urmtoarele tehnologii. Pentru partea client, FrontEnd , se va utiliza HTML, CSS i JavaScript / jQuery. Partea server, BackEnd, va fi creat n PHP, cu baza de date n MySQL, iar comunicarea ntre client si server va fi realizat cu AJAX, ca limbaj de comunicare ntre client i server va fi folosit JSON-ul. Deci avem urmataorea lista de tehnologii: FrontEnd: HTML CSS JavaScript / jQuery FrontEnd < > BackEnd AJAX JSON BackEnd: PHP SQL Server

Apache Server
Aceste tehnologii au fost selectate pentru dezvoltarea sistemului dat, reeind din trasaturile specifice fiecrui limbaj / tehnologie ce urmeaz. HTML

Unul din primele elemente fundamentale ale WWW ( World Wide Web ) este HTML ( Hypertext Markup Language ), care descrie formatul primar in care documentele sint distribuite si vazute pe Web. Multe din trasaturile lui, cum ar fi independenta fata de platforma, structurarea formatarii si legaturile hipertext, fac din el un foarte bun format pentru documentele Internet si Web. HTML a fost dezvoltat initial de Tim Berners-Lee la CERN in 1989. HTML a fost vazut ca o posibilitate pentru fizicienii care utilizeaza computere diferite si schimbe intre ei informatie utilizind Internetul Primele specificatiile de baza ale Web-ului au fost HTML, HTTP si URL. Erau prin urmare necesare citeva trasaturi : independenta de platforma, posibilitati hypertext si structurarea documentelor.Independenta de platforma inseamna ca un document poate fi afisat in mod asemanator de computere diferite ( deci cu fonte, grafica si culori diferite ), lucru vital pentru o audienta atit de variata. Hipertext inseamna ca orice cuvint, fraza, imagine sau alt element al documentului vazut de un utilizator ( client ) poate face referinta la un alt document, ceea ce usureaza mult navigarea intre multiple documente sau chiar in interiorul unui aceluiasi document. Structurarea riguroasa a documentelor permite convertirea acestora dintr-un format in altul precum si interogarea unor baze de date formate din aceste documente. CSS Fiierele CSS - Cascading Style Sheets - foi de stil n cascad- utilizate la mbuntirea prezentrii unei pagini Web (adic a modului n ca re browserul o afieaz). CSS permite de stabilit proprieti pentru elementele HTML utiliznd o gam uria de valori. Avnd la dispoziie mai mult de 100 de proprieti, CSS este un instrument avansat destinat proiectanilor Web pentru crearea de site -uri Web profesionale care nu pot fi construite folosind atribute HTML. Specificaiile CSS sunt gestionate de World Wide Web Consortium(W3C) .

Consoriul Web a conceput i standardizat dou niveluri ale foilor de stiluri: -CSS1 ofer un mecanism simplu care permite autorilor i utilizatorilor de pagini Web s ataeze acestora stiluri de afiare. Limbajul CSS1 este uor de neles i folosit. Acesta exprim stilurile conform terminologiei editrii computerizate. -CSS2 reprezint o generalizare (extensie) a primului nivel de foi de stiluri, aducnd n plus faciliti de motenire a stilurilor, efecte vizuale, poziionri i paginri, integrarea mai multor tipuri de media (de exemplu, suport pentru sunet). Propietile de stil CSS ofer soluii a cel puin dou probleme cu care se confrunt creatorii documentelor HTML: -eliminarea redundanei stilurilor introduse n paginile web prin intermediul unor marcatori cum ar fi ; -mbogirea n termeni de design a paginilor Web. JavaScript JavaScript este un limbaj de programare orientat obiect bazat pe conceptul prototipurilor. Este folosit mai ales pentru introducerea unor funcionaliti n paginile web, codul Javascript din aceste pagini fiind rulat de ctre browser. Limbajul este binecunoscut pentru folosirea sa n construirea siturilor web, dar este folosit i pentru acesul la obiecte ncastrate (embedded objects) n alte aplicaii. A fost dezvoltat iniial de ctre Brendan Eich de la Netscape Communications Corporation sub numele de Mocha, apoi LiveScript, i denumit n final JavaScript. n ciuda numelui i a unor similariti n sintax, ntre JavaScript i limbajul Java nu exist nicio legtur. Ca i Java, JavaScript are o sintax apropiat de cea a limbajului C, dar are mai multe n comun cu limbajul Self dect cu Java. Ajax Ajax, prescurtare pentru Asynchronous JavaScript and XML, este o tehnic de programare pentru crearea de aplicaii web interactive. Intenia este s fac paginile web s devin mai rapide i deci mai acceptate, prin schimbul n fundal al

unor cantiti mici de date cu serverul, astfel nct s nu fie nevoie ca pagina s fie rencrcat la fiecare aciune a utilizatorului. Aceasta are ca scop creterea interactivitii, vitezei i uurinei n utilizare a aplicaiilor web. JSON JSON este un acronim n limba englez pentru JavaScript Object Notation, i este un format de reprezentare i interschimb de date ntre aplicaii informatice. Este un format text, inteligibil pentru oameni, utilizat pentru reprezentarea obiectelor i a altor structuri de date i este folosit n special pentru a transmite date structurate prin reea, procesul purtnd numele de serializare. JSON este alternativa mai simpl, mai facil dect limbajul XML. Elegana formatului JSON provine din faptul c este un subset al limbajului JavaScript (ECMA-262 3rd Edition) , fiind utilizat alturi de acest limbaj. Formatul JSON a fost creat de Douglas Crockford i standardizat prin RFC 4627. Tipul de media pe care trebuie s l transmit un document JSON este application/json. PHP PHP este un limbaj de programare. Numele PHP provine din limba englez i este un acronim recursiv : Php: Hypertext Preprocessor. Folosit iniial pentru a produce pagini web dinamice, este folosit pe scar larg n dezvoltarea paginilor i aplicaiilor web. Se folosete n principal nglobat n codul HTML, dar ncepnd de la versiunea 4.3.0 se poate folosi i n mod linie de comand (CLI), permi nd crearea de aplicaii independente. Este unul din cele mai importante limbaje de programare web open-source i server-side, existnd versiuni disponibile pentru majoritatea web serverelor i pentru toate sistemele de operare. Conform statisticilor este instalat pe 20 de milioane de situri web i pe 1 milion de servere web. Este disponibil sub Licena PHP i Free Software Foundation l consider a fi un software liber. SQL

SQL (Structured Query Language - Limbaj Structurat de Interogare) este un limbaj de programare specific pentru manipularea datelor n sistemele de manipulare a bazelor de date relaionale (RDBMS), iar la origine este un limbaj bazat pe algebra relaional. Acesta are ca scop inserarea datelor, interogaii, actualizare i tergere, modificarea i crearea schemelor, precum i controlul accesului la date. A devenit un standard n domeniu (standardizat ANSI-ISO), fiind cel mai popular limbaj utilizat pentru creearea, modificarea, regsirea i manipularea datelor de ctre SGBD-urile (Sistemele de Gestiune a Bazelor de Date) relaionale. Pe lng versiunile standardizate ale limbajului, exist o mulime de dialecte i variante, unele proprietare, fiind specifice anumitor SGBD-uri i de asemenea coninnd extensii pentru a suporta SBD-urile (Sistemele de Baze de Date) obiectuale (obiectual-relaionale). Apache Server Serverul Apache este caracterizat ca fiind un software gratuit i open source, acesta fcnd ca, ncepnd din aprile 1996, el s fie cel mai popular server HTTP. Cu toate c n noiembrie 2005 a nceput s piard din cota de pia, n aprilie 2008 Apache sttea nc la baza a peste 50 % din siturile web. Apache suport o mare varietate de module care i extind funcionalitatea, acestea variaz de la server side programming i pn la scheme de autentificare. Cteva limbaje suportate sunt: mod_perl, mod_python, Tcl si PHP. Ca alte module putem enumera : SSL si TLS support (mod_ssl), un modul proxyun, modul de rescriere URL (cunoscut ca un motor de rescriere mod_rewrite), custom log files (mod_log_config) i suport de filtrare (mod_include i mod_ext_filter). O alt calitate a serverului Apache este virtual hosting (gzduirea virtual), care const n posibilitatea de a gzdui mai multe situri simultan pe acelai server.

CAPITOLUL IV
PROIECTAREA I DEZVOLTAREA APLICAIEI

Se propune elaborarea unui sistem informatic care se va ocupa de gestionarea managementul proiectelor. Elaborarea acestei aplicaii va permite dezvoltarea mai eficienta a lucrului in cadrul companiilor mari, interaciunea dintre client i lucrtor, monitorizarea att a proiectelor ct i a personalului de lucru.

3.1. Elaborarea arhitecturii sistemului informatic Exist o mulime de tehnologii i instrumente cu ajutorul crora se poate de realizat ntr-un anumit sens un proiect optimal al unui SI, ncepnd cu etapa de analiz i sfrind cu crearea codului programului. Limbajul UML include n sine o mulime de instrumente de modelare, care n prezent sunt acceptate de majoritatea instrumentelor de programare. Creatorii UML l definesc ca un limbaj de identificare, reprezentare, proiectare i documentare a SI, sistemelor economice, sisteme tehnice i a altor sisteme de diferit natur. UML conine un set de diagrame i notaii de diferite tipuri. Standardul UML versiunea 1.0, acceptat de OMG n anul 1997, propune urmtorul complet de diagrame de modelare: diagrama cazurilor de utilizare (Use Case Diagram) o ofer o descriere general a modului n care va fi utilizat sistemul o furnizeaz o privire de ansamblu a funcionalitilor ce se doresc a fi oferite de sistem.

 diagrama claselor (Class Diagram) o diagrama de clase, arat structura static a obiectelor, structura lor intern, i relaiile dintre acestea. diagrama de secven (Sequence Diagram) o diagrama de secven prezint secvena de mesaje corespunztoare sistemului real-time modelat. diagrama de colaborare (Collabration Diagram) o descrie mulimea de interaciuni dintre clase sau tipuri o arata relaiile dintre obiecte diagrama strilor (State Diagram) o diagrama de stare arat secvena de stri prin care trece un obiect pe parcursul existenei sale ca rspuns la stimuli, mpreun cu rspunsurile i aciunile realizate de acesta. Pentru proiectare sistemului cercetat au fost realizate mai multe diagrame cu ajutorul instrumentului de proiectare i modelare a sistemelor informatice Enterprise Architect. 3.1.1 Analiza aplicaiei i identificarea cerintelor funcionale Procesele studiate la elaborarea acestei aplicaii: Lucrul zilnic al echipei la un anumit proiect Crearea zilnic a task-urilor i datelor statistice de cum decurge proiectul, la ce stadie a ajuns etc. Feedback-ul lucrtorilor din mai multe firme referitor la managementul lucrului. n plan tehnic, pentru dezvoltare, studierea tehnologiilor noi care permit dezvoltarea unei aplicaii flexibile, usor de dezvoltat, rapide i securizat.

Lista cerinelor fa de arhitectura aplicaiei: Flexibil i uor configurabil pentru diferite companii. Gestionarea accesului securizat la informaie pentru utilizatori externi. Gestionarea accesului la informaie pe roluri (Administrator, Operator) pentru utilizatori interni / angajai. Menu de administrare, de exemplu adaugarea unui nou user, abilitarea unui user existent la diferite pagini ect. Rapiditatea execuiei operaiilor, i anume ncarcarea datelor, salvarea datelor, afiarea datelor, printarea datelor ect. Lista cerinelor funcionale fa de aplicaie: Crearea proiectelor de ctre administratori. Adugarea utilizatorilor cu anumite drepturi de acces de ctre administrator Formarea echipelor care vor fi alocate la proiectul respectiv Createa task-urilor pentru fiece membru al echipei Crearea ticket-urilor cu notificarea, la persoan, echip sau proiect Adugarea comentariilor, imaginilor, fisierelor in formatele prestabilite de administrator Administrarea de fiecare utilizator a profilului sau: limb, avatar, informaie personala, drepturile de acces la informaie Crearea datelor statistice att pentru firm ct i pentru client Expert,

3.1.2 Analiza i Proiectarea arhitecturii sistemului Pentru a satisface cerinele funcionale i arhitecturale impuse sistemului, s -a hotrt crearea unui sistem client server, unde partea client va fi elaborat cu ajutorul tehnologiilor HTML, CSS i JavaScript, partea server va fi elaborat cu ajutorul tehnologiilor PHP, SQL i Apache server, ca limbaj de comunicare ntre partea client i partea server se va folosi limbajul JSON. Acest aspect arhitectural al sistemului il putei observa n figura ce urmeaz:

Fig.1 Aspectul fizic al sistemului. Deoarece se planific ca acest sistem s permit gestionarea accesului la informaie pe roluri, pentru a putea gestiona dinamic acest acces am identificat urmatorii actori pentru sistemul dat: Admin utilizatorii cu acest rol reprezint administratorii sistemului, care au acces la toate paginile sistemului i pot gestiona abilitatile celorlalte roluri.

 Manager n aceast clas de utilizatori intr, project managerii de la companie care se ocup de gestionarea proiectelor, adaugarea task-urilor, adaugarea persoanelor in echip etc. User utilizatorii cu acest rol sunt toi lucrtorii companiei respective, care pot sa vizualizeze nsrcinarile, sa comenteze anunite lucruri, s adauge ticket-uri, sa poata comunica cu echipa sa de lucru etc.

Pentru dezvoltarea acestei aplicaii vom folosi din punct de vedere arhitectural, vom folosi SOFEA, care se descifreaza ca : Service Oriented Frontend Architecture. Am ales aceast arhitectur, deoarece dup prerea experilor, ea este viitorul in web, iar mvc pattern-ul care pina la moment se socotea cel mai bun pattern pentru dezvoltarea structurata a codului unei aplicatii WEB, este greit, i anume de ce: - MVC pattern transmite la partea client html-ul desenat pe partea server; - Este imposibil de folosit aceai aplicaie att pentru calculator ct i pentru telefon, tableta etc. - Modul de lucru este mai ncet deoarece transmite mai mult coninut necesar clientului

Fig.2 Arhitectura Web aplicaiilor.

Fig.3 Partea client a arhitecturii.

Fig. 4 Alocarea proceselor pentru SOFEA

Pentru backend, ca sa putem folisi la maxim arhitectura SOFEA pentru aplicaia noastr, vom folosi RESTFUL API. REST este un stil arhitectural constnd dintr-un set coordonat de constrngeri arhitecturale aplicate pentru componente , conectori , i elemente de date , ntr - un sistem hipermedia distribuit. REST ignor detaliile de imp lementare a componentei i sintax protocol pentru a se concentra asupra rolurilor de componente, a constrngerilor asupra interaciunii lor cu alte componente, precum i interpretarea lor de elemente importante de date. Transferul de stat de reprezentare termen a fost introdus i definite n 2000 de ctre Roy Fielding n teza de doctorat la UC Irvine. REST a fost aplicat pentru a descrie arhitectura web dorit, pentru a identifica problemele existente, pentru a compara soluii alternative, precum i pentru a se asigura c extensiile de protocol nu ar nclca restriciile de baz. Fielding REST folosite pentru a proiecta HTTP 1.1 i Unifo rm Resource Identifiers ( URI ). Stilul arhitectural REST este , de asemenea, aplicat la dezvoltarea serviciilor web ca o alternativ la alte specificatii distribuite - de calcul , cum ar fi SOAP . Pentru a ntelege mai corect arhitectura REST vom analiza Figura 5, care arata relaia dintre client server, metodele de comunicare (transferul de date), Comunicarea cu baza de date etc.

Fig. 5 Arhitectura RESFFUL

3.2. Dezvoltarea modulelor i crearea sistemului informatic Dup analizarea i proiectarea sistemului la etapa anterior nu rmne dect de elaborat pe pai fiecare etap descris mai sus, i anume crearea bazelor de date, crearea RESFTUL API, createa interfeei grafice (UI), si comunicarea dintre ele dupa arhitectura aleasa SOFEA.

3.2.1. Crearea bazei de date Primul pas la elaborarea aplicaiei a fost construirea bazelor de date, care se va numi application_dev cu cu tabele InnoDB, encoding-ul utf8_general_ci. Am ales InnoDB i nu Myisam, deoarece InnoDB permite tranzacii i foreign key i anume tergerea i renoirea n cascada. De fiecare dat cnd nserm ceva, tergem sau nlocuim o nregistrare, va trebui sa verificm i s meninem relaiile. De exemplu dac tergem un printe, toi copiii ar trebui i ei de ters. n InnoDB acest lucru se face automat de ctre motorul de baze de date. Referitor la tranzacii la fel este un lucru foarte important, pentru ca atunci cind avem de rulat un anuit funcional, de exemplu pentru adaugarea unui task, trebuie de scris in mai multe tabele, iar daca la un anumit pas se blocheaza, sau da o eroare, sau dispare internetul, tranzacia permit e pina nu sa produs ultimul pas de modificare in baza de date, sa nu modifice nici intr-un tabel. Mai jos avem afiata schema bazei de date pentru sistemul nostru informational, care const din 32 de tabele i care vor ine toata informaia atit de aplicaie ct i tabele care se ocup de configurare aplicaie, ca de exemplu tabela: project_config_option

Fig 6 Schema bazei de date

3.3.2Dezvoltarea RESTFUL API Pentru dezvoltarea REST API vom folosi un bundle special care se ocupa de acest lucru: "nelmio/api-doc-bundle". El ne permite de a crearea usoara a REST API, cit si documentatia acestuia. Pentru a instala acest bundle in aplicatia noastra, adaugam in fisierul composer.json acest rind de cod: "nelmio/api-doc-bundle": "dev-master", dupa aceasta face update la composer.phar, ca urmare se instaleaza acest bundle la noi in proiect, dupa aceasta adaugam in fisierul AppKernel.php, in functia registerBundles : $bundles = array( ... new ScrumTool\Bundle\ApiBundle\ScrumToolApiBundle(), ); Gata, avem totul necesar pentru a dezvolta REST API-ul nostru, ct i documentaia acestuia. Vom crea pentru fiecare entitate care o avem in baza de date, controllerul sau, care va avea metodele: metoda GET : GET: DELETE DELETE POST PUT url /entity_name /entity_name/id /entity_name /entity_name/id /entity_name/ /entity_name/id functionalitatea - ia toata lista de date - ia un element dupa id - sterge toata listat - sterge un element dupa id - creaza un obiect nou - reinoieste un element duba id

Mai jos vom dezvolta metoda GET pentru entitatea company, ca s vedeam ct de simplu se face REST API, daca folosim acest bundle:

/** * Lists all Company entities. * * @ApiDoc( * * * * * * *) * * @Annotations\QueryParam( * * * * * *) * @Annotations\QueryParam( * * * * *) * * name="limit", requirements="\d+", default="10", description="How many records." name="offset", requirements="\d+", nullable=true, default="0", description="Offset" } section = "Company", resource = true, description = "Lists all Company entities.", statusCodes = { 200 = "Returned when successful" *

* @Annotations\View() * * @param Request $request the request object

* @param ParamFetcherInterface $paramFetcher param fetcher service * * @return \FOS\RestBundle\View\View */ public function indexAction(Request $request, ParamFetcherInterface $paramFetcher) { $offset $limit = $paramFetcher->get('offset'); = $paramFetcher->get('limit');

$em = $this->getDoctrine()->getManager();

$entities = $em->getRepository('ScrumToolCoreBundle:Company')>findBy([], [], $limit, $offset);

$this->info = array( 'offset' 'limit' => $offset, => $limit, => 'Company'

'entityName' );

$this->data = array( 'entities' => $entities );

return $this->createViewResponse(); }

Aceasta bucata de cod este compusa din 2 parti, partea documentativa, pe care o poate vedea user-ul, si partea logica, care se ocupa de acest functional (ia din baza toate companiile i le ntoarce in format JSON). Partea documentativa: este compusa din Annotations, care la prima vedere este doar un comentariu, dar care acest bundle, l interpreteaz ca o documentaie, mai jos vom arta ce a generat i cum arat aceste annotations pentru entitatea company. Primul rnd prezinta routingul cu care va fi accesat API, mai departe sunt aratate 5 metode care au fost descrise mai sus.

Fig. 7 Documentaia pentru metodele GET POST PUT DELETE, pentru entitatea company

Apsm pe prima metod GET, i vedem documentaia pentru aceast metod, ce face metoda, care sunt parametri pentru filtru i ce tip au, status codul pentru succes.

Fig. 8 Documentaia metodei GET Dac apasm butonul Sandbox, se deschide un panel care poate sa simuleze request-ul la server, complectam filtrele i apsm butonul Try.

Fig. 9 Panenul de simulare a request-ului

Dup ce am apasat acest buton, observm aceast imagine, care ne indic, url care sa apelat, status codul, 200 nseamn c requestul sa facut cu succes i responsul de la server n format JSON.

Fig . 10 Response-ul de la server n format JSON

3.3.3 DEZVOLTAREA APLICAIEI Ne-a ramas sa dezvoltam aplicatia pe pasi, partea front-end, vom dezvolta utilizind arhitectura descrisa de mai sus, fiece pagina care o vom crea, vom atasa cite o imagine ca sa vedem ce sa primit si vom comenta rolul acestei pagini si functionalul ei. Pentru partea front-end vom folosi petru design, Css Bootstrap, si pentru buisnes logica backbone js, dupa pattern-ul MVVM. Prima pagina va fi pagina de logare, unde utilizatorul va introduce loginul si parola si va putea intra in aplicatie, aceasta pagina nu despune pagina de inregistrare, pentru ca doar administratorul va da drept de acces la utilizator, primind pe un email loginul si parola, care desigur ca va putea sa o modifice.

Fig. 11 Pagina de logare

Dupa ce ne-am logat, se deschide pagina principala, Dashboard-ul , unde utilizatorul va vedea informatia relatata pe scurt despre proiectele la care a fost alocat, cine ce a modifcat la ele, daca are mesaje, task-uri commentarii referitoare la lucru legat de dinsul etc.

Fig. 12 Pagina principal Urmatoarea pagina este legata de proiecte, scopul principal al acestei aplicatii. Ea ne afiseaza lista de proiecte totale, daca suntem administratori, sau lista de proiecte la care suntem alocati, daca suntem useri simpli. La moment avem un proiect, care este activ, el contine numele lui, descrierea lui pe scurt si statusul lui.

Fig. 13 Lista de proiecte Pentru a crea un proiect nou, selectam din submenu Add project, care deschide o forma cu 4 cimpuri, numele proiectului, decrierea lui, prioritatea acestui proiect pentru companie, si un radion box care ne permite sa alegem daca dorim sa afisam sau nu descrierea acestuia. Complectam toate cimpurile acestei forme si apasam butonul Add project

Fig14 Forma de adaugare a unui proiect nou Dupa apasarea acestui buton, observam in Figura 15, mesajul informativ ca proiectul sa adaugat cu succes, proiectul care l-am adaugat, permisiunile proiectului, care dupa default sunt All , adica se poate de modificat, si un buton Update Permission, care dupa apasarea lui, Figura 16, vedem alt mesaj informatic, care ne anunta ca drepturile de acces asupra acestui proiect sau modificat cu succes. In partea dreapta vedem un panel care ne permite monitorizarea cu accest proiect si statusul proiectului.

Fig15 Pagina de succes de adaugare a noului proiect

Fig 16 Pagina de succes de modificare a drepturilor de acces la proiectul creat

Ne ducem innapoi la lisa cu proiecte, ca sa ne convingem ca proiectu sa adaugat corect si se afla in lista cu proiecte, Figura 17.

Fig17 Lista de proiecte Pe linga acele operatii care ne permite sa monitorizam proiectul, descrie mai sus, mai putem copia proiectul, ce presupune aceasta: Daca dorim da avem rapid, tot priectul cu toata informatia cu care am lucrat la el, crearea taskurilor, ticketurilor, mesajelor, comentarii, fisiere etc. sau pe bucati, adica spre exemplu, numai taskurile de la proiectul respectiv, bifam acea casuta cu taskuri si ca urmare avem copiate toate aceste taskuri, care le putem adauga la alt proiect sau sa le dam clientului Figura 18. Pentru a fi mai usor pentru useri sa vada lista de proiecte, am adaugat si functionalul de a adauga logo la proiect Figura 19.

Fig 18 Copierea unui proiect

Fig 19 Adaugarea logo la proiect

Pentru a putea comunica mai usor in echipa sau la proiect, am creat menul Messages care ne va vizualizarea mesajelor primite si crearea mesajelor. La accesarea submenului Add message, se deschide o forma cu titlu mesajui, continutul lui si milestone, daca dorim. Complectam aceasta forma (Figura 20) si apasam butonul Add message. Dupa apasarea lui ne apare pagina de succes ca mesajul sa adaugat (Figura 21) si mai jos mesajul respectiv, cu titlul, de catre cine a fost creat, data cind a fost creat, contextul mesajului pe scrurt si butonul Read more, numarul de comentarii la acest mesaj, si doua butoate pentru persoana care a creat acest mesaj si administrator, Read si Delete

Fig 20 Forma de adaugare a mesajelor

Fig. 21 Pagina de succes, de adaugare a mesajului O alta functionalitate foarte importanta la dezvoltarea proiectului, putem sa o numit cea mai importanta, este taskurile, orice proiect este impartit pe taskuri si subtaskuri, fiece persoana care lucreaza la proiect va avea anumite taskuri care vor avea la rindul lor o anumita perioada cind persoana data va trebui sa le rezolve. Vom adauga un task nou, la proiectul creat mai sus, pentru asta accesam menu Add task, ca urmare se deschide forma de adaugare a unui task nou Fig. 22, o complectam cu informatia anumita, adaugam subtaskurile la acest task, alegem persoana cui dorim sa ii atasam acest task creat si apasam butonul submit.

Fig. 22 Forma de creare a unui task

Ca urmare se deschide pagina se succes Figura 23, cu mesajul informativ ca taskul sa adaugat, si taskul respectiv, care consta din denumirea lui, bara de progres, care odata cu rezolvarea unuia din subtaskuri ea calculeaza in procente cit a mai ramas si cit sa rezolvat, mai jos este timpul cind va trebui de inchis (rezolvat). Lista de subtaskuri, fiecare avind butoanele de copiere, editare, butonul de marcare ca complet, de mutare.

Fig. 23 Pagina de succes de adaugare a unui task Milestone-ul este un eveniment care primete o atenie deosebit. Acesta este de multe ori pus la sfritul unei etape pentru a marca finalizarea unui pachet de lucru sau faz. In Figura 24 este vizualizata forma de adaugare a unui milestone, iar in Figura 25 este pagina de succes de adaugare a unui milestone, care contine tiltul, cerintele, data cind treb de facut si trei butoane, redactare, stergere si marcare ca complet.

Fig. 24 Forma de adaugare a unui milestone

Fig. 25 Pagina de succes de adaugare a unui milestone

Pentru a lucru mai mai usor cu proiectele, adica atunci cind este nevoie de atasa o lista de taskuri de la client, sau o imagine foto, am creat menu Files. Vom incerca sa a adaugam o imagine pentru testare Figura 26, alegem fisierul, dam drepturile de acces, scriem descrierea fisierului si apasam butonul Save.

Fig. 26 Forma de adaugare a unui fisier Dupa salvarea fiserului, apare pagina de succes, care afiseaza datele despre fisierul incarcat, thumbnail daca vom incarca imagine, butonul Download, pentru ca persoanele sa le poata descarca in calculatoare , butonul Edit, Delete, Add revisio, si comentariile la fisierul dat.

Fig.27 Pagina de succes de adaugare a unui fisier

O alta parte importanta pe care am inclus-o in aceasta aplicatie, este create ticketurilor. Adica cind o persoana are anumite probleme de ordin tehnic, spre exemplu nu ii lucreaza calculatorul, trebuie de instalat o programa noua etc. Persoana creaza un ticket (Figura 28) in care indica ce probleme are, indica prioritatea, din ce categorie face parte aceasta problema. Dupa apasarea butonului submit, se deschide o pagina noua, care confirma ca ticketul sa adaugat cu succes, (Figura 29) si mai vedem mai jos informatia despre ticket, iar labelul in care se afla acest ticket are culoarea galbena, pentru a sti ce inseamna aceasta culoare, ne uitam in partea dreapta unde este o Legenda cu 4 culori, si fiece culoare indica prioritatea ticketului creat.

Fig. 28 Forma de adaugare a unui ticket

Fig. 29 Pagina de succes de adaugare a unui ticket

Pentru a ne mai convinge o data ca tot ce am adaugat mai sus sa inregistrat cu succes, accesam iarasi pagina principala (dashboard), si vedem ca tot ce am adaugat este afisat in pagina.

Fig. 30 Pagina principala a aplicatiei A mai ramas doar sa aratam cum se adauga mai multi useri, la un anumit proiect. Pentru aceata accesam Company->Add User, care deschide o forma de adaugare a unui user nou, complectam forma cu datele despre userul nou, si dupa apasarea butonului submit, userul va primi pe email un mesaj informativ ca sa inregistrat in aplicatia noastra, si loginul si parola pentru a se punea loga.

Fig.31 Forma de adaugare a unui user nou Pasul doi, este setarea drepturilor de acces pentru userul creat(Figura 32), pe partea orizontala sunt afisare drepturile de acces, iar pe partea verticala, proiectele la care este atasat userul, bifam ce credem ca va avea nevoie userul nou, si apasam butonul Update Permission, care urmare se deschide pagina de succes de adaugare a userului nou.

Fig. 32 Panelul de drepturi de acces pentru userul nou

Fig 33. Pagina de succes de adaugare a userului nou

CONCLUZII