treball fi de carrera -...

PROJECTE FI DE CARRERA

TÍTOL: Aplicació web per gestionar serveis d’entregues a domicili amb magatzem

centralitzat.

AUTOR: Xavier Pérez Gallart

TITULACIÓ: Enginyeria tècnica en informàtica de gestió

DIRECTOR: Jordi Esteve Cusiné

DEPARTAMENT: Llenguatges i Sistemes Informàtics

DATA: 27 de Gener del 2013

Universitat Politècnica de Catalunya 2

TÍTOL:

Aplicació web per gestionar serveis d’entregues a domicili amb magatzem centralitzat.

COGNOMS: Pérez Gallart NOM: Xavier

TITULACIÓ: Enginyeria tècnica

ESPECIALITAT: Informàtica de gestió PLA: 1992

DIRECTOR: Jordi Esteve Cusiné

DEPARTAMENT: Llenguatges i Sistemes Informàtics

QUALIFICACIÓ DEL PFC

TRIBUNAL

PRESIDENT SECRETARI VOCAL

DATA DE LECTURA: 06/02/2013


Aquest Projecte té en compte aspectes mediambientals: Sí No

PROJECTE FI DE CARRERA

RESUM (màxim 50 línies)

L’objectiu final d’aquest projecte de fi de carrera és dissenyar una aplicació suportada

en un servidor web, per gestionar entregues a domicili des de diferents punts de venda

amb un magatzem centralitzat d’una forma més eficient i senzilla.

Es realitzarà un estudi per poder determinar les necessitats del projecte i poder escollir

la tecnologia que s’utilitzarà per dur-lo a terme.

Seguidament, es farà un anàlisi de tots els requeriments i les necessitats detectades i

s’elaborarà un disseny de l’aplicació. Aquest disseny el durem a terme de forma real a

base de comprovacions per a poder analitzar si aquest satisfà les necessitats detectades.

El resultat serà una aplicació web que ens permetrà gestionar les entregues a domicili

dins de la mateixa empresa dels diferents punts de venda, ja siguin punts de venda físics

com punts de venda online. Centralitzarem el punt de recollida en el magatzem central

de logística de l’empresa amb la finalitat de reduir costos de transport en recollides

individuals.

Finalment, es farà un estudi de viabilitat per determinar si la nova organització

proposada pel projecte compensa la inversió de desenvolupar-lo. Aquest punt serà clau

per analitzar si el projecte ha estat un èxit o no hem obtingut els resultats esperats.

Paraules clau (màxim 10):

LOGISTICA ENTREGA HTML EFICIENCIA

MYSQL ESTALVI JQUERY CSS

APACHE PHP

Aplicació gestora d’entregues a domicili Xavier Pérez




Agraïments

Al meu tutor, el Jordi Esteve, per la seva dedicació i confiança.

Als meus amics pel suport incondicional durant el temps del projecte.

Als meus companys del Decathlon per la paciència que han tingut i per l’ajuda que m’han ofert.

A la Montse Sala i per l’ajuda amb el logo del projecte Wigow.

A la Roser Català per haver-me ajudat i recolzat des de el principi del projecte fins al final.

i a totes aquelles persones que he conegut al llarg del projecte que d’una manera o altre m’han

ajudat en aquest.



Índex

1. Introducció al projecte ................................................................................................................ 10

1.1 Introducció ............................................................................................................................. 10

1.1.1 Wigow ...................................................................................................................... 10

1.1.2 Objectius ................................................................................................................... 11

2. Avaluació de tecnologies ............................................................................................................. 12

2.1.1 Tecnologies disponibles ........................................................................................... 12

2.1.2 Elecció de tecnologia: LAMP .................................................................................. 14

3. Planificació inicial i estimació de costos .................................................................................... 15

3.1.1 Anàlisi de temps ....................................................................................................... 15

3.1.2 Estimació de costos en funció al temps .................................................................... 18

4. Anàlisi i especificació .................................................................................................................. 19

4.1 Introducció ............................................................................................................................. 19

4.2 Diagrama de fluxos ................................................................................................................ 22

4.3 Anàlisi de requeriments .......................................................................................................... 24

4.4 Model conceptual ................................................................................................................... 27

4.5 Casos d’ús .............................................................................................................................. 29

4.5.1 Cas d’ús genèric d’afegir .......................................................................................... 32

4.5.2 Cas d’ús genèric de modificar .................................................................................. 33

4.5.3 Cas d’ús genèric d’eliminar ...................................................................................... 34

4.5.4 Cas d’ús genèric de mostrar ..................................................................................... 35

4.5.5 Cas d’ús afegir albarà ............................................................................................... 36

4.5.6 Cas d’ús buscar ......................................................................................................... 38

4.5.7 Cas d’ús assignar ruta ............................................................................................... 39

4.5.8 Cas d’ús canviar estat ............................................................................................... 40

4.5.9 Cas d’ús canviar contrasenya ................................................................................... 41

4.5.10 Cas d’ús netejar sistema ........................................................................................ 42

4.5.11 Cas d’ús executar sentencia SQL ......................................................................... 43

4.5.12 Cas d’ús login ....................................................................................................... 44

4.5.13 Cas d’ús logout ..................................................................................................... 45

4.5.14 Cas d’ús configurar sistema .................................................................................. 46

5. Disseny .......................................................................................................................................... 47

5.1 Introducció ............................................................................................................................. 47

5.2 Model de Components ........................................................................................................... 48

5.2.1 Llista de components ................................................................................................ 50

5.3 Diagrames de Col·laboració ................................................................................................... 52



5.3.1 Digrama genèric d’afegir.......................................................................................... 52

5.3.2 Digrama genèric de modificar .................................................................................. 53

5.3.3 Digrama genèric d’eliminar...................................................................................... 54

5.3.4 Digrama genèric de mostrar ..................................................................................... 56

5.3.5 Digrama d’afegir albarà............................................................................................ 56

5.3.6 Digrama de buscar .................................................................................................... 58

5.3.7 Digrama assignar ruta ............................................................................................... 60

5.3.8 Digrama de canviar d’estat ....................................................................................... 60

5.3.9 Digrama de canviar contrasenya .............................................................................. 61

5.3.10 Digrama de netejar sistema ................................................................................... 63

5.3.11 Digrama d’executar sentencia SQL ...................................................................... 64

5.3.12 Digrama de login .................................................................................................. 65

5.3.13 Digrama de logout ................................................................................................ 65

5.3.14 Digrama de configurar sistema ............................................................................. 66

5.4 Disseny de la Base de Dades .................................................................................................. 67

5.4.1 Introducció................................................................................................................ 67

5.4.2 Model Relacional ..................................................................................................... 67

5.5 Disseny de la Interface ........................................................................................................... 68

5.5.1 Introducció................................................................................................................ 68

5.5.2 Disseny Gràfic .......................................................................................................... 68

5.5.3 Usabilitat .................................................................................................................. 85

6. Implementació i Tests ................................................................................................................. 88

6.1 Introducció ............................................................................................................................. 88

6.2 Estratègia de Desenvolupament ............................................................................................. 88

6.3 Tests ....................................................................................................................................... 89

7. Viabilitat ....................................................................................................................................... 91

7.1 Definició de Necessitats ......................................................................................................... 91

7.2 Model de Negoci .................................................................................................................... 92

7.2.1 Ingressos ................................................................................................................... 92

7.2.2 Costos ....................................................................................................................... 93

7.2.3 Conclusions .............................................................................................................. 93

8. Balanços i conclusions ................................................................................................................. 95

8.1 Planificació final i anàlisi ....................................................................................................... 95

8.2 Conclusions i propostes de millora ........................................................................................ 95

8.2.1 Conclusions .............................................................................................................. 95

8.2.2 Propostes de millora ................................................................................................. 96



9. Annexos ........................................................................................................................................ 98

9.1 Instal·lació de LAMP ............................................................................................................. 98

9.2 Instal·lació de Wigow .......................................................................................................... 100

9.3 Possibles servidors de Wigow .............................................................................................. 104

10. Glossari ................................................................................................................................ 105

11. Bibliografia .......................................................................................................................... 108

11.1 Programació ......................................................................................................................... 108

11.2 Disseny Web ........................................................................................................................ 109

11.3 Usabilitat .............................................................................................................................. 109



1. Introducció al projecte

1.1 Introducció

1.1.1 Wigow

Wigow pretén ser una aplicació que permeti, a les empreses que treballen amb diferents punts de

venda i que tenen un magatzem centralitzat, gestionar totes les entregues que hagin de realitzar,

centralitzant tot l’estoc al magatzem central, així aconseguirem reduir costos de transport. Aquesta

idea neix de la necessitat, cada cop més evident, de les empreses en aplicar una política de reducció

de costos. A més a més, cada cop s’està important més la filosofia Japonesa de “Lean

manufacturing”1 i això provoca que, cada cop més, les empreses treballin amb un magatzem

centralitzat per reduir els estocs. Al eliminar els estocs dels punts de venda, és necessari una

logística excel·lent, la qual ens permeti re aprovisionar tot l’estoc i alhora, facilitar a les botigues les

quantitats de productes necessàries, en el moment en que es necessiten. Aquesta metodologia de

gestió logística és coneguda com “just – in – time”.

Amb Wigow el que es vol aconseguir és que cada cop que un client va a un punt de venda i

sol·licita un servei d’entrega a domicili, que no sigui el propi punt de venda qui s’encarregui de

gestionar el servei d’entrega a domicili. Cada cop que surt un producte del punt de venda, el sistema

logístic es posa en marxa per re aprovisionar aquell producte. El punt de venta sol·licitarà al

magatzem central el servei d’entrega i li donarà tots els detalls necessaris, així el punt de venta ja

se’n desentén i passa a ser responsabilitat del magatzem.

Guanyem en transports interns i ens estalviem tots els processos que es durien a terme per la

reposició de cada article venut. A més a més, estalviem en els costos de les empreses de transport

que duen a terme les entregues, ja que, només tenen que anar a recollir a un sol punt i recullen molts

articles de un sol cop. Simplement, amb el fet de delegar a una altra persona de dins la mateixa

empresa, A posteriori podem estalviar a la llarga molts diners. Així doncs, durem a terme un estudi

econòmic sobre el que ens podríem estalviar i si realment és un estalvi significatiu com perquè es

pogués dur a terme en una empresa.

Dins la pròpia aplicació es crearan diferents rols d’usuaris per poder gestionar el que son els serveis

de control de l’aplicació. Per això es definiran administradors de diferents nivells amb els seus

respectius panells per poder gestionar l’aplicació.

1 Filosofia japonesa sobre la gestió enfocada a donar el màxim benefici al client. Veure

“8.Glossari”



1.1.2 Objectius

Dissenyar l’aplicació de gestió de les entregues a domicili, això inclou:

Analitzar els requeriments i necessitats.

Especificació de tots els processos.

Disseny de l’aplicació.

Implementació i comprovacions.

Dissenyar un pla d’implementació del projecte.

Elaborar un estudi de viabilitat per determinar la rendibilitat de la inversió en elaboració i

implementació del projecte.



2. Avaluació de tecnologies

2.1.1 Tecnologies disponibles

- LAMP

LAMP es l’acrònim de Linux, Apache, MySQL i Php. És una estructura de programes que es

complementen per poder suportar un espai web. Està basat amb el sistema operatiu lliure de

Linux, un servidor Apache que ens suporta la web, la base de dades MySql de Oracle i el

llenguatge de programació PHP (PHP Hypertext Preprocessor).

o Linux

Sistema operatiu basat en el nucli de UNIX. Va ser creat per l’any 1991 per Linus Torvals.

És un sistema operatiu de codi lliure, això vol dir que, qualsevol persona pot consultar el

codi font, modificar-lo i distribuir-lo sota la llicència GPL (Llicencia Publica General). La

llicència GPL no ens permet la restricció de codi de qualsevol programa o aplicació que

contingui parts de codi amb llicencia GPL, si una part del codi és de llicencia GPL, tot el

codi té que tenir la llicencia GPL.

Actualment, el sistema operatiu LINUX és un dels més utilitzats en servidors de xarxa, ja

que, ens ofereix característiques semblants a les del seu principal competidor Windows

però, gràcies a les llibertats que ofereix la seva llicència fa més econòmica la seva

adquisició.

o Apache

Servidor de HTTP de codi obert, no té cap mena de restricció en la seva distribució, tant

sigui pública com privada. Neix a l’any 1995 a mans de Robet McCool. Actualment, és un

dels servidors HTTP més utilitzats, destaca per la seva senzillesa, l’alta estabilitat, altament

configurable i que és un sistema Multi-plataforma, suporta els sistemes operatius de

Windows, Linux i Macintosh.

o MySQL

És un potent gestor de base de dades de codi lliure amb llicencia GPL, utilitza dades

relacionals, és multi-procés i multi usuari, ens permet que varis usuaris puguin estar

treballant de forma paral·lela sense interrompre la seva activitat. Dedicat principalment a

usos per pagines web, és un sistema multi-plataforma, molt ràpid en lectures però amb un

alt nombre de modificacions pot donar algun problema.

o PHP

Llenguatge de programació de codi obert, sota llicencia PHP License. Neix l’any 1995 a

mans de Rasmus Lerdorf. Molt popular pel seu potencial com a llenguatge de programació.



Permet integrar-lo directament dins el codi HTML sense la necessitat de la crida de cap

programa extern. Llenguatge de la banda del servidor, no té la necessitat de compilació per

lo que es compila en el moment de l’execució. En cas de que es produeixi un error en la

programació, no causa la caiguda del servidor complet, simplement obtenim un missatge

d’error a la pantalla. Fàcil aprenentatge i alt suport.

- .NET

De l’empresa Microsoft, neix l’any 2002, conta amb el suport del seu creador Microsoft que és

qui el va desenvolupant i actualitzant. Per suportar la Web ens ofereix ASP.NET amb

l’estructura IIS (Internet Information Service). Per la base de dades, Microsoft ofereix el seu

gestor “Microsoft SQL Server”, molt potent i molt robust. Aquesta tecnologia de Microsoft és

principalment utilitzada en l’àmbit de les empreses, ja que, el fet de poder gaudir del suport de

Microsoft és un gran aspecte a tenir en compte.

El llenguatge ASP.NET que en els seus orígens era bastant similar al PHP, s’ha anat separant

del llenguatge PHP, però actualment, ens permet instal·lar eines per poder utilitzar el PHP.

- iPlanet

Creat per l’empresa Sun Microsystems i actualment de Oracle. És un WebServer que ens

ofereix els serveix necessaris per poder desenvolupar una pàgina web. Venint de l’empresa Sun

MicroSystems, no ens sorprèn que el seu nucli principal estigui fet amb JAVA. Sistema multi-

plataforma, amb el nucli gestor de UNIX. Es regeix sota la llicencia GPL. Utilitza la seva pròpia

base de dades de l’empresa Oracle. No és una mala solució ja que, el llenguatge Java té un

aprenentatge bastant senzill. A més a més, consta d’unes grans llibreries que faciliten molt la

feina.

o Java

Llenguatge de programació d’alt nivell, neix l’any 1995 en mans de Sun Microsystems. Té

moltes similituds amb llenguatges de programació com són el C, el Cobol o el Visual Basic.

Java a diferència dels llenguatges esmentats anteriorment, no disposa de les funcions més

bàsiques del llenguatge, s’eliminen les funcions de baix nivell. Tot i que es pugui compilar a

llenguatge màquina, el Java normalment utilitza un intèrpret que s’executa en el moment de

l’execució del codi Java. L’inconvenient de que s’hagi d’executar una màquina virtual per

interpretar el codi Java, ens permet que pugui ser un llenguatge multi-plataforma, ja que, acaba

sent la màquina virtual qui interactua amb el sistema operatiu.



2.1.2 Elecció de tecnologia: LAMP

Després d’analitzar les principals solucions que hem trobat per suportar el servidor Web, s’ha

decidit utilitzar la tecnologia de LAMP. No ha estat una elecció senzilla, ja que, el sistema de

Microsoft .NET ofereix unes prestacions molt bones, principalment la seva base de dades SQL

Server. Els principals motius per els que s’ha escollit LAMP han estat els següents:

Alt coneixement sobre el funcionament d’aquesta tecnologia, porto molts anys treballant

amb tecnologia LAMP, amb experiència després de muntar ja varies pàgines webs, avalen

que el projecte surti endavant.

És una tecnologia molt extensa en la xarxa, l’utilitza un alt nombre de usuaris, amb lo que

aconseguir suport sempre serà més senzill que no pas una altre tecnologia molt més concreta

que utilitzen poques persones.

Costos en aconseguir la tecnologia en servidors contractats. La majoria de les empreses de

hosting o de servidors dedicats disposen de la tecnologia LAMP, per tant, aconseguir un

servidor serà més econòmic. A mes a més, a diferència de la tecnologia .NET que s’havia

valorat al principi, LAMP utilitza el Sistema Operatiu Linux, a diferència de la tecnologia

.NET que utilitza Windows. Amb el sistema operatiu també aconseguim reduir costos ja

que, la llicencia de Windows es més cara.

Compleix tot el que necessita l’aplicació per poder funcionar correctament sense cap

problema. No té eines que després no utilitzarem.

En l’apèndix “7.1 Instal·lació de LAMP” he elaborat una petita guia de com dur a terme la

instal·lació de la tecnologia LAMP en un servidor de Linux. Aquest programari és el que utilitzaré

per desenvolupar el projecte.



3. Planificació inicial i estimació de costos

3.1.1 Anàlisi de temps

Degut a la complexitat del projecte és importantíssim tenir una bona planificació en el temps per

evitar que es retardi o incrementi els costos de desenvolupament. Aquest projecte en cas de dur-se a

terme en una empresa, requeriria varis professionals, ja que, és un projecte complex i es

desenvolupen varies àrees. La planificació que duré a terme a continuació és la que definirà, en el

cas que es volgués dur a terme en una empresa, si és un projecte rentable o no. Realitzaré una

estimació, però, per cada empresa és diferent. Per tant, s’hauria de reajustar els càlculs realitzats per

obtenir unes dades fiables de si sortiria rentable en un cas en concret.

En el meu cas, al ser l’únic membre, duré a terme tots els papers dels professionals que

intervindrien en el projecte. Igualment, especificaré totes les funcions que desenvoluparia cada

professional que treballés en el projecte.

Analista

L’analista del projecte és el professional que juga una de les peces més importants en el

desenvolupament del projecte. Serà l’encarregat de detectar les necessitats i de definir

quines funcionalitats haurà de dur a terme l’aplicació per poder cobrir les necessitats del

client. En funció de l’empresa en que es dugui a terme canviaran els aspectes més específics

de cada una, però totes coincidiran en els punts més importants de l’aplicació. L’analista ha

de tenir molta cura en desenvolupar bé la seva feina perquè d’ella en dependrà tota la

funcionalitat de l’aplicació, per tant, és essencial saber què necessita el client.

En el meu cas tinc la sort de treballar en una empresa en la que perfectament es podria dur a

terme aquest projecte, per tant, realitzaré el paper d’analista i de client, ja que, conec les

necessitats d’un client, i a partir d’aquí, ho estandarditzaré per a qualsevol empresa.

En aquesta tasca tinc previst dedicar-li aproximadament unes 100 hores.

Programador

El programador és el professional dins el desenvolupament del projecte que tindrà més

feina, ja que, aquest ha d’interpretar els dissenys de l’analista i els ha de dur a la pràctica

sense realitzar cap modificació en el disseny. Només se l’hi permet fer els ajustos necessaris



per adaptar el disseny al llenguatge de programació més específic.

En aquest projecte, el programador té una gran càrrega de treball, ja que, l’aplicació no

consta de grans funcionalitats, però, si que en té moltes i de molt relacionades entre si.

En aquesta tasca previnc dedicar-li aproximadament unes 220 hores.

Dissenyador Web

Aquest professional que moltes vegades passa desapercebut, en el desenvolupament

d’aquest projecte és un dels pilars importants, ja que, al ser un aplicació Web, el dissenyador

web serà el que decidirà com vol que es visualitzi l’aplicació, quina és la millor manera

perquè s’entengui i com vol que l’usuari interactuï amb l’aplicació. He comentat

anteriorment que era un pilar perquè, al cap i a la fi, és la part que veu el client. Per molt ben

elaborada que estigui internament, si el disseny, que és la cara de l’aplicació, no funciona,

no aconseguirem que el client estigui satisfet. Per tant, el dissenyador abans de començar

haurà de llegir-se detingudament totes les necessitats i requeriments detectades per

l’analista.


Maquetador

El maquetador és el que s’encarregarà de passar a codi HTML i CSS el disseny web creat

per el dissenyador web. Semblant al programador, ha de complir al peu de la lletra totes les

especificacions de usabilitat. A més a més, tindrà la feina de conèixer el disseny del Analista

per poder adaptar el disseny web amb el disseny de l’aplicació. És molt important una bona

sincronització de la part gràfica amb el motor de gestió de l’aplicació, en cas que no fos així,

no aconseguiríem el màxim rendiment de l’aplicació.


Documentador

És molt important una bona documentació de l’aplicació, ja que, en el futur quan es vulgui



realitzar alguna modificació o alguna actualització, si no hem fet una bona documentació

ens suposarà una càrrega de feina molt més gran de que si ho tenim ben documentat.

El documentador serà el responsable de plasmar en escrit tots els dissenys, tant de l’analista

com del dissenyador web. A més a més, tindrà en compte les especificacions del

programador i del maquetador. No suposarà un gran volum de feina, però d’aquí dependrà el

futur de l’aplicació.


Per tant ajuntant totes les tasques a fer, tenim que per dur a terme el projecte necessitarem un total

de 630 hores desglossades de la següent manera :

Professional Hores Total

Analista 100 100

Programador 220 320

Dissenyador Web 70 550

Maquetador 160 480

Documentador 80 630

Contant que es treballa 8 hores al dia i 5 dies a la setmana, les 630 hores que hem calculat que

necessitem per dur a terme el projecte són uns 4 mesos aproximadament. Suposant que hi ha dies

festius entre setmana, en el pitjor dels casos, el projecte se’ns allargaria a 5 mesos, que seria amb les

vacances de nadal entremig.

En el meu cas, al ser jo sol i de forma educativa, tot i agafar les vacances de nadal entremig, seguiré

treballant igualment com si fossin dies laborables. Per tant, la planificació que es durà a terme per

elaborar el projecte serà la següent:

En el diagrama de Gantt anterior veiem que iniciem el projecte el 3 de setembre del 2012 i l’acabem

el 10 de gener del 2013. Per evitar que es s’enredereixi la data de finalització del projecte, hem de



respectar al peu de lletra les dates del camí crític2. Com veiem, només hi ha una tasca que no formi

part del camí crític, que és la de “Disseny Web”. Aquesta tasca encara que s’enredereixi, o no

comenci correctament al dia, no ens afectarà en la data de finalització del projecte (sempre i quan,

aquest endarreriment més el temps de la tasca no siguin superiors al temps de la tasca paral·lela de

“Programació”).

3.1.2 Estimació de costos en funció al temps

A continuació volem realitzar un càlcul econòmic sobre el impacte que tindria en una empresa

realitzar aquest projecte. El càlcul es basa amb el salari mínim professional de cada especialista, i

tenint en compte un càlcul aproximat de un 35% de Seguretat Social(SS) i un 35% de costos varis

(lloguer oficina, llum, aigua, etc...).

Professional Hores Preu/hora Seguretat Social Varis Subtotal Total

Analista 100 25,7 € 900 € 900 € 4.369 € 4.369 €

Programador 220 20,2 € 1.555 € 1.555 € 7.555 € 11.924 €

Dissenyador Web 70 20,2 € 495 € 495 € 2.404 € 14.328 €

Maquetador 160 20,2 € 1.131 € 1.131 € 5.494 € 19.822 €

Documentador 80 11,6 € 325 € 325 € 1.578 € 21.400 €

Els costos mostrats anteriorment no són costos reals ja que, depenent de l’empresa on es realitzi pot

tenir uns costos o uns altres. Com més gran i més prestigiosa sigui l’empresa, més s’encarirà el

projecte, ja que, tots els seus costos augmenten significativament. Però, en el cas hipotètic que he

simulat anteriorment, la realització d’aquest projecte tindria un cost aproximat de uns 21.400€.

Tenint un càlcul aproximat dels costos de desenvolupar el projecte ja serà la empresa pròpia qui faci

els balanços per veure si els compensa el cost amb el estalvi que els genera.

2 Un camí crític són un conjunt de tasques que si s’enredereixen, enredereixen la data de fi del

projecte.



4. Anàlisi i especificació

4.1 Introducció

Com s’ha comentat en l’inici del projecte, Wigow, pretén ser una aplicació web per gestionar de

forma eficient les entregues a domicili per les empreses que tenen més de un punt de venda. La clau

del projecte està en centralitzar en un punt totes les entregues a domicili dels clients que han

sol·licitat el servei des de un dels punts de venda.

Ja hi havia empreses que havien començat a canviar la seva metodologia de treball, i actualment,

amb la situació econòmica que hi ha, cada cop més empreses estan apostant per implementar la

metodologia Lean. Aquesta metodologia intenta suprimir l’estoc que no sigui estrictament

necessari, perquè un estoc quiet són diners immobilitzats, i per tant diners que no estem aprofitant el

seu cost d’oportunitat. Per aquest motiu, les grans empreses treballen amb un magatzem centralitzat

amb l’ estoc, que aprovisiona a diferents punts de venda a mesura que es van venent. D’aquesta

organització se’n diu “Just in Time”3.

Conèixer aquesta organització és imprescindible per entendre l’essència del projecte. Un cop ja

sabem com s’organitzen, ens centrem amb les empreses que ofereixen un servei d’entregues a

domicili, és a dir, el client va a un punt de venda, compra un article i sol·licita que se li porti a casa

per el motiu que sigui, ja sigui pel seu volum, molt pesat, simplement per decisió personal.

Actualment tindríem el següent esquema:

Esquema organitzatiu de les entregues

3 Consisteix en no tenir estoc en les puntes i re aprovisionar de forma diària el 100% del estoc

venut.



En el esquema anterior, he simulat 4 punts de venda amb 1 magatzem centralitzat. En aquest podem

veure com 4 clients sol·liciten en 4 punts de venda diferents un servei d’entregues a domicili.

Aquest servei, al no estar centralitzat, cada punt de venda contracta a una empresa de transport que

realitzi el servei. Automàticament, com que s’ha venut un article, el mecanisme logístic per

re-aprovisionar es posa en marxa, es prepara l’article al magatzem i s’envia per transport al punt de

venda i es torna a col·locar al lineal.

El que pretén solucionar Wigow és que es repeteixin processos, que re-aprovisionem un estoc que

no seria necessari. Per això, es canvia l’organització, cada cop que es realitza una venda i es vol que

se li porti a casa el client, la tenda sol·licita a l’aplicació Wigow que es realitzi una entrega, li passa

el client i els articles a entregar i en aquest moment el punt de venda se’n desentén.

Llavors en el magatzem central, l’equip4 que s’encarrega de gestionar les entregues, rep tot la

informació del punt de venda i comença a gestionar tots els serveis. Aquest equip agrupa els serveis

i contracta a una empresa perquè li realitzi el servei. Per tant, amb aquesta nova organització

l’esquema quedaria així:

Nou esquema organitzatiu de les entregues

4 Pot ser 1 persona o més de una persona, no té perquè ser estrictament més d’una.



Amb aquest nou sistema organitzatiu tenim diferents beneficis. Per exemple, passem de 4 camions a

1 camió, això significa que l’empesa de transport no ens cobrarà 4 recollides i 4 entregues, sinó que,

ens cobrarà, 1 recollida i 4 entregues. A més a més, al treure l’ estoc del magatzem central i no del

lineal del punt de venda, evitem que es posi en marxa el mecanisme logístic que re-aprovisionaria

aquell o aquells productes, per tant, també ens estalviem els processos interns de preparació i els

costos en transport.

Com hem vist en els esquemes, tenim dos persones que seran les que de forma directa treballaran,

els operaris dels punts de venda que sol·licitaran els serveis i els operaris del magatzem que

gestionaran els serveis.

L’operari del punt de venda ha de ser capaç de crear els albarans d’entrega, afegir-hi serveis, com

poden ser: entrega, muntatge o recollida. A més a més, l’operari del punt de venda té l’accés a la

consulta dels albarans realitzats, veure els històrics dels clients i saber en tot moment el que se li

està re-facturant al seu punt de venda.

L’operari del magatzem ha de ser capaç de veure els albarans creats pels punts de venda associats al

seu centre logístic, ha de poder modificar totes les dades que hi consta en el albarà, el client, els

serveis, etc... I a més a més, ha de poder modificar l’ estat en que es troba l’albarà. Com que un dels

objectius de Wigow és agrupar les entregues, el l’operari gestor ha de poder crear grups

d’entregues, que les agruparem per els dies, per tant, direm que el l’operari ha de poder crear rutes

en els dies que vol que l’empresa de transport ho reculli. Tal i com fa el l’operari de tenda, el

l’operari de magatzem podrà buscar qualsevol albarà o client que sigui del seu centre. I per acabar,

podrà veure les re facturacions5 que es realitzen per cada un dels seus punts de venda o de forma

global.

A més a més, en l’aplicació hi afegirem 3 persones més que podran accedir-hi. Un perfil comptable,

que serà utilitat pel departament de comptabilitat per a poder dur a terme la comptabilitat analítica,

un perfil de gestor, que serà el responsable dels operaris gestors del magatzem i un perfil per a

informàtica, que serà per donar suport i solucionar incidències.

El comptable ha de poder accedir a un apartat especial per a poder veure els assentaments

comptables que ha d’executar per realitzar la seva comptabilitat analítica. Aquests assentaments

seran el resum de tots els serveis realitzats entre dues dates per cada un dels punts de venta associats

al centre. A més a més, el comptable podrà buscar albarans o clients com els operaris de l’aplicació.

5 No son factures reals, es comptabilitat analítica que es realitza de forma interna en l’empresa

per controlar tots els costos de cada un dels centres.



El gestor de l’aplicació tindrà els mateixos permisos que l’operari del magatzem, a més, aquest

gestor tindrà accés al panell de control de l’aplicació. En aquest panell podrà crear usuaris de menys

categoria que ell, per tant, podrà crear: Operaris de Tenda i Operaris de Magatzem. A més a més,

podrà modificar-los i suprimir-los. En aquest panell de control també podà crear, modificar i

suprimir els punts de venda i els diferents serveis de transport. Finalment, aquest tindrà accés a la

configuració del seu centre, on podrà modificar el nom de l’empresa, la direcció, telèfon, NIF, ...

El informàtic tindrà accés a tota la informació que tenen accés tots els usuaris esmentats

anteriorment, podrà crear albarans, modificar-los, programar-los, veure la comptabilitat analítica,

accedir al panell de control, etc.. a més a més, aquest tindrà de peculiaritat de que en el panell de

control tindrà una opció per poder esborrar totes les dades més antigues a 5 anys. En el panell de

control també hi tindrà una opció que el permetrà escriure sentencies SQL directament des de la

pròpia aplicació. Aquest perfil està pensat per al departament de suport informàtic que es suposa

que consta d’experts i que per tant, no poden causar cap problema.

Finalment, tots els usuaris de l’aplicació Wigow disposaran de un panell d’usuari, on hi podran

veure les seves dades personals, on pertanyen, quin és el seu càrrec, el seu usuari i podran canviar la

seva contrasenya d’accés a l’aplicació.

4.2 Diagrama de fluxos

Per aclarir més el funcionament de l’aplicació he creat un diagrama de fluxos perquè puguem veure

de forma gràfica com interactuen els diferents elements que intervenen en tot el procés. Des de que

el client va una de les tendes i decideix que vol que li portin a casa, passen per tots els processos

intermedis fins que, el client rep el servei que ha sol·licitat.

Aquest diagrama no contempla tots els casos de les diferents funcionalitats, simplement és per

aclarir conceptes, resoldre algun dubte de com intervé algun component en el procés i en quin ordre

hi intervé.



Diagrama de fluxos de l'aplicació



4.3 Anàlisi de requeriments

De la introducció anterior en traiem els requisits indispensables per poder elaborar el model

conceptual i els corresponents casos d’ús. Apart dels requisits extrets del apartat introductori afegiré

uns altres requisits no contemplats però si que estrictament necessaris per aconseguir un bon

disseny de l’aplicació.

Base de Dades

Albarans

Centres

Clients

Configuració

Estats

Rols

Rutes

Serveis

Tendes

Tipus de Entregues

Usuaris

Usuari de Tenda

Ha de poder accedir a l’aplicació.

Ha de poder crear albarans associat un client amb els serveis.

Ha de poder veure albarans i clients.

Ha de poder utilitzar el buscador

Ha de poder veure el que l’hi re facturen amb ell entre dues dates.

Ha de poder veure el seu panell d’usuari.

Usuari de Magatzem


Ha de poder veure els albarans pendents de tractar del seu centre.

Ha de poder modificar els serveis i els clients.

Ha de poder canviar d’estat a un albarà.

Ha de poder crear noves rutes en una data.



Ha de poder veure la ruta d’una data.

Ha de poder imprimir els balises d’un albarà i d’una ruta sencera.

Ha de poder assignar albarans en una ruta.

Ha de poder veure el que es re factura a un punt de venda en concret.

Ha de poder veure el global del que es re factura.

Ha de poder utilitzar el buscador


Gestor dels Serveis



Ha de poder modificar els albarans i els clients.








Ha de poder utilitzar el buscador.


Ha de poder accedir al panell de control.

Ha de poder crear, modificar i eliminar usuaris.

Ha de poder crear, modificar i eliminar tendes.

Ha de poder crear, modificar i eliminar serveis.

Ha de poder accedir a la configuració del centre

Comptable




Ha de poder accedir als assentaments comptables

Ha de poder veure albarans i clients.




Informàtic



Ha de poder modificar els albarans i els clients.








Ha de poder accedir als assentaments comptables

Ha de poder utilitzar el buscador.


Ha de poder accedir al panell de control.

Ha de poder crear, modificar i eliminar usuaris.

Ha de poder crear, modificar i eliminar tendes.

Ha de poder crear, modificar i eliminar serveis.

Ha de poder accedir a la configuració del centre

Ha de poder executar les neteges de l’aplicació.

Ha de poder executar sentencies SQL des de la pròpia aplicació.

Clients

Un client ha de poder tenir associats diferents albarans de diferents punts

de venda.

L’estat del client serà el pitjor estat de tots els albarans que contingui.

Un client podà estar en estat: Pendent, Disponible, Enviat i Entregat.

Albarans

Un albarà només ha de poder estar associat a una ruta.

Els albarans han de poder tenir tants serveis com sol·liciti el client.

L’estat del albarà ha de ser el pitjor estat de tots els serveis que contingui.

Un albarà només ha de poder esta en estat: Pendent, Disponible, Enviat i



Entregat.

S’ha de poder imprimir les balises dels articles a entregar.

Rutes

Només s’ha de poder crear una ruta en una data determinada.

S’ha de poder imprimir les balises de tots els articles a entregar de la ruta.

S’ha de poder imprimir el full de carga 6i el packlist

7.

Serveis

Un servei només ha de poder ser de 3 categories: Entrega, Muntatge o

Recollida.

Només han de poder tenir assignat un tipus de servei i una data d’entrega.

Re-facturació

Només es podrà veure tots els serveis realitzats entre 2 dates.

S’ha de poder imprimir el extracte.

4.4 Model conceptual

A partir de la introducció i dels requeriments que hem esmenat anteriorment construïm el model

conceptual. El model conceptual dóna, una imatge del que ens hem plantejat fins ara, segurament

quan elaborem el disseny i estiguem fent la implementació hi haurà coses que no tindran sentit i les

canviarem.

S’hi han afegit els atributs de cada classe, a més a més, no s’han representat el 100% dels

requeriments ja que, molts requeriments són de diferents rols de l’aplicació i molts són repetits. Per

aquest motiu, en el model conceptual he representats els rols amb un atribut d’accés que és el que

determinarà quins permisos i quines accions puc executar.

6 Conegut com a CMR, es un document oficial per el transport de mercaderies dintre del territori

Nacional. Conté dades importants com el numero de articles, el pes i el volum. 7 És un document on conta desglossat tots els articles que porta el transportista.



Model conceptual de l’aplicació



4.5 Casos d’ús

A continuació podem veure tots els casos d’ús de l’aplicació Wigow, com que tenim 5 perfils

diferenciats, he separat els casos d’ús per els 5 perfils. Alguns d’ells estan repetits en més de un

perfil, per tant, en el moment de fer l’explicació de cada un dels casos d’ús, només sortiran

comentats una vegada. He considerat que era important separar els casos d’ús per els 5 perfils per

poder tenir molt clar que podrà fer cadascun d’ells i que no podrà fer.

Els perfils que tindrem en l’aplicació seran els següents:

1- Operari de tenda (“Sol·licitarà els serveis”)

2- Comptable (“Comptabilitzarà tots els serveis”)

3- Operari de magatzem (“Gestionarà els serveis”)

4- Gestor d’entregues (“Supervisarà el servei d’entregues”)

5- Informàtic (“Donarà suport a l’aplicació”)

Casos d’ús del operari de tenda



Casos d’ús del operari de magatzem

Casos d’ús del gestor del servei



Casos d’ús del comptable

Casos d’ús del informàtic



Com podem veure en els diagrames anteriors, els casos d’ús que pot utilitzar cada un dels actors que

poden accedir a l’aplicació Wigow, són molt diferents. Des del comptable que és el que té 8 casos

d’ús, fins al informàtic que té un total de 31 casos d’ús. Com ja he comentat anteriorment, alguns

casos d’ús es repeteixen en més d’un dels actors, per això, només s’explicaran un vegada, a més a

més, molts casos d’ús són molt similars entre si, sobretot els casos d’ús de afegir, modificar i

eliminar. Amb la finalitat de simplificar els casos d’ús, explicaré de forma genèrica aquells casos

d’ús que són similars als altres i em centraré en els que són peculiars o que són més complexos.

4.5.1 Cas d’ús genèric d’afegir

El cas d’ús d’afegir és el que crea tots els nous registres de la base de dades. Al ser una aplicació

web, tota la informació d’aquesta s’emmagatzema a la base de dades. Per tant, tota la informació

que l’hi passem al sistema és a través d’un formulari, l’aplicació només té que encarregar-se de

introduir les dades a la base de dades.

De forma general, tots els identificadors estaran determinats per el gestor de la base de dades, ja

exceptuant 1 cas utilitzarem índexs auto incrementables.

CONTRACTE crear()

Responsabilitat Inserta a la base de dades un registre nou.

Precondicions 1. Existeix una variable $_POST que conté el formulari amb totes les

dades.

Post-condicions 1. Existeix un registre a la base de dades amb les dades de l formulari.



4.5.2 Cas d’ús genèric de modificar

Aquest cas genèric agrupa tots els casos d’ús que modifiquen registres de l’aplicació. Totes les

modificacions que es poden realitzar, al tractar-se d’una aplicació web són dels registres de la base

de dades, per tant, primer de tot, el que farà és accedir a la base de dades per càrrega les dades ja

existents i mostrar-les a l’usuari amb un formulari que podrà modificar. Aquest formulari serà el

que després, un cop fetes les modificacions corresponents, guardarem de nou a la base de dades

sobreescrivint els registres carregats anteriorment.

CONTRACTE modificar(id)

Responsabilitat Modificar el registre que correspon al identificador id

Precondicions

1. Id és un identificador vàlid.

2. Existeix un registre amb el identificador id.

Postcondicions 1. Es mostra un formulari amb les dades corresponents al identificador id.

CONTRACTE guardar(id)

Responsabilitat Actualitzar els valor del registre id amb les dades del formulari $_POST.

Precondicions

1. Existeix una variable $_POST que conté el formulari amb totes les

dades.

Postcondicions 1. El registre de la base de dades corresponent al identificador id conté

les noves dades de la variable $_POST.



4.5.3 Cas d’ús genèric d’eliminar

Aquest cas d’ús genèric agrupa a tots els casos d’ús de l’aplicació que el seu propòsit és suprimir

algun registre de la base de dades. Per evitar la pèrdua d’informació, a tots els casos d’ús que

pretenen eliminar informació els he afegit una confirmació que si no és acceptada no executa

l’ordre d’eliminar les dades.

CONTRACTE eliminar(id)

Responsabilitat Eliminar de la base de dades el registre corresponent al identificador id.

Precondicions



Postcondicions 1. S’ha sol·licitat al usuari una confirmació.

CONTRACTE confirmació(bool)

Responsabilitat Confirmar que el usuari vol suprimir la informació de la base de dades.

Precondicions

1. S’ha sol·licitat suprimir un registre de la base de dades corresponent a

un identificador id.

Postcondicions 1. S’ha suprimir el registre corresponent al identificador id.



4.5.4 Cas d’ús genèric de mostrar

Aquest cas d’ús genèric agrupa a tots aquells casos d’ús que mostren algun registre de la base de

dades. Encara que alguns casos d’ús mostrin molta més informació que altres, internament la forma

com extreu les dades de la base de dades és la mateixa, per aquest motiu, he considerat oportú

simplificar-los en un mateix cas d’ús. Cap i a la fi, tots acaben sent SELECT de la base de dades.

CONTRACTE mostrar(id)

Responsabilitat Mostrar el registre que correspon al identificador id

Precondicions



Postcondicions 1. Es mostra un formulari amb les dades corresponents al identificador id.



4.5.5 Cas d’ús afegir albarà

Aquest cas d’ús és el cas d’ús més complex de l’aplicació Wigow. Tot i ser un cas que afegeix

informació, no l’he inclòs dins del cas d’ús genèric d’afegir, degut a que, és més complex que la

resta i m’interessa detallar-lo de forma més precisa. Aquest serà el responsable d’introduir a

l’aplicació tots els albarans amb els serveis i els clients que gestionarem. El client pot existir o no, si

el client no existeix es dóna d’alta un nou client, en cas de que ja existeixi, el sistema

automàticament associa el nou albarà al client en qüestió.

CONTRACTE crear_albarà()

Responsabilitat Crear un albarà perquè s’associï a un client i s’hi afegeixin serveis.

Precondicions 1. No hi ha cap albarà actiu.

Postcondicions

1. Hi ha un formulari obert per inserta les dades del client.

2. Hi ha un albarà actiu.



CONTRACTE afegir_client(id)

Responsabilitat Assignar un client al albarà.

Precondicions

1. Hi ha un formulari obert per inserta les dades del client.


3. El albarà no té cap client associat.

4. Les dades del client son correctes.

Postcondicions

1. El albarà té un client associat.

2. El albarà segueix actiu.

CONTRACTE afegir_servei(id)

Responsabilitat Afegir un servei al albarà que estem tractant.

Precondicions


2. Les dades del client son correctes.

Postcondicions

1. El albarà segueix actiu.

2. El albarà actiu té un servei nou.

CONTRACTE guardar()

Responsabilitat Guardar el albarà amb tota la informació introduïda.

Precondicions


2. El albarà actiu té associat un client.

3. El albarà actiu conté com a mínim 1 servei.

Postcondicions

1. A la base de dades s’han afegit registres amb la informació del albarà

actiu.

2. Ja no hi ha cap albarà actiu.



4.5.6 Cas d’ús buscar

El cas d’ús de buscar, no és dels casos d’ús més complicats, però si que serà per l’aplicació una

peça clau. Anirà associat al buscador de l’aplicació, i està pensat perquè trobi la informació que

busquem de la forma més ràpida i eficient possible. Basat amb el “finder” de Apple, el buscador

serà capaç de trobar coincidències encara que no siguin entrades completes.

CONTRACTE buscar(clau)

Responsabilitat Buscar en la base de dades registres amb coincidències amb la clau.

Precondicions -

Postcondicions 1. Es mostren totes les coincidències trobades amb la paraula clau.



4.5.7 Cas d’ús assignar ruta

Aquest cas d’ús serà el responsable d’assignar un albarà a una ruta en concret. D’aquesta forma

anirem agrupant els albarans en les diferents rutes planificades. Simplement actualitzarem un valor

del albarà que ens relacionarà amb la ruta.

CONTRACTE assignar_en_ruta(id_albarà,id_ruta)

Responsabilitat Assignar una ruta a un albarà.

Precondicions

1. Existeix un albarà amb el identificador id_albara.

2. Existeix una ruta amb el identificador id_ruta.

3. El albarà id_albara no té cap ruta assignada.

4. El albarà id_albara està en estat “Disponible”.

Postcondicions 1. El albarà id_albara té assignada la ruta id_ruta.



4.5.8 Cas d’ús canviar estat

Aquest cas d’ús té la finalitat de canviar d’estat a un servei concret d’un albarà. En l’aplicació

només canviarem els estats dels serveis dels albarans, mai canviarem els estats del albarans ni dels

clients. Canviant els estats dels serveis, ja s’actualitzarà l’estat del albarà i del client si es oportú. Un

albarà sempre agafarà com a estat el pitjor dels estats dels seus servis, i seguint el mateix patró, un

client agafarà el pitjor estat dels seus albarans. En conclusió, modificant els estats dels serveis del

albarà ja s’aniran variant de forma automàtica els altres estats dels objectes per sobre.

CONTRACTE canviar_estat(id_servei,nou_estat)

Responsabilitat Canviar d’estat a un servei en concret d’un albarà.

Precondicions

1. Existeix un servei amb el identificador id_servei.

2. Existeix un estat a la base de dades que coincideix amb nou_estat.

Postcondicions 3. El servei id_servei, té com a estat nou_estat.



4.5.9 Cas d’ús canviar contrasenya

Aquest cas d’ús té la finalitat de que el propi usuari es pugui modificar la seva pròpia contrasenya

sense necessitar d’una tercera persona. Serà accessible en qualsevol moment, per tant, sempre que

l’usuari ho desitgi, es podrà modificar la contrasenya.

CONTRACTE canviar_ contrasenya()

Responsabilitat Mostrar el formulari per introduir la nova contrasenya.

Precondicions 1. Hi ha un usuari loguejat a l’aplicació.

Postcondicions

1. Es mostra un formulari al usuari amb 2 camps per introduir la

contrasenya.

CONTRACTE guardar_ contrasenya(id_usuari,nova_contrasenya,nova_contrasenya2)

Responsabilitat Guardar la nova contrasenya introduïda per el usuari a la base de dades.

Precondicions 1. La variable $_POST conté les noves contrasenyes.

Postcondicions 2. El usuari té la nova contrasenya introduïda.



4.5.10 Cas d’ús netejar sistema

El cas d’ús de netejar el sistema ens servirà per realitzar un manteniment de l’aplicació. El propòsit

del cas d’ús és que escanegi tot el sistema, trobi tota la informació més antiga de 5 anys i l’esborri.

Per tant, el sistema esborrarà tots els albarans amb data de compra més gran de 5 anys a partir de la

data actual. A més a més, esborrarà tots els serveis d’aquests albarans, i en cas de que un client es

quedi sense albarans associats, també serà esborrat.

CONTRACTE netejar_sistema()

Responsabilitat Netejar el sistema dels registres sense activitat en 5 anys.

Precondicions -

Postcondicions

1. S’ha llençat la sol·licitud per esborrar els registres sense activitat en 5

anys.

CONTRACTE confirmació(bool)

Responsabilitat Confirmar que es vol executa l’ordre de netejar el sistema.

Precondicions

1. S’ha llençat la sol·licitud per esborrar els registres sense activitat en 5

anys.

Postcondicions

1. S’ha esborrat de la base de dades aquella informació sense activitat en

els darrers 5 anys.



4.5.11 Cas d’ús executar sentencia SQL

Aquest cas d’ús està pensat com ja he comentat anteriorment, perquè només hi pugui tenir accés el

informàtic que doni suport a l’aplicació. Remarco tants cops aquest fet, ja que, al ser una aplicació

web que emmagatzema tota la informació en la base de dades, que s’hi pugui tenir accés directe, pot

ser perillós, ja que, en males mans pot destrossar l’aplicació. Aquest cas d’ús està pensat perquè es

pugui incidir de forma directa sobre alguns registres de la base de dades en cas de que es produís

algun problema o es necessites fer alguna modificació que l’aplicació no permet.

CONTRACTE executar_sql(sentenciaSQL)

Responsabilitat Executar la sentencia SQL que l’hi passa l’usuari.

Precondicions 1. La sentenciaSQL és una sentencia SQL correcta.

Postcondicions 1. S’ha executat la sentencia SQL que passa l’usuari en la base de dades.



4.5.12 Cas d’ús login

El cas d’ús d login, és un cas d’ús bastant senzill, però sense ell l’aplicació no podria funcionar. Per

això he considerat important detallar-lo correctament. El sistema de login realitzarà la comprovació

del usuari i de la contrasenya. Per motius de seguretat, en la base de dades hi guardarem la

contrasenya encriptada. Utilitzaré el mètode d’encriptació MD5 de PHP. Un cop realitzada la

comprovació en cas afirmatiu es crearà una $_SESSION8 en el navegador amb les dades del

usuari(nom i cognom), el nivell d’accés (operari de tenda, comptable, etc...). A més a més, hi

inclourem una variable que serà la que comprovarem de forma ràpida per saber si l’usuari està

identificat, aquesta variable l’hi diré src i contindrà la paraula “wigows” encriptada amb MD5.

CONTRACTE accés(usuari,contrasenya)

Responsabilitat Permetre accedir o no als usuaris de l’aplicació.

Precondicions

1. L’usuari que es vol identificar, no està identificat ja.

2. Existeix un usuari a la base de dades que concorda amb el

identificador usuari.

3. El usuari de la base de dades que coincideix amb el identificador

usuari, coincideix la seva contrasenya amb contrasenya.

Postcondicions

1. Hi ha una nova variable $_SESSION que conté les dades del usuari per

tal de se identificat.

8 $_SESSION és molt semblant a una galeta emmagatzemada en el navegador del servidor, però aquesta

variable té com a peculiaritat que s’emmagatzema en el servidor.



4.5.13 Cas d’ús logout

El cas d’ús logout possiblement és un dels casos d’ús més simples de l’aplicació. Aquest cas d’ús te

la funcionalitat de deixar sortir els usuaris que ho desitgen. El que farà serà destruir la variable

$_SESSION que hem creat quan el usuari s’ha identificat. Per motius de seguretat i per evitar

vulnerabilitats, abans de destruir la variable $_SESSION, posarem a nul totes les seves sub-

variables. Finalment, destruirem la variable $_SESSION.

CONTRACTE sortir()

Responsabilitat Permetre als usuaris sortir de l’aplicació.

Precondicions 1. Existeix una variable $_SESSION que identifica al usuari.

Postcondicions 1. Ja no existeix la variable $_SESSION que identifica al usuari.



4.5.14 Cas d’ús configurar sistema

Aquest cas d’ús de configurar el sistema, en realitat es podria generalitzar amb un cas d’ús de

modificar, ja que realment modifiquem les dades de l’empresa. L’he volgut destacar, per poder

remarcar que les dades que es modifiquen aquí, són dades importants, ja que, a través d’aquestes

serà amb les que es farà la facturació, es generaran les balises i es crearan les cartes de port

nacional.

CONTRACTE configurar(nom_complet,nom_comercial,direcció,població,provincia,nif)

Responsabilitat Configurar les dades de l’empresa.

Precondicions 1. Els valors dels paràmetres passats son correctes.

Postcondicions 1. Les dades de l’empresa tenen els nous valors passats per paràmetres.



5. Disseny

5.1 Introducció

El disseny és fonamental en el desenvolupament d’una aplicació. Realitzar un bon estudi dels

requeriments i de les necessitats ens ajuda a definir d’una forma molt precisa les funcionalitats de la

nostra aplicació. Això facilita la feina al programador doncs només se li deixa les decisions

estrictament necessàries del llenguatge de programació.

Al ser una aplicació web, el disseny de les funcions segueix essent molt important, però guanya

molt de pes el disseny web. Al cap i a la fi, el disseny web serà l’intermediari entre l’ usuari i

l’aplicació, ja que, una mala sincronització entre el disseny de l’aplicació i el disseny web fa que

perdem potencialitat en l’aplicació.

Durant el disseny es respectarà el model MVC (Model, Vista Controlador). El model MVC és un

model d’abstracció en el disseny que separa en 3 parts la interfície de l’usuari i la lògica de

l’aplicació. Utilitzaré aquest model en el disseny de l’aplicació Wigow degut a que, per defecte ja

tenim separades les parts. Al tractar-se d’una aplicació web, estem parlant d’un usuari que es

connecta a un servidor. En aquesta connexió tenim per un costat el usuari que rebrà informació i es

mostrarà en el seu navegador (vista), per altre costat tenim el servidor que escoltarà les sol·licituds

del clients que se l’hi connectin i els respondrà (controlador), i finalment, la base de dades i les

funcions de l’aplicació (model).

Servidor

HTML Base de dades i lògica

Com ja passa amb els casos d’ús, no elaboraré un digrama de col·laboració per cada cas d’ús, sinó

que utilitzaré de nou els diagrames genèrics per aquells casos d’ús que són iguals. Aprofundiré més

en aquells casos en que consideri oportú fer-ho. Sent una aplicació web, la majoria de diagrames de

col·laboració s’assemblaran, ja que, la àmplia majoria són de afegir, llegir, modificar i eliminar.

Aquests mètodes més simples són coneguts com a mètodes CRUD (create, read, update i delete).



Sobre la gestió de la base de dades dedicaré un apartat especial anomenat: “3.4 Disseny de la base

de dades”, ja que, el disseny d’aquesta és bastant complex degut a la alta quantitat de dades

diferents que arriba a tractar i les relacions que tenen aquestes dades. En quest apartat hi podrem

trobar una petita introducció sobre les decisions preses en el disseny i el model relacional de la base

de dades.

En l’apartat de disseny de la interfície dedicaré un apartat a parlar sobre la usabilitat de l’aplicació.

Detallaré les decisions en el disseny de la interfície per aconseguir una interfície fàcil d’utilitzar,

intuïtiva i no molt carregada.

5.2 Model de Components

En el següent model de components hi podem trobar tots els components que he creat jo. No hi he

inclòs ni les vistes ni alguna de les llibreries que suporten a les vistes, com són les llibreries del PDF

i de JQuery. També excloem les variables globals $_POST i $_GET. Aquestes variables són vistes

per tots els components de l’aplicació i són utilitzades per recollir la informació dels formularis de

l’aplicació. He considerat oportú no incloure les dues variables globals, ja que, al ser variables

globals tots els components tenen visibilitat d’atribut sobre aquestes variables, per tant, afegirien

moltes més visibilitats en el model i el farien molt complicat de comprendre.

He afegit el component de sistema en el model de components. En aquest component hi he assignat

aquells casos d’ús que no tenien un model directe. Per exemple, el cas d’ús d’executar sentencies

SQL, o el cas d’ús de configurar.

Totes les visibilitats que podem trobar en el model de components són visibilitats d’atribut. Al ser

una aplicació web, no passem dades com a paràmetres. Passarem totes les dades a través de les

variables globals $_POST i $_GET.

Amb la finalitat de fer més comprensible el model de components, no he inclòs els mètodes que pot

executar cada un dels components. Els llistaré tots a sota en l’apartat de “3.2.1 Llista de

Components”.



Diagrama de components



5.2.1 Llista de components

Component Centre

Mètodes mostrar_centre_del_usuari(id), llistar_centres()

Visibilitats

Component Usuari

Mètodes mostrar_dades_usuari(id), afegir_usuari(data), modificar_usuari(id,data),

eliminar_usuari(id), login(data), logout(), modificar_contrasenya(data)

Visibilitats tenda, client, albarà, ruta, servei, tipo_servei, re-facturació, centre, accés

Component Accés

Mètodes llistar_accessos(), mostrar_acces_usuari(id)

Visibilitats

Component Re-facturació

Mètodes

mostrar_refacturacio_per_tenda(id),

mostrar_refacturacio_global_per_centre(id), mostrar_comptabilitat_centre(id),

imprimir_extracte_tenda(id,data,data), imprimir_extracte_global(id,data,data),

Visibilitats tenda, centre, serveis

Component Tenda

Mètodes llisar_tendes(), afegir_tenda(data), modificar_tenda(id,data),

eliminar_tenda(id)

Visibilitats

Component Albarà

Mètodes cear_nou_albara(), assignar_client(id), guardar_albara(), eliminar_albara(id),

imprimir_balises(id), assignar_ruta(id), modificar_estat(data),

modificar_comentaris(data), mostrar_albarans_per_client(id),

mostrar_albarans_per_ruta(id), buscar(clau)

Visibilitats client, servei, tenda, ruta



Component Ruta

Mètodes crear_ruta(data), mostrar_ruta(data), imprimir_balises_ruta(id),

imprimir_packlist_ruta(id)

Visibilitats albarà

Component Servei

Mètodes afegir_nou_servei(id), modificar_servei(id,data), eliminar_servei(id),

assignar_data_entrega(id,data), assignar_tipusservei_a_servei(id),

mostrar_serveis_entre_dates(data,data), mostrar_serveis_per_albara(id),

canviar_estat_servei(id,data)

Visibilitats Tipo_servei

Component Tipus_servei

Mètodes llistar_tipusservei(), afegir_tipusservei(data), modificar_tipusservei(id,data),

eliminar_tipusservei(id), mostar_tipusservei_per_servei(id)

Visibilitats

Component Client

Mètodes mostrar_client_per_albara(id), mostrar_client(id), mostrar_client_per_ruta(id),

modificar_client(id), eliminar_client(id), afegir_nou_client(data),

modificar_estat(), buscar(clau)

Visibilitats albarà

Component Sistema

Mètodes executar(consultaSQL), mostrar_dades(), configurar(id),

Visibilitats



5.3 Diagrames de Col·laboració

En aquest punt, veurem els diagrames de comunicació de tots el casos d’ús. Tal i com he comentat

anteriorment, en els casos d’ús no detallaré el 100% dels casos, ja que molts dels casos que hi ha,

ara són diagrames i són molt similars, com hem dit són mètodes CRUD. Tornaré a utilitzar de nou

els diagrames genèrics per aquells casos que són iguals a la resta. Aprofundiré en aquells casos que

són més complexes.

5.3.1 Digrama genèric d’afegir

Afegir genèric fa referència a totes aquelles instancies de l’usuari al sistema que tenen la finalitat de

crear algun paràmetre nou. En el cas d’afegir intervé el controlador que és qui rep directament

l’ordre de crear. El controlador és el responsable de rebre les dades del formulari i de delegar la

responsabilitat de crear al component que correspongui. Serà el component qui posteriorment

executarà la sentencia a la base de dades per crear el nou element. Un cop ja s’ha creat el element,

el controlador envia una ordre d’actualització a la vista perquè s’actualitzi amb el nou missatge que

l’hi passa. Aquest missatge podria ser un missatge de confirmació indicant al usuari que s’ha

executat la seva sol·licitud.

El formulari el recollim a través de la variable global $_POST. Aquesta variable la rep el

controlador a través de la vista. Com que és una ordre de creació, el component no retorna rés.

ConsultaSQL representa una sentencia SQL que la base de dades compren. Aquesta sentencia ha

estat construïda pel component amb les dades que ha recollit el controlador de la variable $_POST.



5.3.2 Digrama genèric de modificar

El modificar fa referència aquelles instancies de l’usuari que pretenen modificar algun registre de la

base de dades. Totes les modificacions que l’usuari realitzi sobre els registres de la base de dades,

prèviament se l’hi han de mostrar les dades perquè aquest les pugui modificar. Per tant, dins del cas

de modificar tindrem 2 casos, el primer ens mostrarà les dades a modificar i el segon cas, recollirà

les dades modificades per l’usuari i actualitzarà les dades del registre amb les noves dades. El

controlador rep la instància de modificar amb el identificador i sol·licita al component en el que

correspon el registre a modificar, que l’hi carregui les dades del registre en qüestió. Un cop el

controlador té les dades les envia a la vista perquè el usuari les pugui visualitzar.

Les dades es mostren a l’ usuari a través del formulari $_POST. Aquest formulari no té els camps

buits, sinó que, els camps contenen la informació que l’usuari vol modificar. Per exemple, si volem

modificar les dades d’un usuari, primer sol·licitem al sistema que ens mostri les dades del usuari. Es

mostrarà per pantalla un formulari amb les dades sol·licitades i serem nosaltres els qui modificarem

les dades corresponents i sol·licitarem que és guardin de nou a la base de dades.

En el moment que vulguem guardar les dades que hem estat modificant, enviarem de nou un

sol·licitud al sistema perquè es guardin les dades que tinc en el formulari del navegador. El

controlador serà qui capturarà aquesta instància, recollirà la variable $_POST del nostre navegador

amb les dades del formulari i delegarà al component en qüestió la responsabilitat d’actualitzar

aquestes dades a la base de dades.



En el diagrama anterior tal i com hem vist en el cas d’afegir, tenim el component “component”,

això és degut a que estem representant un cas genèric. En un cas en concret no tindríem al

component “component”, sinó que, tindríem el component a qui l’hi correspon la responsabilitat de

modificar el registre de la base de dades. Aquest component és el responsable de construir la

sentencia SQL amb les dades actualitzades passades per el controlador.

5.3.3 Digrama genèric d’eliminar

Eliminar fa referencia aquelles instàncies del sistema que tenen la finalitat de suprimir algun

registre de la base de dades. Deleguem la responsabilitat de capturar d’aquest esdeveniment de

sistema al controlador. Per motius de seguretat i per evitar que es perdi informació per un error

humà, he incorporat una confirmació una vegada hem executat el esdeveniment de sistema

d’eliminar. El sistema no procedeix a elimina els registres fins que no ha rebut la confirmació de

que si que volem suprimir els registres.

El controlador captura el esdeveniment de suprimir i sol·licita a la vista una confirmació. El

controlador retindrà el identificador del registre a suprimir, en cas de que la confirmació sigui

positiva procedirà a eliminar el registre i en cas de que la confirmació sigui negativa suprimirà el

identificador i no executarà cap procés.



Com he comentat anteriorment, el controlador sol·licita a la vista una confirmació per evitar que es

suprimeixin dades per error. Retindrem el identificador del registre a eliminar en la variable global

$_POST. En cas afirmatiu procedirem a eliminar el registre, en cas negatiu, ignorarem el

identificador de la variable $_POST. Per al usuari aquesta confirmació es traduirà en un script de

JQuery que ens bloquejarà la pantalla i només ens permetrà polsar els botons de Acceptar o

Cancel·lar.

En cas de que la confirmació sigui positiva el controlador procedeix a eliminar el registre. Delega al

component en qüestió la responsabilitat d’eliminar de la base de dades el registre corresponent al

identificador. Tot seguit, el controlador envia a la vista una ordre perquè s’actualitzi amb un

missatge. Aquest missatge podria ser un missatge per confirmar que s’ha suprimit el registre.



5.3.4 Digrama genèric de mostrar

El cas de mostrar ja l’he comentat una mica en el cas genèric de modificar, ja que, abans de que el

l’usuari pugui modificar les dades, aquestes dades han de ser mostrades. Tot i així, aquí explicaré

més detalladament, aquest esdeveniment de sistema.

El controlador és el responsable de capturar l’esdeveniment de sistema i delegar al component que

l’hi correspongui la responsabilitat de carregar les dades de la base de dades. El controlador pot

rebre aquesta sol·licitud a través de una URL directa o a través d’un enllaç. Pot ser que, en el

mostrar d’algun element intervinguin més d’un component. Per exemple, per carregar un albarà, el

albarà carrega les dades del client associat, les dades pròpies del albarà i les dades dels serveis

associats en aquell albarà.

El component és el que elabora la consulta a la base de dades amb el identificador. Un cop les

recupera, les retorna al controlador. El controlador és el responsable envia a la vista les dades

carregades per el o els components. L’usuari se l’hi mostraran les dades a través del navegador i en

format de formulari, però amb els camps omplerts amb les dades sol·licitades.

5.3.5 Digrama d’afegir albarà

Afegir un albarà és el esdeveniment de sistema més complex que tenim en el disseny de l’aplicació

Wigow. En aquest esdeveniment de sistema hi intervenen varis components, a més a més, per el

principi d’incorporació tardana, afegirem el albarà al final de tot, un cop tinguem totes les dades del

albarà completes. No ens interessa que es pugui afegir informació incompleta en el sistema, per

aquest motiu aplicarem la incorporació tardana. El controlador serà el responsable de capturar tots



els esdeveniments de sistema. Aquest anirà emmagatzemant tota la informació que es vagi afegint a

través dels formularis. No procedirà a delegar-la als components corresponents perquè l’afegeixin a

la base de dades fins que no tingui tota la informació completa.

Tota la informació es va emmagatzemant en la variable $_SESSION, he decidit guardar-la aquí

perquè la variable $_SESSION és única per cada usuari. A més a més, és destruïda cada cop que es

finalitza la sessió o es tanca el navegador del usuari.



Un cop el controlador ja disposa de tota la informació necessària per poder afegir l’ albarà, ja

accepta l’ esdeveniment de sistema per guardar l’albarà. Per afegir un albarà no és tant senzill com

pot ser afegir qualsevol altre registre. Un cop tenim tota la informació del albarà, si l’usuari executa

el l’esdeveniment de sistema per guardar l’ albarà, el controlador és el responsable de capturar

aquest esdeveniment de sistema. Com que tenim la informació del albarà, el client i dels serveis

emmagatzemada en la variable global $_SESSION, el controlador delega a cada un dels

components implicats en el albarà, la responsabilitat d’afegir els registres corresponents.

En aquest cas tenim implicats el client que és el que afegeix el client del albarà a la base de dades,

el l’albarà, que afegeix el nou albarà i finalment, el servei, que s’encarrega d’afegir tots els registres

corresponents als serveis sol·licitats. L’ordre d’inserció és molt important, ja que, alguns

components necessiten els identificadors d’altres. Per això, primer afegirem el client, després el

l’albarà i finalment, els serveis.

Un cop el controlador ja ha delegat a tots els components la responsabilitat, envia a la vista una odre

d’actualització amb un missatge. Aquest missatge pot ser un missatge de confirmació indicant que

la inserció ha estat satisfactòria.

5.3.6 Digrama de buscar

El buscar és utilitzat per l’usuari per buscar albarans o clients de forma directa dins la base de

dades. El controlador és qui captura l’esdeveniment de sistema amb la clau. Aquest delega la



responsabilitat als components de client i albarà. Els passa la clau i espera que aquests l’hi retornin

els resultats obtinguts de la cerca. No sempre tenen perquè retornar resultats. Només retornaran

resultats quan trobin coincidències. El sistema buscarà per la base de dades qualsevol coincidència

que trobi amb la paraula clau. No serà necessari que la paraula clau coincideixi amb un registre, es

consideraran resultats aquells registres que siguin o continguin la paraula clau.

Un exemple de cerca podria ser:

Suposant que tenim la clau: Joan i tenim els registres amb:

Joan

Pere

Joan Josep

Joana

Pere Joan

El sistema en aquest cas anterior ens retornaria els registres següents:

Joan

Joan Josep

Joana

Pere Joan

Com veiem el sistema no només retornarà la coincidència completa amb el registre, sinó que, també

ens retornarà aquells registres que contenen la clau. Aquesta forma de cerca ens facilitarà la cerca,

ja que, no serà estrictament necessari haver de buscar el registre complert. Finalment, el controlador

enviarà a la vista, els resultats obtinguts tant d’albarans com de clients.



5.3.7 Digrama assignar ruta

Assignar ruta servirà per poder programar un albarà en una ruta determinada. Serà la forma que

tindrem d’anar agrupant albarans de clients. Aquest esdeveniment de sistema simplement el que

farà és actualitzar el identificador que indexa a una ruta del registre del albarà en concret. Per

defecte, l’albarà tindrà a null el camp del registre que indexa amb una ruta en concret.

El controlador serà qui rebrà el esdeveniment de sistema. Aquest serà el responsable de delegar la

responsabilitat al component albarà. L’albarà serà el que rebrà el identificador del albarà i el

identificador de la ruta, amb això, executarà una sentencia SQL per actualitzar el valor.

Aquest esdeveniment de sistema només estarà disponible en el moment que tots els serveis del

albarà tinguin com a estat: “Disponible”. Aquest fet indicarà que el albarà està preparat i per tant, es

pot assignar a una ruta.

Finalment, el controlador un cop delgada la responsabilitat d’assignar la ruta al component albarà,

enviarà una ordre d’actualització a la vista, perquè aquesta s’actualitzi i mostri el nou estat.

5.3.8 Digrama de canviar d’estat

El esdeveniment de sistema de canviar d’estat ens permetrà modificar l’estat d’un servei determinat.

Aquest esdeveniment serà utilitzat dins del albarà, anirem canviant l’estat de tots els serveis del

albarà a mesura que vagi evolucionant fins que tinguem tots els serveis a “Disponible”, llavors

podrem executar l’ esdeveniment de sistema d’assignar ruta.



El controlador és qui rep la sol·licitud de canvi d’estat i delega al component servei la

responsabilitat de realitzar la modificació a la base de dades. El component servei rep el

identificador del servei que ha de modificar i el nou valor del estat dins la variable nou_estat.

Un cop delegada la responsabilitat, el controlador envia una ordre a la vista perquè aquesta

s’actualitzi i així agafi el nou valor del servei.

5.3.9 Digrama de canviar contrasenya

Canviar la contrasenya té la finalitat de permetre l’ usuari canviar la contrasenya. El formulari per

posar la nova contrasenya no sempre està habilitat. Necessita un esdeveniment de sistema per part

del usuari que habiliti aquest formulari. El controlador és el que rep el esdeveniment i envia a la

vista una sol·licitud perquè aquesta mostri l’usuari el formulari per canviar la contrasenya.



Un cop ja tenim habilitat el formulari, a l’usuari l’hi apareixeran 2 camps per introduir la nova

contrasenya. Aquesta nova contrasenya, ha de ser igual en els dos camps. Per motius de seguretat

farem que l’usuari tingui que repetir 2 vegades la mateixa contrasenya. D’aquesta manera reduïm la

possibilitat de que l’usuari introdueixi de forma errònia la seva contrasenya.

Un cop introduïda dues vegades la nova contrasenya, l’usuari pot prémer guardar. Si les dos

contrasenyes que ha introduït el usuari són iguals s’executa l’esdeveniment de sistema que guarda la

nova contrasenya. Aquest esdeveniment de sistema el rep el controlador, aquest sol·licita a la vista

les noves contrasenyes que ha introduït l’usuari. Tot seguit, delega al component usuari la

responsabilitat de guardar la nova contrasenya.

El component usuari és el responsable de modificar la contrasenya del usuari que ha sol·licitat el

canvi de contrasenya. Com que l’usuari el tenim emmagatzemat dins de la variable global

$_SESSION no necessitem que el usuari indiqui quin és el seu usuari.

Finalment, el controlador un cop delegada al usuari la responsabilitat de modificar la contrasenya,

envia a la vista una ordre d’actualització amb un missatge. Aquest missatge pot ser un missatge de

confirmació indicant que el canvi ha estat satisfacció.



5.3.10 Digrama de netejar sistema

Netejar el sistema es refereix l’ esdeveniment des sistema que neteja la base de dades d’aquella

informació que té més de 5 anys. Per motius de seguretat i per evitar que es perdi informació he

afegit una confirmació com el esdeveniment genèric d’eliminar. Aquest esdeveniment és capturat

pel controlador i és el propi controlador qui sol·licita a la vista una confirmació de si realment

volem realitzar la neteja.

La confirmació tal i com hem fet amb el esdeveniment de sistema genèric d’eliminar, utilitzarem un

script del JQuery que ens bloquejarà la pantalla i només ens permetrà polsar els botons de Acceptar

o Cancel·lar. En cas afirmatiu es precedirà a executar el següent esdeveniment de sistema.



El controlador és el que captura l’esdeveniment del sistema. El controlador delega als components

de client, albarà i servei la responsabilitat de que aquests netegin les seves dades més antigues. En

aquest punt hi ha un aspecte molt important que és l’ ordre en que es du a terme aquesta neteja.

Primer s’ha de suprimir els albarans més antics de 5 anys, tot seguit, els serveis associats a cada un

d’aquests albarans suprimits i finalment, eliminar aquells clients que s’han quedat sense albarà. Si

no ho fem en aquest ordre no podrem veure quins són els clients que s’han quedat sense albarà.

Un cop fetes totes les delegacions, el controlador envia a la vista una ordre d’actualització amb un

missatge, que podria ser un missatge de confirmació indicant que s’ha realitzat la neteja

correctament.

5.3.11 Digrama d’executar sentencia SQL

Aquest esdeveniment de sistema és una mica delicat, ja que, el fet de que l’usuari pugui executar

directament una sentencia SQL, dóna moltes possibilitats. Per aquest motiu, s’ha associat aquest

esdeveniment de sistema al component sistema, ja que, no es pot saber sobre quins components

influirà la sentencia SQL del usuari. El controlador rebrà el esdeveniment de sistema i delega al

component sistema la responsabilitat d’executar la sentencia SQL. Al no tenir retorn encara que

s’executi un select no es podrà mostrar. El controlador un cop delegada la responsabilitat, envia a la

vista una ordre d’actualització amb un missatge que pot ser de confirmació.



5.3.12 Digrama de login

El control d’usuaris de l’aplicació, està controlat per el esdeveniment de sistema accés. Aquest

esdeveniment de sistema té la finalitat de comprovar si l’usuari pertany a l’aplicació. En cas

afirmatiu, construir les corresponents variables per tindre l’usuari identificat i que pugui accedir a

l’aplicació.

El controlador és el responsable de capturar l’esdeveniment de sistema accés. Rep l’ usuari i la

contrasenya que l’usuari ha intruït per identificar-se. Tot seguit, delega al usuari la responsabilitat

de buscar a la base de dades. L’hi passa l’usuari que haurà de correspondre a un registre de la base

de dades. L’usuari retorna al controlador les dades que ha trobat a la base de dades coincidents amb

el usuari. Finalment, és el controlador que comprova que la contrasenya introduïda per l’usuari

correspon a la de la base de dades. Envia a la vista una instrucció d’accés amb un booleà que indica

si ha estat satisfactòria o no la identificació.

5.3.13 Digrama de logout

El logout o conegut com a “sortir” fa referència a l’esdeveniment de sistema que permet l’usuari

sortir de l’aplicació. Aquest esdeveniment és capturat per el controlador i és ell mateix qui té la

responsabilitat de suprimir la variable $_SESSION. Tot seguit, envia una ordre d’actualització a la

vista perquè es carregui de nou i comprovi que no està identificat.



5.3.14 Digrama de configurar sistema

Entenem com a configurar el sistema configurar les dades corporatives de l’empresa, el centre on

pertany l’usuari o les dades de l’empresa de transport. Seran 3 formularis que es mostraran en la

mateixa finestra i depenent del formulari que indiquem a guardar modificarà unes dades o unes

altres. En cas de modificar el centre el controlador enlloc de delegar la responsabilitat al sistema la

delega al centre. En els casos propis del esdeveniment de configurar, el controlador delegarà al

component sistema la responsabilitat de modificar les dades. El component de sistema serà el

responsable amb el identificador i les dades de modificar els registres corresponents de la base de

dades. El controlador un cop delegada la responsabilitat enviarà a la vista una ordre d’actualització

amb un missatge que pot ser de confirmació.



5.4 Disseny de la Base de Dades

5.4.1 Introducció

El disseny de la base de dades, és un element clau en la majoria d’aplicacions web. La base de

dades juga un paper important perquè tota la informació l’emmagatzemem dins d’ella. Wigow està

pensat perquè treballi només amb una base de dades. Dins de la base de dades es necessitaran 11

taules. Aquestes taules podem veure com es creen en l’apèndix “7.2 Instal·lació de Wigow”. El

disseny del model relacional ha estat fet a partir de les necessitats de dades a emmagatzemar. Com

podem veure en el model relacional la majoria d’entitats s’han convertit en taules. L’èxit de

l’aplicació està en la forma com estan lligades aquestes taules de la base de dades.

5.4.2 Model Relacional



En el model relacional anterior podem apreciar com la majoria de les taules tenen alguna relació

amb alguna altre. Exceptuant la base de dades de configuració i la d’estats. Aquestes dues taules no

tenen cap relació directa amb cap altre degut a que són taules purament d’emmagatzematge

d’informació. Aquestes taules intervenen per la creació d’elements volàtils, com pot ser, veure el

que es re factura entre dues les cartes de transport, etc...

En el model relacional de la taula de la base de dades, podem veure una decisió en el disseny que no

s’ha tingut en compte abans. Els estats dels diferents elements de l’aplicació, com són el estat del

albarà, l’estat del client o l’estat del servei, no estan referenciats amb la taula d’estats. El motiu

d’aquesta decisió, és que no m’interessa que un component que un dia es va posar en un estat

determinat, a causa de que és modifiqui algun estat, pugui canviat d’estat sense voler-ho. A més a

més, realitzar una consulta extra per carregar només una dada no és molt eficient. El motiu de

perquè existeix la taula amb els estats, és per poder-los indexar tots, que si es volen afegir treure o

modificar que no es tingui que modificar el codi de l’aplicació.

5.5 Disseny de la Interface

5.5.1 Introducció

Per dissenyar la interfície gràfica s’ha decidit utilitzar les fulles d’estil en cascada CSS. Actualment,

la majoria dels navegadors ja accepten les fulles d’estil. Aquest mètode agilitza la càrrega de la

pàgina web, ja que, al recarregar la pàgina o al moure’ns per dins de la pàgina web només carrega la

informació de contingut. Ens estalviem així haver de recarregar informació d’estructura de la

pàgina. Tots els coneixements sobre les fulles d’estil CSS els he adquirit durant el desenvolupament

del projecte. A la bibliografia del projecte hi trobarem un apartat de “Disseny Web” on indicaré

totes les fonts utilitzades per adquirir els coneixements.

En el disseny de la interfície també s’ha tingut en compte la usabilitat de l’aplicació Wigow.

Entenem com a usabilitat, lo pràctic que sigui utilitzar l’aplicació. Que sigui senzilla, intuïtiva, que

no suposi un esforç a l’usuari fer-la funcionar, etc...

5.5.2 Disseny Gràfic

Per elaborar el disseny gràfic s’han utilitzat 2 games monocromàtiques de colors. S’ha utilitzat una

gama de blaus i l’altre de grisos. En alguns moments determinats s’ha utilitzat algun color fora de la

gama, només puntualment en algun icona o algun estat. Sobre l’estructura de l’aplicació s’ha

utilitzat una estructura estàndard. Una capçalera, el cos de la pàgina i el peu de la pàgina. Entre la



capçalera i el cos de la pàgina i he afegit una barra de menús. De forma esquemàtica ens queda de la

següent forma:

Aquesta barra de menús serà diferent per cada usuari de l’aplicació, a més a més, ens anirà indicant

en quina pàgina estem. Tant la capçalera de l’aplicació com el peu, seran els mateixos per tota

l’aplicació. Només anirem variant el contingut del cos de l’aplicació. Aquest fet és important perquè

al ser genèric es pot separar el codi de la capçalera i del peu en arxius diferents. En els fitxers de

cada pàgina hi queda la informació del menú i del contingut de la pàgina. Així millorem la velocitat

de la pàgina, ja que, només ha de carregar una vegada la capçalera i el peu. Tots els canvis de

pàgina només es transmetrà la informació necessària.

A continuació veurem l’aplicació Wigow. Per tal de poder veure totes les funcionalitats, l’aplicació

ha estat omplerta amb dades de demostració. Qualsevol coincidència amb la realitat és pura

coincidència. El 100% de les dades ha estat inventat.

Capçalera

Barra de menús

Contingut

Peu



Pantalla d’accés a l’aplicació.

A la imatge anterior veiem el formulari d’accés que és utilitzat per accedir a l’aplicació. L’aplicació

només s’ha dissenyat en un idioma, però, com a proposta de millora trobarem traduir-la a diferents

idiomes. En la següent imatge veurem ja la pàgina d’inici d’un perfil informàtic.

Pantalla d’inici de l’aplicació.



He utilitzat el perfil d’informàtic per mostrar les diferents pantalles de l’aplicació perquè aquest

perfil té accés a tots els casos de l’aplicació. En aquest formulari que és per afegir albarans, clients i

serveis a l’aplicació, hi poden accedir el informàtic i el dependent de la tenda. Per evitar repetir

imatges de l’aplicació només mostraré una vegada cada una de les finestres. Més endavant mostraré

quins són els canvis destacats amb els diferents perfils.

Pantalla d’afegir una entrega



Pantalla de veure albarans pendents a tractar.

En la pantalla de mostrar albarans pendents, es mostren tots aquells albarans que no tenen una ruta

assignada. A continuació podem veure la pantalla on podrem crear rutes i mostrar rutes ja existents.

Pantalla per crear i mostrar rutes.



En la següent finestra veiem com es mostra un albarà en l’aplicació. Veiem totes les dades que dona

sobre el client, la tenda sol·licitant i els serveis sol·licitats. De forma intuïtiva ja podem veure com

guardar comentaris, modificar serveis, afegir serveis, eliminar el albarà, modificar estats i imprimir

les balises.

Pantalla de mostrar un albarà.



Com ja hem comentat en la especificació, quan un albarà té tots els serveis en disponible, l’estat del

albarà canvia a disponible i s’habilita una casella per indicar el dia de ruta.

Casella desplegable per indicar el dia de la ruta.

Pantalla de mostrar un client.



Quan anem a introduir una data per mostrar una ruta, se’ns desplega el següent calendari on només

podem seleccionar aquelles dates en que hi ha programada o hi ha hagut una ruta.

Calendari de rutes disponibles per mostrar.

Pantalla de mostrar una ruta.



PDF amb les balises per a tots els serveis d’entrega.



PDF amb el CMR que va amb el full de serveis(packlist).



PDF amb el full de serveis(packlist) que va amb el CMR.



Finestra de Re-facturació.

Finestra de Re-facturació (Assentaments comptables).



Finestra de re-facturació (re-facturació d’una tenda entre dues dates).

La re-facturació d’una tenda ens serveix simplement per poder treure un extracte entre dues dates i

poder veure quin volum de serveis s’ha efectuat entre ambdues dates. No té cap finalitat, perquè

com es pot veure en la captura anterior només tenim l’opció de retrocedir i de imprimir l’extracte.

Com en el cas de les balises dels articles a entregar, si volem imprimir el extracte es genera un PDF

amb la informació preparada per imprimir. L’estructura es similar a la de una factura, però no és

una factura ja que, realment no es generen factures. A continuació, podem veure el PDF generat

amb el extracte de una tenda.



PDF amb la re-facturació d’una tenda entre dues dates.



Finestra de control sense cap opció marcada.

Finestra de control amb la opció d’usuaris desplegada.



Finestra amb els resultats de buscar “10”.

Finestra amb el panell del usuari.



Barra de menús del operari de tenda.

Barra de menús del comptable.

Barra de menús del operari de magatzem.

Barra de menús del gestor dels serveis.

Barra de menús del informàtic de l’aplicació.

Opcions del panell de control del gestor dels serveis.

Opcions del panell de control del informàtic de l’aplicació.

En el cas de que un usuari intenta accedir alguna part de l’aplicació se l’avisa amb un missatge

indicant-li que té denegat l’accés a la informació que sol·licita i que si ho desitja que es posi en

contacte amb el servei de suport informàtic. D’aquesta manera s’evita que un usuari pugui accedir a

informació de la que no està autoritzat.



Finestra d’accés denegat a la informació que es volia accedir.

Hem visualitzat la majoria de les finestres de l’aplicació. He obviat aquelles finestres que són amb

lleugeres modificacions, com ara: la modificació d’un servei o de un client i la re-facturació global.

El motiu per el que les he obviat es perquè son similars a les que hem vist però amb camps diferents

o informació diferent.

5.5.3 Usabilitat

Entenem com a usabilitat, tots aquells aspectes tinguts en compte en el disseny gràfic que faciliten

l’ús a l’usuari. En cas de l’aplicació Wigow, he considerat essencial dedicar-hi un temps per

dissenyar una aplicació que sigui senzilla, fàcil d’utilitzar i intuïtiva. Moltes aplicacions o pàgines

web no tenen gens en compte la usabilitat, per aquest motiu, ens podem trobar pàgines web o

aplicacions molt difícils d’utilitzar, que encara que hi prestem atenció ens suposa un gran esforç

utilitzar-la. A continuació detallaré quins han estat els aspectes considerats en el disseny de Wigow:

Interfície homogènia:

Que tota l’aplicació tingui la mateixa estructura, els mateixos colors, permet a l’usuari

treballar molt millor. Si a cada pàgina es modifica l’estructura es desorienta a l’usuari, ja

que, cada cop ha de tornar a mirar que pot fer i que no. Si no es varia l’estructura i només

variem el contingut facilitarem molt més la navegació del usuari.



Sobrecàrrega del menú:

Tenir una barra de menús amb moltes opcions a priori sembla fantàstic, perquè al cap i a la

fi són funcionalitats, però un excés d’opcions sobrecàrrega el menú i l’usuari. Un excés

d’opcions crea a l’usuari una sensació de inseguretat ja que, el porta a pensar que poder no

és la millor forma d’accedir a la informació. En l’aplicació Wigow he respectat aquest

aspecte. El gestor de l’aplicació que és l’usuari amb més permisos no supera les 5 opcions

en la barra de menús. Només és l’informàtic que disposa de 6 menús, però, al ser un usuari

més avançat s’assumeix que no l’hi resultarà un trasbals.

Buscador:

Per facilitar a l’usuari poder buscar en qualsevol moment és essencial que el buscador de

l’aplicació sigui accessible en tot moment. Per aquest motiu, vaig decidir integrar el

buscador a la capçalera de l’aplicació. Així es visible des de qualsevol finestra de l’aplicació

i pot ser utilitzat en qualsevol moment.

Imatge del buscador de l’aplicació.

El buscador és molt senzill. Constituït per un camp on s’introdueix la clau a buscar i un botó

amb un icona d’una lupa per poder buscar. Del icona de la lupa ja s’intueix que estem

parlant d’un buscador.

Espais en blanc:

En deixar espais en blanc hem refereixo a no carregar molt l’aplicació amb continguts.

Deixar els marges corresponents, espais entre informació i informació. Que sigui fàcil de

llegir, fàcil d’identificar la informació i poca dificultat per ser manipulada.

Compatibilitat

Wigow s’ha dissenyat i implementat amb la finalitat de que sigui accessible des de qualsevol

navegador. S’han utilitzat estàndards per aconseguir que els navegadors més coneguts no

tinguin problemes en visualitzar l’aplicació. S’ha comprovat amb Mozilla Firefox, Internet

Explorer, Google Chrome i Safari.



Icones senzills:

Els icones utilitzats també han estat escollits amb la finalitat de que permetin a l’usuari

intuir quina serà la seva funcionalitat. Per exemple, si volem imprimir un document, el icona

que indueix aquesta decisió és una impressora. Així aconseguim que els icones de forma

independent ja informin a l’usuari de les funcionalitats. En l’aplicació podem trobar els

següents icones:

Afegir

Editar

Eliminar

Guardar

Contrasenya

Advertència

GMAIL

Imprimir

Com podem comprovar molts icones ja intueixen tot sols la seva funcionalitat. Els que no està del

tot clar, van acompanyats amb la funció que representen.

Usuaris

Tendes

Serveis

Neteja

Configuració

Base de Dades

Tornar

Restaurar



6. Implementació i Tests

6.1 Introducció

Per tal de poder dur a terme el desenvolupament d’una aplicació com Wigow, és molt important una

bona estratègia de desenvolupament. Hi ha dos principals mètodes de programació, el mètode

tradicional i el mètode àgil. El mètode tradicional és un mètode seqüencial, des del principi fins al

final. No es fins al final que es realitzen les comprovacions. Aquest mètode té principalment com a

inconvenient la poca maniobra de la que disposa.

En canvi el mètode àgil a diferencia del mètode tradicional, revisa l’estratègia en punts entremitjos,

i en cas que fos necessari, pot reajustar les necessitats. En el cas de Wigow, al ser un projecte amb

les necessitats molt definides de les funcionalitats, he utilitzat el mètode de desenvolupament àgil,

ja que, d’aquesta manera, he pogut assegurar complir totes les funcionalitats i les necessitats.

6.2 Estratègia de Desenvolupament

Per cada una de les funcionalitats que he anat desenvolupant del projecte, he anat analitzant si

complia amb els requeriments establerts. En cas de complir-los ja es deixava preparat per el final. Si

no complia els requeriments s’han tornat a implementar per acabar de polir aquells aspectes que no

s’havien tingut en compte la primera vegada.

Per dur a terme la implementació no s’ha utilitzat cap entorn de treball. Tota la programació ha estat

elaborada manualment per part meva. He utilitzat el IDE Komodo Edit. Aquest editor et permet

programar més ràpid ja que, a mesura que vas escrivint et corregeix els errors sintàctics que pots

cometre. Per exemple, cada cop que s’obra un parèntesi, automàticament el editor et posa el que

tanca. A més a més, com fan molts altres editors et posa colors a les funcions i a les variables,

Anàlisi de

Requeriments Implementació Disseny

Tests Verificació Producte final

o entremitjos



d’aquesta manera és molt més fàcil identificar les variables, funcions,...

El motiu per el que he decidit programar-ho tot jo manualment és perquè volia aprendre i aprofundir

en programació d’aplicacions web. Havia utilitzat molt poques vegades el llenguatge de

programació PHP i mai havia utilitzat les fulles d’estil en cascada CSS ni els scripts JAVA. Aquest

fet ha provocat que hagués de realitzar un gran esforç en aprendre la programació i el disseny, però

he considerat que era més interessant que utilitzar un entorn de treball.

6.3 Tests

Com he utilitzat una metodologia de programació àgil, tots els tests i les comprovacions

corresponents les he anat fent durant el desenvolupament de l’aplicació. Per cada funcionalitat o

bloc de funcionalitats s’han anat realitzant comprovacions per comprovar el seu funcionament

correcte. Els errors trobats s’han anat corregint a mesura que s’anaven trobant en les comprovacions

que s’anaven fent. No s’ha realitzat una gran prova d’errors com es fa en les aplicacions

desenvolupades amb el mètode tradicional.

Els errors que s’han trobat al llarg de l’aplicació han estat errors molt comuns en aplicacions web o

pàgines web. Els podem agrupar en els següents blocs:

Errors de programació

Problemes deguts a errors en el codi. PHP al ser un llenguatge interpretat no es compila, per

tant, aquells errors en el codi es traslladen a l’aplicació en funcions que no compleixen la

seva funcionalitat. També varis errors gramaticals no detectats per l’editor, com por ser un

error en la crida de funcions que provocava un error en l’execució de la pàgina PHP.

Errors de maquetació

Amb maquetació s’han corregit molts errors, sobretot en adaptar el disseny amb la

programació. Al tractar amb dades dinàmiques, s’ha hagut de adaptar algunes parts del

disseny perquè fossin dinàmiques. També s’han corregit errors de compatibilitat amb algun

navegador. Hi ha atributs del CSS que són acceptats per alguns navegadors i no per altres.

Errors de usabilitat

S’han produït alguns erros en usabilitat. Directament no existeixen errors en usabilitat, però

he considerat errors en usabilitat, aquelles funcions o finestres que un cop es mostraven a

l’usuari no eren del tot clares. S’han hagut de modificar alguns dissenys per tal de que



complís els principis d’utilitat.

Totes aquestes comprovacions han estat realitzades de forma manual, no s’han elaborat proves

automàtiques per comprovar l’aplicació. S’ha seguit tot el procediment que seguiran els usuaris de

l’aplicació i provant de trobar els casos extrems on pot fallar l’aplicació.

Tant les proves de les funcionalitats i les proves d’usabilitat, han estat comprovades per mi mateix

en persona i per companys de feina que treballen en aquest àmbit. Gràcies a ells he pogut detectar

problemes en funcions però, majoritàriament problemes en la usabilitat. Al ser persones alienes al

projecte m’han pogut donar una opinió externa.

Finalment, com que la base de dades juga un paper molt important, és molt important comprovar la

seva sincronització amb l’aplicació. Per aquest motiu, s’ha realitzat una prova de càrrega sobre la

base de dades. S’han realitzar moltes sol·licituds a la aplicació de forma contínua per comprovar

les connexions de la base de dades. En aquesta prova de càrrega ha arribat un moment que la base

de dades s’ha saturat.

Aquesta prova m’ha permès detectar un error en una connexió d’una part de l’aplicació que establia

la connexió però no les finalitzava, per tant, anava deixant connexions obertes. Aquest error s’havia

escapat de les proves realitzades anteriorment degut a que la pròpia base de dades anava tancant les

sessions inactives, però en cas de un gran volum de sol·licituds l’aplicació no hauria aguantat.



7. Viabilitat

7.1 Definició de Necessitats

Wigow té molt poques necessitats com a requeriments de servidor. El fet de que l’hagi programat

de forma manual, fa que l’aplicació només contingui el codi necessari que necessita. No té ni

llibreries innecessàries, ni complements, ni funcions que mai utilitzarà. Aquest fet l’hi sumem que

el codi ha estat optimitzat per evitar que és repetís codi, fa que tinguem que tota l’aplicació sencera

de Wigow ocupi un total de 3,01MBytes. En aquests 3,01MB s’hi inclouen les imatges i els icones

utilitzats en totes l’aplicació. Tota l’aplicació està dividida de la següent manera:

Com podem veure tenim un total de 244 arxius dividits en 15 carpetes. Un altre dels motius per el

que ocupa tant poc és perquè en la part gràfica s’han utilitzat fulles d’estil que no requereixen

pràcticament imatges. Totes les imatges que podem trobar són majoritàriament icones o petites

imatges per a reproduir moltes vegades i generar la sensació d’una imatge gran. Amb aquesta petita

“trampa” aconseguim reduir el pes de la pàgina i per tant, incrementem la velocitat de càrrega.

Com hem vist l’espai necessari per poder instal·lar l’aplicació és molt petit, per tant, no

considerarem com a requeriment el espai de disc dur. El que si que haurem de tenir en compte és en

la base de dades. Wigow emmagatzema tota la informació a la base de dades, per tant, es

necessitarà una base de dades que compleixi els requisits.

Per calcular els requeriments de la base de dades utilitzaré uns càlculs aproximats tirant cap a

pessimistes per evitar que ens sorprengui després. Suposant que tenim una mitjana de 20 clients

nous al dia, que cada client sol·licita una mitjana de 2 serveis tenim:

20 clients / dia * 365 dies = 7.300 clients per any

7.300 clients / any * 2 serveis = 14.600 serveis per any



Suposant que guardem la informació durant 6 anys i que, per cada sol·licitud d’un client a la base

de dades ens genera un volum de 4,5 Kbytes (contant tot el que comporta el client amb els 2 serveis

de mitja) tenim:

7.300 clients / any * 4,5 Kbytes / client = 32.850 Kbytes / any

32.850 Kbytes / any * 6 anys = 197.100 Kbytes

Per emmagatzemar la informació que hem suposat necessitem aproximadament una base de dades

de 198 Mbytes. Amb aquesta informació l’hi hem de sumar els usuaris més la informació necessària

per la gestió de la base de dades. Tant els usuaris com la configuració incrementen en el pitjor dels

casos uns 5Mbytes. Per seguretat evitarem que la base de dades se’ns carregui més del 80% amb la

suposició. Així disposarem de marge de maniobra en el pitjor dels casos.

Recomano per l’aplicació amb les dades hipotètiques una base de dades com a mínim de 250

Mbytes.

7.2 Model de Negoci

Wigow no està pensat per vendre res. Està pensat per oferir un servei més eficient i econòmic. Al no

vendre productes, es consideren ingressos aquells diners que la nova organització permet estalviar.

D’aquesta forma podem extreure conclusions i veure si ens sortiria rentable o no.

7.2.1 Ingressos

Per fer el càlcul dels ingressos he agafat uns costos ficticis d’una empresa abans i despès d’aplicar

l’aplicació Wigow. Són uns càlculs purament aproximats, no s’han considerat tots els costos que pot

arribar a tenir una empresa. Es tindria que adaptar a la situació particular de cada empresa. S’ha fet

una suposició del temps invertit a gestionar per persones no qualificades. A ingressos veiem el que

ens estalviem per cada servei gestionat amb la nova metodologia.

Costos Actuals

Costos amb Wigow

Gestió del Servei per Tenda 3,5 €

Gestió del Servei per Tenda 2,0 €

Personal Logistic 3,5 €

Gestió del Servei per Magatzem 3,5 €

Transport Intern 13,5 €

Empresa transport 18,0 €

Empresa transport 28,0 €

Costos Manteniment 2,0 €

Total 48,5 €

Total 25,5 €

Ingresos 23,0 €



7.2.2 Costos

El sistema actual té uns costos associats en funció del volum de serveis, el nou sistema

d’organització té uns costos menors que els actuals, però aquests costos l’hi hem de sumar els

costos totals que té desenvolupar l’aplicació. Així podem veure quan de temps tardaria una empresa

en amortitzar els costos i començar obtenir beneficis.

Els costos previstos per desenvolupar l’aplicació en funció amb la planificació inicial són

aproximadament un 21.400€.

Els costos per gestionar cada un dels serveis amb la nova organització veiem que són de 25,5€

comparats amb els 48,5€ que suposa el sistema actual sense l’aplicació Wigow.

Els costos del manteniment de l’aplicació s’han calculat en funció de la necessitat de l’aplicació

contemplats anteriorment en definició de necessitats. S’han dividit els costos de manteniment del

servidor, de xarxa i de suport entre el número de serveis mensuals. En l’apèndix “7.3 Possibles

Servidors de Wigow”, podrem trobar diferents empreses que ofereixen el servei de hosting i de

servidors dedicats.

7.2.3 Conclusions

Amb la finalitat de poder extreure conclusions coherents, he realitzat una taula amb els costos

inicials. En aquests costos se l’hi ha sumat els costos variables en funció del número de serveis.

Seguint la hipòtesi de 20 clients al dia amb una mitjana de 2 serveis per client, tenim els següents

resultats:

Actual Wigow

Sem 1 13.580,0 € 28.539,6 €

Sem 2 27.160,0 € 35.679,6 €

Sem 3 40.740,0 € 42.819,6 €

Sem 4 54.320,0 € 49.959,6 €

Sem 5 67.900,0 € 57.099,6 €

Sem 6 81.480,0 € 64.239,6 €

Sem 7 95.060,0 € 71.379,6 €

Sem 8 108.640,0 € 78.519,6 €

Sem 9 122.220,0 € 85.659,6 €

Sem 10 135.800,0 € 92.799,6 €

Sem 11 149.380,0 € 99.939,6 €

Sem 12 162.960,0 € 107.079,6 €



A partir de la taula anterior elaborem la següent gràfica amb la finalitat de poder veure molt més

visualment la diferència entre costos d’un sistema d’organització amb el nou sistema proposat amb

l’aplicació Wigow.

Com hem vist el nou sistema d’organització a la 4ª setmana ja hem amortitzat els costos de

desenvolupament de l’aplicació. Per tant, a partir de la 5ª setmana ja comencem a reduir costos.

Realment no són beneficis, sinó que, parlem de reducció de costos.

En conclusió, el nou sistema de gestió de les entregues proposat per Wigow és un sistema que, a

priori, és rentable. Serà en funció de l’empresa, els costos específics i del número de serveis podem

tardar més inclús menys en amortitzar la inversió inicial.

0,0 €

20.000,0 €

40.000,0 €

60.000,0 €

80.000,0 €

100.000,0 €

120.000,0 €

140.000,0 €

160.000,0 €

180.000,0 €

Sem1

Sem2

Sem3

Sem4

Sem5

Sem6

Sem7

Sem8

Sem9

Sem10

Sem11

Sem12

Actual

Wigow



8. Balanços i conclusions

8.1 Planificació final i anàlisi

Finalment després de desenvolupar el projecte, fent el recompte d’hores invertides en desenvolupar

totes les tasques, he tingut que balancejar els pesos de les diferents tasques. Amb la planificació

inicial vaig fer una estimació del temps que dedicaria, en programació vaig planificar un total de

220 hores, quan un cop traslladat a la realitat, vaig realitzar la feina amb 180 h. Aquestes hores

sobrants les vaig dedicar al disseny web. El disseny web es va fer molt més costós del esperat, els

tests que vaig elaborar durant tota l’aplicació, van fer que hagués de modificar moltes vegades el

disseny web perquè no complia amb els principis d’usabilitat esperats.

La data de finalització del projecte era el 10 de gener del 2013, finalment, el projecte l’he acabat el

dia 23 de gener del 2013. S’ha enrederit un total de 13 dies. El motiu per el que s’hagi enrederit ha

estat per motius laborals. Durant uns dies que tenia previstos no he pogut seguir amb la planificació

perquè he estat ocupat amb altres temes. Tot i el retràs, el número total d’hores ha acabar sent el

mateix, distribuïts de la següent forma:

Professional Horas Total

Analista 100 100

Programador 180 280

Dissenyador Web 110 550

Maquetador 160 440

Documentador 80 630

La nova distribució d’hores no afecta econòmicament al cost del projecte. S’han mogut hores d’un

especialista a un altre que tenen el mateix cost/hora. La resta de temps que es van planificar s’han

respectat perfectament sense cap problema. Generalment, s’han complert els objectius que es van

marcar a l’ inici del projecte.

8.2 Conclusions i propostes de millora

8.2.1 Conclusions

Wigow ha sigut una gran experiència per a mi, no només per el desenvolupament tècnic de

l’aplicació, sinó per el nivell d’organització que he hagut d’assolir a nivell personal per dur a terme

el projecte. Mai havia dut a terme un projecte d’aquesta envergadura, on jo tenia que desenvolupar

totes les parts del projecte. En tots els projectes que havia treballat, havia estat un membre més del

projecte, mai el protagonista. Poder desenvolupar totes les funcions dels diferents especialistes m’ha



permès poder-me posar a la pell d’altres persones i entendre moltes de les decisions.

A nivell tècnic, he aprés moltes coses noves en el desenvolupament del projecte, he aprés

programació PHP, maquetació CSS i a utilitzar JQuery. Tots aquests coneixements no els havia

adquirit mai abans de desenvolupar el projecte, per això, considero que ha estat molt profitós ja que,

cada cop més, s’utilitzen aquestes eines per la creació d’aplicacions i pàgines Web.

Sobre l’aplicació Wigow, després de realitzar l’estudi de viabilitat considero que el projecte ha estat

un gran èxit. Si que té uns costos inicials, però aquesta inversió es recupera molt ràpidament, ja que,

el estalvi que et produeix el nou sistema d’organització permet recuperar la inversió molt

ràpidament. En el càlcul realitzat en un cas hipotètic recuperar una inversió inicial en 4 setmanes es

pot considerar una inversió molt rentable. En empreses on el volum d’expedició fos menor es

tardaria una mica més en recuperar la inversió però, en un temps raonable es recupera. Amb la

situació actual es difícil incrementar els ingressos, per tant, una bona forma per incrementar els

beneficis és reduint els costos.

Respecte a la planificació inicial comparat amb el que ha acabat sent el projecte, la conclusió que en

trec és que és molt important portar la feina al dia, sobretot quan participes en un projecte d’aquesta

envergadura. Apurar a les dates m’ha demostrat que t’enredereix el projecte perquè sempre surten

imprevistos en algun apartat del projecte.

El projecte demostra que sense invertir molts diners i fent canvis en l’organització podem obtenir

grans beneficis. He pogut demostrar que la meva proposta d’una nova organització és molt més

rentable que l’organització actual en moltes empreses. Per tant, hem sento satisfet perquè la meva

idea no era una idea esbojarrada sinó que una idea que el projecte Wigow permet dur a terme.

8.2.2 Propostes de millora

En el projecte es podrien afegir infinitat de noves coses. Tal i com he comentat en la memòria, una

proposta de millora podria ser traduir l’aplicació a diferents idiomes per poder arribar a més països.

Altres propostes podrien ser com ara:

Un sistema de notificacions per e-mail per informar el client del estat del servei.



Permetre que l’usuari final pugui accedir a l’aplicació per fer un seguiment.

Integració amb sistemes de gestió de les empreses on s’implementa l’aplicació.

Elaborar un sistema per calcular els kilòmetres entre punt i punt i que s’automatitzés els

serveis en funció de la distància.

Notificar als clients per SMS.

.....

Són moltes les propostes que es podrien afegir a l’aplicació. Wigow és una aplicació de gestió i

depenent de l’empresa on es dugués a terme, en funció de les seves necessitats l’hi interessaria

afegir algunes millores o les altres. Segurament, alguna empresa té una necessitat específica que no

s’ha tingut en compte.



9. Annexos

9.1 Instal·lació de LAMP

Instal·lar LAMP server a un sistema operatiu Linux és realment senzill, com hem comentat

anteriorment LAMP és un grup de programes que combinats entre si ens permeten poder crear un

servidor web amb les seves corresponents eines. Per instal·lar-ho podem utilitzar dos mètodes, de

forma manual, és a dir, instal·lant tots els programes un per un o directament utilitzant un grup de

paquets existent que ens instal·larà de forma automàtica totes les aplicacions. A continuació,

detallem els dos mètodes d’instal·lació:

Mètode Manual

De forma manual tenim que instal·lar tots els paquets dels diferents programes de forma

individual. Si el ubuntu en el que estem disposa de entorn Gràfic podríem utilitza el

Gestor de Paquets Synaptic, en cas que no el disposi, utilitzarem la el terminal de Ubuntu.

Òbviament sempre podem utilitzar el terminal de Ubuntu abans que el Gestor de Paquets

Synaptic.

Apache

Des del Terminal de Ubuntu introduïm la següent comanda:

El mètode sudo apt-get install ens descarrega els paquets per poder instal·lar el programa

que té a continuació i l’instal·la. Un cop finalitzi aquest procés ja tenim el servidor

Apache instal·lat. Si en algun moment determinat necessitem aturar o encendre el

servidor apache, el podem aturar amb la comanda:

I si necessitem posar-lo en marxa de nou executarem la següent comanda:

Un cop finalitzats quests passos ja tenim disponible el servidor Apache, podem

comprovar que ho hem fet be accedint al navegador a la següent URL: http://localhost/

sudo apt-get install apache2

sudo /etc/init.d/apache2 stop

sudo /etc/init.d/apache2 start



sudo /etc/init.d/apache2 stop

sudo /etc/init.d/apache2 start

PHP

Per instal·lar el llenguatge de programació d’alt nivell PHP es tant simple com executar

la següent comanda en el terminal de Linux:

Un cop finalitza ja tenim instal·lat el llenguatge PHP en el nostre servidor Apache, si

teníem el servidor Apache apagat quan l’engeguem ja ens funcionarà correctament amb

PHP, però si el teníem encès necessitem reiniciar-lo perquè funcioni correctament. Per

reiniciar el servidor Apache perquè ens agafi la nova configuració executarem la següent

comanda:

Per verificar que funciona provarem de obrir amb el nostre navegador qualsevol pàgina

php per comprovar que està tot correcte.

MySQL

Accedirem al terminal de Linux i executarem la següent comanda:

Durant la instal·lació ens demanarà la contrasenya que l’hi volem posar al usuari root.

Aquesta contrasenya serà la que ens servirà per primera vegada per accedir la nostre base

de dades. Un cop finalitzada la instal·lació, accedirem a la base de dades i eliminarem el

usuari root. Realment no es estrictament necessari, però per seguretat l’eliminarem ja que

es el usuari estàndard i on atacaran en cas que ens vulguin entrar a la nostre base de

dades.

Per instal·lar MySQL amb totes les funcionalitats, l’hi instal·larem també uns paquets

suplementaris. Ho farem de la següent manera:

Per accedir a la base de dades per primera vegada hem de recordar de utilitzar el usuari

root amb l contrasenya que hem posat durant la instal·lació.

sudo apt-get install php5 libapache2-mod-php5 php5-cli php5-mysql

sudo /etc/init.d/apache2 restart

sudo apt-get install mysql-server

sudo apt-get install mysql-client mysql-admin mysql-query-browser libmysqlclient-dev



9.2 Instal·lació de Wigow

Amb l’objectiu d’evitar problemes amb els camps de la base de dades, cap dels identificadors

d’atribut porta accents ortogràfics ni lletres que no estiguin en el teclat internacional. Depenent del

servidor MySql en el que s’executés podria donar problemes, per tant, evitarem aquests problemes

si evitem escriure els accents ortogràfics. La instal·lació de Wigow realment és molt senzilla. Es

carreguen tots els fitxers de l’aplicació al servidor, es modifica la connexió a la base de dades i

s’executen les següents comandes SQL sobre la base de dades.

Les comandes que trobarem a continuació són les comandes que creen les taules de les base de

dades amb tots els camps i estableix les relacions que tenen aquestes taules. Executarem les

següents comandes:

//Taula Albarans

CREATE TABLE albarans (

id_albara int NOT NULL,

id_client int NOT NULL,

data_compra date NOT NULL,

num_ruta int NOT NULL DEFAULT 1,

data_entrega date NULL DEFAULT NULL,

venedor varchar(20) NOT NULL COLLATE utf8_spanish_ci,

tenda int NOT NULL,

gestor int NOT NULL,

comentaris varchar(500) NULL COLLATE utf8_spanish_ci DEFAULT NULL,

estat_albara varchar(20) NOT NULL COLLATE utf8_spanish_ci DEFAULT 'Pendent',

PRIMARY KEY(id_albara),

FOREIGN KEY(id_client) REFERENCES clients(id_client),

FOREIGN KEY(num_ruta) REFERENCES rutes (id_ruta)

)

//Taula Clients

CREATE TABLE clients (

id_client int NOT NULL AUTO_INCREMENT,

nom varchar(20) NOT NULL COLLATE utf8_spanish_ci,

cognoms varchar(50) NOT NULL COLLATE utf8_spanish_ci,

direccio varchar(100) NOT NULL COLLATE utf8_spanish_ci,

poblacio varchar(50) NOT NULL COLLATE utf8_spanish_ci,

postal int NOT NULL,

telefon int NOT NULL,

email varchar(50) NOT NULL COLLATE utf8_spanish_ci,

observacions varchar(200) NOT NULL COLLATE utf8_spanish_ci,

estat_client varchar(20) NOT NULL COLLATE utf8_spanish_ci,

PRIMARY KEY(id_client)

)



//Taula Estats

CREATE TABLE estats (

id_estat int NOT NULL AUTO_INCREMENT,

estat varchar(20) NOT NULL COLLATE utf8_spanish_ci,

PRIMARY KEY(id_estat)

)

//Taula Rutes

CREATE TABLE rutas (

id_ruta int NOT NULL AUTO_INCREMENT,

data_ruta date NULL DEFAULT NULL,

PRIMARY KEY(id_ruta)

)

//Taula Serveis

CREATE TABLE serveis (

id_servei int NOT NULL AUTO_INCREMENT,

id_albara int NOT NULL,

article int NULL DEFAULT NULL,

descripcio varchar(100) NULL COLLATE utf8_spanish_ci DEFAULT NULL,

tipus_servei varchar(20) NULL COLLATE utf8_spanish_ci DEFAULT NULL,

tipus_ed varchar(20) COLLATE utf8_spanish_ci NULL DEFAULT NULL,

estado_servicio varchar(20) NULL COLLATE utf8_spanish_ci DEFAULT 'Pendent',

id_entrega int NULL DEFAULT NULL,

data_entrega date NULL DEFAULT NULL,

PRIMARY KEY(id_servei),

FOREIGN KEY(id_albara) REFERENCES albarans(id_albara),

FOREIGN KEY(id_entrega) REFERENCES tipusentrega(id_entrega)

)

//Taula Tendes

CREATE TABLE tendes (

id_tienda int NOT NULL,

nom_tenda varchar(50) NOT NULL COLLATE utf8_spanish_ci,

direccion_tienda varchar(100) NOT NULL COLLATE utf8_spanish_ci,

postal_tienda int NOT NULL,

poblacion_tienda varchar(50) NOT NULL COLLATE utf8_spanish_ci,

provincia_tienda varchar(50) NOT NULL COLLATE utf8_spanish_ci,

telefono_tienda int NOT NULL,

ceco int NOT NULL,

cuenta int NOT NULL,

PRIMARY KEY(id_tienda)

)



//Taula Tipus_entrega

CREATE TABLE tipusentrega (

id_entrega int NOT NULL AUTO_INCREMENT,

nom_entrega varchar(20) NOT NULL COLLATE utf8_spanish_ci,

preu_trans int NOT NULL,

prest_log int NOT NULL,

tipus_entrega varchar(20) NOT NULL COLLATE utf8_spanish_ci,

PRIMARY KEY(id_entrega)

)

//Taula Rols

CREATE TABLE rols (

id_rol int NOT NULL AUTO_INCREMENT,

nom_rol varchar(20) NOT NULL COLLATE utf8_spanish_ci,

PRIMARY KEY(id_rol)

)

//Taula Usuaris

CREATE TABLE usuaris (

id_usuari int NOT NULL AUTO_INCREMENT,

nom varchar(20) NOT NULL COLLATE utf8_spanish_ci,

cognoms varchar(60) NOT NULL COLLATE utf8_spanish_ci,

email varchar(100) NOT NULL COLLATE utf8_spanish_ci,

carrec varchar(20) NOT NULL COLLATE utf8_spanish_ci,

usuari varchar(10) NOT NULL COLLATE utf8_spanish_ci,

contrasenya varchar(100) NOT NULL COLLATE utf8_spanish_ci,

acces int NOT NULL,

centre varchar(50) NOT NULL COLLATE utf8_spanish_ci,

responsable varchar(70) NOT NULL COLLATE utf8_spanish_ci,

PRIMARY KEY(id_usuari)

)";

//Taula Centres

CREATE TABLE centres (

id_centre int NOT NULL,

nom_centre varchar(50) NOT NULL COLLATE utf8_spanish_ci,

direccion varchar(100) NOT NULL COLLATE utf8_spanish_ci,


poblacion varchar(50) NOT NULL COLLATE utf8_spanish_ci,

provincia varchar(50) NOT NULL COLLATE utf8_spanish_ci,


PRIMARY KEY(id_centre)

)



//Taula Configuració

CREATE TABLE configuracio (

id int NOT NULL,

nom_complet varchar(70) NOT NULL COLLATE utf8_spanish_ci,

nom_curt varchar(50) NOT NULL COLLATE utf8_spanish_ci,

direccio varchar(100) NOT NULL COLLATE utf8_spanish_ci,


poblacio varchar(50) NOT NULL COLLATE utf8_spanish_ci,

provincia varchar(50) NOT NULL COLLATE utf8_spanish_ci,


nif varchar(20) NOT NULL COLLATE utf8_spanish_ci,

PRIMARY KEY(id)

)

Un cop carregat tots els fitxers al servidor i executades totes les comandes SQL de creació de

taula ja queda completament disponible l’aplicació Wigow per el seu ús.



9.3 Possibles servidors de Wigow

Empresa: Hostgator

Preu 2,96€ / mes

Espai Il·limitat

Base de dades Il·limitades

Transferència Il·limitada

Empresa: OVH

Preu 4,99€ / mes

Espai 100 GB

Base de dades 1 Base de dades de 2GB


Empresa: DreamHost

Preu 6,71€ / mes

Espai Il·limitat

Base de dades Il·limitades


Empresa: Hostalia

Preu 3,71€ / mes

Espai 5 GB

Base de dades 1 Base de dades Il·limitada

Transferència 10 GB

Empresa: CDMon

Preu 13,75€ / mes

Espai 5 GB

Base de dades 250 MB

Transferència 150 GB



10. Glossari

A

Albarà: Entenem com albarà a la sol·licitud del client que sol·licita a un punt de venda un servei

d’entrega a domicili. Aquest albarà conté tota la informació necessària del client amb tots els

serveis sol·licitats. A diferència d’un albarà normal, no es necessari la firma del client ja que, mai se

l’hi arriba a lliurar.

C

Centre: El centre fa referencia al magatzem central que gestiona els serveis d’entregues dels punts

de venda que serveix. Depenent de l’organització de l’empresa tindrem, un centre o més d’un

centre.

Client: El client és la persona que va al punt de venda i sol·licita els serveis. Aquest client és el

que rebrà els serveis sol·licitats a través de l’empresa de transport.

CSS: És el acrònim de “Cascading Style Sheets”. Traduït significa Fulles d’estil en cascada,

utilitzat en el disseny de pagines web en HTML. Dissenyat especialment per separar el disseny del

codi de la pàgina, conté tota la part gràfica de la pàgina web. Millora la resposta de la pàgina ja que,

només ha de carregar el primer cop tots els estils.

H

HTML: És el acrònim de “HyperText Markup Language”. Traduït significa Llenguatge de

marcació de Hipertext. Utilitzat en pàgines web per descriure l’estructura de la pàgina web.

J

JQuery: És una biblioteca de JavaScript. Dissenyat especialment per interactuar amb els

documents HTML de les pàgines. WEB. Gestiona els esdeveniments, les animacions,... que es

produeixen en la pàgina web.



Just-in-Time: Sistema d’organització per a fàbriques. D’origen japonès permet millorar la

productivitat i reduir els costos. Es basa en produir i distribuir el just i necessari. Reduir els estocs al

mínim, si es poden suprimir es suprimeixen. Considera que és més productiu produir i

re-aprovisionar el que es ven, no es fan previsions d’estoc.

L

Lean-manufacturing: Filosofia japonesa sobre la gestió enfocada a donar el màxim benefici al

client. És conegut també com a Lean. El seu propòsit és eliminar tots els malbarataments. Aquests

malbarataments poden ser:

Sobreproducció

temps d’espera

transport

excés de processos

inventari

moviments

defectes

potencial humà mal utilitzat

P

PHP: Llenguatge de programació d’alt nivell. Utilitzat per la programació de pàgines web. És un

llenguatge interpretat, per tant, no té la necessitat de compilació. S’executa al costat del servidor.

R

Re-facturació: Entenem com a re-facturació a un dels processos de la comptabilitat analítica que

consisteix en atribuir els costos de l’empresa a un compte d’explotació. Serveix per poder imputar

costos i poder portar un control sobre els costos de producció de cada centre.

Ruta: Una ruta representa a les agrupacions de serveis que es fan per poder reduir els costos. Les

rutes estan programades per un dia en concret i s’hi poden afegir tots els albarans i serveis que es

vulguin.



S

Servei: Un servei representa cada una de les accions que es realitzen sobre un article en concret.

Per exemple, entregar un article es considera un article i muntar aquest article és considera un altre

servei. Un albarà pot tenir tots els serveis que el client sol·liciti.

SQL: El acrònim de “Structured Query Language” que significa: Llenguatge de Consulta

Estructurat. És utilitzat en les bases de dades. Permet realitzar consultes sobre les bases de dades.



11. Bibliografia

Per poder realitzar el projecte he necessitat consultar moltes fonts. Els meus coneixements abans de

realitzar el projecte eren molt limitats en el àmbit del desenvolupament d’aplicacions web. He

dividit les fonts consultades en 3 principals blocs. En programació, que conté totes les fonts

consultades per poder desenvolupar el codi de l’aplicació, en disseny web, que conté les fonts

utilitzades per adquirir els coneixements sobre la part gràfica de l’aplicació i finalment, la usabilitat,

que conté les fonts consultades per conèixer els principis d’usabilitat.

11.1 Programació

Manual de PHP ( 20 – 01 – 2013 )

http://www.desarrolloweb.com/manuales/58/

Video Tutorial de PHP ( 20 – 01 – 2013 )

http://www.desarrolloweb.com/manuales/videotutorial-php.html

PHP .NET ( 20 – 01 – 2013 )

http://php.net/

JQuery ( 20 – 01 – 2013 )

http://api.jquery.com/

Manual de SQL ( 20 – 01 – 2013 )

http://www.w3schools.com/sql/default.asp

Manual de SQL ( 20 – 01 – 2013 )


MySQL administrator's guide, MySQL AB, Indianapolis, Ind. Sams Pub., 2004

Proyectos profesionales PHP 5, Charte Ojeda, Francisco, Madrid Anaya Multimedia, 2004

PHP, MySQL y Apache, Meloni, Julie C, Madrid Anaya Multimedia, 2009


http://www.desarrolloweb.com/manuales/videotutorial-php.html

http://php.net/

http://api.jquery.com/

http://www.w3schools.com/sql/default.asp




11.2 Disseny Web

Manual CSS ( 20 – 01 – 2013 )

http://www.desarrolloweb.com/manuales/css3.html

Manual CSS ( 20 – 01 – 2013 )

http://www.w3schools.com/css/

Manual HTML ( 20 – 01 – 2013 )


Video Tutorial HTML ( 20 – 01 – 2013 )

http://www.desarrolloweb.com/manuales/video-tutorial-html.html

Styling web pages with CSS visual quickproject guide, Negrino, Tom; Smith, Dori, Berkeley,

Calif. Peachpit Press, 2009

11.3 Usabilitat

Manual Usabilitat ( 20 – 01 – 2013 )

http://www.desarrolloweb.com/directorio/diseno/usabilidad/

http://www.desarrolloweb.com/manuales/css3.html

http://www.w3schools.com/css/


http://www.desarrolloweb.com/manuales/video-tutorial-html.html

http://www.desarrolloweb.com/directorio/diseno/usabilidad/

treball fi de carrera -...

Documents