mpsporoiectgrup - erp

8/21/2019 MPSporoiectgrup - ERP

1/40

Managementul ProiectelorSoftware

Sistem de planificare a resurselor uneintreprinderii software

Punoiu DanielPintea Codrina Maria

Srbu Roxana LarisaIon Silviu Mihai

Radu Marian

Universitatea din Bucureti Facultatea de Matematica i Informatic


2/40

Bucuresti

2014

Cuprins

A. Business case

1. Nume proiect: Sistem de planificare a resurselor unei ntreprinder software(ERP)2. Obiective3. Motivaie4. Rezumat

4.1. Descrierea produsului4.2. Descrierea soluiei4.3. Descrierea planului de implementare

5. Detalii privind soluia propus5.1. Analiza SWOT5.2. Soluii similare5.3. Paralela cu soluii concurente5.4. Posibile achiziii: observaii despre furnizor5.5. Tehnologii folosite5.6. Integrarea cu alte proiecte/operaii ale companiei5.7. Riscuri posibile

6. Impactul proiectului7. Costuri

7.1. Categorii de costuri si estimari7.2. Analiz cost/beneficiu (ROI - Return of investment, payback period) II.

B. Planificarea proiectului

1. Identificarea scopului i obiectivelor proiectului1.1. Identificarea obiectivelor i metode de msurare a eficienei n atingerea lor1.2 Stabilirea unei autoriti a proiectului1.3. Identificarea prilor interesate de proiect1.4. Redefinirea obiectivelor n urma stabilirii prilor interesate1.5. Stabilirea metodelor de comunicare ntre toate prile implicate

2. Infrastructura proiectului2.1 Stabilirea relaiei dintre proiect i planificare strategic2.2 Identificarea standardelor i procedurilor2.3 Identificarea echipei

3. Analiza caracteristicilor proiectului3.1. ncadrarea proiectului n funcie de obiective sau de orientarea sa ctre

produs3.2. Identificarea riscurilor


3/40

3.3. Identificarea cerinelor utilizatorilor3.5. Stabilirea unei metodologii de dezvoltare3.6. Estimarea necesarului de resurse

4 . Identificare produselor i activitilor asociate proiectului4.1 Identificarea i descrierea produselor asociate proiectului4.2 Documentarea fluxului de producie4.3 Recunoaterea instanelor produsului4.4 Reeaua de activitate ideal a proiectului4.5 Factori ce determina modificarea diagramei de activitate ideal a proiectului

5. Estimarea efortului pentru fiecare etap5.1 Estimri bottom-up5.2 Revizuirea planului pentru crearea unor activiti controlabile

6. Identificarea riscurilor posibile in fiecare etap6.1. Identificarea i estimarea riscurilor posibile in fiecare etap6.2. Modaliti de reducere a riscurilor n fiecare etap6.3. Revizuirea planului n funcie de riscurile posibile

7. Alocarea resurselor

III. Managementul codului (versioning control)


4/40

A.Business case

1. Nume proiect: Sistem de planificare a resurselor unei intreprinderi

software(ERP)

2. Obiective

Obiectivul acestuiproiect este de a realiza o platform web pentru gestiunea activitilor din cadrul

unei firme de dimensiune mic sau mijlocie. Scopul ERP este s asigure transparena datelor n cadrulunei organizaii i s faciliteze accesul la ele ntr-un mod ct mai optim i user-friendly. Avantajele

oferite de sistemele ERP, n afar de simpla gestiune a datelor este generarea de ieiri standardizate,

prin intermediul rapoartelor, i altor documente cu form i coninut predefinit (facturi, comenzi,

chitane, contracte etc). n mare un utilizator, n afara de a accesa datele, poate s i exporte diferite

tipuri de documente specifice aplicaiei.

3. Motivaie

ntr-o firm mic unde numarul de angajai este destul de redus astfel nct administrarea resurselor

nu este o problem, un sistem de tip ERP anticipeaz ngreunarea proceselor de administrare i

creaz bazele unei afaceri prospere. La polul opus, ntr-o lume din ce n ce mai automatizat, o

ntrepridere de dimensiu mari are nevoie de un sistem de gestiune al proceselor.

4. Rezumat

4.1. Descrierea produsului

n primul rnd, sistemul va fi de tip multi-utilizator, permind adugarea de utilizatori

suplimentari pe parcursul utilizrii. De asemenea va fi integrabil, adic va permite preluarea datelor

i exportul lor n diferite formate, i flexibil, se va mula pe orice tip de activitate. Deci poate fi folosit

n egal msur att pentru o firm de web ct i pentru una de croitorie.


5/40

Totui, n vederea ndeplinirii obiectivelor, aplicaia va avea mcar o procesare specific

activitii gestionate. Un grad mare de generalitate poate ngreuna ulterioarele customizri. Este bine

ca un sistem ERP s fie ct mai general, dar rigiditatea exagerat intr n conflict cu nevoia de

flexibilitate a aplicaiei.Utilizatorul primar al sistemului va fi de tip administrator i este reprezentat de un angajat de

resurse umane. Pe parcurs pot fi adugai i ali utilizatori precum manager, administrator de sistem

sau dezvoltator.

Administratorul va introduce in sistem, prin intermediul aplicatiei, datele de lucru precum

funciile angajailor, tipurile de clieni, etc. Mangerul sau dezvoltatorul va putea lucra cu aceste date

i va putea introduce propriile informaii, dar nu va avea acces la informaiile de sistem.

Utilizatorul de tip contabil va introduce n sistem clienii companiei. Va putea genera o

factur cu suma de plat i data scadent. n functie de plaile nregistrate tot de acesta n sistem,

statusul facturilor se va modifica corespunztor. Pentru fiecare plat se va putea elibera o chitan.

Principalele module i funcionaliti ale aplicaiei ERP necesare unei companii IT sunt

prezentate detaliat mai jos.

1. Seciune Operaional- pentru susinerea activitii operaionale i implementarea

fluxurilor n companie.

2. Seciune financiar i contractual pentru gestionarea situaiilor clienilor, facturi,

contracte, condiii i termeni de plat

3. Seciune CRM pentru managementul activitilor de presales, managementul incidentelor

i al solicitrilor i managementul relaiei cu clienii4. Seciune pentru Managementul Documentelor pentru organizarea, stocarea, i

cutarea documentelor.

5. Sectiune access Clieni pentru a oferi clienilor si transparen n procesul de

procesare a documentelor.

1. Sectiune Operational - functionaliti i cerinte generale

Sistemul informatic de tip ERP va trebui sa satisfac urmatoarele cerine generale:

Autentificarea se va face o singur dat pentru tot sistemul informatic (ERP) (single sign-on).

Sistemul informatic va funciona cu un sistem de gestiune al bazelor de date de ultim

generaie, capabil s stocheze volume mari de tranzacii i care s aib un timp mic de

rspuns.

Sistemul informatic va avea modulele integrate ncat informaia s fie introdus o singur

dat si ntr-un singur loc.


6/40

Autentificare / Gestionare Utilizatori

Fiecare utilizator se autentific prin username i parol

Drepturile de acces vor fi configurabile iar prin intermediul lor se vor putea gestiona

drepturile de citire, modificare i stergere.

Utilizatorii vor avea asociate roluri n sistem Detaliile personale vor putea fi modificate de ctre fiecare utilizator n parte cu aprobarea

managementului

Pentru fiecare utilizator va exista o legatur cu sectiunea Proiecte / Clieni / Contracte

Fiecare utilizator va avea acces doar la datele i informaiile care l privesc

Cataloage / Clasificri

Gestionare baza de date de parteneri

Gestionare baza de date de produse si servicii

Clasificare serviciilor si a produselor pe minimum 3 nivele ierarhice

Posibilitatea introducerii de studii de caz si produse / servicii concurente pentru evaluare

Configurare stuctur organizatoric

posibilitatea de defininire a mai multor locaii pentru birourile companiei

posibilitatea de definire a mai multe departamente, puncte de lucru

Parteneri (Clienti, Furnizori, Instituii publice, Colaboratori)

gestionarea informaiilor despre clieni, furnizori, instituii publice si colaboratori att

persoane fizice ct i persoane juridice (date de identificare, persoane de contact, adrese,

sursa de informaii, domenii de activitate, note)


7/40

validarea automat a corectitudinii datelor (validare automata pe iruri de caractere CUI,

IBAN, TVA - pentru parteneri strini)

Exemple de cazuri de utilizare.


8/40

4.2. Descrierea soluiei

Gestionarea ERP propus va fi dezvoltat n framework-ul de CakePHP.

CakePHP este un framework open-source scris n limbajul PHP, modelat dup conceptul

platformei de progamare Ruby on Rails i distribuit cu Licena MIT. Numele de Cake a fost folosit cuscopul de a arta stratificarea acestui frameworki felul n care sunt mprite sarcinile ntre cele trei

mari componente ale lui: Model View Controller.

Acest framework i furnizeaz dezvoltatorului web toate instrumentele necesare pentru a

ncepe implementarea. Mai clar, programatorul trebuie doar s realizeze partea de planificare logic

a aplicaiei i design-ul web al paginilor. Astfel se marete viteza cu care se poate implementa,

calitatea i securitatea codului.

Componentele arhtecturii MVC au fiecare cate un rol: Model-ul manipuleaz operaiile logice

i informaia primit de la rangul superior (baza de date) pentru ca aceast s aib o form uor de

neles.View: vizualizarea este forma grafic n care sunt transpuse datele primite. n cazul paginilor

web este formatul html n care o s apar pagin pe browserul utilizatorului. Controller controleaz

accesul la aplicaie. El este cel prin care trec informaiile nainte de a ajunge la utilizatori cel care d

caracterul dinamic al coninutului site-ului

Baza de date folosita de aplicatie este MySQL si va fi gazduit pe un server Apache

gazduireonline.ro pe care se va realiza versionare prin SVN. Dupa care va fi mutat pe un server intern

al companiei.

4.3. Descrierea planului de implementare

n implementarea aplicaiei se vor parcurge cel puin urmtoarele etape:

1. Analiza fluxului de informaii i a proceselor economice i tranzactionale

specifice companiei

i evaluarea infrastructurii suportului informatic pentru

nregistrarea, stocarea

i manipularea datelor

i determinarea necesarului pentru

implementarea aplica

iei ERP.

Subactivitile specifice sunt:

1.1 determinarea structurii organizaionale i a nivelelor ierarhice,

1.2 determinarea tipurilor de tranzacii specifice,

1.3 determinarea fluxurilor de documente specifice,


9/40

1.4 determinarea proceselor interne specifice i determinarea proceselor

economice specifice,

1.5 determinarea infrastructurii hardware existente,

1.6 evaluarea structurii existente,

1.7 determinarea necesarului de echipamente n vederea implementriisistemului ERP .

3 Design - identificarea necesit

ilor companiei n urma analizei n vederea

dezvoltrii aplica

iei ERP Subactivitile specifice sunt: indentificarea nevoilori necesitilor,

transpunerea nevoilor i necesitilor identificate n specificaii de implementare, elaborarea

calendarului de implementare.

3. Dezvoltare

i testare aplica

ie ERP n urma acestor procese, va fi dezvoltat aplicaia

ERP pentru proiectul prezentat.

4. Trecerea aplicaiei n producie dup verificarea i testarea aplicaiei, utilizatorii

platformei se vor putea folosi de serviciile acesteia. n aceast etap pot s apar probleme sau

cerine suplimentare care vor fi rezolvate de ctre furnizorul aplicaiei.

Darea n exploatare

5. Darea n func

iune a aplicatiei ERP odat aplicaia testati recepionat, va fi lansat

live.

6. Formare personal intern utilizare

i mentenan

aplicatiei ERP - n utilizarea unui

sistem integrat de ERP este necesar instruirea utilizatorilor aplicaiei cti a celor care se vor ocupa

de mentenana acesteia.


10/40

5. Detalii privind soluia propus

5.1. Analiza SWOT

Strengths (Puncte tari - intern):

gestionarea plilor i ncasrilor la un moment exact de timp

generare de rapoarte saptamanale, lunare, trimestriale sau anuale

notificri: trecerea termenului de scaden, expirarea contractului, expirarea termenului

limit pentru un proiect.

se poate integra cu sistemele partnerilor

Weaknesses (Puncte slabe - intern):

pentru utilizarea acestuia este nevoie de instruirea personalului

structura relativ rigid n contextul proceselor de business diferite

posibile probleme de securitate

amortizarea lent a investiiei

Opportunities (Oportuniti - extern):

posibilitatea unei finantari europene

Threats (Ameninri - extern):

concurena mare pe acest tip de aplicaie

diferite probleme ce pot aprea la customizarea aplicaiei pe tipul de companie

5.2. Produse similare

Din pcate exist multe companii de IT care au dezvoltat soluii ERP, i multe companii care

folosesc deja soluiile acestea.

Totui ele folosesc aceleai principii de functionare: sunt adaugai n sistem clieni i furnizori

fiecare cu un status de activ sau inactiv. Apoi exist posibilitatea de a adauga facturi pe aceste entiti

i a compara plaile efectuate ctre furnizori cu ncasrile de la clieni.

Dei exist multe soluii ERP actuale pe pia, urmatoarele sunt cele mai cunoscute i cele mai

cutate pe diferite motoare de cutare:

1. ERP-ul de la Crystal Vision Software http://www.crystalerp.com

ERP-ul a fost dezvoltat pentru companiile mijlociii mari. n afar de ERP-ul propriu zis, Crystal Soft

a dezvoltat i un modul intreg de analiz a datelor introduse n sistem cu rapoarte variate ce pot fi

customizate pentru tipul de bussiness. De asemenea are numar nelimitat de useri pe o singur licen.
http://www.google.com/url?q=http%3A%2F%2Fwww.crystalerp.com&sa=D&sntz=1&usg=AFQjCNFw15ggEA8v4mPxA_U1Mjqd7F6RQw


11/40

Soluia a fost implementat n Oracle Internet Development Suite folosind o baza de date relaional.

2. Charisma ERP http://www.charisma.ro

Soluia a fost construit de TotalSoft i a avut la baz soluia de contabilitate pentru o firm de

farmaceutice: conine pe lang modulele obiligatorii oricarui ERP i module pentru: Achiziii,Managementul bugetelor, Proiecte, Task-uri, Credite Web i Web Leasing. Este folosit de peste 15

companii mari printre care BMW, Germanos, Eurolines, Farmexert i Cosmote.

3. ERP SAP Bussiness One http://www.sysinconsult.ro/

Aceasta soluie dezvoltat de System Innovation Romania vine cu un plus datorit modului de

management al relaiilor cu clienii. Este folosit de aproximativ 40.000 de companii din ntreaga

lume, dar este mai rigid i o posibil customizare poate s coste mai mult dect pentru alte soluii.

5.3. Comparaia cu alte soluii

Aplicaia ERP va fi n prima faz la fel de modularizat ca cele prezentate mai sus, dar nu va

include i modulele de Credite Web i Web Leasing, care pentru posibilii clieni nu au nici un folos.

Totui va include pe lang modulele de bazai pe cele necesare raportrii situaiei financiare i cash

flow-ul companiei.

5.4. Posibile achiziii: observaii despre furnizor

Posibili clieni ce vor folosi aceast aplicaie:

ETA2U (http://www.eta2u.ro) - o firm care ofer pe lang servicii i produse electronice

pentru firme de IT i nu numai. Ei au deja un ERP dar doresc s integreze pe lang el i un

sistem de rapoarte

BELLSYNERGY (http://bellsynergy.com) este de asemenea o companie care are nevoie de o

soluie de ERP dei nc se decid dac s aleag o versiune mai rigid de la un furnizor mai

mare sau soluia customizabil de la noi.

5.5. Tehnologii folosite: compatibilitate cu hard/software

Aplicaia ERP este o aplicaie de tip web ce poate fi vizualizat pe orice browseri va avea de

asemenea i un layout responsive aadar va putea fi accesat i pe dispozitive mobile i tablete. O

aplicaie web fa de una windows are avantajul ca nu depinde de sistemul de operare utilizati nici de
http://www.google.com/url?q=http%3A%2F%2Fbellsynergy.com&sa=D&sntz=1&usg=AFQjCNE9HQWKvCkYkRhR6uNl4WRkoKC1twhttp://www.google.com/url?q=http%3A%2F%2Fwww.eta2u.ro&sa=D&sntz=1&usg=AFQjCNHO7MVgk9s1tpHLpC2jm4SDsH_qPAhttp://www.google.com/url?q=http%3A%2F%2Fresidences.aston.ac.uk%2Feaccom%2F%2Flogin%2Fstart.do&sa=D&sntz=1&usg=AFQjCNEGq4rfYCZdVPj1De70JrOguuPLUghttp://www.google.com/url?q=http%3A%2F%2Fresidences.aston.ac.uk%2Feaccom%2F%2Flogin%2Fstart.do&sa=D&sntz=1&usg=AFQjCNEGq4rfYCZdVPj1De70JrOguuPLUghttp://www.google.com/url?q=http%3A%2F%2Fwww.sysinconsult.ro%2F&sa=D&sntz=1&usg=AFQjCNHKuhT97_c1WunxpF4Laj-C4RhZOAhttp://www.google.com/url?q=http%3A%2F%2Fwww.charisma.ro&sa=D&sntz=1&usg=AFQjCNEevP-ORM_3pzRj0SVy3G3cqjc4hg


12/40

software auxiliar n afar de browser-ul de internet. Limbajul folosit este PHP mpreuna cu

framework-ul de CakePHP.

Framework-ul de Cake ofer posibilitatea construirii unui pachet de modele, Controller-e i

Vizualizri, i, apoi, exportul lor ca un pachet ce poate fi folosit ca i plugin pentru o aplicaie.Aplicatia ERP o sa foloseasca urmatoarele plugin-uri:

1. ACL (Access Control Lists)

Componenta de ACL este adesea criticat, dar n acelai timp este i cea mai folosit dintre

plugin-urile pentru Cake. Pentru cineva care nu a mai folosit vreodat un sistem de gestiune a

accesului la paginile site-ului, aceast metod de acces poate fi destul de confuz.

ACL-ul este un instrument puternic n dezvoltarea aplicaiilor ce au la baz grupuri de de

utlizatori i diferite restricionri pentru acetia. De exemplu exist grupurile: administratori,

salariai i clieni. Un administrator are acces la toate operaiile, salariatul poate vizualizai edita o

anumit categorie de documente i clientul poate doar vizualiza.

ACL-ul gestioneaz dou componente: partea care vrea lucruri i parile care sunt dorite. n

ACL, partea care vrea lucruri (n general userii) este denumit AROs (Access Request Objects) i

partea care este dorit se numete ACOs (Access Control Objects). Entitile implicate nu sunt mereu

persoane/user. Se poate limita accesul la o anummit seciune cnd aciunea vine de la un controller.

ACOs poate fi orice controller, orice aciune, orice funcie.

n esen ACL-ul decide ce ARO are acces la un ACO. Dar trebuie reinut faptul c ACL-ul nu este

echivalent cu componenta de autentificare. Componenta de autentificare este inclus ncomponentele default ale framework-ului i conine date despre cel care s-a autentificat. Scopul

plugin-ului vine dup ce un utilizator s-a logat i reprezint ce face user-ul dup acest pas.

Exis moduri de a ocoli necesitatea componentei ACL, dar asta ar nsemna ca toate restriciile

s se fac manual, n Controller, pentru fiecare pagin n parte. Acest lucru este costisitor ca timpi

ngreuneaz ulterioare modificari ale codului.

2. Uploader

Plugin-ul Uploader a fost creat pentru a ncrca fiiere pe server. Fiierele ncrcate pot fi de

orice tip.

Ceea ce face pluginul de Uploader special este procesarea pozelor ncrcate. Transformrile

care se pot aplica pe imagini sunt multiple. Se pot genera alte imagini (cum ar fi thumbnails) se pote

modifica dimensiunile imaginii, se pot decupa poriuni din ea sau se poate aplica o stampil

(watermark).


13/40

3. Componenta Auth (Authentication)

Autentificarea i autorizarea utilizatorilor este o parte normal a oricrei aplicaii web. n

CakePHP componenta Auth ofer o metod uoar pentru ndeplinirea acestei operaii. Astfel

procesul de indetificare a userului (prin username i parol) se face automat, dac tabela de

utilizatori a fost construit n conformitate cu conveniile framework-ului.

4. Componenta Ofc (Open Flash Chart)

n timp ce componenta de autentificare face parte dintre componentele default ale

framework-ului, componenta Ofc trebuie adugat la aplicaie manual. Acesta componenta

construieste grafice bazate pe orice set de date si parametrii care specifica cum vor fi asezate in

pagina aceste date. De exemplu se poate specifica tipul de vizualizare a graficului: Multiple_bars, sub

forma de plcint (pie) sau bar (bar)

5. Vendor de KeywordPositionOnGoogle

Vendor-ul KeywordPositionOnGoogle se ocup de aflarea rangului unei pagini n ierarhia de

cutare google; mai clar pageRank-ul pentru un set de cuvinte cheie. Dac site-ul nu se afl ntre

primele 30 de pagini, atunci se va returna automat un numr foarte mare care va fi echivalent cu

infinit.

6. Vendor de construire fi

iere PDF

Tot o component open source implementat pentru framework-ul de CakePHP este

componenta TCPDF. Cu ajutorul ei se pot crea fiiere cu extensia pdf. Aceast component va fi fostfolosit la exportarea facturilor de client, a chitanelor si a rapoartelor n format pdf.

5.6. Integrarea cu alte proiecte/operaii ale companiei

Aplicatia fiind construita pe module astfel fiecare modul putand fi folosit separat cu o aplicatie

deja existenta, este usor de integrat.

Modulul de rapoarte a fost dezvoltat pentru a lua datele dintr-o tabela de view care aduna

datele de la diferite alte tabele. Asadar nu conteaza sub ce forma sunt stocate datele pentru o solutie

anterioara, cat timp acestea sub translatate corect in vizualizare.

Acelasi lucru se poate face pentru toate modulele: cel de Client, Furnizori, Facturi, Chitante s.a


14/40

5.7. Riscuri posibile

Riscurile ce le presupune implementarea unei astfel de aplicaii sunt mari, deoarece gestiuneaplilor i aproximarilor facute n aplicaie pot s fie eronate. De asemenea exist anumite proceduricontabile ce difer de la companie la companie. Exist companii care percep TVA la ncasare. Sau

firme precum cele farmaceutice care percep un TVA de 9% n loc de 24%Sistemul va fi testat nainte de a intra n folosin.

6. Impactul Proiectului

Rezolvari aduse prin proiect la diferite probleme ntampinate de companiile care nu utilizeaz

un sistem ERP:

Problema Solu

ia

Editarea manual a unei facturi Factura este generat automat

Gestionarea termenelor de plat Un sistem avansat de filtrare, care alegefacturile al cror termen de plat a fost depaitsau urmeaz sa fie depit n urmatoarele zile

Gesionarea deadline-urilor pentru proiecte/activiti

O listare a proiectelor i activitatilor ce seapropie de termenul de livrare

Rapoarte fcute manual de activitai pentruclieni

Generarea automat a rapoartelor de activitipe o perioad bine definit

Rapoarte de vnzri fcute manual, trecnd nraport toate facturile ncepnd de la o anumitdat

Generarea automat a rapoartelor de vnzri

Cautarea manual a contractelor/anexelorpentru client/furnizor

Descarcarea contractului/anexei n format pdfdirect din aplicaie.

Cautarea unei facturi numai cnd setiu ctevadate despre ea.

Un motor de cutare cu diferite filtre

Chiar i cu aceste noi caracteristici care mbuntesc operaiile financiare fcute ntr-o

companie, procedurile rmn aceleai:

Procedura Procedura automatizat

Venirea unui client Introducerea acestuia n sistem cu datele necesare

Semnarea unui contract cu un client Adugarea contractului ca i fiier pe pagina clientului

Venirea unui furnizor Introducerea acestuia n sistem cu datele necesare


15/40

Semnarea unui contract cu un furnizor Adugarea contractului ca i fiier pe pagina furnizorului

Crearea unei facturi de client/ furnizor Adugarea unei facturi n sistem specificndu-se icontractul pe baza cruia este facut factura.

Stabilirea unui proiect de lucru Adugarea unui proiect pentru client

Stabilirea task-urilor (activitilor) peun proiect

Adugarea unui task pe proiect, i al timpului de lucrualocat acelui task.

7. Costuri

7.1. Categorii de costuri si estimari

Dezvoltarea infrastructurii TIC i a dotrilor companiei prin mbuntirea reelei existente

prin achiziionarea unui server, cinci calculatoare desktop, ase monitoare, dou tablete, o

imprimant multifuncional, trei UPS-uri, un router, dou licene sisteme de operare calculatoare, o

licen sistem de operare server, o licen software profesional creare i editare imagini, o licen

software profesional grafic vectorial, un pachet licene antivirus, o licen software profesional

grafic dtp i print, o licen mediu de dezvoltare aplicaii software, patru licene suite programe de

birou

Achizitie (detaliat pentru fiecare categorie de

cheltuieli)

Pret

unitar

Nr. zile Total

Aplicatie ERP - analiza 750 15 11250

Aplicatie ERP - Design 780 20 15600

Aplicatie ERP - dezvoltare si testare 900 90 81000

Aplicatie ERP -implementare 800 30 24000

Aplicatie ERP -trecere in productie 900 10 9000

140850


16/40

7.2. Analiz cost/beneficiu (ROI - Return of investment, payback

period)

Aplicaia nu va produce venituri, amortizarea realizndu-se ntr-o perioad de timp

ndelungat prin economisirea produselor de tip consumabil i a valorificrii timpului.

ROI = (Venituri in urma investitiei Suma investita) / Suma investita


17/40

B.Planificarea proiectului

1.1. Identificarea obiectivelor i metode de msurare a eficienei n

atingerea lor

Obiectivul general al aplicaiei este gestionarea activitilor economice ale unei interprinderi,

obiectiv ce poate fi divizat astflel:

evidenta serviciilor oferite de firma si organizarea lor in grupuri

nregistrarea facturilor ataate clienilor si furnizorilor

atentionarea clientilor si furnizorilor cu privire la starile facturilor

gestionarea contractelor stabilite cu clienii si furnizorii

gestionarea plilor salariilor ctre angajai

optimizare SEO a proiectelor clientilor

generarea chitantelor atasate facturilor aferente

Eficiena atingerii obiectivelor stabilite se va msura prin evaluarea factorilor urmtori:

numarul facturilor platite la timp de catre clienti prin atentionarea acestora

consumul redus al resurselor materiale de catre firma (preccum harita)

numarul minim de erori al corectitudinii informatiilor folosite pentru asocierea dintrefacturi, servicii si contracte

evidentierea statisticilor cu privire la profitul firmei

partea de SEO: rangul site-ului clientului respectiv in top-ul rezultatelor Google si numarul de

vizualizari ale acelui siteului

1.2 Stabilirea unei autoriti a proiectului

Autoritatea proiectului va fi deinut n ntregime de personalul autoritar al firmei carefolosete acest produs, de regul eful interprinderii. Acesta va furniza parol de administrator

iniiala i va putea efectua operaii critice n sistem precum corectarea anumitor greeli efectuate de

angajai, introducerea unei noi categorii de servicii,crearea oricarui tip de utilizator, mai succint,

toate operaiile care se pot efectua din pagin de administrator al aplicaiei.


18/40

1.3. Identificarea prilor interesate de proiect

Proiectul este realizat pentru a uura munca de gestionare a activitii unei interprinderi.

Prin urmare, aceasta implic o reea important de persoane interesate precum:

personalul firmei, mai precis angajaii care sunt scutii de prelucrarea informaiilor pe hrtie clienii care pot afl informaii despre plti i cei care vor s-i otimizeze site-urile

personalul de management al firmei prin verificarea statusului profitelor indicate de grafice

1.4. Redefinirea obiectivelor n urma stabilirii prilor interesate

Din punct de vedere al administratorului:

definirea conturilor diferitelor tipuri de utilizatori precum ali administratori, manageri decont i conturi de clieni sau furnizori

modificarea i adugarea serviciilor i categoriilor de servicii

modificarea i adugarea facturilor clienilor i furnizorilor

notificarea clienilor i furnizorilor prin comentarii asupra facturilor

modificarea i adugarea contractelor i anexelor contractelor care se stabilesc ntre client i

firma cu privire la abonarea la un serviciu oferit

vizualizarea statisticilor privind profitul firmei

optimizarea SEO a proiectelor corepunzatoare clienilor

vizualizarea evoluiei popularitii unui proiect

generarea chitantelor pentru a dovedi plata facturilor

Din punct de vedere al managerilor de cont:

adugare client i datele aferente acestora

editare client

Din punct de vedere al contabililor:

opiunea de logare n sistem vizualizarea facturilor propri

aduagare factur i setare dat scaden i serviciile/produsele prestate/oferite mpreun cu

costul acestora.

editare facturi n cazul n care aceast a fost nregistrat n sistem n mod eronat.

nregistare o plata a unei facturi


19/40

eliberare de chitan pentru o factur

aduagare de contracte, anexe i ataamente

editare contracte, anexe

Din punct de vedere al clientilor si al furnizorilor:

optiunea de a se loga in sistem vizualizarea abonarilor la serviciile firmei prin contracte

vizualizarea starii facturilor aferente contractelor (platit-verde, neplatit-rosu)

vizualizarea comentariilor atasate la o factura de catre contabil

1.5. Stabilirea metodelor de comunicare ntre toate prile implicate

Prile implicate sunt: administratorul firmei (autoritatea principal), analitii (personalul

contabil care va valida corectitudinea proiectului), programatorii (personalul calificat in domeniul

IT care dezvolta produsul).

Comunicarea se va face pe mai multe cai:

comunicare oral: ntlniri sptmnale ntre prile implicate

email

Trello boards (organizarea task-urilor se va face folosind tool-ul trello.com )

2. Infrastructura proiectului

2.1 Stabilirea relaiei dintre proiect i planificare strategic

Pentru ca proiectul s i ating scopul, acesta trebuie s simuleze procesul zilnic de

funcionare a firmei fr a pierde consistea datelor. De asemenea, aplicaia dezvoltat trebuie s

asigure securitatea informaiilor prelucrate deoarece acestea au un grad de confidenialitate ridicat.

Astfel se poate ntocmi un algoritm care descrie procesul de derulare a ntreprinderii de-a lungul

funcionarii sale (n cadrul unei perioade prestabilite de conducerea ei).

Paii componeni ai acestui algoritm sunt:

n prima instana, se definesc parametrii economici i informativi ai firmei respective,

precum informaii legate de nume, TVA-ul curent, localizarea firmei, contul bancar s.a

dup care se trece la definirea categoriilor de servicii precum i a serviciilor puse la

dispoziie clienilor, la care acetia pot intocmi contracte


20/40

n pasul urmtor se contorizeaz furnizorii necesari firmei pentru a putea oferi anumite

servicii

mai departe, definirea clienilor interesai de serviciile oferite prin crearea unui cont client

pentru fiecare

pentru un client, stabilirea contractelor i anexelor corespunztoare cu privire la abonarea laun serviciu

ct timp firma poate oferi serviciile anexate n cadrul contractelor, se introduc facturi

aferente acestora pentru fiecare client n parte la intervalul stabilit n contract (de obicei

lunar)

la plata facturilor de ctre client, algoritmul avanseaz la pasul introducerii chitantelor care

confirm legal incasarea sumei de bani

dac un client cere un serviciu de optimizare SEO, se trece la definirea paramentrilor de

monitorizare i optimizare a site-ului respectiv

paii de plata a facturilor se reiau pentru gestionarea economic a furnizorilor.

2.2 Identificarea standardelor i procedurilor

Procedurile ce vor fi urmrite pe parcursul dezvoltrii aplicaiei:

1. adugarea comentariilor n punctele cheie ale codului. Toate modificrile realizate n cod vor

fi comentate, specificndu-se motivul modificrii i unde s-a fcut modificarea.

2. Folosirea unui sistem SVN de versionare i nainte de a se face commit la o modificare, se va

face merge cu versiunea de pe server.

3. De asemenea pentru faza de testare se va folosi tool-ul de la JIRA de management al

bug-urilor a crui licen a fost inclus n costurile aplicaiei

(https://www.atlassian.com/software/jira)

Codul va trebui s respecte urmtoarele concepte de inginerie software:

Convention over configuration (Convenia nainta configurrii)Conveia nainte configurrii este un concept de simplificare a setrilor/deciziilor pe care

programatorul este nevoit s le fac atunci cnd dezvolt o aplicaie. Astfel procesul este simplificat

fr a se pierde neaprat din flexibilitate.

Fraza nseamn n esen c un dezvoltator nu mai este obligat s specifice aspectele

convenionale ale aplicaiei, ci numai pe cele neconvenionale. De exemplu dac exist o clas Sale


21/40

(n cazul framework-ului CakePHP un model) acesteia i se va asocia automat tabela Sales din baza de

date. Dac programatorul nu respect aceast convenie i i numete tabela n loc de sales

products_sold sau vnzri va trebui s scrie cod pentru a lega clasa sales de tabela asociat. Din acest

motiv majoritatea programatorilor, indiferent de limba n care este realizat aplicaia, folosesc n

partrea de implementare limba englez.Dac se respect conveniile de scriere a numelor, dezvoltatorul nu mai trebuie s mai

configureze nimic. Astfel este uurat procesul de implementare i se pot urmri mai uor relaiile

dintre componentele proiectului. n plus dac se folosesc setrile default ale framework-ului

proiectul este executata i vizualizat mai repede i mai uor. Pentru o pagin web mic aceast

diferena este insesizabil, dar pentru un proiect mare cu multe tabele i multe restricii se poate

observa diferena.

Majoritatea limbajelor folosesc multe fiiere de setri, cu muli parametrii,i adesea este nevoie

de o mapare ntre clase i tabele pentru a se putea implementa procese de cutare, inserare i

modificare.

Problema pe care o ntlnesc dezvoltatorii atunci cnd au posibilitatea de a folosi conveniile

este aparenta rigiditatea care este dat de restriciile impuse. Programatorul poate avea impresia c

este obligat s foloseasc aceste convenii, i dei ele ajuta la o fluidizare a aplicaiei, nu sunt

mandatorii. n afar de setrile de baz ale framewor-ului, CakePHP ofer posibilitarea de

configurare.

Deoarece este un concept nou, foarte puine framework-uri l au la baz. Unul dintre ele este

CakePHP-ul, dar i alte framework-uri precum Ruby on Rails, Apache Maven i Grails au ajuns sa-l

adopte i s-l foloseasc.

Active record

n ingineria software, conceptul de Active record se refer la felul n care se lucreaz cu

operaiile pe o baz de date relaional. n mod normal acestea sunt realizate prin scripturi SQL de

Select, Insert i Update implementate conform limbajului folosit, fie prin concatenarea deiruri de

caractere i rularea lor. Prima variant dei sigur ocup foarte mult timp de codare i a doua, mai

simpl, determin formarea de bree n securitatea aplicaiei.

Active record ofer posibiliatea de accesa elementele tabelelor ntru-un mod simplui sigur. O

tabel sau o vizualizare din baza de date este nfurat intr-o clas. Instanele clasei sunt defapt linii

din tabel. Astfel crearea unui nou obiect duce la adugarea unei linii n tabeli este echivalent cu

realizarea unei operaii insert. Modificarea unui obiect existent, modific linia din tabel

corespunztoare acestuia (Update). n general, relaia dat de cheia extern este implentat cu

ajutorul proprietilor.


22/40

Aceast model este folosit pentru framework-urile ce au la baz o mapare ntre clasei tabele.

CakePHP-ul, cum s-a explicat n capitolul 4.1.1, folosete conveniile pentru a lega tabelele unei baze

de date cu clasele corespunztoare.

Astfel n loc s se scrie scripturi SQLi iniializri de parametrii, se pot folosi metodele implicite

asociate clasei.De exemplu n loc s scriem SELECT * FROM mytable n CakePHP se poate scrie $query =

$this->mytable->find('all');

Aceast scriere este mai simpl, este orientat obiect, uor de neles i este securizat. Dei se

poate folosii concatenarea deiruri de caractere, forma de mai sus este de preferat deoarece ferete

aplicaia de atacuri de genul SQL Injection.

Front Controller

Front Controller este o metod de implementare a paginlor web, sau a aplicaiilor programabile

de orice natur prin care se centralizeaz datele ntr-o singur instan. Este mai ales folosit pentru

partea de design a paginilor web.

Pentru a explica mai clar, ideea de front controller se refer la a uura navigarea prin paginile

aplicaei. Dei nu este strict necesar sau obligatorie este mult mai uor de controlat flow-ul aplicaiei

i este mult mai confortabil pentru programator s se ocupe de navigare pentru o singur pagini s

schimbe doar coninutul acesteia.

Alternativa folosirii front controller-ului ar fi ca fiecare pagin s conin acelai cod de mai

multe ori, dar aceast metod poate duce la discordane. De asemenea exist pericolul de a observa o

greeal n codul comun dar a corect numai n ctva dintre acestea. Front-ul comun face caelementele comune ale paginii s fie gestionate mpreun.

Front Controller-ul poate fi impementat n diferite moduri,i n diferite limbaje. Framework-ul

de Cake ofer posibilitatea de a realiza acest lucru prin contruirea unui layout numit front.ctp

Model View Controller (MVC)

Structura MVC este un model arhitectural utilizat n ingineria software. Succesul acestiu model,

fa de celelalte modele este dat gradul de independe pe care l are. De asemenea structurarea

riguroas pe cele trei nivele, independena dintre acestea, gradul ridicat de generalizare i

securitatea acestia fac din modelul MVC unul dintre cele mai folosite arhitecturi de pe piaa de pagini

web.

Interaciunea componetelor i legturile ce se formeaz ntre ele definesc design-ul unic al

acestei arhitecturi.


23/40

n primul rnd controller-ul trimite comenzi view-ului aosciat i i schimb structura cu

ajutorul datelor pe care le trimite. De asemenea mai poate trimite comenzi la model pentru a

recupera informaii.

Modelul anun controller-ul dac se produce o schimbare la editarea datelor sale. O

vizualizare poate solicta de la model informaiile de care are nevoie pentru a genera interfaa graficpentru utilizator.

n framwork-ul CakePHP structura de baz a MVC-ului este modificat pentru a avea o

securizare mai bun asupra datelor.

Modelul nu are contact cu vizualizarea, ci doar cu Controller-ul i baza de date. Modelul, n

funcie de numele clasei, extrage date din baza de datei i le trimite Controller-ului de cte ori acesta

le cere (n figura 4.2 legturile 3,4 arat comunicarea dintre Model i Controller). La rndul luiController-ul nu are contact direct cu utilizatorul, clientul care acceseaz pagina, dar poate sa trimit

datele comunicate de model vizualizrii (5).

Vizualizarea este cea care i apare defapt pe ecran utilizatorul. n funcie de ce operaiuni face

acesta, View-ul o s trimit cererea la fiierul de Dispacher (1), care o va trimite la rndul lui la funcia

din Controller asociat paginii/aciunii cerute (2). Controller-ul mai are rolul de a da acces

utlizatorului la anumite pagini sau de a-l restriciona. De exemplu seciunea de administrare nu poate

fi accesat dect de un utilizator logat.

2.3 Identificarea echipei

Echipa va fi formata din 3 analiti care vor analiza fluxul de informaii, procesele economice i

tranzacionale specifice companiei, evaluarea infrastructurii suportului informatic pentru nregistrarea,

stocarea i manipularea datelor, precum si determinarea necesarului pentru implementarea aplicaiei ERP.


24/40

Pe lng acetia va mai fi nevoie de 4 programatori care se vor ocupa de design-ul interfe ei grafice i de

dezvoltarea efectiv a aplicaiei ERP. Ulterior se vor ocupa de testarea produsului i de problemele ce vor

aprea dup ce aplicaia va intra n producie.

Membrii echipei de programatori trebuie sa aib experient in dezvoltarea aplicaiilor web si s

cunoasca limbajul PHP i framework-urile pe care le folosete aplicaia. Membrul echipei care se va ocupade interfa trebuie s aib experien cu HTML, CSS, Javascript, JQuerry i Ajax.

Echipa va fi coordonat de ctre un team manager care n elege tot procesul de producie.

3. Analiza caracteristicilor proiectului

3.1. ncadrarea proiectului n funcie de obiective sau de orientarea sa ctre

produs

Successul unui proiect depinde n mare msur de partea incipient a sa, acea parte n care se

stabilesc funcionalitile si obiectivele proiectului. Un proiect cu obiective clar formulate naintea nceperii

activitai de design are o rat de succes mult mai mare n comparaie cu un proiect n care cerinele sunt

formulate vag la nceput si modificate pe parcurs n plus modificrea cerinelor cnd dezvoltarea aplicaiei se

afl ntr-o faz avansat va crete exponenial costurile de dezvoltare. Acest lucru implic o analiz

preliminar pentru a se stabili funcionalitile si obiectivele aplicaiei.

Proiectul are ca scop furnizarea unui produs, anume o platform web pentru gestiunea activitilor

din cadrul unei firme de dimensiune mic sau mijlocie. Produsul va asigura transparen a datelor i accesul laacestea n cadrul organizaiei.

Deoarece proiectul este adresat prii de gestionare din cadrul unei oragnizaii i este o aplicaie

web, tipul su este Business System i nu Mission-Critical System sau Embedded Life-Critical

System, acest fapt permite:

- folosirea unei metodologiAGILE (SCRUM, Extreme Programming, Pair Programming,etc)

- planificare incremental

- dezvoltarea n paralel a prilor de design i de codare.

- pair programming sau codare individual

- testarea codului de ctre developeri

Impactul scontat al produsului este de a uura activitatea de gestionare din organizaie i implicit

reducerea costurilor necesare acestor activiti.


25/40

3.2. Analizarea diferitelor caracteristici ale proiectului

Realismul:

Proiectul trebuie planificat n aa fel nct obiectivele sale s poat fi realizate innd seama de

timpul alocat, cerinele sale dar i de disponibilitatea resurselor existente. Resursele sunt constituite din

oameni, informaii, tehnologii, fonduri materiale, resurse fizice. Se dorete un management foarte bun al

resurselor pentru ca scopul final s fie atins folosind un numr ct mai mic de resurse.

Limitarea n timp i spaiu:

Planificarea proiectului trebuie s includ o analiza a constrngerilor temporale si care in de locaia

unde se poate dezvolta produsul pentru a se evita ct se poate situaiile de urgen care pot pune echipa de

proiect in situaii deosebit de incomode.

Complexitatea:

Proiectul apeleaz la diverse abiliti n materie de planificare i implementare, implicnd

diversi actori i parteneri, diversi deintori de interese. Pentru ca proiectul s i ating scopul

a fost realizat o analiz amnunit a gestiunii activitilor din cadrul unei firme de dimensiune mic sau

mijlocie. De asemenea, a fost necesar un studiu asupra aplicaiilor existente pentru a

putea nelege principiul general de funcionare al acestora i gradul de complexitate al aplicaie

ce trebuie dezvoltat n raport cu acestea.

Caracterul colectiv:

Proiectul este rezultatul unui efort colectiv. Este dezvoltat de ctre o echip si implic diveri

parteneri, ntr-un final reuind s rspund la nevoie unui puplic int.

Unicitate, irepetabilitate:

Proiectul este inovativ, nu reprezint o munc de rutin, dei unele activiti pot avea un caracter

repetitiv, precum adaugarea de facturi sau a unui client, aceste operatii de rutina sunt necesare pentru a

obtine la sfarsit rapoarte complete cu activitatea companiei. Solutia ERP se bazeaza pe aceleasi principii

ca si solutiile existente, dar modulul individualizat de rapoarte si posibilitatea de a crea module anexate la

proiect (in cazul de fata modulul de SEO si Keywords) o diferentiaza de produsele actuale de pe piata.


26/40

Evaluarea:

Proiectul poate fi evaluat deoarece conine obiective msurabile. n final vom putea evalua dac

proiectul i-a atins scopul i calitatea dorit.

3.3. Identificarea riscurilor

Planul proiectului este n general bazat pe estimri. Aceste estimri conin un factor de

incertitudine, fapt ce implic poteniale riscuri. Managementul riscurilor const n identificarea, evaluarea i

planificarea aciunilor necesare pentru prevenirea sau ameliorarea efectelor situaiilor ce pot duna

dezvoltrii normale a proiectului.

Riscul asociat unui eveniment, are dou componente

- probabilitate de apariie a acelui eveniment

- impactul apariiei evenimentului.

Pentru identificarea potenialelor riscuri ce pot aprea pe parcursul dezvoltrii apliciei a

fost efectuat o analiz amnunit.


27/40

Risc Probabilitate Impact

clientul nu colaboreaz pe parcursul

dezvoltrii aplicaiei

mic mediu

estimri nerealiste ale timpilornecesari pentru dezvoltarea unor fazeale aplicaiei

medie mediu

dezvoltarea funcionalitilor greite mic mare

modficarea cerinelor spre finaluldezvoltrii

mic mare

modificarea echipei de dezvoltare mic mare

descoperirea de buguri n tehnologiilede care se uziteaz

mic mare

gestionarea inadecvat a drepturilorde acces la resursele informaionale,modul n care se pot accesaresursele i informaia din sistem

medie mare

vulnerabilitatea bazei de date laatacuri informationale venite dinreteaua externa

medie foarte mare

3.4. Identificarea cerinelor utilizatorilor

Pentru ca proiectul sa si ndeplineasc cu success este foarte important mprtsirea unei viziuni

comune ntre echipa de dezvoltare i beneficiarii produsului.

Pentru ca acest lucru s fie realizabil a fost analizat ntreg procesul de gestiune al activitilor unei

firme precum i problemele ntmpinate la diferite operaiuni necesare. n urma analizei cerinelor la care

trebuie s rspund aplicaia s-a ajuns la concluzia c este mai bine s se dezvolte o aplicaie web, n locde o aplicaie pentru desktop. n primul rnd, exist uurina accesului la date. Dac exist un calculator i

conexiune la internet utilizatorii pot accesa de oriunde aplicaia indiferent de sistemul de operare rulat. De

asemenea, codul fiind meninut pe server, orice update al aplicaiei ajunge la client fr vreun efort din partea

acestuia.


28/40

3.5. Stabilirea unei metodologii de dezvoltare

Metodologie de dezvoltare i implementare aleas pe baza cerinelor aplicaiei i a experienei

echipei n dezvoltarea de aplicaii web este SCRUM.

SCRUM fiind o metodologie Agile permite: o planificare incremental, dezvoltarea n paralel a

prilor de design i de codare, pair programming sau codare individual, testarea codului de ctre

developeri.

Aceste caracteristici ajut la:

atingerea cu success a obiectivelor,

scurtarea duratei proiectului,

utilizarea n mod eficient a resurselor,

creterea calitii produsului.

Tool-ul folosit pentru managementul proiectului este Trello. Aplicaia permite administrarea iorganizarea proiectului n mod concurent pentru toi membrii echipei, facilitnd accesul la documente i

modificarea acestora n timp real.

3.6. Estimarea necesarului de resurse

Resursele necesare pentru realizarea proiectului:

- resurse materiale (computere, servere, etc)

- spaiu pentru birouri,- perioad de timp,

- resurse financiare pentru achizitionarea altor resurse,

- resurse umane.

4 Identificare produselor i activitilor asociate proiectului

4.1 Identificarea i descrierea produselor asociate proiectului

Produse de sistem

specificaiile generale ale proiectului - prezentarea funcionalitilor pe care le ofer aplicaia

aplicaie software testat - produs rezultat n urma procesului de testare a aplicaiei


29/40

utilizatori pregtii pentru utilizarea aplicaiei - produs rezultat n urma procesului de instruire a

utilizatorilor

Produse aferente modulelor

design-ul modulelor aplicaiei codul corespunztor modulelor aplicaiei

Produse de management

planificarea activitilor din timpul dezvoltrii aplicaiei

planificarea resurselor necesare dezvoltrii i utilizirii aplicaiei

rapoartele de activitate din timpul dezvoltrii aplicaiei

4.2 Documentarea fluxului de producie

4.3 Recunoaterea instanelor produsului1. Seciune Operaional - pentru susinerea activitii operaionale i implementarea

fluxurilor n companie.

2. Seciune financiar i contractual pentru gestionarea situaiilor clienilor, facturi,

contracte, condiii i termeni de plat

3. Seciune CRM pentru managementul activitilor de presales, managementul incidentelor


30/40

i al solicitrilor i managementul relaiei cu clienii

4. Seciune pentru Managementul Documentelor pentru organizarea, stocarea, i

cutarea documentelor.

5. Sectiune access Clieni pentru a oferi clienilor si transparen n procesul de

procesare a documentelor.

4.4 Reeaua de activitate ideal a proiectului

4.5 Factori ce determina modificarea diagramei de activitate ideal a

proiectului

- ntrzieri n realizarea diferitelor module

- ntrzieri n realizarea aplicaiilor ce sunt integrate cu aceast aplicaie


31/40


32/40

5. Estimarea efortului pentru fiecare etap

5.1 Estimri bottom-up

Activitile necesare dezvoltrii proiectului prezint dependene cu privire la resursele materiale,

financiare sau umane disponibile. Pentru a maximiza utilizarea resurselor i a micora timpul necesar

dezvoltrii proiectului se vor face estimri de ctre mangerul de proiect pentru fiecare activitate/ resurs.

Activitile critice sunt cele de care depind alte activiti din cadrul aceluiai proiect.

Activitile ce trebuiesc parcurse n succesiune cronologic, mpreun cu estimrile date n

person-days sunt urmtoarele:

1. Analiza fluxului de informaii i a proceselor economice i tranzactionale specifice

companiei -7 person-days.1.1. determinarea structurii organizaionale i a nivelelor ierarhice - 1 person-days.

1.2. determinarea tipurilor de tranzacii specifice - 1 person-days.

1.3. determinarea fluxurilor de documente specifice - 1 person-days.

1.4. determinarea proceselor interne specifice i determinarea proceselor economice

specifice -1 person-days.

1.5. determinarea infrastructurii hardware existente- 1 person-days.

1.6. evaluarea structurii existente - 1 person-days.

1.7. determinarea necesarului de echipamente n vederea implementrii sistemului ERP

- 1 person-days.

2. Evaluarea infrastructurii suportului informatic pentru nregistrarea - 3 person-days.

3. Identificarea necesitilor companiei n urma analizei n vederea dezvoltrii aplicaiei ERP

- 7 person-days

3.1. indentificarea nevoilor i necesitilor - 2 person-days

3.2. transpunerea nevoilor i necesitilor identificate n specificaii de implementare - 2

person-days

3.3. elaborarea calendarului de implementare - 3 person-days

4. Design-ul bazei de date - 5 person-days5. Generarea modelelor pe baza tabelelor stabilite anterior - 3 person-day

6. Dezvoltarea interfeei (design-ul paginilor) - 5 person-days

7. Implementarea conexiunii la modulul de autentificare - 5 person-days

8. Implementarea funcionalitii pentru administrator- 5 person-days (in paralel):

8.1. Crearea/ editarea/ tergerea unui utilizator de tip angajat - 5 person-days


33/40

8.2. Sistem pentru adugarea/ modificarea funciilor angajailor - 5 person-days

8.3. Sistem pentru clasificarea clienilor - 5 person-days

9. Implementarea funcionalitii pentru contabil 5 person-day(in paralel)s:

9.1. Crearea/ editarea/ tergerea unui utilizator de tip angajat - 5 person-days

9.2. Sistem pentru generarea facturilor - 5 person-days9.3. Sistem pentru eliberarea chitanelor - 5 person-days

10. Implementarea funcionalitii pentru angajat 5 person-days(in paralel):

10.1. Sistem pentru exportarea fiierelor - 5 person-days

10.2. Sistem pentru modificarea fiierelor- 5 person-days

11. Implementarea funcionalitii pentru clieni 10 person-days:

12. Testare aplicaie ERP - 10 person-days

13. Trecerea aplicaiei n producie.n aceast etap pot s apar probleme sau cerine

suplimentare care vor fi rezolvate de ctre furnizorul aplicaiei - 5 person-days

14. Formare personal intern utilizare i mentenan aplicatiei ERP -10 person-days

Efortul total estimat este de 85 person-days

5.2 Revizuirea planului pentru crearea unor activiti controlabile

Activitile sunt prioritizate iar oridinea de efectuarea trebuie s respecte urmtoarea ordine:

1. activitile critice cu o durat de timp estimat mic,

2. celelalte activiti critice,

3. activitile cu o durat estimat de timp mic,

4. restul activitilor.

6. Identificarea riscurilor posibile in fiecare etap

6.1. Identificarea i estimarea riscurilor posibile in fiecare etap

Pe parcursul dezvoltrii proiectului pot aprea diferite tipuri de probleme ce pot duce la

amnarea termenului de finalizare a proiectului. Urmtoarele reprezint posibile riscuri:

- identificarea eronat a proceselor economice i financiare specifice companiei, problema

care poate duce la o funcionare defectuas a produsului software.

- layout-ul aplicaiei nu respect cerinele aplicaiei sau pe parcursul dezvoltrii se observ

nevoia modificrii acestuia pentru a se adapta la noile cerine


34/40

- la testarea sistemului s se obin bug-uri majore a cror rezolvare s necesite modificarea

aplicaiei la nivel de baza

- implementare funcionalitii de administrator/contabil/manager diferit fa de specificaii

din nevoia de a face mai puini pai.

- pericolul de a nu se integra anumite module, cu cele existente.- posibile modificri la modulul de autentificare (efectul pe care l au asupra dezvoltrii

depinde de magnitudinea modificrii)

- riscul de a se produce erori n design-ul bazei de date, care poate avea urmri majore asupra

structurii aplicaiei i modulelor.

6.2. Modaliti de reducere a riscurilor n fiecare etap

Metoda cea mai sigur de a evita riscurile prezentate mai sus este ca la nceputul fiecrei

etape s se fac o analiz detaliat asupra felului n care clientul dorete s se efectueze pasii in

aplicaie. Acelasi principiu se aplica si pentru partea de interfa a aplicatiei pentru care este

necesara o analiza la fel de detaliata, care sa fie realizata dupa etapa de analiza a functionalitatilor.

De asemenea clientul trebuie s dea detalii referitoare la modulele pe care le vrea integrate i

s ofere acces la modulele deja existente (chiar dac informaiile din aceaste module sunt

confideniale)

Testarea ar trebui facuta dupa implementarea fiecarui modul pentru a rezolva problema

modificarilor ce pot surveni in urma identificarii unor nereguli in sistem.

6.3. Revizuirea planului n funcie de riscurile posibileDeoarece majoritatea riscurilor apar datorit unui numr mic de zile pentru analiz i din

lipsa comunicrii cu clientul se va marii perioada de analiz cu un numr nelimitat de zile i de

asemenea se vor face edine o dat pe sptmna la care va participa un reprezentant al clientului i

n care vor fi clarificate activitile realizate n acea sptmna. Aadar va exist o edina

sptmnal de rezumare a task-urilor ndeplinite n acea perioada.

De asemenea se va face cate o testare dupa fiecare implementare a unui modul si o testare

generala dupa definitivarea dezvoltarii proiectului.

7. Alocarea resurselor

Resursele de care dispune aplicaia trebuiesc alocate n mod optim astfel nct s se maximizeze

uzitarea lor iar timpul de dezvoltare s fie minimizat.


35/40


36/40

Resursele umane alocate implementrii proiectului.

1 manager de proiect

3 analiti

4 programatori

Resurse nemateriale includ resursele informaionale, timpul dedicat i capitalul social.Resurse materiale - sunt bunurile care pot fi exploatate n derularea diferitelor activiti:

paiu pentru birouri,

echipamente tehnice i de birou ( cinci calculatoare desktop, ase monitoare, dou

tablete, o imprimant multifuncional, trei UPS-uri, un router, dou licene sisteme de

operare calculatoare, o licen sistem de operare server, o licen software profesional

creare i editare imagini, o licen software profesional grafic vectorial, un pachet licene

antivirus, o licen software profesional grafic dtp i print, o licen mediu de dezvoltare

aplicaii software, patru licene suite programe de birou )

acces la internet

acces la surs de curent

Resursele financiare acestea vor fi necesare pentru achiziionarea de alte resurse a cror

necesitate va aprea n cursul dezvoltrii proiectului.

Lista activitilor n ordine cronologic mpreun cu alocarea task-urilor pentru fiecare membru al

echipei de dezvoltare.

1. Analiza fluxului de informaii i a proceselor economice i tranzactionale specifice companiei -

analist 1 + 2 + 3.1.1. determinarea structurii organizaionale i a nivelelor ierarhice - analist 1

1.2. determinarea tipurilor de tranzacii specifice - analist 2

1.3. determinarea fluxurilor de documente specifice - analist 1

1.4. determinarea proceselor interne specifice i determinarea proceselor economice

specifice - analist 1

1.5. determinarea infrastructurii hardware existente- analist 2

1.6. evaluarea structurii existente - analist 3

1.7. determinarea necesarului de echipamente n vederea implementrii sistemului ERP -

analist 1

2. Evaluarea infrastructurii suportului informatic pentru nregistrarea - analist 1 + 2

3. Identificarea necesitilor companiei n urma analizei n vederea dezvoltrii aplicaiei ERP

analist 2 + 3.

3.1. indentificarea nevoilor i necesitilor - analist 2

3.2. transpunerea nevoilor i necesitilor identificate n specificaii de implementare - analist 3


37/40

3.3. elaborarea calendarului de implementare - analist 3

4. Design-ul bazei de date - analist 1

5. Generarea modelelor pe baza tabelelor stabilite anterior - programator 1

6. Dezvoltarea interfeei (design-ul paginilor) - programator 1 +2 + 3

7. Implementarea conexiunii la modulul de autentificare - programator 48. Implementarea funcionalitii pentru administrator- programator 1 + 2

8.1. Crearea/ editarea/ tergerea unui utilizator de tip angajat - programator 1

8.2. Sistem pentru adugarea/ modificarea funciilor angajailor -programator 2

8.3. Sistem pentru clasificarea clienilor - programator 2

9. Implementarea funcionalitii pentru contabil - programator 3 + 4

9.1. Crearea/ editarea/ tergerea unui utilizator de tip angajat - programator 4

9.2. Sistem pentru generarea facturilor - programator 3

9.3. Sistem pentru eliberarea chitanelor - programator 3

10. Implementarea funcionalitii pentru angajat - programator 1 + 2

10.1. Sistem pentru exportarea fiierelor - programator 1

10.2. Sistem pentru modificarea fiierelor- programator 2

11. Implementarea funcionalitii pentru clieni - programator 3 + 4

12. Testare aplicaie ERP - programator 1 + 2

13. Trecerea aplicaiei n producie.n aceast etap pot s apar probleme sau cerine

suplimentare care vor fi rezolvate de ctre furnizorul aplicaiei programator 1 +2 + 3 + 4

14. Formare personal intern utilizare i mentenan aplicatiei ERP - programator 1 + 2 + 3 + 4.

In figurile de pe pagina urmatoare se poate observa diagrama Gantt a planificarii derularii proiectului,

care a fost impartita in doua figuri pentru a putea fi capturata in intregime.


38/40


39/40

C. Managementul codului (versioning control)

Pentru managementul codului am folosit Apache Subversioning (SVN) cu TurtoiseSVN casource control software.


40/40

Bibliografie

http://www.netsuite.com/portal/resource/articles/er

p/what-is-erp.shtmlhttp://www.portalcontabilitate.rohttp://www.investopedia.com/terms/c/cashflow.asphttp://www.entrepreneur.com/article/66008
http://www.google.com/url?q=http%3A%2F%2Fwww.entrepreneur.com%2Farticle%2F66008&sa=D&sntz=1&usg=AFQjCNEq8JKCOH0FxNv8orK30nRiMGEYKAhttp://www.google.com/url?q=http%3A%2F%2Fwww.investopedia.com%2Fterms%2Fc%2Fcashflow.asp&sa=D&sntz=1&usg=AFQjCNEcRCvISXZXmmQcXtoF1r2_iutolQhttp://www.google.com/url?q=http%3A%2F%2Fwww.portalcontabilitate.ro&sa=D&sntz=1&usg=AFQjCNH7RUO5g27SSPlM0Q9xFirwY1C1twhttp://www.google.com/url?q=http%3A%2F%2Fwww.netsuite.com%2Fportal%2Fresource%2Farticles%2Ferp%2Fwhat-is-erp.shtml&sa=D&sntz=1&usg=AFQjCNHOZDoyg0THDPFlWbCZ3k0KXoAq-Ahttp://www.google.com/url?q=http%3A%2F%2Fwww.netsuite.com%2Fportal%2Fresource%2Farticles%2Ferp%2Fwhat-is-erp.shtml&sa=D&sntz=1&usg=AFQjCNHOZDoyg0THDPFlWbCZ3k0KXoAq-A

mpsporoiectgrup - erp

Documents