Managementul Proiectelor

Software
Sistem de planificare a resurselor unei
ntreprinderii software

Punoiu Daniel
Pintea Codrina Maria
Srbu Roxana Larisa
Ion Silviu Mihai
Radu Marian

Universitatea din Bucureti Facultatea de Matematica i Informatic

Bucuresti
2014

Cuprins
A.

Business case
1.
2.
3.
4.

5.

6.
7.

B.

Nume proiect: Sistem de planificare a resurselor unei ntreprinder software(ERP)

Obiective
Motivaie
Rezumat
4.1.
Descrierea produsului
4.2.
Descrierea soluiei
4.3.
Descrierea planului de implementare
Detalii privind soluia propus
5.1.
Analiza SWOT
5.2.
Soluii similare
5.3.
Paralela cu soluii concurente
5.4.
Posibile achiziii: observaii despre furnizor
5.5.
Tehnologii folosite
5.6.
Integrarea cu alte proiecte/operaii ale companiei
5.7.
Riscuri posibile
Impactul proiectului
Costuri
7.1.
Categorii de costuri si estimari
7.2.
Analiz cost/beneficiu (ROI - Return of investment, payback period) II.
Planificarea proiectului

1.

2.

3.

Identificarea scopului i obiectivelor proiectului

1.1.
Identificarea obiectivelor i metode de msurare a eficienei n atingerea lor
1.2
Stabilirea unei autoriti a proiectului
1.3.
Identificarea prilor interesate de proiect
1.4.
Redefinirea obiectivelor n urma stabilirii prilor interesate
1.5.
Stabilirea metodelor de comunicare ntre toate prile implicate
Infrastructura proiectului
2.1
Stabilirea relaiei dintre proiect i planificare strategic
2.2
Identificarea standardelor i procedurilor
2.3
Identificarea echipei
Analiza caracteristicilor proiectului
3.1.
ncadrarea proiectului n funcie de obiective sau de orientarea sa ctre

produs
3.2.

Identificarea riscurilor

4.

5.

6.

7.

3.3.
Identificarea cerinelor utilizatorilor
3.5.
Stabilirea unei metodologii de dezvoltare
3.6.
Estimarea necesarului de resurse
Identificare produselor i activitilor asociate proiectului
4.1
Identificarea i descrierea produselor asociate proiectului
4.2
Documentarea fluxului de producie
4.3
Recunoaterea instanelor produsului
4.4
Reeaua de activitate ideal a proiectului
4.5
Factori ce determina modificarea diagramei de activitate ideal a proiectului
Estimarea efortului pentru fiecare etap
5.1
Estimri bottom-up
5.2
Revizuirea planului pentru crearea unor activiti controlabile
Identificarea riscurilor posibile in fiecare etap
6.1.
Identificarea i estimarea riscurilor posibile in fiecare etap
6.2.
Modaliti de reducere a riscurilor n fiecare etap
6.3.
Revizuirea planului n funcie de riscurile posibile
Alocarea resurselor

III. Managementul codului (versioning control)

A.Business case
1. Nume proiect: Sistem de planificare a resurselor unei intreprinderi
software(ERP)
2. Obiective
Obiectivul acestui proiect 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 cadrul
unei 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.

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 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.

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.

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)

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

IBAN, TVA - pentru parteneri strini)

Exemple de cazuri de utilizare.

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 cu
scopul de a arta stratificarea acestui framework i 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 utilizator i 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 aplicaiei 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,

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 implementrii

sistemului ERP .

Design - identificarea necesitilor companiei n urma analizei n vederea

dezvoltrii aplicaiei ERP

Subactivitile specifice sunt: indentificarea nevoilor i necesitilor,

transpunerea nevoilor i necesitilor identificate n specificaii de implementare, elaborarea

calendarului de implementare.

3.

Dezvoltare i testare aplicaie 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 funciune a aplicatiei ERP odat aplicaia testat i 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 ct i a celor care se vor ocupa
de mentenana acesteia.

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 mijlocii i 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.

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 baza i 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 browser i 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 utilizat i nici de

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 vizualiza i 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 n
componentele 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 timp i
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).

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 fiiere 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 fost
folosit 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

5.7. Riscuri posibile

Riscurile ce le presupune implementarea unei astfel de aplicaii sunt mari, deoarece gestiunea
plilor i aproximarilor facute n aplicaie pot s fie eronate. De asemenea exist anumite proceduri
contabile 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

Soluia

Editarea manual a unei facturi

Factura este generat automat

Gestionarea termenelor de plat

Un sistem avansat de filtrare, care alege

facturile al cror termen de plat a fost depait
sau urmeaz sa fie depit n urmatoarele zile

Gesionarea deadline-urilor pentru proiecte/

activiti

O listare a proiectelor i activitatilor ce se

apropie de termenul de livrare

Rapoarte fcute manual de activitai pentru

clieni

Generarea automat a rapoartelor de activiti

pe o perioad bine definit

Rapoarte de vnzri fcute manual, trecnd n

raport toate facturile ncepnd de la o anumit
dat

Generarea automat a rapoartelor de vnzri

Cautarea manual a
pentru client/furnizor

Descarcarea contractului/anexei n format pdf

direct din aplicaie.

contractelor/anexelor

Cautarea unei facturi numai cnd se tiu cteva

date 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

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 i

contractul pe baza cruia este facut factura.

Stabilirea unui proiect de lucru

Adugarea unui proiect pentru client

Stabilirea task-urilor (activitilor) pe

un proiect

Adugarea unui task pe proiect, i al timpului de lucru

alocat 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

Pret

cheltuieli)

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

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

period)
Aplicaia nu va produce venituri, amortizarea realizndu-se ntr-o perioad de
ndelungat prin economisirea produselor de tip consumabil i a valorificrii timpului.
ROI = (Venituri in urma investitiei Suma investita) / Suma investita

timp

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 dintre

facturi, 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 care
folosete 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.

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 de

cont 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

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

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 la

un 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

crui

licen

fost

inclus

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

(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 de iruri 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 simplu i 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 tabel i 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.

Aceast model este folosit pentru framework-urile ce au la baz o mapare ntre clase i 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 SQL i 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 folosi i concatenarea de iruri 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 pagin i 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 ca
elementele 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.

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 grafic
pentru 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 date i 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 lui
Controller-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.3Identificareaechipei

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.

Pe lng acetia va mai fi nevoie de 4 programatori care se vor ocupa de designul interfeei grafice i de
dezvoltarea efectiv a aplicaiei ERP. Ulterior se vor ocupa de testarea produsului i de problemele ce vor
apreadupceaplicaiavaintranproducie.
Membrii echipei de programatori trebuie sa aib experient in dezvoltarea aplicaiilor web si s
cunoasca limbajul PHP i frameworkurile pe care le folosete aplicaia. Membrul echipei care se va ocupa
deinterfatrebuiesaibexperiencuHTML,CSS,Javascript,JQuerryiAjax.
Echipavaficoordonatdectreunteammanagercarenelegetotprocesuldeproducie.

3.Analizacaracteristicilorproiectului

3.1.ncadrareaproiectuluinfunciedeobiectivesaudeorientareasactre
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 nceputsi modificate pe parcurs n plus modificrea cerinelorcnddezvoltarea aplicaieise
afl ntro faz avansat va crete exponenial costurile de dezvoltare. Acest lucru implic o analiz
preliminarpentruasestabilifuncionalitilesiobiectiveleaplicaiei.
Proiectul are ca scop furnizarea unui produs, anume o platform web pentru gestiunea activitilor
din cadrulunei firme dedimensiune micsau mijlocie. Produsulva asigura transparena dateloriaccesulla
acesteancadrulorganizaiei.
Deoarece proiectul este adresat prii de gestionare din cadrul unei oragnizaii i este o aplicaie
web, tipul su este Business System i nu MissionCritical System sau Embedded LifeCritical
System,acestfaptpermite:
folosireauneimetodologiAGILE(SCRUM,ExtremeProgramming,PairProgramming,etc)
planificareincremental
dezvoltareanparalelaprilordedesignidecodare.
pairprogrammingsaucodareindividual
testareacoduluidectredeveloperi

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

3.2.Analizareadiferitelorcaracteristicialeproiectului

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
resurselorpentrucascopulfinalsfieatinsfolosindunnumrctmaimicderesurse.

Limitareantimpispaiu:
Planificarea proiectului trebuiesincludo analiza a constrngerilor temporale sicareinde locaia
unde se poate dezvolta produsul pentru a se evitact sepoate situaiile deurgencare pot pune echipa de
proiectinsituaiideosebitdeincomode.

Complexitatea:
Proiectulapeleazladiverseabilitinmateriedeplanificareiimplementare,implicnd
diversiactoriiparteneri,diversideintorideinterese.Pentrucaproiectulsiatingscopul
a fost realizat o analiz amnunit a gestiunii activitilor din cadrul unei firme de dimensiune mic sau
mijlocie.Deasemenea,afostnecesarunstudiuasupraaplicaiilorexistentepentrua
puteanelegeprincipiulgeneraldefuncionarealacestoraigraduldecomplexitatealaplicaie
cetrebuiedezvoltatnraportcuacestea.

Caracterulcolectiv:
Proiectul este rezultatul unui efort colectiv. Este dezvoltat de ctre o echip si implic diveri
parteneri,ntrunfinalreuindsrspundlanevoieunuipuplicint.

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 anexatela
proiect(incazuldefatamodululdeSEOsiKeywords)odiferentiazadeproduseleactualedepepiata.

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

3.3.Identificareariscurilor

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
dezvoltriinormaleaproiectului.
Risculasociatunuieveniment,aredoucomponente
probabilitatedeapariieaaceluieveniment
impactulapariieievenimentului.

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

fostefectuatoanalizamnunit.

Risc

Probabilitate

Impact

clientul nu colaboreaz pe parcursul mic

dezvoltriiaplicaiei

mediu

estimri nerealiste ale timpilor medie

necesari pentru dezvoltarea unor faze
aleaplicaiei

mediu

dezvoltareafuncionalitilorgreite

mic

mare

spre finalul mic

mare

modficarea cerinelor
dezvoltrii

modificareaechipeidedezvoltare

mic

mare

descoperirea de buguri n tehnologiile mic

decareseuziteaz

mare

gestionarea inadecvat a drepturilor medie

de acces la resursele informaionale,
modul n care se pot accesa
resurseleiinformaiadinsistem

mare

vulnerabilitatea bazei de date la medie

atacuri informationale venite din
reteauaexterna

foartemare

3.4.Identificareacerinelorutilizatorilor

Pentru ca proiectul sa si ndeplineasc cusuccesseste foarteimportant mprtsirea uneiviziuni

comunentreechipadedezvoltareibeneficiariiprodusului.
Pentru ca acest lucru s fie realizabil a fost analizat ntreg procesul degestiune al activitilor unei
firme precum i problemele ntmpinate la diferite operaiuni necesare. n urma analizei cerinelor la care
trebuie s rspund aplicaia sa ajuns la concluzia c este mai bine s se dezvolte oaplicaie web,nloc
de o aplicaie pentru desktop. n primul rnd, exist uurina accesuluiladate.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 aplicaieiajungela client frvreun efort dinpartea
acestuia.

3.5.Stabilireauneimetodologiidedezvoltare

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

echipeindezvoltareadeaplicaiiwebesteSCRUM.
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.
Acestecaracteristiciajutla:

atingereacusuccessaobiectivelor,

scurtareadurateiproiectului,

utilizareanmodeficientaresurselor,

cretereacalitiiprodusului.

Toolul folosit pentru managementul proiectului este Trello. Aplicaia permite administrarea i
organizarea proiectului n mod concurent pentru toi membrii echipei, facilitnd accesul la documente i
modificareaacestorantimpreal.

3.6.Estimareanecesaruluideresurse

Resurselenecesarepentrurealizareaproiectului:
resursemateriale(computere,servere,etc)
spaiupentrubirouri,
perioaddetimp,
resursefinanciarepentruachizitionareaaltorresurse,
resurseumane.

4Identificareproduseloriactivitilorasociateproiectului

4.1Identificareaidescriereaproduselorasociateproiectului

Produsedesistem

specificaiilegeneralealeproiectuluiprezentareafuncionalitilorpecareleoferaplicaia

aplicaiesoftwaretestatprodusrezultatnurmaprocesuluidetestareaaplicaiei

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

Produseaferentemodulelor

designulmoduleloraplicaiei

codulcorespunztormoduleloraplicaiei

Produsedemanagement

planificareaactivitilordintimpuldezvoltriiaplicaiei

planificarearesurselornecesaredezvoltriiiutiliziriiaplicaiei

rapoarteledeactivitatedintimpuldezvoltriiaplicaiei

4.2Documentareafluxuluideproducie

4.3Recunoatereainstanelorprodusului
1.SeciuneOperaionalpentrususinereaactivitiioperaionaleiimplementarea
fluxurilorncompanie.
2.Seciunefinanciaricontractualpentrugestionareasituaiilorclienilor,facturi,
contracte,condiiiitermenideplat
3.SeciuneCRMpentrumanagementulactivitilordepresales,managementulincidentelor

ialsolicitrilorimanagementulrelaieicuclienii
4.SeciunepentruManagementulDocumentelorpentruorganizarea,stocarea,i
cutareadocumentelor.
5.SectiuneaccessClienipentruaofericlienilorsitransparennprocesulde
procesareadocumentelor.

4.4Reeauadeactivitateidealaproiectului

4.5Factoricedeterminamodificareadiagrameideactivitateideala
proiectului
ntrzierinrealizareadiferitelormodule

ntrzierinrealizareaaplicaiilorcesuntintegratecuaceastaplicaie

5.Estimareaefortuluipentrufiecareetap

5.1Estimribottomup
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
dezvoltriiproiectuluisevorfaceestimridectremangeruldeproiectpentrufiecareactivitate/resurs.

Activitilecriticesuntceledecaredepindalteactivitidincadrulaceluiaiproiect.
Activitile ce trebuiesc parcurse n succesiune cronologic, mpreun cu estimrile date n
persondayssunturmtoarele:

1.

Analiza fluxului de informaii i a proceselor economice i tranzactionale specifice

companiei7persondays.
1.1.

determinareastructuriiorganizaionaleianivelelorierarhice1persondays.

1.2.

determinareatipurilordetranzaciispecifice1persondays.

1.3.

determinareafluxurilordedocumentespecifice1persondays.

1.4.

determinarea proceselor interne specifice i determinarea proceselor economice

specifice1persondays.

1.5.

determinareainfrastructuriihardwareexistente1persondays.

1.6.

evaluareastructuriiexistente1persondays.

1.7.

determinarea necesarului de echipamentenvedereaimplementrii sistemuluiERP

1persondays.

2.

Evaluareainfrastructuriisuportuluiinformaticpentrunregistrarea3persondays.

3.

Identificarea necesitilor companiei n urma analizei n vederea dezvoltrii aplicaiei ERP

7persondays
3.1.

indentificareanevoilorinecesitilor2persondays

3.2.

transpunereanevoilorinecesitiloridentificatenspecificaiideimplementare2
persondays

3.3.

elaborareacalendaruluideimplementare3persondays

4.

Designulbazeidedate5persondays

5.

Generareamodelelorpebazatabelelorstabiliteanterior3personday

6.

Dezvoltareainterfeei(designulpaginilor)5persondays

7.

Implementareaconexiuniilamodululdeautentificare5persondays

8.

Implementareafuncionalitiipentruadministrator5persondays(inparalel):
8.1.

Crearea/editarea/tergereaunuiutilizatordetipangajat5persondays

9.

8.2.

Sistempentruadugarea/modificareafunciilorangajailor5persondays

8.3.

Sistempentruclasificareaclienilor

5persondays

Implementareafuncionalitiipentrucontabil5personday(inparalel)s:

10.

9.1.

Crearea/editarea/tergereaunuiutilizatordetipangajat5persondays

9.2.

Sistempentrugenerareafacturilor5persondays

9.3.

Sistempentrueliberareachitanelor5persondays

Implementareafuncionalitiipentruangajat5persondays(inparalel):
10.1.

Sistempentruexportareafiierelor5persondays

10.2.

Sistempentrumodificareafiierelor5persondays

11.

Implementareafuncionalitiipentruclieni10persondays:

12.

TestareaplicaieERP10persondays

13.

Trecereaaplicaieinproducie.naceastetappotsaparproblemesaucerine
suplimentarecarevorfirezolvatedectrefurnizorulaplicaiei5persondays

14.

FormarepersonalinternutilizareimentenanaplicatieiERP10persondays

Efortultotalestimatestede85persondays

5.2Revizuireaplanuluipentrucreareaunoractiviticontrolabile
Activitilesuntprioritizateiaroridineadeefectuareatrebuiesrespecteurmtoareaordine:
1.

activitilecriticecuoduratdetimpestimatmic,

2.

celelalteactiviticritice,

3.

activitilecuoduratestimatdetimpmic,

4.

restulactivitilor.

6.Identificareariscurilorposibileinfiecareetap

6.1.Identificareaiestimareariscurilorposibileinfiecareetap
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

- 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.Modalitidereducereariscurilornfiecareetap
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.Revizuireaplanuluinfunciederiscurileposibile
Deoarece 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.Alocarearesurselor
Resursele de care dispune aplicaia trebuiesc alocate n mod optim astfel nct s semaximizeze
uzitarealoriartimpuldedezvoltaresfieminimizat.

Resurseleumanealocateimplementriiproiectului.

1managerdeproiect

3analiti

4programatori

Resursenematerialeincludresurseleinformaionale,timpuldedicaticapitalulsocial.
Resursematerialesuntbunurilecarepotfiexploatatenderulareadiferiteloractiviti:

paiupentrubirouri,

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

tablete, o imprimant multifuncional, trei UPSuri, 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 profesionalgraficvectorial, un pachetlicene
antivirus, o licen software profesional grafic dtp i print, o licen mediu de dezvoltare
aplicaiisoftware,patrulicenesuiteprogramedebirou)

acceslainternet

acceslasursdecurent

Resursele financiare acestea vor fi necesare pentru achiziionarea de alte resurse a cror
necesitatevaapreancursuldezvoltriiproiectului.
Lista activitilor n ordine cronologic mpreun cu alocarea taskurilor pentru fiecare membru al
echipeidedezvoltare.

1.

Analiza fluxului de informaii i a proceselor economice i tranzactionale specifice companiei

analist1+2+3.
1.1.

determinareastructuriiorganizaionaleianivelelorierarhiceanalist1

1.2.

determinareatipurilordetranzaciispecificeanalist2

1.3.

determinareafluxurilordedocumentespecificeanalist1

1.4.

determinarea proceselor interne specifice i determinarea proceselor economice

specificeanalist1

1.5.

determinareainfrastructuriihardwareexistenteanalist2

1.6.

evaluareastructuriiexistenteanalist3

1.7.

determinarea necesarului de echipamente n vederea implementrii sistemului ERP

analist1

2.

Evaluareainfrastructuriisuportuluiinformaticpentrunregistrareaanalist1+2

3.

IdentificareanecesitilorcompanieinurmaanalizeinvedereadezvoltriiaplicaieiERP
analist2+3.
3.1.

indentificareanevoilorinecesitiloranalist2

3.2. transpunereanevoilorinecesitiloridentificatenspecificaiideimplementareanalist3

3.3.

elaborareacalendaruluideimplementareanalist3

4.

Designulbazeidedateanalist1

5.

Generareamodelelorpebazatabelelorstabiliteanteriorprogramator1

6.

Dezvoltareainterfeei(designulpaginilor)programator1+2+3

7.

Implementareaconexiuniilamodululdeautentificareprogramator4

8.

Implementareafuncionalitiipentruadministratorprogramator1+2

9.

8.1.

Crearea/editarea/tergereaunuiutilizatordetipangajatprogramator1

8.2.

Sistempentruadugarea/modificareafunciilorangajailorprogramator2

8.3.

Sistempentruclasificareaclienilor

programator2

Implementareafuncionalitiipentrucontabilprogramator3+4

10.

9.1.

Crearea/editarea/tergereaunuiutilizatordetipangajatprogramator4

9.2.

Sistempentrugenerareafacturilorprogramator3

9.3.

Sistempentrueliberareachitanelorprogramator3

Implementareafuncionalitiipentruangajatprogramator1+2
10.1.

Sistempentruexportareafiierelorprogramator1

10.2.

Sistempentrumodificareafiierelorprogramator2

11.

Implementareafuncionalitiipentruclieniprogramator3+4

12.

TestareaplicaieERPprogramator1+2

13.

Trecereaaplicaieinproducie.naceastetappotsaparproblemesaucerine
suplimentarecarevorfirezolvatedectrefurnizorulaplicaieiprogramator1+2+3+4

14.

FormarepersonalinternutilizareimentenanaplicatieiERPprogramator1+2+3+4.

In figurile de pe pagina urmatoare se poate observadiagrama Gantta planificariiderularii proiectului,

careafostimpartitaindouafiguripentruaputeaficapturatainintregime.

C. Managementul codului (versioning control)

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

Bibliografie
http://www.netsuite.com/portal/resource/articles/er
p/what-is-erp.shtml
http://www.portalcontabilitate.ro
http://www.investopedia.com/terms/c/cashflow.asp
http://www.entrepreneur.com/article/66008