Magazin Virtual Folosind PHP Si My-SQL

UNIVERSITATEA ROMÂNO-AMERICANĂ FACULTATEA DE INFORMATICĂ MANAGERIALĂ

Magazin Virtual folosind PHP si My-SQL

Cuprins Cuprins......................................................................................................................2 Capitolul 1 – Studiul, analiza și prezentarea sistemului existent...............................4 1.1. Indicatori economici........................................................................................7 1.2. Obiect de activitate.........................................................................................8 1.2.1. Departamentul Evaluări Imobiliare............................................................8 1.2.2. Departamentul Agenție Imobiliară............................................................8 1.3. Structura organizatorică................................................................................12 1.3.1. Organigramă...........................................................................................12 1.3.2. Prezentarea sistemului de conducere.....................................................14 1.3.3. Prezentarea sistemului condus...............................................................14 1.5. Descrierea sistemului actual si direcții de perfectionare...............................16 1.6. Studiul sistemului informațional....................................................................17 1.6.1. Schema fluxului informațional....................................................................17 1.6.2. Aria de cuprindere (locul) circuitului informațional in cadrul sistemului informațional general al unitatii........................................................................17 1.6.3. Documente utilizate................................................................................17 1.6.4. Proceduri utilizate...................................................................................20 1.6.5. Analiza sistemului actual și identificarea neajunsurilor (punctelor critice) existente în funcționarea sistemului existent....................................................20 1.6.6. Direcții de perfecționare a sistemului actual...........................................21 1.6.7. Fluxul documentelor informational..........................................................22 Capitolul 2 – Proiectarea de ansamblu a sistemului informatic...............................23 2.1. Definirea obiectivelor și oportunitații sistemului/aplicației informatice.........23 2.2. Orientari generale avute in vedere pentru stabilirea solutiei de informatizare........................................................................................................ 23 2.3. Modelarea conceptuală a datelor..................................................................24 2.3.1. Definirea entitătilor.................................................................................24 2.3.2. Definirea relatiilor dintre entitați.............................................................25 2

2.3.3. Definirea Atributelor................................................................................27 2.3.4. Modelarea logica și fizica a datelor.........................................................27 2.4. Diagrama Entitate - Asociere........................................................................29 2.5. Prezentarea platformei software a noului sistem informatic.........................30 2.5.1. SGBD-ul ales pentru aplicatie..................................................................30 2.5.2. Limbajul de programare..........................................................................30 2.6. Personalul de specialitate și utilizatorii viitorului sistem informatic..............31 2.6.1. Categoriile de utilizatori initial stabiliti sunt urmatoarele:.......................32 2.7. Definirea ieșirilor sistemului..........................................................................32 2.8. Definirea intrărilor sistemului........................................................................35 2.9. Estimarea necesarului de resurse și a calendarului de realizare...................36 Capitolul 3 – Proiectarea în detaliu a noului sistem.................................................37 3.1. Detalierea funcțiunilor si a structurii functionale ale sistemului informatic ..37 În baza proiectării anterioare ale componentelor sistemului vom defini în continuare toate funcţiile pe care aplicaţia le va folosi cât şi modulele pe care aceasta le va avea...............................................................................................37 3.2. Proiectarea logica si fizica a iesirilor.............................................................43 3.3. Proiectarea logica si fizica a intrarilor...........................................................45 3.4. Proiectarea bazei de date..............................................................................45 3.5. Proiectarea ecranului aplicatiei.....................................................................49 3.6. Eficiența economică a sistemului..................................................................50 Capitolul 4 - Prezentarea produsului software, implementarea si exploatarea aplicației..................................................................................................................50 4.1. Cerințele platformei hardware și software ale produsului.............................50 4.2. Descrierea functiunilor aplicatiei...................................................................54 4.3. Mesaje de eroare...........................................................................................64 4.4. Instalarea și implementarea aplicatiei..........................................................64 4.5. Eficienta si utilitatea sistemului informatic....................................................65

3

Capitolul 1 – Studiul, analiza și prezentarea sistemului existent.

Obiectivele şi oportunitatea temei propuse.

Este bine cunoscut în ziua de azi că „sistemul informaţional este un element component

al

automatizarea

sistemului

de management iar

acestuia

prin introducerea

prelucrării,

transmiterii şi stocării automate a datelor dă naştere sistemului informatic” . Orice sistem informaţional modern presupune „includerea technologiilor informatice în activităţile de

culegere, prelucrare şi

transmitere a datelor” . De aceea prezentul studiu îşi propune prin metodologia de proiectare şi programare să îmbunătăţească fluxul de informaţii şi comunicarea desfăşurate între angajaţii departamentului evaluări al firmei Prestige Invest S.A., prin dezvoltarea unui sistem informaţional, centralizat de prelucrare al datelor de intrare şi de împărţire de responsabilităţi. Prezentul proiect a apărut din necesitatea de a avea o metode mai bună de organizare şi

manangement al comenzilor firmei care

datorită numărului mare ajund involuntar la necentralizarea lor ducând la pierderi de bani. Obiectivul fundamental al aplicaţiei constă în furnizarea de informaţii corecte, relevante şi în timp util atât conducerii, cât şi nivelelor operaţionale

specifice departamentului de evaluări, în scopul creşterii

eficienţei organizării. Datorită sistemului de raportare al aplicaţiei se va putea cunoaşte în orice moment pe

bază datelor de intrare numărul de

evaluări spre exemplu realizate către o anumită bancă într-o luna / zi / an de către un anumit agent de evaluări. Aplicaţia

îşi

propune

să

crească

eficientă

departamentului

scăzând timpii de realizare al unui raport şi odată cu un management mai bun al firmei creşterea imaginii acestea pe piaţă în care această îşi desfăşoară activitatea. 4

5

Prezentarea succintă a unităţii economico-sociale.

Firma Prestige Invest S.A. a luat fiinţă la 15/04/2006 având un capital social de 200 RON (având asociaţi persoane fizice a o parte socială = 10 RON a şi asociaţi persoane juridice a 19 părţi sociale = 190 RON). Această a pornit având ca activitate principală aceea de Agenţie Imobiliară (KN7031),

desfăşurându-şi activitatea pe zona

împrejurimi.

Ca

activităţi

secundare

ale

oraşului Bucureşti şi

firmei

se

pot

număra

următoarele : -

Dezvoltare şi promovare imobiliară (KN7011)

-

Cumpărare şi vânzare bunuri imobiliare (KN7012)

-

Închiriere şi subanchiriere subanchiriate

bunuri

imobile proprii

sau

(KN7020) -

Administrare imobil pe bază de tarife şi/sau contract (KN7032)

-

Alte activităţi prestate în special intrprinderilor

(KN7844) La momentul înfiinţării firmă avea patru departamente: -

Evaluări Imobiliare a condus de un manager de departament şi

având în subordine 7 consultanţi imobiliari. -

Agenţie Imobiliară a condus de un manager de departament şi

având în subordine un consultant. -

Administrativ a având un manager de departament.

-

Financiar / Contabil a având un manager de departament şi

având în subordine un economist. Din anul 2002 până în anul 2006 activitatea principală a firmei a fost aceea de Agenţie Imobiliară, clienţii activităţii de evaluări fiind în principal persoane fizice. Începând cu 2006 activitatea departamentului evaluări a crescut şi s-a dezvoltat într-un timp relativ scurt. Preponderent clienţii acestui departament au început să fie băncile şi aceasta a atras în mod corespunzător creşterea exponenţială a numărului de angajaţi ai departamentului acesta ajungând de la 7 la 40.

6

Tot în anul 2006 datorită cerinţelor băncilor de a avea consultanţi ai firmei, local, în diferite zone ale ţării, s-au înfiinţat puncte de lucru în majoritatea oraşelor mari, printre acestea numărându-se oraşe ca Timişoara, Braşov, Cluj, Constanţa, Sibiu, Galaţi, etc. În imobiliare

paralel

cu

dezvoltarea

departamentului

de

evaluări

s-a dezvoltat şi extins şi departamentul de agenţie

imobiliară care şi-a extins numărul de consultanţi la 5, totodată luând amploare şi două alte activităţi ale agenţiei şi anume cel de investiţii imobiliare şi cel de retail. Toate aceste creşteri de personal la nivelul firmei au atras după ele şi creşterea numărului de angajaţi în departamentele Financiar / Contabil şi Administrativ. Dezvoltarea departamentelor în anul 2006 au adus după şine creşterea cifrei de afaceri care după cum se poate observă în următorul grafic a crescut spectaculos faţă de anul precedent. 1.1. Indicatori economici

3.500.000

3.000.000

Cifra de afaceri (RON)

2.500.000

2.000.000

1.500.000

1.000.000

500.000

0 2003

2004

2005

2006

Fig. 1 – Cifra de afaceri a firmei Prestige Invest S.A.

7

2007

1.2. Obiect de activitate 1.2.1. Departamentul Evaluări Imobiliare NAI Property Partners realizează evaluări pentru toate tipurile de proprietăţi, indiferent

că

sunt

pentru

afaceri,

pentru

închiriat,

industriale sau pentru vacanţă. Expertiză firmei acoperă toate regiunile României. Aceste evaluări se fac în principal pentru dispoziţii sau achiziţii, preluări şi mărfuri, revizii contabile sau bilanţ, taxe sau pur şi simpli pentru administrarea mai eficient rapoartele

se

fac

folosind

instituturii de evaluare

afacerea

informaţiile

unei

firme.

Toate

de rigoarea ale unor

cum ar fi : ANEVAR (Asociaţia Romană a

Evaluatorilor cu licenţă) sau RICS (Institutul social al drepturilor evaluărilor). Indiferent de cerere firmă poate oferi sfaturi solide pe piaţă de valori. Firma se bazează pe experienţă directă pe piaţă, datorită echipelor

departamentului

de agenţie care acumulează zilnic noi

informaţii din toate ariile domeniului. 1.2.2. Departamentul Agenție Imobiliară Cu o echipă de agenţi imobiliari în întreagă ţara, NAI Property Partners pune la dispoziţia clienţilor săi o informaţie vastă bazată pe experienţa acumulată de- alungul timpului. Deasemenea firma oferă o gamă largă de servicii developerilor, proprietarilor, de

investiţii,

chiriaşilor şi

instituriilor

persoanelor particulare,

vânzătorilor

pentru

toate

tipurile

de

properietati. Echipa de consultanţi foloseşte standardele internaţionale ale agenţiei ca să ofere clienţilor stafaturi în timp util pentru a implementa şi executa cele mai bune strategii imobiliare, scopul principal fiind acela de a maximiza în fiecare tranzacţie beneficiile clientului. Clienţii firmei beneficiază de asemenea de sistemul de brokeraj al firmei care include căutarea particularilor, programul CRM şi baza de date cu proprietăţi 8

online . Specialităţile firmei includ : -

Agricultura

9

-

Investitii

-

Hoteluri -

Birouri Achiziţionări terenuri

/

vânzări

Rezidenţial Retail În conformitate cu dorinţa firmei de a oferi tot timpul soluţii clienţilor şi bazându-se

pe

experienţa acumulată de-a lungul

timpului firma este calificată pentru : -

Structurare

comparativă

corporativă potrivită

pentru

şi

financiară

organizaţia

-

o

formulă

Clientului

pentru

management, marketing şi sarcini financiare pentru a îmbunătăţi activităţile operaţionale Angajare de personal - evaluarea şi selectarea angajaţilor necesari (management angajaţi)

şi

Servicii de bază - birouri moderne dotate cu internet de mare viteză -

Consultare în administraţia publică - asistentă tehnică în

tratarea şi rezolvarea oricărei probleme legate de administraţia locală şi centrală cum ar fi: obţinerea de permise, aprobări, certificate,

tratarea

cu

firmele

de utilităţi (apă, electricitate,

gaz), autoritatea vamală etc... Asistentă legală pentru cumpărarea şi vinderea de firme.

10

11

1.3. Structura organizatorică 1.3.1. Organigramă

DIRECTOR GENERAL

DEPARTAMENT UL EVALUĂRI

MANAGER DEPARTAMEN T

DEPARTAMENTU L ADMINISTRATIV

MANAGER DEPARTAMEN T

MANAGER DEPARTAMEN T

MANAGER

MANAGER

DEPARTAMENTUL CONTABILITATE

MANAGER

DEPARTAMENTUL IT

DEPARTAMENTUL FINANCIAR/BANCAR

12

MANAGER

CONSULTAN ȚI EVALUATORI

DEPARTAMENTUL RESURSE UMANTE

DEPARTAMENTUL RETAIL

DEPARTAMENTUL INVESTIȚII

MANAGER EXECUTIV

MANAGER EXECUTIV

MANAGER EXECUTIV

CONSULTAN ȚI EVALUATOR I

DEPARTAMENT UL AGENȚIE

Fig. 2 – Organigrama firmei

13

1.3.2. Prezentarea sistemului de conducere Sistemul de conducere prin scopul său este menit să ia deciziile de nivel organizatoric şi să formeze strategii pe termen lung urmând bunul mers al firmei pe piaţa în care îşi desfăşoară activitatea. Societatea Comercială NAI Property Parters are ca principal Manager de nivel

înalt

Directorul

General

urmat

de

managerii

departamentelor instituţiei. Aceştia în urma informaţiilor primite de la managerii

de

nivel

mediu

analizează

situaţia

proiectelor

în

desfăşurare şi cele deja realizate pentru a găsi punţi de dezvoltare şi pentru a stabili strategia de urmat pentru viitor. Deasemenea Managerii departamentelor se asigură de calitatea serviciilor oferite de firma prin fiecare departament menţinând o legătură constanţa

cu

clienţii societăţii şi urmărind realizarea comenzilor la cel mai înalt grad de satisfacţie al clientului.

1.3.3. Prezentarea sistemului condus Sistemul omogene

condus

reprezintă

un

ansamblu

de

activităţi

sau complementare, respectiv identice, asemănătoare sau

înrudite, care au o logică în manifestarea lor propriu-zisă şi contribuie la o mai bună gestionare a resurselor şi creşterea eficienţei de ansamblu a întreprinderii. Acesta este format din managerii de nivel mediu care asigură conducerea operativă întreprinderii.

a

- Departamentul Financiar - Contabil - înglobează activităţile de obţinere şi folosire

raţională

a

disponibilităţilor

băneşti,

controlul

operaţiilor în care s-au investit fonduri băneşti, stabilirea necesarului de mijloace financiare şi găsirea de noi surse de finanţare a activităţii. - Departamentul de Resurse Umane - reprezintă un ansamblu de activităţi care urmăresc procesele la care umane,

adică

se

supun resursele

asigurarea întreprinderii cu forţă de muncă

calificată, recrutarea personalului, selecţionarea, încadrarea, promovarea, specializarea

retribuirea salariaţilor, pregătirea

şi

anagjatilor. De asemenea, în cadrul acestui departament sunt analizate problemele

sociale, de asistentă medicală şi raporturile manager-salariaţi şi sunt incluse activităţi administrative, de secretariat şi protocol. - Departamentul IT - prin rolul sau se are în vedere atât funcţionarea în parametrii normali a tuturor resurselor IT (de la calculatoare, imprimante, telefoane, centrale telefonice digitale, până la prize, cabluri utp, management servere)ci şi organizarea şi achiziţionarea de noi resurse, astfel încât volumul de muncă per angajat să aibă un grafic de creşte exponenţial aducând beneficii materiale firmei. 1.5. Descrierea sistemului actual si direcții de perfectionare În prezent departamentul de evaluări imobiliare din punct de vedere al organizării nu este unitar, însemnând că fiecare manager are o metodă proprie de organizare folosind metode agreate de fiecare. Se doreşte de la noua aplicaţie o unificare a sistemului de management al cererilor printr-o soluţie centralizată şi multiuser stratificata pe niveluri de acces şi structurată pentru un acces cât mai facil la informaţii. Datorită

necesităţii

de

manangement centralizat al

a

avea

o soluţie

de

organizare

şi

comenzilor şi a etapelor lor am ales o

soluţie bazată pe platformă PHP în relaţie cu o bază

de date sub

platforma Microsoft SQL. Datorită accesibilităţii interfaţa WEB bazată pe limbajul Orientat Obiect PHP, combinaţia dintre cele două este o soluţie uşor de implementat necesitând ca aceasta să fie instalată doar pe un SERVER

urmând

ca

utilizatorii

finali

să

folosească

pentru accesare un client web precum Internet Explorer, Mozilla Firefox sau Opera. Proiectarea şi programarea acestei aplicaţii datorită platformei orientate obiect se va face sistematic şi organizat în final garantând timpi minimi utilizaţi pentru căutarea unei informaţii cât şi pentru introducerea sau modificarea unei comenzi din sistem.

1.6. Studiul sistemului informațional 1.6.1. Schema fluxului informațional

INTRĂR I

IEȘIRI

SISTEM DE CONDUCERE (MANAGERI DE CONT)

INFORMAȚI I (CLIENT)

INFORMAȚII (FACTURAR E)

INFORMAȚI I (EVALUAR E)

SISTEM DE CONDUCERE (CONTABILITATE)

SISTEM CONDUS (CONSULTANTI) Fig. 3 – Schema fluxului informațional

1.6.2. Aria de cuprindere (locul) circuitului informațional in cadrul sistemului informațional general al unitatii Dintre este

departamentele

vital departamentului

companiei de

fluxul

evaluări

informaţional,

imobiliare

pentru

care a-şi

desfăşura în bune condiţii activitatea, mai include şi departamentul financiar-contabil. Privind acest flux în cadrul sistemului informaţional general al unităţii, el poate fi considerat ca cel mai important deoarece în

mare

şi

în

eforturile

firmei

sunt

parte către departamentulde direcţia

eficientizării

îndreptate evaluări

demersului

acestui departament.

1.6.3. Documente utilizate In cadrul relatiei cu clienții firmei, de la comanda propriu zisă de a executa o evaluare a unei proprietați și până la executarea practica a evaluarii au loc mai multi pași in care sunt folosite urmatoarele

documente :

Cerere evaluare tip Clientul care poate fi atât persoană fizică cât şi persoană juridică trimite către

firmă

evidenţiate

despre proprietatea

detalii

o

cerere

tip

completă care

va

în

care

urma

sunt

să

fie

evaluată cum ar fi : tipul proprietăţii (casă, apartament, teren, hală etc), suprafaţa în metrii pătraţi a proprietăţii, detalii legate de client (nume, detalii de identificare a

un

telefon

de

contact

pentru

stabilirea legăturii şi data vizitei), cât şi detalii legate de facturare. Această cerere deşi are un scop fix nu are o metodă fixă de intrare în sistemul integrat al firmei, el depinzând în momentul curent de posibilităţile fizice de transmitere ale clientului (fax, poştă, email etc). Documente proprietate Aceste documente sunt vitale pentru evaluarea în curs și pe

care proprietarul este obligat să le aibă pentru ca evaluarea să

poata fi încheiata. Printre aceste documente se numara : Contractul de Proprietate, Certificat Fiscal pentru Cadastru si Intabulare s.a. Document Blank Este un document intern și este reprezentat de prima parte a raportului de evaluare în care sunt prezente (dupa ce a fost facută o vizita în prealabil a proprietații care trebuie evaluată) poze în care proprietatea apare din mai multe unghiuri la exterior, tot aici mai apar și vecinațatile, prezența este și localizarea pe hartă a proprietații în curs de evaluare ca și documentele proprietații primite de la client dupa ce vizita a fost efectuată. Raport Evaluare Reprezintă documentul final al activitații departamentului de evaluări și are la bază toate detaliile despre proprietatea evaluata : poze, localizare, documente proprietate, pe baza carora aplicand 3 formule de calculatie (conform ANEVAR - Asociaţia Evaluatorilor

din

România)

și

a

comparabilelor

Naţională

a

(alte proprietați

asemanatoare cu cea evaluata, și în vecinătatea acestuia) este dat pretul pieții la momentul in care a fost facuta evaluarea respectiva.

1.6.4. Proceduri utilizate În prealabil după ce este primitaă de la client cererea de evaluare tip informațiile sunt colectate de către Managerul de Cont și

sunt

derulate

mai departe

catre

responsabilii

în

firma

cu

evaluările imobiliare pe teren și catre persoanele autorizate în firma cu facturarea din departamentul Financiar-Contabil. Responsabilii cu evaluările imobiliare contacteaza clientul și stabilesc

o întrevedere pentru a putea fi efectuată evaluarea

proprietații. După ce vizita a fost efectuată, vital pentru continuarea activitătii este ca evaluatorul să aibe toate actele proprietații pentru a putea proceda la o evaluare corectă și echitabilă a proprietații. Documentul Blank în care evaluatorul strânge toate detaliile despre proprietate

ajunge în ultim pas la Managerul de Cont care

bazat pe cercetările evaluatorului și folosindu-se

de 3 metode de

calcul stabileste prețul final pentru respectiva proprietate. 1.6.5. Analiza sistemului actual și identificarea neajunsurilor (punctelor critice) existente în funcționarea sistemului existent Sistemul informaţional al departamentului aşa cum se prezintă în momentul de faţă a rămas neschimbat încă de la întemeierea firmei în cauza. Acesta prezintă : - management

deficitar

al

istoricului

evaluărilor

şi

al

evaluărilor în curs datorită faptului că nu există o soluţie unitară în

sistem,

ci

managementul reprezintă alegerea fiecărui angajat în

fluxul informaţional de date să îşi organizeze datele aşa cum consideră de cuviinţă. - neexistenţă unei soluţii de management integrat şi aplicat pe un server dedicat aduce cu sine problema redundanţei datelor. - slaba

organizare

a

datelor

din

punctul

de

vedere

al

posibilităţilor de sortare / căutare / filtrare prin care o informaţie poate fi extrasă într-un timp mai lung sau mai scurt. - neexistenţă unei funcţii de a crea rapoarte în funcţie de client (bancă), Manager de Cont, Consultant sau doar pentru a avea o situaţie asupra numărului de evaluări total pe o zi / luna / an.

1.6.6. Direcții de perfecționare a sistemului actual Soluţia singulară pentru evoluţia afacerii departamentului de evaluări o reprezintă o soluţie integrată, automatizată care să ofere : - management eficace al comenzilor de intrare şi a organizării datelor atât pentru Managerii de Cont cât şi pentru Consultanţi prin distribuirea automată de responsabilitate către un Consultant, de la introducerea în sistem a unei comenzi şi până la terminarea raportului de evaluare. Comanda introdusă în sistem fiind unică şi pentru Managerii de Cont cât şi pentru Consultanţi, aceştia din urmă putând să completeze spaţiile care le revin pentru finalizarea comenzii în sistem. -

notificare prin email la repartizarea unei comenzi de la un

Manager de Cont către un Consultant, pentru o eficientizare şi o optimizare a timpului de realizare a evaluării imobiliare. -

redundanţa datelor prin implementarea soluţiei pe un

server dedicat alături

de

o

soluţie

RAID,

pentru

maximizarea

securităţii datelor, şi un back-up programat zilnic pentru baza de date. -

organizarea maximală a datelor prin implementarea de

funcţii avansate de sortare / afişare / căutare / filtrare a datelor în timpi optimi -

funcţie avansată de generare rapoarte de activitate

-

funcţie

de

mesagerie

internă

pentru

o

comunicare

fluentă între utilizatorii sistemului. controlul eficace al drepturilor fiecăruia în sistem prin implementarea de conturi cu răspunderi controlabile.

1.6.7. Fluxul documentelor informational Cerere Evaluare Imobiliară

Documente proprietate de evaluat

Se centralizează

Se trimit detalii evaluare către consultant

Se evectueaza vizita

Se trimit date facturare către Contabilitate

Se emite factura

Factura Se intocmeste document Blank Se inregistrează detalii client

Se intocmeste raport de evaluare

Lista centralizatoare clienţi

Fig. 4 – Fluxul documentelor

Capitolul 2 – Proiectarea de ansamblu a sistemului informatic

2.1. Definirea obiectivelor și oportunitații sistemului/aplicației informatice Pentru

activitatea

din

cadrul

Departamentului

Evaluări

au

fost stabilite următoarele obiective ale noului sistem informatic: -

Crearea unei posibilităţi de management şi organizare centralizate

a datelor de intrare. Asigurarea redundanţei şi securităţii datelor. -

Automatizarea procesului de schimb de informaţii între membrii departamentelor şi în cadrul acţiunii de atribuire de

responsabilitate. -

Implementarea unui sistem de Rapoarte care va permite o

evidenţa clară a numărului de rapoarte a fost realizat într-o anume perioadă sau de către o anumită persoană. Aplicaţia care urmează a fi dezvoltată se interpune managerii de cont, consultanţii evaluatori

şi

departamentul

contabilitate, creând

o

relaţie

de

automatizată

între

departamentele respective.

2.2. Orientari stabilirea

generale avute in vedere solutiei de informatizare

pentru

Se va avea in vedere în principal în proiectarea soluției de informatizare în principal coerența datelor și a relatiilor dintre acestea. Deoarece sistemul de gestiune a datelor este primordial pentru modul în care aplicația va functiona după ce aceasta va fi definitivată, prin solutia propusă de informatizare firma va beneficia de unul dintre cele mai stabile si performante sisteme de gestiune ale informatiei alaturi de unul dintre cele mai raspandite limbaje de programare Orientat Obiect.

2.3. Modelarea conceptuală a datelor O ramură

foarte importantă în proiectarea unei aplicaţii o

reprezintă modelarea datelor şi a felului în care ele relationeaza între ele. Tehnologia de specialitate a stabilit mai

multe modalităţi prin

care se pot determina structura tipurilor de date cu care se va lucra. Proiectarea şi realizarea unui sistem informatic care presupune prelucrarea automată a datelor necesită, pe lângă activităţile legate de formularea

problemei,

de

analiză

acesteia

în

vederea

găsirii

algoritmului de rezolvare şi o altă activitate, deosebit de importantă, legată de organizarea datelor, în concordanţă atât cu caracteristicile tehnice

ale

prelucrare.

echipamentelor Acestea

trebuie

de

calcul,

să

fie

codificarea şi apoi memorarea lor

cât

şi

structurate

pe suporţi

cu

cerinţele

astfel

tehnici

încât să

de prin

permită

prelucrarile necesare, stocarea şi regăsirea ulterioară a datelor după criteriile stabilite. Legăturile şi relaţiile dintre date poate fi stabilit prin Modelarea Conceptuală a Datelor, această modalitate fiind reprezentată prin modelul

Entitate

a

Asociere (Diagrama Entitate - Asociere sau DEA). 2.3.1. Definirea entitătilor Luând în considerare activitateaaşa cum este ea desfăşuratăîn departamendul de evaluări găsim că: - departamentul

primeşte

prin

diferite

metode

abordate

de clienţi comenzile pentru evaluarea proprietăţilor. - după ce comenzile sunt primite un utilizator introduce datele primite în sistem. Apoi alt utilizator se ocupă de evaluare urmând să completeze cu detalii comanda primită iniţial. - firma are câte un responsabil pentru fiecare client (bancă) cu care aceasta colaborează. - fiecare comandă reprezintă un tip de proprietate care trebuie evaluată Pentru

înlesnirea

comunicării

include şi un sistem de mesagerie.

dintre

utilizatori

aplicaţia

va

Analizând datele culese din modul în care departamentul funcţionează în prezent identificăm următoarele entităţi: - COMENZI - BĂNCI - TIPURI PROPRIETAȚI - UTILIZATORI - MESAJE

2.3.2. Definirea relatiilor dintre entitați

(1,n) UTILIZATO R

(1,1)

BĂNCI

POAT E LUCR A

(1,n)

(1,n)

POATE APARTIN E

POAT E AVEA

TIP PROPRIETATE

(1,n) POATE FI

(1,1) (1,1)

MESAJ E

COMENZ I

Fig. 5 – Relații intre entitați

(1,1)

2.3.3. Definirea Atributelor După ce au fost definite și corelate relațiile dintre entitătile ce urmeaza a fi implementate

în baza de date fizica, urmeaza a fi

definite și atributele fiecarei entităti prin care se vor crea respectivele legături. În cele ce urmeaza se vor defini atributele pentru fiecare entitate: CONTINUT (Comanda) - id, Account_Manager, Banca, Data_Comanda, Nume_Client, Adresa_Client,

Telefon_Client,

Banca_Client,

CNP_RegCOM,

Nr_Inreg_Fiscala,

Sucursala_Banca, Tip_Proprietate,

Cont_Banca,

Persoana_Contact,

Telefon_Contact,

Consultant_Delegat,

Data_Vizita,

Data_Raport_Complet. UTILIZATOR - id, accType, userName, userEmail,

US,

defaultuserResPerPage, userResPerPage, userFields, defaultuserModify,

defaultuserFields, userModifyC,

defaultuserView, userAdd,

PS, userBanks,

userModify, defaultuserModifyC,

userView,

defaultuserAdd, userDelete,

defaultuserDelete, userPostNav, defaultuserPostNav,userSort, defaultuserSort,

userSortDir, defaultuserSortDir,

userMessages, defaultuserMessages, userReports, defaultuserReports. MESSAGES - id, userFrom, userTo, userMessage, userMessageTitle, data BANKS - id, Banci PROPTYPE - id, Proprietati

2.3.4. Modelarea logica și fizica a datelor Modelarea modului

conceptuală

a

datelor

defineşte

reprezentarea

de organizare a datelor independent de tehnologiile de

prelucrare a acestora şi fără a acordă o atenţie deosebită

calităţii

modelului datelor. Modelul conceptual este prezentat prin intermediul diagramelor Entitate a

Asociere

şi

evidenţiază reprezentarea logică, detaliată a entitatilor, a asocierilor şi a datelor elementare din

cadrul sistemului obiect. Procesul de modelare logică a datelor se desfăşoară în paralel cu

celelalte activităţi de proiectare, cum sunt

proiectarea rapoartelor, a machetelor de introducere a datelor, a interfeţei. 2.4. Diagrama Entitate - Asociere Are

1,n

1,1

UTILIZATO R

COMENZ I

userNam e

Account_Manag er Tip_Proprietate Banca

1, 1

Include

1, n

1,n

1,1

Primest e

BĂNCI Banci

Are 1,n

1,1 MESAJE 11111

TIP PROPRIETATE

userFrom

Properietati

Fig. 6 – Diagrama Entitate – Asociere

Relațiile dintre tabele : Utilizator-Mesaje –> PK userName FK user From Utilizator-Comenzi -> PK userName FK Account_Manager Tip Proprietate-Comenzi -> PK Proprietati FK Tip_Properietate Banci-Comenzi -> PK Banci FK Banca

2.5. Prezentarea platformei software a noului sistem informatic Alegerea unui SGBD care să fie nu numai compatibil din toate punctele de vedere cu sistemul în care va urma sa se programeze aplicația informatică este de mare importanță totodată aceasta relație între cele două oferind și calitatea și simplitatea folosirii de zi cu zi a aplicatiei.

2.5.1. SGBD-ul ales pentru aplicatie Pentru dezvoltarea

aplicaţiei

s-a

optat

pentru

Sistemul

de

Gestiune a Bazelor de Date Microsoft SQL, datorită platformei stabile şi mamagementului facil şi exploatării în condiţii de securitate. Un alt motiv pentru alegerea acestui SGBD este acela că firma deţine în prezent o unealtă de gen CRM de la Microsoft numită NAVISION (sau Microsoft Dynamics NAV), care are deasemenea ca SGBD la bază, Microsoft SQL, iar dorinţa conducerii firmei doreşte ca în viitor să fie dezvoltat şi un modul pentru crearea unei punţi de legătură între aplicaţia

ce

urmează

a

fi dezvoltată

şi

NAVISION.

Prin

aceasta

firmă urmăreşte că atât aplicaţia cât şi NAVISION să beneficieze de aceleaşi informaţii referitoare

la clienţii

firmei şi la detaliile de

facturare, aceste detalii fiind introduse o singură data în sistem. 2.5.2. Limbajul de programare Aplicația care urmează a fi proiectată și programată va folosi ca și platformă software din punctul de vedere al sistemului de operare Microsoft Vista / XP. Dar privind la faptul că platforma limbajului

de

programare este o platforma care poate fi implementată practic pe orice sistem de operare, portarea aplicației de pe un server bazat pe Windows la unul bazat pe Unix nu va fi o procedură foarte complexă. Aplicația va necesita pe langă accesul la un server cu baza de date Microsoft SQL și de platformele PHP și APACHE instalate și configurate pentru ca aplicația să poata fi accesată practic de oricine, printr-un user si o parolă. Organizarea bazei de date va fi facută conform specificațiilor celor trei forme normale. Nu in ultimul rând se va urmari ca baza de date să aibe o structură

logică pentru a facilita accesul la informațiile stocate în ea în cel mai scurt timp. Se va avea în vedere și structurarea tabelelor astfel încat ele relationeze intre ele. Aplicația va avea la baza de un limbaj de programare larg raspandit, el apartinand

platformei WEB fiind foarte asemanator in

sintaxa cu C++. Limbajul PHP ofera o gama larga de functii predefinite dar ofera si posibilitatea de a putea crea functii si clase conform metodologiei de programare Orientata Obiect. PHP este un limbaj de programare destinat în primul rând Internetului, aducând dinamică unei pagini de web. Este unul din cele mai importante limbaje de programare web

open-source şi server-

side. PHP a parcurs o cale lungă în decursul ultimilor ani. Dezvoltarea până la nivelul unuia din cele mai proeminente limbaje care dirijează Web-ul nu a fost o sarcină uşoară. PHP este simplu de utilizat, fiind un limbaj de programare structurat, ca şi C-ul, Perl-ul sau începând de la versiunea 5 chiar Java, sintaxa limbajului fiind o combinaţie a celor trei. Datorită modularităţii sale poate fi folosit şi pentru a dezvolta aplicaţii de sine stătătorare. Probabil una din cele mai importante facilităţi ale limbajului este conlucrarea cu majoritatea bazelor de date relaţionale, de la MySQL şi până la Oracle, trecând prin MS Sql Server, PostgreSQL, sau DB2. PHP poate rula pe majoritatea sistemelor de operare, de la UNIX, Linux, Windows, sau Mac OS X şi poate interacţiona cu majoritatea servereler web.

2.6. Personalul de specialitate și utilizatorii viitorului sistem informatic Ca oricare altă aplicație profesională din domeniu dezvoltată pâna acum, care va trebui sa faca legatura intre mai multe tipuri de utilizatori necesitatea de a avea

o imparțire pe tipuri de conturi cu

diferite drepturi de a modifica informațiile stocate devine o cerință obligatorie. Desi aplicația va avea initial patru

categorii principale

de

utilizatori posibilitațile de a costumiza aplicația din punctul acesta de vedere nu se opresc aici. S-a avut în vedere ca aplicația per total să poată fi modificată / utilizată în felul în care firma decide să fie folosită sau chiar utilizatorul să poată avea posibilitatea de a-și alege cum va fi folosită aplicația de catre el.

2.6.1. Categoriile de utilizatori initial stabiliti sunt urmatoarele: Administrator Această categorie de utilizator caracterizează o persoană de specialitate care se va ocupa în mare de mentenanţa sistemului şi care va avea grijă ca sistemul să funcționeze în parametrii normali el totodată având drepturi totale pentru toate funcţionalităţile pe care aplicaţia le pune în folosinţă. Supervisor Prin supervisor înţelegem o persoană responsabilă care are scopul precis şi prestabilit

de

a

monitoriza

toată

acţiunea

utilizatorilor din sistem şi totodată asigurând corectitudinea datelor introduse în sistem. La dorinţa utilizatorului supervisor se vor putea scoate din sistem rapoarte de activitate pe fiecare utilizator din sistem, pe o anumită perioadă, iar posibilităţile funcţiei de raport nu se opresc aici. Account Manager Un alt utilizator important în sistem prin faptul că el va fi responsabil de toate

comenzile

introduse

în

sistem.

Account

Managerul este persoană care primeşte comenzile venite din partea clienţilor

şi

se

ocupă

atât

de

adăugarea comenzilor cât şi de

distribuirea informaţiilor necesare procesului de evaluare cât şi de managementul şi supervizarea activităţii până aceasta va ajunge la o finalitate. Consultant Luată în ordinea funcţiilor din sistem utilizatorul Consultant poate părea mai lipsit de importantă dar nu e aşa. După ce acestuia îi este distribuită o comandă prin sistemul informaţional acesta va purcede la finalizarea comenzii prin raportul pe conchide

ciclul

de

realizare

al

care unei

îl

va

evaluări

întocmi

şi

va

în departamenul

specific din firmă. 2.7. Definirea ieșirilor sistemului Obiectivele

oricărui

satisfacerea cerinţelor

sistem

informatic

informaţionale

ale

se

concretizează

coducerii,

în

precum

fundamentarea sau asistarea

deciziilor,

adică

însemnând

furnizarea

la

cere

sau

periodic

a

situaţiilor, a rapoartelor de ieşire care grupează informaţii, date necesare cunoaşterii

realităţii curente.

Pe

bază

aceastora

se

fundamentează

deciziile pentru dirijarea funcţionării viitoare a unităţii economice. Utilitatea şi viabilitatea sistemului informatic este dereminata de tipul, conţinutul şi operativitatea cu care se transimt situaţiile de ieşire la factorii de decizie. Pentru a fundamenta şi a concretiza atât cerinţele unui sistem informatic modern cât şi cerinţele conducerii firmei pentru care se dezvoltă

aplicaţia

se propune dezvoltarea unui modul de raportare,

care prin modalitatea în care va fi dezvoltat va permite la dorinţa unui utilizator al sistemului să genereze date de ieşire din sistem, acesta nefiind limitat de o metodă fixă de sustragere de informaţii ci mai degrabă utilizatorul va beneficia de un sistem dinamic totuşi în acelaşi timp exact prin care un utilizator să poată scoate exact ceea ce are nevoie din sistem. Practic fiecare utilizator al sistemului va dori la un moment dat în timp să poată extrage din sistem informaţii referitoare la raportul de activitate personal, sau a persoanelor în subordinea persoanei în cauza. De aceea în continuare vom defini

pentru

fiecare tip

de

utilizator în parte tipurile de rapoarte necesare şi perioadă de timp la care vor fi acestea de folos.

CONȚINUT INF.

ACCOUNT MANAGER PERIODICITATE NR. EXEMPLARE

Raport per Bancă Raport per Consultant

CONȚINUT INF. Raport per Bancă

Luna r Săptămanal

1 1

SUPERVISO R PERIODICITATE NR. EXEMPLARE Lunar, 1 Săptămanal

DESTINATAR Banc a Account Manager

DESTINATAR Supervisor

Raport per Consultant Raport per Account

Lunar, Săptămanal Lunar, Săptămanal

1

Supervisor

1

Supervisor

Manage

CONȚINUT INF. Raport per banca

CONSULTAN T PERIODICITATE NR. EXEMPLARE Lunar, 1 Săptămanal

DESTINATAR Consultant

2.8. Definirea intrărilor sistemului Intrările sistemului informatic reprezintă totalitate datelor primare necesare obţinerii informaţiilor de ieşire ale sistemului. Datele primare

reflectă

starea

şi dinamica

fenomenelor

şi

proceselor economice din unitatea economică, necesare pentru crearea, actualizarea bazei de date şi obţinerea situaţiilor de ieşire. Acestea pot fi exerne sau interne firmei. În urma analizării atente a fluxului informaţional din prezent al firmei şi din punctul de vedere al organizării noului sistem informatic, aplicaţia va avea ca informaţii de intrare, datele referitare la client şi la proprietatea care urmează a fi evaluată. Structură datelor de intrare va fi următoarea : - BANCA (cea care apelează la firmă pentru evaluarea unei proprietăţi şi care oferă detaliile despre client şi proprietate) - DATA COMENZII - NUMELE CLIENTULUI - ADRESA CLIENTULUI - TELEFONUL CLIENTULUI - CNP / NR. REGISTRUL COMERŢULUI (în funcţie de caz) - NR ÎNREGISTRĂRII FISCALE (după caz) - BANCA CLIENTULUI (după caz) - SUCURSALĂ PENRU BANCĂ CLIENTULUI (după caz) - CONT BANCĂ (după caz)

- TIP PROPRIETATE - PERSOANĂ CONTACT (în cazul în care clientul este persoană juridică, cel care solicita evaluarea nu este proprietarul sau persoana de contact este singură persoană aflată la locul proprietăţii în vederea evaluării) - TELEFON PERSOANĂ CONTACT - DATA VIZITĂ (detalii completate ulterior) - DATA RAPORT COMPLET (detalii completate ulterior) În bază informaţiilor de intrare se pot crea rapoarte de ieşire din sistem sau aşa cum repartizată

mai

ciclul

apoi

departamentului

către

arată,

o

cerere

este

un consultant în vederea continuării

procesului de evaluare imobiliară.

2.9. Estimarea necesarului de resurse și a calendarului de realizare Resurse Hardware Pentru a accelera procesul de proiectare va fi nevoie de 3 computere dotate cu procesoare de ultimă generație, Intel Core 2 Duo sau echivalent, 1GB Ram și 100 GB HDD, care vor rula în paralel. În acest fel procesul de proiectare va scădea la jumătate. Resurse software Ca și resursă software este necesar ca fiecare computer să fie dotat cu sistem aplicația

va

fi

de

operare

Microsoft

Windows

XP

(deoarece

proiectată pentru platforma Windows), alături de

MSSQL Server 2005 și de serverul APACHE plus PHP. Resurse umane Un inginer proiectant pentru Baza de Date, un inginer proiectant pentru punerea la punct al ieșirilor / intrărilor, un inginer proiectant pentru clasele / modulele aplicației. Resurse financiare Se estimează o suma de proiectare / programare / implementare de 30.000 euro.

Calendarul de realizare al sistemului informatic

Asamblar e component e 15

Inserare date 2

Baza de date 25

Clase / Membrii 20

Module 30

Fig. 7 – Calendar de realizare a proiectului informatic (zile)

Estimare total numar zile pentru elaborarea proiectului Se estimeaza un total de aproximativ 92 de zile

Capitolul 3 – Proiectarea în detaliu a noului sistem

3.1. Detalierea funcțiunilor si a structurii functionale ale sistemului informatic În baza proiectării anterioare ale componentelor sistemului vom defini în continuare toate funcţiile pe care aplicaţia le va folosi cât şi modulele pe care aceasta le va avea. Luate în ordinea în care acestea au fost necesare definim următoarele metode ale clasei „ServConn” (listarea metodelor va fi pusă la dispoziţie în „ANEXA 1” a acestei licenţe):

Zonă privată a clasei - definirea variabilei „SrvAddr” - în această variabila vor şi stocate atât adresă ip de conectare la serverul de MSSQL (în cazul de faţă aplicaţia va fi instalată pe acelaşi server ca şi SGBD-ul deci adresă va fi „localhost”) cât şi portul prin care se va face conectarea. - definirea variabilei „SrvUser” -

această variabila va stoca

userul de conectare la baza de date. - definirea variabilei „SrvPass” - această variabila va stoca parola de conectare la baza de date. - definirea variabilei „SrvDB” - această variabila va stoca numele bazei de date la care se va face conectarea. - definirea variabilei „sqlconn” - această variabila va stoca legătura

la funcţia

php

de

conectare

la

baza

de

date

„mssql_connect” apelată în funcţia definită mai jos „Conn()”. - definirea variabilei „db” - această variabila va stoca legătura la funcţia php de conectare la bază de date „mssql_select_db” apelată în funcţia definită mai jos „Conn() ”.

Zona publică a clasei - definirea variabilei „result” - în urma apelării uneia dintre celor 4 funcţii definite, de

query, la baza de date: „advQuery()”,

„upQuery()”, „insQuery()”, „delQuery()”, respectiva funcţie apelată va crea un link în variabila result către rezultatul query-ului, urmând ca apoi variabila să poată fi apelată de către una dintre funcţiile de parcurgere de date şi a se afişa un rezultat. - definirea funcţiei „Conn()” - în urma apelării funcţiei se va face legătura între scriptul programat şi baza de date. - definirea funcţiei „advQuery()” - funcţie avansată cu multiple opţiuni de query, va face că această să fie una dintre cele mai importante funcţii din sistemul proiectat. Funcţionalitatea acestei funcţii va fi de „SELECT” în bază de date.

- definirea funcției „upQuery()”

–

funcție definită cu

opțiuni pentru modificarea de date deja existente în baza de date - definirea funcței „insQuery()” – funcție definită pentru a fi folosită la introducerea de date în baza de date - definirea funcției „delQuery()” – funcție definită pentru a fi folosită la ștergerea de informații din baza de date - definirea funcției „closeConn()” - funcție

care

va

actiona

închiderea conexiunii cu baza de date atunci cand nu va mai fi nevoie de aceasta - definirea funcției „userDetailes()” – funcție care va prelua informațiile despre user (drepturi, user, parola, nume...etc) dupa pagina de login - definirea funcției „fieldName()” – va returna numele campului pe un rând în funcție de o variabila indice de tip INT (0 = campul 1, 1 = campul 2...etc) din query-ul curent - definirea funcției „fieldLength()” -

va returna marimea

câmpului pe un rând în funcție de o variabilă indice de tip INT (0 = campul 1, 1 = campul 2...etc) din query-ul curent - definirea funcției „fieldsNumber()” – va returna numarul de câmpuri rezultate în urma unui query - definirea funcției „rowsNumber()” – va returna numărul de rânduri rezultate în urma unui query - definirea funcției „fieldRows()” – va returna într-o variabilă de tip ARRAY toate rândurile returnate dintr-un camp - definirea funcției „affRows()” – verifică și returnează numarul de câmpuri afectate în urma unui query - definirea funcției „queryResultsPag()” – în baza unor opțiuni prestabilite se va calcula în urma apelarii funcției numarul de pagini care vor fi afișate în urma query-ului stabilit de

utilizator. Această

funcție face și apel la funcția advQuery pentru a face paginația rezultatelor și afișerea în modulul „Tabela” numarul de pagini și navigașia aferentă.

- definirea funcției "genQuery()” – Aplicată în modulul de căutare și în cel de rapoarte, genereaza dinamic în funcție de numarul de câmpuri (pe care se vrea sa se facă o căutare sau sa se afișeze un raport) și în funcție de numărul de cuvinte (pe care se face căutarea) o funcție nouă în fișierul „functie-temp.php” care la rândul ei va genera query-ul în baza de date pentru a returna cat mai fidel ce s-a vrut să se caute. - definirea funcției „sendMail()” modulul de adăugare mesaje

interne,

–

funcție folosită atat de

de comenzi în baza de date cât și de cel de

pentru

a trimite mesaje de notificare pe email

persoanelor implicate în respectiva actiune În continuare se vor defini modulele

sistemului, în ordine

alfabetica, cu funcționalitatea fiecaruia : - definirea modulului „actiuni.php” – detine toate acțiunile care se fac de catre aplicație (adăugare, ștergere, updatare...) practic în acest

fisier

se

fac

apelările la toate funcțiile definite în clasa

„classConn()” - definirea modulului „adauga.php”

- reprezintă modulul de

adăugare de comenzi în baza de date. Acest modul este corelat cu modulul „actiuni.php” pentru a duce la îndeplinire acțiunea de adaugare comanda. - definirea modulului „addmoddelAdmin.php” – reprezintă modulul contului administrator, care îi permite acestuia să aplice modificări în baza de date, în tabelele de

comenzi, utilizatori, bănci și tipuri

proprietate. Acest modul este corelat cu modulul „actiuni.php” pentru a duce la îndeplinire acțiunile definite în modul. - definirea modulului „afiseaza.php” se

ocupă

de

afișarea

/

ascunderea

de

reprezintă modulul care campuri

în

modulul

„tabela.php”, la acțiunea userului. Acest modul este corelat

cu

modulul „actiuni.php” pentru a duce la îndeplinire acțiunea definita în modul. - definirea modulului „app.php” – reprezintă modulul principal care face legatura cu toate celelalte module. Aici sunt afișate atat structura aplicației cât și toate modulele funcționalitatile lor.

cu

- definirea modulului „cauta.php” – reprezintă funcția de cautare

a sistemului

„genQuery()”

informațional.

Aceasta

bazându-se

pe

funcția

afișeaza rezultate în funcție de un numar nelimitat de

cuvinte și campuri. Acest modul este corelat cu modulul „actiuni.php” pentru a duce la îndeplinire acțiunea definita în modul. - definirea modulului „erori.php” – conține erorile care apar în sistem pe tot parcursul folosirii acestuia. - definirea modulului „index.php” – reprezintă primul modul al sistemului în care este

verificată autorizarea unui utilizator de a

opera modificări / vizualiza sistemul. -

definirea

modulului

care include meniul

în

„meniu.php”

urma

modulele „tabela.php”,

căruia

–

reprezintă

sunt

modulul

apelate

„adauga.php”,

„afiseaza.php”, „cauta.php”, „mesagerie.php”, „rapoarte.php”, „setari.php”. - definirea modulului „mesagerie.php” – în acest modul este conținuta o modalitate de a crea o mai buna legatură între utilizatorii sistemului prin scurte mesaje. - definirea modulului „rapoarte.php” – aici este conținut motorul de raportare prin care un utilizator poate genera rapoarte nefiind limitat în optiuni. Acest modul este corelat cu modulul „actiuni.php” pentru a duce la îndeplinire acțiunea definita în modul. - definirea modulului „raport.php” – modulul care se ocupa cu afișarea rapoartelor în format pregatit pentru printare sau salvare în alt format (ex: PDF) Acest modul este corelat cu modulul „actiuni.php” pentru a duce la îndeplinire acțiunea definita în modul. -

definirea

modulului

„setari.php”

–

conține

opțiunile

utilizatorului de a modifica și salva unele din setările inițiale cu care a fost creat userul. Printre ele se numără : sortarea

campurilor din

modulul „tabela.php” în funcție de un anumit camp afișat cât și direcția (crescător, descrescător) a acesteia, afișarea / ascunderea unor campuri selectate de utilizator, numarul de înregistrari afișat per pagina ș.a.

Acest modul este corelat cu modulul „actiuni.php” pentru a duce la îndeplinire acțiunile definite în modul. - definirea modulului „tabela.php” – reprezintă prima imagine pe care unu utilizator o vede cand se înregistreaza cu contul sau. Conține afișarea de comenzi din baza de date, pe care le-a adaugat el. Pe langa aceste funcții și module au mai fost definite doua alte fișiere pentru a folosi la dinamicitatea sistemului și modului de afișare. S-au definit în fișierul „functii-inc.js” funcții javascript pentru validarea unor campuri și pentru interschimbarea unor module fara a fi nevoie de reînprospatarea paginii principale. Deasemenea a fost definit și un fișier „style.css” conținand formatarile tabelelor din aplicație.

3.2. Proiectarea logica si fizica a iesirilor Ieşirile sistemului informatic au fost definite la nivel global în

cadrul proiectului de ansamblu, care precede şi pregăteşte

proiectarea în detaliu. Ieşirile sistemului informatic conţin rapoarte generate din sistem în urma cărora se poate observa atât direcţia firmei dar se poate

face şi o evaluare a fiecărui angajat în parte.

Modulul proiectat pentru rapoarte poate genera următoarele tipuri de rapoarte : - Raport Analitic - acesta poate fi reprezentat în sistem prin situaţia evaluărilor pe o perioadă data de utilizator, o zi / mai multe , o luna / mai multe, pe o anumită bancă. - Raport de us intern - poate fi reprezentat în sistem prin cererea Directorului firmei de a afla numărul de vizite făcute într-o luna / zi / an de către un agent evaluator. - Rapoarte periodice - la solicitarea clienţilor (bănci) sistemul poate returna la acţiunea utilizatorului raport de activitate pentru a putea fi trimis clientului.

Proiectarea logica de detaliu a ieșirilor Pentru fiecare din tipurile rapoartelor de mai sus a fost definit un tip unitar de raport reprezentată in Fig. 8

Fig. 8 – Exemplu raport iesire

Proiectarea fizica de detaliu a iesirilor Rapoartele ieşite din sistem vor avea următoarea formă : - Conform Fig. 8 în partea de sus a formei se va afla titlul reprezentat în exemplu de « Raport de activitate » - Rândul imediat următor conţine un rând de informare cu privire la ce s-a căutat (vrut) a se afişa prin raportul cerut, cât şi numărul de rânduri pe care acest raport l-a generat. - Sub acest rând se află detalii legat de data / oră când raportul a fost cerut - Ultima reprezentare a machetei de ieşire o are tabelul în format n X m (n reprezentând numărul de câmpuri, m reprezentând numărul de rânduri rezultate în urma raportului +1) După generarea raportului în funcţie de instrumentele instalate pe sistem, poate fi salvat sub formă de PDF sau JPG sau poate fi printat. Datorită faptului că până la momentul prezent un gen de document care să reprezinte un tip de raport nu a existat în firmă o cerinţa explicită de a avea un format concret , prestabilit nu a fost înregistrată la data analizării sistemului.

3.3. Proiectarea logica si fizica a intrarilor După ce acestea au fost definite în cadrul proiectării de ansamblu, acestea urmează a fi detaliate. Sistemul va funcţiona în felul următor : - Clientul trimite o comandă sub formă electronică, fie că aceasta este sub formă de email sau fax. - Detaliile incluse în această cerere sunt următoarele : Bancă, Data_Comandă, Numele Clientului,

Adresă

Clientului , Telefonul Clientului, CNP sau Nr. Reg. COM, Nr. Inreg. Fiscală, Banca Clientului, Sucursală Băncii, Cont Bancă, Tipul Proprietăţii, Persoană Contact, Telefon Contact. Aceste detalii vor fi completate în continuare cu: Data Comandă şi Consultant Delegat de către Account Manager iar Consultantul va completa şi el la rândul lui Data Vizită şi Data Raport Complet. Pentru a se introduce în sistem o comandă se va folosi formularul de la fig. 9 prezent în informatică :

noua

soluţie

Fig. 9 – Formular de intare în sistem a datelor despre comandă 3.4. Proiectarea bazei de date Pentru definitivarea proiectării bazei de date începută în capitolul proiectării de ansamblu, pe baza detaliilor deja prelucrate despre entităţi şi atributele lor se vor proiecta în continuare tabelele care vor face parte integrantă a sistemului nou. Numele bazei de date este A« MNGMApp A« . În anexe va fi ataşat query-ul SQL pentru crearea atât a bazei de date cât şi pentru crearea tuturor tabelelor folosite

în aplicaţie. (alături de restricţii, setări notNull, câmpuri autoincrement etc). Aşa cum a fost menţionat şi în cadrul proiectării de ansamblu, ca

bază

de

date relaţională a fost ales SGBD-ul Microsoft SQL Server

2005. Tabela appBanks

T

Tabela appContinut

Tabela appUsers

Tabela appBanks

Tabela appPropType

Relatiile dintre tabele

3.5. Proiectarea ecranului aplicatiei. Prin modalitatea în care a fost structurate interfaţa s-a căutat ca ea să îndeplinească condiţii :

următoarele

- Proiectarea s-a făcut ţinând cont şi de utilizatorul nespecialist în informatică, interfaţa fiind foarte sugestivă şi uşor de utilizat. - Mediul grafic este complex şi complet totuşi s-a avut în vedere a nu se aglomera ecranul cu elemente grafice, pentru ca scopul principal să rămână utilizarea facilă a aplicaţiei. - Interfaţa este autoadaptabila pentru toate tipurile de monitoare, sa luat în considerare folosirea de către utilizator a unui monitor mai mare decât cel pe care a fost proiectată iniţial interfaţa. -

Atractivitatea

interfeţei

este

un

alt

punct

forte

al

aplicaţiei

dezvoltate această beneficiind de un colorit plăcut la vedere, fără combinaţii ţipătoare neaglomerata de

prea

multe

elemente

de

grafică. S-a mers pe ideea că simplitatea atrage întotdeauna. - Interfaţa este atât uşor de învăţat pt a se lucra cu ea şi în aceeaşi măsură şi de utilizat. - Datorită dinamicităţii de care aplicaţia dă dovadă, utilizatorul va avea destul de multe

modalităţi prin care să poată să îşi configureze

modalitatea

care programul este afişat

în

totodată putând salva

aceste setări ca setări implicite per utilizator.

Fig. 10 – Ecranul principal al aplicatiei

3.6. Eficiența economică a sistemului Aplicatia realizată în cadrul societații Prestige Invest S.A. va fi destinată să serveasca managementului activitatii de evaluari imobiliare. Această aplicație informatică are ca obiectiv crearea unui mijloc modern de organizare al informației centralizate si relationate. În mod absolut pasul de a investi într-o aplicație care desi costa o anumită cantitate de

bani, acești bani se vor recupera însa prin

timpul mult mai mic de utilizare, estimarea fată de sistemul actual este că timpul de a realiza un raport de evaluare va scadea semnificativ datorită automătizarii relatiei Account Manager – Consultant

și

prin

managementul de exceptie adus de aplicație. Totodată securitatea dadelor nu este nici ea pe un loc nesemnificativ. Cerintele informaționale ale unitații economico –sociale sunt pe deplin satisfacute de sistemul informatic dezvoltat, ea acoperind de departe situația curenta și îmbunatatind aspecte importante în utilizarea

aplicației

cum

ar

fi usurința in utilizare, interfața

prietenoasa si intuitiva.

Capitolul 4 - Prezentarea produsului software, implementarea si exploatarea aplicației 4.1. Cerințele platformei hardware și software ale produsului Aplicația pentru a fi exploatata in condiții de securitate și optimizare va trebui sa respecte urmatoarele cerințe minime atât pentru sistemul persoanei care va opera aplicatia cât si pentru serverul unde va fi gazduita aplicatia: Cerinte minime server: Hardware - pentru a funcţiona în parametrii optim se cere ca serverul să aibe un processor de minim 2 Ghz (Pentium 4 sau echivalent), 2 Gb memorie RAM, 500 Gb HDD. Datorită faptului că SGBD-ul de la Microsoft este o unealtă complexă utilizarea acestuia în parametrii optima necesită multe resurse ale sistemului să fie îndreptate către serverul SQL. Deasemeni

pentru redundantă datelor şi securitatea

lor este necesar un HDD de capacitate mai mari deoarece serverul SQL va fi programat astfel încât să facă automat un back-up al bazei de date odată pe zi, de preferat după terminarea programului de lucru. Deasemenea un amănunt foarte important pentru funcţionarea sistemului în condiţii optime îl are şi locaţia unde serverul va fi instalat. De preferat să existe un loc special amenajat (un DataCenter) unde se ţin toate serverele indiferent de utilitatea respectivului server în reţeaua locală / internet. De preferat ca serverul să fie ţinut la o temperaturi între 10-20 grade Celsius. Software – platforma software recomandată pentru funcționarea sistemului este Microsoft Windows 2003 Server, datorita funcțiilor avansate de server și stabilitații în functionare. (platforme mai vechi cum ar fi Microsoft Windows 2000 Server SP1 nu au fost testate pentru funcționalitatea cu aplicația dezvoltata). Cerinte minime client: Hardware – cerințele de sistem sunt dupa cum urmeaza : processor de minim 1.5 Ghz (Pentium 4 sau echivalent), 1Gb memorie RAM, 60 Gb HDD. Software -

platforma pe care sistemul va funcţiona este

Microsoft Windows, fie că el este Windows XP sau

Vista

platform

mai

viitoare

(de mentiontionat că versiunile

sau

o

vechi de

Microsoft Windows nu au fost testate pentru funcţionalitate împreună cu noul system). Alături de cerinţele legate de sistemul de operare pentru funcţionarea aplicaţiei clientul

va necesită

un client WEB că Internet Explorer, Mozilla Firefox, Operă s.a.spune. Se recomanda că, pentru cea mai bună experienţă din punct de vedere al vitezei de execuţie a programului şi a rezultatelor returnate din bază de date, atât aplicaţia cât şi bază de date să fie instalate pe acelaşi server, iar serverul să fie găzduit

în

intranet-ul

firmei,

acces direct spre internet pentru a putea fi accesibilă aplicaţia evaluări din ţara.

şi

de

reprezentanţii

departamentului

cu

4.2. Descrierea functiunilor aplicatiei Prezentarea principal

ecranului

Fig. 11 – Meniul aplicatiei

În Fig. 11 avem reprezentat ecranul principal al aplicației care apare de fiecare dată când un user intră în sistem. Cum este el afișat și ce acțiuni pot avea loc în acest ecran ține de setările individuale per fiecare user. Acțiunile standard pe fiecare dintre tipurile standard de useri în parte : Consulta nt - Poate modifica doar câmpurile « Data_Vizita » și « Data_Raport_Complet » (modificarea se efectuează în ecranul principal) - Poate scoate rapoarte din sistem bazat pe ce a facut el. Nu poate vedea nici prin sistemul de rapoarte sau prin modulul de cautare alte comenzi decat cele repartizate lui. - Are acces la sistemul de mesagerie în sistem Account Manager - Poate modifica orice camp al comenzilor din

sistem (modificarea se efectuează în ecranul principal)

- Poate adăuga comenzi noi în sistem - Poate scoate rapoarte din sistem bazat pe ce a facut el. Nu poate vedea nici prin sistemul de rapoarte sau prin modulul de cautare alte comenzi decat cele introduse de el. - Are acces la sistemul de mesagerie în sistem Administrat or - Prin statutul pe care îl are, acest user are acces la meniul Admin putând : - adăuga / modifica / șterge useri din sistem - adăuga / modifica / șterge banci din sistem - adăuga / modifica / șterge tipuri proprietate din sistem - Poate modifica orice câmp al comenzilor din sistem. Poate șterge orice comandă înregistrată sistem

în

(modificarea se efectuează în ecranul principal) - Poate adăuga comenzi noi în sistem - Poate scoate rapoarte din sistem nefiind limitat - Are acces la sistemul de mesagerie în sistem Supervis or - Poate modifica orice camp al comenzilor din sistem (modificarea se efectuează în ecranul principal) - Poate scoate rapoarte din sistem nefiind limitat - Are acces la sistemul de mesagerie în sistem Optiuni comune - Poate căuta o comandă în sistem - Poate modifica numarul de câmpuri afișate în panoul

principal - Poate modifica sortarea comenzilor afisate în functie de un anumit câmp, ascendent sau descendent - Acces la meniul setări. De unde se poate seta numărul de înregistrari afișate pe pagină .

Prezentarea meniurilor aplicatiei Meniul ADAUGĂ Acest meniu este considerat ca fiind cel mai important dintre meniurile de adaugare date în sistem (date de intrare). Conține

toate

detaliile

pentru

ca

o

comandă

să

poată

fi

considerată ca atare și să se continue prin vizita consultantului. Tot aici (Fig. 12) din cate se poate observa se face distribuirea comenzii catre un consultant.

Fig. 12 – Meniul adaugă

Meniul AFIȘEAZĂ Din meniul afisează utilizatorul poate selecta ce campuri să i se afișeze în pagina de start. Setarea poate fi facuta implicita (vezi meniul setari) ca de fiecare dată când acesta intra în aplicatie să se afișeze în felul prestabilit. Toate checkbox-urile se selectează / deselectează la intrarea în aplicatie în funcție de câmpurile setate de utilizator în baza de date.

Fig. 13 – Meniul afișează

De specificat că din motive de funcționaliate a programului câmpurile « Account_Manager »

și

«

sunt

Consultant_Delegat

scoase

»

din meniu în

momentul în care ori un account manager ori un consultant intră în sistem, deoarece limitarea pe care aceștia o au de a afișa doar ce e al fiecaruia (pentru account manager se afișeaza doar comenzile introduse de el, pentru consultant se afișeaza doar ce comenzi au fost repartizate lui) are de suferit în momentul în care din meniul Afiseaza se deselectează ”account

manager” sau ”consultant delegat” (după

caz), query-ul nemaifiind valabil în baza de date, ducând la o eroare fatală.

Meniul CAUTĂ Din acest meniu se pot face căutari în toate câmpurile sau în

câmpul specificat în

lista de tip dropdown alături de câmpul

căutare. De menționat că datorită limitărilor de afișare din meniul « afișare » căutarea se va face doar în câmpurile care sunt deja afișate (deasemeni lista dropdown se populează automat tot cu câmpurile selectate în meniul « afișează ».)

Fig. 14 – Meniul cauta Meniul MESAGERIE Prin acest meniu se pot trimite mesaje prin circuitul intern de mesagerie, către ceilalti utilizatori ai sistemului. Scopul acestui

modul

fiind

acela

de

a

crea

o

punte

de

legătura între utilizatori ei putand comunica mai usor unii cu altii doar folosind sistemul informatic.

Fig. 14 – Meniul mesagerie

Meniul RAPOARTE În acest meniu se pot genera rapoarte de activitate în funcție de orice camp din baza de date. Pot fi introduse și mai multe cuvinte moment în care raportul se va genera în funcție de amandouă cuvintele, ca și în exemplul scris din fig. 15.

Fig. 15 – Meniu rapoarte Meniul SETĂRI Meniul setări conține 3 funcții importante : - Salvare setări per utilizator (în momentul în care acesta

modifică setările implicite pentru userul sau).

- Funcție de revenire la setările initiale ale userului (setări stabilite cand a fost creat utilizatorul). - Funcție de modificare al numărului de comenzi per pagină afișate. Ultimele două funcții au nevoie de a apasa și butonul salvare setări pentru a face modificarea permanentă, altfel modificarea va fi temporară (insemnand că urmatoarea dată când utilizatorul se va înregistra în sistem va avea setările implicite.

Fig. 16 –Meniul setări

Meniul ADMIN Meniul permite a se face modificări în baza de date la tabela userilor, a băncilor și a tipului de proprietate.

Fig. 17 - Meniul Admin (adaugare tip proprietate)

nou .

Exemplul din figura 17 exprima actiunea de adaugare de tip proprietate

4.3. Mesaje de eroare Începand cu prima pagina, cea de ”index.php” avem de notat in revista doua erori care pot aparea : - In momentul in care nu sunt completate ambele casute de user si parola se da un mesaj de notificare - În momentul in care combinatia de user . parola nu exista pe server se afiseaza un mesa care notifica evenimentul. Restul de mesaje de eroare apar pentru a confirma sau a infirma : - Adaugarea unei inregistrari in baza de date.

- Modificarea unei inregistrari din naza de date. - Stergerea unei inregistrari din baza de date.

4.4. Instalarea și implementarea aplicatiei După cum am specificat și în capitolul 2, subcapitolul 5.1 pentru baza de date a fost ales sistemul Microsoft SQL. Acest sistem vine cu o întreagă paletă de funcționalitați. Datorită

faptului că firma pentru

care s-a proiectat acest sistem informatic beneficiază deja de acest sistem nu va mai fi nevoie de o instalare / implementare a serverului in prealabil sau a SGBD-ului. Totuși vom avea de creat baza de date cu tabelele standard ale aplicației. Atașat acestui proiect pe CD se afla fișierele SQL (/Aplicatie/Baza de date) pentru baza de date și pentru fiecare tabela în parte. Se foloseste pentru importul bazei de date un utilitar specific MSSQL numit ”Microsoft SQL Server Management Studio”. Dupa încarcarea acestui program se va face click în stânga pe serverul de SQL, și se va da click pe New Query. Apoi în noua fereastră aparută se va copia

conținutul celor 6 fișiere (conținutul cadru al bazei de date și 5 tabele) rând pe rând acționand butonul Execute din cadrul ferestrei de query. Pentru instalarea serverelor APACHE si PHP se va folosi aplicatia inclusa în acest proiect pe CD numita APPSERV. Instalarea este foarte simpla și intuitiva singurele setări în instalare fiind legate de numele domeniului pe care se instalează aplicatia alături de port restul instalării decurgând în mod automat. După instalarea acestei aplicații vom observa că PHP nu suportă conexiunea cu baze de date MSSQL ca setare implicită. De aceea fișierul de configurare al PHP numit php.ini va trebui modificat decomentând urmatoarea linie : ;extension=php_mssql.dll Prin decomentare linia va arăta așa : extension=php_mssql.dll Pentru ca aplicația să funcționeze conținutul ei va fi copiat în directorul

www

al

aplicației

APPSERV

(în

general

instalat

in

C:\Appserv\www)

4.5. Eficienta si utilitatea sistemului informatic Sistemul a fost conceput , proiectat pentru a aduce un plus de management firmei pentru

care s-a facut proiectarea. Deoarece

sistemul actual pe care firma functioneaza este deficitare din multe puncte

de

vedere

aceasta

aplicatie informatica vine sa modifice

multe aspecte ale sistemului prezent. Printr-o mai buna organizare a comenzilor si a sistemului per total se modifica timpul de raspuns aceasta crescand productivitatea firmei si totodata si imaginea acestea crescand in ochii clientilor si partenerilor.