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
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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)
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - ERP
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)
8/21/2019 MPSporoiectgrup - ERP
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/21/2019 MPSporoiectgrup - ERP
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,
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - ERP
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_U1Mjqd7F6RQw8/21/2019 MPSporoiectgrup - ERP
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_3pzRj0SVy3G3cqjc4hg8/21/2019 MPSporoiectgrup - ERP
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).
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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
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
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - 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.
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
31/40
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - ERP
35/40
8/21/2019 MPSporoiectgrup - ERP
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
8/21/2019 MPSporoiectgrup - ERP
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.
8/21/2019 MPSporoiectgrup - ERP
38/40
8/21/2019 MPSporoiectgrup - ERP
39/40
C. Managementul codului (versioning control)
Pentru managementul codului am folosit Apache Subversioning (SVN) cu TurtoiseSVN casource control software.
8/21/2019 MPSporoiectgrup - ERP
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